IoT-A and FIWARE: Bridging the Barriers between the Cloud and
IoT Systems Design and Implementation
Alexandros Preventis, Kostas Stravoskoufos, Stelios Sotiriadis and Euripides G. M. Petrakis
Intelligent Systems Laboratory Department of Electronic and Computer Engineering,
Technical University of Crete (TUC), Chania, gr-73100, Greece
Keywords: Cloud Computing, Internet of Things, IoT-A, FIWARE, Cloud Service Interoperability.
Abstract: Today, IoT systems are designed and implemented to address specific challenges based on domain specific
requirements, thus not taking into consideration issues of openness, scalability, interoperability and use-case
independence. As a result, they are less principled, lacking standards, vendor oriented and hardly replicable
since the same IoT architecture cannot be used in more than one use-cases. To address the fragmentation of
existing IoT solutions, the IoT-A project proposes an architecture reference model that defines the principles
and standards for generating IoT architectures and promoting the interoperation of IoT solutions. However,
IoT-A addresses the architecture design problem, and does not focus on whether existing cloud platforms can
offer the tools and services to support the implementation of IoT-A compliant IoT systems. In this work we
propose an architecture based on IoT-A that focuses on the FIWARE open cloud platform that in turn provides
the building blocks of future Internet applications and services. We further correlate FIWARE and IoT-A
projects to identify the key features for FIWARE to support IoT-A compliant system implementations.
1 INTRODUCTION
Over the recent years, Cloud Computing and IoT have
been rapidbly advancing as the two fundamental
technologies of the Future Internet concept. Although
both focus on different domains and have evolved
independently, various works integrate common
solutions and identify significant advantages. These
are as follows:
The cloud's virtually unlimited resource pool
could be paired with the exponentially growing
demands of the IoT. As enormous amounts of
data is generated, cloud offers the requiring
facility to store and processes as well as to
access for multiple third party users.
The cloud offers an elastic environment that can
scale on demand and according to the needs of
the user, thus allowing the creation of more
flexible IoT systems that can effectively adapt
to their changing requirements.
High availability is crucial for any IoT system
and can be currently guaranteed by modern
cloud providers.
Cloud computing can bridge the gap between
devices and applications by abstracting IoT
management and composition services, acting
as and intermediate layer and by hiding the
complexities and the peculiarities of the IoT
systems.
Thus, it is clear that Cloud Computing and IoT
forming an ideal environment for massive data
storage and manipulation. However, the lack of
standardization in the IoT domain has resulted in the
fragmentation of current IoT systems. Existing IoT
architectures have been designed and implemented to
address specific challenges with specific
requirements, not taking into consideration issues of
openness, scalability, interoperability and use-case
independence. Considering the above and due to the
vast variation of technologies in the IoT domain,
current solutions are vertically closed forming many
“Intranets of Things” rather than an “Internet of
Things”.
To address this problem, the IoT-A project
proposes a Reference Model and Architecture (RMA)
defining the principles and guidelines for generating
IoT architectures, providing the means to connect
vertically closed systems. The adoption of the IoT-A
promotes the interoperation of IoT solutions by
enabling interoperability as follows:
At the communication layer to support the co-
existence of various communication
technologies (existing or emerging).
146
Preventis, A., Stravoskoufos, K., Sotiriadis, S. and Petrakis, E.
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 Science (CLOSER 2016) - Volume 2, pages 146-153
ISBN: 978-989-758-182-3
Copyright
c
2016 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
At the service layer, thus ensuring smooth
integration into the service layer of Future
Internet applications.
Moreover, IoT-A compliant architectures assure
that generated knowledge will be modular and re-
usable across domain or use-case specific boundaries.
In this work we propose to design FIWARE IoT
systems deriving from IoT-A. We study FIWARE
Generic Enablers (GEs) and investigate whether the
proposed architecture can be implemented on
FIWARE by testing FIWAREs ability to support IoT-
A compliant IoT system implementations. We
compare the functionality of GEs against IoT-A
requirements and guidelines and point out
weaknesses and missing points along with
suggestions.
Having said that, we present the background and
related work in Section2. In Section 3 we discuss the
proposed architecture and then the correlation
between IoT-A and FIWARE. Finally, in Section 4,
we state our conclusions and discuss future research
issues.
2 BACKGROUND WORK
This section presetns the IoT-A project that
introduces standards, guidelines and directions for
generating IoT architectures. We also discuss
FIWARE and its relationship with IoT systems. IoT-
A introduces a Reference Model and a Reference
Architecture that are discussed bellow.
2.1 Architectural Reference Model
ARM is an abstract framework that comprises of a
minimal set of unifying concepts, axioms and
relationships for understanding significant
relationships between the entities of the IoT domain.
It consists of several sub-models that set the scope for
the IoT design space:
IoT domain model: It is a top-level description
of the IoT domain that introduces the main
concepts of the IoT like Devices, IoT Services
and Virtual Entities (VEs), and it also relations
between these concepts.
IoT Information model: It defines the structure
(e.g. relations, attributes) of IoT related
information in an IoT system on a conceptual
level.
IoT Functional model: It identifies groups of
functionalities, grounded in key concepts of the
IoT Domain Model. Functionality Groups (FGs)
provide the functionality for interacting with the
instances of these concepts or managing the
information related to the concepts (e.g.,
information about Virtual Entities or
descriptions of IoT Services). FGs use the
Information Model for structuring any
information they manage.
IoT Communication model: Introduces
concepts for handling the complexity of
communication in heterogeneous IoT
environments. Constitutes one FG in the IoT
Functional model.
Trust,Security and Privacy (TSP) model:
Introduces relevant functionality,
interdependencies and interactions. The TSP
model is also one FG in the IoT functional
model.
2.2 Reference Architecture
The IoT-A Reference Architecture is designed to
allow the generation of many, potentially different,
compliant IoT architectures that can be tailored to
specific use cases. The Reference architecture is
based on the concepts of architectural views and
architectural perspectives which are introduced
in~\cite{rozanski-woods-viewpoints}
and~\cite{rozanski-woods-perspectives}
respectively. Architectural views derive from the
concerns of stakeholders (i.e., people, groups, or
entities with an interest in the realization of the
architecture) in actual system design (e.g.,
developers, users, system administrators etc.).
Views are defined as ``representations of one or
more structural aspects of an architecture that
illustrate how the architecture addresses one or more
concerns held by one or more of its
stakeholders''~\cite{woods211} and are used to
achieve the decomposition of the architectural
description with each view addressing one aspect of
the architectural structure. The IoT-A reference
architecture comprises of the following views:
Physical Entity View It describes all physical
entities and their relations (e.g., sensors,
actuators, environment measurements) in an IoT
system. This view is not covered by IoT-A
because it is use-case independent.
IoT context View: It provides context
information about physical entities such as the
Physical Entity View, this view is also not
covered by IoT-A as it is use-case independent.
Functional View: It describes the system’s
runtime Functional Components and, also, their
responsibilities, default functions, interfaces
and primary interactions. The Functional View
IoT-A and FIWARE: Bridging the Barriers between the Cloud and IoT Systems Design and Implementation
147
derives from the Functional Model and reflects
the developers perspectives on the system.
Information View: It is used to generate an
overview about static information structure and
dynamic information flow. It is based upon the
IoT information model.
Deployment View: It explains the operational
behaviour of the functional components and the
interplay of them.
Information View: It shows how the information
flow is routed through the system and what
requests are needed to query for or to subscribe
to information offered by certain functional
components.
Figure 1 demonstrates the relationship between
IoT-A architectural views and model in the process of
designing an actual system architecture.
Figure 1: Relationship of IoT-A architectural views and
models.
Along with architectural views, IoT-A also
introduces architectural perspectives in IoT system
architectures that are collections of activities,
checklists, tactics and guidelines to guide the process
of ensuring that a system exhibits a particular set of
closely related quality properties (i.e., such as
performance, security, availability etc.) that require
consideration across a number of the system’s
architectural views~\cite{rozanski-woods-
perspectives-2005}. Perspectives are “applied” to
views to ensure acceptable qualities and guide
changes where required. The quality properties that
have been identified by IoT-A as the most important
in the IoT domain are:
Evolution and Interoperability to enable
communication between devices and services.
Availability and Resilience as the ability of the
system to stay operational and handle failures.
Trust, Security and Privacy to handle such
parameters.
Performance and Scalability related to the
monitor of the system's state and configuration
of perfomance thresholds.
2.3 FIWARE Platform
Today, FI-WARE develops cloud services to build
novel FI applications that use remotely accessible
modules (GEs) on a pay on demand model. FI-WARE
is a leading cloud vendor that offers open
specification for services that could be spread at
different geographically locations (and hosted in
various nodes-namely XIFI nodes), and are available
for utilization over the Internet. In FI-WARE, the
cloud model defines three main roles namely as the
service consumer (the developer), the service
provider (the FI-WARE open specification) and the
service creator (the GE implementer).
Traditionally, the service creator generates a
service that is hosted by FI-WARE and represents the
user requirements. FI-WARE is an innovative, open
cloud-based infrastructure for cost-effective creation
and delivery of Future Internet applications and
services named GEs. GEs are considered as software
modules that offer various functionalities along with
protocols and interfaces for operation and
communication. These include the cloud
management of the infrastructure, the utilization of
various IoT devices for data collection and the
provision of APIs (e.g. tools for data analytics) and
communication interfaces (e.g., gateways, messaging
etc.). GEs are implementations of open specifications
of the most common functionalities that are provided
by FI-WARE and are stored in a public catalogue,
thus developers could easily browse and select
appropriate APIs to use.
3 OPPORTUNITIES FROM THE
CORRELATION BETWEEN
FIWARE AND IoT-A
The role of Reference architectures such as IoT-A in
the process of creating actual systems is to provide
the key building blocks for the generation of the
system's architecture.
The generated architecture can then be used to
guide the process of the actual system
implementation. Reference architectures are
application independent being more abstract than
architecture which are designed with specific
constraints and requirements in mind. On the other
hand, architectures, which are generated by extracting
essentials (parts of existing architectures,
mechanisms, standards) from references
CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science
148
Figure 2: The proposed architecture.
architectures, should be application specific but
platform independent allowing various
implementations across different platforms. Finally
actual system implementations are platform specific
relying on platforms such as FIWARE. The
relationship between Reference architectures (IoT-
A), architectures and actual system implementations
is illustrated in Figure 3.
Figure 3: Relationship between Reference architecture(IoT-
A), architecture and the actual system implementation.
In the following we propose an architecture
deriving from IoT-A and decide whether this
architecture can be implemented on FIWARE.
Although architectures should be composed by
several views, reflecting the concerns of the different
stakeholders on the system, in our study we focus on
the Functional View of IoT-A adopting the
developers’ perspective as our main concern on the
system is the implementation.
3.1 Proposed Architecture
The proposed architecture is illustrated in Figure 2.
The architecture is composed by seven Functionality
Groups (FGs) each of these consisting of several
Functional Components (FCs). Each FCs provides
different and unique functionality and is able to
communicate with the others in a distributed
environment. In the following we present the FGs and
discuss the functionality of their FCs.
3.1.1 IoT Process Management FG
This FG provides the functional concepts necessary
to conceptually integrate the IoT world into
traditional (business) processes. Applications can
utilize the tools and interfaces defined for the IoT
Process Management FG in order to stay on the
(abstract) conceptual level of a (business) process,
while, at the same time, making use of IoT-related
functionality without the necessity of dealing with the
complexities of IoT Services. It consists of two FCs:
The Process Modelling FC provides the tools
required for modelling IoT-aware business processes
that will be serialised and executed in the Process
Execution FC which is responsible for deploying
process models to the execution environments. Also,
the Process Execution FC utilizes components of the
Service Organization FG to align application
requirements with service capabilities.
3.1.2 Service Organisation FG
Acts as a communication hub between several other
Functional Groups by composing and orchestrating
Services of different levels of abstraction. The
Service Orchestration FC resolves the IoT Services
that are suitable to fulfil service requests coming from
the Process Execution FC or from Users while the
Service Composition FC is responsible for creating
services with extended functionality by composing
IoT services with other services. Finally, the Service
IoT-A and FIWARE: Bridging the Barriers between the Cloud and IoT Systems Design and Implementation
149
Choreography FC offers a broker that handles
Publish/Subscribe communication between services.
3.1.3 Virtual Entity FG
Provides all the necessary functionality for the
interaction of VEs with the IoT system, for VE look-
up and discovery and for providing information
concerning VEs. The VE Resolution FC allows
associations between VEs and IoT services providing
discovery and look-up functionalities for these
associations while VE & IoT Service Monitoring FC
is responsible for automatically finding new
associations based on service descriptions and
information about VE’s. Finally, the VE Service FC
handles entity services (for example, services that
provide access to an entity via operations that enable
reading and/or updating the value(s) of the entity's
attributes).
3.1.4 IoT Service FG
This FG contains IoT services as well as
functionalities for discovery, look-up, and name
resolution of IoT Services. The IoT Service FC
exposes IoT resources (e.g., information retrieved
from sensors) making them accessible to other parts
of the IoT system. This FC can also be used for
delivering information to a resource in order to
control actuator devices or to configure the resource
(e.g., manage access control and permissions on the
resource). IoT Services can be invoked either in a
synchronous way by responding to service requests or
in an asynchronous way by sending notifications
according to subscriptions. Finally, the IoT Service
Resolution FC provides service discovery and
resolution functionalities along with service
description management capabilities.
3.1.5 Communication FG
The Communication FG abstracts the interaction
schemes derived from the variety of communication
technologies in IoT systems in order to provide a
common interface to the IoT Service FG. The Hop To
Hop Communication FC provides the first layer of
abstraction from the device’s physical
communication technology, the Network
Communication FC enables communication between
networks and, finally, the End to End Communication
FC offers reliable transfer, transport and, translation
functionalities, proxy/gateway support and setting
configuration parameters when the communication
crosses different networking environments.
3.1.6 Security FG
This is the FG that is responsible for security and
privacy matters in IoT-A-compliant IoT systems.
The Authorization FC is used to provide access
control and access policy management while the
Authentication FC is used for user and service
authentication. The Identity Management FC
addresses privacy by issuing and managing
pseudonyms and accessory information to trusted
subjects so that they can operate anonymously and the
Key Exchange and Management (KEM) FC enables
secure communications ensuring integrity and
confidentiality by distributing keys upon request in a
secure way. Finally, Trust and Reputation FC collects
user reputation scores and calculates service trust
levels.
3.1.7 Management FG
The Management FG is responsible for the
composition and tracking of actions that involve the
other FGs. The Configuration FC is responsible for
initialising the system's configuration (e.g., gathering
applying configurations from FC’s and Devices). It is
also responsible for tracking configuration changes and
planning for future extensions of the system. The Fault
FC is used to identify, isolate, correct and log faults that
occur in the IoT system. The Member FC is responsible
for the management of the membership of any relevant
entity (FG, FC, VE, IoT Service, Device, Application,
User) to an IoT system working in cooperation with the
Authorisation and Identity Management FCs of the
Security FG. The Reporting FC generates reports about
the system and, finally, the State FC can change or
enforce a particular state on the system by issuing a
sequence of commands to the other FCs. Moreover, it
is constantly monitoring the state of the system
notifying subscribers about changes.
3.2 FIWARE Implementaion
In the following we show how the proposed
architecture can be realized and implemented in
FIWARE using FIWARE GEs. We go through each
FG of the architecture and show which GEs
implement can supply the functionality of FCs
pointing out missing points and weaknesses and
making suggestions.
3.2.1 Service Organization FG
The functionality of the Service Choreography
FCThe is encapsulated by the Orion Context Broker
CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science
150
GE. The broker offers Publish/Subscribe capabilities,
providing NGSI9/10 interfaces, allowing clients to do
several operations like register context producer
applications, update context information and get
notifications when context information changes take
place or with a given frequency. Finally the broker
allows also to query context information and stores
context information update so queries are resolved
based on that information. The functionalities of the
other two FCs of this FG are not covered by any
FIWARE GE.
3.2.2 Service Organization FG
The functionality of the two FCs in the IoT Service
FG is partially covered by the IoT Discovery, the IoT
Broker and the Backend Device Management (IDAS)
GEs. The IoT Discovery GE allows context producers
to register their IoT Objects in linked-data format and
in turn allows context consumers to discover them
using a set of search techniques. Focuses on
semantically-annotated IoT descriptions to supports
querying via SPARQL. Although the IoT Discovery
GE offers a device discovery mechanism, it does not
offer a service resolution mechanism thus, covers
only partially the functionality of the IoT Service
Resolution FC. A service discovery and resolution
mechanism should be added to this GE. The IoT
Broker GE and the Backend Device Management GE
encapsulate both the functionality of the IoT Service
FC each of them covering different parts of it.
The IoT Broker GE retrieves and aggregates
information from IoT devices acting as a middleware
component that separates IoT applications from
devices. The GE is based on NGSI and closes the gap
between information-centric applications and device-
centric IoT installations by communicating
simultaneously with large quantities of IoT gateways
and devices in order to obtain exactly the information
that is required by the running IoT applications. By
using the broker all IoT devices can be abstracted to
be viewed as NGSI entities on a higher level hiding
the complexity of the Internet of Things from
developers. The IoT broker does not currently support
delivering information to resources in order to control
them or configure them. This is supported by the
Backend Device Management GE. The Backend
Device Management GE, provides an API for M2M
application developers and a device communication
API for device (sensor/actuators/gateways)
communication which currently implements the
SensorML and Lightweight SensorML following
protocols.
The GE Collects data from devices (status etc)
and translates them into NGSI events available at a
context broker. Application developers can use data
and send commands through the broker. An open
source Reference Gateway called "FIGWAY" is also
offered for Raspberry PI and Z-wave devices.
Although this GEs complements the IoT broker
towards supporting the specifications of the IoT
Service FC it does not make a clear separation of the
layers as they are defined by IoT-A and it's
functionality intervenes into the communication
layer. Moreover, The GE currently works only with
FIGWAY meaning that it can collect data and
manage only specific devices controlled by the
Raspberry PI and Z-wave gateways. It should be
extended to support any kind of gateway and support
all protocols other than CoaP (e.g., XMPP, MQTT,
REST).
3.2.3 Communication FG
The Protocol Adapter GE handles low level
communication between devices and the rest of the
IoT system encapsulating the functionality of the Hop
to Hop Communication FC. The GE handles
communication of devices using CoaP over 6LowPan
protocol but currently supports only the IBM Mote
hardware running the Moterunner operating system.
Although it does cover the required functionality, the
protocol Adapter is currently working with specific
devices(Mote) over a specific platform (Moterunner)
and, thus, needs to be extended to be compatible with
all available devices and platforms.
The Network Communication FC functionality is
partially covered by the Gateway Data Handling GE
which is designed to provide a common access in real
time to all data. Using a simple local XML storage,
the GE locally stores relevant processed data and
offers Filtering, aggregating and merging real-time
data from different sources.
Transforms data into events in a way that
applications need only to subscribe to events (data)
which is relevant to them. The GE offers more
functionality of what the Network Communication
FC specifies but goes against the clear separation of
layers as the IoT-A specification does not
contemplate any data processing and handling in the
Communication FG.
3.2.4 Security FG
In the Security FG the KeyRock Identity
Management (IDM) GE provides secure and private
authentication from users to devices, networks and
services, authorization, user profile management and
privacy-preserving disposition of personal data,
IoT-A and FIWARE: Bridging the Barriers between the Cloud and IoT Systems Design and Implementation
151
Figure 4: FIWARE implementation.
encapsulating the functionality of four out of five
FCs. The Key Exchange and Management FC
functionality is not currently supported. Also, as the
KeyRock architecture encapsulates the functionality
of four out of five FCs, the architecture becomes less
modular as there is no clear separation of modules.
3.2.5 Management FG
The functionality of the Member FC is covered by the
KeyRock GE which handles all entities membership
in the IoT system. This way KeyRock encapsulates
functionality of FCs in two different layers of the
architecture demoting modularity and task separation.
The functionality of the remaining Management
FG FCs is not offered by any FIWRARE GE. In
Figure 4 we illustrate the architecture substituting
FCs with FIWARE GEs. Green colour denotes that
the GE can effectively providing the specified
functionality of the FC, yellow that it does so partially
and red denotes there is currently no GE that can
provide the functionality of the FC. Finally, we
provide an array with all FCs and the corresponding
GEs in Figure 5.
Figure 5: IoT-A FIWARE Correlation Table.
4 CONCLUSIONS
Existing IoT architectures have been conceptualized
and implemented to address certain challenges based
CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science
152
on domain and use case specific requirements not
considering issues of openness, scalability,
interoperability and use-case independence. As a
result they, are less principled, lacking standards and
are vendor or domain specific. More importantly,
they are hardly replicable in the sense that the same
architecture cannot be used in more than one use
cases. The IoT-A project addresses the above
problems by providing the standards and
specifications for designing IoT architectures.
In this work, we focused on the relationship
between FIWARE and IoT-A. We proposed an
architecture based on IoT-A and showed how it can
be implemented on FIWARE using GEs. The results
show that FIWARE cannot currently support IoT
architectures fully compatible with the IoT-A
standards and specifications as it is lacking the tools
(GEs) to do so. New GEs need to be designed and
implemented to provide the required functionality
while a clear distinction of the architecture layers
specified by IoT-A should be made by redesigning
the GEs.
ACKNOWLEDGEMENTS
The research leading to these results has received
funding from the European Unions Seventh
Framework Programme (FP7/2007-2013) under grant
agreement no 604691 (project FI-STAR)
REFERENCES
IoT-A references.
Preventis, A., Stravoskoufos, K., Sotiriadis, S. and Petrakis,
E. (2015), A Future Internet Gesture Recognition Cloud
Service, 14th International Symposium on Parallel and
Distributed Computing, 29 Jun - 01 July, 2015,
Limassol, Cyprus.
Sotiriadis, S., Petrakis, G.M.E., Covaci, S., Zampognaro,
P., Georga, E., Thuemmler, C. (2013) "An architecture
for designing Future Internet (FI) applications in
sensitive domains: Expressing the Software to data
paradigm by utilizing hybrid cloud technology", 13th
IEEE International Conference on BioInformatics and
BioEngineering (BIBE 2013), November 10-13,
Chania, Greece.
IoT-A and FIWARE: Bridging the Barriers between the Cloud and IoT Systems Design and Implementation
153