MODEL-BASED CONTROL SYNTHESIS FOR DISCRETE EVENT SYSTEMS

Mourad Chouikha, Eckehard Schnieder Bernhard Ober

Institute of Control and Automation Engineering Siemens AG
Technical University of Braunschweig Automation and Drives
Langer Kamp 8 P.O. Box 3220
D-38106 Braunschweig, Germany D-91050 Erlangen, Germany
Phone.: +49-0531-391-76 67 Phone.: +49-9131-7-24876
Fax: +49-0531-391-51 97 Fax: +49-9131-7-31509
E-Mail: {chouikha, schnieder}@ifra.ing.tu-bs.de E-Mail: bernhard.ober@ERL6.siemens.de

ABSTRACT The main design approaches for the control of discrete

event systems using Petri nets are [2]:
In control engineering models of the controlled systems
are the basis for controller synthesis as well as for analyti- controlled behaviour approach,
cal or simulative examination of open or closed-loop be- logic controller approach and
haviour. This model-based methodology is being trans- control theoretic approach.
ferred into automation engineering by means of a devel- In the controlled behaviour approach the model describes
opment environment for the programming of logical con- the behaviour of the plant and the controller joined to-
trollers. Petri net models of the controlled system allow an gether. For the implementation the control algorithm has
automatic computation of the control algorithm. The con- to be extracted from the combined model.
trol algorithms which are equally represented as Petri nets The logic controller approach tries to define the input-
are then automatically translated into code for program- output behaviour of the controller, which satisfies all the
mable logic controllers (PLCs). system requirements. Using this method the control pro-
gram can be deduced directly from the obtained I/O-
Keywords Petri nets, Modelling, Synthesis, Code behaviour. This approach leads to the physical implemen-
Generation, PLC. tation of the control program, but simulation is required to
validate the closed-loop behaviour.
1. INTRODUCTION
connections to
superior controllers
The aim of modelling in automation engineering is to
describe a process with a formal language, which allows connections to
us to generate control algorithms and to simulate, analyse neighbouring
controller controllers
and verify the controlled system by exploiting the
structural and dynamic properties of the description
language. In the literature several special classes of Petri
nets, various kinds of condition/event systems, temporal actors sensors
logic, boolean differential calculus or some combinations
of these are employed. For a selection see [3], [4], [5] and
[7]. In this context Petri nets have many advantages over plant connections to
neighbouring
other description languages. Indeed the graphic notation of processes

Petri nets allows an easy and intuitive modelling of .

systems. Petri net models are generally more compact and
more powerful. The algebraic foundation of Petri nets
facilitates efficient analysis and synthesis, for which a
large number of tools exists.
In this section we present an overview of the different
control synthesis methods described in the literature
focusing on an efficient method, the model-based control
synthesis with Petri net models. The most discussed
methods use special classes of Petri nets, such as
controlled Petri nets and labelled nets.
Fig. 1: STRUCTURE OF AUTOMATION SYSTEMS
The control theoretic approach has been investigated by
numerous research teams and is getting more and more
popular. The approach adopts the controller synthesis
paradigm from control theory for continuous systems. A
decomposition of an automation system leads to a
structure very similar to a control loop in control
engineering (Fig. 1). The approach is based on separate libraries comprise pre-defined objects, which can be
models of plant and controller. inserted, combined and specified (define parameter)
during modelling with a design tool.
In this paper a complete methodology for modelling,
specification, model-based controller synthesis and code According to the modelling methodology presented in [1],
generation is presented. Section 2 presents an object- the model in Fig. 3 is obtained, which is composed of
oriented modelling approach with Petri nets. In section 3 a elementary library objects, such as pusher or die, etc.
new specification language with its syntax and operators is process resources
explained. Based on the plant model and the specifications
the control synthesis is illustrated in section 4. Section 5 pusher1 die compressed air pusher2 light barrier
deals with the generation of PLC-Programs. The paper
moving right moving up switch on moving down reset
ends with a conclusion in section 6. The important steps of left right high off on high low on off
low
the model-based methodology will be explained using a
moving left set
simple example. moving
down
switch off moving up
c
c

2. MODELLING APPROACH store lowest position mould container

<wp> <wp> <wp> <wp>

fall down push in throw out
Using the model of a simplified stamping process (Fig. 2),
store material flow
the model-based methodology for controller synthesis will processing flow
stamp
coin.stamp
be explained. In this process a pusher 1 moves coins from
mf.stamp
a store into a mould. Then the coin is stamped by a die and
coin
afterwards ejected by pusher 2 and blown out of the processed object raw stamp stamped
process by compressed air. The workpiece leaving the .

process is reported by a light barrier.

p compressed
Fig. 3: PLANT MODEL OF STAMPING PROCESS
air A The plant model is composed of 3 layers, which represent
coins 2
A3 different aspects of the plant. The first layer describes the
processed object, namely the workpiece. This layer
p
store
contains the properties and the states of the machined
die workpiece. The second layer represents the processing
flow (material flow). Here, the possible locations and the
S3
S1
corresponding transportation processes of the workpiece
S A
4 are described. The third layer represents the dynamic of
pusher 1 5
E
R light
the process resources (active objects) which influence the
barrier state and the location of the workpiece.
S2
In our institute we have implemented a software tool
A1 Designet, which supports the model-based methodology in
pusher 2 all its steps, from modelling to code generation. Fig. 4
container
p shows a screen shot of the graphical editor of Designet.
p The tool is being implemented using the C++
programming language on a Windows PC.
A4 3. SPECIFICATIONS
To specify system requirements a special language is
Fig. 2: EXAMPLE PROCESS developed which is similar to temporal logic. The operands
In order to simplify and optimise the modelling process of of the new language are states and state sequences. The
discrete event systems we exploit the advantages of the combination of the operands is made by various operators,
object-oriented methods, such as easy comprehensibility such as is forbidden or is forbidden after or is forbidden
and completeness as well as automatically resulting before etc., which represent prohibition operators. On the
documentation [8]. As shown in [1] the object-oriented other hand several states can be combined to state
analysis and modelling allow us to structure the relevant sequences, which must be kept during the execution of the
information about any system. An important result of this process. Such combinations describe enforcing operations.
analysis are moreover the identified inheritance structures, To specify the stamping process we first define states, which
which inform us about similar behaviours and are relevant for the process course, e.g. start and end state or
characteristics of objects. The dynamic behaviours of each intermediate states. Furthermore we define states which
object is represented by Petri nets. These information can must not be reached. We declare them as forbidden states to
be exploited to generate object libraries. Indeed these avoid dangerous situations. For example the state in which
 The second method is based on an optimised
calculation of occurrence graph parts
simultaneously (during the calculation)
considering the specifications. In the worst case
the complete occurrence graph is calculated, but
only the right sequence with the corresponding
states is stored.

Z1
T1 T2

A1

S1

Fig. 5 SIMPLE STEP

Fig. 4: SCREEN SHOT OF DESIGNET
the die is in the low position and the pusher is
simultaneously in the right position must be forbidden,
because otherwise there is a collision between pusher and
die. Moreover there are situations which are not absolutely
dangerous, but they cause an unnecessary use of the process
resources. For example switching on the compressed air
before stamping the workpiece is not a meaningful action.
In addition to the combinations of states and state
sequences which can be timeless, it is possible to define
states with timed tokens, so that states with the same
marking differ in the age of the tokens. In this way precise
time specifications can be defined.
4. CONTROL SYNTHESIS
The main task of the control synthesis is to calculate a
firing sequence from a given start state to a likewise a
given end state considering all the given system
specifications.
A controller net, which represents the control algorithm, is
then derived from the calculated sequence. The automatic
generation of the controller net guarantees a high semantic
correctness of the control algorithm.
For generating a control algorithm there are many
possibilities (at least three). The methods which are
implemented in Designet, are an occurrence graph based
search and an optimised calculation and search.
Applying the first method, the complete occurrence graph
must be calculated. A firing sequence is then searched
considering the specifications. This method is suitable for
small and simple processes because the calculation of the
occurrence graph of large processes require enormous
processing time and memory space.
Regardless whether the first or the second
method is applied, the generation of the control-
ler net is the same since the resulting sequences of both
methods are equal. A sequence consists of a list of firing
steps. Each step represents a number of transitions which
can be concurrently executed and defines the control out-
puts necessary to fire these transitions as well as the sensor
places changing when executing them.
The fundamental structure of a control net for a simple
step is represented in Fig. 5. Here the transition T1 sets the
output place A1 enabling one or more transitions in the
plant model. When sensor place S2 indicates the end of the
step, transition T2 resets output place A1.
The controller net of the stamping process is represented
in Fig. 6. The net consists of three parts. The first one is a
cycle (at the top), which describes the cyclic character of
the control algorithm. Between the output places and the
transitions of the cycle, there are connections, which
describe when outputs are set and reset. The third part are
the connections between sensor places and transitions of
the cycle, which model the relation between plant and the
inputs of the controller.
Z1 Z2 Z3 Z4
T1 T2 T3 T4
A1 A2 A3 A4 A5
S1 S2 S3 S4

pusher1 mf.mould die.low light_barrier.on

.left

Fig. 6: CONTROLLER NET

The stamping process is supposed to be timeless. next control step can not be started before both actions
However, real processes are timed systems, so that we have been finished, indicated by tokens and the places Z4
must extend the control net generation method in order to and Z6.
consider time aspects. Because of space limitations, we
T2_1
will describe in this paper only the basic concepts of the
T1 Z2 Z3 T3 Z4
timed control net generation. t =2 t =1
t =2 T2_2
We assume that the step, for which a control net must be
generated, consists of firing the transition t with time delay
= [2, 3] (Fig. 7). Hereby the place P1 (grey instead of
white) is a sensor place [3].
P1 t P2
t =[2, 3]
A

. . P1 P2
t =[2, 3] t

Fig. 7 SIMPLE TIMED STEP

The corresponding control net is described in Fig. 8. In
this net the output A is set for at least two time units. The
output is reset, if the sensor place P1 is no longer marked
or if three time units are passed. In the first case A is reset
by transition T2_2. In the second case first the transition
T2_1 fires and then A is reset by T3.
Now we assume that we may have parallel actions with
different time delays. The corresponding control net is
represented in Fig. 9 (for two parallel actions). The net has
two branches (boxes), which have the same elementary
structure as the net in Fig. 8. Both steps are initiated at the
same time by firing the transition Tstart. Due to the decou-
pling of the nets, both steps can run independently, but the
P3
t =[2, 3]
. .
Fig. 8 CONTROL NET FOR A SIMPLE TIMED
STEP
5. PLC-PROGRAMMING
The Petri nets obtained from control synthesis are directly
translated into PLC code. Currently modules for generat-
ing STEP 5 and STEP 7 code are available, standardised
IEC 1131-3 code will be available in near future. As input
only the synthesized controller net and a file defining the
mapping of PLC I/O-addresses to output and sensor places
are neccessary. No knowledge of the actual hardware on
which the algorithm is to be executed is needed when
programming the PLC in this way.
t2 P4

. .

A2

T2_1
Z1 T1 Z2 Z3 T3 Z4
t =2 t =1
T2_2
t =2
Zstart Tstart Ten d Zen d

T2_1 T3_1 T4_1

Z1 T1 Z2 Z3 Z4 Z5 T5 Z6
t =1 t =1 t =1 t =1
T2_2 T3_2 T4_2
t =1 t =1 t =1

A1

P1 t1 P2
t =[1, 4]

. .

Fig. 9 CONTROL NET FOR PARALLEL STEPS

The PLC program consists of two parts. The first part is
the Petri net execution module, it is independent of the
translated Petri net. This module can remain unchanged as
it can execute any Petri net which is stored in special data
blocks. These data blocks form the second part of the PLC
code, the Petri net data module. This module contains all
information on the Petri net calculated during controller
synthesis, see Fig. 10. All information on tokens, token
ages, places, arcs and transitions is stored in the data mod-
ule. The execution module checks transitions from the data
module and fires enabled transitions. The information on
tokens deleted and created are updated in the data module.
A PLC program is cyclically repeated. On each cycle start
all input data from the sensors is updated and stored.
Afterwards the user program is called, in this case the Petri
net execution module. On completion of the user program
the results are used to update the PLC output. For better
performance the Petri net execution module checks only
transitions from the Petri net data module which have
neighbouring places that were modified in the last program
cycle or by modified sensor information from the plant.
program cycle
update
input
information
Petri Petri
net net
execution data
module module
update
output
information
Fig. 10 STRUCTURE OF PLC
PROGRAMS
6. CONCLUSIONS
With the presented PLC software development toolkit
Designet it is possible to create graphical models of plants,
to edit specifications and to automatically generate control
algorithms from the plant model and the specification. The
control algorithm is again a Petri net, which can be di-
rectly translated into PLC code.
This method of control code generation yields high quality
programs, as no programming in any programming lan-
guage is neccessary. Due to automatic code generation
syntactical errors do not exist. As the program is specified
by an object oriented model of the plant which uses ob-
jects that are very close to the real-life elements of the
plant and by a specification stating explicitly what the
program has to do instead of how to do it, even the se-
mantic level of the program makes no problem at all.
The model and the specification serve as an excellent
documentation of the controller program. As modifications
and improvements are always made at the level of model
or specification the program documentation is always up-
to-date.
The model based information on the plant and the
controller collected during the program development
process can be easily used for the generation of higher
level control algorithms or diagnosis systems.
7. REFERENCES
[1] M. Chouikha, K. Lemmer, E. Schnieder :Object-
oriented modelling of discrete event systems with
coloured Petri nets. Proceedings of the IASTED
International Conference on Modelling, Simulation
and Optimization (MSO 97), pp 49-52, Singapore,
1997
[2] L. E. Holloway, B. H. Krogh, A. Giua: A Survey of
Petri Net Methods for Controlled Discrete Event
Systems. Journal of Discrete Event Dynamic Sys-
tems (Draft, Feb. 1996).
[3] K. Lemmer, B. Ober, E. Schnieder: Model-Based
Programming and Diagnosis for Programmable
Logical Controllers. IEEE International Conference
on Systems, Man and Cybernetics, Vancouver,
1995
[4] J. S. Ostroff, Temporal Logic for Real-Time Sys-
tems, Research Studies Press Ltd, Taunton, Somer-
set, England and John Wiley & Sons, New York et.
Al. 1989
[5] P. J. Ramadge, W. M. Wonham, The Control of
Discrete Event Systems, Proceedings of the IEEE
77 (1989), pp. 81 - 98.
[6] J. Rumbaugh et al.: Object-Oriented Modelling and
Design. Prentice Hall, New York, 1991
[7] R. S. Sreenivas, B. H. Krogh, On Condition/Event
Systems with Discrete State Realisations, Discrete
Event Dynamic Systems: Theory and Application 1
(1991), pp. 209 - 236.
[8] W. Stein: Object-Oriented Analysis Methods -
Comparison, Evaluation and Choice. BI-Verlag,
Mannheim,1993 (in German)