Petri Nets

From BrickWikiTwo
Jump to: navigation, search

Petri Nets allow specifying business processes in a formal and abstract way.

Different classes of Petri Nets could be distinguished, each with its own options in representing business process models.


Condition Event Nets

  • each place can have at most one token at each point in time of a condition event net
  • one token is withdrawn of each input place and one token is put on each output place when a transition fires
  • tokens could not be distinguished from one another, they are unstructured
  • M(p) <= 1
  • a transition is enabled, if and only if all input places have one token and all output places have no token
  • conditions represented by the input places are met and the conditions represented by the output places are not met

Place Transition Nets

  • are an extension of condition event nets
  • each place can have an arbitrary number of tokens at any point in time of a place transition net
  • multiple token are withdrawn of each input place and multiple token are put on each output place when a transition fires
  • the number of withdrawn and produced tokens depends from the weights associated with the arcs connecting the transition, they could be represented by labeled arcs or by a appropriate number of arcs
  • tokens could not be distinguished from one another, they are still unstructured
  • multiple process instances represented by multiple tokens could not distinguished in all cases

Coloured Petri Nets

  • tokens carry values in each state of a Petri net and therefore they could be distinguished and also different process instances could be distinguished
  • coloured tokens carry values, i.e. a identifier of the process instance they belong to
  • the values could be typed like variables in programming languages, i.e. data types are so called colour sets
  • enabling of a transition depends on the presence and value of a token
  • expressions are attached to transitions to evaluate presence and value of a token
  • the specific firing behaviour of a transition depends from the postcondition of the transition
  • expressions could be attached to arcs (arc expressions, they could determine whether a transition is enabled, they evaluate to multi-sets which determine the tokens removed from the input places and added to the output places
  • bindings associate data values to variables, i.e. colours to tokens
  • the enabling of a transition depends on a binding
  • each transition in a coloured Petri net can have its own transition behaviour, therefore a high expressive power is available
  • therefore coloured Petri nets are well suited to represent business process models, they are the basis for Workflow Nets


In case of representing real live business process models, some deficiencies of Petri Nets must be considered. They could be identified and described by comparing the possible control flow pattern of Petri Nets with the full set of nowadays well-known control flow patterns.

Multiple Instances
If multiple instances of a specific activity occur in a business process, Petri Nets do not facilitate an adequate representation.
Advanced Synchronising Patterns
In Petri Nets, no abilities of representing advanced synchronisation patterns like or split, or join and discriminator are available.
Nonlocal Firing Behaviour
In Petri Nets only a token in the input place of a transition enables activation and execution of this transition. No possibility to affect non-local parts of the process is available. For instance no cancellation patterns with impact to non-local activities are possible.

Quod Vide

Personal tools