Using Grafcet To Structure Control Algorithms

Anders Wallén
Department of Automatic Control
Lund Institute of Technology
Box 118, S-221 00 Lund
Sweden
andersw@control.lth.se

Keywords: Real-time systems, sequential control, in- 2 Grafcet

telligent control, automatic tuning
Abstract
A method is proposed for structuring real-time control
algorithms. Grafcet is used for representing the con-
trol logic, and traditional programming languages are
used for describing the pure algorithms. A detailed
example with a relay auto-tuner is given.
1 Introduction
Industrial control systems contain a mixture of con-
trol algorithms, sequences and logic. The pure control
algorithms consist of algebraic, differential and dif-
ference equations coded in some traditional program-
ming language. Most of the research in control system
design has been devoted to development and imple-
mentation of such algorithms. Robust and adaptive
control are two areas where numerous design meth-
ods exist, leading to different control algorithms.
The logic surrounding the control algorithms is tra-
ditionally done by introducing boolean variables to-
gether with if and case statements in the algorithms.
Grafcet, or sequential function charts (SFC), is becom-
ing a standard tool in industry for programming PLC
systems. It can be viewed as a specialization of Petri
Nets [David and Alla, 1992]. Thus, the existing formal
methods for analyzing Petri Nets may be applied to
Grafcet.
An example containing the basic Grafcet building
blocks is shown in Figure 1. The Grafcet consists
of interconnected steps and transitions. The steps
represent the states of the Grafcet. A filled marker
indicates that a step is currently active. Steps drawn
with double squares are called initial steps, implying
that they are initially active. Associated with each
step is a number of actions to be performed while the
step is active.
The steps are connected via transitions, each having
a boolean condition. This condition is tested while
the transition is enabled, i.e., when the preceding
step is active. If the condition is true, the succeeding
step becomes active, and the preceding step becomes
inactive.
Initial step
Alternative paths
Parallel activities

As the complexity of the controller grows, the logic

tends to hide the actual control algorithm. Even if the
pure algorithm may be written in just a few lines, the Transition
final computer code might be very messy.
There is thus need for good tools to describe the Step
mixture of continuous algorithms with logic. In this
paper we will explain how an extension of Grafcet can
be used for this purpose. The approach combines the
clarity of the graphical representation of the logic with
Marker
the ability to perform high-level operations using or-
dinary programming languages. The obtained struc-
ture will simplify both development, debugging and
maintaining of the system. To illustrate the ideas, an
example with a relay auto-tuner for a PID controller
is discussed in more detail. Figure 1. Basic Grafcet building blocks.

Figure 2. A macro step with exception transition.
Grafcet supports alternative and parallel paths. The
syntax for these is shown in Figure 1. In order to
structure the Grafcet hierarchically, it is possible to
use macro steps, see Figure 2. A macro step is a
way of condensing an arbitrary number of steps and
transitions into just one step. It has one enter step
and one exit step, and general Grafcet structures in
between. The enter step is activated as soon as the
macro step becomes active. The transitions following
the macro step may not be fired until the exit step is
active.
The power of Grafcet can be increased substantially
by some minor modifications, see e.g. [Årzén, 1994].
In this paper, the most important extension is that
we allow general statements and expressions in the
actions and transition conditions. Another useful ex-
tension is the exception transition, found to the left
in Figure 2. It is connected to a macro step, and it is
enabled all the time while the macro step is active.
This makes the exception transition suitable for han-
dling failures, abortion and other types of exception
handling.
3 Mixing discrete-time and
continuous-time systems
A typical realistic control system contains a mixture of
algorithms running in continuous and discrete time.
Here, ’continuous-time systems’ refers to traditional
control algorithms, which are sampled with a fixed,
fairly high, sampling rate. The discrete-time events
are assumed to happen less frequently, either ran-
domly or regularly. Sequential controllers is an im-
portant class of discrete-time systems that are often
run together with continuous-time controllers, e.g. in
batch control.
The logic in a control system can be viewed as a
discrete-time system interacting with the continuous-
time control algorithms. The logic appears at different
levels of the control system. On the signal level, the
logic may consist of range checks for measured sig-
nals, control signal saturation, and other tests. In this
context, these checks are randomly occurring discrete
events which interfere with the continuous algorithm.
They are primarily done with simple logic inside the
control algorithms. It is convenient to interpret the
limit tests as non-linear modifications of the (mostly)
linear control algorithms, instead of emphasizing the
discrete-time property.
At the control loop level, there might be a lot of logic
governing the execution of the control algorithm. This
is especially true when implementing a controller with
more autonomy. For example, in order to successfully
install a controller, it is necessary to first make some
loop assessment, i.e. find the basic characteristics of
the process [Åström, 1993]. This includes a number
of more or less complex off-line and on-line tests, as
well as reasoning about the results from these tests.
Further, there may be several different phases and
modes of operation. Which mode to use may be decided
by various conditions such as operator commands,
working regions, scheduled control goals etc. During
on-line control, it may be desirable to do performance
assessment to see whether the control loop behaves
as intended. Based on this, a decision may be taken
to retune the controller parameters. Finally, it may
be possible to perform on-line diagnosis and fault
handling on the local loop level. In Section 4 it is
shown how Grafcet can be used to address these
problems.
On the global control system level, the discrete-time
activities appear in control system (re)configuration,
plant start-up and shut-down, planning and man-
ufacturing, global fault handling and diagnosis etc.
[Årzén, 1994] shows how Grafcet can be used in this
case.
4 Using Extended Grafcet to describe
mixed systems
Many of the problems concerning the logic on the
control loop level are conveniently modeled using a
Grafcet approach. This is especially true when the
logic and decisions have a sequential nature.
In traditional Grafcet, the actions are normally ba-
sic operations on simple data structures. There are ba-
sically two different types of actions: those performed
only once when the step becomes active, and those ex-
ecuted continuously while the step is active. Similarly,
the transition conditions are just simple tests. The be-
havior of the Grafcet during execution is standardized
and quite straightforward.
By allowing more general expressions in actions and
transition conditions, Grafcet becomes a powerful tool
for structuring more complex algorithms. However,
the simple rules for executing actions in a standard
Grafcet must be altered in order to specify the be-
havior of the extended Grafcet. The approach used in
this paper allows every step to execute two different
pieces of code, one initial action upon entry and one
continuous action while the step is active. In this case,

C:{u = u+udot/h;}
(u>umax || abs(y)>ymax)
C:{u = u-udot/h;}
(u-u0<eps)
I:{u = u0;}
(stationarity(y))
I:{prop = analyze(u,y);}
Figure 3. The Grafcet for a simple loop assessment
experiment
“continuous” of course means that the action is exe-
cuted with a fixed sampling rate. Each sample, the
Grafcet behaves as follows:
1. Fire all fireable transitions.
2. For all steps becoming active in 1, execute their
initial actions.
3. Repeat 1-2 until no more transitions may fire.
4. Execute the continuous actions of all active steps.
This behavior has a number of features that the
designer of the Grafcet must be aware of. At every
sample, the algorithm above searches for stability,
i.e. a situation where no transitions can be fired.
This is a potential danger, since it is possible to
create, but often difficult to detect, situations where
all transitions in a loop are always fireable. Another
feature of the execution algorithm is that the initial
actions may influence variables in the system, and
thus change the values of the transition conditions
in the same sample. Continuous actions, on the other
hand, may not cause these changes until the following
sample.
The behavior described above has been chosen since
it is rather simple and straightforward, and yet pow-
erful enough for the applications that have been stud-
ied. It is not obvious, though, that this behavior is
desired in all possible applications.
A very simple example using C syntax in the ac-
tions and conditions is shown in Figure 3. The actions
labeled I: and C: are initial and continuous actions,
respectively. This part of the Grafcet models a possible
part of a loop assessment experiment. The process in-
put u is increased until either u or the measured value
y reaches its maximum value. Then, u is decreased to
its initial value. When the process has reached sta-
tionarity, the function analyze is called. This returns
some properties of the process that can be used in
decisions later on.
5 An example: Automatic PID tuning
A scheme for automatic tuning of PID controllers will
now be modeled using the ideas from the previous
section. The tuning procedure consists of a relay feed-
back experiment, followed by a small closed-loop step-
response. The relay experiment will give the ultimate
period and gain, and the step response will give the
static gain. This information is used to tune the con-
troller parameters according to the empirical rules
based on dominant pole design presented in [Åström
and Hägglund, 1995].
The relay experiment consists of the following steps:
0. The operator has to make sure that the system is
in steady state before starting the tuning experi-
ment.
1. Check the process output and the reference value.
If they differ too much, abort the tuning experi-
ment.
2. Freeze the control signal and estimate the mea-
surement noise.
3. Set the relay hysteresis and the desired oscilla-
tion amplitude.
4. Increase the relay amplitude until the output
reaches either of the crossing levels.
5. Set the sign of the process gain accordingly, if this
has not been given a priori.
6. Switch the relay, and wait for the process output
to change direction.
7. Wait for the other crossing level to be reached.
8. If there is a satisfactory oscillation, stop the tun-
ing experiment, otherwise go to step 6.
9. Compute new controller parameters.
10. If a refined tuning is desired, start the step re-
sponse experiment, otherwise switch to automatic
mode.
The optional step response experiment should do the
following:
1. Close the loop with a preliminary PI controller
obtained from the relay experiment.
2. Await stationarity.
3. Make a small step change in the reference value.
4. Await stationarity
5. Compute refined PID parameters and switch to
automatic mode.
The scheme above should probably be modified in
order to work for a larger class of plants, but it can be
used as an illustration of the modeling using Grafcet.
 Manual
Auto
Abortion
recovery Tuning
Figure 4. The main operating modes.
The PID controller used in this example is on po-
sition form. It uses set point weighting on the pro-
portional term. Anti-windup is obtained by a track-
ing scheme as described in [Fertik and Ross, 1967].
The idea is to make the computed PID control signal
equal to the actual control signal being sent to the
plant. This is done by altering the value of the inter-
nal state of the controller, i.e. the integral part. To
obtain both anti-windup and bumpless mode changes,
the PID control signal and the state updating must be
computed each sample in all modes. Thus, this com-
putation can be done in a continuously running proce-
dure, independent of the current mode. The grafcet de-
scribed below only selects what control signal should
be used.
The main modes (manual, auto and tuning) of the
controller, and the logic for switching modes is mod-
eled by the Grafcet in Figure 4. The step labeled
Manual has a continuous action {u = uman;} to deter-
mine the control signal. The user may set the value of
uman. Likewise, the Auto step has an action consisting
only of the statement {u = upid;}. The Tuning step
is a macro step and will be described later.
The exception transitions to the left of the tun-
ing step are enabled during the whole tuning exper-
iment. This is a convenient way of doing exception
handling when the tuning experiment for some rea-
son is aborted. This may for example happen if the
user desires to go to manual or automatic mode while
tuning.
The expansion of the tuning step in Figure 4 is
shown in Figure 5. The basic actions of the chart
are explained by the texts next to the steps. All
tuning sessions start by initializing and running a
relay experiment. For the refined tuning method, a
preliminary design is calculated and used in a closed
Init
Relay experiment
Timed out. Preliminary
No oscillation. design
Step response
experiment
Final
design
Figure 5. Expansion of the tuning step.
loop step response. These steps are bypassed for the
simpler methods. The tuning session ends with a
calculation of the new controller parameters.
The Init step, expanded in Figure 6, initializes the
variables and checks the set point and noise level. If
the measured variable y is too far from the set point,
the tuning experiment will be aborted by activating
the exception handling in Figure 4. The noise level
is checked by keeping u constant and measuring the
deviations of y from its nominal value during a fixed
number of samples. If information about the noise is
available, e.g. from a previous experiment, this step is
bypassed. Finally, the relay hysteresis is set to twice
the maximum detected noise amplitude.
The chart for the relay feedback experiment is
shown in Figure 7. The first step has a continuous ac-
tion that each sample increases the relay amplitude,
and thus the control signal, by a constant factor. The
following transitions wait for y to become larger than
the hysteresis level. If the gain sign is not set a pri-
ori, the first switching of either level is detected by
the right transition, and the gain sign is set accord-
ingly. When the plant has right half-plane zeros, this
may cause problems, since y might initially go in the
wrong direction. By setting the gain-sign a priori, the
left transition will wait for the correct switching level.
The main part of Figure 7 consists of a loop which
will switch the relay until a stable oscillation is es-
 Increase relay amplitude,
Initialize variables wait for relay crossing

Setpoint
check
Set gain sign
Setpoint OK

Check noise level Set the control signal

and wait for maximum

Set relay hysteresis Maximum reached

Update relay
amplitude

Wait for relay crossing

Figure 6. Tuner initialization.

tablished. The first step in the loop has two actions.
Initially, the relay switches the value of the control
signal. Then, the maximum deviation of y during the
new half period is recorded each sample. The follow-
ing transition is fired when the deviation of y has de-
creased enough from its maximum value. After the
peak has been detected, the step labeled Maximum
reached stores the amplitude.
The step Update relay amplitude becomes active
only after the third relay switch, and is by-passed oth-
erwise. The purpose of this step is to adjust the relay
amplitude in order to make the output oscillate with
a desired amplitude. The next step has no actions, but
just waits for its output transition to fire. This hap-
pens when y reaches the next crossing level. The last
step in the loop stores the current half period time and
determines the current oscillation status. This decides
which path to choose in the alternative branching. If
there is a stable oscillation, i.e. the last oscillation
peaks have been almost equal, the relay experiment
has succeeded, and execution returns from this macro
step.
Two situations will abort the relay experiment be-
fore it has succeeded. Firstly, when the relay has
switched too many times without any stable oscilla-
tion, the lower right step in Figure 7 becomes active.
Secondly, if the time between two consecutive switches
becomes too large, the exception transition in Figure 5
will fire. In both cases, the exception handling in Fig-
ure 4 will be activated.
Switching level reached,
check oscillation status
Continue Abort
Tuning
succeeded
Timed out.
Too many
oscillations.
Figure 7. The relay experiment.
The step response experiment is straightforward
and is not further discussed here.
Going from the verbal description of the algorithm
to the Grafcet involves a few intermediate steps. A
suitable data structure must be chosen, and the algo-
rithm has to be described in detail using this struc-
ture. A detailed specification will make the construc-
tion of the Grafcet easy, though there is still some non-
uniqueness in choosing the Grafcet structure. Macro
steps can be used for grouping the steps hierarchi-
cally into different phases of the algorithm. This is
especially useful when the exception handling behav-
ior is similar for a set of steps, as is the case for the
auto-tuner.
The auto-tuner has been implemented and simu-
lated in G2 using the Grafchart toolbox [Årzén, 1994].
The control panel may look as in Figure 8. The slid- y (solid) and u (dashed)
0.1

0.05

PID 1 0

u man -1.0 1.0 −0.05

0.2 −0.1
yr -1.0 1.0 0 50 100 150 200 250 300 350 400 450 500
0.2
PID1, a pid-controller Figure 9. A tuning experiment for
Manual K 1.0 G(s) = e−10s /(2s + 1)3 .
Auto Ti 120.0
Td 0.0
Tune
Refined PID tuning
B 1.0
0.4

Design Method: 0.3

0.2
Ziegler-Nichols Refined PI
PI Refined PID 0.1
PID 0
Dead time Tuner settings
−0.1
0 50 100 150 200 250 300 350

Ziegler−Nichols method
0.4
Figure 8. The control panel of the controller PID1.
0.3

0.2
ers are used to set the manual control signal and set
point, respectively. The traditional PID parameters 0.1

are displayed to the right, and they may be edited 0

manually. The lower part contains buttons for selec- −0.1

tion of design method. The ones to the left only require
a relay experiment, whereas the refined methods also
require a step response experiment.
The simulation results of a typical tuning experi-
ment with both relay feedback and a step response
is found in Figure 9. The plant in the simulation has
the transfer function G (s) = e−10s/(2s + 1)3 . Based
on the tuning experiment a refined PID tuning is cal-
culated. Figure 10 shows the response to a set point
change and an input load disturbance, both with pa-
rameters from the refined PID method and Ziegler-
Nichols method. For this particular plant, the new
method obviously performs much better than Ziegler-
Nichols method.
6 Implementational issues
G2 [Gensym, 1992] is a good tool for rapid real-
time software prototyping. It was originally used for
developing expert systems, but it has become useful
for other types of applications as well. It is fairly
easy to design graphical user interfaces using built-
in tools. G2 also has a built-in real-time simulator,
which makes it easy to test control algorithms against
a simulation of the plant.
In the Grafchart toolbox, steps and transitions are
G2 objects, linked together by arcs. The actions are
written as G2 rules, which are placed upon the sub-
workspaces of the steps. Initial actions are imple-
mented using initially rules, which are executed
once when a step becomes active. Continuous actions
0 50 100 150 200 250 300 350
Figure 10. Response to a set point change and an
input load disturbance.
are implemented as unconditionally rules, which
are executed regularly while the step is active. The
transition conditions are treated in a similar way. The
rules may call G2 procedures written in the built-in
pascal-like programming language.
Grafchart together with the real-time simulator is
a good environment for developing systems mixing
continuous and discrete time activities. A drawback is
that G2 is not well suited for hard real-time demands.
To meet this, routines have been developed in G2 to
translate the Grafcet into C + + code, which may be
executed in a real-time control system. This way, it is
possible to test the algorithms on a real plant.
7 Conclusions
The example in Section 5 shows that Grafcet is a pow-
erful and intuitive modeling tool for systems mixing
pure algorithms with sequencing and logic. A good
structure is obtained by the graphical representation
of the logic, and the ability to perform advanced ac-
tions using ordinary programming languages.
We will continue to study new auto-tuning methods
and explore how the information given by the exper-
iments can be used. Grafcet will be used as a conve-
nient tool for structuring these methods.
8 References
ÅRZÉN, K.-E. (1994): “Grafcet for intelligent super-
visory control applications.” Automatica, 30:10,
pp. 1513–1525.
ÅSTRÖM, K. J. (1993): “Autonomous process control.”
In Proceedings of The Second IEEE Conference on
Control Applications, Vancouver, British Columbia.
ÅSTRÖM, K. J. and T. HÄGGLUND (1995): PID Control.
Instrument Society of America, Research Triangle
Park, North Carolina.
DAVID, R. and H. ALLA (1992): Petri Nets and
Grafcet: Tools for modelling discrete events sys-
tems. Prentice-Hall International (UK) Ltd.
FERTIK, H. A. and C. W. ROSS (1967): “Direct digital
control algorithms with anti-windup feature.” ISA
Trans., 6:4, pp. 317–328.
GENSYM (1992): G2 Reference Manual, Version 3.0.
Gensym Corporation, 125 CambridgePark Drive,
Cambridge, MA 02140, USA.