Keywords

1 Introduction

The Internet of Things (IoT) refers to the networked interconnection of billions of “smart objects”, i.e., autonomous networked devices equipped with sensors, actuators, computational and storage facilities, that cooperate with each-other and the environment. In recent years IoT has gained much attention from industry and researchers with a variety of applications, e.g., smart-grid [28], smart-home [32], smart-parking [13], earthquake early warning [10], etc. This trend is sure to continue in the immediate future [11], as it continues to be supported by the standardization efforts of well known organizations like ITU-T [20], ETSI [9], IEEE and IETF [16, 17].

Heterogeneity and distribution scale speak for the complexity of IoT applications and call for a careful analysis prior to any deployment on target environments. However, a thorough analysis is possible if the application is already deployed, which contradicts the purpose of the analysis in the first place. A controlled environment (e.g., experimentation test-bed [14]) can be a solution, with the advantage of having the application itself (i.e., the application intended for deployment) under analysis. Nevertheless, scalability of such environments maybe unfeasible, thus hindering the analysis of properties that can be inferred from the interaction of devices deployed in a large-scale. Simulation can address this issue, but the development of an accurate simulation model is not a trivial task. Indeed, a simulation model is an abstraction of the application (i.e., a selection of properties that are relevant to the analysis) and not the application itself. Derivation of this abstraction may become a development process in its own based on the complexity of the system, and validation is a must to ensure that it correctly represents the application intended for deployment.

In Sect. 2 we give an overview of related work on simulation of IoT applications and position our approach in respect to existing state of the art. We introduce our modeling approach by means of a typical application example in Sect. 3. The automatic transformation from model to simulation executable is described in Sect. 4. Finally, we present some conclusions in Sect. 5.

2 Related Work

We identify two types of simulators for IoT applications: specialized and generic. Specialized simulators are provided by IoT operating systems as part of their development environment, e.g., Cooja [27] for Contiki OS [8] and TOSSIM [25] for TinyOS [24]. They simulate the entire device, i.e., hardware, communication, operating system, and application. A major advantage of these simulators is that they do not require a simulation model of the application, i.e., the same description (usually code) can be used for simulation and deployment. However, the number of device models is limited to those supported by the operating system, and scalability is a possible issue as entire devices are simulated. On the other hand, generic simulators (e.g., ns-2 [2], ns-3 [15], and OMNeT++ [34]) can be used to analyze large-scale application-specific properties without the additional overhead of low-level models (e.g., hardware and operating systems), but they require a simulation model of the application.

Weingärtner et al. in [35] discuss possible solutions to the limitations of available simulators. They identify the extension of generic simulators with capabilities of executing real applications or hybrid frameworks as smarter choices.

Although extending generic simulators is quite common, it focuses on models of the underlying communication protocols and not on applications. Tazaki et al. in [33] describe how to execute nearly unmodified applications in the context of ns-3 simulations. The aim is to increase the number of available protocol models and realism of simulations. The framework is not specifically targeted to IoT applications, however it is an important extension to generic simulation.

Brambilla et al. in [1] present a hybrid framework for the simulation of large-scale IoT scenarios. The framework is characterized by high modularity and loose coupling between simulation models to allow reuse of the code. Although it is possible to deploy the source code on real devices, this can be achieved only by adopting the required interfaces.

We follow a different approach to application development by exploiting the model-driven development (MDD) paradigm. With a pragmatic MDD approach it is possible to construct a model of the application that can be transformed into the application for deployment and/or a simulation model for analysis [31]. We use the standard languages SDL [19] or SDL-RT [30]Footnote 1 in our integrated development environmentFootnote 2 to capture architectural, behavioral, communication, and deployment aspects of the application into a single description (model). Automatic code generation can then transform such description into an executable simulation model for the ns-3 network simulator.

3 Modeling

Several efforts have been made in the last decade to bring together standard modeling languages with generic simulation frameworks. The advantages are obvious: while the former allow description of aspects at a higher level of abstraction independent from the target platform, the later are used to simulate such description in large-scale scenarios. Representative examples are the use of SDL with ns-2 [23] or ns-3 [3], and UML with OMNeT++ [7]. There is however an important difference between SDL- and UML-based approaches. While SDL models are used also for deployment (e.g., [10, 22]), this is not the case with UML, where models are used only for simulation.

3.1 Architecture and Behavior

In SDL the overall design is called the system, and everything outside of it is defined as the environment. The system can be composed of agents and communication constructs. There are two kinds of agents: blocks and processes. Blocks can be composed of other agents and communication constructs. When the system is decomposed down to the simplest block, the way the block fulfills its functionality is described with processes. A process provides this functionality via extended finite state machines. It has an implicit queue for signals. A signal has a name and parameters; they go through channels that connect agents and end up in the processes implicit queues. Figure 1 illustrates these concepts in a typical IoT sensor-gateway application example for parking lots.

Fig. 1
figure 1

Architecture and behavior description of a simple sensor-gateway application for parking lots

Full size image

The gateway keeps an updated list of all sensors it is responsible for. This binding is realized at startup via the signals mRequest and mRequestOk . To keep track of the state of each individual sensor, the gateway assigns a unique identifier to it. At start, every registered sensor is in Free state. When a sensor detects the arrival of a car at its slot (i.e., the mArrive signal), it will change the state to Occupied and let the gateway know about such change by means of the mOccupied signal. This signal has the sensor’s unique identifier as parameter, so that it is possible for the gateway to correctly update its list of available slots. When the car leaves the parking slot (i.e., the mDepart signal), the sensor will reset its state to Free and notify the gateway with the mFree signal. Additional signals may trigger the gateway to report the current status of the parking lot, however for simplicity these signals are not shown in the figure.

3.2 Communication

The strong point of SDL is that it allows the description of communication systems in a formal and abstract way (i.e., platform independent). However, this level of abstraction presents a number of challenges when implementation is concerned (i.e., platform specific). In this context, an important aspect to be considered is communication, which puts the internet into the internet-of-things. Communication in SDL is realized using channels, e.g., cIntern in Fig. 1, and it can be local or distributed. Not making the difference between these two types of communication is an important feature of SDL that is needed to abstract from the platform. Indeed, there is no way to tell whether the pSensor and pGateway processes in Fig. 1 are running on the same node or device (i.e., local communication) or on different nodes (i.e., distributed communication). Platform specific implementation for local communication can be derived in general without much effort. The information contained in the SDL architecture and behavior description is enough to uniquely identify the sender and receiver of a signal, because all process instances are part of the same executable running on a single node. Problems begin to emerge when processes are distributed and use platform specific inter-process communication. To uniquely identify a process instance in a distributed IoT infrastructure, information about the node where the instance has been deployed is required; a typical example would be the IP address of the IoT node. However, this information is not present in a SDL model, due also to the missing concept of the node in the language.

Schaible and Gotzhein in [29] define a set of SDL patterns for describing distributed communication. The advantage of these patterns is that they are formalized, thus they can be used in every SDL description without affecting this important feature of the language. However, the introduction of patterns implies changes to an existing SDL description, and what is more important, it does not follow the choice of SDL to abstract the type of communication.

Brumbulli and Fischer in [5] apply the same concept but in the context of SDL-RT. Although not formalized,Footnote 3 the patterns are very compact, descriptive, easy to apply, and exploit the pragmatic nature of the language. Nevertheless, the problems of a pattern-based approach are still present, and it is not possible to use the patterns in SDL.

To address these issues we decided to not define and/or apply any pattern to SDL descriptions. The additional information that is required to derive platform specific implementation can be provided using SDL-RT deployment diagrams [30]. This approach does not introduce any changes to the SDL model of a system, thus keeping the desired level of abstraction in the description of communication. Also, by keeping deployment aspects (e.g., nodes and their IP addresses) separate from architecture and behavior, it is possible to use the approach for both SDL and SDL-RT. Furthermore, extending our integrated development environment with the presented approach is an important step towards a complete model-driven solution for the development of IoT applications.

3.3 Deployment

The deployment diagram describes the physical configuration of run-time processing elements of a distributed system and may contain (Fig. 2):

Fig. 2
figure 2

Deployment scenario for the sensor-gateway application for parking lots

Full size image

  • nodes are physical objects that represent processing resources,

  • components represent distributable pieces of implementation of a system (i.e., SDL block or process),

  • files provide information about external signals required for simulation.

The node and component are identified by means of the id attribute. The type of values for this attribute depends on the parameters required for inter-process communication, e.g., IP address for the node and TCP port for the component. A comma separated list of values can be assigned to the attribute. This allows the description of large-scale scenarios while keeping the readability of the diagrams. The pair of id attributes is used to uniquely identify each component. The semantics of communication between two process instances are as follows:

  • if the sender and receiver instances belong to the same component, then SDL communication semantics apply;

  • if the sender and receiver instances belong to different components, then:

    • at first, the pair of identifiers is used to send the signal to the peer component via inter-process communication;

    • afterwards, the signal is delivered to the receiver inside the component using SDL semantics.

The use of deployment diagrams was introduced [5]. We improve the approach in two significant ways:

  • introduce deployment information exclusively in the deployment diagram, without mixing architecture, behavior, and deployment aspects of the system, thus supporting both SDL-RT and standard SDL;

  • provide simple means to describe interaction with the environment.

Interaction with the environment is an important aspect that must be considered during simulation. An example of such interaction is the detection of arrival and departure of a car into a parking slot. This is modeled with the mArrive and mDepart signals in Fig. 1. These signals are addressed to the sensor, and it makes perfect sense when the system has a single sensor. However, this is not the case in our example scenario (or every IoT application scenario in general), which is composed of several sensors. In this context, external signals may be addressed to one or more distributed process instances, and to add to the complexity, they can have different parameters, timing, and order of arrival based on the intended receiver. We define a simple yet complete method for extending the deployment model with the required information. The set of external signals with parameters, timing, and receiver is described in a tabular form (i.e., comma separated values format) in a file symbol attached to the deployment diagram as shown in Fig. 2. Each signal is configured with the time it is sent by the environment (row head) and the receiving component (pair of identifiers in column head).

4 Simulation

The SDL (or SDL-RT) description (architecture and behavior) combined with the deployment diagram are used as a basis for the generation of an executable simulation model for ns-3. A generic model for code generation was introduced in [5]. We extend the model as shown in Fig. 3 by introducing the implementation of deployment and distributed communication concepts, i.e., RTDS_DeplNode, RTDS_DeplComponent, and RTDS_Proxy.

Fig. 3
figure 3

Extended class diagram for code generation based on [5]

Full size image

The RTDS_DeplNode maintains the list of all its attached components in its attribute named componentsList. The RTDS_DeplComponent keeps a reference to the scheduler (RTDS_Scheduler), which manages process instances (RTDS_Proc), communication via signals (RTDS_MessageHeader), and timers (RTDS_TimerState). Local communication between process instances is handled via a memory shared mechanism. This is possible because local communication implies sender and receiver instances managed by the same scheduler. The information about the sender and receiver of a signal is encapsulated in RTDS_MessageHeader. If the sender and receiver are not managed by same scheduler, then distributed communication is implied, and the signal is forwarded to the RTDS_Proxy instance. Every scheduler manages an implicit proxy instance, which interfaces to the underlying communication models provided by ns-3.

Our integrated development environment (RTDS) will automatically:

  • check the syntax/semantics of the SDL description,

  • check the syntax/semantics of the deployment description,

  • check the syntax/semantics of the external signals given in tabular form,

  • produce an executable by generating the code, compiling it, and linking it to the ns-3 library, and

  • launch the executable in the background, interpret and visualize simulation events traced during execution.

Visualization of simulation events is realized as described in [4], but extended with two modes:

  • in live mode events are visualized as they are traced from the simulation running in the background,

  • in post-mortem mode the simulation can be replayed entirely after it has successfully terminated, which allows stepping through the events without having to re-run the simulation.

Figure 4 shows the deployment of one gateway and 99 sensors (nGateway and nSensor in Fig. 2). Nodes, their state, and distributed communication (between nodes) are visualized in the RTDS Deployment Simulator as shown in Fig. 4a. Nodes are displayed as colored rectangles, where the color represents the current state of the node. A sent signal is a directed arrow from the sender to the receiver, and its color represents the type of the signal. The arrow is removed from the view when the signal is received. The states and signals can be configured via the provided interface. It is possible to change their color and choose whether to display them during simulation. This feature is useful in cases where not all the states and/or signals are relevant to the analysis.

Fig. 4
figure 4

Visualization of simulation events for the sensor-gateway example

Full size image

If an issue is detected in the behavior of the application (e.g., a missed state change or a signal not sent), it is possible to analyze the cause in detail by visualizing the internals of each node. This can be done on-demand using standard MSCs [18] as shown in Fig. 4b, c. MSCs are linked to the SDL description, thus identifying the source of misbehavior in a MSC trace would allow navigation to the corresponding part in the description where changes can be made.

5 Conclusions

In recent years IoT has gained much attention from industry and researchers, a trend that will continue in the immediate future. Heterogeneity and distribution scale contribute to the complexity of IoT applications, which need a careful analysis prior to any deployment.

In this paper we introduced a model-driven approach for the analysis of IoT applications via simulation. The standard language SDL captures architectural, behavioral, and communication aspects into a model of the application that is independent from the target platform. Deployment diagrams describe the distribution of the SDL system (blocks and/or processes) in an IoT infrastructure and the interaction with the environment. The automatic code generation transforms the description into an executable simulation model for the ns-3 network simulator. The RTDS Deployment Simulator provides a graphical interface for the visualization of simulation traces.

The concepts and tools presented in this paper are important steps towards the model-driven analysis of IoT applications via simulation. In this context, the use of standard MSCs for representing traced events can aid the formal verification of properties [12]. As to how this can be applied for applications deployed in large-scale is yet to be investigated in future work. Furthermore, we are considering the possibility to extend the approach with testing support by means of standard TTCN-3 [21]. A deployment model analysis based on symbolic resolution tools such as [6] can be the next step towards a complete and fully automated approach.