Adapting parallel DEVS semantics to FMI 3.0 co-simulation using synchronous clocks

Abstract

Simulating cyber-physical systems (CPSs) often requires integrating continuous dynamics, typically described by differential equations, with discrete-event dynamics that represent the behavior of embedded controllers. Version 3.0 of the functional mock-up interface (FMI) standard introduces synchronous clocks and a discrete-event mode, creating new opportunities for the co-simulation of hybrid systems. So far, it has not been demonstrated that these features can faithfully capture the semantics of discrete-event formalisms such as the discrete-event system specification (DEVS) and its extension, parallel DEVS (PDEVS). This leaves open the question of whether FMI 3.0 can effectively support complex hybrid dynamics. This paper addresses this gap by showing how PDEVS models can be exported and coupled as FMI 3.0 functional mock-up units (FMUs) while preserving PDEVS semantics. We first derive requirements that any simulator must satisfy to correctly preserve PDEVS semantics. Based on these requirements, we present a systematic mapping of PDEVS abstract simulator functions to the FMI 3.0 interface with synchronous clocks and present an orchestration algorithm to co-simulate multiple PDEVS FMUs accordingly. The approach is validated using an adaptive cruise control case study, where our FMI-based co-simulation reproduces the results of an established PDEVS simulator. To support reproducibility and further research, we provide an open-source prototype together with the complete validation setup.

1. Introduction

In general, the simulation of cyber-physical systems (CPS) requires simulating both continuous dynamics, which evolve smoothly over time, and discrete-event dynamics, where changes occur instantaneously at specific points in time. The physical part of a CPS is typically described using ordinary differential equations (ODEs) to capture the underlying continuous dynamics. The cyber part, in contrast, is inherently discrete, with controllers, communication protocols, and embedded systems, which operate on clocks and both react to and produce events. The challenge in faithfully simulating CPS lies in coordinating these two fundamentally different domains in a coherent co-simulation framework. Over the years, various formalisms have been proposed. Broadly, these approaches can be classified as discrete-event first, where all subsystems are converted to a discrete-event formalism, and continuous-time first, where all subsystems are expressed in continuous time and discretization merely happens to enable stepwise simulation.

The discrete-event system specification (DEVS) ¹ provides a well-defined methodology to model and simulate systems where state changes are driven by events occurring at discrete points in time. It is particularly effective in scenarios where the interactions between subsystems are naturally described as sequences of events, such as embedded systems and communication protocols. DEVS and its extension, parallel DEVS ² (PDEVS), are widely used for modeling large-scale discrete-event systems. These formalisms not only provide expressive modeling constructs but also specify precise operational semantics. Moreover, many other modeling formalisms can be transformed into DEVS,^3,4 positioning it as a unifying framework to integrate different formalisms. This makes DEVS a natural candidate for modeling the cyber components of CPS and for capturing their interactions with the continuous physical dynamics.

The functional mock-up interface (FMI) standard has become the de facto mechanism for enabling co-simulation across tools. Earlier versions of FMI, however, were designed around a continuous-time first perspective, lacking explicit mechanisms for accurate event detection and localization, which limited interoperability with discrete-event formalisms such as PDEVS. Version 3.0 of FMI introduces new features that open opportunities to address this gap. More specifically, it introduces the concept of synchronous clocks (SCs), which allow subsystems to synchronize on common times, and the discrete-event mode, facilitating the propagation of discrete events interleaved with continuous dynamics. These extensions open the door to faithfully capturing discrete-event behavior within FMI-based co-simulation.

However, while the semantics of SCs have been defined,^5,6 and an orchestration algorithm has been proposed by Hansen et al., ⁷ there has been no work to date demonstrating the ability of FMI 3.0 FMUs to faithfully capture the semantics of discrete-event formalisms, such as PDEVS. This leaves open the question of whether FMI 3.0 can effectively simulate complex hybrid dynamics where discrete-event and continuous subsystems interact.

In this paper, we take a first step toward this goal by focusing on the discrete-event side. Our central question is whether FMI 3.0 can be used to faithfully co-simulate PDEVS models when exported as FMUs. This is nontrivial, as PDEVS not only defines a modeling formalism but also precise operational semantics for how coupled models should interact: how internal and external transitions are scheduled, how simultaneous events are handled, and how outputs are routed between components. When PDEVS models are exported as FMUs, these semantics must be preserved; otherwise, the coupled FMUs would no longer reproduce the behavior defined by the PDEVS formalism.

1.1. Contribution and prior work

Our previous work ⁸ did not extend to coupling multiple DEVS FMUs through the FMI interface. It demonstrated how FMI 3.0 can be used to co-simulate a single DEVS model, encapsulated as an FMU to evaluate the performance of embedded applications, but did not couple multiple DEVS models through FMI. That work leveraged the discrete-event mode and SCs to signal the occurrence of events, but events could not carry other data, as required in large-scale DEVS simulations.

The present work addresses these limitations by demonstrating how PDEVS models can be faithfully exported and coupled as FMI 3.0 FMUs without violating the semantics of PDEVS. Note that in this paper, we adopt PDEVS instead of “classic” DEVS. PDEVS resolves key limitations of DEVS, most importantly the handling of simultaneous events, which is essential in the context of FMI-based co-simulation. The rationale for this choice is discussed in detail in section Challenges in coupling classic DEVS models.

The contributions of this paper are fourfold:

1. We derive a set of requirements that must be satisfied to preserve PDEVS semantics when models are encapsulated as FMUs and coupled through FMI.

2. We present an implementation outline that defines the systematic mapping between PDEVS abstract simulator functions and the FMI 3.0 interface with SCs in a manner that satisfies the requirements.

3. We present an example orchestration algorithm to co-simulate multiple PDEVS FMUs using SCs and discrete-event mode to enable correct event scheduling, communication, and time advancement, further satisfying the requirements.

4. We validate the approach using an example case study, comparing our approach to an established PDEVS simulator. Simulation results confirm that PDEVS semantics are preserved in practice.

To foster reproducibility and further research, we also release an open-source prototype implementation together with the complete validation setup.

1.2. Structure

The remainder of this paper is organized as follows. Section Background first describes the adaptive cruise control case study that we use as a running example and then introduces the necessary background on FMI 3.0 with SCs as well as the DEVS and PDEVS formalisms. Section Related work positions our work in relation to prior research on integrating DEVS with other formalisms, such as FMI. Section Contribution presents our main contribution: the requirements for preserving PDEVS semantics, the mapping to FMI 3.0 functions, and an orchestration algorithm for PDEVS FMUs. In section Results and discussion, we evaluate the correctness of our approach against a PythonPDEVS reference simulation, interpret the results and highlight broader implications. Section Limitations discusses the main limitations of our approach and outlines potential ways to address them. Finally, section Conclusions and future work summarizes the findings and outlines directions for future work.

2. Background

2.1. Running example

To demonstrate the use of FMI SCs and PDEVS, we consider an example of an adaptive cruise control (ACC) system, adapted from an example provided by the MathWorks. ⁹ An ACC system is designed to enhance vehicle safety and comfort by automatically adjusting the vehicle’s speed. Unlike conventional cruise control, which maintains a constant speed set by the driver, an ACC dynamically adapts the ego vehicle’s speed based on traffic conditions by tracking a car in the front (i.e., the lead vehicle). The overall system architecture is shown in Figure 1. To simplify the illustration of our contribution, we consider three variants of the system, shown in the figure: the open-loop scenario is used to illustrate how the event communication is implemented; the closed-loop scenario is used to motivate the use of PDEVS and how it is mapped to FMI, and helps illustrate our design choices for the orchestration of events; finally, the full scenario validates the semantic equivalence between PDEVS and the FMI-based co-simulation.

Figure 1.

Running example of an adaptive cruise controller using SCs. The different clock types are defined in section FMI 3.0—SCs.

The ACC system operates in two primary modes: speed control and distance control. In speed control mode, it maintains a fixed target speed, typically active at higher speeds on highways. In distance control mode, it maintains a safe distance from the lead vehicle and is typically active in congested traffic. A supervisor manages the mode transitions based on the current speed and relative distance to the lead vehicle. The supervisor updates the controller’s speed setpoint, setting it either to the maximum allowed speed or a reduced speed to maintain a safe following distance. The controller then adjusts the acceleration of the ego vehicle accordingly. Further implementation details are provided in section PDEVS models of the running example.

2.1.1. Test scenario

To make the running example more concrete, we define a test scenario. In this scenario, the ego and lead vehicles begin with predefined initial conditions and interact with each other through the ACC system. In the test scenario, the ego vehicle starts out at position $10$ m, velocity $20$ ms^–1, and acceleration ms^–2, while the lead vehicle starts at position $50$ m, velocity $25$ ms^–1, and acceleration $0$ ms^–2. The driver causes the lead vehicle to accelerate and decelerate following a sine wave with amplitude $0.6$ ms^–2and $\omega 0.2$ rads^–1. The ACC system is tasked with maintaining a safe distance of 1.4s *ego_vehicle_speed + 10 m between the two vehicles, with a maximum allowed speed for the ego vehicle of $30$ ms^–1.

Figure 2 presents simulation traces for this scenario. As can be seen, the system maintains the ego vehicle’s speed at $30$ ms^–1 whenever the actual distance between the ego and lead vehicles exceeds the safe distance, such as during the interval from $13$ to $25$ s. However, as the ego vehicle closes in on the lead vehicle, its speed is reduced to maintain a safe distance, as seen between $25$ and $45$ s.

Figure 2.

Traces obtained using PythonPDEVS ¹⁰ for the described test scenario.

2.2. FMI 3.0—SCs

Co-simulation involves integrating multiple simulation tools or models to analyze complex systems collaboratively. ⁴ To facilitate interoperability between different simulation environments, the FMI standard defines a standardized wrapper for models (with their solvers), referred to as the functional mock-up unit (FMU). ¹¹ These FMUs expose a standardized interface, allowing external tools, known as importers, to integrate and interact with them in a tool-agnostic manner.

Earlier FMI versions primarily supported co-simulation of continuous dynamic systems. However, FMI 3.0 introduces significant enhancements, particularly in the domain of discrete-event simulation. A key addition is the concept of SCs, ¹² which enable precise synchronization of events across different FMUs. Here we introduce clocks informally and refer the reader to Gomes et al., ⁵ and Hansen et al. ¹³ for more formal treatments. These features are particularly relevant for integrating DEVS models within FMI-based co-simulations.

2.2.1. Motivation for SCs in co-simulation

To illustrate the need for SCs, consider the ACC system in Figure 1. The ACC system can be modeled as a co-simulation of multiple FMUs, each representing a system component such as the controller, supervisor, driver, ego vehicle, or lead vehicle.

This system includes both continuous and discrete dynamics operating at different rates. The ego and lead vehicles exhibit continuous behavior, whereas the supervisor, controller, and driver operate in a discrete manner. The controller and supervisor execute periodic routines (e.g., every 10 ms), though the supervisor may or may not change the controller’s setpoint at each step. Meanwhile, the driver FMU can change its output at arbitrary times. Clocks are used to synchronize the execution of these routines within the different FMUs, for example, ensuring that the controller and supervisor are always in sync.

To co-simulate the above scenario using FMI without synchronous clocks, where each FMU provides the get, set, and doStep, operations, the orchestration algorithm would follow the simulation loop: ¹⁴

1. Advance simulated time.

2. Determine the next simulated synchronization time. In the above scenario, it could be current simulated time + 10 ms, or the time when the driver FMU is expected to change its output.

3. Synchronize all FMUs to this simulated time by calling their doStep function with the same simulated time step (e.g., 10 ms).

4. Exchange data between FMUs by calling their get and set functions.

5. Repeat steps 1–5 until the target simulated time has been reached.

This orchestration poses challenges in synchronizing routines:

• Predicting driver output changes: The orchestrator must be able to predict when the driver will change its output, which is not always straightforward. Broman et al. ¹⁵ identified this as a key challenge in co-simulation.

• Timing drift due to floating-point arithmetic: The periodic execution of the controller and supervisor FMUs may drift over time due to numerical inaccuracies in floating-point representation. This issue can only be avoided by using integer-based timing, fixed-point arithmetic, or designating a single FMU as the timekeeper for the simulation.

2.2.2. SCs and event mode in FMI 3.0

FMI 3.0 introduces SCs to address these synchronization issues. Another key addition in this version is the introduction of event mode, alongside the traditional step mode. Event mode allows FMUs to explicitly handle discrete events, such as input events, time events, and state changes, without advancing simulation time. This ensures that all discrete changes are resolved before proceeding with time stepping, improving synchronization accuracy. In addition, FMUs can now signal early return from a doStep call, indicating that an event has occurred and must be handled before continuing. These enhancements provide greater flexibility in co-simulation by allowing fine-grained event handling in systems with mixed continuous and discrete behaviors.

Co-simulations with SCs follow a structured execution sequence, incorporating step execution in continuous-time mode (similar to traditional co-simulation), event detection, and event handling phases. Before we describe the orchestration algorithm, we first introduce the different types of clocks defined in FMI 3.0:

Time-based clocks trigger events at specific intervals during a simulation and can be categorized based on their behavior. For instance, periodic clocks trigger at constant intervals, while aperiodic clocks activate based on specific conditions rather than a fixed schedule. For other time-based clock types, we refer the reader to Gomes et al. ⁵

Triggered clocks, in contrast with time-based clocks, are activated by state changes or external conditions, without a predefined interval. These include Input Triggered Clocks, activated by the orchestrator to signal state or input changes, and Output Triggered Clocks, activated internally by an FMU based on its internal logic, signaling events to other FMUs or the orchestrator.

In the ACC example (Figure 1), the controller and supervisor both have input time-based clocks $R$ that are set by the importer, while other clocks are event-triggered. For instance, the controller FMU has an input triggered clock $S$ that is connected to the supervisor’s output event clock with the same name.

2.2.3. Orchestration algorithm for FMI 3.0 SCs

Ravi et al. ¹⁶ address the challenge of orchestrating simulations for FMI SCs and provided the basis for the orchestration algorithm presented in this paper. The proposed orchestration algorithm divides the simulation process into a repetition of co-simulation steps that incrementally advanced the simulated time until it meets the stopping criteria. Each co-simulation step has three phases: step execution (step mode), event detection, and event handling (event mode), detailed next:

1. Step execution (step mode): the same as in traditional co-simulation. Step and synchronize FMU states by invoking the doStep function for all FMUs and exchanging data, and obtain the new simulation time. FMUs can return earlier from the doStep function if they have detected an event. FMUs are set to step mode.

2. Event detection: Compute the set of ticking clocks from time-based clocks, and detect events triggered by state-based conditions or active event clocks (triggered clocks).

3. Event handling (event mode): For all FMUs with active clocks:

4. (b) Resolve events by:

5. (ii) Propagating clock activation values between connected clocks across FMUs.

6. (iii) Exchange relevant data between FMUs in the event mode.

(c) Execute the discrete-event step function for all FMUs in the event mode.

(d) Repeat event handling if necessary.

(e) Return FMUs to Step mode and repeat.

Thanks to the use of synchronous clocks, the event detection and handling is carried out in a controlled manner and the FMU coroutines (which are run when their outputs are queried) are run synchronously, and numerical inaccuracies are circumvented by having a single source of clock ticking authority at all times.

In the following subsection, we first introduce the DEVS formalism as a foundation for modeling discrete-event systems, and then present its extension, PDEVS.

2.3. DEVS

This subsection provides a brief overview of the relevant aspects of the DEVS using a didactic example of a traffic light system. A more extensive discussion regarding the DEVS concepts can be found in the work by Vangheluwe. ¹⁷

The DEVS specification, introduced by Zeigler, ¹ is a framework used to model and simulate systems where events occur at specific moments in time. It organizes system behavior into two levels: atomic models and coupled models.

2.3.1. Atomic DEVS models

Atomic DEVS models are the basic building blocks that describe how a system behaves over time. They describe the behavior of a discrete-event system as a sequence of deterministic transitions between sequential states, including how it reacts to external input (events) and how it generates output (events). ¹⁷ Figure 3 shows an illustration of two such atomic DEVS models, one of a police officer (“Police”), and one of a traffic light (“TrafficLight”).

Figure 3.

Illustration of a traffic system model, modeled using DEVS. ⁸

Formally, an atomic DEVS model can be defined as:

$$\mathrm{atomicDEVS}\equiv 〈S,\mathrm{ta},{\delta }_{\mathrm{int}},X,{\delta }_{\mathrm{ext}},Y,\lambda 〉$$

With:

• $S$ the set of admissible sequential states.

• $\mathrm{ta}:S\to {\mathbb{R}}_{0,+\infty }^{+}$ the time advance function, which models the time the system remains in a certain state, before transitioning to the next sequential state

  Notes: (1) instantaneous transitions can be modeled using $\mathrm{ta}\left(s\right)=0$ , and (2) if the system should remain in a state, this can be modeled using $\mathrm{ta}\left(s\right)=+\infty$ .

• ${\delta }_{\mathrm{int}}:S\to S$ the internal transition function, which models the transition from one state to the next sequential state.

• $X={\times }_{i=1}^m{X}_i$ the set of admissible inputs, formalizing multiple $\left(m\right)$ input ports, each identified by a unique index $i$ (possibly derived from a port name).

• ${\delta }_{\mathrm{ext}}:Q\times X\to S$ the external transition function describing how the system responds to external events, with $Q=\{(s,e)\mid s\in S,0\le e\le \mathrm{ta}\left(s\right)\}$ the total state set, where $e$ is the elapsed time since transitioning to the current state $s$ .

  Note: the time left $\sigma =\mathrm{ta}\left(s\right)-e$ is often used.

• $Y={\times }_{i=1}^l{Y}_i$ the set of admissible outputs, formalizing multiple $\left(l\right)$ output ports, each identified by a unique index $i$ (possibly derived from a port name).

• $\lambda :S\to Y\cup \{\varphi \}$ the output function, which determines which output events are generated at the time of an internal transition.

  Note: (1) the state before the transition is used as input to $\lambda$ , and (2) output events are only generated on internal transitions and not on external ones.

As an example, the atomic DEVS representation of the “TrafficLight” model shown in Figure 3 is given below:

$$\mathrm{TrafficLight}=〈S,\mathrm{ta},{\delta }_{\mathrm{int}},X,{\delta }_{\mathrm{ext}},Y,\lambda 〉$$

$$S=\{\mathrm{green},\mathrm{yellow},\mathrm{red},\mathrm{manual}\}$$

$$\begin{array}{c}\multicolumn{1}{c}{\mathrm{ta}=\left\{\begin{array}{ccc}\mathrm{green}\hfill & \to \hfill & 50s,\hfill \\ \multicolumn{1}{c}{\mathrm{yellow}}& \to \hfill & 10s,\hfill \\ \multicolumn{1}{c}{\mathrm{red}}& \to \hfill & 60s,\hfill \\ \multicolumn{1}{c}{\mathrm{manual}}& \to \hfill & +\infty \hfill \end{array}\right\}}\end{array}$$

$$\begin{array}{c}\multicolumn{1}{c}{{\delta }_{\mathrm{int}}=\left\{\begin{array}{ccc}\mathrm{green}\hfill & \to \hfill & \mathrm{yellow},\hfill \\ \multicolumn{1}{c}{\mathrm{yellow}}& \to \hfill & \mathrm{red},\hfill \\ \multicolumn{1}{c}{\mathrm{red}}& \to \hfill & \mathrm{green}\hfill \end{array}\right\}}\end{array}$$

$$X=X_1=\{\mathrm{toManual},\mathrm{toAuto}\}$$

$${\delta }_{\mathrm{ext}}=\left\{\begin{array}{ccc}(\mathrm{green},e),\mathrm{toManual}\hfill & \to \hfill & \mathrm{manual},\hfill \\ \multicolumn{1}{c}{(\mathrm{yellow},e),\mathrm{toManual}}& \to \hfill & \mathrm{manual},\hfill \\ \multicolumn{1}{c}{(\mathrm{red},e),\mathrm{toManual}}& \to \hfill & \mathrm{manual},\hfill \\ \multicolumn{1}{c}{(\mathrm{manual},e),\mathrm{toAuto}}& \to \hfill & \mathrm{red}\hfill \end{array}\right\}$$

$$Y=Y_1=\{\mathrm{toGreen},\mathrm{toYellow},\mathrm{toRed}\}$$

$$\lambda =\left\{\begin{array}{ccc}\mathrm{green}\hfill & \to \hfill & \mathrm{toYellow},\hfill \\ \multicolumn{1}{c}{\mathrm{yellow}}& \to \hfill & \mathrm{toRed},\hfill \\ \multicolumn{1}{c}{\mathrm{red}}& \to \hfill & \mathrm{toGreen}\hfill \end{array}\right\}$$

The atomic DEVS representation of the “Police” model is omitted here for brevity.

2.3.2. Coupled DEVS models

These models build on atomic models to represent larger systems made up of interconnected components. They describe a system as a network of coupled components (models), with connections between components denoting how they influence each other. More specifically, through a connection, output events of one component can become input events for another (internal coupling). These components can be atomic DEVS models, but also other coupled DEVS models. As such, DEVS allows for a hierarchical modeling approach. ¹⁷ In addition, components can be connected to input/output ports of an encompassing coupled DEVS model (external coupling).

A coupled DEVS model can be defined as follows:

$$\mathrm{coupledDEVS}\equiv 〈X_{\mathrm{self}},Y_{\mathrm{self}},D,\{M_i\},\{I_i\},\{Z_{i,j}\},\mathrm{select}〉$$

With:

• $\mathrm{self}$ denoting the coupled model itself.

• $X_{\mathrm{self}}$ the (possibly structured) set of allowed external inputs to the coupled model.

• $Y_{\mathrm{self}}$ the (possibly structured) set of allowed (external) outputs of the coupled model.

• $D$ a set of unique component references, not including self.

• $\{M_i\}$ the set of components, where each component is an atomic DEVS model referenced by D.

• $\{I_i\}$ the set of influencees, determining the components influenced by a component $i\in D\cup \{\mathrm{self}\}$ , that is, the components whose input ports are connected to output ports of component $i$ .

  Note: a component (1) cannot influence components outside the coupled model, and (2) cannot influence itself directly.

• $\{Z_{i,j}\}$ the set of translation functions, used to translate an output event of one component $i\in D\cup \{\mathrm{self}\}$ to a corresponding input event in an influencee $j\in I_i$ of that component (if necessary).

  Note: if not defined, these are typically implicitly assumed to be the identity function. ¹⁸

• $\mathrm{select}$ the tie-breaking function used to resolve collisions between components, that is, multiple components set to transition at the same time, by selecting exactly one of those components to execute its transition.

Figure 3 shows an illustration of such a coupled DEVS model (“TrafficSystem”), consisting of two atomic DEVS models of a police officer and a traffic light. In autonomous mode, the traffic light automatically transitions between the states “green,”“yellow,” and “red.” When the police officer starts working (transitions to the “working” state), an output event “toManual” is generated, which causes an external transition in the “TrafficLight” model (“?toManual”), transitioning it to a manual mode (“manual”). Similarly, when the police officer stops working, the traffic light is switched back to autonomous mode, starting in the “red” state. The coupled DEVS representation of this “TrafficSystem” model is given below:

$$\begin{array}{cc}\multicolumn{1}{c}{\mathrm{TrafficSystem}}& =〈X_{\mathrm{self}},Y_{\mathrm{self}},D,\{M_i\},\{I_i\},\{Z_{i,j}\},\mathrm{select}〉\hfill \end{array}$$

$$\begin{array}{l}{X}_{self}=\varphi \\ Y_{self}=\{toGreen,toYellow,toRed\}\\ D=\{light,officer\}\\ \left\{M_i\right\}=\left\{\begin{array}{l}{M}_{light}=TrafficLight,\\ M_{officer}=Police\end{array}\right\}\\ \left\{I_i\right\}=\left\{\begin{array}{l}light\to self,\\ officer\to light\end{array}\right\}\\ \left\{Z_{i,j}\right\}=\left\{\begin{array}{l}{Z}_{light,self}=\{\begin{array}{l}toGreen\to toGreen\\ toYellow\to toYellow\\ toRed\to toRed\end{array}\\ Z_{officer,light}=\{\begin{array}{l}toAuto\to toAuto\\ toManual\to toManual\end{array}\end{array}\right\}\\ select=\left\{\begin{array}{ccc}\{\mathrm{light},\mathrm{officer}\}\hfill & \to \hfill & \mathrm{officer},\hfill \\ \multicolumn{1}{c}{\{\mathrm{light}\}}& \to \hfill & \mathrm{light},\hfill \\ \multicolumn{1}{c}{\{\mathrm{officer}\}}& \to \hfill & \mathrm{officer},\hfill \end{array}\right\}\end{array}$$

2.4. Parallel DEVS

PDEVS was presented by Chow and Zeigler ² as a revision of the “classic” DEVS formalism to better support parallelism. Instead of relying on a select function to resolve collisions at the coupled model level, it allows the modeler to explicitly define the collision behavior at the atomic model level using a new confluent transition function ( ${\delta }_{\mathrm{conf}}$ ). Often, the confluent transition function is defined as first invoking the internal transition function, followed by the external transition function. ¹⁹ In addition, the external and confluent transition functions now operate on bags instead of single inputs. Similarly, the output function produces a bag instead of a single event.

Therefore, an atomic PDEVS model can be defined as follows:

$$\mathrm{atomicPDEVS}\equiv 〈S,\mathrm{ta},{\delta }_{\mathrm{int}},X,{\delta }_{\mathrm{ext}},{\delta }_{\mathrm{conf}},Y,\lambda 〉$$

Note the addition of the confluent transition function ( ${\delta }_{\mathrm{conf}}$ ) compared to “classic” DEVS.

And a coupled PDEVS model can be defined as follows:

$$\mathrm{coupledPDEVS}\equiv 〈X_{\mathrm{self}},Y_{\mathrm{self}},D,\{M_i\},\{I_i\},\{Z_{i,j}\}〉$$

Note the removal of the select function compared to “classic” DEVS.

2.4.1. PDEVS abstract simulator

An abstract simulator defines the operational semantics of the formalism. Chow et al. ²⁰ provide the original description of the abstract simulator for PDEVS. A possible implementation of this abstract simulator is given in Algorithms 1–3. For a more extensive description, the reader is referred to the original work.

Algorithm 1: PDEVS atomic model simulator.

Function getOutput(t):  if $t=t_N$ then   $y\leftarrow \lambda \left(s\right)$   return $y$  else  raise error endendFunctionsetInput(x): bag←bag∪{x}endFunctiondoTransition(t): if $t_L\le t<t_N$ and $\mathrm{bag}\ne \varnothing$ then  // External transition   $e\leftarrow t-t_L$    $s\leftarrow {\delta }_{\mathrm{ext}}(s,e,\mathrm{bag})$   bag ←∅   $t_L\leftarrow t$    $t_N\leftarrow t_L+\mathrm{ta}\left(s\right)$  else if $t==t_N$ and $\mathrm{bag}=\varnothing$ then  // Internal transition   $s\leftarrow {\delta }_{\mathrm{int}}\left(s\right)$    $t_L\leftarrow t$    $t_N\leftarrow t_L+\mathrm{ta}\left(s\right)$  else if $t==t_N$ and $\mathrm{bag}\ne \varnothing$ then  // Confluent transition   $s\leftarrow {\delta }_{\mathrm{con}}(s,\mathrm{bag})$   bag←∅   $t_L\leftarrow t$    $t_N\leftarrow t_L+\mathrm{ta}\left(s\right)$  else if $t>t_N$ or $t<t_L$ then  raise error end return $t_N$ end

DEVS: discrete-event system specification; IMM: set of model references for models with imminent transitions; INF: set of model references for influenced models, that is, models with input events.

Algorithm 2: PDEVS coupled model orchestrator.

Function getOutput(t):   if $t==t_N$ then    $t_L\leftarrow t$    yext ←∅   // For each component with an imminent internal    Transition   foreach $i\in D$ with $M_i.t_N==t$ do     $y\leftarrow M_i.\mathrm{getOutput}\left(t\right)$     IMM ←IMM ∪{i}    // Communicate events    foreach $j\in I_i$ do     ifj≠self then      // Internal coupling       $x\leftarrow z_{i,j}\left(y\right)$        $M_j.\mathrm{setInput}\left(x\right)$        $\mathrm{INF}\leftarrow \mathrm{INF}\cup \{j\}$      else      // External coupling      yext←yext∪ $\mathrm{zi},\mathrm{self}(y)$      end    end   end   return $\mathrm{yext}$  else  raise error endendFunctionsetInput(x): bag←bag∪{x}endFunctiondoTransition(t): if $t_L\le t\le t_N$ then  // Forward external inputs  foreach $j\in I_{\mathrm{self}}$ and $x\in \mathrm{bag}$ do    $x\leftarrow z_{\mathrm{self},j}\left(x\right)$     $M_j.\mathrm{setInput}\left(x\right)$     $\mathrm{INF}\leftarrow \mathrm{INF}\cup \{j\}$   end   $\mathrm{bag}\leftarrow \varnothing$   // Do component transitions  foreachi ∈IMM ∪INF do    $M_i.\mathrm{doTransition}\left(t\right)$   end  // Update times   $t_L\leftarrow t$    $t_N\leftarrow \mathrm{minimum}\mathrm{of}\mathrm{components}\mathrm{\text{'}}{t}_N$   IMM←∅  INF←∅  return else  raise error endend

DEVS: discrete-event system specification; IMM: imminent; INF: influenced.

Algorithm 3: PDEVS root orchestrator.

// Advance time to first event $t\leftarrow t_N\mathrm{of}\mathrm{topmost}\_\mathrm{coordinator}$ while not stoppingcondition() do  // Get and exchange output events   $y\leftarrow \mathrm{topmost}\_\mathrm{coordinator}.\mathrm{getOutput}\left(t\right)$   // Do transitions   $t_N\leftarrow \mathrm{topmost}\_\mathrm{coordinator}.\mathrm{doTransition}\left(t\right)$   // Advance time to next event   $t\leftarrow t_N$ end

DEVS: discrete-event system specification.

While Chow et al. described the algorithms in terms of messages being passed between them, highlighting their parallelizability, we instead describe them in terms of (blocking) function calls to more easily relate them to the FMI functions in subsequent discussions.

First, Algorithm 1 presents the simulator for atomic models, while Algorithm 2 presents the orchestrator for coupled models. Note how the functions implemented in the atomic simulator and coupled orchestrator have similar signatures. This allows the simulation to be constructed hierarchically, that is, components of the coupled model can again be coupled models with their own orchestrators. Algorithm 3 presents the root-level orchestrator to run the simulation by interacting with the topmost coupled model’s orchestrator.

The presented algorithms use the following variables:

• $t$ : simulation time

• $t_N$ : simulation time at which the next internal transition will occur

• t_L: simulation time at which the last transition occurred

• $s$ : state of the (atomic) model

• $e$ : simulation time elapsed since the last transition

• $x$ : input event(s)

• $y$ : output event(s)

• y_ext: external output event(s)

• $\mathrm{self}$ : reference to the model itself

• IMM: set of model references for models with imminent transitions

• INF: set of model references for influenced models, that is, models with input events

2.5. Comparison between FMI SCs and (P)DEVS

Previous works^8,13 have highlighted the similarities and differences between the two formalisms. Both FMI SCs and (P)DEVS are designed to handle discrete events in simulation, emphasizing event-based synchronization to ensure consistent interactions across components. While FMI SCs standardizes co-simulation interfaces to integrate diverse models, (P)DEVS focuses on system representation and structured state transitions. Event handling in FMI SCs relies on input and output clocks activated at predefined intervals or by external triggers, whereas (P)DEVS uses internal and external event transitions to manage system state changes. (P)DEVS inherently supports hierarchical modeling through coupled models, whereas FMI SCs enables modular co-simulation by integrating multiple FMUs, though composing FMUs into coupled FMUs requires additional orchestration which has not been done for FMI SCs. FMI SCs is also optimized for real-time and co-simulation scenarios, coordinating events across FMUs through synchronous clocks. While (P)DEVS is grounded in a strict mathematical formalism, FMI SCs lacks formal semantics and instead relies on external orchestration mechanisms.

2.6. PDEVS models of the running example

In the running example of Figure 1, the whole adaptive cruise control scenario can be modeled as a coupled PDEVS model, with the controller, supervisor, drivers, and both vehicles as component models. The vehicles periodically change their state (discretizing their continuous dynamics), generating output events with their updated position ( $x$ ), speed ( $v$ ), and acceleration ( $a$ ). Both vehicles also receive external events with a wanted acceleration, provided by either the controller (for the ego vehicle) or by a driver model (for the lead vehicle). The rest of the system can be similarly modeled, using periodically generated output events to trigger external transitions in components, for example, to update a speed setpoint, wanted acceleration, etc.

An overview of the PDEVS implementation of the ACC example is given below. To keep the main text concise, the formal description of the atomic and coupled PDEVS models is provided in Appendix 1: Formal Specification of the ACC Models, Definitions 1 to 8. The PythonPDEVS implementation of these models is also available on GitHub: https://github.com/Cosys-Lab/2025-SIMULATION-DEVS-FMI3.0

The ACC system can be modeled in PDEVS as a coupled model (Definition 8) composed of the following components:

• Ego Vehicle (Coupled)—Definition 6

Coupled PDEVS model representing the ego vehicle

• ○ Vehicle (Atomic) - Definition 1

• ○ Implements a simple kinematic vehicle model

• ○ Generator (Atomic) - Definition 2

• ○ Used to periodically trigger the kinematic vehicle model to update its state

• Lead Vehicle (Coupled)—Definition 7

Coupled PDEVS model representing the lead vehicle

• ○ Vehicle (Atomic) - Definition 1

• ○ Implements a simple kinematic vehicle model

• ○ Generator (Atomic) - Definition 2

• ○ Used to periodically trigger the vehicle model to update its state

• ○ Sine (Atomic) - Definition 3

• ○ Signal generator (sine wave), represents the driver by periodically updating the wanted acceleration for the vehicle model

• •Controller (Atomic)—Definition 4

Atomic PDEVS model implementing a basic speed controller (cruise control), periodically updates the (wanted) acceleration of the ego car.

• Supervisor (Atomic)—Definition 5

Atomic PDEVS model implementing the “adaptive” aspect of the cruise control model by periodically updating the speed setpoint for the speed controller to either (1) maintain a safe distance to the lead vehicle, or (2) to obey the speed limit.

• Controller Generator (Atomic)—Definition 2

Periodically triggers the controller to update its output (cfr. time-triggered clock in Figure 1).

• Supervisor Generator (Atomic)—Definition 2

Periodically triggers the supervisor to update its output (cfr. time-triggered clock in Figure 1).

Note that the ACC system model is constructed hierarchically, that is, it contains both atomic PDEVS models and other coupled PDEVS models. It’s also these components (Ego Vehicle, Lead Vehicle, Controller, Supervisor, Controller Generator, Supervisor Generator) that are exported as FMUs. As such, this allows us to validate our approach for both types of PDEVS models.

3. Related work

There has been much work on integrating DEVS with other formalisms, such as FMI, to enable coupling these two formalisms. At the foundational level, we highlight the work of Vangheluwe et al. ²¹ where the multiple ways to integrate formalisms are presented, including transformation to a single formalism, semantic adaptation, and co-simulation. Examples of formalism transformation are given in the cited paper, and an example semantic adaptation is given by Mustafiz et al. ²² and with a focus on FMI by Gomes et al. ²³ We focus on the co-simulation approach, where the two formalisms are kept separate, and the co-simulation is orchestrated by an external tool. We classify related works into three categories: (1) integrating FMI into DEVS (wrapping FMUs as DEVS), (2) integrating DEVS into FMI (wrapping DEVS as FMUs), and (3) applications leveraging DEVS–FMI integration.

In terms of wrapping FMU as DEVS models, we highlight the work of Camus et al. ²⁴ where they present a hybrid co-simulation approach where FMUs are wrapped to integrate them with DEVS in the MECSYCO middleware. A case study on a barrel-filling system demonstrates the framework’s capability to manage event synchronization and numerical resolution, ensuring accurate and scalable co-simulation. The work of Quraishi et al. ²⁵ explores co-simulation of hardware described at the register-transfer level (RTL) and software using the FMI standard. A DEVS-FMI interface integrates DEVS-Suite for RTL models and MATLAB for software models, enabling modular co-simulation of hardware-software interactions. The approach is validated using a network-on-chip (NoC) system, demonstrating its ability to simulate hybrid systems efficiently and handle disparate simulation environments. Lin ²⁶ introduces a DEVS-FMI adapter for integrating DEVS-Suite and FMUs, enabling co-simulation of discrete and continuous models. Using a four-variable model framework, the paper evaluates a case study of an electric scooter, demonstrating the adapter’s ability to synchronize cyber and physical systems. The work highlights challenges, such as step size effects, and proposes a hybrid co-simulation strategy for CPS design and validation. In addition, the paper by Joshi et al. ²⁷ introduces a method to integrate FMUs into the DEVS-based cadmium simulator by wrapping FMUs as DEVS atomic models. The integration leverages a quantized state system (QSS) solver to simulate continuous-time behavior efficiently, replacing traditional time discretization with state quantization.

With a focus on integrating DEVS models within FMI, we previously introduced a co-simulation framework for evaluating multicore embedded platforms in cyber-physical systems. ²⁸ This previous approach integrates DEVS models of multicore platforms with plant and application models using the FMI standard to enable early design-stage evaluations of temporal and functional behavior. However, this previous approach made use of version 2.0 of FMI, which lacked support for discrete-event simulation. To work around these limitations, the previous approach required the DEVS models to be included as part of the FMI orchestration algorithm itself, rather than as FMUs. Therefore, the orchestration algorithm was not generic. More recently, we presented an approach using FMI 3.0. This approach makes use of, among others, the event mode and synchronous clocks introduced in FMI 3.0 to wrap DEVS models in FMUs and to co-simulate them with plant and application models. However, this previous work did not explicitly support the co-simulation of multiple DEVS FMUs. The feasibility of coupling multiple DEVS models through FMI without breaking the DEVS formalism remained an open question, now answered in the current manuscript.

For applications, we highlight Paris et al., ²⁹ where the authors propose a component-based approach to DEVS for enhancing reuse and integration in complex system modeling and simulation. The authors draw parallels with FMI’s success for equation-based models and advocate for a DEVS-based standard to facilitate modularity and co-simulation. Using the MECSYCO middleware as an example, the paper illustrates how DEVS can bridge heterogeneous simulation tools, enabling multiparadigm modeling and co-simulation.

Compared to previous works, we address the limitation of the approach presented in Vanommeslaeghe et al. ⁸ to demonstrate that FMI 3.0 FMUs can faithfully reproduce PDEVS semantics and that clocked partitions enable the transport of event data in FMI 3.0, ensuring that coupling PDEVS models through FMI does not violate the PDEVS formalism. In this regard, we are the first to relate FMI SCs to PDEVS. Key considerations to adapt PDEVS models for FMI 3.0’s interface include the development of mechanisms for signaling events, managing input/output communications, and synchronizing clocks. These are detailed in the next section.

4. Contribution

To enable the integration of PDEVS models in FMUs and their coupling through FMI, we need to make semantic adaptations between PDEVS and FMI. These adaptations require addressing several key aspects, including handling internal transitions, communicating input and output events, and ensuring that PDEVS models encapsulated in different FMUs can be coupled without violating the PDEVS formalism.

First, in section Requirements, we define the general requirements that a simulator must satisfy to correctly simulate PPDEVS models. These requirements establish the foundation for ensuring accurate and consistent behavior when integrating PDEVS models within FMI and serve as the basis for our approach.

Then, we detail our approach to adapting the semantics of PDEVS to FMI. Specifically, we focus on three main aspects. We describe how the FMI importer can be made aware of internal transitions in PDEVS models, how input and output events can be communicated using the standard FMI interface, and how PDEVS models encapsulated in separate FMUs can be coupled while preserving the PDEVS formalism.

The following subsections elaborate on these aspects and provide the motivations and considerations behind our chosen approach and its relation to the predefined requirements. Sections Signaling imminent internal transitions and Communicating input/output events provide a static view of the first two aspects, while coupling DEVS FMUs presents a dynamic view of the last.

4.1. Requirements

Based on the abstract simulator (Algorithms 1–3), we identify requirements that a simulator must meet—including the overall flow it must follow—to correctly simulate PDEVS models. The simulator:

• R0: Must advance the simulation time $t$ to the next event time $t_N$ , meaning it:

• R0.b: Must obtain the next event time $t_N$ based on the components’ $t_N$

R1: Must generate outputs $y$ for each component with an imminent internal transition (each model $m\in \{M_i\}$ with $m.t_N==t$ ), meaning it:

R1.a: Must know when the next internal transition should happen for each component ( $m.t_N$ )

R1.b: Must trigger a call to the getOutput(…) function of a component to generate (bags of) outputs $y$ for said component

R2: Must communicate events between component models, based on their coupling ( $\{I_i\}$ ), meaning it:

R2.a: Must get (bags of) outputs $y$ from a component

R2.b: Must set (bags of) inputs $x$ for a component

R2.c: Must respect the coupling defined in $\{I_i\}$

R3: Must tell components to execute their transitions, triggering a call to the doTransition(…) function

R4: Must preserve the overall flow imposed by the abstract simulator, specifically:

R4.a: The getOuput(…) function must be called before the outputs $y$ are collected

R4.b: Outputs $y$ must be collected before they are communicated, that is, before inputs $x$ are set

R4.c: All events must be communicated before components’ transitions (doTransition(…)) are executed to ensure the correct transition function (internal, external, or confluent) is executed

Regarding the mapping to FMI, these requirements determine (1) the overall flow an FMI orchestration algorithm must follow, and (2) the functions that need to be implemented in PDEVS FMUs, to ensure a correct coupling of PDEVS models through FMI. Overall, the FMI orchestration algorithm must impose the same flow as Algorithms 2 and 3 to ensure it satisfies requirement R4, while the FMUs must expose the functionality of Algorithm 1 (or Algorithm 2 if they contain a coupled model) through standard FMI functions to enable this.

4.2. Signaling imminent internal transitions

To ensure proper event handling, an FMI importer must transition the relevant FMUs into event mode when necessary. This requires the importer to be aware of, and keep track of, imminent events. In the context of PDEVS models, these imminent events correspond to imminent internal transitions. As such, this aligns with requirements R1.a and by extension R0.b.

To signal these imminent internal transitions, we use a subtype of FMI 3.0 time-based clock called the countdown aperiodic clock. More concretely, for our PDEVS FMUs, we define a countdown aperiodic input clock “ta” (“time advance”), whose period is equal to the time until the next internal transition ( $\sigma$ ). Therefore, a call to $\mathrm{fmi}3\mathrm{GetInterval}$ for this clock allows the importer to query a PDEVS FMU for the time until the next internal transition, thereby obtaining the next event time $t_N$ and satisfying R1.a. As the FMI importer is responsible for keeping track of when any input clocks should tick, this also allows it to satisfy R0.b. Listing 1, Line 2 shows how this “ta” clock is defined in an excerpt from a modelDescription.xml file from a PDEVS FMU.

Listing 1.

Definition of the aperiodic countdown clock and input/output clocks with associated clocked variables for the lead vehicle model.

1 <ModelVariables>2 <Float64 name = “time” valueReference = “999” causality = “independent” variability = “continuous” description = “Simulation time”/>3 <Clock name = “ta” valueReference = “1001” causality = “input” intervalVariability = “countdown”/>4 <String name = “state” valueReference = “1” causality = “output” variability = “discrete”/>5 <Clock name = “update_a_wanted” valueReference = “1002” causality = “input” intervalVariability = “triggered”/>6 <String name = “update_a_wanted_data” valueReference = “2” causality = “input” variability = “discrete” clocks = “1002”>7 <Dimension start = “1”/>8 <Start value = “”/>9 </String>10 <Clock name = “vehicle_state” valueReference = “1003” causality = “output” clocks = “1001” intervalVariability = “triggered”/>11 <String name = “vehicle_state_data” valueReference = “3” causality = “output” variability = “discrete” clocks = “1003”/>12 </ModelVariables>13 <ModelStructure>14 <Output valueReference = “1003” dependencies = “1001”/>15 </ModelStructure>

In addition, the importer is responsible for instructing the relevant clocks to tick at the right point(s) in time. As later described in section Implementation outline, triggering a call to getOutput(…) on activation of this “ta” clock also allows us to satisfy R1.b.

Rationale: An alternative mechanism provided in FMI 3.0 that could be used to signal imminent internal transitions is the ability for an FMU to signal the early return from an fmi3DoStep call. When the importer calls the fmi3DoStep function, we can check if the requested step size is greater than the remaining time until the next internal transition in the PDEVS model ( $\sigma$ ). If this is the case, we could advance the internal time up to the point of the internal transition, and signal the early return and need for event handling to the importer using the relevant return values.

However, there are some major drawbacks to that approach. First, the importer needs to explicitly support early return. As such, relying on this mechanism would likely limit in which tools these PDEVS FMUs could be used. Second, in the case the importer does support early return, an FMU signaling such an early return might mean that the importer needs to roll back the state of other FMUs which did fully advance their internal time, such that they may be advanced instead to the lastSuccessfulTime of the signaling FMU. In addition, this is an optional feature that needs to be explicitly supported by the FMUs. In our experience, most FMUs do not support this feature, as it is not mandatory. As such, this would likely severely limit the co-simulation setups in which these PDEVS FMUs could be used. In addition, relying on this mechanism makes it difficult to satisfy requirements R0.b and R1.a, as the importer does not know a priori when an event will occur.

To avoid the mentioned drawbacks of relying on the early return mechanism, we opt for the countdown aperiodic clock instead. As it is basic required functionality for an FMI 3.0 compatible importer (1) to keep track of when input clocks should tick and (2) to move the FMUs into event mode and to instruct the relevant clocks to tick at the right point(s) in time, we believe that relying on this mechanism for the PDEVS FMUs makes it more likely for them to be usable in different (co)simulation tools and scenarios.

4.3. Communicating input/output events

As mentioned in section DEVS, (P)DEVS models can generate output events on internal transitions, and can transition between states in response to input events (external transitions). To enable the coupling of PDEVS FMUs through FMI, we need to be able to communicate the occurrence of these events using some interface defined in the FMI standard (R2).

Version 3.0 of the FMI standard introduces clocked variables, which are discrete variables explicitly tied to the activation of one or more clocks. These variables are subject to access restrictions to ensure synchronization with their associated clocks. Specifically, clocked variables can only be accessed when one of the referenced clocks is active. This ensures that the variables are updated and accessed in sync with their associated clocks.

In the current work, we adopt this concept of clocks and clocked variables to model input/output ports of PDEVS models. For each input/output port of a PDEVS model, we define both a triggered input/output clock and an associated clocked variable. Conceptually, the clocks indicate the occurrence of events on a specific port, while the clocked variables are used to carry the associated data (i.e., the actual event) for each port, updated strictly when their corresponding clock signals an event. This concept is illustrated in Figure 4. As further detailed in section Implementation outline, these clocks and clocked variables allow the FMI importer to get outputs and set inputs using standard FMI functions, satisfying R2.a and R2.b, respectively.

Figure 4.

Conceptual illustration of the open-loop variant represented using PDEVS FMUs.

In addition, as outputs may be generated on imminent internal transitions, as signaled using the “ta”clock, we define a dependency between each triggered output clock and the “ta”clock. This serves to satisfy R4.a.

An example of this can be seen in Listing 1, which shows an excerpt of the model description for the ego vehicle model. The PDEVS model of the ego vehicle (Definition 6) has an input port “update_a_wanted” and an output port “vehicle_state.” As such, the listing shows a triggered input clock “update_a_wanted” (line 3), and a triggered output clock “vehicle_state” (line 8). It also shows two clocked variables, “update_a_wanted_data” and “vehicle_state_data” (lines 4, 9), with a “clocks” attribute linking them to their associated clocks. These values are computed and queried, while their corresponding clocks are active. (Recall Section Orchestration Algorithm for FMI 3.0 Synchronous Clocks.) In addition, Line 14 shows the dependency between the output clock “vehicle_state,” and the “ta” clock.

Note that in our current implementation of the presented approach, events are serialized to base64 encoded strings to provide a generic implementation that is independent of the types of events being exchanged. Hence, the shown clocked variables are of type “String.” However, other data types might be used depending on the specific implementation.

Rationale: This approach addresses limitations of our previous work, ⁸ where we relied solely on triggered input/output clocks to communicate events. More explicitly, in that earlier approach, we defined a triggered input clock for each admissible input event in $X$ and a triggered output clock for each admissible output event in $Y$ (rather than for each port). Then, we defined mappings associating each input/output clock (using their value reference) to specific events in $X$ and $Y$ , respectively. While this approach was shown to be sufficient for the use cases presented in the previous paper, including the traffic system example also shown in Figure 3, it does not scale to more complex (P)DEVS models. Defining input/output clocks for each $x\in X$ and $y\in Y$ is feasible only when the sets are small. However, when events contain data, for example, the wanted acceleration output by the controller in the adaptive cruise control example, this previous approach becomes unusable. As such, in the current work, we propose an alternative approach using both clocks and clocked variables.

4.4. Coupling DEVS FMUs

In previous work, ⁸ we showed how we could use a single DEVS FMU to trigger other (non-DEVS) FMUs to simulate the behavior of a cyber-physical system. However, one major question that remained unanswered was whether multiple DEVS FMUs could be co-simulated (coupled) using FMI without violating the DEVS formalism. In this section, we address this question.

First, we describe the difficulties of coupling “classic” DEVS models, as used in our previous work, ⁸ using FMI, and motivate a switch to PDEVS in the current work. Then, we outline an approach to integrate PDEVS in FMUs which satisfies the requirements defined in section Requirements. Finally, we present an example orchestration algorithm, based on one proposed by Ravi et al., ¹⁶ which further satisfied these requirements.

4.4.1. Challenges in coupling classic DEVS models

One major point of attention in coupling DEVS models in general is that due to the coupling of multiple concurrent components (models), multiple state transitions can happen at the same point in time. In sequential simulation systems, such transition collisions are resolved by means of some form of selection of which of the components’ transitions should be handled first. This corresponds to the introduction of priorities in some simulation languages. ¹⁷

In classic DEVS, coupled models explicitly include a select function for tie-breaking between simultaneous transitions. This function is used by the DEVS solver to select one component from a set of components with simultaneous transitions, essentially prioritizing certain components over others and serializing the solving of the coupled model. As such, to couple DEVS models through FMI, we must be able to similarly prioritize the different FMUs containing the component DEVS models to ensure the FMI co-simulation exhibits the same behavior as a pure DEVS simulation. However, as this select function is defined at the level of the coupled model, and the coupling is to be performed by the FMI importer, this complicates the implementation as the importer must somehow preserve the functionality of the select function.

Given these challenges, a more effective approach is to adopt PDEVS. PDEVS eliminates the need for a select function by introducing explicit mechanisms for handling concurrent transitions. Instead of requiring an external entity to impose a priority order, PDEVS allows components to execute transitions in parallel while ensuring deterministic behavior through well-defined confluent transition functions. As these confluent transitions are defined at the atomic model level, this significantly simplifies the integration of PDEVS model in FMUs and their coupling through FMI while preserving the intended behavior of the PDEVS formalism.

Rationale: As mentioned, in “classic” DEVS, coupled models incorporate a select function to resolve simultaneous transitions. This function determines which component takes priority when multiple transitions occur at the same time, effectively serializing the solving of the coupled model. Therefore, to correctly couple DEVS models through FMI, the simulation must allow for similar prioritization of FMUs containing individual DEVS components. This to ensure that the co-simulation behaves consistently with a pure DEVS simulation.

For simple cases in which there are no loops, such as the traffic system (Figure 3), or indeed the open-loop scenario in Figure 1, it might be possible to ensure a specific ordering of FMUs by strategically defining dependencies between different input/output clocks or clocked variables. However, this assumes (1) that the priorities match the flow of data/events and (2) that the priorities do not change. As such, this approach would be severely limited compared to the expressiveness offered by the select function.

In any case, for more complex cases, such as the closed-loop scenario in Figure 1, a different approach is needed. One option here would be to include the select function, or a version thereof, as part of the orchestration itself. However, this approach has drawbacks. First, it results in a DEVS-specific orchestration algorithm. Not only that, as the select function can be specific to a given coupling, this can even result in a simulation-specific orchestration algorithm. As such, such an approach would severely limit the possibility of using DEVS FMUs in different co-simulation setups.

Another option could be to wrap the select function itself as a separate “coordinating” FMU, which could then coordinate the component DEVS FMUs using triggered clocks. However, this approach also has its drawbacks. The coordinating FMU would generally require certain information from the different DEVS FMUs, including their current state, time remaining, etc. This concept is illustrated in Figure 5. This information would need to be communicated using FMI, which would complicate the cosimulation setup. Moreover, as the select function can be specific to a given coupling, modifications to the coupled model or the select function would likely require the coordinating FMU to be re-generated and could require extensive modifications to the co-simulation setup (connections), for example, when different component models are added or removed.

Figure 5.

Illustration of the coordinating FMU concept for “classic” DEVS.

To avoid these drawbacks, we instead propose to switch to PDEVS over classic DEVS. PDEVS does away with the select function and introduces other changes to the DEVS formalism to explicitly handle the occurrence of concurrent events/transitions.

4.4.2. Implementation outline

The following outlines an implementation of “PDEVS FMUs” and their coupling using standard FMI 3.0 functions satisfying the requirements defined in section Requirements, with relevant parts also represented in a sequence diagram (Figure 6):

• R0: Advance the simulation time to the next event time

• FMU: on a call to fmi3DoStep(…): advance the local simulation time, as well as the elapsed time (e) in the PDEVS model

R0.b: Obtain the next event time

Importer: keep track of the time when “ta” clocks are supposed to tick, selection of the next event time is handled in the orchestration algorithm, as detailed in section Orchestration algorithm.

R1: Generate outputs for each component with an imminent internal transition (see also section Signaling imminent internal transitions)

R1.a: Know when internal transitions should happen

Importer: use fmi3GetIntervalDecimal(…) for the ta clock to find when it should tick next

FMU: on a call to fmi3GetIntervalDecimal(…) for the “ta” clock, return the time remaining ( $\sigma$ ) from the PDEVS model

R1.b: Trigger a call to the getOutput(…) function

Importer: use fmi3SetClock(…) to activate the “ta” clock

FMU: on a call to fmi3SetClock(…) to activate the ta clock, call the getOutput(…) function for the PDEVS model and store outputs $y$

R2: Communicate events between models (see also section Communicating input/output events)

R2.a: Get (bags of) output(s)

Importer: use fmi3GetClock(…) to get the activation state of triggered output clocks

FMU: on a call to fmi3GetClock(…), return fmi3ClockActive if there are stored events for the associated output port of the PDEVS model, else return fmi3ClockInactive

Importer: if fmi3GetClock(…) returned fmi3ClockActive, use fmi3GetString(…) on the associated clocked variable to get (serialized) events (this information is in the model description)

FMU: on a call to fmi3GetString(…), return the (serialized) stored events for the associated output port of the PDEVS model

R2.b: Set (bags of) input(s)

Importer: use fmi3SetClock(…) to activate triggered input clocks connected to an active output clock (from R2.a)

FMU: on a call to fmi3SetClock(…), store the activation state of the clock

Importer: use fmi3SetString(…) on the associated clocked variable to set the (serialized) events obtained from the connected output port (from R2.a)

FMU: on a call to fmi3SetString(…), deserialize the events for the associated input port of the PDEVS model and store them, cfr. bag in setInput(…)

R2.c: Respect the coupling

Importer: connections between FMUs are defined using external relations, these are used by the orchestration algorithm when communicating outputs to inputs

R3: Tell models to execute their transitions

Importer: use fmi3UpdateDiscreteStates(…) to signal a converged solution at the current super-dense time instant (this function must be called at least once per super-dense time instant as per the FMI standard)

FMU: on a call to fmi3UpdateDiscreteStates(…), call doTransition(…) to execute the relevant state transition function(s) in the PDEVS model

R4: Preserve the overall flow

Importer: the orchestration algorithm satisfies this requirement and its subrequirements, as detailed in section Orchestration algorithm.

Figure 6.

Sequence diagram of the implementation outline.

Note: (1) the PDEVS model inside the FMU as mentioned can be either an atomic or coupled model, and (2) certain checks, for example, checking that a clocked variable being set has at least one active associated clock, have been omitted from the steps above for clarity.

4.4.3. Orchestration algorithm

Algorithm 4 shows an example algorithm to orchestrate the co-simulation of DEVS FMUs. Note that while this orchestration algorithm is somewhat simplified for this use case, that is, it contains the bare minimum handling for the continuous-time part, it contains no special “PDEVS-specific” constructs, that is, the discrete-event handling is as generic as possible. Indeed, our orchestration algorithm is based on the one presented by Ravi et al. ¹⁶ and overall matches their version closely.

Algorithm 4: Example FMI orchestration algorithm.

1 Function runUntil(stop_time): 2 $\mathrm{time}\leftarrow 0$ 3  $t\_\mathrm{next}\leftarrow \mathrm{getEarliestTickTime}$ () // R0.b4 while $t\_\mathrm{next}\le$ stop_time do5   $\mathrm{step}\_\mathrm{size}\leftarrow t\_\mathrm{next}-\mathrm{time}$ 6  foreach $\mathrm{fmu}\in \mathrm{fmus}$ do// R0.a7    fmu.enterStepMode()8    fmu.doStep(time, step_size, True)9  end10   $\mathrm{time}\leftarrow t\_\mathrm{next}$ 11  foreach $\mathrm{fmu}\in \mathrm{fmus}$ do12   fmu.enterEventMode()13  end14   $\mathrm{it}\leftarrow 0$ 15   $\mathrm{eventHandlingNeeded}\leftarrow \mathrm{True}$ 16  whileeventHandlingNeeded do17    $\mathrm{clocksNeedingActivation}\leftarrow \{\mathrm{clock}\in \mathrm{time}\_\mathrm{based}\_\mathrm{clocks}\mid \mathrm{clock}.\mathrm{nextTickTime}=\mathrm{time}\}$ // R118   if $\mathrm{clocksNeedingActivation}==\varnothing$ then19    eventHandlingNeeded ← False20    break21   end22   while $\mathrm{clocksNeedingActivation}\ne \varnothing$ do23    activeInputClocks $\leftarrow \varnothing$ 24    activeOutputClocks $\leftarrow \varnothing$ 25    foreach $\mathrm{clock}\in \mathrm{clocksNeedingActivation}$ do26     clock.activateClock() // R1.b for “ta”, R2.b for inputs27     activeInputClocks ← activeInputClocks ∪ clock28    end29    clocksNeedingActivation $\leftarrow \varnothing$ 30    foreach $\mathrm{inClock}\in \mathrm{activeInputClocks}$ do31     foreachinPort ∈ dataPorts where inClock ∈ inPort.clocks do// clocked inputs32      outPort ← getConnectedOutput(inPort) // R2.c33      inPort.setValue(outPort.value) // R2.b34     end35     foreachoutClock ∈ inClock.internalRelations where 36       outClock.getState() == active do// activated output clocks, R4.a37      activeOutputClocks ← activeOutputClocks ∪ outClock // R2.a38     end39    end40    foreach $\mathrm{outClock}\in \mathrm{activeOutputClocks}$ do41     foreachoutPort ∈ dataPorts where outClock ∈ outPort.clocks do// clocked outputs42      outPort.value ← outPort.getValue() // R2.a43     end44     foreachinClock ∈ outClock.externalRelations do// connected input clocks, R2.c45      clocksNeedingActivation.append(inClock)46     end47    end48     $\mathrm{it}\leftarrow \mathrm{it}+1$ 49   end50   foreachfmu in fmus do51    fmu.updateDiscreteStates() // R3, R4.c52   end53   foreachclock in time_based_clocks do54    clock.updateNextTickTime(time) // R1.a55   end56  end57   $t\_\mathrm{next}\leftarrow \mathrm{getEarliestTickTime}()$ // R0.b58 end59 end

FMI: functional mock-up interface.

The relations of different parts of the orchestration algorithm to the requirements are mostly indicated using comments in the pseudocode. Some important parts not fully covered in the outline (section Implementation outline) are as follows:

• R0.b: Must be able to obtain the next event time $t_N$ based on the components’ $t_N$

R2.c: Must respect the coupling defined in $I_i$

As previously mentioned, connections between FMUs are defined using external relations, which are used by the orchestration algorithm when communicating outputs to inputs. This can be seen in the orchestration algorithm on Lines 32, where getConnectedOutput(…) resolves the external coupling for a specific input port to a specific output port. Then, on Line 33, this is used to set the input value based on the connected output value. In addition, on Lines 44-46, the external relations are used to communicate the occurrence of events from output clocks to connected input clocks. However, one limitation of the FMI standard in this regard is that external relations can only be “one-to-many,” while PDEVS supports a “many-to-many” coupling. As such, these external relations only partly satisfy R2.c.

In general, the orchestration algorithm must preserve the overall flow imposed by the abstract simulator (R4). More specifically:

• R4.a: The getOuput(…) function must be called before the outputs $y$ are collected

R4.b: Outputs y must be collected before they are communicated, that is, before inputs x are set

This requirement is satisfied by the external relations between output clocks and input clocks, as well as the dependencies between clocks and clocked variables as described in section Communicating input/output events. On one iteration of the event handling, the orchestration algorithm uses the output clocks to determine the occurrence of events (Lines 35-38). Then, for active output clocks, it stores the value of the associated clocked output variables (Lines 41-43) and flags connected input clocks for activation (Lines 44-46). Then, in the next iteration, connected input clocks are activated (Lines 25-28) and their associated clocked input variables are set (Lines 31-34). As such, this ensures output are collected before connected inputs are set, satisfying R4.b.

R4.c: All events must be communicated before components’ transitions (doTransition(…)) are executed…

As described in section Implementation outline, we use the function fmi3UpdateDiscreteStates(…) to trigger a call to the doTransition(…) function. As per the FMI 3.0 standard, this function is called to signal a converged solution at the current super-dense time instant. Therefore, this function gets called when there are no more clocks needing activation, that is, no more events to communicate, as can be seen on Lines 50-52. As such, this satisfies requirement R4.c.

5. Results and discussion

A prototype implementation was made to validate the presented approach using the adaptive cruise control use case presented in section Running example. First, section Implementation details our implementation. After this, in Validation, we present the results of our validation efforts. Our prototype implementation and all code required to reproduce the presented results are available on GitHub: https://github.com/Cosys-Lab/2025-SIMULATION-DEVS-FMI3.0

5.1. Implementation

Figure 7 shows an overview of our implementation. The different parts are detailed below. From left to right:

Figure 7.

Overview of the implementation.

5.1.1. Importer

We implemented an example FMI importer to demonstrate the presented approach. It provides functionality for importing FMUs and defining external relationships (connections) between ports of those FMUs, provides logging capabilities, and implements the presented Overview of the implementation. (Algorithm 4) to run the co-simulation. Hence, it implements the “Importer” part of the steps outlined in paragraph Implementation Outline. The importer is implemented in Python, making use of the FMPy library ³⁰ to interact with the FMUs.

5.1.2. PDEVS FMU

The PDEVS FMUs were largely implemented in Python by using UniFMU ³¹ and its Python backend. UniFMU is a tool that facilitates the implementation of FMI-compatible FMUs in programming languages that cannot (easily) produce C-compatible binaries. It achieves this by providing generic binaries that implement the standard FMI functions. These binaries can forward the FMI function calls to several supported language-specific backends, where the user can implement their required functionality. Overall, the FMUs consist of three main parts: an FMI wrapper, a PDEVS wrapper, and the PDEVS model itself.

5.1.3. FMI wrapper

The FMI wrapper is implemented in the UniFMU Python backend. It provides the translation between the standard FMI functions (fmi3…(…)) and the functions used to interact with the PDEVS models (getOutput(…), setInput(…), doTransition(…)), including the serialization and deserialization of events. Therefore, it implements the “FMU” part of the steps outlined in paragraph Implementation Outline.

5.1.4. PDEVS wrapper

The PDEVS wrapper (Python) implements the functions used to interact with the PDEVS models. Depending on the type of the PDEVS model being wrapped, that is, atomic or coupled, it acts as, respectively, a simulator (Algorithm 1) or an orchestrator (Algorithm 2). This enables a more generic implementation of the PFMI wrapper that can handle both atomic and coupled models.

In the case of a coupled model being wrapped, the model hierarchy is first flattened using the direct connection technique. ³² This technique transforms any hierarchically constructed coupled model into an equivalent flat coupled model with only directly connected atomic models, without changing the behavior of the coupled model. This is not strictly necessary, but simplifies the implementation as it negates the need to implement a full hierarchical simulator in the PDEVS wrapper. In our implementation, this step is carried out using the implementation of this technique provided by PythonPDEVS. ¹⁰

5.1.5. PDEVS model

This is the PDEVS model being wrapped. As such, this constitutes the “PDEVS model” part of the steps outlined in section Implementation outline. The PDEVS models are implemented in Python using PythonPDEVS ¹⁰ and are included in the FMU without modification.

5.1.6. Exporter

To automate the process of creating the FMUs from PDEVS models, we implemented a prototype exporter. The exporter is implemented in Python and allows PythonPDEVS models to be exported to FMUs using a single function call. In addition, the exporter provides functionality to easily set up a co-simulation equivalent of a coupled model. Meaning, from a coupled model, the exporter can generate a folder containing an FMU for each component of that model, together with a JSON file describing the coupling of those components.

5.1.7. PDEVS model

This is the PDEVS model being wrapped, and is the same as the PDEVS Model part of section PDEVS FMU. The models are implemented using a standard (unmodified) version of PythonPDEVS, and needs no modifications or specific constructs to be compatible with the presented approach. For all intents and purposes, they are “normal” PythonPDEVS models.

5.2. Validation

To validate our approach, we use our prototype exporter to generate FMUs for the different components of the ACC system model (i.e., Ego Vehicle, Lead Vehicle, Controller, Supervisor, Controller Generator, Supervisor Generator) described in PDEVS models of the running example. We then use our example importer to set up and run a co-simulation using the generated PDEVS FMUs. We then compare the co-simulation with the PythonPDEVS simulation in two ways.

First, we numerically compare the communicated events where possible (i.e., vehicle states, controller output, supervisor output), as well as the simulation time at which events occur. The reasoning being that if our co-simulation approach is correct, the obtained simulation traces should be the same as those obtained using PythonPDEVS.

Second, we directly compare the behavior of the PDEVS models themselves. Meaning, which transitions occur at what point in simulation time, with which inputs, which outputs are generated, etc. We do this by instrumenting each atomic PDEVS model, having them generate a log of each state transition. We then compare the logs for each atomic PDEVS model between the co-simulation and the PythonPDEVS simulation to ensure they are equivalent. Logs are deemed equivalent if all the same transitions occur in the same order, with the same input and/or output events on the same ports, at the same time instant. The reasoning being that if our co-simulation approach is correct, the logs should be equivalent to those obtained using only PythonPDEVS.

Rationale: The reason for comparing behavior (logs) at the level of atomic models is that events in coupled models can occur in parallel. However, these parallel events are recorded sequentially in the logs. This means that logs for coupled models can have multiple valid orderings. As a result, comparing logs at the level of coupled models becomes more complex because differences in ordering may not necessarily indicate issues in the co-simulation. The behavior of atomic models, however, is inherently sequential. Therefore, our reasoning is that issues with the orchestration will likely be visible as differences in the logs.

5.3. Discussion

First, the results of comparing the values of the communicated events are shown in Table 1. This table shows an analysis of the differences between the (FMI) co-simulation and the PythonPDEVS simulation. For each relevant component of the ACC system model, it shows the mean absolute error, and the mean and standard deviation of the error for different values in the communicated events (for 801 samples each). In addition, it shows this same analysis for the difference in the time at which events occur in both simulations. From the results, it is clear that the simulation results do not match exactly. However, the differences between the two simulations are small, with the biggest differences being on the order of ${10}^{-11}$ . These numerical differences appear to be caused by issues related to floating-point representation and/or conversions occurring somewhere in our implementation, which involves both compiled (C) binaries (UniFMU) and Python code. Examining the obtained traces, we observe small discrepancies in numerical values for our approach compared to PythonPDEVS, which is fully implemented in Python. For example, we observe timestamps with a value of 0.7999999999999999 instead of the expected 0.8. As several of our PDEVS models make use of the elapsed time when updating their internal state, such as the new position and speed of a vehicle, it stands to reason that these differences in time cause small differences in the states, which cause further differences in the closed-loop behavior of the simulation.

Table 1.

Analysis of the differences in values communicated in events between our approach and PythonPDEVS.

Component	Value	Max. Abs.	Mean	Std.
Overall	Time	$6.39\times {10}^{-13}$	$2.13\times {10}^{-13}$	$2.28\times {10}^{-13}$
Ego Vehicle	Position	$1.50\times {10}^{-11}$	$4.32\times {10}^{-12}$	$6.24\times {10}^{-12}$
	Speed	$7.85\times {10}^{-13}$	$-7.65\times {10}^{-14}$	$1.49\times {10}^{-13}$
	Acceleration	$2.15\times {10}^{-12}$	$4.71\times {10}^{-15}$	$4.19\times {10}^{-13}$
Lead Vehicle	Position	$1.50\times {10}^{-11}$	$4.19\times {10}^{-12}$	$6.28\times {10}^{-12}$
	Speed	$4.51\times {10}^{-13}$	$-1.05\times {10}^{-13}$	$1.18\times {10}^{-13}$
	Acceleration	$4.13\times {10}^{-15}$	$5.61\times {10}^{-17}$	$1.15\times {10}^{-15}$
Controller	Wanted Acceleration	$1.01\times {10}^{-11}$	$4.67\times {10}^{-15}$	$1.52\times {10}^{-12}$
Supervisor	Wanted Speed	$8.53\times {10}^{-13}$	$-7.60\times {10}^{-14}$	$1.61\times {10}^{-13}$

Second, we use the logs to directly compare the behavior of each atomic PDEVS model, as described in section Validation. However, We need to take into account the previously observed numerical differences when comparing the logs. As such, we add an absolute tolerance of ${10}^{-10}$ when comparing timestamps and input/output events between the two approaches. Excerpts from the logs for the ego vehicle model when using PythonPDEVS and our approach are shown in Listings 2 and 3, respectively.

Listing 2.

Excerpt of the ego vehicle log, with PythonPDEVS.

1  …2 <event>3   <model> ego_vehicle_vehicle </model>4   <time> 0.3 </time>5   <kind> EX </kind>6   <port name = “update_state” category = “I”>7    <message> 1.0 </message>8   </port>9   <port name = “update_a_wanted” category = “I”>10   </port>11   <state>12     <mode> update_state </mode> update_state13   </state>14 </event>15 <event>16   <model> ego_vehicle_vehicle </model>17   <time> 0.3 </time>18   <kind> IN </kind>19   <port name = “vehicle_state” category = “O”>20   <message>[16.003999999999998, 20.04, 0.3999999999999999]</message>21   </port>22   <state>23     <mode> idle </mode> idle24   </state>25 </event>26 <event>27   <model> ego_vehicle_vehicle </model>28   <time> 0.3 </time>29   <kind> EX </kind>30   <port name = “update_state” category = “I”>31   </port>32   <port name = “update_a_wanted” category = “I”>33     <message>-3.0 </message>34   </port>35   <state>36     <mode> idle </mode> idle37   </state>38 </event>39 …

Listing 3.

Excerpt of the ego vehicle log, using our approach.

1  …2 <event>3   <model> ego_vehicle_vehicle </model>4   <time> 0.30000000000000004 </time>5   <kind> EX </kind>6   <port name = “update_state” category = “I”>7     <message> 1.0 </message>8   </port>9   <port name = “update_a_wanted” category = “I”>10   </port>11   <state>12     <mode> update_state </mode> update_state13   </state>14 </event>15 <event>16   <model> ego_vehicle_vehicle </model>17   <time> 0.30000000000000004 </time>18   <kind> IN </kind>19   <port name = “vehicle_state” category = “O”>20    <message>[16.004, 20.04, 0.40000000000000013]</message>21   </port>22   <state>23     <mode> idle </mode> idle24   </state>25 </event>26 <event>27   <model> ego_vehicle_vehicle </model>28   <time> 0.30000000000000004 </time>29   <kind> EX </kind>30   <port name = “update_state” category = “I”>31   </port>32   <port name = “update_a_wanted” category = “I”>33    <message>-3.0 </message>34   </port>35   <state>36    <mode> idle </mode> idle37   </state>38 </event>39 …

In both excerpts, the following behavior can be observed: First, at time $0.3$ (line 4), the vehicle model receives a message to update the vehicle state (lines 6–8), causing an external transition (line 5) to “update_state” (line 11–13). From “update_state,” there is an instantaneous transition to the “idle” state, whereby a message will be generated with the new vehicle state (position, velocity, and acceleration). However, at the same time, the vehicle model receives a message from the controller with a new wanted acceleration. Hence, the confluent transition function must be executed. As is common, the confluent transition function has been defined as first executing the internal transition function, followed by the external transition function. ¹⁹ This can be observed in the logs, whereby the internal transition (line 18) is executed, generating an output message with the new vehicle state (lines 19–21), and transitioning the model to the “idle” state (line 23). Then, an external transition (line 29) is executed, wherein the vehicle model receives the new wanted acceleration (lines 32–34), and transitions back to the “idle” state (line 36).

Comparing both excerpts, it can be observed how the behavior is equivalent between both approaches. Meaning, the same events occur at (nearly) the same points in time, in (exactly) the same order, with (nearly) the same input/output messages. However, the numerical differences between both approaches is also apparent. It can be observed how the timestamps do not match exactly between both approaches (lines 4, 17, and 28). As the vehicle state (position, velocity, and acceleration) is dependent on the elapsed time, this also results in small differences in the “vehicle_state” message (lines 19–21).

When comparing the full logs for all atomic DPEVS models, we find that they are all equivalent between the two approaches. Therefore, the behavior of the atomic models matches in our approach when compared to an established PDEVS simulator, that is, PythonPDEVS.

While these results confirm that FMI 3.0 can indeed preserve PDEVS semantics for the presented case study, some practical limitations remain. These are discussed in the following section.

6. Limitations

Although the presented results demonstrate that our approach can preserve PDEVS semantics in FMI 3.0 co-simulations, some limitations remain that may affect applicability in broader settings. In this section, we discuss these and outline potential strategies to address them where possible.

6.1. Coupling restrictions

6.1.1. Many-to-many coupling

The current version of the FMI standard only allows a one-to-many structure when connecting inputs and outputs of FMUs. However, PDEVS is more flexible as it allows for many-to-many couplings, where multiple component models can influence each other. Therefore, the use of FMI for co-simulating PDEVS FMUs restricts the allowed couplings. While this restriction does not break correctness for simple examples, it does limit the applicability of the presented approach for more complex co-simulations.

Possible workarounds include the introduction of additional “aggregator FMUs,” which could collect events on multiple inputs, combine them, and then forward them to one or more other FMUs using a single output. Alternatively, further semantic adaptation could be performed to achieve a similar effect. More specifically, a PDEVS FMU could be again wrapped into an FMU with multiple inputs, whereby the parent wrapper could perform the aggregation function for the enclosed PDEVS FMU. Similar approaches are described by Gomes et al. ²³ to extend FMUs with functionality such as input interpolation.

However, both approaches have similar drawbacks. They add modeling overhead and their concrete implementation (e.g., number of supported inputs, aggregation logic) would depend heavily on the specific co-simulation setup in which they are used, making them application-specific, limiting reuse, and increasing maintenance effort when the co-simulation setup changes.

6.1.2. Translation functions

Coupled PDEVS models can include a set of translation functions ({ $Z_{i,j}$ }) to translate an output event of one component to a corresponding input event for another component if necessary. This increases the flexibility of the PDEVS formalism as it allows the coupling of component models with otherwise incompatible event definitions. However, in the presented approach, we do not explicitly consider translation functions, essentially assuming them to be identity functions. While sufficient for the presented example, it does limit the flexibility of the presented approach and its applicability to more complex scenarios that require event translation.

As these translation functions are defined at the level of the coupled models, these also need to be considered at the level of the co-simulation. The FMI standard itself has no specific provisions for adapting incompatible signals. As with the many-to-many coupling, such functionality could be introduced through additional semantic adaptation. Gomes et al. ²³ describe such an approach to introduce unit conversions between FMUs to solve signal data mismatches. While this would restore flexibility, it again comes at the cost of additional modeling overhead and limited reuse.

6.2. Hierarchical modeling

A core strength of the PDEVS formalism is its support for hierarchical modeling, where coupled models can contain both atomic models and other coupled models. This allows large systems to be organized into nested coupled models, improving modularity and maintainability. However, FMI co-simulation is inherently flat as FMUs are coordinated by a central orchestration algorithm without an explicit notion of hierarchy. As such, once PDEVS models are wrapped into FMUs, this hierarchical modeling capability is lost.

This loss of hierarchical modeling capability when using FMI has practical drawbacks to modelers. Particularly, it makes maintaining, modifying, and debugging models more difficult as the structure of the modeled system is not easily visible in the co-simulation. However, existing PDEVS debugging approaches ³³ may provide useful support in this regard.

A potential strategy to reintroduce hierarchical modeling is to adopt a hierarchical co-simulation technique, as described by Gomes et al. ²³ and supported in the FMPy ³⁰ tool. In their approach, a set of coupled “internal” FMUs is wrapped into a higher-level “external” FMU, such that the entire assembly behaves as a standard FMU from the perspective of the orchestration algorithm. While this reintroduces hierarchical modeling in an FMI-based co-simulation, it again requires additional modeling effort and increases implementation complexity.

6.3. Numerical precision and time-keeping

Another limitation concerns numerical precision and how it affects time-keeping and simulation results. In FMI co-simulations, time and step sizes are communicated using floating-point numbers. As in most simulation setups, this can introduce small rounding errors, which can accumulate over time if not managed carefully. In our results, we also observed such discrepancies when comparing our FMI-based approach to PythonPDEVS. While these discrepancies were small and did not meaningfully affect the simulated behavior of the system, they do complicate strict reproducibility across different simulation tools.

It is important to note that these difficulties are not unique to our approach, or FMI in general, but affect most simulators that rely on floating-point arithmetic. In fact, FMI includes different mechanisms to detect and mitigate the potential of time-drift or mismatched time between FMUs. First, the doStep call communicates both the current simulated time and the requested step size to an FMU, allowing it to detect mismatches between FMU and orchestrator, and the FMU can opt for calculating the next time as $\mathrm{current}\_\mathrm{time}+\mathrm{step}\_\mathrm{size}$ instead of just accumulating $\mathrm{step}\_\mathrm{size}$ , which would indeed introduce time-drift. Second, the synchronous clocks introduced in FMI 3.0 ³⁴ provide an additional mechanism for time-synchronization. While an FMU can communicate to the importer when a particular time-based input clock should tick, it is up to the importer to activate the clocks at the correct moment in time. Here, the importer is considered as the single source of truth for simulation time. When a clock ticks, the FMU is expected to synchronize to the corresponding time. In addition, fixed-point arithmetic may be used to further manage time-keeping, for example, by defining a fixed time-base, in situations where strict reproducibility is critical.

Together, these mechanisms help to manage time-drift and resulting numerical discrepancies. However, it should be noted that perfect reproducibility across different simulators is difficult to guarantee in any floating-point-based environment.

6.4. Continuous dynamics and hybrid simulations

In the current paper, we focused exclusively on discrete-event models. While we demonstrated that FMI 3.0 can preserve PDEVS semantics, we have not yet considered hybrid settings that combine PDEVS FMUs with continuous-time FMUs. This is a limitation as many practical applications, such as the simulation of cyber-physical systems, require the co-simulation of both continuous dynamics and discrete-event-driven components.

In such a hybrid setting, the events produced by the PDEVS FMUs must be correctly deserialized and interpreted by continuous FMUs, while state changes in continuous FMUs must be translated into events the PDEVs FMUs can understand. While FMI 3.0 provides mechanisms such as synchronous clocks and event mode to support such interoperability, these do not by themselves solve this communication.

One way to provide a bridge between continuous and discrete-event components is to introduce explicit interface models. Jiresal and Wainer ³⁵ formalized cyber-physical system interfaces in DEVS using dedicated sensor and actuator models. In their work, the sensor models translate physical sensor signals into discrete events that their DEVS models can process, while actuator models translate events into physical signals. A similar approach could be taken in FMI-based co-simulations, where interface FMUs would take on the role of translating between continuous signals and PDEVS events. Such constructs could provide a structured way to bridge PDEVS and continuous-time FMUs, though at the cost of additional modeling effort.

6.5. Use of PDEVS over DEVS

A possible limitation of our approach is that it relies on PDEVS rather than the original DEVS formalism. This choice was necessary because PDEVS solves fundamental challenges in coupling models, in particular, it avoids reliance on a global select function to resolve simultaneous events. This proved essential to correctly couple models using FMI 3.0 without relying on a DEVS-specific orchestration algorithm or other model-specific coordination mechanisms.

In practice, the impact of this choice is limited. Many existing models are already defined in PDEVS, requiring no additional effort. For models defined in classic DEVS, migration to PDEVS should be straightforward, as PDEVS is a conservative extension of DEVS. The actual cost–benefit trade-off will depend on the specific scenario, but in cases where FMI-based co-simulation is needed, the additional effort of migration is generally manageable relative to the advantages offered by this approach.

Together, the identified limitations define the boundaries of the presented contribution. They emphasize both the assumptions under which PDEVS semantics can be preserved in FMI 3.0 and the challenges that remain for broader applicability. The demonstrated preservation of PDEVS semantics confirms the feasibility of the approach, while the identified challenges highlight promising directions for extending it. The next section summarizes our contributions and outlines directions for future research.

7. Conclusions and future work

To summarize, we have presented an approach to couple DEVS models using the FMI standard 3.0, making heavy use of the new synchronous clocks. We have shown how PDEVS can be used to avoid the need for a select function when coupling DEVS models through FMI. We have also shown how the different steps in the PDEVS abstract simulator map to different FMI functions, and how an FMI orchestration algorithm can be implemented to ensure the correct coupling of DEVS FMUs. Finally, we have presented a common example orchestration algorithm based on the literature that meets these requirements.

It is worth stressing the importance of bridging these two formalisms. As shown by Vangheluwe, ³ many hybrid and discrete formalisms can be transformed into DEVS. By enabling the coupling of DEVS models using FMI 3.0, we open up new possibilities for hybrid system simulation, allowing for broader interoperability and more flexible co-simulation setups across different modeling paradigms.

As limitations, we have chosen not to validate the work with combinations of non-PDEVS FMUs and PDEVS FMUs. Since we obey the FMI standard interface, we do not lose generality in assuming all FMUs are PDEVS FMUs. A minor limitation is in the serialization of events that forces other FMUs to parse them accordingly. It is trivial to adjust this to ensure interoperability with a set of known FMUs, but impossible to ensure its compatibility with any FMU.

A more significant limitation, as previously mentioned, is that FMI cannot fully preserve the coupling semantics of PDEVS models in all cases. Specifically, FMI only supports “one-to-many” connections, whereas PDEVS allows “many-to-many” coupling. This restriction impacts the correct propagation of simultaneous events across interconnected FMUs in specific scenarios. In addition, in adapting PDEVS models into FMUs, we lose PDEVS’ ability for hierarchical composition of models, and floating-point time communication can introduce small discrepancies that complicate strict reproducibility. Finally, our contribution has so far only addressed discrete-event models, leaving open the question of how PDEVS FMUs can be co-simulated with continuous-time FMUs. Together, these limitations define the boundaries of the presented approach, but the demonstrated preservation of PDEVS semantics confirms its feasibility and motivates further extension.

In future work, we aim to address these challenges. Extending FMI-based co-simulation with support for many-to-many couplings and translation functions will likely require additional semantic adaptations of PDEVS FMUs. ²³ We also plan to investigate wrapper-based techniques for reintroducing hierarchical modeling.

Most importantly, we intend to explore the integration of PDEVS FMUs with continuous-time FMUs to enable hybrid system simulation, such as the cyber-physical systems application shown in previous work. ⁸ This will require addressing the event serialization to allow interoperability with non-DEVS FMUs, potentially through structured interface models such as sensors and actuators that translate between discrete events and continuous signals. ³⁵

Finally, we plan to evaluate the computational overhead introduced by coupling DEVS models through FMI. Using benchmarks such as DEVStone, ³⁶ we will assess performance trade-offs and scalability of the approach.