MODEL-BASED CONTROL SYNTHESIS FOR DISCRETE EVENT SYSTEMS Mourad Chouikha, Eckehard Schnieder Institute of Control and Automation Engineering Technical University of Braunschweig Langer Kamp 8 D-38106 Braunschweig, Germany Phone.: +49-0531-391-76 67 Fax: +49-0531-391-51 97 E-Mail: {chouikha, schnieder}@ifra.ing.tu-bs.de
ABSTRACT In control engineering models of the controlled systems are the basis for controller synthesis as well as for analytical or simulative examination of open or closed-loop behaviour. This model-based methodology is being transferred into automation engineering by means of a development environment for the programming of logical controllers. Petri net models of the controlled system allow an automatic computation of the control algorithm. The control algorithms which are equally represented as Petri nets are then automatically translated into code for programmable logic controllers (PLC’s). Keywords Petri nets, Modelling, Synthesis, Code Generation, PLC.
1. INTRODUCTION The aim of modelling in automation engineering is to describe a process with a formal language, which allows us to generate control algorithms and to simulate, analyse 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 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 other description languages. Indeed the graphic notation of 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.
Bernhard Ober Siemens AG Automation and Drives P.O. Box 3220 D-91050 Erlangen, Germany Phone.: +49-9131-7-24876 Fax: +49-9131-7-31509 E-Mail:
[email protected]
The main design approaches for the control of discrete event systems using Petri nets are [2]: • controlled behaviour approach, • logic controller approach and • control theoretic approach. In the controlled behaviour approach the model describes the behaviour of the plant and the controller joined together. For the implementation the control algorithm has to be extracted from the combined model. The logic controller approach tries to define the inputoutput behaviour of the controller, which satisfies all the system requirements. Using this method the control program can be deduced directly from the obtained I/Obehaviour. This approach leads to the physical implementation of the control program, but simulation is required to validate the closed-loop behaviour. connections to superior controllers connections to neighbouring controllers
controller
sensors
actors
plant
connections to neighbouring processes
.
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 models of plant and controller. In this paper a complete methodology for modelling, specification, model-based controller synthesis and code generation is presented. Section 2 presents an objectoriented modelling approach with Petri nets. In section 3 a new specification language with its syntax and operators is explained. Based on the plant model and the specifications the control synthesis is illustrated in section 4. Section 5 deals with the generation of PLC-Programs. The paper ends with a conclusion in section 6. The important steps of the model-based methodology will be explained using a simple example.
libraries comprise pre-defined objects, which can be inserted, combined and specified (define parameter) during modelling with a design tool. According to the modelling methodology presented in [1], the model in Fig. 3 is obtained, which is composed of elementary library objects, such as pusher or die, etc. process resources
pusher1
die
moving right right
left
high
moving left
store
Using the model of a simplified stamping process (Fig. 2), the model-based methodology for controller synthesis will be explained. In this process a pusher 1 moves coins from a store into a mould. Then the coin is stamped by a die and afterwards ejected by pusher 2 and blown out of the process by compressed air. The workpiece leaving the process is reported by a light barrier. p compressed air A
coins
A3
2
p
store die S3
S1
S A 4
pusher 1
E
S2 A1
pusher 2
p
R
5
light barrier
container
p
A4
Fig. 2: EXAMPLE PROCESS In order to simplify and optimise the modelling process of discrete event systems we exploit the advantages of the object-oriented methods, such as easy comprehensibility and completeness as well as automatically resulting documentation [8]. As shown in [1] the object-oriented analysis and modelling allow us to structure the relevant information about any system. An important result of this analysis are moreover the identified inheritance structures, which inform us about similar behaviours and characteristics of objects. The dynamic behaviours of each object is represented by Petri nets. These information can be exploited to generate object libraries. Indeed these
off
on
light barrier
pusher2
switch on
moving down high
low
reset off
on
low
moving down
c
2. MODELLING APPROACH
compressed air
moving up
switch off
c
lowest position fall down
set
moving up
mould
container
push in
store
throw out
material flow
stamp
processing flow
coin.stamp mf.stamp
processed object
coin raw
stamp
stamped
.
Fig. 3: PLANT MODEL OF STAMPING PROCESS The plant model is composed of 3 layers, which represent different aspects of the plant. The first layer describes the processed object, namely the workpiece. This layer contains the properties and the states of the machined workpiece. The second layer represents the processing flow (material flow). Here, the possible locations and the corresponding transportation processes of the workpiece are described. The third layer represents the dynamic of the process resources (active objects) which influence the state and the location of the workpiece. In our institute we have implemented a software tool Designet, which supports the model-based methodology in all its steps, from modelling to code generation. Fig. 4 shows a screen shot of the graphical editor of Designet. The tool is being implemented using the C++ programming language on a Windows PC.
3. SPECIFICATIONS To specify system requirements a special language is developed which is similar to temporal logic. The operands of the new language are states and state sequences. The combination of the operands is made by various operators, such as is forbidden or is forbidden after or is forbidden before etc., which represent prohibition operators. On the other hand several states can be combined to state sequences, which must be kept during the execution of the process. Such combinations describe enforcing operations. To specify the stamping process we first define states, which are relevant for the process course, e.g. start and end state or intermediate states. Furthermore we define states which must not be reached. We declare them as forbidden states to 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 controller 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 outputs 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
T1
A1
Z3
T2
A2
S1 pusher1 .left
T3
A3
S2 mf.mould
Z4
A4
S3 die.low
A5
S4 light_barrier.on
Fig. 6: CONTROLLER NET
T4
The stamping process is supposed to be timeless. However, real processes are timed systems, so that we must extend the control net generation method in order to consider time aspects. Because of space limitations, we will describe in this paper only the basic concepts of the timed control net generation.
next control step can not be started before both actions have been finished, indicated by tokens and the places Z4 and Z6. T2_1 T1
Z2
t =[2, 3]
T2_2
t =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
Z3
t =2
t =1
Z4
P2
t
A
. .
P1
Fig. 7 SIMPLE TIMED STEP
t =[2, 3]
P2
t
. .
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.
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 generating 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.
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 decoupling of the nets, both steps can run independently, but the P3
t =[2, 3]
P4
t2
. . A2
T2_1 Z1
Zstart
T3
T1
Z2
t =2
Tstart T2_1 Z1
T1
Z2
t =1
T2_2
T2_2
T3
t =1
T4_1 Z4
t =1 t =1
Z4
Ten d T3_1
Z3
t =1
Z3
t =2
T3_2
Z5
t =1
T4_2
t =1
t =1
T5
A1 P1
t =[1, 4]
P2
t1 . .
Fig. 9 CONTROL NET FOR PARALLEL STEPS
Z6
Zen d
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 module. 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
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 upto-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 :Objectoriented 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 Systems (Draft, Feb. 1996).
update input information
Petri net execution module
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 semantic level of the program makes no problem at all.
Petri net data module
update output information
[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 Systems, Research Studies Press Ltd, Taunton, Somerset, 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.
Fig. 10 STRUCTURE OF PLC PROGRAMS
[6] J. Rumbaugh et al.: Object-Oriented Modelling and Design. Prentice Hall, New York, 1991
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 directly translated into PLC code. This method of control code generation yields high quality programs, as no programming in any programming language 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-
[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)
