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