Content uploaded by Darwin Alulema
Author content
All content in this area was uploaded by Darwin Alulema on Apr 29, 2021
Content may be subject to copyright.
An approach to integrate IoT systems with
no-web interfaces
Darwin Alulema1,2, Javier Criado2and Luis Iribarne2
1Universidad de las Fuerzas Armadas ESPE, Sangolqu´ı, Ecuador
2Applied Computing Group, University of Almer´ıa, Spain
doalulema@sespe.edu.ec
{javi.criado,luis.iribarne}@ual.es
Abstract. The introduction of new technologies such as the Internet
of Things (IoT) raises important problems that must be solved. One of
these problems is the interoperability caused by the heterogeneity of the
protocols and platforms. In this context, the web of Things is an ar-
chitectural solution to this problem, because it takes advantage of Web
technologies as a means to guarantee interoperability. Another significant
challenge is developing and maintaining multiple variants of the applica-
tions to support different platforms. For this, Model Driven Engineering
(MDE) can help in solving the current problem of developing and main-
taining separate application variants. This is because MDE makes use
of models to raise the level of abstraction in order to avoid addressing
the details of the platforms and speed up the software development pro-
cess by allowing the design and reuse of the code, and increasing the
software quality. In this sense, this document describes a methodology
based on models and services for the interoperability of emerging tech-
nologies that have a fundamental role in the emergence of the IoT. The
result of this research is a concrete and abstract syntax along with a
Model-to-Text transformation, to automatically generate software arti-
facts for IoT systems, thereby achieving the interoperability of mobile
technologies, DTV, controllers, REST services and service coordination.
Keywords: Model-Driven Engineering (MDE) ·Domain Specific Lan-
guage (DSL) ·Internet of Things (IoT) ·Mobile ·Digital TV (DTV)
1 Introduction
In recent years, the fourth industrial revolution is taking place and one of the
main enabling technologies of this revolution is the Internet of Things (IoT)
whose objective is to connect all kinds of devices to exchange information. IoT
can be defined as a set of interconnected things (human beings, tags, sensors,
etc.) through the Internet which have the ability to measure, communicate and
act around the world. The main idea of the IoT is to obtain information about
our environment to understand, control and interact with it [4]. However, the lack
of a common standard and clear interoperability rules for the IoT can result in
higher maintenance and development costs. The scalability issues of IoT could be
2 Darwin Alulema, Javier Criado and Luis Iribarne
expected to worsen if the current growth rate is maintained in the near future [3].
Thus, the Web of Things (WoT) is a recent approach in the IoT domain, focusing
on solving the problem of IoT interoperability by using the Web as an integration
layer. The Web, as one of the pillars of the Internet, offers a possibility of reaching
a consensus to achieve the interoperability of IoT [8]. The W3C initiative for the
specification of WoT aims to address the fragmentation of IoT through the use of
existing web standards [7]. This opens up the possibility for industries to use the
cyber workspace for collaboration from anywhere in distributed environments.
For example, remote control of robots becomes important not only in rescue
operations but also in domestic and industrial environments [10].
IoT is now one of the present most interesting research fields, and the most
active applications are transportation, smart home, robotic surgery, aviation,
defence, critical infrastructure, etc. [10]. In this regard, the homes contain more
and more smart objects and will continue to grow. Proper orchestration between
all connected objects in the home could save end users money. This technology
will allow not only to know the average temperature of our home and the con-
sumption of energy and water but also the quality of the air we breathe by
being able to automate the ventilation of the home, the prediction of water or
gas, leaks or any structural failure [4].
For example, when we get back home, we want a comfortable temperature
both in summer and winter. However, the room temperature may change when
the number of people increases or when the oven is turned on. In this context,
the proposed Smart Home scenario (Figure 1) is composed of multiple smart
objects (sensors and actuators) connected locally and with the option of being
controlled from the Internet, in which through an interface mobile, the home
owner can monitor the status of its home or even activate some of the actuators
from work. In addition, while other tasks are being carried out, the DTV (digital
TV) interface is also available so that you can control all the smart objects in
your home from multiple places from your sofa. This system also maintains
communication with the Health services and can act before the recommended
Fig. 1. Coexistence of heterogeneous systems in Smart Home.
An approach to integrate IoT systems with no-web interfaces 3
protocols such as when there is a concentration of people in a closed environment
and it can activate a fan or open the windows to maintain a healthy environment.
There are several difficulties in developing the vision of a Smart Home, and
this work addresses two of them: (i) interoperability between systems; (ii) and
development costs. With regard to interoperability, our approach proposes the
use of: (a) an Event-Driven Architecture (EDA) for the publication and sub-
scription of smart objects to a topic; (b) a Service Oriented Architecture (SOA)
for the creation of RESTful services for each of the smart objects and thus can
be accessed from the web; (c) a Bridge for interoperability between EDA and
SOA; (d) an Orchestrator for the coordination of web services; and (e) a user
interface on non-web platforms. In terms of development costs, our approach pro-
poses the use of Model-Driven Engineering (MDE) together with Model-to-Text
(M2T) transformations, to alleviate the problem of code generation for each of
the platforms in addition to speeding up development processes and validation.
The rest of the article is organized as follows. Section 2 provides a review
of relevant IoT interoperability solutions, focusing on those that employ MDE.
Section 3 presents the methodology for the design of IoT applications by means
of a metamodel and M2T transformations for code generation and it describes
the scenario used to demonstrate the operation of the proposed methodology.
Finally, Section 4 presents the conclusions and future work.
2 Related Work
There is a growing body of research on automated code generation for IoT
systems as well as on the use of MDE for the IoT environment.
Cai et al. [3] propose a metamodel that integrates CIM (Computation Inde-
pendent Model) with PIM (Platform-Independent Model) as a reference struc-
ture to encapsulate and manage commercial resources for the development of
applications for Cloud of Things (CoT). The metamodel connects business re-
quirements with executable components. Additionally, the authors provide three
development patterns: role-driven, data-driven and process-driven for service
configuration. These patterns allow the rapid development of mobile services
based on service resources. The proposal does not contemplate the use of non-
web interfaces nor does it consider the coordination of services.
The work of Sneps-Sneppe and Namiot [13] analyses the challenges for the
detection and collection of data from various sources in the development of ap-
plications for smart cities. The authors propose a Domain-Specific Language
(DSL) based on Java Server Pages. With this DSL, operations enable IoT com-
munication between process instances and sensors. This approach does not au-
tomatically generate code or have a graphical editor. Also, it does not consider
a mechanism for interaction with users.
The authors of [11] propose a specific language along with an Editor devel-
oped in JavaScript to design IoT devices. The proposal generates Java code
and OpenHAB which allows the interconnection of software components and
middlewares; hardware and software; and mapping the code of the devices to
4 Darwin Alulema, Javier Criado and Luis Iribarne
the software components. However, none service coordination mechanism is pre-
sented in this proposal.
In [14], the authors present an approach based on a UML profile for the inte-
gration of Cyber Physical Systems (CPS) and IoT. The approach automates the
component generation process and a RESTful API is implemented. The tech-
nologies adopted by the authors are: Open Mobile Alliance (OMA) LWM2M
application protocol and the Internet Protocol for Smart Objects (IPSO) Al-
liance. This work does not address the development of user interfaces or service
coordination mechanisms.
The approach presented in [15] addresses the problem of mobile application
maintenance because multiple native variants of applications must be developed
and maintained to support different mobile operating systems, devices, and vary-
ing application functional requirements. This approach considers three types of
variations in mobile applications: variation due to operating systems and their
versions, the software and hardware capabilities of mobile devices, and the func-
tionalities that the mobile application offers. However, it does not address the
development of hardware nodes or object coordination mechanisms.
Although many solutions provide high-level interfaces to simplify IoT appli-
cation development, they are often based on HTTP which is too costly for the
scarce resources of embedded devices. In contrast, SOA-based solutions are more
efficient but they suffer from inefficient access to physical resources: some of them
require direct interaction with embedded devices; others expose resources but
only through an intermediate database. Ultimately, no solution provides truly
simplified tools that enable the development of IoT applications for both non-
expert and expert users, spanning hardware, business logic and a non-web user
interface, as given in our proposal.
3 Proposed integration approach
In this section we present our approach to the integration of heterogeneous plat-
forms. Our proposed architecture is an extension of some of our previous work
[2] and consists of three layers: (a) Physical layer, it corresponds to the sensors,
actuators and controllers from which the hardware nodes are built; (b) Logical
Layer, together with the Physical Layer, they are the Back-End of the system
and allow the coordination of the information from the physical and application
layers, for which it consists of: (i) MQTT Broker, it handles publication events or
subscription from the physical layer, (ii) Bridge, it routes the messages from the
Broker to the RESTful API or the Orchestrator, (iii) RESTful API, it deploys
HTTP methods (GET, POST, PUT and DELETE) with communication to a
database so that each physical node at which it is associated can be consumed by
the orchestrator, the application layer or by remote services; (iv) Orchestrator, it
coordinates the call sequences to the REST or Bridge services for the execution
of the business logic; (c) Application layer, it corresponds to the Front-End of
the system and allows user interaction in non-web interfaces (mobile and DTV).
An approach to integrate IoT systems with no-web interfaces 5
The Figure 2 shows graphically the relationships that each of the layers of the
proposed architecture have.
Fig. 2. Proposed integration architecture.
To allow the integration of the platforms, the Thing Description of the WoT
[9] has been taken as a guide and a simplified version has been proposed that
can be handled more easily by the hardware nodes, which have fewer computing
resources; in addition to not saturate the Bandwidth if many nodes are deployed.
The structure for the exchange of information consists of: (a) Id, identifier of the
event; (b) Date, date of occurrence of the event; (c) Time, time of occurrence of
the event; (d) Location, physical location of the node; (e) Attribute, logical value
of the event; (f) Artefact, node name; and (g) Property, identifier of the data
type of the attribute value.
For the development of the metamodel (Abstract Syntax) the Eclipse Ecore
tool was used [5]. The metamodel of the Figure 3 is a capture of the new section
of our proposal in which the mobile device platform is incorporated in order
to provide a new interface to interact with IoT systems. The meta-classes are
grouped according to the layers of the proposed architecture as detailed below:
–Physical layer: This layer groups the meta-classes that allow the design of
the hardware nodes and details the characteristics of the network infrastruc-
ture on which the IoT system is deployed. The main meta-classes are: (a)
For hardware nodes, IoTNode, Sensor, Actuator, Controller and Communi-
cation; and (b) For the network infrastructure, WebServer, DataBaseServer,
AccesPoint and MessageBroker.
–Logical Layer: This layer groups the meta-classes that allow integrating and
coordinating all the nodes and services of the IoT system. The main meta-
classes are: BridgeServer, REST, IntegrationPattern and Orchestrator.
6 Darwin Alulema, Javier Criado and Luis Iribarne
Fig. 3. Proposed metamodel for the integration of heterogeneous systems.
–Application layer: This layer groups the meta-classes that allow designing
the non-web user interface that allows interaction with the IoT system. The
main meta-classes are: DTV, Interface, Mobile and Activity.
3.1 Graphic editor for the design of IoT systems
For the development of IoT systems, a previous graphical editor (Concrete Syn-
tax) has been created in Eclipse Sirius [12] based on the metamodel described in
the subsection. For the development of the Graphic Editor, the VSM (Viewpoint
Specification Model) was configured with the meta-classes and their relation-
ships. In addition, the visual components were created to allow the developer to
create applications graphically.
The graphical editor (Figure 4) has 3 main areas: (a) Tool palette (right panel)
from which developers can select the elements to be incorporated into their ap-
plications; (b) Canvas (central panel) in which developers can drag and drop
the visual components and their relationships for an IoT application; and (c)
Properties (bottom panel) to add or edit information related to the different
components of the model. As can be seen in Figure 4, the Tool Palette allows
modelling the Network Infrastructure, the hardware of the IoT nodes, the in-
tegration patterns of the services and the control interface for the Mobile and
DTV interfaces.
3.2 Model-to-Text transformation for code generation
To automate the development process of the IoT applications, Model to Text
transformation was used in the Eclipse Acceleo tool [1]. To exemplify the use-
fulness of MDE techniques, the following were used as test platforms: (a) on
Android mobile phones (b) in the case of DTV, the ISDB-T standard [6] with
NCL-Lua; (c) for the controller, Node MCU ESP 8266 compatible with Arduino;
(d) for REST services, Ballerina; (e) for the Bridge, Node-Red and (f) for the
integration of services, Ballerina. These platforms were selected for the follow-
ing reasons: (i) they are platforms that allow at least one textual programming
language; (ii) they are platforms that have Internet connectivity; and (iii) they
are platforms with an active development community.
An approach to integrate IoT systems with no-web interfaces 7
Fig. 4. Screenshot of the graphical editor (The lower section corresponds to the system
properties. The section on the right corresponds to the tool palette. The middle section
is the canvas for the system design).
The Acceleo code shown in Listing 1.1 contains the shows the general code
blocks that generate the software artifacts that will be deployed on each of the
system platforms: (a) Creation of all the RESTful APIs associated with each
of the sensors and actuators (.bal); (b) Creation of all the Bridges associated
with each of the sensors (OutputBridge) and actuators (InputBridge) (.json);
(c) Creation of the controller configuration for sensors and actuators (.ino); (d)
Creation of the integration pattern based on Sagas (.bal); (e) Creation of the
user interface for DTV (.ncl and .lua); and (f) Creation of the user interface for
Mobile (.java and .xml).
[ co mme nt en c o d i n g = UTF−8 / ]
[∗∗
∗The d o c u m e n t a t i o n o f t h e m o du l e g e n e r a t e .
∗/ ]
[ m od ul e g e n e r a t e ( ’ h t t p : / / w w w . e x a m p l e . o r g / w s i o t v m ’ ) ]
[∗∗
∗The d o c u m e n ta t i o n o f t he te m p l a t e ge n e r a t e E l e m e n t .
∗@param a Sy st e m
∗/ ]
[ te m p l a t e p u b l i c g e n e r a t e E l e m e n t ( aS ys t em : Sy s te m ) ]
[ com ment @ma in / ]
[ com ment API RESTFULL/ ]
[ f o r ( w e b s e r v i c e : W e bS e rv i c e |aS y st em . w e b s e r v i c e ) ]
[ f o r ( r e s t : REST |aS ys te m . w e b s e r v i c e . r e s t ) ]
[ f i l e ( r e s t . d e v i c e . nam e . t o S t r i n g ( ) . c on c a t ( ’ . b a l ’ ) , false ,’ U T F - 8 ’ ) ]
. . .
[ / f i l e ]
[ / f o r ]
[ / f o r ]
[ com ment BRIDGE MQTT/]
[ f o r ( b r o k e r : B r i d g e S e r v e r |aS ys te m . b r i d g e s e r v e r ) ]
[ f o r ( ou t : Ou t pu tB ri d ge |b r o k e r . b r i d g e ) ]
[ f i l e ( o ut . s e n s o r . na me . t o S t r i n g ( ) . c o nc a t ( ’ . j s o n ’ ) , false ,’ U T F -8 ’ ) ]
. . .
[ / f i l e ]
[ / f o r ]
[ f or ( input : InputBridge |b r o k e r . b r i d g e ) ]
[ f i l e ( i n p u t . a c t u a t o r . nam e . t o S t r i n g ( ) . c on c a t ( ’ . j s o n ’ ) , false ,’ U T F - 8 ’ ) ]
. . .
[ / f i l e ]
8 Darwin Alulema, Javier Criado and Luis Iribarne
[ / f o r ]
[ / f o r ]
[ com ment HARDWARE/]
[ f o r ( n od o : Io TNo de |a Sy st e m . i o t n o d e ) ]
[ f o r ( c o n t r o l l e r : C o n t r o l l e r |n od o . d e v i c e ) ]
[ f i l e ( c o n t r o l l e r . name . t o S tr i n g ( ) . c o nc a t ( ’ . i n o ’ ) , false ,’ U T F -8 ’ ) ]
. . .
[ / f i l e ]
[ / f o r ]
[ / f o r ]
[ com ment ORCHESTRATOR/ ]
[ f o r ( i n t e g r a t i o n : I n t e g r a t i o n P a t t e r n |a Sy st em . i n t e g r a t i o n p a t t e r n ) ]
[ f o r ( o r c h e s t r at o r : O r c h e s t r a t o r |i n t e g r a t i o n . o r c h e s t r a t o r ) ]
[ f i l e ( o r c h e s t r a t o r . name . t o S t r i n g ( ) . c o n ca t ( ’ . b a l ’ ) , false ,’ U T F - 8 ’ ) ]
. . .
[ / f i l e ]
[ / f o r ]
[ / f o r ]
[ com ment TV APP/ ]
[ f o r ( tv : DTV |aSy st em . d tv ) ]
[ f i l e ( t v . n ame . c o n c a t ( ’ . n c l ’ ) , false ) ]
. . .
[ / f i l e ]
[ f i l e ( ’ t c p . l u a ’ ,false ) ]
. . .
[ / f i l e ]
[ f i l e ( ’ ConnectorBase . ncl’ ,false ) ]
. . .
[ / f i l e ]
[ com ment MOBILE APP/ ]
[ f o r ( m o v i l : M o b i l e |a S ys t em . m o b i l e ) ]
[ f o r ( a c t i v i d a d : A c t i v i t y |m o vi l . ac t i v i t y ) ]
[ f i l e ( ac t i v i d a d .n ame . c o n ca t ( ’ A c t i v i t y . j a v a ’ ) , false ,’ U T F -8 ’ ) ]
. . .
[ / f i l e ]
[ f i l e ( ’ activity_ ’. c o n c a t ( a ct i vi d ad . name . t o Lo w e r ( ) . c o n c a t ( ’ . x m l ’ ) ) , false ,’ U T F -8
,→’) ]
. . .
[ / f i l e ]
[ / f o r ]
[ f i l e ( ’ A n d r o i d M a n i f e s t . x m l ’ ,false ,’ U T F - 8 ’ ) ]
. . .
[ / f i l e ]
[ / f o r ]
[/ template ]
Listing 1.1. M2T transformation for generating the software artifacts.
3.3 A case study scenario
In order to demonstrate the functionality of our proposal, the Smart Home do-
main was chosen for its high degree of diffusion. In this case, a simplified imple-
mentation of the scenario proposed in Figure 1 was made, which was modelled
with the graphic editor developed as shown in Figure 4. The scenario consists
of (Figure 5): (a) a temperature sensor (LM35); (b) an actuator (Relay) that
controls the switching on of a fan; (c) an interface for Android mobiles with
which the user can check the status of the sensor and activate the actuator and;
(d) an interface for DTV that is transmitted via Broadcast by the TV provider
and is controlled with the interactivity buttons. In addition, a control was estab-
lished to automate the ambient temperature by means of an ON/OFF control
algorithm implemented in the Orchestrator that coordinates the REST services
and the sensor and actuator Bridges. The users of both interfaces can interact
with the temperature sensor to observe its sensed value or with the actuator
that controls the fan relay to switch it on or off.
An approach to integrate IoT systems with no-web interfaces 9
Fig. 5. Coexistence of heterogeneous systems in Smart Home.
4 Conclusions and Future Work
IoT is transforming the way modern systems will develop and operate. However,
the adoption of IoT imposes a paradigm shift for systems development and com-
plicates the design process and for this reason, effective approaches are required
to handle the complexity introduced by this transition. In this article, we address
the challenges that IoT application developers face in achieving interoperable
software solutions against highly heterogeneous platforms, protocols, and data.
To do this, we have proposed and implemented a solution based on models and
services that allows the integration of software and hardware platforms. Thus,
avoiding that developers have to delve into the programming languages of all the
technologies that intervene in the system. The tools created are: (a) a graphical
editor for the design of IoT applications and; (b) an M2T transformation for the
generation of code for each platforms. To achieve this goal, we have expanded
the functionalities of several of our tools developed in previous work [2] to facil-
itate the creation of mobile interfaces that are integrated into IoT systems. As
a result, we obtained a semi-automatic process for the generation of Ballerina
code for RESTful and orchestrator services, Arduino code for the deployment of
IoT nodes, NCL-Lua code for the DTV interface and Android code for Smart
Phones. The proposal includes a manual step before executing the application
that involves the developer by having the multimedia components available for
the DTV application (Images and videos) and copying the Android files (.java
and .xml) in Android Studio for compilation. Finally, the electrical connections
of the components (sensors and actuators) must be made in the controller.
With regard to our future work, we consider several relevant issues: (a) Devel-
oping an indexing and discovery service that will allow the use of multiple remote
networks to implement more complex and intelligent applications; (b) Extending
10 Darwin Alulema, Javier Criado and Luis Iribarne
our proposal to go beyond REST and web services to include AMQ and Kafka;
and (c) Incorporate all the W3C WoT Thing Description recommendations.
Acknowledgments
This work has been funded by the EU ERDF and the Spanish Ministry MINECO
under the Project TIN2017-83964-R.
References
1. Acceleo - The Eclipse Foundation, https://www.eclipse.org/acceleo/. Last ac-
cessed August 26, 2020.
2. Alulema, D., Criado, J., Iribarne, L., Fren´amdez-Garc´ıa, A., Ayala, R.: A model-
driven engineering approach for the service integration of IoT systems. Cluster
Comput (2020).
3. Cai, H., Yizhi, G., Athanasios, V., Boyi, X., Jun, Z.: Model-Driven Development
Patterns for Mobile Services in Cloud of Things. IEEE Transactions on Cloud
Computing, 6(3): pp. 771–84. (2018).
4. D´ıaz, M., Mart´ın, C., Rubio, B.: State-of-the-Art, Challenges, and Open Issues in
the Integration of Internet of Things and Cloud Computing. Journal of Network
and Computer Applications, 67: pp. 99-–117. (2016).
5. Eclipse Modeling Project: The Eclipse Foundation. https://www.eclipse.org/
modeling/emf/. Last accessed August 26, 2020.
6. El-Hajjar, M., Lajos H.: A Survey of Digital Television Broadcast Transmission
Techniques. IEEE Com. Surveys and Tutorials, 15(4): 1924—1949. (2013).
7. Iglesias-Urkia, M., G´omez, A., Casado-Mansilla, D., Urbieta, A.: Automatic Gen-
eration of Web of Things Servients Using Thing Descriptions. Personal and Ubiq-
uitous Computing, pp. 1–17. (2020).
8. Kovatsch, M., Matsukura, R., Lagally, M., Kawaguchi, T., Toumura, K., Kajimoto,
K.: Web of Things (WoT) Architecture, W3C Recommendation (2020)
9. Kaebisch, S., Kamiya, T., McCool, M., Charpenay, V., Kovatsch, M.: Web of
Things (WoT) Thing Description, W3C Recommendation (2020)
10. Lihui, w., T¨orngren, M., Onori, M.: Current Status and Advancement of Cyber-
Physical Systems in Manufacturing. Journal of Manufacturing Systems, 37: pp.
517–27. (2015).
11. Salihbegovic, A., Eterovic, T., Kaljic, E., Ribic, S.: Design of a Domain Specific
Language and IDE for Internet of Things Applications. International Convention
on Information and Communication Technology, Electronics and Microelectronics,
pp. 996–1001. (2015).
12. Sirius - The easiest way to get your own Modeling Tool. https://www.eclipse.
org/sirius/. Last accessed August 26, 2020.
13. Sneps-Sneppe, M., and Dmitry, N.: On Web-Based Domain-Specific Language for
Internet of Things. Int. Cong. Ultra Modern Telecommunications and Control Sys-
tems and Workshops, pp. 287–292. (2015).
14. Thramboulidis, K., Vachtsevanou, D., Kontou, I.: CPuS-IoT: A cyber-physical mi-
croservice and IoT-based framework for manufacturing assembly systems. Annual
Reviews in Control, 47:237–248. (2019).
15. Usman, M., Zohaib, M., Uzair, M.: A Product-Line Model-Driven Engineering
Approach for Generating Feature-Based Mobile Applications. Journal of Systems
and Software, 123:1—32. (2017).
