grafchart applications

GRAFCHART APPLICATIONS! Karl-Erik Årzén and Charlotta Johnsson

Department of Automatic Control, Lund Institute of Technology, Box 118, S-221 00 Lund, Sweden, Email: karlerik, [email protected]

Abstract: An overview of Grafchart, a graphical language for sequential control applications is given. Grafchart is based on Grafcet/SFC to which it adds concepts from high-level Petri nets, Statecharts and object-oriented programming. Applications of Grafchart in batch control, alarm filtering, decision support, and FMS are briefly presented. 1. INTRODUCTION The advantages of graphical programming languages are simplicity and declarativeness. They often allow programming in a style that closely mimics the style that people model problems. Examples of mental models that are naturally represented graphically include fault trees, organization charts, program flowcharts, and block diagrams. Graphical languages fit users’ existing perception of problem, making the application easier to build, debug, document, and maintain. An added benefit is the possibility to use colour and animation to provide feedback as the program executes. Graphical programming languages have always been popular in the automatic control community. Programming logic controllers (PLCs) have by tradition been programmed with relay (ladder) logic diagrams. Continuous control algorithms are often programmed by function block based graphical data flow languages. This programming style has recently also been recognized by the software community and proposed as a software architecture paradigm [Shaw, 1982].

The recent IEC standard 1131-3 for PLC programming language integrates three graphical languages and two text-based languages. One of the graphical programming languages is Sequential Function Charts (SFC). The domain of SFC is sequential discrete logic control. SFC has its roots in Grafcet [David This is a modified version of the paper presented at SNART’97, Lund, Sweden.

and Alla, 1992], a French standard for logical controllers developed in the mid 1970s that is based on ideas from state machines and Petri nets. The state machine and Petri net formalisms are also commonly used in the context of formal methods for analysis of discrete event systems. Here they are used to prove system properties, e.g., safety, and liveness, for verifying that a plant model in combination with a controller fulfills a given specification, and, in certain, quite restricted, cases, also for controller synthesis. Grafchart is the name of graphical language for sequential control applications. Grafchart is based on the graphical syntax of Grafcet. To this it adds ideas from high-level Petri Nets [Jensen and Rozenberg, 1991], Statecharts [Harel, 1987], and object-oriented programming. Grafchart has been developed at Lund Institute of Technology since 1991 [Årzén, 1991; Årzén, 1994b; Årzén, 1993; Årzén, 1996b; Johnsson, 1997]. The system is implemented in G2, an objectoriented graphical programming environment developed for supervisory applications, [Moore et al., 1990]. The primary aim of Grafchart is to show how SFC can be modified from a rather low-level graphical language into a high-level, object-oriented graphical language. The secondary aim is to be able to use available analysis methods and tools developed for state machines and Petri nets also for Grafchart. In this way the same formalism may be used both for execution and formal analysis.

!

This paper gives an overview of the Grafchart lan-

guage and gives examples of different applications where it has been used. 2. GRAFCHART Grafchart has a similar syntax to that of Grafcet/SFC, i.e., the primary building blocks are steps, representing states, and transitions, representing the change of state. A step and a transition is connected by an arc. Grafchart also supports alternative and parallel branches, see Figure 1. An active step is indicated by the presence of a token in the step. Grafchart comes in two different versions, a basic version, and a high-level version. In the basic version, the tokens are simple boolean indicators that indicate if a step is active or inactive. In the highlevel version the tokens are objects that may contain information.

or−divergence

and−divergence

and−convergence

active. Initially (finally) actions are executed once when the step becomes active (inactive). Abortive actions are executed once immediately before the step becomes aborted. The actions can be conditional or unconditional. The actions are represented as G2 rules and the things that can be performed in a step action include all of G2’s built in rule actions. For example, it is possible to assign values to variables (the conclude action), to start procedures, to create and delete objects, hide and show information, perform animation actions, etc. The step actions associated with a step are placed on the subworkspace of the step. To each transition a receptivity is associated. Each receptivity contains two attributes: a condition and an event. The transition is enabled when all the preceding steps are active. When the receptivity of a transition becomes true, the transition is fired. This means that the preceding step is deactivated and the succeeding step is activated. The receptivity of a transition is also translated into a G2 rule. This rule is invoked when a transition is enabled and is responsible for the transition firing. When the transition fires a procedure is started that takes care of the activation and deactivation. A Grafchart function chart can be closed or terminate through a sink transition. However, it always starts with an initial-step. A function chart can optionally be encapsulated by a Grafchart process object, see Figure 2.

or−convergence

Fig. 1

Grafchart graphical syntax.

Grafchart is implemented in G2, a graphical objectoriented language, [Gensym Coorporation, 1995]. The different building blocks in Grafchart are defined in a class hierarchy and represented as objects. An object can have an activatable subworkspace attached to it. A subworkspace is a virtual rectangular window upon which various G2 items such as rules, procedures, objects, displays, and interaction buttons can be placed. When the subworkspace is deactivated, the items placed on it are inactive and invisible for the G2 execution engine. The arcs are implemented as G2 connections. Associated with the steps are actions. Four basic action types are supported: always, initially, finally, and abortive. Always actions are executed cyclically as long as the step they are associated with is

Fig. 2

A Grafchart process.

2.1 Hierarchical Abstractions Grafchart contains four hierarchical abstractions: macro steps, procedure steps, process steps and super steps. Macro steps are used to represent steps that have an internal structure. The internal structure of the macro step is placed on the subworkspace of the macro step. Special enter-steps and exit-steps are used to indicate the first and the last step of the substructure. A macro-step is shown in Figure 3 (top left).

Sequences that are executed in more than one place in a function chart can be represented as Grafchart procedures. 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 procedure step and a Grafchart procedure is shown in Figure 3 (top right). A process step is similar to a procedure step. The difference is that the procedure is started as a separate execution thread, i.e., as a process. An outlined circle token is shown in the process step as long as the process is executing. The transitions after a process step become enabled as soon as the execution has started in the Grafchart procedure whereas the transitions succeeding a macro step or a procedure step do not become enabled until the entire sub-sequence has been executed. A process step and a Grafchart procedure is shown in Figure 3 (bottom right). Macro steps are only allowed to have one input and one output connection. This is not sufficient if one truly wants to be able to cluster a number of states (steps) into a super state. Then it must be possible to enter and exit the super state in several ways. This is provided by the super step. A super step may have several inputs and several outputs, see Figure ?? (bottom left). It can be compared to the super-state of Statecharts.

step following the exception transition will become active. Abstraction steps “remember” their execution state from the time they were aborted and it is possible to resume them from that state. An exception transition is shown in Figure 4. Exception transitions are an addition to Grafcet that was first proposed in [Årzén, 1991]. It has proved to be very useful when implementing error handling.

Fig. 4

Macro step with exception transition.

The building blocks and the hierarchical abstraction facilities described previously exists in both the basic version of Grafchart and the high-level version. 2.2 Grafchart - the basic version The basic version of Grafchart includes two features: parameterization and methods and message passing. Grafchart processes (i.e entire function charts), macro steps, super steps, and steps may have parameters. The parameters can be accessed from within step actions and transition expressions. The parameterization feature is based on the fact that all Grafchart language elements are objects defined in class definitions. The user can specialize these classes to subclasses in which additional attributes are added. These attributes act as parameters with lexical scoping. Within some limitations it is also possible to modify the graphical representation, i.e., the icon, in the subclass definition of a step.

Fig. 3

Macro step, procedure step, process step, and super step.

The transitions following a macro step, super step, and procedure step will not be enabled until a final step of the abstraction step is active. An exception transition is a special type of transition that may only be connected to macro steps, super steps, and procedure steps. An exception transition is enabled all the time that the abstraction step is active. If the exception transition condition becomes true while the step is executing the execution will be aborted, abortive actions, if any, are executed, and the

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 or a process step. The values can either be constants (numbers, strings, or symbols) or the value of a parameter that is visible in the context of the procedure or process step. 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 that will be called by the procedure step, i.e., there is support for dynamical binding. The method feature denotes the possibility to have

Grafchart procedures as methods of general G2 objects. For example, a G2 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 the self notation. A Grafchart object method is called through a procedure step. The method that will be called is determined by an object reference and by a method reference. The example in Figure 5 shows a reactor object R1 that contains the method charge. The method is implemented by the Grafchart procedure reactor-charge. The procedure step invokes the charge method of the R1 object.

Fig. 5

also possible to delete a token in the preceding step, to create a new instance of a token in the succeeding step, or to execute an arbitrary G2 rule action. In fact, the tokens residing in a step are not objects themselves, instead they are pointers that point to the real object token which contains the attributes. The reason for this is the parallel structure. This structure can cause problems when merging if, e.g., the attributes of a token are changed in one of the parallel branches. By instead letting the token that resides in the step be a pointer that points to the ’real’ object token, an attribute that is changed in one of the branches will directly be visible in all branches. The token residing in a step is called a grafchart-marker and it points to the object token. The situation is shown in Figure 6. When a transition is fired that moves a token to the beginning of a parallel branch, then for each parallel branch a new token is created that points at the same object token. An analogous approach is used for the parallel join. The adopted approach makes High-Level Grafchart backward-compatible with ordinary Grafchart and makes it possible to fold several identical Grafchart function charts into one high-level function chart.

Grafchart methods.

2.3 Grafchart - the high-level version In addition to the features described previously, HighLevel Grafchart includes two more features; object tokens and multi-dimensional charts. The object token feature makes it possible for the token to be an object with an identity and with attributes. The function chart can contain several tokens, of the same or of different classes. Each step action is associated with a token class. For example, initially actions associated with the token class foo are executed once every time a token that is an instance of the class foo or one of its subclasses is entered into the step. The token attributes can be referenced and changed from the step actions. Each transition receptivity is associated with a token class. The receptivity is enabled and may fire as soon as at least one token of the associated class is present in the step preceding the transition. The receptivity has the attributes condition, event, and action. The condition may involve the attributes of the token in the preceding step. The condition may also involve the presence of other tokens in the preceding step, and their attributes. When the transition fires the actions associated with the receptivity are executed. The default action is to move a token from the preceding step to the succeeding step. It is, however,

Fig. 6

A grafchart marker and an object token.

The approach is, however, not enough in order to achieve the same expressibility that is available in high-level Petri nets. Therefore a special type of transition, a PN-transition (Petri Net transition), has been added. The PN-transition can have multiple inputs and multiple outputs, i.e., multiple preceding steps and succeeding steps. The inputs and outputs are inscribed with a number. In the receptivities it is possible to specify that a token should reside in the step connected to input x and that, when the transition is fired, the token should be deleted, moved to a certain succeeding step, or that a new token should be created in a certain succeeding step. Since a token is an object and since objects to have methods also tokens may have methods. This gives a multi-dimensional structure whereby a token moving around in a chart may itself contain contain one or more charts, see Figuremulti. Th multi-dimensional

structure gives several powerful structuring possibilities.

process, [Nilsson, 1991]. In this application Grafchart is used both to structure the simulation model and the process and to implement the control system of the process. 3.3 Flexible Manufacturing Cell

Fig. 7

A multi-dimensional chart.

A toy example of this is the Russian philosophers problem, [Lakos, 1994]. This problem is like the dining philosophers problem, except that each Russian philosopher is thinking about a dining philosophers problem. A more realistic example where this can be useful is in the context of batch control. A batch is represented by a control recipe. The batch is subject to two types of operations: production of the batch or a part of the batch according to the batch procedure contained in the control recipe and allocation of production units, e.g., unit processes, to the batch. This fits nicely into a multi-dimensional structure were the control recipe is an object token that contains the batch procedure as a method. The control recipe token moves around in a function chart where the resource allocation is performed. A batch control application of H-L Grafchart is described in [Johnsson and Årzén, 1994; Johnsson and Årzén, 1996; Johnsson, 1997]. 3. APPLICATIONS Grafchart has been used in several applications. 3.1 Hydrogen Balance Advisory Control The application that has being running on-line the longest time is an oil refinery application [Årzén, 1994a]. The system uses KBS techniques coupled with numerical optimization in a decision-support system that gives on-line advice regarding the distribution of hydrogen resources in the refinery. The solution to the problem, i.e. the main reasoning cycle, is structured into three sequential substeps. Each of these substeps are internally decomposed into further substeps. The main reasoning cycle is executed once every two minutes. 3.2 Training Simulator Grafchart has been used to implement a prototype of a training simulator for a sugar crystallization

In [L´opez González et al., 1994], a system is described were Grafchart is used to implement a flexible manufacturing cell. Here, Grafchart is used in a four-layered hierarchical structure to represent the plant-wide operating phases of the control system, to describe the sequences of tasks to be executed to manufacture the parts, to describe the tasks at the workstation level, and, finally, to describe the different services offered by the device drivers in the cell. Grafchart has also been used to implement a prototype of a training simulator for a sugar crystallization process, [Nilsson, 1991]. Here, Grafchart is used both to structure the simulation model of the process and to implement the control system for the process. In [Årzén, 1995], Grafchart is integrated with DMP, a model-based diagnosis framework. The aim is to integrate the monitoring and diagnostics for sequential processes with the sequencing logic. The steps contains both actions implementing the sequence control logic and objects representing diagnostic model equations and process faults. 3.4 Batch Recipe Structuring The main application of Grafchart is recipe and resource management in multi-purpose, flexible batch production cells. A simulated scenario consisting of a batch cell has been implemented in G2. The cell consists of raw material storage tanks, mixers, buffers, batch reactors, and product storage tanks. The units are interconnected through valve batteries. The cell can produce two products D and E using three reactants A, B and C. The scenario consists of a dynamic simulator, the process control system and the operator interface. The dynamic simulator simulates the mass balances, energy balances and chemical reactions in real time. The control system contains sensors, actuators, PID controllers based recipe management system. The operator interface is shown in Figure 8. Grafchart is used at two levels, to represent the recipes and to represent the sequence control logic contained in the equipment units. A number of different ways to structure the recipes have been investigated. It is, e.g., possible to let each individual batch be represented by its own recipe and to let this recipe (called a control recipe) be represented as an ordinary Grafchart function chart. In the first example the control recipe consists solely of phases repre-

resource allocation by having special steps with object tokens representing the available equipment resources. When a batch needs a certain resource, it may only proceed if an object token representing a resource of matching type is available in the free resources step. This approach is equivalent to using Petri nets to represent resource sharing under mutual exclusion. The situation is shown in Figure 10.

Fig. 8

Process schematic

sented as procedure steps. Each phase calls the associated equipment phase through a method call. The resulting control recipe is shown in Figure 9. Fig. 10 High-Level Grafchart recipe with integrated resource allocation.

Using this approach it is possible to apply Petri net analysis methods to, e.g., check whether there is a risk for deadlock or not. The most advanced recipe structure is achieved if the multi-dimensional chart feature is used to structure the recipes. In this structure the tokens the token contains, not only information about the required equipments, but also a method described how it should be produced. The situation is shown in Figure 11.

Fig. 9

Control recipe based on recipe phases.

It is also possible to let each active batch be represented by an object token that resides in a high-level function chart that represents a generic recipe for a certain product type, a so called master recipe. Using the latter approach it is possible to integrate the

Fig. 11 High-Level grafchart recipe with the multi-dimentional chart feature.

3.5 Alarm Filtering Finally, Grafchart has also been been to used implement alarm filters. Information overload due to large numbers of warnings and alarms is a common problem in, e.g., the process industry. This typically occurs in fault situations when a primary alarm is accompanied by large numbers of secondary alarms. Another case is nuisance alarms caused by improperly tuned alarm limits. One way of handling excess alarms is to use alarm filters. The task of the alarm filter is to filter out alarms and to aggregate multiple alarms into high-level alarms. In many cases it is the combination of multiple alarms that have occurred within a certain time period that gives the best indication of what is happening in the process. Grafchart can be used to represent alarm (event) patterns. The approach is based on the possibility to use a finite state machine as an acceptor for strings in a formal language. Since Grafchart is an extended state machine with temporal facilities it is possible to accept more general expressions than the regular expressions that are possible with ordinary state machines. The occurrence of an alarm is associated with a transition event. The representation of the simple sequence A1, A2, A3 where Ai are low-level alarms is shown in Figure 12.

Fig. 12 A simple sequence pattern.

When A1 occurs, a token will be created in the step following the transition associated with A1. The token represents the sequence that is currently being matched. The token points to an object that contains a list attribute that stores the events as they occur together with the time when the events occurred. When the last event in the pattern has occurred, the token reaches the final step. Here, a high-level alarm is issued to the operator. This alarm may suppress the associated low-level alarms that have generated the high-level alarm. The high-level alarm can also be an empty alarm. In that case, the low-level alarms are suppressed without the generation of any high-level alarm, i.e., the low-level alarms are filtered out.

Due to the sampled nature of the control system and to measurement noise, in some cases the relative ordering between a pair of low-level alarms may be unimportant. Situations also exist when one wants to specify that n out of m alarms should have occurred, or that some alarms in a pattern could be omitted. By utilizing the possibilities in Grafcet for parallel and alternative paths, different sequence patterns of these types can be easily expressed. In many cases the timing between alarms carries information. Situations exist when it is important to be able to specify that one alarm should be followed by another alarm within a certain time, after a certain time, or within a time window. Likewise, one can think of situations when it is important to be able to specify that all alarms in a pattern should occur within a certain time period. Temporal constraints between alarms can be expressed with the help of the step attribute T. This attribute contains the number of time units since the step last was activated. The possibility of having multiple tokens in a chart can be utilized in several ways. For example, it gives the possibility of representing multiple overlapping partially matched alarm sequences. Representation of different event patterns in Grafchart is presented in detail in [Årzén, 1996a]. 4. CONCLUSIONS Grafchart is an extension of Grafcet with concepts from high-level programming languages and from High-Level Petri nets. Grafchart is aimed at supervisory control applications. However, it can be used for any application that involves sequences of operations, a controlled flow of execution, and where a a graphical configuration and end-user interface is important. It is a strong advantage to use the same graphical language on the supervisory level that already is used on the PLC-level in the form of Grafcet or SFC. The support for parameterization increases the reuse possibilities and makes it possible to build up libraries of macro or procedure steps that contains generic solutions. The support for methods and message passing makes it possible to combine graphical function chart programming with object-oriented programming. The possibilities to have object tokens and multi-dimensional charts strongly enhances the structuring possibilities of Grafchart and open up new application types, e.g., batch control recipe management. This work was supported by the TFR project “Integrated Control and Diagnosis”, TFR-92-956 and by the NUTEK REGINA project “High-Level Grafcet for supervisory sequential control”.

REFERENCES ÅRZÉN, K.-E. (1991): “Sequential function charts for knowledge-based, real-time applications.” In Proc. Third IFAC Workshop on AI in Real-Time Control. Rohnert Park, California. ÅRZÉN, K.-E. (1993): “Grafcet for intelligent real-time systems.” In Preprints IFAC 12th World Congress. Sydney, Australia. ÅRZÉN, K.-E. (1994a): “Grafcet for intelligent supervisory control applications.” Automatica, 30:10. ÅRZÉN, K.-E. (1994b): “Parameterized high-level Grafcet for structuring real-time KBS applications.” In Preprints of the 2nd IFAC Workshop on Computer Software Structures Integrating AI/KBS in Process Control Systems, Lund, Sweden. ÅRZÉN, K.-E. (1995): “Integrated control and diagnosis of sequential processes.” In Preprints of the IFAC Workshop on On-line Fault Detection and Supervision in the Chemical Process Industries. Newcastle, UK. ÅRZÉN, K.-E. (1996a): “A Grafcet based approach to alarm filtering.” In Proc. of the IFAC World Congress 1996. ÅRZÉN, K.-E. (1996b): “Grafchart: A graphical language for sequential supervisory control applications.” In IFAC’96, Preprints 13th World Congress of IFAC. San Francisco, California. DAVID, R. and H. ALLA (1992): Petri Nets and Grafcet: Tools for modelling discrete events systems. Prentice-Hall International (UK) Ltd.

GENSYM COORPORATION (1995): G2 Reference Manual, Version 4.0. Gensym Coorporation, 125 Cambridge Park Drive, Cambridge, MA 02140, USA. HAREL, D. (1987): “Statecharts: A visual formalism for complex systems.” Science of Computer Programming, No 8, pp. 231–274. JENSEN, K. and G. ROZENBERG (1991): High-level Petri Nets. Springer Verlag. JOHNSSON, C. (1997): “Recipe-Based Batch Control Using High-Level Grafchart.” Licentiate thesis ISRN LUTFD2/TFRT--3217--SE. Dept. of Automatic Control, Sweden. Available at http:://www.control.lth.se/˜lotta/papers.html.

JOHNSSON, C. and K.-E. ÅRZÉN (1994): “Highlevel Grafcet and batch control.” In Symposium ADPM’94—Automation of Mixed Processes: Dynamical Hybrid Systems. Brussels, Belgium.

JOHNSSON, C. and K.-E. ÅRZÉN (1996): “Batch recipe structures using High-level Grafchart.” In Proc. of the IFAC World Congress 1996. LAKOS, C. (1994): “Object Petri Nets – definition and relationship to coloured nets.” Technical Report R94-3. Department of Computer Science, University of Tasmania, GPO Box 252C, Hobart Tasmania 7001, Australia. ´ GONZÁLEZ, J. M., J. I. LLORENTE GONZÁLEZ, LOPEZ J. M. SANTAMAR´IA YUGUEROS, O. PEREDA MART´INEZ, and E. ALVAREZ DE LOS MOZOS (1994): “Graphical methods for flexible machining cell control using G2.” In Proc. of the Gensym European User Society Meeting, Edinburgh, October. MOORE, R., H. ROSENOF, and G. STANLEY (1990): “Process control using a real time expert system.” In Preprints 11th IFAC World Congress. Tallinn, Estonia. NILSSON, B. (1991): “En on-linesimulator för operatörsstöd,” (An on-line simulator for operator support). Report TFRT-3209. Department of Automatic Control, Lund Institute of Technology. SHAW, W. (1982): Computer Control of Batch Processes. EMC Controls Inc, Cockeysville, MD.