Flight control system probability and non-probability cross-domain hybrid analysis verification method based on multiple models

Abstract

The invention relates to the technical field of formalized analysis and verification, 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 initial safety requirements according to typical fault cases of various different control systems, and performing knowledge migration on the initial safety requirements; the safety requirement of the flight control system is obtained; determining key risk requirements of the flight control system according to existing fault cases of the flight control system and document data of the flight control system; processing the flight control system safety requirement and the flight control system key risk requirement to obtain a non-probability analysis attribute verification result; analyzing the flight control system safety requirement and the flight control system key risk requirement to obtain a multi-model fault occurrence probability; an analysis verification result of the flight control system is obtained; according to the method, the sufficiency and completeness of analysis and verification of the flight control system can be improved.

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 model-based flight control systems includes development and testing phases. The development phase defines product specifications and requirements, conducts basic design, specifies design details, and develops prototypes; the testing phase tests the performance of each component and the system as a whole, conducts system-level testing and improves market demand, and obtains results through control models or codes.

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

[0004] The first is that models are used to describe system requirements and designs. This development method uses use case diagrams, sequence diagrams, etc. to guide code development. However, in actual applications, model building and code development are often not done by the same person, which easily leads to inconsistencies between models and codes.

[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 problems, business problems of state transitions, or deep division by zero problems. On the other hand, the model's own 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 a variety of 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 prior art, 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 a plurality of 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 the safety requirements of the flight control system; determine the key risk requirements of the flight control system based on the existing failure cases of the flight control system and the documents of the flight control system;

[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 failure probability analysis of multiple models on the safety requirements of the flight control system and the key risk requirements of the flight control system 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 verification result of the flight control system.

[0013] Preferably, the step S1 specifically includes:

[0014] Step S1-1, collecting and summarizing typical fault case sets of control system software in multiple different fields to form security requirements in multiple fields, and integrating the security requirements in multiple fields through 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 represented 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 requirement to obtain an expression of the flight control system safety requirement:

[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 the 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 of the flight control system and the key risk requirements of the flight control system, guiding the XSTAMPP software to perform automated analysis through system risk analysis based on STAMP theory, and generating safety regulations;

[0028] Step S3-2: using the security specification as the input of the timed automaton software UPPAAL, performing a dynamic simulation analysis of the model level based on the timed automaton theory, and obtaining the attribute verification result of UPPAAL, the result includes passing or failing. When the attribute verification fails, a counterexample path is given;

[0029] Step S3-3, verifying the security attributes of the security specification at the code level through the ESBMC software tool to obtain the ESBMC attribute verification result, which includes pass or fail;

[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 identification of the sensor, and the model output is the ground state and leveling state identification;

[0033] Step S4-2, taking the input of the Simulink model and the correctness of each input as the bottom event of the event tree, taking the event of the correct output of the Simulink model as the top event of the event tree, and constructing a tree 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, converting the Simulink model into a UPPAAL SMC model, using the UPPAAL SMC model to perform probability attribute verification, and obtaining the probability of failure calculated by the UPPAAL SMC model;

[0038] Step S4-3-3, automatically converting the UPPAAL SMC model into a PRISM model, using the PRISM verifier to perform probability attribute verification, and obtaining 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, and obtaining the fault occurrence probability calculated by the STROM model;

[0040] Step S4-3-5, using the mCRL2 verification tool to perform Markov chain modeling on the behavior of the flight control system, and calculating the relevant probability and occurrence relationship of the fault / event of 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 failure 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) Use 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 transitions and probabilities of the original model are retained, finally obtaining the PRISM model.

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

[0047] (1) The multi-model probability and non-probability cross-domain hybrid flight control system verification method provided by the present invention can effectively detect the non-probability properties of the model-based software system, solving the problem of insufficient detection at the traditional model level. Through the method of converting the model to code and then converting the code to the model, the inconsistency between the model and the 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) The present 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. Combining historical fault information, knowledge from other fields, and the results of different model detections, the accuracy and precision of the detection results are improved.

[0049] (3) The present invention can not only detect the basic functions of the flight control system within a limited time, but also detect the implicit deadlock, state space switching disorder, system boundary test and division by zero problems of the flight control system. By testing the safety requirements through multiple non-probabilistic models and multiple probabilistic models, in addition to providing qualitative evaluations (such as pass / fail), quantitative evaluations (such as the probability of an event occurring) can also be provided, which is significantly better than the single model detection method. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0052] Figure 2 Schematic diagram of the probability and non-probability cross-domain hybrid analysis and verification method for a flight control system based on multiple models provided by the present invention;

[0053] Figure 3 A flow chart 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 time 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] Fig. 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 more clearly understand the above-mentioned purpose, features and advantages of the present invention, the present invention is further described in detail below in conjunction with the accompanying drawings and specific embodiments. It should be noted that, in the absence of conflict, the embodiments of the present invention and the features in the embodiments can be combined with each other. In addition, the present invention can also be implemented in other ways different from those described herein, and therefore, the protection scope of the present invention is not limited by the specific embodiments disclosed below.

[0061] At present, most formal analysis and verification methods focus on the analysis and verification of non-probabilistic properties of logical correctness and functional completeness, but lack the ability to analyze their 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 logic or time constraints. There is a lack of effective measurement for uncertainty and random failures.

[0062] The method provided by the present invention aims to improve the comprehensiveness and accuracy of verification by comprehensively considering probability and non-probabilistic attributes, conducting in-depth analysis of multiple models and their internal connections, and addressing the problems of lack of verification of probability attributes, limitations of single model analysis, and 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 invention, the above technical solution of the present invention is described in detail below through a specific embodiment. Figure 1 As shown, a multi-model-based probability and non-probability cross-domain hybrid analysis and verification method for a flight control system is disclosed, and the specific implementation steps are as follows:

[0064] 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 special safety requirements;

[0065] In this step, typical fault case sets of control system software in multiple different fields are collected and summarized to form safety requirements in multiple fields. The multiple fields may include, for example, flight control system software, other control system software, etc., which can be listed as field one, field two, ... The common requirements for system safety in these fields are integrated through cross-domain knowledge to summarize and form the general safety requirements.

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

[0067]

[0068] The unique security requirements of each field are summarized to form the dedicated security requirements. For each field i, its dedicated 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 the safety requirements of the flight control system; determine the key risk requirements of the flight control system based on the existing failure cases of the flight control system and the documentation of the flight control system.

[0072] In this step, the process expression of knowledge migration of 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 the proprietary information and key risk requirements of 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 Carry out 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 of the flight control system and the key risk requirements of the flight control system are analyzed, and the XSTAMPP software is guided to perform automated analysis based on the system risk analysis of the STAMP theory to generate safety regulations;

[0079] Then, the security specification automatically generated by XSTAMPP software is used as the input of timed automaton software UPPAAL. Based on the timed automaton theory, dynamic simulation analysis of the model level is performed to obtain the attribute verification results, which include pass or fail. When the attribute verification fails, a counterexample path is given.

[0080] The security specification is verified at the code level using the ESBMC software tool to obtain a property verification result, which includes 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 failure probability analysis of multiple models on the safety requirements of the flight control system and the key risk requirements of the flight control system to obtain a multi-model failure probability;

[0083] In this step, based on the safety requirements of the flight control system and the key risk requirements of the flight control system, 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 safety requirements of the flight control system and the key risk requirements of the flight control system, the probability values ​​of various events occurring in the flight control system and the AND / OR relationship of the occurrence of fault events are determined to construct an event tree. The bottom event of the event tree is set as multiple input variable values ​​of the flight control system and the correctness of each input variable, and the top event of the event tree is set as the event 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 identification of the sensor, and 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 a UPPAAL SMC model. In the specific implementation, the Simulink model (StateFlow model) can be converted into a UPPAAL SMC model, and the UPPAAL SMC model is used to perform probability attribute verification to obtain the fault occurrence 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) Use 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 transitions and probabilities of the original model are retained, finally obtaining the PRISM model.

[0096] Use the built-in algorithms of the PRISM tool to verify the safety 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 nature 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 as a Markov chain using the mCRL2 verification tool, and the probability of occurrence of the fault calculated by the mCRL2 verification tool is obtained based on the calculation of the relevant probability and occurrence relationship of the fault / event of the Markov chain.

[0105] Finally, the failure probability from the failure 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 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 probability / non-probabilistic hybrid analysis verification result, thereby achieving the goal of improving the 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 is experimented on a real case. The specific experimental environment and experimental results are as follows:

[0109] This practical application will be aimed at a certain type of aircraft flight control system (complex dynamic concurrent system). This flight control system is developed based on the Simulink model as a whole. By converting the Simulink model into C code and embedding it into a specific environment for application. In terms of safety testing, this flight control system is verified by the Simulink model's own verifier, the Model Advisor verifier, to ensure the correctness of the model.

[0110] By analyzing typical accident case sets, 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 evaluation

[0113] The non-probabilistic assessment mainly focuses on the detection of safety issues in state switching. There are two state switches in this flight control system. The specific contents are:

[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 above state switching situation, we first try to use the Z3 solver for preliminary solution. The Z3 solver is a high-performance theorem proving and SMT (satisfiability modulo theory) solver, which is widely used in 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 the system to fail. 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, such as 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 test results based on only one model are of limited credibility, 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] Convert Simulink model to SCADE model: Export the Simulink model to JSON format, then re-import it into SCADE Suite, set the import options and configure the conversion, then start the conversion to generate the converted model. The unconverted functions can be adjusted until the SCADE model is finally generated. The SCADE model detects no problem with the Simulink model.

[0121] Convert Simulink (StateFlow) model to UPPAAL model: Extract all states and transitions from the StateFlow model, parse these states and transitions, and generate UPPAAL model. After converting the model in the actual case to UPPAAL model, it is 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 at 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, and more than 2 throttle levers are in a low position of <5, and both the barometric pressure and radio altimeter show an altitude of >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 help decision-making in complex concurrent systems.

[0126] First, the mapping relationship between model input and output is established. The model input includes the system ground state, radio altitude, pressure altitude, airspeed, wheel load, and valid identification of various sensors. The model output is the ground state and leveling state identification. By converting the Simulink model composed of physical signals into an event tree model composed of events, the relationship between events is established, and according to the characteristics of this flight control system (complex concurrent system), a probability model is established to accurately calculate the probability of events or faults.

[0127] Construct an event tree. The output variable value of the control system in this complex concurrent system is related to the execution of the control instructions of the aircraft itself. Therefore, it is necessary to focus on the final output value of this control system. The input of the Simulink model and the correctness of each input are used as the bottom event of the event tree, and the event of the correct output of the Simulink model is used as the top event of the event tree. The tree result of the event tree is constructed according to the logical calculation of the Simulink model to obtain the final event tree.

[0128] Event tree simulation. Based on the probability of occurrence of related bottom events in the flight control system, the probability of occurrence of the top event is calculated by AnyLogic software. The simulation process is as follows: Figure 5 The event tree simulation results show that the probability of the top event occurring is 0.994996393.

[0129] (4) Multi-model validation of probability assessment

[0130] Conversion between event tree and timed automaton. Based on the probability simulation of event tree, it can only obtain the probability of the final top event through the formulation of internal logic and the definition of probability events. The intermediate process is a black box; and how to ensure the accuracy of the event tree simulation results is a problem worth exploring. Considering this situation, the event tree is converted into a timed automaton model, and the occurrence of simulation probability events is further simulated through states, state transitions, and the probability of transitions. The UPPAAL model obtained by converting the event tree is as follows: Figure 6 The calculation results show that the probability of the top event of the event tree is 0.950056. Figure 7 As shown, it is different from the simulation result of the number of events 0.994996393.

[0131] Conversion between timed automata and probability models. To realize the difference in model simulation results, it is necessary to convert between models, migrate the states and transition relationships of the models, and effectively realize the simulation and calculation of probability models by taking advantage of the advantages of different models. Convert the timed automata model UPPAAL to the probability model PRISM, and re-simulate UPPAAL, such as Figure 8 As shown, the result calculated by the PRISM model is 1.0.

[0132] Double verification of the probability model. Further, the probability model was double verified. The PRISM model was exported and input into the STORM model. The event probability was further calculated through the STORM model. The verification results of the STORM model are shown in the figure. Fig. 9 As shown, the probability of the top event occurring is calculated to be 1.0.

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

[0134] Through multi-model hybrid analysis and verification of non-probabilistic and probabilistic models, we can not only obtain the results of the non-probabilistic attribute verification of the model (safety attribute verification pass / fail, counterexample path), but also obtain the probability of the model occurring, providing support for decision-making in complex concurrent systems. Different models have different computational accuracy and advantages. Effective integration of multiple models can effectively combine the advantages of multiple models to obtain more accurate and comprehensive detection results.

[0135] It can be seen from the actual application of the above-mentioned certain type of aircraft flight control system 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 all illustrated actions or steps to be performed to obtain the desired results. Under certain circumstances, multitasking and parallel processing may be advantageous. Similarly, although several specific implementation details are included in the above discussion, these should not be interpreted as limiting the scope of the present disclosure. Certain features described in the context of a separate embodiment can also be implemented in a single implementation in combination. On the contrary, 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 protection scope of the present invention is not limited thereto. Any changes or replacements that can be easily thought of by any technician familiar with the technical field within the technical scope disclosed by the present invention should be covered within the protection scope of the present invention.

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

Claims

1. A multi-model based probability and non-probabilistic cross-domain hybrid analysis and verification method for a flight control system, characterized in that: 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 special safety requirements; Step S2: performing knowledge transfer on the preliminary safety requirements to obtain the safety requirements of the flight control system; Determine the key risk requirements of the flight control system based on the existing failure cases and documentation of the flight control system; 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 failure probability analysis of multiple models on the safety requirements of the flight control system and the key risk requirements of the flight control system to obtain a multi-model failure probability; Step S5: taking the non-probabilistic analysis attribute verification result and the multi-model fault occurrence probability together as the analysis verification result of the flight control system.

2. The method for probabilistic and non-probabilistic cross-domain hybrid analysis and verification of a flight control system based on multiple models according to claim 1 is characterized in that: The step S1 specifically includes: Step S1-1, collecting and summarizing typical fault case sets of control system software in multiple different fields to form security requirements in multiple fields, and integrating the security requirements in multiple fields through 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 probability and non-probability cross-domain hybrid analysis and verification method for a flight control system according to claim 2 is characterized in that: The step S1-1 specifically includes: Assume that the number of domains is n, and the security requirements of each domain i are represented as a set R i , i=1,2,...,n, general safety requirement R universal is the intersection of all domain sets, expressed as: The step S1-2 specifically includes: the dedicated security requirement R of domain i special,i It can be expressed as: 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.

4. The method for probabilistic and non-probabilistic cross-domain hybrid analysis and verification of a flight control system based on multiple models according to claim 3 is characterized in that: In step S2, knowledge migration is performed on the preliminary safety requirements to obtain the expression of the flight control system safety requirements: R special,k =Q(R universal ,R special,i ,M k ) Among them, R special,k Indicates the safety requirements of the flight control system type k equipment, M k Indicates the proprietary information and key risk requirements of the 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; 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 method for probabilistic and non-probabilistic cross-domain hybrid analysis and verification of a flight control system based on multiple models according to claim 4 is characterized in that: The step S3 specifically includes: Step S3-1, analyzing the safety requirements of the flight control system and the key risk requirements of the flight control system, guiding the XSTAMPP software to perform automated analysis through system risk analysis based on STAMP theory, and generating safety regulations; Step S3-2: using the security specification as the input of the timed automaton software UPPAAL, performing a dynamic simulation analysis of the model level based on the timed automaton theory, and obtaining the attribute verification result of UPPAAL, the result includes passing or failing. When the attribute verification fails, a counterexample path is given; Step S3-3, verifying the security attributes of the security specification at the code level through the ESBMC software tool to obtain the ESBMC attribute verification result, which includes pass or fail; 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.

6. The multi-model-based probability and non-probability cross-domain hybrid analysis and verification method for a flight control system according to claim 5 is characterized in that: 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 identification of the sensor, and the model output is the ground state and leveling state identification; Step S4-2, taking the input of the Simulink model and the correctness of each input as the bottom event of the event tree, taking the event of the correct output of the Simulink model as the top event of the event tree, and constructing a tree 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.

7. The multi-model based probability and non-probability cross-domain hybrid analysis and verification method for flight control system according to claim 6 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, converting the Simulink model into a UPPAAL SMC model, using the UPPAAL SMC model to perform probability attribute verification, and obtaining the probability of failure calculated by the UPPAAL SMC model; Step S4-3-3, automatically converting the UPPAAL SMC model into a PRISM model, using the PRISM verifier to perform probability attribute verification, and obtaining 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, and obtaining the fault occurrence probability calculated by the STROM model; Step S4-3-5, using the mCRL2 verification tool to perform Markov chain modeling on the behavior of the flight control system, and calculating the relevant probability and occurrence relationship of the fault / event of the Markov chain to obtain the fault occurrence probability calculated by the mCRL2 verification tool; Step S4-3-6, the failure probability from the failure 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.

8. The multi-model based probability and non-probability cross-domain hybrid analysis and verification method for flight control system according to claim 7 is 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) Use 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 transitions and probabilities of the original model are retained, finally obtaining the PRISM model.

Images