Parallel Process Modeling

with Petri Nets and Finite

Automata
What is Parallel Process
Modeling?
Creating a simplified representation of a system where
multiple processes execute simultaneously is essential
for understanding and analyzing systems with concurrent
activities—tasks that happen at the same time. In both
computing and daily life, many tasks occur in parallel,
and modeling these activities helps in designing,
verifying, and optimizing such systems.
Why Model Parallel Processes?

Concurrent systems can be complex and challenging to

design correctly due to the vast number of possible event
orderings that can occur. Testing every interleaving of
concurrent events manually is infeasible, and issues like
deadlocks or race conditions may only surface under
specific timing scenarios. Modeling provides a powerful
solution—it helps detect such problems early and ensures
that the system behaves safely and correctly. Moreover,
modeling offers valuable design insight by clarifying
interactions and synchronization requirements between
parallel tasks.
Two Modeling Approaches
We will explore two formalisms for modeling parallel
processes:

1. Finite Automata (Finite State Machines): Model system

behavior as states and transitions.
2. Petri Nets: Model system behavior with places (states),
transitions (events), and tokens to represent
concurrent conditions.
Both can represent parallelism, but in different ways.
We’ll examine each individually.
Finite Automata – Basics
A mathematical model of computation consisting of a finite number of
states. The system is always in exactly one state at a time
The automaton can change state in response to events or inputs
(transitions are labeled by those events). Each transition moves from
one state to another​
Key Components:
• Set of states (including a starting state and possibly one or more
ending/accepting states).
• Set of input events or symbols that trigger transitions.
• Transition function defining how state changes occur.
Finite automata naturally model sequential processes – one event at
a time causes a state change.
 Finite Automata – Example
(Turnstile)
A simple finite state machine for a turnstile. It has
two states (Locked and Unlocked) and transitions
on two events: coin (insert coin) and push.
Initially, the turnstile is Locked. Inserting a coin
causes a transition to Unlocked (allowing passage),
and pushing the gate when Unlocked causes a
transition back to Locked
Finite Automata and Parallel
Processes
• Single FSM = one active state at a time. How do we handle
multiple things at once?
• Concurrent Components: We can model each parallel component
as its own FSM, then consider the combination.
• Composition: One approach is to take the Cartesian product of
states (one FSM for each parallel process) – the combined
system’s state is a tuple (State_A, State_B, ...).
• Interleaving Semantics: In the combined model, transitions from
different component FSMs can occur in turn (interleaved) to
represent concurrent execution. There is no built-in notion of
“simultaneous” state change in basic FSMs; concurrency is
modeled by rapid switching or by parallel state machines.
Finite Automata and Parallel
Processes
Extended FSMs: Advanced models (e.g. statecharts)
introduce the idea of orthogonal regions (multiple
FSMs running in parallel)​to explicitly handle
concurrency.
Petri Nets – Introduction
Places represent conditions or states, while transitions
represent events or actions. These nodes are connected
by arcs, which always link a place to a transition or vice
versa, never between two places or two transitions.
Tokens—shown as dots—reside in places and indicate
the current state or availability of resources. The
marking of a Petri net refers to the distribution of tokens
across places, effectively representing the system’s
state. A transition becomes enabled when all its input
places contain at least one token. When it fires, it
consumes one token from each input place and
produces a token in each output place, thereby
simulating a state change in the system.
Petri Net Basics – Places, Transitions,
Tokens
• Places (○): Hold tokens; represent conditions or
resources. A place can have zero, one, or multiple
tokens. For example, a place might represent “Task A is
completed” and a token in it means yes, it’s done.
Transitions (▭): Fire (trigger) when enabled. Enabled =
all input places have ≥1 token​. Firing = consume
token(s) from inputs, produce token(s) in outputs.
Petri Net Basics – Places, Transitions,
Tokens
• Token Dynamics: Tokens move through the net via
transition firings, modeling the flow of execution.
Multiple tokens in different places mean multiple
conditions hold concurrently.
• Concurrent Execution: If two transitions have no
dependency (they don’t require the same token), they
can fire independently – possibly simultaneously. This
represents parallel events.
• Graphical Example Elements: A Petri net diagram
might show, for instance, two tokens in two separate
places enabling two different transitions at the same
time – illustrating parallel tasks.
Petri Nets and Concurrency
• Natural Parallelism: Petri nets are well-suited to
model concurrent behavior of distributed systems​.
Multiple tokens = multiple activities can proceed in
parallel.
• Example Concept: If we have two parallel tasks, we
can represent each with a branch of places/transitions.
Tokens in each branch move independently until a
synchronization point.
• Synchronization: Petri nets easily model
synchronization by requiring tokens from multiple
places for a transition to fire (e.g., an AND-join requires
all parallel activities to complete before proceeding​)
Petri Nets and Concurrency
• Choice: They also model decisions or branching (places
feeding into multiple transitions – this gives
nondeterministic choice or OR-split).
• No Global Clock: Transitions fire as soon as they are
enabled (in any order if concurrent). This asynchronous
firing mimics real concurrent processes.
Example Scenario – Parallel
Assembly Process
• Scenario: Manufacturing a product that requires two
components (A and B) to be made in parallel, then
assembled together.
• Process Description:
• Task A and Task B can start at the same time (independent
assembly lines for two parts).
• Once both parts are completed, a final assembly (Task
C) puts them together.
Example Scenario – Parallel
Assembly Process
• Real-World Context: Think of assembling a gadget
where one team works on Part A, another on Part B
simultaneously. Only after both parts are ready can you
combine them into the final product.
• Modeling Goal: We want to model this so that it
captures the parallel execution of A and B and the
synchronization that assembly C cannot start until A
and B are done.
Finite Automata Model – Assembly
Process
States in this FSM:
• Start: neither task done yet (both A and B in progress).
• A done, B in progress: A finished first, B still working.
• B done, A in progress: B finished first, A still working.
• A and B done: both tasks completed (ready for
assembly).
• End: final assembly completed.
Finite Automata Model – Assembly
Process
Transitions:
• “Fork/start both” – begins A and B in parallel (from Start
to parallel-in-progress state).
• “A finishes” or “B finishes” – occur when a task
completes, moving to a state reflecting that completion.
• “Assemble join” – represents the final assembly starting
once both are done (transition into End state).
 Finite Automata Model – Assembly
Process
Finite Automaton modeling two
parallel tasks A and B followed by a
join. Each state represents the
completion status of tasks. For
example, state “A done, B in progress”
means Task A is finished while Task B
is still running. From that state, if B
finishes, the system moves to “A and
B done”. Similarly, if B had finished
first, there’s a state “B done, A in
progress”, and then if A finishes it also
leads to “A and B done”. Once both
are done, the transition “Assemble”
leads to the final state End,
Petri Net Model – Assembly Process
• Parallel tokens: After the initial fork transition, there are two
tokens marking that A and B are in progress simultaneously.
• Independent transitions: “Finish A” and “Finish B” can occur
in any order (or even at the same time in theory) because they
are enabled independently when their respective task-in-
progress place has a token.
• Synchronization: The “Join (assemble)” transition waits until
one token in A done and one token in B done are present,
enforcing that both tasks finished. This is the synchronization
barrier – an AND-join​
• Result: Token in “End” place signifies the product is assembled
(both parts integrated).
Petri Net Model – Assembly Process

Petri Net modeling the same parallel assembly

scenario. Two branches represent Task A and Task
B proceeding concurrently. A token in the top
branch (left circle) indicates Task A is underway,
and a token in the bottom branch (right circle)
indicates Task B is underway. The transitions
“Finish A” and “Finish B” fire independently when
their tasks complete, moving tokens into the
places A done and B done. The final transition “Join
(assemble)” has two incoming arcs (from A done
and B done), so it will only fire when both places
have tokens (meaning both A and B are done).
When it fires, it consumes those two tokens and
produces a token in the End place, indicating the
assembly is complete.
Applications of Finite Automata
Finite state machines (FSMs) are widely used for modeling
control logic in various domains such as communication
protocols, workflows, user interface interactions, and
hardware design. In workflow and protocol modeling, each
component or participant can be represented as an FSM, and
the overall system emerges from their interaction through
event communication—such as in network protocols where
sender and receiver each have their own automaton. In
hardware design, FSMs are fundamental for sequential circuit
design, where each module transitions through states based
on inputs and clock signals; multiple FSMs can operate in
parallel on a chip, typically synchronized by a global clock.
Applications of Finite Automata
In software, FSMs are used in game development to model
character behaviors, which can be extended to concurrent
scenarios by assigning FSMs to multiple characters or
subsystems. UI navigation and process flows are also often
managed through state machines. To model concurrency,
FSMs can be composed in parallel—for example, in model
checking, each software thread can be modeled as an FSM,
allowing tools to explore all possible interleavings. Finite-
state process languages like FSP and tools such as LTSA
support the specification and analysis of multiple FSM-
based processes, enabling verification of complex
concurrent behavior.
Applications of Petri Nets
petri nets are extensively used across various domains to
model and analyze systems with concurrent behavior. In
manufacturing systems, they help represent production
lines, assembly processes, and robotic coordination by
modeling concurrent machines, buffers, and workflows,
thereby aiding in the identification of bottlenecks and
potential deadlocks. In business process modeling, Petri
nets naturally capture parallel activities—such as
multiple departments concurrently approving forms—and
many business notations like BPMN reflect similar
semantics with constructs like AND-splits and joins.
Applications of Petri Nets
Petri nets are also valuable in modeling distributed systems and
communication protocols, where they represent complex
interactions such as synchronization and mutual exclusion between
processes, enabling formal verification of behaviors like deadlock-
freedom and message ordering. In embedded and control systems,
they are used to model concurrent behaviors—such as coordinating
traffic lights to prevent conflicting green signals—ensuring safe
system operation. Beyond practical applications, Petri nets are
supported by a strong theoretical foundation that allows for formal
analysis of properties like reachability and invariants. This makes
them popular in academia and research, supported by tools like
CPN Tools and PIPE that allow for simulation, visualization, and
analysis of real-world system models.
Design Considerations and
Observations
Finite Automata:
• Great for clear sequential logic and relatively simple concurrent
scenarios. However, modeling many parallel components can lead
to a state explosion (combined state space grows exponentially
with number of concurrent processes).
• Need additional mechanisms to handle true simultaneity (often rely
on interleaving to simulate parallel steps). In practice, often used
with techniques like state hierarchy or parallel regions (statecharts)
to manage complexity​
• Analysis: Finite automata models (especially when composed for
concurrency) can be analyzed via model checking by exploring all
state interleavings, but this can become expensive as concurrency
grows.
Design Considerations and
Observations
• Petri Nets:
• Naturally handle multiple parallel threads of execution.
The model explicitly represents concurrency (multiple tokens)
without enumerating all orderings explicitly.
• Can compactly represent synchronization patterns (like our
AND-join) that might require multiple states in an FSM model.
• Complexity: Large Petri nets can also become complex to
analyze (reachability problems are exponential in general).
However, Petri net theory provides analysis tools (invariants,
reachability graphs, etc.) to tackle this.
• Petri nets assume an asynchronous model; if timing is
important, extensions like Timed Petri Nets or adding clocks
might be needed.
Summary & Key Points
Parallel process modeling is essential for understanding systems with
concurrently executing components – it helps manage complexity and
ensure correctness. We discussed two approaches: Finite Automata and
Petri Nets.

Finite Automata (FSM):

• Model system as one state at a time, transitioning on events.
• Can represent parallel processes by combining multiple FSMs
(considering all combinations of states). This is effective but can become
complex as concurrency grows.
• Good for scenarios where the number of parallel components is small or
interactions are simpler. Often used in sequential logic design and with
extensions (statecharts) for concurrency.
Summary & Key Points
Petri Nets:
• Explicitly designed to handle multiple simultaneous
conditions and events. Tokens in separate places
naturally represent parallel activities.
• Provide a visual and mathematical way to model
concurrency, synchronization (AND-joins), and conflict
(choice) in processes.
• Particularly useful for complex workflows and
distributed systems where multiple things happen at
once.
Summary & Key Points
Our Example Recap: Both FSM and Petri net models
captured the parallel assembly example. The FSM
required enumerating states for each possible progress
scenario, while the Petri net directly showed two tokens
flowing and joining. Each approach arrived at the same
logical requirement: both parts must be done before
assembly.
Summary & Key Points
Takeaway: There’s more than one way to model
concurrency. Finite Automata and Petri Nets each offer
insights – FSMs highlight the sequence of events (good
for step-by-step logic), whereas Petri Nets highlight the
concurrent structure (good for seeing what can happen
independently). A solid understanding of both enriches
your ability to design and reason about parallel
systems.
Further Resources for Learning
Textbooks & Courses:
• “Concurrency: State Models & Java Programs” by Jeff Magee
and Jeff Kramer – introduces modeling concurrency with
state machines (includes FSP language and LTSA tool)​
• “Petri Nets: An Introduction” by Wolfgang Reisig – a classic
introductory text on Petri net theory and applications.
• Online courses or lecture notes on Automata Theory (for
FSM basics) and Concurrent Systems or Distributed
Systems (often cover Petri nets and related models).
Further Resources for Learning
tools:
• LTSA (Labelled Transition System Analyzer): Tool for
modeling and analyzing concurrent finite state process
models (like the FSP examples) – great for experimenting
with parallel FSM composition.
• CPN Tools: A widely-used tool for drawing and simulating
Colored Petri Nets (an advanced form of Petri nets). Lets
you animate token flows and check properties.
• Pipe (Platform Independent Petri net Editor): A simpler
tool for drawing Petri nets (place/transition nets) and
running some analysis (e.g., reachability graphs).
Further Resources for Learning
• Communities and Further Reading:
• Look into research papers by Tadao Murata (his 1989 paper
“Petri Nets: Properties, Analysis and Applications” is a well-
known tutorial​)
• Check out the IEEE Transactions on Systems, Man, and
Cybernetics or conferences on Application of Concurrency to
System Design – they often have case studies using Petri nets
and FSMs.
• For a practical angle, consider exploring how UML State
Machine diagrams (which are essentially FSMs with some
concurrency features) and BPMN (Business Process Model
and Notation) diagrams (which often parallel Petri net ideas)
are used in industry.