The emergence of the Internet of Things (IoT) has dramatically changed how physical objects are conceived in our society and industry. In this new IoT era, every object becomes a complex cyber-physical system (CPS), where both the physical characteristics and the software that manages them are highly intertwined. More specifically, IoT is defined by the ITU as a “global infrastructure for the information society, enabling advanced services by interconnecting (physical and virtual) things based on existing and evolving interoperable information and communication technologies”. Currently, billions of devices become connected with potential capabilities to sense, communicate, and share information about their environment.

Traditional IoT systems rely on cloud-based architectures, which allocate all processing and storage capabilities to cloud servers. Although cloud-based IoT architectures have advantages such as reduced maintenance costs and application development efforts, they also have limitations in bandwidth and communication delays [1]. These limitations are intended to be addressed with edge and fog computing, whose objective is to distribute processing and storage close to data sources (i.e. things). Today, developers tend to leverage the advantages of edge, fog, and cloud computing to design multi-layered architectures for IoT systems.

Nevertheless, designing these complex systems is a challenging task, including their management and adaptability at runtime. IoT systems are commonly exposed to changing environments that induce unexpected events at run-time (such as unstable signal strength, latency growth, and software failures) that can impact their Quality of Service (QoS). To deal with such events, a number of runtime strategies (such as auto-scaling and offloading tasks) should be automatically applied.

In this sense, better support to define complex IoT systems and their (self)adaptation rules to semi-automate the deployment and evolution process is necessary [2]. A usual strategy when it comes to modeling complex domains is to develop a domain-specific language (DSL) for that domain [3]. Nevertheless, current DSLs for IoT do not typically cover multi-layered architectures and even less include a sublanguage to ease the definition of the dynamic rules governing the IoT system.

In our paper  Modeling self-adaptative IoT architectures, co-authored by Iván Alfonso, Kelly Garcés, Harold Castro and Jordi Cabot, accepted in SAM’21 (co-located with Models’21), we propose a new domain-specific language (DSL) for IoT systems focusing on three main contributions:

  1. Modeling primitives covering the four layers of an IoT system, including IoT devices (sensors or actuators), edge, fog, and cloud nodes
  2. Modeling the deployment and grouping of container-based applications on those nodes
  3. A specific sublanguage to express adaptation rules to guarantee QoS at runtime.

We have implemented the DSL using the Meta Programming System (MPS). A proof of concept of a generator for deploying the modeled IoT system on a K3S-based (Kubernetes distribution built for IoT and edge computing) infrastructure is also provided. Keep reading for more details, read the full paper, or check the slides (at the end).

Background and running example

Edge computing and fog computing are solutions that propose to bring computation, storage, communication, control, and decision-making closer to IoT devices [4]. There are strong similarities between these two solutions, but the main difference is where the processing takes place. While edge computing takes place on devices directly connected to sensors and actuators, or on gateways physically close to these, fog computing takes place on LAN-connected nodes usually farther away from the sensors and actuators. Sensors and actuators compose the device layer. Sensors generate information by monitoring physical variables (such as temperature, motion, and oxygen) and actuators (such as valves, fans, and alarms) are devices capable of transforming energy into activation of a process.

A coal mining industry case as a running example is shown in Figure 1 to better illustrate these concepts. It is a well-known fact that the underground coal mining industry has adopted the use of monitoring systems to alert workers to the presence of toxic and explosive gases inside the underground mines [5]. For our running example, the infrastructure and software features of the gas monitoring system are as follows.

  • Device layer. Each work front has a temperature sensor, a methane gas sensor, and a visual alarm to alert workers to the existence of gases. Additionally, there is a fan at the entrance of tunnel B to control the temperature and avoid gas concentrations in the mine.
  • Edge layer. An edge node deployed at each work front receives the information collected by the sensors. These nodes run the App1 containerized application which analyzes sensor data in real time and triggers alarms when methane gas is detected in the environment.
  • Fog layer. The mine has a fog node that communicates with the Edge nodes. This fog node located at the entrance of tunnel A, runs a containerized application to control the fan speed based on aggregated temperature and methane gas data (App2).
  • Cloud layer. The cloud layer has a server or cloud node that runs two containers: (DB1) a database to store part of the sensor data, and (App3) a web application to visualize historical information from sensor data and incidents at any of the mine’s work fronts.
Figure 1. Overview of the gas monitoring system in a mine

Figure 1. Overview of the gas monitoring system in a mine

DSL for the specification of multi-layered IoT systems

Our DSL has two main components, the sublanguage to describe the IoT architecture and the sublanguage to describe the rules governing the self-adaptation to this architecture to adapt to changes in the environment the IoT system lives in.

Modeling the IoT architecture

Figure 2 shows the excerpt of the metamodel that abstracts the concepts to define multi-layer IoT architectures. The concepts for representing the IoT system infrastructure and the deployment of container-based applications have been captured in this metamodel. While the IoTDevice concept enables the modeling of device layer devices such as sensors and actuators, the Node concept allows modeling nodes from the edge, fog, and cloud layers. Physical (or even virtual) spaces such as tunnels, work fronts, buildings, or mines can be represented by the concept Region.

Figure 2. Excerpt of the metamodel depicting multi-layer architecture and deployment

Figure 2. Excerpt of the metamodel depicting multi-layer architecture and deployment

Together with the abstract syntax (metamodel), each language should provide one or more concrete syntaxes. A concrete syntax refers to the type of notation (such as textual, graphical, tabular, or hybrid) to represent the concepts of the metamodel. We take advantage of MPS projectional editors to define a hybrid notation (textual, tabular, and tree view). Projectional editors are editors in which the user’s editing actions directly change the Abstract Syntax Tree (AST) without using a parser. Our DSL enables the modeling of all concepts using a textual notation. Additionally, for some concepts we also offer complementary notations that we believe are better suited for that concept: a tabular notation for modeling nodes and IoT devices, and a tree notation for regions. For example, following the running example, Fig. 3 shows the list of sensors and actuators located in theWork-Front1 region.

Figure 3. IoT devices modeling example (tabular notation)

Figure 3. IoT devices modeling example (tabular notation)

Modeling the self-adaptation rules

The dynamic environment of an IoT system generates unexpected changes that could affect the QoS. The system should be prepared to cope with unexpected changes and self-adapt to different situations. Because of this, our DSL enables the modeling of self-adaptation rules of the system.

The metamodel excerpt representing the abstract syntax for defining the rules is presented in Figure 4. Every rule is an instance of AdaptationRule that has a triggering condition which is an expression. We reuse an existing Expression language to avoid redefining in our language all the primitive data types and all the operations to manipulate them. Such Expression language could have been for instance the Object Constraint Language (OCL) but to facilitate the implementation of the DSL later, we directly reused the MPS Baselanguage. The metamodel extends the generic Expression concept by adding sensor and QoS conditions that can be combined also with all other types of expressions (e.g. numerical ones) in a complex conditional expression.

An action can be classified as Offloading, Redeploy, Scaling, or OperateActuator:

  • The Offloading action consists in migrating a container from a source node to a destination node. This migration can be between nodes of different layers.
  • The Scaling action involves deploying replicas of an application (the number of replicas to be deployed is defined by the instances attribute).
  • The Redeployment action consists in stopping and redeploying a container running on a node.
  • Finally, the OperateActuator action is to control the actuators of the system (e.g. to activate or deactivate an alarm). The message attribute represents the message that will be published in the broker and interpreted by the actuator. This action can control actuators that require only one control value such as On/Off.
Metamodel to specify self-adaptation rules

Figure 4. Excerpt of the metamodel depicting adaptation rules

The system adaptation rules are specified by a textual notation using as keywords the names of the metaclasses of the abstract syntax. The conditions follow the grammar of a relational expression with the use of mathematical symbols (such as <, >, and =) and logical operators (such as & and ||). It is worth to note that, given that the textual notation is a projection of the abstract syntax, the MPS editor offers a powerful autocomplete feature to guide the designer through the rule creation process.

Continuing our running example, to guarantee the execution of the App1 deployed on the EdgeWF1 node (container C01), we modeled the rule as shown in Figure 5. This rule offloads the container C01 hosted on node EdgeWF1 to a nearby node (e.g., node EdgeWF2) when the CPU or RAM consumption exceeds 90\% for one minute. If the EdgeWF2 node does not have the necessary resources to host that new container, a Region (e.g. Level1) can be specified so that a suitable node will be searched there. However, if this offloading action cannot be executed, for example, because in Level1 there is no node capable of hosting the container, then we must define a backup action. Therefore, we have modeled a second action (Scaling) to deploy a new container instance of the App1 application on any of the nodes of the mine.

Figure 5. Adaptation rule modeling

Figure 5. Example of the modeling of an Adaptation rule with our DSL

Tool support

Our DSL is implemented using MPS, an open-source language workbench developed by Jetbrains. In addition, we have developed a proof-of-concept of a code generator. Both DSL and generator are freely available in our repository.

In addition to the multiple projections that we have defined as the concrete syntax of our DSL, we have used the MPS constraint mechanism to embed several well-formedness rules in the editors. For instance, we have added a constraint to avoid repeated names, a constraint to limit the potential values of some numerical attributes, a constraint to restrict the potential relationships between nodes, etc.

While the DSL formalizes the knowledge about the business in the domain, the code generator encapsulates the implementation of that knowledge in a particular target technology. More specifically, as a proof of concept, we have implemented a model-to-text transformation that generates a YAML handle code to deploy container-based applications with the K3S orchestrator from our IoT system definition.


We have presented a DSL for modeling multi-layered architectures of IoT systems and their self-adaptation rules. The DSL is implemented as a projectional editor created with the Jetbrains MPS tool. This gives us the flexibility to offer, and mix, a variety of concrete notations for the different concepts of the DSL.

We have also presented a prototype Kubernetes manifest generator for deploying container-based applications by defining pods (to deploy containers) and services (to set up access to the applications).



  • Jiang, Z. Huang, and D. H. Tsang, “Challenges and solutions in fog computing orchestration,” IEEE Network, vol. 32, no. 3, pp. 122–129, 2017.
  • Rhayem, M. B. A. Mhiri, and F. Gargouri, “Semantic web technologies for the internet of things: Systematic literature review,” Internet of Things, p. 100206, 2020.
  • Brambilla, J. Cabot, and M. Wimmer, “Model-driven software engineering in practice,” Synthesis lectures on software engineering, vol. 3, no. 1, pp. 1–207, 2017.
  • C. A. W. Group et al., “Openfog reference architecture for fog computing,” OPFRA001, vol. 20817, p. 162, 2017.
  • Alfonso, C. Gómez, K. Garcés, and J. Chavarriaga, “Lifetime optimization of wireless sensor networks for gas monitoring in underground coal mining,” in 2018 7th International Conference on Computers Communications and Control (ICCCC). IEEE, 2018, pp. 224–230.

Featured image created with freepik

Want to build better software faster?

Want to build better software faster?

Read about the latest trends on software modeling and low-code development

You have Successfully Subscribed!

Pin It on Pinterest

Share This