DEVS Closure Under Coupling, Universality, and Uniqueness: Enabling Simulation and Software Interoperability from a System-Theoretic Foundation

Abstract

This article explores the foundational mechanisms of the Discrete Event System Specification (DEVS) theory—closure under coupling, universality, and uniqueness—and their critical role in enabling interoperability through modular, hierarchical simulation frameworks. Closure under coupling empowers modelers to compose interconnected models, both atomic and coupled, into unified systems without departing from the DEVS formalism. We show how this modular approach supports the scalable and flexible construction of complex simulation architectures on a firm system-theoretic foundation. Also, we show that facilitating the transformation from non-modular to modular and hierarchical structures endows a major benefit in that existing non-modular models can be accommodated by simply wrapping them in DEVS-compliant format. Therefore, DEVS theory simplifies model maintenance, integration, and extension, thereby promoting interoperability and reuse. Additionally, we demonstrate how DEVS universality and uniqueness guarantee that any system with discrete event interfaces can be structurally represented with the DEVS formalism, ensuring consistency across heterogeneous platforms. We propose that these mechanisms collectively can streamline simulator design and implementation for advancing simulation interoperability.

1. Introduction

DEVS (Discrete Event System Specification) theory provides foundational mechanisms—closure under coupling, universality, and uniqueness—enabling interoperability through modular, hierarchical model construction and simulation [1,2,3,4]. Although the foundational mechanisms of DEVS have been discussed in several publications [5,6,7,8,9,10,11,12,13,14], our aim is to provide a more intuitive understanding of the concept that will help extend the concept to broader contexts of simulation interoperability and development of software systems such as DoD’s modular open systems approach (MOSA) [15]. Closure under coupling in DEVS ensures that interconnected models, whether atomic or coupled, can be composed into a single unified model without leaving the formal DEVS framework. This modularity enables the construction of complex, hierarchical systems from simpler, reusable components, streamlining model management and supporting scalability [5,13,16,17,18,19,20] In current practice, however, simulation systems are often developed without regard to modular construction considerations. This motivates the upcoming discussion of transformation from non-modular to modular and hierarchical structures which makes models easier to maintain, integrate, and expand, thus promoting interoperability and reuse.

DEVS universality and the uniqueness of representation [21,22,23,24,25] guarantee that any system characterized by discrete-event interfaces and behaviors can be accurately modeled and executed within the DEVS framework. We will review these concepts in the context that they provide a common formal basis for representing diverse systems, enabling uniform treatment and integration of models regardless of complexity or origin. This is crucial for implementations that require consistent, reliable integration across heterogeneous platforms. Flattening and hierarchical organization [2,4,26,27,28,29,30,31,32,33] in DEVS allow nested models to be represented and executed as atomic models, preserving behavioral equivalence. We will review these operations and provide a simplified approach to using them to facilitate efficient DEVS simulation execution of representation.

Figure 1 sketches the types of DEVS models and a taxonomy of DEVS models and is intended to help present the organization of the paper. This paper is organized as follows:

Figure 1. (a) The 3 types of DEVS models. (1) Atomic models, (2) flat coupled models composed of only atomic models, and (3) hierarchical coupled models are composed of at least one non-atomic model component. (b) Taxonomy of DEVS models with operations of flattening and modular/non-modular transformation included.

Section 2 reviews the modeling and simulation (M&S) framework developed in reference [14] to place the breakdown of DEVS models into atomic and coupled (Figure 1) in the wider context of the M&S enterprise. It goes on to provide background information on DEVS universality and uniqueness of representation which, along with closure under coupling, provide theoretical support for claiming that DEVS supports the best way to construct simulation models for interoperability and related traits. Finally, it provides background information on the closure under coupling and its foundation for definition of the DEVS abstract simulator/simulation protocol.

Section 3 reviews the DEVS Simulation Protocol and Abstract Simulator and builds on this background to present a new design for object-oriented implementation of the DEVS Abstract Simulator. The design employs closure under coupling explicitly to simplify the operation of the DEVS simulator.

Section 4 reviews the DEVS bBus concept for generalizing the DEVS protocol to apply more generally. It then goes on to consider the inter-conversion between the non-modular and modular form for flat coupled models (Figure 1).

This finding has important implications for distributed simulations in practice since it indicates that existing federations of various types can be coordinated within the same coupled model without needing to refactor their internal structures. This removes a major barrier to widespread adoption of DEVS within organizations with large legacy simulation investments.

Section 5 discusses operations on the hierarchical structure of DEVS model flattening and its inverse deepening. In the flattening process hierarchical coupled models are transformed to behaviorally equivalent “flat” coupled models, i.e., having only atomic models as components [28,34,35,36]. Conversely, as suggested in Figure 1, the reverse direction is also possible—“deepening” adds hierarchical structure to flat coupled models. This section concludes with the implications for structural operations for the design of DEVS models and simulators. In summary, flattening eliminates structure by reducing message traffic and increasing simulation efficiency; deepening can introduce hierarchical structure to enable modularity, reuse, and scalability.

Section 6 considers DEVS closure under coupling in relation to closure properties in other systems-adjacent formalisms such that the special nature of the DEVS concept is highlighted.

Section 7 provides in depth examination of needs and opportunities for further research and development of DEVS-based simulation interoperability.

Moreover, the application of DEVS theory within Model Based System Engineering (MBSE) and Mathematical Systems Theory offers potential concepts and tools to enable formal analysis of complex system-of-systems designs. Finally, Section 8 concludes the paper with discussion of limitations, caveats, and a summary of the opportunities for continued development.

Several appendices provide detail for the interested reader.

2. Background: Modeling and Simulation Framework and DEVS Theory

The Modeling and Simulation Framework, presented in Figure 2a, formalizes a small set of foundational entities and relationships that describe any model–simulation system in an abstract, domain-independent way. This framework provides the conceptual scaffolding behind DEVS and other system-specifications [14,25,33,34,35,36]. In brief the entities are (a) Source System, a real or imagined system, characterized by observable behavior over time in a defined set of variables; it may be physical (a spacecraft), conceptual (a policy process), or hypothetical. (b) Experimental Frame (EF), a specification of the conditions under which the system is observed or experimented upon, includes the following: inputs, including allowable stimuli; outputs, including observations to record; conditions, including intended scope, constraints, metrics, and sampling plans (in collaborative modeling, the EF ensures reproducibility and relevance); (c) model, an abstract, formal specification that generates behaviors consistent with the source system under the EF and exists in many forms—including mathematical equations, logical rules, and state machines—and must be valid with respect to the EF (i.e., produce correct behavior for the intended scope); and (d) simulator, the computational realization that executes the model to produce behavior over (simulated) time and separates model specification from the execution engine, allowing reuse and platform independence. The entities are related by (a) the validity relation that judges whether the model represents the system’s behavior under the EF and (b) the simulator realizing (executes) the model correctly. In summary, executing the simulator of the model produces observable behavior for analysis and validation against the real system within the EF.

Figure 2. (a) Modelling and simulation framework. (b) Experimental frame in coupled model form.

Figure 2b provides more structuring of the experimental frame, presenting it as a coupled model consisting of (1) generators of inputs to the system or model, (2) acceptors that check the constraints and conditions governing termination of execution, and (3) transducers that process raw simulation data to provide metrics and summaries of interest with the frame. More details are available in [11,37].

2.1. DEVS Universality and Uniqueness

We first briefly recall the ability of DEVS to represent general dynamic systems; for a more introductory and detailed presentation, see [14]. In the DEVS formalism, an atomic models keep track of how long it has been in its current state. That duration—called the “elapsed time”—is a core input to handling both internal scheduling and reacting to external inputs. By feeding elapsed time into the state-update logic, a DEVS model can faithfully reproduce continuous dynamics within a discrete-event framework. The model maintains its representation of the system state, as well as the elapsed time since its last update of this state. When an input arrives, the model updates the continuous variables over the elapsed time before applying the input and resetting the elapsed time variable to 0. This ensures the state reflects all continuous evolution up to the instant of the external event. To model continuous-time systems described by differential equations, DEVS employs elapsed time to integrate state derivatives between events. This on-demand integration avoids fixed time-step loops, advancing state only when inputs arrive or outputs are needed.

Such a representation is an instance of general systems that have discrete-event input/output interfaces. As depicted in Figure 3a, we consider the representation of DEVS-like systems, defined as systems with input and output time segments that contain events that happen at discrete points in time. These differ from continuous time segments with variable values defined throughout the interval. As shown in Figure 3b, the considerations begin with the lowest level of the system specification hierarchy and work up to the highest level in stages: the IORO (input/output relation), IOFO (input/output function), canonical I/O system (state level), and coupled system. In these terms, the DEVS representation of DEVS-like systems is universal (applies to all such systems at the IORO level) and unique (their minimal state representations are isomorphic to DEVS systems at the state level). DEVS representation at the coupled-system level is characterized by its ability to support efficient component-wise simulation of multi-component systems [14].

Figure 3. (a) DEVS-like systems exemplifying input and output time segments with discrete events, shown as vertical lines. (b) DEVS representation of DEVS-like systems at the levels of system specification ranging from input/output behavior to increasingly structural representations.

2.2. Background on Closure Under Coupling

We start with a discussion of Figure 4, which illustrates the closure of the set of all rectangles under an operation called attachment. Here, attachment is a geometric operation that places two rectangles with equal-length sides next to each other to form a bigger rectangle. The geometric details of the figure are presented in Appendix A, which verifies the intuition that attaching two rectangles along sides of equal length results in another rectangle. When applied to subsets of squares, this operation creates rectangles that are not square. This illustrates the concept of closure of a set under an operation as the smallest set containing all the results of such an operation. Here, rectangles are closed under attachment and constitute the smallest set closed under attachment that is generated by squares.

Figure 4. Analogy: geometric class of rectangles is closed under attachment, but the subclass of squares is not.

An analogy can be drawn between the geometric notion of closure under attachment and the DEVS property of closure under coupling: Just as rectangles are closed under the operations of attachment, DEVS models are closed under coupling (the counterpart of attachment). On the other hand, the subset of squares is not so closed. Likewise, the subset of atomic models is not closed under coupling, yielding coupled models as the smallest inclusive set. However, unlike geometric analogy, they prove to be behaviorally equivalent to atomic models. The central guarantee is that the resulting coupled model can itself be represented as a valid atomic DEVS model.

The concept of closure under coupling is framed within general dynamic systems as involving a basic subclass of systems such as Discrete Time System Specification (DTSS) and Differential Equation System Specification (DESS) [14].

Referring to Figure 5, as with the just-mentioned system specifications, a basic formalism (1) is assumed that specifies (2) the subclass of basic systems. Also, a coupled subclass (3) is assumed that has a specification (4) that is based on the coupling (5) of basic specifications. The coupled specification is assumed to produce a resultant (6) which is a coupled system of basic systems. Closure under coupling for the subclass of interest requires that all such resultants be behaviorally equivalent to basic systems—shown in Figure 5 as that the coupled subclass being included within the basic systems subclass. Proof of this inclusion consists in constructing a basic specification (7) of a system equivalent to the resultant (see [36] for a detailed discussion). Such a specification can then participate as a component in a coupled system of basic components leading to hierarchical construction that is formalism compliant. Roughly, the closure under coupling theorem states the following:

Figure 5. Systems specification formulation of closure under coupling: a basic formalism (1) specifies (2) the subclass of Basic Systems; Coupled Subclass (3) specifies (4) coupled subclass systems based on coupling (5) of Basic System Specifications. When closure under coupling holds, the resultant (6) is included in Basic Systems.

Any coupled DEVS model can be transformed into an equivalent atomic DEVS model.

In the proof, atomic models form a coupled DEVS model, representing their interactions. Constructing an equivalent atomic DEVS model involves defining a global state (i.e., the state representing the current states of the components), constructing global transition functions, and ensuring synchronization of time advances and event propagation. Detailed proof is provided in [14], and a sketch of the proof is provided in Appendix B.

Concisely summarized, closure under coupling in DEVS theory allows interconnected DEVS models to be treated as a single DEVS model. This ensures modularity (building large systems from reusable components) and hierarchical modeling (nesting models within models). Simulation benefits include designing efficient simulation engines that treat any model uniformly.

3. DEVS Simulation Protocol/Abstract Simulator

The DEVS simulation protocol is a formal mechanism that governs how DEVS models—both atomic and coupled—interact during simulation. It ensures that time advances, event scheduling, and message passing are handled correctly and consistently across a hierarchical model structure. A generic implementation of the DEVS simulation protocol is given by the DEVS Abstract Simulator. Details of these constructs are provided in [2,14,38]. and sketched in Appendix C.

The relationship between the proof of closure under coupling and the definition of the DEVS abstract simulator is foundational. The proof of closure under coupling dictates how a DEVS simulator must operate. The simulator must do the following:

i.

Maintain time synchronization across components by keeping track of the elapsed time for each component.

ii.

Compute the minimum time advance to determine the next event, correctly route messages between components, and apply internal, external, or confluent transition functions correctly.

These requirements are direct consequences of the closure proof. This leads to the abstract simulator algorithm for use in DEVS simulation. While the proof does not define the algorithm directly, it dictates the structure and behavior that any correct DEVS simulator must implement. We now explain how this happens by examining the proof of closure and abstract simulator in a simple coupled model.

Figure 6 depicts a coupled model of simple atomic components that illustrate the requirements for the DEVS abstract simulator enumerated above. State diagrams of the components, Imm, RecImm, ReccNonImm, and NonImm are shown within rectangles representing atomic model transition specifications. We consider the initial state of the composite model (called the global state to distinguish it from the states of the components called local states) as described in Table 1.

Figure 6. DEVS Coupled Model Illustrating Closure Under Coupling.

Table 1. Initial global state of the model.

Component	Sequential State	Time Advance
Imm (imminent)	sendActivate	1.
RecImm (receives input and is imminent)	sendActivate	1.
RecNonImm (receives input and is not imminent)	waitForActivate	infinity
NonImm (nonimminent)	active	10.

(1)

The time advance of the next internal event is determined: The internal transition function defined by the proof of closure under Coupling computes the time advance to the next internal event and its effect on the state described in the table. The resultant time advance is the minimum of the time advances of the components, which is 1. The simulation clock, having originally been set to 0, 0 will now be advanced to 1. The imminent components (those having the minimum) are Imm and RecImm. To determine the next state after that time has advanced, the following steps take place:

(2)

The outputs of the imminent components are computed: Here these are both the Activate outputs from Imm and RecImm whose outputs are determined by their output functions applied to their current states.

(3)

Using the coupling table illustrated inTable 2, the outputs are routed to the recipients: Here the table depicts the three 4-tuples that are derived from the coupled model specification of Figure 6. Such tuples are of the form (source, outport, destination, inport) with the interpretation that an output message originating from the source component on its output port output should be routed instantaneously to appear on the input port inport of the destination. For example, the first row in the table dictates that an output message appearing on the activate outport of the source Imm will be placed on the input port Activate of the RecImm component. Likewise the second line differs only in the recipient and its input port from the first row. The last tuple states that an output produced by RecImm on its output port Activate must be placed on the input port Activate of the component NonImm.

Table 2. Coupling table for closure illustration example.

Source	Outport	Destination	Inport
Imm	Activate	RecImm	Activate
Imm	Activate	RecNonImm	Activate
RecImm	Activate	NonImm	Activate

The routing of the output messages into input messages is done instantaneously, as explained above. To do this, the simulator calls an algorithm called “RouteMessages”(),which looks up the table given the source and its output port. As illustrated in Figure 7, the simulator calls the method RouteMessage (C1,P1,x) when C1 is imminent and the call to its output function produces message x; The coordinator places the message x on the inport IP of the destination D by calling D’s external (or confluent) transition function with input x on inport IP. The algorithm is briefly described by the following sketch:

Figure 7. Example of an internal coupling: component C1 sends unspecified messages on Port PI to Component C2 on Port P2.

   RouteMessage(C1,P1,x) given IC = {(C1,P1,C2,P2)}:

    Extract all couplings that have source = C1 and outport = P1

    For each such coupling, let the destination = D and inport = IP

    return the pairs (D,IP)

In the example of Figure 6, components Imm and RecImm are imminent, and place activate messages on their output ports Activate. The RouteMessages algorithm looks ups the source/input port pairs for these messages and the coordinator calls either the external transition function or the confluent transition function as described below in step (4).

(4)

The effects of transmitted outputs (now inputs) are computed:

a.

Since RecImm is imminent and receives an input, it uses its confluent function to compute its next state as waitForActivate (here the confluent function computes the external transition before the internal transition)

b.

Since RecNonImm is not imminent, it uses its external transition function to compute its next state as passive.

(5)

Imminent components that are not receivers apply their internal transition functions—here Imm transitions to passive.

(6)

Components that are neither imminent nor receive inputs update their time advances to reflect the passage of the elapsed time. Here NonImm updates its time advance to 9. (10 − 1).

This computed next state is displayed inf Table 3:

Table 3. Global state after transition.

Component	Sequential State	Time Advance
Imm (imminent)	passive	Infinity
RecImm (receives input and is imminent)	waitForActivate	Infinity
RecNonImm (receives input and is not Imminent)	passive	Infinity
NonImm (nonImminent)	active	9

The next cycle repeats with a minimum time advance of 9, and the clock is updated to 10. Note that NonImm transitions to passive as originally scheduled at this time while the other components remain inactive.

Here we see that the abstract simulator algorithm changes the global state to the correct new configuration with the correct time advance in steps that correspond to those of the proof of closure under coupling. When transferred to a network context, the abstract simulator is referred to as the “distributed DEVS simulation protocol” to reflect that model components may reside on different computing elements and the coupling implemented as routing of messages among them.

Object-Oriented Implementation of DEVS Abstract Simulator

The process of closure under coupling can be viewed as collapsing the entire coupled model into a single behaviorally equivalent DEVS atomic model. The atomic state space is the global state space of the coupled model, i.e., the Cartesian product of all component model states (plus their elapsed times). The proof proceeds by deriving the form of the basic functions: output, internal, external, confluent and time advance. For example, the latter computes the global time-advance function (the minimum of the component time advances). The resulting atomic model reproduces exactly the behavior of the original coupled network, but at the cost of a vastly larger state description—yet with zero inter-component message passing at runtime [39].

In this section, we present a new design for object-oriented implementation of the DEVS Abstract Simulator. In contrast to existing designs [2,39,40,41,42,43,44]. The design employs closure under coupling explicitly to simplify the operation of the DEVS simulator, hereafter referred to as the “2-level DEVS simulator” (2DEVSim). It does so by reducing the requirement for coordinators to handle arbitrary hierarchical models so that they only are concerned with models that are instances of the atomic class as defined in the class structure of Figure 8a, which illustrates the class structure of 2DEVSim. In the sketched UML class diagram, the DEVS base class is extended by the atomic and coupled subclasses.

Figure 8. (a) UML class diagram sketch of DEVS Abstract Simulator, (b) Illustrating Closure Atomic Class Structure.

An instance of a Coupled class is composed of one or more Atomic instances. Further structuring of these classes reflects the formal definitions of their respective DEVS basic, atomic, and coupled models (not shown in the figure). Classes AtomicSimulator and CoupledCoordinator handle instances of Atomic and Coupled, respectively. In this design, the CoupledCoordinator only handles atomic models, simplifying its definition by eliminating the recursion needed for routing messages in arbitrary coupled models.

Closure under coupling enables this design to handle hierarchical models. As shown in Figure 8a, the subclass ClosureToAtomic wraps a Coupled instance to make it behave like an Atomic instance to a CoupledCoordinator. Figure 8b illustrates the inner workings of ClosureToAtomic, showing how the wrapped coupled model interfaces with the AtomicSimulator, which calls the standard DEVS functions: internalTransition(), externalTransition(), confluentFunction(), getOutput(), and getTimeAdvance(). The wrapped model delegates these calls to the internal CoupledCoordinator following the simulation cycle derived from the closure under coupling proof.

Appendix D shows the inner workings in detail. Its operation is sketched in Table 4.

Table 4. Definition sketches of DEVS functions.

The Wrapped Model Definition of the	Sketch of Its Definition
Internal transition function	(1) Get the next event time from the internal coordinator (2) Tell the internal coordinator to execute its next event at the given next event time
External transition function with arguments of elapsed time and input bag	(1) Get the last event time from the internal coordinator (2) Tell the internal coordinator to process the input bag with the time stamp of the given last event time plus the elapsed time
Output function	Tell the internal coordinator to compute the output and return this output bag
Time advance function	Tell the internal coordinator to get the next event time and the last event time and to return the second minus the first

This wrapping can be done automatically when the user creates an instance of CoupledCoordinator and provides a coupled model to work on; it should be noted that this does not require flattening of the model structure.

4. DEVS BUS and Model Transformation

Following the introduction of the DEVS abstract simulator and associated DEVS simulation protocol, we will demonstrate how non-DEVS models can be incorporated within this framework. Figure 9 presents the DEVS bus concept, which enables interoperability with multiple modeling formalisms [44,45,46,47,48,49,50,51,52,53,54]. The ability for DEVS-based simulators to import and export models for integrated simulations, improving compatibility and supporting model sharing and reuse, is an area where many DEVS tools still require further development for full interoperability in complex engineering applications. To facilitate integration, each formalism must be encapsulated in a DEVS-compliant format through an appropriately defined simulator. These models may then be coupled with others and executed via a standard coordinator. Furthermore, as reviewed above, DEVS possesses the versatility to represent models developed using other prominent formalisms such as DTSS and DESS, thereby making it feasible to unify these within an all-DEVS simulation environment, as supported by the DEVS bus concept. In the following we discuss transformations of non-modular multi-component models to modular form that enable these formalisms to be adapted for compatibility with basic DEVS. Adaptation occurs by incorporating essential input/output interface elements, namely external transition, and output functions to create so-called DEVS wrappers.

Figure 9. DEVS BUS support of multiformalism modeling—originally defined for interoperating different event-scheduling “worldviews” and later generalized to different DEVS model specification formalisms.

4.1. Transforming Non-Modular Multi-Component DEVS Models into Modular Form

Multi-component systems with non-modular couplings directly access and modify each other’s state variables. This results in a lack of modularity when compared to systems with modular couplings. The following procedure outlines how to convert non-modular coupled systems into a modular structure. This conversion can always be achieved by identifying dependencies between components and restructuring them into input and output interfaces and modular couplings. The process of introducing input/output interfaces is referred to as “modularization”.

There are two types of non-modular couplings that require different handling. In the first type, component A has write access to a variable v belonging to component B (Figure 10). Modularization transforms this arrangement into a communication from A to B using a modular coupling. Specifically, A is provided with an output port, vout, while B receives an input port, vin, which are connected by a coupling. When A intends to update v in the original transition function, it initiates an output event at vout with the corresponding value in the modular form. This action triggers an input event at vin of B, and B’s external transition function updates its variable v with the received value.

Figure 10. Transforming non-modular to modular structures.

In the second type, component B has read access to a variable u of component A (Figure 10). In the modular form, this scenario requires B to consistently access the current value of u. To address this, B maintains a copy of u’s state information. Whenever A changes the value of u, B must be notified of the modification. This notification occurs through a coupling that connects ports uout on A and uin on B, similar to the mechanism used in the first case. As a result, B maintains an updated copy of variable u in its own state variable ucopy (Figure 10).

Non-modular models are often designed as single, rigid structures that are difficult to modify or extend. To convert them to modular form, the model is broken down into smaller, independent components, each representing a distinct part of the system. These components become reusable modules, which can be interconnected using the principles of DEVS closure under coupling. This transformation allows the overall system to be reconstructed as a network of modules, making it easier to manage, maintain, and expand. Additionally, hierarchical organization can be introduced, with modules nested within larger modules, further supporting flexibility and scalability. We will show that the modular approach streamlines model design and supports interoperability by enabling uniform treatment and integration of diverse models expressed in different formalisms and approaches. Moreover, this approach has the advantage that hierarchical DEVS models can be readily transformed into executable simulation code.

4.2. Non-Modular Non-DEVS Models in Distributed Simulation

The concept of DEVS models coordinated on the DEVS Bus is particularly important in distributed simulation. Non-modular models are models that unlike their modular counterparts, allow other models to access their internal state. For example, in Figure 11, model B has direct read access to model A during its state-transition function. Model B also has direct write access to the state of model C. This type of global state access is common in distributed simulation implementations.

Figure 11. Non-modular model illustrating direct access of model B to model A and B to C.

Standardized simulation protocols typically implement their components as non-modular models with a global state sharing mechanism, as shown in Figure 12. This is true for the published SISO (Simulation Interoperability Standards Organization) standards, High Level Architecture (HLA) and Web Live, Virtual, Constructive (WebLVC) [4,36,45,46,47,48,49,50,51,52,53,54,55]. Another characteristic of such distributed simulation standards is to synchronize time via real time, also known as “wall-clock” synchronization. In this paradigm, there is no synchronized global event list, and each model executes events once the real-time clock reaches their scheduled time. This is true for Distributed Interactive Simulation (DIS) IEEE Standard and WebLVC [51].

Figure 12. Non-modular distributed simulation protocols federating models A and B.

The universality and uniqueness of DEVS representation can be applied to represent non-modular models in DEVS-compliant form. In short, if the non-modular model is a set of functions to produce time-based output streams from time-based input streams, then there is a way to construct an equivalent DEVS model for that non-modular model. DEVS-SF [52,53] constructs equivalent DEVS models via DEVS wrappers for existing non-modular protocols using the approach outlined in Section 4.1. Once this is done, they can be executed by a parallel DEVS coordinator as if they were parallel DEVS models, as shown in Figure 13, with a wrapped non-modular WebLVC model. The non-modular system model A publishes its state to the DEVS/WebLVC wrapper. The parallel DEVS coordinator then couples model A’s output with the input of parallel DEVS Model B.

Figure 13. Non-modular WebLVC model wrapped by a DEVS model.

The DEVS community has had success in leveraging the universality and uniqueness of DEVS to interoperate with HLA and WebLVC [52,53].

Recognizing the DEVS ability to represent DEVS-like systems (Section 4), we can extend the concept of wrapping from an operation on models to a similar operation on simulators of non-modular models.

To elaborate, suppose that we are given a complex coupled model already in executable form such as a federation in HLA. We suppose that as is likely the case, the simulator (e.g., HLA Runtime Infrastructure) is a DEVS-like system. Then we can treat this simulator as a component in a larger coupled model that we wish to construct.

In practice, this requires that the higher-level simulator can inject inputs, receive outputs, and query to acquire the time advance as required by the DEVS abstract simulator.

In summary, the theory provides us with two approaches for converting non-modular coupled models embedded in simulators to modular form for coupling in hierarchical compositions:

(1)

Convert the atomic constituents of the coupled model to modular form so that they, as well as the coupled model, can be reused.

(2)

Treat the existing simulator as a DEVS-like system and wrap it so that it appears as an atomic model to the coordinator of the enclosing coupled model.

This conclusion carries significant practical implications for distributed simulation. It demonstrates that heterogeneous federations—regardless of their internal architectures—can be orchestrated within a unified coupled model without requiring structural refactoring. This approach removes a key obstacle to broader DEVS adoption, especially for organizations with substantial legacy simulation assets.

4.3. DEVS Co-Simulation

4.3.1. Functional Mockup Unit (FMU) and Interface (FMI)

The DEVS bus concept is also essential in co-simulation, a method that connects different simulation models or tools to analyze complex systems. In co-simulation, these models exchange data for a more accurate view of system behavior [55,56,57,58,59,60,61,62,63]. This capability serves as an essential instrument for the development and management of emerging socio-technical systems that require integrating continuous-time components with event-driven elements and presents significant challenges from both modeling and operational tool perspectives. In [59], there is proposed an approach that exploits the ability of DEVS to integrate the DEV&DESS formalism—which offers a sound framework for describing hybrid models (Section 2).

In the following we start from a more fundamental perspective in considering the basic problem of coupling models of different formalisms in a well-defined DEVS composition. The Functional Mock-up Interface Standard (FMI) [64,65,66,67,68,69,70,71,72] was developed to standardize model exchange and co-simulation which enables interaction among models developed in different formalisms. FMI defines a C interface that is implemented by an executable called a Functional Mock-up Unit (FMU). Simulation environments use the FMI to create an instance of the FMU to work together with other FMUs or other native models. Ritvik et al. [64] developed a framework based on FMI/FMU for exporting and importing modular DEVS models (after non-modular-to-modular conversion (Section 4.1) if necessary), enabling interoperation of DEVS simulators as formulated in the DEVS bus concept. Moreover, the framework demonstrates how DEVS can support broader FMI-based co-simulation via standardized integration with tools such as MATLAB-Simulink and Open-Modelica [67].

A key aspect of FMI is that each shared model runs independently, synchronizing only at discrete points. This aligns well with DEVS-coupled-model synchronization, defined by closure under coupling. FMI co-simulation’s modular, hierarchical interaction management also matches the DEVS Bus concept, enabling integration with other modeling frameworks for hybrid systems. When DEVS is combined with FMI, discrete and continuous-time models can interact seamlessly without redefining existing continuous models [4]. For instance, a DEVS-based navigation system in MS4 Me [73] and a vendor created continuous time controller were integrated in the Cadmium DEVS environment [74,75] via FMI. As a result, DEVS-based simulators can import and export models for integrated hybrid simulations, improving the opportunity to achieve greater interoperability (Section 7).

4.3.2. Exporting DEVS Models as DEVS FMUs

Figure 14 illustrates a UML diagram depicting the environment established for exporting a DEVS model as an FMU. FMU4-MS4Me leverages the FMU4J library [68] and its capabilities to package models into FMUs, with extensions developed to facilitate the export of DEVS models created using MS4Me. This functionality is structured through definitions of both generic DEVS operations and model-specific design elements. The DevsFMU and application model classes, represented in Figure 14, were implemented utilizing the FMU4J and ms4systems libraries. The DEVS model package showcased in Figure 14 comprises model code that MS4 Me generates automatically.

Figure 14. UML diagram describing the libraries for modeling FMI-based applications.

The DevsFMU class provides core DEVS modeling and simulation (M&S) functionalities; it incorporates Fmi2Helper from FMU4J, which supports FMU export. DevsFMU maintains objects of the model and simulator classes as class variables. Specifically, the model class (CoupledModelImpl) describes the model structure, while the simulator class (SimulationImpl) contains all methods necessary for model simulation—both classes are defined within MS4Me. DevsFMU overrides several Fmi2Helper methods, such as registerVariables, utilized to set and update timeRemaining, which indicates the time until the next event and uses setupExperiment to initiate the simulation. Simulation functions are triggered via the doStep method, which may invoke injectInput from MS4Me to deliver inputs or otherwise call simulateIterations to execute subsequent simulation steps.

FMU instantiation and function calls let the FMU interface with the simulator. The model’s internal transition triggers the doStep function, using the time advance value as the next communication point. This approach enables the DEVS model in the FMU to act as a single atomic unit, ensuring events follow global simulation time through closure under coupling.

5. Operations on DEVS Model Structure

5.1. Flattening and Its Inverse, Deepening

Flattening in DEVS refers to a structural transformation that eliminates the nested layers of coupled models, resulting in a single-level coupled model [31,38,39,40]. This process begins with a hierarchical coupled model, traverses its decomposition tree, and reconstructs all inter-component couplings so that each leaf atomic model is connected directly to the top level. The outcome is a flat coupled model whose external interface remains consistent with the original but does not require hierarchy navigation during runtime. Closure under coupling is key to proving the flattened model is equivalent to the original. Flattening can have significant execution advantages primarily through reducing inter-component message traffic and removal of intermediary components [3,76,77,78,79].

Flattening is illustrated in the example of Figure 15 where on the left of the arrow, models A and C are coupled through their enclosing models AB and CD. The flattened version is show on the right of the arrow where all the components are atomic models and A is directly coupled with C.

Figure 15. Flattening illustration. (a) Hierarchical model (left) (b) flattened (right).

Here the couplings are direct from one component to another rather than travelling through hierarchical levels while retaining the identical port-to-port connections.

As with the join operation of relational data tables, the operation of merging couplings is illustrated in Figure 16.

Figure 16. Illustration of the basic step in the flattening operation. (Top) In the original structure, component C1 sends message x to component C2 which transmits it to subcomponent C3. (Bottom) In the flattened structure, component C1 sends message x directly to C3 which is now at the same level as C1 since C2 is eliminated and replaced by its children,.

Ref. [25] provides an algorithm for flattening that represents the topology of connectivity through coupling matrices from each component model, merging them into a global coupling–structure matrix. It then generates the flattened coupling–structure matrix through depth-first search or matrix operations such as transitive closure. However, this approach abstracts away the ports involved in the couplings which must be restored in a subsequent phase that was not considered by the authors. Here we provide an efficient algorithm that works directly on the hierarchical model’s composition tree, as illustrated in Figure 15b. As sketched below, the approach is to form a recursion whose basic step is to remove a coupled model from its parent and replace it with its components inserted into its parent’s composition as well as couplings to the parent and its other children that represent the concatenated couplings, as in Figure 16. The recursion proceeds by finding a coupled model to eliminate in this manner until no such models are left. The process repeats until all coupled models are eliminated. In a straightforward recursion, it can proceed level by level through the composition tree, restructuring by eliminating the coupled models it encounters in a top-down manner. Interestingly, since the tree structure is transformed into the process, the recursion remains focused on the root node while the flattened versions of the successively shallower structure are created underneath it. The computational complexity ranges from constant to exponential in tree depth as it depends on the tree’s growth behavior. However, unless the simulation involves dynamic restructuring, the flattening operation is performed only once while saving numerous hierarchy traversals that would be needed during runtime.

Flattening Algorithm Sketch

flatten(CoupledModel) perform a “flattening” operation on a hierarchical coupled model by successively flattening one level of hierarchy: replace all children coupled models with their children so that the parent’s grandchildren become its children and adjust all associated couplings accordingly.

Basic Step: flattenChild(CoupledModel, child) eliminates the coupled model’s child and reconnects its grandchildren to become direct children of the coupled model following the procedure illustrated in Figure 16.

Recursion: flattenChildren(CoupledModel) calls the basic step, flattenChild for each of its non-atomic children. In Java, the operations are performed on a copy of the tree which is then used for the next round. This is to avoid concurrent operation due to the ongoing structural changes.

Termination: The process stops when there are no coupled models with non-atomic model children left. Termination is guaranteed since the tree is finite and the non-atomic nodes (coupled models) are visited exactly once. The process stops when there are no coupled models with non-atomic model children left. Termination is guaranteed since the tree is finite and the non-atomic nodes (coupled models) are visited exactly once.

5.2. Deepening

Deepening of a hierarchical model is an inverse operation to flattening in which several components are grouped to form a single coupled model with the coupling amended to preserve the model’s behavior. Coupling between components that have become separated by a partition boundary must now be refactored accordingly. This can be visualized in Figure 16 where instead of working from top to bottom, we rewrite the coupling at the bottom to a new pair on the top, where a new port is introduced to mediate the flow from source to the destination. Deepening can be a fundamental process in creating modules where components are grouped into higher-level coupled models according to criteria related to design considerations. This is another area for future research as discussed in Section 7.

5.3. Implications of Flattening for Design of DEVS Models and Simulators

Although flattening can have significant execution advantages, it also has downsides that must be considered. Because flattening removes intermediate coupled models, the loss of critical information increases the cognitive complexity for understanding system behavior. As a result, it can be more challenging to gain insight during verification and validation (V&V) and to quickly identify errors. Similarly, there is less data available for visualizations unless additional logging is implemented, which may slow down the process. A balanced approach may be best: decompose hierarchical models for distribution across nodes and then flatten those assigned to nodes for local execution. We revisit this issue in the discussion of future research (Section 7).

6. DEVS Closure Under Coupling in Relation to Other System Formalism/Frameworks

In this section, we examine DEVS closure under coupling in relation to notions in other formal frameworks that exhibit closure properties under various operations. We will see that DEVS closure under coupling is unique in several ways including its origin in mathematical systems theory [80], its basis for a rigorous method to interpret a coupled model as a basic DEVS model (Section 2), and for definition of an associated abstract simulator (Section 3).

6.1. Wymore’s Mathematical Systems Theory

A. W. Wymore’s work [81,82,83] significantly advanced systems theory, especially in model-based systems engineering, by rigorously formulating the concept of closure under coupling for dynamic systems. His formulation showed that coupled dynamic systems could transform into an equivalent atomic system within the same framework, promoting modularity. Wymore’s precise mathematical foundation supported complex system design and analysis, as detailed in his book, Model-Based Systems Engineering [82]. DEVS as shorthand for specifying a class of Wymore’s systems provides an important computational basis for Wymore’s theory that was heretofore missing. Although related concepts existed in cybernetics, control theory, and automata theory, Wymore’s treatment was one of the earliest and most rigorous. Pioneers such as Norbert Wiener [84] and Ross Ashby [85] dealt extensively with the composition and interconnection of systems. Although their work did not use the same formal language or focus explicitly on “closure under coupling” as later defined by Wymore, they did analyze how systems interact and how their collective behavior could be understood as part of a unified whole.

6.2. Automata Theory and Formal Languages

In automata theory [86], the class of regular languages is closed under operations such as union, concatenation, and Kleene star. Each of these operations corresponds to a coupling of finite automata that individually accepts a language, and proof of closure is obtained by showing that the resulting composite is still a finite automaton. In that sense, the proof of closure for DEVS is a generalization of the related automata theory concept. In fact, it can be shown that interpreted as DEVS models, the set of finite state systems is closed under coupling [14].

6.3. Process Algebras (e.g., CSP, CCS, π-Calculus [87,88])

Process algebras offer methods for describing systems through the parallel and sequential composition of processes. By combining individual processes, a new process is created that conforms to the algebra’s semantics. This combination often remains implicit, with the resulting system requiring additional semantic elements such as synchronization or communication channels. DEVS extends this concept by allowing the coupled system to be explicitly reconstituted as a basic DEVS model. This explicit conversion provides a formal guarantee that enhances DEVS’s suitability for hierarchical modeling, enabling simulation engines or analysis tools to handle a coupled system as a single unit in appropriate contexts.

Petri Nets and Other Graph-based Formalisms [89,90,91,92,93]

When connecting Petri nets, the resulting network is often still a Petri net with the same properties (places, transitions, tokens). However, while compositional methods exist, the transformation from a network of coupled nets into a “single net” is not always as straightforward or canonical as it is in DEVS. The DEVS closure property guarantees that every coupled model can be transformed into an equivalent basic DEVS model by a systematic procedure. This kind of formal “flattening” of the structure is not as universally available or as well-defined in all other modeling frameworks. Moreover, the inclusion of elapsed time as a fundamental state variable in DEVS (Section 2.1) is salient as the missing concept in Petri nets limited compositionality.

Control Theory and Linear Systems [80]

In control theory, the interconnection of linear systems results in another linear system. This closure property under interconnection is crucial for analyzing complex control loops. As with finite-state systems, linear systems constitute a class of Wymore systems and can be specified as special cases of DESS and DTSS (Section 2.2).

Although both share this idea, DEVS addresses discrete events rather than continuous dynamics. The DEVS framework’s advantage is its ability to represent a highly interconnected network of discrete-event systems, which may operate with asynchronous timing and event-driven transitions, as a single, well-defined DEVS model.

In summary, many formal frameworks exhibit closure properties under various definitions and operations to ensure that the system’s integrity is maintained. DEVS closure under coupling stands out because it not only tells us that the composition remains within a “system” class but also provides a rigorous method to reconstruct the coupled system as a DEVS atomic model and an associated abstract simulator. This unique feature reinforces the utility of DEVS in modular and hierarchical modeling, making it easier to build, analyze, and simulate complex discrete-event systems.

7. Discussion and Directions for Research

7.1. Hierarchical Modular Construction and Multi-Resolution Modeling

Sisti [94] was an early recognizer of the need for moving away from the desire for a single comprehensive model. He concluded that modeling of large-scale and complex software systems requires multi-resolution modeling, i.e., following a convention of multiple levels of representation, such that the entities are modeled at varying levels of detail, ranging from the top-level representation of the “essence” of the entity to the lowest level, which would model the entity in great detail.

Multi-resolution modeling [10,44,47,51,61,78,95,96,97,98,99,100,101,102,103,104,105,106] must bring to bear a variety of technical, theoretical, and practical aspects, including modularity, software reuse, object-oriented design, a hierarchy of models in a component library, and a model management system for manipulating such repositories. Anticipating later directives, Sisti concluded that an approach to modularization must be developed in which modules interact through defined interfaces, protecting implementation details via data abstraction and encapsulation. He saw the benefits of modularity as follows:

• Simplified development and maintenance through smaller, manageable modules and clear focus on core functionality.
• Support for parallel development with controlled interactions among collaborators.
• Enhanced testing, verification, and validation [107,108,109,110,111,112,113,114,115] of system components.
• Flexible hierarchical modeling allowing representation at different levels of detail.
• Improved software reuse, enabling standardized models and libraries for future applications.

Further, Sisti predicted that despite obstacles, pursuing modularity and reuse is essential for building valid, acceptable large-scale battlefield simulations, emphasizing their implications in combat simulation and recommended areas of research meriting increased investigation [116,117,118,119].

7.2. Empirical Applications and Validation of DEVS Support for Interoperability

This paper shines light on the potential for well-defined universal interoperability conditions for models and simulations. That is, if any DEVS-like system can be represented uniquely as a DEVS input/output system, as shown by DEVS universality and uniqueness (Section 2.1). Further, if DEVS systems, whether atomic or coupled, can be joined by additional couplings, as shown by DEVS closure under coupling, then DEVS can be used as a universal framework to integrate any combination of DEVS-like systems. If adopted, such a framework would have great value to the simulation community. Meanwhile, the DEVS community has been hard at work using DEVS in challenging environments while also integrating simulation models and frameworks into their architectures. In fact, the DEVS simulators in these projects are all remarkably similar to the DEVS abstract simulator described in Section 3. Thus, this fundamental DEVS concept is surprisingly simple yet offers potential for provable interoperability universally across DEVS-like systems. Examples of simulation projects that have employed DEVS as a unifying framework are given in Appendix E F, along with examples of implementations of the DEVS simulation protocol that establish its utility as a basis for a universal metalevel standard.

Research is needed to build on the foundation presented here to formalize the necessary and sufficient conditions for simulation interoperability and to establish a detailed engineering process, supported by appropriate tools, for systems engineers engaged in federation development. A persistent challenge lies in ensuring that federated models remain valid and effective when applied to new contexts. Validation in one domain does not guarantee suitability in another, which means additional steps are required to compose reliable and trustworthy federations. Specific directions are outlined in the sequel.

7.3. Formal Theory Extensions

7.3.1. Extending Closure Under Coupling Theory and Applying It to Important Classes of Models

Research can be done to extend DEVS closure to hybrid co-simulations that mix discrete event, discrete time, and continuous subsystems. Appendix F reviews the literature on closure under coupling in DEVS-related system specifications, broadening understanding of its modeling and simulation implications. Similar to the squares example (Section 2.2), failure of coupling closure suggests a need for more flexible definitions or additional dimensions. In this paper, closure is emphasized as supporting hierarchical modular model construction, ensuring well-definition, composability, and reuse.

7.3.2. Exploiting Uniqueness of DEVS Representation for Basic Building Blocks

The uniqueness of DEVS representation for DEVS-like systems generalizes to the hierarchy of system specifications and morphisms [50,114,115,116,120], offering a foundation for defining building blocks and architectural patterns that can be replicated and reused in system development. Research can focus on identifying such elements and establishing their status as minimal realizations of their defined behaviors. These minimal designs provide computational advantages and must underpin any implementation of the corresponding behaviors. Future research may explore methodologies for extending DEVS building blocks and architectural patterns, particularly for applications in Internet-of-Things (IoT) and Cyber-Physical Systems [37,121,122,123,124,125,126,127,128,129,130,131].

7.4. Support for Model and Simulation-Based System Engineering

DEVS support for collaborative simulation can enable domain experts and modelers to work together to build, integrate, and simulate models, often facilitated by web-based environments, middleware, or shared libraries of reusable models [6,16,17,18,19,20,21]. In this context, research is needed to address the challenge of integrating models developed in different tools by providing a common framework for collaboration and model exchange, leading to more realistic and comprehensive simulations.

DEVS can be combined with Wymore’s mathematical systems design theory (Section 6) to provide a scientific basis for Model-Based Systems Engineering (MBSE) [14,27,94,132]. In the context of MOSA, DEVS hierarchical coupled models can faithfully represent System-of-Systems architectures and provide cost and performance feedback for iterative design alternatives executed in experimental frames defined by Wymore’s levels of system design. This approach supports continuous simulation-based testing, verification, and the creation of executable MBSE Digital Twins, enabling persistent simulation across the entire system lifecycle, early error detection, reduced development risks, and seamless transition from design models to real-world implementation [133].

Research can further explore the following:

• Generalizing co-simulation frameworks to hybrid systems, reexamining the general concept without reference to FMIs. A DEVS simulator can execute in synchrony with an HLA federation where each can share global state variable data with the other. Problems not yet mentioned are the quantized state representation of continuous trajectories [134,135,136,137,138,139,140,141,142,143,144,145] and the location of state events [146] in coupling of hybrid component. Camus [59] presents a co-simulation framework employing the universality of DEV&DESS and its formally defined approach to locating state events in differential equation components attaining the capability to modify event-detection functions and to handle discrete internal transitions. The Heterogeneous Flow System Specification [26,147] provides a more general approach that is not fully integrated within DEVS, limiting its effectiveness. Research is needed to identify modes of global state sharing that are effective and efficient where non-modular models possibly expressed in different formalisms are involved as they are in hybrid systems.
• Implementing DEVS simulations using data distribution middleware, mapping message semantics to Quality of Service (QoS) profiles and event streaming systems such as Kafka, while ensuring causal delivery, latency guarantees, and backpressure handling.

7.5. Flattening and Deepening

Research can be conducted to help to deal with the issue of retaining the benefits of flattening while mitigating against the loss of information that it entails. As summarized in Table 5, flattening of hierarchical structure has consequences in multiple aspects that rely on such structural knowledge. Typically, dynamic structure change involves components and couplings at their locations in the original hierarchical structure [148,149,150,151]. In the absence of such information, it may be complicated to implement dynamically changing models or those requiring frequent updates. Similarly, modular components are generally easier to reuse across different models. Similarly, partitioning flattened models for parallel [152,153,154,155,156,157,158,159,160] or distributed simulation [161,162,163,164,165,166,167,168] may be more complex due to the reduced modular boundaries, affecting load balancing. In the absence of hierarchy, supplementary metadata or annotations are needed to convey the original design intent. Concerning scalability, flattening typically results in a combinatorially greater number of direct couplings, possibly increasing memory consumption and computational requirements during initialization. Research is needed to identify and provide tools for recovering the initial modular structure such as maintenance of comprehensive data throughout the transformation process [169].

Table 5. Drawbacks of flattening.

Aspect	Drawbacks
Information Retention	Loss of critical design information from intermediate models; less intuitive for human analysis.
Verification & Validation (V&V)	Greater difficulty in gaining insight during V&V; harder to quickly identify errors.
Visualization	Less data available for visualizations unless extra logging is added, which may slow performance.
Computation for Flattening	Potentially computationally expensive flattening algorithms, especially for deep hierarchies.
Dynamic Structure Change	Complex-to-implement dynamic changes without original hierarchical location data.
Reusability	Reduced modularity making components harder to reuse across models.
Parallel/Distributed Simulation	Greater complexity in partitioning for parallel/distributed execution; reduced modular boundaries hindering load balancing.
Design Intent	Requirement of supplementary metadata/annotations to convey original design intent.
Scalability	Potential creation of combinatorially larger number of direct couplings, increasing memory and initialization costs.
Reconstruction of Hierarchy	An ability to uniquely recover original modular structure without comprehensive metadata.

As discussed above, deepening as the inverse of flattening trades visibility for abstraction and is powerful for modularity, reuse, and scalability. However, it requires discipline in documentation and validation to avoid hidden complexity. As with flattening, research can be performed on clarifying and tool development, as illustrated in Table 6 that captures the benefits and drawbacks of deepening in hierarchical DEVS modeling:

Table 6. Deepening in hierarchical models—benefits vs. drawbacks.

Aspect	Benefits of Deepening	Drawbacks of Deepening
Abstraction and Clarity	Groups related components into a higher-level coupled model, improving conceptual clarity and modularity.	May obscure fine-grained details, making debugging or tracing individual component behavior harder.
Reusability	Facilitates reuse of coupled subsystems as encapsulated modules in other models.	Over-encapsulation can reduce flexibility if frequent modifications to internal components are needed.
Maintainability	Simplifies top-level model structure by reducing the number of visible components.	Adds complexity to the hierarchy, requiring careful documentation to avoid confusion.
Scalability	Supports scaling by organizing large systems into manageable subsystems.	Excessive nesting can lead to deep hierarchies that are difficult to navigate and maintain.
Behavior Preservation	Uses coupling amendments to ensure that the overall system behavior remains consistent after grouping.	Risk of introducing coupling errors or unintended side effects during restructuring.
Decision Support	Provides a structured view of system evolution, useful for teaching, analysis, and standards alignment.	May require additional reasoning steps to validate equivalence with the flattened version.

Of course, as two sides of the same coin, research may examine both deepening and flattening operations together to address the identified issues in a unified way.

7.6. DEVS Standard for Interoperable Simulation Modules

Continued research is needed to develop a robust DEVS standard for interoperable simulation modules. A multi-pronged research agenda needs to be pursued that bridges formalism, middleware, tooling, and community adoption. As suggested above, the ability to wrap legacy simulation engines in DEVS-compliant shells is critical to enabling reuse without full rewrites.

A summary of the main challenges in developing a DEVS standard for interoperable simulation modules appears in Table 7.

Table 7. Challenges in developing a DEVS standard for interoperable simulation modules.

Type of Challenge	Description
Support for Experimental Frames	Support for specification of experimental frames is essential to facilitating the sharing, reuse, and management of DEVS models and simulation experiments within the modeling and simulation community, promoting collaboration and reducing redundant efforts.
Semantic Divergence	There are variations in lifecycle semantics and behavior across DEVS implementations and a lack of formal equivalence between DEVS variants (classic, parallel, etc.).
Platform & Language Interoperability	Diverse programming languages and environments complicate module exchange; middleware and adapter design must preserve DEVS semantics.
Tool Development & Infrastructure Gaps	Unified model formats, graphical editors, and debugging tools are absent, limiting usability and adoption across domains.
Testing & Certification	There is no standard benchmark suite or compliance criteria; distributed execution introduces synchronization and rollback complexities.
Community & Governance	Fragmented research communities and legacy systems resist change; balancing extensibility with strict interoperability is politically and technically complex.

This agenda can be carried out along the following lines:

7.6.1. Continuing Research in Tool Development and Language Interoperability

To facilitate DEVS module integration across various programming languages such as Python, Java, and C++, it is essential to develop adapters that bridge these environments. Establishing neutral serialization formats such as JSON and XML will further support cross-platform DEVS model exchange. Additionally, exploring the development of editors capable of generating standard-compliant DEVS code and metadata can enhance usability. Defining machine-checkable interface contracts for DEVS components—including specifications for types, timing guarantees, and exception semantics—will enable the auto-generation of adapters, ensuring seamless interaction among heterogeneous simulation units.

7.6.2. Continuing Validation, Benchmarking, and Use Case Development

To advance the standardization and practical adoption of DEVS-based simulation modules, it is crucial to develop benchmark models explicitly designed for interoperability testing across widely used tools such as CD++, DEVSJava, and DEVSimpy. By applying the emerging DEVS standard to diverse application domains—including satellite networks, cyber–physical systems, and command-and-control simulations—researchers can rigorously evaluate the framework’s versatility and effectiveness. Furthermore, specifying robust metrics for model reuse, execution accuracy, and integration effort will provide a quantifiable means to assessing the value and maturity of DEVS implementations. This approach not only facilitates objective comparison among different tools and domains but also drives improvements in usability, reliability, and the seamless integration of heterogeneous DEVS modules.

7.6.3. Continuing Integration of DEVS into M&S Community and Standards

To achieve broader compatibility and foster robust interoperability in simulation module development, it is essential to continue to align the DEVS framework with widely adopted standards such as HLA (High Level Architecture) [5,37,57,58,59] and FMI (Functional Mock-up Interface) [73,76,77,78,79,80]. Maintaining an open-source, modular DEVS engine as a reference implementation will serve as a foundational tool for the community, promoting transparent validation and extensibility. Furthermore, establishing a consortium dedicated to overseeing DEVS standardization, regular updates, and certification processes will help unify fragmented research efforts and ensure the consistent evolution and adoption of interoperable DEVS-based simulation modules.

7.7. Towards a Framework for Modeling and Simulation Complexity

Understanding and managing complexity, critical for the effective design and execution of DEVS-based simulations, constitute an area of research that is needed for further development. Complexity can be analyzed at three complementary levels:

Simulation execution complexity [80] emphasizes the computational efficiency of the simulation engine and its runtime behavior. It is shaped by factors such as the efficiency of event scheduling mechanisms—whether priority queues, calendar queues, or other structures—the computational cost of evaluating transition functions for internal, external, or confluent events; and the overhead introduced by message passing and synchronization among components, particularly in modular or distributed models.

Descriptive complexity [14] reflects the cognitive and informational load inherent in the model itself, independent of execution. It encompasses the richness of information represented, the resolution of state variables and time discretization, the trade-offs between output detail and abstraction, and formal measures such as Kolmogorov complexity, which captures the minimum description length of the model’s representation [90].

Structural complexity, viewed from an architecture-centric standpoint [13,32], concerns how the organization of model components influences both computational performance and reusability. It is affected by the density of couplings between components, the synchronization overhead arising from interdependencies, and the balance between modularity and performance. As discussed above, while modular structures enhance clarity and reuse, they may also increase execution costs, particularly in flattened or distributed implementations.

Research into these three dimensions—execution, descriptive, and structural—is needed to help modelers to systematically assess the trade-offs involved in DEVS model design, enabling optimized simulation performance, maintainable modular structures, and accurate representation of complex systems.

8. Conclusions

This paper has demonstrated that DEVS, as a computational basis for mathematical systems theory, provides the essential conceptual and technical foundation for advancing modeling and simulation (M&S) research. By enabling scalable, modular, and interoperable representations of complex systems, DEVS ensures consistency, efficiency, and reusability across a wide range of applications. Unlike many formal frameworks that exhibit closure properties to maintain system integrity, DEVS closure under coupling also offers a rigorous approach to representing a coupled model as a DEVS atomic model with an abstract simulator. This distinctive capability strengthens the modularity and hierarchical structure of DEVS, simplifying the process of building, analyzing, and simulating complex discrete-event systems, while supporting consistency, efficiency, and reusability across diverse applications.

At its core, we have shown how DEVS theory offers a mathematically rigorous framework for modeling, simulating, and integrating complex systems. We have emphasized how its defining mechanisms—closure under coupling, modularity with hierarchical modeling, and universality with unique representation—collectively support the construction of robust, efficient, and scalable simulation architectures. These principles standardize the treatment of complex models and underpin advanced integration strategies, including the Modular Open Systems Approach (MOSA), which is becoming increasingly critical for software-intensive and cyber–physical systems.

The exploration of open research areas underscored a clear imperative: future M&S research should be grounded in the principles of DEVS and systems theory. Building upon this foundation enables the systematic management of complexity, ensures composability of models, and enhances capabilities in distributed and hybrid simulation. This approach lays the groundwork for more reliable, extensible, and efficient modeling of heterogeneous cyber–physical systems.

Promising avenues for theory-driven research include extending closure under coupling to new classes of models, leveraging the uniqueness of DEVS representation to identify fundamental building blocks across modeling domains, generalizing co-simulation frameworks to support hybrid systems within model-based systems engineering (MBSE), and clarifying the roles of flattening and deepening in hierarchical model management.

Looking forward, DEVS theory will be indispensable in establishing standards for interoperable simulation modules, tool and language interoperability, validation and benchmarking practices, and integration into the broader M&S community. Its mathematically rigorous framework provides both the necessary and sufficient foundation to ensure reliable, reproducible, and extensible simulation results across complex, heterogeneous systems.

Caveats and Limitations: Reviewers have noted that the case for DEVS-based approach to simulation interoperability advocated here has not been supported by empirical evidence derived from actual case studies. Indeed, to our knowledge, no study exists—nor have we offered one—that provides metrically based empirical evidence that DEVS provides a better interoperability solution than do other approaches. Instead, we argue that DEVS, through its universality, uniqueness, and closure under coupling, provides a foundation for universal interoperability across diverse modeling and simulation systems. This is especially valuable given the proliferation of standards in domains such as space and defense, where organizations such as NATO and SISO and partial standards such as Modelica and FMI exist, as discussed above. This diversity shows the need for a unifying meta-standard to align simulations across various standards. Demonstrations in military and systems-of-systems contexts show that DEVS frameworks can interoperate with standards such as HLA, WebLVC, and FMI, underscoring DEVS’s potential as a simple yet rigorous basis for provable interoperability. Accordingly, we have offered avenues for extending DEVS in the theoretical and empirical directions to realize this potential. Moreover, we have commented on the need to encourage the adoption of DEVS among communities of interest.