WO2015139755A1

WO2015139755A1 - Method and engineering system for verifying an automation program

Info

Publication number: WO2015139755A1
Application number: PCT/EP2014/055624
Authority: WO
Inventors: Martin Richard NEUHÄUSSER; Thomas Trenner; Sylvia REICHARDT
Original assignee: Siemens Aktiengesellschaft
Priority date: 2014-03-20
Filing date: 2014-03-20
Publication date: 2015-09-24

Abstract

The verification of automation programs is to be configured more efficiently. For this, a first predicate logic formula (Ψ) of the automation program (PRO) and a second predicate logic formula (¬ß) are proposed to determine undesired behaviour of the automation system and to combine these two formulas into one complete AND formula. The complete formula is then examined for truth. To determine the first formula (Ψ), a graph model of instructions (*) of the automation program is used and, for each program step in the first formula, only the respective instructions are considered which can actually be achieved on the basis of the graph model in the respective program step.

Description

description

Method and engineering system for verifying a

automation program

The present invention relates to a method for verifying an automation program for automation ^¬ assurance system by determining a predicate logic first formula of the automation program with a Recheneinrich ^¬ tung, determining a predicate logic second formula of undesirable behavior of the automation system with the computing device, ANDing the first and second Formula with the computing device to a total formula and testing with a test device, whether the overall formula is true under at least one condition. Moreover, the present invention relates to a corresponding engineering system for verifying an automation program. Programmable logic controllers (PLC; English: PLC = Programmable Logic Control), industrial to take are embedded systems that are programmed by programming languages according to IEC 61131-3 out specific reasoning tasks Steue ^¬. Logical errors in these programs generally lead to a standstill of the system and can also pose a danger to operating personnel and the environment. They generate very high costs in a short time and are therefore to be excluded as much as possible due to regulatory measures as well as for economic reasons. So far, this has been done by tests whose scope differs depending on the criticality of the system. Testing involves a great deal of time and money and remains inherently incomplete, as it does not prove the absence of errors except for trivial code. This circumstance can be counteracted by means of a code verification.

For this purpose, a verification tool is created, which checks ^¬ fully automated by means of a formal predetermined characteristic the code fragment to be tested. This can save costs be reduced in the system test, the quality of the resulting code is improved and costs due to errors in operation (eg due to errors overlooked in the system test) can be reliably avoided.

Previous tools for system validation focus on the calculation of safety properties (eg reliability values), whereas the verification with Bounded Model

Checking the fulfillment of a property of PLC code math ^¬ matically verifies. In addition, the property of the PLC code to be tested does not necessarily have to be security-relevant, but can also serve to prove the function of an algorithm. Even in the academic field, no tools are known that can automatically lead to logical proof of correctness of PLC programs. The reasons for this are in particular the complexity of the verification, which leads to the fact that even for small PLC programs an algorithmic proof often fails (either due to the exponential memory requirement or the runtime, which increases exponentially).

The object of the present invention is thus to provide a method with which it is possible to investigate an automation program for an automation system for undesired behavior. In addition, an engineering system is to be provided with which such a verification is possible.

According to the invention this method is achieved by a drive Ver ^¬ for verifying an automation program by for an automation system

Determining a first-order logic first formula of the automation program with a computing device, determining a predicate-logical second formula of undesired behavior of the automation system with the computing device,

ANDing the first and second formulas with the computing device into an overall formula and Check with a test device whether the overall formula is true under at least one condition,

in which

for determining the first formula with the computing device, a graph model of instructions of the automation ^¬ program is used and

only Dieje ^¬ Nigen instructions are considered for each program step in the first formula, which are actually reachable from the graph model in the respective program step.

In addition, the invention provides a

Engineering system for verifying an automation program for an automation system with

a computing device for determining a predicate-logical first formula of the automation program, for determining a predicate-logical second formula of undesired behavior of the automation system, and for ANDing the first and second formulas into an overall formula and

a test device for checking that the overall formula is true under at least one condition,

in which

in the computing device, a graph model of instructions of the automation program for determining the first formula is implemented, and

the computing device is designed so that only those instructions are taken into account for each program step in the first formula, based on the

Graphene model in the respective program step are available at all.

In an advantageous manner, the invention thus makes it possible, in the search for conditions for undesired behavior of the automation program or of the automation system, to use a graph model with which only those instructions are analyzed which are actually achieved in the individual sequence steps of the automation program. With this determination of the possible instructions, the number of instructions to be checked is drastically reduced, in particular in the case of automation programs. The reason for this is that automation programs usually have no loops or branches, so that in each workflow step, not all instructions of each Pro ^¬ must be checked program branch. On the contrary, due to the previ ^¬ ously cyclical execution models of PLC programs, usually only one or very few instructions are to be checked in each execution step.

For example, one of the instructions may relate to an engine speed of the automation system. This makes it possible to check whether the automation program controls the automation system to an undesirably high engine speed.

Alternatively or additionally, one of the instructions may relate to an angle of a controller or encoder of the automation system. This makes it possible to check, for example, whether a swivel arm of the automation system pivots into a prohibited or safety-relevant area.

Preferably, the automation program is a program for a programmable logic controller. As mentioned above, in such PLC programs are usually given purely sequential processes. For example, in one step, a sensor detects an engine speed, and in a second step, this engine speed is used to control another component. With such sequential processes, ie if there are no loops, the optimization according to the invention can be most benefited by a graph model of the instructions.

It is particularly advantageous if path information for each instruction of the automation program is determined for determining the first formula, and the path information is the set of step numbers in which the respective instruction can be reached in the automation program is. The path information thus provides for an instruction the information in which steps this information is reached. Conversely, it can be immediately deduced from the path information which instructions can be reached in a certain step. This results in the optimization that not all instructions must be checked.

Unwanted behavior of the automation system may be visualized by a visualization device if the overall formula is true under the at least one condition. By checking the truth of the overall formula can be targeted manner thereon so that the automation program and the automation system displays an undesirable behavior, which can then be visually ei ^¬ nem operator negotiate to correct the Automatisierungspro ^¬ program accordingly.

The present invention will be further explained with reference to the accompanying drawings, in which:

1 shows a principle of the automatic code verification for

PLC programs;

2 shows a detailed description of the formal verification approach;

3 shows an automation program with a loop;

and

4 shows a reduction of the obligation of proof by limiting to syntactically possible program paths.

The embodiments described in more detail below represent preferred embodiments of the present invention. An engineering system for creating automation programs can be designed in such a way that it contains a Veri ^¬ fikationstool or verification tool. In the engineering system can then be an automatic code verification, for example, for a PLC program after the

Scheme of FIG 1 are performed. Accordingly, a project or program PRO is provided ^¬ means of the engineering system. This PRO program undergoes fully automated VA verification. For this purpose it is fed to the verification tool VT. At the same time a desired or expected behavior EXB of the automation program and the automation system verification work ^¬ convincing VT is supplied ^¬ leads. The verification tool now determines whether the Pro ^¬ gram equivalent PRO expected behavior EXB. If that is the case, the verification tool VT is the Informa ^¬ tion "correct" co from. Otherwise, it sends the "incorrect" inco out. In the latter case, a entspre ^¬ sponding error visualization EV follows a visualization device. The presented visualization can be used by an operator to perform an error correction EC.

The verification tool VT thus automatically checks VA whether the expected property EXB is fulfilled by the program PRO to be examined. In the positive case, it has been mathematically proven that the PRO program fulfills the EXB property in all cases (ie the result is complete - unlike testing procedures). Otherwise, the property will EXB injured and the verification tool VT gene ^¬ preferably riert a counterexample CEX (see FIG. 2), which is provided for the developer as a diagnostic feedback (eg., In the form of a debugger) to him to assist with troubleshooting or error correction EC.

FIG. 2 shows the core of the verification method in more detail. The automation program becomes concrete

PRO translates into a model MOD in a translator TR. In a formula generator FG, the MOD model is represented in a symbolic So MOORISH model Ψ a predicate logic formula first set to ^¬.

The expected behavior EXB is converted into a predicate-logical second formula β by a further formalization tool FW. The formalization generator FG negates the second formula β - β. The Formalisierungsgenerator FG also outputs a test depth k before talking ent ^¬ the number of steps, which are executed by the automation program.

A so-called solver SOL, which serves as a checking device, checks for all steps k whether the predicate logic formulas -iβ and Ψ individually or their AND operation (overall formula) can be satisfied under at least one condition. If this is not the case, the solver SOL outputs a corresponding ^information USAT, which means that an undesired ^behavior in the automation program in all k

Steps is not present. Otherwise, if least determines under min- a condition of the Solver SOL that the AND operation of the two predicate logic formulas -, ß, and Ψ is true, it displays the information satellite from which be ^¬ indicated that occurs in the automation program unexpected behavior , Based on this information, the SAT counterexample CEX is generated, which can be used to modify the Pro ^¬ program PRO.

In this verification, therefore, the semantics of each instruction (ie the way the machine state is changed by executing the instruction) is formalized as a predicate logic formula. The individual formulas are then conjugated with the negation of the property to be detected, and placed in the so-called SMT solver SOL, which searches for satisfying assignments for the resulting overall formula. Due to the negation of the property, such a satisfying occupancy (if it exists) describes a violation of the expected property (EXB) by the program PRO. In the other case, there is no satisfying occupancy. It means that the property EXB is valid among all possible program executions.

To implement a formal verification, so the semantic policy of the language elements of the program fragment to be tested so ^¬ to formulate how the property to be tested accurately. Both activities are automated to a possible ß ^¬ gene rierendes model and Ψ with a tool (TR, FW and FG) implemented. In general, grows in automated evidence (ie, for. Example, the program variables) process the time and space complexity of the Ve ^¬ rifikation the model exponential in the number of model ^¬ variable and the possible program branches. This means that the calculation time required to test the model against the specified property can be so great even for small program fragments that practical use is no longer possible. In addition to runtime, disk space requirements generally increase exponentially. To limit this increase to Re ^¬ computing time and storage requirements, inventions will dung as a static pre-analysis example of the PLC program (hereinafter, "path analysis" called) performed that determines the possible program paths If this Informa ^¬ tion used., The actual verification can . be performed significantly faster off under Beibe ^¬ attitude of the original precision the present invention addresses this problem by reducing the size of the verification model - and with which the solver is faced with the problem - is reduced by restricting the syntactically possible program paths.

FIG. 3 shows an automation program in the programming language AWL which calculates the largest common divisor of two numbers a and b and places it in the first accumulator. An input arrow EP symbolizes the start of the program. Program ^{sections are labeled} 1, 2, 3 and 4. Jump instructions on lines 4 and 13 form a loop structure with a complex number of loop iterations. The following is a proof obligation for the program of FIG.3 without the inventive path analysis and optimization ^¬ tion is represented:

ψ2 = φ2, ΐΛφ ₂ , 2Λφ2,3Λφ ₂ , 4

ψ3 = φ3, ΐΛφ3,2Λφ3,3Λφ ₃ , 4

ψ4 = φ4, ΐΛφ4 _ί 2Λφ4 _ί 3Λφ _4ί 4

In this case, ψι denotes a call or a step in the automation program and φ ± _ιΐα an instruction in the ith step in the _mth program section. It can be seen that all instructions cpi, _{m are} taken into account here for the entire steps ψι, so that a matrix is created. With each step and each program section of the matrix is increased by one row and thus the Beweisver ^¬ obligation correspondingly more complex.

FIG. 4 shows a graph model of the individual instructions cpi, φ ₂ , φ3 and φ4. These instructions cpl to φ4 have the same effect as the program sections al to a4 of FIG. 3. However, the path analysis and optimization according to the invention are used here. This results in the following simplified formulas needed for verification:

Ψι ° ^ρ "= φι, ι

The first line of these formulas results from the fact that in the first step i | ri ^opt only the instruction cpi can be achieved. In the second step i | i2 ° ^pt , either the instruction Φ2 or the instruction 93 is reached. In the third step i | i3 ° ^pt , either in the case of the loop passage starting from Instruction φ ₃ again reaches the instruction cpi or it is jumped starting from the instruction 9 ₂ to the instruction φ ₄ . In the fourth step i | i4 ° ^pt , after the first loop pass, starting from instruction cpi, either instruction 9 ₂ or instruction φ _{3 is} jumped. Another possibility in the fourth step is not. In the fifth step i | i5 ° ^pt , starting from instruction 9 _2, the instruction jumps back to instruction φ ₄ in the fourth step or back to instruction cpi on the basis of instruction φ ₃ . The formulas can be continued in this way.

In the above example, the size of the formulas is reduced by a factor of 2k, where k is the number of program steps considered. It should be noted that control programs are generally much less complex in their operation. In particular, only very simple loops exist whose iteration number is usually constant and is not dynamically determined as in FIG. The simpler the cyclic program paths in the program, the greater the reduction of the size and complexity of the evidence obligation.

It should be explicitly pointed out that the said Proble ^¬ matics is independent of the particular programming language, in particular, it applies regardless of whether the verification environment in a PLC is used. Yet is their special ^¬ those benefits in automation technology as by the cyclic execution model of today's programmable logic controllers and the fact possess rolling flow graph a very simple and iA acyclic Kont- the resulting time requirements PLC programs.

All optimized steps i | ri ^opt , i | r2 ° ^pt , ψ3 ^0ρΐ -. be "ANDed" to ei ^¬ ner predicate logic first formula Ψ (ie AND linked) Finally, the predicate logic ers ^¬ te formula Ψ is then reacted with the predicate logic second formula - ANDed ß so that ultimately results in the total formula. ψ ₁ ° ^ΓΛ Λψ2 ^ΟΓΛ Λψ ₃ ^ΟΓΛ ... Λ ^ β This overall formula is tested in the tester or solver SOL for conditions where it is true. If this is the case, is - as above erläu- tert - an undesirable behavior of the Automatisierungspro ^¬ program before.

Core of the path analysis is a two-step approach leads ^¬ out on a processing unit, wherein pre- dikatenlogischen formulas, a model in the form:

1. For each program instruction instr ± it is checked whether instr ± π in at least one program path after a gegebe ^¬ NEN number j is performed by steps. The result of this check is stored as analysis or path information AI ±. Thus, AI ± is the amount of step numbers in which the ith instruction can be achieved in the underlying program. Specifically, this means that

3, 5, ..}, because the first instruction cpi becomes the first step, after a loop pass in the third step and another

Loop passage in the fifth step, etc. reached. In addition, Al ₂ = {2, 4, 6, ..}, because the second instruction cp2 is reached in the second step, after a loop pass in the fourth step, after two loop passes in the sixth step, and so forth. The following path information AI ± is similar.

2. The predicate logic formula that formalizes the program semantics in the jth step is restricted to the instructions instr ± for which there is an execution path π such that instr ± is performed in the jth step. This means that all the path information AI ± examined to determine who ^¬ whether a particular step (step number) is included. For example, all path information AI ± after the number 5 (ie step 5) are examined. Therein lies the optimization ^¬ tion or reduction: are to formalize Instead each execution step in that all program instructions considered possible, the quantity of candidates can be obtained by the Path analysis are drastically restricted. As a result, only such instructions are discarded that are guaranteed not to come in the j-th step to execute. With the path analysis explained above, polynomial reductions of the size of the proof commitment are achieved in acyclic control flow graphs (from square matrix to a vector). This leads to significant efficiency gains in verification. Test results that achieved a speed improvement by a factor of 10 or higher could be proven. The verification of non-trivial PLC programs becomes possible in the first place.

Static analyzes are known from the field of compiler construction in computer science. The analysis information calculated with the path analysis is in the manner according to the invention in FIG

Compiler construction can not be used because there are no restrictions on the instruction number considered (as in bounded model checking). Furthermore, the presented path analysis for Bounded Model Checking of arbitrary programs can be used in principle, but is generally inefficient due to complex loops and recursions.

On the application in the field of PLC programming the Bounded Model Checking can be used as a process, as a PLC forces due to the real-time requirements per execution cycle ^¬ an upper bound on executable instructions and has a cyclical model. In addition, PLC programs usually have a simple and linear sequence structure. Therefore, the path analysis as a preliminary analysis for the verification of PLC programs is particularly suitable. In general, the path analysis can bring great benefits for all simple ^programs . In a specific area of application, safety modules can be verified that serve to safely monitor a hazardous area in automation systems. This can be verified that the security modules z. B. also ensure that the danger zone is not affected by a machine or plant.

Reference sign list

PRO program

EC error correction

EV error visualization

EXB expected behavior

VA fully automatic verification

VT verification tool

inco information "incorrect"

CO information "correct"

MOD model

ß predicate logical formula

predicate logic formula

Ψ predicate logic formula α, ι to a ₄ program section

k test depth

FW formalization tool

FG formalization generator

TR translator

SOL solver

USAT information

SAT information

CEX counterexample

EP input arrow

Claims

claims

A method for verifying an automation program for an automation system

Determining a predicate logic first formula (Ψ) of the automation program (PRO) with a Recheneinrich ^¬ tion (TR, FW, FG),

Determining a predicate-logical second formula of undesired behavior of the automation system with the computing device (TR, FW, FG),

ANDing the first and second formulas with the computing device (TR, FW, FG) into an overall formula and testing with a test device (SOL), if the overall formula is true under at least one condition,

characterized in that

for determining the first formula (Ψ) with the computing device (TR, FW, FG) a graph model of instructions (cpi to cp ₄ ) of the automation program (PRO) is used and

for each program step (ψι to ψ ₄ ) in the first formula (Ψ) only those instructions (cpi to cp ₄ ) are taken into account, which are even reachable on the basis of the graph model in the respective program step (ψι to ψ ₄ ).

2. The method of claim 1, wherein one of the instructions (cpi to cp ₄ ) relates to an engine speed of the automation system.

3. The method of claim 1 or 2, wherein one of the instructions (cpi to cp ₄ ) relates to an angle of a controller or encoder of the automation system.

4. The method according to any one of the preceding claims, wherein the automation program is a program for a programmable logic controller.

5. The method according to any one of the preceding claims, wherein the automation program has no loops.

6. The method according to any one of the preceding claims, wherein for the determination of the first formula (Ψ) a path information (Ali) for each instruction (cpi to 9 ₄ ) of the automation program is determined, and the path information (Ali) while the amount of Step numbers is in which the respective instruction (cpi to 9 ₄ ) can be reached in the automation program.

A method according to any one of the preceding claims, wherein undesirable behavior of the automation system, i. if the overall formula under the at least one condition is true is visualized by a visualization device.

8. Engineering system for verifying an automation program for an automation system with

a computing device (TR, FW, FG) for determining a predicate logic first formula (Ψ) of the automation program, for determining a predicate-logical second formula (-iss) of undesired behavior of the automation system, and for ANDing the first and second formulas an overall formula and

a checking device (SOL) for checking whether the overall formula is true under at least one condition,

characterized in that

in the computing device (TR, FW, FG) a graph model of instructions (cpi to 9 ₄ ) of the automation program for determining the first formula (Ψ) is implemented and - the computing device (TR, FW, FG) is designed

that, for each program step (ψι to ψ ₄₎ in the first formula (Ψ) are taken into account only those instructions (cpi to cp ₄₎ in which each ^¬ weiligen program step on the basis of the graph model (ψι to ψ ₄₎ are actually reachable.

9. The engineering system according to claim 8, which has a visualization device with which an undesired behavior th of the automation system, ie if the overall formula under the at least one condition is true, can be visualized.