On the Complexity of Cloud and IoT Integration: Architectures,

Challenges and Solution Approaches

Damian Kutzias

1 a

, J

urgen Falkner

2 b

and Holger Kett

2 c

University of Stuttgart IAT, Institute of Human Factors and Technology Management, Germany

Fraunhofer IAO, Fraunhofer Institute for Industrial Engineering IAO, Germany

Keywords:

Integration, Architecture, Cloud Computing, Internet of Things, IoT, Cloud Architecture, IoT Architecture.

Abstract:

Cloud Computing and the Internet of Things (IoT) shift from trend technologies to well established and broadly

accepted means to foster business development and service quality. For utilising their full potential in the

context of complex systems, applications based on these technologies often have to be properly integrated

resulting in major challenges. In this paper, we provide means for better understanding possible occurrences

of integration challenges when establishing Cloud and IoT systems. We brieﬂy present several existing Cloud

and IoT architectures and a survey on existing integration challenges. Based on these results, we derived an

overall integration architecture as a supporting tool for the indication of the different integration challenges,

which is presented in a short and full version due to the overall complexity. At last, some general approaches

for integration are discussed.

1 INTRODUCTION

Cloud Computing and the IoT are two trend technol-

ogy paradigms of the last years and also two main

enablers for smart manufacturing and digitisation.

Smart Products can have advantages over their stan-

dard variants and customers begin to expect certain

levels of monitoring, smartness and scalability mak-

ing these technologies more and more a necessity for

many enterprises. For production systems, the adop-

tion and integration might be necessary to fulﬁl the

market demands and being able to compete (Chrys-

solouris et al., 2012).

As usual, with new technologies new challenges

arise. The integration of Cloud and IoT into ex-

isting hard- and software systems comes with such

challenges. Not only solving integration problems,

but also knowing about possible occurrences as well

as calculating the costs and necessary effort to solve

them are challenging tasks.

Cloud-based integration is a system integration

that is delivered as a Cloud process and therefore

as a service. It includes data integration often im-

plemented with a service-oriented architecture (SOA)

https://orcid.org/0000-0002-9114-3132

https://orcid.org/0000-0003-2059-825X

https://orcid.org/0000-0002-2361-9733

(Korpela et al., 2016). When considering IoT sys-

tems, an integrated service can be deﬁned as a ser-

vice that works with entities (physical devices) and

composes them with non IoT services (Thoma et al.,

2012).

While traditionally enterprises have bilateral in-

tegration of services from point to point, the trend

is to chose modular solutions such as an integration

Platform as a Service (iPaaS), often making extensive

use of API management with micro service architec-

tures. This can solve integration challenges at a frac-

tion of the costs and signiﬁcantly less time (Pathak

and Khandelwal, 2017). Anyway, most enterprises

have got legacy systems in use, which usually requires

difﬁcult and costly integration or replacing activities

(Gholami et al., 2017). For small and medium-sized

enterprises in particular, the beneﬁts from using in-

tegration of different Software as a Service (SaaS)

based on an iPaaS solution are high, also when con-

sidering hybrid architectures including existing on-

premises services (Bolloju and Murugesan, 2012).

Considering both, Cloud Computing and IoT, the

combined usage brings the most beneﬁts due to the

storage and computational resources needed for IoT.

This makes communication easy and affordable and

enables new capabilities (Botta et al., 2014) and there-

fore lately, these two technologies are converging

(Cavalcante et al., 2016).

376

Kutzias, D., Falkner, J. and Kett, H.

On the Complexity of Cloud and IoT Integration: Architectures, Challenges and Solution Approaches.

DOI: 10.5220/0007750403760384

In Proceedings of the 4th International Conference on Internet of Things, Big Data and Security (IoTBDS 2019), pages 376-384

ISBN: 978-989-758-369-8

It is not always useful to store and compute ev-

erything in the Cloud. With IoT, the two paradigms

Fog Computing and Edge Computing emerge. While

the ﬁrst is about using and optimising the components

and resources between the Cloud and the devices, the

latter is about using the devices themselves, e.g. for

preprocessing the data (Linthicum, 2018). The use of

Fog and Edge Computing is considered to be appro-

priate for many IoT services, e.g. connected vehicles,

smart grids and smart cities, and is envisioned to be a

unifying platform fostering IoT applications (Bonomi

et al., 2012).

As (nearly) always in this context, security and

privacy play an important role; due to high sensitiv-

ity of data in Cloud and IoT systems, it is critical to

develop techniques that enable data integration and

sharing without any privacy breaches (Madaan et al.,

2018). For instance, a collection of timestamps may

not be seen as personally identiﬁable information or

personal data, but it could contribute to data linkage

and thereby may have some inﬂuence on privacy risks

(Danezis et al., 2014).

2 INTEGRATION

ARCHITECTURE

Within this section, an overview over several existing

Cloud and IoT architectures and their core structure

and scope is given. After that, we propose our in-

tegration architecture. It is an extensive architecture

focused on components and connections relevant for

integration challenges. It is differentiated and derived

from the outlined architectures as well as possible IoT

integration challenges we collected and identiﬁed.

A generally accepted basic IoT architecture splits

the components of an IoT system into three layers,

namely the Perception Layer containing the sensor

devices, the Network Layer for the connectivity and

the Application Layer for everything related to Ser-

vices (Wu et al., 2010)(Lee and Lee, 2018). This

might be supplemented for example by a Business

Layer and a Processing Layer (Wu et al., 2010).

From a pure Machine to Machine (M2M) perspec-

tive, the European Telecommunications Standards In-

stitute (ETSI) gives a high level architecture consist-

ing of only two layers called Network Domain and

Device and Gateway Domain (European Telecommu-

nications Standards Institute, 2013). Mapped to the

basic architecture from above, this matches the Net-

work Layer and the Perception Layer. While the Net-

work Domain contains the fundamental requirements,

such as network access and the core network, the De-

vice and Gateway Domain also contains special net-

work elements which are M2M or IoT related.

(Douzis et al., 2018) provide a sensor data collec-

tion service architecture, which includes several dif-

ferent storages, namely user information, sensor in-

formation and a logs for sensors and subscriptions.

There are also existing layer models with an inte-

gration focus, especially when an Enterprise or Man-

ufacturing Service Bus or an iPaaS is included for all

or major parts of the integration challenges. Schel et

al. propose a ﬁve layer architecture: 1) Data Source,

2) Data Service, 3) Integration, 4) Integration Service

and 5) Business Process with a manufacturing service

bus covering the Integration Layer and additional in-

tegration services and manufacturing applications on

the Integration Service Layer. Whereas from a data

centre perspective this might cover all of or the major

integration challenges, we have a more holistic view

of integration challenges without a focus on smart

manufacturing, also including the physical environ-

ment and the basic infrastructure as well as message

broker systems.

In (Srdjan Krco and Carrez, 2014), a architectural

reference model functional view is given as a layered

model of functional groups management, service or-

ganisation, virtual entity, IoT service, security and

communication between the device and the applica-

tion, giving an overview of the main functions usually

required by IoT systems.

For our integration architecture we decided to sep-

arate it into three areas and six layers, as shown in Fig-

ure 1. The areas are ranging from the shop ﬂoor (in-

dustrial internet of things) or ﬁeld (internet of things)

through the actual IT system (Cloud or on premises)

to the user (that may be anywhere) or actuator (in-

cluded in machines on the shop ﬂoor or in products

out in the ﬁeld). Concerning the six layers you ﬁnd

sensors, users or actuators on the Edge of any Cloud

or IoT architecture. Human users or products and

machines in the role of actuators make up the top

layer. Sensor devices, which might include some kind

of Edge processing capabilities, make up the bottom

layer. Each of the two requires an Access Layer to-

wards the actual IT infrastructure. The latter is di-

vided into a Data Layer where the actual data process-

ing takes place and an Application / Services Layer

where the added value services are located that are

to be made use of by the top layer. Figure 1 also

shows certain functions for each layer like e.g. Fog

pre-processing of sensor information. Finally secu-

rity integration and IT governance are tasks that span

through all layers and therefore need to be addressed

holistically.

For integration tasks the Access Layers towards

the before mentioned are most relevant, together with

On the Complexity of Cloud and IoT Integration: Architectures, Challenges and Solution Approaches

377

User

(Office/Shopfloor/Field)

Actuator

(ShopFloor/Field)/

ITSystem

(Cloud/OnPremises)

Sensor

(ShopFloor/Field)

AccessLayer

(Sensors)

Sensor/Environment

Layer

User&ActuatorLayer

AccessLayer

(Users&Actuators)

(Wireless)NetworkConnection

FogPreprocessingorFiltering

DeviceConnection&Management

ServiceIntegration

EndUserServices

EndUserInterface

EndUser

DataProcessing&AnalyticsServices

Sensors&EdgeProcessing

Application/Service

Layer

DataLayer

AutonomousActuator

DeviceConnection&Management

ActuatorInterface

SecurityIntegraton&ITGovernance

Figure 1: Architecture Overview.

the data Processing Layer and the Application or Ser-

vice layer. In the latter the data previously collected,

stored and managed are reﬁned in order to produce

the required results for users and actuators. The in-

formation ﬂow goes from bottom to top if you look at

Figure 1. This structure matches the enabling technol-

ogy categorisation to object, networking, middleware

and application in (

Colakovi

c and Had

ziali

c, 2018).

Compared to the ﬁrst mentioned and most fundamen-

tal three layer basic IoT architecture, this corresponds

with the same basic architecture and an additional

Data Layer, which was added. The reason for that is,

that there are several data integration challenges and

data do not necessarily belong to speciﬁc applications

for example when it is collected without a use case in

mind. Data is often cleaned (Salem and Abdo, 2016)

before being used by software solutions. The detailed

graphical overview can be seen in Figure 2 and its

components and layers are described in the following.

2.1 Our Architecture

A clear and widely accepted deﬁnition of IoT plat-

forms or reference architectures is missing and unam-

biguity usually can only be achieved by abstraction

(Guth et al., 2016). However, to be able to provide

means to gain a good overview and understanding of

complex Cloud and IoT systems and the related inte-

gration challenges as well as their placement, the de-

rived architecture includes many details and therefore

many optional parts.

Let us ﬁrst have a look at the overall structure of

the detailed architecture. As in the overview in Fig-

ure 1, again the information ﬂow goes from bottom to

top, beginning with sensors in production (on the shop

ﬂoor) or in products (somewhere out in the ﬁeld).

From there, sensor data moves on to a more or less

Cloud-based back-end system. In principal, this can

be public, private or hybrid Clouds, classical (ded-

icated) on premises servers or combinations (Cloud

systems working together with on premises IT). That

area is where the data processing takes place and

where applications and services are provided that gen-

erate an added value for actuators and human users. In

the detailed architecture, a fourth area is added where

additional data might be included from sources in the

web or internet. The latter can be seen as the clas-

sic internet of information and services in contrast to

the (industrial) internet of things, which adds lots of

sensor devices and corresponding data. On top, user

interfaces can be found – either for human users or

for actuators. These may simply be remote control-

lable products such as independent vehicle or heaters.

In a more complex scenario, machines in production

that can be remotely conﬁgured to produce different

variants of products give additional examples -– de-

pending on automatised decisions made by back end

services in the Cloud.

IoTBDS 2019 - 4th International Conference on Internet of Things, Big Data and Security

378

Field

Cloud/

EnterpriseIT

ShopFloor

(Wireless)

Network

Connection

Local

preprocessing

Localpreprocessing

UserInterface

Web

FogPreprocessing

orFiltering

DeviceConnection

&Management

1stLevel

DataStorage

DataIntegration

2ndLevel

DataStorage

Primary

DataLake

Semantic/Ontologic

DataLake

DataEnhancement

Service

Integration

EndUserServices

DeviceRegistration,Connection

andUpdateService

EndUser&

ActuatorInterface

User

End

User

DataRouting

EventProcessing

DataGathering

DataIntegrationService

SemanticIntegrationService

ServiceA ServiceB ServiceC AIService

Application&ServiceIntegration

PredictionData

DataAnalyticsService

Algorithms/Data

Analytics

VisualAnalytics

Service

WebServices

IndustrialInternetofThings

(IIoT)

InternetofThings

(IoT)

AccessPoint

(WLAN,NB‐IoT,

etc.)

AccessPoint

(WLAN,NB‐IoT,

etc.)

AccessPoint

(WLAN,NB‐IoT,

etc.)

AccessPoint

(WLAN,NB‐IoT,

etc.)

Sensors&Edge

Processing

InternetofInformation

andServices(WWW)

External

Information

Systems

Internal

Information

Systems

DataQualityManagementService

Machine

Learning

Service

MessageQueuingService

Application/Service

Layer

Data

Layer

Access

Layer

Sensor/

Environment

Layer

User&

Actuator

Layer

SecurityIntegration

&ITGovernance

API‐Mgmt ESB iPaaS

OpenDataSources

Actuator

Autono‐

mous

Actuator

DeviceRegistration,Connection

andUpdateService

Access

Layer

DeviceConnection

&Management

Actuator

Interface

API

Figure 2: Detailed overview of common Cloud and IoT system components for demonstrating possible integration challenge

occurrences.

To the left and right of these core areas describ-

ing the information ﬂow, boxes describing the differ-

ent integration tasks and levels can be found, such

as device connection or service integration. To the

far right, we displayed the basic layers of integration

equal to the Overview in Figure 1.

Figure 2 adds details especially in the Data Layer.

Data needs to be gathered either by putting it into

some sort of message queue or by routing it into a

database directly. One may have event processing in-

cluded, which might also use information from other

internal information systems such as Enterprise Re-

source Planning (ERP) or Production Life-cycle Man-

agement (PLM) systems. When data is collected in

the ﬁrst level data storage, it may be integrated into

a data lake (2nd level storage) by some data integra-

tion service. This data integration service may also

connect with data sources from the internet. Exam-

ples may be external information systems, e.g. from

suppliers, web services like weather forecasts, real-

time trafﬁc information or open data sources of all

kinds. The next possible step is the enhancement of

the data in one or several (distributed) databases. De-

pending on the size and usage, these are also called

data lake. The enhancement can be done by managing

data quality, by semantic integration or by letting ma-

chine learning services create new information based

on the second level data storage to give some exam-

ples. On top of that, the actual analysis starts, making

use of the aggregated and enhanced data and ﬁnally

completing the Data Layer.

Within the Application Layer all the services that

On the Complexity of Cloud and IoT Integration: Architectures, Challenges and Solution Approaches

379

are ﬁnally processing and using the data in order to

offer it to human users or in order to inﬂuence or con-

trol actuators in machines or products can be found.

These services range from visual analytics services

for human data scientists to artiﬁcial intelligence ser-

vices that may be the foundation of digital assistants

and new forms of customer services. Also they may

be the classics of enterprise systems from ofﬁce, from

customer relationship management (CRM) to enter-

prise content management (ECM) systems and the

likes. Of course information needs to be passed be-

tween those application services and therefore the Ap-

plication Layer also needs to comprise an application

& service integration component, such as API man-

agement services, an enterprise service bus (ESB) or

an iPaaS which is basically an ESB as a service from

the (public) Cloud.

Below the Data Layer as well as on top of the

application layer we ﬁnd an Access Layer. The Ac-

cess Layers connect the sensor and user/actuator areas

with the IT System area. Of course, actuators and sen-

sors are often part of the same device or production

machine, and the data and commands also may have

to go all the way back through Edge or Fog process-

ing and network connection in order to reach the ac-

tuators. However, these two are separated from each

other for the purpose of better comprehension. In the

Access Layers the integration of networked sensors,

actuators and ﬁnally also human users with the (possi-

bly Cloud-based) IT back-end takes place. Some sort

of device management may be used here and in the

case of Edge or Fog computing also local data pre-

processing may take place here. The upper Access

Layer provides human access to services (and the data

included) or integrates actuators with the IT system

through an actuator API.

The task of integration spans throughout the

whole picture and due to the complexity of the topic,

it will not be described in detail in this architectural

overview. All the same, security integration may not

be underestimated. It comprises many different ﬁelds,

starting from technical aspects such as identity man-

agement and over-the-air (OTA) ﬁrmware updates for

sensors and actuators throughout security processes

and incident response and not ending with the setup

of service level agreements or the encryption of data

ﬂows.

Whereas the architecture contains six layers, we

discuss only the ﬁrst four rather technical layers in

detail for the integration challenges, since challenges

on the last two layers are usually covered by the Ac-

cess Layer or are part of the application development

instead of the overall system setup. These are the Sen-

sor/Environment Layer, the Access Layer, the Data

Layer and the Application Layer.

3 INTEGRATION CHALLENGES

Within this section, for the four technical layers of

our architecture which are most relevant for the inte-

gration, challenges are depicted and described.

While most challenges are located predominantly

at one layer, security is a challenge class which ranges

over all layers and is therefore not listed for the layers.

As more and more systems are connected with each

other the overall vulnerability increases dramatically

(van Velzen, 2017). The challenges affect nearly ev-

ery component and include on-boarding, (single) sign

on, (distributed) identity management, access delega-

tion, encryption, network separation, incident man-

agement and many more. Since security is a topic re-

quiring investigation on a different level, we exclude

it from our list of challenges. We included it here

and in the architecture to respect it when consider-

ing complex systems, but to really take security chal-

lenges and their effect to systems implementation into

account, a separate survey is necessary.

3.1 Environment Integration

The challenges in the Environment Layer are about

setting up the devices in their physical environment

as well as providing the basic network functionality.

 Device Placement. The placement of the devices

can be as easy as just placing them somewhere, but

can also be a complex task. Depending on the tech-

nical requirements of the devices themselves (e.g.

being waterproof) and their tasks, the environment

has to be chosen appropriately (e.g. a temperature

sensor for heating control behaves drastically dif-

ferent when placed interior, exterior or in sun af-

fected places). For Smart Products and wearables,

the sensor integration into a product can be a major

task, such as embedding them into clothing (Chen

et al., 2017).

 Mobility. Whereas many protocols and devices are

designed to be used stationary, mobility such as for

smartphones and wearables brings new challenges.

Besides of the power supply, adequate network

protocols have to be used and the devices have to be

robust and precise under movement (Pereira et al.,

2013) (Botta et al., 2014).

 Network Access. While a broad availability net-

work is quite common, especially for enterprises,

there are still areas where the necessary bandwidth

or even internet at all is an issue (Clark, 2018).

IoTBDS 2019 - 4th International Conference on Internet of Things, Big Data and Security

380

In addition, the environment can contain disrup-

tive factors limiting the possible connection types

(Apple Inc., 2017) which can be the case e.g. in

manufacturing halls.

 Power Supply. The energy consumption of the de-

vices varies depending on the task they are used

for and their frequency. Whereas for many station-

ary devices a continuous power supply is no prob-

lem, for mobile devices and wearables this is one

of the primary challenges (Partin-Vaisband, 2017).

Not only physical actions, but also reading sensor

values and sending data over a network connection

consumes a lot of energy.

3.2 Access Integration

 Protocols. Whereas there are some standards such

as MQTT or HTTP (REST) establishing, there

are also many other possible protocols which can

cause much effort to integrate into the IoT system

(

Colakovi

c and Had

ziali

c, 2018). For machine to

machine communication, OPC UA (OPC Uniﬁed

Architecture) is a common and important proto-

col, but for higher level applications such as mon-

itoring, the protocol compliance may be not given

(Hazarika et al., 2015).

 Gateways. In complex IoT systems, gateways can

play an important role acting as message brokers.

A message broker provides communication chan-

nels for both things and a platform, which helps to

improve the scalability and reliability of IoT sys-

tems (Pipatsakulroj et al., 2017). Well designed

message broker systems can drastically increase

the overall system robustness and prevent or re-

duce the single points of failure. They also help

decoupling different system components (Kolluru

and Mantha, 2013), fostering the implementation

of SOA or microservice architectures. IoT smart

gateways may improve the performance of IoT de-

vices inserted into an IP backbone even in indus-

trial environments without compromising the net-

work load (Diaz-Cacho et al., 2015). Gateways can

also operate as an additional abstraction layer be-

tween the devices and the rest of the system, i.e.

as adapters making the system device (and proto-

col) independent (Busemann et al., 2012). That

addresses the heterogeneous devices and compo-

nents, which is one of the major challenges for IoT

(Guo et al., 2018).

 Device Management. Besides registration and

convenient conﬁguration, there are also other de-

vice related requirements to facilitate service en-

abling, including software/ﬁrmware update, re-

mote diagnostics, and device capability provision-

ing. These are requirements usually handled by a

uniﬁed device management mechanism (Ma et al.,

2008).

 Servers and Virtualisation. When not only con-

suming public Cloud resources, the back end in-

frastructure has to be managed and provided. Dedi-

cated servers and Cloud systems even more require

extensive installation, conﬁguration and adminis-

tration. In case of (partially) self managing Cloud

systems, core Cloud management such as rapid

provisioning, resource changing, monitoring and

reporting has to be solved (Liu et al., 2011). Pow-

erful tools like VMWare, Cloud Foundry or Open-

Stack can be used to handle these challenges, but

installation and conﬁguration is not always easy,

e.g. half of the enterprises that tried to implement

an OpenStack, failed (SUSE, 2016).

3.3 Data Integration

 Data Quality Management. Decisions based on

the analysis and evaluation of data and information

are more likely to produce desired results, but in

order to achieve that, the quality has to be ensured,

i.e. the data has to be correct, reliable and complete

(ISO, 2015) (Ardagna et al., 2018). In addition,

the risk of bad quality of data increases with the

amount and complexity of the collected data (Watts

et al., 2009). When considering IoT systems such

as smart home/building, a crucial challenge is to

handle the weakest links such as defects or miscon-

ﬁguration of sensors (Banerjee and Sheth, 2017).

 Deletions. Depending on the amount of collected

data, storage can cause scaling challenges, at least

an increase of the price. Also, not all data should

be collected without question and data not creating

any value can and should be deleted or not stored

(Lenz et al., 2018).

 Harmonised information model. Different ap-

plications often use different information models

(Schel et al., 2018) and the majority of global busi-

ness documents are sent in formats not readable for

machines (Korpela et al., 2016).

 Rights Management. When data is not stored

separately for every application, but in shared

databases or even data lakes, it might be neces-

sary to have rights management. Features like

multi-tenancy and third party managed infrastruc-

ture in Cloud environments require identity and ac-

cess management mechanisms (Indu et al., 2018).

 Analytics. When data is used to learn and opti-

mise or in reﬁnements based on rules or other data,

On the Complexity of Cloud and IoT Integration: Architectures, Challenges and Solution Approaches

381

the data has to be accessible for analytics services.

Many enterprises, especially in the manufacturing

industry, tend to have a rather diverse analytics

landscape resulting in a complex and sometimes

redundant and therefore inefﬁcient system (Lenz

et al., 2018). This may include several dedicated

solutions from different areas such as analytics of

process states, data quality, energy consumption

and device or system condition.

 Big Data. When services make extensive use of

huge data amounts, common data bases and com-

putation architectures are not sufﬁcient anymore.

When IoT devices are involved it should be care-

fully considered whether a big data architecture is

required or not. With an estimated number of 50

billion IoT devices in 2020, the IoT will be one of

the main sources of big data with Cloud Comput-

ing enabling the computation and analysis of the

data (Botta et al., 2014). A common architecture

for handling big data is called Lambda Architec-

ture and has two different streams, a long process-

ing line for the long computation and a real time

processing stream (Gribaudo et al., 2018).

3.4 Application Integration

Integration challenges in the Application Layer cover

integration directly between applications, integration

by service buses and integration of services in internet

based service platforms.

 Application Communication. When different ap-

plications have to work with the same data or are

part of the same (business) processes, the com-

munication between them has to be solved (Schel

et al., 2018).

 Monitoring. Due to the continuously growing

complexity of infrastructure, services and systems

especially in the Cloud context, effective, efﬁcient

and constant monitoring is required for proper op-

eration and management (Botta et al., 2014) (Aceto

et al., 2013).

3.5 Solution Approaches

 Bilateral Service Integration (BSI). Conceptually

the most simple approach, the bilateral service in-

tegration usually is the most labour-intensive ap-

proach for application integration. For every two

applications, the integration has to be solved anew

if they are expected to work together. The bilat-

eral integration of services is the traditional way

and sometimes also called EAI (Enterprise Service

Integration) (Pathak and Khandelwal, 2017). How-

ever, we have not chosen the term EAI, since it is

misleading due to its usage similar to the Enter-

prise Servise Bus Approach (Thoopurani, 2014).

BSI is also understood as a solution for the com-

plexity problem of the biliteral approach (Mungrah

and Cadersaib, 2017) which is in conﬂict with the

former usage. Nowadays, the biliteral approach

is not considered a meaningful approach anymore

and usually at least one of the solutions below is

chosen. According to the EAI Industry Consor-

tium, more than 70% of the BSI projects fail in

some way, either by failing the deadline, the costs

or the integration goal (Craggs, 2004).

 Enterprise Service Bus. The bus concept for

the software level is a standard based communica-

tion framework allowing different software mod-

ules to communicate with each other in a cen-

tralised way providing transformation or transla-

tion of messages to allow for easy integration of

legacy applications (Morariu et al., 2012). Service

buses can have more speciﬁc forms to meet the

requirements of speciﬁc industry sectors, e.g. as

Manufacturing Service Buses (Schel et al., 2018).

Due to the translation and transformation capabili-

ties of service buses, the integration of them usually

also covers challenges from the Data Layer.

 iPaaS. Integration Platform as a Service contains

a set of integration services providing elastic scal-

ability Cloud platform integration, also between

different deployment models (e.g. on premises,

Cloud) (Palanimalai and Paramasivam, 2015). This

can be seen as an enterprise service bus for Cloud

solutions which is itself consumed from a Cloud,

that is, as a service. Such setup includes not only

the execution of the primary business processes on

third-party Cloud systems but the interactions with

the other Cloud and on-premise systems on behalf

of a client, as well (Suzic, 2016).

 Service Platform Integration. Over the last years

many internet service platforms came up. These

can not only act as marketing and sales channels for

software services, but also add value by providing

an integrated environment with middleware such

as billing, single-sign on, authentication, authori-

sation, developer support and many more and they

grow in value proportional to the platform ecosys-

tem (Mineraud et al., 2016). Often such platforms

also solve many challenges from the other layers

such as data handling, analytics and even device

management (Rauen et al., 2018) as well as analyt-

ics or machine learning (D

ıaz et al., 2016). These

values can be used to solve many integration chal-

lenges at once, whereas the services have to be inte-

grated to the platform itself according to the inter-

faces, standards and protocols deﬁned by the ser-

IoTBDS 2019 - 4th International Conference on Internet of Things, Big Data and Security

382

vice platform. The main difference compared to

iPaaS solutions is, that the offered services are al-

ready integrated, but the customer is limited to the

platform repertoire.

4 CONCLUSION

In this paper, we surveyed, brieﬂy presented and dis-

cussed several Cloud and IoT architectures with a fo-

cus on components relevant for integration. We also

surveyed integration challenges for Cloud and IoT

and derived an integration architecture as an overview

of possible integration occurrences. The components

are structured in six layers, namely the Environment,

Access, Data, Application, User Access and User

Layer, whereat the ﬁrst four layers are the important

ones for the technical integration. The identiﬁed chal-

lenges are assigned to the most related layers and dis-

cussed respectively. Whereat there is much literature

about both, architectures and integration, to the best

of our knowledge, no extensive overview existed so

far. We also present the most common solution ap-

proaches bilateral service integration, enterprise ser-

vice buses, iPaaS and service platforms, each cover-

ing many of the integration challenges.

REFERENCES

Aceto, G., Botta, A., de Donato, W., and Pescap

e, A.

(2013). Cloud monitoring: A survey. Computer Net-

works, 57(9):2093–2115.

Apple Inc. (2017). Potential sources of Wi-Fi and Bluetooth

interference.

Ardagna, D., Cappiello, C., Sam

a, W., and Vitali, M.

(2018). Context-aware data quality assessment for big

data. Future Generation Computer Systems, 89:548–

562.

Banerjee, T. and Sheth, A. (2017). IoT Quality Control for

Data and Application Needs. IEEE Intelligent Sys-

tems, 32(2):68–73.

Bolloju, N. and Murugesan, S. (2012). Cloud-based B2B

Systems Integration for Small-and-Medium-sized En-

terprises. Proceedings of the International Conference

on Advances in Computing, Communications and In-

formatics.

Bonomi, F., Milito, R., Zhu, J., and Addepalli, S. (2012).

Fog Computing and Its Role in the Internet of Things.

Proceedings of the ﬁrst edition of the MCC workshop

on Mobile cloud computing.

Botta, A., de Donato, W., Persico, V., and Pescape, A.

(2014). On the Integration of Cloud Computing and

Internet of Things. In 2014 International Conference

on Future Internet of Things and Cloud, pages 23–30.

IEEE.

Busemann, C., Gazis, V., Gold, R., Kikiras, P., Kovace-

vic, A., Leonardi, A., Mirkovic, J., Walther, M., and

Ziekow, H. (2012). Enabling the Usage of Sensor Net-

works with Service-Oriented Architectures. Proceed-

ings of the 7th International Workshop on Middleware

Tools, Services and Run-Time Support for Sensor Net-

works.

Cavalcante, E., Pereira, J., Alves, M. P., Maia, P., Moura,

R., Batista, T., Delicato, F. C., and Pires, P. F. (2016).

On the interplay of Internet of Things and Cloud Com-

puting: A systematic mapping study. Computer Com-

munications, 89-90:17–33.

Chen, M., Ma, Y., Li, Y., Di Wu, Zhang, Y., and Youn, C.-H.

(2017). Wearable 2.0: Enabling Human-Cloud Inte-

gration in Next Generation Healthcare Systems. IEEE

Communications Magazine, 55(1):54–61.

Chryssolouris, G., Georgoulias, K., and Michalos, G.

(2012). Production Systems Flexibility: Theory and

Practice. IFAC Proceedings Volumes, 45(6):15–21.

Clark, J. (2018). Bandwidth Limitations and the Cloud: The

Data Center Journal.

Colakovi

c, A. and Had

ziali

c, M. (2018). Internet of Things

(IoT): A Review of Enabling Technologies, Chal-

lenges, and Open Research Issues. Computer Net-

works.

Craggs, S. (2004). Avoiding EAI Disasters.

Danezis, G., Domingo-Ferrer, J., Hansen, M., Hoepman,

J.-H., Le M

etayer, D., Tirtea, R., and Schiffner, S.

(2014). Privacy and Data Protection by Design – from

policy to engineering. European Union Agency for

Network and Information Security.

ıaz, M., Mart

ın, C., and Rubio, B. (2016). State-of-the-

art, challenges, and open issues in the integration of

Internet of things and cloud computing. Journal of

Network and Computer Applications, 67:99–117.

Diaz-Cacho, M., Delgado, E., Falcon, P., and Barreiro, A.

(2015). IoT integration on Industrial Environments.

IEEE World Conference on Factory Communication

Systems.

Douzis, K., Sotiriadis, S., Petrakis, E. G., and Amza, C.

(2018). Modular and generic IoT management on the

cloud. Future Generation Computer Systems, 78:369–

378.

European Telecommunications Standards Institute (2013).

TS 102 690 - V2.1.1 - Machine-to-Machine commu-

nications (M2M); Functional architecture.

Gholami, M. F., Daneshgar, F., Beydoun, G., and Rabhi, F.

(2017). Challenges in migrating legacy software sys-

tems to the cloud — an empirical study. Information

Systems, 67:100–113.

Gribaudo, M., Iacono, M., and Kiran, M. (2018). A perfor-

mance modeling framework for lambda architecture

based applications. Future Generation Computer Sys-

tems, 86:1032–1041.

Guo, H., Ren, J., Zhang, D., Zhang, Y., and Hu, J. (2018).

A scalable and manageable IoT architecture based on

transparent computing. Journal of Parallel and Dis-

tributed Computing, 118:5–13.

Guth, J., Breitenb

ucher, U., Falkenthal, M., Leymann, F.,

and Reinfurt, L. (2016). Comparison of IoT Platform

Architectures: A Field Study based on a Reference

Architecture. 2016 Cloudiﬁcation of the Internet of

Things.

On the Complexity of Cloud and IoT Integration: Architectures, Challenges and Solution Approaches

383

Hazarika, P., Shenoy, S., Tolety, S. B., and Kalekar,

N. (2015). Mobile Cloud Integration for Industrial

data Interchange. International Conference on Ad-

vances in Computing, Communications and Informat-

ics (ICACCI).

Indu, I., Anand, P. R., and Bhaskar, V. (2018). Identity and

access management in cloud environment: Mecha-

nisms and challenges. Engineering Science and Tech-

nology, an International Journal, 21(4):574–588.

ISO (2015). Quality management principles.

Kolluru, N. V. S. and Mantha, N. (2013). Cloud Integration

- Strategy to Connect Applications to Cloud. Annual

IEEE India conference (INDICON).

Korpela, K., Mikkonen, K., Hallikas, J., and Pynnonen, M.

(2016). Digital Business Ecosystem Transformation –

Towards Cloud Integration. In 2016 49th Hawaii In-

ternational Conference on System Sciences (HICSS),

pages 3959–3968. IEEE.

Lee, D. and Lee, H. (2018). IoT service classiﬁcation and

clustering for integration of IoT service platforms. The

Journal of Supercomputing, 10(2):1568.

Lenz, J., Wuest, T., and Westk

amper, E. (2018). Holistic

approach to machine tool data analytics. Journal of

Manufacturing Systems.

Linthicum, D. (2018). Edge computing vs. fog computing:

Deﬁnitions and enterprise uses.

Liu, F., Tong, J., Mao, J., Bohn, R., Messina, J., Badger, L.,

and Leaf, D. (2011). NIST Cloud Computing Refer-

ence Architecture. National Institute of Standards and

Technology, Gaithersburg, MD.

Ma, J., Liao, J., and Zhu, X. (2008). Device Management

in the IMS. Journal of Network and Systems Manage-

ment, 16(1):46–62.

Madaan, N., Ahad, M. A., and Sastry, S. M. (2018). Data

integration in IoT ecosystem: Information linkage as

a privacy threat. Computer Law & Security Review,

34(1):125–133.

Mineraud, J., Mazhelis, O., Su, X., and Tarkoma, S. (2016).

A gap analysis of Internet-of-Things platforms. Com-

puter Communications, 89-90:5–16.

Morariu, C., Morariu, O., Borangiu, T., and Raileanu,

S. (2012). Manufacturing Service Bus Integration

Model for Implementing Highly Flexible and Scalable

Manufacturing Systems. IFAC Proceedings Volumes,

45(6):1850–1855.

Mungrah, R. and Cadersaib, Z. (2017). Cloud Applica-

tion Integration Methodology using Enterprise Appli-

cation Integration. 2017 International Conference on

Infocom Technologies and Unmanned Systems (IC-

TUS).

Palanimalai, S. and Paramasivam, I. (2015). An Enterprise

Oriented View on the Cloud Integration Approaches

– Hybrid Cloud and Big Data. Procedia Computer

Science, 50:163–168.

Partin-Vaisband, I. (2017). Automated Design of Stable

Power Delivery Systems for Heterogeneous IoT Sys-

tems. In Behjat, L., Han, J., Velev, M. N., and Chen,

D., editors, Proceedings of the on Great Lakes Sym-

posium on VLSI 2017 - GLSVLSI ’17, pages 381–386,

New York, New York, USA. ACM Press.

Pathak, R. C. and Khandelwal, P. (2017). A Model for

Hybrid Cloud Integration: With a Case Study for IT

Service Management (ITSM). In 2017 IEEE Interna-

tional Conference on Cloud Computing in Emerging

Markets (CCEM), pages 113–118. IEEE.

Pereira, P. P., Eliasson, J., Kyusakov, R., Delsing, J., Raay-

atinezhad, A., and Johansson, M. (2013). Enabling

Cloud Connectivity for Mobile Internet of Things

Applications. In 2013 IEEE Seventh International

Symposium on Service-Oriented System Engineering,

pages 518–526. IEEE.

Pipatsakulroj, W., Visoottiviseth, V., and Takano, R. (2017).

muMQ: A Lightweight and Scalable MQTT Broker.

2017 IEEE International Symposium on Local and

Metropolitan Area Networks (LANMAN).

Rauen, H., Glatz, R., Schnittler, V., Peters, K., Schorak,

M. H., Zollenkop, M., L

uers, M., and Becker, L.

(2018). Platform Economics in Mechanical Engineer-

ing: Challenges – opportunities – courses of action.

Roland Berger GmbH.

Salem, R. and Abdo, A. (2016). Fixing rules for data clean-

ing based on conditional functional dependency. Fu-

ture Computing and Informatics Journal, 1(1-2):10–

26.

Schel, D., Henkel, C., Stock, D., Meyer, O., Rauh

oft, G.,

Einberger, P., St

ohr, M., Daxer, M. A., and Seidel-

mann, J. (2018). Manufacturing Service Bus: An Im-

plementation. Procedia CIRP, 67:179–184.

Srdjan Krco, B. P. and Carrez, F. (2014). Designing IoT

Architecture(s): A European Perspective. IEEE World

Forum on Internet of Things (WF-IoT).

SUSE (2016). New Research Shows OpenStack Adoption

Strong, But Complexities Remain.

Suzic, B. (2016). Securing integration of cloud services in

cross-domain distributed environments. In Ossowski,

S., editor, Proceedings of the 31st Annual ACM Sym-

posium on Applied Computing - SAC ’16, pages 398–

405, New York, New York, USA. ACM Press.

Thoma, M., Meyer, S., Sperner, K., Meissner, S., and

Braun, T. (2012). On IoT-services: Survey, Classiﬁca-

tion and Enterprise Integration. In 2012 IEEE Inter-

national Conference on Green Computing and Com-

munications, pages 257–260. IEEE.

Thoopurani, G. (2014). Rethinking B2B business: Enter-

prise application integration (EAI) in the cloud.

van Velzen, J. T. (2017). Securing the Insecurable?

An overview of Security for the Internet of Things.

Datenschutz und Datensicherheit - DuD.

Watts, S., Shankaranarayanan, G., and Even, A. (2009).

Data quality assessment in context: A cognitive per-

spective. Decision Support Systems, 48(1):202–211.

Wu, M., Lu, T.-J., Ling, Ling, Fei-Yang, Sun, J., and Du,

H.-Y. (2010). Research on the architecture of Internet

of things. 3rd International Conference on Advanced

Computer Theory and Engineering (ICACTE), 2010.

IoTBDS 2019 - 4th International Conference on Internet of Things, Big Data and Security

384