Nothing Special   »   [go: up one dir, main page]

WO2024225124A1 - 障害分析支援システム及び障害分析支援方法 - Google Patents

障害分析支援システム及び障害分析支援方法 Download PDF

Info

Publication number
WO2024225124A1
WO2024225124A1 PCT/JP2024/015210 JP2024015210W WO2024225124A1 WO 2024225124 A1 WO2024225124 A1 WO 2024225124A1 JP 2024015210 W JP2024015210 W JP 2024015210W WO 2024225124 A1 WO2024225124 A1 WO 2024225124A1
Authority
WO
WIPO (PCT)
Prior art keywords
confirmation
safety
cause
work
control system
Prior art date
Application number
PCT/JP2024/015210
Other languages
English (en)
French (fr)
Inventor
浩二 浦脇
貴広 池田
壮希 櫻井
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from JP2023070723A external-priority patent/JP2024156343A/ja
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Publication of WO2024225124A1 publication Critical patent/WO2024225124A1/ja

Links

Definitions

  • the present invention relates to a fault analysis support system and a fault analysis support method for a control system.
  • monitoring devices monitor the system and instruct on-site maintenance personnel on how to respond, etc., thereby improving efficiency.
  • Patent Document 1 discloses a technology in which a system monitoring device receives abnormality data from a control system, analyzes how to deal with the problem, and instructs on-site maintenance personnel on how to deal with the problem.
  • Patent Document 2 discloses a technology in which a monitoring system collects data from a control system and analyzes whether the cause of an incident is a cyber attack.
  • a logistics warehouse system is made up of a control system that controls each device in the warehouse and a fault analysis support system that measures the operation data of each device and monitors the operating status of the entire control system or each device.
  • the measurement data uploaded to the fault analysis support system may not be sufficient to analyze the status of the control system. Also, in order for on-site maintenance personnel at the warehouse where the abnormality occurred to analyze the cause, confirmation work may be required, such as obtaining data such as the operation logs and external appearance of various devices.
  • Causes of control system anomalies are not limited to equipment failures due to aging, but can also be security-related, such as cyber attacks or malware infections. When security issues are the cause, anomalies may occur simultaneously in multiple devices, which can increase safety risks during on-site inspection work. In addition, while various data is collected and equipment is operated during confirmation work for cause analysis, valid data may not be collected depending on the order in which tasks are performed, which poses the issue of reduced efficiency of cause analysis.
  • the present invention aims to provide technology that allows on-site maintenance personnel to safely and efficiently carry out on-site inspection work when an abnormality is detected in a control system.
  • the fault analysis support system is a fault analysis support system that supports fault analysis of a control system consisting of one or more devices, and includes a monitoring input unit that collects equipment monitoring data related to the operating status of the devices and stores it in an equipment monitoring log database, an anomaly detection unit that monitors the equipment monitoring data to detect abnormalities in the control system, an anomaly cause database that associates and stores abnormalities in the control system with causes inferred from the abnormalities, a cause estimation unit that estimates a cause based on a detected abnormality in the control system, and a system anomaly detection unit that associates and stores the abnormalities in the control system, common cause events having the estimated cause as a common cause, the operating status of the control system, and safety impacts that indicate the impact on safety in the work area caused by the abnormality in the devices.
  • the system is configured as a failure analysis support system having a safety analysis unit that uses a normal operation database to analyze the impact of the work to confirm the estimated cause on safety, a confirmation work derivation unit that uses the estimated cause and the common cause event to search for confirmation work corresponding to the estimated cause and the common cause event from a confirmation work database that associates and stores confirmation work that lists work to check whether the estimated cause is the true cause with the work area where the confirmation work is performed, and derives the search results as a confirmation work list, and a confirmation work evaluation unit that evaluates the safety of the confirmation work based on the analysis results of the impact on safety and the confirmation work included in the confirmation work list, and outputs the confirmation work list that reflects the evaluation results.
  • a safety analysis unit that uses a normal operation database to analyze the impact of the work to confirm the estimated cause on safety
  • a confirmation work derivation unit that uses the estimated cause and the common cause event to search for confirmation work corresponding to the estimated cause and the common cause event from a confirmation work database that associates and stores confirmation work that lists
  • FIG. 1 is a diagram showing a state in which a fault analysis support system according to one embodiment of the present invention is connected to equipment in a logistics warehouse or information terminal equipment of a site maintenance worker via a communication network.
  • 1 is a configuration diagram of a failure analysis support system according to an embodiment.
  • FIG. 2 illustrates an example of a device monitoring log database.
  • FIG. 13 is a diagram illustrating an example of an abnormality cause database.
  • FIG. 13 is a diagram illustrating an example of a system abnormal operation database.
  • FIG. 11 is a diagram illustrating an example of a confirmation work database.
  • FIG. 4 is a diagram illustrating an example of a safety measure database.
  • FIG. 13 is a flowchart illustrating a processing flow from when the fault analysis support system detects an abnormality in a control system to when the system evaluates the safety of a work area in a logistics warehouse.
  • 11 is a flowchart illustrating a process flow in which the failure analysis support system derives confirmation work contents necessary for cause investigation and determines the execution order.
  • This figure shows a flowchart from when a confirmation work list created by the fault analysis support system is displayed on a screen display unit viewed by a field maintenance worker, to when, based on the results of the confirmation work, cause analysis is performed and the confirmation work list is re-created until the cause can be identified.
  • FIG. 13 is a diagram showing an example of a confirmation task list displayed on a screen display unit.
  • FIG. 11 is a diagram showing an example of a site confirmation work list.
  • FIG. 11 is a diagram showing an example of a site confirmation work list (after steps ST502 and ST503 are performed).
  • FIG. 11 is a diagram showing an example of an on-site confirmation work list (after steps ST505 and ST506 are performed).
  • expressions such as “table,” “list,” and “queue” may be used, but the various types of information may be expressed in other data structures.
  • various types of information such as “XX table,” “XX list,” and “XX queue” may be expressed as “XX information.”
  • identification information expressions such as “identification information,” “identifier,” “name,” “ID,” and “number” are used, but these are interchangeable.
  • the processing performed by executing a program may be described.
  • a computer executes the program using a processor (e.g., a CPU or a GPU), and performs processing defined by the program using storage resources (e.g., a memory) and interface devices (e.g., a communication port). Therefore, the subject of the processing performed by executing a program may be a processor.
  • the subject of the processing performed by executing a program may be a controller, device, system, computer, or node having a processor.
  • the subject of the processing performed by executing a program may be a calculation unit, and may include a dedicated circuit that performs specific processing.
  • the dedicated circuit is, for example, an FPGA (Field Programmable Gate Array), an ASIC (Application Specific Integrated Circuit), or a CPLD (Complex Programmable Logic Device).
  • the program may be installed on the computer from a program source.
  • the program source may be, for example, a program distribution server or a computer-readable storage medium.
  • the program distribution server may include a processor and a storage resource that stores the program to be distributed, and the processor of the program distribution server may distribute the program to be distributed to other computers.
  • two or more programs may be realized as one program, and one program may be realized as two or more programs.
  • FIG. 1 is a diagram showing a state in which a fault analysis support system 20 according to one embodiment of the present invention communicates with equipment in a logistics warehouse or with an information terminal device 80 of a site maintenance worker 10 via a communication network 70.
  • the communication network 70 is a data communication path that uses a communication protocol such as EtherCAT or Modbus.
  • the logistics warehouse is also equipped with automatic transport devices 30 and 40, robot arms 50, and conveyor equipment 60, etc., that transport, load, unload, and process luggage.
  • the fault analysis support system 20 is positioned as one of the subsystems included in the WMS (Warehouse Management System) that manages the incoming and outgoing of goods in the logistics warehouse system 1000 and the WES (Warehouse Execution System) that controls the equipment and handles communication between devices.
  • WMS Warehouse Management System
  • WES Warehouse Execution System
  • the fault analysis support system 20 monitors the operating status of the control system 200, and when a fault occurs, performs analysis to determine the cause and provides information to the on-site maintenance personnel 10.
  • Causes of abnormalities in the control system 200 include not only equipment failures due to aging, but also security-related causes such as cyber attacks and malware infections.
  • the work of confirming the cause of the problem involves acquiring various data and operating equipment, but depending on the order in which tasks are performed, it may not be possible to acquire valid data, which can reduce the efficiency of the cause analysis.
  • the failure analysis support system 20 in the embodiment of the present invention derives the tasks required for cause investigation when an abnormality is detected in the control system 200, and enables on-site maintenance personnel to safely and efficiently analyze the cause based on the analysis results of the safety of each task and the dependency relationships between tasks. Furthermore, the system supports system failure analysis by calculating the priority of tasks and notifying the on-site maintenance personnel 10. In order to analyze the cause of a failure in a remote environment, the system enables the on-site maintenance personnel 10 to efficiently perform the tasks required for cause investigation on-site while reducing safety and security risks.
  • FIG. 2 is a configuration diagram of a failure analysis support system 20 according to this embodiment.
  • the fault analysis support system 20 has a monitoring input unit 202, an abnormality detection unit 203, a cause estimation unit 204, a safety analysis unit 205, a confirmation work derivation unit 206, a confirmation work evaluation unit 207, a monitoring output unit 208, an equipment monitoring log database 210, an abnormality cause database 211, a system abnormal operation database 212, a confirmation work database 213, and a safety measure database 214.
  • the screen display unit 701 is a display device such as a display of the information terminal device 80.
  • the abnormality detection unit 203 monitors equipment monitoring data, including operation logs of each control device 201 constituting the control system 200 and a system operation status indicating whether the control system 200 is operating, as well as on-site confirmation data acquired by the on-site maintenance personnel 10 during confirmation work, to detect abnormalities (referred to as observed events) in the control system 200.
  • the cause estimation unit 204 estimates the cause based on the abnormality detected by the anomaly detection unit 203 (the estimated cause is called the estimated cause), and derives events that occur with the estimated causes as a common cause (called common cause events).
  • the safety analysis unit 205 analyzes the impact on safety of observed events, presumed causes, and common cause events.
  • the confirmation task derivation unit 206 derives the confirmation tasks required for the on-site maintenance personnel 10 to investigate the occurrence of the event, and creates a confirmation task list.
  • the confirmation work evaluation unit 207 evaluates the safety of each confirmation work content based on the results of the impact analysis on safety and each confirmation work content, and outputs a confirmation work safety evaluation result.
  • the confirmation work evaluation unit 207 also outputs a feasibility evaluation result for the confirmation work. Furthermore, the confirmation work evaluation unit 207 outputs a confirmation work safety evaluation result after countermeasures have been taken and a feasibility evaluation result for the confirmation work after countermeasures have been taken.
  • FIG. 3A to 3E are diagrams showing examples of each database used for analyzing a system fault by the fault analysis support system 20 according to this embodiment. They show data items and data contents of each database (device monitoring log database 210, abnormality cause database 211, system abnormal operation database 212, confirmation work database 213, and safety measure database 214) shown in the configuration of the fault analysis support system 20 in FIG.
  • FIG. 3A is a diagram showing an example of the equipment monitoring log database 210.
  • the equipment monitoring log database 210 is where the fault analysis support system 20 accumulates data from the logistics warehouse site.
  • the equipment monitoring log database 210 stores equipment monitoring data including operation logs of each control device 201 constituting the control system 200 and a system operation status indicating whether the control system 200 is operating, and on-site confirmation data acquired by the on-site maintenance personnel 10 during confirmation work.
  • it is composed of information such as the date of collection, the target equipment, and the sender for identifying whether the data was sent from the equipment or collected by the on-site maintenance personnel 10.
  • the actual equipment monitoring data and on-site confirmation data described above are stored in association with this information.
  • the collection date "YYYY/MM/DD" indicating the timing when the data was acquired, the target device "Device A” indicating the subject of data acquisition, and the sender "Device A” indicating the location of the subject of data acquisition are stored in association with each other, and further the data entities acquired during monitoring are associated with this information and stored as device monitoring data. As with the device monitoring data, the data entities acquired during on-site inspections are also stored in association with each of these items.
  • FIG. 3B is a diagram showing an example of the anomaly cause database 211.
  • the anomaly cause database 211 is used by the cause estimation unit 204 to estimate the cause of a detected anomaly in the control system 200.
  • the anomaly cause database 211 contains information on observed events and causes (estimated causes) estimated from the observed events.
  • FIG. 3C is a diagram showing an example of the system abnormal operation database 212.
  • the system abnormal operation database 212 is used by the safety analysis unit 205 to further investigate events that may occur due to the same cause.
  • the system abnormal operation database 212 contains information such as the above-mentioned observed events and common cause events, information on the system operation status indicating whether the control system 200 is operating or not, and safety impact information indicating the impact on safety of the work area in the logistics warehouse caused by an abnormality in the control system 200.
  • FIG. 3D is a diagram showing an example of the confirmation work database 213.
  • the confirmation work derivation unit 206 uses the confirmation work database 213 to derive on-site confirmation work for analyzing the true cause of a system abnormality.
  • the confirmation work database 213 contains information such as the above-mentioned presumed causes and common cause events, confirmation work that lists the work to investigate whether the presumed cause is the true cause, the work area in which the confirmation work is performed, the work procedure for the confirmation work, the equipment used for the confirmation work, the data collected in the confirmation work, and the dependency relationship between the confirmation work and other confirmation works.
  • the operation log of device A is collected in work area 1 as a confirmation task.
  • This confirmation task is performed using a USB memory and information terminal device 80, which serves as the operation terminal for device A, by first connecting the USB memory to device A and saving the operation log of device A on DD day, MM month, YYYY. Furthermore, this confirmation task is restricted to be performed before the restart of device A as a dependency relationship with other confirmation tasks other than this confirmation task.
  • FIG. 3E is a diagram showing an example of the safety measures database 214.
  • the safety measures database 214 is used by the confirmation work evaluation unit 207 to investigate countermeasures for reducing the risk of confirmation work with high safety risks.
  • the safety measures database 214 contains information on the above-mentioned confirmation work, measures for reducing the safety risk of the confirmation work, and the expected effects. Examples of safety measures include changing the execution order of multiple confirmation works stored in the confirmation work list, moving equipment (e.g., equipment A, equipment C) operated in the confirmation work, and stopping the operation of equipment with high safety risks or the control system 200 including the equipment or the equipment based on the results of the safety impact analysis. In addition, the effects of these measures include information on changes in risk, such as a safety risk changing from "high" to "low.”
  • the confirmation work evaluation unit 207 reduces safety risks by performing at least one of these.
  • the equipment monitoring log database 210 is composed of accumulated data collected from the control system 200.
  • the data for each of the other databases (210-214) shown in Figures 3A-3E is prepared based on the results of a prior analysis of the safety of the configuration of the control system 200 and the logistics warehouse site, such as events that are observed in advance and their presumed causes, events that may occur due to common causes, and their impact on safety.
  • Safety risk assessment flow chart> 4 is a flow chart explaining the flow of processing in which the fault analysis support system 20 detects an abnormality in the control system 200, infers the cause, and evaluates events that may occur due to the cause and the safety of the work area in the logistics warehouse due to the events. Each step in FIG. 4 will be explained below.
  • the abnormality detection unit 203 monitors the equipment monitoring data received by the monitoring input unit 202, including the operation logs of each control device 201 that constitutes the control system 200 and the system operation status indicating whether the control system 200 is operating, to detect an abnormality in the control system 200.
  • Step ST402 Cause Estimation Cause estimation unit 204 estimates a possible cause based on the abnormality detected by abnormality detection unit 203. It outputs the estimated cause (estimated cause). This will be specifically described below.
  • the cause estimation unit 204 When the cause estimation unit 204 receives equipment monitoring data including observed events and system operation status from the anomaly detection unit 203, it searches the anomaly cause database 211 for the estimated cause of the anomaly using the system operation status and observed events as conditions. The cause estimation unit 204 sets the cause that meets the search conditions as the estimated cause that may have caused the observed event. For example, the cause estimation unit 204 reads out the equipment monitoring data contained in the equipment monitoring log database 210 shown in FIG. 3A, and when the control system 200 is in a normal operating state while equipment A is unresponsive, it refers to the anomaly cause database 211 shown in FIG. 3B and outputs "cybersecurity attack" and "equipment A failure" as the estimated cause of the observed event.
  • Step ST403 Identification of Common Cause Events
  • the cause estimation unit 204 derives events (called common cause events) other than the observed events that may occur due to the estimated causes. This will be specifically described below.
  • the cause estimation unit 204 searches the anomaly cause database 211 for events other than the observed event, using the estimated cause estimated in step ST402 and the system operating status as conditions.
  • the cause estimation unit 204 regards the cause that meets the search conditions as the estimated cause that may have caused the observed event.
  • the cause estimation unit 204 detects a communication anomaly between the equipment of the control system 200 and the fault analysis support system 20, in which the operating status of the equipment cannot be monitored (no response from equipment A), as an observed event.
  • the estimated cause may be not only equipment failure due to aging or the like, but also security-related causes such as cyber attacks and malware infection.
  • the observed event is a communication anomaly with the equipment
  • the common cause event derived is an operation anomaly due to equipment failure in the equipment and an unintended operation due to security factors.
  • the cause estimation unit 204 derives "cybersecurity attack” as the common cause event of equipment A and equipment B.
  • the cause estimation unit 204 outputs the observed event (no response from device A), the common cause event (cybersecurity attack), and the system operating status (all control systems 200 are in a normal state). If the anomaly cause database 211 similarly stores information about device C, it outputs "cybersecurity attack” as the common cause event for devices A to C, and outputs the system operating status (all control systems 200 are in a normal state).
  • Step ST404 Analysis of Impact on Safety
  • the safety analysis unit 205 analyzes the impact on safety of the estimated cause estimated in ST402 and the common cause event derived in ST403. This will be specifically described below.
  • the safety analysis unit 205 receives information on observed events, common cause events, and system operation status from the cause estimation unit 204, and uses this information to search the system abnormal operation database 212 for the impact on safety of work areas in the logistics warehouse.
  • the safety analysis unit 205 evaluates the safety of each work area using the search results that correspond to the content of each of the above information.
  • the impact on safety may be, for example, a change in the degree of danger in a specific area in a logistics warehouse or the presence or absence of such a change.
  • a transport device moving through the work area 1 may perform an unintended operation due to an observed event or a common cause event, and may collide with or cause harm to equipment or workers in the work area 1.
  • the system abnormal operation database 212 evaluates the safety of the work area as "increased safety risk in the work area 1" (i.e., there is an impact that safety is reduced).
  • the safety analysis unit 205 outputs a safety impact of "increased safety risk in the work area 1" corresponding to this information.
  • the case where the common cause event is a "cybersecurity attack” is also defined in the system abnormal operation database 212.
  • the fault analysis support system 20 After detecting an abnormality in the control system 200 in the logistics warehouse through the above process, the fault analysis support system 20 estimates the cause of the abnormality and analyzes events that occur due to a common cause, and performs a safety assessment of the work area in the logistics warehouse that changes due to the abnormality detected as an observed event and the common cause event.
  • FIG. 5 is a flowchart for explaining the flow of processing performed by the failure analysis support system 20 from deriving the confirmation work contents required for cause investigation to determining the order of execution.
  • Step ST501 Deriving Confirmation Work Necessary for Cause Investigation
  • the confirmation work derivation unit 206 derives a confirmation work for the field maintenance worker 10 that is necessary for investigating whether the estimated cause is the true cause.
  • the confirmation work derivation unit 206 references the confirmation work database 213 and outputs a confirmation work list for investigating the occurrence status and occurrence process of the presumed causes, observed events, and common cause events output in each process from step ST401 to step ST404. Based on the confirmation work list output by the confirmation work derivation unit 206, the on-site maintenance personnel 10 performs confirmation work such as checking equipment logs, communication logs between equipment, external appearance conditions, conducting diagnostic tests, and collecting data.
  • the confirmation task derivation unit 206 derives a confirmation task list, which includes confirmation tasks such as collecting communication logs between devices, diagnosing a communication interface failure, and collecting operation logs of devices that are unable to communicate.
  • the confirmation task derivation unit 206 uses the input information on presumed causes, observed events, and common cause events to search the confirmation task database 213 for confirmation tasks stored in association with the presumed causes and common cause events.
  • the relevant search results are compiled into a list, and output as a confirmation task list.
  • the confirmation work derivation unit 206 searches the confirmation work database 213 for a confirmation work list for determining the true cause of (1) a cybersecurity attack and (2) a failure of device A, which are stored as presumed causes. In this search, records 301 are searched. An example of the search results is shown in the on-site confirmation work list 901 in FIG. 9.
  • FIG. 9 is a diagram showing an example of an on-site confirmation work list 901.
  • the on-site confirmation work list 901 corresponds to an order indicating the order in which the confirmation work is performed, a state indicating the implementation status of the confirmation work, each item similar to the above-mentioned confirmation work database 213, as well as the items of safety risk when performing the confirmation work and feasibility indicating whether the confirmation work can be performed in light of the safety risk.
  • the above-mentioned order, state, safety risk, and feasibility items are recorded in subsequent processing.
  • the list obtained by the above search corresponds to record 9011 of the on-site confirmation work list 901.
  • the above lists are output for all of the presumed causes, observed events, and common cause events output in each process from step ST401 to step ST404 in FIG. 4 (a total of four records).
  • Step ST502 Evaluation of Safety of Confirmation Work
  • the confirmation work evaluation unit 207 evaluates the safety of each confirmation work included in the confirmation work list derived in step ST501.
  • the confirmation work evaluation unit 207 searches the confirmation work database 213 for the work areas of each confirmation work included in the confirmation work list.
  • the confirmation work evaluation unit 207 compares the work areas found by this search with the safety evaluation results of each work area evaluated in step ST404, evaluates the safety of each confirmation work, and outputs the results as the confirmation work safety evaluation results.
  • the confirmation task evaluation unit 207 identifies the confirmation task "equipment A operation log collection" in the on-site confirmation task list 901 shown in FIG. 9 and the task area "task area 1" corresponding to the confirmation task in the confirmation task database 213 shown in FIG. 3D.
  • the confirmation task evaluation unit 207 compares the confirmation task "equipment A operation log collection” with the safety impact "increased safety risk in task area 1" output in ST404, and evaluates that performing the confirmation task in task area 1 will have the effect of increasing the safety risk.
  • the confirmation task "equipment A operation log collection” has been described, but the same applies to other confirmation tasks. That is, if the confirmation task in the on-site confirmation task list 901 shown in FIG.
  • the confirmation work evaluation unit 207 sets safety standards in advance and evaluates the safety risks. For example, three levels of “high, medium, low” are set as the criteria for the level of safety risk, with a "high” level indicating a level that causes harm to people, a “medium” level indicating a level that causes harm to objects but does not break them, and a “low” level indicating a level that has no impact on the outside. If the level required for safety in work area 1 is a specified level of safety risk that causes harm to people, the confirmation work evaluation unit 207 evaluates the safety risk of the confirmation work as "the confirmation work in work area 1 has a high safety risk.”
  • Step ST503 Evaluating Feasibility of Confirmation Work before Countermeasures are Taken
  • the confirmation work evaluation unit 207 evaluates the feasibility of each confirmation work by using the confirmation work safety evaluation result, which is the processing result of step ST502.
  • the confirmation work evaluation unit 207 sets a criterion for determining whether or not a confirmation work can be performed, and evaluates the feasibility of the confirmation work. For example, if the safety risk described in step ST502 is expressed as a three-level scale of "high, medium, and low,” the confirmation work is evaluated as “feasible” if the safety risk is “medium” or “low,” and is otherwise evaluated as “not feasible.” The feasibility evaluation result is output as the feasibility evaluation result of the confirmation task.
  • Figure 10 shows an example of an on-site confirmation work list created when steps ST502 and ST503 are performed.
  • FIG 10 it can be seen that by performing the processing of steps ST502 and ST503, each item of safety risk and feasibility is evaluated, and the results of that evaluation are written and reflected in the confirmation work list output.
  • the confirmation task in work area 1 can be determined to have an increased safety risk in work area 1 based on the common cause events and safety impact data in the system abnormal operation database 303. Therefore, the confirmation task evaluation unit 207 evaluates the safety risk as "high”. On the other hand, using the same idea, the confirmation task evaluation unit 207 evaluates the safety risk of other tasks performed in work area 2 as "low”. Furthermore, referring to the criteria in step ST503, the confirmation task evaluation unit 207 evaluates the feasibility of tasks with a "high” safety risk as "not feasible” and creates an on-site confirmation task list 1001 for which no safety measures are implemented.
  • the confirmation work evaluation unit 207 sets safety measures for the confirmation work that is determined to be "not executable” in the feasibility evaluation result of the confirmation work, which is the processing result of step ST503, and re-evaluates the safety risks and feasibility.
  • the confirmation work evaluation unit 207 searches the safety measures database 214 for safety measures for confirmation works that have been evaluated as having a high safety risk and being infeasible, based on the confirmation work safety evaluation result output in step ST502 and the confirmation work feasibility evaluation result output in step ST503, and selects effective measures.
  • the confirmation work evaluation unit 207 then reevaluates the safety risk due to the measures, and outputs the result as the confirmation work safety evaluation result after the measures have been taken.Furthermore, it reevaluates feasibility based on the reevaluated safety risk, and outputs the result as the feasibility evaluation result for the confirmation work after the measures have been taken.
  • the confirmation task evaluation unit 207 evaluates the confirmation task "collecting device A's operation log" in work area 1 as having a "high” safety risk and an "unfeasible” feasibility. Therefore, by referring to the safety measure database 214 shown in FIG. 3E, the unit selects the safety measure "stopping abnormal operation of device C to reduce the safety risk in work area 1" that corresponds to the confirmation task "collecting device A's operation log.”
  • the confirmation work evaluation unit 207 When the on-site maintenance worker 10 checks the above safety measures and "stops the abnormal operation of equipment C", the confirmation work evaluation unit 207 again performs steps ST502 and ST503. At this time, in ST502, the safety evaluation results of each work area evaluated in step ST404 are again referred to. In this reference, the confirmation work evaluation unit 207 requests the safety analysis unit 205 to perform step ST404 again. In accordance with this request, the safety analysis unit 205 performs an impact analysis on safety at the current time. In this example, since the on-site maintenance worker 10 checks the above safety measures and "stops the abnormal operation of equipment C", the "abnormal operation of equipment C" has been eliminated as a common cause event. Therefore, the safety analysis unit 205 returns a result of "none" as a safety impact to the confirmation work evaluation unit 207.
  • the confirmation task evaluation unit 207 performs step ST502 in accordance with the safety evaluation received from the safety analysis unit 205, and evaluates that if the confirmation task "collecting device A's operation log" is performed in work area 1, the safety risk has decreased to a certain degree and the level has become “low”. Furthermore, the confirmation task evaluation unit 207 performs step ST503, and evaluates the confirmation task as "feasible” in accordance with the above-mentioned criteria. In this example, the confirmation task "collecting device A's operation log" in work area 1 is reevaluated as having a safety risk of "low” and feasibility of "feasible”.
  • Step ST505 Analyzing dependencies between confirmation tasks
  • the confirmation task evaluation unit 207 has evaluated the safety risk and feasibility of each confirmation task included in the on-site confirmation task list 901, and further re-evaluated it.
  • the confirmation task evaluation unit 207 examines the dependencies between each confirmation task included in the confirmation task list.
  • the confirmation task evaluation unit 207 examines the work procedure indicating the specific work content of each confirmation task, and the impact on other tasks.
  • the confirmation work evaluation unit 207 refers to the item "Dependencies with other confirmation works" stored in the confirmation work database 213 shown in FIG. 3D and analyzes the contents of that item, or reads all of the "Work procedures" items for each confirmation work and analyzes their contents. From the results of these analyses, the confirmation work evaluation unit 207 determines the chronological order of each work procedure, thereby determining the precedence relationship of each confirmation work. The confirmation work evaluation unit 207 confirms the dependencies as described above, and outputs the dependency confirmation results.
  • Step ST506 Determining the Execution Order of the Verification Works
  • the verification work evaluation unit 207 determines the execution order of each verification work for which the feasibility has been evaluated and the dependency relationship has been confirmed.
  • the basic priority selection criteria of the confirmation work evaluation unit 207 is to highly evaluate work that has a low safety risk, is feasible, and has no dependencies on other work or that should take precedence due to dependencies, and to select from those works.
  • the confirmation task evaluation unit 207 first selects (1) tasks that do not require safety measures, have low safety risks, and have been evaluated as "feasible” for feasibility, and that have no dependencies on other tasks, as the tasks to be executed with priority. Next, the confirmation task evaluation unit 207 selects (2) tasks that have been evaluated as "feasible” for feasibility after implementing safety measures and reducing safety risks, and that have been selected with priority in terms of dependencies, as the tasks to be executed with priority.
  • the confirmation tasks selected in (2) are the confirmation tasks whose safety risks and feasibility have been reevaluated in steps ST502 and ST503 described above.
  • FIG. 11 An example of a site confirmation task list created when steps ST505 and ST506 are performed is shown in FIG. 11.
  • the confirmation task evaluation unit 207 identifies a confirmation task that has a high safety risk and is not feasible.
  • the confirmation task evaluation unit 207 adds a procedure to stop the operation of equipment C based on the safety measures in the safety measures database 214 in order to ensure the safety of the work area 1, which was a factor in increasing the safety risk, for the identified confirmation task.
  • "(1) Operation stopped for safety measures" is added to the record with the order "2". By adding this procedure, the safety risk of the work area 1 can be reduced, and all tasks can be performed.
  • a site confirmation task list 1101 such as that shown in FIG. 11 is output.
  • the site maintenance worker 10 refers to the list and performs the work procedure for the confirmation task (in this case, for equipment C, the work procedure "(1) Operation stopped for safety measures" of the confirmation task "Fault diagnosis and log collection of equipment C").
  • the safety risk of other inspection tasks performed in work area 1 in this example, inspection tasks numbered "3" and "4" becomes "low” and the feasibility becomes "feasible.”
  • the confirmation work evaluation unit 207 prioritizes log collection for device B, which has no execution dependency (order 1), and then performs fault diagnosis and log collection for device C, which includes safety measures procedures (order 2). Furthermore, in collecting logs for device A, the confirmation work evaluation unit 207 performs operation log collection for device A before the device is restarted, due to the dependency of collecting logs before the device is restarted (order 3). Finally, the confirmation work evaluation unit 207 performs operation log collection after the device is restarted (order 4).
  • FIG. 6 is a flowchart showing the process in which the confirmation work list created as described above is displayed on the screen display unit 701 of the information terminal device 80, and the confirmation work list is recreated based on the results of the confirmation work performed by the on-site maintenance worker 10.
  • Step ST601 Screen display of confirmation work
  • the monitor output unit 208 receives the confirmation work list including the execution order, which is the output of step ST506, and sends the confirmation work list to the screen display unit 701 of the information terminal 80.
  • the screen display unit 701 displays the confirmation work list to the site maintenance worker 10.
  • Fig. 7 is a diagram showing an example of a confirmation work list displayed on the screen display unit 701.
  • the items displayed on the screen display unit 701 include some or all of the items in the on-site confirmation work list described using Figs. 9 to 11.
  • Step ST602 Confirmation Work and Upload to the Failure Analysis Support System
  • the field maintenance worker 10 confirms the confirmation work list displayed on the screen display unit 209 and understands the confirmation work required for the cause analysis.
  • the field maintenance worker 10 performs the confirmation work according to the order of the confirmation work displayed on the screen display unit 701.
  • the screen display unit 701 of the information terminal 80 in response to an operation from the field maintenance worker 10, uploads data of the work result (referred to as field confirmation data) acquired from the device or system in association with the performed confirmation work to the failure analysis support system 20.
  • the field maintenance worker 10 connects a recording medium such as a USB memory to device A, and the control device 201 connected to device A transmits the log data of device A to the monitoring input unit 202 of the failure analysis support system 20 and records it in the USB memory.
  • the monitoring input unit 202 records the transmitted log data in the device monitoring log database 210 of the failure analysis support system 20 .
  • the screen display unit 209 When the log data is acquired and one confirmation task is completed, the screen display unit 209 rewrites the status of the target task in the confirmation task list from "not performed” to "completed.”
  • the screen display unit 209 can perform this rewriting by receiving information from the on-site maintenance worker 10 that all tasks included in the work procedures in the on-site confirmation task list have been performed.
  • the on-site maintenance worker 10 may manually operate the on-site confirmation task list to update the status when the data is uploaded.
  • the screen display unit 209 recreates a new on-site confirmation task list with the status updated, consisting of confirmation tasks other than the confirmation tasks whose updated status has become "completed,” and displays it on the screen. This makes it possible to present to the on-site maintenance worker 10 a new on-site confirmation task list that includes only uncompleted confirmation tasks, excluding completed confirmation tasks.
  • the fault analysis support system 20 performs cause analysis using the transmitted log data.
  • the fault analysis support system 20 checks the occurrence status of the common cause event and checks the accuracy of the estimated cause.
  • the possible estimated causes are narrowed down and the confirmation work content is limited. That is, the fault analysis support system 20 can execute each process from FIG. 4 onwards, such as abnormality detection of the control system, cause estimation, and investigation of the true cause, based on the log obtained as a result of the completed confirmation work, by newly accumulating the transmitted log data in the equipment monitoring log database 210.
  • the above log includes equipment monitoring data including the operation log of the control device 201 and the system operating status of the control system 200, and on-site confirmation data acquired by the on-site maintenance worker 10 during the confirmation work.
  • ⁇ Figure 8 Example of hardware configuration of a fault analysis support system> 8 shows an example of a hardware configuration of the failure analysis support system 20.
  • the basic configuration of the failure analysis support system 20 includes a CPU (Central Processing Unit) 801 that executes programs and the like, a ROM (Read Only Memory) 802 that records programs, tables, program data, and the like that realize each function, a volatile RAM (Random Access Memory) 803 that stores information such as files, a storage 804 that records databases, and the like, an input device 805 that serves as an interface for human operation input, a display device 806 that displays an operation screen, data, and the like, and a network interface 807 that communicates with the control system 200.
  • a CPU Central Processing Unit
  • ROM Read Only Memory
  • RAM Random Access Memory
  • Each functional unit of the CPU 801 can be configured using a circuit device that implements that function, or can be configured by the CPU 801 executing software that implements that function.
  • control device 201 and the information terminal device 80 may also be configured using the computer shown in FIG. 8.
  • the fault analysis support system detects an abnormality in the control system, derives the on-site inspection work required to determine the cause, and notifies on-site maintenance personnel of safety measures and work priorities for carrying out the inspection work safely and efficiently, enabling the on-site maintenance personnel to carry out the on-site inspection work safely and efficiently.
  • a monitoring input unit 202 that collects equipment monitoring data relating to the operating state of the above devices and accumulates it in an equipment monitoring log database 210
  • an abnormality detection unit 203 that monitors the above equipment monitoring data to detect abnormalities in the above control system
  • an abnormality cause database 211 that associates and stores abnormalities in the above control system with causes estimated from the abnormalities
  • a cause estimation unit 204 that estimates a cause based on a detected abnormality in the above control system
  • a system abnormality operation unit that associates and stores the abnormality in the above control system, a common cause event having the above estimated cause as a common cause, the operating state of the above control system, and a safety impact indicating an impact on safety in the work area caused by an abnormality in the above devices.
  • the system includes a safety analysis unit 205 that uses a database 212 to analyze the impact on safety of the work to confirm the estimated cause, a confirmation work derivation unit 206 that searches for confirmation work corresponding to the estimated cause and the common cause event from a confirmation work database 213 that associates and stores confirmation work that lists work to check whether the estimated cause is the true cause using the estimated cause and the common cause event with the work area where the confirmation work is performed, and a confirmation work evaluation unit 207 that evaluates the safety of the confirmation work based on the analysis result of the impact on safety and the confirmation work included in the confirmation work list, and outputs the confirmation work list reflecting the evaluation result.
  • This allows on-site maintenance personnel to safely and efficiently perform on-site confirmation work when an abnormality in the control system is detected.
  • the confirmation work database stores the dependency between the confirmation work and other confirmation works
  • the confirmation work evaluation unit checks the dependency between each confirmation work included in the confirmation work list, and gives a high priority to the confirmation work that should precede the others in terms of the dependency. This allows the on-site maintenance personnel to efficiently perform on-site confirmation work without having to be aware of the work order.
  • the confirmation work evaluation unit searches for the safety measures for confirmation work with high safety risks from the safety measures database 214, which associates the confirmation work with the safety measures for reducing the safety risks of the confirmation work, evaluates the effect of reducing the safety risks using the safety measures corresponding to the search results, and reevaluates the feasibility of the confirmation work after the safety measures are implemented. This allows on-site confirmation work to be carried out based on the evaluation of what would happen if the safety measures were implemented.
  • the confirmation work evaluation unit reduces the safety risk by performing at least one of the following: rearranging the execution order of the multiple confirmation works, moving the equipment operated in the confirmation work, and stopping the operation of equipment with a high safety risk or the control system including that equipment. This makes it possible to reduce safety risks based on these measures.
  • the system has a screen display unit 209 that displays the confirmation work list including the priority order evaluated by the confirmation work evaluation unit on the screen, so that the on-site maintenance personnel can easily understand the confirmation work to be performed and the order in which to perform them.
  • the monitoring input unit imports data obtained in the confirmation work performed by the on-site maintenance personnel as confirmation data
  • the fault analysis support system further uses the imported confirmation data to carry out the processes of the cause estimation unit, safety analysis unit, confirmation work derivation unit, and confirmation work evaluation unit, thereby investigating the true cause of the estimated cause. This makes it possible to investigate the true cause while analyzing the estimated cause, or to conduct an investigation to investigate the true cause.
  • the present invention is not limited to the above-described embodiment and includes various modifications.
  • the above-mentioned embodiments have been described in detail to clearly explain the present invention, and are not necessarily limited to those including all of the configurations described.
  • the impact of safety risks assessed by the safety analysis unit may not be limited to the work area, but may be assessed for each piece of equipment used in the work and for each type of work.

Landscapes

  • Testing And Monitoring For Control Systems (AREA)

Abstract

一つまたは複数の機器からなる制御システムの障害分析を支援する障害分析支援システムであって、機器の動作状態に関する機器監視データを収集し機器監視ログデータベースに蓄積する監視入力部と、機器監視データを監視して制御システムの異常を検知する異常検知部と、制御システムの異常と当該異常から推定される原因とを対応付けて記憶する異常原因データベースと、検知された制御システムの異常とに基づいて、原因を推定する原因推定部と、制御システムの異常と、推定された原因を共通の原因とする共通原因事象と、制御システムの稼働状態と、機器の異常に伴って生じる作業エリアにおける安全性への影響を示す安全性影響とを対応付けて記憶するシステム異常動作データベースを用いて、推定された原因を確認するための作業の安全性への影響を分析する安全分析部と、推定された原因と共通原因事象とを用いて、推定された原因が真因であるかを調べるための作業をリスト化した確認作業と、当該確認作業を行う作業エリアとを対応付けて記憶する確認作業データベースから、当該推定された原因および共通原因事象に対応する確認作業を検索し、当該検索の結果を確認作業リストとして導出する確認作業導出部と、安全性への影響の分析結果と、確認作業リストに含まれる確認作業とに基づき、確認作業の安全性を評価し、当該評価の結果を反映した確認作業リストを出力する確認作業評価部と、を有する。

Description

障害分析支援システム及び障害分析支援方法
　本発明は、制御システムの障害分析支援システム及び障害分析支援方法に関する。
　制御システムで発生するインシデントへの対応を効率化するための監視装置に関する技術が盛んに開発されている。制御システムを利用する現場保守員だけでは分析に時間がかかるため、監視装置がシステムを監視し、対処方法などを現場保守員に指示することで効率化を図っている。
　下記特許文献１は、制御システムから異常データを受け取ったシステム監視装置が対処方法を分析し、現場保守員に対処方法を指示する技術を開示している。また、下記特許文献２は、監視システムが制御システムからデータを収集して、インシデントの原因がサイバー攻撃か否かを分析する技術を開示している。
特開２０１８－１８５７１２号公報 特開２０２１－１１１００３号公報
　物流倉庫内の各機器を制御する制御システムと各種機器の動作データを計測し制御システム全体または各機器の稼働状態を監視する障害分析支援システムとで構成される物流倉庫システムがある。
　制御システムで異常が発生したときに、障害分析支援システムにアップロードされた計測データでは、制御システムの状況を分析するには不十分な場合がある。また、異常が発生した倉庫現場で現場保守員が原因を分析するために、各種機器の動作ログや外観などのデータを取得するといった確認作業が発生するケースがある。
　制御システムの異常の原因には、経年劣化等による設備の機器の故障に限らず、サイバー攻撃やマルウェア感染などのセキュリティに係る原因もある。このようなセキュリティを原因とする場合、複数の機器で同時に異常が起こることもあり、現場の確認作業に安全性上のリスクが高まることがある。また、原因分析の確認作業において、様々なデータの取得や機器の操作を行うが、作業の実行順によっては有効なデータが取得できないこともあり、原因分析の効率が低下する課題がある。
　本発明は、制御システムの異常を検知したときに、現場保守員が現場確認作業を安全でかつ効率的に実施できる技術を提供することを目的とする。
　本発明に係る障害分析支援システムは、一つまたは複数の機器からなる制御システムの障害分析を支援する障害分析支援システムであって、前記機器の動作状態に関する機器監視データを収集し機器監視ログデータベースに蓄積する監視入力部と、前記機器監視データを監視して前記制御システムの異常を検知する異常検知部と、前記制御システムの異常と当該異常から推定される原因とを対応付けて記憶する異常原因データベースと、検知された前記制御システムの異常とに基づいて、原因を推定する原因推定部と、前記制御システムの異常と、推定された前記原因を共通の原因とする共通原因事象と、前記制御システムの稼働状態と、前記機器の異常に伴って生じる作業エリアにおける安全性への影響を示す安全性影響とを対応付けて記憶するシステム異常動作データベースを用いて、推定された前記原因を確認するための作業の安全性への影響を分析する安全分析部と、前記推定された原因と前記共通原因事象とを用いて、前記推定された原因が真因であるかを調べるための作業をリスト化した確認作業と、当該確認作業を行う前記作業エリアとを対応付けて記憶する確認作業データベースから、当該推定された原因および前記共通原因事象に対応する確認作業を検索し、当該検索の結果を確認作業リストとして導出する確認作業導出部と、前記安全性への影響の分析結果と、前記確認作業リストに含まれる前記確認作業とに基づき、前記確認作業の安全性を評価し、当該評価の結果を反映した前記確認作業リストを出力する確認作業評価部と、を有することを特徴とする障害分析支援システムとして構成される。
　本発明によれば、制御システムの異常を検知したときに、現場保守員が現場確認作業を安全でかつ効率的に実施できる。
本発明の一つの実施形態である障害分析支援システムが物流倉庫の設備の機器、または、現場保守員の情報端末機器と通信ネットワークを介してつながっている様子を示す図である。 実施形態に係る障害分析支援システムの構成図である。 機器監視ログデータベースの一例を示す図である。 異常原因データベースの一例を示す図である。 システム異常動作データベースの一例を示す図である。 確認作業データベースの一例を示す図である。 安全対策データベースの一例を示す図である。 障害分析支援システムが制御システムの異常を検知してから物流倉庫内の作業エリアに対する安全性の評価を行うまでの処理の流れを説明するフローチャートである。 障害分析支援システムが原因究明に必要な確認作業内容の導出から実行順序を定めるまでの処理の流れを説明するフローチャートである。 障害分析支援システムが作成した確認作業リストを現場保守員が見る画面表示部に表示してから、確認作業の結果を受けて、原因が究明できるまで、原因分析と確認作業リストの再作成を行うまでのフローチャートを示した図である。 画面表示部における確認作業リストの表示例を示す図である。 障害分析支援システムのハードウェア構成の例を示す図である。 現場確認作業リストの一例を示す図である。 現場確認作業リストの一例を示す図である（ステップＳＴ５０２とステップＳＴ５０３の実施後）。 現場確認作業リストの一例を示す図である（ステップＳＴ５０５とステップＳＴ５０６の実施後）。
　以下、図面を参照して本発明の実施形態を説明する。実施例は、本発明を説明するための例示であって、説明の明確化のため、適宜、省略および簡略化がなされている。本発明は、他の種々の形態でも実施することが可能である。特に限定しない限り、各構成要素は単数でも複数でも構わない。図面において示す各構成要素の位置、大きさ、形状、範囲などは、発明の理解を容易にするため、実際の位置、大きさ、形状、範囲などを表していない場合がある。このため、本発明は、必ずしも、図面に開示された位置、大きさ、形状、範囲などに限定されない。
　各種情報の例として、「テーブル」、「リスト」、「キュー」等の表現にて説明することがあるが、各種情報はこれら以外のデータ構造で表現されてもよい。例えば、「ＸＸテーブル」、「ＸＸリスト」、「ＸＸキュー」等の各種情報は、「ＸＸ情報」としてもよい。識別情報について説明する際に、「識別情報」、「識別子」、「名」、「ＩＤ」、「番号」等の表現を用いるが、これらについてはお互いに置換が可能である。
　同一あるいは同様の機能を有する構成要素が複数ある場合には、同一の符号に異なる添字を付して説明する場合がある。また、これらの複数の構成要素を区別する必要がない場合には、添字を省略して説明する場合がある。
　実施例において、プログラムを実行して行う処理について説明する場合がある。ここで、計算機は、プロセッサ（例えばＣＰＵ、ＧＰＵ）によりプログラムを実行し、記憶資源（例えばメモリ）やインターフェースデバイス（例えば通信ポート）等を用いながら、プログラムで定められた処理を行う。そのため、プログラムを実行して行う処理の主体を、プロセッサとしてもよい。同様に、プログラムを実行して行う処理の主体が、プロセッサを有するコントローラ、装置、システム、計算機、ノードであってもよい。プログラムを実行して行う処理の主体は、演算部であれば良く、特定の処理を行う専用回路を含んでいてもよい。ここで、専用回路とは、例えばＦＰＧＡ（Field Programmable Gate Array）やＡＳＩＣ（Application Specific Integrated Circuit）、ＣＰＬＤ（Complex Programmable Logic Device）等である。
　プログラムは、プログラムソースから計算機にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な記憶メディアであってもよい。プログラムソースがプログラム配布サーバの場合、プログラム配布サーバはプロセッサと配布対象のプログラムを記憶する記憶資源を含み、プログラム配布サーバのプロセッサが配布対象のプログラムを他の計算機に配布してもよい。また、実施例において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。
　＜図１：物流倉庫システムの概要図＞
　図１は、本発明の一つの実施形態である障害分析支援システム２０が物流倉庫の設備の機器、または、現場保守員１０の情報端末機器８０と通信ネットワーク７０を介して通信を行っている様子を示す図である。
　通信ネットワーク７０は、例えば、ＥｔｈｅｒＣＡＴやＭｏｄｂｕｓのような通信プロトコルを使用したデータ通信経路である。また、物流倉庫には自動搬送装置３０や自動搬送装置４０、ロボットアーム５０、コンベア機器６０などの荷物の搬送、積み下ろし、加工などを行う機器が備わっている。
　障害分析支援システム２０は、物流倉庫システム１０００における荷物の入出庫を管理するＷＭＳ（Ｗａｒｅｈｏｕｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）や設備の制御や機器間の通信を担うＷＥＳ（Ｗａｒｅｈｏｕｓｅ　Ｅｘｅｃｕｔｉｏｎ　Ｓｙｓｔｅｍ）に備わる一つのサブシステムの位置づけである。
　ＷＥＳのように、障害分析支援システム２０は、制御システム２００の稼働状態を監視し、障害発生時には原因を究明するための分析及び現場保守員１０への情報提供を行う。
　＜課題説明＞
　制御システム２００で異常が発生した場合、障害分析支援システム２０にアップロードされた計測データが限定的であることから、異常が発生した場所で現場保守員１０が原因を分析するために各種機器の動作ログや外観などのデータを取得するといった確認作業が発生するケースがある。
　制御システム２００の異常の原因には、経年劣化等による設備の機器の故障に限らず、サイバー攻撃やマルウェア感染などのセキュリティに係る原因もある。
　このようなセキュリティを原因とする場合、複数の機器で同時に異常が起こることもあり、現場の確認作業に安全性上のリスクが高まることがある。
　また、原因分析の確認作業において、様々なデータの取得や機器の操作を行うが、作業の実行順序によっては有効なデータが取得できないこともあり、原因分析の効率が低下するという課題がある。
　＜解決策＞
　そこで、本発明の実施形態における障害分析支援システム２０は、制御システム２００の異常を検知したときに原因究明に必要な作業を導出し、各作業の安全性と作業間の依存関係の分析結果から、現場保守員による安全で効率的な原因分析を可能とする。さらに、作業の優先順位を算出し、現場保守員１０に通知することで、システム障害分析を支援する。　リモート環境で障害要因の分析を行うために、現場保守員１０が安全性とセキュリティのリスクを低減しつつ、現場で効率的に原因究明に必要な作業をできるようにする。
　＜図２：障害分析システム構成図＞
　図２は、本実施形態に係る障害分析支援システム２０の構成図である。
  本実施形態に係る障害分析支援システム２０は、監視入力部２０２、異常検知部２０３、原因推定部２０４、安全分析部２０５、確認作業導出部２０６、確認作業評価部２０７、監視出力部２０８、機器監視ログデータベース２１０、異常原因データベース２１１、システム異常動作データベース２１２、確認作業データベース２１３、安全対策データベース２１４を有する。画面表示部７０１は、情報端末機器８０のディスプレイ等の表示装置である。
　異常検知部２０３は、制御システム２００を構成する各制御装置２０１の動作ログや制御システム２００が稼働しているか否かを示すシステム稼働状態などを含む機器監視データと、現場保守員１０が確認作業で取得する現場確認データとを監視して、制御システム２００の異常(観測事象と称す)を検知する。
　原因推定部２０４は、異常検知部２０３で検知した異常を基に原因を推定し(推定した原因を推定原因と称す)、推定原因を共通の原因として発生する事象(共通原因事象と称す)の導出を行う。
　安全分析部２０５は、観測事象、推定原因、共通原因事象による安全性への影響を分析する。
　確認作業導出部２０６は、事象の発生状況を調査するために必要な現場保守員１０の確認作業を導出して、確認作業リストを作成する。
　確認作業評価部２０７は、前記安全性への影響分析結果と各確認作業内容とに基づき、各確認作業内容の安全性を評価し、確認作業安全評価結果を出力する。また、確認作業評価部２０７は、確認作業の実行可能性評価結果を出力する。さらに、確認作業評価部２０７は、対策後の確認作業安全評価結果と対策後の確認作業の実行可能性評価結果を出力する。
　＜図３：データベース構成＞
　図３Ａ～３Ｅは、本実施形態に係る障害分析支援システム２０がシステム障害の分析に用いる各データベースの例を示した図である。図２の障害分析支援システム２０の構成で示した各データベース（機器監視ログデータベース２１０、異常原因データベース２１１、システム異常動作データベース２１２、確認作業データベース２１３、安全対策データベース２１４）のデータ項目とデータの内容を示している。
　図３Ａは、機器監視ログデータベース２１０の一例を示す図である。機器監視ログデータベース２１０は、障害分析支援システム２０が物流倉庫現場のデータを蓄える。機器監視ログデータベース２１０は、制御システム２００を構成する各制御装置２０１の動作ログや制御システム２００が稼働しているか否かを示すシステム稼働状態などを含む機器監視データと、現場保守員１０が確認作業で取得する現場確認データを格納する。例えば、採取対象日、対象機器、機器からの送信か現場保守員１０が採取したデータかを識別するための送信元などの情報で構成する。実際には、これらの情報に加え、上述した機器監視データや現場確認データの実体が、これらの情報に対応付けて記憶されている。
　図３Ａでは、例えば、データが取得されたタイミングを示す採取年月日「ＹＹＹＹ年ＭＭ月ＤＤ日」、データの取得対象を示す対象機器「機器Ａ」、データの取得対象の位置を示す送信元「機器Ａ」が対応付けて記憶され、さらに監視時に取得されたデータの実体がこれらの情報に対応付けられたデータが、機器監視データとして蓄積されている。現場確認データについても機器監視データと同様、これらの各項目に対応付けて、現場確認時に取得されたデータの実体が蓄積されている。
　図３Ｂは、異常原因データベース２１１の一例を示す図である。異常原因データベース２１１は、検知された制御システム２００の異常から原因推定部２０４が原因を推定するために用いられる。異常原因データベース２１１は、観測事象とその観測事象から推定される原因(推定原因)の情報が含まれている。
　図３Ｂでは、例えば、機器の観測事象として「機器Ａの応答無し」が記憶され、当該観測事象の推定原因として、「サイバーセキュリティ攻撃」、「機器Ａ故障」が対応付けて記憶されている。
　図３Ｃは、システム異常動作データベース２１２の一例を示す図である。システム異常動作データベース２１２は、安全分析部２０５が更に同様の原因によって発生しうる事象を調べるために用いる。システム異常動作データベース２１２は、上述した観測事象および共通原因事象、制御システム２００が稼働しているか否かを示すシステム稼働状態の各情報、制御システム２００の異常に伴って生じる物流倉庫内の作業エリアに対する安全性への影響を示す安全性影響などの情報が含まれる。
　図３Ｃでは、例えば、観測事象として「機器Ａの応答無し」が観測され、システム稼働状態が「全て稼働」である場合、「機器Ａの応答無し」という観測事象に対して因果関係がある事象、すなわち起こり得る挙動として、「機器Ａの異常動作」、「機器Ｂの異常動作」、「機器Ｃの異常動作」があることを示している。また、これらの挙動のうち、「機器Ａの異常動作」、「機器Ｂの異常動作」が起こった場合には、安全性への影響はない一方、「機器Ｃの異常動作」が起こった場合には、作業エリア１における安全性リスクの高まり（例えば、制御システム２００配下の機器Ｃの衝突による作業エリア１における作業の危険が一定以上高くなること）が懸念されることを示している。
　図３Ｄは、確認作業データベース２１３の一例を示す図である。確認作業データベース２１３は、確認作業導出部２０６が、システム異常の真因を分析するための現場確認作業を導出するために用いる。確認作業データベース２１３は、上述した推定原因および共通原因事象、推定原因が真因であるかを調べるための作業をリスト化した確認作業、当該確認作業を行う作業エリア、当該確認作業における作業手順、当該確認作業で使用する機材、当該確認作業で採取するデータ、当該確認作業と他の確認作業との依存関係などの情報が含まれている。
　図３Ｄでは、例えば、推定原因として「サイバーセキュリティ攻撃」が推定され、共通原因事象として「機器Ａの異常動作」が導出された場合、その推定原因が真因であることを調べるために、作業エリア１において確認作業として機器Ａの動作ログが採取されることを示している。また、当該確認作業は、ＵＳＢメモリと機器Ａの操作端末となる情報端末機器８０を用いて、まず、ＵＳＢメモリを機器Ａに接続し、ＹＹＹＹ年ＭＭ月ＤＤ日の機器Ａの動作ログを保存する手順で行われるものであることを示している。さらに、当該確認作業は、当該確認作業以外の他の確認作業との依存関係として、機器Ａの再起動よりも前に実施するという制約があることを示している。
　図３Ｅは、安全対策データベース２１４の一例を示す図である。安全対策データベース２１４は、確認作業評価部２０７が、安全性リスクの高い確認作業についてリスクを軽減するための対策方法を調査するために用いる。安全対策データベース２１４は、上述した確認作業と、当該確認作業の安全性リスクを軽減するための対策と期待される効果の情報が含まれている。安全対策の例としては、確認作業リストに記憶される複数からなる確認作業の実行順序の入替え、確認作業で操作する機器（例えば、機器Ａ，機器Ｃ）の移動、安全性影響分析結果に基づき安全性リスクの高い機器またはその機器または当該機器を含めた制御システム２００の稼働停止などがある。また、これらの対策による効果として、安全性リスク「高」だったものが「低」になるなどのリスクの変化の情報がある。確認作業評価部２０７が、これらの少なくとも１つを行うことにより、安全性リスクを低減する。
　図３Ｅでは、例えば、機器Ａの動作ログを採取する確認作業に対する安全対策として、機器Ｃの異常動作を停止し、作業エリア１の安全性リスクを低減させる対策が必要であることを示している。
　機器監視ログデータベース２１０は、制御システム２００から採取したデータを蓄積して構成される。その他の図３Ａ～３Ｅに示した各データベース（２１０～２１４）は、予め観測される事象と推定される原因、共通の原因で起こりうる事象や安全性への影響など、予め制御システム２００と物流倉庫現場の構成の安全性について分析した結果をもとに、データベースの各データを用意しておく。
　＜図４：安全性リスク評価フローチャート＞
　図４は、障害分析支援システム２０が制御システム２００の異常を検知して、原因を推定し、その原因によって起こりうる事象とその事象による物流倉庫内の作業エリアに対する安全性の評価までの処理の流れを説明するフローチャートである。以下、図４の各ステップについて説明する。
　（図４：ステップＳＴ４０１）制御システムの異常検知
　異常検知部２０３は、監視入力部２０２が受け取った、制御システム２００を構成する各制御装置２０１の動作ログや制御システム２００が稼働しているか否かを示すシステム稼働状態などを含む機器監視データを監視して、制御システム２００の異常を検知する。
　（図４：ステップＳＴ４０２）原因推定
　原因推定部２０４は、異常検知部２０３が検知した異常を基に、考えられる原因を推定する。推定した原因(推定原因)を出力する。以下、具体的に説明する。
　原因推定部２０４は、異常検知部２０３から観測事象やシステム稼働状態を含む機器監視データを受け取ると、異常原因データベース２１１から、システム稼働状態と観測事象を条件として、推定される異常の原因を検索する。原因推定部２０４は、検索条件に該当した原因を、観測事象を起こした要因として考えられる推定原因とする。原因推定部２０４は、例えば、図３Ａに示した機器監視ログデータベース２１０に含まれる機器監視データを読み出し、制御システム２００が正常な稼働状態である一方、機器Ａが応答無しであった場合、図３Ｂに示した異常原因データベース２１１を参照し、「サイバーセキュリティ攻撃」、「機器Ａ故障」を、当該観測事象の推定原因として出力する。
　（図４：ステップＳＴ４０３）共通原因事象の洗い出し
　原因推定部２０４は、推定原因で発生する可能性がある観測事象以外の事象(共通原因事象と称す)を導出する。以下、具体的に説明する。
　原因推定部２０４は、ステップＳＴ４０２で推定した推定原因とシステム稼働状態とを条件として、異常原因データベース２１１の中から、観測事象以外の事象を検索する。原因推定部２０４は、検索条件に該当した原因を、観測事象を起こした要因として考えられる推定原因とする。
　例えば、原因推定部２０４は、機器の稼働状態が監視できない（機器Ａの応答無し）という制御システム２００の機器と障害分析支援システム２０間の通信異常を観測事象として検知した場合を考える。この場合、推定原因としては経年劣化等による設備の機器の故障だけでなく、サイバー攻撃やマルウェア感染などのセキュリティに係る原因も考えられる。観測事象としては、機器との通信異常ではあるが、共通原因事象としては、設備の機器の故障による動作異常や、セキュリティ要因による意図しない動作が導出されることになる。図３Ｂでは、一例として、ＳＴ４０２で「サイバーセキュリティ攻撃」、「機器Ａ故障」が観測対象とした機器Ａの推定原因とされた場合、対象とした機器以外の機器となる機器Ｂについて、機器Ａと同様の「サイバーセキュリティ攻撃」が機器Ｂの推定原因として記憶されている。そのため、原因推定部２０４は、機器Ａおよび機器Ｂの共通原因事象として、「サイバーセキュリティ攻撃」を導出する。原因推定部２０４は、観測事象（機器Ａの応答無し）、共通原因事象（サイバーセキュリティ攻撃）、システムの稼働状態（制御システム２００が全て正常状態）を出力する。異常原因データベース２１１に機器Ｃについても同様に記憶されている場合には、機器Ａ～機器Ｃの共通原因事象として、「サイバーセキュリティ攻撃」を出力し、システムの稼働状態（制御システム２００が全て正常状態）を出力する。
　（図４：ステップＳＴ４０４）安全性への影響分析
　安全分析部２０５は、ＳＴ４０２で推定された推定原因と、ＳＴ４０３で導出された共通原因事象とによる安全性への影響を分析する。以下、具体的に説明する。
　安全分析部２０５は、原因推定部２０４から、観測事象、共通原因事象、システム稼働状態の各情報を受け取り、これらの情報を用いて、システム異常動作データベース２１２から物流倉庫内の作業エリアに対する安全性への影響を検索する。安全分析部２０５は、上記各情報の内容に該当する検索結果を用いて、各作業エリアの安全性を評価する。
　安全性への影響としては、例えば、物流倉庫内の特定エリアの危険度の変化やその有無などが挙げられる。具体的には、作業エリア１を移動する搬送機器が、観測事象や共通原因事象により意図しない動作をし、作業エリア１の装置や作業者などに衝突したり、危害を加えるなどする可能性がある場合がある。このような場合を考慮して、システム異常動作データベース２１２には、「作業エリア１の安全性リスクの高まり」（つまり安全性が低くなる影響がある）として、作業エリアの安全性が評価されている。したがって、安全分析部２０５は、観測事象（機器Ａの応答無し）、共通原因事象（この例では機器Ｃの異常動作）、システムの稼働状態（制御システム２００が全て正常状態）の場合、これらの情報に対応する「作業エリア１の安全性リスクの高まり」という安全性影響を出力する。ここでは例示していないが、共通原因事象が「サイバーセキュリティ攻撃」である場合も同様にシステム異常動作データベース２１２に定義されている。
　以上の処理の流れにより、障害分析支援システム２０は、物流倉庫内の制御システム２００の異常を検知した後、障害分析支援システム２０では、異常の原因推定と、共通原因により発生する事象を分析し、観測事象として検知された異常と、共通原因事象とによって変化する物流倉庫内の作業エリアの安全性評価を行う。
　＜図５：確認作業の導出から確認作業の実行順序決定までのフローチャート＞
　図５は、障害分析支援システム２０が、原因究明に必要な確認作業内容の導出から実行順序を定めるまでの処理の流れを説明するフローチャートである。
　（図５：ステップＳＴ５０１）原因究明に必要な確認作業の導出
　確認作業導出部２０６は、推定原因が真因かを究明するために必要となる現場保守員１０の確認作業を導出する。
　確認作業導出部２０６は、確認作業データベース２１３を参照し、ステップＳＴ４０１からステップＳＴ４０４までの各処理で出力された推定原因、観測事象、共通原因事象の発生状況やその発生過程を調べるための確認作業リストを出力する。現場保守員１０は、確認作業導出部２０６が出力した確認作業リストに基づいて、機器のログ、機器間の通信ログ、外観の状態、診断試験などの実施やデータの採取などの確認作業を行う。
　例えば、観測事象が通信異常である場合、確認作業導出部２０６は、機器間の通信ログを採取する、または、通信インタフェースの故障を診断する、通信不可となった機器の動作ログを採取する、といった確認作業を確認作業リストとして導出する。
　推定原因、観測事象、共通原因事象とそれらに必要な確認作業の情報は、確認作業データベース２１３に含まれている。確認作業導出部２０６は、入力した推定原因、観測事象、共通原因事象の情報を用いて、確認作業データベース２１３から、当該推定原因および共通原因事象に対応付けて記憶されている確認作業を検索する。該当した検索結果をリスト化し、確認作業リストとして出力する。
　例えば、確認作業導出部２０６は、確認作業データベース２１３から、推定原因として記憶されている（１）サイバーセキュリティ攻撃、及び（２）機器Ａ故障、の真因を究明するための確認作業リストを検索する。当該検索では、レコード３０１が検索される。検索結果の例を、図９の現場確認作業リスト９０１に示す。
　図９は、現場確認作業リスト９０１の一例を示す図である。図９に示すように、現場確認作業リスト９０１は、確認作業を行う順序を示す順番、当該確認作業の実施状態を示す状態、上述した確認作業データベース２１３と同様の各項目のほか、確認作業を行う際の安全性リスク、安全性リスクに照らして当該確認作業を行うことの可否を示す実行可能性の各項目が対応付けられている。上述した順番、状態、安全性リスク、実行可能性の各項目は、以降の処理で記録される。上記検索して得られるリストは、現場確認作業リスト９０１のレコード９０１１に該当する。図９では、図４のステップＳＴ４０１からステップＳＴ４０４までの各処理で出力された推定原因、観測事象、共通原因事象の全てについて、上記リストが出力されている（計４レコード）。
　（図５：ステップＳＴ５０２）確認作業の安全性評価
　確認作業評価部２０７は、ステップＳＴ５０１で導出した確認作業リストに含まれる各確認作業の安全性を評価する。
　確認作業評価部２０７は、確認作業リストに含まれる各確認作業の作業エリアを確認作業データベース２１３で検索する。本検索により該当した作業エリアと、ステップＳＴ４０４で評価した各作業エリアの安全性評価結果を照らし合わせ、各確認作業の安全性を評価し、確認作業安全評価結果として出力する。
　例えば、確認作業評価部２０７は、図９に示した現場確認作業リスト９０１の確認作業「機器Ａ動作ログ採取」と、図３Ｄに示した確認作業データベース２１３のなかで当該確認作業に対応する作業エリア「作業エリア１」を特定する。確認作業評価部２０７は、当該確認作業「機器Ａ動作ログ採取」と、ＳＴ４０４で出力された安全性影響「作業エリア１の安全性リスクの高まり」とを突き合わせ、当該確認作業を作業エリア１で行う場合には、安全性リスクが高まる影響があると評価する。ここでは確認作業「機器Ａ動作ログ採取」について説明したが、他の確認作業の場合も同様である。すなわち、図９に示した現場確認作業リスト９０１の確認作業が「機器Ｃ動作ログ採取」であり、ＳＴ４０４で安全性影響「作業エリア１の安全性リスクの高まり」が出力されている場合には、確認作業「機器Ａ動作ログ採取」の場合と同様、当該確認作業を作業エリア１で行う場合には、安全性リスクが高まる影響があると評価する。
　確認作業評価部２０７は、予め安全性の基準を設定し、上記安全性リスクの評価を行う。例えば、安全性リスクの高さを判断基準として「高、中、低」という三段階のレベルを設定し、人に危害を加えるレベルを「高」、ものにぶつかるが壊さないレベルを「中」、外部に影響がないレベルを「低」とする。確認作業評価部２０７は、作業エリア１の安全性として要求されているレベルが、人に危害を加える程度の所定の安全性リスクの高さのレベルである場合、確認作業の安全性リスクについて「作業エリア１における確認作業は安全性リスクが高い」と評価する。
　（図５：ステップＳＴ５０３）対策前の確認作業の実行可能性を評価
　確認作業評価部２０７は、ステップＳＴ５０２の処理結果である確認作業安全評価結果を用いて各確認作業の実行可能性を評価する。
　確認作業評価部２０７は、予め確認作業の実行可否を判断するための基準を設けておき、上記実行可能性の評価を行う。例えば、ステップＳＴ５０２で説明した安全性リスクが「高、中、低」という三段階のレベルで表される場合、安全性リスク「中」または「低」の場合は、当該確認作業を「実行可能」と評価し、それ以外は「実行不可」と評価する。
  実行可能性の評価結果は、確認作業の実行可能性評価結果として出力する。
　ステップＳＴ５０２とステップＳＴ５０３を実施した際に作成する現場確認作業リストの例を図１０に示す。図１０では、ステップＳＴ５０２、ＳＴ５０３の処理が行われることにより、安全性リスク、実行可能性の各項目が評価され、その評価の結果が書き込まれて反映された確認作業リストが出力されていることがわかる。
　例えば、現場確認作業リスト９０１で洗い出した確認作業のうち、作業エリア１での確認作業は、システム異常動作データベース３０３の共通原因事象と安全性影響のデータをもとに、作業エリア１の安全性リスクが高まっていると判断できる。そのため、確認作業評価部２０７は、安全性リスク「高」の評価をしている。一方、同様の考え方で、確認作業評価部２０７は、その他の作業エリア２で実施する作業は安全性リスクを「低」と評価している。さらに、確認作業評価部２０７は、ステップＳＴ５０３の基準を参照して、安全性リスク「高」の作業は、実行可能性を「実行不可」と評価し、安全対策を行わない現場確認作業リスト１００１を作成する。
　（図５：ステップＳＴ５０４）安全対策の設定と再評価
　確認作業評価部２０７は、ステップＳＴ５０３の処理結果である確認作業の実行可能性評価結果において「実行不可」となった確認作業の安全対策を設定し、安全性リスクと実行可能性の再評価を行う。
　確認作業評価部２０７は、ステップＳＴ５０２で「出力した確認作業安全評価結果と、ステップＳＴ５０３で出力した確認作業の実行可能性評価結果をもとに、安全性リスクが高く、実行不可と評価した確認作業に対し、安全対策を安全対策データベース２１４から検索し、効果的な対策を選定する。そして、確認作業評価部２０７は、その対策による安全性リスクを再評価し、対策後の確認作業安全評価結果として出力する。さらに、再評価した安全性リスクを前提に実行可能化を再評価し、対策後の確認作業の実行可能性評価結果として出力する。
　例えば、確認作業評価部２０７は、作業エリア１における確認作業「機器Ａ動作ログ採取」は、安全性リスク「高」、かつ実行可能性「実行不可」と評価している。そのため、図３Ｅに示した安全対策データベース２１４を参照し、確認作業「機器Ａ動作ログ採取」に対応する安全対策「機器Ｃの異常動作停止し、作業エリア１の安全性リスクを低減」を選定する。
　現場保守員１０が上記安全対策を確認し、「機器Ｃの異常動作停止」を行うと、確認作業評価部２０７は、再びステップＳＴ５０２、ＳＴ５０３を行う。このとき、ＳＴ５０２では、再び、ステップＳＴ４０４で評価した各作業エリアの安全性評価結果が参照される。当該参照にあたり、確認作業評価部２０７は、安全分析部２０５に対して、ステップＳＴ４０４を再実行するよう要求する。安全分析部２０５は、当該要求に従って、現時点における安全性への影響分析を行う。この例では、現場保守員１０が上記安全対策を確認し、「機器Ｃの異常動作停止」を行ったため、共通原因事象として「機器Ｃの異常動作」が除去されたことになる。そのため、安全分析部２０５は、安全性影響として「無し」という結果を、確認作業評価部２０７に返す。
　確認作業評価部２０７は、安全分析部２０５から受け取った安全性評価に従って、ステップＳＴ５０２を行い、確認作業「機器Ａ動作ログ採取」を作業エリア１で行う場合には、安全性リスクが一定程度低下し、レベル「低」になったと評価する。さらに、確認作業評価部２０７は、ステップＳＴ５０３を行い、上述した基準に従って、当該確認作業を「実行可能」と評価する。この例では、作業エリア１における確認作業「機器Ａ動作ログ採取」は、安全性リスク「低」、かつ実行可能性「実行可」と再評価している。
　（図５：ステップＳＴ５０５）確認作業間の依存関係を分析
　これまでの処理では、確認作業評価部２０７は、現場確認作業リスト９０１に含まれる確認作業のそれぞれについて、安全性リスク、実行可能性を評価し、さらに再評価した。次の処理では、確認作業評価部２０７は、確認作業リストに含まれる各確認作業間の依存関係を調べる。確認作業評価部２０７は、図３Ｄに示した確認作業データベース２１３を用いて、各確認作業の具体的な作業内容を示す作業手順、他の作業への影響を調べる。
　確認作業の依存関係の観点としては、確認作業の実行順により、他の確認作業の妨げにならないか、あるいは順番を入れ替えると実行可能か、という点が挙げられる。また、確認作業で採取すべきデータが他の確認作業によって変更、削除されないか、という点が挙げられる。具体例としては、「他の確認作業では再起動や試験動作を行う。これらの再起動や試験動作によってメモリ上のデータが変更、または、削除される可能性がある。そのため、これらの再起動や試験動作より前にメモリ上のデータを採取する作業が必要である。」などの依存例がある。
　確認作業評価部２０７は、図３Ｄに示した確認作業データベース２１３に記憶されている項目「他の確認作業との依存関係」を参照し、当該項目の内容を解析したり、各確認作業の項目「作業手順」のすべてを読み取って内容を解析する。確認作業評価部２０７は、これらの解析の結果から、各作業手順の時間的な順序を判断することにより、各確認作業の先行関係を決定する。確認作業評価部２０７は、上記のように依存関係を確認し、依存関係確認結果として出力する。
　（図５：ステップＳＴ５０６）確認作業の実行順序決定
　確認作業評価部２０７は、実行可能性の評価と依存関係の確認を行った各確認作業の実行順序を定める。
  確認作業評価部２０７は、基本的な優先順位の選定基準は、安全性上リスクが低く実行可能で、かつ他の作業との依存関係のない、または依存関係上、先行すべき作業を高く評価し、その作業から選定していく。
　実行順序策定の例としては、次の方法がある。確認作業評価部２０７は、まず、（１）安全対策不要で安全性リスクが低く、実行可能性を「実行可」と評価した確認作業のうち、他の作業との依存関係のない作業を優先的に実行する作業に選定する。次に、確認作業評価部２０７は、（２）安全対策を実施した上で安全性のリスクを低減し、実行可能性を「実行可」と評価した作業のうち、依存関係上優先すべき作業から順に実行する作業に選定する。（２）のように選定された確認作業は、上述したステップＳＴ５０２、ＳＴ５０３で安全性リスク、実行可能性が再評価された確認作業である。
　ステップＳＴ５０５とステップＳＴ５０６を実施した際に作成する現場確認作業リストの例を、図１１に示す。例えば、確認作業評価部２０７は、安全性リスクが高く、実行可能性が実行不可となっていた確認作業を特定する。確認作業評価部２０７は、特定した確認作業について、安全性リスクを高める要因となっていた、作業エリア１の安全性を確保するため、安全対策データベース２１４の安全対策に基づき、機器Ｃの動作を停止する手順を追加する。図１１では、順番「２」のレコードに、「（１）安全対策のため動作停止」が追加されている。この手順を追加することで、作業エリア１の安全性リスクを低下させることができ、全ての作業が実行可能となる。つまり、ステップＳＴ５０４で説明した安全性リスクや実行可能性を再評価する際に、図１１に示したような現場確認作業リスト１１０１を出力し。当該リストを参照して、現場保守員１０が当該確認作業の作業手順（この場合は、機器Ｃについて、確認作業「機器Ｃの故障診断とログ採取」の作業手順「（１）安全対策のため動作停止」）を行う。これにより、作業エリア１で行われる他の確認作業（この例では、順番「３」、「４」の確認作業）の安全性リスクが「低」、実行可能性が「実行可能」となる。
　この例では、作業順番について、確認作業評価部２０７は、実行依存関係のない機器Ｂのログ採取を優先し（順番１）、その後、安全対策手順を含む機器Ｃの故障診断とログ採取を実施する（順番２）。さらに、確認作業評価部２０７は、機器Ａのログ採取においては、機器Ａの再起動前にログを採取する依存性からききＡ動作ログ採取を再起動よりも前に実施する(順番３)。最後に、確認作業評価部２０７は、機器Ａ再起動後、動作ログ採取を実施する（順番４）。
　＜図６：確認作業の画面出力から確認結果による再分析までのフローチャート＞
　図６は、上記のとおり作成された確認作業リストが情報端末機８０の画面表示部７０１に表示され、現場保守員１０による確認作業の結果を受けて、確認作業リストの再作成を行うまでのフローチャートを示した図である。
　（図６：ステップＳＴ６０１）確認作業の画面表示
　監視出力部２０８は、ステップＳＴ５０６の出力である実行順序を含めた確認作業リストを受けて、情報端末機８０の画面表示部７０１に確認作業リストを送る。画面表示部７０１は、現場保守員１０に対し、確認作業リストを表示する。
　＜図７：画面表示部における確認作業リストの表示例＞
　図７は、画面表示部７０１が表示する確認作業リストの例を示す図である。画面表示部７０１が表示する項目は、図９～１１を用いて説明した現場確認作業リストの各項目の一部または全部を含む。
　（図６：ステップＳＴ６０２）確認作業と障害分析支援システムへのアップロード
　現場保守員１０は、画面表示部２０９に表示された確認作業リストを確認し、原因分析に必要な確認作業を把握する。現場保守員１０は、画面表示部７０１に表示された確認作業の順番に沿って、確認作業を実施する。情報端末機８０の画面表示部７０１は、現場保守員１０からの操作を受けて、実施された確認作業に伴って機器やシステムから取得した作業結果のデータ(現場確認データと称す)を、障害分析支援システム２０にアップロードする。例えば、画面表示部７０１は、現場保守員１０からの操作を受けて、機器Ａのログデータを取得する。現場保守員１０は、ＵＳＢメモリなどの記録媒体を機器Ａに接続し、機器Ａと接続された制御装置２０１が、機器Ａのログデータを障害分析支援システム２０の監視入力部２０２に送信するとともに、上記ＵＳＢメモリに記録する。監視入力部２０２は、上記送信されたログデータを、障害分析支援システム２０の機器監視ログデータベース２１０に記録される。
　画面表示部２０９は、上記ログデータが取得され、一つの確認作業が完了すると、確認作業リストの対象作業の状態を「未実施」から「完了」に書き換える。画面表示部２０９は、現場確認作業リストの作業手順に含まれる全ての作業が実行された旨の情報の入力を現場保守員１０から受け付けることにより、当該書き換えを実行できる。なお、上記状態は、データがアップロードされたタイミングで、現場保守員１０が現場確認作業リストを手動で操作し、上記状態を更新しても良い。画面表示部２０９は、上記状態を更新した現場確認作業リストのうち、更新した上記状態が「完了」となった確認作業以外の確認作業により構成された新たな現場確認作業リストを再作成し、画面に表示する。これにより、完了した確認作業を除く、未完了の確認作業のみを含む新たな現場確認作業リストを現場保守員１０に提示できる。
　（図６：ステップＳＴ６０３）確認データによる原因分析と確認作業の再分析
　障害分析支援システム２０は、上記送信されたログデータを用いて、原因分析を行う。障害分析支援システム２０は、共通原因事象の発生状況などを確認し、推定原因の正確性を確認する。共通原因事象の発生状況の有無によって、考えられる推定原因を絞込み、確認作業内容を限定する。すなわち、障害分析支援システム２０は、上記送信されたログデータを新たに機器監視ログデータベース２１０に蓄積することにより、完了した確認作業の結果得られたログを踏まえて、制御システムの異常検知、原因推定、真因の究明といった、図４以降の各処理を実行できる。上記ログには、制御装置２０１の動作ログや制御システム２００のシステム稼働状態などを含む機器監視データや、現場保守員１０が確認作業で取得した現場確認データを含む。
　＜図８：障害分析支援システムのハードウェア構成例＞
　図８は、障害分析支援システム２０のハードウェア構成の例を示す。障害分析支援システム２０の基本構成は、プログラム等を実行するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）８０１、各機能を実現するプログラム、テーブル、プログラムのデータなどを記録するＲＯＭ(Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ)８０２、ファイル等の情報を保存する揮発性のＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）８０３、また、データベースなどを記録するストレージ８０４、人の操作入力等を行うためのインタフェースとなる入力装置８０５、操作画面やデータ等を表示するための表示装置８０６、制御システム２００との通信を行うためのネットワークインタフェース８０７からなる。
　ＣＰＵ８０１が備える各機能部は、その機能を実装した回路デバイスを用いて構成することもできるし、その機能を実装したソフトウェアをＣＰＵ８０１が実行することにより構成することもできる。
　制御装置２０１や情報端末機器８０についても、図８に示したコンピュータにより構成されてよい。
　＜まとめ＞
　ステップＳＴ４０１の制御システムの異常検知からステップＳＴ６０１の確認作業の画面表示までの処理を実行することで、制御システムの異常を検知したときに、現場保守員が現場確認作業を安全でかつ効率的に実施できる。また、ステップＳＴ４０１の制御システムの異常検知からステップＳＴ６０３の再分析までを繰り返し実施することで、安全性を保ちつつ、確認作業の依存関係を考慮した上で、確認作業と原因究明を進めることが可能となる。
　以上説明したように、本実施例に係る障害分析支援システムによれば、制御システムの異常を検知したときに、原因究明に必要な現場確認作業を導出し、確認作業を安全でかつ効率的に実施するための安全対策と作業の優先順位を現場保守員に通知することで、現場保守員が現場確認作業を安全でかつ効率的に実施できるようになる。
　例えば、図５のステップＳＴ５０１－ＳＴ５０３等を用いて説明したように、一つまたは複数の機器からなる制御システム２００の障害分析を支援する障害分析支援システム２０において、上記機器の動作状態に関する機器監視データを収集し機器監視ログデータベース２１０に蓄積する監視入力部２０２と、上記機器監視データを監視して上記制御システムの異常を検知する異常検知部２０３と、上記制御システムの異常と当該異常から推定される原因とを対応付けて記憶する異常原因データベース２１１と、検知された上記制御システムの異常とに基づいて、原因を推定する原因推定部２０４と、上記制御システムの異常と、推定された上記原因を共通の原因とする共通原因事象と、上記制御システムの稼働状態と、上記機器の異常に伴って生じる作業エリアにおける安全性への影響を示す安全性影響とを対応付けて記憶するシステム異常動作データベース２１２を用いて、推定された上記原因を確認するための作業の安全性への影響を分析する安全分析部２０５と、上記推定された原因と上記共通原因事象とを用いて、上記推定された原因が真因であるかを調べるための作業をリスト化した確認作業と、当該確認作業を行う上記作業エリアとを対応付けて記憶する確認作業データベース２１３から、当該推定された原因および上記共通原因事象に対応する確認作業を検索し、当該検索の結果を確認作業リストとして導出する確認作業導出部２０６と、上記安全性への影響の分析結果と、上記確認作業リストに含まれる上記確認作業とに基づき、上記確認作業の安全性を評価し、当該評価の結果を反映した上記確認作業リストを出力する確認作業評価部２０７と、を有するので、制御システムの異常を検知したときに、現場保守員が現場確認作業を安全でかつ効率的に実施できるようになる。
　また、図５のステップＳＴ５０６等を用いて説明したように、上記確認作業データベースには、上記確認作業と他の確認作業との依存関係が記憶され、上記確認作業評価部は、上記確認作業リストに含まれる各確認作業間の依存関係を調べ、依存関係上、先行すべき確認作業の優先順位を高く評価する。これにより、現場保守員が作業順序を意識することなく、効率よく現場確認作業を行うことができる。
　また、図５のステップＳＴ５０４等を用いて説明したように、上記確認作業評価部は、上記確認作業と、当該確認作業の安全性リスクを軽減するための安全対策とを対応付けてする安全対策データベース２１４から、安全性リスクの高い確認作業についての上記安全対策を検索し、当該検索の結果に該当する安全対策により、上記安全性リスクの軽減効果を評価し、上記安全対策された後の上記確認作業の実行可能性を再評価する。これにより、安全対策を行った場合の評価に基づいて、現場確認作業を実施できる。
　また、上記確認作業評価部は、上記安全対策として、複数からなる上記確認作業の実行順序の入替え、上記確認作業で操作される機器の移動、安全性リスクの高い機器または当該機器を含めた上記制御システムの稼働停止の少なくとも一つを行うことにより、上記安全性リスクを低減する。これにより、これらの対策に基づいた安全性リスクの低減が可能となる。
　また、図７等を用いて説明したように、上記確認作業評価部で評価した上記優先順位を含む上記確認作業リストを画面に表示する画面表示部２０９、を有するので、現場保守員は、行うべき確認作業やその順序を容易に把握することができる。
　また、図６等を用いて説明したように、上記監視入力部は、現場保守員により行われた上記確認作業で得られたデータを確認データとして取り込み、上記障害分析支援システムは、さらに、上記取り込まれた上記確認データを用いて、上記原因推定部、上記安全分析部、上記確認作業導出部、上記確認作業評価部、の各処理を行うことにより、上記推定された原因の真因を究明する。これにより、推定された原因を分析しながら、その真因を究明したり、当該究明のための調査を行うことができる。
　＜変形例について＞
　本発明は、上記実施形態に限らず様々な変形例が含まれる。
  例えば、上記実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施形態の構成の一部を他の実施形態の構成に置き換えることが可能である。また、ある実施形態の構成に他の実施形態の構成を加えることも可能である。また、各実施形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
　また、安全性分析部による安全性リスクへの影響を作業エリアに限らず、作業に用いる機器や作業内容ごとにリスクを評価しても良い。
１０…現場保守員、２０…障害分析支援システム、３０…自動搬送装置、４０…自動搬送装置、５０…ロボットアーム、６０…コンベア機器、７０…通信ネットワーク、８０…情報端末機器、２００…制御システム、２０１…制御装置、２０２…監視入力部、２０３…異常検知部、２０４…原因推定部、２０５…安全分析部、２０６…確認作業導出部、２０７…確認作業評価部、２０８…監視出力部、２０９…画面表示部、２１０…機器監視ログデータベース、２１１…異常原因データベース、２１２…システム異常動作データベース、２１３…確認作業データベース、２１４…安全対策データベース、８０１…ＣＰＵ、８０２…ＲＯＭ、８０３…ＲＡＭ、８０４…ストレージ、８０５…入力装置、８０６…表示装置、８０７…ネットワークインタフェース

Claims (7)

  1. 　一つまたは複数の機器からなる制御システムの障害分析を支援する障害分析支援システムであって、
    　前記機器の動作状態に関する機器監視データを収集し機器監視ログデータベースに蓄積する監視入力部と、
    　前記機器監視データを監視して前記制御システムの異常を検知する異常検知部と、
    　前記制御システムの異常と当該異常から推定される原因とを対応付けて記憶する異常原因データベースと、検知された前記制御システムの異常とに基づいて、原因を推定する原因推定部と、
    　前記制御システムの異常と、推定された前記原因を共通の原因とする共通原因事象と、前記制御システムの稼働状態と、前記機器の異常に伴って生じる作業エリアにおける安全性への影響を示す安全性影響とを対応付けて記憶するシステム異常動作データベースを用いて、推定された前記原因を確認するための作業の安全性への影響を分析する安全分析部と、
    　前記推定された原因と前記共通原因事象とを用いて、前記推定された原因が真因であるかを調べるための作業をリスト化した確認作業と、当該確認作業を行う前記作業エリアとを対応付けて記憶する確認作業データベースから、当該推定された原因および前記共通原因事象に対応する確認作業を検索し、当該検索の結果を確認作業リストとして導出する確認作業導出部と、
    　前記安全性への影響の分析結果と、前記確認作業リストに含まれる前記確認作業とに基づき、前記確認作業の安全性を評価し、当該評価の結果を反映した前記確認作業リストを出力する確認作業評価部と、
    　を有することを特徴とする障害分析支援システム。
  2. 　前記確認作業データベースには、前記確認作業と他の確認作業との依存関係が記憶され、
    　前記確認作業評価部は、前記確認作業リストに含まれる各確認作業間の依存関係を調べ、依存関係上、先行すべき確認作業の優先順位を高く評価する、
    　ことを特徴とする請求項１に記載の障害分析支援システム。
  3. 　前記確認作業評価部は、前記確認作業と、当該確認作業の安全性リスクを軽減するための安全対策とを対応付けてする安全対策データベースから、安全性リスクの高い確認作業についての前記安全対策を検索し、当該検索の結果に該当する安全対策により、前記安全性リスクの軽減効果を評価し、前記安全対策された後の前記確認作業の実行可能性を再評価する、
    　ことを特徴とする請求項２に記載の障害分析支援システム。
  4. 　前記確認作業評価部は、前記安全対策として、複数からなる前記確認作業の実行順序の入替え、前記確認作業で操作される機器の移動、安全性リスクの高い機器または当該機器を含めた前記制御システムの稼働停止の少なくとも一つを行うことにより、前記安全性リスクを低減する、
    　ことを特徴とする請求項３に記載の障害分析支援システム。
  5. 　前記確認作業評価部で評価した前記優先順位を含む前記確認作業リストを画面に表示する画面表示部、
    　を有することを特徴とする請求項２に記載の障害分析支援システム。
  6. 　前記監視入力部は、現場保守員により行われた前記確認作業で得られたデータを確認データとして取り込み、
    　前記障害分析支援システムは、さらに、前記取り込まれた前記確認データを用いて、前記原因推定部、前記安全分析部、前記確認作業導出部、前記確認作業評価部、の各処理を行うことにより、前記推定された原因の真因を究明する、
    　ことを特徴とする請求項５に記載の障害分析支援システム。
  7. 　コンピュータにより、一つまたは複数の機器からなる制御システムの障害分析を支援する障害分析支援方法であって、
    　前記機器の動作状態に関する機器監視データを収集し機器監視ログデータベースに蓄積し、
    　前記機器監視データを監視して前記制御システムの異常を検知し、
    　前記制御システムの異常と当該異常から推定される原因とを対応付けて記憶する異常原因データベースと、検知された前記制御システムの異常とに基づいて、原因を推定し、
    　前記制御システムの異常と、推定された前記原因を共通の原因とする共通原因事象と、前記制御システムの稼働状態と、前記機器の異常に伴って生じる作業エリアにおける安全性への影響を示す安全性影響とを対応付けて記憶するシステム異常動作データベースを用いて、推定された前記原因を確認するための作業の安全性への影響を分析し、
    　前記推定された原因と前記共通原因事象とを用いて、前記推定された原因が真因であるかを調べるための作業をリスト化した確認作業と、当該確認作業を行う前記作業エリアとを対応付けて記憶する確認作業データベースから、当該推定された原因および前記共通原因事象に対応する確認作業を検索し、当該検索の結果を確認作業リストとして導出し、
    　前記安全性への影響の分析結果と、前記確認作業リストに含まれる前記確認作業とに基づき、前記確認作業の安全性を評価し、当該評価の結果を反映した前記確認作業リストを出力する、
    　ことを特徴とする障害分析支援方法。
PCT/JP2024/015210 2023-04-24 2024-04-17 障害分析支援システム及び障害分析支援方法 WO2024225124A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2023070723A JP2024156343A (ja) 2023-04-24 障害分析支援システム及び障害分析支援方法
JP2023-070723 2023-04-24

Publications (1)

Publication Number Publication Date
WO2024225124A1 true WO2024225124A1 (ja) 2024-10-31

Family

ID=93256512

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2024/015210 WO2024225124A1 (ja) 2023-04-24 2024-04-17 障害分析支援システム及び障害分析支援方法

Country Status (1)

Country Link
WO (1) WO2024225124A1 (ja)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11259119A (ja) * 1998-03-09 1999-09-24 Toshiba Corp 保守作業支援システム
JP2002189513A (ja) * 2000-10-13 2002-07-05 Toyota Motor Corp 設備管理方法及び安否確認方法及び設備管理サーバ
JP2013092954A (ja) * 2011-10-27 2013-05-16 Hitachi Ltd 管理業務支援装置、管理業務支援方法及び管理業務支援システム
JP2020166650A (ja) * 2019-03-29 2020-10-08 株式会社日立製作所 リスク評価対策立案システム及びリスク評価対策立案方法
WO2022102211A1 (ja) * 2020-11-12 2022-05-19 三菱パワー株式会社 異常時対応教示システム、異常要因推定方法、異常時対応教示方法およびプログラム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11259119A (ja) * 1998-03-09 1999-09-24 Toshiba Corp 保守作業支援システム
JP2002189513A (ja) * 2000-10-13 2002-07-05 Toyota Motor Corp 設備管理方法及び安否確認方法及び設備管理サーバ
JP2013092954A (ja) * 2011-10-27 2013-05-16 Hitachi Ltd 管理業務支援装置、管理業務支援方法及び管理業務支援システム
JP2020166650A (ja) * 2019-03-29 2020-10-08 株式会社日立製作所 リスク評価対策立案システム及びリスク評価対策立案方法
WO2022102211A1 (ja) * 2020-11-12 2022-05-19 三菱パワー株式会社 異常時対応教示システム、異常要因推定方法、異常時対応教示方法およびプログラム

Similar Documents

Publication Publication Date Title
JP4859558B2 (ja) コンピュータシステムの制御方法及びコンピュータシステム
US8621637B2 (en) Systems, program product and methods for performing a risk assessment workflow process for plant networks and systems
JP5267736B2 (ja) 障害検出装置、障害検出方法およびプログラム記録媒体
EP2759938A1 (en) Operations management device, operations management method, and program
JP6141471B2 (ja) システムの可用性を解析するための方法、装置、当該装置を含むシステム、並びに、上記方法を実施するためのコンピュータプログラム
JP6095140B2 (ja) 遠隔監視システム、遠隔監視方法、及びプログラム
JP2004258940A (ja) 情報システムのネットワーク監視方法及びオペレーショナルリスク計量方法
KR20090038683A (ko) 자동 취약점 진단 웹 방화벽 및 이를 이용한 취약점 진단방법
JP5007247B2 (ja) ジョブ処理システムおよびジョブ管理方法
US20060230122A1 (en) Method and system for managing programs in data-processing system
JP4842738B2 (ja) 障害管理支援システム及びその情報管理方法
Staron et al. Industrial experiences from evolving measurement systems into self‐healing systems for improved availability
US8099527B2 (en) Operation management apparatus, display method, and record medium
WO2024225124A1 (ja) 障害分析支援システム及び障害分析支援方法
JP2024156343A (ja) 障害分析支援システム及び障害分析支援方法
US11768730B2 (en) Analyzing device, analyzing method, and analyzing program
CN111951944A (zh) 一种辅助管理工程师的方法和平台
CN113419887B (zh) 主机联机事务异常的处理方法及装置
US20220166840A1 (en) Presentation device, presentation method, and presentation program
CN108880920A (zh) 云服务管理方法、装置以及电子设备
CN113900902A (zh) 日志处理方法、装置、电子设备及存储介质
JP2001005795A (ja) 分散システムにおける異常検出方法
KR20180027161A (ko) 장애 복구 최적화를 위한 규칙 기반 워크플로우 관리 시스템 및 방법
Jagannathan et al. REFORM: Increase alerts value using data driven approach
Tarak et al. DIA4M: A Tool to Streamline DevOps Processes of Distributed Cloud-Native Systems