Probabilistic-nonprobabilistic cross-domain hybrid analysis and verification method for flight control system based on multiple models

Abstract

The application relates to the field of formal analysis and verification technology, in particular to a flight control system probability-non-probability cross-domain hybrid analysis and verification method based on multiple models, which comprises the following steps: determining preliminary safety requirements according to typical fault cases of multiple different control systems; performing knowledge migration on the preliminary safety requirements to obtain flight control system safety requirements; determining flight control system key risk requirements according to existing fault cases of the flight control system and flight control system document materials; processing the flight control system safety requirements and the flight control system key risk requirements to obtain non-probability analysis attribute verification results; analyzing the flight control system safety requirements and the flight control system key risk requirements to obtain multiple-model fault occurrence probabilities; and obtaining analysis and verification results of the flight control system; and the application can improve the sufficiency and completeness of flight control system analysis and verification.

Description

Technical Field

[0001] The present invention relates to the technical field of formal analysis and verification, and in particular to a probabilistic and non-probabilistic cross-domain hybrid analysis and verification method for a flight control system based on multiple models. Background Art

[0002] The development of a model-based flight control system consists of two phases: development and testing. The development phase defines product specifications and requirements, conducts basic design, specifies design details, and develops a prototype. The testing phase tests the performance of individual components and the overall system, conducts system-level testing, and refines market requirements, achieving results through control models or code.

[0003] There are two main approaches to model-based flight control system software development:

[0004] The first is to use models to describe system requirements and designs. This development approach uses use case diagrams, sequence diagrams, and other tools to guide code development. However, in practice, model building and code development are often done by different people, which can easily lead to inconsistencies between the model and code.

[0005] The second is model-to-code generation. This development method mainly converts the established model (such as Simulink or SCADE model) directly into code through modeling software such as Matlab or SCADE. The code generated by this method has poor readability and it is difficult to find problems through code review. Existing code detection tools also face problems such as insufficient detection of state space completeness issues, business issues of state transitions, or deep-level division by zero problems. On the other hand, model verifiers such as Matlab's ModelAdvisor, Simulink Design Verifier, Simulink Converage, Simulink Check verifier, SCADE's Model Checker, Model Verifier, etc. also face the problem of insufficient detection.

[0006] Therefore, even though the flight control system model itself has integrated multiple verification tools to verify the model, it is still difficult to discover some deep-seated and business-related problems. Summary of the Invention

[0007] In view of the above problems, the present invention provides a probabilistic and non-probabilistic cross-domain hybrid analysis and verification method for a flight control system based on multiple models, which solves the technical problems of the flight control system verification method in the existing technology, such as the lack of verification of probabilistic attributes, the limitation of single model analysis, and insufficient detection.

[0008] The present invention provides a multi-model-based probabilistic and non-probabilistic cross-domain hybrid analysis and verification method for a flight control system, comprising: step S1, determining preliminary safety requirements based on typical failure cases of multiple different control systems, wherein the preliminary safety requirements include general safety requirements and special safety requirements;

[0009] Step S2: Perform knowledge transfer on the preliminary safety requirements to obtain flight control system safety requirements; determine key risk requirements of the flight control system based on existing flight control system failure cases and flight control system documentation;

[0010] Step S3: performing safety specification generation, dynamic simulation analysis, and safety attribute verification processing on the flight control system safety requirements and the flight control system key risk requirements to obtain a non-probabilistic analysis attribute verification result;

[0011] Step S4: performing a multi-model failure probability analysis on the flight control system safety requirements and the flight control system key risk requirements to obtain a multi-model failure probability;

[0012] Step S5: taking the non-probabilistic analysis attribute verification result and the multi-model fault occurrence probability together as the analysis and verification result of the flight control system.

[0013] Preferably, the step S1 specifically includes:

[0014] Step S1-1: Collect and summarize typical fault case sets of control system software in multiple different fields to form security requirements in multiple fields, and integrate the security requirements in multiple fields into cross-domain knowledge to form the general security requirements;

[0015] Step S1-2: Summarize the unique security requirements of each of the multiple fields to form the dedicated security requirements.

[0016] Preferably, the step S1-1 specifically includes:

[0017] Assume that the number of domains is n, and the security requirements of each domain i are expressed as a set R i , i=1,2,...,n, general safety requirement R universal is the intersection of all domain sets, expressed as:

[0018]

[0019] The step S1-2 specifically includes: the dedicated security requirement R of domain i special,i It can be expressed as:

[0020]

[0021] Among them, Tj→i (·) represents the transfer function that transfers and adapts the requirements of domain i to domain j, R i -R universal represents the unique requirements of domain i, ∪ j≠i T h→i (R j -R universal ) represents the requirements transferred from other domains and adapted to domain i.

[0022] Preferably, in step S2, knowledge migration is performed on the preliminary safety requirements to obtain the expression of the flight control system safety requirements:

[0023] R specoal,k =Q(R universal ,R special,i ,M k )

[0024] Among them, R special,k Indicates the safety requirements of flight control system type k equipment, M k Indicates the proprietary information and key risk requirements of flight control system model k equipment; Q(R universal ,R special,i ,M k ) represents the general safety requirement R universal and the specific security requirements R of domain i special,i Based on M k Conduct knowledge transfer processing;

[0025] The key risk requirements for the flight control system include key risk requirements for state switching issues in the flight control system, and the key risk requirements for state switching issues include requirements for airspeed, throttle position, barometric altitude indication and radio altitude value.

[0026] Preferably, the step S3 specifically includes:

[0027] Step S3-1, analyzing the safety requirements and key risk requirements of the flight control system, guiding the XSTAMPP software to perform automated analysis based on the STAMP theory system risk analysis, and generating safety regulations;

[0028] Step S3-2: Using the security specification as input to the timed automaton software UPPAAL, a dynamic simulation analysis of the model level is performed based on timed automaton theory to obtain a property verification result of UPPAAL, which may be a pass or fail result. When the property verification fails, a counterexample path is provided;

[0029] Step S3-3: Verify the security attributes of the security specification at the code level using the ESBMC software tool to obtain an ESBMC attribute verification result, which may include a pass or fail result.

[0030] Step S3-4: Merge the attribute verification result of the UPPAAL and the attribute verification result of the ESBMC to obtain the final attribute verification result of the non-probabilistic analysis.

[0031] Preferably, the step S4 specifically includes:

[0032] Step S4-1, modeling the behavior of the flight control system as a Simulink model, wherein the input of the Simulink model includes the system ground state, radio altitude, barometric altitude, airspeed, wheel load, and valid sensor identification, and the model output is the ground state and leveling state identification;

[0033] Step S4-2: Using the input of the Simulink model and the correctness of each input as the bottom event of the event tree, using the event of the correct output of the Simulink model as the top event of the event tree, and constructing a tree-like result of the event tree according to the logical calculation of the Simulink model to obtain an event tree;

[0034] Step S4-3: Analyze the event tree using multiple models to obtain multi-model fault occurrence probabilities.

[0035] Preferably, the step S4-3 specifically includes:

[0036] Step S4-3-1, using Isograph software or AnyLogic software to analyze the event tree, calculate the probability of occurrence of the top event, and obtain the probability of occurrence of the fault from the fault perspective;

[0037] Step S4-3-2: convert the Simulink model into a UPPAAL SMC model, perform probability attribute verification using the UPPAAL SMC model, and obtain the probability of failure calculated by the UPPAAL SMC model;

[0038] Step S4-3-3: automatically convert the UPPAAL SMC model into a PRISM model, perform probability attribute verification using the PRISM verifier, and obtain the probability of failure calculated by the PRISM model;

[0039] Step S4-3-4: using the PRISM model as the input of the STROM model, performing probability attribute verification through the STROM model verifier to obtain the probability of failure calculated by the STROM model;

[0040] Step S4-3-5: Use the mCRL2 verification tool to perform Markov chain modeling on the behavior of the flight control system, and calculate the relevant probability and occurrence relationship of the faults / events in the Markov chain to obtain the fault occurrence probability calculated by the mCRL2 verification tool;

[0041] Step S4-3-6: The failure probability from the fault perspective, the failure probability calculated by the UPPAAL SMC model, the failure probability calculated by the PRISM model, the failure probability calculated by the STROM model, and the failure probability calculated by the mCRL2 verification tool are collectively used as the multi-model failure probability.

[0042] Preferably, in step S4-3-3, the specific steps of automatically converting the UPPAAL SMC model into the PRISM model include:

[0043] (1) Map each state in the UPPAAL SMC model to a state in the PRISM model;

[0044] (2) Using global variables and Boolean flags to simulate the clock constraints and synchronization of the UPPAAL SMC model in the PRISM model;

[0045] (3) Each UPPAAL SMC model transformation is mapped to a probability transformation in the PRISM model, and the state transition and probability of the original model are retained, and finally the PRISM model is obtained.

[0046] Compared with the prior art, the present invention has at least the following beneficial effects:

[0047] (1) The multi-model probabilistic and non-probabilistic cross-domain hybrid flight control system verification method provided by this invention can effectively detect the non-probabilistic properties of model-based software systems, solving the problem of insufficient detection at the traditional model level. By converting the model to code and then from code to model, the inconsistency between model and code and the poor readability of the code are overcome, and the probability of an event occurring can be accurately given from a quantitative perspective.

[0048] (2) This invention adopts a cross-domain knowledge fusion solution, based on the migration of knowledge from other fields, to achieve knowledge sharing, thereby enhancing the detection capability and accuracy of system security. By combining historical fault information, knowledge from other fields, and the results of different model detection, the accuracy and precision of the detection results are improved.

[0049] (3) The present invention not only detects the basic functions of the flight control system within a limited time, but also detects potential problems such as deadlock, state space switching disorder, system boundary testing, and division by zero. By testing safety requirements using multiple non-probabilistic and probabilistic models, in addition to providing qualitative assessments (such as pass / fail), it also provides quantitative assessments (such as the probability of an event occurring), significantly outperforming single-model detection methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] The drawings are only for purposes of illustrating particular embodiments and are not to be considered limiting of the invention.

[0051] Figure 1 Flowchart of the multi-model-based probabilistic and non-probabilistic cross-domain hybrid analysis and verification method for the flight control system provided by the present invention;

[0052] Figure 2 Schematic diagram of the multi-model-based probabilistic and non-probabilistic cross-domain hybrid analysis and verification method for the flight control system provided by the present invention;

[0053] Figure 3 A flowchart for analyzing and verifying a certain type of aircraft flight control system provided by the present invention;

[0054] Figure 4 This is the simulation result of the flight control system state switching model provided by the present invention.

[0055] Figure 5 This is the flight control system event tree simulation process provided by the present invention.

[0056] Figure 6 The present invention provides a flight control system probabilistic time automaton UPPAAL model.

[0057] Figure 7 This is the simulation result of the UPPAAL model of the flight control system probabilistic timed automaton provided by the present invention.

[0058] Figure 8 This is the simulation result of the PRISM model of the flight control system probability model provided by the present invention.

[0059] Figure 9 This is the simulation result of the STORM model of the flight control system probability model provided by the present invention. DETAILED DESCRIPTION

[0060] In order to enable the above-mentioned objects, features and advantages of the present application to be clearer, the present application will be described in further detail below with reference to the accompanying drawings and specific embodiments. It should be noted that the embodiments of the present application and the features in the embodiments can be combined with each other without conflict. In addition, the present application can also be implemented in other manners different from those described herein, and therefore the protection scope of the present application is not limited by the specific embodiments disclosed below.

[0061] Most of the current formal analysis and verification methods focus on the analysis and verification of non-probabilistic properties such as logical correctness and functional completeness, but lack the ability to analyze probabilistic properties. Non-probabilistic formal methods (such as model checking) cannot handle random uncertainty and can only verify whether the design meets non-probabilistic properties such as logical or temporal constraints, and lack effective measures for uncertainty and random failure.

[0062] The method provided by the present application can improve the comprehensiveness and accuracy of verification by comprehensively considering probabilistic and non-probabilistic properties and deeply analyzing multiple models and their internal relationships, in view of the lack of verification of probabilistic properties, the limitations of single model analysis, and the problem of insufficient detection in the current model-based flight control system analysis and verification process.

[0063] In order to illustrate the effectiveness of the method proposed by the present application, the above technical solutions of the present application will be described in detail below through a specific embodiment, as shown in the accompanying drawings, a multi-model-based flight control system probabilistic and non-probabilistic cross-domain hybrid analysis and verification method is disclosed, and the specific implementation steps are as follows: Figure 1

[0064] Step S1, determine preliminary safety requirements from typical failure cases of multiple different control systems, wherein the preliminary safety requirements include general safety requirements and special safety requirements;

[0065] In this step, a plurality of safety requirements in multiple fields are formed by collecting and summarizing a plurality of typical failure case sets of control system software in different fields, wherein the multiple fields can include, for example, flight control system software, other control system software, etc., which can be listed as field 1, field 2, …, and the common requirements for system safety in these fields are summarized to form the general safety requirements through cross-domain knowledge fusion.

[0066] Suppose the number of fields is n, and the safety requirements of each field i are represented as a set R i , i = 1, 2, …, n. Then the general safety requirements R universal are the intersection of all field sets, and the expression is:

[0067]

[0068] ​The unique security requirements of each field are summarized to form the special security requirements. For each field i, its special security requirements R special,i It can be expressed as:

[0069]

[0070] Among them, T j→i (·) represents the transfer function that transfers and adapts the requirements of domain i to domain j, R i -R universal represents the unique requirements of domain i, ∪ j≠i T j→i (R j -R universal ) represents the requirements transferred from other domains and adapted to domain i.

[0071] Step S2: Perform knowledge transfer on the preliminary safety requirements to obtain flight control system safety requirements; determine key risk requirements of the flight control system based on existing flight control system failure cases and flight control system documentation.

[0072] In this step, the process expression of performing knowledge migration on the preliminary security requirements is:

[0073] R special,k =Q(R universal ,R special,i ,M k )

[0074] Among them, R special,k Indicates the safety requirements of flight control system type k equipment, M k Indicates proprietary information and key risk requirements for flight control system type k equipment. universal ,R special,i ,M k ) represents the general safety requirement R universal and special safety requirements R special,i Based on M k Perform knowledge transfer processing.

[0075] Through the above processing, the safety requirements for the flight control system are obtained.

[0076] In some embodiments, the key risk requirements of the flight control system include key risk requirements for state switching problems in the flight control system, and the key risk requirements for state switching problems include requirements for airspeed, throttle position, barometric altitude indication and radio altitude value.

[0077] Step S3: performing safety specification generation, dynamic simulation analysis, and safety attribute verification processing on the flight control system safety requirements and the flight control system key risk requirements to obtain a non-probabilistic analysis attribute verification result;

[0078] In this step, first, the safety requirements and key risk requirements of the flight control system are analyzed, and the XSTAMPP software is guided to perform automated analysis based on the STAMP theory system risk analysis to generate safety regulations.

[0079] The security specifications automatically generated by the XSTAMPP software are then used as input to the timed automaton software UPPAAL. Based on timed automaton theory, a dynamic simulation analysis of the model level is performed to obtain the property verification results, which can be either passed or failed. If the property verification fails, a counterexample path is provided.

[0080] Verify the security attributes of the security specification at the code level using the ESBMC software tool to obtain a property verification result, including a pass or fail result;

[0081] Finally, the attribute verification results obtained by UPPAAL simulation and the attribute verification results obtained by ESBMC software detection are combined to obtain the final attribute verification results of the non-probabilistic analysis.

[0082] Step S4: performing a multi-model failure probability analysis on the flight control system safety requirements and the flight control system key risk requirements to obtain a multi-model failure probability;

[0083] In this step, based on the safety requirements and key risk requirements of the flight control system, a probability analysis is performed from a fault perspective, a dynamic behavior perspective, and a state transition perspective.

[0084] In terms of the fault perspective:

[0085] Based on the flight control system safety requirements and the flight control system's key risk requirements, the probability values ​​of various events occurring in the flight control system and the AND / OR relationships between fault events are determined to construct an event tree. The bottom events of the event tree are set to the values ​​of multiple input variables of the flight control system and the correctness of each of the input variables, and the top events of the event tree are set to the events of the correct output of the flight control system.

[0086] In some embodiments, the present invention can model the behavior of the flight control system as a Simulink model, which is a StateFlow model. The input of the Simulink model includes the system ground state, radio altitude, barometric altitude, airspeed, wheel load, and valid sensor identification. The model output is the ground state and leveling state identification.

[0087] By analyzing the constructed event tree and calculating the probability of the top event occurring, the effect of fault probability analysis can be achieved.

[0088] In some embodiments, the present invention may use Isograph software or AnyLogic software to analyze the event tree, calculate the probability of occurrence of the top event, and obtain the probability of occurrence of the fault from the fault perspective.

[0089] In terms of the dynamic behavior perspective:

[0090] The behavior model of the flight control system is modeled as an UPPAAL SMC model. In the specific implementation, the Simulink model (StateFlow model) can be converted into an UPPAAL SMC model, and the UPPAAL SMC model is used to perform probability property verification to obtain the fault probability calculated by the UPPAAL SMC model.

[0091] The established UPPAAL SMC model is automatically converted into a PRISM model, and the probability attribute verification is performed using PRISM's own verifier to obtain the failure probability calculated by the PRISM model.

[0092] The specific steps of the present invention for automatically converting the UPPAAL SMC model into the PRISM model are as follows:

[0093] (1) Map each state in the UPPAAL SMC model to a state in the PRISM model;

[0094] (2) Using global variables and Boolean flags to simulate the clock constraints and synchronization of the UPPAAL SMC model in the PRISM model;

[0095] (3) Each UPPAAL SMC model transformation is mapped to a probability transformation in the PRISM model, and the state transition and probability of the original model are retained, and finally the PRISM model is obtained.

[0096] Use the built-in algorithms of the PRISM tool to verify the security properties of the input PRISM model. The core of PRISM verification is to calculate the target properties. Whether the given probability conditions are met, namely:

[0097]

[0098] Indicates that before reaching a certain state, the property The probability of occurrence does not exceed q.

[0099] Based on pre-defined transitions and probabilities, the probability of an event occurring is calculated by analyzing the model state transition matrix.

[0100]

[0101] Among them, S init is the initial state set, π(s) is the initial state probability distribution, Indicates that the calculation starts from state s and meets the property probability.

[0102] The PRISM model is used as the input of the STROM model, and the probability attribute is verified by the STROM model verifier to obtain the fault occurrence probability calculated by the STROM model.

[0103] From the state transition perspective:

[0104] The behavior of the flight control system is modeled by a Markov chain using the mCRL2 verification tool. Based on the calculation of the relevant probability and occurrence relationship of the faults / events in the Markov chain, the fault occurrence probability calculated by the mCRL2 verification tool is obtained.

[0105] Finally, the failure probability from the fault perspective, the failure probability calculated by the UPPAAL SMC model, the failure probability calculated by the PRISM model, the failure probability calculated by the STROM model, and the failure probability calculated by the mCRL2 verification tool are collectively taken as the multi-model failure probability.

[0106] Step S5: taking the non-probabilistic analysis attribute verification result and the multi-model fault occurrence probability together as the analysis and verification result of the flight control system.

[0107] In this step, the non-probabilistic analysis attribute verification result and the fault occurrence probability are combined to obtain a multi-model probabilistic / non-probabilistic hybrid analysis verification result, thereby achieving the goal of improving system safety design.

[0108] In order to verify the effectiveness of the multi-model-based probabilistic and non-probabilistic cross-domain hybrid analysis verification method proposed in this paper, the proposed method was experimented on a real case. The specific experimental environment and experimental results are as follows:

[0109] This practical application will focus on a specific aircraft flight control system (a complex, dynamic, and concurrent system). This flight control system was developed entirely based on a Simulink model. By converting the Simulink model into C code and embedding it into a specific application environment, the system was validated for safety using the Simulink model's own verifier, Model Advisor, to ensure model correctness.

[0110] By analyzing typical accident case collections, historical system failure information, and system-related documentation, we can obtain the system's safety requirements and key risk requirements, such as state switching requirements.

[0111] Then, multi-model probability / non-probability mixed analysis verification is carried out. The specific steps are as follows:

[0112] (1) Non-probabilistic assessment

[0113] The non-probabilistic assessment mainly focuses on the state switching problem to detect safety issues. There are two state switches in this flight control system, specifically:

[0114] When the system is in state 1, if A∪(B∩C), then transition to state 2;

[0115] When the system is in state 2, if B∪(C∩D), then transition to state 1.

[0116] Based on the actual state switching situation described above, we first attempted to use the Z3 solver for a preliminary solution. The Z3 solver is a high-performance theorem prover and SMT (satisfiability modulo theory) solver, widely used in fields such as verification, analysis, and synthesis.

[0117] The Z3 solver is used to verify whether there are two conditions for state switching that are satisfied, that is, to verify whether the constraint (A∪(B∩C))∩(B∪(C∩D)) is possible. The verification results show that when the conditions (A=False, B=True, C=True, D=False) are met, the state will switch frequently and cannot reach a stable state, causing system failure. The timed automaton tool is used to verify whether the condition combination problem found will cause the problem of frequent state switching. It is found that during the UPPAAL simulation process, the system jumps back and forth between two states and cannot reach a stable state. Figure 4 As shown, that is, if the conditions are met, the system will fail.

[0118] (2) Multi-model validation of non-probabilistic evaluation

[0119] Considering that the credibility of the test results based on only one model is limited, and each model has its own advantages, we consider implementing mutual conversion between models to give full play to the advantages of various models and achieve the effect of multi-model verification.

[0120] Converting a Simulink model to a SCADE model: Export the Simulink model to JSON format, then import it into the SCADE Suite environment. Set the import options and configure the conversion. Then, start the conversion to generate the converted model. You can continue to adjust any unconverted features until the SCADE model is generated. The SCADE model will verify that there are no issues with the Simulink model.

[0121] Converting Simulink (StateFlow) models to UPPAAL models: Extract all states and transitions from the StateFlow model, parse these states and transitions, and generate the UPPAAL model. After converting the actual case model to the UPPAAL model, we found that there are indeed two situations that may cause frequent state switching:

[0122] Case 1: When the airspeed is between 100 and 200 km / h, if the throttle is in a low position, the pressure altitude indication is >20, and one of the two radio altimeters shows <0 and the other >10, frequent state switching may occur.

[0123] Case 2: When the airspeed is between 100 and 200 km / h, with more than two throttle levers in a low position of <5, and both the barometric pressure and radio altimeter indicate an altitude >20, if the wheel pressure sensor erroneously changes from 0 to 1, that is, from no pressure to pressure, it may cause frequent state switching.

[0124] (3) Probability assessment

[0125] Furthermore, by adding probabilistic attributes to events, the probability of events or failures occurring from a probabilistic perspective can be verified, which can be used to assist in decision-making in complex concurrent systems.

[0126] First, a mapping relationship between model inputs and outputs was established. Model inputs included the system's ground state, radio altitude, barometric altitude, airspeed, wheel load, and valid sensor identifiers. Model outputs included ground state and flare state identifiers. By converting the Simulink model, which consisted of physical signals, into an event tree model composed of events, the relationships between these events were established. Based on the characteristics of this flight control system (a complex concurrent system), a probabilistic model was developed to accurately calculate the probability of an event or fault occurring.

[0127] The output variable value relationship of the control system in this complex concurrent system is related to the execution of the control instruction of the aircraft itself, so the final output value of the control system needs to be focused on. The input of the Simulink model and the correctness of each input are taken as the bottom event of the event tree, the correct output event of the Simulink model is taken as the top event of the event tree, the tree-like result of the event tree is constructed according to the logic calculation of the Simulink model, and the final event tree is obtained.

[0128] Event tree simulation. According to the occurrence probability of the relevant bottom event in the flight control system, the probability of the occurrence of the top event is calculated by AnyLogic software, and the simulation process is as shown in Figure 5 The event tree simulation result shows that the probability of the occurrence of the top event is 0.994996393.

[0129] (4) Multi-model verification of probability evaluation

[0130] Conversion of event tree and time automaton. Based on the probability simulation of the event tree, the final probability of the occurrence of the top event can only be obtained by formulating the internal logic and defining the probability event, and the process in between is a black box. Moreover, how to ensure the accuracy of the event tree simulation result is a problem worth exploring. Considering this situation, the event tree is converted into a time automaton model, and the occurrence of the probability event is further simulated through the state, state transition and probability of transition occurrence. The UPPAAL model obtained by converting the event tree is as shown in Figure 6 The calculation result shows that the probability of the occurrence of the top event of the event tree is 0.950056, as shown in Figure 7 which is different from the event tree simulation result 0.994996393.

[0131] Conversion of time automaton and probability model. Realizing the difference between the model simulation results, it is necessary to convert the models between each other, migrate the state and transition relationship of the models, and effectively realize the simulation and calculation of the probability model by taking advantage of different models. The UPPAAL model is converted into a PRISM model, and the UPPAAL simulation is performed again, as shown in Figure 8 The calculation result of the PRISM model is 1.0.

[0132] Double verification of probability model. Further, the PRISM model is derived and input into the STROM model, and the event probability is further calculated by the STORM model. The verification result of the STORM model is as shown in Figure 9 The calculation result shows that the probability of the occurrence of the top event is 1.0.

[0133] (5) Multi-model probability / non-probability mixed analysis verification

[0134] Through multi-model hybrid analysis and verification using non-probabilistic and probabilistic models, we can not only obtain the results of the model's non-probabilistic property verification (safety property pass / fail verification, counterexample paths), but also determine the probability of the model's occurrence, providing support for decision-making in complex concurrent systems. Different models have different computational accuracy and advantages. Effectively integrating multiple models can effectively combine their strengths to obtain more accurate and comprehensive detection results.

[0135] From the actual application of the above-mentioned aircraft flight control system, it can be seen that the method provided by the present invention can well realize the detection and evaluation of the safety issues of the system, and has theoretical and practical application value.

[0136] Although the specific embodiments of the present invention depict various actions or steps in a specific order, this should be understood as requiring such actions or steps to be performed in the specific order shown or in a sequential order, or requiring that all illustrated actions or steps should be performed to obtain the desired results. Under certain circumstances, multitasking and parallel processing may be advantageous. Similarly, although a number of specific implementation details are included in the above discussion, these should not be interpreted as limiting the scope of this disclosure. Certain features described in the context of separate embodiments can also be implemented in combination in a single implementation. Conversely, the various features described in the context of a single implementation can also be implemented in multiple implementations individually or in any suitable sub-combination. The above is only a preferred specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or replacements that can be easily thought of by any technician familiar with this technical field within the technical scope disclosed by the present invention should be covered within the scope of protection of the present invention.

[0137] The above description is only a preferred specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily thought of by any technician familiar with this technical field within the technical scope disclosed by the present invention should be covered by the scope of protection of the present invention.

Claims

1. A multi-model based probabilistic and non-probabilistic cross-domain hybrid analysis and verification method for flight control systems, characterized by: The following steps are involved: Step S1: determining preliminary safety requirements based on typical failure cases of various control systems, wherein the preliminary safety requirements include general safety requirements and specific safety requirements; Step S2: performing knowledge transfer on the preliminary safety requirements to obtain flight control system safety requirements; Determine the key risk requirements of the flight control system based on existing failure cases and flight control system documentation; Step S3: performing safety specification generation, dynamic simulation analysis, and safety attribute verification processing on the flight control system safety requirements and the flight control system key risk requirements to obtain a non-probabilistic analysis attribute verification result; Step S4: performing a multi-model failure probability analysis on the flight control system safety requirements and the flight control system key risk requirements to obtain a multi-model failure probability; Step S5: taking the non-probabilistic analysis attribute verification result and the multi-model fault occurrence probability as the analysis and verification result of the flight control system; The step S3 specifically includes: Step S3-1, analyzing the safety requirements and key risk requirements of the flight control system, guiding the XSTAMPP software to perform automated analysis based on the STAMP theory system risk analysis, and generating safety regulations; Step S3-2: Using the security specification as input to the timed automaton software UPPAAL, a dynamic simulation analysis of the model level is performed based on timed automaton theory to obtain a property verification result of UPPAAL, which may be a pass or fail result. When the property verification fails, a counterexample path is provided; Step S3-3: Verify the security attributes of the security specification at the code level using the ESBMC software tool to obtain an ESBMC attribute verification result, which may include a pass or fail result. Step S3-4: Merge the attribute verification result of the UPPAAL and the attribute verification result of the ESBMC to obtain the final attribute verification result of the non-probabilistic analysis; The step S4 specifically includes: Step S4-1, modeling the behavior of the flight control system as a Simulink model, wherein the input of the Simulink model includes the system ground state, radio altitude, barometric altitude, airspeed, wheel load, and valid sensor identification, and the model output is the ground state and leveling state identification; Step S4-2: Using the input of the Simulink model and the correctness of each input as the bottom event of the event tree, using the event of the correct output of the Simulink model as the top event of the event tree, and constructing a tree-like result of the event tree according to the logical calculation of the Simulink model to obtain an event tree; Step S4-3: Analyze the event tree using multiple models to obtain multi-model fault occurrence probabilities.

2. The multi-model-based probabilistic and non-probabilistic cross-domain hybrid analysis and verification method for a flight control system according to claim 1 is characterized in that: The step S1 specifically includes: Step S1-1: Collect and summarize typical fault case sets of control system software in multiple different fields to form security requirements in multiple fields, and integrate the security requirements in multiple fields into cross-domain knowledge to form the general security requirements; Step S1-2: Summarize the unique security requirements of each of the multiple fields to form the dedicated security requirements.

3. The multi-model-based probabilistic and non-probabilistic cross-domain hybrid analysis and verification method for a flight control system according to claim 2, characterized in that: The step S1-1 specifically includes: Set the number of fields to , each field The security requirements are expressed as a set , , general safety requirements is the intersection of all domain sets, expressed as: The step S1-2 specifically includes: Special security requirements for Expressed as: in, Indicates that the field The requirements are transferred and adapted to the field The transfer function, Representation field The unique requirements of Indicates transfer from other fields and adaptation to the field requirements.

4. The multi-model-based probabilistic and non-probabilistic cross-domain hybrid analysis and verification method for a flight control system according to claim 3 is characterized in that: In step S2, knowledge transfer is performed on the preliminary safety requirements to obtain the expression of the flight control system safety requirements: in, Indicates the flight control system model k Safety requirements for equipment, Indicates the flight control system model k Proprietary information and key risk requirements of the equipment; Indicates general security requirements and fields Special security requirements for based on Conduct knowledge transfer processing; The key risk requirements for the flight control system include key risk requirements for state switching issues in the flight control system, and the key risk requirements for state switching issues include requirements for airspeed, throttle position, barometric altitude indication and radio altitude value.

5. The multi-model-based probabilistic and non-probabilistic cross-domain hybrid analysis and verification method for a flight control system according to claim 4 is characterized in that: The step S4-3 specifically includes: Step S4-3-1, using Isograph software or AnyLogic software to analyze the event tree, calculate the probability of occurrence of the top event, and obtain the probability of occurrence of the fault from the fault perspective; Step S4-3-2: convert the Simulink model into a UPPAAL SMC model, perform probability attribute verification using the UPPAAL SMC model, and obtain the probability of failure calculated by the UPPAAL SMC model; Step S4-3-3: automatically convert the UPPAAL SMC model into a PRISM model, perform probability attribute verification using the PRISM verifier, and obtain the probability of failure calculated by the PRISM model; Step S4-3-4: using the PRISM model as the input of the STROM model, performing probability attribute verification through the STROM model verifier to obtain the probability of failure calculated by the STROM model; Step S4-3-5: Use the mCRL2 verification tool to perform Markov chain modeling on the behavior of the flight control system, and calculate the relevant probability and occurrence relationship of the faults / events in the Markov chain to obtain the fault occurrence probability calculated by the mCRL2 verification tool; Step S4-3-6: The failure probability from the fault perspective, the failure probability calculated by the UPPAAL SMC model, the failure probability calculated by the PRISM model, the failure probability calculated by the STROM model, and the failure probability calculated by the mCRL2 verification tool are collectively used as the multi-model failure probability.

6. The multi-model-based probabilistic and non-probabilistic cross-domain hybrid analysis and verification method for a flight control system according to claim 5, characterized in that: In step S4-3-3, the specific steps of automatically converting the UPPAAL SMC model into the PRISM model include: (1) Map each state in the UPPAAL SMC model to a state in the PRISM model; (2) Using global variables and Boolean flags to simulate the clock constraints and synchronization of the UPPAAL SMC model in the PRISM model; (3) Each UPPAAL SMC model transformation is mapped to a probability transformation in the PRISM model, and the state transition and probability of the original model are retained, and finally the PRISM model is obtained.

Images