The platform architecture developed by the CPaaS.io project - both the overall system architecture as well as the two implementation architectures, one based on FIWARE and the other on u2 - as presented at the first year review meeting in Tokyo on October 5, 2017. Disclaimer: This document has been produced in the context of the CPaaS.io project which is jointly funded by the European 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 that the information is fit for any particular purpose. The user thereof uses the information at its sole risk and liability. For the avoidance of all doubts, the European Commission and NICT have no liability in respect of this document, which is merely representing the view of the project consortium. This document is subject to change without notice.

1. City Platform as a Service – Integrated and Open
WP 3: Platform Architecture
Klaus Mößner (University of Surrey)
Noboru Koshizuka (University of Tokyo)
Year 1 Review Meeting, Tokyo
October 5, 2017

2. Overview
29.11.2017 CPaaS.io - Consortium Confidential 2
WP 7: Impact Generation
WP 3:
Platform Architecture
WP 4: Cloud & Edge Programming
WP 5: Citizen Empowerment for Data Privacy
WP 6: Holistic Data Management & Governance
WP 8: Project Management
WP 2: Use Cases & Trials
WP 1: Ethics Requirements

3. Involved Participants
29.11.2017 CPaaS.io - Consortium Confidential

4. Main Results
• Obj1: Perform a requirements analysis & cross-check
 Requirements analysis done and preliminary requirement mapping
achieved;
• Obj2: Design the CPaaS.io system architecture
 First version of IoT ARM-compliant system (logical) architecture;
 First version of each a FIWARE- and u2- based platform instantiation view;
• Obj3: Perform system integration
 EU-side: FIWARE and security components are integrated and tested with
simple WP2 use cases;
 Japan-side: in u2 architecture IoT components, open data components, and
PDS (omotenashi-platform) components are integrated.
29.11.2017 CPaaS.io - Consortium Confidential 4

5. IoT-ARM methodology (Architecture Reference Model)
What is it made of?
29.11.2017 CPaaS.io - Consortium Confidential 5
• IoT Reference Model to promote common understanding
 High abstraction level
 Describes the aspects of the IoT domain that do not change
 Enables a general discourse on the IoT domain
 Provides a Domain, Information, Functional, Communication and Security models
• IoT Reference Architecture to describe essential building blocks and identify design
choices
 Based on IoT Reference Model
 Reference for building compliant IoT architectures
 Provides views and perspectives on different architectural aspects that are of concern to
stakeholders
• Guidelines to help in developing an architecture for a specific system based on the
IoT Reference Architecture
 Provide different types of guidance: process, usage per model and view, examples etc…
IoTARMframeworkand
methodology

6. Guidance through IoT ARM Process
29.11.2017 CPaaS.io - Consortium Confidential 6
IoTARMframeworkand
methodology

7. IoT ARM Reference Model
29.11.2017 CPaaS.io - Consortium Confidential 7
Attribute
attributeName
attributeType
ValueContainer
MetaData
metadataName
metadataType
metadataValue
VirtualEntity
identifier
entityType
ServiceDescription
Association
Value
Resource
Description
Device
Description
0..* 1..*
1
0..*
metadata
0..1
0..*
Information Model:
structure (e.g. relations,
attributes) of all the
information (data) that is
handled in an IoT system
Domain Model: Core concepts of IoT
and their relations - independent of
specific technologies
Device
Physical
Entity
Service
exposes
Resource
hosts
Association
Virtual
Entity
models
User
interacts
invokes
Functional Model: Functional
groups of an IoT system and their
relations
Management
Security
Application
IoT
Process
Management
Virtual
Entity
IoT
Service
Communication
Device
Service
Organisation
IoTARMframeworkand
methodology

8. IoT ARM views
• Physical Entity view
• Context view
• Functional view
• Uses the FM as canvas for describing the system “logical” functional
decomposition
• Information view
• Modelling of information / ontologies / data storage
• inter-FC data flows & interactions through System use-cases
• Instantiation view (new – CPaaS.io)
• Instantiation of “logical” FCs into “concrete” FCs and mapping information
• Deployment view
29.11.2017 CPaaS.io - Consortium Confidential 8
IoTARMframeworkand
methodology

9. Results in Year 1
Summary and Discussion
29.11.2017 CPaaS.io - Consortium Confidential 11

10. Results in Year 1
• Requirement Analysis
• Platform requirement collection
• Requirement Analysis and mapping
• VOLERE template summarises the outcomes of this first phase
• System Architecture (IoT ARM compliant)
• Functional view v1 which introduces needed Functional Components (FC)s
• Information view v1: System UCs describing flows of information and
interactions between FCs
• Set of perspectives
• 2 instantiation views with concrete FC mapping figure and table
• Platform integration(s) (u2- & FIWARE- based))
29.11.2017 CPaaS.io - Consortium Confidential 12

11. Requirement Analysis (1/2)
Tasks
1. Collect platform requirements (FReq & NFReq)
2. Unified with use-case requirements
a. Understand: x-check with issuers and rewrite if necessary
b. Adopt uniform terminology / split / factorise / rewrite
3. Analysis  requirement mapping
 FReq: identify target FC (functional decomposition) and impacted
Domain Model concept  Functional & Information views
 NFReq: identify target perspectives
29.11.2017 CPaaS.io - Consortium Confidential 13

12. Requirement Analysis (2/2)
Fragment of VOLERE template
29.11.2017 CPaaS.io - Consortium Confidential 14

13. System architecture (1/3)
Overview
• Consists of a set of views and perspectives (main focus in period 1 was on
views)
• Functional view:
• Set of functional groups and components organised along the IoT ARM Functional
Model
• Logical components with high-level descriptions
• Those high-level functionalities need being implemented in both derived u2- and
FIWARE- based concrete architectures
• Information view:
• Identifies typical usages of logical FCs (simplest ones in Arch v1)
• Describes those usages through UML use-case and interaction diagrams (so-called
system use-cases)
• An extensive set of system UCs can be seen as a CPaaS.io platform cookbook.
• Perspectives: few ones have been identified already (e.g. security and
interoperability) and technical objectives described
• 2 instantiation views with FC mapping
29.11.2017 CPaaS.io - Consortium Confidential 15

14. System architecture (2/3)
“logical” vs. “concrete”
29.11.2017 CPaaS.io - Consortium Confidential 16
“Logical”
architecture
U2- based
architecture
FIWARE- based
architecture
“logical” views “concrete” views (instantiation)
• Logical components  concrete components
• Logical system UCs  concrete system UCs
• Mapping tables (u2 and FIWARE instantiations)

15. System architecture (3/3)
“logical” Functional View
29.11.2017 CPaaS.io - Consortium Confidential 17

16. Platform Integrations
Achievements
• EU-side:
• Integration of FIWARE components (IoT-broker / Context-broker / IoT
Discovery / IoT Knowledge Server) + Security components
• Tested with simple use-cases from Waterproof Amsterdam/colour run
scenario
• Japan-side:
• Functional level integration of several components (IoT Aggregator,
IoT Engine, OPaaS.io, open data distribution platform, eTRON) into
integrated u2 architecture.
• Tested with Sapporo Event Management scenario.
29.11.2017 CPaaS.io - Consortium Confidential 18

17. 29.11.2017 CPaaS.io - Consortium Confidential 19
Architecture
Achievements

18. CPaaS.io Platoform/JP side
Based on CPaaS.io System Architecture
29.11.2017 CPaaS.io - Consortium Confidential 20
IoT-Engine
(μT-Kernel)
ucode
BLE
ucode
NFC
ucode
QR
IoT Aggregator
* Tunneling
* Device Access Control
ucode Resolution Module (ucode+ucR Manager)
ucode RP
* ID Resolution * IoT Service Finding
ucR Query Protocol
* SPARQL-Based * REST-based
eTRONSecurityArchitecture
eTP(EntityTransferProtocol)
eTRONTags
OPaaS.io
* Personal Data Store
*Access Control
of Privacy Data
u2 Open Data Catalog KokosilIoT Translation Engine
Open Data
Distribution
Platform
Smart City Services
Other Platform
(External)
City Government Data (Static)
Obtained from Other Data Stores
Personal Data
Sensor/Realtime Data (Dynamic)
Obtained from City Infrastructures
Applications & Services
Information Services Layer
& Analytics Layer
Semantic Integration Layer
IoT Services Layer (Cloud Side)
IoT Services Layer (Edge Nodes Side)
Privacy,Security&Trust
Data Resources
WP2 WP2
WP2
WP3 WP4
WP3
WP5
WP5WP6
WP6
WP4
WP2 WP5WP4

19. Components in u2 Open IoT Platform
IoT-Engine
 IoT-Engine is a standard development platform,
standardized by TRON Forum, for Open IoT to realize
"Aggregate Computing". The RTOS used on the IoT-
Engine is µT-Kernel 2.0 which TRON Forum releases as
open source.
ucode BLE, ucode NFC, ucode QR
 ucode BLE, ucode NFC, and ucode QR are tiny devices
which export ucodes in several communication media.
IoT Aggregator
 IoT Aggregator implements "aggregate computing model"
which uses all devices, services and systems connected to
the network to achieve desired services. It tries to offer a
holistically optimized IoT service by mixing various devices
and services as a whole.
OPaaS.io (Omotenashi Platform)
 OPaaS.io (Omotenashi-Platform as a Services) is the
general-purpose Personal Data Store (PDS) in u2 Open
IoT Platform. "Omotenashi" means "hospitality" according
to personal conditions in Japanese.
Open Data Distribution Platform
 Open Data Distribution Platform contains data storages
for open data in ucR-based format, and APIs for the data
storage.
 It deals with both static open data such as statistic data
and real-time/dynamic open data such as sensor data.
eTRON
 eTRON (Entity and Economy TRON) is a security
architecture in u2 Open IoT Platform.
 It consists with ETP (Entity Transfer Protocol), which
exchanges valued data securely, and eTRON Tag, tamper
resistant smart card supporting ETP, etc.
29.11.2017 CPaaS.io - Consortium Confidential 21

20. Components in u2 Open IoT Platform
u2 Open Data Catalog
 u2 Open Data Catalog provides a data catalog for open
data which uses "Open Data Distribution Platform". cKAN
and dKAN are used for its core module.
IoT Translation Engine
 IoT Translation Engine realizes multilingual IoT Services
and Open Data Services. It utilized automatic translation
technologies.
Kokosi
 Kokosil is the location-aware information service platform
of u2 Open IoT platform architecture.
 It is mainly used for tourism support information services.
ucode Manager
 To identify individual objects, spaces, and concepts in the
real world, unique identifiers are assigned to respective
objects, spaces and concepts that we wish to identify.
 Information associated with ucodes, namely, the ucR
graph is registered in the ucR database. The protocol for
accessing the ucR database in this manner is called ucode
Resolution Protocol (ucodeRP).
ucR Manager
 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.
 ucR Manager provides APIs both in REST API format and
in SPARQL format.
29.11.2017 CPaaS.io - Consortium Confidential 22

21. Platform Integration – EU Side (1/3)
FIWARE-based architecture
29.11.2017 CPaaS.io - Consortium Confidential 24
• Three-layered view of the
integration
• Layer 1: IoT devices
• Layer 2: Context & process
management
• Layer 3: Security layer
• Current system allows
FIWARE and SPARQL app
developers (shown on top)

22. Platform Integration – EU Side (2/3)
FIWARE- instantiation view (with FC mapping)
29.11.2017 CPaaS.io - Consortium Confidential 25

23. Platform Integration – EU Side (3/3)
Next steps of system integration
• FogFlow component to be deployed (it is already integrated
with IoT Broker)
• Integration of security layer with IoT Broker (in progress)
• Adapter from NGSI to SPARQL (in progress)
• Collecting data from other use cases (in progress)
• Adapters for possible other use cases (not started)
29.11.2017 CPaaS.io - Consortium Confidential 26

24. Plan for Year 2
Outlook
29.11.2017 CPaaS.io - Consortium Confidential 27

25. WP3 Outlook
• Provide V2 of functional decomposition with focus on
• Edge computing, semantic integration layer, analytics and platform federation
(both FIWARE and u2 instances)
• Extend the collection of logical system UCs
• Revise the two instantiation views with:
• Additional FCs
• Interface and functionalities & API level integration study (esp. IoT Aggregator, Omotenasi Platform,
and open data distribution platform)
• Updated FC mapping figure and table
• Introduction of „concrete“ system UCs in the form of sequence charts
• Elucidate the tactics/design choices for the inter-operability perspective and platform
federation
• Continuously integrate more FCs to the 2 concrete CpaaS.io platforms
• Integrate with relevant scenarios
• Evaluation of architecture from the view of IoT applications and services
• Starting study for interoperability between FIWARE and u2 architecture.
29.11.2017 CPaaS.io - Consortium Confidential 28

26. Gracias Mulțumesc 謝謝 Paldies Eskerrik asko Dziękuję Mahalo ‫תודה‬ Go raibh maith agat спасибо Grazzi आभारी
Xin cảm ơn 감사합니다 நன்றி Köszönöm ‫مرسي‬ Ndiyabulela Grazia Tak Благодаря Aitäh Terima kasih Děkuji
Asante Diolch ‫شكرا‬ Takk Ďakujem Gràcies Kiitos Obrigado Teşekkür ederim Ngiyabonga Þakka þér Grazas
Tapadh leibh ขอบคุณ Faleminderit Ačiū Danke Merci Grazie Hvala Ευχαριστώ Dankon Tack Dank je Grazcha
…
Thank You
ありがとう
This document has been produced in the context of the CPaaS.io project which is jointly funded by the European
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 that the information is fit for any particular
purpose. The user thereof uses the information at its sole risk and liability. For the avoidance of all doubts, the European
Commission and NICT have no liability in respect of this document, which is merely representing the view of the project
consortium. This document is subject to change without notice.
29.11.2017 CPaaS.io - Consortium Confidential 29