Modeling Programmable Logic
Controllers for Logic Verification
I1 Moon
verification method has been developed for determining the
afety and operability of programmable logic controller
(PLC) based systems. The method automatically checks sequential logic embedded in PLCs and provides counterexamples if it
finds errors. The method consists of a system model, assertions,
and a model checker. The model is a Boolean-based representation of a PLC’s behavior. Assertions are questions about the
behavior of the system, expressed in temporal logic. The model
checker generates a state space based on the above two inputs,
searches the space efficiently, determines the consistency of the
model and assertions, and supplies counterexamples. Amodeling
technique has been developed to verify relay ladder logic (RLL),
a PLC programming language. The performance of the model
checker is studied in a series of alarm designs.
As
scribes a RLL program being verified, 2) assertions that express
questions about the RLL behavior with respect to safety and
operability, and 3) a model checker that searches a model to
determine the validity of assertions and supplies counterexamples. The assertions are expressed using temporal logic operators
for reasoning about event occurrence over time. We applied the
method to alarm systems to understand the performance of the
method.
RLL Models
PLC programs can be developed in a number of different
forms. Relay ladder logic (RLL) is a common representation used
to document PLC programs. Grafcet, Function Chart, Boolean
and other high level programming languages are also available
for PLC program development [3], [6].These representations of
a PLC program can be converted into equivalent logical expresAutomatic Verifification Method
The safety and reliability of control systems are becoming sions, for example, Petri nets or Finite State Machines [5].We
more important as they are used in crucial systems such as toxic select a popular language, RLL, and apply the automatic model
chemical plants, nuclear power plants and space shuttles. As checking method to verify PLC software. This section illustrates
control systems become increasingly complex to satisfy diverse the modeling of RLL as an input to the model checker. Relative
demands, complete testing of their safety becomes more difficult. issues are PLC scanning cycles, basic elements of RLL and the
Lack of any formal and efficient verification method has pre- conversion rules from a RLL to an equivalent model expression.
A PLC is a dedicated microprocessor that continuously reads
vented the creation of practical design aids. We have developed
inputs and in real-time determines new outputs. The outputs are
an automatic verification method to test PLC-based systems.
based on inputs and the previous outputs, according to its proPLCs are used in a wide variety of control applications. Relay grammed logic. Fig. 1 presents the data flow of a PLC and a
ladder logic (RLL) is a popular programming language for PLCs.
process system. When controlling a system, a PLC repeatedly
While much literature is available about designing RLL [SI-[lo],
executes a scanning cycle. One scanning cycle consists of three
there is little in the literature about automatic testing of RLL.
steps:
Errors in RLL can be included at any time over the software
1. reading input values from sensors and storing them in an
development cycles. The more PLCs are used, the more imporintemal bit table,
tant verification of RLL becomes. Traditionally, the verification
2. executing the programmed logic and altering the intemal
process of RLL depends on manual tests based on the designer’s
bit table, and
experience. Altematively, simulators might be used to test a
3. writing new outputs to actuators based on the values in the
limited number of scenarios. As the number of input variables
bit table.
increases, in which the variables can be changed at any time
For the PLC to be an effective controller, the scanning time
randomly, the number of scenarios to be tested increases very
must be less than the shortest duration time of an input or an
quickly. The state explosion is the primary limitation of testing
output signal. Scanning times commonly range from millisecall possible scenarios using traditional approaches. The model
onds to tenths of seconds, depending on the processor speed, the
checking verification method provides a reasonable solution to
program length, and the number of input and output devices [4].
this problem.
RLL is a Boolean-based programming language used in PLC.
Clarke et a/. [ 2 ] developed the model checking verification The values of all the variables for the control program are stored
method and applied it to testing communications protocols and in the PLC’s intemal bit table. Two input contacts and one output
VLSI circuit designs. We have extended this method to verify coil are used to access these values. Fig. 2 shows their symbols
PLC-based systems. The method includes: 1 ) a model that de- in RLL. The first input symbol of the figure is a normally open
contact. A PLC examines the specified bit corresponding to this
The author is with the Department of Chemical Engineering, Yonser symbol and it retums logic 0 if that bit is a zero or logic 1 if that
University, Seodaemun-Ku, Shinchon-Dong 134, Seoul 120-749, bit is a one. The second input symbol is a normally closed contact.
Republic of Korea. Email: ilmoon@buhble.~onsei.ad.kr
This symbol represents the logical negation by retuming logic 1
Agrill994
0272- 1708/94/$04.000 1994IEEE
-
~~
53
PLC
Relay Ladder Logic
if the specified bit is a zero or logic 0 if that bit is a one. The
output coil assigns the logic value of the given function to the bit
indicated.
The conversion from a RLL to a model description is almost
an one-to-one correspondence. The value of the output coil, in
the right-most end of each rung, depends on the structure and the
values on the left hand side of the rung. Each rung can be
converted into the corresponding model description using the
operators: (NOT), & (AND), I (OR), next (one scanning time
later) and := (define).
Fig. 3 shows a RLL (left diagram) and the equivalent model
description (right text). The vertical rails of the RLL indicate the
power source and sink, while the horizontal lines, called rungs,
indicate the possible current flow. A PLC scans rungs from top
left to bottom right of the RLL. Depending on PLC makers, PLCs
scan rung-by-rung or column-by-column. In many cases, the two
scanning orders make no difference in the PLC’s behavior. To
avoid exceptional cases [SI, we choose the popular rung-by-rung
scanning order and model RLL under the given scanning order.
The column-by-column scanning order can be modeled in a
similar way.
Rung 1 of the diagram consists of a normally open contact
and an output coil. The current value of the output coil (R2) is
the same as the value of the contact (Rl) in the previous scanning
time. This means that if input R1 is TRUE then R2 is TRUE in
the next scanning cycle; otherwise R2 is FALSE in the next
scanning cycle. Though the bit table is updated immediately as
the related inputs are changed, the output signal occurs after one
scanning time. To include the notion of the time difference
between the input and the output, the operator “next” is used in
the model description as shown on the right hand side text of the
figure. Rung 2 represents the Boolean logic “NOT” and the
equivalent model description is shown in the text using the
operator
Series and parallel arrangements of input variables represent
Boolean logic “AND” and “OR,” respectively, as shown in rung
3 and 4. For example, R7 in rung 3 is TRUE in the next scanning
time only if both R5 and R6 are TRUE currently. Rung 5 shows
a latch which is a fundamental component of all storage elements.
The value of R12 becomes TRUE (latched) if the value of R11
becomes TRUE and the value remains TRUE until the value of
R13 becomes TRUE (unlatched). The equivalent model description is shown in the text of the figure. Notice that R12 is shown
on both the right and the left hand side of the text, but their timing
is different by the operator “next”. Because R7 in rung 6 is also
shown in rung 3 as an output, the value of R7 has been already
changed when the PLC starts scanning rung 6 (only in the
rung-by-rung scanning order). So the value of R7 in rung 6 is the
same as the next value of R7 changed in rung 3. R7 in rung 6 is
represented in the model description as next(R7) instead of R7
even though R7 is shown on the left hand side of the rung. The
conversion rule here is that if the input variable is already shown
as an output variable above the current rung, the operator “next”
should be added to represent the variable in the model description. We can translate a RLL into a corresponding system model
for its verification using the conversion rules shown in Fig. 3.
The models of other advanced PLC features such as timers are
needed to verify RLLs more completely.
i ~ T d *
Bit Table
-
Sensors
I
I
I
Processes
I
Actuators
1 “;_.-.-..-.-~.-.--.-__.._~
Process System
I
._I_“.I__-_
-=
I
-
_-.llll-
*
ri
Fig. I Dataflow between a PLC and a process yystem
bit I
Normally Open Contact
=0
{ 0,1, ifif bitl
bitl = 1
k
“w.”
bit2
(
Normally Closed Contact
Output Coil
&
~
0, if bit2 = 1
1, if bit2 = 0
bit3 = 0, i f f = 0
bit3 = 1, i f f = 1
Fig. 2. RLL input and output symbols as adaptedfrom 141.
Rung 1
-+
next(R2) := R1
Rung 2
next(R4) := -R3
R6
R5
Rung 4
next(R10) := R B I
R9
Rung 6
~~7HR~y~l
next(R15) := next(R7) & R14
R15
Fig. 3. RLL and equivalent model description
54
. -
IEEE Control Systems
CTL Assertions
Assertions are questions about the behavior of the system with
respect to safety and operability. We use computation tree logic
(CTL) [2] to describe assertions formally. CTL is a variant of
propositional logic with additional operators for expressing temporal relationships. Propositional logic operators are (NOT),
& (AND), I (OR) and -> (imply). The time associated operators
include state quantifies and path quantifiers. The state quantifiers
are G (globally), F (future),X (next time), and U (until). The path
quantifiers are A (all) and E (some). For example, if g is a formula,
then Fg is TRUE if and only if g holds at some state in the future.
The path quantified formula AFg holds if g holds at some state
in all possible future. Also, EGg is TRUE if g is always TRUE
in some possible future. CTL is a branching time logic where the
temporal operators quantify over the paths that are possible from
a given state. The following abbreviations are used in writing
CTL formulas:
-
A F O = A[TRUE U,fl
EFO
E[TRUE U f l
A G O E -EF-f
EGO
-AFyf
Detailed explanation for the usage of CTL operators is in [ 7 ] .
for every state s E S do
for every f
if
sub(f0) of length i do
f = A[fl U f2] and f2 E set(s) or
f = E[fl U f2] and f2 E set(s) or
f = EXfl and $x[(s,x)E R and f l E set (x)] or
f = f l & f2 and f l E set(s) and f2 E set(s)
then add f to set(s) end if
end for
end for
E
A: for j = 1 to card (s) do
for every state s E S do
for every f E sub(f0) of length i do
i f f = A[fl U f2] and f l E set(s) and
Vx[(s,x) E R - Z f E set (x)] or
f = E[fl U f2] and f l E set(s) and
3x[(s,x)E R & f E set (x)]
then add f to set(s) end if
end for
B:end for
end for
for every state s E S do
for every f E sub(f0) of length i do
i f f @ set(s) then add -f to set(s) end if
end for
C:end for
Fig. 4. Model checking algorithm of pass i as adapted from 121.
Model Checker
lengthvo). On pass i, every state s E S is labeled withfor -ffor
The model checker is a program which determines whether
each
formula f E sub(f0) of length i. The information, gathered
the assertion is satisfied in the model being verified. The model
checker constructs a complete state transition graph of the sys- in earlier passes about formulas of length less than i, is used to
thenf should
tern. Then, using an efficient graph algorithm, it labels the perform the labeling. For example, iff =fl &p,
vertices in the graph which satisfy each subformula of the asser- be placed in the set for s precisely whenfl a n d p are already
tion, following the parse tree of the formula from inner to outer present in the set for s. Information from the successor states of
subformulas. For each CTL operator, there is an algorithm for s is used for modalities such as A V Up].Since A W Up]=f2
&l
AXAlfl U f l ] ) ,ALfl U f L ] should be placed in the set for
determining the truth of a formula constructed with the operator, I (f
given that the truth of the subformulas has already been deter- s whenfl is already in the set for s or whenfl is in the set for s
mined. The model checker is the combination of these algo- and ALfl U,f2] is in the set of each immediate successor state of
rithms. For the detailed algorithms, see [2].
S.
Fig. 5 illustrates the model checking algorithm. A state tranThe model checker may also be used to provide a counterexample to a FALSE assertion. The trace of a counterexample is a sition graph to be verified, coming from a system model, is shown
sequence of states that demonstrates why the formula being in FigS(a). The next graphs show snapshots of the algorithm in
tested is FALSE. When the model checker determines that an operation for the formula AF h & EG a (which abbreviates AF b
assertion is FALSE, it tries to find a path which demonstrates that & -AF-a). The given formula is broken into the following
the negation of the assertion is TRUE. This feature is quite useful subformulas:
for locating the cause of errors in the system being verified.
{ h, -a, AF-a, AFb, -AF-a, AFh & -AF-a}
A part of the model checking algorithm is given in Fig. 4 [2].
Assume that we determine whether formulaf is TRUE in a finite
structure M = (S, R, P). S is a finite set of states, R is a binary The first two subformulas are used to determine the labeling of
relation on S which gives the possible transitions between states each state. Then if b is labeled TRUE, the state is labeled again
and P(s) is the set of TRUE atomic propositions in state s, where as AFh is TRUE. Similarly, if -a is TRUE, AF-a is TRUE.
an atomic proposition is the state variable which denotes the Consequently AFh is labeled in state 1 and 3, and AF-a is labeled
property of interest and has either TRUE or FALSE value. in state 1 as shown in Fig. 5(b). The next step is to propagate AFb
StatementM, s I= f means that formulafholds at states in structure to its previous states. Since AFh is TRUE in state 3, it is true in
M . Let sub(fo) denote the set of subformulas offo. We label each state 2 as shown in Fig. 5(c). Similarly it is also TRUE in state 0
state s E S with the set of positive/negative formulas f in sub(fo) as shown in Fig. 5(d). The last two subformulas are labeled in
so that f E label(s) if and only if M , s I=fand - f ~label(s) if and Fig. 5(e) and 30. In this case, the answer of the model checker
only if M , s I= -f The algorithm makes I I + I passes where 17 = to the assertion is TRUE since the assertion is TRUE in state 0
April 1994
55
danger signal (dl)
push button (APB)
horn (horn)
warning light (lig)
Fig. 6. A single-alarm system as adapted from [9].
~ i5 ,A~ ,
process with assertion AFh & E C ;as
~ adapted
from 121. ( a )A system model to he verified. (b) First time at label A
in pass 1 . (c) First time at label B in pass 1 . ( d )Second time at label
B in pass 1. ( e ) First time at label C in pass 1. (fi At termination.
s(f). A thorough description of the model checking
algorithm is given in [2],
So far, the three components of the modcl checking verification method (model, assertion, modcl checker) have been explained. The following examples illustrate the verification
method by testing alarm systems.
of Fig.
allowable limit: for example, a reactor is in a high temperature
or in a low pressure state.
Informal design specifications for the RLL of this alarm
system are the following. If the danger signal is detected ( d l =
I), the alarm system sounds the hom (hom = 1). The operator
may press the push button (APB = 1) to shut off the hom. At the
same time, the operator’s acknowledge signal (APB = 1) tums
on the warning light (lig = 1). The light stays on as long as the
danger signal remains (dl = 1). In the meantime, the operator
(hopefully) corrects the cause of the problem. As soon as the
danger signal ceases (dl = 0), the light tums off (lig = 0) and the
system retums to its initial normal state. Suppose that an engineer
designs a RLL for the alarm system as shown in Fig. 7 based on
the above specifications. Now we can use the verification method
to make sure that the RLL follows all the given specifications.
As the first step of the verification, we need to model the RLL.
Fig. 8 shows a part of the representation of the RLL in the
model checking language. Each line of the figure corresponds to
each rung shown in Fig. 7. At every time step (scanning time of
a PLC), thc dependent variables, R1,hom and lig, change according to the right hand side rules of each line. At the same time
the independent variables, dl and APB, vary freely: that is, each
independent variable can be either 0 or 1 in every time step. Since
the number of the independent variables is two in this example,
the number of possible situations is four (2*) in every time step.
The model checker verifies all those possible cases efficiently as
time goes by.
With the system description, we are ready to ask questions
about the behavior of the RLL. Fig. 9 shows assertions and
executions of the automatic model checker applied to the system
description. The lines in bold face represent inputs (assertions)
from the user. The first three assertions shown in lines 1,4, and
Case Studies
This example illustrates the modeling of RLL and the use of
the verification method. First, we will test a single alarm system
to demonstrate the usefulness of counterexamples. Then, we
multiply the single alarms and verify the multiple alarm systems
to compare the size of the memory used in verifying different
structures of RLL.
Single-Alarm System
Consider a typical alarm system shown in Fig. 6 [9]. The
system has two binary inputs: the danger signal (dl) and the
operator’s acknowledge push button signal (APB) and two bin a y outputs: the hum (hom) and the warning light (lig). Each
binary variable has a value of either 1 (TRUE) or 0 (FALSE).
1 1 4 1
I
next(R1) := ((-dl & (APB I -horn)) I R1) &((-horn & -APB) I -dl);
next(horn) := ((next(R1) & d l ) 1 horn) & -APB;
next(lig) := ((dl & APB) I lig) & (next(R1) I d l ) ;
-i
Fig. 8. System description for the RLL shown in Fig. 7
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
I= AG(APB -5 AF -horn)
The assertion is TRUE.
is equivalent to A[horn Unless APB], which means that the horn
remains TRUE unless APB is TRUE. The assertion examines the
case where once the horn turns on, then the horn keeps on unless
the push button is pressed. The push button may not be pressed
forever. The answer is TRUE as shown in line 8. The results of
the above three tests indicate that the horn behaves correctly as
the user requires.
Now we test the behavior of the warning light. The CTL
expression, shown in line 10,
AG (-dl -> A F -1ig)
I= AG(-dl & -APB -Z AX(d1 & -APB -> AF horn))
The assertion is TRUE.
I= AG(horn -> -E[-APB U (-horn & -Ape)])
The assertion is TRUE.
I= AG(-dl -5 AF-lis)
The assertion is FALSE.
State 0: R1 = 1, horn = 0, lig = 0, d l = 0, APB = 0
State 1: d l = 1
State 2: horn = 1
State 3: R1 = 0, APB = 1
State 4: horn = 0, lig = 1, d l = 0, APB = 0
AF (-lig) is FALSE:
State 5: R1 = 1, d l = 1
State 6: horn = 1
State 7: R1 = 0, APB = 1
State 8: horn = 0, d l = 0, APB = 0
Fig. 9. Model checker execution for the RLL.
means that the light does not turn on without the danger input.
The answer is FALSE. This means that there is a state that the
light turns on (lig = 1) when there has been no danger signal (dl
= 0). Let us trace the counterexample to locate the error. The
initial condition shown in line 13 is that all variables except R1
are zero (FALSE). The danger signal (dl) is detected in state 1.
The horn sounds in state 2. The acknowledge push button (APB)
is pressed in state 3. The hom goes off and the light turns on in
state 4. In the following states as shown in line 19, the light does
not always turn off again even though the danger signal disappeared. One example is the loop, states 5, 6, 7, 8, 5 , ... . This
behavior confuses the operator because the warning light is still
on even though heishe already removed the cause of the problem.
This counterexample might suggest a modification to the design,
particularly the logic part related to the light. Current methods
do not automatically correct the system design.
For the light to work properly for this situation, the RLL
should be revised. Fig. 10 illustrates a possible solution by
removing R1 in the third rung of the RLL.
I
7 are questions about the behavior of the hom, and the last
assertion is about the light. The first assertion
AG (APB -> AF -hom)
makes the model checker search all possible states in the system
and answer the question, “If the push button is pressed, does the
hom eventually shut off?” This assertion tests the tuming off
behavior of the horn. The model checker’s answer to this question
is TRUE as shown in line 2 of Fig. 9, which means that pressing
the push button always makes the horn shut off eventually. Now
we want to check the sequence of tuming on the hom. The second
assertion
Fig. IO. Revised third rung.
The same assertions are used to check the revised RLL as
shown in lines 1 through 11 of Fig. 11. Two more assertions are
added to test the behavior of the warning light as shown in lines
13 to 17. The TRUE answers mean that the light behaves as the
designer requires. The assertion in line 19,
AG (-dl & -APB ->AX(dl & -APB -> A F hom))
AG -(hom & lig)
means if the push button is not pressed and, in the next time
instant, the danger signal comes in (dl changes from 0 to l), then
the horn sounds eventually. The model checker answers that this
test is TRUE as shown in line 5. The third assertion
asks whether there is any situation that the horn sounds and the
light is on simultaneously.The answer TRUE means that the hom
and the light are never on simultaneously, which is implied in the
original specifications. All the tests shown in Fig. 11 assure the
user that the alarm system follows the given specifications. This
method does not guarantee anything about the system behavior
which is not asked.
AG(horn -> -E[-APB U (-hom & -APB)])
tests the time period when the hom sounds. The second part of
the CTL expression
-E[-APB U (-horn & -APB)]
April 1994
Multiple-Alarm Systems
The following examples illustrate the performance of the
model checker in multiple-alarm designs. Two different multi-
57
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
I=AG(APB -> AF -horn)
The assertion is TRUE.
I= AG(-dl & -APB -> AX(d1 & -APB -> AF horn))
The assertion is TRUE.
I= AG(horn -> -E[-APB U (-horn 81-Ape)])
The assertion is TRUE.
I=AG(-dl
-> AF(-lig))
The assertion is TRUE.
I
. .
R1
I= AG(d1 & -APB -> AX(d1 & APB -> AF lig))
The assertion is TRUE.
17
I= AG(lig -> -E[dl U (-lig & dl)])
The assertion is TRUE.
18
19
20
I= AG-(horn & lig)
The assertion is TRUE.
Fig. 11. Model checker e.wecution for the revised RLL.
ple-alarm systems are tested: 1) modular system and 2) merged
input variable system. These alarm systems are based on the
previous single alarm system. We will describe the two systems
and compare the size of the computer memory used for their
verification. We use the same assertions applied to the single
alarm system as shown in Fig. 1 1 to test all the multiple-alarm
systems.
q
;:7GP
j
APBi
horni APBi
horni
Ri
Modular System. This system consists of many modules of
the single alarm system as shown in Fig. 12. There is no interaction among the modules. Each variable is connected to its own
hom (or voice) and light. The upper line of Fig. 14 shows that
the computer memory used for the verification grows fast as the
number of alarms increases.
Merged Input Variable System. Fig. 13 shows a different
design of the multiple-alarm system. As shown in the first rung
of the figure, all input variables are connected in parallel and
merged into one variable, det. Other rungs are the same as the
single-alarm system. If any of those inputs become TRUE, the
coil det becomes activated and the hom sounds. This system
requires a smaller state space than the modular multiple-alarm
system. The memory size required to verify this system grows
slowly and linearly as the number of alarms increases as shown
in Fig. 14.
This example demonstrates that the memory size heavily
depends on the RLL structure. The number of states needed to
be checked for the modular system grows almost exponentially
as the number of alarms grows, while the number of states for
the merged system grows linearly.
The CPU time needed to solve these multiple-alarm examples
follows the same trend as the memory size. None of the runs
required more than 30 s with the automatic model checker
running on a DEC 3 100.
Summary of the Method
The integrity of PLC-based control systems depends in part
on the correctness of their software. In the traditional approach
58
-
Fig. 12. RLL for the modular alarm system
to test the software, a series of manual tests is used to find errors.
Simulators are frequently used to test the software formally, but
there is a limit in the number of test cases. We have developed
an automatic verification method to identify errors in RLL, a
popular programming language used in PLCs. The method is:
complete in the sense that it checks all possible cases for the
system being verified,
efficient because it searches the state space symbolically,and
automatic in its determination of the error existence.
This method consists of three components: a model of RLL,
assertions which represent questions about the system, and a
model checker which automatically determines whether the system operates as specified by assertions. The single-alarm example demonstrates that the method is able to express RLL and
assertions and it can find errors. The performance of the model
checker has been tested in a series of multiple-alarm designs. The
IEEE Control Systems
system integrity depends on the user’s interpretation of the
system and has not been automated in this research. Applications
to industrially relevant problems will require
an interface converting RLL in PLCs into a model description
that the model checker can read,
model templates for timers, counters, arithmetic computation,
file handling, and other high level functions, and
a high level language for a user to describe assertions easily.
Acknowledgment
The author wishes to thank Gary Powers and Scott Probst in
Chemical Engineering, Edmund Clarke in Computer Science,
and Bruce Krogh in Electrical and Computer Engineering at
Camegie Mellon University for numerous beneficial discussions.
References
[ l ] J.R. Burch, E.M. Clarke, K.L. McMillan, D.L. Dill and J. Hwang,
“Symbolic model checking: lo2’ states and beyond,” Info. Cornput., vol. 98,
no. 2, pp. 142-170, June 1992.
[2] E.M. Clarke, E.A. Emerson and A.P. Sistla, “Automatic verification of
finite-state concurrent systems using temporal logic specifications,” ACM
Trans. frog. Lung. Sysr., vol. 8, no. 2, pp. 244-263, Apr. 1986.
~
e
~
lig
[3] A.J. Crispin, Programmable Logic Controllers and their Engineering
~
~
Applicurions. New York: McGraw
Hill, 1990.
[4] A. Falcione and B.H. Krogh, “Design recovery for relay ladder logic,”
lig
IEEE Control Syst. Mug., vol. 13, no. 2, pp. 90-98, Apr. 1993.
Fig. 13. RLL for the merged input variable alarm system
[5] Y. Ho, “Dynamics of discrete event systems,” in Proc. IEEE, vol. 77, no.
1, pp. 3, Jan. 1989.
[6] A.J. Laduzinsky, “PLCs develop new hardware and software personalities.” Control Eng.. vol. 37, no. 2, pp. 53, Feb. 1990.
[7] I. Moon, G.J. Powers, J.R. Burch, and E.M. Clarke, “Automatic verification of sequential control systems using temporal logic,” Amer. Insr. Chem.
Eng. J . , vol. 38, no. 1, pp. 67-75, 1992.
10-
8-
[8] J.D. Otter, Programmable Logic Controllers;Operarion, Interfacing and
Programming. Englewood Cliffs, NJ: Prentice-Hall, pp. 75-77, 1988.
6-
[9] D.W. Pessen, “Using programmable controllers for sequential systems
with random inputs,”Proc. Insr. Mech. Eng., vol. 201, no. C4, pp. 245, 1987.
4-
[ 101 L.A. Ready, “Programming PLCs with sequential logic,” Control Eng.,
vol. 38, no. 15, pp. 101-107, Nov. 1991.
2merged system
0-
0
I
10
20
-
I
30
-
I
40
.
I
*
50
,
60
.
I
70
.
,
80
.
90
Number of alarms
Fig. 14. Relationship between the size of state spaces and the number
of alarms.
method currently is limited to the verification of discrete event
systems and depends on the development of process models. In
addition, the generation of appropriate CTL assertions to assure
April 1994
II Moon received the B.S. degree from Yonsei University, Korea in 1983, the M.S. degree from
KAIST, Korea, in 1985, and the Ph.D. degree from
Carnegie Mellon University, Pittsburgh, PA, in
1992, all in Chemical Engineering. From 1985 to
1988 he undertook research at KIST, Korea, in the
development of diverse chemical processes. He did
post-doctoral work at Camegie Mellon in 1992 and
worked at the Centre for Process Systems Engineering, Imperial College, London, in 1993 as a Consultant. His research focuses on developing a methodology for the synthesis and
analysis of chemical process control systems. He recently joined the Chemical Engineering Department at Yonsei University as a Faculty Member.
59
I