Lustre-to-c code verification method based on symbolic execution

Abstract

This invention relates to a method for verifying Lustre-to-C translation code based on symbolic execution, belonging to the field of embedded software development. Addressing the paradigm differences between Lustre programs and target C code, this invention first constructs formal semantic models of both at the time-step granularity. Then, the Lustre source program and the compiled C code are transformed into unified intermediate representations, and the execution trajectories of both are explored in parallel under the same input environment based on path-sensitive symbolic execution technology. During symbolic execution, combining Lustre's unique clock semantics and timing constraints, equivalence verification conditions covering variable states, clock enable, and output behavior are dynamically generated and automatically determined by the SMT solver. This invention effectively compensates for boundary scenarios that traditional testing struggles to cover, improving the reliability and certification efficiency of embedded control software.

Description

Technical Field

[0001] This invention belongs to the field of embedded software development, specifically relating to a method for verifying Lustre-to-C translation code based on symbolic execution. Background Technology

[0002] With the increasing demands for software reliability in safety-critical systems such as aviation, aerospace, rail transportation, and nuclear power, Model-Based Development (MBD) has become the mainstream paradigm for developing highly reliable embedded software. In this paradigm, designers typically use modeling languages ​​with strict formal semantics to define system behavior, and then use automated tools to convert the model into executable code for the target platform. This reduces errors introduced by manual coding and improves development efficiency and software quality.

[0003] Lustre, a typical synchronous dataflow modeling language, is widely used in the modeling and verification of safety-critical systems due to its clear temporal semantics, support for formal analysis, and strong mathematical foundation. For example, the French SCADE toolchain is based on a Lustre variant. In practical engineering, Lustre models typically need to be automatically translated into ANSI C code using a code generator for deployment on embedded target machines.

[0004] However, while automated code generation improves development efficiency, the accuracy of the translation process itself lacks an effective guarantee mechanism. On the one hand, Lustre's synchronous semantics (such as implicit global clocks, deterministic execution, and side-effect-free computation) are fundamentally different from the sequential, state-driven execution model of C. On the other hand, existing code generation tools mostly rely on empirical rules for syntax conversion, making it difficult to guarantee that the generated C code is completely equivalent to the original Lustre model in all input sequences and timing scenarios. Once semantic deviations occur during the translation process (such as incorrect variable initialization, clock alignment errors, improper array boundary handling, etc.), the generated code will exhibit behaviors inconsistent with the model's expectations at runtime, seriously threatening system security.

[0005] This invention addresses the application of synchronous dataflow languages ​​in safety-critical systems, particularly in the compilation process from a model language to a target language. It proposes a translation validation approach to formally verify key compilation transformations. Specifically, this invention focuses on the semantic alignment and translation correctness between synchronous dataflow languages ​​such as Lustre and the target language. By introducing Translation Validation (TV) technology, it performs post-compilation verification of the results of a single compilation, ensuring the semantic equivalence of the translation under specific logic. At the implementation level, this invention parses and extracts key morphemes such as variable type declarations, function calls, and conditional expressions from the syntax trees of the model and target languages, and performs corresponding mappings based on heuristic rules and a formal semantic framework. Summary of the Invention

[0006] (a) Technical problems to be solved The technical problem this invention aims to solve is how to provide a method for verifying Lustre-to-C translation code based on symbolic execution, in order to address the issue that when synchronous data stream languages ​​such as Lustre are automatically converted to C, the generated C code may have semantic inconsistencies with the original model, thereby jeopardizing system security.

[0007] (II) Technical Solution To address the aforementioned technical problems, this invention proposes a Lustre-to-C translation code verification method based on symbolic execution, which includes the following steps: The first step is to extract the control flow and data flow structures from the Lustre source program and the generated C code. After the Lustre2C compiler completes the translation, the Lustre program and the generated C code are extracted in a structured manner. The key is to identify the node calls, clock enable conditions, and instantaneous assignment semantic units in the Lustre program and map them to the loop bodies, if-else branches, and state variable update logic in the C code, laying the foundation for subsequent path alignment. The second step is to perform branch-level semantic matching on the execution paths before and after translation based on symbolic execution. Using symbolic execution techniques, we explore the behavioral paths triggered by all possible input combinations in a Lustre program within a time step, as well as all control flow paths of the corresponding iterations in the C code within the main loop. By generating precise path constraints for each path, we establish a semantic correspondence between Lustre time step behavior and C code branch execution, and perform consistency modeling on the output variables and state update expressions under the matching paths. The third step is to construct the path equivalence verification formula and submit it to the SMT solver for counterexample search. The equivalence assertions of the output and state variables under each matching path are encoded into a first-order logic formula, and combined with their respective path constraints to form a verification condition. Then, the SMT solver is called to determine the satisfiability of the formula: if there is an input that satisfies the constraints but makes the equivalence not hold, then the input is a counterexample of translation inconsistency; if none of the path pairs can satisfy the counterexample condition, then it can be determined that the translation from Lustre to C is correct within the covered semantic range.

[0008] This invention also provides a method for verifying Lustre-to-C translation code based on symbolic execution, the method comprising the following steps: (a) Perform syntactic and semantic analysis on the Lustre source program and construct the Lustre abstract syntax tree; (b) Parse the target C code generated by the Lustre to C automatic translation tool and construct a C abstract syntax tree; (c) Based on the semantics of synchronous data streams, establish the structural mapping relationship and semantic equivalence constraints between Lustre abstract syntax tree and C abstract syntax tree; (d) Use the symbolic execution engine to explore the path of the C program corresponding to the C abstract syntax tree, and generate symbolic execution paths and corresponding output expressions; (e) Generate the desired output constraints based on the temporal behavior and input-output specification of the Lustre model; (f) Perform a formal comparison between the symbolic output expression obtained in step (d) and the expected output constraint in step (e), and use the SMT solver to determine whether there is a semantic inconsistency; if there is, report the verification failure, otherwise determine that the translation result is correct.

[0009] (III) Beneficial Effects This invention proposes a method for verifying Lustre-to-C translation code based on symbolic execution. This method has the following main technical advantages and practical effects: (1) This method systematically explores all feasible execution paths in the Lustre time step and C code control flow through symbolic execution, and generates precise path constraints for each path. This enables the verification coverage to reach a path-sensitive level, effectively avoiding hidden semantic biases caused by uncovered branches.

[0010] (2) When inconsistencies exist in the translation, the SMT solver can not only determine the inequivalence, but also automatically generate specific input counterexamples that satisfy the path constraints but lead to differences in output or state. These counterexamples can directly reproduce the translation error, providing developers with clear debugging clues and significantly shortening the "verification-repair" iteration cycle, which is especially suitable for embedded software development scenarios with high reliability requirements.

[0011] (3) This verification framework is compatible with the existing Lustre2C compiler. It only needs to perform symbolic execution modeling based on its inputs and outputs, thus improving industrial applicability. Attached Figure Description

[0012] Figure 1 This is a block diagram of the method of the present invention. Detailed Implementation

[0013] To make the objectives, contents, and advantages of the present invention clearer, the specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples.

[0014] In model-based embedded software development processes, synchronous dataflow languages ​​such as Lustre are often used to model safety-critical systems, which are then automatically converted into C language implementations using code generation tools. However, due to the complexity of the translation process and the lack of effective verification methods, the generated C code may contain semantic inconsistencies with the original model, thereby jeopardizing system security. To address this issue, this invention proposes a symbolic execution-based verification method. By analyzing the structure and semantic mapping of Lustre and C syntax trees, a formal comparison and correctness assurance of the translation results can be achieved.

[0015] This invention relates to a symbolic execution-based method for translating and verifying Lustre to C code, aiming to provide a high-reliability guarantee of semantic correctness for C code compiled from the synchronous dataflow language Lustre. Addressing the paradigm differences between the Lustre program and the target C code (such as mismatches between implicit clocks, instantaneous responses, and explicit loop control structures), this method first constructs a formal semantic model of both at the time-step granularity. Then, it transforms the Lustre source program and the compiled C code into unified intermediate representations, and, based on path-sensitive symbolic execution technology, explores their execution trajectories in parallel under the same input environment. During symbolic execution, it dynamically generates equivalence verification conditions covering variable states, clock enable, and output behavior, incorporating Lustre's unique clock semantics and timing constraints, and submits these conditions to the SMT solver for automatic logical equivalence determination. If all verification conditions on reachable paths are met, it confirms that the translation has preserved the key semantics of the source program, thus achieving automated and high-coverage verification of the translation results. This invention is particularly applicable to the trusted verification of Lustre program compilation products in safety-critical fields such as avionics and rail transportation. It can effectively compensate for boundary scenarios that traditional testing cannot cover, and improve the reliability and certification efficiency of embedded control software.

[0016] The purpose of this invention is to solve the problem of formal verification of key domain software in model-based software development tools in the aerospace field, and to realize the translation and verification from the model language (extended Lustre language) to the target language (C language).

[0017] The first step is to extract the control flow and data flow structures from the Lustre source program and the generated C code. After the Lustre2C compiler completes the translation, the Lustre program and the generated C code are extracted in a structured manner. The focus is on identifying semantic units such as node calls, clock enable conditions, and instantaneous assignments in the Lustre program, and mapping them to loop bodies, if-else branches, and state variable update logic in the C code, laying the foundation for subsequent path alignment.

[0018] The second step is to perform branch-level semantic matching on the execution paths before and after translation based on symbolic execution. Using symbolic execution techniques, we explore the behavioral paths triggered by all possible input combinations within a time step of the Lustre program, as well as all control flow paths of the corresponding iterations in the C code's main loop. By generating precise path conditions for each path, we establish a semantic correspondence between Lustre time-step behavior and C code branch execution, and perform consistency modeling on the output variables and state update expressions under matching paths.

[0019] The third step is to construct the path equivalence verification formula and submit it to the SMT solver for counterexample search. The equivalence assertions of the output and state variables under each matching path are encoded into a first-order logic formula, which is then combined with their respective path constraints to form the verification condition. The SMT solver (such as Z3) is then called to determine the satisfiability of this formula: if there exists an input that satisfies the constraints but makes the equivalence invalid, then that input is a counterexample of translation inconsistency; if none of the path pairs satisfy the counterexample condition, then the translation from Lustre to C can be determined to be correct within the covered semantic range.

[0020] Example 1: Invention process as follows Figure 1 As shown, the specific implementation steps are as follows: The first step is to extract the control flow and data flow structures from the Lustre source program and the generated C code. This step aims to construct structured intermediate representations (IRs) for the Lustre program and the target C code, respectively, in order to establish a semantic mapping and verification foundation between the two.

[0021] The structured extraction of Lustre programs mainly includes parsing Lustre syntax, constructing an abstract syntax tree, extracting variable information, removing time identifiers, and constructing an intermediate representation.

[0022] Lexical and syntax analysis are performed by an ANTLR-based lexical analyzer and syntax analyzer, constructing an abstract syntax tree. Using Lustre nodes as the basic unit of processing, the input variable list, output variable list, and local variables are extracted, and the scope information of the corresponding variables is established. Within the scope, def-use pairs are further identified and extracted to characterize data dependencies. The def-use pair, a definition-value pair, is a core concept in program analysis, used to describe the association between the position where a variable is assigned a value and the position where that value is used; the association is represented as (d1, u1). As shown below: The value defined in line 1 is used in line 2: 1: x = 5; / / d1: the point where x is defined 2: y = x + 2; / / u1: The point where x is used (using the value of d1) Building data dependencies is the foundation for program slicing and taint analysis.

[0023] Eliminating time identifiers: For the timing operators specific to the Lustre language, this invention uses static expansion and the introduction of state variables to perform semantic de-timing processing, thereby eliminating explicit timing operators and converting them into equivalent state-driven forms. The core timing operators to be processed include: `when_every_expr : not_expr ( WHEN clock_expr )*;` represents an expression that is activated under a specific clock condition. Here, `when_every_expr` is the grammar definition (production rule), `when_every_expr`: the left-hand side is the name of the grammar non-terminal (which can be understood as the "name of the grammar rule"), `:` indicates "defined as", and `not_expr ( WHEN clock_expr )*`: the right-hand side is the expanded form of the rule.

[0024] `pre_expr : PRE uarith_expr | reverse_expr;` is used to reference the value of the previous time step.

[0025] arrow_Expr : conditional_lor_expr( ARROW conditional_lor_expr )*; indicates assigning an initial value.

[0026] primary_expr: FBY '(' list ';' expr ';' list ')'; indicates a deferred operation, specifying the initial historical sequence.

[0027] For the aforementioned timing operators, this method introduces a corresponding past state copy variable into the intermediate representation (the introduction is explained in the table below), and updates this copy variable at the end of each execution step (tick), thereby transforming the synchronous data flow semantics into a static single assignment (SSA) style representation with explicit state transitions. Ultimately, the Lustre program is transformed into a Lustre structured intermediate representation IR_L without explicit timing operators but retaining complete timing semantics, including the control flow skeleton, data dependency graph, and clock partition information.

[0028] Operator Semantics The type of the introduced copy variable quantity WHEN Clock conditions The modified expression introduces an enable condition. 0 PRE The value of the previous beat Single historical state variable 1 ARROW Assign initial value Initialize flags 1 FBY Delayed sequence Fixed-length history buffer n The structured extraction of C code includes: parsing the target C code generated by the Lustre-to-C translation tool using an ANTLR-based lexical and syntax analyzer, constructing an abstract syntax tree for the C language, and thus obtaining an intermediate representation of C.

[0029] In the preprocessing stage, all macro definitions and constant declarations are first parsed and recorded, and multi-file projects are merged into a single logical unit to ensure global symbol consistency. Subsequently, the local scope of each function (especially the generator function corresponding to the Lustre node) is constructed, and the following information is extracted to build an intermediate C representation: A function's control flow graph (CFG) is used to depict the execution path; Data dependencies, including variable definitions, usage, and data flow across statements; State variable identification (such as static variables and global structure members) is often used to simulate historical states in Lustre (such as the implementation of pre or fby).

[0030] After completing the intermediate representations of Lustre and C code, the system constructs the path exploration framework required for symbolic execution based on the C intermediate representation IR_C: symbolically modeling branch conditions, collecting path constraints, and tracking the symbolic expressions of output variables under different inputs and paths. The variable relationships obtained in this process will serve as key inputs for subsequent formal comparisons with the expected behavior of Lustre.

[0031] The second step involves performing branch-level semantic matching on the execution paths before and after translation based on symbolic execution. This step utilizes symbolic execution technology to explore paths for the intermediate representations of Lustre and C respectively, and within the same logical execution step, performs semantic equivalence verification on the branch paths that may be triggered by the two under the same input conditions and states.

[0032] In this step, the first step is to create a set of symbolic input variables for the Lustre node and its corresponding C function node. and , The number of symbolic input variables for Lustre nodes. The number of symbolic input variables for C function nodes; the set of symbolic variables introduced for historical states with timing identifiers. , Introduce a number of symbolic variables for historical states. Based on the variable mapping relationship established in the first step, and by adding equality constraints, the variable set is determined based on the variables used in the C code to simulate Lustre inputs and states. and and Perform an explicit association to ensure that both parties begin execution within a aligned symbolic environment. An example of an association is shown below: For example, the lustre node is: node Counter (inc: bool; reset: bool) returns (count: int); let count = 0 ->if reset then 0 else (pre count + 1) when inc; tel Create symbolic variables for the input of the Lustre node: Il={il1,il2}={inc_l,reset_l} The C implementation function prototype is: int counter(int inc, int reset, int *state); Input variables on the C side (including explicit inputs and state variables): Ic={ic1,ic2,ic3}={inc_c,reset_c,state_c} In Lustre, pre-count introduces a historical state and creates symbolic variables: Pl={pl1}={pre_count_l} The relationships are established as follows: Lustre symbol C symbol meaning inc_l inc_c Count enable input reset_l reset_c Reset Input pre_count_l state_c Historical status (count value of the previous time step) Its SMT constraints are as follows: Lustre side symbolic variable (declare-const inc_l Bool) (declare-const reset_l Bool) (declare-const pre_count_l Int) C-side symbolic variable (declare-const inc_c Bool) (declare-const reset_c Bool) (declare-const state_c Int) (declare-const count_c Int) Constraint: Inputs are equal (assert (= inc_l inc_c)) (assert (= reset_l reset_c)) Constraint: State equality (assert (= pre_count_l state_c)) The semantics of Lustre (translated into logical formulas) ; count = if init then 0 else (if reset then 0 else (pre_count + 1)when inc) (define-fun count_l () Int (ite init 0 (ite reset_l 0 (ite inc_l (+ pre_count_l 1) pre_count_l)))) The semantics of C (translated into logical formulas) ... Constraint: Outputs are equal (assert (= count_l count_c)) The Lustre section, for the current step, collects two types of branch condition information based on the data flow graph: conditions for conditional expression branches (if-then-else) and enable conditions for clock-enabled conditional branches (such as expr when clk, which is activated only when clk = true), creating a path constraint for each feasible execution path. , , ..., Each executable path corresponds to a symbolic variable mapping table, where L represents the association constraints of Lustre and n represents the number.

[0033] Part C performs symbolic execution on the objective function, advancing along the basic blocks through the control flow graph and generating path predicates for each branch point (such as if (cond), switch). Symbolic execution is then performed on individual ticks. This ultimately yields the path constraints associated with the output. , , ..., C represents the association constraint of C, and m represents the quantity.

[0034] Matching is performed separately for different conditional branches; that is, when using constraints, for each pair of possible paths... Determine whether the input and path constraints are satisfied: that is, whether there are input / state assignments that simultaneously satisfy the constraints. and If satisfied, then construct semantic equivalence constraints after branch matching and adding path constraints: The third step is to construct the path equivalence verification formula and submit it to the SMT solver for counterexample search. This step performs a satisfiability check on the path constraints obtained by symbolic execution and uses SMT to perform a counterexample search.

[0035] The equivalence assertion between the output and state variable under each matching path is encoded into a first-order logic formula, and combined with their respective path constraints to form the verification conditions, including: after the second step of matching, first check... If the condition is met, it means that there exists the same input and initial state, and it is possible to enter that state. Construct a semantic equivalence verification formula: in, This means that all constraints from 1 to m are conjunct, which implies that all outputs are equal. and These represent the path constraints. and Below are the symbolic expressions of the corresponding output variables that map to each other. The meaning of this formula is: under the same input / state conditions that both sides can enter, their outputs must be equal.

[0036] The above formula is given to the SMT solver for judgment. If the formula is not always true, a counterexample is generated, including the specific input value, state value and different output result that triggered the defect.

[0037] Example 2: The implementation of the symbolic execution-based Lustre to C code translation verification method is mainly based on the following steps: (a) Perform syntactic and semantic analysis on the Lustre source program and construct the Lustre abstract syntax tree; (b) Parse the target C code generated by the Lustre to C automatic translation tool and construct a C abstract syntax tree; (c) Based on the semantics of synchronous data streams, establish the structural mapping relationship and semantic equivalence constraints between Lustre abstract syntax tree and C abstract syntax tree; (d) Use the symbolic execution engine to explore the path of the C program corresponding to the C abstract syntax tree, and generate symbolic execution paths and corresponding output expressions; (e) Generate the desired output constraints based on the temporal behavior and input-output specification of the Lustre model; (f) Perform a formal comparison between the symbolic output expression obtained in step (d) and the expected output constraint in step (e), and use the SMT solver to determine whether there is a semantic inconsistency; if there is, report the verification failure, otherwise determine that the translation result is correct.

[0038] Technical advantages and effects: This invention proposes a Lustre-to-C translation verification method based on symbolic execution, which has the following main technical advantages and practical effects: (1) This method systematically explores all feasible execution paths in the Lustre time step and C code control flow through symbolic execution, and generates precise path constraints for each path. This enables the verification coverage to reach a path-sensitive level, effectively avoiding hidden semantic biases caused by uncovered branches.

[0039] (2) When inconsistencies exist in the translation, the SMT solver can not only determine the inequivalence, but also automatically generate specific input counterexamples that satisfy the path constraints but lead to differences in output or state. These counterexamples can directly reproduce the translation error, providing developers with clear debugging clues and significantly shortening the "verification-repair" iteration cycle, which is especially suitable for embedded software development scenarios with high reliability requirements.

[0040] (3) This verification framework is compatible with the existing Lustre2C compiler. It only needs to perform symbolic execution modeling based on its inputs and outputs, thus improving industrial applicability.

[0041] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for verifying Lustre-to-C translation code based on symbolic execution, characterized in that, The method includes the following steps: The first step is to extract the control flow and data flow structures from the Lustre source program and the generated C code. After the Lustre2C compiler completes the translation, the Lustre program and the generated C code are extracted in a structured manner. The key is to identify the node calls, clock enable conditions, and instantaneous assignment semantic units in the Lustre program and map them to the loop bodies, if-else branches, and state variable update logic in the C code, laying the foundation for subsequent path alignment. The second step is to perform branch-level semantic matching on the execution paths before and after translation based on symbolic execution. Using symbolic execution techniques, we explore the behavioral paths triggered by all possible input combinations in a Lustre program within a time step, as well as all control flow paths of the corresponding iterations in the C code within the main loop. By generating precise path constraints for each path, we establish a semantic correspondence between Lustre time step behavior and C code branch execution, and perform consistency modeling on the output variables and state update expressions under the matching paths. The third step is to construct a path equivalence verification formula and use the SMT solver to perform a counterexample search. The equivalence assertions of the output and state variables under each matching path are encoded into a first-order logic formula, and combined with their respective path constraints to form a verification condition. Then, the SMT solver is called to determine the satisfiability of the formula: if there is an input that satisfies the constraints but makes the equivalence not hold, then the input is a counterexample of translation inconsistency; if none of the path pairs can satisfy the counterexample condition, then it can be determined that the translation from Lustre to C is correct within the covered semantic range.

2. The method for verifying Lustre-to-C translation code based on symbolic execution as described in claim 1, characterized in that, In the first step, the structured extraction of the Lustre program includes parsing the Lustre syntax, constructing an abstract syntax tree, extracting variable information, removing time identifiers, and constructing an intermediate representation. The structured extraction of C code includes: parsing the target C code generated by the Lustre-to-C translation tool using an ANTLR-based lexical and syntax analyzer, constructing an abstract syntax tree for the C language, and thus obtaining an intermediate representation of C.

3. The method for verifying Lustre-to-C translation code based on symbolic execution as described in claim 2, characterized in that, The process of parsing Lustre grammar, constructing an abstract syntax tree, and extracting variable information includes: lexical analysis and syntax analysis are performed by an ANTLR-based lexical analyzer and syntax analyzer to construct the abstract syntax tree; using Lustre nodes as the basic unit of processing, the input variable list, output variable list, and local variables are extracted, and the scope information of the corresponding variables is established; within the scope, def-use pairs are further identified and extracted to characterize data dependencies; where def-use pairs are defined value-use pairs used to describe the relationship between the position where a variable is assigned a value and the position where that value is used.

4. The method for verifying Lustre-to-C translation code based on symbolic execution as described in claim 2, characterized in that, The process of eliminating time identifiers and constructing intermediate representations includes: For the timing operators specific to the Lustre language, semantic de-timing is performed using static expansion and the introduction of state variables, thereby eliminating explicit timing operators and converting them into equivalent state-driven forms. The core timing operators to be processed include: `when_every_expr : not_expr ( WHEN clock_expr )` --- indicates an expression that is activated under a specific clock condition; pre_expr : PRE uarith_expr | reverse_expr --- used to reference the value of the previous time step; arrow_Expr : conditional_lor_expr ( ARROW conditional_lor_expr ) *---Indicates assigning an initial value; primary_expr: FBY '(' list ';' expr ';' list ')' --- indicates a deferred operation, specifying the initial historical sequence; For the aforementioned timing operators, a corresponding past state copy variable is introduced into the intermediate representation, and this copy variable is updated at the end of each execution step, thereby transforming the synchronous data flow semantics into a static single-assignment style representation with explicit state transitions. Finally, the Lustre program is transformed into a Lustre structured intermediate representation IR_L without explicit timing operators but retaining complete timing semantics, which includes the control flow skeleton, data dependency graph, and clock partition information.

5. The method for verifying Lustre-to-C translation code based on symbolic execution as described in claim 2, characterized in that, The process involves parsing the target C code generated by the Lustre-to-C translation tool using an ANTLR-based lexical and syntax analyzer to construct a C language abstract syntax tree, thereby obtaining an intermediate C representation, including: In the preprocessing stage, all macro definitions and constant declarations are first parsed and recorded, and multi-file items are merged into a single logical unit to ensure global symbol consistency. Subsequently, the local scope of each function is constructed, and the following information is extracted to construct an intermediate C representation: The control flow graph (CFG) of a function is used to depict the execution path; Data dependencies, including variable definitions, usage, and data flow across statements; State variable identification is used to simulate historical states in Lustre.

6. The method for verifying Lustre-to-C translation code based on symbolic execution as described in any one of claims 1-5, characterized in that, The second step includes: using symbolic execution techniques to explore paths for the intermediate representations of Lustre and C respectively, and within the same logical execution step, performing semantic equivalence verification on the branch paths that may be triggered by the two under the same input conditions and states.

7. The method for verifying Lustre-to-C translation code based on symbolic execution as described in claim 6, characterized in that, The second step specifically includes: First, create symbolic input variable sets for the Lustre node and its corresponding C function node. and , The number of symbolic input variables for the Lustre node. The number of symbolic input variables for C function nodes; the set of symbolic variables introduced for historical states with timing identifiers. , The number of symbolic variables is introduced to represent historical states; based on the variable mapping relationship established in the first step, equality constraints are added, and the variable set is determined based on the variables used in the C code to simulate Lustre inputs and states. and and Establish an explicit association to ensure that both parties begin execution within a aligned symbolic environment; The Lustre section, for the current step, collects two types of branch condition information based on the data flow graph: conditions for conditional expression branches and enable conditions for clock enable condition branches, creating a path constraint for each feasible execution path. , , ..., Each executable path corresponds to a symbolic variable mapping table, where L represents the association constraints of Lustre and n represents the number; Part C performs symbolic execution on the objective function, advancing along the basic blocks through the control flow graph, generating path predicates for each branch point; symbolic execution is performed on individual ticks; ultimately, the path constraints associated with the output are obtained. , , ..., C represents the association constraint of C, and m represents the quantity; Matching is performed separately for different conditional branches; that is, when using constraints, for each pair of possible paths... Determine whether the input and path constraints are satisfied: that is, whether there are input / state assignments that simultaneously satisfy the constraints. and If satisfied, then construct semantic equivalence constraints after branch matching and adding path constraints: 。 8. The method for verifying Lustre-to-C translation code based on symbolic execution as described in claim 7, characterized in that, In the third step, the equivalence assertion between the output and state variable under each pair of matching paths is encoded into a first-order logic formula, and combined with their respective path constraints to form the verification conditions, including: The equivalence assertion between the output and state variable under each matching path is encoded into a first-order logic formula, and combined with their respective path constraints to form the verification conditions, including: after the second step of matching, first check... If the condition is met, it means that there exists the same input and initial state, and it is possible to enter that state. Construct a semantic equivalence verification formula: in, This means that all constraints from 1 to m are conjunct, which implies that all outputs are equal. and These represent the path constraints. and The symbolic expression of the corresponding output variables that are mapped to each other; the meaning of this formula is: under the same input / state conditions that both sides can enter, their outputs must be equal.

9. The method for verifying Lustre-to-C translation code based on symbolic execution as described in claim 8, characterized in that, In the third step, the above formula is given to the SMT solver for judgment. If the formula is not always true, a counterexample is generated, including the specific input value, state value and different output result that trigger the defect.

10. A method for verifying Lustre-to-C translation code based on symbolic execution, characterized in that, The method includes the following steps: (a) Perform syntactic and semantic analysis on the Lustre source program and construct the Lustre abstract syntax tree; (b) Parse the target C code generated by the Lustre to C automatic translation tool and construct a C abstract syntax tree; (c) Based on the semantics of synchronous data streams, establish the structural mapping relationship and semantic equivalence constraints between Lustre abstract syntax tree and C abstract syntax tree; (d) Use the symbolic execution engine to explore the path of the C program corresponding to the C abstract syntax tree, and generate symbolic execution paths and corresponding output expressions; (e) Generate the desired output constraints based on the temporal behavior and input-output specification of the Lustre model; (f) Perform a formal comparison between the symbolic output expression obtained in step (d) and the expected output constraint in step (e), and use the SMT solver to determine whether there is a semantic inconsistency; if there is, report the verification failure, otherwise determine that the translation result is correct.

Images