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

Deliverable D8.4

Final Report: Summary of
Outcomes
Version V1.2
March 1, 2018

ABSTRACTThis report summarizes the CPaaS.io project and its results. With the main
objective of delivering a Cloud-based, IoT and Open Data platform to enable
Smart City innovation, the project yielded a variety of results that will foster thedevelopment of Smart Cities also after the conclusion of the project: A common
functional architecture with a toolbox of implementation components that can be
combined for deploying a Smart City platform, mechanisms for federating
platform instances and for dealing with personal data, and supporting tools for
blueprinting Smart City applications and for analyzing and developing Smart City
strategies.

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/.

Deliverable D8.4

Final Report: Summary of Outcomes

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 respect of
this document, which is merely representing the view of the project consortium. This document is subject
to change without notice.

Document Information
Editors
Authors
Reviewers
Delivery Type
Dissemination
Level
Contractual
Delivery Date
ActualDelivery Date
Keywords

H2020 EUJ-02-2016

Stephan Haller (BFH), Chiaki Ishikawa (YRP)
Stephan Haller (BFH)
Klaus Moessner (UoS), Fahim Khan (UoT)
R
PublicDecember 31, 2018
December 31, 2018
Smart City Platform, FIWARE, u2, Federation, Personal Data Store,
Application Blueprints, Smart City Canvas, Strategy Framework

CPaaS.io

Page 2 of 40

Deliverable D8.4

Final Report: Summary of Outcomes

Revision History
Rev.
0.1
0.2

Date
21.11.201805.12.2018

0.3

07.12.2018

0.4
0.5
1.0

24.12.2018
25.12.2018
28.12.2018

1.1

22.02.2018

1.2

01.03.2018

H2020 EUJ-02-2016

Description
ToC
Added sections 2.1 (Conceptual
outcomes) and 2.2 (FIWARE
Toolbox)
Added 2.5 (Smart City Strategy
Framework and Blueprint
Template)
Added 2.3 (u2 Toolbox)
Reviewed version
Added SEDAQ and finalized
document
Updated Figure 4, smaller error
corrections
Updated Figure 6

CPaaS.io

Contributors
Stephan Haller (BFH)
Juan Antonio Martinez (OdinS)
Everton Berz (NEC)Stephan Haller (BFH)

Noboru Koshizuka (UoT)
Klaus Moessner (UoS)
Adrian Gschwend (BFH), Stephan Haller (BFH)
Stephan Haller (BFH)
Chiaki Ishikawa (YRP)

Page 3 of 40

Deliverable D8.4

Final Report: Summary of Outcomes

Table of Contents
1

Project Overview...................................................................................................................................................................... 5

2

Project Outcomes.................................................................................................................................................................... 7

3

2.1

Conceptual Outcomes.................................................................................................................................................. 8

2.2

FIWARE Toolbox ........................................................................................................................................................... 12

2.3

u2 Toolbox...................................................................................................................................................................... 17

2.4

Tools Supporting City Developers ......................................................................................................................... 23

2.5

Concrete Results in Cities.......................................................................................................................................... 29

Summary and Outlook ........................................................................................................................................................ 35

References ......................................................................................................................................................................................... 36
Appendix: Smart City Toolbox Flyers ...................................................................................................................................... 37

H2020 EUJ-02-2016

CPaaS.io

Page 4 of 40

Deliverable D8.4

Final Report: Summary of Outcomes

1 Project Overview
The CPaaS.io project was a 30-month research project jointly funded under the Horizon 2020 programmeby the European Commission and the National Institute of Information and Communications Technology(NICT) in Japan and ran from July 2016 to December 2018. The acronym stands for "City Platform as aService - Integrated and Open".
The overall goal of the project was to develop a cloud-based urban data platform for Smart City innovation.
The platform combines Internet of Things (IoT) with Open Government Data (OGD) and gives access to thedata via open APIs or as Linked Data, so that others can build new services and applications on top of theplatform. As such, the platform supports bottom-up and co-creation approaches that are used in many
cities, e.g., Amsterdam, Zurich or Tokyo.

Figure 1: CPaaS.io combines IoT, Big Data, and Cloud with Linked Data and Open Government Data to create Smart City
Innovation

The practical relevance of this platform has been evaluated and reviewed in cooperation with several cities
that already had previous experience in the Smart City and Open Data domains. In Europe these are
Amsterdam, Murcia and Zurich, in Japan these are Sapporo, Tokyo and Yokosuka.
Overall, the project had the six objectives. Table 1 lists this as well as how they have been achieved.

H2020 EUJ-02-2016

CPaaS.io

Page 5 of 40

Deliverable D8.4

Final Report: Summary of Outcomes

Table 1: Project objectives and achievements

Objective
Develop an open social city platform

Achievements

Open in the sense of open data, the platform isaccessible to any interested party who then can build
value-added applications and services on top of it.
Open also in the sense of open innovation, additional
data sources like sensors operated by private citizens,
small start-up companies or established infrastructure providers caneasily be integrated into the platform and the resulting data can bemade available to all. The platform – operated by or on behalf of a city– thus forms the basis for an open digitized society, making the city
more attractive for its citizens and new businesses, and also helping
the city in streamlining and improving its own governmental processes
and services.

Deploy the city platform as a service solution
The objective is to develop a cloud-based open
platform for all city information offering multiple
services and the capability for federation with otherplatform instances. Flexibility and elasticity will be key
principles in the design of the architecture in order tosupport the deployment in many different cities with differing
requirements, both regarding use cases, services and operational
aspects. The platform will also annotate such inherently unreliable IoT
data with quality parameters, so that applications can decide if the data
quality is good enough to be used.

Empower the citizen to her data
A platform with city information as targeted by
CPaaS.io will also have data about its residents – inparticular with the envisioned linking of IoT data with
OGD. The platform must thus provide all necessary
security mechanisms for the desired privacy and dataprotection properties to materialize. However, by simply restricting allaccess to such data, the potential benefits for the individual as well as
for the society at large of using such data are lost. CPaaS.io is therefore
taking a more progressive stance using a MyData approach: let thecitizen control who can access which personal data under whatcircumstances.

The project developed a common functionalarchitecture consisting of several layers and all
required functionality (cf. section 2.1.1), and two
instantiations using concrete technologies, one
based on FIWARE (cf. section 2.2) and one based onu2 (cf. section 2.3). These instantiations are at
Technology Readiness Level (TRL) 7, i.e., systemprototypes have been demonstrated in the relevant
operational environment. Users can access theplatform instances and retrieve data via the respective
platform APIs1, or also via semantic SPAQRL queries.

Federation between platform instances is possible via
the respective APIs or via Linked Data approaches (cf.
section 2.1.2). To achieve flexibility, the projectcontributed significantly to the development of a new
FIWARE Generic Enabler called FogFlow. FogFlow is an
IoT edge computing framework that automaticallyorchestrates dynamic data processing flows overcloud and edges based on context.
CPaaS.io influenced the ETSI ISG CIM standard andthe NGSI-LD API which merges open linked data andthe FIWARE NGSI API2. In addition, a data quality
ontology has been defined (cf. section 2.1.4) toenable quality annotations.
The MyData approach has been rigorously followed
and instantiated in form of Personal Data Stores(PDS) that have been integrated and used in order toprotect personal data and to give the user control
over her data (cf. section 2.1.3). In particular, the PDS
is a central piece for the Japanese Omotenashi
hospitality solution, improving the tourism experiencefor overseas visitors (e.g., visitors to the Tokyo
Olympics 2020).

Validate the platform with use cases providing public value
The platform will be deployed and validated by
implementing several use cases that provide public
value in cities, be it to the urban society as a whole,
be it to individual citizens and city visitors, or be it to
the city administration. While for the validation of theuse cases public value and acceptance are the top criteria, the CPaaS.io
platform itself will be validated along several additional dimensions: its
technical feasibility and performance, ease of deployment andoperation, transferability and robustness, and economic benefits forthe various stakeholders.

Use cases have been implemented and piloted in fourdomains: Event management (Sapporo, Utrecht),water
management(Amsterdam),publictransportation & mobility (Tokyo, Murcia) as well as
emergency medical care (Yokosuka).
The success of these implementations led toadditional projects in other cities based on the
CPaaS.io technology, i.e., in Heidelberg, Miura andKochi (cf. section 2.5).

1 For the FIWARE NGSI APIs please refer to- https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FI-WARE_NGSI_Open_RESTful_API_Specification
Several API descriptions are available for the Japanese platform instantiation, e.g.,- General Open Data Platform APIs (VLED): http://www.vled.or.jp/results/docs/gaibu-shiyou-2-201501.pdf- Omotenashi Platform APIs: http://www.soumu.go.jp/main_content/000406839.pdf
2 See https://docbox.etsi.org/ISG/CIM/Open/ISG_CIM_NGSI-LD_API_Draft_for_public_review.pdf
H2020 EUJ-02-2016

CPaaS.io

Page 6 of 40

Deliverable D8.4

Final Report: Summary of Outcomes

Objective
Develop blue prints for the adaptation and transfer ofsolutions to other cities

Achievements

One of the main reasons for implementing CPaaS.io
as a joint EU-Japan project is to demonstrate thatconcepts and use cases developed in one city can betransferred to other cities even when crossing culturalbarriers and when dealing with different ways in whichcity, regional and national governments are structured. The project will
therefore develop blue prints to make such transfers easy, coveringboth technical and process aspects as well as the holistic approach toprivacy and security across the value chain, independent of the city inwhich the applications are used and data is exploited.

A template for Smart City application blue prints
has been defined, consisting of various documentsthat help city developers both when initializing as wellas when transferring Smart City applications. The
cornerstones of the template are a Smart City Canvas
to capture the essence of the use case and where
public value is created, as well as an application onepager, summarizing the different aspects that appear
along the value chain.

Create impact in cities
Creating impact beyond the partners of the project isin essence the ultimate goal. The project will therefore
actively promote the results through its City
Stakeholder Board. In addition, public administrations
usually place a great importance on systems that
conforms to standards, hence the project willemphasize de facto and de jure standardisation in the relevant areas
like IoT, Linked Data, Smart City and E-Government.

The partner cities have already been impacted by the
project work and approach through theimplementation of the relevant use cases, these willcontinue to be used and enhanced even after the
project has ended, the cities have committed to thisalready. And other cities have started to implement
solutions based on the CPaaS.io architecture.
Furthermore, a number of standards have been
influenced, in particular ETSI ISG CIM and the AIOTIWG3 Subworking Group “Semantic Interoperability”.
And finally, a Smart City Strategy Framework has
been proposed that supports cities in their strategicwork.

2 Project Outcomes
The CPaaS.io project has resulted in a set of conceptual outcomes, concrete tools and city implementations
that will live on beyond the project. This set is depicted in Figure 2. The foundation for all results are anumber of conceptual outcomes that are relevant for the platform as a whole and across the regions. The
concepts are implemented using specific tools for the two implementation platforms, one for FIWAREbased implementations and one for u2-based implementations. A third toolbox contains instruments thatmake life easier for city planners and developers. And finally, the project has resulted in concrete use case
deployments in various cities in Japan and Europe, using the tools provided by the project.

Figure 2: Overview of the CPaaS.io project outcomes

In the following sections an overview is given on all these outcomes as well as an outlook how these results
can be sustained in the future.
H2020 EUJ-02-2016

CPaaS.io

Page 7 of 40

Deliverable D8.4

Final Report: Summary of Outcomes

2.1 Conceptual Outcomes
2.1.1 Functional Architecture
Figure 3 presents the system architecture where the different layers that it is composed of are alsopresented.

Figure 3: CPaaS.io system architecture

We can highlight that the platform comprises four horizontal layers, as well as two traversal ones. Let us
give some details for all of them following a bottom-up approach:
•

•

•
•

IoT Data & Ingestion Layer represents the context information acquired by our platform. It follows
the NGSI interface so that a unified representation of information is carried out. Our main component
responsible for this task is the IoT Broker which, thanks to the IDAS module, incorporates theinformation to the platform.
Virtual Entity Layer: Taking advantage of the NGSI interface, and thanks to our Context Broker we
can generate aggregated information for required virtual information that services, and application
placed at the upper layer will use.
Semantic Data & Integration Layer: This layer allows a richer information representation andexpression of relations among the stored information
Knowledge Layer: Finally, this layer contains the Machine Learning (ML) component which
implements different algorithms for different purposes extracting information available from Social
Media. This layer contains the aggregated and processed information that is exploited by Smart City
upper-layer services and applications.

The two traversal features are the Platform Management Federation and Operation Pillar and the Security& Privacy Pillar.

H2020 EUJ-02-2016

CPaaS.io

Page 8 of 40

Deliverable D8.4••

Final Report: Summary of Outcomes

Platform Management Federation and Operation Pillar: As its name indicates, this pillar comprises
the components that simplify deployment of the platform. Actually, the more remarkable component
in this pillar is FogFlow, which allows for dynamic deployment in both edge and cloud layers.
Security & Privacy Pillar: Finally, this pillar contains the enablers that guarantee secure & private
exchange of information by employing security mechanisms such as authentication, authorization.
Privacy is also applied by providing a mechanism that encrypts the data stored in the platform andallow only the legitimate consumers to decrypt it.

In addition, this architecture is based on open and standard protocols and mechanisms such as the
adoption of NGSI for exchanging information based on HTTP or the use of the XACML framework as abaseline for our authorization scheme. Although an alternative and also viable approach for developing
the CPaaS.io platform would have been a development based on closed and proprietary technologies, wefollowed the philosophy that our main outcome should not be one enclosed product containing all thecomponents and enablers necessary, but rather an open and federated platform capable to embracedifferent cultures and instantiation approaches, as we demonstrated with our FIWARE based European andthe u2-based Japanese instantiations of the platform. The most significant outcome therefore is thecommon architecture, which is instantiated by both sides of this project, as can be seen in Figure 4.

Figure 4: Instantiation of our functional architecture based on FIWARE (right) and based on u2 (left)

This functional architecture can be regarded as one of the main outcomes of the project, as everythingelse is building on top of it. It provides the definition of an interoperable city platform capable ofintegrating services from different cultures. The architecture can be reused as whole, or individualcomponents of the architecture can be integrated into other Smart City platforms.
Outlook beyond the project
CPaaS.io has been able to define a set of common enablers for the smart city system architecturethat have been instantiated over EU and Japan concrete architectures, based on open and standard
protocols and mechanisms that will facilitate the extension and reusability by other cities. The
collection of interoperable city platform enablers provides the possibility of integrating services fromdifferent approaches as CPaaS.io has demonstrated in its various deployments.

2.1.2 Federation Mechanism
Integration and federation of the FIWARE-based and u2-based platform instantiations is an importantfeature for interoperability. We have demonstrated two aspects how this can be done: Firstly, an API-based
mechanism, and secondly, federation of personal information in Personal Data Stores (see 2.1.3).
H2020 EUJ-02-2016

CPaaS.io

Page 9 of 40

Deliverable D8.4

Final Report: Summary of Outcomes

For the API-based federation we demonstrated this using a smart building monitoring use case, as shownin Figure 5. Sensor data (room temperature and humidity etc.) of a building at the University of Tokyo,
connected to the u2-based platform instance, can be shown in a dashboard on the FIWARE-based instance,and vice versa (building information from Murcia being shown on the Japanese dashboard).

Figure 5: EU-JPN Federation. Smart building use case

Since it is a concrete development for integrating both FIWARE-based and u2-based platforms, the nichetargeted by this software is concrete and easy to identify. By distributing this software in an open-sourcemanner through GitHub,3 other software platforms and users facing the same challenge will be able toreuse and possibly adapt this code.
For Linked Data based data sources, a SPARQL proxy is used built on an index-assisted query processing
engine. SPARQL queries can be transparently executed against multiple SPARQL endpoints without theneed of using explicit federation using the SPARQL SERVICE keyword. The SPARQL proxy is analysing theSPARQL query, transparently rewrites it and sends the sub-queries to the appropriate SPARQL endpoint.
NGSI-LD will make it much easier to provide FIWARE data as Linked Data and thus platforms built on NGSILD can greatly benefit from this SPARQL federation approach.
Outlook beyond the project
The interoperability mechanism for data sharing demonstrated in CPaaS.io defined some key aspects
for real federation of smart city platforms, allowing different data sources to be used in a common
way, increasing the potential of the platforms and facilitating future integration of subsystems, that
follow the platform of platforms model. Additionally, workshops and other fora such as the FIWARE
summit can be a good opportunity to promote this development.

2.1.3 Personal Data Store
Finally, and perhaps one of the most referent use cases for the application of security and privacy is thatof Personal Data Stores (PDS). The concept of PDS is novel in terms of personal information management
since it empowers users with tools that allow them to control the way their personal information is
managed and commercialized by online services as presented in Figure 6.

3 See https://gitlab.neclab.eu/darp-git-cpaasio/cpaasio

H2020 EUJ-02-2016

CPaaS.io

Page 10 of 40

Deliverable D8.4

Final Report: Summary of Outcomes

Figure 6: PDS implementation from Japan (showing English translation) and EU

In addition to exposing an API for registering services and accessing the stored personal information, it
also presents an intuitive GUI that allows the users to easily handle the way each specific detail/attributeof their personal information is disclosed.
The capability of federating PDSs is also an added value for this software component which allows for a
multi-domain solution where the user is placed in the centre, deciding in every moment the information
being exposed.
Again, thanks to an open strategy and by attending to events focused on customers and/or smart city thissoftware, or at least the need for having this sort of solution can be motivated. Furthermore, the adoptionof open and standard protocols assures that interested parties could use and deploy it, or even evolve it
to a richer solution. This sort of solution can be of interest at different levels (local, regional or national),
since it paves the way for new solutions where the users make the decision about how their personal
information is managed.
Outlook beyond the project
CPaaS.io is enabling data-centric user empowerment using the PDS model as a mechanism toprovide users the definition of the data disclosure rules and procedures, supporting an access control
mechanism for users to control how their data and attributes are being used and accessed by services
and applications. PDS is also a cornerstone of the Omotenashi hospitality cloud platform for helping
visitors to Japan in 2020 and beyond.

2.1.4 Data Quality Ontology
Re-using data requires information about the quality of the data. This helps potential users of the data tounderstand the scope and quality of what they might be using. This is especially important when data is
coming from sources like IoT devices which might or might not work correctly. Between the device andthe data storage endpoint there are also many potential pitfalls that could stop data to be sent/arrive
properly and thus does not get stored as planned by the device provider.
Within the CPaaS project, the data quality ontology SEDAQ was developed4 that allows data providers tospecify what users can expect from the data. This includes features like what device the data was collectedfrom to which time synchronisation method was used for the timestamp to in what frequency the data is

4 Available at GitHub: https://github.com/cpaasio/sedaq

H2020 EUJ-02-2016

CPaaS.io

Page 11 of 40

Deliverable D8.4

Final Report: Summary of Outcomes

expected to be available. This not only gives an idea of what to expect but also provides a way to detect if
something went wrong. The SEDAQ ontology is based on the following models and standards:••

Basic W3C standards used for ontology modelling: RDF, RDFS, OWL.
Existing vocabularies either directly related to the domain of sensors or related to machineto-machine communication (M2M):
o Semantic Sensor Network (SSN)o DCAT for static data set description and data catalogues.
o OneM2M and M2M Ontology
o PROV-O for data provenance information.
o Existing schemas from schema.org

Outlook beyond the project
The ETSI ISG CIM specification group is looking into data models and especially into the data
quality aspects of data. The data quality ontology from CPaaS.io is a valuable input to the activities
which will be taken up by the ETSI ISG CIM members NEC and OdinS.

2.2 FIWARE Toolbox
This section presents the components that are part of the FIWARE Toolbox. During the project, existing
FIWARE Generic Enablers, components from other projects and new components have been integrated
into the European instantiation of the CPaaS.io platform. Some of the existing components have beenenhanced to address requirements needed by users and developers. Most software in the platform isavailable as open-source projects and can be freely downloaded. Those components will be sustained
through GitHub services, which means that issues and new features can be handled by the community. In
addition to being open source, components found in the FIWARE Catalogue are strongly supported andpromoted by FIWARE foundation and its members (organisations and individuals). FIWARE also provides
a complete set of resources to users and developers, including tutorials, courses, repositories and test
environments. The next subsections present detailed information about the software components as well
as how they are distributed, promoted and sustained.
2.2.1 IoT Broker
The IoT Broker is specified as a lightweight and scalable middleware component that separates IoT
applications from the underlying device installations. This implementation satisfies all properties describedin the FIWARE specification of the IoT Generic Enabler (GE). More details about the IoT Broker GE
specification can be found in [1]. The IoT Broker provides means to assemble lower-level device information(device-centric access) into higher-level Thing information (information-centric access). By providing asingle point of contact to the user, it collects and aggregates information about thousands of real-world
objects on behalf of the user, which also decreases the complexity of the multi-provider nature present in
IoT.
The IoT Broker is integrated with three other components: IoT Discovery (ConfMan), IoT Knowledge Server,and FIWARE (Orion) Context Broker. In the CPaaS.io platform, the IoT Broker is also integrated into an
Nginx proxy, in order to push notifications to external endpoints. IoT Broker is an open-source project
maintained and promoted mainly by NEC Laboratories Europe and the open-source community. The
source code is available on GitHub. Table 2 presents links for the IoT Broker source code, docker images
and manuals.

H2020 EUJ-02-2016

CPaaS.io

Page 12 of 40

Deliverable D8.4

Final Report: Summary of Outcomes

Table 2. Web links for IoT Broker artifacts

Artifact
Source code
Docker image
Documentation

Online course

Link
https://github.com/Aeronbroker/Aeron
https://hub.docker.com/r/fiware/iotbroker/
http://fiware-iot-broker.readthedocs.io/en/master/
https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.
IoT.Backend.IoTBroker
https://edu.fiware.org/course/view.php?id=33

2.2.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 detailed
information about the IoT Discovery GE can be found in [2].
ConfMan is responsible for discovering the availability of context. The availability of context must be
through the registrations made by IoT Agents (i.e., data providers). By registering, data providers maketheir access endpoints available for the data consumers. Data providers offer information about context
entities (i.e., virtual entities) and their attributes (e.g., measurement values, metadata).
Typically, context source availability information is forwarded to the FIWARE Context Broker GE. This allows
context information (i.e., information generated by or coming from the “Things” i.e. the Physical Entities)
to be available and accessible by the applications. ConfMan is integrated with two other components
within CPaaS.io platform: IoT Broker, Context Broker and IoT Knowledge Server.
ConfMan is sustained and promoted in the same way as the IoT Broker and its source code is accessible athttps://github.com/Aeronbroker/NEConfMan.
2.2.3 IoT Knowledge Server
The IoT Knowledge Server adds semantic information into NGSI messages and enhance these NGSI
messages with semantic reasoning. IoT Knowledge Server component has an internal triple-store where
NGSI (or other) ontologies are kept. It serves semantic knowledge such as entity subtypes or supertypes
and provides high-level access to the semantic ontologies via query/subscription functionalities.
The IoT Knowledge Server has the ability to serve high level queries (e.g., get subtypes of a sensor).
Moreover, it is a flexible component which can be extended with new features on the fly. The IoT
Knowledge Server is composed of two HTTP web servers and two databases along with their HTTP servers.
One of the databases is a HSQLDB (a SQL database) and the other is a Apache Jena Fuseki server, an RDF
triple store.
IoT Knowledge Server is an open-source project supported by NEC Laboratories Europe. It can be
downloaded at https://github.com/Aeronbroker/NECIoTKnowledge.
2.2.4 Orion Context Broker
Orion is a C++ implementation of the NGSIv2 REST API binding developed as part of the FIWARE platform.
Orion Context Broker allows to manage the entire lifecycle of context information including updates,
queries, registrations and subscriptions. It is an NGSIv2 server implementation to manage context
information and its availability. Details on the Context Broker GE specification can be found in [3]. Using
the Orion Context Broker interfaces, clients can run operations like: (i) update and query context
information; (ii) register context producer applications; (iii) being notified when changes on context
information take place.

H2020 EUJ-02-2016

CPaaS.io

Page 13 of 40

Deliverable D8.4

Final Report: Summary of Outcomes

In the CPaaS.io platform, the Orion Context Broker has been fully integrated into the IoT Broker and STH
Comet. In the first integration, data pushed to IoT Broker is automatically forwarded to Orion Context. In
addition, STH Comet subscribes to data from Orion in order to populate a temporal database.
The Orion Context Broker is an open-source FIWARE Generic Enabler (GE) and it can be downloaded athttps://github.com/telefonicaid/fiware-orion. As Orion can be found in the FIWARE Catalogue, it is
supported by resources from the FIWARE foundation, like documentation, test environments and courses.
Orion is part of promotional activities performed by FIWARE members and it is also directly promoted by
the European Commission through the Connecting Europe Facility framework5.
In the course of the CPaaS.io project, the NGSI-LD specification has become available which marks themove from simple record structures to linked knowledge graphs such as postulated by the CPaaS.io
Knowledge Layer and standardized in ETSI ISG CIM. The FIWARE foundation has announced to move theopen source ecosystem to NGSI-LD.
2.2.5 FogFlow
FogFlow [4] is a distributed execution framework to support dynamic processing flows over cloud andedges. It was to a large extent developed in the course of the CPaaS.io project. It can dynamically andautomatically composite multiple NGSI-based data processing tasks to form high level IoT services, andthen orchestrate and optimize the deployment of those services within a shared cloud-edge environment,with regards to the availability, locality, and mobility of IoT devices. In the CPaaS.io platform, FogFlow is
integrated with IoT Broker, ConfMan and Orion Context Broker.
The FogFlow programming model defines the way of how to specify a service topology using declarative
hints and how to implement tasks based on NGSI. First, developers decompose an IoT service into multiple
tasks and then define its service topology as a directed acyclic graph (DAG) in JSON format to express thedata dependencies between different tasks. On the other hand, the FogFlow programming model provides
declarative hints for developers to guide service orchestration without introducing much complexity.
FogFlow is an open-source FIWARE Generic Enabler (GE) and it is currently sustained and promoted by the
FIWARE foundation and its members. FogFlow can be downloaded at https://github.com/smartfog/fogflow.
FogFlow can be found in the FIWARE Catalogue at https://catalogue-server.fiware.org/enablers/fogflow.
Documentation and manuals can be found at http://fogflow.readthedocs.io.
2.2.6 NGSI-LD Broker
The NGSI-LD Broker is a middleware component that implements the new NGSI-LD API for Context
Information Management [5]. NGSI-LD has been standardized by the ETSI Industry Specification Group forcross-cutting Context Information Management (ISG CIM). A preliminary version of the specification has
been released in April 2018, and a final version submitted to the ETSI board in December 2018. It defines
a standard API that enables close to real-time access to information coming from many different sources[6]. NGSI-LD is the evolution of the NGSI v1 and NGSI v2 interfaces that are currently implemented by
ConfMan, IoT Broker, and FIWARE Context Broker. The NGSI-LD Broker is still under development and it isexpected to have an initial release in early 2019.
The NGSI-LD Broker combines many functionalities from the Context Broker, the IoT Broker and IoTDiscovery. For instance, it also provides abstraction to the context, context subscription/notification,
context query and data push, geo-scoped queries, federation and scalability. Additionally, it provides
exclusive features that are different from current implementations. Three of the most relevant new featuresof the NGSI-LD Broker are:

5 https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/Orion+Context+Broker

H2020 EUJ-02-2016

CPaaS.io

Page 14 of 40

Deliverable D8.4•••

Final Report: Summary of Outcomes

NGSI-LD is based on JSON-LD, which enables support of linked data and semantic interoperability
through heterogeneous context sources and consumers.
A standardized Temporal Query Language is supported, which means temporal properties can be
defined over entities and attributes, as well as the storage and retrieval of time-series information.
Another relevant feature is the use of the GeoJSON6 format for geographic data structures, whichenables many geometry types and enhanced geo-information exchange with third-party
components.

All those features are expected to provide better interoperability, meaning and reliability of data in thescope of context information management for Smart Cities. As this software component is still being
developed, its business model and promotional activities are currently under discussion.
2.2.7 Deployment Knowledge BaseThe Deployment Knowledge Base is a tool for managing the deployment of IoT Devices. It covers aninventory for managing IoT Devices and sensors and allows IoT deployment managers to plan adeployment of physical devices including a description (location, time, floor plan) of deployments. The tool
supports both the deployment of static and mobile devices, and associations of mobile devices with people
and other physical entities can be managed.
The data generated by this tool can be used for metadata enrichment of raw data and analytic results. The
deployment knowledge base exposes a SPARQL endpoint and has a web-based front end. Deployment
metadata created by the tool instantiates a deployment ontology extending the semantic sensor network(SSN) ontology (see [7] for further details about the ontology) and it is stored as RDF triples in a triple store(deployment knowledge base) within the platform.
An initial version of the deployment tool has been made available to partners in the project, currently
contains inventory and deployment metadata for the “Color Run” event. The software component itself
proprietary software of AGT, who continues to maintain and promote it, as well as use it in specific projects.
Only access to Web front end and APIs are provided. The web front end, accessible athttps://cpaasio.agtinternational.com/devices, and APIs however are public.
2.2.8 NGSI to RDF Mapper
This component maps NGSI data model instances to RDF triples and inserts them in the CPaaS.io Semantic
Data repository. The component understands NGSI 10 notifications and updates the Semantic datarepository accordingly. This enables the semantic integration between the European FIWARE-based andJapanese U2-based CPaaS.io instance. It also provides a common semantic data integration layer for any
other non-FIWARE based IoT Platforms. For instance, AGT’s own IoTA platform offers via its World Grapha rich semantic representation of dynamic and complex physical environments. With the NGSI to RDF
mapping service, IoTA is interoperable with the NGSI standard and FIWARE implementations. NGSI to RDF
Mapper is a proprietary component and it is sustained by AGT.
2.2.9 STH Comet
The Short Time Historic (STH, aka. Comet) is a component of the FIWARE ecosystem in charge of managing(storing and retrieving) historical raw and aggregated time series information about the evolution in timeof context data (i.e., entity attribute values) registered in an Orion Context Broker instance. All thecommunications between the STH and the Orion Context Broker as well as between the STH and any third
party (typically for data retrieval) use standardized NGSI9 and NGSI10 interfaces.

6 http://geojson.org

H2020 EUJ-02-2016

CPaaS.io

Page 15 of 40

Deliverable D8.4

Final Report: Summary of Outcomes

STH Comet is a FIWARE Generic Enabler (GE) and the source code can be found athttps://github.com/telefonicaid/fiware-sth-comet. Tutorials, installation instructions and the API
specification are available at https://fiware-sth-comet.readthedocs.io/en/stable/.
In CPaaS.io project, STH Comet has been improved to support metadata information. A patch has beendeveloped and a pull request to the official repository is currently under review. The patch can be foundat https://github.com/evertonberz/fiware-sth-comet/.
2.2.10 Security components
KeyRock is the FIWARE component responsible for Identity Management. Therefore, it is for representing
the user attributes and validate if they are correct. Capability Manager is the entity responsible for receiving
authorization requests, processing them and generating the Capatility Tokens associated to such
authorization in case of a positive answer.
XACML is a component that includes a PAP (Policy Administration Point) and a PDP (Policy Decision Point).
PAP is responsible for managing the access rules and creating the XACML triplets <subject, resource,
action> regarding the authorization for a specific resource. Such XACML policies are stored in a documentthat will be acceded by the PDP to generate the corresponding authorization verdict. PDP validates thedifferent requests against them. It receives XACML authorization requests and issue a verdict based on the
XACML policies set by the PAP.
Finally, PEP-Proxy receives the requests from Orion and IoT Broker in order to enforce the authorization
policies. PEP-Proxy is responsible for handling the requests for accessing to the information stored in Orionor IoT Broker. After validating the Capability Token associated to a specific request, it forwards the queryto the aforementioned broker and it also forwards the response to the requester of that information.
All security components are present in a single Docker image and they are available in the CPaaS.io GitHub
repository (cf. https://github.com/cpaasio/). A configuration manual can also be found on the same
repository.
2.2.11 LoRaWAN to NGSI10 bridge
This bridge listens to incoming messages on LoRaWAN applications and transforms them into NGSI10
format using TTN device and decoder API. The new formatted message is then sent to a pre-configured
URL, which is an IoT Broker instance most of the time. It also allows to contact devices by sending formatted
messages to a call back URL defined by TTN or the application user. Additionally to the bridge, a HTTP
proxy dedicated to the WaterProof application has been also provided. This proxy simplifies the connection
and the message format for the WaterTank connected to the platform.
2.2.12 Grafana-NGSI Plugin
For data visualisation, Grafana (www.grafana.com) is a powerful and freely available tool. In order to beable to use it in the context of the CPaaS.io project, we have written an NGSI-plugin for Grafana, as data
can only be retrieved from the CPaaS.io platform using NGSI.
The source code for this plugin is available at https://github.com/cpaasio/Grafana-NGSI-Plugin.

H2020 EUJ-02-2016

CPaaS.io

Page 16 of 40

Deliverable D8.4

Final Report: Summary of Outcomes

Outlook beyond the project
The FIWARE-based implementation of CPaaS.io will be distributed and sustained mostly throughopen-source platforms like GitHub and the FIWARE community. Proprietary products will bedisseminated and supported by their respective vendors. The FIWARE foundation and its members
will play a key role in promoting and advertising the components in workshops and conferences aswell as exploiting their potential within cities and organizations.

2.3 u2 Toolbox
2.3.1 Introduction
In Japan, the CPaaS.io architecture has been implemented based on the u2 architecture (ubiquitous ID
architecture version 2) which has initially been developed by the TRON Project. The TRON Project is thefirst project on IoT or ubiquitous computing in the world, which was started by Professor Ken Sakamura in
1984. It aimed at the realization of a Highly Functionally Distributed System (HFDS) where any objects inour surroundings will have computers embedded and collaborate with each other to offer better services
to human users. Today, the concept of HFDS has been realized partially with the IoT and ubiquitous
computing. In a sense, the world has finally caught up with what the project has tried to achieve. In 2003,
key players in the field established a non-profit open forum called the Ubiquitous ID Center (uID Center;www.uidcenter.org). So far, more than 500 companies and organizations worldwide have contributed to it,
publishing uID standards, industrial open standard specifications for IoT or ubiquitous computing systems.
In developing IoT or ubiquitous computing standards, we need to explore the essence of IoT or ubiquitous
computing – "context awareness". So, the central point of the u2 architecture should be a context-aware
computing mechanism. Thus, we need to answer the question, “What is context awareness?” A typicalanswer might be “adapting behaviour based on information sensed from the physical and computational
environment.” A technology standard can support context awareness in two ways: as a standard for context
representation or as a standard for acquiring the context information necessary for adapting information
system behaviours to a real-world context.
For the context representation, we need a consistent system for determining the identity, location, andstatus (“who,” “what,” “where,” and “when”) of real-world entities represented by a single ID. In the u2
architecture, every real-world entity such as an object or location receives a standard ID scheme ucode, a
128-bit unique identifier. And more complex context information is described in a standard manner byusing the ucode Relation (ucR) Model, which uses triples to represent relations, similar as it is done withRDF (Resource Description Format). For the context information acquisition, we provide a standard
component ucode Resolution component for service finding, and an IoT Aggregator for managing andconnecting to IoT devices.
In the following, we will describe the main components of the u2-based CPaaS.io instantation architecture(cf. also left side of Figure 4).
2.3.2 u2 Open Data Catalog Component
The u2 Open Data Catalog is a software module in the knowledge layer of the CPaaS.op architecture. It
provides an open data catalog function which is very imporant for the smart city infrastructure. It canmanage meta data of open data on the basis of an RDF framework and a SPARQL-based API for eachcatalog entry. As shown in Table 3, this component has been deployed in several smart city platforms inJapan, both as part of the CPaaS.io project as well as other projects.

H2020 EUJ-02-2016

CPaaS.io

Page 17 of 40

Deliverable D8.4

Final Report: Summary of Outcomes

Table 3: Open Data Catalogs in Japan based on CPaaS.io

Catalog NameOpen Data Catalog of Yokosuka City
Open Data Catalog of Sapporo City
Open Data Drill Page

Access URL
http://yokosuka-opendata.ubin.jp
http://docs-sapporo.odcity.org/
https://www.opendata-training.org/about/(intended for the promotion of our open data
platform to local governments in Japan)

2.3.3 Open Data Distribution Platform Component
The Open Data Distribution Platform is mainly used in combination with the u2 Open Data Catalog
described above, and it mainly manages real time data in the open data catalog. It collects realtime open
data such as sensor data by providing RESTful APIs. Technically, it is based on semantic web technologies
such as RDF framework and SPARQL-based query API, and also RESTful APIs.
2.3.4 IoT Translation Engine
The IoT Translation Engine is a component which provides a service for automatic translation among many
languages. This is mainly used to build multi-language user interfaces for IoT Services including web pages,
open data catalogues, smartphone apps., and so on. The current implementation of the IoT Translation
Engine is using Microsoft Translator, which could be replaced by any other automatic translation engine
with network APIs.
2.3.5 kokosil
kokosil is a software package to provide information for visitors and tourists in towns, tourist spots,
commercial facilities, museums, parks, exhibition venues, etc. It has a management function to register
information on target areas, tourist facilities, stores, etc. easily, an information distribution function toprovide timely information on, e.g., popular seasonal spots or ongoing events. This application supports
Chinese (traditional and simplified Chinese), English, French, Japanese, Korean and Thai characters. It is
ideal for building information services targeted to inbound tourists. kokosil has been introduced in morethan 50 areas and facilities so far.
kokosil provides many functions which are selectable according to the needs of each area to vitalize towns.
For example, following functions are available:••••

stamp rally, tour courses, etc. to improve the mobility of visitors in the area,“sightseeing passport” to offer benefits (coupons) that can be used at the tourist facilities,
restaurants, lodgings, etc.,
functions based on augmented reality (AR) such as photo frame to let users have their photos takenwith animation charactersvirtual experience based on virtual reality (VR) such as viewing and visiting a recreated castle, etc.

kokosil has also been used as a “comprehensive app for local governments” that provides information
mainly to the residents.
2.3.6 ucode Manager (ucode RP) + ucR Manager (ucR Query protocol)a) 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 the 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.

H2020 EUJ-02-2016

CPaaS.io

Page 18 of 40

Deliverable D8.4

Final Report: Summary of Outcomes

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 and programs.
"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 isa target to be identified among objects, places, or concepts in the real world, and the identifier to identify
the entity is a ucode.
b) ucR
The u2 architecture represents the real-world context by modeling the relation on a real-world entity as arelational representation among ucodes allocated to entities or between the ucode and an atom, i.e., aliteral 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 a ucR model, it is called a Relation.
c) ucR Unit
The basic unit of the ucR model consists of two ucodes or a ucode and an atom, and their relationships.
Moreover, the respective relationships between the two are provided with a logical ucode called a relationucode. This basic unit consisting of the above triple is called a ucode relation unit (ucR unit). When this
triple is set in a sentence where the relationships are represented as the predicate, the ucode as the subject
is called a subject ucode, and the ucode as the predicate which is a relation part is called a relation ucode,and the ucode as the object or complement is called an object ucode. The atom can be substituted for theobject 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 atom. When it is not necessary
to uniquely identify any of the three elements comprising a ucR unit, their relevant parts can be left blank.
d) 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 informationsuch 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 areconnected 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 graph structure, in which ucodes
are connected by relations and pieces of information described as atoms are associated with each ucode.
e) ucode Resolution
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.
The u2 architecture does not specify the internal configuration of the ucR database. However, the ucR
database must provide an interface for ucode resolution as explained in the following section.
When a user physically accesses an entity in the real world, the 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 ucR graph isregistered in the ucR database. The protocol for accessing the ucR database in this manner is called ucode
Resolution Protocol (ucodeRP).
2.3.7 IoT Aggregator Component
Aggregate computing uses all devices, services and systems that are connected to the network to achieve
desired services. Let us take an example of the optimum control of air conditioning in our living
H2020 EUJ-02-2016

CPaaS.io

Page 19 of 40

Deliverable D8.4

Final Report: Summary of Outcomes

environment. Aggregate computing uses air conditioners, of course, but it also employs other objects suchas windows, air vents, gas stoves, temperature sensors, humidity sensors, and any other devices that are
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 must pay due attention to the governance of the usage of functions. Users shouldhave the final say about who can control what and when, rather than the vendors of the devices or theservice 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 the IoT-Aggregator. It has not been easy to connect devices fromdifferent manufacturers and make them collaborate with each other. The 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.
2.3.8 OPaaS.io
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 a mechanism to let objects communicate witheach other to collaborate. But we also need a mechanism to learn and collect the attributes of eachindividual user such as language spoken, age, many physical characteristics, preferences, etc. Suchknowledge must be reflected to create an optimized environment. For this purpose, CPaaS.io has
contributed to building a general-purpose PDS (Personal Data Store) that uses the IoT technology. It iscalled "OPaaS. io" and also called "Omotenashi (hospitality) cloud" under its nickname. OPaaS.io has
officially started with the funding from the Ministry of Internal Affairs and Communications since last year,
and it now goes through development and testing through feasibility study experiments.
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 toward 2020 with the Tokyo Olympic
and Paralympic Games. Customers (consumers) store their individual characteristics such as preferredspoken language, food taboos, passport information for sales tax-exemption in the cloud. Once the datais stored, such information is easily retrieved on the spot and passed to service providers such as storesand public services by using the smartphone apps or transportation IC cards as retrieval key. OPaaS.io has
been designed to collaborate with the 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. This concept of letting customer (consumer) control the vendors iscalled VRM (Vendor Relationship Management). Its model of who controls what is the opposite of ordinary
CRM (Customer Relationship Management). OPaaS.io plays the important role of a PDS in the scheme. This
framework has been designed to be useful in Japan AFTER the year 2020 as legacy service platform when
it will be utilized very much for hospitality service to Japanese citizens as well as foreign tourists. Small
regional service vendors who did not have the resources to build conventional CRM can now join the
OPaaS.io service framework and provide better services suited for the new IoT Age. OPaaS.io will be usefulfor invigorating the regional economy and also is expected to add to e-inclusion by accelerating therealization of Enableware.

H2020 EUJ-02-2016

CPaaS.io

Page 20 of 40

Deliverable D8.4

Final Report: Summary of Outcomes

2.3.9 eTRON Security Architecture
eTRON is a tamper-proof hardware for PKI nodes developed by YRP. Although many IoT devices, especiallysensors, only need lightweight cryptographic functions, there are some IoT nodes that need high-level ofcryptographic functions. The eTRON architecture enhances the solution to mitigate privacy concerns insuch advanced cryptographic environments. The project explores whether such tamper-proof hardware
PKI node can be made to work with the concept of partial identity and, in general, can meet the needs ofprivacy-preserving IdM in general.
2.3.10 IoT Engine
The IoT-Engine is a standard development platform, standardized by the TRON Forum, for Open IoT torealize "Aggregate Computing". The IoT-Engine standard specifies the connector on the Micro Processor
Unit (MPU) board, and the RTOS used by the MPU, and requires the function to connect to the cloudservices on the Internet. The RTOS used on the IoT-Engine is µT-Kernel 2.0 which is available as open
source7. IoT-Engines collaborate with the cloud platform called IoT-Aggregator. By doing so, edge nodes
can be connected via the cloud and they act as the components of the "Aggregate Computing", a visionof the next generation computing architecture framework. The IoT-Engine project has the participation ofseven semiconductor companies from six countries and regions of the world (as of December 2018):
Toshiba Microelectronics, Renesas Electronics, Cypress, Imagination Technologies, Nuvoton Technology,
NXP Semiconductors, and STMicroelectronics.
In 2018, a realtime kernel specification based on μT-Kernel 2.0 has become an international standard, IEEE
Standard 2050-2018. This is a standard specification of an embedded real-time OS for IoT edge devices,which are very important elements in the IoT age. The standard addresses relatively powerless 16-bit CPUs
to use the OS based on the standard, and can create systems with small memory footprint, using not sopowerful CPUs without MMU, for example.
2.3.11 ucode Tags: ucodeBLE, ucode NFC, and ucode QR
The u2 architecture uses ucode tags as a device to store a ucode. There are various types of ucode tags
such as print tags, passive RFID tags, active RF tags, active infrared tags, etc. This results from the fact thatthe optimal tag for storing a ucode differs depending on the applications and usage environment.
•
•
•
•
•

Price/Cost consideration
Readability near metal surface
Readability near water-rich objects
Readability over long (or short) distance
Required security level

In the u2 architecture, ucode tags are classified into various types of tags from two viewpoints. One is thecommunication method (interface) and the other is the security level. The values of these classifications
are shown in the tables below.
Table 4: Interface categories of ucode tags

Category0
1
2
3Content
Print tag
Passive RFID Tag/Smart Card
Active RF Tag (built-in battery type)
Active Infrared Tag (built-in battery type)

7 See https://www.tron.org/download/index.php?route=product/category&path=50

H2020 EUJ-02-2016

CPaaS.io

Page 21 of 40

Deliverable D8.4

Final Report: Summary of Outcomes

Table 5: Security classes of ucode tags

Class
0
1
2
3
4
5
6

Content
Function to detect missing or lost data
Anti-physical duplication/forgery
Identification prevention function
Tamper-resistant function/function to control access for each resource
Function to construct secure communication channels with hitherto unfamiliar
nodes
Resource management function using a timer
Update function of internal programs/security information

We have already certified many kinds of tags as standard ucode tags. Currently, there are three kinds oftags which are widely used: ucode BLE, ucode NFC, and ucode QR.
ucode BLE is a ucode tag using Bluetooth Low Energy as communication protocol. We have a standard
protocol specification for this tag as follows:•"Packet Format Specification for Bluetooth LE ucode Marker"
http://www.uidcenter.org/wp-content/blogs.dir/1/files/2017/11/UID-00049-01.A0.05.pdf(in Japanese)ucode NFC is a ucode tag using Near Field Communication (NFC) protocol. We have a standard protocol
specification for this tag as follows:•"Standard of memory format of NFC ucode tag"
http://www.uidcenter.org/ja/wp-content/themes/wp.vicuna/pdf/UID-00046-01.A0.11.pdf(in Japanese)ucodeQR is a paper-based ucode tag using QR code standard. We have already defined a standard QR
code format for ucode as follows:•"ucode Encoding Specification for QR Code Tag"
http://www.uidcenter.org/wp-content/themes/wp.vicuna/pdf/UID-00025-01.A0.00_en.pdf

Outlook beyond the project
The u2-based implementation of CPaaS.io has already been deployed in several cities; additional
locations in the world are to follow. Some will be distributed as a standard specification which canbe freely implemented by any vendors as a commercial software and/or hardware, some will be
distributed as an open-source software (such as micro-T-Kernel), and some will be provided as a
cloud-based standard API services. For the deployment of the u2-based implementation as a smart
city platform, the eco-system among industry, city-governments, and universities is very important. We havealready established organizations for the deployment in cooperation with the national government of Japan, city
governments, industry, and universities, such as TRON Forum, VLED (Association for Vitalizing Local Economy
Organization by Open Data & Big Data), ODPT (Association for Open Data of Public Transportation), Sapporo
Open Data Association, Yokosuka Emergency Medical Service Working Group, Yokosuka Smart Mobility
Promotion Consortium, and so on.

H2020 EUJ-02-2016

CPaaS.io

Page 22 of 40

Deliverable D8.4

Final Report: Summary of Outcomes

2.4 Tools Supporting City Developers
2.4.1 Smart City Strategy Framework
Based on literature on governance, implementation and infrastructure, we have developed an analyticalframework for analyzing smart city strategies, called "Smart City Strategy Framework". The frameworkprovides comparative ground in an international context and supports the formulation of new strategies.
The framework is explained in detail in [8], but we give here a short overview.
The framework consists of a morphological box, with the 19 elements grouped into 4 dimensions: City
context, governance, implementation and infrastructure (see Table 6). For each element, 2-6 possible
manifestations are defined. Morphological analysis is a well-suited method for studying and analyzing
complex problem fields that are inherently non-quantifiable, contain non-resolvable uncertainties, cannot
be casually modelled or analyzed, and require a judgmental approach [9]. Devising a smart city strategy
represents such a problem. In a morphological box, all important elements are listed, and for each element,
possible manifestations are identified, resulting in the definition of a multi-dimensional solution space.
With an initial version of the morphological box we analyzed our six stakeholder cities. Two examples ofthis analysis, for Amsterdam and Tokyo, can be seen in Figure 7. The qualitative comparison of the six cities
shows a number of similarities, as e.g. the predominance of government-driven approaches or the
relevance of platforms. Context and concrete goals of smart cities activities may vary: The motivation is
primarily increasing the quality of life, with technological and economic emphasis. While smart city
activities still address primarily environmental pressures, demographic and economic issues are continuing
to grow in importance. Citizen-involvement in the sense of co-creation is yet at a very low maturity level.

H2020 EUJ-02-2016

CPaaS.io

Page 23 of 40

Deliverable D8.4

Final Report: Summary of Outcomes

Table 6: Smart City Strategy Framework
Domain/Elements

Possible Manifestations

City Context
Population< 50'000

50'000 100'000

100'000 –1 mio.

Development
Stage

Greenfield(New City)

Retrofitting(Existing City)

Brownfield

Political System

Authoritarian

Representative
Democracy

DirectDemocracy

Education Level*< 20%

20-40%

Pressures

Demographic

GovernanceModel

1 - 5 mio.

> 5 mio.

40-60%

60-80%> 80%

Environmental

Fragility

Financial

Economic

Infrastructure

Governmentdriven

Industry-driven

PPP

CitizenInvolvement

None

Open
Communication

Co-creation

Motivation

Technology

Quality of Life

Economic
Prosperity

Ecological
Footprint

Innovation

Resilience

City Role

Customer/User

Facilitator

Lead & Control

Initiator

Responsibilty
Smart City
process

No overall
responsibility

City

City-sponsored
3rd party

Independent
3rd party

Business Sector
Development

Financialincentives

Businessincubation
services

Tech. transfer& commercialization
services

Approach

Project

Program

Initiative

Regional
Cooperation

City-onlywith bordering
regionInter-City
cooperation

Implementation
Model

AnchorPlatform

Beta City

Application
Domains

Singleapplication
domain2-3 domains

Coordinatedapproach on 6
main domains

Stakeholderdefined

Performance
Measurement

Project-based

Dashboard

Data
Infrastructure

Per Project

Closed API

Open Data
PortalLinked Data

Networking
Infrastructure

Per ProjectCity-wide
WLAN

City-wide IoTNetworkCloudInfrastructure

Per ProjectCity-wide
platform

Governance

Implementation

Infrastructure

H2020 EUJ-02-2016

CPaaS.io

Page 24 of 40

Deliverable D8.4

Final Report: Summary of Outcomes

Figure 7: Instantiations of the Smart City Strategy Framework: Amsterdam (above) and Tokyo (below)

The comparison emphasizes the need for a holistic approach. Applying the framework in practice allowed
us to validate and extend the framework with additional characteristics, e.g., for the elements motivation(innovation, resilience) and city role (initiator) as shown in Table 6.

Outlook beyond the project
BFH is planning to set up a database with information from different cities analyzed, consisting of
the different manifestations of each of the elements as well as explanatory texts. Such a database
will allow to better compare the activities of different cities, to be spread both in the research andpractice communities, and form the basis for strategy consulting projects with cities.

H2020 EUJ-02-2016

CPaaS.io

Page 25 of 40

Deliverable D8.4

Final Report: Summary of Outcomes

2.4.2 Blueprint Template
Today, cities often re-invent the wheel when implementing smart city applications, although thetransformability of use cases and applications from city to city would be possible, thereby re-using
experience and know-how. We have therefore developed a blueprint process and a template covering
technical and organizational aspects.
Since every city has specific characteristics, smart city applications are not transferable without adaption
to its context. Given a blueprint template at hand for smart city applications would well support theadaption of smart city applications. The template guides through the problem-solving cycle and assists inthe abstraction and concretization process of a smart city application and with that help in the adaption
process.
The blueprint template covers important categories along the value chain [10] of smart city applications.
The objective of the blueprint template is to create a description of the system without enforcing specificimplementation methods. It considers processes, architecture views, hardware, software, possible projectand communication plans. Further aspects support the creation of public value within a smart city
application as well as the operation and optimization of an application set in place.
The smart city blueprint template consists of four parts (see Figure 8) which relate to the four typical phasesof most projects plus a One-Pager giving a summary and overview of the blueprint and its use case. The
One-Pager guides through the development of the blueprint and shows which aspects need to be reevaluated when adapting an existing blueprint to another city. A filled-out example of such a One-Pager
for the CPaaS.io Amsterdam water management use case is shown in Table 7. All the other parts aredescribed in detail in [11] and [12].

Figure 8: Structure of Smart City Blueprint and relationship to project phases

H2020 EUJ-02-2016

CPaaS.io

Page 26 of 40

Deliverable D8.4

Final Report: Summary of Outcomes

Table 7: Smart City One-Pager for the Amsterdam Water Management use case
Smart City Blueprint One Pager
Value Proposition –Creation of Public Value

Extreme rainfall and periods of continued drought are occurring more and more often
in urban areas. Because of the rainfall, peak pressure on a municipality’s sewerage
infrastructure needs to be load balanced to prevent flooding of streets and basements.
With drought, smart water management is required to allow for optimal availability ofwater, both underground as well as above ground.

Requirement Specification
Ownership / Contact

WaterNet (water utility)

Affected Value
Chain
Elements:

Data Collection

Data Carriage

Data Storage

Data Analytics

Data
Marketplace

ApplicationLayer[x] yes[x] yes[x] yes[x] yes[ ] yes[x] yes

Supporting Activities
Sourcing

LoRa Network (The Things Network), Polderdak (water buffers)

Governance &RiskManagement

tbd

Data
Protection &Security

Remote-control access to valves must be secured, data transmission over secure channels

Financing

Government-level funding

Realization
Project organisation

Led by WaterNet

Roadmap

Prototyping individual sites, then boader roll-out

Architecture

PaaS (Platform as a Service), using CPaaS.io / FIWARE components (e.g., FogFlow for
distributed edge computing

Chain link specific tools and technologies used:
Data Collection

Data Carriage

Data Storage

Data Analytics

1. Water-levelsen-sors (inbuffers aswell as insewagesystems)
2. Weather
data

LoRaWANtransmissionon(EU 863870MHz ISM
band)

Storing theData in the
FIWARE Orioncontext broker

Control water
buffer valves
based on filllevels,expected
weather data,and status odsewagesystem.

Data
Marketplace

Application
Layer
FIWARE APIs(NGSI-10)

Operation
Currently in prototype stage, determining parameters for continuous operation.

H2020 EUJ-02-2016

CPaaS.io

Page 27 of 40

Deliverable D8.4

Final Report: Summary of Outcomes

One of the most important aspects of the template is the Smart City Canvas. The Smart City Canvas isbased on Osterwalder & Piguer's Business Model Canvas [13], a well-recognized tool in the business world
for the creation of innovations and the associated development of new business fields. However, a city is
not a business: its main focus is not in creating profit, but rather in creating public value. This is reflectedin the Smart City Canvas.

Figure 9: Smart City Canvas

Outlook beyond the project
We are currently promoting the use of this template to both the scientifc community as well as tocities directly with the goal of establishing this template and methodology as best practice in Smart
City application development. One successful way of spreading the knowledge about it is the use inteaching curricula about Smart Cities, e.g., in master courses like the one we held at Linneus
University in Växjö, Sweden.
Regarding concrete work with cities, work has just started with a larger city in Switzerland to adapt the Smart
Parking use case from Murcia for the purposes of that city. As such, the blue print template proves to be an
important asset to be used in future development and consulting projects with cities.

H2020 EUJ-02-2016

CPaaS.io

Page 28 of 40

Deliverable D8.4

Final Report: Summary of Outcomes

2.5 Concrete Results in Cities
2.5.1 Stakeholder Cities
Table 8: Summary of results in the stakeholder cities

City
Amsterdam

MurciaSapporoH2020 EUJ-02-2016

Summary of Results
In practice, CPaaS.io provided a standard forstoring data and analyse it. This allowed us tomake easy ingest data from different
manufacturer and format while shortening thetime for analytic. The deployment stack,
FogFlow, also helped to provide a clear
architecture and protocol to transmit theapplication to other cities. We also gather
experience in handling data management andsecurity for Waternet and the smart water
solution.
CPaaS.io has been a relevant testing and bestpractice provider, that have helped Murcia
Municipality to validate, reconsider and get
experience on smart city platforms, that latter
have provided us ideas to be integrated in thetender we have just launched. In that sense
CPaaS.io was in the right moment as it has
provided us relevant insights that we havebeen able to tune the requirements andtechnology request for the MiMurcia tender.
Also technology choices like the usage of LoRA
for water management have been included aspart of the tender, or the need to support
gateways for the integration of parking spot
managements.
The impetus that the early CPaaS.io
prototyping experiment for tourism in
Sapporo, and the early Hackathon helped by
UTokyo, a CPaaS.io partner, have driven thecity of Sapporo to adopt open data
wholeheartedly. It has created an open data
portal: https://data.pf-sapporo.jp/
The city of Sapporo did not do it alone, butrather has created Sapporo Open Data
Association and a few other mechanisms to
involve the local industry and academia (mostprominently Hokkaido University in Sapporo
city.)
The courting of the private sector to join forces
with the city's open data movement has
succeeded. More private entities are interested
in offering open data sets than initially.
The city is trying to use open data for
improving the quality of life for citizens.
Private industry, especially, tourism and thecity of Sapporo are trying to make the visit to
the city interesting to 2.5 million overseas
visitors each year.

CPaaS.io

Outlook
Waternet is satisfied with the current workand planning to continue working on thewaterproof project. Now, the objective is tobuild a platform to visualise and analyse theeffect of the rain on the roofs. In this regard,
the model adopted by CPaaS.io will be useful
and we are aiming to tailor it to the projectneeds.

The ideas behind the PDS model of CPaaS.io
it is an interesting approach that we willconsider how to exploit. Also, the integrationof enablers for access control mechanism
within the platform operation it is also now inthe objective of the Platform Murcia it isdeploying. Prototypes will continue and will
be integrated in the final MiMurcia platformthat will be deployed within next 2 years. The
concept of smart parking or the sensors formeasurement based on LoRA will be
integrated and will interoperable as part of
the MIMurcia platform.

The city is pleased with the open data
movement so far. The collaboration with
CPaaS.io worked well.
But it looks beyond it. It wants to put the
open data movement in a sustainable mode.
So, an office has been created to establish abody that can:
- Promote the use of
https://data.pf-sapporo.jp/- Conduct data gathering- Consult for the usage of data
- Promote regional industries- Nurture human resources for open data,
IoT, etc.
The city hopes to establish such an operating
entity in three years.
Addition of more open data sets continue:
public transport open data will be included in
the city's open data portal by the end of
March 2019. This should be useful to thecitizens of Sapporo and the overseas visitors.
The city plans to use the open data gatheredin conjunction with the underground pathbeacon markers for improving the health ofPage 29 of 40

Deliverable D8.4

City

Tokyo

H2020 EUJ-02-2016

Final Report: Summary of Outcomes

Summary of Results
The open data portal has been used by private
entities to create some interesting apps.
The success of the city's open data movement
can be shown by the apps. Some interesting
applications are prioritization of ploughingsnow off the street by assessing the slowdown
on the streets: this is done by the positions of
the garbage collecting trucks and othervehicles.
Streets that experience great delay are given
higher priority for snow ploughing. Also, there
is an open data collection website to monitor
slippery roads: the result is used to deliver
sand bags in a timely fashion to make theroads less slippery.
In addition, there are private apps to look for
day care centers for children in a given area, tolearn when we can throw away certain types ofgarbage for classified garbage collection.
Tokyo as the host of the Tokyo Olympic andParalympic Games in 2020 is trying to establish
the ICT infrastructure for the future. Tokyo
Games is just a one of the future targets, but
still it is an important target to advance the ICT
infrastructure.
A round-table panel to discuss these ICT issues
has been established by the Tokyo
Metropolitan Government (TMG) and it ischaired by non-other than Ken Sakamura, thedirector of YRP Ubiquitous Networking
Laboratory and Japanese coordinator of
CPaaS.io.
TMG has established open data portal. It
currently has 13,000 data sets. This has been
done based on the policy goals that were
prompted by the proposals from the roundtable panel chaired by Ken Sakamura.
The proposals from the panel stressed thefollowing:- open- data (open data, that is)- public participation.
In 2017, TMG established the following four
policy goals based on the proposals from theround-table.
- ICT to enhance urban functions- Use data
- Use ICT to build mechanisms for solving
government challenge through public-private
collaboration- Support use of ICT in the private sector toraise productivity and create new value
The open data movement has taken root in theTokyo Metropolitan Government to the pointthat the Governor herself mentions the term
CPaaS.io

Outlook
the snow-covered city: the citizens do notwalk outside during winter often. But there
are underground paths where CPaaS.io andother efforts placed beacon markers for
positioning: GPS signals do not reach theunderground paths. The city plans to use thedata from people who walk in theunderground paths and the movement
information gathered by means of beacon
markers (and citizen's consent) for
monitoring people's health and even plan toexpand future underground paths based onsuch data.

The current Tokyo Governor has high hopes
for transforming Tokyo into a future smart
city beyond 2020 when the Tokyo Games will
be held.
TMG will continue to streamline its
application procedures so that it will be
paperless,stamp-less (currently many paper
processing fees need to pay by an
official stamp that is bought nearby.),andcashless.
In order to court investment and introduce
technology innovation, TMG is helping theprivate sector to introduce autonomous
driving in Tokyo.
TMG's open data movement will not stop.
The open data portal will have 40,000 data
sets (from the current 13,000 sets).
2020 Tokyo Games will provide a great
opportunity to deploy OPaaS PDS (O in
OPaaS stands for Omotenashi, hospitality inJapanese) developed by YRP, a CPaaS.io
partner.
OPaaS PDS has been created during CPaaS.io
and will be a tool for customized services fortourists and the citizens alike in the future.
Tokyo, the largest regional government inJapan, has a high visibility throughout Japanand its open data movement and other ICTrelated activities have a great impact on therest of Japan. So, CPaaS.io partners in Japan
expect Tokyo leadership will affect the
adoption of open data and ICT, especially the
IoT, in Japan.

Page 30 of 40

Deliverable D8.4

City

Yokosuka

H2020 EUJ-02-2016

Final Report: Summary of Outcomes

Summary of Results"API to access data" in her speech at the city
stakeholders' session of the 2018 TRON
Symposium.
TMG itself has used the data, for example, topredict the number of heat stroke cases in
preparation of the Tokyo Olympics andParalympics in 2020, which will be held in thesummer months. Also, the traffic modeling
during large sport events has been tried
successfully.
TMG has held a few open data application
contests at the suggestion of the panel. TMG
will support the 3rd Open Data Challenge for
Public Transportation in Tokyo (held by the
Association of Open Data for Public
Transportation, ODPT short, which aresupported by a few CPaaS.io partners inJapan). The third contest focuses onindoor/underground route guidance. ODPT
has held two such contests already and thecontests have produced interesting apps whichhave been covered widely in Japanese trade
media. The contests use the CPaaS.io
architecture, mainly u2-based tools, to offer
public transportation open data to contestants.
The Emergency Medical Care system proposed
and implemented by YRP, a CPaaS.io partner,
has taken root in the city of Yokosuka.
The aim of the Emergency Medical Care system
was to share the condition of the patient in an
ambulance among the rescue crew members
and the doctors at hospitals. Sharing of theavailability of beds in emergency wards of
hospitals was one of the original goals. Due toreasons beyond city’s fire fighters departmentthat manages ambulances, this sharing of theavailability of beds is not available yet. This is a
future goal.
By streamlining the data sharing, the time towork on the patient once the ambulancereaches a hospital can be shortened. The
system has done it using relatively inexpensive
off-the-shelf devices. Right now, the images
from the ambulances and their locations areshared. The system has tried to simplify theoperation so that the rescue crew members
can learn and operate it without too muchoverhead.
The system is used daily now. The success has
prompted the neighboring Miura city to adopt
the same system for its ambulance operation.
It has been a model case of such operationand it has been showcased at the 68th Annual
Meeting of Japanese Association for Acute
Medicine in January 2018 at the Hongo
CPaaS.io

Outlook

Yokosuka city itself is content to operate thesystem as is. So is Miura city.
Also, new features such as the sharing of theavailability of hospitality beds will be
implemented as the medical community
experience matures.
Given the wider area including Yokosuka andMiura is considered a unified single area fromthe viewpoint of medical community due tothe serviceability and transportation
availability, it may be beneficial to expand theoperation to the whole area.
The unified area viewed as one entity by the
medical community includes Yokosuka city,
Kamakura city, Zushi city and Miura city, andtown of Hayama. See Japan Medical
Association's statistics about the area and themap (in Japanese):
http://jmap.jp/cities/detail/medical_area/1406.
Actually, there is a proposal to do so, but it isa matter of the prefectural government todecide on doing so.
The system's merit of ease of use andrelatively inexpensive price tag would help
the adoption in Kanagawa prefecture andelsewhere in Japan.
Aside from the Emergency Medical Care
which has been firmly planted, the city of
Yokosuka is pursuing the use of ICT to
improve the quality of life of its citizens. It has
Page 31 of 40

Deliverable D8.4

Final Report: Summary of Outcomes

City

Summary of Results
campus of the University of Tokyo (cf.
http://jaam68_kantou.umin.ne.jp/).

ZurichZurich has been one of the forerunners in
Switzerland regarding the publication of Open
Data. In December 2018 finally, Zurich has
published its Smart City strategy, based on
three focus areas: smart public transportation,
smart participation, and the digital city.

Outlookfocused on the intelligent mobility as thenext target.
CPaaS.io partners will monitor thedevelopment to see if we can offer our knowhow to the city and its partners.
Based on the strategy, the city will takeactions in particular around fostering
innovation with specific instruments,
cooperation using a Smart City lab as well asa public (sensor) data infrastructure as well as
communication and dialog with the public,
also using smart city monitoring tools.

2.5.2 Other Cities or Regions
Table 9: Summary of results in other cities and regions

City
Heidelberg

Summary of Results
Based on the CPaaS.io system, Heidelberg has
selected FIWARE as their context information
management system. First element of the FIWARE
strategy of city of Heidelberg will be an
implementation of city data sources into theDigital Hub “kurpfalz@bw”8. The purpose of theDigital Hub is to make advanced digitaltechnology available to citizens as well asenterprises. By using the FIWARE system together
with IoT gateways for HOPU (see above), theDigital Hub can educate their people on smart
city technologies. The realization will be based on
a FIWARE sandbox (a cloud offering of a complete
FIWARE system including a NGSI-LD broker).
Besides the Digital Hub activities, NEC is also
major contributor to the “Smart Sensible
Heidelberg” project, especially in defining the
Heidelberg Smart City reference architecture.
Other contributors are SAP, ITEOS (the service
provider of all cities in the state of BadenWürtemberg), the Digitalagentur Heidelberg, theStadtwerke Heidelberg, as well as the upcoming“Amt für Digitales” (currently the IT department of
Heidelberg), FIWARE will be used as the major
integration platform for Heidelberg, even for
SAP-based city services. Use cases currently being
discussed are “City Health” in which personal data
spaces of citizens (CPaaS.io concept) willcontribute data to the overall assessment of
citizens health. Other use cases are Smart Winterand a single City Portal in which all citizens
services are concentrated and personalized forthe citizen.

Outlook
The following projects will be realized withthe city of Heidelberg and partners in thelocal eco-system(1) FIWARE-based Smart City Platform forthe Digital Hub “kurpfalz@bw” utilizing the
FogFlow platform on top of the HOPU IoT
gateway devices.
(2) FIWARE-based City platform as the basefor interoperability between city services(3) Mobility Analytics in the Neuenheimer
Feld (using NGSI-LD as common data
standard).

8 https://www.heidelberg.de/hd,Lde/HD/Arbeiten+in+Heidelberg/digital+hub+kurpfalz_bw.html

H2020 EUJ-02-2016

CPaaS.io

Page 32 of 40

Deliverable D8.4

City
Utrecht

MiuraGreater Tokyo
Area

Kochi Pref.

H2020 EUJ-02-2016

Final Report: Summary of Outcomes

Summary of Results
We used the Color Run event in Utrecht, The
Netherlands as an initial test bed to create thefirst versions of the My Events prototype. We
could successfully show how we can use theEuropean CPaaS.io platform instance to manage
wearable data that we used for creating
memorizable moments when visiting andactively participating at large events. Bothdeployments, in Utrecht and Sapporo, helped toprogress the overall application concept andunderstand the feasibility of the analytics
applied in the application. Although both the
Sapporo Snow Festival and the Color Run arequite different events in nature, we could
develop a homogenous application concept, an
initial unifying ontology and both generic andevent specific analytics.
Given that Miura city is mere 1/9th of the size of
Yokosuka in terms of population (Yokosuka:
about 400,00 vs Miura: about 44,000 in 2017)and both Miura and Yokosuka cities arerecognized as part of one big area both by thegovernment of Kanagawa prefecture and the
medical community in terms of medical service,
the description of Miura city is omitted. Please
see the description of Yokosuka
The use case of Tokyo Management of Service
Vehicle has been expanded to the greater Tokyo
Area including Kanagawa, Chiba, Saitama,
Ibaraki, Tochigi, and Gunma Prefectures.
Kochi prefecture and the Graduate School ofInterdisciplinary Information Studies, Universityof Tokyo, signed an MoU to collaborate for thetechnology and academic exchange related to
ICT such as IoT on June 2, 2018.
Kochi prefecture previously established Kochi IoT
Promotion Laboratory Study Group thatconsisted of private sector organizations,
universities, and financial institutions in July
2016. This move was to introduce the IoTtechnology to improve productivity of various
industrial sectors in Kochi. Also, it was meant tointroduce new solutions to the relief efforts after
the Nankai megathrust earthquakes off the costof Kochi, the issues of medical/health care andeducation in the sparsely populated midmountain range of the prefecture. Eventually thestudy group intends to market the IoT
application systems it develops to buyers in theprefecture and outside. As part of theprefecture’s approach in the ICT sector, theprefecture signed an MoU to collaborate on thetechnology and academic exchange related to
ICT such as IoT with the Graduate School ofInterdisciplinary Information Studies, the
CPaaS.io

Outlook
We will use the insights and experience,both from using the application and the
CPaaS.io components, for further
exploitation in research and development
projects as well as considering thecommercial exploitation.

As in Yokosuka, Miura city is content andcontinues to use the system in the future.
Mirura will help Yokosuka to showcase theoperation for wider adoption.

The use case can be deployed in any partof Japan or outside of Japan as far as
usable map infrastructure is available.
For the graduate school, the MoU is
expected to accelerate the research ofindustrial innovation and solutions toregional problems through IoT by using
local areas of Kochi prefecture as feasibility
experiment spots for IoT technology.
By using the MoU signing as a trigger, theprefecture will match and combine theneeds from the local primary sector ofindustry and the advanced know-hows andresearch results from the graduate school.
This helps the prefecture to promote thepolicy of “industry creation by problemsolving” to create systems, such as the IoT
applications, that offer new innovativevalues in the future.
Currently, the following four activities are
considered for the collaboration:
1.
2.

Performing a feasibility study of ICT by
the graduate school in Kochi prefecture
Graduate students visit Kochi
prefecture to learn firsthand how the
ICT is used in real world situation.
Page 33 of 40

Deliverable D8.4

City

H2020 EUJ-02-2016

Final Report: Summary of Outcomes

Summary of Results
University of Tokyo to promote the local
industry and devise solutions in local issues ofKochi prefecture by taking advantage of theadvanced latest IoT and other technologies
which the school has.
The graduate school of interdisciplinary
information studies is a school-wideorganization that performs integrated andadvanced research and education of informatics
by the collaboration of various study areas. Thisis the first time the graduate school signs anagreement with a prefecture government office.
It has been less than six months since the MoU
signing.
Two systems were developed and went throughfeasibility study experiments around the time
MoU was signed.
Both systems are IoT applications that use LoRa.
1. IoT system for Forestry Workers Safety
Workplace environment for forestry workers
is very dangerous: they handle dangerous
equipment such as chainsaws and the
topography of the workplace tends toexperience landslides, falling rocks, andfalling logs. In order to assure safety andemergency rescue in case of emergency, if aworker cannot move any more due to injury,etc., a means of emergency communicationmust be secured. In the past, however, theworkers tend to work in a dispersed manner,thus nearby workers are at a distance, andmobile phones may not be available since
the workplace is out of the service area.
The IoT system for Forestry Workers Safety"RingRing" [14] realizes the low-power long
distance communication by using a LoRa
network in forestry work environment inmountain areas where mobile phones
cannot be used. A forestry worker carries asmartphone and LoRa node. If an
unexpected accident happens and theworker is immobilized, the acceleration
sensor on the smartphone detects thesituation. That information is communicatedto the base camp (forestry industry
association, etc.) at the foot of the mountain
via the LoRa network. Base camp personnel
can then check the report of the potential
accident on the PC screen. If necessary,
warning messages are sent to nearby
workers via LoRa network so that the rescue
operation can start.
2. IoT system for Fishery Monitoring
Fishing off the coast requires widelydifferent methods and different timing to
CPaaS.io

Outlook
3. The graduate school provides/creates
the learning opportunities bycollaborating with Kochi IoT Promotion
Laboratory Study Group.
4. The graduate school offers training
opportunities of human resources in
the IoT sector (receiving personnel as
visiting researchers).
As of now, as the next step of theapplication of IoT to the primary sector of
the industry, UTokyo will join Kochi
prefecture's effort and conduct a projectcalled "Horticulture/Agriculture based on
Next Generation Facility" by means of IoP(Internet of Plants). This is a great
foundation for applying IoT platform to theagriculture, an important industry for ruralcities [15].

Page 34 of 40

Deliverable D8.4

City

Final Report: Summary of Outcomes

Summary of Results
catch fish based on the water temperatureand the wave patterns. If a fishing boat goes
off the coast when the waves are very high,the voyage may be futile. Hence, people in
the fishing industry desire to obtain theinformation of waves and temperature of
the fishing ground off the coast before they
set sail (temperature, vibration of the water
surface, acceleration, etc.).
The IoT system for Fishery Monitoring,"SeeSea" monitors the acceleration andtemperature of water surface and subsurface
water volume continuously and uploads theinformation to a cloud server via a LoRa
network. The SSC (SeaSee Cloud) systemprovides numerical values of theaccumulated sensor data or its visualization.
Fishermen can check the information of
sensors off the coast by using a smartphone,even from home.

Outlook

3 Summary and Outlook
CPaaS.io – City Platform as a Service – was 30-month Horizon 2020 EU-Japan joint Research and Innovation
Action, that set out to develop a Smart City data platform that can be federated to support regional oreven global applications, and that forms the basis for a smart city data infrastructure. Another goal had
been to implement use cases relevant to our city stakeholders. Both goals were reached.
The functional architecture of CPaaS.io is generic in the sense that it defines necessary functional
components for a Smart City data platform that integrates and makes available IoT data, that can address
security and data protection aspects, and that allows a flexible (re-)deployment of analytics functionality
from the cloud to the the edges. It also enables integration on the semantic layer, to enable interoperability
between different platform instances based on different implementation technologies, as wedemonstrated by federation of a FIWARE-based platform instance in Europe with a u2-based instance inJapan.
We are confident the concrete outcomes of the project as described in this report will live on beyond the
project. So has the projects work resulted in improved or with Fogflow completely new FIWARE
components that are available as open source and that we already see being used in other projects andcity deployments. Secondly, the work of CPaaS.io on semantics has strongly influenced the new semanticinterface for FIWARE, NGSI-LD.
Finally, the uptake in cities in the future will be critical. Already now we see that our stakeholder cities are
expanding their smart city activities, and new cities are adopting the technologies. The project partners of
CPaaS.io are continuing to work with these cities, using the tools developed during the project for the
benefit of these cities and their citizens.

H2020 EUJ-02-2016

CPaaS.io

Page 35 of 40

Deliverable D8.4

Final Report: Summary of Outcomes

References[1] FIWARE Architecture Description: IoT Broker. [Online] Available:
https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Io
T.Backend.IoTBroker. Accessed on: Dec. 21 2018.
[2] FIWARE Architecture Description: IoT Discovery. [Online] Available:
https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Io
T.Backend.IoTDiscovery. Accessed on: Dec. 21 2018.
[3] FIWARE Architecture Description: Data Context Broker. [Online] Available:
https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.D
ata.ContextBroker. Accessed on: Dec. 21 2018.
[4] B. Cheng et al., “FogFlow: Easy Programming of IoT Services Over Cloud and Edges for Smart Cities,”
IEEE Internet Things J., vol. 5, no. 2, pp. 696–707, 2018.
[5] ETSI, ETSI ISG CIM group releases first specification for context exchange in smart cities. [Online]
Available: https://www.etsi.org/news-events/news/1300-2018-04-news-etsi-isg-cim-group-releasesfirst-specification-for-context-exchange-in-smart-cities. Accessed on: Dec. 21 2018.
[6] ETSI, “GS CIM 004 - V1.1.1 - Context Information Management (CIM); Application Programming
Interface (API),” 2018. [Online] Available:
https://www.etsi.org/deliver/etsi_gs/CIM/001_099/004/01.01.01_60/gs_CIM004v010101p.pdf.
Accessed on: Dec. 21 2018.
[7] CPaaS.io, “Deliverable D6.1: Holistic Data Management: State of the Art,” Dec. 2016. [Online]
Available: https://cpaas.bfh.ch/wp-content/uploads/2017/08/CPaaS.io_D6.1_Holistic-DataManagement_State-of-the-Art.pdf. Accessed on: Dec. 21 2018.
[8] S. Haller, A. C. Neuroni, M. Fraefel, and K. Sakamura, “Perspectives on smart cities strategies,” in The
proceedings of the 19th Annual International Conference on Digital Government Research:
Governance in the Data Age : May 30 - June 1, 2018, Delft University of Technology, The Netherlands,
Delft, The Netherlands, 2018, pp. 1–6.
[9] T. Ritchey, “Modelling Complex Socio-Technical Systems Using Morphological Analysis,” 2003.
[Online] Available: http://www.swemorph.com/pdf/it-webart.pdf. Accessed on: Dec. 21 2018.
[10] K. Laaboudi and S. C. D’Ouezzan, “Introduction to the value chain smart city - From data to value,”2016. [Online] Available: http://www.e-madina.org/wp-content/uploads/2016/11/White-Paper-eMadina-3.0-Value-Chain-of-Smart-cities.pdf. Accessed on: Dec. 21 2018.
[11] C. Pfister, S. Haller, and E. Klein, “Towards a Smart City Blueprint Template,” in ICDS 2019: The
Thirteenth International Conference on Digital Society : February 24-28, 2019 - Athens, Greece, 2019.
[12] CPaaS.io, “Deliverable D2.9: Validation of Federation and Transferability,” Oct. 2018. Accessed on:
Dec. 21 2018.
[13] A. Osterwalder and Y. Pigneur, Business model generation: A handbook for visionaries, gamechangers, and challengers. Hoboken, N.J.: John Wiley & Sons, 2010.
[14] M. Kawaguchi, D. Nagayama, and N. Koshizuka, “RingRing：LoRaを活用した林業現場の緊急通報シ
ステム,” in 17th Forum on Information Technology (FIT 2018), 2018.
[15] Kochi Prefecture, Kochi prefecture’s activity framework (in Japanese). [Online] Available:
http://www.pref.kochi.lg.jp/soshiki/120801/files/2018110900071/file_201811951208_1.pdf. Accessedon: Dec. 29 2018.

H2020 EUJ-02-2016

CPaaS.io

Page 36 of 40

Deliverable D8.4

Final Report: Summary of Outcomes

Appendix: Smart City Toolbox Flyers
The following pages show single-page flyers that summarize the most important aspects of individual
Smart City Toolboxes:•••

FIWARE-based Smart City Toolbox
u2-based Smart City Toolbox
Smart City Toolbox for City Planners

The flyers can be used both as handouts at events or for initial discussions in Smart City projects. They
are also available on the project’s web site at https://cpaas.io/?page_id=1152.

H2020 EUJ-02-2016

CPaaS.io

Page 37 of 40

Smart City Tool Box

Brought to you by the Horizon 2020 EU-Japan Project CPaaS.io

The CPaaS.io project has resulted in a set of conceptual outcomes, concrete
tools and city deployments that will live on beyond the project, as shown in
the figure to the right. The foundation for all results are a number ofconceptual outcomes that are relevant for the platform as a whole and acrossthe regions. The concepts are implemented using specific tools for the two
implementation platforms, one for FIWARE-based implementations and one
for u2-based implementations. A third toolbox contains instruments thatmake life easier for city planners. And finally, the project has resulted inconcrete use case deployments in various cities in Japan and Europe, using
the tools provided by the project.

In this flyer, we highlight the FIWARE-based tools that others can use to make their cities smart. For all the rest and moredetails, please visit http://www.cpaas.io/

FIWARE Toolbox

Component
Name
IoT Broker
FogFlow
NGSI-LD Broker
Deployment
Knowledge BaseNGSI to RDF
Mapper
STH Comet

Security
Components
LoRaWAN to
NGSI-10 bridge
Grafana Plugin
Android App

The following components were developed or enhanced:

Short Description &Source Code Link
Separates IoT applications from underlying devices.
https://github.com/Aeronbroker/Aeron

Maintainer

Distributed execution framework to support dynamic
processing flows over cloud and edges.
https://github.com/smartfog/fogflow
Middleware component that implements the new
NGSI-LD API for Context Information Management

Tool for managing the deployment of IoT Devices,
including associations of mobile devices with people
and other physical entities .

Maps NGSI data model instances to RDF triples andinserts them in the CPaaS.io Semantic Data repository.
Manages historical raw and aggregated time series
information about the evolution in time of context
data registered in an Orion Context Broker instance.

FIWARE-based Instantiation
Architecture

PEP Proxy enforces authorization policies. All security
components available as a Docker image:https://github.com/cpaasio/
This bridge listens to incoming messages on
LoRaWAN applications and transforms them into
NGSI10 format using TTN device and decoder API.

Plug-in to visualize CPaaS.io data using the NGSI API
in Grafana.
https://github.com/cpaasio/Grafana-NGSI-Plugin.

Provides users with means for producing data(“Crowd-sensing”) and control their personal data.

For more information on other FIWARE components, please refer to the FIWARE Catalogue available athttps://www.fiware.org/developers/catalogue/

The CPaaS.io project is jointly funded by the European
Commission (grant agreement n° 723076) and NICT fromJapan (management number 18302). All information
provided on this flyer 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 atits sole risk and liability. For the avoidance of all doubts, theEuropean Commission and NICT have no liability in respectof this document, which is merely representing the view ofthe project consortium.

cpaas@bfh.ch

w w w . c p a a s . i oCoordinator Europe:

Prof. Stephan Haller
Bern University of Applied Sciences
E-Government InstituteBrückenstrasse 73
CH-3005 Bern
Switzerland

Project Duration:

July 2016 – December 2018@cpaasioSmart City Tool Box

Brought to you by the Horizon 2020 EU-Japan Project CPaaS.io

The CPaaS.io project has resulted in a set of conceptual outcomes, concrete
tools and city deployments that will live on beyond the project, as shown in
the figure to the right. The foundation for all results are a number ofconceptual outcomes that are relevant for the platform as a whole and acrossthe regions. The concepts are implemented using specific tools for the two
implementation platforms, one for FIWARE-based implementations and one
for u2-based implementations. A third toolbox contains instruments thatmake life easier for city planners. And finally, the project has resulted inconcrete use case deployments in various cities in Japan and Europe, using
the tools provided by the project.

In this flyer, we highlight the u2-based tools that others can use to make their cities smart. For all the rest and more details,
please visit http://www.cpaas.io/

u2 Toolbox

The following components were developed or enhanced:
Component
Name
u2 Open Data
Catalogue

Short Description & Relevant Links

kokosil

Software package to provide information for visitors andtourists in towns, tourist spots, commercial facilities, museums,
parks, exhibition venues, etc. as well as to residents. Easily
customizable to city needs. http://kokosil.net/index.en.html

OPaaS.io

uCR-Light
UTsignage

UTdashboard

Enhanceducode BLE

Maintainer

Provides an open data catalog function, managing meta dataof open data on the basis of an RDF framework and a
SPARQL-based API for each catalog entry.
Usage examples:• http://yokosuka-opendata.ubin.jp• http://docs-sapporo.odcity.org/

General-purpose PDS (Personal Data Store) that uses the IoTtechnology. Also called "Omotenashi (hospitality) cloud“, it canbe used to advance the hospitality service to the increasing
number of overseas tourists who are expected to peak toward2020 with the Tokyo Olympic and Paralympic Games.
Enhanced API: https://contest.opaas.io/api-spec.html
uCR-Light is a federation layer API to exchange data acrossdifferent CPaaS.io instances. Its syntax is based on JSON and
RESTful protocol. Its semantics is ucR, i.e., ucode + RDF.

UTsignage is a signage system that can customize the display
based on the personal data of the user stored in the OPaaS.io
cloud. It is built on top of uCR-Light and can use the data fromremote CPaaS.io instance(s).

UTdashboard is a dashboard for monitoring IoT smart
buildings built on top of the u2-based architecture. It has beencreated using ucR-Light, and can monitor Japanese and the EU
smart buildings simultaneously.

Enhanced by UTokyo to offer the proof of the location feature.
Standard specification of ucode tags using Bluetooth Low
Energy as communication protocol (in Japanese):
http://www.uidcenter.org/wpcontent/blogs.dir/1/files/2017/11/UID-00049-01.A0.05.pdf

The CPaaS.io project is jointly funded by the European
Commission (grant agreement n° 723076) and NICT fromJapan (management number 18302). All information
provided on this flyer 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 atits sole risk and liability. For the avoidance of all doubts, theEuropean Commission and NICT have no liability in respectof this document, which is merely representing the view ofthe project consortium.

cpaas@bfh.ch

w w w . c p a a s . i oCoordinator Japan:

Prof. Ken Sakamura
YRP Ubiquitous Networking Laboratory
Seijitsu Building-1
2-12-3 Nishigotanda
Shinagawa, Tokyo 141-0031
Japan

Project Duration:

July 2016 – December 2018@cpaasioSmart City Tool Box

Brought to you by the Horizon 2020 EU-Japan Project CPaaS.io

The CPaaS.io project has resulted in a set of conceptual outcomes, concrete
tools and city deployments that will live on beyond the project, as shown in
the figure to the right. The foundation for all results are a number ofconceptual outcomes that are relevant for the platform as a whole and acrossthe regions. The concepts are implemented using specific tools for the two
implementation platforms, one for FIWARE-based implementations and one
for u2-based implementations. A third toolbox contains instruments thatmake life easier for city planners. And finally, the project has resulted inconcrete use case deployments in various cities in Japan and Europe, using
the tools provided by the project.

In this flyer, we highlight the tools that support city planners for making their cities smart. For all the rest and more details,
please visit http://www.cpaas.io/

Toolbox for City Planners

Smart City Strategy Framework
The Smart City Strategy Framework provides a tool for comparing
smart cities in an international context and supports cities in theformulation of new strategies.
The framework consists of a morphological box, with the 19
elements grouped into 4 dimensions: City context, governance,
implementation and infrastructure. For each element, 2-6 possible
manifestations are defined. Morphological analysis is a well-suited
For method for studying and analyzing complex problem fields
that are inherently
inherently non-quantifiable,
non-quantifiable, containcontain non-resolvablenon-resolvable uncertainties, cannot be casually modeled or analyzed,
and require a judgmental approach.
For further information, see https://cpaas.io/?page_id=1169#strategy_framework or the following research paper:
Haller, Neuroni, Fraefel, Sakamura, Perspectives on smart cities strategies, 2018. doi: 10.1145/3209281.3209310.
Smart City Application Blueprint Template
Since every city has specific characteristics, smart city applications
are not transferable without adaption to its context. The Smart
City Application Blueprint Template supports such an adaption
well. The template guides through the problem-solving cycle andassists in the abstraction and concretization process of a smart city
application and with that help in the adaption process.
The blueprint template covers important categories along thevalue chain of smart city applications. It considers processes,
architecture views, hardware, software, possible project andcommunication plans, supporting the creation of public valueinterest
are:are:thetheSmart
City City
One-One-Pager, and the Smart City Canvas based onwithin aa smart
smartcity.
city.OfOfparticularparticularinterest
Smart
Pager, and theBusiness
Smart City
Canvasbased on Osterwalder’s Business
Osterwalder’s
Model
Canvas.
Model Canvas.
For further information, see https://cpaas.io/?page_id=1169#blueprint_template or the following research paper:
Pfister, Haller, Klein, Towards a Smart City Blueprint Template, 2019.
https://www.thinkmind.org/index.php?view=article&articleid=icds_2019_2_10_10013

The CPaaS.io project is jointly funded by the European
Commission (grant agreement n° 723076) and NICT fromJapan (management number 18302). All information
provided on this flyer 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 atits sole risk and liability. For the avoidance of all doubts, theEuropean Commission and NICT have no liability in respectof this document, which is merely representing the view ofthe project consortium.

cpaas@bfh.ch

w w w . c p a a s . i oCoordinator Europe:

Prof. Stephan Haller
Bern University of Applied Sciences
E-Government InstituteBrückenstrasse 73
CH-3005 Bern
Switzerland

Project Duration:

July 2016 – December 2018@cpaasio