Presented at FOCAPO 98, Snowbird, USA. PETRI NET ANALYSIS OF BATCH RECIPES STRUCTURED WITH GRAFCHART Charlotta Johnsson and Karl-Erik Årzén Department of Automatic Control, Lund Institute of Technology, Box 8, S- Lund, Sweden, E-mail: (lotta,karlerik)@control.lth.se Abstract: Grafchart is a graphical language aimed a sequential control applications. The language is implemented in a toolbox and it has been developed at the Department of Automatic Control in Lund, Sweden since 99. The language is based on Grafcet and Petri nets and it can be used for sequential control applications on both the local and the supervisory level. The main application so far, has been batch recipe structuring. In this paper it is shown how Petri net analysis methods can be applied to batch recipes that are structured with Grafchart. Keywords: Grafchart, Grafcet, Petri net, formal analysis, batch recipes.. INTRODUCTION Grafchart is a toolbox aimed at sequential control application on the local and the supervisory control level. Grafchart is based upon () the industrial and well known graphical syntax of Grafcet/SFC, () Petri nets, a discrete event modeling language with support for formal analysis, and (3) constructs from high-level programming languages. Grafchart exists in two different versions, one basic version and one high-level version. Only the basic version is presented in this paper. From a system theoretical point of view, sequential control logic belongs to the area of discrete event dynamic systems. The research in this area has traditionally been divided in two parts: () formal methods for verification and synthesis, and () improved tools and languages. The two research areas complement each other. The research done developing Grafchart has for most part focused on the second area. Production in batch mode is becoming more and more popular. The main reason for this is the increased demands on data logging and traceability. The specification of how to produce a batch is called a recipe. Recipe-based control is a special type of sequential control and the recipes can therefore be represented with Grafchart. Batch recipe structuring has, so far, been the main application of Grafchart. When developing Grafchart, the main objective has been to provide the user with a simple but yet powerful programming language. This allows the user to create recipes with a clear and intuitive syntax without giving up on functionality. The user to can use the same language both on the supervisory control level, e.g., to structure the recipe, and on the local control level, e.g., to implement the actual equipment control. Grafchart can, however, also be used to analyze the recipes in order to look for, e.g., deadlock situations. Deadlock situations might occur in a multi-product, flexible batch plant if, e.g., one batch currently being in one unit requires another unit and if that unit is reserved by another batch that requires the unit held by the first batch. Deadlock situations might lead to a deletion of the entire batch; this is costly and should therefore be avoided. The main objective developing Grafchart has not been analysis. However, Grafchart may very well be used also for this purpose. This is thanks to its foundation in Petri nets. The idea is to transform the Grafchart recipe into a Petri net and then apply the already existing analysis methods for Petri nets to the recipe. In the paper, two batch recipes are presented. The recipes are structured with Grafchart. The recipes are assumed to be run in the same plant. In the paper it is shown how Petri net analysis methods can be applied to the two recipes in the plant and how possible deadlock situations can be detected.
. GRAFCHART Grafchart is a graphical language developed at the Department of Automatic Control in Lund, Sweden, Årzén (994). It is based on Grafcet, Petri nets, and ideas from object-oriented programming.. Grafcet Grafcet was developed in France in 977, AFCET (977). Grafcet, or Sequential Function Charts (SFC), has become widely accepted in industry as a representation format for sequential control logic at the local control level, IEC (988), IEC (995). The graphical syntax of Grafcet is clear and intuitive. The building blocks are steps, representing states, and transitions, representing the change of states. Parallel and alternative branches are supported, see Figure (left). An active step is indicated by the presence of a token in the step. Associated with the steps are actions that are performed when the step is active. To each transition a receptivity is associated. The transition is enabled when all the preceding steps are active. When the receptivity becomes true, the transition is fired. This means that the preceding step(s) is deactivated and the succeeding step(s) is activated. Grafcet also supports macro steps, i.e., steps with an internal substructure consisting of steps and transitions. Grafchart is based on the same graphical syntax as Grafcet. However, in order to make Grafchart suitable also for sequential control at the supervisory control level, new building blocks are added. The new building blocks do not extend the functionality of Grafchart but facilitates the implementation of more advanced sequence structures. two types of nodes; places and transitions, see Figure (right). The mathematical modeling ability of Petri nets makes it possible to set up state equations, algebraic equations and other models governing the behavior of the system. While Grafcet is aimed at controlling a system, Petri nets are aimed at simulation, visualization and analysis of a system. Grafcet and Petri nets are presented in David and Alla (99). A Petri net transition is enabled if all of its input places contain at least one token. An enabled transition may or may not fire. The firing of a transition consists of removing one token from each input place and adding one token to each output place of the transition. The firing of a transition has zero duration. A Petri net may be analyzed with respect to properties like, e.g., deadlock, i.e., situations where no transition in the net structure can fire. The basic and most simple analysis method is to draw the so called reachability graph. In this graph the nodes correspond to the reachable markings (the number of tokens in the places), and the arcs correspond to the firing of transitions. The reachability graph for the Petri net in Figure (right) is shown in Figure. According to this figure, the Petri net is deadlock free since there is always at least one transition that can fire. t t t4 t3 t5 x t t3 x Fig. x4 t x3 t4 t5 alternative branch parallel branch x5 alternative branch t A Grafcet (left) and a Petri net (right).. Petri nets t3 p p4 p t t4 t5 p3 parallel branch Grafcet is based upon Petri nets, a graphical and mathematical model developed in the 6s, Petri (96). The graphical syntax of Petri nets is similar to that of Grafcet. In Petri nets there are p5 Fig. Reachability graph for the Petri net in Figure. Although the construction of the reachability graph is an efficient way of determining the properties of a small-size PN it is not a suitable method when a net has a large number of reachable markings. However, reduction methods exist that transform a large size PN into a PN of a smaller size. The idea of the reduction methods is to successively apply local transformation rules that transform the net into a simpler net, i.e., into a net with a smaller number of places and transitions, while preserving the properties of the net that one wants to investigate. Four reduction rules exist that preserves the property of deadlock-freeness.. Reduction R : Substitution of a place
. Reduction R : Implicit place 3. Reduction R 3 : Neutral transition 4. Reduction R 4 : Identical transitions The four reduction rules are thoroughly presented in David and Alla (99)..3 Object-oriented programming Grafchart is implemented in G, an object-oriented graphical programming environment. The building blocks in Grafchart are structured in a class hierarchy, and they may have attributes and methods. procedure is started as a separate execution thread, i.e. as a process. An outlined circle token is is shown in the process step as long as the process is executing. Macro steps are used to represent steps that have an internal structure. The internal structure is placed on the subworkspace of the macro step. A procedure step, a process step and a macro step are shown in Figure 4..4 Grafchart building blocks A part from steps and transitions, Grafchart supports: Grafchart processes, Grafchart procedures, procedure steps, process steps, and macro steps. An entire function chart can be encapsulated by a Grafchart process, i.e., the function chart is placed on the subworkspace of the Grafchart process. Sequences that are executed in more than one place in a function chart can be represented as Grafchart procedures. The procedure body is stored on the subworkspace of the Grafchart procedure. Special enter-step and exit-step are used to indicate the first and the last step of a procedure. Each procedure invocation is executed in its own local copy of the procedure body, i.e., the Grafchart procedures are reentrant. In Figure 3 (top) a Grafchart process and a Grafchart procedure are shown, the same figure (bottom) also shows a step with its associated action and a transition with its associated receptivity. Fig. 3 Grafchart process, Grafchart procedure, step with action, and transition with receptivity. The call to a Grafchart procedure is represented by a procedure step. The procedure step contains a procedure attribute that designates the Grafchart procedure that should be called. A process step is similar to a procedure step, the difference is that the Fig. 4 Procedure step, macro step and process step..5 Grafchart features Grafchart adds two features to Grafcet; Parameterization and methods. Steps, macro steps, procedure steps and Grafchart processes (entire function charts), may have parameters. The parameters can be accessed from within step actions and transition receptivities using a special sup.attribute notation. The parameterization feature is based on the fact that all building blocks of Grafchart are objects defined in a class hierarchy. The user can specialize these classes to subclasses in which additional attributes are added. These attributes act as parameters with lexical scoping. It is also possible for Grafchart procedures to have parameters. The parameters are given their actual values when the procedure is called, i.e. in the procedure step. A Grafchart procedure may return values to the calling procedure step. It is also possible to let the value of a parameter determine which procedure that will be called by the procedure step. The method feature denotes the possibility to have Grafchart procedures as methods of general objects. For example, an object representing a batch reactor could have methods for charging, discharging, agitating, heating, etc. From the body of the procedure realizing the method it is possible to reference the attributes of the object that the method belongs to using a special self.attribute notation. A Grafchart method is called through a procedure step. The method that should be called is determined by an object reference and a method reference. The example
in Figure 5 shows a reactor object R that contains the method charge. The method is implemented by the Grafchart procedure reactor-charge. The procedure step invokes the charge method of the R object. and it is therefore released. When the content has been cooled down it is transfered back to the mixer where the rest of the batch is waiting. is now released. The mixture is agitated and thereafter discharged. Finally the mixer is released. FillA FillB FillA FillB / / Fig. 5 Grafchart methods. Heat Cool 3. BATCH RECIPES Cool Heat Grafchart allows for a number of different way to structure batch recipes, these are presented in Johnsson (997) and Johnsson and Årzén (998). The idea, when using Grafchart for structuring the recipes, is to split the implementation in two parts. First, the equipment specific information is implemented. This is done through methods that belong to the equipment itself. In the method it is possible to refer to the attributes associated with the equipment. The recipe, i.e., the step by step instructions of how to proceed from raw-material to end-product, is implemented using procedure steps and process steps from which calls to the already implemented equipment methods can be performed, see Figure 6. Grafchart for representing the recipe procedure CHARGE Method call Grafchart for representing equipment sequence logic name a reactor R charge a grafchart-method Fig. 7 Discharge Two Grafchart recipe structures. Discharge, ReactorB, Another batch recipe is shown in Figure 7 (right). This batch mixes two reactants in a mixer, transfers half of the content to a reactor for cooling. When the cooling is performed, the other half of the batch is transfered from the mixer to a reactor for heating. Finally the content of the two reactors are transfered back to the mixer for final agitation and discharging. Both recipes presented in Figure 7 are structured with phases, i.e., each procedure step in the recipe corresponds to a phase. A phase is the smallest procedural element that can accomplish a process oriented task. A phase must always execute within the same equipment, S88. (995). Fig. 6 Recipe structure / Equipment specific information. An example of a simple recipe is shown in Figure 7 (left). The recipe starts by assigning a mixer to the batch. The need of a mixer is indicated by the first transition. After the assignment the to reactants A and B are filled into the mixer, and the mixture is agitated. Thereafter a reactor is assigned and half of the content in the mixer is transfered to the reactor. The other half of the batch is left in the mixer. The content in the reactor is heated and then transfered to another reactor where it is cooled. Two different reactors, reactor A and reactor B, are used for the heating and the cooling. After the transfer from reactor A to reactor B, reactor A is no longer needed 4. BATCH RECIPE TRANSFORMATION If the two recipes, called Recipe and Recipe, are produced in the same plant at the same time, they will effect each other since they utilize the same equipment. This can be represented by combining the two Petri nets corresponding to the two recipes, see Figure 8 in which recipe is placed to the left and recipe to the right. Assume that there is one mixer, one reactor of type A (used for heating) and one reactor of type B (used for cooling) in the plant. This is represented by placing one token in each of the places corresponding to the equipment. The number of tokens placed in the initial step in each of the transformed recipe structures corresponds to the intend to produce this number of batches.
ReactorA ReactorB In order to obtain the two transformed recipes shown in Figure 8, the restrictions and assumptions presented above are used. In addition to this, the fact that a phase always executes within the same equipment, is used. This implies that each procedure step, corresponding to a phase, can be replaced by one single Petri net place, i.e., the procedure step does not have to be replaced by the internal structure of the corresponding Grafchart procedure. The two transformed recipes in Figure 8 can now be reduced according to the reduction rules previously mentioned, see Figure 9. The transformed recipe on the left side in the figure corresponds to Recipe and the transformed recipe on the right side corresponds to Recipe. Fig. 8 Two Petri net recipe structures. In order to be able to make a transformation between a Grafchart and an autonomous Petri net some assumptions and restrictions have to be made. What differs a Grafchart from a Petri net is () the actions and receptivities in Grafchart, () its graphical representation, and (3) the dynamic behavior. Fig. 9 Two reduced Petri net recipe structures.. Since a Petri net does not have any actions associated with the places or receptivities associated with the transitions, these have to be ignored when transforming a Grafchart into a Petri net. This means that deadlock situations caused by unsuitable actions and receptivities cannot be found.. The graphical syntax for steps, transitions, parallel branches and alternative branches are not identical in Grafchart and Petri nets, see Figure. Grafchart contains a larger number of graphical elements than Petri nets. The additional graphical elements that exist in Grafchart must therefore be replaced with a larger number of Petri net elements. Macro steps, procedure steps and process steps should be replaced with the internal structure or the internal structure of the associated Grafchart procedure. 3. The dynamical behavior of a Grafchart and a Petri net differs with respect to the firing instance of a transition. In Grafchart an enabled transition fires immediately whereas the firing instance of an enabled transition in a Petri net is not uniquely given. However, this does not influence the reachability graph and is therefore of no importance for the analysis results. If only one batch of each type should be produced, the system cannot get into a deadlock situation. This can be shown by drawing the reachability graph. What if we add an extra resource to the plant, e.g., a mixer? The intuitive reaction is that; adding an extra resource cannot lead to a deadlock since deadlocks occur when there are to few resources. Thus, adding an extra resource cannot cause the system to get into a deadlock situation. However, by drawing the reachability graph one can show that this is not true. This means that informal arguments about behavioral properties are dangerous, Jensen (99). The reachability graph, corresponding to Figure 9, using two mixers, is shown in Figure. The deadlock situation that arises when a second mixer is added to the plant can intuitively be understood by examining Figure 9. The two recipes use reactor A and reactor B in reversed order, this means that if a deadlock situation should occur, it is due to this. When there is only one mixer in the plant, the mixer assures that a second batch cannot start until the first batch has finished, and a deadlock situation can therefore not occur. 5. ANALYSIS OF A BATCH PLANT The deadlock property is a behavioral property, i.e., it is marking dependent. Off-line analysis can be per-
Fig. T T T3 T T6 Reachability graph. formed and the results stored in a table. The results can, e.g., show the number of batches in different recipe combinations, that can execute at the same time in the plant without risk for a deadlock. Figure shows "possible-deadlocks" with respect to the two recipes, versus different plant configurations. Assume that the default plant is 3 mixers, reactor A and reactor B. The table shows the "risk of deadlocks" for the default plant as well as for the plant * Recipe * Recipe * Recipe Recipe Recipe * Recipe Recipe Recipe T3 T6 T DEADLOCK -- -- -- -- -- ok ok ok -- -- ok -- ok ok -- ok ok ok ok -- 3MRaRb MRaRb MRaRb 3MRaRb 3MRaRb T6 T3 with one or several of the equipments broken down. The table can be used as a help when determining how to avoid deadlock situations in a batch plant. 6. CONCLUSIONS A recipe structured with Grafchart can be transformed into a corresponding Petri net to which already existing Petri net analysis methods can be applied. Using, e.g., the reduction techniques and the reachability graphs, characteristics like deadlockfreeness can be investigated. As shown in this paper it is only the topology of the Grafchart structured recipe that can be analyzed, influences of step actions or transition receptivities cannot be included in the analysis. The deadlock analysis can be performed offline and stored in a table. The results from the deadlock analysis can also be implemented by a supervisor according to the Supervisory Control Theory (SCT), Ramadge and Wonham (989). 7. REFERENCES AFCET (977): Normalisation de la representation du cahier des charges d un automatisme logique. J. Automatique et Informatique Industrielle. ÅRZÉN, K.-E. (994): Grafcet for intelligent supervisory control applications. Automatica, 3:. DAVID, R. and H. ALLA (99): Petri Nets and Grafcet: Tools for modelling discrete events systems. Prentice-Hall International (UK) Ltd. IEC (988): IEC 848: Preparation of function charts for control systems. International Electrotechnical Commission. IEC (995): IEC 3-3. Technical Report. International Electrotechnical Commission. JENSEN, K. (99): Coloured Petri Nets. Basic Concepts, Analysis Methods and Practical Use., vol., Basic Concepts. Springer- Verlag. JOHNSSON, C. (997): Recipe-Based Batch Control Using High- Level Grafchart. Licentiate thesis ISRN LUTFD/TFRT-- 37--SE. Dept. of Automatic Control, Sweden. Available at http:://www.control.lth.se/ lotta/papers.html. JOHNSSON, C. and K.-E. ÅRZÉN (998): Grafchart for recipebased batch control. Computers and Chemical Engineering. To appear. PETRI, C. A. (96): Kommunikation mit automaten. Technical Report. Institut fur Instrumentelle Mathematik, Universitat Bonn. Schriften des IIM Nr. 3. Also in English translation, Communication with Automata, New York: Griffiss Air Force Base. Tech. Rep. RADC-TR-65-377, vol., Suppl., 966. RAMADGE, P. and W. WONHAM (989): The control of discrete event systems. In Proceedings of the IEEE, vol. 77, pp. 8 98. S88., I. (995): Batch control. Instrument Society of America. Fig. A table showing the possibility of deadlock for different recipes in different plant configurations, ok deadlock not possible, deadlock possible.