High-safety PLC compiling verification method for nuclear energy automatic control system

Abstract

The invention discloses a high-safety PLC compiling verification method for a nuclear energy automation control system, and relates to the technical field of software engineering and nuclear energy control, and the method comprises the following steps: firstly, designing a PLC language subset ST-light suitable for the nuclear energy control system; secondly, constructing a semantic model of ST-light based on big step semantics; then, a trusted compilation algorithm from ST-light to Light is designed; comprising the steps of performing type checking to ensure variable type matching; a Light code is generated; a CompCert credible compiling chain is adopted to convert the Light into a target code; and finally, proving the semantic consistency of the designed trusted compilation algorithm by using a theorem proving technology. According to the method provided by the invention, system faults caused by compiling errors are avoided, so that the operation reliability of nuclear energy facilities is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of software engineering and nuclear energy control, and in particular to a high-security PLC compilation and verification method for nuclear energy automation control systems. Background Art

[0002] In nuclear power control systems, PLCs (Programmable Logic Controllers) are widely used for automated control, including critical aspects such as reactor cooling systems, fuel delivery, and radiation monitoring. Because compilation errors in PLC programs can pose safety risks, improving the reliability of PLC compilers is crucial for ensuring nuclear power system safety.

[0003] Traditional PLC (Programmable Logic Controller) compilers rely primarily on testing and manual checking to verify compilation correctness. However, this approach struggles to cover all possible code paths and cannot guarantee the correctness of the compilation process itself. Formal verification techniques can mathematically verify the correctness of compiler transformations, but currently there is limited research on formal verification of PLC (Programmable Logic Controller) compilers for the nuclear power sector. Summary of the Invention

[0004] The purpose of this invention is to provide a high-security PLC compilation verification method for nuclear energy automation control systems, which ensures the correctness of the PLC compilation process through formal verification technology and avoids potential security vulnerabilities.

[0005] To achieve the above object, the present invention provides a high-security PLC compilation and verification method for a nuclear energy automation control system, comprising the following steps:

[0006] Step 1: Design a PLC language subset ST-light suitable for nuclear power control systems to avoid grammatical ambiguity and improve verifiability;

[0007] Step 2: Build the semantic model of ST-light based on big-step semantics;

[0008] Step 3: Design a trusted compilation algorithm from ST-light to Clight, including: performing type checks to ensure variable types match; and generating Clight code.

[0009] Step 4: Use theorem proving techniques to prove the semantic consistency of the trusted compilation algorithm designed in step 3.

[0010] Preferably, the PLC language subset ST-light designed in step 1 for nuclear power control systems is improved at four levels, namely, the type level, the expression level, the statement level, and the declaration level; the specific improvements are as follows:

[0011] At the type level, compared to the IEC 61131-3 standard, an additional type is added, specifically the type pointing to the instance;

[0012] At the expression level, all expressions are annotated with their static type;

[0013] At the statement level, remove parameters from the call statement and change the state of the POU (Program Organization Unit) instance through a separate assignment form; and add an additional reset statement to reset the POU (Program Organization Unit) state to the initial condition, and a sequence statement for continuous execution of operations;

[0014] At the declaration level, function blocks, functions and programs are no longer distinguished. Instead, function blocks, functions and programs are uniformly regarded as POUs; each POU definition includes the identifier (id) of the POU (program organization unit), the definition of variables (pou_vars), the definition of temporary variables (pou_temps), the statement of the POU reset area (pou_reset) and the statement of the POU execution area (pou_exec).

[0015] Preferably, the ST-light semantic model in the semantic model of ST-light constructed based on big-step semantics in step 2 includes two evaluation environments, the first part is temporary memory, and the second part is global memory; wherein, the temporary memory is used to save the state of temporary variables, which is a mapping of variable names to values; the global memory is used to save the state of variables, and there are nested sub-instances, and the global memory contains two mappings, including variable name mapping to value and instance name mapping to sub-memory.

[0016] Preferably, the process of designing the trusted compilation algorithm from ST-light to Clight in step 3 is as follows:

[0017] S31. Design a type checking algorithm and perform type checking. During the annotation process, type-annotate the unannotated abstract syntax tree and check whether it is well-typed. If the check result is well-typed, proceed to the next step. Otherwise, report a type error.

[0018] S32. Design a code generation algorithm to convert ST-light programs into Clight code, and convert POUs into Clight code through compilation while maintaining semantic consistency; converting POUs into Clight code through compilation includes generating expressions and statements, where different types of expressions are converted into Clight expressions through the gen_exp function; and different types of statements are converted into Clight statements through the gen_stmt function;

[0019] Preferably, the process of converting different types of expressions into Clight expressions using the gen_exp function is as follows:

[0020] S321A, variables: For identifier id, gen_exp directly returns id;

[0021] S322A, Temporary variables: For a temporary variable temp(id), gen_exp returns _id, which indicates the naming convention of the temporary variable;

[0022] S323A, unary operation: For unary(e), gen_exp generates operands through gen_exp(e) and re-synthesizes the unary operation;

[0023] S324A, binary operation: For a binary operation (e1, e2), gen_exp recursively generates expressions for e1 and e2 and combines them into a binary operation;

[0024] S325A, Member access: For member access e.id, gen_exp generates an expression for e and appends the member access operation.

[0025] Preferably, the process of converting different types of statements into Clight statements through the gen_stmt function is as follows:

[0026] S321B, assignment statement: For the assignment statement e1:=e2, gen_stmt first calls gen_exp to generate the expressions of e1 and e2, and then combines them into an assignment statement;

[0027] S322B, function call: For the function call call(e), gen_stmt uses the T_exec function to generate a call statement, where gen_exp(e) is used to generate the parameter expression of the call;

[0028] S323B, reset operation: For the reset operation reset(e), gen_stmt uses the T_reset function to generate a reset statement and generates an expression for the reset target through gen_exp(e);

[0029] S324B, Compound statement: For compound statement s1; s2, gen_stmt recursively generates statements of s1 and s2 and concatenates them sequentially.

[0030] Preferably, the semantic consistency of the trusted compilation algorithm designed in step 3 is proved using theorem proving technology in step 4 as follows: the correspondence between ST-light and Clight environments is described by invariants to ensure the semantic consistency of the trusted compilation algorithm. The invariants are as follows:

[0031]

[0032] The meaning of the above invariants is as follows: define an invariant called match_states, for a given definition list pro and one of the POUs P, match the environments M and E of ST-light with the environments e and le of Clight and the memory addresses (b self ,δ self ) are associated; the invariant consists of three parts: var_repPEle indicates that ST-light's temporary memory E matches Clight's temporary environment le, and every temporary variable in E can find an equal value in le; Indicates that there is a pointer value named self in the Clight temporary environment le, whose value is ptr(b self ,δ self ); Indicates that ST-light's global memory M matches Clight's memory. For each variable x in M ​​and its nested instances, an offset value δ relative to the starting variable will be calculated based on the order of the variables in the definition. i ; Assume that the value of x in M ​​is v, and (b self ,δ self +δ i ) can also be read as c.

[0033] Therefore, the present invention adopts the above-mentioned high-security PLC compilation and verification method for nuclear energy automation control systems, which can effectively improve the security of PLC (programmable logic controller) code in nuclear energy control systems, avoid system failures caused by compilation errors, and thus improve the operational reliability of nuclear energy facilities.

[0034] The technical solution of the present invention is further described in detail below through the accompanying drawings and embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 This is an overall flow chart of a high-security PLC compilation and verification method for a nuclear energy automation control system according to the present invention;

[0036] Figure 2 The ST-light semantic model diagram provided by the embodiment of the present invention;

[0037] Figure 3 An example diagram of a type checking algorithm provided by an embodiment of the present invention;

[0038] Figure 4 This is an example diagram of the core method of code generation provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0039] The following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but rather merely represents selected embodiments of the present invention. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present invention without inventive effort shall fall within the scope of protection of the present invention.

[0040] See also Figure 1-Figure 4 A high-security PLC compilation and verification method for a nuclear energy automation control system includes the following steps:

[0041] Step 1: Design a PLC language subset, ST-light, suitable for nuclear power control systems to avoid grammatical ambiguity and improve verifiability. This PLC language subset, ST-light, suitable for nuclear power control systems, was improved at four levels: type level, expression level, statement level, and declaration level. The specific improvements are as follows:

[0042] At the type level, compared to the IEC 61131-3 standard, an additional type is added, specifically the type pointing to the instance;

[0043] At the expression level, all expressions are annotated with their static types; this approach enables us to analyze potential semantic issues in the code and provides the possibility of applying different semantic evaluation methods to variable expressions, making it easier to express type-overloaded semantics for functions. ST-light guarantees that each expression has no side effects, meaning that the program state is not modified when the expression is evaluated. This approach not only effectively avoids language ambiguity but also reduces the burden of semantic expression for complex expressions.

[0044] At the statement level, to unify the assignment behavior, parameters are removed from the call statement, and the state of the POU (Program Organization Unit) instance is changed through a separate assignment form. In addition, a reset statement is added to reset the POU (Program Organization Unit) state to the initial condition, and a sequence statement is added to execute operations continuously.

[0045] At the declaration level, function blocks, functions, and programs are no longer distinguished. Instead, they are all considered POUs. Each POU definition includes the POU (Program Organization Unit) identifier (id), variable definitions (pou_vars), temporary variable definitions (pou_temps), statements for the POU reset area (pou_reset), and statements for the POU execution area (pou_exec). Compared to standard ST, ST-light has the following features: variable types are simplified, with variables and temporary variables distinguished based on whether they retain their values ​​after each call. ST-light separates variable definitions from initialization expressions, placing the initialization content of related variables in the POU (Program Organization Unit) reset area. ST-light does not provide content related to functions.

[0046] Step 2. Build the semantic model of ST-light based on big-step semantics; big-step semantics, also known as natural semantics, is a mathematical method for defining the semantics of a programming language. It defines the execution process of a program by directly describing how the program's input is converted into output. Specifically, it includes two parts of the evaluation environment, the first part is temporary memory, and the second part is global memory. Among them, temporary memory is used to save the state of temporary variables, which is a mapping from variable name to value; global memory is used to save the state of variables, and there are nested sub-instances, and global memory contains two mappings, including variable name mapping to value and instance name mapping to sub-memory. For each type of expression and statement, we have corresponding semantic rules. Due to limited space, we selected some representative rules and listed them in Figure 2 Through this semantic description, we can clearly define the execution process of the ST-light program and ensure the consistency and correctness of the semantics. Figure 2The first two rules describe the evaluation of variable expressions. Based on type annotations, they are evaluated numerically and instance-wise, respectively. Temporary variables, since they cannot be instances, are directly evaluated numerically, as shown in Rule 3. Rules 4 and 5 are used to evaluate unary and binary expressions, respectively. The operands of the expression operators are evaluated first, followed by the invocation of their respective evaluation functions. The annotated type of the expression is passed as an additional parameter to the evaluation function, facilitating overloading and type conversions between different types. The evaluation function may fail. For example, when adding two expressions annotated with LINT and REAL, the addition requires implicit conversion of the operands to the same type. Because implicit conversions in ST must ensure numerical correctness, converting LINT to REAL or vice versa is illegal. Rules 6 and 7 are used to evaluate expressions accessing instance members of the form e.id. First, the subexpression e is evaluated for its instance type, resulting in a list of IDs, ids, indicating the instance. Then, the corresponding evaluation method is used based on the type annotation on the overall expression: if it is an instance method evaluation, id is directly inserted at the beginning of ids as the result. If it is a numeric type, the instance memory M' is first determined, and then the value corresponding to id is retrieved from the instance memory as the result.

[0047] Step 3: Design a trusted compilation algorithm from ST-light to Clight. This includes: performing type checking to ensure variable types match; generating Clight code; and using the CompCert trusted compilation chain to convert Clight into target code. The specific process is as follows:

[0048] S31. Design a type checking algorithm to perform type checking. During the annotation process, annotate the unannotated abstract syntax tree with a type and check whether it is well-typed. If the check result is well-typed, proceed to the next step; otherwise, report a type error. This process ensures the correctness and consistency of the ST-light program at the type level. The type checking algorithm is a function that annotates the unannotated abstract syntax tree with a type during the annotation process and checks whether it is well-typed, such as Figure 3 As shown. For the input AST section n, it will be discussed in categories: if n does not have child nodes, it will be annotated according to the definition or its own literal value; in the other case, that is, n has child nodes, all child nodes will be annotated first, and if it fails, it will return directly. Afterwards, if n is an expression, the type will be deduced based on the type of the child to get its own type. For example, for a binary arithmetic expression, its type will be the one with a larger range among the operands. If n is a statement, it needs to be checked according to the type rules. When an error occurs in any check or deduction operation, the algorithm will return;

[0049] S32. Design a code generation algorithm to convert ST-light programs into Clight code while maintaining semantic consistency. A significant difference of ST-light compared to the target language Clight is that it has certain object-oriented features. This feature allows multiple instances to be defined in the same POU (Program Organization Unit), thereby supporting more complex program structures and behaviors. To achieve this object-oriented feature, each POU (Program Organization Unit) generates specific structures and functions during the compilation process to manage its state and behavior. Specifically, for each POU (Program Organization Unit), we will generate the following:

[0050] Structure Definition: First, to record the internal state of a POU (Program Organization Unit), we generate a structure with the same name as the POU. This structure contains all the internal variables and state information of the POU, allowing each POU instance to independently maintain its own state. This design is similar to class instantiation in object-oriented programming, where each instance has its own properties and methods.

[0051] Reset Function: Next, we generate a function named (pou_name)_reset for each POU (Program Organization Unit). This function resets the state of the POU (Program Organization Unit), restoring all its internal variables to their initial state. This is useful when you need to reinitialize a POU (Program Organization Unit) or reset its state under certain conditions.

[0052] Execution Function: Finally, we generate a function named (pou_name)_exec to execute the POU (Program Organization Unit) logic. This function encapsulates all the POU's operational logic and is responsible for updating the POU's state based on input and generating output. By calling this function, the program can execute the specific functionality of the POU (Program Organization Unit).

[0053] The Clight code generation process specifically includes the generation of expressions and statements. Different types of expressions are converted into Clight expressions through the gen_exp function; different types of statements are converted into Clight statements through the gen_stmt function. The entire process is completed by the gen function, which accepts the POU (Program Organization Unit) list pro as input and finally outputs the Clight global environment ge.

[0054] The process of converting different types of expressions into Clight expressions using the gen_exp function is as follows:

[0055] S321A, variables: For identifier id, gen_exp directly returns id;

[0056] S322A, Temporary variables: For a temporary variable temp(id), gen_exp returns _id, which indicates the naming convention of the temporary variable;

[0057] S323A, unary operation: For unary(e), gen_exp generates operands through gen_exp(e) and re-synthesizes the unary operation;

[0058] S324A, binary operation: For a binary operation (e1, e2), gen_exp recursively generates expressions for e1 and e2 and combines them into a binary operation;

[0059] S325A, Member access: For member access e.id, gen_exp generates an expression for e and appends the member access operation.

[0060] The process of converting different types of statements into Clight statements through the gen_stmt function is as follows:

[0061] S321B, assignment statement: For the assignment statement e1:=e2, gen_stmt first calls gen_exp to generate the expressions of e1 and e2, and then combines them into an assignment statement;

[0062] S322B, function call: For the function call call(e), gen_stmt uses the T_exec function to generate a call statement, where gen_exp(e) is used to generate the parameter expression of the call;

[0063] S323B, reset operation: For the reset operation reset(e), gen_stmt uses the T_reset function to generate a reset statement and generates an expression for the reset target through gen_exp(e);

[0064] S324B, Compound statement: For compound statement s1; s2, gen_stmt recursively generates statements of s1 and s2 and concatenates them sequentially.

[0065] Step 4: Use theorem proving techniques to prove the semantic consistency of the trusted compilation algorithm designed in Step 3. Specifically, describe the correspondence between the ST-light and Clight environments through invariants to ensure the semantic consistency of the trusted compilation algorithm. The invariants are as follows:

[0066]

[0067] The meaning of the above invariants is as follows: define an invariant called match_states, for a given definition list pro and one of the POUs P, match the environments M and E of ST-light with the environments e and le of Clight and the memory addresses (b self ,δ self ) are associated; the invariant consists of three parts: var_repPEle indicates that ST-light's temporary memory E matches Clight's temporary environment le, and every temporary variable in E can find an equal value in le; Indicates that there is a pointer value named self in the Clight temporary environment le, whose value is ptr(b self ,δ self ); Indicates that ST-light's global memory M matches Clight's memory. For each variable x in M ​​and its nested instances, an offset value δ relative to the starting variable will be calculated based on the order of the variables in the definition. i ; Assume that the value of x in M ​​is v, and (b self ,δ self +δ i ) can also be read as v.

[0068] Semantic consistency means that the source code and target code directly have similar observable behavior. A PLC executes in a loop and updates the output state after each iteration. The observable behavior is the tracking of variable outputs. In our design, variable outputs depend on the use of ST-light expressions containing access operations. Therefore, semantic consistency between ST-light and Clight can be considered to mean that after the source code and target code are executed, the value of a Clight expression is the same as the corresponding ST-light expression evaluation. Given that expression evaluation depends on their respective environments, we need to describe the correspondence between the ST-light and Clight environments, specifically their respective memory spaces. To do this, we use invariants. Specifically, this invariant consists of three parts: ensuring that ST-light's temporary memory E matches the Clight temporary environment le; ensuring that the Clight temporary environment le contains a pointer value named self; and ensuring that ST-light's global memory M matches Clight's memory m. We propose and prove that the invariant guarantees that the expression has the same value before and after translation, thereby guaranteeing the semantic consistency proposed above, as shown in the following lemma.

[0069] (Invariants ensure semantic consistency) Given the generated result ge for the declaration list pro, the invariant match_states, and the ST-light language expression evaluation result, if the following conditions are met:

[0070] 1.gen(pro)=ge

[0071] 2.

[0072] 3.

[0073] Then there will be a corresponding Clight expression evaluation:

[0074]

[0075] Therefore, our goal is to prove that the invariant holds both at initialization and after each execution cycle. Taking one execution as an example, we are able to complete the definition of the following theorem.

[0076] (Execution Semantics Consistency) Given the generation result ge for the declaration list pro, the invariant match_states, and the ST-light language execution statement evaluation result, if the following conditions are met:

[0077] 1.gen(pro)=ge

[0078] 2.

[0079] 3.fun-entry ge f exec (P)[(b self ,δ self )]melem

[0080] 4.

[0081] Then there will be m' temporary environments le' in Clight memory that meet the following requirements:

[0082] 1.

[0083] 2.

[0084] All the lemmas and theorems we defined are formalized in Coq. Coq is a powerful interactive theorem prover and programming language used for formal verification and proof of logical propositions. The unique advantage of Coq lies in its rigorous mathematical logic framework and powerful type system, which enables users to perform precise formal reasoning in a computer-assisted manner. It supports a rich strategy language that can help users construct complex proofs in an interactive way while ensuring the correctness and reliability of the proofs. Taking the "invariants ensure semantic consistency" lemma proposed in the previous article as an example, we can briefly introduce the basic method of expressing and proving theorems in Coq. First, we define the theorem in Coq:

[0085] 1Hypothesis

[0086] 2(Findpou:find_pou_declpo_idpro=Somepo)

[0087] 3(Hmem:m|=match_states gcenvpropo(me,ve)(e,le)

[0088] 4sb sofs**P).

[0089] 5Theorem expr_correct:

[0090] 6forallex v,

[0091] 7wt_exppropo ex->

[0092] 8exp_eval me ve ex(Some v)->

[0093] 9eval_expr tge e le m(translate_exppo ex)v.

[0094] Then, we use a series of strategies in Coq to prove the inductive type variable ex. First, we use the induction x; intros; simpl. strategy to inductively prove and simplify the inductive type variable ex. At this point, the proof goal is decomposed into several sub-goals:

[0095] 1(1 / 6)

[0096] 2eval_expr tge e le m

[0097] 3(deref_field self(pou_name po)i(cltype t))v

[0098] 4(2 / 6)

[0099] 5eval_expr tge e le m

[0100] 6(if is_inst t

[0101] 7then deref_field self(pou_name po)i(cltype t)

[0102] 8else Etempvar i(cltype t))V

[0103] 9(3 / 6)

[0104] 10eval_expr tge e le m(translate_const c)(sem_constc)

[0105] 11(4 / 6)

[0106] 12eval_expr tge e le m

[0107] 13(translate_unop u(translate_exp po ex)(cltype t))V

[0108] 14(5 / 6)

[0109] 15eval_expr tge e le m

[0110] 16(translate_binop b(translate_exp po ex1)

[0111] 17(translate_exp po ex2)(cltype t))V

[0112] 18(6 / 6)

[0113] 19eval_expr tge e le m

[0114] 20(Efield(translate_exp po ex)i(cltype t))V

[0115] We will then apply a series of previously proven corollaries. For example, we have previously proved the following corollary:

[0116] 1eval self field

[0117] 2:forall(x:ident)(ty:type),

[0118] 3In(x,ty)(filter_val(pou_vars po))->

[0119] 4forall V:val,

[0120] 5find_val x me=Some V->

[0121] 6eval_expr tge e le m

[0122] 7(deref_field self(pou_name po)x(cltype ty))v

[0123] The first subgoal can be proved directly using apply eval_self_field; auto. Similar methods can be used to prove other subgoals.

[0124] Therefore, the present invention adopts the above-mentioned high-security PLC compilation verification method for nuclear energy automation control systems, ensures the correctness of the PLC compilation process through formal verification technology, effectively improves the security of PLC code in nuclear energy control systems, avoids system failures caused by compilation errors, and thus improves the operational reliability of nuclear energy facilities.

[0125] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention rather than to limit the same. Although the present invention has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that they can still modify or replace the technical solutions of the present invention with equivalents, and these modifications or equivalent replacements cannot cause the modified technical solutions to deviate from the spirit and scope of the technical solutions of the present invention.

Claims

1. A high-security PLC compilation and verification method for nuclear energy automation control systems, characterized in that: The following steps are involved: Step 1: Design a PLC language subset ST-light suitable for nuclear power control systems; Step 2: Build the semantic model of ST-light based on big-step semantics; Step 3: Design a trusted compilation algorithm from ST-light to Clight, including: performing type checks to ensure variable types match; and generating Clight code. Step 4: Use theorem proving techniques to prove the semantic consistency of the trusted compilation algorithm designed in step 3.

2. A high-security PLC compilation and verification method for a nuclear energy automation control system according to claim 1, characterized in that: The PLC language subset ST-light designed in Step 1 for nuclear power control systems was improved at four levels: type level, expression level, statement level, and declaration level. The specific improvements are as follows: At the type level, compared to the IEC 61131-3 standard, an additional type is added, specifically the type pointing to the instance; At the expression level, all expressions are annotated with their static type; At the statement level, remove the parameters from the call statement and change the state of the POU instance through a separate assignment form; and add an additional reset statement to reset the POU state to the initial condition, and a sequence statement for executing operations continuously; At the declaration level, function blocks, functions, and programs are no longer distinguished. Instead, function blocks, functions, and programs are uniformly regarded as POUs. Each POU definition includes the POU identifier, variable definitions, temporary variable definitions, statements in the POU reset area, and statements in the POU execution area.

3. A high-security PLC compilation and verification method for a nuclear energy automation control system according to claim 2, characterized in that: The ST-light semantic model in the ST-light semantic model based on big-step semantics in step 2 includes two evaluation environments, the first part is temporary memory and the second part is global memory; among them, the temporary memory is used to save the state of temporary variables, which is a mapping from variable name to value; the global memory is used to save the state of variables and has nested sub-instances, and the global memory contains two mappings, including variable name mapping to value and instance name mapping to sub-memory.

4. A high-security PLC compilation and verification method for a nuclear energy automation control system according to claim 3, characterized in that: The process of designing the trusted compilation algorithm from ST-light to Clight in step 3 is as follows: S31. Design a type checking algorithm and perform type checking. During the annotation process, annotate the unannotated abstract syntax tree with a type and check whether it is well-typed. If the check result is well-typed, proceed to the next step; otherwise, report a type error. S32. Design a code generation algorithm to convert the ST-light program into target code, and convert the POU into Clight code through compilation while maintaining semantic consistency; converting the POU into Clight code through compilation includes the generation of expressions and statements, among which different types of expressions are converted into Clight expressions through the gen_exp function; different types of statements are converted into Clight statements through the gen_stmt function.

5. A high-security PLC compilation and verification method for a nuclear energy automation control system according to claim 4, characterized in that: The process of converting different types of expressions into Clight expressions using the gen_exp function is as follows: S321A, variables: For identifier id, gen_exp directly returns id; S322A, Temporary variables: For a temporary variable temp(id), gen_exp returns _id, which indicates the naming convention of the temporary variable; S323A, unary operation: For unary(e), gen_exp generates operands through gen_exp(e) and re-synthesizes the unary operation; S324A, binary operation: For a binary operation (e1, e2), gen_exp recursively generates expressions for e1 and e2 and combines them into a binary operation; S325A, Member access: For member access e.id, gen_exp generates an expression for e and appends the member access operation.

6. A high-security PLC compilation and verification method for a nuclear energy automation control system according to claim 5, characterized in that: The process of converting different types of statements into Clight statements through the gen_stmt function is as follows: S321B, assignment statement: For the assignment statement e1:=e2, gen_stmt first calls gen_exp to generate the expressions of e1 and e2, and then combines them into an assignment statement; S322B, function call: For the function call call(e), gen_stmt uses the T_exec function to generate a call statement, where gen_exp(e) is used to generate the parameter expression of the call; S323B, reset operation: For the reset operation reset(e), gen_stmt uses the T_reset function to generate a reset statement and generates an expression for the reset target through gen_exp(e); S324B, Compound statement: For compound statement s1; s2, gen_stmt recursively generates statements of s1 and s2 and concatenates them sequentially.

7. A high-security PLC compilation and verification method for a nuclear energy automation control system according to claim 6, characterized in that: In step 4, the semantic consistency of the trusted compilation algorithm designed in step 3 is proven using theorem proving techniques. The semantic consistency of the trusted compilation algorithm is ensured by describing the correspondence between the ST-light and Clight environments through invariants. The invariants are as follows: The meaning of the above invariants is as follows: define an invariant called match_states, for a given definition list pro and one of the POUs P, match the environments M and E of ST-light with the environments e and le of Clight and the memory addresses (b self ,δ self ) are associated; the invariant consists of three parts: var_repPEle indicates that ST-light's temporary memory E matches Clight's temporary environment le, and every temporary variable in E can find an equal value in le; Indicates that there is a pointer value named self in the Clight temporary environment le, whose value is ptr(b self ,δ self ); Indicates that ST-light's global memory M matches Clight's memory. For each variable x in M ​​and its nested instances, an offset value δ relative to the starting variable will be calculated based on the order of the variables in the definition. i ; Assume that the value of x in M ​​is v, and (b self ,δ self +δ i ) can also be read as v.

Images