Simulation-Based Development of Internet of Cyber-Things Using DEVS

1. Introduction

Internet of Cyber-Things (IoCT)  [1] refers to systems designed within the paradigms of Internet of Things (IoT), emphasizing the the connectivity of devices ("Things") with robust, cyber-enabled control over physical processes (CPS).

The combined paradigm recognizes that an internet backbone not only connects devices but can actively manage and control physical systems in real time [1]. The combination suggests the overarching goal of a seamless integration and coordination of smart devices, bolstered by advanced cyber capabilities that control and optimize physical dynamics [1]. In such a network, digital and analog information flows through channels between sensors and effectors under the control of computational intelligence [1,2].

Simulation-based development involves creating virtual models of a system to study its performance, behavior, and potential failure modes under different conditions. By simulating the system, designers can iterate rapidly on design choices, validate functionality, and optimize performance. Through detailed simulation, designers gain insights into how cyber components (software, network protocols) and physical entities (sensors, actuators) interact, ensuring that real-time constraints and performance requirements are met. Such simulation also allows for comprehensive testing under varied environmental conditions and scenarios, mitigating the risk of failure when the system is deployed in the real world. When simulation is employed early in development, the high costs of early-stage physical prototyping can be minimized or even eliminated, reducing the need for expensive physical prototypes with associated development costs and potential downtime.

Simulation-based development addresses the role of communication and control in IoCT by representing interactions such as sensor data transmission, actuator commands, and control logic as streams of discrete events. Simulation supports examining how data flows through the network and how control decisions are made in real time, which is crucial when merging the loosely coupled nature of IoT with the stringent requirements of CPS. By running simulations, developers can subject the system models to various challenges including communication delays, system failures, and unexpected physical process behaviors. These simulations help to identify potential bottlenecks or design flaws, enabling iterative refinements before actual hardware deployment.

We propose that essential requirements for a language to support the development of IoCT systems are model expressiveness and model continuity for all stages of the process including design, simulation, and implementation (see Figure 1).

Basically, model expressiveness is the ability to express required functionality in a form that can be easily coded, simulated, and verified. Included in expressiveness is the ability to support construction of simulation models that combine discrete event logic with continuous system dynamics which is particularly useful in CPS where physical processes involve continuous variables (e.g., temperature, motion). Expressiveness also includes the ability to incrementally add or modify model components, which is especially useful as IoCT technologies continue to evolve.

Likewise, model continuity refers to the ability to transition the "same" description from stage to stage in the development process, where by "same", we mean that little or no modification is needed in such transitions. Included in continuity is capturing and handling the stringent timing requirements typical of IoCT applications, ensuring that the simulated responses closely mimic real-world behaviors.

The Discrete Event System Specification (DEVS) formalism [3] is a formal modeling and simulation framework that allows systems to be described as a set of discrete events. It offers a modular and hierarchical approach, where individual components (atomic models) can be composed to form more complex structures (coupled models). This makes it ideal for modeling both the asynchronous events of IoT devices and the real-time processes of CPS. DEVS enables component-based, hierarchical modular construction, and dynamic changes in structure to support intelligent, adaptive, and autonomous behavior characteristic of IoCT systems [4,5,6]. DEVS Atomic Models enable each IoT device or CPS component to be modeled as an atomic (independent) entity with defined states and transitions triggered by discrete events. DEVS coupling concepts connect atomic components to form coupled models that represent larger subsystems or the entire system. This hierarchy helps manage complexity and supports system evolution.

In this paper, we will show that DEVS has the necessary model expressiveness and continuity properties to serve as an IoCT Design language. We will illustrate with several examples to show wide applicability. We will demonstrate the added value of the System Entity Structure (SES) to enhance expressiveness, scalability, and flexibility in IoCT system design, making it a powerful tool for managing complexity and enabling efficient simulation and deployment.

Figure 1 illustrates the stages and the requirements for an IoCT Design Language. On the left side of Figure 1 we conceptualize an IoCT system as interacting with its environment through sensors and effectors (also called actuators), and on the right side, three basic stages of the development of such a system are shown as Design, Simulation, and Implementation. In the design stage, the focus is on system architecture, often using high-level design tools [7], with the environment and the sensor/effector interaction minimally represented. Model continuity allows transferring the designed model to be evaluated in the simulation stage and deployed in the implementation stage with minimal changes. Currently, an IoCT design language that supports these requirements is lacking [8]. On the other hand, DEVS model expressiveness is manifested in its support of hierarchical and modular model construction. These characteristics enable the implementation and verification of smaller models, which can then be coupled to form a complete model. In this process, a family of models emerges in which the models can be reused and integrated with multiple other models. Moreover, DEVS allows for the simulation of these models alongside in the context of previously constructed models that can apply to both discrete-event and continuous systems [9]. Furthermore, DEVS supports model continuity in which only the simulator needs to be changed to run from abstract time to real-time [10,11] while the model remains substantially the same.

Figure 1. Stages and the requirements for an IoCT Design Language. The DEVS formalism provides the model expressiveness needed for IoCT functional design and supports the model continuity needed to transition from stage to stage.

Figure 1. Stages and the requirements for an IoCT Design Language. The DEVS formalism provides the model expressiveness needed for IoCT functional design and supports the model continuity needed to transition from stage to stage.

The remainder of this paper is organized as follows. Section 3 provides a review of the DEVS formalism and the SES, which serve as foundational frameworks for the modeling and simulation (M&S) of complex systems. Section 3 presents requirements for IoCT design and development and summarizes how DEVS serves as a language to help users address these requirements.

Section 4 presents a series of illustrative examples demonstrating the application of DEVS in designing IoCT systems. These examples include: home automation, the CAIDE architecture, the Actuation Conflict Management (ACM) framework, and swarm-based systems. Section 5 offers a discussion on how the presented examples highlight the expressiveness of DEVS for capturing dynamic and complex behaviors and its continuity in seamlessly transitioning simulation models to real-world implementations. It also compares these features with those of other widely used formalisms.

Finally, Section 6 concludes the paper by summarizing the key findings and discussing limitations of DEVS-based IoCT system design. It then discusses how model-driven engineering can help address such limitations. Finally, we outline future directions for further leveraging DEVS in IoCT system design.

2. Background in DEVS and SES

DEVS Atomic and Coupled Models specify Mathematical Systems [12], one of the earliest forms of general system specification that combined both the automaton formalism of computer science and the dynamic systems models of control theory [13]. DEVS Atomic model specify the dynamic input/output and state behavior of atomic components (elements that are not further decomposed in the model).

DEVS Coupled models include components and their couplings - connections from output ports of components to input ports of other components. As illustrated in Figure 2, component models can themselves be coupled models (as well as atomic models) leading to hierarchical structures. Closure under coupling of DEVS models is an important theorem that justifies the confidence in managing the complexity of hierarchical models. The theorem states that the resultant of coupling well-defined DEVS models is itself a well-defined DEVS model, i.e, is equivalent in its input/output behavior as a DEVS atomic model [3]. As we will show, such Hierarchical Modular Composition supports the model construction needed for development of IoCT systems.

The System Entity Structure (SES) is a declarative knowledge representation scheme that characterizes the structure of a family of models in terms of decompositions, component taxonomies, and coupling specifications. Formalized by a set of axioms [11], the SES is used to define and construct hierarchical modular DEVS models. As an ontology for M&S, it concentrates a relatively few basic relations as follows:

• Aspect expresses a way of decomposing a system into components and is relation between the parent and the children. For instance, IoCTSmartApp in Figure 3 is an entity composed of Sensors and Actuators. Sensors and Actuators are each represented as components (called multi-entities) that are decomposed into one or more Sensor and Actuator, respectively. An aspect holds the coupling relations that will connect the components (children) to create a coupled model for the parent. An entity that has no aspects (decompositions) is the smallest indivisible element and is represented by an atomic DEVS model.
• Specialization expresses the variants that a component can assume within a decomposition. Smoke detector, WaterLeakageDetection or ThermalSensor can replace any of the Sensors and Smartphone, WindowController or AirConditioner can replace any of the Actuators in Figure 3.

The corresponding constrained natural language of the SES description depicted in Figure 3 appears as follows:

From the IoCTDecomp perspective, IoCTSmartApp is made of Sensors and Actuators!

From the SensorMult perspective, Sensors is made of more than one Sensor!

From the ActuatorMult perspective, Actuators is made of more than one Actuator!

Sensor can be SmokeDetector,WaterleakageDetection,or ThermalSenor in SensorType!

Actuator can be Smartphone, WindowController, or AirConditioner in ActuatorType!

Figure 3. IoCT smart App SES design. Sensors and Actuators are defined as specialization. A sensor entity can be smoke detector or thermal sensor. A actuator can be smartphone or air conditioner.

Figure 3. IoCT smart App SES design. Sensors and Actuators are defined as specialization. A sensor entity can be smoke detector or thermal sensor. A actuator can be smartphone or air conditioner.

The SES specifies hierarchical coupled models and makes it easier to create them. Indeed, tools exist that help users define SES’s in a constrained form of natural language as well interfaces to prune such models [11]. A specific model is chosen from the SES family of models by selecting from the available choices in a process called pruning. This results in several Pruned Entity Structures (PES), which can then be automatically converted to simulatable DEVS models, thus enabling comparison of alternative architectures [14].

Two other properties of DEVS are applicable to IoCT system design and will be expanded on later:

• DEVS Universality: DEVS models can represent a wide variety of system types including continuous, discrete, finite state, etc. [15]. For instance, when addressing actuation and other service access conflicts in IoCT systems, the rules managing such conflicts are typically specified using particular formalisms. For example, ECA (Event-Condition-Action) rules are widely used for high level specification of controllers in Cyber-Physical Systems and smart environments composed of devices equipped with sensors and actuators. Due to the DEVS universality these description formalisms can be expressed in DEVS models and integrated with other components in a composition hierarchy.
• Dynamic Structure DEVS: a type of DEVS model that can change its own structure while running [16,17]. The ability to change a model’s structure during its simulation is highly interesting in the IoCT domain, where a system can update the list of available devices (sensors or actuators) upon discovering a new context.

3. Requirements for IoCT Design and Development

The identified traits of the DEVS formalism—modularity, event-driven behavior, concurrency, adaptability, scalability, and model continuity—are essential and sufficient for dealing with the complexities of IoCT systems design and development. IoCT systems are inherently heterogeneous, with diverse devices and components that must interact seamlessly. IoCT systems are characterized by several critical requirements:

• Heterogeneity: IoCT systems typically comprise a diverse array of devices, sensors, and actuators, each with distinct communication protocols, data formats, and computational capabilities. An effective modeling formalism must accommodate this heterogeneity and enable seamless interaction between these diverse components.
• Real-Time and Event-Driven Behavior: Many IoCT applications require real-time processing of sensor data, with decision-making based on specific events. For example, a smart thermostat must respond immediately to temperature fluctuations, while a smart city traffic management system must process sensor inputs in real time to optimize traffic flow.
• Concurrency and Synchronization: The dynamic and distributed nature of IoCT systems often necessitates the concurrent operation of multiple devices or subsystems. These devices must interact and synchronize effectively to ensure that the system operates cohesively, without conflicts or performance degradation.
• Adaptability: IoCT systems must be able to adapt to changing environmental conditions, such as the failure of components, the introduction of new devices, or network disruptions. A modeling approach must therefore support flexible system structures capable of responding to such dynamic conditions.
• Scalability: As IoCT systems grow in size and complexity, the ability to scale the system without introducing instability or performance issues becomes critical. A modeling formalism must support scalable architectures that can accommodate the addition of new components or the expansion of existing ones.
• Model-to-Execution Continuity: An IoCT system must transition smoothly from the design phase to the simulation and execution phases. This requires that the behavior modeled during the design phase is accurately reflected in the real-world execution of the system.

DEVS’s modular and hierarchical approach addresses this heterogeneity by enabling the design of complex systems as compositions of simpler, reusable models. Furthermore, IoCT systems often require real-time responses to sensor data, and DEVS’s event-driven nature allows it to model the time-based behaviors that are critical for such applications. The ability of DEVS to handle concurrent events and synchronize multiple interacting processes makes it ideal for modeling the distributed, concurrent nature of IoCT systems, where multiple devices must operate in parallel and remain synchronized. Additionally, IoCT systems must be adaptive to changing conditions, such as device failures or network disruptions, and DEVS supports dynamic model structures that allow for this flexibility. DEVS also facilitates scalability by allowing models to grow incrementally, an important feature for large-scale IoCT systems. Finally, DEVS’s model continuity ensures that the system’s behavior remains consistent throughout the development lifecycle, from design to simulation and real-world execution. This continuity is crucial for ensuring that IoCT systems perform as intended when deployed.

Secondary studies on IoCT systems highlight these same traits as essential, reinforcing that DEVS’s modularity, real-time event handling, concurrency management, adaptability, scalability, and smooth transition across stages are not only sufficient but minimal for modeling IoCT systems effectively. While other formalisms, such as state machines, Petri nets, and UML, may address some aspects of IoCT design, they lack the comprehensive support for concurrency, event-driven behavior, and model continuity that DEVS offers. Thus, DEVS provides a robust and minimal set of traits that make it an ideal candidate for IoCT system design and simulation.

4. DEVS Design Principles for IoCT Systems: Practical Examples

This section is dedicated to presenting several examples highlighting the enhanced expressiveness and continuity offered by DEVS in the field of IoCT systems.

4.1. DEVS Architecture for Home Automation

Faizel and Wainer [9] provide a DEVS specification of a home automation architecture, validated through a case study integrating multiple sensors and actuators. They developed DEVS atomic models for the different functional aspects that are required such as sensor polling, data transmission, and data-sharing algorithms, which were then combined into a complete coupled model for execution on devices. A communication network of nodes was designed as a next level coupled model to integrate the device component models. DEVS-based simulations showed the desired behavior, which was to effectively combine sensor readings and exchanged messages to agree on common values. A home automation application demonstrated the practical use of their approach. The application of DEVS model continuity was manifested in their hardware construction. Using Cadmium version 2, a C++ implementation of DEVS, the C++ classes employed for simulation were flashed (deployed) on micro-controller firmware with only slight modifications in code. One exception was that the message broker model was replaced with a commercial equivalent. Details are described in [9].

In [18], the authors demonstrate the suitability of the DEVS formalism for modeling synchronous automata and verifying execution strategies in the context of IoCT system design. They validate their approach using a pedagogical case study: the development of an application to control room lighting. In this work, the behavior of a DEVS model is represented as specifications of a finite state automaton. However, these DEVS specifications encapsulate both the state automaton and the execution machine. The key advantage of using DEVS lies in its flexibility to define multiple strategies through distinct DEVS model specifications.

The traditional IoCT system design process typically involves: (i) defining the behavior of IoCT components in a library (ii) designing the coupling between components in the library and (iii) executing the resulting coupling. If errors are detected, the designer must redefine component behaviors, particularly those of the execution machine, to handle time conflicts within the ambient system.

In [18], the authors proposed an alternative approach based on DEVS M&S. Instead of waiting until the implementation phase to identify potential conflicts, they introduced an initial phase where the behavior of IoCT components and execution machines is modeled and simulated using DEVS. Once the simulations yield successful results, the designer can confidently implement the system behavior within an IoCT framework. We will also discuss the advantages of DEVS in managing access conflicts in IoCT systems in Section 4.3.

We review how the features of this application illuminate DEVS mode expressiveness and continuity:

• Model expressiveness:

  –

  Employs hierarchical, modular construction to achieve incrementally verifiable functionality

  –

  Interacts with Sensors and Actuators in a dynamic environment

• Model continuity:

  –

  DEVS Simulation engine was expressed in programming language (Cadmum V2, Python) for development

  –

  DEVS models were converted to firmware for real-time execution

4.2. DEVS IoCT System: Real-time Monitoring, Management, Forecasting

Developed using the DEVS formalism, the Cloud-Based Analysis and Integration for Data Efficiency (CAIDE) framework has been successfully applied to Solar Irradiance Sensor Farms [19]. The system’s design leverages DEVS, Model-Based Systems Engineering (MBSE) [20], and an IoT infrastructure to deploy and analyze solar plants in dynamic environments. In addition to managing multiple sensor farms simultaneously, the framework continuously enhances predictive models in real time by dynamically adapting and retraining them to ensure forecasts remain accurate and up-to-date.

As illustrated in Figure 4, the system was developed as a hierarchical DEVS coupled model, featuring two primary components: Farms and cloud-based training with big data services. Each Farm comprises atomic models that perform data processing, interface with solar sensors, and coordinate through a central Fog server. The DEVS architecture allows these components to run in sequential, parallel, or distributed configurations, ensuring scalability. The working system was demonstrated in a complex scenario where multiple solar irradiance sensor farms were linked to a centralized management system, highlighting its significant implications for solar plant deployment and the future of renewable energy technologies.

As above, we review how the features of this application illuminate DEVS mode expressiveness and continuity:

• Model expressiveness:

  –

  DEVS supports expression of the CAIDE architecture which is layered with sensor, Fog, and cloud layers, consistent with IoCT Layered Architecture.

  –

  DEVS atomic models express the required temporal interaction with solar sensors.

  –

  DEVS modularity provides the flexible basis to support the variable functionality required for AI/ML analysis and retraining.

• Model continuity:

  –

  The DEVS Simulation engine was employed in Python for development.

  –

  A DEVS real-time execution engine continues to implement essentially the same model that resulted from the initial design.

4.3. Conflict Management in IoCT System DevsOps

In managing IoCT conflicts, rigorous validation is essential to detect issues by analyzing both the events generated by smart applications and the resulting actions on shared actuators. As these applications increasingly control common IoCT devices—especially actuators that produce tangible physical effects—the risk of actuation conflicts grows. These conflicts manifest either directly, when multiple applications vie for the same actuator, or indirectly, when applications influence shared physical properties.

To mitigate these challenges, actuation conflicts must be addressed during the design phase, rather than relying on end users to resolve them. The goal is to implement Actuation Conflict Management (ACM) mechanisms that proactively identify and resolve both direct and indirect conflicts early in the system’s lifecycle (see Figure 5). Validation plays a critical role in this process by simulating IoCT application events and actuator responses, ensuring that the ACM specifications remain robust and effective in real-world scenarios.

This approach work builds upon the M&S approach outlined in recent research [21], proposing a method that integrates M&S into the design of IoCT systems (Figure 5). The methodology leverages the DEVS formalism within the DEVSimPy multi-platform framework [22,23], facilitating robust and flexible system Design. DEVSimPy is an advanced wxPython cross-platform General User Interface for the M&S of systems based on the DEVS formalism. With DEVSimPy, a user can construct a DEVS model for a system by interconnecting atomic and coupled models instantiated from libraries.

Figure 5. DEVS M&S inside the custom ACM Design process with its three levels: The Logical ACM Design, Model validation and Model Deployment.

Figure 5. DEVS M&S inside the custom ACM Design process with its three levels: The Logical ACM Design, Model validation and Model Deployment.

Figure 5 shows the custom ACM Design process that include the following levels:

Figure 5 illustrates a custom ACM design process organized into three main levels:

• Logical ACM Design: At this stage, the logical properties of custom ACMs—such as completeness, safety, and liveness—are formally verified using techniques like model checking [24,25]. These ACMs are defined by the designer as finite-state machines (FSMs), forming the basis for further validation.
• Model Validation: This level assesses the impact of conflict resolution on the environment through DEVS simulation. The DEVS ACM model incorporates temporal properties (for example, event delays and state durations) derived from the ACM FSM, ensuring that the temporal behavior of the system is accurately captured.
• Model Deployment At this level, the temporal properties of custom DEVS ACMs are formally verified using various asynchronous execution machine strategies associated with the ACM FSM. DEVS formalism is employed to simulate different implementation approaches, which allows for experimentation with various hardware platforms that have unique asynchronous timing specifications. Moreover, different middleware/EDGE solutions (e.g., node-red [26] and ThingML [27]) can be explored through the automatic implementation of the DEVS simulation kernel tailored to the target middleware.

The approach described above integrates an innovative Actuation Conflict Management (ACM) mechanism that identifies and resolves conflicts stemming from spatial and temporal competition among application flows. In IoCT systems, such conflicts occur when safety properties—whether related to actuators or the environment—are violated. For example, conflicts can emerge when multiple application flows attempt to control the same actuator, thereby compromising one of its features. These conflicts are classified as direct (see Figure 6(a)) when they target a single device, or indirect (see Figure 6(b)) when application flows affect environmental properties inconsistently.

This simulation-based approach intercepts all interactions between application flows (actions) and IoCT devices (actuators) to detect potential direct and indirect conflicts. It validates resolution strategies implemented by a dedicated ACM component (Figure 6(c)).

DEVS models were utilized at an early stage of the ACM Design process, enabling simulation-based validation of the ACM mechanism prior to deployment in physical environments. The results demonstrate the expressiveness of the DEVS formalism in specifying and validating the ACM component, ensuring its seamless integration and functionality within simulated physical environments.

The ACM coupled DEVS model consists of two atomic models: a DEVS Synchronizer, which receives events from application flows and drives the evolution of the Logical Behavior based on the inputs it transmits (Figure 7).

Designers leverage a Logical Behavior model—typically represented as a Finite State Machine (FSM)—to specify conflict resolution rules through defined state transitions and output functions. An execution engine triggers these functions based on incoming inputs, producing the corresponding outputs. Although model checking is effective at validating the logical correctness of the FSM, it does not address issues related to synchronization and timing.

A robust synchronization policy is crucial to maintaining the Logical Behavior’s desired properties. The Synchronizer DEVS model manages input events from IoCT application flows by synchronizing and serializing them according to a pre-defined strategy. This strategy might involve various alternatives such as waiting for all inputs before triggering outputs, sending inputs immediately, or following specific time intervals.

Figure 8) illustrates an example of modeling a custom Actuation Conflict Management (ACM) system in a smart home environment using DEVSimPy, with a focus on conflict detection in IoCT-based smart homes. In this scenario, 216 application flows control 37 actuators—including windows, air conditioners, and lights. Conflicts occur when multiple applications attempt to manage the same actuator; for example, applications 14 and 134 simultaneously controlling the TV. In total, there are 3124 direct conflicts and 673 indirect conflicts. The custom ACM component detects and resolves both types—addressing direct conflicts (such as conflicting TV commands) as well as indirect conflicts (like ambient noise interference between the speaker and TV)—thereby validating the ACM rules.

Due to DEVS model continuity, the DEVS simulation engine was successfully mapped to middleware solutions such as Node-RED and ThingML, enabling straightforward integration with IoCT infrastructures. The objective is to support the orchestration and deployment of IoCT systems whose software components can be deployed over IoCT, edge, and cloud infrastructures. The ACM simulation model can be part of the chosen deployment solution, as the DEVS abstract simulator is portable across any platform [10,18].

Thanks to the DEVS formalism, the approach supports deployment across diverse hardware platforms with varying timing characteristics, underscoring its adaptability and portability. By leveraging the DEVS formalism within the DEVSimPy framework, this work effectively bridges the gap between simulation and practical IoCT implementations—ensuring that validation performed during the design phase translates seamlessly into real-world applications.

Another application where sensor access conflicts arise is smart parking. Smart parking systems optimize the use of parking spaces by integrating driver behavior and sensor data. A major challenge in this field is creating a robust model that can manage cumulative parking conflicts—situations where multiple drivers vie for available parking in a dynamic environment that depends on both user behavior and real-time sensor input. With modern sensor networks, parking spaces can be equipped with sensors that monitor availability in real time. In [28], the authors propose a DEVS-based Modeling and Simulation approach that develops conflict management strategies using estimated travel times to desired locations within an area. DEVS is favored for this application because (i) its explicit inclusion of elapsed time as an essential state variable and the associated time-advance function provides an effective framework for managing time advances in both simulation and real-time scenarios, and (ii) its hierarchical, modular structure supports the construction of conflict models for individual drivers that can be reused in difference scenarios.

Figure 9 depicts the DEVSimPy simulation model for the smart parking system. The simulation starts with the Space atomic models—representing sensors—that are grouped together into a Zone coupled model. Next, the UserLink atomic model aggregates data from these sensors and transmits it to the drivers. The User model then filters and processes the available parking spaces based on specific criteria, passing the pertinent information to the Travel model. The Travel model evaluates this data according to various decision policies and selects an appropriate parking space. Finally, this decision is forwarded to the AccessConflictManagement model, which resolves conflicts between users by applying multiple algorithms to effectively manage competition.

Thanks to DEVS model continuity, the "space" models can be directly linked to an API that delivers real-time sensor data from an operational parking lot. By incorporating user authentication and switching the DEVS simulation kernel to real-time mode, this model becomes suitable for mobile application deployment. In this configuration, the mobile app enables city drivers to locate available parking spaces and occupy them. In fact, this DEVS-based simulation model was deployed within a mobile application—as illustrated in Figure 10—for the city of Bastia in Corsica, France.

To summarize, the features of this application that illuminate DEVS model expressiveness and continuity are:

• Model expressiveness: DEVS ability to express concurrent multiple streams of temporal events enabled simulation-based validation of the actuator coordination mechanism prior to its deployment ensuring its seamless integration and functionality within simulated physical environments.
• Model continuity:

  –

  The DEVS simulation engine can be mapped to middleware implementations enabling straightforward integration with IoCT infrastructures.

  –

  DEVS supports deployment across diverse hardware platforms with varying timing characteristics, underscoring its adaptability and portability.

  –

  DEVS bridges the gap between simulation and practical IoCT implementation, enabling design-phase validation to be translated effectively to real-world applications.

4.4. DEVS IoCT Development: Dynamic Structure for Adaptive Unmanned Swarm Systems

In [17] Zhang et al. emphasized the model expressiveness capability of DEVS, especially its dynamic structure feature, in application to M&S of unmanned swarm systems (USS). Such systems have broad applicability to a variety of domains including military, agriculture, aerospace, etc. Arguing that traditional modeling methods cannot effectively describe the dynamics of USS, they show how to apply DEVS to design, simulate, and implement such IoCT systems. The article shows how DEVS enables description of the unmanned component platforms from both behavioral and structural perspectives. In the former, DEVS atomic components model the microscopic behaviors; in the latter, DEVS coupling relationships describe the collaborative structure between unmanned platforms.

Particularly, Figure 11 illustrates how swarm growth and self-optimization for surveillance by USS is supported by dynamic structure DEVS. The capability to dynamically add and delete sub-models and input and output ports, and to change port connection relationships enables such systems to make structural adjustments in response to environmental changes. They perform such adaptation in accordance with given goals and structure change rules during simulation operation. A DEVS-based synchronization mechanism supports implementation of coordinated actions and changes in structure as required for adaptive behavior.

The hierarchical, modular structure of the USS and its environment is sketched in Figure 12 using the SES on top and the block diagram form at the bottom. The Swarm is decomposed into a Controller and Unmanned Autonomous Vehicles (UAVs), each of which are coupled models containing maneuverability and terrain feature detection atomic models. The USS implements adaptive reconnaissance in the sense that UAVs adaptively adjust their positions in the area under surveillance, or exit the mission, following rules such as:

• Deploy a UAV when an area is not being surveilled.
• If a UAV sustains damage exceeding 50 per cent, it must be withdrawn from the mission.
• When a UAV experiences interference, it should exit the interference zone.
• In cases where UAV reconnaissance areas overlap, the UAV with greater damage must vacate the area.

Figure 12. Hierarchical, modular structure of an unmanned swarm system and its environment is described in the SES (top of figure) and depicted by the hierarchical coupled model (figure bottom). Figure copied and modified with permission.

Figure 12. Hierarchical, modular structure of an unmanned swarm system and its environment is described in the SES (top of figure) and depicted by the hierarchical coupled model (figure bottom). Figure copied and modified with permission.

Such rules are implemented in the model using the dynamic structure capability of DEVS. Further, the temporal properties of DEVS are well suited to model the synchronization mechanism. The latter is necessary because UAVs can take different amounts of time to finish their assigned tasks due to the heterogeneity of rule application and environmental effects such as damage and interference. Synchronization is implemented by having the controller wait for all UAVs to report that they have completed the preceding task, before issuing the order to proceed to the next task.

Figure 13 leverages the SES to express how synchronization can be implemented in a decentralized manner as opposed to the centralized one just discussed. In the former, the central controller is absent and its functionality is implemented by the individual UAVs. While DEVS expresses the synchronization behavior required in either case, the SES expresses the alternative implementations employing different aspects (decomposition sub-trees) for the centralized and decentralized alternatives, respectively. Figure 14 illustrates such an SES description.

The first line in the fragment of Figure 14 defines an aspect called topLevel that decomposes the overall model SwarmNEnvironment into UAVSwarm and Environment components. Subsequent lines for this aspect declare coupling relations that state how output ports of sender components connect to input ports of receiver components. The yellow and green highlighted lines define two different aspects for decomposing the UAVSwarm component corresponding to those shown in color in Figure 13, respectively. In these lines coupling relations express connections from a coupled model input port to one more of its components input ports (called External Input Coupling) as well as conversely, from component output ports to output ports of the parent coupled model (called External Output Coupling),

4.5. Integration of Cyber Components with IoT devices in IoCT Systems

While IoT design focuses on communication and control of sensors and effectors, CPS design emphasizes the interaction between digital and physical components. As indicated above, applications become more demanding, the two thrusts are converging toward a more complete methodology, called Internet of Cyber-Things (IOCT) that combines their capabilities [29].

Figure 15 presents an architecture that harnesses the DEVS formalism to define the building blocks for both computational and control-theoretic functionalities essential to intelligent CPS design [30]. A related implementation, discussed in [31], exploits DEVS model continuity to efficiently develop embedded controllers for robotic systems. This same continuity supports the design, simulation, and implementation of similar concepts for USS systems as well.

In this use case, the features that illuminate DEVS model expressiveness and continuity are:

• Model expressiveness:

  –

  DEVS Atomic functions capture microscopic behaviors (messages, timing, decisions)

  –

  DEVS atomic and coupled models support synchronization.

  –

  DEVS Hierarchical modular structure expresses collaborative interaction in centralized and decentralized control.

  –

  DEVS Dynamic structure enables the structural changes needed for adaptive behavior.

• Model continuity:

  –

  DEVS supports definition of building blocks and architectural patterns for IoCT system design.

  –

  DEVS Execution engines can be implemented in diverse technologies such as virtualization, hardware, embedded system, and bioware.

5. Discussion

In the following we summarize the properties of the DEVS formalism that were elucidated in the examples given above to support the claims for its validity as an IoCT design language based on its model expressiveness and continuity. This is followed by a review of other formalisms that can address these features with a comparison of their relative adequacy.

5.1. DEVS Properties for Model Expressiveness and Model Continuity

DEVS is a strong candidate for the expressiveness of IoCT system design due to its ability to model heterogeneous, dynamic, and event-driven environments while ensuring modularity, hierarchy, and formal validation. IoCT systems are inherently complex and distributed, involving diverse components that operate at different time scales and require flexible interaction mechanisms. DEVS offers key advantages that align well with these characteristics:

• Modeling of Asynchronous and Event-Driven Behavior: IoCT systems rely on asynchronous interactions among devices, sensors, and actuators. DEVS, as a discrete-event formalism, naturally represents systems where state changes occur at discrete time instants, making it well-suited for capturing real-world IoCT dynamic [32]. It represents state changes at discrete time intervals, making it adept at modeling real-world dynamics in IoCT environments [33];
• Hierarchical and Modular Structure: DEVS enables hierarchical composition of models, allowing IoCT architectures to be designed in layers—such as edge, fog, and cloud computing—while maintaining encapsulation and interoperability between components [34]. This modularity enhances the reusability of models across different applications [32].
• Separation of Concerns (Structure vs. Execution): IoCT systems often require separating functional behavior from execution strategies. DEVS achieves this through its atomic models (defining component behavior) and coupled models (specifying interactions and execution flow), providing a clear separation between computation and communication [35].
• Support for Concurrency and Synchronization: IoCT components often involve multiple interacting subsystems that require concurrent processing. DEVS inherently supports parallel discrete-event simulation (P-DEVS), making it suitable for modeling concurrency, synchronization mechanisms, and conflict resolution in distributed IoCT systems [36].
• Adaptability to Dynamic Environments: IoCT applications demand adaptability due to changing conditions and evolving requirements. Dynamic Structure DEVS (DS-DEVS) extends DEVS by allowing on-the-fly reconfiguration, which is essential for modeling adaptive behavior in IoCT networks [37]. Adaptive decision-making frameworks, such as the one proposed by Wang et al., utilize layers that sense, decide, and execute actions based on dynamic conditions [38].
• Validation through Discrete-Event Simulation: A critical aspect of IoCT system design is verifying whether execution strategies remain conformant with the intended functional model while incorporating real-world constraints. DEVS provides a rigorous simulation-based validation framework, allowing designers to test control strategies, real-time constraints, and system reliability before deployment [37].
• Interoperability with Other Modeling Approaches: IoCT system design often integrates multiple modeling paradigms, such as synchronous automata, Petri nets, and state machines [39]. DEVS can coexist with and complement these models, making it a flexible bridge for heterogeneous system design.

By capturing both system structure and execution dynamics, while enabling modularity, adaptability, and validation, DEVS emerges as a powerful and expressive framework for IoCT system modeling and simulation.

Table 1 lists properties of the DEVS formalism related to model expressiveness, defined as its ability to express functional aspects of IoCT systems.

Model continuity refers to the ability to transition a system description seamlessly across different stages of development—design, simulation, and execution—with minimal or no modifications. This is particularly important in IoCT system development, where models need to remain consistent across heterogeneous platforms and real-world constraints. DEVS provides a formal and modular approach that supports model continuity in the following ways:

• Transition from Design to Simulation: DEVS provides a formal specification that allows IoCT models to be directly simulated without reinterpreting their structure or behavior. The same model used in design can be executed in a discrete-event simulation environment, ensuring that functional behaviors (e.g., message passing, event synchronization, timing constraints) are validated early. The hierarchical and modular nature of DEVS allows developers to incrementally refine their models while preserving core behavioral properties. For example, IoCT system architects can design DEVS models representing sensor interactions, data aggregation, and processing logic, then test these models in a simulation engine before deployment.
• Transition from Simulation to Execution: DEVS enables migration from simulated environments to real-world execution by transitioning from abstract simulation time to real-time execution. DEVS models can be mapped to real-time platforms, ensuring that the timing, coordination, and decision-making behaviors observed in simulation are maintained during execution. Through real-time DEVS (RT-DEVS), the same IoCT models can be integrated into embedded systems, middleware, and cloud environments without major alterations. For example, a DEVS-based traffic monitoring system tested in a simulation environment can be directly deployed onto real-world IoCT infrastructure while maintaining its event-driven behavior [40].
• Support for Diverse Implementation Platforms: DEVS models can be executed across a wide range of hardware and software platforms, including: (i) Embedded systems (IoCT devices, microcontrollers) (ii) Edge and fog computing environments (iii) Cloud-based IoCT platforms and (iv) Distributed simulation frameworks [41]. This adaptability ensures that the same IoCT model can be scaled and reused across multiple deployment scenarios. For example, a DEVS-based smart grid model can be tested in a cloud-based simulation environment and later deployed onto real-time distributed IoCT systems while preserving model fidelity.
• Model Validation and Conflict Resolution: DEVS simulation helps verify and validate execution strategies, ensuring that an IoCT system’s operational behavior remains consistent with its design [42]. At the Operational Model level, DEVS supports conflict actuation management, helping resolve issues such as resource contention, sensor conflicts, and dynamic adaptation. For example, a smart building IoCT system modeled in DEVS can simulate conflicting temperature control settings before deployment, ensuring smooth operation.
• Dynamic Adaptation and Evolution: IoCT systems can reconfigure themselves autonomously, reducing the need for human intervention. This self-management is vital in complex environments, as highlighted in studies on self-adaptive software systems [43]. Through Dynamic Structure DEVS (DS-DEVS), models can adapt to environmental changes in real-time, allowing IoCT systems to be self-reconfigurable. This ensures that model continuity extends beyond initial deployment, supporting evolution and updates without requiring full redesigns. For example, an IoCT-based disaster response system modeled with DS-DEVS can dynamically adjust communication patterns and resource allocation in response to changing emergency conditions.

Table 2 lists transitions from the Design stage to the Simulation stage and from the latter to the Execution stage for which DEVS model continuity supports development of IoCT systems. The table also considers the diversity of implementation that DEVS can work within.

5.2. Comparison with Other Formalisms

It is important to compare are other modeling formalisms that aim to achieve expressiveness and continuity in IoCT systems, including Class Diagrams, State Machines, and Petri Nets [44]. While each formalism has its strengths, they do not fully address the unique challenges of IoCT systems in the same way that DEVS does. In this section, we explore how some of these popular formalisms compare with DEVS in terms of expressiveness, continuity, and support for IoCT system features. Appendix 1 reviews these formalisms in relation to DEVS in detail. Table 3 compares these formalisms for expressiveness and model continuity in IoCT system design. In summary, while each of these formalisms offers valuable features — for static structure, control flow, concurrency, or complex systems modeling - they generally do not provide the same level of temporal expressiveness, modularity, and integrated execution support that DEVS delivers for dynamic IoCT systems.

6. Conclusion and Future Directions

In this paper, we have demonstrated that the DEVS formalism, coupled with the System Entity Structure, SES, possesses the necessary expressiveness and continuity to serve as a robust design language for IoCT systems. Through illustrative examples, such as home automation, solar sensor farm management, conflict resolution mechanisms, and dynamic unmanned swarm systems, we highlighted how DEVS supports adaptive and complex behaviors with hierarchical modularity, synchronization, and dynamic structure capabilities. Furthermore, the continuity inherent in DEVS enables seamless transitions from design and simulation to real-world implementation, making it a powerful tool for bridging the gap between conceptual models and operational systems.

While we have demonstrated the capability of DEVS to support simulation-based design of IoCT systems, there remain limitations in the design of such systems. In this context, model-driven engineering (MDE) [45] can play a significant role in augmenting DEVS-based design of such systems from the aspects of higher level support for expressiveness and continuity. More specifically, MDE provides a formal methodology to apply DEVS-based design capabilities to address the challenges of expressiveness and continuity in IoCT system design. On the expressiveness side, MDE supports the use of Domain-Specific Languages (DSLs), which provide customized abstractions to empower designers to articulate complex IoCT behaviors at a higher level, aligning the system design more closely with its functional requirements. Moreover, MDE promotes modular design and validation through formal methods, features that can significantly augment simulation-based equivalents when tractable. MDE also supports automated model transformations—converting models from design to simulation and then from simulation to execution—ensuring that a consistent system description is maintained at every stage. This consistency is further reinforced by traceability mechanisms that link different levels of abstraction, guaranteeing that changes in one phase are accurately propagated to subsequent phases.

By allowing for high-level abstractions, modular design, and seamless transitions between stages of development, MDE can augment the expressive and continuity capabilities of DEVS to significantly enhance the efficiency and accuracy of IoCT system development, from initial design through to real-world deployment.

On the other hand, more research needs to be done to improve the expressive capability of DEVS while improving the user experience at the same time. Developments such as non-standard DEVS point the way to such tool development [46].

Looking ahead, we envision expanding DEVS applications to encompass even more diverse IoCT domains, emphasizing its scalability, flexibility, and integration potential with emerging technologies. By leveraging these strengths with the support of MDE methodology, DEVS is poised to play a pivotal role in the evolution of intelligent, adaptive systems within the rapidly advancing IoCT ecosystem.