Method for analyzing a programmable logic controller program

Abstract

A PLC program analysis method is disclosed, wherein a program (PROG) is converted (TRANS1) into a program model (PMOD) in a logical framework, and a property (Prop) is determined from the program model. The property combined with the interlocking property (IntProp) is verified by an automatic solver (SMT). If the opposition of the property (Prop) is satisfyable, a counterexample (PROOF NOK) representing the input and internal memory values ​​of the model is provided. The counterexample (PROOF NOK) is converted into an incorrect initial configuration (IniConf) of the model. The execution (EXE) of the model is simulated using the incorrect initial configuration (IniConf) of the model, and the incorrect intermediate configuration (AST-IntConf) of the model simulation is recorded until the property is violated. The incorrect initial and intermediate configurations (Lad-IniConf, Lad-IntConf) of the original program (PROG) are derived from the incorrect initial configuration (IniConf) of the model and the incorrect intermediate configuration (AST-IntConf) of the model simulation and are displayed. A device for executing the method is provided.

Description

Technical Field

[0001] The present invention relates to a method and a device for analyzing a program written in a language described in the IEC 61131-3 standard. Such a program is particularly intended for use in a programmable logic controller (PLC) to perform control of an industrial system.

[0002] The present invention more particularly relates to methods and apparatus for analyzing, detecting and correcting errors in such PLC programs. Background Art

[0003] A programmable logic controller (PLC) is an industrial digital computer that is used as an automated controller for manufacturing processes, such as assembly lines or robotic equipment.

[0004] The PLC is equipped with software that calculates outputs based on inputs and internal memory values, thus replacing hard-wired relays, timers and sequencers. Standard IEC 61131-3 describes different programming languages ​​used to program PLCs, such as: Ladder Logic (Ladder), Instruction List (IL), Structured Text (ST), Sequential Function Chart (SFC) and Function Block Diagram (FBD). In particular, the Ladder Diagram language, also known as Ladder Logic, is a programming language used to develop PLC software. This language represents PLC programs through graphical diagrams using circuit diagrams of relay logic hardware.

[0005] A portion of the software development process is devoted to functional specifications. In the present disclosure, functional specifications are also referred to as user specifications. Functional specifications typically consist of a document written in a natural language and specify what the program is to do. The functional specification describes the functions that the program is expected to perform. Software is then developed using programs written according to the functional specifications.

[0006] Another part of the software development process is dedicated to debugging. Debugging involves checking whether the program operates safely according to the given specifications in the functional specification document. Debugging is required before implementation in a production environment, because program bugs (bugs) in a factory can be very costly in terms of human and material losses and plant shutdown time. Program bugs in factory automation systems can also be costly in terms of downtime and sometimes damage to people and hardware.

[0007] There are different types of tests configured for the debugger.

[0008] The first type involves single and integration testing and involves checking the behavior and common interactions of different components. These tests are configured to detect programming errors that specifically lead to runtime errors.

[0009] The second type of testing is related to system testing (also called functional testing) and acceptance testing and consists in detecting errors with respect to the functional specifications of the program. Functional testing evaluates whether the program complies with the requirements specified in the functional specifications in which it was written. Thus, functional testing allows verifying whether the program operates correctly and safely from the end user's perspective and according to business requirements.

[0010] A common way to run tests on a program is the simulation method, which consists of setting up some tests defined by initial configurations and executing the program on said tests to check its behavior under these configurations. This program is usually executed in a software simulation at a factory.

[0011] The main disadvantage of this debugging method is that it is not exhaustive and is time-consuming and therefore costly. This non-exhaustiveness makes it completely impossible to guarantee that the selected tests cover all possible executions of the program in the production environment. Bugs may remain in the program after the testing phase, since the only guarantee is that the program will not produce bugs for the tested configuration.

[0012] Model checking approaches consist in continuously executing the program model to be tested, rather than the program itself, to save time and resources. However, the complexity associated with the execution paths is often exponential, especially for industrial applications. Testing efficiency is limited by CPU time, so this approach is still not exhaustive.

[0013] Furthermore, tests are partially or fully developed and run manually, since at least some configurations need to be manually defined to generate and execute the tests. Although part of the test generation and execution can be automated, another disadvantage of this approach is that the programmer still has to analyze the output values ​​of the tests, and the only available information about the program vulnerability is the initial configuration of the inputs and internal memories that led to the program vulnerability. Therefore, it is often difficult to understand the root cause of the error and why the considered initial configuration led to the error at a certain point in the program.

[0014] Another disadvantage of this approach is that program vulnerabilities may arise from the way tests are developed with respect to the functional specifications.

[0015] First, writing functional specifications in natural language is imprecise and can be ambiguous. Although some standardized methods of expressing specifications in natural language may have emerged, such methods may create ambiguity at implementation time when developers may misunderstand the specification and write irrelevant code and at implementation time when testers may set inadequate tests due to misunderstanding of the specification.

[0016] Secondly, writing a functional specification in natural language is very time-consuming. But most importantly, this document is also intended for test engineers who need to read and interpret it to build appropriate functional and approved tests. All of these stages are very time-consuming and therefore costly.

[0017] Third, this approach is not exhaustive because the ambiguities arising from the use of natural language may include some unspecified parts during the test development process. Failure to provide clear functional specifications increases the exhaustiveness problem encountered during test-based debugging. It is impossible to test all possible executions of the software, and program vulnerabilities may remain in the code even if the tests pass successfully.

[0018] Some methods have been developed to express functional specifications in an unambiguous way so that tests can be developed in the test step without the risk of misunderstanding. Some of these methods are based on formal methods that allow temporal specifications to be expressed in a very precise and unambiguous way. However, these methods are difficult to operate, especially for ordinary engineers, since logical knowledge is usually required to use these methods appropriately. One example consists in providing templates of predefined specifications, such as natural language sentences to be filled in with blanks. However, this approach is only applied to temporal specifications. Temporal specifications can only be verified with non-exhaustive formal methods, such as model checking methods applied to formal models rather than directly to the program.

[0019] One object of the present disclosure is to provide a solution for exhaustively validating a programmable logic controller program, which solution ensures that all possible executions of the program are covered. Summary of the invention

[0020] According to one aspect of the present invention, a programmable logic controller program analysis method is disclosed, and the programmable logic controller program analysis method comprises the following steps:

[0021] -Convert the original program of PLC program type into a program model in a logic framework;

[0022] - based at least on said program model, converting the user specification into a specification model in a logical framework;

[0023] - determining a set of properties related to internal variables of the original program from at least the program model and a predefined language formalization;

[0024] - verifying, by an automatic solver, the satisfiability of the set of properties combined with the interlocking properties obtained from the specification model and providing, if the opposition of properties to the set of properties is satisfiable, a set of counterexamples representing inputs to the program model and internal memory values ​​that satisfy the opposition of properties, or providing confirmation thereof if the set of properties is always satisfied;

[0025] - converting the counterexample into an erroneous initial configuration of the program model, the initial configuration including initial values ​​of inputs and internal memory;

[0026] - simulating the execution of the program model with an erroneous initial configuration of the program model, and recording an erroneous intermediate configuration of the program model simulation from the start of the execution to the property violation, the intermediate configuration including intermediate values ​​of the internal memory;

[0027] - Converting the erroneous initial configuration of the program model and the erroneous intermediate configuration of the program model simulation into the erroneous initial configuration and the erroneous intermediate configuration of the original program; and displaying the erroneous initial configuration and the erroneous intermediate configuration of the program.

[0028] Under these arrangements, a program vulnerability occurs when one or more properties associated with the program are violated. The properties are related to the values ​​of the program's inputs, outputs, and local memories. The present invention allows such violations to be detected before the program is executed in a simulated or real environment. The method includes finding the initial values ​​of the inputs and local memories that cause errors during the execution of the program. Debugging is automated and accelerated. The method is exhaustive because it guarantees that if no error scenarios are found using the described method, no execution configuration violates the program property. In fact, in the prior art, even if no property violation is detected during the execution of the test, there is no guarantee that the property will hold in all possible executions.

[0029] More specifically, the present invention provides a solution to explicitly express the functional specification of a PLC program and to fully automate and accelerate the verification of such functional specification.

[0030] Since the specification model is expressed in a logical framework, the verification of the satisfiability of the set of properties in combination with the specification model guarantees that if no specification violation is found, then no execution of the program violates the specification at production time.

[0031] The specification model is then automatically verified in a satisfiability verification step. Deductive verification is used in this verification step to ensure that if no property violation is found, no execution of the program will violate the functional specification. This approach is exhaustive, in contrast to the usual test-based methods for verifying the functional specifications of PLC programs, which are not able to test all possible executions of a program written according to the functional specification. Thus, with the PLC program analysis method of the present invention, PLC program specifications can be specified and verified explicitly, completely and automatically.

[0032] The method covers all possible executions of the validated PLC program and its functional specifications. Therefore, thanks to the obtained initial and intermediate configurations, useful information about error scenarios can be provided in the final step of the method together with the program code to indicate where, how and why such errors occurred during program execution. Property violations are accurately accounted for. The initial configuration that led to the property violation is calculated and execution information from the initial configuration to the program point where the property was violated, such as memory allocation, is recorded and retrieved.

[0033] The present invention provides a solution for verifying functional specifications in addition to ensuring the execution safety and rationality of PLC programs. The method detects runtime errors or functional specification violations expressed by the programmer in first-order logic as interlocking properties. When runtime errors or specification violations are found, the present invention provides useful debugging information. Depending on the programming language of the PLC program, the present invention provides all execution information about the initial configuration and intermediate configurations that led to the runtime errors or specification violations.

[0034] If a specification violation is detected, all the information the programmer needs to understand when and why the specification was violated is displayed. This information typically includes the initial and intermediate values ​​of the memory that caused the specification violation.

[0035] The program can print additional information related to memory values ​​during execution (such as initial and intermediate values ​​that caused property violations) and how to fix program vulnerabilities. Therefore, the method allows automatic debugging because no human intervention is required to determine the tests to run, supervise their execution, and analyze their results.

[0036] The method also allows faster debugging, since it relies on property verification rather than continuous execution of the program under multiple test configurations for simulation, as the case of automatic simulation is limited to complex programs of industrial scale. The execution time on the central processing unit is thus reduced. With the PLC program analysis method of the present invention, a typical industrial-scale PLC program can be verified in a few seconds.

[0037] Due to these configurations, an efficient, exhaustive and fast tool is provided which can safely reduce the deployment time of PLC programs and increase the confidence in PLC programs in the factory automation industry.

[0038] Program models are best represented using a first-order logic framework that can be mathematically proven and can therefore be used to represent computational problems. Furthermore, first-order logic is suitable for expressing properties derived from PLC program models and corresponding functional specifications, and the generation of first-order logic properties is easier to automate than with higher-level logic frameworks.

[0039] According to one embodiment, the step of converting the user specification into a specification model comprises an intermediate step in which the user specification is expressed using functional specification templates and a selection of devices used by the PLC program.

[0040] The user specification describes the functions that the PLC program is expected to perform and is usually written before the PLC program is developed according to the user specification. The PLC program functions are usually specified in a natural language, which results in the user specification being expressed in an informal language. This intermediate step of the user specification conversion step allows the user specification to be expressed in a formal language.

[0041] In this way, a specification model is generated in a logical framework from a user specification expressed using a functional specification template and a selection of devices used by the PLC program. The selection of devices used by the PLC program can be provided from the program model. Therefore, the generated specification model is related to the program model. According to one embodiment, the step of converting the original program into the program model includes a first intermediate step of expressing the original program as an abstract syntax tree, and a second intermediate step of generating the program model from the abstract syntax tree.

[0042] The implementation of such an intermediate step is advantageous because the abstract syntax tree can be enhanced with information such as attributes and comments for each element it contains. The abstract syntax tree is preferably described in a functional language such as OCAML. The abstract syntax tree also allows the location of each element in the PLC program to be stored, which is useful for retrieving erroneous intermediate configurations during the simulation execution of the program model.

[0043] To this end, the steps performed by the simulation program model preferably include:

[0044] - a first intermediate step, converting the program model's incorrect initial configuration into an incorrect initial configuration corresponding to an abstract syntax tree;

[0045] - A second intermediate step of computing an abstract syntax tree having said corresponding initial configuration and retrieving an intermediate value of the internal memory corresponding to the abstract syntax tree.

[0046] The abstract syntax tree representation is advantageous because it allows the generation of intermediate values ​​that cannot be obtained by simply executing the PLC program, such as the values ​​at the logic gates connecting the instructions.

[0047] According to one embodiment, the step of converting the original program to a program model includes an intermediate step of a static single assignment transformation. The static single assignment transformation is preferably applied to an abstract syntax tree representation and facilitates tracking of internal memory values ​​during execution.

[0048] According to one embodiment, during the step of determining the set of attributes, the set of attributes is calculated using the Dijkstra weakest prior condition calculus to determine a priori conditions on the set of attributes, based on which the validation of the set of attributes is performed. A priori conditions are basic assumptions inherent in the attributes. Satisfied a priori conditions mean that the attribute is validated and no errors occurred during its execution.

[0049] According to one embodiment, the satisfiability of the set of predicates in combination with interlocking properties is verified using a satisfiability modulo solver, which is an automatic solver configured to solve satisfiability modulo theory problems, which are decision problems expressed as logical formulas in first-order logic.

[0050] According to another aspect of the present invention, a computer program comprising instructions is disclosed. When the instructions are executed by at least one processor, the instructions are used to perform the method as described above.

[0051] In a preferred embodiment, the computer program is executed on a deductive program verification platform.

[0052] The invention also aims at providing a non-transitory computer-readable medium storing a computer program according to the invention and causing a computer to execute the steps of the method as defined above.

[0053] According to another aspect of the present invention, a device for executing the programmable logic controller program analysis method as described above is disclosed. In one embodiment, such a device may include a processing circuit PC (such as Figure 7 ), the processing circuit PC comprises:

[0054] a memory MEM storing the above-mentioned computer program instructions and possibly other data, such as temporary calculation data,

[0055] a processor PROC adapted to read the content of the memory MEM and to execute the steps of the method according to the invention, and

[0056] - Possibly, an input / output interface INT for receiving / sending data (through a network or any other link) to be processed by / with the processor PROC. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] Other features and advantages of the invention are given by way of non-limiting example and with reference to the above discussion. Figure 7 This will become apparent from the following detailed description of one of its embodiments given by further drawings, in which:

[0058] [ Figure 1 ]

[0059] Figure 1 An exemplary set of steps involved in the disclosed method is shown.

[0060] [ Figure 2 ]

[0061] Figure 2 A portion of a graphical interface representing steps for implementing the disclosed method.

[0062] [ Figure 3 ]

[0063] Figure 3 An example of a ladder diagram is shown in a specific implementation of the disclosed method.

[0064] [ Figure 4a ]

[0065] Figure 4a The results of executing the intermediate steps involved in the disclosed method are shown.

[0066] [ Figure 4b ]

[0067] Figure 4b The results of executing the intermediate steps involved in the disclosed method are shown.

[0068] [ Figure 5 ]

[0069] Figure 5 Another execution result of the intermediate steps involved in the disclosed method is shown.

[0070] [ Figure 6 ]

[0071] Figure 6 Error scenarios are shown as a result of execution of the disclosed method.

[0072] [ Figure 7 ]

[0073] Figure 7 An apparatus for performing the disclosed method is shown. DETAILED DESCRIPTION

[0074] In the drawings, the same reference numerals denote the same or similar elements.

[0075] Figure 1 There is shown an exemplary set of steps, denoted by reference numeral 10, and involved in deductive validation of a PLC program. This set of steps represents the global architecture of the implementation of the method of analyzing and validating a PLC program.

[0076] exist Figure 1In the example shown, the method includes seven steps. The first six steps can be applied to PLC programs written in any PLC programming language. The seventh step is implemented according to the programming language used to write the PLC program. Figure 1 The following steps represent the method according to the invention:

[0077] In a first step (TRANS1) of the method, the PLC program (PROG) is converted into a program model (PMOD);

[0078] In a second step (TRANS2), the functional specification is converted into a specification model (SMOD). The specification model (SMOD) is represented in the logical framework of the program model (PMOD) and is generated using a specification template and a selection of devices used by the PLC program. The functional specification is advantageously expressed on a graphical interface that displays a functional specification template for formally expressing said functional specification. More precisely, the functional specification template is displayed on the graphical interface together with the selection of devices used by the PLC program;

[0079] • In the third step (PredT), the properties to be verified are generated from the program model (PMOD), the specification model (SMOD) and the predefined PLC language formalism.

[0080] In the fourth step of the method (SMT), the properties generated in the third step are formally proved or counterexamples are found using an automated solver;

[0081] In the fifth step (TRANSB), the property counterexamples (PROOF NOK) - if any - are converted into the model configuration, in particular into the initial model configuration;

[0082] In a sixth step (EXE), the execution of the PLC program is simulated in order to calculate all the intermediate values ​​of the internal memory according to the initial configuration of the model obtained in the fifth step. This step is optional if all the intermediate values ​​are provided in the attribute counterexample returned in the fourth step;

[0083] In the seventh step (DISP), the model intermediate values ​​are converted back to a PLC program with intermediate value information. When the PLC language used is ladder logic, the results are printed to the user in a graphical form, similar to the original ladder program.

[0084] The first step (TRANS1) of the method is a conversion step consisting in converting the PLC program (PROG) into a program model (PMOD).

[0085] The PLC program PROG can be executed on a programmable logic controller, hereinafter referred to as a PLC. The PLC is capable of storing and executing instructions such as sequencing, timing, counting, arithmetic, data manipulation and communication to control industrial machines and processes. Interface circuits with field devices are provided in the form of input and output connections.

[0086] In one embodiment, the PLC program is written in ladder logic, and the ladder diagram represents the sequential control logic of the PLC program in the form of a graphical diagram. Ladder diagram language is a graphical language that simulates relay logic circuit diagrams, such as Figure 3 As shown, it represents an example of a ladder diagram. Ladder logic is actually a rule-based language. Rules (also called "rungs") are instantiated when activated by conditions in a set of data. A set of statements belonging to those rules are selected and executed based on the activation. When implemented using electromechanical devices such as relays, the various rules that make up the program are executed sequentially in a continuous loop as part of the software. Executing multiple loops per second can achieve the effect of simultaneous and immediate execution. The rungs are executed in a given order to achieve the correct operation of the programmable controller. More specifically, a ladder program can include a loop that is executed continuously, for example every 100 milliseconds.

[0087] The rung inputs are logic checkers, also called "contacts". The so-called "contacts" can refer to physical or hard inputs from physical devices (such as push buttons and limit switches) to the programmable controller through integrated or external input modules. Contacts can also represent the state of internal storage bits that may be generated elsewhere in the program.

[0088] Ladder outputs are actuators represented by "coils". A "coil" can represent a physical output that operates some device connected to the programmable controller, or it can represent an internal memory bit used elsewhere in the program. Each contact or coil corresponds to the state of a single bit in the programmable controller's memory. These instructions provide the ability to check the ON / OFF state of a specific bit address in memory and control the state of internal and external outputs. Unlike electromechanical relays, a ladder program can reference the state of a single bit multiple times, equivalent to a relay with an unlimited number of contacts.

[0089] In a ladder diagram, rungs are constructed as a network of connected instructions. The connection between instructions represents the logical relationship between the instructions. For example, in ladder logic, OR logic is implemented by the parallel connection of two contacts, while AND logic is implemented by ladder logic as a series connection of contacts.

[0090] The conversion performed in the first step (TRANS1) is performed by implementing a conversion algorithm. The conversion algorithm uses a predefined modeling of PLC language primitives to convert a PLC program (PROG) into a program model (PMOD) represented by a logic framework. PLC language primitives consist of logical instruction elements that make up the PLC logic circuit, such as logic checkers represented by contacts, actuators represented by coils, function blocks, and more generally any basic or enhanced ladder language instructions.

[0091] The program model (PMOD) is best represented using the logical framework of first-order logic. First-order logic is an extension of propositional logic and considers whether a proposition is true or false in a local view of the world (called a domain). First-order logic consists of an alphabet, a first-order language, a set of axioms, and a set of inference rules. Since first-order logic can be proven mathematically, it is useful in representing computational problems. First-order logic consists of syntax and semantics. The syntax of first-order logic is a formal language used to express concepts, and the semantics of first-order logic formulas determines the value of any first-order logic formula.

[0092] Given the sequential structure of the PLC program, the conversion operates only on the instructions contained in the loop itself. Therefore, there is no need to express the program model in temporal logic, since the program does not involve the continuous execution of loops. During the first step of the conversion, algebraic data types are used to model the inputs, internal memory, and outputs of the program, while polymorphic types are used to decompose the number of model primitives.

[0093] The modeling of instructions consists in expressing them as first-order formulas to represent predicates. Predicates are basically binary-valued functions of binary and non-binary variables. Authorized values ​​of inputs and local memory at execution time can be obtained from these predicates. Instruction modeling can be associated with properties expressed as first-order formulas that represent authorized values ​​of inputs and local memory at execution time, i.e., values ​​that the instruction will not cause an error when executed. These formulas may be associated with additional information, such as the instructions they refer to and the cause of the error.

[0094] The PLC program model (PMOD) is generated using a mathematical statement including the predicate. In other words, the target of the PLC program is expressed with a set of predicates in a selected mathematical logic. The verification of this mathematical statement ensures that the calculation method of the program is correct. The verification of this mathematical statement clearly explains the reason why the calculation method performs the expected calculation. This verification is also referred to as proof, and ensures the security of execution and the rationality of the program related to the mathematical statement. If it is proved that during program execution, no runtime error (such as, illegal access to memory or overflow, illegal operations such as attempt to divide by 0 or in the case of other types of programs involving continuous execution loops, termination problems like infinite loops) is encountered, then the security of execution can be ensured. Program rationality is also referred to as functional correctness, and includes verifying whether the program has completed what it should do.

[0095] In formal logic, a logical system is sound if and only if every formula that can be proved in the system is logically valid with respect to the semantics of the system. In other words, a system is sound when all theorems of the system are tautologies. The soundness of a deductive system is the property that any sentence provable in that deductive system is also correct with respect to all interpretations or constructions of the semantic theory of the language on which the theory is based.

[0096] In a preferred embodiment, the first step (TRANS1) comprises a first intermediate step (AST-TRANS), wherein the PLC program is first represented as an abstract syntax tree, also called AST representation or syntax tree, and hereinafter referred to by the acronym AST. Then, in a second intermediate step (MOD-TRANS), a PLC model is generated from the AST representation of the PLC program.

[0097] An abstract syntax tree is a tree representation of the abstract syntax structure of a source code written in a programming language. Each node of the tree represents a construct that appears in the source code, which in this embodiment is a PLC program.

[0098] The AST can be edited and enhanced using information such as properties and comments for each element it contains. With the source code of the PLC program, such editing and commenting is not possible because it means changing it.

[0099] Compared to a PLC program, its AST does not contain every detail that occurs in the real syntax, but only structural and content-related details like braces, semicolons or parentheses, etc. A syntactic structure like an if-condition-then expression can be represented by a single node with three branches.

[0100] The AST often contains additional information about the program due to the successive analysis phases of the compiler. Representing a PLC program with an AST is advantageous because it allows storing the position of each element in the PLC program, which is useful in the subsequent steps of the method. This intermediate step is also interesting because a complete traversal of the AST often allows verifying the correctness of the program.

[0101] In this embodiment, the AST representation is preferably described in a functional language such as OCAML.

[0102] In a preferred embodiment, the conversion algorithm includes a third intermediate step, in which a static single assignment transformation (SSAT) is used to track internal memory values ​​during program execution. In imperative programming languages ​​such as PLC languages, assignments allow variables to maintain different values ​​at different times in their lifetime and scope. The static single assignment transformation is conducive to tracking the values ​​assigned at each execution stage. In order to perform deductive verification on programs written in imperative languages, a transformation to a function model can be implemented, and if so, it can be performed on the model, especially on the AST representation, thanks to the static single assignment transformation. The static single assignment transformation can be seen as a linking step, which allows information to be added to model elements (such as code locations) in order to link them to PLC program elements. Therefore, tracing back to the original PLC program (PROG) can be easily performed. Figure 4b An example of such a static single assignment transformation is provided in which the values ​​of integer D1 at different steps of the model execution are stored as the values ​​of (d1_1, d1_2, d1_3). The equivalent of this transformation is in Figure 4a is represented in the ladder diagram.

[0103] Figure 2 An excerpt of an exemplary graphical interface for performing the second step is shown.

[0104] The second step (TRANS2) of converting the user specification into a specification model is advantageously implemented via a graphical user interface for fully and automatically expressing and specifying the functional specification of the PLC program. Due to the use of deductive verification tools, the second step allows expressing and specifying the functional specification of the PLC program in an exhaustive manner.

[0105] In a particular embodiment, the second step (TRANS2) of converting the user specification into a specification model is performed when the user expresses the functional specification. In an advantageous embodiment, the user expresses the functional specification via a graphical interface. When the functional specification is entered via the graphical interface, a functional specification template based on the program model can be suggested to the user. The expression of the functional specification becomes easy and unambiguous. The functional specification template is advantageously suggested to the user together with a list of devices used by the PLC program and can thus be used to express the functional specification. Figure 2, section A represents a list of devices that the user can select by clicking.

[0106] Compared to the classical techniques of functional specification expression and verification, this step allows to precisely state the functional specification in the form of logical properties, thanks to the use of a template proposed to the user. As a result, a specification model (SMOD) is generated based on the logical properties corresponding to the functional specification and is represented in a logical framework.

[0107] Give users real-time feedback when converting functional specifications into specification models. Figure 2 The natural language shown in Part B and Figure 2 The ladder diagram language shown in Part C of the PLC program is used. This allows the user to express the functional specifications unambiguously. Regardless of the programming language used in the original PLC program, the user can be given feedback on the expressed functional specifications through graphical means such as ladder diagrams.

[0108] The third step (PredT) of the method comprises generating properties (Prop) from the PLC program model (PMOD). The third step combines the program model (PMOD) with a predefined language formalization (LForm) to obtain properties (Prop) related to the program model (PMOD). Then, conditions (Cond) on the properties are obtained.

[0109] These properties represent operations that are performed when the program model is executed, and are expected to be verified at each stage of execution. They are similar to verifying loop invariants at each recursive call. The conditions for the properties can be divided into two categories: preconditions and postconditions.

[0110] A precondition (PreCond) represents a potential assumption inherent in a property (Prop) and should be verified before its execution; otherwise errors may occur. More specifically, when a routine is called, the precondition corresponding to the routine property is assumed to be satisfied, thereby verifying the routine property.

[0111] For example, the factorial function program consists of a loop that represents a recursive calculation performed on a variable. One a priori condition of such a loop is that the variable for calculating the factorial must be a positive integer at the beginning of the loop.

[0112] A postcondition represents the result that is expected when the routine is called with the prior condition verified. Thus, the prior condition of a routine property can be inferred from the result that is expected when the property is evaluated at the end of the routine. In the case of loops, the prior and postconditions are closely related or even similar and form loop invariants, especially in programs involving continuously executed loops. If the postcondition is satisfied in an execution phase of the loop, the prior condition of the next phase is guaranteed to be satisfied as well.

[0113] To this end, the third step (PredT) uses the Dijkstra's weakest prior condition algorithm to calculate the properties and determine the prior conditions (PreCond) associated with the model properties (Prop). Figure 5 Examples of properties generated and calculated in the third step to obtain prior conditions are shown. Figure 5 The property of can be interpreted as: "If the value stored in X is "ON" / "True", then the value stored in D1 is greater than 0 and less than 9999". Another example of a property that can be generated and calculated in the third step is represented as follows:

[0114] ||X||->(Y1 and(not Y2))or((not Y1)and Y2)

[0115] This property means "if the value stored in X is "ON" / "True", then one and only one of the outputs Y1 and Y2 has the stored value "ON" / "True"".

[0116] Performing Dijkstra's weakest prior condition calculus on first-order logic properties ensures that such calculations are reasonable while minimizing the size of the calculated properties. The prior conditions provide the domain of each property. This step ensures the rationality of the proof, because satisfied prior conditions mean that the routine properties hold and no errors occurred during its execution. Therefore, if the property is satisfied, or in other words, the opposite of the property is not satisfied, no errors will occur when executing the corresponding PLC program.

[0117] In an advantageous embodiment, other properties are represented by user specifications (FUNC). User specifications are also called functional specifications and describe the expected behavior of the program, i.e., the functions that the program must perform to satisfy the needs of the program user, as well as the requested properties of the inputs and outputs. For example, in an industrial environment, a robot arm operation can be requested only when a sensor receives a signal within a given range. Other examples of user specifications include the following types of conditions: "two or more specific outputs should not be activated at a time"; "if one or more specific inputs are activated, then one or more specific outputs should / should not be activated"; "only one of the specific outputs can be activated at a time".

[0118] The written program should comply with the above specifications; however, the computed properties derived from the user specification are an additional safety measure, as the written program may contain runtime errors. These properties are interlocking properties (IntProp) and are obtained by expressing the functional specification in first-order logic. More specifically, the interlocking properties (IntProp) are obtained from the specification model (SMOD) obtained in the second step (TRANS2). The interlocking properties are computed together with the properties of the model as additional a posteriori conditions to be satisfied. Therefore, using the Dijkstra weakest a priori condition calculus, the prior conditions (PreCond) can also be derived from these interlocking properties.

[0119] A high-level logic framework can also be used for the first, second, and third steps; however, first-order logic is usually sufficient to express the properties derived from the PLC model (Prop) and the corresponding functional specifications (IntProp). A high-level logic framework may introduce unnecessary complexity in the final application. In addition, the generation of first-order logic properties is easier to automate than a high-level logic framework.

[0120] The computation of properties derived from the functional specifications ensures that when the properties of the model are satisfied, no errors due to violations of the functional specifications will occur at execution time.

[0121] The third step is also referred to as predicate transformation, and is preferably calculated on a deductive program verification platform (PLAT), which includes appropriate tools for receiving program models as input and generating formal proofs of various programs. The first step is also preferably calculated on a deductive program verification platform (PLAT). More specifically, the static single assignment transformation of the first step can be performed by a deductive program verification platform (PLAT). Instruction modeling can be performed by an external modeling tool, which can include a library downloaded in the deductive program verification platform and includes predefined templates and models of PLC language. In an advantageous embodiment, the platform (PLAT) is of WHY3 type, and the program model (PMOD) is expressed in a programming language of WHYML type.

[0122] The fourth step (SMT) of the method uses an automatic solver in order to formally prove the properties generated in the third step, or to find counterexamples to these properties. The generated properties are formally proved if they are always satisfied, or if their opposition is not satisfyable. The satisfiability of the property (Prop) or its opposition is evaluated based on its previously defined prior conditions (PreCond).

[0123] In a preferred embodiment, the fourth step is performed by an automatic theorem prover for Satisfiability Modulo Theory (SMT) problems, which can be used to prove the validity or doubly satisfiability of first-order formulas in a large number of built-in logic theories and combinations thereof. Such a solver is configured to solve Satisfiability Modulo Theory problems, which are decision problems expressed in first-order logic as logic formulas. SMT problems are SAT problems in which propositional variables are replaced by formulas from another mathematical theory. More specifically, SMT problems are expressed as a set of SMT instances, which are formulas in first-order logic with additional interpretations.

[0124] The deductive program verification platform previously used in the third step generally also includes an automatic solver. Therefore, it can also be used to calculate the fourth step. An example of a solver that can be preferably used is CVC4. Another example can be Z3 and Alt-Ergo. The solver must be configured to interact appropriately with the platform to run proofs and provide counterexamples. The interaction includes indicating model elements that require proofs or counterexamples. In a preferred embodiment where the platform (PLAT) is WHY3, model elements that require proofs or counterexamples can be marked by specific functions of the WHYML language, such as Figure 4b shown with the label “model-tracking”.

[0125] Solving is performed heuristically with respect to background theory and includes determining whether an SMT instance is satisfiable. The automatic theorem prover advantageously includes a model generation capability, which is a key feature for providing counterexamples. The properties obtained from the third step are addressed in at least the theory of integer linear arithmetic, and preferably the theory of records, linear real arithmetic, and strings. In an advantageous embodiment, the automatic theorem prover is based on first-order logic with polymorphic types, and preferably includes built-in basic theory, such as equality of rational numbers and integer linear arithmetic, arrays, tuples, records, inductive data types, bit vectors, strings, and uninterpreted function symbols. In a more preferred embodiment, such an automatic theorem prover also includes support for quantifiers.

[0126] If the properties (Prop, IntProp) obtained in the third step are satisfied when calculated using the SMT solver, a response (PROOF OK) representing the proof that the properties are satisfied is generated by the SMT solver. It is then ensured that no instruction of the program (PROG) will fail at production time, and / or that the functional specification (FUNC) expressed by the user holds for all possible executions of the PLC program (PROG). The rationality of the program (PROG) is thus proven.

[0127] Otherwise, if the pair of properties (Prop, IntProp) is satisfiable, the solver provides a counterexample to the property. The response (PROOF NOK) representing the counterexample is generated by the SMT solver and corresponds to the model configuration that leads to the situation where the property is not satisfied. In particular, the content of the counterexample concerns at least the initial configuration, since the formal proof is based on the evaluation of prior conditions (PreCond).

[0128] The fifth step of the method converts (TRANSB) the obtained property counterexample (PROOF NOK) into a model configuration, and more specifically, into an initial model configuration. The model configuration includes the input and internal memory values ​​of the model. The conversion is performed based on the predefined language formalization (LForm) and operates as the inverse of the property generation process in the third step of the program model (PMOD).

[0129] The obtained property counterexamples include data corresponding to the initial (IniConf) and intermediate (IntConf) model configurations, since the program model and the deductive verification process are functional. The initial model configuration (IniConf) includes the inputs of the model and the initial values ​​of the internal memory at the beginning of the execution of the program model (PMOD), which leads to the situation where the property is not satisfied. The intermediate model configuration includes the intermediate values ​​of the internal memory between the beginning of the execution of the program model (PMOD) and the model position where the property is not satisfied.

[0130] However, the counterexample does not include all the intermediate values ​​generated during the execution. For example, four values ​​may be assigned to a PLC program variable X during its execution. Therefore, these four values ​​are assigned to four intermediate variables (X1, X2, X3, X4) representing the variable X. The obtained counterexample may not return values ​​corresponding to all the intermediate variables (X1, X2, X3, X4) in some cases.

[0131] As described in detail below, a preferred method to overcome this situation is to select an initial configuration from the counterexamples obtained and recalculate the values ​​of the intermediate variables (X1, X2, X3, X4) by executing the program model (IniConf) with said initial configuration selected from the counterexamples.

[0132] The sixth step consists in simulating the execution of the PLC program (EXE) in order to calculate intermediate values ​​of the internal memory from the initial configuration of the model obtained in the fifth step.

[0133] In a preferred embodiment, the sixth step comprises a first intermediate step (AST-TRANSB), which comprises converting the model initial configuration (IniConf) obtained in the fifth step into a corresponding initial configuration (AST-IniConf) represented by an AST, preferably expressed in the OCAML language. This conversion can be obtained from the conversion of the AST representation to the model, as operated in the first step.

[0134] The sixth step includes a second intermediate step (AST-SyEx), which includes calculating the AST representation with the corresponding initial configuration (AST-IniConf) by the simulation execution engine to retrieve and record intermediate values ​​(AST-IntConf) of the internal memory of the AST representation. The AST representation execution operation is a simulation of the execution of the PLC program. The collection of intermediate values ​​is performed to the execution point where an error or violation of the specification occurs. The sixth step can also be performed on the deductive program verification platform.

[0135] The AST representation is advantageous because it allows the generation of intermediate values ​​that cannot be obtained by executing the PLC program. One of the reasons is that in the program model, the logic gates connecting the instructions are not represented as variables. Therefore, errors occurring at these code locations are not explicitly stated in the returned counterexamples. The values ​​of these code locations are lost when converted in the first step and are not retrieved in the counterexample values ​​provided in the fourth step. However, the values ​​at these code locations are crucial for properly interpreting the causes of the errors. The sixth step also allows the retrieval of the values ​​at these code locations, thanks to the execution of the AST representation to which a single static allocation has been applied.

[0136] This sixth step provides model error scenarios, through which values ​​that lead to errors or specification violations are collected. Model error scenarios are based on AST representation configurations (AST-IniConf, AST-IntConf).

[0137] The seventh step (DISP) converts the model error scenarios back to the PLC program. The AST representation configurations (AST-IniConf, AST-IntConf) are converted back to the corresponding configurations of the PLC program. The seventh step of the PLC program analysis method is language-centric and is implemented according to the programming language in which the PLC program is written. Due to the additional information contained in the AST about the original program (generated in the first step (TRANS1) and saved in the different processes and transformations of the subsequent steps), the method is able to return the error scenarios to the programmer. This information is conveniently represented in the form of the program itself, with instructions that make the programmer understand why and when functional specification violations or runtime errors occur and how to repair the PLC program. In the specific case of ladder diagram programming, this representation of error scenarios can be displayed graphically.

[0138] Figure 6 The error scenario is shown with a color of binary value and a label of integer value of the error scenario. If the PLC program is written in ladder diagram programming language, the ladder diagram program is displayed in a graphical way, such as Figure 6 The error scenario, together with the error location and cause information added to the program model in the first step, provides very complete information about the error that was found and how to fix it.

[0139] Figure 7 An apparatus for executing the programmable logic controller program analysis method as described above is shown. In the embodiment shown, such an apparatus comprises a processing circuit PC, which comprises:

[0140] a memory MEM storing a computer program comprising instructions for executing the method according to the invention and possibly also other data, such as temporary calculation data,

[0141] a processor PROC adapted to read the content of the memory MEM and to execute the steps of the method according to the invention, and

[0142] - Possibly an input / output interface INT for receiving / sending (through a network or any other link) data to be processed by / with the processor PROC.

Claims

1. A programmable logic controller program analysis method, the programmable logic controller program analysis method The following steps are involved: -Converting an original program of the type of a programmable logic controller program into a program model in a logical framework; - based at least on said program model, converting the user specification into a specification model in a logical framework; - determining a set of properties related to internal variables of the original program from at least the program model and the predefined language formalization; - verifying, by an automatic solver, the satisfiability of the set of properties associated with the interlocking properties obtained from the specification model and, if an alignment of the properties in the set of properties is satisfiable, providing a set of counterexamples representing inputs and internal memory values ​​of the program model that the alignment of the properties is satisfiable, or providing confirmation of the set of properties if the set of properties is always satisfied; - converting the counterexample into an erroneous initial configuration of the program model, the initial configuration including initial values ​​of inputs and internal memory; - simulating the execution of the program model using an erroneous initial configuration of the program model, and recording an erroneous intermediate configuration of the program model simulation from the start of execution to a property violation, the intermediate configuration including intermediate values ​​of an internal memory; - Converting the erroneous initial configuration of the program model and the erroneous intermediate configuration of the program model simulation into the erroneous initial configuration and the erroneous intermediate configuration of the original program; and displaying the erroneous initial configuration and the erroneous intermediate configuration of the program.

2. The programmable logic controller program analysis method according to claim 1, in, The step of converting the user specification into a specification model comprises an intermediate step in which the user specification is expressed using a functional specification template and a selection of devices used by the programmable logic controller program.

3. The programmable logic controller program analysis method according to claim 1, in, The step of converting the original program into the program model includes: a first intermediate step of expressing the original program as an abstract syntax tree; and a second intermediate step of generating the program model from the abstract syntax tree.

4. The programmable logic controller program analysis method according to claim 2, in, The step of converting the original program into the program model includes: a first intermediate step of expressing the original program as an abstract syntax tree; and a second intermediate step of generating the program model from the abstract syntax tree.

5. The programmable logic controller program analysis method according to claim 3, in, The steps performed by the simulation model include: - a first intermediate step, converting the model's incorrect initial configuration into an incorrect initial configuration corresponding to the abstract syntax tree; - A second intermediate step of computing the abstract syntax tree using a corresponding initial configuration and retrieving an intermediate value of an internal memory corresponding to the abstract syntax tree.

6. The programmable logic controller program analysis method according to claim 4, in, The steps performed by the simulation model include: - a first intermediate step, converting the model's incorrect initial configuration into an incorrect initial configuration corresponding to the abstract syntax tree; - A second intermediate step of computing the abstract syntax tree using a corresponding initial configuration and retrieving an intermediate value of an internal memory corresponding to the abstract syntax tree.

7. The programmable logic controller program analysis method according to claim 1, in, The process model is expressed in a first-order logic framework.

8. The programmable logic controller program analysis method according to claim 2, in, The process model is expressed in a first-order logic framework.

9. The programmable logic controller program analysis method according to claim 3, in, The process model is expressed in a first-order logic framework.

10. The programmable logic controller program analysis method according to claim 4, in, The process model is expressed in a first-order logic framework.

11. The programmable logic controller program analysis method according to claim 5, in, The process model is expressed in a first-order logic framework.

12. The programmable logic controller program analysis method according to claim 6, in, The process model is expressed in a first-order logic framework.

13. The programmable logic controller program analysis method according to any one of claims 1 to 12, in, The step of converting the original program into the program model includes an intermediate step of static single assignment transformation.

14. The programmable logic controller program analysis method according to any one of claims 1 to 12, in, In the step of determining the set of attributes, the set of attributes is calculated using Dijkstra's weakest priori condition algorithm to determine prior conditions for the set of attributes, and verification of the set of attributes is performed based on the prior conditions for the set of attributes.

15. The programmable logic controller program analysis method according to claim 13, in, In the step of determining the set of attributes, the set of attributes is calculated using Dijkstra's weakest priori condition algorithm to determine prior conditions for the set of attributes, and verification of the set of attributes is performed based on the prior conditions for the set of attributes.

16. The programmable logic controller program analysis method according to any one of claims 1 to 12, in, The satisfiability of the set of properties associated with the interlocking properties is verified using a satisfiability modulo solver.

17. The programmable logic controller program analysis method according to claim 13, in, The satisfiability of the set of properties associated with the interlocking properties is verified using a satisfiability modulo solver.

18. The programmable logic controller program analysis method according to claim 14, in, The satisfiability of the set of properties associated with the interlocking properties is verified using a satisfiability modulo solver.

19. The programmable logic controller program analysis method according to claim 15, in, The satisfiability of the set of properties associated with the interlocking properties is verified using a satisfiability modulo solver.

20. A computer program comprising instructions for performing the method according to any one of claims 1 to 19 when the instructions are executed by a processor.

21. A device for executing a computer program according to claim 20, in, The apparatus comprises a memory storing the computer program and a processor connected to the memory.

Images