Modelling and Formal Verification of Timing Aspects in Large PLC Programs

One of the main obstacle that prevents model checking from being widely used in industrial control systems is the complexity of building formal models out of PLC programs, especially when timing aspects need to be integrated. This paper brings an answer to this obstacle by proposing a methodology to model and verify timing aspects of PLC programs. Two approaches are proposed to allow the users to balance the trade-off between the complexity of the model, i.e. its number of states, and the set of specifications possible to be verified. A tool supporting the methodology which allows to produce models for different model checkers directly from PLC programs has been developed. Verification of timing aspects for real-life PLC programs are presented in this paper using NuSMV.


INTRODUCTION
CERN, the European Organization for Nuclear Research, relies on a large number of PLC (Programmable Logic Controller) applications to operate its different particle accelerators.These applications are critical to CERN operation, thus guaranteeing that their behaviour conform to their specifications is of highest importance.Formal verification, and especially model checking, appears to be a promising technique to ensure that PLC programs meet their initial specifications.However, this technique is not widely used in industry due to the complexity of building the formal model of a PLC program: building such formal model requires an in-depth knowledge of the system to model (hardware and software) as well as the underlying model checker.Moreover, when timing aspect needs to be taken into account, i.e.PLC time and timers, the modelization task becomes even more complex as the resulting models, without a refined representation, are usually too large in terms of state space to be handled by model checkers.
In this paper, we are proposing a methodology to model PLC time and timers.The methodology is integrated into the generic framework described in Darvas et al. (2013) allowing to generate formal models automatically out of PLC programs.Two approaches are proposed in order to take timing aspects into consideration: realistic and abstract modelization.The realistic approach represents the behaviour of timers and the internal representation of time in PLCs with high fidelity.Such modelling allows to verify time-related properties to ensure that a given action will (or will not) be performed after or before a given delay (e.g.PLC output set to true 500 ms after a given input has been set to true).While this modelization is powerful in terms of expressivity, it may produce models that are too big to be handled by model checkers and thus, leads to the second modelling approach.The abstract approach omits the modelization of time itself and gives a non-deterministic model of timers.Compared to the first approach, this one drastically reduces the state space of the generated model and therefore allows to verify large PLC programs while still providing the ability to verify some time-related specifications.The properties that can be verified by applying this second modelization are for example liveness properties (e.g.PLC output will be set to true after its input is set to false).The requirements verified using the abstract time modelization remain valid on the realistic model, as the realistic approach is a refinement of the abstract one.Finally, a tool implementing the two types of time modelization and generating formal models for NuSMV (Cimatti et al. (2002)), BIP (Basu et al. (2011)) and UPPAAL (Amnell et al. (2001)) has been developed and applied to CERN's control systems.

Related Work
Although modelling timing behaviour of PLC programs has previously been studied in the literature, none of them provides a general methodology which allows automatically generating formal models including timing aspects, and performing verification on these models at the same time.Moreover, all approaches found in the literature are bounded to a specific model checker and thus prevent to take advantages of the different types of model checkers.
Indeed, Mader and Wupper (1999) or Perin and Faure (2013) proposes an approach for modelling PLC timers using timed automaton models, but does not present verification results.As time is considered as a linear and monotonic function, the generated models would have a huge state space, making verification impossible if this approach would be applied to large systems, as the systems developed at CERN.Similarly, Mokadem et al. (2010) presents a case study where a global model for a timed multitask PLC program is created for verification purposes.This approach is similar to the one proposed by Mader and Wupper (1999) but verification is performed with UPPAAL using clocks and therefore with monotonic time representation.In Wang et al. (2013), several aspects of PLC control systems including timers are modelled, using the component-based BIP framework.In this case, they assume fixed PLC cycle length which is a big constrain, and timer models are not precise enough compare to real PLC timers.In addition, verification results are not presented.
The rest of the paper is structured as follows: Section 2 introduces the notion of time and timers in PLCs.Section 3 gives an overview of the proposed methodology which allows to generate formal models for various model checkers out of PLC programs.Section 4 presents in detail the two proposed ways to model timing aspects of PLC programs, along with a case study applying the modelization.In addition, this section demonstrates formally that a realistic time modelization is a refinement of its abstraction.Finally, Section 5 analyses the two approaches by highlighting their advantages and disadvantages, and concludes the paper.

TIMED PLC CONTROL SYSTEMS
This section gives an overview of PLC control systems, with a focus on timing aspects.In addition, a case study is presented which will be used throughout the remaining sections to illustrate the modelization approach proposed in this paper.

Timing behaviour of PLCs
A PLC is an industrial computer which performs a synchronous and cyclic process called scan cycle, consisting of the following main steps: (1) reading the input values to the memory, (2) interpreting and executing the program logic using the read data, and finally (3) writing the computed output values to the real outputs.
In standard PLCs, i.e. non-safety PLCs, the cycle time is not fixed, but there is an upper limit enforced by a watchdog module.If the PLC cycle time is bigger than this upper limit, e.g.due to an infinite loop in the PLC program, the PLC executes a special part of the program responsible for handling timing errors.By contrast, safety PLCs have a fixed cycle time.
Timing operations, such as timers, are defined by IEC 61131 and can be considered as a function block that delays a signal or produces a pulse.Different types of timers can be found in PLCs, one of the most common timers is TON (Timer On-delay) (see Fig. 1).This timer has 2 inputs variables: IN and PT.IN is a Boolean input signal and PT is the delay time.The timer has 2 outputs: Q and ET.Q is the Boolean output variable, its value will be true after the predefined delay (PT ) when IN performs a rising edge, and it will be false if IN is false.ET is the elapsed time, its value is increased until PT, starting when a rising edge occurred on IN.PLC timers use a specific data type for timing operations called TIME.This data type is defined by IEC 61131 as a finite variable which states that "The range of values and precision of representation in these data types is implementation-dependent". Representing time by a finite variable leads to a non-monotonic time representation as the variable can overflow (c.f. the upper part of Fig. 3).For example, in Siemens S7 PLCs, the TIME data type is defined as a signed 32-bit integer with the same precision of 1 ms (see Siemens (1998)), having an upper limit of approximately +24 days and a lower limit of −24 days.However, in Schneider and Beckhoff PLCs, the TIME data type is an unsigned 32-bit integer with a precision of 1 ms.In this paper, we consider the signed time interpretation as defined in Siemens PLCs.

Case study
In the context of this paper, the industrial control system framework, developed and used by CERN, called UNICOS (Blanco et al. (2011)) is taken as a case study.UNICOS provides a library of base objects representing common industrial control instrumentation (e.g.sensor, actuators, subsystems).These objects are represented as function blocks in the PLC code, using the ST (Structured Text) language, which can call different functions, function blocks on the PLC.Currently UNICOS is implemented for standard PLCs, i.e. in which the cycle time is not fixed and depends on the overall application.
In this paper, we focus on the OnOff object provided by the UNICOS library for Siemens PLCs.This object is used to represent a physical equipment, as actuators driven by digital signals (e.g. valves, heaters, motors).With 60 input variables (of which 13 are parameters), 62 output variables, 600 lines of ST code, and 3 timer instances, the OnOff object is representative of other UNICOS objects in terms of size and complexity.

MODELLING PLC PROGRAMS
This section gives a brief overview of the general methodology for modelling PLC programs without considering timing aspects.For more details, readers should refer to Darvas et al. (2013).Also, the applied reductions and abstractions are introduced.

Methodology
This methodology aims to generate formal models out of ST code.It provides an intermediate model and a set of transformation rules to produce the input models for different verification tools from the "non-formal world" of control systems (see Fig. 2).This "non-formal world" is basically composed by the ST program and environmental factors related to the execution platform (for example the PLC scan cycle).

Non-formalwworld
Intermediatewmodel Formalwmodels Verification Our automata-based formalism is strong enough to model all relevant features of a PLC control system.The semantics of the intermediate model is similar to the network of timed automata formalism defined in Behrmann et al. (2004) but without explicit logical clock representation.In addition, an automatic generation tool has been developed supporting this methodology, which allows to generate models for NuSMV, UPPAAL and BIP out of ST code.

Reduction and abstraction techniques
Modelling PLC programs for verification purposes implies the creation of models with huge state spaces, as it happens for any other real-life software.If these are timed systems, then modelling of time is required, so the problem becomes even bigger.Although the main goal of this paper is not to present the abstraction techniques applied on the generated models in details, we introduce them as they are needed to understand our experimental results on timed PLC programs.These techniques are included in the methodology and applied automatically to the intermediate model, therefore all the generated final models benefit from them.The main abstraction and reduction techniques applied: The reader find detailed information about the applied techniques in Darvas et al. (2014).

MODELLING TIMING ASPECTS OF PLC PROGRAMS
This section focuses on the modelling aspects of PLC time and timers extending the described methodology in Section 3. The TON timer, presented in Section 2, is used to illustrate the two proposed approaches to model timing aspects, but the same methodology can be applied to any other PLC timer block.In the proposed methodology extension, a PLC timer is represented by a separated automaton which is synchronized with the main program.Modelling PLC timers also implies to model the TIME data type.However, as mentioned previously, timed models usually contain a huge state space, which cannot be handled by model checkers.Based on this observation, two different approaches are proposed in this section.The first is a realistic timer representation, which is close to the reality, enabling precise modelling and verification.The second approach proposes an abstract time representation, which is less accurate, but drastically reduces the state space of the model.
Both approaches are analyzed hereafter paying attention to time and timer representation, property specification, and experimental results.In addition, we are presenting the proof that the abstract approach simulates the realistic one, thus guaranteeing that any property verified by the abstract approach also holds in the realistic one, even if is much simpler.

Realistic approach
This first approach presents a realistic model of a TON timer and the time handling.This approach allows to specify properties with explicit time in it.Having this realistic representation of the timer implies that time needs also to be modelled realistically.

Time representation
Three main characteristics are considered to model time for this approach: 19th IFAC World Congress Cape Town, South Africa.August 24-29, 2014 (1) Time is modelled as a finite variable: it represents with high fidelity the TIME data type in a PLC.However, instead of having a signed 32-bits integer variable (like in Siemens PLCs), a 16-bits variable is used to represent this data type.This range reduction is possible as the behaviour of a PLC is cyclic and the cycle time, the delays of the timers, and the delays in the requirements are much smaller than the range of this 16 bit variable.The accuracy of this variable is 1 ms, as it is in real PLCs.Because of this time representation, overflow of time has to be considered when the timer is modelled, also when the requirement to be checked is expressed (e.g., the current time can be smaller for a later event, see Fig. 3).
(2) Time is incremented by adding the cycle time: In this representation, time is not incremented by individual units of time.It is instead incremented by the duration of the last PLC cycle at the end of it.This assumption obviously simplifies the global model and there is not any loss of accuracy when comparing with the real implementation in a PLC, considering that the timers are called at most once in each PLC cycle, which holds for our real cases.
(3) Cycle time is chosen non-deterministically: in order to represent standard PLC with a varying cycle time, a random value is generated at the end of each cycle to represent this.The selected random values are between 5 ms and 100 ms, which is a valid assumption based on the PLC systems at CERN.

Timer representation
Given this finite time representation, the behaviour of the timer is represented as it is shown on the ST code (see Fig. 4).In this code, the input variables are IN and PT, and the output variables are Q and ET.The variable ctime represents the current time and it is modelled as previously explained.In addition, two variables are added: running and start, where running is a Boolean variable representing when the timer is working after a rising edge on IN and start contains the value of ctime when IN has a rising edge.
By applying the extended methodology, the corresponding automaton of the TON ST code was produced and the equivalent state machine is shown in Fig. 5. (Note that the assignments of ET are omitted from the state machine to simplify the figure.)This state machine contains 3 states corresponding to the 3 original states of the TON: NR (not running; running=false, Q=false), R (running; running=true, Q=false) and TO (timeout; running=true, Q=true).The transitions in the state machine (labelled as t 1 , t 2 , t 3 , t 4 ) correspond to the conditional statements in the ST code.Only one transition can happen in this state machine for every call of the timer.Therefore the timer cannot go from state NR to state TO with one function call, which is valid if we assume that delays are always greater than zero (PT > 0).According to the specification of the Siemens TON implementation (Siemens (1998)), the parameter PT should be positive.
The potential state space (PSS) size of this timer representation is 3.38 • 10 16 and its reachable state space (RSS) is 5.91 • 10 15 without counting the variable ctime (as it is a global variable used by all the timers). [¬in] [¬in] [in ∧ P] [in] Property specification Using the methodology and the developed tool, input models for NuSMV are automatically generated.The experimental results presented here are produced using this model checker.NuSMV provides CTL (Computational Tree Logic) and LTL (Linear Temporal Logic) for property specification.Our goal is to verify properties with explicit time in it, like "if C 1 is true, after t m time C 2 will be true, if C 1 remained true" (where C 1 and C 2 are Boolean expressions, C 1 contains input variables and parameters and C 2 contains output variables).
CTL and LTL do not provide this expressiveness, for this reason a monitor or observer automata is added to the model.The goal of the monitor is to check C 1 , and if it is true for at least t m time, the monitor output value Mout is set to true.By using such monitor, the requirement is simplified as "if Mout is true, then C 2 should be true".This requirement can be formalized easily in CTL: AG(Mout → C 2 ).An example for this monitor usage can be seen on Fig. 6.As the computed values are assigned to the real outputs of the PLC only at the end of the PLC cycle, the requirements should be checked only at this point.The general CTL expression extended with it is the following: AG(PLC END → (Mout → C 2 )), where PLC END is true, iff the execution is at the end of a PLC scan cycle.The behaviour of this monitor is similar to the TON timer, but it is independent of the rest of the program logic, therefore Mout will be true after t m time, if C 1 is true and it can be used to verify if outn holds the property.It has to be noticed, that it is not enough to save a "timestamp" t C1 when C 1 is true, and formalize the requirement as AG((ctime ≥ t C1 + t m ) → C 2 ), because the ctime variable is a finite integer, thus it can overflow, as it is illustrated by Fig. 3. Experimental results This approach has been applied to the UNICOS framework.In particular, the experiments here have been applied to the OnOff object from the UNICOS library.Table 1 presents different state spaces depending on which abstraction and reductions techniques are applied.On the OnOff model, we made our experiments with a requirement of the previously introduced structure: "if C 1 is true, after t m units of time C 2 will be true, if C 1 remained true".
To be able to verify this property, the original model was shrink from a PSS of 1.6 • 10 218 states to a PSS of 1.1 • 10 36 as can be seen in Table 1.In order to do so, reductions, fixed parameters (focusing on a specific scenario), and COI technique (which eliminated 2 timers out of 3) have been applied.As it was mentioned before, time values were modelled as 16-bits variables instead of 32-bits.
Table 2 presents verification results for the OnOff model after applying all the previously mentioned reduction techniques.We checked the introduced requirement with three different configurations in terms of timer delay (t p ) and monitor delay (t m ).The first uses t p = t m = 10 s values, which means the parameter t p of OnOff and the delay parameter t m of the monitor were both 10 s.In this case, the result is true which is given by NuSMV in 11.4 s.The other two configurations use monitor delay times smaller than the parameter t p , therefore the output is expected too early, thus the result should be false.As it can be seen in Table 2, in both cases the verification time was around 5-20 s, but the generation of the counterexample (C.ex.gen.time) took significantly more time.In the case when we used t m = 9 s, the counterexample was longer (3 876 steps), and its generation time was around 15 times bigger than when we used t m = 1 s.Notice that these verification results can have a timing error not bigger than the maximal cycle time, 100 ms in this case, because the current time is incremented in quanta.

Abstract approach
As it was shown in the previous experimental results, the models created by realistic approach have a big state space even if only one TON is modelled.If this approach is applied to larger models than the UNICOS OnOff object probably verification would not be even possible.For that reason, we propose a second approach based on a data abstraction of the first approach.
Time representation In this case, time is not represented explicitly in the model, the variable ctime representing the current time is not maintained.Therefore properties with explicit time cannot be validated.

Timer representation
This timer representation approach consists in a non-deterministic model produced as an abstraction of the realistic approach.The corresponding state machine is presented in Figure 7.
Similarly to the realistic model, this model has three possible internal state: NR (not running), R (running) and TO (timed out).If the input IN is true, the TON will start to run (goes to state R).After that, the TON can stay in the state R or go to TO non-deterministically, which means, we do not know when the timer will stop.However, by adding a fairness constraint to the model, it is ensured that the timer cannot stay in state R for infinite time.In one PLC cycle only one transition can be fired, i.e., the timer cannot go from state NR to state TO with one call.This corresponds to the previously introduced PT > 0 constraint.Figure 8 shows the timing diagram of the abstract approach compared with the realistic one.The size of the PSS and RSS for this model is 6 comprising the Boolean input variable, reducing significantly the size of the realistic approach but introducing some limitations of the property specification.
This representation can result false positives, meaning that verification tools can give spurious counterexample that cannot occur in reality.However false negatives can never occur, therefore if a property holds in the abstract model, it holds in the real system.

Property specification
Obviously, this abstract model implies certain limitations in the specification properties.Explicit delay times cannot be expressed in the requirement, but safety or liveness properties can be expressed.
Experimental results This approach has also been applied to the OnOff object from the UNICOS library.For Experiment 1, we used the same reduction techniques and the same fixed parameters as for the realistic approach.The PSS of the OnOff model became 5.5 • 1024 (instead of 1.1 • 10 36 ).Representing the requirement checked on the realistic model is not possible in this approach as the time is not counted explicitly.Instead, we can check the following liveness property: "if C 1 is sometime true and remains true forever, eventually C 2 will be true".The equivalent LTL property is: , where PLC END represent the end of a PLC cycle.In this case, no monitor is needed.
We made two other experiments on the model with abstract time representation (Exp.2, 3).In these cases, no parameters were fixed and all the three timers had effect on the requirement.The requirement 2 was a simple safety requirement in CTL (AG(C 3 → C 4 )), while requirement 3 was a bit more complex: AG(C 5 → AF (C 6 )).Our experiments (c.f.Table 4) showed that these requirements can be checked using the abstract time representation, even without fixing any parameters.With the realistic time representation, the state space would be too large to be verified using NuSMV.

Refinement between the two approaches
We can verify that the realistic approach indeed refines the abstract approach.Using this proof, we are able to guarantee that requirements verified on the abstract model -where verification is easier -also hold on the realistic model -where automatic verification would be harder and more time consuming.However, the false result on the abstract model does not imply false result on the realistic model.Using more abstract models for verification purposes and lifting results to realistic models is a well known technique (Clarke et al. (1999); Loiseaux et al. (1995)) and we apply it to the PLC domain.Specifically to PLC timer models and we perform a proof in a similar fashion as the refinement proofs described in Blech and Grégoire (2011).
The proof is done by first establishing a simulation relation S between realistic (Fig. 5) and abstract automaton (Fig. 7) that relates the states of the different automata with each other such that only the following holds: S(NR realistic , NR abstract ) S(R realistic , R abstract ) S(TO realistic , TO abstract ) Furthermore, the simulation relation ensures that Q has the same value in all states.In order to finish the proof, we show that: • The initial states are in the simulation relation: NR realistic and NR abstract are in the simulation relation and the value of Q is the same, false.Based on the definition of the simulation relation, safety properties making use of the atomic elements -like conditions on the used variables Q and in -that are preserved in S are also preserved between abstract and realistic model.However, the abstract model can impose false positives, i.e. the given abstract counterexamples can never occur in the in the real system.

ANALYSIS AND CONCLUSIONS
This paper proposes two different approaches for modelling time and timers in PLC-based control systems.Experimental results applied to a real PLC program developed at CERN and an analysis of both approaches have been presented.While the first approach provides a realistic model of a PLC time and timers, the second provides an abstract representation of them.
The first approach represents with high fidelity the TON implementation on a real PLC.This TON representation implies also to model time.The accuracy of the model is high enough, using as unit of logic time 1 ms for timers (as in a real PLC).In terms of specification, this approach allows to express properties with explicit time by using CTL and a monitor.However the resulting state space is very big.Even if some abstraction techniques are applied verification time can become very large and in some cases it may not be handled by model checkers.
The second approach solves the problem of state space explosion by proposing a simplified model of the first approach.The resulting model has a non-deterministic nature, so the accuracy is reduced and it can produce false positives.In terms of specification, it is not possible to verify properties explicit time, but it can verify properties that guarantee that the timer gives a response (liveness property) although we can not verify when the response will be given.
Table 5 summarizes the main differences of both approaches.The first approach is thus needed when properties with explicit time have to be verified but there is a higher chance of having a state explosion problem.The second approach is suitable for timed properties without explicit time (for example certain before/after properties) and for non-timed properties (for example safety or liveness properties), where the variables linked to the property are affected by a timer in the real system and this timer cannot be eliminated by using abstraction techniques, such as cone of influence.Although, false positive results can occur using this approach, false negative can never occur.
Both approaches are supported by the suggested general methodology for verifying PLC programs.A tool is also provided for the automatic generation of formal models for different verification tools.
Future plans comprise the integration of the tool and methodology in the UNICOS development process.In addition, extending and optimizing the abstraction techniques and the proof of the transformation to guarantee its correctness are ongoing work.

Fig. 2 .
Fig. 2. Overview of generic methodology producing formal models out of ST code.This intermediate model based on automata simplifies the transformation rules to any formal model used by a model checker, whose modelling language is close to an automata-based formalism.It allows to easily add new model checkers to the methodology and verify the same model with different verification tools, thus benefiting from the different advantages of the verification tools in terms of verification performance, simulation and expressiveness of properties specification.

[Fig. 5 .
Fig. 5. State machine of the realistic TON representation

Fig. 6 .
Fig. 6.Verification configuration for OnOff model extended with monitor

t
Fig. 7. State machine of the abstract TON representation

Fig. 8 .
Fig. 8. Timing diagram of TON modelled using different approaches

•
Clarke et al. (1999)eductions are used to simplify the generated automata by taking advantage of the characteristics of the PLC's execution model.For example, variable assignments on succeeding transitions can be merged if they are not affecting each other, as the value of the variables are not checked during the execution of the PLC cycle but only at the end.More than 20 rules have been defined to simplify and reduce the model.•Whentheproperty to verify is provided, we apply the Cone of Influence (COI) reduction (c.f.Clarke et al. (1999)), which consists in removing all variables that do not affect the property.As it is depending on the requirement to be checked, its impact on the size of the state space highly varies, but for many examples, we can observe a large state space reduction.• In some cases, predicate abstraction can be also applied to PLC applications.It consists in substituting non-Boolean variables by Boolean-valued functions.

Table 1 .
State space of the OnOff model with realistic time representation

Table 2 .
Verification time on OnOff model with realistic time representation

Table 3
presents different state spaces depending on which reductions techniques are applied and what requirement was verified.Table 4 shows the measured run times.

Table 3 .
State space of the OnOff model with abstract time representation

•
Each pair of realistic and abstract model state transitions with a corresponding condition -regarding the value of in -from possible states in the simulation relation S lead to a pair of states for which S holds again.Most cases are trivial expect: the transition of the [in]-guarded transition in the abstract model in the (TO realistic , TO abstract ) state pair has two corresponding transitions in the realistic model since we do not regard the value of P in the abstract model.Due to the fairness constraint in the abstract model, its state cannot be R abstract for infinite time.However, this is also true for the corresponding NR realistic state of the realistic model if it is called sufficiently often 1 , because the delay time PT is finite.

Table 5 .
Overview of the timer representation approaches