Petri Nets and Machines of Things That Flow

Petri nets are an established graphical formalism for modeling and analyzing the behavior of systems. An important consideration of the value of Petri nets is their use in describing both the syntax and semantics of modeling formalisms. Describing a modeling notation in terms of a formal technique such as Petri nets provides a way to minimize ambiguity. Accordingly, it is imperative to develop a deep and diverse understanding of Petri nets. This paper is directed toward a new, but preliminary, exploration of the semantics of such an important tool. Specifically, the concern in this paper is with the semantics of Petri nets interpreted in a modeling language based on the notion of machines of things that flow. The semantics of several Petri net diagrams are analyzed in terms of flow of things. The results point to the viability of the approach for exploring the underlying assumptions of Petri nets.

💡 Research Summary

The paper “Petri Nets and Machines of Things That Flow” investigates the semantics of Petri nets by interpreting them within a modeling language called Machines of Things That Flow (MoT). Petri nets are a well‑established graphical formalism used to capture concurrency, synchronization, and nondeterminism through the movement of tokens among places and transitions. Despite their popularity, the concrete meaning of tokens, places, and transitions often remains abstract, which can lead to ambiguities when Petri nets are used to describe other modeling notations or to serve as a lingua franca between formalisms.

To address this gap, the authors introduce MoT, a conceptual framework that treats system elements as “things” that undergo four primitive operations: creation, transfer, transformation, and destruction. In MoT, a “thing” is any entity that can be generated, moved, altered, or removed; a “machine” is the mechanism that performs these operations. By mapping the three core components of a Petri net onto MoT’s primitives, the authors obtain a systematic correspondence:

• Place → Storage – a location where things reside temporarily.
• Transition → Machine – an active component that applies a transformation or transfer to incoming things.
• Token → Attribute/Information Unit – not the thing itself but a representation of a property or piece of data that travels with the thing.

With this mapping, the firing of a transition is re‑interpreted as a sequence of MoT operations: a machine consumes input attributes (destruction), applies a transformation, and then transfers the resulting attributes to downstream storage locations (creation). This reinterpretation makes explicit the otherwise implicit assumptions of Petri nets, such as atomicity of concurrent events, infinite token availability, and instantaneous transition execution.

The paper proceeds to illustrate the approach with three canonical Petri net patterns:

1. Simple Sequential Flow – A single transition creates a new token, transforms it, and moves it to the next place. In MoT terms, a machine performs a create‑transform‑transfer chain.
2. Parallel Branch‑and‑Join – A branching transition simultaneously initiates multiple transfer operations, modeling parallel execution paths. A subsequent join transition aggregates several incoming flows via a single transformation, highlighting synchronization.
3. Self‑Consuming Loop – A transition that both destroys and recreates tokens, forming a feedback loop. MoT captures this as a cyclic combination of destroy‑create operations, illustrating self‑regulation and steady‑state behavior.

Through these case studies, the authors demonstrate that MoT can serve as a semantic bridge: it translates the graphical syntax of Petri nets into a flow‑centric narrative that is easier to compare with other modeling languages (e.g., BPMN, SysML). Moreover, the explicit representation of creation, transformation, and destruction enables systematic detection of modeling errors, such as unintended token accumulation or missing synchronization points.

The authors acknowledge that their current mapping addresses only basic (ordinary) Petri nets. Extending the approach to colored Petri nets, timed Petri nets, and hybrid systems will require additional MoT constructs (e.g., typed things, temporal constraints). Nevertheless, they argue that the foundational flow‑machine correspondence provides a solid base for such extensions. Future work outlined includes:

• Developing automated tools that convert Petri net diagrams into MoT specifications and vice versa.
• Integrating MoT‑based semantics into simulation and model‑checking pipelines to verify properties like liveness and safety.
• Applying the methodology to real‑world case studies in manufacturing, logistics, and software engineering to assess practical benefits.

In summary, the paper offers a novel perspective on Petri net semantics by grounding them in a concrete flow‑of‑things paradigm. This reinterpretation clarifies hidden assumptions, facilitates cross‑formalism translation, and opens avenues for richer analysis and tool support. While still preliminary, the work establishes a promising foundation for deeper semantic integration of Petri nets with other system modeling approaches.