⚡ electrical engineering

Modelling and Analysis of Supply Chains using Product Time Petri Nets

This paper proposes a modular Product Time Petri Net (PTPN) framework for modeling and analyzing supply chains, explicitly treating the supply chain manager as a critical mobile resource to evaluate how timing constraints and managerial capacity influence system feasibility, timeouts, and timelocks.

Original authors: Eric Lubat (Université Toulouse, Toulouse, France), Pierre-Emmanuel Hladik (Nantes Université, École Centrale Nantes, CNRS, LS2N, UMR 6004, 44000, Nantes, France), Yoann Mateu, Rémi Sauvère

Published 2026-04-07

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Eric Lubat (Université Toulouse, Toulouse, France), Pierre-Emmanuel Hladik (Nantes Université, École Centrale Nantes, CNRS, LS2N, UMR 6004, 44000, Nantes, France), Yoann Mateu, Rémi Sauvère

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine a massive, high-stakes game of Lego, but instead of building a castle, you are trying to assemble a complex machine (like a smartphone) using parts made by different factories scattered all over the world.

This paper is about how to build a digital simulation of this entire process to see if it will actually work before anyone spends a dime on real materials.

Here is the breakdown of the paper using simple analogies:

1. The Problem: A Chaotic Orchestra

Imagine a supply chain as a giant orchestra. You have:

The Suppliers: The violinists (making parts).
The Factory: The conductor (assembling the final product).
The Manager: The only person who can tune the instruments.

In the real world, if the violinist is late, or if the conductor waits too long to give a cue, the whole song falls apart. The problem is that these "orchestras" are so complex that if you try to draw the whole thing on one piece of paper, it becomes a messy, impossible-to-read scribble.

2. The Solution: The "Modular" Lego Approach

The authors propose a new way to model this system using something called Product Time Petri Nets (PTPNs).

Think of this as Lego blocks.

Instead of drawing one giant, messy picture of the whole orchestra, you build a small, perfect Lego model of just the Violinist.
Then you build a separate model of the Conductor.
Then a separate model of the Manager.

The magic happens when you snap them together. The "snap" is a synchronized label. It's like a handshake: "I am ready to play my note exactly when you are ready." If the timing doesn't match, the blocks don't snap together, and the model breaks. This tells the engineers, "Hey, this plan won't work!"

3. The Star of the Show: The "Mobile Manager"

The most interesting part of this paper is how they treat the Supply Chain Manager.

In many old models, the manager is invisible or just a background rule. In this model, the manager is a physical character in the game.

Imagine the Manager is a mobile referee running from field to field.
The Manager has to run to Supplier A to approve a part.
Then they have to run to Supplier B to approve a modification.
The Catch: The Manager can only be in one place at a time.

If Supplier A and Supplier B both need the Manager's approval at the exact same second, but there is only one Manager, the system freezes. In computer science terms, this is called a Timelock. It's like a traffic jam where two cars try to enter a single-lane bridge at the exact same moment, and neither can move.

4. The Experiment: What Happens When We Push the Buttons?

The authors used a computer program (a "model checker") to run thousands of simulations, acting like a flight simulator for supply chains. They asked "What if?" questions:

What if we add more suppliers?
- Result: If you add 3 suppliers but keep only 1 Manager, the system crashes. The Manager gets overwhelmed, and the "traffic jam" (Timelock) happens.
What if the Manager is slower?
- Result: If the Manager takes too long to approve changes, the whole chain misses its deadline.
What if we stagger the orders?
- Result: This was the "Aha!" moment. Instead of ordering parts from all suppliers at the exact same time, the Factory orders from Supplier A, waits a few days, and then orders from Supplier B.
- Analogy: It's like a restaurant kitchen. If 10 customers order steak at the exact same second, the chef (Manager) burns out. But if the orders come in one by one, the chef can handle them all.

5. The Conclusion: Why This Matters

The paper proves that timing is everything.

Old Way: You just hope the parts arrive on time.
New Way: You use this Lego-block simulation to see exactly when the system will break.

The authors found that simply having enough resources (like managers) isn't enough; you have to schedule them correctly. If you stagger your orders, a single Manager can handle multiple suppliers. If you don't, even a huge team of Managers might get stuck in a deadlock because everyone is trying to do the same thing at the same time.

In a nutshell:
This paper gives supply chain managers a crystal ball. It lets them build a digital twin of their network, introduce "bugs" (like delays or missing managers), and see if the whole thing collapses before they ever ship a single real product. It turns a chaotic, global mess into a set of manageable, snapping Lego blocks.

1. Problem Statement

Supply chains involve geographically distributed manufacturing and assembly sites that must be coordinated under strict timing and resource constraints. Key challenges include:

Coordination Complexity: Managing interactions between subcontractors, main factories, and logistics under Just-In-Time (JIT) constraints.
Resource Contention: Critical shared resources, specifically the Supply Chain Manager, who must physically travel between sites to validate non-conformities or approve modifications.
Timing Sensitivity: Local delays (e.g., production delays, inspection times) can propagate through the network, causing bottlenecks, deadlocks, or missed delivery deadlines.
Modelling Limitations: Existing approaches often rely on monolithic models (e.g., standard Colored Time Petri Nets) that are difficult to analyze, simulate, or reuse when scaling to large, distributed systems. There is a need for a modular framework that supports compositional analysis of synchronized timed systems.

2. Methodology

The authors propose a modular modelling approach based on Product Time Petri Nets (PTPNs).

A. Formal Framework: Product Time Petri Nets (PTPN)

Definition: A PTPN is a composition of multiple Time Petri Nets (TPNs) where transitions are synchronized via shared labels. Unlike standard TPNs where transitions fire individually, PTPNs allow sets of transitions (firing sets) to fire synchronously if they share the same label and do not share input places.
Semantics: The system is modeled as a Time Transition System (TTS). The state space is analyzed using State Class Graphs (SCG), which abstract the infinite state space of timed systems into finite classes defined by linear inequalities (difference constraints).
Composition: The authors use a synchronous product operator ( $\times_L$ ) to compose independent TPNs (Suppliers, Factory, Manager) into a global model without merging transitions, preserving modularity.

B. The Supply Chain Benchmark Model

The system is decomposed into four independent TPN subsystems:

Suppliers: Model the production lifecycle: receiving an order $\to$ inspection (1–7 days) $\to$ production (6–10 days) $\to$ validation. If a modification is needed, they request it from the manager.
Manager: A critical mobile resource. The manager validates pieces or grants modifications. The model includes variables for the number of available managers and the time bound ( $y$ ) required to process a modification.
Factory (BAZ): The central hub that issues supply orders and coordinates the final assembly. It synchronizes with all suppliers and the manager.
End-of-Line: A monitoring net that checks if the entire process completes within a global lead time limit (210 days). It detects Timeouts (exceeding the limit) or Success.

C. Analysis Tools

TWINA: Used to generate the synchronized PTPN model from individual TPN files.
TINA Toolbox & selt: Used for model checking. The authors verify properties using SE-LTL (State-Event Linear Temporal Logic):
- Success: $\Diamond \Box \{success\}$ (Eventually, success holds forever).
- Failure: $dead \lor \Diamond \{timeout\}$ (Deadlock or eventual timeout).

3. Key Contributions

Modular PTPN Benchmark: The first application of Product Time Petri Nets to supply chain coordination, allowing independent modeling of suppliers, managers, and factories that are composed via synchronized labels.
Explicit Manager Modeling: Unlike classical approaches that treat management as a passive constraint, this model explicitly represents the manager as a mobile, shared resource. The manager's availability and travel/validation times are critical variables that directly impact system feasibility.
Identification of Timelocks: The study distinguishes between standard deadlocks and timelocks caused by incompatible timing constraints in synchronized transitions (e.g., a manager cannot validate two suppliers simultaneously because their timing windows do not overlap).
What-If Analysis Framework: The model supports systematic parameter variation (number of suppliers, number of managers, timing bounds) to evaluate coordination policies.

4. Experimental Results

The authors analyzed configurations with 1 to 3 suppliers and varying numbers of managers and timing constraints.

State Space Explosion: As expected, the number of state classes grows exponentially with the number of suppliers (e.g., 18 classes for 1 supplier vs. 2.76 million for 4 suppliers), highlighting the complexity of synchronized timed systems.
Managerial Bottlenecks:
- With 1 Manager and 2+ Suppliers, the system frequently enters a Timelock. This occurs because the manager cannot process simultaneous modification requests within the required time windows, leading to incompatible timing constraints.
- Increasing the number of managers resolves timelocks but introduces Timeouts if the total processing time exceeds the global lead time (210 days).
Impact of Staggering Orders:
- The authors tested a "Staggered Supply Order" strategy where the factory delays orders to different suppliers (e.g., Supplier 1 at $t=0$ , Supplier 2 at $t=50$ ).
- Result: This significantly improved feasibility. A single manager could successfully handle 2 suppliers without timelocks because the modification requests no longer occurred simultaneously.
- Trade-off: While timelocks were eliminated, the delay increased the risk of global Timeouts if the staggered schedule pushed the final delivery beyond the 210-day limit.

5. Significance and Conclusion

Theoretical Contribution: The paper demonstrates that PTPNs are a powerful formalism for analyzing synchronized timed systems, particularly where resource contention and timing compatibility are critical. It validates the use of SCG-based verification for detecting subtle timing deadlocks (timelocks) that standard workflow models might miss.
Practical Implications:
- Resource Allocation: Supply chain managers must balance the number of suppliers against managerial capacity. Simply adding suppliers without adding managers leads to system failure (timelocks).
- Scheduling Policies: The study proves that staggering orders is a viable strategy to reduce resource contention, provided the overall lead time constraints are met.
- Design Support: The modular nature of the model allows engineers to perform "what-if" analyses to optimize supply chain designs before implementation.

Future Work: The authors suggest extending the model to handle multiple product flows, incorporating failure/rework loops, and developing compositional analysis techniques (e.g., partial-order reduction) to mitigate state-space explosion for larger networks.