Modeling, Specification and Controller Synthesis for Discrete Event Systems

Bengt Lennartson, Michael Tittus, Martin Fabian Control Engineering Laboratory, Department of Signals and Systems

Chalmers University of Technology S-412 96 Goteborg

bl,mt,mf@control.chalmers.se

Abstract

Based on some modeling primitives from automata, Petri Nets and Process algebra, an architecture for a general routing and re- source booking problem is presented. The architecture is based on general models for a set of resources, desired routiiig spec- ificatiorzs for a set of objects (products, data packets, vehicles) and a controller that synchronizes the objects utilization of the available resources.

High level graphical routing specifications for the objects are also introduced, together with corresponding Petri nets, in order to simplify the specification of desired routes. Two specific opera- tors, eveit/ s,yricliroiiizatioii and arbitrary orcler including an alge- bra of events, are then used in the formal Petri net specifications.

Keywords: Discrete event systems, automata, Petri nets, process algebra, flexible cells, multi-purpose batch plants.

1 Introduction

An architecture is presented, where general models for a set of re- sources are given together with desired routing specifications for a set of objects. The objects may be products in a flexible yroduc- tion system, data packets in a communication network or vehicles in a traffic coiitrol system. A controller that synchronizes the ob- jects utilization of the available resources is then antonlatically constructed and adapted to the current resource/routing informa- tion. From a user point of view the basic idea is that the objects are to route themselves through the resource system.

The routing specification of each object is assumed to be given initially as a high level routing specification (HLRS). This in- formal specification is then transformed into a PN to be used for simulation, controller synthesis and verification, cf. [7,2, 16, 151. Four fundamental examples of HLRS with their PN interpreta- tions are presented, in order to show typical building blocks when specifying desired routes. The building blocks considered are se- quence, join, split and arbitrary order.

To simplify the formal PN specification two additional operators are introduced, event syiicliroriimtiori and arbitrary order. An al- gebra for these operators is also presented. These operators are of special interest when multiple resources are booked and un- booked. Typically, multiple resources are booked at the same time, which can be expressed by event synchronization, while

0-7803-4778-1 /98 $10.00 0 1998 IEEE 698

they are released (unbooked) in arbitrary order.

As applications of the suggested architecture we have consid- ered cell controllers for flexible manufacturing systems [l, 51 and multi-purpose batch plants in chemical processing industry [16,15]. Both new resources and new products (objects including their routing specification) are then easily introduced and modi- fied. The key function to obtain this flexibility is the controller, which is automatically synthesized to guarantee a live and safe system. Additionally, time-optimal performance can be obtained by applying a scheduling technique based on Petri nets [lo].

2 Parameterized events

In this section we will introduce parameterized events, in order to obtain reusable resource models. This can be done using CCS’s value passing calculus, [12], pp. 53-59. In general value passing is introduced to handle variables in events. For instance, the event receiwe(z) means that a variable x receives a value when the event receiwe occurs. In the case of parameterized events, the value of x is typically the name of a specification process, and the event e(z) is introduced in a general process, which will be used together with different specification processes not known beforehand.

The following two basic rules from CCS’s value passing calcu- lus will be used. They transform process expressions with a free variable x to expressions with constants from a given value set S = {si; i E I } , where I is an index set.

P = a ( x ) . P’(x) = x u ( s i ) P ; (1) % € I

P ( x ) 3 u(z).P’(z) f) Pi = U(8i)G’ vi E I (2)

Example 1 -Parameterized events

Consider the process R = a(z) . R’(z) = a(z) . a(%). R, and assume that the value set S = {si; i E I } , where the index set I = { 1,2}. Then (1) gives

R = U(.). R’(z) = U ( S I ) . R; + u(s,). Rh

and R’(x) = b ( z ) . R is according to (2) rewritten as

RI = b ( ~ i ) . R i E {1,2}

R’

Figure 1: Automaton with parameterized events, and corresponding transformed automaton based on CCS value passing calculus and the index set I = { 1,Z).

This means that

R = U(.). b ( z ) . R = ~ ( 5 1 ) . b ( ~ 1 ) . R + U ( 5 2 ) . b(S2). R

0 The corresponding automata are shown in Fig. 1

In the next section will be demonstrated how the value passing calculus can be applied to reusable resource booking models.

3 Resources and Routing Specifications

An architecture for a general routing and resource booking prob- lem is presented in this section, where

a set of resources are. available. a set of objects (products, data packets, vehicles) are given, each with a desired routing specification.

a controller, which synchronizes the objects utilization of the available resources, is automatically constructed and adapted to the current resource/routing information.

From a user point of view the basic idea is that the objects shall route themselves through the resource system.

This general problem setup can be applied within many different areas such as flexible manufacturing systems, batch process con- trol, tele- and datacommunication, traffic control etc. The first two applications have been investigated for some time in our re- search group, cf. [l, 5, 16, 151. We will therefore relate to these areas when we now discuss some more details on the three main coniponents in the suggested architecture: the resource models, the routirig specifications and the controller.

Resources

For flexible cells in manufacturing industry and multi-purpose batch plants in chemical processing the resources can be divided into two main groups:

Producers, such as machines and welding robots in maw ufacturing applications, or tanks and reactors in chemical plants. A producer refines an object physically or logi- cally, in the latter case e.g. by measuring the object, thus

obtaining increased information about its status. As a gen- eral booking model for such prodiicers we use the DES process

where the event bpk (z) represents ”book producer p, for object x”, and Upk(2) represents ”unbook producer P, for object 2”.

0 Trurisporters, such as conveyor systems, pick-and-place robots and AGVs in manufacturing enterprises, or valves and pumps in chemical plants. As the name indicates, this kind of resources moves objects bletween the producers. As a corresponding transporter moclel the DES process

(4)

p k = b p k (z) . UPk (x) . p k (3)

T k = btk (Z) . Utk(:C) . Tk

is used, where btk(2) represents ”book transporter T k to move object z”, and Utk (z) represents ”unbook transporter T k for object x”.

Routing specification

In general, each product to be produced or imanipulated may have its own route through the resource system. In manufacturing sys- tems this route is represented by an openition list for each in- dividual product, specifying (alternative) mources necessary for the manufacturing of the product. Corresponding routing specifi- cations in chemical batch applications are termed recipes.

The routing specification for each object i is assumed to be given initially as a high level rowtirig specijicatiotz (HLRS), This infor- mal specification is then transformed into a formal DES model Si, in this paper represented as a PN. Four fundamental examples of HLRS with their PN interpretations are presented in Section 5 , in order to show typical building blocks when specifying desired routes. The building blocks considered art: sequence, join, split and arbitrary order.

Con troller

The purpose of the controller is to synchronize the objects uti- lization of common, available resources. It is important for this utilization to be as efficient as possible. Utiriecessary restrictions must be avoided, and as much flexibility as possible be given to the system, without danger of running into blocking states or other forbidden configurations.

Optionally an optimal or suboptimal schedule for the booking of the resources may be desirable. Then also, timing aspects need to be introduced into the models, and the optimization may be performed based on criteria such as minimal due date or mini- mal flow time. Liljenvalt [ IO] has studied this kind of scheduling problem based on models similar to the ones presented in this Paper.

As a first step to obtain a controller, the parameterized resource models are transformed based on the current muting specifica- tions. Assume that a resource Rk is specified to be used by the routing specifications si, where i E Ik, and I k is the index set corresponding to the specifications that utilize resource k. Then the trmisjonned resource model, evaluated by CCS value passing calculus based on the valne set S = {si; i E Ik) and the index set Ik, cf. Example 1, is denoted RP.

699

The transformed resource models are synchronized with the rout- ing specifications. Assume that n specifications SI , . , . , s, are given which altogether use m resources R I , . . . , R,. Then the DES model

is a first specijkation of the desired behavior of the plant s = Sl I I . . . I IS,

P = R:* 11 . . . 11R;-

Here 11 is CSP's full synchronous composition (FSC) [9]. Also note that the specifications Si run independently of each other, since our modeling approach implies that the specification alpha- bets are disjunct. On the other hand, individual resources may be synchronized by common event labels.

The two DES models P and S give together what is called the global specijcariorr

This is a first candidate for a possible controller C, and in fact it is a model of the controlled closed loop system. This model may however be blocking or noncomplete, [13, 171. The first aspect has to do with liveness and the second one is related to uncontrollable events, which we do not consider in this paper.

The global specification Ssp therefore has to be manipulated to result in an appropriate controller. This is formally expressed by the operator NB, which removes blocking states from Ssp to make it trim. Optionally, this operator may also include time optimization, Liljenvall [ 101. The synthesized controller is now expressed as

s s p = PllS (5)

C =NB(SaP) =NB(R:'I). . . IIRLml1SiII.. . /IS,) (6)

The operator Nl? calculates a non-blocking controller [ 13, 171, where the blocking states are removed. This can be done by ex- haustive search where all the reachable states are visited. More efficient methods, based on Partial ordering techniques [SI, are interesting alternatives.

Example 2 - Global specifwation

Two routing specifications SI and SZ are given in Fig. 2, both as HLRSs and as a PN. Models for the five producers to be booked are also included in the PN, which implies that this model is the global specification S,, = PllS (5).

In this example we only specify the order in which the de- sired producers shall be booked. In a following section on HLRS we will also include transporter resources in the spec- ification. Since no buffers are assumed, the next resource in the PN specification in Fig. 2 is booked before the current resource is released.

TO see how the transformation of a resource works, look at Fig. 2. The transformed model of producer PLb evaluated for producer P3, becomes

@ = bps(81). Up3(81). P$ + bp3(sz). ~ps(8z). P,'"

Furthemore, the index set of the five producers are

I1 = {1}, I2 = {l}, 13 = {1,2), 4 = {1,2), 15 = (2)

Figure 2: Two routing specifications Si and Sz are given both as HLRSs and as a PN. Since the models for the five producers to be booked are also included in the PN, this formal model is the global specification Ssp.

The two routing specifications in Fig. 2 including the book- ing models for the five desired producers (the global spec- ification) imply, according to (G), that the controller can be expressed as

4 Algebra of Events

To get more powerful tools for specification of events, especially for high level routing specifications (HLRS), two operators for events will be introduced in this section. Based on CCS, se- quences of events and choices between events are denoted

a. b (sequence) a + b (choice)

Here we take the freedom to exclude the underlying processes, which means that we present an algebra for event expressions (strings) instead of processes. Corresponding process expressions are obvious, and this altemative notation will be useful in the next section where we apply these event expressions to HLRS.

Event synchronization

The first additional operator is eiwiit s.y~icliroriizaiioiz, which may be considered as FSC for events that are not equally labeled. Con- sider two processes P = a . P' and Q = b. &'. A third process S = a & b . S specifies that the events a and b are required to occur at the same time i.e. a and b need to be synchronized. The

700

result of synchronizing these three processes can formally be ex- pressed as

pap1 Q ~ Q I ~ " 3 ~ s ~ PllQllS "ab P'llQ'll~~

From now on we write a & b in string expressions as + and . above, especially for transition labels in automata and PN speci- fications. This concept was suggested by Fabian in [ 6 ] , but then denoted coininon eiwrts. Similar ideas for event synclronization can be fourid in [3,4, 141.

The event synchronization operator & is useful when flexibility and reusubiZity is desired. Take the following example: the is sue is to synchronize the processes P and Q at one moment atid later on P with another process R = c . R'. To specify these synchronizations by FSC it is required to introduce specific event labels for these two different situations in the correspriding DES models. By the suggested event synchronization operator & a specification process S including a & b, later followed by a & c, implies that the resource processes do not need to be modifed. This idea is further illustrated in the next section on HLRS.

Arbitrary order

Sometimes the order between events is not necessarily determined beforehand. Instead two or more events may be allowed to oc- cur in arbitrary order. The only restriction is that all events in such a group must have occured (in any order) before continuing. By standard expressions, this kind of specification becomes quite messy, including all possible alternative sequences of events.

To achieve a clean description, an urbitrary order operator de- noted @ is introduced. In principk

a1 @a2 e.. . @ a,

represents a choice (sum) between altemative sequences, each a permutation of the event sequence a1 . a2 . . . . . a,. For instance

a @ b = a . b + b . a

a@b@c=a.b.c+a.c.b+b.a.c+b.c.a+c.a.b+c.b.a A typical application is two simultaneously booked resources R1 arid Rz. The unbooking of these resources may occur in any order, specified as UTI @UTZ = m-1 . UTZ +UTZ . UTI. Additional examples are given in the next section.

Precedence

The operators above are executed with the following precedence, increasing from left to right,

+_<e<. < &

a + b & c = a + ( b & c )

This implies e.g. that

i.e. either event a occurs, or b and c occur synhronized. The expression a . b & c means that a occurs first and then b and c are syniclronized. Furthermore

a + b @ c = a + b . c + c . b a f 3 b . c = a . b . c + b . c . a

a @ b & c = a . b & c + b & c . a

Figure 3: both as an HLRS and interpreted as a PN.

Routing specification for a straight sequence,

Macro events

Lastly, we note the possibility to replace the atomic events in the expressions above by macro events. That is, a label may itself be interpreted as an event expression. Take for instance the expres- sion a&b, where, say, b -- bl @ bz. Noting that macro event expressions naturally have the highest precedence, we obtain

This macm event option, together with the four basic operators above, make the event algebra suggested jn this section a power- ful means for various kinds of specifications. This will be illus- trated in the next section where HLRSs are interpreted by PNs.

5 High Level Routing Specifications

In this section we will show four fundamental examples of high level routing specifications (HLRS), with their PN interpretations. These examples illustrate typical building blocks when specify- ing desired routes. Corresponding building blocks have been de- veloped earlier in different versions for flexible production, both for manufacturing applications [7, 21, and multi-purpose batch plants in chemical processing [ 16, 151.

The general idea is that the user specifies; a desired route for each object by an HLRS, and then an automatic translation of the HLRS to a formal PN specification can be achieved. The formal specification can be used both for controller synthesis, simulation and formal verification.

In this section we include transporter processes Tk (4). either as a single transporter (typically a robot in a smaller manufacturing cell), cf. Fig. 3, h, or as a unique transporter between each pair of source arid sink producers (corresponding; to the line objects in [ 15]), cf. Fig. 45.

70 1

Figure 4: Routing specification for a join operation, both as an HLRS and interpreted as a PN.

Sequence

A routing specification given as a straight sequence is shown in Fig. 3, both as an HLRS and as a PN. The order in which the producers are used is specified together with the transporter mov- ing the object between the different producers. Since we have specialized the presentation to flexible production systems, the objects are products which are manipulated by the producers and moved by the transporters.

Note that the transporter and the next producer are booked at the same time by use of the &-operator. The reason for this synchro- nization is that there is no idea to book e.g. the next resource before there is a transporter available. On the other hand, the order in which the transporter and the previous producer will be finished is not always known beforehand. Hence, these resources are unbooked in arbitrary order, specified by the operator €B.

Join

When two separate route branches are joined together, this can be specified as in Fig. 4. This join function has two extra places in the middle of the PN, due to the as.ymlirorious behavior of the join operation. The branches do not have to wait for each other before their next common producer P.3 is booked. On the other hand, P3 cannot be booked twice for the same operation. The PN specifies that the first ready branch books both P3 and the corresponding transporter, while the next one only books the related transporter but not 4. As for the straight sequence the producers and transporters are unbooked in arbitrary order.

A s.ymhroizous join operation is easier to specify and can be ob- tained by the following event expression

bp3 & bt13 & btm. (up1 €I3 upz €B ut13 CEI d 2 3 ) (8)

Note that this join function is flexible in the sense that the num- ber of input flows to the sink resource can vary. It is straiglitfor- ward to extend to multiple joins, where the number of inputs is specified only by the muting specification; no modification of the resource model is required.

Sometimes the transporter consists of a group of resources, like

Figure 5: Routing specification for a split operation, both as an HLRS and interpreted as a PN.

a number of valves in a batch plant that all need to be booked to obtain a flow from one tank to another. In such situations the macro event option is useful. Assume that transporter Ti3 needs to book the valves VZ, V5 and V7. Then the event bt13 may be replaced, in the case of asynchronous join, by the expression

bvz @ bv5 @ b ~ 7 (9)

(synchronous join requires a slight redefinition of (8)). This means that the valves are booked when they are available, which reduces the risk for starvation. Such a strategy is suitable when syncluo- nization and deadlock avoidance are the only goals.

If on the other hand an optimal schedule is required there is no reason to book any valve before all are available, since the opti- mization implies that unnecessary waiting is avoided. Hence, for optimization (9) is replaced by the expression

bvz & bv5 & bv7 ( 10)

This quite simple idea, which originally was noted by Liljenvall [ 111, implies a considerable reduction of the total number of dis- crete states compared to (9), where all permutations of the events are modeled, instead of the single synctmnous event in (10). The state reduction becomes even more significant as the number of valves to be booked increases.

split

When an object or flow is separated into two parts this can be specified as in Fig. 5. This split function has an extra place in the middle of the PN, which allows the unbookirig of the producer A and the transporters 7'12 and T14 to be made in arbitrary or- der. In the same way as before the next producer and the related transporter are booked simultaneously by use of the &-operator.

Arbitrary order

Sometimes it is not necessary to specify in which order a set of resources are going to be used. The only restriction is that a group of resources must be visited (in any order) before continuing. An example of this type of arbitrary order specification is shown in Fig. 6.

702

Figure 6: Routing specification for arbitrary order, both as an HLRS and interpreted as a PN.

With the arbitrary order operator 63, the previous producer cannot be determined beforehand. Therefore, a generic event upp is in- troduced in the PN for the event unbookprei,iousproLcer. When all the possible sequences are unfolded in the final specification (an automaton corresponding to the PN in Fig. 6), the previous producer becomes known, and consequently the generic event is replaced by the actual producer unbook event. Note that within an arbitrary order block, specific subsequences can be introduced as in Fig. 6.

G Conclusions

An architecture for a general resource booking problem has been presented, based on reusable models for a set of resources, de- sired routing specifications for a set of objects, and a controller, which synchronizes the objects utilization of the available re- sources. High level graphical routing specifications have also been introduced, together with corresponding Petri nets. Here the two operators everu syrrclrrortiZariori and arbitrary order were shown to be useful.

References

[I] A. Adlemo, S-A Andreasson, M. Fabian, P. Gullander, and B. Lennartson. Towards a truly flexible manufacturing sys-

tem. Cotttrol Engineering Practice, 3(4):545-554, April 1995.

[2] S-A Andreasson, A. Adlemo, M. Fabian, P. Gullander, and B. Lennartson. A machining cell level language for prod- uct specification. In Proc of INCOM '95, pages 118-124, Beijing, China, Oct 1995.

[3] A. Arnold. Finite Transition Systems: Setnuntics of Corn- rnurticuhg Systems. International Series in Computer Sci- ence. Prentice-Hall International, En,glewood Cliffs, NJ, 1994.

[4] R. David. Grafcet: ,4 powerful tool for specification of logic controllers. IEEE Trmis. Control S,ystems Teclitwlogy, 3(3):253-268, 1995.

[5] M. Fabian, B.Lennartson, P. Gullandeir, S.-A. Andreasson, and A. Adlemo. Integrating process planning and control for flexible production systems. In Proc of rlw 4th European Control Corlference, Brussels, Belgium, July 1997.

[6] M. Fabian and B. Lennartson. Petri nets and control syn- thesis; an object oriented approach. In Proc of the 2nd lFAC/lFIP/lFORS Workshop on Iiltelliigent Martufacturing Systems, IMS '94, Vienna, Austria, June 1994.

[7] M Fabian and B Lennartson. Petri net constructs for high level operation lists. In Proc of INCOM'Y5, pages 163-168, Beijing, China, Oct 1995.

[8] P. Godefroid. Partial-Order Methods for tlte verificutiort of concurrent s,yslerns, volume 1032 of Ltpcture Notes in Cotn- puter Science. Springer Verlag, 1996.

[9] C.A.R. Hoare. Cornmurticatirtg Sequeittiul Processes. Ir- ternational Series in Computer Science. Prentice-Hall Ir- temational, Englewood Cliffs, NJ, 1985.

[lo] T. Liljenvall. Job shop scheduling with limited buffers. In Proc. AARTC'Y7, pages 312-313, 'Vilamoura, Portugal, 1997.

[ 111 T. Liljenvall. Schedulling for manufacturing systems. Lic. Thesis, to be published, 1998.

[ 121 R. Milner. Cotntnuriicutiori aid Corcurrericy. International Series in Computer Science. Prenticc:-Hall International, Englewood Cliffs, NJ, 1989.

[13] P.J. Ramadge and W.M. Wonham. Suprvisory control of a class of discrete event processes. SIAM J. Control Optirn., 25(1):206-230, Jan 1987.

[14] C. Stirling. Modal and temporal logics for processes. In F. Moller and G. Birthwistle, editors, Logics for Concur- rency: Structure versws automata, pages 149-237. Springer Verlag, 1996.

[15] M. Tittus and B. Egardt. On the use of multiple models and formal control synthesis in batch conitrol. In Proc of tlte IFAC World Congress, pages 301-306, San Francisco, CA, July 1996.

Controlling and coordinating recipes in batch applications. In Proc of the 34th IEEE Conference on Decisiori urd Corttrol, pages 2484-2489, New Orleans, LA, Dec 19195.

I171 W.M. Wonham and P.J. Ramadge. On the suprema1 con- trollable sublanguage of a given language. SIAM J. Control Optirn., 25(3):637459, May 1987.

[16] M. Tittus, M. Fabian, and B. Lennartson.

703