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

Deliverable D2.5

Requirements Specification(V2)
Version V1.5
October 3, 2018
ABSTRACTIn this deliverable we provide an update of the application requirements. The
initial requirement specification has been described as part of deliverable D2.1.
Two prototypes of the main applications that drive the design of the CPaas.io
platform have been described in deliverables D2.2 and D2.4 respectively. As
expected, experiences have been gained while developing the application andreceiving feedback from stakeholders both from an application as well as from aplatform perspective. In addition, we made progress towards the federation of
the European and Japanese platform and the transferability of applications as
described in deliverable D2.7. We have also collected data at the Sapporo Snow
Festival that we consider for integration in the Enhanced User Experience
application. These developments are reflected in this document by providing an
update on the scope of the applications and their requirements. We cover all main
driving applications plus an additional Smart Parking application that emerged asa particularly suitable application for transferring knowledge to other cities. Other
main driving applications include the Sapporo Visitor Experience, Tokyo Public
Transportation, Tokyo Management of Service Vehicles, Yokosuka Emergency
Medical Care and Waterproof Amsterdam.

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

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

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

Martin Strohbach (AGT), Chiaki Ishikawa (YRP)
Martin Strohbach (AGT), Juan A. Martinez (OdinS), Sylvain Prost (TTN), Chiaki
Ishikawa (YRP)
Marianne Fraefel (BFH), Katsunori Shindo (YRP)
ReportPublic31/01/2018
30/03/2018 1
Requirements, applications, data source

1 Delivery deadline postponed by two months in order to better address reviewers’ recommendation related to individual use caseand cross-border requirements, agreed by Project Officer Olavi Luotonen in a mail dated Dec. 11, 2017.
H2020 EUJ-02-2016

CPaaS.io

Page 2 of 70

Deliverable D2.5

Requirements Specification (V2)

Revision History
Rev.
0.1
0.2
0.3

Date
30/11/2017
07/02/2018
05/03/2018

Description
TOC and document structure
Updated TOC
Smart Parking contribution

0.4

12/03/2018

0.5

26/03/2018

0.6

28/03/2018

1.0
1.1

30/03/2018
24/09/2018

1.2

28/09/18

1.3

28/09/18

1.4
1.5

01/10/2018
02/10/2018

Consolidated Input of EUE (Section 2) and Appendix
B
Integrated Chiaki’s initial input, added abstract,
introduction and summary and made further editorialchanges
Addressed review comments of Marianne Fraefel(BFH) in abstract, introduction, EUE section, summary
and appendicesFinal edits and formatting
Added explanation for introduction about selecting
requirements for validation. Added field description in
Appendix B. Adjusted requirement section of EUE
application highlighting requirements used forvalidation
Adjusted WA section, adding requirement forvalidation.
Adjusted sections for Sapporo Visitor Experience andTokyo Public Transportation
Editing touches for requirements sections 5,6 and 9.
Final edits

H2020 EUJ-02-2016

CPaaS.io

Contributors
Martin Strohbach (AGT)
Martin Strohbach (AGT)
Juan A. Martinez, Agustín
Cánovas, Antonio F. Skarmeta(OdinS)
Martin Strohbach (AGT)
Martin Strohbach (AGT)
Martin Strohbach (AGT)Stephan Haller (BFH)
Martin Strohbach (AGT)

Sylvain Prost (TTN)
Chiaki Ishikawa (YRP)
Martin Strohbach (AGT)
Martin Strohbach (AGT)

Page 3 of 70

Deliverable D2.5

Requirements Specification (V2)

Table of Contents
1

Introduction ...................................................................................................................................................................... 7

2

Event Management - Enhanced User Experience .................................................................................................. 9

3

4

5

6

2.1

Application Description ........................................................................................................................................ 9

2.2

Updated Scope........................................................................................................................................................ 9

2.3

Core Functionalities and Components ........................................................................................................... 10

2.4

Data Sets ................................................................................................................................................................. 11

2.5

Deployment Plan .................................................................................................................................................. 11

2.6

Requirements......................................................................................................................................................... 12

Event Management – Sapporo Visitor Experience .............................................................................................. 17
3.1

Application Description ...................................................................................................................................... 17

3.2

Architecture ............................................................................................................................................................ 17

3.3

User Interface ........................................................................................................................................................ 18

3.4

Data Sets ................................................................................................................................................................. 18

3.5

Deployment Plan .................................................................................................................................................. 20

3.6

Requirements......................................................................................................................................................... 20

Event Management – Tokyo Public Transportation ............................................................................................ 25
4.1

Application Description ...................................................................................................................................... 25

4.2

Architecture ............................................................................................................................................................ 25

4.3

User Interface ........................................................................................................................................................ 25

4.4

Data Sets ................................................................................................................................................................. 25

4.5

Deployment Plan .................................................................................................................................................. 26

4.6

Requirements......................................................................................................................................................... 27

Event Management – Tokyo Management of Service Vehicle ........................................................................ 35
5.1

Application Description ...................................................................................................................................... 35

5.2

Architecture ............................................................................................................................................................ 36

5.3

User Interface ........................................................................................................................................................ 36

5.4

Data Sets ................................................................................................................................................................. 36

5.5

Deployment Plan .................................................................................................................................................. 37

5.6

Requirements......................................................................................................................................................... 38

Waterproof Amsterdam .............................................................................................................................................. 44
6.1

Application description....................................................................................................................................... 44

6.2

Updated Scope...................................................................................................................................................... 45

6.3Core functionality and component ................................................................................................................. 46

6.4

Data set ................................................................................................................................................................... 47

7.1

Deployment plan .................................................................................................................................................. 48

H2020 EUJ-02-2016

CPaaS.io

Page 4 of 70

Deliverable D2.5

7.2
8

Requirements Specification (V2)Requirements......................................................................................................................................................... 49

Yokosuka Emergency Medical Care ......................................................................................................................... 53
8.1

Application Description ...................................................................................................................................... 53

8.2

Architecture ............................................................................................................................................................ 53

8.3

User Interface ........................................................................................................................................................ 53

8.4

Data Sets ................................................................................................................................................................. 53

8.5

Deployment Plan .................................................................................................................................................. 54

8.6

Requirements......................................................................................................................................................... 54

9Smart Parking ................................................................................................................................................................. 60
9.1

Application Description ...................................................................................................................................... 61

9.2

Core Functionalities and Components ........................................................................................................... 61

9.3

Data Sets ................................................................................................................................................................. 62

9.4

Deployment Plan .................................................................................................................................................. 65

9.5

Requirements......................................................................................................................................................... 65

10

Summary ..................................................................................................................................................................... 68

Appendix A – Description of the fields used in the data set description .............................................................. 69
Appendix B –Description of the fields in the requirements tables .......................................................................... 70

H2020 EUJ-02-2016

CPaaS.io

Page 5 of 70

Deliverable D2.5

Requirements Specification (V2)

Table of Acronyms
Acronym
API
TTN
LoRa
ODPT
OGD
POC
RPZ
UI

H2020 EUJ-02-2016

Definition
Application Programming Interface
The Things Network
Short for LoRaWAN: Long-Range Wide Area Network
Association of Open Data for Public Transportation
Open Governmental Data
Proof-of-Concept
Regulated Parking Zone
User Interface

CPaaS.io

Page 6 of 70

Deliverable D2.5

Requirements Specification (V2)1 Introduction
This deliverable is the second version of the requirements specification of the use cases developed on topof the CPaaS.io platform as initially described in D2.1. In this deliverable, we provide an updated
requirement specification of the use cases required for the second implementation and validation phase.
The second phase particularly focuses on the federation capability of the platform. For each application we
provide an update of the
•
•
•
•
•

Use case description
Scope of the application
Description of core functionalities, components and architecture
Definition of data sources and data sets
Description the requirements

For the actual description of the requirements we highlight whether the requirement is old, new or
updated. The updated list of requirements is the result of experiences gained while developing theapplications (see deliverables D2.2 and D2.4 for a description of the first and second application
prototypes) and receiving feedback from stakeholders, both regarding the respective applications as well
as from a platform perspective. In particular, we have taken care to reflect scalability and privacy aspects
and to link the requirements to the project objectives as described on our web page 2. These overall project
objectives are:
•

•

•

•

Objective 1: Develop an Open Social City Platform. Open in the sense of Open Data, the platform
is accessible to any interested party who then can build value-added applications and services on
top of it. Open also in the sense of Open Innovation, additional data sources like sensors operated
by private citizens, small start-up companies or established infrastructure providers can easily be
integrated into the platform and the resulting data can be made available to all. The platform –operated by or on behalf of a city – thus forms the basis for an open digitized society, making thecity more attractive for its citizens and new businesses, and also helping the city in streamlining
and improving its own governmental processes and services.
Objective 2: Deploy the City Platform as A Service Solution. The objective is to develop a Cloudbased open platform for all city information offering multiple services and the capability forfederation with other platform instances. Flexibility and elasticity will be key principles in the designof the architecture in order to support the deployment in many different cities with differing
requirements, both regarding use cases, services and operational aspects. The platform will alsoannotate such inherently unreliable IoT data with quality parameters, so that applications candecide if the data quality is good enough to be used.
Objective 3: Empower the Citizen to Her Data. A platform with city information as targeted by
CPaaS.io will also have data about its citizens – in particular with the envisioned linking of IoT datawith Open Government Data. The platform must thus provide all necessary security mechanisms
for the desired privacy and data protection properties to materialize. However, by simply restricting
all access to such data, the potential benefits for the individual as well as for the society at large ofusing such data are lost. CPaaS.io is therefore taking a more progressive stance using a MyData
approach: Let the citizen control who can access which personal data under what circumstances.
Objective 4: Validate the Platform With Use Cases Providing Public Value. The platform will be
deployed and validated by implementing several use cases that provide public value in cities, be it
to the urban society as a whole, be it to individual citizens and city visitors, or be it to the city

2 https://www.cpaas.io/#post-37

H2020 EUJ-02-2016

CPaaS.io

Page 7 of 70

Deliverable D2.5••

Requirements Specification (V2)administration. Platform deployments and use case trials will be held in Amsterdam, Sapporo,
Yokosuka and Tokyo. While for the validation of the use cases public value and acceptance are the
top criteria, the CPaaS.io platform itself will be validated along several additional dimensions: its
technical feasibility and performance, ease of deployment and operation, transferability androbustness, and economic benefits for the various stakeholders.
Objective 5: Develop Blue Prints for The Adaptation And Transfer Of Solutions To Other
Cities. One of the main reasons for implementing CPaaS.io as a joint EU-Japan project is todemonstrate that concepts and use cases developed in one city can be transferred to other cities
even when crossing cultural barriers and different ways in which city, regional and national
governments are structured. The project will therefore develop blue prints to make such transfers
easy, covering both technical and process aspects as well as the holistic approach to privacy andsecurity across the value chain, independent of the city in which the applications are used and data
is exploited.
Objective 6: Create Impact in Cities. Creating impact beyond the partners of the project is inessence the ultimate goal. The project will therefore actively promote the results through its City
Stakeholder Group. In addition, public administrations usually place a great importance on systems
that conforms to standards, hence the project will emphasize de facto and de jure standardisationin the relevant areas like IoT, Linked Data, Smart City and e-Government.

We have also added an additional column that highlights whether the requirement qualifies as coreplatform requirement, i.e. a requirement that application stakeholders consider to be fulfilled by theplatform and possibly be reused by other applications. Finally, all requirements are prioritized, andrequirements used for validation are marked. This supports better tracking throughout the project andupcoming deliverables, e.g. D2.6 Feedback and Validation Report, and D2.7 Criteria for validating
federation and transferability. The criteria for selecting which requirements are selected for validation is
described in the respective application subsection but is generally influenced by the priority of therequirement and the feasibility of its validation within the project.
In this second version of the requirements specification we have also particularly taken the requirements
for cross-border applications into account. These requirements are derived from our work on defining acommon scenario that is used to extend the Enhanced User Experience Application (MyEvents web app)with data provided by the Japanese CPaaS.io instance. More specifically, we plan to use data from the U2
architecture that has been collected at the Sapporo Snow Festival 2018. At the time of writing we arenegotiating a data transfer agreement between YRP and AGT so that the data can be used an integrated
in the MyEvents application.
In addition to the use cases and applications as described in the description of action (DoA) of the Grant
Agreement, we also describe the requirements for a Smart Parking application that emerged as aparticularly suitable application for transferring project results and experiences to other cities.
The present deliverable is structured as follows: We first describe the Event Management applications
including the Enhanced User Experience application in section 2, the Sapporo Visitor Experience in section
3, Tokyo Public Transportation in section 4, and Tokyo Management of Service Vehicles in section 5. In
section 6 we provide an update of the requirements of Waterproof Amsterdam and the updated
requirements of Yokosuka Emergency Medical Care are descried in section 8. Section 9 describes the Smart
Parking application including a list of requirements. Finally, we conclude this deliverable with a summary
in section 10. Appendix A contains a description of the fields used in the data set description and Appendix
B contains a summary of the fields used in the requirements tables.

H2020 EUJ-02-2016

CPaaS.io

Page 8 of 70

Deliverable D2.5

Requirements Specification (V2)2 Event Management - Enhanced User Experience
The Enhanced User Experience application is one of the applications that are part of the Managing Fun andSports Events Use Case or short Event Management. The Enhanced User Experience application aims at
providing the best possible experiences to event participants. It is a sensor intensive application that draws
from wearables and other sensors with the objective to detect event highlights and make event visits forparticipants unique.

2.1 Application Description
The core idea of this application is to use IoT sensors and analytics to enhance people’s experience while
visiting or participating at a fun or sports event. Wearables and mobile phones are used as sensors to learn
about the activities of event participants. Event participants may include members of the audience, butalso performing artists or athletes. For instance, in commercial settings AGT has equipped referees andcheerleaders in basketball matches with wearable sensors and created content based on the analysed datafor consumption on site and for distribution via TV broadcasting, social media and other digital distribution
channels 3. Furthermore, the application uses sensors deployed at the venue to measure and analyse fanbehaviour and engagement.
In CPaaS.io we deployed wearables at the Color Run event in Utrecht and created two initial prototypes as
described in the prototype release deliverables D2.2 and D2.5. The result is a web-based app, called
MyEvents with which users can access highlights of their event participation.

2.2 Updated Scope
While the scope compared to the first version of the requirement specification described in D2.1 has not
significantly changed, the updated requirements described in this deliverable are driven by the endeavourof using the application in a joint European Japanese use case and achieving the overall project objectives.
In particular, this includes a data collection effort that we conducted at the Sapporo Snow Festival 2018.
Details about how we plan to use the MyEvents application as part of the Sapporo Snow Festival and as
part of an overall joint use case that is described in deliverable D2.7, which details the criteria for validating
federation and transferability.
The scope is driven by the following project objectives:••

Objective 1: Develop an open social city platform. The MyEvents application focuses on thesocial aspects of the platform as it connects personal data collected from individuals both withpersonal data from friends and aggregated open data. A concrete example for such aggregatedopen data, are the IoT-based attraction ratings that can be created based on wearables of event
participants and made openly available for other applications. In addition to managing personaldata, the MyEvents application relies on the CPaas.io platform to effectively publish new open data.
Objective 3: Empower the citizen to her data. The key data sets for the MyEvents application are
personal data. This requires particular care when managing the data in the platform and whentransferring the data between regions with different legislations. The experience with the data

http://www.euroleague.net/final-four/berlin-2016/news/i/6vokoibj5fsgqg4q/heed-the-event-platform-based-joint-venturebetween-wme-img-and-agt-international-makes-first-official-foray-into-sports
3

H2020 EUJ-02-2016

CPaaS.io

Page 9 of 70

Deliverable D2.5•

Requirements Specification (V2)collection efforts in Utrecht and Sapporo further emphasized that effective means of fine granular
data access control and the ability to delete all personal data are required.
Objective 5: Develop Blue Prints for the adaptation and transfer of solutions to other cities.
The data collection event at the Sapporo Snow Festival has demonstrated the hurdles of crossregional data transfer of personal data. Multiple roles of entities collecting and processing the data
in different regions using different platform instances create a complexity that requires detailed
capturing of how data flows between entities and technical components. In the last year of the
project we use the MyEvents application for addressing both, legal and technical challenges
associated to managing personal data by different entities.

2.3 Core Functionalities and Components
The implemented architecture has been described in the second prototype release (D2.4) and is repeatedin Figure 1 below.

Figure 1: MyEvents Application

Figure 2 depicts the current view on the planned architecture for the MyEvents application. Please notethat this reflects the status at the time of writing the deliverable and that the architecture will be subject
to the final implementation decisions. The MyEvents application will focus on the semantic integration
component that will provide a common interface for accessing both platform instances. Color Run data
will be available from the European platform instance while Sapporo Snow Festival data will be available
from the Japanese instance.
On the instance of the European platform we plan to connect data sources to AGT’s IoTA platform that can
provide semantically enriched analytic results and provide the data to the IoT Broker. Depending on theconfiguration of the NGSI to RDF mapper as described in D6.3, the Semantic Integration Layer can use theSemantic Data Repository directly to respond to SPARQL queries from the application or dynamically map
between SPARQL queries and NGSI queries and NGSI responses and SPARQL responses.
On the Japanese side we plan to use the SPARQL end point of the U2 architecture. Thus no specificmapping is required. For the MyEvents application the data consumer for the Japanese platform instanceis the IoTA analytics platform that will provide the processed data to the European instance.

H2020 EUJ-02-2016

CPaaS.io

Page 10 of 70

Deliverable D2.5

Requirements Specification (V2)Figure 2: MyEvents architecture reflecting the updated scope

Please note that the following main dependencies and requirements need to be taken into consideration
when moving towards the envisaged architecture as described above:
1. The security components of WP5 need to be integrated with the IoTBroker. Without
encrypting the data managed by the IoT broker and providing fine grained access control, we
cannot provide personal data to CPaaS.io.
2. The data transfer agreement between YRP and AGT needs to be signed. Without the signatureof the data transfer agreement, we cannot transfer the data between the Japanese and European
platform instance.
3. The semantic integration layer needs to be able to query the appropriate platform instance.
The semantic integration layer needs to have knowledge about which data store holds therequested information in order to respond with the correct results.

2.4 Data Sets
Although the scope of the MyEvents application has been extended to cover the Sapporo Snow Festival,
there are no major changes with respect to the sensor-based data sets used by the application. The same
sensors and data sets have been used for collecting the data.

2.5 Deployment Plan
The deployment plan is aligned with the initial deployment plan as described in D2.1 which we repeat here
for convenience:•••

M01-M03: Initial requirement analysis and 1st deployment in order to collect data (D2.1)
M03-M06: Data analysis and implementation of first analytics prototype (D2.2)
M06-M12: 2nd deployment including test of analytics chain (internal milestone)

The first deployment was executed at the Color Run Utrecht 2016, the analytics chain has been
implemented and analytics results been made available as described in the second prototype release. The
second deployment has been executed at the Sapporo Snow Festival 2018. As soon as the data transfer
H2020 EUJ-02-2016

CPaaS.io

Page 11 of 70

Deliverable D2.5

Requirements Specification (V2)agreement is in place, we will investigate the collected data and explore whether new features can be
integrated into the application.

2.6 Requirements
In this section we extend on the requirement described in the first version (D2.1). The list of requirements
has not changed, but we extend on the existing requirements by adding new fields as described inAppendix B. In addition, we provide some additional explanatory text for each of the requirements.

H2020 EUJ-02-2016

CPaaS.io

Page 12 of 70

Deliverable D2.5

Requirements Specification (V2)ID

Description

Rationale

Fit Criterion

EUE-1

Data collection
infrastructure

EUE-2

Metadata
management

Existence of a datacollection
infrastructure
Method forcollecting metadata
and enriching
sensor data

EUE-3

Visualization of
personal data

EUE-4

Data processing

EUE-5

Control overdata collection

All services require
the collection ofreal-time data
Sensor data can only
be processed if it is
known how sensors
were deployed,
operated, to whichuser, event etc. thedata relates etc.
The visualization
component is thefront end towards
end user thatprovides him/her
access to a record of
his/her event
experience.
Data such as
excitement levels
require processingof raw sensor data
This allows users tobe empowered tomake a decision
between what datais collected and what
services they can use

H2020 EUJ-02-2016

Old/New/
UpdatedOld

Core req?
Yes

Priority

StatusUsed for validation

High

Rel. Project
Objectives
O1

Done

Yes

Old

Yes

High

O1

Done

Yes

Visual data accessfor end user

Old

No

High

O1, O3Done

No

Availability ofanalytical services

Old

Yes

High

O1, O3Done

Yes

UI for controllinguse of data

Old

Yes

Medium

O3

Open

Yes

CPaaS.io

Page 13 of 70

Deliverable D2.5

Requirements Specification (V2)ID

Description

Rationale

Fit Criterion

EUE-6

Synchronizedclocks between
IoT devices

Timesynchronization isrequired so that
sensor data fromdifferent sensors canbe correlated bytime

Maximum clock
drift

EUE-7

Efficient query ofuser data

EUE-8

Guarantees forbasefunctionality

EUE-9

Data
completeness

Personalizedvisualizations require
efficient retrieval of
media data andprocessed data fromsensor streams
When local (BT links,
wireless links to local
base stations) orbackend connectivity(cloud) is lost, theapplication must still
provide value to theend user
When local (BT links,
wireless links to local
base stations) orbackend connectivity(cloud) is lost, it
must be ensured
that data loss isavoided in order toensure service
operation

H2020 EUJ-02-2016

Old/New/
UpdatedOld

Core req?
No

Priority

StatusUsed for validation

High

Rel. Project
Objectives
O4

Done

No

Query latency in ms

Old

Yes

High

O1

Partially
done

Yes

User value

Old

No

Low

O4

Done

No

Percentage of lost
packets

Old

No

High

O4

Done

No

CPaaS.io

Page 14 of 70

Deliverable D2.5

Requirements Specification (V2)ID

Description

Rationale

Fit Criterion

EUE-10

Data sharing

Availability of data
sharingmechanisms

EUE-11

Semantic data
integration

EUE-12

Scale tothousands ofpeopleEUE-13

Access data fromdifferent
platform
instances

Users may want toshare their data via
various channels
using various
platform instances
Data sharing
between diverse
systems can only
efficiently beachieved if thesemantics of thedata are machinereadable
The application willcollect sensor andmedia data forthousands of people.
The platform needs
to be able toefficiently ingest,
store, process user
data.
Depending on where
event takes place
and who is providing
the data, it may be
stored in different
platform instances.
Ideally this shouldbe transparent for
the application.

H2020 EUJ-02-2016

Old/New/
UpdatedOld

Core req?
Yes

Priority

StatusUsed for validation

Low

Rel. Project
Objectives
O3

Open

No

Ontologies for data
to be shared

Old

Yes

High

O5

Partially
Done

Yes

Number of data
points ingested per
second, processing
latency, storage
footprint

UpdatedYes

MediumO6

StartedNo

Transparent data
access acrossplatform instances

New

Yes

High

O6

StartedYes

CPaaS.io

Page 15 of 70

Deliverable D2.5

Requirements Specification (V2)

2.6.1 Requirements Used for Validation
The following requirements are used for validating the platform. They have been selected for validation as1) they have been identified as a core requirement that should be provided by the platform, and 2) due totheir high priority.
2.6.1.1 EUE-1
The data collection infrastructure is currently realized as part of the proprietary data collection
infrastructure of AGT’s IoTA platform.
2.6.1.2 EUE-2
The metadata is managed and accessed by the CPaaS.io deployment knowledge base.
2.6.1.3 EUE-4
The data processing component has been realized as an analytical component in AGT’s IoTA analytics
platform. Consequently, there is not a strong requirement towards the platform to provide a dataprocessing or analytics service. This requirement links to objective 1, because the question of how tointegrate analytic results is an important challenge that CPaaS.io needs to address for developing theoverall platform. It also links to objective 3, as users must be able to control both their raw and processeddata.
2.6.1.4 EUE-5
This requirement is extremely important for managing personal data. Our experiences in the Utrecht andSapporo data collection effort have shown that the current approach of manual consent forms, datatransfer agreements, and implementing the technical and organizational measures slows down the processof using the data considerably. The whole process of managing personal data is extremely complex due tothe involvement of multiple data controllers, data processors and data subjects spread across regions withdifferent legislation. It is therefore highly desirable that the platform facilitates this process.
2.6.1.5 EUE-7
In the current implementation, the query latency based on the IoTA platform fully satisfies the application
requirements. We have also conducted some initial measurements on the IoTBroker that seems to satisfy
the requirement at least for smaller data sets. The maximum query latency should be below 1s.
2.6.1.6 EUE-11
As described in D6.3, ontologies for describing the deployment aspects of sensors have been defined. In
addition, in section 2.3 we have described how the SPARQL and the semantic integration layer is used by
the application to share data between platform instances. A basic ontology for sharing MyEvent data iscurrently under development.
2.6.1.7 EUE-13
This requirement is a new requirement that emerged from the fact that the Enhanced User Experience
application will need to access both the European and Japanese platform instance in order to cover the
Sapporo Snow Festival event. Transparent semantic data access to federated platform instances is a corerequirement to the CPaaS.io platform.
2.6.2 Requirements Not Used For Validation
The following list of requirements are not used for validation. For each requirement we describe briefly
why.

H2020 EUJ-02-2016

CPaaS.io

Page 16 of 70

Deliverable D2.5

Requirements Specification (V2)

2.6.2.1 EUE-3
The visualization component has been realized as part of the second prototype release D2.5. Thisrequirement is not used for validating the platform as it requires the implementation of an application
specific component.
2.6.2.2 EUE-6
This requirement has been implemented by using the Network Time Protocol (NTP) and is implemented
by the data sources and the IoTA platform. Thus, it is not a requirement towards the platform and therefore
not used for validation.
2.6.2.3 EUE-8
The MyEvents application is a web-based application and the requirement is satisfied by caching the datain the web browser. This requirement is not used for validation as it is not a core platform requirement.
2.6.2.4 EUE-9
Data completeness is achieved by the data collection infrastructure of AGT’s analytics platform, which
includes a mobile app that buffers data locally if there is no network connectivity. As this is not a coreplatform requirement it is not used for platform validation.
2.6.2.5 EUE-10
For the application itself it is not necessary that users can share their data. However, it would empowerusers to better control whether friends can use for instance a dance energy index provided by the platform
to compare against their own instance. In addition, such a functionality would help in digitalizing andimplementing informed user consent. Due to the low priority of the requirement it is not used forvalidation.
2.6.2.6 EUE-12
This requirement has been updated to scale with data collected from thousands of people at the sametime. For instance, if we assume that about 10.000 people participate at a colour run event and 10% of theparticipants are equipped with sensors, we need to target collecting and processing the data from about
1.000 participants at the same time. This requirement has not been selected for validation due to its
medium priority.

3 Event Management – Sapporo Visitor Experience
The Sapporo Visitor Experience application is part of a set of applications that will use the CPaaS.io platform
to manage fun and sports event. This application focuses on tourist information services including event
information and public transportation information.

3.1 Application Description
See V1 (D2.1) document since there have not been any changes.

3.2 Architecture
See V1 (D2.1) document since there have not been any changes.

H2020 EUJ-02-2016

CPaaS.io

Page 17 of 70

Deliverable D2.5

Requirements Specification (V2)

3.3 User Interface
See V1 (D2.1) document since there have not been any changes.

3.4 Data Sets
Although there have not been changes for the data sets since V1 (D2.1), for convenience we quote theparagraphs verbatim.
We established the “Sapporo Open Data Association”, whose members are data providers such as Sapporo
City, companies and organizations in tourism, sports and transportations. The association collects datafrom its members, transforms them to Open Data and publishes them on the Sapporo Open Data Portal.
Sightseeing Spot
Detailed Description
OGD or private data
Personal Data
Hosting
Data Provider
FormatUpdate Frequency
Update Size
Data Source
SensorNumber of Sensors

Comments, pictures and locations of popular sightseeing spots
OGD
No
Sapporo Open Data Association
Sapporo City
PDF, HTML, CSV, JPEG
YearlyN/A
Web
ucode marker
11

Meal
Detailed Description
OGD or private data
Personal Data
Hosting
Data Provider
FormatUpdate Frequency
Update Size
Data Source
SensorNumber of Sensors

Restaurant name, location, opening hours, menu, service
PrivateNo
Sapporo Open Data Association
Hotel, Sapporo Station Shopping Mall
PDF, HTML, CSV, JPEG
Monthly
N/A
Web
ucode marker
11

Hotel
Detailed Description
OGD or private data
Personal Data
Hosting
Data Provider
FormatUpdate Frequency
Update Size
Data Source
SensorNumber of Sensors

Hotel name, location, number of rooms, accessPrivateNo
Sapporo Open Data Association
HotelsPDF, HTML, CSV, JPEG
Monthly
N/A
Paper
N/A
N/A

H2020 EUJ-02-2016

CPaaS.io

Page 18 of 70

Deliverable D2.5

Other Facilities
Detailed Description
OGD or private data
Personal Data
Hosting
Data Provider
FormatUpdate Frequency
Update Size
Data Source
SensorNumber of Sensors
Snow Festival
Detailed Description
OGD or private data
Personal Data
Hosting
Data Provider
FormatUpdate Frequency
Update Size
Data Source
SensorNumber of Sensors

Requirements Specification (V2)

Location of ATM, Toilet, Rental Locker, etc.
PrivateNo
Sapporo Open Data Association
Sapporo Station Shopping Mall
PDF, HTML, CSV, JPEG
Monthly
N/A
Web
ucode marker
11

Event information in Sapporo Snow Festival
PrivateNo
Sapporo Open Data Association
Operating Committee of Sapporo Snow Festival
PDF, HTML, CSV, JPEG
YearlyWeb
ucode marker
11

Stadium Data
Detailed Description
OGD or private data
Personal Data
Hosting
Data Provider
FormatUpdate Frequency
Update Size
Data Source
SensorNumber of Sensors

Location, facilities and drawing of stadiums
OGD
No
Sapporo Open Data Association
Sapporo City
PDF, HTML, CSV, JPEG
YearlyN/AWeb, Paper
N/A
N/A

Train & Bus Data
Detailed Description
OGD or private data
Personal Data
Hosting
Data Provider
FormatUpdate Frequency
Update Size
Data Source

Time table, Operating status, Line, Real time location, bus stop, etc.
OGD & private
No
Sapporo Open Data Association
Sapporo City, Hokkaido Chuo Bus
PDF, HTML, CSV, JPEG
Monthly
N/A
File

H2020 EUJ-02-2016

CPaaS.io

Page 19 of 70

Deliverable D2.5

Requirements Specification (V2)

SensorNumber of Sensors

N/A
N/A

Express Way Data
Detailed Description
OGD or private data
Personal Data
Hosting
Data Provider
FormatUpdate Frequency
Update Size
Data Source
SensorNumber of Sensors

Information of service area
PrivateNo
Sapporo Open Data Association
NEXCO East Japan
PDF, HTML, CSV, JPEG
Yearly
N/A
Web
N/A
N/A

Underground Map Data
Detailed Description
OGD or private data
Personal Data
Hosting
Data Provider
FormatUpdate Frequency
Update Size
Data Source
SensorNumber of Sensors

Drawing of underground map
PrivateNo
Sapporo Open Data Association
Sapporo Station Shopping Mall
PDF, HTML, CSV, JPEG
YearlyN/A
Fileucode marker
11

3.5 Deployment Plan
We have started information services on Kokosil before Sapporo Snow Festival and Asian Winter Games in
February 2017. At the event venue, we will introduce the Kokosil service to visitors and collect feedback
from users. Additionally, data for the Enhanced User Experience application was collected at the Sapporo
Snow Festival in February 2018 as explained in section 2.
Also, we plan to carry out additional prototyping using signages in public places in Sapporo pending thecooperation of the city of Sapporo who owns and manages the public spaces.

3.6 Requirements
Table 1 lists the requirements.

H2020 EUJ-02-2016

CPaaS.io

Page 20 of 70

Deliverable D2.5

Requirements Specification (V2)

Table 1: Requirements for Sapporo Visitor ExperienceID

Description

Rationale

Fit Criterion

SVE-1

Data collection
infrastructure

The service requires the collectionof real-time data about the visitor(for example, the current position,
preferred language for guidance,
etc.)

Existence of a datacollection
infrastructure

SVE-2

Metadata
management

SVE-3

Visualization of
personal dataand open data

SVE-4

Data
processing

H2020 EUJ-02-2016

We include “Communication “ aspart of this infrastructure
Sensor data and data from open
data sources of various players suchas transportation operators andgovernment tourism promotion
office can only be processed if it is
known how sensors were deployed,
operated, to which user, event etc.
the data relates etc.
The visualization component is thefront end towards end user
(tourists, tourism business
operators, etc.) that provides themaccess to a record of the tourist,and sightseeing and tourism
information.
Sapporo visitor experience as
originally envisioned doesn't needthis much

CPaaS.io

Old/New/
Updated
New

Core
req ?
Yes

Priority

StatusLow

Rel. Project
Objectives
O1

Done

Used
for
Validation
Yes

Method for collecting
metadata andenriching sensor data

New

Yes

High

O1

Done

Yes

Visual data access forend userNewNo

O1, O2

O1, O3Done.

Yes

Availability ofanalytical services

New

Yes

low

O1, O2

Done

No

Page 21 of 70

Deliverable D2.5

Requirements Specification (V2)ID

Description

Rationale

Fit Criterion

SVE-5

Control overdata collection

This allows tourists to be
empowered to make a decision
between what data is collected
while the tourists are in the service
area.

SVE-6

Synchronizedclocksbetween IoT
devices
Efficient queryof sightseeing
information

Time synchronization is required sothat sensor data from different
sensors can be correlated by time

UI for controlling useof data
Aside fromautomatically collected
data such as GPS
location, the tourists
can enter data such asplaces in which they
are interested, theirfood preference, etc. attheir discretion.
Maximum clock drift(usually second
resolution is sufficientfor tourism purposes)
Query latency in sec.

SVE-7

SVE-8

Guarantees forbasefunctionality

SVE-9

Data
completenessSVE-10

Data sharing

H2020 EUJ-02-2016

Personalized visualizations require
efficient retrieval of media data andprocessed data from sensor
streams. (For example, map
information needs to be shownquickly. Also, some guidance video
clips are often shown.)
When communication between thecloud servers and mobile terminals
of tourists are cut off, the cachedinformation can be used until thecommunication is restored.
SVE as originally envisioned does
not use many sensors on the
tourists’ side and so this may not
apply here.
Tourists may want their preferencesuch as place of interest, their foodpreference, preferred language for
guidance shared between service
operators in the region.
CPaaS.io

Old/New/
Updated
New

Core
req ?
Yes

Priority

StatusMediumRel. Project
Objectives
O3

New

No

High

O1

Done

No

New

Yes

High

O1

done

Yes

User value

New

No

Low

O1

Done.

No

Percentage of lost
packetsNew

No

Low or
N/A

O1

Done.

No

Availability of data
sharing mechanisms

New

Yes

MediumO3

Donepartially.

No

Page 22 of 70

Donepartially

Used
for
ValidationNoDeliverable D2.5

Requirements Specification (V2)ID

Description

Rationale

Fit Criterion

SVE-11

Semantic data
integration

Ontologies for data to
be shared

SVE-12

Scale to a few
million visitors
in one week

The data offered by various tourism
service operators need to beoffered uniformly and this requires
the data integration function. But
this requires cooperation from thetourism business operators who
provides open data.
The largest event in Sapporo,
Sapporo Snow Festival attracts a
few million people in a week. So thesystem needs to support such large
user base.

H2020 EUJ-02-2016

CPaaS.io

Number of tourists
profile registered overtime, processing
latency, storage
footprint of suchtourist data.
And the same goes forthe sightseeing
information provided
by the service
operators andaccessed by suchtourists via kokosil.

Old/New/
Updated
New

Core
req ?
Yes

PriorityNew

Yes

Page 23 of 70

StatusHigh

Rel. Project
Objectives
O4

Open

Used
for
ValidationNo

Medium

O6

Done.

No

Deliverable D2.5

Requirements Specification (V2)

3.6.1 Requirements Used for Validation
The following requirements are used for validating the platform. They have been selected for validation as1) they have been identified as a core requirement that should be provided by the platform, and 2) due totheir high priority. Some core requirements could not be validated due to scalability issues.
3.6.1.1 SVE-1 Data collection infrastructure
The data collection infrastructure is currently realized as described in the high-level application architecture(see D2.1) and marker information is also collected to learn the whereabout of users in undergroundpassages.
3.6.1.2 SVE-2 Metadata management
The metadata is managed and accessed by the high-level application architecture (see D2.1).
3.6.1.3 SVE-3 Visualization of personal data and open data
Open data related to tourism and public transportation is incorporated and used for user interaction.
(See D2.1). Personal data is not incorporated yet. (being planned for the future).
3.6.1.4 SVE-7 Efficient query of Sightseeing information
In the current implementation, the query latency based on the high-level application architecture fully
satisfies the visitor experience application requirements. This requirement is extremely important forproviding tourism information as envisioned by the original application.
3.6.2 Requirements not used for validation
The following list of requirements are not used for validation. For each requirement we describe briefly
why.
3.6.2.1 SVE-4 Data processing
Data processing is not needed much in Sapporo User Experience prototype.
3.6.2.2 SVE-5 Control over data collection
The current application does not take advantage of personal data very much and thus this crietria was not
used for validation. Incorporation of u2 implementation of CPaaS.io PDS is being planned, and once that
happens, we can offer more customized service to the users, but since the basic functions of high-levelapplication are already available, this is not used for validation.
3.6.2.3 SVE-6 Synchronized clocks between IoT devices
Synchronization is important generally, however, as of now, the application does not need sub-second
accuracy of clos. So this not used for validation at this stage.
3.6.2.4 SVE-8 Guarantees for base functionality
Guarantees for base functionality in the face of loss of communication, cached information can be used tosome extent. But this is not used for validation purposes as of now.
3.6.2.5 SVE-9 Data completenessSVE as originally envisioned does not use many sensors on the tourists’ side and so this is not a strong
validation factor.
3.6.2.6 SVE-10 Data Sharing
Tourists may want their preference such as place of interest, their food preference, preferred language for
guidance shared between service operators in the region. As long as the service is offered through thecommon platform kokosil, the data is shared. Thus it is done partially. However, as is clear, this requires
the wide cooperation of operators in the region, and is not considered for validation factor at this stage.
H2020 EUJ-02-2016

CPaaS.io

Page 24 of 70

Deliverable D2.5

Requirements Specification (V2)

3.6.2.7 SVE-11 Semantic data integration
The data offered by various tourism service operators need to be offered uniformly and this requires thedata integration function. But this requires cooperation from the tourism business operators who provides
open data. The cooperation is beyond CPaaS.io project control and so this was not used for validation.
3.6.2.8 SVE-12 Scale to a few million visitors in one week
In principle, there does not seem to be inherent scalability issue. But CPaaS.io did not have the resources
to try this out for real. It is up to the local city and tourism industry to use the high-level applicationarchitecture that includes kokosil as a component at the forecasted scale. This this was not used forvalidation.

4 Event Management – Tokyo Public Transportation
The Tokyo Public Transport application is part of a set of applications that will use the CPaaS.io platform tomanage fun and sports event. This sub-application focuses on integrating data from different public
transportation services.

4.1 Application Description
See V1 (D2.1) since there have not been changes.
This use case trial shall be performed in Tokyo Area with the support of the "Association of Open Data for
Public Transportation" (AODPT 4). As of February 2018, ODPT has 60 members. The number of members
has increased almost two-fold since the CPaaS.io proposal had been filed. The members include railway
companies, bus companies, Japan Airlines, All Nippon Airways, and ICT companies such as Fujitsu, NEC,
Google, and Microsoft. We are collaborating with this association for the deployment of the results of the
CPaaS.io project.

4.2 Architecture
See V1 (D2.1) since there have not been any changes.

4.3 User Interface
See V1(D2.1) since there have not been any changes. Please note there will be many different UIs fordifferent apps (for example, ones developed for “Open Data Challenge for Public Transportation in Tokyo”
contest (see 4.5 for details).

4.4 Data Sets
The data sets have not changed since V1 (D2.1), but for convenience, we list them here.
In addition to the collaboration with ODPT, we will also have support from the Ministry of Land,
Infrastructure, Transport and Tourism which releases many kinds of open data for public transportation. In
our application, we will use data sets as summarized in the following table:

4 http://odpt.org

H2020 EUJ-02-2016

CPaaS.io

Page 25 of 70

Deliverable D2.5

Requirements Specification (V2)

Tokyo Public Transportation Data
Detailed Description(1) Time tables and real-time traffic information of public
transportation such as railways, buses, and airplanes.
(2) Geographical data for routes, locations of railway stations, bus
stops, airports, etc.
(3) Data of railway stations such as maps, facility lists,
OGD or private data
OGD and Private Data
Personal Data
Not included
Hosting
Consortium of Open Data for Public Transportation
Data Provider
Consortium of Open Data for Public Transportation, and many
public transportation companies and sectors
FormatucR (ucode Relation) format (RDF + ucode in JSON format)
Update Frequency
Yearly: Geographical data, railway station data, etc.
About every 6 months: Static data for operation such as time
tables, etc.
Real-time update: real-time traffic information, etc.
Update Size
New real-time data is appended to (old) existing data.
Yearly update size and 6-month update size are estimated to berelatively small (less than 10% of the existing data size).
Data Source
1.
Tokyo Public Transportation Open Data
http://www.odpt.org/
2.
Tokyo Metro Open Data
https://developer.tokyometroapp.jp/info
3.
Open Data for Pedestrian Navigation Support Services
https://www.hokoukukan.go.jp/top.html
4.
4. others
SensorLocation sensors of trains, GPS for bus locations, etc.
Number of Sensors
Hard to count/ hard to estimate (To output the data, all train andbus cars are using sensors.)

4.5 Deployment PlanAs the first step, we have started to offer public transportation open data services in Tokyo in collaboration
with ODPT. The final target year is 2020, in which the Tokyo Olympic and Paralympic Games will be held inTokyo. For the next step, we will provide SaaS for public transportation for many satellite cities in Japan.
In order to test the feasibility of the system approach, we have organized a contest for the developmentof applications based on open data made available by ODPT, called the "Open Data Challenge for Public
Transportation in Tokyo". 5This contest will help us to iron out the bugs and undesirable features from the open data offering. Also,
the apps developed in the contest will prove (or disprove) the realistic applicability of our approach.
This public transportation application scenario is planned to be experimented in the third year of the
CPaaS.io project.

5 See https://tokyochallenge.odpt.org/en/index.html for details.

H2020 EUJ-02-2016

CPaaS.io

Page 26 of 70

Deliverable D2.5

Requirements Specification (V2)

4.6 Requirements
The table below lists the updated requirements. In addition to the original requirements listed in V1 (D2.1),
we have looked at the requirements listed for EU use cases and added appropriate relevant items to thelist.

H2020 EUJ-02-2016

CPaaS.io

Page 27 of 70

Deliverable D2.5

Requirements Specification (V2)ID

Description

Rationale

Fit Criterion

TPT-1

Automated datacollection
mechanism

Existence of automatic
data collection systemfor public
transportation.

TPT-2

Multi-lingual
data

Public transportation data tends
to update frequently. Efficient
update of the data requires anautomatic data collection system(even for static data such as time
tables and maps of stations).
Foreign tourists may not haveJapanese language skills andneed multilingual information
on public transportation.

TPT-3

Live datacollection anddistribution

TPT-4

Data format andAPIstandardization(Metadata +API)

H2020 EUJ-02-2016

This use case deals with realtime operation information of
public transportation such as
trains, busses, an air planes. It isnecessary to provide automatic
data collection mechanism forthese data.
Since public transportation is
operated by many private andpublic sectors, data distribution
can only be achieved efficiently
based on standard data formats
and APIs.
Sensor data and open data frompublic transportation operators
can only be processed if it is
known how sensors were
deployed, operated, to whichuser, event etc. the data relatesetc.
End user information needs such
metadata, too.

Old/New/Updated
Old

Core
req ?
Yes

Priority

Ratio of multilingual
information in all
information.
Existence of automatictranslation system.
Existence of automaticcollection system anddistribution system oflive operation data.

Old

Existence of standard
data format andstandard API
specifications.

CPaaS.io

StatusHigh

Rel. Project
Objectives
O1

Used
for
Validation
No

Yes

High

O6

Done
partially

Yes

Old

Yes

High

O1

Done

Yes

Updated

Yes

High

O1,O5

Done
partially

Yes (forcompliantoperators)

Done

Page 28 of 70

Deliverable D2.5

Requirements Specification (V2)ID

Description

Rationale

Fit Criterion

TPT-5

Secure androbustcommunication

Existence of
cryptographic
communication
mechanism and fault
tolerance mechanism.

TPT-6

Developers' Site

TPT-7

Data License

TPT-8

Third party apps

TPT-9

Services for thephysicallychallenged

TPT-10User feedback
collection

Public transportation is a criticalsocial infrastructure.
Communication among playersof the public transportation
open data system should besecure and robust.
For the open innovation withpublic transportation open data,
it is necessary to provide anopen development environmenton the platform called"developers site".
Good data license is necessary
for the deployment of the data.
For the data license, the balance
between data holders’ merits
and users' merits is essentially
important.
Open data is a method for thecollaboration between dataholders and application
developers.
Contribution to improve qualityof life of the physicallychallenged and the elder inmoving in Tokyo is one of themost important objectives.
User feedback is necessary forthe evaluation of the use caseexperiment.

H2020 EUJ-02-2016

Old/New/Updated
Old

Core
req ?
Yes

PriorityHigh

Rel. Project
Objectives
O6

Existence of developers'site of Tokyo Public
Transportation Open
Data.

Old

Yes

High

O1,O6

Yes

Existence of open data
license.

Old

Yes

High

O1

Yes

Number of third party
apps or software.

Old

Yes

High

O1, O6

Yes

Number of services forthe physicallychallenged.

Old

Yes

High

O4

No

Number of user
feedbacks.

Old

Yes

High

O6

No

CPaaS.io

StatusUsed
forValidation
Yes

Page 29 of 70

Deliverable D2.5

Requirements Specification (V2)ID

Description

Rationale

Fit Criterion

TPT-11Visualization of
data

Visual data access forend user

TPT-12

Data processing

TPT-13Control overdata collection

TPT-14

Synchronizedclocks between
IoT devices

The visualization component is
the front end for end user thatprovides them access tointeresting data such as
timetable, the location ofvehicles, operation status, etc.
The open data from public
transportation operators need to
be processed to produce
interesting output to the end
users (for example, finding theshortest path between location
A and B, or the fastest service
between two locations, etc.)
This allows users to be
empowered to make a decision
about what data is collected
while the end user is in Tokyo
region (such as automaticallycollected GPS location, thedestination of a trip, etc.)
Time synchronization is required
so that sensor data fromdifferent sensors can becorrelated by time

H2020 EUJ-02-2016

Old/New/Updated
New

Core
req ?
No

Priority

Availability of analyticalservicesNew

UI for controlling use ofdata

Maximum clock drift(usually milliseconds.)

CPaaS.io

StatusHigh

Rel. Project
Objectives
O3

Yes

mediumO1, O3Done
partially

No

New

Yes

High

O3

Done
partially

No

New

No

High

O4

Done.

No

Done
partially

Used
for
Validation
No

Page 30 of 70

Deliverable D2.5

Requirements Specification (V2)ID

Description

Rationale

Fit Criterion

TPT-15

Efficient queryoftransportation
open data

Timely visualization ofinteresting data requires
efficient retrieval of sensor andopen data and processed datafrom sensor streams and data
sources.

TPT-16

Guarantees forbasefunctionality

TPT-17

Data
completenessTPT-18

Data sharing

When communication between
the cloud and the mobile
terminal of end users is cut off,cached data can be used tosome extent. But the nature oftransportation information
which requires the always up-todate status of the transportation
service, the loss ofcommunication basically meansthat the service is degraded very
badly.
This actually falls within the
responsibility of public
transportation operators who
provide the data to end users.
Data from various data sources
need to be shared.
End user information needs tobe shared with certain limit.

H2020 EUJ-02-2016

Core
req ?
Yes

Priority

Query latency in sec.

Old/New/Updated
New

High

Rel. Project
Objectives
O1

User value

New

No

Low

O4

Done (forcurrently
available
open data
sources:
not allpublictransporta
tion
operators
havereleased
their data
yet.)
Done.

Percentage of lost
packets

New

No

High

O4

Descoped

No

Availability of data
sharing mechanisms

New

Yes

High

O1, O3Done

Yes

CPaaS.io

StatusUsed
forValidation
Yes

No

Page 31 of 70

Deliverable D2.5

Requirements Specification (V2)ID

Description

Rationale

Fit Criterion

TPT-19Semantic data
integration

Ontologies for data to
be shared

TPT-20Scale to millions
of users

TPT-21

Communication

The data from various data
sources must be integrated andoffered in a uniform manner.
The data sources are expected
to be used by a few million users
daily.
Each day, about 3 million people
pass through Tokyo’s Shinjuku
station. So the system as awhole need to support such
scalability.
If the communication between
the cloud servers and the mobile
terminal of end users is cut off,
then cached information may be
usable to some extent. However,
due to the nature oftransportation data which needs
always up-to-date status, suchcached data may not be useful
all the time.

H2020 EUJ-02-2016

Old/New/Updated
New

Core
req ?
Yes

Priority

Number of data points
ingested per second,
processing latency,
storage footprint, andthe number of queries

New

Number of data queries
per seconds, processing
latency storage
footprint, and required

New

CPaaS.io

StatusHigh

Rel. Project
Objectives
O5

Done

Used
for
Validation
Yes

Yes

MediumO6

DescopedNo

Yes

Medium

O4, O6

Done

No

Page 32 of 70

Deliverable D2.5

Requirements Specification (V2)

4.6.1 Requirements Used for Validation
The following requirements are used for validating the platform. They have been selected for validation as1) they have been identified as a core requirement that should be provided by the platform, and 2) due totheir high priority. Some core requirements could not be validated due to scalability issues and also
because those requirements must be satisfied by the public transportation operators themselves and notby the CPaaS.io partners.
4.6.1.1 TPT-2 Multi-lingual data
Data processing is not needed much in Sapporo User Experience prototype.
4.6.1.2 TPT-3 Live Data collection and distribution
This use case deals with real-time operation information of public transportation such as trains, busses, an
air planes. It is necessary to provide automatic data collection mechanism for these data and provide thedata to the users.
4.6.1.3 TPT-4 Data format and API standardization (Metadata + API)
Done partially. Not every ODTP public transportation operators have complied yet. This is beyond thecontrol of CPaaS.io partners. Since public transportation is operated by many private and public sectors,
data distribution can only be achieved efficiently based on standard data formats and APIs. Sensor dataand open data from public transportation operators can only be processed if it is known how sensors were
deployed, operated, to which user, event etc. the data relates etc. End user information needs such
metadata, too. This is very important for data distribution.
4.6.1.4 TPT-5 Secure and robust communication
Public transportation is a critical social infrastructure. Communication among players of the public
transportation open data system should be secure and robust.
4.6.1.5 TPT-6 Developers site
For the open innovation with public transportation open data, it is necessary to provide an open
development environment on the platform called "developers site".
4.6.1.6 TPT-7 Open data license
Good data license is necessary for the deployment of the data. For the data license, the balance between
data holders’ merits and users' merits is essential.
4.6.1.7 TPT-8 Third party apps
Open data is a method for the collaboration between data holders and application developers. So themore number of apps means that the open data infrastructure is more successful.
4.6.1.8 TPT-15 Efficient query of transportation open data
Done for currently available data souces.: not all public transportation operators have released their data yet.
Timely visualization of interesting data requires efficient retrieval of sensor and open data and processeddata from sensor streams and data sources.
4.6.1.9 TPT-18 Data sharing
Done for the currently available open data sources. Data from various data sources need to be shared. Enduser information needs to be shared to some extent (but not much interest as of now from the viewpointof CPaaS.io project).

H2020 EUJ-02-2016

CPaaS.io

Page 33 of 70

Deliverable D2.5

Requirements Specification (V2)

4.6.1.10 TPT-19 Semantic data integration
Done for the currently available data sources. he data from various data sources must be integrated andoffered in a uniform manner. Note that this is primarily the responsibility of the public transportation
operators.
4.6.2 Requirements NOT Used for Validation
The following list of requirements are not used for validation. For each requirement we describe briefly
why.
4.6.2.1 TPT-1 Automated data collection mechanism
Automated data collection mechanism. This refers to the data collection done by the transportation
operators. Although it is very important, this is beyond the control of CPaaS.io partners in Japan. Thus it is
excluded from the validation criteria.
4.6.2.2 TPT-9 Services for the physically challenged
This is important for future cities. However, the provision of the services depend on the data providers, i.e.,transportation operators: for example, we depend on them to provide the barrier-free routes inside thestation for wheelchair users. Such provision is beyond the control of CPaaS.io partners. Thus it is excluded
from the validation criteria. It is certain that we can offer such services once the data for them is provided
by the public transportation operators.
4.6.2.3 TPT-10 User feedback
At this stage, the public transportation operators have just begun to accept the open data approach. They
are not quite ready to listen to the user feedback based on the use of the published open data. So theimplementation of user feedback loop either via software or manual survey is simple in principle, we haveexcluded this from validation criteria.
4.6.2.4 TPT-11 Visualization of data
Done for certain applications. The visualization component is the front end for end user that provides themaccess to interesting data such as timetable, the location of vehicles, operation status, etc. However, this is
more about the APPLICATION built on top of CPaaS.io infrastructure and not about the underlying CPaaS.io
infrastructure itself. Thus, we have excluded this from the validation criteria.
4.6.2.5 TPT-12 Data processing
Done for certain applications. The open data from public transportation operators need to be processedto produce interesting output to the end users (for example, finding the shortest path between location A
and B, or the fastest service between two locations, etc.) However, this is more about the APPLICATION
built on top of CPaaS.io infrastructure and not about the underlying CPaaS.io infrastructure itself. Thus, wehave excluded this from the validation criteria.
4.6.2.6 TPT-13 Control over data collection
Done for certain applications. This allows users to be empowered to make a decision about what data iscollected while the end user is in Tokyo region (such as automatically collected GPS location, thedestination of a trip, etc.) However, this is more about the APPLICATION built on top of CPaaS.io
infrastructure and not about the underlying CPaaS.io infrastructure itself. Thus, we have excluded this fromthe validation criteria.
4.6.2.7 TPT-14 Synchronized clocks between IoT devices
Time synchronization is required so that sensor data from different sensors can be correlated by time.
However, this is to be done by public transportation operators, and NOT BY CPaaS.io consortium. Thus, wehave excluded this from the validation criteria.
H2020 EUJ-02-2016

CPaaS.io

Page 34 of 70

Deliverable D2.5

Requirements Specification (V2)

4.6.2.8 TPT-16 Guarantees for base functionality
When communication between the cloud and the mobile terminal of end users is cut off, cached data canbe used to some extent. But the nature of transportation information which requires the always up-to-datestatus of the transportation service, the loss of communication basically means that the service is degradedvery badly. Since there is not much we can do in the face of communication cut-off, we excluded this fromthe validation criteria.
4.6.2.9 TPT-17 Data completenessThis actually falls within the responsibility of public transportation operators who provide the data to end
users. This is beyond the responsibility of CPaaS.io partners. Thus, we have excluded this from thevalidation criteria.
4.6.2.10 TPT-20 Scale to millions of users
Descoped. The data sources are expected to be used by a few million users daily. Each day, about 3 million
people pass through Tokyo’s Shinjuku station. So the system as a whole need to support such scalability.
A single service app may not need to serve million users: an app may only have a few hundred thousand
users, but there can be many service apps that access the data sources simultaneously. While thearchitecture should be capable of supporting such capability, Due to resource issues, testing at such a scale
won’t be done within CPaaS.io context. Thus, we have excluded this from the validation criteria.
4.6.2.11 TPT-21 Communication
If the communication between the cloud servers and the mobile terminal of end users is cut off, thencached information may be usable to some extent. However, due to the nature of transportation data
which needs always up-to-date status, such cached data may not be useful all the time. Since there is notmuch we can do in the face of communication cut-off, we excluded this from the validation criteria.

5 Event Management – Tokyo Management of Service Vehicle
The Tokyo Public Transport application is part of a set of applications that will use the CPaaS.io platform tomanage city events. This sub-application focuses on ensuring reliable transportation of a wide range ofvehicles in the city including for instance utility vehicles by private companies.

5.1 Application Description
This use case trial shall be performed in the extended Tokyo Area with a private transportation company.
It utilizes the package gathering/delivery operation in a metropolitan area. It provides plan, operation, andmonitor of service vehicles and images of truck beds. It provides real time updates of delivery plan andmonitoring of vehicle positions on a map. It provides QR-code based driver registration on a smart phone
application at the driver side.

H2020 EUJ-02-2016

CPaaS.io

Page 35 of 70

Deliverable D2.5

Requirements Specification (V2)

5.2 Architecture

Figure. u2-based architecture

5.3 User Interface
The user interface will be provided as a) a mobile web application and b) a web browser application.
A smart phone UIS for that provides driver assistance of vehicle transportation. There will also be an
integrated web application to incorporate the real-time operation, pre-defined routes and plans, real-timeplan updates, and road information such as traffic conditions and weather forecast.
A web browser application provides plan operator assistance of delivery planning, update, and real time
monitoring of delivery updates.

5.4 Data Sets
There are four types of data:••

Operation plan
Operation logs
Operation plan
Detailed Description
OGD or private data
Personal Data
Hosting
Data Provider
FormatUpdate Frequency
Update Size

H2020 EUJ-02-2016

Routes, delivery time and place, contact addresses, driver
information
PrivateContact addresses, driver information
External
Operation companies
JSON
Daily (with some irregular updates)
KB
CPaaS.io

Page 36 of 70

Deliverable D2.5

Requirements Specification (V2)

Operation plan
Data Source
SensorNumber of Sensors

Operation companies
N/A
N/A

Vehicle logs
Detailed Description
OGD or private data
Personal Data
Hosting
Data Provider
FormatUpdate Frequency
Update Size
Data Source
SensorNumber of Sensors

Tracking data of vehicle transportation
PrivateNo
External
Driver of a vehicle
JSON
Per minute
KB
Smartphone of a driver
Embedded in a smartphone
1 per smartphone

Truck bed status
Detailed Description
OGD or private data
Personal Data
Hosting
Data Provider
FormatUpdate Frequency
Update Size
Data Source
SensorNumber of Sensors

Camera Photo of Truck beds
PrivateNo
External
Service providers
image
Per gathering/delivery (1 per 1 hour, approx..)
50 KB
Service providers
Camera embedded in a smartphone
Not known

5.5 Deployment Plan
The deployment is plannd for the year 3. Detailed adoption plan is under way at the time of this writing.
In the simplest case, vehicle location is tracked by the smartphone of the driver.
ACCESS has experience of implementing vehicle transportation planning and management systems.
In order to provide enhanced user experience, iterated cycles of field experiments and integration of city
information data has been deployed using the CPaaS.io platform.
The deployment and improvement cycles of field tests will provide an important step-stone to provide
robust and reliable operation-management services on top of a city information infrastructure platform. It
will test the feasibility of a city information infrastructure for a wide range of operation services deployedin city areas.

H2020 EUJ-02-2016

CPaaS.io

Page 37 of 70

Deliverable D2.5

Requirements Specification (V2)

5.6 Requirements
Table 2 lists the requirements for managing service vehicles in Tokyo.
Table 2: Requirements for Tokyo Management of Service Vehicels

ID

Description

Rationale

Fit Criterion

TMS-1

Automated datacollection
mechanism

Existence of automatic
data collection systemfor public
transportation.

TMS-2

Multi-lingual
dataTransportation data tends to
update frequently. Efficient updateof the data requires an automatic
data collection system (even for
static data such as time tables andmaps of stations).
Foreign labour may not haveJapanese language skills and needmultilingual information ontransportation.

TMS-3

Live datacollection anddistribution

TMS-4

Data format andAPIstandardization(Metadata +API)

H2020 EUJ-02-2016

This use case deals with real-time
operation information oftransportation between a driver anda operator.
Since transportation is operated bymany private companies, data
distribution can only be achieved
efficiently based on standard data
formats and APIs.
Sensor data and open data frompublic transportation operators canonly be processed if it is known
how sensors were deployed,
operated, to which user, event etc.
the data relates etc.
End user information needs such
metadata, too.

Ratio of multilingual
information in all
information.
Existence of automatictranslation system.
Existence of automaticcollection system anddistribution system oflive operation data.
Existence of standard
data format andstandard API
specifications.

CPaaS.io

Old/New/
Updated
Old

Core
req ?
Yes

Priority

StatusHigh

Rel. Project
Objectives
O1

Old

Yes

Low

O6

Desco
ped

No

Old

Yes

High

O1

Done

Yes

UpdatedYes

High

O1, O5

Open

No

Open

Used
for
Validation
No

Page 38 of 70

Deliverable D2.5

Requirements Specification (V2)ID

Description

Rationale

Fit Criterion

TMS-5

Secure androbustcommunication

Existence of
cryptographic
communication
mechanism and fault
tolerance mechanism.

TMS-6

Developers' Site

TMS-7

Data License

TMS-8

Third party apps

TMS-9

Services for thephysicallychallenged

TMS-10User feedback
collection

TMS-11Visualization ofdata

Public transportation is a criticalsocial infrastructure.
Communication among players of
the public transportation open datasystem should be secure androbust.
For the open innovation with public
transportation open data, it isnecessary to provide an open
development environment on theplatform called "developers site".
Good data license is necessary forthe deployment of the data. For thedata license, the balance between
data holders’ merits and users'
merits is essentially important.
Open data is a method for thecollaboration between data holders
and application developers.
Contribution to improve quality oflife of the physically challenged andthe elder in moving in Tokyo is oneof the most important objectives.
User feedback is necessary for theevaluation of the use caseexperiment.
The visualization component is thefront end for end user that provides
them access to interesting datasuch as the location of vehicles.

H2020 EUJ-02-2016

CPaaS.io

Old/New/
Updated
Old

Core
req ?
Yes

Priority

StatusHigh

Rel. Project
Objectives
O6

Done

Used
for
Validation
Yes

Existence ofdevelopers' site ofTokyo Public
Transportation Open
Data.
Existence of open data
license.

Old

Yes

High

O1, O6

Open

No

Old

Yes

High

O1

Open

No

Number of third party
apps or software.

Old

Yes

High

O1, O6

Open.

No

Number of services forthe physicallychallenged.

Old

Yes

High

O4

Open.

No

Number of user
feedbacks.

Old

Yes

High

O6

Open.

No

Visual data access for
users

New

No

High

O3

Done
for
locatio
n on
maps.

Yes

Page 39 of 70

Deliverable D2.5

Requirements Specification (V2)ID

Description

Rationale

Fit Criterion

TMS-12

Data processing

Availability ofanalytical services

TMS-13Control overdata collection

TMS-14

Synchronizedclocks between
IoT devices
Efficient queryoftransportation
open data

The open data from public
transportation operators need to beprocessed to produce interesting
output to the end users (forexample, finding the shortest path
between location A and B, or the
fastest service between two
locations, etc.)
This allows users to be empowered
to make a decision about what datais collected while the end user is inTokyo region (such as automaticallycollected GPS location, , etc.)
Time synchronization is required sothat sensor data from different
sensors can be correlated by time
Timely visualization of interestingdata requires efficient retrieval of
sensor and open data andprocessed data from sensor streams
and data sources.
When communication between thecloud and the mobile terminal ofend users is cut off, cached data
can be used to some extent. But thenature of transportation
information which requires thealways up-to-date status of thetransportation service, the loss ofcommunication basically meansthat the service is degraded very
badly.
This actually falls within the
responsibility of transportation
operators who provide the data to
end users.

TMS-15

TMS-16

Guarantees forbasefunctionality

TMS-17

Data
completenessH2020 EUJ-02-2016

CPaaS.io

Old/New/
Updated
New

Core
req ?
Yes

Priority

StatusmediumRel. Project
Objectives
O1, O3

UI for controlling useof data

New

Yes

High

O3

No

New

No

High

O4

Done
for
certainservices
Open.

Maximum clock drift(usually milliseconds.)
Query latency in sec.

New

Yes

High

O1

Open.

No

User value

New

No

Low

O4

Desco
ped

No

Percentage of lost
packets

New

No

High

O4

Open.

No

Page 40 of 70

Open.

Used
for
Validation
Yes

NoDeliverable D2.5

Requirements Specification (V2)ID

Description

Rationale

Fit Criterion

TMS-18

Data sharing

Availability of data
sharing mechanisms

TMS-19Semantic data
integration

Data from various data sources
need to be shared.
End user information needs to beshared with certain limit.
The data from various data sourcesmust be integrated and offered in a
uniform manner.

TMS-20Scale to millions
of users

The data sources are expected to
be used by a few million users daily
to cover the whole Tokyo area
private delivery operations.

TMS-21

Communication

If the communication between thecloud servers and the mobile
terminal of end users is cut off, thencached information may be usable
to some extent. However, due tothe nature of transportation data
which needs always up-to-datestatus, such cached data may not
be useful all the time.

H2020 EUJ-02-2016

CPaaS.io

Old/New/
Updated
New

Core
req ?
Yes

Priority

StatusHigh

Rel. Project
Objectives
O1, O3

Ontologies for data to
be shared

New

Yes

High

O5

No

New

Yes

MediumO6

Due tothepartner’s
request, theopen
data
facility
is notdeployed intheprototype atthisstage.
Open.

Number of data points
ingested per second,
processing latency,
storage footprint, andthe number of queries
Number of data
queries per seconds,
processing latency
storage footprint, andrequiredNew

Yes

Medium

O4, O6

Open.

No

Page 41 of 70

Open.

Used
for
Validation
Yes

NoDeliverable D2.5

Requirements Specification (V2)

5.6.1 Requirements Used for Validation
The following requirements are used for validating the platform. They have been selected for validation as1) they have been identified as a core requirement that should be provided by the platform, and 2) due totheir high priority. Some core requirements could not be validated due to scalability issues and also
because those requirements must be satisfied by the transportation operators themselves and not by the
CPaaS.io partners.
5.6.1.1 TMS-3 Live Data collection and distribution
This use case deals with real-time operation information of trucks. It is necessary to provide automatic datacollection mechanism for these data and provide the data to the users.
5.6.1.2 TMS-5 Secure and robust communication
Communication among stakeholders of the transportation open data system should be secure and robust.
5.6.1.3 TMS-11 Visualization of data
The visualization component is the front end for end user that provides them access to real time photo
data and location information on maps. When an end user requests and the partner agrees, it can be also
provided to the end user.
5.6.1.4 TMS-12 Data processing
The data from transportation operators need to be processed to produce usable output for optimization.
Intelligent processing of photo data to track delivery status is used for validation.
5.6.1.5 TMS-18 Data sharing
Data from various data sources need to be shared. Real time sharing between driver’ apps and plan
operators are important.
5.6.2 Requirements NOT Used for Validation
The following list of requirements are not used for validation. For each requirement we describe briefly
why.
5.6.2.1 TMS-1 Automated data collection mechanism
Automated data collection mechanism. This refers to the data collection done by the transportation
operators. This is not done at the initial stage. Evaluation is needed to identify how to facilitate cost-benefit
automatic data collection. Although it is very important , this is beyond the control of a CPaaS.io partner
in Japan at the initial adoption. Thus, it is excluded from the validation criteria.
5.6.2.2 TMS-2 Multi-lingual data
Multi-lingual data is not needed much in Tokyo Management of Service Vehicle prototype as the partner
does not require it at this stage. Therefore, this requirements has been descroped.
5.6.2.3 TMS-4 Data format and API standardization (Metadata + API)
Since smart city transportation is operated by many private companies, data distribution can only beachieved efficiently based on standard data formats and APIs. Sensor data and open data fromtransportation operators can only be processed if it is known how sensors were deployed, operated, towhich user, event etc. the data relates etc. This is very important for data distribution. Due to partner’s
request, open data format is not deployed and validated in the prototype at this stage.
5.6.2.4 TMS-6 Developers site
For the open innovation with transportation open data, it is necessary to provide an open development
environment on the platform called "developers site". It is important, but the partner is not ready for
opening the private data, it is excluded from validation at this stage.
H2020 EUJ-02-2016

CPaaS.io

Deliverable D2.5

Requirements Specification (V2)

5.6.2.5 TMS-7 Open data license
Good data license is necessary for the deployment of the data. For the data license, the balance between
data holders’ merits and users' merits is important, but the partner is not ready for opening the private
data, it is excluded from validation at this stage.
5.6.2.6 TMS-8 Third party apps
Open data is a method for the collaboration between data holders and application developers. So themore number of apps means that the open data infrastructure is more successful. However, the partner is
not ready for opening the private data, it is excluded from validation at this stage.
5.6.2.7 TMS-9 Services for the physically challenged
This is important for future cities. However, the provision of the services depend on the data providers, i.e.,transportation service operators. Such provision is beyond the control of CPaaS.io partners. Thus it is
excluded from the validation criteria.
5.6.2.8 TMS-10 User feedback
At this stage, the transportation operators has just begun to deploy the real time operation assistance.
They are not quite ready to listen to the user feedback based on the use of the published open data. So
we have excluded this from validation criteria due to their burdens.
5.6.2.9 TMS-13 Control over data collection
This allows users to be empowered to make a decision about what data is collected while the end user isin Tokyo region (such as automatically collected GPS location, the destination of a trip, etc.) This prototype
provides an enterprise application and does not support this feature. This requirement is more about theapplication built on top of CPaaS.io infrastructure and not about the infrastructure itself. Thus, we haveexcluded this from the validation criteria.
5.6.2.10 TMS-14 Synchronized clocks between IoT devices
Time synchronization is required so that sensor data from different sensors can be correlated by time.
However, this prototype does not utilize synchronized operation among operators. These are to be doneby public transportation operators, and NOT BY CPaaS.io consortium. Thus, we have excluded this fromthe validation criteria.
5.6.2.11 TMS-15 Efficient query of transportation open data
Timely visualization of interesting data requires efficient retrieval of sensor and open data and processeddata from sensor streams and data sources. Due to the partner’s request, query of open data is excluded
from this prototype at this stage.
5.6.2.12 TMS-16 Guarantees for base functionality
When communication between the cloud and the mobile terminal of end users is cut off, cached data
can be used to some extent. But the nature of transportation information which requires the always upto-date status of the transportation service, the loss of communication basically means that the service isdegraded very badly. Since there is not much we can do in the face of communication cut-off, we
descoped this requirement and excluded it to be used for validation.
5.6.2.13 TMS-17 Data completenessThis actually falls within the responsibility of transportation operators who provide the data to end users.
Thus, we have excluded this from the validation criteria.
5.6.2.14 TMS-19 Semantic data integration
The data from various data sources must be integrated and offered in a uniform manner. Note that this is
primarily the responsibility of the public transportation operators.
H2020 EUJ-02-2016

CPaaS.io

Page 43 of 70

Deliverable D2.5

Requirements Specification (V2)

5.6.2.15 TMS-20 Scale to millions of users
The data sources are expected to be used by a thousand users daily. So the system as a whole need tosupport such scalability. The current prototype has estimated to have a capacity of 10-scale expansion. A
million-scale users to cover the whole Tokyo delivery is not in scope of this prototype. Due to resource
issues, testing at such a scale in the private company context won’t be done within CPaaS.io context. Thus,
we have excluded this from the validation criteria.
5.6.2.16 TMS-21 Communication
If the communication between the cloud servers and the mobile terminal of end users is cut off, thencached information may be usable to some extent. However, due to the nature of transportation data
which needs always up-to-date status, such cached data may not be useful all the time.
Since there is not much we can do in the face of communication cut-off, we excluded this from thevalidation criteria.

6 Waterproof Amsterdam
The rain proof Amsterdam application is a single, but highly relevant application that will use the CPaaS.io
platform to improve water management. Through smart, connected rain buffers, water supply peak shaving
can be done in order to prevent streets, sidewalks and basements from flooding during heavy rainfall.
What makes this application interesting, is the ability to orchestrate the operation of multiple buffers
simultaneously across a geographical network. This way, significant impact is expected which will actually
address the existing bottlenecks of insufficient water processing capacity.
Update: The use case project has now the approval and the support of Waternet, the local water
management company. A start-up under the name De Dakdokters 6 has joined the project, they are
manufacturing green roofs that use the collected rain water to irrigate roof gardens.

6.1 Application description
As research shows, extreme rainfall is becoming fiercer and will occur more frequently. The application is apart of an effort initiated in Amsterdam by Waternet to prevent damage during this kind of weather. Byleveraging new smart-roof technologies and rain collectors (rain barrel, underground tanks) along smart
city solution, the goal is to create a network of water reservoir that will improve cities’ water absorption.
Roughly speaking, a solution has to deal with information from three different areas: the private domain,
the public domain and weather forecast. For an optimal contribution of the smart water management
system to the existing water management infrastructure, these three domains need to be integrated,featuring an iterative self-learning system which considers the limitations of the existing water
management infrastructure. The buffers will be productised for the use in residential and commercial areas.
The main premise is that an owner of a smart rain barrel can determine to what extent he / she wants toconnect and share on the public network and how permission is given to be overruled by a third party
such as Waternet (Amsterdam regional parastatal water management company) in case of predicted
extreme rainfall or drought.
To that end, the application will periodically fetch data from a weather platform. It will attempt to use local
weather platform with better geographic data and timeline or register to the local weather forecast alerts.

6 http://dakdokters.nl/en/green-roofs/

H2020 EUJ-02-2016

CPaaS.io

Page 44 of 70

Deliverable D2.5

Requirements Specification (V2)

In case a potential harmful rain is detected, it will calculate how to setup the water network to avoid
damage with the minimum amount of action needed.

6.2 Updated Scope
On the device side we added support for IP devices, i.e., Internet-ready devices. So now a device in chargeof collecting rain can either use LoRaWAN or HTTP. The devices will report their status, containing at least
the current amount of water held, on a set time and it will be possible to send command messages to thedevices to release or retain water.
To match the CPaaS.io objectives, efforts have been directed towards the structure of the application andits security. The structure is now based on micro-services that integrate the different services of CPaaS.io,
notably FogFlow and the security layer.
On the user interface side, we decided to change the approach: We won't provide a full device owner
dashboard or app, only a simple web app for device owners to visualize their data as a POC. This is
motivated by the fact that each manufacturer has a different approach to their user relations and businessmodel. Furthermore, it would be a duplicate of the CPaaS.io dashboard as it would show the same data(all sensor data). The device makers will have access to all their deployed devices that are on the platform
with data access defined in the User Agreement they present to their user, so they can integrate the datain their own solution.
We will keep developing a global dashboard for the water management company to aggregate sensor
data and display it on a map.
The scope is motivated by the following objectives:
Objective 1: Develop an open social city platform. Smart rooftops are mainly installed on top ofbuildings that either host offices or apartment. In those cases, occupants might be able to visualize thedata reported but more importantly use the platform to build other applications such as an automatedgarden or redirect the water inside the building.
Objective 2: Deploy the city platform as a service solution. First, data must respect a defined format
which avoids different interpretation of data semantics, though it stays free on the choice of the displayed
physical unit. Second, a service will be put in place to monitor the device behaviour. It will be able to detect
unusual data changes and raise an alert that the device might need intervention.
Objective 3: Empower the citizen and her data. The user is the sole owner of the data and is free todelete any records. Other parties can be given access through a CPaaS.io capability token. User will want
to give access to the manufacturer depending on the provided service, and mostly to the city water
management company if the user agrees to share the control of its buffer. Being part of the application isa choice that can be changed at any time.
Objective 4: Validate the platform with use cases providing public value. The applications main
objective is to reduce structural damages provoked by intense rain. Less public money and workers in thestreet to repair those damages.
Objective 5: Develop blueprints for adaptations and transfer of solutions to other cities. All theservices settings and deployment are defined in a FogFlow service topology. In practice, duplicating the
topology and change a few settings will suffice to create a new instance of the solution.

H2020 EUJ-02-2016

CPaaS.io

Page 45 of 70

Deliverable D2.5

Requirements Specification (V2)

Objective 6: Create impact in cities. The data are formatted and exploitable by any other parties, given
they are given access to the data. The smart roof project also has impact in making the city more water
efficient. De Dakdokters roofs for example are gardens that will attract new wildlife and help treat pollution.

6.3 Core functionality and component
A first version of the application was realized but it was lacking stability and flexibility. A second version isin the making. It aims for a more scalable architecture using microservices and leverage Fog Flow for
deployment. The whole application will be separated in different microservices contained by docker. TTN
will host two bridges where the sensors data are published (an HTTP endpoint and an MQTT client
connected to TTN), the analytics service, device registry and context are orchestrated by Fog Flow andfinally, any authorized dashboard can connect to the Fog Flow context manager. Overall it will improvestability, configuration, scalability, service integration and security.

Dashboard

TTN
HTTP inFog flowTasks
Analytic

HTTP out

Context
Manager

LoRaWAN in
LoRaWANoutgroupBy:
DeviceType
Figure 3 - Waterproof architecture

One of the motivations to use Fog Flow was the ability to create streams of data or messages. We defined
two streams, inbound and outbound, all under the same id, but each message has a DeviceType field todifferentiate the origin of the data and which bridge to use.
The model is two bound, I/O bounds with two different interfaces:•

Inbound (in):o Basic http server where devices can push their sensor data.
o LoRaWAN, a TTN – Fog Flow integration that converts LoRaWAN uplinks to proper JSONNGSI-10o We are considering a websocket bridge to avoid a complex callback setup when using IP
capable devices. When installed on a home network, for example, it can be difficult to createsuch a callback

H2020 EUJ-02-2016

CPaaS.io

Page 46 of 70

Deliverable D2.5•

Requirements Specification (V2)

Outbound:o An HTTP callback is open to listen for messages in the outbound stream having theDeviceType HTTP. The messages are then converted for the device to understand them.
o Another HTTP callback is open to listen for message in the outbound stream having theDeviceType LoRaWAN. They are then formatted to fit the LoRaWAN requirement.

Other services can subscribe to the generated stream of data, which includes the Waternet analytics service.
This service constantly monitors the state of the water buffer in case actions need to be taken. It will also
periodically pull a weather report.

6.4 Data set
We use the following types of data, nothing has changed:
1. Data from the private domain.
a. The type of storage (rooftop, rain barrel, underground storage)b. The per hour uptake and release capacityc. The drainage destination (direct to sewerage, into garden soil
i. with varying levels of soil humidity, for instance connected to soil sensors
d. Situation of buffers across a city, determining the density of the buffer network
7 Data from the public domain:a. (Historical) water-related data: known areas of water flooding and other rainfall related
issues, ground water levels
b. Water infrastructure: sewerage, capacity, bottlenecks, etc.
c. Data from weather forecast agencies
Depending on the availability of data to be stored in the CPaaS.io platform, the application may draw form
this data to get data on local water infrastructure and weather. All those data are processed by theapplication (Note: only the water level and debit are processed for the water tank).
Weather data
Detailed Description
OGD or private data
Personal Data
Hosting
Data Provider
FormatUpdate Frequency
Update Size
Data Source
SensorNumber of Sensors
Water tank data
Detailed Description
OGD or private data
Personal Data
Hosting
Data Provider
FormatUpdate Frequency
H2020 EUJ-02-2016

Upcoming weather displaying periods of heavy rain or
drought
OGD
No
Platform
KNMI – Dutch weather forecast agency
JSON, XML
Hourly10kb
Sensors
Water sensor
unknown

Filling degree of a water buffer (rooftop, barrel,
underground storage); Any other data provided by thedevice.
PrivateYes
External
TTN / Waternet
JSON
Hourly or instantly with sudden increasing levels
CPaaS.io

Page 47 of 70

Deliverable D2.5

Requirements Specification (V2)

Update Size
Data Source
SensorNumber of Sensors

10b
Sensors
Water sensor
1 per buffer

Municipality water infrastructure
Detailed Description

Geographical data on water infrastructure depicting
capacity and ground water levels
OGD
No
Platform
Waternet
XML
Hourly1kb
Sensors, maps
Water sensor
unknown

OGD or private data
Personal Data
Hosting
Data Provider
FormatUpdate Frequency
Update Size
Data Source
SensorNumber of Sensors

7.1 Deployment plan
Over the last year, we made progress on the deployment of smart roofs, thanks to the addition of De
Dakdokters. We also defined, prototyped and prove the concept. For the next months we will work toward
a first market ready LoRaWAN roof, a connection to the security layer of CPaaS and FogFlow deployment.
Smart roofs have a lot of constrains to be deployed and it is unsure that cities will have the same regulationas Amsterdam, so we are holding off on plans to deploy those roofs in other regions or countries.
Nonetheless it is perfectly possible to connect any devices for a proof-of-concept in other regions.
•••

M01~M12: Requirement analysis and service/system designoAlign all stakeholders and receive contractual commitment from Waternet for thedevelopment of the use case (M04-M05)

oInvestigate areas in the city that dictate the highest urgency or best applicability for a pilot

M03~M18: System and service developmentoDevelop a smart, connected hardware prototype in a lab setting.

oIntegrate prototype on The Things Network backend.

o

Set up a physical LoRa network in the pilot area by placing gateway on rooftop in pilot areaoFirst and second release prototype

M06~M28: Experiment and evaluationo

Test of first and second releaseoDevelop 10 more hardware prototypes to be deployed and tested in real life, outdoor
setting.

H2020 EUJ-02-2016

CPaaS.io

Page 48 of 70

Deliverable D2.5

Requirements Specification (V2)oDeploy prototypes in existing rain buffer projects in business district in Amsterdam (Zuidarea).

oThird release prototype

As of today, Waternet is on board, we have prototyped and demonstrated live both LoRaWAN and HTTP
devices. New rooftops have been deployed and more are to come.

7.2 Requirements
Table 3 lists the updated requirements.

H2020 EUJ-02-2016

CPaaS.io

Page 49 of 70

Deliverable D2.5

Requirements Specification (V2)

Table 3: List of requirements for Waterproof Amsterdam

ID

Description

Rationale

Fit Criterion

WA-1

Data collection

Existence of datacollection
infrastructure

WA-2

Data processing

WA-3

User hierarchies

WA-4

Manual control
over device

WA-5

Automated control
over device

WA-6

Adaptive control
levels

The application collects andstores data from different
sources, including sensors
and static cadastral andinfrastructural information
A rain buffer contains a set ofstandard parameters, such as
type, location, capacity. These
parameters should becomplemented with lifetime
usage data, such as
times/open close, amountbuffered/released,
active/inactive, filling level,
battery status, etc.
Different user groups canexert different levels ofcontrol over a device, so ahierarchy between groups isestablished
The user or shared user canorder the buffer to release orretain water.
Circumstances need to be
defined, based on the various
data sources, in which device
control for user groups are
suspended and delegated toa central user/authority.
The rules and circumstances
may automatically trigger
control levels as they occur.

H2020 EUJ-02-2016

Old/New/
UpdatedUpdated

Core
req ?
Yes

Priority

StatusHigh

Rel. Project
Objectives
O1

Done

Used for
Validation
Yes

Method for collecting
metadata andenriching sensor data

Old

Yes

High

O1

Done

Yes

Definition of usergroups, definition ofaccess rights

Updated

Yes

High

O3

Partiallydone

No

UI where users canactivate/deactivate thereleasePresence of algorithms

Updated

No

Low

O3

Partiallydone

NoUpdatedYes

Medium

O4, O6

Open

Yes

Control levels defined

Old

No

Low

O3

Open

No

CPaaS.io

Page 50 of 70

Deliverable D2.5

WA-7

Visualisation ofdevice status

WA-8

Operator control
centreWA-9

Push notifications

WA-10

User feedback
collection

WA-11

Data harmonisation

WA-12

Physical network

WA-13

MulticastMessaging

H2020 EUJ-02-2016

Requirements Specification (V2)

Users can access information
via a graphical front-end that
displays a record of the rain
buffer status, such as fillinglevel.
Data can be aggregated per
geographical area in order tomonitor the status of andtrigger actions on a numberof devices altogether?
Circumstances may trigger
communication of predefined
messages to users such aspush notifications.
Prompts in the application
can be used to manually
collect user feedback.
Data collected from thevarious sources needs to beuseable and interpretable by
the application
Data transmission ismodulated with LoRa,
operated by The Things
Network network server. The
application needs to be
integrated with TTN API
Multicast messaging

UI that can beaccessed by user.

Updated

No

Low

O3

PartiallyDone

No

UI for network
operator.

UpdatedYesHigh

O4, O6O

Open

No

Reception of
notifications

Old

No

Low

O3

Open

No

Collection of feedback

Old

No

Low

O3

Open

No

Ontologies for data to
be shared

Old

Yes

Medium

O1

Done

Yes

Data received inapplication server via
TTN API

Updated

Yes

High

O1

Done

Yes

Bulk downlink
messages may be sent
to control large
quantities of actuators
at the same time.

Messagessent fromcontrol
centreNo

MediumO1

PartiallyNo

CPaaS.io

Page 51 of 70

Deliverable

D2.5

Requirements Specification (V2)

7.2.1 Requirements Used for Validation
The following requirements are used for validating the platform. They have been selected for validation as1) they have been identified as a core requirement that should be provided by the platform, and 2) due totheir high priority.
7.2.1.1 WA-1
Done. All data are stored and annotated in a broker. This is a basic requirement, data need to be stored
and accessible for the operators (user or analytic) to visualize and act based on the data.
7.2.1.2 WA-2
Done. Metadata of the water buffer are required when registering the buffer on the platform. Additional
metadata are collected for LoRa devices (radio strength, etc.). Metadata such as the physic unit and theoptional metrics are required to provide accurate information and detect defect.
7.2.1.3 WA-5
Open. The service has not been deployed yet. Crossing weather data and the current state of the watertanks is one of the main added value of the application.
7.2.1.4 WA-11
Done. Data are following a define format that enforces the ontology of the application. Some freedom isallowed in the choice of the physical unit. If the message doesn't follow the format it is refused. Attributes
names must be harmonised otherwise the analytics cannot recover the data, same as the UI and user.
7.2.1.5 WA-12
Done using a proxy, handling the formatting of the message. Will be replaced by complete NGSI
integration being deployed on TTN. Mapping data to the correct format defined by WA-11. Therefore
required.
7.2.2 Requirements not Used for Validation
7.2.2.1 WA-3
Partial. Some command can be set as "locking" but we need to see how to integrate this with the capability
and security service of CPaaS.io and be synchronised with the device manufacturer. This feature requiredas this only enforce the decision of the service, so the user cannot remotely control the device via CPaaS.
The use case is still valid as this is a simple measure to make the network of water tank more reliable.
7.2.2.1.1 WA-4
Partial. Workflow and API exist but not the UI. The point is to have the analytic pilot the buffer, the user
come second in this case.
7.2.2.2 WA-6
Open. Same as WA-5. User can input rules, such as release water when the water level is above a limit. A
service will pass over those rules when a new message is received. This is not relevant for validation as it ishigh level feature to provide comfort to the user, it also most of the time implemented by the manufacturer
or resellers in their own application.
7.2.2.3 WA-7
Partial. A first UI was made using MyDevices dashboard. Need to move it to the CPaaS.io dashboard. User
will be able to visualize the water level of their buffer, the metadata and the other sensor data sent by thedevice. UI is secondary for the application, visualization should be made through the CPaaS dashboard.
7.2.2.4 WA-8
Open. Waiting on CPaaS.io dashboard. Same a WA-7 for the validation criteria.
H2020 EUJ-02-2016

CPaaS.io

Deliverable

D2.5

Requirements Specification (V2)

7.2.2.5 WA-9
Open. Low importance and priority. Furthermore, it can only be effective and useful once the WA-4, WA5- WA-6 are done.
7.2.2.6 WA-10
Open. Now end-user have been involved for now. We rely on feedback made by the manufacturer andWaternet. Feedback form will be integrated in the user UI or via email. User feedback are not necessary forthe application to be validated. They define the attraction of the application and leads of improvement.
7.2.2.7 WA-13
Partial. Process and workflow are here but the UI is not present. It is to speed up request and reduce
network usage. The others services can simply send command one by one, it then no required.

8 Yokosuka Emergency Medical Care
The Yokosuka Emergency Medical Care application is a single, but highly relevant use application that will
use the CPaaS.io platform to improve first aid management.
The use case has not changed much from V1 (D2.1) except for a triage system.

8.1 Application Description
See V1 (D2.1) since there have not been many changes. The only notable change is that we no longer
actively support a triage system since the medical teams do not use them currently at all.

8.2 Architecture
See V1 (D2.1) since there have not been any relevant changes.

8.3 User Interface
See V1 (D2.1) since there have not been any relevant changes

8.4 Data Sets
The data sets in this use case has been updated since V1 (D2.1) as follows:
Yokosuka Emergency Medical Care Data
Detailed Description
Emergency Medical Care Sensor data
OGD or private data
Private Data
Personal Data
Some include Personal Data
Hosting
Location Information: Emergency Medical Care Server
Camera Image: none (connected directory)
Data Provider
Location Information: Emergency Medical Care Server
Camera Image: none (connected directory)
FormatucR (ucode Relation) format (RDF + ucode in JSON format)
Update Frequency
Real-time Update
Update Size
New real-time data is appended to (old) existing data.
H2020 EUJ-02-2016

CPaaS.io

Deliverable

D2.5

Requirements Specification (V2)

Data Source
SensorNumber of Sensors

Emergency service seam and emergency hospitals of the City of
Yokosuka
14 ambulances in Yokosuka City and Miura City are equipped withsensors such as cameras (image sensors) and GPSs (location
sensors).
More than 100 sensors will be used.

8.5 Deployment Plan
We made a significant progress in terms of societal impact. The following is an updated paragraph sinceV1 (D2.1):
We have collaborated with the Yokosuka City Office and all emergency hospitals in the City of Yokosuka.
In April 2017, Fire authorities in Miura city were integrated with one in Yokosuka City, so ambulances in
Miura city have been incorporated in our Emergency Medical Care system.
For the next step, we will extend the deployment to the whole Miura Peninsula, a region which includes
Yokosuka City, Zushi City, Kamakura City, and Hayama Town. These city and town halls are collaborating,and they often adopt common municipal service systems as a standard. After that, we will try to deploy
our system across Japan.
This Yokosuka emergency medical service use case started from the 2nd year of the CPaaS.io project. So,
the development and experiment plan are as follows:•••

M01~M09: Requirement analysis and service/system design
M10~M25: System and service development
M16~M21: Experiment

8.6 Requirements
Table 4 lists the updated requirements. In addition to the original requirements listed in V1 (D2.1), we havelooked at the requirements listed for the EU use cases and added appropriate relevant items to the list.

H2020 EUJ-02-2016

CPaaS.io

Deliverable D2.5

Requirements Specification (V2)
Table 4: Yokosuka Emergency Medical Care Requirements

ID

Description

Rationale

Fit Criterion

YEM-1

Data collection

Existence of automaticcollection system

YEM -2

Consensus forusing medical
and personal
data by city
government

YEM -3

Privacyprotection ofpatients

YEM-4

Low-effort for
emergency
medical teamstaff members

YEM-5

User feedback
collection

This use case deals with realtime operation informationof such as patients'
conditions, and position of
ambulances. It is necessary toprovide automatic datacollection mechanism forthese data.
The data may have direct orindirect relations withpersonal information ofpatients. Before the trial, we
need to have formal
consensus with city
government on the basis of
official guidelines for
personal data.
We must provide strong dataprotection mechanism suchas secure communicationand secure storage.
Emergency medical teamstaff members are doing very
hard work for taking care ofpatients. It is impossible forthem to spend time andeffort for the operation ofthis system. We must realize
a good work-flow and userinterface for the team staff.
User feedback is necessary
for the evaluation of the usecase experiment.

H2020 EUJ-02-2016

Old/New/
Updated
Old

Core
req ?
Yes

Priority

StatusHigh

Rel. Project
Objectives
O1

Done

Used for
Validation
Yes

Agreement with Yokosuka
city government

Old

Yes

High

O1

Done

Yes

Existence of privacy dataprotection mechanism

Old

Yes

High

O1, O3

Done

Yes

Existence of low-effort
mechanism andevaluation score by theteam staff members

Old

Yes

High

O1, O3

Done

Yes

Number of user feedbacks

Old

Yes

High

O3

Done

Yes

CPaaS.io

Page 55 of 70

Deliverable D2.5

Requirements Specification (V2)ID

Description

Rationale

Fit Criterion

YEM-6

Metadata
management

Method for collecting
metadata and enriching
sensor data

YEM-7

Visualization of
personal data

YEM-8

Data processing

YEM-9

Control overdata collection

Sensors are used to obtain
vital data for patients. Sensor
data can only be processed if
it is known how sensors were
deployed, operated, to whichuser, event, etc. the data
relates, etc.
The visualization component
is the front end towards end
user (doctors, dispatchers,etc.) that provides them withthe up-to-date health related
vital data of the patient.
Emergency medical systemdoes not need this much asof now in the current
scenario/form.
This allows patients to be
empowered to make adecision between what datais collected while the patient
is in the ambulance.

YEM-10Synchronizedclocks between
IoT devices

H2020 EUJ-02-2016

Time synchronization isrequired so that sensor datafrom different sensors can becorrelated by time

Old/New/
Updated
New

Core
req ?
Yes

Priority

Visual data access for end
user

New

Availability of analyticalservices
UI for controlling use ofdata
PATIENTS CAN REFUSE to
be monitored using the
remote diagnosis, etc.
BUT BASICALLY, THISMEANS THE PATIENTDOES NOT USE
EMERGENCY MEDICALSERVICE EFFECTIVELY.
Maximum clock drift(usually minute ordersuffices for bed
assignment purposes, but
milliseconds resolution isnecessary for medical
devices to havecorrelation of vital datasuch as heart beat.)
CPaaS.io

StatusHigh

Rel. Project
Objectives
O1

Done

Used for
Validation
Yes

No

MediumO1, O3

Done

No

New

Yes

low

O1, O3

Done

No

New

Yes

Medium

O3

Done

No

New

No

High

O4

Done

No

Page 56 of 70

Deliverable D2.5

Requirements Specification (V2)ID

Description

Rationale

Fit Criterion

YEM-11

Efficient queryof patient,hospital bed anddoctor data

YEM-12

Guarantees forbasefunctionality

YEM-13

Data
completenessYEM-14

Data sharing

Personalized visualizations
require efficient retrieval of
media data and processeddata from sensor streams.
Finding unused bed at
hospitals where doctors withappropriate specialization areavailable require quick searchof such data.
When communication
between the ambulance andthe hospitals is lost, thesystem downgrades to the
traditional phone-based
services.
YEM does not need the failover *IF* the communication
between the sensor devices
and collection node is lost.
Basically, the systemdowngrades to the
traditional service WITHOUTACCESS to vital data for the
remote diagnosis.
Patients want their medical
data shared between doctors
at various hospitals. Also, thestatus of beds and doctors
need to be shared among
the hospitals and dispatcher’s
office.

H2020 EUJ-02-2016

Core
req ?
Yes

Priority

Query latency in sec.

Old/New/
Updated
New

User value

New

Percentage of lost packets

Availability of data sharing
mechanisms

CPaaS.io

StatusHigh

Rel. Project
Objectives
O1, O3

Done

Used for
Validation
No

No

Low

O6

Done

No

New

No

High

O6

Done

No

New

Yes

Low

O1, O3Done
partially

Yes

Page 57 of 70

Deliverable D2.5

Requirements Specification (V2)ID

Description

Rationale

Fit Criterion

YEM-15

Semantic data
integration

Ontologies for data to besharedYEM-16

Scale tohundreds ofthousands ofpeopleYEM-17

Communication

The collected data insideambulance is currently fixeddata.
Bed and doctor availability isalso fixed information. But, ingeneral, data sharing
between diverse systems canonly efficiently be achieved if
the semantics of the data aremachine readable
The service is offered rightnow per a district that
services hundreds ofthousands of people.
However, do note that the
number of emergency
patients at a time is NOT thatlarge. The numbers of beds
are in the order of tens of
thousands and the doctors
are in the range of thousands
at most for now. The
platform needs to be able toefficiently ingest, store,
process user data andhospital bed and doctor
status.
The application collects
medical data of the patient
inside the ambulance andshare this via communication
to doctors at various
hospitals. The platform needs
to be able to efficiently
ingest, store, process patientdata.

H2020 EUJ-02-2016

Old/New/
Updated
New

Core
req ?
Yes

Priority

Number of data points
ingested per second,
processing latency,
storage footprint

New

Number of data points
ingested per second,
processing latency,
storage footprintOld

CPaaS.io

StatusLow

Rel. Project
Objectives
O4

Done

Used for
ValidationNo

Yes

Medium

O6

Done

No

Yes

Medium

O6

Done

Yes

Page 58 of 70

Deliverable

D2.5

Requirements Specification (V2)

8.6.1 Requirements Used for Validation
The following requirements are used for validating the platform. They have been selected for validation as1) they have been identified as a core requirement that should be provided by the platform, and 2) due totheir high priority. Some items are not used for validation due to reasons cited below.
8.6.1.1 YEM-1 Data collection.
This use case deals with real-time operation information of such as patients' conditions, and position of
ambulances. It is necessary to provide automatic data collection mechanism for these data.
8.6.1.2 YEM-2 Consensus for using medical and personal data by city government
The data may have direct or indirect relations with personal information of patients. Before the trial, we
need to have formal consensus with city government on the basis of official guidelines for personal data.
8.6.1.3 YEM-3 Privacy protection of patient
We must provide strong data protection mechanism such as secure communication and secure storage.
8.6.1.4 YEM-4 Low-effort for emergency medical team staff members
Emergency medical team staff members are doing very hard work for taking care of patients. It is
impossible for them to spend time and effort for the operation of this system. We must realize a good
workflow and user interface for the team staff. This is important for the system to be accepted by theworking staff members.
8.6.1.5 YEM-5 User feedback collection
User feedback is necessary for the evaluation of the use case.
8.6.1.6 YEM-6 Metadata management
Sensors are used to obtain vital data for patients. Sensor data can only be processed if it is known how
sensors were deployed, operated, to which user, event etc. the data relates, etc.
8.6.1.7 YEM-14 Data sharing
Patients want their medical data shared between doctors at various hospitals. Also, the status of beds anddoctors need to be shared among the hospitals and dispatcher’s office for emergency medical team staff
members to select an acceptable hospital. However, in Yokosuka City, hospitals cooperating in this use
case almost accept patients. Thus, in this use case, only their medical data was used for validation.
8.6.1.8 YEM-17 Communication
The application collects medical data of the patient inside the ambulance and share this via communication
to doctors at various hospitals. The platform needs to be able to efficiently ingest and process patient data.
8.6.2 Requirements NOT Used for Validation
8.6.2.1 YEM-7 Visualization of personal data
Visualization component is the front end towards end user (doctors, dispatchers, etc.) that provides themwith the up-to-date health related vital data of the patient. Except for the visual capture of the patient
using a camera, the visualization of data is not high priority.
8.6.2.2 YEM-8 Data processing
Emergency medical system does not need this much as of now in the current scenario/form.
8.6.2.3 YEM-9 Control over data collection
This is not used for evaluation due to the following reason: patients can make a decision between what
data is collected while the patient is in the ambulance.

H2020 EUJ-02-2016

CPaaS.io

Page 59 of 70

Deliverable

D2.5

Requirements Specification (V2)PATIENTS CAN REFUSE to be monitored using the remote diagnosis, etc. BUT BASICALLY, THIS MEANS
THE PATIENT DOES NOT USE EMERGENCY MEDICAL SERVICE EFFECTIVELY. The patient, if conscious, canrefuse the data collection. But so far, none has done so.
8.6.2.4 YEM-10 Synchronized clocks between IoT devices
Time synchronization is required so that sensor data from different sensors can be correlated by time.
Usually minute order accuracy suffices for bed assignment purposes, but milliseconds resolution isnecessary for medical devices to have correlation of vital data such as heart beat. However, as of now, noaccurate measurement regarding to timestamp is necessary for the type of vital data we collect.
8.6.2.5 YEM-11 Efficient query of patient, hospital bed and doctor data
Personalized visualizations require efficient retrieval of media data and processed data from sensor
streams. Finding unused bed at hospitals where doctors with appropriate specialization are available
require quick search of such data. Infrastructure was put in place, but the data from the hospitals anddoctors were not made available so far. This is beyond the control of CPaaS.io partners. Thus, this was not
used for validation.
8.6.2.6 YEM-12 Guarantees for base functionality
When communication between the ambulance and the hospitals is lost, the system downgrades to the
traditional phone-based service. This is the default operation mode.
8.6.2.7 YEM-13 Data completeness
YEM does not need the fail over *IF* the communication between the sensor devices and collection nodeis lost. Basically, the system downgrades to the traditional service WITHOUT ACCESS to vital data for the
remote diagnosis.
8.6.2.8 YEM-15 Semantic data integration
The collected data inside ambulance is currently fixed data. Bed and doctor availability are also fixed
information. But, in general, data sharing between diverse systems can only efficiently be achieved if thesemantics of the data are machine readable. But due to the relatively small fixed data set, we do not use
this as validation factor.
8.6.2.9 YEM-16 Scale to hundreds of thousands of people
The service is offered right now per a district that services hundreds of thousands of people. However, donote that the number of emergency patients at a time is NOT that large. The numbers of beds are in theorder of tens of thousands and the doctors are in the range of thousands at most for now. The platformneeds to be able to efficiently ingest, store, process user data and hospital bed and doctor status.

9 Smart Parking
In this deliverable we are introducing a new use case related with one of the most common issues that big
cities cope with daily, traffic congestion. Helping citizens in the task of finding a parking spot is therefore
an important contribution to reduce the amount of time that vehicles move along the city.
Murcia is a medium-size city in the south east of Spain with a population of 450.000 residents. This number
increases by about 5.000 residents per year, with a noteworthy distribution of people among the city
districts. Because of this and the fact that Murcia is the capital of the Murcia Region, it has seen a dramaticrise of accesses to the city centre in the last years. Day by day, commuters, tourists and families travelingby car collapse the core of Murcia, wanting to park at commerce, financial and historical areas.

H2020 EUJ-02-2016

CPaaS.io

Page 60 of 70

Deliverable

D2.5

Requirements Specification (V2)

To improve the situation, the aim of this use case is that of taking advantage of the CPaaS.io platform toprovide a service that tracks the state of the parking spots to provide the drivers with this information
beforehand, so they can better plan where they will park. This will also lead to a more fluid traffic in thecentre of the city, because there will be less drivers wandering, looking for a parking spot in areas that do
not have any available.

9.1 Application Description
Our objective is to provide an easy-to-use app which will allow the user to obtain an indication of the mostprobable area to look for a free parking spot closer to her desired destination. To do so, this app makes
use of the framework called FogFlow which is detailed in D4.1 and D4.2.

9.2 Core Functionalities and Components
According to the requirements specified in D2.1 we provide the following architecture. For this use casethe platform provides the data and their analytics capabilities in such a way that The Arrival Time Estimation
module will be able to extract the information and provide the user with the best area to find a free parking
spot.

Figure 4. Diagram of the architecture for Smart Parking

The following diagram, Figure 5, presents the different tasks comprising this use case, as well as the flowof information among them.

H2020 EUJ-02-2016

CPaaS.io

Page 61 of 70

Deliverable

D2.5

Requirements Specification (V2)Figure 5: Diagram of the tasks for the use case

Following a bottom-up approach, we can see the following tasks:
Real-time prediction task: This task corresponds to the private parking sites; whose data is available inreal time. The town will be divided in five zones, each having multiple private parking sites. A task instancewill be launched for each zone, listening to occupation changes from its parking sites, but will only publish
significant changes, i.e., only when the difference in available spots is above a certain threshold, because achange in a single parking spot will not change the behaviour of the system.
Estimation task: This task corresponds to the regulated parking zones of Murcia city. Their data is received
by the system once a day, containing all the tickets issued that day, and therefore the data is not available
in real time. Because of that, an intelligent application will predict the occupation based on the previous
data. However, the prediction should be updated daily to include the new data. This task will read the newdata, update the prediction application and then publish it so the other components can use it.
Parking Site Recommendation task: The results from the two previous tasks will feed this task, which will
be used to generate the response the user will receive.
Arrival Time Estimation task: This task is the endpoint receiving the requests by the users which areparametrized by specifying the location of the vehicle, as well as the desired destination.
This information is extended in D4.1.

9.3 Data Sets
Since this use case is new, in this section we detail the different involved datasets. The application needs
the information provided by the concessionary companies responsible for the management of private
parking sites and the regulated parking zones (RPZs). This information is therefore divided in two groups.
On the one hand, the information regarding private parking sites:-

Id: An identifier of the parking site

H2020 EUJ-02-2016

CPaaS.io

Page 62 of 70

Deliverable

D2.5

Requirements Specification (V2)-

Type: The current value for this entity is Sensor
Attributes:
o name: The name of the parking siteo geolocation: Geographical position of the parking siteo forced: This attribute can be set to establish a number of free parking spots publicly
available.
o free parking spots: The number of free parking spots.
o total parking spots: The number of total parking spots.

Such information will be transmitted using NGSI the following way:{}"contextResponses": [{"contextElement": {"attributes": [{"name": "forzado","type": "number","value": "0"},{"metadatas": [{"name": "location","type": "string","value": "WGS84"}],"name": "geoposicion","type": "coords","value": "37.9942698,-1.1294058"},{"name": "libres","type": "number","value": "113"},{"name": "nombre","type": "number","value": "Morales Meseguer"},{"name": "plazas%20libres","type": "number","value": "118"},{"name": "plazas%20totales","type": "number","value": "220"},{"name": "totales","type": "number","value": "220"}],"id": "Aparcamiento:105","isPattern": "false","type": "Sensor"},"statusCode": {"code": "200","reasonPhrase": "OK"}}]Private parking site availability
H2020 EUJ-02-2016

CPaaS.io

Page 63 of 70

Deliverable

D2.5

Requirements Specification (V2)

Detailed Description
OGD or private data
Personal Data
Hosting
Data Provider
FormatUpdate Frequency
Update Size
Data Source
SensorNumber of Sensors

Availability of 5 private parking sites. The information
contains both total amount of parking spots and thefree ones
PrivateNo
Platform
Murtrafic – Dutch weather forecast agency
JSON, XML
Every 5 min-Concesionary Company platform-unknown

On the other hand, regarding the RPZs information we have received in our platform the information about
the tickets issued the day before. Such information comprises:-

id: identifier of the ticket, e.g. Ticket:XXXXXXX.
type: for these entities the value is set to Ticket.
Attributes:
o duration: duration in seconds.
o expender: expendero date_of_issue: issued date.
o hour_of_issue: issued time.
o price: priceo payment_method: Payment option (e.g. Efectivo = Cash)o rate: rate
o validity: booked period of time e.g.12:09 – 12:54
o zone: Sector or area.

Below, you can find an example of the NGSI information per ticket.
"contextResponses": [{"contextElement": {"attributes": [{"name":"duration","type":"Integer","value":2700},{"name":"expender","type":"Integer","value":78},{"name":"date_of_issue","type":"Date","value":"01/03/2018"},{"name":"hour_of_issue","type":"Time","value":"12:09"},{"name":"price","type":"String","value":"0,3 EUR",},{"name":"payment_method","type":"String","value":"Cash",},{"name":"rate","type":"String","value":"Azul",},{"name":"validity","type":"String","value":"12:09 - 12:54"},{"name":"zone","type":"String","value":"Sector 4"}],"id": "Ticket:443994176","isPattern": "false","type": "Ticket"}}}

RPZ tickets
Detailed Description

H2020 EUJ-02-2016

Detailed information about the tickets issued by the
expenders. This information comprises, duration,
expender, date of issue, hour of issue, value, payment
method, rate, validity, zone
CPaaS.io

Page 64 of 70

Deliverable

D2.5

Requirements Specification (V2)

OGD or private data
Personal Data
Hosting
Data Provider
FormatUpdate Frequency
Update Size
Data Source
SensorNumber of Sensors

PrivateNo
Platform
EYSA – Spanish concessionary company
JSON, XML
Daily
Dynamic
Expenders-unknown

For this scenario is also fundamental the destination where the user intends to park his car.

9.4 Deployment Plan
For this use case, the deployment plan involves the following phases:
1. M18~M20: Deployment of the FogFlow framework
2. M20~M22: Integrate the instantiated components with real information about Murcia city
regarding private parking sites and RPZs.
3. M21~M24: Definition of the different tasks and workers responsible for the processing activities
achieved in the edge and cloud layer.
4. M23~M26: Development of the application
5. M24~M26: Application Validation

9.5 Requirements
Table 4 lists the updated requirements.

H2020 EUJ-02-2016

CPaaS.io

Page 65 of 70

Deliverable D2.5

Requirements Specification (V2)
Table 5: Requirements for Smart Parking

ID

Description

Rationale

Fit Criterion

SP-1

Data
collection
infrastructure

Existence of a data collection
infrastructure

SP-2

Edge
processing

SP-3

Cloud
processing

SP-4

Communicati
on

SP-5

Virtualized
services

Private parking site
info must be
provided in realtime. RPZ info isprovided at the endof the day
In the edge,
processing
capability is needed
to carry out specifictasks.
In the same sense,
complex tasks
should be achievedby virtualized
services in the cloudConnectivity
between different
players of the
FogFlow framework
must be guaranteed
Fogflow requires
the deployment of
virtualized services
in a specific server

H2020 EUJ-02-2016

Old/New/
Updated
New

Core
req ?
Yes

Priority

Existence of devices able tohandle processing tasks in the
edge.

New

Yes

Cloud services able to processcomplex tasks

New

Online availability of services anddevices

Support for virtualized services

CPaaS.ioRel. Project
Objectives
O1, O2, O3,
O4, O6

Status
Open

Used
for
validation
Yes

High

O1, O2, O3,
O4, O6

Open

Yes

Yes

High

O1, O2, O3,
O4, O6

Open

Yes

New

Yes

High

O1, O2, O4,
O6

Done

Yes

New

Yes

High

O1, O2, O4,
O6

Done

Yes

Page 66 of 70

HighDeliverable

D2.5

Requirements Specification (V2)

9.5.1 Requirements Used for Validation
The following requirements are used for validating the platform. They have been selected for validation as1) they have been identified as a core requirement that should be provided by the platform, and 2) due totheir high priority.
9.5.1.1 SP-1
Done. All data are stored and annotated in a broker. This is a basic requirement, data need to be stored
and accessible for the operators (user or analytic) to visualize and act based on the data.
9.5.1.2 SP-2
Done. Thanks to the FogFlow framework, edge nodes have been deployed according to private parking
availability and Regulated Parking Zone daily logs.
9.5.1.3 SP-3
Done. The Recommendation module is stored in the cloud to provide a recommendation to an incoming
parking area request for a connected car.
9.5.1.4 SP-4
Done. The components involved in the Smart Parking use case have been deployed using the FogFlow
framework. It also guaranteed the communication between them so as to allow a connected car to receive
the appropriate recommentadion decision.
9.5.1.5 SP-5
Done. Again, thanks to the FogFlow framework, edge and cloud tasks have been deployed using virtualized
services.

H2020 EUJ-02-2016

CPaaS.io

Page 67 of 70

Deliverable D2.5

Requirements Specification (V2)10 Summary
In this deliverable we have provided an update of the requirements of the applications based on which wedevelop the CPaaS.io platform. As the focus in the last phase of the project, is on transferability andfederation, we have revisited the requirement in particular with respect to covering cross-border aspects
that drive the federation aspects of the European and Japanese platform instances. This has for instancebe reflected by the requirement EUE-11 (Semantic data integration) and newly added requirement EUE-13(Access data from different platform instances). We also described the requirements of Smart Parking as
an additional CPaaS.io application. In section 2 we have described the new focus of the Enhanced User
Experience (MyEvents) Application that should be able to use the data collected at the Sapporo Snow
Festival 2018 stored in the Japanese CPaaS.io instance.
While the core of the requirements has been unchanged, some requirements have been updated andadded in order to reflect the experiences gained while developing the applications, receiving feedback
from stakeholders and discussing with representatives of the technical work packages within the project.
We have taken particular care to reflect scalability and privacy requirements into account and link therequirements to the project objectives.
The respective application requirements have been carefully reviewed to identify core requirements, i.e.
requirements that developers or other application stakeholders consider to be fulfilled by the platform andpossibly be reused by other applications. Furthermore, the requirements have been linked to the project
objectives and requirements used for validating the platform have been identified.

H2020 EUJ-02-2016

CPaaS.io

Page 68 of 70

Deliverable D2.5

Requirements Specification (V2)

Appendix A – Description of the fields used in the data set description
Table 6: Description of the fields used in the data set descriptions

Data Set Name
Detailed Description
OGD or private data
Personal Data
Hosting
Data Provider

FormatUpdate Frequency
Update Size
Data Source
SensorNumber of Sensors

H2020 EUJ-02-2016

A name that identifies the data set
A verbal description of the data set.
Classifies the data whether it is open governmental data (OGD) or private
data, i.e. data that is not provided by governmental institutions. Possible
values are OGD or Private data.
Indicates whether information contained in the data set identifies or could
be used to identify any individual person. Possible values are yes and no.
Indicates whether the data set is planned to be hosted by the CPaaS.io
platform or not. Possible values are platform and external.
Describes the entity that is offering the data set. This can be an open data
portal, a partner of the consortium or any other private and public entitythat provides the data. Possible values include a string that identifies thedata provider such as partner name, city name/department and may
include a URL.
Describes the technical format in which the data is provided. Possible values
include a string referencing a technical format. Examples include CSV for
comma separate value or RDF for a serialization format for data represented
in the Resource Description Format.
Describes the rate in which updates of the data sets are available. This may
be specified in Hz or by specifying a time interval between an average
update, e.g. 1 update per hour, minute or year etc.
Describe how big a single update. Possible values include bytes, Kilobytes,
etc. or a number of atomic data units such as a record, document, or triple.
Technically characterizes the source. Possible values include but are notlimited to SQL database, sensor, file.
Describes the sensor that provides the data if applicable. Possible values
are N/A if the data source is not a sensor or a string describing the sensor
including but not limited to wristband, mobile phone,
The amount of sensors used in a deployment if applicable. The field may
be extended to specify a finer deployment granularity, e.g number of
sensors per person. Possible values are integer values.

CPaaS.io

Page 69 of 70

Deliverable D2.5

Requirements Specification (V2)

Appendix B –Description of the fields in the requirements tables
Table 2 describes the fields used for the requirements. The ID, Description, Rationale and Fit Criterion are
the same as in D2.1.
Table 7: Field description of backlog items

FIELD
ID
Description
Rationale
Fit Criterion
Old/New/UpdatedCore requirement ?
Priority
Related Project
Objectives

StatusUsed for validation

H2020 EUJ-02-2016

DESCRIPTION
Each requirement is uniquely identified of the form <application_id>-<number>, e.g. forrequirement 1 of the enhanced user experience application: EUE-1
The description is the intent of the requirement. It is a statement about what the system
has to fulfil according to the rationale.
The rationale is the reason behind the requirement’s existence. It explains why therequirement is important and how it contributes to the system’s purpose.
A quantification or measurement to assess to which extent the original requirement has
been eventually implemented/taken into account within the system. In some cases only
the criteria used for quantification may be provided.
Is this an old requirement that has already been described in D2.1 in the same way, or is it
an updated requirement that already existed in D2.1 and one of the fields above have been
updated, or is it a new requirement that did not exist in D2.1
Could this application requirement be a common, application independent requirement
for the platform
Is it a high, medium or low priority requirement
Links to the project objectives
Objective 1 (O1): Develop an Open Social City Platform
Objective 2 (O2): Deploy the City Platform as a Service Solution
Objective 3 (O3): Empower the citizen to her data
Objective 4 (O4): Validate the platform with use cases providing public value
Objective 5 (O5): Develop blue prints for the adaptation and transfer of solutions to other
citiesObjective 6 (O6): Create impact in cities
Is this requirement already addressed, is it still open or hast it been descoped because it
is not a requirement any more.
Is this requirement used for validating the CPaaS.io platform ?

CPaaS.io

Page 70 of 70