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

Deliverable D2.9

Validation of Federation andTransferability
Version V1.0
October 31, 2018
ABSTRACTIn this deliverable we report on the evaluation results of federation andtransferability criteria for the respective use cases. Based on the transferability
analysis work, we also provide a Blue Print template to facilitate the transfer ofSmart City applications to another city, including an initial instance of such a blue
print for one of the project's use cases. In addition to the use cases that we usedin D2.7 Criteria for Validating Federation and Transferability further technicalfederation scenarios are used for validating CPaaS.io federation capabilities. This
includes a Smart Building scenario and a technical use case for storing personal
data across platform instances. This deliverable includes an overall assessment
using the validation framework described in D2.7. For each scenario we provide ashort technical description of how the CPaaS.io platform is used to achievetransferability and federation and highlight the CPaaS.io components used for therespective scenarios. As defined in D2.7, we also explain explicitly which relevant
application requirements have been validated for each criteria and scenario.

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 D2.9

Validation of Federation and Transferability

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

Martin Strohbach (AGT), Chiaki Ishikawa (YRP)

Authors

Martin Strohbach (AGT), Stephan Haller (BFH), Christian Pfister (BFH), Juan A.
Martinez (OdinS), Antonio Skarmeta (OdinS)

Reviewers

Ernö Kovacs (NEC), Fahim Khan (UoT)

Delivery Type

ReportDissemination Level

PublicContractual Delivery Date

30/09/2018

Actual Delivery Date

31/10/2018 (as agreed with PO, 26/09/2018)

Keywords

Validation, Federation, Transferability, cross-border, blue prints

CPaaS.io

Page 2 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

Revision History
Rev.

Date

Description

Contributors

27/07/2018

TOC and initial document structure

Martin Strohbach (AGT)

0.2

08/08/2018

Initial input for section 4.1.1

Martin Strohbach (AGT)

0.3

27/08/2018

Initial input for section 4.2.1 and 4.2.2

Juan A. Martinez (OdinS)

0.4
0.5
0.6

10/09/2018
18/09/2018
20/09/2018

Stephan Haller (BFH)
Stephan Haller (BFH)
Juan A. Martinez (OdinS)

0.7
0.8

10/10/2018
15/10/2018

0.9

16/10/2018

Added chapter 2, validation results
Added chapter 5, blue prints
Extension to section 4,2, 4.2.1 and4.2.2
Updated section 4.1.1
Finalized contributions in section
4.1.1 and updated 3.2
Finalized contributions in section
3.1.4, 4.2.1 and 4.2.2

0.10

17/10/2018

0.11

17/10/2018

0.12

19/10/2018

0.13

19/10/2018

0.14

25/10/2018

0.15

29/10/2018

0.1

CPaaS.io

Edited Table 13 and Table 14 andadded paragraphs referring to thetablesAbstract and introduction added,
integrated final version of
Waterproof Amsterdam
Edited 3.1.3 Tokyo Management ofService Vehicle (ACC)
Updated Tables in Chapter 2, Added
section 6 (Summary), References in
Chapter 5 and 7
Added tables/figures for Yokosuka
and Sapporo use cases.
Minor edits to prepare for review

Page 3 of 60

Martin Strohbach (AGT)
Martin Strohbach (AGT)
Juan A. Martinez (OdinS),
Antonio Skarmeta(OdinS)
Martin Strohbach (AGT)

Martin Strohbach (AGT),
Sylvain Prost (TTN)
Toshihiko
Yamakami(ACC), Martin
Strohbach (AGT)Stephan Haller (BFH),
Martin Strohbach (AGT)
Chiaki Ishikawa(YRP)
Martin Strohbach (AGT)

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

Table of Contents
1

Introduction............................................................................................................................................................................... 6

2

Overview of Validation Results .......................................................................................................................................... 7

3

4

5

2.1

Overall Results ................................................................................................................................................................. 7

2.2

Assessment of Maturity Criteria ............................................................................................................................... 8

2.3

Assessment of Federation and Transferability Criteria .................................................................................... 8

2.4

Assessment of Transformation Criteria.................................................................................................................. 9

2.5

Assessment of Sustainability Criteria ...................................................................................................................... 9

Transferability Results.......................................................................................................................................................... 18
3.1

Driving applications .................................................................................................................................................... 18

3.2

List of Criteria ................................................................................................................................................................ 27

Federation Results ................................................................................................................................................................ 27
4.1

Driving Applications .................................................................................................................................................... 28

4.2

Technical Federation Scenarios .............................................................................................................................. 34

4.3

List of Criteria ................................................................................................................................................................ 45

Blueprints ................................................................................................................................................................................. 46
5.1

Value Chain of Smart City Applications ............................................................................................................... 47

5.2

Structure of the Smart City Blue Print Template .............................................................................................. 48

5.3

Adapting an existing Smart City Blue Print ........................................................................................................ 56

5.4

Smart City Blue Print Validation ............................................................................................................................. 57

6

Summary................................................................................................................................................................................... 59

7

References................................................................................................................................................................................ 59

CPaaS.io

Page 4 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

Table of Acronyms
AcronymDefinition

IoT

Internet of Things

CPaaS.io

Page 5 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

1 Introduction
In this deliverable we present our validation results of the CPaaS.io that 1) demonstrate how the CPaaS.io
platform supports the transferability of applications to different city and regions and 2) how different
platform instances can be federated, in particular focusing on federation of European and Japaneseplatform instances.
In order to assess and validate the CPaaS.io results we have developed a validation framework that we
presented in D2.7 Criteria for Validating Federation and Transferability. In section 2 we present how thisframework has been used for validating our results. This includes an assessment of maturity critieria,federation and transferability criteria, transformation criteria, sustainability criteria and an assessment of
the value creation. The assessment shows that we could validated most of the criteria.
In the following sections we use the main CPaaS.io use cases to validate federation and transferability
capabilities offered by the platform. For each scenario we provide a concise technical description of how
the CPaaS.io platform is used and how the criteria and relevant application requirements described in D2.7
have been used for validation. In particular, we highlight the CPaaS.io components and potential target
cities.
Section 3 presents the transferability results and includes the scenarios Waterproof Amsterdam, Yokosuka
Emergency Medical Care, Tokyo Management of Service Vehicles and Smart Parking. We could show that
all of these applications benefit from the transferability support offered by CPaaS.io which includes
primarily the unified interfaces and data models that CPaaS.io is offering for managing data. For most of
the applications concrete transfer activities are in progress and initial results have been achieved bytransferring the Yokosuka Medical Emergency Care application to Miura City. Although not explicitly
mentioned in section 3, the My Events application, the web app implementing the Enhanced User
Experience use case, has been demonstrated to be transferrable from an event in the City of Utrecht to the
Sapporo Snow Festival.
Federation results are presented in section 4 in which we distinguish between the driving applications
including the Enhanced User Experience and Sapporo Visitor Experience use cases and additional technicalfederation scenarios including a smart building use case and a Personal Data Storage integration scenario.
Each of the use cases and scenarios have their specific focus on validating the federation capabilities of
the CPaaS.io platform. For instance, the Enhanced User Experience use case validates how the CPaas.io
platform can be used for semantically federating the European and Japanese platform instances, i.e. theintegration happens on the semantic integration layer. In addition, this use case relies intensively on
personal data and therefore uses the CPaaS.io security and privacy enablers. The smart building scenario
on the other hand demonstrates how the European and Japanese platform instances can be federated on
the virtual entity layer of the platform in order to achieve a unified view on physically separated entities
such as buildings and rooms. Another example is the Personal Data Storage integration that validates how
two the respective mechanism in the European and Japanese platform instances can be federated to
manage personal data across platform instances.
Finally, we present the synthesized findings for transferring applications between cities and countries as a
blue print template in section 5. Blue prints can be used to facilitate and speed up re-occurring challenges
in smart city projects with a particular focus to avoid re-inventing the wheel, but take into account thatevery city has its specific characteristics and requirements, which require adaptations when transferring
applications to a different environment.
Finally, we conclude this deliverable in section 6 summarizing our key results and findings.
CPaaS.io

Page 6 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

2 Overview of Validation Results
In deliverable D2.7 we presented a validation framework as a tool the assessment of Smart City project andin particular CPaaS.io, as we had realized that validation activities had been fragmented and distributed
across several deliverables. We have now used this framework to assess the current state of CPaaS.io, andthe results are presented in the following subchapters.
To recap, the validation framework considers different validation dimensions: the CPaaS.io project, thecities view regarding the four use cases and the joint use case, as well as the CPaaS.io platform (see ). Eachdimension is validated from four perspectives: maturity, federation and transferability, transformation as
well as sustainability. Furthermore, the assessment takes into account various approaches and possible
challenge areas, such as technical, social, political and legal ones.
Figure 1 Dimensions of the Validation Framework

2.1 Overall Resultsshows the results of the overall assessment for each criterion. For the overall assessment, each criterion is
given a summary "achievement score" based on the detailed assessment of the maturity, federation andtransferability, transformation and sustainability perspectives. These detailed assessments will be describedin the subsequent chapters. We used a 3-level rating on each criterion:Table 1 shows the results of theoverall assessment for each criterion. For the overall assessment, each criterion is given a summary"achievement score" based on the detailed assessment of the maturity, federation and transferability,transformation and sustainability perspectives. These detailed assessments will be described in thesubsequent chapters. We used a 3-level rating on each criterion:••

Overachieved (dark green): More was delivered than originally envisioned or promised.
Achieved (green): The project reached the goals

CPaaS.io

Page 7 of 60

H2020 EUJ-02-2016

Deliverable D2.9•

Validation of Federation and Transferability

Partially achieved (red to yellow): The targets were only reached partially. In this case a percentage ofthe target achievement is given.

Where measureable KPIs had been defined beforehand, the achievement score is based on the actual
numbers, in the other cases, the score is based on an assessment by the project members.
When looking at , it becomes clear that the project did very well overall. The project created significant
value for the cities involved and results are being reused also for projects in other cities, and components
like FogFlow or the security components, as well as standardisation efforts (in particular through ETSI CIM
and ETSI CDP) show the impact of the platform on other communities as well. Similarly, the impact of
CPaaS.io also manifests itself in the maturity, transformation and sustainability perspectives, where mostcriteria get a score of achieved or even overachieved.
The picture is currently less positive on the federation and transferability. This is mainly due to two reasons:Firstly, activities on federation topics issues were from the beginning scheduled towards the end of the
project and thus are still on-going. Secondly, the use cases in the two regions are quite different, thus there
is no or only little real business value for federation or data transfer. In the remainder of the project, weare though trying to address these issues and are working on some prototypes to demonstrate thetechnical feasibility of federating platform instances.

2.2 Assessment of Maturity Criteria
The assessment regarding the maturity criteria is shown in . Most of the targets have been achieved, andthe project scores especially on the impact in cities, with additional platform and use implementations in
Heidelberg, Murcia, Miura and Kochi prefecture that go beyond the project's lifetime. Regarding thetechnology readiness level (TRL 1 ), the prototypes have been demonstrated in relevant environments,
corresponding to TRL 6 and the target value of CPaaS.io, and some (Sapporo, Yokosuka) even in theoperational environment, i.e., reaching TRL 7. CPaaS.io has also significantly contributed to standards, as
has already been reported in deliverable D7.6, and is continuing to do so.
The goals regarding blue-printing of Smart City solutions has not been reached yet. While an initial
template for blue prints as well as the blue printing process is given in chapter 5, including an initial blue
print for the Amsterdam Water Management use case for illustrative purposes, this work needs to befurther validated, which is a currently on-going process.5, including an initial blue print for the Amsterdam
Water Management use case for illustrative purposes, this work needs to be further validated, which is acurrently on-going process.
Regarding data quality annotations, an ontology has been defined, and the enhancement of data query
results with data quality information is currently on-going.

2.3 Assessment of Federation and Transferability Criteria
As can be seen, work on federation and transferability has so far mainly been limited to showing thetechnical feasibility, concretely by accessing another platform instance via APIs, SPARQL queries acrossplatform instances, as well as data transfer of Sapporo event data from Japan to Europe for further analysis.

1 For a definition of the TRL as used within the Horizon 2020, see

https://ec.europa.eu/research/participants/data/ref/h2020/wp/2014_2015/annexes/h2020-wp1415-annex-g-trl_en.pdf
CPaaS.io
Page 8 of 60
H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

Work on this is still on-going, however, the use cases in Japan and Europe are very different, thus afederated use case with clear and concrete business value is hard to find. Hence the project is more focusedon exchanging knowledge among the project members and limiting the federation aspects to the technicalfeasibility. As clear APIs are defined for both platforms, and SPARQL queries across platforms are easily
implementable as well, federation on a data level is not difficult to achieve. More effort is required by thelegal process to allow such data exchange; for the transfer of Sapporo data not only did the data subjects
needed to sign consent forms, but also the partners involved in the data transfer needed to sign respective
legal agreements.

2.4 Assessment of Transformation Criteria
shows the assessment regarding the transformation criteria. Innovative Smart City projects like CPaaS.io
often are facing a moving target. In the case of this project, it meant to set its focus on use cases with aclear business value for the cities involved, rather than stressing the less relevant – though interesting –topic of federation.
Assessing the extent to which the CPaaS.io project is leading to transformations in cities is difficult
currently, as many of the use cases are still in a testing and evaluation phase. Certainly, the Emergency
Health Care Service use case is leading to process and service changes in Yokosuka and Miura, tourists can
profit from new informational services in Sapporo (and will for the upcoming 2020 Tokyo Olympics),
participants in fun events like the Colour Run get new experiences through the new service offerings, andin Amsterdam the use of smart water buffers changes how it is managing its water systems. Also, theOmotenashi platform, to which CPaaS.io contributed, will give visitors to Japan better control over theirdata.

2.5 Assessment of Sustainability Criteria
Sustainability in this context means the sustainability of the project's results and their effects beyond thelifetime of the project, not ecological sustainability. shows the current assessment in this regard.
The project is doing very well on publication, impact and usage. The latter two are especially important, as
they fit with one of the most important objectives of the project, i.e., to create impact in cities. Also new
projects are being launched out of the experiences gained in CPaaS.io, both research projects as well as
implementation projects in cities.
Two criteria, the stakeholder benefit as well as benefit and pain reliefs, are currently set to 0% achievement.
This number is misleading, as the assessment has been postponed until after the last city stakeholder
workshop in December. The feedback we have received from cities so far is however positive.
Finally, the business and financial model for sustaining the platform is not in the scope of the project itself,
but is being done by project partners individually.

CPaaS.io

Page 9 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability
Table 1: Overall Assessment of CPaaS.io
Project view (A)Maturity criteria (I)Federation and Transferability
criteria (II)Transformation criteria (III)Achievement

City/ Use cases view (B)Overall:
Value creation assessment

CPaaS.io

Platform view (C)Achievement
overachieved• Formulated objectives fulfillment

achieved• Maturity use cases and joint caseachieved• # functionalities andcomponents (incl. usefulness)• Concrete contribution to thedeclared motivation areasachieved• Clarification political, legal andorganizational issues

achieved• Usage of functionalities andcomponents in different scenarios• Contribution goals EU-JPN-Call(incl. collaboration rate EU-JPN)

60%• Amount scenarios beyond the
project

overachieved

cf. BII and CII• Project goals evolution andcreated value assessment

50%

achieved• Cross-border collaboration
options and exchange rates ofbest-practices

80%• Transferability options for use
cases scenarios in other cities(activities, plans or ideas)50%• Participants transformationassessment (cities, companies,
citizen)• Benefit assessment for different
stakeholder

Sustainability criteria (IV)

Achievement• Dissemination rate and launch
new R&D-Ideas respectively new
projects• Created value and innovation in
the area “IoT – Smart cities”• Created value in the EU-JPNconstellation

overachieved

overachieved
80%

achieved0%• Stability and performanceassessment• Amount of federate crossborder instances that enableapplications using different
platform instances• Transferability of functionalities,
applications and data to different
city• Platform Evolution Assessment(2016-2017-2018), incl. data
quality, governance andapplications• Benefits and pains reliefs fordifferent stakeholder• Platform usage evidence• Impact measurement in the use
cases

overachieved• Created value for the cities

overachieved• Created value for other servicedeliverers

Page 10 of 60

achievedachieved

80%

50%

33%

achieved

0%achieved• Finance model for the platform
maintenance beyond the project75%• Created value throughfunctionalities and components ofthe platformoverachieved

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

Table 2: Assessment of Maturity Criteria
Ref.

Criteria

Description

KPI

Overall
Achievement

Value

Achievement

Assessment# of OGD data sets interlinked with IoT data

3

60%

SPARQL access point in the platformY

achieved

Technology Readiness Level (TRL)

6overachieved# of third party applications built on the top of theplatform> 20

achieved

Cf. Open Data Challenge for Public
Transportation in Tokyo# of deployed platform instances in the Cloud3

achieved

1 in Europe, 2 in Japan (Sapporo, Yokosuka)# of federations

2

achieved

Sapporo data has been transferred to European
platform, cross-platform calls being
implemented# of demonstrations showing redeployment ofanalytics functionality

3

achieved

2 of NEC, 1 in Japan in planning

Data quality annotations for all queries-

20%

Quality ontology defined, will be available insome queriesYachieved

Settings in MyEvents as well as Omotenashi

1

33%

6

overachieved

Sapporo, Yokosuka, Tokyo, Amsterdam, Murcia,
Heidelberg
Blue print template defined and preliminarily
filled out for Amsterdam.
Yokosuka use case has been adopted by Miura
city

Cf. Tab. 1 - Self-assessment goals attainment

IAIA

CPaaS.io

Fulfillment
objectives

Contribution
areas / call

CPaaS.io combines IoT,Big Data, and Cloud with
Linked Data and Open
Government Data tocreate Smart City
Innovation (cf. Figure
1.1.a DoA, p. 3) – are theformulated objectives
fulfilled?

Dashboard easily usable by citizens to control accessto their data
# of credible demonstrations showing adaptive,
context-dependent data access# of use cases implemented and positively validated
by the City Stakeholder Group

Traffic data in Tokyo, tourist info in Sapporo,weather data planned in Amsterdam
1 in Europe and 1 in JapanTRL 6-7: Prototypes have been demonstrated in
relevant environments, some also in theoperational environment (Sapporo, Yokosuka)

Privacy settings in Omotenashi platform# of blue prints developed and successfullytransferred and adapted to another region

1-2

50%

# of cities testing prototype

8

overachieved

Sapporo, Yokosuka, Tokyo, Miura, Kochi,
Amsterdam, Murcia, Heidelberg# of cities interested in continued operation of theplatform beyond the project>4

overachieved

Yokosuka, Miura, Kochi, Murcia# of standards contributions

5

overachieved

ETSI CIM & CDP, IEEE P2748, AIOTI WG3,FIWARE

Self- assessment of addressed scopes in the call (scale
1 to 5):

Page 11 of 60

achievedachieved

H2020 EUJ-02-2016

Deliverable D2.9
Ref.

Criteria

Validation of Federation and Transferability
Description

KPI“The scope is to realize IoT/Cloud/Big Data platforms
in social application contexts.”“Specific requirements include multiple sensors anddevices linked with big data analytics and cloud data
management, edge-heavy computing, machinelearning and complex event discovery, and a
programmable IoT logic and IoT Data Warehouse.”
Which are the main
project contribution
areas?

IA

Collaboration
EU-JPN

Description of thecollaboration (quality, in
IT and business view)
and value

Overall
Achievement

Value

AchievementYachieved

Platforms have been implement in EU andJapan, and applications with social value havebeen implemented on the platforms

achieved

Multiple IoT sensors have been used in all
scenarios, and data analytics has been used in
the Color Run and Sapporo use cases.
Furthermore, FogFlow enables flexible edge
computing and programmable IoT logic, andoffers the required cloud/edge management
capabilities.

Y

Assessment“The research will address technological issues in big
data application scenarios such as: elasticity andscalability of cloud data management; transregional
federated clouds; distributed storage; distributed
and/or edge computing; wireless sensor networks;
cross-sectoral and spatio-temporal data analysis; etc.”

Yachieved

The focus of CPaaS.io was on simplifying the useof distributed logic and edge computing.
FogFlow has significantly facilitated this and also
has become an official FIWARE Generic Enabler,
ensuring use in the future.

“Applications related in particular to smart cities
supporting urban needs and green manufacturing
should serve as test-bed and verification areas.”Yachieved

Several smart city applications have been
implemented that will go beyond just test-beds.

50%

As the technical implementation architecturesare quite different, technical collaboration takes
mainly place on a conceptual level, as well as
API-based federation.

50%

Scenarios are too different for concrete direct
collaborations.

Self-assessment of collaboration quality for IT mattersn/aSelf-assessment of collaboration quality for businessmattersn/a# of scenarios with value generation (incl. description)

(1)

80%

Several smart city applications have been
implemented in each region, but only minimal
collaboration.

6

overachieved

Sapporo, Yokosuka, Tokyo, Amsterdam, Murcia,
Heidelberg

(1-2)

50%

Blue print template defined and preliminarily
filled out for Amsterdam.
Yokosuka use case has been adopted by Miuracity

Yachieved

60%

Cf. Tab. 1 - Self-assessment goals attainment, e.g.

IB

IB

CPaaS.io

Implementation
state use cases

How can we assess theimplementation state ofthe different use cases
and the joint case?

# of use cases implemented and positively validated
by the City Stakeholder Group# of blue prints developed and successfullytransferred and adapted to another region
Y/N

Page 12 of 60

achievedachieved

H2020 EUJ-02-2016

Deliverable D2.9
Ref.

Validation of Federation and Transferability

Criteria

Description

KPI

Clarification
generalconditions

Were political, legal andorganizational issues
clarified? Contribution?

Description of specific contributions

IB

Scenarios
beyond the
project

Concrete follow-ups?

# of scenarios beyond the project3

overachieved

IC

Functionalities
andComponents

Developed
functionalities andcomponents?

# of functionalities and components

4achieved# of scenarios with usage of functionalities andcomponents

6

achieved

Usage

Usefulness of thefunctionalities andcomponents?

IC

IC

CPaaS.io

Stability and
Performance

Stability andperformance of theplatform?

Value

Achievement

Overall
Achievement

Assessment
Main issue here was to address privacy aspects,
using consent forms and data transfer
agreements.

Qualitative self-assessment usefulness

Qualitative self-assessment / results D2.6 and D2.11

Page 13 of 60

With Kochi, Heidelberg and Murcia 3 concrete
additional use cases will be implemented
beyond the project
New functionalities include Semantic integration
layer (cross-platform), Personal Data Store, Edge
Computing (2), other existing components havebeen enhanced
All scenarios use some of the new functionalities
and components.

achieved

In particular FogFlow enables completely new
kinds of scenarios.

80%

Both stability and performance fits the current
use caseoverachievedachievedachieved

80%

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

Table 3: Assessment of Federation and Transferability Criteria
Ref.

II B

II B

II B

Criteria

Description

KPI

Collaboration
Use Cases

In what way havecross-bordercollaboration
options and bestpractice exchanges
taken place?

# of collaboration scenarios / knowledge & experiencetransfer between use cases / joint case (incl. short
description)

Transferability
Use Cases

Transferability
options for use cases
scenarios in other
cities (activities,
plans or ideas)

Exchange of
personal
information

II C

Federation
Feasibility

II C

Transferability
Feasibility

CPaaS.io

Can the CPaas.io
platform be used to
exchange personal
information between
Europe and Japantaking respective
regulations into
account?
Can the CPaaS.io
instances befederated to enable
the implementationof a cross-regional
application withvalidated businessvalue?
Transferability offunctionalities,
applications anddata to different city

Overall
Achievement

Value

Achievement

380%

A few joint demonstration use cases are indevelopment to show the technicalfeasibility.

80%

50%

The blue print templates will enabletransferability, but due to the very different
requirements of the cities, no concrete
transfers have taken place with the exceptionof the Emergency Health Care Applicationthat has been transferred from Yokosuka to
Miura.

50%

50%

Data from Sapporo has been transferred to
CPaaS.io instance. However, automatic datatransfer is not possible, as legal data transfer
agreements need to be signed.

50%

75%

A few joint demonstration use cases are indevelopment to show the technicalfeasibility, but without concrete businessvalue.

75%

50%

Only some data from Sapporo has beentransferred, plus the transfer from Yokosuka
to Miura50%# of activities, plans or idea for reproducing a scenario in
a new context (incl. short description)

1

Availability prototype that shows the exchange of
personal information and an explanation how platform
components support the exchange of personal
information

Y# of applications

1

At least one implemented application that relies onfederated platform instances# of transferred components

1-2Page 14 of 60

Assessment

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability
Table 4: Assessment of Transformation Criteria

Ref.

III A

III B

III C

CPaaS.io

Criteria

Description

Moving targets

Any changes(goals, emphasis)
during theexecution of the
project?

Transformationin cities

Any changes inprocesses andservice delivery?
Empowerment
citizen?

Evolution
platform

Platform evolution
fromconceptualization
to realization?

KPI

Value

Achievement

Overall
Achievement

Assessment

Y /N (if Y, description of goals evolution)Yachieved

Focus on value in the specific use cases andthe requirements of the cities - e.g.,federation not that important in the involved
cities# of changed processes (incl. short description)3

achieved

Emergency services, tourist services, parking# of changed services (incl. short description)

4

achieved

Emergency services, tourist services, colour
run, parking# of scenarios with citizen empowerment (incl. short
description)2achieved

Omotenashi, Colour Run# of additional functionalities resp. components(compared to DoA)

1

achieved

Functionalities/components mostly as
originally foreseen. FogFlow as main newcomponent.

1

33%

Privacy settings in Omotenashi platformY

achieved

Settings in MyEvents as well as Omotenashi

Data quality principle (available Y / N)Y

achieved

Data quality ontology defined

Data governance concept (available Y / N)Y

achieved

Available for the specific city
implementations# of credible demonstrations showing adaptive, contextdependent data access
Dashboard easily usable by citizens to control access totheir data (available Y / N)

Page 15 of 60

achievedachievedachieved

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

Table 5: Assessment of Sustainability Criteria
Ref.

IV A

IV A

IV B

IV B

IV C

Criteria

Publications

New projects

Benefitstakeholders

Impact use
cases

Benefit andpains reliefs

Description

Dissemination rate

Launch new
projects
Benefit description/ stakeholder(overall)Concrete impact inpractice

Benefit and pains
reliefs platform

KPI

Achievement

Assessment# of paper at IoT / Big Data / Cloud / LOD / Smart City
scientific conferences

19

overachieved

19 conference papers plus 3 journal
publications by the end of Y2# of contributions at IoT / Big Data / Cloud / LOD /Smart City professional events

11

overachieved

8 demos at exhibitions, 2 co-creation
workshops, 1 summer school session by theend of Y2# of standards contributions

5

achieved

3

achieved

3

achieved# of new international projects and activities (short
description)# of new national projects and activities (short
description)
Qualitative self-assessment / reflection results D2.6 +
D7.5

Usage

5 contributions so far
achieved

n/a

not available yet

0%# of areas where value has been created (short
description)

5

achieved

Event management, tourist information,water management, smart parking,emergency health care

# of cities testing prototype

8

overachieved

Sapporo, Yokosuka, Tokyo, Miura, Kochi,
Amsterdam, Murcia, Heidelberg

4overachieved

Yokosuka, Miura, Kochi, Murcia# of cities interested in continued operation of theplatform beyond the project
Qualitative self-assessment / reflection results D2.6 +
D7.5

n/a

not available yetoverachieved

0%(given Y / N - per stakeholder: scale 1 to 5)
8overachieved

Usage of the
CPaaS.io platform

Amsterdam, Murcia, Heidelberg, Sapporo,
Yokosuka, Miura, Kochi, Tokyo
achieved

Qualitative self-assessment usefulness

CPaaS.io

overachieved(given Y / N - pro stakeholder: scale 1 to 5)# of scenarios with platform usage (evidence)
IV C

Overall
Achievement

Value

n/a

Page 16 of 60

achieved

Continued use of application after the
project; new city applications being
developed.

H2020 EUJ-02-2016

Deliverable D2.9
Ref.

IV C

CPaaS.io

Validation of Federation and Transferability

Criteria

Description

KPI

Business model

Finance model forthe platform
maintenancebeyond the
project?

Concrete options / finance model Y / N

Value

Achievement

Y

75%

Page 17 of 60

Assessment

Up to project partners

Overall
Achievement75%

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

3

3 Transferability Results
In this section we provide the validation results related to the transferability of applications to different
cities.

3.1 Driving applications
Driving applications for transferability include waterproof Amsterdam, Yokosuka Emergency Medical Care,
Tokyo Management of Service Vehicle and Smart Parking. We first describe the applications with respect
to their transferability, describe transfer activities, the target cities and finally present requirements.
3.1.1 Waterproof Amsterdam
The Waterproof Amsterdam application is in itself a city-agnostic application as it is not bound by any
geography. However, it is addressing urban challenges that are only relevant for cities dealing with large
amounts of (rain) water and/or outdated sewerage infrastructure.
It is also a complex application to transfer in its full breadth to other cities, due to the number of different
stakeholders involved in an implementation, even at a small scale. It requires first of all a willing and capable
local water management company. Next, different hardware vendors and distributors need to be(technically) aligned and open to collaborate with the water management company. Lastly, real estate

SMART CITY Services Layer

SPARQL App
Developer

FIWARE App
Developer

Security &Privacy Pillar

IdM API

KeyRock

Knowledge Layer
SPARQLKAT Toolkit

Platform
Management ,Federation andOperation
Pillar

XACML
XACML

Semantic Data &Integration Layer

IoT Knowledge
Server
Deployment
Tool

STH Comet
NGSI10KnowledgeServer API

Capability
API

NGSI to RDF
mapperNGSI10NGSI9NGSI10

PEP-Proxy

Virtual Entity Layer

FogFlowNGSI9

IoT Discovery

Capability
ManagerContext Broker

NGSI9

Encryption
API
NGSI10NGSI10CP-ABE

IoT Data &Ingestion Layer
NGSI10IoT Broker
NGSI10SPARQL

Existing components
New/enhanced
components

IoT Resource Layer

SPARQLAgent

IoT Agent

LoRaWAN to NGSI
bridgeDevice API

Device architecture
LoRa Device
Figure 1 - Waterpoof
diagramCPaaS.io

Page 18 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

owners and developers have to be willing to implement smart rain buffer solutions on their rooftops andpotentially delegate part of the control over the mechanisms.

3.1.1.1 Transfer Activities and Validation Results
At the time of writing, there are no concrete plans for transferring the Waterproof application to anothercity. The reason behind this is that even for Waternet, the water management company for the city of
Amsterdam, the application is highly experimental, and the scope limited to a limited number of rooftops
that contain smart rain water buffering capacity. The Netherlands makes a good geography for broader
implementation of the Waterproof application due to its wet climate and its susceptibility to water
problems.
We however have been in touch with water management company from the city of Delft(Hoogheemraadschap Delfland) and with the city of Enschede (east Netherlands) and University of Twente
to familiarize them with the Waterproof application.
The project recently gained more traction with Waternet and are pushing actors for a better collaboration
but at the same times require a working production application before envisaging to implement it indifferent cities. We are currently working toward bridges that should simplify the integration with devices
to accelerate manufacturer on-boarding.
Table 6: Validation Results of Waterproof Amsterdam

Criterion
Transferability Feasibility

Unified interface

Domain Model

Requirements
Validation Result
WA-1, WA-2, WA-5, WA-11, WA- The services can be deployed12
in another city by simply
using a different
configuration. The only
problem is the LoRaWAN
network availability which
isn’t guaranteed (WA-12)
WA-1, WA-2, WA-11, WA-12
Services API are unified anddeployment is handled via
FogFlow.
WA-1, WA-2, WA-5, WA-11
Devices data pass through a
proxy or another service that
map the data to ngi10 or v2

3.1.1.2 Target Cities
The Waterproof Amsterdam application is applicable cities that must deal with intensifying volatility of
weather conditions due to climate change. Often, sewerage infrastructure capacity is dated from decades
back, and overhauling this infrastructure is mostly not an option due to heavy investments involved.
Therefore, we target cities that seek to implement novel and out-of-the-box solutions that can be built on
top of a city’s existing sewerage.
The following conditions need to be met for a city to be a target for the Waterproof application:•

CPaaS.io

The city SHOULD have a history of hindrance by rain water and acknowledge the drainage capacity
limitations potentially emerging with climate change.
Page 19 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability•

The city MUST have a policy or strategic priority in place to actively deal with rain water tocomplement the existing sewerage infrastructure.

•

The city SHOULD have someoin place that forces real estate developers to compensate for thenatural rain water drainage capacity they take away by their building structures. This regulation
could also be an incentivising one in the sense of availing subsidies for implementing innovative
water management solutions. in place that forces real estate developers to compensate for thenatural rain water drainage capacity they take away by their building structures. This regulation
could also be an incentivising one in the sense of availing subsidies for implementing innovative
water management solutions.

•

The city SHOULD be open to innovative, riskier solutions that may not have a track record of provensuccess.

•

The city MUST acknowledge the added value of centralised data collection and centralised control.

•

The city and stakeholders MUST work together to integrate the various components in the value
chain, such as hardware, applications and real estate.

•

There SHOULD be a wireless infrastructure that can be used to connect the smart rain buffers totransfer its data. This could for instance be a public LoRaWAN network provided by a municipality.

3.1.1.3 Required Transferability Support
The solution is based on micro-services that are packed into docker container and orchestrated by
FogFlow. Only a few configurations files are to be modified for the application to be transferred to anothercity. It is also preferable to have a hosting server close from the city it is responsible of.
Concerning security, the certificate and encryption key will have to be regenerated/updated to ensure
maximum safety and identification.
No data from a region are to be transferred to another for several reasons:
1. The application operates on one city only with one company.
2. Data collection policies apply. All country doesn’t have the same laws concerning security andpersonal information collection.
3. User only agreed to share their personal information with only one application & company.
Finally, the key for a successful transfer is the hardware support and availability. Connected water tankaren’t easy to install and most of the time will require an expert. Before transferring the application, one
should make sure there are people capable of selling, installing and maintaining the water tank in the city.
3.1.2 Yokosuka Emergency Medical Care
The Yokosuka Emergency Medical Care application provides two main functions. One function is video
transmission, which enables it possible for doctors in hospital to see patients’ images or monitors in realtime. The other function is ambulance location shared, which enables it possible for doctors to know
ambulances’ arrival time precisely.
These functions are city-agnostic but some cities have already installed other medical care systems. To
extend service area of this application requires regulation with fire bureau of target cities, nearby hospitals,
and installed systems in the cities.
CPaaS.io

Page 20 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

3.1.2.1 Transfer Activities
In April 2018, fire bureaus of Yokosuka City and Miura City, next to Yokosuka City, are joined and both
medical care systems are also integrated. Therefore, we expanded our Emergency Medical Care application
to Miura City and other nearby cities. In addition to that, we will introduce other cities visited for inspections.
Table 7 shows the brief summary of validation results. Please note that Unified Interface is in a sense
impossible due the regonal changes of laws and regulations concerning the handling of patients, etc.,
especially privacy handling. However, in the case of Miura city, the laws and regulations are basically
identical and thus the transfer of the existing Yokosuka application into Miura city was a very smooth
operation.
Table 7 Validation Results of Yokosuka Emergency Medical Care

Criterion
Transferability
Feasibility

Requirements
YEM-2, YEM-14

UnifiedInterfacen/aDomain models YEM-6, YEM-14

Validation Result
The technology part is transferable. What must be
taken into account is the difference of laws andregulations which differ in different jurisdictions.
This actually is more or less the application
requirement, and can be highly dependent on eachcity emergency medical care operator and thus
highly application-specific. The end users may
require totally different unified interfaces (!) The
underlying infrastructure is believed to support
such different user application interfaces.
The current data used in the Yokosuka emergency
medical care applications are believed to besatisfactory and transferable for this type of
applications.

3.1.2.2 Target Cities
Yokosuka Emergency Medical Care application has a hardware requirement that the ambulances havesome equipment to install camera(s). To operate this application, we should gain the cooperation of firebureau of target cities and nearby hospitals.
3.1.2.3 Required Transferability Support
In business or social point, regulation with city offices and nearby hospitals is required.
In technical point, adaptability of existing systems with regulation in target cities is required. Also scaling
support is required to cope with much bigger cities than Yokosuka (population is about 406,000.)
Yokosuka Emergency Medical Care application is developed on a cloud-based service, so scaling support
is realizable on cloud service technology. In Figure 2 the u2-based architecture of Yokosuka Emergency
Medical Care is shown. Unlike other use cases, this use case is really built on top of the smart city services
layer (application level) and uses only ucode Manager internally at this moment.
So the transferability from the viewpoint of CPaaS.io infrastructure is almost assured. The application in
Smart City Services needs only to address the legal and regulation differences (and possibly the privacy
policy differences) in target cities. Within Japan, the differences are not that large.
To expand this application to countries outside Japan, we should tackle laws and privacy policies of thesecountries.
CPaaS.io

Page 21 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

Figure 2 u2-based Architecture Diagram of Yokosuka Emergency Medical Care

3.1.3 Tokyo Management of Service Vehicle
The Tokyo management of Service Vehicle application provides a real time monitoring of delivery trucks.
It supports the package gathering/delivery operation in a metropolitan area. It provides plan, operation,and monitor of service vehicles and images of truck beds. It provides real time updates of delivery planand monitoring of vehicle positions on a map. It provides QR-code based driver registration on a smart
phone application at the driver side.
3.1.3.1 Transfer Activities and Validation Results
This use case starts real-world deployment in 2018. Therefore, it is still early to describe any concrete
transfer activities.
However, the application does not depend on any Tokyo-specific data infra-structure. When the maplicense is available, it is easy to transfer to other cities.
The use case itself contains coverage of wider area of metro-Tokyo area and covers other prefectures suchas Kanagawa, Chiba, Saitama, Gunma, and Tochigi prefectures. These areas fold 43 million population andmore than a third of total population of Japan.
There is a caveat that the fundamental transfer obstacles lie in its open data concept which potentiallyconflicts with interests of private companies.
In Tokyo metropolitan area, it is almost difficult to compose transportation-related open data smart city
infrastructure without positive consent of private companies.
Also, we found the challenges of deployment on new services on enterprise operating services. During the
deployment time, enterprises need a transition time during which existing and new delivery management
systems co-exist. This gives great pains to operation people and local ground-level workforces. This painis larger when there is a large workforce and when there is an established delivery management system.
CPaaS.io

Page 22 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

For camera-based object detection, we enhanced the truck bed capacity identification. We did a small
feasibility study with an electric operation management company (a subsidiary of a train company). It
shows some offline identification results for automatic detection of signals along railroads.
Table 8 shows the validated transferability results linked to the application requirements described in D2.7
Table 8: Validate Transferability Results for Tokyo Management of Service Vehicles

Criterion

Requirements

Transferability
Feasibility

TMS-3,
TMS-5, The services can be deployed in another city by simply using
TMS-11, TMS-12, a different configuration. The major obstacles are a) consent
TMS-18from private companies for open data, b) operation support
during the transition time.

Unified interface

TMS-3, TMS-11, Services API are unified with u2 architecture
TMS-12, TMS-18
TMS-3, TMS-11, This is not verified due to the lack of consent of open data
TMS-12, TMS-18
from the partner company. Only utility of closed use isverified.

Domain Model

Validation Result

3.1.3.2 Target Cities
The application can be used in many cities with private delivery services without real time monitoring. It
provides values from real time tracking for delivery operators and end users.
For B2B applications (for monitoring, maintenance, delivery and collecting), any cities with public
transportation companies can be possible targets.
The application can be used for any location-based periodical collection, delivery, monitoring, andmaintenance with photo evidence. So, it can be transferable to many enterprise operations which needlocation-based transactions (delivery, collection, check, monitor, replacement, et al.).
The target use cases of Tokyo Management of Service Vehicle could be non-Japanese specific, especiallyfor the B2B use part.
3.1.3.3 Required Transferability Support
Business: For on-going cloud-service support, commitment of ground level operation is needed, especiallyto introduce smart-phone based monitoring, maintenance, delivery and collecting services. In order tomaximize the delivered benefits, business intelligence to utilize gathered data is needed. The evidences ofbusiness merits are needed from earlier deployments.
Social: Social engagement to guide local private companies to share open data for social wellness isimportant. Privacy protection for technical infrastructure and operations should be ensured.
Technical: Mobile and cloud infrastructure and deployment/operational skills are needed.
Integration to local open data, wireless infrastructure is needed. Deployment and operational supports areneeded.
The local support both of UI and operation is needed.

CPaaS.io

Page 23 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

Sm art City Services Layer

Security &Privacy Pilar

Smart City Services

Know ledge Layer

Platform
Management,
Federation
andOperation
PillarSem antic Data & Integration Layerucode Manager
ucode RP

ucR Manager
ucR Query Protocol

Virtual Entity Layer

IoT Aggregator* Tunneling

IoT Data & Ingestion
LayerControl* Access

IoT Resource Layer
IoT-Engine(μT-Kernel
2.0)

Figure 3: Architect of Tokyo Management of Service Vehicles. Components used by the application are highlighted in red.

3.1.4 Smart Parking
This application is presented to the citizens as a web service or mobile app with the purpose of helping
her in finding a free parking place either in a private parking site or in the regulated parking zones (RPZ).
This way, its final goal is to reduce the amount of traffic and its corresponding pollution caused by vehicles
moving around the city looking for such a parking place. When the user uses this application, she indicatesher destination, and she will obtain a place with the estimated probability to find a free parking slot. The
application will also guide the user to the selected parking area. This application is also useful for thosecities which are promoting the use of the public transport service in the city centre. For these scenarios,
the application could also interact with the information obtained from the public transport service toprovide an intermodal solution where the user is advised to leave her car parked in the outskirts of the cityand use the public transport service to reach her destination.
Figure 4 illustrates the European CPaaS.io architecture where the interaction between all the components
is also described. In addition, the relevant components involved in this application are also highlighted.

CPaaS.io

Page 24 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

Figure 4: European CPaaS.io Architecture as used by the Smart Parking application. Components used by the application
are highlighted in red.

Following a bottom-up approach, firstly the concessionary companies responsible for private parking sites
management, as well as for the RPZ management, must publish their information about free parking slots,
and their expended tickets to a smart city platform using open interfaces. This information coming fromthe IoT Resource Layer is transmitted via IoTBroker to the Context Broker, which is the repository that the
Smart Parking application uses thanks to the FogFlow Framework. This way, the web services/app manages
the entities involved in the recommendation task performed by the Smart Parking application.
3.1.4.1 Transfer Activities
Since the development of this use case is still in an early state, it is still too soon to define concrete activities
regarding its transferability. Nevertheless, the goal of this application provides a way of dealing with acommon problem that medium/big-sized cities suffer which are the optimization of the resources of thecity; traffic congestion and pollution. For this reason, we have planned and envisioned the following
transfer activities which can serve as a minimum set of measures to succeed in the deployment of thisapplication in other cities:•

Promote different workshops related to the issue of Smart Cities where the issues of traffic andparking activities are also considered. As a matter of fact, the presence in events such as Smart City
World Congress, FIWARE Summit, Urban Intelligence is planned•

Establish commercial relation with other companies (NEC) to help and guide us in the distribution
and application of the solution into other cities.

•

Define a portfolio related to the traffic application, features, advantages and direct results.

CPaaS.io

Page 25 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

Table 9: Transferability Results

Criterion

Requirements

Validation Result

Transferability Feasibility

SP-1, SP-2, SP-3, SP-4, SP-5

We have developed a web service
that can be used by any city.
Nevertheless, the instantiation of
FogFlow framework is fundamental
step to obtain an efficientdevelopment

Unified Interface

SP-1, SP-2, SP-3, SP-4, SP-5

FogFlow management tool allowed
us to easily define the Edge andCloud tasks that must be
undertaken by the corresponding
processing nodes.

Domain models

SP-1, SP-2, SP-3, SP-4, SP-5

NGSI representation has been
agreed to represent both private
parking availability, as well as theprobability per sector of the RPZ.
In the same way, therecommendation result is also
based on NGSI.

3.1.4.2 Target Cities
In the last decades, there exists a global concern and care for the environment, which is also aligned withthe recent concept of Smart City and its main goal of optimizing the available resources improving thequality of living of its citizens. In this sense, traffic is tightly related to pollution, and this application
provides a possible solution to reduce the amount of vehicle wandering in search for a free parking slot.
For this reason, the possible target of this application is nearly each city suffering the common and wellknown traffic problems. Another advantage of this application is that the provision of information is notvery difficult to achieve since the involved third parties usually provide APIs to access the information
related to parking slots, as well as expended tickets.
Obviously, such APIs are a requirement to successfully deploy the Smart Parking application in the city.
3.1.4.3 Required Transferability Support
Regarding the requirements for transferring this solution we consider the following ones:•

At business level, the concessionary companies responsible for managing private parking sites andregulated parking zones should be able to export their data to any other platform. Usually, this is
the first obstacle to deal with, since the common contracts do not consider it.

•

At technical level and related to the previous requirement, the systems, platforms or software used
for such management must provide APIs to allow the integration of the information into otherplatforms.

CPaaS.io

Page 26 of 60

H2020 EUJ-02-2016

Deliverable D2.9•

Validation of Federation and Transferability

Since the application can be used anonymously, and no personal information is transferred, security
and privacy are not the main concern for this solution.

3.2 List of Criteria
For reference, we include in Table 10Table 15 below the list of federation criteria as described in D2.7
Criteria for validating federation and transferability results.
Table 10: List of Transferability Criteria

Criterion

Description

KPI

Transferability
Feasibility

Can the CPaaS.io
platform support thetransferability of
applications toanother city?

Easy orchestrationand deployment by
FogFlow
framework.
Developed newreal application forthe city of Murcia.

UnifiedInterface

Do the various
platform instances
provide the sameinterface so that no
adoption in theapplication is required
when transferring toanother city that is
running anotherplatform instance.
Are there generalapplication domain
models available into
which city specificdata sources can bemapped?

FogFlowmanagement tool
allows for an easy
deployment asproved by Smart
Awning as well as
Smart Parking

DomainmodelsCommonrepresentation forparking availability
information basedon NGSI.
Recommendation
also follows NGSI
representation.

Platform
Layer
IoT Data &Integration
Layer;
Platform
Management,
Federation
andOperation
PillarPlatform
Management,
Federation
andOperation
Pillar; Virtual
Entity Layer;
IoT Data &Integration
Layer
Virtual Entity
Layer, IoT
Data &
Integration
Layer

Requirements
SP-1, SP-2, SP-3, SP-4,
SP-5, TMS-3, TMS-18,
WA-1, WA-2,
FREQ.13, NFREQ.25,
YEM-2, YEM-14

SP-1, SP-2, SP-3, SP-4,
SP-5, WA-1, WA-2,
WA-11, NFREQ.25,
NFREQ.26, NFREQ.27,
FREQ.12, FREQ.13

SP-1, SP-2, SP-3, SP-4,
SP-5, WA-1, WA-2,
WA-11, FREQ.13,
YEM-6, YEM-14

4 Federation Results
In this section we provide the validation criteria related to federating CPaaS.io platform instances, inparticular a European and Japanese instance for cross-border smart city applications.

CPaaS.io

Page 27 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

4.1 Driving Applications
Here we describe the driving applications for the Federation Criteria. These applications are part of the
Event Management applications use case.
4.1.1 Enhanced User Experience
The Enhanced User Experience application is part of the European driven component of the event
management use case. In deliverable D2.7 we have described the on-going federation activities connectedto the My Events application. In deliverable D2.8 we have provided the third prototype release of theplatform providing an updated version of the My Events architecture. The major result presented in thissection consists of personal data from participants at the Sapporo Snow Festival 2018 collected in a joint
European/Japanese effort that has been integrated with data from the Color Run Utrecht 2016 using the
CPaaS.io semantic integration layer federating the European and Japanese platform on a semantic level. In
detail this includes:
1. A SPARQL federation service is used to achieve semantic integration between the European andJapanese platform instances accessing SPARQL endpoints on the respective platform instances
2. Raw Data collected from the Sapporo Snow Festival is exposed via a SPARQL endpoint as part of
the Japanese CPaaS.io instance
3. Event and deployment metadata, raw data form the Color Run Utrecht 2016 and analytics results
are hosted on the European platform instance and partially exposed via an SPARQL endpoint
In the following subsections we elaborate on these scenarios and describe current and planned federation
activities, target cities as well as the required federation support.
4.1.1.1 Validated Federation Results
The overall federation scenario is based on an extension of the My Events application with data collected
at the Sapporo Snow Festival 2018. The main challenge in federating the European and Japanese platform
instance is twofold
1) Federating personal data in different regions with different legal frameworks
2) Ensuring semantic interoperability between data coming from different events.
In the context of the My Events application we were assuming that participants that visit a Japanese event
such as the Sapporo Snow Festival should provide their data to the Japanese instance where it is primarily
hosted, stored and managed. This way it is possible to collect the data according to Japanese datacollection regulations. When actually collecting the data, YRP took care of that issue by obtaining thenecessary consent forms from the event participants.

CPaaS.io

Page 28 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

Figure 5: Federate European and Japanese CPaaS.io Architecture as used by the MyEvents application. Components usedby the application are highlighted in red.

In addition, the application needs access to both, data stored on the European instance, and data stored
in the Japanese instance. In order to enable such exchange of data AGT and YRP signed a data transfer
agreement that lays out the rules and principles for dealing with personal data across regional boundaries.
AGT and YRP went through the complete legal process, establishing the legal framework and thus legallyvalidating the feasibility of such a federation scenario.
Figure 5 shows the federated European and Japanese CPaaS.io instances as used by the MyEvents
application. Components used are highlighted in red. The non-federated use of CPaaS.io components has
been described in D2.6 Feedback and Validation Report. Here we briefly provide more details on the useof the security and semantic integration components.
Personal data requires adequate technical and operational measures that make sure that only authorized
persons get access to the data and that data is securely stored, e.g. by encrypting. Both attribute-levelauthorization and attribute level encryption are supported by the security components developed in WP5.
This is realized by sending the following NGSI update request to the IoTBroker using the CPaaS.io security
components:
POST /cpassSecurityComponent HTTP/1.1
Host: localhost:8087
Content-Type: application/json
Cache-Control: no-cache{"updateAction": "APPEND","contextElements": [{"entityId": {"id": "agtres:Jon","type": "foaf:Person","isPattern": false},"attributes": [{"name": "agtres:hasActivity",
CPaaS.io

Page 29 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability"type": "cyphertext","contextValue":"agtres:1ff84ed0-f59a-4bce-a703-fb91ddae202aWalking","metadata": [{"name": "cpabe-policy","type": "string","value": "Jon and admin"
}
]
}
]
}
]
}
In order to realize the semantic federation between the two platform instances we have used CostFed. The
MyEvents application is configured to use a the CostFed SPARQL endpoint as a single SPARQL endpoint.
CostFed transparently forwards the queries either to the Knowledge Server of the European CPaaS.io
instance (e.g. for retrieving aggregated Twitter sentiments) or the SPARQL endpoint provide by the ucRManager of the Japanese platform instance. Details about federating the semantic integration layers will
be provided in deliverable D6.4 Holistic Data Management – Refined Concepts and Models.
In summary we could validate that CPaaS.io provides the necessary federation capabilities as required by
the MyEvents application. Table 11 summarizes the relevant criteria and requirements as described in D2.5
Requirements Specification (V2) that also contains the full description of validation criteria.
Table 11: Validated Federation Criteria linked to the application requirements

Criterion
Consistent data
operations
Federation Feasibility
Exchange of personal
information

Effort for linking data
between several
platform instances

Requirement
EUE-11, EUE-13

Validation Result
By using CostFed data can be accessed
uniformly across platform instances.
EUE-11, EUE-13
CostFed has been used and integrated
into the My Events application.
EUE-11, EUE-13, EUE- The exchange of personal data has been
3
validated by using the CPaaS.io security
components that are used by the
MyEvents application.
EUE-11, EUE-13
The effort is minimal: each instancedecides which data to expose via a
SPARQL endpoint and CostFed isconfigured with the endpoints. As a result
the platform instances do not need to beaware of each other.

4.1.1.2 Target Cities
As described in D2.7 Criteria for validating federation and transferability any city or even village arepotential target cities as each community is typically hosting at least small events in which the public canbe actively involved. The main increments since D2.7 is that we have been using My Events in Sapporo andused the CPaaS.io federation capabilities.

CPaaS.io

Page 30 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

4.1.2 Sapporo Visitor Experience
We are planning to add features to Sapporo visitor experience, which include digital signage with IC card
authentication. The service is developed using Omotenashi Cloud service and its architecture is also basedon CPaaS.io.
Figure 6 shows the u2-based Architecture Diagram for Sapporo Visitor Experience. The components
marked with red border are used by the Sapporo Visitor Experience. Omotenashi Cloud service is in theright hand component.

Figure 6 u2-based Architecture Diagram for Sapporo Visitor Experience

4.1.2.1 Validated Federation Results / Federation Activities
Omotenashi Cloud is also providing services to other tourist information application services in othergeographical areas. Omotenashi cloud is a common platform service that includes open data information
service, especially PDS (Personal Data Store) and ID management (authentication, etc.) that can use very
popular IC card systems in Japan. The PDS and ID management will be used by many applications including
the tourism service as in Sapporo Visitor Experience, but many types of services in other geographicalareas, too.
Despite the considerations paid during design and implementation stages of Sapporo Visitor Experiencefor federation, and the cooperation from the office of the city of Sapporo and local business communities,
the full-blown Sapporo Visitor Experience is yet to be federated with other full blown u2-based instancesin other cities. This is because no large scale full-blown u2-based CPaaS.io implementation at the scale of
Sapporo Visitor Experience is in other cities yet. This is simply a matter of finding a willing city andpersuading the city and is not a technical issue, but rather that of a business and political issue.
CPaaS.io

Page 31 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

However, do note that a smaller scale implementations based on kokosil have sprung up all over Japan (itcounts 40+ as of October 2018 and the number is growing. And the following best guess evaluation isbased on the experience of kokosil deployment.
Since AGT’s Enhanced User Experience in 4.1.1 deals with the federation example of FIWARE-based
CPaaS.io instance and u2-based instance (4.1.12), here we focus on the potential validation result of
possible federation between two u2-based instances in Japan. The evaluation is based on best educational
guesses.
The interaction between the user in one city and a u2-based CPaaS.io instance in other city will be handled
either by through the application layer as shown in the smart city services layer in the top-most part of the
figure or through kokosil location information component below it.
It is noted that small implementations based on kokosil to offer tourism information has grown in numbers.
As an example, in Figure 7, the arrows are the interaction of users of two instances that go through kokosil
components of each instance. The arrow shows only the access from the user of the instance on the left.
But due to symmetry, the access from the instance on the right will be very similar. Such federation using
kokosil as the top-layer interface has been in place for sometime already. The access to kokosil component
in the other instance will be based on open API of kokosil via TCP/IP network path.

User

Figure 7 Federation of two (2) u2-based instances as used by Sapporo Visitor Experience applications(s)We still need to validate this federation scenario in the future when a city such as one in greater Tokyo
metropolitan area, in Hokkaido or in Kochi prefecture steps forward and shows its willingness to build afull-blown u2-based Visitor Experience application (of the scale of Sapporo Visitor Experience) there.

Table 12 Best Educated Guess of Federation Criteria linked to the application requirements between two u2-based
instances

Criterion
Consistent data
operations

CPaaS.io

Requirement
SVE-11, SVE-13

Validation Result
Since the underlying data domain andvocabulary is the same between two u2based CPaaS.io infrastructure, theconsistent data operations across two
Page 32 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Federation Feasibility

Exchange of personal
information

Effort for linking data
between several
platform instances

Validation of Federation and Transferability

instances shall be possible as long as the
database therein in each instance iscomplete.
SVE-11, SVE-13
We do not need a full-blown feature suchas CostFed between two u2-basd
instances in Japan.
SVE-3, SVE-11, SVE- The exchange of personal data between
13
two u2-based in Japan should bepossible. This is handled by OpaaS.io
component. There is a national privacy
policy in Japan and OpaaS.io can
implement the policy acccording to sucha nation-induced policy.
SVE-11, SVE-13
The effort to link data managed by two
u2-based instances is smaller than theeffort to link the data between one
FIWARE-based instance in EU and one
u2-based instance in Japan. It should bealmost nil: each instance decides whichdata to expose via a SPARQL endpoint.
Because of the differences of thecomplete set of data available at each u2based instance, some kind of wrapper
may be necessary, but full-blown
CostFed-like function will not be requiredin this case. As a result the platform
instances do not need to be aware ofeach other.

4.1.2.2 Target Cities
Generally speaking the type of tourism service, a major component of Sapporo Visitor Experience can beextended to many other cities. The service can be extended to:•

any cities that have active tourism industry, nice tourist spots that sustain the visitor activity all theyear around, and preferably a big annual event and additionally many smaller events. The maintenancecost of permanent installations of signage and such requires enough number of visitors spread overmany months, and the maintenance/upgrade/update cost of the backend software system favours
cities that use such software years every so often.

As for the tourism support, we need to mention rather mundane but very important feature that the cities
need to have:•a strong commitment or leadership of the regional government to use such ICT-based tourism support.

This is because the mere act of installing signage in populated areas along the road (most often under
government's jurisdiction), and stations (quite likely to be under the management of local public
transportation operators) would require the cooperation of regional government offices and public bodies
such as transportation operators).

CPaaS.io

Page 33 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

Without such commitment of the regional/local government offices, sooner or later, the efforts tointroduce such service would hit a dead end. CPaaS.io has been lucky to have the strong support of themayor of the city of Sapporo and the local business communities so far.
As a concrete target for the next federation targets, the digital signage service will be expected to be
deployed to other cities by Olympic/Paralympic 2020. Chiba City and its 3rd sector company (jointly createdby the city office and private sector) which manage “Makuhari Messe”, a large convention facility in Chiba
City, wants to use the digital signage system that used open data and cloud service in an effective way.
Chiba city is the capitol city of Chiba prefecture immediately next to Tokyo. Makuhari Messe, one of thelargest convention centers in Japan boasts many large events throughout the year and attract many visitor.
With the commitment from city office, this activity fits the conditions of the criteria mentioned above. The
envisioned service includes the following.
••••

Installation of several digital signages around “Makuhari Messe”
Provision of the content that supports domestic/international visitors using Kokosil service.
Switching used languages on digital signages will use the preferred language of the visitor, apersonal data obtained after IC card authentication
The personal data including the preferred language, food preference, etc. will be managed on
Personal Data Store (PDS) on Omotenashi Cloud

The above expectation expressed in earlier draft seems premature. The administration of activities related
to Olympic and Paralympic Games in 2020 is closely guarded by the Tokyo Olympic Committee andpartners of CPaaS.io and, for that matter, even the governor of Tokyo has little say about what thecommittee is going to do. It is a political matter and thus the progress of federation activity is unlikely tohappen in Tokyo area for 2020 games unfortunately. However, Tokyo government and many cities ingreater Tokyo metropolitan area is interested in promoting the local environment for the quality of living,business, etc. aside from the aspect of 2020 games, so there is still a chance of seeing an instance near
Tokyo area AFTER 2020.
4.1.2.3 Required Federation Support
CPaaS is the architecture and Omotenashi Cloud is in service phase. So there are still gaps for actual social
service. In that sense, Chiba City case will be the stage of PoC (Proof of Concept).
In business aspect, business model should still consider who must pay the maintenance and operational
cost: city government or servicer who provides content for tourists?
From the technical point of view, PDS must secure personal data in the cloud. So we need to establish
security management on Omotenashi Cloud by including personal data protection as one of the key
features. This feature has to use the popular IC cards used in Japan for the wide acceptance. But please
note that it does not necessarily mean that the Omotenashi could uses the card service providers’ software
backend, but it is planned that the basic hardware characteristics of the IC cards, such as their uniquehardware IDs embedded in the individual IC chip is used to identify each user anonymously.

4.2 Technical Federation Scenarios
In this section, we present three federated scenarios which we have selected with the purpose of illustrating
the interaction between both European and Japanese architectures. Specifically, we have selected Smart
Building and Personal Data Management with the objective of covering a wide range of federations,considering security and privacy aspects too.

CPaaS.io

Page 34 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

Before going into details for these federation scenarios, we present two figures that provide a hierarchicalview of the different component comprising each architecture, as well as their relationships. We will use
them later on in the following subsections to explain the performance of the federation at different levels.
Figure 8 shows the European architecture which is divided into the following layers:
•
•
•
•
•
•
•
•

IoT Resource Layer, where the different sources of information transmit their data.
IoT Data & Integration Layer, where IoTBroker receives the information from the different sources of
information.
Virtual Entity Layer, where we process and represent the information in a more abstract andrepresentative way.
Semantic Data & Integration Layer, where we enrich the information coming from the lower layer byusing semantic representation.
Knowledge Layer, whose components provide a SPARQL interface for querying the stored information.
SMART CITY Services Layer, which represents the services and application consuming the information
at the user level.
Platform Management, Federation Operation Pillar, where we have considered FogFlow anddeployment tools.
Security & Privacy Pillar, which provides the required components for applying security and privacy tothe information stored in the platform.

CPaaS.io

Page 35 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

SMART CITY Services Layer

SPARQL App
Developer

FIWARE App
Developer

Security &Privacy Pillar

IdM API

KeyRock

Knowledge Layer
SPARQLKAT Toolkit

Platform
Management ,Federation andOperation
Pillar

XACML
XACML

Semantic Data &Integration Layer

IoT Knowledge
Server
Deployment
Tool

NGSI to RDF
mapper

STH Comet
NGSI10KnowledgeServer API

Capability
API

NGSI10NGSI9NGSI10

PEP-Proxy

Virtual Entity Layer

FogFlowNGSI9

IoT Discovery

Capability
ManagerContext Broker

NGSI9

Encryption
API
NGSI10NGSI10CP-ABE

IoT Data &Ingestion Layer
NGSI10IoT Broker
NGSI10SPARQL

Existing components
New/enhanced
components

IoT Resource Layer

SPARQL
Agent
Device API

IoT Agent

LoRaWAN to NGSI
bridgeDevice

LoRa Device

Figure 8: Fiware-based European Architecture

On the other hand, Figure 9 depicts the u2-based Japanese architecture with the appropriate matching to
the same layers described in the European architecture which are enumerated next:
•
•
•
•
•
•
•

CPaaS.io

IoT Resource Layer, considering sources of information such as LPWAN, BLE, NFC or QR
IoT Data & Integration Layer and Virtual Entity Layer, highlighting the Open Data Distribution
Platform and the IoT Aggregator component.
Semantic Data & Integration Layer where ucode and ucR Manager are presented.
Knowledge Layer, providing the u2 Open Data Catalogue, the IoT Translation Engine and Kokosil.
Smart City Services Layer, which following the same approach as in the European side, involves theuser-level applications consuming the information of the platform.
Platform Management, Federation and Operation Pillar, managed by the LightWeight Device
Manager.
Security & Privacy Pillar, containing the eTRON Security Architecture as well as the Personal DataStore.

Page 36 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

Security &Privacy Pilar

Smart City Services Layer
Smart City Services

Knowledge Layer
u2 Open Data
Catalog

IoT Translation
EngineKokosilucR Query Protocol

OPaaS.io

ucR Manager

ucode RP

Virtual Entity Layer

LightWeight
DeviceManager* Personal Data Store

Semantic Data & Integration Layerucode Manager

eTRON Security ArchitectureeTP (Entity Transfer Protocol)
eTRON Tags

Platform
Management,
Federation andOperation Pillar

Open Data
IoT Aggregator
Distribution* Tunneling
IoT
Data
&
Ingestion
Layer Control* Access
Platform

IoT Resource Layer
IoT-Engine(μT-Kernel 2.0)

LPWA
Nodes

ucode
BLE

ucode
NFC

ucode
QR

Figure 9: u2-based Japanese architecture

Once that we have explained the layers and components comprising each platform, in the next sections
we proceed to describe each of the proposed federation scenarios.
4.2.1 Smart Building Sensor Integration
The Smart Building use case is a worth considering scenario within the Smart City scope were energy
consumption and other measurements such as temperature and humidity are monitored as a first step toprovide an intelligent energy management service. For this reason, we have worked on integrating thesensors coming from these sorts of facilities to our CPaaS.io platform allowing users to access thisinformation regardless of their origin.
Since partners from both sides of this project (EU and Japan) own smart infrastructures which are being
monitored, a federation of this information became interesting for the purpose of this project. This
integration has also been enriched with the use of Dashboards which allow the user to perceive thisinformation of both EU and Japan platform in a graphical view.
In the following subsections we elaborate on this scenario and describe current and planned federation
activities, target cities as well as the required federation support.
4.2.1.1 Validated Federation Results
Figure 10 presents the well-known EU-JPN CPaaS.IO federated architecture. We have highlighted thecomponents involved in this federation scenario.
The cornerstone components of this federation are the connectors responsible for exchanging information
between both platforms thanks to them the information is located in a distributed manner between both
platforms. This way, by using the exposed API provided by the European and the Japanese services, a user
can access the information that is now synchronized between both platforms. Additionally, specific
CPaaS.io

Page 37 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

applications or services such as dashboards can be developed over this common platform thanks to ahomogeneous API presenting an integrated view of the data.

Figure 10: Federate European and Japanese CPaaS.io Architecture as used by Smart Building Sensor Integration scenario

In the following figures we present both EU-JPN dashboards providing the integrated and synchronized
between both platforms.

Figure 11: Integrated information presented in the EU dashboard

CPaaS.io

Page 38 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

Figure 12: JPN Dashboard

This integration has been successfully achieved because of the exposed APIs by the different sides which
are detailed in the following paragraphs:
Japanese platform API
1. Retrieving data for each sensor/api/<ucode>/sensorstate/
Exampletoretrievethetemperature
0x00001C00000000000002000000063433.

sensor

data

whose

ucode

is

% curl http://133.11.240.193/api/00001C00000000000002000000063433/sensorstate/
2. Retrieving All sensor data
/api/ALL/sensorstate/
Example to retrieve all sensor data in our intelligent building% curl http://133.11.240.193/api/ALL/sensorstate/
Japanese platform data model
Regarding the representation of the information, the data is formatted using a JSON document as
described next.
{"ucode": <ucode>, # ID of the sensor"name": <Sensor Name>, # Name the sensor"type": "temperature", # Sensor type = "temperature""category": "temp_sensor",# Sensor category = "temp_sensor""value": <value>,# Value of the sensor (degree in celcius)
CPaaS.io

Page 39 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability"timestamp": <time stamp># time stamp}
Example:{"ucode": "00001C00000000000002000000063433","name": "TempRoomA301","type": "temperature","category": "temp_sensor","value": "29.650002","timestamp": "2018-08-07 18:24:34"}
European platform API
Since the European platform is based on the use of the NGSI API, so it exposes a homogeneous andunified method to query all the information stored in it.
1. Get All Entities
GET http://155.54.210.177:1026/v2/entities
2. Query Context by TypeGET http://155.54.210.177:1026/v2/entities&type=TemperatureSensor
GET http://155.54.210.177:1026/v2/entities&type=HumiditySensor
3. Query Context Operation
POST http://155.54.236.10/NGSI/v1/queryContext
European platform data model
The representation provided by the European and Fiware-based platform uses the NGSI representation
which employs a JSON document as the following one.
{"entities": [{"type": "TemperatureSensor","isPattern": "false","id": "335544563:Sensor temperatura sala 3.11"},{"type": "HumiditySensor","isPattern": "false","id": "335546943:Sonda humedad exterior estación meteorológica"}]}

CPaaS.io

Page 40 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

Table 13 lists the validation results of the Smart Building Scenario. As the this a scenario has been added
later as purely technical demonstration scenario, there are no requirements to which the validation results
are linked.
Table 13: Validated Federation Criteria for Smart Building Sensor Integration

Criterion

Validation Result

Federation Feasibility

The federation of this use case is feasible byexchanging the information coming from thesensors installed on smart buildings between EU
and Japan platforms. Thanks to this, theinformation can be requested regardless theirlocation by using the corresponding API for any
platform.
The effort needed to link data between platform
instances depends uniquely on the API exposed bythem. NGSI guarantees a seamless integration
with little effort. On the other hand, this link also
depends on the other end.
Although for this specific use case we have notmade scalability tests yet, the Context Broker coremodule has been designed for handling hugeamount of data with simultaneous access by users.
So, scalability is granted in these terms.

Effort for linking data between
several platform instances

Scalability

4.2.1.2 Target Cities
Although this scenario was not presented in D2.7 Criteria for validating federation and transferability, anycity or even village are potential target cities. In the scope of this project the involved cities were Murcia
and Tokyo.
4.2.2 Personal Data Store Integration
So far, users do not have tools to handle their personal information. In fact, online services and applications
are the ones that provide the terms and conditions that the user must accept so as to use them with two
negative consequences from the user point of view: The user loses the control of the personal data thathas been registered in these services and they are usually not provided with a mechanism to revoke theaccess of such personal data by these services. This is actually, the motivation of this federation scenario
where thanks to the use of a Personal Data Store (PDS) with its corresponding application the users are
empowered to manage their personal data commercialization and distribution by online services.
In the following paragraphs we detail this federated scenario specifying also the different security
mechanisms that are used to provide security and privacy.
4.2.2.1 Validated Federation Results
This use case makes use of the highlighted security components provided by both platforms such as
KeyRock for the authentication; XACML, Capability Manager for the authorization, and CP-ABE for privacy
considerations from the EU-side, as well as OpenId Connect for the integration between EU-JP PDS which
are presented in Figure 13 allowing the JP-PDS to obtain the personal data stored in the EU-PDS. On theother hand, the Japanese u2-based platforms rely on eTRON Security Architecture as well as Omotenashi
PDS (OPaaS.io).

CPaaS.io

Page 41 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

Figure 13: Security components interaction between platforms

Within the framework of this scenario, this consortium has addressed the problem of personal data
distribution from the perspective of the user. To do so, a PDS is provided to give its users the tools todecide which personal information is distributed through the different online services and platformworldwide available.
Focusing on the use case description, a user whose data has been stored in a PDS from EU travels to Japan
as presented in Figure 14. After accessing to U-Tokyo, the user specifies to get her personal data to the
PDS from Japan. So, as described in step 3.1 and 3.2, it requests this data which is transferred by using
Open Id Connect. This way, now the user is able to handle her personal data and give consent to thespecific online services which wants to handle her personal information.

CPaaS.io

Page 42 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

Figure 14: PDS integration

In the following paragraphs, we present an application of this use case where the content which ispresented to the user uses the most appropriate language according to her personal data. Following thediagram presented in
Figure 14, in the PDS from EU side the user specifies her preferences with regards to data exportation
allowing other PDS to obtain her information. This way, when the user arrives in Tokyo, she uses the PDS
at the destination which contacts the PDS at origin (EU PDS) and requests her personal data.

Figure 15: Validation form

After validating the operation by inserting her credentials into the web form shown in Figure 15, theOmotenashi PDS obtains the personal data, and presents the information in her native or preferredlanguage (Spanish) as displayed in the following figure.
CPaaS.io

Page 43 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

Figure 16: PDS integration application

Finally, Figure 17 presents the security properties employed during the exchange of personal information
between both PDS.

Figure 17: Security and privacy properties required for the exchange of personal information

Firstly, the user defines in the EU-PDS her policies regarding the exchange of her personal data with other
PDS by specifying the attributes of her personal data to be exchanged in case a request for her data isreceived.

CPaaS.io

Page 44 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

Now, the user moves to Japan and uses the JPN-PDS, so it asks for permission to obtain her personal datafrom the EU-PDS. Open ID Connect technology provides the secure protocol for the interaction between
PDS. So, the JPN-PDS issues a request to the EU-PDS for obtaining the information of the user. Such
request is handled actively by her who must interactively give permission by introducing her credentials in
the presented form. This whole process integrates the authentication and authorization mechanisms
defined for the EU-PDS which also take place for allowing the JPN-PDS to access the information.
Table 14 lists the validation results of the Personal Data Storage Integration. As the this a scenario has
been added later as purely technical demonstration scenario, there are no requirements to which thevalidation results are linked.
Table 14: Validated Federation Criteria for Personal Data Storage Integration

Criterion

ResultConsistent
operations

data Both PDS from EU and Japan are based on the same corefunctionalities and APIs. Both support the Open ID Connect
framework.
Federation Feasibility
By developing a PDS based on the same API, federation is feasible.
Exchange of personal Thanks to the API the information exchange is secured, granting a
information
successfully experience for the user.
4.2.2.2 Target Cities
Although this scenario was not presented in D2.7 Criteria for validating federation and transferability, anycity or even village are potential target cities. In the scope of this project the involved cities were Murcia
and Tokyo.

4.3 List of Criteria
For reference, we include in Table 15 below the list of federation criteria as described in D2.7 Criteria forvalidating federation and transferability results.
Table 15: List of Federation Criteria

Criterion
Consistentdata
operations

Description
Is there a unified accessmethod acrossplatform instances ?

KPIPrototype of thesemantic integration
layer that can be used
to federated platform
instances

Platform Layer
Semantic
Integration Layer

Federation
Feasibility

Can the CPaaS.io
instances be federated
to enable theimplementation of across-regional
application withAt least one
implemented
application that relies
on federated platform
instances

Semantic
Integration Layer

CPaaS.io

Page 45 of 60

Requirements
EUE-11, EUE13
SVE-11, SVE13
NFREQ.25,
NFREQ.26,
NFREQ.27,
NFREQ.29,
FREQ.12,
FREQ.13,
FREQ.14
EUE-11, EUE13
SVE-11, SVE13
NFREQ.25,
NFREQ.26,
H2020 EUJ-02-2016

Deliverable D2.9

Exchange of
personal
information

Effort forlinking data
betweenseveralplatform
instances

Validation of Federation and Transferability

validated businessvalue
Can the CPaas.io
platform be used to
exchange personal
information between
Europe and Japantaking respective
regulations into
account

What is the effort tolink data managed by
the European andJapanese instance?

A prototype thatshows the exchange of
personal information
and an explanation
how platform
components support
the exchange of
personal information

Semantic
Integration Layer,
Security andPrivacy Pillar

Demonstrate anapplication prototype
that uses the samedata operations acrossplatform instances sothat the application is
not aware which
platform instanceactually manages thedata

Semantic
Integration Layer

NFREQ.27,
NFREQ.29
EUE-11, EUE13, EUE-3,
SVE-11, SVE13, SVE-3
NFREQ.12,
NFREQ.13,
NFREQ.16,
NFREQ.17,
NFREQ.20,
NFREQ.22,
FREQ.23,

EUE-11, EUE13
SVE-11, SVE13
NFREQ.25,
NFREQ.27,
NFREQ.29,
FREQ.12,
FREQ.13,
FREQ.145 Blueprints
To date, there is no common process or even a recommendation for developing a smart city project beyond
the trinity data – platform – smart applications. Often, the wheel is re-invented instead of trying totransform and adapt use cases and applications successfully deployed elsewhere, and thus profiting fromknowledge and experience gained.
Here we propose a blueprint process and a template covering technical and organizational aspects. It is aholistic approach along the value chain of smart city applications.
Since every city has specific characteristics and context, smart city applications are not transferable toothers without adaption to its context. Given a blueprint template at hand for smart city applications would
well support the adaption of smart city applications. The template can guide through the problem-solving
cycle and assist in the abstraction and concretizing process of a smart city application and with that help
in the adaption process.
The blueprint template covers important categories along the value chain 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.
CPaaS.io

Page 46 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

5.1 Value Chain of Smart City Applications
In business, the concept of a value chain is commonly used. Porter defined 5 primary activities of acompany that lead to profit: sourcing logistics, production, distribution logistics, marketing & sales, andcustomer services (Porter 2014). In addition, he defined the following supporting activities: infrastructure,human resources, technology development, and procurement. A city however is not a company and has
different goals: While a company's primary goal is to increase profits, a city should strive to create public
value. Introduced by Moore, the concept of public value describes the value an entity contributes to society,e.g., increasing the quality of life for its population, supporting transparency and democratic processes, orother useful services a city may provide to residents or enterprises (Moore & Khagram, 2004). Such services
are especially important where market mechanisms alone are not providing the desired service levels, likein health care or public transportation (Neuroni et al. 2019).
So how could a value chain for a Smart City be defined? The base currency for a Smart City is data: data
leads to information and insights, and thus to new services and better and faster management of city
processes. Laaboudi and D'Ouezzan postulate that the value chain of a Smart City consists of the following
elements (Laaboudi & D'Ouezzan 2016):
•
•
•
•

•
•

Data Collection: Data collection from a wide range of devices such as mobile devices, sensors, home
applications, vehicles or data from 3rd party applications via interfaces.
Data Carriage: Network technologies like fiber, wireless, telecommunication infrastructure or LowPower Wide-Area Network LPWAN or other connectivity components to transfer the collected data.
Data Storage: Data centers, cloud or other storage capabilities to store the collected data.
Data Analytics: The heart of the value chain that brings smartness into a Smart City application.
Dedicated platforms are used for standardization, communication of information and transforming
data into linked data with semantic context.
Data Marketplace: Exposing data, authenticating users, authorizing access as well as a possible
billing or booking capabilities. The marketplace is a central element to open data strategies for cities.
Application Layer: The application layer is dedicated to creating, developing and improving a Smart
City application. It represents the tools and services, as well as APIs for the city and the users.

All these elements need to be considered when creating a Smart City application generating public value.
However, not every element may be essential for value creation in every Smart City application, some
applications only address one, but usually most, elements of the Smart City Value chain.
Regarding supporting activities, we have identified the following: sourcing of vendors, governance & risk
management, data protection & security, as well as financing. Thus, we can adapt the model of Porter asshown in Figure 18:

CPaaS.io

Page 47 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

Figure 18: Smart City Value Chain (adapted from Porter 2014 and Laaboudi & D'Ouezzan 2016)

Sustainable and optimal development of a Smart City application is based on a city’s business vision withfocus on public value, a network of organized actors, a set of codes and technologies and values thatgoverns all stakeholders. In this sense, governance is needed around a common vision for thetransformation of cities.

5.2 Structure of the Smart City Blue Print Template
The Smart City Blue Print template consists of four parts which – as is shown in – relate to the four typical
phases of most projects (cf. Jenny 2014) plus a "One-Pager" giving a summary and overview of the blue
print and its use case. In the following, we will describe these parts in more detail.

Figure 19: Structure of Smart City Blue Print and relationship to project phases

CPaaS.io

Page 48 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

5.2.1 Smart City Application White Paper
The Business Model Canvas defined by Osterwalder and Pigeur (Osterwalder & Pigeur 2013) is a wellrecognized tool in the business world for the creation of innovations and the associated development of
new business fields. However, as we have discussed above, a city is not a business, but its main focus is increating public value. Hence the Business Model Canvas needs to be adapted for Smart City applications.
The result of this adaptation is shown in .

Figure 20: Smart City Canvas

Let's describe the 8 elements in the suggested – but not mandatory – order in which they should be filledout.
1. Beneficiaries: According to Osterwalder (Osterwalder, Pigneur 2011, 25ff.), customers form theheart of every business model. Since public value plays a decisive role in smart city applications,rather than the customer, it is important to find out who are the biggest beneficiaries of an
application.
• For whom or what do we create value?
• Who benefits most from this Smart City application?
• Which public services are being expanded and optimised?
2. Public Value Proposition: Describes the public value delivered, the type of value, and the packageof products and services generating the value.
• What kind of urban problem is being solved?
• What public needs are met by application?
• Which areas of the public sector are affected? E.g., energy supply, mobility, water supply,
public services, public buildings etc.
3. Relationships: Describes the type of relationship that the public sector can expect. It is aboutfinding out who supports the Smart City application and who doesn't. Furthermore, it defines how
the different stakeholders are managed.
• Who are the supporters of the initiative and who are the opponents?
• How to deal with different parties? Are certain groups like NGOs involved?
4. Revenue Streams / Saving Potential: Describes any revenue streams for the city, and savings thatthe public sector can achieve with this Smart City application. These are important as they canprovide the financial justification for implementing or deploying this application.
CPaaS.io

Page 49 of 60

H2020 EUJ-02-2016

Deliverable D2.9

5.

6.

7.

8.

Validation of Federation and Transferability• How are the expenses for the Smart City application justified?
• Where is the potential for saving public expenditure?
Key Resources: Describes the most important business assets that are necessary for the functioningof the Smart City application.
• What physical, intellectual, human and technical resources are needed to achieve the goal?
Key Activities: Represents the activities that a city must carry out to ensure that the Smart City
application the targeted public value. Activities could include activities regarding development,
deployment and operation of the application and needed platforms and networks, communciation
activities towards citizens and/or citizen participation, etc.
• What key activities are required for delivering the public value?
Key Partnerships: Describes the network of suppliers and partners that contribute to the successof the application. Reducing risks and uncertainties as well as acquiring certain resources andactivities are of central importance.
• Who are the key partners?
• Who are the key suppliers?
• Which key activities are taken over by third suppliers?
Cost Structure: Describes all costs incurred in the creation and operation of the Smart City
application.
• What are the most important costs?
• What are the most expensive key resources?
• What are the most expensive key activities?

This Smart City Canvas is central piece and starting point of the Smart City Application White Paper. In
addition to the canvas, the white paper should provide an overview of services, standards and technology,
especially on IT topics. This includes user descriptions, case studies and market research results.
5.2.2 Requirements Specification
The following specification guidelines are based on the IREB Standard according to Pohl (Pohl 2008). This
standard includes a toolset of different methodologies for the management of requirements. Further
assistance can be found in the literature of Pohl.
The requirement specification should begin with the description of the planned system and thus describe
an introduction or an overview of the application to be created. According to Pohl, it should be ensured
that the system boundary and the system context are defined before the requirements are collected. Thisis relevant for the definition and understanding of the requirements of the system under consideration
To structure the requirements catalogue in a uniform and retrievable manner, we categorize these
according to the elements in the value chain of Smart City applications. Such a split is also helpful whendeveloping the application, as each part may possibly be developed as a separate component. As a firststep, it is thus advisable to identify which elements of the value chain are affected and play an importantrole in the application at hand. Table 16 provides a simple tool for such analysis. It also lists some questions
to help elicit requirements, and gives a sentence template how to formulate the requirements. Sentence
templates are an easy-to-learn and easy-to-use approach to reduce linguistic effects (Pohl 2008) – animportant issue in multi-stakeholder projects as Smart City applications typically are – and are also
commonly used in agile approaches like SCRUM.

CPaaS.io

Page 50 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

Table 16: Checklist to determine the application requirements according to the Smart City value chain

Value Chain
Element

Element
affected?

Questions to ask about the application
Is the planned application dependent on collecting data?
What types of data are required to implement the Smart City application? Where,
how (e.g., sensors) and by whom (e.g., 3rd parties) is the data collected?

Data
Collection

Sentence template:
The systemmustsensorsshould collect data from 3rd party applicationcan<<other source>>about

temperatureschedule<<other topic>>yes

Is the transfer of data needed for the application?
All functional and non-functional requirements related to data transmission.
Data
Carriage

Sentence template:
The data

yes

must
LPWAN
should be transferred via WLAN
tocan<<other technology>><<target>>Is persistent storage of data relevant to the application?
How is the data stored? How sensitive is the data? How fast must the data be
retrievable? Does the data have to be stored in a certain form? Which semantic
standards or guidelines must be observed?
Data
Storage

yes

Sentence template:
The data

mustshould be stored <<where>>can<<form>>to<<purpose>>

Does the application require the data to be analyzed in order to provide value?
How must data be aggregated? Which data is relevant for the analysis? What does
the data curation processes look like?
Data
Analytics

Sentence template:
The data

must
find out
should be analyzed to recordcan<<other verb>>

yes
for

<<purpose>>

Is it intended to sell data?
Who should have access to the collected data? How is the operator of theapplication remunerated for providing the information? What are the price models
and payment modalities?
Data
marketplace

CPaaS.io

yes

Sentence template:must
The marketplace shouldcanprovide <<what>> toPage 51 of 60<<whom>> under <<condition>>

H2020 EUJ-02-2016

Deliverable D2.9

Value Chain
Element

Validation of Federation and Transferability

Element
affected?

Questions to ask about the application
Is an interface / API necessary to provide another application with information?
Which interfaces are required? Are actuators required for the application? Is a userinterface provided? What actions are users or actuators performing?

Application
Layer

Sentence template: (-)
As the types of requirements here can be very different and are very applicationspecific, the use of a single sentence template makes no sense. Rather it is important
to collect requirements from the user's perspective and, if actuators are required forthe application, to record under which conditions they have to react and which
actions are to be carried out.

yes

A similar table can also be used for the supporting activities in , as shown below:Figure 14, as shown below:
Table 17: Requirements relating to supporting activities

Supporting
Activity
Sourcing

Element
affected?

Requirements
Requirements for potential providers of key activities and/or resources,
and possibly also a shortlist of providers eligible. Legal aspects (e.g.,
WTO rules) need to be taken into account.

yes

The requirements should indicate the GRC (Governance, Risk andCompliance) standards to which the Smart City application must adhere:
Governance
The governance process within an organization includes elements suchas definition and communication of corporate control, key policies,
enterprise risk management, regulatory and compliance management
and oversight and evaluating business performance through balanced
scorecards, risk scorecards and operational dashboards. A governanceprocess integrates all these elements into a coherent process to drive
corporate governance
Governance&Risk Mgmt.

Risk
Operators of smart city platforms should strive to systematically identify,
measure, prioritize and respond to all types of risks and to manage therisks accordingly. A risk management process offers a strategicorientation with a formal process for identifying, measuring andcontrolling risks. Requirements for risk minimisation should be
mentioned in this area.

yesCompliance
As the public sector faces multiple regulations at the same time, astreamlined process for managing compliance with each of these
initiatives is critical, as costs get out of control and the risk of noncompliance increases. The compliance process enables the public sector
to make compliance reproducible and thus maintain it permanently andcost-effectively.

CPaaS.io

Page 52 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Supporting
Activity

Validation of Federation and Transferability

Element
affected?

Requirements
Requirements arising from GDPR and national legislations must be
considered.

Data
Protection&
Security

Furthermore, the creation of an information security management
system ISMS according to ISO 27001 (ISO 2013), which helps
organizations to keep their information assets secure, is highly
recommended. All requirements for such an ISMS should be recorded.

yes

Financing must be secured before a corresponding project can beinitiated. Any Smart City endeavour, whether it is a small project or alarge Smart City program, is an expensive process. (McClellan et al.
2018)

Financing

Options for financing include, but are not limited to, the following:• Direct government-level funding at the national, regional or
local level• Public-Private Partnerships (PPP)• Private funding• Community-based funding and crowd-funding• Loans and municipial bonds• User Charges and pay-for-performance• Smart city challenges and competitions, primarily for early
prototypes

yes

5.2.3 Realization Concept
An important first part of the realization concept is listing selected technology toolsets for realising theapplication. Similar tables as used in the requirements specification (cf. and ) can also be used forsummarizing the technology options, however, instead of listing requirements, possible solutions are listed
here, thus spanning a solution space from which elements can be selected during a transfer and adaptation
project. A similar table like the one in Table 16 can also be used for summarizing the technology options,however, instead of listing requirements, possible solutions are listed here, thus spanning a solution spacefrom which elements can be selected during a transfer and adaptation project.
In addition to technology options, the realization concept must also tackle the issues of of project
methodology, development road map and architecture.
5.2.3.1 Project methodology
What project methodology is used to implement the application? Answering this question is an importantpart of the realization concept. There are various project methodologies in use, from classical waterfall-likemodels to agile approaches like SCRUM. Also, to what extent is citizen participation encouraged or evenco-creation approaches used?
Since smart city projects are mostly highly complex projects with multiple stakeholders and sometimes
unproven technology, agile project methods are very suitable, as they are designed to deal with changing
requirements, and use a controlled, iterative procedure to offer an appropriate, situational response.
However, government agencies often have regulations and standards how public projects have to be
executed (e.g., HERMES in Switzerland) that mandate more classical, waterfall-like models of project
management.
CPaaS.io

Page 53 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

5.2.3.2 Project Roadmap
According to Galati, Smart City planners must develop a realistic path to move from the concepts of their
Smart City architecture to achieving the application objectives (Galati 2018). When planning the roadmap,
project managers must consider that there may be delays in projects and that unexpected obstacles may
arise. Furthermore, all expenditure should be meticulously managed and monitored. The roadmap in therealization concept must give the necessary, high-level guidance, possibly also coordinating with other
Smart City applications being developed in parallel. What common platforms should be used is a typicalelement of such a roadmap.
5.2.3.3 Architecture
Architecture of the overall Smart City application landscape is an important topic; any newly developed
application needs to fit into the landscape. In particular when a common Smart City platform is already oris planned to be deployed, a common architecture like the functional architecture developed by CPaaS.io
becomes very useful. The realization concept must address how the application is integrated into theexisting landscape.
In any case, using views and perspectives as defined by Nick Rozanski and Eoin Woods (Rozanski & Woods
2013) is recommended to describe the application architecture itself. Of particular importance for Smart
City applications are the following perspectives: security, regulation, performance and scalability, usability,
availability and resilience, as well as evolution.
5.2.4 Operational Concept
According to Mourgue d’Algue et al., the following aspects should be considered when defining an
operational concept (Mourgue d’Algue et al. 2014):
•
•
•
•
•
•

Determining the requirements for operation
Describing the system technology
Description of the organizational plan
Description of business processes
Treatment of disorders
Description of safety aspects

The IT4IT operating model (Andenmatten 2016) proves to be well suited within the realization concept due
to its flexibility, because it can be integrated into existing operating models such as ITIL and COBIT but
focuses on the clear embedding and obligation to integrate new applications and suppliers into theoperating model. The great benefit of IT4IT as a reference architecture for the IT function lies in its
application as a guide.
For a smart city application landscape, it is important to think about the transfer and operation of theplatform in advance. By using the IT4IT reference model, a future-proof operation of the application isachieved in view of necessary extensions. In (Andenmatten 2016) a template is given according to which
IT4IT could be implemented.
5.2.5 Smart City One-Pager
The information described in the previous sections – White Paper/Value Proposition Requirement
Specification, Realization Concept and Operational Concept – can and should be summarized in the socalled Smart City Blue Print One-Pager, as shown in Table 18. It forms the basis for any transfer, as a city
official interested in a specific application can quickly gauge if that blue print is relevant for his or her city,and if yes, it provides an initial list of issues that need to be tackled, and thus to an initial roadmap andproject plan.

CPaaS.io

Page 54 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

Table 18: Smart City Blue Print One-Pager

Smart City Blueprint One Pager
Value Proposition –Creation of Public Value

Requirement specification
Ownership / Contact

Affected:Datacollection

Data carriage

Data storage

Data analytics

Data market[ ] yes[ ] yes[ ] yes[ ] yes[ ] yesplace

Application
layer[ ] yes

Supporting activities:
Sourcing(Types of vendors, vendor shortlist)

Governance & Risk Management(Frameworks and standards that are covered)

Data Protection & Security(Frameworks and standards that are covered)Financing(How is the project financed?)

Realization(List used methodologies for realization phase)

Project organisation
Roadmap[ ] PaaS (Platform as a Service) (Name of Platform)[ ] in-house development - [ ] minimal version | [ ] full value chain implementation

Architecture

Chain link spezific tools and technologies used:
Data collection

Data carriage

Data storage

Data analytics

Data market place

Application layer

List used sensors
and platforms
where data is being
collected fromList technology
used for datacarriage including
frequency whenusing wirelesstransmission

List specialities
regarding data
storage. Tools andtechnology.

List specialities
regarding data
analytics. Tools
and technology.

Tools andtechnology.

Tools andtechnology.

Operation – Organisation and Optimization

CPaaS.io

Page 55 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

5.3 Adapting an existing Smart City Blue Print
An adaption of an existing Blueprint starts with the consultation of the corresponding Blueprint One-Pager.
With the use of the One-Pager the city is able to determine the gaps between the blueprint and theirtargeted implementation. It helps to identify the parts of the blueprint which must be validated again
against the blueprint template. Once the adaption is done, the blueprint may be enhanced (e.g., with new
options for the realization phase) are a completely new blueprint may be created.
shows in BPMN notation the process of adapting an existing Smart City Blueprint. Note that in theadaptation process it is crucial to take the technical possibilities as well as the cultural context of a country
or a city into account. Figure 17 shows in BPMN notation the process of adapting an existing Smart City
Blueprint. Note that in the adaptation process it is crucial to take the technical possibilities as well as thecultural context of a country or a city into account.

Figure 21: Adaption process of an existing Smart City Blueprint

Checklists can assist in identifying existing gaps between the blue print and the needs of the city that wants
to adapt a blue print. An initial version of such a checklist is given in , refering to sections in the One-Pager;
but this initial checklist will need to be continuously updated with the experience gained in actual blue
print adaption processes.
SectionChecklist questions

Vision•

Does the Value Proposition cope with the needs of urban environment?

•
•
•
•
•
•

Are there any additional special security risks?
Are frameworks in use, which are not applicable for us?
Are sourcing and vending partners considered who are not suitable for us?
How is the project financed?
Is it possible to use the project methodology used for implementation?
Can the implementation period be similar or is a massively shortened implementation
period targeted?
Can the same software be used?
o Yes
o No  Does the software intended for use have the same functionality as the one usedin the other city?

Requirement
Specification

Realization

CPaaS.io•

Page 56 of 60

H2020 EUJ-02-2016

Deliverable D2.9

SectionValidation of Federation and Transferability

Checklist questions••

Tools &
Technologies

•
•
•
•

Operation••

Is data collected independently or obtained from existing systems that cannot be used by
us? Do we depend on the same data?
Is the technology used for data transmission available in our region and does it operate in
the same frequency band?
Does the data storage meet our expectations with regard to queries and does it havesufficient protection mechanisms against external access?
Is the syntax and semantics used sufficient for data analysis?
Is recorded content made available to other parties and does the marketplace support yourrequirements for data transfer or provision?
Should the end application be structured as it is used in the other city? Can the softwareand any actors involved also be used?
How can the Smart City application be operated after introduction?
What does the organisation look like?

Figure 22: Checklist for blueprint adaptation

5.4 Smart City Blue Print Validation
The Smart City Blue Print Template provides a tool to guide developers of Smart City applications in theinitial process, giving a structure for a project plan and listing all aspects that should be considered. Using
the Blue Print Template already at this early stage allows also capturing important information andexperiences gained along the way, and providing the basis for the transfer to another city.
To validate that this can be done in practice, we first need to fill out the template for selected use cases,
leading to concrete blue prints. In a second step we need to adapt these blue prints to the requirements
and the context of other cities, and use this adapted template in the implementation of the use case in therespective city, thus verifying that the blue prints significantly facilitate and speed up the implementation
process.
In a preliminary One-Pager is shown for the Amsterdam water management use case, illustrating the basic
use of the Blue Print Template. We are currently working on completing and detailing this one further, andon also creating blue prints for other use cases. In parallel we are talking to several cities regarding the useof such blue prints in their Smart City activities, in order to demonstrate the usefulness of the wholetemplate or at least parts of it. Initial discussions have shown that there is interest at least in the Smart City
Canvas as well as the One-Pager. In Table 16 an initial One-Pager is shown for the Amsterdam water
management use case, illustrating the basic use of the Blue Print Template. We are currently working on
completing and detailing this one further, and on also creating blue prints for other use cases. In parallel
we are talking to several cities regarding the use of such blue prints in their Smart City activities, in orderto demonstrate the usefulness of the whole template or at least parts of it. Initial discussions have shownthat there is interest at least in the Smart City Canvas as well as the One-Pager.

CPaaS.io

Page 57 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

Table 19: Smart City Blue Print One-Pager for 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 inurban 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. Withdrought, smart water management is required to allow for optimal availability of water, bothunderground as well as above ground.

Requirement specification
Ownership / Contact

Affected:

WaterNet (water utility)

Data
collection

Data carriage

Data storage

Data analytics

Data market[x] yes[x] yes[x] yes[x] yes[ ] yesplace

Application
layer[x] yes

Supporting activities:
Sourcing

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

Governance & Risk Managementtbd

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 spezific tools and technologies used:
Data collection

Data carriage

Data storage

Data analytics

1. Water-level sensors (in buffers aswell as in sewage
systems)
2. Weather data

LoRaWANtransmissionon (EU863-870MHz ISM
band)

Storing the Data in
the FIWARE Orioncontext broker

Control water
buffer valves
based on fill levels,
expected weather
data, and status
od sewage system.

Data marketplace

Application layer
FIWARE APIs (NGSI10)

Operation – Organisation and Optimization
Currently in prototype stage, determining parameters for continuous operation.

CPaaS.io

Page 58 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

6
6 SummaryIn this deliverable we have assessed how the CPaaS.io platform supports transferability of applications andprovides concrete capability and functionalities to enable cross-regional federation between European andJapanese platform instances. Moreover, we used the CPaaS.io validation framework developed in D2.7
Criteria for Validating Federation and Transferability to include the maturity, the capability to transformcities, the sustainability and value creation.
For each major CPaaS.io use case we could validate that CPaaS.io indeed supports the transferability of theapplications and is a suitable platform that is capable of federating heterogeneous IoT platforms used indifferent regions such as in Europe and in Japan. We presented three scenarios in which a technicalfederation between the European FIWARE-based CPaaS.io instance and the Japanese u2-based CPaaS.io
instance has been achieved. The first use case, the Enhanced User Experience scenario, validated that
CPaaS.io can be used for federating cross-regional platform instances on the Semantic Integration Layer
exchanging personal information. The second scenario, validated that the Virtual Entity Layer can be used
to federate cross-regional Smart Bulidings and develop application that have a holistic view on the sensors
and data managed in both platforms. Finally, the Personal Data Storage Integration successfully validated
how personal data can be managed in cross-regional applications that require the exchange between
European and Japanese platform instances.
These validation results have been part of a further analysis to identify a common methodology andtemplates when developing Smart City applications. We have therefore proposed blueprints that covertechnical and organizational aspects in a holistic way. It is a holistic approach along the value chain ofsmart city applications. Using the Waterproof Amsterdam use case we provided an initial validation of our
proposed blueprint method.

7 References
Andenmatten, M. (2016). IT4IT - das digitale Betriebskonzept der IT der Zukunft. Retrieved May 12, 2018,from https://www.iso20000.ch/application/files/8314/7871/3444/itSM38_FA_Glenfis2.pdf.
Galati, S. R. (2018). Funding a Smart City: From Concept to Actuality. In S. McClellan, J. A. Jimenez, & G.
Koutitas (Eds.), Smart Cities (pp. 17–39). Cham: Springer International Publishing.
Jenny, B. (2014). Projektmanagement: Das Wissen für den Profi (3., vollst. überarb. und aktualisierte Aufl.).
Zürich: Vdf Hochschulverlag.
Laaboudi, K., & D’Ouezzan, S. (2016). White Pater: Smart City Value Chain. Retrieved October 16, 2018,from http://www.e-madina.org/wp-content/uploads/2016/11/White-Paper-e-Madina-3.0-Value-Chainof-Smart-cities.pdf.
Moore, M., & Khagram, S. (2004). On creating public value: What business might learn from government
about strategic management (Working Paper no. 3). Cambridge, MA: John F. Kennedy School ofGovernment, Harvard University. Retrieved October 16, 2018, from http://www.hks.harvard.edu/mrcbg/CSRI/publications/workingpaper_3_moore_khagram.pdf.
CPaaS.io

Page 59 of 60

H2020 EUJ-02-2016

Deliverable D2.9

Validation of Federation and Transferability

Mourgue d’Algue, H., Eicher, G., & Kruschitz, B. (2014). Hermes 5.1: Projektmanagementmethode für alle
Projekte : Referenzhandbuch (1. Aufl.). Bern: Eidgenössisches Finanzdepartement EFD
Informatiksteuerungsorgan des Bundes ISB and Vertrieb BBL Verkauf Bundespublikationen.
Neuroni, A. C., Haller, S., van Winden, W., Carabias-Hütter, V., & Yildirim, O. (2019). Increasing Public Value
Creation for Smart Cities Using an Ecosystem Approach. In M. P. Rodriguez Bolivar (Ed.), Setting
Foundations for the Creation of Public Value in Smart Cities. Springer.
Osterwalder, A., & Pigneur, Y. (2013). Business Model Generation: A Handbook for Visionaries, Game
Changers, and Challengers (1.th ed.). New York, NY: John Wiley & Sons.
Pohl, K. (2008). Requirements engineering: Grundlagen, Prinzipien, Techniken (2., korrigierte Aufl.).
Heidelberg: dpunkt-Verlag.
Porter, M. E. (2014). Wettbewerbsvorteile: Spitzenleistungen erreichen und behaupten = (Competitive
Advantage) (8., durchges. Aufl.). Frankfurt am Main: Campus-Verlag.
Rozanski, N., & Woods, E. (2013). Software systems architecture: Working with stakeholders using
viewpoints and perspectives (2nd ed., 3rd print). Upper Saddle River, NJ: Addison-Wesley.

CPaaS.io

Page 60 of 60

H2020 EUJ-02-2016