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 environments can be cumbersome, since this oftentimes requires many complex manual steps, such as setting up devices, con guring 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 approach 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.
In the Internet of Things (IoT), interconnected devices communicate through
standardized internet protocols to achieve common goals [
However, since devices in the IoT are very heterogeneous, building IoT
applications can be very cumbersome [
Furthermore, in the IoT, not only the devices are very heterogeneous but
also the communication protocols, e.g., CoAP [
To cope with this issue, in this paper, we introduce a new approach for easing 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 components, 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 o er a uniform way of describing the software and hardware 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 di erent steps that can be conducted either
in parallel or sequentially in case of any dependencies. For example, before
connecting 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) [
The remainder of this paper is structured as follows: in Section 2, we introduce 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, nally, Section 6 summarizes our paper and gives an outlook on future work. 2
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 prede ned set of building blocks that can be combined to set up Domain experts
Requirement Specification
IoT Environment Retirement 1 6
Building
Block
Selection Feedback
IoT Environment Adaptation 2 5
Process Creation Process Execution 3 4 Method step the desired IoT application. Even though this method is generic in terms of the kinds of applications that should be set up, applying it speci cally 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 e ort and decreased necessary technical knowledge since technical details are abstracted through the building blocks.
In the rst step of this method, domain experts and involved stakeholders discuss the characteristics of their IoT application and de ne a set of requirements for the application. The set of requirements is de ned as R 6= ;, whereas each r 2 R describes a speci c 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, de ning 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 application 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 nal 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
Our toolbox o ers a set of building blocks (BB) that are divided into di erent categories. These categories include, for example, physical devices, network protocols, or software applications. In order to ensure understanding and applicability of our approach, we introduce a formalization of the toolbox. A BB is formalized as follows:
BB: Building Block
BB:
Building Block Name Type Description Dependencies Icon Capabilities
Name: Publish
Subscribe
Type: Communication
Description: Loosely coupled communication Dependencies: None Icon: Capabilities: Loose Coupling { N ame 6= ;: unique name of the building block. { T ype 6= ; : the type t 2 T , where T is the set of available bb types. { Description: optional description. { Dependencies: set of bb 2 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 requirements to the BBs of the toolbox. De nition 2 (Building Block Implementation). Let bbi 2 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: { 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 implementation. { Dependencies: list of bbi 2 BBI related to this building block implementation.
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 di erent 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 di erent BBIs.
For example, some BBIs might require the installation of certain programming
languages (Java, Python) or a speci c operating system. In addition, each BBI
requires a de nition of its interfaces to enable an easy orchestration via business
processes. In case of software artifacts, these interface descriptions should be
de ned based on standards, such as WSDL [
For our BB example in Figure 2, implementations include MQTT brokers, such as Mosquitto or RabbitMQ. Once domain experts decide to use the publishsubscribe paradigm, they will nd the according building block in the toolbox and will be able to select one of the corresponding implementations.
The BBs and BBIs can be de ned 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 de ned, representing all possible kinds of connections. This Connection BB is then derived to the \Wireless Connection" building block, which represents all connection BBs that are wireless. The Wireless Connection BB has three di erent implementations, which can again be derived by di erent 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 lled with BBs and BBIs, it can serve as a foundation for our method to set up IoT environments, which is described in the following.
In the rst step of our method, IoT application developers, i.e., the domain experts and their stakeholders, need to de ne 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 [
The toolbox provides a list of prede ned requirements for the most common IoT application scenarios where the stakeholders can nd the requirements that t their needs. The list should be kept up-to-date to the current state-of-the-art of the IoT eld. These requirements need to consider di erent aspects, such as network capabilities, used communication paradigms, costs, e ciency, security, privacy, available computing resources, and so on. De ning such requirements might involve many di erent stakeholders and even a requirements engineer, i.e., a person who understands the domain of the desirable application and also possesses 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 documented to provide an overview of possible relations, assisting in requirements engineering for future applications.
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 nal selection is conducted by the involved stakeholders. We de ne the mapping that assigns a requirement to one or more building blocks as reqM apping : R ! BB.
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 oor. The goal of this application is that these vehicles dynamically determine the best routes and also consider other vehicles as well as people and utilities of the shop oor. 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 oor through a wireless network. Setting up such a complex scenario, requires the expertise of many di erent 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 oor. 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 recommended by the toolbox:
If we now consider the non-functional requirements as well, for example highe ciency, robustness, and accuracy, the toolbox would lter the resulting BB list accordingly. For example, localization using BLE and triangulation has issues regarding accuracy and also e ciency. Hence, the BB "BLE localization" would not be recommended by the toolbox, but rather a solution based on UWB (ultrawideband). 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 oor.
Once the BBs are selected, a list of available BBIs is generated by the toolbox. The selection of the BBIs is then conducted by the stakeholders based on available expertise or costs.
The third step deals with the business process modeling [
Install stationary UWB receivers Install mobile UWB senders Install position calculation on edge cloud
Configure channel Configure channel
Measure receiver connection
Validate positioning of receivers
Integrate and test the system perts and involved stakeholders through the process of setting up their IoT environment. 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 cumbersome and time-consuming task.
Hence, setting up a given BBI in most of the cases will need common steps to be taken even in di erent 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 oor, the corresponding steps that need to be undertaken are mostly the same for di erent companies with only minor di erences based on the layout of the shop oor.
An example of a process is provided in Figure 4 in BPMN 2.0 syntax. This process shows a simpli ed version of the di erent steps to set up an indoor localization system using UWB technology, as discussed above. In parallel, the receiver and sender hardware needs to be installed on the shop oor. Furthermore, software for calculation of the position needs to be installed in an edge cloud environment, which will later communicate with the receivers. After conguration and measurements of the hardware, the system can be integrated, tested, and can then go into production.
Note that the con guration of di erent BBIs can have a di erent 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.
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 noti cation about the tasks they need to conduct, for example, plugging in sensors, con guring a WiFi connection, or installing software on IoT devices. Documentation of the di erent 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-speci c 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 execution, e.g., due to unforeseen errors, experts need to be available to cope with occurring di culties and to x the problems. All occurred problems should then be documented inside the BBI's description so that this knowledge is preserved.
It is not unusual that adaptations are necessary over time after an IoT environment 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 return to the rst step, rede ning 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 includes 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.
The nal 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 environment. 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
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 producer of transport vehicles on shop oors. Our experiences with this scenario helped us with the conception and improvement of our toolbox.
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 di erent 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 speci cally for this scenario. Step 1: Requirement Speci cation. The requirement speci cation for this use case requires many di erent stakeholders: Shop oor workers that have experience with the environment the scenario is implemented in, network experts, setting up wireless connectivity and the edge cloud environment, indoor localization 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 e ciency 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. 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 speci c 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 processes 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 process. 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 rst before the localization system can be set up. This needs to be modeled in the processes.
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 con guration and integration step. The rest of the setup should stay the same.
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 process 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
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 di erent 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 speci c software and hardware components, which 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 developer might have to add additional code manually to make the artifacts work with the respective environment. Hence, programmers are still necessary, even though their e ort 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 identi ed 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 signi cantly 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
Franco da Silva et al. [
Yelamarthi et al. [
In the past, many IoT environment models have been developed. These
models contain information about the devices of the IoT environment, their
properties (e.g., location or computing resources), the attached sensors and actuators,
and their interconnection. However, these models highly di er in their content,
the formats being used, and the domain they are applied to. Famous
examples for such models are SensorML [
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 application. First, the requirements of the environment and its applications need to be de ned by domain experts and involved stakeholders. After that, a toolbox is provided, containing a large variety of building blocks domain experts can select from. These building blocks cover di erent aspects of IoT environments. By plugging them together, IoT environments can be set up easily. The actual set up is then provided by processes, de ning 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.
This work is nanced in part by the Coordenac~ao de Aperfeicoamento 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).