GRAFCHART AND GRAFCET: A COMPARISON

BETWEEN TWO GRAPHICAL LANGUAGES AIMED

FOR SEQUENTIAL CONTROL APPLICATIONS

Charlotta Johnsson and Karl-Erik Årzén

Department of Automatic Control,

Lund Institute of Technology,
Box 118, S-221 00 Lund, Sweden,
E-mail: (lotta,karlerik)@control.lth.se

Abstract: This paper compares the language Grafcet with the language Grafchart.
Both are graphical languages aimed for sequential control applications. Grafcet
is aimed for specification of controller structures, i.e., for local level control
applications. Grafchart is based on Grafcet, Petri nets and ideas from object-
oriented programming and it can be used for any sequential control application,
both applications on a local level and on a supervisory level. In addition to this,
applications structured with Grafchart can be analyzed with respect to, e.g.,
deadlock situations, this is thanks to its foundation in Petri nets. In this paper,
the similarities and the differences that exit between Grafcet and Grafchart are
clarified and discussed.

Keywords: Discrete Event Systems, Sequential Control, Grafcet, Grafchart.

1. INTRODUCTION named IEC 848. In this standard Grafcet is

refered to under the name Sequential Function
Charts (SFC). Five years later, the standard,
The advantages of graphical programming lan-
IEC 1131-3, with Grafcet/SFC as essential part
guages are simplicity and declarativeness. They
arrived. Today, Grafcet/SFC is well accepted
often allow programming in a style that closely
in industry much thanks to its clear graphi-
mimics the style that people model problems.
cal interface. Grafcet has its roots the in the
Examples of mental models that are naturally
Petri nets formalism. Petri nets are a graphical
represented graphically include fault trees, or-
and mathematical model aimed for visualiza-
ganization charts, program flowcharts, and block
tion and simulation of discrete systems. Petri
diagrams. Graphical languages fit users’ exist-
nets are often used in the context of formal
ing perception of problem, making the appli-
methods for analysis of discrete event systems.
cation easier to build, debug, document, and
maintain. An added benefit is the possibility to Grafchart is the name of graphical language
use colour and animation to provide feedback as for sequential control applications. Grafchart is
the program executes. based on the graphical syntax of Grafcet. To
this it adds ideas from Petri nets, high-level
Grafcet is a graphical language that was pro-
Petri Nets and object-oriented programming.
posed in France in 1977 as a formal specification
Grafchart has been developed at Lund Institute
method for logical controllers, AFCET (1977).
of Technology since 1991, Årzén (1991); Johns-
In 1988, Grafcet, with minor changes, was
son (1997). The system is implemented in G2,
adopted by the International Electrotechnical
an object-oriented graphical programming en-
Commission (IEC) as an international standard
vironment for supervisory applications, Gen- Initial

sym Coorporation (1995). The primary aim of

step
or−divergence Alternative paths

Grafchart is to show how Grafcet/SFC can be Transition

and−divergence

modified from a rather low-level graphical lan- Token

guage into a high-level, object-oriented graphi- Parallel

cal language. The secondary aim is to be able paths

to use available analysis methods and tools de-

veloped for Petri nets also for Grafchart. In this and−convergence

way the same formalism may be used both for or−convergence

execution and formal analysis.
This paper starts, in Section 1 and Section 2,
with a presentation of Grafchart and Grafcet,
respectively. Thereafter follows a discussion
about the similarities and differences between
the two languages.
2. GRAFCHART
Grafchart is a graphical language aimed at se-
quential control applications. It is based on (1)
the industrially well-known and well-accepted
graphical syntax of Grafcet/SFC, (2) Petri nets,
mainly an academically known modeling lan-
guage with means for formal analysis and for-
mal definitions, (3) object-oriented program-
ming constructs. Grafchart exists in two differ-
ent versions, one basic version and one high-
level version. In this paper only the basic ver-
sion of Grafchart will be treated and compared
to Grafcet.
Grafchart has a graphical syntax similar to that
of Grafcet/SFC. The primary building blocks
are steps, representing states, and transitions,
representing the change of states. It also sup-
ports alternative and parallel branches, see Fig-
ure 1. An active step is indicated by the pres-
ence of a token in the step.
Step
Fig. 1. Grafchart graphical syntax.
once when the step becomes active (inactive).
Abortive actions are executed once just before
the step becomes aborted. All actions can be con-
ditional or unconditional. In Figure 2 (bottom
left) a step with an initially action is shown.
Transitions: To each transition a receptivity
is associated, each receptivity contains two at-
tributes: event and condition. When the re-
ceptivity of an enabled transition becomes true
the transition fires i.e., deactivates the steps
preceding it and activates the steps succeeding
it. A transition with a receptivity is shown in
Figure 2 (bottom right).
2.1.2. Grafchart Procedure: Sequences that
are executed in more than one place in a func-
tion chart can be represented as Grafchart pro-
cedures, see Figure 2 (top right). The proce-
dure body is stored on the subworkspace of the
Grafchart procedure object. Special enter-steps
and exit-steps are used to indicate the first and
the last sub-step of a procedure. The Grafchart
procedures are reentrant and recursive proce-
dure calls are possible.

Macro steps: Macro steps are used to represent

2.1 Building blocks steps that have an internal structure. The inter-
nal structure is placed on the subworkspace of
Grafchart supports eight different building blocks.
the macro step object, see Figure 3 (top right).
A subworkspace can be attached to each build-
Macro steps have enter-steps and exit-steps in
ing block.
the same way as the Grafchart procedures.
2.1.1. Grafchart Process: An entire function Subworkspace Subworkspace
chart can be encapsulated by a Grafchart pro- Grafchart Grafchart
process procedure
cess, i.e., the function chart can be placed on the
subworkspace of the Grafchart process object,
see Figure 2 (top left). A the function chart
always starts with an initial-step represented
by a double square.
Step Transition
Steps: Associated with the step are actions Initially
Open the valve
a transition

event
that are performed when the step is active. Four named B
condition

action types exist: always, initially, finally and

abortive. Always actions are executed cyclically
as long as the step they are associated with is Fig. 2. Grafchart process, Grafchart procedure,
active. Initially (finally) actions are executed Step and Transition
 Procedure Subworkspace
step
Procedure
call Macro
step
Grafchart
procedure
Process
step
Subworkspace
Exception
Process
transition
creation
Grafchart
procedure
Fig. 3. Procedure step, Macro step, Process step
and Exception transition.
Procedure step: The call to a Grafchart pro-
cedure is represented by a procedure step, see
Figure 3 (top left). The procedure step contains
a procedure attribute that contains the name
of the procedure that should be called.
2.1.3. Process steps: With a process step, see
Figure 3 (bottom left), it is possible to start a
procedure as a separate execution thread, i.e. as
a process. The transitions after 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.
2.1.4. Exception transition: An exception tran-
sition may only be connected to macro steps
or procedure steps. An exception transition is
enabled all the time that the step is active.
If the exception transition fires, the execution
of the corresponding step will be aborted and
abortive actions, if any, are executed. The steps
remember their execution state and it is pos-
sible to resume them from that state. An ex-
ception transition is shown in Figure 3 (bottom
right). Exception transitions was first proposed
in Årzén (1991). They have proved to be very
useful when implementing error handling.
2.2 Advanced features
Grafchart includes two advanced features: pa-
rameterization, and methods and message pass-
ing.
2.2.1. Parameterization: Grafchart processes,
macro steps, and steps may have attributes
acting as parameters. The parameters can be
accessed from within the step actions and the
transition receptivities using a special sup.att-
ribute notation. It is also possible for Grafchart
procedures to have parameters. The parameters
are given their actual values when the proce-
dure is called, i.e., in a procedure step or process
step. A procedure may also return values to the
Subworkspace calling step. It is possible to let the value of a
parameter determine which procedure that will
be called, i.e., there is support for dynamical
binding.
Subworkspace
2.2.2. Methods and message passing: The
method feature denotes the possibility to have
Grafchart procedures as methods of general ob-
jects. From the body of the Grafchart procedure
realizing the method it is possible to reference
the attributes of the object that the method
belongs to using a special self.attribute no-
tation. A method is called through a procedure
step. The method that will be called is deter-
mined by an object reference and a method
reference.
3. GRAFCET
Grafcet was developed in 1977 with the aim
to be a formal specification method for logi-
cal controllers. In industry Grafcet, with minor
changes, is better known under the name Se-
quential Function Charts (SFC). In this section
a brief overview of Grafcet is given. A more
thorough presentation of Grafcet can be found
in David (1995).
3.1 Building blocks
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 should be active when the system
is started, is represented as a double square.
Grafcet has support for both alternative and
parallel branches in the same way as shown in
Figure 1.
3.1.1. Steps A step can be active or inactive.
An active step is marked with 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.
3.1.2. 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 tran-
sition is fireable. A fireable transition will fire
immediately. When a transition fires the steps
preceding the transition are deactivated and the
steps succeeding the transition are activated.
3.1.3. Actions There are two major categories
of actions: level actions and impulse actions. A
level action is modeled by a binary variable and
has a finite duration. The level action remains
set all the time while the step, to which the
action is associated, is active. 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 an impulse action.
A situation can be stable or unstable. If the
transition following a step is immediately fire-
able when the step becomes active, the situa-
tion 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 exter-
nal events it is assumed that there is always
enough time to reach a stable situation. In Fig-
ure 4 two steps are shown. A level action, A, is
associated with the upper step and an impulse
action, B*, is associated with the lower step.
^
|x
I
A
y
M Action
B*
O
x .^
|z
Fig. 4. Two actions and three receptivities (left).
A macro step (right).
3.1.4. Receptivities Each transition has a re-
ceptivity. A receptivity may either be a logical
condition, an event, or an event and a condition.
In Figure 4 (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 combi-
nation of a condition and an event, x ⋅ ↑z .
3.2 Macro Steps
To facilitate the description of large and com-
plex 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 sep-
arately. 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. A macro step is shown in Figure 4 (right).
4. SIMILARITIES AND DIFFERENCES
Grafcet and Grafchart have many similarities.
This is natural since Grafchart is based upon
Grafcet. However, there are also some impor-
tant differences. These will be pointed out and
discussed in this section.
4.1 General aim
The language of Grafcet was developed with
the focus on logical controllers (PLCs). The lan-
guage is most often used only as a specifica-
tion language, i.e., as a graphical description of
how the controller should work. The implemen-
tation is then done in another language, e.g.,
relay (ladder) logic diagrams. Grafchart has
been developed without focus on any particular
application. Grafchart is also intended to be a
language used, not only for specifications, but
also for the actual implementation. A Grafchart
function chart is interpreted on-line.
4.2 Interface
Grafcet and Grafchart have different exter-
nal interfaces for actions and receptivities.
In Grafcet the interface consists mainly of
boolean variables whereas the interface in
Grafchart consists of everything that the under-
lying implementation language supports. Since
Grafchart is implemented in G2 this means that
there are support for e.g., booleans, strings,
numbers, arrays, structures etc. In Figure 2
(lower left) a Grafchart step with an initially
action is shown. This action can be compared
with the Grafcet impulse action shown in Fig-
ure 4 (left, lower step). Both the Grafcet and the
Grafchart action sends out a signal that should
open a valve named B.
All four types of actions in Grafchart can
be compared to impulse actions in Grafcet.
Grafchart does not support Grafcet level ac-
tions. The reason for this is that level ac-
tions are only of interest for boolean variables
(true/false, high/low) and Grafchart supports
a lot of different variable types. However, the
functionality of a level action can always be
expressed by one or more impulse actions.
4.3 Execution
The firing rules that apply to Grafchart are
similar to those of Grafcet.
Rule 1: All fireable transitions are immedi-
ately fired – this rule applies to Grafcet and
Grafchart.
Rule 2: Several simultaneously fireable tran-
sitions are simultaneously 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 sit-
uation by nondeterministically choosing one of
the branches. In order to have an interpretation
algorithm without ambiguities, situations like
this must be avoided. It is therefore required
that all branches are made mutually exclusive.
Rule 3: When a step must be simultaneously
activated and deactivated, it remains active –
this rule apply to Grafcet but not to Grafchart.
In Grafchart, the step will first be deactivated
and then activated again.
For Grafcet, many different interpretation al-
gorithms exists. A complete and unambiguous
algorithm is given by David (1995). This algo-
rithm is global. A global interpretation algo-
rithm 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 fire-
able. 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 the
Special care has to be taken to firing rules
interpreted differently in the two models.
If the Grafchart contains only steps and transi-
tions, 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 macro step must be replaced by an input
step and output step of Grafcet. Alternatively,
the macro step icon can be replaced by its inter-
nal 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 Figure 5.
T1
a procedurestep
T1
M1
name
parameters
I
T2 T2
procedure gp1
M1
T5

corresponding receptivities becomes true and a Procedure call

T5
T6
T3 T3
procedure called fire is automatically started. O
T6
This procedure takes care of the deactivation Grafchart
procedure
T4 T4
and activation of steps and the enabling and gp1

de-enabling of transitions. The local algorithm

is more efficient and less time demanding than
the global algorithm.
4.4 Graphical elements
The Grafchart language contains more graphi-
cal elements (building blocks) than Grafcet. The
new building blocks introduced in Grafchart
are: Grafchart process, Grafchart procedure,
process step, Procedure step and exception
transition. However, the new building blocks
does not extend the functionality of Grafchart
compared to Grafcet, but they facilitates the
implementation of more advanced sequence
structure. The development of Grafchart from
Grafcet can be compared to the evolution of as-
sembler languages to a high-level programming
Fig. 5. A Grafchartand an identical Grafcet.
If the Grafchart contains process steps, these
should be replaced by a parallel construct (and-
divergence) with two branches. One branch con-
tains an empty step followed by the transition
succeeding the process step. The second branch
contains an empty step followed by an alterna-
tive structure (or-divergence) where each path
contains a macro step followed by a sink transi-
tion. The macro steps are all identical and their
internal structure is that of the Grafchart pro-
cedure called by the process step. 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 is shown in Figure 6.
M1, M2, ... , MK

language like e.g., Java. T5 I

T5
T1 T6 T1
Grafchart
procedure T6
gp1 O
T2 T2

4.5 Grafchart to Grafcet transformation a process step

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

A Grafchart and a Grafcet are identical if, ap- T4 T4

M1 M2 MK

plied to the same input sequence, their output

sequences are identical. The transformation of
a Grafchart to a Grafcet consists of two steps.
First, the graphical elements must be changed
to those of Grafcet. Secondly, the action types of
Grafchart must be changed to those of Grafcet.
Fig. 6. A Grafchart(left) and an identical
Grafcet.
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 re-
placed 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.
4.6 Action transformation
Each step in Grafchart, that contains actions
can be replaced by one or several steps with ac-
tions in Grafcet, see Figure 7. The transforma-
tion 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 huge and messy Grafcet.
a
Impulse A
1
a scaninterval
Initially A
Always B
Finally C
Impulse B
b 1
b
Impulse C
c
1
c
Fig. 7. A Grafchart and an identical Grafcet.
4.7 Firing rules
The firing rules are not exactly identical in
Grafchart and in Grafcet. A step that has to
be simultaneously activated and deactivated
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 8.
T1
Initially A T1 a A*
T2
Fig. 8. A Grafchart and an identical Grafcet.
The activation of the extra step assures that
the step containing the impulse action is de-
activated. 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.
4.8 Advanced features
The two features in Grafchart, parameteriza-
tion and methods, cannot conveniently be re-
constructed in Grafcet. These two features are
traces from the object-oriented programming in-
fluence. The parameterization feature can only
be reconstructed by having one Grafcet for each
parameter setup, which is of course a bad re-
placement. The method feature can be recon-
structed by having ordinary macro steps as re-
placements for the methods. This will give the
same functionality but it will not allow the ap-
plication to be as well structured and organized.
4.9 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 the
structure of a Grafchart can be analyzed with
respect to e.g., deadlock situations, Johnsson
and Årzén (1998).
5. CONCLUSIONS
The two languages Grafcet and Grafchart have
been compared. Both languages are graphical
sequential languages. Grafcet was developed
with the aim to be a specification languages for
logical controllers, i.e., for local control applica-
tions. Grafchart is mainly based upon Grafcet
but it was developed to suit any sequential
control application, i.e., both applications on
the local and on the supervisory control level.
Grafchart and Grafcet have many similarities.
There are also some important differences, e.g.,
the execution models and the transition firing
rules are not identical and in order to facilitate
for the user Grafchart includes more graphi-
cal elements and more advanced features. In
the paper the differences between the two lan-
guages are pointed out and discussed.
6. REFERENCES
AFCET (1977): “Normalisation de la representation du
a
cahier des charges d’un automatisme logique.” J. Au-
1
tomatique et Informatique Industrielle.
ÅRZÉN, K.-E. (1991): “Sequential function charts for
knowledge-based, real-time applications.” In Proc.
Third IFAC Workshop on AI in Real-Time Control.
Rohnert Park, California.
DAVID, R. (1995): “Grafcet: A powerful tool for specification
of logic controllers.” IEEE Transactions on Control
Systems Technology, 3:3, pp. 253–268.
GENSYM COORPORATION (1995): G2 Reference Manual, Ver-
sion 4.0. Gensym Coorporation, 125 Cambridge Park
Drive, Cambridge, MA 02140, USA.
JOHNSSON, C. (1997): “Recipe-Based Batch Control Us-
ing High-Level Grafchart.” Licentiate thesis ISRN
LUTFD2/TFRT--3217--SE. Dept. of Automatic Control,
Sweden. Available at http:://www.control.lth.se/ ˜lotta/pa-
pers.html.
JOHNSSON, C. and K.-E. ÅRZÉN (1998): “Formal analysis
of batch recipes structured with Grafchart.” In FO-
CAPO’98 — Foundations of Computer Aided Process
Operations. Accepted for.