Controlling and Coordinating Recipes in Batch Applications Michael Tittus Martin Fabian Bengt Lennartson Control Engineering Lab, Chalmers University of Technology S-412 91 Goteborg, Sweden e-mail: mt/fabian/bl@control.chalmers.se 34th CDC, New Orleans, USA, 1995 Abstract Starting with a model of the plant and a number of product specications (recipes), a formalism is presented to design a discrete supervisor that controls and coordinates the simultaneous execution of these recipes. The paper introduces general, reusable Petri net blocks used to model recipes and uses an extension of the Wonham-Ramadge framework to synthesize a supervisor. Introduction A batch process involves a sequence of operations that are carried out on a discrete quantity ofmaterial within a piece of operating equipment. Given a plant and a device independent general recipe, all possible ways the plant can be utilized to produce the desired product are generated through static resource allocation [1]. This set of possible solutions is called the master recipe. In each solution of the master recipe, each operation is associated with some unit in the plant. The purpose of this paper is to (1) present amodeling framework for generic process operations, (2) formulate the synchronization issues occurring when transferring material between dierent units and (3) discuss how a discrete supervisor that coordinates the simultaneous execution of a number of recipes within one plant, can be synthesized from the master recipes and a model of the plant. For related work and an overview of the state-of-the-art we refer the reader to [2]. In [3] a set of discrete event processor (DEP) modelclasses for the dierent resources has been proposed. These model classes are very general. When modeling aplant, instances of these classes are created by giving each plant resource a set of unique events. Operating concurrently, the resources constitute the plant to be controlled. With the plant thus modeled and the master recipes for the products to be produced in parallel, already generated, sequential creation of the following recipes leads to the synthesis of a supervisor. Synchronizable Master Recipe (SMR): As a rst step, each master recipe is translated into a Petri net (PN). Dierent operations are expressed as places, with transitions indicating the beginning Research supported by the Swedish Research Council for Engineering Sciences (TFR) under the project number 92-185. and end of each operation. Each transition t in the SMR is labeled with those resource events (plant events) that need to be red simultaneously (i.e. that need to be synchronized) with t for the recipe to progress properly and achievethe desired behavior. The SMR can be created by assembling instances of generic PN building-blocks. Each such building block when instantiated controls either an operation or a material transfer. Interleaved SMR (ISMR): Next, the transition events of the SMRs of all recipes that are to be executed in parallel, and thus compete for resources in the plant, are interleaved with each other. This results in a nondeterministic PN that describes all thinkable intermixings of the recipes. Thus, all recipes to be processed by the plant are included in this PN. We note that no physical restrictions like exclusive use of the resources are yet taken into consideration. Control Recipe: The synchronization of the ISMR with the resource automata results in the control recipe. Here, the ISMR is reduced to all the physically possible intermixings of the recipes by considering the fact that each resource can only be used by one recipe at a time. Supervisor: Finally,using a version of supervisory control theory (SCT) introduced by [4], the control recipe is further reduced by removing those places and transitions that can lead to a violation of the non-blocking and safeness properties (see [5] for a denition). This guarantees that all recipes can be executed all the way without violating any constraints. Modeling Resources Each plant consists of a number of equipment devices, called resources. All the possible resources are organized as a hierarchy of classes in a library, in which each modelclass inherits all the features of the class one step up in the hierarchy. For our purposes it suf- ces to dene the top class of this hierarchy as the class of resources, which comprises any kind of process equipment. On the next level we divide the resources into two sub-classes, processors (units) and transporting devices.
In [3] general, DEP models for processors and transporting devices (exemplied here by valves) have been introduced. They are shown in Fig. 1. Each processor and transporting device has a number of control states and a unique event alphabet. Whenever an object is created as an instance of its class, a set of unique events are assigned to the object by adding the modeled resource's ID as an index to each event. For a detailed discussion of these models, see [3]. (b) (a) bp op unbooked ubp wait wp operate c ub bk blocked_1 bk open o closed b unbooked ubk ubk blocked_2 Figure 1: DEP model of a processor (a) and a valve (b) A special class of processors are buer tanks, labeled B i. They contain raw material and are assumed to be innite in content. Since these tanks have no function other than to supply material, it suces us to model these tanks as simple on/o valves. When moving material from one processor to another, a number of valves have tocooperate to open and close certain connections. Thus, a higher-level class containing transporting devices, called connecting line or simply line, is created (Fig. 2). A line is an abstract object that has purely supervisory functions. For each possible connection between any two processors, a line object can automatically be created from information about the plant's topology. It serves as a kind of mediator, booking and coordinating the dierent valves needed to open and close a connection. At the event blij, meaning \book the line between units P i and P j ", the line object books or blocks the dierent valves needed for controlling the connections, as soon as they become available. Avalve V k, for example, is booked, if event b k can be triggered in both the line DEP and the DEP representing V k. This is automatically achieved by synchronizing the line DEP with the valve DEPs. When the line is ready and set, event lokij (\line ij ok"), it is by default closed. When opening and closing the line, the corresponding valves are opened or closed, respectively. Event lubij initiates the unbooking of the line and its associated valves. From Master Recipe to SMR The goal of this section is to transform the set of recipes called the master recipe into a PN that can be synchronized with the plant. We shall show that it is possible to create general PN building-blocks representing operations and dierent join constructs, which can be assembled to build synchronizable recipes. { ub,...,ubk } m n lub ij b m... unbooked bl ij lok ij bk n operate cij closed o ij open Figure 2: DEP representation of a connecting line Building blocks that translate the following ve basic functions will be proposed here: operation: dierent phases applied to a part of the batch primitive move: possibility of moving a batch from one unit to another asynchronous join: independent merging of two parts of a batch synchronous join: parts of a batch coordinated merging of two add: adding material into a unit that already contains part of the batch Transforming Operations An operation is a major processing sequence applied to the whole or a well-dened part of the batch. Each operation has to be executed within only one unit and no two operations can be applied to the same part of the batch. An operation consists of a set of dierent phases that can be executed in sequence or parallel. They start at a well-dened initial state/set of states and are supposed to terminate in some nal (set of) state(s), satisfying a number of constraints on the way. For our SMR it suces us to represent each operation as a single place in a PN. Whenever a token is placed in this place, a local, hybrid supervisor belonging to the current unit and synthesized according to the hybrid supervisory control theory (HSCT) introduced in [6] and [7], is taking control. Its purpose is to transfer the system safely from its current initial system-state to some nal state. As soon as this nal state is reached, the transition exiting from the PN place is enabled. Figure 3 shows the reusable building block representing an operation. Places denoting local, hybrid supervisors have a double contour (S 1 ). Furthermore, all building blocks start and end with an event setting the unit into control state wait. This makes it possible to easily connect the dierent building blocks, a wp event being the common transition. In [6] HSCT is used to nd one possible sequence of system modes (a path) that transfers the system from an initial to a nal state. In batch applications
wp i op i S 1 wp i Figure 3: PN building block of an operation it is more probable that there only exists one desirable path and the task is to generate a correct control law for this path. The reusable building blocks determine which plant events have to be red and when, i.e. in which sequence. Whenever a local supervisor is connected to an input arc of a transition, e.g. the second transition wp i in Fig. 3, this transition is enabled by the supervisor. All events in the building blocks carry generic labels, which in turn have indices that uniquely associate each label with some generic resource. For the operation building block, the generic event op i carries the identication number of a generic unit P i. If the building block is inserted into a recipe and associated with a unit, say P 1, the index i is set to 1, resulting in an event op 1. An event by the same name exists in the DEP model of unit P 1 (see Fig. 1a), thus forcing a synchronization of recipe and resource. Booking of Resources All resources have to be booked by a recipe before they can be utilized by that particular recipe. For the representation of an operation this has no consequence since we already assume the batch to be contained in the unit. All other basic PN building blocks, however, are concerned with transferring material from one unit (source) to another (target). Before any material can be transferred, the target unit, together with the line that connects the two units, needs to be booked by the recipe. A line is only booked when both the target and source unit have already been secured by the recipe. This guarantees the line's availability and avoids the occurrence of circular waits on the line/unit level. The building blocks in this section assume a booking strategy that waits as long as possible before initiating the booking of a resource, i.e. last-minute-booking. This strategy is also included in the building blocks. Synchronous Booking of Connecting Lines. Assume that the contents of two units, P 1 and P 2, are supposed to be merged into unit P 3. Two lines, namely P 1 P 3 and P 2 P 3, need to be booked by the same recipe. Assume further that both lines need to either book or block the same valve, say V k. Since the opening and closing of both lines can be controlled by the same local supervisor, it can be assured that the common valve is opened and closed correctly and this kind of double-booking is allowed. We distinguish between three cases: Both lines need to block V k : No competition arises, since blocking a valve does not book it. Both lines need tobook V k : V k has to be booked by the recipe, since access to the valve's states open and closed is needed. The two line-events denoting the booking of V k are synchronized, i.e. they are treated as only one event and red simultaneously (see Fig. 4, case 1) and V k is put into control state closed. The two lines need to block and book V k, respectively: Valve V k is booked by the recipe. This is done by changing the label bk k to b k and then treating the two identically labeled events as one event asabove (seefig.4,case2). bl ik b m... b k b k... lok ik bl jk bk n lok jk bl ik b m... b k f bk... lok ik case 1 case 2 join( k ) Figure 4: Synchronous Booking of Lines bl jk bk n lok jk In the last two cases, the recipe has to resolve the competition for the valve and guarantee that only one line is opened at a time. More formally: Let 1 3 and 2 3 denote the event alphabets of line automata P 1 P 3 and P 2 P 3 respectively and let join = 1 3 [ 2 3. Then we dene a relabeling function f join : join! join for 2 join such that f join () = bi if = bk i ^ b i 2 join if otherwise As a result of this possible competition for transporting devices, we distinguish between two ways of booking resources in connection with join constructs: synchronous booking and asynchronous booking. Synchronous booking implies that both lines have to be booked at the same time and has to be applied when both lines compete for the same transporter. Otherwise, asynchronous booking can be employed, i.e. both lines are booked independently of each other. For all synchronous joins, synchronous booking is used (SS) while asynchronous joins can be associated with synchronous (AS) or asynchronous (AA) line booking, depending on whether or not there is a competition for transporting devices. General Building Blocks for Material Transfer Each transfer of material requires at least three resources: a target unit, one or more source units and connecting line(s). As soon as all involved source units are ready for material transfer, the system goes through the following steps: (1) Booking of target unit and corresponding lines, (2) preparation of target unit (preprocessing), (3) the actual material transfer, and (4) the post-processing (e.g. cleaning) and unbooking of all source units. To be able to eciently model a general building block, we rst need to dene some operations on PNs.
Dierent Synchronization Operations. The full synchronous composition operator PN 1 k PN 2 models the interaction of two concurrently executing PNs, PN 1 and PN 2. This interaction requires simultaneous participation of all the involved nets on mutually labeled transitions. The interaction between the recipe and the plant is modeled by means of the uni-directional synchronous composition (UDSC). The UDSC PN 0 j U fpn 1 :::PN n g denes an operation between a slave Petri net PN 0 and a set of master PNs fpn 1 :::PN n g with disjoint alphabets i i=1 :::n and unique transition labels, i.e. each transition is associated with a unique event. The slave Petri net's alphabet consists of ordered tuples 0 1 2 ::: n. Events belonging to one tuple are considered to be connected, meaning that they have to happen simultaneously. The alphabet of each PNeven contains a null event meaning that no transition is red. However, for a simpler notation, and since all events in the master PN are unique, it suces to label the slave PNwith the sets of events, e.g. f 1 2 g, to be connected, thus omitting the null event. PNs, interacting according to the UDSC, execute as follows. A transition t 1 in the slave PN PN 0 is enabled if the place connected to the input arc into t 1 contains a token. Transition t 1 enabled implies that the events dened by t 1 's label are connected and can only be triggered in synchrony with each other. All other enabled transitions in the master PNs can happen arbitrarily. This event connection terminated with the ring of the connected events, and the next transition in the slave PN is enabled and denes a new relevant event connection. As a last operation we introduce the alternative connection of events, denoted by h 1 2 3 i with i denoting transition labels. The alternative connection is interpreted as follows: As soon as 1 is ready to re it is connected to either 2 or 3, depending on which of these is rst enabled, and the newly found set of connected events, either f 1 2 g or f 1 3 g,isredin direct sequence. After that, the remaining transition, 3 or 2, is red as soon as it is enabled. It is important to note that the ring of the transition labeled that way cannot start without the ring of 1. This operator is easily generalized to the case where 2 and 3 can be substituted by sets of connected events. Furthermore, if the PN is branching following an alternative connection, labeled paths can be specied to be taken depending on the events red. We then write h 1 f j g 1 f k g 2 i for an alternative connection, with the PN interpretation shown in Fig. 5. Building Blocks for Material Transfer. Figure 6 shows the generic building block used to model a primitive move, and the three dierent join constructs (AA, AS, SS). All transition labels are generic plant events assuming material transfer from two source units, P i and P j to the target unit P k, using lines P i P k and q 0 1 2 τ 1,{τ 2},{τ 3} 1 2 q 1 q 2 q 0 {τ 1,τ 2 } {τ 1,τ 3} τ 2 q 1 q 2 τ 3 Figure 5: The alternative connection operator with labeled paths (cf. 2 in Fig. 6) and their PN interpretations P j P k. In case one or both of the source units are buer tanks, it was mentioned before that buer tanks are modeled as on/o valves and are thus booked by the corresponding line. If, for example, the generic P i is a buer tank, then all generic events from P i 's PN are omitted. P i P k ubp i wp i P j σ 3a wp i S 2a σ 1 σ 2 1 2 S 1 op k S 0 wp k wp k wp j σ 3b wp j S 2b ubp j Figure 6: Generic building block for material transfer The transitions labeled i i =1 2 3a 3b represent important synchronization points where synchronization between dierent resources is required. This synchronization is achieved by connecting the corresponding events in the plant's resource models. 1 coordinates the booking of target unit and corresponding lines, and guarantees that no line is booked without the target unit being secured. 2 ensures that the lines are ready and the target unit prepared (preprocessed) before material transfer is started. 3a and 3b nally initiate post-processing and unbooking of source units P i and P j, respectively, when they have been emptied. This building block also contains four local supervisors: S 0 leads the target unit through a number of phases with the purpose of preparing it for operation. Once the desired initial system-state for the following operation is reached the unit switches to wait (event wp k ), where it is controlled to stay within this system-state.
S 1 belongs to the target unit and controls the actual material transfer by opening and closing the corresponding line. S 1 continues to control the target unit even after the source units have been emptied, so as to allow the material transfer to be part of another operation. The nature of S 1 depends very much on the kind of material transfer modeled (synchronous or asynchronous). S 2a and S 2b are used to post-process the source units before releasing them. After S 2a and S 2b have accomplished their tasks, the units are released (unbooked). All local supervisors can be either hybrid, i.e. designed to satisfy hybrid specications and synthesized using HSCT, or purely discrete. A table determines the -labeled transitions and the kind of local supervisors used for dierent material transports in Fig. 6. As an example, the following table contains these transitions and supervisors for a primitive move and a SAjoin. Prim. Move SA join 1 fbp k bl ik g fbp k bl ik bl jk g 2 fop k op i lok ik g hop k fop i lok ik g 1 fop j lok jk g 2 i 3a fop i lub ik g fop i lub ik g 3b fop j lub jk g S0 Hybrid Hybrid S1 Hybrid Discrete S2a Hybrid Hybrid S2b Hybrid The building block representing the primitive move has only one source unit, P i. Hence, the part of the PN in Fig. 6 associated with unit P j (the right branches) is omitted. Furthermore, the discrete local supervisor in the SA-join has the form of a semaphore and is needed to ensure that only one line is opened at a time. The building block for the adding of material is slightly dierent since both the target and the source unit already are booked by the recipe. For a detailed presentation see [7]. Finally, the synchronizable master recipe is built using the dierent building blocks as shown in the example at the end of this paper. Supervisory Control of Batch Processes Each recipe now describes a number of alternative paths through the plant. It is thus natural to view a recipe as a specication on the plant to exhibit a certain event sequence. However, there can be several independent recipes using the plant simultaneously. All of these together form a joint specication on the system's overall behavior. Let the plant P consist of a set of processors, P i, and a set of transporting devices, TD j. Connecting lines are denoted by L k. Furthermore, let the plant's alphabet consist of the following sub-alphabets: P = P [ L [ TD The sub-alphabets contain all the events of the processors, lines and transporting devices, respectively. We note that the lines are linked to the contained transporting devices by means of mutual events and dierent lines can be linked to the same transporting devices. In the sequel we will also need the alphabet LnB which contains all transporter events that book or block transporting devices. The plant is constructed by combining the automata of the dierent resources. Since lines can be linked to the same transporting devices (common events), the plant P is constructed as follows: P =(L 1 k L 2 k :::) k (P 1 k P 2 k :::TD 1 k TD 2 :::) (1) The interleaving of the lines, together with the fact that one and the same transporter can be linked to dierent lines causes the plant to be non-deterministic in the sense that the same event can put the plant into dierent states. In order to resolve this nondeterminism in the plant, caused by the line objects, we willre-labeltheevents, causing determinism in the lines as well as the transporters. First, each of the line events that either books/blocks a transporting device is re-labeled with a unique label. Next, for each re-labeling of a line event, a new transition is added in the corresponding TD Petri net parallel to, and is labeled with the new label, and, nally, all events that have been re-labeled are deleted from the TDs' Petri nets. The result of this re-labeling is a plant P that is deterministic. The creation of the overall specication, that is, the joint specication given by the combination of all recipes, is somewhat more tricky due to event connection. Each set of connected plantevents in the recipe is treated as one distinct event when generating the joint specication by interleaving the dierent routes of all recipes. Essentially, interleaving means that two PNs can execute their events completely asynchronously and independently of each other, even though there may exist mutual events. We denote the interleaving of two PNs, PN 1 and PN 2 as PN 1 k PN 2. For n recipes R i, i =1 ::: nthe joint specications is given by R =(R 1 k R 2 k :::R n ). So far the alphabet of R, R 6 P, since R contains events of the form h 1 2 i with i 2 P. After this interleaving, each connected event in the resulting joint specication is substituted by a sequence of its elementary events. Thus, a connected event h 1 2 i is substituted by the sequence of events 1 and 2. This substitution after the interleave, resulting in the joint specication R, ensures that (1) connected events are executed in strict sequence and (2) that R P. Augmenting the alphabet of R such that R = P [ LnB furthermore guarantees that all signicant plant events only happen in concert with the recipe when synchronizing the plant with the recipe. The synchronization P k R is necessary to retain only the physically possible and desired routes through the plant.
However, in the control recipe the booking of transporting devices is, due to the synchronization of plant and joint specication, possible in any order. Unfortunately, some combinations of valve booking will inevitable block the system from ever reaching a state where all recipes have been satisfactorily completed. Thus, some combinations of valve booking must be prohibited, and this is the task of the supervisor. Supervisor Synthesis It is shown in [4] that with a deterministic plant P and a nondeterministic specication R, there exists and can be synthesized a nondeterministic supervisor S that ensures that the closed loop system PkS= S and that S is the largest possible sub-automaton (least restrictive) of PkR such thats is both complete with respect to P and trim. A complete supervisor is able to follow all uncontrollable events that can be generated in each closed-loop system state, and trimness ensures that each process can be executed to some marked state (completion of all specied batches). This means that a trim and complete S allows the largest possible plant behavior that fullls all specications. A formal description of the supervisor synthesis algorithm is given in [4], and summarized below. Algorithm. We dene two operators, maxc() and maxt (), calculating the maximal complete and maximal trim subprocess, respectively. C denotes the set of all complete sub-processes and T the set of all trim sub-processes. Then, for i =0 1 2 ::: 1. Set S 0 : = max C(P kr) 2. S i+1 := max T (S i ) = max T (max C(S i;1 )). If S i+1 = S i terminate, else 3. S i+2 := max C(S i+1 ) = max C(max T (S i )). If S i+2 = S i+1 terminate, else 4. i:=i +2. Goto 2. In step 1, the control recipe is compared to the plant model, and those states of the control recipe that try to disable any uncontrollable event are removed. This is done iteratively until no further states to remove are found. That is, the control recipe is pruned at controllable events, guaranteeing that it can inuence the plant accordingly. This is the maximal complete subprocess of PkR, called S 0 in step 1 of the algorithm. The resulting automaton is either trim or not. This is tested by generating S 1, the maximal trim subprocess of S 0 in step 2. S 0 is made trim by removal of all states that are not reachable from the initial state or cannot reach some marked state. If S 0 is equal to S 1, the maximal complete and trim subprocess of P k R is found, and we have obtained our solution. However, if S 0 is not equal to S 1, the maximal complete subprocess of S 1 is generated in step 3. This subprocess is denoted S 2 and mayormay not be equal to S 1. Again, if they are equal the desired subprocess is found, and if not, the algorithm iterates, until a xpoint is reached. This xpoint may be reached when all states have been removed, in which case no usable supervisor exists. Example A simple example will serve asan illustration. Consider the tank system in Fig. 7. We specify two SMRs. Figure 7 shows the rst recipe, R 1,whichmoves material from buer tank B 1 into T 1 and from there out of the system via valve V 4. The second recipe, R 2 does the same but from buer tank B 2. Line events lok and lub carrying indices 1, 2 and 3, refer to line objects connecting B 1 ; P 1, B 2 ; P 1 and P 1 ;, respectively. B 1 B 2 V 1 V 2 V 3 V 4 P 1 ubp 1 { bp1, bl1} op 1 wp 1 { lok1, op1} { lub1, wp1} bl 3 R 1 { lok3, op1} { lub 4,wp1} Figure 7: Batch process with SMR For this simple example, plant P, as dened in (1), results in an automaton with 3375 accessible states, i.e. states that are physically possible. We have reduced this number of states by erasing the states blocked in the DEPs for V 3 and V 4 since they are never used. The number of automaton states is cut down to 256 in the next step, when P is synchronized with the two interleaved recipes, R. Since all events are controllable and no competition for valves arises in this example, PkRis both trim and complete. That is, S = PkR constitutes the supervisor for the system. The thus synthesized supervisor only allows a sequential execution of the two recipes. The large number of states when computing the plant automaton can be avoided by creating P k R using only PNs. References [1] M. Tittus and M. Fabian. Automated generation of plant-specic recipes in batch control. In Proc. of the ICCI'95, pages 99{102, Hong-Kong, 1995. [2] Imperial College, London, U.K. Workshop Analysis and Design of Event-Driven Operations in Process Systems, 1995. [3] M. Tittus, B. Egardt, and B. Lennartson. Plant and product models for batch processes. In Proc. of the ECC'95, Rome, Italy, 1995.
[4] M. Fabian and B. Lennartson. A class of nondeterministic specications for supervisory control. In Proc. of ECC'95, Rome, Italy, 1995. [5] P.J. Ramadge and W.M. Wonham. Supervisory control of a class of discrete event processes. SIAM J. Control Optim., 25(1):206{230, January 1987. [6] M. Tittus and B. Egardt. Control-law synthesis for linear hybrid systems. In Proc of33rdcdc, pages 961{966, Orlando, FL, USA, 1994. IEEE. [7] M. Tittus. Control Synthesis for Batch Processes. PhD thesis, Control Eng. Lab, Chalmers Univ. of Techn., Goteborg, Sweden, 1995.