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

Deliverable D2.1

Requirements Specification(V1)
Version V1.0
September 30, 2016

ABSTRACTThis deliverable specifies an initial set of requirements for the applications thatwill build on top of the CPaaS.io platform. The objective of this deliverable is (1)to define and communicate what needs to be implemented for each application,and (2) to provide input to the task of defining the platform requirements.
Consequently, it contains an initial description of each application that provides
a high level understanding of the applications and a high level architecture thatshows potential interactions with the CPaaS.io platform. Where available we also
provide a description of a user interface. For each application we describe the key
data sets and their characteristics as well as a deployment plan that provides aninitial overview of how, when and where the application will be deployed. The
actual requirements are provided as an initial backlog of user stories as known
from agile software development such as Scrum. These requirements are writtenfrom an application perspective, i.e. the user stories represent functional andpartially non-functional requirements that must be met for implementing thewhole application. In a second step, the user stories will – as part of the platform
requirements analysis – be fed into the process of identifying the actual subset of
requirements for the platform.

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

Requirements Specification (V1)Disclaimer
This document has been produced in the context of the CPaaS.io project which is jointly funded by theEuropean Commission (grant agreement n° 723076) and NICT from Japan (management number 18302).
All information provided in this document is provided "as is" and no guarantee or warranty is given thatthe information is fit for any particular purpose. The user thereof uses the information at its sole risk andliability. For the avoidance of all doubts, the European Commission and NICT have no liability in 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

H2020 EUJ-02-2016

Martin Strohbach (AGT)
Martin Strohbach (AGT), Alexander Overtoom (TTN), Noboru Koshizuka (UoT)
Marianne Fraefel (BFH), Toshihiko Yamakami (ACC)
R
Public30/09/2016
14/10/2016
Requirements, applications, data source

CPaaS.io

Page 2 of 40

Deliverable D2.1

Requirements Specification (V1)

Revision History
Rev.
0.1
0.2

Date
26/07/2016
04/08/2016

0.3

31/08/2016

0.4

16/09/2016

0.6
0.7

19/09/2016
20/09/2016

0.8

22/09/2016

0.9
0.10

23/09/2016
28/09/2016

0.11
0.12
0.13

28/09/2016
29/09/2016
30/09/2016

0.14

30/09/2016

0.15

1/10/2016

0.16

1/10/2016

0.17
0.18

1/10/2016
4/10/2016

0.19
0.20
0.21

05/10/2016
05/10/2016
06/10/2016

0.22

06/10/2016

0.23

07/10/2016

0.24

10/10/2016

1.0

14/10/2016

H2020 EUJ-02-2016

Description
TOC and document structure
Update according to meeting: renamed use cases toapplication, added responsibilities as known,
provided template for user story backlog
Application description Enhanced User Experience(Section 2)
Architecture and data sets for Enhanced User
Experience (Section 2)
Section 5 added
Deployment plan for Enhanced User Experience
added (Section 2)
Initial version of Enhanced User Experience
requirements (Appendix A)
Initial version of Abstract
TTN deployment plan added
User requirements added
Introduction added
Summary and introduction for appendix added
Amended Waterproof Amsterdam summary inintroduction
Integrated Tokyo Public transportation and Yokosuka
Emergency Medical Care
Appendix for Tokyo Public Transportation and
Yokosuka Emergency Medical Care added
Tokyo Public Transportation Scenario modified. Thishas two scenarios, added in independent sections.
Sapporo Scenario by MSJ integrated
Review of version 0.17 with comments andsuggestions
Minor comments
Replied to comments in intro section
Addressed
Toshihiko
Yamakami
review
recommendations
Added a definition of data set fields in the
introduction. Refined value perspective templates ineach section.
Addressed reviewer comments in Section 2.
Refactored time plan into deployment plan in eachsection.
Addressed reviewers comments in section 6
Added proviso to introduction of section 6
Final edits

CPaaS.io

Contributors
Martin Strohbach (AGT)
Martin Strohbach (AGT)

Martin Strohbach (AGT)
Martin Strohbach (AGT)
Alexander Overtoom (TTN)
Martin Strohbach (AGT)
Martin Strohbach (AGT)
Martin Strohbach (AGT)
Alexander Overtoom (TTN)
Martin Strohbach (AGT)
Martin Strohbach (AGT)
Martin Strohbach (AGT)
Martin Strohbach (AGT)
Noboru Koshizuka (UoT)
Noboru Koshizuka (UoT)
Noboru Koshizuka (UoT)
Marianne Fraefel (BFH)
Martin Strohbach (AGT)
Martin Strohbach (AGT)
Martin Strohbach (AGT)
Martin Strohbach (AGT)

Martin Strohbach (AGT)

Alexander Overtoom (TTN)
Martin Strohbach (AGT)

Page 3 of 40

Deliverable D2.1

Requirements Specification (V1)

Table of Contents
1

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

2

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

3

4

5

6

7

2.1

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

2.2

Architecture .................................................................................................................................................................... 10

2.3

User Interface ................................................................................................................................................................ 11

2.4

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

2.5

Deployment Plan .......................................................................................................................................................... 13

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

Application Description ............................................................................................................................................. 14

3.2

Architecture .................................................................................................................................................................... 14

3.3

User Interface ................................................................................................................................................................ 15

3.4

Data Sets ......................................................................................................................................................................... 17

3.5

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

Event Management – Tokyo Public Transportation (1) .......................................................................................... 20
4.1

Application Description ............................................................................................................................................. 20

4.2

Architecture .................................................................................................................................................................... 20

4.3

User Interface ................................................................................................................................................................ 21

4.4

Data Sets ......................................................................................................................................................................... 22

4.5

Deployment Plan .......................................................................................................................................................... 23

Event Management – Tokyo Public Transportation (2) .......................................................................................... 24
5.1

Application Description ............................................................................................................................................. 24

5.2

Architecture .................................................................................................................................................................... 24

5.3

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

5.4

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

5.5

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

Waterproof Amsterdam ...................................................................................................................................................... 26
6.1

Application Description ............................................................................................................................................. 27

6.2

Architecture .................................................................................................................................................................... 28

6.3

User Interface ................................................................................................................................................................ 29

6.4

Data Sets ......................................................................................................................................................................... 29

6.5

Deployment Plan .......................................................................................................................................................... 30

Yokosuka Emergency Medical Care ............................................................................................................................... 31
7.1

Application Description ............................................................................................................................................. 31

7.2

Architecture .................................................................................................................................................................... 32

7.3

User Interface ................................................................................................................................................................ 32

7.4

Data Sets ......................................................................................................................................................................... 33

H2020 EUJ-02-2016

CPaaS.io

Page 4 of 40

Deliverable D2.1

7.5
8

Requirements Specification (V1)

Deployment Plan .......................................................................................................................................................... 34

Summary................................................................................................................................................................................... 34

Appendix A - Backlog of User Stories .................................................................................................................................... 35
Event Management - Enhanced User Experience.......................................................................................................... 36
Event Management – Tokyo Public Transportation (YRP).......................................................................................... 37
Waterproof Amsterdam (TTN) .............................................................................................................................................. 38
Yokosuka Emergency Medical Care (YRP) ........................................................................................................................ 39

H2020 EUJ-02-2016

CPaaS.io

Page 5 of 40

Deliverable D2.1

Requirements Specification (V1)

Table of Acronyms
Acronym
LOD
ML
OGD
WP

H2020 EUJ-02-2016

Definition
Linked Open Data
Machine LearningOpen Governmental Data
Work package

CPaaS.io

Page 6 of 40

Deliverable D2.1

Requirements Specification (V1)1 Introduction
In this deliverable we provide a set of initial use cases and their requirements. Throughout the project wewill use these scenarios to demonstrate how applications can benefit from the CPaaS.io platform. These
scenarios are carefully chosen to validate that the platform can indeed support a range of diverse usage
scenarios that are of societal and commercial value. Consequently, the scenarios are used as input for therequirement analysis of the platform as carried out in WP3. In the validation phases we will use theapplication to demonstrate the federation and transfer capabilities of the platform.

Figure 1: Overview of the CPaaS.io validation concept. Cities and local as well as virtual communities provide problems defining
the requirements. The consortium provides innovative technical solutions that are implemented as part of the platform. The usecase validates the platform including the transferability between Japan and Europe. (This picture is taken from the Grant Agreement
document).

As depicted in Figure 1 we will implement 3 use cases and 5 application scenarios:

Use Case 1: Managing Fun and Sports Events. This use case addresses event management
challenges associated both with the supporting city infrastructure such as transportation as wellas with managing the event on site and enhancing the visitor and user experience. It is used as thedriving use case for the platform validation and federation capabilities and will need to fully draw
on the technical features of the platform such as citizen empowerment, cloud and edge computing,and holistic data management. In order to demonstrate not only the cross-regional, but also crossapplication use of data, three of the application scenarios will be implemented to realize thiscomplex use case. The Enhanced User Experience application in Section 2 focuses on sensor
intensive analytics to enhance people’s experience and will first be deployed in Europe. The Visitor
Experience application in Section 3 will both address logistic challenges related to large events andprovide visitor services for these events. Finally, the Public Transportation application will provide
next generation mobile transportation for all citizens. This application is further split into two subapplications. Section 4 details an application that integrates available open public transportation
data and Section 5 includes vehicle such as taxis, trucks, and utility vehicles by public and private

H2020 EUJ-02-2016

CPaaS.io

Page 7 of 40

Deliverable D2.1



Requirements Specification (V1)companies. Both the Visitor Experience and Public Transportation application will initially be
deployed in Japan.
Use Case 2: Waterproof Amsterdam. This use case emphasizes the diversity of city applications
supported by the platform. It contains a single, but highly relevant application that is concernedwith the problem that increasing amount of rainfall in Amsterdam is overloading the capacities ofthe sewage system. This use case further poses some unique demands to the platform in that it
operates an actuator mechanism.
Use Case 3 Yokosuka Emergency Medical. This is the third use case that further will demonstrate
how IoT technologies used across the city help to maintain health and welfare of citizens.
Specifically, the applications developed in this use case will aid first aiders to obtain life-saving andrelevant information when and where they are needed.

This deliverable introduces all five application scenarios in their own sections. For each application scenario
we provide an initial description of each application, a high level architecture, where available a userinterface, a list of data sets and a deployment plan. The architecture sketches an initial idea of platform
interactions and is meant to be quickly iterated in the platform requirements analysis phase.
The data set descriptions further characterize the application and provide important information withrespect to the required data management functionalities of the platform. The deployment plan provides
an initial overview of how, when and where the application will be deployed and helps to understand theschedule of the individual application deployments and their complexity.
Table 1: 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

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 andpublic entity that provides the data. Possible values include a stringthat identifies the data 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
not limited to SQL database, sensor, file.
CPaaS.io

Page 8 of 40

Deliverable D2.1

Data Set Name
SensorNumber of Sensors

Requirements Specification (V1)

A name that identifies the data set
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.

The appendix contains the list of requirements in the form of an initial backlog of user stories as known
from agile software development such as Scrum. These requirements are written from an application
perspective, i.e. the user stories represent functional and partially non-functional requirements that arenecessary for implementing the whole application. In a second step, the user stories will – as part of theplatform requirements analysis – be fed into the process of identifying the actual subset of requirementson the platform.

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 make event visits for participants 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 in orderto learn about the activities of event participants. Event participants may include members of the audience,but also performing artists or athletes. For instance AGT has previously equipped referees and cheerleaders
in basketball matches with wearable sensors and created content based on the analysed data for
consumption on site and for distribution via TV broadcasting, social media and other digital distribution
channels1. Furthermore the application uses sensor deployed at the venue to measure and analyse fanbehaviour and engagement.
We will extend this work and initially focus on active participants that are equipped with wearables. As adriving event, we plan to deploy our sensors and analytics at Color Run events2. The Color Run is a global
event series that takes place in many cities around the world including Tokyo and Amsterdam. At the Color
Run, participants run a distance of five kilometres and are being sprayed with color on their way. As theevent focuses on health and fun rather than athletic achievements the aim for the participants is to reachthe finish line rather than comparing the running time with other runners. At the finish line the runners
gather to party and dance to music getting sprayed with more color.
AGT will draw from its analytics portfolio to visualize the user’s personal data for each event. For instance,
wristband data can be used to show trajectories, effort (heartbeat) and excitement levels during the events

1http://www.euroleague.net/final-four/berlin-2016/news/i/6vokoibj5fsgqg4q/heed-the-event-platform-based-joint-venture-

between-wme-img-and-agt-international-makes-first-official-foray-into-sports
2 http://thecolorrun.com/
H2020 EUJ-02-2016

CPaaS.io

Page 9 of 40

Deliverable D2.1

Requirements Specification (V1)and video analytics solutions can be used to create dynamic, geo-linked colour maps that can be linked torunners’ “sensor trails”.
The frequency of events in both Europe and Japan renders this application useful to validate the federation
concepts of the CPaaS.io platform. As this application relies on the collection and management of personal
data it is paramount that it protects the privacy of the event participants and uses CPaaS.io’s citizen
empowerment features developed in WP 5.
2.1.1 Value Perspective
In the following tables we describe two values perspective. Table 2 lists the various user and stakeholder
groups that benefit from the application and list for each group the benefits they have by using theapplication. Table 3 in turns takes the perspective from the platform and lists for each key concept thepotential benefit the CPaaS.io platform can provide to the application.
Table 2: The benefits the application provides to the different user groups

User Value Perspective
Event Participants
Recorded personal experiences of visited events
Event Organizers
Value-added services attracting more participants
Table 3: The benefits the CPaaS.io platform provides to the application

Platform Value Perspective
Use of IoT
Data collection and integration of wearable sensor data, real-timeTechnologies
analysis of sensor streams
Use of Open
Integration of geospatial data for user visualizations
Governmental Data
Use of Linked Data
Metadata descriptions of sensors, integration with related data sets
Big Data Analysis
Re-use of ML and analysis toolkits
My Data Approach
Transparency and control over use of personal data

2.2 Architecture
Figure 2 shows an initial version of the high level components and their envisioned interaction with the
CPaaS.io platform. It contains the following componentsData Collection is responsible for collecting all data necessary for this application as detailed in
Section 2.3. This includes primarily collecting data from wearables and other sensor deployed at
the event, but may also include other data from third parties such as meta information about theevent. Other metadata includes data related to the deployment that will be retrieved from thedeployment knowledge base developed in WP6 and required user information. The data collection
component registers data at the CPaaS.io platform, but may also retrieve data from the platform
provided by other applications or data providers, e.g. data providers for the event metadata.
Analytic Services will use raw data from wearables, environmental sensors and other data tocompute personal event data. The component encapsulates various data aggregation and machinelearning modules.
Personal Data Visualization is the front end component that offers users to view their data per
event using different visualizations. This front end should provide means for controlling what datais collected and how (e.g. update frequency). In particular it should provide feedback about theminimum settings for data collection that is required for presenting useful analytics results.

H2020 EUJ-02-2016

CPaaS.io

Page 10 of 40

Deliverable D2.1

Requirements Specification (V1)

Figure 2: Enhanced User Experience: Initial version of the high level application architecture.

2.3 User Interface
The user interface will be provided as a web interface that provides access to personalized visualizationsof individuals. There will also be a mobile version, either as mobile web application or as native mobileapp.

2.4 Data Sets
In this section we briefly describe the data sets that will be used in this application. This list reflects theinitial data sets that we plan to use for this application and is therefore subject for change.
The data described here is used for analytics and generating personalized visualizations. While all of thedata described below constitutes personal data collected primarily from wearables not every data set isused for each users to the same extent. Whether a data set is stored and used for processing, depends on
several factors, such as
Sensor Deployment: Has the respective sensor been deployed? E.g. did the event participant wear
a device that has a sensor for measuring heart beat information?
User Control: Did the event participant allow the recording of the respective data in the way
described in the data set? The application foresees that the end user has full control over what datais collected and in what way. This means that a user could decide to not collect heart beat data, or
lower the update frequency to a few seconds. Of course this may have implications on theinformation that can be derived from the data.
Data Quality: Is the data of sufficient quality in order to be presented to the user? Among otherfactors data quality can be assessed by having knowledge about the sensor accuracy, the update
frequency or data set size. For instance wearables differ widely in the accuracy of their heart rate
sensors. The data set size can have an impact on providing optimised models for machine learningor may not cover relevant time spans.
Biometric data
Detailed Description

H2020 EUJ-02-2016

We will collect a range of biometric measurements fromwearables such as wristbands, chest straps and smart
sportswear that provides biometric measurements including
heart rate, breathing rate and galvanic skin response, burned
calories measurements and skin temperature.
CPaaS.io

Page 11 of 40

Deliverable D2.1

Requirements Specification (V1)

Biometric data
OGD or private data
Personal Data
Hosting
Data Provider
FormatUpdate Frequency
Update Size
Data Source
SensorNumber of Sensors
person
GPS Traces
Detailed Description
OGD or private data
Personal Data
Hosting
Data Provider
FormatUpdate Frequency
Update Size
Data Source
SensorNumber of Sensors
personMotion Data
Detailed Description
OGD or private data
Personal Data
Hosting
Data Provider
FormatUpdate Frequency
Update Size
Data Source
SensorNumberpersonof

Sensors

Step Counts
Detailed Description
H2020 EUJ-02-2016

PrivateYes
External
AGT
JSON
up to every 200ms~1 KB
SensorWristband, chest strap, smart shirts
per ~6

GPS traces include positional data including altitude
information as delivered by GPS devices.
PrivateYes
External
AGT
common GPS formats (GPX, KML, CSV, NMEA)
Up to 1s
< 1KB
SensorGPS sensor in wristbands and mobile phones
per 1-2

Motion data that measures hand and body movements
based on accelerometer and gyroscope sensors
PrivateYes
External
AGT
JSON
Up to every 16 ms~ 200 byte per sensor reading
Sensors
Accelerometer and gyroscope sensors of mobile phones,
wristband and other wearables
per 2-3This data set contains step counts.
CPaaS.io

Page 12 of 40

Deliverable D2.1

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

OGD or private data
Personal Data
Hosting
Data Provider
FormatUpdate Frequency
Update Size
Data Source
SensorNumber of Sensors
personRequirements Specification (V1)

PrivateYes
External
AGT
JSON
Up to 1Hz
~ 200 byte per sensor reading
Sensors
Step count measurement of wristband
per 1-2

This data set environmental data such light intensity andbarometric pressure. The data is primarily collected fromwearable sensors.
PrivateYes (tbc)
External
AGT
JSON
Up to 1Hz
~ 200 byte per sensor reading
Sensors
Sensors in wristband
per 1-2

2.5 Deployment Plan
In the simplest case a deployment of the enhanced user experience application consists of equipping
participants with wearables that provide their data in real-time to the data collection platform for further
processing. Additionally an event site or venue may be equipped with further sensors such as cameras or
microphones.
AGT has already deployed sensors on a group of 8 participants during the Color Run in Utrecht, The
Netherlands on 11th September 2016. The purpose of this deployment was to compare wearable device
technologies suitable for the event type and validating the analytics. Data using the sensors describedabove has been used for both during the 5 kilometre run and the after run party. For obtaining groundtruth for our biometric data AGT also used video recordings of the 8 participants. The data collected at thisevent will provide the basis to develop the initial set of services for the first prototype (Deliverable D2.2,
due December 2016).
The enhanced user experience application will be iteratively developed and incrementally use platform
components and concepts. In alignment with the project plan we are planning to deploy and evaluate thefirst prototype at another Color Run event early next year. For instance, we are considering the Color Run

H2020 EUJ-02-2016

CPaaS.io

Page 13 of 40

Deliverable D2.1

Requirements Specification (V1)in Amsterdam that will take place on the 28th of May 2017. The plan for developing the Enhanced User
Experience application in the first year is as follows:

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)

For the second and following prototypes we would like to gradually extend the application to other event
types and locations in Japan.

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
We deliver mobile applications “Kokosil Sapporo” that provide information of sightseeing spots,
restaurants, hotels, public transportation and events for tourists. By leveraging a geo-spatial position
recognition system, tourists can get information at the point where they need it in a timely manner. They
can drill down on spot information by tapping an icon on the map made available in the mobile application.
By tapping the “go to this place” button, a navigation service from where they are to the place of interest
is made available on Google Maps. Since information is translated in multiple languages, users can selecta language in the language settings for their mobile devices.
Sapporo Snow Festival Guide is one of the mobile applications that provide event information to visitors.
The Sapporo Snow Festival is a very large event that is visited by 3 million people in February every year.
This application will deliver relevant event information such as location and additional information on snow
sculptures, shops, toilets, and tour bus meeting points.
We are going to develop an application for The Asian Winter Games held in February 2017 as well. This
will provide information on the game schedule and locations, rules, stadium facilities and transportation
services.

3.2 Architecture
Figure 3 shows an initial version of the high level components and their envisioned interaction with the
CPaaS.io platform. It contains the following components:

The Open Data Portal is built on CKAN and Microsoft Azure. The platform provides Open Data as
well as guidance for application developers. Developers can use industry standard tools including
an API defined by the Ministry of Internal Affairs and Communications and a vocabulary defined by
the Information-technology Promotion Agency.
Mobile applications leveraging open data are implemented on YRP UNL’s Kokosil and uID 2.0.
Kokosil receives a ucode3 as the position ID from the BLE (Bluetooth Low Energy) markers installedat information signage. Then Kokosil sends the ucode to uID 2.0, which manages the ucode system

3 “ucode” is an ID system approved as ITU-T’s International Standards H.642.1.

H2020 EUJ-02-2016

CPaaS.io

Page 14 of 40

Deliverable D2.1

Requirements Specification (V1)and related data, and gets information connected with the ucode. This mechanism can recognize
the position of the Kokosil user more precisely than GPS in particular, whether it is indoor oroutdoor. The information provided by Kokosil is automatically translated to multiple languages byMicrosoft Translator.
Apps for Sapporo
Tourist Guide(Sapporo Snow Festival,
Asia Winter Sports Games)

U2 Open IoT Platform w/t MS Azure for Sapporo Open Data
Data from Many SourcesSportsdata

Transport
ation Data

Hotel
Data

Restaurant
Data

GIS
Data
(Map)

Tourists
Data

Figure 3: Visitor Experience: Initial version of the high level application architecture.

3.3 User Interface
The user interface will be provided as mobile web applications (Kokosil) for iOS and Android devices. Those
screen shots below are sample user interface.

H2020 EUJ-02-2016

CPaaS.io

Page 15 of 40

Deliverable D2.1

Requirements Specification (V1)

Figure 4: Tourist information service with geo spatial position recognition

Figure 5: Sports event information

H2020 EUJ-02-2016

CPaaS.io

Page 16 of 40

Deliverable D2.1

Requirements Specification (V1)

Figure 6: Public Transportation Information

3.4 Data Sets
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
H2020 EUJ-02-2016

CPaaS.io

Page 17 of 40

Deliverable D2.1

Requirements Specification (V1)

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

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

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

Snow Festival
Detailed Description
OGD or private data
Personal Data
Hosting
Data Provider
FormatUpdate Frequency
Update Size
Data Source
SensorNumber of Sensors
Stadium Data
Detailed Description
OGD or private data
Personal Data
Hosting
Data Provider
FormatUpdate Frequency
H2020 EUJ-02-2016

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

Location, facilities and drawing of stadiums
OGD
No
Sapporo Open Data Association
Sapporo City
PDF, HTML, CSV, JPEG
YearlyCPaaS.io

Page 18 of 40

Deliverable D2.1

Update Size
Data Source
SensorNumber of Sensors
Train & Bus Data
Detailed Description

Requirements Specification (V1)

N/A
Web, Paper
N/A
N/A

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

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
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
File
Ucode marker
11

H2020 EUJ-02-2016

CPaaS.io

Page 19 of 40

Deliverable D2.1

Requirements Specification (V1)

3.5 Deployment Plan
We will start 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.

4 Event Management – Tokyo Public Transportation (1)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
Public transportation data is highly public in nature, and much of the public transportation services areoperated by the public sector and private companies. Today, they are providing information services suchas transfer guidance services based on timetables, and operational information services such as delays andservice troubles. For buses, some operators are providing location information and operational informationin real time by so-called bus location systems.
Tokyo and other mega-cities have huge and complicated networks of public transportation consisting of
hundreds of railway stations, thousands of bus stops and routes, many operators, and so on. In this case,open data is the best and only approach for providing integrated information about public transportation
networks.
On the other hand, for monitoring real-time public transportation information such as location of trains
and/or busses, we also need IoT technologies on top of open data. So, integrated public transportation
information services are good use cases for using both open data technologies and IoT technologies. For
example, in this project, we use an RDF model based on the LOD technology for the data model, the ucode
system developed by Ubiquitous ID Center4, SPARQL and RESTful API with JSON format, and a special new
vocabulary for the expression of public transportation data.
This use case trial shall be performed in Tokyo Area with the support of the "Association of Open Data for
Public Transportation" (ODPT)5. http://odpt.org/). As of January 2016, the association has 39 members.

4.2 Architecture
The following figure is the architecture plan overview of the public transportation application of CPaaS.
We will use the CPaaS.io platform for the "information distribution/collaboration platform" portion in thefollowing figure.

4 http://uidcenter.org
5 http://odpt.org

H2020 EUJ-02-2016

CPaaS.io

Page 20 of 40

Deliverable D2.1

Requirements Specification (V1)

Figure 7: Public Transportation: Initial version of the high level application architecture.

4.3 User Interface
Two user interfaces will be provided: one for end users of the information service and one for developers.
The end-user interface will be provided as a mobile web application. Figure 8 and Figure 9 are prototype
images of the end-user interface of our public transportation information services using open data and/or
private data.

Figure 8: Prototypes of end-user interface of public transportation information services

H2020 EUJ-02-2016

CPaaS.io

Page 21 of 40

Deliverable D2.1

Requirements Specification (V1)

Figure 9: Prototypes of large screen view of end-user interface of public transportation information services

The user interface for software/service developers, will be provided as web interface, i.e. “Developers' site”.
Figure 10 shows a prototype of the developers' site.

Figure 10: Prototype of the developer user interface of the public transportation application

4.4 Data Sets
We will collaborate with the “Association for Open Data of Public Transportation”. We will also have support
from the Ministry of Land, Infrastructure, Transport and Tourism which releases many kinds of open datafor public transportation. In our application, we will use data sets as summarized in the following table.
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.
H2020 EUJ-02-2016

CPaaS.io

Page 22 of 40

Deliverable D2.1

Requirements Specification (V1)

Tokyo Public Transportation Data
(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, andmany 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 estimatedto be relatively 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
SensorNumber of Sensors

Location sensors of trains, GPS for bus locations, etc.
Hard to count/ hard to estimate (To output the data, all train
and bus cars are using sensors.)

4.5 Deployment Plan
We have already been organizing "Association of Open Data for Public Transportation (ODPT)", which has
more than 50 members including railway companies, bus companies, Japan Air Line, All Nippon Air Line,ICT companies such as Fujitsu, NEC, Google, and Microsoft. We will collaborate with this association forthe deployment of the result of this project.
As the first step, we are planning to start public transportation open data services in Tokyo. The final target
year is 2020, in which Tokyo Olympic and Paralympic Games will be held in Tokyo. For the next step, we
will provide SaaS for public transportation for many satellite cities in Japan.
This public transportation application scenario is planned to be experimented in the third year of thisproject. So, the development and experiment plan is as follows:

M01~M12: Requirement analysis and service/system design
M13~M21: System and service development
M21~M27: Experiment

H2020 EUJ-02-2016

CPaaS.io

Page 23 of 40

Deliverable D2.1

Requirements Specification (V1)5 Event Management – Tokyo Public Transportation (2)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 ensuring reliable transportation of a wide
range of vehicles in the city including for instance utility vehicles by public and private companies.

5.1 Application Description
A city infrastructure for transportation includes buses, trucks, taxis, and utility vehicles by public and privatecompanies. Reliable transportation systems require both, consumer-based and operator-based services. It
is important for cities to manage the smooth coordination of both types of transportation services. It
should orchestrate various types of city information in order to operate a wide range of vehicles in the cityarea.
In order to facilitate the efficient and reliable transport operation, it is necessary to incorporate vehicle
locations, routes and plans, driver information and external information (such as weather, traffic jams) in atimely manner
Using the well-designed city information infrastructure, this trial case will be performed in Tokyo area.

5.2 Architecture
The following plan depicts the architecture plan overview of the vehicle transportation application of
CPaaS.io. We will use the CPaaS.io platform for the underlying platform layer to support orchestration andintegration of the collections of vehicle transportation and management services.

Driver guidance(plan,location, ..)External source(traffic jams,
weather forecast, …)

Operation information(Routes, plans,
backups, ..)Tokyo Vehicle Transportation
CPaaS.io platform

Figure 11: Vehicle Transportation: Initial version of the high level application architecture.

H2020 EUJ-02-2016

CPaaS.io

Page 24 of 40

Deliverable D2.1

Requirements Specification (V1)

5.3 User Interface
The user interface will be provided as mobile web application that provides driver assistance of vehicletransportation. There will also be an integrated web application to incorporate the real-time operation,
pre-defined routes and plans, real-time plan updates, and road information such as traffic conditions andweather forecast.

5.4 Data Sets
There are four types of data:Operation plan
Operation logs
External information in relation to operation: weather forecast, traffic conditions
Operation plan
Detailed Description
OGD or private data
Personal Data
Hosting
Data Provider
FormatUpdate Frequency
Update Size
Data Source
SensorNumber of Sensors

Routes, delivery time and place, contact addresses, driver
information
privateContact addresses, driver information
External
Operation companies
JSON
Daily (with some irregular updates)
KB
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

Traffic condition
Detailed Description
OGD or private data
Personal Data
HostingTraffic conditions and road status on transportation paths
privateNo
External

H2020 EUJ-02-2016

CPaaS.io

Page 25 of 40

Deliverable D2.1

Requirements Specification (V1)

Data Provider
FormatUpdate Frequency
Update Size
Data Source
SensorNumber of Sensors

Service providers
To be investigated
1 per 10 minutes
10 KB
Service providers
Not known
Not known

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

Weather forecast of transportation paths
OGD
No
External
Service providers
To be investigatedHourly10 KBService providers
Not known
Not known

5.5 Deployment Plan
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 will be 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.
This vehicle transportation use case is planned to be experienced in the third year of this project. The
development and experiment plan is as follows:

M01-M12: Requirement capturing and service/system design
M13-M21: Service and system development, feasibility analysis of infrastructure configuration
M22-M27: experiment and evaluation

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.
H2020 EUJ-02-2016

CPaaS.io

Page 26 of 40

Deliverable D2.1

Requirements Specification (V1)

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.
At the time of submitting this deliverable, The Things Network is negotiating with its local partners on aformal collaboration for development of this application. Waternet, the local water management company,
is a required partner, as they are problem owner and provide data and infrastructure for both development
and implementation of the application. If this collaboration does not succeed, The Things Network will not
be in the position to further pursue this application. It will then choose to continue the back-up use
application as input for the CPaaS.io project. This application is about smart parking of cargo trucks
together with the Port of Amsterdam. The project plan for this application has been formalised already andthere is commitment from the problem owner, so this alternative offers a reliable contingency plan. Clarity
on the collaboration with Waternet is expected in October 2016, so minimal impact on other deliverables
is expected.

6.1 Application Description
As research shows, extreme rainfall is becoming fiercer and will occur more frequently. Heavy rains are
already causing occasional flooding and water damage in the city of Amsterdam. If the city does not adjust
to the increasing intensity, the nuisance and damage will only increase in the future. Because the sewerage
has not been designed for these enormous amounts of water, measures will have to be taken above groundin order to cope with peak loads. It has become clear that relatively simple large surfaces such as residential
rooftops in the private domain may play a role in the water management.
6.1.1 Use case
IoT has the potential to help absorb rainwater at micro scale, slowly, and in a controlled manner throughthe use of water buffers – containers that collect, store and discharge beyond 1.000 litres of water per
instance. These can be rooftops, rain barrels or underground tanks.
Roughly speaking, a solution has to deal with information from three different areas: 1. the private domain,
2. the public domain and 3. the weather / 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 takes into account to the limitations of theexisting water management infrastructure. The buffers will be productised for the use in residential andcommercial areas. Main premise is that an owner of a smart rain barrel can determine to what extent he /she wants to connect and share on the public network and how permission is given to be overruled by athird party such as Waternet (Amsterdam regional parastatal water management company) in case ofpredicted extreme rainfall or drought.
Below are a few design considerations for the smart buffer (hereafter called ‘device’):Devices feature one or more sensors (e.g. to measure filling levels of buffer) and are equipped witha LoRa module (PHY layer) to communicate wirelessly using the open source LoRaWAN protocol.
o Free to use and abundant LoRa connectivity is already present in the pilot areas
o The LoRaWAN specs are suited for this use case, as it requires long battery life, little
investments in infrastructure and only low data rates
Devices feature an actuator that can be used to collect water into and release from the buffer. The
actuation part of the application operates valves on the device which will control water inlet andwater outlet.
Device owners are able to individually fill/empty a buffer through an app

H2020 EUJ-02-2016

CPaaS.io

Page 27 of 40

Deliverable D2.1







Requirements Specification (V1)

Weather data can be fed into the system to determine the necessity of collecting or releasing water.
This data may be supplemented with data from other sources such as sewerage filling degree, soil
hydration, ground water levels and water infiltration rates, etc.
The system will allow for a combination of autonomous and manual control – in case of
emergencies, an authority like Waternet can take control of the actuators. Owners can howeverdetermine the degree of control they are willing to transfer (e.g. ranging from fully to semiautonomous control)
Machine learning may be applied for pattern recognition to optimise the network of buffers

This application will comprise both a software and hardware development, as it concerns a non-existentproduct and non-existing sources for data that serve as input and output for CPaaS.io.
6.1.2 Value Perspective
In the following tables we describe two values perspective. Table 4 lists the various user and stakeholder
groups that benefit from the application and lists for each group the benefits they have by using theapplication. Table 5 in turns takes the perspective from the platform and lists for each key concept thebenefit the CPaaS.io platform provides to the application.
Table 4: The benefits the application provides to the different user groups

User Value Perspective
Home owner or Use the excess water collected as input for the ‘grey water system’ or forbuilding
owner the garden/parks
who owns a buffer Entertainment: gamification of water collection and release andvisualised impact to bigger system
Waternet – water
Centrally and (semi-)automatically managing of water release to
management
sewerage infrastructure, taking pressure off the system.
company
Muncipality – dept
Fewer floodings and hinderance for properties and trafficof infra and waterBest practice and benchmarking towards other cities
management
Table 5: The benefits the CPaaS.io platform provides to the application

Platform Value Perspective
Use of IoT
Centralised storage and control over data streams of various sources
Technologies
Use of Open
Ability to harmonise data from different governmental institutions
Governmental Data
Ability to include location bound data
Use of Linked Data
Not applicable
Big Data Analysis
Ability to add analytics for pattern recognition and (semi-)automatedoperation of the buffer network
My Data Approach
Not applicable

6.2 Architecture
Figure 12 shows an initial version of the high level components and their envisioned interaction with the
CPaaS.io platform. It contains the following components:

H2020 EUJ-02-2016

CPaaS.io

Page 28 of 40

Deliverable D2.1

Requirements Specification (V1)

Figure 12: Rain Proof Amsterdam: Initial version of the high level application architecture.

6.3 User Interface
The user interface for the end user (owner of the rain buffer) will be provided as mobile web application
to operate the buffer and configure settings. There will also be a network operations centre web interface
with aggregated, real time information about water situations (supply and demand) across the city andcontrols to operate the rain buffers.
Thirdly, the hardware components that need to be developed may also have a user interface. The rain
buffers, whether a smart rooftop, rain barrel or underground container, all need to be equipped withhardware in order to gather data and potentially also actuate the device. The devices will be operated
through digital commands, but a physical/mechanical fall back scenario also needs to be provided. Thismeans a control panel will be part of the device.

6.4 Data Sets
We use the following types of data:
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
2. 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 fromthis data to get data on local water infrastructure and weather.

H2020 EUJ-02-2016

CPaaS.io

Page 29 of 40

Deliverable D2.1

Weather data
Detailed Description
OGD or private data
Personal Data
Hosting
Data Provider
FormatUpdate Frequency
Update Size
Data Source
SensorNumber of Sensors
Water buffer filling degree
Detailed Description
OGD or private data
Personal Data
Hosting
Data Provider
FormatUpdate Frequency
Update Size
Data Source
SensorNumber of Sensors

Requirements Specification (V1)

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, undergroundstorage)
PrivateYes
External
TTN / Waternet
JSON
Hourly or instantly with sudden increasing levels
10b
Sensors
Water sensor
1 per buffer

Municipality water infrastructure
Detailed Description
Geographical data on water infrastructure depicting capacityand ground water levels
OGD or private data
OGD
Personal Data
No
Hosting
Platform
Data Provider
Waternet
FormatXML
Update Frequency
HourlyUpdate Size
1kb
Data Source
Sensors, maps
Sensor
Water sensor
Number of Sensors
unknown

6.5 Deployment Plan
The Things Network will develop this use case together with Water Management company Waternet.
Waternet is launching a project called Rainproof Amsterdam, which pursues the objectives as stated above.
H2020 EUJ-02-2016

CPaaS.io

Page 30 of 40

Deliverable D2.1

Requirements Specification (V1)

The project will bring together different partners in the value chain of this application, from interest groups
who represent users and problem owners, to hardware engineers, product developers and softwaredevelopers. The Things Network is currently in the process of aligning project partners. The development
is an iterative process, so the below high level planning will show overlap between stages.


M01~M12: Requirement analysis and service/system designo Align all stakeholders and receive contractual commitment from Waternet for thedevelopment of the use case (M04-M05)
o Investigate areas in the city that dictate the highest urgency or best applicability for a pilot
M03~M18: System and service developmento Develop a smart, connected hardware prototype in lab setting.
o Integrate prototype on The Things Network backend.
o Set up a physical LoRa network in the pilot area by placing gateway on rooftop in pilot areao First and second release prototype
M06~M28: Experiment and evaluationo Test of first and second releaseo Develop 10 more hardware prototypes to be deployed and tested in real life, outdoor
setting.
o Deploy prototypes in existing rain buffer projects in business district in Amsterdam (ZuidAs
area).
o Third release prototype

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

7.1 Application Description
To maintain the health and welfare of citizens, and to aid them in emergencies such as accidents or natural
disasters in particular, emergency medical service is important.
Medical care professionals always race against time in emergency medical practice. YRP UNL has beendeveloping an Emergency Medical Service Support System, which transmits the real-time location
information of ambulances and images of patients to emergency hospitals via the tablet devices and IP
cameras placed in ambulances. With this system, emergency wards of hospitals can learn about theconditions of the patients in advance and get ready to receive them smoothly. This Emergency Medical
Service Support System has been used for two years in the city of Yokosuka, Japan.
Also, in the disaster-affected area, Triage Support System shares the triage levels of injured and sick people
among medical professionals and rescue teams in real time and supports the smooth emergency rescue
and medical care on site with active RFID tags that use Bluetooth Low Energy. Active RFID triage tags
attached to injured and sick people allow medical care staff to learn the real–time state of the rescue siteby constantly transmitting the triage levels of the patients by radio wave. The information is consolidated
to give an overview of the rescue site.
Emergency medical service is made possible by people of rescue teams on ambulances, at hospitals, andat dispatching headquarters, and by their teamwork. Information sharing among them is very important

H2020 EUJ-02-2016

CPaaS.io

Page 31 of 40

Deliverable D2.1

Requirements Specification (V1)to provide smooth emergency medical care. YRP UNL has been developing the system to collect the
information from emergency hospitals and ambulances and share it among them and headquarters.
The Japanese-side consortium intends to enhance and extend the existing services to take full advantageof the new sensors, new networking technologies, and emerging CPaaS.io platform architecture to add
new services and application to the existing system in this project for the benefit of citizens in Yokosuka
and everywhere. The emergency medical staff of the City of Yokosuka where YRP's headquarters is locatedwill help the consortium to carry out new prototype study there.

7.2 Architecture
The following figure is the architecture plan overview of Yokosuka Emergency Medical Service applicationof CPaaS.

Figure 13: Emergency Medical Care High Level Architecture

7.3 User Interface
The user interface for doctors and emergency medical service staff members will be provided as web
application for mobile phones or tablets.

H2020 EUJ-02-2016

CPaaS.io

Page 32 of 40

Deliverable D2.1

Requirements Specification (V1)

Figure 14: Visualisation of end-user interface of emergency medical information service

Doctors in emergency hospitals can see the location and movement of ambulances while they are heading
to the hospitals.

Figure 15: large screen view of user interface of emergency medical information service

7.4 Data Sets
In our project, we will use data sets as summarized in the following table.
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
H2020 EUJ-02-2016

CPaaS.io

Page 33 of 40

Deliverable D2.1

Data Provider
FormatUpdate Frequency
Update Size
Data Source
SensorNumber of Sensors

Requirements Specification (V1)ucR (ucode Relation) format (RDF + ucode in JSON format)
Real-time Update
New real-time data is appended to (old) existing data.
Emergency Service Team and Emergency hospitals of City of
Yokosuka
All ambulances in Yokosuka City are equipped with sensors
such as cameras (image sensors) and GPSs (location
sensors).
In triage system, a triage tag works as a patient's locationand medical condition indicator.
More than 100 sensors will be used.

7.5 Deployment Plan
Presently, we are starting collaboration with Yokosuka City Office and all emergency hospitals in Yokosuka
Cities. If our project can bring good results, we will make marketing effort for the deployment of our system
in Yokosuka City. This is the first step. For the next step, we will extend the market to the Miura Peninsula,a region which includes Yokosuka City, Zushi City, Kamakura City, Miura City, and Hayama Town. These cityand town halls are collaborating and they often adopt common municipal service systems as standard.
After that, we will try to deploy our system across Japan.
This Yokosuka emergency medical service use case is planned to be experimented in the 2nd year of thisproject. So, the development and experiment plan is as follows:

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

8 SummaryIn this deliverable we have described 5 application scenarios and their requirements that will drive thedesign and implementation of the CPaaS.io platform. For each of the application scenarios we haveprovided a high level architecture, where available a user interface, a list of data sets and a deployment
plan.
The architecture sketches an initial idea of platform interactions and is meant to be quickly iterated in theplatform requirements analysis phase. The architectures are expected to change considerably throughout
the course of the project. For instance we expect that some of the components that are currently
considered to be part of the application may indeed be offered by the platform. Here is a summary of
initial observations across all the application architectures:All applications are concerned with data collection. While the data collection subsystems certainlycontain application specific components, e.g. reading data from wearable sensors, we would expectthat the platform provides a capability to ingest data from various sources. At the very minimum
level however the platform must offer a capability to register data sources so that data can be used
across applications.
Most of the applications use a data analysis component. This component varies strongly fromapplication to application with respect to both how data is processed and how fast it needs to be

H2020 EUJ-02-2016

CPaaS.io

Page 34 of 40

Deliverable D2.1



Requirements Specification (V1)

processed. Processing may include simple analysis using aggregations of the original data or
involve complex machine learning algorithms. With respect to the speed of processing, some
applications such as the Enhanced User Experience, use machine learning algorithms and ultimately
require low latencies which may require the need of complex event processing infrastructures. Asa next step we will identify what infrastructure components and possibly analytic toolboxes should
be provided by the platform.
Some of the applications such as Waterproof Amsterdam require actuation services. There may
be a case that the platform provides a capability to manage access to various actuators distributedin the city.
Most of the use cases require that the platform manages and registers users. For instance theapplication scenarios within the event management use case provide personalized services.

As of now we have identified 24 data sets. Across the applications the data is diverse including structured
sensor data, maps and video data originating from both open governmental and private data sources. We
also have varying data formats including for instance JSON and CSV and data that is already provided as
RDF triples as in the case of the Tokyo Public Transportation application scenario or the Emergency Medical
Care application. This means that we need to transform or annotate non-RDF data sources in order tofacilitate semantic data integration. Update frequencies also vary significantly between 16ms and yearly
updates which shows that the data needs to be ingested in high rates.
The deployment plans of the individual applications show the progress of the planning andimplementation of the application scenarios. For the Enhanced User Experience use case, an initial datacollection in order to evaluate the potential concrete services has already been executed. The services for
the Sapporo Visitor Experience will be provided in February 2017. The deployment of the Tokyo Public
Transportation application scenario is done in collaboration with 50 members including key stakeholders
and global IT companies such as Fujitsu, NEC, Google and Microsoft and planned for the third year of the
project. The Waterproof Amsterdam use case addresses a pressing problem for the city of Amsterdam andprogress is ensured as TTN is seeking collaboration with Waternet as a key partner targeting a first
prototype in Q4 2016. Finally, for the Emergency Medical Care use case there is already a prototype thatwill be deployed in the second year of the project.

Appendix A - Backlog of User Stories
In this appendix we provide for each application an initial set of requirements as a backlog of user stories.
The requirements are consumed by the requirements analysis task of WP 3 and also constitute a list of
epics that can further be broken in smaller user stories that will be implemented during the implementation
phase. The requirements have the format as detailed in Table 6. The list of requirements for the Sapporo
Visitor Experience will be provided in conjunction with the deliverable D2.2.
Table 6: Field description of backlog items

FIELD
ID
Description
Rationale

H2020 EUJ-02-2016

DESCRIPTION
Each requirement is uniquely identified of the form <application_id>-<number>, e.g.
for requirement 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.

CPaaS.io

Page 35 of 40

Deliverable D2.1

Requirements Specification (V1)

Fit Criterion

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.

Event Management - Enhanced User Experience
ID
EUE-1

Description
Data collection
infrastructure

Rationale
All services require the collection ofreal-time data

EUE-2

Metadata management

Sensor data can only be processed if it
is known how sensors were deployed ,operated, to which user, event etc. thedata relates etc.

EUE-3

Visualization of personal
data

EUE-4

Data processing

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
processing of raw sensor data
This application offers personalized
services.

User Registration andManagement

EUE-5

Control over data collection

EUE-6

Synchronized clocks
between IoT devices

EUE-7

Efficient query of user data

EUE-8

Guarantees for basefunctionality

EUE-9

Data completenessEUE-10

Data sharing

H2020 EUJ-02-2016

This allows users to be empowered tomake a decision between what data iscollected and what services they canuseTime synchronization is required sothat sensor data from different
sensors can be correlated by time
Personalized visualizations require
efficient retrieval of media data andprocessed data from sensor streams
When local (BT links, wireless links tolocal base stations) or backend
connectivity (cloud) is lost, theapplication must still provide value tothe end user
When local (BT links, wireless links tolocal base stations) or backend
connectivity (cloud) is lost, it must be
ensured that data loss is avoided inorder to ensure service operation
Users may want to share their data via
various channels using various
platform instances
CPaaS.io

Fit Criterion
Existence of a datacollection
infrastructure
Method forcollecting
metadata andenriching sensor
data
Visual data accessfor end user

Availability ofanalytical services
Existence of user
registration
management
component
UI for controllinguse of data

Maximum clock
drift
Query latency in
msUser value

Percentage of lost
packets

Availability of data
sharingmechanisms
Page 36 of 40

Deliverable D2.1

EUE-11

Semantic data integration

EUE-12

Scale to personal data of
millions of people

Requirements Specification (V1)

Data sharing between diverse systems
can only efficiently be achieved if thesemantics of the data are machinereadable
The application will collect sensor andmedia data for millions of people. The
platform needs to be able toefficiently ingest, store, process user
data.

Ontologies for data
to be shared

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

Event Management – Tokyo Public Transportation (YRP)
ID
TPT-1

Description
Automated data collection
mechanism

TPT -2Multi-lingual data

TPT -3

Live data collection anddistribution

TPT -4

Data format and API
standardization

TPT -5

Secure and robust
communication

TPT -6Developers' Site

H2020 EUJ-02-2016

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

This use case deals with real-time
operation information of public
transportation such as trains, busses,
an air planes. It is necessary toprovide automatic data collection
mechanism for these data.
Since public transportation is
operated by many private and public
sectors, data distribution can only beachieved efficiently based onstandard data formats and APIs.
Public transportation is a criticalsocial infrastructure. Communication
among players of the public
transportation open data systemshould be secure and robust.
For the open innovation with public
transportation open data, it isnecessary to provide an open
development environment on theplatform called "developers site".

CPaaS.io

Fit Criterion
Existence ofautomatic datacollection systemfor public
transportation.
Ratio of multilingual
information in all
information.
Existence ofautomatictranslation system.
Existence ofautomatic collection
system anddistribution systemof live operation
data.
Existence ofstandard data
format andstandard API
specifications.
Existence of
cryptographic
communication
mechanism andfault tolerance
mechanism.
Existence ofdevelopers' site ofTokyo Public
Transportation
Open Data.

Page 37 of 40

Deliverable D2.1

TPT -7

Data License

TPT -8

Third party apps

TPT -9Services for the physicallychallenged

TPT -10User feedback collection

Requirements Specification (V1)Good data license is necessary for the
deployment of the data. For the data
license, the balance between dataholders’ merits and users' merits isessentially important.
Open data is a method for thecollaboration between data holders
and application developers.
Contribution to improve quality of lifeof the physically challenged and theelder in moving in Tokyo is one of themost important objectives.
User feedback is necessary for theevaluation of the use caseexperiment.

Existence of open
data license.

Rationale
The application collects and stores
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 be complemented with lifetime
usage data, such as times/open close,amount buffered/released,
active/inactive, filling level, battery
status, etc.
Different user groups can exert
different levels of control over adevice, so a hierarchy between groups
is established
Rules are set by individual users which
determine the level of control overtheir own device. Users may havedifferent preferences.
Circumstances need to be defined,
based on the various data sources, inwhich device control for user groups
are suspended and delegated to acentral user/authority
The rules and circumstances may
automatically trigger control levels as
they occur

Fit Criterion
Existence of datacollection
infrastructure

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

Waterproof Amsterdam (TTN)ID
WA-1

Description
Data collection

WA-2

Data processing

WA-3

User hierarchies

WA-4

Manual control over device

WA-5

Automated control overdeviceWA-6

Adaptive control levels

H2020 EUJ-02-2016

CPaaS.io

Existence of datacollection
infrastructure

Definition of usergroups, definitionof access rights
UI where users can
set their
preferences
Presence ofalgorithms

Control levels
definedPage 38 of 40

Deliverable D2.1

WA-7

Visualisation of device
status

WA-8

Operator control centre

WA-9

Push notifications

WA-10

User feedback collection

WA-11

Data harmonisation

WA-12

Physical network

WA-13

Multicast messaging

Requirements Specification (V1)

Users can access information via agraphical front-end that displays arecord of the rain buffer status, suchas filling level
Data can be aggregated per
geographical area in order to monitor
the status of and trigger actions on anumber of devices altogether
Circumstances may trigger
communication of predefined
messages to users such as push
notifications.
Prompts in the application can beused to manually collect user
feedback.
Data collected from the various
sources needs to be useable andinterpretable by the application
Data transmission is modulated with
LoRa, operated by The Things
Network network server. The
application needs to be integrated
with TTN API
Bulk downlink messages may be sent
to control large quantities of actuators
at the same time.

UI that can beaccessed by user

UI for network
operator

Reception of
notifications

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

Messages sentfrom control centre

Yokosuka Emergency Medical Care (YRP)
ID
YEM-1

Description
Data collection

YEM -2

Consensus for using medical
and personal data by city
government

YEM -3

Privacy protection ofpatients

YEM -4Low-effort for emergency
medical team staffs

H2020 EUJ-02-2016

Rationale
This use case deals with real-time
operation information of such as
patients' conditions, and position of
ambulances. It is necessary to provide
automatic data collection mechanism
for these data.
The data may have direct or indirect
relations with personal information ofpatients. Before the trial, we need tohave formal consensus with city
government on the basis of official
guidelines for personal data.
We must provide strong dataprotection mechanism such as securecommunication and secure storage.
Emergency medical team staffs are
doing very hard work for taking careof patients. It is impossible for them to
CPaaS.io

Fit Criterion
Existence ofautomaticcollection system

Agreement with
Yokosuka city
government

Existence of privacy
data protection
mechanism
Existence of loweffort mechanismand evaluation
Page 39 of 40

Deliverable D2.1

WA-6

User feedback collection

H2020 EUJ-02-2016

Requirements Specification (V1)spend time and effort for theoperation of this system. We must
realize a good work-flow and userinterface for the team staff.
User feedback is necessary for theevaluation of the use case experiment.

CPaaS.ioscore by the teamstaffsNumber of user
feedbacks

Page 40 of 40