2021 IEEE/ACM 3rd International Workshop on Software Engineering Research and Practices for the IoT (SERP4IoT)
2021 IEEE/ACM 3rd International Workshop on Software Engineering Research and Practices for the IoT (SERP4IoT) | 978-1-6654-4569-6/21/$31.00 ©2021 IEEE | DOI: 10.1109/SERP4IoT52556.2021.00008
Model-driven Development for ESP-based IoT
Systems
Burak Karaduman
University of Antwerp & Flanders Make, Belgium
burak.karaduman@uantwerpen.be
Abstract—The large variety of low-end devices and their
programming environment increases the development complexity
of embedded software for the Internet of Things. Therefore,
developing IoT-based systems has been found to be a complex
process. As a consequence, the development of these systems
becomes more error-prone, time-consuming and costly. ESP
(ESP8266 and ESP32) is one of the preferred micro-controllers
for education, industrial projects, and prototyping. Arduino, a
well-known firmware, is used in ESP which makes it easy-to-
use. However, learning the device-specific configurations, using
network features, and implementing IoT applications for ESP on
the Arduino platform are still burdensome and time-consuming
tasks. Raising the abstraction level can help to decrease the
complexity and address this problem. To this end, in this
paper, a model-driven approach is proposed for the development
of Arduino-based programmable ESP micro-controllers. First,
a meta-model is designed for the Arduino-based ESP micro-
controllers. Based on this meta-model, a Domain-specific Lan-
guage (DSL) is developed to graphically represent the domain
models. To gain more functionality for the language, domain
rules are defined as constraints. Also, partial system codes
are automatically generated from the instance models. In this
way, the development of IoT systems based on ESP modules is
supported by code synthesis which increases the performance
and reduces the number of errors. Finally, a motion-sensitive
thief detector and a servo-motor based room temperature control
system are implemented to evaluate the proposed DSL.
Index Terms—Model-driven Engineering, Metamodel,
Domain-specific (Modelling) Language, Internet of Things,
ESP32, ESP8266, Code generation
I. I NTRODUCTION
One of the popular IoT modules is ESP including ESP8266
and ESP32 versions. ESP32 is a 32-bit, low-cost, cheap ( 5$),
and dual-core micro-controller. It has integrated WiFi and
Bluetooth modules that target a wide variety of applications
ranging from low-power sensor networks to the most demand-
ing tasks [1]. It is Arduino based and preferred in various
domains such as smart farming, smart home automation, and
indoor-positioning systems [2]. Arduino is an open-source
programming environment for embedded devices based on
easy-to-use hardware and software. It is able to define and
command input/output ports, create a web server, and control
actuators like servo motors which can be fundamental features
to create an IoT system. It is preferred for education, self-
learning , and industrial tasks.
Building IoT systems require embedded hardware, develop-
ment firmware, software code, and networking. The resulting
978-1-6654-4569-6/21/$31.00 ©2021 European Union
DOI 10.1109/SERP4IoT52556.2021.00008
Authorized licensed use limited to: Aristotle University of Thessaloniki. Downloaded on July 04,2024 at 11:49:11 UTC from IEEE Xplore. Restrictions apply.
Moharram Challenger
University of Antwerp & Flanders Make, Belgium
moharram.challenger@uantwerpen.be
system is complex with different components requiring to be
programmed to work collaboratively. This complexity makes
learning and programming of these systems time-consuming,
costly, and cumbersome. This can be addressed with Model-
Driven Engineering (MDE) techniques [3] which suggests
using models during the development of the system. In this
way, the system can be designed and developed with more
abstract elements that represent the system components. When
the system is modeled, most of the code can be automatically
synthesized. Moreover, these models can be used for the early
analysis and validation of the target system. To this end, we in-
troduce a Domain-specific Language (DSL), called DSL4ESP,
for the design and development of ESP and Arduino based
IoT systems. DSL4ESP raises the level of abstraction from the
Arduino language level to the model level, which is leading
to increase in the development performance and decrease
in the number of errors. Also, learning the device-specific
configurations, using network features, and implementing IoT
applications for ESP on the Arduino platform are burdensome
and time-consuming tasks. Raising the abstraction level can
help to decrease the complexity and improve the learning curve
of these systems.
This study contributes to the literature by providing a
Model-driven Engineering (MDE) approach for developing
IoT systems based on ESP32 hardware and Ardunio frame-
work. To the best of our knowledge, currently, there is no
study to address MDE based modeling and development of IoT
systems using ESP32 and Arduino. This study, can facilitate
the efficient development of IoT systems based on ESP32
device and Arduino environment.
This paper is organized as follows: The next section reports
the literature. Section 3 discusses the proposed DSL called
DSL4ESP including the abstract syntax, the concrete syntax
and the code generation. Section 4 elaborates the case study
and evaluates the performance of the proposed modeling
language. Finally, the paper is concluded in Section 5.
II. R ELATED W ORK
There are some studies in the literature applying MDE
approaches on various IoT systems. LwiSSy is a DSL to model
Wireless Sensor and Actuators Network (WSAN) systems [4].
It allows the separation of responsibilities between application
domain experts and network experts. In [5], a Model-Driven
9
Architecture (MDA) is proposed which provides Platform-
Independent Modeling (PIM), Platform-Specific Modeling
(PSM), and transformation rules for WSAN application de-
velopment. Doddapaneni et al. [6] propose a framework to
separately model the software components and their interac-
tions, the low-level and hardware specification of the nodes,
and the physical environment where the nodes are deployed. A
similar study [7] provides a Platform-Independent metamodel
and graphical editor for IoT systems. They use ESP8266 and
Arduino environment in their study. However, they do not
provide any M2M communication like web-server in their case
study. They provide higher view in their approach compared
to our specialised aspect. They categorised the sensors and
actuators as types. In our design, we modelled them as I/O
operations, because we think that they are port reading and
writing operations fundamentally. Fig. 1. DSL4ESP Meta-model.
We had a series of studies with the ultimate goal of
providing a platform-independent generative modeling lan-
guage supporting both WSN and WiFi based IoT systems • Wifi: This element configures wifi connection. Mode
independent of target tools/languages/platforms. In this regard, attribute specifies the operation mode of the ESP. Wifi-
we have developed a meta-model for ContikiOS [8]. Also, ClientName represents the current client in the incoming
domain-specific languages have been developed for TinyOS requests. Gateway, Subnet and IP attributes are required
[9], RIOT [10] and ContikiOS [11]. Moreover, to evaluate fields for network connection.
these DS(M)Ls, different case studies [12]–[16] have been im- • Servo: This element represents servo motor (it can be
plemented. Lastly we have provided a Petri-net based analysis extended to any acutator) that is connected to the ESP.
for IoT and WSN based systems [17]. Name attribute identifies the label of the servo element
(e.g., doorlock servo). Port attribute represents the pin
III. DSL4ESP: D OMAIN - SPECIFIC L ANGUAGE FOR ESP number of the ESP to which the servo is connected. Angle
field defines the rotation angle of the servo.
This section presents the main elements of the DSL in-
• ESP Node: This element is used to create an ESP node.
cluding the abstract syntax (meta-model), the concrete syntax
Specifically, it represents an ESP device. SSID and Pass-
(graphical notations mapped to the meta-elements), static
word parameters define network name and password.
semantics (constraint checking rules), and code generation
Host field defines which service is going to be connected
(translational semantics) of the language.
for data transmission (e.g. Thingspeak or Firebase). Se-
A. The Syntax of the DSL rialNo defines baud rate for serial communication.

The meta-model of DSL4ESP is introduced in this section.
It represents the abstract syntax of the domain-specific lan-
guage. Generally, a meta-model represents system elements,
relations, and cardinally constraints of the elements. It can
also contains some attributes and operations for the elements.
The meta-model is implemented in EMF Ecore framework.
The important elements of the meta-model for DSL4ESP
are described below:
• ESP Platform: It is the root element of the DSL4ESP. It
has a containment relation with all ESP elements which
need to be represented in the editor palette.
• HttpClient: It represents an HTTP client to send re-
quest(s) to the web-server. In this way, machine-to-
machine communication between IoT nodes can be
achieved. HTTP requests are useful communication ap-
proach when there are many features that need to be
triggered at the server-side.
• WebServer: This element creates a web-server inside
ESP32 device. webserver listens to the port number as-
signed by PortNo attribute for upcoming HTTP requests.
The meta-elements of the meta-model are mapped to graph-
ical notations and a graphical editor is developed in Eclipse
using Sirius Framework. This editor supports DSL4ESP for
designing the application models.
B. Static Semantics
To empower the language, in addition to cardinality con-
strains of the meta-model, some other domain-specific con-
straints are added to the editor. These constraint rules apply
some static checks for the semantics of the designed models
by the end user. These rules are implemented in the DSL4ESP
editor using Acceleo Query Language (AQL). This can help
the designer (the end user) to have less semantic errors in the
model. The syntactic error are already checked by the syntax
directed editor developed using the meta-model.
1) aql: self.No > 0
2) aql: not(self.eContainer().eContents(PSMM::GPIO ESP)
→ select (myGPIO ESP — myGPIO ESP.No =
self.No) → excluding(self)→size() > 0)

10

Authorized licensed use limited to: Aristotle University of Thessaloniki. Downloaded on July 04,2024 at 11:49:11 UTC from IEEE Xplore. Restrictions apply.
 3) aql: not (self.eContainer().eContents(PSMM::Servo)
→ select (myServo — myServo.Port=self.Port)
→ excluding(self) → size() > 0)
4) aql: self.IP.contains(’,’)
5) aql:self.Subnet.contains(’,’)
6) aql:self.Gateway.contains(’,’)
7) aql:self.Mode.size() > 0
The first constraint rule checks if any port number is entered
as a negative value. It warns the user to select a positive
value. The second constraint rule controls that if any GPIO
pin number is used more than once. In this way, any design
problem during port definition can be avoided. The third
constraint rule finds servo element instances, selects elements
that have the same port number. If the port numbers are the
same, then one of the servos does not operate. Therefore, in
these cases, the editor issues an error to the designer. The
fourth, fifth and sixth constraint rules check that if the user
used commas to separate addresses instead of periods. This
is because Arduino firmware uses C/C++ syntax to define IP
address, subnet, and gateway values and based on this syntax
it is required to use comma to separate the address elements.
Finally, in the seventh constraint, the WiFi mode is checked
in order to warn the user if this field is empty.
C. Transnational Semantics
In this section, the code generation mechanism of DSL4ESP,
using some translation rules, is elaborated. To this end, model
to code/text transformation is used. Some excerpts of the
generation rules are given and discussed below.
Listing 1. Code excerpts from DSL4ESP
1 [ if (e . wifi . IP−>size()>0)] IPAddress ip ([ e . wifi . IP /]) ;
2 IPAddress gateway([e . wifi .Gateway/]) ;
3 IPAddress subnet ([ e . wifi .Subnet /]) ; [/ if ]
4 [ if (e . gpio esp−>size()>0)]
5 [ for (p:GPIO ESP | aIoTSystem.esp.esp node−>at(i).
gpio esp)]
6 [ if p.Type. contains ( ’ digital input ’ ) or p.Type. contains ( ’
digital output ’ ) ]
7 pinMode([p.Name/], [p.Type /]) ; [/ if ]
8 [ if p.Type. contains ( ’ digital input ’ ) ]
9 int dread [p.Name/] = digitalRead ([ p.No/]) ;[/ if ]
10 [ if p.Type. contains ( ’ digital output ’ ) ]
11 int dwrite [p.Name/]= digitalWrite ([ p.No/], 125) ;[/ if ]
12 [ if p.Type. contains ( ’ analog input ’ ) ]
13 int aread [p.Name/] = analogRead([p.No/]) ;[/ if ]
14 [ if p.Type. contains ( ’ analog output ’ ) ]
15 int awrite [p.Name/] = analogWrite([p.No/],125) ;..
16 [ if (e . servo−>size()>0)]
17 [ for (s : Servo | e . servo ) ]
18 [e . webserver.Name/].on(” /[ s .Name/] [s.Port /] [s .Angle/]” ,
handle [s .Name/] [s.Port /] [s .Angle /]) ;
19 [e . webserver.Name/].on(” /[ s .Name/] [s.Port /] 0”, handle [
s . Name/] [s.Port /] 0) ;[/ for ][/ if ]
20 [ if (e . servo−>size()>0)]
21 [ for (s : Servo | e . servo ) ]
22 void handle [s .Name/] [s.Port /] [s .Angle /]() {
23 [s . Name/].write ([ s .Angle /]) ;
24 [e . webserver.Name/].send(200, ” text /html”, ”ServoTurns [s
. Angle/]”) ; }
25 void handle [s .Name/] [s.Port /] 0(){
11
Authorized licensed use limited to: Aristotle University of Thessaloniki. Downloaded on July 04,2024 at 11:49:11 UTC from IEEE Xplore. Restrictions apply.
26 [s .Name/].write (0) ; [e .webserver.Name/].send(200, ” text /
html”, ”Servo Goes 0”); }[/ for ][/ if ]
27 [ for (h: HttpClient |aIoTSystem.esp.esp node. httpclient ) ]
28 http . begin(”[h.Name/]”); // Specify the URL
29 int httpCode = http .GET();
30 http .end() ; // Make the request [/ for ]
In listing 1, the lines between 1 and 3 generate IP, gate-
way, and subnet variables. The lines between 4 and 15 are
written to generate input-output ports. They can be either
analog or digital ports. The user should give one of these
parameters ”digital input”, ”digital output”, ”analog input”
or ”analog output” to define the role of the port. In the lines
between 17 and 26, webserver codes and web server controlled
servo requests are generated. The user can make requests to
these URLs to rotate the servo motor up to the designer’s angle
selection. Finally, the lines between 27 and 30 describes the
HTTP requests’ code generation rules.
IV. C ASE STUDIES AND E VALUATION
To validate DSL4ESP and evaluate its code generation
capability, two case studies are designed and implemented
using DSL4ESP. The models of the case studies are shown
in fig 4. The architectural codes are generated using the DSL
based on the designed models and then the delta codes are
added to have the final code.
Case 1: Motion Sensitive Thief Detector
This case study uses two ESP32 devices. The client ESP32
samples digital signal from the motion sensor. The sensitivity
and range of the motion sensor can be configured. When
motion sensor detects any movement (meaning a thief in the
room), it sends a request to the server ESP32 to turn on the
built-in LED. In addition to LED, a buzzer can also be used to
make an alarm. To achieve this case study a digital output pin
on the server side and a digital input pin on the client side are
used. The implemented version of this case study is shown in
Fig. 2.
Fig. 2. Motion sensitive thief detector.
Case 2: Servo motor based Room Temperature Control
This case study uses ESP32 modules to control room
temperature. A temperature sensor on the client side is used.
When the heat exceeds the set point, then a servo motor can
rotate to open/close the window. The implemented version of
this case study is shown in Fig. 3
These case studies have been modeled in DSL4ESP, see Fig.
4 and their architectural codes are generated automatically.
Evaluation of our modeling language is done by assessing
its code generation capabilities. This was done by comparing

Fig. 3. Servo motor based room temperature.
Fig. 4. Models of the case studies.
the lines of generated code and the final code (the code after
adding the delta codes). Fig 5 shows the evaluation results of
both case studies (the average of the results). Generally, the
server side did not require much delta codes. The client sides
required delta codes for the logical comparison in the program,
e.g., if the sensor value is higher than the set point. According
to the results (average for both case studies), the generation
performance for the server side is 95% and for the client side
is 84%. The grant average of the generation performance for
both server and client sides is 89% of the total code.
Fig. 5. Evaluation result of both case studies.
V. C ONCLUSION AND F UTURE W ORK
In this study, a domain-specific language is presented, called
DSL4ESP, including its abstract and concrete syntaxes as
well as static and translational semantics. Also, the DSL is
evaluated using two case studies. According to the results
of this evaluation, 89% of the total code of the system is
generated automatically. As future work, we plan to 1) extend
the language to support a wide range of sensors and actuators,
12
Authorized licensed use limited to: Aristotle University of Thessaloniki. Downloaded on July 04,2024 at 11:49:11 UTC from IEEE Xplore. Restrictions apply.
and 2) raise the level of abstraction for the modeling envi-
ronment to support Arduino level programming in Platform-
Independent level.
R EFERENCES
[1] A. Maier, A. Sharp, and Y. Vagapov, “Comparative Analysis and
Practical Implementation of the ESP32 Microcontroller Module for the
Internet of Things,” in 2017 Internet Technologies and Applications
(ITA), pp. 143–148, IEEE, 2017.
[2] N. Karimpour, B. Karaduman, A. Ural, M. Challenger, and O. Dagde-
viren, “IoT based Hand Hygiene Compliance Monitoring,” in 2019
International Symposium on Networks, Computers and Communications
(ISNCC), pp. 1–6, IEEE, 2019.
[3] D. C. Schmidt, “Model-Driven Engineering,” Computer-IEEE Computer
Society-, vol. 39, no. 2, p. 25, 2006.
[4] P. Dantas, T. Rodrigues, T. Batista, F. C. Delicato, P. F. Pires, W. Li, and
A. Y. Zomaya, “LWiSSy: A Domain Specific Language to Model Wire-
less Sensor and Actuators Network Systems,” in 2013 4th International
Workshop on Software Engineering for Sensor Network Applications
(SESENA), pp. 7–12, May 2013.
[5] T. Rodrigues, F. C. Delicato, T. Batista, P. F. Pires, and L. Pirmez,
“An approach based on the domain perspective to develop WSAN
applications,” Software & Systems Modeling, vol. 16, no. 4, 2017.
[6] K. Doddapaneni, E. Ever, O. Gemikonakli, I. Malavolta, L. Mostarda,
and H. Muccini, “A Model-driven Engineering Framework for Archi-
tecting and Analysing Wireless Sensor Networks,” in 3rd International
Workshop on Software Engineering for Sensor Network Applications,
SESENA ’12, (Piscataway, NJ, USA), pp. 1–7, IEEE Press, 2012.
[7] D. Alulema, J. Criado, and L. Iribarne, “A Model-driven Approach for
the Integration of Hardware Nodes in the IoT,” in World Conference on
Information Systems and Technologies, pp. 801–811, Springer, 2019.
[8] C. Durmaz, M. Challenger, O. Dagdeviren, and G. Kardas, “Modelling
Contiki-Based IoT Systems,” in 6th Symposium on Languages, Appli-
cations and Technologies (SLATE 2017), vol. 56 of OpenAccess Series
in Informatics (OASIcs), (Dagstuhl, Germany), pp. 5:1–5:13, 2017.
[9] H. M. Marah, R. Eslampanah, and M. Challenger, “DSML4TinyOS:
Code Generation for Wireless Devices,” in International Workshop on
Model-Driven Engineering for the Internet-of-Things, 2018.
[10] B. Karaduman, M. Challenger, R. Eslampanah, J. Denil, and
H. Vangheluwe, “Platform-specific Modeling for RIOT based IoT Sys-
tems,” in Proceedings of the IEEE/ACM 42nd International Conference
on Software Engineering Workshops, pp. 639–646, 2020.
[11] T. Zafer Asici, B. Karaduman, R. Eslampanah, M. Challenger, J. Denil,
and H. Vangheluwe, “Applying Model Driven Engineering Techniques
to the Development of Contiki-based IoT Systems,” in 1st International
Workshop on Software Engineering Research & Practices for the Inter-
net of Things (SERP4IoT 2019), Accepted.
[12] B. Karaduman, M. Challenger, and R. Eslampanah, “ContikiOS based
Library Fire Detection System,” in 2018 5th Intl. Conf. on Electrical
and Electronic Engineering (ICEEE), pp. 247–251, IEEE, 2018.
[13] B. Karaduman, T. Aşıcı, M. Challenger, and R. Eslampanah, “A Cloud
and Contiki based Fire Detection System using Multi-Hop Wireless Sen-
sor Networks,” in Proceedings of the Fourth Intl. Conf. on Engineering
& MIS 2018, p. 66, ACM, 2018.
[14] S. Arslan, M. Challenger, and O. Dagdeviren, “Wireless Sensor Network
based Fire Detection System for Libraries,” in 2017 International
Conference on Computer Science and Engineering (UBMK), pp. 271–
276, IEEE, 2017.
[15] M. Challenger, R. Eslampanah, B. Karaduman, J. Denil, and
H. Vangheluwe, “Development of an IoT and WSN based CPS us-
ing MPM approach: A Smart Fire Detection Case Study,” in Multi-
Paradigm Modelling Approaches for Cyber-Physical Systems, Chapter
10, (B. Tekinerdogan, D. Blouin, H. Vangheluwe, M. Goulão, P. Carreira,
and V. Amaral, eds.), pp. 245–270, Academic Press, 2021.
[16] L. Özgür, V. K. Akram, M. Challenger, and O. Dağdeviren, “An IoT
based Smart Thermostat,” in 5th International Conference on Electrical
and Electronic Engineering (ICEEE), pp. 252–256, IEEE, 2018.
[17] B. Karaduman, M. Challenger, R. Eslampanah, J. Denil, and
H. Vangheluwe, “Analyzing WSN-based IoT Systems using MDE Tech-
niques and Petri-net Models,” in 4th International Workshop on Model-
Driven Engineering for the Internet-of-Things (MDE4IoT), Co-Located
With Software Technologies: Applications and Foundations (STAF 2020),
Virtual Event, Norway, pp. 35–46, 2020.