STPA-based flight guidance system mode conversion safety analysis method

Abstract

The invention discloses a safety analysis method for mode conversion of a flight guidance system based on STPA, and the method comprises the steps: determining the demands, assembly and structure information of the flight guidance system, and recognizing the loss, system-level danger and system-level safety constraint; constructing a control structure model according to the flight guide structure information, wherein the control structure model comprises an external interaction part and an internal mode logic part; converting the control structure model into a UPPAAL model capable of performing model inspection according to a specific conversion relation; identifying a potential unsafe control behavior; converting system requirements and potential unsafe control behaviors into a CTL formula; verifying the correctness of the model by using a CTL formula and determining an effective unsafe control behavior; and for effective unsafe control behaviors, using an cause factor analysis framework to analyze loss scenes and cause factors one by one. According to the method, the limitation that the correctness of the model and the effectiveness of the unsafe control behaviors are difficult to guarantee in the STPA method is effectively dealt with, and the analysis quality and efficiency can be improved.

Description

Technical Field

[0001] The present invention relates to the fields of flight guidance systems, formal modeling, safety analysis, and verification, and particularly to a safety analysis method for flight mode conversion of a flight guidance system based on STPA. Background Art

[0002] The Flight Guidance System (FGS) is an important part of the Flight Control System (FCS). It is responsible for collecting the current flight state of the aircraft and various environmental data from sensors such as AHRS, ADS, and Nav Radio, comparing the measured state with the desired state set by the pilot or the Flight Management System (FMS), and providing pitch or roll guidance commands to the Autopilot (AP) and the Flight Director (FD) to minimize the difference between the measured state and the desired state. There are dozens of flight modes in the flight guidance system. During different stages of automatic flight, the flight guidance system activates different flight modes and calls corresponding flight control laws to control the flight of the aircraft. Incorrect invocation of flight modes will lead to mode confusion and cause irreparable danger. Therefore, it is urgent to conduct a safety analysis of the flight guidance system modes.

[0003] Currently, the most widely used safety analysis methods are the Fault Tree Analysis (FTA) and the Failure Mode and Effects Analysis (FMEA), etc. However, these traditional safety analysis methods only focus on component failures and the causal relationships between failures, believing that accidents are only caused by linear event chains and ignoring the safety risk problems caused by unsafe interactions between the system, subsystems (components), and the environment. These defects make it difficult for traditional methods to be applicable to complex systems that are constantly updated and developed.

[0004] To conduct a security analysis of the interaction behaviors among systems, subsystems, and environments, Nancy et al. from the Massachusetts Institute of Technology in the United States proposed the System Theoretic Accident Model and Processes (STAMP) based on system theory, and based on this, proposed the System Theory Process Analysis (STPA) method. System theory provides a comprehensive perspective for understanding the operating mechanism of complex systems. STPA is based on system theory and identifies hazards by focusing on the control and feedback relationships among system components. It is not limited to traditional failure mode analysis but delves into the dangerous situations that may be caused by component interactions during the normal operation of the system.

[0005] Although STPA has significant advantages in risk identification and system security analysis, there are still some limitations: First, it is difficult for the traditional STPA method to ensure that the control structure diagram manually built by relying on domain experts conforms to the expected functional settings of the system, that is, the model correctness; Second, it is difficult to ensure the effectiveness of the unsafe control behaviors analyzed by domain experts or automatically generated according to the enumeration method, and the subsequent loss scenario analysis will cause a waste of human resources. To address these limitations, the present invention proposes an analysis framework that combines STPA with UPPAAL and gives a system conversion process from the STPA model to a formal model for model checking. Through two model checks, the correctness of the model and the effectiveness of the unsafe control behaviors are ensured, and the quality and efficiency of the analysis are improved. Summary of the Invention

[0006] Object of the Invention: The present invention provides a security analysis method for the mode conversion of a flight guidance system based on STPA, which effectively improves the security analysis efficiency and quality of the mode conversion of the flight guidance system.

[0007] Technical Solution: A security analysis method for the mode conversion of a flight guidance system based on STPA according to the present invention specifically includes the following steps:

[0008] S1. Define the requirements, components, and structural information of the flight guidance system, and identify losses, system-level hazards, and system-level safety constraints;

[0009] S2. Construct a control structure model according to the flight guidance structure information, including an external interaction part and an internal mode logic part;

[0010] S3. Convert the control structure model into a UPPAAL model that can be used for model checking according to a specific conversion relationship;

[0011] S4. Identify potential unsafe control behaviors;

[0012] S5. Transform system requirements and potential unsafe control behaviors into CTL formulas;

[0013] S6. Verify the model correctness using CTL formulas and determine effective unsafe control behaviors;

[0014] S7. Analyze the loss scenarios and causal factors of effective unsafe control behaviors one by one using the causal factor analysis framework.

[0015] Furthermore, the implementation process of step S1 is as follows:

[0016] Sort out the functional and performance requirements for the mode conversion of the flight guidance system, including that at any moment, only one lateral mode and one vertical mode are activated when the flight mode is on;

[0017] Determine all components involved in the mode conversion analysis of the flight guidance system, including: crew, flight control panel, flight guidance system, autopilot, flight director, primary flight display, various sensors;

[0018] Describe the connection methods and structural layouts among the components involved in the mode conversion analysis of the flight guidance system, including that the flight control panel and the primary flight display, as the human-machine interaction interfaces, are connected to the crew and the flight guidance system to transmit control instructions and feedback information;

[0019] Identify the losses that the flight guidance system may face, the system-level hazards that may cause losses, and the relevant system-level safety constraints, including flight impairment caused by flight mode confusion, and obtain that the flight mode of the flight guidance system cannot be in a state of mode confusion during flight.

[0020] Furthermore, step S2 is specifically as follows:

[0021] The external interaction part includes a controller, an actuator, sensors, and a controlled process; the controller includes the crew and the flight guidance system; the actuator includes the flight control panel, autopilot, flight director, primary flight display, flight control surfaces; the sensors include an attitude and heading reference system, an air data system, and radio navigation;

[0022] The internal mode logic part refers to the component interaction inside the flight guidance system, including controller mode logic and flight control laws;

[0023] Each component forms a control feedback loop according to the hierarchy: the aircraft provides a control command of "activating or canceling a certain flight mode" to the flight guidance system through the flight control panel; the flight guidance system provides "mode status" feedback to the aircraft crew through the flight control panel or the primary flight display; the flight guidance system provides control commands of "lateral or vertical guidance commands" to the aircraft through the autopilot and flight controls; the aircraft provides "flight attitude" feedback to the aircraft crew through the attitude and heading reference system and the primary flight display; the flight guidance system receives feedback information of "aircraft status" and "navigation information" from the air data system and radio navigation sensors.

[0024] Further, the specific content of step S3 is as follows:

[0025] Each component and flight mode in the control structure model are transformed into timed automata to form a timed automata network; a timed automaton is a tuple TA = (L, l0, C, A, E, I); where L is the set of locations, which is the set of states of components or modes; l0 is the initial location, which is the state when the component or mode is just turned on; C is the set of clocks, which is used to represent the priority of the response order of each instruction in the flight control panel; A is the set of actions, which is used to represent the synchronization of control and feedback and the set composed of internal actions of components or modes; E is the set of state transitions between locations with actions, guard conditions, and sets of clocks to be reset. B(C) represents the conditions that the location clocks must satisfy, which is the set composed of the state transitions of components or modes and the transition conditions; I: L → B(C) assigns invariant time conditions to locations.

[0026] The timed automata in the timed automata network share clocks and action sets; different timed automata communicate synchronously through handshakes to simulate the control and feedback relationships between components; use "a!" to represent sending a synchronous message, use "a?" to represent receiving a synchronous message, and "a" is the name of the synchronization; when a timed automaton sends "a!", the other timed automaton that receives "a?" synchronously transfers to the next state location.

[0027] Further, the specific content of step S4 is as follows:

[0028] Unsafe control behaviors include <source>, <type>, <control behavior>, <context>, and <associated hazard>. Among them, <source> refers to the controller that provides the control behavior; <type> refers to four situations where the control behavior may be dangerous, including: the hazard caused by the absence of the control behavior, the hazard caused by the provision of incorrect control behavior, the hazard caused by the provision of a potentially safe control behavior but with the node being too early, too late, or in the wrong order, and the hazard caused by the premature stop or excessive duration of the control behavior; <control behavior> refers to the control behavior or command itself; <context> refers to the set of variables and their values related to the process of the controller issuing control behaviors to control the controlled process; <associated hazard> refers to the hazard that may be caused by the unsafe control behavior.

[0029] Further, the specific steps of step S5 are as follows:

[0030] Convert the system requirements and unsafe control behaviors into branching-time temporal logic CTL formulas. CTL formulas consist of path formulas and state formulas. Path formulas include: E<>p means that there exists a path where p is true at a certain state on this path; E[]p means that there exists a path where p is true at all states on this path; A<>p means that for all paths, p is true at a certain state on any path; A[]p means that for all paths, p is true at all states on any path; p-->q means that when p holds, q will hold. State formulas are represented by Backus-Naur form.

[0031] Further, the specific steps of step S6 are as follows:

[0032] Input the obtained CTL formulas into the property area to be verified of the UPPAAL verifier. If all CTLs related to the system requirements are verified to pass, it proves that the system modeling meets the modeling expectations and the model is correct. If there are parts that do not pass, it proves that there are defects in the modeling and the model needs to be modified. After the correctness of the model is determined, then check the CTL formulas related to potential unsafe control behaviors. If the verification passes, it proves that there may be related safety hazards in the current system, and this potential unsafe control behavior is identified as a real unsafe control behavior, and loss scenarios and causal factors need to be analyzed to find the incentives for the possible occurrence of this unsafe control behavior. Further, generate safety requirements according to the unsafe control behavior and correct the system.

[0033] Further, the specific steps of step S7 are as follows:

[0034] Loss scenarios include: (a) Why does an unsafe control behavior occur; (b) Why does the control behavior execute improperly or fail to execute, resulting in danger?

[0035] For scenario (a), the causes of unsafe control behaviors themselves are explored, considering controller components and the feedback information received by the controller; for scenario (b), the exploration is about the situation where a control behavior that is safe in itself fails to be executed or is executed improperly during the execution process, resulting in danger, considering the actuator and the working state of the controlled process; all possible categories are listed in the causal factor analysis framework: the factors in scenario (a) include incorrect or missing control inputs or external information received by the controller, defects in the controller's control algorithm, insecure controller control models, improper operation of sensors, improper sensor feedback, improper feedback of the controlled process, dangerous output of the controlled process, and failure of controlled process components; the factors in scenario (b) include improper operation of the controller, improper operation of the actuator, lag in actuator operation, conflicting control behaviors provided by other controllers, omission of controlled process inputs, and failure of the controlled process to recognize interference information.

[0036] Advantages: Compared with the prior art, the advantages of the present invention are as follows: The present invention combines the STPA method based on system theory and the model checking tool UPPAAL. On the premise of ensuring the rigorous order of system safety analysis, it supplements the lack of formality in STPA, verifies the correctness of the model using UPPAAL, and screens out unsafe control behaviors, improving the efficiency and quality of safety analysis. Description of the Drawings

[0037] Figure 1 is the flow chart of the present invention;

[0038] Figure 2 is the schematic diagram of the control structure model of the flight guidance system;

[0039] Figure 3 is the framework diagram of loss scenarios and causal factors. Detailed Embodiments

[0040] The present invention will be further described in detail below with reference to the drawings.

[0041] As Figure 1 shown, the present invention provides a safety analysis method for flight guidance system mode conversion based on STPA. The main idea of this method is to select the STPA method based on system theory as the main body for safety analysis of the flight guidance system mode conversion problem. Then, aiming at the lack of formality in the STPA method, it is extended by introducing UPPAAL so that the model constructed by STPA can be verified to ensure the correctness of the model. The specific steps are as follows:

[0042] S1. Define system requirements, components, and structural information, and identify losses, system-level hazards, and system-level safety constraints.

[0043] Comprehensively sort out the functional and performance requirements for the mode conversion of the flight guidance system. For example, when the flight mode is on, at any given moment, only one lateral mode and one vertical mode are activated, etc.

[0044] Identify all components involved in the mode conversion analysis of the flight guidance system, including: flight crew, flight control panel, flight guidance system, autopilot, flight director, primary flight display, various sensors, etc.

[0045] Describe in detail the connection methods and structural layouts among the components involved in the mode conversion analysis of the flight guidance system. For example, the flight control panel and the primary flight display, as the human-machine interaction interfaces, connect the flight crew and the flight guidance system to transmit control commands and feedback information.

[0046] Identify the Losses that the flight guidance system may face, the system-level Hazards that may cause the losses, and the related system-level Safety-Constraints. For example, flight mode confusion (H-1) may lead to flight damage (L-1), so the flight mode of the flight guidance system cannot be confused during flight (SC-1), etc.

[0047] S2. Construct the control structure model of the flight guidance system as shown in Figure 2 the following.

[0048] The mode conversion control structure model of the flight guidance system is divided into an external interaction part and an internal mode logic part. The components involved in the external interaction part are: controllers (flight crew, flight guidance system), actuators (flight control panel, autopilot, flight director, primary flight display, flight control surfaces), sensors (attitude and heading reference system, air data system, radio navigation, etc.) and the controlled process (aircraft). The internal mode logic part refers to the component interaction within the flight guidance system, mainly involving the controller (mode logic) and the controlled process (flight control law).

[0049] Each component forms a control feedback loop according to the hierarchy: the flight crew provides a control command of "activate or cancel a certain flight mode" to the flight guidance system through the flight control panel; the flight guidance system provides a "mode status" feedback to the flight crew through the flight control panel or the primary flight display; the flight guidance system provides a control command of "lateral or vertical guidance command" to the aircraft through the autopilot and flight control surfaces; the aircraft provides feedback such as "flight attitude" to the flight crew through the attitude and heading reference system and the primary flight display; the flight guidance system receives feedback information such as "aircraft status" and "navigation information" from sensors such as the air data system and radio navigation.

[0050] S3. Convert the control structure model into a UPPAAL model that can be model - checked according to a specific conversion relationship.

[0051] Convert the STPA control structure model into a UPPAAL model that can be used for verification. The basic idea is to convert each component and flight mode in the control structure model into timed automata, thus forming a network of timed automata. A timed automaton is a tuple TA=(L, l0, C, A, E, I); where L is the set of locations, which is the set of states of components or modes in this method; l0 is the initial location, which is the state when the component or mode is just turned on in this method; C is the set of clocks, and in this method, the clocks are mainly used to represent the priorities of the response order of each instruction in the flight control panel; A is the set of actions, and in this method, it is the set composed of the synchronization of control and feedback and the internal actions of components or modes; E is the set of state transitions between locations with actions, guard conditions, and sets of clocks to be reset. Here, B(C) represents the conditions that the location clocks must satisfy, which is the set composed of the state transitions of components or modes and the transition conditions in this method; I: L→B(C) assigns invariant time conditions to locations.

[0052] The timed automata in the network of timed automata share clocks and action sets. Different timed automata communicate synchronously through handshakes, which can be used to simulate the control and feedback relationships between components. Use a! to represent sending a synchronous message, and use "a?" to represent receiving a synchronous message, where a is the name of the synchronization. When a timed automaton sends "a!", another timed automaton that receives "a?" synchronously transfers to the next state location.

[0053] S4. Identify potential unsafe control behaviors.

[0054] Unsafe control behaviors refer to control behaviors that may cause danger under specific scenarios and worst - case conditions. Unsafe control behaviors consist of five parts: <source><type><control behavior><context><related danger>. Among them, <source> refers to the controller that provides the control behavior; <type> refers to four situations where the control behavior may be dangerous: (1) Failure to provide a control behavior causes danger. (2) Providing an incorrect control behavior causes danger. (3) Providing a potentially safe control behavior, but the node is too early, too late, or in the wrong order. (4) The control behavior stops too early or lasts too long; <control behavior> refers to the control behavior or command itself; <context> refers to the set of variables and their values related to the process of the controller sending a control behavior to control the controlled process, including environmental conditions, the state of the controlled process, and the state of the controller, etc.; <related danger> refers to the danger that the unsafe control behavior may cause.

[0055] The present invention believes that the unsafe control behaviors obtained by manual analysis by domain experts or enumerated according to state variables but not verified are potential unsafe control behaviors, and model checking needs to be carried out before cause factor analysis.

[0056] S5. Convert the system requirements and potential unsafe control behaviors into CTL formulas.

[0057] Convert the system requirements and unsafe control behaviors into the branching-time logic CTL formulas. CTL formulas consist of path formulas and state formulas. Path formulas include: E<>p means there exists a path such that p is true at a certain state on this path; E[]p means there exists a path such that p is true at all states on this path; A<>p means for all paths, p is true at a certain state on any path; A[]p means for all paths, p is true at all states on any path; p-->q means when p holds, q will hold. State formulas are represented by the Backus-Naur (BNF) normal form.

[0058] S6. Use the CTL formulas to verify the model correctness and determine the effective unsafe control behaviors.

[0059] Input the obtained CTL formulas into the property area to be verified of the UPPAAL verifier, and click "Start Verification" to start verifying the property. If the status indicator on the right side of the property shows green, it means the property verification passes; on the contrary, if the indicator shows red, it means the property verification fails. If all CTLs related to the system requirements are verified to pass, it proves that the system modeling meets the modeling expectations and the model is correct; if there are parts that do not pass, it proves that there are defects in the modeling and the model needs to be modified. After the model correctness is ensured, then check the CTL formulas related to the potential unsafe control behaviors. If the verification passes, it proves that there may be related safety hazards in the current system, and this potential unsafe control behavior is identified as a real unsafe control behavior. Loss scenario and cause factor analysis need to be carried out to find the incentives that may cause this unsafe control behavior. Further, generate safety requirements according to this unsafe control behavior, and then modify the system.

[0060] S7. Use the cause factor analysis framework to analyze the loss scenarios and cause factors of the effective unsafe control behaviors one by one.

[0061] After determining the real unsafe control behaviors, it is necessary to carry out loss scenario and cause factor analysis on them. Loss scenarios are usually divided into two major parts: a) Why does the unsafe control behavior occur? And b) Why does the control behavior occur with improper execution or non-execution, thus leading to danger?

[0062] Type a explores the causes of unsafe control behaviors themselves, which requires considering controller components and the feedback information received by the controller; type b explores that safe control behaviors themselves have accidents during execution, resulting in non-execution or improper execution, thus causing danger, which requires considering the actuator and the working state of the controlled process. All possible categories are listed in the loss scenario and causal factor framework, such as Figure 3 shown. (a) Scenario factors include incorrect or missing control inputs or external information received by the controller, controller control algorithm defects, unsafe controller control models, improper sensor operations, improper sensor feedback, improper controlled process feedback, dangerous outputs of the controlled process, and failures of controlled process components; (b) Scenario factors include improper controller operations, improper actuator operations, actuator operation lags, conflicting control behaviors provided by other controllers, missing controlled process inputs, and unrecognized interference information in the controlled process. Therefore, every unsafe control behavior and danger needs to be investigated for factors using this framework.

[0063] The above embodiments are only for illustrating the technical idea of the present invention, and the protection scope of the present invention cannot be limited thereby. Any modifications made on the basis of the technical solution according to the technical idea proposed by the present invention shall fall within the protection scope of the present invention.

Claims

1. A safety analysis method for mode transition of a flight guidance system based on STPA, characterized in that: The following steps are involved: S1. Clarify flight guidance system requirements, components, and structural information, and identify losses, system-level hazards, and system-level safety constraints; S2. Construct a control structure model according to the flight guidance structure information, including an external interaction part and an internal mode logic part; S3, transforming the control structure model into a UPPAAL model that can be used for model testing according to a specific transformation relationship; S4. Identify potential unsafe control actions; S5. Convert system requirements and potential unsafe control behaviors into CTL formulas; S6. Use the CTL formula to verify the correctness of the model and determine the effective unsafe control behavior; S7. Use the causal factor analysis framework to analyze the loss scenarios and causal factors of effective unsafe control behaviors one by one.

2. The safety analysis method for mode conversion of a flight guidance system based on STPA according to claim 1, characterized in that: The implementation process of step S1 is as follows: Sort out the functional and performance requirements of the flight guidance system mode conversion, including that when the flight mode is turned on, only one lateral mode and one vertical mode are activated at any time; Identify all components involved in the flight guidance system mode transition analysis, including: crew, flight control panel, flight guidance system, autopilot, flight director, primary flight display, and various sensors; Describe the connection mode and structural layout between the components involved in the flight guidance system mode conversion analysis, including the flight control panel and primary flight display as the human-machine interaction interface, connecting the crew and the flight guidance system to transmit control commands and feedback information; Identify the possible losses faced by the flight guidance system, the system-level hazards that may cause losses, and the related system-level safety constraints, including flight mode confusion leading to flight damage, and ensure that the flight mode of the flight guidance system cannot be confused during flight.

3. The safety analysis method for mode conversion of a flight guidance system based on STPA according to claim 1, characterized in that: The step S2 is specifically as follows: The external interaction part includes controllers, actuators, sensors and controlled processes; the controller includes the crew and the flight guidance system; the actuator includes the flight control panel, autopilot, flight director, primary flight display, and flight control surface; the sensor includes the attitude and heading reference system, air data system, and radio navigation; The internal mode logic part refers to the component interactions within the flight guidance system, including controller mode logic and flight control laws; Each component constitutes a control feedback loop in a hierarchical manner: the crew provides the flight guidance system with control instructions of "activating or canceling a certain flight mode" through the flight control panel; the flight guidance system provides the crew with "mode status" feedback through the flight control panel or the primary flight display; the flight guidance system provides the aircraft with control instructions of "lateral or vertical guidance instructions" through the autopilot and the flight control plane; the aircraft provides the crew with "flight attitude" feedback through the attitude and heading reference system and the primary flight display; the flight guidance system receives "aircraft status" and "navigation information" feedback from the air data system and the radio navigation sensor.

4. The safety analysis method for mode conversion of a flight guidance system based on STPA according to claim 1, characterized in that: The step S3 is specifically as follows: Each component and flight mode in the control structure model is converted into a timed automaton to form a timed automaton network; a timed automaton is a tuple TA = (L, l0, C, A, E, I); where L is a position set, which is a state set of a component or mode; l0 is an initial position, which is the state of a component or mode when it is just turned on; C is a clock set, which is used to indicate the priority of the response sequence of each instruction in the flight control panel; A is an action set, which is used to indicate the synchronization of control and feedback and the set of internal actions of a component or mode; It is a set of state transitions between locations with actions, guard conditions, and clock sets to be reset. B(C) represents the conditions that the clock at the location must meet. It is a set of state transitions of components or modes and transition conditions. I:L→B(C) is the invariant time condition for the location assignment. The timed automata in the timed automata network share clocks and action sets; different timed automata communicate synchronously through handshakes to simulate the control and feedback relationship between components; "a!" is used to represent the sending of synchronization information, and "a?" is used to represent the receiving of synchronization information, and "a" is the name of synchronization; when a timed automata sends "a!", the other timed automata that receives "a?" will synchronously transfer to the next state position.

5. The safety analysis method for mode conversion of a flight guidance system based on STPA according to claim 1, characterized in that: The step S4 is specifically as follows: Unsafe control behaviors include <source>, <type>, <control behavior>, <context> and <related hazards>; among which, <source> refers to the controller that provides control behavior; <type> refers to four situations in which control behavior may be dangerous, including: the danger caused by not providing control behavior, the danger caused by providing incorrect control behavior, the danger of providing potentially safe control behavior but the nodes are too early, too late or in the wrong order, and the danger caused by the control behavior stopping too early or lasting too long; <control behavior> refers to the control behavior or command itself; <context> refers to the set of variables and variable values ​​related to the process in which the controller issues control behavior to control the controlled process; <related hazards> refers to the danger that may be caused by unsafe control behavior.

6. The safety analysis method for mode conversion of a flight guidance system based on STPA according to claim 1, characterized in that: The step S5 is specifically as follows: Convert system requirements and unsafe control behaviors into branching sequential logic (CTL) formulas; The CTL formula consists of a path formula and a state formula; the path formula includes: E<>p means that there is a path, and p is true in a certain state under this path; E[]p means that there is a path under which all states of p are true; A<>p means that for all paths, p is true in a certain state under any path; A[]p means that for all paths, p is true in all states under any path; p-->q means that when p is true, q will be true; the state formula is expressed in Backus-Naur form.

7. The safety analysis method for mode conversion of a flight guidance system based on STPA according to claim 1, characterized in that: The step S6 is specifically as follows: The obtained CTL formula is input into the property to be verified area of ​​the UPPAAL verifier. If all CTLs related to the system requirements are verified, it proves that the system modeling meets the modeling expectations and the model is correct. If there are parts that fail, it proves that the modeling is defective and the model needs to be modified. After the correctness of the model is determined, the CTL formula related to the potential unsafe control behavior is tested. If the verification is passed, it proves that the current system may have related safety hazards. The potential unsafe control behavior is identified as a real unsafe control behavior, and loss scenario and causal factor analysis is required to find the possible cause of the unsafe control behavior. Furthermore, safety requirements are generated based on the unsafe control behavior and the system is corrected.

8. The safety analysis method for mode conversion of a flight guidance system based on STPA according to claim 1, characterized in that: The step S7 is specifically as follows: Loss scenarios include: (a) why unsafe control actions occur; (b) why control actions are improperly executed or not executed, resulting in danger; For (a) scenario, the cause of the unsafe control behavior itself is explored, taking into account the controller components and the feedback information received by the controller; for (b) scenario, the cause of the safe control behavior itself is explored, which leads to danger due to an accident during the execution process, resulting in failure to execute or improper execution, taking into account the working status of the actuator and the controlled process; all possible categories are listed in the causal factor analysis framework: (a) scenario factors include incorrect or missing control inputs or external information received by the controller, defects in the controller control algorithm, unsafe controller control model, improper sensor operation, improper sensor feedback, improper controlled process feedback, dangerous output of the controlled process, and failure of controlled process components; (b) scenario factors include improper controller operation, improper actuator operation, delayed actuator operation, conflicting control behaviors provided by other controllers, missing inputs to the controlled process, and failure of interference information to be identified by the controlled process.

Images