door to door information for air passengers · the information contained in this document is...

DORA Deliverable D2.4

Door to Door Information for Air Passengers

D 2.4 Technical and Legal Requirements

Editor: Jan-Niklas Willing & Tom Schilling, VMZ Berlin

Deliverable nature: Report (R)

Dissemination level: Public (PU)

Date: planned | actual 29 February 2016 29 February 2016

Version | no. of pages Version 1.0 86

Keywords: Requirements Analysis, Requirements Coordination


2 / 86

Disclaimer

This document contains material, which is the copyright of certain DORA consortium parties,

and may not be reproduced or copied without permission.

All DORA consortium parties have agreed to full publication of this document.

The commercial use of any information contained in this document may require a license

from the proprietor of that information.

Neither the project consortium as a whole nor a certain party of the consortium warrant that

the information contained in this document is capable of use, nor that use of the

information is free from risk, and accepts no liability for loss or damage suffered by any

person using this information.

Impressum

Project acronym/name DORA Door to Door Information for Air Passengers

Project number/type 643973 Research and Innovation Action

WP number/leader 2 Patricia Bellver Munoz, ETRA I+D

Task(s) no.(s)/leader(s) 4 Claudia Baumgartner, VMZ Berlin

Task(s) no.(s)/leader(s) 5 Patricia Bellver Munoz, ETRA I+D

Copyright notice

2015/2016/2017/2018 VMZ Berlin and members of the DORA consortium


3 / 86

Executive Summary

This deliverable D2.4 is the result of the requirement definition process in tasks 2.4

(Technical Requirement Analysis and Specification) and 2.5 (Legal and Regulatory

Requirement Analysis and Specification). The objective of this report is to defi ne all

requirements that have to be taken into account for the upcoming specification activities in

work package 3 (DORA Concept Specification).

The requirements are based on the use cases and use case scenarios defined in D2.3 and

translate those into technical and legal framework conditions. The main outcome of this

deliverable is a list of altogether 151 requirements (140 technical and 11 legal requirements)

that were collected and coordinated with the help of the VOLERE requirement analysis tool.

The VOLERE tool provides an iterative instrument to collect, validate and revise all

requirements with the involvement of all developing partners. The different work stages of

the VOLERE process were carried out between M4 and M9.

The definition of technical requirements shows that all partners have generally the same

understanding of what each component has to perform and how different components

interact with each other. However, different dependencies and conflicts between

requirements as well as component-specific uncertainties could be identified. Based on the

discussion supported by the VOLERE tool, these problems could be solved by clarifying or

modifying certain requirements.

The legal requirement analysis mainly focuses on data protection topics as real-test users

will be involved in the later stages of the project. Different data protection legislations on

European and national level were analysed and translated into specific requirements that

will be considered for the data protection concept of the project.

The main results of the mentioned tasks can be found in chapters 5 and 6 where the final

and harmonised list of technical and legal requirements is presented.


4 / 86

List of Authors

Organisation Authors Main organisations’ contributions

VMZJan-Niklas Willing

Tom Schilling

ToC, Chapter 1, Chapter 2, Chapter 3,

Chapter 4, Chapter 5, Chapter7, Chapter

8

CSE Konstantinos Koutsopoulos Input Chapter 5

UPVLC Benjamin Molina Input Chapter 5

ETRAPatricia Bellver Munoz, Germán

MartínezInput Chapter 5, Chapter 6

EUREVA Philippe Martineau Input Chapter 5

VBB Jörg Becker Input Chapter 6


5 / 86

Table of contents

1 INTRODUCTION ............................................................................................... 10

1.1 Purpose of the Document ................................................................................ 10

1.2 Structure of the Document............................................................................... 10

1.3 Organization of work ....................................................................................... 11

2 CONNECTION TO OTHER TASKS........................................................................ 12

2.1 WP2 Use Cases ................................................................................................ 12

2.2 WP3 Concepts and Specification ...................................................................... 12

3 REQUIREMENT ANALYSIS ................................................................................. 13

3.1 Methodology ................................................................................................... 13

3.2 VOLERE Tool .................................................................................................... 13

3.2.1 Requirement Definition........................................................................................ 16

3.2.2 Requirement Validation ....................................................................................... 18

3.2.3 Requirement Revision .......................................................................................... 18

4 DEFINITIONS.................................................................................................... 20

4.1 Technical Requirements................................................................................... 20

4.2 Legal Requirements ......................................................................................... 21

5 TECHNICAL REQUIREMENT SPECIFICATION....................................................... 22

5.1 DORA Components .......................................................................................... 23

5.1.1 DORA Mobile App (& Smartwatch)....................................................................... 23

5.1.2 DORA Web GUI .................................................................................................... 28

5.1.3 DORA Platform..................................................................................................... 30

Door to Door Journey Planner ......................................................................................... 32

5.1.4 Indoor Positioning ................................................................................................ 34

5.1.5 Indoor Router ...................................................................................................... 39

5.1.6 Intermodal Landside Router ................................................................................. 44

5.1.7 Operation Centre Application............................................................................... 47


6 / 86

5.1.8 Strategic Routing Service...................................................................................... 48

5.1.9 Flight Information Service .................................................................................... 50

5.1.10 Trip Monitoring Service........................................................................................ 52

5.1.11 Waiting Time Detection ....................................................................................... 55

5.2 Validation and Revision Process ....................................................................... 57

5.2.1 Dependencies ...................................................................................................... 57

5.2.2 Conflicts ............................................................................................................... 66

5.2.3 Objections............................................................................................................ 68

6 LEGAL REQUIREMENT SPECIFICATION .............................................................. 70

6.1 Security Requirements: Privacy and Data Protection ........................................ 70

6.1.1 EU Legislation and Regulation .............................................................................. 70

6.1.2 National Laws: Spain and Germany ...................................................................... 76

6.1.3 DORA System Privacy Requirements .................................................................... 77

6.2 DORA System Standards Requirements ............................................................ 78

6.3 List of Legal Requirements ............................................................................... 80

7 IMPACTS.......................................................................................................... 83

7.1 Impacts on the DORA Architecture ................................................................... 83

7.2 Impacts on Service and Application Specification ............................................. 84

8 CONCLUSION ................................................................................................... 85


7 / 86

List of Figures

Figure 1: DORA VOLERE Tool login page ...............................................................................14

Figure 2: Requirement Definition Main Page ........................................................................15

Figure 3: VOLERE Requirements Specification Overview .......................................................16

Figure 4: Initial Definition of Requirements ..........................................................................18

Figure 5: Validation of Requirements....................................................................................18

Figure 6: Revision of Requirements ......................................................................................19

List of Tables

Table 1: Overview technical Requirements ...........................................................................22

Table 2: Technical Requirements DORA App.........................................................................27

Table 3: Technical Requirements DORA Smart Watch App....................................................28

Table 4: Technical Requirements DORA Web GUI .................................................................29

Table 5: Technical Requirements DORA Platform .................................................................32

Table 6: Technical Requirements DORA Door-2-Door Journey Planner .................................34

Table 7: Technical Requirements DORA Indoor Positioning ..................................................39

Table 8: Technical Requirements DORA Indoor Router .........................................................44

Table 9: Technical Requirements DORA Intermodal Landside Router ...................................46

Table 10: Technical Requirements DORA Mobility & Incident Management Panel................48

Table 11: Technical Requirements DORA Strategic Routing Service ......................................49

Table 12: Technical Requirements DORA Flight Information Service .....................................52

Table 13: Technical Requirements DORA Trip Monitoring Service ........................................54

Table 14: Technical Requirements DORA Waiting Time Service ............................................56

Table 15: Technical Requirements Dependencies .................................................................65

Table 16: Technical Requirements Conflicts ..........................................................................67


8 / 86

Table 17: Technical Requirements Objections ......................................................................69

Table 18: Legal Requirements...............................................................................................82


9 / 86

Abbreviations

Abbreviation Explanation

APP DORA App

BER Berlin Brandenburg Airport Willy Brandt

BLE Bluetooth Low Energy

DJP Door-2-Door Journey Planner

DORA Door to Door Information for Airports and Airlines

FDPA Federal Data Protection Act

FIS Flight Information Service

ILR Intermodal Landside Router

IP Indoor Positing

IR Indoor Routing

MIM Mobility and Incident Management Panel

PLA DORA Platform

PMI Palma de Mallorca airport

SRS Strategic Routing Service

SWA DORA Smart Watch App

SXF Berlin-Schönefeld Airport

TMS Trip Monitoring Service

TXL Berlin-Tegel Airport

WEB DORA Web GUI

WMS Web Map Service

WP Work Package

WTS Waiting Time Service


10 / 86

1 INTRODUCTION

1.1 Purpose of the Document

The purpose of this document is to give an overview on all technical and legal requirements

that have to be considered for the specification and the development of the DORA system.

The definition of requirements is of crucial importance for the specification of the system as

they line out the detailed framework in which the system and its components are to be

developed. Furthermore requirements help to clarify the responsibilities of all involved

partners and the interrelations between all system components.

The requirements presented in this deliverable are of different character. They include

functional and data requirements, usability requirements, performance requirements,

security requirements and legal requirements. In the DORA specification process this

document represents the last step needed in order to define the final system architecture in

T3.1.

This document enables all partners in DORA to start the development process in a

coordinated way as the requirements provide the detailed framework for each component.

The requirements clarify the interactions and dependencies between all components, they

describe which data is needed from each service in which format, summarize the main

functionalities and outline legal and security conditions for the DORA system in general.

1.2 Structure of the Document

This document consists of 8 chapters with different subchapters. Chapters 5 & 6 include the

main content of this deliverable summarizing the technical and legal requirements.

Chapter 2 gives an overview on how the DORA requirements definition is interconnected

with previous and following tasks. It is shown how the requirements are derived from both

the use cases defined in T2.3 as well as the initial DORA architecture described in D3.1.

Furthermore it is explained how the requirements are connected to the definition of the

final architecture in D3.2.

Chapter 3 illustrates the process of how the requirements were gathered and defined

among all project partners. As the central tool for the requirements defini tion in DORA the

VOLERE methodology is explained.


11 / 86

In Chapter 4 it is described what is understood under the terms technical and legal

requirements and summarized which aspects conditions fall under these topics.

Chapter 5 lists all technical and data requirements in table format divided by the

components they refer to. It also goes into detail regarding the requirements change history

resulting from the VOLERE validation and revision process.

In chapter 6 the security and legal requirements relevant for DORA are listed. Especially data

protection, standards and compliance aspects are summarized and translated into

requirements.

Chapter 7 gives an outlook on how the requirements identified impact the further work in

the final architecture, application and service specification.

1.3 Organization of work

This deliverable, which is edited by VMZ, contains the results of two tasks: Task 2.4

“Technical Requirement Analysis and Specification” has been led by VMZ and task 2.5 “Legal

and Regulatory Requirement Analysis and Specification” by ETRA. The work in both tasks has

been carried out from month 4 (September 2015) until month 9 (February 2016) with the

involvement of all developing project partners. Both tasks belong to work package 2 “DORA

Requirements and Use Cases” coordinated by ETRA.

The central tool for defining the requirements based on the VOLERE methodology has been

provided by ETRA. VMZ in turn has been in charge of the administration of the VOLERE tool

for DORA project which included the general management of the different working steps

and sessions within the VOLERE process. In each phase of the process inputs were gathered

from all developing project partners. The VOLERE process is explained in detail in chapter 3.

The analysis and specification of legal requirements, in contrast to the technical part,

required desk research regarding data protection and security legislations.

In addition to the management and edition of requirements in the VOLERE online tool, the

technical framework for the requirements was discussed during the two technical

workshops in Berlin on the 6th of October 2015 and in Frankfurt on the 26 th of November

2015.


12 / 86

2 CONNECTION TO OTHER TASKS

2.1 WP2 Use Cases

In deliverable 2.3 the DORA use cases were defined in December 2015. These use cases

illustrate what the DORA system needs to achieve in order to fulfil the project objectives. In

order to fulfil the use cases the overall system and its components have to provide a wide

variety of functions. As these functions often times require the interaction between different

components which are developed by different partners, a requirements definition process is

needed which clarifies the data exchange and dependencies between the services and

applications.

The use case definition and the requirements analysis have been carried out in parallel from

months 4 to 7 (September 2015 - December 2015). After the final list of use cases was

available at the end of December 2015 the already existing requirements were reviewed in

order to identify possible gaps between the final use cases and the draft technical

requirements. Based on this review, technical requirements were modified or added

accordingly.

2.2 WP3 Concepts and Specification

In deliverable D3.1 the draft architecture of the DORA system was illustrated in December

2015. In this document it was outlined of which components the DORA system consists and

how the different services and data sources interact. Existing local data sources were

analysed that can be used by the different services to be developed. It was described which

components are located in the so-called DORA city nodes and how they basically

communicate with the central services located in the service platform over the open service

API. Furthermore it was depicted how the different applications communicate with the

central services in the service platform and the local services in the city nodes by using the

open application API.

Although the architecture in D3.1 is only a draft and will be specified in D3.2 (DORA

architecture) some fundamental principles of the interaction between services could be

identified. The definition of requirements takes into account the communication processes

and specifies the different interactions to data and functional requirements.


13 / 86

3 REQUIREMENT ANALYSIS

3.1 Methodology

Gathering the requirements from all partners in a project is a key success factor. The

requirements not only describe different aspects of a project but they also help to identify

conflicting features in early stages. Such an important step – that identifies and affects the

overall outcome of the project - is worth investing considerable efforts and utilizing a proper

tool.

Based on the use cases, the initial architecture and discussions during the technical

workshops, a basic classification of technical components was performed to set the

foundation for the actual requirement definition process.

The classification of components is as follows: DORA Platform (PLA), Mobile Application

(APP), Smartwatch Application (SWA), Web GUI (WEB), Door to Door Journey Planner (DJP),

Flight Information Service (FIS), Intermodal Landside Router (ILR), Indoor Positioning (IP),

Indoor Router (IR), Mobility and Incident Management Panel (MIM), Strategic Routing

Service (SRS), Trip Monitoring Service (TMS), Waiting Time Detection Service (WTS). Apart

from these technical components a set of legal requirements (LEG) was defined.

In order to define the technical and legal requirements for DORA, the VOLERE requirements

analysis approach has been applied. The requirements definition process consisted of three

different iterative phases: The initial requirement definition, the requirement validation and

the requirement revision. These three phases and their respective purposes are described in

the following subchapter on the VOLERE tool. As a result of this process a final list of

requirements has been generated provided in chapters 5 & 6.

Whereas the technical requirements in chapter 5 are a result of the use cases, the initial

architecture and detailed coordination processes, the legal requirements in chapter 6 result

from desk research on legislations, standards and compliance frameworks.

3.2 VOLERE Tool

The VOLERE methodology is used mainly because of its simplicity. It helps project partners to

describe, formalize and track the project requirements in an explicit and unambiguous

manner. Besides being a success in past projects, the VOLERE methodology is selected for

the following reasons:


14 / 86

1. The VOLERE methodology requires simple steps to identify and formalize the

requirements in an unambiguous manner.

2. The VOLERE methodology provides an easy process to track and evaluate the

progress of the project.

3. A number of the project partners have already experience with the VOLERE

methodology. Hence, they did not have to accomplish an extra learning effort.

The consequent application of the VOLERE methodology is not only useful in the initial

phases of the project for specifying requirements but it is also helpful in specifying a

reference point for the later stages. During the implementation and management, it can be

used to track and evaluate the progress of the individual work packages and the overall

project. Besides being efficient and easy to use, the VOLERE methodology provides a

mechanism for all partners to specify the requirements in a standard format. Thereby,

specifying additional context of a requirement such as the rationale and the acceptance

criteria for every requirement helps to build a common understanding of the overall system.

Furthermore, defining priorities helps to clarify the focus of the project. In DORA project we

only distinguish between optional and mandatory requirements.

Aiming at defining an optimum and complete list of requirements, a web tool based on the

VOLERE methodology was developed by ETRA. This web tool has to facilitate the definition,

the validation and the prioritization of the DORA requirements.

Figure 1: DORA VOLERE Tool login page


15 / 86

Access to the web tool is granted after a successful identification on the system. The

application allows the administrator to control the status of the validation process from the

initial definition to the final list of requirements passing through the required validation and

revision status.

If the administrator approves the request, then, an email with the user name and password

is sent to the requester. From that moment, the user will be able to access the DORA

requirements definition website. Once he has logged in, the user can access the main page.

Figure 2: Requirement Definition Main Page


16 / 86

The overall process of Volere as supported by the web tool is depicted in Figure 3. After an

initial specification of requirements, the users can specify conflicts, dependencies and

objections. After specifying them, they can iteratively revise the specification and identify

additional issues until it is free of conflicts, dependencies and objections. The result will

constitute the final list of requirements. The following subsections briefly outline the

individual steps.

Figure 3: VOLERE Requirements Specification Overview

3.2.1 Requirement Definition

The requirement definition is the first stage of the overall specification process. At this stage

all technical project partners insert requirements for all services and especially for those for

which they will probably be involved in the development proce ss. To insert a new

requirement, the following fields have to be filled out.

ID: The scope of this requirement (depends on the group in which it is classified.). Appended by an automatically generated sequential number, this ID uniquely identifies each requirement. This ID will be generated after the requirement has been added.

Description: A one sentence statement which describes the intention of the requirement.

Type: The type of the requirement as defined by Volere.

Rationale: A justification of the requirement.

Acceptance criteria: A measurement of the requirement for further verification that the solution matches the original requirement.


17 / 86

Priority: The importance for the customer of successfully implementing the requirement. We suggest to use only number 1 (=Optional) and 5 (=Mandatory) in the current scale of the tool.


18 / 86

Figure 4: Initial Definition of Requirements

3.2.2 Requirement Validation

After the initial definition of requirements, the validation stage begins. All the requirements should be approved by all the users. At this stage, conflicts and dependencies between requirements must be detected. Furthermore, any objection must be pointed out.

Dependency: Requirements that have some dependency on other requirements.

Conflict: Requirements that cannot be implemented if another requirement is implemented or a conflict due to an insufficient definition of the requirement.

Objection: A reason or argument offered in disagreement, opposition, refusal or disapproval of the requirement.

Figure 5: Validation of Requirements

3.2.3 Requirement Revision

All the dependencies, conflicts and objections encountered by the experts during the

validation stage must be revised and solved. However, if the authors do not agree with the

validator’s opinion, then they can make use of the “Reviser’s comments” option f or pointing

out their disagreement or clarifying the intention of the requirement. Note that only the


19 / 86

authors of the requirements that have to be revised are able to add comments to the

dependency, conflict or objection.

Figure 6: Revision of Requirements

The checkboxes in “Requirements revised” column and “Validator’s approval” column help the users to check the status of the revision and together with the possibility of adding comments facilitate the interaction and communication between the author and the validator. For security reasons, the checkboxes on the “Requirements revised” column are only enabled for the authors of the requirements who have also enabled the possibility of adding comments. For the same reason, the checkboxes on the “Validator’s approval” column are enabled only for the author of the validation.

The revision process consists of four steps:

First, the authors should identify which requirements have been objected to or are involved in any conflict or dependency.

Second and after analyzing the validator’s opinion:

o The author may agree with the validator and proceed to modify or delete the requirement.

o The author may disagree with the validator, therefore he/she should make appropriate comments trying to clarify the requirement with a better explanation or justify the intention of the requirement.

Third, the author should mark the checkbox of the requirement as revised.

Finally, the validator should be aware of the revised requirements and approve the actions taken by the author for resolving the dependency/conflict/objection. It is possible to review the history of a requirement.


20 / 86

4 DEFINITIONS

The DORA requirements are divided into two different groups: technical requirements and

legal requirements. In this chapter it is specified, what we understand under these two

headlines and what types of requirements are covered in each section.

4.1 Technical Requirements

Among technical requirements are understood all requirements which have to be fulfilled by

the DORA system in terms of functional features as well as performance -related issues,

reliability issues, and availabilities.

These requirements influence the entire DORA system regarding the functionalities to be

realized i.e. in the frontends like the App and the DORA Web GUI. In addition these

requirements list the data requirements to be accomplished and services to be provided in

the DORA backend system like i.e. the DORA Service Platform or a specific component like

the Door-2-Door Journey Planner (DJP).

In the following subsection each group of technical requirements is described in more detail.

Functional Requirements

The functional requirements specify what the DORA system and/or a specific component

must do. They relate to the actions that the system must carry out in order to satisfy the

fundamental reasons for its existence. It describes an action that the product must take if it

is to carry out the work for which it is intended.

Data requirements

A specification of the essential subject matters regarding to objects, entities or classes that

are related to the system. These requirements influence the definition of the architecture

and the communication between the services through interfaces as well.

Performance Requirements

Performance Requirements are related to the specifications of speed and response times

(the amount of time which is needed to complete specified tasks), or accuracy requirements

(Quantification of the desired accuracy of the results produced by the DORA system or a

single service) and in addition reliability and availability requirements (the allowable time

between failures, or the total allowable failure rate).


21 / 86

Operational Requirements

Operational Requirements focus on the analysis of needed environments for the DORA

services in physical and technological means.

Maintainability and Support Requirements

A quantification of the time necessary to make specified changes to DORA. There may be

special requirements for maintainability, such as this system must be able to be maintained

by its end-users, or developers who are not the original developers. In addition this category

specifies the level of support that is required.

Usability and Humanity Requirements

They describe the DORA client's aspirations for how easy it will be for users of the product to

operate it. The product's usability is derived from the abilities of the expected users of the

product and the complexity of its functionality. Here just a first impression on usability

requirements will be given because of the strong connection to other mentioned

requirements. The full analysis of user requirements will be given in WP3 within the task of

the specification of (end user) applications.

4.2 Legal Requirements

Legal requirements cover all requirements towards the DORA system regarding existing

legislations on data protection, compliance and the use of technological standards. In

contrast to the technical requirements which describe the technical dependencies between

the different components, the legal requirements affect the DORA system by setting the

legal framework that has to be taken into account for the development process.

The VOLERE tool allows the following classification of legal requirements:

Legal requirements

This type of requirements covers all aspects regarding compliance frameworks and the use

of standards.

Security Requirements

This type of requirements treats all aspects of data protection and data security legislation. It

covers the specification who has access to data, under what circumstances this access is

granted, how the privacy of individuals can be insured and how the national and

international laws of data protection are applied.


22 / 86

5 TECHNICAL REQUIREMENT SPECIFICATION

This chapter lists all technical requirements separated for each DORA service classification.

Overall the DORA consortium in general and especially the technical partners have identified

140 technical requirements. 125 of them are mandatory requirements. They have to be

taken into account for the design of the DORA system and for the service and application

specification. In addition 15 optional requirements have been identified too – see Table 1.

Type of Requirement

Service Classification

Amount Mandatory Optional

Technical

APP 23 20 3

SWA 5 5 0

WEB 10 10 0

PLA 10 10 0

DJP 6 6 0

IP 23 16 7

IR 17 15 2

ILR 9 9 0

MIM 11 11 0

SRS 4 4 0

FIS 8 5 3

TMS 9 9 0

WTS 5 5 0

Sum 140 125 15

Table 1: Overview technical Requirements

The following subchapter lists the detailed requirements for each DORA component and

explains for each requirement the rational description and its acceptance criteria as well as

the priority level.


5.1 DORA Components

5.1.1 DORA Mobile App (& Smartwatch)

Requirement ID

Description (Service) Classification

Type Rationale Acceptance criteria Priority

APP_001 The DORA App supports multiple languages

DORA App Functional and data requirements

The App should be designed to work with different languages in order to guarantee transferability.

The UI of the App can be configured to show messages at least in English, Spanish, Catalan and German

Mandatory

APP_002 The DORA App is available for iOS and Android


The DORA App should be available for the latest version of Android and iOS and at least available for Android 4.2 and iOS 8

The DORA App can be used by the majority of smartphone users in both clusters Berlin and Palma

Mandatory

APP_003 The DORA App is connected to the DORA Service Platform


The DORA App is provided through the open Application API with all routing functionalities and POI detail data

The DORA App uses the open application API for data communication with the backend

Mandatory

APP_004 User can save personal trip preferences in the DORA App settings

DORA App Usability and humanity requirements

The user does not have to enter personal trip preferences every time again before a trip plan could be requested

The user can at least save two personal trip preferences in the app

Mandatory

APP_005 DORA App is easy to use DORA App Usability and humanity requirements

The App user is able to handle the provided functionalities in the frontend in a convenient way

An useability test verifies an easy handling of the App with users being not involved in DORA

Mandatory

APP_006 The App informs DORA App Functional and data The DORA App informs The DORA App informs Mandatory


24 / 86

proactively in cases of disruptions or disturbances

requirements proactively the user about a disruption, delay or another kind of disturbance, having an impact to complete the travel chain

proactively at least about disturbances in the street network

APP_007 Routing results will be presented through a map and through textual instructions in the app


The calculated routes can be comprehend both through route itinerarysketches on a map and through textual instructions (turning movements)

The two described ways are included

Mandatory

APP_008 The DORA App supports to calculate routes optimizedfor duration, CO2 and monetary costs


The DORA App allows user to calculate trips by using different optimization criteria’s (trip duration, CO2 emissions and monetary costs in â‚¬)

The App allows at least the change of two routing optimization criteria’s

Optional

APP_009 User can use current position in the App to plan the trip


User is able to choose actual position of the smartphone as a starting or destination point of the trip

User can enter current GPS position as a starting or destination point

Mandatory

APP_010 User can choose points on a map to plan the trip


User is able to choose a point on a map as a starting and/or destination point of the trip

User are provided with the functionality to click on the map to use them as start and destination points of

Mandatory


25 / 86

the trip

APP_011 The App allows to reserve / book a car sharingvehicle


The user of the DORA App is able to reserve/book a car sharing vehicle directly in the App without an App-to-App-Linkage

The car sharing booking functionality is directly integrated in the App

Optional

APP_012 The App allows to pay the public transport ticket


The user of the DORA App is able to pay directly in the App the public transportation ticket without an App-to-App-Linkage

The public transport ticketing functionality is directly integrated in the App

Mandatory

APP_013 DORA App integrates the indoor positioning library


Via a small interface the DORA App uses the native library of the indoor positioning service

The App uses the indoor positioning service for the indoor localisation

Mandatory

APP_014 DORA App integrates the navigation library


Via a small interface the DORA App uses the native library of the indoor positioning service

The App uses the indoor positioning service for the indoor localisation

Mandatory

APP_015 Native Indoor Positioning Lib and Indoor Navigation Lib communicate with each other through the DORA open Service API


Both services communicate with each other through the DORA open Service API

n.a. Mandatory

APP_016 The path through the airport is realized via an indoor navigation


The indoor routing at the airport will be presented to the user via arrows and

The presentation of the indoor navigation should be at least realized through

Mandatory


26 / 86

active texts (display of smartphone or smartwatch) and announcements (speaker of smartphone or smartwatch)

arrows

APP_017 Visual Assistance DORA App Functional and data requirements

Photos can be used for certain directions to allow users be able follow the correct path

Photos are associated with certain positions along the overall path and allow the user to put them on display to better resolve any complex direction (e.g. take certain lift or stairs if more than 2-3 are available)

Optional

APP_018 The DORA app provides a personal assistance button with telephone numbers deposited for airports and public transport operators


For mobility impaired people it is important to contact a mobility assistance desk if needed

At least the telephone numbers for the three airports and the main public transport operators should be provided

Mandatory

APP_019 The DORA App needs to support user survey functions


For evaluation purposes the app has to be able to integrate user surveys

Mandatory

APP_020 The user can select the option "Start monitor my trip" in the app which starts the supervision of the selected route in the


The TMS needs to know which route to supervise (even before the trip has even started). That is why the user needs to start this

Optional


27 / 86

Trip Monitoring Service function proactively

APP_021 Start Trip DORA App Functional and data requirements

GPS must be activated when the users starts the trip

GUI should offer a functionality for letting the user to start a trip

Mandatory

APP_022 Ignore problem DORA App Functional and data requirements

User must decide what to do when a problem is raised

User can take a decision when a problem is raised

Mandatory

APP_023 Recalculate route DORA App Functional and data requirements

Recalculate route User can take a decision when a problem is raised

Mandatory

Table 2: Technical Requirements DORA App

Requirement ID

Description (Service) Classification Type Rationale Acceptance criteria Priority

SWA_001 The SWA supports multiple languages

DORA Smartwatch App Functional and data requirements

The SWA should be designed to work with different languages in order to guarantee transferability

The UI of the SWA can be configured to show messages at least in English, Spanish, Catalan and German

Mandatory

SWA_002 The SWA is available for iOS and Android


The SWA should be available for the latest version of Android and iOS devices

The DORA SWA can be used by the majority of smartphone users in both clusters Berlin and Palma

Mandatory

SWA_003 The SWA is connected to the DORA App and the related smartphone


The DORA SWA communicates only with the DORA App on the user device (smartphone)

The DORA App uses the open application API for data communication with the backend and gives the needed information to the smartphone

Mandatory


28 / 86

SWA_004 The SWA informs proactively in cases of disruptions or disturbances


The DORA SWA informs proactively the user about a disruption, delay or another kind of disturbance, having an impact to complete the travel chain

The DORA App informs proactively at least about disturbances in the street network

Mandatory

SWA_005 The DORA SWA presents navigation advices and turn relations to the user


The DORA SWA gives navigation advices - which are provided by the Smartphone native library and the DORA App

The DORA SWA presents at least for the indoor part of the trip the navigation advices

Mandatory

Table 3: Technical Requirements DORA Smart Watch App

5.1.2 DORA Web GUI

Requirement ID



WEB_001 Select route DORA Web GUI

Functional and data requirements

A route must be selected for being able to check everything is correct on it during the monitoring process

User must be able to select one of the proposed routes by DORA system

Mandatory

WEB_002 Start Trip DORA Web GUI


GPS must be activated when the users starts the trip

GUI should offer a functionality for letting the user to start a trip

Mandatory

WEB_003 Ignore problem DORA Web GUI


User must decide what to do when a problem is raised

User can take a decision when a problem is raised

Mandatory

WEB_004 Recalculate route DORA Web Functional and User must decide what to do when a User can take a decision when a Mandatory


29 / 86

GUI data requirements

problem is raised problem is raised

WEB_005 The DORA Web GUI needs to be have a responsive design

DORA Web GUI


In order to be displayable on smartphones and tablets the design should be responsive

Mandatory

WEB_006 The DORA Web GUI supports multiple languages

DORA Web GUI


The App should be designed to work with different languages in order to guarantee transferability.

The UI of the App can be configured to show messages at least in English, Spanish, Catalan and German

Mandatory

WEB_007 The DORA Web GUI supports Chrome, Firefox and IE browsers

DORA Web GUI


The Web GUI should be available for the latest versions of different browsers

The Web GUI can be used by the majority of all potential users

Mandatory

WEB_008 The DORA Web GUI is connected to the DORA Service Platform

DORA Web GUI


The DORA Web GUI is provided throughthe open Application API with all routing functionalities and POI detail data

The DORA Web GUI uses the open application API for data communication with the backend

Mandatory

WEB_009 Routing results will be presented through a map and through textual instructions in the GUI

DORA Web GUI


The calculated routes can be comprehend both through route itinerary sketches on a map and through textual instructions (turning movements)

The two described ways are included

Mandatory

WEB_010 The DORA Web GUI supports identical trip preferences and routing critirias like the DORA App

DORA Web GUI


The DORA Web GUI supports the same functionalities to personalize the trip like the DORA App

Identical trip personalization in both end user frontends

Mandatory

Table 4: Technical Requirements DORA Web GUI


30 / 86

5.1.3 DORA Platform

Requirement ID Description (Service) Classification Type Rationale Acceptance criteria Priority

PLA_001 DORA Platform provides open interfaces for front ends

DORA Platform Functional and data requirements

The DORA platform provides an open application interface for the frontends (DORA App, DORA Web GUI, Third Party Apps and Third Party Web GUIs)

The DORA App and the DORA Web GUI uses the open frontend interface

Mandatory

PLA_002 DORA Platform provides open interface for traffic management panel


The DORA platform provides an open application interface for the management panel frontend

The MIM uses the open application interface for the management panel interface

Mandatory

PLA_003 The DORA platform and its integrated services are high available

DORA Platform Operational requirements

Through the frontends the DORA services should be reachable anytime

The DORA services in the platform are reachable through the interfaces 24/7

Mandatory

PLA_004 The DORA platform is easily scalable

DORA Platform Operational requirements

Anytime the DORA platform can be easily scaled up/down regarding the actual load

The scalability of the DORA platform is realized through cloud computing techniques

Mandatory

PLA_005 The DORA Platform is EU wide transferrable


To ensure interoperability the DORA platform should

DORA platform offers provider specific backend interfaces

Mandatory


31 / 86

offer open backend interfaces to transfer the platform to other cities and regions following ITS, EU and de facto standards

being open to adapt to the platform

PLA_006 DORA is independent from GoogleMaps services


DORA does not dependent from GoogleMaps

DORA does not use google maps as background map tiles

Mandatory

PLA_007 The DORA services are provided with the same data basis and data inventory


The DJP, all routing services and the trip monitoring service as well as LBS and WMS services work with the identical data basis and data inventory

All main DORA services are provided with the same data basis and data inventory

Mandatory

PLA_008 A central DORA map tile service within the DORA service platform provides map data in PNG format


To provide all frontends, GUIs and applications with PNG files for maps, a central DORA map tile service is necessary

All frontends are provided with map tiles for indoor and outdoor in PNG format

Mandatory

PLA_009 The DORA service platform is provided with available real time information about POI data in the airport


The DORA service platform needs to be provided with indoor POI data at the airport for stairs, escalators, elevators, etc. and internal disruptions in real time

The DORA service platform is at least provided with the real time POI information for escalators, elevators

Mandatory

PLA_010 The DORA platforms DORA Platform Performance In order to collect all At least Mandatory


32 / 86

and all services need to log system performance for technical evaluation purposes (KPIs still to be defined)

requirements needed data for the technical evaluation, the platform and all services need to support logging procedures

uptimes/downtimes, requests/responses for each DORA API and response times need to be logged

Table 5: Technical Requirements DORA Platform

Door to Door Journey Planner


DJP_001 The DJP calculates long term door-to-door routes from A to B around a known flight

Door-to-Door Journey Planner


The basis for the door-to-door journey planning is the flight. The related flight number is used to calculate the way from the starting point to the airport and from the arrival airport to the final destination

After entering a flight number in a DORA frontend the DJP calculates complete routes

Mandatory

DJP_002 The DJP calculates long term door-to-door trips based on starting or arrival times



If the user determines start time or arrival time at the final destination and let the door-to-door router calculate routes including different

Based on the request parameters the door-to-door router starts the route calculation.

Mandatory


33 / 86

flight connections.

DJP_003 The Door-to-Door Journey Planner is connected to the single DORA services providing the routes for relevant parts of the overall trip chain



The DJP needs the connection to theIntermodal Landside Router, Indoor Router and Flight Information Service

Based on the routing request by the DORA user the Door-to-Door Journey Planner calculates different route suggestions for an overall trip

Mandatory

DJP_004 The DJP supports individual routing parameters or optimization criteria’s



To allow the user to adjust trips to personal needs and physical constraints the DJP should take into account personal parameters

The DJP should at least work with two different personal trip preferences

Mandatory

DJP_005 The DJP provides optimal door-to-door routes to a given cost function



Based on the personal request and trip optimization criteria’s, the DJP should calculate at least one trip from A to B

Based on the responses of the partial routing services the Door-to-Door Journey Planner combines the provided routes to one or several overall door-to-door connections.

Mandatory

DJP_006 The D2D Journey Planner needs to get a routing request from a DORA frontend including relevant routing parameters (Time, Date, origin,



The routing calculation only starts after a routing request containing relevant routing parameters

Routing request needs to be in correct format and has to contain at least the parameters: Time, Date, Origin, Destination

Mandatory


34 / 86

destination, Transport modes, Mobility settings, etc.)

Table 6: Technical Requirements DORA Door-2-Door Journey Planner

5.1.4 Indoor Positioning

Requirement ID Description (Service) Classification


IP_001 Mobile support for georeferenced maps

Indoor Positioning Functional and data requirements

The mobile app should be able to manage georeferenced maps to display indoor maps and the position of the user

A georeferenced map is correctly displayed on the app. The app is able to deal with various layers and place icons (e.g. positioning point) on the map to show the users positioning

Mandatory

IP_002 Mobile RSSI measurements


The mobile app should be able to get the corresponding RSSI values from each detected network (SSID for Wi-Fi and UUID for BLE)

he mobile app is able to generate an array of RSSI measurements that can be later sent to the IPS

Mandatory

IP_003 Fingerprinting database (FPD)


The IPS should have an (updated) table of the FPD

The IPS algorithm is able to access to a database and query

Mandatory


35 / 86

the FP values

IP_004 Internet connection to DORA services


The mobile app requires Internet connection to access the DORA services (e.g. IPS)

The mobile app is able to query basic/test DORA services

Mandatory

IP_005 Provisioning of previous measurement


The IPS can provide a better estimation if it is aware of the context (last measurement and time of measurement). For efficiency purposes, the IPS algorithm is stateless, and therefore the mobile app should provide its previous measurement (optional) to o

The mobile app provides the previous measurement in the request

Mandatory

IP_006 Provisioning of maps Indoor Positioning Functional and data requirements

Buildings (airports) should be previously configured before positioning a user, as it is typically placed on a map. Therefore, the maps of the buildings should be previously given

The mobile app is able to show the map of the building. The map can be obtained from a GIS server.

Mandatory

IP_007 IPS Response Time (3s) Indoor Positioning Performance requirements

The IPS should have a low response time

The IPS responds to a positioning request in less than 3s

Mandatory

IP_008 IPS Accuracy (5-10 m) depending on various

Indoor Positioning Performance requirements

The user must be located on the map

The estimation value differs less than 5-10

Mandatory


36 / 86

deployment criteria approx. in the same place as it is in the real world

m to the real point (dependable)

IP_009 IPS Accuracy improvement

Indoor Positioning Performance requirements

Using inertial sensors (if available) between updates in the client side can improve the accuracy

The enhanced estimated value at client level is more accurate than the estimated value from the IPS on the current time interval

Optional

IP_010 Wi-Fi and/or BLE RSS and RSSI measurements must be processed taking into account ambient conditions as well as equipment variations


RSSI measurements may be affected by environment conditions as well as by thedifferent level of sensitivity among various end devices

The evaluation of the position remains unaffected or with small variations from device to device or with respect to how much crowded a place is

Mandatory

IP_011 IPS Beacon intervals and battery life


Battery life especially for the trial period is crucial and therefore no high frequency in beacon transmissions must be required for IPS services

Beacons have a battery life close to three months without any recharging or battery replacement

Mandatory

IP_012 Beacon augmented info transmission


In case battery status as well RSSI measurements can be performed without significant power expenses, the broadcasted SSIDs can be augmented to cater

IPS algorithms get indeed improved with the injection of real time information pertaining to environment conditions

Optional


37 / 86

for assisting IPS algorithms with real time beacon and anonymous crowd sensing conditions

IP_013 Accelerometer and user movement direction


The use of accelerometer and previous location info may reveal the direction of the user movement as well as the direction of his smartphone. This information may be used to improve user location calculation.

The inclusion of the smartphone and movement direction proves to be useful in location calculations

Optional

IP_014 Beacon ID and Tx Level must be fixed and configurable

Indoor Positioning Operational requirements

Beacons are identified by the transmitted ID at a specific power level. The reception of the ID at certain RSSI levels across covered places is recorder in the Fingerprinting DB.

Beacon IDs are not received in areas other than those initially associated.

Mandatory

IP_015 Beacon installation must be easy and independent of existing infrastructure

Indoor Positioning Maintainability and support requirements

Pilot and trial phases must not pose any complex procedures in the installation and maintenance of Beacons

Easy installation and maintenanceprocedures

Mandatory

IP_016 Beacon expected battery life


Beacon infrastructuremust remain stable for a period to cover pilot

No frequent battery maintenance tasks are required

Mandatory


38 / 86

execution needs

IP_017 Beacon Energy Harvesting Indoor Positioning Maintainability and support requirements

The battery life of Beacon devices shall be long

No frequent battery maintenance tasks are required

Optional

IP_018 Beacon housing/materials and other production/manufacturing constraints


Ease of use and installation/maintenance

Physical and other constraints delivered

Mandatory

IP_019 Native Implementation of Indoor Positioning Service


To call back the DORA services and open the DORA App when necessary the IPS needs to be an own service with an own lib on the smartphone device

The indoor positioning service should be implemented as an own lib for at least Android and iOS

Mandatory

IP_020 Beacon Management Interface


In case a management interface can be added to the beacons without any significant impact on energy and battery life, it may prove useful for emergency information distribution.

SSIDs can be augmented with ephemeralemergency short messages to be detected by the location library

Optional

IP_021 Mobile devices battery life Indoor Positioning Functional and data requirements

Excess scanning for Wi-Fior BLE beacons depletes battery in mobile devices

Impact on battery life is acceptable and does not influence users in a negative manner

Mandatory

IP_022 Beacons SSIDs may include a frequency factor to aid mobile devices in


IP library may take into account the beacon frequency and schedule

Mobile device battery life is preserved

Optional


39 / 86

optimising scanning schedule

scanning accordingly

IP_023 Consider location information (approximate) already provided by OS


Place identification may be already available by existing OS location mechanisms.

IP processing optimises scan scheduling

Optional

Table 7: Technical Requirements DORA Indoor Positioning

5.1.5 Indoor Router


IR_001 Mobile Indoor navigation library

Indoor Router Functional and data requirements

Part of the INS is performed at client level. However, there is a suite of INS libraries to help the mobile APP in the process

The mobile app is ableto use the provided INS library

Mandatory

IR_002 Outdoor Geocoding service


As there is a commutation from outdoors to indoors, the corresponding building (airport) should be identified to retrieve the map from the INS and launch the navigation

A building id is provided given an input parameter, such as: position(lat/lon), airport name, etc. (TBD)

Mandatory

IR_003 Flight Information Indoor Router Functional and data Provided the Flight ID, Given the Flight ID, the Mandatory


40 / 86

service and Indoor Geocoding Service

requirements there is a list of corresponding company airport counters (or kiosks) to perform the check-in

AIS (Airport Information Service) will provide a list of (consecutive) boxes to perform the check-in. Given one of this airport counters, the Indoor Geocoding Service provides a georeferenced point to locate the counter on the ma

IR_004 Indoor real-time status Indoor Router Functional and data requirements

Depending on the real time status of some nodes in the airport (e.g. elevator is out of order), the INS should provide the best (shortest) path to the destination node

The INS service (algorithm) is able to react with a different navigation path once a node changes its status affecting to the navigation cost.

Mandatory

IR_005 Average queue time Indoor Router Functional and data requirements

Depending on the real time status of some nodes in the airport (e.g. average queue time in security points), the INS should provide the best (shortest) path to the destination node avoiding queues.

The INS service is able to react when there is more than one observed node (e.g. security point) and the average queue time is significant on one of them, showing a path through the other less congested node (e.g. control points)

Mandatory


41 / 86

IR_006 User profile implication


Depending on the user profile, the INS should provide a comfortable & viable navigation path to the user (e.g. an impaired people will typically use mechanical devices (lifts, escalators instead of stairs)

The INS service is able to react with a different navigation path if the user profile changes. This results in a change of costs per node

Optional

IR_007 Navigation distance and time estimates


Besides the navigation path, the INS provides the approximate distance to the destination and an average expected time.

The INS service provides a reasonable estimated distance compared to the real distance. If the test is performed exactly through the provided navigation path, the difference should be less than 5 meters. A similar evaluation applies to the estimated time.

Mandatory

IR_008 INS Response Time (5s)

Indoor Router Performance requirements

The INS should have a low response time

The INS responds to a navigational request in less than 5s

Mandatory

IR_009 Alerting the user (far away and close to boarding)


The user needs to be alerted if some events happen during his/her stay at the airport. The mobile app, depending

The mobile app alerts the user about the approaching boarding gate departure time when he/she away

Optional


42 / 86

on relative user position to the boarding gate in terms of time, should alert the user.

from the boarding gate and there is little (configurable) time for departure.

IR_010 Provisioning of POIs Indoor Router Functional and data requirements

Buildings (airports) have a different points of interest where the user may want to go (from boarding gates to shops)

The mobile app is able to show selected POIs on a map

Mandatory

IR_011 IR supports via points and residence time


The indoor routing service supports the use of via points and the residence time

An indoor route could be planned via different interim destinations including the time there

Mandatory

IR_012 The indoor maps include the geometries for both clusters Palma (PMI) and Berlin (SXF and BER)


The indoor maps include surfaces, floors, building, escalators, elevators, toilets, security checks, check-in counters, counters, shops, parking spots, ways and tunnels

The indoor maps for each airport include the relevant geometries for both clusters Palma (PMI)and Berlin (SXF and BER)

Mandatory

IR_013 Provides the indoor routing result in WGS84 coordinates plus the z-coordinate for the floor


To combine the indoor routing results with all other involved parts of the entire trip, the indoor part needs to be provided in WGS84

The indoor routing result could be interpreted by the ILR

Mandatory


43 / 86

coordinate system with additionalinformation about the floor (z-coordinate)

IR_014 Indoor maps are provided in a standard format for each airport


Indoor maps should be provided in SHP, KML or other kind of standard

Indoor maps are available in a standardised format for both clusters Palma (PMI) and Berlin (SXF and BER)

Mandatory

IR_015 The rerouting of the indoor App is initiated through the DORA App


The DORA indoor routing service should not call permanently the DORA services regarding updates or disturbances on the current indoor route.

The DORA App triggers a rerouting of a current route

Mandatory

IR_016 Processing of different routing parameters


The IR has to be able to process the routing parameters sent by the D2D Journey Planner for its internal route calculation and to send back the calculated routes (Response) to the D2D JP

The IR has to take into account all routing parameters sent by the D2D JP (except landside parameters) and sends back at least 1 route in a response

Mandatory

IR_017 The IR needs to be able to consider areas not to be entered in its navigation


In order to route the user around restrictedareas in case of terminal closures or

Mandatory


44 / 86

avoid the use of closed elevators, staircases or entries the IR needs to be able to define restricted polygons or POIs

Table 8: Technical Requirements DORA Indoor Router

5.1.6 Intermodal Landside Router


ILR_001 ILR needs to have access to modal routers for public transport, car, bike and walking per test site

Intermodal Landside Router


The ILR i only combines the routes provided by the single modal routers in each test site. The more modal routers are connected to the ILR the more different modes of transport can be taken into account for the route calculation

The ILR has access to at least the modal routers for public transport, car and walking for both Berlin and Palma test site.

Mandatory

ILR_002 The ILR should have access to different Location Based Services (LBS) in each test site such as car



Location Based Services extend the variety and quality of route suggestions

Per test site at least one LBS needs to be accessible by the ILR

Mandatory


45 / 86

sharing, bike sharing, charging infrastructure, parking facilities etc.

ILR_003 The connected local modal routers need to calculate the routes based on real-time traffic situation, traffic incidents, disruptions, delays



In order to provide time-optimised routes for door-to-door mobility the route suggestions have to be based on real-time data

At least the modal routers for public transport and car calculate routes based on real-time data

Mandatory

ILR_004 Response times of local modal routers


Performance requirements

Each routing service which contributes to the calculation of the overall door-to-door route needs to respond as fast as possible in order to achieve an adequate user acceptance

the response times of the local modal routers should be under 5 seconds

Mandatory

ILR_005 The single local modal routers need to be able to calculate routes optimised by different criteria



The single local modal routers need to be able to calculate routes optimised by length, duration, CO2-emissions and price

Mandatory

ILR_006 All services connected to the ILR have to be able to process coordinates based on the WGS84 coordinate



It is important to use a common coordinate system among all routing services

Mandatory


46 / 86

system

ILR_007 ILR takes into account personal trip preferences



The ILR is able to take into account personal trip preferences of the user which are locally stored in the frontend (especially in the App)

The ILR is able to integrate least two different user preferences into the trip calculation

Mandatory

ILR_008 ILR calculates intermodal routes



The ILR uses the specialized modal routers for calculating single modal routes and combines them to intermodal routes containing of more than only one traffic type

The ILR calculates intermodal routes for at least the combination of bike and public transportation and car with public transportation

Mandatory

ILR_009 Valid GTFS data for the PT is necessary for Palma and Berlin



The ILR needs to be provided for pre-calculations valid GTFS data for the public transportation systemfor both clusters Palma and Berlin

GTFS data is integrated or connected to the Intermodal Landside Router

Mandatory

Table 9: Technical Requirements DORA Intermodal Landside Router


47 / 86

5.1.7 Operation Centre Application


MIM_001 Monitor the trip Mobility & Incident Management Panel


It must be continuously checked the user is not having incidents on the trip

The monitoring process warns the user if there is any possible deviation during the trip

Mandatory

MIM_002 Connect DORA to Operation Centres

Mobility & Incident Management Panel


Incidents are provided by 3rd parties, and DORA System must be able to receive them

DORA receives information from the Operation Centres

Mandatory

MIM_003 Monitor incidents Mobility & Incident Management Panel


As soon as an incident is received DORA checks if it affects any trip plan

Users are warned if an incident affects them

Mandatory

MIM_004 Handle Traffic news Mobility & Incident Management Panel


As soon as a traffic news is received all subscribed users, like DORA system, are informed

Users are informed as soon as an incidence happens

Mandatory

MIM_005 Handle disturbances at the airport



As soon as am incident at the airport is received all subscribed users, like DORA system, are informed

Users are informed as soon as an incidence happens

Mandatory

MIM_006 Handle real time data Mobility & Incident Management Panel


DORA System gathers real time information

DORA System is constantly received

Mandatory


48 / 86

updated real time information

MIM_007 Handle transport network information



DORA System gathers transport network information

DORA System is constantly received updated transport network information

Mandatory

MIM_008 The MIM needs to support automated and manual entries of incidents into the system



Incidents can come from data providers but might also be entered manually by Operation Centre staff

Mandatory

MIM_009 Enter airport disturbance



Airport staff can add new disturbances into the system

Airport staff can add new disturbances into the system

Mandatory

MIM_010 Close airport disturbance



Airport staff can end closed disturbances

Airport staff can end closed disturbances

Mandatory

MIM_011 Edit airport disturbance



Airport staff can edit disturbances happening on the airport

Airport staff can edit disturbances happening on the airport

Mandatory

Table 10: Technical Requirements DORA Mobility & Incident Management Panel

5.1.8 Strategic Routing Service


SRS_001 The SRS provides static strategies to influence the computed route

Strategic Routing Service


The SRS provides static strategies to inform the passenger in

At least two static strategies have to be installed per pilot

Mandatory


49 / 86

recommendations advance and traffic or passenger flows can be controlled as required before a delay or disruption occurs

cluster

SRS_002 The SRS provides dynamic strategies to influence the computed route recommendations



The SRS provides dynamic strategies to inform the passenger during a delay or disruption

At least two dynamic strategies have to be installed per pilot cluster

Mandatory

SRS_003 The strategic routing service is linked to all Routing Services of DORA



To cover for all involved modal routing services strategic routing procedures, the SRS needs to be connected to the other DORA routing systems

SRS is connected to all routing services of DORA

Mandatory

SRS_004 Based on pre-defined strategies the control centres of air transport, public transport and road traffic, manage disruptions consistently



The SRS provides strategies which can be activated through the different Management Panels

At least the traffic information centres and the airport control centres could activate pre-defined strategies

Mandatory

Table 11: Technical Requirements DORA Strategic Routing Service


50 / 86

5.1.9 Flight Information Service


FIS_001 Integration of real-time departure and arrival data from local existing flight info services

Flight Information Service


FIS needs to be connected to local real-time flight information data sources in order to receive real-time departure and arrival times

Real-time flight information for 3 days in advance (72 hours before departure time) need to be integrated for the following airports: PMI, BER, SXF

Mandatory

FIS_002 Integration of scheduled departure and arrival data from local existing flight info services



FIS needs to be connected to local scheduled flight information data sources in order to receive departure and arrival times for the trip planning process

Scheduled departure and arrival information needs to be integrated for 3 months in advance and for at least the following flight connections: PMI <-> SXF, PMI <-> BER

Mandatory

FIS_003 Integration of real-time terminal number, gate and check-in counter data from local existing flight info services



FIS needs to be connected to local real-time flight information data sources in order to receive real-time terminal, gate and check-in counter information

Real-time terminal, gate and check-in counter information for 3 days in advance (72 hours before departure time) need to be integrated for the following airports: PMI, BER, SXF

Mandatory


51 / 86

FIS_004 Integration of scheduled terminal number, gate and check-in counter data from local existing flight info services



FIS needs to be connected to local scheduled information data sources in order to receive terminal number, gates and check-in counters for a flight number for the trip planning process

Scheduled terminal, gate and check-in counter information needs to be integrated for 3 months in advance and for the following airports: PMI, SXF, BER

Optional

FIS_005 The FIS needs to be able to calculate flight connections based on the routing parameters time, date, departure and destination airports



In order to enable the D2D Journey Planner to calculate door-to-door routes, the FIS needs to provide suitable flight connections

The FIS needs to calculate at least two flight connections based on the routing parameters transmitted by the D2D Journey Planner and send it back in a response over the DORA Open Service API

Mandatory

FIS_006 The FIS needs to provide the following information for the calculated flight connections: Duration, length, flight number, flight operator, departure airport, arrival airport, planned terminal number, check-in counter and



Different information has to be provided by the FIS, to enable the D2D Journey Planner to combine the different partial routes to seamless door-to-door connections

The above mentioned information should be provided for at least the following flight connections: PMI <-> BER, PMI <-> SXF

Mandatory


52 / 86

gate number

FIS_007 The FIS should provide the following information for the calculated flight connections: CO2-emissions, aircraft type



The information mentioned would improve the flight connection information provided to the user and enable the Door-to-Door Journey Planner to calculate CO2 emissions for the entire trip

Optional

FIS_008 The FIS should provide the following information for the calculated flight connections: luggage belt numbers of selected flights



The luggage belt number and locations are needed for indoor routing purposes

At least the luggage belt numbers for Berlin - Palma connections in the airport areas detected with DORA indoor positioning technologies should be provided

Optional

Table 12: Technical Requirements DORA Flight Information Service

5.1.10 Trip Monitoring Service


TMS_001 The TMS supervises the current journey of

Trip Monitoring Service


The Trip Monitoring will be provided with

The TMS forces a re-routing for at least

Mandatory


53 / 86

the passenger trip details, being calculated by the D2D-Journey Planner in order to force a re-routing in case of significant changes of the trip

disturbances in the street network.

TMS_002 TMS is provided with trip information of routes to be supervised



To supervise the current trip of the passenger, the TMS needs the information of the current trip from the D2D-Journey Planner

An internal interface is realized from D2D-Journey Planner to the TMS to transfer trip details

Mandatory

TMS_003 The TMS is provided with current disruptions in the street environment



The TMS is provided through local (existing) services with real time data about the individual traffic environment having an impact on travel times

The TMS alerts in cases of disturbances in the street network

Mandatory

TMS_004 The TMS is provided with current disruptions in the public transport



The TMS is provided through local (existing) services with real time data about the PT network having an impact on travel times

The TMS alerts in cases of disturbances in the PT network

Mandatory

TMS_005 The TMS is provided with current disruptions in the



The TMS is provided through local (existing) services with real time

The TMS alerts in cases of disturbances in the terminal

Mandatory


54 / 86

terminal data about the indoor airport environment having an impact on travel times

TMS_006 The TMS is provided with current disruptions or changes of the flight



The TMS is provided through local (existing) services with real time data about flight changes or delays having an impact on travel times

The TMS alerts in cases of flight disturbances

Mandatory

TMS_007 TMS alerts through a central messaging service in case of disruptions



Does the disruption or the delay have an impact on the planned or current trip, TMS alerts through push (iOS, Android) and through mail; and forces a re-routing

TMS alerts at least in case of disruptions for the chosen land side transport modes and the flight

Mandatory

TMS_008 Incidents status is monitored



Active incidents are marked as inactive or cleared when disruptions cease to exist

Planning resumes normal calculations after incident marked as inactive.

Mandatory

TMS_009 TMS needs to update the status of incidents and cancel incidents that are no longer valid



Only current incidents should be taken into account

Mandatory

Table 13: Technical Requirements DORA Trip Monitoring Service


55 / 86

5.1.11 Waiting Time Detection


WTS_001 Current mean service time

Waiting Time Service Functional and data requirements

The main aim of this service is to provide a time estimation to pass a given queue

There is a REST service able to provide a time value (minutes or seconds) for a given queue

Mandatory

WTS_002 Historical mean service time


By planning the journey (future event) there is a need to estimate the mean queue time at a given timestamp based on historical data

There is a REST service able to provide a historical mean value for a given timestamp (day, hour)

Mandatory

WTS_003 General identification of queue nodes


Queues supporting WTS are placed on nodes also used by other services in DORA (e.g. Indoor routing, DORA app). Thus, there should be a unique way of identifying them in the DORA system

There is a global ID for the queue nodes shared by all involved DORA services.

Mandatory

WTS_004 WTS Response Time (3s)

Waiting Time Service Performance requirements

The service must respond with low response time in order

The service is able to respond to a query (current or historical

Mandatory


56 / 86

not to delay other services interacting with it (DORA app, Indoor Routing)

mean) below 3s

WTS_005 WTS provides the DORA system through the Open Service API with WT information


The WT has to be provided for security checks and is optional for gates and check-in counters

The waiting time for security checks is provided by the WTS

Mandatory

Table 14: Technical Requirements DORA Waiting Time Service


57 / 86

5.2 Validation and Revision Process

This chapter gives an overview about the validation and revision process in the VOLERE approach. After the technical requirements were

initially defined, they were double checked by all developing project partners. In this validation process dependencies and conflicts between

requirements and objections could be marked out. With the help of comments in the VOLERE tool, a discussion on specific requirements was

initiated until existing problems with a requirement could be solved. The tables below are supposed to transparently illustrate this discussion.

5.2.1 Dependencies

Id. Dependency Requirements revised Validator's aprovement Reviser’s comments

DEP_223 While provisioning POIs to apps, a metadata value providing images should be available in the POI data model

UPVLC (Benjamin Molina) UPVLC (Benjamin Molina) Comment 1 by CSE (Konstantinos Koutsopoulos):

APP_018 regards not only POIs but cases like specific lifts, stairs, entrances that may not be linked to POIs

IR_013 Comment 2 by UPVLC (Benjamin Molina):

Kostas is right; typically a POI does not include lists, stairs and so on. However in our data model a POI is almost everything and it is its category that determines what is is, though it may have multiple categories.


58 / 86

CSE (Konstantinos Koutsopoulos)

Comment 3 by UPVLC (Benjamin Molina):

From another point of view, the data model will include images (or links to it), but the generation of images for airport nodes/pois is not considered urgent from UPVLC. We may help after the maps have been georeferenced. Updated IR_013

APP_018 Comment 4 by CSE (Konstantinos Koutsopoulos):

Given the priority of APP_018 I consider that dependency is OK

DEP_224 In order to obtain an accurate value, the positioning algorithm must consider overall changes in the RSSI values due to environmental conditions.

UPVLC (Benjamin Molina) UPVLC (Benjamin Molina) Comment 1 by UPVLC (Benjamin Molina):

It is possible that various parallel Fingerprinting grids according to environmental status are measured. This will be evaluated after deployment and testing.Updated IP_008

IP_008


IP_010

DEP_225 The personal preferences in terms of routing parameters need to be consistent

VMZ (Tom Schilling) VMZ (Jan-Niklas Willing)

APP_004

DJP_007

ILR_007


59 / 86

DEP_226 Using inertial sensor data from mobile devices helps improving accuracy. The Fingerprint DB is set up by a physical grid that determines the accuracy of the positioning algorithm; inertial sensors help adding greater granularity level.


The though is that inertial sensors may be used reveal the position of the body or the walking direction so as to combine it with beacon positions.

IP_003 Comment 2 by UPVLC (Benjamin Molina):

Right, the idea is trying to be as accurate as possible, including inertial sensors, but depending on various criteria it may be variable in the airport. We should more focus on not confusing the user/traveller. Updated IP_008

IP_008 Comment 3 by CSE (Konstantinos Koutsopoulos):

These enhancements and complexity might be subject to future investigation and therefore low priority for IP_013 complies with the envisaged approach.

IP_009


IP_013

DEP_227 MIM_001 is required so that APP_006 can work


APP_006

ETRA (Germán Fco. Martínez Navarro)

MIM_001


60 / 86

DEP_228 MIM_001 and MIM_003 both depends of those requirements that provide some information needed to be constantly checking if the user is on the right way

VMZ (Tom Schilling) ETRA (Germán Fco. Martínez Navarro)

Comment 1 by CSE (Konstantinos Koutsopoulos):

TMS_008 regards removal of an incident so as not to be taken into consideration.

APP_016 Comment 2 by VMZ (Tom Schilling):

Please see new requirement TMS_09

TMS_001 Comment 3 by VMZ (Jan-Niklas Willing):

TMS_009 has been deleted as it was identical with TMS_008

TMS_002 Comment 4 by UPVLC (Benjamin Molina):

The navigation library will provide means to locate and 'navigating' the user. But we should define when it is supposed that the user is not in its right way indoors (it is not always clear). Updated IR_001

TMS_003 Comment 5 by ETRA (Germán Fco. Martínez Navarro):

The idea of MIM_001 and MIM_003 is checking if open Incidents are closed, but it is what TMS_008 does, so they should be removed.

TMS_004

TMS_005

TMS_006

TMS_007

VMZ (Jan-Niklas Willing)

TMS_009

UPVLC (Benjamin Molina)

IR_001


61 / 86

IR_012


MIM_001

MIM_003


TMS_008

DEP_229 DJP_007 needs a re-route button on the user app to be invoked, that is stated on WEB_004

VMZ (Tom Schilling) ETRA (Germán Fco. Martínez Navarro)

Comment 1 by VMZ (Tom Schilling):

See that the web based version wouldn´t support trip monitoring functionalities

DJP_007 Comment 2 by ETRA (Germán Fco. Martínez Navarro):

Agree. It should be a functionality of the AppETRA (Germán Fco. Martínez

Navarro)

WEB_004

DEP_230 For handling disturbances at the airport (MIM_005) is needed some mechanism to detect those problems

VMZ (Jan-Niklas Willing) ETRA (Germán Fco. Martínez Navarro)

Comment 1 by VMZ (Jan-Niklas Willing):

The Flight Information Service does not provide information on disturbances in the terminals. The FIS only provides flight connections, terminal and gate numbers. Disturbances in the airports should be provided in the MIM itself by airport staff


62 / 86

FIS_003 Comment 2 by ETRA (Germán Fco. Martínez Navarro):

MIM_009, MIM_010 and MIM_011 allow the airport stuff to add/edit/close disturbances happening on the airport. MIM_005 is removed then

FIS_004


MIM_005

DEP_231 TMS_008&9 depend on the info provided via MIM_003-8

VMZ (Jan-Niklas Willing) CSE (Konstantinos Koutsopoulos)


TMS_009 was deleted as it is the same as TMS_008 (see above)MIM_008

TMS_009


MIM_003

MIM_004

MIM_005

MIM_006

MIM_007


TMS_008


63 / 86

DEP_232 For handling the entry of information on the DORA System (traffic new, disturbances at the airport, real time data, transport network information) the system must offer support for that task (MIM_008)

VMZ (Jan-Niklas Willing) ETRA (Germán Fco. Martínez Navarro)


Some incidents might be inserted manually (e.g. incidents at the airports (door malfunctions, closed areas)) others might be generated automatically such as road closures

MIM_008 Comment 2 by ETRA (Germán Fco. Martínez Navarro):

MIM_009, MIM_010 and MIM_011 let the airport staff to handle any disturbance happeningthere. MIM_002 connects DORA system to Operation Centres to receive real time disturbances.


MIM_004

MIM_005

MIM_006

MIM_007

DEP_233 Battery life regards both beacons and mobile devices. Scanning and beacon transmissions have to be evaluated for saving battery in both transmitting and receiving devices.

UPVLC (Benjamin Molina) CSE (Konstantinos Koutsopoulos)


End devices cannot be constantly monitoring the emitted beacons. Any increase in the frequency may deplete phone's battery very quickly. Scanning has to be assisted by extra info (beacon interval in certain areas, etc.). This is subject to evaluation.

IP_002


IP_011

DEP_234 Support of IP in iOS devices necessitates the investigation of BLE integration in Beacons with the same requirements described in IP_00X requirements indicated

VMZ (Tom Schilling) CSE (Konstantinos Koutsopoulos)


BLE has been added to requirements.APP_002

APP_014

IP_019


64 / 86


IP_010

IP_011

IP_012

IP_014

IP_016

DEP_235 Wi-Fi and/or BLE beacons must be compliant with EU regulation regarding wireless signals



The use of certified transceivers is taken into account in the design. As presented also in the internal requirements list.

SWA_001


IP_011

IP_012

IP_014

IP_015

DEP_236 All services providing routing functions need to use WGS 84 coordinate system

VMZ (Tom Schilling) VMZ (Jan-Niklas Willing) Comment 1 by UPVLC (Benjamin Molina):

Updated IP_008, IR_001 to explicitly include return values in WGS84 values

DJP_001


ILR_006


IP_008

IR_001

DEP_237 implementation of indoor navigation library has to be


UPVLC can provide libraries in Javascript (Ionic/Phonegap), APP_015


65 / 86

coordinated between App and IR developing partners

UPVLC (Benjamin Molina) probably in Java (Android), but we do not develop for iPhone.IR_001

DEP_238 The gate and check-in numbers of each flight will be available only 3 days in advance depending on the real-time flight data sources used by the airports. As soon as this data is available the DORA flight information service provides this data for other services.

VMZ (Jan-Niklas Willing) VMZ (Jan-Niklas Willing) Comment 1 by UPVLC (Benjamin Molina):

We (UPVLC) do not know the endpoints for such AIS services yet. For offline planning (e.g. a week before) we should agree on how to provide indoor results (arbitrary counter and gate??)

FIS_003


IR_003

DEP_239 The Indoor Router and the Intermodal Landside Router should be able to process routing strategies provided by the Strategic Routing Service


I agree, but I would like to know what type of strategies to check whether it is feasible. anyway, I don't see initially any impact on IR_012

SRS_003


ILR_003


IR_012

Table 15: Technical Requirements Dependencies


66 / 86

5.2.2 Conflicts

Id. Conflict Requirements revised Validator's approvement Reviser’s comments

CONF_102 The positioning algorithm works properly when the beacon transmission power is always the same. The reception power may change due to environmental conditions, but the transmission power should be as constant as possible.


Tx power will remain the same, however it should be possible to configure it before installation

IP_003

IP_008


IP_014

CONF_103 IP based on wifi beacons is not initially foreseen for iOS devices.


Comment 1 by VMZ (Tom Schilling):

The iOS version of the App is mandatory, therefore this issue should be solved

APP_002 Comment 2 by UPVLC (Benjamin Molina):

I do not know how to solve this only with Wi-Fi, as iOS SDK does not help much on this.

APP_014

IP_019


IP_002

CONF_104 MIM does not monitor the trip. This is handles by TMS.

VMZ (Tom Schilling) VMZ (Tom Schilling) Comment 1 by CSE (Konstantinos Koutsopoulos):

TMS should check if MIM has cleared an event so as not consider it any more.

TMS_001 Comment 2 by VMZ (Tom Schilling):

A new requirement was entered to solve this; TMS_09


67 / 86

TMS_002 Comment 3 by ETRA (Germán Fco. Martínez Navarro):

MIM_001 should do what Tom Schilling proposed on TMS_09. So MIM_001 can be removed

TMS_003 Comment 4 by VMZ (Jan-Niklas Willing):

TMS_009 was removed as it was identical with TMS_008. What is said here about TMS_009 thus applies to TMS_08 instead

TMS_004

TMS_005

TMS_006

TMS_007


TMS_009


MIM_001


TMS_008

CONF_105 The WEB GUI will not support the alert functionality in case of disruptions on the trip after starting a trip.


VMZ (Tom Schilling) Comment 1 by ETRA (Germán Fco. Martínez Navarro):

Totally agree. These should be requirement for the DORA App. They have been moved from "DORA Web GUI" to "Dora App"

WEB_002

WEB_003

WEB_004

Table 16: Technical Requirements Conflicts


68 / 86

5.2.3 Objections

Id. Objection Requirements revised Validator's approvement Reviser’s comments

OBJ_914 If the inter-beacon time is significantly incremented to reduce battery life, it will take more time for the mobile app to collect all RSSI measurements, which might impact the overall response time (requesting the server, calculating the position and sending response back)


Indeed there is need for balancing this. In lab experiments so far Mobile Device can cope with 400ms period but with continuous scanning. We have to see this in more experiments.

IP_007 Comment 2 by CSE (Konstantinos Koutsopoulos):

We are currently in the process of re-evaluating the overall design so as to be more optimal with respect to battery issues. The aim is to manage to have frequent transmissions but the current SotA is not offering such solution w/o power cost.

CSE (Konstantinos Koutsopoulos) Comment 3 by CSE (Konstantinos Koutsopoulos):

An initial version with increased inter-tx time might be used as a starting point.

IP_011

OBJ_915 Up to our knowledge, mobile APIs do not allow accessing low level

CSE (Konstantinos Koutsopoulos) UPVLC (Benjamin Molina) Comment 1 by CSE (Konstantinos

Extra information will be used as temporary suffix after the SSID no


69 / 86

information from the beacon frame. It seems reasonable to keep priority 1 for this requirement.

IP_012 Koutsopoulos): need to access beacon packet fields.

OBJ_916 Maybe this requirement should be optional because it is not clear yet if car sharing reservation functions can be provided in the DORA app


APP_012

OBJ_917 Scheduled flight data probably does not include gate, check-in counter information. Terminal number might be available though

VMZ (Jan-Niklas Willing) VMZ (Jan-Niklas Willing)

FIS_004

Table 17: Technical Requirements Objections


6 LEGAL REQUIREMENT SPECIFICATION

6.1 Security Requirements: Privacy and Data Protection

This section provides an overview of the Privacy and Data Protection framework to be used

in DORA. The project involves the collection of personal data, in different countries of the

European Union such as Spain and Germany, where the pilot sites are located. Moreover,

although being under the same European directives, the national laws of EU member states

might have differences. Therefore, a close follow up of data protection requirements in each

pilot site will be carried out.

The collection, processing and transmission of personal data must be analysed under the

principles of Directive 95/46/EC (1) and especially the respective national laws. Any

additional regulations at European or national level that are not in the Directive and apply to

Data Protection or any other sensitive information have to be also taken into account.

6.1.1 EU Legislation and Regulation

In the European ambit, Directive 95/46/EC was created in order to approximate the state

legislation on personal data protection that exists in the EU member states. Differences

indeed exist between the national regulations, despite the spirit of the directive, whose

main objective was to harmonise the level of personal data protection in all member states.

The Directive sets out the principles and procedural minimum requirements to be

considered so that protection is adequate. There are two types of principles:

Those to be taken into account in the time to collect data

Those to be taken into account during the processing of the data

Data should be or fulfil the following principles:

Collected for specified, explicit and legitimate purposes and untreated subsequently

incompatible way with those purposes

Updated when necessary

Preserved for no longer than is necessary for the purposes for which they were

collected

Prohibition on the processing of sensitive data (personal data relating to racial or

ethnic origin, religious or philosophical beliefs, trade union membership and data

concerning health and sexuality)

Confidentiality of the data collected, security and consent from the subject

Subject access rights and opposition


71 / 86

The common framework derived from the Directive 95/46/EC is as follows:

Personal Data Treatment Census And Analysis

It is necessary to census all personal treatments in order to have a clear picture of the scope

of work. Each personal data treatment should be analysed in order to clarify:

Who the data controller1 is

Who the possible data processors2 are and who actually manages the data

To verify the lawfulness of data treatment

To identify all the means by which the treatment is performed and stored (e.g.

application systems, paper folder, etc.)

Law Analysis

To identify, also according with national laws, the accomplishments need for each data

treatment. Such as:

Information to data subjects

Consent by data subjects3

Formal identification of data processor

Formal identification of people in charge of data treatment

Possible notification to the local data protection authority

Analysis of information management security system

1The natural or legal person, public authority, agency or any other body which alone or jointly with others

determines the purposes and means of the processing of personal data; where the purposes and means of

processing are determined by national or Community laws or regulations, the controller or the specific criteria

for his nomination may be designated by national or Community law.2 A natural or legal person, public authority, agency or any other body which processes personal data on behalf

of the controller.3

Any freely given specific and informed indication of his wishes by which the data subject signifies his

agreement to personal data relating to him being processed.


72 / 86

Member States shall provide that one or more supervisory authorities to monitor the

implementation of the Directive. One responsibility of the supervisory authority is to

maintain an updated public register enabling widespread access to the names of all data

controllers and its characteristics.

As a general rule, all data controllers must notify the supervisory authorities if they are

processing data. Member States may simplify or exempt from notification procedure certain

kinds of treatment that do not involve special risks.

Each data controller must assume the data processing rules of the Member State where they

are, even if the data processed belong to an individual residing in another member state.

Some app owners may wish to include an End User License Agreement (EULA) in their

application in order to explicitly limit liability and establish terms of use of the application, in

particular related to data that may be collected and used. EULA's may be displayed in a first-

use pop-up after the user has installed the app, or it may be referenced elsewhere in the app

such as under the app's "Settings" view. App owners should consult with their legal advisors

to establish an appropriate EULA (2).

Another option is to attach a terms and conditions agreement that includes the terms, the

rules and the guidelines of acceptable behaviour, plus other useful sections, to which users

must agree in order to use or access a website or mobile app, such as the DORA app.

The Article 29 Data Protection Working Party was set up under Article 29 of Directive

95/46/EC and it is an independent European advisory body on data protection and privacy.

In their “Opinion 02/2013 on apps on smart devices” (3), the Working Party clarifies the legal

framework applicable to the processing of personal data in the development, distribution

and usage of apps on smart devices, with a focus on the consent requirement, the principles

of purpose limitation and data minimisation, the need to take adequate security measures,

the obligation to correctly inform end users, their rights, reasonable retention periods and

specifically, fair processing of data collected from and about children. According to this

report, app developers must:

Be aware of, and comply with, their obligations as data controllers when they process

data from and about users;

Be aware of, and comply with, their obligations as data controllers when they

contract with data processors such as if they outsource the collection and processing

of personal data to developers, programmers and for example clo ud storage

providers;


73 / 86

Ask for consent before the app starts to retrieve or place information on the device,

i.e., before installation of the app. Such consent has to be freely given, specific and

informed;

Ask for granular consent for each type of data the app will access; at least for the

categories: Location, Contacts, Unique Device Identifier, Identity of the data subject,

Identity of the phone, Credit card and payment data, Telephony and SMS, Browsing

history, Email, Social networks credentials and Biometrics;

Be aware that consent does not legitimise excessive or disproportionate data

processing;

Provide well-defined and comprehensible purposes of the data processing in advance

to installation of the app, and not change these purposes without renewe d consent;

provide comprehensive information if the data will be used for third party purposes,

such as advertising or analytics;

Allow users to revoke their consent and uninstall the app, and delete data where

appropriate;

Respect the principle of data minimisation and only collect those data that are strictly

necessary to perform the desired functionality;

Take the necessary organisational and technical measures to ensure the protection of

the personal data they process, at all stages of the design and implementation of the

app (privacy by design);

Provide a single point of contact for the users of the app;

Provide a readable, understandable and easily accessible privacy policy, which at a

minimum informs users about:

o who they are (identity and contact details),

o what precise categories of personal data the app wants to collect and

process,

o why the data processing is necessary (for what precise purposes),

o whether data will be disclosed to third parties (not just a generic but a specific

description to whom the data will be disclosed),

o what rights users have, in terms of withdrawal of consent and deletion of

data;

Enable app users to exercise their rights of access, rectification, erasure and their

right to object to data processing and inform them about the existence of these

mechanisms;

Define a reasonable retention period for data collected with the app and predefine a

period of inactivity after which the account will be treated as expired;

The Working Party recommends that app developers:

Study the relevant guidelines with regard to specific security risks and measures;


74 / 86

Proactively inform users about personal data breaches along the lines of the

requirements of the ePrivacy Directive (2002/58/EC, as revised by 2009/136/EC)4;

Inform users about their proportionality considerations for the types of data

collected or accessed on the device, the retention periods of the data and the applied

security measures;

Develop tools to enable users to customise retention periods for their personal data

based on their specific preferences and contexts, rather than offering pre -defined

retention terms;

Include information in their privacy policy dedicated to European users;

Develop and implement simple but secure online access tools for users, without

collecting additional excessive personal data;

Together with the OS and device manufacturers and app stores use their creative

talent to develop innovative solutions to adequately inform users on mobile devices,

for example through a system of layered information notices combined with

meaningful icons.

Particularly in the DORA system, the consent of the passenger that his/ her device and route

is going to be tracked will be required. It is very important to ensure passengers’ consent for

using particular part of DORA applications, where privacy issues occur.

Although the way of harmonization of legislation, regarding processing of personal data, it

seemed to have culminated in the Directive 95/46/EC, however it will require additional

regulatory efforts to bring the still distant data protection laws of the various Member

States.

On 15 December 2015, the European Parliament, the Council and the Commission reached

agreement on the new data protection rules, establishing a modern and harmonised data

protection framework across the EU: The General Data Protection Regulation (4). The

Regulation is an essential step to strengthen citizens' fundamental rights in the digital age

and facilitate business by simplifying rules for companies in the Digital Single Market. A

single law will also do away with the current fragmentation and costly administrative

burdens, leading to savings for businesses. The final texts will be formally adopted by the

European Parliament and Council at the beginning 2016. Therefore, the new rules will

become applicable two years thereafter. As a Regulation and not a Directive, it will have

immediate effect on all EU Member States after the transition period and does not require

4ePrivacy directive sets a specific standard for all parties worldwide that wish to store or access information

stored in the devices of users in the European Economic Area (EEA).


75 / 86

any enabling legislation to be passed by governments. The Commission will work closely with

Member State Data protection authorities to ensure a uniform application of the new rules.

During the two-year transition phase, the Commission will inform citizens about their rights

and companies about their obligations. The Regulation updates and replaces the current

Data protection rules that are based on the 1995 Data Protection Directive, so the DORA

consortium will monitor its implementation in the coming years as long as it affects the

DORA system data protection issues.

The new rules will strengthen the existing rights and will empower individuals with more

control over their personal data. Most notably, these include:

Easier access to your own data: individuals will have more information on how their

data is processed and this information should be available in a clear and

understandable way

A right to data portability: it will be easier to transfer your personal data between

service providers

A clarified "right to be forgotten": when you no longer want your data to be

processed, and provided that there are no legitimate grounds for retaini ng it, the

data will be deleted

The right to know when your data has been hacked: companies and organisations

must notify the national supervisory authority of serious data breaches as soon as

possible so that users can take appropriate measures

By unifying Europe's rules on data protection, lawmakers are creating a business opportunity

and encouraging innovation though:

One continent, one law: The regulation will establish one single set of rules which will

make it simpler and cheaper for companies to do business in the EU.

One-stop-shop: businesses will only have to deal with one single supervisory

authority.

European rules on European soil– companies based outside of Europe will have to

apply the same rules when offering services in the EU.

Risk-based approach: the rules will avoid a burdensome one-size-fits-all obligation

and rather tailor them to the respective risks.

Rules fit for innovation: the regulation will guarantee that data protection safeguards

are built into products and services from the earliest stage of development (Data

protection by design). Privacy-friendly techniques such as pseudonymisation will be

encouraged, to reap the benefits of big data innovation while protecting privacy.


76 / 86

6.1.2 National Laws: Spain and Germany

Following, a summary of current applicable Data Protection legislation in the pilot countries

is provided.

Spain

Protection of personal data is attained though Personal Data Protection Law: Organic Law

15/1999 (5) regarding organizational measures to ensure the security of Electronic Personal

Data Files and documentation procedure concerning incidents affecting personal data. The

purpose of the Data Protection Law is to guarantee and protect civil liberties and

fundamental rights of individuals, and especially their honour and personal and family

privacy with regard to the processing of personal data.

The liability regime determines that those responsible for the files and those in charge of

treatment will be subject to the sanctions regime established by this law. The sanctioning

body is the director of the Spanish Agency of Data Protection. The offenses are classified as

minor, serious and very serious. There are different types of applicable sanctions, classified

according to severity.

Data protection authority in Spain is the Spanish Agency of Data Protection (Agencia de

Protección de Datos, (http://www.agpd.es/portalwebAGPD/index-iden-idphp.php).

Germany

In Germany, the transposition of Directive 95/46/EC carried out by the Federal Data

Protection Act (FDPA) (6), adopted on 18 May 2001.

Unlike the Spanish Personal Data Protection Law, the German law does not specify the

subject recipients of the regulation. German law provides for criminal offenses and their

consequences within the same data protection law, namely Federal Data Protection Act.

This FDPA prescribes in § 4, paragraph 1 for the collection, processing and use of personal

data the use of the FDPA or another legal provision, which allows or authorizes the use of

personal data. Otherwise a consent form from the user must be obtained.

Data protection authority in Germany is „Der Bundesbeauftragte für den Datenschutz“

(http://www.bfdi.bund.de/DE/Home/home_node.html).


77 / 86

6.1.3 DORA System Privacy Requirements

Specification of what the DORA system has to do to insure the privacy of individuals that it

stores information about. The system must also ensure that all laws about privacy of an

individual's data are observed:

The DORA system shall ask for user consent before the app starts to retrieve or place

information on the device.

The DORA system shall ask for granular consent for each type of user data the app

will access (Location, Unique Device Identifier, Identity of the data subject, Identity of

the phone, Telephony and SMS, Browsing history, Email, Social networks credentials).

The DORA system shall provide well-defined and comprehensible purposes of the

data processing in advance to installation of the app, and not change these purposes

without renewed consent; provide comprehensive information if the data will be

used for third party purposes.

The DORA system shall allow users to revoke their consent and uninstall the app, and

delete data where appropriate.

The DORA system shall ensure the protection of the personal data, at all stages of the

design and implementation of the app (privacy by design).

The DORA system shall provide a single point of contact for the users of the app.

The DORA system shall provide a readable, understandable and easily accessible

privacy policy for the users.

The DORA system shall inform the users about the existence of mechanisms to

exercise their rights of access, rectification, erasure and their right to object to data

processing.

The DORA system shall define a reasonable retention period for data collected with

the app and predefine a period of inactivity after which the user account will be

treated as expired.


78 / 86

6.2 DORA System Standards Requirements

The DORA system standards requirements consist on specifying applicable standards and

referencing detailed standards descriptions to the DORA system. The main standards that

could be identified concern standards for public transport related passenger information:

About 600 companies performing public passenger transport and rail freight t ransport in

Germany are organised in the “Verband Deutscher Verkehrsunternehmen” (VDV =

Association of German Transport Companies). The VDV prepares technical, operational

principles and defines interfaces.

Integration Interface for Automatic Vehicle Management Systems – VDV 453

Connection protection

Dynamic passenger information

Visualisation

General message service

Integration Interface for Automatic Vehicle Management Systems – VDV 454

Schedule Information

The underlying concept as outlined in recommendation VDV 453 and VDV 454 follows the

approach of a universal interface for the integration of AVMS systems (Automatic Vehicle

Management Systems), which allows the participating transport operators to implement

such functionality at an acceptable cost. Technical implementation is based on standard

technologies (http/XML). It defines common limiting requirements on the design of the

interface and describes the data exchange in detail (subscription procedure). The modern

service architecture with a communication structure based on the subscription method

provides a simple means of integrating further services, even to external non -AVMS specific

systems.

The recommendations VDV 453 and VDV 454 represent the subset of the “CEN” (Comité

Européen de Normalisation) standard “SIRI” (Service interface for real-time information

relating to public transport operations). They reduce the number of optional data elements

and alternative communication methods described in SIRI to a well -defined selection, which

has proven its efficiency in numerous real time projects in Germany and neighbouring

countries. The CEN standard was developed with representatives from France, Germany,

Scandinavia and UK and is based on Transmodel. SIRI is a CEN standard since 2007. VBB has

not yet used the SIRI standard.

On the initiative of VDV and funded by the Federal Ministry of Economics, the research and

standardization project „Internet Protokoll basierte Kommunikationsdienste im öff entlichen


79 / 86

Verkehr (IP-KOM-ÖV)“ [Internet Protocol-based Communications services in Public

Transport] was started in 2010.

The DORA system shall furthermore comply with the E-ticketing standard of the Association

of German Transport Companies. This standard called “VDV-Kernapplikation” is an open

data and interface standard regulating E-Ticketing-processes in Germany. This standard is

the only acknowledged standard for electronic tickets for public transport in Germany.


6.3 List of Legal Requirements

Requirement ID



LEG_001 Ask for user consent on each type of user data the app will access (Location, Unique Device Identifier, Identity of the data subject, Identity of the phone, Telephony and SMS, Browsing history, Email, Social networks credentials).

DORA App Security requirements

DORA shall ask for user consent before the app starts to retrieve or place information on the device

The user must accept before the app starts to retrieve or place information on the device

Mandatory

LEG_002 Provide well-defined and comprehensible purposes of the data processing (including if the data will be used for third party purposes)


Purposes of the data processing should be informed to the user inadvance to installation of the app, and not change these purposes without renewed consent; provide comprehensive information if the data will be used for third party purposes.


Mandatory

LEG_003 Allow users to revoke their consent and uninstall the app, and delete data where appropriate.


Allow users to revoke their consent and uninstall the app, and delete data where appropriate.


Mandatory

LEG_004 Provide a single point of contact for the users


Users need contact data to address their requests

Contact data availability Mandatory

LEG_005 Provide a readable, DORA App Security Users should be informed Privacy policy availability Mandatory


81 / 86

understandable and easily accessible privacy policy for the users.

requirements on the privacy policy of DORA

LEG_006 Inform the users about the existence of mechanisms to exercise their rights of access, rectification, erasure and their right to object to data processing.


Mandatory

LEG_007 The DORA Platform and all involved services follow the local data security and privacy regulations

DORA Platform Legal requirements The local data security and privacy laws are fulfilled in both clusters Berlin and Palma

Local data security concepts secure a proper data privacy management

Mandatory

LEG_008 Ensure the protection of the personal data

DORA Platform Security requirements Ensure the protection of the personal data, at all stages of the design and implementation of the system (privacy by design).

Mandatory

LEG_009 Define a retention period for data collected and a period of inactivity for expiration.

DORA Platform Security requirements Retention period for data collected with the app and period of inactivity after which the user account will be treated as expired.

Availability of information to the user and mechanism to manage retention and inactivity period

Mandatory

LEG_010 Directive 95/46/EC and the Member State data protection laws compliance

DORA Platform Legal requirements Personal information shall be implemented in the DORA system so as to comply with Directive 95/46/EC and especially with the Member State laws where the data controller is, even if the data

Mandatory


82 / 86

processed belong to an individual residing in another Member St

LEG_011 Use of standard “VDV-Kernapplikation” for public transprot e-ticketing

DORA Platform Legal requirements “VDV-Kernapplikation”-standard is the only acknowledged standard for public transport e-ticketing in Germany

optional

Table 18: Legal Requirements


7 IMPACTS

This chapter summarizes the major outcomes of the requirements definition process and

points out what impacts these requirements have on two upcoming tasks: The definition of

the final architecture in T3.1 and the specification of services and applications in T3.2 and

T3.3.

7.1 Impacts on the DORA Architecture

In D3.1, which was finalized in M6, the initial DORA architecture had been designed and

reported before the final list of use cases and requirements was elaborated. This means that

not all specific technical requirements were regarded for the architecture draft. The final

architecture is due to be specified in M 10. In the respective deliverable 3.2 the defined

requirements will be taken into account.

Requirements that influence the final architecture are first and foremost the ones that deal

with the central DORA platform. Especially the requirements PLA_001, PLA_002 and

PLA_005 are important for the final architecture as they concern the use of open APIs for the

different DORA frontends such as the end user applications and the Operation Centre

Application as well as for the communication between different backends. These

requirements led to the specification of the DORA open application API and the DORA open

service API. The final architecture also has to take into account requirements PLA_003 and

PLA_004. These operational requirements ask for high reliability and scalability of the system

by using cloud computing techniques which has to be considered when specifying the

system architecture.

Furthermore PLA_007 and PLA_008 require a common data base and data inventory for the

DORA routing services as well as a central DORA map tile service which provides all

connected applications with PNG files. Based on this the architecture specifies how this

common data base will be accessed. PLA_010 finally requires that the platform performance

is logged for the technical evaluation. To ensure central logging functionalities the APIs and

the overall platform have to support this requirement.

The technical requirements also describe which components communicate with each other.

More precisely it is specified which data and information has to be exchanged in which

format. The DORA APIs for example are aligned with the communication flow of the routing

calculation by the DORA end-user applications, the central Door to Door Journey Planner and

the connected subordinate routing services such as the Flight Information Service (FIS),

Indoor Router (IR) and Intermodal Landside Router (ILR) (see e.g. DJP_003, DJP_004 and

DJP_006).


84 / 86

Also legal/security requirements impact the architecture design. Requirements LEG_008 and

LEG_010 ask for protection of personal data in the whole implementation of the DORA

system which has to be guaranteed and supported by the architecture framework.

7.2 Impacts on Service and Application Specification

The impact of the technical requirements on the specification of the services and

applications is very essential and versatile. Basically all requirements, as part of the

development framework, have an influence on the specification process as that is reason

why they were collected.

After the final list of technical and legal requirements is aligned and available with the

present report, all developing partners are able to oversee the basic conditions and

dependencies for the component development. All technical and legal requirements have to

be double checked by the responsible developing partners so that they are able to assess

how they affect the upcoming work.

DEP_236 serves as an example how the requirement definition process impacts the

upcoming service specification. The mentioned detected dependency points out that all

single routing services contribution to the overall door to door route calculation need to use

WGS 84 coordinate system. This particularly concerns the Door to Door Journey Planner, the

Intermodal Landside Router, The Indoor Positioning as well as the Indoor Router

(Requirements DJP_001, ILR_006, IP_008, IR_001). After this dependency has be detected

during the VOLERE validation phase, all initial authors of the mentioned requirements

agreed on the use of WGS 84 and modified the requirements accordingly. Many

requirements have been coordinated in a similar way and will now set the framework for the

specification and development.

Not only the technical requirements affect the specification of services and applications, also

some legal requirements have an impact. All data protection requirements that concern the

platform and architecture specification (LEG_001 – LEG_011) are also valid for all single

components. Also the legal requirements that call for the use of specific standards such as

the mentioned e-ticketing standard in Germany need to be considered for service and

application specification.


85 / 86

8 CONCLUSION

The requirement definition process has been a very important step towards the upcoming

specification of services and applications. It links the activities carried out in work package 2

with the following central specification and development steps. Especially the use cases are

translated in technical framework conditions that outline how the different components

need to work together in order to achieve the project´s objectives.

The use of the VOLERE procedure model and tool proved to be very helpful to gather all

requirements needed and to coordinate the different expectations and perspectives of all

relevant developing project partners towards the communication flow within the overall

system. With the help of the iterative requirements definition approach of VOLERE, many

uncertainties, problems and objections could be solved during the process so that a common

list of requirements is finally available. This coordination process is transparently reproduced

in chapter 5.2.

A total of 140 technical requirements have been collected divided into 13 different

component categories of the DORA system. Especially the data exchange between the DORA

end-user applications and the Door to Door Journey Planner, the Door to Door Journey

Planner and the connected single routing services (ILR, IR, FIS) and between the Indoor

Positioning System and the Indoor Router were subject of the VOLERE coordination process.

For the upcoming specification process all 125 mandatory requirements have to be taken

into account by the responsible developing partners.

The legal requirements analysis pointed out some important data protection guidelines for

DORA. Different European and national legislations on personal data protection were

analysed and translated into single requirements mainly concerning the user data handling

in the DORA end-user applications. The main requirements here ask for user consent on data

handling procedures, guarantee users to delete personal data if desired and regulate the

transparent treatment of personal data in general following the applicable legislations.

Based on the present definition of the technical requirements, the specification of the final

architecture, the services and applications can finally be addressed in detail. The final

architecture will be available by the end of March 2016 (D3.2), the specification of s ervices

and applications are to be finalized by the end of July 2016 (D3.3 & D3.4).


86 / 86

References

[1] European Parliament and the Council. Directive 95/46/EC on the protection of individuals with

regard to the processing of personal data and on the free movement of such data . 24 October 1995.

[2] [Online] [Cited: 2 February 2016.] http://www.purpleforge.com/index.php/knowledge-base/249-

end-user-license-agreement-eula-for-a-mobile-app.

[3] Article 29 Data Protection Working Party. Opinion 02/2013 on apps on smart devices. Brussels :

s.n., 2013.

[4] European Comission. Regulation on the protection of individuals with regard to the processing of

personal data and on the free movement of such data (General Data Protection Regulation). 2012.

[5] Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos. s.l. : «BOE» núm. 298, 1999.

[6] Federal Data Protection Act . s.l. : Federal Law Gazette I p. 66, 2003.

door to door information for air passengers · the information contained in this document is...

Documents