AutoIoT: a Framework based on User-driven MDE for

Generating IoT Applications

Thiago Nepomuceno, Tiago Carneiro, Paulo Henrique Maia, Muhammad
Adnan, Thalyson Nepomuceno, Alexander Martin

To cite this version:

Thiago Nepomuceno, Tiago Carneiro, Paulo Henrique Maia, Muhammad Adnan, Thalyson Nepomu-
ceno, et al.. AutoIoT: a Framework based on User-driven MDE for Generating IoT Applications. SAC
’20: The 35th ACM/SIGAPP Symposium on Applied Computing, Mar 2020, Brno, Czech Republic.
pp.719-728, �10.1145/3341105.3373873�. �hal-02554798�

HAL Id: hal-02554798

https://hal.science/hal-02554798v1
Submitted on 26 Apr 2020

HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est

archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents
entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non,
lished or not. The documents may come from émanant des établissements d’enseignement et de
teaching and research institutions in France or recherche français ou étrangers, des laboratoires
abroad, or from public or private research centers. publics ou privés.
 AutoIoT: a Framework based on User-driven MDE for
Generating IoT Applications
Thiago Nepomuceno Tiago Carneiro Paulo Henrique Maia
Fraunhofer Center for Applied INRIA Lille - Nord Europe State University of Ceará
Research on Supply Chain Services France Brazil
Germany tiago.carneiro-pessoa@inria.fr pauloh.maia@uece.br
thiago.nepomuceno@scs.fhg.de

Muhammad Adnan Thalyson Nepomuceno Alexander Martin

Fraunhofer Center for Applied Federal Institute of Ceará Friedrich-Alexander-Universität
Research on Supply Chain Services Brazil Erlangen-Nürnberg
Germany thalyson.silva@ifce.edu.br Germany
adnanmd@scs.fhg.de alexander.martin@fau.de

ABSTRACT 1 INTRODUCTION
Developing an Internet of Things (IoT) system requires knowledge Over the past years, the interest in the Internet of Things (IoT)
in many different technologies like embedded programming, web technologies has grown both in industry and academia due to its
technologies, and data science. Model-Driven Engineering (MDE) wide range of applications, including smart homes, smart healthcare,
techniques have been used as a concrete alternative to boost IoT smart grids, smart cities, and smart factories [16]. IoT projects
application development. However, the current MDE-to-IoT solu- usually share some essential features, such as sending and receiving
tions require expertise from the end-users in MDE concepts and data to/from devices, analyzing and visualizing data, and providing
sometimes even in specific tools, such as the Eclipse Modelling a user management system [2].
Framework, which may hinder their adoption in a broader context. A complete IoT system is composed of four different layers [10]:
To tackle this problem, this work proposes AutoIoT, a framework device layer, gateway, a server-side application, and data analysis.
for creating IoT applications based on a user-driven MDE approach. The usual data flow in an IoT system starts when a device sends it’s
The proposed framework allows users to model their IoT systems sensor data using low-level communication protocols (e.g., sock-
using a simple JSON file and, through internal model-to-model and ets) to a gateway. Then, the gateway transforms the binary data
model-to-text transformations, generates a ready-to-use IoT server- received into a more human readable format (e.g., JSON) and sends
side application. The proposed approach was evaluated through it to the server-side application, which is responsible for collecting
an experiment, in which 54 developers used AutoIoT to create a and storing the data in a database. Additionally, the server applica-
server-side application for a real-world IoT scenario and answered tion can also provide features like a virtual representation of the
a post-study questionnaire. The experiment reports the efficacy of devices, a Graphical User Interface (GUI) to visualize the data, a
AutoIoT and user satisfaction of more than 80% through 6 out of 7 user management system, and ways to share collected data with
evaluated criteria. third-party systems (e.g., via an API or a message queue). Finally,
the data analysis subsystem accesses the data stored and produces
CCS CONCEPTS useful insights to help the users of the IoT system to understand
their data and to take decisions accordingly.
• Computer systems organization → Sensors and actuators; •
In some cases, an IoT system does not need all four layers. Ex-
Software and its engineering → Software prototyping;
amples include (i) when devices are powerful enough to support
internet protocols a gateway is not needed; (ii) in prototypes or
KEYWORDS simpler systems the data analysis layer is not required; and (iii) in
Code Generation, User-driven, MDE, IoT application some cases, even the server-side application is not needed, since
devices can communicate directly between them autonomously.
ACM Reference Format: Developing a complete IoT system requires expertise in many
Thiago Nepomuceno, Tiago Carneiro, Paulo Henrique Maia, Muhammad different technologies like embedded programming, web technolo-
Adnan, Thalyson Nepomuceno, and Alexander Martin. 2020. AutoIoT: a gies, and data science. Given the complexity of the task, some tools
Framework based on User-driven MDE for Generating IoT Applications. In and platforms have been created to support developers. The better
Proceedings of . ACM, New York, NY, USA, 10 pages. well-known solutions are the platforms created by big companies
like Google1 , Amazon2 , and Microsoft3 . However, costs associated

,, 1 https://cloud.google.com/iot-core/

© 2 https://aws.amazon.com/iot/
3 https://azure.microsoft.com/en-us/services/iot-hub/
,, T. Nepomuceno et al.

with the provided services, as well as the vendor lock-in, may hin- The remainder of this document is organized as follows: Section 2
der the adoption of such solutions for some smaller or more specific presents the most related work. Section 3 introduces the AutoIoT
IoT projects. Framework, describing the user-driven process and implementation
Alternatively, Model-Driven Engineering (MDE) has been gain- details. Next, Section 4 details the evaluation of AutoIoT in an
ing attention from both academia and industry in recent years as a industrial use case and its findings and Section 5 briefly discuss how
concrete solution to ease the development of IoT systems through to use AutoIoT in more complex use cases. Finally, the conclusions
automatic code generation to different hardware devices [12] and are outlined in Section 6.
server-side application platforms [3, 6, 11, 13]. Nonetheless, most
of those approaches to build IoT applications present at least one of 2 RELATED WORK
the following drawbacks: (i) they are based on a strong modeling
Previous work have already used MDE technologies to ease the
phase with complex meta-models that are designed to cover a wide
development of IoT server-side applications. We describe some of
range of different scenarios, hence requiring time and modeling
these approaches as follows.
expertise; (ii) they generate only boilerplate code of the application,
Brambilla, Umuhoza, and Acerbis [3] propose a model-driven
demanding developers to write most of the application logic by
approach to design IoT Graphical User Interfaces (GUI). The work
hand; and (iii) they require expertise in tools that are standard in
defines both specific components and design patterns using a visual
the MDE community, but not well known in the industry, like the
modeling language for IoT applications and discusses the impor-
Eclipse Modeling Framework (EMF) suite.
tance of having good GUI to improve the acceptance of the IoT
According to a definition given by Abrahão et. al. [1], those
system and to model the user interactions with the GUI. The paper
work are considered as technology-driven approaches, in which
discusses the back-end software and how it stores and retrieves in-
the primary goal is to improve existing MDE techniques, usually
formation from a database, but it is not clear whether the proposed
making them more general in order to cover a broader range of
approach also generates those components or not. The approach
use cases, and not to improve the usability or to ease the adoption
requires users to have expertise in MDE and Interaction Flow Mod-
by a general target audience. Most of those works require their
eling Language (IFML).
audience to became MDE experts, learning theory and techniques
ThingML (Internet of Things Modeling Language) [11] is an
commonly used in the MDE field. On the other hand, in a user-
MDE approach that aims to cover a considerable amount of IoT
driven approach [1], the user knowledge and necessities guide the
use cases. It is already in a more advanced stage of development
development of the new MDE approach. This way, such approach
when compared with other MDE-to-IoT solutions and is especially
should provide tools that help to bridge the gap between what its
attractive to teams with MDE experts. According to the authors, the
users already know and what is expected from them to know to
main contribution of the project is a code generation framework
use the new tools/methods, making the adoption easier.
and an associated methodology to give practitioners full control
Previous work have already followed the premise behind user-
of the code by letting them easily customize compilers for their
driven MDE approaches. GenApp [15], for example, is a tool for
needs. To accomplish this, expertise in MDE and Domain Specific
building entirely functioning science gateways and standalone GUI
Language (DSL) is required.
applications from collections of definition files and libraries of code
Pramudianto et al. [13, 14] proposes IoTLink, which aims to
fragments, and Json-GUI [5] is an AngularJS front-end module that
hide many of the required expertise to develop an IoT server-side
dynamically allows data scientists and web form users to generate
application behind a Flow-Based Programming interface. It targets
form-based web interfaces. However, to the best of our knowledge,
inexperienced developers entering the IoT development, allowing
we have not found any work that applies the concepts of user-driven
them to create a ready-to-use application in minutes. While IoTLink
MDE for the design and development of IoT applications. This kind
makes an important step and is aware of the limited expertise of
of approach would benefit not only experienced IoT developers to
developers, it still requires developers to learn new skills to get
boost the application creation by reducing development time, but
started with the tool, like Flow-Based Programming and the Eclipse
also introducing new ways to build IoT systems to developers and
Modeling Framework. Additionally, the resulting system lacks some
practitioners by decreasing the technology learning curve.
essential features usually requested in an IoT application, like a
In this realm, this work proposes a framework, called AutoIoT,
GUI.
for generating IoT server-side applications that relies on a user-
All aforementioned work require some level of MDE expertise
driven MDE approach. This way, AutoIoT allows users to model
to create IoT applications, which may hinder their adoption. In
their IoT system using a simple JSON file and through internal
contrast, AutoIoT has been designed based on a user-driven MDE
model-to-model transformation and code generation techniques, to
approach and uses only technologies that its target audience al-
create automatically the IoT server-side application. Furthermore,
ready knows, like JSON representation and a general programming
IoT developers that have some expertise in MDE can extend Au-
language4 . This way, IoT and Web developers with no or little
toIoT by creating specific components, called Specialized Builders,
knowledge in MDE techniques can design and generate ready-to-
that are responsible for generating the source code of specific IoT
use IoT server-side applications, thus reducing development effort
applications. The proposed framework is evaluated with users with
and the technology learning curve.
different backgrounds who modeled and developed a real IoT server-
side application. The results indicate that the users were able to
create the application correctly and in a short time with no or little 4 Currently
the AutoIoT framework is available only in Python, but ports to other
knowledge in MDE. programming languages are planned
AutoIoT: a Framework based on User-driven MDE for Generating IoT Applications ,,

and visualization of data, both historical (from the database) and

real-time data. Finally, the system should (v) provide an API that
allows project partners (third-party systems) to access the stored
data.

3.2 The User-driven MDE Process

The MDE process proposed by this work, as shown in Figure 2, is
composed of three main phases: modeling the IoT Scenario, gener-
ating server-side application code, and extending the source code.
The first two phases are mandatory, while the last one is optional.
Each phase is detailed as follow.
Figure 1: The hardware device and its sensors are attached
to a container. The device includes a temperature, position 3.2.1 Modeling the IoT Scenario. The process starts with the de-
(GPS) and filling status sensors. This picture shows a proto- veloper modeling the IoT scenario, which is defined according to
type of the smart container where all sensors are visible, not the meta-model depicted by Figure 3. The meta-model defines an
the final product. IoT project and its components, i.e., devices, sensors and the data
sent by them, besides the system communication with devices or
third-party applications through communication protocols (MQTT,
Finally, AutoIoT does not intend to replace more complete MDE- HTTP, and WebSockets) and the connection to a database. Addi-
to-IoT approaches (e.g., ThingML), since these approaches are de- tionally, it can also describe the data visualization using dashboards
signed to cover a broader range of IoT use cases. Instead, it proposes and components, such as tables, charts, and maps.
a solution that allows developers to get some of the benefits of MDE The meta-model has been created based on our experience on
without the need of learning new technologies. developing several IoT projects for both research and industry
in Fraunhofer SCS. It can not be considered complete and does
3 AUTOIOT FRAMEWORK not intend to cover all IoT use cases. Its main goal is to provide
This section presents the proposed framework for generating IoT all information needed by the current Specialized Builders, and
server-side applications. Initially, a simple motivating example that when new Builders are created, the meta-model will be updated
will be used throughout this section is presented and, subsequently, accordingly.
the user-driven MDE process is described. After that, one type of a Figure 3 depicts components represented by either dotted or
Specialized Builder component is detailed. Finally, implementation continuous lines. A valid model that conforms to the proposed
issues about the framework are presented. meta-model only needs to define the continuous-line components.
This work focuses on how AutoIoT can be used to create a proto- The dotted-line ones are optional and will be generated by using a
type for the motivating example, but all the concepts presented can model-to-model transformation (M2M). This way, the code attribute
be expanded to cover a more complex IoT use case, as discussed in in Topic, Endpoint, WebSockets and Dashboard does not need to be
Section 5. defined by the developer in the application model. Only a descrip-
tion of the system is required, removing the need for defining any
3.1 Motivating example business logic in the modeling phase.
The use case presented in this section consists of smart containers To model the IoT scenario, users can write the JSON file manually
that send information about location, temperature, and filling status or use a Web GUI that will generate such a file. Independently of
(whether the container is empty or not). In this scenario, the IoT the chosen method, the final result of the modeling phase is always
device is a hardware module attached to each container, as shown in a JSON file containing the model representing the system, and that
Figure 1, that sends sensor data to a base station using a proprietary is in accordance with the meta-model presented in Figure 3.
communication protocol called MIOTY, it is similar to LoRa protocol Considering the example of the smart container, a model used
and has a range of 15 kilometers. Then, the base station, which is as input to AutoIoT can be seen in Listing 1. In this example, the
connected to the Internet and works as a gateway, transmits data developer only gives information about the continuous-line com-
to the server-side application through the MQTT protocol. In turn, ponents: the project, database, MQTT broker configuration, and
the server-side application is also in the Internet, hosted on a cloud the device and its sensor. The device’s fields in line 19 represents
server. The data sent by the base station is codified in JSON format attributes of the device itself and are not supposed to change very
and contains the location of the box (GPS), temperature, and filling often. The same happens for the sensor’s fields in line 26. However,
status. in addition to fields, sensors can have data_fields that represents
The server software in this scenario needs to (i) create a virtual the data that is regularly sent by this kind of sensor to the server
representation of the container. Additionally, it (ii) receives and application.
processes messages from the base station (using MQTT protocol), The JSON file is the only artifact created by the user during the
and links received data to the correspondent virtual device. Fur- modeling phase and the only expertise required is knowing the
thermore, it also needs (iii) to store sensor data in a database and JSON syntax (if the file is written manually, without the GUI). Devel-
(iv) to provide a GUI for easing the user interaction with the system opers extensively use JSON to exchange data between systems and
,, T. Nepomuceno et al.

Generate the application

code using a Specialized
Builder

Model the M2M

IoT Scenario Transformation

Developer

M2T Need to extend IoT Server-side

No
Transformation the generated system? Application

Yes

Extend the source

code of the
generated system

Figure 2: The developer starts the process by creating the model that represents the IoT scenario. It can be done using a GUI,
programming library or a simple JSON file. The defined model is the input for a Specialized Builder that, through M2M and
M2T transformation, generates the IoT server-side application source code. Optionally, the developer can also extend the
generated application to fulfill further requirements.

Project
project + name : EString
project
+ description : EString
+ app_port : EInteger

project project

communication_protocols database dashboards

* devices
* *
Communication Database Device Dashboard
Protocol + hostname : EString + name : EString + name : EString
+ port : EInteger + description : EString + route : EString
+ database_name : EString device device + code : EString
+ username : EString + generated_from_device : EString
+ password : EString dashboard

MQTT WebSocket * DeviceField components

*
HTTP API fields
+ hostname : EString + name : EString Component
+ port : EInteger + namespace : EString + name : EString
http_api
+ username : EString + on_connect_code : EInteger + type : EString
Field
+ password : EString + on_disconnect_code : EString + width : EInteger
+ name : EString
mqtt + background_thread_code : EString + heigth : EInteger
+ type : EEnum
+ visual_code : EString

endpoints + system_code : EString

topics
* component
* Endpoint
* sensors sensor_fields
Topic + path : EString
parameters
Sensor SensorField
+ topic : EString + type : EEnum sensor
* *
+ name : EString Parameter
+ code : EString + code : EString
sensor + name : EString
sensor_data_fields
SensorDataField + value : EEnum
*

Figure 3: The meta-model that defines an IoT project and its components. Components represented by continuous line are
obligatory and need to be present in the model created based on this meta-model. Components represented by dotted line are
optional and will be generated using a model-to-model transformation (M2M) (explained in Section 3.2).

most of the General Programming Languages have native support 3.2.2 Generating server-side application code. After the modeling
to JSON. phase is finished, the created model is used as input to a Special-
After the modeling is completed, AutoIoT loads the content of ized Builder that starts an M2M transformation. Then, the extended
the model file using a function. The first step is to validate and model goes to an M2T transformation phase that generates the
transform the JSON file into Python objects using the Pydantic5 source code of an IoT server-side application. The type of applica-
library. After that, the framework finally delivers these objects to tion generated depends on the Builder used. This work implements
the appropriated Builder that will generate the application code. the Prototype Builder (PB), a Specialized Builder that produces an
IoT system to manage IoT devices. The PB, the M2M, and the M2T
5 https://github.com/samuelcolvin/pydantic transformations are detailed in Section 3.3.
 AutoIoT: a Framework based on User-driven MDE for Generating IoT Applications ,,

1 { from autoiot import AutoIoT 1

2 "project": { from autoiot.builders import PrototypeBuilder 2
3 "name": "Container Management Project", 3
4 "description": "The Container Management Project.", autoiot = AutoIoT() 4
5 "app_port": 5000 autoiot.load_project('project.json') 5
6 }, autoiot.build(PrototypeBuilder, 'output/project', {'docker': False}) 6
7 "database": {
8 "type": "sqlite",
9 "hostname": "localhost" Listing 2: Using AutoIoT to load a model file and generate an
10 }, IoT server-side application
11 "mqtt": {
12 "hostname": "iot.eclipse.org",
13 "port": 1883
},
14
15 "devices": [
The PB generates a Flask application7 written in Python, HTML,
16 { CSS, and Javascript. The generated server-side application commu-
17 "name": "Container", nicates with IoT devices and third-party system through MQTT,
18 "description": "An IoT device that sends temperature, position
,→ and filing status.",
Rest API, and WebSockets. Moreover, the generated application
19 "fields": { manages IoT devices (creates, edits and deletes them), stores and
20 "name": "String", visualizes sensor data sent by them. Additionally, it also provides a
21 "barcode": "String"
22 }, user management feature that controls access to the stored data.
23 "sensors": [ Figure 4 outlines more Specialized Builders that are planned
24 { for future work. Each Specialized Builder should follow the meta-
25 "name": "MainSensor",
26 "fields": { model proposed by this work. However, the set of components that
27 "send_interval": "String" are mandatory (continuous line) or optional (dotted-line) can vary
28 },
29 "data_fields": {
from one Builder to another. Each Builder has to implement an
30 "temperature": "Float", M2M transformation that extends the input model adding custom
31 "filing_status": "Integer", components (dotted-line components) and an M2T transformation
32 "position": "Point"
33 } that generates the final application source code.
34 } To create the PB, the abstract class Builder is extended as shown
35 ] in Figure 4. The Builder class has a set of abstract methods that
36 }
37 ] need to be implemented by the Prototype Builder class. The most
38 } important ones are extend, which performs the M2M transforma-
tion, and generate that is responsible for the M2T transformation
Listing 1: Example of a model represented in JSON format
7 http://flask.pocoo.org/

Listing 2 presents a small example of the AutoIoT Framework

being used to load a project.json file and shows how to generate the «abstract class»
IoT server-side application using a Specialized Builder. Builder

The build method is responsible for applying the M2M and M2T
transformation to the model created by the load_project method.
In turn, the parameters of the build method are the chosen Spe-
Specialized Builders
cialized Builder, the output folder and a dictionary with additional
configuration. In this example the Prototype Builder is used, and Prototype
Builder
Device Twin
Builder
Flutter App
Builder
the Docker6 deployment is set to false.
3.2.3 Extending the generated code. After the source code gener-
ation, the developer has the choice to extend it to fulfill further Prototype application to
A microservice that Flutter App source code
requirements of the project or use the generated application as is. manage different IoT
provides a REST API and
create an abstraction of
that can be compiled to
devices Android or iOS
The generated application is already ready-to-use, and it can be IoT devices

executed locally or deployed on a cloud server.

3.3 Prototype Builder Figure 4: A developer can create Specialized Builders extend-
AutoIoT provides an implemented Specialized Builder called Proto- ing the abstract class Builder provided by AutoIoT. Each
type Builder (PB). It has been chosen as the first Specialized Builder Builder receives the same model but produces different ap-
due to its wide use as a server-side application in several IoT plications. The generated application can follows a mono-
projects, since every project usually needs a prototype and most lith architecture like the application generated by the Proto-
IoT scenarios need to communicate with and manage IoT devices. type Builder, a microservice architecture like one generated
6 Docker
by the Device Twin Builder or even create a complete mobile
is a tool designed to make easier to deploy, run and maintain applications by
using containers technology. application if the Flutter App Builder is used.
,, T. Nepomuceno et al.

(Section 3.3.1 and Section 3.3.2). Following the transformations pages. Since developers are already familiar with its syntax, they
executed by the PB are detailed. can easily change the templates if there is a need for it.
To help developers implement both transformations (M2M and
3.3.1 M2M Transformation. When the model defined by the user M2T), the Builder class provides a function that goes through the
is loaded by AutoIoT (line 5 of Listing 2) it is validated, processed whole model and triggers functions depending on the type of the
and stored in memory as a graph, whose nodes are components component found during the search as already described in Sec-
of the model. The M2M transformation consists of visiting each tion 3.3. After the implementation of the callback functions, which
node of the graph and checking its type. Examples of types include are triggered when the search find each type of component, the
Project, MQTT, Database, Device and Sensor. For each type of com- Specialized Builder became very simple as shown in Listing 3.
ponent, the transformation creates specific dotted-line components
and attaches them to the input model. For example, whenever the
transformation finds a Device component in the original model, it 1 from .callback_functions import found_device, found_project,
creates a Topic, HTTP API, WebSocket and Dashboard components ,→ found_database
and includes them in the original model. 2
3 class MySpecializedBuilder(Builder):
3.3.2 M2T Transformation. Similar to the process described in the 4
5 def __init__(self, project, output_path, config):
M2M transformation (Section 3.3.1), in the M2T transformation the 6 self.project = project
PB also visits each node of the graph and checks its type. For each 7 self.output_path = output_path
8 self.config = config
different type, it triggers a different function that generates source 9
code for the application using the templating technique. The default 10 def extend(self):
templating engine used by AutoIoT is Jinja8 , commonly used inside 11 self.register_callback(Project, found_project)
12
the Flask Framework to render HTML content. 13 self.search()
Each triggered function receives as input a component defined 14
def generate(self):
in the model and generates part of the IoT application source code. 15
16 self.register_callback(Device, found_device)
For example, whenever the search finds a Device type component, 17 self.register_callback(Database, found_database)
the found_device function is triggered. It receives the Device object 18
19 self.search()
as input and generates a Python class that represents this type of
Device. Furthermore, the found_device function also generates a
controller class to feed the GUI with information from the database Listing 3: A simplified example of a Specialized Builder class.
concerning this type of device. Additionally, it also generates HTML This is not a working source code, some parts like libraries
files that list the devices stored in the database and performs the importing and inheritance specific details were removed to
CRUD operations (Create, Read, Update and Delete). However, in increase the overall readability.
case the graph search finds a Dashboard instead of a Device, it trig-
gers a different function that generates HTML, CSS, and Javascript
files that compounds the GUI. Other Specialized Builders can be created by developers and in-
At the end of the M2T transformation process, the PB generates corporated to AutoIoT (as shown in Figure 4). The only restriction
the source code of a Flask project. This project is written in Python, is that it receives as input a JSON object containing a model that
HTML, CSS, and Javascript, communicates with IoT devices, and follows the proposed meta-model as shown in Listing 2. There are
stores its sensor data in a database. The Flask project supports differ- no restrictions about the type of system the Specialized Builder
ent communication protocols (e.g., HTTP, Web Sockets and MQTT) can generate (Web, Mobile or Desktop) or the underlying program-
that allows third-party systems to communicate using various web ming language used to implement it. Even that anyone can create
technologies. Furthermore, it provides a GUI that can be used to a Builder and incorporate to AutoIoT, in a normal workflow devel-
manage the IoT devices, and visualizes sensor data using tables, opers do not need to create any Specialized Builders since most of
charts, and maps updated in real time. Finally, it also provides a user the Builders are provided by the AutoIoT Framework itself or its
management system to allows different levels of access to the stored community, similar to how it happens when choosing a third-party
data. Figure 5 depicts a dashboard page of the system generated for programming library.
the smart container motivating example.
4 EVALUATION
3.4 Implementation Details To evaluate the AutoIoT framework an experiment has been con-
AutoIoT Framework is implemented using Python 3 and uses the ducted. It consists of using AutoIoT to generate the server-side
Pydantic library to provide model (JSON file) validation and pro- application of an IoT use case, extracted from one of our industrial
cessing. projects. After trying AutoIoT, the developers answered a post-
The Jinja is the default template engine used for the M2T transfor- study questionnaire to evaluate their experience. This helps us to
mation (but other options can be used). It is the standard template understand what technologies should be used when developing
engine used by the Flask framework, which is used to render HTML tools for this target audience: IoT and Web developers.
In the rest of this section the use case, the experiment, and the
8 http://jinja.pocoo.org/ results are detailed.
AutoIoT: a Framework based on User-driven MDE for Generating IoT Applications ,,

Figure 5: A dashboard page of the prototype application generated by the Prototype Builder for the motivating scenario. It
allows visualisation of the data sent by a container, including basic information about the container and its sensor data (tem-
perature, position and filing status).

4.1 Experiment the same scenario introduced in Section 3.1. This very simple sce-
To evaluate the proposed framework an experiment was conducted. nario was chosen to make the evaluation process simpler, since
First, 5 developers from both academy and industry were invited to some of the participants are Web developers with no expertise in
use AutoIoT to develop the application for the use case described IoT, a simpler use case allows them to understand and evaluate
in Section 3.1 and answer the post-study questionnaire (available the framework better. In Section 5 is discussed briefly how to use
on Google Forms9 ). This initial phase was used to improve both AutoIoT in more complex IoT use cases.
the experiment and the questionnaire itself. The tutorial also describe the steps required to accomplish the
In the second phase of the experiment, developers from different task. The task consists of (i) using AutoIoT to generate the applica-
companies and research labs around the world were invited to try tion source code for the given scenario, (ii) running the generated
AutoIoT. The only requirement needed was to have previous experi- software and (iii) simulate the smart containers through the pro-
ence with IoT or Web development. In total, 54 developers finished vided Simulator software.
the experiment and completed the questionnaire. The evaluation After completing the tutorial, the participants were asked to
was performed by 17 − 56 years old participants (Mdn = 28.81, answer a post-study questionnaire. The questions are presented as
Std = 7.56), with qualification ranging from Doctorate to no tech- statements (S1-7) and are divided into two groups. The first group
nical qualification at all. The two most common qualification levels evaluates AutoIoT itself, and the participants should choose the
have a Bachelor and Master degree, corresponding to 62% of the answer from a five-point Likert scale ranging from agree to disagree.
total of participants (17 participants has each qualification). Most of
the participants declared to have between 5 to 8 years of experience • S1 - The system generated by AutoIoT cover the require-
in programming (38.89% of the participants). ments of the scenario.
The experiment consisted of downloading a zip file containing • S2 - After reading the project description file I could easily
AutoIoT, a device Simulator software and a tutorial that describes change the configuration to cover a scenario with different
IoT devices.
• S3 - I would spend more than 40 working hours to manually
9 https://forms.gle/m2BBKmWJfNxiiexA6 codify the same system generated by AutoIoT.
,, T. Nepomuceno et al.

• S4 - The code generated by AutoIoT is well organized and

easy to understand.
• S5 - If I had to change the generated code and change the
way that the sensor data is handled, I would know which file
I should change. (Example: Instead of just store the received
data in the database, inspect it and check if the "filling_status"
is equal to zero, if so send an email/message to administrators
informing that the container is empty).
• S6 - Use AutoIoT to generate the server application was easy.
• S7 - I could use AutoIoT to generate the server-side applica-
tion in some of my IoT projects in the future.
The questionnaire was designed to evaluate whether the code
generated by AutoIoT works and cover the requirements of the
proposed scenario (S1). Additionally, it was evaluated whether
the developers could use AutoIoT to cover different IoT scenarios, Figure 6: The percentage of developers that declared to have
whether the generated source code was easy to understand, and experience 4 or 5 (in a 1-5 scale) in a given technology.
whether developers were able to extend the code to fulfill further
project requirements (S2, S4, and S5, respectively). One of the main
benefits of using an MDE approach with code generation is to
save development time, this aspect was also evaluated (S3). Finally,
developers were asked if their experience using AutoIoT was easy
and if they could use the framework to develop future IoT projects
(S6 and S7, respectively).

The main objective of this work is to provide a tool that uses

technologies that developers already know, removing the need for
Figure 7: Questionnaire results from the participants with
having a long learning phase and easing its adoption. Additionally
no expertise in MDE.
to the evaluation of AutoIoT itself, it is important to know the
expertise of the developers regarding different technologies. There-
fore, the second group of questions asked how much experience
the participants had regarding the following technologies.
• General Programming Language (e.g. Python, Java, C++, etc.)
• Internet of Things Development (e.g. MQTT Protocol, IoT
projects, etc.)
• Domain Specific Languages (e.g. WebRatio, OCL, ThingML,
etc.)
• Flow-Based Programming (e.g. Node-RED)
• Model Driven Engineering (e.g. models, system modeling, Figure 8: Questionnaire results from the participants with
model transformations, etc.) expertise in MDE.

After gathering feedback from the participants, the evaluation

of the results was conducted.

4.2 Results
Since the group of developers that participated in the experiment
consists of professional Web developers and IoT researchers, it was
expected that most of them show expertise in General Programming
Languages and Internet of Things technologies as depicted in Figure 6.
Few developers reported expertise in Domain Specific Languages Figure 9: Questionnaire results from the participants with
and Model-Driven Engineering. This finding supports our choice of expertise in IoT.
not including any of these technologies, at least not in a way visible
to developers. Results also show that few developers have expertise To better understand the groups with different expertise, the
in Flow-Based programming, a technology commonly employed to participants were divided in three groups (with possible intersec-
quickly model the behavior of a system (used by Pramudianto [14] tions): (i) participants with no expertise in MDE, (ii) participants
and Node-Red, for example). with expertise in MDE and (iii) IoT experts.
AutoIoT: a Framework based on User-driven MDE for Generating IoT Applications ,,

The participants with no expertise in MDE represent 86% of It is possible that the participants were already considering tools
the total and reacted positively to all aspects evaluated. 97% of the that they know that could speed up the development process. This
participants agreed that the system generated by AutoIoT cover is a preliminary result, only 8 out of the 54 participants that partici-
the requirements of the scenario (S1) and all of them agreed that pated in the experiment declared to have expertise in MDE. This
using AutoIoT to generate the server application was easy (S6), as is expected since MDE experts are not the target audience for this
can be seen in Figure 7. In turn, 71.73% of the participants agreed work. To better understand this group, further studies including
that it is easy to use AutoIoT in a different IoT scenario (S2) and more MDE experts are needed.
84.78% agreed that they could use AutoIoT in a future IoT project The group with expertise in IoT mostly contains no MDE ex-
(S7). Only 4.34% and 6.52% of the participants had difficulties in perts, so its evaluation is very similar to the first group. The main
understanding the generated code (S4) and changing the behavior difference between both groups is that IoT developers are familiar
of the generated system (S5), respectively. Finally, 93.47% of the with the difficulties of developing the application to the proposed
participants agree that AutoIoT saves development time and that scenario. All of them agreed that they would take more than 40
replicating the software produced by AutoIoT manually would cost hours of work to implement the application generated by AutoIoT.
them more than 40 hours of work (S3). This work also shows that Web and IoT developers do not have
No participants of the group containing MDE experts disagreed expertise in many of the technologies required to use conventional
with S1, S4, S6, and S7, but 12.5% of them disagree about the time MDE-to-IoT approaches. This finding goes in accordance with [7],
necessary to create the same application generated by AutoIoT (S3), which found that less than 11% of a total of 3785 surveyed pro-
the easiness of change the JSON file for a different scenario (S2) and fessional developers use any form of modeling (even sketches in
about how easy would be to change the behaviour of the generated a whiteboard) during the development, and most of them do not
system (S5). know or do not remember formal notations, like UML.
In the last group (Figure 9), containing participants with expertise Finally, it is important to highlight that none of the developers
in IoT development, 96.55% of them agreed that the generated had any assistance other than the step-by-step tutorial provided
application cover all requirements of the scenario (S1). All of them during the experiment. Personal assistance or further documenta-
agreed that develop the generated system manually would take tion about AutoIoT were not provided. The lack of documentation
more than 40 hours (S3) and that use AutoIoT was easy (S6). 93.10% may be the reason behind some of the participants (7.40% of all
of them agreed that they would easily apply AutoIoT in a scenario participants) were not sure about how to extend the generated code
with different devices (S2) and 89.65% agreed that they could use (S5).
AutoIoT in future IoT projects (S7). Finally, only 3.44% thinks that
the generated code was not well organized (S4), and 6.89% of them
5 MORE COMPLEX USE CASES
were not able to extend the generated system (S5).
The system generated by the Prototype Builder (PB) is excellent for
prototyping development or scenarios that are very similar to the
4.3 Discussion one presented in Section 3.1, but since it is based on a monolith
Overall, all participants were satisfied with the system generated architecture, it would be hard to adapt its source code to more
by AutoIoT and its easy(and ready)-to-use feature. The results of complex IoT scenarios.
the evaluation show that the user-driven approach proposed by In bigger IoT projects, it is common to use a microservice archi-
this work and the AutoIoT framework accomplish its goals, pro- tecture [17], in which the complete system is composed of multiple
viding a tool that helps developers quickly create IoT server-side small independent services that communicate to each other using
applications with no need to learn new technologies, as shown by lightweight mechanisms. In those scenarios, AutoIoT could be used
the group with no MDE expertise (Figure 7). to generate some of these services, like a Device Twin Service, MQTT
The experiment also shows that the group with MDE expertise Message Processing Service, Report Generator Service or a GUI, for
is slightly more resistant to the AutoIoT approach (as shown in example. This way, the complete solution would be composed by
Figure 8), 12.5% of them had difficulties changing the model (the manually written software in conjunction with the ones generated
JSON file) and extending the generated source code. This probably automatically by AutoIoT.
happens because they are used to other kind of model representa- The main advantage in use AutoIoT compared to hand-written
tion and it is not common, in a traditional MDE approach, to ask software is that AutoIoT automatically adapts to the characteris-
users to change the generated source code. Usually the user rarely tics of the devices and sensors that are going to be used in the
update the generate code and, if a different output is desired, the new project. This means that changing one file (the JSON file that
models or the transformation usually need to be changed. contains the model) AutoIoT is able to generate multiple ready-
While working with models is natural to system designers and to-use microservices that can be automatically incorporated into
MDE experts, it is mainly avoided by common developers. Mostly the new project, with little-to-no change in the generated source
of the participants of the experiment showed no modeling expertise code. Without AutoIoT, either the microservices would need to be
and are used to work in the source code directly (Figure 6), using implemented or previous source code would need to be adapted,
AutoIoT as a tool to speed up the development in the initial phase increasing the cost of the project.
of the project. Additionally, 12.5% of the participants with MDE Furthermore, the microservices created by the Specialized Builders
expertise disagree that they would take more than 40 hours of work could also work in collaboration with other open-source projects
to manually develop the system generated by AutoIoT. like Node-RED, Eclipse Hono and Eclipse Ditto, for example.
,, T. Nepomuceno et al.

6 CONCLUSION for Digitalized Value Creation" within the framework of „BAYERN

With the growth of IoT applications, new IoT-specific technologies DIGITAL II“
have also arisen. In order to avoid the overload of such technologies,
many approaches have advocated the adoption of MDE with a REFERENCES
[1] S. Abrahão, F. Bourdeleau, B. Cheng, S. Kokaly, R. Paige, H. Stöerrle, and J. Whittle.
promise of long term benefits, but most of these work achieved 2017. User Experience for Model-Driven Engineering: Challenges and Future
limited success due to the use of tools and concepts very well known Directions. In 2017 ACM/IEEE 20th International Conference on Model Driven
in the MDE community, but less used outside of it [4, 8, 9]. Engineering Languages and Systems (MODELS). 229–236. https://doi.org/10.1109/
MODELS.2017.5
This work proposed AutoIoT, a framework based on a user-driven [2] Ala Al-Fuqaha, Mohsen Guizani, Mehdi Mohammadi, Mohammed Aledhari, and
MDE approach to develop IoT server-side applications. By using it, Moussa Ayyash. 2015. Internet of Things: A Survey on Enabling Technologies,
users can model their IoT scenarios either graphically (Web GUI) Protocols, and Applications. IEEE Communications Surveys & Tutorials 17, 4
(2015), 2347–2376. https://doi.org/10.1109/COMST.2015.2444095
or textually (manually writing a JSON file) and, through internal [3] Marco Brambilla, Eric Umuhoza, and Roberto Acerbis. 2017. Model-driven de-
M2M and M2T transformations carried by Specialized Builder com- velopment of user interfaces for IoT systems via domain-specific components
and patterns. Journal of Internet Services and Applications 8, 1 (26 Sep 2017), 14.
ponents, the source code of the IoT application is automatically https://doi.org/10.1186/s13174-017-0064-1
created. During the modelling developers only need to use tech- [4] Jesús Sánchez Cuadrado, Javier Luis Cánovas Izquierdo, and Jesús García Molina.
nologies that they are used to work with (JSON representation and 2014. Applying model-driven engineering in small software enterprises. Science
of Computer Programming 89 (2014), 176 – 198. https://doi.org/10.1016/j.scico.
a general programming language), thus decreasing the learning 2013.04.007 Special issue on Success Stories in Model Driven Engineering.
phase and easing the framework adoption. [5] Antonella Galizia, Gabriele Zereik, Luca Roverelli, Emanuele Danovaro, Andrea
According to the initial evaluation, AutoIoT can successfully be Clematis, and Daniele D’Agostino. 2019. Json-GUI—A module for the dynamic
generation of form-based web interfaces. SoftwareX 9 (2019), 28 – 34. https:
used to speed up the development of IoT server-side applications //doi.org/10.1016/j.softx.2018.11.007
and has been well received by Web and IoT developers. The partici- [6] Francesco Gianni, Simone Mora, and Monica Divitini. 2018. RapIoT toolkit: Rapid
prototyping of collaborative Internet of Things applications. Future Generation
pants of the evaluation reported more than 80% of satisfaction in Computer Systems (2018). https://doi.org/10.1016/j.future.2018.02.030
6 out of 7 evaluated criteria. Due to lack of documentation about [7] Tony Gorschek, Ewan Tempero, and Lefteris Angelis. 2014. On the use of software
the framework and the system generated by it during the experi- design models in software development practice: An empirical investigation.
Journal of Systems and Software 95 (2014), 176 – 193. https://doi.org/10.1016/j.
ment, only 74% of the participants reported being able to extend jss.2014.03.082
the generated system. This problem will be addressed in future [8] A. Hamou-Lhadj, A. Gherbi, and J. Nandigam. 2009. The Impact of the Model-
versions. Driven Approach to Software Engineering on Software Engineering Education.
In 2009 Sixth International Conference on Information Technology: New Generations.
This work shows how to design an user-driven MDE approach 719–724. https://doi.org/10.1109/ITNG.2009.160
with very simplified modeling phase, while still giving users some [9] John Hutchinson, Jon Whittle, and Mark Rouncefield. 2014. Model-driven en-
gineering practices in industry: Social, organizational and managerial factors
freedom and control over the system to be generated. Additionally, that lead to success or failure. Science of Computer Programming 89 (2014), 144 –
it demonstrates that hiding MDE concepts behind technologies 161. https://doi.org/10.1016/j.scico.2013.03.017 Special issue on Success Stories
that users already know has a great impact on user satisfaction in Model Driven Engineering.
[10] S. Mora, F. Gianni, and M. Divitini. 2016. RapIoT Toolkit: Rapid Prototyping of
and adoption of the approach. Furthermore, it does not intend to Collaborative Internet of Things Applications. In 2016 International Conference
replace existing MDE-to-IoT approaches. Instead, it gives develop- on Collaboration Technologies and Systems (CTS). 438–445. https://doi.org/10.
ers an option to get some benefits of MDE methods without the 1109/CTS.2016.0083
[11] B. Morin, N. Harrand, and F. Fleurey. 2017. Model-Based Software Engineering
need of learning MDE theory or using very specific MDE tools. Fi- to Tame the IoT Jungle. IEEE Software 34, 1 (Jan 2017), 30–36. https://doi.org/10.
nally, this work does not tackle all layers of a complete IoT system 1109/MS.2017.11
[12] X. T. Nguyen, H. T. Tran, H. Baraki, and K. Geihs. 2015. FRASAD: A framework
development, but rather focuses only on developing the server- for model-driven IoT Application Development. In 2015 IEEE 2nd World Forum
side application part. It does not generate device, gateway or data on Internet of Things (WF-IoT). 387–392. https://doi.org/10.1109/WF-IoT.2015.
analysis source code in the current stage. 7389085
[13] F. Pramudianto, M. Eisenhauer, C. A. Kamienski, D. Sadok, and E. J. Souto. 2016.
As future work it is planned the release of more Specialized Connecting the Internet of Things rapidly through a model driven approach.
Builders that will allow AutoIoT to be used to create IoT systems In 2016 IEEE 3rd World Forum on Internet of Things (WF-IoT). 135–140. https:
following the microservice architecture and tackle more complex //doi.org/10.1109/WF-IoT.2016.7845416
[14] F. Pramudianto, C. A. Kamienski, E. Souto, F. Borelli, L. L. Gomes, D. Sadok,
IoT use cases. Additionally, it is intended to create a better AutoIoT and M. Jarke. 2014. IoT Link: An Internet of Things Prototyping Toolkit. In
ecosystem, publishing the source code of the framework at the 2014 IEEE 11th Intl Conf on Ubiquitous Intelligence and Computing and 2014 IEEE
11th Intl Conf on Autonomic and Trusted Computing and 2014 IEEE 14th Intl Conf
Github and creating a website where users can share information on Scalable Computing and Communications and Its Associated Workshops. 1–9.
and custom created Specialized Builders. https://doi.org/10.1109/UIC-ATC-ScalCom.2014.95
Further information about AutoIoT Framework and its related [15] Alexey Savelyev and Emre Brookes. 2019. GenApp: Extensible tool for rapid
generation of web and native GUI applications. Future Generation Computer
projects can be found on Github10 . Systems 94 (2019), 929 – 936. https://doi.org/10.1016/j.future.2017.09.069
[16] C. S. Shih, J. J. Chou, N. Reijers, and T. W. Kuo. 2016. Designing CPS/IoT ap-
plications for smart buildings and cities. IET Cyber-Physical Systems: Theory
7 ACKNOWLEDGEMENT Applications 1, 1 (2016), 3–12. https://doi.org/10.1049/iet-cps.2016.0025
The research was partially supported by the Bavarian State Ministry [17] K. Vandikas and V. Tsiatsis. 2016. Microservices in IoT clouds. In 2016 Cloudifi-
cation of the Internet of Things (CIoT). 1–6. https://doi.org/10.1109/CIOT.2016.
of Economic Affairs, Regional Development and Energy (StMWi) 7872912
through the Center for Analytics – Data – Applications (ADA-
Center) and as part of the lead project "Technologies and Solutions

10 https://github.com/AutoIoT