Outline
GRAF GR AFCE CET T and and Pe Petr trii Ne Nets ts
Prof. J.-D. Decotignie
introduction GRAFCET GEMMA Petri nets
CSEM Centre Suisse Suisse d’Electroniqu d’Electroniquee et de Microtechniq Microtechnique ue SA Jaquet-Droz Jaquet-Droz 1, 2007 Neuchâtel Neuchâtel
[email protected]
Real-Time Programming
Introduction
Description of process evolution Description of process interaction
Petri nets
Functional specifications Requirements for automata
© J.-D. Decotignie, 2007
GRAFCET Graphe de Commande Commande Etape Transition Transition (Step Transition Transition Control Control Graph) 2 levels
GRAFCET GRAFCET and and Petrinets 2
GRAFCET
Functional specification Operational specification
Described in the international standard IEC 848 under the name of function charts [Dav90] R. David, David, A. Alla, « Petri nets and Grafcet", Prentice Hall, 1992. R. David David,, Grafc Grafcet: et: a powe powerf rful ul too tooll fo forr spec specif ifica icatio tion n of logi logicc controllers, IEEE Trans. on Control Systems Technology, vol. 3, Issu Issuee 3, 3, Sept Sept.. 199 1995, 5, pp.2 pp.253 53 - 268 268
GRAFCET
GRAFC GR AFCET ET - def defini initio tion n
Definition Evolution rules Defining actions Taking time into account Defining transition conditions Execution algorithm Macrostep and macroactions macroactions
Quadruple C = {S, TR, A, M 0} N steps si ∈ S; each each step si may be active (Xi= true) or not (Xi=false). M0 denotes denotes the set of of steps steps active at startup startup L transitions tr i ∈ TR; to each transition transition is associated associated a boolean boolean condition condition (recept (receptivity) ivity) Steps and transitions transitions are are linked linked by aarcs rcs ai ∈ A
GRAFCET and Petri nets 5
© J.-D. Decotignie, 2007
Exercise - syntax
b1 2
+ EVOLUTION CONDITIONS
Real-Time Programming
GRAFCET GRAFCET and and Petrinets 6
© J.-D. Decotignie, 2007
Exercise - syntax (2)
F
a
a
B
C
D
a b
a
a G
H
a E
a
I
b
a K
a
b
L=0 /b1
a
A
L=1
Real-Time Programming
1
Directed Directed graph graph derived derived from PN
a L
M
O
P
a
b N
GRAFCET
GRAFC GR AFCET ET - def defini initio tion n
Definition Evolution rules Defining actions Taking time into account Defining transition conditions Execution algorithm Macrostep and macroactions macroactions
Quadruple C = {S, TR, A, M 0} N steps si ∈ S; each each step si may be active (Xi= true) or not (Xi=false). M0 denotes denotes the set of of steps steps active at startup startup L transitions tr i ∈ TR; to each transition transition is associated associated a boolean boolean condition condition (recept (receptivity) ivity) Steps and transitions transitions are are linked linked by aarcs rcs ai ∈ A
GRAFCET and Petri nets 5
© J.-D. Decotignie, 2007
Exercise - syntax
b1 2
+ EVOLUTION CONDITIONS
Real-Time Programming
GRAFCET GRAFCET and and Petrinets 6
© J.-D. Decotignie, 2007
Exercise - syntax (2)
F
a
a
B
C
D
a b
a
a G
H
a E
a
I
b
a K
a
b
L=0 /b1
a
A
L=1
Real-Time Programming
1
Directed Directed graph graph derived derived from PN
a L
M
O
P
a
b N
Divider by 2
Examples of logical graphs a
1 (1)
(1)
(2)
a
G (A)
1 S
1
a
(1)
↑a
(1)
4 (4)
2 a'
a S
Controlling system
S
(2)
↑a
(2)
Real-Time Programming
b
© J.-D. Decotignie, 2007
Example
(3)
Real-Time Programming
(1)
↑m.a
2
3
G a
1
V b
(2)
a GRAFCET and Petri nets 18
V b © J.-D. Decotignie, 2007
m
Initial conditions
Tanks empty, valves closed
Sensors and actuators
(2)
Go to left Arrived on left
Increment a counter reservoir
↑m
2
D
3
GRAFCET and Petri nets 17
(1)
↑m
Go to right Arrived on right
3 (3)
1
2
(3)
(B)
S
3
m pressed
2 (2)
a'
(3)
b
D
↑a
a
2
1
m
S
Vi, Wi = 1 if open h1 hi, bi = 1 if level above sensor
operations:
V1
b1
Fill each tank until above h i, close valve V i and open Wi until level below b i . Procees cannot be repeated before both tanks are empty
tank 1 W1
V2 h2 b2
1 (1)
=1
↑a
(2)
(C←C+1)*
3 (3)
↑a
a Stable situation (C←0)*
2
tank 2 W2
(C←0)*
(C←C+1)*
{2}
{3}
{2}
{3}
Duration of a continuous action
Pulse shaped actions c1
Continuous actions are only defined for stable situations
3 (2) 4
a
(2)
(3)
b
5 6 (3) b
Action A
c3
open P*
c2
(4)
X6
X4
action A
(5)
X5
c3 6
c4 X3
5
X5
a
c2
c1
close P*
X6 open P*
c4
close P* P open Real-Time Programming
GRAFCET and Petri nets 25
© J.-D. Decotignie, 2007
Conditional Pulse Shaped Actions X3
(3)
a Action A* if b
3 (4)
b
c
Real-Time Programming
Actions types
Continuous actions (à niveau) unconditional conditional
A* if b=1 when ↑X3 A* when X3=1 as soon as b=1
A* when ↑(X3.b)
A* if b is ambiguous. Unsufficient notation !! We shall not keep this capability
GRAFCET and Petri nets 26
Condition is a boolean variable Condition is based on a timer
Pulse shaped actions
Always unconditional
© J.-D. Decotignie, 2007
Exercise: drilling machine
Actions and outputs
h: upper position
Controlling part High speed
E
High speed up
b1: end of approach Working speed
h b1 b2
(calculations, timers,..)
C* h: upper position
b3: end of drilling
D
High speed
b3
b1: end of approach Working speed
High speed up
High speed up
Working speed
m
Operator or supervising system
b2: end of deburring
GRAFCET and Petri nets 29
© J.-D. Decotignie, 2007
Transition conditions
variables
Real-Time Programming
A
B*
GRAFCET and Petri nets 30
© J.-D. Decotignie, 2007
∀a ∈ {0,1} si a(t)=1 when t ∈ [t1, t2[ et t ∈ [t3, t4[ definition 1: ↑a occurs in t1 and in t3 definition 2: ↓a occurs in t2 and in t4 definition 3: ↑a.b occurs at the same instant as ↑a each time b=1 at this instant definition 4: ↑a.↑ b occurs when ↑a and ↑ b occur at the same instant
Relative to the state of a step (Xi) State of the operative part (of the controlling part)
condition Ci = boolean combination of variables event Ei = rising (falling) edge of an external variable (e always occurring event)
a
Coming from the process or from the external world relative to time (t/i/ Δ)
receptivity R i = Ci Ei
(described by the graph)
Events
Internal boolean variables
Control part of the controlling part
(processus to control)
External boolean variables
b
inputs: a,b,m actions: A, B*, D, C* outputs: A, B*, D, E
Operative part
b3: end of drilling
Real-Time Programming
Operative part of the controlling part
Show that ↑a = ↓a' ↑a.↑a = ↑a
↑a.a = ↑a ↑a. ↑a' = 0
↑a.a' = 0 ↑a.e = ↑a
↓a.a = 0
Interpretation Algorithm (without stability search)
Graph interpretation
1
2 persons in front of the same graph and assuming the same sequence of inputs should deduce the same sequence of outputs.
1. 2.
3.
4.
Asumptions:
c
2 uncorelated events may not occur at the same time The graph has enough time to reach a stable state before the occurrence of the next event
3
↑ b
(7)
4
D
=1
(6)
G
c
m.a'
(3)
↑a
(2)
5
b
2
HD
Read the state of the inputs evolve (one or more (1) ↑ b simultaneous clearings) 7 G Execute actions (4) c a goto 1 (5)
D
6 (8)
d
d
H G Real-Time Programming
GRAFCET and Petri nets 33
© J.-D. Decotignie, 2007
(1)
4 a
(2)
5 /b
(2)
6 (3)
↑a
(1)
5
/b 6
↑c
(3)
↑c
Real-Time Programming
GRAFCET and Petri nets 34
© J.-D. Decotignie, 2007
Interpretation Algorithm (with stability search)
Iterated Clearing 4
D
a b c Stable situation
{4}
{6}
1. initialization: activation initial step(s), execution of associated pulse shaped actions; go to 5 2. If an external event Ei occurs, determine the set T1 of transitions that can be cleared on Ei; if T 1≠∅ goto 3, else modify conditional actions and goto 2 3. Clear transitions that can be. If, after clearing, the state is unchanged goto 6 4. Execute the pulse shaped actions that are associated to the step that were activated at step 3 (incl. timers) 5. Determine the set T2 of transitions that can be cleared on occurrence of e. If T2≠∅, goto 3
Interpretation Algorithm (with stability search)(2)
Interpretation Algorithm (with stability search)(3) 1
6. A stable situation has been reached
1. Determine the set A0 of continuous actions that must be deactivated (incl. conditional actions) 2. Determine the set A1 of continuous actions that must be activated (incl. conditional actions) 3. Set to 0 all the actions that belong to A0 and not to A1. Set to 1 all the actions that belong to A1 4. go to 2
Real-Time Programming
GRAFCET and Petri nets 37
© J.-D. Decotignie, 2007
Non stable cycle
1 a
(3) 5 (5)
A
a'
a'
2
(1)
(4) b 4
Real-Time Programming
↑ b
(1) (4)
3
↑ b
(7)
c
=1
(6)
G
5
4
D
c (5)
m.a'
(3)
↑a
(2)
G
7
2
HD
D
6 (8)
d
stage 4: no pulse shaped action stage 5: T 2= {(6)} stage 3: clearing (6) stage 4: no pulse shaped action stage 5: T 2=∅ stage 6: A 0= {H,D}, A1= {D} ......
GRAFCET and Petri nets 38
© J.-D. Decotignie, 2007
Exercise [Dav90] Let H1 and H2 be two wagons carrying goods from loading points C1 and C2 respectively to an unloaded point D. Variables c1,c2 and d correspond to end of track sensors. They turn to 1 when a wagon is present at the given point. Variable a1 turns to 1 when the front wheels of wagon H1 are on the tracks between A1 and D (same for a2 if wagon H2 is between A2 and D). If wagon H1 is in C1 and if button m1 is pressed, a cycle C1 → D → C1 starts with a possible wait in A1 until the track common to both wagons is free, then a wait in D during 100s. Wagon H2 performs the same on C2 → D → C2. The path C1-D is set when V equals 1, otherwise path C2-D is set.
b' B
stage 1: situation {1,2} stage 5: (1) (2) et (3) enabled, cannot be cleared on e, T 2=∅ stage 6: stable situation {1,2}, A0=∅, A1= {H,D} stage 2: m=1, on e, T 1= {3} stage 3: clearing (3) stage 4: no pulse shaped action stage 5: T 2=∅ stage 6: A 0=∅=A1 stage 2: on ↑a, T1= {2} stage 3: clearing (2)
(2)
(6) b'
12 a
(3) 5 (5)
(1) A
a'
(4) b 4
m1
B
(6) b'
m2
c1 C1 c2 C2
G1
D1 H1
A1
V G2
D2 H2
A2
d D
Macro-step
Pseudo macro-step A
4 (4) E30
A
4 (4)
32 V1 c
5
M30
b
(5) 6
34
D
c'.d
G
30 B
B
↑a
a.d'
a.d'
↑a
b 31 V1 ↑a' 33 B c
32
c 34 D c'.d
S30
(5)
30' b 6
Real-Time Programming
b 31 V1 ↑a' 33 B c
V1
GRAFCET and Petri nets 41
G
© J.-D. Decotignie, 2007
Pseudo macro-step P1 3
Start of units
end
Normal operations
2
Stop units
© J.-D. Decotignie, 2007
Normal operations
Globaly act on a GRAFCET Do not increase the expression power But ease specification Exhibit same properties as actions
Stop request
Stop request P2 5
Start unit 1
4
end 2
Start unit 2
end
start P51
GRAFCET and Petri nets 42
System stopped
start System stopped
Real-Time Programming
Macro actions 1
1
Represents a set of steps All arcs do not necessarily go to the same step (no need for a unique entry step) All arcs do not necessarily go to the same step (no need for a unique exit step) All arcs entering or leaving the pseudo macro-step need be represented
P2 5
Stop unit 1
end
end
restart Stop unit 2
6 end
Continuous
restart
Forçage(forcing), figeage(freezing), masquage(masking)
Pulse shaped
Forcer (force), masquer(mask), démasquer(unmask), figer(freeze), libérer(release)
Outline
GEMMA
introduction GRAFCET GEMMA Petri nets
Real-Time Programming
GRAFCET and Petri nets 49
© J.-D. Decotignie, 2007
Problems with GRAFCET
GRAFCET is good to describe normal operation but:
GRAFCET and Petri nets 50
© J.-D. Decotignie, 2007
Objectives of GEMMA inventors
Create a graphical tool that can deal with: Emergency cases Manual modes Degraded modes
Emergency cases Manual modes Degraded modes
Does not favor a good separation of operating modes Does not give a clear vocabulary concerning modes Does not include any security aspect
Problems with GRAFCET Objectives Concepts How to use GEMMA Advantages Drawbacks
Real-Time Programming
Not well suited to describe
Guide d'Etude des Modes de Marche et d'Arrêt
Estblish a precise vocabulary Tool show present itself as a guide (checklist)
control PC part power power on off
GEMMA concepts
A OPERATIVE PART (OP) STOP PROCEDURES A6
initial state>
A7
Assumes that controlling part is operational Separate production states from other states Distinguishes 3 categories of operating modes Working procedures Stopping procedures Failure procedures
PC power on
Real-Time Programming
GRAFCET and Petri nets 53
© J.-D. Decotignie, 2007
reached>
A2
A3
stop request
F2
F3
F1 < normal production>
D3
PRODUCTION procedures>
D1
D
F5
F6
production>
PRODUCTION
OPERATIVE PART FAIL PROCEDURES
Real-Time Programming
How to use GEMMA
D2
CP power off
control part power off
start request
A4
PRODUCTION A5
F4
stop>
given state>
CP power off
PROCEDURES DE FONCTIONNEMENT
F
A1
failure detect
F
WORKING PROCEDURES
GRAFCET and Petri nets 54
© J.-D. Decotignie, 2007
Example – joint test bed
Selection of modes Showing relationships Search for evolution conditions
3 tested values V, C, β Long tests on a typical run Periodic request for withdraw and check
ß
cardan
Frein couple C
V
C
β moteur vitesse V
on off ack man.
auto
AU
Verrin pour réglage angle ß
How to manage an automation project
Phases according to GEMMA tenants
Define requirements Use GEMMA for start/stop operations Create GRAFCET Select control technology Technological realization Trial and commissioning
Real-Time Programming
GRAFCET and Petri nets 65
© J.-D. Decotignie, 2007
Petri nets
Invented by C. Petri in 1962 in his PhD thesis ("Kommunikation mit Automaten) J. Peterson, "Petri Net Theory and the Modelling of Systems", Prentice Hall, 1981. R. David, A. Alla, "Du Grafcet aux réseaux de Petri", Hermes, 1990. T. Murata, Petri nets: Properties, analysis and applications, Proc. of the IEEE, Vol. 77 (4), April 1989, pp.541 - 580 2 view points
Theoretical
Definitions and evolution rules Properties
Application to functional specifications
Outline introduction GRAFCET GEMMA Petri nets
Real-Time Programming
GRAFCET and Petri nets 66
© J.-D. Decotignie, 2007
Petri Nets
Definition Marking PN types Modelling with Petri nets Modelling synchronization and cooperation between tasks Design Analysis and validation
Petri nets - definition
Directed graph tuple C={P, T, I, O} N places pi ∈ P L transitions ti ∈ T Input matrix I [LxN] places → transitions Output matrix O [LxN] transitions → places
Petri net example
p1
p2
p3
t1
p4
P = {p1, p2, p3, p4, p5} T = {t1, t2}
© J.-D. Decotignie, 2007
Petri nets - marking
2
p3 2
p4 0
p5 0 t1
0
0
0
0
1 t2
p1 0
p2 0
p3 0
p4 1
p5 2 t1
#(pi, I(t j)) weight of arc pi → t j
0
0
1
0
0 t2
#(pi, O(t j)) weight of arc t j→ pi
t1
Real-Time Programming
t2
2 4
GRAFCET and Petri nets 70
p5
© J.-D. Decotignie, 2007
PN – evolution rules p1
p3
p2 1
I=
p5
GRAFCET and Petri nets 69
p2
p1 1
O=
Real-Time Programming
1
marking M = {m(p1),....., m(pi), ....., m(p N)} with m(pi) = number of tokens in place p i p4 Initial marking M 0, example M0={2,1,3,0,1} Evolution by firing transitions Can then represent behavior (dynamic)
p2
p3
2
t1
t2
2
p5
a transition t i may be fired iif for all i m(pi) ≥ #(pi, I(t j)) Only one transition may fired at a time A transition is fired instantaneously by: Removing in each place that immediately preceeds the transition a number of tokens equal the weight of arc that links them Adding in each place that immediately follows the transition a number of tokens equal the weight of arc that links them m(pi) := m(pi) - #(pi, I(t j)) + #(pi, O(t j))
EVOLUTION IS NOT DETERMINISTIC
Evolution rules p1
Exercise - syntax
p2
For each of the graphs below, answer the following questions: 1. Is it a PN ? 2. What are the validated transitions ? 3. What will be the marking after firing ? 4. What are the validated transitions
p3 2
t1
t2
2
p4 1
p2
p5
p3
p1
p2
p3
2
t1
B
C
F
G
H
D
E
2
t2
t1
2
t2
2
p5
4
A
p4
Real-Time Programming
GRAFCET and Petri nets 73
p5 © J.-D. Decotignie, 2007
Exercise – syntax (2)
Real-Time Programming
I
GRAFCET and Petri nets 74
© J.-D. Decotignie, 2007
PN types
For each of the graphs below, answer the following questions: 1. Is it a PN ? 2. What are the validated transitions ? 3. What will be the marking after firing ? 4. What are the validated transitions
Generalized PNs There a weight on each arc Can be transformed into ordinary PN
PNs with predicates
Cannot be transformed into ordinary PN Marc
J
K
L
X Y father of X Y
X
t1
Y Luc
t1
PN types (2)
PN types (3) t1 fired
PNs with capacity
t1 fired
t1
t1
t1
t2
t2
Tokens have colors Any colored PN with a finite number of colors may be transformed into an ordinary PN
cap(p2)=2
2
t2
Can be transformed t1 into ordinary PN 2
t1 fired
p2'
p2' t2
t2
GRAFCET and Petri nets 77
© J.-D. Decotignie, 2007
PN types (4)
PNs with inhibiting arcs
1
Synchronized PNs Time PNs Stochastic PNs Stochastic Time PNs ....
Continuous PNs The number of tokens can be a real number Cannot be transformed into ordinary PN
Real-Time Programming
GRAFCET and Petri nets 78
© J.-D. Decotignie, 2007
p3
Transform this PN into an ordinary PN
2
t1
4
Cannot be transformed into ordinary PNs
t1 p1
t2 p2
2
Several types
p2
Cannot be transformed into ordinary PNs
Cannot be transformed into ordinary PN
Exercise
No autononous PNs
PNs with priorities
t1
p2'
t2 Real-Time Programming
t1 fired t1
Colored PNs
p5
t2 cap(p3)=3
t3 p3 t4 p4
t5
Modelling with PNs
actions associated to places
Conditions « and" & « or"
Activated by token presence
actions associated to transitions (short duration)
Activated by transition firing
Task waiting
p1
p2
type "AND"
Start of execution
executing
type "OR"
Processor free
p1
p2 x1
p3 x2
p3 y
p1 x3
p2 x1
t1
t1
Real-Time Programming
GRAFCET and Petri nets 81
p4
p4
© J.-D. Decotignie, 2007
Introduction of external conditions
p1 When synchronisation is required Task controlled system → waiting controlling system (.,begin_exec) Label on the transition p3 executing (if condition, action) Transition may be fired iif (end_exec,.) external condition satisfied Task p4 terminated Timers (extern or minimal sejourn duration in a place)
p2
Processor free
p4
Real-Time Programming
x3 t3
t2
End of execution
Tasked ended
p3 x2
GRAFCET and Petri nets 82
y
© J.-D. Decotignie, 2007
Introduction of external conditions (2) Task waiting
p1
p2
Processor free
t11
p3
p15 t12
t13
p14
p16 t14
(end_exec,.)
Task terminated
(begin_exec, .)
p13
(.,begin_exec)
executing
p11
p4
p17 (.,end_exec)
t15
Introduction of external conditions (3) p1
t1
Modelling task synchronisation mechanisms
Mutual synchronisation (rendez-vous)
(.,start_timer)
A1
p3 t2
B1 t2
timer
t3 t1
(end_timer,.)
A2
GRAFCET and Petri nets 85
© J.-D. Decotignie, 2007
Modelling task synchronisation mechanisms(2)
Real-Time Programming
A1
A2
B
B1
B2
A
A1
B
B1
OR
A2
B2
p4 Real-Time Programming
A
B2
GRAFCET and Petri nets 86
© J.-D. Decotignie, 2007
Modelling task synchronisation mechanisms(3)
mailbox
Interrupt driven task As an external condition on a transition t1 Interrupt handler modeled using A 2 places
A1
B1 t2
t3 B
t1 A2
B2
A1
A2
B1
B2
p4 t2 p3 t5
B
(interrupt,...) t3
p2 t4
B
(interrupt,...)
p1 t6