Grafcet programming

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


Exercise - syntax

b1 2

+ EVOLUTION CONDITIONS




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






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



Exercise - syntax

b1 2

+ EVOLUTION CONDITIONS




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






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)


b


Example

(3)


(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


(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



Conditional Pulse Shaped Actions X3

(3)

a Action A* if b

3 (4)

 

b

c


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






Condition is a boolean variable Condition is based on a timer

Pulse shaped actions 

Always unconditional


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



Transition conditions 

variables 














A

B*



∀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


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



(1)

4 a

(2)

5 /b

(2)

6 (3)

↑a

(1)

5

/b 6

↑c

(3)

↑c




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





      




Non stable cycle

1 a

(3) 5 (5)

A

a'

a'

2

(1)

(4) b 4


↑ 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} ......



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


b 31 V1 ↑a' 33 B c

V1


G


Pseudo macro-step P1 3

Start of units

 

end

Normal operations

2

Stop units


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


System stopped

start System stopped


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



     




Problems with GRAFCET 

GRAFCET is good to describe normal operation but: 

 



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


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




 

reached>

A2
A3

stop request

F2

F3

F1 < normal production>

D3

PRODUCTION procedures>

D1

D

F5

F6

production>

PRODUCTION

OPERATIVE PART FAIL PROCEDURES


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



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 



  


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




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}


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


t2

2 4


p5


PN – evolution rules p1



p3

p2 1

I=

p5


p2

p1 1

O=


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



p5 © J.-D. Decotignie, 2007

Exercise – syntax (2)


I



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



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 




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



p4

p4


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


x3 t3

t2

End of execution

Tasked ended

p3 x2


y


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



Modelling task synchronisation mechanisms(2) 


A1

A2

B

B1

B2

A

A1

B

B1

OR

A2

B2

p4 Real-Time Programming

A

B2



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

Grafcet programming

Recommend Documents