Petriflow 102 - Part 3
Sequence Variations & Token Multiplicity
💡 What you'll learn
Explore how different execution sequences can occur in Petri nets, how token multiplicity affects concurrency, and what limitations exist in Petriflow compared to the general Petri net theory.
Overview
Goal & Context
In the third section of the lecture, we continue with the bicycle assembly example and focus on execution sequence variations and token multiplicity. You’ll see how the same process can unfold in multiple ways depending on token distribution, and how Petriflow restricts certain concurrency to keep workflow semantics deterministic.
This section covers:
- Sequence alternatives in token flow
- Token multiplicity and its meaning
- How Petriflow limits simultaneous task instances
- Differences between Petri nets and workflow systems
Key concepts
Sequence Variations
In a Petri net, multiple transitions may be enabled simultaneously if their input places contain tokens. This creates sequence variation - different orders of firing can lead to the same or different final states.
For example, in the bicycle assembly model:
- You can attach wheels first or attach the handlebar first
- Both paths lead to the same final marking (a completed bicycle)
NOTE
The Petri net captures true concurrency - tasks that can happen in parallel without interfering with each other.
Token Multiplicity
Each token in a Petri net represents a unit of availability - a part, data item, or resource.
Having multiple tokens in a place means the transition can fire multiple times, once per token.
| Place | Tokens | Meaning |
|---|---|---|
| Wheel | 2 | Two wheels ready for use |
| Skeleton | 1 | One bicycle frame |
| Handlebar | 2 | Two handlebars in stock |
| Bicycle | 0 | None assembled yet |
When transitions are fired repeatedly, the model behaves quantitatively rather than just logically. Each firing consumes the required number of tokens from input places and produces them in output places.
NOTE
Token multiplicity = how many times a transition can fire given current resources.
Concurrency and Petriflow Limitations
In standard Petri nets, the same transition can be executed concurrently multiple times if enough tokens exist. However, Petriflow restricts this behavior for workflow clarity:
- You cannot have multiple parallel instances of the same task
- You can have different tasks executing concurrently
Example:
You cannot run Assemble Skeleton + Wheels twice at the same time in Petriflow, but you can execute Assemble Skeleton + Wheels and Assemble Skeleton + Handlebar simultaneously.
This limitation reflects real-world role-based constraints - typically one user or processor handles a task instance.
Workflow State Definition
The state of a Petriflow workflow is defined by:
- The marking - how many tokens are in each place
- The execution state - which tasks are currently active or finished
Together, they define the complete runtime state of a process.
| State Element | Represents |
|---|---|
| Token distribution | Availability of resources or process states |
| Task execution | Which transitions are assigned or finished |
NOTE
Petriflow = Petri net + Execution semantics + Roles + Data
This transforms a theoretical model into an executable workflow.
Video
Watch the lecture segment from Petriflow 102 - Part 3 (25:40 – 36:29).
Visual steps
1️⃣ Parallel Assembly Paths
Two transitions can fire independently: attaching wheels first or handlebar first.
2️⃣ Token Multiplicity Visualization
Multiple tokens in input places enabling repeated execution of transitions.
3️⃣ Petriflow Concurrency Rules
Illustrates allowed and disallowed concurrency - different tasks may run, except identical ones.
4️⃣ State and Marking Overview
Combined marking and task execution define workflow state in Petriflow simulation.
Summary
| Concept | Description |
|---|---|
| Sequence Variation | Multiple enabled transitions allow different execution orders |
| Token Multiplicity | Defines how many times transitions can fire |
| Concurrency | Multiple tasks can execute in parallel under Petriflow rules |
| Restriction in Petriflow | Only one instance per task can be active |
| Workflow State | Defined by token marking and task activity |
Takeaway:
Petri nets describe flexible process behavior through tokens and concurrency. Petriflow builds on this but enforces controlled execution semantics, ensuring predictable, user-centric workflows.
You now understand:
- How sequence variation emerges in Petri nets
- How token multiplicity influences firing behavior
- Why Petriflow restricts duplicate task instances
- How Petriflow defines the state of workflows using markings and execution data