Event-driven Architecture for Sensor Data Integration for Logistics Services

Jens Leveling¹, Luise Weickhmann¹, Christian Nissen¹, Christopher Kirsch²

¹Software & Information Engineering, Fraunhofer Institute for Material Flow and Logistics, Dortmund, Germany
² BEUMER Group GmbH & Co. KG, Beckum, Germany
(jens.leveling@iml.fraunhofer.de, luise.weickhmann@iml.fraunhofer.de, christian.nissen@iml.fraunhofer.de,
christopher.kirsch@beumergroup.com)

Abstract – Sensor data offers a massive potential for the communication approaches as shown in [16, 17], but also
logistics sector. To achieve an optimal, effective and for an architecture that is able to provide well-formed data
productive supply chain, operators and manufacturers are for other IT-systems and cloud environments.
challenged to use this information and extract value from it. However, a suitable architecture to integrate data
They have to comply with the main task of efficiently
managing logistics processes as well as fulfilling
from different sensor devices is still missing. Therefore, a
requirements and guidelines. To do so, it is necessary to simple way to integrate, pre-process and provide data
monitor all processes and understand exceptions and from sensor and other Internet of Things devices is
anomalies. Sensor and Internet of Things (IoT) data is the required. This paper introduces a software architecture
key for these tasks. Currently, the data is available but not that contributes to these challenges. The focus lays on
(sufficiently) used. The heterogeneity of sensor data is a receiving data from several devices and transforming it
major obstacle for the usage. Therefore, we present an into well-formed datasets for further usage, e.g. data
architecture, which addresses these challenges by integrating analytics. Figure 1 shows the general structure of our
heterogenic data in well-formed data sets. architecture. The main component is the IoT Gateway,
which communicates with sensor devices as well as with
Keywords – Internet of Things, Sensor Devices, Sensor
PLCs and more complex modules. It is also providing a
Data, Data Integration, Data Fusion, Smart Services, Data-
Driven Logistics, Logistics. System View, which displays the received data. The
gateway communicates with a Cloud environment, where
data is stored and processed. The cloud itself is providing
I. INTRODUCTION a Process View, which displays data like the system view,
but more detailed and with insight in context information.
Nowadays, logistics operators have to cover a lot of
complex tasks and challenges. Therefore, they have a
need for a simple and efficient management of their
logistics processes. Furthermore, it is mandatory to fulfil
and implement new requirements and guidelines. The
third challenge is to detect and understand process
exceptions and anomalies, which occur from time to time.
All these tasks lead to new requirements for the
manufacture of logistics systems. To comply these,
operators and manufacturers need more information and a
better understanding of their systems in production.
The background is that programmable logic
controllers (PLCs) consume sensor data, but it is neither
forwarded nor stored. Hence, a further usage becomes
possible as sensor devices grow more and more
intelligent. [2] describes this development in three
aspects. The sensor CPU has more processing power, the
sensor functionality is parametrized by software and the
device has ISO/OSI level 7 interfaces, like HTTP or Fig. 1: High-level view of sensor data integration
MQTT. Besides this, as outlined by [3] smart sensor
devices become more and more important. This paper’s structure is as follows: Section II
Today, based on current developments as described describes the status quo of sensor and Internet of Things
by Industry 4.0 and Digitization [3] all this data becomes devices in more detail and derives requirements for an
available and can be a basis for new services. As stated in architecture. Section III refers to existing approaches and
[15], companies often offer these services on top of their related work in this field. Section IV outlines the core
physical products to work in their own ecosystem. concepts based on the requirements. Section V presents
Next to the more and more intelligent devices, the the architecture. It illustrates the concept of the
number of sensor and IoT devices in modern warehouses architecture and states which components are involved,
is growing. Concerning this, there is a need for new

978-1-5386-6786-6/18/$31.00 ©2018 IEEE 536

 Proceedings of the 2018 IEEE IEEM
what tasks they fulfil, and how they interact with each
other. Finally, section VI concludes the paper and gives
an outlook on further research fields and improvements,
which are dependent on how the technology evolves.
II. REQUIREMENTS
A. Sensor and Internet of Things devices
Today, logistics and production systems are using
numerous different sensor- and Internet of Things devices
from various vendors. Unfortunately, these vendors are
using their own software interfaces and protocols. Open
or sector wide standards are uncommon, today. This
approach derives from the past: Devices only had to be
connected to a PLC to handle upcoming tasks without any
further connectivity, especially not to cloud environments.
Although technology developed a lot since then, the
vendors themselves still do not address this. However, the
devices are becoming more and more software
configurable and solutions like app stores for devices are
developed [13, 14].
Besides this, many different devices are available and
used. For example, there are lots of diverse sensor types.
In summary, all these aspects lead to the four core aspects
of device heterogeneousness as shown by figure 2.
Fig. 2: Heterogeneousness of sensors is described by four aspects
B. Challenges
The former described aspects also lead to four
challenges, which are influencing an architecture for data
integration and connectivity of heterogeneous devices as
shown in figure 3.
Fig. 3: Sensor data integration requirements/challenges
Next to the various data structures and interface
technologies, in many cases, a data context is missing nor
is a semantic description available. It must also be
537
considered that sensor devices are implemented in
distributed organizations and the number and variety of
devices is high. Additionally, sensors are usually sending
data in high frequencies up to 1000 events per seconds.
Generally, not all of these events are of interest for an
integration into a cloud environment. Nevertheless, the
frequency is one of the major challenges when a data
integration architecture starts receiving messages from the
devices just as they are created and send. We think it is
important and fruitful for any further usage of data to set
the context and origin of the datasets as early as possible.
In many cases and industrial projects, this was and is the
key concept for an easier understanding and analytics of
data within services.
Additionally, to the challenges of the devices, the
data will be used by IT-services. These services have to
be adjusted, exchanged or reconfigured to cover new or
changing requirements. Moreover, different devices have
to be connected and reconnected. Both aspects lead to the
need for an architecture that is flexible and easy to adjust
for new services and devices.
C. Requirements
The former outlined challenges lead to these major
requirements:
1. Add context and origin of data to improve the
data interpretability for further usage
2. Aggregate and filter data to tackle the high
frequency and to reduce the amount of data
3. Transform data into open protocols and formats
to ease the usage
4. Transform data into a well formed semantic
based data model
5. The services require a loosely coupled approach
to adjust the architecture in a flexible manner
III. RELATED WORK
There are several approaches to address the problem
of unifying software architectures and data models for
IoT. With IoT-A [6] a reference model was introduced,
that includes a definition of uniform terms to establish a
common understanding of the attending components and
builds the foundation for concrete IoT architectures.
The iCore framework [7] and the SENSEI
architecture [8] deal with the integration of data out of
different heterogeneous sources. They obtain a high usage
of the data by transferring data into a uniform data model.
The research programme FI-PPP also addressed this
topic and thereby developed FIWARE [12]. It is an open-
source platform, which provides a uniform interface for
IoT applications to enrich IoT data with context and
connect it with big data services.
They expose the challenges, which are accompanied
to building up an architecture for IoT in general. Since
there are several application domains with various
requirements for IoT the complexity of that task increases
 Proceedings of the 2018 IEEE IEEM
massively. Therefore, many specific application-oriented
and in many cases incompatible solutions were
developed. This leads to the fragmented Intranet of
Things mentioned in [9] rather than a feasible Internet of
Things. In order to counter these trends Krco and Pokric
reviewed existing initiatives for building up a common
base for IoT architectures [4]. They advocate further work
in refining IoT-A ARM, which was among others done by
developing the FIESTA-IoT platform, which improves the
semantic interoperability of different IoT architectures
[5]. In [11] an IoT-A-based architecture is connected to
the FIWARE platform to meet the requirements of both
sides – the operator and manufacturer.
Additionally there are pilot projects to evolve
different solutions and archive best-practice experience in
the different fields.
Particularly, we want to mention the EU project
TransformingTransport [10], which is in the Horizon
2020 programme and addresses the opportunities and
progress of the transport sector by using IoT and Big
Data.
A second promising initiative is the Industrial Data
Space (IDS) - initiated by Fraunhofer. Its main goal is to
develop a platform for a secure, semantically well-formed
and easy exchange of business data. FIWARE provides
the digital platform for the data space, on which the
specific services are build.
All the outlined projects and frameworks have one
thing in common: they focus more or less on specific use-
cases. However, data transformation and covering of
device specifics are only in focus of the IDS and the
FIWARE approach. Additionally, the IDS also considers
business data, e.g. from ERP systems.
IV. CORE CONCEPTS
The essential goal of the architecture is the assurance
of a flexible exchange of services. We reached this
functionality by establishing application containers.
Applications will run on a runtime inside a container and
thereby be independent of the device where they are
deployed. Furthermore, all necessary libraries are added
to the container and not to the underlying infrastructure.
Finally, based on the application container concept all
services are running isolated. Figure 4 shows the basic
components of the Integration Stack running in
application containers. They all communicate by a
Publish/Subscribe mechanism and hence event-driven and
not directly, all communication goes over a message bus.
The next subchapter outlines the communication approach
in more detail.
Both concept combined lead to a flexible architecture.
We can replace, stop and add services individually
without an effect on the others. This supports a loosely
coupling of services, so that only the interfaces and data
models besides the application container implementation
are fixed.
The core concepts we are following to design this
architecture are: Loosely coupling [18] to have a flexible
538
architecture and no service orchestration but a service
choreography based on Publish/Subscribe communication
[18]. Furthermore, we rely on the Micro Service concept
(one service - one function), and finally, we are using
exclusively opens standards, like JSON and HTTP, to
enable an easy usage and adoption of our results in
various logistics applications. In summary, our
architecture is following the design principles of an
Event-Driven Architecture as outlined here [19].
V. EVENT-DRIVEN ARCHITECTURE
This section describes our Event-Driven Architecture.
This paper uses the definition of Architecture by IEEE
Std. 1471-2000 [20], describing the architecture, its
components, their relationships to each other and
information exchange.
A. Basic Architecture Components
Fig. 4: Basic components of the Integration Stack
Figure 4 shows the six different types of services we
designed. First, for every device that is connected we
implemented a Device Adapter, which has exactly one
task: Collect all device specifications, like data models
and protocols, transform the data into well-formed JSON-
documents and send them via our communication concept
as outlined in the next subchapter. One of the basic
requirements, setting data into a context, is covered here.
With this approach, we see our concept, setting data into a
context as early as possible, implemented.
The Device Adapter is also responsible for adding
context and origin information to a new dataset. We have
seen in industrial projects with sensor and system vendors
that this information is mandatory for further usage, e.g.
processing or system optimization and maintenance cases.
The context involves information about a process or a
rule, why a sensor has been triggered to send an event.
Simply speaking, we are adding information about a
reason, why a sensor has created an event. As an example,
this can be a status information, like a temperature value,
which has to be detected every minute. In addition,
information about the adherence of boundary values is
important here. Furthermore, origin information as
timestamp, position and id of the device, to know which
 Proceedings of the 2018 IEEE IEEM
device has created this message, completes the set of
context data. In summary, origin is the sender of a
message and context is why this message is send. Both
information is present in most cases, when you connect a
device. The presented architecture does not define the
message structure. We are leaving this open. From our
point of view, this is in many cases use-case specific.
On the other side, the Cloud Adapter covers all
specifics that are required to establish a connection to a
target IT-system or cloud environment. Next to the two
already explained services, we have two more services
that have core functions. The Data Cache is used by all
services to store data that cannot be send by MQTT. In
our projects, that is data of 1MB or more. The Data
Cache has a RESTful interface for providing the stored
data. Each dataset is identified by a unique id. Now a
service adds data to the Data Cache and receives an
HTTP link, including the id. This link is part of a MQTT
message. A client can use that link to get the data.
The Management Service contains functionality to
administrate the other services, e.g. for starting and
stopping other services from outside. The functions are
provided by RESTful interfaces. Elemental is, that all
other services have to be registered at the Management
Service. It assigns a service a unique id, which is
mandatory for our communication model.
Finally, all application specific functionality is placed
into a Core Service. Here, as to the other services, we
follow the Micro Service approach, one service one
function.
B. Communications
Elemental for our Event-Driven Architecture is the
communication approach. Therefore, we use a
Publish/Subscribe concept. The background here is that
many sensor and IoT devices are sending data frequently
or on demand depending on the configuration. A
request/response based approach is uncommon. In our
approach, the Device Adapter is responsible for handling
a message from a device. It is transforming the received
data into a well-formed data format. Here we use JSON.
This message is now published to a message topic with a
specific structure /device/[originDeviceId]/event to an
Event Broker.
We have two different types of topics in our
architecture. A device topic with the former shown
structure and a core topic for the results of a Core Service
/service/[originServiceId]/result.
The communication comes with two different types,
depending on the size of the payload. In our projects we
have seen, that events with a payload of 1MB or more
might lead to issues in message fragmenting on the
underlying network communication stack. The result is
that a client might not receive the message correctly, as
some fragments do not arrive in the correct order. Our
solution is here, to add this payload to the Data Cache, as
outlined above. For example, the Device Adapter sends an
event message with a 2MB picture. First, it adds this
539
picture to the Data Cache and receives an HTTP link to
the picture in return. Then it is sending not the picture but
the HTTP link within the event message to the topic as
described before in this chapter. If the payload is smaller
than 1MB it is not stored in the Data Cache and bundled
within the event message. A Core Service is subscribing
to a device topic.
All Device Adapters and Core Services are using this
communication model. If possible, – depending on the
cloud side – we prefer to use exactly the same procedure
for the communication with a cloud environment. In this
case, the Data Cache interfaces are capsulated by a Cloud
Adapter. This makes them accessible only for a cloud
environment. Here, the topic for cloud events follows the
/system/[originSystemId]/[originServiceId]/result pattern.
This topic will also be used, if events are directly
forwarded from a device to the cloud. In this case, the
originServiceId is the id of the Device Adapter.
C. Technologies & Implementation
We realised the communication by using the JSON
format to describe data models and MQTT as
transmission protocol. For addressing the REST interface,
the payload of an MQTT message is defined as HTTP
link of the Data Cache service including a unique id
identifying the payload content. We used the eclipse
MQTT Broker mosquito as the event broker in our
implementation. A more detail analysis of IoT protocols,
including MQTT and HTTP, describes [23].
The application container technologies are Docker or
Snap. Today Docker is widely supported (e.g. by build
tools, frameworks, operation systems and cloud
environments). So far, this does not count for Snap, which
is offering a good solution for providing updates and new
versions in a snap store (like a package repository of deb
or rpm packages). A client downloads and installs those
updates autonomously. This concept is similar to deb or
rpm package management solutions. A joint solution of
Docker and Snap is also possible and combines both
advantages [21].
Only Docker and the usage of MQTT, HTTP and
JSON limits the implementation of the services. Since all
of them are versatile usable, the limits are more than
sufficient for the desired tasks. As a result, there is a wide
scope for developing service solutions.
In our implementation, we use Node.js to implement
all services light-weighted, which is suitable for IoT [22]
especially in relation to common Java or .Net
implementations. A C or C++ implementation is also
possible, and common for procession of optical data, like
pictures or point clouds.
D. Application domain
So far, this paper does not answer the question where
this architecture is implemented. Actually, we leave this
consciously open to that point. The application container
based approach allows to implement this architecture on a
 Proceedings of the 2018 IEEE IEEM
device itself (assuming required IT resources like
processing power, memory and disk space), on an IoT
gateway or on the cloud side. The services only have to be
compiled, if the underlying HW is changing between
ARM, x86 or other instruction sets. For this, there are also
solutions like QEMU available, but we did not use this so
far.
We have implemented this architecture on an x86
based IoT Gateway and on an ARM based IoT Gateway.
The goal was to integrate data from different sensor
devices of a material flow system. The use-case was to
collect data for a further analytics in regards of
maintenance and process optimization.
VI. CONCLUSION AND OUTLOOK
Our Event-Driven Architecture is able to cover
vendor and device specifics on the one side and is flexible
in terms of extension and exchange of service due to new
requirements on the other side. Today, this is possible to
the widely used concept of application containers, the
available process power together with the use of the
Publish/Subscribe communication model.
An integration of sensor data and IoT data via mobile
networks is not in focus of this paper. The next step of our
research is to adjust and implement the shown
architecture for modern mobile networks and for
upcoming standards, mainly NarrowBand IoT and 5G.
Here, limited bandwidth and battery lifetime are
important requirements to cover.
Since this paper does not focus on IT-security, we
used the safety facilities, results and connector
architectures (both, the trusted and base connector) of the
Industrial Data Space.
REFERENCES
[1] D. J. Beebe, “Signal conversion (Book style with paper title
and editor),” in Biomedical Digital Signal Processing, W. J.
Tompkins, Ed. Englewood Cliffs, NJ: Prentice-Hall, 1993,
ch. 3, pp. 61–74.
[2] Stankovic, J.A., 2014. Research Directions for the Internet
of Things. IEEE Internet of Things Journal 1, 3–9.
doi:10.1109/JIOT.2014.2312291.
[3] Bauernhansl, T., ten Hompel, M. & Vogel-Heuser, B.,
2014. Industrie 4.0 in Produktion, Automatisierung und
Logistik Anwendung Technologien Migration.
[4] S. Krco, B. Pokric, F. Carrez, „Designing IoT
Architecture(s) – A European Perspective“, in 2014 IEEE
World Forum on Internet of Things (WF-IoT), Seoul, South
Korea, pp. 79 – 84.
[5] F. Carrez, T. Elsaleh, D. Gómez, L. Sánchez, J. Lanza, P.
Grace, “A Reference Architecture for federating IoT
infrastructures supporting semantic interoperability”, in
2017 European Conference on Networks and
Communications (EuCNC), Oulu, Finland.
[6] IoT-A Consortium, “Deliverable D1.5 Final architectural
reference model for the IoT v3.0,” Tech. Rep., 2013.
[7] R. Giaffreda, „iCore: A Cognitive Management Framework
for the Internet of Things“, in The Future internet Assembly
540
2013: Validated Results and New Horizons, A. Galis, A.
Gavras (Eds.), Springer Open, pp. 350-352.
[8] V. Tsiatsis, A. Gluhak, T. Bauge et al., „The SENSEI Real
World Internet Architecture“, in Towards the Future
Internet, G. Tselentis et al. (Eds.), IOS Press, 2010 pp. 247-
256.
[9] M.Zorzi, A. Gluhak, S. Lange, A. Bassi, „From today’s
Intranet of Things to a future Internet of Things: A
wireless- and mobility-related view“, in IEEE Wireless
Communications, December 2010, pp. 44-51.
[10] EU Horizon 2020 project TransformingTransport, [Online],
Available: https://transformingtransport.eu/ [Accessed:
24.05.2018].
[11] A. Preventis, K. Stravoskoufos, S. Sotiriadis, E. Petrakis,
“IoT-A and FIWARE: Bridging the Barriers between the
Cloud and IoT Systems Design and Implementation”, in
Proceedings of the 6th International Conference on Cloud
Computing and Services Scienc, Rome, Italy. 23–25 April
2016, pp. 146–153.
[12] FIWARE platform, [Online], Available:
https://www.fiware.org/ [Accessed: 24.05.2018].
[13] sensegrow marketplace, [Online], Available:
http://www.sensegrow.com/ [Accessed: 25.05.2018].
[14] Ubuntu IoT app store toolkit, [Online], Available:
https://www.ubuntu.com/internet-of-things/appstore
[Accessed: 25.05.2018].
[15] A. Taivalsaari and T. Mikkonen, A Roadmap to the
Programmable World: Software Challenges in the IoT Era,
in IEEE Software, 2017, volume: 34,
issue: 1, pp. 72-80.
[16] R. Falkenberg, M. Masoudinejad, and M. Buschoff, et al.
PhyNetLab: An IoT-Based Warehouse Testbed, eprint
arXiv: 1706.09219, 2017.
[17] R. Falkenberg, J. Drenhaus, B. Sliwa, C. Wietfeld, System-
in-the-loop Design Space Exploration for Efficient
Communication in Large-scale IoT-based Warehouse
Systems, IEEE SysCon, Vancouver, Canada, 2018.
[18] Erl, Thomas. 2008. SOA - Entwurfsprinzipien für
serviceorientierte Architektur. München : Addison-Wesley,
2008. 978-3-8273-2651-5.
[19] Michelson, Brenda M. 2006. Event-Driven Architecture
Overview. Boston: Patricia Seybold Group, 2. 02 2006.
[20] IEEE Computer Society, “IEEE Recommended Practice for
Architectural Description of Software-Intensive Systems”,
IEEE Std 1471-2000, ISBN 0-7381-2518-0, i-25, 10.2000.
[21] Snapcraft and Docker, [Online], Available:
https://snapcraft.io/docker [Accessed: 29.05.2018].
[22] M. Collina, M. Bartolucci et al: Internet of Things
Application Layer Protocol Analysis over Error and Delay
prone Links, in 2014 7th Advanced Satellite Multimedia
Systems Conference and the 13th Signal Processing for
Space Communications Workshop (ASMS/SPSC), 2014.
[23] N. Naik: Choice of Effective Messaging Protocols for IoT
Systems: MQTT, CoAP, AMQP and HTTP, in IEEE
International Systems Engineering Symposium (ISSE),
2017.