=Paper=
{{Paper
|id=Vol-2716/paper7
|storemode=property
|title=A Toolbox for the Internet of Things – Easing the Setup of IoT Applications
|pdfUrl=https://ceur-ws.org/Vol-2716/paper7.pdf
|volume=Vol-2716
|authors=Matheus Frigo,Pascal Hirmer,Ana Cristina Franco da Silva,Lucinéia Heloisa Thom
|dblpUrl=https://dblp.org/rec/conf/er/FrigoHST20
}}
==A Toolbox for the Internet of Things – Easing the Setup of IoT Applications==
https://ceur-ws.org/Vol-2716/paper7.pdf
Judith Michael, Victoria Torres (eds.): ER Forum, Demo and Posters 2020 87
A Toolbox for the Internet of Things –
Easing the Setup of IoT Applications
Matheus Frigo1,2 , Pascal Hirmer2 ,
Ana Cristina Franco da Silva2 , and Lucinéia Heloisa Thom1
1
Institute of Informatics, Federal University of Rio Grande do Sul,
Bento Gonçalves Avenue, 9500, Porto Alegre, Brazil
lastname@inf.ufrgs.br
https://www.inf.ufrgs.br
2
Institute for Parallel and Distributed Systems, University of Stuttgart,
Universitätsstraße 38, 70569 Stuttgart, Germany
lastname@informatik.uni-stuttgart.de
https://www.ipvs.uni-stuttgart.de/
Abstract. The Internet of Things (IoT) is a paradigm that aims at
making people’s life easier, e.g., through highly automated production
processes in Smart Factories. In the IoT, heterogeneous interconnected
devices communicate through standardized internet protocols to reach
common goals. Well-known applications of the IoT are Smart Homes,
Smart Factories, or Smart Cities. However, setting up new IoT environ-
ments can be cumbersome, since this oftentimes requires many complex
manual steps, such as setting up devices, configuring sensors, or writing
scripts. The heterogeneity and high distribution in the IoT makes this
task even more complex and time-consuming. To ease the setup of IoT
environments, we propose a new approach composed of (i) a toolbox with
common building blocks of the IoT, and (ii) a business process based ap-
proach to orchestrate the setup of these building blocks. Through our
approach, domain experts can select the building blocks they require for
their IoT application and generate a step-by-step manual for their setup.
Keywords: Internet of Things · Toolbox · BPM · Domain Experts
1 Introduction
In the Internet of Things (IoT), interconnected devices communicate through
standardized internet protocols to achieve common goals [17]. Usually, these
devices are connected to sensors, to monitor the environment, and actuators to
control it. The IoT enables creating new kinds of applications, such as Smart
Homes [8], Smart Cities [5], or Smart Factories [15].
However, since devices in the IoT are very heterogeneous, building IoT appli-
cations can be very cumbersome [11]. For example, there are powerful devices,
such as Raspberry Pis, able to provide an operating system and built-in com-
munication technologies, such as WiFi or Bluetooth. In contrast, there are very
Copyright © 2020 for this paper by its authors.
Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
88 M. Frigo et al.
restricted devices, such as micro-controller boards, that do not provide any so-
phisticated operating system but rather a limited runtime environment to run
small scripts, usually implemented in C programming language. Some of these
restricted devices provide a WiFi connection, others require Bluetooth or need
to be connected via cable.
Furthermore, in the IoT, not only the devices are very heterogeneous but
also the communication protocols, e.g., CoAP [3], MQTT [9], or HTTP. This
makes selection of the right hardware components and protocols for building IoT
applications even more complex. Consequently, there is a demand for coping with
this large heterogeneity and to support IoT application developers in making
the right choices when it comes to hardware, technology, and protocol selection.
This wide variety also introduces a challenge to create and use a uniform way of
describing things in smart spaces in terms of what a particular thing is, what is
does and how it communicates [10].
To cope with this issue, in this paper, we introduce a new approach for eas-
ing the setup of IoT environments and their applications. First, we introduce
a toolbox, containing common building blocks that are oftentimes used in the
creation of IoT environments. These building blocks can represent hardware com-
ponents, network protocols, message brokers, gateways, IoT platforms, or any
other software component. A building block consists of a high-level description
to be understandable by domain experts as well as concrete implementations.
These building blocks offer a uniform way of describing the software and hard-
ware components of an IoT application. The building blocks are provided by
experts in building IoT applications and are provided by a toolbox, which can
be accessed by domain experts.
Second, we introduce a business process based approach to ease the set up
of an IoT environment based on the suggested building blocks. Usually, setting
up IoT environments requires many different steps that can be conducted either
in parallel or sequentially in case of any dependencies. For example, before con-
necting a device to an IoT platform, a network connection needs to be set up.
Hence, it makes sense to use business process management for orchestration of
these steps. In this paper, we use the Business Process Model and Notation 2.0
(BPMN 2.0) [4] for modeling of the processes.
The remainder of this paper is structured as follows: in Section 2, we in-
troduce our main contribution: a toolbox for the Internet of Things. Section 3
then describes a case study, which applies our approach to the Smart Factory
domain. Section 5 discusses related work and, finally, Section 6 summarizes our
paper and gives an outlook on future work.
2 A Toolbox for the Internet of Things
In this section, we introduce a holistic method that describes the necessary steps
domain experts need to undertake to set up IoT applications from scratch. This
method is depicted in Figure 1. The foundation for this method is our toolbox,
containing a predefined set of building blocks that can be combined to set up
A Toolbox for the Internet of Things 89
Building Process
Requirement
Block Creation
Specification
Selection
Domain 1 2 3
experts Feedback
IoT IoT
Process
Environment Environment
Execution
Retirement Adaptation
6 5 4
Method step
Fig. 1. Method for setting up IoT environments based on our toolbox
the desired IoT application. Even though this method is generic in terms of the
kinds of applications that should be set up, applying it specifically to the IoT
domain emphasizes its strengths, since in the IoT, usually many heterogeneous
software and hardware components need to be set up, which can overwhelm
application providers. Our method can help in setting up IoT environments with
low effort and decreased necessary technical knowledge since technical details are
abstracted through the building blocks.
In the first step of this method, domain experts and involved stakeholders
discuss the characteristics of their IoT application and define a set of require-
ments for the application. The set of requirements is defined as R 6= ∅, whereas
each r ∈ R describes a specific application requirement. After that, in the second
step, the toolbox recommends building blocks to be selected by domain experts.
In step 3, a business process is created by experts based on the selected building
blocks, defining the necessary steps that need to be undertaken to set them up.
In step 4, this process is executed, guiding the domain experts in the process of
creating the IoT environment for their application. In step 5, the IoT applica-
tion is tested and, if there are no changes necessary, it goes into production. A
feedback loop in this method ensures that new requirements can be considered
also after the setup. In the final step 6, the IoT environment is retired, once an
IoT application reaches its lifetime. In the following, the toolbox and the steps
of this method are described in more detail.
2.1 Toolbox and Building Blocks
Our toolbox offers a set of building blocks (BB) that are divided into differ-
ent categories. These categories include, for example, physical devices, network
protocols, or software applications. In order to ensure understanding and appli-
cability of our approach, we introduce a formalization of the toolbox. A BB is
formalized as follows:
90 M. Frigo et al.
Name: Publish-
Subscribe
Name
Type:
Type Communication
Description: Loosely
BB: Description BB: coupled communication
Building Block Dependencies Building Block
Dependencies: None
Icon Icon:
Capabilities
Capabilities:
Loose Coupling
Fig. 2. Left: Remainder of a Building Block, right: Building Block example for publish-
subscribe communication
Definition 1 (Building Block). Let bb ∈ BB be a tuple bb := (N ame, T ype,
Description, Dependencies, Icon, Capabilities), whereas BB is the set of all
available building blocks in the toolbox T B. A bb has the following properties:
– N ame 6= ∅: unique name of the building block.
– T ype 6= ∅ : the type t ∈ T , where T is the set of available bb types.
– Description: optional description.
– Dependencies: set of bb ∈ BB related to this building block.
– Icon 6= ∅: icon of the building block.
– Capabilities: set of capabilities of the building block, used to map user re-
quirements to the BBs of the toolbox.
Figure 2 depicts on the left the structure of a building block. Each block con-
tains a name, a type, a description (suitable for domain experts), dependencies
to other building blocks, an icon to ensure recognition, and a set of capabilities
that are able to fulfill the users’ requirements. On the right of Figure 2, an exam-
ple building block is given for the communication paradigm publish-subscribe,
enabling loosely coupled communication. In an initial phase, experts in the IoT
domain need to agree upon a common list of building blocks, which has to be
extensible, since new technologies appear frequently in the IoT. We are aware
that this is an ambitious goal, which would require some sort of standardization
IoT experts agree upon. In our vision, IoT technology providers create building
blocks themselves in order to promote their new solutions and add them to the
toolbox. With a strong community, the toolbox could grow to a comprehensive
collection of all kinds of IoT components.
Each BB has one or more implementations, which are referred to as building
block implementation (BBI) in the following. A BBI is a concrete implementation
of a BB, which is formalized as follows:
Definition 2 (Building Block Implementation). Let bbi ∈ BBI be a tuple
(N ame, Artif act, Description, Icon, ImplementedBB, Dependencies), whereas
BBI is the set of all available building block implementations in the toolbox T B.
A bbi contains:
A Toolbox for the Internet of Things 91
– N ame 6= ∅: unique name of the building block implementation.
– Artif act: software artifacts.
– Description: optional description.
– Icon 6= ∅: icon of the building block implementation.
– ImplementedBB 6= ∅: a list of BB implemented by the building block im-
plementation.
– Dependencies: list of bbi ∈ BBI related to this building block implementa-
tion.
Furthermore, bbiM apping : BB → BBi corresponds to the mapping, which
assigns a BB to one or more BBIs.
A BBI contains a software artifact, which can be of different types, e.g., a
Docker container, a cloud service, or a binary application. Furthermore, BBIs
can have a set of dependencies that could require installation of different BBIs.
For example, some BBIs might require the installation of certain programming
languages (Java, Python) or a specific operating system. In addition, each BBI
requires a definition of its interfaces to enable an easy orchestration via business
processes. In case of software artifacts, these interface descriptions should be
defined based on standards, such as WSDL [18].
For our BB example in Figure 2, implementations include MQTT brokers,
such as Mosquitto or RabbitMQ. Once domain experts decide to use the publish-
subscribe paradigm, they will find the according building block in the toolbox
and will be able to select one of the corresponding implementations.
The BBs and BBIs can be defined in a hierarchical structure, meaning that
building blocks can inherit characteristics of other building blocks, enabling their
specialization. The depth of the hierarchy is arbitrary and is decided by the
designer of the toolbox. Figure 3 depicts an example of hierarchical building
blocks for a connection between devices. In this example, as root, the generic
building block “Connection” is defined, representing all possible kinds of connec-
tions. This Connection BB is then derived to the “Wireless Connection” building
block, which represents all connection BBs that are wireless. The Wireless Con-
nection BB has three different implementations, which can again be derived by
different BBIs. Each BBI could have BB and/or BBI dependencies, and one BBI
can implement one or more BBs, therefore the relationship between BBIs could
be AND, OR or both. After the toolbox is filled with BBs and BBIs, it can serve
as a foundation for our method to set up IoT environments, which is described
in the following.
Step 1: Requirement Specification
In the first step of our method, IoT application developers, i.e., the domain
experts and their stakeholders, need to define a set of requirements for their
application.
A requirement is a condition or capability needed by the user to solve a
problem or to achieve an objective [14]. These requirements in an IoT system’s
context can be functional (e.g., sensed variable, sending rate) or non-functional,
also known as quality-of-service requirements (e.g., lifetime, reliability) [6].
92 M. Frigo et al.
Fig. 3. Hierarchy of building blocks, example for a Wireless Connection building block
The toolbox provides a list of predefined requirements for the most common
IoT application scenarios where the stakeholders can find the requirements that
fit their needs. The list should be kept up-to-date to the current state-of-the-art
of the IoT field. These requirements need to consider different aspects, such as
network capabilities, used communication paradigms, costs, efficiency, security,
privacy, available computing resources, and so on. Defining such requirements
might involve many different stakeholders and even a requirements engineer, i.e.,
a person who understands the domain of the desirable application and also pos-
sesses enough IoT knowledge to be aware of the suitable features and resources
for the development. E
To enhance the reusability of the toolbox in multiple projects, a systematic
collection of requirements and the respective chosen building blocks are docu-
mented to provide an overview of possible relations, assisting in requirements
engineering for future applications.
Step 2: Building Block Selection
In the second step of our method, involved stakeholders select the building blocks
they need based on the set of requirements created in step 1. As mentioned
before, the toolbox contains a collection of best practices in IoT application
development and, hence, gives an overview regarding which technologies and
approaches are available without the need for domain experts to acquire this
knowledge themselves.
The selection of BBs is made based on recommendations by the toolbox,
which are generated by matching the requirements of the IoT application to
the capabilities of the building blocks. The final selection is conducted by the
involved stakeholders. We define the mapping that assigns a requirement to one
or more building blocks as reqM apping : R → BB.
A Toolbox for the Internet of Things 93
To make this selection process more clear, let us assume that a company aims
at developing a smart factory application in which self-driving vehicles transport
goods on the shop floor. The goal of this application is that these vehicles dynam-
ically determine the best routes and also consider other vehicles as well as people
and utilities of the shop floor. To achieve this, the vehicles need to be equipped
with sensors, monitoring the environment, and need to communicate with other
vehicles and participants on the shop floor through a wireless network. Setting
up such a complex scenario, requires the expertise of many different stakeholders
that need to agree upon functional and non-functional requirements. Regarding
functionality, for example, an indoor localization system is essential to monitor
the position of vehicles, utilities and people on the shop floor. In addition, a
broad-band wireless network (e.g., 5G) needs to be established to cope with the
high data load. Furthermore, non-functional requirements are of high importance
in such safety-critical environments. Security, safety, robustness, accuracy and
real-time capabilities are only some of the essential requirements of this scenario.
In workshops, the stakeholders need to assess and discuss the requirements.
Based on the functional requirements ”indoor localization” and ”wireless
communication”, we show in Table 1, which BBs and BBIs could be recom-
mended by the toolbox:
Table 1. Example of BB and BBI selection.
Building Block Matching Requirement Implemented by BBI
UWB Localization indoor localization RTLS localization modules
BLE Localization indoor localization BLE modules
WiFi wireless communication WiFi network
LTE wireless communication 4G network
5G wireless communication 5G network
If we now consider the non-functional requirements as well, for example high-
efficiency, robustness, and accuracy, the toolbox would filter the resulting BB list
accordingly. For example, localization using BLE and triangulation has issues
regarding accuracy and also efficiency. Hence, the BB ”BLE localization” would
not be recommended by the toolbox, but rather a solution based on UWB (ultra-
wideband). Similiar issues occur for WiFi connections, since they tend to be
unstable. The toolbox could suggest using LTE or 5G networks. The company
can then choose depending on costs or already available infrastructure on the
shop floor.
Once the BBs are selected, a list of available BBIs is generated by the tool-
box. The selection of the BBIs is then conducted by the stakeholders based on
available expertise or costs.
Step 3: Process Creation
The third step deals with the business process modeling [7] to guide domain ex-
94 M. Frigo et al.
Install Measure
Configure
stationary receiver
channel
UWB receivers connection
Validate
Install mobile Configure
positioning of
UWB senders channel
receivers
Install position Integrate
calculation on and test
edge cloud the system
Fig. 4. Exemplary simplified BPMN 2.0 process to set up the indoor localization system
perts and involved stakeholders through the process of setting up their IoT envi-
ronment. The tasks of the process set up the previously selected BBIs, whereas
usually several process tasks are required for each BBI. The business process
creation needs to be conducted manually by experts, which can become a cum-
bersome and time-consuming task.
Hence, setting up a given BBI in most of the cases will need common steps
to be taken even in different scenarios and the toolbox categorizes these typical
steps as best practices that can be used for the process creation. Assume, for
example, that a BBI sets up an indoor localization system on the shop floor, the
corresponding steps that need to be undertaken are mostly the same for different
companies with only minor differences based on the layout of the shop floor.
An example of a process is provided in Figure 4 in BPMN 2.0 syntax. This
process shows a simplified version of the different steps to set up an indoor lo-
calization system using UWB technology, as discussed above. In parallel, the
receiver and sender hardware needs to be installed on the shop floor. Further-
more, software for calculation of the position needs to be installed in an edge
cloud environment, which will later communicate with the receivers. After con-
figuration and measurements of the hardware, the system can be integrated,
tested, and can then go into production.
Note that the configuration of different BBIs can have a different number of
tasks in the process due its complexity, as shown in our example process. For
manual creation, the above mentioned best practices can help in selecting the
tasks for the creator.
Step 4: Process Execution
In step 4, the process is then executed in order to realize the setup of the IoT
environment. Depending on the chosen modeling language, a suitable BPMN 2.0
Business Process Management System (BPMS) needs to be provided. For BPMN
2.0, for example, the established BPMS Camunda could be used. In each step
of the process, domain experts get a notification about the tasks they need to
A Toolbox for the Internet of Things 95
conduct, for example, plugging in sensors, configuring a WiFi connection, or
installing software on IoT devices. Documentation of the different technologies
that are set up, can be found in the BBIs. In simple scenarios, setting up the
IoT environments, should also be possible for non-expert users. However, usually
this requires domain-specific expertise, as shown in our smart factory example.
After task completion, the process moves to the next task. Parallelism is usually
supported by such BPMS as well.
Once the process has successfully reached its end, the IoT environment is set
up. This process can then be reused in similar scenarios, sometimes only with
minor necessary adaptations. In case of issues in the processes creation or exe-
cution, e.g., due to unforeseen errors, experts need to be available to cope with
occurring difficulties and to fix the problems. All occurred problems should then
be documented inside the BBI’s description so that this knowledge is preserved.
Step 5: IoT Environment Adaptation
It is not unusual that adaptations are necessary over time after an IoT envi-
ronment was set up. For instance, due to changes in the application and, hence,
changes in the requirements, or due to failing devices that need to be replaced.
If adaptations are necessary, the feedback loop in our method allows to re-
turn to the first step, redefining the requirements of the application, adding or
removing requirements. After that, in the second step, the already chosen and
running BBIs need to be considered, i.e., only the new BBs and BBIs should be
chosen from the toolbox.
The process creation step then creates a so-called adaptation plan, which in-
cludes removing unnecessary BBIs and only setting up and integrating the newly
added ones. After execution of the adaptation plan, the IoT environment is set
up again, considering the new requirements as well.
Step 6: IoT Environment Retirement
The final step is the retirement of the IoT environment, which is executed once
an IoT application reaches its lifetime. In this case, the creation of a termination
process is required, reversing the steps of the original process setting up the en-
vironment. Using the process for creation as a foundation eases the creation of
the termination process. After this process was executed, the IoT environment is
retired. Note that the creation and termination processes should be stored since
they can be useful to re-setup IoT applications after some time.
3 Case Study
This section presents a case study that applies our approach to a smart factory
scenario. We worked on this scenario in cooperation with a large German pro-
ducer of transport vehicles on shop floors. Our experiences with this scenario
helped us with the conception and improvement of our toolbox.
96 M. Frigo et al.
Fig. 5. Case study in the smart factory domain
In this scenario, depicted in Fig. 5, indoor localization of self-driving vehicles
should be realized. These vehicles are able to pick up goods in a warehouse and
transport them to a different location. In order to realize this scenario, so it is
robust enough for real-world use, it must be known where the vehicles are at
all times. For this, each vehicle needs a localization tag, which communicates
with multiple stationary tags throughout the factory to determine the current
location. Hence, many assets, sensors, and actuators need to be set up. In the
following, the steps of our method are described specifically for this scenario.
Step 1: Requirement Specification. The requirement specification for this
use case requires many different stakeholders: Shop floor workers that have ex-
perience with the environment the scenario is implemented in, network experts,
setting up wireless connectivity and the edge cloud environment, indoor local-
ization experts, setting up the localization system, electricians making sure that
the power supply for the localization is guaranteed, business experts, bringing
in knowledge about the processes, and so on.
Step 2: Building Block Selection. Once the domain experts have created
the list of requirements, the toolbox makes suggestions regarding the building
blocks that can be applied to this scenario. For example, one requirement is the
need for an indoor localization system. The toolbox can propose using Bluetooth
Low Energy localization through triangulation or more exact systems, using a
real-time localization system, e.g., based on ultra-wideband (UWB). Since the
requirement ”high accuracy” is also given, the recommendation would suggest
the more accurate UWB based system. Furthermore, wireless communication
might be required. Due to the high efficiency requirements, a 5G network might
be suggested instead of WiFi or LTE. The suggestions of the toolbox are an
important part to decrease the time necessary to analyze and select the right
systems for the scenario, which usually can take months.
A Toolbox for the Internet of Things 97
Step 3: Process Creation. The process creation is conducted by an IoT expert
and is, for now, designed manually. In this case, the set of BBs and BBIs above
was given to a specialist and the process was created as shown in Figure 4 only
for the localization system. For such a complex scenario, multiple processes are
required to set up the specific parts (e.g., localization, door control, networks,
etc.). Best practices based on previous scenarios can help in process creation.
Step 4: Process Execution. In order to set up the desired scenario, the pro-
cesses in Figure 4 are executed. By doing so, the corresponding experts install
the hardware, e.g., the localization system, by using the steps given by the pro-
cess. After all processes have been executed, the scenario is set up. In general,
during process execution, there might be dependencies between the processes.
For example, it is necessary to set up the wireless communication first before
the localization system can be set up. This needs to be modeled in the processes.
Step 5: IoT Environment Adaptation. In step 5, the IoT environment could
be adapted by the stakeholders, for example, to extend the area the self-driving
vehicles can move into or adding more vehicles. The overall setup should stay
the same. Only necessary adaptations should be made in the IoT environment.
In this case scenario, an adaptation process includes, e.g., setting up more UWB
senders and receivers and an additional configuration and integration step. The
rest of the setup should stay the same.
Step 6: IoT Environment Retirement. Possible cases when such a scenario
is retired are moving the factory to another location or using other kinds of
devices that fundamentally change the setup. In these cases, a termination pro-
cess reverses all steps of the setup, for example by removing the UWB senders,
powering down the edge cloud, etc.
Prototype. The toolbox is under development as a web-based prototype that
will serve as a proof-of-concept for our approach. This prototype is available on
Github (separated in backend: https://github.com/mtfrigo/IoT-Toolbox-Backend
and frontend: https://github.com/mtfrigo/IoT-Toolbox-Frontend). A screenshot
of the frontend is depicted in Fig. 6.
4 Discussion
The recommendation of Building Blocks is highly dependent on the applications’
requirements. Their discovery is a complex task for the involved stakeholders.
Hence, for the method to work well, it is essential that the stakeholders are
supported in the requirement selection process by experts of different domains.
Missing requirements may lead to a non-satisfactory result.
Our method treats the IoT application as a combination of software and
hardware. Thus, it proposes specific software and hardware components, which
98 M. Frigo et al.
Fig. 6. Toolbox
should be used to implement the application and also provide artifacts for the
implementation. However, there are limitations regarding the artifacts, as they
are particular to the application and not to the domain, causing that the de-
veloper might have to add additional code manually to make the artifacts work
with the respective environment. Hence, programmers are still necessary, even
though their effort is decreased by our recommendations.
Furthermore, there are some limitations, especially regarding process creation
and adaptation. Currently, the processes need to be created by experts in the
corresponding modeling language, e.g., BPMN 2.0. Automated techniques, such
as process mining, for the process creating and adaptation should be added.
As result of the provided case study, we have also identified that given a
complex scenario, the task to gather suitable devices and technologies can take
several years and creating an optimal solution is even harder. This time can be
significantly reduced using the toolbox and choosing the recommended building
blocks. Secondly, such a complex scenario, as the case study, can be hard and
time-consuming to model even for an expert, and the toolbox doesn’t provide
any support for this yet. We will work on this in the future.
5 Related Work
Franco da Silva et al. [16] present Internet of Things Out-of-the-Box, an ap-
proach using the OASIS standard TOSCA [12] to set up IoT environments. In
their work, the goals are similar to ours, setting up IoT environments with as less
effort as possible. Instead of a toolbox, they are using a TOSCA Type Reposi-
tory, however, the steps of defining requirements and selecting the most suitable
TOSCA types are not described. The processes they use for setting up the IoT
A Toolbox for the Internet of Things 99
environments do not support human tasks. Thus, hardware device setup and
other manual steps should already be done in their approach.
Yelamarthi et al. [19] introduce a modular IoT architecture. Their work is
similar to our approach since they use modular building blocks to create an IoT
architecture. Their work shows that IoT architectures work best when they are
built in a modular manner since replacing parts of the architecture becomes
more easy. We built on the idea of such a modular architecture and extend it by
providing a means to set it up through a holistic lifecycle method based on our
toolbox containing a variety of building blocks.
In the past, many IoT environment models have been developed. These mod-
els contain information about the devices of the IoT environment, their proper-
ties (e.g., location or computing resources), the attached sensors and actuators,
and their interconnection. However, these models highly differ in their content,
the formats being used, and the domain they are applied to. Famous exam-
ples for such models are SensorML [13] or IoT-Lite [2]. Some of these models
are developed and maintained by large organizations, others have been created
in research projects and are maintained by a small group of people. Further-
more, some of them are even standardized. These models can be used to provide
a standardized mean to describe the building blocks we aim for. Since many
models are built based on ontologies (e.g., using the Web Ontology Language
OWL [1]), important aspects, such as hierarchies and inheritance, dependencies,
and attributes, are already provided. When defining the specifics of the building
blocks in the future, we will consider these models.
6 Summary and Future Work
In this paper, we present an approach to guide users through the whole process
of setting up IoT environments and corresponding custom IoT applications. We
introduce a holistic method that covers the whole lifecycle of an IoT applica-
tion. First, the requirements of the environment and its applications need to be
defined by domain experts and involved stakeholders. After that, a toolbox is
provided, containing a large variety of building blocks domain experts can se-
lect from. These building blocks cover different aspects of IoT environments. By
plugging them together, IoT environments can be set up easily. The actual set
up is then provided by processes, defining the order of the necessary steps to be
conducted to set up the IoT environment based on the building blocks. After
process execution, the IoT environment is successfully set up and can be adapted
any time through the feedback loop in our method. Once the IoT environment
is retired, the method reaches its end.
Acknowledgments
This work is financed in part by the Coordenação de Aperfeiçoamento de Pessoal
de Nı́vel Superior - Brasil (CAPES) - Finance Code 001 and the research project
IC4F funded by the German Ministry for Economics and Energy (01MA17008G).
100 M. Frigo et al.
References
1. Antoniou, G., van Harmelen, F.: Web Ontology Language: OWL, pp. 67–92.
Springer Berlin Heidelberg (2004)
2. Bermudez-Edo, M., Elsaleh, T., Barnaghi, P., Taylor, K.: IoT-Lite: a lightweight
semantic model for the internet of things and its use with dynamic semantics.
Personal and Ubiquitous Computing 21(3), 475–487 (Jun 2017)
3. Bormann, C., Castellani, A.P., Shelby, Z.: CoAP: An Application Protocol for
Billions of Tiny Internet Nodes. IEEE Internet Computing 16(2), 62–67 (2012)
4. Chinosi, M., Trombetta, A.: BPMN: An introduction to the standard. Computer
Standards & Interfaces 34(1), 124–134 (2012)
5. Chourabi, H., Nam, T., Walker, S., Gil-Garcia, J.R., Mellouli, S., Nahon, K., Pardo,
T.A., Scholl, H.J.: Understanding smart cities: An integrative framework. In: 2012
45th Hawaii International Conference on System Sciences. pp. 2289–2297 (2012)
6. Costa, B., Pires, P., Delicato, F.: Specifying functional requirements and qos
parameters for iot systems. In: Proceedings of the 2017 IEEE 15th Intl Conf
on Dependable, Autonomic and Secure Computing. pp. 407–414 (11 2017).
https://doi.org/10.1109/DASC-PICom-DataCom-CyberSciTec.2017.83
7. Dumas, M., Rosa, M.L., Mendling, J., Reijers, H.A.: Fundamentals of Business
Process Management, Second Edition. Springer (2018)
8. Harper, R.: Inside the Smart Home. Springer Science & Business Media (2006)
9. Hunkeler, U., Truong, H.L., Stanford-Clark, A.: MQTT-S — A publish/subscribe
protocol for Wireless Sensor Networks. In: 2008 3rd Int Conf on Comm Systems
Software and Middleware and Workshops (COMSWARE ’08). pp. 791–798 (2008)
10. Khaled, A.E., Helal, A., Lindquist, W., Lee, C.: Iot-ddl–device description language
for the “t” in iot. IEEE Access 6, 24048–24063 (2018)
11. McEwen, A., Cassimally, H.: Designing the Internet of Things. Wiley Publishing
(2013)
12. OASIS: Topology and Orchestration Specification for Cloud Applications
(TOSCA) Primer Version 1.0 (2013)
13. OGC: Sensor Model Language (SensorML). online,
http://www.opengeospatial.org/standards/sensorml
14. Pohl, K.: Requirements Engineering: Fundamentals, Principles, and Techniques.
Springer Publishing Company, Incorporated, 1st edn. (2010)
15. Shrouf, F., Ordieres, J., Miragliotta, G.: Smart factories in industry 4.0: A review
of the concept and of energy management approached in production based on the
internet of things paradigm. In: 2014 IEEE Int Conf on Industrial Engineering and
Engineering Management. pp. 697–701 (2014)
16. Franco da Silva, A.C., Breitenbücher, U., Hirmer, P., Képes, K., Kopp, O., Ley-
mann, F., Mitschang, B., Steinke, R.: Internet of Things Out of the Box: Using
TOSCA for Automating the Deployment of IoT Environments. In: Proceedings
of the 7th Int Conf on Cloud Computing and Services Science (CLOSER). pp.
358–367. SciTePress Digital Library (2017)
17. Vermesan, O., Friess, P.: Internet of Things: Converging Technologies for Smart
Environments and Integrated Ecosystems. River Publishers (2013)
18. Weerawarana, S., Curbera, F., Leymann, F., Storey, T., Ferguson, D.F.: Web
Services Platform Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-
BPEL, WS-Reliable Messaging and More. Prentice Hall PTR, USA (2005)
19. Yelamarthi, K., Aman, M.S., Abdelgawad, A.: An application-driven modular IoT
architecture. Wireless Communications and Mobile Computing (2017)