Internet of Things 12 (2020) 100321

Contents lists available at ScienceDirect

Internet of Things
journal homepage: www.elsevier.com/locate/iot

Seamless integration of devices in industry 4.0 environments

Daniel Del Gaudio, Pascal Hirmer∗
Institute for Parallel and Distributed Systems, University of Stuttgart, Universitätsstraße 38, Stuttgart, Germany

a r t i c l e i n f o a b s t r a c t

Article history: In Industry 4.0, the connected devices in production communicate with each other via
Received 18 August 2020 standardized Internet protocols to achieve common goals. In this way, they enable the con-
Revised 3 November 2020
struction of complex, self-organizing applications, such as self-propelled transport vehicles
Accepted 3 November 2020
in factory environments. Especially in large factories, newly emerging devices, as well as
Available online 10 November 2020
devices that are no longer available or fail, pose a great challenge. New devices have to be
Keywords: integrated into the application, while failing devices have to be handled. Dealing with this
Industry 4.0 dynamic is a big issue, especially if this happens automatically. In this paper we present
Smart factory a life cycle method for device management in Industry 4.0 environments. This method
Discovery allows for the integration of newly emerging devices into Smart Factory applications and
Device integration also provides ways to deal with failing devices. We evaluate our approach by prototypically
Decentralization implementing our method and the corresponding architecture.
© 2020 Elsevier B.V. All rights reserved.

1. Introduction

Industry 4.0 [1,2] is a new paradigm, in which interconnected devices of the shop floor communicate with each other
via standard internet protocols to achieve mutual goals [3]. Devices on the shop floor include, e.g., production machines,
transport vehicles, or edge cloud devices. Furthermore, human actors are involved using these devices and making the envi-
ronment even more dynamic. In Industry 4.0, traditional applications should become highly automated to increase efficiency.
Especially Industry 4.0 environments highly dynamic, meaning that devices enter and leave regularly. For example, au-
tonomous transport vehicles enter and leave the shop floor, new production machines are bought and old ones are retired.
Furthermore, machine failures are a common issue in shop floor environments. Industry 4.0 applications need to adapt to
these changes automatically to avoid costs produced by a stopped production. This, however, is a great challenge. More
precisely, failing devices could cause errors in the applications, which could disturb the whole application. Even if devices,
e.g. production machines, are shut-down voluntarily and are being replaced, a minimal adaptation effort of the Industry 4.0
applications is desired.
Hence, the goal of this paper is coping with such changes in Industry 4.0 environments autonomously, with as little
human interaction as possible [4]. When a new device enters the environment or a device leaves it, it is costly and time-
consuming to involve a human actor, such as a technician. Especially in large-scale factories, the overhead would be tremen-
dous.
Hence, our goal is that Industry 4.0 applications are capable of including newly emerging devices and coping with leaving
and failing devices automatically with minimal user interaction. To realize this, in this article, we introduce a new life
cycle method for device management in Industry 4.0 environments by providing seamless integration of smart devices. Our

∗
Corresponding author.
E-mail address: pascal.hirmer@ipvs.uni-stuttgart.de (P. Hirmer).

https://doi.org/10.1016/j.iot.2020.100321
2542-6605/© 2020 Elsevier B.V. All rights reserved.
D. Del Gaudio and P. Hirmer Internet of Things 12 (2020) 100321

Fig. 1. Motivational scenario.

approach includes (i) a processing model to describe the behavior of an Industry 4.0 environment, (ii) a structural model
to describe smart factory environment, (iii) the life cycle method to integrate newly emerging devices into smart factory
environments considering their capabilities and the environment’s requirements, and (iv) a system architecture to implement
the method. We evaluated our approach with a prototypical implementation of this architecture.
One important aspect of our work is keeping data processing as decentralized as possible. Especially the number of
central components should be kept as low as possible because the vision of Industry 4.0, or IoT in general, focuses on direct
machine-to-machine communication. Integrating a new device into an environment is difficult to do in a decentralized
manner Since one must have an overview of the whole environment to delegate an appropriate task. Hence, we decided to
handle this aspect centrally. This paper is a revised and extended version of the publication [5].
The remainder of this paper is structured as follows: Section 2 describes an Industry 4.0 scenario, we use to motivate
our contribution. Next, in Section 3 the meta models are described that form the foundation for our paper. Section 4 then
describes our main contribution: Seamless integration of smart devices in Industry 4.0 environments. Section 5 introduces
related work that copes with the integration of devices in running Industry 4.0 environments. Section 6 evaluates our ap-
proach and Section 7 concludes the paper and gives an outlook to future work.

2. Motivation

In this chapter we present a motivational scenario to explain our approach and to serve as a basis for evaluation pur-
poses. This motivating scenario is describing an Industry 4.0 application. In this domain, a large number of devices exist,
such production machines, transport vehicles, automated doors, or stationary edge servers. These devices are highly dy-
namic, i.e. they tend to move through the environment and are susceptible to failures, and furthermore, very heterogeneous.
As mentioned in the introduction, a seamless integration of these devices is desirable to save costs that are necessary to
adapt Industry 4.0 applications manually. The scenario of this article has been extracted from the large research project
Industrial Communication for Factories (IC4F), involving over 15 industrial and academic partners throughout Germany.
The overall goal of this scenario is realizing autonomous transport vehicles, more specifically forklifts, that are able to
transport good from the shelfs of the shop floor to trucks that transport them to distant locations. The challenge of this
scenario is especially that a large amount of vehicles should be realized, which need to communicate with each other to
avoid collisions and, furthermore, human actors are still part of the shop floor, which need to be detected by the vehicles
for their safety.
The introduced scenario is depicted in Fig. 1. In this figure, first, a newly arriving truck registers itself at the nearest
Road Side Unit, which is depicted on the top middle of this figure. In a second step, the Road Side Unit sends the appro-
priate information to the truck, including the responsible autonomous transport vehicles that will deliver the goods. This
information is also sent to the forklifts (step 3). Once the truck is registered, it can be considered as a new actor in the
environment. Forklifts will now start getting goods from the shelfs, while communicating with the other actors (forklifts,
humans, automated doors) to avoid collisions (step 4). Once a forklift newly enters the environment, for example, in case of
different shop floor levels or a newly bought vehicle, it receives information about its task from the Road Side Unit as well
(step 5), i.e., which goods should be transported to which truck. This integration should be possible as seamless as possible
to avoid a costly stop of the whole autonomous application.
The devices in our scenario communicate with each other, depending on geographic proximity, user preferences and use
cases. In addition, Industry 4.0 environments typically use not just one application, but many different ones, sometimes on
the same devices. With the contribution of this paper we aim to solve the following challenges of this scenario: (i) dis-
covery and registration of devices, in this scenario autonomous transport vehicles, (ii) automated deployment of software
and application logic on heterogeneous devices, (iii) data processing on the devices to increase privacy and scalability, and
(iv) seamless device communication according to the specific application.

2
D. Del Gaudio and P. Hirmer Internet of Things 12 (2020) 100321

3. Metamodels

In order that heterogeneous devices are able to communicate with each other, standards are necessary to describe the
communication aspect of applications. In this section, we present two meta-models that lay the foundation for our life cycle
method: (i) a data processing model that defines the business logic of the application. (Section 3.1), and (ii) a structural
description of smart factory environments, including devices, sensors, actuators, and network links (Section 3.2).
These models are necessary to decouple data processing from the devices that actually perform data processing opera-
tions, which leads to a clear separation of concerns. Thus, devices can be added, removed, and exchanged without the need
to adjust the processing model, i.e., the application. Furthermore, an application developer can design an Industry 4.0 appli-
cation via the processing model without further knowledge of the structure of the smart factory environment in which the
application will be executed. Consequently, both models are also fully decoupled and, thus, interchangeable. We describe
these models in detail below.

3.1. Processing model

Communication between devices in smart factory environments can be described by directed graphs according to the
pipes-and-filters design pattern [6], which we refer to as the processing model. In our experience, and as shown in related
work (e.g., [7,8]), the pipes-and-filters pattern is appropriate to describe the behavior of smart factory environments and IoT
environments in general.
Nodes in the processing model (the filters) are called operations and are not associated with specific devices. Instead,
they are associated with a set of requirements, enabling to dynamically choose a correct device for the operator. We define
the processing model as a tupel DF = (O, E, R, req ) including the set of operations O, the set of directed edges E = {e =
(oi , o j )|oi , o j ∈ O}, stating that operation oi must be performed right before operation o j , the set of requirements R, and the
function req : O → P (R ), which links each operation to a set of requirements. An example for a processing model of our
introduced Industry 4.0 scenario in JSON representation looks as follows:

In this example, flow_id defines a unique name for each processing model. Each sub-element of flow represents
an operation. next_oiid indicates which operation must be executed after AnnounceArrival and so forth. The pro-
cessing model is depicted in Fig. 2. The first operation AnnounceArrival is executed by SmartTruck by sending its
position data to SmartGate to announce its arrival. It uses the data to execute OpenGate and tell the next available
AutonomousForklift to unload the Truck.
In the following sections, this processing model is used to define the business logic (more precisely, the data flow) of the
applications. In our scenario, this involves, which goods should be transported from the shelves to the specific truck.

3
D. Del Gaudio and P. Hirmer Internet of Things 12 (2020) 100321

Fig. 2. Smart truck unloading processing model.

Fig. 3. Life cycle method with six steps [5].

3.2. Structural description of smart factory environments

Additionally to the behavior of the applications, we need a model to specify the structure of smart factory environments,
referred to as the environment model. This involves all included devices and connections between them. For this model,
we propose an undirected and weighted graph E = (D, L, C, cap, w ) with a set of devices D = {d1 , . . . , dn }, that exist in the
environment, a set of links L = {l = {di , d j }|di , d j ∈ D}, stating that device di can communicate with device d j and vice versa,
and a set of capabilities C. The function cap : D → P (C ) links each device with a set of capabilities in order to match them
with the requirements of the processing model. The function w :→ Q associates each link with a specific weight. The weight

4
D. Del Gaudio and P. Hirmer Internet of Things 12 (2020) 100321

of a link indicates the costs of delivering a message via the link. The weight of a link can be very dynamic and must be
monitored during runtime.
The environment model needs to be changed by devices being added and removed, which is the main contribution of
this paper. This model in JSON representation is shown in the following example:

This example defines an excerpt of the involved devices of our Industry 4.0 scenario including one of the forklifts as well
as an automated gate. Note that links in the environment model are not necessary in smart factory environments where
every device is able to connect to every other device via a network and link costs are not relevant. Furthermore, especially
in environments with mobile devices, link costs are highly dynamic.

4. Life cycle method for device management

To integrate new devices into an existing Industry 4.0 environments, we created a generic life cycle method, which is
depicted in Fig. 3 [5]. It consists of six steps and describes how one device can be integrated into an existing smart factory
environment to work together with the other devices. It describes the life cycle of a single device in terms of entering,
leaving, and reentering a smart factory environment. We furthermore propose a system architecture that implements the
life cycle. The architecture is depicted in Fig. 4.

5
D. Del Gaudio and P. Hirmer Internet of Things 12 (2020) 100321

Fig. 4. Architecture to apply our life cycle method for device integration.

The cycle is initiated by the runtime agent, which must be deployed on each device, by discovering the runtime manage-
ment, which is our system for device integration (step 1). Next, the device registers itself at the runtime management by
sending a registration message. The runtime management fills the environment model database with meta data of each device
that is registered, meta data of each operation that can potentially be installed and executed in the environment, and which
operation is deployed on which device.
In the next step, the model mapping component of the runtime management determines the appropriate set of operations
to deploy on the new device, as defined in the processing model of the Industry 4.0 application stored inside the processing
model repository (step 3) and created by the application designer using the application modelling tool. The application can be
modeled in different meta-models, depending on the use case, as long as it can be transformed into a processing model
described in Section 3.1. After that, the software deployment and configuration component deploys the associated software
and configures it using the designated processing models and the software from the software repository (step 4). If the
device has been a part of the environment in the past and has stored data in the application data repository, the data is also
transferred back to the device, so that is can resume processing it at the point that it left the environment.
The next step 5 comprises processing the data. That means, the new device is included into the execution of the run-
ning processing models of the Industry 4.0 environment. The runtime management is now only responsible for monitoring
the new device. It is not involved in the machine-to-machine coordination or communication. Data is processed in a de-
centralized manner, which improves the robustness due to no single point of failure. Eventually, in step 6 of the life cycle
method, the device is removed from the environment intentionally or by failure. The details of all steps are described in the
following sections.

4.1. Step 1: server discovery

The first step of our life cycle method is the discovery of the server component. For a device to be integrated in an
existing application, registers itself at the device registration and monitoring component, i.e., the registration server.
We evaluated three possible solutions how a new device can find the registration server in an environment: (i) the
address of the registration component is preconfigured on the device, (ii) the device broadcasts a message into the network

6
D. Del Gaudio and P. Hirmer Internet of Things 12 (2020) 100321

so that the registration server receives and responds to it, or (iii) the server discovery is implemented into the network via
a DHCP or DNS server.
Since a environment specific preconfiguration of devices omits the dynamicity we aim for in our system, we do not
further consider the first solution. For example, because in different environments the addresses of the servers might be
different. Also, the address of the registration server can be changed easier if it is enquired dynamically.
The third solution requires a sophisticated configuration of DNS or DHCP servers, which would be the most elegant
solution, but is also not further regarded because of the implementation overhead. Consequently, we prefer the second
solution that can be implemented by our system itself without any critical dependencies. Within the second solution, the
runtime agent on the devices broadcasts messages into the network and the registration server responds on receiving the
message. The other solutions can be considered as a backup if the network does not allow broadcasting. In our motivation
scenario, the registration server is represented by the Road Side Unit, the trucks and forklifts communicate with once they
enter the environment.

4.2. Step 2: device registration

After a new device received the address of the registration server (step 1), it registers itself by sending a registration
message to the registration server, which includes the necessary metadata. This is an example of a registration message for
our smart truck scenario, in which the truck registers itself on arrival:

The element device includes metadata to specify the new device. name is the self-assigned name for the device, which
does not necessarily have to be unique, but can be used for human users. The sub-element capabilities defines the
capabilities of the device in terms of hardware resources, sensors, actuators, etc. It is used to choose appropriate opera-
tions for the device. address defines the IP address and mac the MAC address. credentialGroup is used to define
the credentials to access the device, for example, via SSH. Furthermore, the element options is used for the registration
process itself, defining important properties, such as ttl, determining the time-to-life for the registration as explained in
Section 4.5. The registration server stores the information about the device based on the registration message. After step 2,
the device is registered and can be further processed.

4.3. Step 3: software determination

After the new device is registered at the registration server, the runtime management must now determine a suitable
set of operations, implementing specific business logic of the Industry 4.0 application (for example, delivering goods from
one location to another), and deploy them on the device. This is done in step 3 of our life cycle method. We determined
three aspects to consider for choosing suitable operations: (i) the capabilities of the device, e.g., sensors, actuators, and
processing power, (ii) the requirements of available operations, e.g., sensors, actuators, and processing power, and (iii) the
specific characteristics of the environment the Industry 4.0 applications are provided in.
The Model Mapping component in our architecture (cf. Fig. 4) is responsible for mapping the capabilities of the devices
onto the most useful set of applications. Therefore, it regards each applications that is available in the software repository.
We define the function f ul f il l s(c, r ) for each requirement r ∈ R and each capability c ∈ C, which evaluates to 1 if capability

7
D. Del Gaudio and P. Hirmer Internet of Things 12 (2020) 100321

c fulfills requirement r. Therefore, we define the function executableBy(o, d ) for each operation o ∈ O and each device d ∈ D
as

1, ∀r ∈ req(o)∃c ∈ cap(d ) :
executableBy(o, d ) = f ul f il l s(c, r ) = 1 (1)
0, else
stating that operation o is executable by device d in terms that for each of requirement d, o offers a fulfilling capability.
For a new device d, we can now seek for the subset of operations
Od = {o ∈ O|executableBy(o, d ) = 1}, (2)
which contains all operations that are executable by d and, thus, fulfills aspects (i) and (ii).
In terms of aspect (iii), many different characteristics must be considered when choosing which operation is the most
”useful” for an environment. We consider an operation as the most useful for an environment if it is one that is not yet
deployed on a device at all, expanding the application’s coverage of the smart factory environment.
Furthermore, for choosing suitable operations to be run of the devices, we evaluated two processing patterns of opera-
tions that need to be handled separately. Those are parallelizable operations and unique operations.
Parallelizable operations can be scaled horizontally by deploying multiple instances of them. Hence, when deploying such
operations, it needs to be considered whether scaling is required by the specific application and also whether the application
supports this. Furthermore, if all available operations are already deployed, we only look for parallelizable operations.
A unique operation must be unique inside the environment, for example, because all data that is processed by the oper-
ation must be consolidated in one instance, e.g., a data base that does not support sharding.
To manage the operations in the environment, we must keep track of operations that are already running, the workload
of each operation, and the utilization of resources of the devices. The set of operations that are executed by a given device
d in the context of any processing model is determined by executedBy(d ).
To realize this, a sophisticated monitoring of the environment is essential and, thus, described in Section 4.5.

4.4. Step 4: software deployment and configuration

In the fourth step of the life cycle method, the previously chosen operations must be deployed on the new device. For
each operation in any processing model in the processing model repository, the associated software components must be
stored in the software repository, as shown in our system architecture (cf. Fig. 4). Software components can be simple scripts
or even complex software applications, typically linked with several helper sripts to install, deinstall, start and stop the
software. Nonetheless, only lightweight software can be deployed onto resource-restricted devices.
The Software Deployment and Configuration component of our architecture starts installing the software and all required
dependencies by connecting to the device and using the software repository. This deployment step can be either imple-
mented manually using, for example, SSH connections, or in a more sophisticated manner. One approach for a more robust
software deployment strategy is offered by the OASIS standard TOSCA [9,10]. An open-source implementation of TOSCA is,
for example, provided by OpenTOSCA [11]. Using a standard-based approaches, like TOSCA, makes the deployment strategy
more future-proof than non-standard-based approaches.
After all applications have been deployed on the new device, the messaging engine, which is responsible for machine-
to-machine communication, must be configured accordingly. The messaging engine needs the operations it can perform, the
section of the processing model it participates in, and the meta information of devices it must interact with.
In addition, messaging engines on other devices that need to interact with the new devices require information about the
newly released device, more specifically what operations it provides and how to interact with it. A simpler, but less scalable
solution would be to inform every device in the environment about the newly released device (e.g., by broadcasting) while
passing the necessary information about the new device. However, since smart factory devices often tend to be limited in
terms of storage capacity and minimizing network traffic, we do not consider this simple solution.
In our approach, to compute all relevant devices that need to communicate with a newly added device d, the runtime
management traverses the processing model and looks for each operation in executedBy(d ). Every device that executes a
predecessor of an operation in executedBy(d ) must be notified about d. Vice versa, d must be notified about each device,
that executes a successor operation of each operation in executedBy(o). By doing so, only the devices need to be notified,
which are required to interact with the newly added device. This reduces the network traffic that would have been produced
by broadcast messages and leads to a more tailored solution.
Note that devices can also communicate using MQTT [12]. Therefore, the software deployment and configuration compo-
nent would deploy MQTT clients and brokers on devices and configure them in the same manner as the messaging engine.

4.5. Step 5: data processing and monitoring

After deployment of the required software components, the newly added device is ready to receive, process, and forward
data as it is described by the application developer. Devices in environment are now also beeing monitored by the system.
Therefore, each runtime agent sends health messages to the server periodically. Since the required frequency of those health

8
D. Del Gaudio and P. Hirmer Internet of Things 12 (2020) 100321

messages depends highly on the use case, i.e., how critical device failures influence the health of the application and how
restricted network capacities are in the environment, it is specified in ttl in options in the registration message as
introduced in Section 4.2. This time period can be individual for each device, since Industry 4.0 environments tend to be
highly heterogeneous. To prevent unnecessary network traffic, choosing the right time period in which devices send their
heartbeat messages must be considered wisely.
When the server has not received any health messages from a device for the specified time period, it assumes that the
device has left the environment accidentally, for example due to an occurring failure. This will be discussed in more depth
in step 6.
Important metrics for device health monitoring are the weight of links (cf. Section 3) and the resource utilization of
devices. Monitoring information can be used to detect bottlenecks and react by deploying additional software on devices in
order to scale the application. For further monitoring mechanisms, we refer to existing work, for example, provided by [13],
that can be implemented in the runtime agent and the device registration and monitoring component.

4.6. Step 6: device removal

A device can be removed from the environment in two ways: either on purpose, for example, when a smart truck leaves
the smart factory, or accidentally, for example, when the network connection is lost or the hardware of the device is dam-
aged.
When a device leaves the environment on purpose, for example when it needs to be exchanged, it should be able to
backup all its data to the application data repository in the runtime management depicted in Fig. 4. When a new device
enters the environment that is able to perform one of the operations the leaving device performed, the runtime management
can initialize the new device with the backup data. By doing so, it can be ensured that no data is left. Of course, this data
needs to be attached with a timespan until it gets stale. Especially streaming data in Industry 4.0 get stale very quickly,
thus, loses its usefulness after a short amount of time.
To prevent loss of data due to device failures, we propose periodical backups into the application data repository. How-
ever, keep in mind that such backups lead to significant overhead in terms of computing and network resources. Therefore,
this compromise must be carefully considered for each application individually.
After the last step of our life cycle method, the device leaves the environment. At any time, the device can re-enter
and the whole method is re-initialized by using associated data in the application data repository. Note that if a device
already contains the required software components when re-entering, the method can be significantly accelerated. Thus, it
also considers previous iterations.

5. Related work

In the earlier work [7] we introduced a lightweight messaging engine to enable communication between devices. This
messaging engine handles information exchange between devices in a dynamic, scalable, and robust manner. Communication
between devices is defined by a processing model. Data is packaged in messages that contain a header and a payload with
the actual data. In this earlier work, the messaging engine lacked mechanisms to cope with the dynamics we are aiming at
in this paper. Therefore, in this paper, we plan to improve this messaging engine to handle newly added or failed devices
and to enable more dynamic device-to-device communication.
Seeger et al. [14] propose an approach for data processing in Industry 4.0 environments in a distributed manner similar
to ours. They model data processing based on choreographies [15]. They also introduce a concept of error detection, where
devices monitor themselves to detect failures. In contrast to our work, Seeger et al. focus their choreographies specifically
on equipment failures and their remedy. However, newly appearing devices are not automatically detected and taken into
account. In addition, we strive for a more generic approach, which is not only specific to choreographies, but to all kinds of
models.
Franco da Silva et al. and Hirmer et al. [8,15,16] propose the new IoT platform MBP as well as means to map opera-
tors onto distributed IoT devices and execute them. However, they do not provide any mechanisms for coping with newly
appearing devices or device failures.
Kodeswaran et al. [17] present Idea - a system for efficient fault management in intelligent IoT environments. The core of
the Idea approach is a centralized system that provides means to monitor sensor failures and, if a failure occurs, a planning
component for maintenance. The work is mainly focused on smart home applications. In contrast to Kodeswaran et al. we
do not only deal with failing devices, but also integrate new devices into the IoT applications. Furthermore, our approach is
more decentralized, while the Idea framework describes a centralized system.
Similar to Kodeswaran et al., Kapitanova et al. [18] present a system to handle non-stopping failures in Smart Home
environments. Failure detection is achieved by machine learning algorithms. In contrast, we strive for a more traditional,
lighter monitoring approach and also provide means to handle newly added devices, not just those that fail.
Fredj et al. [19] propose a semantic-based service discovery using ontologies. A semantic model that can be used to
achieve discovery in this way is IoT-Lite [20]. We use a similar but lighter approach, which introduces a metamodel repre-
senting the IoT devices of an application used for discovery purposes. In this way, discovery can be made more efficiently,
as opposed to using heavyweight ontology models.

9
D. Del Gaudio and P. Hirmer Internet of Things 12 (2020) 100321

CoAP-based discovery mechanisms can make use of the resource discovery (/.well-known/core) interface of a CoAP server,
through which provided services of the server can be retrieved [21,22]. Cirani et al. [23] propose an architecture for peer-
to-peer-based autonomous resource and service discovery in the IoT. The architecture utilizes a central IoT gateway and the
CoAP resource discovery interface. In our paper, we decided to focus on a more generic approach for device discovery and
integration that is not specifically tailored to CoAP.
The W3C Web of Things Working Group1 introduces an architecture and a description language for things. Furthermore,
in the scope of the W3C Web of Things Working Group, Sciullo et al. [24] propose a store to discover and deploy software
for IoT devices. In contrast to the W3C solutions, we aim to minimize communication with devices and central management
components. Software and application logic is deployed once on devices so that devices can interact autonomously and only
communicate directly with each other.
In the Industry 4.0, OPC UA is a widespread standard that can also be used to integrate devices into Industry 4.5 envi-
ronments [25,26]. Nonetheless, OPC UA does not provide a method to integrate new devices from the bottom up, which is
the goal of our approach.
There are also proprietary solutions, e.g. by Google2 or Microsoft.3 We aim to create a solution to deploy software and
processes in IoT environments independent from specific vendors or software distributors. A possible next step would be to
integrate auch proprietary solutions into our concept.
In conclusion, our thorough literature review of related work shows that even though there are already many works
focusing either on device failures or on device discovery and integration, there is yet no combined approach, which provides
the flexibility, dynamics and genericity we aim for in this paper.

6. Prototype and discussion

To evaluate our concept, we implemented a prototype of the runtime management and the runtime agent, running on
the device itself (cf. Fig. 4).
The agent application is usually deployed on resource-limited IoT hardware, so it is implemented in Python to ensure
some degree of lightness. In contrast, the runtime management component, which runs in a scalable cloud environment, is
implemented in Java.
These components communicate via CoAP, a lightweight HTTP-like protocol. We used the Python implementation
CoAPthon [27] for the client and the Java implementation Californium [28] for the server. s database to store information
about registered devices on the server, we use MongoDB4 . All communication payload is serialized in JSON.
We evaluated our prototype at one of Germanys largest producer of forklifts and other transport vehicles. As a platform
for the registration server, we use an Industrial Edge Cloud solution, which runs the Linux distribution Redhat. As devices, a
forklift, an automated door, as well as batteries are used, whereas the batteries are the goods to be transported by the fork-
lift. The forklift and door are equipped with an device that provides computing power, storage, and network communication
through WiFi or LTE. Route computing of the forklifts are done on the attached device itself, communication between the
forklifts is done through LTE.
The runtime management component is set up in the Industial Edge Cloud. In order to set this component, a few simple
steps need to be conducted, thus, making it easy to set it up in different scenarios by different stakeholders. First the
runtime management needs to be deployed on the Industial Edge Cloud, manually or over-the-air. Second, the runtime agent
must be installed on each device that is involved in the scenario, i.e., the attached devices of forklift and door. Furthermore,
each device needs a minor preconfiguration to be able to share its capabilities with the runtime management. For many
devices, we recommend automating this installation and configuration step, using for example, TOSCA or other well-known
deployment tools, such as Ansible.5
As mentioned before, all additional software necessary for a specific scenario should be stored in the software repository
and gets installed automatically by the runtime management according to the processing model for the scenario and the
devices capabilities in step 4 of our life cycle method.
The prototype shows that our concept can handle the challenges listed in Section 2. Devices are automatically registered
after they entered a new environment and connect to the network (i). Software is automatically deployed on each device
according to the processing model (ii). Data is (pre-)processed on the devices by the deployed software and is sent to the
other devices according to the processing and environment models ((iii) and (iv)).
Modelling distributed applications with the processing model in Section 3.1 and the smart factory environment with
the environment model in Section 3.2 decouples application development from executing environments and, thus, creates
dynamic IoT environments with interchangeable devices. Data processing can be scaled horizontally by adding more de-
vices to the environment, since parallelizable operations are deployed automatically and load is balanced amongst them.
Nonetheless, we did not consider security threats, which will be part of our future work [29,30].

1
https://www.w3.org/WoT/.
2
https://cloud.google.com/solutions/iot.
3
https://azure.microsoft.com/overview/iot/.
4
https://www.mongodb.com.
5
https://www.ansible.com/.

10
D. Del Gaudio and P. Hirmer Internet of Things 12 (2020) 100321

7. Conclusion

In this article we present an approach to seamless device integration in Industry 4.0 environments. The live cycle method
allows easy integration of new devices into Industry 4.0 applications without the need for time-consuming manual steps. In
addition, we introduce concepts that allow to deal with failed devices or voluntarily leaving ones. Our life cycle approach
is based on meta-models that describe data processing and the infrastructure landscape. Based on these models, we can
find new devices, register them, install the necessary software and integrate them for data processing into Industry 4.0
applications. Finally, the devices can be retired either voluntarily or in case of a failure. Even when they fail, we can support
Industry 4.0 applications by providing a reliable way of process data so that applications do not fail when individual devices
do.
We have implemented a prototype in a real scenario and provided a proof of concept. In the future, we aim to apply this
prototype to more complex scenarios to further demonstrate the strength of our approach.

Declaration of Competing Interest

The authors declare that they have no known competing financial interests or personal relationships that could have
appeared to influence the work reported in this paper.

References

[1] K. Zhou, T. Liu, L. Zhou, Industry 4.0: towards future industrial opportunities and challenges, in: 2015 12th International Conference on Fuzzy Systems
and Knowledge Discovery (FSKD), 2015, pp. 2147–2152.
[2] M. Ghobakhloo, Industry 4.0, digitization, and opportunities for sustainability, Journal of Cleaner Production 252 (2020) 119869, doi:10.1016/j.jclepro.
2019.119869. http://www.sciencedirect.com/science/article/pii/S0959652619347390
[3] O. Vermesan, P. Friess, Internet of Things: Converging Technologies for Smart Environments and Integrated Ecosystems, River publishers, 2013.
[4] D. Del Gaudio, P. Hirmer, Fulfilling the IoT vision: are we there yet?, in: Proceedings of the 5th International Conference on Internet of Things, Big
Data and Security - Volume 1: IoTBDS„ INSTICC, SciTePress, 2020, pp. 367–374. 10.5220/0 0 09439603670374.
[5] D. Del Gaudio, M. Reichel, P. Hirmer, A life cycle method for device management in dynamic IoT environments, in: Proceedings of the 5th International
Conference on Internet of Things, Big Data and Security - Volume 1: IoTBDS„ INSTICC, SciTePress, 2020, pp. 46–56. 10.5220/0 0 0934090 0460 056.
[6] R. Meunier, The pipes and filters architecture, in: Pattern Languages of Program Design, ACM Press/Addison-Wesley Publishing Co., 1995, pp. 427–440.
[7] D. Del Gaudio, P. Hirmer, A Lightweight Messaging Engine for Decentralized Data Processing in the Internet of Things, SICS Software-Intensive Cyber-
Physical Systems, 2019, doi:10.10 07/s0 0450- 019- 00410- z.
[8] A.C. Franco da Silva, P. Hirmer, B. Mitschang, Model-based operator placement for data processing in IoT environments, in: 2019 IEEE International
Conference on Smart Computing (SMARTCOMP), IEEE, 2019, pp. 439–443.
[9] OASIS, Topology and orchestration specification for cloud applications, 2013a, (????a). http://docs.oasis-open.org/tosca/TOSCA/v1.0/os/TOSCA- v1.0- os.
pdf.
[10] OASIS, TOSCA primer, 2013b, (Onlineb). http://docs.oasis-open.org/tosca/tosca-primer/v1.0/cnd01/tosca-primer-v1.0-cnd01.pdf.
[11] T. Binz, U. Breitenbücher, O. Kopp, F. Leymann, Tosca: portable automated deployment and management of cloud applications, in: Advanced Web
Services, Springer, 2014, pp. 527–549.
[12] U. Hunkeler, H.L. Truong, A. Stanford-Clark, Mqtt-a publish/subscribe protocol for wireless sensor networks, in: 2008 3rd International Conference on
Communication Systems Software and Middleware and Workshops (COMSWARE’08), IEEE, 2008, pp. 791–798.
[13] M.T. Lazarescu, Design of a WSN platform for long-term environmental monitoring for IoT applications, IEEE J. Emerg. Sel. Top. Circt. Syst. 3 (1) (2013)
45–54, doi:10.1109/JETCAS.2013.2243032.
[14] J. Seeger, A.D. Rohit, V. Sarafov, A. Brring, Dynamic IoT choreographies, IEEE Pervasive Comput. 18 (2019) 19–27, doi:10.1109/MPRV.2019.2907003.
[15] P. Hirmer, U. Breitenbücher, A.C.F.d. Silva, K. Képes, B. Mitschang, M. Wieland, Automating the provisioning and configuration of devices in the Internet
of Things, Complex Syst. Inform. Model. Q. 9 (2016) 28–43, doi:10.7250/csimq.2016-9.02.
[16] A.C. Franco da Silva, P. Hirmer, J. Schneider, S. Ulusal, M. Tavares Frigo, Mbp: not just an IoT platform, in: Proceedings of the 18th Annual IEEE Intl.
Conference on Pervasive Computing and Communications, 2020, pp. 1–3.
[17] P.A. Kodeswaran, R. Kokku, S. Sayandeep, M. Srivatsa, Idea: a system for efficient failure management in smart IoT environments, in: Proceedings of
the 14th Annual International Conference on Mobile Systems, Applications, and Services, in: MobiSys ’16, ACM, New York, NY, USA, 2016, pp. 43–56,
doi:10.1145/2906388.2906406.
[18] K. Kapitanova, E. Hoque, J.A. Stankovic, K. Whitehouse, S.H. Son, Being SMART about failures: assessing repairs in SMART homes, in: Proceedings of
the 2012 ACM Conference on Ubiquitous Computing, in: UbiComp ’12, ACM, New York, NY, USA, 2012, pp. 51–60, doi:10.1145/2370216.2370225.
[19] S.B. Fredj, M. Boussard, D. Kofman, L. Noirie, Efficient semantic-based IoT service discovery mechanism for dynamic environments, in: 2014 IEEE 25th
Annual International Symposium on Personal, Indoor, and Mobile Radio Communication (PIMRC), IEEE, 2014, pp. 2088–2092.
[20] M. Bermudez-Edo, T. Elsaleh, P. Barnaghi, K. Taylor, IoT-lite: a lightweight semantic model for the internet of things, in: 2016 Intl IEEE Conferences
on Ubiquitous Intelligence & Computing, Advanced and Trusted Computing, Scalable Computing and Communications, Cloud and Big Data Computing,
Internet of People, and Smart World Congress (UIC/ATC/ScalCom/CBDCom/IoP/SmartWorld), IEEE, 2016, pp. 90–97.
[21] Z. Shelby, K. Hartke, C. Bormann, The Constrained Application Protocol (CoAP), Technical Report, Universitaet Bremen TZI, 2014.
[22] Z. Shelby, C. Bormann, S. Krco, CoRE resource directory, 2013.
[23] S. Cirani, L. Davoli, G. Ferrari, R. Léone, P. Medagliani, M. Picone, L. Veltri, A scalable and self-configuring architecture for service discovery in the
internet of things, IEEE Internet Things J. 1 (5) (2014) 508–521.
[24] L. Sciullo, C. Aguzzi, M. Di Felice, T.S. Cinotti, et al., WoT store: enabling things and applications discovery for the W3C web of things, in: 2019 16th
IEEE Annual Consumer Communications and Networking Conference, CCNC 2019, 2019, doi:10.1109/CCNC.2019.8651786.
[25] S.-H. Leitner, W. Mahnke, OPC UAService-oriented Architecture for Industrial Applications, Softwaretechnik-Trends 26 (4) (2006) 1–6. http://www2.
cs.uni- paderborn.de/cs/ag- engels/GI/ORA2006- Papers/leitner- final.pdf%5Cnhttp://dblp.uni- trier.de/db/journals/stt/stt26.html-LeitnerM06%5Cnhttp:
//www2.cs.uni- paderborn.de/cs/ag- engels/GI/ORA2006- Papers/leitner- final.pdf
[26] T. Hadlich, Providing device integration with OPC UA, in: 2006 IEEE International Conference on Industrial Informatics, INDIN’06, 2006, pp. 263–268,
doi:10.1109/INDIN.2006.275791.
[27] G. Tanganelli, C. Vallati, E. Mingozzi, CoAPthon: easy development of coAP-based IoTapplications with python, in: 2015 IEEE 2nd World Forum on
Internet of Things (WF-IoT), IEEE, 2015, pp. 63–68.
[28] M. Kovatsch, M. Lanter, Z. Shelby, Californium: scalable cloud services for the internet of things with coap, in: 2014 International Conference on the
Internet of Things (IOT), IEEE, 2014, pp. 1–6.

11
D. Del Gaudio and P. Hirmer Internet of Things 12 (2020) 100321

[29] A.S. Sohal, R. Sandhu, S.K. Sood, V. Chang, et al., A cybersecurity framework to identify malicious edge device in fog computing and cloud-of-things
environments, Comput. Secur. 74 (2018) 340–354, doi:10.1016/j.cose.2017.08.016.
[30] C.-T. Kuo, P.-W. Chi, V. Chang, C.-L. Lei, Sfaas: Keeping an eye on iot fusion environment with security fusion as a service, Future Generation Computer
Systems 86 (2018) 1424–1436, doi:10.1016/j.future.2017.12.069. http://www.sciencedirect.com/science/article/pii/S0167739X17324834

12