Co-simulation for IoT systems

Nowadays, simulation is used during the development and commissioning of automation systems, but with the introduction of the “digital twin”, the use of simulation is also expanding to operations. These new uses of simulation present new challenges, especially in the simulation of IoT systems, which are dynamic and heterogeneous systems. Due to the high dynamics (entry and exit of components) and heterogeneity (strongly different components) in IoT systems, it is no longer possible to simulate all components with all relevant aspects in one simulation tool, which is why co-simulation is needed. In order to cope with the high dynamics of the real system, a concept is also needed to enable “plug-and-simulate”, which meets the following challenges.

Challenge 1: Integration of the simulations of the individual IoT components separately into the overall simulation.

In order to be able to exchange individual components as easily as possible in “plug-and-produce” scenarios, it is desirable to transfer the existing modularization of the components there to the simulation world as well in order to achieve a “plug-and-simulate” in simulations.

Challenge 2: Usage of different simulation tools from different domains.

IoT systems are becoming more and more heterogeneous due to ever-increasing networking, even across domain boundaries. This heterogeneity also affects the simulation world: different tools from different domains will be able to be used to simulate the individual components.

Challenge 3: Simulations and their models should be able to occur at runtime.

Simulations are increasingly used throughout the lifecycle and thus also during the operation of a system. It is therefore advantageous if, due to a new component entering the real IoT system at runtime, a simulation of this new component can also enter the simulation at runtime.

Based on these challenges, a concept was developed in recent years in cooperation between the Institute of Automation and Software Systems at the University of Stuttgart and Vector Informatik.

Existing concepts for simulating IoT systems

Several approaches for the simulation of IoT systems already exist in the literature, but it has become apparent that the aspects of simulation on which the individual publications focus vary greatly, e.g., detailed simulation of communication or the scalability of IoT systems. While these simulation approaches do justice to the dynamics of IoT systems, they cannot represent the required heterogeneity, since only one specialized simulation tool is ever used.

In addition to these “single tool” approaches, there are different co-simulation standards such as FMI (Functional Mock-up Interface), HLA (High-Level Architecture) or CAPE-OPEN (Computer-Aided Process Engineering). However, these are these standards do not fulfill the required extensibility at runtime, since they do not provide for the inclusion of new simulation tools at runtime. Some of them are also domain-specific (CAPE-OPEN) and thus also do not fulfill the required heterogeneity.

Since no currently available simulation concept fulfills both the required extensibility at runtime and the required heterogeneity, a new co-simulation concept for the simulation of IoT systems is needed.

Agent-based co-simulation of IoT systems

An agent system was chosen as the approach for coupling the individual sub-simulations, since agent systems allow agents to enter and leave the simulation at runtime without any problems. In principle, however, other concepts such as SOA or OSGi would also be conceivable here. Each IoT component is simulated in its own simulation and represented by an agent, see Figure 1. By modeling and simulating the IoT components in individual simulations and representing them by agents, the individual simulations can enter and exit at runtime just like the real IoT components. Data exchange takes place via the agent system.

Interface between agents and simulation tools

To enable data exchange between the individual simulations, an interface between the simulation tools and the agents is required. The data that must be exchanged among the simulations can be divided into communication-oriented and process-oriented data. Communication-oriented data represents the messages sent in the IoT system through communication channels, and the process-oriented data simulates the process-oriented interaction in the IoT system. The process-oriented interactions in an IoT system are the physical interactions in the IoT system. For example, if a heater heats a room, this has an effect on a temperature sensor located in the room. Thus, the heater and temperature sensor interact with each other through the process of heating. For both types of interaction, an interface between agents and simulation tools is needed. It makes sense to subdivide the interactions, since the communication-oriented interaction is precisely specified via the communication protocols used in the real system, whereas the process-oriented interaction must be abstracted, since no specification exists for the physical world.

To allow certain reusability of the interfaces, the interfaces are divided into a specific and a generic part, see Figure 2. The specific part is adapted to the respective simulation tool and has to be developed once for each simulation tool. If several models are modeled with the same simulation tool, this specific part can be reused for each of these models. The generic part is the upward interface to the agent and can be used for all simulation tools.

Data exchange between the partial simulations

However, only integrating communication and process-oriented interface is not enough, these interaction types must also be simulated. For this purpose, one or more communication simulations and one or more process simulations are additionally integrated, see Fig. 2. In these, communication protocols and technologies such as Wifi, Bluetooth or bus protocols such as CAN are then simulated, or physical processes such as forces, temperature curves, etc. are simulated.

Synchronization of the co-simulation

In addition, synchronization between the individual simulations is required. This has to be done centrally, because information about the simulation progress of each partial simulation is needed. The synchronization is done by a clock agent, see Figure 2, which sends synchronization messages to the individual co-simulation participants. In order to be able to process these synchronization messages, a synchronization interface between the agents and the simulation tools is also required, through which the agents can influence the time progress in the individual simulation tools. For reasons of simpler feasibility, conservative synchronization was chosen in the project.

Realization of the co-simulation

The presented concept was realized based on two scenarios, whereas the focus of this blog post will be set on one, the warehouse scenario:

The warehouse consists of a forklift, a refrigeration unit, a temperature sensor, goods, warehouse shelves, and environment, which were simulated with different simulation tools. If a good enters the warehouse, it communicates with the warehouse shelves to get a storage location. The storage racks contact the temperature sensors to match the current temperature with the temperature requirements of the goods, and then tell the forklift which storage rack to put the goods in. In addition, the heater communicates with the temperature sensors to keep the environment at the desired temperature. After a certain time, another forklift is integrated to increase the throughput of the warehouse.

The following simulation tools were chosen for the individual sub-simulations:

In this scenario, the agents as well as the agent environment were implemented with JADEX, an agent framework of Java. This scenario demonstrated well that new partial simulations can be integrated into a co-simulation at runtime.

Conclusion: Proved concept for simulation of IoT systems

Although there are initial approaches to modeling and simulating IoT systems, these usually consider only one particular aspect of IoT systems and, because they use only one simulation tool, cannot do justice to heterogeneity. Existing co-simulation standards such as FMI and HLA can better address heterogeneity, but they do not address dynamics because they do not allow the incorporation of new sub-simulations at runtime via “plug-and-simulate”. The co-simulation concept presented in this article enables a “plug-and-simulate” capable co-simulation, into which new sub-simulations from different simulation tools can be integrated at runtime. This was demonstrated using scenarios.

Further readings

• Jung, Tobias & Jazdi, Nasser & Krauß, Stefan & Köllner, Christian & Weyrich, Michael. (2020). Hardware-in-the-Loop Simulation for a Dynamic Co-Simulation of Internet-of-Things-Components
• Jung, Tobias & Weyrich, Michael. (2018). Synchronization of a “Plug-and-Simulate”-capable Co-Simulation of Internet-of-Things-Components
• Jung, Tobias & Shah, Payal & Weyrich, Michael. (2018). Dynamic Co-Simulation of Internet-of-Things-Components using a Multi-Agent-System
• Jung, Tobias & Jazdi, Nasser & Weyrich, Michael. (2017). A survey on dynamic simulation of automation systems and components in the Internet of Things

More about IoT testing

• IoT test beds: 4 typical setups
• Testing IoT systems: Challenges and solutions
• Technical debt in the world of Internet of Things / IoT