Exception Handling in S88 using Grafchart *

Transcription

1 Presented at the World Batch Forum North American Conference Woodcliff Lake, NJ April 7-10, S. Southgate Drive Chandler, Arizona Fax Exception Handling in S88 using Grafchart * Rasmus Olsson and Karl-Erik Årzén Department of Automatic Control Lund Institute of Technology, Box 118, S Lund, Sweden {rasmus,karlerik}@control.lth.se KEY WORDS Exception handling, Recipe-based batch control, Supervision, Finite state machines, S88, Grafchart. ABSTRACT Exception handling constitutes a large part of the design and implementation effort in batch production, but so far little work has been carried out to specify this area. This paper proposes an internal model approach for equipment unit supervision using Grafchart. It also discusses exception handling at the recipe level. 1. INTRODUCTION A batch control system must support a large number of functions in addition to the basic regulatory control. Some examples are production planning, production scheduling, recipe management, resource arbitration and allocation, batch report generation, unit supervision, and exception handling. The focus of this paper is exception handling in batch control. Exception handling is a critical element for achieving long-term success in batch production. It is reported to constitute percent of the batch control design and implementation effort [2]. Correct handling of exceptions is a key element in process safety, consistent product quality, and production cost minimization. * This work has been supported by CPDC - Center for Chemical Process Design and Control and by TFR. Copyright 2002 World Batch Forum. All rights reserved. Page 1

2 Recently a lot of focus has been put on standardization of the models and terminology used in batch control, e.g., NAMUR and S88, in particular for network-structured multi-purpose batch plants. However, so far very little has been specified in the area of exception handling. In this paper the work on Grafchart, a Grafcet-related language for sequential programming, for batch process recipe handling and resource allocation is extended to also include exception handling. An internal model approach is proposed where each equipment unit is extended with a state machine-based model that is used on-line to structure and implement the safety interlock logic, and to provide a safety check to ensure that recipe operations are performed in a correct order. The previous work on Grafchart for batch control is outlined in Section 2. The internal model approach for unit supervision is described in Section 3. The connections to the recipe level are discussed in Section 4, where also a major example is given. 2. GRAFCHART Grafchart is a graphical programming language for sequential control applications. It is based on Grafcet together with ideas from Petri nets, high-level programming languages and object-oriented programming. Two different versions exist. The first and ordinary version is based directly on Grafcet whereas the second version, called High-Level Grafchart, also incorporates ideas from high-level Petri nets. Grafchart is described and defined in [1], [8]. Grafchart has a similar syntax to that of Grafcet/SFC, i.e., the basic building blocks are steps, representing states and containing actions, and transitions, representing the change of states. An active step is indicated by the presence of a token in the step. In ordinary Grafchart the tokens are simple boolean indicators, whereas the tokens in High-Level Grafchart are objects that may contain information. Grafchart contains three hierarchical abstractions: macro steps, procedure steps, and process steps. Macro steps are used to represent steps that have an internal structure. The internal structure of the macro step is encapsulated within the macro step. The call to a procedure is represented by a procedure step. The procedure step contains a procedure attribute that contains the name of the procedure that should be called. A process step is similar to a procedure step. The difference is that the procedure is started as a separate execution thread. An open problem in Grafcet is how the logic for the normal operating sequence best should be separated from the exception detection and exception handling logic and sequences. Grafchart contains a number of assisting features for this. Using connection posts, it is possible to break a graphical connection between, e.g., a step and a transition. In this way it is possible to separate a large function chart into several parts that may be stored on different workspaces. This enhances the readability of the chart. An exception transition is a special type of transition that may only be connected to macro steps and procedure steps. An ordinary transition connected after a macro step will not become active until the execution has reached the last step of the macro step. An exception transition is active all the time that the macro step is active. If the exception transition condition becomes true while the corresponding macro step is executing the execution will be aborted, abortive actions, if any, are executed, and the step following the exception transition will become active. Macro steps and procedure steps remember their execution state from the time they were aborted and it is possible to resume them from that state. Exception transitions have proved to be very useful when implementing exception handling. Copyright 2002 World Batch Forum. All rights reserved. Page 2

3 Figure 1 S88 Procedural Model (left) and its representation im Grafchart (right). Steps, macro steps and entire function charts, may have parameters. The parameters can be accessed from within the step actions and the transition conditions. It is also possible for Grafchart procedures to have parameters. The parameters are given their actual values when the procedure is called. The values can either be constants or the value of a parameter. In the latter case a procedure may also return values to the calling procedure step. It is also possible to let the value of a parameter determine which procedure will be called by the procedure step. Grafchart procedures can be stand-alone entities or methods of objects. For example, an object representing a batch reactor could have Grafchart methods for charging, discharging, agitating, heating, etc. A method is called through a procedure step. The method that will be called is determined by an object reference and a method reference. In the high-level version of Grafchart the tokens can be objects with attributes. A step may contain several tokens, of the same or of different classes. Each step action and each transition condition is associated with a token class. Grafchart has been implemented in G2, a graphical programming environment from Gensym Corp, and is currently being re-implemented in Java using a Swing-based graphics library from Northwoods Software Corp called JGo. Grafchart and Batch Control Grafchart has been used for batch control recipe handling and resource allocation, see e.g., [8], [9], [10]. Different possibilities for representing recipes and combining recipe execution with resource allocation have been explored using both versions of Grafchart. The S88 procedural model is straightforward to model in Grafchart, see Fig. 1. Grafchart has also had a considerable impact on the definition of Procedure Function Charts (PFC), see [4]. The linking between the control recipe and the equipment control is implemented using methods and message passing according to Fig. 2. The element in the control recipe where the linking should take place is represented by a procedure step. Depending on at which level the linking takes place, the Copyright 2002 World Batch Forum. All rights reserved. Page 3

4 procedure step could represent a recipe procedure, recipe unit procedure, recipe operation or recipe phase. The procedure step calls the corresponding equipment control element which is stored as a method in the corresponding equipment object. Figure 2 Equipment unit with finite state machine. A number of different ways to represent recipes have been proposed. The most straightforward way is to represent each control recipe by a separate Grafchart function chart. Another possibility is to use a highlevel function chart for representing each master recipe, and to use the object tokens in this function chart to represent the individual batches. This can also be combined with resource allocation in a Petrinet style, and equipment-oriented operations, e.g., CIP (Cleaning-In-Place), see [8]. 3. UNIT SUPERVISION The proposed method for unit supervision is based on augmenting the equipment objects with a finite state machine as shown in Fig. 2. The unit contains three parts: a set of attributes, Grafchart methods representing equipment unit operations or phases, and a state machine. The attributes could either be attributes of simple types, e.g., max-capacity, or they could be objects, e.g., representing the equipment/control modules within the equipment unit. In the latter case the proposed structure applies recursively, i.e., the equipment/control modules may also contain three parts. The state machine is used to model the behavior of the physical object. The state machine could either be a single automaton, or consist of several smaller parallel automata, which, when composed, form a single automaton. The latter alternative is probably more user-friendly. The state machine serves two purposes. The first purpose is to check that all the equipment objects are in a consistent state when a Grafchart method is invoked. For example, it should not be allowed to open a valve (represented by a control module) if the valve already is open, and it should not be allowed to fill an equipment vessel that is already full. In a properly designed batch control system that always executes in automatic mode, one could argue that consistency checking of this type is already performed through off-line validation and verification of recipes, equipment logic, and production schedules. However, in practice batch processes are often run in manual mode for substantial parts of time. Then, it Copyright 2002 World Batch Forum. All rights reserved. Page 4

5 is the operator that manually invokes different equipment operations and a consistency check of the proposed type could be very useful. The consistency check is realized by associating a set of allowed states with each Grafchart method. It is only allowed to start the execution of the method if the state of the equipment object belongs to the allowed set of states. The execution of the Grafchart method causes the state machine to change state, see Fig. 3. For example, when the control systems sends a signal to a valve to open, the state machine of the valve will go from the state closed to the state open. Figure 3 Grafchart method and state machine. Figure 4 State machine with safety and supervision logic. The second purpose of the state machine is to provide a structure for organizing the safety and supervision logic at the equipment level. This is done by implementing the safety logic as transitions or guards in the state machine, as in Fig. 4. The safety logic is only enabled when its preceding state is active. If a fault occurs the safety logic causes a state transition from a normal state to a fault state. For example, when the valve mentioned earlier changes state to open the error transitions of this state become active. One of the transition conditions might be that if the valve does not respond to the signal within a given time, and sends back a signal that it is physically open, the state machine of the valve will go to the error state. The state machines can be implemented in several ways. An interesting question is whether it is possible to implement also the state machines using Grafchart. Since Grafcet, and hence Grafchart, has the same expression power as Moore and Mealy state machines, [3], it is in principle possible. However, Grafcet has two drawbacks with respect to implementing state machines. The first is the graphical syntax with its top to bottom style and its orthogonal-only connections between steps and transitions. The second, and more important drawback, is the nature of Grafcet's hierarchical language constructs. A Grafcet macro step is sequential in nature and has only one entry point and one exit point. This is different from hierarchical states in state machines, e.g., the super-state construct in Statecharts, [5], where several entry points and exit points are allowed. Due to this it is quite awkward to model hierarchical state machines with Grafcet. To partly overcome the above problems, the super step language element has been added to Grafchart. A super step can be described as a macro step that may have several enter steps and exit steps, see Fig. 5. Using super steps and by relaxing the requirement on orthogonal connections to also allow diagonal connections, it is possible and convenient to model hierarchical state machines of the proposed type using Grafchart. Copyright 2002 World Batch Forum. All rights reserved. Page 5

6 Figure 5 State machine for a valve implemented in Grafchart using a super step. 4. RECIPE LEVEL EXCEPTION HANDLING In the proposed approach the main responsibility for fault detection and exception handling lies at the equipment level. However, exception handling is also needed on the recipe level. For example, when an exception occurs during the production of a batch this must be fed back to the control recipe, recorded in the batch report, and appropriate actions must be taken. The nature of the actions that must be taken depends on the application. In a few very special cases it might be possible to undo an operation and rollback the execution of the recipe to a safe execution point, and from there continue the execution using, e.g., a new unit. This is similar to the check-pointing and rollback employed in fault-tolerant realtime systems [6]. One situation where it would be natural to be able to rollback the execution would be when a method is called and the equipment object is in an unallowed state. When the state of the equipment object is changed into one of the allowed states the method would be called again and the execution of the recipe would be able to continue. However, due to the nature of chemical batch processes this is in most cases not a viable alternative. For example, it is very seldom possible to undo a chemical reaction. Also in the more common case where the batch cannot be produced as intended there are several alternatives. In certain situations it might be possible to still make use of the batch to produce a product of a different grade or quality. In other situations it is possible to recirculate the batch ingredients for later reuse. Also in the case where the batch cannot be used as a product, special actions must be taken. Due to environmental regulations the partly produced batch must be taken care of in an appropriate way. This may include further processing to separate the batch ingredients. An important consideration is how to separate the recipe information from the exception handling logic and operations. If the latter is included in the recipe, it becomes difficult to develop, maintain, and use. The exception handling would probably be several times larger than the recipe it self. Grafchart provides several features that simplify the representation of exception handling logic at the recipe level. One possibility is to use step fusion sets [7]. A step fusion set contains a number of steps that all are different graphical representation of the same Grafchart step. The different steps can be seen as different views or aspects of the step. When one of the steps in the fusion set becomes active (inactive) all the steps in the sets will become activated (inactivated). Step fusion set can be used for recipe exception handling. Consider a control recipe consisting of a sequence of method calls to different equipment phases. Each method call is represented by a procedure step. The transition after each procedure step becomes enabled when the execution of the corresponding Grafchart method has finished. If an exception has occurred and it has been detected by the equipment exception handling logic, this is reported back to the recipe level by a special exit code. The transitions Copyright 2002 World Batch Forum. All rights reserved. Page 6

7 for handling the different error exit codes can be separated out and represented in a special exception handling view of the corresponding procedure step, see Fig. 6. Two of the error exits would typically be the exit for emergency shutdown and the exit when the state of the unit is not a member of the allowed starting states at the instant of the method call. Other error exits would be for the malfunction of a valve, a sensor etc. It is also possible to use exception transitions for recipe level exception handling. Figure 6 Step fusion sets for exception handling: recipe and exception view. Example As part of a recipe reactant A should be filled in a buffer tank. The reactant should be heated to a certain temperature in the tank and then transported to a reactor to react with reactant B. The recipe contains a procedure step for filling the buffer unit with A. The buffer unit has regular attributes, e.g. the maximum volume, and object attributes: an in-valve, an out-valve, a level sensor, a temperature sensor, a pump for emptying the vessel, and a PID regulator which regulates the flow of the heating medium using a flow control valve. Each equipment/control module has a state-machine representing the current state of the module. The state machine consists of a Grafchart function chart which describes the allowed paths of the state machine and a state list which contains the currently active states. The states of a valve can for example be open and closed, and the fault state error as in Fig. 5. The state list is updated every time the state of the machine is changed. The buffer unit itself also has a state machine describing the state of the whole unit. Each module's state machine affects the state machine of the unit. The state machine of the buffer unit consists only of the states OK and not-ok. The state changes to not-ok if any of the error conditions for any of the modules are fulfilled. When the procedure step in the recipe calls the fill method of the buffer unit, the method contains a list of the allowed states of the buffer unit for beginning to fill the tank, e.g. the tank must be empty, the Copyright 2002 World Batch Forum. All rights reserved. Page 7

8 temperature cannot be too high, and the out-valve must be closed. This way it can be assured that the filling of the tank is performed in a safe way. Assume that the method can be started, then the attributes of the buffer unit will change according to the execution of the phases in the procedure. This will make the state machine of each module change states as described in Fig. 3. The filling of the buffer tank consists of opening the in-valve of the tank. This is carried out by calling the open method of the invalve, which then checks the allowed states of the open method against the state list of the in-valve. The state machines are used for fault detection as described in Fig. 4. If for example the level sensor breaks during the filling, and assuming we can detect this error, the state machine of the level sensor will end up at the fault state error. The change of state will update the state machine list of the buffer unit and the state of the buffer unit will become not-ok. This will cause an alarm to the operator and the procedure will be stopped. As soon as the procedure is stopped the fault information will be passed on to the recipe, which can take the appropriate action. In the case there is no specified action related to the error a default action can be carried out to take the unit to a safe state. In this case, since the level sensor is broken, the volume of the reactant is unknown. To take care of the problem the tank can be emptied to another buffer tank or the reactant pumped back to the storage tank. Before this can take place the reactant has to be cooled down to the original temperature in the storage tank. Then it is possible to rollback the execution of the recipe according to Fig. 6 and the production of the batch can continue using another buffer tank or waiting for the original buffer tank to become available again. 5. CONCLUSIONS Exception handling is an important area of batch control that so far has received little interest from the standardization organizations. In this paper a state machine approach is proposed, which is integrated with recipe execution and resource allocation using Grafchart. 6. REFERENCES [1] Årzén, K.-E. and C. Johnsson (1996): Object-Oriented SFC and ISA-S88.01 Recipes. In WBF 96, Toronto, Canada. [2] Christie, D. (1998): A Methodology for Batch Control Implementation a Real World Lesson In WBF 98, Baltimore,USA. [3] David, R. and H. Alla (1992): Petri Nets and Grafcet Tools for Modelling Discrete Event Systems, Prentice-Hall. [4] Emerson, D. (1999): What Does a Procedure Look Like? The ISA-S88.02 Recipe Representation Format. WBF Homepage, SP88 Part Two Overview Paper 6. [5] Harel, D. (1987): Statecharts, a Visual Approach to Complex Systems Sci. Comp. Programming. [6] Jalote, P. (1994): Fault Tolerance in Distributed Systems. Prentice-Hall. [7] Jensen, K. and G. Rozenberg (1991): High-Level Petri Nets. Springer Verlag. [8] Johnsson, C. (1999): A Graphical Language for Batch Control. Ph.D. Thesis ISRN LUTFD2/TFRT-1051-SE, Department of Automatic Control, Lund Institute of Technology, Lund Sweden. [9] Johnsson, C. and K.-E. Årzén (1998a): Grafchart and Batch Recipe Structures. In WBF 98, Baltimore,USA. [10] Johnsson, C. and K.-E. Årzén (1998b): Grafchart and Recipe-Based Batch Control. Computers and Chemical Engineering, 22:12, pp Copyright 2002 World Batch Forum. All rights reserved. Page 8