You are on page 1of 6

What is the method in applying formal methods to PLC applications?

Angelika Mader and Hanno Wupper


Computing Science Institute, University Nijmegen, The Netherlands, email: mader wupper @cs.kun.nl

Abstract
The question we investigate is how to obtain PLC applications with confidence in their proper functioning. Especially,
we are interested in the contribution that formal methods can provide for their development. Our maxim is that the
place of a particular formal method in the total picture of system development should be made very clear. Developers
and customers ought to understand very well what they can rely on or not, and we see our task in trying to make this
explicit. Therefore, for us the answer to the question above leads to the following questions: Which parts of the system
can be treated formally? What formal methods and tools can be applied? What does their successful application tell
(or does not) about the proper functioning of the whole system?

Keywords: formal methods, PLC, embedded systems, verification, testing, specification

1 I NTRODUCTION make this explicit. Therefore, for us the answer to the
question above leads to the following questions:
The question we investigate is how to get PLC applica-
tions with confidence in their proper functioning. Es- 

Which steps in the development process can be
pecially, we are interested in the potential contribution supported by formal methods?
from formal methods for their development.
They way we approach this question is via a 

What formal methods and tools can be applied?
schematic presentation of an overall picture of PLC ap-
plications (see figure 1). We assume that this schema in


What does their successful application tell (or not)
some form or other is familiar to everyone working in about the proper functioning of the whole system?
the field of PLC applications. Making it explicit helps
Although many PLC-specific issues are addressed,
us to classify our own and others’ existing work, evalu-
our results are not confined to PLCs. Whenever pos-
ating its relevance, and identifying new research ques-
sible, we try to present them in such a general way that
tions that could lead to useful contributions.
they can also be used for the development of other em-
PLC applications typically consist of a variety of dif-
bedded software.
ferent parts: an environment that has to be controlled
The paper is structured as follows: in section 2 we
(e.g. a plant), a PLC, a PLC program, connections be-
sketch a schema of PLC applications, i.e. the compo-
tween a PLC and its environment, connections between
nents of PLC applications, their different abstraction
a PLC and a PC, etc. During its design a PLC applica-
levels and the interconnections between them. Refer-
tion is influenced by the programming environment on
ring to this schema, we describe in section 3 formal
a PC, a compiler, etc. A PLC application only works
methods that support development and validation of
correctly if all its parts and their interactions work cor-
PLC applications.
rect.
A methodical development of PLC applications can
be supported by formal methods such as program syn- 2 A SCHEMATIC PRESENTATION OF PLC APPLI -
thesis, a posteriori verification, formal testing, specifi- CATIONS
cation and program design methods. All of them have In this section we sketch an overall schema of PLC ap-
their limits, which are e.g. the complexity of the sys- plications (see figure 1). Using this schema we moti-
tem, the simplification of reality, and the inherent re- vate and discuss different abstraction levels on which
striction to small segments of reality. However, we are PLC applications can be treated, and their interconnec-
optimistic about the usefulness of formal methods: we tions. Each formal method applies to a fragment of the
strongly believe that it is the only way to get reliable whole system at a certain level of abstraction. The re-
applications. Our maxim is that the place of a partic- sult obtained using a particular method therefore also
ular formal method in the total picture of system de- has to be interpreted relative to the relevant fragment
velopment should be made very clear. Developers and and abstraction level.
customers ought to understand very well what they can
rely on and what not, and we see it as our task to try to System requirement: Specification of the goal.


supported by a NWO postdoc grant and the EC LTR project VHS A specification of the overall goal of a system or at least
(project nr. 26270) of its relevant properties is a prerequisite to make any

derive them are a research topic. meets the overall goal.g. satisfies it is acceptable as a controller in the given envi- spect to a given overall goal. the PLC standard and the control specification level: e. aircraft.t.  It can be used for the construction of meaningful essary to establish that it. Embedded system specifications. such specifi-  It provides guidance for the derivation of the con- cations are hardly ever given.II Angelika Mader and Hanno Wupper system requirement Specification of the goal embedded system specification specification specifications of the environment of the control high level plant diagram structure (e. A specification should.. Correctness of one component is only meaning. . In practice. such a control. as simply as possible. and an environment to be the environment has to be controlled. together with the specified tests. On the most abstract level ronment. a computer A specification of a controller should only state how on which the program runs. ment of the program. Methods that allow to trol specification. Ideally.r. An embedded system consists of a program. anything about PLCs or PLC languages in particular. in order to be readable to a customer or at least to a domain expert. or a whole fac.g. should be sufficiently general so that any machine that ful with respect to the other components and with re. On the other hand it should be clear reasons: and simple. given a specification of an specification and correctness of the control speci- overall goal and a specification of the environment a fication w. P/I diagram) PLC standard PLC program description low level structure description construction plans switching diagram bits and bytes environment PLC reality PLC program Figure 1: Abstraction levels of PLC applications useful statement about its correctness. if we want to apply an environment specification is useful for the following formal methods. state only those assumptions about the environment that are nec. Specification of the control. The availability of such a control specification this means that a specification theorem must hold of the is useful for the following reasons: following form:  It allows to divide the correctness proof for the  S PECenvironment  S PECcontrol  S PECoverall goal PLC program into two parts: correctness of the  Theorem describes a correctness question on the program w.  It is a prerequisite for systematic development and can provide valuable guidance during the develop- Specification of the environment. It tory). The availability of such specification is formal and exact. vehicle. It should not state controlled (a machine.t. control is only correct  if it satisfies a specification that makes implication true.r.  It can be used for purposes of simulation. the environment and the overall goal.

the classification below is not complete. This has led to a sophisticated culture of If the PLC languages of the standard IEC 1131-3 [5] are experimentation in the natural sciences.and firmware that verification is a formal model of a real system. That is why correctness proofs. Up to now. Deduction in its most precise form. abstractions on which they were based. Certainly. It should be the most important part of the PLC ory attempts to help to construct meaningful tests and standard. Only aspects of the reality that are taken into account in the model can The physical program in the PLC is some electro- be verified. In computer to have the same semantics independent of the model science systems are mainly tested. We must there. Therefore. it must port insight. tion. and nuts of specific geometry. In principle. Of course. assume that the PLC manufacturer provides compilers Induction. This process is called verification. hierarchical and compositional ap- Lowest level PLC. each formal model is only an abstraction of a real system. from the descriptions of the lowest level The system in which the PLC with its program is em- machine program. tion 3. The corresponding mathematical model is the corresponding long sequence of zeros and Proving correctness for arbitrary programs is very ones. If a phenomenon can be observed again and that correctly translate the higher level languages to ma- again. Within the framework of our research we chical decomposition. Of course. Rather than reasoning about a physical plant with its pipes. A pre- A PLC is a huge and complex electro-magnetic circuit condition for such approaches is a structured formal de- that forms a programmable computer. Again.3. have been connected in the right way. helps us to know for sure that of our results. With respect to PLCs fore base our research on as few assumptions as possi. causalities. to provide insight for complex be clear that the actual bits in the actual PLC are a systems requires also a notion of hierarchy. This imple- 3. we will mention a method for control design that mentation will. Be. bolts. and. we distinguish between four PLC program. In sec- means of suitable formalisms. this is far too complex to be vironment and its (relevant) behaviour can be modelled feasible. in the ideal case. In order to deal with the complexity. something is the case. the lowest level PLC and the envi. 3 F ORMAL METHODS CONTRIBUTING TO RELI - ABLE PLC APPLICATIONS . it must be clear that any ac. interpretations of their results. In section correct implementation of that program. ing computer scientists. ble about a well-chosen fragment of the PLC languages.2. together with an scription of a program that. tual PLC is an implementation of this standard. of the actual machines with respect to such schemas to Before getting to the concrete formal approaches we other engineers and believe that the appropriate pipes. the future . is obtained operating system. proaches can be applied (“divide et impera”). we must leave the verification moreover. there may be other useful classifications. because of its complexity. verification can help to eliminate magnetic representation of a large number of bits in only certain classes of errors. be different for different for one part is based on insight combined with a hierar- PLC models. applications it will be discussed in section 3.unless one has overlooked some essential PLC standard. a chemical plant etc. of higher-level formalisms. agram” that abstracts from irrelevant information. Testing the- needed. grams this would be a text in one or more of the stan- Some of the PLC languages have been designed to sup- dard PLC programming languages. In general. or ronment it should be provable that the overall specifi. applications in the context of our schema of figure 1. we might In this section we try to put formal approaches for PLC prefer something like a “piping and instrumentation di.1 we treat verification approaches for PLC appli- . In practice. Schema of environment. The knowledge we obtain from such for- Low level structure description. one may conclude that it will also observable in chine code. one single formal specification of all PLCs is is a rather poor application of induction. At a very basic level. by the way. Both can be modelled exactly by by a structured program development process. Therefore. in system development we rely in Rather than reasoning about bits we can reason in terms a combination of all of them. logical reasoning and make these assumptions explicit as a “parameter” and mathematical proofs. the PLC’s memory. at higher levels have to be used. Nat- is a correct implementation of the standard. etc. supported by model checkers and proof tools. are ap- within the framework of our research we assume that plied. mal methods can never be more meaningful than the Lowest level machine program. urally. Typically. difficult. more abstract formal descriptions exactly. it does not exist. which in some cases of PLC. ways to get confidence in the correct behaviour of a system.. A basis for the PLC manufacturer provides hard. Environment. In the case of PLC pro- Insight is based on the simplicity of a representation. bedded can be complex mechano-electrical machine. All relevant properties of the en- cation holds.What is the method in applying formal methods to PLC applications? III High level structure description. want to consider the principal possibilities for valida- bolts.

the following questions. ferent models during one verification process. system. An easy example is that an untimed property cation. The question that [2]. tion. with respect to the system specification. but some properties that seem to be relevant class and property to be verified. Its answer provides a basis to make use of dif- cation still leaves the correctness question   of the spec. the program. There. used several times only needs to be verified once. [9]). Moreover. arises is about the relation between different mod- Having verified a program against the control specifi.IV Angelika Mader and Hanno Wupper cations. mantics? For PLC languages semantics are defined in the standard IEC 1131-3 [5]. verification of Petri-nets. We distinguish three levels of program verification:  Second. If this property does not hold this Most work done in formal methods for PLC applica.1 Program verification. A special case is. If a semantics of a high the overall goal. check “specification-independent” properties as e. process algebras etc. thing meaningful without having to believe in the cor.e. fragments whose semantics are At a certain point when the model designer be- unambiguous. etc. Here. Furthermore. In most cases with a model of the controlled system are shown to sat- we believe that the modelled behaviour coincides with isfy the overall goal or relevant properties implied by the real behaviour in the reality. unwanted history. in [1]. we want to emphasize the relations of verification ap. cations and allow to find suitable models for each sidered. it is necessary for and intuition. sibly be too large. and do derivation of a certain model or class of models raises the compiler and hardware behave according to the se. Consequently. In such cases it is essential to should be aware of that it may be difficult to obtain a be conscious of what one believes and what not. Where proof of a complete specification by means of model system development is based on belief. a property that is verified is the absence of 3. verification of a program together with its environment such as described by timed or hybrid automata. Therefore. It is static program analysis. of the languages. forbidden control structures in SFCs. to rect implementation of the PLC languages. Here. a model of the program together the behaviour of the program is derived. can tell us some. In ification open as given by theorem in section 2. ture description and its relations to the embedded sys. However. The most general case is verification of a program tem specification or the system requirement. one kind of errors. pilers. level description is defined there are two questions to For all these levels of verification the choice and answer: does the model match the semantics. grams is done in this class (see e. proaches with both. An example of this approach can be found in may not require a timed model. els. model checking is often for example. i. Advantage here is that a function block Program verification is band on the high level struc.g. testing of PLC behaviour Most existing work about verification of PLC pro- mentioned earlier. together with its environment with respect to the system from a high level description of the program a model of specification. used like a debugger: the property checked describes mantics of the PLC languages is built into correct com. mentation of any “intended” specification. A survey can be a program with respect to the control specification. a program specification is not required given a property it would be best to use always explicitly. Typically.g. A further restriction is not to verify a whole program. In [7] we report on criteria that classify PLC appli- most cases not a complete program specification is con. are based on the belief that the correct se. such as the function blocks used by level. ware and compilers according to the semantics. useful to have different classes of models avail- In static program analysis errors such as unreachable able: a model needs not contain more information code. Correctness proofs for PLC programs. without being able to establish its truth by insight. In this Belief. On the other hand. Therefore. lieves that the model is correct the results of veri- ature the question whether the they match with the se. The goal of that . one induction or deduction. we simply believe that something is the case one should make sure that the properties checked case. but a detected error indicates that a program the most abstract model that allows for verifica- is not an implementation of any “reasonable” specifi. deriving a model is mainly based on experience biguous and incomplete. these semantics are to some extent am. are implied by the control specification. can be than the property to verify requires. in present examples the process of point of view. A discussion of this aspect can be found we trust in the manufacturers for having produced hard. on the other hand. Often. detected. from a formal  First of all. with help of a model checker. specification level and physical but only parts of it.g. as in static program analysis. e. are verified. in [3]. might be an indication that the program is not an imple- tions is done in the area of program verification. fication are interpreted with respect to the physical mantics is answered on basis of insight. there are many classes of useful models. For most models introduced in the liter. this should be checking: the number of properties to verify can pos- made explicit. The first verification attempts have program verification to restrict to the “safe” fragments mainly the function to correct errors in the model. and found in [9] and in the long version of [7]. There.

g.3 Program derivation. mation about the controlled system and the control is quirement. computer science. pins of chips are tested for being Testing is the only validation method that can be connected correctly. plications is. con. e. languages with complex features. of memory together with the new data on the in- put points. Also on a higher level. One example is a whole answer. used to find out whether a real. specifications. it is dangerous to test of the program and verification techniques can be used the whole system.2 Testing PLC applications. For several PLC applications. this context it is anyway questionable whether the models we use can capture the complexity of the  Finally. added. Starting point is a very general fication. i. where e. There are many possible applications of formal . In designing the program. The work of [4] introduces a method to generate PLC For an introduction to testing using formal methods see programs starting from a control specification in dura- e. which may be we need to be sure about the correctness of the program too strong initially. where input consists of the “old” state models clearer. etc. The goal is that in the end such a the- other possibility is reducing the object under test to the orem can be proved. ory state and new values on the output points. the coupling to the synchronous theory and tool put points provides certainly useful information. on theorem . insight in the sense discussed earlier. rectness question of theorem is open. Hence. There exists a tool [10] supporting this Testing the integrated embedded system (reality) process. Of course. PLC applications. ables are connected in the correct way to the hard- for synchronous models of PLC programs.g. In this context questions such as are the pro. However. input/output behaviour. the area of protocol testing much research is done with respect to testing of control structures. Testing that the internal vari- methods based testing of PLC applications. tool [10] also allows to generate timed automata models trol of chemical or nuclear plants. In transferred to PLC applications. and output consists of a new mem-  Originally. In this paper we have raised the question what the role of formal methods for increasing confidence in PLC ap-  Often it is useful to consider the input/output be. results from testing of software systems could be tion. operating system and programming languages. variables hardware addresses are used. also hardware testing may be useful for systems considered. Program derivation is a long investigated subject in fied only by testing methods. does the simulation cap. During the approximation process specification: does the program specification together the system requirement is weakened stepwise as infor- with an environment specification imply the system re.What is the method in applying formal methods to PLC applications? V work is to make the derivation process for PLC scan cycle. the un-  A typical application area for PLCs is process con. tion calculus. the mance testing. they have become almost as complex and functions. The 4 C ONCLUSION results obtained there could be useful for PLC ap- plications. satisfy the overall specification. hand.e. all arrows connecting to the lowest level in figure 1 can be justi. However. In this case (as with verification approaches) statement about the system requirement. To get such a theorem we use an PLC program and testing it against the program speci. Concerning the general   picture. still the cor- against the system requirement is known as confor. [11]. With this point of view interrupts. derstanding of the overall problem we obtained by for- trol. physical object (plant 3. In principle. In the context of PLCs we want to proaches are possible between the reality level on one mention two approaches. PLCs had a very simple architecture.  We suggested a method that is based on ture the relevant properties of the physical plant? An. mulating the hierarchy of theorems gives guidance in cesses activated in the right order? are relevant.g. It turned out that even methods: when not striving for a complete formal proof that the program implements the control specification. We applied the eral different testing disciplines could provide useful method in a PLC case study [8]. testing ap. ware. and each of the higher levels on the other hand. approximative method.g. or control) satisfies its specification. This approach introduces In [12] we investigated the design process of the new correctness questions. vironment by a simulation. as e. in ware addresses and furtheron to the input and out- [6]. we have given only a partial haviour of PLC programs. This is similar to boundary scan testing for hard- atively straightforward. This way of introducing information supports It seems to be the case that for PLC applications sev. To overcome this problem there are to show that program (model) and environment (model) (at least) two possible ways: one is to substitute the en. One difficulty of programming PLCs is due to the fact that for input and output 3. it is reasonable to investigate the as “usual” computers: they allow multi-tasking. cyclical or periodical program execu. machinery inclusive testing approaches should be rel. which eas- The authors are not aware of work done on formal ily leads to errors. the one of function blocks Meanwhile.

1998. proaches is ongoing work. In Proceedings of the to evaluate results gained by formal methods with re. ceedings of European Control Conference 1999 trary unstructured complexity (“spaghetti programs”). Detect. 1999. Roussel. A classification of PLC models and The necessity of formal descriptions is obvious for applications. It is also obvious that Design of a PLC control program for a batch making them explicit increases insight and the quality plant. Ralf Huuck.M Baeten and S. 2000. 2000. One reason is [9] O. ulation. Dierks.Uni- The authors want to thank Ed Brinksma for useful dis. Springer Verlag. In J. Controllers. Belgium. Part 3. volume 1664 of Lecture Notes in [1] A. September 18-19. System design as a 1998. Ger- many. Programming Languages. Tapken. Germany. 2000. Relating the structure Mixed Processes. Fähndrich. Dortmund. 4th International Conference on Automation of spect to the rest of the picture. [4] H. Programmable . Mader. Dortmund. pages 126–133. creative mathematical activity. Tretmans. However. and N. [3] Ed Brinksma. [5] International Electrotechnical Commission. Lecture Notes in Computer Science. In Proceedings of Tenth Inter- national Symposium on System Synthesis. Aiken. [12] H. M. J. Technical Report CSI-R9919. cussions. Su. Lesage. volume 1384 of Lecture Notes in Computer Science. E. Oldenburg. also necessary for the design process: a control design Gent. [2] Sébastien Bornot. Moby/PLC . Testing concurrent systems: A for- remarks. we claim that formal descriptions are only useful if they are simple enough. Bauer. Another validation of PLC programs: a survey. [6] Fernando Jiménez-Fraustro and Eric Rutten. we claim that they are on Discrete Event Systems. [10] J. Moreover. submitted for publica- of the control program. or other speci- fication approaches. 2000. but can be useful for well-structured problems. edi- tors. (ECC’99). Brinksma. we believe that the struc. volume 1382 of by the availability of tools supporting the method. Synthesising controllers from real- time specifications. 1999. pages 184–199.VHS case study 1. 1997. 18-19 September presented with more existing and possible formal ap. Lecture Notes in Computer Science. Judy Romijn and the referees for their critical [11] J. Mader. Utilizing static analysis for programmable logic controllers. and J.VI Angelika Mader and Hanno Wupper methods for validation not mentioned here. Formal that only then they go together with insight. Additionally. University of Nijmegen. these descriptions are implicit.DE/ moby/. tion. In Proced. and Ben Lukoschus. In formal method for industrial size systems is determined Proceedings of FASE’98. August 21-23. Yassine Lakhnech. 2000. and Z. CONCUR’99 – 10th Int. Hy- ture presented helps to find out which aspects of the brid simulation of IEC-61131 PLC programs us- whole picture are treated by a certain method and how ing Signal and Simulink. in control design.C. Springer-Verlag. can only be as good as the environment specification (environment description) is. Often. on other fragments of the whole picture. IEEE CS Press. 2000. verification and testing approaches 1993. 1999. M. Mader. [8] A. Verification is experimentation! In Proceedings of CONCUR 2000. J. H. we are convinced that the usefulness of any for Hierarchical Real-Time Automata. ADPM’00. pages 46–65. 2000. [7] A. 2000.Informatik. pages 326–329. dings of TACAS’98. Computer Science. mal approach.A Design Tool Finally. Rossi. synthesis. Wupper. IEC International Standard 1131-3. In Pro- reason is that the tools available cannot deal with arbi. Wupper and A. ing races in Relay Ladder programs. avail- ACKNOWLEDGMENT able at: http://theoretica. In ADPM 2000: 4th International Conference on Automa- tion of Mixed Processes: Hybrid Dynamic Sys- tems. Conference on Con- R EFERENCES currency Theory. Mauw. such as sim. Springer. In WODES 2000: 5th Workshop (formal) validation.