Vous êtes sur la page 1sur 159



  

Prof.dr.ir. Wil van der Aalst


Eindhoven University of Technology, Faculty of Technology Management,
Department of Information and Technology, P.O.Box 513, NL-5600 MB,
Eindhoven, The Netherlands.

| 
  
  

PN-1



  

Prof.dr.ir. Wil van der Aalst


Eindhoven University of Technology, Faculty of Technology Management,
Department of Information and Technology, P.O.Box 513, NL-5600 MB,
Eindhoven, The Netherlands.

| 
  
  

PN-2
Process modeling
‡ Emphasis on dynamic behavior rather than
structuring the state space
‡ Transition system is too low level
‡ We start with the classical Petri net
‡ Then we extend it with:
± Color
± Time
± Hierarchy

| 
  
  

PN-3
Classical Petri net
‡ Simple process model
± Just three elements: , 

 and .
± Graphical and mathematical description.
± Formal semantics and allows for analysis.
‡ History:
± Carl Adam Petri (1962, PhD thesis)
± In sixties and seventies focus mainly on theory.
± Since eighties also focus on tools and applications (cf.
CPN work by Kurt Jensen).
± ³Hidden´ in many diagramming techniques and
systems.
| 
  
  

PN-4
p
place

Elements t t transition

(name) p

place

t t

p
(name) transition
token

arc (directed connection)


t t

token p

t t

p
| 
  
  

PN-5
free

Rules

wait enter before make_picture after leave gone

occupied

‡ Connections are directed.


‡ No connections between two places or two transitions.
‡ Places may hold zero or more tokens.
‡ First, we consider the case of at most one arc between
two nodes.
| 
  
  

PN-6
Enabled
‡ A transition is 
 if each of its input places
contains at least one token.
free

wait enter before make_picture after leave gone

occupied

› ›  


| 
  
  

› › › ›
PN-7
Firing
‡ An 
 transition can  (i.e., it occurs).
‡ When it  it 
  a token from each
input place and   a token for each
output place. free

Y ›

wait enter before make_picture after leave gone

occupied

| 
  
  

PN-8
Play ³Token Game´
‡ In the new state, u   is enabled. It will fire, etc.
free

wait enter before make_picture after leave gone

occupied

| 
  
  

PN-9
Remarks
‡ Firing is  .
‡ Multiple transitions may be enabled, but only one
fires at a time, i.e., we assume 


 
 (cf. diamond rule).
‡ The number of tokens may vary if there are
transitions for which the number of input places is
not equal to the number of output places.
‡ The network is static.
‡ The  is represented by the distribution of
tokens over places (also referred to as 
).
| 
  
  

PN-10
p4 p4

Non-determinism
t34 t43 t34 t43

p3 p3

t23 t32 t23 t32


transition t23
p2 fires p2

t12 t21 t12 t21

p1 p1

r    ›
› ›
  
t01 t10 t01 t10
 ›  Y › p0 p0

| 
  
  

PN-11
Example: Single traffic light rg

green

red go

orange

or
| 
  
  

PN-12
Two traffic lights rg

rg rg

gr

gr  gr 

 
r go r go

¢ r go

ora g ora g

ora g
or or

or

| 
  
  

PN-13
Problem

| 
  
  

PN-14
Solution
rg1 rg2

g1 g2

r1 go1 x go2 r2

ß  › o1 o2
› 
› ›
or1 or2
| 
  
  

PN-15
Playing the ³Token Game´ on the Internet
‡ Applet to build your own Petri nets and execute
them:
http://www.tm.tue.nl/it/staff/wvdaalst/Downloads/
pn_applet/pn_applet.html
‡ FLASH animations:
http://www.tm.tue.nl/it/staff/wvdaalst/courses/pm
/flash/

| 
  
  

PN-16
Exercise: Train system (1)
‡ Consider a circular railroad system with 4 (one-
way) tracks (1,2,3,4) and 2 trains (A,B). No two
trains should be at the same track at the same
time and we do not care about the identities of
the two trains.

| 
  
  

PN-17
Exercise: Train system (2)
‡ Consider a railroad system with 4 tracks
(1,2,3,4) and 2 trains (A,B). No two trains should
be at the same track at the same time and we
want to distinguish the two trains.

| 
  
  

PN-18
Exercise: Train system (3)
‡ Consider a railroad system with 4 tracks
(1,2,3,4) and 2 trains (A,B). No two trains should
be at the same track at the same time.
Moreover the next track should also be free to
allow for a safe distance. (We do not care about
train identities.)

| 
  
  

PN-19
Exercise: Train system (4)
‡ Consider a railroad system with 4 tracks
(1,2,3,4) and 2 trains. Tracks are ,  or
 . Trains need to claim the next track
before entering.

| 
  
  

PN-20


 
 

 
 ! "#   
 
    !
| 
  
  

PN-21
Multiple arcs connecting two nodes
‡ The number of arcs between an input place and
a transition determines the number of tokens
required to be enabled.
‡ The number of arcs determines the number of
tokens to be consumed/produced.
free

wait enter before make picture after lea e gone

| 
  
  

PN-22
Example: Ball game

re lack

rr

| 
  
  

PN-23
Exercise: Manufacturing a chair
‡ Model the manufacturing of
a chair from its components:
2 front legs, 2 back legs, 3
cross bars, 1 seat frame,
and 1 seat cushion as a
Petri net.
‡ Select some sensible
assembly order.
‡ Reverse logistics?

| 
  
  

PN-24
Exercise: Burning alcohol.
‡ Model $%&'%()*'$ +,$*'$ ()*%$'
‡ Assume that there are two steps: first each
molecule is disassembled into its atoms and
then these atoms are assembled into other
molecules.

| 
  
  

PN-25
Exercise: Manufacturing a car
‡ Model the production process shown in the Bill-
Of-Materials.
? 
  



? 
  


?  

| 
  
  

PN-26
Formal definition
A classical Petri net is a four-tuple (P,T,I,O)
where:
‡ P is a finite set of places,
‡ T is a finite set of transitions,
‡ I : P x T ->  is the input function, and
‡ O : T x P ->  is the output function.

Any diagram can be mapped onto such a four


tuple and vice versa.
| 
  
  

PN-27
Formal definition (2)
The state (marking) of a Petri net (P,T,I,O) is
defined as follows:
‡ s: P-> , i.e., a function mapping the set of
places onto {0,1,2, « }.

| 
  
  

PN-28
Exercise: Map onto (P,T,I,O) and S

red black

rb

rr bb

| 
  
  

PN-29
Exercise: Draw diagram
Petri net (P,T,I,O):
‡ P = {a,b,c,d}
‡ T = {e,f}
‡ I(a,e)=1, I(b,e)=2, I(c,e)=0, I(d,e)=0, I(a,f)=0,
I(b,f)=0, I(c,f)=1, I(d,f)=0.
‡ O(e,a)=0, O(e,b)=0, O(e,c)=1, O(e,d)=0,
O(f,a)=0, O(f,b)=2, O(f,c)=0, O(f,d)=3.
State s:
‡ s(a)=1, s(b)=2, s(c)=0, s(d) = 0.
| 
  
  

PN-30
Enabling formalized
Transition  is enabled in state
if and only if:

| 
  
  

PN-31
Firing formalized
If transition  is enabled in state
, it can fire and
the resulting state is
:

| 
  
  

PN-32
Mapping Petri nets onto transition systems
A Petri net (P,T,I,O) defines the following
transition system (S,TR):

| 
  
  

PN-33
Reachability graph
‡ The reachability graph of a Petri net is the part
of the transition system reachable from the
initial state in graph-like notation.
‡ The reachability graph can be calculated as
follows:
1. Let X be the set containing just the initial state and let Y
be the empty set.
2. Take an element x of X and add this to Y. Calculate all
states reachable for x by firing some enabled transition.
Each successor state that is not in Y is added to X.
3. If X is empty stop, otherwise goto 2.

| 
  
  

PN-34
Example
re lack

r :  :  : 

:  : :


rr

:

›  ››      ››› › › 


› :   › r›› 
›Y
Y
  › › : ›Y›  › › ›
| 
  
  

PN-35
Exercise: Give the reachability graph using
both notations
rg rg

g g

r go x go r

o o

or or

| 
  
  

PN-36
Different types of states
‡ 
: Initial distribution of tokens.
‡  : Reachable from initial state.
‡ -
 (also referred to as ³dead states´):
No transition is enabled.
‡ %  (also referred to as home marking):
It is always possible to return (i.e., it is
reachable from any reachable state).

ß     



 
   
 
| 
  
  

PN-37
Exercise: Producers and consumers
‡ Model a process with one producer and one
consumer, both are either  or  and
alternate between these two states. After every
production cycle the producer puts a product in
a  . The consumer consumes one product
from this buffer per cycle.
‡ Give the reachability graph and indicate the final
states.
‡ How to model 4 producers and 3 consumers
connected through a single buffer?
‡ How to limit the size of the buffer to 4?
| 
  
  

PN-38
Exercise: Two switches
‡ Consider a room with two switches and one
light. The light is
or . The switches are in
state  or  .
. At any time any of the
switches can be used to turn the light on or off.
‡ Model this as a Petri net.
‡ Give the reachability graph.

| 
  
  

PN-39
Modeling
‡ Place: passive element
‡ Transition: active element
‡ Arc: causal relation
‡ Token: elements subject to change

r
 
    



u
u 
 
  
 
  
 
 
u  
 
 
 

u


| 
  
  

PN-40
Role of a token
Tokens can play the following roles:
‡ a   /, for example a product, a part, a drug,
a person;
‡ an 
 
 /, for example a message, a
signal, a report;
‡ a  
  /, for example a truck with
products, a warehouse with parts, or an address file;
‡ an 
  , for example the indicator of the
state in which a process is, or the state of an object;
‡ an 
  

: the presence of a token
indicates whether a certain condition is fulfilled.
| 
  
  

PN-41
Role of a place
‡ a type of  

  , like a
telephone line, a middleman, or a
communication network;
‡ a  : for example, a depot, a queue or a
post bin;
‡ a    
, like a place in a
warehouse, office or hospital;
‡ a possible  

: for
example, the floor where an elevator is, or the
condition that a specialist is available.

| 
  
  

PN-42
Role of a transition
‡ an 
: for example, starting an operation, the
death of a patient, a change seasons or the
switching of a traffic light from red to green;
‡ a 
  
 
 /, like adapting a
product, updating a database, or updating a
document;
‡ a 
  
 /: for example,
transporting goods, or sending a file.

| 
  
  

PN-43
Typical network structures
‡ Causality
‡ Parallelism (AND-split - AND-join)
‡ Choice (XOR-split ± XOR-join)
‡ Iteration (XOR-join - XOR-split)
‡ Capacity constraints
± Feedback loop
± Mutual exclusion
± Alternating

| 
  
  

PN-44
Causality

| 
  
  

PN-45
Parallelism

| 
  
  

PN-46
Parallelism: AND-split

| 
  
  

PN-47
Parallelism: AND-join

| 
  
  

PN-48
Choice: XOR-split

| 
  
  

PN-49
Choice: XOR-join

| 
  
  

PN-50
Iteration: 1 or more times

] ] 

| 
  
  

PN-51
Iteration: 0 or more times

] ] 

| 
  
  

PN-52
Capacity constraints: feedback loop

j j 

| 
  
  

PN-53
Capacity constraints: mutual exclusion

| 
  
  
 j j 

PN-54
Capacity constraints: alternating

| 
  
  
 j j 

PN-55
We have seen most patterns, e.g.:
rg rg
 ›Y



› 
 g g

r go go r

ß  ›
o o
› 
› ›
or or
| 
  
  

PN-56
Exercise: Manufacturing a car (2)
‡ Model the production
process shown in the
Bill-Of-Materials . 
?   .
  
‡ Each assembly step
 requires a dedicated
machine and an
operator.
?  ‡ There are two operators
  
and one machine of
 each type.
?  ‡ Hint: model both the


start and completion of


an assembly step.
| 
  
  

PN-57
Modeling problem (1): Zero testing
‡ Transition  should fire if place  is empty.

 â

| 
  
  

PN-58
Solution
‡ Only works if place is N-bounded

 
 
    ››


 ››




| 
  
  

PN-59
Modeling problem (2): Priority
‡ Transition t1 has priority over t2


â


| 
  
  
 ß
u    


PN-60
A bit of theory
‡ Extensions have been proposed to tackle these
problems, e.g., inhibitor arcs.
‡ These extensions extend the modeling power
(Turing completeness*).
‡ Without such an extension not Turing complete.
‡ Still certain questions are difficult/expensive to
answer or even undecidable (e.g., equivalence
of two nets).

* Turing completeness corresponds to the ability to execute any


computation.
| 
  
  

PN-61
Exercise: Witness statements
‡ As part of the process of handling insurance
claims there is the handling of witness
statements.
‡ There may be 0-10 witnesses per claim. After
an initialization step (one per claim), each of the
witnesses is registered, contacted, and informed
(i.e., 0-10 per claim in parallel). Only after all
witness statements have been processed a
report is made (one per claim).
‡ Model this in terms of a Petri net.
| 
  
  

PN-62
Exercise: Dining philosophers
‡ 5 philosophers sharing 5 chopsticks: chopsticks are
located in-between philosophers
‡ A philosopher is either in state eating or thinking and
needs two chopsticks to eat.
‡ Model as a Petri net.

| 
  
  

PN-63
% 

01


.   2
 
   
 
 
!

Prof.dr.ir. Wil van der Aalst


Eindhoven University of Technology, Faculty of Technology Management,
Department of Information and Technology, P.O.Box 513, NL-5600 MB,
Eindhoven, The Netherlands.

| 
  
  

PN-64
Limitations of classical Petri nets
‡ Inability to test for zero tokens in a place.
‡ Models tend to become large.
‡ Models cannot reflect temporal aspects
‡ No support for structuring large models, cf. top-
down and bottom-up design

| 
  
  

PN-65
Inability to test for zero tokens in a place

 â

r      Y 


›
| 
  
  

PN-66
Models tend to become (too) large
r1 r2 r3 r4 r5

incr1 incr2 incr3 incr4 incr5

wheel bell steering


bike frame
wheel

decr1 decr2 decr3 decr4 decr5

]
 
 
l2 l3
?
l1 l4 l5

| 
  
  

PN-67
Models tend to become (too) large (2)
    

 ›  ›  ›  ›

    

  

    


        


]
 
  ?

| 
  
  

PN-68
Models cannot reflect temporal aspects
rg1 rg2

g1 g2

r1 go1 x go2 r2

  ? o1 o2

 


 
or1 or2
| 
  
  

PN-69
No support for structuring large models
rg1 rg2

g1 g2

r1 go1 x go2 r2

o1 o2

or1 or2
| 
  
  

PN-70
High-level Petri nets
‡ To tackle the problems identified.
‡ Petri nets extended with:
± Color (i.e., data)
± Time
± Hierarchy
‡ For the time being be do not choose a concrete
language but focus on the main concepts.
‡ Later we focus on a concrete language: ( .
‡ These concepts are supported by many variants
of CPN including ExSpect, CPN AMI, etc.
| 
  
  

PN-71
Running example: Making punch cards
free Y››› 
›  ››
wait done

start stop

busy

   ››
 ›   ›   › 
›  ››
| 
  
  

PN-72
Extension with color (1)
‡ Tokens have a    (i.e., a )

{ ran " ", e istrationNo " - -11", Year 1 3, olo r " l e", wner "In e"}

{ ran " a a", e istrationNo "P -1 -P ", Year 1 , olor " re ", wner "In e"}

| 
  
  

PN-73
Extension with color (2)
‡ Places are  (also referred to as   ).

›      ›      !› 


"   ¢ ›  

{Brand="BMW", RegistrationNo="GD-XW-11", Year=1993, Colour="blue", Owner= "Inge"}

{Brand="Lada", RegistrationNo="PH-14-PX", Year=1986, Color="grey", Owner="Inge"}

| 
  
  

PN-74
Extension with color (3)
‡ The 
between production and
consumption needs to be specified, i.e., the
value of a produced token needs to be related
to the values of consumed tokens.
3
in sum

2 add 0
3

1 r
?

?i   

| 
  
  
 ? 
PN-75
Running example: Tokens are colored

{ mpNo 6 , xperience 7}

ait done
free
start stop

us
{Name " laas", ddress "Plein ", ate f irt " - ec- 6 ", ender " "}

| 
  
  

PN-76
Running example: Places are typed
record EmpNo:int * Experience:int

wait done
free
start stop

record Name:string *
record Name:string *
Address:string *
Address:string * busy
record Name:string * DateOfBirth:str *
DateOfBirth:str *
Address:string * Gender:string
Gender:string
DateOfBirth:str *
Gender:string *
EmpNo:int *
| 
  
  
 Experience:int
PN-77
Running example: Initial state
{EmpNo=641112, Experience=7}

wait done
free
start stop

busy
{Name="Klaas", Address="Plein 10", DateOfBirth="13-Dec-1962", Gender="M"}

  

| 
  
  

PN-78
Running example: Transition start fired

?   
 ?

it
fr
st rt st

{ " l s", r ss " l i ", t f irt " - c- ", r " ", , ri c }

 

| 
  
  

PN-79
Running example: Transition stop fired
{ , ri c }

it
fr
st rt st

s
{ " l s", r ss " l i ", t f irt " - c- ", r " "}


 ?   

? 

| 
  
  

PN-80
The number of tokens produced is no longer
fixed (1)
{sample_number=931101011, measurement_outcomes="XYV"}

positive

test

sample
negative

{sample_number=931101023, measurement_outcomes="VXY"}

 ?
 ? 

?? 
| 
  
  

PN-81
The number of tokens produced is no longer
fixed (2)
{s mple number , me surement outcomes " Y "}

positi e

test

s mple
neg ti e

r ? ?


?
   

| 
  
  

PN-82
r r r3 r r

Example

incr incr incr3 incr incr

eel ell steerin


ike frame
eel

decr decr decr3 decr decr

l l l3 l l

Model as a colored Petri net.


| 
  
  

PN-83
in

{prod="bell", num=2}


 
#
   › 
›
›Y› increase
›
[{prod="bike", num=4},
stock {prod="wheel", num=2},
r››  › {prod="bell", number=3},
{prod="steering wheel", num=3},
   {prod="frame", num=2}]

›› › › 
decrease
›
›Y
›› 
› Y
›  
| 
  
  
 out
PN-84
in

{prod="bell", num=2}
Types
& ›

increase

[{prod="bike", num=4},
stock {prod="wheel", num=2},
{prod="bell", number=3},
{prod="steering wheel", num=3},

$  % &  {prod="frame", num=2}]


›$ % decrease

& › $› 



 

›%
& $ & › % & ›
| 
  
  
 out
PN-85
Extension with time (1)
‡ Each token has a   .
‡ The timestamp specifies the   when
it can be consumed.

| 
  
  

PN-86
Extension with time (2)
‡ The 

  of a transition is the maximum
of the tokens to be consumed.
‡ If there are multiple tokens in a place, the earliest
ones are consumed first.
‡  transition with the smallest firing time will fire first.
‡ Transitions are  , i.e., they fire as soon as they
can.
‡ Produced token may have a .
‡ The      
is the firing
time plus its delay.
| 
  
  

PN-87
Running example: Enabling time
‡ Transition start is enabled at time 2 =
max{0,min{2,4,4}}.
0

ait done
2 free
start stop

bus

| 
  
  

PN-88
Running example: Delays
‡ Tokens for place busy get a delay of 3
‡ @+3 = firing time plus 3 time units

@+
ait done
free
start stop
@+3 @+

| 
  
  

busy
PN-89
Running example: Transition start fired
‡ Transition start fired a time 2.

ait 0 done
free
start stop
0

us

" 
› : ››  ›'
| 
  
  

PN-90
Exercise: Final state?
a

1 x
1

c e

| 
  
  

PN-91
Exercise: Final state?

re lack
2
r
2 2

rr

| 
  
  

PN-92
Extension with hierarchy
‡ Timed and colored Petri nets result in more
compact models.
‡ However, for complex systems/processes the
model does not fit on a single page.
‡ Moreover, putting things at the same level does
not reflect the structure of the process/system.
‡ Many hierarchy concepts are possible. In this
course we restrict ourselves to 


 
 
.

| 
  
  

PN-93
Instead of rg1 rg2

g1 g2

r1 go1 x go2 r2

o1 o2

or1 or2

| 
  
  

PN-94
We can use hierarchy tl 

tl

 
r  r

 


  
r  r
 

 


  
r r

| 
  
  

PN-95
tl1 tl2
Reuse
x

‡ Reuse saves design


efforts. rg

‡ Hierarchy can have


any number of g

levels
‡ Transition
go r
refinement can be x

used for top-down


and bottom-up o

design
| 
  
  
 or

PN-96
Exercise: model three (parallel) punch card
desks in a hierarchical manner

free

wait done

start stop

busy

| 
  
  

PN-97

  3 
   2

2
 

Prof.dr.ir. Wil van der Aalst


Eindhoven University of Technology, Faculty of Technology Management,
Department of Information and Technology, P.O.Box 513, NL-5600 MB,
Eindhoven, The Netherlands.

| 
  
  

PN-98
Questions raised when considering the
handling of customer orders
‡ How many orders arrive on average?
‡ How many orders can be handled?
‡ Do orders get lost?
‡ Do back orders always have priority?
‡ What is the utilization of office workers?
‡ If the desired product is no longer available,
does the order get stuck?
‡ Etc.

| 
  
  

PN-99
Questions raised when considering the
handling of customers in the canteen
‡ What is the average waiting time from 12.30-
13.00?
‡ What is the variance of waiting times?
‡ What is the effect of an additional cashier on the
queue length?
‡ Etc.

| 
  
  

PN-100
Questions raised when considering the an
intersection with multiple traffic lights
‡ How much traffic can be handled per hour?
‡ Give some volume of traffic, what is the
probability to get a red light?
‡ Is the intersection safe, i.e., crossing flows have
never a green light at the same time?
‡ Can a light go from yellow to green?
‡ Is the intersection fair (i.e., a traffic
light cannot turn green twice while
cars are waiting on the other side)?
| 
  
  

PN-101
Questions raised when considering a printer
shared by multiple users
‡ Can two print jobs get mixed?
‡ Do small jobs always get priority?
‡ Can the settings of one job influence the next
job?
‡ Do out-of-paper events cause jobs
to get lost?
‡ How many jobs can be handled per
day?
‡ What is the probability of a paper jam?
| 
  
  

PN-102
Questions raised when considering a teller
machine
‡ What is the average response time?
‡ Is there a balance, i.e., the amount of money
leaving the machine matches the amount taken
from bank accounts?
‡ How often should the machine be filled
to guarantee 90% availability?
‡ Is fraud possible?
‡ Etc.

| 
  
  

PN-103
Analysis
‡ Analysis is typically model-
 driven to allow e.g. what-if
questions.
‡ Models of both operational
¢  
 processes and/or the
 
  information systems can be
analyzed.
‡ Types of analysis:

± O  
± O 

±   
  
| 
  
  

PN-104
Three analysis techniques (Chapter 8)
‡ Reachability graph
‡ Place & transition invariants
‡ Simulation

‡ Each can be applied to both classical and high-level Petri


nets. Nevertheless, for the first two we restrict ourselves to
the classical Petri nets.
‡ Use:
± reachability graph (validation, verification)
± invariants (validation, verification)
± simulation (validation, performance analysis)

| 
  
  

PN-105
Reachability graph

rg1 rg


: :
g1 g



r1 g 1 g r
:
 
1

 
: :
r1 r

›› › › 


| 
  
  

rYY   › Y›(
PN-106
Alternative notation

r 1 r

 

1


r1 o1 o r


o1 o


 
or1 or

| 
  
  

PN-107
Reachability graph (2)
‡ Graph containing a node for each reachable
state.
‡ Constructed by starting in the initial state,
calculate all directly reachable states, etc.
‡ Expensive technique.
‡ Only feasible if finitely many states (otherwise
use coverability graph).
‡ Difficult to generate diagnostic information.

| 
  
  

PN-108
Infinite reachability graph
rg1 rg

g1 g

r1 g 1 g r

r1 r
| 
  
  

PN-109
Exercise: Construct reachability graph

free

ait enter before ake picture after lea e gone

occupie

| 
  
  

PN-110
Exercise: Dining philosophers (1)
‡ 5 philosophers sharing 5 chopsticks: chopsticks are
located in-between philosophers
‡ A philosopher is either in state eating or thinking and
needs two chopsticks to eat.
‡ Model as a Petri net.

| 
  
  

PN-111
Exercise: Dining philosophers (2)
‡ Assume that philosophers take the chopsticks one by
one such that first the right-hand one is taken and then
the left-hand one.
‡ Model as a Petri net.
‡ Is there a deadlock?

| 
  
  

PN-112
Exercise: Dining philosophers (3)
‡ Assume that philosopher take the chopsticks one by one
in any order and with the ability to return a chopstick.
‡ Model as a Petri net.
‡ Is there a deadlock?

| 
  
  

PN-113
Structural analysis techniques
‡ To avoid state-explosion problem and bad
diagnostics.
‡ Properties independent of initial state.
‡ We only consider place and transition
invariants.
‡ Invariants can be computed using linear
algebraic techniques.

| 
  
  

PN-114
Place invariant
man ‡ Assigns a .  to
each place.
‡ The weight of a
couple token depends on
marriage divorce
the weight of the
place.
woman ‡ The . 
 
 is
  , i.e., no
transition can
      
› change it
| 
  
  

PN-115
Other invariants
‡ 1 man + 0 woman + 1 couple
man
(Also denoted as: man + couple)
‡ 2 man + 3 woman + 5 couple
‡ -2 man + 3 woman + couple
couple
‡ man ± woman
marria e divorce
‡ woman ± man
woman (Any linear combination of
invariants is an invariant.)

| 
  
  

PN-116
Example: traffic light
rg1 rg2
‡ r1 + g1 + o1
‡ r2 + g2 + o2
g1 g2
‡ r1 + r2 + g1 + g2 + o1 + o2
‡ x + g1 + o1 + g2 + o2
r1 go1 x go2 r2 ‡ r1 + r2 - x

o1 o2

or1 or2

| 
  
  

PN-117
Exercise: Give place invariants
start pr cti n start c ns pti n

free pr cer ait c ns er

pr ct

en pr cti n en c ns pti n
| 
  
  

PN-118
Transition invariant
‡ Assigns a .  to
man each 

.
‡ If each transition
fires the number of
couple times indicated, the
marriage divorce system is 

 
.
woman ‡ I.e. transition
invariants indicate
   firing sets
without any net
  ›  › effect.
| 
  
  

PN-119
Other invariants
‡ 1 marriage + 1 divorce
(Also denoted as: marriage +
divorce)
‡ 20 marriage + 20 divorce
c l
Any linear combination of
rri i rc
invariants is an invariant, but
transition invariants with
negative weights have no
obvious meaning.
Invariants may be not be
  .

| 
  
  

PN-120
Example: traffic light
rg1 rg2
‡ rg1 + go1 + or1
‡ rg2 + go2 + or2
g1 g2
‡ rg1 + rg2 + go1 + go2 + or1
+ or2
r1 go1 x go2 r2 ‡ 4 rg1 + 3 rg2 + 4 go1 +
3 go2 + 4 or1 + 3 or2
o1 o2

or1 or2

| 
  
  

PN-121
Exercise: Give transition invariants
start ro ction start cons tion

free ro cer ait cons er

ro ct

en ro ction en cons tion


| 
  
  

PN-122
Exercise: four philosophers
st1
‡ Give place
e1 t1
invariants.
se1
‡ Give
c c1
transition
t e2 invariants
st se se2 st2
e t2

c3 c2

se3

t3 e3

| 
  
  

st3
PN-123
Two ways of calculating invariants
‡ "Intuitive way": Formulate the property that you
think holds and verify it.
‡ "Linear-algebraic way": Solve a system of linear
equations.

Humans tend to do it the intuitive way and


computers do it the linear-algebraic way.

| 
  
  

PN-124
man
Incidence matrix of a Petri net
‡ Each row corresponds to couple
a place.
marriage divorce
‡ Each column corresponds
to a transition. woman

‡ Recall that a Petri net is


described by  r
‡  where
   
 is a place and  a  €
transition. `     €
   €
| 
  
  


PN-125

   ›
Example
man

   
couple
 €
marriage divorce
`     €
woman    €



›   ›
| 
  
  

PN-126
Place invariant
‡ Let N be the incidence matrix of a net with n
places and m transitions
‡ Any solution of the equation ] is a
transition invariant
± ] is a row vector (i.e.,   matrix)
±  is a row vector (i.e.,  u matrix)
‡ Note that (0,0,... 0) is always a place invariant.
‡ Basis can be calculated in polynomial time.

| 
  
  

PN-127
Example    
 €
    €  :
man

couple

   €


marriae i orce


oman

Solutions:
‡ (0,0,0)
   ‡ (1,0,1)
 €
:    ?
   €  : ‡ (0,1,1)
 €
 ‡ (1,1,2)
‡ (1,-1,0)
| 
  
  

PN-128
Transition invariant
‡ Let N be the incidence matrix of a net with n
places and m transitions
‡ Any solution of the equation ] is a place
invariant
± ] is a column vector (i.e., u  matrix)
± is a column vector (i.e.,   matrix)
‡ Note that    r is always a place invariant.
‡ Basis can be calculated in polynomial time.

| 
  
  

PN-129
Example      
 €  €
   €   €
man

couple

   €  €
 

marriae i orce


oman

     Solutions:
 €     € ‡ (0,0)T
  € €€    €
 €  ?  € ‡ (1,1)T
   ‡ (32,32)T
| 
  
  

PN-130
start_production start_consumption

Exercise
free producer wait consumer

product

end_production end_consumption

‡ Give incidence matrix.


‡ Calculate/check place invariants.
‡ Calculate/check transition invariants.
| 
  
  

PN-131
Simulation
‡ Most widely used analysis technique.
‡ From a technical point of view just a "walk" in
the reachability graph.
‡ By making many "walks" (in case of transient
behavior) or a very "long walk" (in case of
steady-state) behavior, it is possible to make
reliable statements about properties/
performance indicators.
‡ Used for validation and performance analysis.
‡ Cannot be used to prove correctness!

| 
  
  

PN-132
Stochastic process
‡ Simulation of a deterministic system is not very
interesting.
‡ Simulation of an untimed system is not interesting.
‡ In a timed and non-deterministic system, durations
and probabilities are described by some
 
.
‡ In other words, we simulate a   
 !
‡ CPN allows for the use of distributions using some
internal random generator.

| 
  
  

PN-133
Uniform distribution

Y

 ›

| 
  
  

PN-134
Negative exponential distribution

| 
  
  

PN-135
Normal distribution

| 
  
  

PN-136
Distributions in CPN Tools
Assume some library with functions:
‡ uniform(x,y)
‡ nexp(x)
‡ erlang(n,x)
‡ Etc.

A nice function is also C.ran() which returns a randomly


selected element of finite color set C, e.g.,

     
 
   
returns a number between 1 and 5
| 
  
  

PN-137
Example

c l r T it;
c l r ice i t it 1.. ;

() ()
4"
!

tri er T () t r ice tc me ice

| 
  
  

PN-138
Example(2)

c l r INT i t;
c l r TINT i t time ;
c l r ice i t it 1.. ;
c l r ela i t it ..99;
t r ice
tri er 4"
!

TINT tc me ice
5!6 4 "
!!

| 
  
  

PN-139
Subruns and confidence intervals
‡ A single run does not provide information about
reliability of results.
‡ Therefore, multiple runs or one run cut into
parts: 
.
‡ If the subruns are assumed to be mutually
independent, one can calculate a 



, e.g., the flow time is with 95%
confidence within the interval 5.5+/-0.5 (i.e.
[5,6]).

| 
  
  

PN-140
Example of a simulation model
‡ Gas station with one pump and space for 4 cars
(3 waiting and 1 being served).
‡ Service time: uniform distribution between 2 and
5 minutes.
‡ Poisson arrival process with mean time between
arrivals of 4 minutes.
‡ If there are more than 3 cars waiting, the "sale"
is lost.
‡ Questions: flow time, waiting time, utilization,
lost sales, etc.

| 
  
  

PN-141
Top-level page: u 
clr r stri

rri› r

› ir › t s st ti

ri› r

›rt r

| 
  
  

PN-142
I

rri› r
c c
Subpage 

   [l› ( )< ] [l› ( ) ]


ti 
›
› ri›

clr r stri ; [c]


clr  it; []
clr Tr r ti›;
clr ›
› list r;
›
›
›
›
r c:r; c::
r :
›
›;
f
l› ( :
›
›) if [] t › strt
›ls› l› (tl( ));
c
ifr( , ) () c


fr›› ()

fill
 Tr

c ()

› 

c

t
t

| 
  
  
 ›rt r ri› r

PN-143
Assuming pages for the environment and
measurements the last two pages allow for ...

‡ Calculation of  .  (average, variance,


maximum, minimum, service level, etc.).
‡ Calculation of .
  (average, variance,
maximum, minimum, service level, etc.).
‡ Calculation of   (average).
‡ Probability of no space left.
‡ Probability of no cars waiting.
For each of these metrics, it is possible to formulate
a confidence interval given sufficient observations.

| 
  
  

PN-144
In

arrive ar
c c
Alternatives [len( )< ] [len( ) ]

putin ueue driveon



color ar string; [c]


color Pump unit; []
color Tar ar timed;
color ueue list ar; ueue ueue
var c:ar; c::
var : ueue;
fun len( : ueue) if [] then start
else 1 len(tl( ));
c uniform(2,5) () c

pumpfree ()
Model the following
fillup Tar Pump
alternatives: c ()

‡ 5 waiting spaces end

‡ 2 pumps c
ut ut

‡ 1 faster pump
| 
  
  
 depart ar driveon ar

PN-145
Simulation of a Production system

& ] ! ) "
*

"
| 
  
  

PN-146
ë ›  
 

Data Y X $
  7 Y )
 8 9 Z 
 : ; 5 ?
2?  ?

A $ A $ A ¬
B  B  B 
C $ C  C 

  Š   r 

    
? 
| 
  
  
 
PN-147
Top level page: u 
clr I T  i t;
clr r  stri ;
clr T  r
ct r * I T;
clr Ti›  r ti›;
clr TTi›  T ti›;
r : r;
r t:I T; 
r i:I T;
r›s
rc›s I T r›s
rc›sY I T r›s
rc›s I T
" " " " " "
" " " " " "
"" "" ""
r r r r
 k   k   k   k   
rk rk rk
s
li›r c› t›r  c› t›r  c› t›r  c
st›r
 Y 

r
ct r r
ct r r
ct r r
ct r
(" ",) (" ",) (" ", ) (" ", ) (" ", )
(" ",) (" ",) (" ", ) (" ", ) (" ", )
("",) ("",) ("", ) ("",) ("", )
il›ti› T rc›ssi  T rc›ssi  T rc›ssi  T citi› TTi›
ti› ti›Y ti›
s
li›r rkc› t›r rkc› t›r rkc› t›r c
st›r
il›ti›  il›ti› rc›ssi ti›  rc›ssi ti›  rc›ssi ti›  citi›  citi›
k  i  k   rc›ssi ti› rc›ssi ti›Y rc›ssi ti› k  
t  k  
r
ct
t  r
ct r›s
rc›s  r›s
rc›s r›s
rc›s  r›s
rc›sY r›s
rc›s  r›s
rc›s r
cti  r
ct
k  i  k   k  i  k   k  i  k  
r
cti  r
ct r
cti  r
ct r
cti  r
ct
k  
t  k   k  
t  k   k  
t  k  
| 
  
  
 r
ct
t  r
ct r
ct
t  r
ct r
ct
t  r
ct

PN-148
Sub page:


accept_order In
p

(p,t) kanban_in Prod


p@+t
In/Out (p,t)

io_lead_time PT oip PTimed


p
Out
p

deliver_order product_out Prod

| 
  
  

PN-149
Sub page: 
 u

Out place_order
p

kanban_out Prod (p,t)

(p,t)@+t In/Out

c_ia_time PTTimed

In p

product_in Prod consume

| 
  
  

PN-150
Sub page:  

t

k  
t r 
› rc

t


i 
r
ct
t r
 i I /
t

i Ti› I T
r›s
rc›s
t
[i ] i-
I  i
(,t)
k  i r strtrc I /
t
I  (,t)

rc›ssi ti› T
r
cti r

| 
  
  

PN-151
clr INT  i t;
clr Pr  stri ;
clr PT  r
ct Pr * INT;
clr PTie  Pr tie;
clr PTTie  PT tie;
vr :Pr; 
vr t:INT;  5

Overview vr i:INT;


2""
1" "
res
rces INT

2""
1" "
res
rcesY INT

2""
res
rces INT

1" "
1"" 1"" 1""
Pr Pr Pr Pr
 k  1 k  2 k   k   

›
  s
lier
wrk
ce ter


wrk
ce ter
Y

wrk
ce ter

 c
ster

+ ›  › › r
ct1 Pr r
ct2 Pr r
ct Pr r
ct Pr
      
+
    iletie
1(" ",2)
1(" ",1)
1("",2)
PT rcessi 
1("",2)
1(" ",)
1("",)
PT rcessi 
1(" ",5)

1("", )
PT

1(" ", )

rcessi 
1(" ",)
1(" ", )
1("",1)
PT citie
1("",)

1(" ", )
1("", )
PTTie

+ , › s
lier
iletie  iletie
k  i  k  1
tie
wrkce ter
rcessi tie 
rcessi tie
tieY
wrkce ter
rcessi tie 
rcessi tieY
tie
wrkce ter
rcessi tie 
rcessi tie
c
ster
citie  citie
k  
t  k  
r
ct
t  r
ct1 res
rces  res
rces res
rces  res
rcesY res
rces  res
rces r
cti  r
ct

+ ››   k  i  k  2
r
cti  r
ct1
k  
t  k  1
r
ct
t  r
ct2
k  i  k  
r
cti  r
ct2
k  
t  k  2
r
ct
t  r
ct
k  i  k  
r
cti  r
ct
k  
t  k  
r
ct
t  r
ct

+ › 
O
t
ccetrer I
 lcerer
k  
t Pr  O
t
e rc

(,t) O
t
k  i Pr
t  (,t)
k  
t Pr
I /O
t (,t)
i1
r
ct
t Pr (,t)t I /O
t
 i I /O
t
iletie PT i PTie
 citie PTTie
O
t wi PTie INT
res
rces
 t I
[i>1] i-1 
I
 i
eliverrer r
ct
t Pr r
cti Pr c s
e
(,t)
k  i Pr strtrc I /O
t
I  (,t)

rcessi tie PT
r
cti Pr

| 
  
  

PN-152
Classical versus high-level Petri nets
‡ Simulation clearly works for all types of nets.
‡ Hierarchy is never a problem.
‡ Time allows for new types of analysis.
‡ Reachability graphs and invariants can also be
extended to high-level nets.
± More complex (both technique and computation)
‡ Sometimes abstraction from color is possible to
derive invariants (consider previous example).

| 
  
  

PN-153
Exercise: Five Chinese philosophers
‡ Recall hierarchical CPN model of five
Chinese philosophers alternating between
states thinking and eating.
± Give place invariants
± Give transition invariants
‡ Change the model such that philosophers
can take one chopstick at a time but avoid
deadlocks and a fixed ordering of
philosophers.
± Give place invariants
± Give transition invariants
| 
  
  

PN-154
color lackToke 
it;
var : ackToke Top-level page
p ilosop er
left  
 rig t  1
()  ()
1

lackToke
P1 lackToke


P5 P
p ilosop er
left  1 
rig t  5 p ilosop er
left  
()  () rig t  
5

lackToke lackToke

 ()
P P
 
p ilosop er
lackToke p ilosop er
left  5 left  
rig t   rig t  
| 
  
  

PN-155
Page philosopher
thi k () eat

lackToke lackToke

 
 
takechopsticks p
to chopsticks

 


left right

lackToke I /
t I /
t lackToke

| 
  
  

PN-156
Flat model is obtained by replacing
substitution transitions by subpages
color BlackToken = unit;
var b:BackToken  
HS
philosopher
left = CS2
right = CS1
+2 
() CS2 ()
CS1

BlackToken
+2  
PH1 BlackToken
+2  ??
PH5
HS
philosopher
left = CS1
PH2
HS
+2 ??
right = CS5 philosopher
left = CS3
() CS3 () right = CS2
CS5

BlackToken BlackToken think () eat

CS4 () BlackToken BlackToken


PH4 PH3
HS HS b b
philosopher
BlackToken philosopher
b b
left = CS5 left = CS4 takechopsticks putdonchopsticks
right = CS4 right = CS3

b b
b
b
left right

BlackToken In/ ut In/ ut BlackToken

| 
  
  
 ››- › 
PN-157
t ink () eat
Alternative page lackTken lackTken

 
 
starteating startt inking

 


lleft l rig t

lackTken lackTken

  
ret
rnleft takeleft takerig t ret
rnrig t

 
 
left rig t

lackTken In/
t In/
t lackTken

| 
  
  

PN-158
You should be able to ...
‡ Construct a reachability graph for a classical Petri
net.
‡ Give meaningful place and transition invariants for
a classical Petri net.
‡ Construct a reachability graph and give
meaningful place and transition invariants for a
hierarchical CPN after abstracting from data and
time and removing hierarchy.
‡ Build a simple simulation model using CPN.
‡ Motivate the use of each of the analysis
techniques.
| 
  
  

PN-159

Vous aimerez peut-être aussi