A Domain-Specific Language For Modeling IoT System Architectures That Support Monitoring

Received May 11, 2022, accepted May 30, 2022, date of publication June 8, 2022, date of current version
June 15, 2022.

Digital Object Identifier 10.1109/ACCESS.2022.3181166
A Domain-Specific Language for Modeling IoT

System Architectures That Support Monitoring
LENIN ERAZO-GARZÓN 1, PRISCILA CEDILLO 2, (Member, IEEE), GUSTAVO ROSSI 3,
AND JOSÉ MOYANO 2

1 LIDI, Universidad del Azuay, Cuenca 010204, Ecuador
2 Department of Computer Science, Universidad de Cuenca, Cuenca 010203, Ecuador
3 LIFIA, Fac. Informática, UNLP y CONICET, La Plata 1900, Argentina
Corresponding author: Priscila Cedillo ([email protected])
This work was supported in part by the Vice-Chancellor for Research at the Universidad del Azuay under Grant 2020-0059,
Grant 2021-0040, and Grant 2022-0030; and in part by the Vice-Chancellor for Research at the Universidad de
Cuenca through the Project ‘‘Fog computing applied to monitor devices used in assisted living environments;
study case: A platform for the elderly,’’ under Grant XVIII-2018.
ABSTRACT The Internet of Things (IoT) is a technological paradigm involved in a diversity of domains
with favorable impacts on people’s daily lives and the development of industry and cities. Nowadays,
one of the most critical challenges is developing software for IoT systems since the traditional Software
Engineering methodologies and tools are unproductive in the face of the complex requirements resulting from
the highly distributed, heterogeneous, and dynamic scenarios in which these systems operate. Model-Driven
Engineering (MDE) emerges as an appropriate approach to abstract the complexity of IoT systems. However,
there are no domain-specific languages (DSLs) aligned to standardized reference architectures for IoT.
Furthermore, existing DSLs have an incomplete language to represent the IoT entities that may be needed at
the edge, fog, and cloud layers to monitor IoT environments. Therefore, this paper proposes a domain-
specific language named Monitor-IoT, which supports developers in designing multi-layer monitoring
architectures for IoT systems with high abstraction, expressiveness, and flexibility. Monitor-IoT consists
of a high-level visual modeling language and a metamodel aligned with the ISO/IEC 30141:2018 reference
architecture. In addition, it provides a language capable of modeling architectures with a wide variety of
digital entities and dataflows (synchronous and asynchronous) between them across the edge, fog, and cloud
layers to support the monitoring of a diversity of IoT scenarios. The empirical evaluation of Monitor-IoT
through the application of an experiment, which contemplates the use of the Technology Acceptance Model
(TAM), demonstrates the intention of the participants to use this tool in the future since they consider it easy
to use and useful.
INDEX TERMS Architecture, domain-specific language (DSL), Internet of Things (IoT), metamodel,
model-driven engineering (MDE), monitoring.
I. INTRODUCTION by the International Data Corporation (IDC) [4] estimates that

The Internet of Things (IoT) is a technological paradigm that there will be 41.6 billion IoT devices in 2025.
has evolved dramatically in recent years. Its growth has been Currently, one of the most critical challenges for the sci-
stimulated by the great variety of intelligent objects (things) entific community and the industry is the development of
that are being interconnected through the Internet to provide software for IoT systems because traditional Software Engi-
services to users across a broad spectrum of application neering methodologies and tools are mainly focused on the
domains (e.g., home, health, education, industry, transporta- implementation domain (programming to low level) instead
tion) [1], [2]. According to Gartner [3], the total number of of the problem domain [5]. In addition, those solutions have
IoT devices installed in 2017 (8.4 billion) already exceeded proven to be not very productive in the face of the intrinsic
the total population of human beings; furthermore, a forecast characteristics of IoT systems [6], such as i) heterogeneity,
made up of a set of physical devices, each one with different
programming interfaces (APIs), operating systems, com-
The associate editor coordinating the review of this manuscript and puting capabilities, communication protocols (e.g., CoAP,
approving it for publication was Kashif Sharif . MQTT, HTTP), and data exchange standards (e.g., XML,
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License.
For more information, see https://creativecommons.org/licenses/by-nc-nd/4.0/
VOLUME 10, 2022 61639
L. Erazo-Garzón et al.: Domain-Specific Language for Modeling IoT System Architectures That Support Monitoring
JSON, RDF); ii) distributed computing, comprises a set of applications that are characterized by requiring an infras-
computing nodes, located on the edge, fog, or cloud to achieve tructure that efficiently integrates various resources from the
a balance in the use of resources; iii) scalability, requir- edge, fog, and cloud layers in order to collect, transport,
ing the transparent expansion of its infrastructure, discover- process, and store data at different levels of aggregation for
ing and incorporating new devices or services in real-time; later analysis, unlike other IoT applications that are limited
and iv) uncertainty, operate in highly changeable scenarios, only to reacting from the data collected at that time.
making it impossible to identify all the requirements in the Monitor-IoT provides a graphical designer (high-level
development stages of an IoT system [7]. visual language) built in the Obeo Designer Community and
Therefore, there is a need to create formal Software Engi- Eclipse Sirius tools [23] to support developers in modeling
neering methods and tools adapted to the specificities of IoT IoT multi-layer monitoring architectures with a high level
systems, which simplify and speed up their development with of abstraction, expressiveness, and flexibility. Thus, devel-
a high level of abstraction, flexibility, and extensibility [6]. opers are freed from implementation details, facilitating and
Model-Driven Engineering (MDE) emerges as a promis- speeding up the development tasks. Furthermore, Monitor-
ing software development approach to bridge the problem- IoT is based on a metamodel specified in Ecore [24] and
implementation gap and consequently abstract the complex aligned with the reference architecture for IoT ISO/IEC
and dynamic aspects of the new generation of systems 30141:2018 [20] that provides a language to mainly sup-
(e.g., IoT) and their environment [8], [9]. Specifically, port: i) the definition of entities (physical or digital) to be
to address the complexity of these systems, MDE focuses on monitored; ii) the definition of digital entities (computing
developing technologies that combine domain-specific lan- nodes and their resources) that support the monitoring pro-
guages (DSLs), transformation engines, and generators [9]. cesses (data collection, transport, processing, and storage) at
There are several proposals on DSLs oriented to the IoT the edge, fog, and cloud layers; iii) the specification of the
domain [10]–[19]. However, they are not based on a globally properties to be monitored for each entity; iv) the definition
accepted metamodel or aligned with a standardized reference of dataflows between digital entities, based on synchronous
architecture for IoT (e.g., ISO/IEC 30141:2018 [20]). In turn, or asynchronous communication; and v) the establishment of
these DSLs have a language made up of a reduced set of aggregation operations for the collected data.
digital entities and dataflows (interactions) between them at It should be emphasized that although Monitor-IoT is
the edge, fog, and cloud layers; this limits the representation oriented in the first instance to the design of architectures
of the possible variants of monitoring processes that may be that support the monitoring processes of IoT systems, the
required, which depend on the hardware capabilities of the proposed metamodel is highly flexible and extensible. The
devices, microcontrollers, and servers, as well as the net- expansion and validation of Monitor-IoT to support other
work bandwidth and data volume, among the most important. types of processes (e.g., analysis, generation of reports for
According to Mineraud et al. [21], one of the research gaps decision-making, actuation) will be addressed in future work
in IoT is the absence of DSLs that offer functional primitives since the final purpose is to build a DSL that covers all the
to describe the problem and the solution space with a high stages of the MAPE-K.
level of abstraction (e.g., primitives to manage dataflows The structure of this paper is as follows: Section 2 presents
catalogs or data fusion and aggregation operations), in order a brief overview of the main concepts addressed in this
to simplify the development of IoT applications. study and a review and comparative analysis of related work.
This study is a first step towards developing a methodolog- Section 3 describes the Monitor-IoT DSL. Section 4 explains
ical approach and a set of tools based on MDE [8] and the the proposed process to design monitoring architectures for
MAPE-K feedback loop [22] to build self-aware and self- IoT systems with Monitor-IoT. Section 5 provides an illus-
adaptive IoT systems. That is, systems capable of obtaining trative example to demonstrate the usefulness of Monitor-IoT.
metrics to autonomously evaluate the current state and pos- Section 6 describes the empirical evaluation of Monitor-IoT.
sible future evolution of themselves and their environment Finally, Section 7 presents the conclusions and lines of future
and, based on this knowledge, act if necessary (e.g., explain, work.
report, suggest, self-adapt). The MAPE-K loop consists of
four stages: i) monitor or collect data on the state of the II. BACKGROUND AND RELATED WORK
system and its environment; ii) analyze the data collected The term IoT refers to a global infrastructure made up
to assess the situation and detect any anomaly or problem; of a set of ubiquitous intelligent objects interconnected
iii) plan how to adapt the system to solve a detected problem; by information and communication technologies to collect,
and iv) execute the adaptation plan based on knowledge of store, process, and analyze data from the physical and vir-
the system and its environment [22]. tual world and react with the minimum human intervention
In this context, the scope of this paper is the monitoring [7], [25], [26].
stage of the MAPE-K. Hence, a domain-specific language An IoT infrastructure includes: i) devices to collect
named Monitor-IoT is proposed to design IoT system archi- data (monitoring) or perform an action on the environment
tectures that support monitoring through the edge, fog, and (actuation), which can be standard or specialized objects.
cloud layers. Monitor-IoT DSL is mainly oriented to IoT These objects can be carried by people, be located in homes,
61640 VOLUME 10, 2022

form part of the infrastructure of a city, or be integrated ii) domain-specific language (DSL), a language with a con-
into the equipment of a factory; ii) gateways to securely crete syntax (notation), abstract syntax (metamodel), and spe-
interconnect the devices with the cloud, controlling the cialized semantics to create models in a specific domain; iii)
exchange of data between them; and iii) cloud to store, metamodel, a conceptual model of a DSL that defines the con-
process, and analyze data in real-time or in batches in cepts of language and the relationships between them, as well
order to obtain knowledge and respond to changes in the as the rules that establish when a model is well-formed; and
environment [27], [28]. iv) model transformations, to achieve the automation of the
Additionally, due to the exponential growth of IoT devices models, through their translation into code [31].
and data generated [4], a solution based solely on the cloud The following subsections present a bibliographic review
may be impractical for some IoT scenarios. Therefore, an IoT of the main proposals of reference architecture models, meta-
infrastructure may require solutions that decentralize applica- models, and DSLs existing in the literature for the IoT
tions, management, and data analysis to solve performance domain. In addition, a comparative analysis between different
problems, network congestion, security, reliability, among DSL proposals and this work (Monitor-IoT) is included.
others. In this sense, as a complement to cloud computing,
two solutions or technological paradigms have been pro- A. REFERENCE ARCHITECTURE MODELS FOR IoT
posed: edge computing and fog computing. Edge computing ISO/IEC 30141:2018 [20] provides a standardized IoT refer-
is the peripheral network layer, also known as proximity net- ence architecture, which includes a generic conceptual model
work or IoT network, encompassing the IoT devices (sensors, that describes the concepts of the common entities of an
actuators) and other devices (IoT gateways) to which the IoT IoT system and their relationships. The conceptual model
devices connect to access local or wide area networks. Its is derived into a high-level reference model, broken down
purpose is to provide local storage and processing capabilities into five architectural views: functional, system, informa-
to these devices to react immediately without transferring tion, communication, and usage. In turn, Bauer et al. [32]
the data to another location. In comparison, fog computing propose an IoT Architectural Reference Model (IoT ARM)
comprises a set of decentralized computing nodes located based on five submodels: i) domain [33], includes the main
in local or wide area networks (before the cloud) that act IoT concepts (e.g., physical entities, virtual entities, devices,
as mediating instances between the cloud and the devices resources, services) and the relationships between these;
located at the network edge (sensors, actuators, IoT gate- ii) information, defines the structure of information related
ways). Fog computing decouples the hardware and software to IoT; iii) functional, identifies groups of functionalities of
functions from the cloud, allowing dynamic reconfigurations an IoT system; iv) communication for heterogeneous IoT
of what data are stored and processed in the fog nodes and environments; and v) trust, security, and privacy for IoT.
what data are prepared and sent to the cloud for storage and In the same way, Patel et al. [34], [35] present a methodology
further analysis. Therefore, fog computing is hierarchical, that separates the development of IoT applications into four
running different IoT applications that process data from a concerns: domain, functional, implementation, and platform,
large number and diversity of devices, unlike edge comput- which are represented in a conceptual model.
ing, which runs specific IoT applications for a small number
of devices [29]. B. METAMODELS AND DSLs FOR IoT
Consequently, IoT takes advantage of a large part of
Concerning metamodels and DSLs for the IoT domain, the
existing and emerging technologies, combining them to cre-
most relevant proposals are described and analyzed below:
ate new products and services, and ultimately improve the
user experience. Among the IoT-enabled technologies are: 1) Eterovic et al. [10] focus on creating an IoT systems
communication networking technologies, sensing/control development language powerful enough for profession-
technologies, device/hardware technologies, and software als and understandable enough for end-users that pro-
technologies [1], [2]. vide the requirements. Hence, they propose a Visual
Model-Driven Engineering (MDE) is a software develop- Domain-Specific Modeling Language (VDSML) for
ment approach in which domain models are created and sys- IoT using a stereotype-based UML profile. The VDSML
tematically transformed into concrete implementations [8]. allows the modeling of real and virtual things, which
Therefore, MDE increases the importance of models since can contain a virtual collection of items, such as inputs
they are used for documentation and communication, and as (sensors), outputs (actuators), and software components.
central artifacts of the software development process. Fur- One limitation is the low specialization of the language,
thermore, models raise the abstraction level and automation requiring more specific stereotypes to represent edge,
of the development process, which favors the management fog, or cloud nodes, as well as software components,
of software complexity and change, and improves several of such as middleware, services, applications, or databases.
the quality attributes of software (for example, productivity, Additionally, a usability test was used to validate the
maintainability, flexibility) [30]. VDSML by calculating the SUS (System Usability
The fundamental elements of MDE are: i) model, Scale) score, task success rate, time on task, and user
abstract representation of an aspect of a software system; error rate.
VOLUME 10, 2022 61641

2) Salihbegovic et al. [11] propose DSL-4-IoT to tackle was performed to determine the level of expressivity of
the complexity and heterogeneity of IoT systems. This SoaML4IoT.
is a VDSML to design the structure of an IoT system 7) Alulema et al. [16] present a model-driven approach that
using hierarchical blocks (system, subsystem, devices, includes a DSL, a graphical editor, and a Model to Text
device channels) mainly focused on the edge layer. The (M2T) transformation to generate the code for IoT nodes
blocks can be saved in libraries to support reusability containing controllers, sensors, and actuators. Conse-
and scalability. The configuration files generated on quently, this solution only targets the edge layer of an
the DSL-4-IoT run on the OpenHAB runtime engine. IoT platform. In turn, the authors designed a smart home
In turn, to demonstrate the viability and usability of the scenario to demonstrate the functionality and feasibility
solution, an IoT testbed was implemented, spanning a of the proposed approach.
variety of static and mobile sensors in two application 8) C. G. Garcia et al. [17] propose a graphical
domains (smart home and remote patient monitoring). DSL (MOCSL) aimed at people without programming
3) ThingML [12] includes a modeling language, a method- knowledge in order to facilitate the creation of native
ology, and tools to support multiplatform code gener- applications for smart objects interconnected through
ation for distributed reactive systems. The ThingML the IoT Midgar platform. With MOCSL, users can create
language comprises two structures: i) Things that rep- the necessary logic for their objects by only selecting
resent software components; and ii) Configurations that the sensors and actuators they want to use on their
describe their interconnection. Software components smartphone or Arduino. Therefore, MOCSL also only
can include properties, functions, messages, ports, and focuses on the edge layer of an IoT platform. In addition,
state machines. However, ThingML does not allow mod- to validate the usefulness and efficiency of the solution,
eling the nodes on which the software components run the authors carried out an experiment in which two
at the edge, fog, and cloud layers. Several case studies, profiles of participants with different levels of knowl-
combining various implementation platforms, were car- edge about smart objects had to create a basic Arduino
ried out to evaluate ThingML. application using MOCSL and another graphical editor.
4) Pramudianto et al. [13] present an architecture for devel- 9) Barriga et al. [18] have built a DSL (SimulateIoT) to
oping IoT prototypes, separating domain modeling from design, code, and deploy IoT system simulations. The
technological implementations. Using a model-driven solution comprises a domain metamodel, a graphical
tool called IoTLink, domain experts can create domain concrete syntax, and model-to-text transformation algo-
models, composing virtual objects linked to implemen- rithms. The IoT simulation model created in the graph-
tation technologies (sensors, actuators) to abstract their ical editor can include sensors, actuators, fog nodes,
complexities and specificities. IoTLink generates arti- cloud nodes, databases, and complex event processing
facts in Java from the defined model. As with ThingML, engines. However, these elements can only be connected
a disadvantage of IoTLink is that it does not cover mod- using asynchronous communication protocols (publish-
eling of the compute nodes on which Java artifacts reside subscribe). The solution was implemented in two case
and run. Finally, IoTLink was evaluated against classical studies of IoT environments (smart building and agricul-
Java development using a controlled experiment in terms ture) to demonstrate the expressiveness of the solution
of development time and user satisfaction. through the opinion and impression of the authors, sug-
5) Negash et al. [14] introduce a flexible and scalable gesting a need for the use of more rigorous techniques
approach that enhances programmability and modifia- (based on statistics) to test the end-user perception.
bility in the perception layer of an IoT system, especially 10) Alfonso et al. [19] propose a DSL to model the static
in resource-constrained devices. The approach uses a and dynamic aspects of an IoT deployment. The DSL
domain-specific language (DoS-IL) with a textual nota- includes an MPS projectional editor with textual, tab-
tion to write lightweight scripts and store them in a gate- ular, and tree view notation. Furthermore, the solution
way. In turn, the scripts are requested and executed by comprises a prototype Kubernetes manifest generator
the perception layer devices using an embedded resource to deploy the modeled IoT systems. This work only
browser that integrates a DoS-IL interpreter and manip- provides a proof of concept of the code generator pro-
ulates a Device Object Model (DOM). However, this totype. Therefore, as with the previous proposal, a more
proposal does not present an empirical evaluation. rigorous empirical evaluation is required to validate the
6) Costa et al. [15] propose a DSL (SoaML4IoT) to design usability and usefulness of the DSL concerning the
SOA-based IoT systems. The DSL extends the Service end-user.
Oriented Architecture Modeling Language (SoaML)
with specific concepts of the IoT domain. The edge C. COMPARATIVE ANALYSIS
nodes are represented in a general way, requir- Based on this bibliographic review, there are important
ing specialization in sensors, actuators, tags, or IoT advances in the field of DSLs for IoT, whose common
gateways (controllers). Instead of an empirical evalua- denominator has been abstracting the complexity and het-
tion, a comparative analysis with other DSL proposals erogeneity of IoT systems to speed up their development.
61642 VOLUME 10, 2022

However, several limitations have been identified in the Model (IoT ARM) [32], there is no globally accepted
related work. Tables 1 and 2 present a comparative analysis metamodel. Ambiguities have even been observed
between the DSLs studied and Monitor-IoT. The main limi- between the solutions studied regarding the mean-
tations and challenges encountered and that are addressed in ing and use of various IoT terms and concepts,
this paper through Monitor-IoT are discussed below: the lack of consensus being an open problem.
1) Although some proposals on DSLs [13], [14] Furthermore, the proposed DSLs are not based
are based on the IoT Architectural Reference on a metamodel aligned with the standardized
TABLE 1. Comparative analysis between the DSLs studied and Monitor-IoT. (Part 1: Capacity of specification and modeling of entities, resources,
properties, and dataflows.)
TABLE 2. Comparative analysis between the DSLs studied and Monitor-IoT. (Part 2: Standardization, visual modeling language, methodology, and
empirical evaluation.)
VOLUME 10, 2022 61643

reference architecture for IoT ISO/IEC 30141:2018 (see only collect data for a single property, unlike reality,
Table 2). where there are sensors that can collect data for multiple
2) The proposals studied are based on metamodels with properties (e.g., the DHT11 sensor collects temperature
a limited language to represent the key concepts that and humidity) [18].
may be required for monitoring an IoT system, such 7) A group of DSLs [12]–[15] explicitly include the prop-
as physical entities, digital entities (computing nodes erty concept in their metamodels to characterize certain
and their resources), communication networks and pro- types of IoT entities. However, it is necessary to delve
tocols, entity properties, and dataflows between entities. into this aspect in order to propose metamodels with an
Table 1 shows in detail that, unlike Monitor-IoT, the extensible structure capable of supporting the specifi-
analyzed DSLs cannot specify or model all the key cation of various types of properties (telemetry, state,
concepts mentioned. and metadata) for any IoT entity, whether physical or
3) Regarding physical entities, three proposals [10], [13], digital (computing nodes and resources), depending on
[15] include the possibility of representing any physical the needs of each IoT scenario. In this sense, telemetry
entity in their metamodels. In turn, the proposal by properties have information about a physical entity col-
Alfonso et al. [19] allows representing only the regions lected from sensors (e.g., temperature in a room, blood
or places to monitor in an IoT scenario. pressure of a patient); state properties contain informa-
4) Most of the DSLs studied focus on the edge layer of tion that describes the current status of a digital entity
an IoT infrastructure, allowing the specification of sen- (e.g., battery power level of a sensor, amount of memory
sors, actuators, tags, and to a lesser extent, IoT gate- or processing used by an edge node, bandwidth used by
ways located in the proximity network. On the con- a network); and metadata, which have information that
trary, there are only three studies [15], [18], [19] that rarely changes and that is known at design time (e.g.,
support the modeling of fog and cloud nodes in their serial number, brand, model).
metamodels. 8) Since an IoT system can have many entities of the same
5) Some proposals represent the software and hardware type, metamodels must also support generic structures
resources used by edge, fog, and cloud nodes through (e.g., property templates per entity category) to allow
generic concepts in their metamodels. However, this common properties between entities to be specified only
limits the possibility of specifying in detail the attributes once. However, this is an aspect that is not considered
and configurations of the essential resources to monitor by the related work. Another aspect not covered is map-
and control IoT scenarios (APIs, applications, services, ping the properties to be monitored both with the APIs
databases, middlewares, brokers, network interface), responsible for collecting the data and with the storage
requiring a specialization of these resources in the structures (database, tables, columns) where said data
metamodels. In turn, although other proposals focus are stored.
on specialization, they do not represent all the essen- 9) The proposals [10], [13], [16], [18] that support the
tial resources mentioned. Therefore, metamodels that modeling of dataflows do not cover the diversity of
combine these two approaches are required, including a possibilities of communication links and data exchange
specialization/generalization relationship between sub- between digital entities (APIs, applications, services,
classes to define in detail the essential resources of an databases, middlewares, brokers) that the IoT scenar-
IoT system and a concrete superclass to represent any ios may require across the edge, fog, and cloud lay-
other hardware or software resource (e.g., CPU, RAM, ers. Depending on the hardware capabilities of the IoT
Battery). devices, the network bandwidth, and the data volume,
6) In particular, the studied solutions and their metamod- different types of digital entities and communication
els have limitations in representing the software or configurations between them may be needed to support
data resources used by a typical IoT monitoring sce- the motorization of an IoT environment. From direct
nario. Thus, only two proposals [13], [18] consider the communications between the IoT devices (sensors) and
database concept in their metamodels; however, these the cloud nodes to including intermediate nodes located
proposals do not allow modeling the logical storage on edge (IoT gateway) or fog layers, responsible for
structure of the database (tables and columns). In turn, carrying out the routing, processing (merging, aggrega-
only one study [13] allows specifying aggregation and tion), and data storage operations. Also, synchronous or
merger operations on the monitored data. Also, several asynchronous communications between digital entities
metamodels do not allow specifying the compute nodes may be required. Therefore, one of the challenges is
on which the resources reside or run. For example, to propose sufficiently flexible and extensible DSLs to
although two proposals [18], [19] contemplate using allow graphical modeling (with a high degree of abstrac-
topics to support asynchronous communication, they tion) of dataflows as a sequential set of various types
do not incorporate the broker concept to represent the of communication links between digital entities. In turn,
resource in which those topics are managed. Another it must be possible that the types of links between digital
limitation is that the solutions assume that a sensor can entities can be combined and ordered in different ways
61644 VOLUME 10, 2022

to form dataflows according to the needs of each IoT and database, data aggregation operations) were incorporated
scenario. into the metamodel. Finally, it was essential to understand
10) On the other hand, only three proposals [12], [13], [18] how entities collaborate during the monitoring processes
(see Table 2) have included as part of their solution the of an IoT environment in order to define the relationships
definition of a methodological process that guides the between said entities.
tasks of specification, modeling, and implementation of This construction approach has made it possible to ensure
IoT solutions with the support of the proposed DSL the semantic coherence of the metamodel (alignment with
tool. In this sense, it is desirable to have a method- ISO/IEC 30141:2018) and provide it with a more com-
ological process associated with a DSL tool to ensure plete and flexible language capable of modeling a variety of
that end-users can use it in a disciplined, efficient, and alternatives for monitoring processes and dataflows in IoT
effective manner. systems.
11) Finally, although most of the DSLs studied have a visual Furthermore, Monitor-IoT allows the construction of IoT
modeling language (graphical concrete syntax), few monitoring architectures with asynchronous and synchronous
proposals [10], [13], [17] have carried out a rigorous communication between the computing nodes. In the first
empirical evaluation based on the end-user perception case, the sending and receiving of data are temporarily sep-
to validate the ease of use and usefulness of the DSL arated, which is crucial for improving the performance of
tool (see Table 2). However, these proposals focus only large-scale IoT systems. Whereas in the second case, the data
on the edge layer or have a limited modeling language. exchange (sending - receiving) is carried out in real-time to
On the contrary, those proposals that focus on the edge, prioritize those requests that require an immediate response.
fog, and cloud layers [15], [18], [19] do not include The Monitor-IoT metamodel has been specified in Ecore,
an empirical evaluation or have only validated their using the tools included in the Eclipse Modeling Framework
solutions based on the opinion and impression of their (EMF) [24]. Fig. 1 presents an extract of the metamodel
authors. with the main metaclasses and relationships. In contrast,
Fig. 9, 10, 11, and 12 (shown in Appendix A) contain the com-
III. MONITOR-IoT DSL plete metamodel, including all metaclasses, relationships,
First, the Monitor-IoT metamodel (abstract syntax) is attributes, and enumerations. The metaclasses included in the
described, including a review of the main metaclasses figures are identified with a number enclosed in a circle of
and their relationships (subsection A). Then, the Monitor- different colors. The red identifies the metaclasses aligned
IoT graphical designer (concrete syntax) is presented with ISO/IEC 30141:2018, the blue identifies the metaclasses
(subsection B). selected from the proposals studied (related work), and the
green identifies the additional metaclasses incorporated by
A. MONITOR-IoT METAMODEL the researchers of this work.
The Monitor-IoT metamodel was built from the reference The most important Monitor-IoT metaclasses are described
architecture for IoT ISO/IEC 30141:2018. This architec- below, while the remaining metaclasses are detailed in
ture includes a generic and abstract conceptual model that Appendix.
describes the concepts of the key entities (physical and digi- MonitoringArchitectureModel. Main metaclass that
tal) and their relationships within a typical IoT system [20]. describes and contains the multi-layer monitoring architec-
Hence, the key entities and relationships of this conceptual ture model of an IoT system (see Fig. 1(1), 9(1), and 11(1)).
model were reused to create the metamodel. This reuse (align- IoTSystem. Represents a system composed of a set of
ment) provides the metamodel with a common vocabulary physical (things) and digital entities that interact and coop-
that can be used unambiguously in any IoT subdomain or erate in the collection, transmission, processing, and storage
implementation. Specifically, 18 of the 21 concepts contained of data from the physical and virtual world, as well as to
in the conceptual model were reused. Most of the reused act on physical entities from digital instructions, in order
concepts (entity, physical entity, digital entity, network, IoT to provide services to end-users in a variety of domains
user, human user, non-human user, IoT device, sensor, tag, (e.g., home, health, transportation, industry). The metamodel
actuator, IoT gateway, application, service, database) have enables the representation of IoT ecosystems by reusing the
been represented as metaclasses in the metamodel, except physical and computational capabilities of individual IoT sys-
three concepts (domain, endpoint, identifier) that have been tems (subsystems) existing in different domains. This solu-
included as attributes of metaclasses (see Fig. 9 and 10). tion contributes to the provision of smarter emerging services
Then, based on the analysis of the related work, the most com- with efficient use of resources. For example, an emerging
mon entities among the proposals, which also are relevant for IoT disaster recovery ecosystem can be made up of a trans-
data collection, transport, processing, and storage of an IoT portation system, a health system, and an emergency system
system, were included in the metamodel. In turn, additional (see Fig. 1(2) and 9(2)).
entities necessary to represent important monitoring aspects Entity. A global concept; it represents anything (physical
not covered (e.g., dataflows, property templates, database or digital) with distinctive and independent characteristics
structure, middlewares, brokers, property mapping with APIs (e.g., places, people, home appliances, electronic devices,
VOLUME 10, 2022 61645

FIGURE 1. Extract of the Monitor-IoT metamodel with the main metaclasses and relationships.
servers, communication networks, software components). DigitalEntity. Represents a computational element (at the
In some of the proposals studied, it is often called ‘‘entity hardware or software level) of an IoT system. These elements
of interest’’ to highlight that it is something of user interest to can be: cloud nodes, fog nodes, IoT gateways, IoT devices
achieve their objectives (see Fig. 1(4) and 9(4)). (sensors, tags, actuators), middlewares, databases, services,
PhysicalEntity. Represents a real-world thing that is mon- APIs, applications, network interfaces, among others. There-
itored by a sensor and/or controlled by an actuator. Physical fore, digital entities can be specialized in: computing nodes
entities can be: living organisms, objects, or the environ- and hardware or software resources (see Fig. 1(8) and 9(9)).
ment (e.g., buildings, people, animals, vehicles, home appli- Property. Defines an attribute that characterizes a partic-
ances, articles, clothing, electronic devices). A physical entity ular physical or digital entity. Properties make it possible to
extends to the digital world by incorporating, containing, identify or describe an entity, determine its state at a given
or carrying one or more information and communication moment, as well as its evolution over time (see Fig. 1(6),
technology devices that provide an interface to obtain infor- 9(7), 10(10), and 11(7)). In turn, the general specifications
mation or act on the physical entity. In addition, a physical of a property are contained in a template using the Proper-
entity can contain other physical entities. For example, a tyTemplate metaclass (see Appendix A).
house can contain rooms, which in turn contain home appli- IoTUser. Represents an actor or beneficiary of an IoT
ances (see Fig. 1(7) and 9(8)). system that can specialize in: i) HumanUser, a person who
61646 VOLUME 10, 2022

interacts with an IoT system through one or more appli- Protocol / Representational State Transfer) (see Fig. 1(9, 23),
cations that run on user devices (e.g., personal computer, 9(10, 24), and 10(5, 15)).
tablet, smartphone, other specialized devices); and ii) Non- DataFlow. Represents with a high level of abstraction
HumanUser, machine, artifact, or device (e.g., robot, vehicle) the trajectory of the data and how digital entities (nodes
that acts on behalf of human users and can interact with or resources) interact within a process of data collection,
one or more services offered by an IoT system through a transfer, processing, and storage. In this sense, a dataflow
communication network (see Fig. 1(10-12) and 9(11-13)). describes how the raw data collected by IoT devices are trans-
ComputingNode. Represents a digital entity with capabil- ported through the different computing nodes and resources
ities to collect, exchange, process, and store data in an IoT until stored (at different levels of aggregation) in the cor-
system. Computing nodes can be located on the cloud, fog, responding columns and tables of a database. The execu-
or edge layers. In addition, these nodes can contain hardware tionTimeInterval and flowExecutionTime properties define
and software resources, such as network interfaces, middle- the frequency and time of dataflow execution, respectively.
ware, brokers, databases, services, APIs, or applications (see The communication type supported by a dataflow can be:
Fig. 1(13), 9(14), and 10(2)). i) synchronous, uses a request/response model, where the
CloudNode. A centralized computing node with high sending - receiving of data is carried out in real-time between
capacities to process, analyze, and store the data obtained a source digital entity (client) that makes the request and a
directly from the IoT devices or fog and edge intermediate destination digital entity (server) that receives the request;
computing nodes (see Fig. 1(15) and 9(16)). and ii) asynchronous, uses an event-based data publica-
FogNode. A decentralized computing node that acts as tion/subscription model, that is, the data sent by the issuing
a mediating instance between the cloud and edge devices digital entities (publishers) are published through topics in
(sensors, actuators, IoT gateways). Fog nodes play the role an intermediate entity (Broker) so that the receiving digital
of the intermediate layer; they decide what data are stored entities (subscribers) can read them later. A dataflow com-
and processed in this layer and what data are prepared and prises a set of ordered and interconnected links (Link meta-
sent to the cloud for storage and subsequent analysis. The class). Each link allows communication and data exchange
objective of fog nodes is to reduce costs, latency, and data between two digital entities. The link types supported by
traffic on the network by implementing data storage and the metamodel are: API-IoTDevice, App-API, Service-API,
processing nodes closer to the source, that is, to IoT devices App-Service, App-Broker, Service-Broker, Service-Service,
(see Fig. 1(16) and 9(17)). and Service-Database. The previousLink relationship defines
EdgeNode. A computing node or device located at the the order of the links that make up a dataflow. Further-
network edge of an IoT system. Edge nodes can be: IoT more, a dataflow contains one or more data mapping rules
devices (sensors, tags, actuators) or IoT gateways. Therefore, (DataMappingRule metaclass) to map data sources (source)
they can have varied hardware capabilities, being capable to storage locations (destination) of a dataflow; whereas
of storing and processing data on the same device, that is, links define how the data will be transported between the
at the network edge. Furthermore, these nodes can be located source and the destination (traceability). Data mapping rules
close to or embedded in physical entities to provide them can specialize in metaclasses: i) PropertyToDataColumn,
with detection, processing, storage, or actuation capabilities associates an entity property with a table column; and ii)
(see Fig. 1(17) and 9(18)). DataColumnToDataColumn, associates two data columns,
Resource. Represents a software or hardware component a source column to which aggregation operations are applied,
used by the cloud, fog, or edge nodes to detect, collect, and its result is stored in a destination column. The diversity
process, and store data on physical entities and act on these of configurations and combinations of links between digital
entities based on digital instructions. The resources can entities that a dataflow can support provides flexibility and
be specialized in: network interfaces, APIs, applications, extensibility to the metamodel. Thus, in addition to data col-
middlewares, services, databases, or configuration files (see lection and aggregation flows, the metamodel could support
Fig. 1(14), 9(15), and 10(1)). report generation flows for decision-making and actuation
Network. Represents an infrastructure that supports the flows. However, in this paper, only the first two types of
communication and exchange of data between a set of dig- dataflows are evaluated, leaving the others to be addressed
ital entities. The metamodel supports various communica- in future work (see Fig. 1(38-42), 10(22-30), and 11(2-8)).
tion technologies (e.g., Ethernet, Wi-Fi, Bluetooth, Zigbee,
Ultra-Wideband, RFID) and communication protocols (meta- B. MONITOR-IoT GRAPHICAL DESIGNER
class Protocol) to interconnect heterogeneous IoT nodes Monitor-IoT provides a graphical design tool (high-level
with diverse hardware capabilities. Communication proto- visual modeling language) that simplifies and facilitates the
cols, according to their functions, are organized in layers. creation and maintenance of multi-layer monitoring archi-
For example, at the application layer level, there are several tecture models for IoT systems conforming to the domain
useful protocols for different IoT scenarios, such as CoAP vocabulary (metamodel) presented in the previous subsec-
(Constrained Application Protocol), MQTT (Message Queue tion. The graphical designer has been built in Obeo Designer
Telemetry Transport), and HTTP/REST (Hypertext Transfer Community Edition and Eclipse Sirius [23] to take advantage
VOLUME 10, 2022 61647

of the modeling technologies included in EMF (Eclipse Mod- automatically generate the code that supports the commu-
eling Framework) and GMF (Graphical Modeling Frame- nication interfaces and data exchange between the software
work). In this way, Monitor-IoT supports creating a modeling resources. For example, a monitoring architecture model may
workbench comprising a set of editors (diagrams, tables, contain a dataflow that relates to the following digital entities:
trees) whose structure and behavior are determined by the i) an API that obtains data from a CO sensor; ii) a software
metamodel. Fig. 2 shows the graphical notation (concrete application on a gateway that receives the data from the
syntax) for each Monitor-IoT metaclass. API and sends them through a web service to a fog node;
Through Monitor-IoT’s visual modeling interface, devel- and iii) a web service that stores the monitored data in a
opers can create architecture models, providing only high- database of the fog node (see Fig. 5). The specifications of
level specifications about the digital entities (e.g., sensors, this dataflow can be used to automatically include, as part of
APIs, applications, services, brokers, databases) and interre- the programming logic of the gateway application, the code
lationships between these (dataflows) required at the edge, to call the API of the CO sensor and obtain the monitored
fog, and cloud layers to support the monitoring processes of data. Also, the code to consume the web service and transfer
an IoT system; without worrying about how these entities and the monitored data to the fog node (synchronous commu-
dataflows should be implemented or coded at a low level. nication) can be added below. Likewise, in the body of the
In turn, Monitor-IoT creates a serialized monitoring archi- web service, the code to store the monitored data and its
tecture model in XMI so that a computer can interpret it. metadata in a specific table of the fog node database can be
Hence, the specifications included in these models can be encapsulated.
processed by transformation algorithms to automatically gen- This development approach on which Monitor-IoT is based
erate the software resources of an IoT system in charge of sup- allows developers to focus their efforts on defining the prob-
porting the monitoring operations (e.g., APIs, applications, lem while freeing them from tasks such as coding APIs,
services, brokers, topics, databases). applications, or web services, creating topics in a broker,
In particular, the interrelationships (links) between the or constructing the logical storage structure of a database
digital entities that are part of the dataflows can be used to (tables and columns).
FIGURE 2. Monitor-IoT DSL graphical notation.
61648 VOLUME 10, 2022

Consequently, the monitoring architecture models obtained high cohesion and low coupling between its parts, and
from Monitor-IoT constitute an abstraction layer that acts in this way, promote the reuse of the computational and
as a bridge between the monitoring requirements of an IoT physical capacities of all or part of the IoT system in
system and its implementation details. Furthermore, this other applications or scenarios. The data to document
abstraction layer represented by models and its alignment for each system or subsystem are: acronym (identifier),
with the ISO/IEC 30141:2018 standard allows Monitor-IoT name, description, and application domain to which it
to be used in any subdomain and technology platform of belongs.
IoT. As the models generated by Monitor-IoT are high-level 1.2) Identification of entities. Defines the physical or digital
domain specifications, the target technology platform can entities to monitor. In addition, it determines the digital
be quickly changed by implementing new transformation entities (computing nodes and IoT devices), the hard-
algorithms; however, the specifications of the IoT monitoring ware/software resources (e.g., network interfaces, mid-
architecture models remain fixed. dlewares, databases, services, APIs, applications), and
Currently, a transformation engine (synchronizer) is being the communication networks necessary to support the
implemented in Node.js to automatically create the software monitoring processes at the cloud, fog, and edge layers.
components of the IoT system (e.g., APIs, applications, ser- The entities are organized and grouped into subsystems
vices, brokers, topics, databases) from the monitoring archi- if they exist. The main data documented by entity are:
tecture model. These components allow collecting the data name, description, metaclass, category, and subsystem
from sensors, performing aggregation operations on these to which it belongs.
data, and storing them in the respective databases. Although 1.3) Identification of entity properties. Describes the prop-
medium-term, the focus will be on an engine capable of erties to be monitored for each entity. The data to be
maintaining a causal relationship between an IoT system and specified are: name and definition of the property, type
its architecture model at runtime so that any change in the of property (telemetry, state, metadata), data type and
IoT system is reflected in the model and vice-versa, without measurement unit of the property, if the property allows
having to halt its operation. the unique identification of the entity, and whether the
Finally, the source files of the Monitor-IoT tool and a video property value is assigned at design or run time.
that explains the steps for its configuration and execution can 1.4) Identification of dataflows. In this task, the dataflows
be obtained from the tool’s website: https://sites.google.com/ are specified, describing how the digital entities interact
uazuay.edu.ec/dslmonitoriot. with each other to support data collection, transport,
processing, and storage. The data to be documented are:
IV. DESIGN PROCESS OF IoT MONITORING description and type of dataflow (collection or aggre-
ARCHITECTURES USING MONITOR-IoT gation), type of communication that the dataflow uses
The proposed process to model the multi-layer monitoring (synchronous or asynchronous), and frequency and time
architecture of an IoT system using Monitor-IoT consists of of dataflow execution.
three main activities: i) Identification of subsystems, entities,
properties, and dataflows; ii) Modeling of subsystems, enti- 2) MODELING OF SUBSYSTEMS, ENTITIES, AND PROPERTIES
ties, and properties; and iii) Modeling of dataflows. In turn, First modeling activity that uses the Monitor-IoT DSL.
each activity is divided into several specific tasks. In Fig. 3, In general terms, this activity focuses on modeling the hier-
the process diagram based on SPEM 2.0 (Software & Sys- archical structure between the system and its subsystems,
tems Process Engineering Meta-Model Specification) [37] is designing the structure between physical and digital entities
presented, which details the execution order of the activities (computing nodes and their resources), and configuring the
and tasks defined to design IoT monitoring architectures with properties to monitor for each entity. This activity is divided
the support of Monitor-IoT, as well as the input and output into seven tasks, several of which run in parallel:
artifacts that are used during the process. The activities and 2.1) Modeling of subsystems. Designs the hierarchical
tasks included in the process diagram are described below. structure between the IoT system and its subsystems if
it exists. In addition, this task groups the entities into
1) IDENTIFICATION OF SUBSYSTEMS, ENTITIES, subsystems, being able a physical or digital entity to be
PROPERTIES, AND DATAFLOWS reused by several subsystems.
This activity receives as input the specification of functional 2.2) Modeling of physical entities. Designs the hierarchical
and non-functional requirements of an IoT system to analyze structure between the physical entities identified in the
it and prepare the documentation required by the Monitor-IoT first activity.
DSL to carry out the subsequent monitoring architecture 2.3) Modeling of computing nodes at the edge, fog, and
modeling activities. This activity is divided into four tasks: cloud layers. Adds to the model the cloud nodes, fog
1.1) Decomposition of the IoT system. Defines the hierar- nodes, gateways, and/or IoT devices (sensors, tags,
chical structure of the IoT system, breaking it down into actuators) specified in the first activity and necessary to
subsystems if they exist. This task aims to promote the support the monitoring processes of the IoT system. The
creation of IoT monitoring architectures that guarantee computing nodes can be contained within the physical
VOLUME 10, 2022 61649

FIGURE 3. Process diagram to design monitoring architectures for IoT systems with Monitor-IoT.
61650 VOLUME 10, 2022

entities to provide them with detection, processing, stor- a CO and smoke sensor has been installed in the kitchen
age, or actuation capabilities. (see Fig. 4(b)). These sensors collect data from the environ-
2.4) Modeling of resources used by computing nodes. Adds ment every 10 minutes. In addition, the user has a smartwatch
to the model the hardware and software resources (Samsung Galaxy Watch3) that includes a heart rate sensor,
required by the computing nodes specified in the first which collects data every 30 minutes (see Fig. 4(c)).
activity. The IoT platform also includes the use of two gateways.
2.5) Modeling of communication networks and protocols. On the one hand, a microcontroller (Raspberry Pi 3) that
Adds to the model the networks and protocols that executes a software application (environmentController) that
support synchronous and asynchronous communication calls two APIs (getTemperature, getCO&Smoke) to collect
between digital entities. In addition, it establishes the the data from the temperature, CO, and smoke sensors via
networks and protocols used by each of the software Bluetooth (see Fig. 4(d)). In turn, the software application
resources (e.g., middlewares, databases). synchronously sends the collected data to a local server
2.6) Configuration of entity categories. This task groups located in the user’s home (fog node), consuming a REST-
entities of the same type (they share common properties ful service provided by the fog node. On the other hand,
to be monitored) into categories. the smartwatch (Samsung Galaxy Watch3) acts as a gate-
2.7) Configuration of entity properties. In this task, the way that runs an App (healthController) that calls an API
properties to be monitored are created, together with (getHeartRate) to retrieve data from the heart rate sensor
their templates containing the properties’ general spec- (see Fig. 4(c)). Additionally, the App asynchronously sends
ifications. The information contained in the templates the collected data to the fog node, using a broker as an
can be reused later in the configuration of common intermediary.
properties for other entities. The gateways and the fog node communicate over a Wi-Fi
local area network using the application protocols: HTTP
3) MODELING OF DATAFLOWS (synchronous communication) and MQTT (asynchronous
Once the physical and digital entities have been incorporated communication).
into the model, this last activity designs how digital entities
interact to support dataflows, for which it is divided into two B. FOG LAYER
tasks: As mentioned, this layer contains a server (HP Proliant
3.1) Data mapping. In this task, the data sources (source) are Microserver) located in the user’s home with local stor-
mapped to the logical storage locations (destination) for age and processing capabilities (see Fig. 4(e)). In addition,
each dataflow. this fog node includes the following resources: i) a Post-
3.2) Modeling of links between digital entities. For each greSQL database management system whose objective is
dataflow, an ordered sequence of links is designed to store the low-level raw data from all the sensors of the
between the digital entities. This sequence determines IoT platform; ii) an Eclipse Mosquitto broker that imple-
the trajectory of data and how computing nodes and ments an asynchronous data communication model (publica-
resources interact in a dataflow to transport the data tion/subscription model) between the smartwatch and the fog
from the source to its storage location. node; and iii) an application server created using the Node.js
Express framework that contains RESTful services for data
V. ILLUSTRATIVE IoT SCENARIO exchange, aggregation, and storage.
An IoT scenario within the Ambient Assisted Living subdo- The fog node provides the following services: i) a RESTful
main (see Fig. 4) is presented in this section to demonstrate service (saveEnvironmentData) that is consumed directly by
the usefulness of the Monitor-IoT DSL. The proposed sce- the Raspberry Pi 3 software application in order to send
nario aims to design a monitoring architecture for an emer- the data obtained from the temperature, CO, and smoke
gency management system aimed at older people who live sensors for storage in the PostgreSQL database (supports
alone in their homes. The system comprises two subsystems: synchronous data collection flows); ii) a RESTful service
i) an environmental control subsystem responsible for moni- (saveHealthData) in charge of obtaining the user’s heart rate
toring temperature, carbon monoxide (CO), and smoke in the data from the broker and then storing them in the PostgreSQL
house environment; and ii) a healthcare subsystem to monitor database (supports asynchronous data collection flows); and
the heart rate of the older adult. For this, the subsystems iii) a RESTFul service (saveHealthSummaryDaily) that cal-
require various computing devices and nodes at the edge, culates the daily average, maximum, and minimum values
fog, and cloud layers, which are described in the following of the user’s heart rate and stores them in the cloud node
subsections. (supports data aggregation flows).
A. EDGE LAYER C. CLOUD LAYER

The IoT platform includes different types of sensors to sup- The proposed IoT scenario requires a cloud node imple-
port monitoring requirements. A temperature sensor has been mented on the Google Cloud Platform (see Fig. 4(f)). This
installed in the older adult’s bedroom (see Fig. 4(a)), while node has a PostgreSQL database management system to store
VOLUME 10, 2022 61651

FIGURE 4. Illustrative IoT scenario.
the data resulting from the aggregation operations executed in In Fig. 5(2), the hierarchical structure of the system is
the fog node. The fog and cloud nodes communicate over the modeled, decomposing it into subsystems. This structure
Internet using the HTTP application protocol. enables entities to be grouped, reused, and shared between
subsystems.
In Fig. 5(3), the networks and protocols that support com-
D. RESULTING ARCHITECTURE MODEL
munication between digital entities and their resources are
Once the IoT scenario has been described, Fig. 5 presents the
modeled. For this case, three networks have been designed.
multi-layer monitoring architecture designed in the Monitor-
The former is a proximity network that uses Bluetooth to
IoT DSL to solve the monitoring requirements proposed in
communicate between the sensors (temperature, CO, and
this scenario.
smoke) and the respective gateway (Raspberry Pi 3). Then,
In Fig. 5(1), the physical and digital entities are modeled,
a Wi-Fi LAN network that uses the MQTT (asynchronous
and the dataflows between them. Physical entities are orga-
communication) protocol between the smartwatch and the fog
nized hierarchically; for example, the house contains the bed-
node and the HTTP (synchronous communication) protocol
room and the kitchen, while the older adult contains (wears) a
between the Raspberry Pi 3 and the fog node. Finally, a WAN
smartwatch. The digital entities are distributed and contained
network that uses the HTTP protocol between the fog and
in the physical entities. The temperature, CO, and smoke
cloud nodes.
sensors are distributed in the rooms of the house. The gateway
The resolution of the illustrative IoT scenario has shown
(Raspberry Pi 3) and the fog node (HP Proliant Microserver)
that the Monitor-IoT tool is expressive enough to model the
are contained locally in the house. The heart rate sensor and
monitoring architecture of an IoT system with a high degree
a gateway are included in the smartwatch (Samsung Galaxy
of abstraction. Specifically, how physical and digital entities
Watch3). The cloud node (Google Cloud Platform), being
(nodes and resources) relate and interact through dataflows to
an external entity, is modeled outside the house. Concerning
support the data collection, transportation, aggregation, and
software resources, these are modeled within the computing
storage processes.
nodes following the requirements established in the IoT sce-
nario. The controller applications and sensor APIs running
on the gateways. The broker (Eclipse Mosquitto), the appli- VI. EMPIRICAL EVALUATION OF MONITOR-IoT
cation server (Node.js Express), and their RESTful services In this section, the empirical evaluation of the Monitor-IoT
running on the fog node. While the databases (PostgreSQL) DSL is presented. It is aimed to know the user perception
are located in both the fog and cloud node. about the ease of use, usefulness, and intention of future
61652 VOLUME 10, 2022

FIGURE 5. Multi-layer monitoring architecture for the IoT system specified in the illustrative scenario.
use of this tool to design monitoring architectures for IoT of undergraduate students from the last semesters of the
systems. Systems Engineering College at the University of Azuay and
For the evaluation of Monitor-IoT, a quasi-experiment was the University of Cuenca. Participants used Monitor-IoT to
used as an empirical strategy [38]. It includes the participation design a monitoring architecture for the healthcare subsystem
VOLUME 10, 2022 61653

described in the previous section as part of the illustra- TABLE 3. Questionnaire to measure perception.
tive IoT scenario. In addition, the Technology Acceptance
Model (TAM) proposed by Davis [36] was used. It integrates
user perception variables as a mechanism to predict the adop-
tion and use of Monitor-IoT in future practices.
The following subsections present the adaptation of the
TAM for the evaluation of Monitor-IoT. Also, the design,
execution, and analysis of the results of the quasi-experiment.
A. ADAPTATION OF THE TAM FOR THE EVALUATION OF

MONITOR-IOT
The TAM is a widely used model to predict the acceptance
and use of new technology. This model is based on the
following primary constructors: i) Perceived Ease of Use (E),
the degree to which a user believes that using a target system
will require less effort to perform their tasks; ii) Perceived
Usefulness (U ), the subjective probability of the user that
using a target system will improve their performance at work;
iii) Attitude Towards Using (A), user’s desire to use the target
system (both E and U predict A); iv) Behavioral Intention
to Use (BI), a measure of resistance to perform a specific
behavior, (U and A influence BI); and v) Use, represents the
current use of the system, which is predicted by BI [36].
It is necessary to operationalize the TAM for its application
in evaluating the Monitor-IoT DSL. The operationalization
consists of defining the TAM constructors based on the
relevant perception variables for Monitor-IoT and adapting These hypotheses implicitly contain the TAM variables
a measurement instrument (questionnaire) to evaluate these (E, U, and BI). Finally, In Fig. 6, the proposed model to
variables in the Monitor-IoT context. evaluate the user perception about the adoption and use of
Table 3 presents the questionnaire adapted to measure Monitor-IoT is presented.
the perception variables of the TAM, made up of twelve
questions, distributed as follows: i) five questions to measure
perceived ease of use (E); ii) four questions to evaluate the
perceived usefulness (U); iii) two questions focused on the
intention of use (BI); and iv) an open-ended question to
collect suggestions about the Monitor-IoT DSL.
In turn, the questions were formulated using the Likert
scale (5 points), assuming three as a neutral value, from which
the Monitor-IoT tool can be accepted or rejected according to
the perception variables.
According to the adaptation of the TAM, the probability
that the Monitor-IoT DSL will be accepted in practice can be FIGURE 6. Model adapted from the TAM to evaluate the user perception
of the use of Monitor-IoT.
predicted by testing the following hypotheses:
• H10 : The Monitor-IoT DSL is perceived as difficult to
use, H10 = ¬H11 . B. DESIGN OF THE QUASI-EXPERIMENT
• H20 : The Monitor-IoT DSL is not perceived as useful, The quasi-experiment was designed based on the experi-
H20 = ¬H21 . mental process proposed by Wohlin et al. [39]. As a first
• H30 : There is no intention to use the Monitor-IoT DSL step, the quasi-experiment goal was formulated according
in the future, H30 = ¬H31 . to the Goal-Question Metric (GQM) paradigm proposed by
• H40 : The perceived usefulness is not determined by the Basili et al. [40]. In addition, the research questions were
perceived ease of use, H40 = ¬H41 . defined. Tables 4 and 5 present the goal and the research
• H50 : The intention to use is not determined by the questions, respectively.
perceived ease of use, H50 = ¬H51 . Research questions were evaluated through hypothesis
• H60 : The intention to use is not determined by the testing. In particular, the first question was studied through
perceived usefulness, H60 = ¬H61 . the hypotheses: H10 , H20 , and H40 . Moreover, the second
61654 VOLUME 10, 2022

TABLE 4. Goal-question-metric for the quasi-experiment. description of the process to design monitoring architectures
for IoT systems using Monitor-IoT; and iv) a worksheet with
the description of the experimental exercise (design of the
monitoring architecture for the healthcare subsystem), which
includes several fields to collect metrics on the activities
carried out by the participants and the products obtained.
The experimental material was distributed to the participants
through a website.
C. EXECUTION OF THE QUASI-EXPERIMENT

The quasi-experiment was carried out virtually on the Zoom
TABLE 5. Research questions. platform with 33 undergraduate students of the Systems Engi-
neering College, 21 belonging to the University of Cuenca
and 12 to the University of Azuay. In addition, it lasted four
hours and was divided into two sessions.
The first session focused on the training of the participants.
This session lasted an hour and a half. It included the follow-
ing activities: i) presentation of the main concepts related to
Monitor-IoT (e.g., Internet of Things, systems architecture,
question was analyzed through the hypotheses: H30 , H50 , domain-specific languages); ii) explanation and support in
and H60 . the installation and configuration process of Monitor-IoT,
Regarding the quasi-experiment context, it was determined iii) review of the work environment (design area, tool palette,
by: i) the Monitor-IoT DSL tool; ii) the IoT scenario used properties window) of Monitor-IoT, how to instantiate the
in the Monitor-IoT evaluation, which is within the Ambi- elements of the DSL, define their properties, and interconnect
ent Assisted Living subdomain and consists of the design them with each other; and iv) resolution of the training exer-
of the monitoring architecture for the healthcare subsystem, cise in order to demonstrate how Monitor-IoT should be used
described in Section 5; and iii) the participation of 33 under- to design a monitoring architecture according to the process
graduate students from the last semesters of the Systems presented in section 4.
Engineering College at the University of Azuay and the Uni- The second session was oriented to the development of the
versity of Cuenca, who have solid knowledge about Software experimental exercise by the participants. This session lasted
Architectures, Model-Driven Development, and Internet of two and a half hours, distributed as follows: i) 20 minutes to
Things. present the practical case (healthcare subsystem) to be solved
The quasi-experiment tasks were defined systematically with the Monitor-IoT tool; ii) 120 minutes to design the mon-
and orderly, following the proposed process to design monitoring architecture of the experimental exercise; however,
itoring architectures for IoT systems with the support of the it should be noted that the participants were allowed to finish
Monitor-IoT DSL presented in section 4. the experiment, even if time was running out in order to
The quasi-experiment dependent variables to evaluate mitigate the ceiling effect; and iii) 10 minutes to answer a
Monitor-IoT were the perception variables defined in the questionnaire in Google Forms with the questions presented
TAM (E, U, and BI). These variables allowed testing the in Table 3, as well as to send the resolved worksheet of the
hypotheses and were measured using the questionnaire pre- experimental exercise and the file with the architecture model
sented in Table 3. obtained in XMI format. The researchers responsible for
The quasi-experimental material consisted of the docu- experimenting clarified any doubts or questions throughout
mentation and tools necessary to carry out the experimental the development of the experimental exercise.
tasks and a questionnaire (Google Forms) to measure the
user perception once the experiment was carried out. The D. RESULTS OF THE QUASI-EXPERIMENT
supporting documentation included: i) a presentation used by Descriptive statistics, box plots, and tests with the support of
the researchers to train the participants, which describes the the SPSS V20 tool (with α = 0.05) were used to analyze
main concepts related to the Monitor-IoT DSL, the base soft- the data collected from the experimental exercise. The data
ware (Obeo Designer Community Edition) used by Monitor- were analyzed to contrast the established hypotheses that
IoT, the Monitor-IoT graphical designer’s work environment, include the TAM perception variables (E, U, and BI). For
and a training exercise that contemplates the design of the the acceptance or rejection of the hypotheses, the significance
monitoring architecture of the environmental control subsys- levels suggested by Moody [41] were used.
tem, described in the illustrative IoT scenario (section 5); Before analyzing user perception, the monitoring archi-
ii) a video tutorial with the description of the steps for the tecture models for the health subsystem designed by the
installation and configuration of the Monitor-IoT tool; iii) a participants were evaluated concerning the requirements
video tutorial on the training exercise; iii) a guide with the established in the experimental scenario. The evaluation
VOLUME 10, 2022 61655

results determined that all 33 participants satisfactorily ful- to use (BI). The simple linear regression statistical method
filled the experimental requirements and tasks. Therefore, all has been used to test the hypotheses H40 , H50 , and H60 .
the cases were qualified as valid for further analysis. These hypotheses are defined as causal relationships between
the variables indicated above. The results obtained for each of
1) ANALYSIS OF THE USER PERCEPTION the causal relationships are described below:
Fig. 7 presents the box plots for each perception variable. As a • Perceived Ease of Use vs. Perceived Usefulness. A
common denominator, it is evident that the mean of each vari- linear regression model was constructed with E as the
able is greater than the neutral value (3) of the Likert scale. independent variable and U as the dependent variable,
In turn, the box plot of the intention to use variable (BI) shows as presented in (1). The resulting model shows a high
a single outlier belonging to the participant with identifier 1. significance (p < 0.01), and the coefficient of determina-
This participant has been excluded to avoid distortions in the tion (R2 ) indicates that the variable E explains 33.1% of
subsequent statistical analysis. the variance of U (see Table 7). Consequently, the results
allow rejecting the null hypothesis H40 and accepting its
alternative hypothesis, which means that the perceived
usefulness (U) is partly determined by the perceived ease
of use (E).
U = 2.124 + 0.547 ∗ E (1)
• Perceived Ease of Use vs. Intention to Use. The linear

regression model is presented in (2), where E is the inde-
pendent variable and BI is the dependent variable. The
resulting model has a very high significance (p < 0.001),
and the coefficient of determination (R2 ) indicates that
the variable E explains 50.1% of the variance of BI
(see Table 8). Hence, the results allow rejecting the null
hypothesis H50 and accepting its alternative hypothesis,
which corroborates that the intention of use (BI) is partly
determined by the perceived ease of use (E).
BI = 1.186 + 0.763 ∗ E (2)

FIGURE 7. Box plots of the perception variables. (E, U, and BI.)
• Perceived Usefulness vs. Intention to Use. The linear
As part of the analysis, the Shapiro-Wilk test was applied regression model is presented in (3), where U is the inde-
to check if the perception variables have a normal distribution pendent variable and BI is the dependent variable. The
and determine the type of test to be used to contrast the null model obtained has a very high significance (p < 0.001),
hypotheses H10 , H20 , and H30 . The penultimate column of and the coefficient of determination (R2 ) indicates that
Table 6 shows the results of the Shapiro-Wilk test, where it the variable U explains 48.8% of the variance of BI (see
can be observed that all the variables studied (E, U, and BI) Table 9). Therefore, the results allow rejecting the null
do not have a normal distribution (p < 0.05). Therefore, hypothesis H60 and accepting its alternative hypothesis,
the Wilcoxon one-tailed one-sample test (nonparametric test) which means that the intention of use (BI) is partly
with a test value equal to three (neutral value of the Likert determined by the perceived Usefulness (U).
scale) has been selected to contrast the hypotheses.
BI = 0.964 + 0.791 ∗ U (3)
The results of the Wilcoxon one-tailed one-sample test for
each variable are presented in the last column of Table 6,
which shows that all the perception variables (E, U, and BI) 3) DISCUSSION
have a very high level of significance (p < 0.001). Thus, these The quantitative evaluation showed that the experiment
results allow rejecting the null hypotheses H10 , H20 , and H30 , participants found the Monitor-IoT tool easy to use and
which means that, the participants perceive the Monitor-IoT useful. It even evidenced that they would be willing to use
DSL as an easy-to-use and useful tool, and they intend to use Monitor-IoT to design IoT monitoring architectures in future
this tool to design monitoring architectures for IoT systems projects. Likewise, this evaluation demonstrated that the par-
in future projects. ticipants’ perception of ease of use and usefulness partly
determines their intentions to use Monitor-IoT in the future.
2) ANALYSIS OF CAUSAL RELATIONSHIPS However, there may be other variables that influence the
At this point, the structural part of the TAM is validated in participants’ intention to use. Fig. 8 presents a synthesis of
terms of the causal relationships between the variables per- the results obtained in the evaluation of Monitor-IoT with the
ceived ease of use (E), perceived usefulness (U), and intention support of the TAM.
61656 VOLUME 10, 2022

TABLE 6. Results for perception variables.
TABLE 7. Simple linear regression model between perceived ease of use and perceived usefulness.
TABLE 8. Simple linear regression model between perceived ease of use and intension of use.
TABLE 9. Simple linear regression model between perceived usefulness of use and intension of use.
puting nodes, together with their essential resources (APIs,

applications, services, databases and their structure, brokers,
topics, network interface) at the edge, fog, and cloud lay-
ers; and iii) communication flows, both synchronous and
asynchronous. Likewise, the evaluation evidenced a saving
of time and effort when modeling the IoT monitoring sce-
narios architectures due to using a language that allows
the definition of property templates for IoT entities of the
same type. In general, the empirical evaluation has confirmed
that Monitor-IoT satisfactorily covers the limitations of the
analyzed DSLs and the challenges exposed in the related
work.
Finally, unlike related work on DSL solutions that focus on
FIGURE 8. Synthesis of the results of the application of the TAM to the edge, fog, and cloud layers, this research work designed
Monitor-IoT.
and executed a rigorous empirical evaluation to validate the
usability of Monitor-IoT based on the end-user perception.
Regarding the qualitative evaluation (open-ended ques-
E. THREATS TO THE VALIDITY OF THE
tion), a remarkable aspect is that several participants consider
QUASI-EXPERIMENT
it essential to have a methodological process associated with
Monitor-IoT since it was very helpful in fulfilling the tasks This subsection presents the main threats to the validity of
and requirements of the experiment. In turn, the participants’ the Monitor-IoT evaluation results that were mitigated during
suggestions have allowed the refinement and continuous the development of the quasi-experiment. These threats are
improvement of the Monitor-IoT tool and its methodological organized according to the classification proposed by Cook
process. and Campbell [42].
The IoT scenarios used during the pilot test and training
and experimental exercises demonstrated that Monitor-IoT 1) INTERNAL VALIDITY
has a sufficiently comprehensive domain language to In this study, internal validity is relevant because causal rela-
represent the key concepts that the diverse IoT monitoring tionships are examined. The main threats to internal validity
environments may require. In this sense, the evaluation of were the participants’ experience and the biases produced by
Monitor-IoT contemplated: i) different types of physical enti- the researchers, the experimental material, and the Monitor-
ties and properties to be monitored; ii) diversity of com- IoT tool. Regarding participants’ experience, a training phase
VOLUME 10, 2022 61657

was prepared, focused on developing a practical case that VII. CONCLUSION AND FUTURE WORK
provides participants with a clear understanding of the design The bibliographic review has shown that despite the existence
process of monitoring architectures for IoT systems with the of several proposals on DSLs oriented to the domain of IoT,
support of the Monitor-IoT DSL. In turn, the biases pro- some problems persist in this field, mainly related to the
duced by the researchers, the experimental material, and the functional limitations that DSLs present. This situation is due
Monitor-IoT tool were reduced through a pilot experiment. to metamodels that provide a limited language to represent
Here, expert researchers in the area participated during the the possible digital entities and variants of dataflows (syn-
development of the experiment in detecting and correcting chronous and asynchronous) that an IoT system may require
errors related to ambiguities in the experimental material and during the monitoring processes at the edge, fog, and cloud
usability problems of the Monitor-IoT tool. layers. Furthermore, these metamodels are not aligned with
a standardized reference architecture for IoT; even ambigui-
2) EXTERNAL VALIDITY ties have been observed between the solutions regarding the
The representativeness and generalizability of the evalua- meaning and use of various concepts.
tion results may be affected by the evaluation design and In this sense, the main contribution of this work consists
the context of the selected participants. On the one hand, of providing a domain-specific language (Monitor-IoT) to
to mitigate the threats related to the evaluation design, a suf- facilitate and streamline the design of multi-layer monitoring
ficiently complete IoT scenario was proposed, including dif- architectures for IoT systems with a high level of abstraction,
ferent types of entities (physical and digital) and types of expressiveness, and flexibility. For this, the Monitor-IoT DSL
communication (synchronous, asynchronous). In addition, comprises a graphical designer and a metamodel aligned
the IoT scenario included multiple subdomains (e.g., smart with the reference architecture for IoT ISO/IEC 30141:2018,
home, health) throughout the pilot test, training case study, which also incorporates a set of common and relevant entities
and experimental exercise. On the other hand, to reduce among the related work studied. Furthermore, it ensures the
the threats related to the context of the participants, the semantic coherence of the metamodel and provides a lan-
experiment had the participation of undergraduate students guage capable of modeling a wide variety of digital entities
from the last semesters of the Systems Engineering Col- and dataflows between them to support the data collection,
lege of several universities. These students could be con- transportation, processing, and storage processes.
sidered the next generation of professionals [43] as it has The empirical evaluation of Monitor-IoT, through the
been shown that, under certain conditions, there is not a application of a quasi-experiment and the Technology Accep-
significant difference between this type of students and pro- tance Model (TAM), demonstrated the favorable intention
fessionals [44], [45]. Therefore, the ability of these stu- of the experiment participants to design monitoring archi-
dents to design architectures for IoT systems is comparable tectures for IoT systems in future projects with the sup-
to junior professionals, even more so when only students port of Monitor-IoT; since they also consider Monitor-IoT
who had passed courses on Software Architectures, Model- as an easy-to-use and useful tool for the development of
Driven Development, and Internet of Things have been IoT systems.
selected. This work is a first step towards developing a methodology
and support infrastructure based on MDE and MAPE-K to
build self-aware and self-adaptive IoT systems. In future
3) CONSTRUCT VALIDITY
work, it is proposed to build a synchronization engine to
The main threat was the reliability of the questionnaire, for support at runtime the causal relationship between the IoT
which the Cronbach’s alpha reliability test [46] was applied system and its architecture model designed in Monitor-IoT.
to each group of questions related to the perception vari- In addition, it is necessary to continue with the evalua-
ables. The results of the tests were greater than the minimum tion of Monitor-IoT through the execution of experiments
accepted threshold (α = 0.70), obtaining a Cronbach’s alpha or case studies in other IoT subdomains with the par-
for perceived ease of use (E) of 0.808, perceived usefulness ticipation of industry professionals, as well as expanding
(U) of 0.778, and intention to use (BI) of 0.855, which shows the scope of Monitor-IoT to support the report generation
high internal consistency. dataflows for decision-making and the actuation dataflows of
an IoT system.
4) CONCLUSION VALIDITY
The sample size of 33 participants was one of the main
problems since it can affect the causality between the differ- APPENDIX
ent variables. However, the results were encouraging since ADDITIONAL METACLASSES OF THE MONITOR-IoT
all the participants successfully carried out the requirements METAMODEL
and tasks proposed in the experiment. In turn, as mentioned, This appendix presents the description of the additional meta-
a homogeneous group of participants has been selected to classes of the Monitor-IoT metamodel. In turn, it includes
control the risk of variation due to individual differences that Fig. 9, 10, 11, and 12 with all the metaclasses, relationships,
may grow due to treatment. attributes, and enumerations of the metamodel.
61658 VOLUME 10, 2022

FIGURE 9. Monitor-IoT metamodel (Part 1), includes metaclasses and relationships to represent subsystems, physical entities, digital entities
(computing nodes, IoT devices), and communication networks.
VOLUME 10, 2022 61659

FIGURE 10. Monitor-IoT metamodel (Part 2), includes metaclasses and relationships to represent computing resources and the interactions (links)
between them.
61660 VOLUME 10, 2022

FIGURE 11. Monitor-IoT metamodel (Part 3), includes metaclasses and relationships to represent dataflows, links between digital entities, and
mapping rules.
EntityCategory. Defines a grouping of entities of the same and depending on their hardware and power capabilities, they
type to specify a single time (using a template) general infor- can communicate directly or through an IoT gateway with
mation about the common properties and APIs of these enti- digital entities (cloud or fog nodes) located in local or wide
ties. This abstraction reduces the workload when modeling area networks. Sensors, tags, and actuators are a type of IoT
the IoT monitoring architecture. For example, it can create a device (see Fig. 1(18), 9(19), and 10(3)).
category that represents all the rooms to be monitored in a Sensor. An IoT device that perceives or monitors specific
house (see Fig. 1(3) and 9(3)). properties of a physical entity and transforms them into
PropertyTemplate. Defines a template with the general digital data to be transmitted over a network. For example,
specifications of a common property for all entities in a a temperature sensor that sends measurements to a smart-
category. The metamodel supports three types of properties: phone application to monitor the temperature of a room
i) metadata, which contains information that rarely changes (see Fig. 1(20) and 9(21)).
about an entity (e.g., serial number, brand, model, manufac- Tag. An object that can be applied to or incorporated into
ture date) and can be determined at design time; ii) telemetry, a physical entity to identify or trace it. The identification
data about a physical entity or the environment collected process is carried out by sensors (readers) that read the tags
through sensors (e.g., temperature or humidity in a room, (see Fig. 1(21) and 9(22)).
blood pressure of a patient); and iii) status, information that Actuator. An IoT device that acts on (changes) the proper-
describes the current status of a digital entity (e.g., battery ties of a physical entity based on digital instructions; that is, it
power level of a sensor, amount of memory or processing allows modifying the state of a physical entity. For example,
used by an edge node, bandwidth used by a network). A prop- a mobile application that connects via Bluetooth with an air
erty can uniquely identify an entity within an IoT system conditioner (actuator) to control the temperature of a room
(identifier attribute). In addition, it has a data type (dataType (see Fig. 1(22) and 9(23)).
attribute) and a measurement unit (MeasurementUnit meta- IoTGateway. A computing node located at the network
class) (see Fig. 1(5), 9(5, 6), and 10(9)). edge. It acts as an intermediary to interconnect IoT devices
IoTDevice. A device located at the network edge that asso- located in proximity networks with other digital entities
ciates physical entities in the real world with other digital enti- (cloud or fog nodes) located in local or wide area networks.
ties in an IoT system. IoT devices interact through a network, In turn, a gateway can offer a wide range of functionalities,
VOLUME 10, 2022 61661

FIGURE 12. Monitor-IoT metamodel (Part 4), includes the enumerations used by the attributes of the metaclasses.
such as i) agent for configuring, managing, and controlling NetworkInterface. Specifies an interface that connects a
IoT devices; ii) data cleaning, filtering, and routing; that is, computing node or IoT device to a communication network
it determines what data should be sent to the fog or cloud to share resources and data. A network interface uses a
nodes and what data should be processed locally; iii) storage communication technology (e.g., Wi-Fi, Ethernet, Bluetooth)
of data collected by associated IoT devices, as a solution to and has some kind of network address that consists of
problems related to intermittent or saturated communication a unique node identifier in its own right (see Fig. 1(24)
networks; iv) local data processing for fast and effective con- and 10(4)).
trol of actuators based on input data from sensors; v) protocol API (Application Programming Interface). A software
conversion and address mapping; and vi) implementation of component that encapsulates functionalities to manage IoT
security at the edge device level. Furthermore, the gateways devices (sensors, tags, actuators) with a high degree of
can be standalone equipment or be integrated with other abstraction. Specifically, an API can retrieve raw data of
IoT detection and control devices (sensors, actuators). There- the physical entities properties or act on (change) them.
fore, they can be implemented in: servers, personal comput- The metamodel allows specifying the input data (Parame-
ers, microcontrollers, smartphones, routers, virtual machines, ter metaclass) and the output information (ReturnVariable
among others (see Fig. 1(19) and 9(20)). metaclass) of an API, as well as encapsulating its instruction
61662 VOLUME 10, 2022

sequence (instructions attribute) (see Fig. 1(34, 35, 37) aggregation operations on the collected data. The metamodel
and 10(6-8)). allows specifying the connection string of the databases used.
Application. A software component that offers a set of A database contains tables (DataTable metaclass) that can be
functionalities to perform a specific task. An application can temporary or permanent. For the first case, a time interval
be: desktop, web, mobile, or embedded, and it can run on the must be defined to manage the persistence of the data. In turn,
cloud, fog, or edge nodes. Furthermore, an application can a table is made up of columns (DataColumn metaclass) that
call APIs to access the data observed by the sensors or control can be of two types: i) data, which contains the data collected
the actuators, consume services to exchange data with other or processed for a property; and ii) metadata, which contains
digital entities (synchronous communication), and publish information that describes the data collected or processed;
or receive data through a broker (asynchronous communi- for example, the IoT device that collected the data, when
cation). Finally, an application can have a visual interface the data were collected (timestamp), where the data were
to interact with human users. For example, in an IoT sys- collected, or the quality of the data collected (precision, com-
tem for a smart home, a user using an application installed pleteness). Finally, the DataInstance metaclass represents the
on a smartphone can monitor or adjust room temperature column values, that is, the values of the monitored properties
(see Fig. 1(36) and 10(11)). and their associated metadata (see Fig. 1(25-28), 10(18-21),
Service. A software component that, through an open and and 11(8)).
standardized interface, provides a set of functional capabili- Finally, Fig. 12 presents the enumerations of the Monitor-
ties to exchange, store, and process data, hiding the hetero- IoT metamodel. Note that some of the enumerations used
geneity of the entities involved. The services are contained in by the attributes of the metaclasses are not exhaustive (e.g.,
middlewares and can be accessed through endpoints. A ser- SensorType, ActuatorType, AggregationOperation, Commu-
vice can interact with other services to provide high-level nicationTechnology); that is, they do not reflect all the
functionality. Also, services can receive input data (Param- possible values. Hence, new values may be required for
eter metaclass) and produce output information (ReturnVari- the enumerations depending on the needs of each IoT
able metaclass) represented in different formats (e.g., JSON, scenario.
XML, RDF). Additionally, services can contain headers to
send metadata associated with the service request or response ACKNOWLEDGMENT
(Header metaclass) (see Fig. 1(32-35) and 10(7, 8, 12, 13)). The authors would like to thank the Universidad del Azuay
Middleware. A software component that supports and and the Universidad de Cuenca for their continued support,
provides services for synchronous and asynchronous data and David C. Siddons for revising the English translation.
management (exchange, processing, storage). This resource
facilitates interoperability between heterogeneous digital REFERENCES
entities located in a distributed manner in the edge, fog, [1] L. Atzori, A. Iera, and G. Morabito, ‘‘The Internet of Things: A sur-
and cloud layers of an IoT platform, through the implemen- vey,’’ Comput. Netw., vol. 54, no. 15, pp. 2787–2805, Jun. 2010, doi:
tation of services that hide the particular implementation 10.1016/j.comnet.2010.05.010.
[2] A. Al-Fuqaha, M. Guizani, M. Mohammadi, M. Aledhari, and M. Ayyash,
details of each digital entity. In addition, the metamodel ‘‘Internet of Things: A survey on enabling technologies, protocols, and
allows specifying one or more protocols and communica- applications,’’ IEEE Commun. Surveys Tuts., vol. 17, no. 4, pp. 2347–2376,
tion ports through which the middleware offers its services 4th Quart., 2015, doi: 10.1109/COMST.2015.2444095.
[3] R. van der Meulen. Gartner Says 8.4 Billion Connected ‘Things’
(see Fig. 1(29) and 10(14)). Will be in Use in 2017, up 31 Percent From 2016. Gartner, Egham,
Broker. It is an explicit specialization of a middleware that U.K. Accessed: Feb. 7, 2017. [Online]. Available: https://www.gartner.
supports messaging or asynchronous data transfer between com/en/newsroom/press-releases/2017-02-07-gartner-says-8-billion-
connected-things-will-be-in-use-in-2017-up-31-percent-from-2016
the digital entities of an IoT system. A broker is responsible
[4] E. Estopace. IDC Forecasts Connected IoT Devices to Generate 79.4 ZB
for receiving, organizing, and publishing the data (payload) of of Data in 2025. FutureIoT. Accessed: Jun. 22, 2019. [Online]. Available:
the IoT entities (publishers) in topics and distributing them https://futureiot.tech/idc-forecasts-connected-iot-devices-to-generate-79-
to all the IoT entities (subscribers) that have subscribed to 4zb-of-data-in-2025/
[5] X. Chen, A. Li, X. Zeng, W. Guo, and G. Huang, ‘‘Runtime model based
said topics. This data transmission model is recommended approach to IoT application development,’’ Frontiers Comput. Sci., vol. 9,
for the Internet of Things since IoT devices often have no. 4, pp. 540–553, 2015, doi: 10.1007/s11704-015-4362-0.
power, processing, and bandwidth limitations. The properties [6] C. M. Sosa-Reyna, E. Tello-Leal, and D. Lara-Alabazares, ‘‘Method-
ology for the model-driven development of service oriented IoT
data of an entity are organized and identified by the Topic applications,’’ J. Syst. Archit., vol. 90, pp. 15–22, Oct. 2018, doi:
metaclass in a Broker. Topics can be atomic if they include 10.1016/j.sysarc.2018.08.008.
data for a single property or composite if they include data [7] D. Miorandi, S. Sicari, F. De Pellegrini, and I. Chlamtac, ‘‘Inter-
net of Things: Vision, applications and research challenges,’’ Ad Hoc
for multiple properties. Furthermore, they can use different Netw., vol. 10, no. 7, pp. 1497–1516, Sep. 2012, doi: 10.1016/j.adhoc.
formats for data exchange (e.g., JSON, XML, RDF, HL7) 2012.02.016.
(see Fig. 1(30, 31) and 10(16, 17)). [8] R. France and B. Rumpe, ‘‘Model-driven development of complex soft-
DataBase. A software component that stores the data of the ware: A research roadmap,’’ in Proc. Future Softw. Eng. (FOSE), Min-
neapolis, MN, USA, May 2007, pp. 37–54, doi: 10.1109/FOSE.2007.14.
monitored properties in an IoT system. The data to be stored [9] D. C. Schmidt, ‘‘Model-driven engineering,’’ Computer, vol. 39, no. 2,
can be raw (obtained directly from IoT devices) or result from pp. 25–31, 2006, doi: 10.1109/MC.2006.58.
VOLUME 10, 2022 61663

[10] T. Eterovic, E. Kaljic, D. Donko, A. Salihbegovic, and S. Ribic, [29] M. Iorga, L. Feldman, R. Barton, M. Martin, N. Goren, and C. Mahmoudi,
‘‘An Internet of Things visual domain specific modeling language ‘‘Fog computing conceptual model,’’ National Institute of Standards and
based on UML,’’ in Proc. XXV Int. Conf. Inf., Commun. Autom. Tech- Technology, Gaithersburg, MD, USA, Tech. Rep. NIST SP 500-325,
nol. (ICAT), Sarajevo, Bosnia Herzegovina, Oct. 2015, pp. 1–5, doi: Mar. 2018. [Online]. Available: https://doi.org/10.6028/NIST.SP.500-325
10.1109/ICAT.2015.7340537. [30] B. Selic, ‘‘MDA manifestations,’’ Eur. J. Inform. Prof., vol. 9, no. 2,
[11] A. Salihbegovic, T. Eterovic, E. Kaljic, and S. Ribic, ‘‘Design of pp. 12–16, Apr. 2008.
a domain specific language and IDE for Internet of Things applica- [31] A. Kleppe, Software Language Engineering: Creating Domain-Specific
tions,’’ in Proc. 38th Int. Conv. Inf. Commun. Technol., Electron. Micro- Languages Using Metamodels. Boston, MA, USA: Pearson, 2008.
electron. (MIPRO), Opatija, Croatia, May 2015, pp. 996–1001, doi: [32] M. Bauer, N. Bui, J. D. Loof, and C. Magerkurth, ‘‘IoT reference model,’’
10.1109/MIPRO.2015.7160420. in Enabling Things to Talk, A. Bassi, Eds. Berlin, Germany: Springer,
[12] N. Harrand, F. Fleurey, B. Morin, and K. E. Husa, ‘‘ThingML: A lan- 2013, pp. 113–162, doi: 10.1007/978-3-642-40403-0_7.
guage and code generation framework for heterogeneous targets,’’ in Proc. [33] S. Haller, A. Serbanati, M. Bauer, and F. Carrez, ‘‘A domain model
ACM/IEEE 19th Int. Conf. Model Driven Eng. Lang. Syst., New York, NY, for the Internet of Things,’’ in Proc. IEEE Int. Conf. Green Comput.
USA, Oct. 2016, pp. 125–135, doi: 10.1145/2976767.2976812. Commun. IEEE Internet Things IEEE Cyber, Phys. Social Comput., Bei-
[13] F. Pramudianto, M. Eisenhauer, C. A. Kamienski, D. Sadok, and jing, China, Aug. 2013, pp. 411–417, doi: 10.1109/GreenCom-iThings-
E. J. Souto, ‘‘Connecting the Internet of Things rapidly through a model CPSCom.2013.87.
driven approach,’’ in Proc. IEEE 3rd World Forum Internet Things (WF- [34] P. Patel, A. Pathak, T. Teixeira, and V. Issarny, ‘‘Towards applica-
IoT), Reston, VA, USA, Dec. 2016, pp. 135–140, doi: 10.1109/WF- tion development for the Internet of Things,’’ in Proc. 8th Middle-
IoT.2016.7845416. ware Doctoral Symp. (MDS), Lisbon, Portugal, 2011, pp. 1–6, doi:
[14] B. Negash, T. Westerlund, A. M. Rahmani, P. Liljeberg, and H. Tenhunen, 10.1145/2093190.2093195.
‘‘DoS-IL: A domain specific Internet of Things language for resource con- [35] P. Patel and D. Cassou, ‘‘Enabling high-level application development for
strained devices,’’ Proc. Comput. Sci., vol. 109, pp. 416–423, May 2017, the Internet of Things,’’ J. Syst. Softw., vol. 103, pp. 62–84, May 2015, doi:
doi: 10.1016/j.procs.2017.05.411. 10.1016/j.jss.2015.01.027.
[15] B. Costa, P. F. Pires, and F. C. Delicato, ‘‘Modeling SOA-based IoT [36] F. D. Davis, ‘‘A technology acceptance model for empirically testing new
applications with SoaML4IoT,’’ in Proc. IEEE 5th World Forum Internet end-user information systems: Theory and results,’’ Ph.D. dissertation,
Things (WF-IoT), Limerick, Ireland, Apr. 2019, pp. 496–501, doi: 10.1109/ Dept. Sloan School Manage., MIT, Boston, MA, USA, 1985. [Online].
WF-IoT.2019.8767218. Available: https://dspace.mit.edu/handle/1721.1/15192
[16] D. Alulema, J. Criado, and L. Iribarne, ‘‘A model-driven approach for the [37] (Apr. 2008). Software & Systems Process Engineering Meta Model Spec-
integration of hardware nodes in the IoT,’’ in New Knowledge in Infor- ification Version 2.0, Object Management Group—OMG. [Online]. Avail-
mation Systems and Technologies (WorldCIST) (Advances in Intelligent able: https://www.omg.org/spec/SPEM/2.0/PDF
Systems and Computing), vol. 930, Á. Rocha, H. Adeli, L. Reis, and [38] P. Cedillo, E. Insfran, S. Abrahao, and J. Vanderdonckt, ‘‘Empirical
S. Costanzo, Eds. Cham, Switzerland: Springer, 2019, pp. 801–811, doi: evaluation of a method for monitoring cloud services based on mod-
10.1007/978-3-030-16181-1_75. els at runtime,’’ IEEE Access, vol. 9, pp. 55898–55919, 2021, doi:
[17] C. G. García, D. Meana-Llorián, V. García-Díaz, A. C. Jiménez, and 10.1109/ACCESS.2021.3071417.
J. P. Anzola, ‘‘Midgar: Creation of a graphic domain-specific language [39] C. Wohlin, P. Runeson, M. Höst, M. C. Ohlsson, B. Regnell, and
to generate smart objects for Internet of Things scenarios using model- A. Wesslén, Experimentation in Software Engineering. Berlin, Germany:
driven engineering,’’ IEEE Access, vol. 8, pp. 141872–141894, 2020, doi: Springer, 2012.
10.1109/ACCESS.2020.3012503. [40] V. R. Basili, G. Caldiera, and H. D. Rombach, ‘‘The goal question
[18] J. A. Barriga, P. J. Clemente, E. Sosa-Sánchez, and Á. E. Prieto, ‘‘Simu- metric approach,’’ in Encyclopedia of Software Engineering, vol. 1,
lateIoT: Domain specific language to design, code generation and execute J. J. Marciniak, Ed. New York, NY, USA: Wiley 1994, pp. 528–532.
IoT simulation environments,’’ IEEE Access, vol. 9, pp. 92531–92552, [41] D. L. Moody, ‘‘Dealing with complexity: A practical method for represent-
2021, doi: 10.1109/ACCESS.2021.3092528. ing large entity relationship models,’’ Ph.D. dissertation, Dept. Inf. Syst.,
[19] I. Alfonso, K. Garcés, H. Castro, and J. Cabot, ‘‘Modeling self-adaptative Univ. Melbourne, Melbourne, VIC, Australia, 2001.
IoT architectures,’’ in Proc. ACM/IEEE Int. Conf. Model Driven Eng. Lang. [42] T. D. Cook and D. T. Campbell, Quasi-experimentation: Design & Analysis
Syst. Companion (MODELS-C), Fukuoka, Japan, Oct. 2021, pp. 761–766, Issues in Field Settings. Boston, MA, USA: Houghton Mifflin, 1979.
doi: 10.1109/MODELS-C53483.2021.00122. [43] B. A. Kitchenham, S. L. Pfleeger, and L. M. Pickard, ‘‘Prelimi-
[20] Internet of Things (IoT)—Reference Architecture, Standard ISO/IEC nary guidelines for empirical research in software engineering,’’ IEEE
30141:2018, ISO, Aug. 2018. [Online]. Available: https://www. Trans. Softw. Eng., vol. 28, no. 8, pp. 721–734, Aug. 2002, doi:
iso.org/standard/65695.html 10.1109/TSE.2002.1027796.
[21] J. Mineraud, O. Mazhelisb, X. Suc, and S. Tarkoma, ‘‘A gap analysis of [44] M. Höst, B. Regnell, and C. Wohlin, ‘‘Using students as subjects—A
Internet-of-Things platforms,’’ Comput. Commun., vols. 89–90, pp. 5–16, comparative study of students and professionals in lead-time impact assess-
Sep. 2016, doi: 10.1016/j.comcom.2016.03.015. ment,’’ Empirical Softw. Eng., vol. 5, no. 3, pp. 201–214, Nov. 2000, doi:
[22] (Jun. 2005). An Architectural Blueprint for Autonomic Computing. 10.1023/A:1026586415054.
IBM, White Paper. [Online]. Available: https://www-03.ibm.com/ [45] V. R. Basili, F. Shull, and F. Lanubile, ‘‘Building knowledge through fami-
autonomic/pdfs/AC%20Blueprint%20White%20Paper%20V7.pdf lies of experiments,’’ IEEE Trans. Softw. Eng., vol. 25, no. 4, pp. 456–473,
[23] Obeo Designer Community. (11.4). OBEO—Eclipse Sirius. Accessed: Jul. 1999, doi: 10.1109/32.799939.
Feb. 7, 2022. [Online]. Available: https://www.obeodesigner.com/en/ [46] L. J. Cronbach, ‘‘Coefficient alpha and the internal structure of
product/sirius tests,’’ Psychometrika, vol. 16, no. 3, pp. 297–334, Sep. 1951, doi:
[24] Eclipse Foundation. Eclipse Modeling Framework (EMF) Documentation. 10.1007/BF02310555.
Eclipse. Accessed: Feb. 7, 2022. [Online]. Available: https://www.eclipse.
org/modeling/emf/docs/
[25] S. Madakam, R. Ramaswamy, and S. Tripathi, ‘‘Internet of Things (IoT): LENIN ERAZO-GARZÓN received the degree
A literature review,’’ J. Comput. Commun., vol. 3, pp. 164–173, Jan. 2015, in systems engineering from the Universidad de
doi: 10.4236/jcc.2015.35021. Cuenca, Ecuador, in 1999, and two master’s
[26] Internet of Things (IoT) Preliminary Report 2014, ISO, Geneva,
degrees in business administration and in software
Switzerland, Standard ISO/IEC JTC 1, 2014. [Online]. Available:
engineering and computer systems from Universi-
https://www.iso.org/files/live/sites/isoorg/files/developing_standards/
docs/en/internet_of_things_report-jtc1.pdf dad del Azuay and Universidad Internacional de
[27] P. Fremantle, ‘‘A reference architecture for the Internet of Things,’’ La Rioja, Spain, in 2012 and 2018, respectively.
WSO2, Mountain View, CA, USA, White Paper, Version 0.9.0, Oct. 2015. He is currently pursuing the Ph.D. degree in com-
[Online]. Available: https://docs.huihoo.com/wso2/wso2-whitepaper-a- puter sciences with the Universidad Nacional de
reference-architecture-for-the-internet-of-things.pdf La Plata, Argentina. He has been an Associate
[28] (2014). The Internet of Things Reference Model. Cisco, White Paper. Professor with the Universidad del Azuay, Ecuador, since 2001. His current
[Online]. Available: https://es.scribd.com/document/440866359/IoT- research interests include model-driven engineering, the Internet of Things
Reference-Model-White-Paper-June-4-2014-pdf (IoT), self-aware systems, and software quality.
61664 VOLUME 10, 2022

PRISCILA CEDILLO (Member, IEEE) received JOSÉ MOYANO received degree in the systems
two master’s degrees in telematics and in soft- engineering from the Universidad de Cuenca,
ware engineering, information systems, and for- Ecuador, in 2021. He worked for two years as a
mal methods from the Universidad de Cuenca and Research Assistant on the project ‘‘Fog comput-
the Universitat Politècnica de València (UPV), ing applied to monitor devices used in assisted
respectively, and the Ph.D. degree in computer living environments; study case: A platform for
science from UPV, in 2017. She obtained a schol- the elderly’’ at the Universidad de Cuenca. His
arship from the Senescyt for her doctoral studies interests include developing software for cloud
and from the Fundación Carolina for two post- computing and the Internet of Things.
doctoral research stays. She has been an Asso-
ciate Professor with the Universidad de Cuenca, Ecuador, since 2009. Her
main research interests include model-driven engineering, cloud computing,
software quality, and the Internet of Things (IoT).
GUSTAVO ROSSI received the Ph.D. degree from

PUC-Rio, Brazil. He is a Full Professor with Uni-
versidad Nacional de La Plata, Argentina, and a
Researcher with CONICET. His current research
interests include web engineering, requirements
engineering, and human–computer interaction.
He is a member of the Editorial Board of IEEE
INTERNET COMPUTING, IEEE IT PROFESSIONAL, and
the World Wide Web journal.
VOLUME 10, 2022 61665

A Domain-Specific Language For Modeling IoT System Architectures That Support Monitoring

Uploaded by

Copyright:

Available Formats

A Domain-Specific Language For Modeling IoT System Architectures That Support Monitoring

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

A Domain-Specific Language For Modeling IoT System Architectures That Support Monitoring

Uploaded by

Copyright:

Available Formats

Received May 11, 2022, accepted May 30, 2022, date of publication June 8, 2022, date of current version

June 15, 2022.

A Domain-Specific Language for Modeling IoT

AND JOSÉ MOYANO 2

I. INTRODUCTION by the International Data Corporation (IDC) [4] estimates that

61640 VOLUME 10, 2022

VOLUME 10, 2022 61641

61642 VOLUME 10, 2022

VOLUME 10, 2022 61643

61644 VOLUME 10, 2022

VOLUME 10, 2022 61645

61646 VOLUME 10, 2022

VOLUME 10, 2022 61647

FIGURE 2. Monitor-IoT DSL graphical notation.

61648 VOLUME 10, 2022

VOLUME 10, 2022 61649

61650 VOLUME 10, 2022

A. EDGE LAYER C. CLOUD LAYER

VOLUME 10, 2022 61651

FIGURE 4. Illustrative IoT scenario.

61652 VOLUME 10, 2022

VOLUME 10, 2022 61653

A. ADAPTATION OF THE TAM FOR THE EVALUATION OF

61654 VOLUME 10, 2022

C. EXECUTION OF THE QUASI-EXPERIMENT

VOLUME 10, 2022 61655

U = 2.124 + 0.547 ∗ E (1)

• Perceived Ease of Use vs. Intention to Use. The linear

BI = 1.186 + 0.763 ∗ E (2)

61656 VOLUME 10, 2022

TABLE 6. Results for perception variables.

puting nodes, together with their essential resources (APIs,

VOLUME 10, 2022 61657

61658 VOLUME 10, 2022

VOLUME 10, 2022 61659

61660 VOLUME 10, 2022

VOLUME 10, 2022 61661

61662 VOLUME 10, 2022

VOLUME 10, 2022 61663

61664 VOLUME 10, 2022

GUSTAVO ROSSI received the Ph.D. degree from

VOLUME 10, 2022 61665

You might also like