Petri nets are a powerful graphical formalism that is well-suited for modeling and simulating concurrent systems. However, existing solutions for integrating high-level Petri net models with external systems and physical devices are limited, restricting their applicability for developing cyber-physical systems. This paper presents a middleware implementation that bridges this gap by enabling reference nets, a high-level Petri net class supported by the Renew tool, to interface with physical devices. The proposed middleware implementation facilitates Petri net-driven development, where the graphical net model serves as the core specification driving the system's behavior using a low-code, top-down approach. This approach transforms the traditionally autonomous Petri net model into an event-driven, reactive model capable of bidirectional communication with external physical components. The paper demonstrates the middleware's usage through a case study involving a gate and button as physical devices, exemplifying how their states and events can be seamlessly integrated into the high-level Petri net model's execution semantics. This integration empowers the development of sophisticated cyber-physical systems with Petri nets as the central, formal modeling paradigm.
Model-based engineering leverages low-code platforms that employ precise diagrammatic
models to bridge requirements and automated code generation. The rise of user-friendly,
low-code tools not only eases software development but can accelerate time-to-market by
streamlining the model-driven development lifecycle, allowing developers to focus on core
system logic rather than low-level coding. Petri nets ofer a powerful visual formalism with
precise semantics, supporting key concepts adopted by numerous graphical modeling languages.
Unlike some graphical specification languages, Petri nets’ formal rigor enhances efective
communication, system validation, and automated code generation throughout the development
lifecycle. This aligns with low-code approaches (e.g., [
In this paper, we leverage Reference nets [
The following section surveys relevant related work. Section 3 uses a running example to describe the proposed system’s components and their behavior. Section 4 delves into the example Petri net models, including the implementation of the Observer pattern. Finally, Section 5 concludes the paper and outlines future directions.
Graphical modeling formalisms, such as Petri nets, are often used to design the system, but also
to simulate it, as in the work presented in [
The work [
The work presented in [
Although there have been many studies and projects involving Petri nets, it is rare to come across the use of high-level Petri nets as a foundation for implementing systems using a lowcode, model-driven approach. The use of Petri nets in systems implementation seems mostly restricted to the areas of design and simulation. The following section, presents the use of the developed middleware through an example of a simple cyber-physical system.
As a running example, we considered a prototype for a Cyber-Physical System (CPS) comprising
two physical devices: a gate and a button. The system is loosely based on the one presented by
Jackson [
Each communication between the Physical Device and the net model is supported by two
main components: (1) one implemented in C++ and running on each of the external devices
(Arduinos, in our prototype), and (2) a logical component, developed in Kotlin and reference
nets models, running on the Renew tool. These two components communicate bidirectionally
via the MQTT (Message Queuing Telemetry Transport) protocol, a well-known protocol that
requires minimal resources [
The gate behavior and the interaction between the model and the Physical devices (the gate and button) take place on a reference net named Controller, later presented in Section 4.1. This net models the gate behavior and can be seen as its controller model. It creates instances of Gate nets, presented in Section 4.2, that handle the MQTT messages to and from the physical devices.
The Physical Component is supported by C++ code running on, or directly connected to, a physical device, and has two tasks: (1) receive, read, and execute the actions from the logical component (the reference net); (2) send messages to the logical component allowing its update and state synchronization. The messages are exchanged using the MQTT protocol.
The Logical Component is the software that initiates communication with a physical device. It is written in the Kotlin programming language, chosen for its seamless integration with Java, which the Renew tool uses. The Logical Component also encompasses Petri Nets-based modeling to represent and control the system’s states and transitions.
The MQTT protocol supports the bidirectional communication between each physical device and the Logical Component. MQTT enables the two system parts to communicate efectively and dependably, even in unstable network conditions or with constrained bandwidth.
The MQTT server acts as a communication intermediary between each physical device and the Logical Component. It is hosted in the cloud. It allows the connected devices (in this case, the physical device in an Arduino and the server running the Logical Component) to post messages on specific topics and subscribe to receive messages of interest. This cloud server ofers scalability, availability and security for communication between the system’s components, allowing them to communicate reliably on a global scale.
The Logical Component operates in a computing environment distinct from that of the Physical Component. This means that the Logical Component can be on a device such as a personal computer or a server. At the same time, in our prototype, each Physical Device, is embedded in an Arduino.
Several components need to interact asynchronously and synchronously to allow
communication between each physical device and the logical component. The sequence diagram in Figure
1 shows two message flows between the various elements, with all the elements to the right
of the MQTT Server forming part of the Logical Component. Message sequence 1 to 5 starts
on the Physical Device, while message sequence 6 to 9 start on the Controller net. Note that
messages up to the Communicator element (1 to 3) are asynchronous, as the communication
between the Java MQTTClient class and the Communicator net uses the Observer Pattern [
Physical Device
MQTT Server
MQTT Client
Communicator
Gate Net
Controller 1 : Publish Status 2 : Foward to Client 3 : Trans. to Model 4 : Trans.to Net 5 : Update Status 9 : Receive Command 10 : Publish Command 8 : Publish Command 7 : Publish Command 6 : Publish Command
The observer pattern is implemented using a net as an observer. This net uses synchronization
channels (between transitions) in diferent net instances to synchronously pass the message.
The Renew tool provides a specific tool, called stubs [
In summary, the middleware prototype demonstrates bidirectional communication between an embedded device (Arduino) and a computing environment (PC/server) using MQTT. The Logical Component (based on Kotlin and Petri Nets) reflects Physical Devices’ status and sends commands. The Physical Device’s C++ code executes received commands and provides results to the Logical Component. The cloud MQTT server facilitates message exchange between the components.
In this section, we present the diferent nets that make up the Logical Component. In addition to demonstrating the system state, we also model the interaction between the gate and button devices. The observer pattern implementation is presented in Subsection 4.4.
The net Controller consists of two subnets (see Fig. 2): (1) the one on the left represents what state the gate is in, and (2) the one on the right how a stop button interacts with the model to pause the gate when it is moving: the gate up and down movement is gain modeled, and a virtual place is used to duplicate place In Move. A virtual place is represented by a double circle or ellipse and is a reference to a place, thus allowing multiple occurrences of the same place. On the left, the net state is updated with messages that are sent by physical devices to instances of the net gate, where each instance models a physical gate.
As usual in high-level nets, tokens in Reference nets can have distinct values. The place num
of gates uses that possibility as the token has de initial value 1 and transition create gate
can remove that token, bind it to variable x and create a new token with value x + 1 using
an output arc expression. Additionally, and very significantly, Reference nets implement the
nets-within-nets paradigm [
Like the net Gate, an instance of net Button is also created, represented by variable bt (top right in Fig 2. If there is a g token in the In Move virtual place, the transition button stop is enabled. The stop button sends a message to the gate instance (g:publish("stopMotor")) to make the physical system stop, but only if an "s" message has been received in net Button allowing the bottom transition in Fig. 3 to fire. This is achieved using synchronous channels, a type of transition fusion inspired by method calling in object-oriented programming languages: one side uses the notation netInstance:message() and the other :message(). When transition button stop fires, the g token is placed in place Gate stop. After, the gate movement can continue up or down.
When the net Controller is instantiated, a unique net identifier is obtained ( holonId). This identifier is sent to the created net Gate instance (g: new gate(holonId)), which passes it to the new instance of net Communicator, that is stored in variable hc (:new(id); hc: new communicator(id)) (see top of Fig. 3a). The following transition (in net Gate) subscribes to the "toNet" topic, receiving messages sent by the physical device. This net allows messages to be published to the "toPhysicalSystem" topic, which is subscribed to by the physical counterpart, and to receive messages. Whenever the Communicator net instance, in hc, receives a message (hc:onMessage(message)), the transition fires: the hc token is not consumed, and the message is put in place incoming message to be consumed by one of the following transitions. Guards are used to translate from the text message to the respective transition to be fired, thus establishing synchronous communication between this net and the net where the message is relevant to fire the intended transition.
The net Button is analogous to the net Gate, with the primary distinction being its inability to publish messages. Instead, it only receives a message indicating the intention to stop.
The net Communicator (see Fig. 4a) is responsible for instantiating the Kotlin class MqttClient, responsible for communication via the MQTT protocol and identified as "client", and for creating an instance of net MqttMessageReceiver (see Fig. 4b), identified as "receiver", which is then passed on to the "client".
Whenever the "client" instance receives a message, it is passed to the "receiver" net
instance by a "stub" code built according to the Renew tool requirements [
The listing below shows the stub code used to enable communication between the mqtt_message_receiver network, represented in Figure 4b, and the Kotlin MqttClient class. class MqttMessageReceiver for net mqtt_message_receiver implements pt.nfriacowboy.presib.hermes.communication.IMessageProcessor { break void messageReceived(org.eclipse.paho.mqttv5.common.MqttMessage arg0) { this:incomingMessage(arg0); } }
Although the code is very similar, it is worth noting the line in the class declaration with the reserved word sequence "for net". Renew uses these words to identify which network the stub is applied to. The stub is used by the Java class as if it were another Java class. When it receives a message, the stub’s "message received" method is invoked, and a MqttMessage object is passed. The method MessageReceived contains code that is interpreted by renew: the "this" refers to the net instance defined by the "for net" in the stub’s class declaration followed by the transition that is to be fired, in this case, incomingMessage. The MQTT message is passed from one net instance to the other through synchronous channels between transitions.
The MqttClient class implements the observer pattern [
mqttService.sendMesssage(topic, message) } override fun subscribe(topic: String) { subscribersObservers.getOrPut(topic, ::mutableListOf).add {
result: ReceivedMessage -> this.processor.messageReceived(result.message) } mqttService.subscribe(topic) } override fun messageProcessor(processor: IMessageProcessor) { ... } }
The presented functional example provides a method and software to support the use of a high-level Petri Net model as the central component of a CPS implementation. This provides a low-code approach, where the Petri Net models’ precise semantics is used to define the systems’ behavior and the interaction between the diferent devices. This approach ofers practical benefits, as the nets used for simulation and analyzed for correctness can be directly applied in implementation. In fact, the nets become part of the implementation, which not only reduces development time but also minimizes errors, enhancing the eficiency and reliability of the CPS implementation process.
The use of bidirectional asynchronous communication provides added value as it makes the system reactive and dependent on incoming messages. This makes the net model evolution non-autonomous, as needed for proper synchronization with external devices. Moreover, the proposed approach facilitates the integration of external systems with minimal modifications to the physical components themselves. For instance, it paves the way for seamless integration with artificial intelligence-based systems, which can be leveraged to dynamically condition the execution semantics of the Petri net models. Another future step will be the net model deployment outside the Renew tool, which will allow for autonomous and lighter execution. However, using Java with garbage collection still deserves further testing as it will still be a limitation in critical systems.
This work was financed by Portuguese Agency FCT – Fundação para a Ciência e Tecnologia, in the framework of project UIDB/00066/2020.