Deliverable D3.2

CPaaS.io System Architecture (v1)

H2020-EUJ-02-2016
H2020 Grant Agreement Number 723076
NICT Management Number 18302

Deliverable D3.2

CPaaS.io System Architecture(v1)
Version V1.0
January 31st, 2017

ABSTRACTThis second WP3 deliverable follows the requirement collection phase (as summarised in
Deliverable D3.1) and – as far as requirements are concerned – focuses on carrying out
the requirement analysis on the one hand and sketching a first version of the systemarchitecture, based on the output of the requirement mapping phase, on the otherhand. This document provides some elements of the used methodology and thenprovides both the Functional and Information Views, together with some Perspectives(including security and interoperability in particular). The Functional View gives a firstview about which functional components need to be implemented in order to fulfil
functional requirements. Perspectives on the other hand focuses on how (throughstrategies and tactics) the non-functional requirements can be fulfilled.
As explained in the DoW, we are using the IoT ARM methodology, which means that thisdocument features a technology-agnostic logical architecture - which is agreed upon byboth parties (Japan and EU) - in addition to two concrete instantiations of this logicalarchitecture (later referred as u2-based and FIWARE-based concrete architectures)
which are formally captured within two so-called Instantiation Views.
Finally an accompanying technical annex in the form of a Volere template, keeps track of
the functional and non-functional requirement coverage, through respectively thearchitecture Views and Perspectives. This template is the result of the requirement
process, part of the IoT ARM methodology.

This work is licensed under the Creative Commons Attribution 4.0 International License.
To view a copy of this license, visit http://creativecommons.org/licenses/by/4.0/.

H2020 EUJ-02-2016

CPaaS.io

Page 1 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

Disclaimer
This document has been produced in the context of the CPaaS.io project which is jointly funded by theEuropean Commission (grant agreement n° 723076) and NICT from Japan (management number 18302).
All information provided in this document is provided "as is" and no guarantee or warranty is given thatthe information is fit for any particular purpose. The user thereof uses the information at its sole risk andliability. For the avoidance of all doubts, the European Commission and NICT have no liability in respectof this document, which is merely representing the view of the project consortium. This document issubject to change without notice.

Document Information
EditorFrançois Carrez (UoS)

Authors

François Carrez (UoS);
A. Skarmeta, M-A. Zamora, A. Canovas (OdinS);
M. Strohbach (AGT),
S. Haller, M. Fraefel, A. Gschwend (BFH);
G. Solmaz, B. Cheng, M. Bauer (NEC);N. Koshizuka (UoT)

Reviewers

Martin Strohbach (AGT);
Katsunori Shindo (YRP)

Delivery TypeR

Dissemination
Level

PublicContractual
Delivery Date

December 30th, 2016

ActualDelivery Date

January 31st, 2017

Keywords

Requirement analysis, functional decomposition, system usecases, system architecture, concrete platform instantiations, IoT
ARM

H2020 EUJ-02-2016

CPaaS.io

Page 2 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

Revision History
Rev.

Date

Description

Contributors

v0.1

24/10/2016 Extended ToC

F. Carrez (UoS)

v0.2

21/11/2016 Revised ToC + some background sections +Arch diagram v0.1

F. Carrez (UoS)

v0.3

02/12/2016 Initial description of FCs + background sections

F. Carrez (UoS)

v0.4

08/12/2016 Update in security section

A. Skarmeta (OdinS)

v0.5

09/12/2016 Update in Requirement Section

M. Strohbach (AGT)

v0.6

16/12/2016 Update in Requirement Section

M. Fraefel (BFH)

v0.7

22/12/2016 Descriptions of FCs, FIWARE in Sections 5 & 6

G. Solmaz, B. Cheng (NEC)v0.8

04/01/2017 Integration and update to Architecture figure

F. Carrez (UoS)

v0.9

10/01/2017 Update of the Security Perspective & FIWARE
component sections

A. Skarmeta (OdinS)

v0.10

13/01/2017 Update in Sections 4 and 6

G. Solmaz (NEC)v0.11

13/01/2017 Updates in Chapter 2 and section 4.1

F. Carrez (UoS)

v0.12

16/01/2017 Reviewed Case 1c in 4.3.1.3.1

M. Strohbach (AGT)

Added intro for 4.2.1 and provided description
for 4.2.1.3
Reviewed section 4.2.6.3
v0.13

16/01/2017 Section 6.1.1 and 6.1.2

N. Koshizuka (UoT)

v0.14

17/01/2017 Update 4.2.6.1 Semantic Integration

A. Gschwend (BFH)

v0.15

17/01/2017 Update of security FCs description and FIWARE
mapping

A. Skarmeta (OdinS)

v0.16

18/01/2017 Update in Section 4.3.1

F. Carrez (UoS)

v0.17

18/01/2017 Update of FIWARE mapping table and figure in
Section 6. Update to Platform Management FC
description

G. Solmaz (NEC)v0.18

19/01/2017 Expanding the System UC section with preconfiguration UML UCs. Introduction &Conclusion. Review before submitting forreview to AGT

F. Carrez (UoS)

v0.19

25/01/2017 Review by AGT

M. Strohbach (AGT)

H2020 EUJ-02-2016

CPaaS.io

Page 3 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)v0.20

27/01/2017 Review by YRP and update of Section 6.1

Katsunori Shindo (YRP)

v1.0

29/01/2017 Integration and updates following review
comments, Version for submission to EC

F. Carrez (UoS)

H2020 EUJ-02-2016

CPaaS.io

Page 4 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

Table of Contents
1

Introduction............................................................................................................................................................................... 9

2

Methodology .......................................................................................................................................................................... 11

3

4

5

6

2.1

Introduction to the IoT ARM.................................................................................................................................... 11

2.2

Using the IoT ARM in the context of CPaaS.io.................................................................................................. 21

CPaaS.io Requirements Analysis and Mapping ......................................................................................................... 21
3.1

Summary of requirement collection phase ........................................................................................................ 21

3.2

Requirement Analysis ................................................................................................................................................. 30

CPaaS.io Views ....................................................................................................................................................................... 32
4.1

Actors involved in data production....................................................................................................................... 32

4.2

CPaaS.io Functional View .......................................................................................................................................... 32

4.3

CPaaS.io Information View ....................................................................................................................................... 40

Perspectives ............................................................................................................................................................................. 51
5.1

Security ............................................................................................................................................................................ 51

5.2

Semantic Interoperability .......................................................................................................................................... 53

5.3

Performance ................................................................................................................................................................... 53

5.4

Scalability ........................................................................................................................................................................ 53

Instantiation views ................................................................................................................................................................ 54
6.1

U2-based Instantiation View.................................................................................................................................... 54

6.2

FIWARE-based Instantiation View ......................................................................................................................... 62

7

Conclusions & Next Steps ................................................................................................................................................. 72

8

References................................................................................................................................................................................ 73

Appendix : Requirements (Volere Template) ....................................................................................................................... 75

H2020 EUJ-02-2016

CPaaS.io

Page 5 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

List of Figures
Figure 1: Simplified process leading to generating a concrete architecture ........................................................... 11
Figure 2: Simplified IoT Domain Model (feat. most important concepts) ................................................................ 12
Figure 3: IoT Domain Model (as in IoT-A D1.5 [1]) ............................................................................................................ 14
Figure 4: IoT Information Model (as in IoT-A D1.5 [1]) .................................................................................................... 15
Figure 5: IoT Functional Model (as in IoT-A D1.5 [1]) ....................................................................................................... 17
Figure 6: IoT Functional View (as in IoT-A D1.5 [1]) .......................................................................................................... 18
Figure 7: Coverage of Requirements [green-covered, dotted line–induced] vs. the functional
decomposition................................................................................................................................................................................. 31
Figure 8: CPaaS.io logical functional architecture .............................................................................................................. 33
Figure 9: UML UC for Class-I RDP pre-configuration case ............................................................................................. 42
Figure 10: UML UC for Class-II RDP pre-configuration case .......................................................................................... 43
Figure 11: UML UC for Class-III RDP pre-configuration case ........................................................................................ 44
Figure 12: UML UC for Class-IV RDP pre-configuration phase ..................................................................................... 45
Figure 13: Data production for Class-I RDPs........................................................................................................................ 47
Figure 14: Data production for Class-II RDP ........................................................................................................................ 48
Figure 15: Data production for Class-III RDP ....................................................................................................................... 48
Figure 16: Data production for Class-IV RDP....................................................................................................................... 49
Figure 17: u2 Architecture (ucR focus) ................................................................................................................................... 56
Figure 18: u2 architecture (IoT Aggregator focus)............................................................................................................. 57
Figure 19: u2 architecture ("Omotenashi" Cloud focus) .................................................................................................. 58
Figure 20: IoT Engine with IoT Engine Open Platform ..................................................................................................... 58
Figure 21: uID architecture ......................................................................................................................................................... 59
Figure 22: Matching of the u2 components to the CPaaS.io Functional View........................................................ 60
Figure 23: FIWARE-based architecture ................................................................................................................................... 66
Figure 24: Matching of the FIWARE components to the CPaaS.io Functional View ............................................. 68
Figure 25: Interactions of the FIWARE FCs............................................................................................................................ 68

List of Tables
Table 1: List of Non-Functional Requirements .................................................................................................................... 26
Table 2: List of Functional Requirements .............................................................................................................................. 28

H2020 EUJ-02-2016

CPaaS.io

Page 6 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

List of Acronyms
AcronymAEAPI
BC
IoT ARM
CapBAC
CEP
CP-ABE
CPU
CRM
CSF
CSV
DC
DoW
FC
FG
FREQ
FV
GE
GUI
HFDS
HSM
IdM
IoT
IoT-A
JSON
KAT
IV
LOD
M2M
MPU
NFREQ
NGSI
OMA
OMG
PAP
PDP
PDS
PE
PKI
RDF
RDP
RTOS
SCIM
SCP
SotA
SPARQL
SSN

Definition
Augmented Entity
Application Programming Interface
Business CaseIoT Architectural Reference Modelcapability-based access control model
Complex Event Processing
Ciphertext-Policy Attribute-Base Encryption
Central Process Unit
Customer Relationship Management
Common Service Function
Comma Separated Values
Design Constraints
Description of Work
Functional Component
Functional Group
Functional REQuirement
Functional View
General Enabler
Graphical User Interface
Highly Functionally Distributed System
Hardware Security Module
Identity Management
Internet of Things
Internet of Things – Architecture
JavaScript Object Notation
Knowledge Acquisition Toolkit
Information View
Linked Open Data
Machine to Machine
MicroProcessor Unit
Non Functional REQuirement
Next Generation Service Interface
Open Mobile AllianceObject Management Group
Policy Administration Point
Policy Decision Point
Personal Data Store
Physical Entity
Public Key Infrastructure
Resource Description Framework
Raw Data Producer (or Provider)
Real-Time Operating System
System for Cross-domain Identity Management(ETSI) Smart Card Platform
State of the Art
SPARQL Protocol and RDF Query Language
Semantic Sensor Network

H2020 EUJ-02-2016

CPaaS.io

Page 7 of 78

Deliverable D3.2

UC
VE
VRM
XACML

CPaaS.io System Architecture (v1)

Use-Case
Virtual Entity
Vendor Relationship Management
eXtensible Access Control Markup Language

List of Editing Shortcuts
Shortcut
e.g.
etc
feat.
h/w
i.e.
incl.
p/f
resp.
s/w
tbd
vs.
w.r.t.

Definition
exempli gratia – for example
et ceterafeaturinghardwareid est – that isincludingplatform
respectively
softwareto be discussed/decided
versuswith respect to

H2020 EUJ-02-2016

CPaaS.io

Page 8 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

1 Introduction
This Deliverable D3.2 is an incremental document that provides a preliminary version of the CPaaS.io
platform architecture, complemented in M15 (resp. M35) by D3.3 (resp. D3.5).
Following a global iterative and incremental approach, this version of the architecture provides a firstconsistent view that focuses on the main aspects and components of the platform. Additional and more
complex aspects like for instance federation, semantic integration, task composition and deployment are
kept for the next iteration after consolidation and refinement of requirement analysis v2.
In CPaaS.io project, we are reusing the architectural approach promoted by the IoT-A FP7 project called
the Internet of Things Architectural Reference Model (IoT ARM). As we explain in Section 2, the IoT ARM is
not an IoT architecture as such; instead it provides a whole methodology and framework for creatingsuch an IoT Architecture.
While an architecture team usually uses the IoT ARM for creating one single concrete architecture
considering one single use case (targeted product), CPaaS.io has to face an additional difficulty as the
project will produce two different concrete platform architectures: one for the Japanese side, based on
u2 technology and a second one for the European side based on FIWARE. The IoT ARM is therefore atool that helps the two involved communities for reaching common understanding and agreeing on themain architecture principles. The scope of this agreement includes:
•
•
•
•
•

•

A taxonomy of concepts (Domain Model);A logical structure for dealing with information (Information Model);A functional decomposition into logical components (Functional View);
System use-cases that illustrate interactions taking place between functional components forsome typical platform usage (Information View);
A strategy for ensuring interoperability, since the two concrete instantiations of a common“abstract & logical” platform architecture must eventually talk with each other and understandeach other in order to implement the interoperability and federation principles described as oneof the main technical objectives of the CPaaS.io project;
Strategies for ensuring additional system qualities (Perspectives).

The two later aspects – fully developed in the second iteration of the architecture- are usually dealt with,
with the adoption of common or compatible design and technology choices (e.g. adopting RDF as asemantic data internal format and JSON-LD for serialisation) and the definition of common interfaces(e.g. adopting REST, SPARQL etc.).
Finally this document is accompanied with a technical annex (Volere template) that summarises thefunctional and non-functional requirements resulting from earlier project activities (see D2.1 [2] and D3.1
[4] for more detail about Requirement collection and analysis).
This deliverable is then structured as follows.
Section 2 gives an introduction to the IoT ARM and in particular details the process part of the IoT ARM
methodology, focussing on requirement engineering, views and perspective definition.
Section 3 focuses on requirements and provides some insights about the analysis of requirements
collected earlier form the scenario holders on the one hand and on the other hand on functional/nonH2020 EUJ-02-2016

CPaaS.io

Page 9 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)functional requirements as seen from the platform perspective. It also shows the current coverage of theset of requirements by the functional decomposition discussed in Section 4.2.
Section 4 provides the initial views of the CPaaS.io architecture. The functional view depicts and describes
a preliminary functional decomposition following the IoT ARM layered Functional Model, while theInformation View, at this stage, mainly consists of a collection of system use-cases that describe inter-FCs
interactions for a selected set of basic activities at platform level, involving not only the platform, but
additional actors like platform clients and data producers as well.
Section 5 consists of the architecture Perspectives and gives insights about how the different nonfunctional properties of the system will be dealt with.
Section 6 is an important section that bridges the common logical and abstract view upon the CPaaS.io
architecture to two distinct instantiations of it. It describes in particular the various reused components(u2- and FIWARE- based technologies) and spots some new ones, which will be in the centre of CPaaS.io
specific software developments. It also shows how the concrete sets of components maps to the abstract
and logical functional decomposition.
Finally Section 7 provides a conclusion and in particular gives some hints about the few limitations andgaps of this preliminary version. It also details next steps towards CPaaS.io architecture v2.

H2020 EUJ-02-2016

CPaaS.io

Page 10 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

2 Methodology
2.1 Introduction to the IoT ARM
The IoT ARM methodology (see an overview of the whole process in Figure 1 below) covers the full
requirement process as introduced and described already in D3.1 [4], but also covers everything about
elaborating architectural Views and Perspectives. In the following sections we remind some aspects of
the requirement process (the one covered in D3.2) and introduce the Reference Model and Reference
Architecture (which ultimately makes the system architecture).

Figure 1: Simplified process leading to generating a concrete architecture

In this picture we have preliminary activities which start with the elaboration of architectural views(Physical Entity and Context Views – see Sections 2.1.4.3 & 2.1.4.4 for more details about those views)
that are depending on the scenarios and which basically describe in detail the aspects relating to IoT(what are the objects, what are the properties of interests, what is the hardware needed for capturing
those properties, how do we virtualise those objects, what are the actors outside the system and how dothey interact with the system etc…). Then based on those scenario specific information and businessconsiderations, we start a Requirement Process. This process is described in former deliverables D2.1 andD3.1 [2] [4] and consists of 3 steps: requirement collection (tackled in the two deliverables aforementioned), analysis and mapping (see sub-sections below). Finally starts the elaboration of remainingarchitectural Views (Functional, Information, Instantiation and Deployment & Operation Views 1).
2.1.1 Requirement Analysis
As soon as the raw material has been collected (see D2.1 and D3.1) there is a need for reviewing thoserequirements, removing duplicates, unifying/factorizing similar ones and translating/rewriting all
requirements using unified terms and concepts as introduced within the IoT ARM (Domain Model inparticular). The result of this phase is a collection of unified system requirements collected andsummarised within the Volere template (which is a technical annex to this document).

1

Deployment & Operation will be called Deployment View in the rest of this document

H2020 EUJ-02-2016

CPaaS.io

Page 11 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

2.1.2 Requirement Mapping
Functional unified requirements need to be mapped to the Functional View (FV) where one or more
Functional Groups (FG) and Functional Components (FC) can be identified. This will result into a firstfunctional decomposition of the targeted system. Some of the non-functional requirements can bemapped to the Information and Deployment Views. The CPaaS.io requirement analysis and mapping arecovered in Section 3.
2.1.3 IoT Reference ModelIn the IoT ARM methodology, the IoT Reference Model (RM) consists of a set of models which are used todescribe aspects of the IoT field which are meant to be agreed upon by architecture team members. In
the context of CPaaS.io we consider – for sake of simplicity – only three of them, namely the IoT Domain,
Information and Functional Models.
2.1.3.1 IoT Domain Model
The purpose of the IoT Domain Model (DM) as proposed by IoT-A [1] [7] is to introduce the concepts
pertaining to the IoT domain (see Figure 3 below) and the different relationships between thoseconcepts. Among the different concepts introduced by the DM, it is important to remind of the following
main ones (see a simplified view of the Domain Model in Figure 2 below):

Figure 2: Simplified IoT Domain Model (feat. most important concepts)

Physical Entities (PEs): Physical Entities are the objects from the real world that can be sensed and forwhich different aspects can be measured. They are virtualized in cyber-space using Virtual Entities.
Examples of PEs from the CPaaS.io project include people and geographical areas.
Virtual Entities (VEs): VEs are at the heart of an IoT system. They represent the PEs in the virtual world.
Aspects of the PE are captured by VE properties, and using sensors and actuators allows one to bridge
the physical and logical worlds and then to act on (or read about) properties. At the level of the VE, wewill consider a special kind of service, called a VE Service, which is used to manipulate or access those
properties. It is important to mention here that it is not compulsory that data providers provide
modelling of PEs into VEs and manage the associated VE Services. However it is highly important that
CPaaS.io provides the means for doing so. Actually the activity of defining VEs and their associatedproperties and then binding these properties to sensor readings for instance can be endorsed byadditional CPaaS.io actors bringing higher level of abstraction and added value services to the end-usersof the CPaaS.io platforms.
H2020 EUJ-02-2016

CPaaS.io

Page 12 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

IoT Devices: In CPaaS.io, IoT devices are the hardware supporting the sensing and actuation functions.
Micro-controllers, batteries, ROM memory etc. are also devices (but without the IoT prefix).
IoT Resources: IoT Resources are the software embedded in IoT Devices that provides the raw readings(for sensors) and actuations. The IoT Domain Model advises not accessing directly resources, but on thecontrary to access corresponding Resource-centric IoT Services (see below).
IoT Services: We can consider different kinds of IoT services depending on their level of abstraction:••

Resource-centric IoT services (r-IoT Service) are exposing the IoT Resources using
standardized interfaces and possibly adding metadata to the raw reading available at theresource level. They all connect to a sole resource (sensor or actuator). For instance getting
the reading of a temperature sensor (e.g. via a REST interface) is accomplished through an rIoT Service;
VE-centric IoT Services (ve-IoT Service) are associated to the VEs and are used for accessing
VEs attributes/status or to access VE-level services not directly connected to VEs attribute orsituation. In the Functional View the VE Service FC deals with such accesses. Getting the valueof the “hasTemperature” property of a room VE is an example of a ve-IoT Service.

Note: In the rest of this document IoT Services and VE Services are to be understood as respectively rIoT Services and ve-IoT Services.
Both kinds of IoT Services described above should be associated with service descriptions that can beused to discover particular sensing/actuation capabilities (as recommended by the Information Model).
Services: Services (without IoT prefix) are associated to VEs but do not relate to specific properties as
illustrated in the example above. Services are not part of the IoT Domain Model but could be added to
the global picture for the sake of clarity. For instance autonomous objects (with cognitive capabilities)
may expose services that do not relate de facto to any of their VE properties.
User: Different kinds of users are expected to interact with the CPaaS.io platform.

H2020 EUJ-02-2016

CPaaS.io

Page 13 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

User
0..*

0..*

invokes /subscribes
Human
User
DigitalArtefact

interacts
with
ActiveDigitalArtefact

contains

Passive
DigitalArtefact0..*Augmented
0..*
Entity1..*0..*Serviceisassociated
with

0..*

XOR

1

contains
contains
0..*0..1 Virtual

exposes1..*1

1
represents

Entity

0..1
0..*

1

1..*

0..*

0..*

is
attached
to

0..*

0..*
PhysicalEntity0..*0..*0..* 0..10..*
contains
Resource0..*is0..* associated
with

0..1
hosts

0..*

0..*
monitors

Device10..*
Network
Resource

On-Device
Resource

0..*
Actuator

Tag

reads
0..*

0..*
has Information
about / acts on

Sensor0..*
identifies

0..*
acts
on

Colour Scheme

Animate objects (humans, animals etc.)
Hardware
SoftwareNot clearly classifiable (e.g., combination)

Figure 3: IoT Domain Model (as in IoT-A D1.5 [1])2.1.3.2 IoT Information Model
The Information Model (IM) (see Figure 4 below) focuses on the description of the structure of Virtual
Entities as a representation in the cyber space of Physical Entities. The representation of the information(either it is encoded in eXtensible Markup Language - XML, RDF, binary or any other format) is kept
away from the Information Model and left to the architect’s choice, as part of the semanticinteroperability perspective.
The central part of the IM (referring to Figure 4 below) consists of the structure of the VirtualEntity
which is modelled using a set of Attributes and which are associated (via the Association
relationship) to the so-called Service Description. These associations are essential in the IoT IM as
they make the binding between a VE property – which as the name suggests is at the VE level – and acorresponding IoT Service (meaning a service exposing an IoT Resource), which is at the resource level.
H2020 EUJ-02-2016

CPaaS.io

Page 14 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)This association must be managed in a dynamic way so that the binding between a VE property(attribute) and an IoT Resource (via an IoT Service) can vary in time.
The Attribute is the aggregation of one-to-many ValueContainers. Each of those containers
contains one single Value and one-to-many MetaData (e.g. time stamp, location, accuracy, etc.).
VEs are described using a ServiceDescriptions where each Service would be characterised (e.g. by
its interface) or any useful information that a look-up service can exploit.
As an IoT Service is exposing IoT Resources, which are themselves hosted by IoT Devices, the IM
authorises ServiceDescription to contain 0 to many ResourceDescription(s) and Resource
Description to contain 0-to-many DeviceDescription(s). The structure of descriptions is notconstrained by the IM and therefore left to the architect’s own choice.
Value

1

VirtualEntity
entityType
identifier

ValueContainer

Attribute
attributeName
0..* attributeType1..*

Association
serviceType0..*
Service
Description

MetaData
metadataName
metadataType
metadataValue

metadataMetadata

0..*

0..*
DeviceDescription

Resource
Description
0..1

Figure 4: IoT Information Model (as in IoT-A D1.5 [1])2.1.3.3 IoT Functional Model
The Functional Model (FM) (see Figure 5 below) proposed by IoT-A corresponds to a service-oriented
approach of IoT. It identifies 7 main Functional Groups (FGs) and 2 additional ones that are kept outside
the scope of the IoT ARM. The purpose of the section is to introduce the different layers (FG) of the FM
as they are central to the functional decomposition achieved later on in the Functional View (see Section
4.2).
The Functional Groups are defined as follows [1]:H2020 EUJ-02-2016

CPaaS.io

Page 15 of 78

Deliverable D3.2

•

•

•

•

•

•
•

CPaaS.io System Architecture (v1)

IoT Process Management FG: The purpose of this FG is to allow the integration of process
management systems with the IoT platform. For example, the formal definition of a task-based
application (supported by CPaaS.io platform) would fall into this category;
Service Organisation FG: This FG is responsible for composing and orchestrating services, acting
as a communication hub between other FGs. The execution of an application described within the
IoT Process Management FG would take place in this FG, like any other kind ofchoreography/orchestration engine;
Virtual Entity FG: This FG relates to VEs as defined in the IoT Domain model, and contains
functionalities such as discovering VEs and their associations with IoT Services. This FG also allows
access to the VE Service offered (formally “associated with”) by a Virtual Entity. In CPaaS.io those
VE Services can be accessed via a VE endpoint;
IoT Service FG: The IoT Service FG contains functions relating to Resource-centric IoT Services.
Those services expose the resources like sensors and actuators and provide the means for reading
sensor values or setting actuation. It also contains storage capability functionality. Morespecifically the IoT ARM states that: “A particular type of IoT Service can be the Resource history
storage that provides storage capabilities for the measurements generated by resources”;
Communication FG: The Communication FG is used to abstract the communication mechanisms
used by the IoT Devices. Communication technologies used between applications and other FGs
is out of scope for this FG as these are considered to be typical Internet technologies. A central
message bus offering publish/subscribe functionalities would also be part of this FG as we will see
when describing the CPaaS.io Functional View;
Security FG: The Security “transversal” FG is responsible for ensuring the security and privacy of
IoT- compliant systems. The management of security itself is also part of this FG;
Management FG: The Management “transversal” FG contains components dealing withconfiguration, faults, reporting, membership and state. It should be mentioned here that this FG
works in tight cooperation with the Security FG.

H2020 EUJ-02-2016

CPaaS.io

Page 16 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

Application

IoT
Process
Management

VirtualEntityIoTServiceSecurity

Management

ServiceOrganisation

Communication

DeviceFigure 5: IoT Functional Model (as in IoT-A D1.5 [1])2.1.4 IoT ARM Views
The IoT ARM comes with a comprehensive list of architectural Views (see Figure 1). However not all Views
will be touched in this document; the description of the CPaaS.io-related Physical Entity and Context
Views, which are scenario specific will fall in the scope of deliverables relating to scenario
implementation.
2.1.4.1 Functional View
In this section we provide a reminder (see Figure 6 below) of the “native” IoT-A Functional View as it
shows an illustrative example of functional decomposition resulting from a thoroughly conducted
requirement analysis (in that particular case it was the analysis of the IoT-A requirements coming fromthe different stakeholders resulting into the final list of UNIs [20]). We recommend referring to the IoT
ARM final architecture deliverable D1.5 [1] in order to get more detail about the purpose of each of the
Functional Components shown in that Functional View.

H2020 EUJ-02-2016

CPaaS.io

Page 17 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

Application

Management

ServiceOrganisation

IoT
Process Management

Virtual Entity

IoT Service

Security

Process
Modeling

Configuration

ServiceComposition

Fault

Service
Orchestration

Reporting

Process
Execution

Authorisation

Key Exchange &Management

VE & IoT
Service Monitoring

Service
Choreography

Trust & Reputation
VE Resolution

VE Service
Identity Management

MemberIoT Service
Resolution

State

IoT Service

Authentication

Communication
End To End
Communication

NetworkCommunication

Hop to HopCommunication

DeviceFigure 6: IoT Functional View (as in IoT-A D1.5 [1])Along with a description of the FCs within FGs it is equally important to get a concise – still precise –description of the different FCs implemented in the various data producers (which step outside the
CPaaS.io platform) and to understand also very clearly how they interact with and position w.r.t. othercomponents. At this point in time we concentrate on a clear textual description, but in the architecture
document System Use-Cases (UC) (see Section 4.3.1) we will formally elucidate those inter-component
interactions.
The CPaaS.io Functional View will be based on the native IoT (native) Functional View but will also
introduce those additional FCs which aim at capturing the CPaaS.io specifics.
2.1.4.2 Information View
We use the following various viewpoints for describing the information view:•

Information flow: shows how information flows between FCs;•

System use-cases: elucidate usage patterns and explicitly shows interactions between FCs;•

Structure of information: in the case of CPaaS.io we will describe the used ontologies andstrategies for storing of information;•

Sequence diagrams: temporal sequences of interactions between FCs using e.g. the UML
notation.

2.1.4.3 Physical Entity View
Considering a specific scenario, the PE View provides:

H2020 EUJ-02-2016

CPaaS.io

Page 18 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)•

The description of the Objects (hence so-called Physical Entities), their physical properties ofinterest and how those objects are virtualized into the cyber-spaces, explaining how the PEs are“translated” into VEs and how their physical properties can be modelled through VE properties;•

The physical association between objects and hardware devices, e.g. if a sensor is attached(touching, fixed) to the physical object or if the physical object is in the scope of a detachedsensor (e.g. a camera);•

A clear description of the information captured by devices, including meta-data.

There is no CPaaS.io Context View described in this document. Such views will be provided indeliverables relating to the scenario implementation.
2.1.4.4 Context View
According to the IoT ARM [1] and Rozanki & Woods [17] the Context View describes “the relationships,
dependencies and interactions between the system and its environment (the people, systems, external
entities, with which it interacts)” either using plain text or UML-like notations.
The concerns addressed by the Context View cover the following aspects:
•
•
•
•
•
•

System scope and responsibilities;
Identity of external entities and services and data used;
Nature and characteristics of external entities;
Nature and characteristics of external interfaces;
Other external dependencies;
Impact of the system upon its environment.

In the context of CPaaS.io, a dedicated Context View will be associated with each Scenario
implementation and therefore will be documented within deliverables relating to scenario
implementation (like for PE Views).
2.1.4.5 Deployment & Operation View
The Deployment & Operation View (or Deployment View) main purpose is to describe how the different
FCs and hardware (including gateways, sensors, actuators etc.) are deployed in the “real life” according to
specific scenarios. The Deployment View considers concrete FCs and individual scenarios and provides
the description of the concrete platform deployments (u2- and FIWARE- based) following:
1. The respective u2-based and FIWARE-based Instantiation Views (see Sections 6.1 and 6.2);
2. any additional deployment of components needed for implementing the scenarios (see the cases
relating to Class-I to Class-VI data providers, where some existing infrastructure do exists outside
the CPaaS.io platform).
Like for The PE and Context Views, the Deployment View is scenario specific. Each CPaaS.io scenario shalldescribe, using a Deployment View, how it is physically deployed in the field (with information about
infrastructure at the RDP side, network, storage and computing resources, including FCs that are part ofthat Scenario-specific infrastructure (e.g. Semantic Annotator, Resource Manager, Data and Service
endpoints…)).
2.1.5 IoT ARM Perspectives
According to Rozanski & Woods [17] an architectural Perspective “is a collection of activities, tactics andguidelines that are used to ensure that a system exhibits a particular set of related quality properties that
require consideration across a number of the system’s architectural views”.
H2020 EUJ-02-2016

CPaaS.io

Page 19 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

In this definition, a quality property is meant to be “an externally visible, non-functional property of asystem such as performance, security or scalability” [17].
As we can see architectural Perspectives are orthogonal to architectural Views; therefore any architecture
or design decision pertaining to non-functional or quality requirements often spans more than one
architectural View, if not all. Following the methodology from Rozanski & Woods [17], the IoT ARM
leverages this methodology and proposes to approach and structure those transversal aspects ofarchitecture using a comprehensive list of perspectives that focus on specific non-functional
requirements or desired quality properties of the architecture, with special focus on the IoT domain. The
IoT ARM proposes the following structure as far as “aspects” of an architecture are concerned:
•
•
•
•
•

•
•
•

Evolution (or Evolvability): is a quality of a system that has been designed in such a way it caneasily be adapted to new technologies;
Interoperability: ability of a system to easily interoperate with other systems at various levels like
technical, syntactical, semantic and organisational [9]Availability: ability of a system to be fully (or partly) available when required2
Resilience: ability of a system to effectively handle failure or attacks that could affect the system
availability2
Trust, Security and Privacy:o Security: ability of the system to reliably control, monitor and audit who can perform what
actions on what resources, to detect and recover from failures insecurity mechanisms andto resist to cyber attacks2o Trust: ability of a system to establish and enforce trusted relation between the different
parties involved in a system (end-users, component, data) in such a way system operation
and behaviours comply to expected oneso Privacy: ability of a system to deal with all kind of personal data and in particular to
implement reliably privacy policies about accessing, sharing that data or hiding people’s
identity
Performance: ability of a system to predictably perform its operations within its mandated
performance requirements and profile2
Scalability: ability of the system to cope with increasing demand in computing, networking,storage resulting from increasing volume of system usage2
Usability: quality that illustrate how easy a system can be used, how easy data can beapprehended by the end users, how easy the GUI is understandable and ergonomic while
maintaining efficient work

Of course the list of qualities can be updated or adapted according to architects’ needs.
Each desired quality will be then associated with a set of activities (for instance activities associated with
Trust, Security and Privacy are the collection of trust requirements, the conduction of risk and threat
analysis, the definition of a trust model, etc.
Then defining a certain number of tactics allows showing how the desired system quality can be
eventually reached. Because a tactic can span more than one view, the implementation of a tactic
through Design Choices (DC) can lead to more than one of those DCs (e.g. a tactic for realizing semanticinteroperability can lead to a collection of DCs relating to Data Structure for the Information View and
DCs relating to interfaces, storage and protocols for the Functional View).

2

adapted from [27]H2020 EUJ-02-2016

CPaaS.io

Page 20 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

2.2 Using the IoT ARM in the context of CPaaS.io
In CPaaS.io we are using the IoT ARM in order to agree, between EU and Japanese colleagues, on the one
hand about the logical functionalities (i.e. FCs) that a CPaaS.io concrete platform must provide, and on
the other hand about the nature and sequences of interactions that must take place between thoselogical functional components in order to accomplish typical actions like producing data, consuming
data etc. (i.e. system UCs).
The following Section 4 is therefore about identifying and defining all needed FCs, based partly on
functional requirements (see Section 4.2), taking as a starting point the functional decomposition
provided by IoT-A [1] and describing such sequence of interactions (see Information View/system UCs in
Section 4.3.1).
2.2.1 Views
Since Japanese and European consortia are taking different technical approaches when it comes toimplementing a concrete platform (respectively u2- and FIWARE- based), we need to provide two
additional architectural Views (called Instantiation Views), the role of which is:
1. to identify available and still-to-be-implemented u2-based (resp. FIWARE-based) concrete
components;
2. to show how that list of concrete components map to the list of logical FCs (so that we canidentifying coverage and gaps);
3. to provide an architectural view of the whole u2-based (resp. FIWARE-based) concretearchitecture, i.e. instantiation of the common ARM-driven logical system architecture;
4. to show concrete instantiations of the system UCs featured in Section 4.3.1, using the u2-based(resp. FIWARE-based) concrete components.
2.2.2 Perspectives
As far as CPaaS.io is concerned, we will need to synchronise and align, between Japanese and EU
partners, about 1/ the desired system properties or qualities and 2/ tactics to be followed, taking also
into account that two platforms based upon two different technologies (u2 and FIWARE), need to offer
the highest possible level of interoperability (interoperability being itself a perspective). The Volere
template shows an initial mapping of the non-functional requirements to the list of Perspectives listed in
Section 2.1.5.

3 CPaaS.io Requirements Analysis and Mapping
3.1 Summary of requirement collection phase
In the three following sub-sections we come back on the results of the two previous WP2 and WP3phases (achieved between M1 and M3 and concluded with respectively D2.1 and D3.1) and provide threelists of requirements:
1. Scenario requirements: requirements from the CPaaS.io scenario point of view (Section 3.1.1) as
introduced in D2.1
2. Platform requirements: functional requirements (Section 3.1.3) and non-functional requirements(Section 3.1.2) as introduced in D3.1

H2020 EUJ-02-2016

CPaaS.io

Page 21 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

The purpose of this section is then the analysis and unification of those requirements into a single list ofunified requirements (called UNIs in the IoT-A terminology). The following step will be the mapping toviews and perspectives, as explained in the previous introductory sections.
3.1.1 Scenario requirements
This section gives a summary of findings in term of scenario requirements, which still need translation
into platform functional and non-functional requirements (to be unified with the existing ones shown in
Section 3.1.2 and Section 3.1.3).
3.1.1.1 Event Management / Enhanced User ExperienceID

Description

Rationale

EUE-1

Data collection
infrastructure

All services require thecollection of real-time data

EUE-2

Metadata management

EUE-3

Visualization of personal
data

EUE-4

Data processing

EUE-5

Control over datacollection

EUE-6

Synchronized clocks
between IoT devices

EUE-7

Efficient query of user
data

EUE-10

Data sharing

EUE-11

Semantic data
integration

EUE-12

Scale to personal dataof millions of people

Sensor data can only beprocessed if it is known how
sensors were deployed ,operated, to which user, event
etc. the data relates etc.
The visualization component is
the front end towards end userthat provides him/her access toa record of his/her event
experience.
Data such as excitement levels
require processing of raw
sensor data
This allows users to be
empowered to make a decision
between what data is collected
and what services they can use
Time synchronization isrequired so that sensor datafrom different sensors can becorrelated by time
Personalized visualizations
require efficient retrieval of
media data and processed datafrom sensor streams
Users may want to share theirdata via various channels using
various platform instances
Data sharing between diverse
systems can only efficiently beachieved if the semantics of thedata are machine readable
The application will collectsensor and media data for

H2020 EUJ-02-2016

Refinement
of

CPaaS.io

Fit Criterion
Existence of adata collection
infrastructure
Method forcollecting
metadata andenriching
sensor data
Visual data
access for end
user

Availability ofanalyticalservices
UI forcontrolling useof data
Maximum clock
drift

Query latency in
msAvailability ofdata sharing
mechanisms
Ontologies fordata to besharedNumber of data
points ingested
Page 22 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

millions of people. The platformneeds to be able to efficiently
ingest, store, process user data.
EUE-13User Registration andManagement

This application offers
personalized services.

EUE-14

Semantic linking
between data anddeployment metadata

EUE-15

Semantic dataregistration

In order to display an
experience log the platformneeds to enrich data withmetadata
Data Registration: For legal
reasons some data may not be
stored by the platform directly.
Semantic Data Registration:
enables semanticinteroperability. Example 1:
User activity is available atstorage endpoint S

EUE-16Storage of semanticallyenriched personal data
streams

Semantically Enriched
Storage: data must be
discoverable and consumableby other application based on acommon ontology
Personal Data: the storage of
personal data is required forfurther processing and use byother applications

per second,
processing
latency, storage
footprint
Existence ofuser
registration
management
component
EUE-11, EUE- Enriched data1
can besemanticallyqueried
EUE-11, EUE- Semantic
1
discovery
queries (e.g.
SPARQL) can beissued returninga semantic
description how
the data can beaccessed
EUE-11, EUE- Semantic
1, EUE-7
queries can beused to query
personal datafrom theplatform

3.1.1.2 Event Management / Tokyo Public Transportation
ID
TPT-1

Description
Automated data collection
mechanism

TPT -2Multi-lingual data

TPT -3

Live data collection anddistribution

H2020 EUJ-02-2016

Rationale
Public transportation data tends to
update frequently. Efficient update ofthe data requires an automatic datacollection system (even for static datasuch as time tables and maps ofstations).
Foreign tourists may not haveJapanese language skills and needmultilingual information on public
transportation.

This use-case deals with real-time
operation information of public
transportation such as trains, busses,
CPaaS.io

Fit Criterion
Existence ofautomatic datacollection system for
publictransportation.
Ratio of multilingual
information in all
information.
Existence ofautomatictranslation system.
Existence ofautomatic collection
system andPage 23 of 78

Deliverable D3.2

TPT -4

Data format and API
standardization

TPT -5

Secure and robust
communication

TPT -6Developers' Site

TPT -7

Data License

TPT -8

Third party apps

TPT -9Services for the physicallychallenged

TPT -10User feedback collection

CPaaS.io System Architecture (v1)

an air planes. It is necessary to provide
automatic data collection mechanism
for these data.
Since public transportation is operated
by many private and public sectors,
data distribution can only be achieved
efficiently based on standard data
formats and APIs.
Public transportation is a critical social
infrastructure. Communication amongplayers of the public transportation
open data system should be secureand robust.
For the open innovation with public
transportation open data, it isnecessary to provide an open
development environment on theplatform called "developers site".
Good data license is necessary for the
deployment of the data. For the data
license, the balance between dataholders’ merits and users' merits isessentially important.
Open data is a method for thecollaboration between data holders
and application developers.
Contribution to improve quality of lifeof the physically challenged and theelder in moving in Tokyo is one of themost important objectives.
User feedback is necessary for theevaluation of the use-case experiment.

distribution systemof live operation
data.
Existence ofstandard data
format and standard
API specifications.
Existence of
cryptographic
communication
mechanism andfault tolerance
mechanism.
Existence ofdevelopers' site ofTokyo Public
Transportation
Open Data.
Existence of open
data license.

Number of third
party apps orsoftware.
Number of services
for the physicallychallenged.
Number of user
feedbacks.

3.1.1.3 Waterproof Amsterdam
ID
WA-1

Description
Data collection

WA-2

Data processing

WA-3

User hierarchies

H2020 EUJ-02-2016

Rationale
The application collects and stores datafrom different sources, including
sensors and static cadastral andinfrastructural information
A rain buffer contains a set of standard
parameters, such as type, location,
capacity. These parameters should becomplemented with lifetime usage
data, such as times/open close, amountbuffered/released, active/inactive,
filling level, battery status, etc.
Different user groups can exert
different levels of control over a device,
CPaaS.io

Fit Criterion
Existence of datacollection
infrastructure
Existence of datacollection
infrastructure

Definition of usergroups, definition
Page 24 of 78

Deliverable D3.2

WA-4

Manual control over device

WA-5

Automated control overdeviceWA-6

Adaptive control levels

WA-7

Visualisation of device status

WA-8

Operator control centre

WA-9

Push notifications

WA-10

User feedback collection

WA-11

Data harmonisation

WA-12

Physical network

WA-13

Multicast messaging

CPaaS.io System Architecture (v1)so a hierarchy between groups isestablished
Rules are set by individual users which
determine the level of control overtheir own device. Users may havedifferent preferences.
Circumstances need to be defined,
based on the various data sources, inwhich device control for user groups
are suspended and delegated to acentral user/authority
The rules and circumstances may
automatically trigger control levels as
they occur
Users can access information via agraphical front-end that displays arecord of the rain buffer status, such as
filling level
Data can be aggregated per
geographical area in order to monitor
the status of and trigger actions on anumber of devices altogether
Circumstances may trigger
communication of predefined
messages to users such as push
notifications.
Prompts in the application can be used
to manually collect user feedback.
Data collected from the various sources
needs to be useable and interpretableby the application
Data transmission is modulated with
LoRa, operated by The Things Network
network server. The application needs
to be integrated with TTN API
Bulk downlink messages may be sent
to control large quantities of actuators
at the same time.

of access rights
UI where users can
set their
preferences
Presence ofalgorithms

Control levels
definedUI that can beaccessed by user

UI for network
operator

Reception of
notifications

Collection of
feedback
Ontologies for data
to be shared
Data received inapplication server
via TTN API
Messages sent fromcontrol centre

3.1.1.4 Yokosuka Emergency Medical Care (YEM)
ID
YEM-1

Description
Data collection

YEM -2

Consensus for using medical
and personal data by city

H2020 EUJ-02-2016

Rationale
This use-case deals with real-time
operation information of such as
patients' conditions, and position of
ambulances. It is necessary to provide
automatic data collection mechanism
for these data.
The data may have direct or indirect
relations with personal information of
CPaaS.io

Fit Criterion
Existence ofautomaticcollection system

Agreement with
Yokosuka city
Page 25 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)government

YEM -3

YEM -4YEM-5

patients. Before the trial, we need tohave formal consensus with city
government on the basis of official
guidelines for personal data.
Privacy protection of patients We must provide strong dataprotection mechanism such as securecommunication and secure storage.
Low-effort for emergency
Emergency medical team staffs are
medical team staffs
doing very hard work for taking care ofpatients. It is impossible for them tospend time and effort for the operationof this system. We must realize a goodwork-flow and user interface for theteam staff.
User feedback collection
User feedback is necessary for theevaluation of the use-case experiment.

government

Existence of privacy
data protection
mechanism
Existence of loweffort mechanismand evaluation
score by the teamstaffsNumber of user
feedbacks

3.1.2 Non-functional platform requirements
Those two following tables focus on Non-Functional REQuirement (NFREQ) and Functional REQuirements(FREQ) from the platform point of view (based on DoW ‘generic’ technical objectives and challenges
pertaining to Smart City domain).
Table 1: List of Non-Functional Requirements

ID #Description

Perspective

Priority

Category

NFREQ.1

Support different service level agreements(SLA)

Scalability

SHOULD

Platform,
Infrastructure

NFREQ.2

Process services and events on a set of
distributed nodes

Scalability

SHOULD

Platform,
Infrastructure

NFREQ.3

Continuously monitor quality of service atruntimeScalability

SHOULD

Platform,
Infrastructure

NFREQ.4

Balance its load at runtime

Scalability

SHOULD

Platform,
Infrastructure

NFREQ.5

Provide high availability

Availability

SHOULD

Platform,
Infrastructure

NFREQ.6

Guarantee infrastructure availability

Availability

SHOULD

Platform,
Infrastructure

NFREQ.7

Ensure network availability

Availability

SHOULD

Platform,
Infrastructure

NFREQ.8

Be able to perform self-healing

Availability

SHOULD

Platform,
Infrastructure

NFREQ.9

Expose data and services to authorized users

Security

MUST

H2020 EUJ-02-2016

CPaaS.io

City Data,
Platform
Page 26 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

City Data,

NFREQ.10

Ensure services are always accessible toentitled users

Security

MUST

NFREQ.11

Ensure data freshness

Security,
Performance

MUST

Platform

NFREQ.12

Support access control mechanisms

Security

MUST

Platform

NFREQ.13

Have security mechanisms to protect datatransmission

Security

SHOULD

Platform,
Infrastructure

NFREQ.14

Make it difficult to spy on communicatedmessages

Security

SHOULD

Platform,
Infrastructure

NFREQ.15

Be able to perform to detect threats at runtime

Security

SHOULD

Platform,
Infrastructure

NFREQ.16

Provide trusted and secure communicationand information management

Trust

SHOULD

Platform,
Infrastructure

NFREQ.17

The platform infrastructure and services shallbe trustable

Trust

SHOULD

Infrastructure

NFREQ.18

Allow users to use free services anonymously

Privacy

SHOULD

Societal Needs,
Platform

NFREQ.19

Allow people to use free services anonymously

Privacy

SHOULD

Societal Needs,
Platform

NFREQ.20

Allow users to control which data they arewilling to provide and how their data should
be usedPrivacy

SHOULD

Societal Needs,
Platform

NFREQ.21

Keep users access-control rights/ policies
secured.

Privacy

SHOULD

Platform

NFREQ.22

Provide privacy protection for users interactingwith the platform

Privacy

SHOULD

Societal Needs,
Platform

NFREQ.23

Provide communication confidentiality

Privacy

SHOULD

Platform,
Infrastructure
Societal Needs,
City Data,
Platform,
Infrastructure

Platform

NFREQ.24

Be extensible for future technologies.

Evolvability

MUST

NFREQ.25

Provide standard interfaces for service
providers

Extensibility

SHOULDNFREQ.26

Be able to provide services in an interoperable
mannerExtensibility

SHOULD

Platform

NFREQ.27

Data must be interoperable across thedifferent parties (data / service producers)

Interoperability

MUST

Platform

H2020 EUJ-02-2016

CPaaS.io

Platform,Business Needs

Page 27 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

NFREQ.28

Provide data quality constraints for data sets

Trust

SHOULDBusiness Needs

NFREQ.29

Enable the linking of data sources acrossplatforms

Evolvability

MUST

Business Needs

Priority

Category

3.1.3 Functional platform requirements
Table 2: List of Functional Requirements

ID #Description

FREQ.1[REQ25]

Discovery and lookup service of IoT systems should allow
locating the physical entities based on geographicalparameters.

SHOULD

Discovery Look-up

FREQ.2[REQ31]The look-up service of CPaaS.io shall withhold or grantinformation depending on context such as application
involved, requesting entity, and security permissions.

MUST

Discovery Look-up

The IoT system shall enable the dynamic discovery of relevant
virtual entities and their related services based on respective
specifications.

MUST

Discovery Look-up

The IoT system shall enable the dynamic discovery of relevant
VEs and their related services based on a geographical location
scope.

MUST

Discovery Look-up

The IoT system shall enable the lookup of service descriptionsof specified services for Virtual Entities with the VE identifier as
key for the lookup.

MUST

Discovery Look-up

Object (Virtual Entities), services and resources shall besemantically described

MUSTInteroperability

FREQ.10

Any data at the platform level shall have data quality
annotations

MUST

FREQ.11

Data search and retrieval shall be achieved upon a collection of
criteria that includes location (of the Physical entity concerned),characteristics of the underlying IoT Resource reputation andthe quality of information.

MUST

Interoperability

FREQ.12The platform shall provide a SPARQL end-point for accessing
semantic information (either annotated data or semantic
descriptions)

MUSTInteroperability

FREQ.13

Any data at the platform level shall be following a accepted
set of standard schemas (ontologies)

MUST

Interoperability

FREQ.14

The platform shall be able to aggregate data from various
sources using LOD principles

MUST

interoperability

FREQ.20[REQ19]User anonymity shall be provided in order to enforce privacy(e.g. at communication level)

MUST

Security/Privacy &Trust

FREQ.3[REQ36]
FREQ.4[REQ37]
FREQ.5[REQ38]
FREQ.09

H2020 EUJ-02-2016

CPaaS.io

Trust

Page 28 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

FREQ.21[REQ81]

Personal data in servers should be ciphered by a private key.

SHOULD

Security/Privacy &Trust

FREQ.22[REQ84]

Secure storage of data should be ensured.

SHOULD

Security/Privacy &Trust

FREQ.23[REQ34]

Data owners shall be able to set access-control rights/ policies(set up by data owners) to their data stored on resources.

MUST

Security/Privacy &Trust

FREQ.24

Access-control rights/ policies (set up by data owners) should
not be published publicly.

SHOULD

Security/Privacy &Trust

FREQ.25[REQ63]

Communicated data shall remain confidential.

MUST

Security/Privacy &Trust

FREQ.26

Service providers shall be able to set access-control rights/
policies (set up by service owners) to their services

MUST

Security/Privacy &Trust

FREQ.30[REQ116]

CPaaS.IO shall be able to evaluate access request dependingon access control policies.

MUST

Security/Privacy &Trust

FREQ.31[REQ117]

CPaaS.IO shall provide an authorization policy to data, object
and service for the different users or devices.

MUST

Security/Privacy &Trust

FREQ.32

User or device as part of the platform deployment shall be
registered before using any services provided by the platform.

MUST

Management
Security/Privacy &TrustUser or device shall be identified.

MUST

Management

User or device shall be authorized to use a service.

MUST

Security/Privacy &Trust

Objects should authenticate a person or object that try toaccess its data.

SHOULD

Security/Privacy &TrustAuthentication of user or service shall be carried out by devices
before delivering data.

MUST

Security/Privacy &TrustAuthentication of user or service shall be carried out to accessa service.

MUST

Security/Privacy &TrustUser's data shall be processed only with the user's consent.

MUST

Security/Privacy &Trust

CPaaS.io should support context-aware access policies.

MUST

Security/Privacy &TrustServices shall maintain a log of the operations done by users.
This log shall not be modified by attackers.

MUST

Security/Privacy &Trust[REQ35][REQ 59]
FREQ.33[REQ60]
FREQ.34[REQ62]
FREQ.35[REQ69]
FREQ.36[REQ77]
FREQ.37[REQ 82]
FREQ.38[REQ123]
FREQ.39[REQ133]
FREQ.50

H2020 EUJ-02-2016

CPaaS.io

Page 29 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

[REQ90]
FREQ.60[REQ20]Time stamps should be supported.

SHOULD

Platform

FREQ.70[REQ131]

The IoT system shall ensure that processing of information
takes place on trusted nodes.

MUST

Security/Privacy &Trust
Load Balancing &Bandwidth
Optimization

FREQ.71[REQ132]

The IoT system should optimize the processing of information
with respect to a cost function, e.g. communication,
computation, energy, etc.

SHOULD

Load Balancing

FREQ.72

The CPaaS.io platform shall be able to provide mechanisms for
migrating tasks to nodes participating the CPaaS.io systems
according to its characteristics

MUST

Load Balancing &Bandwidth
Optimization

FREQ.80

CPaaS.io platform shall be able to perform analytics, and event
detection/prediction using “live” and historical data

MUST

Platform

FREQ.90

The CPaaS.io platform shall provide publish / subscribe
functionality and criteria for filtering in/out data based (atleast) on geographical area, data type and data source

MUST

Platform

FREQ.91

The CPaaS.io platform shall provide Complex Event Processing
techniques that are able to infer high level events out of an
incoming flow of data, based on various criteria (condition forthat event to be triggered)

MUST

Platform

FREQ.92

The CPaaS.io platform provides data validation services

MAY

Platform

FREQ.93

The CPaaS.io platform functionality to map between common
RDF identifiers and vocabularies

MAY

Platform

3.2 Requirement Analysis
The starting point of the analysis is the set of functional and non-functional requirements introduced in
the earlier sections 3.1.2 & 3.1.3. Those requirements were consolidated, then duplicates were removed
and similar ones were merged in order to minimize their number. Some of scenario-originatedrequirements were also rewritten in order to remove ambiguities and/or to extend their scope.
Then all scenario-originated requirements were examined and compared to existing NFREQs and FREQs
and then were – depending on the result – linked to existing requirements or considered as new
requirements (classified then in FREQs, NFREQs or Design Choices). Existing requirements may also be
updated in order to cover the scope of the scenario-originated requirements.
The result of this analysis consists therefore of a list of UNIs which are fully captured in the Volere
template (technical Annex to this document).
An initial requirement mapping as been also achieved, with mapping to Views, Perspectives, Functional
Groups and Functional Components.

H2020 EUJ-02-2016

CPaaS.io

Page 30 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)Many comments are also associated to those requirements and will be used to feed forthcoming
technical discussions (towards the next architecture release e.g.).
Finally the Functional Architecture in Figure 7 below shows the current coverage of the list ofrequirements by the functional decomposition (as shown in Section 4.2 and Figure 8).

Figure 7: Coverage of Requirements [green-covered, dotted line–induced] vs. the functional decomposition

H2020 EUJ-02-2016

CPaaS.io

Page 31 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

4 CPaaS.io Views
4.1 Actors involved in data production
When defining the CPaaS.io logical architecture we needed to define various kinds of situations for data
provision, resulting in various classes of Raw Data Providers (RDP) numbered along decreasing
capabilities; Class-I being fully semantics-ready while Class-IV does not own/manage any local
infrastructure therefore relying fully on CPaaS.io platform for basically everything. The various RDP
classes are described below:
•

•

•

•

•
•

Class-I RDP: This class describes and stores IoT Service/Resource semantic descriptions locally. It
also stores semantically CPaaS.io-ontology compliant data locally. It provides support fordiscovery of available IoT Service and provides a data SPARQL-compatible endpoint for querying
the locally stored semantic historical data and a REST IoT Service endpoint for invoking IoT
Services (and then accessing live data in a synchronous way). Finally it can also describe andadvertise data sets;
Class-II RDP: This class of RDP is not CPaaS.io-ready as it does not store semantics in a way thatcan be directly understood by CPaaS.io. It stores either non-semantic/or non-compatible
semantic data locally. It registers IoT Service / Resource descriptions, and eventually data set
descriptions to CPaaS.io. It provides a REST IoT Service endpoint and implements a CPaaS.iocompatible semantic annotator used to annotate and respond to IoT Service invocations. It uses
the semantic annotator in order to publish semantic data towards the CPaaS.io platform (via theCommunication Channel FC) following the Resource Manager inner publishing policy. Finally it
offers a non-semantic endpoint or non-aligned semantic endpoint for the data to be accessed
directly by the CPaaS.io client;Class-III RDP: This class of RDP does not store any data locally so it cannot answer any SPARQL
data query. As for Class-II, it publishes IoT Service/Resource descriptions to the CPaaS.io platform
and publishes (using the annotator) semantic data to the CPaaS.io semantic data repository (viathe communication channel). As it provides an IoT Service endpoint, IoT Services can be invoked(current values of sensors can be read and actuation value can be set);
Class-IV RDP: In fourth case, the RDP only manages its IoT Resources locally and relies on
CPaaS.io for everything else. In an initial pre-configuration phase it needs to upload its
production policy as well as the IoT Services exposing its IoT Resources to the CPaaS.io platform(resp. to the Resource Manager FC and IoT Service FC). It does not provide locally any direct data
endpoint, however IoT Services can be of course invoked at the platform level;
Class-V RDP: they refer in the CPaaS.io architecture to Web third parties producing live data e.g.
twitter, news feeds, RSS …;Class-VI RDP: they refer to Government data.

NOTE: The various use-cases relating to Class-V and –VI will be dealt with in the second release of the
CPaaS.io architecture.

4.2 CPaaS.io Functional View
Each sub-section below provides a textual description for each FC and a list of functionalities provided by
the FC.
Below is a first version of the logical functional decomposition featuring a tentative list of FCs which will
be confirmed, updated and extended during the forthcoming architecture iterations.
H2020 EUJ-02-2016

CPaaS.io

Page 32 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

Figure 8: CPaaS.io logical functional architecture

H2020 EUJ-02-2016

CPaaS.io

Page 33 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

4.2.1 MANAGEMENT FG
The management FG groups a set of FCs offering management functionalities in order to manage
platforms and platform federation.
4.2.1.1 Web Front-End FC
The Web Front-End FC is a component that offers a web interface to many of the FCs implemented
across the various FGs. Those components include, but are not limited to:
•
•
•
•
•

All management functionalities;
Discovery and browsing of VE, VE properties, IoT service, IoT Resources, data sets etc.;
Look-up and resolution;
Definition of access and privacy policies;
Management of credentials.

4.2.1.2 Platform Management FC
Platform Management FC is responsible for managing configurations and platform-related aspects of
CPaaS.io IoT architecture.
This component deals with both intra- and inter- platform management. Different aspects are covered
like:
•

•

•
•

Platform federation: Registration of peers and inter-peer links, definition of nature of links
between the different platform instances and the functionalities they are supporting: federated
data query, discovery, task composing spanning multiple instances, etc.;
Task deployment: in order to enable smart and flexible deployment of tasks within the platform(see the Task Deployment FC) and in particular towards the platform edge, information about theplatform components like network capacity, CPU and memory capacities need to be known at theplatform level;
Management of security across the various platform instances and domains;
Publishing of new data/knowledge or replication of data from one platform instance to another(e.g. considering a hierarchical model from leaves towards the root) in order to allow multiple
input CEP or data processing.

Platform management is an essential requirement for realization of the CPaaS.io platform due to the
distributed nature of IoT. In the CPaaS.io platform, there will be vast number of IoT Devices (e.g. sensor
nodes) and various hardware and software components. Moreover, different deployments from Japanand Europe may be connected to each other and exchange information based on the federation concept.
4.2.1.3 Resource Deployment Tool FC
The Resource Deployment component is a web-based front end for managing the deployment of IoT
Devices. It covers an inventory for managing IoT Devices and sensors and allows IoT deployment
managers to plan a deployment of physical devices including a description (location, time, floor plan) of
deployments. The tool supports both the deployment of static and mobile devices. The management ofmobile devices is realized by associations with mobile entities such as people. The data generated by thistool is used for metadata enrichment of raw data and analytic results as described in deliverable D2.2
[3]".
Deployment metadata created by the tool instantiates a deployment ontology extending the SSN
ontology (see D6.1 for further details about the ontology) and is stored as RDF triples in a triple store(deployment knowledge base) within the platform. An initial version of the deployment tool is available
H2020 EUJ-02-2016

CPaaS.io

Page 34 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)to partners in the project. The deployment knowledge base currently contains inventory and deployment
metadata for the “Color Run” event.
4.2.2 IOT PROCESS MANAGEMENT FG
4.2.2.1 Task Composer FC
Task Composer FC is a component which can be configured by developers to create necessary tasks forcertain services. In more advanced settings, tasks can be composed automatically by the Task Composer
FC itself. To execute a service, there is need for defining the set of tasks. This FC decides how many tasks
necessary for the service as well as how the tasks are organized. Examples of task includes the FCs shown as dashed rectangles in Figure 8 - that could be deployed closer to the edge for execution
depending on the node capabilities. The concept of task (and related activities) will be developed further
in the next iteration of the CPaaS.io architecture.
4.2.2.2 Process Optimization FC
Process Optimization FC is a component that decides on how to execute the processes that are requiredfor providing services. This optimization includes or relies on aspects such as the order of execution of
the tasks, the necessary inputs and needed configurations for optimized performance, as well as the
optimization algorithms for the processes. Process Optimization FC makes decisions based on improving
the performance of the processes.
4.2.3 SERVICE ORGANISATION FG
4.2.3.1 IoT Resource Manager FC
The Resource Manager FC is a component which can be configured and used by the owner of IoT
Resources (see the RDP Class-IV case) in order to manage the reading of their IoT Resources and its
periodicity.
This FC allows RDPs for defining publishing policies and relies on CPaaS.io-hosted IoT Services which are
deployed by the RDPs Class-IV and which are exposing the IoT Resources under the RDPs’ responsibility.
4.2.3.2 Service Orchestrator FC
Service orchestrator FC is the component which generates task instances and manages execution ofthese task instances based on the available resources. In order to perform this role, the Service
Orchestrator FC must know about the availability of the resources such as the cloud or edge resources(e.g., servers). It monitors the usage of resources and the status of all running tasks on the nodes.
This FC manages all the tasks and the execution of task instances over the edge nodes or cloud nodes.
Hence, the assignment of task instances to the available resources is handled by Service Orchestrator FC.
4.2.3.3 Task Deployment FC
Task Deployment FC takes the assignment from Service Orchestrator FC as an input and performs thenecessary deployment of task instances. It aims to minimize the cross-edge node and cross-site network
traffic while doing these deployments by generating a deployment plan and performs the task
deployment on the available cloud or edge resources based on a deployment plan.
4.2.3.4 Task Execution Engine FC
Task Execution Engine FC is the component that executes the tasks that are defined by the Task
Composer FC and deployed by the Task Deployment FC based on the available resources. The
instantiation of this FC is a worker that executes the necessary tasks.
H2020 EUJ-02-2016

CPaaS.io

Page 35 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

4.2.4 VIRTUAL ENTITY FG
As explained earlier in Section 2.1.3.3 this FG deals with all aspects pertaining to Virtual Entities likestorage of VE-related observations and VE/VE Service Descriptions, discovery, look-up and resolution of
VEs and VE Services, discovery, look-up and resolution of Associations and VE Service endpoint.
Functionalities shared with the IoT Service FG are handled in Section 4.2.6.
4.2.4.1 Semantic VE Data repository FC
This FC provides a database for storing VE-related data (i.e. historical data) as well as a SPARQL endpoint
for accessing that VE-related data.
4.2.4.2 VE Registry FC
VE Registry FC is the component that stores, queries and retrieves VE semantic descriptions. This FC
could be merged with the VE Resolution FC or can be implemented by a stand-alone component that is
integrated with the VE Resolution component.
4.2.4.3 VE Resolution FC
This FC is an extension of the IoT-A native component that can be used to discover and retrieve
associations existing between VEs and IoT Services. Using Associations (see Figure 4) the entity managing
VE Services can know about which IoT Services should be used in order to return the value of a VE
Property (as associations between VEs and IoT Services are dynamic in order to deal with mobility). In
addition to providing means for retrieving those associations, this component can be used to by VEs toregister their availabilities. The existing VEs that are available and registered can be discovered based on
fitting the searching criteria. This search can typically be done by the VE Service End-Point FC for
identifying the IoT Service to be triggered for answering a READ/UPDATE request upon a specific VE
property.
4.2.4.4 VE & IoT Service Monitoring FC
This component is a IoT-A native FC responsible for automatically finding new associations, which are inturn stored by the VE Resolution FC.
4.2.4.5 VE Service End-Point FC
This FC is an extension of the IoT-A native FC that provides a unique endpoint to accessing (Read/Set)
Virtual Entities and their properties. This FC is responsible for:••

Maintaining and publishing a snapshot of VE state at regular interval (sampling rate to be
configured) as VE observations which are therefore also stored within the Semantic VE Data
Repository FC;
Handling and answering requests for accessing VE properties. As explained in case 2/ in Section
4.3.1.3, answering such requests requires identifying the appropriate corresponding IoT Service
via existing associations between device-level and thing-level information.

4.2.5 IOT SERVICE FG
This IoT Service FG deals with all aspects pertaining to IoT data like storage of IoT Data, discovery, lookup and Resolution of IoT Services, invocation of IoT Services, storage, discovery, look-up and resolutionof IoT Service descriptions and IoT Resource descriptions.

H2020 EUJ-02-2016

CPaaS.io

Page 36 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)Functionalities shared with the Virtual Entity FG are handled in Section 4.2.6.
4.2.5.1 Semantic Data Repository FC
Semantic Data Repository FC is used for storing data managed at CPaaS.io level (coming from Class-II, III and -IV RDPs). This FC provides a SPARQL endpoint that can be used for searching and retrieving thedata from the database (either it is a full-fledge triple store or relational database with SPARQL
endpoint).
4.2.5.2 IoT Service & Resource Registry FC
The IoT Service/Resource Registry 3 FC provides an API for registering a Resource and the associated IoT
Services within a registry with associated metadata. This particular API can be used either by CPaaS.io
users for registering virtual resources and associated IoT services or by RDPs which do not handle locallythe definition of the IoT Services that expose their resources (see definition of Class-II, -III and –IV RDPs ).
This registry allows also to look-up IoT Services exposing IoT Resources based on various criteria(metadata).
4.2.5.3 Live Data Manager FC
This component is responsible for pulling data from external data sources (like e.g. Twitter RSS or newsfeed) and putting it in an appropriate form with needed meta-data. This FC therefore uses as well the
Semantic Integration FC and publishes related knowledge to the communication FG for other component
users to use.
4.2.5.4 IoT Service FC
This FC provides a REST endpoint for accessing resource data (resources are exposed to CPaas.io users
by IoT Services).
4.2.6 COMMON TO VE AND IOT SERVICE FGs
4.2.6.1 Semantic Integration FC
As described in D6.1, CPaaS.io will use Linked Data and RDF to facilitate integration of data fromplatforms like FIWARE and u2. Neither of the two platforms is currently supporting RDF and Linked Dataout of the box. CPaaS.io will integrate a semantic layer that enables mapping existing data to RDF.
This semantic integration layer can be implemented in different phases and levels. Initially the semantic
layer will simply expose metadata as Linked Data, using common vocabularies and best practices as
described in D6.1 [5]. This enables users to query information about available data within the FIWARE
and u2 platform as Linked Data. Access to this metadata layer will be done by providing a SPARQL
endpoint that can be queried.
In a second step, data residing in FIWARE or u2 can be mapped to RDF. For that, one needs to extend theappropriate data model used and introduced in D6.1, Chapter 3.2 [5]. In the case of FIWARE, this can bedone by using the new NGSIv2 data model that supports JSON-LD representations. By providing
appropriate tools and user interfaces, FIWARE users can thus map existing data to RDF representations.
The ucode data model of u2 is close to a RDF as it stores information in a triple-like data model. The
semantic integration layer needs to map internal ucode IDs to publicly used and dereferencable URIs,

3

This FC correspond to the IoT Service Resolution FC in Figure 6

H2020 EUJ-02-2016

CPaaS.io

Page 37 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)preferably as HTTP URIs to allow Linked Data usage. In some use-cases like the Tokyo Metro real-timedata system, this is already being done and can be used as an example implementation.
To be able to query this kind of data, a SPARQL endpoint will proxy requests to the platform. CPaaS.io
should provide a virtual-graph feature similar to what RDF graph databases provide to access relational
data using W3C standards like R2RML 4. Users should be able to run SPARQL queries on data residing in
FIWARE or u2.
If technically feasible, FIWARE and u2 could in a final step implement its own SPARQL endpoint.
Feasibility of this feature needs to be evaluated during the project runtime.
4.2.6.2 Pre-processing FC
Pre-processing groups all kinds of algorithms that could apply straight away to the raw data before it isannotated and published. More precise description about needed algorithms will be provided in the next
iteration of the architecture as soon as we get more detail about the CPaaS.io scenario developments.
4.2.6.3 Analytics FC
The Analytics FC provides a large variety of algorithms that can take as input a broad range of structured
data (e.g. video streaming, time series, t-uple series) in order to perform for instance statistical analysis,
machine learning, prediction, anomaly/event detection before publishing their result through thecommunication channel. Example of analytics (input formats, algorithms, output format) can be found in
the two Instantiation Views.
4.2.7 COMMMUNICATION FG
4.2.7.1 Communication Channel FC
The communication channel is a FC that provides a message bus with support for publish/subscribe andpublishing/consuming along topics. In the architecture it is used as a way 1/ to provide subscribers with“live data” 2/ to store data using a pre-determined topic (see UCs in Section 4.3.1)
4.2.8 SECURITY FG
The Security FG follows closely the recommendation for IoT-A native FCs as shown in Figure 6. This FG is
made of several components already identified in the IoT-A Native Functional View:•

AuthN: Authentication of CPaaS.io users;•

AuthZ: Access-Control policies, decision and enforcement;•

KEM: Key Exchange and management (including as well Group Management);•

Identity Management (including also The key/X509 certificate generation).

Those different FCs are described here after in more detail.

4

See for example R2RML implementation in Stardog: http://docs.stardog.com/#Virtual%20Graphs

H2020 EUJ-02-2016

CPaaS.io

Page 38 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

4.2.8.1 Authentication (AuthN) FC
This AuthN 5 component is responsible for enforcing the authentication of registered CPaaS.io users.
Based upon a user credential passed to the AuthN FC we can make an assertion about the identity of theuser i.e. that they are a known CPaaS.io users.
The AuthN component interacts with the User Management FC when the user registers in order toproduce the user credentials (such credentials can take multiple forms e.g. both username/password andan X509 certificate).
When access to a resource or service is requested by a user, the request is captured by a decision point
as whether to grant or deny the request based upon whether the requester is authorized to do so. At thispoint, the AuthN FC can be contacted by the decision point to assert the authenticity of the requester.
4.2.8.2 Authorization (AuthZ) FC
The AuthZ 6 component makes decisions about access control requests (intercepted at access decision
points) based upon Access Control Policies (ACPs).
Access control can be applied at the level of look up, e.g.:•

for a request to search for a list of VEs/resources in a specific domain or part of a domain
meeting some criteria; or•for direct access to resources via their interfaces.

Access is denied if the assertions made about the request and requester do not comply with the AccessControl Policy. Usually the three parameters of an access request include an assertion (data guaranteeing
for the occurrence of an authentication of a user client at a particular time using a particular method ofauthentication), the targeted resource and requested operation (read or write for instance).
4.2.8.3 Access Policy Administration FC
This sub-component of AuthZ FC provides a Policy Administration Point to the AuthZ FC where accesspolicies are defined and managed. A GUI is provided to the owner of resources who wish to protect
access; using the GUI the owner can create new access policies, attach them to resources, update accesspolicies and delete access policies.
The Access Policy Administration FC will typically be used by Raw-data producers signing up to CPaaS.io
and registering their resources. When they register a resource, they can assign an access policy (applying
a default rule e.g. all CPaaS.io users can perform a read operation on the API, or define their own policy
using the GUI).
Access Policies defined in this FC will be followed by the AuthZ component when making access control
decisions.

5
6

AuthN correspond to the one proposed in Figure 6 as part of the Security FG
AuthZ correspond to the one proposed in Figure 6 as part of the Security FG

H2020 EUJ-02-2016

CPaaS.io

Page 39 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

4.2.8.4 Key Exchange and Management FC
The Key Exchange and Management (KEM) component manages the exchange of security information
between two parties. In particular, it ensures that the keys required to construct a secure and trusted
communication channel is carried out in a secure manner.
4.2.8.5 Identity Management
The Identity Management (IdM) component takes into account the management of the identity lifecycle
and also the interoperability issues with components like Authentication, Authorization and KEM. While
the Authentication component is responsible for asserting the identity of subjects using different IoTframeworks (different identifiers, cryptographic algorithms, key strength), the IdM component must
support pseudonym creation across different identity frameworks.
The IdM component needs to interact with the Authentication, Authorization and IoT Service Resolution
component in order to provide its functionalities.
•••

Relationship with the Authentication component;
Authenticate the requesting subject;
Authenticate the subject for which a pseudonym is requested.

Relationship with the Authorization component:••

Get the access rights of the requesting subject and of the subject for which a pseudonym isrequested;
Create a new access policy associated to the pseudonym.

One of the tasks of the IdM FC is to enable security features between different IoT frameworks bycreating pseudonyms for identities pertaining to other IoT frameworks. The IdM component addresses
this kind of problems by issuing pseudonyms and accessory information to trusted subjects so that they
can operate (use or provide Services) anonymously. Pseudonyms are temporary identities of fictional
subjects (or groups of subjects) whose credentials can be used by a subject or a set of subjects wheninteracting with other subjects instead of using its own credentials. Access rights associated topseudonyms depend on those of the identities of the request issuing subject(s). As pseudonyms are
identities, they can be used in turn to request other pseudonyms.

4.3 CPaaS.io Information View
The purpose of the Information View is to provide system UCs and information about the information
structure. This second aspect of the IV will be dealt with in the next iteration of the architecture, in theform of 1/ CPaaS.io core ontology for data & VE observation, VE/VE Service/IoT Resource/IoT Service
Descriptions and 2/ scenario related domain ontologies.
4.3.1 System use-cases
This section provides a non-exhaustive list of system use-cases which are used to illustrate the accepted
platform behaviours and to reach common understanding between the various partners:••••

Configuration phase (pre-operational phase);
Production of data (depending of various cases) and sub-sequent data flows between
components;
Consumption of data (ranging to simple consumption to usage of reasoning and analytics);
Any other typical usage.

H2020 EUJ-02-2016

CPaaS.io

Page 40 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

When a common understanding is reached each single use-case needs to be “instantiated” within the
Instantiation View using concrete components (for both u2- and FIWARE-based platforms).
4.3.1.1 Configuration phases
We describe in this section all UCs that occur before operation phase:
•
•
•
•
•
•
•
•
•

To assign the platform with a unique identifier;
To define CPaaS.io clients (and actors in general);To create and configure users of the platform i.e. actors producing data, accessing data to/fromthe platform or creating/running application using CPaaS.io capabilities;
To set-up access rights between actors;
To register platform components capabilities;
To link platform instances with each other (for federation purpose);
To declare IoT services, VE services and Data endpoints (by RDPs);
To register IoT Service, IoT Resources, VE services semantic descriptions;
To implement a Semantic Annotator, the role of which is to annotate raw data in such a way it isaligned with the CPaaS.io ontology.

4.3.1.1.1 Data producer Class-I pre-configuration
In order to be either forwarded SPARQL data requests by CPaaS.io platform instances or be invoked an
IoT Service, the different endpoints (Semantic data endpoints and IoT Service endpoints) must be
declared to the platform instance, the RDP is linked to (See Figure 9 below). This also allows discovery
requests to reach Class-I RDP as they locally manage IoT Service and IoT Resource semantic descriptions.
Optionally, data sets can also be described and advertised so that data can be accessed directly at the
RDP level by the CPaaS.io client without requesting that data at the platform level and relying onfederation. Finally access-rights must be defined so that discovery, look-up and access can be eventually
granted (or denied) to the pre-registered CPaaS.io clients.

H2020 EUJ-02-2016

CPaaS.io

Page 41 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

Figure 9: UML UC for Class-I RDP pre-configuration case

4.3.1.1.2 Data producer Class-II pre-configuration
The main difference with the Class-I case is that a Class-II RDP needs to provision a Semantic Annotatorthat will be used to annotate raw data so that it complies with the CPaaS.io ontology (see Figure 10
below). As a Class-II RDP is not semantic-ready, only a non-semantic data endpoint is provided in orderto accommodate direct access by a CPaaS.io client to the locally stored raw data (following e.g. prioradvertisement of non-semantic data sets as illustrated in Section 4.3.1.3.2).

H2020 EUJ-02-2016

CPaaS.io

Page 42 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

Figure 10: UML UC for Class-II RDP pre-configuration case

4.3.1.1.3 Data producer Class-III pre-configuration
Pre-configuration for Class-III is simpler than for previous cases as they do not provide data endpoints. It
includes:•••Registration of IoT Service endpoint;
Definition of access rights;
Provision of a Semantic Annotator in order to publish CPaaS.io-compliant data

as illustrated in Figure 11 below:

H2020 EUJ-02-2016

CPaaS.io

Page 43 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

Figure 11: UML UC for Class-III RDP pre-configuration case

4.3.1.1.4 Data producer Class-IV pre-configuration
As explained in Section 4.1 RDPs Class-IV are infrastructure-less parties that only own IoT Resources.
They rely on the CPaaS.io platform for:
•
•
•
•
•

Registering their IoT Resources so that they can be discovered or looked-up;
Serving, registering and managing IoT Services that expose their IoT Service so that they can be
discovered, looked up and invoked (for synchronous live data consumption);
Pulling data from the IoT Resources;
Annotating semantically the data;
Producing the data towards the Semantic Data Repository.

The two first items of this list pertain to a configuration phase that occurs prior to any data production(which is elucidated in Section 4.3.1.3). The UML use-case below (Figure 12) explains in details thoseactions.

H2020 EUJ-02-2016

CPaaS.io

Page 44 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

Figure 12: UML UC for Class-IV RDP pre-configuration phase

RDP Class–IV have the responsibility of providing IoT Services exposing their IoT Resources, they also
provide IoT Service and IoT Resource semantic descriptions. The sequence of actions is therefore to 1/ todeploy IoT Service to the CPaaS.io (the needed IoT Service server is not shown in the architecture but
will be part of the Deployment and Instantiation Views) 2/ to register the descriptions to the IoT Service
and Resource registry FC 3/ to provide a polling policy to the Resource Manager FC.
4.3.1.2 Declaring a new platform to the CPaaS.io eco-system
For the sake of platform federation, a new platform instance needs to be known from existing CPaaS.io
platform instances. This UML use-case will be fully described as soon as aspects pertaining to federation
have been fully dealt with (architecture next release).
4.3.1.3 Production of data
There are basically two main ways to producing data:
1. Asynchronously: it is meant here that the data is produced on its own and then fed into theplatform (published, stored) at the initiative of the data producers, following its own production
policy (including sampling rate). In this scenario producers can either fully rely on platform
capabilities (we will see later on what this exactly means) or rely on their own infrastructure. In
this later case they will decide which part of the data needs to be published to the CPaaS.io
platform;
2. Synchronously (or on-demand): it is meant in this second mode, that the data will be pulled fromthe IoT Resource (i.e. sensor) only when there is a request from “the top” to receive or consume
such data, and this is done basically by triggering an IoT Service exposing that IoT Resource.
Again this case refines into two sub-cases:
o The IoT Service is triggered explicitly, i.e. through a direct call like for instance a REST GET;H2020 EUJ-02-2016

CPaaS.io

Page 45 of 78

Deliverable D3.2

oCPaaS.io System Architecture (v1)

The IoT Service is triggered implicitly whenever a platform user wants to access a VE
property (as VE properties are bound to IoT Service through the use of Associations). Thissecond case makes the assumption that the VE endpoint implements this mechanism.

If the asynchronous mode is used, accessing a VE property results in the VE endpoint retrieving the latest
stored value for the IoT Resource bound to the property via the Association. Alternatively it is possiblethat the direct invocation to the IoT Service is made in the case the RDP provides an IoT Service endpoint
as well (even if working mostly in the asynchronous mode).
Publishing of data in case 1/ is made through the Communication Channel which offers
publish/subscribe functionalities. Implicit storage can be achieved when publishing along specific topic(see Section 4.3.1.5).
This section gives illustrations to those different possibilities, while section 4.3.1.3.3 will focus on data
consumption.
4.3.1.3.1 Data Producer Class-I produces data to the platform
We develop here three different cases:•••

Case I.a/: corresponds to classical publishing of semantic data (without federation capability);
Case I.b/: corresponds to classical publishing of semantic data (with federation capability);
Case I.c/: corresponds to the publishing of data/data set descriptions.

The detail of those 3 cases is discussed hereafter:•••

Case I.a/: The general idea (Case I.a/) explained in Figure 13 (shown with the plain red arrows) isthat a Class-I RDP follows its own publishing policy and therefore pulls and stores data at a predetermined rate and then publishes its semantic data (or part of it) to the CPaaS.io semantic
repository using the Communication Channel FC (which can be seen as a message bus withpublish/subscribe capability (see the Asynchronous case in 4.3.1.3 1/)). Relevant interactions inFigure 13 are 1/, 2/, 3/, 4/ & 5/. Corresponding data consumption is illustrated in section 4.3.1.4.1
Case II.a/.
Case I.b/: This case is very close to Case I.a/. Main difference is that, since the semantic data isalready stored locally there is no additional publishing towards CPaaS.io platform. Data stays local
and any attempt to consume data using a SPARQL request at the CPaaS.io level is forwarded tothe data endpoint provided by the CPaaS.io-registered Data Providers. Relevant interactions inFigure 13 are 1/, 2/ and 3/.
Case I.c/: This last case illustrates a quite different scenario, where the RDP stores the semantic
data within his own repository (therefore locally outside the CPaaS.io) and only publishes to
CPaaS.io semantic repository a semantic description of the data sets that can be therefore
accessed only locally. This scenario is quite different from 1.a/ but is still very relevant in practice.
Following this strategy, a data consumer will not consume the semantic data from the CPaaS.io
repository like in case II.a/ (see Section 4.3.1.3.1) but indeed will discover which data is available
and how to access it. The final part of the consumption process involves a classical SPARQL
request sent out to the RDP data endpoint in order to retrieve the semantic data from the local
semantic data store. Relevant interactions are 1/, 2/, 3/, 4bis/ and 5bis/.

H2020 EUJ-02-2016

CPaaS.io

Page 46 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

Figure 13: Data production for Class-I RDPs

4.3.1.3.2 Data Producer Class-II produces data towards the platform
In the Class-II case there is no local support to semantic so only non-semantic data is stored locally. The
RDP then needs to annotate the raw data (aligning it with the CPaaS.io ontology) before publishing to
the platform. Only a non-semantic data endpoint is provided by such RDPs.
••

Case II.a/: This case follows the general idea already presented in section 4.3.1.3.1 Case 1/. Data isretrieved by the Resource Manager FC and stored locally, then annotated in order to comply with
CPaaS.io ontology and published towards CPaaS.io Semantic repository via the Communication
Channel FC. Relevant interactions in Figure 14 are 1/, 2/, 3/, 4/, 5/ & 6/;
Case II.b/: This second case is similar to Case I.b/ described in section 4.3.1.3.1. Instead ofsystematically annotating and publishing data towards CPaaS.io, the RDP publishes only
descriptions of available data or data set (incl. information about how to access that data).
Relevant interactions in Figure 14 are 1/, 2/, 3/, 4bis/ and 5bis/.

H2020 EUJ-02-2016

CPaaS.io

Page 47 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

Figure 14: Data production for Class-II RDP

4.3.1.3.3 Data Producer Class-III produces data towards the platform
In Class-III case, the RDP can either decide to annotate locally and publish semantic-data to theCommunication Channel, or alternatively to rely on CPaaS.io as for the annotating process (as shown in
Figure 15 below with dashed red arrows).

Figure 15: Data production for Class-III RDP

4.3.1.3.4 Data Producer Class-IV produces data towards the platform
The following description assumes the configuration phase already performed as explained in Section
4.3.1.1.2

H2020 EUJ-02-2016

CPaaS.io

Page 48 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

Figure 16: Data production for Class-IV RDPFirst thing is for the Resource Manager to execute the polling policy by invoking IoT Services, which inturn pull raw data from the corresponding IoT Resources. Then the received data is sent for annotation to
the Semantic Integration FC before being published to the Communication Channel FC.
Asynchronously the Semantic Data Repository FC receives the data from the Communication Channel FC
and locally stores it (more explanation about the Semantic Data Repository available in Section 4.3.1.3
item 1/ ).
4.3.1.4 Consumption of data
Consumption of data can be done as follows:••

Live data• Invoking an IoT Service, in order to either retrieve annotated current readings from a sensor
resource, or setting a new actuator value;• Invoking a VE-service in order to get directly current value of VE properties;
Historical data (stored data)• Retrieving VE-level observations or annotated sensor historical data using SPARQL queries;• Subscribing to Communication Channel along specific topics.

4.3.1.4.1 CPaaS.io client consumes data from RDP Class-I
Data consumption from Class-I RDP offers 5 alternative methods:••

Case I.a/: Data previously published by a Class-I RDP can be consumed from the CPaaS.io
semantic repository via a SPARQL request (this corresponds to the case where the RDP either
duplicates all its semantic data or publishes surveys or part of its semantic data within CPaaS.io
repository) to the CPaaS.io semantic data repository;
Case I.b/: Alternatively if the RDP local platform has registered its data endpoint to the CPaaS.io,
the federation capabilities of the platform, makes sure that any incoming SPARQL request is
forwarded to the RDP. The request is therefore answered by the RDP itself;

H2020 EUJ-02-2016

CPaaS.io

Page 49 of 78

Deliverable D3.2

•

•

•

CPaaS.io System Architecture (v1)

Case I.c/: In this last case, the data endpoint of the RDP is accessed directly by the CPaaS.io client
as means to access the data/data set and data/data set descriptions were previously advertised tothe platform and therefore could be discovered by the client prior to data consumption (See Case
I.c/ in Section 4.3.1.3.1);
Case I.d/: As far as live data is concerned, the CPaaS.io client can invoke directly an IoT Service(following discovery and resolution) via the IoT Service endpoint and therefore being returned thecurrent annotated value;
Case I.e/: Subscribing to the Communication Channel in order to receive automatically the flow of
produced data.

4.3.1.4.2 CPaaS.io client consumes data from RDP Class-II
Data consumption from Class-I RDP offers 4 alternative methods:
•

•

•
•

Case II.a/: like in Case I.a/ above the historical data can be accessed from the CPaaS.io Semantic
data Repository FC via a SPARQL request sent to the Semantic Data Repository SPARQL data
endpoint;
Case II.b/: Corresponding to Case I.b/ above, {historical data/data set} has been previously
advertised and therefore can be accessed directly by the CPaaS.io client from the RDP SPARQL
data endpoint, without involving the CPaaS.io platform (apart for the discovery phase);
Case II.c/: Subscribing to the Communication Channel in order to receive automatically the flowof produced data;
Case ii.d/: As far as live data is concerned, if the CPaaS.io client is not satisfied with the sampling
rate implemented by the RDP, it can also invoke directly an IoT Service (following discovery andresolution) via the IoT Service endpoint and therefore being returned the current annotated value
in near real time.

4.3.1.4.3 CPaaS.io client consumes data from RDP Class-III
Unlike for Class-I & -II RDP there is only one way to consume historical data from the Class-III RDP as it
does not provide any data endpoint. Data which has been semantically annotated (either locally or using
the Semantic Integration FC) and stored at the platform level can be queried using a SPARQL request
sent directly to the Semantic Data Repository SPARQL data endpoint or subscribe to the Communication
Channel in order to receive automatically the flow of produced data.
As far as live data is concerned, the CPaaS.io client can invoke directly an IoT Service (following discovery
and resolution) via the IoT Service endpoint and therefore being returned the current annotated value orsubscribe to the Communication Channel in order to receive automatically the flow of produced data.
4.3.1.4.4 CPassS.io client consumes data from RDP Class-IV
Data consumption from Class-IV RDP is achieved in 3 ways:•••

Using SPARQL request at the CPaaS.io platform level in order to query historical data from the
Semantic Data Repository;
Invoking IoT Services exposing the RDP resources via the IoT Service server at the platform level;
Subscribing to the Communication Channel for live data consumption.

4.3.1.5 Storage of Data
Storage of IoT data or VE data can be achieved explicitly using the two Semantic Data Repository FC and
Semantic VE Data Repository FC APIs or implicitly when publishing the data to the Communication
Channel along a pre-determined topic.
By default the two data repositories (VE-level and IoT-level) are listening the Communication Channeland storing everything coming along that pre-determined topic.
H2020 EUJ-02-2016

CPaaS.io

Page 50 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

4.3.2 CPaaS.io ontologies and internal formats
Ontologies will be used for describing PEs (via the modelling of VE properties), for metadata like quality
information, and for linking of data sets from different providers. In particular for the federation of
implementation platforms between Europe and Japan, as the implementation platforms in the tworegions provide the data in different forms (NGSI in Europe, ucR in Japan).
As mentioned in Deliverable D6.1 [5], the project will be implementing the W3C proposed
recommendation on “Data on the Web Best Practices” 7 and make use of existing ontologies and evolving
standards. At the time of writing it has however not been decided yet which concrete ontologies andvocabularies will be used. In a first iteration, FIESTA-IoT is a good candidate for IoT data. For moredetails, please refer to Deliverable D6.1.

5 Perspectives
This section provides a preliminary description of the CPaaS.io perspectives and starts sketchingstrategies for reaching the identified targeted properties/qualities of the CPaaS.io platform. The objective
here is to refine strategies and find synchronisation points between the Japanese and European
approaches so that interoperability can be eventually ensured. See Section 2.1.5 for an introduction to
Perspectives.

5.1 Security
5.1.1 Policy Based Authorization for Access Control
Description: The Access Control module within CPaaS.io is responsible for making authorization
decisions based on access control policies. These polices define the permissions that a subject (smart
object or user) has over certain target resources (e.g. IoT service). Thus, the policies specify which
particular actions that subjects or groups are allowed to perform over a target resource under certain
conditions. These conditions usually refer to the context information provided by the context manager
module. In this regard, the eXtensible Access Control Markup Language (XACML) [22] policy language will
be adopted in CPaaS.io to deal with authorization policies.
Additionally, it is desirable to employ access control solutions specially designed for IoT scenarios.
Recently, the capability-based access control model (CapBAC) has been postulated as a realistic andpromising approach to be deployed on IoT scenarios. In this sense, the authorization component is able
to perform capability-based access control based on the mechanism presented in [23].
In a typical CapBAC scenario, an entity (subject) tries to access a resource of another entity (target).
Usually, a third party (issuer) generates a token for the subject specifying which privileges it has. Thus,
when the subject attempts to access a resource hosted in the target, it attaches the token which was
generated by the issuer. Then, the target evaluates the token granting or denying access to the resource.
Therefore, a subject which wishes to get access to certain information from a target, requires sending thetoken together with the request. Thus, the target that receives such token already knows the privilegesthat the subject has and a local Policy Decision Point (PDP) only needs to verify the capability token isvalid. This simplifies the access control mechanism, and it is a relevant feature in scenarios with resource-

7

https://www.w3.org/TR/dwbp/

H2020 EUJ-02-2016

CPaaS.io

Page 51 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)constrained devices since complex access control policies are not required to be deployed on
constrained end-devices.
Additionally, the token must be tamper-proof and unequivocally identified in order to be considered in areal environment. Therefore, it is necessary to consider suitable cryptographic mechanisms to be usedeven on resource-constrained devices which enable an end-to-end secure access control mechanism.
Moreover, given its high level of flexibility, CapBAC could be also extended to consider contextual
conditions related to parameters which are locally sensed by end-devices. Also, this model could becomplemented by other access control models by providing automated tools to infer the privileges to beembedded into the token.
5.1.2 Authentication
Description: Authentication ensures that an identity of a subject (user or smart object) is valid, i.e., thatthe subject is indeed who it or what it claims to be. The authentication module enables authenticating
users and smart objects based on the provided credentials. The credential can be in form oflogin/password, shared key, digital certificate.
Traditional authentication mechanisms based on for instance login-password or electronic IDs have been
already solved in by other projects and solutions. CPaaS.io focuses on alternative and more sophisticatedways of performing authentication ensuring, at the same time, privacy and minimal disclosure of
attributes. Thus, this kind of alternative privacy-preserving way of authentication using anonymous
credential system is handled in CPaaS.io framework by the Identity Management Component.
The IdM is able to verify anonymous credential and then, in case the identity is proved, the IdM interacts
with the authentication module which is the one that actually delivers authentication assertion to be usedduring a transaction.
5.1.3 Privacy Preserving Identity Management
Description: The Identity Management module is responsible for managing the identities of smart
objects and users. The module is able to take into account privacy concerns to manage subjects’credentials (from users or smart objects), in a privacy-preserving way relying on anonymous credential
systems. It is able to endow subjects with mechanisms to ensure anonymity, which is done mainly issuing
pseudonyms and proof of credentials to minimal personal data disclosure.
The Identity Management (IdM) system is responsible for managing and storing the credentials, which areused by subjects to request information from an IoT services. The IdM allows users to obtain the proper
credentials that can be use afterwards to derive proofs of identity to be presented to a Verifier (e.g., IoT
Service provider) in order to prove the identity condition while disclosing the minimum amount ofprivate information.
The component is envisioned as endowed with a cryptographic engine like Idemix [24] responsible forlow level cryptographic operations required by the anonymous credential system.
5.1.4 Extension to Key Exchange and Management
Description: The Key Exchange and Management (KEM) component assists peers involved in acommunication in the process of establishing a security context, like for instance, setting up tunnels for asecurity communication. It involves cryptographic key exchange and provides interoperability between
the peers in order to reach an agreement regarding the security functions to use for the communication.
This component is also in charge of storing and generating the cryptographic keys.
The Group Manager module as an extension of the KEM, enables sharing information in a secure andH2020 EUJ-02-2016

CPaaS.io

Page 52 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

private way, with those groups of entities that satisfy certain particular sets of identity attributes values.
These particular sets of attributes are represented by attribute sharing policies, which are influenced bycontext information where the data sharing is being performed.
This module is envisioned to manage dynamic sharing groups. To this aim, the group manager makes
use of attribute based encryption mechanism, namely the Ciphertext-Policy Attribute-Base Encryption(CP-ABE) scheme [25]. With this scheme, data to be shared within a group is encrypted under a policy of
attributes, while keys of participants are associated with sets of attributes. Only those target users thatsatisfy particular identity attributes (those given in the policy) possess the cipher keys to decrypt thedata. In this way, a data producer can exert full control over how the information is disseminated to otherentities, while a consumer’s identity can be intuitively reflected by a certain private key.

5.2 Semantic Interoperability
Information Model
Description: The FIWARE focuses on a common data model and powerful interfaces for searching andfinding information. FIWARE is using the OMA Next Generation Service Interface (NGSI) data model as thecommon information model of IoT-based systems and the protocol for communication. We describe the
NGSI9 and NGIS10 below.
NGSI9 is used to manage the availability of context entity. A system component can register theavailability of context information, and later on the other system component can issue either discover orsubscribe messages to find out the registered new context information.
NGSI10 is used to enable the context data transfer between data producers and data consumers. NGSI10
has query, update, subscribe and notify context operations for providing context values. A context broker
is necessary for establishing data flow between different resources as well as consumers or providers.

5.3 Performance
Service Orchestrator
Description: The Service Orchestrator module is responsible for generating processing task instances
and assigning them to proper resources (e.g., edge or cloud nodes) for task deployment, based on the
topology defined by developers, the current system status, and also some parameters (e.g., the scope ofdata sources) given by the operator on the fly. Meanwhile, the Service Orchestrator is managing all task
instances over the resources at the global level.

5.4 Scalability
Federation Agent
Description: Federation agent of the IoT Broker provides capability of forwarding data from one IoT
Broker to another with hierarchical or mash-up topologies. For instance, one deployment in a certain
area using an IoT Broker can be accessed by another deployment with another IoT Broker. Hence,Federation Agent separates IoT data in different domains and enhances the privacy by giving control ofthe data access to the IoT domain administrators.

H2020 EUJ-02-2016

CPaaS.io

Page 53 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

6 Instantiation views
6.1 U2-based Instantiation View
The TRON Project, since its inception in 1984, has been aiming at the realization of Highly FunctionallyDistributed System (HFDS) where any objects worth connected in our surroundings will be embeddedwith computers and work in a collaborative manner to offer better service to human users. The conceptof HFDS has been realized partially by the concept of the IoT and/or ubiquitous computing. In a sense,
the world has finally caught up with the project. So far the project has attempted to realize HFDS bydeveloping technological components that would be necessary such as node devices, identification
infrastructure, information distribution infrastructure, etc. We are now at the stage when we can combine
the components to build a system as a whole and fill in the details since the component technologies
have matured.
6.1.1 Description of u2 Functional Components
6.1.1.1 Pre-requisites
In this short section we introduce some concepts which are at the centre of the u2 technology.
6.1.1.1.1 ucode
To identify individual objects, spaces, and concepts in the real world, unique identifiers are assigned torespective objects, spaces and concepts that we wish to identify. This model is called a ucode model. The
target in the real world to be identified in the ucode model is called an "entity,” and the unique identifierassigned for identifying the entity is called a ucode.
The entity consists of objects, places, and concepts. "Objects" in the ucode model include tangible
objects such as industrial products and agricultural crops, and intangible objects such as content andprograms. "Places" include features in the real world such as roads and buildings and more detailed
smaller components in the real world such as rooms and corridors. "Concepts" include the relationships
between "objects" and "places" and the information which can be the real-world context. In a nutshell,
the entity is a target to be identified among objects, places, or concepts in the real world, and theidentifier to identify the entity is a ucode.
6.1.1.1.2 ucR: ucode Relation
ucR: u2 architecture represents the real-world context by modeling the relation on a real-world entity asa relational representation among ucodes allocated to entities or between the ucode and atom , which isa value such as a string, a number or a date. This representation model is called a ucode Relation model(ucR model). When a relationship is represented by ucR model, it is called a Relation.
ucR Unit: The basic unit of the ucR model consists of two ucodes or a ucode and atom, and theirrelationships. Moreover, the respective relationships between the two are provided with a logical ucodecalled a relation ucode. This basic unit consisting of the above triplet is called a ucode relation unit (ucRunit). When this triplet is set in a sentence where the relationships are represented as the predicate, theucode as the subject is called a subject ucode, and the ucode as the predicate which is a relation part iscalled a relation ucode, and the ucode as the object or complement is called an object ucode. The atom
can be substituted for the object ucode. For example, in a description, "R of S is O" or "there is a relation
R between S and O," S refers to the subject ucode, R to the relation ucode, and O to the object ucode or
H2020 EUJ-02-2016

CPaaS.io

Page 54 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)atom. When it is not necessary to uniquely identify any of the three elements comprising a ucR unit, theirrelevant parts can be left blank.
ucR Graph: The information and context about an entity are represented by combining relations among
multiple entities. For example, for information on an entity indicating a “stuffed cabbage,” pieces of
information such as its recipe, a cabbage as ingredients, and a production area of the cabbage are
combined. To represent such information, ucR units are combined, and a digraph where multiple ucodes
and atoms are connecting by relation ucodes is built. The digraph generated based on the above
method is called a ucode Relation graph (ucR graph). More specifically, the ucR graph is a massive graphstructure, in which ucodes are connected by relations and pieces of information described as atoms areassociated with each ucode.
6.1.1.2 ucode Resolution Component
The wide-area distributed database which manages ucR graphs is called a ucode Relation database. The
ucR database comprehensively manages information on the relations among multiple ucodes in addition
to the content such as information services associated with individual entities to which ucodes are
assigned. The ucR database is basically an open database which anyone can use to reference or register
information, but it can also implement an access control.
u2 architecture does not specify the internal configuration of the ucR database. However, the ucR
database must provide an interface for ucode resolution explained in the following section.
When a user physically accesses an entity in the real world, u2 architecture identifies the information
appropriate to the situation from the ucR database, based on the ucode assigned to the entity. This
process is called ucode resolution. Moreover, the information associated with ucodes, namely, the ucRgraph is registered in the ucR database. The protocol for accessing the ucR database in this manner iscalled ucode Resolution Protocol (ucodeRP).

H2020 EUJ-02-2016

CPaaS.io

Page 55 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

Figure 17: u2 Architecture (ucR focus)

6.1.1.3 IoT Aggregator Component
Aggregate computing uses all devices, services and systems that are connected to the network toachieve desired services. Let us take an example of the optimum control of air conditioning in our living
environment. Aggregate computing uses air conditioners, of course, but it also employs other objects
such as windows, air vents, gas stoves, temperature sensors, humidity sensors, and any other devices thatare related to the control of the air in our living space to achieve the desired optimum control of theenvironment beyond the confine of the original manufacturers. While we aim to achieve such computing
environment, we also have to pay due attention to the governance of the usage of functions. Users
should have the final say about who can control what and when instead of the vendors of the devices orservice providers. Thus the users should guide the governance, and we need to provide flexible access
control that can be dynamically changed according to the current context. However, note that theembedding of complex and comprehensive access control in each node will negate the general efforts toachieve the miniaturization and energy-efficiency of such devices. Yet, we can still achieve theminiaturization, low-cost, energy-saving by moving the complex advanced functions such as access
control, which is auxiliary to the original inherent function of the device, to the cloud. Thus "Aggregate
Computing" tries to offer a holistically optimized IoT service by mixing various devices and services as awhole.
The reference implementation for it is "IoT-Aggregator". It has not been easy to connect devices fromdifferent manufacturers and make them collaborate with each other. IoT-Aggregator will act as lubricant
and mediator among the devices, systems and services that would not have been capable ofcollaborating with each other easily.
H2020 EUJ-02-2016

CPaaS.io

Page 56 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

Figure 18: u2 architecture (IoT Aggregator focus)

6.1.1.4 "Omotenashi" Cloud Component
The TRON Project has been aiming to realize the vision of so-called HDFS environment in which many
computers in our surroundings cooperate together to offer better services to improve the quality of
everyday living. To realize such an environment, we need the mechanism to let objects to communicate
with each other to collaborate. But we also need a mechanism to learn and collect the attributes of eachindividual user such as the language spoken, age, many physical characteristics, preferences, etc. Suchknowledge must be reflected to create an optimized environment. For this purpose, TRON Project is now
building a general-purpose Personal Data Store (PDS) that uses the IoT technology. It is called"Omotenashi (hospitality) cloud" under its nickname. "Omotenashi" cloud is a project supported byindustry-government-academia and now has officially started with the funding from the Ministry ofInternal Affairs and Communications.
In the short time span, this "Omotenashi cloud" can be used to advance the hospitality service to theincreasing number of overseas tourists who are expected to peak in 2020. Customers (consumers) store
their individual characteristics such as preferred spoken language, food taboos, passport information forsales tax-exemption in the cloud. Once the data is stored, such information is easily retrieved and passedon the spot to service providers such as stores and public services by using the smartphone apps ortransportation IC cards as retrieval key. OPaaS.io has been designed to collaborate with IoT-Aggregator.
The collaboration will implement an HFDS environment.
The party who receives a service escrows the personal data in the PDS cloud, and lets it pass the data to
the service vendors as the need arises. So it is the customer (consumer) that controls the vendors. This
concept, Vendor Relationship Management (VRM) is the reverse of the conventional idea of Customer
Relationship Management (CRM). OPaaS.io plays the important role of PDS in the scheme. This
framework has been designed to be useful as legacy service platform in Japan after the year 2020 when it
will be utilized very much for hospitality service to foreign tourists. Small regional service vendors who
did not have the resources to build conventional CRM can join OPaaS.io service framework and can now
provide better services suited for the new IoT age. Omotenashi Cloud will be useful for invigorating
regional economy and also is expected to add to e-inclusion by accelerating the realization of
Enableware.
H2020 EUJ-02-2016

CPaaS.io

Page 57 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

Figure 19: u2 architecture ("Omotenashi" Cloud focus)

6.1.1.5 IoT-Engine Component
IoT-Engine is a standard development platform, standardized by TRON Forum, for Open IoT to realize"Aggregate Computing". IoT-Engine standard specifies the connector on the MicroProcessor Unit (MPU)
board, and the RTOS used by the MPU, and requires the function to connect to the cloud services on theInternet. The RTOS used on the IoT-Engine is µT-Kernel 2.0 which TRON Forum releases as open source.
IoT-Engines collaborate with the cloud platform called IoT-Aggregator. By doing this, edge nodes can beconnected via the cloud and they act as the components of the "Aggregate Computing", a vision of thecomputing architecture framework in next generation. IoT-Engine project has the participation of sevensemiconductor companies from six countries and regions of the world (as of December 2016): Toshiba
Microelectronics, Renesas Electronics, Cypress, Imagination Technologies, Nuvoton Technology, NXP
Semiconductors, and STMicroelectronics.

Figure 20: IoT Engine with IoT Engine Open Platform

H2020 EUJ-02-2016

CPaaS.io

Page 58 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

6.1.2 Description of CPaaS.io u2-based platform architecture

Figure 21: uID architecture

For historical reasons, u2 architecture was designed by a top-down manner driven by the needs ofapplications. Applications themselves have held many functions, which correspond to FGs withinthemselves. This is in contrast to today’s CPaaS.io architecture overview, so it is not easy to create
concrete mapping since some functional modules in u2 architecture is still offered as part of applications.
In Figure 22 below, yellow round corner rectangles corresponds to the base u2 architecture functions(ucR DB, resolution, etc.) Blue and violet round corner rectangles correspond to functions offered in
Omotenashi (Hospitality) Cloud. Red rounded corner rectangles correspond to modules from IoTAggregator. But do note that the u2 architecture itself is in flux, and many applications will offer
additional modules in the future, the mapping today may be slightly changed in 6-12 months’ time.

H2020 EUJ-02-2016

CPaaS.io

Page 59 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

Figure 22: Matching of the u2 components to the CPaaS.io Functional View

H2020 EUJ-02-2016

CPaaS.io

Page 60 of 78

u2 Components

IoT Aggregator p2p
securecommunication

Apps

H2020 EUJ-02-2016

ucR DBxxx

Omotenashi
ID/Authentication

Omotenashi VRM

xCPaaS.ioxxxxPage 61 of 78
x
x
x
x
x
x
x

Ucode resolutionxx

Web Front-end

Platform Management

Resource Deployement Tool

Pre-Processing (VE/IoT)

Post-Processing (VE/IoT)

Rule-based Reasoner

Analytics (VE/IoT)

Resource Manager

Task Execution Engine

Processing Optomizatiom

task Deployment

Task Composer

Kem

AuthZ

AuthN

VE Service Endpoint

VE Semantic Integration

VE & IoT Service Monitoring

VE Resolution

VE Registry

Semantic VE Data Repository

IoT Service

IoT Semantic Integration

Live Data Manager

IoT Service & Resource Registry

Semantic Data Repository

Communication Channel

Deliverable D3.2
CPaaS.io System Architecture (v1)

6.1.3 Mapping u2 / System Architecturex

x

IoT Aggregator
Device Manager
modulesxxxx

Deliverable D3.2

CPaaS.io System Architecture (v1)

6.2 FIWARE-based Instantiation View
6.2.1 Description of FIWARE Functional Components
In this short section let us introduce components which are at the centre of the FIWARE IoT Chapter aswell as some components from the European side coming from previous or ongoing EU projects (e.g.
KAT Toolkit or FIESTA-IOT IoT Registry).
6.2.1.1 IoT Broker
The IoT Broker Generic Enabler (GE) is specified as a lightweight and scalable middleware component
that separates IoT applications from the underlying device installations. The IoT Broker implementation
available through the FIWARE Catalogue is the reference implementation of this Generic Enabler. This
implementation satisfies all properties described in the specification of the Generic Enabler. The mainfeatures of the IoT Broker are:•••Offering a single point of contact to the user, hiding the complexity of the multi-provider natureof the Internet of Things.
Collecting and aggregating information about thousands of real-world objects on behalf of theuser.
Provide means to assemble lower-level device information (device-centric access) into higherlevel Thing information (information-centric access).

6.2.1.2 ConfMan
The NEC Configuration Management or NEC ConfMan is an implementation of the FIWARE IoT Discovery
Generic Enabler. This implementation is specifically designed to interwork with the IoT Broker GE FIWARE
reference implementation, serving as the registry of FIWARE NGSI context providers.
The NEC ConfMan APIs are fully based on FIWARE NGSI-9. ConfMan supports the following operations
for exchanging context availability information:•

The registerContext operation is available to register information about data sources in the
ConfMan's database;•The discoverContextAvailability operation can be used to query ConfMan for data sources.

Users
can
subscribefordatasourcesusing
thesubscribeContextAvailability,
updateContextAvailabilitySubscription and unsubscribeContextAvailability operations. Subscribed users
need to expose a resource for receiving notifyContextAvailability messages from ConfMan.
6.2.1.3 IoT Knowledge Server
IoT Knowledge Server adds semantic information into NGSI messages and enhance these NGSI messages
with semantic reasoning. IoT Knowledge Server component has an internal RDF storage where NGSI (orother) ontologies are kept. It serves semantic knowledge such as entity subtypes or supertypes andprovides high-level access to the semantic ontologies via query/subscription functionalities.
6.2.1.4 FIWARE Context-Broker
FIWARE’s Context Broker is a specific middleware for brokering the communication between IoT data
providers and IoT applications based on NGSI-standard as an open-source generic enabler and it can
H2020 EUJ-02-2016

CPaaS.io

Page 62 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

provide functionalities such as queries pertaining to historical information, federation, entity
compositions (aggregating information), and so on. FIWARE Context Broker has functionality fordiscovery of information sources (for things/ entities) and the information sources and what information
they can provide are registered to this Context Broker. FIWARE Context Broker is used for discovering
information sources and then accesses/forwards the information. The communication between Context
Broker for context value data forwarding as well as registration of entity registrations are based on NGSI
protocol.

6.2.1.5 KAT Toolkit
The Knowledge Acquisition Toolkit (KAT) provides a set of methods for labelling data sets after initial preprocessing and data abstraction. In particular the tool provides an algorithm workflow that is
implemented sequentially: pre-processing method, along with dimensionality reduction e.g. principle
component analysis), data abstraction (e.g. clustering) and finally labelling/annotation of the resulting
abstracted data is carried out. Input data format is time series in a tuple format or Comma Separated
Values (CSV). Some newly developed machine learning techniques for data prediction will be integrated
to the existing toolkit in the course of the project.
6.2.1.6 IoT Registry
The IoT Registry is a component developed for FIESTA-IoT (FIRE project) by University of Cantabria,
based on a preliminary version developed by UoS. It currently offers:
1. IoT Resource and IoT Service registration with semantic support;
2. Storage and query of semantic data (SPARQL enabled);
3. Discovery, Look-up and Resolution of IoT Services and Resources.
A next version under development will support VE and VE Service registration and relating discovery,
look-up and resolution mechanisms. It should also support Associations.
6.2.1.7 Authorization Component
The authorization component is able to perform capability-based access control based on themechanism presented in [23]. It describes authorization tokens specified in JavaScript Object Notation(JSON) and optimizations to manage access control on constrained devices. The access control
component it is controlled by XACML policies
The CPaaS.io Authorization scenario will consists of the following main entities:
•
•

•
•

Capability Client: performs requests to the Capability Manager to obtain capability tokens, which
are used to perform actions over entities that are registered with the Context Manager;
Capability Verifier: a server receiving access requests from Capability Clients. Such access requests
contain a capability token, which is evaluated by the Capability Verifier in order to deny or grant
the requesting action. This entity makes use of the Capability Evaluator functionality, which isintended to validate capability tokens;
Capability Manager: a server accepting requests for capability tokens generation. Additionally,
this entity acts as a client requesting authorization decisions to the Policy Decision Point;
Policy Decision Point (PDP): It is a server that accepts XACML requests to make authorization
decisions. The PDP is contacted by the Capability Manager before generating a capability token
for the Capability Client;

H2020 EUJ-02-2016

CPaaS.io

Page 63 of 78

Deliverable D3.2•

CPaaS.io System Architecture (v1)

Policy Administration Point (PAP): It is a web application responsible for defining and managing
the access control policies. It provides the functionality so users can define XACML policies in auser-friendly way. The PAP has a GUI to facilitate the generation of policies.

6.2.1.8 Identity Management
The IdM module is responsible for managing the identities of the smart objects and users. The module isable to take into account privacy concerns to manage subjects’ credentials (from users or smart objects),
in a privacy-preserving way relying on anonymous credential systems. It is able to endow subjects withmechanisms to ensure anonymity, which is done mainly issuing pseudonyms and proof of credentials tominimal personal data disclosure.
The Identity Management system is responsible for managing and storing the credentials, which are usedby subjects to request information from an IoT services. The IdM allows users to obtain the proper
credentials that can be use afterwards to derive proofs of identity to be presented to a Verifier (e.g., IoT
Service provider) in order to prove the identity condition while disclosing the minimum amount ofprivate information.
The component is endowed with the Idemix cryptographic engine that is responsible for low level
cryptographic operations required by the anonymous credential system. The information provided by theContext Manager module is used by the IdM to handle the usage of partial identities under a specificcontext.
The CPaaS.io IdM has been integrated within the FIWARE IdM, i.e., the Keyrock IdM. The CPaaS.io IdMIssuer, which is in charge of generating the Idemix credentials, is able to communicate with the Keyrock
to generate the credentials based on the attributes stored in the Keyrock for the user requesting thecredential. To this end, the CPaaS.io IdM provides a Java library to interact with Keyrock by means of the
SCIM standard [26]. This library provides methods such as add, remove or update users.
Because CPaaS.io IdM relies on Keyrock, users profile management is delegated to Keyrock, the rest of
the components of the CPaaS.io framework interacts with Keyrock through the CPaaS.io IdM.
The IdM components that have been designed and implemented in the scope of CPaaS.io are
enumerated below:•

CPaaS.io IdM Client: This is a client application that allows obtaining Idemix credentials from theIssuer Server. It also allows interacting with the Verifier server which can validate the partial
identity derived from the credential;•

CPaaS.io-Issuer-Server: This is a web application which allows generating Idemix credentials forclients. The client must be authenticated against the Issuer using a valid certificate. The Issuer also
supports the verification functionality;•

CPaaS.io-Verifier-Server: This is a web application, which is able to validate partial identities
presented by the client application;•

CPaaS.io-IdM-Enabled-Capability Manager: This is a web application that allows users to obtaincapability tokens using their partial identities. In other words, it allows authenticating anddemonstrating their attributes by means of Idemix proofs of having a valid credential issued by
the Issuer;

H2020 EUJ-02-2016

CPaaS.io

Page 64 of 78

Deliverable D3.2•

CPaaS.io System Architecture (v1)

CPaaS.io IdM KeyRock Client: This is a library that provides a basic API for identity management
by implementing a client to interact with the FI-WARE KeyRock server.

6.2.1.9 Authentication
The authentication module verifies if a subject is truly who or what it claims to be. Authentication services
are provided by the CPaaS.io IdM system. Besides the conventional password-based and key-based
mechanisms, the CPaaS.io IdM also supports authentication based on anonymous credentials.
•••

Login password-based authentication: The CPaaS.io IdM relies on the Keyrock IdM to perform
this kind of authentication. To this end, the CPaaS.io IdM library provides a method that given theusername and password authenticates the user against the keyrock and generates anauthentication token that can be used afterwards to perform other actions against the Keyrock
IdM. The CPaaS.io Keyrock IdM client library provides two main methods for dealing with thiskind of authentication. The first method is for authenticating a user registered in the Keyrock
given the password and username and its domain. The second method, provided by the Keyrock
IdM client, is for validating a given token ID;
PKI-based authentication: CPaaS.io framework allows users to authenticate using their digital
certificates. It requires a Public Key Infrastructure (PKI) where the user’s certificates are signed by
the Certificate Authority (CA) and validated on the server side. The IdM server performs client
authentication based on asymmetric-key cryptographic. This is done actually by the IdM web
server that authenticates the client that must possess the private key associated with its public
X509 certificate (the server trusts the CA);
Anonymous credentials based authentication: This kind of authentication is done by the
CPaaS.io privacy-preserving IdM, which offers a claim-based solution for authentication. The
CPaaS.io IdM relies on an anonymous credential system, namely Idemix from IBM [24], to ensurea privacy and minimal disclosure of personal information.

6.2.1.10 Policy Manager
The Policy Manager is the decision taking engine that receives the adequate context classification fromthe Context-Manager and uses it to decide which policy to apply in order to control the behaviour of all
the policy-aware components. The Policy-Manager can be configured with a set of default systemdefined policies that apply for each context defined and can include feedback from the user in terms of
the policy rating and application in order to adapt its behaviour.

H2020 EUJ-02-2016

CPaaS.io

Page 65 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

6.2.2 Description of CPaaS.io FIWARE-based platform architecture

Figure 23: FIWARE-based architecture

The Figure 23 above shows the FIWARE IoT architecture which mainly consists of IoT Edge and IoT
Backend domains. These domains are described as follows:••

IoT Edge: It is made of all on-field IoT infrastructure elements needed to connect physical devices
to FIWARE Apps. Typically, it comprises: IoT end-nodes, IoT gateways and IoT networks(connectivity). The IoT Edge and its related APIs will facilitate the integration of new types ofgateways and devices [28];IoT Backend: It comprises the set of functions, logical resources and services hosted in a Clouddata centre. Up north, it is connected to the data chapter ContextBroker, so IoT resources aretranslated into NGSI Context Entities. South-wise the IoT backend is connected to the IoT edge
elements, that is all the physical IoT infrastructure.

FIWARE’s IoT architecture follows FIWARE OMA NGSI context management information model, whichallows performing context operations such as query, update, subscribe, and notify. NGSI9 API is mainly
used for discovering VEs while NGSI10 is mainly for accessing context information.
Considering the architecture from a bottom-up (south to north) perspective, in the south IoT devices areconnected to IoT Broker and IoT Discovery through IoT NGSI gateway. IoT NGSI Gateway can be
implemented with an adapter so that the devices with various APIs (shown as Device API) can beregistered via NGSI9. Moreover, the context information can be sent to IoT Broker via NGSI10. IoT Broker
H2020 EUJ-02-2016

CPaaS.io

Page 66 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)then forwards the context to the data context broker and to the application developers. In FIWARE, each
FC in this architecture is realized by Generic Enablers (GEs). Detailed information about specific GEs canbe found in FIWARE catalogue [29].
We listed the four components in Section 6.2.1 and showed them in the above figure. These
components, namely Aeronbroker, NEConfMan, IoT Knowledge Server, and Orion Context Broker aresupported by FIWARE. Now, in the below figure we match these components to the CPaaS.io FCs basedon where the already implemented FIWARE components possibly fit in this Functional View.

H2020 EUJ-02-2016

CPaaS.io

Page 67 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

Figure 24: Matching of the FIWARE components to the CPaaS.io Functional View

In the Figure 24 above, the FIWARE components are matched with the FCs of CPaaS.io. Note that the
FIWARE components are placed in arbitrary places for visual purpose, while their places actuallycorrespond to the places of the marked FCs in CPaaS.io functional view.
While CPaaS.io architecture is clearly more advanced, having each FC has various requirements, somerequirements of the FCs are not completely met by the FIWARE components. For instance, considering
the requirements that are listed for use-cases, Semantic VE Data Repository may require more advanced
and novel features compared to the existing functionalities of the IoT Knowledge Server component. For
this reason, some FIWARE components may be either extended or improved or new components should
be developed during the CPaaS.io project when necessary. At this stage, the decisions have not been
finalized for the implementation necessities of the proposed CPaaS.io architecture. On the other hand,some components can already meet the listed requirements of some of the FCs without further
implementation effort. For instance, VE Resolution is provided by IoT Discovery and therefore IoT
discovery component could be integrated without much effort.
We provide an instantiation view for the FIWARE components below. The Figure 24 below includes
multiple (distributed with a load balancer) IoT Broker instances, IoT Knowledge Server, Context Broker, as
well as IoT Discovery GEs as well as their interactions (APIs).

Figure 25: Interactions of the FIWARE FCs

In the above Figure 25, the historical data is stored in CouchDB by IoT Broker. IoT Broker also forwards
the context to the context broker or applications. Moreover, subscriptinos are stored in and accessed
H2020 EUJ-02-2016

CPaaS.io

Page 68 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)from a shared SQL database by the distributed IoT Broker instances. Registrations are saved in theRegistration Respository (ConfMan) via NGSI9. Lastly, IoT Agent is responsible for providing context of
VEs in NGSI9/10 information model and therefore it can be considered as an NGSI device.

H2020 EUJ-02-2016

CPaaS.io

Page 69 of 78

KAT Toolkit (3party)

Context Broker(FIWARE)IoT Broker(FIWARE)IoT Discovery(FIWARE)IoT Knowledge
Server (FIWARE)
FIESTA-IoT IoT
Registry
Service
Orchestratorrd(3 party)

H2020 EUJ-02-2016
X

X
X
X

NR

SocIoTal
FIWARE based
Authentication
SocIoTal
FIWARE based
Authorization

CPaaS.io
X

PA
PA

NR
X

X
X

X

X

Page 70 of 78

X
X
IoT

rd

IoT

Concrete
FIWARE
Componentsrdand 3 party
components

X
X
X
PA

X
X
X
PA
PA

Web Front-end

Platform Management

Resource Deployement Tool

Pre-Processing (VE/IoT)

Post-Processing (VE/IoT)

Rule-based Reasoner

Analytics (VE/IoT)

Resource Manager

Task Execution Engine

Processing Optomizatiom

task Deployment

Task Composer

Kem

Identity Management

AuthZ

AuthN

VE Service Endpoint

VE Semantic Integration

VE & IoT Service Monitoring

VE Resolution

VE Registry

Semantic VE Data Repository

IoT Service

IoT Semantic Integration

Live Data Manager

IoT Service & Resource Registry

Semantic Data Repository

Communication Channel

Deliverable D3.2
CPaaS.io System Architecture (v1)

6.2.3 Mapping FIWARE / System Architecture

Concrete
FIWARE
Componentsrdand 3 party
components

H2020 EUJ-02-2016

SocIoTal
FIWARE based
Identity
Management
SocIoTal
FIWARE based
Policy manager

CPaaS.io

X

X

X: covers the FC currently

NR: covers the FC in Next Release of the concrete FC

PA: covers PArtly the FC

Page 71 of 78

Web Front-end

Platform Management

Resource Deployement Tool

Pre-Processing (VE/IoT)

Post-Processing (VE/IoT)

Rule-based Reasoner

Analytics (VE/IoT)

Resource Manager

Task Execution Engine

Processing Optomizatiom

task Deployment

Task Composer

Kem

Identity Management

AuthZ

AuthN

VE Service Endpoint

VE Semantic Integration

VE & IoT Service Monitoring

VE Resolution

VE Registry

Semantic VE Data Repository

IoT Service

IoT Semantic Integration

Live Data Manager

IoT Service & Resource Registry

Semantic Data Repository

Communication Channel

Deliverable D3.2
CPaaS.io System Architecture (v1)

Deliverable D3.2

CPaaS.io System Architecture (v1)

7 Conclusions & Next Steps
We have provided in this first version, a solid foundation to the CPaaS.io architectural activities and a firstcomprehensive and sound version of the CPaaS.io logical architecture (architectural Views andPerspectives with requirement tracking) and two Instantiation Views that shows how this logicalarchitecture can be instantiated using two different technologies, namely u2 for the Japanese side and
FIWARE for the European counterpart.
As we emphasised in the introduction section, this first release of the architecture document is apreliminary version only that will be extended along the project lifetime with few more official
incremental versions focussing on introducing more advanced features and complementing existingones.
This version V1 focuses on the primary aspects of the CPaaS.io architecture and does not fully coversome aspects like task distribution, federation, which are still under discussion. Some limitations of thecurrent version are:•••

System UCs are simplified, do not cover all FCs and do not cover all possible scenario, for instancethey do not include yet any interactions with the Security FG;
Interfaces are not provided as they are still under discussion;
Perspectives do not show yet any synchronisation points between the EU and Japaneseapproaches.

The next version of the CPaaS.io architecture will be updated in M15 and will provide the following
additions and improvements:
•
•
•
•
•
•

Updated Functional View: refinement of the logical architecture (updated list of FCs);
Updated Information View:
o Updated list of system UCs covering more scenarios and more FCs;
Updated Instantiation views (u2- and FIWARE- based concrete architectures) with information
about the interfaces;
Insights about solutions to inter-platform instances interoperability;
Updated Volere template (update of requirement mapping);
Updated system Perspectives.

H2020 EUJ-02-2016

CPaaS.io

Page 72 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

8 References[1] F. Carrez et al., “IoT-A Deliverable D1.5 – Final Architectural Reference Model for the IoT v3.0”,
www.iot-a.eu/public/public-documents/[2] D2.1: CPaaS.io deliverable “Requirement Specification (V1)”, Martin Strohbach ed.
[3] D2.2: CPaaS.io deliverable: “Prototype, 1st release”[4] D3.1: CPaaS.io deliverable “Requirement Collection and Analysis”, François Carrez ed.
[5] D6.1: CPaaS.io deliverable “Holistic Data Management State of the Art”, Mariane Fraefel ed.
[6] ETSI TR 103 167Machine-to-Machine Communications (M2M); Threat analysis and countermeasures to M2M service layer[7] Haller, S et al: “A Domain Model for the Internet of Things”, in iTHINGS’2013 proceedings, Beijing,
China (see also IEEE eXplore)[8] Ho, E. & al., “IoT-A Deliverable D6.1 – Requirements list”, www.iot-a.eu/public/public-documents/[9] IoT Semantic Interoperability: Research Challenges, Best Practices, Recommendations and Next
Steps [IERC – European Research Cluster on the IoT], Position Paper available at www.internet-ofthings-research.eu/pdf/IERC_Position_Paper_IoT_Semantic_Interoperability_Final.pdf[10] IoT-A web site: http://www.iot-a.eu[11] oneM2M white paper, January 2015, http://www.onem2m.org/images/files/oneM2M-whitepaperJanuary-2015.pdf[12] oneM2M Functional Architecture, http://www.onem2m.org/images/files/deliverables/TS-0001Functional_Architecture-V1_6_1.pdf[13] OneM2M security solutions”, oneM2M-TR-0008-Security-V1.0.0, 2014[14] Pastor, A. “Updated Requirements List”, www.iot-a.eu/public/public-documents/[15] OneM2M security solutions”, oneM2M-TR-0008-Security-V1.0.0, 2014[16] “Requirements Specification for Urban Plarforms v2.2” prepared by Demand-Side Engagement
Stream I the context of the European Innovation Partnership for Smart Cities & Communities(EIP_SCC) Integrated Infrasturcture Action Cluster – Urban Platform[17] N. Rozanski and E. Woods, “Applying Viewpoints and Views to Software Architecture” , Addison
Wesley, 2011[18] SMARTIE Project Deliverable D2.2 “Requirements”[19] SPARQL Protocol And RDF Query Language http://www.w3.org/TR/rdf-sparql-query/[20] UNIs: List of IoT-A UNIfied requierementS. Available at http://www.iot-a.eu/public/requirements[21] Volere Requirements Resources, http://www.volere.co.uk/[22] E. Rissanen, extensible access control markup language (xacml) version 3.0 oasis standard (2012).
[23] J. L. Hernández-Ramos, A. J. Jara, L. Marín, and A. F. Skarmeta, “Dcapbac: Embedding
authorization logic into smart things through ecc optimizations,” International Journal ofComputer Mathematics, pp. 1–22, 2014.
[24] Specification of the Identity Mixer Cryptographic Library. Version 2.3.40 IBM Research, Zurich
January 30, 2013. Available http://www.zurich.ibm.com/idemix/
H2020 EUJ-02-2016

CPaaS.io

Page 73 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)[25] Bethencourt, J., Sahai, A., & Waters, B. (2007, May), Ciphertext-policy attribute-based encryption.
In Security and Privacy, 2007. SP'07. IEEE Symposium on (pp. 321-334).
[26] System for Cross-domain Identity Management. (SCIM). Internet Engineering Task Force (IETF),
RFC 7643. ISSN: 2070-1721.
[27] www.viewpoints-and-perspectives.info/home/perspectives/ Last accessed 26/01/2017[28] FIWARE
InternetofThings(IoT)
services
enablement
architecture.
Available
https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Internet_of_Things_(IoT)_Services_Enablement_Architecture[29] FIWARE Catalogue, Available https://catalogue.fiware.org/enablers

H2020 EUJ-02-2016

CPaaS.io

Page 74 of 78

Deliverable D3.2

CPaaS.io System Architecture (v1)

Appendix : Requirements (Volere Template)
The following pages show a snapshot of the unified requirements as of January 2017.

H2020 EUJ-02-2016

CPaaS.io

Page 75 of 78

Deliverable D3.2

Requirements

Volere Template

Traceability regarding the architectural reference model
Rationale

DependenciesConflicts

View

Perspective

Functionality
Group

Functional Component Domain Model

Originating
Business Scenario

Demonstration
Business Scenario

Req. TypePriority

Category

NFREQ.1

NFREQ

MEDIUM

Platform,
Infrastructure

The p/f SHOULD support different service
level agreement

Scalability

Probably to be dropped as no rationale is provided

NFREQ.2

NFREQ

HIGH

Platform,
Infrastructure

The p/f MUST offer mechanisms forbalancing processing load (services, events,
data,…)

Scalability

NFREQ.2 & NFREQ.4 SHOULD -> MUSTNFREQ.3

NFREQ

MEDIUM

Platform,
Infrastructure

Quality of service SHOULD be monitored atruntimeScalability

NFREQ.6

NFREQ

MEDIUM

Platform,
InfrastructureHigh availability of the p/f SHOULD beguaranted

Availability

NFREQ.5 is dropped and captured by NFREQ.6 and NFREQ.7

NFREQ.7

NFREQ

MEDIUM

Platform,
InfrastructureHigh availabiilty of the networking resources
SHOULD be guaranted

Availability

TPT-5. NFREQ.5 is dropped and captured by NFREQ.6 and NFREQ.7

NFREQ.8

NFREQ

MEDIUM

The p/f SHOULD be able to provide some
self-healing mechanisms

Availability

This can be linked to the flexibility in distributing tasks.

NFREQ.9

NFREQ

HIGH

Data and services MUST be exposed or
made available only to authorised actors

Security

NFREQ.9, NFREQ.10 & NFREQ.12 are merged

NFREQ.11

NFREQ

HIGH

NFREQ.13

NFREQ

MEDIUM

Platform,
Infrastructure
City Data, City
Services,
Platform
City Data,
Platform
City Data,
Platform,
Infrastructure

NFREQ.15

NFREQ

MEDIUM

NFREQ.16

NFREQ

NFREQ.17

NFREQ

UNI ID

Description

CPaaS.io System Architecture (v1)Security,
Performance

Data freshness MUST be ensured

System use caseComments!!! To be clarified, too vague

The p/f SHOULD provide mechanisms forprotecting the data transmission

Security

NFREQ.13 & NFREQ.14 are merged, YEM-3

Platform

The p/f SHOULD be able to detect some of
the threats at runtime

Security

Which threats are concerned is still to be discussed

MEDIUM

Platform,
Infrastructure

The p/f SHOULD provide a trusted andsecured communication and information
management (incl. storage)

Security, Trust

MEDIUM

Platform,
Infrastructure

The p/f and infrastructure SHOULD betrustable

Trust

The p/f users (including Physical people)
SHOULD be able to access data andservices anonymously (under certain
restriction)

Privacy

NFREQ.18 & NFREQ.19 merged, Data has been added. Meaning they can accessservices and data that are granted to ALL.

Security

Made clear we're talking about personal data

YEM-3

NFREQ.18

NFREQ

MEDIUM

City Data, City
Services,
Platform

NFREQ.20

NFREQ

MEDIUM

The users SHOULD be able to control theSocietal needs,
personal data they provide and how theirPlatform
personal data is used

NFREQ.21

NFREQ

MEDIUM

Platform

Access control policies SHOULD be secured

Security

NFREQ.22

NFREQ

HIGH

Platform

The p/f MUST provide mechanisms forrespecting user's privacy

Privacy

Changed to MUSTNFREQ.23

NFREQ

MEDIUM

Platform

The p/f SHOULD provide mechanisms for
ensuring the confidentiality of communication

Privacy

YEM-3, TPT-5

The p/f MUST be extensible in order tosupport future technology

Evolvability!!! Expressed like that, this requirement is meaningless and pretty dangerous,
assuming its priority is HIGH. It must be refined for V2

The p/f SHOULD provide preferably
standard interfaces to Service providers

Extensibility,
Evolvability

TPT-4

Interoperability

Moved to MUSTNFREQ.24

NFREQ

HIGH

Social needs,
City Data,
Platform,
Infrastructure

NFREQ.25

NFREQ

MEDIUM

Platform,Business

NFREQ.26

NFREQ

HIGH

Platform

NFREQ.27

NFREQ

HIGH

Platform

NFREQ.28

NFREQ

MEDIUM

Business,
Platform

NFREQ.29

NFREQ

HIGH

Business,
Platform

NFREQ.30

NFREQ

MEDIUM

Platform

NFREQ.31

NFREQ

MEDIUM

City Data,
Platform

NFREQ.32

NFREQ

MEDIUM

City Data,
Platform

NFREQ.13

Service MUST be provided in aninteroperable manner
Data MUST be interoperable across thedifferent parties and domains (data/service
providers)
It SHOULD be possible to set-up data quality
constraints for data producers to comply with.
In the same way it SHOULD be possible tomonitor/verify data quality

Interoperability

Trust

It MUST be possible to enable the linking of
Data Sources across the platform instances
The p/f SHOULD be able to ensure a short
response-time for data queries
The data producers SHOULD be able topublish his data to several different p/finstances
The p/f SHOULD be able to ingest hugeamount of data, meaning: Collecting,processing, publishing, storing and serving

Users may want to share their data via
various channels using various platform
instances

probably trust and reputation

Evolvability!!! To be clarified what we mean by linking in this context.

Performance!!! We're not talking about real-time here. However there is no clear requirements
about msec. to be refined later on

Interoperability

EUE-10Scalability

EUE-12 (few millions at least)

Resilience

YEM-4

NFREQ.33

NFREQ

MEDIUM

Platform

The p/f SHOULD provide a level of ergonomy,
smartness and self-management that
For scenario, the plaform users need tominimize the intervention of the platform
concentrate on the specifics of the scenario
users in management duties or minimize
while forgetting about any constraints
interaction of the p/f user with the platform
pertaining to p/f operation
itself.

NFREQ.34

NFREQ

MEDIUM

Platform,
Management

Different user groups can exert different
The p/f SHOULD be able to deal with userlevels of control over a device, so a hierarchyroles and assignment of roles to user groups.
between groups is established

Security

WA-3. As a result accountability must consider not only the identity of the action
performer but also the role under which the action was undertaken

NFREQ.35

NFREQ

MEDIUM

Platform,
Management,
GUI

The p/f SHOULD be usable by any citizen
regardless to the spoken tongue

Evolvability

TPT-2

NFREQ.36

NFREQ

HIGH

Platform

The architecture MUST favour the reuse ofwide-spread standards for Data and API

Extensibility,
Evolvability

TPT-4

NFREQ.37

NFREQ

MEDIUM

Platform

The p/f SHOULD facilitate the development ofapplications reusing its enablers

Extensibility,
Evolvability

TPT-6 (partly, TPT-8). Standard API, powerful discovery and rich data queries (to namejust a few) are a way to go

Discovery,
lookup

Discovery and lookup MUST allow theselection of physical entities (via VEs) andservices based on geographical parameters

FREQ.1FREQ

HIGH

H2020 EUJ-02-206

Pending AP

In an international context, there is a need for
multilingual support.

NFREQ.25

Like Time-Stamp, geographical information
can be used for scoping purpose ('spacial' inthis particular case)

Functional
View,
Information
View

IoT Service,
Virtual Entity

IoT Service & Resource
Registry, VE Registry

CPaaS.io

Virtual Entity

Moved SHOULD to MUST and intergate FREQ.4

Page 76 of 78

Deliverable D3.2

Requirements

Volere Template
UNI ID
FREQ.2

FREQ.3

FREQ.5

Req. Type

FREQ

FREQ

FREQ

Priority

Description

HIGH

Discovery,
lookup

The look-up service of CPaaS.io MUST
withhold or grant information depending oncontext such as application involved,
requesting entity, and security permissions.

HIGH

Discovery,
lookupThe IoT system MUST enable the dynamic
discovery of IoT Resources, Virtual Entities
In order to enable semantic-based selection
and all services (VE Service and IoT Service)
based on respective specifications.

HIGH

Discovery,
lookupThe IoT system MUST enable the lookup ofservice descriptions of specified services for
Virtual Entities with the VE identifier as key
for the lookup

FREQ.9FREQ

HIGH

FREQ.10

FREQ

HIGH

Discovery,
Lookup, Trust

FREQ.11

FREQ.12

FREQ

FREQ

Traceability regarding the architectural reference model

Category

Discovery,
Object (Virtual Entities), VE- & IoT-services
lookup,and resources shall be semanticallyInteroperability described and registered

HIGH

HIGH

CPaaS.io System Architecture (v1)

Rationale

DependenciesConflicts

View

Functional Component Domain Model

NFREQ.9

Functional
View

IoT Service,
Virtual Entity

IoT Service & Resource
Registry, VE Registry

FREQ.1

Functional
View

IoT Service,
Virtual Entity,
Management

IoT Service & Resource
Registry, VE Registry,Resource Deployment
Tool

Functional
View

Virtual Entity

VE Registry

IoT Service,
Virtual Entity,
Management

IoT Service & Resource
Registry, VE Registry,Resource Deployment
Tool

Needed for powerful semantic discovery andlook-up

FREQ.1,
FREQ.13

Information
View

Any data at the platform level shall have data
quality annotations
Data search and retrieval shall be achieved
upon a collection of criteria that includes
location (of the Physical entity concerned),
Data Query,Interoperability characteristics of the underlying IoT
Resource reputation and the quality of
information

Allows to select data and data sources
according to the application and scenario

FREQ.1,NFREQ.28

Information
View

FREQ.13

Functional
View,
Information
View

The platform shall provide a SPARQL endInteroperability point for accessing semantic data (either
annotated data or semantic descriptions)

SPARQL is the currently the best option forquerying data, It requires some expertisethoughSensor data can only be processed if it isannotated with additional information relating
to the data itself (unit, phydical
phenomenon,…), quality and accurancy ofmeasurement, origin, location, who owns thedevices etc

Using meta-data as criteria for data queries
allows to filter out data which is of no interest

Perspective

Functionality
Group

IoT Service,
Virtual Entity

Semantic Data
Repository, Semantic VE
Data Repository

IoT Service,
Virtual Entity

Semantic VE Data
Repository, VE Registry,
Semantic Data
Repository, IoT Service &Resource Registry

Functional
View

FREQ.1

Information
View

Interoperability

Functional
View

Interoperability

IoT Service,
Virtual Entity

Semantic Integration

Functional
View

Privacy

Security

Identity Management

Functional
View

Security,
Privacy

Security

KEM

Functional
View

Security,
PrivacyIoT Service,
Virtual Entity,
Security

Semantic VE Data
Repository, VE Registry,
Semantic Data
Repository,KEM

Data owners shall be able to set accessRDPs must be able to discreminate between
Security, Privacy
NFREQ.9,
control rights/ policies (set up by data owners) whomever is authorised or not to access and& TrustNFREQ.21
to their data stored on resources.
use their data

Functional
View

Security,
Privacy

Security,
Management

AuthZ, Web Front End

Access-control rights/ policies (set up by data
Security, Privacy
owners) SHOULD NOT be published& Trustpublicly.

NFREQ.21

Functional
View

Security,
Privacy

Security

AuthZ, KEM

NFREQ.23

Functional
View

Security,
Privacy

Security,
Communication

KEM, Communication
ChannelFREQ.13

FREQ

HIGH

FREQ.14

FREQ

HIGH

Interoperability

FREQ.20

FREQ

HIGH

In order to expose private data it is
Security, Privacy User anonymity MUST be provided in order tonecessary to garanty that the data can't be& Trustenforce privacy (e.g. at communication level)
traced back to its owner.

FREQ.21FREQ

MEDIUM

Security, Privacy Personal data in servers should be ciphered& Trustby a private key
Security, Privacy
Secure storage of data should be ensured.
& TrustThe platform shall be able to aggregate datafrom various sources using LOD principles
NFREQ.18&
NFREQ.22
NFREQ.13&
NFREQ 16

To guaranty data integrity and make sure thedata can't be stolen or replicated.

Demonstration
Business Scenario

System use caseComments

Geographical location should be part of standardVE and Service metadata used for
discovery and lookup

IoT Service,
Virtual Entity,
IoT Resource,
DevicesInteroperability

Virtual Entity,
IoT Resource!!! We have not planned so far T&R mechanisms

EUE-16, WA-11

IoT Service,
Virtual Entity,
IoT Resource,
Devices

EUE-2, EUE-11, WA-2

EUE-11, EUE-14 (partly), WA-11

FREQ.22FREQ

MEDIUM

FREQ.23

FREQ

HIGH

FREQ.24FREQ

MEDIUM

FREQ.25

FREQ

HIGH

Security, Privacy Communicated data MUST remain& Trustconfidential if needed.

FREQ.26

FREQ

HIGH

Service providers MUST be able to set
Security, Privacy
access-control rights/ policies (set up by& Trustservice owners) to their services

NFREQ.9

Functional
View

Security,
PrivacyIoT Service,
Virtual Entity,

AuthN, AuthZ,

FREQ.30

FREQ

HIGH

Security, Privacy CPaaS.IO MUST be able to evaluate access& Trustrequest depending on access control policies.

NFREQ.9

Functional
View

Security,
PrivacyIoT Service,
Virtual Entity

AuthN, AuthZ, VE
Service, IoT Service

Access is quite vague here, must include access to Data, Discovery, Service invocation
etc…

HIGH

CPaaS.IO MUST provide an authorization
policy to data, object and service for the
Security, Privacy
different users or devices which in turn will
& Trusthave to be authenticated and auhorised
before accessing them

Functional
View

Security

IoT Service,
Virtual Entity,
Management

AuthN, AuthZ, Web FrontEnd

Not only the user must define access policyfor his data but the platform must also grantauthorization to the user for using services or accessing objcts. Meregd with FREQ.34,
FREQ.35, FREQ.36 & FREQ.37

User (CPaaS.io client) or device as part of theplatform deployment MUST be registered
Needed for authentication and authorisation
before using any services provided by theplatform.

Functional
View

Security

Security,
Management

Identity Management,
Web Front End

Users and devices MUST be identified

Functional
View

Security

Security

AuthN, Identity
Management

NFREQ.20

Functional
View

Security,
Privacy

Security,
Management

ConsentManagement,
Web Front End

FREQ.31

Functional
View

Security,
Privacy

Security

AuthZ!!! Context needs to be define (in that context)

Functional
View

Security

Security

Accountability,
Accounting!!! Missing in Arch v1. Non-repudiation needed

FREQ.31

FREQ

FREQ.32

FREQ

HIGH

Management,
Security

FREQ.33

FREQ

HIGH

Management.
Security

In some scenario, a formal aggrement from
User's data MUST be processed only with thethe data owner is necessary for theuser's consent.
exploitation of personal data

FREQ.38

FREQ

HIGH

FREQ.39

FREQ

HIGH

Security, Privacy CPaaS.io MUST support context-aware& Trustaccess policies.

FREQ.50

FREQ

HIGH

Services MUST maintain a log of the
Security, Privacy
operations done by users. This log shall not& Trustbe modified by attackers.

FREQ.60

FREQ

HIGH

Platform,
Discovery,
LookupTime stamps MUST be supported.

Basic meta-data needed for many aspects
like data query, time-series building,causality detection

HIGH

Social needs,
City Data,
Platform,
Infrastructure

The IoT system MUST ensure thatprocessing of information takes place on
trusted nodes.

Only trusted nodes can be involved in
CPaaS.io platform

FREQ.70

FREQ.71

FREQ.72

FREQ

FREQ

FREQ

MEDIUM

HIGH

H2020 EUJ-02-206

Privacy

For security and privacy issue it must be
possible to cypher communication

for security reason it is important toremember whom did what, and make sure
non-repudiation is ensured
FREQ.9 &FREQ.13

Information
View

Functional
View

Pending AP

Virtual Entity,
IoT Service

FREQ.13

Any data at the platform level shall beInteroperability following a accepted set of standard
schemas (ontologies) for annotation

Originating
Business Scenario!!! We probably will have to include FCs from Service Organisation and IoTProcess MNGT FG as well.

EUE-13or associated with an ID, or authenticated? (to be clarified)

IoT Service,
Virtual Entity

Security, Trust

ServiceOrganisation,
IoT process
Mngt

Task Deployment,
Processing Optimization

ServiceOrganisation,
IoT process
Mngt

Task Deployment,
Processing Optimization

The IoT system SHOULD optimize theprocessing of information with respect to a
Load Balancing
cost function, e.g. communication,
computation, energy, etc.

NFREQ.2,
FREQ.72,
FREQ.70

Functional
View

Performance,
Resilience

The CPaaS.io platform MUST be able to
Load Balancing,
provide mechanisms for migrating tasks toPart of the Cloud and Edge programming
Bandwidthnodes participating the CPaaS.io systems
objectives of the project
Optimizationaccording to its characteristics and availability

FREQ.71

Functional
View

Performance,
Scalability,
Resiliencechanged from MEDIUM to HIGH. Standard semantic annotation must include timestamp when relevant

Which implies some kind of peer-authentication and provision of security credential at
the node level.

Added availability

CPaaS.io

Page 77 of 78

Deliverable D3.2

Requirements

Volere Template

Traceability regarding the architectural reference model

Req. TypePriority

Category

Description

Rationale

Dependenci
esFREQ.72

FREQ

HIGH

Platform,
Management

It MUST be possble to describe thecapabilities of the platform nodes in term of
memory, CPU and network capacity

This basic information is needed by thedecision making process that decides how
and where tasks must be deployed

FREQ.80

FREQ

HIGH

Platform

UNI ID

FREQ.90

FREQ

HIGH

Platform

FREQ.91

FREQ

HIGH

Platform

FREQ.92

FREQ

LOW

Platform,
Management

FREQ.93

FREQ

LOW

Platform

FREQ.100

FREQ

HIGH

FREQ.110

FREQ

HIGH

FREQ.111

FREQ

HIGH

FREQ.112

FREQ

HIGH

FREQ.113

FREQ.114

FREQ.115

FREQ

FREQ

FREQ

CPaaS.io platform MUST be able to perform Analytics and event detection is part of basic
analytics, and event detection/prediction using functionalities for leveraging raw data andproducing value-added knowledge“live” and historical data
The CPaaS.io platform MUST provide publish/ subscribe functionality and criteria forfiltering in/out data based (at least) on
geographical area, data type and data source
The CPaaS.io platform MUST provide
Complex Event Processing techniques that
This technique allows to infer data from a
are able to infer high level events out of anlive data stream. It can be coupled with ML
incoming flow of data, based on various
for infering production
criteria (condition for that event to be
triggered)
It must be possible to assess that data
The CPaaS.io platform MAY provide data
follows the ontology it is expected to comply
validation services
with
The CPaaS.io platform MAY provide afunctionality to map between common RDF
identifiers and vocabularies

Discovery,
It MUST be able to describe data sets
lookup,(content-wise and access-wise) in order toInteroperability allow for discovery and lookup

CPaaS.io System Architecture (v1)

View

Perspective

NFREQ.71

Information
View

Performance,
Scalability

FREQ..91

Functional
View

IoT Service,
Virtual Entity

Functional
View

Communication Communication Channel

Functional
View

IoT Service,
Virtual Entity

CEP Engine

Semantic Validator

FREQ.117

Conflicts

Functionality
Group

Functional Component Domain Model

Originating
Business Scenario

Demonstration
Business Scenario

System use caseComments

Devices

Analytics, Rule-based
Reasoner, CEP Engine

Functional
View

Interoperability

Management

Functional
View

Interoperability

Management!!! To be discussed!!! To be discussed if we need a specific FC. EUE-15!!! Missing in Arch v1

For legal reasons some data may not be
stored by the platform directly.

Information
View

IoT Service

All services require the collection andstorage of real-time data and historical data

Functional
View

IoT Service,
Virtual Entity

Semantic VE Data
Repository, Semantic
Data Repository

In order to empower people about theCity Data, Data The platform MUST provide mechanisms for
management of their own data and makeCollection,
presenting data & personal data in a user
and associated access right, this data must
Platformfriendly form
be presented in a user firendly form

Functional
View

Management

WEB Front End

EUE-3, WA-7

Analytics, Preprocessing,!!! The exact nature of analytics functionalities will have to be confirmed. EUE-4. Post processing is captured in Analytics FC

City Data,
Platform

The p/f MUST provide mechanisms forcollecting, publishing and storing semantic
data (historical data)

Usability

EUE-7, EUE-16, WA-1

City Data,
Platform

The p/f MUST provide some analytics for(pre/post) processing data

Before being published (and annotated), raw
data needs some processing

Functional
View

IoT Service,
Virtual Entity,

Platform

The p/f SHOULD offer means forsynchronizing clocks between IoT devices

Time synchronization is required so that
sensor data from different sensors can becorrelated by time

Functional
View

Management

City Data, Data The p/f MUST be able in certain
Collection,
circumstances to pull data from the IoT
Platform
resources

In some cases the data should be pulled
directly by the platform from data producers
instead of being produced towards theplatform by data producers

Functional
View

ServiceOrganisation,
VE Service, IoT
Service

IoT Resource Manager,
IoT Service, VE Service
End-Point!!! To be checked if there is a need for additional FC. More form Service
Organisation FG probably. YEM-1 & TPT-1

MEDIUM

Platform,
Management

In some scenario (medical e.g.) it isimportant to provide an App for dealing withconsent management, especially when
dealing with Personal information.

Functional
View

Management,
Security

Consent Management,
Web Front End

YEM-2

Functional
View,
Information
View

IoT Service,
Virtual Entity

IoT Service, VE Service
End-Point

When explicit actuation is performed, actuation observation should be published.
Actuationobservation should also be published from the external RDP. WA-2. Priority
should probably be moved from Medium to High (TBD)

MEDIUM

HIGH

The p/f SHOULD provide consent
management functionalities

FREQ.116FREQMEDIUM

For some scenarios, not only sensor data
City Data, Data
It SHOULD be possible to publish data about are important, but also information about
Collection,
actuation
actuation (like when a pipe is opened/closed
Platformand for which duration.

FREQ.117FREQ

MEDIUM

City Data, Data
Collection,
Data of type "event" SHOULD be supported
Platform

FREQ.118

FREQ

LOW

Platform,
Management

DC.1

DC

HIGH

Infrastructure,
Networking

FREQ.119

FREQ

HIGH

Platform,
Infrastructure

The p/f MUST be able to host and serve IoT
Services and VE Services locally

FREQ.120FREQ

MEDIUM

Platform,
Management

End-users SHOULD be able to perform
managing operation using a WEB Front End

FREQ.121FREQ

MEDIUM

Security

The p/f SHOULD provide non-repudiation
mechanisms

H2020 EUJ-02-206

Not only information about devices aremeaningful. CPaaS.io should also support
events and alert

The p/f SHOUD be able to collect andmanage user 's feedback
Data transmission is modulated with LoRa,
Data received in application server via TTN
operated by The Things Network network
server. The application needs to be integrated API
with TTN API
Some IoT Resource owner do not have any
infrastructure for running IoT Services
exposing their IoT Resources
General Usability issues like providing theend-user with human readable and user
friendly interfaces to the different CPaaS.io
FC
For scenario that include actuation it ishighly crucial to provide this functionality

FREQ.38

FREQ.91

Pending AP!!! This functionality has not been planned for V1. Still to be discussed

Information
View

The ontology must support the concept of event. WA-9.

Information
View!!! User feedback mechanisms have not been agreed upon yet. TBD. WA-10 &YEM-5 & TPT-10

Management!!! TBD

Functional
View

IoT Service

IoT Service

Functional
View

Usability

Management

Web Front-End

Functional
View

Security

Security

KEM, Accountability,
Accounting

CPaaS.io

Needed for scenarios where IoT Services are not served by the party manging the IoT
Resources!!! Non present in the current V1

Page 78 of 78