- Email: [email protected]
Formal verification of PLC-programs
FORMAL VERIFICATION OF PLC-PROGRAMS ...
Copyright © 1999 IFAC 14th Triennial World COnJuess,
14th World Congress oflFAC
C-2a-15-1 Beiiin~,
P.R. China
FORMAL VERIFICA nON OF PLC-PROGRAMS
Dr. Th. Filkorn, M. HOlzlein, Dr. P. Warkentin, M. Wei8
Siemens Corporate Technology 81730 Munich, Gennany email: [email protected]
Abstract: Siemens Corporate Technology has developed a methodology for formal verification. This methodology allows to prove or falsify the correctness of programs for a PLC (programmable logica1 controller) fully automatically and exactly in a strongly mathematical sense. A program is correct, if every possible execution trace of the program fulfils a set of required properties specified by the user. For instance, a property for a traffic light control at some given intersection could be 'traffic lights never all show green at the same time' or 'when a car stops at a red traffic light that traffic light will eventually switch to green'. For this verification method a tool has been developed that checks properties fully automatically and completely. In case a given property is not satisfied by the PLC-program, the verification tool generates an execution trace of the program (a so-called countersequence) that illustrates its erroneous behaviour. In a pilot application, tool machine manufacturers used and evaluated the verification tool with respect to specification, error detection, costfbenefitestimation and other criteria for verification. The verification tool was received very well. Copyright 0 1999 IFAC Keywords: Formal Verification, Control Design, Programming Support, Debugging, Error Detection, Productivity, Quality Control.
1. WHAT IS FORMAL VERIFICATION? This paper introduces a methodology with the expression 'Fonnal Verification of PLC-Programs' that allows to give a mathematical proof for the correctness of PLC-programs with regard to a formal specification. Further infonnation about this methodology is given in section 6. HOlzlein et al (1998) give a detailed description of the tool. So far formal verification has been applied to instruction list- and HiGraph-prograrns. HiGraph-programs are graphical state-oriented automation-programs for the PLC SIMATIC S7 by Siemens. Such programs are developed with the CASE-tool HiGrapb (Siemens, 1997) by Siemens (the following sections refer to HiGraph mainly). The underlying state diagram methodology is based on results of a German
working group consisting of PLC-manufacturers and PLC-applicants. Rath (1997) provides further information on the methodology. Emphasis has to be placed upon the fact that the checking algorithm of the Siemens verification tool works fully automatically which allows an application in the industrial area without problems - not only to HiGraph but also to other automation languages and to SDL for telecommunication software. As a result, the proposed method has the following advantages: • increase of productivity and cost reduction due to error detection in early development phases by the developer, • target-oriented debugging of errors by the developer on the basis of fully automatically generated countersequences that illustrate the erroneous behaviour of the program,
1513
Copyright 1999 IFAC
ISBN: 0 08 043248 4
FORMAL VERIFICATION OF PLC-PROGRAMS ...
14th World Congress oflFAC
Method
Advantages
.Ir.-er
Disadvantages
IIIoIIi
•
safety by complete correctness checking (with regard to specifications), • regression test after program modifications, • possible application to certification of automation programs, • exact specification of properties to be held for the control, • acceptance of control with program checking by the principal. Table 1 shows a swnmary of advantages and disadvantages of various methods for quality management and error detection which are used nowadays. The essential disadvantages of the other methods are the high costs and their incompleteness. Section 2 describes the schematic structure of the verification and introduces a tool machine and its control. In section 3, the user language for properties and assumptions is introduced and examples for the tool machine are given. Section 4 shows how verification is used to detect and debug errors in the control (program) for the tool machine . Section 5 illustrates the support of semantical analysis by the verification tool. In section 6, a methodology for finding a certain class of properties in a systematical manner is introduced. A short deSCription of the technological basis in section 7 and the presentation of our results and experiences in section 8 conclude the paper.
2. ANALYSING PLC-PROGRAMS WITH VERIFICATION Figure 1 shows the schematic structure of the verification from the user's point of view. The verification tool requires as input the system description and the
1 -.. o_eqilW_bolC '"'" l;
O_ Ql,iJ)ILCn -
§OGD"
hOllib
-~.-,.- - . -.---- ---
- complex + fully automatic Formal algorithmics Verification + complete -new + comfortable methodology + counter sequence (training in case of errors required) + documentation high costs for + simple Program + established method intensive testing testing - incomplete - high costs for Simulation + illustrative process simulation - long runtime - incomplete Code- high costs + documentation Reviewl - incomplete InsEection
Properties
System Description
Tablel FOTInal verification versus conventional methods
l-.J.mL1IDp =
1
O_=IU._,~ ,.,.
1;
V isua liZation
prup_...wIU,..lLop
.ono
antn i d . =1ID~UCI"l~ ~",,,k;d
Fig. 1. Verification structure from the user' s point of view properties defined by the user and computes whether the properties are valid or not. In case of invalidity (error case) the tool generates a countersequence that guides the user to the program error. Such a sequence is visualized in the case-tool like HiGraph. Internally, the verification tool works with a finite state machine representation that models the system behaviour. The existing system description given as a HiGraph program is automatically translated into this internal format. Besides HiGraph programs, there are also translations from VHDL (hardware descriptions), SDL (telecommunication protocols) and from instruction list programs (PLC-programs), being used and developed at Siemens, into the internal finite state machine format. In the following the focus is on the verification of HiGraph-programs that are developed with the CASE-tool HiGraph by Siemens. HiGraph generates the machine code MC 7 of the PLC S7 by Siemens. Based on the example of a tool machine control for a station of a transfer line for motor engine manufacturing the methodology of verification and state diagrams is illustrated. Figure 2 shows the structure of a tool machine unit and its control. A carriage with two spindles moves back and forth between the rear tool exchange position and the front machining position. In the front position the workpiece, a connecting rod, is machined with the spindles while a cooleant is added. For instance, two holes are drilled into the workpiece. The control is arranged in 3 levels: decision level, coordination level and power level. The levels are realized by various components described as state diagrams (cf. fig. 3). The state diagrams communicate with each other and their environment, i.e. machine process and possibly other control processes, via messages or global variables. For instance, the state diagram "decision" of the decision level releases the carriage to move back by setting the message 'release_movin~back'. State diagram 'moving back' of the coordination level reacts to this message by sending the message 'command_spindle_l_off' to the state diagram 'spindle_I' of the power level
1514
Copyright 1999 IFAC
ISBN: 0 08 043 248 4
14th World Congress oflFAC
FORMAL VERIFICATION OF PLC-PROGRAMS ...
tfrGmC!b:ftogrc:rn d.::1V2
(0 :~lTllltl~~)piJdll)_tl~; ..
lO 11)~'fle1 UJr; co()(din.~\¥r
(''''J''t'·;) I
I"n 0 ,elf.1
jeomrnill(spod1EJ .JR: Cill.SFrdil1i•.t C'Q ~~_~W,
.~~aft.p rt:(,ntOl ;
Fig. 2. Program architecture and machine process which finally turns off spindle_l by resetting the actuator 'spindle_I_on' to O. The control program for this station is also influenced by the top control program for the whole transfer line. For example, the top control program sends the signal 'all_spin dIes_off' to all stations of the transfer line forcing all stations to turn off their spindles. Figure 3 represents a strongly simplified state diagram 'spindle_I' for the direct control of the spindIe_Ion the carriage. It consists of the initial state 0 and the additional states 2, 4 and 6 (bold numbered circles). As can be seen from the diagram, a state transition from state 6 to state 4 occurs if and only if transition condition number 10 holds, i.e. if one of the variables 'command_spindle_l_on' and 'all_spindles_on' has the value 1. In state 4 the action 'N spindle_Con' is executed as long as the program control remains in state 4. The semantics of this action is such that in state 4 the actuator 'spindle_I_on' is set to 1, but is reset to 0 as soon as state 4 is left! Therefore, in state 6 the actuator has got the value 0 as required. More detailed information about state diagrams and the case-tool HiGraph can be found in the language manual (Siemens, 1998).
3. PROPERTIES AND ASSUMPTIONS For specifying the desired or required behaviour of control programs, the user formulates properties and asswnptions. Properties are required (partial) specifications of the control program that have an exact semantical meaning . Specifications express, for instance, what behaviour is allowed by the control, what is forbidden or what must be guaranteed at any rate. Assumptions, on the other hand, describe specifications about the environment (machine process) the developer has in mind with regard to the interaction with the control program. Both properties and assumptions are formulated using an intuitive user language developed at Siemens that is based on natural language constructs from English or German with an underlying exact semantics. Expressions built with the used program variables are inserted into these patterns. Some constructs of the user
0(; rW c~mmiiTd
/
I'~~;'-"~ I
I ~,.
I tll';
AA1t!pi!t i~_;'Il : ~-
I;
octmmar(&;IinileJ }fl; Oitwflrlln. at;
O iCo~_c'rires;
Fig.3. State diagram 'spindle_I' language that are used frequently include: ALWAYS HOLDS ... NEVER HOLDS ... AS LONG AS ... HOLDS .. . AS SOON AS ... HOLDS .. . AS SOON AS ... THEN AS LONG AS ... UNTIL '" An example for a property for the tool machine unit described in section 2 is that 'spindle_Lon' receives value 0 within at most I PLC cycle after one of the variables 'command_spindle_ Coff' or 'all_spindles_off' received the value 1. The formulation of the property in the user language is as follows: AS LONG AS command_spindle_l_off == 1 or all_spindles_off = 1 HOLDS AT THE LATEST AFfER 1 CYCLE (spindle_on == 0) (1) Given such a property, the verification tool can check whether the property holds for the given program for every possible sequence. In case of an error the tool presents a concrete countersequence starting in an initial state and showing the values of all input, output and program variables for each PLC cycle up to a point in which the computed sequence violates the required property. Such countersequences consist of two parts, the first leading to an error constellation, and the second exhibiting the erroneous behaviour. It is possible, however, that a generated countersequence does not describe real program errors but represents an unrealistic execution behaviour. In
1515
Copyright 1999 IF AC
ISBN: 0 08 043248 4
14th World Congress oflFAC
FORMAL VERIFICATION OF PLC-PROGRAMS ...
order to understand why this can happen you need to keep in mind that although the verification tool has got the necessary information about the control program itself possibly important information about the environment is lacking. Recall that the environment consists of machine and other control parts that are not part of the control program to be verified, but communicate with the control program (for example via shared memory or via sensors and actuators). Without any additional infonnation about the environment, the verification tool assumes an arbitrary behaviour that might lead to unrealistic executions. With the help of assumptions (interface specifications) the user is in the position to specify environmental behaviour in a more detailed way. Successful verification therefore amounts to showing that the control program fulfils the required properties under the assumptions imposed on the environment. For this example, one can add the following assumption about the top control program that is not part of the state diagram program under consideration ALWAYS HOLDS alCspindles_on == 0 or all_spindles_off == 0 (2) This assumption expresses that the top control never sends the signals 'all_spindles_on' and 'all_spindles_off' to the stations at the same time. While this assumption seems to be reasonable, it is worth to have a closer look at it. On the one hand this assumption about the behaviour of the top control which is not a verification object in this contex:t reflects a property for the top control which must still be checked. On the other hand the necessity of such an assumption indicates the lack of robustness of the HiGraph-program with regard to "erroneous" behaviour of the top control. In addition to stating such reasonable requirements on the environment, assumptions are also used to disallow certain behavioural sequences for the verification. For example, if one wants to exclude the manual operation mode of the control from the verification the following assumption about the HiGraph system variable 'om_manual' (operation mode manual) can be added: ALWAYS HOLDS om_manual 0 (3)
==
This effectively focuses the subsequent verification task to those system executions that do not allow manual interaction.
4. APPLICATION OF VERIFICATION In the following the practised application of the verification method to the example of section 2 is illustrated. The goal is to verify propeny 1 already introduced in section 3. Without further assumptions
Table 2 Counterseguence for property 1
01234 PLC cycle 00110 [SPINDLE_l,alLspindles_onJ 01000 [SPINDLE_1,alLspindles_off] [SPINDLE_l,command_spindle_l_on] 00000 [SPINDEL_l,command_spindle_l_off] 00010 00011 [SPINDEL I,spindle Ion] the verification tool computes a countersequence in which the operation mode is "manual" and in which the top control issues the inconsistent commands 'all_spindles_on==l' and 'all_spindles_off==1 ' at the same time. Since the property is not required to hold in the operation mode "manual" and since the designer can assume that the top control is implemented correctly - at least with regard to the consistency of the commands 'all_spindles_on' and 'all_spindles_off' sent to the single stations - assumptions 2 and 3 from section 3 are added to the verification task. This approach is typical of verification. Firstly, you try to verify your property without assumptions, i.e. for the most general environment. In case of the output of countersequences assumptions are added successively if necessary. Otherwise the countersequences lead to a program error. With these assumptions the verification tool determines that the above property is violated, and reports the countersequence as shown in Table 2. In order to interpret such a sequence the program developer concentrates on the end of the sequence where the erroneous behaviour is manifested. The beginning of the sequence just leads into the error constellation. By examining individual columns, the developer gains an overview of the whole constellation. In PLC cycle 4 of the given countersequence 'spindle_I' is turned on although in the preceding PLC cycle a command to turn it off has been issued. A snapshot of the total configuration at PLC cycle 3 is shown in Figure 4. While the carriage is moving back both 'command_spindle_I_off' and 'alCspindles_on' from the top control are set to 1. But the control seems to ignore the command to turn the spindle off. Based on this observation, the next step for the developer consists in putting the behavioural sequence into relationship to the program itself (see Figure 3) in order to detect the program error. The reason for the erroneous behaviour here is that a transition from state 6 to state 4 of state diagram 'spindle_I' is made due to the 'all_spindles_on' command (from top control). During this transition no commands are taken into consideration that could turn off the spindle ('command_spindle_l_off' , 'all_spindles_off') although they occur in the countersequence. In order to correct the control program error the developer can now inspect the transition condition of the violating transition from state 6 to state 4 and can
1516
Copyright 1999 IFAC
ISBN: 0 08 043248 4
FORMAL VERIFICATION OF PLC-PROGRAMS ...
14th World Congress ofIFAC
6. METHODOLOGY FOR FINDING PROPERTIES
Fig. 4. situation represented in PLC cycle 3 of relating countersequence modify it in such a way that the transition fires only if there is no command to turn spindle_l off. In order to achieve this, he simply adds AN command_spindle_Loff; AN all_spindles_off; to the transition 10 ('AN' means 'AND NOT'). The modified program can then be checked by simply running the verification tool again since property and assumptions remain unchanged (only the program itself has been modified). The tool could now report further errors or the validity of the property under these assumptions. In this case verification establishes that the property indeed holds for the modified program under the stated assumptions.
5. SEMANTICAL ANALYSIS The verification tool does not only check whether properties hold or not, but also produces information based on a semantical analysis of the dynamic behaviour of the control program. Different kinds of information about the program can be extracted that way, among which the following have been found especially useful: • reachability of the states of the state diagrams, • indication of transitions that never fire, • list of all logical input variables, i.e. variables that are only read, but not written to by the program. The discovery of unreachable states usually hints at a design error. By specifying properties concerning some unreachable state and the transition leading to it the developer can detect errors in his programming logic. A transition that never fires often points to an error in the corresponding transition condition or in the sequence of priorities given to transitions. Finally, the list of all logical input variables can be compared with the actual input variables; differences often point to the mix-up of variables or to faulty mapping of program variables to the address space of the PLC.
Experience shows that the main job for the user of the verification method is to find suitable properties. In order to support this task, a methodology has been developed that aides the user in achieving this. The basic idea is to determine for each actuator the values of the sensors that requires it to be set or to be reset. More specifically, the proposed method proceeds in the following steps: 1. Build the two lists of all input and output variables 2. For each output variable it is to be determined under which (input-) condition the variable is required to have value 0 3. For each output variable it is to be determined under which (input-) condition the variable is required to have value 1 The formulation of the property in step 2 for the value 0 of the output variable is normally quite easy. This is the case because value 0 normally represents the safe state of an actuator. Therefore. the conditions for making an actuator become "safe" is simple and often very general. Contrary to this, setting an actuator is allowed typically only if neither the reset condition nor some often complex restrictions on the control's environment do hold. Following this methodology the user is guided towards obtaining specifications of the control as complete and exact as possible. The methodology, however, does not help in finding properties about the relationship between different actuators. It is very difficult to support the finding of such properties in a methodological way as these properties typically depend strongly on the control task, at hand. Similarly, properties about the program design such as specifications of the relationship between internal variables (variables that cannot be accessed from outside the program) and input/output variables (interface variables) cannot be derived in a general fashion since such properties typically depend on design decisions made by the programmer. Frequently, a part of these properties can be formulated as invariants. Thus the property ALWAYS HOLDS
specifies an invariant of a control for a multi-storey car park.
7. TECHNOLOGICAL BASIS Figure 1 not only describes the application of the verification method but also the fundamental system architecture of the verification tool. The system description is translated into a finite state machine
1517
Copyright 1999 IF AC
ISBN: 008 0432484
FORMAL VERIFICATION OF PLC-PROGRAMS ...
representation whose behaviour is represented with the help of Binary Decision Diagrams (Bryant, 1986). The properties are translated into formulae (Emerson, 1990). The actual verification is performed with the techniques for symbolic mooe1 checking oftemporallogic. Burch et at (1994) give a good overview of these techniques. Symbolic model checking allows to verify systems with some hundred (state) variables at enormous amounts of reachable states in the finite state machine.
14th World Congress oflFAC
Siemens (1998) SIMATIC HiGraph for S7-300 and S7-400, Programming State Graphs, Manual, 6ES7-81l-3CA02-8BAO, Siemens AG, Ni.irnberg.
8. RESULTS About 80 state diagram programs by tool machine and assembly-line manufacturers have been analysed with the verification tool. Most of them represent programs for a station or top control. The size of them varies between 3 and 24 state diagrams. The average number of states per state diagram is about 7. The average number of variables per program is over 200. The line number of the exclusively textual representation varies from 400 to 3000. In almost all applications errors have been detected with the verification that have led to the modification of the program. Since verification checks every possible run of the control even errors that are rare and very difficult to detect have been found. The cost for formulating properties and the analysis of countersequences is rated low in comparison with the effort necessary for error debugging during first system start up or final operation. The time of a verification run per property depends on the program size and the properties and assumptions specified. A typical verification run takes between a few seconds and 120 minutes on a PC with Pentium-processor.
REFERENCES Bryant. R.E. (1986): Graph-based algorithms for boolean function manipulation.IEEE In : Transactions on Computers, C-35(8), 677-691. Burch, J.R., E.M.Clarke, D.E.Long, K.L.McMillan and D.L.Dill (1994). Symbolic Model Checking for Sequential Circuit Verification. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, Vol. 13, No.4, 401-424. Emerson, E.A.(1990). Temporal and Modal Logic In: Handbook of Theoretical Computer Science, Chapter 16, pp.996-1072. Elsevier Science Publisher, Oxford. Htilzlein, M. , Th. Filkom, P. Warkentin and M. WeiB (1998). Eine Veriftkationskomponente fUr HiGraph In: GMA-Kongress '98. VDI-Berichte 1397, pp. 281-290. VDI-Verlag, Dusseldorf. Rath, G. (1997): Zustandsgraphen - eine neue, aussichtsreiche Progranuniermethode. GMA-Bericht, 31.
1518
Copyright 1999 IFAC
ISBN: 0 08 043248 4
Copyright © 1999 IFAC 14th Triennial World COnJuess,
14th World Congress oflFAC
C-2a-15-1 Beiiin~,
P.R. China
FORMAL VERIFICA nON OF PLC-PROGRAMS
Dr. Th. Filkorn, M. HOlzlein, Dr. P. Warkentin, M. Wei8
Siemens Corporate Technology 81730 Munich, Gennany email: [email protected]
Abstract: Siemens Corporate Technology has developed a methodology for formal verification. This methodology allows to prove or falsify the correctness of programs for a PLC (programmable logica1 controller) fully automatically and exactly in a strongly mathematical sense. A program is correct, if every possible execution trace of the program fulfils a set of required properties specified by the user. For instance, a property for a traffic light control at some given intersection could be 'traffic lights never all show green at the same time' or 'when a car stops at a red traffic light that traffic light will eventually switch to green'. For this verification method a tool has been developed that checks properties fully automatically and completely. In case a given property is not satisfied by the PLC-program, the verification tool generates an execution trace of the program (a so-called countersequence) that illustrates its erroneous behaviour. In a pilot application, tool machine manufacturers used and evaluated the verification tool with respect to specification, error detection, costfbenefitestimation and other criteria for verification. The verification tool was received very well. Copyright 0 1999 IFAC Keywords: Formal Verification, Control Design, Programming Support, Debugging, Error Detection, Productivity, Quality Control.
1. WHAT IS FORMAL VERIFICATION? This paper introduces a methodology with the expression 'Fonnal Verification of PLC-Programs' that allows to give a mathematical proof for the correctness of PLC-programs with regard to a formal specification. Further infonnation about this methodology is given in section 6. HOlzlein et al (1998) give a detailed description of the tool. So far formal verification has been applied to instruction list- and HiGraph-prograrns. HiGraph-programs are graphical state-oriented automation-programs for the PLC SIMATIC S7 by Siemens. Such programs are developed with the CASE-tool HiGrapb (Siemens, 1997) by Siemens (the following sections refer to HiGraph mainly). The underlying state diagram methodology is based on results of a German
working group consisting of PLC-manufacturers and PLC-applicants. Rath (1997) provides further information on the methodology. Emphasis has to be placed upon the fact that the checking algorithm of the Siemens verification tool works fully automatically which allows an application in the industrial area without problems - not only to HiGraph but also to other automation languages and to SDL for telecommunication software. As a result, the proposed method has the following advantages: • increase of productivity and cost reduction due to error detection in early development phases by the developer, • target-oriented debugging of errors by the developer on the basis of fully automatically generated countersequences that illustrate the erroneous behaviour of the program,
1513
Copyright 1999 IFAC
ISBN: 0 08 043248 4
FORMAL VERIFICATION OF PLC-PROGRAMS ...
14th World Congress oflFAC
Method
Advantages
.Ir.-er
Disadvantages
IIIoIIi
•
safety by complete correctness checking (with regard to specifications), • regression test after program modifications, • possible application to certification of automation programs, • exact specification of properties to be held for the control, • acceptance of control with program checking by the principal. Table 1 shows a swnmary of advantages and disadvantages of various methods for quality management and error detection which are used nowadays. The essential disadvantages of the other methods are the high costs and their incompleteness. Section 2 describes the schematic structure of the verification and introduces a tool machine and its control. In section 3, the user language for properties and assumptions is introduced and examples for the tool machine are given. Section 4 shows how verification is used to detect and debug errors in the control (program) for the tool machine . Section 5 illustrates the support of semantical analysis by the verification tool. In section 6, a methodology for finding a certain class of properties in a systematical manner is introduced. A short deSCription of the technological basis in section 7 and the presentation of our results and experiences in section 8 conclude the paper.
2. ANALYSING PLC-PROGRAMS WITH VERIFICATION Figure 1 shows the schematic structure of the verification from the user's point of view. The verification tool requires as input the system description and the
1 -.. o_eqilW_bolC '"'" l;
O_ Ql,iJ)ILCn -
§OGD"
hOllib
-~.-,.- - . -.---- ---
- complex + fully automatic Formal algorithmics Verification + complete -new + comfortable methodology + counter sequence (training in case of errors required) + documentation high costs for + simple Program + established method intensive testing testing - incomplete - high costs for Simulation + illustrative process simulation - long runtime - incomplete Code- high costs + documentation Reviewl - incomplete InsEection
Properties
System Description
Tablel FOTInal verification versus conventional methods
l-.J.mL1IDp =
1
O_=IU._,~ ,.,.
1;
V isua liZation
prup_...wIU,..lLop
.ono
antn i d . =1ID~UCI"l~ ~",,,k;d
Fig. 1. Verification structure from the user' s point of view properties defined by the user and computes whether the properties are valid or not. In case of invalidity (error case) the tool generates a countersequence that guides the user to the program error. Such a sequence is visualized in the case-tool like HiGraph. Internally, the verification tool works with a finite state machine representation that models the system behaviour. The existing system description given as a HiGraph program is automatically translated into this internal format. Besides HiGraph programs, there are also translations from VHDL (hardware descriptions), SDL (telecommunication protocols) and from instruction list programs (PLC-programs), being used and developed at Siemens, into the internal finite state machine format. In the following the focus is on the verification of HiGraph-programs that are developed with the CASE-tool HiGraph by Siemens. HiGraph generates the machine code MC 7 of the PLC S7 by Siemens. Based on the example of a tool machine control for a station of a transfer line for motor engine manufacturing the methodology of verification and state diagrams is illustrated. Figure 2 shows the structure of a tool machine unit and its control. A carriage with two spindles moves back and forth between the rear tool exchange position and the front machining position. In the front position the workpiece, a connecting rod, is machined with the spindles while a cooleant is added. For instance, two holes are drilled into the workpiece. The control is arranged in 3 levels: decision level, coordination level and power level. The levels are realized by various components described as state diagrams (cf. fig. 3). The state diagrams communicate with each other and their environment, i.e. machine process and possibly other control processes, via messages or global variables. For instance, the state diagram "decision" of the decision level releases the carriage to move back by setting the message 'release_movin~back'. State diagram 'moving back' of the coordination level reacts to this message by sending the message 'command_spindle_l_off' to the state diagram 'spindle_I' of the power level
1514
Copyright 1999 IFAC
ISBN: 0 08 043 248 4
14th World Congress oflFAC
FORMAL VERIFICATION OF PLC-PROGRAMS ...
tfrGmC!b:ftogrc:rn d.::1V2
(0 :~lTllltl~~)piJdll)_tl~; ..
lO 11)~'fle1 UJr; co()(din.~\¥r
(''''J''t'·;) I
I"n 0 ,elf.1
jeomrnill(spod1EJ .JR: Cill.SFrdil1i•.t C'Q ~~_~W,
.~~aft.p rt:(,ntOl ;
Fig. 2. Program architecture and machine process which finally turns off spindle_l by resetting the actuator 'spindle_I_on' to O. The control program for this station is also influenced by the top control program for the whole transfer line. For example, the top control program sends the signal 'all_spin dIes_off' to all stations of the transfer line forcing all stations to turn off their spindles. Figure 3 represents a strongly simplified state diagram 'spindle_I' for the direct control of the spindIe_Ion the carriage. It consists of the initial state 0 and the additional states 2, 4 and 6 (bold numbered circles). As can be seen from the diagram, a state transition from state 6 to state 4 occurs if and only if transition condition number 10 holds, i.e. if one of the variables 'command_spindle_l_on' and 'all_spindles_on' has the value 1. In state 4 the action 'N spindle_Con' is executed as long as the program control remains in state 4. The semantics of this action is such that in state 4 the actuator 'spindle_I_on' is set to 1, but is reset to 0 as soon as state 4 is left! Therefore, in state 6 the actuator has got the value 0 as required. More detailed information about state diagrams and the case-tool HiGraph can be found in the language manual (Siemens, 1998).
3. PROPERTIES AND ASSUMPTIONS For specifying the desired or required behaviour of control programs, the user formulates properties and asswnptions. Properties are required (partial) specifications of the control program that have an exact semantical meaning . Specifications express, for instance, what behaviour is allowed by the control, what is forbidden or what must be guaranteed at any rate. Assumptions, on the other hand, describe specifications about the environment (machine process) the developer has in mind with regard to the interaction with the control program. Both properties and assumptions are formulated using an intuitive user language developed at Siemens that is based on natural language constructs from English or German with an underlying exact semantics. Expressions built with the used program variables are inserted into these patterns. Some constructs of the user
0(; rW c~mmiiTd
/
I'~~;'-"~ I
I ~,.
I tll';
AA1t!pi!t i~_;'Il : ~-
I;
octmmar(&;IinileJ }fl; Oitwflrlln. at;
O iCo~_c'rires;
Fig.3. State diagram 'spindle_I' language that are used frequently include: ALWAYS HOLDS ... NEVER HOLDS ... AS LONG AS ... HOLDS .. . AS SOON AS ... HOLDS .. . AS SOON AS ... THEN AS LONG AS ... UNTIL '" An example for a property for the tool machine unit described in section 2 is that 'spindle_Lon' receives value 0 within at most I PLC cycle after one of the variables 'command_spindle_ Coff' or 'all_spindles_off' received the value 1. The formulation of the property in the user language is as follows: AS LONG AS command_spindle_l_off == 1 or all_spindles_off = 1 HOLDS AT THE LATEST AFfER 1 CYCLE (spindle_on == 0) (1) Given such a property, the verification tool can check whether the property holds for the given program for every possible sequence. In case of an error the tool presents a concrete countersequence starting in an initial state and showing the values of all input, output and program variables for each PLC cycle up to a point in which the computed sequence violates the required property. Such countersequences consist of two parts, the first leading to an error constellation, and the second exhibiting the erroneous behaviour. It is possible, however, that a generated countersequence does not describe real program errors but represents an unrealistic execution behaviour. In
1515
Copyright 1999 IF AC
ISBN: 0 08 043248 4
14th World Congress oflFAC
FORMAL VERIFICATION OF PLC-PROGRAMS ...
order to understand why this can happen you need to keep in mind that although the verification tool has got the necessary information about the control program itself possibly important information about the environment is lacking. Recall that the environment consists of machine and other control parts that are not part of the control program to be verified, but communicate with the control program (for example via shared memory or via sensors and actuators). Without any additional infonnation about the environment, the verification tool assumes an arbitrary behaviour that might lead to unrealistic executions. With the help of assumptions (interface specifications) the user is in the position to specify environmental behaviour in a more detailed way. Successful verification therefore amounts to showing that the control program fulfils the required properties under the assumptions imposed on the environment. For this example, one can add the following assumption about the top control program that is not part of the state diagram program under consideration ALWAYS HOLDS alCspindles_on == 0 or all_spindles_off == 0 (2) This assumption expresses that the top control never sends the signals 'all_spindles_on' and 'all_spindles_off' to the stations at the same time. While this assumption seems to be reasonable, it is worth to have a closer look at it. On the one hand this assumption about the behaviour of the top control which is not a verification object in this contex:t reflects a property for the top control which must still be checked. On the other hand the necessity of such an assumption indicates the lack of robustness of the HiGraph-program with regard to "erroneous" behaviour of the top control. In addition to stating such reasonable requirements on the environment, assumptions are also used to disallow certain behavioural sequences for the verification. For example, if one wants to exclude the manual operation mode of the control from the verification the following assumption about the HiGraph system variable 'om_manual' (operation mode manual) can be added: ALWAYS HOLDS om_manual 0 (3)
==
This effectively focuses the subsequent verification task to those system executions that do not allow manual interaction.
4. APPLICATION OF VERIFICATION In the following the practised application of the verification method to the example of section 2 is illustrated. The goal is to verify propeny 1 already introduced in section 3. Without further assumptions
Table 2 Counterseguence for property 1
01234 PLC cycle 00110 [SPINDLE_l,alLspindles_onJ 01000 [SPINDLE_1,alLspindles_off] [SPINDLE_l,command_spindle_l_on] 00000 [SPINDEL_l,command_spindle_l_off] 00010 00011 [SPINDEL I,spindle Ion] the verification tool computes a countersequence in which the operation mode is "manual" and in which the top control issues the inconsistent commands 'all_spindles_on==l' and 'all_spindles_off==1 ' at the same time. Since the property is not required to hold in the operation mode "manual" and since the designer can assume that the top control is implemented correctly - at least with regard to the consistency of the commands 'all_spindles_on' and 'all_spindles_off' sent to the single stations - assumptions 2 and 3 from section 3 are added to the verification task. This approach is typical of verification. Firstly, you try to verify your property without assumptions, i.e. for the most general environment. In case of the output of countersequences assumptions are added successively if necessary. Otherwise the countersequences lead to a program error. With these assumptions the verification tool determines that the above property is violated, and reports the countersequence as shown in Table 2. In order to interpret such a sequence the program developer concentrates on the end of the sequence where the erroneous behaviour is manifested. The beginning of the sequence just leads into the error constellation. By examining individual columns, the developer gains an overview of the whole constellation. In PLC cycle 4 of the given countersequence 'spindle_I' is turned on although in the preceding PLC cycle a command to turn it off has been issued. A snapshot of the total configuration at PLC cycle 3 is shown in Figure 4. While the carriage is moving back both 'command_spindle_I_off' and 'alCspindles_on' from the top control are set to 1. But the control seems to ignore the command to turn the spindle off. Based on this observation, the next step for the developer consists in putting the behavioural sequence into relationship to the program itself (see Figure 3) in order to detect the program error. The reason for the erroneous behaviour here is that a transition from state 6 to state 4 of state diagram 'spindle_I' is made due to the 'all_spindles_on' command (from top control). During this transition no commands are taken into consideration that could turn off the spindle ('command_spindle_l_off' , 'all_spindles_off') although they occur in the countersequence. In order to correct the control program error the developer can now inspect the transition condition of the violating transition from state 6 to state 4 and can
1516
Copyright 1999 IFAC
ISBN: 0 08 043248 4
FORMAL VERIFICATION OF PLC-PROGRAMS ...
14th World Congress ofIFAC
6. METHODOLOGY FOR FINDING PROPERTIES
Fig. 4. situation represented in PLC cycle 3 of relating countersequence modify it in such a way that the transition fires only if there is no command to turn spindle_l off. In order to achieve this, he simply adds AN command_spindle_Loff; AN all_spindles_off; to the transition 10 ('AN' means 'AND NOT'). The modified program can then be checked by simply running the verification tool again since property and assumptions remain unchanged (only the program itself has been modified). The tool could now report further errors or the validity of the property under these assumptions. In this case verification establishes that the property indeed holds for the modified program under the stated assumptions.
5. SEMANTICAL ANALYSIS The verification tool does not only check whether properties hold or not, but also produces information based on a semantical analysis of the dynamic behaviour of the control program. Different kinds of information about the program can be extracted that way, among which the following have been found especially useful: • reachability of the states of the state diagrams, • indication of transitions that never fire, • list of all logical input variables, i.e. variables that are only read, but not written to by the program. The discovery of unreachable states usually hints at a design error. By specifying properties concerning some unreachable state and the transition leading to it the developer can detect errors in his programming logic. A transition that never fires often points to an error in the corresponding transition condition or in the sequence of priorities given to transitions. Finally, the list of all logical input variables can be compared with the actual input variables; differences often point to the mix-up of variables or to faulty mapping of program variables to the address space of the PLC.
Experience shows that the main job for the user of the verification method is to find suitable properties. In order to support this task, a methodology has been developed that aides the user in achieving this. The basic idea is to determine for each actuator the values of the sensors that requires it to be set or to be reset. More specifically, the proposed method proceeds in the following steps: 1. Build the two lists of all input and output variables 2. For each output variable it is to be determined under which (input-) condition the variable is required to have value 0 3. For each output variable it is to be determined under which (input-) condition the variable is required to have value 1 The formulation of the property in step 2 for the value 0 of the output variable is normally quite easy. This is the case because value 0 normally represents the safe state of an actuator. Therefore. the conditions for making an actuator become "safe" is simple and often very general. Contrary to this, setting an actuator is allowed typically only if neither the reset condition nor some often complex restrictions on the control's environment do hold. Following this methodology the user is guided towards obtaining specifications of the control as complete and exact as possible. The methodology, however, does not help in finding properties about the relationship between different actuators. It is very difficult to support the finding of such properties in a methodological way as these properties typically depend strongly on the control task, at hand. Similarly, properties about the program design such as specifications of the relationship between internal variables (variables that cannot be accessed from outside the program) and input/output variables (interface variables) cannot be derived in a general fashion since such properties typically depend on design decisions made by the programmer. Frequently, a part of these properties can be formulated as invariants. Thus the property ALWAYS HOLDS
specifies an invariant of a control for a multi-storey car park.
7. TECHNOLOGICAL BASIS Figure 1 not only describes the application of the verification method but also the fundamental system architecture of the verification tool. The system description is translated into a finite state machine
1517
Copyright 1999 IF AC
ISBN: 008 0432484
FORMAL VERIFICATION OF PLC-PROGRAMS ...
representation whose behaviour is represented with the help of Binary Decision Diagrams (Bryant, 1986). The properties are translated into formulae (Emerson, 1990). The actual verification is performed with the techniques for symbolic mooe1 checking oftemporallogic. Burch et at (1994) give a good overview of these techniques. Symbolic model checking allows to verify systems with some hundred (state) variables at enormous amounts of reachable states in the finite state machine.
14th World Congress oflFAC
Siemens (1998) SIMATIC HiGraph for S7-300 and S7-400, Programming State Graphs, Manual, 6ES7-81l-3CA02-8BAO, Siemens AG, Ni.irnberg.
8. RESULTS About 80 state diagram programs by tool machine and assembly-line manufacturers have been analysed with the verification tool. Most of them represent programs for a station or top control. The size of them varies between 3 and 24 state diagrams. The average number of states per state diagram is about 7. The average number of variables per program is over 200. The line number of the exclusively textual representation varies from 400 to 3000. In almost all applications errors have been detected with the verification that have led to the modification of the program. Since verification checks every possible run of the control even errors that are rare and very difficult to detect have been found. The cost for formulating properties and the analysis of countersequences is rated low in comparison with the effort necessary for error debugging during first system start up or final operation. The time of a verification run per property depends on the program size and the properties and assumptions specified. A typical verification run takes between a few seconds and 120 minutes on a PC with Pentium-processor.
REFERENCES Bryant. R.E. (1986): Graph-based algorithms for boolean function manipulation.IEEE In : Transactions on Computers, C-35(8), 677-691. Burch, J.R., E.M.Clarke, D.E.Long, K.L.McMillan and D.L.Dill (1994). Symbolic Model Checking for Sequential Circuit Verification. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, Vol. 13, No.4, 401-424. Emerson, E.A.(1990). Temporal and Modal Logic In: Handbook of Theoretical Computer Science, Chapter 16, pp.996-1072. Elsevier Science Publisher, Oxford. Htilzlein, M. , Th. Filkom, P. Warkentin and M. WeiB (1998). Eine Veriftkationskomponente fUr HiGraph In: GMA-Kongress '98. VDI-Berichte 1397, pp. 281-290. VDI-Verlag, Dusseldorf. Rath, G. (1997): Zustandsgraphen - eine neue, aussichtsreiche Progranuniermethode. GMA-Bericht, 31.
1518
Copyright 1999 IFAC
ISBN: 0 08 043248 4