Petri nets modeling conventions

Process modeling with Petri nets is based on these principles:

  • An activity is enabled when there is at least one token in all connected input states of the activity.
  • An activity consumes one token from every input state, and produces one token to every connected output state.
  • Control activities are dedicated for the routing of tokens and have special capabilities.
  • Typically, control activities behave as normal activities regarding token consumption and production.
  • The actual behavior of control activities is fully determined by assigning static conditions to the input and output transitions with states. Static conditions refer to an implementation decision. Dynamic conditions refer to a run-time decision moment. The static condition overrules the dynamic condition because the static condition enables/disables paths in the business process. Dynamic conditions determine the path through the business process.
  • There can be more than two incoming or outgoing transitions.
The control structures

The R1 and R2 references used in the following texts refer to dynamic conditions.

AND split
[...]

The control activity unconditionally consumes one token and produces two tokens, with one for each output state.

OR/XOR split

The control activity consumes one token and produces one or two tokens, with one for each output state at the most, depending on the actual dynamic condition values of R1 and R2.

If R1 and R2 exclude each other, the construction is an exclusive OR, called XOR (R1 or R2, but not both). Otherwise, the construction is an OR (R1 or R2, or both).

AND join (optional)
[...]

If all input states contain at least one token, the control activity is enabled. The control activity unconditionally consumes the two tokens and produces one token.

OR/XOR join (optional)

Depending on the actual condition values of R1 and R2, the control activity will consume one or two tokens and produce one token. If R1 and R2 exclude each other, the construction is an exclusive OR (R1 or R2, but not both). Otherwise, the construction is an OR (R1 or R2, or both).

Logically applying these control structure principles results in these basic building blocks. Each process can be modeled with these building blocks, and using these blocks guarantees the correct syntax.

The Petri net building blocks

AND: activities executed in parallel (mandatory)

[...]

The sequence in which B and C are executed is not important. The AND join is optional and not necessary in a DEM business process.

OR: activities executed in parallel (optional)

[...]

The first control activity has a variable number of output states, determined by the conditions R1 and R2. The second control activity has a variable number of input states, determined by the same conditions R1 and R2. The OR join is optional and not necessary in a DEM business process.

XOR: specialized activities
[...]

Based on the conditions R1 and R2, activity B or C is selected (not both, hence an exclusive OR). An OR join (no longer required in DEM) is represented by a single output state at the end of the process.

Iteration of activities
[...]

The execution of activity B, one or more times. The number of iterations is set.