Complex software system multi-modal cross-language multi-layer verification formalized integration method

Abstract

The invention relates to the technical field of formalized analysis and verification of a complex software system, and particularly provides a multi-modal cross-language multilayer verification formalized integration method. According to the method, a multi-dimensional analysis and verification process from codes to models is realized through a code or model self verifier layer, a code or model plug-in verifier layer, a multi-language or multi-model conversion verification layer and a code and model bidirectional cross verification layer. The multi-level verification framework covers code static analysis, model dynamic simulation and cross-language and cross-model conversion, various formalized tools are systematically integrated, verification results of different languages and models are deeply integrated while automatic and efficient verification is achieved, on one hand, system compatibility and consistency are kept, and on the other hand, the verification efficiency is improved; on the other hand, the sufficiency and reliability of system analysis and verification are remarkably improved.

Description

Technical Field

[0001] The present invention relates to a formalized integrated method for multi-modal, cross-language and multi-layer verification of complex software systems. Background Art

[0002] Problems with the prior art in this field include:

[0003] (1) The verification method is single and cannot fully cover the multi-dimensional requirements of complex software systems

[0004] Traditional verification methods are usually single-level and lack a systematic multi-level verification framework. This method often only focuses on the verification of a specific aspect, which easily leads to verification blind spots and loopholes and cannot fully cover all levels of complex software systems. In complex software systems, a single verification method can often only solve problems at a specific level and cannot provide comprehensive system verification. This limitation may lead to unforeseen errors and failures in the actual operation of the system. The literature Jacklin S, Schumann J, Gupta P, et al. Verification, validation, and certification challenges for adaptive flight-critical control system software [C] / / AIAA Guidance, Navigation, and Control Conference and Exhibit. 2004: 5258 and the literature Ferrara P, Arceri V, Cortesi A. Challenges of software verification: the past, the present, the future [J]. International Journal on Software Tools for Technology Transfer, 2024: 1-10 also point out that traditional single verification methods often fail to capture complex interactions and potential concurrency issues between systems when dealing with multi-threaded and distributed systems. In the face of the problem of comprehensive system verification, the literature Raman R, Gupta N, Jeppu Y. Framework for Formal Verification of Machine Learning Based Complex System-of-Systems [J]. Insight, 2023, 26 (1): 91-102 proposed combining machine learning with formal methods, and proposed a novel method that combines machine learning classifiers and formal methods to analyze and evaluate the framework of emergent behaviors in complex systems. The paper points out that the emergent behavior of complex systems is generated by the interaction between various subsystems, and this behavior may be positive or negative. In order to cope with this complexity, the scheme develops a machine learning classifier model that can learn potential positive and negative emergent behaviors and predict the behavior that the system may exhibit. Subsequently, a formal verification model is used to confirm negative emergent behaviors. Although this method enhances performance through machine learning, the formal method is still single. This singleness may have blind spots and loopholes when dealing with the multi-dimensional requirements of complex software systems.Formal methods usually rely on mathematical models and logical reasoning to verify the correctness and robustness of the system. However, the emergent behavior of complex systems and the interactive characteristics between systems may lead to the explosion of the state space, making it difficult for a single formal verification method to fully cover all possible system behaviors. In addition, a single formal method has limitations in dealing with dynamic changes and uncertainties.

[0005] (2) Lack of effective cross-platform verification tools leads to limitations in verification results

[0006] In complex software systems in multi-language and multi-platform environments, existing verification tools can often only verify specific programming languages ​​or platforms and lack cross-platform verification capabilities. This limitation leads to inconsistent or incomplete verification results for different parts of complex software systems, especially in cross-language and cross-model verification, which often faces compatibility and inconsistency issues. In addition, there is a lack of effective tools and methods for conversion and verification between different languages ​​and models, resulting in unreliable verification results. Patent CN201911382582.3 made preliminary explorations in cross-platform verification by packaging user information and user data on different platforms into blocks and writing them into the blockchain to achieve cross-platform verification synchronization. However, this method mainly focuses on the data synchronization level rather than comprehensive system behavior verification. The literature Garcia M, Francesquini E, Azevedo R, et al. HybridVerifier: a cross-platform verification framework for instruction set simulators [J]. IEEE Embedded Systems Letters, 2017, 9 (2): 25-28 proposed a cross-platform verification framework for instruction set simulators. This framework implements the reliability and correctness verification of instruction set simulators by performing cross-memory checks in a heterogeneous instruction set architecture environment. Then, HybridVerifier mainly focuses on the verification of instruction set simulators. Although some progress has been made in cross-platform verification, its application scope is relatively limited, mainly focusing on the verification of processor models and compilers. Therefore, in terms of cross-platform verification tools for complex software systems, there is still a lack of multi-dimensional solutions to ensure the reliability and credibility of verification results.

[0007] (3) Existing verification process lacks automation and integration

[0008] In the current field of software testing and verification, insufficient automation and integration is a significant challenge. Traditional verification tools often lack effective automated coordination mechanisms when dealing with multiple verification stages of complex software systems. This results in a large amount of manual intervention in the verification process, which is not only time-consuming and labor-intensive, but also prone to human errors. In addition, the use of formal tools is usually isolated and lacks deep integration and automated processes. The document Bertolino A. Software testing research: Achievements, challenges, dreams [C] / / Future of Software Engineering (FOSE'07). IEEE, 2007: 85-103 discusses the challenges in the field of software testing and verification, and points out the deficiencies of existing tools in automation and integration. The document mentions that although some progress has been made in test automation, these tools are often limited to specific application scenarios and lack broad practicality and flexibility. On the other hand, the document Garousi V, MV. When and what to automate in software testing? A multi-vocal literature review [J]. Information and Software Technology, 2016, 76: 92-117 discusses the automation of software testing and verification in depth. The article points out that although automated testing tools can significantly improve test efficiency and coverage, in practical applications, the degree of automation and timing selection are still complex issues. Many organizations face technical and process barriers when implementing automation, resulting in unsatisfactory automation results. In summary, the research on formal integrated verification automation analysis technology is still in the stage of continuous development and improvement. Especially in the verification of complex software systems, how to effectively coordinate and integrate different verification stages and tools is a technical problem that needs to be solved urgently. Summary of the invention

[0009] According to one aspect of the present invention, a formal integrated method for multi-modal, cross-language, and multi-layer verification of a complex software system is provided, which is characterized by comprising:

[0010] When the object to be analyzed is code, perform the following operations:

[0011] A1) Perform code self-verification. Perform code self-verification on the code to be analyzed to ensure the basic quality and security of the code, including:

[0012] Use code static analysis tools to identify basic syntax errors,

[0013] Use code quality detection tools to ensure content management and execution efficiency, and use code security verification tools to check for potential vulnerabilities and threats.

[0014] A2) Perform code plug-in verification, including: using the code plug-in verifier to conduct a deeper analysis of the code, identifying code duplication and complexity through the structure optimization plug-in, checking interface consistency through the cross-platform compatibility plug-in, and identifying state switching in the code through the state transition plug-in, so as to provide more accurate verification results.

[0015] A3) Perform cross-language verification, including: converting the code to be analyzed into another language for multi-language analysis, such as converting C code into C++ for performance optimization, or into Python for rapid prototyping and flexibility testing, thereby leveraging the ecosystem and tool chain of multiple languages ​​to expand verification,

[0016] A4) Perform code-to-model verification, including: converting the code to be analyzed into a model for further verification, using model analysis tools such as UPPAAL to analyze and verify the timing model to ensure the timing behavior of the system, or using PRISM to analyze the probability model to evaluate the reliability and failure probability of the system, thereby abstracting the code behavior into a verifiable model.

[0017] When the object to be analyzed is a model, perform the following operations:

[0018] B1) Perform model self-verification, including: self-verification of the model to be analyzed, using the verification tools provided by the model framework to perform self-verification, such as consistency verification tools to ensure the integrity of state diagrams and flow charts, and constraint checking tools to ensure that design specifications are not violated, thereby ensuring the rationality and standardization of the preliminary design,

[0019] B2) Perform model plug-in validator verification, including: Extended verification of the model through the model plug-in validator, using plug-ins such as the SPIN tool to further discover deadlock (a process or thread in the system enters a permanent waiting state when waiting for certain conditions to be met), livelock (a situation where the system is constantly changing states but does not perform any useful work), and security (whether security properties are violated) issues, ensuring that the system behavior complies with the design specifications and helping developers quickly locate problems, thereby improving the reliability and security of the model.

[0020] B3) Perform cross-model verification, including: converting the model to be analyzed into other model formats for diversified verification, such as converting the model into NuSMV for formal verification and logical reasoning, or converting it into UPPAAL model to enhance the accuracy of timing verification, so as to cover the performance and properties under different modeling methods,

[0021] B4) Model-to-code verification: The model is converted into code form and further analyzed using code-side verification tools. Static analysis tools are used to check the performance of the converted code in the target language, and dynamic analysis tools are used to simulate system operation and identify reactions in real scenarios, thereby ensuring that the model can be accurately converted into an executable form and verifying its authenticity and practicality.

[0022] According to a further aspect of the present invention, in the above-mentioned complex software system multi-modal cross-language multi-layer verification formal integration method, the overall verification function is defined as V total , the code side verification process is V code , the model-side verification process is V model , then:

[0023] V total =V code ∪V model

[0024] The overall verification will be the code verification process (V code ) and model validation process (V model ), that is, the system can be in code form or model form, and the verification process will select the corresponding verification process according to the form of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 It is a schematic diagram of the formal integrated method for multi-modal, cross-language, and multi-layer verification of complex software systems;

[0026] Figure 2 It is an example of the aircraft status switching code of the flight control system;

[0027] Figure 3 It is the result of Python's own verifier verifying the correctness of the aircraft state transition;

[0028] Figure 4 It is the UML state diagram of the flight control system state transition;

[0029] Figure 5 It is the simulation result of the flight control system using EnterpriseArchitect software tool;

[0030] Figure 6 It is the result of Pylint plug-in tool detecting Python code;

[0031] Figure 7 It is the SPIN syntax check verification result;

[0032] Figure 8 It is the SPIN redundancy check verification result;

[0033] Fig. 9 It is the SPIN model validation test result;

[0034] Fig.10 It is the verification result of C++ language by CPPcheck tool;

[0035] Fig.11 It is the Petri net modeling diagram of CPIN IDE tool;

[0036] Fig.12 It is the result of the simulation of the initial state of the Petri net by the CPIN IDE tool;

[0037] Fig.13 It is the execution process of Petri net state simulation by CPIN IDE tool;

[0038] Fig.14 It is the final result of the CPIN IDE tool executing the Petri net state simulation;

[0039] Fig.15 It is the result of executing the Petri net model replication by the CPINIDE tool;

[0040] Fig.16 It is a state diagram generated by Graphviz software parsing Python code;

[0041] Fig.17 It is the UPPAAL timed automaton model generated by Python code parsing;

[0042] Fig.18 It is the model checking result of UPPAAL timed automaton model;

[0043] Fig.19 It is the result of direct compilation and verification of the JAVA language converted from the UML state diagram;

[0044] Fig. 20 It is the compilation verification result after the UML state diagram is converted into JAVA code and modified manually;

[0045] Fig.21 It is the compiled and executed result after the UML state diagram is converted into C++ code and manually corrected;

[0046] Fig. 22 It is the C++ compilation and execution result considering the transition between Landing state and Ground state;

[0047] Fig.23 It is the result of converting the UML state diagram directly into Python code and compiling and testing it;

[0048] Fig.24 It is the Python code compilation test result after considering the transition between Landing state and Ground state;

[0049] Fig.25 It is the case execution process of the multi-modal, cross-language, and multi-layer verification method for the flight control system state transition. DETAILED DESCRIPTION

[0050] According to an embodiment of the present invention, a complex software system multi-modal cross-language multi-layer verification formal integration method is as follows Figure 1 As shown, it includes two cases. In the first case, the object to be analyzed is code, and in the second case, the object to be analyzed is a model.

[0051] (1) The object to be analyzed is code (code side)

[0052] The first step is to verify the code itself with a validator: perform self-validation on the code to be analyzed, using verification tools designed specifically for the code language, such as static analysis tools to identify syntax and logic errors, code quality detection tools to ensure content management and execution efficiency, and security verification tools to check for potential vulnerabilities and threats, thereby ensuring the basic quality and security of the code.

[0053] The second step is code plug-in verifier verification: use the code plug-in verifier to perform a deeper analysis of the code, through plug-ins such as structure optimization plug-ins to identify code duplication and complexity, cross-platform compatibility plug-ins to check interface consistency, and state transition plug-ins to identify state switches in the code, thereby providing more accurate verification results.

[0054] The third step is cross-language verification: convert the code to be analyzed into another language for multi-language analysis, such as converting C language code into C++ for performance optimization, or converting it into Python for rapid prototyping and flexibility testing, thereby leveraging the ecosystem and tool chain of multiple languages ​​to expand verification.

[0055] The fourth step is code-to-model verification: convert the code to be analyzed into a model for further verification, use model analysis tools such as UPPAAL to analyze and verify the timing model to ensure the timing behavior of the system, or use PRISM to analyze the probabilistic model to evaluate the reliability and failure probability of the system, thereby abstracting the code behavior into a verifiable model.

[0056] (2) The object to be analyzed is a model (model side)

[0057] The first step is model self-verification: the model to be analyzed is self-verified, using the verification tools provided by the model framework, such as consistency verification tools to ensure the integrity of state diagrams and flow charts, and constraint checking tools to ensure that design specifications are not violated, thereby ensuring the rationality and standardization of the preliminary design.

[0058] The second step is model plug-in validator verification: the model is extended to be verified through the model plug-in validator. Using plug-ins such as the SPIN tool, you can further discover deadlocks, unreachable states, and security and liveness properties to ensure that the system behavior meets the design specifications and help developers quickly locate them, thereby improving the reliability and security of the model.

[0059] The third step is cross-model verification: convert the model to be analyzed into other model formats for diversified verification, such as converting the model into NuSMV to facilitate formal verification and logical reasoning, or converting it into a UPPAAL model to enhance the accuracy of timing verification, thereby covering the performance and properties under different modeling methods.

[0060] The fourth step is model-to-code verification: the model is converted into code form and further analyzed using code-side verification tools. Static analysis tools are used to check the performance of the converted code in the target language, and dynamic analysis tools are used to simulate system operation and identify reactions in real scenarios, thereby ensuring that the model can be accurately converted into an executable form and verifying its authenticity and practicality.

[0061] Among them, the overall verification function is defined as V total , the code side verification process is V code , the model-side verification process is V model , then:

[0062] V total =V code ∪V model

[0063] The overall verification will be the code verification process (V code ) and model validation process (V model ), that is, the system can be in code form or model form, and the verification process will select the corresponding verification process according to the form of the system. (1) Code-side analysis of specific execution process

[0064] Define C as the code to be analyzed, then:

[0065] Step 1: Define the code's own verification function as V c_self (·), the total number of verification tools is n, then the code self-verification can be expressed as:

[0066]

[0067] Where C represents the code to be analyzed, V c_self (C) represents the result of analyzing code C by the code verification tool. i represents the i-th verification tool, v i (C) Code is analyzed by the i-th verification tool, i.e., for a given code C, it will apply n different verification tools v i . It represents the union of the results of n different verification tools analyzing and verifying code C, that is, it integrates the results of multiple verifiers for code C. Only when all verifications are passed will the code be considered to have passed its own verification. If it fails, the specific location of the error will be given to assist in system modification.

[0068] The second step is to define the code plug-in verification function as V c_plugin (·), then the code plugin validator verification can be expressed as:

[0069]

[0070] Where C represents the code to be analyzed, V c_plugin (C) represents the result of analyzing code C using the plug-in verifier, j represents the jth plug-in verifier, m represents the total number of plug-in verifications of code C, p j (C) Code C is analyzed by the j-th verifier, represents the union of the analysis and verification results of code C by m plug-in validators. represents the th plug-in verification tool, using different plug-in verification tools to analyze. If the verification result fails, a detection report will be generated and the specific number of problem lines and the cause of the problem will be reported.

[0071] The third step is to define the cross-language verification function as V c_cross (·), then cross-language verification can be expressed as:

[0072]

[0073] Where C represents the code to be analyzed, V c_cross (C) represents the results of cross-language validation analysis of code C. k (·) represents the conversion function from code C to other target analysis languages ​​(such as C++, Python, etc.), L k (C) represents the conversion of code C into the target analysis language, l represents the number of target languages, and k represents the current language. c_self (L k (C)) means converting code C into the target analysis language and then performing the target analysis language's own verifier analysis. c_plugin (L k(C)) indicates that the code C is converted into the target analysis language and then analyzed by the plug-in verifier of the target analysis language. c_self (L k (C))∪V c_plugin (L k (C)) represents the results of self-verification and plug-in verification of the kth language converted from code c. It represents the result of self-verification and plug-in verification of the target language into which the code C is converted, that is, the result V of cross-language verification c_cross (C).

[0074] Step 4: Define the code-to-model validation function as V c_to_m (·), then the code-to-model verification can be expressed as:

[0075] V c_to_m (C)=A(M r (C)

[0076] Where C represents the code to be analyzed, V c_to_m (C) represents the verification result of the code C to be analyzed by converting the code into a model, M r (C) means converting the code C analyzed by code into model M r , represents the analysis of the converted model, A(M r (C)) represents the model M converted from code C r Analyze and finally get the analysis and verification results of code-to-model conversion V c_to_m (C).

[0077] To sum up, the entire code-side verification process can be expressed as:

[0078] V code (C) = V c_self (C)∪V c_plugin (C)∪V c_cross (C)∪V c_to_m (C)

[0079] Where ∪ represents the result fusion, which is the result of the verification of the code itself verifier V in the comprehensive verification layer 1. c_self (C) Verification result V of the code plug-in verifier of verification 2 c_plugin (C) , the result of cross-language verification at verification layer 3 V c_cross (C) and the verification results of the code-to-model verification of the verification layer 4 V c_to_m (C) By merging (taking the union), we can get the result V of the entire code verification. code (C).

[0080] (2) Specific execution process of model-side analysis

[0081] Define M as the model to be analyzed, then:

[0082] Step 1: Define the model's own validation function as V m_self (·), the total number of verification tools is p, then the model's own validator verification can be expressed as:

[0083]

[0084] Where M represents the model to be analyzed, V m_self (M) represents the verification result of the model M using the model's own verification tool, i represents the i-th verification tool, p represents the total number of verification tools, s i (·) represents the analysis of the ith model validation tool, s i (M) represents the analysis of model M by the i-th model validation tool, Represents the result of verifying model M using p model's own verification tools, that is, the model's own verification result The model is considered to have passed its own verification only when all verifications have passed. If it fails, the specific location of the error will be given to assist in improving the model structure.

[0085] The second step is to define the model plug-in verification function as V m_plugin (·), then the model plugin validator validation can be expressed as:

[0086] V m_plugin (M) = f x (M)

[0087] Where M represents the model to be analyzed, V m_plugin (M) indicates that the model M is validated using the model plug-in validator, x indicates the model M plug-in validator, and f x (·) indicates that the model M is analyzed and verified using the plug-in validator x, and the plug-in verification result V of the model M is finally obtained. m_plugin (M).

[0088] The third step is to define the cross-model validation function as V m_cross (·), then cross-language verification can be expressed as:

[0089]

[0090] Where M represents the model to be analyzed, V m_cross (M) represents the result of cross-language validation of model M, j represents the jth target model (other models different from model M), q represents the total number of models converted by model M, T j (·) means converting the model into the jth model different from itself, then Tj (M) represents the conversion of model M into the jth target model, A j (·) is the analytical function of the jth model, A j (T j (M)) indicates the analysis of the jth model converted from model M. Indicates that by converting model M into other q models and analyzing them, the final cross-model validation analysis result V is obtained m_cross (M).

[0091] Step 4: Define the model-to-code verification function as V m_to_c (·), then the model code can be expressed as:

[0092] V m_to_c (M) = A(C(M))

[0093] Where M represents the model to be analyzed, V m_to_c (M) represents the model M converted to code for analysis, C(·) represents the model-to-code function, A(·) represents the code analysis function, and A(C(M)) represents the analysis of the code converted from the model M to obtain the model-to-code verification result V m_to_c (M).

[0094] To sum up, the entire model-side verification process can be expressed as:

[0095] V model (M) = V m_self (M)∪V m_plugin (M)∪V m_cross (M)∪V m_to_c (M)

[0096] Where M represents the model to be analyzed, ∪ represents the fusion of the results (taking the union), V model (M) represents the analysis result of the entire model, that is, the result of the model self-verification at the comprehensive verification layer 1 V m_self (M), verification result V of the model plug-in validator of verification 2 m_plugin (M), the result of cross-model validation at validation layer 3 V m_cross (M) and the verification result V of the model conversion verification of verification layer 4 m_to_c (M) synthesis.

[0097] In summary, the formal integrated method for multimodal, cross-language, and multi-layer verification of complex software systems proposed in the present invention can select the corresponding verification process according to the form of the system (code or model). If it is code, the code verification process is applied; if it is a model, the model verification process is applied. These verification processes together constitute a comprehensive verification framework that covers multiple verification levels of code and models, including self-verification, plug-in verification, cross-language / model verification, and mutual conversion verification. This multi-level and multi-angle approach ensures comprehensive verification of complex software systems.

[0098] Improved effects of the present invention

[0099] In view of the problems in the current field of formal analysis and verification of complex software systems, such as the inability of a single verification method to perform comprehensive system verification, the lack of effective cross-platform verification tools, and the insufficient automation and integration of the verification process, the present invention proposes a multi-modal, cross-language, and multi-layer verification formal integration method for complex software systems. By proposing a novel multi-level verification framework, the method of the present invention performs multiple dimensions of code-to-model verification. At the same time, it combines multiple verification tools in cross-language and cross-model aspects to achieve automation and efficiency of the verification process, making the verification results credible, reliable, and complete.

[0100] Specifically, the improved effects of the present invention include:

[0101] (1) Achieved system integration of multi-level verification framework

[0102] The method of the present invention proposes an innovative multi-level verification framework, which overcomes the shortcomings of a single verification method by integrating a variety of formal methods and code detection technologies, and provides comprehensive coverage for the multi-dimensional requirements of complex software systems. This multi-layer verification method includes multi-dimensional verification from code to model, and ensures the comprehensiveness and accuracy of the system through the systematic integration of verification layer one to verification layer four. Each verification layer provides a unique perspective and method, covering code static analysis, model dynamic simulation, and cross-language and cross-model conversion verification, and ultimately achieves two-way cross-verification of code and model. As a result, not only the blind spots and loopholes in traditional verification methods are reduced, but also the detection capability of the system under dynamic changes and uncertainties is enhanced, and the reliability and security of the system are improved.

[0103] (2) Implemented cross-language and multi-modal verification technology

[0104] The method of the present invention converts a single language into multiple other languages ​​for multi-language verification, and converts a single model into multiple other models with different characteristics, and then compares and integrates the verification results of different languages ​​with the verification results of different models to ensure the compatibility and consistency between different languages ​​and models. This cross-language and cross-modal verification method of the method of the present invention provides multi-level quality assurance for complex software systems by combining multiple verification tools and multiple model verifiers, which not only improves the depth and breadth of verification, but also strengthens the system's ability to operate stably in different environments, so that the system can better cope with potential risks.

[0105] (3) Optimized the integration and automation of the verification process

[0106] The method of the present invention realizes the automation and efficiency of the verification process by deeply integrating multiple formal tools (such as Pylint, SPIN, Graphviz, UPPAAL, etc.), and significantly improves the verification efficiency through the automated verification process, reducing the possibility of human error. This innovative automated verification method of the method of the present invention not only enhances the credibility and authority of the verification result, but also provides a direct feedback mechanism for future optimization and iteration of the system. Through this deep integration and automation, the verification process becomes more flexible and scalable, and is suitable for larger and more complex systems.

[0107] Specific examples of the present invention

[0108] In order to verify the effectiveness of the formal integrated method for multi-modal, cross-language, and multi-layer verification of complex software systems proposed in this paper, the proposed method was experimented on real cases. The specific experimental results are as follows:

[0109] (1) Experimental background

[0110] The flight control system of an aircraft is responsible for switching between different flight states of the aircraft. The flight states of the aircraft are: Ground, Takeoff, Cruise, and Landing. The flight control system of an aircraft needs to ensure that the aircraft can switch between different states normally and ensure safety when switching between different states. Currently, there are codes for switching states of the flight control system and UML state diagrams (simplified) that represent the state switching of the flight control system. Therefore, this example will conduct verification separately at the code level and the model level.

[0111] (2) Verification layer 1: Code and model verification

[0112] ① Code level: code self-verification

[0113] The code for switching the aircraft status is as follows Figure 2As shown in the figure, the flight control system controls the aircraft to switch between different aircraft states to ensure the correctness of the aircraft operation. The above code is verified by the Python self-verifier, and the result shows that there is no problem. The result is as follows Figure 3 As shown. Figure 3 From the verification results, we can see that the Python self-verifier has passed the verification, verifying that the basic state transition logic is correct.

[0114] ②Model level: Model self-verification

[0115] The UML state diagram corresponding to this system is as follows Figure 4 shown. Figure 4 It describes the transition process of an aircraft's flight state, which involves four states: Ground, Takeoff, Cruise and Landing, and also includes three state transition processes:

[0116] Ground->Takeoff: When the "takeoff" event occurs, the aircraft will take off from the ground;

[0117] Takeoff->Cruise: When the "cruise" event occurs, the aircraft enters the cruise state;

[0118] Cruise->Landing: When the "land" event occurs, the aircraft begins to land.

[0119] Next, we use Enterprise Architect (EA) to test the UML state diagram we created. We test whether the state transition from the "Ground" state to the "Takeoff" and "Cruise" states is successful and reaches the "Landing" state. That is, there is no problem with the test result. Figure 5 As shown, the verification result of the state diagram passed, proving that the state transition logic detected by the EA tool is correct.

[0120] (3) Verification layer 2: code and model plug-in verification

[0121] ① Code level: code plug-in verification

[0122] Use static analysis tools to detect potential problems in the code. Use the Pylint plug-in tool to check whether there are any problems with the code logic involved in the aircraft flight state transition. The Pylint plug-in tool is a static code analysis tool for Python code. Its main functions include code quality inspection, coding style inspection, error detection, etc.

[0123] Code quality checking includes checking for errors, potential errors, and non-compliance with coding standards in the code. It analyzes the code through a series of predefined rules and gives a score; coding style checking can check whether the code complies with PEP 8 (Python's coding style guide), and it will mark out non-compliance with the style, such as indentation, variable naming, and line length; error detection means that Pylint can identify common errors in the code, including undefined variables, unused variables, unused imported modules, and other problems.

[0124] The results of using the Pylint plug-in tool to detect the above python code are as follows Figure 6 As shown in the figure, the Pylint plug-in tool has detected many areas that need improvement. The main problems are shown in Table 1.

[0125] Table 1 Pylint plug-in tool detection results of Python code

[0126]

[0127] According to the results in Table 1, the Pylint plug-in tool found some unhandled problems in the Python code. These problems were not detected by the code itself verifier in the aforementioned verification layer 1.

[0128] ②Model level: model plug-in verification

[0129] The model plug-in verification tool SPIN is used to verify the state transition logic of the verification model. SPIN is a tool for verifying models and algorithms, which can be used to check synchronization and communication issues in concurrent systems. At the same time, the core of SPIN is to use Promela (Process Meta Language) as a description language to model the behavior of the system. The Promela language supports multi-threaded behavior modeling and can describe the concurrency, message passing, and synchronization mechanisms of concurrent systems.

[0130] SPIN can perform the following tests on the system model:

[0131] Model checking: SPIN can perform a comprehensive state-space search of the Promela model to check the design specifications

[0132] Correctness;

[0133] Concurrency: It can support simulation and verification of concurrent algorithms, and identify deadlocks, race conditions, and other concurrency errors; Error detection: It can effectively detect errors that may occur in a multi-threaded environment, such as deadlock, unresponsiveness, etc.

[0135] The following uses SPIN to perform syntax checking, redundancy checking, model checking, and model verification on the above model as an example and gives the test results. The test results of the syntax check are as follows: Figure 7 As shown, according to Figure 7 The results of the SPIN checker show that there is nothing to report, which means that the above model has no grammatical problems. Figure 8 As shown, according to Figure 8 From the test results, we can see that the results of SPIN redundancy check are:

[0136] consider usingpredicate abstraction to replace:

[0137] mtype state 4 <flightcontrolsystem> <constant>{scope_2_}

[0138] According to the test results, it is recommended to use predicate abstraction to replace these states or transitions. In the above example, these states have no practical impact. Therefore, a more abstract way can be used to represent state transitions to simplify the model and improve verification efficiency. Fig. 9 As shown in the figure, you can see that SPIN believes that there are no invalid endstates, assertion violations, and unreachable code.

[0139] (4) Verification layer 3: cross-language and cross-model verification

[0140] ①Cross-language verification

[0141] Now convert the above Python code into C++ code to use C++ static analysis tools for detection. Python code can be converted into C++ code by defining class definitions, exception handling, string processing, assertions, and input and output in C++.

[0142] After converting Python to C++, three verification tools, CPPcheck, TScanCode and flawfinder, are used to verify the C++ code. CPPcheck, TScanCode and flawfinder have different focuses on the detection of C++ code. CPPcheck pays more attention to code quality and error detection, TScanCode provides a more comprehensive analysis on code quality and security, and Flawfinder focuses on the detection of security vulnerabilities. The following three tools are used to detect the above C++ code, and further analysis is performed based on the test results. It is worth noting that the verification tools for different languages ​​have their own characteristics. In actual testing, you can customize and select test tools that are adapted to the test language according to your needs.

[0143] CPPcheck tool analysis and verification: CPPcheck can detect common problems such as static code analysis, memory leaks, uninitialized variables, out-of-bounds access, etc., and also supports multi-threaded analysis. The test results of CPPcheck are as follows Fig.10 As shown, the result shows "No errors found.", indicating that CPPcheck did not detect any problems with the above Python code.

[0144] TScanCode tool analysis and verification: TScanCode can detect code quality and security, and can check potential vulnerabilities, code style, performance and other issues in the code. The TScanCode tool is used to verify the C++ language generated by Python, and the result shows "scan result is empty", which means that TScanCode did not detect any problems with the C++ code.

[0145] Flawfinder tool analysis and verification: Flawfinder can detect security issues in C++ code, as well as security issues such as buffer overflow, format string vulnerability, and SQL injection. After the flawfinder detection, the result is empty, indicating that flawfinder did not detect the above code problems.

[0146] From the above C++ code detection tools, we can see that CPPcheck, TScanCode and flawfinder did not detect the problems of the above C++ code.

[0147] ②Cross-model validation

[0148] At the model level, the UML state diagram can be converted into a Petri net, and the CPIN IDE tool can be used for simulation and verification to detect model-related problems. Fig.11 As shown in the figure, 1 in the figure indicates that there is a token at the "Ground" position, which is used to indicate that the system is initially in the "Ground" state, that is, the aircraft is on the ground and ready to take off. The Petri net is verified at the model level, and the model verification result shows "Model is correct", indicating that the model is established correctly.

[0149] Further, initialize the simulator, such as Fig.12 As shown, the result shows "Simulator initialized in 0.254 sec.", which means that the initialization is complete. Then the established Petri net model is verified and simulated. Through the simulation function of CPN IDE, the established model is simulated and the simulation results are verified. During the simulation process, the currently active state or transition will be marked with a bold frame, indicating that the state or transition is active or triggered in the current simulation step. At the same time, when a transition is triggered, it will consume tokens in the input library and generate tokens in the output library, that is, marked as "Fired" indicates that the transition has been triggered in the current simulation step, as shown Fig.13 As shown. By observing these marks, you can analyze the behavior of the system and verify the correctness of the model. Continue to execute the above steps. When all states are executed, the simulation will stay in the last state of the system, as shown in Fig.14 As shown. In the state switching of the entire system, the system finally stays in the last state, and no error is reported during the simulation, which means that the system state is executed normally and correctly.

[0150] On the other hand, "Petri net model replication" can be used to detect whether the tag replication and distribution operations in the system are incorrect, such as Fig.15 As shown in the figure. The "Petri Net Model Copy" execution process is 100% complete, which means that all required tag copying and distribution operations have been completed, and no errors or interruptions were encountered during the copying process. On the other hand, it also shows that CPIN IDE detects that the above model conversion process is also correct, and CPN IDE software is very suitable for further verification and analysis on the basic model.

[0151] (5) Validation layer 4: two-way cross validation of code and model

[0152] ① Code level: code to model verification

[0153] The above Python code is converted into a state diagram model in UML and a UPPAAL timed automaton model for further verification.

[0154] 1) Convert Python code to UML state diagram

[0155] After the Python code is converted to a .dot file, it is analyzed using Graphviz software. Graphviz software will check the state transitions in the Python file and the correctness between the state transitions. If the content is correct, the state diagram will be regenerated. Use the command "dot-Tpng-o flight_control.png flight_control.dot" to generate a UML state diagram from the .dot file, such as Fig.16 As shown in the figure, we can see that the Python code file successfully generates states through the Graphviz software, indicating that there is no problem with the state transfer in this Python file.

[0156] 2) Convert Python code to UPPAAL timed automaton model

[0157] Furthermore, the above Python code is converted into a timed automaton model. Here, the UPPAAL model is taken as an example. The UPPAAL timed automaton model converted by Python is as follows: Fig.17 As shown. Fig.17 As can be seen in the figure, after converting the functions in Python into the trigger conditions between the states of the UPPAAL timed automaton and extracting the states and state transition information in Python, the UPPAAL timed automaton model can be formed.

[0158] The UPPAAL software was used to analyze and verify the UPPAAL model. The verification results are as follows: Fig.18 As shown in the figure, it can be seen that the UPPAAL time automaton detects the risk of deadlock in the above state transitions and reports the error "Deadlock: There are no outgoing transitions to choose from", which means that when the state transition is to the "Landing" state, it is unknown how the next state should occur. Further analysis shows that the "Landing" state in the state diagram has no outgoing edges, which prevents the system from continuing to other states. In reality, when the aircraft does not define subsequent operations after landing, such as stopping or shutting down the system, this may cause the system to be unable to complete the entire mission process, ultimately leading to mission failure or failure to complete the specified task.

[0159] ②Model level: Model conversion code verification

[0160] Convert the initial UML state diagram model into JAVA code or C++ code and use JAVA or C++ code checking tools for verification.

[0161] 1) Java code verification tool verification

[0162] Convert the UML state diagram model into JAVA code for verification. The verification results are as follows Fig.19 As shown. Fig.19 It can be seen that there will be problems when compiling the generated code directly. After some manual modification, the verification results are as follows Fig. 20 The result shows "Arrived at destination.", and the system has reached the specified state correctly without any error.

[0163] 2) Verification by C++ code verification tool

[0164] After converting the above UML state diagram into C++ code and manually correcting it, the compilation and execution results are as follows Fig.21 As shown, the problem is correct at this time. Further, if we consider the transition between the Landing state and the Ground state and convert it into a test case in the C++ code, recompile and execute the C++ code, the test results are as follows: Fig. 22 As shown. Fig.21 and Fig. 22 From the comparison, we can see that the possible paths will be detected only when the transition between the Landing state and the Ground state is taken into account, that is, when the possible problems are taken into account. When the Landing state and the Ground state are taken into account, the test result "State after invalid land: Ground" appears, that is, after the Landing state, the original UML diagram will not be converted to the Ground state. That is, for code testing, the tester needs to know the specific test cases to be tested before conducting code testing; in other words, if a certain test case is not taken into account, the code-side detection is not capable of detecting situations that are not in the test case set.

[0165] 3) Python compilation test

[0166] Furthermore, the above UML state diagram is converted into Python code, and the correctness of the UML state diagram is verified through Python test cases. When the transition between the Landing state and the Ground state is not considered, the Python compilation test passes smoothly, such as Fig.23 As shown; when considering the transition between the Landing state and the Ground state, the detection result is "Stateafter invalid land: Ground", as shown Fig.24 As shown in the figure, it means that the Landing state cannot be converted to the Ground state in the current UML state diagram, that is, a deadlock occurs between the Landing state and the Ground state. In general, Python compilation testing also requires testers to consider the path that may trigger the problem and then verify it. It does not have the ability to actively discover the problem path and search the entire state space.

[0167] (6) Comprehensive integration verification

[0168] By integrating the execution results of the above four verification layers (each verification layer includes the code side and the model side), not only can problems at different levels (compilation level, execution level, etc.) be discovered, but also problems in the dynamic execution process such as concurrency, state transition, and timing logic correctness can be further discovered, thus achieving more comprehensive detection of the code side and the model side. The above problems found will be summarized, analyzed, and fed back to modify and maintain the existing software or system to improve the reliability and security of the system.

[0169] The overall test process of this case is as follows Fig.25 As shown in the figure, the code and model itself are verified at the verification layer 1. At the code level, Python's own validator is used to verify the Python code, and type checking can be performed before compilation; at the model level, the flight control system UML state diagram is verified using EA's own validator to check the model correctness and completeness to ensure that the model has no logical errors.

[0170] At the second verification level, the code and model plug-in verifiers are used for verification. At the code level, the Python plug-in verifier Pylint is used for verification, which can check the code quality, coding style and error detection; at the model level, the flight control system UML state diagram is verified using the SPIN plug-in verifier, which can check the model correctness and detect concurrency errors.

[0171] At the verification layer 3, cross-language and cross-model verification is performed. At the code level, Python code is converted to C++ code and tested using C++ detection tools (CPPcheck, TScancode, flawfinder). Since C++ has stricter type checking and higher execution efficiency and resource utilization, it is easier to identify memory management, uninitialized variables, and potential concurrency issues. At the model level, UML state diagrams are converted to Petri nets, and the Petri nets are verified using the CPIN IDE tool to further analyze concurrency and synchronization characteristics.

[0172] In the verification layer 4, two-way cross-validation of code and model is performed. On the one hand, Python code is converted into UML state diagram, and Graphviz software is used for verification to identify potential logical errors; Python code is converted into UPPAAL timed automaton model to simulate and verify the complex behavior of the system, identify deadlock and perform performance analysis. On the other hand, the UML state diagram model of the flight control system is converted into JAVA code, and the test is performed through JAVA test cases; at the same time, the UML state diagram model is converted into C++ code, and the test is performed through C++ test cases; finally, the UML state diagram model is converted into Python code, and the test is performed through Python test cases. By converting the UML state diagram into specific implementations in different languages, on the one hand, the consistency and integrity check of the model and code can be tested, and on the other hand, the consistency and behavioral correctness between different languages ​​can be checked and verified.

[0173] Finally, the four verification layers (code and model self-validator layer, code and model plug-in validator layer, cross-language and cross-model validation layer, and code and model two-way cross-validation layer) and two different levels (code level, model level) are tested. Not only can the detection be performed from a coarse-grained level (syntactic correctness, logical correctness, etc.), but also from a fine-grained level (state switching correctness, clock synchronization consistency, etc.) can be performed. Various tools and methods can be fully utilized to improve system performance, integrity, and reliability, ensuring that software products run more efficiently and stably.< / constant> < / flightcontrolsystem>

Claims

1. A formal integrated method for multi-modal, cross-language, and multi-layer verification of complex software systems, characterized by include: A) When the object to be analyzed is code, perform the following operations: A1) Perform code self-verification. Perform code self-verification on the code to be analyzed to ensure the basic quality and security of the code, including: Use code static analysis tools to identify basic syntax errors, Use code quality checking tools to ensure content management and execution efficiency, and Use code security verification tools to check for potential vulnerabilities and threats. A2) Perform code plug-in verification and use the code plug-in verifier to conduct a deeper analysis of the code. A3) Perform cross-language validation, including: converting the code to be analyzed into another language for multi-language analysis, A4) Perform code-to-model verification, including: converting the code to be analyzed into a model for further verification, B) When the object to be analyzed is a model, perform the following operations B1) Perform self-validation of the model, including using the validation tools provided by the model framework to perform self-validation. B2) Perform model plug-in validator verification, and perform extended verification on the model through the model plug-in validator. B3) Perform cross-model validation and convert the model to be analyzed into other model formats for diversified validation. B4) Perform model-to-code verification, convert the model into code form, use code-side verification tools for further analysis, use static analysis tools to check the performance of the converted code in the target language, and use dynamic analysis tools to simulate system operation and identify reactions in real scenarios, so as to ensure that the model can be accurately converted into executable form and verify its authenticity and practicality. The step A1 comprises: Define the code's own verification function as V c_self (·), the total number of verification tools is n, and the code itself verifier verification is expressed as: in: C represents the code to be analyzed, V c_self (C) represents the result of analyzing code C using the code verification tool. v i represents the i-th verification tool, v i (C) Code is analyzed by the i-th verification tool on code C, i.e. for a given code C, it will apply n different verification tools v i , It represents the union of the results of n different verification tools analyzing and verifying code C, that is, it integrates the results of multiple verifiers for code C. Only when all the verifications pass will the code be considered to have passed its own verification. If it fails, the specific location of the error will be given to assist in system modification. The step A2 comprises: Define the code plugin verification function as V c_plugin (·), the code plugin validator validation is expressed as: in: C represents the code to be analyzed, V c_plugin (C) represents the result of analyzing code C using the plug-in validator. j represents the jth plugin validator, m represents the total number of plugin verifications for code C, p j (C) Code C is analyzed by the j-th verifier, Represents the union of the analysis and verification results of code C by m plug-in validators. If the verification result fails, a detection report will be generated and the specific number of problem lines and the cause of the problem will be reported. The step A3 comprises: Define the cross-language verification function as V c_cross (·), and express cross-language verification as: in: C represents the code to be analyzed, V c_cross (C) represents the result of cross-language validation analysis of code C. L k (·) represents the conversion function from code C to other target analysis languages, L k (C) means converting code C into the target analysis language. l represents the number of target languages, k represents the current language, V c_self (L k (C)) means converting code C into the target analysis language and then performing self-verification analysis of the target analysis language. V c_plugin (L k (C)) means converting code C into the target analysis language and then performing plug-in validator analysis of the target analysis language. V c_self (L k (C))∪V c_plugin (L k (C)) represents the result of self-verification and plug-in verification of the k-th language converted from code C. It represents the result of self-verification and plug-in verification of the target language into which the code C is converted, that is, the result V of cross-language verification c_cross (C) The step A4 comprises: Define the code conversion model verification function as V c_to_m (·), the code-to-model verification is expressed as: V c_to_m (C)=A(M r (C)) in: C represents the code to be analyzed, V c_to_m (C) represents the verification result of the code C to be analyzed by converting the code into a model. M r (C) means converting the code C of code analysis into model M r , A(·) represents the analysis of the transformed model. A(M r (C)) represents the model M converted from code C r Analyze and finally get the analysis and verification results of code-to-model conversion V c_to_m (C). Define M as the model to be analyzed, The step B1 comprises: Define the model's own validation function as V m_self (·), the total number of verification tools is p, and the model's own validator verification is expressed as: in: M represents the model to be analyzed, V m_self (M) represents the verification result of analyzing the model M using the model's own verification tool. i represents the i-th verification tool, p represents the total number of verification tools, s i (·) represents the analysis of the i-th model validation tool, s i (M) represents the analysis of model M by the i-th model validation tool, It represents the result of verifying the model M using p verification tools of the model itself, that is, the model self-verification result V m_self (M). The model is considered to have passed its own verification only if all verifications have passed. If some verifications fail, the specific location of the error will be given to help improve the model structure. The step B2 comprises: Define the model plugin validation function as V m_plugin (·), the model plugin validator validation is expressed as: V m_plugin (M)=f x (M) in: M represents the model to be analyzed, V m_plugin (M) indicates that the model M is validated using the model plug-in validator. x represents the model M plugin validator, f x (·) indicates that the model M is analyzed and verified using the plug-in validator x, and the plug-in verification result V of the model M is finally obtained. m_plugin (M). The step B3 comprises: Define the cross-model validation function as V m_cross (·), and express cross-language verification as: in: M represents the model to be analyzed, V m_cross (M) represents the result of cross-language verification of model M. j represents the jth target model, i.e., other models different from model M. q represents the total number of models converted by model M. T j (·) means converting the model into the jth model different from itself. T j (M) means converting model M into the jth target model. A j (·) is the analytical function of the j-th model, A j (T j (M)) indicates the analysis of the jth model converted from model M. It means that by converting model M into other q models and analyzing them, the final cross-model validation analysis result V is obtained. m_cross (M). The step B4 comprises: Define the model code conversion verification function as V m_to_c (·), the model is converted into code: V m _toc(M)=A(C(M)) in: M represents the model to be analyzed, V m_to_c (M) represents the model M converted into code for analysis. C(·) represents the model-to-code function, A(·) represents the code analysis function, A(C(M)) means analyzing the code converted from model M to obtain the verification result V of model-to-code conversion m _toc(M).

2. The method for formal integration of multi-modal, cross-language, and multi-layer verification of complex software systems according to claim 1 is characterized by: The step A is expressed as: V code (C)=V c_self (C)∪V c_plugin (C)∪V c_cross (C)∪V c_to_m (C) in: ∪ indicates result fusion, The result of the code self-verification of the comprehensive verification layer 1 is V c_self (C) Verification result V of the code plug-in verifier of verification layer 2 c_plugin (C) Result of cross-language verification at verification layer 3 V c_cross (C) and the verification results of the code-to-model verification of the verification layer 4 V c_to_m (C) Fusion is performed, that is, taking the union, to obtain the result V of the entire code end verification code (C).

3. The method for formal integration of multi-modal, cross-language, and multi-layer verification of complex software systems according to claim 1 is characterized by: The step B is expressed as: In model (M)=V m_self (M)∪V m_plugin (M)∪V m_cross (M)∪V m_to_c (M) in: M represents the model to be analyzed, ∪ represents the fusion of the results, that is, taking the union. V model (M) represents the analysis result of the entire model, that is, the result of the model self-verification at the comprehensive verification layer 1 V m_self (M) Verification result V of the model plug-in validator of the verification layer 2 m_plugin (M) Result of cross-model validation at validation layer 3 V m_cross (M) and the verification result V of the model conversion verification of verification layer 4 m_to_c (M) synthesis.

4. The method for formal integration of multi-modal, cross-language, and multi-layer verification of complex software systems according to claim 1 is characterized by: Step A2) comprises: Identify code duplication and complexity through structural optimization plugins, Checking interface consistency via cross-platform compatibility plugins, and The state transition plug-in is used to identify state switches in the code, thereby providing more accurate verification results.

5. The method for formal integration of multi-modal, cross-language, and multi-layer verification of complex software systems according to claim 1 is characterized by: Step A3) comprises: Convert C code to C++ for performance optimization and / or C code to Python for rapid prototyping and flexibility to extend verification by leveraging ecosystems and tool chains in multiple languages.

6. The method for formal integration of multi-modal, cross-language, and multi-layer verification of complex software systems according to claim 1 is characterized by: Step A4) comprises: Use model analysis tools such as UPPAAL to analyze and verify the timing model to ensure the timing behavior of the system, and / or Use PRISM to analyze probability models and evaluate system reliability and failure probability. This abstracts the code behavior into a verifiable model.

7. The method for formal integration of multi-modal, cross-language, and multi-layer verification of complex software systems according to claim 1 is characterized by: Step B1) comprises: Use the model framework's own consistency verification tools to ensure the integrity of state diagrams and flow charts, and Use the constraint checking tools provided by the model framework to ensure that the design specifications are not violated. This ensures the rationality and standardization of the preliminary design.

8. The formal integrated method for multi-modal, cross-language, and multi-layer verification of complex software systems according to claim 1 is characterized by: Step B2) includes: using a plug-in including the SPIN tool to further discover deadlocks, livelocks and / or security issues, ensuring that the system behavior complies with the design specifications and helping developers to quickly locate them, thereby improving the reliability and security of the model.

9. The method for formal integration of multi-modal, cross-language, and multi-layer verification of complex software systems according to claim 1 is characterized by: Step B3) comprises: Convert the model to NuSMV to facilitate formal verification and logical reasoning, and / or Convert the model to UPPAAL model to enhance the accuracy of timing verification. This covers the performance and properties under different modeling approaches.

10. A computer-readable storage medium storing a computer-executable program, wherein the computer-executable program enables a processor to execute the method according to any one of claims 1 to 9.

Images