APPLYING SUPERVISORY CONTROL THEORY TO DISCRETE EVENT SYSTEMS MODELED BY OBJECT ORIENTED PRINCIPLES

APPLYING SUPERVISORY CONTROL THEORY TO DISCRETE EVENT SYSTEMS MODELED BY OBJECT ORIENTED PRINCIPLES M. Fabian, B. Lennartson Control Engineering Laboratory Chalmers University of Technology S-412 96 Göteborg Sweden fabian@control.chalmers.se fax: +46 31 772 3730 Abstract. Implementation of complex discrete event manufacturing systems can be considerably simplified by use of general reusable software modules, representing the physical components. At the same time, construction of the control system can be facilitated by use of formal methods for automatic generation of the control laws. These two aspects can be joined into a general concept with object oriented modeling and control law synthesis as foundations. The goal is to allow an operator to specify the product routes through the system, for each type of product, irrespective of any other type of product that may be simultaneously present within the production system. Control laws guaranteeing production according to those product specifications can then be synthesized, given the model of the system. We will describe such an object oriented modeling approach to discrete event manufacturing systems. Based on the supervisory control theory, using interleaved product routes as specification, it is shown how control laws can be synthesized. An added complexity is that such a specification becomes nondeterministic in the sense that the same string of events can lead to different system states. We have shown that the supervisory control theory can indeed be used with nondeterministic specifications, but also that the notion of controllability is not strong enough to guarantee an implementable supervisor. Keywords. Flexible Manufacturing, Finite State Automata, Supervisory Control, Object Oriented Modeling 1 INTRODUCTION Manufacturing and assembly systems are becoming larger and more flexible as the demands for costumer oriented production increases. When implementing control of production systems there has to exist high level support for modeling. Object oriented modeling has shown to be a valuable tool for structuring complex systems and easing their implementation by providing general software components reusable in different applications with little or no alteration. In a flexible production system there is also a need for distributed product specification. Each product is an autonomous entity coexisting with other products simultaneously present within the system. However, we can certainly do without the added complexity of having to specify independent product routes with regard to other products that may be existing at the time of production. It is favorable to be able to specify a distinct product route irrespective of any other products, and have some underlying system tie it all together. However, both of the aspects of modeling and specifying product routes have to be supported by a ridgid foundation of formal methods. Given a model of the system and a number of independent product specifications, together with other specifications on the systems behavior, control laws has to be synthesized. These control laws must be proven correct. Since a manufacturing system can be regarded as discrete event process (DEP) this foundation can be found in the supervisory control theory (SCT) initiated by Ramadge and Wonham. Being a relatively new discipline within control theory, DEPs have attracted much attention both in the systems modeling area and within the control-law synthesis field. Shlaer (1992), Fabian (1992), Adiga (1993) all described modeling methodologies based on object-oriented approaches. Ramadge (1987) and Wonham (1987) have, with the SCT, provided a unifying framework for synthesis of control laws for DEPs. Kumar (1991) and Balemi (1992), among others, have proposed their own variation of the SCT, based on a different interpretation of the interaction between the controlling and the controlled processes. Giua (1992) bases an approach on Petri nets. However, until now there has been very little work done in merging the two domains of object-oriented modeling and supervisory control synthesis. In this paper 1 we will show how an object-oriented model of a flexible assembly system can be used with the SCT. The object oriented modeling approach builds on the ability to identify and extract the general behavior of production resources into reusable software models, one for each different class of manufacturing device. These reusable models offer generalized functions on a high abstraction level, using lower level, specific instruction sequences to implement that behavior. In this way the synchronizing aspects of the required control will be separated from the control of the actual devices. The general, high level functionality is represented by message driven DEPs. The messages being modeled as events. Thus, the plant to be controlled consists of a number of independent (but possibly coupled) DEPs, operating concurrently. The specification of the product routes will likewise be given as DEPs. Each type of product can be specified without regard for any other product simultaneously present within the system, even though they may require use of the same processing equipment. The product routes thus specified 1 supported by the Swedish National Board for Industrial and Technical Development (NUTEK) under project 90-01076 P Applying Supervisory... 1 M. Fabian, B. Lennartson

encompass a subset of the events offered by the plant, not necessarily disjoint between different types of products. The concurrently executing product routes can thus be seen as a specification for the plant to exhibit a certain behavior, and it is up to some underlying control system, the supervisor, to see to it that this behavior is actually accomplished. To synthesize a globally optimal supervisor the individual product route specifications have to be composed into joint specification on the overall system. However, the products are to run asynchronously with respect to each other, though synchronously with respect to the plant. Thus, the sharing of the machining resources by the products will be modeled by interleaving, Hoare (1985). In Fabian (1994) is shown that the SCT is valid for the certain class of nondeterministic specification arising in systems as described above, that a supervisor does exist and is algorithmically constructable. The resulting system contains three basic types of objects all described as DEPs; internal resources that are models of the actual machining equipment; product individuals that model the physical workpieces; and a controller that controls the behavior of the system, so as to have the products satisfactorily produced. The controller operates within the boundaries set by the supervisor, since the supervisor expresses all allowable routes through the system, satisfying the specifications. This paper begins with a brief introduction of the example system, followed by a short description of the object oriented modeling approach in general, and its application to the example system. Then some aspects of distributed product specification is discussed, and two products to be produced by the example system are introduced. Finally, the SCT algorithm is briefly described, and applied to the example system. The presented solution will by no means be exhaustive. For instance, the robot is not modeled. However, we feel that this paper gives a reasonable indication on how object oriented modeling and the SCT can be used in practice. 2 THE EXAMPLE SYSTEM The example system is shown schematically to the right in fig 2.1. It consists of an input buffer, a lathe, a mill and an assembly unit, which are the resources that we will regard here. The system also contains a robot for loading and unloading the production resources and an operator station for supervising the production. In fig 2.1 is also shown a bar code reader that registers incoming works. The input buffer, M1, has a limited capacity of one product at a time. Products are loaded onto M1 on request, by some external source which is not modeled and considered to be infinite. From M1 the products are transported to either of the resources, depending on the specification of the product route. The assembly unit, M4, takes two different products, loaded one at a time, assembles them and emits one product to some external sink outside the system. As with the external source, the external sink is likewise not modeled, and considered to be of infinite capacity. The lathe, M2, and the mill, M3, can both handle only one product at a time. Bar Code Camera Operator S tation Lathe Conceptual model PI PI Input S tation Mill Control System Robot PI Assembly Assembly Physical reality Lathe Fig 2.1 Object oriented model of a flexible assembly cell. Note that this is purely an imaginary system, carefully chosen so as to illustrate the core of the concepts described in this paper. However, the example system has many things in common with real life flexible manufacturing and assembly systems. 3 OBJECT ORIENTED MODELING For the generation of any type of control system, a model of the system to be controlled is needed. It is favourable for this model to lie as close to the physical representation as possible, yet encompass as little information as necessary of the real life system. A manufacturing system involves a number of independent manufacturing devices interacting to perform useful work. Object oriented modeling caters for abstraction by encapsulating data and behavior. It also modularizes the modeled system in a natural way by resulting in an object structure close to the physical structure. The objects are independent software modules interacting by messages, in much the same way as the modeled physical entities. 3.1 Internal Resources The internal resources are autonomous reusable software models, each described as a DEP. The reusability emanates from the fact that machining devices can be described by their general behavior on an abstract level. On this level application-specific details are not visible, which is a crucial requirement for the generation of reusable software components. However, the functionality promised by the abstract level, the general, has to be implemented somewhere. Therefore, each resource also has a specific that interacts with the general. This specific is tailored to the requirements of the actual physical device in the specific application. Thus, control over the physical device is routed through the corresponding internal resource. Operating concurrently the internal resources constitute the plant to be controlled. This concurrenty execution is modelled by full synchronous composition (FSC) of the internal resources, see Hoare (1985). Thus, internal resources can be coupled Mill Applying Supervisory... 2 M. Fabian, B. Lennartson

and are able to synchronize over mutual use of tools, for instance. Messages Internal resource General General Specific Specific External resources Fig 3.2 Each internal resource consists of a general and a specific, thus separating the control of the assembly process from the control of the individual devices. General s, representing generic production resources such as a milling device and an assembly unit, are given in fig 3.3; in this case in the form of Petri nets, see Peterson (1981). More elaborate resource models can be found in Gullander (1994). These must be considered more realistic than the ones presented in fig 3.3. We can also note the work of Tittus (1995a), were reusable resource models are given for control of chemical batch processes. system at M1, while AB and CD represent the finished products. The C and D products are not processed upon, other than in the assembly unit, M4, while the A and B products are operated upon by the lathe, M2, and the mill, M3, respectively. The exact specifications for these operations are given as parameters hidden within the boxes of fig 4.4. Note that these parameters can represent an entire program for a numerically controlled production resource, if necessary. However, for the control of the overall assembly process, the nature of the operations being performed within each resource is not important, merely the sequencing between the resources is regarded. Fig 3.3 M1 represents a general production unit, such as a lathe or a mill. M4 represents a general assembly unit. 4 DISTRIBUTED PRODUCT SPECIFICATION Products are also modeled as a DEPs. Each product specification describes a number of alternative desired routes through the system. It is thus natural to view a product as a specification on the manufacturing process to exhibit a certain event-sequence. However, there can be several independent products using the plant simultaneously. All of these together form a joint specification on the system s overall behavior. So as not to overburden the user with an overly detailed knowledge of the system, it is important that there exists support for high level distributed specification of the product routes. Fig 4.4 Distributed high-level specification of desired product routes. M1 represents the entry buffer, while M2 and M3 denotes the lathe and the mill, respectively. M4 is the assembly unit. Note that all products use M1 and M4. The distributed high-level specifications can, together with a model of the plant, be translated into DEPs, describing the desired product routes in a context applicable to the SCT. In Tittus (1995b), is shown a detailed example of this, relating to chemical batch processes, but this approach is equally as appropriate for manufacturing and assembly systems. The resulting low-level distributed specifications are given in fig 4.5. The indices of the events denote the respective resources. 4.1 High Level Product Specification The preferred way to specify product routes is graphical. The operator focuses merely on what operations to perform and in which order. A graphical layout is well suited for a computerized tool with a graphical interface. In Fabian (1995) is given a number of high level operators for specifying product routes in manufacturing systems modeled by object oriented principles. For the example system two product routes are given in fig 4.4. The two products, AB and CD, are assembled from A and B, and C and D products, respectively. Thus, A, B, C and D represents raw material entering the Fig 4.5 A Petri net describing the desired routes for the products of fig 4.4. 4.2 Interleaving The products use the functional capabilities of the resources that constitute the plant. These functional capabilities are modeled as events, so that all product specifications have event sets that are subsets of the Applying Supervisory... 3 M. Fabian, B. Lennartson

plant alphabet. Thus, it is not uncommon for products to have mutual events, on the contrary, see fig 4.5. At the same time, for maximal utilization of the plant, all products must be able to run as unconstrained by all other products as possible. Given distributed product specifications, a joint specification on the overall systems behavior is obtained by composing the independent product specifications by interleaving. The concept of interleaving is described by Hoare (1985). Essentially, interleaving means that two DEPs can execute their events asynchronously and irrespective of each other, even though there may exist mutual events. In fact, interleaving explicitly prohibits synchronous execution of any event. Thus, at each time instant the total system behaves as either of the DEPs, and at no times will two DEPs engage in the same action synchronously. This generates event sequences of the total system that is the interleaving of the event sequences of the respective DEPs. Thus, fig 4.5 really shows the interleaving of the distributed product specifications of the example system. The interleaved product specification of all simultaneously present products will be denoted Sp. Each product specification is deterministic in the sense that no two simultaneously possible transitions are labeled by the same event. When interleaving, however, this is no longer guaranteed by Sp, due to the fact that multiple product descriptions may have equally labeled simultaneously executable transitions. Thus, Sp is nondeterministic. This nondeterminism arises naturally, given a number of independent resources and distributed specification of products to be manuafactured by these resources. However, this nondeterministic specification is also an added complexity in regard to the SCT, which originally only considered deterministic plant and specification. In Fabian (1994) is shown how the SCT can be extended to handle the case of nondeterministic specification. 5 SUPERVISORY CONTROL A supervisor is a DEP that operates in synchrony with the plant, influencing the plant so as to have the closed-loop system of plant and supervisor exhibit a pre-specified desired behavior. For our purposes, the FSC adequately models the interaction between the plant and the supervisor. The plant will be regarded as a generator of events; all events occur as a consequence of some action within the plant. Thus, the supervisor is confined to restrict the actions of the plant by disabling events as the system executes. With the FSC this disabling is a matter of the supervisor not defining events at each closed-loop system-state. Note that in different closed-loop system-states different events can be disabled. However, not all events generated by the plant can be disabled by the supervisor. The alphabet of the plant is itioned into two disjoint event-sets, the controllable and the uncontrollable events. The controllable events can be influenced by the supervisor so as to occur or not to occur. The uncontrollable events are, on the other hand, not subject to influence by the supervisor; the plant can generate any of these whenever it occupies a state from which an uncontrollable event is valid. For the supervisor not to become out of sync with the plant, it is imperative that the supervisor is able to follow all uncontrollable events that can be generated in each closed-loop system-state; the supervisor must be complete with respect to the plant. It may be desirable for the closed-loop system to always be able to reach some significant state, for instance, the state denoting completion of production with all recipes satisfactorily manufactured is such a desired state. For this, the specification includes marked states. The closed-loop system should be trim, that is, any event sequence should be completable into a marked state. This ensures that the specification can always be upheld. 5.1 Global Specification Sp contains all possible interleavings of the desired product routes through the system. Not all of these interleavings are physically possible, though, due to the configuration of the plant, P. In fact, Sp does not fully describe the desired behavior of the plant. This is so, because some events of P are not in the alphabet of Sp, and thus the plant can execute any of these whenever in a state to do so. Fig 5.6 The global specification P Sp expressed as a Petri net. Note that, for clarity, the places corresponding to M4 have been duplicated. To retain only the physically possible and desired routes, Sp is synchronized with the plant under FSC. That is, the global specification P Sp is generated, see fig 5.6. This guarantees that only physically possible routes are expressed, and it also guarantees that the desired behavior, expressed by P Sp, is a restriction of the possible behavior, expressed by P. However, in the global specification some combinations of product routing will inevitable block the system from ever reaching a state where all products have been satisfactorily completed. For instance, in fig 5.6 it is clear that allowing two consequtive C products to enter the system will indefinitely prohibit the assembly Applying Supervisory... 4 M. Fabian, B. Lennartson

of any product. Thus, some combinations of product routing must be prohibited, and this is a task of the supervisor. 5.2 Event Connection The algorithm of Fabian (1994) concerns finite state atomata. Therefore, the (finite) state automaton representing the DEP P Sp, that is, the reachability graph of the Petri net of fig 5.6, must be generated. Naturally, this requires the Petri net to be marked. Since P Sp of fig 5.6 is a bounded Petri net, this can be done, see Peterson (1981). The number of states of P Sp is considerably smaller than the number of states of Sp, primarily because the number of physically possible routes through the plant is limited. This is one of the reasons for first using some higher level description of DEPs, like Petri nets, to express P, Sp and P Sp, and then generating a state automaton representation of P Sp. Notice that we have not modeled any transporting resource, that is robot. Because of this, some places, and hence states, of P Sp of fig 5.6 represent transport of products between two resources. For instance, a token in the C2 place of fig 5.6. Thus, whenever a product occupies such a state no other product can be picked up for transport by the same transporting device. In the example system there is only one robot, and hence, after a c 1 event, no other exit event can in practice occur for any resource. Which means that the c 1 and the y 4 events surrounding the C2 place are the same event. We say that these events are connected. This event connection can be seen as a task unspecific specification (see Balemi (1992)), and is a consequence of the fact that we have autonomous resources with mutually disjoint alphabets. Event connection is enforced by removing transitions in the state automaton representation of P Sp. In Fabian (1994) it is shown that this is valid, since it generates a subprocess of P Sp from which a valid supervisor for P can be synthesized. Note that event connection is much simpler to do in a state automaton representation that in Petri net form. There may be raised arguments against event connection, since this essentially regards two (or more) distinct events as equal. However, with reusable autonomous resources, we have found no other way around this problem. The approach of Banaszak (1990) does away with event connection by altering the resources with respect to the products, incorporating specific events for each product. Each product specification then has its own set of events disjoint from all others. Consequently, the resources include information of the products present within the system, and so are not reusable. Moreover, Banaszak (1990) only consider deadlock avoidance and so has no need for modeling the resources other than the two states occupied or free. We feel the need for more elaborate specifications and so have adopted the SCT for its ability to express, and fulfil, specifications on forbidden and/or desired states and/or routes, together with its extension to uncontrollable events. A transporting device with specific events for loading unloading each resource, would also not be reusable. And modeling a general transporting resource, with its own event set, disjoint from the other resources would again require events to be connected between the transporting resource and the production resources. We regard event connection as a general concept, only dependent on the physical connectivity of the plant, not on the desired product routes. 5.3 The Supervisor The synthesis of a supervisor is an iterative process, no general closed form expressions exist. In the approach described by Fabian (1994) a supervisor is a subprocess of final specification. A subprocess is a DEP with its structural apperance contained within the superprocess. A subprocess can be generated from a given process by removing states and transitions between states, but the alphabets of the two processes are the same. In generating the supervisor, a complete and trim subprocess of the final specification is synthesized. Naturally, there may exist several solutions to the problem of finding a complete and trim supervisor for a given plant. However, an additional requirement is to find the supervisor allowing the largest possible behavior, that is, the supervisor is required to be minimally restrictive. Since the supervisor is an exact model of the plant under supervision, it is clear that the minimally restrictive complete and trim supervisor is the maximal complete and trim subprocess of P Sp. A formal description of the supervisor synthesis algorithm is given in Fabian (1994). Usually the number and types of the resources are constant and known, while the number and types of products is time-varying. New products are initiated and old ones terminate, asynchronously and independently as the work progresses. Thus the total number of products, and their routes through the system cannot be known a priori. For the sake of flexibility we must allow any possible route through the system. To cope with this we note that though different initial-states of one and the same automaton describe different languages, the formal properties of interest to the SCT are not altered. Because of this, we can start up the system with just a few product routes and when new orders for more products arrive, we interleave the new routes in their initial-states with the old routes in their current state. The resulting joint specification is then composed with the plant in its current state, and a new supervisor can be calculated. Even as product routes terminate, this calculation can be performed so as to minimize the number of concurrently running products. The supervisor is a state automaton expressing all physically possible and allowable routes through the Applying Supervisory... 5 M. Fabian, B. Lennartson

system, given the product- and the task unspecific specifications. It is within the boundaries set by the supervisor that the system will be driven by the controller. 5.4 The Controller We have carefully avoided defining the controller, mentioned above. This is for the reason that there are many ways to interpret the controlling entity, and they all come down to the question of event generation. Who sends which message when and to whom? That is, who generates which events and who follows? Assume that there are four entities present within the system; the plant P, the interleaved product routes Sp, the supervisor S and a controller C. Assume further that the controller generates all events, and that the supervisor only restricts event generation to physically possible and allowable events. Thus, control of the system is exercised by C in synchrony with S. An interesting question is now if C can be favorably expressed in terms of some or all of the other three entities. Having Sp only as the controller is no option since Sp does not include all plant events. The SCT normally regards the plant as generating all events. The supervisor merely follows and restricts the event generation. This is the philosphy we have adopted in generating the supervisor. In such a case, Sp would be of no importance since it is included in S, and P would in fact be the controller. However, this makes it impossible for the products to synchronize, even though there is formally no problem with this. Balemi (1992) regards the supervisor as generating some events, the commands, and the plant as generating other events, the responses. It is shown that the commands can be equated to the controllable events, while the responses are equal to the uncontrollable events. Furthermore, Balemi shows that the supervisor and the plant has to be mutually complete so that the supervisor only generates events for which the plant is ready. In our case, since S is derived from P this is always the case. Thus, C would be the synchronous composition of plant and supervisor. But, it can be shown, see Fabian (1994), that this is in fact equal to the supervisor itself. With this we feel that it is quite acceptable to view the supervisor itself as generating all events. This makes it possible for the products to include their own synchronizing events, and the need for a separate Sp is gone. However, though P is also included in S, the internal resources are still necessary as gateways to the physical resources. Note though, that this view is not consistent with Ramadge (1987). The system controller requests loading of M1 with specific types of products as appropriate. Thus, the event a 1 of the supervisor represents different messages depending on the achieved state change. At times the supervisor expresses nondeterministic choices of products to load, but the controller would have to choose, taking into account aspects like fairness, due dates, etc. The optimal choosing between nondeterministic routes may be a complex task, the implementation of which is outside the scope of this paper. 6 REFERENCES Adiga, S. (ed.), (1993). Object-Oriented Software for Manufacturing Systems, Chapman & Hall Banaszak, Z.A., B.H. Krogh, (1990). Deadlock Avoidance in Flexible Manufacturing Systems with Concurrently Competing Process Flows, IEEE Trans. Robot. Automation., Vol. 6, No. 6 Balemi, S., (1992). Control of Discrete Event Systems: Theory and Application, Ph.D. Thesis, Swiss Federal Inst. of Tech., Zürich, Switzerland Fabian, M., B. Lennartson, (1992) Control of Manufacturing Systems; An Object Oriented Approach, INCOM 92, Toronto, Canada Fabian, M., B. Lennartson, (1994). Object-Oriented Supervisory Control with a Class of Nondeterministic Specifications, 33rd CDC, Buena Vista, Florida, USA Fabian, M., B. Lennartson, (1995). Petri Net Constructs for High Level Operation Lists, INCOM 95, Beijing, China Giua. A., F. DiCesare, (1991). Supervisory Design Using Petri Nets, 30th CDC, Brighton, England Gullander, P., M. Fabian, S-A Andréasson, B. Lennartson, A. Adlemo, (1995). Generic Resource Models and a Message Passing Structure in an FMS Controller, ICRA 95, Nagoya, Japan Hoare, C.A.R., (1985). Communicating Sequential Processes, Prentice-Hall Int. Kumar, R., V. Garg, S.I. Marcus, (1991). On Controllability and Normality of Discrete Event Dynamical Systems, Systems & Control Letters 17 Peterson, J.L., (1981). Petri Net Theory and the Modeling of Systems, Prentice-Hall Int. Ramadge, P.J., W.M. Wonham, (1987). Supervisory Control of a Class of Discrete Event Processes, SIAM J. Control & Optimization, Vol. 25, No 1 Shlaer, S., S.J. Mellor, (1992). Object Lifecycles, Modeling the World in States, Yourdon Press Tittus, M., B. Egardt, B. Lennartson, (1995a). Plant and Product Models for Batch Processes, submitted to ECC 95, Rome, Italy Tittus, M., M. Fabian, B. Lennartson, (1995b). Controlling and Coordinating Recipe in Batch Applications, submitted to 34th CDC, New Orleans, Louisiana, USA Wonham, W.M., P.J. Ramadge, (1987). On the Supremal Controllable Sublanguage of a Given Language, SIAM J. Control & Opt., Vol. 25, No 3. Applying Supervisory... 6 M. Fabian, B. Lennartson