A model and code cross-validation analysis method based on uppaal

Abstract

The application provides a model and code cross-validation analysis method based on UPPAAL, a valuable solution is provided by using UPPAAL and a code analysis tool for a double-source code verification method, including system modeling, model verification, model verification analysis, attribute verification, model-code conversion, code verification, model and code cross-validation and the like, which can ensure comprehensive checking of the system, and can ensure the correctness of the syntax semantics, system attributes and behaviors of the system, overcome the limitations (limited range, false positive, lack of integration) of the prior art, and achieve higher level of software quality. It has the advantages of improving code quality, enhancing system reliability, improving efficiency, accuracy and reducing development cost.

Description

TECHNICAL FIELD

[0001] The application is a model and code cross-validation analysis method based on UPPAAL, and relates to the field of system verification, and specifically uses model checking and code verification to verify system design and implementation. BACKGROUND

[0002] The formal method solves the problem that the traditional software development method cannot determine whether the design level specification is correct, it can analyze and model the system from the model level by abstracting the top-level design and extracting the key features of the top-level design, and set the properties of the system from the requirement level, so as to simulate whether the design system can traverse all states. UPPAAL is a tool for verifying time automata in formal detection methods, which models the system as a system with a finite control structure and a non-deterministic process set of real-time clocks, and communicates through channels or shared variables.

[0003] UPPAAL verifies the reachability, safety and liveness of the system through CTL (Computation Tree Logic). The basic CTL formula for verifying reachability is E<>P, which means that there is a path that can satisfy the logical formula P; the basic CTL formula for verifying safety is A[]P, which means that each state of the system can satisfy the logical formula P; E[]P, which means that there is always a path state that satisfies P; the basic CTL formula for verifying liveness is A<>P, which means that a certain state in all paths eventually satisfies the logical formula P.

[0004] Some extensions of UPPAAL model have been developed based on UPPAAL model, such as CORA, ECDAR, Tiga, TRON. Among them, CORA is a linear priced timed automaton based on UPPAAL model. Given an LPTA model, UPPAAL CORA can find the optimal path of states that meet certain goal conditions, and this optimal path has the lowest cumulative cost. ECDAR is a timed interface theory tool designed to check incremental refinement between specifications. It can combine different timed I / O automata with composition or concatenation operators and check whether the composed specification refines another specification. ECDAR treats timed game automata as timed I / O automata, opening up the way for incremental design and composition reasoning. Tiga optimizes the basic symbolic algorithm by using regions as the underlying data structure to perform each step of the algorithm to obtain the time-optimal winning strategy. TRON is a black-box conformance test for timed systems, mainly for embedded software commonly found in various controllers. Test primitives are generated directly from the model, and when connected to the SUT (System Under Test) for online (dynamic) execution and simultaneous checking of system responses, it avoids the need for a huge intermediate test suite. The specification is a UPPAAL timed automaton network.

[0005] Existing UPPAAL model and code cross-validation related technologies can be divided into three categories:

[0006] 1. Model checking and code verification technology

[0007] These technologies focus on verifying the correctness of UPPAAL models and their corresponding code implementations. This process includes separate UPPAAL model checking, which can verify the properties of the model according to various event logic, indicating that the model correctly reflects the expected behavior of the system; at the same time, static code analysis identifies potential errors and vulnerabilities by checking the source code. Another method is model-based testing, which generates test cases from UPPAAL models for execution on actual systems to identify differences between the model and the code. However, these methods treat model checking and code verification methods and processes as independent processes, with the goal of model checking being to check whether the model can correctly reflect and verify the properties and expected behavior of the system; the goal of static code analysis is to check the code and identify potential code defects.

[0008] 2. Model and code co-simulation technology

[0009] Model and code co-simulation techniques mainly fall into two categories: one is to link UPPAAL model with external simulators and code implementation, for example: UPPAAL-SMC; the other is to integrate UPPAAL model with real-time operating system, and execute model and code verification on a platform, for example: CORA, ECDAR, TRON and other tools. However, in general, in the model and code system simulation technology method, the verification of the model and the verification of the code are still two independent aspects, which lacks the information sharing and cooperation between the model and the code.

[0010] 3. Model and code refactoring techniques

[0011] Model and code refactoring techniques aim to improve the quality and maintainability of UPPAAL models and their corresponding code implementations. These techniques include model refactoring, which reorganizes UPPAAL models, and code refactoring, which involves reorganizing code.

[0012] In summary, there is currently no specific technology for directly cross-verifying UPPAAL models and code. Therefore, the present application is directed to UPPAAL model and code cross-verification technology, which realizes bidirectional cross-verification technology of UPPAAL-based model and code by combining model checking and code verification technology, verifies the correctness of the object properties, and realizes the consistency and correctness of the model and the code.

[0013] Existing model checking and code detection techniques are mainly distributed independent processes. The system is modeled and the model checking tool is used to verify the properties and behaviors of the system; the code of the system is detected, and the range and value of the variable are detected. There is a lack of an effective bridge between model checking and code detection to realize the fusion of model checking results and code detection results. This causes the following problems:

[0014] ① Limited range: traditional code analysis tools mainly focus on the correctness of syntax and semantics, often ignoring subtle behavior problems or potential runtime errors. UPPAAL is suitable for verifying time properties and system behavior, and has limitations and range in variable analysis, and the coverage range of variables is limited. At the same time, a single tool may have limitations in covering specific aspects of the code. And the verification of UPPAAL at the model level also has limitations in the range of variables.

[0015] ② False positive: model checking and code detection are specific to tool limitations: code detection tools (such as static analysis tools) may not be able to capture all types of errors, or may produce false positives / negatives. Similarly, model checking tools (such as UPPAAL) may not be able to handle complex systems or may require a lot of expertise.

[0016] ③ Lack of integration: Code detection tools and model checking tools are often used separately, which makes it difficult to correlate results and identify inconsistencies.

[0017] In summary, the single model verification and code detection technology has the problems of limited range, false positives and lack of integration, which limits the further development of the current model verification and code detection technology. SUMMARY

[0018] The present application is aimed at the problems of limited range, false positives and lack of integration faced by current model verification and code detection. By combining code detection tools and UPPAAL model verification tools, the advantages of the two methods are used to realize a more comprehensive verification process. The present application provides a model and code cross-validation analysis method based on UPPAAL to improve the reliability of system verification. This is achieved through a structured process that ensures that the model and its corresponding code implementation meet the specified properties and requirements. The following goals are achieved:

[0019] ① Comprehensive coverage: UPPAAL can effectively detect concurrency issues such as deadlocks, which, combined with traditional code analysis tools, not only identify system behavior and time properties, but also address syntax and semantic correctness (such as syntax errors, type errors, or security vulnerabilities) or potential runtime errors, solving the problem of variable range limitations.

[0020] ② Mutual verification: Combining the results of model verification and code detection for cross-validation can reduce the possibility of false positives / negatives, capture deadlocks, variable detection limitations, etc. By specifying time properties in UPPAAL, it can be verified whether the system follows the required behavior pattern over time, thereby preventing unexpected results (such as memory leaks, deadlocks, or inefficient resource allocation). Code detection tools can check variables, semantics, etc. within the code, and mutual verification with model verification techniques can solve the problem of false positives.

[0021] ③ Integration and cross-validation: Integrating model verification and code detection methods and cross-verifying the two methods can identify inconsistencies and potential errors. Not only does this make the detection results more comprehensive, but it also facilitates debugging and fixing these errors, forming a more robust and efficient verification process.

[0022] ④ Improve efficiency and accuracy: Combining model verification and code testing processes not only reduces the time and effort required for manual code review and testing, but also provides more accurate experimental results. It can provide a higher level of assurance for the correctness and reliability of the system, which is crucial in safety-critical and mission-critical applications.

[0023] The present application aims at solving the above problems, and provides a model and code cross-validation analysis method based on UPPAAL, which can ensure comprehensive checking of a system, and can ensure correctness of syntax semantics, system attributes and behaviors of the system, has the advantages of improving code quality, enhancing system reliability, improving efficiency, accuracy and reducing development cost, and the overall process is as shown in Figure 1 .

[0024] To achieve the above object, the present application adopts the following technical scheme.

[0025] A model and code cross-validation analysis method based on UPPAAL, and the specific steps are as follows:

[0026] Step (1), system modeling: the system is described as a timed automaton UPPAAL model, and the system described by UPPAAL is represented as M.

[0027] Step (2), model verification: the verifier of UPPAAL is used to perform initial syntax correctness verification to check the basic correctness of the model; if M meets the initial syntax correctness standard, Verify(M) returns true, and the next verification is performed; if M does not meet the initial syntax correctness standard, Verify(M) returns false, and the specific error position and error reason are given, the model syntax structure is further modified, and step (2) is repeated until M meets the initial syntax correctness standard, that is, Verify(M) returns true.

[0028] Step (3), model verification analysis: if Verify(M) is true, the model dynamic verification can be performed, which can simulate the dynamic change of the state from the initial state, and the change of the variable value at any time can be viewed, and whether the model has a deadlock problem can be detected here. Assuming that the deadlock problem is represented as Deadlock(M), if the system has a deadlock, Deadlock(M) returns true, and the deadlock problem is recorded in the "model checking problem description", the system structure is modified, and step (2) is returned until the system does not have a deadlock problem, that is, Deadlock(M) returns false, and the subsequent attribute verification step can be entered.

[0029] Step (4), attribute verification: assuming that the system modeling M must meet the attribute P, the verification Verify(M, P) is performed; if Verify(M, P) returns true, the model is determined to be correct; if Verify(M, P) returns false, the problems are recorded in the "model checking problem description".

[0030] Step (5), model-code conversion: the UPPAAL model M is converted into an XML representation M X, using model conversion tool to convert M X into C language file M C .

[0031] Step (6), code verification: applying code verification tool (e.g. CBMC, ESBMC, SPIN) to verify the C language file converted in step (5); if the verification process VerifyCode(C) returns true, it proves that the code is correct; if the verification process VerifyCode(C) returns false, it proves that the code verification detects problems, and records in "code detection problem description".

[0032] Step (7), model and code cross verification: merging the problems detected from "model detection problem description" and "code detection problem description" to form "model and code cross verification problem set"; and according to the "model and code cross verification problem set" to modify the system modeling.

[0033] In step (1), the time automaton UPPAAL model is specifically: assuming S represents the state (location) set, δ represents the transition set, s0 represents the initial state, and C represents the clock set, then the system is represented by a four-tuple A=(S, δ, s0, C) through the time automaton UPPAAL. Its behavior can be represented as:

[0034] δ: S × Guards × S → Synchronization, wherein the guard condition (Guards) and synchronization (Synchronization) describe the state transition rule and communication mechanism. Further, the state evolution of the system can be represented as Path(G)=∑ e∈E w(e), wherein G represents the system state graph, e belongs to an edge in the edge set E, and each edge e in the edge set E has a weight function w(e) representing the time or resource consumption of state transition.

[0035] In step (2), assuming ∑X is the set of UPPAAL model syntax rules, for any model M, it should belong to the legal model set ∑ valid X, i.e. M∈∑ validX. Define a verifier function Verifier_Syntax(M) to check the correctness of model syntax, if model M satisfies all the syntax rules, then Verifier_Syntax(M) returns true; if Verifier_Syntax(M) does not satisfy the syntax rules, then Verifier_Syntax(M) returns (false, error_loc, error_reason), where false indicates that the syntax check fails, error_loc indicates the location of the error, and error_reason indicates the reason for the error. The initial syntax correctness verification can be represented as:

[0036] If Verifier_Syntax(M) returns true, then the subsequent verification steps are continued; if Verifier_Syntax(M) returns false, then the model syntax structure is further modified according to the error location and error reason, and step (2) is repeated until Verifier_Syntax(M) returns true, i.e. where M (k) represents the model after the kth modification. Assuming F represents the set of models for which Verifier_Syntax(M) returns false, then F can be represented as F = {M | Verifier_Syntax(M) = false}, and the modification process of the model M can be equivalent to finding an element of the complement of F , i.e.

[0037] In step (4), the specific process of verification Verify(M, P) is as follows: assuming p represents an attribute, and P represents the set of attributes that need to be verified, then p ∈ P represents a certain condition that the model must satisfy. Define a verifier function Verifier_Property(M, p) to check whether the model M satisfies the attribute p, and assume that property_reason represents the specific reason why the attribute does not satisfy. The process of the verifier function Verifier_Property(M, p) to check whether the model M satisfies the attribute p can be represented as:

[0038]

[0039] Further, P = {p1, p2,..., p m}, and the attribute verification process can be represented as:

[0040]

[0041] Assuming the problem record set is ε, and ε records the information of Verifier_Property(M,p) = (false,property_reason), that is...

[0042] ε={(p,property_reason)|Verifier_Property(M,p)=false}.

[0043] In step (5), the UPPAAL model M is converted into an XML representation M. X Use a model conversion tool to convert M X Convert to C language file M C The specific operating procedure is as follows:

[0044] The first step is to convert the UPPAAL model M into an XML representation. The basic conversion steps include: converting the template into XML tags and their attributes; and converting the system definition into XML tags and their attributes. Assume that the UPPAAL model M contains n templates T1, T2, ..., T... n The system is defined as S. Then the XML representation of model M can be represented as M XML It includes the template part and system definition section S XML Furthermore, M XML ={T XML ,S XML}

[0045] The second step is to convert the XML file into a C language file. The basic conversion steps include parsing the XML representation and generating C code. First, the XML representation is parsed. Let's assume the XML-to-C language conversion tool is defined as T... c Use conversion tool T c Conversion function Secondly, use T c Analysis of M XML Generate intermediate structure Ψ: Ψ = parse(M XML Subsequently, the corresponding C language file M is generated using the parsed intermediate structure Ψ. C M C =generate_C_code(Ψ).

[0046] The specific process for code verification in step (6) is as follows: First, input the verification model: input the C language file M generated in step (5). CAs input, the input C language file is verified by using code detection tools (CBMC, ESBMC, SPIN). Assume that the verification function of the code detection tool is Y, and the code detection result set is R verify , then the code detection tool verification process can be represented as: Y: M C → {true, false}, and R verify = Y {M C}. Wherein, R verify = true indicates that the code verification is correct, and R verify = false indicates that the code detection method detects an error. Finally, the result of R verify = false is stored in the "code detection problem description".

[0047] Wherein, in step (7), the specific process of model and code cross-verification is as follows: first, the problem is summarized. Assume that the set of model detection problems is P model-check , the set of code detection problems is P code-verify , and the set of model and code cross-verification problems is P cross-validation , then P cross-validation = P model-check ∪ P code-verify . Wherein, P model-check = {p1, p2,..., p m}, P code-verify = {q1, q2,..., q n},

[0048] P cross-validation = {r1, r2,..., r k} (k≤m+n), r i is the problem item obtained by merging p i and q i . Secondly, the system model is modified according to the problems in P cross-validation . Let the modification function be , the input is the current system and the problem set, and the output is the modified new system model, which can be represented as: (M, P cross-validation )→ M ′ , that is the modified model M ′ and the corresponding C code file M C ' re-enter the model detection and code detection cycle, return to step (1), until the verification result is true, that is, no new problem description is generated, that is, |P cross-validation | = 0.

[0049] In summary, the UPPAAL-based model and code cross-validation method includes system modeling, model verification, code conversion, and problem integration steps. Model verification includes checking the correctness of structure and behavior, and code verification includes using multiple tools to ensure robustness against different types of errors.

[0050] The present application provides a UPPAAL-based model and code cross-validation analysis method by ensuring that both the model and its implementation conform to the predefined specification, thereby improving the reliability and correctness of system development.

[0051] Compared with the prior art, the present application has the following beneficial effects:

[0052] The UPPAAL-based model and code cross-validation analysis method provides a valuable solution to overcome the limitations of existing technology (limited scope, false positives, lack of integration) to achieve higher levels of software quality. Compared with the prior art, the UPPAAL-based model and code cross-validation technology has the following beneficial effects:

[0053] ① Enhanced consistency verification

[0054] In traditional methods, model verification and code verification are usually separate, which may lead to inconsistencies between the model and its implementation. The present application integrates the verification process of the model and the code, ensuring that every step from the model to the code conforms to the predetermined properties and requirements, thereby enhancing the consistency of the final system.

[0055] ② Improve system reliability:

[0056] By cross-verifying the model and the generated code, potential errors and problems can be detected more comprehensively. The present application combines model checking and code verification techniques to conduct comprehensive verification and confirmation of the system. Through model checking, the design and specification of the system can be verified; through code verification, the implementation can be ensured to conform to the design and specification. This two-way cross-validation method can significantly improve the reliability and correctness of the system.

[0057] ③ Reduce rework and cost:

[0058] By model checking and code verification, errors and defects in the system can be precisely located. Model checking can find problems at the design and specification level, while code verification can find problems at the implementation level. Combining the results of the two, problems in the system can be comprehensively and accurately identified. By finding problems in the early stages of the development process, the invention reduces the need for later rework, saving time and cost. At the same time, once the system is deployed, the complexity and cost of its maintenance and upgrade will also be reduced.

[0059] ④Improve verification efficiency:

[0060] The invention realizes fast verification of models and codes through automated tools and processes such as UPPAAL and CBMC, ESBMC, SPIN, etc. The improvement of this degree of automation can significantly speed up the verification process, enabling the development team to iterate and improve the product more quickly. At the same time, the invention can be seamlessly integrated with existing verification tools such as UPPAAL, CBMC, ESBMC, SPIN, etc., making full use of the functions and advantages of these tools. This compatibility can save development costs and improve verification efficiency.

[0061] ⑤Enhanced error tracking and analysis capabilities:

[0062] By recording the problems found in model verification and code verification in detail and integrating them into the "model and code cross-verification problem set", the invention provides a clear error tracking and analysis framework. According to the information in the problem set, errors can be repaired, designs can be optimized, and the performance and reliability of the system can be improved. This not only helps the continuous improvement of the system, but also provides valuable experience and data support for future projects.

[0063] ⑥Support verification of complex systems:

[0064] UPPAAL as a powerful real-time system modeling and verification tool, combined with code verification tools, makes the invention particularly suitable for handling complex system verification problems such as concurrency, communication and time constraints, which are often difficult to accurately handle in traditional verification tools. At the same time, the invention can be applied to various types of systems such as embedded systems, real-time systems, safety-critical systems, etc. As long as the system can be modeled with UPPAAL and C code can be generated, the invention can be used for verification and confirmation.

[0065] Through these beneficial effects, the invention not only improves the quality and efficiency of system development, but also provides a more scientific and systematic verification method for the design and implementation of high-reliability systems. The application of this method can significantly improve the performance of the system and the trust of the user, which is of great significance to improving the competitiveness of the product.

[0066] The present application can play an important role in many fields, particularly in aspects related to concurrent systems, real-time systems, embedded systems, and communication protocols. Specific application fields include, but are not limited to, embedded systems, communication protocols, autonomous driving systems, aerospace and aviation systems, medical devices, power systems, and intelligent transportation systems. BRIEF DESCRIPTION OF DRAWINGS

[0067] Figure 1 is a UPPAAL-based model and code bidirectional cross-verification flowchart.

[0068] Figure 2 is the first process POne.

[0069] Figure 3 is the second process PTwo.

[0070] Figure 4 is the UPPAAL process simulation.

[0071] Figure 5 is the modified POne process.

[0072] Figure 6 is the modified PTwo process.

[0073] Figure 7 is the modified model simulator simulation. DETAILED DESCRIPTION

[0074] Now, the effectiveness of the "UPPAAL and C code-based model and code bidirectional cross-verification" implementation scheme proposed by the present application will be illustrated with a specific application in the field of aviation. There are programs on an airplane that are simultaneously executed by multiple sensors. The sensors can read and modify shared data at the same time, and if the design does not reasonably ensure the consistency and safety of the data, it can lead to serious safety problems.

[0075] Specifically, there are many sensors on the plane and the functions are coupled, and these sensors perform different control programs. Flight data sensors such as accelerometers, gyroscopes, altimeters, etc. are used to monitor the attitude, position and speed of the aircraft in real time; environmental sensors such as temperature sensors, barometric pressure sensors, engine speed sensors, etc. are used to monitor changes in the flight environment; engine sensors such as oil pressure sensors, temperature sensors, engine speed sensors, etc. monitor the running state of the engine. The data volume of these sensors reaches hundreds or even more, and they simultaneously read and modify shared data, such as real-time state parameters of the aircraft. The following problems may exist when multiple sensors simultaneously read and modify shared data: 1) data race: multiple sensors simultaneously access the same shared data area, which may cause data inconsistency; 2) synchronization problem: data synchronization between sensors is very cumbersome and prone to errors under high real-time requirements; 3) difficulty in code verification: traditional code detection methods are insufficient for detecting code involving multiple system interactions and complex interactions, and it is difficult to ensure that thousands of lines of code or more in sensor control will not have errors.

[0076] Therefore, the above problems can be solved by using a model and code bidirectional cross method, specifically:

[0077] 1) Model establishment

[0078] A time automaton model of the aircraft sensor control program is established using UPPAAL, which describes the process of sensor data reading, data processing and shared data modification, and extracts the core logic and timing characteristics in the control program code.

[0079] 2) Code conversion

[0080] The sensor control program is converted to C code through rule conversion and optimization to ensure that the converted C code accurately reflects the operation logic in the model, especially the read-write and sensor synchronization logic and timing relationship of shared data.

[0081] 3) Model-code bidirectional cross verification

[0082] The detection results of the model side and the detection results of the code side are compared and verified for consistency and correctness, and the verification results of the model-code bidirectional cross verification are obtained, and the problems detected are improved.

[0083] (1) System modeling

[0084] Based on the above practical application background, the aircraft sensor control program is modeled as two independent timed automata for the aircraft accelerometer and gyroscope. In each time, the aircraft attitude from the shared data area is read and updated after the sensor measurement. This process can be modeled as a multi-threaded program with two processes, the accelerometer process P1 and the gyroscope process P2, running concurrently, which simultaneously operate on the aircraft attitude variable (global variable x) in the shared data area and perform a subtraction operation and check the result in each iteration. The concurrent operation is formally modeled and verified by UPPAAL to assess whether the concurrent operation will cause data race or inconsistency, and to check whether the program satisfies some specific properties such as safety, consistency, and integrity.

[0085] The specific modeling process is as follows:

[0086] First, set the global variable declaration: variable x of int type, and initialize x to 0 and the channel variable reset. Among them, x represents the global variable shared by the processes, and reset is a channel type that can realize the synchronization and communication between processes in the model, allowing different concurrent processes to perform data transmission and synchronization operations, thereby realizing the interaction and coordination between concurrent programs. Through the channel, different processes can send and receive messages to coordinate and synchronize in the system.

[0087] Second, establish the aircraft accelerometer process POne (as shown in Figure 2 ): set its local variable y1 to int type and initialize it to 0; establish the gyroscope process PTwo (as shown in Figure 3 ): set the local variable y2 to int type and initialize it to 0. Combine the aircraft accelerometer process and the gyroscope process into a local aircraft sensor system and use UPPAAL for simulation. Among them, the idle state is the initial state; want is the state after variable initialization; wait is the waiting state; cs is the state after updating the y1 or y2 variable; ct is the state after updating the aircraft attitude angle x variable, and it is specified that x cannot be less than 0.

[0088] (2) Model verification

[0089] As shown in Figure 4 , the UPPAAL simulator result shows that a deadlock occurs when the process transitions from the wait state to the cs state. Record this problem in the "model checking problem description". Analyze the deadlock problem and find that no specific operation is performed in the process from the ct state to the wait state, and there is a resource conflict at some time, causing a deadlock. (For example, the P2 process has received the channel reset instruction, while the P1 process still stays in the wait state, which will cause a deadlock when transitioning from the wait state to the cs state.)

[0090] (3) Model verification and analysis

[0091] The modeling process is analyzed, and the modeling process is changed as shown in Figure 5 , Figure 6 .

[0092] First, the global variable z of int type and the channel type variable reset are declared; the aircraft accelerometer process POne is declared, and the POne process includes a local int type variable yl, which is initialized to 0; the gyroscope process PTwo is declared, and the PTwo process includes a local int type variable y2, which is initialized to 0. At the same time, in the model declaration part, POne process and PTwo are two system processes P1 and P2.

[0093] The system simulates two processes POne and PTwo of the system under the shared variable (aircraft attitude variable z), POne process adds 1 to the global variable z every time loop, PTwo process subtracts 1 from the global variable z every time loop, and requires that x in the system cannot be less than 0, and the path in this case is verified by UPPAAL.

[0094] (4) Property verification

[0095] According to the built model, the simulator is used for simulation, and the verifier is used for verification, and the results are as follows.

[0096] ① Simulator simulation

[0097] Using the simulator to simulate, it is found that when the simulator simulates the interaction times to reach 32766 times, the type overflow problem occurs. The model cannot handle values greater than 32767, as shown in Figure 7 .

[0098] ② Verifier verification

[0099] Verify whether the condition system satisfies the condition that "for any case, as long as it is in the P1.wait state, the aircraft attitude variable z will always satisfy > 0", and give the constraint condition: A [] P1. wait imply z> 0, and verify it in the verifier. The verifier result shows: "does not satisfy the property". It is indicated that in the wait state of P1 process, the value of z is not always greater than 0.

[0100] Verify the condition that "there is a path in the system so that the system satisfies the aircraft attitude variable z equal to 0 when it is in the P1.wait state", and give the constraint condition: E<> P1. wait and z==0, and verify it in the verifier. The verification result shows: "satisfies the property". It is indicated that in the wait state of P1 process, there is a case that the value of z is equal to 0.

[0101] To verify the condition "there is a path in the system such that the system satisfies the condition that the aircraft attitude variable z is less than 0 when in the P1.wait state", the constraint condition E<>P1.wait and z<0 is given, and the verification is performed in the verifier. The verification result shows that "Assignment of value '32768' to variable 'P2.y2' is out of range on line 1 of Project / PTwo / wait→wait / assignment", indicating that the model cannot verify whether the wait state in the P1 process is less than 0, and the value is out of range.

[0102] Similarly, to verify whether for any state space, the condition that the aircraft attitude variable z is greater than or equal to 0 when in the P1.wait state is satisfied, the constraint condition A[]P1.wait imply z>=0 is given, and the verification is performed in the verifier. The verification result shows that "Assignment of value '32768' to variable 'P2.y2' is out of range on line 1 of Project / PTwo / wait→wait / assignment", indicating that the model cannot verify whether the wait state in the P1 process is always greater than or equal to 0, and the value is out of range.

[0103] In the "model checking problem description", the problem "number range out of [-32768, 32767], UPPAAL model cannot verify the relevant situation" that occurs during the model checking process is recorded.

[0104] (5) Model-code conversion

[0105] In view of the above situation that UPPAAL cannot verify, the C code generated by UPPAAL will be detected again using a C code detection tool. First, convert UPPAAL to an XML file, click "File / Model Save As" to convert the UPPAAL model to XML format; then convert the XML language to the corresponding C code, mainly converting the elements of location, transition, variable and clock in the model to variable and function representation in C language.

[0106] (6) Code verification

[0107] Apply code verification tools (such as CBMC, ESBMC) to verify the C language file converted from the model in step (5), and the specific process is as follows.

[0108] ① CBMC detects C code

[0109] The CBMC is used to detect the C language file. The CBMC 5.88 version program is selected and runs under the Linux platform. The configuration parameters are as follows:

[0110] --trace: print the specific variable that does not meet the assertion;

[0111] --unwind: loop expansion 3 times.

[0112] The detection result shows "Violated property: file / src / test.c function P2 line 21 thread 2 assertion x>=0", which indicates that the CBMC tool finds that the variable x may be 0 at the 21st line of the code. The result of the CBMC detection of the C language file is recorded in the "code inspection problem description".

[0113] ②ESBMC detects C code

[0114] The ESBMC 7.2.0 version program is selected and runs under the 64-bit Windows platform. The configuration parameters are as follows:

[0115] --context_bound 2: context switching 2 times;

[0116] --no-unwinding-assertions: disable the assertion of the number of loop expansion times;

[0117] --unwind 3: loop expansion 3 times.

[0118] After detection, the result shows "Violated property: file / src / test.c function P2 line 21 thread 2 assertion x>=0", which indicates that the aircraft attitude variable x may be 0 at the 21st line of the code. The result of the ESBMC detection of the C language file is recorded in the "code inspection problem description".

[0119] (7) Model code bidirectional cross-validation

[0120] The "model inspection problem description" and the "code inspection problem description" are fused to form the "model and code cross-validation problem set". The "model and code cross-validation problem set" in this example includes three problems of the original model producing a deadlock, type overflow, and the aircraft attitude variable x may be 0. According to the "model and code cross-validation problem set" formed, the system model is modified until no related problem is reported.

[0121] In summary, this case illustrates the importance and value of model and code cross-validation through the modification of shared variables (aircraft attitude variables) by aircraft accelerometers and gyroscopes. This not only allows for more comprehensive problem detection from both the model and code sides, but also promotes the accuracy and completeness of model and code detection by integrating the results of model and code detection. Finally, the detection results can be returned to the system side, and through continuous correction, the goal of detecting problems and correcting the system is achieved.

Claims

1. A model-code cross-validation analysis method based on UPPAAL, characterized in that, The specific steps are as follows: Step (1) System modeling: The system is described as a time-based automaton model called UPPAAL. The system described by UPPAAL is represented as M. Step (2), Model Validation: Use UPPAAL's validator to perform initial syntax correctness validation to check the basic correctness of the model; if M meets the initial syntax correctness criteria, Verify(M) returns true and the next validation step is performed; if M does not meet the initial syntax correctness criteria, Verify(M) returns false and gives the specific error location and error reason, further modify the model syntax structure, repeat step (2) until M meets the initial syntax correctness criteria, that is, Verify(M) returns true; Step (3), Model Validation Analysis: If Verify(M) is true, then perform dynamic model validation. Starting from the initial state, simulate the dynamic changes of the state and check the changes of variable values ​​during the dynamic changes to detect whether there is a deadlock problem in the model. Let the deadlock problem be represented as Deadlock(M). If there is a deadlock in the system, Deadlock(M) returns true. Record the deadlock problem in the model validation problem description, modify the system structure, and return to step (2) until there is no deadlock problem in the system, that is, Deadlock(M) returns false, and then proceed to the subsequent attribute validation steps. Step (4), Attribute Verification: Suppose that the system model M must satisfy attribute P, then execute Verify(M, P); if Verify(M, P) returns true, then the model is considered correct; if Verify(M, P) returns false, then these problems are recorded in the model verification problem description. Step (5), Model-to-Code Conversion: Convert the UPPAAL model M into an XML representation M X Use a model conversion tool to convert M X Convert to C language file M C ; Step (6), code verification: Use a code verification tool to verify the C language file converted in step (5); if the verification process VerifyCode(C) returns true, it proves that the code is correct; If the verification process VerifyCode(C) returns false, it means that the code verification detected a problem, and this problem will be recorded in the code detection problem description. Step (7), Model-code cross-validation: Integrate the problems verified or detected from the model verification problem description and the code detection problem description to form a model-code cross-validation problem set; and make system modeling corrections based on the model-code cross-validation problem set.

2. The UPPAAL-based model-code cross-validation analysis method according to claim 1, characterized in that: In step (1), the UPPAAL time automaton model is specifically as follows: Let S represent the set of locations, δ represent the set of transitions, s0 represent the initial state, and C represent the set of clocks. Then, the system is represented by a quadruple A = (S, δ, s0, C) through the UPPAAL time automaton; its behavior is represented as follows: δ: S×Guards×S→Synchronization, where Guards and Synchronization describe the state transition rules and communication mechanisms; the state evolution of the system is represented as Path(G)=∑ e∈E w(e), where G represents the system state graph, e is an edge in the edge set E, and each edge e in the edge set E has a weight function w(e) representing the time or resource consumption of the state transition.

3. The UPPAAL-based model-code cross-validation analysis method according to claim 1 or 2, characterized in that: In step (2), let ∑X be the set of UPPAAL model syntax rules, and for any model M, it should belong to the set of legal models ∑. valid X, i.e., M∈∑ valid X; Define a validator function Verifier_Syntax(M) to check the correctness of the model's syntax. If model M satisfies all syntax rules, Verifier_Syntax(M) returns true; if Verifier_Syntax(M) does not satisfy the syntax rules, Verifier_Syntax(M) returns (false, error_loc, error_reason); where false indicates that the syntax check failed, error_loc indicates the location of the error, and error_reason indicates the reason for the error.

4. The UPPAAL-based model-code cross-validation analysis method according to claim 3, characterized in that: The initial syntax correctness verification is represented as: If Verifier_Syntax(M) returns true, continue with subsequent verification steps; if Verifier_Syntax(M) returns false, further modify the model syntax structure according to the error location and cause, and repeat step (2) until Verifier_Syntax(M) returns true, i.e. Among them, M (k) Let F represent the model after the k-th correction; let F represent the set where Verifier_Syntax(M) returns false, then F is expressed as F = {M|Verifier_Syntax(M) = false}, and the correction process of model M is equivalent to finding the complement of F. The elements, namely 5. The UPPAAL-based model-code cross-validation analysis method according to claim 1, characterized in that: In step (4), the specific process of verifying Verify(M, P) is as follows: Let p represent an attribute, P represent the set of attributes to be verified, then p∈P represents a certain condition that the model must satisfy; define a verifier function Verifier_Property(M, p) to check whether the model M satisfies the attribute p, and let property_reason represent the specific reason why the attribute is not satisfied.

6. The UPPAAL-based model-code cross-validation analysis method according to claim 5, characterized in that: The process by which the validator function checks whether the model M of Verifier_Property(M, p) satisfies attribute p is represented as follows: Furthermore, P = {p1, p2, ..., p} m The attribute validation process is represented as follows: Let the problem record set be ε, and record the information of Verifier_Property(M, p) = (false, property_reason) in ε, that is... ε={(p, property_reason)|Verifier_Property(M, p)=false}.

7. The UPPAAL-based model-code cross-validation analysis method according to claim 1, characterized in that: In step (5), the specific operation process is as follows: The first step is to convert the UPPAAL model M into an XML representation; this includes: converting the template into XML tags and their attributes; and converting the system definition into XML tags and their attributes. Let the UPPAAL model M contain n templates T1, T2, ..., T... n If the system is defined as S, then the XM representation of model M is M. XML Including the template part and system definition section S XML Furthermore, M XML ={T XML S XML }; The second step is to convert the XML file into a C language file; this includes parsing the XML representation and generating C code. First, the XML representation is parsed. Let the conversion tool for XML to C language be defined as T. c Use the conversion functions of the conversion tool Tc. Secondly, use T c Analysis of M XML Generate intermediate structure ψ: ψ = parse(M XML Finally, the corresponding C language file M is generated using the parsed intermediate structure ψ. C M C =generate_C_code(ψ).

8. The UPPAAL-based model-code cross-validation analysis method according to claim 7, characterized in that: The specific process of code verification in step (6) is as follows: First, input the verification model: input the C language file M generated in step (5). C As input, the C language file is validated using code verification tools CBMC, ESBMC, and SPIN; let the validation function of the code verification tool be Y, and the code verification result set be R. verify The code verification process can be represented as: Y:M C →{true, false}, and at the same time, R verify =Y{M C }; where R verify =true indicates that the code verification is correct, R verify =false indicates that the code detection method detected an error; finally, R verify The result of `=false` is stored in the code detection problem description.

9. The UPPAAL-based model-code cross-validation analysis method according to claim 1, characterized in that: In step (7), the specific process of cross-validation between the model and the code is as follows: First, the problem is summarized; let the set of model detection problems be P. model-check The set of code detection problems is P. code-verify The set of model and code cross-validation problems is P. cross-validation Then P cross-validation =P model-check ∪P code-verify ; Among them, P model-check ={p1, p2, ..., p m }, P code-verify ={q1, q2, ..., q n }, P cross-validation ={r1, r2, ..., r k };k≤m+n;r i It is a merge p i and q i The obtained question items; secondly, according to P cross-validation The problems in the model are used to correct the system model; let the correction function be... The input is the current system and the set of problems, and the output is the revised new system model, represented as: Right now The corrected model M′ and the corresponding C code file M′ C Re-enter the model detection and code detection loop, return to step (1), until the verification result is true, that is, no new problem description is generated, i.e., |P cross-validation |=0.

Images