2

Sequential control in the past and

present

In this chapter we brie y describe how sequential control problems have been
solved in the past and present. In Section 2.1 we take a control engineer's
viewpoint. Before describing how sequential control has been formulated in the
domain of arti cial intelligence (AI) (Section 2.3) we given a short introduction
to complexity theory in Section 2.2. Some other related areas are described in
Section 2.4.

2.1 Sequential control from a practical view-

point
In this section we give a short survey over sequential control in the past and
present from a control engineer's viewpoint. Section 2.1.1 gives some examples
of sequential control problems, and some techniques to design and implement
sequential control schemes are described in Section 2.1.2. In Section 2.1.3
we describe when automatic synthesis of such schemes may be useful, and
formulate some requirements for such methods.

2.1.1 Sequential control in reality

As described earlier a major part of the hard- and software when developing
a controller is devoted to sequential control 14]. In this section we give a
few examples of sequential control problems. Typically the sequential parts
are invoked during startup or shut-down to bring the system into its normal
operating region or into some safe standby region respectively, see e.g. Example
2.1. Among the more obvious examples we nd manufacturing systems and
assembly systems, see e.g. Example 2.3.

5
6 Sequential control in the past and present

Example 2.1 When handling chemical processes, it is, for example, of utmost
importance that the reactants have speci ed pressures and temperatures before
the chemical reaction is allowed to start. This might require fairly complex
initialization procedures where actions have to be performed in a certain order
to prevent uncontrollable reactions or to get any reaction at all. Consider
Figure 2.1.

MV1

Reactant 1
MV3

Heater
Cooler
MV2
MV4
Reactant 2

Resulting
product

Figure 2.1: A chemical process plant.

To initialize the process in Figure 2.1 safely we may have to do the following:

1. Open solenoid valve MV 1 until the pressure p 1 is obtained.

2. Turn on the heater until the temperature T1 is obtained.

3. Open solenoid valve MV 2 until the pressure p 2 is obtained.

4. Start cooling via valve MV 3.

p
When the pressure 3 is obtained the process may be stable and we can activate
the continuous input/output ow control. �
Another example of the same character is the Steritherm process described in
Example 2.2.

Example 2.2 Steritherm is an Alfa-Laval process for UHT sterilization of

liquid food products, for example milk or cream. The liquid is heated to a high
temperature during a short time interval. This will kill all micro organisms in
the product and the product can then be stored at room temperature. The
product is heated indirectly using plate heat exchangers, and cooled in the
same way before it enters the packing machine.
2.1 Sequential control from a practical viewpoint 7

In Figure 2.2 a picture of a simulation system is shown. The simulator

was developed at the Department of Automatic Control at Lund Institute of
Technology using the expert system tool G2 42] (a short description of G2 is
given in Section 7.1.1). A description of the implemented plant can be found
in 12].

Figure 2.2: A simulation system of a Steritherm process plant.

The process is continuous but, once again, there are also signi cant sequen-
tial parts. Before production starts the plant must be sterilized and it must
also be cleaned at speci c time intervals. These parts are essentially sequential.
As can be seen in Figure 2.2 the typical actions are to turn on or o speci c
motors and to change the uids ows by closing or opening valves. There are
also ordinary PI-controllers and automatic mechanical devices that control the
temperature, the input ow and the pressure while the plant is running in its
normal operating mode. These can be turned on or o . �
We end this section by a more traditional example of sequential control, namely
a system of manufacturing type.

Example 2.3 Suppose we want to design an automatic system for unloading

a freight carrier as illustrated in Figure 2.3. The system contains four di erent
8 Sequential control in the past and present

e ectors, or motors, for moving the trolley horizontally, for moving the grabber
vertically, for opening and for closing the grabber, and opening the hopper
hatch. Information about the state of the system is provided through ten
sensors indicating the position of the trolley, the position of the grabber and
so on. �
2.1.2 Designing and implementing sequential control
schemes
Basically, practical sequential control problem solving consists of, or should
consist of, four steps, namely:

1. Specifying the goals

Before starting the actual design procedure the goal of the design, i.e.
what the resulting controller should achieve, must be clearly stated.

2. Specifying the means

In this step the means to achieve the speci ed goals are recognized. For
instance we identify the available sensors and actuators of the plant. This
is where a model of the plant is being developed.

3. Synthesis
Synthesis of a control scheme, or planning, is the process of deciding
upon a control scheme, i.e., nding an order in which the given1 actions
should be performed to achieve the speci ed goals. By actions we mean
operations such as turning on or o motors, or opening or closing valves.
Thus the set of actions is de ned by the available actuators and control
signals.

4. Implementation
In this step the control scheme is implemented, i.e., the actual controller
or sequencer hard- and/or software is designed.

In practise these four steps seldom occur as distinct parts in the design proce-
dure. Normally only a minor part of the time is spent on the rst two steps,
and very seldom any formal models are being used. Instead the goal and
the plant model are typically described informally in words, and the designer
starts the synthesis without having access to a formal plant model. Further-
more the synthesis and the implementation is often carried out interleaved.
One important reason for all this is the absence of systematic design methods.
Since the rst two steps normally are carried out informally we do not
describe them further at this stage.

Usually the set of actions is given and well de ned when the control engineers starts to
�
work.
2.1 Sequential control from a practical viewpoint 9

Trolley
E1 Winch motor
G2L G2AR G2R E2

Hatch
Grabber E3 G4O
G1U G3O
G3C

Storage

Wished Cycle
G5F
E4

G1D

OPERATOR PANEL

START STOP EMERGENCY STOP ALARM ACKNOWLEDGEMENT

Control signals Description Outputs Sensor signals Logic Description Input signals

E1D Move grabber down. G1D H Grabber down.

E1U Move grabber up. G1U H Grabber up.
E2R Move trolley to the right. G2R H Trolley in rightmost position.
E2L Move trolley to the left. G2L H Trolley in leftmost position.
E3C Close grabber. G3C H Grabber closed.
E3O Open grabber. G3O H Grabber open.

E4O Open hatch.. G5F L Storage full.

G4O H Hatch open.
ALARM Storage full. Turn on alarm lamp. G2AR H Trolley almost in rightmost
position.
START H Push-button start affected.
STOP L Push-button stop affected.
EMERGENCY L Emergency stop affected.
STOP
ACKNOW- H Ackment push-
LEDGEMENT button affected.

Figure 2.3: Sketch over the freight carrier unloading system.

10 Sequential control in the past and present

Synthesis
As stated above, the lack of systematic design methods implies that the synthe-
sis of the controller is often integrated with the implementation. Hopkins and
Walker 83] observe that the requirements are rarely expressed formally, but
instead given by drawings such as plant layouts, timing diagrams etc. They
suggest the use of state transition diagram when a sequential control scheme
should be designed. Other approaches are mainly focused on using structured
high level languages such as those described below, and preferable GRAFCET
25, 53, 122, 129].

Implementation
A sequential control scheme can be implemented in several ways. The rst
sequential controllers were implemented using some kind of mechanical se-
quencers. Today electro-mechanical sequencers are still, to some extent, used
in for example washing machines, dish-washing machines and co ee machines.
Electro-mechanical relays has been widely used to build sequencers. They can
imitate the function of a sequencer, but is more exible since the program is
stored by the electrical wiring. Even if they do not dominate the market any
more they are still used in smaller systems and in safety critical parts of a plant
controller. Often relays are used in combination with modern computer based
controllers as an independent security system. Later, but to a small extent,
hardwired electronic devices such as transistors came to replace the relays.
Nowadays the market are dominated by PLC:s (Programmable Logical Con-
trollers). The PLC-systems are specialized computers developed for control
purposes only. They are exible and comparably cheap. A major drawback is
that the programming languages supplied di ers from machine to machine and
they are often at a very low assembly-like level. These languages are not easy
to use, and a program developed for one PLC-system cannot easily be moved
to another system. However, the PLC-manufacturers sometimes supply some
kind of higher level language to make them easier to use. The by far most
common \high level" language is \relay ladder logic", but for example Boolean
logic and function block diagrams have also been used 108]. The graphical
relay ladder programming environment was developed to allow descriptions of
the control scheme in the same manner as for relay systems, and the di erent
symbols imitate the physical relay components. It is thus easy to use for sta
used to the classical relay technique, and is highly accepted and understood by
factory oor personnel, e.g. operators and service personnel. The fact that it
is a graphical language has contributed to making relay ladder programming
so popular. It is easy to follow the ow of electrical signals, and the activity
during execution can be easily displayed. However, it is not always trivial to
see the actual ow of control commands that are being represented by the
2.1 Sequential control from a practical viewpoint 11

+ -
D
A B

Figure 2.4: A simple relay ladder diagram realizing D A ^:B _ C

=( ) ,
where ^ denotes logical and, : logical not and _ logical or.

electrical signals. An example of a simple relay ladder diagram is given in

Figure 2.4.

Since the relay ladder logic was developed, applications and programs have
grown in size and in complexity. Often additional internal relays need to be
added to identify events, thus making the logic more complicated and making
it even more di cult to follow the actual control sequence, i.e. realize what
actually happens in the plant. Another disadvantage is that a relay ladder
logic program is scanned from the beginning to the end, and thus every step in
the program is scanned whether it need to be executed or not. This results in
unnecessary slow program execution, but it can to some extent be dealt with
by using subroutines that can be called upon from the main program when
needed. Even if the PLC-systems of today are very exible, the extensive
use of relay ladder diagrams has delayed the development of new and e cient
programming techniques. Controllers have been developed and implemented
using basically the same methods as when electro-mechanical relays dominated
the market, forcing the developers to do programming at a very low level.

By the introduction of sequential function charts (SFC) 45, 84], also known
as GRAFCET, the possibility to use abstraction has to some extent been
facilitated. GRAFCET shows many similarities with Petri nets 45, 127],
but is more aimed at solving practical sequential control problems, and is
therefore basically a restriction of the Petri net formalism. It is a carefully
speci ed international standard, and compilers that can generate PLC-code
from a GRAFCET chart have been developed and are commercially available
28, 87, 106]. It can be used not only for implementing controllers, but for
modelling, specifying and simulating plants. A GRAFCET chart displays the
state of the controller, i.e. which actions that are currently being executed.
Together with the information supplied by the transition conditions this gives
the state of the plant. Thus the process of locating plant faults is simpli ed.
The program itself is a good documentation of the controller, and by using
macro steps as explained below a top-down design is supported. Even when a
compiler that translates a GRAFCET chart to PLC-code is not available, it is
still advisable to use GRAFCET to modularize and structure the program and
12 Sequential control in the past and present

thereafter translate it to e.g. relay ladder logic 75]. Although the GRAFCET
formalism represent a promising improvement in abstraction, it is important
to remember that it is still nothing but a high level programming language.

Basic notions of sequential function charts

We will not give a full description of GRAFCET, but only state the main
parts. See, for example, 45, 84] for a more comprehensive account.
A GRAFCET chart is mainly composed of steps interconnected via directed
links, so called transitions as in Figure 2.5. The steps can either be active,
which is illustrated by a highlighted dot called a token, or inactive. Once a
step is activated its associated action is executed (e.g. open a valve, start
a motor). Conversely, deactivating a step implies that the step's action is
inhibited. The change from an active step to an inactive one is determined
by the transition located between the steps in question. More precisely, a
state change occurs when the so called transition condition associated with
the transition becomes true (e.g. when a sensor is triggered).
In addition to the ordinary action type as described above, the GRAFCET
standard de nes a number of simple action types (stored, conditional, delayed,
time limited) as well as combinations of them. For example, a stored action is
an action that is initiated by a set step and is continuously performed until a
subsequent step executes a reset action.
Since most practical sequential control schemes are not strictly sequential,
the GRAFCET standard also includes two control structures { simultaneous se-
quences (or parallel branches) and sequence selection (or alternative branches).
The start and the end of parallel branches are represented by special objects
consisting of two parallel and horizontal bars, see Figure 2.5. Once a parallel
branch is encountered, all underlying sequences are activated simultaneously,
and thereafter executed independently of each other. To be able to continue
from the convergence point of a branch, all incoming branches must be ready,
i.e. all steps connected to the \closing" point must be active at the same
time. Alternative branches must start with transition conditions as in Fig-
ure 2.5. These conditions should be carefully chosen so that no more than one
transition condition is true at the same time.
The GRAFCET objects can only be connected to each other according to
some basic rules. For example, two steps must be separated by exactly one
transition and two transitions must be separated by one step. Again we refer
to Figure 2.5 where a syntactically correct graph illustrating many of the ideas
behind GRAFCET is given.
Apart from the above a GRAFCET chart can contain loop branches (see
Figure 2.5), which makes it possible to create iterations, and the standard can
be extended to contain macro steps where a step itself contains a GRAFCET
chart. Since macro steps are not included in the original standard, there is no
2.1 Sequential control from a practical viewpoint 13

Type of Control Constraint

action signal Action (action executed
only if this is true)

Initial Step S0 C E2 G5

Transition
Transition G4 condition
Simultaneous sequences

Step S1 S3

G3*F2 G2 or V1
A complete graph
must be closed.
S2 S4

Alternative branching
G7 not G7

S5

F4

S6

G4
Loop chart

S7

not G5 G5

Figure 2.5: Concepts and ideas found in GRAFCET.

14 Sequential control in the past and present

Subgraph S23
Subgraph S2

S231
S0 S21

S1 S22 S232 S233

S2 S23 S234 S235

S3 S24
S236

Figure 2.6: The use of macro steps in GRAFCET.

uniform syntax for them. An example of the use and syntax of macro steps
is shown in Figure 2.6. To further illustrate the basic ideas in GRAFCET
we show how a control chart for controlling the previously presented freight
carrier may look like.

Example 2.4 Consider the freight carrier in Example 2.3. A GRAFCET

chart for unloading the freight carrier is shown in Figure 2.7. �

2.1.3 Automatic synthesis of control schemes

Automatic synthesis of control schemes can only be achieved if a plant model
is available. Thus it emphasizes the two rst steps in the design procedure
described in Section 2.1.2. Consequently the designer must rst chose a mod-
elling language, then specify the goals of the controller and model the plant
using this language. Finally this model can be used by a systematic procedure
to create a control strategy. A system able to automatically create control
schemes can of course also be used on-line if it is fast enough. This possi-
bility opens up completely new applications such as operator supervision and
simpli ed error recovery and restart procedures as is exempli ed below.
2.1 Sequential control from a practical viewpoint 15

S1 (Move to freight carrier)

R: /EMERGENCY STOP
S11 E2L

S5 /G2AR

START S12 E2L

S E4O = 0
S6 OPERATION
S2 (Fill grabber)

/STOP E1D
S21

G1D

S22 E3C

R: /EMERGENCY STOP S3 (Move to storage)

S31 E1U

S0
G1U

OPERATION S4 (TömS skopan)

S32 E4O = 1

S1 C E2R /G2AR
S41
+ G4O
G2L Alarm

G5F /G5F
S2
S42 ALARM
G3C
G5F*ACKNOW-
S3 LEDGEMENT

G2R S43 E3O

S4 G3O

WAIT1*G3O S44 D WAIT1 3 s

Figure 2.7: Control sequences for the freight carrier unloading system.
Here n means logical not and + logical or.
16 Sequential control in the past and present

Adding new devices to the plant

A situation where systematic synthesis of control schemes is particularly inter-
esting is when dealing with a plant with varying structure. It is common that
new devices are added when the control scheme has already been developed,
and hence it must be changed to take the new devices in the plant into account.
It may be di cult to realize how the plant changes a ect di erent parts of the
program. However, if the plant is described by a model and the control scheme
is automatically generated from this model, only the model has to be changed
when the process has been changed.

Operator support
Automatic plan generation can also be used for operator support as in Fig-
ure 2.8. A supervisor checks if the operations that the operator wants to
perform are allowed. If, for example, the operator wants to open a speci c
valve, the supervisor should quickly tell the operator that to be allowed to
open this valve he or she must rst, e.g., open another valve. Another possi-
bility is to automatically generate and execute a sequence of actions resulting
in the opening of the valve. This can be viewed as semi-automatic control.

Operator

Supervisor

Plant Controller

Plant

Figure 2.8: A supervisor used for operator support.

2.1 Sequential control from a practical viewpoint 17

Plant fault and error recovery

Normally when creating sequential control programs one must take into ac-
count not only the ordinary operation of the plant, but also what should be
done when a plant fault occurs. For each possible fault situation we must con-
struct a control strategy that eliminates the e ects of, or at least reduces the
damage caused by, the fault. This control strategy is traditionally constructed
o -line. When a fault occurs during operation it must be decided beforehand
which plan to follow. To verify that such a program is correct is very costly,
and in practice each case must be simulated, which due to time constraints
often is impossible. There are in principle three di erent situations.

When a plant fault occurs the plant should be taken to some prior de ned
\safe state". This \safe state" may depend on the current fault situation,
that is, di erent fault may lead to di erent \safe states".

The problem is to design a control scheme transforming the current fault

x
situation, i.e. the current initial state 0, into a prior de ned \safe state"
x ?. Note that the \safe state" may be the same for many fault situations.

A slightly di erent situation occurs if something in the plant breaks

down. If possible we want to keep the process running even if there are
some \missing actions". If this is not possible at least we want to reach
a \safe state".

The initial state x

0 can be any state in the state space, and the set of

\allowed" actions at a speci c time t is

At
~( ) = A factions which are \out of order"g;
where A is the set of available actions during normal operation. The
actions which are out of order may, for example, be due to motors that
are broken. The problem is to nd a sequence of actions in the set ~ A
which transforms the current initial state
0
x
into the desired nal state
x?. If this is impossible because of some missing actions, we want to

come as close as possible.

An example of the initialization problem is when there has been an emer-

gency shut-down, and we want to re-start the process. Usually this is
done manually by the operator.

The nal state x

? and the set of available actions A are given beforehand,
but the initial state is not fully speci ed until the plan is needed. From
x
the beginning we only know that the initial state 0 belongs to a given
S
set 0 . Given an initial state
0
x 2S t
0 at a certain time , the problem
consists of nding a control strategy transforming the current initial state
x0 into the nal state ? . x