Automatic Verification of Event-Driven Control Programs: a CaseStudy

Peizun Liu, Guiming Luo, Mo Xia, and Maosong He

Abstract— Execution environment and temporal performanceare very important for modeling a real PLC system. They alsobecome two impediments when verifying with model checking.This paper presents a methodology for modeling a PLC systemincluding time and environment. In order to take into accountinteraction of PLC controller with execution environment,the proposed method extends the modeling method with anevent-driven mechanism. The heterogeneous environments areabstracted as concurrent entities and further formalized intostate graphs. A timed abstraction method is proposed to dealwith real-time features which specified as timer on delay (TON).We have validated our approach on a concrete case study, acontroller for steel plate transfer devices, and report on theresults obtained for this case study.

I. INTRODUCTION

PROGRAMMABLE Logic Controllers (PLCs) are

spreading to a wide range of control tasks in various

industries, from common applications such as manufacturing,

chemical process control to safety-critical systems like nu-

clear power plants. Formal property verification is assuming

growing importance as PLC designs grow in complexity and

traditional validation techniques struggle to keep pace. For-

mal methods introduce mathematical rigor in their analysis

of PLC designs thereby guaranteeing exhaustive state space

coverage.

Model checking, as an automatic technique for verifying

finite state systems, has become an important application

of verification in PLC domain [1], [2]. However, several

challenges prevent widespread adoption of model checking

in industrial systems. The main challenge in formal verifi-

cation is to keep up with the ever-growing complexity of

the systems we are faced with. A second challenge is the

temporal performance. Introducing the study of quantitative

properties related to time make this verification step harder,

because additional components must be added in the model,

for instance clocks, which increase the size of the model.

The third challenge is the increased interconnectedness of

systems. The behavior of many PLC applications depends

on communication with external environments like sensors,

actuators, or other software-controlled systems. Since these

external components often need to be taken into account in

the verification of the system, we face a much bigger system

Peizun Liu and Guiming Luo are with the School of Software, TsinghuaUniversity, Beijing, P.R.China (email: liupz09@mails.tsinghua.edu.cn andgluo@tsinghua.edu.cn).

Mo Xia is with Department of Computer Science, Tsinghua University,Beijing, P.R.China.

Maosong He is with CISDI, MCC, Chongqing, P.R.China.This work is supported by the Funds of NSFC 60973049, 60635020, and

TNList cross-discipline foundations.

than just a local one. This adds to the main complexity

challenge mentioned above.

A. Our Contribution

In this paper, we propose a method for modeling exter-

nal environments and temporal features together with the

PLC controllers. In particular, we consider an event based

modeling approach – event-driven model – for PLCs system

to simulate the interconnectedness with environments. We

also propose an effective distinct time abstraction method

to specifying temporal features. We exhibit the method on a

running example, a controller for traverse control system in a

manufacturing line of steel plate, and report our experiences

on verifying the specifications with the model checker SPIN

[3].

B. Related Work

During the past decade, a lot of effort is being spent

on improving modeling of the timed features. In this area,

published work was most devoted to the model of timed

automaton introduced by Alur and Dill [4]. In [5], Mader

and Wupper firstly specified as timed automaton the real-

time property of PLCs based on IL (Instruction Lists) lan-

guage. Sacha used the finite state time machine (FSTM),

an extension of Moore automata with time feature, to model

PLC systems and generate code automatically in [6] [7]. And

then the FSTM model can be translated to timed automata of

UPPAAL for verification [8]. Klein and Frey et al. developed

a signal interpreted petri net (SPIN) editor for PLCs. This tool

can generate PLC codes from SPIN model [9]. The notion

of time is introduced into SPIN by timed places. Each timed

place is associated with a minimal time constant, which is the

time span token in the place. Comparing to timed automata,

this kind of time extension is less expressive.

Precious works on modeling of execution environment of

PLC system is rare. In [10], the authors modeled execution

environment using the model checker UPPAAL, which mod-

eled the external environment and PLC controller as different

timed automatons. An individual automaton of event-driven

task was introduced to receive and response to the emission

of a message from environment, while in this paper we

integrated event-driven mechanism with the whole model of

TCS system. The idea of event-driven mechanism is popular

in many areas of computer science, including the formal

verification. The work of Lohmann et al. [11] investigated

the event-based method and cycle-driven method through

transformed SFC (Sequential Function Charts) into timed

automata. However, it did not present how to model the

249

Fourth International Workshop on Advanced Computational Intelligence Wuhan, Hubei, China; October 19-21, 2011

978-1-61284-375-9/11/$26.00 @2011 IEEE

execution environments but merely simply defined the events

as value changes of variables. The main difference of our

work with the precious researches lies in the integration

style of event-driven mechanism and the model. We model

each part of TCS involving the external environment and

controller as different processes, in the context of SPIN,

which interconnect through event-driven mechanism. We also

compare our approach with cycle − driven model and

experiment results show the promising performance.

C. Organization of this Paper

The rest of this article is structured as follows. The follow-

ing section presents some preliminary background necessary

to understand the topic in the later sections. Section III gives

more details about the TCS system, including the properties

to check. Section IV is the core of this paper, and presents

modeling principle with event-driven. The experimental re-

sults are reported in Section V. Section VI concludes the

paper and presents the future work.

II. PRELIMINARIES

This section describes basic notations and definitions nec-

essary for later sections. Readers are referred to [12], [13]

for more detail.

A. Programmable Logic Controllers

PLCs which composed by hardware and software are

special computers designed for industrial control domain.

The hardware of a PLC (Fig. 1) consists of a CPU based on a

dedicated microprocessor, a memory, input and output ports.

PLC programs are typically written in a special application

on a personal computer, and then downloaded to the PLC.

The program is stored either in battery-backed-up RAM or

some other non-volatile flash memory in the PLC.

When controlling a system, a PLC repeatedly executes

scanning cycles. It continuously reads inputs and determines

new outputs by inputs and previous outputs, according to

its programmed logic. One scanning cycle consists of three

steps:

• scanning values from input ports, and

• executing the programmed logic, and

• writing results to output ports.

There exist many distinctive programming languages for

PLCs because of differences of manufacturers or appli-

cations domain. To achieve a more conformity, the IEC

(International Electrotechnical Commission) developed the

standard IEC 61131-3 [13]. Five programming languages

for programmable control systems have been defined in

this standard. The project talked about in this article is

implemented by Ladder diagram, one of them.

B. State Graphs

To conveniently formalize the execution environment of

PLC system, we introduce state graphs (SGs), a variant

of transition system [12]. The behaviors of environment,

through it, are formalized as a nondeterministic operative

process. Time is abstracted in a discrete way by assuming

Fig. 1. Programming logic controllers

Fig. 2. An example of SG: a sensor

that the environment fires exactly one transition at every

discrete-time tick. Each transition is labeled with a decision

or operation, etc. referred to as an action. It indicates that

the movement of firing this transition as the next step of

environment if in the origin state of the transition. The

definition of SGs is given as follows:

Definition 1 (State Graphs): A state graph M is a tuple

(A,S,R, init, AP, L), where:

1) A is a finite set of action,

2) S is a finite nonempty set of states,

3) init ∈ S is the start state,

4) R ⊂ S ×A× S is the set of state transition,

5) AP is the set of atomic propositions, and

6) L : S → 2AP is a labeling function.

For a SG M , A = Ao ∪ ζ, Ao is the set of actions

generated by an environment of a PLC system such that

the control program can observe and react. ζ is a symbol

to represent any actions of an environment not visible to

control program. Since the invisible action are irrelevant to

the input values of control program, ζ is used to represent

all invisible actions to make presentation clear. For instance,

Fig. 2 illustrates a SG modeling an environment: a sensorwhich monitors if some device passes. The sensor stays idle if

no devices comes. Otherwise, it becomes busy after finishing

the transition (s0, enter, s1) until the device leaves. For this

example, its output actions Ao = {enter, left, through} ,

and its invisible actions ζ = {no}.III. DESCRIPTION OF THE TCS

A. Presentation

TCS (Traverse Control System), which is part of manufac-

turing line of Steel Plate Heat Treatment (SPHT) controlled

250

Fig. 3. Traverse Control System

by PLC program, is designed to control Steel Plate Transfer

Devices (SPTDs). According to the requirement of manufac-

turing process, SPTDs are responsible for shifting the steel

plates from one group of rollers (C4/C5) to another parallel

group (D1/D2). The ichnography of TCS is shown as Fig. 3.

There exist two sets of SPTD – transfer device 1 and transfer

device 2 – in the sketch. The device 1 takes charge of moving

the plate from C4 to D1, while device 2 is in charge of C5

and D2. In the TCS system, there are eight sensors and each

device has four, as illustrated in Fig. 3, which respectively

indicate low, high, fore and back locations of the device. The

SPTDs are dollies based, powered by electrical motors and

lifted through hydraulic pressure.

The work process of the SPTDs is illustrated as follows: in

the initial stage, SPTDs stay in the low location, and then get

ready to work after launched. Once notified steel plates have

been laid on the C4/C5, they ascend and jack up plate away

from the rollers. When up to high location, SPTDs move

forward drawn by dollies, until arrive at the fore location

above D1/D2. Then SPTDs place plates smoothly on the

rollers and return to the back location. The subsequently

devices are down to the low location and wait for next

operation. This whole procedure runs under the control

of PLC program. In this case, TCS supplies two control

modes: remote and nearby control. Through each of which,

the operators can control SPTDs with the corresponding

switches.

B. Specification to Check

The traverse control system of the steel plate transfer

devices must satisfy the following specification.

1) S1: when the rollers run, the SPTDs must stay in

the low location; when the SPTDs are ascending or

descending, the rollers must be still.

G¬((T1up ∨ T1down) ∧ C4run)

and

G¬((T2up ∨ T2down) ∧ C5run)

2) S2: if there are plates on the D1/D2 rollers, the SPTDs

can never shift another plate.

G(¬T1for U D1ready) and G(¬T2for U D2ready)

IV. MODELING THE TCS

In this section, we explain the structure of our model for

the TCS system including the control program and execution

environment, with a particular attention to modeling timers

and application of event-drive mechanism. Finally, we give

a comprehensive description of the Promela based model for

the system.

A. Modeling Principle

A general PLC system embraces two components: PLCcontroller and execution environment. The model therefore

also divides into two parts: the model of PLC controller and

that of environment. The former is used to simulate CPU

and I/O module. During one scanning cyclic, PLC controller

executes three steps: reading inputs, executing and writing

output. What the executing process does is to execute PLC

control program. So modeling PLC controller is to model

the control program. According to the semantic of Promela

and the well-defining of PLC programming languages in

IEC-61131-3, it is convenient to convert PLC program to

the corresponding Promela program. However, one stopper

during this conversion is how to model timers, we will pay

a special attention to this question in later section.

PLC execution environment, including diverse hardware

and software entities, also play a pushing role in PLC system.

It is of significant for verification to faithfully and effec-

tively model it. Since its complexity, however, modeling the

environment is generally more troublesome. This work not

merely needs a throughout knowledge of the control system,

especially the behavior of each element, but also requires

well-defining formal representations for environment. In this

paper, we define the hardware and software context involved

in the environment as the concurrent entities. The definition

of concurrent entities is given as follow:

Definition 2 (Concurrent Entity): A concurrent entity Crefers to a hardware device or software program in PLC

system, which independently and concurrently executes with

PLC controller.

In TCS system, for example, all of the rollers, the sensors

or even the operators belong to the concurrent entities.

In order to simulate concurrent entities, each of them is

represented as an independent process in the model. Simulta-

neously, these processes interact with the main process which

models the PLC controller through a special mechanism:

event-driven. It provides an effective way to model the

interaction, as well as to ameliorate the state space explosion

problem. We will talk about it in detail in the following

section.

B. Event-Driven model

Due to high-speed scanning feature of PLC controller and

low-speed characteristic of peripheral devices, the environ-

ment variables in general update their values in more than

one scanning cycles. However, this speed gap cannot be

reflected just simply modeling concurrent entities as indepen-

dent processes. Since the sufficient concurrent characteristic

guaranteed by fairness properties results in that the chance

of executing each concurrent entity is almost the same as the

PLC controller. So the following negative effects might be

yielded. First of all, the interaction between the execution

251

Fig. 4. An instance for event-driven

environment and the PLC controller is hard to simulate .

Secondly, some state transitions of concurrent entities might

be undetected, which cause liveness property cannot be

accurately checked. A property for instance like this: if thebutton is pressed down, the roller should be enabled at somepoint in future. If the action of press button, however, cannot

be detected by PLC controller in that the following actions

cover it, the above property cannot be accurately verified.

For resolving these problems, we integrate to the model

of PLC system the event-driven mechanism and propose an

event-driven model. Some event based modeling methods

have been studied in [10] [14] [15] etc. Different from

these existed researches, however, this approach focuses

on the interactive relationship between the PLC controller

and execution environment. The external operations or other

efficacious inputs, named as events, can be timely detected

and responded. That is, when an event occurs, the PLC

controller will be notified, respond in the following. Such

model, undoubtedly, enhances the interactivity and reduces

the response time, makes the program more aim-oriented.

It is also closer to the real situations of PLC system. To

apply the event-driven model, this paper assumes that the

PLC controller can normally respond to any event, that is,

any value changes for input variables can be dealt with in

right way. The definition of event is given as following:

Definition 3 (Event): An event E is a state transition t in

a state graph M w.r.t a concurrent entity C, which its action

a ∈ Ao

Intuitively, an event represents some input variable of PLC

controller changes its value. The idea of event-driven model

is as follows. If an event E occurs, the process C of a

corresponding concurrent entity will block itself, and the

process P modeling PLC controller will be triggered and

begin computing, simultaneously new states will be gener-

ated; otherwise, P just execute idly without producing new

states. After complete computation and output the results, Pwakes up the blocked process C to finish the state transition.

During this procedure, PLC controller needs scanning cycles

one or more to produce stable output. An instance for event-

driven model shown in Fig. 4, at t0 an event E occurs, the

process of concurrent entity C blocks itself and wakes up

PLC controller before state transition. During time interval

(tm, tn), PLC controller scans no less than one time and

produces output , then activates the blocked C process and

completes E at time tk as well as generates one new states.

In order to verify real-time system, time is introduced

Fig. 5. The relationship of components in event-driven model

into event-driven model. However, different from real-time

model checker such as UPPAAL etc., the designers of SPIN

deliberately ignores time concept on account of performance

and efficiency. Therefore accurate and concrete time is dif-

ficult to obtain under SPIN/Promela setting. To address this

problem, some researches such as [16] have put forward time

handling technologies, including variable time advance etc.

Although satisfying some special demands, these methods

are ineffective to present the timer’s features. In this paper,

we propose a novel time abstraction method which make the

continuous time discrete. For describing time, we first define

the clock benchmark:

Definition 4 (Clock Benchmark): The clock benchmark

CB equals a scanning cycle, viz. the duration time for PLC

controller executes once.

Now we will present how to compute the CB value with

time abstraction method. In a real PLC system, two situations

should be considered: 1) CB can be set in terms of users’

requirement, so it is advisable to define CB in terms of the

timers’ preset values, 2) these preset values in general span

largely such as ranging from several milliseconds to several

hours, it is difficult and unnecessary to obtain an optimal

value. In this paper, the value of CB can be computed in

following steps:

1) unifying all of the timers’ unit, such as millisecond,

and

2) computing the great common divisor (gcd) of these

converted values and assign it to the CB, that is

CB = gcd(timer1.value, · · · , timern.value) (1)

Then all of the timers will be assigned a new preset value

computed from the following formula:

timeri.newvalue =timeri.value

CB(2)

This new value must be an integer in that CB is a divisor

of the old value.

For simulating time-measuring with crystal oscillator in

actual PLC system, this work defines a global clock G,

represented by an inline function, which is responsible for

timing. It synchronizes with PLC controller by function call

and updates the activated timers. Specifically, the activated

timers tick one per scanning cycle. If some timer is arrival,

252

G notifies PLC controller to respond accordingly. This

procedure is similar to the event, but not modeled as an

independent process.

Note that there exists a side-effect with time abstractionthat cannot reflect the difference of residence time between

PLC controller and concurrent entities. In other word, the

execution time of PLC controller and that of concurrent

entities are indefinite in our model. However, it does not

impact the effectiveness of this abstract method in that a

time slice, defined as the interval between two adjacent

CB, can approach to infinity theoretically (in fact, this is

not going to happen because fairness constraint). So it has

included all possible situations in the real system. If no

counterexamples in abstract model, we can say that the

specification is satisfied in real system; otherwise, we should

analyze the counterexample to validate if it is spurious.

The relationship in event-driven model between the PLC

controller P and concurrent entities Mi(i = 1, 2, · · · , n),global clock G and the timers is illustrated as Fig. 5.

The interaction between P and Mi is through event, while

that between P and G, as well as G and the timers is

through function call. For clarity, the PLC model M can

be represented as follows:

M = (P ←↩ G)‖M1‖M2‖ · · · ‖Mn (3)

C. Modeling Environment

In most cases, modeling environment is indispensable for

validation of a PLC system. Furthermore, it makes possible to

speed up the verification time by reducing the combinatorial

aspects related to nondeterministic definition of all possible

input values, including sometimes irrelevant ones. Indeed,

when the input values of the PLC program are emitted by a

model instead of a nondeterministic process, the space of

reachable states is reduced. Note that this paper restricts

to only model the environment relevant with properties and

assumes works without failure.

In TCS, the environment is split into three parts: 1)

the rollers, 2) the control operation and switches, and 3)

the transporting devices and sensors. The environment is

described as different concurrent entities represented by state

graphs. In such SGs, a given state represents a particular

status of the concurrent entity, and a given action represents

a corresponding operation.

1) The Rollers: The rollers are important components

for TCS. Only correct cooperation between the SPTDs and

rollers can shift the plate. Because of similarity among the

rollers, we just describe the C4 and D1 in this paper. The

SGs as for these two rollers are illustrated as Fig. 6. Each of

them has two types of properties need to describe: 1) whether

there is some steel plate on it, or 2) if it is running. So the

set of atomic propositions representing the status of rollers

is defined AP = {idle, run, busy, stop}. The meaning of

states of the rollers is clear, for instance, state {idle, run}represents the roller is running without plate. While state

{idle, stop} is the ready state for D1.

(a) Roller C4 (b) Roller D1

Fig. 6. State Graph of the rollers: (a) C4 roller (b) D1 Roller

Fig. 7. State Graph of the control operation and switches

Fig. 8. State Graph of the transfer devices and sensors

2) The Control Operation and Switches: Review that the

behaviors of SPTDs are controlled manually by operators

through corresponding switches, including chose device,

giving forward, backward, ascend, descend and emergencystop instruction. In this case, we simulate the operations

and switches together, viz., we model this environment in

such a way as that a operator is controlling the switches.

This model, on one hand, can precisely and conveniently

simulate the real situation; on the other hand, comparing

with modeling switches one by one, it is possible to abate

the state space through reduce the number of concurrent

entities. The SG is illustrated as Fig. 7. In this model, ζ ={!press asc, !chose device} defines the invisible actions for

PLC controller.

3) The Transfer Devices and Sensors: SPTDs are the

critical components of the environment, because conveyance

of the steel plates depends on its correct work. It is also the

most delicate to model since its continuous behavior along

the fixed orbit, while our model can only provide a discrete

abstraction of this behavior, leaving out the details which

do not influence the properties to be checked. To obtain

reasonable performances in terms of memory and automatic

verification time, we model only the almost stable positions,

i.e., the positions where the SPTDs can stop, or trigger a

253

(a) TON (b) State graph of TON

Fig. 9. A timer TON: (a) TON (b) State graph

sensor. Fig. 8 shows the state graph of this concurrent entity.

Recall that each device possess four sensors – low, high,

fore and back sensor. They are used for detection, interacting

with PLC controller through events. The triggering of these

sensors depend on the position of SPTDs. Between two given

positions, the behaviors of the SPTDs is assumed to be

movement with constant speed, and thus modeled by a timer.

This timer evolves in one state and is assigned by an constant,

representing the time needed by SPTDs cross the distance

between these two position. The SPTDs for instance goes

from the back location to the fore location in 70CB. At the

time of its arrival to the desired position, the corresponding

input variables are modified and the event is triggered.

D. Modeling Timer

TCS system includes timing operation, implemented by

the timer on delay (TON), as shown by Fig. 9(a). This func-

tion block has four variables including two input variables

S and TV , as well as two output variables Q and RT . The

meaning for them is: S is enable input, TV is preset time

value, and Q describes the status of the timer, while the

RT represents the remaining time value with integer format.

Fig. 9(b) illustrates the SG of timers. More information can

be found in [13].

This paper refers the approach of RT-SPIN [17] and defines

the timer as a short type variable when modeling timer.

Different from [17], however, the variable is specified as

hidden – anonymous variable – to ameliorate state explo-

sion problem. Anonymous variable is a special variable in

Promela which has the advantage that its value is not part

of the states of a computation, so no memory is required to

store it during a verification. It certainly cannot be used to

specify properties of the system. In this case, it is however

suitable in that the values of timers represent the remaining

time are not cared. We merely concern whether the timer

expires. So it does not refer the value when describes the

properties for the TCS. The definition of the timer is given

in Promela as follow:

#define timer hidden short

For conciseness, this definition and some common func-

tions about timer are given through macro. Then computing

the CB and assigning the corresponding abstraction time to

the timers in term of method discussed in section IV-B.

Fig. 10. The Promela model of the main control program

E. Model of Entire System

1) The event-driven Program: Each concurrent entity is

modeled as an independent concurrent process in our model.

Accompany with each process, global anonymous variables

eventXX shown in Fig. 10 are defined as event marks. A

function SystemTime is called by process PLC simulates

the global clock, and anonymous variable timerIsArrivalrepresents if some timer is arrival. The following formula

reveals the relationship of event-driven in our case:

M = (P ←↩ G)‖Mrollers‖Mcontrol‖Mdevices (4)

The interaction between P and the concurrent entities

(Mrollers,Mcontrol, Mdevices) is implemented through eventmark. However, we must make sure that the continuous

execution of the control program does not cause a starvation

of the concurrent entities processes. This is taken care of by

allowing fair execution of Promela model: no process willbe ignored indefinitely.

2) The Main Program: The main control program of

TCS system is implemented with ladder diagram. It can be

translated into Promela language in a straightforward way on

the ground of its semantic. Since the Promela model of this

case is too big to be part of this paper, here we present only

an excerpt – scheme of the process as for the PLC controller

– to show the main features.

Fig. 10 illustrates the model of the main control program.

The model consists of a loop repeatedly check whether some

conditions, e.g. timerIsArrival==1 or transEvent==1, is true.

If fulfilled, controller will execute the body of the loop (using

the atomic construct).

V. VERIFICATION

The specifications S1 and S2 formulated as the following

LTL formulae and then checked in tool SPIN:

• S11 ([]!((T1up||T1down)&&C4run)),• S12 ([]!((T2up||T2down)&&C5run)),• S21 ([](!T1for U D1ready)), and

• S22 ([](!T2for U D2ready)).

254

TABLE I

THE SIZE OF TCS MODEL

Design #Timer #V arEvent− driven Model Cycle− driven Model

#Proc #V ar #Proc #V ar

MNT1 6 122 5 76 2 76

MNRT1 6 156 6 89 2 89

MNT12 12 243 8 124 2 124

MNRT12 12 290 9 135 2 135

To validate our approach, we compared it to the cycle −driven model, which considers the cyclic mode by explicitly

modeling the sequence of reading inputs, executing the pro-

gram, and writing the outputs [1] [11]. We implemented the

TCS models under these two schema with Promela. Table I

lists the differences of these two schemas w.r.t the numbers

of processes and variables. We compared how fast and how

efficient do these methods verify above LTL properties for

TCS. The results are listed in Table II. All experiments were

carried out on a Windows machine with an Intel(R) Xeon(R)

CPU and 2 GB memory.

In Table I, Design is the name of the model. The design’s

name implies relevant parameters. For example, name MNRT12

indicates the model includes device 1 and device 2, and

two control styles – remote and nearby. The #Timer,

#Proc and #V ar columns represent the number of timers,

processes and variables respectively. Note that, to improve

efficient of model checking, we used the cone of influence

reduction – an abstraction technique – to reduce the model

size. This abstraction preserves correctness of above LTL

properties and more details can be found in [18]. To make

a fair comparison, we make the same abstraction in these

two schemas, so the variables number is same in event −driven model and cycle− driven model.

TABLE II

EXPERIMENT RESULT AND COMPARISON FOR EVENT-DRIVEN MODEL

AND CYCLE-DRIVEN MODEL

Design PropertyEvent− driven Model Cycle− driven Model

Result Time(Sec.) Mem(MB) Result Time(Sec.) Mem(MB)

MNT1

S11 No 5.94 78.514 No 100.21 384.615

S12 Yes 3.14 61.326 Yes 88.30 280.200

S21 Yes 0.67 40.623 Yes 31.74 260.701

S22 Yes 0.65 39.200 Yes 32.43 257.543

MNRT1

S11 No 25.66 169.233 No 333.78 578.572

S12 Yes 14.23 122.311 Yes 278.70 498.233

S21 Yes 2.79 80.362 Yes 188.65 466.233

S22 Yes 2.81 78.213 Yes 190.24 478.106

MNT12

S11 No 145.23 556.578 − N/P > 1000

S12 Yes 127.76 578.715 − N/P > 1000

S21 Yes 55.94 324.265 − N/P > 1000

S22 Yes 56.00 327.523 − N/P > 1000

MNRT12

S11 − > 352.234 > 2000 − N/P > 1000

S12 − > 396.670 > 2000 − N/P > 1000

S21 Yes 335.94 863.972 − N/P > 1000

S22 Yes 345.78 857.658 − N/P > 1000

Table II lists the comparison results between our approach

and cycle − driven model. The efficiency of a method is

evaluated by its runtime, the memory usage and the verifi-

cation results. The columns under result describe whether

the specification is satisfied. To guarantee termination, we

impose a limit of two hours on the running time. We denote

by N/P in the Time(Sec.) column that could not be solved

in this time limit. A ”−” indicates that the verification result

is unavailable.

Form the results in this table, the following observations

can be obtained. Firstly, in comparison with the two methods,

we observed that our approach can always obtain verification

result in shorter runtime and memory except two properties

S11 and S12 for design MNRT12 . The cycle − driven model

quickly blows up as the problem size increases. Such phe-

nomena show that event driven based model can improve

the performance of model checking and promote its appli-

cation in PLC design. Secondly, a counterexample is found.

Because these models are abstracted system, we need to re-

produce this counterexample on the original system to check

if it is spurious. Through simulation, the counterexample

was reproduced successfully in the original system. Such

phenomena showed the power of our approach.

Here, we can see that our approach can effectively model

and check an entire PLC systems, including execution en-

vironment and timers. However, the state space explosion

is still a stopper if the verification system is too large. The

verification results for properties S11 and S12 in MNRT12 show

this question. The 2G memory is quickly exhausted because

of too much processes and variables.

VI. CONCLUSION

In this paper, we presented a systematic approach to verify

a timed PLC system and its execution environment with

model checking technique. As we known, execution environ-

ment and temporal performance are two important ingredient

for a PLC design, and they also pose the main hurdles dur-

ing the model checking process. We proposed event-driven

mechanism and time abstraction method to solve these prob-

lems, and integrated them into the SPIN/Promela context.

Experiment results showed the efficiency and power of our

approach. The impact of the state explosion problem is not as

significant as the general method with cycle−driven model.Modeling execution environment and the application of time

abstraction help to tackle the state explosion problem.

Abstraction and modeling of the complex execution envi-

ronment is very important in verification of PLC systems,

future research should focus on the development of new

environment abstraction techniques. We think that combi-

nation of compositional method and abstraction refinement

techniques is promising. Therefore, it should be determined

whether there are abstraction refinement methods that could

be integrated into this approach.

REFERENCES

[1] G. Frey and L. Litz, “Formal methods in PLC programming,” in Proc.IEEE Int. Conf. Systems, Man, and Cybernetics (SMC’00), Nashville,USA, Oct. 2000, pp. 2431–2436.

[2] R. Huuck, “Software Verification for Programmable Logic Con-trollers,” Ph.D. dissertation, Christian-Albrechts-Universitat zu Kiel,Kiel, Germany, 2003.

255

[3] G. J. Holzmann, “The Model Checker SPIN,” IEEE Trans. Softw. Eng.,vol. 23, no. 5, pp. 279–295, May 1997.

[4] R. Alur and D. Dill, “A Theory of Timed Automata,” Theor. Comput.Sci., vol. 126, no. 2, pp. 183–235, Apr. 1994.

[5] A. Mader and H. Wupper, “Timed automaton models for simpleprogrammable logic controllers,” in Proc. 11th Euromicro Conf. Real-Time Systems (EUROMICRO-RTS’99), York, England, Jun. 1999, pp.106–113.

[6] K. Sacha, “Automatic code generation for PLC controllers,” in Proc.24th Int. Conf. Computer Safety, Reliability, and Security (SAFE-COMP’2005), R. Winther, B. Gran, and G. Dahll, Eds., Berlin,Germany, Sep. 2005, pp. 303–316.

[7] K. Sacha, “Translatable finite state time machine,” in Proc. Design ForDependable Systems (SDL’2007), E. Gaudin, E. Najm, and R. Reed,Eds., Paris, France, Sep. 2007, pp. 117–132.

[8] K. Sacha, “Verification and implementation of software for dependablecontrollers,” Int. J. Crit. Comput.-Based Syst., vol. 1, pp. 238–254, Feb.2010.

[9] S. Klein, G. Frey, and M. Minas, “PLC programming with signalinterpreted Petri nets,” in Proc. 24th Int. Conf. Applications and Theoryof Peti Nets (ICATPN’2003), W. VanDerAalst and E. Best, Eds.,Eindhoven, Netherlands, Jun. 2003, Proceedings Paper, pp. 440–449.

[10] H. Bel Mokadem, B. Batrice, V. Gourcuff, O. De Smet, and J. Roussel,“Verification of a Timed Multitask System With Uppaal,” IEEE Trans.Autom. Sci. Eng., vol. 7, no. 4, pp. 921–932, Oct. 2010.

[11] S. Lohmann, O. Stursberg, and S. Engell, “Comparison of event-triggered and cycle-driven models for verifying SFC programs,” inProc. American Control Conference (ACC’07), New York, NY, Jul.2007, Proceedings Paper, pp. 4793–4798.

[12] C. Baier and J.P. Katoen, Principles of Model Checking. The MITPress, 2008.

[13] IEC Standard 61131-3:Programmable Controllers–Part 3, Standard61131-3, IEC (International Electrotechnical Commission) Std., 1992.

[14] S. Kowalewski, S. Engell, J. Preussig, and O. Stursberg, “Verificationof logic controllers for continuous plants using timed condition event-system models,” Automatica, vol. 35, no. 3, pp. 505–518, Mar. 1999.

[15] H.-M. Hanisch, J. Thieme, A. Luder, and O. Wienhold, “Modelingof PLC behavior by means of timed net condition/event systems,” inProc. 6th IEEE Conf. Emerging Technologies and Factory Automation(ETFA’97), Sep. 1997, pp. 391–396.

[16] E. Brinksma, A. Mader, and A. Fehnker, “Verification and optimizationof a PLC control schedule,” Int. J. Softw. Tools for Technol. Trans.,vol. 4, no. 1, pp. 21–33, Oct. 2002.

[17] S. Tripakis and C. Courcoubetis, “Extending Promela and Spin for realtime,” in Proc. Tools and Algorithms for the Construction and Analysisof Systems (TACAS‘96), Berlin, Germany, Mar. 1996, pp. 329–348.

[18] E. Clarke, O. Grumberg, and D. Peled, Model Checking. The MITPress, 2001.

256