OBJECT-ORIENTED MODELLING OF DISCRETE EVENT SYSTEMS WITH

COLOURED PETRI NETS

Mourad Chouikha, Karsten Lemmer, Eckehard Schnieder
Institute of Control and Automation Engineering
Technical University of Braunschweig
Langer Kamp 8, D - 38106 Braunschweig, Germany
Tel.: ++49-531/391-7667 , Fax: ++49-531/391-5197
E-Mail: {chouikha, lemmer, schnieder}@ifra.ing.tu-bs.de

ABSTRACT Petri nets will be explained using the model of a simplified

This paper deals with design process for automation
systems. Getting started with an introduction of an example
process an overview of the object-oriented approach was
given. Furthermore the transformation of these models into
coloured Petri nets will be described. Moreover the control
synthesis of the net model will be outlined. Using the object-
oriented approach and integrating Petri nets as a description
language for modeling during the whole technical design
process a high degree of automation from the first ideas to
physical implementation is possible.
Keywords: Automation, Computer Aided Systems
Design, Object-Oriented Design, Petri
Nets, Systems Methodology
1. INTRODUCTION
Technical design becomes more difficult as the systems get
more and more complex and the degree of automation is
always increasing. To work efficiently together designers
use tools for representation of their knowledge in the design
process and for implementation of new products such as
computer programs or mechanical constructions. The use of
tools is essential in all phases of system design [7].
This paper deals with design process for automation
systems. combining Petri nets and the Object-Oriented
approach
2. EXAMPLE PROCESS
All steps of the object-oriented modelling with coloured
L1
E
L2
Obli
S1
E
sorting process (Fig. 1). This process is composed of
an oblique slide with two pusher to single
(separate) workpieces,
a conveyor belt to transport workpieces,
two pusher to eject sorted workpieces and
a container for workpieces which run over.
The arrival announcement of a workpiece is made by the
light barrier L1. After separating workpieces with pusher 1
and 2 a single workpiece passes through light barrier L2.
This starts the motor of the conveyor belt, which carries
the workpiece up to pusher 3, if detector D reports that the
workpiece is metal. Else the workpiece is carried over the
light barrier L3 to detect its size. If the workpiece exeeds a
given size, it will be carried until pusher 4. Else the work-
piece will be carried up to the end of the conveyor belt and
it falls into container 3. This is reported by light barrier
L6. The ejecting of workpieces with pusher 3 and 4 into
container 1 and 2 is detected by light barrier L4 and L5.
All end positions of the pusher are supervised by sensors
S1 to S8. The next workpiece can be sorted, only if the
preceding workpiece has left the process.
3. OBJECT-ORIENTED MODELLING
Object-oriented Analysis and Design are applied up to
now primary in the software engineering. This design
method has many advantages mainly for the modelling
process, such as easy comprehensibility and detailed
documentation. Generally models must be:
L4 L5
L3 L6
Container Container

que S E
lide 1 E 2 E
S3
S2 1 Pushe S5 Conveyor Belt S7
r
S4 2 Container
S Pusher 3 Pusher 4
M 3
M
S6 S8
S1F S
S1B S2F M
S M
S
S2B P1F P2F
D
P1B P2B

Fig. 1: SORTING PROCESS

 definite, positions. For the transportation start position, end position
complete, and duration must be included. The important properties
checkable and of the controller are the inputs, outputs and process image.
changeable. Finally a sensor has an attributes, which describes its state
(set or reset).
These requirements can not be satisfied by ordinary mod-
elling methods. These are usually an intuitive process, To determine the operations of the classes we proceed
which depends strongly from designer and his experience. exactly like the identification of attributes. However we
Object-oriented models can grant as a rule all require- search now the functions that must be executed by the
ments [8]. objects and their reactions. In Fig. 3 the identified classes
are illustrated with their attributes and operations.
The presented process in section 2 has a comparatively
complex structure. However the object-oriented analysis
of this process can be restricted to the inspection of an
exemplary part process, namely pusher 1 and its environ-
ment. The results of this investigation can be applied to the
entire System.
As mentioned in the introduction the description of the
object-oriented models is made by the object model nota-
tion according to [6] The method how to develop the ob-
ject-oriented models is derived from [1]. In this context
the object-oriented models are developed in three steps,
that are basic, static and dynamic models. For the defini-
tions of the used concepts see [2], [3] and [6].
3.1 Basic Model
The basic model consists of classes, attributes and opera-
tions, which must be identified from the examined process.
Fig. 3: CLASSES WITH
Based on the process description we can identify five THEIR ATTRIBUTES AND
1
classes , which are represented in Fig. 2. The most found OPERATIONS
classes describe concrete components, such as workpiece
or sensor. Generally a system is more then the sum of its 3.2 Static Model
physical parts, so that we can identify more classes which To build the static model we must identify inheritance
result from the interaction of many components. For ex- structures, associations and their order and aggregation
ample the movement of the pusher connected with a and as well their order.
workpiece generate a material flow. This transportation is
denoted as the potential (process object classes) of the In our pushing process there is no inheritance, so that we
pusher [7]. examine the entire system. Observing the characteristics
and the behaviours of a conveyor belt and a pusher, we can
conclude that they have many similarities. We can define
then a sup-class transport device and we derive the con-
veyor belt and the pusher from this basic class. Compared
with a pusher the class conveyor belt has no end positions.
These attributes belong only to the derived class pusher.

Fig. 2: IDENTIFIED CLASSES

The identification of attributes depends primary on the

abstraction level and the angle of view. Indeed we pay
attention only to the attributes, which are relevant to our
problem.
For a workpiece type and position are the important prop-
Fig. 4: INHERITANCE STRUCTURE
erties. The relevant characteristics of a pusher are the end
Similar considerations lead to the definition of a basic
1 class transportation, from which the classes push and
Few classes was ignored, because they are irrelevant, e. g. the position
carry are derived. The class carry has one more operation,
which allow us to move the workpiece backward. Fig. 4
illustrates the identified inheritance structures.
A transportation represents a permanent relation between
pusher and workpiece. Missing one of these objects, we
can generate no transportation. This fact can be interpreted
as an association between the classes pusher and work-
piece. The pusher is so designed, that it is able to push
only one workpiece. The association has consequently the
order 1 on both sides. Fig. 5 shows the graphic representa-
tion of the association.
Fig. 5: ASSOCIATION PUSHER -WORKPIECE
The Aggregation is the part-whole or a-part-of rela-
tionship in which objects representing the components of
something are associated with an object with representing
the entire assembly.
In our example we can interpret the pushing process as an
aggregation of pusher, workpiece, sensor and controller
(Fig. 6).
pushing
process
Pusher Workpiece Sensor .......... Controller
. .
Fig. 6: AGGREGATION
3.3 Dynamic Model
The dynamic model consists of the identification of mes-
sages between objects and generation of object life cycles.
In object notation by Rumbaugh the representation of
messages is not possible, so that we introduce a proper
notation to describe messages and their transfer (Fig. 7).
A message channel from a class A to a class B is repre-
sented by an arrow from A to B. The messages are then
specified in a so-called coupling list. In this context we
distinguish two forms of coupling, namely state and event
coupling. The declaration B.O2.()A.O1() means that an
object of B send a message to a defined object of A, when
the operation B.O2() is called. The sent message call then
the operation A.O1(). This is obviously an event coupling.
The declaration B.aA.O1() is state coupling and it
means that the operation A.O1() must be called only if the
attribute B.a is set. In the coupling list logical operations
are admissible, e. g. B.aB.bA.O2(). We can also define
bi-directional message channels, which are represented by
a bi-directional arrow.
Definition of Object Libraries
The object-oriented analysis and modelling allow us to
structure the relevant informations about any system. An
important result of this analysis are moreover the identi-
fied inheritance structures, which inform us about similar
behaviours and characteristics of objects. These informa-
tions can be exploited to generate object libraries. Indeed
these libraries comprise pre-defined objects of same basic
type, which can be inserted, combined and specified (de-
fine parameter), while modelling any system with a design
tool. The use of objects from such libraries corresponds to
the mechanism of creating an instance or inheritance.
In control systems we can define libraries for the compo-
nents, which are often used. For example libraries for
transport devices, e. g. pusher, conveyor belt or crane. For
different transport methods we define a library too (push,
carry,...). To machine workpieces we need a library for
machines and a library for production tasks (drill, lathe,
mill,...). For automatic process detection and operation a
library of sensors and actors is useful, for example light
barrier, mechanical detector or motor.
Such libraries can not be defined only in control systems,
.
but also in many technical domain such as chemical in-
dustry, where libraries for valves, pipelines, tanks, pumps
etc. must be built.
4. TRANSFORMATION INTO A PETRI
NETS MODEL
The result of the transformation of the object oriented
model into a Petri Net is shown in Fig. 8 In the top of the
figure the four objects of the class pusher and the con-
veyor belt can be found. Regarding the objects of the class
pusher it is obvious that each net has the same structure.
The representation of the transportation show the same,
but in this case the objects are combined directly.

Fig. 7: COUPLING LISTS
The interaction between the specific transportation and
pusher objects according to the coupling list in Fig. 8
can be done by the coupling Place indicated by C
(compare [5]).
Furthermore we have a special net for the workpiece.
The actual state of the object is represented by the colour
of the token. The token attribute corresponds to the de-
fined object in Fig. 8 with the attributes type and position.
6. CONCLUSION
In order to simplify and optimise the
modelling process of discrete event sys-
tems we exploit the advantages of the
object-oriented methods combined with
the Petri net approach.
Furthermore it was shown, that object
libraries can be derived from the object-
oriented models. Transforming these
models into Petri net models by the pre-
sented formalism object-oriented Petri net
models are as well obtained. As in control
engineering (block diagrams) the model-
ling of discrete event systems can be
simplified by using the object libraries.
Exploiting the structural and dynamic
properties of Petri net models the control synthesis of
automation systems can be done by many approaches. In
this context Petri net models are preferred, as they have
many advantages over other description languages, espe-
cially for the description of the dynamic aspects of auto-
mation systems.
7. REFERENCES

In further steps a folding of the nets, which represents each [1] H. Balzert: Methods of the Object-Oriented Analysis.
an individual object behaviour (life cycle), the transforma- BI-Verlag, Mannheim, 1995 (in German)
tion to a coloured Petri Net can be realised. In means in [2] G. Booch: Object-Oriented Analysis and Design with
detail, that for each class a special net structure exist. For Applications. The Benjamin/Cummings Publishing
each object (of a class) a token with the object specific and Company, Redwood City, 1994
individual attributes have to defined on the class specific [3] P. Coad; E. Yourdon: Object-Oriented Analysis.
structure. Yourdon Press, Prentice Hall, 1990
[4] L. E. Holloway, B. H. Krogh, A. Giua: A Survey of
With the created net model the dynamic behaviour of the Petri Net Methods for Controlled Discrete Event Sys-
objects and their interaction can be discussed and verified tems. Journal of Discrete Event Dynamic Systems
according to the for Petri Nets existing analysis technique (Draft, Feb. 1996).
[5] K. Lemmer, B. Ober, E. Schnieder: Model-Based
Programming and Diagnosis for Programmable
Logical Controllers. International
Conference on Systems, Man and
Cybernetics, Vancouver, 1995
[6] J. Rumbaugh et al.: Object-
Oriented Modelling and De-
sign. Prentice Hall, New York,
1991
[7] E. Schnieder: Methodical De-
sign of Automation systems -
Bases and Visions. In: Design
of Complex Automation Sys-
tems with Petri Nets and other
Formal Languages, pp 1-20 (in
German)
[8] W. Stein: Object-Oriented
Analysis Methods - Compari-
son, Evaluation and Choice.
BI-Verlag, Mannheim,1993 (in
German)
Fig. 8: ENTIRE MODEL