System analysis apparatus, system analysis method, and program
Patent Information
- Application Number
- JP2023140583
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2023-08-30
- Publication Date
- 2025-03-13
AI Technical Summary
【0009】 本発明によれば、複数のコントローラを備えるシステムの高精度な安全性の解析を可能にすることができる。また、システム設計者は、複数のコントローラを備えるシステムのアーキテクチャを設計する際、コントローラの切り替え等の重要なケースに対して、システム安全解析を適用することができ、作業対効果を向上させることができる。
Smart Images

Figure 2025034288000001_ABST
Abstract
Description
[Technical field]
[0001] The present invention relates to a system analysis device, a system analysis method, and a program. [Background technology]
[0002] Conventionally, when designing a system architecture, a safety analysis method based on systems thinking (STAMP / STPA: System Theoretic Accident Model and Processes / System Theoretic Process Analysis) is known, which performs analysis from a safety perspective. STAMP / STPA is a method that focuses on the interactions between elements inside and outside the system and analyzes factors that violate safety constraints that prevent system loss. [Prior art documents] [Patent documents]
[0003] [Patent Document 1] JP 2015-111402 A Summary of the Invention [Problem to be solved by the invention]
[0004] When applying STAMP / STPA to a system with multiple controllers and actuators, in the first step (Step 0) of STAMP / STPA, the controllers, controlled objects, and their operations and feedbacks related to the hazards are extracted and a control structure is created. At that time, because the target system has multiple controllers and actuators, there were cases where the number of operations and feedbacks became numerous, resulting in an explosion of hazard scenarios.
[0005] In addition, in the STAMP / STPA procedure (Step 2), a loop structure is used to analyze one factor by going back in time. However, because the target system has multiple controllers and sensors, it was not possible to analyze cases where multiple constraints such as observations and algorithm corrections occurred simultaneously (particularly cases where problems arose over time).
[0006] In addition, in the STAMP / STPA procedure (Step 2), countermeasures against the causes are analyzed. Since the target system has multiple controllers, it is desirable to consider which controller the countermeasure should be applied to. However, in conventional methods, countermeasures are considered for the hazard cause of a single controller as a scenario, so it is not possible to consider which controller the countermeasure should be applied to from the perspective of the control structure.
[0007] The present invention has been made in consideration of the above circumstances, and one of its objects is to provide a system analysis device, a system analysis method, and a program that enable highly accurate analysis of the safety of a system equipped with multiple controllers. [Means for solving the problem]
[0008] One aspect of the present invention is a system analysis device that analyzes the safety of a system having multiple controllers, the system analysis device comprising: an acquisition unit that acquires information about an operational phase in which control switching between the multiple controllers may occur and which is defined by pre-conditions and post-conditions of the system; a generation unit that generates, for each operational phase, a sequence diagram that chronologically represents hazard scenarios that may occur in the system between the pre-conditions and the post-conditions; and a display control unit that displays the generated sequence diagram on a display unit. Effect of the Invention
[0009] According to the present invention, it is possible to perform a highly accurate analysis of the safety of a system having multiple controllers. Furthermore, when designing the architecture of a system having multiple controllers, a system designer can apply the system safety analysis to important cases such as controller switching, thereby improving the work efficiency. [Brief description of the drawings]
[0010] [Figure 1] 1 is a functional block diagram showing an example of a configuration of a system analysis device 1 according to an embodiment. [Diagram 2] FIG. 2 is a diagram showing the correspondence between various tables and various figures according to the embodiment. [Diagram 3] FIG. 2 is a diagram showing an example of a hazard definition table ST-1 according to the embodiment. [Figure 4] FIG. 2 is a diagram showing an example of a state machine diagram FI-1 according to the embodiment. [Figure 5A] FIG. 13 is a diagram showing an example of a control structure extraction table ST-2 according to the embodiment. [Figure 5B] FIG. 13 is a diagram showing an example of a control structure extraction table ST-2 according to the embodiment. [Figure 5C] FIG. 13 is a diagram showing an example of a control structure extraction table ST-2 according to the embodiment. [Figure 6A] FIG. 13 is a diagram showing an example of a control structure diagram FI-2 according to the embodiment. [Figure 6B] FIG. 13 is a diagram showing an example of a control structure diagram FI-2 according to the embodiment. [Figure 7] FIG. 13 is a diagram showing an example of an unsafe operation analysis table ST-3 according to the embodiment. [Figure 8] FIG. 13 is a diagram showing an example of a control loop analysis table ST-4 according to the embodiment. [Figure 9] FIG. 13 is a diagram showing an example of a control loop analysis diagram FI-3 according to the embodiment. [Figure 10] FIG. 11 is a diagram showing an example of a hazard scenario list ST-5 according to the embodiment. [Figure 11] FIG. 13 is a diagram showing an example of a hazard scenario diagram FI-4 according to the embodiment. [Figure 12] FIG. 11 is a diagram showing an example of an operation sequence analysis table ST-92 according to the embodiment. [Figure 13] FIG. 2 is a diagram illustrating an example of an operation sequence OS according to the embodiment. [Figure 14] 4 is a flowchart showing an example of a processing flow of the system analysis device 1 according to the embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0011] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, embodiments of a system analysis device, a system analysis method, and a program according to the present invention will be described with reference to the drawings.
[0012] <System Analysis Equipment Overview> The system analysis device of the present embodiment supports safety analysis when examining the required specifications of a system (device, function) to be designed. In particular, the system analysis device supports comprehensive analysis of a system having multiple controllers and actuators, from identifying accidents, hazards, and safety constraints to examining causes and countermeasures for hazard scenarios. Specifically, the system analysis device 1 reflects modeling rules in MBSE (Model-based Systems Engineering) expressed in SysML (Systems Modeling Language) into each procedure of STAMP / STPA while reflecting the characteristics of the target system. The characteristics of the target system include, for example, events that cause recognition errors by the controller due to the passage of time, such as time constraints on algorithm correction of the controller, observation constraints of sensors, and spatial constraints on actuator operation.
[0013] <Configuration of system analysis device 1> 1 is a diagram showing an example of a configuration of a system analysis device 1 according to an embodiment. The system analysis device 1 includes, for example, an input interface 10, a display unit 20, a control unit 30, and a storage unit 40.
[0014] The input interface 10 accepts various input operations from a user of the system analysis device 1, converts the accepted input operations into electrical signals, and outputs the electrical signals to the control unit 30. For example, the input interface 10 includes a mouse, a keyboard, a touch panel, etc. When the input interface 10 is a touch panel, the input interface 10 may also have a display function of the display unit 20 described later.
[0015] The display unit 20 displays various information. For example, the display unit 20 displays images and files (tables, diagrams, etc.) generated by the control unit 30, a GUI (Graphical User Interface) for receiving various input operations from a user, and the like. The display unit 20 is an LCD (Liquid Crystal Display), an organic EL (Electro Luminescence) display, or the like. The display unit 20 may be provided separately from the system analysis device 1. The display unit 20 is an example of a "display unit" in the claims.
[0016] The control unit 30 controls the operation of the system analysis device 1. The control unit 30 has functions of, for example, an acquisition unit 31, a first generation unit 32, a second generation unit 33, and a display control unit 34. The control unit 30 realizes each of the functional units of the acquisition unit 31, the first generation unit 32, the second generation unit 33, and the display control unit 34 by, for example, a hardware processor (computer) such as a CPU (Central Processing Unit) executing a program (software) stored in the storage unit 40. In addition, some or all of these components may be realized by hardware (including circuitry) such as an LSI (Large Scale Integration), an ASIC (Application Specific Integrated Circuit), an FPGA (Field-Programmable Gate Array), or a GPU (Graphics Processing Unit), or may be realized by cooperation between software and hardware.
[0017] The acquisition unit 31 acquires information required to generate various tables (hazard definition table ST-1, control structure extraction table ST-2, unsafe operation analysis table ST-3, control loop analysis table ST-4, hazard scenario list table ST-5, operation sequence analysis table ST-92) and various diagrams (state machine diagram FI-1, control structure diagram FI-2, control loop analysis diagram FI-3, hazard scenario diagram FI-4, operation sequence OS) described later based on, for example, a user's operation via the input interface 10. The acquisition unit 31 is an example of the "acquisition unit" in the claims. That is, the acquisition unit 31 acquires information on an operation phase in which control switching between multiple controllers may occur and which is defined by pre-conditions and post-conditions of the system. The details of the function of the acquisition unit 31 will be described later.
[0018] The first generating unit 32 generates various tables (hazard definition table ST-1, control structure extraction table ST-2, unsafe operation analysis table ST-3, control loop analysis table ST-4, hazard scenario list table ST-5, and operation sequence analysis table ST-92). The second generating unit 33 generates various diagrams (state machine diagram FI-1, control structure diagram FI-2, control loop analysis diagram FI-3, hazard scenario diagram FI-4, and operation sequence OS). The first generating unit 32 and the second generating unit 33 are examples of the "generating unit" in the claims. That is, for each operation phase, a sequence diagram (hazard scenario list table ST-5) is generated that shows hazard scenarios that may occur in the system in time series between pre-conditions and post-conditions. The functions of the first generating unit 32 and the second generating unit 33 will be described in detail later.
[0019] The display control unit 34 controls the operation of the display unit 20. The display control unit 34 causes the display unit 20 to display, for example, various tables generated by the first generation unit 32, various diagrams generated by the second generation unit 33, a GUI for receiving various input operations from a user, and the like. The display control unit 34 is an example of a "display control unit" in the claims.
[0020] The storage unit 40 stores, for example, table data TD, diagram data FD, operation sequence OS, etc. The table data TD includes, for example, a hazard definition table ST-1, a control structure extraction table ST-2, an unsafe operation analysis table ST-3, a control loop analysis table ST-4, a hazard scenario list table ST-5, an operation sequence analysis table ST-92, etc. These various tables are frameworks (templates) of tables used in each process in the first generation unit 32. The diagram data FD includes, for example, a state machine diagram FI-1, a control structure diagram FI-2, a control loop analysis diagram FI-3, a hazard scenario diagram FI-4, etc. The storage unit 40 is realized, for example, by a random access memory (RAM), a read only memory (ROM), a hard disk drive (HDD), a flash memory, or a hybrid storage device in which a plurality of these are combined. In addition, a part or all of the storage unit 40 may be an external device accessible to the system analysis device 1, such as a network attached storage (NAS) or an external storage server.
[0021] FIG. 2 is a diagram showing the correspondence between various tables and various diagrams according to the embodiment. As shown in FIG. 2, the system analysis device 1 starts processing with the hazard definition table ST-1 as a starting point. The state machine diagram FI-1 is generated based on information input by the user to the hazard definition table ST-1 via the input interface 10. The control structure extraction table ST-2 is generated based on the hazard definition table ST-1 that has already been input by the user. The control structure diagram FI-2 is generated based on information input by the user to the control structure extraction table ST-2. The non-safety operation analysis table ST-3 is generated based on the control structure extraction table ST-2 that has already been input by the user. The control loop analysis table ST-4 is generated based on information input by the user to the non-safety operation analysis table ST-3. The control loop analysis diagram FI-3 is generated based on information included in the control loop analysis table ST-4. The control loop analysis table ST-4 is updated based on the contents input by the user to the control loop analysis diagram FI-3. The operation sequence analysis table ST-92 is generated based on information included in the control loop analysis table ST-4. The operation sequence OS is generated based on the information contained in the control loop analysis table ST-4 and the contents entered by the user into the operation sequence analysis table ST-92. The hazard scenario list ST-5 is generated based on the control loop analysis table ST-4. The hazard scenario diagram FI-4 is generated based on the contents entered by the user into the hazard scenario list ST-5.
[0022] (Hazard Definition Table ST-1) FIG. 3 is a diagram showing an example of a hazard definition table ST-1 according to an embodiment. The hazard definition table ST-1 is used to extract the relationship between the safe state definition, hazard definition, and accident definition in the target system and the system state (operation phase). In the hazard definition table ST-1, the user inputs the definitions of the safe state, hazard state, and accident in the target system to the first input area AR1-1. Here, the safe state refers to a state in which the system operates normally and does not lead to an accident. In addition, the hazard state refers to a state in which the system may cause a loss to the outside, the system itself is lost, the purpose cannot be achieved, and it leads to an accident. In addition, the accident refers to a state in which the system causes a loss to the outside. Next, the user inputs the system state (operation phase), the pre-condition of the system state, and the post-condition of the system state to the second input area AR1-2. Next, the user inputs information into the third input field AR1-3 indicating whether or not the defined state input into the first input field AR1-1 can occur for each system state (operational phase) input into the second input field AR1-2 (if it can occur, enter "O").
[0023] (State machine diagram FI-1) FIG. 4 is a diagram showing an example of a state machine diagram FI-1 according to an embodiment. The state machine diagram FI-1 is used to visually confirm state transitions for each operation phase based on information input by a user to the hazard definition table ST-1. FIG. 4 shows a state machine diagram FI-1 for a "system state (operation phase)" in the hazard definition table ST-1 shown in FIG. 3 that is "approaching." In this way, by dividing the operation phase in which the system position or the actuator operating state changes by setting pre-conditions and post-conditions, it becomes easy to extract hazard states for important phases in which switching between controllers may occur. By using such a state machine diagram for each operation phase, the user can visually check whether the various states defined by the user are appropriate or not and check for any missing definitions.
[0024] (Control structure extraction table ST-2) 5A to 5C are diagrams showing an example of the control structure extraction table ST-2 according to the embodiment. Although FIG. 5A to FIG. 5C are shown as separate tables, they may be one table. The control structure extraction table ST-2 is used to identify controllers and control objects in a target system and extract their control structures. A user inputs a control object controlled by a controller, and a component and a state quantity (e.g., a system position) that are in a hazard state, in a first input area AR2-1 in FIG. 5A. A safe state definition and a hazard definition input by a user in the hazard definition table ST-1 are reflected in a second input area AR2-2 in FIG. A user determines an "operational aspect" to be analyzed in this second input area AR2-2, and makes corrections according to the "safe state / hazard state" of the "control object". Next, a user determines a hierarchy between controllers and inputs a controller name in a third input area AR2-3 shown in FIG. 5B. Next, the user enters in the fourth input area AR2-4 shown in Fig. 5B the algorithm by which the controller judges whether to issue a control operation to prevent a hazard state, and the "state value" condition for that judgment. Next, the user enters the information to be instructed between the controllers and the feedback information for that in the fifth input area AR2-5 shown in Fig. 5C. Here, if there is no direct instruction relationship, no information is entered.
[0025] (Control structure diagram FI-2) 6A and 6B are diagrams showing an example of a control structure diagram FI-2 according to an embodiment. The control structure diagram FI-2 is used to visually confirm the control structure based on the information input by the user to the control structure extraction table ST-2 for each operation phase. FIG. 6A shows a control structure diagram FI-2 for a "system state (operation phase)" in the hazard definition table ST-1 shown in FIG. 3 that is "approaching". FIG. 6B shows a control structure diagram FI-2 for a "system state (operation phase)" in the hazard definition table ST-1 shown in FIG. 3 that is "capturing and combining with the target G". In this way, by illustrating the correspondence between the controller / control object for each operation phase in which the position of the system and the operating state of the actuator change, it becomes easy to extract the state of the control structure. By using such a control structure diagram FI-2 for each operation phase, the user can visually confirm whether the relationship between the controller / control object defined by the user is appropriate or not, and can visually confirm any omissions in the definition.
[0026] (Unsafe operation analysis table ST-3) FIG. 7 is a diagram showing an example of an unsafe operation analysis table ST-3 according to an embodiment. The unsafe operation analysis table ST-3 is used to analyze an unsafe operation in a target system. An unsafe operation refers to a control operation that may lead to a hazard. The user inputs, in a first input area AR3-1 in FIG. 7, what state the system will be in as a result of the unsafe operation (whether it will be in a hazard state). Next, in a second input area AR3-2 in FIG. 7, the user inputs what conditions and state values the control operation (unsafe operation) that will result in a hazard state may have in a combination of an operational phase and a system precondition.
[0027] (Control Loop Analysis Table ST-4) FIG. 8 is a diagram showing an example of a control loop analysis table ST-4 according to an embodiment. The control loop analysis table ST-4 is used to analyze a control loop in a target system. When the user performs the work for the first time (when the control loop analysis diagram FI-3 and the hazard scenario diagram FI-4 have never been created), the user does not input anything into this control loop analysis table ST-4 and proceeds to generate the control loop analysis diagram FI-3 and the hazard scenario diagram FI-4. On the other hand, when the control loop analysis diagram FI-3 and the hazard scenario diagram FI-4 have already been created, the user selects one hazard scenario (one row) in the control loop analysis table ST-4 to define an operation sequence. That is, the state values of the judgment conditions of the other controllers are clarified.
[0028] (Control Loop Analysis Diagram FI-3) 9 is a diagram showing an example of a control loop analysis diagram FI-3 according to an embodiment. The control loop analysis diagram FI-3 visually shows a control loop between a controller and a controlled object based on information input by a user to a hazard definition table ST-1, a control structure extraction table ST-2, and an unsafe operation analysis table ST-3. The user inputs factors that cause unsafe operations to a first input area AR4-1 of the control loop analysis diagram FI-3. The factors input here are reflected in the control loop analysis table ST-4.
[0029] (Hazard Scenario List ST-5) FIG. 10 is a diagram showing an example of a hazard scenario list ST-5 according to the embodiment. The hazard scenario list ST-5 is used to analyze each countermeasure. A hazard scenario is a scenario that leads from a hazard state to an accident. The user inputs each countermeasure in the first input area AR5-1 in FIG. 10.
[0030] (Hazard Scenario Diagram FI-4) FIG. 11 is a diagram showing an example of a hazard scenario diagram FI-4 (event sequence diagram) according to an embodiment. The hazard scenario diagram FI-4 is used to visually confirm whether or not a scenario is established based on the information of each countermeasure entered in the hazard scenario list ST-5. By checking the hazard scenario diagram FI-4, a user can confirm the effectiveness and comprehensiveness of the countermeasures. The hazard scenario diagram FI-4 is an example of a "sequence diagram" in the claims. The hazard scenario diagram FI-4 includes information that represents the factors of hazards included in the hazard scenario in association with the countermeasures against the factors.
[0031] (Operation Sequence Analysis Table ST-92) 12 is a diagram showing an example of an operation sequence analysis table ST-92 according to an embodiment. The operation sequence analysis table ST-92 is generated based on information included in the control loop analysis table ST-4. To convert it into a sequence diagram, the user inputs the output from the controller (From), the input to the controller (To), and the From and To messages (physical state of the system) into the operation sequence analysis table ST-92 (if the From and To controller names are the same, a self message is entered).
[0032] (Operation sequence OS) 13 is a diagram showing an example of an operation sequence OS according to an embodiment. The operation sequence OS is generated based on the information included in the control loop analysis table ST-4 and the contents input by the user to the operation sequence analysis table ST-92. The operation sequence OS is generated by transcribing information on the upper controller EC1, the lower controllers EC31 and EC32, the controlled object T, the controller C to be analyzed, and the unsafe operation from the information included in the control loop analysis table ST-4 (control loop analysis diagram FI-3).
[0033] <Processing flow of system analysis device 1> The processing of the system analysis device 1 will be described below. Fig. 14 is a flowchart showing an example of the flow of processing of the system analysis device 1 according to the embodiment. This flowchart is executed, for example, when a user of the system analysis device 1 inputs an instruction to start processing via the input interface 10. Moreover, the processing in each of the following steps is executed when the user inputs an instruction to execute each processing via the input interface 10.
[0034] First, the first generating unit 32 generates the hazard definition table ST-1 based on the framework (template) of the hazard definition table ST-1 stored in the storage unit 40, and the display control unit 34 displays the generated hazard definition table ST-1 on the display unit 20 (step S101). The user inputs the system state (operation phase), pre-condition of the system state, post-condition of the system state, etc., in addition to the safety state definition, hazard definition, and accident definition for the system to be analyzed, to the hazard definition table ST-1 displayed on the display unit 20. Furthermore, the user inputs information on whether or not the safety state definition, hazard definition, and accident definition state can occur for each operation phase to the hazard definition table ST-1.
[0035] Next, the acquisition unit 31 acquires the above-mentioned various information input by the user to the hazard definition table ST-1, the second generation unit 33 generates a state machine diagram FI-1 based on the acquired information, and the display control unit 34 displays the generated state machine diagram FI-1 on the display unit 20 (step S103). The user checks the state machine diagram FI-1 displayed on the display unit 20 to confirm whether the various information he or she inputs is appropriate and whether there are any omissions. The processing of these steps S101 and 103 corresponds to the identification of accidents, hazards, and safety constraints (Step 0) in the conventional STPA process.
[0036] That is, the first generating unit 32 generates a hazard definition table ST-1 capable of accepting input of information on an operation phase by a user, and the display control unit 34 causes the generated hazard definition table to be displayed on the display unit 20. In addition, the second generating unit 33 generates a state machine diagram FI-1 indicating a state transition from a hazard state of the system to an accident for each operation phase, based on the hazard definition table ST-1 including the information on the operation phase input by the user.
[0037] Next, the first generating unit 32 generates the control structure extraction table ST-2 based on the framework (template) of the control structure extraction table ST-2 stored in the storage unit 40 and the hazard definition table ST-1 input by the user, and the display control unit 34 displays the generated control structure extraction table ST-2 on the display unit 20 (step S105). The user inputs information about the controller and the controlled object to the control structure extraction table ST-2 displayed on the display unit 20.
[0038] Next, the acquisition unit 31 acquires the above-mentioned various information input by the user to the control structure extraction table ST-2, the second generation unit 33 generates a control structure diagram FI-2 based on the acquired information, and the display control unit 34 displays the generated control structure diagram FI-2 on the display unit 20 (step S107). The user checks the control structure diagram FI-2 displayed on the display unit 20 to confirm whether the various information he or she inputs is appropriate and whether there are any omissions. The processing of these steps S105 and S107 corresponds to the construction of a control structure (Step 0) in a conventional STPA process.
[0039] That is, the first generating unit 32 generates a control structure extraction table ST-2 capable of accepting input of control structure information that associates each of a plurality of controllers with a control target of each of the plurality of controllers by the user, based on a hazard definition table ST-1 including information on operation situations input by the user, and the display control unit 34 displays the generated control structure extraction table on the display unit 20. Moreover, the second generating unit 33 generates a control structure diagram FI-2 for each operation situation, based on the control structure extraction table ST-2 including the control structure information input by the user.
[0040] Next, the first generating unit 32 generates a non-safe operation analysis table ST-3 based on the framework (template) of the non-safe operation analysis table ST-3 stored in the storage unit 40 and the control structure extraction table ST-2 input by the user, and the display control unit 34 displays the generated non-safe operation analysis table ST-3 on the display unit 20 (step S109). The user inputs information about the state of the system as a result of the non-safe operation to the non-safe operation analysis table ST-3 displayed on the display unit 20. The process of step S109 corresponds to the extraction of non-safe control actions (Step 1) in the conventional STPA process.
[0041] Next, the first generation unit 32 generates a control loop analysis table ST-4 based on the framework (template) of the control loop analysis table ST-4 stored in the memory unit 40 and the non-safe operation analysis table ST-3 input by the user, and the display control unit 34 displays the generated control loop analysis table ST-4 on the display unit 20 (step S111).
[0042] Next, the second generating unit 33 generates a control loop analysis diagram FI-3 based on the control loop analysis table ST-4, and the display control unit 34 displays the generated control loop analysis diagram FI-3 on the display unit 20 (step S113). The user inputs factors that cause unsafe operations to occur to the control loop analysis diagram FI-3 displayed on the display unit 20. The information on the factors input to the control loop analysis diagram FI-3 is reflected in the control loop analysis table ST-4. The processing of these steps S111 and S113 corresponds to the identification of hazard induction factors in the conventional STPA process (Step 2). Here, the second generating unit 33 generates an operation sequence OS based on the information included in the control loop analysis table ST-4 and the contents input by the user to the operation sequence analysis table ST-92. By referring to such an operation sequence OS, the user can consider factors that cause unsafe operations to be input to the control loop analysis diagram FI-3 while checking the relationship between the controllers.
[0043] Next, the first generation unit 32 generates a hazard scenario list ST-5 based on the framework (template) of the hazard scenario list ST-5 stored in the storage unit 40 and the control loop analysis table ST-4 reflecting the factor information, and the display control unit 34 displays the generated hazard scenario list ST-5 on the display unit 20 (step S115). The user inputs information about measures against hazard factors to the hazard scenario list ST-5 displayed on the display unit 20.
[0044] That is, the first generation unit 32 generates a hazard scenario list ST-5 that can accept user input of information on countermeasures against hazard factors, and the display control unit 34 displays the generated hazard scenario list ST-5 on the display unit 20.
[0045] Next, the acquisition unit 31 acquires the above-mentioned various information input by the user to the hazard scenario list ST-5, the second generation unit 33 generates a hazard scenario diagram FI-4 based on the acquired information, and the display control unit 34 displays the generated hazard scenario diagram FI-4 on the display unit 20 (step S117). The user checks the hazard scenario diagram FI-4 displayed on the display unit 20 to confirm whether the various information he or she inputs is appropriate and whether there are any omissions. The processing of these steps S115 and S117 corresponds to the consideration of measures against hazard scenarios in the conventional STPA process (Step 2). With the above, the processing of this flowchart ends.
[0046] As described above, the system analysis device 1 of this embodiment can perform a highly accurate analysis of the safety of a system having multiple controllers. When designing the architecture of a system having multiple controllers, a system designer can apply system safety analysis to important cases such as controller switching, thereby improving work efficiency. In addition, measures against hazard scenarios created in the system safety analysis can be considered not only for one controller, but also for other controllers. This makes it possible to achieve non-personalization.
[0047] In particular, by dividing the operational phase in which the system position or the operating state of the actuator changes by setting pre-conditions and post-conditions, it is possible to limit it to important phases where switching between controllers may occur, preventing the explosion of hazard scenarios. In addition, by fixing the operations, observations, and corrections by algorithms between multiple controllers as a chronological order, and making it possible to accumulate the time lapse and identify the causal relationship in which multiple constraints occur, it is possible to prevent the overlooking of the factors that caused multiple constraints. In addition, by considering countermeasures not only for the hazard factor itself but also for each operation before and after the occurrence of the hazard factor and before and after the transmission of an unsafe operation, it is possible to consider countermeasures on the controller that is higher in the architecture or on the same level. However, only when the hazard factor is not a hardware failure but an operation from another controller, the notation is a branching expression on the event sequence diagram. This makes it possible to prevent the overlooking of countermeasures by other controllers.
[0048] The above describes the form for carrying out the present invention using an embodiment, but the present invention is not limited to such an embodiment, and various modifications and substitutions can be made within the scope that does not deviate from the gist of the present invention. [Explanation of symbols]
[0049] 1... system analysis device, 10... input interface, 20... display unit, 30... control unit, 31... acquisition unit, 32... first generation unit, 33... second generation unit, 34... display control unit, 40... storage unit
Claims
1. A system analysis device that analyzes safety of a system including a plurality of controllers, comprising: an acquisition unit that acquires information on an operation phase in which control switching between the plurality of controllers may occur, the operation phase being defined by a pre-condition and a post-condition of the system; a generation unit that generates, for each of the operational phases, a sequence diagram that represents a hazard scenario that may occur in the system between the pre-condition and the post-condition in a time series; a display control unit that displays the generated sequence diagram on a display unit; A system analysis device comprising:
2. the sequence diagram includes information representing hazard factors included in the hazard scenario in association with countermeasures against the hazard factors; The system analysis device according to claim 1 .
3. The generation unit generates a hazard definition table capable of accepting an input of information on the operation aspect by a user; The display control unit causes the generated hazard definition table to be displayed on the display unit. The system analysis device according to claim 1 .
4. the generating unit generates, for each of the operational phases, a state machine diagram showing a state transition from a hazard state of the system to an accident, based on the hazard definition table including information on the operational phases input by the user; The system analysis device according to claim 3 .
5. the generation unit generates a control structure extraction table capable of accepting input of control structure information by the user that associates each of the plurality of controllers with a control target of each of the plurality of controllers, based on the hazard definition table including information on the operation aspect input by the user; The display control unit causes the generated control structure extraction table to be displayed on the display unit. The system analysis device according to claim 3 .
6. the generation unit generates a control structure diagram for each of the operation phases based on the control structure extraction table including the control structure information input by the user. The system analysis device according to claim 5 .
7. the generation unit generates a hazard scenario list capable of accepting input of information on measures against the causes of the hazards by a user; The display control unit causes the generated hazard scenario list to be displayed on the display unit. The system analysis device according to claim 2 .
8. A system analysis method for analyzing safety of a system including a plurality of controllers, comprising the steps of: The computer acquiring information on an operation situation in which control switching between the plurality of controllers may occur, the operation situation being defined by a pre-condition and a post-condition of the system; generating a sequence diagram for each of the operational phases, the sequence diagram representing a chronological order of hazard scenarios that may occur in the system between the pre-conditions and the post-conditions; displaying the generated sequence diagram on a display unit; Systems analysis methods.
9. A program for analyzing safety of a system having a plurality of controllers, comprising: On the computer, acquiring information on an operation situation in which control switching between the plurality of controllers may occur, the operation situation being defined by a pre-condition and a post-condition of the system; generating a sequence diagram for each of the operational phases, the sequence diagram representing a chronological order of hazard scenarios that may occur in the system between the pre-conditions and the post-conditions; displaying the generated sequence diagram on a display unit; program.
Citation Information
Patent Citations
Safety analysis of complex system using component-oriented fault trees
JP2015111402A