D1.3 WISE IoT updated high level architecture and reference technologies and standards Editor: Martin Bauer (NECLE, EU) / SeungMyeong Jeong (KETI, KR) Submission date: 04/07/18 Version 1.0 Contact: [email protected] / [email protected]This deliverable will provide the final architecture of Wise-IoT concept and specific pilots. A detailed technology plan will help forthcoming initiatives to choose optimum infrastructures and technologies. Project Number: 723156 Project Acronym: Wise-IoT Project title: Worldwide Interoperability for SEmantics IoT
77
Embed
Project Number: 723156 Project Acronym: Wise-IoT Project ...wise-iot.eu/wp-content/uploads/2018/09/D1.3-Wise-IoT-Updated... · Introduction 10 1 Introduction An increasing number
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
D1.3
WISE IoT updated high level architecture
and reference technologies and standards
Editor: Martin Bauer (NECLE, EU) / SeungMyeong Jeong (KETI, KR)
4.1.1 Santander Smart City Use Cases Architecture Carmen López (UC)
4.1.2 Busan Smart Parking Use Case Architecture SeungMyeong Jeong (KETI)
4.1.3 Busan Bus Information Use Case Architecture Minh Hoang Nguyen (KAIST)
4.2 Smart Skiing Use Cases Martin Bauer (NECLE)
4.2.1 Chamrousse Smart Skiing Use Case Architecture Rémi Druilhe (CEA)
4.2.2 Alpensia Smart Skiing Use Case Architecture Hyokeun Choi (SDS)
4.3 Lifestyle Use Cases Cheolwoo Jung (KNU)
4.3.1 Daegu Lifestyle Use Case Architecture Cheolwoo Jung (KNU)
4.4 Service Roaming and Cross-Domain Data Reuse Use Case Martin Bauer (NECLE)
5 Conclusions Martin Bauer (NECLE)
Glossary
Term or Abbreviation Definition (Source)
AIOTI Alliance for Internet of Things Innovation
ALE Application Level Events
API Application programming interface
ASM Adaptive Semantic Module
CAG Context-Aware Auxiliary Gateway
CMC Context Management Component
DS Discovery Service
EPC Electronic Product Code
EPCIS Electronic Product Code Information Services
GE Generic Enabler (FIWARE)
GIoTS Global IoT Services
GPC Global Product Classification (GS1)
GW Gateway
HLA AIOTI High-Level Architecture
IAL Information Access Layer
IEC International Electrotechnical Commission
IEEE Institute of Electrical and Electronics Engineers
IoT Internet of Things
ISO International Organization for Standardization
ISO/IEC JTC1 ISO/IEC Joint Technical Committee 1
ITU International Telecommunication Union
LLRP Low Level Reader Protocol (GS1)
LoRa(WAN) Long Range Wide Area Network
M2M machine-to-machine
MMG Morphing Mediation Gateway
NGSI NGSI Next Generation Service Interfaces (OMA), in the context
of this project referring to the NGSI Context Interfaces,
numbered NGSI-9 and NGSI-10.
OCF Open Connectivity Foundation
OMA Open Mobile Alliance
ONS Object Naming System
PAN Personal Area Network
QoI Quality of Information
REST REpresentational State Transfer
SAR Self-Adaptive Recommender
WAN Wide Area Network
Introduction
10
1 Introduction
An increasing number of devices is getting deployed in the cities, whatever their size is. These
deployments are today often driven by regulation obligations or security concerns. A simple example is
the monitoring of indoor air quality, being an obligation in many countries (e.g. France (Décret n° 2015-
1926 du 30 décembre 2015 modifiant le décret n° 2012-14 du 5 janvier 2012 relatif à l'évaluation des
moyens d'aération et à la mesure des polluants effectuées au titre de la surveillance de la qualité de l'air
intérieur de certains établiss)). To comply with this obligation, public procurement is being launched by
the cities which get in return attractive offers from companies proposing solutions such as LoRaWAN
sensors connected to a proprietary web-based dashboard. Such a simple offer appears at first glance
cost efficient and easy to deploy. However, it appears from direct contact with cities managers during
the Wise-IoT trials that they start questioning the long-term sustainability of such an approach which
multiply deployment of vertical siloes and break the IoT paradigm. On the other side, researchers and
technologists in the IoT field have been working over the past years to solve the interoperability issue
of the IoT paradigm and as a consequence, many standards and IoT platforms, either open or
proprietary, have emerged. Unfortunately, this multiplication still does not help the city managers which
are getting lost in the market offer while perceiving the underlying issues. This holds particularly true in
small and medium size cities which do not have the large IT teams able to devote the necessary time to
understand the market offering. In addition, cities are often grouped over a certain area, building
territories, having to share some services (i.e. public, transportation).
The Wise-IoT project made in its first period an analysis of high level architectures proposed by several
standard organisations and Alliances (Wise-IoT D1.2 - Wise-IoT high level architecture and reference
technologies and standards, 2017). It resulted in a simplified 5 layers approach over which the analysed
high-level architectures can be mapped. This approach, despite having been kept simple to ease
understanding by non-experts, considers also connectivity between IoT and data enrichment (big data,
AI) domains, through a context information layer as well as multi-domain federation.
During the second period of the project, the proposed high-level architecture has been tested within
field trials. Lessons learnt are described in this D1.3 document intended to be a guideline for
administration willing to deploy an IoT infrastructure.
The document is structured as follows:
Section 2 reminds about the Wise-IoT high-level architecture. This section includes updates made over
the first version, justified by findings obtained within the field trials.
Section 3 describes several potential technologies and standards which can be used for actual
implementation of the Wise-IoT architecture.
Section 4 illustrates the use of these technologies within different use cases to help the reader to
understand the Wise-IoT architecture.
This document is an evolution of the content of D1.2 (Wise-IoT D1.2 - Wise-IoT high level architecture
and reference technologies and standards, 2017). To be self-contained and complete, some material
from D1.2 has been kept with limited changes. In some sections, where there have been significant
updates, a short description in italics at the beginning of the section explains what has changed
compared to D1.2.
Introduction
11
High-Level Architecture
12
2 High-Level Architecture
In this chapter, the Wise-IoT high-level architecture is described. The Wise-IoT high-level architecture
describes the important functional and non-functional aspects that need to be fulfilled to achieve the
main project objectives. It represents a reference architecture that then needs to be instantiated with
concrete components developed based on specific technologies to result in a system architecture. The
technologies and components that have been selected in Wise-IoT – either explicitly or they happened
to be already deployed on a certain site – are presented in Section 3. A specical focus in Wise-IoT was to
select solutions based on international standards and use semantic information to achieve semantic
interoperability. Section 4 then shows what platforms and components have been selected to
instantiate the high-level architecture in the respective pilot sites.
As a first step, key high-level architecture requirements are identified in the context of the main Wise-
IoT project objectives. Then different views and perspectives of the high-level architecture are
described, following the approach specified in the ISO/IEC/IEEE 42010 (ISO/IEC/IEEE 42010: Systems and
software engineering — Architecture description, the latest edition of the original IEEE Std 1471:2000,
Recommended Practice for Architectural Description of Software-intensive Systems., 2011). Each view
and perspective covers a different aspect and these aspects are largely orthogonal. It is not possible to
put all aspects into a single architecture diagram, e.g. information abstraction level, functional aspects
and deployment aspects should not be mixed as the same functional aspect may be covered on multiple
abstraction levels or multiple abstraction levels may be deployed in different parts of the system.
2.1 High-level Architecture Requirements
The Wise-IoT project proposed four main objectives (Wise-IoT D1.1 - Wise-IoT Pilot Use Case Technical
Description, Business Requirement, and Draft High-Level Architecture, 2016). From an architectural
perspective in particular the first two are relevant:
1. Provide a world-wide interoperable Internet-of-Things that utilizes a large variety of different IoT systems and combine them with contextualized information from various data sources.
2. Prove that this system can securely deliver dependable dynamic, real-time, and remote IoT
services with automatic adaptation to available resources and data lakes at any place in the
world.
3. Help users to trust the GIoTS and effectively exploit it for international events like the Winter
Olympics in Korea 2018.
4. Strengthen the on-going international IoT standardization based on outcomes from field pilots
Based on these, a number of high level architecture requirements are presented in this section, whose
fulfillement is at the core of the Wise-IoT architecture.
After giving an overview of the most relevant architecture views and perspectives from section 2.2 to
section 2.7, the fulfilment of the high-level architecture requirements is checked in the context of the
Wise-IoT System definition in section 2.8.
Access to information
REQ1. Integrate heterogeneous IoT technologies and platforms
Often, IoT devices like sensors and other IoT technologies have already been deployed at a certain
site. This may already include a local IoT platform that is used by local applications. Redeploying
High-Level Architecture
13
sensors or reengineering complete installations is often not feasible and thus the existing IoT
technologies and platforms have to be integrated into an encompassing IoT platform architecture.
This requirement primarily targets project objective 1 as it supports integrating a large variety of
different IoT systems.
REQ2. Enable that higher-level applications and components on only need to support one API
To ease the development of applications, it should be possible to only use a single API and still be
able to utilize core system functionality, in particular to access all relevant IoT information. This
requirement primarily targets project objective 2 as it enables uniform access to available resources
at any place in the world.
REQ3. Provide support to the data / information / knowledge pyramid
An important source of IoT data are sensors providing raw data. Only if this data is transformed and
annotated, it becomes information that can be found and used by applications that are not tightly
coupled to the sensors in the first place. Further processing and analytics can create knowledge and
eventually wisdom. This hierarchy created by annotation, processing and analytics is also known as
the knowledge or wisdom pyramid (Rowley, 2007). IoT applications require access, but also can
contribute to the layers of the knowledge pyramid, thus the IoT platform architecture needs to
support it. This requirement targets project objectives 1 and 2 as it enables contextualized and thus
higher-level information and it enables the uniform access to available resources at any place in the
world.
Semantics
REQ4. Support semantic modelling / semantic annotation
In order to understand information, its semantics needs to be clear. Semantics is the study of
meaning. If producers and consumers of information are tightly coupled, the semantics can be
implicitly encoded in the producers and consumers themselves, but if consumers need to find and
utilize information from previously unknown producers, the semantic information needs to be
explicitly provided. Raw information providers may not directly provide explicit semantics and thus
there is a need for semantic annotation to reach a higher layer in the knowledge pyramid (REQ3).
The semantic information provides the basis for achieving semantic interoperability. Semantic
interoperability is of key importance for providing a world-wide interoperable Internet-of-Things
and thus this requirement targets project objective 1.
Local and remote information
REQ5. Support transparent access to local & remote information
Applications need to be able to access local information, i.e. concerning IoT information related to
the current location of the user as well as IoT information from other locations. Beyond specifying
the geographic location of interest, the underlying access, e.g. across boundaries of underlying
systems, should be transparent to the user and the consuming application. This requirement
primarily targets project objective 2 as it enables delivering remote IoT services with uniform access
to available resources at any place in the world.
REQ6. Enable access to local & remote information for roaming users
If the user is not in his/her home location, e.g. home city or home country, the user is considered to
be “roaming”. The IoT system should still provide access to IoT information relevant at the user’s
High-Level Architecture
14
current location, but also at a remote location, e.g. the home location. This is needed to provide the
user with the same level of support in the remote location as in the home location, but also enable
the user to keep up with the situation at home or in another location. This requirement primarily
targets project objective 2 as it enables delivering remote IoT services with uniform access to
available resources at any place in the world.
Dynamic discovery
REQ7. Support discovery of information
As applications cannot be tightly coupled to sources of IoT information, e.g. in the case of a roaming
user (REQ6), they do not a priory know what information is available in the system and who can
provide it. Thus applications have to discover this, specifying the information they need. The
architecture must support the applications in either directly receiving the information or at least
getting a list of sources back that can provide the information. In order to deliver IoT services at any
place in the world, it is essential to be able to discover information. Thus this requirement targets
project objective 2.
REQ8. Support discovery and management of devices
The Wise-IoT architecture needs to support large scale IoT systems. The available devices in such
systems will change dynamically, e.g. as new devices become available, devices are replaced and
others become unavailable. Thus the system must support the discovery and management of
devices, ideally without having to do system adaptations beyond the local environment.
When working with a large variety of different IoT systems, it is important to be able to automatically
discover devices as the available devices will be changing continuously. Thus this project
requirement targets project objective 1.
Security
REQ9. Adherence to common security standards
To deliver IoT services securely in real-time and dependable dynamic manner, the Wise-IoT project
requires standard security definitions applicable in all parts. Authentication and authorization
policies should answer the different requirements of IoT systems in the interoperating network. Due
to the federated nature of Wise-IoT, any updating of the security standards (e.g., threat definition,
users’ authentication, and black list updating) should be automatically delivered to the different
parties. Furthermore, the new updates should be practical at the shortest time.
Due to the diversity of IoT applications, services, and platforms, the security protection system
requires more usability, scalability, and applicability in an interoperable model. Since Wise-IoT
provides an interworking possibility between IoT systems, the security requirements of IoT systems
should be reported regularly to provide the required updates and patches. Detecting any attack in
an IoT platform should be reported to other systems to prevent the same threat.This requirement
primarily targets project objective 2 as it enables secure and dependable IoT services.
Trust
REQ10. Support for trust building between IoT systems and their users
In the Wise-IoT architecture, components are connected for data sharing and data analysis. The data
is accessed by services or by humans in order to generate value from knowledge that is aggregated
from the IoT data. The Wise-IoT architecture shall enable close interactions between users and
systems involving access to user data or information. Thus, support for trust building between the
High-Level Architecture
15
users and the IoT systems becomes an important requirement. This requirement primarily targets
project objective 3 as it helps users to trust global IoT services.
2.2 Layered Architecture View
From a high-level perspective, the Wise-IoT architecture follows a layered approach similar to the AIOTI
HLA architecture (WG03, 2017). In addition to the basic layering of the HLA, it differentiates layers and
respective functionalities according to their level of abstraction (see Figure 1). Raw data is collected and
real-world actuation executed by a large number of heterogeneous devices. To be able to handle this,
there is an integration layer for making the raw data accessible and semantically annotate it. At the same
time, the heterogeneous devices and the connectivity between the devices is managed in this layer. The
information access layer makes information derived from the raw data accessible to applications, as well
as analytics and recommendation components. The latter makes up the Knowledge Processing Layer.
The layering follows the knowledge pyramid as specified in requirement REQ3.
Figure 1: Wise-IoT Layered Architecture View
Components making up the higher layers can talk to components in the lower layers, not just in the layer
directly below, even though this is typically the preferred way of interaction. Figure 1 shows the
interactions between the components in the layers with different line weights. The stronger the line
weight the more interactions can be expected between these layers.
The motivation behind the Layered Architecture View is the observation that typically different enablers
have been designed to support the respective functionalities on the respective abstraction layers. In
Wise-IoT, the aim is to choose standardized enablers that are best suited for the particular task and
connecting them in a suitable way to combine the particular stengths while mitigating possible
weaknesses.
2.2.1 Data Collection and Device Actuation Layer
The Data Collection and Device Actuation Layer provides the connection to the physical world. It can
utilize a large number of different device and communication technologies and is inherently
High-Level Architecture
16
heterogeneous. Key technologies are sensors and actuators for sensing and controlling relevant aspects
of the physical world. These sensors may be part of specific, often resource-constraint sensor nodes or
be attached to sensor platforms running on more powerful devices, e.g. mobile phones, gateways or
dedicated servers. The important aspect for the Wise-IoT Architecture View is that interfaces are
provided for accessing data, controlling physical world aspects and managing the devices.
2.2.2 Integration and Management Layer
The Integration and Management Layer integrates and homogenizes the access to the data and services
provided by the Data Collection Layer. The requirement REQ1 on integrating heterogeneous IoT
technologies and platforms is primarily addressed here. As a result, the components in higher layers do
not have to deal with the heterogeneous access and communication technologies. However, the data
may still be in its raw form, i.e. there may not be any common abstraction with respect to the data
provided by different devices and technologies.
In addition to providing access to the data, the Integration and Management Layer may also enable the
management of devices in the Data Collection and Device Actuation Layer and configuring and
controlling the connectivity and communication. This addresses REQ8 on management of devices.
Finally, to enable the abstraction needed by the Information Access Layer, annotation capabilities are
required through which additional (meta-) information can be added. This partially addresses
requirement REQ4 on (semantic) annotation.
2.2.3 Information Access Layer
The Information Access Layer provides access to information on a higher, common abstraction level.
Applications and components of the Knowledge Processing Layer can request information, specifying
what information they need, and they get back exactly the requested information. This addresses REQ7
on discovery of information. For this purpose, expressive filters may be supported. The Information
Access Layer may provide different interaction styles, e.g. request-response or subscribe-notify. It
integrates information from different sources in the Integration and Management Layer. The
Information Access Layer provides a suitable interface for fulfilling REQ2.
2.2.4 Knowledge Processing Layer
The components of the Knowledge Processing Layer process information and data, primarily information
provided by the Information Access Layer, to elicit higher level knowledge, implicitly contained in the
information. Different kinds of analytics, e.g. from the artificial intelligence domain, including reasoning
and learning, can be used for this purpose. Furthermore, smart applications may be supported through
recommendations derived from the information, while taking into account the application goals.
2.2.5 Application Layer
The Application Layer is the place for end-user applications. The applications primarily access Knowledge
Processing Layer and Information Access Layer components to have a good basis for optimally
supporting the users in their respective tasks. Applications directly interact with the users to find out
about their goals, which are then the basis for interacting with the Information Access Layer and the
Knowledge Processing Layer to retrieve the required information and knowledge.
High-Level Architecture
17
2.3 Deployment View and Federated Architecture
Figure 2 shows a high-level view of an IoT deployment. It consists of three logical levels on which
computing nodes can be found – device, edge and infrastructure, which may be a cloud. In practice,
there may be sublevels involving multiple nodes, but nodes can generally be characterized according to
these levels.
Figure 2: Deplployment View
Devices are nodes with a direct connection to the physical world, i.e. they can provide information about
or actuate on the physical world. So these nodes are connected to sensors and/or actuators – through
a wired or wireless connection.
Edge nodes are typically part of the wired network infrastructure, but are geographically located close
to the devices to which may be connected to edge nodes via a wireless connection. Gateway nodes are
typical examples edge nodes. They may have significant computational resources and possibly a good
network connection. If short delays are required or communication with the infrastructure represents a
bottleneck, they are a good place for deploying computation tasks.
The infrastructure/cloud is rich in computational power, but there may be bottlenecks in the connection
to devices and there may be significant delays.
High-Level Architecture
18
Figure 3: Federation of domains
A set of nodes on the device, edge and infrastructure level can be combined to form a domain, which is
typically managed by one administrative entity. In Wise-IoT, each local deployment for smart cities or
smart skiing can be seen as such a domain. To enable cross-domain operation, a federation level as
shown in Figure 3 can be added, which enables applications connecting to the federation level to access
all federated domains without having to know different access points. In order to enable efficient access
on the federation level, suitable index structures are needed. In particular, indexing according to
location is suitable for IoT. If the domains are registered with the area and type, e.g. parking spots in the
area of one city like Santander or Busan, a request scoped for one location can be forwarded to the right
domain(s) and not all domains need to be considered. It is also possible to have multiple levels of
federations, i.e. to have a federation of federated domains etc.
2.4 Semantics Perspective
Semantics is the study of meaning. In our context, this refers to the meaning of data, information or
knowledge represented in an IoT system. If systems can a-priori agree on the semantics of information,
the semantics can be implicit, i.e. encoded in the system itself. For example, due to such an agreement,
an information consuming system knows that the value 56.0 provided by an information producing
system is a temperature value in Celsius that represents the internal working temperature of a particular
machine. Such exchange of information is efficient, but requires a very tight coupling and each change
requires explicit steps to change the configuration or even to re-compile the system. For large-scale,
dynamically changing systems as in the Internet of Things, the involved systems need to be able to self-
adapt to any such changes. To be able to find the currently relevant information or the set of currently
relevant sources of information, their semantics has to be explicit, i.e. provided as meta information
with the data or information itself.
High-Level Architecture
19
For two systems to interwork in a meaningful way, they have to agree on the semantics of the
information they exchange. This is referred to as semantic interoperability, which in (W3C) is defined in
the following way: semantic interoperability “means enabling different agents, services, and applications
to exchange information, data and knowledge in a meaningful way, on and off the Web”, and in
(Murdock, et al., 2016): “Semantic interoperability is achieved when interacting systems attribute the
same meaning to an exchanged piece of data, ensuring consistency of the data across systems regardless
of individual data format.”
As shown in Figure 4 (oneM2M TR-0007 Study of Abstraction and Semantics Enablement., 2014), there
are different levels of meaningfulness regarding the semantic (meta) information that is provided, both
concerning the data itself and the device.
Figure 4: Increasing levels of meaningfulness
Semantic interoperability is a core feature of the Wise-IoT architecture as it enables the integration of
heterogeneous systems. In general, semantic information can be explicitly made available on all layers
of the Layered Architecture View described in Section 2.2. However, not all devices on the Data
Collection and Device Actuation Layer may support the explicit representation of semantic (meta)
information. Thus adding such information on higher layers, in particular the Integration and
Management Layer is required, which is also referred to as semantic annotation. Following from the
discussion above, the less semantic information is explicitly provided between systems in two layers,
the tighter the coupling has to be due to the implicit agreements necessary. In general, the higher the
layer, the higher the level of abstraction and the more important the explicit representation of semantic
(meta) information. In particular this is relevant when federating systems from different domains, which
will typically be less tightly coupled than systems in the same domain.
2.5 Trust Perspective
In addition to enabling global interoperability, the Wise-IoT project aims at building mechanisms for
ensuring trust in the global IoT systems. Such trust enablement is important because systems and
devices become increasingly connected, the need for personalization, the number of points-of-failure,
and the exposure to attacks increases.
Trust can be generally defined as an ‘assurance’ or ‘confidence’ of a trustor in a trustee to perform a
task in a way that satisfies the trustor’s expectation. In this sense, the trustor partly recognizes the
High-Level Architecture
20
vulnerabilities and potential risks when the trustee accomplishes the task. Thus, it represents the
trustor’s willingness to be vulnerable under the conditions of risks and interdependence. Generally, trust
is defined as a belief of a trustor in a trustee that the trustee will provide or accomplish a trust goal as
trustor’s expectation within a specific context for a specific period of time. As illustrated in Erreur !
Source du renvoi introuvable., in the IoT environment, trustors and trustees can be humans, devices,
systems, applications and services. Measurement of trust as the belief (called trust value) can be
absolute (e.g., probability) or relative (e.g., level of trust). It could be an action that the trustee is going
to perform (trust for action); it could also be information that the trustee provides (trust for
information). Trustor’s expectations are deliberately considered to include specific requirements for
well perform (in some degree) the trust goal.
Figure 5: Conceptual Model of Trust in the IoT
2.6 Security Perspective
In addition to enabling global interoperability, the Wise-IoT project aims also at building a standarized
mechanisms for ensuring end-to-end security in the global IoT systems. As identified by REQ9, security
is an important part of the Wise-IoT project since authentication and authorization are required in order
to identify users, things, services and applications in different domains and enabling the ability to give
them proper access rights to use enforced resources in connected IoT platforms. As the project
interconnects several IoT platforms, proper security interworking mechanisms are a key to success in
delivering reliable IoT services to users. To perform secure interworking, there is a need to integrate
security mechanisms of IoT platforms such as FIWARE or oneM2M because IoT platforms use different
security standards and security mechanisms including authentication and authorization, security
policies, etc. In addition, it is required to analyze the security requirements of each IoT platform
(oneM2M and FIWARE) to provide a federated security approach that encompass all the security
requirements of these platforms .
2.7 Self-Adaptation and Evolution Perspective
The Self-Adaptation and Evolution Perspective has been successfully incorporated into the Knowledge
Processing Layer as part of the Self-Adaptive Recommender. It has been used and validated in the
Santander Smart City field trials. As a result, we found that no change had to be made to our high-level
view on self-adaptation systems in IoT. Therefore, our theory presented in deliverable D1.2 on the Self-
Adaptation and Evolution Perspective is still valid. For the convenience of the reader, we repeat the
theory in the remainder of this section.
High-Level Architecture
21
The Knowledge Processing Layer offers the IoT system the capabilities to self-adapt and engineers to
understand the needs for IoT system evolution. It allows collecting information, analyzing that
information by answering questions, deciding how to act by interpreting these insights, and acting
according to these decisions. These abilities are the elements of a loop that controls the dynamic
behavior of the system (Cheng, et al., 2009) as illustrated in Figure 6. They allow the system to examine,
introspect, and modify its structure and behavior at runtime. They also allow engineers to understand
the achievements, problems, and needs for evolving the system over versions and releases.
Figure 6: Control loop enabling self-adaptation based on (Cheng, et al., 2009).
The Knowledge Processing Layer aggregates information needed for answering adaptation-related
questions and makes the insights that are generated by answering these questions available to
subscribers. The information may concern user intentions and requirements, context information, and
use context of the IoT system and applications. The insights may concern the validity of context
information and models of the world, the fulfillment of user requirements and preferences, and
trustworthiness of entities comprised by the system.
The Knowledge Processing Layer may initiate self-adaptation or recommend adaptations to entities
listening to the layer. Self-adaptation actions may include alterations to the system configuration,
modification of problem-solving and recommendation mechanisms, online learning, and the
manipulation of effectors. Recommendations may be targeted at humans and applications that use the
IoT system and at engineers that monitor, maintain, and evolve the IoT system.
In the Wise-IoT architecture self-adaptation and evolution are seen as a means to build end user trust
over time as the global IoT system is being used. A system that does not fulfill user needs or may not be
dependent upon will be abandoned. For that reason, mechanisms are needed to discover insights such
as unsatisfied needs and encountered problems. Wise-IoT aims at discovering these problems and needs
during runtime and acts on them by self-adapting and offering decision-support for engineers that are
concerned of evolving parts of the system.
Figure 7 offers an overview of the components and data flows needed for enabling self-adaptation and
supporting evolution.
High-Level Architecture
22
Figure 7: Self-adaptation capabilities and support for evolution.
The components and data flows are orchestrated according to the control shown in Figure 6. Data are
collected to understand the application’s requirements, the use context, the real-world context as
sensed by the IoT system, and the users’ opinions. These data are being analyzed by an inference
mechanism to offer insights, recommendations, and initiate self-adaptation. Insights might relate to the
proper functioning of the IoT system, the fulfillment of user needs, the validation of assumptions, and
other observations that are of interest to applications or humans that depend on the IoT system. The
IoT system finally offers mechanisms for subscribing to recommendations that are implied by the
insights and adapting such recommendations.
Table 1 shows the component types needed for self-adaptation and evolution of the Wise-IoT system.
Table 1: Component types of the self-adaptation and evolution perspective.
Component Types
Description
Information Sources
IoT Sensors, end-user applications, and humans involved in the use of the IoT system
Information Collectors
Subscriptions to context data (IoT sensors) and mechanisms that collect information about user needs (user inputs), use context (session managers), and user opinions (feedback probes).
Knowledge Database
Databases that allow storage of information used for inference and knowledge produced with inference.
Inference Mechanisms
Mechanisms that transform the sensed inputs into knowledge. The inference mechanisms include help for users to exploit the IoT system (recommenders), analysis of information quality (QoI analyzers), assessment of trustworthiness (trust analyzers and aggregators), and decision support for system change (fault detectors and requirements probes).
Knowledge Brokers
Mechanisms that offer subscriptions or other forms of access to knowledge such as recommendations for exploiting the IoT system, insights about system quality and fulfillment of user needs, and parameters and data needed for self-adaptation.
Knowledge Subscribers
Applications used by end-users, analysis and backlog management tools used by engineers, and components offering configuration and adaptation capabilities.
The information collectors, knowledge database, inference mechanisms, and knowledge brokers
represent the core of the self-adaptation and evolution perspective and represent mandatory elements
of an IoT system that is self-adapting or offers support for evolution. The information sources and
knowledge subscribers are considered to be the elements external of the self-adaptation and evolution
Users
IoT System
Engineers
Recommendations
Insights
Evolve
Inference
Adaptation
Requirements,Use Context, Opinions
KnowledgeInformation
CollectorKnowledge
Broker
IoT Context
Self-Adaptation
High-Level Architecture
23
view. An inference mechanism is considered internal if it consumes produced knowledge as input
information.
2.8 Wise-IoT System Definition
A Wise-IoT System is a system that instantiates the high-level architecture described in this chapter and
thereby fulfills the high-level architecture requirements specified in Section 2.1.
A Wise-IoT System implements the layered architecture. It supports local IoT platforms and
heterogeneous IoT devices with sensing an actuating capabilities in the Data Collection and Device
Actuation Layer. It integrates these IoT devices and local IoT platforms in the Integration and
Management Layer, thereby fulfilling REQ1. It supports the data / information / knowledge pyramid by
implementing corresponding layers, i.e. the Integration and Management Layer, the Information Access
Layer and the Knowledge Processing Layer respectively. Thus REQ3 is fulfilled.
The purpose of the Information Access Layer is to provide a uniform API for accessing information.
Application developers that require general high level information can use this API and do not need to
know about any others, thus fullfiling REQ2. More device-specific information and functionality can be
accessed through the common interface provided by the Integration and Management Layer. As this
interface also provides common abstractions, albeit possibly not to the level of a general, technology-
independent information model, it is an alternative option for applications that require this more device-
specific level of interaction.
The Wise-IoT architecture enables the federation of Wise-IoT System instantiation, i.e. in this way
applications can access information across these instantiation. Ideally, this is done completely
transparently, e.g. by always explicitly providing a geographic scope. In this case the federating
component can identify the relevant instantiations. This fulfils REQ5, the support of transparent access
to local & remote information. As this is independent of where the user is currently located – as long as
the access to its federation component is available – it also fulfils REQ6, the transparent access to local
and remote information for roaming users.
The semantic perspective plays an important role for Wise-IoT as it enables the interoperability between
the different layers. For the higher layers, the explicit representation of semantic information is required
to support semantic interoperability. As many technologies in the Data Collection and Device Actuation
Layer do not directly support explicitly representing semantic information, the Integration and
Management Layer has to support semantic annotation functionality and the semantic information must
be at the core of the Information Access Layer. Thus REQ4 is supported. The Knowledge Processing and
Application Layers then make use of the semantic information.
The Information Access Layer allows applications to specify what information they are interested in, thus
REQ7 is fulfilled. The Integration and Management layer has to support the integration and management
of devices in the Data Collection and Device Actuation Layer, hence REQ8 is also fulfilled.
Wise-IoT is building on security standards in particular with respect to authentication and authorization
in order to identify users, things, services and applications in different domains and enabling the ability
to give them proper access rights (enforcement policies, security proxy) to use protected resources in
connected IoT platforms and thus REQ9 is fulfilled.
The interactions between the Wise-IoT entities especially between the system and users call for ensuring
that exchange of data or information between the users and the system can be trusted so that users are
guaranteed trustworthiness of data especially context data. The monitoring and evaluation of such
High-Level Architecture
24
interactions using feedback data and the quality of information supports the decision making process of
users, and especially those of the functionalities of the Wise-IoT System such as the self-adaptation
and recommendation to treat cautiously any data that is considered untrustworthy. Thus, support for
trust building (REQ10) has been fulfilled.
Technology Plan: Protocols, Standards and Technologies
25
3 Technology Plan: Protocols, Standards and
Technologies
After introducing the Wise-IoT high-level architecture in Section 2, Section 3 introduces the protocols,
standards, technologies and the components build from these that are used to instantiate the Wise-IoT
architecture. An instantiation of the Wise-IoT architecture may cover a single use case site or be
extended to federate a multitude of use case sites. These specific instantiations will be described in
Chapter 4.
3.1 Mapping Layers to Technologies
Figure 8 depicts how the components based on protocols, standards and technologies that have been
selected for the Wise-IoT platform and use cases can be used to instantiate the Layered Architecture
View introduced in Section 2.2. As we are going to show in Section 4, a subset of these components is
used in each of the pilot site deployments. The Wise-IoT applications that instantiate the Application
Layer are specific to each use case and thus are not shown in this general architecture overview.
Figure 8: Mapping Technoloigies to Layered Architecture View
In the Data Collection and Device Actuation Layer (Section 3.2) devices and edge-side platforms can be
found. In this project, there is a focus on integrating devices based on LoRa and Z-Wave, which are
introduced in Sections 3.2.4 and 3.2.5 respectively. Further devices can be connected through the GS1,
sensiNact and OCF platforms, which are introduced in Sections 3.2.1, 3.2.2 and 3.2.3. On the one hand
they integrate different other technologies and thus could be assigned to the Integration and
Management Layer, on the other hand they provide only limited management functionalities and are
primarily used for data collection. Thus they are shown with a gradient colour, but are assigned to the
Data Collection and Device Actuation Layer due to their actual use in Wise-IoT. In another instantiation
of the proposed high-level architecture a different assignment could be considered.
The Integration and Management Layer (Section 3.3) is instantiated by the oneM2M platform. oneM2M
is a worldwide standard produced by the oneM2M partnership project. On the one hand oneM2M
supports the interworking with a wide range of technologies and platforms (REQ1), providing a
Technology Plan: Protocols, Standards and Technologies
26
homogeneous interface (REQ2) to higher layers, on the other hand it supports different ways of
managing devices and connectivity. In the project, three different implementations – Mobius, Brightics
and ThingPlug – provided by different partners are going to be used. All these implementations in
principle provide the same standardized interfaces, but may differ slightly in the concrete set of features
that have been implemented.
The Information Access Layer (Section 3.4) is instantiated by FIWARE Generic Enablers (GEs) using the
NGSI Context Interfaces. The FIWARE platform has been developed as part of the European Future
Internet Public-Private-Partnership. In addition to the open specification for each GE, FIWARE has
provided an open source reference implementation. The FIWARE GEs used in Wise-IoT are the Context
Broker GE (Orion open-source implementation), the IoT Broker GE (Aeron open-source implementation)
and the IoT Discovery GE (NEConfMan open-source implementation), which are introduced in Sections
3.4.1.2 and 3.4.1.3 respectively. Whereas the Context Broker GE primarily supports a centralized
architecture, the IoT Broker GE and the IoT Discovery GE support a distributed approach and can be used
to implement a federation. All GEs are based on the NGSI Context Interfaces that have been specified as
abstract interfaces by OMA and for which FIWARE has defined an HTTP binding with a JSON-based
representation. The NGSI interface allows components of the higher layers to specify and retrieve
exactly the information required (REQ2).
The Knowledge Processing Layer is instantiated by the Self-Adaptive Recommender (SAR). The SAR can
be used by applications from the Application Layer to generate recommendations for users. The SAR
retrieves IoT data from the lower layers, and can consider the user’s preferences and feedback when
calculating recommendations. User feedback is used to compute trust values that influence future
recommendation and make the SAR self-adaptive. To fulfil its tasks, the SAR consists of a number of
loosely-coupled, distributed sub-components that have been developed in Wise-IoT Work Package 2
(with the exception of the Supersede framework that is developed in the Supersede project) and are
described in Section 3.5.1. Five components are implemented as web services: the QoI Monitor observes
the quality of IoT data, the IoT Recommender calculates recommendations, the Adherence Monitor
monitors the (non)adherence of users to recommendations, the Trust Monitor calculates trust values
between users and IoT entities, and the SAR façade hides the SAR’s complexity and partitioning from
application developers. In addition, a front end library takes care of all communication with the SAR and
includes the Supersede framework that gathers feedback from users.Due to the heterogeneity of
protocols and data representations on the one hand and the differences of core platform concepts on
the other hand, it is not possible to simply plug the different components and layers together directly.
To bridge these gaps, Wise-IoT introduces the Morphing Mediation Gateway (MMG) component, which
has been developed in Wise-IoT Work Package 2. The idea of the MMG is to have a flexible modular
component that enables translating between different protocols and data representations. For example,
from a Z-Wave sensor to the oneM2M platform or from the oneM2M platform to an NGSI-based FIWARE
enabler. While the former case may be simple and straight-forward as it connects a sensor to a platform,
the latter case is more diverse and complex as two platforms are being connected. The idea here is to
enable the continuous discovery of information in the source platform. In the case of oneM2M, semantic
annotations (REQ4) are used to provide the meta information necessary to enable the translation of
possibly raw sensor data to the NGSI entity-attribute model, for which an entity type, entity id, attribute
and possibly further attribute information needs to be derived. The “morphing” aspect of the MMG is
that it can change itself at runtime. It can download and dynamically initiates transformations. If a new
source is provided or even if information annotated using a different ontology, the MMG can check for
suitable components in its repository, dynamically instantiates them and create a translation process
for this new kind of information, without having to recompile or manually reconfigure the component.
Technology Plan: Protocols, Standards and Technologies
27
A detailed description of the Morphing Mediation Gateway can be found in the Wise-IoT Deliverable
D2.7 (Wise-IoT D2.7 – Final System, 2018).
3.2 Data Collection and Device Actuation Layer
The Data Collection and Device Actuation Layer connects to physical devices deployed in real world. IoT
devices consists mainly of sensors and actuators that gathers real time data about various aspects of our
environment. These devices can use various different wireless protocols and technologies that include
Z-Wave, Lora, RFID, etc. Wise-IoT uses oneM2M as service layer for data storage and access. This layer
contains various components that perform data translation to oneM2M after gathering it from physical
world. This section discusses working and integration of such components in Wise-IoT architecture in
detail.
3.2.1 GS1
GS11 is a international not-for-profit organization that develops and maintains global standardized
identification systems for products, assets, services, places, and organizations. GS1 standards may be
divided into three groups (9): Identify (GS1 standards for Identification), Capture (GS1 standards for
barcodes & EPC/RFID), and Share (GS1 standards for data exchange).
- Identify: provide the means to identify real-world entities so that they may be the subject of
electronic information that is stored and/or communicated by end users.
- Capture: provide the means to automatically capture data that is carried directly on physical
objects, bridging the world of physical things and the world of electronic information.
- Share: provide the means to share information, both between trading partners and internally,
providing the foundation for electronic business transactions, electronic visibility of the physical
and digital world, and other information applications.
1 GS1, The Global Language of Business, https://www.gs1.org/
As one of the Data Collection and Device Actuation Layer technology, OCF interworks with oneM2M and
this interworking has been specified in oneM2M (oneM2M TS-0024 oneM2M-OCF Interworking, 2018).
This specification provides means to oneM2M applications to use OCF devices and its services.
Since both system is designed in RESTful, the interworking can be done as resource mapping in principle.
When the OCF-oneM2M interworking proxy is initiated, it discover and exposes OCF devices in oneM2M
platform as oneM2M resource. Then those OCF resources in oneM2M platfrom can be used by oneM2M
applications (e.g. controlling OCF devices).
For example, in Figure 15, when a oneM2M application wants to turn on OCF light bulb what is exposed
to oneM2M system, it creates an instance under the container that represents the OCF light switch
resource of a OCF light bulb. That new instance creation gets notified to the proxy and then the proxy
translates that notification into OCF request message to send it to the targeted light bulb.
Figure 15: OCF-oneM2M Interworking Architecture
Technology Plan: Protocols, Standards and Technologies
35
3.2.4 LoRa
LoRa (short for Long Range) low powered wide area wireless communication technology covering
several killometers as its coverage. As a trade-off its bit rate is quiet low (0.25 ~ 22kbps) so it is suitable
for IoT services with small payloads and low time sensitivity (e.g. metering). LoRa is deployed by
operators and especially in South Korea, it has been deployed nation widely.
The communication between LoRa devices and gateways are non-IP. When a LoRa message was sent
from the gateway toward the IoT platfrom, it is sent to the gateway then the gateway forward it to the
platfrom over IP.
3.2.4.1 Mapping to Wise-IoT Architecture
To support bi-directional communication in Wise-IoT between LoRa devices and oneM2M system, LoRa-
oneM2M proxy has been designed. The proxy bridges non-IP and IP communication in between while
translating LoRa message parameters into oneM2M resource path for core APIs (e.g. <contentInstance>
creation). As a setup, the proxy exposes LoRa devices per its Application EUI (Extended Unique Identifier).
For example, LoRa parking sensors are represented in oneM2M platform as children resources of a
specific AppEUI container. Each device container then has uplink and downlink sub-containers to enable
bi-directional communication in end-to-end manner.
Figure 16: LoRa-oneM2M Interworking Architecture
3.2.5 Z-Wave
Z-Wave is a low powered wireless communication protocol that is primarily used in home automation.
Due to its ability to deal with small messages efficienty, it is widely used in the IoT environment. The Z-
Wave automation system is controlled via the Internet with a Z-Wave gateway that serves as Z-Wave
controller. Multiple Z-Wave devices can be connected to a single controller. The Z-Wave controller helps
in getting data from registered devices (e.g. sensors).
The Z-Wave-oneM2M compoenent translates Z-Wave data to oneM2M standard format and send to
oneM2M service layer. Data from the Z-Wave devices are gathered by the Z-Wave Driver (an application
for specific Z-Wave device) residing on gateway with the assistance of Z-Wave controller. The Z-Wave-
oneM2M component collects data from Z-Wave Driver and then performs data translation. Data from
multiple Z-Wave Drivers can be managed by a single Z-Wave-oneM2M component. Z-Wave Driver is
Technology Plan: Protocols, Standards and Technologies
36
needed for a specific Z-Wave device in order to collect its data. Fig. 10 shows working of Z-Wave-
oneM2M component.
Figure 17: Z-Wave-oneM2M Component
3.2.5.1 Mapping to Wise-IoT Architecture
In the Wise-IoT architecture, data from the Z-Wave devices is gathered in Device Collection and
Actuation Layer. Z-Wave-oneM2M integrates in Integration and Management Layer through MMG
Manager. The MMG manager maintains the docker repository for different oneM2M components. The
Z-Wave-oneM2M docker component resides in MMG repository. The MMG manager instantiates the
component on-demand to store translated data in oneM2M service layer. Fig. 11 shows integration of
Z-Wave-oneM2M with MMG Manager and oneM2M service layer in Wise-IoT architecture.
Figure 18: Integration of Z-Wave-oneM2M in Wise-IoT Architecture
Technology Plan: Protocols, Standards and Technologies
37
3.3 Integration and Management Layer
Integration and Management Layer is defined on top of Data Collection and Device Actuation Layer.
There are a lot of different protocols and platforms for IoT devices on the market and this is the main
reason to have Wise-IoT project demonstrating global IoT services with interoperability technologies.
oneM2M is the choice that provides interoperability framework to other technologies (e.g. GS1, Z-Wave)
in this layer. one of the benefits to adopting oneM2M standard is to integrate other systems than
oneM2M due to its resource oriented architecture design and published interworking specifications (e.g.
OCF-oneM2M interworking). Therefore oneM2M provides abstraction to heterogeneous underlying
technologies in Data Collection and Device Actuation Layer. All the thing needed in the upper layer
components is complying oneM2M standard APIs not the individual protocols and APIs.
3.3.1 oneM2M Platform
oneM2M is the global partnership project among regional standard development organizations (i.e. ETSI,
TTA, ATIS, TIA, TTC, ARIB, CCSA, TSDSI) and also stands for its technical standard name. Since 2012, to
reduce IoT technology fragmentation, oneM2M started its standardization to deliver the same standards
to those partner countries. Instead of silo platform and APIs, oneM2M provides common and horizontal
platform for different IoT domains (e.g. home, energy). Then with that horizontal platform ready not
just to guarantee interoperability via its standard APIs, but it enables time-to-market and lower cost for
further service deployments. There are open source implmentations (e.g. Mobius of KETI) and
commercial products including oneM2M certified ones.
oneM2M specification has been transposed into ITU-T Recommendations since 2017 in Y.4500 series. It
was industry standards but now it became the international standards.
3.3.1.1 oneM2M Platform as an IoT Middleware
It is easier to understand oneM2M standard with IoT Reference Model of ITU-T compared to traditional
OSI 7 layer model. oneM2M defines 3 layered model and its platform resides in Common Services Layer.
The reason why it is called Common Services is oneM2M as IoT middleware provide common functions
(e.g. device management, group access) to different IoT services. Then the application developers can
focus on service logic implementations while using oneM2M APIs for common service functions. One
key idea to understand is oneM2M applications talk to oneM2M platform. So to exchange data, for
example, between different applications, they share it via the platform using the standard APIs.
Technology Plan: Protocols, Standards and Technologies
38
Figure 19. oneM2M as Service Layer Middleware
From deployment perspectives, a oneM2M platform (e.g. one in gateway or server) provides more than
data exchange for applications. As adopted in Wise-IoT, oneM2M platform offers interworking features
and it now provides generic interworking framework for different technologies. Backend systems or
external IoT systems can interwork too over oneM2M standard and this south to north interworking
scenarios illustrates the concept of heterogeneous system integration using oneM2M.
Figure 20. Example of oneM2M integration deployment
3.3.1.2 oneM2M Common Services Functions
As explained in section 3.3.1.1, oneM2M platform as IoT middleware provides common functions in
terms of its APIs. The Figure 21 show the list of common services functions of oneM2M release 2
specifications. In Rel-3 which is going to be published in 3Q 2018 offers more functions.
Technology Plan: Protocols, Standards and Technologies
39
Figure 21. oneM2M Common Services Functions (Rel-2)
Providing common services by the platform to its applications means that platform work as applications
asked to do so. For instance, when application stores sensing data into platform so that can be consumed
by other applications, not just retrieve APIs give back the data to consumer, but also the platform
manages the data storage (e.g. maximum storage size and number of instances of a data container). In
the other example, when an application wants to fetch latest measurement of thousands metering
sensors in field, what application does is not sending out thousands of requests but querying one single
request to the platform once it configured those sensors into one group resource.
3.3.1.3 oneM2M Security Component
Access to oneM2M can be managed by validating REST API request that is supported to control a
resource and IoT device. In Wise-IoT project, oneM2M security component is developed for managing
access to oneM2M based on OAuth 2.0. Figure 22 is overview of oneM2M security component.
Figure 22. Overview of oneM2M Security Component
As described in Figure 22, oneM2M security component is built on Mobius which is one of
implementations of oneM2M, and validates REST APIs in front of Mobius. The detailed operation is
depicted in Figure 23.
Technology Plan: Protocols, Standards and Technologies
40
Figure 23. Operation of oneM2M Security Component
To use oneM2M resource, all clients (applications) must have an access token issued by oneM2M
security component based on client credentials (i.e., username and password). After the token is issued,
client can access a resource with the token.
3.3.1.4 Mapping to Wise-IoT Architecture
In terms of heterogeneous systems (e.g. device, platform) integration, oneM2M plays a pivotal role in
Integration and Management Layer. To the lower layer, Data Collection and Device Actuation Layer,
different protocols and APIs can be abstracted and exposed to the oneM2M platform. Several specific
systems (e.g. OCF, OMA LwM2M) interworking technologies have been standardized in oneM2M.
Others (e.g. Z-Wave) can be interworked following the interworking framework using oneM2M resource
driven architecture, too.
Devices and actuators in oneM2M or different systems then can be accessed via oneM2M APIs by
oneM2M applications in Application Layer or other components like Fiwware Context Broker in
Information Access Layer. Semantic features of oneM2M standards is also used to provide interworking
with the Context Broker.
oneM2M system has more value propositions however the focus in Wise-IoT is to use as interoperability
framework to the lower layer and upper layers.
3.3.2 Wise-IoT Morphing Mediation Gateway
Figure 24 a) shows the underlying concept of a Morphing Mediation Gateway (MMG). An MMG can be
used to connect one platform to another or a specific technology to a platform. The assumption is that
the interfaces are conceptually so different that one platform cannot simply access the other platform.
The core idea is that the MMG is the driver of the communication, i.e. it reads (possibly after a discovery
step) information from the source platform, transforms it to fit the information model of the target
platform and finally writes the transformed information to the target platform. With this approach,
there is no direct coupling between the platforms / platform and device.
Technology Plan: Protocols, Standards and Technologies
41
Figure 24: a) Morphing Mediation Gateway Concept b) Example Instantiation
Figure 24 b) shows an example instantiation, which is also of special importance for Wise-IoT. The source
platform is the oneM2M platform, the MMG discovers relevant sources via the Mca interface and sets
up a process for continously retrieving information. The MMG then translates the information using
either some configuration information or the semantic annotation provided in the oneM2M platform to
the NGSI data model required by the FIWARE GE, e.g. a Context Broker. It then uses the NGSI-10 update
operation to provide the translated information as entity information to the FIWARE GE.
Figure 25 shows the architecture of the MMG. At the core, there is an MMG manager that allows the
loading and configuration of different translation modules implemented as docker containers.
Depending on the source and target system, a fitting translation module can be configured and
instantiated. A repository provides the docker modules. The morphing concept is based on the idea that
the MMG can be dynamically adapted or even adapt itself during runtime: the MMG changes itself, it
morphes.
Depending on the platforms or technologies between which the translation is supposed to happen, the
modules can be relatively simple or highly complex and may even have more fine-grained adaptation
capabilities. One module that uses semantic information and fucntionalities enabling fine-grained
adaptation is the Adaptive Semantic Module, whose structure is shown in Figure 26.
Technology Plan: Protocols, Standards and Technologies
42
Figure 25: Morphing Mediation Gateway Manager
The Adaptive Semantic Module (ASM) works as follows. It has a discovery process that allows the
discovery of semantically annotated information in the source system, e.g. a oneM2M system. A
oneM2M system consists of a hierarchically structured set of REST resources. To semantically annotate
a resource, a semantic descriptor child resource is created that contains the semantic annotation in RDF.
According to the semantic annotation, the ASM checks whether a suitable translation process exists. If
this is the case, the translation process is instantiated. The translation process subscribes or if necessary
polls the information. The information in combination with the semantic annotation (meta information)
is used as a basis to derive the information necessary for the translation, e.g. to NGSI for FIWARE as the
target system. In the case of NGSI, the entity type, entity id, attribute name, attribute type and possibly
further meta information are required. For this purpose further knowledge and semantic reasoning may
be required. The ASM then creates the target information, possibly transforming the original
information into the required representation and finally it updates the information in the target system,
in this case using the NGSI-10 update operation. The process is continuously repeated for each new
information instance as long as the information is provided by the source system. If this is no longer the
case, the translation process is terminated.
Technology Plan: Protocols, Standards and Technologies
43
Figure 26: Adaptive Semantic Module
3.4 Information Access Layer
The Information Access Layer provides access to information on a higher, common abstraction level. In
Wise-IoT it was decided to instantiate this layer with FIWARE Generic Enablers implementing the
FIWARE NGSI interface. FIWARE NGSI allows applications and components of the Knowledge Processing
Layer to request information, specifying the information they need, and then get back exactly the
requested information. This fulfils REQ2. FIWARE NGSI provides the concept of Entity as an abstraction.
An Entity has an entity type and a number of attributes that provide information about the entity.
Applications can request information about a specific entity or discover entities specifying the entity
type and possibly a scope. This addresses REQ7 on discovery of information. Applications can also filter
on attribute layers. FIWARE NGSI provides both request-response or subscribe-notify interaction styles.
The FIWARE Generic Enabler can integrate information from different sources in the Integration and
Management Layer.
3.4.1 FIWARE Generic Enablers
FIWARE has been developed as the core of the EU Future Internet PPP launched by the European
Commission in 2010. The FIWARE platform has a modularized architecture based on existing standards.
The elements of the platform architecture are Generic Enablers (GEs) for which open source reference
implementations have been made available. In the following subsections we focus on some core GEs
relevant for the Internet of Things, in particular, the Context Broker GE, the IoT Broker GE and the IoT
Discovery GE. All of these GEs are based on the NGSI Context Interfaces that have originally been
developed by OMA. As OMA only developed an abstract interface, the FIWARE project developed a REST
Technology Plan: Protocols, Standards and Technologies
44
binding and proposed changes and enhancements to the original interfaces. The ETSI ISG on Context
Information Management is developing an evolution of the NGSI Context Interface. The intention is that
future versions of the FIWARE GEs will implement these evolved interfaces.
The remainder of this section is structured as follows. First, the OMA NGSI context interfaces, the
FIWARE NGSI bindings and the evolution of the interfaces are presented, which form the basis of the
FIWARE GEs relevant for IoT and their open source reference implementations which are presented in
subsequent subsections: the Context Broker GE, the IoT Broker GE and the IoT Disocvery GE.
3.4.1.1 NGSI Context Interfaces and Evolution
3.4.1.1.1 OMA NGSI Specification
In 2009/2010 the Open Mobile Alliance developed specifications for a set of interfaces, called Next
Generation Service Interfaces (NGSI) as shown in Figure 27. Among these were the interfaces numbered
NGSI-9 and NGSI-10, which deal with Context Management. In the following, only these two interfaces
will be considered.
Figure 27: OMA NGSI Interface Specifications
The NGSI Context Interfaces NGSI-9 and NGSI-10 are based on the Context Information Model depicted
in Figure 28.
Figure 28: NGSI Context Information Model
class Context Information Model
Context Entity
- EntityId: xsd:string
- EntityType: xsd:anyURI
Person Group Place Ev ent Thing
Context Attributes
- Name: xsd:string
- Type: xsd:anyURI
- Value: xsd:any
Meta-Data
- Name: xsd:string
- Type: xsd:anyURI
- Value: xsd:any
*1 *1
Technology Plan: Protocols, Standards and Technologies
45
All information is related to an entity which has an entity identifier and an entity type. Figure 28 gives
some examples of entities, e.g. a concrete real-world entity like a person, place or thing, but can also
represent more abstract concepts like groups or events.
Entities are characterized by attributes, which have a name, a type and a value. In addition there can be
any number of meta information – again represented by a name, type and value.
For example, an entity could be GroupMeetingRoom#1 (unique identifier), which is of type
MeetingRoom and which may have attributes like IndoorTemperature, Occupancy or Size. For the
IndoorTemperature (of attribute type Temperature) relevant meta information may be the Unit (Celsius
or Fahrenheit), the Timestamp of the measurement, the Provenance (sensor that measured it) and the
Accuracy of the measurement.
Figure 29 shows the operations supported by the NGSI-10 interface that is used for accessing and
providing context information itself.
Figure 29: NGSI-10 Operations
In OMA NGSI only interfaces are defined, not complete architectures. Only some very high-level
architectural assumptions are made concerning the role of components. Context producers produce
context information, context consumers consume context information and the Context Management
Component (CMC) is an intermediary that manages the context information. The CMC is a functional
component; it says nothing about the implementation and deployment of this functional component,
i.e. the functions can be implemented by multiple components and in a distributed fashion.
The update operation allows a context producer to update a context value in the CMC. The query
operation enables the context consumer to do a synchronous one-time request. An actor 1 can subscribe
for an actor 2 to be asynchronously and continuously notified whenever a certain notification conditions
is reached. Actor 1 and actor 2 can but do not have to be the same.
Technology Plan: Protocols, Standards and Technologies
46
Figure 30: NGSI-9 Operations
The NGSI-9 interface, whose operations are depicted in Figure 30, supports a distributed operation with
decentralized storage of context information. Actors can register themselves or others with the CMC,
identifying what context information they can provide on request. This means they would identify what
entities and attributes they can provide information for, but not the actual information – the attribute
values – themselves. The CMC can use this registration information to find the relevant producers of
context information when a request is received and only then retrieve and aggregate the information,
before returning it to the requester.
For this purpose, there is again a synchronous one-time discovery operation that returns the currently
registered producers potentially fitting a request and an asynchronous, continuous subscription
operation to be notified about changes regarding the availability of context producers, which can be
relevant for supporting NGSI-10 subscription under changing context producers.
3.4.1.1.2 FIWARE NGSI Binding(s)
As OMA only defined the abstract interfaces for NGSI, FIWARE had to define a binding to be able to
utilize the interfaces. The choice was a REST(-like) HTTP binding, initially using an XML serialization,
which was later replaced by JSON. Figure 31 shows the structure of the REST resources for the NGSI-10
binding in version 1.
Technology Plan: Protocols, Standards and Technologies
47
Figure 31: FIWARE NGSI-10 Binding v1
The interface was separated in two parts. One set of resources provides a one-to-one mapping to the
abstract NGSI-10 operations specified by OMA, and another set of resources is for convenience
operations that implement the REST idea, but only provide a subset of the functionalities provided by
the complete NGSI-10 operations.
Technology Plan: Protocols, Standards and Technologies
48
Figure 32: FIWARE NGSI-9 binding
As shown in Figure 32, the same approach was taken for the NGSI-9 interface.
In the course of the FIWARE project, an evolution of FIWARE NGSI was developed that corresponds to
an evolved functionality of NGSI-10 with the goal of simplifying its use for developers. NGSIv2 is currently
only supported by the Orion Context Broker implementation (see Section 3.4.1.2), which simultaneously
still supports NGSIv1. For NGSI-9 no second version has been defined.
3.4.1.1.3 ETSI ISG CIM - NGSI-LD
Recently the ETSI Industry Specification Group on Context Information Management (ETSI ISG CIM) has
published the NGSI-LD specification (ETSI, 2018). NGSI-LD represents an evolution of the previous NGSI
versions, including previous NGSI-10 and NGSI-9 functionalities. It has been developed with significant
input from Wise-IoT partners (NEC, EGM, KETI) taking into account requirements and experiences from
Wise-IoT, in particular the semantic grounding, enabling semantic interoperability, and the need for
supporting the federation of NGSI systems (see Section 4.4.1), enabling the support of remote
information access as well as roaming users.
Technology Plan: Protocols, Standards and Technologies
49
NGSI-LD uses JSON-LD for the information representation, providing a semantic grounding and to create
a seamless connection to the world of linked data and the semantic web. It is the intention that future
versions of the FIWARE GEs will support NGSI-LD.
3.4.1.2 Context Broker GE
The Context Broker GE has a centralized architecture as shown in Figure 33. The primary assumption is
that context producers update the information in the Context Broker database using the NGSI update
operation. Context consumers can query information using the NGSI query operation or subscribe using
the NGSI subscribe operation. In the latter case, they are asynchronously notified whenever the
notification condition specified in the subscription is fulfilled.
Figure 33: Context Broker Architecture
The reference implementation of the Context Broker GE is called Orion, which is available as an open
source implementation. It supports the NGSIv2 and NGSIv1 JSON bindings.
3.4.1.3 IoT Broker GE and IoT Discovery GE
The IoT Broker GE – whose architecture is shown in Figure 34 – in combination with an IoT Discovery GE
supports a distributed operation, where the actual information is stored in distributed IoT sources, e.g.
IoT Agents, and is only accessed in case the IoT Broker gets a request for which the IoT source may have
relevant information. To enable this, the IoT sources register themselves with the IoT Discovery GE,
specifying what information they can provide, e.g. that they can provide the occupancy of meeting room
A or that they can provide the speed of cars in a given area. On a query, the IoT Broker asks the IoT
Discovery for IoT sources that are possibly relevant, requests the information from each of the sources,
aggregates the information and returns the aggregated information. On a subscription, the IoT Broker
first subscribes for suitable resources, sets up subscriptions with potential IoT sources and notifies the
component to be notified whenever the notification condition is fulfilled. The typical interactions when
requesting information from an IoT Broker are shown in Figure 35.
Technology Plan: Protocols, Standards and Technologies
50
Figure 34: IoT Broker Architecture
As can be seen from the registration examples, different granularities of registrations are possible. This
represents a trade-off, i.e. the more fine-grained the registration, the more registration updates may be
needed, but the fewer IoT sources have to be asked on each request; the more coarse-grained the
registration, the more IoT sources may have to be asked on each query, but the fewer registration
updates are needed.
Technology Plan: Protocols, Standards and Technologies
51
Figure 35: Interactions required when requesting information from an IoT Broker
In order to efficiently support type-based queries, e.g. give me the speed of cars, scopes are important.
Typically not all cars are of interest, but possibly the cars within a certain geographic area. In this case,
a geographic scope can be used. IoT sources register themselves with the geographic area for which they
can provide information about entities of certain type(s). When receiving a request, the IoT Discovery
GE matches the requested scope against the registered geographic area of all registered IoT sources
returning only those for which there is a spatial overlap. This may reduce the number of IoT sources
from a large number that have information about entities of the given type, to a small number which
have information about entities of the given type within the specified geographic scope.
An IoT Broker GE with an associated IoT Discovery GE can also be used as a Federation Broker. In this
case, the IoT sources are not simple information providers, but the brokers (Context Brokers or IoT
Brokers) responsible for whole domains. These brokers would be registered with the IoT Discovery GE
on the federation level on a course grained level with their respective scopes, e.g. can provide
information about parking spots or crowd density in a certain geographic area. For example, the brokers
providing parking information for Santander and Busan could each be registered with their geographic
coverage area and applications requesting parking information from the federation broker with the
respective location scope being either in Santander or Busan would get the information from the broker
with the relevant information.
The reference implementation of the IoT Broker GE is the Aeron IoT Broker and the preferred
implementation of the IoT Discovery GE to work together with the Aeron IoT Broker, supporting
geographic scopes, is the NEConfMan implementation.
3.4.1.4 Mapping to Wise-IoT Architecture
The NGSI-based Context Broker GE and IoT Broker GE are suitable to implement the Information Access
Layer as the NGSI interface provides the right abstraction level, allowing applications to specify the
information they are interested in, so they receive exactly the information fitting the specification as a
result. As discussed in Section 3.4.1.3, the IoT Broker GE in combination with the Discovery GE can be
Technology Plan: Protocols, Standards and Technologies
52
used to implement a federation with Context Brokers or IoT Brokers as IoT sources, representing
complete domains.
3.4.2 OAuth-based Framework for Wise-IoT
3.4.2.1 OpenAM and OpenIG
OpenAM and OpenIG provide flexibility in terms of customizing user Identity and Access Management
(IAM) experience. The solution requirements include design and implementation of a highly performant,
highly available, and scalable digital identity provider service that allows system users to register their
accounts, update their profiles and credentials, use their accounts as a point of reference for identity
federation, and register/reach to other services in the federation.
Figure 36: Intercations (User-Protected reource)
The solution architecture for such an approach is depicted in Figure 36. A session is initiated by a user
browsing to a protected web resource. A Java EE OpenAM Policy Agent sitting in front of the url
intercepts the request from the client (user’s browser) and redirects the request to OpenAM
component, OpenAM will send then to the OpenAM Login Page back to the user, the user needs to
supply the credential, which the OpenAM verifies. If authentication is successful, OpenAM adds the
username of the user and his/her encrypted password to the session and sends it to Java EE Policy Agent.
A Java EE Policy agent validates the user’s session, gives control to OpenIG. Because the URL that the
client requested for the protected resource, matches a specific route (say 04-route.json). configured in
OpenIG, it applies the filters in the route configuration file. The first filter will use a shared key (also
known to the OpenAM) to decrypt the encrypted password sent by OpenAM. The second filter will
retrieve the username and password from the exchange and replaces your browser’s original HTTP GET
request with an HTTP POST login request that contains the credentials to authenticate and the third
filter will remove the username and password headers before continuing to process the exchange. The
server validates the credentials and respond back to OpenIG with user’s profile page. If the server
doesn’t have other security implementation. OpenIG will send that response directly to the End user.
Technology Plan: Protocols, Standards and Technologies
53
3.4.2.2 FIWARE Security
The security architecture of FIWARE is built around the topical areas :
Identity and Access Management
Access Control Decision and Enforcement The security architecture consists of three GEs (Generic Enabler) that together provide a comprehensive
set of services for applications to comply with major security requirements such as authentication and
authorization. Access management in FIWARE is performed as described in Figure 37.
Figure 37. FIWARE Security Architecture
The Identity Management GE in Figure 6 provides user, organization and application identity (and
credentials) management, and authentication. It complies with IETF System for Cross-domain Identity
Management (SCIM) 2.0 Specification, providing a REST API for managing user identities in multi-tenant
cloud-based applications and services. It also provides flexible management of organization-specific
and/or application-specific roles and associated permissions (on specific URLs and actions), as well as
user-role assignments. As shown on the diagram, developers (application owners) interact with the IdM
to register their applications, and manage the security of their application (credentials, roles,
authorization policy); end-users interact with the IdM to self-register, manage their profile and their
organizations. Finally, all users and client applications (e.g. service consumers) interact with the IdM for
authentication and possibly delegate access to a third-party client application (using the OAuth2 flow).
The Authorization PDP GE (PDP) in Figure 37 manages authorization policies in XACML format and
enforces decisions based on them when requested by PEPs to authorize or deny access requests to
services. Besides the interaction with PEPs, the IdM uses the PDP GE (REST API) to manage policies
defined by developers for their application and have them enforced via the PDP API when requested by
PEPs. The Authorization PDP GEri currently available in the catalogue is AuthZForce.
The PEP Proxy GE in Figure 37 plays the role of Policy Enforcement Point in the form of a HTTP reverse-
proxy in front of the protected REST services. The PEP intercepts requests to the service, then
authenticates the access request by requesting the IdM to validate the attached access token; then it
authorizes the request by requesting the PDP with the client access request information and token-
Technology Plan: Protocols, Standards and Technologies
54
related information (such as user attributes retrieved in previous step from the IdM), for the PDP to
decide whether to permit or deny based on the current authorization policy enforced by the PDP for the
requested resource. The PEP applies the PDP's decision to permit or deny the access request. If
permitted, the PEP forwards the request to the service, then forwards the service’s response back to
the client, like a reverse proxy (FIWARE., 2017).
3.5 Knowledge Processing Layer
The Knowledge Processing Layer analyses data from the Information Access Layer to provide higher level
knowledge. In Wise-IoT, the purpose of the Knowledge Processing Layer is to offer mechanisms for
ensuring trust of users and developers in the global IoT systems. Such trust enablement is important
because systems and devices become increasingly connected, and the need for personalization, the
number of points-of-failure, and the exposure to attacks increases.
The data provided by the Knowledge Processing Layer can be categorized into three types of knowledge:
i) knowledge in the form of recommendations for end-users, ii) knowledge provided to developers and
engineers in the form of insights how the systems and the user experience can be improved, and iii)
trust information. Combining these three knowledge types enables developers and engineers to manage
trust and offer users trusted experiences.
This section describes how the Knowledge Processing Layer is implemented with a Self-Adaptive
Recommender (SAR) component (Section 3.5.1) and a Trust Monitor compontent (Section 3.5.2).
Knowledge of the first two types ('i' and 'ii') is provided by the SAR: its IoT Recommender subcomponent
analyzes available IoT and context data to create recommendations for users, and the Adherence
Monitor subcomponent creates insights for developers according to the results of user monitoring and
user feedback. Knowledge of the third type ('iii') is provided by the Trust Monitor: it takes various factors
into account to calculate trust values between entities.
The output from the Trust Monitor is very valuable for the generation of recommendations and thus
also influences the generated insights. This leads to a big dependency between the Trust Monitor and
the SAR, which is the reason why the integration of the Trust Monitor into the SAR is explained in Section
3.5.1 although the Trust Monitor is described in more detail in Section 3.5.2. The combination of the
SAR and the Trust Monitor has been validated successfully in the Santander Smart City use case.
3.5.1 Wise-IoT Self-Adaptive Recommender
This section extends the corresponding section in deliverable D1.2. The first two subsections 3.5.1.1 and
3.5.1.2 are revised versions that contain some changes compared to D1.2: changes include the addition
of a frontend library that simplifies the use of the Self-Adaptive Recommender and encapsulates the
Supersede frontend library, as well as the replacement of the Supersede backend with a context broker
that provides the insights stream to developers or/and engineering tools. The second two Subsections
3.5.1.3 and 3.5.1.4 are new. They explain how the components of the Self-Adaptive Recommender map
to the theory of the Self-Adaptation and Evolution Perspective, and present implementations of the
control loop (Collect-Analyze-Decide-Act pattern (Cheng, et al., 2009)).
3.5.1.1 Approach
The Self-Adaptive Recommender (SAR) component offers mechanisms for managing trust. SAR allows
monitoring of IoT system use and offers cues about potential problems. Developers and engineers may
use these cues to adapt the IoT system and user applications by maintaining and evolving them. SAR is
Technology Plan: Protocols, Standards and Technologies
55
also using these cues for self-adaptation of recommendations that depend on the IoT system to account
for the problems that are discovered. With the help of these mechanisms trust in global IoT systems
becomes observable and, thus, manageable. Thus, the mechanisms contribute towards requirement
REQ10.
The SAR backend consists of four sub-components that carry out the monitoring and adaptation
mechanisms:
- The QoI Monitor checks quality of information (QoI) of the context data data and thereby
contributes to requirement REQ4. It enables system engineers to understand problems in data
syntax and semantics, who may adapt the data sources to comply with formatting constraints
and ontologies. Also, data that is not plausible is reported for checking by systems engineers,
possibly entailing the replacement of defective sensors.
- The IoT Recommender utilizes context information to answer user questions about the real
world that is being sensed by the IoT system. According to the Wise-IoT use cases, such
questions concern the recommendation of point-of-interest locations and the pathways for
reaching these locations. When computing a recommendation for a user, the IoT
Recommender can take the preferences of the user into account. User preferences are stored
in the user application and can be explicit selections/restrictions chosen by the user, or trust
values that originate from previous feedback of the user (see Trust Monitor).
- The Adherence Monitor monitors the use of the recommendations and collects feedback from
users if recommendations are not adhered to. Deviations to recommendations are cues
indicating that information about the real world or assumptions about the user are wrong. It
could be that a parking space is occupied even though the sensor indicates the parking to be
free, that a street is blocked even though the pathway network available to the recommender
indicates that the street is available, or that a user’s preferences have not been considered.
The component shares the gathered insights with other Wise-IoT components for self-
adaptation as well as application developers and systems engineers for informing evolution
and maintenance decisions.
- The Trust Monitor aggregates QoI information and feedback obtained from users to derive an
indicator for the trustworthiness of context data. Such knowledge about trustworthiness
supports decision-making of users. Also, the trustworthiness indicator is considered by the IoT
recommender for self-adaptation purposes, thus treating context data cautiously if that data is
untrustworthy. This process supports trust building between the IoT system and its users
(REQ10). For details, see Section 3.5.2.
The SAR backend component offers a façade that abstracts from the individual components and offers
a single point of access for components that use the SAR. As an implementation decision, Wise-IoT chose
to utilize the Supersede feedback framework to elicit feedback from end-users. Furthermore, Android
applications can benefit from a SAR Frontend Library that takes care of all communication with the SAR
backend and the Supersede framework, and performs some steps automatically. Information about
users is managed by the use case application to account for privacy requirements.
3.5.1.2 Mapping to Wise-IoT Architecture
Figure 38 gives an overview of the SAR and its integration into Wise-IoT.
Technology Plan: Protocols, Standards and Technologies
56
Figure 38: Knowledge Processing Layer featuring the Self-Adaptive Recommender (SAR). Components belonging to the SAR are colored in green, other parts of the Wise-IoT system are colored in blue.
The SAR backend offers the following interfaces for integration into the global IoT system:
- Southbound, the SAR backend interacts with the Information Access Layer (IAL) through the
NGSI interface. The Wise-IoT Morphing Mediation Gateway (MMG) offers connectivity from
FIWARE to the oneM2M Service Layer.
- Northbound, the SAR backend (or alternatively the SAR Frontend Library) interacts with the use
case application to answer requests for recommendations and offer trust-related insights. SAR
utilizes the use case application for eliciting user feedback and for managing user information.
As indicated in the figure, a use case application may bypass the Knowledge Layer and directly
interact with the IAL.
- Eastbound, the SAR backend interacts with engineering tools through a publish/subscribe
interface that offers trust-related insights. An engineering tool may be as simple as a logger that
collects the insights in a format that may be inspected by a developer or engineer. On the
contrary, it can be as complex as a big data analytics tool that feeds packages of issues to
development backlog management tools like Atlassian Jira.
To enable easy deployment and interoperability, the SAR backend component is offered in the form of
Docker containers. SAR is a RESTful component that offers REST APIs for the use case application and
engineering tools. To ease integration into a use case application, an Android SAR Frontend Library is
provided, as well as customized versions of the Supersede front-end libraries for Android and Web
applications3. Southbound, SAR expects a FIWARE ORION Context Broker. Eastbound, SAR can either use
the same Context Broker instance to publish insights, or it can use a separate instance. The SAR only
Technology Plan: Protocols, Standards and Technologies
57
needs to use the FIWARE ORION Context Broker API, which means that in this case, requirement REQ2
is fulfilled. The SAR adopted this philosophy and provides single API to end-user applications.
3.5.1.3 Self-adaptation and evolution components in the SAR
The following table shows the mapping between the components of the self-adaptation and evolution
perspective presented in Section 2.7, and the implemented SAR components.
Table 2: Mapping between component types and SAR functionality.
Component Type
Implementation in the SAR for WiseIoT
Information Sources
<External to the SAR>
Information Collectors
The QoI Monitor is subscribed for updates in the IoT context data. The Adherence Monitor collects session data such as the gps signals from the users and user feedback.
Knowledge Database
SAR backend: The Trust Monitor stores accumulated trust scores, derived from anonymous user feedback. The QoI Monitor stores its analysis results of the context data. The Adherence Monitor manages and temporarily stores the user sessions, and publishes information related to the sessions in the insights stream, such as deviation notifications and user feedback. Frontend: The trust scores of each individual user, as well as the user’s preferences, are stored in the user application for data privacy reasons.
Inference Mechanisms
The IoT Recommender takes IoT context data, user preferences, and trust scores as input and makes recommendations. The QoI Monitor takes IoT context data as input and calculates the data’s quality. The Trust Monitor takes user feedback and data quality values as input and calculates trust values. The Adherence Monitor observes users’ adherence to recommendations and calculates deviations, concluding whether a user followed a recommendation or not.
Knowledge Brokers
The Adherence Monitor publishes user feedback and deviation information in an insight stream. For this purpose, a FIWARE Orion Context Broker is used. Knowledge Subscribers can subscribe for listening to the stream and can then decide based on the received information whether they want to update the system or the user application. The Adherence Monitor forwards user feedback to the Trust Monitor. The derived trust values lead to system self-adaptation.
Knowledge Subscribers
<External to the SAR>
3.5.1.4 Control Loops in the SAR
The SAR contains three control loops following the Collect-Analyze-Decide-Act pattern (Cheng, et al.,
2009) as shown in Section 2.7. The first two loops enable self-adaptation of the SAR system. Collecting
user feedback, trust scores, user preferences and IoT data over time leads to different system decisions.
The third loop enables the evolution of the SAR system and includes the developer in the loop.
Loops for system self-adaptation
• Loop for user recommendations: this loop enables the system to adapt its recommendations to
the users’ context and preferences. [Collect] The system collects information from various
sources. The Adherence Monitor and Trust Monitor components gather user feedback, and the
Technology Plan: Protocols, Standards and Technologies
58
IoT Recommender collects user preferences and IoT data (point of interest information, the user
position, available routes, crowdedness of route segments). [Analyze] The user feedback gets
analyzed for user ratings of IoT entities and context information. The ratings become part of the
user preferences. The IoT Recommender then analyzes the collected information to find good
recommendations for the user. [Decide] Given the available data, the IoT Recommender decides
what the best recommendation for the user could be. [Act] The system presents the
recommendation to the user. The user can follow or deviate from the recommendation, and
give feedback about his/her experience. This information can then again be collected and
analyzed in the next iteration of the loop.
• Loop for mitigating quality problems: the quality of information coming from users and IoT
devices can vary. This loop especially considers the trustworthiness of the data. [Collect] The
QoI monitor collects IoT data through its subscription to updates in the Information Access
Layer, and the Trust Monitor collects user feedback. [Analyze] The QoI monitor checks the
syntax and semantics of the IoT data to analyze the trustworthiness of IoT devices. The Trust
Monitor analyzes the user feedback to obtain further information about the trustworthiness of
individual IoT devices. [Decide] The results of the analysis enable the IoT Recommender to
decide what data can be taken into account for generating user recommendations, and what
data should be ignored because either there is a quality problem with the data or the user does
not trust a particular entity. [Act] The system filters out untrustworthy data and makes sure that
the consideration of corresponding IoT devices is less likely when making a recommendation.
Loop for system evolution
Development loop: the system generates insights about user behavior that help developers in improving
the system. The Adherence Monitor observes the users (non-)adherence to recommendations, and
publishes the observations together with anonymous user feedback in an insights stream. [Collect]
Engineers and developers can subscribe to the insights stream to collect the insights. [Analyze] An
analysis of the insights helps the developers to identify potential problems. [Decide] Depending on the
analysis results, developers can come up with specific hypotheses: wrong information about a route
segment could lead to bad recommendations, the users might particularly like or dislike a specific point
of interest, there could be a usability problem in the user application, a specific IoT sensor could be
broken, etc. [Act] According to the hypotheses, developers can improve the user application, the SAR
system, or replace defect IoT sensors. Their actions will have an influence on the data that they will
receive in the next iteration of the loop.
3.5.2 Wise-IoT Trust Monitor
As the aim of many IoT services, such as those deployed on the Wise-IoT platform, is to autonomously
make decisions without human intervention, trust has been highlighted as a vital feature for establishing
seamless connectivity, secure interactions between components (as illustrated in Figure 39) and reliable
services. A trust platform thus is expected to minimize the unexpected risks and to maximize the
predictability, which helps both IoT infrastructures and services to operate in a controlled manner and
to avoid unpredicted conditions and service failures.
Accordingly, trust related components are supposed to associate all vertical layers of the IoT platform
architecture from the data collection/device actuation layer to application layer. That is, the final value
of trust of specific entity is determined not only by one single parameter but by trust matrices distributed
among users, applications, connections and devices. Moreover, this aggregated data is essential for the
Technology Plan: Protocols, Standards and Technologies
59
decision making process. In the Wise-IoT layered architecture, the trust framework allows collection of
interaction data such as feedback to provide trustwothiness of the interactiing entities. Thus, in the
architecture the trust maps vertically between the data collection and device actuation layer to the
application layer.
Figure 39: Interaction between context-aware applications and context providers via IoT context broker
To simplify its implementation and instantiation, the approach for the design of the Trust Framework
for the Wise-IoT platform, is based on the development and implementation of trust evaluation
processes comprising of some key components addressing related technical issues, as illustrated in the
implementation architecture in Figure 40. Additionally, the trust framework has been instantiated as
trust monitor and integrated into the SAR compoonent architecture in Figure 38, where it has been
deployed to provide trustworthiness knowledge of interacting entities such as users and services..
Accordingly, the following processes have been implemented as integral parts of the trust framework to
support trust monitoring in the Wise-IoT platform.