To Hans and Josefine

Published by Department of Automatic Control

Lund Institute of Technology
Box 118
SE-221 00 LUND
Sweden

ISSN 02805316
ISRN LUTFD2/TFRT1051SE

 c 1999 by Charlotta Johnsson

All rights reserved

Printed in Sweden by Lunds Offset AB

Lund 1999
Contents

Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1 Contribution of the Thesis . . . . . . . . . . . . . . . . . 15
1.2 Published Papers . . . . . . . . . . . . . . . . . . . . . . . 16
1.3 Outline of the Thesis . . . . . . . . . . . . . . . . . . . . 18

2. Petri Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2 Formal Definition . . . . . . . . . . . . . . . . . . . . . . 24
2.3 Petri Net Properties . . . . . . . . . . . . . . . . . . . . . 26
2.4 Petri Net Analysis Methods . . . . . . . . . . . . . . . . . 26
2.5 Generalized Petri Nets . . . . . . . . . . . . . . . . . . . 29
2.6 Other Petri Net Classes . . . . . . . . . . . . . . . . . . . 30
2.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3. Grafcet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2 Dynamic Behavior . . . . . . . . . . . . . . . . . . . . . . 37
3.3 Formal Definition . . . . . . . . . . . . . . . . . . . . . . 40
3.4 Grafcet vs Petri Nets . . . . . . . . . . . . . . . . . . . . 46
3.5 Grafcet vs Finite State Machines . . . . . . . . . . . . . 47
3.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5
Contents

4. High-Level Nets . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.1 Coloured Petri Nets . . . . . . . . . . . . . . . . . . . . . 50
4.2 Coloured Grafcet . . . . . . . . . . . . . . . . . . . . . . . 57
4.3 Object Petri Nets and LOOPN . . . . . . . . . . . . . . . 60
4.4 OBJSA Nets . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.5 Other High-Level Languages Influenced by Petri Nets . 63
4.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5. Grafchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.1 Graphical Language Elements . . . . . . . . . . . . . . . 68
5.2 Actions and Receptivities . . . . . . . . . . . . . . . . . . 73
5.3 Parameterization and Methods . . . . . . . . . . . . . . . 74
5.4 Grafchart the basic version . . . . . . . . . . . . . . . . 76
5.5 Grafchart the high-level version . . . . . . . . . . . . . 86
5.6 Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 100
5.7 Foundations of Grafchart . . . . . . . . . . . . . . . . . . 104
5.8 Grafchart vs Grafcet/Petri Nets . . . . . . . . . . . . . . 106
5.9 Implementation . . . . . . . . . . . . . . . . . . . . . . . . 118
5.10 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . 128
5.11 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

6. Batch Control Systems . . . . . . . . . . . . . . . . . . . . . . 131

6.1 Batch Processing . . . . . . . . . . . . . . . . . . . . . . . 132
6.2 Batch Control . . . . . . . . . . . . . . . . . . . . . . . . . 134
6.3 The Batch Standard ISA-S88.01 . . . . . . . . . . . . . . 134
6.4 Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
6.5 Industry Practice . . . . . . . . . . . . . . . . . . . . . . . 142
6.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

7. Batch Control Systems and Grafchart . . . . . . . . . . . . 149

7.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 149
7.2 Grafchart for Batch Control . . . . . . . . . . . . . . . . 151

6
 Contents

7.3 A Batch Scenario Implemented in G2 . . . . . . . . . . . 155

7.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

8. Recipe Structuring using Grafchart . . . . . . . . . . . . . 164

8.1 Control Recipes as Grafchart Function Charts . . . . . . 165
8.2 Control Recipes as Object Tokens . . . . . . . . . . . . . 170
8.3 Multi-dimensional Recipes . . . . . . . . . . . . . . . . . 175
8.4 Process Cell Structured Recipes . . . . . . . . . . . . . . 180
8.5 Resource Allocation . . . . . . . . . . . . . . . . . . . . . 184
8.6 Distributed Execution . . . . . . . . . . . . . . . . . . . . 186
8.7 Grafchart Structured Recipes vs Industry Practice . . . 188
8.8 Other Batch Related Applications of Grafchart . . . . . 191
8.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

9. Recipe Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 193

9.1 The Deadlock Problem . . . . . . . . . . . . . . . . . . . . 194
9.2 Batch Recipes . . . . . . . . . . . . . . . . . . . . . . . . . 196
9.3 Batch Recipe Transformation . . . . . . . . . . . . . . . . 199
9.4 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
9.5 Using the Analysis Results . . . . . . . . . . . . . . . . . 206
9.6 Grafchart Supervisor . . . . . . . . . . . . . . . . . . . . 213
9.7 Other Analysis Approaches . . . . . . . . . . . . . . . . . 221
9.8 Resource Allocation and Scheduling . . . . . . . . . . . . 224
9.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

10.1 Future Research Directions . . . . . . . . . . . . . . . . . 227

11. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

A. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

B. Petri Net Reduction Methods . . . . . . . . . . . . . . . . . 240

7
Contents

C. Formal Definition of Grafchart . . . . . . . . . . . . . . . . 243

C.1 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
C.2 Grafchart the Grafcet version . . . . . . . . . . . . . . . 247
C.3 Grafchart the basic version . . . . . . . . . . . . . . . . 255
C.4 Grafchart the high-level version . . . . . . . . . . . . . 272
C.5 Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

D. Dynamic Simulator . . . . . . . . . . . . . . . . . . . . . . . . 281

D.1 Total Mass Balance . . . . . . . . . . . . . . . . . . . . . 282
D.2 Component Mass Balance . . . . . . . . . . . . . . . . . . 282
D.3 Energy Balance . . . . . . . . . . . . . . . . . . . . . . . . 282
D.4 Level and Volume . . . . . . . . . . . . . . . . . . . . . . 284
D.5 Reaction Rates . . . . . . . . . . . . . . . . . . . . . . . . 284
D.6 Implementation . . . . . . . . . . . . . . . . . . . . . . . . 285
D.7 Notation and Constants . . . . . . . . . . . . . . . . . . . 287

E. An Introduction to G2 . . . . . . . . . . . . . . . . . . . . . . 289

8
 Acknowledgments

Acknowledgments
The work presented in this thesis started in August 1993 when I started
as a PhD-student at the department. Now, in February 1999, when the
thesis is completed, there are several people that I would like to extend
my special thanks to.

I have enjoyed my employment at the department very much. A great part

of this is thanks to the persons working here; four cheerful and caring
secretaries, a handful very helpful technicians, many skillful professors,
associate professors and lecturers, and a lot of friendly, joyful, crazy and
funny PhD-students. Thanks to all of you!

Throughout the project, Karl-Erik rzn, my advisor, has helped and en-
couraged me. He has been an excellent advisor with many great ideas and
a deep knowledge in my research area. Thank you Karl-Erik!

Karl Johan strm, the head of the department, led me into the world
of Automatic Control and for this I am very grateful. He has also been a
never ending source of inspiration and optimism.

During the work with the thesis, I have had the opportunity to visit and
work with colleagues from universities abroad. I have enormously appre-
ciated these sessions and I would like to thank Professor Ren David and
Professor Hassane Alla at Laboratoire dAutomatic de Grenoble, Institut
National Polytechnique de Grenoble, France, Professor Venkat Venkata-
subramanian at Laboratory for Intelligent Process Systems, Purdue Uni-
versity, USA, and Jo Simensen at Department of Engineering Cybernetics,
Norwegian University of Science and Technology, Norway.

An industrial reference committee has been linked to the project and

the feedback from the members has been very valuable. Participating
in this committee were: Tage Jonsson (ABB Industrial Systems), Lars
Pernebo (Alfa Laval Automation), Stefan Johansson (Astra Production
Chemicals), Bjrn Perned (Van den Berghs Food), and Carl-Erik Flod-
mark (Kabi Pharmacia).

The work has been supported by NUTEK, the Swedish National Board
for Industrial and Technical Development, Project Regina, 97-00061 and
by TFR, the Swedish Research Council for Engineering Sciences, 95-759.

I would also like to thank some people, not directly involved in the project.
Thanks to my friends for giving me many great moments far away from
batch control systems. Thanks to my parent and my sisters for always

9
Contents

supporting and encouraging me. The last and most important thanks go
to Hans, my beloved husband, for his love, enthusiasm and help through
times of hard work. As a sign of my gratitude, the thesis is dedicated to
him and to our newborn daughter Josefine.

10
1
Introduction

Industrial manufacturing processes and production processes can gener-

ally be classified as continuous, discrete or batch. The classification de-
pends mainly upon the appearance of the process output, [Fisher, 1990].
The output of a continuous process is a continuous flow. The output from
a discrete process is individual units or groups of individual units. The
output of batch processes appears as lots or quantities of materials. The
product produced by a batch process is called a batch.

Batch processes are common and important in, e.g., the chemical, food
and pharmaceutical industries. Batch processes are often of the multi-
purpose, multiproduct type, which means that different batches of differ-
ent products can be produced in the same plant at the same time. The
specification of how to produce a batch is called a recipe. The batch plants
can have a network structure which means that the batch can take sev-
eral different paths when passing through the plant. The combination of
multiproduct and network-structured batch plants is the most effective
and the most economical profitable plant structure. However, the multi-
product and network-structured batch plants are also the most difficult
plants to control.
Economical interests have caused an increased interest for small scale pro-
ductions, quick product changes, and order-based production. This means
that there is a need for a flexible way of modifying the production in a
plant. Recipe-based production is suitable for these purposes. Batch pro-
cesses and the control of such processes have therefore lately received
great interest. Even though batch production traditionally has belonged
to the food, pharmaceutical and chemical industries, the idea of having a
recipe-based system is applicable also in many other industries.
Recipe-based control can be seen as a special type of sequential control.
Sequential control is important, not only in batch production but also in
the continuous and discrete industries. All industries have devices that

11
Chapter 1. Introduction

have to be controlled. This is usually done sequentially, e.g. a device should

first be opened and then closed, or first turned-on and later turned-off.
Industrial production runs in different modes, e.g. start-up, operation and
shut-down. In addition to this it is sometimes possible to decompose the
production into sequential steps. Sequential control is therefore important
both on a local level, compare the device control, and on a supervisory
level, compare different operation modes.
Grafcet is a well known and well accepted representation format used for
sequential control at the local control level. Grafcet has a well accepted
and intuitive graphical syntax, and a well specified semantics. Two in-
ternational standards, IEC 848 and IEC 1131-3, define Grafcet and as a
result of this Grafcet has become well known in industry. In the standards,
however, Grafcet is refered to as Sequential Function Charts (SFC). In
industry, Grafcet is mainly used for PLC implementations, i.e., for local
control. No commonly accepted representation format exists for sequen-
tial control at the supervisory control level. Grafcet is based on Petri nets.
Formal analysis methods that can be used to verify properties of a system
exist for Petri nets. In parallel with the development of Grafcet, Petri nets
have been developed into high-level Petri nets, a richer and more elabo-
rate version of Petri nets. Even though a strong relation exists between
Grafcet and Petri nets, Petri nets are not well-known in industry.
From a system theoretic point of view sequential control logic belongs to
the area of Discrete Event Dynamic Systems (DEDS). This is a relatively
new area in the control community where, currently, a large amount of
research is performed, e.g., [Gunnarsson, 1997], [Charbonnier, 1996], [Tit-
tus, 1995], [Cassandras, 1993], [Ho, 1991], etc. A large number of alter-
native approaches have been introduced for modeling, analysis, and, in
certain restricted cases also for synthesis of DEDS. However, their practi-
cal use is severely restricted. This is due to the combinatorial complexity
which makes it very difficult to scale up DEDS approaches so that they
can handle industrial size applications.
The research on discrete event dynamic systems can be divided into two
main areas:

1. Formal methods for verification and synthesis.

2. Improved tools and languages for controller implementation.

In the first research area, formal specification languages and formal mod-
eling techniques are used to describe the behavior of a system. Formal
analysis techniques are then used to verify certain critical properties. A
number of approaches have been developed. They are based on, e.g., state

12
machines, Petri nets, logics, and process algebras. The approaches must
provide appropriate means for modeling the process and the controller.
The model must be able to represent the dynamics and reactive nature of
the process, and allow for proper expression of timing properties. Hence,
a strong focus of formal methods is modeling and modeling languages.
Most of the proposed approaches are only concerned with verification. The
verifier is presented with a formal model of the process and the control
system and a specification of the desired behavior of the system. The
verification problem consists of demonstrating that the model satisfies
the specification. In the synthesis problem a specification is given that the
process should satisfy. The synthesis problem consists of the construction
of a controller that ensures that the combined model of the process and
the controller fulfills the specification.
One formal method approach that has gained a lot of interest in the control
community is the Supervisory Control Theory (SCT) [Ramadge and Won-
ham, 1989]. This approach has also been combined with Grafcet [Char-
bonnier, 1996], [Charbonnier et al., 1995]. SCT has also been developed
in to Procedural Control Theory (PCT) [Sanchez et al., 1995]. Petri nets
have been used as the basis for controller analysis and synthesis, in the
form of Controlled Petri Nets [Holloway and Krogh, 1994], [Holloway and
Krogh, 1990].
The second research area focuses on development of tools and languages
for implementation of discrete event controllers. With better abstraction
and structuring possibilities it is easier to get a good overview of the con-
trol problem and the implementation is simplified drastically. The focus in
this research area is, in most cases, on graphical programming languages
rather than on modeling and specification languages.
The two research areas complement each other. Most formal approaches
only support verification. The designer must develop and implement the
controller manually. If the approach also supports synthesis, a controller
is constructed and presented in terms of a specification language. Also in
this case, the user must implement the controller. It is therefore important
to have good structuring mechanisms and good programming languages
for controller implementations. Of course, it is also important to be able
to use formal methods for verification of systems that have already been
designed and implemented with, e.g., a high-level implementation lan-
guage.
Two lines of research have been pursued in this thesis

Developing a programming language and tool for sequential control

applications.

13
Chapter 1. Introduction

Finding suitable ways to represent recipe-based control. The appli-

cation area has been batch processes.

The two lines can be regarded as two separate activities. However, there
has been a strong interaction. Both research lines belong to the latter of
the two research areas of DEDS. However, elements better categorized to
the first area can be found.
The work of developing a programming language and tool for sequen-
tial control applications has consisted in providing better abstraction and
structuring mechanisms for Grafcet. A secondary aim of the work has
been to make use of the available formal methods that exists for Petri
nets and Grafcet. The first goal is met by Grafchart, a new high-level pro-
gramming language for sequential control applications presented in this
thesis. Grafchart can, unlike Grafcet, be used to implement all levels in a
control system, supervisory as well as local. The situation, of having bet-
ter abstraction and structuring possibilities, can be compared with moving
from assembly languages to object-oriented high-level languages in ordi-
nary programming. Grafcet can be compared to an assembly language
whereas Grafchart is a high-level object-oriented language. The approach
taken for the secondary goal is to show that Grafchart can be translated
into Grafcet and/or into Petri nets. The formal methods for analysis of
Petri nets or Grafcet can then be applied.
The development of Grafchart has, as much as possible, followed the
Grafcet standard. Grafchart has a syntax similar to Grafcet, i.e., it is
based on the concepts of steps, representing the states, and transitions,
representing the change of state. Grafchart exists in two versions: one
basic version and one high-level version. The basic version is a Grafcet-
based model with an extended syntax with improved abstraction facilities.
A toolbox implementation exists. When the work presented in this the-
sis started, the basic version of Grafchart was already available, [rzn,
1994a]. The high-level version of Grafchart contains additional high level
programming language constructs and features inspired by high-level
Petri nets. Also for the high-level version of Grafchart, a toolbox has been
implemented.
Recipe-based control can with advantage be represented sequentially by a
graphical programming language. The language should have an intuitive
and clear syntax and must have good abstraction facilities. This is pro-
vided by Grafchart. In the thesis it is shown how Grafchart can be used
for recipe structuring both at the lowest level of control and for the over-
all structuring. A recent international standard, IEC 61512 [IEC, 1997],
provides a formal definition of terminology, models and functionality of

14
 1.1 Contribution of the Thesis

batch systems. The standard was originally an ISA standard, ISA S88.01,
[ISA, 1995], and is therefore often refered to as the ISA S88.01 standard.
The standard actually mentions the possibility to use Grafcet to control a
batch process, i.e., to structure a recipe and to perform the actions associ-
ated with it. However, it is only suggested for the lowest level of control.
No suggestions are made for how to do the overall structuring of a recipe.
The main application area of Grafchart and of this thesis is recipe-based
control of batch systems. In the thesis it is shown how Grafchart can be
used for recipe structuring both at the lowest level of control and for the
overall structuring. By using the features of Grafchart in different ways,
recipes can be represented in a number of alternative ways. All comply
with the ISA S88.01 standard. The different structures are presented and
their advantages and drawbacks are discussed. A simulation of a multi-
purpose, network structured batch plant has served as a test platform.
The thesis also shows how the recipes, structured with Grafchart, can be
transformed into a Petri net and analyzed with respect to deadlock situ-
ations. The results can be used for static deadlock prevention or dynamic
deadlock avoidance. Grafchart, the recipe-execution system, and the batch
plant are implemented in G2, an object oriented programming environ-
ment. G2 is also an industrial environment which makes it possible to
directly use the results in industry.

1.1 Contribution of the Thesis

The contributions of this thesis are the following:

The syntax of Grafchart is formally defined.

The semantics of Grafchart is defined and the translation between
Grafchart and Grafcet and between Grafchart and Petri nets is pre-
sented.

It is shown how Grafchart can be used in recipe-based batch control

both at the recipe level and at the equipment control level. A num-
ber of alternative ways of representing recipes are presented and
discussed.

It is shown how resource allocation can be integrated with recipe

execution using ideas from concurrent programming and Petri nets.

It is shown how the batch recipes can be analyzed using existing

Petri net methods.

15
Chapter 1. Introduction

The work presented in this thesis is a continuation of the work presented

in the licentiate thesis:

* Johnsson C. (1997): Recipe-Based Batch Control Using High-Level

Grafchart, Licentiate thesis, TFRT 3217, Dept. of Automatic Con-
trol, Lund Institute of Technology, Sweden, [Johnsson, 1997]

The work has received a lot of interest by the members of the ISA S88.01
standardization committee.

1.2 Published Papers

The work presented in this thesis is primarily based on the following

conference presentations and journal articles:

Johnsson C. and rzn K.-E. (1994): High-Level Grafcet and Batch

Control, Presented at ADPM94 (Automation of Mixed Processes: Dy-
namical Hybrid Systems), Brussels, Belgium, [Johnsson and rzn,
1994]

Johnsson C. and rzn K.-E. (1996): Object-Tokens in High-Level

Grafchart, Presented at CIMAT96 (Computer Integrated Manufac-
turing and Automation Technology), Grenoble, France, [Johnsson
and rzn, 1996b]

rzn K.-E. and Johnsson C., and (1996): Object-oriented SFC and
ISA-S88.01 recipes, Presented at World Batch Forum, Toronto,
Canada, [rzn and Johnsson, 1996a]

Johnsson C. and rzn K.-E. (1996): Batch Recipe Structuring us-

ing High-Level Grafchart, Presented at IFAC96 (International Fed-
eration of Automatic Control), San Francisco, USA, [Johnsson and
rzn, 1996a]

rzn K.-E. and Johnsson C. (1996): Object-oriented SFC and ISA-

S88.01 recipes, ISA Transactions, Vol. 35, p. 237-244, [rzn and
Johnsson, 1996b]

rzn K.-E. and Johnsson C. (1997): Grafchart: A Petri Net/Gr-

afcet Based Graphical Language for Real-time Sequential Control
Applications, Presented at SNART97 (Swedish Real-Time Systems
Conference), Lund, Sweden, [rzn and Johnsson, 1997]

16
 1.2 Published Papers

Johnsson C. and rzn K.-E. (1998): On recipe-based structures

using High-Level Grafchart, Presented at ADPM98 (Automation of
Mixed Processes: Dynamical Hybrid Systems), Reims, France, [Johns-
son and rzn, 1998e]

Johnsson C. and rzn K.-E. (1998): On recipe-based structuring

and analysis using Grafchart, Accepted for publication in European
Journal of Automation, [Johnsson and rzn, 1998f]

Johnsson C. and rzn K.-E. (1998): Grafchart and batch recipe

structures, Presented at WBF98 (World Batch Forum), Baltimore,
USA, [Johnsson and rzn, 1998a]

Johnsson C. and rzn K.-E. (1998): Grafchart applications, Pre-

sented at GUS98 (Gensym User Society), Newport, USA, [Johnsson
and rzn, 1998c]

Johnsson C. and rzn K.-E. (1998): Grafchart and its relations

to Grafcet and Petri nets, Presented at INCOM98 (Information
Control Problems in Manufacturing), Nancy, France, [Johnsson and
rzn, 1998b]

Johnsson C. and rzn K.-E. (1998): Grafchart for recipe-based con-

trol, Computers and Chemical Engineering 22:12, 1998, [Johnsson
and rzn, 1998d]

Johnsson C. and rzn K.-E. (1998): Petri net analysis of batch

recipes structured with Grafchart, Presented at FOCAPO98 (Foun-
dations of Computer Aided Process Operation), Snowbird, USA,
[Johnsson and rzn, 1998g]

Johnsson C and rzn K.-E. (1999): Grafchart and batch-recipe

structures(extended version of the WBF98 paper), Accepted for
presentation at Interphex99, New York, USA, [Johnsson and rzn,
1999a]

Johnsson C and rzn K.-E. (1999): Grafchart and Grafcet: A com-

parison between two graphical languages aimed for sequential con-
trol applications, Accepted for presentation at IFAC99, Beijing,
China, [Johnsson and rzn, 1999b]

17
Chapter 1. Introduction

Grafchart has also been used in other areas of batch control. This work is
only presented marginally in this thesis. More information can be found
in the following conference presentations and journal articles:

Viswanathan S., Venkatasubramanian V., Johnsson C., and rzn

K.-E. (1996): Knowledge Representation and Planning Strategies
for Batch Plant Operating Procedure Synthesis, Presented at AIChE
annual meeting, Chicago, USA, [Viswanathan et al., 1996]
Simensen J., Johnsson C. and rzn K.-E. (1996): A Framework
for Batch Plant Information Models, Internal report, TFRT-7553,
Dept. of Automatic Control, Lund Institute of Technology, Sweden,
[Simensen et al., 1996]
Simensen J., Johnsson C. and rzn K.-E. (1997): A Multiple-View
Batch Plant Information Model, Presented at PSE97/ESCAPE-7,
Trondheim, Norway and Computers and Chemical Engineering,
21:1001, 1997, [Simensen et al., 1997a] and [Simensen et al., 1997b]
Viswanathan S., Johnsson C., Srinivasan R., Venkatasubramanian
V. and rzn K.-E. (1998): Automating Operating Procedure Syn-
thesis for Batch Processes: Part 1. Knowledge Representation and
Planning Framework, Computers and Chemical Engineering, 22:11,
1998, [Viswanathan et al., 1998a]
Viswanathan S., Johnsson C., Srinivasan R., Venkatasubramanian
V. and rzn K.-E. (1998): Automating Operating Procedure Syn-
thesis for Batch Processes: Part 2. Implementation and Application,
Computers and Chemical Engineering, 22:11, 1998, [Viswanathan
et al., 1998b]

1.3 Outline of the Thesis

The work presented in the thesis is a continuation of the work presented in

the licentiate thesis, [Johnsson, 1997]. This thesis consists of two parts.
The first part, Chapter 2 5, focuses on programming languages and
mathematical models for sequential control. It ends with a presentation of
Grafchart, which is the language used later in the thesis. Chapter 2, 3 and
4 were, with minor modifications, published also in the licentiate thesis.
Chapter 5 is an extended and reworked version of the two corresponding
chapters, Chapter 56, in the licentiate thesis.
The second part, Chapter 69, describes the main application of Graf-
chart, recipe-based batch control. It describes batch control systems in

18
 1.3 Outline of the Thesis

general and a recipe management system for batch processes in particu-

lar. It also deals with analysis of batch recipes. Parts of Chapter 6, 7 and
8 were published in the licentiate thesis. However, these chapters now
contain additional material. Chapter 9 is new and was not included in
the licentiate thesis.
The outline of the thesis is the following:
Chapter 2 4, present the foundation on which Grafchart is based. In
Chapter 2, Petri nets are presented. Petri nets are a mathematical and
graphical model. One main characteristic of the nets are their possibility
to be theoretically analyzed. They can be used for simulation, verifica-
tion and analysis of discrete systems. Grafcet is described in Chapter 3.
Grafcet, or Sequential Function Chart (SFC), is a mathematical model
aimed at formal specification and realization of programmable logic con-
trollers (PLC). In order to model large systems efficiently, the Petri net
model has been enlarged and developed into high-level Petri nets. In
Chapter 4, these nets, and other closely related High-Level Nets are
described.
Chapter 5 describes Grafchart. Grafchart is the name of both a mathe-
matical sequential control model and a toolbox implementation. Grafchart
combines the graphical features of Grafcet/SFC, with high-level program-
ming languages constructs, object-oriented programming structures and
ideas from high-level Petri nets. Grafchart exists in two versions; the
basic version and the high-level version. Both versions are presented.
Grafchart is aimed, not only at local level sequential control problems
like PLC-programming, but also at supervisory sequential control appli-
cations. The Grafchart toolbox is implemented in G2.
Chapter 6 9 present batch control systems, which is the main application
area of Grafchart. Chapter 6 describes batch control systems in general
terms and gives an overview of ISA S88.01. The description of how to
produce a batch is called a recipe. The chapter also includes a presentation
of the batch control industry practice of today. Chapter 7 combines batch
control systems and Grafchart. It is shown how the different features
of Grafchart can be used to implement a batch control system and how
they fit the ISA S88.01 standard.
In Chapter 8 different recipe structures, all implemented with Grafchart,
are presented and discussed. By combining different features of Grafchart,
the recipe structures can be largely variated. Advantages and drawbacks
of the different structures are given. The chapter also contains a dis-
cussion on resource allocation, and a presentation of different possible
strategies is given. Recipe structuring using Grafchart allows an in-

19
Chapter 1. Introduction

tegration between Petri nets based analysis methods and Grafcet/SFC

based structuring and execution.
In Chapter 9 it is shown how the batch recipes can be analyzed and
how possible deadlock situations due to improper resource allocation can
be found. The approach taken is to transform the batch recipes that are
structured with Grafchart to a Petri net. The size of the Petri net structure
can be reduced and then treated with already existing analysis methods.
An example is used to show how this can be done. The recipe analysis
results can be used for static deadlock prevention or dynamic deadlock
avoidance. Both alternatives are presented and discussed in the chapter.
The last chapter, Chapter 10, is dedicated to a summary of the thesis.
Some conclusions are drawn and possible future work is proposed.

Happy Reading!

20
2
Petri Nets

Petri nets were proposed by the German mathematician Carl Adam Petri
in the beginning of the 1960s, [Petri, 1962]. Petri wanted to define a gen-
eral purpose graphical and mathematical model describing relations be-
tween conditions and events. 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 modeled system. The graphical
feature makes Petri nets suitable for visualization and simulation.

The Petri net model has two main interesting characteristics. Firstly, it
is possible to visualize behavior like parallelism, concurrency, synchro-
nization and resource sharing. Secondly, there exists a large number of
theoretical methods for analysis of these nets. Petri nets can be used at all
stages of system development: modeling, mathematical analysis, specifi-
cation, simulation, visualization, and realization. Petri nets have been use
in a wide range of application areas, e.g., performance evaluation, [Molloy,
1982], [Sifakis, 1978], distributed database systems, [Ozsu, 1985], flexible
manufacturing systems, [Murata et al., 1986], [Desrochers and AlJaar,
1995], [Silva and Teruel, 1996], logic controller design, [Silva and Velilla,
1982], [Valette et al., 1983], multiprocessor memory systems, [Kluge and
Lautenbach, 1982], and asynchronous circuits, [Yoeli, 1987].

Petri nets have during the years been developed and extended and several
special classes of Petri nets have been defined. These include, e.g.: gen-
eralized Petri nets, synchronized Petri nets, timed Petri nets, interpreted
Petri nets, stochastic Petri nets, continuous Petri nets, hybrid Petri nets,
coloured Petri nets, object-oriented Petri nets, and multidimensional Petri
nets.

In this chapter a brief overview of ordinary Petri nets and generalized

Petri nets is given as well as a short description of other Petri net classes.
More detailed presentations can be found in [David and Alla, 1992], [Mu-
rata, 1989], [Peterson, 1981].

21
Chapter 2. Petri Nets

2.1 Basic Concepts

A Petri net (PN) has two types of nodes: places and transitions, see Fig-
ure 2.1. A place is represented as a circle and a transition is represented
as a bar or a small rectangle. Places and transitions are connected by
arcs. An arc is directed and connects either a place with a transition or a
transition with a place, i.e., a PN is a directed bipartite graph.

place
P
1
token
1
0
0
1
0
1
transition
T
1

P
2

T
2

Figure 2.1 A Petri net.

The set of places is called P and the set of transitions T . Each place
contains a nonnegative integer of tokens. The number of tokens contained
in a placed is denoted M ( Pi ) or mi . The marking of the net, M, is defined
by a column vector where the elements are the number of tokens contained
in the corresponding places. The marking defines the state of the PN or
the state of the system described by the PN. For the PN given in Figure 2.1
we have:

Places: P
{ P1 , P2 }
Transitions: T
{T1 , T2}
Marking: m1
1, m2
0
 
1
M

0

The set of input (upstream) transitions of a place Pi is denoted Pi and the

set of output (downstream) transitions is denoted Pi . Similar notations
exist for the input and output places of a transition.

22
 2.1 Basic Concepts

A transition without an input place is called a source transition and a

transition without an output place is called a sink transition.
Systems with concurrency can be modeled with Petri nets using the and-
divergence and the and-convergence structure, see Figure 2.2 (left). Sys-
tems with conflicts or choices can be modeled using the or-divergence and
the or-convergence structure, see Figure 2.2 (right).

and-divergence
or-divergence

or-convergence
and-convergence

Figure 2.2 Concurrency and conflicts.

State graphs and event graphs are special classes of Petri net structures.
An unmarked Petri net is a state graph (state machine) if and only if
every transition has exactly one input and one output place. If the Petri
net is marked its behavior will be equivalent to a classical state machine
if and only if it contains only one token. A Petri net is an event graph
(marked graph, transition graph) if and only if every place has exactly one
input and one output transition. In a state graph parallelism cannot be
modeled whereas alternatives or conflicts cannot be modeled in an event
graph.
Some typical interpretations of transitions and places are shown in Ta-
ble 2.1, [Murata, 1989].

Dynamic Behavior
A transition is enabled if each of its input places contains at least one
token. An autonomous PN is a PN where the firing instants are either
unknown or not indicated whereas a non-autonomous PN is a PN where
the firing of a transition is conditioned by external events and/or time.
An enabled transition in an autonomous PN may or may not fire. An en-
abled transition in a non-autonomous PN is said to be fireable when the

23
Chapter 2. Petri Nets

Input Places Transition Output Places

Preconditions Event Postconditions
Input data Computation step Output data
Input signals Signal processor Output signals
Resources needed Task or job Resources released
Conditions Clause in logic Conditions
Buffers Processor Buffers

Table 2.1 Some typical interpretations of transitions and places in Petri nets.

transition condition becomes true. A fireable transition must fire immedi-

ately. 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.

2.2 Formal Definition

An unmarked ordinary PN is a 4-tuple Q
< P , T, Pre, Post >

where:
P
{ P1 , P2 , ... Pn } is a finite, nonempty set of places.
T
{T1 , T2, ..., Tm } is a finite, nonempty set of transitions.
P T
, i.e., the sets P and T are disjoint.
Pre : P  T {0, 1} is the input incidence function.
Post : P  T {0, 1} is the output incidence function.

A marked ordinary PN is a pair R
< Q, M0 > in which Q is

an unmarked ordinary PN and M0 is the initial marking.

Pre( Pi , Tj ) is the weight of the arc connecting place Pi with transition Tj .

This weight is 1 if the arc exists and 0 if not. Post( Pi , Tj ) is the weight of
the arc connecting transition Tj with place Pi . This weight is 1 if the arc
exists and 0 if not.

24
 2.2 Formal Definition

EXAMPLE 2.2.1
Consider the Petri net given in Figure 2.3.
P1

T1

P2

T2 T3

P3 P4

T4 T5

Figure 2.3 A Petri net.

The net is described by the 5-tuple

R
< P , T, Pre, Post, M0 >
where
P
{ P1 , P2 , P2 , P4 }
T
{T1, T2, T3 , T4 , T5 }

1 0 0 0 0
0 1 1 0
0
W
[ Pre( Pi , Tj )]

0 0 0 1 0
0 0 0 0 1

0 0 0 1 1
1 0 0 0
0
W +
[ Post( Pi , Tj )]

0 1 0 0 0
0 0 1 0 0

0
1

M0

1
0
#

25
Chapter 2. Petri Nets

2.3 Petri Net Properties

The marking of a PN is a column vector whose components are the mark-
ing of place Pi . The set of reachable markings from marking M0 is denoted
M0. The firing of transition Ti from marking Mi will result in marking
Mi+1, this is denoted:

Mi [Ti > Mi+1

The firing of more than one transition is called a firing sequence and is
denoted S.

Home state A PN has a home state Mh for an initial marking M0 if,

for every reachable marking Mi M0, a firing sequence Si exists such
that Mi[ Si > Mh.

Reversible A PN is reversible for an initial marking M0 if M0 is a home

state.

Bounded A place Pi is bounded for an intital marking M0 if there is a

nonnegative integer k such that, for all markings reachable from M0, the
number of tokens in Pi is not greater than k ( Pi is said to be k-bounded).
A PN is said to be bounded for an initial marking M0 if all the places are
bounded for M0 (the PN is k-bounded if all the places are k-bounded)

Safe A PN is safe for an initial marking M0 if, for all reachable mark-
ings, each place contains at most one token, i.e., the net is 1-bounded.

Live A transition Tj is live for an initial marking M0 if, for every reach-
able marking Mi M0, a firing sequence S from Mi exists, which con-
tains transition Tj . A PN is live for an initial marking M0 if all its tran-
sitions are live from M0 .

Deadlock-free A deadlock is a marking such that no transition is en-

abled. A PN is said to be deadlock-free for an initial marking M0 if no
reachable marking Mi M0 is a deadlock.

2.4 Petri Net Analysis Methods

There are three main methods for analyzing a PN, i.e., to find out if a cer-
tain property holds; (1) the reachability graph and the related coverability
tree, (2) linear algebra methods, and (3) reduction techniques.

26
 2.4 Petri Net Analysis Methods

(1) Reachability graph and Coverability tree The basic and most
simple method is to draw the reachability graph. In this graph the nodes
correspond to the reachable markings and the arcs correspond to the firing
of transitions. In Figure 2.4 a PN and its reachability graph is shown. The
graph can be used to find out that the PN is safe, live, reversible and that
it has two repetitive components T1 T2 T4 and T1 T3 T5. Another, equivalent
name for the reachability graph is the marking graph.

P1
T4 0
0
T1 0
T2 1
1 0 0
P2 P3 0 T1 1
0 1
T3
T2 T3 0 0
0 0 0
P4 P5 0
0
T4 T5 0
T5
1

Figure 2.4 A Petri net and its reachability graph.

In an unbounded net, the number of tokens in a place can be infinite, this

makes the reachability graph undefined. An unbounded net is instead
represented by associating the symbol with the places that might have
an infinitely large number of tokens. The resulting graph is now called
the coverability tree, see Figure 2.5 (upper right). If the nodes that cor-
respond to the same marking are merged together the coverability graph
is obtained, see Figure 2.5 (lower right).

(2) Linear algebra The linear algebra methods are mathematical

methods used to determine the properties of a net. The fundamental equa-
tion of a net is given by:

Mk
Mi + W S

where S is the characteristic vector of the firing sequence S that takes

marking Mi to marking Mk. The jth element in the column vector S
corresponds to the number of firings of transition j in the sequence S.

27
Chapter 2. Petri Nets

0
T2 0
1 T1 0 0
0
0 1 T2 0
P1 0 1
1 0
T3
0 1
T1
T3 T1 1
T3 0
P2
P3

0
T2 T2 0
1 T1 0 0
0
0 1 T2 0
0 1 T1
1 0
T3
0 1
T3

Figure 2.5 A Petri net and its coverability graph (lower) and coverability tree
(upper).

The matrix W is the incidence matrix defined as:

W
W+ W
+
W
[ Post( Pi, Tj ) ]

W
[ Pre( Pi , Tj ) ]

The marking of a Petri net can be changed through the firing of its tran-
sitions. If a deadlock situation does not occur the number of firings is
unlimited. However, not all markings can be reached and not all firing
sequences can be carried out. The restrictions are given by the invariants
of the net. A marking invariant is obtained if a weighted sum of the mark-
ing of a subset of the places in a net is always constant, no matter what
the firing might be. The places contained in this subset is a conservative
component and the vector containing the weights is the P-invariant. The
conservative components of a net often have a physical interpretation. If
the firing of a certain sequence of transitions results in the same marking
as it was started from, the sequence is called a repetitive component. The
characteristic vector of the firing sequence is the T-invariant.
The P-invariants and the T-invariants of a net can be deduced by linear
algebra methods, [David and Alla, 1992].

28
 2.5 Generalized Petri Nets

(3) Reduction methods 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 properties: live, bounded,
safe, deadlock-free, with home state and conservative, [Murata and Koh,
1980].

1. Reduction R 1 : Substitution of a place

2. Reduction R 2 : Implicit place
3. Reduction R 3 : Neutral transition
4. Reduction R 4 : Identical transitions

Two reduction methods exist that preserves the invariants, [Berthelot,

1986].

1. Reduction R a : Self loop transitions

2. Reduction R b: Pure transitions

The reduction rules are developed for autonomous Petri nets. The rules
are briefly described in Appendix B.

2.5 Generalized Petri Nets

In a generalized PN weights (strictly positive integers) are associated with
the arcs. The weight associated with the arc from place p j to transition ti
is denoted w( p j , ti ) and the weight associated with the arc from transition
ti to place pk is denoted w( ti , pk). In a generalized Petri net a transition
ti is enabled if each input place p j of ti contains at least w( p j , ti ) tokens.
A firing of an enabled transition ti consists of removing w( p j , ti ) tokens
from each input place p j of ti and adding w( ti, pk ) tokens to each output
place pk of ti , see Figure 2.6. If a weight is not explicitly specified it is
assumed to be 1.
All generalized PN can be transformed into ordinary PN.

29
Chapter 2. Petri Nets

P1 P1
0
1
11
0
10
1
00 11
00
0
1 00
11
0
1 00
11
2 Firing of T1 2
T1 T1
3 3
1
0 0
1
01
1 0
11
00 01
1 0
P2 11
00
00
11 00
11
P2 11
00
00
11
00
11
2 2
T2 T2

Figure 2.6 A Generalized Petri net.

2.6 Other Petri Net Classes

A number of special classes of Petri nets have been defined. They are
briefly described in this section.

Synchronized PN
In ordinary autonomous PN an enabled transition may or may not fire,
i.e., the ordinary PN are asynchronous. In synchronized Petri nets exter-
nal events are associated with the transitions. If a transition is enabled
and the associated event occurs, the transition will immediately fire. It is
assumed that two external events can never occur simultaneously.

A synchronized PN is a triple < R , E , Sync > where:

R is a marked PN
E is the set of external events
Sync is a function from T to E {e}, where e is the always
occurring event, i.e., an event that is always true.

Timed PN
Using timed PN, systems with time dependent behavior can be described.
The timing can either be associated with the places or with the transitions.
These nets are called P-timed PN and T-timed PN respectively.

A P-timed PN is a couple < R , Time > such that:

R is a marked PN
Time is a function from the set P of places to the set of
positive or zero numbers. Time( Pi )
di . di is the timing
associated with place Pi .

30
 2.6 Other Petri Net Classes

When a token arrives in place Pi of a P-timed PN, the token must remain
in this place at least di time units. During this time the token is unavail-
able. When time di has elapsed, the token becomes available again and
can now participate in the enabling of a transition.

A T-timed PN is a couple < R , Time > such that:

R is a marked PN
Time is a function from the set T of transitions to the
set of positive or zero numbers. Time( Tj )
dj . dj is the
timing associated with transition Tj .

When a token arrives in a place of a T-timed PN, it directly enables the

output transition of this place. Before the firing of the output transition
can take place the token has to be reserved for at least dj time units. Dur-
ing this time the token is unavailable for any other activity. When dj time
units have elapsed the transition can fire and the token is removed from
the preceding place and placed in the succeeding place of the transition.

Interpreted PN
An interpreted PN is a synchronized, P-timed Petri net. Associated with
the places are operations O
{ O 1, O 2 , }. The interpreted PN has a
data processing part whose state is defined by a set of variables V

{ V1 , V2 , }. This state is modified by the operations. The variables de-
termine the value of the condition (predicate) C associated with the tran-
sition. The operation of an interpreted PN together with its environment
is shown in the left part of Figure 2.7. The right part of the same fig-
ure shows that the timing di and the operation O i are associated with
the place Pi while the event Ej and the condition C j are associated with
transition Tj . The behavior of an interpreted Petri net is strongly related
to Grafcet.

Stochastic PN
In a timed PN a fixed duration is associated with each place or with
each transition. In stochastic PN a random time is associated with the
transition. The most common hypothesis is that the timing is distributed
according to an exponential law. The marking at time t, M ( t) of a stochas-
tic PN is then an homogeneous Markov process. A Markov chain can thus
be associated with every stochastic PN and the probabilities of states in
stationary behavior can be calculated.

31
Chapter 2. Petri Nets

Interpreted Petri Net

Data Processing Part

Computation
of variables
and conditions

Oi Cj Pi Oi d i

Control Part
Tj C j Ej
Synchronized
and P-timed
Petri Net

Vk Ej

Environment

Figure 2.7 An interpreted Petri net.

Continuous PN and Hybrid PN

In a continuous PN the numbers of tokens in a place is given by a real
number. It is possible to put weights on the arcs and thereby have a gen-
eralized continuous PN, the weights can also be real numbers. A hybrid
PN contains one discrete part and one continuous part.

2.7 Summary

Petri nets can conveniently be used to model systems with e.g., concur-
rency, synchronization, parallelism and resource sharing. The graphical
nature of Petri nets also makes them suitable to use for visualization and
simulation of systems. In addition to this, the nets can be theoretically
analyzed with different analysis methods.

32
3
Grafcet

Grafcet was proposed in France in 1977 as a formal specification and

realization method for logical controllers. The name Grafcet was derived
from graph, since the model is graphical in nature, and AFCET (Association
Francaise pour la Cyberntique Economique et Technique), the scientific
association that supported the work.
During several years, Grafcet was tested in French industries. It soon
proved to be a convenient tool for representing small and medium scale
sequential systems. Grafcet was therefore introduced in the French ed-
ucational programs and proposed as a standard to the French associa-
tion AFNOR where it was accepted in 1982. In 1988 Grafcet, with minor
changes, was also adopted by the International Electrotechnical Commis-
sion (IEC) as an international standard named IEC 848, [IEC, 1988]. In
this standard Grafcet goes under the name Sequential Function Chart
(SFC). Seven years later, in 1995, the standard IEC 1131-3, with SFC as
essential part, arrived, [IEC, 1993]. The standard concerns programming
languages used in Programmable Logic Controllers (PLC). It defines four
different programming language paradigms together with SFC. No mat-
ter which of the four different languages that is used, a PLC program can
be structured with SFC.
Because of the two international standards, Grafcet, or SFC, is today
widely accepted in industry, where it is used as a representation format
for sequential control logic at the local PLC level.
In this chapter a brief overview of Grafcet is given. A more thorough
presentation can be found in [David and Alla, 1992].

3.1 Syntax

Grafcet has a graphical syntax. It is built up by steps, drawn as squares,

and transitions, represented as bars. The initial step, i.e., the step that

33
Chapter 3. Grafcet

should be active when the system is started, is represented as a double

square. Grafcet has support for both alternative and parallel branches,
see Figure 3.1.

Initial
step
Alternative paths

Transition
Parallel paths
Token

Step

Figure 3.1 Grafcet graphical syntax.

Steps
A step can be active or inactive. An active step is marked with one (and
only one) token placed in the step. The steps that are active define the
situation or the state of the system. To each step one or several actions
can be associated. The actions are performed when the step is active.

Transitions
Transitions are used to connect steps. Each transition has a receptivity.
A transition is enabled if all steps preceding the transition are active.
When the receptivity of an enabled transition becomes true the transition
is fireable. A fireable transition will fire immediately. When a transition
fires the steps preceding the transition are deactivated and the steps suc-
ceeding the transition are activated, i.e., the tokens in the preceding steps
are deleted and new tokens are added to the succeeding steps.

34
 3.1 Syntax

Actions
There are two major categories of actions: level actions and impulse ac-
tions. A level action is modeled by a binary variable and has a finite du-
ration. The level action remains set all the time while the step, to which
the action is associated, is active. When the step is deactivated, the action
is reset. A level action may be conditional or unconditional. An impulse
action is responsible for changing the value of a variable. The variable
can, but must not, be a binary variable. An impulse action is carried
out as soon as the step changes from being inactive to active. A variable
representing time may be introduced to create time-delayed actions and
time-limited actions. A level action can always be transformed into a set
of impulse actions.

In Figure 3.2 (left) two steps, x1 and x2, are shown. A level action, A, is
associated with the upper step and an impulse action, B*, is associated
with the lower step. In the same figure (right) an example is given de-
scribing the activation and deactivation of the two steps together with the
duration of the two actions.

x1
x1
A
x2

A
x2
B*
B*

Figure 3.2 Level and impulse actions.

A situation can be stable or unstable. If the transition following a step

is immediately fireable when the step becomes active, the situation is
said to be unstable. An impulse action is carried out even if the situation
is unstable whereas a level action is performed only if the situation is
stable. Between two different external events it is assumed that there is
always enough time to reach a stable situation, i.e., two external events
are assumed never to occur so close in time that the system does not have
time to reach a stable situation.

35
Chapter 3. Grafcet

Receptivities
Each transition has a receptivity. A receptivity may either be a logical
condition, an event, or an event and a condition. In Figure 3.3 (left) three
transitions and their receptivities are shown. The receptivity of the first
transition is an event, x . The receptivity of the second transition is a
condition, y, and the receptivity of the last transition is a combination of
a condition and an event, x z .

In the same figure (right) an example is given of the events and conditions
and the corresponding activation and deactivation of the two steps x1 and
x2.

x x

x1
y

y z

x2

x1

x. z
x2

Figure 3.3 Three receptivities.

Macro steps
To facilitate the description of large and complex systems macro steps
can be used. A macro step is a step with an internal representation that
facilitates the graphical representation and makes it possible to detail
certain parts separately. A macro step has one input and one output step.
When the transition preceding the macro step fires the input step of the
macro step is activated. The transition succeeding the macro step does not
become enabled until the execution of the macro step reaches its output
step. The macro step concept is shown in Figure 3.4.

36
 3.2 Dynamic Behavior

M Action

Figure 3.4 A macro step.

3.2 Dynamic Behavior

The dynamic behavior of Grafcet is defined by five rules, [David, 1995].

1. The initial situation of a Grafcet is determined by its initial steps.

2. A transition is enabled if all of its previous steps are active. A en-
abled transition is fireable if its associated receptivity is true. A
fireable transition is immediately fired.
3. Firing of a transition results in deactivation of its previous step and
a simultaneous activation of its following steps.
4. Simultaneously fireable transitions are simultaneously fired.
5. If an active step is to be simultaneously deactivated and activated
it remains active.

EXAMPLE 3.2.1
In Figure 3.5 (left) a system consisting of a tank is shown. The tank has
an inlet valve V1 and an outlet valve V2 . There are two level sensors L0
and L1 , one temperature sensor T and one heater Q.
The Grafcet for controlling the tank system is shown in Figure 3.5 (right).
When the system is started, valve V1 should open and the filling should
start. When the level in the tank reaches L0 , the heating should start.
The tank is now heated and filled in parallel. When the level in the tank
reaches L1 the filling is stopped and when the temperature reaches T the

37
Chapter 3. Grafcet

V1

X1

L1
^| Start
T1
T
X2
V2 V1

L0
T2 L0
Q

X3 x4
Q V1

T3 T T4 L1
X5 x6
0. Start
1. Fill to L1
2. Heat to T. Start at L0 T5 true
3. Empty to L0
x7
V
2

T6 L0

Figure 3.5 A tank example.

heating is stopped. When both the right level and the right temperature
are reached, the tank is emptied. This is done by opening the outlet valve
V2 . When the system is empty, i.e., when the level in the tank is below L0 ,
the sequence can be restarted. All the actions shown in Figure 3.5 (right)
are level actions, e.g., the valve V2 is open (boolean variable V2
1) as
long as step x7 is active.

Interpretation Algorithm
A Grafcet describes a logic controller, i.e., it specifies the relation be-
tween the input sequence and the output sequence. The interpretation of
a Grafcet must be without ambiguity, i.e., the same input sequence ap-
plied to a Grafcet must result in the same output sequence, independently
of the person or system interpreting the Grafcet. The output sequences
must be equivalent both with respect to the relative order between the
actions and with respect to the timing. The aim of the interpretation al-
gorithm given below, [David and Alla, 1992], is to define exactly how a
Grafcet should be interpreted so that there will never be any ambiguities.

38
 3.2 Dynamic Behavior

The interpretation algorithm is based on two assumptions:

1. The system to be controlled by the Grafcet is assumed to be slower

than the logic controller implemented by the Grafcet.
2. Two external events do never occur simultaneously.

Algorithm:

1. Initialization: activate the initial steps and execute the associated

impulse actions. Go to Step 5
2. When a new external event occurs, determine the set T1 of transi-
tions fireable on occurrence of this event. If T1 is not empty, go to
Step 3. If T1 is empty, modify, if necessary, the state of the condi-
tional actions associated with the active steps. Go to Step 2 and wait
for a new external event.
3. Fire all the fireable transitions. Go to Step 6 if the situation remains
unchanged after this firing.
4. Execute the impulse actions associated with the steps that became
active at Step 3.
5. Determine the set of transitions, T2 , that are fireable on the occur-
rence of the event e, i.e., the transitions that have a receptivity that
is true. Go to Step 3 if T2 is not empty.
6. A stable situation is reached
(a) Determine the set A0 of the level actions which should be de-
activated.
(b) Determine the set A1 of the level actions that should activated.
(c) Set all the actions that belong to A0 but not to A1 to 0. Set all
the actions that belong to A1 to 1. Go to Step 2.

The algorithm searches for stable situations (step 6). However, the algo-
rithm is based on the assumption that a finite number of iterations always
results in a stable situation. Therefore, it might seem as if it is not neces-
sary to do the search. Another simpler algorithm exists where the search
is not done. However, the shorter algorithm does not give a correct result
if the net contains unstable situations. Even though the shorter algorithm
does not always give a correct output, this algorithm is the one used most
often in industrial implementations of Grafcet, [Gaffe, 1996].
An interpretation algorithm that works in a synchronous manner has
been developed, [Gaffe, 1996]. The output of a Grafcet interpreted with

39
Chapter 3. Grafcet

the synchronous algorithm will in most cases be equivalent to that of the

algorithm with search for stability. However, since the output sometimes
differ, a Grafcet together with a synchronous interpretation algorithm has
been given a special name, SGrafcet.

Implementation Aspects
The interpretation algorithm to choose when implementing a Grafcet is
the algorithm where a search for stable situations is done. However, cer-
tain practical aspects must be taken into consideration if the real behavior
should be consistent with the interpretation (theoretical behavior). The
algorithm is based on the assumption that no external events can occur
simultaneously. However, when a logic controller, i.e., a Grafcet, is imple-
mented, two events may occur so close in time that there is no technical
mean to distinguish which event occurred first. This might cause prob-
lems in a conflict situation (alternative path). Situations like this should
therefore be avoided. This is done by making the receptivities mutually
exclusive.

3.3 Formal Definition

A Grafcet can formally be defined in many ways. The definition does only
describe the structure of a Grafcet, its actions and its receptivities. To
execute a Grafcet an interpretation algorithm must be applied. In other
words, the formal definition defines the syntax whereas the interpretation
algorithm defines the semantics.

A Grafcet can be defined as a 5-tuple

G
< V r , V a , X , T , I >

where:
V r is the set of variables originating from the plant, V ext,
or corresponding to the internal states of the Grafcet, V int.

V r
{V ext V int }

V ext and V int can either be conditions, i.e., variables that

are true or false, or events, i.e., variables that change val-
ues.

40
 3.3 Formal Definition

V a is the set of variables issued to the plant. V a can either

be continuous, i.e., a variable that is set to true or false, or
discontinuous, i.e., a variable that is given a new value.
X is the set of steps, X
{ x1 , x2 , x3 , ...}.
A step xi X is defined by

{action( xi)}

where
action( xi) defines the actions associated with the step
xi , action( xi) V a.
T is the set of transitions, T
{t1 , t2 , t3 , ...}.
A transition t T is defined by the 3-tuple

{ X P R ( t), X F O ( t), ( t)}

where
X P R ( t) is the set of previous steps of t, X P R ( t) X .
X F O ( t) is the set of the following steps of t, X F O ( t)
X.
( t) is the receptivity associated with t, ( t) {V r
true f alse}.
I is the set of initial steps, I X .

EXAMPLE 3.3.1
The Grafcet given in Figure 3.5 is represented by the 5-tuple G.

G
< V r , V a , X , T , I >

where:

V r
{ Start, L0 , T, L1 , L0 }

V a
{ V1 , Q, V2 }

41
Chapter 3. Grafcet

X
{ X 1, X 2, X 3, X 4, X 5, X6, X7}

action( X 2)
V1
action( X 3)
Q
action( X 4)
V1
action( X 7)
V2

T
{T 1, T 2, T 3, T 4, T5, T6}

X P R ( T 1)
X 1
X P R ( T 2)
X 2
X P R ( T 3)
X 3
X P R ( T 4)
X 4
X P R ( T 5)
{ X 5, X 6}
X P R ( T 6)
X 7

X F O ( T 1)
X 2
X F O ( T 2)
{ X 3, X 4}
X F O ( T 3)
X 5
X F O ( T 4)
X 6
X F O ( T 5)
X 7
X F O ( T 6)
X 1

( T 1)
Start
( T 2)
L0
( T 3)
T
( T 4)
L1
( T 5)
true
( T 6)
L0

I
{ X 1}
#

42
 3.3 Formal Definition

If macro steps are to be considered, the definition will be as follows:

A Grafcet, with macro steps taken into consideration, can be
defined as a 6-tuple
G
< V r , V a , X , T , M , I >
where:
V r is defined as before.
V r can be divided into two subsets, V rX and V rM . V rX are
the variables associated with the transitions not included
in the macro steps. V rM are the variables associated with
the transitions included in the macro steps. The two sub-
sets are not necessarily disjoint.
V a is defined as before.
V a can be divided into two subsets, V aX and V aM . V aX
are the variables associated with the steps not included
in the macro steps. V aM are the variables associated with
the steps included in the macro steps. The two subsets are
not necessarily disjoint.
X is defined as before.
action( xi) V aX
T is defined as above.
X P R ( t) {X M }
X F O ( t) {X M }
( t) {V rX true f alse}
M is the finite set of macro steps, M
{ M1, M2 , }.
A macro step Mi is defined as a 7-tuple
Mi
< V ri , V ai , X i , T i , M i , Ini , Outi >
where:
V ri, V ai , X i , T i are defined as V r , V a , X , T defined
above.
M i is the set of macro steps, M i
{ Mi,1, Mi,2, }.
The macro steps are not allowed to be infinitely re-
cursive.
Ini is the input step of the macro step, In i X i .
Outi is the output step of the macro step, Outi X i .
V rM
{V r1 V r2 }.
V aM
{V a1 V a2 }.
I is the set of initial steps, I X .

43
Chapter 3. Grafcet

EXAMPLE 3.3.2
The Grafcet given in Figure 3.6 is represented by the 6-tuple G.

G
< Vr , Va , X , T , M , I >

X1

T1 a

X2
A

T2 b

X3 X4 M1
B* C
I
X6
T3 ^| c
T6 b
X7
M1 C

T7 d
X8
T4 1 O
X5 A

T5 ^| e

Figure 3.6 A Grafcet with a macro step.

Vr
{ VrX VrM }
VrX
{a, b, c , e}

Va
{ VaX VaM }
VaX
{ A, B , C }

44
 3.3 Formal Definition

X
{ X 1, X 2, X 3, X 4, X 5}
action( X 2)
A action( X 3)
B
action( X 4)
C action( X 5)
A

T
{T 1, T 2, T 3, T 4, T 5}
X P R ( T 1)
X 1 X F O ( T 1)
X 2
X P R ( T 2)
X 2 X F O ( T 2)
{ X 3, X 4}
X P R ( T 3)
X 4 X F O ( T 3)
M1
X P R ( T 4)
{ X 3, M1} X F O ( T 4)
X 5
X P R ( T 5)
X 5 X F O ( T 5)
X 1
( T 1)
a ( T 2)
b
( T 3)
c ( T 4)
1
( T 5)
e

M
{ M1}
VrM
Vr1
{b, d}
VaM
Va1
{ C }
X 1
{ X 6, X 7, X 8}
action( X 7)
C
T 1
{ T 6, T 7}
X P R ( T 6)
X 6 X F O ( T 6)
X 7
X P R ( T 7)
X 7 X F O ( T 7)
X 8
( T 6)
b ( T 7)
d
M1

In1
X 6
Out1
X 8

I
{ X 1}

45
Chapter 3. Grafcet

3.4 Grafcet vs Petri Nets

Grafcet has many similarities to Petri nets. The Petri net model that is
closest in nature to Grafcet is Interpreted Petri nets, see Chapter 2.6.

1. Both models have two types of nodes: steps and transitions for
Grafcet, places and transitions for Petri nets.
2. In both models, the net execution is synchronized by external events.

However, there are also differences:

1. The marking of a Grafcet is boolean whereas the marking of a Petri

net is given by a nonnegative integer.
2. All simultaneously fireable transitions will be simultaneously fired
in a Grafcet whereas in an Interpreted Petri nets the transitions
will be fired in a sequence, called the complete firing sequence. If
the sequence is not maximal all the fireable transitions will not be
fired. This difference means that, for a Grafcet, in an or-divergence
situation, with all receptivities being true, the transitions in both
branches will be fired and both the "alternative" branches will be
executed. This is often not the designers intention and it is rec-
ommended that these transitions are made mutually exclusive. An
Interpreted Petri net treats the situation by nondeterministically
choosing one of the branches.
3. The conditions used in Grafcet can depend on the state of the mark-
ing, this is not the case in an Interpreted Petri net.

Despite the differences that exist, an Interpreted Petri net can be made
equivalent to a Grafcet and a Grafcet can be made equivalent to an In-
terpreted Petri net, see Figure 3.7.

Interpreted PN Grafcet If the PN is safe, see Chapter 2.3, the first

difference does not exists. If the Interpreted PN is such that no transitions
contained in a conflict situation can be fired at the same time the behavior
of the Petri net is deterministic and the second difference is removed. The
third difference can be avoided by rewriting the Interpreted Petri net.

46
 3.5 Grafcet vs Finite State Machines

Interpreted Petri net Grafcet

Grafcet not sound

Petri net either not safe
or not deterministic
Sound Grafcet
AND
Safe and deterministic Petri net

Figure 3.7 Comparison between Grafcet and Interpreted Petri nets.

Grafcet Interpreted PN If the Grafcet is sound, see below, the

Grafcet is equivalent to an Interpreted Petri net.
A sound Grafcet has the following properties, [David, 1995]

An active step cannot have a fireable input transition without having

an output transition that is simultaneously fireable.

For any pair of simultaneously fireable transitions, they have no

input step in common.

No step can have more than one simultaneously fireable input tran-
sition.

3.5 Grafcet vs Finite State Machines

The classical models for describing sequential systems are state machines.
Two different types exist; Mealy machines and Moore machines, [Mealy,
1955], [Moore, 1956]. The output from a Mealy-machine depends on the
internal state and the input whereas the output from a Moore machine
depends only on the internal state.
In Figure 3.8 a Mealy-machine (left) and the corresponding Moore-machine
(right) are shown. The two state machines have two inputs, a and b, and
two outputs, z0 and z1.
A Mealy or a Moore machine can directly be transformed into a Grafcet.
Moreover, it can be shown that the number of steps (and transitions)

47
Chapter 3. Grafcet

Mealy: Moore:
ab
ab/z0 S1/z0

a/z1 a
S0 S1 S0/z1
a

ab/z1 S2/z1
ab

Figure 3.8 A Mealy-machine (left) and a Moore-machine (right).

required in a Grafcet is at most equal to the number of states (and tran-

sitions) required for the description by the corresponding machine. For a
Moore machine the Grafcet actions become unconditional and for a Mealy
machine the Grafcet actions become conditional. The Grafcets correspond-
ing to the Mealy machine and the Moore machine in Figure 3.8 are shown
in Figure 3.9.

A Grafcet may be transformed into a state machine but the number of

states required in the corresponding state machine might be greater than
the number of steps in the Grafcet.

Mealy -> Grafcet Moore -> Grafcet

Z1 Z1

a ab ab

Z0 if b
Z0 Z1
Z1 if b

a a a

Figure 3.9 The Grafcet corresponding to the Mealy machine (left) and to the
Moore machine (right) in Figure 3.8.

A state machine can be either synchronous or asynchronous. Both can be

modeled by a Grafcet. However, Grafcets exist that cannot be transformed
into an asynchronous nor a synchronous state machine, [David, 1995].

48
 3.6 Summary

3.6 Summary
Grafcet was developed in France in the mid seventies. It was proposed
as a formal specification and realization method for logical controllers.
Grafcet has since become well known through the two international stan-
dards, IEC 848 from 1988 and IEC 1131-3 from 1993. In these standards
Grafcet is refered to as Sequential Function Charts (SFC). The aim of
Grafcet, or SFC, in the standards has gradually shifted from being a rep-
resentation format for logical controllers towards being a graphical pro-
gramming language for sequential control problems at the local level. One
main advantage of Grafcet, or SFC, is its simple and intuitive graphical
syntax. Today Grafcet is widely used and well accepted in industry.

49
4
High-Level Nets

If a system has several parts that are identical these parts should, using
ordinary Petri nets or Grafcet, be modeled by as many identical nets as
there are parts. This kind of problem is of no importance for small systems
but it might be catastrophic for the description of a large system. Real-
world systems are often large and contain many parts which are similar
but not identical [Jensen, 1992]. Using ordinary nets, these parts must
be represented by disjoint subnets with a nearly identical structure. This
means that the total net becomes very large and it becomes difficult to see
the similarities between the individual subnets representing the similar
parts. To make the representation more compact, efficient, and manage-
able the different identical parts could be modeled by one net where each
part is represented by an individual token. In order to distinguish the
different tokens, i.e., the different parts, an identifier is associated with
each token. This is the main idea behind all high-level nets, [Jensen and
Rozenberg, 1991].
In this chapter some different high-level nets are described. The different
models presented are not supposed to give a complete overview of the field
but a rough idea of what has been done in the area.

4.1 Coloured Petri Nets

Coloured Petri nets exist in two main different versions. The first version
was developed in 1981, [Jensen, 1981], and the second version, which is
richer and more advanced, was developed in 1986, [Jensen, 1992]. In both
versions, the identifier, associated with each token is called the token
colour. Petri net models where the tokens can be identified, like coloured
Petri nets, are also called high-level Petri nets.
Jensen compares the step from ordinary low-level Petri nets to high-level
nets with the step from assembly languages to modern programming lan-

50
 4.1 Coloured Petri Nets

guages. In low level nets there is only one type of token which means
that the state of the place is described by an integer (or by a boolean).
In high-level nets, each token can carry complex information or data. The
state of the system can therefore be more precise [Jensen, 1992].

EXAMPLE 4.1.1
An example taken from [David and Alla, 1992] illustrates the idea of
coloured Petri nets. Figure 4.1 represents two identical systems. In each
system, the truck can move either to the left or to the right. As soon as
the truck reaches one end, it changes direction and sets of again towards
the other end.

Movement to Movement to
the right the right

Right end reached Right end reached

Movement to Movement to
the left the left

Left end reached Left end reached

Upper truck Lower truck

Figure 4.1 Two identical systems and their associated Petri nets.

The two systems can be modeled by two separate nets, as indicated in

Figure 4.1. Each net contains one token. The two systems can also be
modeled in one single net as shown in Figure 4.2. In order to distinguish
the two trucks from each other, the tokens are given individual names or
colours. The token corresponding to the upper truck is labeled < U > and
the truck corresponding to the lower truck is labeled < L >.

#
The operation performed when transforming an ordinary Petri net to a
Coloured Petri net is called folding. The reverse operation is called un-
folding.

51
Chapter 4. High-Level Nets

<U> Movement to
the right

Right end reached

Movement to
<L>
the left

Left end reached

Figure 4.2 One coloured Petri net representing two identical systems.

The properties of a coloured Petri net are the same as those for an ordinary
Petri net, i.e., firing sequences, bounded, live, deadlock-free, etc.

Coloured Petri Nets Version 1981

To each transition a set of firing colours is associated. These represent
the different firing possibilities. A transformation of colours may occur
during the firing of a transition. To be able to represent colour transfor-
mations the concept of arc inscriptions is introduced. The arc inscriptions
are functions associated with the input and the output arc of a transition.
The functions on the input arcs determine the numbers and the colours of
the tokens that will be removed from the input places when the transition
fires with respect to a certain firing colour. Similarly, the functions on the
output arcs determine the colours and the number of the tokens that will
be added in the output places of the transition. The identity function is
associated to arcs without colour transformation. The identity function is
however, very often not explicitly written out.

EXAMPLE 4.1.2
An example of a small coloured PN is given in Figure 4.3. In the figure it
is shown how the colour functions, associated with the arcs, can be used.
Transition T 1 is enabled with respect to the firing colour m since the
input places contains at least f ( m) and g ( m) tokens, respectively. The
transition is not enabled with respect to the firing colour b. This is due
to the left input place that does not fulfill the condition of containing
f ( b) tokens. When the transition fires with respect to the firing colour m,
f ( m) and g ( m) tokens will be removed from the respective input place
and f ( m) and Id( m)
1 m tokens will be added to the respective output
place.
#

52
 4.1 Coloured Petri Nets

m bb Firing of T1 m b
m m b
bb m b
m m
f g f g
Colour functions:
T1 (m,b) T1 (m,b)
f (m) = 1 m + 2 b
f (b) = 3 m
f Id f Id
g (m) = 1 b m
g (b) = 1 m + 2 b b b m

Figure 4.3 A simple coloured PN.

Complex colours consisting of two or more subcolours can be defined. This

can further reduce the size of the model of a system. However, if the
system is too much compactified, it becomes hard to read and understand.

EXAMPLE 4.1.3
In Figure 4.2 a single colour is used to identify each truck. The system
can however be even more compactly described using complex colours.
The upper and the lower truck can both move either to the left or to the
right. In Figure 4.2 the two directions are represented by two separate
places. If each truck instead is represented by a complex colour where the
first subcolour indicates if it is the upper, U, or the lower, L, truck and
the second subcolour indicates if the truck moves to the right, r, or to the
left, l, the system can be described by only one place and one transition,
see Figure 4.4.

< U, r >
P1
< L, l >
f(<L,l>) = <L,r>
f(<L,r>) = <L,l> f Id
f(<R,l>) = <R,r>
f(<R,r>) = <R,l>
T1 { <L,l>,<L,r>,<U,l>,<U,r>}

Figure 4.4 A coloured Petri net with complex colours.

53
Chapter 4. High-Level Nets

Formal Definition

A coloured PN is a 6-tuple

R
< P , T, Pre, Post, M0 , C >

where:
P is the set of places.
T is the set of transitions.
Pre and Post are functions relating the firing colours to
colours of the tokens.
M0 is the initial marking.
C
{ C1 , C2 , . . . } is the set of colours.

EXAMPLE 4.1.4
The coloured Petri net shown in Figure 4.4 can be described by the 6-tuple
R.

R
{ P , T, Pre, Post, M0, C }

where

P
{ P1 }
T
{T1}
Pre
[ Id ]
Post
[f]
M0
[ < U , r > < L, l > ]T
C
{< U , r >, < U , l >, < L, r >, < L, l >}

Coloured Petri Nets Version 1986

The difference between the second version of Coloured Petri nets and the
first one is the representation of the arc inscriptions. Coloured Petri nets
version 1981, relies on a function representation. The arc inscriptions
are functions that are associated with the input and output arcs of a
transition. Associated with a transition is a set of firing colors that indicate
the firing possibilities of a transition. Coloured Petri nets version 1986
relies on an expression representation where arc expressions are used in

54
 4.1 Coloured Petri Nets

combination with guards. It has been shown that the two representations
can be transformed into each other.
The token colour is a data value, that might be of arbitrarily complex type,
e.g., a record where the first place is an integer and the second place a
boolean variable. Each place in the net have a colour set that specifies
the possible colours of tokens that might reside in this place.
The concept of guards is introduced. A guard is a boolean expression
restricting the conditions under which a transition can fire. The guard
must be fulfilled before the transition can fire. Each arc has an associated
arc expression that determines which and how many tokens that will be
affected by a transition firing. A declaration is associated with each net
specifying the different colour sets and variables.
Presentations of practical applications with Coloured Petri nets can be
found in [Jensen, 1997]. A formal definition of Coloured Petri nets version
1986 can be found in [Jensen, 1995].

EXAMPLE 4.1.5
A example, inspired by [Jensen, 1995], illustrates how this type of net
works. In Figure 4.5 there are two types of processes, called p and q. Three
q-processes start in place p1 and cycle through the places ( p1, p2, p3). Two
p-processes start in place p2 and cycle through the places ( p2, p3). Each
of the five processes is represented by a token, where the token colour is
a pair such that the first element tells whether the token represents a
p-process or a q-process and the second element is an integer telling how
many full cycles that process has completed. In the initial marking there
are three ( q, 0)-tokens at place p1 and two ( p, 0)-tokens at place p2. There
are two different types of resources, one r-resource and three s-resources.
In the arc expressions and in the guards different variables are used. The
variables are specified in the declaration that is associated with the net.
The variable i is allowed to be of type I where I is a colour declared
as an integer. The variable x is allowed to be of type U where U is a
colour either equal to p or q. A guard might restrict the possible types of
variables that can enable a transition. This is, e.g., the case for transition
T 1 where the variable x is only allowed to be of type q. The colour set, P,
associated with the places, indicates the possible token colours allowed in
a place. The colour P is composed of one part of type U and one part of
type I. The resources are of token type E.
Transition T 1 is enabled if there is a token of type ( q, i) in place P1, a
token of type e in place R and a token of type e in place S. When the
transition fires the tokens that enabled the transition are removed and a
token of type ( q, i) is added in place P2. Transition T 3 does not have a

55
Chapter 4. High-Level Nets

declaration
colour U: with p|q;
colour I = int;
initial expression
colour P = product U*I;
colour E: with e;
var x: U; 3(q,0)
var i : I; colour set P P1
if x = q
(x,i) then 1(q,i+1)
e [x = q] else empty
T1
(x,i) guard
2(p,0)
e
P P2
if x = p
1e (x,i) then 1(p,i+1)
R case x of else empty
T2
p => 2e
E | q => 1e (x,i)
arc expression
P P3
if x=p then
1e else (x,i)
3e
empty
S T3
case x of
E p => 3e
| q => 2e

Figure 4.5 A coloured Petri net describing a resource allocation system.

guard, this means that the transition can be enabled by a token of type
( p, i) or a token of type ( q, i) in place P3. If the transition is enabled with
respect to a token of type ( p, i), the firing of the transition will remove a
token of type ( p, i) from place P3 and add one token of type e in place R,
three tokens of type e in place S and one token of type ( p, i + 1) in place
P2. If the transition instead is enabled with respect to a token of type
( q, i), the firing of the transition will remove a token of type ( q, i) from
place P3 and add two tokens of type e in place S and one token of type
( q, i + 1) in place P1.

A toolbox, called Design/CPN, has been developed for Coloured Petri nets,
[Met, 1993]. The user graphically draws the net and textually specifies the
colour sets, arc expressions and guards. The inscription language of the
toolbox is Standard ML, [Harper, 1986].

56
 4.2 Coloured Grafcet

4.2 Coloured Grafcet

Coloured Grafcet is a graphical model similar to Grafcet. Coloured Grafcet
was introduced by Agaoua in a PhD-thesis in 1987 [Agaoua, 1987]. It has
also been used to realize a model for simulation and real-time control,
[Suau, 1989].

Grafcet is used to control a system. In order to be able to control large

systems composed of several identical, or similar, subsystems, the concept
of Coloured Grafcet is introduced, i.e., the main reason for introducing
Coloured Grafcet is the same as that for the introduction of Coloured
Petri nets.

A Coloured Grafcet is built up by steps and transitions in the same way as

Grafcet. Associated with the arcs are functions that specify the numbers
and the colours of the tokens that should be removed or added to a step,
the functions are called Pre and Post, respectively. A step may contain at
most one token of each colour. The set of different token types is denoted
C . All possible combinations of token types that may reside in a step
is called CS . Each action associated with a step is bound to a colour.
When a token enters the step, the action, if any, associated with the step
and with the colour of the token is effectuated. The action types are the
same as those for Grafcet, see Chapter 3.1 (Actions). A transition can be
enabled with respect to different colours. A transition can have several
receptivities. Each receptivity is bound to a colour. The set of different
receptivity types is called CT and is a product of C and R where R is
the set of conditions and events that enable a change of state. The colour-
function is denoted C and is defined as C
{ CS CT }.

The new concepts in Coloured Grafcet, compared to Grafcet, are the in-
troduction of colours and the colour-functions.

EXAMPLE 4.2.1
Consider the case were there are two machines, M1 and M2. Each machine
can be in either of two states: idle or busy. If the machine is in the state
idle and the button start is pushed the machine switches state and starts
to work. If the machine is in state busy and the button stop is pushed
the machine stops working and becomes idle. The two machines can be
modeled by two separate Grafcets, see Figure 4.6 (left), or by one Coloured
Grafcet, see Figure 4.6 (right).

57
Chapter 4. High-Level Nets

S1 S1 S1
Idle S1 Idle
<m1>
<m2>
pre 11
T1 T1 T1
{<m1;start1>, <m2;start2>}
S2 S2 post21
Busy Busy S2
M1 Work
Work Work
M2 Work
pre 22
T2 T2 T2
{<m1;stop1>, <m2;stop2>}
post 12

Machine 1 Machine 2
pre 11<m1;start1> = <m1>
pre <m2;start2> = <m2>
11
pre 22<m1,stop1> = <m1>
pre 22<m2;stop2> = <m2>

post 12<m1;stop1> = <m1>

post 12<m2;stop2> = <m2>
post 21<m1;start1> = <m1>
post 21<m2,start2> = <m2>

Figure 4.6 Two Grafcets transformed into a Coloured Grafcet.

Formal Definition

A Coloured Grafcet, [Agaoua, 1987], is a 6-tuple

C G
< S , T, C , Pre, Post, M0 >

where:

S
{ S1 , S2 , ... Sn } is a finite, nonempty, set of steps.

T
{T1 , T2, ..., Tm } is a finite, nonempty, set of transitions.
S T
, i.e., the sets S and T are disjoint.

58
 4.2 Coloured Grafcet

C is the colour-function defined for S T in the non-empty

set { C Si C Ti } such that C Si CS and C Tj CT . The
elements of { C Si C Tj } are called colours.
Pre is the input incidence function defined for S  T such
that preij is a function C Si C Tj .
Post is the output incidence function defined for S  T
such that postij is a function C Tj C Si .
M0 is the initial marking defined for S such that Si S ,
M0( Si ) CS .

EXAMPLE 4.2.2
The Coloured Grafcet in Figure 4.6 (right) is described by the sextuple:

C G
< S , T, C , Pre, Post, M0 >

where

S
{ S1 , S2 }
T
{T1, T2 }
C
{ CS CT }
C
{< m1 >, < m2 >}
CS

{< m1 >, < m2 >, < m1 > + < m2 >}
R {start1, start2, stop1, stop2}


CT

{< m1; start1 >, < m1; start2 >, < m1; stop1 >, < m1; stop2 >,
< m2; start1 >, < m2; start2 >, < m2; stop1 >, < m2; stop2 >}
 
pre11 0
Pre

0 pre22
 
0 post12
Post

post21 0
M0
[ < m1 > + < m2 > 0 ]T

59
Chapter 4. High-Level Nets

4.3 Object Petri Nets and LOOPN

The difference between ordinary Petri nets (PN) and Coloured Petri nets
(CPN) is the expressive comfort. A Coloured Petri net can be transformed
into an ordinary PN, but the structure of the CPN is more compact and
most often easier to read and understand. CPN therefore constitute a sig-
nificant advance over PN, but the absence of powerful structuring primi-
tives is still a weakness, [Jensen, 1990].
Object Petri nets are a class of Petri nets where object-oriented ideas are
applied to Coloured Petri nets, [Lakos, 1994]. Two class hierarchies exists:
one for tokens and one for subnets or modules. So far, the object Petri nets
have only focused on object-oriented structuring of the token types. The
components of a class are drawn within a frame marked with the class
name. A place is a data field which can supply values. All data fields are
drawn as circles. Transitions and functions are drawn as rectangles. The
export of fields and functions from a class is indicated by an undirected
arc from the object to the class boundary. A class can be made a subclass
of another class and thereby inheriting from it. The Object Petri nets
have retained the traditional Petri net style with tokens as passive data
items and their life cycles specified by the global control structure of the
net. This means that, unlike ordinary object-oriented programming, it is
not possible to let the call to a function, or method, depend on the type
of data within the token and it is neither possible to affect the response
of an operation. The Object Petri nets can be proven to be behaviorally
equivalent to Coloured Petri nets and thus also to ordinary Petri nets. This
means that the analysis techniques developed for PN can be applied.
Object Petri nets provides a simple way to model multi-level systems,
i.e., systems where the components that move through the system have
their own internal life cycles. Real-life situations generally have a num-
ber of layers of data activity, [Lakos, 1994]. For example, in modeling a
traffic intersection, the cars which move through the intersection can be
considered as data objects. The cars also have internal activities such as
consumption of petrol, mechanical failure, etc, which may be of interest
in the simulation.

EXAMPLE 4.3.1
A small example will illustrate how the OBJSA nets work. Figure 4.7
illustrates a truck that can move either to the left or to the right. The
truck is driven by driver. Inside the truck there is food. As soon as the
driver becomes hungry, he stops the truck and starts to eat, when he is
no longer hungry he continues to drive.
The token type for a driver is called Driver and is shown in Figure 4.8

60
 4.3 Object Petri Nets and LOOPN

Figure 4.7 A truck and a driver.

(left). The driver contains data, e.g., an identity number given by an

integer. The state of the driver is described by the net named DriverAction
shown in Figure 4.8 (middle). The net has two functions, Drive and Eat,
that are exported. The two functions depend on the marking of place P1
and P2 respectively, as shown by a special arc, known as the compound
arc. This arc has the effect of binding the variable y to the marking of P1
or P2 and then the function returns the boolean value y
1. The token
moving around in this net is of the type Driver.

Driver DriverAction Truck

y: Driver y: Driver
id: integer = 7564 [y.driving]
P1 y Driving
driving() = boolean : Driving Right
drive()=
Action.drive() bool: |y|=1
Eating
eating() = boolean : T1 T2 [y.eating]
Action.eat() eat()= [y.driving]
bool: |y|=1 Driving
P2 y Left
Action : DriverAction
Eating
Eating
[y.eating]

Figure 4.8 Class definitions for Driver, DriverAction and Truck.

The net describing the truck is shown in Figure 4.8 (right). The token
moving around in this net is of type Driver. Associated with the transitions
are receptivities from which it is possible to check the data of the token.

Modeling a multi-level system with CPN will often result in a large and
complicated net whereas the modeling with OPN will be easier and the
resulting structure of the net becomes easy to read and understand.

The formal definition of OPN as well as the relation to CPN are given
in [Lakos, 1994]. LOOPN++, a textual language for Object Petri nets is
defined in [Lakos and Keen, 1994].

61
Chapter 4. High-Level Nets

4.4 OBJSA Nets

High-level nets all have individual tokens. In the OBJSA nets this is
combined with algebraic specification techniques, [Battiston et al., 1988].
OBJSA net systems is a class of high level Petri nets. The OBJSA nets
can be decomposed into state-machine components. The individual tokens
are defined as abstract data types. To modify the data a language called
OBJ2 or OBJ3 is used.

EXAMPLE 4.4.1
A small example will demonstrate the idea behind the OBJSA nets. The
example is a modified version of an example first published in [Battiston
et al., 1988].

Consider a system that consists of one sender (S) and one receiver (R).
The receiver has a mailbox (M) consisting of a one-cell buffer where the
sender asynchronously put messages. The receiver asynchronously reads
the messages and removes them from the mailbox. The system can be
modeled by an ordinary PN or by a coloured PN (CPN). In the CPN the
tokens carry an identifier permitting the tokens to be distinguished from
each other. The messages from a sender can be represented by the token
< msg > where msg is the message to be sent. The tokens representing
the messages in the mailbox is either of the type empty < > or of the
type message < msg >.

However, usually mailboxes are not one-cell buffers but list of messages.
This can conveniently be modeled using algebraic nets, i.e., nets where
the information associated with the token is algebraically specified and
algebraically modified. Figure 4.9 shows the sender and the mailbox rep-
resented by an algebraic net. The token representing the mailbox is now a
list, either empty < eL > or nonempty < L >. When a new message comes
the mailbox modifies its list of messages by placing the new message in
the end of the old list. This operation is performed by the @-operator in
the OBJ3 language. There exists a large number of operators defined in
the OBJ3 language, e.g., tail ( L), an operator that returns all elements in
the list L but the first.

A formal definition a more thoroughly presentation of the OBJSA nets and

the OBJ2 and OBJ3 languages can be found in [Battiston et al., 1988].

62
 4.5 Other High-Level Languages Influenced by Petri Nets

Sender Mailbox

<> Empty
<> Mailbox
<eL>
Produce a
Message <eL>

Receiver
<msg>
<eL@msg>
<msg> Send <tail(L)>

<L> <L>
<msg> Mailbox with
Send Messages

<> <L@msg>

Figure 4.9 A sender and a receiver represented by an algebraic net.

4.5 Other High-Level Languages Influenced by Petri Nets

Petri nets have also influenced some other high-level programming lan-
guages.

Cooperative Objects
Cooperative Objects is an object-oriented language influenced by the lan-
guage Eiffel and by high-level Petri nets, [Bastide et al., 1993]. Cooper-
ative Objects aims at modeling a system at various abstraction levels as
a collection of concurrent objects. The objects cooperate in a well defined
way to provide the services expected from the system.
In this language concurrency, object behavior and inter-object communi-
cation are described in terms of high-level Petri nets. The language relies
on a client-server organization of objects and it retains the most impor-
tant features in object-oriented languages: classification, encapsulation,
inheritance, instantiation and dynamic use relationship.
In Eiffel, the contract that the server object should fulfill for its client
is expressed by a set of preconditions, postconditions and invariants. In
Cooperative Objects, the contract is expressed by a high-level Petri net.

63
Chapter 4. High-Level Nets

Also the implementation of a class is given by a high-level Petri net as

well as the semantics of a service invocation.

The language can be used both for specification of a concurrent class and
for implementation. Results from the PN theory can be used to ensure
the compatibility between a specification and its implementation.

Moby
MOBY (MOdellierung von BrosYstemen) is a tool which supports mod-
eling and analysis of systems by hierarchical timed high level Petri nets
with objects, [Fleischhack and Lichtblau, 1993]. The tool should assist
in the modeling, analysis and simulation of processes in various applica-
tion areas. The tool consists of editors for the specification of the net part,
and of a simulator for the validation of constructed models. The simulator
contains a conflict resolution component, which reduces the combinatorial
complexity of possible behaviors of a model by using specific knowledge
about the system, [Fleischhack and Lichtblau, 1993].

The nets considered in MOBY combines features from algebraic high level
nets and coloured Petri nets with concepts of time and hierarchy. The
tokens are structured in an object oriented manner. A transition may
be refined and the can be seen as a kind of macro expansion. From a
transitions subnets can be called.

To each place in an object net one of the four types: multiset, stack, queue
or priority queue, is assigned. This means that the objects in a place
are handled according to the rules of the corresponding data type. Multi-
set places may contain tokens belonging to different types whereas other
places are bound to one token type.

Arcs are either of standard type or of inhibitor type. In order to activate

a transition, inhibitor arcs require that its input place does not contain
certain objects. The arcs can be either activating or consuming. Activating
arc behave like standard ones as far as the activation is concerned, how-
ever, the firing of the transition does not remove objects from the place.
Consuming arcs enable a transition to empty a place.

GINA
Gina is an object-oriented language concept for parallel, hierarchically
structured, data driven programs. It is also a Petri net language based on
dynamically modified, interpreted nets, [Sonnenschein, 1993].

64
 4.6 Summary

4.6 Summary
Real-world systems are often very large and do often contain many parts
which are similar but not identical. Using ordinary low level nets, these
parts must be represented by disjoint subnets with nearly identical struc-
tures. This means that the total net becomes very large and it becomes
difficult to see the similarities between the individual subnets represent-
ing similar parts. To make the representation more compact, efficient and
manageable the different identical parts could be modeled by one net
where each part is represented by an individual token. To be able to
distinguish the different tokens, i.e., the different parts, an identifier is
associated with each token.

65
5
Grafchart

Grafcet, or Sequential Function Charts (SFC), has been widely accepted

in industry as a representation format for sequential control logic at the
local level through the standards IEC 848 and IEC 1131-3, as described
in Chapter 3. There is, however, also a need for a common representa-
tion format for the sequential elements at the supervisory control level.
Supervisory control applications receive increasing attention both from
the academic control community and the industry. The reasons for this
are the increasing demands on performance, flexibility, and safety caused
by increased quality awareness, environmental regulations and customer-
driven production.
Sequential elements show up in two different situations in supervisory
control. The first situation arises due to the fact that the processes in the
process industry are typically of a combined continuous and sequential
nature. All processes have different operation modes. In the simplest case
these can consist of start-up, production and shut-down. The second sit-
uation concerns the case when the problem that the supervisory system
should solve itself can be decomposed into sequential steps.
Grafcet was developed for logic controllers. It is a mathematical model
whose semantics is defined by an interpretation algorithm. Since Grafcet
was developed for sequential control logic at the local level it lacks many
features needed to structure and implement the complex applications that
are found on the supervisory control level.
Grafchart is the name of a mathematical sequential control model. It is
based on Grafcet, Petri nets and concepts from object-oriented program-
ming. Grafchart is aimed, not only at local level applications, but also at
supervisory level applications. It has been developed at Lund Institute
of Technology, Sweden, since 1991, [rzn, 1991], [rzn, 1994b], [rzn,
1993]. Grafchart exists in two different versions. The first and basic ver-
sion of Grafchart is mainly based on Grafcet whereas the second and

66
high-level version also incorporates ideas from high-level Petri nets.
Grafchart is also the name of an implementation of the Grafchart model in
G2, an object-oriented graphical programming environment. G2 is briefly
described in [Gensym Coorporation, 1995], see Appendix E. With Graf-
chart the same language can be used both on the local control level and
on the supervisory control level, see Figure 5.1.

Supervisory Control Level:

Grafchart for e.g.

monitoring,
diagnosis and
recipe structuring

Local Control Level:

Grafchart for
sequential control

SEQUENTIAL
PROCESS

Figure 5.1 Supervision of sequential processes.

The language of Grafchart is, like any other programming language, fully
defined by its syntax, semantics and pragmatics, [Turbak et al., 1995].
The syntax defines the notations used, the semantics defines the meaning
of the syntax, and the pragmatics focuses upon how the semantics is
implemented. If the pragmatics is omitted the language is reduced to a
model.
This chapter starts with a presentation of the syntax of Grafchart, i.e.,
its graphical elements and its step actions and transition receptivities.
Then follows a presentation of the basic version (Grafchart-BV) and the
high-level version (Grafchart-HLV) of the language. The presentation cov-
ers, among other things, the dynamic behavior, i.e., the semantics, of
Grafchart-BV and Grafchart-HLV. A section in the chapter covers the
error handling aspect and another section describes the G2 implemen-
tation, i.e, the pragmatics of Grafchart. The chapter ends with a short
presentation of some applications of Grafchart.

67
Chapter 5. Grafchart

5.1 Graphical Language Elements

The graphical syntax of Grafchart is similar to that of Grafcet. It supports
alternative branches and parallel branches. The graphical language ele-
ments of Grafchart are steps, transitions, macro steps, procedure steps,
process steps, Grafchart procedures and Grafchart processes. Each el-
ement is represented by an object. The icon of this object defines the
graphical presentation of the element. The elements are interconnected
using graphical connections.

Grafchart processes
An entire function chart can be represented as a Grafchart process object,
see Figure 5.2. The function chart is encapsulated by the Grafchart pro-
cess object. In the G2 implementation the function chart is placed on the
subworkspace, see Chapter 5.9, of the Grafchart process.

Figure 5.2 A Grafchart process.

A Grafchart can be closed or open, as shown in Figure 5.3. However, the

function chart always starts with one or several initial steps.

Closed chart Open chart

Figure 5.3 One closed and one open function chart.

68
 5.1 Graphical Language Elements

Steps
A step is an object that is represented as a square, see Figure 5.4. Actions,
i.e., can be associated with a step. A step can be active or inactive.

Figure 5.4 A step.

Initial steps
The graphical representation of an initial step, i.e. a step that should be
active when the function chart is started, is a double square, see Fig-
ure 5.5.

Figure 5.5 An initial step.

Transitions
A transition is represented by an object. The graphical representation
of a transition is shown in Figure 5.6. A transition can be enabled or
disenabled.

Figure 5.6 A transition.

Parallel bars
A parallel bar is used to indicate the beginning and the end of a parallel
branch. To indicate the beginning of such a branch a parallel bar of type

69
Chapter 5. Grafchart

and-divergence (parallel split) is used and to indicate the end a parallel

bar of type and-convergence (parallel join) is used, see Figure 5.7.

anddivergence

andconvergence

Figure 5.7 A parallel branch.

Macro steps
Macro steps are used to represent steps that have an internal structure
of (sub)steps, transitions and macro steps. In the G2 implementation a
macro step is represented by an object that has a subworkspace. The
internal structure is placed on the subworkspace. In Figure 5.8, a macro
step and its internal structure are shown.

Figure 5.8 A macro step.

Enter steps and Exit steps

Special step objects, called enter-steps and exit-steps, are used to indicate
the first and the last sub-step of a macro step. When the transition pre-
ceding a macro step becomes true, the enter-step upon the subworkspace
of the macro step and all the transitions following that enter-step are

70
 5.1 Graphical Language Elements

enabled. The transitions following a macro step will not become enabled
until the execution of the macro step has reached its exit-step. An enter
step and an exit step are shown in Figure 5.9.

Figure 5.9 An enter step (left) and an exit step (right).

Grafchart procedures
Sequences that are executed in more than one place in a function chart
can be represented as Grafchart procedures, see Figure 5.10. The Graf-
chart procedure object has a subworkspace on which the procedure body
is placed. The enter-step and exit-step objects are used to indicate the
first and the last sub-step of a procedure. Only one enter step is allowed
in each Grafchart procedure.

Figure 5.10 A Grafchart procedure and its subworkspace.

The Grafchart procedures are reentrant. Each procedure invocation exe-

cutes in its own local copy of the procedure body. This makes recursive
procedure calls possible.

Procedure steps
A Grafchart procedure is called from a procedure step. The procedure step
has a procedure attribute in which the name of the Grafchart procedure
that should be called is specified. Immediately when a procedure step is
activated, the Grafchart procedure is called and a new token is placed
in the enter step of the Grafchart procedure. The transitions following a
procedure step do not become enabled until the execution of the Grafchart
procedure has reached its exit step. In Figure 5.11 a procedure step is
shown.

71
Chapter 5. Grafchart

procedure
call
Grafchart
procedure

Figure 5.11 A Procedure step.

Process steps
A procedure step is the equivalent of a procedure call in an ordinary pro-
gramming language. Sometimes it is useful to start a procedure as a sep-
arate execution thread, i.e., to start the procedure as a separate process.
This is possible with the process step, see Figure 5.12. The transitions af-
ter a process step become enabled as soon as the execution has started in
the Grafchart procedure. An outlined circle token is shown in the process
step as long as the process is executing. It is possible to have more than
one process executing at the same time from the same process step.

process
creation
Grafchart
procedure

Figure 5.12 A Process step.

Tokens
Tokens are represented as filled circles. In the basic version of Grafchart,
the tokens are boolean indicators indicating if a step is active or not,
whereas the tokens in the high-level version of Grafchart are objects that
have an identity and may contain information.

72
 5.2 Actions and Receptivities

5.2 Actions and Receptivities

Actions are associated with steps and receptivities are associated with
transitions. The two versions of Grafchart differs with respect to when a
step is considered active and when a transition is considered enabled, see
Chapter 5.4 and Chapter 5.5 respectively.

Actions
Four different types of actions exist: always, initially, finally and abortive.
An initially action is executed once immediately when the step becomes
active. A finally action is executed once immediately before the step is
deactivated. An always action is executed periodically while the step is
active. An abortive action is executed once immediately before the step is
aborted. All actions can be conditional or unconditional. The actions that
may be performed in a step action depends on the underlying implemen-
tation language. The minimum requirement is that it should be possible
to assign values to variables and that it should be possible to execute
macro actions, see Chapter 5.9.
In Figure 5.13 a step, x1, is shown. Three actions are associated with the
step. The figure (right) shows the execution of the actions.

x1

Initially
x1

Always

Finally

Figure 5.13 A step with three actions.

Actions can also be associated to macro steps and Grafchart procedures.

In this case, the initially actions are executed before the actions of the
enter step of the macro step or the Grafchart procedure and the finally
actions are executed after the actions of the exit step of the macro step
or the Grafchart procedure. Always actions are executed periodically all
the time while the macro step or Grafchart procedure is active. Abortive
actions that are associated with a macro step, are executed if the execution
of the macro step is aborted. Abortive actions can also be associated with

73
Chapter 5. Grafchart

a Grafchart procedure and they are executed if the Grafchart procedure

is aborted.

Receptivities
A receptivity is used for specifying when an active step should fire. Each
receptivity contains two attributes, condition and event. These are used
to enter the event expression and/or the logical condition telling when
the transition should fire. The event expression and the logical condition
are expressed in the underlying implementation language.
In Figure 5.14 two examples are given of how the event or condition of
the transition receptivity effects the activation and deactivation of the two
steps x1 and x2.

x1 x1 x1 x1

y becomes x2 y is true x2
true

x2 x2
y y

Figure 5.14 A transition with a receptivity.

5.3 Parameterization and Methods

Grafchart includes two advanced features: parameterization and methods
and message passing.

Parameterization
Parameterization denotes the possibility for a graphical element to have
attributes acting as parameters. Grafchart processes (i.e., entire function
charts), Grafchart procedures, macro steps, and steps can be parame-
terized. The parameterization feature makes it easier to reuse function
charts from one application to another.
A step is allowed to have none, one or several attributes. These attributes
act as parameters that can be referenced and modified from within the
step actions associated to this step.
The attributes of a Grafchart process, Grafchart procedure, or a macro
step can be referenced from within all steps and all transitions placed

74
 5.3 Parameterization and Methods

on the subworkspace of the graphical element or from within a step or

transition placed deeper in the subworkspace-hierarchy.
To refer to a parameter, a Pascal-like dot notation is used.

sup.attribute1
refers to the attribute1 attribute visible in the current context.

sup.attribute1^
refers to the object named by the attribute1 attribute visible in
the current context. This notation is the G2 equivalent of a pointer
attribute in a conventional programming language.

sup.attribute1^.attribute2
refers to the attribute2 attribute of the object given by the
attribute1 attribute visible in the current context.

Lexical scoping is used when searching for the attribute of an object re-
placing the sup notation. Sup is short for superior.

Methods and Message Passing

Methods and message passing are supported by allowing Grafchart pro-
cedures to be methods of general G2 objects. For example, an object
representing a batch reactor can have Grafchart methods for charging,
discharging, agitating, heating etc. Inside the method body, it is possi-
ble to reference the object itself and the attributes of this object using a
Smalltalk influenced notation.

self
refers to the object that the method belongs to, i.e., this object.

self.attribute1
refers to the attribute1 attribute of this object.

self.attribute1^
refers to the object named by attribute1 of this object.

self.attribute1^.attribute2
refers to the attribute2 attribute of the object named by the
attribute1 attribute of this object.

References to attributes of the object that the method belongs to can be

combined with parameter references using the sup.attribute notation.

75
Chapter 5. Grafchart

5.4 Grafchart the basic version

The basic version of Grafchart (Grafchart-BV) is mainly influenced by
Grafcet, both what concerns the syntax and the semantics. In this version
of Grafchart the tokens are simple boolean indicators indicating whether
a step is active or not. An active step is indicated by the presence of a
token in the step. In Figure 5.15 an active (left) and an inactive step
(right) are shown. Each Grafchart function chart can contain at most one
token, except in an and-divergence situation where there is one token in
each branch.

Figure 5.15 An active step (left) and an inactive step (right).

Associated with a step is none, one or several actions. In Figure 5.16

an active step is shown, associated with the step are two actions, one
initially action and one always action.

Initially
conclude that x = 4

Always
conclude that y = y+1

Figure 5.16 A step with an action.

Associated with a transition is exactly one receptivity, see Figure 5.17.

a transition

event
condition

Figure 5.17 A transition with a receptivity.

Associated with the procedure steps and the process steps is a procedure
attribute that is used to specify the name of the Grafchart procedure that
should be called. When the procedure step or the process step becomes

76
 5.4 Grafchart the basic version

active the corresponding Grafchart procedure is started. In Figure 5.18

a procedure step (left) and a process step (right) with their procedure
attributes are shown.

a procedurestep a processstep

name name
parameters parameters
procedure gp1 procedure gp1

Figure 5.18 A transition with a receptivity.

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 or procedure step will not become enabled
until the execution has reached an exit step. An exception transition is
enabled all the time that the macro step or procedure step is active. If
the exception transition condition becomes true or the exception transition
event occurs, the exception transition will fire, abortive actions, if any, will
be executed, and the step following the exception transition will become
active. Exception transitions cannot be connected to a process step. The
reason for this is that a Grafchart procedure can be started more than once
from such a step and it is therefore not clear which one of the procedures
that should be aborted.
Macro steps and procedure steps remember their execution state from the
time they were aborted and it is possible to resume them in that state.
This is done using the resume macro-action, see Chapter 5.6. A macro step
with an exception transition is shown in Figure 5.19. Exception transitions
were first proposed in [rzn, 1991]. They have proved to be very useful
when implementing error handling.

Enter
step
Exception
transition

Exit
step

Figure 5.19 Macro step with exception transition.

77
Chapter 5. Grafchart

Parameterization
Consider the example shown in Figure 5.20. In the figure a macro step
with two attributes, tank and limit, is shown. The macro step is named
FT1 and it contains the logic for the control and monitoring of the filling
of a tank. The tank attribute contains the name of the tank that should be
filled, i.e., the value of this attribute acts as a pointer. The limit attribute
contains the limit up to which the tank should be filled. The macro step
has an enter-step that contains an action that initiates the filling. In this
action a reference is made to the value of the tank attribute, i.e., the tank-
12 object , using the notation sup.tank^. Similarly the transition condition
refers to the level of the tank referenced by the tank attribute and to the
value of the limit attribute. The sup.attribute notation is translated
and replaced by the corresponding G2 expression during compilation as
described in Chapter 5.9.

FT1

Initially
start filltank(sup.tank^)
FT1, a filltank

name FT1
Condition:
tank tank12 "sup.tank^.level > sup.limit"
limit 10

Figure 5.20 Parameterization of a macro step.

Lexical scoping is used when searching for the attribute of an object re-
placing the sup notation. Consider the example shown in Figure 5.21. The
macro step M1 has an attribute named x with value 156. The substructure
of the macro step contains among other a transition and another macro
step, M2. The macro step M2 has an attribute named x with value 12. The
substructure of M2 contains a transition with a reference to an x-attribute
using the sup.X notation. This reference will be to the x-attribute of the
macro step M2. The transition placed on the subworkspace of the macro
step M1 also refers to an x-attribute using the sup.X notation. In this
case the reference will be to the x-attribute of M1, see Figure 5.21. If,
however, the macro step M2 would not have had an attribute named x,
the sup.X reference of the transition in M2 would instead have refered to
the x-attribute of M1.

78
 5.4 Grafchart the basic version

sup.X >10
sup.X >10
a macro step

Name M1
a macro step
X 156
Name M2
X 12

Figure 5.21 Lexical scoping.

A Grafchart procedure is started from a process step or a procedure step.

The actual values of the parameters of a Grafchart procedure are set
in the procedure step or the process step. In addition to the procedure
attribute, the procedure steps and process steps also have an attribute
named parameters which contains a list of assignments to the formal
parameters of the Grafchart procedures being called, see Figure 5.22.

Initially
a Grafchart procedure if sup.U then
start count(sup.V,
name gp1 sup.W)
U
V
Grafchart
W procedure

a procedurestep
Procedure
name P1 call
parameters "u = true
v = 100
w = ok"
procedure "gp1"

Figure 5.22 Parameterization of a Grafchart procedure.

79
Chapter 5. Grafchart

The assigned values can either be constants (numbers, strings or sym-

bols), as in Figure 5.22 or the value of a parameter that is visible in the
process or procedure step context, as in Figure 5.23. Using the latter form,
it is also possible for a Grafchart procedure to return values to the process
or procedure step. In order to specify the direction in which the parameter
is passed, one of the keywords IN, OUT or INOUT is added after the value of
the parameter. It is also possible to determine which Grafchart procedure
that should be called from the value of a parameter. In Figure 5.23 the
parameters val, v and q are all visible in the context of the procedure
step. The parameter proc is also a parameter visible in the context of the
procedure step, this parameter determines the Grafchart procedure that
should be called. When the Grafchart procedure is called U is assigned the
value of val and W is assigned the value of q. When the execution of the
Grafchart procedure ends, v is assigned the value of V, and q, is assigned
the value of W.
Initially
a Grafchart procedure ........
.....
name .......
U
V
Grafchart
W procedure

a procedurestep Procedure
call
name P1
parameters "u sup.val IN
v sup.v OUT
w sup.q INOUT"
procedure "sup.proc"

Figure 5.23 Parameterization of a Grafchart procedure.

Methods and Message Passing

The method of an object is called through a procedure or process step
in the same way as if the procedure was stand-alone. Instead of giving
a procedure reference, the procedure that will be called is determined
by an object reference and a method reference. An example of a Graf-
chart method is shown in Figure 5.24. The reactor object R1 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. The object and method references can also be determined by
parameters.

80
 5.4 Grafchart the basic version

r1 a reactor

capacity 100

charge a grafchart
method
R1: a reactor a grafchartmethod
procedure "reactor
charge"

Grafchart
a procedure step procedure
Procedure
step Parameters " .... "
Procedure " R1 charge"

reactor
charge

Figure 5.24 Grafchart methods.

EXAMPLE 5.4.1
Consider the tank example in given in Figure 5.25. This is the same tank
as the one in Chapter 3.2 Example 3.2.1.

V1

L1 0. Start
1. Fill to L1
T
2. Heat to T. Start at L0
V2
L0
3. Empty to L0

Figure 5.25 A tank example.

The Grafchart for controlling the tank is represented by a Grafchart pro-

cess with attributes, see Figure 5.26. Each transition in the function chart
is given a name. When clicking on the transition, the corresponding re-
ceptivity shows up. In Figure 5.26 all receptivities are placed on the right
side of the chart. The structure of the function chart is similar to the
Grafcet in Example 3.2.1, the difference being the syntax of the actions
and the receptivities.
The behavior of the system controlled by the Grafchart can easily be mod-
ified. By, e.g., changing the value of the T attribute of the Grafchart pro-
cess, the temperature to which the tank should be heated is changed.

81
Chapter 5. Grafchart

a grafchart process
name gp1
V1 v11
V2 v12
Q q1
L0 false
L1 false
T 100

T1, a transition
Event Start
Condition

T2, a transition
Event
T1
Condition sup.L0
Initially
open sup.V1 T3, a transition
T2 Event
Condition tank1.temp > sup.T
Initially
start sup.Q T4, a transition

T3 T4 Event
Condition sup.L1
Initially Initially
stop sup.Q close sup.V1
T5, a transition

T5 Event
Initially Condition true
open sup.V2
Finally
close sup.V2 T6, a transition
T6 Event
Condition not(sup.L0)

Figure 5.26 A tank example.

Dynamic Behavior
The dynamic behavior of Grafchart is given by the following rules.

Enabled and fireable transitions

A transition is enabled if and only if

All the steps preceding the transition are deactiveable.
An transition is fireable if and only if
The transition is enabled.
The receptivity of the transition is true.

A step, initial step, enter step, exit step, or process step is deactiveable if
and only if it is active.

82
 5.4 Grafchart the basic version

A macro step is deactiveable if and only if the exit step upon the sub-
workspace of the macro step is active.

A procedure step is deactiveable if and only if the exit step in the Grafchart
procedure started by the procedure step is active.

An exception transition is fireable if and only if

The macro step or the procedure step preceding the ex-
ception transition is active.
The receptivity of the exception transition is true.

A macro step is active if at least one of the steps upon the subworkspace
of the macro step is active.

A procedure step is active if at least one of the step in the Grafchart

procedure started by the procedure step is active.

A process step is active if at least one of the step in the Grafchart proce-
dure started by the procedure step is active.

Firing of a transition The firing of a transition consists of deacti-

vating the steps preceding the transition, de-enabling all transitions fol-
lowing the preceding steps, activating the steps succeeding the transition
and enabling the transitions following the succeeding steps.

Firing rules

Rule 1: All fireable transitions are immediately fired.

Rule 2: Several simultaneously fireable transitions are simultane-

ously fired.
The rule applies in all situations except for the or-divergence situ-
ation where Grafchart treats the situation by nondeterministically
choosing one of the branches. In order to have an interpretation al-
gorithm without ambiguities, situations like this must be avoided.
It is therefore required, for Grafchart as in the IEC 1131-3 stan-
dard, that the user makes all branches of an or-divergence situation
mutually exclusive.

Rule 3: When a step must be simultaneously activated and deacti-

vated, it is first deactivated and then activated again.

83
Chapter 5. Grafchart

Interpretation Algorithm
The interpretation algorithm of Grafchart describes the theoretical un-
derstanding of a Grafchart and guarantees that everyone faced with the
same Grafchart understands it in the same way.
As in the case of Grafcet, multiple interpretation algorithms or semantics
are possible for Grafchart. The following algorithm corresponds to the
search for stability algorithm for Grafcet, see Chapter 3.2 (Interpretation
Algorithm). Step 4 - 18 are assumed to take zero time. In order for the
algorithm to be deterministic, all or-divergence situations must be made
mutually exclusive. The algorithm presented below is not deterministic
unless this condition is fulfilled.

Algorithm

1. Initialization. Activate the initial steps and execute the associated

initially actions. Go to Step 18.
2. Wait for a new event to occur or a condition to be true. It might
be necessary to start or stop the execution of the always actions
associated with the active steps since the conditional part of the
always action might change.
3. When a new event occurs or a condition becomes true, determine
the set of fireable transitions T. If T is empty go to Step 2.
4. Determine the set T2, which is the set of exception transitions con-
tained in the set T, T2 T. Let T1 be the set of all transitions
contained in the set T, except the exception transitions, i.e. T1
T\
T2.
5. If T1 is empty and T2 is non-empty, go to Step 6.
If T2 is empty and T1 is non-empty, go to Step 12.
If both T1 and T2 are non-empty, go to Step 6 or Step 12.
6. Make sure that T2 contains no transitions that are in conflict with
each other, i.e., transitions participating in the same or-divergence
situation. If so, the number of transitions contained in T2 must be
reduced. This is done by excluding exceptions transitions participat-
ing in the conflict until T2 no longer contains any exception transi-
tions that are in conflict with each other. The exception transitions
to exclude are chosen randomly.
7. Stop executing the always actions that are still executing and that
belong to the steps (or their activated substeps) preceding the tran-
sitions in T2.

84
 5.4 Grafchart the basic version

8. Carry out the abortive actions associated with the steps (and their
substeps) preceding the transitions in T2.
9. Fire the transitions in T2.
10. Carry out the initially actions of the steps (and their activated sub-
steps) succeeding the transitions in T2.
11. Let T1 be the set of transitions contained in T1 that are still enabled.
If T1 is empty, go to Step 18.
12. Make sure that T1 contains no transitions that are in conflict with
each other, i.e., transitions participating in the same or-divergence
situation. If so, the number of transitions contained in T1 must be
reduced. This is done by excluding transitions participating in the
conflict until T1 no longer contains any transitions that are in con-
flict with each other. The transitions to exclude are chosen randomly.
13. Stop executing the always actions that are still executing and that
belong to the steps (or their activated substeps) preceding the tran-
sitions in T1.
14. Carry out the finally actions of the steps (and their activated sub-
steps) preceding the transitions in T1.
15. Fire the transitions in T1.
16. Carry out the initially actions of the steps (and their activated sub-
steps) succeeding the transitions in T1.
17. Let T2 be the set of transitions contained in T2 and that are still
enabled. If T2 is non-empty, go to Step 6.
18. Determine the set of fireable transitions and exception transitions
T. If T is non empty go to Step 4.
19. A stable situation is reached. Start executing the always actions
associated with the active steps (and their activated substeps). Go
to step 2.

Formal Definition
The formal definition of the basic version of Grafchart is presented to-
gether with an illustrative example in Appendix C.

85
Chapter 5. Grafchart

5.5 Grafchart the high-level version

The high-level version of Grafchart is an extended version of Grafchart-
BV that incorporates ideas from Petri nets, coloured Petri nets and object-
oriented programming. In the basic version of Grafchart, a token is simply
a boolean indicator indicating whether a step is active or not. Only one
token is allowed to reside in the chart (except in parallel situations). In
the high-level version of Grafchart the tokens are objects with an identity.
The tokens are allowed to have attributes and methods. More than one
token is allowed in a function chart and in a step. The tokens may be
of the same or of different type. To indicate if a token is present in a
step or not, a grafchart-marker is used. The grafchart marker appears as
a black or coloured filled circle and it contains a reference to the real
object token. The reason for introducing a grafchart marker that refers
to the real object token containing the attributes and methods and not
letting the grafchart marker itself contain the information has to do with
the way parallel structures are handled, see Chapter 5.5 (parallelism).
In Figure 5.27 a step containing a grafchart marker of type A is shown.
The grafchart marker contains a reference to an object token. The ob-
ject token contains attributes. The attributes of an object token can be
referenced from the actions of the step that the corresponding grafchart
marker is placed in and from the receptivities of the transitions that the
grafchart marker is currently enabling.

an Object Token A
Attribute1
Grafchart marker A Method 1

Figure 5.27 A grafchart-marker and an object-token.

An active step is indicated by the presence of a grafchart marker in the

step. Figure 5.28 (left) shows a step that is active with respect to tokens
of type A, Figure 5.28 (middle) shows a step that is active with respect
to tokens of type A and tokens of type B. The step shown in Figure 5.28
(right) is inactive.
One of the ideas of introducing object tokens is that the description of a
system can be made more compact. Imagine a system with two identical
tanks which both should be filled with water, heated and then emptied,

86
 5.5 Grafchart the high-level version

an Object Token A
an Object Token A Attribute1
Attribute1 Method 1
Method 1

an Object Token B
Attribute1
Method 1

Figure 5.28 Two active steps (left and middle), and an inactive step (right).

compare Example 5.4.1. The tanks operate independently of each other.

In the basic version of Grafchart, each tank system is controlled by a
separate Grafchart and information about e.g., the temperature, the level
etc., is stored as attributes of the entire chart, see Figure 5.29.

a grafchart process a grafchart process

name gp1 name gp2

V1 v11 V1 v21
V2 v12 V2 v22
Q q1 Q q2
L0 false L0 true
L1 false L1 false
T 100 T 500

V11

Tank1
L1
T1 T1
T Initially Initially
V12 open sup.V1 open sup.V1
L0 T2 T2
q1
Initially Initially
V21 start sup.Q start sup.Q
T3 T4 T3 T4
Initially Initially Initially Initially
Tank2 stop sup.Q close sup.V1 stop sup.Q close sup.V1
L1

T T5 T5
Initially Initially
V22 open sup.V2 open sup.V2
L0 Finally Finally
close sup.V2 close sup.V2
q2 T6 T6

Figure 5.29 A system composed of two identical tanks, each controlled by a Graf-
chart.

If, however, the high-level version of Grafchart is used, the two tanks can
be controlled by one chart in which there are two object tokens, one for
each tank. The information about, e.g., the temperature, the level etc.,
can no longer be stored in the attributes of the chart since they do not
have the same values for the two tank systems. Instead the information

87
Chapter 5. Grafchart

is stored as attributes of the object tokens, see Figure 5.30.

V11

a tanktoken
L1 Tank1
name t1
T tank tank1
V12 V1 v11
L0
V2 v12
q1 T1 Q q1
p: tanktoken L0 false
Initially
open p.v1 L1 fasle
T2
T 100
V21
p: tanktoken
Initially
start p.Q
Tank2 T3 T4
L1
p: tanktoken p: tanktoken a tanktoken
Initially Initially
T stop p.Q close p.V1 name t2
V22
L0 tank tank2
T5 p: tanktoken
Initially
V1 v21
q2 open p.V2 V2 v22
Finally Q q2
T6 close p.V2
L0 true
L1 false
T 500

Figure 5.30 A system composed of two identical tanks, controlled by one Graf-
chart.

The corresponding grafchart markers can move around in the function

chart independently of each other since the behavior of one tank does
not depend on that of the other tank. However, applications also exist
where the object tokens are not independent of each other, e.g., a produc-
tion line where the different parts move between different stations but
where it is impossible for one part to pass another. In these applications
the grafchart markers cannot pass each other and a grafchart marker
may therefore have to wait for another grafchart marker to leave a step.
Another example with dependencies between the object tokens is batch
production. The batches in a batch production cell are effected by different
recipe operations and they share the same equipment. One batch might,
e.g., have to wait for an other batch to release a resource. The high-level
version of Grafchart can be used to model structures with dependencies
between the object tokens.
A grafchart marker, or a grafchart marker together with its object token,
will most often be refered to by the shorter term token. Only when we
want to stress the fact that the grafchart marker and the object token are
two different objects their correct names will be used.

88
 5.5 Grafchart the high-level version

Steps and Actions

A step may contain several tokens of the same or of different classes. To
each step, actions can be associated. The action types are the same as in
the basic version of Grafchart, i.e., initially, finally, always and abortive.
The difference is that in Grafchart-HLV each action is associated with
a token class. An initially (finally) action is executed when an instance
of its token class enters (leaves) the step. An always action is executed
periodically when an instance of its token class is present in the step. The
actions may contain conditions that depend on the presence of tokens of
other types or on the values of their attributes.
In Figure 5.31 a step and its actions are shown. Two tokens are placed in
the step, one of class P-token and one of class Q-token. One initially
and one always action are associated with the token class P-token and
one finally action is associated with the token class Q-token.

Token class "Ptoken" Token class "Ptoken"

a Ptoken Action type "INITIALLY" Action type "ALWAYS"
name token22 For any "p:Ptoken" For any "p:Ptoken"
There exists " " There exists " "
marker grafchartmarkerx Condition" " Condition" "
y 3 Action text "conclude that Action text "conclude that
p.y = 0" p.y = p.y+1"

Token class "Qtoken"

Action type "FINALLY"
For any "q:Qtoken"
a Qtoken There exists " p:Ptoken"
name token34 Condition" p.y > 10"
Action text " conclude that
marker grafchartmarkerz q.v = p.y"
v 20

Figure 5.31 Step actions.

The actions-templates are built up by six different parts. In the token

class part, the class of the token to which the action applies is specified.
The action type indicates if the action is an initially, finally, always or
abortive action. In the for any part, the token to which the rule applies
is given a temporary-token-name, this name can be used in the action-
template to refer to the token. The there exists part can be used to
check the presence of other tokens and the condition part can used to
check if certain conditions apply. The last part of the action-template is
the action text where the action that should be performed is specified.
When a token of type P-token enters the step in Figure 5.31 its y attribute
is assigned the value zero, as specified by the initially action-template. If
the token does not directly leave the step, the always action-template will
assure that the y attribute is incremented periodically. The finally action-
template associated with the token class Q-token specifies what should
happen with a token of type Q-token when it leaves the step. If a token of

89
Chapter 5. Grafchart

type P-token exists in the step, and, if the value of the y attribute of the
P-token is greater than ten, then, when a token of type Q-token leaves
the step, the value of its v attribute will be assigned the same value as
the value of the y attribute of the P-token.

Transitions and Receptivities

Each transition has a receptivity for each token class that the transition
can be enabled by. The condition and/or the event of the receptivity may
refer to the attributes of the token that enables the transition. It may also
refer to the presence of other tokens in the input step and the value of
their attributes.
A transition can also have a receptivity that applies to a token superclass.
This means that the transition is enabled by any token belonging to a
subclass of this superclass.
In Figure 5.32 a transition and its receptivities are shown. The transition
has two receptivities, one associated with the token class P-token and one
associated with the token class Q-token.

a Ptoken
name token22
marker grafchartmarkerx
y 3

Token class "Ptoken" Token class "Qtoken"

For any "p: Ptoken" For any "q: Qtoken "

a Qtoken There exists " " There exists " p:Ptoken"
Event " " Event " "
name token34 Condition "p.y = 10 " Condition " q.v > 10"
marker grafchartmarkerz Action "move(p) " Action "move(q)
delete(p)"
v 20

Figure 5.32 Transition with multiple receptivities.

The receptivity is built up by six parts. The token class, for any and
there exists parts are used in the same way as those of a step action.
The event and condition parts are used to specify the event and condi-
tions of the receptivity. When a transition becomes fireable an operation
is performed on the tokens that are referenced by the receptivity. The
operation is specified in the action part of the receptivity.
In the standard case the operation would be to move the token from the
input step to the output step. However, it is also possible to delete and
create tokens and to change the value of the attributes of the tokens. The
latter is useful primarily for initializing the values of a newly created
token. The operations can also be more complex, e.g., an attribute of the
token can be changed at the same time as the token is moved from the

90
 5.5 Grafchart the high-level version

input step to the output step, another token placed in the input step can
be deleted or a new token can be created and placed in the output step.
It is also possible to move, not only the token that enables the transition
but also one or several of the tokens refered to in the condition or event
part of the receptivity.
The action move(p) implies that the grafchart marker that is placed in
the input step of the transition and that points on the object token named
p is moved from the input step of the transition to the output step. The
action create(P-token) implies that an instance of a P-token is created.
A grafchart marker, of the class that animates a P-token is also created
and placed at the output step of the transition. The pointer from the
grafchart marker to the P-token is created. The action delete(p) deletes
the grafchart marker that is placed in the input step of the transition
and that points to the object token named p, and deletes the object token
named p.
In Figure 5.32, two tokens are placed in the step preceding the transition,
one token of class P-token and one token of class Q-token. The transition
is enabled with respect to both token classes but it is only fireable with
respect to the token of class Q-token. When the transition fires the token
of class Q-token will be moved from the input step to the output step of
the transition and the token of class P-token will be deleted.

Parallelism
The reason for having a grafchart marker that acts as a pointer to the
corresponding object token is the way parallel structures are handled.
When the transition preceding a parallel-split (and-divergence) is fired,
the grafchart marker is moved from the input step of the transition to
the first step in one parallel branch, and copies of the grafchart-marker is
added in the first step in each of the other parallel branches. The grafchart
markers in all the parallel branches will therefore point to the same object
token according to Figure 5.33. If the value of an attribute is changed in
one of the branches it will directly be visible in all branches.
The transition after a parallel-join (and-convergence) is only enabled with
respect to a token class if all the input steps of the transition contain graf-
chart markers that point to the same object token. When the transition is
fired, one grafchart marker from one of the preceding steps in the paral-
lel branch is moved to the output step, the rest of the grafchart markers
are deleted. Since all grafchart markers, in the parallel branches, point
to the same object token it does not matter which one that is moved and
which are deleted. The parallel-join (and-convergence) situation is shown
in Figure 5.34.

91
Chapter 5. Grafchart

an Object Token
name
attribute1
attribute2

Before firing After firing

Figure 5.33 An and-divergence situation.

The reason for letting the grafchart marker point to an object token, con-
taining the attributes, and not letting the grafchart marker itself contain
the attributes, is the parallel-join structure. If the grafchart marker would
contain the attributes and if the value of an attribute of one of the graf-
chart markers, in one of the parallel-branches, is modified, it would be
unclear how the parallel-join (and-convergence) should be treated. Which
value of the attribute should be kept and which should be ignored? By

an Object Token an Object Token

name name
attribute1 attribute1
attribute2 attribute2

Before firing After firing

Figure 5.34 An and-convergence situation.

92
 5.5 Grafchart the high-level version

letting the grafchart markers be pointers to an object token containing

the attributes, problems like this are avoided. This is also a natural way
to model a system since a grafchart marker in a chart is a marker visu-
alizing the state of only one object. For example, the grafchart markers
in Figure 5.30 each represent the state of one tank. Even if the state is
visualized by a parallel-branch (the tank is heated and filled at the same
time) the markers still represent one tank.

PN-transition
A special kind of transition has been introduced in Grafchart-HLV, the
transition is called PN-transition (Petri net transition). A PN-transition
can, unlike a normal transition, have more than one incoming arc and
more than one outgoing arc. The arcs are numbered and the numbers can
be used to specify from which step and to which step the token should be
moved.
A PN-transition is shown in Figure 5.35. The PN-transition is enabled
with respect to the color P since there is a token of class P in the preceding
step connected to arc number 1. The PN-transition is also fireable since
there exists a Q token in the preceding step connected to arc number 2.
When the transition is fired, one token of color P is moved from the left
input step to the output step connected to arc number 1, and one Q token
is moved from the right input step to the output place connected to arc
number 2, as specified in the action part of the receptivity.

a Ptoken
name token22
marker grafchartmarkerx
y 3
Token class "Ptoken"
1 2
For any "p: Ptoken(1)"
There exists "q: Qtoken(2)"
1 2 Event ""
a Qtoken Condition "p.y = q.v"
name token34 Action "move(p,1 ); move(q,2 )"
marker grafchartmarkerz
v 20

Figure 5.35 An and-divergence situation using a PN-transition.

Macro steps
As soon as a grafchart marker enters a macro step a copy of the grafchart
marker is placed in the enter-step of the macro step, i.e., the grafchart
marker placed in the macro step and the grafchart marker placed in the
enter-step points at the same object token. Several tokens can be in a
macro step at the same time.

93
Chapter 5. Grafchart

Procedure- and Process steps

In the basic version of Grafchart a procedure or process step has an asso-
ciated attribute that specifies the name of the Grafchart procedure that
should be called. In Grafchart-HLV the call to a Grafchart procedure is
more flexible.

Associated with each procedure or process step is a procedure-call-temp-

late. A procedure-call-template is built up by three parts. The token class
part specifies the class of the token to which the template apply. The
parameter part specifies the attributes to the procedure, if any, and the
procedure part determines the name of the Grafchart procedure to be
called. The name of the Grafchart procedure can either be given explicitly
or implicitly through a reference.

Grafchart
procedure
gp1, a grafchartprocedure
procedure X true
call
Z 4
gp1

Token class: "Ptoken"

Parameters: "x true
z 4"
Procedure: "gp1"

Figure 5.36 Two tokens placed in a procedure step.

In Figure 5.36 a procedure step is shown. A token of class P-token is

placed within the procedure step. The token causes a call to a Grafchart
procedure named gp1. The Grafchart procedure gp1 has two attributes, x
and z. When the call is performed the x attribute is given the value true
and the z attribute is given the value 4. It is also possible to give the x
attribute and the z attribute the values of an attribute of the token. To
do this, a special inv notation is used, see Chapter 5.5 (Object Tokens).
Each call is executed in its own copy, i.e., when a call is done to a Grafchart
procedure a copy of the Grafchart procedure body is created and this copy
is executed, when the execution reaches its end the copy is deleted. This
means that there can never be more than one token in each Grafchart
procedure and therefore the Grafchart procedures of Grafchart-BV can be

94
 5.5 Grafchart the high-level version

used also in Grafchart-HLV. The attributes of the token are, if necessary,

transformed into attributes of the Grafchart procedure called by the token.

Parameterization
The parameterization feature is included in the high-level version of Graf-
chart. The sup notation can be used to reference attributes of an object
visible in the current context in the same way as presented earlier, see
Chapter 5.3.

Methods and Message Passing

The method and message passing feature is included in the high-level
version of Grafchart. The self notation can be used to reference attributes
belonging to the object of the method in the same way as presented earlier,
see Chapter 5.3

Object Tokens
In the high-level version of Grafchart, the tokens are objects with an iden-
tity. The tokens can, unlike the tokens in the basic version of Grafchart,
carry information. This feature is sometimes refered to as the object token
feature of Grafchart.

The attributes of an object token placed in a step or macro-step are refer-

enced from step actions and transition receptivities using the temporary-
token-name notation, see Chapter 5.5 (Steps and Actions) and Chapter 5.5
(Transitions and Receptivities).
In procedure or process steps, the attributes of an object token are refer-
enced using a special inv notation.

inv.attribute1
refers to the attribute1 attribute of the token

In Figure 5.37 a procedure step is shown. Two tokens are placed within
the procedure step, one token of class P-token and one token of class
Q-token. Tokens of class P-token cause calls to a Grafchart procedure
named gp1 whereas tokens of class Q-token cause calls to a Grafchart
procedure named by the proc attribute of the token itself. The grafchart-
procedure gp1 has two attributes, x and z, compare figure 5.36. When the
call to the Grafchart procedure is performed, the x attribute is given the
value of the x attribute of the P-token giving rise to the call, and the z
attribute is given the value 4.

95
Chapter 5. Grafchart

Token class: "Ptoken"

Parameters: "x inv.x
z 4"
Procedure: "gp1"

Token class: "Qtoken"

Parameters: "x ok;
y 12"
Procedure: "inv.proc"

Figure 5.37 Two tokens placed in a procedure step.

Multi-dimensional Charts
Since a token is an object and since objects are allowed to have methods
also tokens may have methods. This will give a multi-dimensional struc-
ture where a token moving around in a chart may itself contain one or
more charts. This feature is sometimes refered to as the multi-dimensional
chart feature of Grafchart. The feature gives several interesting structur-
ing possibilities.

gp2 gp1

a PToken

name
x 5
proc a grafchart
method a grafchartmethod

procedure gp1

a QToken

name
proc a grafchart
method
a grafchartmethod

procedure gp2

Token class: "Qtoken" Token class: "Ptoken"

Parameters: "x ok; Parameters: "x inv.x
y 12" z 4"

Procedure: "inv proc" Procedure: "inv proc"

Figure 5.38 A multi-dimensional chart.

96
 5.5 Grafchart the high-level version

A part of a multi-dimensional function chart is shown in Figure 5.38. It

consists of one step and one process step. A token of class P-token is
placed in the step and a token of type Q-token is placed in the process
step. The name of the Grafchart procedure to be called from the process
step is given by the reference inv proc, i.e., the Grafchart procedure to
be called is the method named proc of the token.
The Q-token, placed in the process step, in Figure 5.38 has caused a call
to the Grafchart procedure gp2. The Q-token can however, continue its
execution independently of the execution of gp2. When the P-token enters
the process step a call to the Grafchart process gp1 will be effected.
The reference to the attributes of an object token is done in different
ways depending from where the reference is done, see Figure 5.39. If the
attribute of an object token should be referenced from within the chart
where the corresponding grafchart marker is placed, the temporary-to-
ken-name.attribute notation is used, and, if the attribute should be
referenced from within a method that belongs to the object token, the
self.attribute notation is used.
In Figure 5.39 a P-token is placed in a step. The P-token has an x at-
tribute and a method called proc. The method is implemented by the graf-

a PToken

name
x 5
proc a grafchart
method
a grafchartmethod

procedure gp1

gp1

........
....... "p:Ptoken"
" p.x = 10 ..."
Action text: .....

.. self.x > 5

Figure 5.39 Different references to an attribute of an object token.

97
Chapter 5. Grafchart

chart method gp1. Associated with the step where the token is placed, is
an action. In the action the P-token is given the temporary name p and
the x attribute is refered to as p.x. The method has three steps. Associated
with the middle step is an action. When refering to the token attribute x
from within this action the self.x notation is used.
The different levels in a multi-dimensional function chart can communi-
cate with each other through the different dot notations that exist, see
Figure 5.40.

a Grafchart process
a PToken
x 14 2
name
y "true" x 5
proc a grafchart
method a grafchartmethod
1
4 3
procedure gp1

gp1

a Grafchart procedure

name gp1
..... z 56
Initially
... sup.x = 14

1
.......
....... " x inv x"
....... " inv proc"

... self ...

.....
Initially
...... p.x = 10 .....
Finally
... sup.z ....

Figure 5.40 The communication between the different levels in a multidimen-

sional function chart.

Four different dot notations exist:

1. The sup notation, described in Chapter 5.3 (Parameterization)

2. The self notation, described in Chapter 5.3 (Methods and Message
Passing)
3. The temporary-token-name notation, described in Chapter 5.5 (Steps
and Actions)
4. The inv notation, described in Chapter 5.5 (Object Tokens).

Formal Definition
The formal definition of the high-level version of Grafchart is presented
in Appendix C.

98
 5.5 Grafchart the high-level version

Conceptual Ideas
The ideas introduced in Grafchart-HLV can be used in many types of ap-
plications. The general idea is that there is a system where one or several
parts reside. The parts may be e.g., cars, people, or chemical batches.
The parts are allowed to have individual information, e.g., production-
descriptions, personal thoughts or customer demands.
The concept of Grafchart is the following: information that applies to all
parts in the system is stored either in the base-level function chart or
as global attributes whereas part specific information is stored either
as methods belonging to the token representing the part or as local at-
tributes, i.e., attributes of the token representing the part.
Consider the example of the Russian dining philosophers, [Lakos, 1994].
Four philosophers are sitting around a circular table. In front of each
philosopher there is a plate. Between each plate there is a chopstick, i.e.,
on the table there are four plates and four chopsticks. Each philosopher is
thinking of a problem. Depending on the state of the problem the philoso-
pher would either like to eat or think. If the philosopher would like to
eat, he or she can only do so if the two chopsticks on each side of his plate
are not used by any of his adjacent philosopher. In this application each
philosopher corresponds to a token. The token resides in a chart corre-
sponding to the table and its setting. The problem that the philosopher
is thinking on is represented by another chart stored as a method of the
token.
Another type of application suitable for Grafchart is production lines. In
a production line entities are produced. The entities-under-production are
moving along a conveyor belt. During their transport they pass one or sev-
eral machines. In this application each entity could be represented by a
token. If all entities should be produced in exactly the same way, the infor-
mation about how this should be done can be represented by the base-level
function chart. If the entities differs only very little, the entity-specific in-
formation can be stored as attributes of the corresponding token. From
the base-level function chart it is possible to refer to the entity-specific in-
formation when needed. Production-lines do also exist that are customer
driven, i.e., the machines that produce the entities perform different tasks
depending on the entity. In this case the base-level chart can be made very
general and information about what a machine should do with a certain
entity can be stored as methods of the token. When a token enters a step
that corresponds to a certain machine the correct method is called. In this
application several entities may be under production at the same time,
however, the entities that are under production can not pass each other
on the conveyor belt. This means that the relative order among the tokens
cannot change.

99
Chapter 5. Grafchart

5.6 Error Handling

Grafchart is, as mentioned earlier, based on Grafcet. A common prob-
lem with Grafcet is how the logic for the normal operating sequence best
should be separated from the error detection and error recovery logic. A
separation is necessary, otherwise, the function chart will rapidly become
very large, its clear structure will disappear, and the function chart will
be hard to read and understand.
Grafchart contains a number of assisting features for separation of error
handling logic and normal operating logic.

Exception transitions The exception transition, see Chapter 5.4, is a

special type of transition. The exception transition can be connected only
to macro steps and procedure steps. The exception transition is, unlike
normal transitions, constantly enabled while the macro step or process
step is active. If the macro step or procedure step is used in such a way
that it corresponds to a certain state in the application, it is, by using
exception transitions, possible to collect all error conditions, applying to
this state, in a compact way. This clarifies the implementations and it has
therefore proved to be very useful.
The exception transition has, so far, only been implemented in the basic
version of Grafchart.

Connection posts A connection post is a special G2 item used to break

a graphical connection, e.g., a connection between a step and a transition.
This enhances the readability of the chart and can be used to separate
error handling from normal operating logic. The use of connection posts
is shown in Figure 5.41. The normal operating sequence has been sepa-
rated from the error handling logic. Connection posts with the same name
establish a logical connection.

Macro actions Grafchart contains a number of macro actions. The

macro actions affect the operation of an entire function chart. The macro
actions can be called from step actions. There exist macro actions that
cause a step to be deactivated, force a step to be active, force a transition
to fire, abort an entire chart, freeze a transition or a whole chart, release
a transition or a whole chart, and resume a macro step. Similar macro
actions exist in Grafcet, [David and Alla, 1992]. The macro actions can
be used to split the error handling logic and the normal operation logic
into separate Grafcharts without loosing the interactions between the two
parts.

100
 5.6 Error Handling

Connection posts

CP1

CP1

CP2

CP2

Error handling

Normal operating sequence

Figure 5.41 Two nets connected by connection posts.

Step fusion sets Grafchart-BV also supports step fusion sets, [Jensen
and Rozenberg, 1991]. Each step in a fusion set represents one view of the
same conceptual step. Using fusion sets a step can have multiple graphi-
cal representations. When one of the steps in the fusion set becomes active
(inactive) all the steps in the set will become activated (inactivated). Fu-
sion sets can conveniently be used to separate normal operation logic from
error handling logic.

Figure 5.42 A step fusion set.

101
Chapter 5. Grafchart

A small example of a step fusion set is shown in Figure 5.42. In this

example step F1 and step F3 belong to one fusion set and step F2 and
step F4 belong to another fusion set. In Figure 5.42 step F1 is active, and
since step F3 belongs to the same fusion set also step F3 is active. Both
of the transitions following step F1 and step F3 are enabled. The normal
execution order is represented by the closed function chart: initial step,
F1, F3. If something goes wrong while being in step F1, the transition
following step F3 will fire, the error will be repaired, represented by the
intermediate step, and step F4 becomes active. At the same time as step
F4 is activated also step F2 is activated and the normal execution can
continue.

EXAMPLE 5.6.1
Consider the tank example presented in Chapter 5.4, Example 5.4.1. The
normal operation logic of this system is presented in Figure 5.26. Assume
that the normal operation can be disturbed by two faults, called X and Y,
[David and Alla, 1992]. When one of the faults occur, all actions should be
reset, i.e., all valves should be closed and all pumps and heaters switched
off. In addition to this an acoustic alarm should be turned on. When the
fault has been repaired the normal operation starts again and the acoustic
alarm is turned off. If the fault was of type X the restart should be done in
the initial state, if the fault was of type Y the restart should be done in the
state normally reached when indicator L0 becomes true. The fault is either
restored by itself or repaired by a service man. The service man can turn
off the acoustic alarm before it has been repaired. This is done by pressing
a button called service arrived. If the fault X occurs twice in less than
a minute, the fact that the fault is restored by itself will not be enough
for the system to return to its normal operation, a manual inspection is
also required. To indicate that the inspection has taken place, the service
man should press the button inspection done.
V1

L1 0. Start
1. Fill to L1
T
2. Heat to T. Start at L0
V2
L0
3. Empty to L0

Figure 5.43 A tank example.

The Grafchart for the system is presented in Figure 5.44. In this Graf-
chart, the normal execution logic and the error logic are combined into

102
 5.6 Error Handling

one Grafchart. As can be seen the Grafchart becomes very large and com-
plex. The transition receptivities for transition T1 - T6 are the same as
the ones presented in Figure 5.26, transition receptivities T8 - T15 are
presented under the function chart.

a grafchart process
name gp1
V1 v11
V2 v12
Q q1
L0 false
L1 false
T 100

T1

Initially
open sup.V1
T2

T7 T10 T13
Initially Initially
start sup.Q Initially Initially
start acoustics start acoustics start acoustics

Finally Finally Finally

T3 T4 stop acoustics stop acoustics stop acoustics

Initially Initially
stop sup.Q close sup.V1 T8 T11 T14

T5
Initially T9 T12 T15
open sup.V2
Finally
close sup.V2

T6

T7, a transition T9, a transition T10, a transition T12, a transition T13, a transition T15, a transition
event x event not(x) event x event not(x) event y event not(y)
condition last firing < 60 sek condition condition last firing > 60 sek condition inspection done condition condition

T8, a transition T11, a transition T14, a transition

event service arrived event service arrived event service arrived
condition condition condition

Figure 5.44 The tank example extended with error logic.

To make the implementation easier to grasp, exception transitions and

connection posts can be used. This solution is indicated in Figure 5.45.
The normal execution is encapsulated within a macro step to which two
exception transitions, one for each type of fault, are connected. The error
logic is stored on two separate workspaces which are connected to the
main workspace by connection posts. The transition receptivities that dif-
fers from the once shown in Figure 5.26 and Figure 5.44 are shown in the
figure.

103
Chapter 5. Grafchart

a grafchart process

name gp1
V1 v11
V2 v12
Q q1
L0 false
L1 false Error logic
T 100 C3

T7 T10
Normal execution logic Initially Initially
start acoustics start acoustics
Finally Finally
stop acoustics stop acoustics

T1 T8 T11
C1
Initially
open sup.V1
T2
T16 T9 T12
Initially
T18 start sup.Q
C3 C2
C4 T3 T4
T19 Initially Initially T7, a transition
T17 stop sup.Q close sup.V1
C2 Error logic event
condition last firing < 60 sek
T5 C4
Initially T13 Initially T10, a transition
open sup.V2 start acoustics
Finally event

T6 close sup.V2 Finally condition last firing > 60 sek

stop acoustics

T14

T16, a transition T17, a transition T18, a transition T19, a transition T15 T13, a transition
event event event x event y event
condition true condition true condition condition C1 condition true

Figure 5.45 The tank example extended with error logic.

Easy-to-grasp-solutions do also exist where macro actions or step fusion

sets are used.

5.7 Foundations of Grafchart

Grafchart is, as we have seen, a graphical programming language for se-

quential control. The language is suitable both for applications on the local
level and on the supervisory level. The language is easy to use and under-
stand and it has potential for formal descriptions, validation and analysis
as shown in Chapter 9. Furthermore, the language is well structured and
easy to use. In order to achieve this, Grafchart has been influenced by
work in several different areas. The main foundations of Grafchart are:
Grafcet, Petri nets, high-level Petri nets and object-oriented programming,
see Figure 5.46.
When reading through the foundations of Grafchart and their impact on
the language it is important to keep in mind that the main objective when

104
 5.7 Foundations of Grafchart

Petri nets

Grafcet Colored Petri nets

Objectoriented
Programming

Grafchart the basic version

Grafchart the highlevel version

Figure 5.46 The foundation of Grafchart.

developing the language has been to provide the user with a user-friendly
and graphical high-level language for sequential control. As a side effect,
caused by the connections to Grafcet and Petri nets, the language could
also, to some extent, be used for analysis and validation of systems.

Grafcet
Grafcet, [David and Alla, 1992], has a clear and intuitive syntax. Grafchart
is based on the same syntax even though it has been enlarged by some
extra graphical elements. The syntax of Grafcet has also been very well
accepted in industry. Therefore we believe that it is a good idea to keep
this syntax.

Petri Nets
It is very difficult, probably impossible, to make an informal explanation
of a function chart which is complete and without ambiguities. It is thus
extremely important that the intuition is completed by a formal definition,
[Jensen, 1992]. Both for Petri nets and Grafcet a formal description exists,
[David and Alla, 1992] and [Jensen, 1992]. A similar description language
has been worked out for Grafchart.
In order to detect e.g., deadlock situations, formal analysis methods must
exist. Since Grafchart is based upon Petri nets and since formal analysis
methods exist for Petri nets, it is sufficient to show that a Grafchart
function chart can be transformed into a Petri net and then applied to
the already existing methods. Alternatively, the Grafchart function chart
can be transformed into a Grafcet and the formal methods that have
been developed for Grafcet can be used, [Roussel and Lesage, 1996] and
[De Loor et al., 1997].

105
Chapter 5. Grafchart

High-Level Petri Nets

High-level Petri nets, [Jensen, 1992], allow a compact graphical descrip-
tion of systems with several similar parts. This can be very useful in some
applications that otherwise would have to be modeled by a very large Petri
net. A more compact description of a large system facilitates the readabil-
ity of a net, however, the readability decreases again if the description is
made to compact, compare Figure 4.1, Figure 4.2 and Figure 4.4.

Object-Oriented Programming
Object-oriented programming incorporates powerful abstraction facilities
and supports well structured applications. The parameterization and meth-
od and message passing features in Grafchart are abstraction facilities
inspired from similar features found in most object-oriented languages.
When implementing large systems it is very important to have good and
logical structuring possibilities. The object token concept is a step in this
direction.

5.8 Grafchart vs Grafcet/Petri Nets

The language of Grafcet and Petri net and the language of Grafchart have
many similarities. This is natural since Grafchart is based upon Grafcet
and Petri nets. However, there are also some important differences, these
will be pointed out in this section.

General Aim
Grafcet was developed with the focus on logical controllers (PLCs). It is
most often used only as a specification language, i.e., as a graphical de-
scription of how the controller is intended to work. The implementation is
then done either in Grafcet or in another language suitable for PLC im-
plementations such as, e.g., relay (ladder) logic diagrams or instruction
lists. Grafchart has been developed without focus on any particular ap-
plication. Grafchart is a general graphical language aimed at sequential
control. Thanks to the advanced features that are included in Grafchart,
the language is suitable to use both at the local control level and at the
supervisory control level. Grafchart is also intended to be a language used,
not only for specifications, but also for the actual implementation. A Graf-
chart function chart is interpreted on-line.

Petri net was developed with the aim to be used for analysis, simulation
and visualization of a process and not for control.

106
 5.8 Grafchart vs Grafcet/Petri Nets

Graphical Interface
The graphical interfaces of Grafcet and Grafchart have many similarities,
e.g., the steps , the transitions, the parallel structures and the alternative
structures. These similarities are intentional. However, the Grafchart lan-
guage contains more graphical elements (building blocks) than Grafcet.
The new building blocks introduced in Grafchart are: Grafchart processes,
Grafchart procedures, process steps, procedure steps and exception transi-
tions. The new building blocks do not extend the functionality of Grafchart
compared to Grafcet, but they facilitate the implementation of more ad-
vanced sequence structures. The development of Grafchart from Grafcet
can be compared to the evolution from assembler languages to high-level
programming languages like Java.

The steps in Grafchart-HLV and the places in Colored Petri nets, have
many similarities. They both represent the states of the system and they
may contain several tokens. The fact that the steps in Grafchart have
actions is a major difference from Petri nets. The actions make Grafchart
resemble Grafcet. However, places with actions can be found in a version
of Petri nets called Interpreted Petri nets, [Moalla, 1985], but here the
actions are only expressed with boolean variables.

The structure of the receptivities in Grafchart-HLV differs from the one

used in Petri nets. The receptivity in Grafchart has not only a conditional
part where it is possible to check if a variable or expression is true or false,
but also an event part where it can be detected when a variable receives
a new value. The event part in the receptivity is a trace from the Grafcet
influence. A Grafchart-HLV structure with a transition containing two
receptivities and the corresponding Colored Petri net structure is shown
in Figure 5.47.

External Interface
Grafcet and Grafchart have different external interfaces for actions and
receptivities. The external interface of Grafcet consists primarily of boolean
variables. Two action types are supported: impulse actions and level ac-
tions. The level actions are only of interest for binary variables (high/low,
true/false, etc).

The external interface of Grafchart consists of the data types that are sup-
ported by the underlying implementation language. The current toolbox
of Grafchart is implemented in G2 and it supports a lot different vari-
able types, e.g., booleans, numbers, symbols, strings, arrays, structures,
etc. Since the boolean variables are not as important in Grafchart as in
Grafcet, only impulse actions are supported.

107
Chapter 5. Grafchart

DECLARATION
color U: with b | g;
Token class: "blacktoken" color A: with B_attr | G_attr;
color P: product U*A;
For any:
There exists: "b:blacktoken" var x: U;
Event: "" var y: A;
Condition: ""

Action text: "move(b)"

Token class: "graytoken"

(x,X_attr)
There exists: "g:graytoken"
Event: ""
Condition: "" case x of
b => 1(b,B_attr)
Action text: "delete(g); | g => 1(g,G_attr)
create(b:blacktoken)"

Figure 5.47 A Grafchart structure (left) and an identical Petri net structure
(right)

Execution
The firing rules that apply to Grafchart are similar, but not identical, to
those of Grafcet.

Rule 1: All fireable transitions are immediately fired this rule

applies both to Grafcet and to Grafchart.
Rule 2: Several simultaneously fireable transitions are simultane-
ously fired for Grafcet this is true in all situations, for Grafchart
this is true for all situations except in an or-divergence situation.
Grafchart treats this situation by nondeterministically choosing one
of the branches. In order to have an interpretation algorithm with-
out ambiguities, situations like this must be avoided. It is therefore
required that the user makes all branches in an or-divergence situ-
ation mutually exclusive.
If the Grafchart is made deterministic and the Grafcet is sound, see
Chapter 3.4, this difference does no longer exist.
Rule 3: When a step must be simultaneously deactivated and ac-
tivated, it remains active this rule applies to Grafcet but not to
Grafchart. In Grafchart, the step will first be deactivated and then
activated again.

The interpretation algorithm of Grafchart describes the theoretical under-

standing of a Grafchart and guarantees that everyone faced with the same

108
 5.8 Grafchart vs Grafcet/Petri Nets

Grafchart understands it in the same way. For Grafcet, many different in-
terpretation algorithms exists. A complete and unambiguous algorithm is
given by [David, 1995]. This algorithm is global, see Chapter 3.2 (Inter-
pretation Algorithm). A global interpretation algorithm does also exist for
Grafchart. However, the algorithm currently implemented is local. When
a new external event occurs, the global algorithm searches through all
receptivities to see which transitions that have become fireable. Since the
implementation of Grafchart is based on activatable subworkspaces such a
search is not performed. When a new external event occurs or a condition
becomes true and the corresponding receptivities becomes true, a proce-
dure called fire is automatically started. This procedure takes care of the
deactivation and activation of steps and the enabling and de-enabling of
transitions. The local algorithm is more efficient and less time demanding
than the global algorithm. The local algorithm is also more suitable than
the global algorithm for applications where the execution is distributed.

EXAMPLE 5.8.1
Imagine a scenario where the execution of a system is implemented by
a Grafchart. The system could, e.g., be a production line where soda bot-
tles are being produced. Three machines are involved in the soda bottling
process. The first machine, called machine A, pours the soda into a bottle.
The second and third machine, called machine B and machine C respec-
tively, work in parallel. Machine B washes the bottles and puts a label
on them, at the same time as machine C wipes off the top of the bottle,
seals it with a cap and specifies its best-before-date. The Grafchart for
controlling the process is shown in Figure 5.48 (upper part).

The Grafchart is configured in the supervisory node but its execution is

distributed on three nodes, one for each machine. Each node contains
the relevant parts of the Grafchart. The production of a new soda bottle
is started from Node A, a token is then placed within the initial step
in the Grafchart stored in Node A. The Grafchart is executing within
Node A until the execution reaches the transition preceding the parallel
split (and-divergence). The token, with possible attributes and methods,
is then sent to Node B and Node C. These nodes know in which step the
token should be placed. Since the interpretation algorithm of Grafchart
is local, Node B and Node C can execute independently of each other.
When a new external event occurs or when a condition becomes true the
transitions concerned are fired. If the interpretation algorithm would have
been global, all transitions in the Grafchart, independently if they were
stored in Node A, Node B or Node C, would have had to been scanned in
order to see which transitions that should fire. The fact that all transitions
should be scanned through each time a new event occurs or a condition

109
Chapter 5. Grafchart

Machine A

Machine C

Machine B

Supervisory
node

Machine A ......................
......................

Soda2 Soda2 Soda2

idle running running
..

......................
...................... ...................... ......................
...................... ......................

Node A Node B Node C

Figure 5.48 A distributed system.

becomes true would require that one of the nodes acted as a supervisory
node taking care of the scanning task. In the standard for Sequential
Function Charts, IEC 1131-3, [IEC, 1993], distributed systems are not
dealt with. In the standard it is assumed that an SFC is always executed
within the same node. However, ongoing standardization efforts are also
concerning distribution.

#
The firing of a transition is viewed differently in the Grafchart-HLV and
the Petri net model. When a transition fires in a Grafchart function chart,
the tokens are moved from the input places to the output places. This
means that it is the same tokens carrying the same attributes that are
moving around in the net. In the Petri net formalism, the tokens are not
being moved from input places to output places. Instead the tokens are
removed from the input places and completely new tokens are added to

110
 5.8 Grafchart vs Grafcet/Petri Nets

the output places. It is, however, possible to obtain the same firing view,
in Grafchart as in Petri nets, by using the delete and create functions
in the receptivities but it is not the intention that these functions should
be used for this purpose.

Arc Inscriptions
In the Petri net formalism, arc inscriptions are needed to specify how the
different input places should contribute to the enabling of a transition and
how the different output places should be affected when the transition is
fired. Assume a Petri net with a place followed by an and-divergence
situation with two paths. The transition following the place is enabled if
there is a token of class P-token and a token of class Q-token in the place.
When the transition fires the two tokens should be removed from the
input place and a P-token should be added in the left path and a Q-token
should be added in the right path. In High-Level Grafchart, situations
like this can be handled in two different ways. The first solution involves
a structure transformation. The and-divergence case is transformed into
an or-divergence case and an extra empty dummy step is introduced, see
Figure 5.49.
a Ptoken
name token22
marker grafchartmarkerx
y 3

Token class "Ptoken"

a Qtoken
name token34
For any "p:Ptoken"
There exists "q: Qtoken"
marker grafchartmarkerz Event ""
v 20 Condition ""
Action "move(p); move(q)"
Dummy

Token class "Ptoken"

Token class "Qtoken"
For any "p:Ptoken"
There exists "" For any "q: Qtoken"
Event "" There exists ""
Condition "" Event ""
Action "move(p)" Condition ""
Action "move(q)"

Figure 5.49 An and-divergence situation transformed into an or-divergence situ-

ation.

In most applications, however, this structure transformation is undesir-

able. Therefore a special kind of transition, named PN-transition, was
introduced, see Chapter 5.5 (PN-transition). A PN-transition can have
more than one incoming arc and more than one outgoing arc. The arcs are
numbered and the numbers can be used to specify from which step and to
which step the token should be moved. The arc numbers of PN-transitions
is the only case where arc inscriptions are used in Grafchart-HLV.

111
Chapter 5. Grafchart

Grafchart - the basic version: Transformation to Grafcet

Since the new building blocks introduced in Grafchart do not extend the
functionality, a Grafchart can be transformed into an equivalent Grafcet.
A Grafchart and a Grafcet are identical if, applied to the same input
sequence, their output sequences are identical.

The transformation of a Grafchart to a Grafcet consists of three steps.

First, the graphical elements must be changed to those of Grafcet. Sec-
ondly, the action types of Grafchart must be changed to those of Grafcet.
Special care has to be taken to the firing rules that are interpreted dif-
ferently in the two models.

Graphical elements: If the Grafchart contains only transitions and steps

without any actions, the structure of the corresponding Grafcet will be
identical to that of the Grafchart. If the Grafchart contains macro steps,
the Grafchart macro step icon must be changed to that of Grafcet. The
enter step and the exit step of the Grafchart macro step must be replaced
by an input step and output step of Grafcet. Alternatively, the macro step
icon can be replaced by its internal structure in which the enter step and
exit steps are replaced by ordinary steps.

If the Grafchart contains procedure steps these should be replaced by a

Grafcet macro step. The internal structure of the macro step should be
that of the Grafchart procedure called by the procedure step, see Fig-
ure 5.50.

T1 T1
a procedurestep M1
name I
parameters
T2 T2
procedure gp1 T5
M1
Procedure call
T5
T3 T6
T3
O
T6
Grafchart
T4 procedure T4
gp1

Figure 5.50 A Grafchart (left) and an identical Grafcet (right).

112
 5.8 Grafchart vs Grafcet/Petri Nets

If the Grafchart contains process steps, these should be replaced by a par-

allel construct (and-divergence) with two branches. One branch contains
an empty step followed by the transition succeeding the process step. The
second branch contains an empty step followed by an alternative struc-
ture (or-divergence) where each path contains a macro step followed by
a sink transition. The macro steps are all identical and their internal
structure is that of the Grafchart procedure called by the process step.
The transition preceding a macro step contains a receptivity that assures
that the token does not enter a macro step that is already active. The
number of paths in the alternative structure are equal to the number of
processes that can run at the same time. This number has to be finite.
The transformation of a process step is shown in Figure 5.51.

M1, M2, ... , MK

I

a a
Grafchart
procedure
gp1 O
b b

a process step

name
c parameters c
procedure M1 M1. M2 M1.M2....MK
gp1
M1 M2 MK

d d

Figure 5.51 A Grafchart(left) and an identical Grafcet (right).

If the macro step or procedure step has an exception transition connected

to it, the macro step icon or procedure step icon has to be replaced by its
internal structure. To each of the internal steps an extra transition has to
be added containing the events and conditions of the exception transition.
The transformation of an exception transition is shown in Figure 5.52.
As can be seen in the figure each step contained in the internal structure of
the macro step or procedure step is, in the Grafcet representation, followed
by an or-divergence situation. In order to have a deterministic interpre-
tation algorithm it is required that all branches in an or-divergence situ-
ations are made mutually exclusive, see Chapter 5.8 (Execution). When
a procedure step or macro step have an exception transition connected to
it, it is most often the users intention that this transition should have a
higher priority than the transitions within the internal structure. In Fig-
ure 5.52 this means that the receptivities b, d, e, c should be extended
with the receptivity not(a). Another possibility is to solve the problem

113
Chapter 5. Grafchart

b d
a
e
e
c

f c
a a a a

Figure 5.52 A Grafchart(left) and an identical Grafcet (right).

by letting an exception transition have a higher priority than an ordinary

transition. This solution is however not ideal since it implies that the
corresponding Petri net, used for analysis purposes, is a Petri net with
priority. A Petri net with priority is, concerning complexity, comparable
with a Turing machine and it can therefore not be analyzed.
Action types: Each step in Grafchart, that contains actions can be re-
placed by one or several steps with actions in Grafcet. Since Grafcet does
not include the concept of impulse actions executed at other time instances
than at the activation of the step, the Grafcet structure, corresponding to
a Grafchart step with several actions, must include more than one step.
The Grafcet structure must assure that the Initially action occurs first,
this is guaranteed by starting the Grafcet structure with an impulse ac-
tion in a separate step. After this step follows a loop taking care of the
periodically execution of the Always action. The execution period of this
action should be the same as the scan interval of the Always action imple-
mented in Grafchart. Finally a separate step ends the Grafcet structure.
This step contains an impulse action corresponding to the Finally action
in Grafchart. The transformation is shown in Figure 5.53.
The transformation of a macro step with actions, or procedure step or
process step for which the corresponding Grafchart procedure has actions,
is possible but results in a large and complex Grafcet.

114
 5.8 Grafchart vs Grafcet/Petri Nets

A*

1
a scan interval
Initially A
Always B B*
Finally C
b 1
b

C*
c
true

Figure 5.53 A Grafchart(left) and an identical Grafcet (right).

Firing rules: The firing rules are not exactly identical in Grafchart and
in Grafcet. A step that has to be simultaneously deactivated and activated
remains active in Grafcet. This means that an impulse action associated
with such a step in Grafcet will not be executed whereas an initially
action associated with such a step in Grafchart will be executed. Some
Grafchart structures therefore has to be extended with an extra step in
the corresponding Grafcet, see Figure 5.54.
The activation of the extra step assures that the step containing the im-
pulse action is deactivated. A transition with a receptivity that is always
true follows the extra step. When this transition fires the step with the
impulse action is activated again and its impulse action is executed.

Grafchart - the high-level version: Transformation to Petri nets

The main reason for transforming a Grafchart into a Grafcet is to show
that a system can equally well be controlled by a Grafchart as a Grafcet.
However, the Grafchart structure is, especially for larger and more com-
plex systems, much clearer and better structured than the corresponding
Grafcet. A Grafchart structure can also be transformed into a Petri net
structure. The main reason for this transformation is analysis. The Graf-

115
Chapter 5. Grafchart

T1 a

Initially A T1 a A*

T2 true

Figure 5.54 A Grafchart(left) and an identical Grafcet (right).

chart to Grafcet transformation consists of three steps; graphical element,

action type and firing rule transformation. In the Grafchart to Petri net
transformation only the graphical element transformation has to be con-
sidered. The action type transformation does not have to be considered.
Since a Petri net does not have any actions, the actions are simply ne-
glected. The firing rule transformation has to do with the firing of tran-
sitions. Since most analysis methods of Petri nets assumes autonomous
Petri nets i.e., Petri nets without transition receptivities, this transforma-
tion step can also be left out.
Graphical elements: In order to transform a Grafchart into a Petri net,
possibly non-autonomous, the following rules apply:

1. A step is replaced with a Petri net place.

2. A transition remains unchanged.
3. A Grafchart parallel structure or alternative structure are replaced
with the syntax of a parallel or alternative structure of Petri net,
see Chapter 2.2.
4. The actions are neglected.
5. The receptivities are rewritten from the language of Grafchart to a
language used for Petri nets.
6. Macro-steps are replaced with their internal structure.
7. Procedure-steps are replaced with the internal structure of the cor-
responding Grafchart procedure.
8. Process-steps are replaced with a parallel branch in which the in-
ternal structure of the corresponding Grafchart procedure is placed.

116
 5.8 Grafchart vs Grafcet/Petri Nets

9. Parameterization of actions are of no importance because of (4).

10. If parameterization is used in a transition receptivity, this transition
must be replaced by an or-divergence situation where there is one
branch for each receptivity possibility.
11. If the call to a Grafchart procedure, performed from a procedure-step
or process-step is parameterized, each possibility must be analyzed.
12. Method calls are treated in the same way as procedure calls.

Advanced Features
The two features in Grafchart, parameterization and methods, cannot
conveniently be reconstructed in Grafcet or Petri nets. The parameteriza-
tion feature can only be reconstructed by having one Grafcet/Petri net for
each parameter setup, which is of course a bad replacement. The method
feature can be reconstructed by having ordinary macro steps as replace-
ments for the methods. This will give the same functionality but it will
not allow the application to be as well structured and organized.

Analysis
A Grafchart can be transformed into a Petri net and the analysis methods
that exist for Petri nets can be applied. This means that a Grafchart can
be analyzed with respect to, e.g., deadlock situations, see Chapter 9. The
transformation procedure should turn the Grafchart into an autonomous
Petri net, i.e., a Petri net without any actions or receptivities. This means
that it is only the structure of the Grafchart that can be analyzed see
Chapter 9.3.
True formal analysis requires that the step actions and the transition re-
ceptivities are taken into consideration. This is not the case in the analysis
examples presented in this thesis, see Chapter 9. However, true formal
verification support exists for Grafcet, see [Roussel and Lesage, 1996]
and [De Loor et al., 1997], and might be of interest also for Grafchart.
There is always a trade off between the complexity of the analysis methods
and the completeness of the generated results. The more complex meth-
ods, the more complete are the results. Complete results are, of course,
always prefered to narrow ones. However, when the analysis methods be-
come too complex, they will be too time-demanding or too complicated to
use, which will result in no result at all, and a narrow result is, of course,
always prefered to no result at all.
The analysis methods used in the thesis, see Chapter 9 are simple and the
generated result does therefore not answer all analysis related questions
but the generated result can still be of large interest in many applications.

117
Chapter 5. Grafchart

5.9 Implementation
An implementation of Grafchart has been made in G2, an object oriented
programming language, [Gensym Coorporation, 1995]. G2 is briefly de-
scribed in Appendix E. The Grafchart objects are implemented as G2
objects and the connections are represented by G2 connections.
The implementation of Grafchart is based on the G2 concept of activatable
subworkspaces. A workspace is a virtual, rectangular window upon which
various G2 items such as rules, procedures, objects, displays, and interac-
tion buttons can be placed. A workspace can also be attached to an object,
see Figure 5.55. In this case the workspace is called a subworkspace of
that object. When a subworkspace is deactivated, all the items on the
workspace are inactive and invisible to the G2 run-time system.

Subwork-
space

Object

Figure 5.55 An object and its subworkspace.

Grafchart - the basic version

Grafchart exists in two different versions, each having its own implemen-
tation. Grafchart-BV is the oldest version and was implemented first.

Steps and actions The actions associated with a step are placed on the
subworkspace of the step. The actions are represented by G2 rules. The
subworkspace of the step is only active when the step itself is active, this
means that the rules, placed on the subworkspace, are only executed when
the step is active. The actions that may be performed are the action types
provided by G2. For example, it is possible to assign values to variables, to
start procedures, to create and delete objects, hide and show information,
perform animation actions, etc.
The actions are written in the G2s built in rule language. Sometimes,
however, the syntax of G2 can be somewhat annoying. To facilitate for
the user, the actions are therefore entered as action templates. These are
text strings that during compilation are translated into the correspond-
ing G2 rules. The entire syntax of G2 can be used in the action tem-
plates together with additional constructs of a syntactical sugar nature.
For example, the sometimes long and complicated syntax of certain G2

118
 5.9 Implementation

subworkspace of
the step
Action-template

Initially subworkspace of
Step conclude that s10.X = 5 the action-template
Name S10 G2-rule
X

Initially
conclude that the x of s10 is 5

Figure 5.56 A step, an action template and the corresponding G2 rule.

expressions can be replaced by a shorter and simpler expression using a

Pascal-like dot notation, e.g. instead of referring to an attribute of an ob-
ject using the standard syntax of G2 as the attribute1 of object1 the
shorter notation object1.attribute1 can be used. In Figure 5.56 a step
and its subworkspace is shown. On the subworkspace an initially action
template is placed. During compilation a subworkspace of the action tem-
plate is created where the corresponding G2 rule is placed. In Figure 5.56,
the subworkspace of the action template and the corresponding G2 rule
are shown under the subworkspace of the step.

Transitions and receptivities The condition and event of a transition

receptivity are entered as attributes of the transition. During compilation
the attributes are automatically translated into an appropriate G2 rule
(compare step actions), which is placed on the subworkspace of the tran-
sition. The subworkspace is only active when the transition is enabled.
A transition that only contains a logical condition is translated into a
scanned when rule with the shortest scan interval possible. A transition
that contains only an event expression and/or an event expression and
a logical condition is translated into a whenever rule that will fire asyn-
chronously when the event occurs.

When the transition fires, i.e., when the G2 rule condition becomes true
and/or the event occurs, the G2 rule starts a procedure that takes care
of the activation and deactivation of steps and transitions.

119
Chapter 5. Grafchart

subworkspace of
the transition
G2-rule

a transition
When n>4 then start fire(the
Name T2 generic-transition superiour to
Event this workspace)
Condition n>4

Figure 5.57 A transition, its attributes and the corresponding G2 rule.

In Figure 5.57 a transition is shown together with its event and condi-
tion attributes. The corresponding G2 rule is placed on the subworkspace
of the transition as shown in the same figure.

Class hierarchy The objects in Grafchart are defined in classes. The

relation between different classes is described by a class hierarchy. At-
tributes and methods can be associated with a class. A class defined above
another class is called a superclass and a class defined below another class
is called a subclass. G2 supports multiple inheritance and polymorphism.
The graphical language elements in Grafchart are defined in the class
hierarchy shown in Figure 5.58.
During compilation the action templates defining the actions of a step
and the attributes defining the receptivity of a transition are translated
into the corresponding G2 rules. Each class has a method, called compile,
that describes how this class should be translated. The translation of a
function chart is initialized by a call to a procedure called compile. This
procedure traverses the function chart and calls the compile-method of
each object in the function chart.

Interpretation algorithm The interpretation algorithm used in the

implementation of Grafchart is based on the one given in Chapter 5.4.1.
However, the algorithm given in Chapter 5.4.1 is a global algorithm where-
as the one implemented in G2 is local. When a new external event occurs,
the global algorithm searches through all receptivities to see which tran-
sitions that have become fireable. Since the implementation is based on
activatable subworkspaces and G2 rules such a search is not performed.
When a new event occurs or a condition becomes true the G2 rule, that
corresponds to a receptivity, immediately becomes true and a G2 proce-
dure, called fire is automatically started, see Figure 5.57. This procedure

120
 5.9 Implementation

Grafchart-object

Generic-transition Grafchart-process Generic-step Grafchart-procedure Parallel-bar

Transition Exception-transition Non-macro-step Generic-Abstraction-step Parallel-split Parallel-join

Exit-step Enter-step Step Initial-step Macro-step Generic-procedure-step

Procedure-step Process-step

Figure 5.58 The class hierarchy in Grafchart.

takes care of the deactivation and activation of steps and the enabling
and de-enabling of transitions. The local algorithm that is used in the im-
plementation is more efficient and less time demanding than the global
algorithm. In almost all cases the behavior is equivalent to the behavior
of the global algorithm.

EXAMPLE 5.9.1
Figure 5.59 shows a part of a function chart. The function chart has two
steps, named S1 and S2, and two transitions, named T 1 and T 2. Step
S1 is active and step S2 is inactive.

When the receptivity of transition T 1 becomes true the procedure fire

is started. The procedure calls, in the given order, the following methods:
deactivate-step, activate-step, de-enable and enable. In Figure 5.59
this corresponds to deactivation of step S1, activation of step S2, de-
enabling of transition T 1 and enabling of transition T 2.

121
Chapter 5. Grafchart

S1

1. deactivate-step
T1 3. de-enable

2. activate-step
S2

T2 4. enable

Figure 5.59 Firing of transition T1.

Firing of a transition The deactivation and activation of steps as well

as the de-enabling and enabling of transitions can be more complicated
if there are more than one input or output step or transition and/or if a
parallel path or an alternative path is affected by the firing.
When a transition is fired, the following will happen (action execution not
taken into account).

1. Deactivate-step
(a) If the Grafchart object preceding the transition is a parallel-join
the deactivation will be done for all Grafchart objects preceding
the parallel-join.
(b) If the Grafchart object preceding the transition is a macro step
the deactivation will done for the macro step and the exit step
of the macro step.
(c) If the Grafchart object preceding the transition is a procedure
step the deactivation will be done for the procedure step and
for the exit step of the corresponding Grafchart procedure.
(d) If the Grafchart object preceding the transition is a process-
step, it will not be deactivated.
(e) If the Grafchart object preceding the transition is a step, the
step will be deactivated.

122
 5.9 Implementation

2. Activate-step

(a) If the Grafchart object succeeding the transition is a parallel-

split the activation will be done for all Grafchart objects suc-
ceeding the parallel-split.
(b) If the Grafchart object succeeding the transition is a macro step
the activation will be done for the macro step and for the enter
step of the macro step.
(c) If the Grafchart object succeeding the transition is a procedure
step the activation will be done for the procedure step and for
the enter step of the corresponding Grafchart procedure.
(d) If the Grafchart object succeeding the transition is a process-
step the activation will be done for the process step, if it is
not already active, and for the enter step of the corresponding
Grafchart procedure.
(e) If the Grafchart object succeeding the transition is a step, the
step will be activated.

3. De-enable

(a) The de-enable message is sent to the Grafchart object preceding

the transition.
i. If, however, this Grafchart object is a parallel-join the de-
enable message will be sent to each Grafchart object pre-
ceding the parallel-join.
(b) The objects receiving the de-enable message transmit the mes-
sage to each succeeding Grafchart object.
i. If, however, this Grafchart object is a parallel-join the de-
enable message will be sent to each Grafchart object suc-
ceeding the parallel-join.
(c) The Grafchart object is now a transition, this transition is de-
enabled.

4. Enable

(a) The enable message is sent to the Grafchart object succeeding

the transition.
i. If, however, this Grafchart object is a parallel-split the en-
able message will be sent to each Grafchart object succeed-
ing the parallel-split.

123
Chapter 5. Grafchart

(b) The objects receiving the enable message transmit the message
to each succeeding Grafchart object.
i. If, however, the Grafchart object is a parallel-join the enable
call will be sent to each Grafchart object succeeding the
parallel-join.
(c) The Grafchart object is a transition, this transition is enabled.
i. If, however, this Grafchart object preceding the transition
is a parallel-join the transition will only be enabled if all
input places to the parallel-join are active.

EXAMPLE 5.9.2
Consider the function chart in Figure 5.60. Transition T 1 and T 2 are
enabled. If transition T 1 fires, the following will happen.

1. Deactivate S1.
2. Activate the parallel bar P B1, i.e activate the steps S3 and S4.
3. De-enable the transitions T 1 and T 2.
4. Enable the transitions T 3 and T 4. Transition T 5 will not be enabled
since S5 is not active.

S1

T1 T2
PB1
S2

S5 S3 S4

PB2 T3 T4
T5

Figure 5.60 The firing of a transition.

124
 5.9 Implementation

Grafchart - the high-level version

The high-level version of Grafchart is the most recent version of Grafchart.
The implementation of this version has tried to mimic the implementa-
tion of Grafchart-BV as much as possible concerning the object names,
procedure names and the class hierarchy. This facilitates for the users
who want to familiarize themselves with the implementational details of
both languages.

Steps and actions The actions associated with a step are placed on
the subworkspace of the step. The actions are represented by action-
templates. Each action-template is related to a token class. During com-
pilation each action-template is translated to a G2 rules. The G2 rule is
placed on the subworkspace of the action-template, see Figure 5.61.
When a token enters a step its class is compared with the class speci-
fied in the action-templates placed on the subworkspace of the step. If
the class of the token and the class of an action-template are the same
the subworkspace of the action-template is activated, i.e., the G2 rule
is activated. The G2 rule checks if the conditions and requirements for
activation are fulfilled. If this is the case, the action is executed.
subworkspace of
the actiontemplate
G2 rule

actiontemplate
for and Qtoken q that is actioninvoking the
actiono superior to this workspace
Token class "Qtoken"
Action type "FINALLY" when (there exists a grafchartmarkero qgmo
that is animating q such that (qgmo is placedat
For any "q:Qtoken" the genericstepo superior to the workspace of
There exists " p:Ptoken" the actiono superior to this workspace))
Condition" p.y > 10" and (the status of qgmo is final)
Action text " conclude that
q.v = p.y" and (there exists a Ptoken p such that (the
grafchartmarkero that is animating p is placedat
the genericstepo superior to the workspace of
the actiono superior to this workspace))
and (the y of p >10)
then conclude that the v of q = the y of p

Figure 5.61 Step action and G2 rule.

Transitions and receptivities The receptivities associated with a

transition are placed on the subworkspace of the transition. The receptiv-
ities are represented by receptivity-templates. Each receptivity is related
to a token class. During compilation each receptivity-template is trans-
lated to a G2 rules. The G2 rule is placed on the subworkspace of the
receptivity-template.

125
Chapter 5. Grafchart

When a token enters a step its class is compared with the class specified
in each receptivity-template belonging to the receptivities of the enabled
transitions. This means that a receptivity-template associated with to-
ken class Q is only active if there is a token of class Q that enables the
transition, i.e., if there is a token of class Q in the preceding step of the
transition. If the class of the token and the class of a receptivity-template
are the same the subworkspace of the receptivity-template is activated,
i.e., the G2 rule is activated. The G2 rule checks if the receptivity is true.
If so, the receptivity is fired.

Compilation Before a Grafchart-HLV can be executed it has to be com-

piled. During compilation all actions and all receptivities are translated
into a corresponding G2 rules. This means that all sup notations and self
notations are replaced by a G2 expression. Most often the G2 expressions
become very complex and hard to read, this explains why the dot notation
was introduced. The G2 rule is hidden for the Grafchart user.
The finally action in Figure 5.31 and its corresponding G2 rule is shown
in figure 5.61.

Class hierarchy The graphical language elements in Grafchart-HLV

are defined in a class hierarchy, see Figure 5.62. The class names are
extended with -o to indicate that these classes are used in the high-level
version of Grafchart.

Object-grafchart-object

Generic-transition-o Grafchart-marker-o Generic-step-o Object-token Parallel-construct-o

Transition-o PN-transition-o Non-macro-step-o Abstraction-step-o Parallel-split-o Parallel-join-o

Exit-step-o Enter-step-o Step-o Initial-step-o Macro-step-o Procedure-step-o Process-step-o

Figure 5.62 The class hierarchy in Grafchart-HLV.

126
 5.9 Implementation

To specify the actions associated with a step the user uses an object called
action-o, to specify the receptivities associated with a transition the user
uses an object called receptivity-o and to specify the name of the Graf-
chart procedure that is to be called from a procedure or process step an
object called procedure-call-o is used. The class hierarchy of these three
template-elements and their icons are shown in Figure 5.63 and 5.64.

Object-grafchart-object

Action-o Receptivity-o Procedure-call-o

Figure 5.63 The class hierarchy in Grafchart-HLV.

Token class "" Token class "" Token class ""

Action type ""
For any "" Parameters ""
For any "" There exists ""
There exists "" Event "" Procedure ""
Condition "" Condition ""
Action text "" Action ""

Action-o Receptivity-o Procedure-call-o

Figure 5.64 The class hierarchy of the template-elements in Grafchart-HLV.

Relations The implementation relies on the use of G2 relations. The

following relations are used.
The relation between a grafchart marker and an object token is called
animating. A grafchart marker may be animating at most one object to-
ken. The inverse relation is called animated-by. An object token may be
animated-by more than one grafchart marker.
The relation between a grafchart marker and a step is called placed-at
and the inverse relation is called holding. A grafchart marker may be
placed-at at most one generic-step but a generic-step may be holding more
than one grafchart marker.
A relation exists between grafchart markers and receptivities. This rela-
tion is called activating, the inverse relation is called activated-by. A

127
Chapter 5. Grafchart

grafchart marker may be activating more than one receptivity. A recep-

tivity may be activated-by more than one grafchart marker.
A relation exists between object tokens and receptivities. This relation
is called enabling, the inverse relation is called enabled-by. An object
token may be enabling more than one receptivity. A receptivity may be
enabled-by more than one object token.
The relation between an object token and an action is called action-
invoking. The inverse relation is called action-invoked-by. An object
token may be action-invoking more than one action. An action may be
action-invoked-by more than one object token.
A relation exists between a grafchart marker and a Grafchart-procedure.
This relation is called marker-invoking and the inverse relation is called
marker-invoked-by. A grafchart marker may be marker-invoking more
than one Grafchart procedure. A Grafchart procedure may be marker-
invoked-by at most one grafchart marker.

5.10 Applications
Grafchart, both the basic and the high-level version, has been used in
several applications.

Training Simulator
Grafchart-BV has been used to implement a prototype of a training simu-
lator for a sugar crystallization process, [Nilsson, 1991]. In this application
Grafchart is used both to structure the simulation model of the process
and to implement the control system of the process.

Hydrogen Balance Advisory Control

Grafchart-BV has been used to implement a knowledge-based system,
(KBS), that generates on-line advice for operators regarding the distri-
bution of hydrogen resources at the Star Enterprise Delaware City Re-
finery [rzn, 1994a]. The system uses KBS techniques coupled with nu-
merical optimization. The specific problem that is solved is to meet the
needs of the hydrogen consuming units in the refinery while minimizing
the hydrogen that is wasted. A catalytic reformer unit produces hydrogen
as by-products. A hydro cracker unit consumes high purity hydrogen and
vents low purity hydrogen. Hydrogen from these units is used to satisfy
the needs of the hydrogen consuming hydro treaters, sulphur recovery,
methanol, and naphtalene units. Any additional hydrogen needs must be
met by a hydrogen production unit.

128
 5.10 Applications

Flexible Manufacturing Cell

In [Lopez Gonzlez et al., 1994] a system is described were Grafchart-BV
is used to implement a flexible manufacturing cell. 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 ex-
ecuted 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.

Lego Car Factory

A Grafchart model of the control system for a LEGO car factory has been
implemented, using an early version of Grafchart-HLV. The LEGO car fac-
tory is a small car factory model built in LEGO that assembles toy LEGO
cars. The factory itself is built in LEGO and consists of four conveyor
belts, three storages for chassis, car frames, and car bodies respectively,
two pressing machines, three machines that take parts from storage, and
one machine that turns the car on the conveyer belt. The factory is sup-
plied with several position sensors.
The model of the control system consists of two function charts. The car-
controller is a straight sequence where each token represents a car. Each
macro-step represents a certain operation that is performed on the car.
The machine-controllers have one token for each machine. The actions
and conditions in the car-controller depend on the presence of a car in a
certain step. The control system is structured into one machine part and
one product part. The product in this case is the cars. Similar structuring
concepts can also be applied to general discrete manufacturing problems.
The LEGO car factory is presented in [rzn, 1994a].

Alarm Filtering
Grafchart-HLV has been used to implement alarm filters. Information
overload due to large numbers of warnings and alarms is a common prob-
lem 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 mul-
tiple 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

129
Chapter 5. Grafchart

for strings in a formal language. Since Grafchart is an extended state

machine with temporal facilities it is possible to accept more general ex-
pressions than the regular expressions that are possible with ordinary
state machines.
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 Grafchart for
parallel and alternative paths, different sequence patterns of these types
can be easily expressed. Situations when temporal constraints between
alarms are important can also be expressed with Grafchart. Represen-
tation of different event patterns in Grafchart is presented in detail in
[rzn, 1996].

Batch Recipe Structuring

Batch recipe structuring is the main application area of Grafchart. Graf-
chart is used at two levels, to represent the sequential structure in the
recipes and to represent the sequence control logic contained in the equip-
ment units. A number of different ways to structure the recipes, using
either Grafchart-BV or Grafchart-HLV, have been investigated, see Chap-
ter 8.

5.11 Summary
Grafchart is the name of a mathematical sequential control model and
a toolbox. Grafchart is based on a syntax similar to that of Grafcet. The
graphical elements are steps, transitions, macro steps, procedure steps,
process steps, Grafchart procedures and Grafchart processes. Grafchart
also includes ideas from Petri nets, high-level nets and object-oriented pro-
gramming. Advanced features like parameterization, methods and mes-
sage passing, object tokens, and multi-dimensional charts, are included
in the language. The language exists in to different versions: one basic
version, mainly based upon Grafcet, and one high-level version including
more ideas from Petri nets and object-oriented programming. Grafchart
is aimed at sequential control application at local and supervisory level.

130
6
Batch Control Systems

Industrial manufacturing and production processes can generally be clas-

sified as continuous, discrete or batch, [Fisher, 1990]. How a process is
classified depends mainly upon how the output from the process appears.
In continuous processes, products are made by passing materials through
different pieces of specialized equipments. Each of these pieces of equip-
ment ideally operates in a single steady state and performs one dedicated
processing function. The output from a continuous process appears in a
continuous flow, [ISA, 1995].
In discrete manufacturing processes, products are traditionally manufac-
tured in production lots based on common raw materials and production
histories. In a discrete manufacturing process, a specified quantity of prod-
ucts moves as a unit (group of parts) between workstations and each part
maintains its unique identity, [ISA, 1995]. The output from a discrete
manufacturing process appears one by one or in quantities of parts.
A continuous process might be, e.g., water purification plants, paper mills
or the generation of electricity from a power plant, whereas a discrete
manufacturing process could be, e.g., the production of cars.
In batch manufacturing the output appears in lots or in quantities of ma-
terials. The product produced by a batch process is called a batch. Batch
processes are neither continuous nor discrete, yet they have characteris-
tics from both.
An example of a batch process, [Rosenhof and Ghosh, 1987], taken from
our daily life, is the preparation of a cake. The work can be divided into
three major tasks: preparation, baking, and cooling and storing. The three
tasks can be broken down into a sequence of substeps. The steps in each
task should be done in a proper order to make a good cake. If not done
in this way, the cake might not be very tasty and, as explained below, do
not adhere to the formal definition of a batch process.

131
Chapter 6. Batch Control Systems

Batch processes define a subclass of sequential processes. The difference

is that sequential processes not necessarily have to generate a product
whereas batch processes do. In industry, batch and sequential processes
are used in many ways and in many areas: food engineering, pharmaceu-
tics, biotechnical manufacturing and chemical plants.
A formal definition of batch process is given by [Shaw, 1982]:
A process is considered to be batch in nature if, due to physical
structuring of the process equipment or due to other factors, the
process consists of a sequences of one or more steps that must be
performed in a defined order. The completion of this sequence
of steps creates a finite quantity of finished product. If more of
the product is to be created, the sequence must be repeated.
An other definition is given by [ISA, 1995]:
A batch process is a process that leads to the production of
finite quantities of material by subjecting quantities of input
materials to an ordered set of processing activities over a finite
period of time using one or more pieces of equipment.

6.1 Batch Processing

Continuous processes have been used to produce many products that were
originally produced by batch processes. One reason for this is that batch
processes have typically been labor intensive and experienced operators
have been required to produce batch products with consistent quality.
Since continuous plants were those that produced the largest volume of
products this is where most of the research and development money were
spent. However, increasing demands on flexibility and customer-driven
production has led to an increased interest in batch processes. This is
because batch processes are more economical for small scale production,
as fewer pieces of process equipment are needed, and intermediate storage
are not very expensive. Batch plants can also be made highly flexible, and
thereby well suited for manufacturing of special products. For example,
high quality malt whisky is produced in batch processes whereas grain
liquor, the basis for blended whisky, is produced in continuous processes.
There are also processes that are not easily amenable to continuous op-
erations. Some examples are given in [Rosenhof and Ghosh, 1987]:

1. Processes with feedstocks and/or products that can not be handled

efficiently in a continuous fashion, such as solids and highly viscous
materials.

132
 6.1 Batch Processing

2. Processes in which the reactions are slow, requiring the reactants to

be held in process vessels for a long time (e.g. fermentation of beer
and wine).
3. Processes in which only small quantities of products and/or different
grades of the same product are required in limited quantities (e.g.
dyestuff and specialty chemicals).
4. Processes that need precise control of raw materials and production
along with detailed historical documentation (e.g. drug manufactur-
ing).

Typically, batch plants are used to manufacture a large number of prod-

ucts. Within each product a number of different grades often exist.
Batch processes can be classified by: (1) the number of products they can
make and (2) the structure of the plant, [Fisher, 1990].

1. A batch process can be single-product, multi-grade or multi-prod-

uct. A single product batch plant produces the same product in each
batch, e.g., a batch pulp digester. The same operations are performed
on each batch and the same amount of raw materials is used. A
multi-grade batch plant produces products that are similar but not
identical. The same operations are performed on each batch but the
quantities of raw materials and/or processing conditions such as,
e.g., temperatures, may vary with each batch. The multi-product
batch plant produces products utilizing different methods of pro-
duction or control. The operations performed, the amount of raw
materials and the processing conditions may vary with each batch.
2. The basic types of batch structures are series (single-stream), paral-
lel (multi-stream) and a combination of the two. A series structure
is a group of units through which the batch passes sequentially.
If the plant has several serial groups of units placed in parallel but
without interaction the plant has a parallel structure. If interactions
exists between the parallel branches, a series/parallel structure is
achieved. Other names for the series, parallel and series/parallel
structures are single-path, multi-path and network-structure, [ISA,
1995].

The batch plant classification by product and by structure can be combined

in a matrix to show the degree of difficulty in automating the various
combinations. The single-product, single-path batch plant is the simplest,
whereas the multi-product, network-structure combination is the most
demanding.

133
Chapter 6. Batch Control Systems

6.2 Batch Control

Batch control projects have traditionally been among the most difficult
and complex to implement [ARC, 1996]. Typically, batch control projects
span over a wider scope of functionality than that required for either con-
tinuous or discrete manufacturing processes. With continuous and discrete
processes, a reasonable level of automation can be attained merely by im-
plementing basic regulatory or logic control. Batch operations typically
require basic regulatory and logic control operating under sequential con-
trol; which in turn, is operating under basic recipe management in order
to achieve process automation. The complexity of control within a process
cell depends on the equipment available within the process cell, the inter-
connectivity among this equipment, the degree of freedom of movements
of batches through this equipment, and the arbitration of the use of this
equipment so that the equipment can be used most effectively [ISA, 1995].

The discussion about batch control systems and the progress in batch pro-
cess control has been hampered by the lack of a standard terminology. In
the last years, there have been three major initiatives with the aim to
provide a common language. The first major effort was an outgrowth of a
Purdue University workshop on batch control in the mid 1980s, [Williams,
1988]. The second was made by NAMUR, [NAMUR, 1992]. The third ma-
jor effort is sponsored by the Standards and Practices division of ISA
(Instrument Society of America), the International Society for Measure-
ment and Control, [ISA, 1995]. The standard is divided into two parts,
Part 1, called S88.01 deals with models, terminology and functionality.
This part of the standard was approved by the main committee of ISA
and ANSI in 1995. Part 2 will deal with data structures and language
guidelines. The ISA S88.01 standard has recently been accepted as an
international IEC (International Electrotechnical Commission) standard
IEC 61512-1, [IEC, 1997].

6.3 The Batch Standard ISA-S88.01

The first part of the ISA S88 standard describes batch control from two
different viewpoints: the process view and the equipment view, see Fig-
ure 6.1. The process view is represented by the process model and is
normally the view of the chemists. The equipment view is represented by
the physical model and is normally the view of the product engineer or
the process operator.

134
 6.3 The Batch Standard ISA-S88.01

Process General Site Master Control Equipment Physical

Model Recipe Recipe Recipe Recipe Control Model

Process Process Process Procedure Procedure Procedure Process

Cell

Process Process Process Unit Unit Equipment

Unit Unit
Stage Stage Stage Procedure Procedure Procedure

Process Process Process Operation Operation Equipment Equipment

Operation Operation Operation Operation Module

Process Process Process Phase Phase Equipment Control

Action Action Action Phase Module

Process Equipment
View Procedural Control View

Figure 6.1 Relations between ISA-S88 models and terminology.

Process Model
A batch process can be hierarchically subdivided as shown in Figure 6.1
(left).

The process consists of an ordered set, serial and/or parallel, of

process stages. A process stage is a part of a process that usually
operates independently from other process stages. It usually results
in a planned sequence of chemical or physical changes in the ma-
terial being processed. Typical process stages can be, e.g., drying or
polymerizations.
Each process stage consists of an ordered set of one or more process
operations. Process operations describe major processing activities.
It usually results in chemical or physical change in the material

135
Chapter 6. Batch Control Systems

being processed. A typical process operation is, e.g., react.

Each process operation can be subdivided into an ordered set of
one or more process actions that carry out the processing required
by the process operation. Process actions describe minor processing
activities that are combined to make up a process operation, Typical
process actions are, e.g., add reactant, and hold.

In the process model, the procedure for making a product does not consider
the actual equipment for performing the different process steps.

Physical Model
The physical model of S88 defines the hierarchical relationships between
the physical assets involved in batch manufacturing. The model has seven
levels, starting at the top with an enterprise, a site and an area. In Fig-
ure 6.1 (right) only the four lower levels are shown, with the following
interpretation:

A process cell contains one or more units.

A unit can carry out one or more major processing activities such
as react, crystallize or make a solution. Units operate relatively in-
dependently of each other. A unit is made up of equipment modules
and control modules.
An equipment module can carry out a finite number of minor pro-
cessing activities like weighting and dosing. It combines all neces-
sary physical processing and control equipment required to perform
those activities. Physically, an equipment module may be made up of
control modules and subordinate equipment modules. An equipment
module may be part of a unit or may be a stand-alone equipment
grouping within a process cell. It may be an exclusive use resource
or a shared resource.
A control module is typically a collection of sensors, actuators or
controllers. Physically, a control module can be made up of other
control modules.

Recipes
To actually manufacture a batch in a process cell the standard proposes
a gradually refinement of the process model based on four recipe types;
general recipe, site recipe, master recipe and control recipe. A recipe con-
tains administrative information, formula information, requirements on
the equipment needed, and the procedure that defines how the recipe
should be produced. The procedure is organized according to the procedu-
ral control model, see Chapter 6.3 (Procedural Control).

136
 6.3 The Batch Standard ISA-S88.01

General recipe
The general recipe is an enterprise level recipe that serves as a
basis for the other recipes. The general recipe is created without
specific knowledge of the process cell equipment that will be used to
manufacture the product.
Site recipe
The site recipe is specific to a particular site. The language in which
it is written, the units of measurements, and the raw materials are
adjusted to the site.
Master recipe
The master recipe is targeted to a specific process cell. A master
recipe is either derived from a general recipe or created as a stand-
alone entity by people that have all the information that otherwise
would have been included in the general or the site recipe.
Control recipe
The control recipe is originally a copy of the master recipe which
has been completed and/or modified with scheduling, operational
and equipment information. A control recipe can be viewed as an
instantiation of a master recipe.

The four recipes are gradually refined to the stage where all necessary
aspects for the execution of the recipe on a certain type of equipment are
taken into account. The general and site recipes are equipment indepen-
dent whereas the master and control recipes are equipment dependent. In
order to distinguish between equipment independent and equipment de-
pendent process steps different terminology is used. The terms Procedure,
Unit Procedure, Operation, and Phase are introduced for the equipment
dependent process steps, see Figure 6.1.

Procedural Control
The four recipe levels together with the equipment control constitute the
link between the process model and the physical model, denoted procedu-
ral control, see Figure 6.1. Procedural control is characteristic for batch
processes. It directs equipment-oriented actions to take place in an or-
dered sequence in order to carry out a process-oriented task.
The procedural structure is hierarchical, see Figure 6.2. A procedure can
gradually be broken down into smaller parts.

The procedure is the highest level in the hierarchy and defines the
strategy for accomplishing a major processing action such as making
a batch. It is defined in terms of unit procedures, and/or operations,

137
Chapter 6. Batch Control Systems

Procedure

Unit
Procedure

Operation

Phase

Figure 6.2 Procedure Control.

and/or phases. An example of a procedure is "Make a batch of prod-

uct A".
A unit procedure defines a set of related operations that causes a
production sequence to take place within a unit. Examples of unit
procedures are, e.g., polymerize, recover or dry. A unit procedure
must be executed within a single unit process.
An operation is a sequence of phases that defines a major processing
sequence that takes the material being processed from one state
to another. An operation usually involves a chemical or physical
change. Examples of operations are, e.g., reaction and preparation.
The smallest element that can accomplish a process oriented task
is a phase. It defines a product independent processing sequence. A
phase may be decomposed into steps and transitions according to
Grafcet/SFC. Examples of phases are, e.g., add catalyst.

The IEC 1131-3 standard, which was published in 1993, specifies program-
ming languages for controllers. This standard fills an important void since
part 1 of ISA-S88 does not specify languages for configuring the sequen-
tial and batch control functions. Many suppliers have however, already
incorporated the IEC 1131-3 standard in their products.
Sequential Function Charts (SFC) are gaining acceptance for configura-
tion of the procedural part of recipes. The main reasons for this are that

138
 6.3 The Batch Standard ISA-S88.01

SFC are graphical, easy to configure and easy to understand. SFC is also
the basis for Procedural Function Charts (PFC), a graphical language for
recipe representation currently being defined in the S88 working group.

Equipment Control
The control recipe itself does not contain enough information to operate a
process cell. On some level it must be linked to the process equipment con-
trol, i.e., the control actions that are associated with the different equip-
ment objects. S88 offers large flexibility with respect to at which level the
control recipe should reference the equipment control. It is also allowed
to omit one or more of the levels in the procedural model. The situation
is shown in Figure 6.3. The dashed levels could either be contained in the
control recipe or in the equipment control. Several examples of how this
can be done will be given in Chapter 8.

Control Recipe Equipment

Procedure Control

Recipe Procedure
Procedure

Unit
Procedure

Operation

Phase Equipment
Phase

Figure 6.3 Control recipe/ Equipment control separation.

Control Activity Model

To successfully manage batch production many control functions must be
implemented. The control activity model shown in Figure 6.4, identifies
the major batch control activities and the relationships amongst them.
This model was outlined in S88, and provides an overall perspective on
batch control.

139
Chapter 6. Batch Control Systems

Production Production
Recipe Planning and Information
Management Scheduling Management

Process
Management

Unit
Supervision

Process
Control

Outside the scope

Personnel and of S88
Environmental
Protection

Figure 6.4 The control activity model of ISA-S88.

The control activities shown relate to real needs in a batch manufacturing

environment.

Recipe Management
The need to have control functions that can manage general, site,
and master recipes implies a need for the recipe management control
activity.
Production Planning and Scheduling
Production of batches must occur within a planned time domain.
Production planning and scheduling is the control activity where
these control functions are implemented. Scheduling is discussed
further in Chapter 6.4.
Production Information Management
Various types of production information must be available and the

140
 6.4 Scheduling

collection and storage of batch histories is a necessity. The produc-

tion information management control activity in the model covers
these control functions.
Process Management
Control recipes must be generated, batches must be initiated and
supervised, unit activities require coordination and logs and reports
must be generated. These control functions fall under the process
management control activity.
Unit Supervision
The need to allocate resources, to supervise the execution of oper-
ation and phases, and to coordinate activities taking place at the
process control level are examples of control functions needed at the
unit supervision control activity level.
Process Control
The Process Control control activity discusses control functions that
deal directly with equipment actions.

6.4 Scheduling
Scheduling is a wide concept that can be broken down hierarchically,
[Fisher, 1990], see Figure 6.5.

Production
planning

Production
scheduling

Dynamic
scheduling

Resource
arbitration
and
allocation

Figure 6.5 The scheduling hierarchy.

141
Chapter 6. Batch Control Systems

At the highest level, scheduling is used to assign product orders to

the various manufacturing plants. At this planning level, the horizon
may be measured in weeks or month.
The order is sent to the production scheduling system in a plant.
Here, the inventories are checked against the production demands
and it is determined how much raw material that needs to be or-
dered. A master recipe is created. The production scheduler is run
once a day or once a week.
At the dynamic scheduling level, it is necessary that the schedule
more closely approximates real-time. Here, the horizon is measured
in shifts, hours or minutes. A detailed schedule based on the spe-
cific resources and requirements of the batch production system is
generated. The scheduling must be repeated if any activity is not
completed in time (delayed, ahead of time). It may also be neces-
sary to repeat the scheduling because of equipment malfunctions,
lack of raw materials, etc.
The resource arbitration system prevents a piece of equipment from
being used by more than one user at a time. The resource arbitration
system comes into play when it is necessary to decide which product
is the most deserving of access to a shared resource that is being
allocated by two resources at the same time. The resource allocation
system takes care of the allocation of resources. Here, a simple first-
come-first-served algorithm is not always sufficient.

Different scheduling techniques exist; linear programming, material re-

quirement planning, simulation, expert systems. However, most batch
plants are still scheduled using human made schedules.

6.5 Industry Practice

Many different commercial batch control systems exist today. They are
produced and utilized all around the world. Some examples are: FlexBatch
from GSE Systems, OpenBatch from PID Incorporate, VisualBatch from
Intellution, FoxBatch from Foxboro, InBatch from Wonderware, SattBatch
from Alfa Laval Automation, Advant from ABB Industrial Systems, etc.
The batch control system suppliers are well aware of the ISA S88 batch
control standard and their systems do, to greater or lesser extent, depend-
ing on the age of the system, comply with it. Even thought the different
systems have been developed at different independent companies they

142
 6.5 Industry Practice

all have, from an operator point of view, a common look-and-feel. This is

probably because of (or thanks to) the standard.

Recipe Structures
The recipe structure in all the different systems is composed of steps and
transitions. The steps are represented by rectangles and the transitions
are represented by horizontal bars or small rectangles, see Figure 6.6.

Step

Transition

Figure 6.6 Building blocks in commercial batch control systems.

The steps visualize the different tasks that should be performed when
producing a batch and the transitions represents a change of task. This
resembles the general ideas in Grafcet.
However, the steps and the transitions do not necessarily appear one after
the other. In most of the systems, a step may be connected to another step
and a transition may follow directly upon another transition. The reason
for this strange syntax is, according to the developers, that not all steps
and transitions in a Grafcet have a meaning. There are cases where the
step is only a dummy-step or the transition represents the-always-true-
condition; these steps and transitions can be omitted without loosing any
functionality. Some examples are given in Figure 6.7.
A recipe is always structured in such a way that the step that should
be activated when the recipe is initialized is placed in the top position
(uppermost position), and the recipe executes from the top position to the
bottom position, see Figure 6.8.

Recipe Execution
The execution of a recipe is normally color-coded. Even though the colors
are not fixed but can be chosen by the operator, the default setting is
always the same. The step(s) that is currently executing is green. The

143
Chapter 6. Batch Control Systems

a a
true b
c
b

Figure 6.7 A commercial batch recipe structure (left) and the corresponding
Grafcet structure (right).

step(s) that has been executed is red and a step that has been halted,
paused or is waiting for any other reason is yellow. The execution of the
recipe structure is thus not visualized by a token that moves around in
the net, like in Grafcet or Grafchart, but with different colors.
EXECUTION ORDER

Figure 6.8 Execution order; top to bottom.

144
 6.5 Industry Practice

Recipe Implementation
The recipes are implemented according to the hierarchical procedural
model. When a recipe is first displayed, each step represents a unit-
procedure. If a step, corresponding to a unit-procedure, is opened-up a
sequence of steps and transitions shows up, compare with macro-steps in
Grafcet. In this sequence the steps correspond to an operation. There is no
special syntax that indicates for the user that a step can be "opened-up".
All commercial systems support three hierarchical levels: unit-procedures,
operations, and phases. In almost all systems it is required that all lev-
els are implemented, even thought this is not required in the standard.
A step that represents a phase can not be opened. The phases are most
often implemented in a textual language.

Plant Status
Even though a single recipe can be represented graphically, the overall
status of the plant is always represented textually. Each recipe is named
by a tag name followed by some information about its status (run/hold/to-
be-started/completed). In Figure 6.9 an example of how the screen can
look for the user is given. In the upper left corner of the screen a textual
view of the plant status is shown. Five batches are under production.
One is completed, two are executing, one is halted and one is not yet
started. Next to the textual view of the plant a recipe structure is shown,
this corresponds to the procedure for the recipe named Recipe-D-001. The
first unit-procedure has executed while the second step is halted. This is
indicated with the colors of the respective step.

Recipes Status Recipe-D-001

procedure
Recipe-D-001 Executing
Recipe-D-002 Halted
Recipe-E-001 Completed
Recipe-D-003 Executing
Recipe-E-001 To-be-started

Figure 6.9 Textual view of the plant status (upper right corner).

145
Chapter 6. Batch Control Systems

The reason for having a textual representation is, according to the devel-
opers, that it would be to messy to display all recipes at the same time
on the screen. A textual overview is less space demanding and gives thus
a better overview. The user can select one or several of the recipes from
the list and display them graphically.

Resource Allocation
Associated with each recipe is a list of resource requirements. The user
can either specify a resource by directly type in the name of the desired
resource or by specifying a group of resources that are all equally good.
No commercial systems of today visualize the resource allocation.

It is possible for the user to specify when the required resource should
be allocated. Either all resources that are going to be used when produc-
ing a batch can be allocated immediately when the recipe is started or
the resources can be allocated one-by-one just before they are needed for
production. The first method is to prefer if the batch is very sensible and
valuable and therefore not should be exposed for a waiting-period. The
method guarantees that the batch will have the resources when needed.
In the second method, the allocation is done just before the resource is
needed. It might then happen that a resource is not available, it could, e.g.,
be allocated by another batch. In that case the batch either has to allocate
another resource or wait until the desired resource becomes available.

Using the first method, the risk of getting into a deadlock situation is re-
moved. On the other hand the resources are unavailable for other batches
for an unnecessary long period of time. Using the second method, the
operator must manually assure that the production does not run into a
deadlock situation. In no commercial system there is support for deadlock
detection.

Phase Implementation
The language chosen for the phase implementation differs from enterprise
to enterprise and depends on their type of PLCs.

The batch control system including the recipe system is sold by a batch
control system vendor. The vendor helps the enterprise to structure the
supervisory implementation of the recipes. However, the implementation
of the phases, i.e., the actual local equipment control, is done by the en-
terprise themselves.

Interlocks and safety assurances are most often taken care of within the
phase logic.

146
 6.6 Summary

Compliance to PLCs
Not all batch control systems are compliant with all PLC types. Certain
batch control systems require that the PLCs are of a certain type. Most
often the PLCs are required to be bought from the same vendor as the
batch control system. However, commercial batch control systems exist
that are PLC-type independent, e.g., OpenBatch from PID Incorporate
and InBatch from Wonderware.

Distributed Control Systems

The batch control system is implemented in a distributed control system.
A general problem is how data should be transfered from one node in
the system to another. Today many different solutions exist. The data
that should be transfered consist of both logged data and batch specific
information such as equipment requirements.

Remarks
The way a recipe is structured in commercial systems reminds of the
structure of Grafcet. Even though the similarities are obvious no explicit
connection exists. No batch system vendor has, as far as we know, expe-
rience or knowledge about the theory of Grafcet and/or Petri nets. The
similarities have occurred by mere accident. The many similarities do
however, confirm that the graphical syntax of Grafcet is very clear and
intuitive.

6.6 Summary
Industrial manufacturing and production processes can be classified as
continuous, discrete or batch. Traditionally the areas of continuous and
discrete processes have been the most research intensive areas. However,
increased demands on production flexibility, small scale production and
customer-driven production have led to an increased interest for batch
processes and batch control. A batch process is neither continuous nor
discrete, yet it has characteristics from both. A batch cell can be made
highly flexible, both with respect to the number of different products it
can produce and with respect to the structure of the plant. The multi-
product, network-structured batch cell is the most flexible but also the
most difficult type of plant to control. The recent batch control standard
ISA-S88.01, formally defines the terminology, models and functionality
of batch control systems. The standard mentions the possibility to use
Grafcet but only at the very lowest level of control. However, there is also

147
Chapter 6. Batch Control Systems

a need for a common representation format, complying with the standard,

at the recipe level.
Several different commercial batch control systems exist today. All sup-
pliers are well aware of the ISA S88 standard. The recipes are structured
according to the hierarchical procedural model. Steps and transitions are
used for visualizing tasks and the changing of tasks. The recipe struc-
ture reminds of a Grafcet structure, however, no formal links exists, the
similarities have occurred by mere accident. Most commercial batch sys-
tems of today lack a user-friendly way of presenting the overall status
of a plant, neither do the systems have an efficient way of handling the
resource allocation. These concerns are treated further in Chapter 8.7.

148
7
Batch Control Systems and
Grafchart

The aim of this thesis is to show various ways in which the concepts
of Grafchart can be used in the context of recipe-based batch control.
The aim is not to present a complete batch control system. As will be
shown Grafchart can be used at all levels in the hierarchical procedure
model, from the PLC level sequence control to the representation of entire
recipes. Grafchart also facilitates the linking that has to exist between the
control recipe procedural elements and the equipment control procedural
elements.
A batch scenario, consisting of one batch cell, has been defined and imple-
mented in G2. The batch scenario is used as a test platform to investigate
how Grafchart can be used in a batch control system.
This chapter starts with a presentation of related work. The common point
of the works presented, is that they are all based on Petri nets or Grafcet.
The chapter also contains a presentation of how Grafchart can be used in
a batch control system and, it contains a description of the defined batch
scenario.

7.1 Related Work

Batch processes receive increasing interest in industry as well as the

academic control community. This can be noticed by the increased number
of researchers in the field. The control of batch processes can be attacked
in various ways. In this section an overview of related work and activities,
all with Petri nets or Grafcet as a basis, is presented. The presentation
does not try to cover the field completely, other activities, not presented
in this section, but yet interesting, most likely exist.

149
Chapter 7. Batch Control Systems and Grafchart

By modeling batch plants and recipes mathematically and by applying

design methods to these models control laws can be generated. The gen-
erated control laws should ensure safe and correct operations. The PhD-
thesis by Tittus, [Tittus, 1995], proposes both models, frameworks and
design methods for this task.

The plant is modeled by a Petri net describing all physically possible

connections between the process units. Each process unit is modeled by
an individual PN presenting the state of this unit. The recipe for a batch,
is modeled by a PN describing all possible execution paths through the
plant. If more than one batch is to be produced at the same time, the
transitions of the Petri nets of all recipes are interleaved and one PN
describing all possible intermixings of the recipes is achieved. This net
is synchronized with that of the plant, forming the control recipe (Note:
the terminology is not the same as that of ISA-S88.01). The control recipe
is reduced to all physically possible intermixings of the recipes and the
plant by considering the fact that each resource can only be used by one
recipe at a time. Further reduction can be done by removing the places
and transitions that can lead to an unsafe or a deadlock situation. From
the reduced control recipe, a discrete supervisor, that guarantees correct
and parallel execution of the recipes, can be generated.

The work by Tittus differ from that in this thesis in that it is more fo-
cused upon formal verification and synthesis, see Chapter 1. The aim is to
generate a safe control recipe and no effort is put into the representation
or implementation of the recipes.

Wllhaf and Engell have developed an object-oriented tool for modeling

and simulation of the production process in a recipe-driven multipurpose
batch plant, [Engell and Wllhaf, 1994]. Models of the production plant,
the recipes and the batches of material are developed. Both continuous
and discrete aspects of the simulation are included in order to support the
supervision of the plant and the scheduling of production tasks. The work
follows the German NAMUR standard, [NAMUR, 1992], see Chapter 6.2.
The control recipe, represented with Sequential Function Charts, essen-
tially contains the discrete model which describes the production steps
and the transitions. The plant model together with the batches of mate-
rial, constitute the continuous system. By substituting the basic functions
of the recipe by the technical functions of the plant, a hybrid system, pos-
sible to use for simulations, is created.

The focus of the work by Wllhaf and Engell is modeling and simulation.
They focus upon the mathematical algorithms used to solve the differ-
ential and algebraic equations for simulation of the materials. A large

150
 7.2 Grafchart for Batch Control

database for physical and chemical properties of the most common sub-
stances is included in their tool. However, they do not focus upon the
recipe management system and the issue of making the recipes reusable
and flexible.

The aim of the work by Hanisch and Fleck is to join the theoretic work on
resource allocation problems with the need of such strategies in recipe-
control framework (recipe-based control systems), [Hanisch and Fleck,
1996]. They use high-level Petri nets to model both the recipe-based oper-
ations and the resource allocation strategy. The resource allocation module
is implemented separately within the process control system. The strategy
of the resource allocation module is to optimize the productivity. Simula-
tion of the system allows the control engineer to answer questions about
the utilization of resources, bottlenecks and resource dimensions.

Superbatch is a scheduling engine developed at Imperial College. Super-

batch matches the demand for products to available resources in order to
find what and how much that should be made and also when and where
it can be made. This task is done by the off-line planner in Superbatch.
Superbatch executes the off-line schedule by sending the appropriate com-
mands and parameters to a control system. However, a change in demand,
a variation in process yield or resource availability will cause the actual
production to deviate from the original schedule. Superbatch therefore
includes also an on-line monitor that updates the schedule to match the
current status of the plant. It alerts messages to advise of problems ahead
in plenty of time to take action. Superbatch was developed at the Center
for Process Systems Engineering at Imperial College.

Not many tools nor methods exist that allow verification of the recipe
before it is used for control. Hazardous processes exist and motivate the
need for such methods. The idea of the approach of Brettschneider, Gen-
rich and Hanisch, [Brettschmeider et al., 1996], is to model the recipe, the
plant and the device control (equipment control) by means of high-level
Petri nets. By merging the nets, verification and performance analysis
can be performed using the analysis methods of Petri nets.

7.2 Grafchart for Batch Control

The physical and procedural models of ISA-S88, as well as the different
recipe types, can all be nicely represented in Grafchart and the G2 envi-
ronment.

151
Chapter 7. Batch Control Systems and Grafchart

Physical Model
The physical model of ISA-S88 defines the hierarchical relationships be-
tween the physical units involved in batch control. Only the lower four
levels will be considered as shown in Figure 7.1 (left).

attribute of Process Cell Object

Process
Cell
aninstanceof

G2 object
Must contain

Unit Equipment Unit

Object

Attribute
Attribute

Attribute
May contain

Equipment
Module aninstanceof
aninstanceof
May
contain
G2 object G2 object
Equipment Module Equipment Module
May contain Object Object

Attribute
Attribute
Attribute
Attribute

Control
Module
May
contain

Figure 7.1 ISA-S88 Physical Model (left) and its G2 representation (right).

The hierarchical structure of the physical model is straightforward to im-

plement in an object-oriented environment such as G2. The attributes of
a G2 object can either be values (numbers, strings, or symbols) or other
objects. The latter case gives a hierarchical object structure that well
matches the physical model. A G2 object representing an equipment unit
may have attributes that contain other G2 objects representing the equip-
ment modules in the unit. The equipment modules may have attributes
containing the control modules and other equipment modules within the
module. The equipment unit object may itself be a part of an object rep-
resenting the batch cell. The situation is shown in Figure 7.1 (right).

Procedural Model
The procedural model of ISA-S88 is also hierarchical, see Chapter 6.3
(Procedural Control). The structure of the procedural model is shown in
Figure 7.2 (left).

152
 7.2 Grafchart for Batch Control

Function chart =
Procedure Procedure

Subworkspace
Subworkspace
consists of an
ordered set of

Macro Step
Unit procedure Unit Procedure Macro Step
Operation Macro Step
Phase
consists of an
ordered set of

Operation

consists of an Subworkspace
ordered set of

Phase Step

consists of an
ordered set of

Step

Figure 7.2 ISA-S88 Procedural Model (left) and its representation in Grafchart
(right).

The hierarchical levels of the procedural model can conveniently be de-

scribed with the hierarchical abstraction facilities of Grafchart. A pro-
cedure can be represented as a function chart composed of macro steps
representing the unit procedures. These macro steps may contain other
macro steps or procedure steps representing the operations. Similarly, the
macro steps representing the operations contain other macro steps repre-
senting the phases. Finally, the phase macro steps contain ordinary steps
with associated step actions. The situation in shown in Figure 7.2 (right).

Recipes
ISA-S88 defines four recipe types: general recipes, site recipes, master
recipes and control recipes. Here, only the master and control recipes are
considered. A recipe contains administrative information, formula infor-
mation, requirements on the equipment needed to produce the recipe and
the procedure that defines how the recipe should be produced. The proce-
dure is organized according to the procedural control model. The master
recipe is targeted to a process cell. Each individual batch is represented
by its control recipe. The control recipe is originally a copy of the master
recipe which has been completed and/or modified with scheduling, oper-
ational and equipment information. A control recipe can be viewed as an
instantiation of a master recipe.

153
Chapter 7. Batch Control Systems and Grafchart

With Grafchart, recipes can be represented using Grafchart-BV or using

Grafchart-HLV. Using Grafchart-BV, a recipe is represented as a func-
tion chart with parameters (attributes). The procedure part of the recipe
is represented by the function chart and the formula information and
equipment requirements are represented by parameters (attributes) of
the Grafchart process encapsulating the function chart. This information
can be accessed from the recipe procedure using the sup.attribute nota-
tion. This way of representing a recipe is shown in Figure 7.3.
Procedure

a Grafchart process
Equipment ...
Formula ...

Figure 7.3 Control recipe as a function chart.

Using Grafchart-HLV, a batch is represented as an object token. The ob-

ject token contains the formula information and equipment requirements
as attributes. The recipe procedure can be represented in two main ways.
In the first case it is represented by the function chart in which the to-
ken resides, see Figure 7.4 (left). In this case, the formula information
and equipment requirements can be accessed using the inv.attribute
notation or the temporary-tokenname notation. The recipe procedure can
also be represented by a Grafchart method belonging to the object to-
ken itself, see Figure 7.4 (right). The recipe procedure method can then
access the formula information and equipment requirements using the
self.attribute notation.

Recipe and Equipment Control Separation

The control recipe does not contain enough information to operate the
process cell. At some level it must be linked to the equipment control that
is responsible for the actual operation of the process equipment. The sep-
aration between the control recipe procedure and the equipment control
is illustrated in Figure 6.3. The dashed levels could either be contained
in the control recipe or in the equipment control. The linking could either
be done on the procedure level, unit procedure level, operation level, or
phase level.

154
 7.3 A Batch Scenario Implemented in G2

Procedure
an object token
an object token Equipment ...
Equipment ... Formula ...
Formula ... Procedure a Grafchart method

Figure 7.4 Control recipe as an object token without method (left) or with method
(right).

Using Grafchart the linking is implemented using methods and message

passing according to Figure 7.5. The element in the control recipe where
the linking should take place is represented by a procedure step. Depend-
ing on at which level the linking takes place, this procedure step could
represent a recipe procedure, recipe unit procedure, recipe operation or
recipe phase. This procedure step calls the corresponding equipment con-
trol element which is stored as a Grafchart method in the corresponding
equipment object. If the linking takes place at the unit procedure level
then the equipment control element corresponds to an equipment unit
procedure. If the linking is done at the operation level the equipment
control element is an equipment operation, etc.

7.3 A Batch Scenario Implemented in G2

A batch scenario consisting of one batch cell has been defined and imple-
mented in G2. The batch scenario is used as a test platform to investigate
how Grafchart can be used for recipe handling.
In the batch cell, different products can be made. The batch cell is struc-
tured as a network, which means that for each batch that will be produced
there are several possible ways through the plant. It is possible to have
several batches in the plant at the same time, the batches may be of the
same or of different types. The batch cell is thus of the multi-product,
network-structure type, see Chapter 6.
The cell consists of three raw material storage tanks, two mixers, three
buffers, two batch reactors, and three product storage tanks. The units are

155
Chapter 7. Batch Control Systems and Grafchart

Grafchart for representing

equipment sequence logic

Grafchart for representing

a reactor
the recipe procedure
name R1
charge a grafchart-method

CHARGE
Method call

Figure 7.5 Control recipe/Equipment Control linking.

interconnected through valve batteries. The cell can produce two products
named D and E using three reactants A, B and C. A schematic of the batch
cell is shown in Figure 7.6.

Figure 7.6 The batch cell.

156
 7.3 A Batch Scenario Implemented in G2

The scenario is divided into three major parts: a simulator that simulates
the dynamics of the scenario, a process control system and an operator
interface. Figure 7.7 shows the three parts of the batch cell.

Figure 7.7 The three parts of the batch scenario.

Unit Processes
The batch cell is composed of several unit processes.

Storage tanks The storage tanks contain the raw materials, i.e the
reactants. Since there are three different reactants there are three storage
tanks in the cell, one for each reactant. Each storage tank has a level-
transmitter and a temperature-transmitter. Each storage tank also has
an output on-off valve and pump connected to the outlet of the tank. The
storage tanks are assumed never to be empty. The schematic of a storage
tank is shown in Figure 7.8 (left).

Mixers The main task of a mixer is to mix different substances, but a

mixer can also be used to store substances while waiting for some other
unit. The mixer is equipped with an agitator. The mixer has two inlets,
each controlled by an on-off valve. In this way it is possible to fill the
mixer in parallel. The outflow of a mixer is controlled by a pump and
an on-off valve. The mixer has three transmitters: a level-transmitter, a
temperature-transmitter and a pressure-transmitter. In Figure 7.8 (mid-
dle) a mixer is shown.

157
Chapter 7. Batch Control Systems and Grafchart

Figure 7.8 A storage tank (left). A mixer (middle). A buffer (right).

Buffers The task of the buffer is to store substances and if necessary

maintain the temperature of the substance. A buffer can also be used
to heat or cool a substance. The inflow of the buffer is controlled by an
on-off valve and the outflow is controlled by a pump and an on-off valve.
As shown in Figure 7.8 (right) a buffer has a level and a temperature
transmitter. The temperature transmitter is connected to a PID-controller.
The PID-controller adjust the flow of hot or cold liquid to the heater of the
buffer and, thus, controls the temperature of the content of the buffer.

Reactors A reactor has two inlets and one outlet. It has an agitator
and four transmitters: level, temperature, pressure and flow. The outflow
is, as before, controlled by a pump and an on-off-valve. The inflow, and
thereby the level in the reactor, is controlled by control valves using a
PID-controller. A schematic of the reactor is given in Figure 7.9 (left).
The main task of the reactor is to perform chemical reactions. This is
done by heating or cooling the substance inside the reactor. The reactor
has a jacket which can be filled with a hot or cold liquid. The temperature
in the reactor is controlled by two cascade coupled PID-controllers that
adjust the flow through the jacket.

Product tanks The product tanks are used for storing the finished
products. They are assumed never to be full. Each product tank has an
inlet valve and a level transmitter. A schematic of a product tank is shown
in Figure 7.9 (right).

158
 7.3 A Batch Scenario Implemented in G2

Figure 7.9 A reactor (left). A product tank (right).

Valve-batteries Valve-batteries, see Figure 7.10, are placed in between

the different units. A valve battery is organized in a matrix structure with
n rows and m columns where n is the number of inlets and m is the number
of outlets. By opening the valve placed in position (i,j), inlet i will be
connected to outlet j.

Figure 7.10 A valve-battery.

159
Chapter 7. Batch Control Systems and Grafchart

Operator Interface
The operator interface, see Figure 7.6, provides the operator with a user
friendly interface, through which he or she can get information about the
status of the plant. Through the interface the operator can also interact
with the plant.
By clicking on any of the units the internal structure of this unit is shown.
The operator can open and close the valves manually by clicking on them.
The pumps can be turned on and off manually. Some of the units also
have PID-controllers, these can be operated manually or automatically.
When clicking on any of the sensors a trend-curve of the measured signal
is shown, see Figure 7.11.

Figure 7.11 The operator interface showing the internal structure of a mixer and
a trend curve.

As the batch moves through the plant, its actual position is highlighted.
A unit currently used by a batch is marked with a black dot placed at the
upper right corner. The level indicator of this unit shows the actual level
in the unit. If the batch is using a pipe, i.e. is on its way from one unit to
an other, this pipe is marked with a colour.

Dynamic Simulator
The dynamic simulator is used as a substitute for a real plant. It simu-
lates the mass balances, energy balances and the chemical reactions. All
simulations are done in real-time.

160
 7.3 A Batch Scenario Implemented in G2

Two reactions can be simulated in the scenario:

A+B 2D
C+D E

The total mass balance, the component mass balances and the energy bal-
ance for the reactions are calculated and simulated. A detailed description
of the dynamic simulator is found in Appendix D.

Process Control System

The process control system implements the basic control functions. It both
receives information from and sends information to the simulator. For ex-
ample, if the operator starts a pump this information must be propagated
to the simulator and the pump should be turned on. Similarly, information
about, e.g., the actual level in a unit should be sent from the simulator to
the process control system.
The process control system contains equipment objects (unit processes)
representing the units in the plant, i.e., the tanks, mixers, buffers and
reactors. The equipment objects have an internal structure of sensors,
actuators and PID-controllers. These correspond to the equipment and
control modules of ISA-S88. These objects are stored as attributes of the
unit process objects, see Figure 7.12.

Figure 7.12 The process control system with its equipment objects and their in-
ternal structure.

161
Chapter 7. Batch Control Systems and Grafchart

To each unit process a number of methods are associated. These methods

are descriptions of the operations or phases that the unit can perform, i.e.,
the methods are detailed descriptions of how to perform a certain task on
one particular unit. The names of the methods are found in the attribute
table of each object whereas the implementation of the different methods
are found on the subworkspace of the class definition it belongs to. A
mixer can, e.g., perform the following tasks: charge, agitate and discharge
as shown in Figure 7.13. The methods are implemented as Grafchart
methods.

Figure 7.13 The methods of the class mixer-process.

Recipes
Two reactions can be simulated in the scenario:

A+ B 2D
C+D E

Recipe A + B 2D : First the same amount of the two reactants

are filled into a mixer. The filling can be done either in parallel or in
sequence. When the filling is completed the agitation is started. When
the two reactants are well mixed the content of the mixer is transfered
into a reactor. In the reactor the reaction takes place. This reaction needs
to be heated for the reaction to start. Finally the reactor is emptied and
the substance is stored in a product-tank.

162
 7.4 Summary

Recipe C + D E : The production of substance E can be done in

either of two ways. Both start with producing substance D as described
above.

Substance D is transported from the reactor to a buffer and then

reactant C is added. The content of the buffer is emptied into a
reactor and the reaction is started by heating the content. When
the reaction is completed the reactor is emptied and the product is
stored in a product-tank.
Reactant C is filled into a buffer and heated to the same temperature
as substance D at the same time as product D is being produced.
Then the content of the buffer is transfered to the reactor and the
two substances are agitated, and, if needed, further heated. When
the reaction is completed, the product, i.e., substance E, is stored in
a product-tank.

7.4 Summary

An object oriented language is well suited to represent the hierarchical

structure of the physical model. Grafchart can be used to represent all
the levels in the hierarchical procedural control model and, by using the
support for methods and message passing, the linking between the control
recipe procedural elements and the equipment procedural elements can
be nicely represented.

163
8
Recipe Structuring using
Grafchart

The main application of Grafchart is recipe structuring and resource man-

agement in multi-product, network-structured batch production cells. A
number of different ways of how to structure the recipes and how to in-
corporate resource allocation have been investigated.

Grafchart is used at two levels, to represent the sequential structure in the

recipes, i.e., the step by step instructions of how to go from raw material
to product, and to represent the sequential control logic contained in the
equipment units. To link the two parts together, method calls are used,
as discussed in Chapter 7.2 (Recipe and Equipment Control Separation).

In this chapter, four alternative representations of recipe structures are

presented. The structuring alternatives have large differences and they
therefore have different advantages and disadvantages. Each major struc-
turing alternative is presented in a separate section. Drawbacks and ad-
vantages are presented for each alternative. The first structuring alter-
natives, Chapter 8.1, use the basic version of Grafchart whereas the re-
minding alternatives, Chapter 8.2, 8.3, and 8.4, use the high-level version
of Grafchart.

In all structuring alternatives, a batch can be followed through the plant

and it is possible to record its history in logs. This has, however, not yet
been fully implemented and is therefore not described.

As a common example, the simple recipe for producing product D, see

Chapter 7.3, will be used. The production is assumed to be performed in
the process cell described in Chapter 7.3.

164
 8.1 Control Recipes as Grafchart Function Charts

8.1 Control Recipes as Grafchart Function Charts

The alternatives given in this section use the basic version of Grafchart.
In this alternative, a master recipe is represented by a Grafchart process.
The Grafchart process has attributes specifying the type of equipment
needed when producing the batch. The control recipe is a copy of the
master recipe where the attributes are given their actual values, i.e., the
equipment that will be used is specified. The situation is shown in Figure
8.1 .

Master recipe Control recipe

Instance

a Grafchart process a Grafchart process

name Recipe1 name Recipe1

mixer mixer M1
reactor reactor R1
size size 0.7
batchid batchid a412

Figure 8.1 Master and control recipes.

From the steps and transitions within the control recipe the attributes
can be referenced using the sup notation, see Chapter 5.3.

Recipes Based on Recipe Phases

In the first example the control recipe procedure consists solely of phases.
Each phase references the associated equipment phase through a method
call according to Figure 8.2.

Control Recipe Equipment

Procedure Control

Recipe
Procedure

Recipe Equipment
Phase Phase
References
(method call)

Equipment
Equipment
Step
Phase

Figure 8.2 Recipes based on recipe phases.

165
Chapter 8. Recipe Structuring using Grafchart

The resulting control recipe is shown in Figure 8.3. The different unit pro-
cesses that the batch passes through are indicated by the column-based
organization of the recipe. The recipe starts by an assignment step in
which the resources necessary to produce the recipe are allocated. Two
versions of the recipe have been implemented. One where the operator
manually assigns all the equipment before starting the procedure and one
where the equipment is assigned automatically through a simple search
algorithm immediately before the equipment is needed. After the assign-
ment step the two reactants A and B are filled into a mixer. This is done in
parallel, since the mixers have two inlets. Then the agitation is started.
When the agitation is finished the mixer is emptied and at the same time

a transition
Event
Condition true

Figure 8.3 Control recipe based on recipe phases.

166
 8.1 Control Recipes as Grafchart Function Charts

the reactor is charged. This is expressed with the Grafchart parallel con-
struct. When the charging is finished, the reaction is started by heating
the batch. Finally, the content of the reactor is transfered to the product
tank and the production of the batch is completed.

Each recipe phase is represented by a procedure step that calls the cor-
responding equipment phase. In Figure 8.3 the attribute table for the
agitate step is shown. The procedure step calls the agitate methods in
the mixer that has been assigned to the batch. This mixer is contained in
the mixer attribute of the recipe. The parameter time is given the value
1. This denotes how long the agitation will take. The agitate equipment
phase consists of two steps where the agitator motor is active until the
defined time has elapsed. The situation is shown in Figure 8.4.

PROCESS CONTROL SYSTEM

MIXING REACTION STORAGE

SB SC
SA
Assignment
a procedure-step
Parameters "time 1"
Fill-A Fill-B
Procedure "sup.mixer agitate"
M1 M2

Agitate Calling the agitate method

of mixer M1
Empty M1_A GITA TE
Charge B2 B3
B1

Heat

R1 R2
Discharge Charge

P1 P2 P3

Figure 8.4 Recipe - Equipment linking.

Between the procedure steps in a recipe, transitions are placed. The equip-
ment phases called by the procedure steps are most often written so that
they themselves take care of the initialization and the termination of the
phase. This means that the receptivity of a transition placed between two
procedure steps becomes very simple. In Figure 8.3, the transition recep-
tivity of the transition following the heat step is shown. As can be seen
this receptivity only contains an always-true condition.

167
Chapter 8. Recipe Structuring using Grafchart

Recipes Based on Recipe Operations

In the second recipe structuring alternative the control recipe is struc-
tured into operations that internally are decomposed into recipe phases.
The linking between the control recipe and the equipment control still
takes place at the phase level. The structure is shown in Figure 8.5.

Control Recipe Equipment

Procedure Control

Recipe
Procedure

Recipe
Operation

Recipe Equipment
Phase Phase
References
(method call)

Equipment
Equipment
Step
Phase

Figure 8.5 Recipes based on recipe operations.

The resulting control recipe is shown in Figure 8.6. The control recipe
is a straight sequence of recipe operations. Each recipe operation is rep-
resented as a macro step that contains the recipe phases. The phases
are represented as procedure steps that call the corresponding equipment
phases.

A problem with this approach is how to handle the parallelism between

the operations. The emptying of the mixer and the charging of the reactor
should be performed in parallel. Here this is solved using process steps.
The Empty phase of the mixer operation is started through a process step,
i.e., as a separate execution thread. The result will be that the Empty
phase will execute at the same time as the Charge phase of the reaction
operation. A drawback with this approach is that the parallelism is not ex-
pressed explicitly with the Grafchart constructs and therefore not directly
visible to the operator as in the previous example. The recipe structure
in Figure 8.6 could also be used if the linking was done at the operation
level. In that case the equipment operations are internally structured as
equipment phases.

168
 8.1 Control Recipes as Grafchart Function Charts

Figure 8.6 Control recipe based on recipe operations.

Recipes Based on Equipment Operations

In the third example the control recipe and the equipment control are
linked at the operation level according to Figure 8.7.

In the previous examples, the control recipe has explicit information about
which type of unit processes that the batch should be processed in, e.g., a
mixer, buffer or reactor. Another possibility is to let the control recipe be
completely independent from which unit type it should use. This can be
achieved by defining a number of generic equipment independent opera-
tions. Examples of generic operations could be store, store-with-agitation,
mix, mix-with-agitation, store-under-heating, exothermal-reaction etc. It
is possible to mix two reactants in both mixers, buffers and reactors. How-
ever, it is preferred to mix reactants in a mixer. The mix-with-agitation
operation cannot be performed in a buffer. The store-under-heating oper-
ation can be performed in both buffers and reactors but it is preferred to
use the buffers for this. Hence, for each generic operation a preference
ordering must be given. It is the task of the resource allocation scheme to
find the best suited unit processes for each recipe operation and to assign
this to the recipe when it is needed. The equipment operations are repre-
sented as equipment object methods. These methods call the equipment
phases which also are methods of the equipment objects. This structure
has not been implemented and tested in the batch scenario.

169
Chapter 8. Recipe Structuring using Grafchart

Control Recipe Equipment

Procedure Control

Recipe
Procedure

Recipe Equipment
Operation Operation
References
(method call)

Equipment
Phase

Equipment
Equipment
Step
Phase

Figure 8.7 Recipes based on equipment operations.

Advantages and Disadvantages

Structuring a recipe management system with control recipes represented
by Grafchart function charts, has advantages and drawbacks. The main
advantage is that the system is easy to comprehend, one batch equals one
Grafchart process. Each control recipe, i.e., each Grafchart process, can
be modified independently of the other control recipes simply by chang-
ing the parameters of the procedure steps or by changing the function
chart. However, the drawback is that it is not easy to get simultaneous
information about all batches being produced in the cell.

8.2 Control Recipes as Object Tokens

The recipe structuring alternatives presented in this section use the high-
level version of Grafchart.
In the previous section, one copy of the master recipe was needed for
each batch that was produced. The reason for this is not that the batches
are produced in different ways or that they use different types of equip-
ment, but that they do not necessarily use the same equipment or have
the same batch-identity number. Since the attributes, in the last section,
were global in the context of the function chart, the same control recipe
cannot be used simultaneously by more than one batch. If, however, the

170
 8.2 Control Recipes as Object Tokens

batch specific information is stored locally, e.g., in the tokens, the same
function chart can be used by more than one batch. Information that the
batches share is represented globally, whereas batch specific information
is represented locally. Since the token contains the batch specific informa-
tion, the token represents the control recipe and the function chart that
the token resides in is the common master recipe. This way of structuring
a recipe is shown in Figure 8.8.

Master recipe

Control recipe

a token

name Recipe1
mixer M1
reactor R1
size 0.7
batchid a412

Figure 8.8 Control recipes as tokens.

The recipe alternatives presented in this section are all based on recipe
phases and each phase calls the associated equipment phase through a
method call. It is also possible to build up the recipe using operations
instead of phases, in the same way as described in Chapter 8.1 (Recipes
Based on Recipe Operations).

The recipe shown in Figure 8.3 can be structured with object tokens. The
attributes previously contained in the control recipe function chart will
now be contained in the tokens. It is possible to have several tokens in
the same master recipe. Each token corresponds to one control recipe, i.e.,
one batch.

Recipes Extended with Explicit Resource Allocation

Using the object token structuring possibility it is possible to combine
resource allocation with recipe execution in a Petri net fashion, see Figure
8.9.

In the recipe two batches are under production. One batch is currently
filling reactant A and reactant B in one of the mixers and the other is
heating the content in one of the reactors. At the moment there is thus
only one mixer (out of two) and one reactor (out of two) reserved by a
batch.

171
Chapter 8. Recipe Structuring using Grafchart

Figure 8.9 Master recipe with resource allocation.

In this approach an available equipment unit is represented as a token

residing in a step. The token corresponds to a semaphore that guarantees
a batch exclusive access to the resource (equipment unit). PN-transitions
with multiple input and output arcs are used to express the resource
synchronization. If a batch has specific resource requirements, these can
be expressed and checked against the equipment capacity in the transition
receptivity.

172
 8.2 Control Recipes as Object Tokens

The chart can also be extended with more equipment oriented operations
such as cleaning (CIP - clean in place). In Figure 8.10 an extremely simple
master recipe is shown. Here, a CIP-operation must be performed on each
unit after it has been used by a batch.

CIP

Master recipe

Free
mixers

Control recipes "batches"

Figure 8.10 A master recipe with combined equipment oriented operations.

Combined Network
Using the object token structuring possibility combined with resource al-
location it is possible to merge all different master recipes into one single
Grafchart. This chart visualizes the resources sharing that exists between
the batches. The chart can be analyzed with Petri nets analysis methods
to detect if there is a risk for deadlock. The case for two simple master
recipes is shown in Figure 8.11.

Master recipe A Master recipe B

Free
mixers

Free
reactors

Figure 8.11 Combined net with all master recipes.

173
Chapter 8. Recipe Structuring using Grafchart

The combined network of the two recipes A + B 2D and C + D E,

see Chapter 7.3, is shown in Figure 8.12. The recipe A + B 2D is
represented to the left in the figure and the more complex recipe, C +
D E is represented to the left. The resources needed are shown in the
center of the figure. The tokens representing mixers reside in the upper
step, the tokens representing the buffers in the mid-step and the tokens
representing the reactors in the bottom-step. The buffers are only used
by the recipe C + D E. This net is large and complex and therefore not
suitable for representation.

coloured-recipe-D
coloured-recipe-E
resource allocation
M4B-T1
MIXING REACTION BUFFER STORAGE

M4B-T1A M4B-T1B

New
M4B-S3 batch Create mixers New batch
M4B-S1

Assignment
M4B-T2

Fill-A Fill-B
Create buffers

Agitate
M4B-T3

Create reactors
Assignment

Empty Charge

Deassignment

M4B-T4B

M4B-T4A
Heat

Assignment

Discharge Fill-D

M4B-T5A

Deassignment
M4B-T5B

Fill-C

Assignment

Charge Discharge

Deassignment

M4B-T6B

Heat

Discharge Charge

Deassignment

M4B-T7B

Figure 8.12 Combined net with all master recipes.

A combined net can however be represented in a more attractive way by

using connection posts. Each master recipe function chart is represented
separately. The different function charts are connected through connection
posts, see Figure 8.13.

174
 8.3 Multi-dimensional Recipes

Master recipe A Resources Master recipe B

CP2

Free
CP1 mixers CP1

CP1 CP1
CP4

Free
CP5 buffers CP3
CP5
CP3

CP6

CP6 Free
reactors CP6
CP4
CP5 CP5

CP2

CP2

Figure 8.13 Combined net with all master recipes using connection posts.

Advantages and Disadvantages

The structuring alternative presented in this section gives a more compact
representation compared with the structuring alternative given in Chap-
ter 8.1. It makes it easy to see how many batches of a certain type that
are under production. The recipes have been structured using phases. It
can however also be structured using operations, in the same way as in
Chapter 8.1. If the master recipe function chart is changed this will affect
all control recipes. This can be both an advantage and a disadvantage.
A drawback is that it is not possible to modify the procedure of one con-
trol recipe alone. This can however be resolved by using one Grafchart
function chart for each batch, according to Chapter 8.1, together with
connection posts. This situation is shown in Figure 8.14.

8.3 Multi-dimensional Recipes

The multi-dimensional feature of Grafchart fits nicely into the batch con-
trol problem. In the first recipe structuring alternative, Chapter 8.1, only
one token, representing one batch, could reside in one chart. In the sec-
ond recipe structuring alternative, Chapter 8.2, several tokens, each rep-
resenting one batch, could reside in a chart, provided they were all of
the same type. The tokens shared the structure of the master recipe but
contained specific information about the equipment to use when being

175
Chapter 8. Recipe Structuring using Grafchart

Master recipe A Master recipe B

Free
mixers

Free
reactors

Figure 8.14 Combined net with all master recipes using connection posts.

produced. Another, more sophisticated structuring alternative is to let

the token contain, not only information about the equipment but also a
method describing how it is produced. The chart in which the tokens re-
side now becomes more general and allows for tokens of different types
to reside in the same chart. The idea is shown in Figure 8.15

a Recipe_A

name batch 123

x 5
proc a grafchart
method

a Recipe_B

name batch 326

Methods describing how
z true to produce the batch
proc a grafchart
method

a Recipe_A

name batch 583

x 5
proc a grafchart
method

Figure 8.15 A multi-dimensional chart.

176
 8.3 Multi-dimensional Recipes

Multi-dimensional Recipes with Implicit Resource Allocation

The first multi-dimensional recipe is shown in Figure 8.16. The function
chart of the base-level of the multi-dimensional recipe is very general
and applies to all batches, independently of their type. In Figure 8.16,
this chart consists of one initial step, two steps and one procedure step.
The tokens in the initial step can represent the orders effected to the
plant. The step following the initial step contains initializational tasks
that have to be performed before the production can start. The batches
currently under production reside in the procedure step and the finished
batches in the last step.

a recipe-token
Procedure a grafchart-method
Size 2
New recipe-A

New recipe-B

a recipe-a
Mixer m1
Initialization Buffer none
Reactor none
MIXING REACTION STORAGE
Size 2
Production Batch id a415
Assignment
Token class "recipe-token"

Parameters "size inv.size" Fill-A Fill-B

Procedure "inv procedure"

Agitate

Assignment
Batch ready

Empty
Charge

Heat

Discharge Charge

Figure 8.16 Multi-dimensional chart with implicit resource allocation.

177
Chapter 8. Recipe Structuring using Grafchart

When a token enters the procedure step a call is performed and a method
of the token is started. This method describes how this specific batch
should be produced and constitutes a part of the second level in the multi-
dimensional recipe. The method is implemented as a Grafchart procedure,
see Chapter 5.5. The attributes of the Grafchart procedure contain the
equipment specification of the batch. The different levels of the multi-
dimensional chart communicate through the different dot notations, see
Chapter 5.5 (Multi-dimensional Charts).
Each control recipe, i.e., each token, is represented by an object token and
visualized by a grafchart marker. When a new batch is to be produced a
new control recipe object token is created and a grafchart marker of the
correct type is placed in the initial-step of the function chart. A master
recipe is represented as an object token with attributes and a method. A
control recipe object token is created by copying the master recipe object
token.
The resource allocation of this recipe structuring alternative is done im-
plicitly. Immediately before an equipment is needed a simple search algo-
rithm is executed and the correct equipment is automatically assigned to
the batch.

Multi-dimensional Recipes with Explicit Resource Allocation

In this structuring alternative the resource allocation is explicitly rep-
resented. The function chart of the base-level contains an initial-step, a
process step, two circular path (one for the batch and one for the equip-
ments) and a final step, see Figure 8.17.
After initialization of a new batch, which is done in the initial step, the
production of the batch is started. This is done in the process step, from
which the method of the token is called. The method represents the recipe
procedure. A multi-dimensional structure of the chart is now achieved.
When the call has been performed the token directly moves to the next
step. It enters a circular path where it sequentially requests resources
and continues its recipe execution in that resource. The token does not
leave the circular path until the execution of the batch has reached its
end, i.e., until the batch is ready.
The resources (equipment units) in the plant are also represented by
tokens. These tokens are included in another circular path, describing
the state of the resources. A resource can either be available, occupied by
a batch or in cleaning mode (CIP). A batch requiring a resource can only
reserve a resource if the resource is available. If the resource required by
the batch is not available the batch has to wait until it becomes available.

178
 8.3 Multi-dimensional Recipes

New recipe-A

New recipe-B

Spawns recipe
procedure CIP

Waits for Available

resource resources

Occupied
Executes
resources
recipe

Resource Batch ready

needed

Figure 8.17 Multidimensional chart with explicit resource allocation.

When a batch releases a resource, the resource has to be cleaned (CIP)

before it can be utilized again by another batch.

Advantages and Disadvantages

The recipe structures presented in this section are more intricate, and
maybe harder to understand at a first glance, than those previously pre-
sented. However, the structures have advantages that the previously ones
do not have. All types of control recipe tokens are allowed to circulate in
the base-level function chart, and as a consequence of this only one chart is
needed for a production cell. The base-level function chart gives complete
information about: (1) the number of ordered batches, (2) the number of
batches in production, (3) the ready produced batches and, (4) the status
of the equipment units. If more specific information about a particular
batch is required, this can easily be obtained since the information is well
structured and placed within the token. This structuring alternative gives
a compact graphical overview of the plant status.

179
Chapter 8. Recipe Structuring using Grafchart

8.4 Process Cell Structured Recipes

An alternative to the previous solutions is to represent the process units
as steps instead of tokens. This gives a resource allocation chart that
resembles the physical structure of the process cell. In Figure 8.18 the
chart for a simplified process cell, consisting of one mixer, two buffers and
two reactors, is shown.

Mixer
M1

Buffer Buffer
B1 B2

Reactor Reactor
R1 R2

Figure 8.18 Process cell structured recipe.

Each batch is represented as a control recipe token that moves around

in the resource allocation chart. The presence of a control recipe token
in an equipment step indicates that the recipe is executing an operation
in that unit process. Using this approach there are two unclear areas:
How should the resource allocation be done and how should parallelism
between operations performed in different units be handled.

The resource allocation task can be treated in different ways. In Fig-

ure 8.18, the resource allocation mechanism is hidden in the transitions
between the equipment steps. In the chart it is assumed that there can be
at most one token in each step. In the Petri net field such net structures
are refered to as maximum-capacity nets. The net structure obtained is
very similar to the Petri net structures used for analyzing batch control
cells in [Genrich et al., 1994], [Yamalidou and Kantor, 1991]. The differ-
ence is that here the resource allocation is integrated with recipe execution
through the multi-dimensional chart nature.

180
 8.4 Process Cell Structured Recipes

If the maximum-capacity constraint on each process unit should be visu-

alized, each process unit must be represented by two steps. The two steps
correspond to the two possible states that a resource can be in: allocated
and not-allocated. When a batch needs to allocate a resource, e.g., a reac-
tor, there must be a token in step named free-reactor. If there is none,
the resource can not be allocated. This solution is shown in Figure 8.19. A
drawback with this approach is that the resource allocation chart becomes
large and less resembles the real plant structure. However, using this ap-
proach it is easy to extend the chart with equipment oriented operations,
e.g., a CIP-operation.

Free
Reactor
Reactor

Figure 8.19 A part of a process cell structured recipe.

In order to decrease the size of the net macro steps can be used to en-
capsulate the extra states. An example of this is shown in Figure 8.20.
This representation can, however, be confusing, since the token is placed
in the resource-macrostep before the resource is allocated.

Mixer

Free
Reactor
Reactor
Reactor

CIP

Figure 8.20 Process cell structured recipe with macro steps.

181
Chapter 8. Recipe Structuring using Grafchart

The problem of how to handle parallelism between operations performed

in different units can be solved in different ways. Assume a scenario
where, e.g., the emptying of a mixer is done in parallel with the charg-
ing of a reactor. One trivial solution could be to have one token placed
in each of the units that are allocated by a batch, i.e., one token placed
in the mixer and one token placed in the reactor. This solution requires
that the transition connecting the mixer-step with the reactor-step has
two receptivities. The first receptivity becomes true when the charging of
the reactor is started. The firing implies that a new token is created and
placed in the reactor-step. The second receptivity becomes true when
the emptying of the mixer is finished. The firing implies that the token
placed in the mixer-step is deleted. In this way, all units that are used
by a batch are clearly marked. However, the user cannot find out how
many batches that are under production simply by counting the tokens.
It can also be hard to see which of the tokens that refer to the same batch.

Another solution could be the following. When the emptying/charging

is started, the token placed in the mixer step is transformed into a real
number, e.g., the number 1.0 indicating that all of the content is contained
in the mixer. At the same time the number 0.0 is placed in the reactor
indicating that nothing of the content is in the reactor. As the mixer
is emptied the token number of the mixer is decreased and the token
number in the reactor is increased. When the mixer is empty, i.e., the
number equals 0.0, and all of the content is in the reactor the number
of the mixer is deleted and the number in the reactor, which is equal to
1.0, is transformed in to a black dot again. Such a sequence is shown in
Figure 8.21.

In the Petri net field, nets with tokens as real numbers are known as
continuous Petri nets, see Chapter 2.6.

Mixer 1.0 Mixer 0.3 Mixer 0.0 Mixer Mixer

Reactor 0.0 Reactor 0.7 Reactor 1.0 Reactor Reactor

Figure 8.21 Visualization of parallel operations in different units.

182
 8.4 Process Cell Structured Recipes

The process cell structured recipe easily becomes complex if there are
many resources in the plant. This is due to the fact that between every
two units there is a transition. In the process plant shown in Figure 7.6
each mixer is connected to three buffers and two reactors. This means
that there should be five transitions following each mixer-step. In order
to improve the situation, a transition-battery can be introduced. The task
of the transition-battery can be compared to the one of the valve-battery,
see Figure 7.10, i.e., to give a more compact visualization. A resource allo-
cation chart structured with transition batteries is shown in Figure 8.22.

ST1 ST2 ST3

TB1

M1 M2

TB2

B1 B2 B3

TB3

R1 R2

TB4

PT1 PT2 PT3

Figure 8.22 Resource allocation chart structured with transition batteries.

In the resource allocation chart there are four transition batteries, TB1,
TB2, TB3 and TB4. The four transition batteries are shown in Figure 8.23.

Advantages and Disadvantages

The recipe structure presented in this section focuses more upon the pro-
cess cell then on the recipe itself. Having a recipe that mimics the configu-
ration can be an advantage since it is very easy to see which units that are
currently being used. However, in order for the recipe to mimic the pro-
cess cell, the Petri net concept of maximum-capacity nets has to be used.
Alternatively, a resource-macrostep or a transition-battery have to be
introduced. A difficulty with the approach is how to visualize parallelism
between operations performed in different units.

183
Chapter 8. Recipe Structuring using Grafchart

TB1: Transition Battery 1 TB2: Transition Battery 2

ST1 ST2 ST3 M1 B1 R1 B2 R2 B3 M2

. . M1 . . B1

. . B1 . . R1

. . R1 . . B2

. . B2 . . R2

. . R2 . . B3

. . B3

. . M2

TB3: Transition Battery 3 TB4: Transition Battery 4

B1 R1 B2 R2 B3 R1 R2

.. . R1
. PT1

. . . R2 . PT2

. PT3

Figure 8.23 Four transition batteries.

8.5 Resource Allocation

Resource allocation is an important part in a recipe management system.

If the resource allocation is not done in a correct way batches can get
mixed, e.g., if a buffer is allocated to more than one batch their contents
will be mixed. This will lead to a costly loss of product. Improper handle
of exclusive-use common resources, such as the process units, might also
lead to a deadlock situation, i.e., a situation were two or more processes
are waiting indefinitely for an event that can be caused only by one of the
waiting processes.

The resource allocation problem is treated in two main ways: implicitly

and explicitly. In the implicit way, the resources are not represented by
any token, instead the allocation is hidden in the actions of a step. This
is the case of the structures presented in Chapter 8.1 (Recipes Based
on Recipe Phases) (Recipes Based on Recipe Operations), Chapter 8.2
(Recipes with Several Tokens), and Chapter 8.3 (Multi-dimensional Reci-
pes with Implicit Resource Allocation). There are two versions of the im-
plicit resource allocation. The first and most basic version is to let the
operator prespecify, before starting the recipe execution, all the equip-

184
 8.5 Resource Allocation

ment that the batch will use. If the specified resource is not available
when needed, the recipe execution will pause and wait until it becomes
available. In the second version of implicit resource allocation, the re-
sources are automatically allocated. A simple search algorithm looks for
an available resource of the correct type, and, if found, allocates it to the
recipe.
In explicit resource allocation, resource tokens are used to represent the
resources, i.e., the state of the resources in the plant are graphically pre-
sented for the user. This is the case of the structures in Chapter 8.2
(Recipes Extended with Resource Allocation) (Combined Network), and
Chapter 8.3 (Multi-dimensional Recipes with Explicit Resource Alloca-
tion).
Resource allocation of exclusive-use resources and deadlock analysis have
been looked at in other areas and their results might be useful also for
a recipe management system in the batch control field. This is discussed
further in Chapter 9.

Semaphores
In real-time programming the concept of semaphores are used to obtain
mutual exclusion, [Dijkstra, 1968]. A semaphore is a flag indicating if a
resource is available or not. If a process requests a non-available resource
it is placed in a queue. The processes have different priorities and the
queue is priority-sorted. When the requested resource is released the first
process in the queue can allocate it. For further reading about semaphores
see [Burns and Wellings, 1996].
The resource token in the recipe structures with explicit resource alloca-
tion can be compared to a semaphore. The fact that different recipes could
be given different priorities and that they could be put in a waiting queue
is relevant also for batch processes. One way of approaching this would be
to introduce special FIFO-steps that maintain a queue of tokens. In Fig-
ure 8.24 a small example of a system with mutually exclusive resources
is shown.

Shared Resources
The semaphore construct can also be used for shared resources, i.e., re-
sources that can be used by maximum n simultaneous users. A situation
like this can be implemented in Grafchart. Each sharable resource is rep-
resented by as many tokens as its maximum usage limit, see Figure 8.25.
Sharable resources might also have real-value capacity constraints. This
can be implemented in Grafchart, according to Figure 8.26.

185
Chapter 8. Recipe Structuring using Grafchart

3 reactors

Figure 8.24 A Grafchart structure representing three mutually exclusive re-

sources.

Max. 3 simultaneous
users of e.g.,
the steam system

Figure 8.25 A Grafchart structure representing a limited sharable resource.

Situations were the resource has to fulfill certain constraints, e.g., the
resource has to have a volume not less than a certain value, can be imple-
mented in Grafchart using the same structure as in Figure 8.26 extended
with a receptivity checking the constraint.

Other Approaches
An algorithm commonly used for resource allocation in real-time systems
is Banker's algorithm, [Silberschatz and Galvin, 1995]. This algorithm
is discussed in Chapter 9.7.
A Petri net can formally be analyzed with respect to deadlocks, using the
analysis methods described in Appendix B. Petri net analysis of batch
recipes is further treated in Chapter 9.

8.6 Distributed Execution

The recipe alternatives proposed implicitly assumes a centralized exe-
cution environment where the recipe execution and the equipment con-
trollers all reside within the same computer. In an industrial batch control
system this is very seldom the case. Instead, a distributed environment is

186
 8.6 Distributed Execution

Need Capacity

2
1

b: batch;
r: resource
If b.need <= r.capacity
then
move(b,1);
r.capacity = r.capacity b.need;
move(r,2);

Figure 8.26 A Grafchart structure representing a sharable resource with

real-valued capacity constraints.

used where, e.g., each equipment controller is implemented as a separate

node. The different nodes communicate with each other over a network.
The question is then how well the presented recipe alternatives are suited
for distributed execution.
The simplest way to obtain distributed execution is to assume that all
recipe management, including recipe execution, is performed in a single
supervisory node. The linking between the recipe level and the execution
control level, that previously was realized by a Grafchart method call, will
now be implemented as a remote procedure (method) call. A drawback
with this approach is that it is still, by large, centralized in nature. If the
supervisory recipe execution node fails all recipe execution in the entire
batch cell will stop.
True distributed recipe execution can only be obtained by sending recipe
information between the different equipment controller. Assume that all
the equipment units that a control recipe will use are prespecified by the
operators before the recipe is started. This is done in one of the nodes of
the system. When the recipe is started the recipe is sent to the first equip-
ment node. When the execution in the first equipment node is finished,
the recipe (or only the remaining part of the recipe) is sent to the next
equipment node, etc.
Depending on which structuring alternative that is used different amount
of information has to be passed between the equipment nodes. If each con-
trol recipe is represented by a separate function chart, then the function
charts have to be passed between the nodes. If, however, function charts
are used only to represent the master recipes and object tokens are used

187
Chapter 8. Recipe Structuring using Grafchart

for representing the individual batches, then things become a bit simpler.
It is now possible to store a copy of each master recipe function chart in
each node, and to pass only the object token information together with
information about the current step of an object token, between the nodes.
If the resource allocation should be integrated with the recipe execution
as, e.g., in Figure 8.9 or 8.11, things become more complicated. One possi-
bility is to let one equipment node for each equipment type, be responsible
for the allocation of resources of that type. When a recipe needs to allocate
a resource of a certain type, a request is sent to the resource allocation
node for the equipment type. The batch will wait in the preceding equip-
ment unit until a suitable equipment unit becomes available. Information
about the identity of the new equipment unit is sent back to the equipment
node where the batch is currently waiting, and the transfer to the new
equipment unit can start. A rather elaborate handshaking procedure is
needed to implement this synchronization. Distributed recipe execution of
this nature is available in modern commercial batch control system such
as, e.g., the batch control system in SattLine from Alfa Laval Automation.

8.7 Grafchart Structured Recipes vs Industry Practice

The status of commercial batch control systems of today is presented in
Chapter 6.5. Most systems follow, to a greater or lesser extent, the ISA
S88.01 standard concerning the recipes and their structuring and exe-
cution. The Grafchart structured recipes presented in this chapter also
follow the standard. The recipes in commercial systems and the Graf-
chart structured recipes have some similarities but they also have a lot
of differences. In this section, the similarities and differences are pointed
out and discussed, and the advantages with Grafchart structured recipes
are presented.

Recipe structures Both the commercial system and the Grafchart

recipe system have a graphical representation of the recipes. According to
the standard, a recipe is built up hierarchically. It is allowed to leave out
one or several of the layers. However, in most commercial systems it is not
possible to skip a layer. Using Grafchart, the layers can be treated with
great freedom, compare Figure 8.2, Figure 8.5 and Figure 8.7. Each layer
contains a structure of steps and transitions. In the recipes in commer-
cial systems, the steps and the transitions can be connected in any order
whereas they have to appear in an alternating sequence (step, transition,
step, transition, etc) in the Grafchart structured recipes. The fact that
the steps do not have to be placed one after the other might, in certain

188
 8.7 Grafchart Structured Recipes vs Industry Practice

cases be space-effective but it can also cause confusion for the user. In
Figure 8.27 a possible sub-sequence of a recipe of a commercial system is
shown. The interpretation of this structure is ambiguous.

Phase A

a
b
c

Phase B

Figure 8.27 A possible sub-sequence of a commercial-structured recipe.

The substructure can be interpreted in many different ways, some of them

are shown in Figure 8.28. The left part of the figure corresponds to an in-
terpretation where the execution of the upper step should terminate as
soon as the uppermost transition becomes true but where the execution of
the lower step should not start until the bottom-most transition has fired.
The middle part of the figure corresponds to an interpretation where the
execution of the upper step should not terminate until all transitions are
true. A third possible interpretation of the recipe from the commercial
system in Figure 8.27 is shown in the right part of Figure 8.28. In this
alternative the ordering between the three transitions are of importance.
Yet other interpretation alternatives are possible. Using Grafchart, un-
ambiguities like this do not exist.

Recipe execution The main and the most important difference is the
token concept in the Grafchart-structured recipes. The fundamental role of
the token is to indicate the step that is currently active. In a commercial-
structured recipe this is indicated by colors. However, as has been shown
in the recipe structures presented earlier in this chapter, the role of the
token can be extended and a token may contain a lot of information. The
same amount of information can not be stored in the colors used in a
commercial-structured system. The fact that a token can contain a lot of
information makes it possible to reduce the size of the representation of
the recipes.
In a recipe of a commercial system, the overall plant status is represented
textually, compare Figure 6.9. The reason for having a textual representa-

189
Chapter 8. Recipe Structuring using Grafchart

Phase A Phase A

a a

wait Phase A Continue Phase A

b a AND b AND c b

wait Phase B Continue Phase A

c c

Phase B Phase B

Figure 8.28 Some possible interpretations of the commercial-structured recipe in

Figure 8.27.

tion is that there does not exist a compact way of representing the status
of all recipes. Using Grafchart and the object token feature, the status of
the plant could easily be represented graphically in a nice way, compare
Figure 8.16. By allowing the token to contain information, the required
logged batch data can be stored in the token in a convenient way.

Resource allocation In most commercial batch systems of today, there

are no means for recipe analysis. In order to guarantee that the execution
of batches does not enter a deadlock situation, the user can pre-allocate all
resources needed for the production of a batch. This is, as will be discussed
in Chapter 9.1, very conservative and non-effective. There are no means
for deadlock detection, deadlock prevention or deadlock avoidance. How
recipe analysis can be combined with the Grafchart structured recipes
will be discussed in Chapter 9.5. Grafchart does also, in contrast to the
commercial systems, allow for a visualization of the resource allocation.

Recipe implementation Even though most recipes in commercial sys-

tems have a graphical interface, the implementation of the lowest level
in the recipe, i.e., the phases, is most often done in a textual language.
Using Grafchart, the same language can be used on all levels in the im-
plementation of a recipe. This helps both the developer and the user, since
they feel comfortable when writing/reading a program.

190
 8.8 Other Batch Related Applications of Grafchart

8.8 Other Batch Related Applications of Grafchart

Grafchart has been used in other batch related applications.

Automating Operating Procedure Synthesis

Plant personnel often spend considerable amount of time and effort, prepar-
ing and verifying the recipes, i.e., the operating procedures. It would
therefore be valuable to automate the synthesis. A framework for this
task is presented in [Viswanathan et al., 1998a]. The framework is based
on Grafchart. Grafchart is used to represent the procedural knowledge.
The declarative knowledge, i.e., the plant and process specific knowledge,
is represented in an object-oriented way. Grafchart is also used to model
the information that is incrementally generated during operating proce-
dure synthesis, the so called inferred knowledge. An hierarchical planning
strategy is presented that processes the declarative knowledge, utilizing
the procedural knowledge, to generate the inferred knowledge incremen-
tally, which leads to the synthesis of the operating procedures.

The implementation of this framework, named iTOPS (Intelligent Tool

for Operating Procedure Synthesis), is described in [Viswanathan et al.,
1998a] and [Viswanathan et al., 1998b]. iTOPS is implemented in G2. The
application of iTOPS to an industrial case study is also presented in the
articles.

An Integrated Batch Plant Operation System

The activities involved in batch plant operation are of a diverse nature
and call for a range of different views to be solved efficiently. However, the
activities interact strongly with each other and it is therefore not possible
to treat the different activities as different problems.

In [Simensen et al., 1996] an integrated batch plant operation system

is presented. The information model underlying this system is based on
a knowledge base containing different models of the plant. The models
depicts the problem area in terms of functions, domain and dynamics. To
structure the system both user views and representation views are used.
The system has the ISA-S88.01 standard as a basis.

A prototype of the integrated batch plant operation system has been im-
plemented and it has been applied to a simulated batch scenario. Depend-
ing on what kind of activity the user would like to perform, different views
are desirable. The user uses an extended version of the Control Activity
Model of ISA-S88.01 as a navigator metaphor. The integrated batch plant
operation system is implemented in G2.

191
Chapter 8. Recipe Structuring using Grafchart

8.9 Summary
The main application of Grafchart is recipe structuring and resource
management in multi-product, network-structured batch production cells.
Grafchart is well suited for these tasks. By using the features of Graf-
chart in different ways, large variations can be made when structuring
the recipes. They still however, comply with the ISA S88.01 standard. The
simplest way is to represent each control recipe with a Grafchart func-
tion chart with batch specific information represented as attributes of the
function chart. The recipes can also be structured using object tokens.
In this case, control recipes of the same type, move around in the same
chart. Batch specific information is stored within the token. By using the
multi-dimensional structure of Grafchart, the chart in which the tokens
reside can be given a general structure. Tokens of different types, i.e.,
of different master recipes, can now reside in the same chart. The token
contains its own recipe-procedure as a method.
Resource allocation can be made in two ways: implicitly or explicitly. If the
resource allocation is done explicitly, i.e., if each resource is represented
by a token, formal analysis methods can be applied to the net, and prop-
erties like deadlocks can be detected. Resource allocation of exclusive-use
resources and deadlock-analysis have been looked at in other areas, e.g.,
Petri nets, and their results can be useful also for a recipe management
system in the batch control field.

192
9
Recipe Analysis

The main objective when developing Grafchart has been to provide a user-
friendly high-level language for sequential control applications. In doing
so, the work has been inspired by the concepts used in several different
areas, e.g., concepts that are normally used within the context of formal
modeling languages for discrete event systems. Hence, it is easy to get
the conception that Grafchart is also developed with the intention to be a
formal modeling language. This is not the case. However, since Grafchart
is based on Grafcet and Petri nets and since it is possible to transform a
Grafchart into a Grafcet and/or a Petri net, see Chapter 5.8, it is possible
to apply some of the formal methods for, e.g., verification, that have been
developed for Grafcet and Petri nets, also to Grafchart.
There are advantages of having a programming language that mechan-
ically can be transformed to an analyzable format. In this way the con-
troller does not have to be manually modeled before applying the formal
methods, and the risk of introducing errors or inconsistencies is therefore
reduced. This means that the Grafchart implementation can be seen as
an executable controller model. Still, however, the plant that is controlled
by the Grafchart has to be modeled in order for the formal analysis to be
complete.
The aim of this chapter is to show how formal methods for Petri nets can
be used in the context of recipe-based batch control. The methods are used
for deadlock analysis due to improper resource allocation. The approach
is based on transforming the combined Grafchart recipe containing all the
master recipes together with the shared resources into a Petri net. The
size of this Petri net is then reduced and the reachability graph is cal-
culated. By inspecting the reachability graph, deadlock situations can be
found. The reachability graph can also be used to detect situations where
the firing of a transition in a recipe may lead to a deadlock situation. The
analysis results can be used statically to prevent deadlocks from occuring,
or dynamically in order to to avoid deadlocks.

193
Chapter 9. Recipe Analysis

A batch cell similar to the one in Chapter 7.3 is used in this chapter. Two
simplifications are made. The first one concerns the connectivity of the
units in the batch plant. All units in the batch cell are assumed to be fully
connected. This means that it is not necessary for a batch to allocate any
transportation equipment such as pipes, valves or pumps, in order for the
batch to be moved from one unit to another. If this would not have been the
case, the transportation equipment would have to be modeled as resources
that the batch would have to allocate. The second simplification concerns
the units. Units of the same type are all assumed to be equivalent, e.g., it
does not matter which of the mixers that is allocated to a batch if there are
several mixers to choose among. The reason why this assumption is made
is that only a structural analysis is performed. Additional constraints,
expressed through the transition receptivities are not taken into account.
The chapter starts, (Chapter 9.1), with a presentation of the general dead-
lock problem. The consequences that the deadlock problem can have in
a batch cell are discussed. Thereafter two batch recipes are presented
(Chapter 9.2). The recipes are structured with Grafchart and they are as-
sumed to be executed in the same plant. After a general discussion about
the Grafchart to Petri net transformation, the two Grafchart structured
recipes are transformed into Petri nets (Chapter 9.3). The Petri net struc-
tured recipes are analyzed (Chapter 9.4) and different ways of using the
results are presented and discussed. (Chapter 9.5). The chapter also con-
tains a presentation of other analysis approaches, (Chapter 9.7), and a
presentation of the relation between resource allocation and scheduling,
(Chapter 9.8).

9.1 The Deadlock Problem

The most efficient batch plants are the multi-product, network structured
plants where several batches, of the same or of different types, can be pro-
duced at the same time. The batches share the equipment in the plant.
If the allocation of the equipment is handled improperly a deadlock situ-
ation might occur, e.g., if a batch currently in one unit requires another
unit and if that unit is reserved by another batch that requires the unit
held by the first batch. Analysis can be performed on the recipes in or-
der to look for certain properties, e.g., deadlock situations. The analysis
methods can also be used to look for other properties, e.g., safe, bounded,
home-states, reversible, etc.
Four conditions exist that must be fulfilled for a deadlock situation caused
by improperly handled resource allocation, to occur, [Burns and Wellings,
1996]:

194
 9.1 The Deadlock Problem

1. The batches need to share resources that are such that they can only
be used by one batch at a time.

2. Batches exist that are holding a resource while waiting for another
resource.

3. A resource can only be released voluntarily by the batch.

4. A circular chain of batches exist such that each batch holds resources
which are requested by the next batch in the chain.

Deadlock situations are always unwelcome since they result in additional

work. To recover from a deadlock one might have to use an additional
unit. One of the batches is moved to this unit and the other batches can
thus proceed. In some cases, however, a deadlock situation might lead to
the deletion of an entire batch. This can, e.g., be the case when all units
are utilized by batches. In order to get out of the deadlock situation one
resource has to be liberated and this can only be done by deleting one
batch. A deletion of a batch is costly and should therefore be avoided.
Batches do also exist that are very sensible and that, after one operation,
e.g., a reaction operation, immediately requires that the following opera-
tion, e.g., cooling, starts. If this is not the case, the quality of the batch
decreases. If the quality does not fulfill the requirements, the batch must
be deleted, or its price must be reduced. It is therefore important to know,
not only when and why a deadlock situation can arise but also how they
can be avoided.
If a deadlock situation has occurred, it is sometimes possible to recover
from it by temporarily moving one of the batches to an unreserved unit in
the plant. In this way, the batches can proceed and all batches involved
in the deadlock can be completed. This method is refered to as deadlock
detection and recovery, [kesson and Tittus, 1998]. Detection and recov-
ery is unsatisfactory since it interrupts the production. A better solution
is achieved by using the analysis results to make sure that a deadlock
situation never occurs. This can be done by restricting the possible re-
source allocations, either statically (deadlock prevention), or dynamically
(deadlock avoidance), [kesson and Tittus, 1998].
The allocation of the resources must be restricted in such a way that one
or several of the four conditions above do not hold.

1. Removing condition number 1 is often unrealistic. Almost all batch

plants have a shared resource structure where a resource only can
be used by one batch at a time.

195
Chapter 9. Recipe Analysis

2. Condition 2 can be removed if the batch pre-allocates all resources

needed during its production before it starts. However, this is a very
conservative method which implies that the resources are not used
in an optimal way.

3. Removing condition 3 means that it must be possible to force a batch

to release a resource. This implies that the batch has to be deleted
or that there are additional resources to which the batch can be
transported.

4. Condition 4 can be removed if an ordering between the resources

is defined, e.g., an hierarchical ordering scheme, and it is required
that the resource allocation is always done in this order. This can
however, also be a relatively conservative method.

How to restrict the allocation of resources is discussed further in Chap-

ter 9.5.

9.2 Batch Recipes

The batch recipes presented in the examples in this section are supposed
to be run in a cell containing three storage tanks, three product tanks,
two reactors and one mixer. In addition to this the cell contains one extra
mixer that can be connected if desired. One of the reactors can be used
for heating, rectorheat and one for cooling, reactorcool. The cell is shown in
Figure 9.1.

Storage
A B C
tanks

An additional mixer,
Mixers to be connected if desired

Reactors

Product
D E F
tanks

Figure 9.1 A batch plant.

196
 9.2 Batch Recipes

The batches that can be run in the plant originate from two different
master recipes called recipe-A and recipe-B. Both recipes are structured
with Grafchart (object tokens without methods). Recipe-A is shown in
Figure 9.2 (left). The recipe starts by assigning a mixer to the batch. This
is indicated by the first transition. After the assignment the two 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, reactorheat and reactorcool, are used for the
heating and the cooling. After the transfer from reactor heat to reactorcool,
reactorheat is no longer needed 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. Reactorcool is now released. The mixture is
agitated and thereafter discharged. Finally the mixer is released.
MIXER REACTOR REACTOR cool
heat
MIXER REACTOR heat REACTOR cool

Mixer
Mixer

FillA FillB
FillA FillB

Agitate
Agitate
Reactorheat
Reactorcool

Empty 1/2 Charge

Empty 1/2 Charge

Heat
Reactorcool Cool
Reactorheat

Charge
Empty Empty Charge

Reactorheat
Cool Heat

Charge Empty Charge Empty Empty

Reactorcool
Agitate Agitate

Discharge Discharge

Mixer Reactor , Reactorcool , Mixer

heat

Figure 9.2 Two Grafchart recipe structures: recipe-A (left) and recipe-B (right).

Recipe-B is shown in Figure 9.2 (right). This batch mixes two reactants
in a mixer, and then transfers half of the content to a reactor for cooling.

197
Chapter 9. Recipe Analysis

When the cooling is ready, 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.

Since batches of the two recipes are produced in the same plant and there-
fore utilize the same units, they will effect each other. The two recipes can
be combined into one Grafchart where the resource allocation is visual-
ized, compare Chapter 8.2 (Combined Network). This is shown in Fig-
ure 9.3. The number of tokens placed in the initial step in each of the
recipes corresponds to the aim of producing the same number of batches.

FillB FillA FillA FillB

Mixer

Agitate Agitate

Charge Empty 1/2 Charge Empty 1/2

ReactorHeat
Heat Cool

Charge Empty Charge Empty

ReactorCool

Cool Heat

Empty Charge
Charge Empty Empty

Agitate
Agitate

Discharge
Discharge

Figure 9.3 Two recipes combined into one Grafchart.

Both recipes are structured with phases. According to the ISA S88 batch
standard, a phase must always execute within the same unit, see Chap-
ter 6.2 (Procedural Control).

Remark: The batch cell as well as the two recipes are not based on a
real scenario but have been made up in order to illustrate the analysis
concepts as clearly as possible.

198
 9.3 Batch Recipe Transformation

9.3 Batch Recipe Transformation

In order to analyze a recipe with respect to deadlock situations, the Graf-
chart structure is transformed into a Petri net structure. The analysis
methods presented in Appendix B apply to autonomous Petri nets. This
means that the corresponding Petri net will not have any transition re-
ceptivities nor will it, since it is a Petri net, have any step actions. The
question is then how the lack of actions and receptivities will influence
the analysis results. Can a Grafchart that is deadlock free be transformed
into a Petri net that, when analyzed, claims that the Petri net could have a
deadlock? If the corresponding Petri net is deadlock free, does this always
mean that the Grafchart is deadlock free or do there exist cases when the
Grafchart could get into a deadlock situation? The different questions at
issue are illustrated in Figure 9.4.

Deadlock- ? Deadlock
free

? ?
Deadlock-
Deadlock ? free

Figure 9.4 Deadlock relation between Grafchart and Petri net.

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 are, compare Chapter 5.8
(Grafchart - the basic version: Transformation to Grafcet): the graphical
elements, the actions and receptivities in Grafchart, and the dynamic
behavior.
Graphical elements: The graphical syntax for steps, transitions, parallel
branches and alternative branches are not identical in Grafchart and Petri
nets, see Figure 9.5.
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,
see Chapter 5.8 (Grafchart - the basic version: Transformation to Grafcet).

199
Chapter 9. Recipe Analysis

x1 alternative branch p1
alternative
branch
t1 t2 t1 t2
x2 x3 p2 p3
parallel branch parallel
t4 t4 branch
t3
p4 p5
x4 x5
t5
t3 t5

Figure 9.5 A Grafcet (left) and a Petri net (right).

Receptivities and actions: An autonomous Petri net does not have any
receptivities associated with the transitions. A Grafchart receptivity can
either cause or prevent a deadlock situation.

In Figure 9.6 (left) a Grafchart structure is shown. The Grafchart contains

an or-divergence situation with two branches. The right branch loops back
to the step preceding the or-divergence situation while the left branch ends
in a step without any succeeding transitions, i.e., a possible deadlock state.
However, since the transition receptivity in the left branch is equal to false
the token can never come to this deadlock state. The transition receptivity
prevents a deadlock from occuring. The corresponding autonomous Petri
net, see Figure 9.6 (right), does not have any transition receptivities and
is therefore not deadlock-free.

false

deadlockfree Not deadlockfree

Figure 9.6 A Grafchart receptivity that prevents a deadlock situation.

200
 9.3 Batch Recipe Transformation

In Figure 9.7 (left) a Grafchart structure is shown. The Grafchart contains

an or-convergence with two branches. However, the transition receptivity
associated with the left branch is equal to false which means that if the
token enters this branch branch it can never leave, i.e., a deadlock situa-
tion has occurred. The transition receptivity causes a deadlock situation.
The corresponding Petri net, see Figure 9.7 (right), does not have any
transition receptivities and can therefore not get into this deadlock state.

false

Not deadlockfree
deadlockfree

Figure 9.7 A Grafchart receptivity that might cause a deadlock situation.

A Petri net does not have any actions associated with the places. A Graf-
chart action can cause a deadlock situation to occur. An example of this
is given in Figure 9.8. The Grafchart structure in the figure contains two
steps and one transition. The action associated with the first step sets
the transition receptivity to false which means that the transition never
can fire and a deadlock situation has therefore occurred. A correspond-
ing Petri net would not contain the action nor the receptivity and could
therefore not result in the deadlock situation.

conclude that x = false

Figure 9.8 An action that cause a deadlock situation to occur.

Reversed scenarios where an action prevents a deadlock situation to occur

also exist.

201
Chapter 9. Recipe Analysis

As has been shown, actions and receptivities might cause deadlock sit-
uations to occur. These situations cannot be found by analyzing the cor-
responding Petri net. Action and receptivities can also prevent deadlock
situation from occuring. In these cases the corresponding Petri net will
not always be deadlock-free.
Dynamical behavior: 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.
Remark As has been shown it is only the topology, i.e., the graphical
structure, of a Grafchart that can be analyzed. Influences from step ac-
tions and transition receptivities can not be taken into account.

Recipe transformation procedure When transforming a Grafchart

into a Petri net, the transformation rules presented in Chapter 5.8 (Graf-
chart - the high-level version: Transformation to Petri nets) should be
used. Since the effect of a step action or a transition receptivity not can
be analyzed the transformation rule number 4, 5 and 9 can be replaced
with the simplified rules:

4. The actions are neglected since the influence of an action not can be
analyzed.
5. The receptivities are neglected since the influence of a receptivity
not can be analyzed.
10. Parameterization of receptivities are of no importance because of
(5).

Using the transformation rules, the recipe structure of Figure 9.3 can
be transformed into a Petri net. The corresponding Petri net is shown
in Figure 9.9. Recipe-A is placed to the left in the figure and Recipe-
B to the right. In addition to the transformation rules, the fact that a
phase always executes within the same equipment (no resource allocation
or deallocation allowed), 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 Petri net structure shown in Figure 9.9 has two initial places, one
in each recipe. In each initial place one token is placed. If the dotted

202
 9.3 Batch Recipe Transformation

transition and dotted arc that closes the loop are disregarded, the tokens
indicate that one batch of each type should be produced. If, however, the
Petri net structure is closed, i.e., if the dotted transition and arc are taken
into account, the tokens placed in the initial-places instead indicate that
at most one batch of each type should be produced at the same time in
the plant. When a batch of, e.g., type A, has been produced, the token can
be returned to the initial place and the production of a new batch of this
type is allowed to start.

Mixer

Reactor_heat

Reactor_cool

Figure 9.9 A Petri net recipe structure corresponding to the combined Grafchart
recipe in Figure 9.3.

The two transformed recipes in Figure 9.9 can now be reduced according
to the reduction rules presented in Appendix B, see Figure 9.10. The
transformed recipe on the left side in the figure corresponds to Recipe-A
and the transformed recipe on the right side corresponds to Recipe-B. The
Petri net structure can be open or closed.

203
Chapter 9. Recipe Analysis

P1 Mixer P5

P9 T4
T1
P2 P6
Reactor_heat
T2 P10 T5
P3 P7

T3 P11 T6

Reactor_cool P8

P4

Figure 9.10 The reduced Petri net recipe structure for to the Petri net recipe
structure in Figure 9.9.

9.4 Analysis

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, see Figure 9.11. The dotted lines correspond to the return of the

0 0 0 0 0
1 0 0 0 0
0 1 0 0 0
0 0 1 1 1
1 1 1 0 0
0
T2 0
T3 0
T4 1
T5 0
0 0 0 0 1
1 T1 0 0 0 0 0 T6 0
0 0 0 1 0 0 0
0 1 0 1 1 1 0
0 1 1 1 1 0 1
1 0
0 0
0 0
0 1 1 1 0 0
0 0 0 1 0 1
1 1
1 T4 0 0 0 0 1 T3
0 0 0 0 0 1
1 1
0 0 0 0 0
1 0 0 0 0
0 T5 1 T6 0 T1 0 T2 0
0 0 1 1 1
0 0 1 0 0
1 1 1 1 0
1 0 1 1 1

Figure 9.11 Reachability graph.

204
 9.4 Analysis

token to the initial place. As can be seen, these lines do only loop back to
already existing states and they can therefore not lead to a new deadlock
situation. In the sequel of this chapter, these lines are left out in all
reachability graphs.
What if we add an extra resource to the plant, e.g., connect the additional
mixer that we have in the plant, see Figure 9.1? 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 danger-
ous, [Jensen, 1992]. The reachability graph, corresponding to Figure 9.10,
using two mixers, is shown in Figure 9.12.

0
0
0
1
1
0
T3 0 T4
0 0 0
0 2 0
1 1 0
0 1 1
1 0
0 1
T2 0 T4 0 0 T5
0 T3 0
0 0 0
1 1 1 1 0
0 0 0 1 0
0 1 0 1 1
1 1 0
0 0 0
1 0 T4 0 0 T5 0 1 T6 0
T1 1 T2 0 0 0
0 0 0
0
DEADLOCK

0 1 0 1 1 0
0 1 0 1 0 1 1
1 1 0 0 0 0
0 1 0 0
0 0
0 1 1 0
0 0 T5 0 T2 0 0 1
1 T1 0
2 0 0 2
0 1 0
0 1
T3
1 T4 0 0 1
1 1 0 0 1
0 0
0 1 0
1 0 0
0 1 0 T6 0 0
0 1 1
0 T1 1
1 0 0 0 T2 1
0 0 0
1 T5 0 0 1
1 1
0 0
1 0 0
0 0 1
1 0 1
1 T6 0 T1 1
0 0 1
0
1
2
1
1

Figure 9.12 Reachability graph.

205
Chapter 9. Recipe Analysis

The deadlock situation that arises when a second mixer is added to the
plant can intuitively be understood by examining Figure 9.10. The two
recipes use reactorheat and reactorcool 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.
Situations where the resource has to fulfill certain constraints, e.g., a
minimum value or a high temperature tolerance, can be implemented
by using the transition conditions in Grafchart-HLV. Examples of this
are given in Chapter 8.5 (Shared Resources). Since the analysis methods
presented do not take the receptivities into account, the specific demands
that a batch can have on a resource are not considered. To solve this
problem, resources with different capacity must reside in different steps.
A drawback with the reachability graph method is that the complexity in-
creases rapidly when the size of the net increases. However, this drawback
is also present in most formal analysis methods for this type of problems.

9.5 Using the Analysis Results

The analysis results can be used both statically and dynamically. Static
reasoning deals with the question of which combinations of number of
batches and number of units that can be safely started in the plant at
the same time. The answer to this question can, e.g., be stored in a table.
Dynamic reasoning is about determining, depending on the status of the
plant, which units that are unsafe to allocate and therefore not should
be reserved by a batch, i.e., to find the unsafe states. To assure that the
system never reaches an unsafe state a supervisor can be used.

Static Deadlock Prevention

Analysis can be performed and the results can be stored in a table. The
results can, e.g., show the number of batches in different recipe combina-
tions, that can execute at the same time in the plant without risk for a
deadlock. Figure 9.13 showspossible-deadlocks with respect to the two
recipes, versus different plant configurations. Assume that the default
plant is 3 mixers (M), 1 reactorheat (Rh) and 2 reactorcool (Rc). The table
shows the risk of deadlocks for the default plant as well as for the plant
with one or several of the equipments broken down.
The risk-of-deadlocks depends on the number of batches that are pro-
duced in the plant. The uppermost row in the table shown in Figure 9.13

206
 9.5 Using the Analysis Results

corresponds to the production of two batches of recipe-A and two batches

of recipe-B. The three rows below correspond to the production of sub-
adjacent cases. If the uppermost row indicates that the production in a
certain plant configuration is ok, then it follows that the production of
the sub-adjacent cases are also ok. This is the case of column two, three
and six. A similar reasoning can be done for the bottommost row. This row
corresponds to the production of one batch of recipe-A and one batch of
recipe-B. The three rows above corresponds to the production of a higher
number of batches. If the bottommost row indicates that the production
in a certain plant configuration is not-ok, it can be concluded that the
production of the three other rows are not-ok either. This is the case in
column four and five.

2* Recipe-A
+ -- ok ok -- -- ok
2* Recipe-B

2* Recipe-A
+ ok ok ok -- -- ok
1 Recipe-B

1 Recipe-A
+
2* Recipe-B
-- ok ok -- -- ok

1 Recipe-A
+
1 Recipe-B ok ok ok -- -- ok
3M+1Rh+2Rc

2M+1Rh+2Rc

1M+1Rh+2Rc

3M+1Rh+1Rc

2M+1Rh+1Rc

1M+1Rh+1Rc

Figure 9.13 A table showing the possibility of deadlock for different recipes in
different plant configurations, ok
deadlock not possible,
deadlock possible.

The table can be used as a help when determining how to prevent dead-
lock situations from occurring in a batch plant. According to the table
in Figure 9.13 two batches, one of type A and one of type B, can be run
in the same plant simultaneously with no risk of entering a deadlock
situation if the plant consists of one, two or three mixers together with
one reactorheat and two reactorcool or if the plant consists of one mixer, one
reactorheat and one reactorcool. These combinations of batches versus plant
configurations can be run without any deadlock considerations. However,
if the plant consists of two or three mixers together with one reactorheat

207
Chapter 9. Recipe Analysis

and one reactorcool there is a risk of getting stuck in a deadlock situation.

In order to completely eliminate this risk, this combination of batches
versus plant configuration should never be run.
Using the analysis results in this way is an example of deadlock preven-
tion. However, this method is very conservative. Even if the starting of a
certain number of batches, e.g., one of type A and one of type B, in a certain
plant configuration, e.g., two mixers, one reactor heat and one reactorcool,
might lead to a deadlock situation, this is not always a consequence. The
execution of this batch-vs-plant combination can complete normally. This
can be seen in the reachability graph shown in Figure 9.12. However, in
order to eliminate the risk of getting into a deadlock situation, all cases
that might lead to a deadlock situation are statically excluded. The ta-
ble based method is more conservative than needed and might, in a worst
case, lead to the conclusion that no batches should be started in any plant
configuration.

Dynamic Deadlock Avoidance

Dynamic deadlock avoidance can be realized through a forbidden state
approach. The forbidden state method is less conservative than the table
method. In the table based deadlock prevention method, the starting of
entire batches are excluded. In the forbidden state method it is a matter
of excluding only the firing of certain transitions, i.e., the allocation of
certain resources. The transitions that should be excluded vary with the
situation in the plant, i.e, dynamically.
Figure 9.12 shows the reachability graph for the case when the plant
consists of two mixers, one reactorheat and one reactorcool and when two
batches, one of type A and one of type B, are assumed to be produced
in the plant. The initial marking of the plant is [10001000211]T . As can
be seen in the reachability graph, it is possible to get into a deadlock
situation. By using the table, Figure 9.13, the user is adviced not two
run the two batches in the plant. However, the deadlock situation can
be avoided by preventing the firing of transition T2 when the marking is
[00100010000]T and preventing the firing of transition T5 when the mark-
ing is [00100100001]T . The reachability graph, with these two transitions
indicated, is shown in Figure 9.14.
More advanced reasoning can also be included when using the forbidden
state method. Assume, for example for recipe-B, that when the two sub-
stances have been filled in to the mixer and agitated, a Reactorcool is imme-
diately needed, i.e., the batch is not allowed to wait for this unit. Can this
requirement be guaranteed by excluding the firing of certain transitions?
Place P6 in Figure 9.10 corresponds to the filling and agitating phases

208
 9.5 Using the Analysis Results

in recipe-B, compare Figure 9.9. In the reachability graph, Figure 9.12,

being in this place corresponds to the marking [1 ]T (
any
number). Whenever in this state there must always exists a possibility
to fire transition T5, since the firing of this transition corresponds to the
allocation of a reactorcool.
There are four markings that fulfill [ 1 ], these are encircled
in Figure 9.15 (left). From marking [00010100111]T it is possible to fire
only transition T5, i.e, being in this state will cause no problem concerning
the requirement. From marking [00100100001]T it is not possible to fire
transition T5 directly since this would result in a deadlock, but it is possi-
ble to first fire transition T3 and then transition T5. However, this might

0
0
0
1
1
0
T3 0 T4
0 0 0
0 2 0
1 1 0
0 1 1
1 0
0 1
T2 0 T4 0 0 T5
0 T3 0
0 0 0
1 1 1 1 0
0 0 0 1 0
0 1 0 1 1
1 1 0
0 0 0
1 0 T4 0 0 T5 0 1 T6 0
T1 1 T2 0 0 0
0 0 0
0
DEADLOCK

0 1 0 1 1 0
0 1 0 1 0 1 1
1 1 0 0 0 0
0 1 0 0
0 0
0 1 1 0
0 0 T5 T2 0 0 1
1 0
2 T1 0 0 0 2
0 1 0
0 1
T3
1 T4 0 0 1
1 1 0 0 1
0 0
0 1 0
1 0 0
0 1 0 0 0
0 T1 T6 1 1
0 1
1 0 0 0 T2 1
0 0 0
1 T5 0 0 1
1 1
0 0
1 0 0
0 0 1
1 0 1
1 T6 0
T1 1
0 0 1
0
1
2
1
1

Figure 9.14 Reachability graph.

209
Chapter 9. Recipe Analysis

require that the batch will have to wait for transition T3 to fire. In order
to guarantee that such a wait does not occur, the state represented by
the marking [00100100001]T should be considered a forbidden state and
to avoid arriving in this state, the firing of the two transitions T4 and T2,
leading to this state, must be excluded. From marking [01000100011]T it
is only possible to fire transition T5 since transition T2 has been excluded.
From marking [10000100111]T it is possible to fire transition T5 either
directly or to fire transition T1 and then transition T5. The reachability
graph with the necessary transitions excluded, i.e., the reachability graph
that fulfills the requirement, is shown in Figure 9.15 (right).
0 0
0 0
0 0
1 1
1 1
0 0
T3 0 T4 T3 0 T4
0 0 0 0 0 0
0 2 0 0 2 0
1 1 0 1 1 0
0 1 1 0 1 1
1 0 1 0
0 1 0 1
T2 0 T4 0
T3 0 T5 0 T2 0 T4
0
T3 0 T5 0
0 0 0 0 0 0 0 0
1 1 1 1 0 1 1 1 1 0
0 0 0 1 0 0 0 0 1 0
0 1 0 1 1 0 1 0 1 1
1 1 0 1 1 0
0 0 0 0 0 0
1 0 T4 0 0 T5 0 1 T6 0 1 0 T4 0 T2 0 T5 0 1 T6 0
0
T1 0 1 T2 0 0 0 0 0
T1 0 1 0 0 0 0
0
DEADLOCK

DEADLOCK
0 1 0 1 1 0 0 1 0 1 1 0
0 1 0 1 0 1 1 0 1 0 1 0 1 1
1 1 0 0 0 0 1 1 0 0 0 0
0 1 0 0 0 1 0 0
0 0 0 0
0 1 1 0 0 1 1 0
0 0 T5 T2 0 0 1 0 0 T5 T2 0 0 1
1 0 1 0
2 0
T1 0
0 0 0
T3 2 2 0
T1 0
0 0 0
T3 2
1 1 0 1 1 1 1 0 1 1
T4 0 1 0
0
T4 0 1 0
0 0
1 0 0 0 1 1 0 0 1
0 1 0 0 1 0
1 0 0 1 0 0
0 1 0 T6 0 0 0 1 0 T6 0 0
0 1 1 0 1 1
0
0
T1 1
0 T2 1
0
0
T1 1
0 T2 1
1 0 1 0
0 0 0 0 0 0
1 T5 0 0 1
1 T5 0 0 1
1 1 1 1
0 0 0 0
1 0 0 1 0 0
0 0 1 0 0 1
1 0 1 1 0 1
1 T6 0 T1 1 1 T6 0 T1 1
0 0 1 0 0 1
0 0
1 1
2 2
1 1
1 1

Figure 9.15 Reachability graphs.

Supervisor
The results from the forbidden state analysis can be implemented by a
supervisor using the supervisory control theory (SCT) of Wonham and
Ramadge, [Ramadge and Wonham, 1989]. The theory can be formulated
both in terms of automata and formal languages. A modified version of
SCT has been developed by Charbonnier and Alla, [Charbonnier, 1996].
The modified version is based on Grafcet and makes a clear distinction
between the controller and the supervisor. Yet an alternative approach,
called Procedural Control Theory (PCT), has been developed at Imperial
College, [Alsop et al., 1996].

SCT In SCT, [Ramadge and Wonham, 1989], a process is modeled as

an automaton that generates events. The set of possible events, denoted
, can be divided into two subsets: controllable events, denoted c and

210
 9.5 Using the Analysis Results

uncontrollable events, denoted uc . The controllable events can, unlike

the uncontrollable ones, be prevented from occuring. The task of the su-
pervisor is to enable or disable the controllable events in such a way that
certain process states are not reached. A process together with a supervi-
sor is shown in, Figure 9.16.

Supervisor

Enabling/Disabling Generated events

of controllable events = c U uc

Plant

Figure 9.16 A process and a supervisor according to SCT.

SCT can be used for both verification and synthesis. The verification ap-
proach consists of modeling the open system, i.e., the process, and con-
structing a supervisor manually. Both the open system and the supervisor
are modeled in terms of a formal language. The language of the closed
loop system, i.e., the process together with the supervisor, is then formed.
Finally, it is checked if the closed loop language is controllable. If so, the
user knows that the supervisor guarantees that the process never enters
certain undesired states. What remains for the user to do is to implement
the supervisor.
The synthesis approach consists of modeling the open system, i.e., the
process, and specifying the desired closed loop behavior. The open system
and the closed loop system are both defined in terms of a formal language.
The controllability of the closed loop language is checked and a supervisor
is generated automatically. The supervisor is given in terms of a formal
language. What remains for the user to do is to implement the supervisor.
The verification approach is more common than the synthesis approach. A
major reason for this is the difficulties involved with specifying the closed
loop system completely for users without training in formal languages.
SCT has received a lot of criticism:

The theory is difficult to grasp.

It can only be applied to small practical systems. This is due to the
combinatorial complexity (state space explosion).
The process is viewed as an event generator. In most real problems,
the process reacts to inputs and generates outputs.

211
Chapter 9. Recipe Analysis

SCT literature provides few indications of how to implement a su-

pervisor.

SCT has been used for batch applications, [Tittus, 1995] and [kesson and
Tittus, 1998], see Chapter 9.7.

Grafcet Supervisor In the SCT approach a supervisor can prevent

some events from occuring, but it can not force any events to occur. In ad-
dition to a supervisor, most real systems need a controller that can force
events to occur. A modified version of SCT has been defined by Charbon-
nier and Alla, [Charbonnier, 1996]. The new approach allows for a clear
distinction between the process, the controller and the supervisor. The
approach is based on Grafcet, i.e., the supervisor and the controller are
represented in Grafcet instead of in a formal language.
The process and the controller constitute the extended process. The events
generated by the process, denoted pr , are assumed to be non controllable,
pr uc . These are typically the output from the sensors in the plant.
The events generated by the controller, denoted co are assumed to be
potentially controllable. However, in a specific case they need not all to
be controllable, i.e., c co. The events generated by the controller are
typically control actions effectuated by the actuators in the plant. The task
of the supervisor is to enable and disable some of the controllable events
in such a way that the extended process never reaches certain undesired
states. The list of authorized events provided by the supervisor is denoted
. In Figure 9.17 a process and controller together with a supervisor is
shown.
enable/disable
controllable events generated events
Supervisor

pr
co
Controller Process

extended process

Figure 9.17 A supervisor.

As can be seen, the controller and the supervisor are separated. Also in
the design procedure, the two parts are designed independently from one

212
 9.6 Grafchart Supervisor

another. The design of the controller constitutes the control specification

for the process. The design of the supervisor constitutes the supervision
specification for the process. The extended process and the supervisor are
converted into an automata model and the language of the closed loop
system is generated. The controllability of the closed loop language can
now be checked in the same way as was done in the SCT.
The advantage of the Grafcet supervisory method by Charbonnier and
Alla compared with classical SCT is that it often reduces the complexity
of the problem. The structure of the Grafcet controller and the structure
of the Grafcet supervisor both gets a relatively small size with a clear
interpretation.
Grafcet based SCT has not been applied in any batch applications yet. As
has been shown, Grafchart resembles Grafcet a lot. The ideas of a Grafcet
supervisor could therefore also be applicable for Grafchart. How this can
be done is discussed further in the following section.

9.6 Grafchart Supervisor

The events taking place in a batch plant need to be controlled and su-
pervised. The plant can be controlled by a Grafchart controller, i.e., by
a recipe. The plant also needs to be supervised, this can be done by a
Grafchart supervisor.
The task of the supervisor is to assure that the system never reaches a
forbidden state, i.e., to assure that certain transitions in the recipe not
are fired. The transitions that should not be fired vary with the state of
the system. A plant controlled by a Grafchart controller (recipe) and su-
pervised by a supervisor is shown in Figure 9.18. The supervisor receives

enable/disable
controllable events Grafchart generated events
Supervisor

Grafchart pl
co
recipe Plant
controller

Figure 9.18 A supervisor.

213
Chapter 9. Recipe Analysis

information about the commands sent by the Grafchart controller to the

plant co, the supervisor also receives information about the events tak-
ing place in the plant, pl . Depending on the new state of the system the
supervisor disables or enables events, .
The supervisor presented here does, however, not take the internal state
of the equipment units into consideration. Assume, for example, that a
mixer in the plant is unreserved but not empty. The supervisor will only
disable the allocation of this mixer if an allocation of it it will lead to a
deadlock state. This means that the non-empty mixer can be allocated by
a batch and the contents of the mixer and the batch will be mixed.

Reachability Graph Based Supervisor

In Chapter 9.5 (Dynamic Deadlock Avoidance), the reachability graph for
a system is shown, Figure 9.14. The system consists of two mixers, one
reactorheat and one reactorcool , and two batches, one of type A and one
of type B, should be produced. In order to exclude the deadlock situation
certain transitions must be disabled. The supervisor for this particular
case is shown in Figure 9.19. An easy way to construct a supervisor is to
let it resemble the structure of the reachability graph: each state in the
reachability graph is modeled by a step in the supervisor and the arcs in
the reachability graph are replaced by transitions in the supervisor.
The arcs in the reachability graph, e.g., Figure 9.14, correspond to the
firing of transitions in the reduced Petri net structure, Figure 9.10. An
arc takes the system from one state to another. For example, the arc
labeled T1 takes the system from the state [1000 1 ]T to the
state [0100 0 ]T and the arc labeled T2 takes the system from
the state [0100 01]T to the state [0010 00]T . A state in the
reduced Petri net structure corresponds to one or several states in the
unreduced Petri net structure, Figure 9.9. The state, in the reduced Petri
net structure, that is reached when T1 has been fired but not yet T2,
i.e., state [0100 ]T , corresponds to the states [0110 ....]T and
[00010 .....]T in the unreduced Petri net structure. This is equivalent to
the execution of the phases mixer fillA and mixer fillB or of the phase
mixer agitate in the Grafchart recipe. This means that the transition
named T1 in the supervisor should be fired when the system has arrived
in the mixer fillA and mixer fillB phase or when the system has arrived
in the mixer agitate phase. Which one that is chosen is unimportant. The
approach is illustrated in Figure 9.20.
The supervisor enables or disables the events "OKT1", "OKT2", "OKT3"
and "OKT4", "OKT5", "OKT6". These events make it possible or impossible
for the Grafchart controller to allocate a Mixer, Reactorheat or Reactorcool

214
 9.6 Grafchart Supervisor

initially
conclude that OKT1, OKT2, OKT3 = true
conclude that OKT4, OKT5, OKT6 = true

T4 T1

T5 T1 T4 T2

T6 T1 T5 T2 T4 T3
Initially Initially
conclude that conclude that
OKT2 = false OKT5 = false

T1 T6 T3 T4
Initially Initially
conclude that OKT2=true conclude that OKT5=true

T2 T5

T3 T6

T1, a transition T2, a transition T3, a transition

Event RecipeA mixer_agitate Event RecipeA reactorH_heat Event RecipeA reactorC_cool

Condition Condition Condition

T4, a transition T5, a transition T6, a transition

Event RecipeB mixer_agitate Event RecipeB reactorC_cool Event RecipeA reactorH_heat

Condition Condition Condition

Figure 9.19 A supervisor for the case in Figure 9.14.

for recipe-A and a Mixer, Reactorcool or Reactorheat for recipe-B respec-

tively. In order to take the events generated by the supervisor into account,
the two recipes must be modified. The unmodified versions of Recipe-A and
recipe-B are shown in Figure 9.2 and the modified versions are shown in
Figure 9.21. As can be seen it is only certain transition receptivities that
have been modified. The modification consists of an additional condition
on "OKTx" in the receptivity. If "OKTx" is true, the enabled transition can
fire, but if "OKTx" is false it cannot fire.

215
Chapter 9. Recipe Analysis

Grafchart recipe Unreduced Petri net Reduced Petri net

p1 Mixer
Mixer
t1 P1 Mixer

Fill-A Fill-B p2 p3 T1 = t1t2

t2 P2
Reactor
Agitate p4 Reactor T2 = t3...
Reactor
t3

p5

1 0
T1, a transition
0 T1 1 T2
event mixer_agitate T1 * *
condition * *

T2

Supervisor Reachability graph

Figure 9.20 The train of thought for finding out the transition receptivities in a
supervisor.

Depending on the number of batches in the plant, the configuration of the

plant, or the requirements on the production of the batches, the struc-
ture of the reachability graph is changed and thus the transitions that
should be disabled varies. This means that the structure of the super-
visor is modified. However, the two recipes, recipe-A and recipe-B, see
Figure 9.21, need not to be further modified depending on the structure
of the supervisor.

The forbidden state method can be used to find the states that should be
avoided and the transitions that should be disabled in order to prevent
a deadlock from occuring. It can, however, also be used to assure other
scenarios, e.g., that a unit is always available for allocation after a certain

216
 9.6 Grafchart Supervisor
MIXER REACTOR REACTOR cool
heat MIXER REACTOR heat REACTOR cool

Mixer
t1 Mixer
t11
FillA FillB
FillA FillB

t2
t12
Agitate
Agitate
Reactorheat Reactorcool
t3
t13

Empty 1/2 Charge

Empty 1/2 Charge

t4
t14
Heat
Reactorcool Cool
t5 Reactorheat
t15

Charge
Empty Empty Charge

t6
Reactorheat t16
Cool Heat
t7
t17

Charge Empty Charge Empty Empty

t8
Reactorcool t18
Agitate Agitate
t9
t19
Discharge Discharge
t10 t20
Mixer
Reactor , Reactorcool , Mixer
heat

t1, a transition t3, a transition t5, a transition t11, a transition t13, a transition t15, a transition
event event event event event event
condition OKT1 condition OKT2 condition OKT3 condition OKT4 condition OKT4 condition OKT5

Figure 9.21 Two Grafchart recipe structures susceptible for events generated by
a supervisor: recipe-A (left) and recipe-B (right).

operation. Such an example was presented in the Chapter 9.5 (Dynam-

ical Deadlock Avoidance) and the corresponding reachability graph can
be seen in Figure 9.15 (right). The supervisor for this case is shown is
Figure 9.22.

217
Chapter 9. Recipe Analysis

initially
conclude that OKT1, OKT2, OKT3 = true
conclude that OKT4, OKT5, OKT6 = true

T4 T1

T5 T1 T4 T2
Initially Initially
conclude that conclude that
OKT2 = false OKT4 = false

T6 T1 T5 T3
Initially
conclude that
OKT4 = true
T1 T6 T4
Initially
conclude that
OKT2 = true

T2 T5

T3 T6

T1, a transition T2, a transition T3, a transition

Event RecipeA mixer_agitate Event RecipeA reactorH_heat Event RecipeA reactorC_cool

Condition Condition Condition

T4, a transition T5, a transition T6, a transition

Event RecipeB mixer_agitate Event RecipeB reactorC_cool Event RecipeA reactorH_heat

Condition Condition Condition

Figure 9.22 A supervisor for the case in Figure 9.15.

Recipe State Based Supervisor

The size of the supervisors shown in the last subsection can easily become
very large. If the size gets too large it becomes impossible to implement
them. It is therefore desirable to reduce the size of the supervisors.

Consider once again the plant consisting of two mixers, one reactorheat and
one reactorcool. In the plant two batches, one of type A and one of type B,

218
 9.6 Grafchart Supervisor

should be produced. The reachability graph for this system is shown in

Figure 9.15. In order for the supervisor to disable and enable the tran-
sitions correctly, the supervisor must know when the system arrives in
or leaves from certain states. These states only constitute a subset of the
total number of states in the reachability graph. For the system under con-
sideration, the important states are [00100100001]T and [01000010010]T .
In Figure 9.23, these states are marked out and given names.

0
0
0
1
1
0
T3 0 T4
0 0 0
0 2 0
1 1 0
0 1 1
1 0
0 1
T2 0 T4 0 0 T5
0 T3 0
0 0 0
1 1 1 1 0
0 0 0 1 0
State A

0 1 0 1 1
1 1 0
0 0 0
1 0 T4 0 0 T5 0 1 T6 0
T1 1 T2 0 0 0
0 0 0
0
DEADLOCK
0 1 0 1 1 0
0 1 0 1 0 1 1
1 1 0 0 0 0
0 1 0 0
0 0
0 1 1 0
0 0 T5 0 T2 0 0 1
1 T1 0
2 0 0 2
0 1 0
0 1
T3
1 T4 0 0 1
State B

1 1 0 0 1
0 0
0 1 0
1 0 0
0 1 0 T6 0 0
0 1 1
0 T1 1
1 0 0 0 T2 1
0 0 0
1 T5 0 0 1
1 1
0 0
1 0 0
0 0 1
1 0 1
1 T6 0 T1 1
0 0 1
0
1
2
1
1

Figure 9.23 A supervisor for the case in Figure 9.15.

The reachability graph based supervisor, see Figure 9.19, contained fifteen
states. The structure of the supervisor can be reduced so that it contains
only four states. The reduced supervisor is shown in Figure 9.24.
In this supervisor, it is assumed that the two states named stateA and
stateB can be detected. By using the same type of reasoning as presented

219
Chapter 9. Recipe Analysis

T1 T2
Initially Initially
conclude that conclude that
OKT5 = false OKT2 = false
T3 T4

T5

T1, a transition T3, a transition T5, a transition

Event Event Event
Condition StateA Condition not(StateA) Condition true

T2, a transition T4, a transition

Event Event
Condition StateB Condition not(StateB)

Figure 9.24 A reduced supervisor for the case in Figure 9.23.

in Figure 9.20 the real states that correspond to the two states in the
reachability graph can be deduced, see the following table:
Reachability graph state Real state

[0010 **** ***] T ((RecipeA mixer_empty

AND recipeA reactor heat _charge)
OR recipeA reactor _heat)
stateA

heat

[**** 0100 ***] T ((RecipeB mixer_fillA

AND recipeB mixer_fillB)
OR recipeB mixer_agitate)

[0100 **** ***] T ((RecipeA mixer_fillA

AND recipeA mixer_fillB)
OR recipeA mixer_agitate)
stateB

[**** 0010 ***] T ((RecipeB mixer_empty

AND recipeB reactor cool _charge)
OR recipeB reactor _cool)
cool

220
 9.7 Other Analysis Approaches

StateA corresponds to the six upper rows in the previous table and stateB
corresponds to the six lower rows. The receptivities in the reduced su-
pervisor can now be rewritten using these conditions. The receptivity of
transition T1 is shown in Figure 9.25.

T1, a transition
Event
Condition ((recipeA mixer_empty AND recipeA reactorheat _charge)
OR recipeA reactor heat _heat)
AND
((recipeB mixer_fillA AND recipeB mixer_fillB)
OR recipeB mixer_agitate)

Figure 9.25 Receptivity of transition T1 in the reduced supervisor shown in Fig-

ure 9.24.

As can be seen the receptivities of the reduced supervisor becomes more

complex than the receptivities of the reachability graph based supervi-
sory. However, the size of the supervisor is drastically reduced.
In Chapter 9.5 (Static Deadlock Prevention), a table was shown indicating
the risk-of-deadlocks for different combinations of batches and plant
configurations, see Figure 9.13. The most intricate combination is the one
corresponding to the first column and the upper row in the table, i.e., 2
type A batches and two type B batches produced in a plant that consists of
three mixers, 1 reactorheat and two reactorcool. The reachability graph for
this combination has 85 states. Constructing a supervisor that resembles
the reachability graph would result in a large supervisor. However, a
closer look at the reachability graph shows that there are only three states
that are of interest, and the size of the supervisor can be reduced to five
states.

9.7 Other Analysis Approaches

The analysis method presented earlier in this chapter is based on Petri

nets. There do also exist other analysis methods that might be of interest
also for batch recipe applications.

Bankers Algorithm
An algorithm commonly used for resource allocation in real-time systems
is Banker's algorithm. The algorithm is used for deadlock-avoidance,
[Silberschatz and Galvin, 1995]. When a new process enters the system it
must declare the maximum number of instances of each resource type that

221
Chapter 9. Recipe Analysis

it might need. This number may not exceed the total number of resources
in the system. When a process requests a set of resources, the system
must determine whether the allocation of these resources will leave the
system in a safe state. If so, the resources are allocated, otherwise, the
process must wait until some other process releases enough resources.
Ideas from this algorithm might be useful for a deadlock-detection system
within a recipe management system.

Modular Control by Tittus et al.

The two recipes, recipe-A and recipe-B, presented in this chapter run in
the same plant. The plant configuration is given in Figure 9.1. Between
the units valve batteries are placed, see Figure 7.10. Thanks to the matrix
structure of the valve batteries there is a separate connection line, i.e.,
set of valves, pumps and pipes, between every two units. A connection
line is reserved only when the two units it connects are reserved. This
means that there will never be any problems allocating a connection line,
neither must a connection line be left unreserved in order for another con-
nection line to work properly. In a plant with such a generous connection
line structure, a deadlock situation can never occur due to the connection
lines and it is therefore enough to take only the units into account when
doing deadlock analysis. However, this is not the case in all batch plants.
Plants exist where both units and connection lines have to be reserved and
unreserved while running the batch. This increases the complexity of the
analysis methods. The methods developed by Tittus et al., [kesson and
Tittus, 1998] and [Tittus, 1995] take this constraint into consideration.
The methods developed by Tittus et al. are based on Petri net theory.
The resources in a plant are divided into two generic classes; processes,
e.g., reactors and pumps, and transport devices, e.g., pumps and valves.
A connection line is defined as the set of required transport devices in
order to connect a source processor with a target processor. When the
batch should be moved from one processor (unit) to another processor
(unit), the two processors (units) as well as the connection line must
be reserved. The task of the supervisor is to prevent deadlock situations
from occurring. Deadlocks can occur when allocating processors or when
allocating transport devices. The two problems are independent from each
other which makes it possible to split the supervisor into two modules,
one which restricts the booking of processors (S -module), and one which
restricts the booking of transport devices (T -module), see Figure 9.26.
In the method developed by Tittus et al. each batch has a correspond-
ing device dependent recipe which contains all possible execution path
through the plant. The recipe is modeled by a Petri net where each oper-
ation is modeled by one place, and the transitions correspond to booking

222
 9.7 Other Analysis Approaches

Plant

T Specification S

Supervisor

Figure 9.26 Supervisor structure according to Tittus et al..

or unbooking of processors or connection lines. The different recipes are

interleaved with each other, i.e., they are run independently of each other.
A specification is defined as all possible interleavings of the recipes. In
addition to this each processor and transport device is modeled by a sep-
arate Petri net. The states indicate if the processor/transport device is
unbooked or booked, i.e., if it is available or unavailable for a batch.

The T -module removes the circular wait between resources in the trans-
porting system by ordering all transport devices and guaranteeing that
all transport devices in a connection line are booked in this order. The
booking order is specified by a Petri net. This Petri net is synchronized
with the recipes, i.e., transitions with the same label acts as if they were
the same transition (i.e. they all fire simultaneously, but only if the input
places in all Petri nets can be fired). By assuring that no circular wait
can occur, the T -module is deadlock free, and a deadlock can therefore
not occur within the transporting system.

The S -module is constructed in the following way. A Petri net describ-

ing the plant is constructed. All different recipes are combined into one
large Petri net. The plant Petri net and the large recipe Petri net are
synchronized, i.e., transitions with the same label are assumed to be the
same transition. This results in a very large Petri net expressing all phys-
ically possible ways of executing the different operations in the plant. This
Petri is now translated into automata representation. A discrete supervi-
sor that coordinates and controls the execution of the different recipes is
algorithmically synthesized (exhaustive search).

223
Chapter 9. Recipe Analysis

9.8 Resource Allocation and Scheduling

The methods presented in this chapter only serve to prevent resource
allocation if it can lead to a deadlock situation. If there are several paths
through the plant, it is not the task of these methods to choose the optimal
one among them. The task of optimization, most often with respect to
time, is instead assured by a scheduling algorithm, see Chapter 6.4. As
was shown in Chapter 6.4 scheduling is a wide concept that can be broken
down hierarchically, according to Figure 6.5. The bottom-most level in the
scheduling hierarchy deals with resource allocation and arbitration.

9.9 Summary
A recipe structured with Grafchart can be transformed into a correspond-
ing 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 deadlock-freeness can be investigated. As shown in
this chapter 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 results of the deadlock analysis
can be used in different ways. Static reasoning deals with the question of
which combinations of number of batches and number of units that can be
safely started in the plant at the same time. The answer to this question
can, e.g., be stored in a table. Dynamic reasoning is about determining,
depending on the status of the plant, which units that are unsafe to al-
locate and therefore not should be reserved by a batch, i.e., to find the
unsafe states. To assure that the system never reaches an unsafe state
a supervisor can be used. In the chapter it is shown how the supervisor
can be constructed from the reachability graph and how the size of the
supervisor can be reduced.

224
10
Conclusions

In this thesis a graphical language for sequential control is presented and

its application to batch control is examined and discussed.
Graphical programming languages have many advantages compared to
textual programming languages. They often allow programming in a style
that closely mimics the style that people model problems. Graphical lan-
guages fit users existing perception of a problem, making the application
easier to build, debug, document, and maintain. An added benefit is the
possibility to use color and animation to provide feedback as the program
executes. Graphical programming languages have always been popular
in the automatic control community, e.g., in the form of relay diagrams
or function block diagrams. Sequential logic is commonly represented by
SFC/Grafcet, a graphical language that has its roots in automata theory
and Petri nets. The state machine and Petri net formalisms are also com-
monly used in the context of formal methods for analysis of discrete event
systems.
Grafchart is the name of a graphical language for sequential control ap-
plications. The main aim of Grafchart is to show how SFC/Grafcet can
be modified from a rather low-level graphical language into a high-level,
object-oriented graphical language. Two versions of Grafchart exist; the
basic version that is strongly related to SFC/Grafcet, and the high-level
version that has more in common with high-level Petri nets. The main new
concepts in the basic version of Grafchart are parameterization, methods
and message passing and exception handling facilities. These concepts
are common in textual languages, but not so often found in graphical lan-
guages. The features increase the possibilities to reuse programs from one
application to another. In the high-level version the new features are the
support for object tokens and multi-dimensional charts. These features
have been inspired by concepts found in the object-oriented programming
and high-level Petri net area. The features greatly increase the abstrac-
tion and structuring possibilities of the language. This makes it possible to

225
Chapter 10. Conclusions

use Grafchart not only for simple local level control applications, but also
for more demanding applications on the supervisory control level. Since
Grafchart is based on Grafcet and Petri nets, it is possible to transform a
Grafchart program into a Petri net and/or a Grafcet. Hence, it is possible
to apply the formal analysis methods developed for Petri nets and Grafcet
also to Grafchart.
Grafchart is a general-purpose language that has been used in several
different application. The topic of this thesis is recipe-based batch con-
trol. In the thesis it has been shown how Grafchart can be used for recipe
structuring and recipe analysis. By using the features of Grafchart in
various ways, recipes can be given different structures with different ad-
vantages and disadvantages. All structures comply with the international
batch standard IEC 61512-1 (also refered to as ISA S88.01). To test and
evaluate the different recipe structures a real-time simulation model of a
batch cell was used. The different features introduced in Grafchart have
many advantages in the context of recipe-based batch control.

The parameterization feature makes it easy to reuse existing recipe

structures and facilitates modifications of already existing recipe
structures.
By utilizing the method and message feature, the linking between
the procedural elements of the control recipe and the equipment, is
easily represented and implemented.
The object token and the multi-dimensional chart features make it
possible to have a compact, but yet clear, description and visualiza-
tion of the recipe execution and of the overall status in the plant.
Batch recipes and resource allocation can be combined. The com-
bined Grafchart network can be translated into an equivalent Petri
net and analyzed in order to look for possible deadlock situations.
The results can be used for static deadlock prevention or dynamic
deadlock avoidance.

Several commercial batch control systems exist today. They all have a
similar approach to recipe structuring, resource allocation and user pre-
sentation. The advantages of using Grafchart compared to some of these
systems, regarding these features are presented in the thesis. Grafchart
allows, e.g., the operator to have a graphical view of the overall status
in the plant as well as of the resource allocation. Analysis of the recipes
can be performed in order to look for possible deadlock situations caused
by improper resource allocation. By using Grafchart it is also possible to
implement all layers in the recipe procedure using the same language.

226
 10.1 Future Research Directions

Grafchart is currently implemented in G2, an object-oriented real-time

programming environment with a strong graphical appeal. Since G2 is
used in industry the step towards industrial application of the results
presented in this thesis is relatively small. However, the Grafchart-based
batch control system lacks several important features that are needed in a
real system, e.g., data logging and report generation. Hence, it should pri-
marily be seen as a source of inspiration for the developer of future batch
control systems. An example of this is that the results presented in this
thesis has attracted a lot of interest from the ISA S88.01 standardization
committee.

10.1 Future Research Directions

The current work can be continued in several directions. They can be

divided into topics that concern the Grafchart model and implementation,
and topics that concern the batch control application.

Implementation Improvements
The G2 implementation of Grafchart can still be viewed as a prototype.
Several modifications are possible. It would be relatively easy to change
the local interpretation algorithm into a global algorithm. With this mod-
ification the semantics of Grafchart would become closer to the Grafcet
semantics. The syntax for step actions and receptivities needs improve-
ments. New language elements could be considered. The main hierarchi-
cal construct of Grafchart, the macro step, is very procedural in nature. A
macro step may only have one entry point, i.e., one enter step. A result of
this is that it becomes cumbersome to represent truly hierarchical steps
with multiple entry points. This is often practical to have when Grafchart
is used for representing state machines. A possibility would be to define
a new super step that may have multiple entry and exit points, similar
to the super state of Statecharts.

Alternative Implementation Platforms

G2 has been a very convenient implementation platform for Grafchart.
The main features that have been utilized are the object-orientation and
the graphical support. However, G2 is still not widely spread. An alterna-
tive implementation platform that shares many of the advantages of G2
is Java. Java is object-oriented and has good graphics support. Further-
more, Java is platform-independent and supports distributed execution.
The current strong trend towards using Java also in process automation
makes it a very strong candidate as a new platform for Grafchart.

227
Chapter 10. Conclusions

Batch Scheduling
The current recipe management system performs dynamic resource al-
location. By applying analysis methods one can find out when and why
deadlock situations can occur. Statical deadlock prevention or dynamical
deadlock avoidance can be used in order not to get caught in an unde-
sired deadlock situation. However, the task of allocating the resources in
an optimal way, most often with respect to time, is not considered. This
task should instead be assured by a scheduling algorithm.

Monitoring of Recipe-Based Batch Production

Monitoring of recipe-based batch control is an interesting area. In recipe-
based batch control, the monitoring consists of monitoring of the equip-
ment, similar to the situation in continuous processes, and monitoring
of the recipe execution. The current recipe execution system contains no
guarantees that ensure that a recipe is well-formulated in the sense that
the sequence of operations and phases in the recipe is physically possible,
considering the capabilities of the equipment units. For example, a recipe
might start with a discharge phase, or perform a heating phase in a reac-
tor before the reactor has been charged. This problem can be attacked in
two ways. One possibility is to check the recipes off-line. This is perhaps
the most realistic alternative. However, alternatively or in addition, one
could also have an on-line check that tests that the equipment is in an
allowed state before a new recipe phase is started. Also, the current recipe
execution system contains no equipment monitoring. Faults may occur in
an equipment unit both when it is used by a batch and when it is free. The
equipment monitoring is normally taken care of by safety and alarm logic
associated with the equipment. A fault can be seen as a change in state
of the equipment. The safety logic responsible for detecting the fault can
be seen as a conditional test that initiates a state change from a normal
state to a faulty state.
The above forms of on-line monitoring can be combined if an internal
model approach is taken. Each equipment unit contains a state machine
that models the equipment state. The safety logic can be represented as
transition conditions in this state machine. The state machine may be a
single automaton or decomposed into several smaller automata. Associ-
ated with each equipment phase is a set of allowed pre-condition states.
A phase may only be started if the current active state belongs to the
precondition states of the phase. Executing a phase corresponds to mov-
ing from a initial state, through a number of intermediate states, to a
final state. Grafchart, possibly extended with the super step construct,
could be used also for representing the equipment state machine. This
would provide an interesting combination where Grafchart is used both

228
 10.1 Future Research Directions

to represent the recipe procedures, the equipment control logic, and the
equipment monitoring system.

229
11
Bibliography

AGAOUA, S. (1987): Spcification et commande des systmes vnements

discrets, le Grafcet color. PhD thesis, Institut National polytechnique
de Grenoble.
KESSON, K. and M. TITTUS (1998): Modular control for avoiding deadlock
in batch processes. In WBF98 World Batch Forum.
ALSOP, N., L. CAMILLOCCI, A. SANCHEZ, and S. MACCHIETTO (1996):
Synthesis of procedural controllers - applications to a batch pilot
plant. Computers and Chemical Engineering, 20:972.
ARC (1996): Batch process automation strategies. Industrial Automa-
tion Strategies for Executives. Automation Research Corporation,
Memorandum.
RZN, 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.
RZN, K.-E. (1993): Grafcet for intelligent real-time systems. In
Preprints IFAC 12th World Congress. Sydney, Australia.
RZN, K.-E. (1994a): Grafcet for intelligent supervisory control applica-
tions. Automatica, 30:10, pp. 1513 1525.
RZN, 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.
RZN, K.-E. (1996): A sequential function chart based approach to alarm
filtering. In Preprints 13th IFAC World Congress, vol. M, pp. 235
241.
RZN, K.-E. and C. JOHNSSON (1996a): Object-oriented SFC and ISA-
S88.01 recipes. In WBF96World Batch Forum. Toronto, Canada.

230
RZN, K.-E. and C. JOHNSSON (1996b): Object-oriented SFC and ISA-
S88.01 recipes. ISA Transactions, 35, pp. 237244.
RZN, K.-E. and C. JOHNSSON (1997): Grafchart: a Petri net/Grafcet
based graphical language for real-time sequential control applica-
tions. In SNART97The Swedish National Real-Time Systems Con-
ference, Lund.
BASTIDE, R., C. SIBERTIN-BLANC, and P. PALANQUE (1993): Cooperative
Objects: A concurrent, Petri-net based, object-oriented language. In
Proceeding of IEEE Conference on Systems, Man and Cybernetics. Le
Touquet, France.
BATTISTON, E., F. DE CINDIO, and G. MAURI (1988): OBJSA: A class of high
level nets having objects as domains. In ROZENBERG, Ed., Advances in
Petri Nets 1988, vol. 340 of Lecture notes in computer science, pp. 20
43. Springer Verlag, Berlin Heidelberg, New York.
BERTHELOT, G. (1983): Transformation et analyse de rseaux de Petri:
Application aux protocoles. PhD thesis, Nice University.
BERTHELOT, G. (1986): Checking properties of nets using transforma-
tions. In Lecture notes in Computer Science, vol. 222, pp. 19 40.
Springer Verlag.
BRETTSCHMEIDER, H., H. GENRICH, and H. HANISCH (1996): Verification
and performance analysis of recipe based controllers by means of dy-
namic plant models. In Second International Conference on Computer
Integrated Manufacturing in the Process Industries. Eindhoven, The
Netherlands.
BURNS, A. and A. WELLINGS (1996): Real-time systems and programming
languages. Addison-Wesley.
CASSANDRAS, C. (1993): Discrete Event Systems: Modeling and Perfor-
mance Analysis. Irwin.
CHARBONNIER, F. (1996): Commande supervise des systmes vne-
ments discrets. PhD thesis, Institut National Polytechnique de Greno-
ble.
CHARBONNIER, F., H. ALLA, and R. DAVID (1995): The supervised control of
discrete event dynamic systems: A new approach. In 34th Conference
on Decision and Control. New Orleans.
DAVID, R. (1995): Grafcet: A powerful tool for specification of logic
controllers. IEEE Transactions on Control Systems Technology, 3:3,
pp. 253268.

231
Chapter 11. Bibliography

DAVID, R. and H. ALLA (1992): Petri nets and Grafcet: Tools for modelling
discrete events systems. Prentice-Hall International (UK) Ltd.
DE LOOR, P., J. ZAYTOON, and G. VILLERMAIN-LECOLIER (1997): Abstrac-
tions and heuristics for the validation of Grafcet controlled system.
JESA European Journal of Automation, 31:3, pp. 561580.
DESROCHERS, A. A. and R. ALJAAR (1995): Applications of Petri nets in
manufacturing systems: Modelling, control and performance analysis.
IEEE Press.
DIJKSTRA, E. (1968): Cooperating sequential processes. In GENUYS, Ed.,
Programming languages. Academic Press N.Y.
ENGELL, S. and K. WLLHAF (1994): Dynamic simulation for improved
operation of flexible batch plants. In Proc. CIMPRO 94, pp. 441455.
Rutgers University, New Jersey, USA.
FISHER, T. G. (1990): Batch Control Systems: Design, Application, and
Implementation. Instrument Society of America, Research Park, NC.
FLEISCHHACK, H. and U. LICHTBLAU (1993): MOBY - A tool for high level
Petri nets with objects. In Proceeding of IEEE Conference on Systems,
Man and Cybernetics. Le Touquet, France.
GAFFE, D. (1996): Le modle Grafcet: Rflextion et intgration dans une
plate-forme multiformalisme synchrone. PhD thesis, Universit de
Nice-Sophia Antipolis.
GENRICH, H. J., H.-M. HANISCH, and K. WLLHAF (1994): Verification of
recipe-based control procedures by means of predicate/transition nets.
In 15th International Conference on Application and Theory of Petri
nets, Zaragoza, Spain.
GENSYM COORPORATION (1995): G2 Reference Manual, Version 4.0. Gen-
sym Coorporation, 125 Cambridge Park Drive, Cambridge, MA 02140,
USA.
GUNNARSSON, J. (1997): Symbolic Methods and Tools for Discrete Event
Dynamic Systems. PhD thesis, Linkping University.
HANISCH, H.-M. and S. FLECK (1996): A resource allocation scheme for
flexible batch plants based on high-level Petri nets. In IEEE SMC,
CESA96. Lille, France.
HARPER, R. (1986): Introduction to standard ML. Technical Report. Dept.
of Computer Science, University of Edinburgh. ECS-LFCS-86-14.
HO, Y. (1991): Discrete Event Dynamic Systems: Analyzing Complexity
and Performance in the Modern World. IEEE Press, New York.

232
HOLLOWAY, L. and B. KROGH (1990): Synthesis of feedback control logic
for a class of controlled Petri nets. IEEE Transactions on Automatic
Control, 35:5, pp. 514523.
HOLLOWAY, L. and B. KROGH (1994): Controlled Petri nets: A tutorial sur-
vey. In 11th International Conference on Analysis and Optimization
of Systems - Discrete Event Systems. Springer-Verlag. number 199
in Lecture Notes in Control and Information Science, pages 158-168,
DES94, Ecole des Mines de Paris, INRIA.
IEC (1988): IEC 60848: Preparation of function charts for control
systems. Technical Report. International Electrotechnical Commissio.
IEC (1993): IEC 61131 programmable controllers - part 3: Programming
languages. Technical Report. International Electrotechnical Commis-
sion.
IEC (1997): IEC 61512-1: Batch control, part1, models and termonology.
Technical Report. International Electrotechnical Commission.
ISA (1995): ISA S88.01 batch control. Instrument Society of America.
JENSEN, K. (1981): Coloured Petri Nets and the invariant method.
Theoretical Computer Science, North-Holland, 14, pp. 317336.
JENSEN, K. (1990): Coloured Petri nets: A high level language for system
design and analysis. In ROZENBERG, Ed., Advances in Petri Nets 1990,
vol. 483 of Lecture notes in Computer Science, pp. 342416. Springer
Verlag, Berlin Heidelberg, New York.
JENSEN, K. (1992): Coloured Petri Nets. Basic Concepts, Analysis Methods
and Practical Use., vol. 1, Basic Concepts. Springer-Verlag.
JENSEN, K. (1995): Coloured Petri Nets. Basic Concepts, Analysis Methods
and Practical Use., vol. 2, Analysis Methods. Springer-Verlag.
JENSEN, K. (1997): Coloured Petri Nets. Basic Concepts, Analysis Methods
and Practical Use., vol. 3, Practical Use. Springer-Verlag.
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. RZN (1994): High-level Grafcet and batch
control. In Symposium ADPM94Automation of Mixed Processes:
Dynamical Hybrid Systems. Brussels, Belgium.

233
Chapter 11. Bibliography

JOHNSSON, C. and K.-E. RZN (1996a): Batch recipe structuring using

high-level Grafchart. In IFAC96, Preprints 13th World Congress of
IFAC. San Francisco, California.
JOHNSSON, C. and K.-E. RZN (1996b): Object tokens in high-level
Grafchart. In CIMAT96Computer Integrated Manufacturing and
Automation Technology. Grenoble, France.
JOHNSSON, C. and K.-E. RZN (1998a): Grafchart and batch recipe
structures. In WBF98 World Batch Forum. Baltimore, ML, USA.

JOHNSSON, C. and K.-E. RZN (1998b): Grafchart and its relations to

Grafcet and Petri nets. In Symposium INCOM98 Information
Control Problems in Manufacturing. Nancy, France.
JOHNSSON, C. and K.-E. RZN (1998c): Grafchart applications. In
GUS98 Gensym User Society meeting. Newport, RI, USA.
JOHNSSON, C. and K.-E. RZN (1998d): Grafchart for recipe-based batch
control. Computers and Chemical Engineering, 22:12, pp. 1811
1828.

JOHNSSON, C. and K.-E. RZN (1998e): On batch recipe structures using

High-Level Grafchart. In Symposium ADPM98 Automation of
Mixed Processes: Dynamical Hybrid Systems. Reims, France.
JOHNSSON, C. and K.-E. RZN (1998f): On batch recipe structuring and
analysis using Grafchart. European Journal of Automation. To appear.

JOHNSSON, C. and K.-E. RZN (1998g): Petri net analysis of batch recipes
structured with Grafchart. In FOCAPO98Foundations of Computer
Aided Process Operations.
JOHNSSON, C. and K.-E. RZN (1999a): Grafchart and batch recipe
structures. In Interphex99. New York, NY, USA.

JOHNSSON, C. and K.-E. RZN (1999b): Grafchart and Grafcet: A

comparison between two graphical languages aimed for sequential
control applications. In Ifac99. Beijing, China.

KLUGE, W. and K. LAUTENBACH (1982): The orderly resolution of memory

access conflicts among competing channel processes. IEEE Trans.
Comp., C-31:2, pp. 194207.
LAKOS, C. (1994): Object Petri nets - definitions and relationship to
coloured nets. Technical Report R94-3. Dept. of Computer Science,
University of Tasmania.

234
LAKOS, C. and C. KEEN (1994): Loopn++: A new language for object-
oriented Petri nets. Technical Report R94-4. Dept. of Computer
Science, University of Tasmania.
LOPEZ GONZLEZ, J. M., J. I. LLORENTE GONZLEZ, J. M. SANTAMARIA
YUGUEROS, O. PEREDA MARTINEZ, 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.
MEALY, G. (1955): A method for synthesizing sequential circuits. Bell
System Technical Journal, 5:34, pp. 10451079.
META SOFTWARE CORPORATION, Cambridge, MA,USA (1993): Design/CPN
Tutorial for X-Windows. version 2.0.
MOALLA, M. (1985): Rseaux de Petri interprts et Grafcet. Technique
et Science Informatique, 14:1.
MOLLOY, M. (1982): Performance analysis using stochastic Petri nets.
IEEE Trans. Computers, C-31:9, pp. 913917.
MOORE, E. (1956): Gedanken experiments on sequential machines.
Automata Studies, pp. 129153. Princeton University Press.
MURATA (1989): Petri nets: Properties, analysis and applications. Pro-
ceedings of the IEEE, 77:4, pp. 541 580.
MURATA, T. and J. KOH (1980): Reduction and expansion of live and safe
marked graphs. IEEE Transactions on Circuit Systems, 27:1, pp. 68
70.
MURATA, T., N. KOMODA, K. MATSUMOTO, and K. HARUNA (1986): A Petri
net-based controller for flexible and maintainable sequence control
and its application in factory automation. IEEE Transaction Ind.
Electron., 33:1, pp. 18.
NAMUR (1992): NAMUR-Emphehlung: Anforderungen an Systeme zur
Rezeptfaheweise (Requirements for Batch Control Systems). NAMUR
AK 2.3 Funktionen der Betriebs- und Produktionsleitebene.
NILSSON, B. (1991): En on-linesimulator fr operatrsstd, (An on-line
simulator for operator support). Report TFRT-3209. Department of
Automatic Control, Lund Institute of Technology.
OZSU, M. (1985): Modelling and analysis of distributed database concur-
rency control algorithms using an extended Petri net formalism. IEEE
Transaction Software Engineering, SE-11:10, pp. 12251240.

235
Chapter 11. Bibliography

PETERSON, J. (1981): Petri net theory and the modeling of systems.

Prentice-hall.
PETRI, C. A. (1962): 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. 1, Suppl. 1, 1966.
RAMADGE, P. and W. WONHAM (1989): The control of discrete event
systems. In Proceedings of the IEEE, vol. 77, pp. 8198.
ROSENHOF, H. P. and A. GHOSH (1987): Batch Process Automation, Theory
and Practice. Van Nostrand Reinhold.
ROUSSEL, J.-M. and J.-J. LESAGE (1996): Validation and verification of
Grafcets using state machine. In CESA96 IMACS/IEEE Symposium
on Discrete Events and Manufacturing Systems, pp. 765770. Lille,
France.
SANCHEZ, A., G. ROTSTEIN, and S. MACCHIETTO (1995): Synthesis of
procedural controllers for batch chemical processes. In Proc. of 4th
IFAC Symposium on Dynamics and Control of Chemical Reactors,
Distillation Columns and Batch Processes (DYCORD+95), Denmark.
SHAW, W. (1982): Computer Control of Batch Processes. EMC Controls
Inc, Cockeysville, MD.
SIFAKIS, J. (1978): Use of Petri nets for performance evaluation. Acta
cybernet., 4:2, pp. 185202.
SILBERSCHATZ, A. and P. GALVIN (1995): Operating System concepts.
Addison-Wesly.
SILVA, M. and E. TERUEL (1996): Petri nets for design and operation of
manufacturing systems: An overview. In First International Work-
shop on Manufacturing and Petri Nets, Osaka Japan, International
Conferences on Application and Theory of Petri Nets (ICATPN96). Uni-
versidad de Zaragoza, Spain.
SILVA, M. and S. VELILLA (1982): Programmable logic controllers and
Petri nets: A comparative study. In IFAC Software for Computer
Control, Madrid, Spain, pp. 8388. Ferrate, G. and Puente, E.A.,
Pergamont Press, Oxford England.
SIMENSEN, J., C. JOHNSSON, and K.-E. RZN (1996): A framework for
batch plant information models. Report ISRN LUTFD2/TFRT--7553-
-SE. Department of Automatic Control, Lund Institute of Technology,
Lund, Sweden.

236
SIMENSEN, J., C. JOHNSSON, and K.-E. RZN (1997a): A multiple-view
batch plant information model. In PSE97/ESCAPE-7. Trondheim,
Norway.
SIMENSEN, J., C. JOHNSSON, and K.-E. RZN (1997b): A multiple-view
batch plant information model. Computers and Chemical Engineer-
ing, 21:1001, pp. 1209 1214.
SONNENSCHEIN, M. (1993): An introduction to Gina. In Proceding of
IEEE Conference on Systems, Man and Cybernetics. Le Touquet,
France.
SUAU, D. (1989): Grafcet color: Conception et realisation dun outil de
generation de simulation et de commande temps rel. PhD thesis,
Universite de Monpellier.
TITTUS, M. (1995): Control Synthesis for Batch Processes. PhD thesis,
Chalmers University of Technology.
TURBAK, F., D. GIFFORD, and B. REISTAD (1995): Applied semantics of
programming languages.. Unpublished Draft.
VALETTE, R., M. COURVOISIER, J. BEGOU, and J. ALBUKERQUE (1983): Petri
net based programmable logic controllers. In 1st Int. IFIP conference:
Comp. appl. in production and engineering, pp. 103116.
VISWANATHAN, S., C. JOHNSSON, R. SRINIVASAN, V. VENKATASUBRAMANIAN,
and K.-E. RZN (1998a): Automating operating procedure synthesis
for batch processes: Part 1. Knowledge representation and planning
framework. Computers and Chemical Engineering, 22:11, pp. 1673
1685.
VISWANATHAN, S., C. JOHNSSON, R. SRINIVASAN, V. VENKATASUBRAMANIAN,
and K.-E. RZN (1998b): Automating operating procedure synthesis
for batch processes: Part 2. Implementation and application. Comput-
ers and Chemical Engineering, 22:11, pp. 1687 1698.
VISWANATHAN, S., V. VENKATASUBRAMANIAN, C. JOHNSSON, and K.-E. RZN
(1996): Knowledge representation and planning strategies for batch
plant operating procedure synthesis. In AIChE annual meeting,
Chicago, USA.
WILLIAMS, T. (1988): A reference model for Computer Integrated Man-
ufacturing (CIM). In International Purdue Workshop on Industrial
Computer Systems, ISA.
YAMALIDOU, E. C. and J. C. KANTOR (1991): Modeling and optimal control
of discrete-event chemical processes using Petri nets. Computers
Chem. Engng, 15, pp. 503519.

237
Chapter 11. Bibliography

YOELI, M. (1987): Specification and verification of asynchronous circuits

using marked graphs. In Concurrency and Nets, pp. 605622.

238
A
Abbreviations

AFCET Association Francaise pour la Cyberntique

Economique et Technique
AFNOR Association Francaise de NORmalisation
ANSI American National Standards Institute
DCS Distributed Control System
DEDS Discrete Event Dynamic System
DES Discrete Event System
ERP Enterprise Resource Planning
GMP Good Manufacturing Practive
IEC International Electrotechnical Commission
ISA Instrument Society of America
MES Manufacturing Execution System
MRD Material Resource Planning
OCS Open Control Systems
PCT Procedural Control Theory
PFC Procedural Function Charts
PLC Programmable Logic Controller
PN Petri Nets
SCT Supervisory Control Theory
SFC Sequential Function Charts
SPC Statistical Process Control

239
B
Petri Net Reduction Methods

Four reduction rules exist that preserve the properties: live, bounded,
safe, deadlock-free, with home state and conservative, [Murata and Koh,
1980].

1. Reduction R 1 : Substitution of a place

2. Reduction R 2 : Implicit place
3. Reduction R 3 : Neutral transition
4. Reduction R 4 : Identical transitions

Two reduction methods exist that preserve the invariants, [Berthelot,

1986].

1. Reduction R a : Self loop transitions

2. Reduction R b : Pure transitions

A presentation of the reduction methods can be found in [David and Alla,

1992].
In this appendix, only the reduction methods R 1 , R 2 , R 3 and R 4 are
presented. The reduction methods are presented for ordinary PN but they
can be applied to generalized PN as well, assumed some adaptations are
made. The properties have been proved by [Berthelot, 1983].
Reduction R 1: Substitution of a place
A place Pi can be substituted if it satisfies the following three conditions:

1. The output transitions of Pi have no other input places than Pi .

2. Place Pi is pure.
3. At least one output transition of Pi is not a sink transition.

240
Figure B.1 shows a simple case of place substitution. It is clear from the
figure that if transition T1 is fired then, sooner or later, transition T2 will
be fired and therefore place P2 can be removed. If place P2 is marked then
this token should be put in place P3 after substitution. If there are several
output places of transition T2, all the possible cases must be considered
and several different nets must be studied from now on.

P1 P1
T1 T12
R1
P2

T2
P3 P3

Figure B.1 Reduction R1 .

Reduction R 2 : Implicit place

A place is implicit if it satisfies the following conditions.

1. The marking of this place never forms an obstacle to the firing of its
output transitions.

2. Its marking can be deducedP from the marking of the other places
by the relation M ( Pi )
k6
i( k M ( Pk)) + , where k is a rational
number 0 and is a rational number.

An example of reduction rule R 2 is shown in Figure B.2.

P1 P1
R2
T1 P2 T1
P3 P3

Figure B.2 Reduction R2 .

241
Appendix B. Petri Net Reduction Methods

Reduction R 3: Neutral transition

A transition Tj is neutral if and only if the set of its input places is
identical to the set of its output transitions, i.e., Tj
Tj . A neutral
transition can be suppressed if and only if a transition Tk 6
Tj exists
such that Post( Pi) Pre( Pi , Tj ) for every place Pi Tj . An example of
reduction rule R 3 is shown in Figure B.3.

T1 T3 T1 T3

T5 R2
P1 P2 P1 P2
T2 T4 T2 T4

Figure B.3 Reduction R3 .

Reduction R 4: Identical transitions

Two transitions Tj and Tk are identical if they have the same set of input
places and the same set of output places, i.e., Tj
Tj and Tj
Tk . An
example of reduction rule R 4 is shown in Figure B.4.

P1 P2 P1 P2
R3

P3 P3

Figure B.4 Reduction R4 .

242
C
Formal Definition of
Grafchart

A programming language is fully defined by its syntax, semantics and

pragmatics. The syntax defines the form of the languages, the semantics
defines the meaning of the languages and the pragmatics defines the im-
plementation of the languages, [Turbak et al., 1995]. If the pragmatics is
omitted the programming language is reduced to a model.
In this chapter the syntax of Grafchart is formally presented.

Syntax
The syntax focuses on the notations used to encode a programming
language. Consider a program, that indicates that the variable C

1 should be increased by 2 if x < 10 and increased by 5 if x 10.
Such a program can be written in many different notations:
as a Pascal program
program Increase-C (C,x)
begin
var C= integer;
x = real;
begin
C:= 1;
if x < 10 then
C := C+2
else
C := C+5;
end;
end

243
Appendix C. Formal Definition of Grafchart

or as a Grafchart function chart, see Figure C.1.

x1

T1
x2 Initially
conclude that C = 1

T2 T3

Initially x3 x4 Initially
conclude that C = C+2 conclude that C = C+5

T4 T5

x5

T1, a transition T2, a transition T3, a transition T4, a transition T5, a transition

Event Event Event Event Event

Condition true Condition x<10 Condition x>10 Condition true Condition true

Figure C.1 A Grafchart function chart.

Although the notation used in the two programs are very different
they are both a description of the abstract phrase: increase the vari-
able C
1 by 2 if x < 10 and by 5 if x 10. The syntax describes
the relationship between a notation and an abstract phrase.
If the language is a graphical language the notation is mainly graph-
ical. The graphical elements together with the notation for step ac-
tions and transition receptivities constitute the syntax for Grafchart.
Semantics
The semantics specifies the mapping between the syntax of a pro-
gramming language and what the syntax means. A programming
language syntax has no meaning without an interpretation algo-
rithm used for interpreting the syntax. Consider for example the
Grafchart function chart shown in Figure C.1. The result of the pro-
gram will be totally different depending on if e.g., the execution
order is top-to-bottom or bottom-to-top, i.e., if step x1 or step x5 is
considered the initialstep.
The same programming language syntax can have many possible
meanings. The semantics describes the relationship between the pro-
gramming syntax and its meaning.
Pragmatics
The pragmatics focuses on how the meaning is computed, i.e, how
is the syntax and semantics implemented.

244
 C.1 Notation

This chapter contains a presentation of the formal definition of Graf-

chart. Section C.1 contains a presentation of notations that will be used
later in the chapter. Grafchart exists in two versions: Grafchart-BV and
Grafchart-HLV. However, Section C.2 introduces yet another version of
Grafchart: Grafchart the Grafcet version. This is a version of Grafchart
that is very close to Grafcet, i.e., there is no support for any advanced
features. The introduction of this version, and the presentation of its for-
mal definition, facilitates the understanding of the formal definitions for
Grafchart-BV, Section C.3, and Grafchart-HLV, Section C.4.

C.1 Notation

Notation useful later in this chapter are presented in this section. In

order to illustrate certain notations an object with three attributes and
two object methods is considered.
Attributes:

A ttr
{size, mixer, reactor}

attr1
size
attr2
mixer
attr3
reactor

The attributes are given the values

attr1
25
attr2
m1
attr3
sup.reactor
>
|{z} r2
during execution

Methods:

OM
{agitate, heat}
O M1
agitate
O M2
heat

245
Appendix C. Formal Definition of Grafchart

The methods are given the values

O M1
gp2
O M2
sup.reactor heat
>
|{z} r2 heat
during execution

Useful functions
Expr( b) gives the value of b.
Expr( attr1 )
25
Expr( attr2 )
m1
Expr( attr3 )
sup.reactor

Expr( O M1)
gp2

Expr( O M2)
sup.reactor heat

Eval ( b) evaluates an expression.

Eval ( sup.reactor)
r2
Eval ( Expr( attr3 ))
r2

Eval ( sup.reactor heat)
r2 heat

Eval ( Expr( O M2))
r2 heat

T ype( b) gives the type of the parameter b.

T ype( Expr( attr1 ))
T ype(25)
integer
T ype( Expr( attr2 ))
T ype( m1)
mixer
T ype( Eval ( Expr( attr3 )))
T ype( Eval ( sup.reactor))

T ype( r2)
reactor

T ype( Expr( O M1))
T ype( gp2)
Gra f chart procedure

T ype( Eval ( Expr( O M2)))
T ype( Eval ( sup.reactor heat)

T ype( r2 heat)
O bject method

Var( b) gives the variables used in the expression b.

Var( conclude that x
10)
x
T ype( Var( conclude that x
10))
T ype( x)
integer

246
 C.2 Grafchart the Grafcet version

C.2 Grafchart the Grafcet version

The most primitive version of Grafchart is achieved if all advanced fea-
tures are disregarded. Grafchart then becomes similar to Grafcet. In this
section, the formal definition of Grafchart - a Grafcet version is presented.

A Grafchart function chart can be defined as a 9-tuple

G
< V r , V a , X , T , M , P procedure, P process, GP , I >

where:
V r is the set of receptivities, V r
{ R 1, R 2 , }.
The set can be divided into two disjoint subsets, V ext and
V int . V ext is the set of receptivities containing variables
originating from the plant. V int is the set of receptivities
containing variables corresponding to the internal states
of the Grafchart.
V r can also be divided into three, not necessarily disjoint,
subsets.

V r
V rX V rM V rGP

V rX are the receptivities associated with the tran-

sitions not included in a macro step or a Grafchart
procedure.
V rM are the receptivities associated with the transi-
tions included in a macro step.
V rGP are the receptivities associated with the tran-
sitions included in a Grafchart procedure.
V a is the set of actions, V a
{ A1 , A2 , }.
V a can be divided into three, not necessarily disjoint, sub-
sets.

V a
V aX V aM V aGP
V aX are the actions associated with the steps not
included in a macro step or a Grafchart procedure.
V aM are the actions associated with the steps in-
cluded in a macro step.
V aGP are the actions associated with the steps in-
cluded in a Grafchart procedure.

247
Appendix C. Formal Definition of Grafchart

X is the set of steps, X
{ x1 , x2 , x3 , ...}.

A step x X is defined by

{action}

action( x) is the actions associated with x,

action( x) V aX .
T is the set of transitions, T
{t1 , t2 , t3 , ...}.
A transition t T is defined by the 3-tuple:

{XP R , X F O , }

X P R ( t) is the set of previous steps of t,

X P R ( t) X M P procedure P process
X F O ( t) is the set of the following steps of t,
X F O ( t) X M P procedure P process
( t) is the receptivity associated with t,
( t) V rX .
M is the set of macro steps, M
{ M1, M2 , }.
V rM is the set of receptivities associated with the
transitions in M
V aM is the set of actions associated with the macro
steps and the steps in M .
P procedure is the set of procedure steps, P
{ P1 , P2 , }.
The name of the procedure that should be called from the
procedure step is given by Procedure( Pi) GP .
P process is the set of process steps, P
{ P1 , P2 , }.
The name of the procedure that should be called from the
process step is given by Process( Pi) GP .
GP is the set of Grafchart Procedures, GP

{ GP1 , GP2 , } that can be called from the Grafchart.
V rGP is the set of receptivities associated with the
transitions in GP
V aGP is the set of actions associated with the Graf-
chart procedure and the steps in GP .
I is the set of initial steps, I X .

248
 C.2 Grafchart the Grafcet version

In order for the formal definition of Grafchart a Grafcet version to be

complete, a formal definition of macro steps, Grafchart procedures, recep-
tivities and actions has to be given.

(1) A macro step Mi is defined as a 10-tuple

Mi
< V ri , V ai , X i , T i , M i , P procedure,i, P process,i, GP i , Enteri , Exiti >

where:
V ri , V ai , X i , T i are defined as V r , V a , X , T , for a Grafchart.
M i is the finite set of macro steps, M i
{ Mi,1, Mi,2, }.
The macro steps are not allowed to be infinitely recursive.
The actions associated with a macro step Mi, j M i are
given by the set action( Mi, j ) V aM i .
V rM i
{V ri1 V ri2 }.
V aM i
{V ai1 V ai2 action( Mi1) action( Mi2)
}.
P procedure,i is the finite set of Procedure steps, P procedure

{ P1 , P2 }.
P process,i is the finite set of Process steps, P process

{ P1 , P2 }.
GP i are the set of Grafchart procedures that can be called
from Mi.
Enteri is the enter step of the macro step, Enteri X i .
Exiti is the exit step of the macro step, Exiti X i .

(2) A Grafchart procedure, GPi is defined by the 10-tuple

GPi
< V ri , V ai , X i , T i , M i , P procedure,i, P process,i, GP i , Enteri , Exiti >

where:
V ri , V ai , X i , T i are defined as V r , V a , X , T for a Grafchart.
M i is the finite set of macro steps, M i is defined as for a
Grafchart.

249
Appendix C. Formal Definition of Grafchart

P procedure,i is the finite set of Procedure steps, P procedure

{ P1 , P2 }.
P process,i is the finite set of Process steps, P process

{ P1 , P2 }.
GP i are the finite set of Grafchart procedures.
GP i
{ GPi,1 , GPi,2 , }. The calls to Grafchart proce-
dures are not allowed to be infinitely recursive.
The actions associated with a Grafchart procedure GPi, j
GP i are given by the set action( GPi, j ) V aGP i .
V rGP i
{V ri1 V ri2 }.
V aGP i
{V ai1 V ai2 action( GPi,1 )
action( GPi,2 ) }.
Enteri is the enter step of the Grafchart procedure,
Enteri X i .
Exiti is the exit step of the Grafchart procedure, Exiti
X i.

(3) A receptivity, R i is defined by the pair

R i
{event, condition}

where: event and condition are functions such that

event( R i )
any G2 event expression
condition( R i) any boolean G2 expression

(4) An action, Ai is defined by the pair

Ai
{actiontype, actiontext}

where: actiontype and actiontext are functions such that

actiontype( Ai) {initially, f inally, always, abortive}

actiontext( Ai ) any G2 rule action statement

250
 C.2 Grafchart the Grafcet version

EXAMPLE C.2.1
In order to illustrate how the formal definition can be used an example is
presented. Figure C.2 shows a Grafchart for which the formal definition
is given in this example.

x1 gp1x1

gp1T1 e
T1 a
gp1x2
x2
Initially A
gp1T2 b
Grafchart
T2 b procedure gp1x3
a process step
gp1
name P2 x3 P2
procedure gp2 Finally C

T3 c
a procedure step
P1 gp2x1
name P1
procedure gp1 gp2T1 e
gp2x2
T4 b
x4
Initially C gp2T2 a
Grafchart
procedure gp2x3
T5 ^| d gp2

T1, a transition T3, a transition T5, a transition gp1T1, a transition gp2T1, a transition
event event event d event event
condition a condition c condition condition e condition e

T2, a transition T4, a transition gp1T2 a transition gp2T2, a transition

event d event event event
condition b condition b condition b condition a

Figure C.2 A Grafchart function chart.

The Grafchart function chart in Figure C.2 is given by the tuple

G
< V r , V a , X , T , M , P procedure, P process, GP , I >

where:

V r
{V rX V rM V rGP }
V rX
{ R 1, R 2 , R 3 , R 4 , R 5 }
event( R 1)
condition( R 1)
a
event( R 2)
d condition( R 1)
b
event( R 3)
condition( R 1)
c
event( R 4)
condition( R 1)
b
event( R 5)
d condition( R 1)

251
Appendix C. Formal Definition of Grafchart

V a
{V aX V aM V aGP }
V aX
{ A1 , A2 , A3 }
actiontype( A1)
Initially actiontext( A1)
A
actiontype( A2)
F inally actiontext( A2)
C
actiontype( A3)
Initially actiontext( A3)
C

X
{ x1, x2, x3, x4}

action( x2)
A1 action( x3)
A2
action( x4)
A3

T
{T 1, T 2, T 3, T 4, T 5}
X P R ( T 1)
x1 X F O ( T 1)
x2 ( T 1)
R 1
X P R ( T 2)
x2 X F O ( T 2)
{ x3, P2} ( T 2)
R 2
X P R ( T 3)
x3 X F O ( T 2)
P1 ( T 3)
R 3
X P R ( T 4)
{ P1, P2} X F O ( T 4)
x4 ( T 4)
R 4
X P R ( T 5)
x4 X F O ( T 5)
x1 ( T 5)
R 5

M

P procedure
{ P1}
Procedure( P1)
gp1

P process
{ P2}
Process( P2)
gp2

GP
{ gp1, gp2}
V rGP
{V r gp1 V r gp2 }
V aGP
{V a gp1 V a gp2 }
I
x1

252
 C.2 Grafchart the Grafcet version

In order for the formal definition for the Grafchart function chart shown
in Figure C.2 to be complete, also the two Grafchart procedures named
gp1 and gp2 have to be formally defined.

The Grafchart Procedure gp1 in Figure C.2 is given by the tuple

gp1
< V r gp1 , Va gp1 , X , T , M , P procedure, P process, GP , I >

where:

Vr gp1
{R1 gp1 , R2 gp1 }

event( R 1 gp1 )

, condition( R 1 gp1 )

e
event( R 2 gp1 )
, condition( R 2 gp1 )
b

Va gp1

X
{ gp1x1, gp1x2, gp1x3}
T
{ gp1T 1, gp1T 2}
X P R ( gp1T 1)
gp1x1 X P R ( gp1T 2)
gp1x2
X F O ( gp1T 1)
gp1x2 X F O ( gp1T 2)
gp1x3
( gp1T 1)
R 1 gp1 ( gp1T 2)
R 2 gp1

M

P procedure

P process

GP

Enter
gp1x1
Exit
gp1x3

The Grafchart Procedure gp2 in Figure C.2 is given by the tuple

gp2
< V r gp2 , Va gp2 , X , T , M , P procedure, P process, GP , I >

where:

Vr gp2
{R1 gp1 , R2 gp1 }

event( R 1 gp2 )

, condition( R 1 gp2 )

e
event( R 2 gp2 )
, condition( R 2 gp2 )
a

253
Appendix C. Formal Definition of Grafchart

V a gp2

X
{ gp2x1, gp2x2, gp2x3}
T
{ gp2T 1, gp2T 2}
X P R ( gp2T 1)
gp1x1 X P R ( gp2T 2)
gp1x2
X F O ( gp2T 1)
gp1x2 X F O ( gp2T 2)
gp1x3
( gp2T 1)
R 1 gp2 ( gp2T 2)
R 2 gp2

M

P procedure

P process

GP

Enter
gp2x1
Exit
gp2x3

#
The formal definition for Grafchart - the grafcet version, is similar to the
formal definition for Grafcet presented in Chapter 3.3.

A Grafcet can be defined as a 5-tuple

G
< V r , V a , X , T , I >

A Grafchart can be defined as an 9-tuple

G
< V r , V a , X , T , M , P procedure, P process, GP , I >

What differs in the two definitions are the macro steps M, the procedure
steps P procedure, the process steps P process, and the Grafchart procedures
GP , included in the Grafchart definition.
Another difference is the meaning of V r and V a . In Grafcet they are vari-
ables specifying the receptivities and the actions respectively. In Grafchart
they are the receptivities and the actions, i.e., they are the corresponding
G2 statements.

254
 C.3 Grafchart the basic version

C.3 Grafchart the basic version

The formal definition for Grafchart the basic version also takes into
consideration the parameterization and methods and message passing
features. The formal definition now concerns a complete Grafchart appli-
cation and not only a single function chart.

A Grafchart-BV application can be defined as a 4-tuple:

Appl
< , G , GP , O >

where:
defines all the types that are allowed in the application.
G is the main function chart implemented by a Grafchart
process.
GP is the finite set of stand alone procedures imple-
mented by Grafchart Procedures, GP
{ GP1 , GP2 , }.
O is the finite set of objects, O
{ O 1, O 2 , }.

The formal definitions of a Grafchart process G, a Grafchart procedure

GP, and an object O are now presented.

(1). A Grafchart process, G, can be defined as a tuple:

G
< , V r , V a , X , T , M , P procedure, P process, I , A ttr >

where:
is a set of types. It defines the different types that are
allowed in the Grafchart process.
V r is the set of receptivities associated with the transi-
tions. V r can be divided into two, not necessarily disjoint,
subsets.

V r
V rX V rM

255
Appendix C. Formal Definition of Grafchart

V rX are the receptivities associated with the transi-

tions not included in a macro step.
V rM are the receptivities associated with the transi-
tions included in the macro steps.
V a is the set of actions issued to the plant. V a can be
divided into three, not necessarily disjoint, subsets.

V a
V aX V aM V aG

V aX are the actions associated with the steps not

included in a macro step.
V aM are the actions associated with the macro steps.
V aG are the actions associated with the Grafchart
process G.
X is the set of steps, X
{ x1 , x2 , x3 , }.
T is the set of transitions, T
{t1 , t2 , t3 , }. T can be
divided into two disjoint subsets.

T
{T o T exception}

T o is the set of ordinary transitions, T o
T \T exception

T exception is the set of exception transitions.
M is the set of macro steps, M
{ M1, M2 , }.
V rM
{V rM1 V rM2 }.
V aM
{V aM1 V aM2 }.
P procedure is the set of procedure steps, P
{ P1 , P2 , }.
P process is the set of process steps, P
{ P1 , P2 , }.
I is the set of initial steps, I X .
A ttr defines the attributes associated with the Grafchart
process.
attri A ttr : [{T ype( Eval ( Expr( attri )))
T ype( Expr( attri ))} ]

256
 C.3 Grafchart the basic version

(2). A Grafchart procedure, GPi is defined by the tuple:

GPi
< , V ri, V ai , X i , T i , M i , P procedure,i, P process,i,

GP i , Enteri , Exiti , A ttr >

where:
is the set of types allowed in the Grafchart procedure.
V ri is the set of receptivities associated with the transi-
tions. V ri can be divided into three, not necessarily dis-
joint, subsets.

V ri
{V rX i V rM i V rGP i}

V rX i are the receptivities associated with the tran-

sitions not included in a macro step or a Grafchart
procedure.
V rM i are the receptivities associated with the tran-
sitions included in a macro step.
V rGP i are the receptivities associated with the tran-
sitions included in a Grafchart procedure.
V ai is the set of actions issued to the plant. V ai can be
divided into three, not necessarily disjoint, subsets

V ai
{V aX i V aM i V aGP i V aGPi}

V aX i are the actions associated with the steps not

included in a macro step or a Grafchart procedure.
V aM i are the actions associated with the steps in-
cluded in a macro step.
V aGP i are the actions associated with the steps in-
cluded in a Grafchart procedure.
V aGPi are the actions associated with the Grafchart
procedure GP.
X i , T i are defined as X , T for a Grafchart process.
M i is the set of macro steps, M i
{ Mi,1, Mi,2 }.
V rM i
{V rMi,1 V rMi,2 }.
V aM i
{V aMi,1 V aMi,2 }.

257
Appendix C. Formal Definition of Grafchart

P procedure,i and P process,i are defined as P procedure and P process

for a Grafchart process.
GP i is the set of Grafchart procedures, GP i

{ GPi,1 , GPi,2 , }, that can be called from the Grafchart
procedure.
V rGP i
{V rGPi,1 V rGPi,2 }.
V aGP i
{V aGPi,1 V aGPi,2 }.
Enteri is the enter step of the Grafchart procedure,
Enteri X i .
Exiti is the exit step of the Grafchart procedure, Exiti
X i.
A ttr is the set of attributes associated with the Grafchart
procedure.
attri A ttr : [{T ype( Eval ( Expr( attri )))
T ype( Expr( attri ))} ]

(3) An object, O is defined by the 3-tuple

O
< , A ttr, OM >

where:
is the set of types allowed for the object.
A ttr is the set of attributes associated with the object.
attri A ttr : [{T ype( Eval ( Expr( attri )
T ype( Expr( attri ))} ]
OM is the set of object methods associated with the ob-
ject, OM
{ O M1, O M2, }.
An object method, O Mi, is defined in the same way
as a Grafchart procedure.

The formal definitions of a step x, a transition t, a macro step M, a pro-

cedure step Pprocedure, a process step Pprocess, a receptivity and an action
are now presented.

258
 C.3 Grafchart the basic version

(a) A step x is defined by:

{action}

action is a function defined from X into expressions such

that:

x X : [action( x) V aX ]

i.e., action( x) defines the actions associated with the

step x.

(b) A transition t is defined by the 3-tuple:

{XP R , X F O , }

X P R is a function defined from T into expressions such

that:

t T : [ X P R ( t) X M P procedure P process ]

i.e., X P R ( t) is the set of previous steps.

X F O is a function defined from T into expressions such
that:

t T : [ X F O ( t) X M P procedure P process ]
i.e., X F O ( t) is the set of following steps.
a function defined from T into expressions such that:

t T : [ ( t) V rX ]

i.e., ( t) defines the receptivity associated with the tran-

sition t.

259
Appendix C. Formal Definition of Grafchart

(c) A macro step Mi is defined as a tuple:

Mi
< , V ri , V ai , X i , T i , M i , P procedure,i, P process,i,

GP i , Enteri , Exiti , A ttr >

where:
is the set of types allowed in the macro step.
V ri is the set of receptivities associated with the transi-
tions. V ri can be divided into two, not necessarily disjoint,
subsets.

V ri
{V rX i V rM i V rGP i}

V rX i, V rM i , and V rGP i are defined as V rX , V rM , and

V rGP for a Grafchart procedure.
V ai is the set of actions issued to the plant. V ai can be
divided into three, not necessarily disjoint, subsets

V ai
{V aX i V aM i V aGP i V aMi}

V aX i, V aM i , and V aGP i are defined as V aX , V aM , and

V aGP for a Grafchart procedure.
V aMi are the actions associated with the macro step
Mi.
X i , T i are defined as X , T , for a Grafchart process.
M i is defined as M for a Grafchart process.
P procedure,i and P process,i is defined as P procedure and P process
for a Grafchart process.
GP i is defined as GP for a Grafchart procedure.
Enteri is the enter step of the macro step, Enteri X i .
Exiti is the exit step of the macro step, Exiti X i .
A ttr is the set of attributes associated with the macro
step.
attri A ttr : [{T ype( Eval ( Expr( attri )))
T ype( Expr( attri ))} ]

260
 C.3 Grafchart the basic version

(d) A procedure step Pi is defined by the pair:

{A ttr, Proc }

A ttr is the set of attributes associated with the procedure step.

attri A ttr : [{T ype( Eval ( Expr( attri )))
T ype( Expr( attri ))} ]
Proc is the Grafchart procedure or the object method that
should be called from the Procedure step.
{T ype( Eval ( Proc )) T ype( Proc )} {GP OM }

(e) A process step Pi is defined by the pair:

{A ttr, Proc }

A ttr is the set of attributes associated with the process step.

attri A ttr : [{T ype( Eval ( Expr( attri )))
T ype( Expr( attri ))} ]
Proc is the Grafchart procedure or the object method that
should be called from the Process step.
{T ype( Eval ( Proc )) T ype( Proc )} {GP OM }

(f) A receptivity, R i is defined by the pair

R i
{event, condition}

where: event and condition are functions such that

event( R i) any G2 event expression

condition( R i) any boolean G2 expression

261
Appendix C. Formal Definition of Grafchart

(g) An action, Ai is defined by the pair

Ai
{actiontype, actiontext}

where: actiontype and actiontext are functions such that

actiontype( Ai) {initially, f inally, always, abortive}

actiontext( Ai ) any G2 rule action statement

EXAMPLE C.3.1
In order to illustrate how the formal definition can be used a Grafchart-
BV application is presented and its definition is given. The Grafchart
application is a batch recipe, see Figure C.3. The batch recipe is supposed
to be executed in the batch cell shown in Figure 7.6.

Figure C.3 A Grafchart-BV application consisting of a batch recipe.

262
 C.3 Grafchart the basic version

The batch recipe application is described by the 4-tuple:

Appl
< , G , GP , O >

is the set of all types allowed in the application.

{integer, boolean, storage-tank, mixer, reactor,

product-tank, on-off-valve, control-valve, 2in-valve,
level-sensor, temperature-sensor, pressure-sensor,
flow-sensor, pump, agitator-switch, pid-controller }

G is a Grafchart process describing the recipe.

GP is the set of stand alone procedures.

GP

O is the set of objects.

O
{stA, stB , m1, r1, ptD}

The definitions of the Grafchart process G and the objects stA, stB, m1,
r1, and ptD are:

(1) The Grafchart process G, see Figure C.3, is described by the tuple:

G
< , V r , V a , X , T , M , P procedure, P process, I , A ttr >

where

{ integer, boolean, storage-tank, mixer, reactor,

product-tank, on-off-valve }

V r
{V rX V rM
V rM

V rX
{ R 1, R 2 , R 3 , R 4 , R 5 , R 6 , R 7 }

The receptivities, V rX are shown in Figure C.4.

263
Appendix C. Formal Definition of Grafchart

R1 : R2 :

R3 : R4 : R5 :

R6 : R7 :

Figure C.4 The set of receptivities for the Grafchart process G.

event( R 1)
condition( R 1)
true

event( R 2)
condition( R 2)
"sup.mixer has a current

value and sup.reactor has a current value
and sup.mixer.reserved is false"

event( R 3)
condition( R 3)
true

event( R 4)
condition( R 4)
true

event( R 5)
condition( R 5)
true

event( R 6)
condition( R 6)
true

event( R 7)
condition( R 7)
true

264
 C.3 Grafchart the basic version

V a
{V aX V aM V aG }
V aG

V aM

V aX
{ A1 , A2 }
The actions, V aX , is shown in Figure C.5.

actiontype( A1)
Initially

actiontext( A1)
"If not(sup.mixer has a current value) then
inform the operator that "No mixer has
been assigned to the batch""

actiontype( A2)
Initially

actiontext( A2)
"If not(sup.reactor has a current value) then
inform the operator that "No mixer has
been assigned to the batch"
X
{ x1 , x2 , x3 }
action( x1)

action( x2)
{ A1 , A2 }
action( x3)

A1 :

A2 :

Figure C.5 The set of actions for the Grafchart process G.

265
Appendix C. Formal Definition of Grafchart

T
{t1 , t2 , t3 , t4 , t5 , t6 , t7 }
To
T
T exception

X P R ( t1)
x1 X F O ( t1)
x2 ( t1 )
R1
X P R ( t2)
x2 X F O ( t2)
{p1 , p2 } ( t2 )
R2
X P R ( t3)
{p1 , p2 } X F O ( t3)
p3 ( t3 )
R3
X P R ( t4)
p3 X F O ( t4)
{p4 , p5 } ( t4 )
R4
X P R ( t5)
{p4 , p5 } X F O ( t5)
p6 ( t5 )
R5
X P R ( t6)
p6 X F O ( t6)
{p7 , p8 } ( t6 )
R6
X P R ( t7)
{p7 , p8 } X F O ( t7)
x3 ( t7 )
R7

M

P procedure
{p1 , p2 , p3 , p4 , p5 , p6 , p7 , p8 }
The set of procedure steps is shown in Figure C.6.

P1 : P2 :

P3 : P :
4

P5 : P :
6

P7 : P :
8

Figure C.6 The set of procedure steps for the Grafchart process G.

266
 C.3 Grafchart the basic version

A ttr(p1 )
{source, level, valve}

Expr( source)
S A, Expr( level )
0.1, Expr(valve)
invalve1
Proc ( p1)
{sup.mixer charge}

A ttr(p2 )
{source, level, valve}

Expr( source)
S B , Expr( level )
0.1, Expr(valve)
invalve2
Proc ( p2)
{sup.mixer charge}

A ttr(p3 )
{time}
Expr( time)
1
Proc ( p3)
{sup.mixer agitate}

A ttr(p4 )
{}
Proc ( p4)
{sup.mixer discharge}

A ttr(p5 )
{source}
Eval ( Expr( source))
Eval ( sup.mixer in)
m1
Proc ( p5)
{sup.reactor charge}

A ttr(p6 )
{temperature}
Expr( temperature)
60
Proc ( p6)
{sup.reactor heat}

A ttr(p7 )
{}
Proc ( p7)
{sup.reactor discharge}

A ttr(p8 )
{source, level}

Eval ( Expr( source))
Eval ( sup.reactor in)
r1, Expr( level )
0.5
Proc ( p8)
{p1 charge}

P process

I
{ x1 }

A ttr
{mixer, reactor, size, batchid}

267
Appendix C. Formal Definition of Grafchart

(2) The object m1, see Figure C.7 is defined by the 3-tuple:

M1
{, A ttr, OM }

where:

{ boolean, on-off-valve, pump, level-sensor, temperature-sensor,

pressure-sensor, agitator-switch }
A ttr
{ reserved, invalve1, invalve2, outvalve, pump, level-sensor,
temperature-sensor, pressure-sensor, agitator }
OM
{ Charge, Agitate, Discharge }

Figure C.7 The mixer m1.

(3) The object R1, see Figure C.8, is defined by the 3-tuple:

R1
{, A ttr, OM }

where:

{ boolean, integer, control-valve, on-off-valve, pump, level-sensor,

temperature-sensor, pressure-sensor, flow-sensor, pid-controller,
2in-valve, agitator-switch }
A ttr
{ reserved, invalve1, invalve2, outvalve, flowvalve, pump,
level-sensor, temperature-sensor, pressure-sensor, flow-sensor,
level-PID, temperature-PID, flow-PID, 2-in, agitiator }
OM
{ Charge, Load, Agitate, Heat, Cool, Discharge }

268
 C.3 Grafchart the basic version

Figure C.8 The reactor r1.

The definitions of stA, stB, and ptD are similar to the ones for m1 and
r1.

All methods belonging to the mixer or to the reactor are defined in a

similar manner. Their definitions are identical to that of a Grafchart pro-
cedure. Here, only the definition of the method Agitate for mixer m1 is
presented. For m1 the following is true:

Expr{agitate}
mixer agitate method

mixer a m will be use as a shorter name for mixer agitate method.

269
Appendix C. Formal Definition of Grafchart

Figure C.9 The object method mixer agitate method belonging to the mixer m1.

The object method mixer agitate method, see Figure C.9, is defined by:

mixer a m
< , V r , V a , X , T , M , P procedure, P process, GP , Enter, Exit, A ttr >

where:

{integer}
V r
{V rX V rM V rGP }
V rGP

V rM

V rX
{ R 1 }
The receptivity is shown in Figure C.10.

event( R 1)

condition( R 1)
"active-time-larger-than(this workspace,sup.time)"

Figure C.10 The receptivity for the mixer method agitate.

270
 C.3 Grafchart the basic version

V a
{V aX V aM V aGP V a,mixer a m }
V a,mixer a m
V aGP
, V aM

V aX
{ A1 , A2 }
The actions are shown in Figure C.11.
actiontype( A1)
Initially
actiontext( A1)
conclude that self.agitator.active
true
actiontype( A2)
F inally
actiontext( A2)
conclude that self.agitator.active
false
X
{ x1 , x2 }
action( x1)
{ A1 , A2 }
action( x2)

T
{t1 }
To
T , T exception

X P R ( t1 )
x1 X F O ( t1)
x2 ( t1 )
R 1
M

P procedure

P process

GP

Enter
{ x1 }
Exit
{ x2 }
A ttr
{time}

A 1:

A2:

Figure C.11 The action for the mixer method agitate.

271
Appendix C. Formal Definition of Grafchart

C.4 Grafchart the high-level version

The formal definition of Grafchart the high-level version takes into ac-
count all four features; parameterization, methods and message passing,
object tokens, and multi-dimensional charts. The formal definition con-
cerns a complete Grafchart application.

The definition of Grafchart the high-level version resembles the defini-

tion of Grafchart the basic version. Therefore only the differences are
pointed out.

A High-Level Grafchart application can be defined as a 5-tuple:

Appl
< , G , GP , O , T C >

where:
defines the types allowed in the application.
G is the main function chart implemented by a Grafchart
Process.
GP is the finite set of stand alone procedures imple-
mented by Grafchart Procedures, GP
{ GP1 , GP2 , }.
O is the finite set of objects, O
{ O 1 , O 2, }.
T C is the finite set of token colors, T C
{T C1 , T C2 , }.

The formal definitions of a Grafchart process G, a Grafchart procedure

GP, an object O and a token color T C are now presented.

(1) A Grafchart process, G, can be defined as a tuple:

G
< , V r , V a , X , T , M , P procedure, P process, I , T C , A ttr >

where:
, V r , V a , X , T , M , P procedure, P process, I , and A ttr are
defined in the same way as for a Grafchart process G in
Grafchart-BV.
T C is the set of token colors allowed in the Grafchart
process.

272
 C.4 Grafchart the high-level version

(2) A Grafchart procedure, GPi is defined by the tuple:

GPi
< , V ri, V ai , X i , T i , M i , P procedure,i, P process,i,

GP i , Enteri , Exiti , A ttr >

where:
, V ri , V ai, X i , T i , M i, P procedure,i, P process,i, GP i , Enteri,
Exiti and A ttr are defined in the same way as for a Graf-
chart procedure GPi in Grafchart-BV.

(3) An object, O i is defined by the 3-tuple

O i
< , A ttr, OM >

where:
, A ttr, and OM are defined in the same way as for an
object, O, in Grafchart-BV.

(4) A token color, T Ci is defined by the three-tuple

T Ci
< , A ttr, OM >

where:
is the set of types allowed within the token color.
A ttr is the set of attributes associated with the token
color.
attri A ttr : [{T ype( Eval ( Expr( attri )
T ype( Expr( attri ))} ]
There are default values associated with the attributes.
OM is the set of object methods associated with the token
color, OM
{ O M1, O M2, }.
An object method, O Mi, is defined in the same way
as a Grafchart procedure.

273
Appendix C. Formal Definition of Grafchart

The formal definitions of a step x, a transition t, a macro step M, a pro-

cedure step Pprocedure, and a process step Pprocess are now presented.

(a) A step x is defined by:

{action}

action is a function defined from X into expressions such

that:

x X : [action( x)) V aX ]

i.e., action( x) defines the actions associated with the

step x.

(b) A transition t is defined by the 3-tuple:

{X P R , X F O , }

X P R is a function defined from T into expressions such

that:

t T : [ X P R ( t) X M P procedure P process ]

i.e., X P R ( t) is the set of previous steps.

X F O is a function defined from T into expressions such
that:

t T : [ X F O ( t) X M P procedure P process ]

i.e., X F O ( t) is the set of following steps.

a function defined from T into expressions such that:
t T : [ ( t) V rX ]

i.e., ( t) defines the receptivity associated with the tran-

sition t.

274
 C.4 Grafchart the high-level version

(c) A macro step Mi is defined as a tuple:

Mi
< , V ri , V ai , X i , T i , M i , P procedure,i, P process,i,

Enteri , Exiti , T C i , A ttr >

where:
, V ri , V ai, X i , T i , M i ,P procedure,i, P process,i, Enteri, Exiti , and
A ttr are defined as for a macro step Mi for Grafchart-BV.
T C i is the set of token colors defined for the macro step.

(d) A procedure step Pi is defined by:

{ ProcC all }

ProcC all is a function defined from P procedure into expres-

sions such that:

Pi P procedure : [ ProcC all ( Pi ) PC ]

i.e., ProcC all ( Pi ) defines the procedure calls associated with

the procedure step Pi . P C
{ PC1 , PC2 , }.

(e) A process step Pi is defined by:

{ ProcC all }

ProcC all is a function defined from P process into expres-

sions such that:

Pi P process : [ ProcC all ( Pi ) PC ]

i.e., ProcC all ( Pi ) defines the procedure calls associated with

the process step Pi . P C
{ PC1 , PC2 , }.

275
Appendix C. Formal Definition of Grafchart

The formal definitions of an action A, a receptivity R and a procedure call

PC are now presented.

Token class:

Action type:

For any:
There exists:

Condition:

Action text:

Figure C.12 A Grafchart-HLV action.

(f) An action Ai , see Figure C.12 is defined by:

Ai
{, Token class, Action Type, For any, There exists,

Condition, Action text}

defines the types allowed in the action.

Token class is a function defined from V a into expression
such that:
Ai V a : [Token class( Ai) ]
Token class specifies the class of the token that activates
the action. Here, only the token class name is given, e.g.,
blue-token.
Action Type is a function defined from V a into expressions
such that:
Ai V a : [ ActionT ype( Ai)

{ Initially, F inally, Always, Abortive}]
Action Type specifies the type of the action, i.e., Initially,
Finally, Always or Abortive.

276
 C.4 Grafchart the high-level version

For any is a function defined from V a into expression such

that:
T ype( Var( T here exists( Ai )))
v Var( F or any( Ai )) : [T ype(v)
Tokenclass( Ai)]
For any defines the temporary-token-name of the tokens in-
volved in the action. A name of the token mentioned in the
token class must be declared. E.g., For any: b:blue-token
or For any: b1: blue-token, b2:blue-token. All names must
be unique.
There exists is a function defined from V a into expressions
such that:
T ype( Var( T here exists( Ai )))
There exists can be used to check the presence of other
tokens than the one activating the action. E.g., There ex-
ists: r:red-token or There exists: g1: green-token, g2:green-
token. All names must be unique.
Condition specifies the conditions that must be fulfilled for
the action to be executed, e.g., b.y
10, not(b1.y
20).
Action text specifies what should be done when the action
is executed, e.g., b.y
r.v, b.on
false.

(g) A receptivity R, see Figure C.13, is defined by:

R i
{, Token class, For any, There exists, Event,
Condition, Action}

defines the types allowed in the receptivity.

Token class is a function defined from V r into expression
such that:
R V r : [T ype( Token class( R i)) ]
Token class specifies the class of the token that enables the
receptivity. Here, only the tokenclass name is given, e.g.,
blue-token.

277
Appendix C. Formal Definition of Grafchart

Token class:

For any:
There exists:

Event:
Condition:

Action:

Figure C.13 A Grafchart-HLV receptivity.

For any is a function defined from V r into expressions such

that:
T ype( Var( T here exists( R i)))
v Var( F or any( Ai )) : [T ype(v)
Tokenclass( Ai)]
For any defines the temporary-token-name of the tokens in-
volved in the receptivity. A name of the token mentioned
in the token class must be declared. E.g., For any: b:blue-
token or For any: b1: blue-token, b2:blue-token. All names
must be unique.
There exists is a function defined from V r into expressions
such that:
T ype( Var( T here exists( R i)))
There exists can be used to check the presence of other to-
kens than the one enabling the receptivity. E.g., There ex-
ists: r:red-token or There exists: g1: green-token, g2:green-
token. All names must be unique.
Event is a function defined from V r into expressions such
that:
R V r : [T ype( Event( R i))
B oolean]
R V r : [T ype( Var( Event( R i))) ]
Event specifies the event that has to occur for the enabled
transition to fire. E.g.,b.y
10.

278
 C.4 Grafchart the high-level version

Condition is a function defined from V r into expressions such

that:
R Vr : [T ype( C ondition( R i))
B oolean]
R Vr : [T ype( Var( C ondition( R i))) ]
Condition specifies the conditions that must be fulfilled in
order for the enabled transition to fire. E.g., r.on
true.
Action is a function defined from V r into expressions such
that:
Action( R i)
{ M ove, C reate, Delete, C hange}
T ype( Var( Action( R i)))
Action specifies what should happen when the transition is
fired. Possible options
move: The action move(b), moves the token refered to
as b from the preceding step to the succeeding step.
delete: The action delete(b), deletes the token refered
to as b, this token must reside in the preceding step.
create: The action create(b:blue-token), creates a
new token and gives it the temporary-name b. The new
token is placed in the succeeding step. By combining
this action with the change action, the attributes of the
new token can be given any value. If this action is not
combined with the change action, the attributes of the
newly created token will have their default values.
change The action change(b.y=12, r.on=false),
changes the y attribute of the token refered to as b and
changes the on attribute of the token refered to as r.

Token class:

Parameters:

Procedure:

Figure C.14 A Grafchart-HLV procedure call.

279
Appendix C. Formal Definition of Grafchart

(h) A procedure call PC, see Figure C.14, is defined by the 4-tuple:

{, Token class, A ttr, Proc}

defines the types allowed in the procedure call.

Token class is a function defined from PC into expressions
such that:
PCi P C : [Tokenclass( PCi) ]
Token class specifies the class of the token that enables the
procedure call. Here, only the tokenclass name is given, e.g.,
blue-token.
A ttr is the set of attributes associated with the procedure-
call.
attri A ttr : [{T ype( Eval ( Expr( attri )))
T ype( Expr( attri ))} ]
A ttr specifies the attributes that should be sent to the Graf-
chart procedure.
Proc defines the Grafchart procedure or the object method
that should be called from the procedure call.
{T ype( Eval ( Expr( Proc ))) T ype( Eval ( Proc ))}
{GP OM }
Proc specifies the name of the Grafchart procedure that
should be called. The name could be given either direct or in-
direct via a reference. The Grafchart procedure that should
be call can either be a stand alone procedure or a method
belonging to an object.

C.5 Remarks

The Grafchart syntax definition is based upon tuples. This kind of syntax
definition is suitable for graphical languages, e.g., Grafcet and Petri nets.
Grafchart mainly has a graphical syntax and a tuple-based definition of
the language has therefore been chosen. However, Grafchart does also
contain textual parts, e.g., the actions and the receptivities. In order to be
consistent, these are also defined using tuples. For textual languages it is,
however, more common to use the extended Backus-Naur form (EBNF).

280
D
Dynamic Simulator

The dynamic simulator is used as a substitute for a real plant. It simu-

lates the mass balances, energy balances and the chemical reactions. All
simulations are done in real-time.
A table over the notation and the constants used in the dynamic simulator
is given in the end of the appendix, Chapter D.7.
Two reactions can be simulated in the scenario:

A+B 2D
C+D E

The total mass balance, m( t), the component mass balances, x( t), and the
energy balance, T ( t), see Figure D.1, for the reactions are calculated.

Win (t) Wout (t)

m(t)
Xin(t) x(t) X(t)
T (t) T(t) T(t)
in

Figure D.1 Mass balance, component mass balance and energy balance.

281
Appendix D. Dynamic Simulator

D.1 Total Mass Balance

The total mass balance of a unit is given by a differential equation together
with an initial condition.

dm( t)

Win Wout
dt |{z} | {z }
incoming mass f low outgoing mass f low

m(0)
mo

The equation comes from the principle of the conservation of mass. m( t) is

the weight of the content in the unit, i.e. the mass. The mass is increased
if there is an inflow to the unit and it is decreased if there is an outflow
of the unit. Win is the mass flowing in to the unit per time unit and Wout
is the mass flowing of the unit per time unit.

D.2 Component Mass Balance

The component mass balance tells how much there is of a specific sub-
stance within a unit, it is given in percentage of the total mass. Unlike
mass, chemical components are not conserved. If a reaction occurs inside
a system, the mass of an individual component will increase if it is a
product of the reaction or decrease if it is a reactant. The mass fraction,
x( t), changes continuously and is therefor given by a differential equation
together with an initial condition.

dx( t) Win MV

( xin x) + r
dt | m {z } | m{z }
in out produced

x(0)
xo

where M is the molweight of the substance, V is the volume and r is the

reaction rate.

D.3 Energy Balance

The energy balance gives a differential equation for the temperature in

the unit, T ( t). The equation is based on the first law of thermodynamics,

282
 D.3 Energy Balance

the conservation of energy.

dT ( t) Win 1 1

( Tin T ) + Qp Qc
dt m cp m cp m
T (0)
to

Qp is the energy produced during the reaction, Qc is the energy that is

removed by, e.g., a cooling jacket, and cp is the heat capacity.

Energy Balance for the Reactor Jacket

The equations given above, apply to all units in the batch scenario. The
reactor, however, needs one more equation that describes its jacket.
Produced reaction rate, Qp :

Qp
Hreac V r

If Qp 0 the reaction consumes energy, i.e., it is an endotherm reaction.

If Qp 0 the reaction generates energy, i.e. it is an exotherm reaction.

Cooling heat, Qc :

Qc
H Ac (T Tc )
m
Ac
kw
A
The cooling heat is the energy that is removed due to, e.g., a cooling jacket.
H is the heat transfer, A is the area of the reactor, kw is the wall coefficient
for the reactor and is the density of the content in the reactor.

Energy balance for the jacket of the reactor:

A

Figure D.2 Reactor with a jacket.

dTc ( t) Wic 1

( Tic Tc ) + Qc
dt mc cp mc

283
Appendix D. Dynamic Simulator

D.4 Level and Volume

Equations for calculating the level and the volume for all the units are
also part of the dynamic simulator.

D.5 Reaction Rates

The reaction rates, r1 and r2 , of the reactions can be calculated by using

the Arrenius equation:
A+ B 2D (D.1)
C+D E (D.2)

Eq. D.1 gives:

rA
r1
rB
r1
rD
2r1
Eq. D.2 gives:
rC
r2
r D
r2
r E
r2
The reaction rate for substance D can now be calculated:
r D
2r1 + r2
The constants r1 and r2 are given by:
E1
r1
K 1 e R(T +273) c A c B
xA xB
K 1 e R(T +273)
E


MA MB

E2
r2
K 2 e R(T +273) cC c D
xC x D
K 2 e R(T +273)
E


MC MD
K 1 and K 2 are reaction constants, E1 and E2 are the activation energies,
R is the gas-law constant, T is the temperature in C, ci , xi and Mi are
the concentration the mass fraction and the mole weight of substance i,
is the density.

284
 D.6 Implementation

D.6 Implementation
The objects are defined in a simulation class hierarchy, see Figure D.3.
The top class, volume, has two subclasses, tube-sim and non-tube-sim.
tube-sim corresponds to the pipes in the cell whereas non-tube-sim cor-
responds to the units. The class names are extended with -sim to indicate
that these classes are used in the dynamic simulator.

Figure D.3 Simulation classes.

On the subworkspace of each class the equations specific for this class
are placed. Equations that are common to all units are placed on the
subworkspace of non-tube-sim, these are e.g. the equations for the vol-
ume, the level, the component-mass-balances, the energy-balances, the
total mass balance and the reaction-rates. In Figure D.4 two of the eight
equations associated with the class mixer-sim are shown.
To each class a number of attributes are associated. The attributes com-
mon to all classes are defined in the class volume, whereas attributes
specific to only one class are defined within the class itself. Attributes
shared by the classes are e.g. the name, the mass fraction of each sub-
stance, the volume and the level, the reaction rates of the two reactions
and the temperature. Attributes specific to a class are, e.g., the number
of inpipes.
When the program is started the equations are calculated and the differ-
ential equations are updated periodically. The results are shown as values
of the attributes to the objects. In Figure D.5 the simulation view of the

285
Appendix D. Dynamic Simulator

Figure D.4 Equations associated with the class "mixer".

batch scenario is shown together with the attribute table of one of the
mixers. The table contains the values of the simulated parameters.

Figure D.5 Attribute table of the mixer-sim named "M-2".

286
 D.7 Notation and Constants

D.7 Notation and Constants

Notation Unit Notation used

in Batch scenario
V m3 Volume Vol
W kg / sek mass flow Wout
X (kg / total kg ) mass fraction x-out-(a,b,c,d,e)
M kg / kmol mole weight MA,MB,MC,MD,ME
m kg mass M
r kmol/(sek m3 ) reaction rate r-a-and-b-to-e etc.
xA
c kmol/ m3 concentration (C A
Ma
)
kg / m 3
density density
E J / kmol activation energy e-a-and-b-to-d etc
K m3 /(kmol sek) reaction-constant k-a-and-b-to-d etc
R J / kmol K gas law constant r

T C temperature t out
h J / kg enthalpy (h
cp T )
u J internal energy (u  H
cp T )
Qp J / sek produced reaction rate Prod
Qc J / sek cooling heat Cool
Hreac J / kmol h-a-and-b-to-d etc
H J /(sek m2 K ) heat transfer cooling-coefficient
kw m wall coefficient wall-area-coefficient
cp J /(kg K ) heat capacity cp

287
Appendix D. Dynamic Simulator

Constant
cp 4180 J /(kg K )
density 1000 kg / m3
wall-area-coef. 40 m
R 8314 J /(kmol K )
mol-weights:
Ma 50 kg / kmol
Mb 60 kg / kmol
Mc 40 kg / kmol
Md 50 kg / kmol
Me 40 kg / kmol
reaction-constants:
k-a-and-b-to-d 2 107 m3 /(kmol sek)
k-c-and-d-to-e 7 1010 m3 /(kmol sek)
activation-energy:
e-a-and-b-to-d 69.418 106 J / kmol
e-c-and-d-to-e 75.00 106 J / kmol
reaction-energy:
h-a-and-b-to-d 6.99 107 J / kmol
h-c-and-d-to-e 75900 J / kmol

288
E
An Introduction to G2

G2, developed by Gensym Corporation in USA, was originally developed

as a real-time expert system. It has however evolved into a very powerful
object oriented programming environment with strong graphical features.
G2 is written in Common LISP which is automatically translated into
C. However, all user programming is done in G2s built in programming
language using either rules, functions or procedures. G2 runs on a variety
of UNIX and Windows platforms.

Classes and objects The programming language of G2 is strictly ob-

ject oriented. This means that objects are implemented in classes defined
in a class hierarchy. Each class has an icon and a number of specific at-
tributes. The icon can be defined either textually with the text editor or
graphically using the icon editor. The attributes contain the data asso-
ciated with a class. Subclasses inherit properties from its superclasses,
multiple inheritance is allowed.

An application is built up by placing objects (instances of a class) on a

workspace. By connecting the objects their relationships are shown. As-
sociated with each object is its attribute table. The table is automatically
created from the definition of the objects class.

Composite objects are objects that have an internal structure. As other

objects, composite objects are represented by an icon and have an attribute
table. The values of these attributes may be other objects. It is, however,
not possible to have a graphical representation of the composite object and
its internal objects at the same time. If such a representation is desired
this can be implemented using the subworkspace concept. In G2 all objects
may have an associated subworkspace and on this subworkspace other
objects may be positioned, i.e., the internal structure of an object can be
represented on its subworkspace.

289
Appendix E. An Introduction to G2

Rules and procedures G2-rules can be used to indicate how to respond

to and what to conclude from changing conditions within the application.
There are five different types of rules; if-, when- initially- whenever- and
unconditionally rules. Rules can be scanned or invoked in a number of
ways.
Procedures are written in a Pascal like language. The roles of procedures
are dual, either they can be used as ordinary procedures or they can func-
tion as processes. Procedures are called from rules, from other procedures
or from user actions, e.g., from buttons. Procedures can have input pa-
rameters and they can return one or several values. When a procedure
operates as a process each invocation of the procedure execute as a sep-
arate task. Since the language of G2 is object oriented it also contains
methods. A method is a procedure that implements an operation for an
object of a particular class.

Simulator G2 has a built in simulator which can provide simulated

values for variables. The simulator allows the simulated expressions to
be algebraic equations, difference equations , or first-order differential
equations.

G2 provides a powerful graphical interface and easy ways to manipulate

and reason about objects. It is particularly well fitted for applications
which need graphical representations like the batch scenario. For more
information about G2 see [Gensym Coorporation, 1995].

290