door to door information for air passengers€¦ · door to door information for air passengers d...

Door to Door Information for Air Passengers

D 2.3 Use cases manual

Editor: Patricia Bellver, ETRA

Deliverable nature: Report (R)

Dissemination level: Public (PU)

Date: planned | actual 31 December 2015 23 December 2015

Version | no. of pages Version 1.0 69

Keywords: Use cases, scenarios, use-case diagram

DORA Deliverable D2.3

2 / 69 2 / 69

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 ETRA

Task(s) no.(s)/leader(s) 2.3 ETRA

Copyright notice

2015 ETRA INVESTIGACION Y DESARROLLO, S.A. and members of the DORA consortium


3 / 69 3 / 69

Executive Summary

This deliverable D2.3 is the outcome of Task 2.3 Definition of Use Cases, whose aim is to

define DORA scenarios and use cases that will lead to the DORA specifications. Therefore,

the purpose of this document is to define the most relevant use cases in order to specify all

the possibilities of the DORA system, to obtain a usable set of features for the development

and to extract best scenarios to be deployed and demonstrated later on.

The outcomes of this deliverable will be a key input in deliverable D2.4 Technical and legal

requirements, which consists of a report on the technical and legal issues to take into

account for the development and integration of the components of DORA inf ormation

system.

The document starts with the initial scenario descriptions, use case definition and purposes.

The use case methodology here is adapted to the particular needs of the DORA purposes.

Next, a table with an overview of all the DORA use cases is presented, including the

classification based in the DORA components. The relation of these use cases is shown at the

use-case diagram.

Finally, the description of use cases is presented. Each use case is extensively developed

using a specific template.

The document will end with a summary reflecting the main conclusions. The list of use cases

intends to cover all the possible situations and functionalities that the DORA system will

provide to the main users involved (passengers, operation centres) but once the system

architecture and the services specifications will be defined in the forthcoming tasks, a

realistic yet feasible selection of the use cases to be demonstrated might be taken into

consideration.


4 / 69 4 / 69

List of Authors

Organisation Authors Main organisations’ contributions

ETRAPatricia Bellver

German Martinez

Introduction, Structure, Scenario

definition and description, Use case

definitions and methodology, Trip

Planning use cases, Trip Monitoring

use cases, Use case diagram,

Conclusions

VMZJan-Niklas Willing

Tom Schilling

Scenarios definition and description,

use case methodology, Trip Planning

use cases, Trip Monitoring use cases,

Landside Transport use cases

UPVLCCarlos E. Palau

Benjamin Molina

Indoor Routing and Positioning use

cases

CSE Konstantinos KoutsopoulosIndoor Routing and Positioning use

cases

VBBJörg Becker

Alexander PilzLandside Transport use cases

EMT Carles Petit Landside Transport use cases

EUREVA Philippe Martineau Waiting time information use cases

FBB Samir Djulancic Flight Information use cases


5 / 69 5 / 69

Table of contents

1 INTRODUCTION ................................................................................................. 9

1.1 Project overview................................................................................................ 9

1.2 Purpose of the deliverable ............................................................................... 10

1.3 Structure of the deliverable ............................................................................. 11

2 SCENARIOS AND USE CASES: DEFINITION, GOALS AND METHODOLOGY ........... 12

2.1 Selected method of the scenario creation ........................................................ 12

2.2 Scenario description ........................................................................................ 13

2.2.1 Business traveller (Peter) ..................................................................................... 13

2.2.2 Senior travellers (Mr. and Mrs. Müller) ................................................................ 15

2.2.3 Mobility impaired traveller (Heidi) ....................................................................... 17

2.2.4 Family travellers (Rodriguez family) ..................................................................... 18

2.2.5 Young travellers (Ana & Pablo)............................................................................. 19

2.2.6 Operation Centres (Bekki) .................................................................................... 20

2.3 Use case .......................................................................................................... 22

2.3.1 Introduction ......................................................................................................... 22

2.3.2 Use case definition and goals ............................................................................... 22

2.3.3 Elements and components of a use case .............................................................. 23

2.3.4 Use case development methodology ................................................................... 26

3 CLASSIFICATION OF USE CASES......................................................................... 27

4 USE-CASES DIAGRAM....................................................................................... 29

4.1 Use-cases diagram definition ........................................................................... 29

4.2 DORA use-cases diagram.................................................................................. 29

5 DESCRIPTION OF USE CASES............................................................................. 31

5.1 Trip planning use cases .................................................................................... 31

5.2 Trip monitoring use cases ................................................................................ 39

5.3 Landside transport use cases............................................................................ 46

5.4 Indoor routing and positioning use cases.......................................................... 54


6 / 69 6 / 69

5.5 Waiting time information use cases ................................................................. 60

5.6 Flight information use cases............................................................................. 62

5.7 Other use cases................................................................................................ 66

6 CONCLUSIONS ................................................................................................. 68


7 / 69 7 / 69

List of Figures

Figure 1: DORA use-cases diagram........................................................................................30

List of Tables

Table 1: Template for description of DORA use cases ...........................................................25

Table 2: Overview of DORA use cases ...................................................................................27


8 / 69 8 / 69

Abbreviations

Abbreviation Explanation

BER Berlin Brandenburg Airport Willy Brandt

D#.# Deliverable number #.# (D7.1 deliverable 1 of work package 7)

DoA Description of Action of the project

DORA Door to Door Information for Airports and Airlines

EC European Commission

EU European Union

H2020 Horizon 2020 Programme for Research and Innovation

ITS Intelligent Transport Systems

PMI Palma de Mallorca airport

TXL Berlin-Tegel Airport

UML Unified Modeling Language

WP Work Package


9 / 69 9 / 69

1 INTRODUCTION

The aim of this section is to introduce the DORA project and the purpose of the deliverable

D2.3 Use cases manual. The contents of the deliverable are summarized in this section as

well as to provide navigation guidelines.

1.1 Project overview

DORA (Door to Door Information for Airports and Airlines) is a three-year research project

supported by the European Commission (EC) through the Horizon 2020 Programme, in the

theme of Smart, Green and Integrated Transport Challenge and the area of Seamless Air

Mobility in the Mobility for Growth call (Grant agreement no 635885). DORA project is

aiming at design and establishment of an integrated information system that helps

passengers to optimise travel time from an origin of the travel to the airplane at the

departing airport as well as from the arrival airport to the final destination. With it, the

DORA integrated information system, which will be created within the project together with

necessary software platforms and end user applications, is aiming at reduction of overall

time needed for a typical European air travel including necessary time needed for transport

to and from the airports.

To ensure this, the DORA system will provide mobile, seamless, and time optimised route

recommendations for the travels to the airport and time optimise d routing within the

airports, leading the passengers through terminals to the right security and departure gates.

The DORA will integrate all necessary real time information on disruptions in the land

transport environments and on incidents in the airport terminals to provide the fastest route

alternatives, ensuring the accessibility of airport and airplane at any time in accordance with

individual passengers’ requirements. The DORA system will be designed in a generic way, to

ensure that it can be widely adopted independently on passengers and airport locations. In

the project, the DORA system will be implemented and tested in realistic environments

involving cities of Berlin and Palma de Mallorca as well as corresponding airports in both

cities with involvement of at least 500 real end users – passengers – in the trials. To support

the passengers’ route optimisation, the DORA project will investigate and design

technologies for recognition of waiting queues and indoor location services in airports,


10 / 69 10 / 69

which will be integrated into the DORA system and tested within the project trials at PMI

and TXL/BER1.

The DORA solution is a combination of offered product (user application) and related

services. For the end customer, DORA offers a simple and free to use digit al application for

phones or tablets. The application may include different features, as a result of a structured

process consisting in the definition of system requirements and specifications, the

development of new software and, finally, the integration with existing solutions.

1.2 Purpose of the deliverable

Implementation of DORA project activities is organised in seven work packages to be

completed during 36 months. Whereas WP1 and WP7 are devoted to the project

management as well as dissemination and exploitation activities respectively, the technical

work will be done within WP2 – WP6:

WP2- DORA Requirements and Use Cases

WP3- DORA Concept Specification

WP4- Software Development and Integration

WP5- Pilot Execution

WP6- Usability and Evaluation

The objectives of work package 2 are to define the set of technical and legal requirements

for the development of the DORA system and for each of its core components: intermodal

router, waiting time detection, indoor location and routing and mobile smart phone

application. For this purpose, the specific objectives are to analyse the market of integrated

Information services for passengers, define user groups according to identified mobility

profiles and describe use cases involving all the relevant actors, goals and p rocesses. Four

deliverables are planned in the work package 2, namely: D2.1 Market analysis report, D2.2

Users groups and mobility profiles, D2.3 Use cases manual, and D2.4 Technical and legal

requirements.

1On the long term it is envisaged to realize the DORA systems for the new airport in Berlin. In case the opening

of BER is not compatible with the project’s time schedule the DORA s ystems will be implemented and tested in

Berlin-Tegel airport (TXL) and transferred to BER afterwards.


11 / 69 11 / 69

This deliverable D2.3 is the outcome of Task 2.3 Definition of Use Cases, whose aim is to

define DORA scenarios and use cases that will lead to the functional specifications.

Therefore, the purpose of this document is to define the most relevant use cases in order to

specify all the possibilities of the DORA system, to obtain a usable set of features for the

development and to extract best scenarios to be deployed and demonstrated.

The outcomes of this deliverable will be a key input in deliverable D2.4 Technical and legal

requirements, which consists on a report on the technical and legal issues to take into

account for the development and integration of the components of DORA information

system.

1.3 Structure of the deliverable

The document starts with the initial scenario descriptions, use case definition and purposes.

The use case methodology is orienting on the particular needs of the DORA purposes.

Next, a table with all the use cases is presented, including the classification and relation with

the DORA components. The relation of these use cases is shown at the use-case diagram.

Finally, the description of use cases is presented. Each use case is extensively developed

using a specific template.

The document will end with a summary reflecting the main conclusions.


12 / 69 12 / 69

2 SCENARIOS AND USE CASES: DEFINITION, GOALS

AND METHODOLOGY

A definition and description of a set of representative DORA use case scenarios will be

developed in this section. These scenarios will inspire the subsequent use case definition for

the DORA system. An introduction and a use case definition, goals, components will follow in

this section. And finally, the use case development methodology will be explained.

2.1 Selected method of the scenario creation

A usage scenario, or scenario for short, describes a real-world example of how one or more

people or organizations interact with a system. They describe the steps, events, and/or

actions which occur during the interaction. Usage scenarios can be very detailed, indicating

exactly how someone works with the user interface, or reasonably high -level describing the

critical business actions but not the indicating how they're performed (1).

There are several differences between use cases and scenarios. First, a use case typically

refers to generic actors, such as “Customer”, whereas scenarios typically refer to examples

of the actors such as Peter, Ana, etc. It's usually better to personalize the scenarios to

increase their understand ability. Second, usage scenarios describe a single path of logic

whereas use cases typically describe several paths (the basic course plus any appropriate

alternate paths). Third, use cases are often retained as official documentation whereas

scenarios are often discarded after they're no longer needed (1).

Scenarios are fully user stories. They do not reflect the system's ac tivities (except as

experience by the user). Scenarios should be technology agnostic (as much as possible).

Below there are the DORA Use Case Scenarios description, six different scenarios in total

that are based in the main user groups defined for the DORA system (see Deliverable 2.1

Market Analysis Report). Along the story of each scenario there are references

(corresponding use case-ID in brackets) to the use cases that will be defined and described

afterwards in the section 3 of this deliverable. Moreover it has been agreed a legend to

remark the references in different colours, depending on the use case cluster or

classification of the use case (see section 2.3.3.):

Trip Planning (TP)

Trip Monitoring (TM)


13 / 69 13 / 69

Landside Transport (LT)

Indoor Routing and Positioning (IRP)

Waiting time information (WT)

Flight Information (FI)

Other (OT)

2.2 Scenario description

Based on the inputs of the results of the previous deliverables and the methodological

explanations in chapter Error! Reference source not found. , six scenarios have been

developed as a pre-step to the final definition of the uses cases for the DORA service.

2.2.1 Business traveller (Peter)

User group profile: in no-leading positions, are represented by 20-65 years old persons in

their active working phases. They put high priority on time efficiency and cost-efficiency.

Peter is a business traveller. He works as a self-employed web designer and lives in

Brandenburg (Berlin’s hinterland). If he is in Berlin occupationally, he prefers to use public

transport, car sharing or bike sharing. Right now he plans a business trip to Palma de

Mallorca to meet with an important potential customer and afterwards other customers in

Palma during the following days. As a freelancer he has a lot of work to do and time is

money. It is difficult to estimate the traffic situation to reach the Berlin Brandenburg Airport

(BER). The BER is conveniently located next to the highway. But due to accidents and the

high volume of traffic there are often severe traffic jams which can increase the travel time

dramatically.

Some time ago Peter has missed an important flight. First he got into a traffic jam and then

into a long line up at the security check. Since then he finds it quite annoying that he needs

to allow extra time that in the end he usually spends at the airport terminal. Since a while

Peter uses the DORA-system to plan his business trips which enables him to reduce his travel

time significantly.

Now Peter is at his office and he is planning his trip to Palma de Mallorca with the DORA-

system. His appointment is in two days at 12 pm. It is his first time that he visits this

potential customer who has his office located at the city centre (Plaça d’Espanya).


14 / 69 14 / 69

Peter is a registered user of the DORA-system. Thus his home address, his office address and

some of his preferences (e.g. business traveller, member of the Air Berlin Frequent Flyer

program) are already stored within the system [OT-02]. Peter chooses his home address as

start and types the customer’s address into the DORA-system for the destination [TP-02].

With a mouse click he starts the itinerary search from „home“ to the customer’s address.

The DORA-system suggests several itineraries with different means of transport

combinations from his home to the airport and from the airport in Palma to the customer’s

site. The routes and processes at both airports are also clearly represented. Peter who is not

familiar with the airport in Palma de Mallorca can now relax because he has all the

information he needs.

Peter decides to drive with his car to a low priced P&R parking area and to take the S -Bahn

from there to the BER.

This itinerary creates less emission than taking the car for the whole route and it is much

faster especially during rush hour traffic. Furthermore DORA offers a cost comparison that

shows that using the P&R parking area is clearly more cost-efficient than paying the park

fees at BER [TP-03]. At the airport in Palma de Mallorca Peter opts for a rent a car option as

he is going to visit several customers in different sites [TP-05].

Peter does not need any further app for his travel planning, neither from one of the public

transport companies (BVG, VBB) nor from the traffic information centre (VIZ). The DORA-

System is based on these real time information systems and offers therefore the same high

quality and reliability as they do.

In the morning of his travel day Peter gets up in time and checks via the DORA -app his

itinerary for today: all on schedule. Otherwise the DORA-system would have informed him

already by push message about the deviation [TP-06].

During the ride to the airport Peter thinks of his presentation to the potential customer. He

knows that he does not have to worry about his arrival. During one of his last trips the S-

Bahn was cancelled and the DORA-system informed him about this incident [TM-02] and the

alternative to use car sharing [TP-03]. He could make the reservation directly via the DORA-

app [OT-03] and he reached his flight without any difficulty. Another time a passenger of an

earlier flight left his luggage unattended in the boarding area. The area had to be evacuated

for further security checks, the departure gates for the following flight had to be changed

and the boarding procedures for the later flight took longer than usual. Via push message

DORA Peter was informed on the gate change and the delay [TM-04]. Well informed Peter

decided to spend the time in the business lounge of Air Berlin. The indoor-routing


15 / 69 15 / 69

functionality of the App showed him the way to the lounge [IRP-01], where he could finish

the presentation. Since these events he fully trusts in the DORA system.

Today everything works fine at the airport: only 5 minutes for the security check and the

plane takes off on time.

During the flight a severe accident takes place on the Ma-13A, which is the connecting road

from Palma Airport to the city. The control centres for the public transport and individual

transport are prepared for this. They activate an incident strategy. This strategy is

transmitted to the DORA system [TM-07].

While Peter is waiting for his luggage at the airport of Palma de Mallorca he receives a push

message on his smart phone. [TM-05] The DORA system informs him about the blocking of

the Ma-13A [TM-01]. Instead of taking the Ma-13A the app suggests the alternative route

Ma-13 [TP-03], so Peter confirms this alternative itinerary [TP-05].

Peter takes his suitcase and follows the navigation instruction of the DORA-app to the rent a

car office in the terminal airport [IRP-01]. Finally, he takes the car and following car routing

instructions of the DORA-app [LT-01] he arrives at the customer’s site in Plaça d’Espanya on

time.

2.2.2 Senior travellers (Mr. and Mrs. Müller)

User group profile: are older than 60 years, are travelling alone or in small groups, are

belonging to middle or upper income classes and are prioritizing culture, social responsibility.

Additionally they are monetary and environmental conscious.

Since their retirement three years ago, Mr. and Mrs. Müller enjoy their time visiting many

places all over Europe that they have always been interested in. Once a year they meet with

same aged friends to make a culinary tour together to discover local foods and traditional

cuisine. As this year´s destination, it was decided to visit Mallorca for a week.

Even though they travel quite a lot recently, it is still challenging for them to get oriented in

all the different airports and public transport systems with inconsistent passenger guidance

and information solutions. For their trip to Mallorca the daughter of Mr. and Mrs. Müller

therefore recommended to them to download the DORA app [OT-01] in order to guarantee

for a trouble-free journey from their home in the outskirts of Berlin to their holiday

apartment in Palma de Mallorca (Apartaments Les Veles). As Mr. and Mrs. Müller try to keep

pace with technical progress in general, they are both quite familiar with how to use

smartphones and apps.


16 / 69 16 / 69

In the evening before their trip to Mallorca, they select their flight [TP-01], request a route

[TP-02] and check the different possibilities to reach their final destination suggested by the

DORA routing system [TP-03]. Since Mrs. Müller is not able to carry heavy luggage anymore,

they select the option to avoid stairs in the routing [TP-04]. In addition, as they are not in a

hurry and prefer stress-free travelling, they opt for an extended buffer time at the terminal

in comparison to the default value [TP-07]. Different routes are suggested for the first part

of their overall trip, the way from their home to Berlin Brandenburg Airport (BER), with

information on duration, costs and CO2-emissions of each route. Mr. and Mrs. Müller are

concerned with environmental issues and, at least as a small compensation for their air

travel, decide to choose the most eco-friendly option with public transport.

The next morning they check if the DORA system has sent any notification about deviations

for the selected route but both the public transport connection and the flight are expected

to be on-time. Mr. and Mrs. Müller live right between two metro stops. Since Mrs. Müller

selected the preference to avoid stairs, the DORA system routes them to the station that has

an elevator. Their journey with metro and train runs smoothly so that they arrive on time at

the train station of BER Airport. A few minutes before their arrival at the airport the DORA

system sends a push message to the app [TM-05] informing Mr. and Mrs. Müller that the

check-in counter for their flight has changed [TM-04]. After they get off the train the

smartphone gets access to the airport´s indoor localization system and navigates them to

their new check-in counter taking into account the accessibility of the terminal

infrastructure. In their DORA app they check the current waiting time at the security check

which is only 5 minutes approximately[WT-01].After check-in and security check they have

enough time to drink a coffee and relax. Mr. Müller notices that he has forgotten his

sunscreen at home and wants to use the remaining time to purchase a replacement at th e

terminal. In the indoor map of the DORA app he looks for a drugstore and lets the DORA app

route him to the shop. After such a smooth journey so far Mr. and Mrs. Müller board their

plane relaxed and with full anticipation for the coming week.

After landing at Palma de Mallorca Airport (PMI) Mr. and Mrs. Müller try to locate the

official meeting point of Terminal Module C where they are appointed with a few friends

from Munich arriving approximately at the same time. The meeting point in the arrival hall is

listed in the DORA app among other points of interest and can be selected as target point for

the indoor routing. After collecting the suitcases from the luggage belt, the DORA app shows

Mr. and Mrs. Müller the easiest and fastest way to the meeting point.

20 minutes later they are successfully reunited with their friends and exchange the latest

news. Their friends need to take the same bus so Mrs. Müller guides the entire group to the


17 / 69 17 / 69

appropriate bus station outside the terminal building with the help of the DORA Indoor

Navigation Service. For their selected route they can see that the bus (line 21) has a delay of

6 minutes so they don´t need to hurry on their way outside the airport. After getting off the

airport bus at the station closest to their holiday apartment (bus stop number 430) they

easily find their destination by means of the detailed walking instructions provided by the

DORA app.

2.2.3 Mobility impaired traveller (Heidi)

Heidi is 47, lives in Berlin Lichtenberg and works as a financial accountant mostly from home

without leaving her flat. She suffers from multiple sclerosis and is, due to that, limited in her

daily mobility especially when walking longer distances. Because of that, she loves it to leave

Berlin during holidays. She likes to travel to destinations in the Mediterranean Sea region

due to the warm climate and the many hours of sunshine. For the upcoming holiday she has

planned a trip to Mallorca. She is going to stay for ten days directly at the coast in a hotel

located in Cala Major (Palma de Mallorca).

Because of her mobility impairment, Heidi has used the internet and the smartphone a lot of

times to inform herself about important details having an impact on her trips and journeys.

She made good experiences with information services. Even though she has been travelling a

lot recently, it is still challenging for her to get enough information in a convenient way for

trips to other places and regions from her starting place to the final destination. That is the

reason why she is still open and interested in new approaches and new services helping her.

She booked her complete holiday trip through a holiday booking portal. Per mail she got all

the confirmations and the details about the hotel and the flight from Berlin Brandenburg

Airport (BER) to Palma de Mallorca Airport (PMI). A couple of days before she is going to

leave Berlin she has heard about the DORA end user services and especially the smartphone

application. She is very interested in the approach to make air travel as convenien t as

possible by providing the users with suitable mobility information. After downloading the

app [OT-01] she opens the menu and adjusts the settings according to her mobility

restrictions. For her it is especially important to reduce the maximum walking distance for

the route calculations [TP-08]. In addition she turned on the functionality that stairs should

be avoided [TP-04] and instead escalators and elevators should be used only.

One day before departure Heidi opens the app. She enters the flight number [TP-01] and the

app shows that the plane will leave the airport at 10:15 am. To reach her flight on time and

to get a convenient connection from her home to the final destination she requests the


18 / 69 18 / 69

DORA App for route recommendations [TP-02]. The app informs her to leave her house at

8:00 am. The app recommends using the public transportation. She is supposed to change

from the metro to the S-Bahn at a barrier-free station [TP-03]. The app allows her to pay the

ticket for this part of the trip directly in the app [LT-09]. The trip plan shows her how to go

through the airport terminal to the baggage check, afterwards to the security check and

later to the gate of departure without using stairs. The route provided by the DORA app for

her way from airport to hotel suggests to take a taxi as the best personal option for her . For

the way from the arrival gate to the taxi stand in front of the airport the app already shows

her the best route. The approximately 18 km long journey by taxi is the most convenient way

for her to reach the hotel in Cala Major without waiting a long time at the bus stop for the

suitable bus. Heidi is impressed by the amount of mode options which are taken into

account by the DORA app. She saves the recommended route to open it easily at t he next

day.

At the day of departure the DORA app informs her with a push notification about a

disruption of the metro line she should have taken [TM-02 & TM-05] as the first transport

mode on the way to the airport. She reads the message and requests for an updated trip

alternative to reach the airport on time. Because of the saved mobility restrictions in the

settings menu she will be routed to an alternative barrier free station [TP-04]. Heidi has to

leave the house 15 min earlier than planned before but the updated trip plan works

probably. She reaches the airport and all further interim stopovers in the terminal on time

without any other disruption or delay. In any case, the monitoring function of the DORA app

would have promptly informed her about further disturbances on the way to the terminal as

well as in the terminal. After landing she will be provided with the details to reach the

correct luggage belt and the taxi stand in front of the terminal. After everything has worked

out according to plan she finally arrives at her final destination in Cala Major planning to use

the DORA app for her way back home as well.

2.2.4 Family travellers (Rodriguez family)

User group profile: are classified between 34-44 years of age. They are traveling with one or

more children, are mostly belonging to upper middle income classes and are looking for cost -

efficient and predictable travels.

The Rodriguez family lives in Palma de Mallorca in Can Pastilla beach. The Rodriguez have

three children of 3, 5 and 8 years old. For their summer holidays they planned a fortnight

trip to Berlin and surrounding area several months in advance. As their children were little

yet (below 12 years old), they wanted to plan their trip stages in detail and have everything


19 / 69 19 / 69

under control. Other parents from the school told them about the DORA app and its

advantages. So they decided to download it [OT-01], register themselves as users [OT-02]

and try it for the trip planning, on-trip information (disruptions, delays, incidents, etc.) and

guidance inside the airport premises (mainly in the Berlin Brandenburg Airport, because they

haven’t been there before). Moreover, as they plan to go around the city and its

surroundings, they booked a family car on a rent-a-car web site that would be picked up at

Berlin airport premises.

A few days before their departure, they selected their flight [TP-01], requested a route [TP-

02] and checked the different possibilities to their final destination suggested by the DORA

routing system [TP-03]. After analysing The DORA app recommendations to reach the PMI

airport, they decided to take the public transportation (bus line 21), because they have a

large family discount in the city public transport, so they select this route option on the

DORA app [TP-05].

At the day of departure, their journey with bus runs smoothly so that they arrive on time at

the PMI airport. Once they have reached the PMI airport, they want to avoid long waiting

times at the security check with their children [WT-01], so they use the DORA app to find out

which is the fastest indoor route to reach their flight gate as soon as possible [IRP -01]. In

their way to the gate, a child asks for the toilet so they slightly deviate from the DORA

suggested indoor route, but the DORA system uses their real location [IRP-02] to re-calculate

the new route to the gate and shows it [TP-03] to Rodriguez family.

After landing at Berlin airport on time and picking up their luggage, the family follows the

DORA app indoor navigation guidance to reach the rent-a-car office in the airport terminal

[IRP-01]. As soon as they enter the rented car, they follow the DORA app routing instructions

to arrive smoothly to their hotel in Berlin [TP-03].

After all, they are so happy with the DORA app performance that they will recommended it

to other families and friends.

2.2.5 Young travellers (Ana & Pablo)

User group profile: at the age between 18-25. They are mostly travelling alone or as a couple,

are at the beginning of their working life and thus very cost-aware.

Ana and Pablo are a Spanish young couple that lives in Palma de Mallorca and they were

planning their Christmas holidays in Berlin with a small budget a few weeks in advance. After

booking a low cost flight to Berlin-Schönefeld Airport (SXF) - Berlin Brandenburg Airport

(BER) in the future- and a hostel near the city centre (Warschauer Platz), they decided to


20 / 69 20 / 69

search in travel forums how to transport themselves from the airport to the city at

affordable prices. In one of these forums, some users recommended the DORA app for door

to door trip information, so they decided to download it [OT-01] and register themselves as

users [OT-02] in their tablet device and use it for the first time in order to plan their trip to

Berlin.

The day before their departure, they select their flight [TP-01], request a route [TP-02] and

check the different possibilities to reach their final destination suggested by the DORA

routing system [TP-03]. The DORA app recommends using the public transportation (bus line

1) from their home near Plaça Espanya in Palma de Mallorca to the airport, so they decided

to take it. At the day of departure the DORA app informs with a push notification about a

delay of 10 minutes in the bus line 1 due to a road accident [TP-06]. Nevertheless they don’t

change their route plan as they have planned to arrive to the airport with enough buffer

time.

Once they have reached the PMI airport, Ana is interested in buying some sandwiches and

snacks for the flight in the airport shops before boarding the aircraft, so she uses the DORA

app to search the nearest shop to their assigned flight gate. DORA app provides them the

indoor guidance to the selected shop [IRP-01], but during their way to the shop, the flight

gate changes [TM-04] so affected passengers are proactively informed about the cha nge of

their gates through the DORA end user services: a push message is sent to Ana and Pablo

tablet informing on these disruption [TM-05] and re-calculating the routing to the new gate

and nearest shop [IRP-01].

After landing at Berlin airport on time, they follow DORA app indoor navigation instructions

to reach the luggage belt and to the exit of the airport terminal [IRP-01]. In order to get their

final destination in Berlin (the hostel near the city centre) they had seen that DORA app

provides real time information about available carpooling journeys offered by Flinc, so they

selected this option and get a confirmed ride to the city centre saving money at the same

time.

At the end of the day, they were so pleased with the DORA app performance that they

recommended it in travel forums and decided to use it in all their future trips abroad and, of

course in their way back home at the end of their Christmas holidays.

2.2.6 Operation Centres (Bekki)

Bekki, 32 years old, works as a traffic news editor at the Traffic Information Centre Berlin

(TIC). The TIC is provided with all relevant real time information about the traffic situation


21 / 69 21 / 69

for motorized individual vehicles, the public transportation as well as the real time flight

information for the Berlin Brandenburg Airport (BER). At the TIC Bekki edits information and

short advices for different communication channels: the webpage, the dynamic traffic signs

or for reporting to local radio stations and newspapers in order to inform the public about

planned activities like construction sites or events and current real time situations like

congestions, delays, accidents or other kinds of disruptions. In addition to the upkeep of the

mentioned communication channels Bekki has an administrator account to DORA´s incident

and information management panel.

In today's morning shift at 7:35 am Bekki receives the information that an accident has

happened on Autobahn A113 near the exit “Adlershof” which results in a complete road

closure. Due to the importance of this link the impact of the accident is immense for

commuters who want to enter the city but also for the access to the airport. Autobahn A 113

is the most important access road for air travellers using the private car or the Taxi from the

inner city of Berlin to the airport BER. The relevant information is pushed by Bekki into the

DORA´s incident and information management Panel [TM-08]. The Panel provides

cooperative management mechanisms and tools to support DORA´s Incident and

Information Strategy Service with routing strategies for urban street environments and

airport terminals. The information and the related dynamic strategies to react to the closure

as best as possible are pushed through the Panel to all other traffic control and operation

centres as well as to the public administration in Berlin. Through the services of the DORA

platform, the passenger will be informed consistently and promptly as well. The DORA App,

the Third Party App and related Web GUIs will be provided with this information. [TM -05]

The routing algorithms are able to take the road closure into account and calculate route

options for individual motorized traffic without using the accident area. In addition the users

will be informed about alternative connections with public transportation to reach the

airport on time. The intermodal landside routing algorithm will calculate the best

alternatives based on the user preferences.

After the important news about the road closure Bekki will be informed during the later

morning about a planned construction site in the terminal of the airport BER. The airport

operator FBB uses their local account of DORA´s incident and information management

Panel to insert the news about a repainting in a part of the departure area for the next two

weeks [TM-09]. Regarding this, the area cannot be used for passenger handling during the

mentioned period. Affected passengers who normally go through this area will be

proactively informed about the area to be avoided through the DORA end user services [TM-

03].


22 / 69 22 / 69

After an exciting shift, Bekki finishes her work for today with the good feeling of providing a

high quality information service to the partners, the public authorities and of course to the

citizens of Berlin.

2.3 Use case

2.3.1 Introduction

A use case is a written description of how the different users will perform tasks on the

system. It outlines, from a user’s point of view, a system’s behaviour as it responds to a

request. Each use case is represented as a sequence of simple steps, beginning with a user's

goal and ending when that goal is fulfilled (2).

Use cases add value because they help explaining how the system should behave. During the

development process, they also help to imagine possible what could go wrong. They provide

a list of goals and this list can be used to establish the cost and complexity of the system.

Project teams can then negotiate which functions become requirements and are built (3).

Thus, there is a high interaction between the use cases and the definition of requirements

(D2.3 and D2.4):

• Basic use cases are outlined considering the definition of the functional

requirements. The development of a complete list of use cases includes the

deployment of functionalities of the system.

• Use cases express the interaction between user and product. Therefore, the

definition of the user (capabilities, needs, constraints) is crucial for the

development of use cases.

• The information gathered through the use cases (D2.3) and the initial definition

of requirements, will be combined and cross checked in order to define the final

list of requirements and to detail specific requirements for the product (D2.4).

2.3.2 Use case definition and goals

A use case is a series of related interactions between a user (or more generally, an “actor”)

and a system that enables the user to achieve a goal. To phrase this definition in another

way, a use case describes the system’s behaviour as it responds to a series of related

requests from an actor (3).


23 / 69 23 / 69

Use cases are a good way to capture functional requirements of a system. The development

of the use cases for the DORA system has been done interactively with the initial compilation

of the requirements. Use cases and initial requirements are going to be used for the

compilation of the requirements specification document (D2.4).

A goal-oriented set of interactions between the users and the DORA systems will be defined.

It is worth to highlight that within the use cases it will be considered as users not only air

passengers but also other stakeholders such as Airport operators, Public transport bod ies

and Traffic information centres.

2.3.3 Elements and components of a use case

There are three basic elements that make up a use case (4):

Actors: are the type of users that interact with the system.

System: Use cases capture functional requirements that spec ify the intended

behaviour of the system.

Description/goals: Use cases are typically initiated by a user to fulfil goals describing

the activities and variants involved in attaining the goal.

These basic elements can be extended to offer a better description of the use case, to help

in the development of functions and requirements. For the DORA system, we have selected

the following components for each use case (5; 2; 4; 6; 7):

Use Case Cluster: Classification of the use case. The following groups of use case have been

defined for the DORA system, based on its main features:

Trip Planning (TP)




Waiting time information (WT)


Other (OT)


24 / 69 24 / 69

Use Case ID: An identification code (e.g.: OT-01) composed of the following elements:

CI: Use Case Cluster

Nr: Order number

Use Case Title: Descriptive name/title of the use case.

External Actors: Anyone or anything that performs a behaviour (who is using the system). A

use case defines the interactions between external actors and the system under

consideration to accomplish a goal. The actors can be either natural persons or system

actors.

Assumptions: An assumption is a state that must be achieved at some time before the

execution of the use case. An assumption is not a testable item, and will not be tested during

unit or system testing. Many times these assumptions are also requirements to the system.

Pre-conditions: A pre-condition is the state of the system and its environment that is

required before the use case can be started. It can be helpful to use preconditions to clarify

how the flow of events starts.

Services involved: It refers to either internal or external services that are directly interacting

with the system during the execution of the use case.

Trigger: This is the event that causes the use case to be initiated.

Flow of events: The description of the normal, expected path through the use case. This is

the path taken by most of the users most of the time; it is the most important part of the

use-case narrative. Flow of events that will occur when the use case is executed. Includes all

primary activities that the use case will perform. The sequence of interactions will be

focused on where these interactions differ from current transport operations.

Expected results: Shows the expected outcomes after the use case execution.


25 / 69 25 / 69

Table 1: Template for description of DORA use cases

Use Case-ID

Use Case Title

Use Case Cluster

External Actors(system actors or natural persons)

Assumptions

Pre-conditions

Services involved

Trigger

Flow of Events

Expected results


26 / 69 26 / 69

2.3.4 Use case development methodology

The following steps have been followed to build the DORA use cases:

1. Description of the DORA system and its components.

2. System breakdown into basic actions.

3. Transformation of the basic actions in a use case list.

4. Classify each use case according to the main features of the DORA system:

a. Trip Planning (TP)

b. Trip Monitoring (TM)

c. Landside Transport (LT)

d. Indoor Routing and Positioning (IRP)

e. Waiting time information (WT)

f. Flight Information (FI)

g. Other (OT)

5. Describe the elements/ components of each use case.

6. Revision and discussion by the project partners, including:

a. Add and remove use cases.

b. Re-allocate the use case in a different cluster.

c. Prioritize.

7. Final table of use cases.


27 / 69 27 / 69

3 CLASSIFICATION OF USE CASES

As explained in previous sections, the DORA use cases have been structured according to the

six main features of the DORA system: Trip Planning, Trip Monitoring, Landside Transport,

Indoor Routing and Positioning, Waiting time information and Flight Information. Moreover

an additional use case cluster (Other) has been defined to include those use cases that

doesn’t belong to any of the previously listed ones.

Table 2: Overview of DORA use cases

Trip Planning (TP)




Waiting Time information (WT)


Other (OT)

01 Selection of flight for door-to-door-route calculation

On-trip information of incidents on the actual car route

Detailed guidance through road network (for drivers)

Indoor Positioning

Estimation of waiting time at security check

Showing arrivals of a time period in a list

Download of mobile application from app stores

02 Request of a door-to-door-Route

On-trip information of incidents on the actual public transportation route

Public transport options and static information (fares, travel time, schedules, stop location…)

Accessing Security Checkpoint

Estimation of waiting time at check-in

Showing departures of a time period in a list

Save user profile in the DORA app

03 Calculation of a door-to-door route

On-trip information of changes on the actual indoor route

Real time public transport information of selected routes

Accessing the Boarding Gate

Auto Updates of departure, arrival lists and details pages

Booking of public transport, car- and bike-sharing

04 Selection of routing parameter “avoid stairs”

On-trip information of flight related changes on the actual indoor route

Detailed guidance through street network (walking and cycling)

Resting before boarding with alerts

Bookmarking specific flights

05 Selection of a door-to-door route

Transmission of incidents to DORA App

Bike and car sharing information (location of stations, availability, fares…)

Arriving and getting the baggage

Sharing flight details with third party and mobile OS


28 / 69 28 / 69

06 Pre-trip information of incidents on the selected route

Click on “Start the trip” button

Request of secondary/ alternative destinations or intermediate stops

Meeting point and exiting airport

Search –Finding a specific flight

07 Adjustment of routing parameter “buffer time at the airport”

Transmission of incidents to DORA backend system

Detailed guidance at transfer stations

Flight details and additional information

08 Adjustment of routing parameter “maximum walking distance”.

Inserting a disturbance at the Traffic Information Centre

Car parking information(static and dynamic)

09 Selection of transport modes for route calculation

Inserting a disturbance at the Airport Operation Centre

Buy public transport ticket in the DORA app

In total, 45 use cases have been defined for the DORA system.


29 / 69 29 / 69

4 USE-CASES DIAGRAM

4.1 Use-cases diagram definition

While a use case itself might drill into a lot of detail about every possibility, a use -cases

diagram can help to provide a higher-level view onto the system. The diagram provides the

simplified and graphical representation of what the whole system must actually do. This

diagram includes all the considered use cases, the flow of actions, the interactions between

use cases and the actors involved (passengers, transport operators, operation control

centres, etc.).A use-case diagram at its simplest is a representation of a user's interaction

with the system that shows the relationship between the user and the different use cases in

which the user is involved (8).

A use-case diagram is a graphic depiction of the interactions among the elements of a

system.

Use-case diagrams are employed in UML (Unified Modelling Language), a standard notation

for the modelling of real-world objects and systems (9).

4.2 DORA use-cases diagram

Figure below shows the diagram that includes all the considered use cases, the flow of

actions, the interactions between use cases and the actors/ services involved. The DORA

use-case diagram is depicted with UML notation.


30 / 69 30 / 69

Figure 1: DORA use-cases diagram


31 / 69 31 / 69

5 DESCRIPTION OF USE CASES

5.1 Trip planning use cases

Use Case-ID TP-01

Use Case Title Selection of flight for door-to-door-route calculation

Use Case Cluster Trip Planning


FARMS System

AENA Flight Info Service

Assumptions Once the flights are available in the Flight Information Service, the user has the option to select a flight via flight number search or from list of departures to request a route. The door -to-door journey planner calculates different route suggestions centered on the expected departure and arrival time of the selected flight. If a flight is selected, only the landside and terminal parts of the suggested routes may vary.

Pre-conditions User has access to an DORA end-user application for trip planning

FARMS System and AENA flight info service provide real time data for the DORA Flight Information Service

The flight needs to be available at the moment of the selection (AENA just the day before of the departure, FARMS 3 days in advance of the departure) Flights presented in list format for departure airport

Search function for a flight via flight number

Services involved DORA mobile application

Door-to-door-journey planner

Flight Information Service

Trigger

Flow of Events Start of DORA application

Selection of flight selection option

Selection of flight via departures list or flight number search

Expected results Selection of a flight for following door-to-door route calculation.

Use Case-ID TP-02

Use Case Title Request of a door-to-door route



32 / 69 32 / 69


Assumptions The user requests a door-to-door route from the starting point to the final destination either by selecting a certain flight and let the routing system calculate the overall door-to-door route around the flight schedule or he or she determines start time or arrival time at the final destination and let the door-to-door router calculate routes including different flight connections. Based on the request parameters the door-to-door router starts the route calculation.

Pre-conditions The user has access to a DORA end-user application for trip planning

Optional: The user selects a flight as basis for his routing request

The User enters starting point and destination of his trip

The user enters start time and/or arrival time

Optional: The user chooses between different cost functions (duration, cost, CO2 emissions of the trip), if not the route calculation will prioritize duration per default

Services involved DORA end-user application

Trigger

Flow of Events The user starts the DORA end-user application for trip planning


The User enters starting point and destination of his trip

The user enters start time and/or arrival time

Optional: The user modifies the mobility settings regarding individual mobility preferences, options and restrictions

Optional: The user chooses between different cost functions (duration, cost, CO2 emissions of the trip), if not the route calculation will prioritize duration per default

Expected results Routing request to the routing system based on selected parameters

Use Case-ID TP-03

Use Case Title Calculation of a door-to-door route



Assumptions After the user starts the door-to-door route calculation based on the different routing parameters selected, the DORA end user application sends a routing request to the Door-to-Door Journey Planner. The door-to-door route is essentially a combined route of five different individual parts of the trip chain: The route from starting point to the airport, the route at and inside the airport terminal at departure, the flight itself, the route at and inside the airport terminal at arrival, and the route from the airport to the final destination. The routes to and from the airport are provided to the Door-to-Door Journey Planner by the Intermodal Landside Router, the routes at and inside the terminal by the Indoor Router. The flight part of the trip is


33 / 69 33 / 69

provided by the Flight Information service.Since there are two options on how the route is basically calculated, two different assumptions have to be described for this use case.Option 1: The user selects a specific flight that he or she will take and let the Door-to-Door Journey Planner calculate the route around this flight. Based on the departure and arrival time of the selected flight, the Door-to-Door Journey Planner requests multiple indoor routes provided by the Indoor Router that match the flight time schedule. Based on the calculated indoor routes, the time can be determined when the passenger should arrive at the airport and when he will probably leave the airport. At the same time the Door-to-Door-Router requests the partial routes for the landside parts of the trip to and from the airport provided by the Intermodal Landside Router. The Door-to-Door Journey Planner combines all partial routes provided by other services and calculates different route suggestions for the overall trip chain. Option 2: The user sets a specific time when he or she wants to start his journey or, more likely, needs to arrive at the final destination. For this case, the Door-to-Door Router requests suitable flights from the Flight Information Service and, based on the flight times, requests suitable routes for the landside and the terminal part of the trip from the ILR and IR respectively as in Option 1.



The user sets the necessary request parameters and starts the route calculation

The Door-to-Door Journey Planner receives the routing request from the DORA end-user application

The Door-to-Door Journey Planner is connected and communicating to the single DORA services providing the routes for relevant parts of the overall trip chain (Intermodal Landside Router, Indoor Router, Flight Information Service)

Optional: The user is matched to one of the specified user groups. Aim is to change the parameters for the server request. (More time for interchanging or orientation). If not the route will be calculated by default or user taken settings.


Door-to-Door Journey Planner


Indoor Router

Intermodal Landside Router

Trigger User starts door-to-door route calculation in a DORA end-user application. The application sends a routing request to Door-to-Door Journey Planner

Flow of Events The DORA end-user application sends a routing request based on different routing parameters to the Door-to-Door Journey Planner for calculation of the overall route

The Door-to-Door Journey Planner sends different routing requests to the single DORA routing services involved (Intermodal Landside Router, Indoor Router, Flight Information Service) with different request parameters (the more detailed sequences are described under “Assumptions”)

Based on the results provided by the single routing services the Door-to-Door Journey Planner combines these routes to different overall trip chains

The different overall routes suggested are sent back to the DORA end-user application informing the user about his or her options

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

The results are presented to the user in the DORA end-user application


34 / 69 34 / 69

Use Case-ID TP-04

Use Case Title Selection of routing parameter “avoid stairs”



Assumptions Under “Preferences” in the DORA end-user application the user can select the option to avoid stairs for the entire trip. This parameter will be sent to the Door-to-Door Journey Planner as part of the routing request. Following the flow of events of the overall route calculation, this setting will be taken into account for both the landside routing as well as the indoor routing. The Intermodal Landside Router only considers public transport stations in the routing where stairs can be avoided (e. g. availability of elevators, escalators or ground-level stations). Similarly the Indoor Router proposes walking routes through the terminal taking into account barrier-free terminal infrastructure such as ramps and elevators.

Pre-conditions The DORA user needs to select the option “Avoid Stairs” before the routing request.

Intermodal Landside Router has to be able to distinguish between stations where stairs can be avoided and stations where not

Indoor Router has to be able to calculate routes where stairs can be avoided

Optional: The parameter can be taken from the user group profile




Indoor Router

Trigger The DORA user selects the option “avoid stairs” and starts the routing request

Flow of Events The DORA user selects the option “avoid stairs” and starts the routing request

This parameter is sent to the Door-to-Door Journey Planner as part of the routing request

The Door-to-Door Journey Planner transmits this parameter for the calculation of the single parts of the trip chain to the respective DORA routing services

The Door-to-Door Router combines these results to route suggestions for the overall trip where stairs are entirely avoided

The DORA user receives the route suggestions via the DORA end-user application

Expected results Route suggestions for the overall route where stairs are avoided

Use Case-ID TP-05

Use Case Title Selection of a door-to-door route


External Actors(system actors or


35 / 69 35 / 69

natural persons)

Assumptions The DORA user can select one of the suggested routes to get further information or features. In the detail view of the selected route he or she gets the exact information on departure and arrival times, connection times, station names, locations of mobility services, flight gates for departure and arrival, indoor routes etc. In the detail view the user can see his selected route in either list or map format. If the route includes public transport for the way to or from the DORA user can buy the ticket directly in the DORA app [TP-09].

Pre-conditions The DORA user needs to get different route suggestions among which he or she can select a route




Indoor Router


Trigger

Flow of Events The DORA user requests a route in a DORA end-user application

Different routes are calculated by the Door-to-Door-Journey Planner and presented to the user in the DORA end-user application

The user selects a mode of transport and a route

The detail view of the selected route opens

Expected results Opening of detail view of the selected route with further information and options

Use Case-ID TP-06

Use Case Title Pre-trip information of incidents on the selected route

Use Case Cluster Trip planning


EMT

CPM

Assumptions The user has previously selected the door-to-door route option among those showed by the DORA app (based on the user preferences, origin, destination, flight schedule …), before starting the trip. So the system starts monitoring the trip (looking for actual or forecasted incidents on that specific route option) even before the user begin the trip (by clicking on “Start the trip” button).




The Door-to-Door Journey Planner receives the routing request from the DORA end-userapplication


36 / 69 36 / 69

The DORA end-user application sends a routing request based on different routing parameters to the Door-to-Door Journey Planner for calculation of the overall route

The Door-to-Door Journey Planner sends different routing requests to the single DORA routing services involved (Intermodal Landside Router, Indoor Router, Flight Information Service) with different request parameters



The user chooses on his or her preferred route option and selects it in the DORA end-user application



Trip monitoring and navigation service

Trigger An incident on the selected route option is transmitted to DORA

Flow of Events An incident on the selected route option is transmitted to DORA

The incident information is showed to the user via the DORA end-user application

The Door-to-Door Journey Planner sends different routing requests to the single DORA routing services involved (Intermodal Landside Router, Indoor Router, Flight Information Service) with different request parameters and taking into account the incident to seek other route alternatives.


The different overall routes suggested are sent back to the DORA end-user application informing the user about his or her options to overcome the incident.

Expected results Pre-trip information of actual or forecasted incidents on the specific route option selected by the user

Re-calculation and presentation to the user of the routing options to overcome the incident.

Use Case-ID TP-07

Use Case Title Adjustment of routing parameter “buffer time at the airport”



Assumptions Under “Preferences” in the DORA end-user application the user can adjust the routing parameter “buffer time at the airport”. There will be a default value for the buffer time yet to be agreed upon together with the airports. This parameter will be sent to the Door-to-Door Journey Planner as part of the routing request. Following the flow of events of the overall route calculation, this setting will be taken into account for the departure landside routing. The Intermodal Landside Router sets the arrival time at the airport for the route calculation according to the adjusted buffer time.


37 / 69 37 / 69

Pre-conditions The DORA user needs to adjust the default value “buffer time” before the routing request.

The Intermodal Landside Router has to be able to change the arrival time for the calculated route according to the adjusted routing parameter




Trigger The DORA user adjusts the routing parameter “buffer time at the airport” and starts the routing request

Flow of Events The DORA user adjusts the option “buffer time at the airport” and starts the routing request


The Door-to-Door Journey Planner transmits this parameter for the calculation of the landside part of the trip chain to the Intermodal Landside Router

The Intermodal Landside Router sends back suitable routes based on the adjusted routing parameter

Door-to-Door Journey Planner includes this response in the overall route calculation


Expected results Route suggestions for the overall route taking into account the adjusted “buffer time at the airport”

Use Case-ID TP-08

Use Case Title Adjustment of routing parameter “maximum walking distance”



Assumptions Under “Preferences” in the DORA end-user application the user can adjust the routing parameter “maximum walking distance”. There will be a default value for the maximum walking distance yet to be agreed upon among the project partners which can be changed. This parameter will be sent to the Door-to-Door Journey Planner as part of the routing request. Following the flow of events of the overall route calculation, this setting will be taken into account in the Intermodal Landside Router. Only routes are suggested where the walking distance between transport stations / vehicles / parking spaces does not exceed the set value.

Pre-conditions The DORA user needs to adjust the default value “maximum walking distance” before the routing request.

The Intermodal Landside Router has to be able to calculate routes according to the adjusted routing parameter





38 / 69 38 / 69

Trigger The DORA user adjusts the routing parameter “maximum walking distance” and starts the routing request

Flow of Events The DORA user adjusts the option “maximum walking distance” and starts the routing request


The Door-to-Door Journey Planner transmits this parameter for the calculation of the landside part of the trip chain to the Intermodal Landside Router

The Intermodal Landside Router sends back suitable routes based on the adjusted routing parameter

Door-to-Door Journey Planner includes this response in the overall route calculation


Expected results Route suggestions for the overall route taking into account the adjusted “maximum walking distance”.

Use Case-ID TP-09

Use Case Title Selection of transport modes and transport infrastructure for route calculation



Assumptions For the landside part of the trip the DORA user can select which transport modes and infrastructure should be taken into account for the route calculation. The selectable options include private car, Public transport, bike, car sharing, bike sharing, taxi, parking stations and charging infrastructure (only available for Berlin)

Pre-conditions The DORA user has access to a DORA end-user application




Trigger

Flow of Events The DORA user opens the routing request page of the DORA end-user application

He or she selects the transport modes and the transport infrastructure that should be taken into account for the route calculation

The Door-to-Door Journey planner calculates routes based on this routing parameters

Expected results Route calculation only taking into account selected transport modes and infrastructure


39 / 69 39 / 69

5.2 Trip monitoring use cases

Use Case-ID TM-01

Use Case Title On-trip information of incidents on the actual car route

Use Case Cluster Trip monitoring


Traffic Information Centre/ Traffic Management Centre

User

Assumptions The user has previously clicked on “Start the trip” button for the selected the door-to-door route option. Therefore the system starts monitoring the door-to-door trip (looking for actual or forecasted incidents or events) in motorized traffic part of the specific route option.










The user clicks on “Start the trip” button when he or she is about to start the door-to door journey.

An accident, congestion or other kind of incident happens, which massively influences the planned or current trip



Trip monitoring service

Trigger The planned route includes a motorized traffic part that is monitored and the user will be informed about the incident in the road network.

Flow of Events The selected route will be transferred to the Trip Monitoring Service at the DORA service platform

The Trip Monitoring Service observes the trip

Before the trip starts or during the trip a massive problem arises in the road network which has an impact on the saved trip

The Trip Monitoring Service is provided with the problemThe Trip Monitoring pushes the details about the related delay to the user front end


40 / 69 40 / 69

Expected results On-trip information of actual (in real time) or forecasted incidents on the specific route option selected and started by the user

Use Case-ID TM-02

Use Case Title On-trip information on the actual public transportation route



Public Transportation Operation Centre

User

Assumptions The user has previously clicked on “Start the trip” button for the selected the door-to-door route option. Therefore the system starts monitoring the door-to door trip (looking for actual or forecasted incidents or events) in the public transport part of the specific route option).










The user clicks on “Start the trip” button when he or she is about to start the door-to door journey.

An accident, incident or other kind of disruption happens that a significant delay occurs which massively influences the planned or current trip




Trigger The planned route includes a public transportation part that is monitored and the user will be informed in case of a disruption, problem or other delay

Flow of Events The selected route will be transferred to the Trip Monitoring Service component


Before the trip starts or during the trip a massive problem arises in the public transportation network which has an impact on the saved trip

The Trip Monitoring Service is provided with the problem

The Trip Monitoring pushes the details about the related delay to the user front end


41 / 69 41 / 69

Expected results On-trip information of actual (in real time) or forecasted incidents on the specific route option selected and started by the user

Use Case-ID TM-03

Use Case Title On-trip information of incidents on the actual indoor route

Use Case Cluster Trip Monitoring


Smartphone

User

Assumptions A construction site, a technical problem or any other kind of event lays to the fact, that the airport blocks certain area for passengers. The area should be entered by the airport in the DORA Incident and Management Panel, that the other DORA services can use this data.If a route was planned and calculated through the DORA WebGUI or the App details of the route will be transferred to the Trip Monitoring Service. This component monitors the current state of the planned trip and pushes information about current avoided areas to the DORA App frontend, if a problem has an impact on a calculated indoor route.

Pre-conditions The DORA backend services need to be connected to the airport infrastructure in real time

DORA frontends has been used by the user for calculating a trip which includes an indoor route at the airport

A problem or disruption or planned construction site happens which has a significant impact on the planned trip



Indoor Positioning

Indoor Router

Trigger The planned route which includes an indoor routing part at the airport is monitored and the user will be informed in case of problems

Flow of Events The selected route contains of an indoor part at the airport

The route will be transferred to the Trip Monitoring Service component


Before the trip starts or during the trip a massive problem arises at the airport infrastructure

The Trip Monitoring Service is provided with the problem

The Trip Monitoring pushes the details about the information to the user front end

Expected results Monitoring service pushes notification about a detected problem at the airport

Use Case-ID TM-04

Use Case Title On-trip information of flight related changes on the actual indoor route



42 / 69 42 / 69


Smartphone

User

Assumptions A gate change or check in counter change happens. This information will be forwarded to the DORA backend services via realized interfaces to the flight information service and data providers: FARMS System and AENA flight info service.If a route was planned and calculated through the DORA WebGUI or the App details of the route will be transferred to the Trip Monitoring Service. This component monitors the current state of the planned trip and pushes information about flight related changes to the DORA App frontend, if a problem has an impact on a calculated route

Pre-conditions The DORA backend services need to be connected to scheduled and real time flight data

DORA frontends has been used by the user for calculating a trip which includes a flight

A flight related problem arises (a gate change or a check in counter change) that has a significant impact on the planned trip

Services involved DORA end-user application (App)


Indoor Positioning

Indoor Router

Trigger The planned route which includes an indoor routing part at the airport is monitored and the user will be informed about an update in the flight specific data

Flow of Events The selected route contains an indoor part at the airport

The route will be transferred to the Trip Monitoring Service component


Before the trip starts or during the trip a gate change or check in counter change arises and has an impact on the planned route

The Trip Monitoring Service is provided with the update

The Trip Monitoring pushes the details about the information to the user front end

Expected results Monitoring service pushes notification about a flight related update at the airport

Use Case-ID TM-05

Use Case Title Transmission of incidents to DORA App



User

Assumptions The user has previously clicked on “Start the trip” button on the selected the door-to-door route option. Therefore the system starts monitoring the door-to door trip (looking for actual or forecasted incidents on that specific route option). The public transport operator and the traffic information center and the airport of the city will inform DORA in real time of any incident in their networks and operation.


43 / 69 43 / 69










Optional: The user clicks on “Start the trip” button when he or she is about to start the door-to door journey.




Trigger An incident on the started (or at least selected) route option is forecasted or occurs

Flow of Events An incident on the started (or at least selected) route option is forecasted or occurs

Data Source providers detect the incident and transmit it to the DORA System

The DORA System detects a change on the data regarding the trip

The user gets a push notification on the smartphone about the detected change

The user will be asked by the system to:

A: Start a re-routing calculation for the current trip

B: Ignore the current problem and follows the current trip advices

Expected results An incident on the started (or at least selected) route option that is forecasted or occurs, is transmitted to DORA App

Optional: Re-calculation and presentation to the user of the routing options to overcome the incident.

Use Case-ID TM-06

Use Case Title Click on “Start the trip” button



User

Assumptions The user has previously selected the door-to-door route option among those showed by the DORA app (based on the user preferences, origin, destination, flight schedule …), before starting the trip. So, when the user is about to start the door-to-door journey, he or she just clicks on “Start the trip” button on the DORA end-user application.


44 / 69 44 / 69












Trip monitoring and navigation service

Trigger The user is about to start the selected route option to the door-to-door journey

Flow of Events The user clicks on “Start the trip” button when he or she is about to start the door-to door journey.

The DORA end-user mobile device transmits the selected route and the start of the trip to the DORA Service Platform

Expected results The DORA system tracks the position of the end-user mobile device to detect any deviation on the planned route: geo-position, time, incident, delay, etc.

Use Case-ID TM-07

Use Case Title Transmission of incidents to DORA backend system



Operation Centers / Service providerso Traffic Information and Traffic Management Centerso Airport Operation Centerso Public Transport Operation Centers

Assumptions DORA is connected through realized backend interfaces to operation centers to be updated in real time about, failures, delays, planned events or construction sites for all DORA related modes of transportation: road network, public transportation system and flights

Pre-conditions Realized interfaces to the Operation Centerso Traffic Information and Traffic Management Centerso Airport Operation Centerso Public Transport Operation Centers

Services involved DORA backend


45 / 69 45 / 69

Trip Monitoring Service

Door-2-Door-Landside Router

Trigger The DORA system is provided with real time information’s about disruptions in the traffic system

Flow of Events A Operation Centre detects a disturbanceo Road traffic: congestion, accident, events, road closureso Public Transportation: Delay, failures and cancellationso Flight: Time shifts, Delayso Airports: Gate changes, construction sites, failures

The Operation Centre provides these information to external data consumers like the DORA system

The DORA backend is connected via realized interfaces to the operation centers to receive the detailed real time data

The DORA backend receives the update of the public transportation network

The Door-2-Door-Journey Planner and the Trip Monitoring Service uses the updated data

Expected results The disruptions can be used in the DORA backend for the route planning and monitoring of a planned route

Use Case-ID TM-08

Use Case Title Inserting a disturbance at the Traffic Information Centre



User (Editor)PC with local account

Assumptions The traffic news editor is provided with updates about the entire traffic and transport network and is able and allowed to enter disturbances having an impact on the entire system

Pre-conditions A road closure happens on the Berlin A113 (inner city Autobahn)

Services involved Mobility & Incident Management Panel

Trigger A huge accident arises and the Traffic Center editor enters details about the event in the DORA Mobility and Incident Management Panel. The incident news will be transferred into the DORA backend to other connected DORA panels

Flow of Events The Traffic Information Centre gets the official news from the Police/administration about a huge accident and a related road closure

This information will be entered by a traffic news editor via a local account of DORAs Mobility and Incident Management Panel (accidents are an automatic process)

The Panel provides cooperative management mechanisms and tools to support DORA´s Incident and Information Strategy

Other users (i.e. airports or public administrations) will be informed about the event and the related strategies through the DORA system

The users will be informed through the DORA end user services


46 / 69 46 / 69

Expected results The information and the related dynamic strategies to react to the accident and the road closure as best as possible are pushed through the Panel to all other traffic control and operation centers as well as to the public administration.

Through the services of the DORA platform, the passenger will be informed

Use Case-ID TM-09

Use Case Title Inserting a disturbance at the Airport operation centre



User (Editor)

PC with local account of

Assumptions A local account of the Incident and Information Management Panel is running at the airport

Pre-conditions An incident happens at the airport

Services involved Mobility & Incident Management Panel

Trigger The airport informs other operation centers and the public authority about an incident which has an impact on the accessibility of it self

Flow of Events The airport detects an incident at their infrastructure

This information will be entered by an editor via a local account of DORAs Mobility and Incident Management Panel

The Panel provides cooperative management mechanisms and tools to support DORA´s Incident and Information Strategy

Other users (i.e. other operation centers or public administrations) will be informed about the event and the related strategies through the DORA system

The users will be informed through the DORA end user services

Expected results The information and the related dynamic strategies to react to the incident as best as possible are pushed through the Panel to all other traffic control and operation centers as well as to the public administration.

Through the services of the DORA platform, the passenger will be informed

5.3 Landside transport use cases

Use Case-ID LT-01

Use Case Title Detailed guidance through road network (for drivers)

Use Case Cluster Landside Transport


Local modal router for individual transport (cars)

user


47 / 69 47 / 69

natural persons)

Assumptions The user has installed the app and a connection to the internet is available.

Pre-conditions The user already selected the origin and destination of the trip

The user has selected a criteria to calculate the optimal car route or at least a part of an entire trip is a car route

The DORA system already calculated several itineraries and displayed the best option



Trigger The user navigates within the App/web in order to get more details concerning the provided car routes, and even choose alternatives

Flow of Events The user opens the detail page of a landside itinerary (either in Berlin or in Palma) which includes a part by car

The App shows the recommended car routes and also alternatives

The user chooses an itinerary among the different options displayed (which might involve a couple of routes)

The App provides a set of different real time information options: travel time, turn relations

The user navigates and checks all the information about that itinerary, to later on maybe go back and check out detailed information about another itinerary

Expected results The user has more information about the individual transport by car itinerary and the possible alternatives

Use Case-ID LT-02

Use Case Title Public transport options and static information



- EMT - VBB- Other involved public transport companies (TIB companies in Mallorca)- user

Assumptions The user has installed the app and a connection to the internet is available..


The user has selected a criteria to calculate the optimal public transport route




Public transport service database

DORA Web service


48 / 69 48 / 69

Trigger The user navigates within the App/web in order to get more details concerning the provided public transport routes, and even choose alternatives

Flow of Events The user opens the detail page of a landside itinerary (either in Berlin or in Palma)

The App shows the recommended public transport routes and transfers, but also alternatives with their routes and transfers

The user chooses an itinerary among the different options displayed (which might involve a couple of routes and transfers)

The App provides a set of different static public information options: fares, travel time, schedules, stop location, accessibility, other

The user navigates and checks out all the information about that itinerary, to later on maybe go back and check out detailed information about another itinerary

Expected results The user has more information about the public transport itinerary and the possible alternatives

The user has checked what really was worrying him/her

Use Case-ID LT-03

Use Case Title Real time public transport information of selected routes



- Web service for real time public transport information (e.g. MobiPalma)- Public Transportation Operation Centre (EMT, VBB…)- Other involved public transport companies (TIB companies in Mallorca)- user

Assumptions The user has installed the app and a connection to the internet is available.Public transport Real Time information is available.

Pre-conditions The user has chosen the stop/station where he/she wants to get in or the mobile App chooses it automatically (if it is possible to match the nearest stop with the user’s current location)

The App already knows which public transport route the user is waiting for (previously chosen)

The period between information updates/refreshing is defined. (e.g. 1 minute)

The web services from public transport operators are able to provide current information every minute or faster.

The app is able to handle info updates and will refresh the displayed details automatically.


Trigger Tap on a “Refresh button” or “Next departures button”

Auto-update started by mobile app (an update is recognized by app)

Flow of Events A list of next departures is displayed

After a defined time the update process will start

The display will refresh if an update trigger appears

The user can select a different route or a different stop, and receive the same information


49 / 69 49 / 69

Expected results Information on the next (at least) 2 departures of the route from the selected stop/station, displayed in number of minutes left until departures

Use Case-ID LT-04

Use Case Title Detailed guidance through road network for walking and cycling



Local modal routers for walking modes

Local modal routers for cycling modes

user

Assumptions The user has installed the app and a connection to the internet is available.


The user has selected a criteria to calculate the optimal route or at least a part of an entire trip is a walking or cycling route




Trigger The user navigates within the App/web in order to get more details concerning the provided walking or cycling routes, and even choose alternatives

Flow of Events The user opens the detail page of a landside itinerary (either in Berlin or in Palma) which includes a part by walking or cycling

The App shows the recommended walking or cycling routes and also alternatives

The user chooses an itinerary among the different options displayed (which might involve a couple of routes)

The App provides a set of different static information options: especially travel time and turn relations

The user navigates and checks out all the information about that itinerary, to later on maybe go back and check out detailed information about another itinerary

Expected results The user has more information about the individual walking or cycling itinerary and the possible alternatives

Use Case-ID LT-05

Use Case Title Detailed Bike and car sharing information (location of stations, availability)



- Mobility Service Providers as Data Providers- Optional: Local Mobility Platform which has integrated bike- and car sharing platform


50 / 69 50 / 69

natural persons)

Assumptions The Intermodal Landside Router can take into account mobility services for car- and bike sharingfor the route calculation of the landside part of the trip. Static and dynamic information on car -and bike sharing is furthermore integrated into the maps of the DORA applications.

Pre-conditions Mobility Service Providers for Car- and Bike sharing need to be integrated into the local City Nodes

For consideration in the door-to-door route calculation: Local modal bike- and car sharingrouting systems are integrated in the Intermodal Landside Router

For the display of static and dynamic information in maps the car- and bike sharing data needs to be integrated into the DORA Web Map Service (Coordinates, availability)



Web Map Service

Trigger For Route Calculation: Selection of Car- and Bike sharing in the app as part of considered transport modes for routing request

For display in map: Opening of map view in the app and clicking on car- and bike sharing POIs for detailed information

Flow of Events For consideration in routing:

A DORA-User requests a route in the app which should take into account car- and bike sharing

The app sends the routing request to the Door-to-Door-Journey Planner

The Door-to-Door Journey Planner sends a routing request to the Intermodal Landside Router for the landside part of the door-to-door route.

If local modal car- and bike sharing routers are integrated into the Intermodal Landside Router for a test site, the calculated routes include options with car- and bike sharing if suitable

For display of static and dynamic car- and bike sharing information in map:

The DORA user opens the map view in an end-user application

The app requests detailed information on car- and bike sharing from the City Node over the Open Application API

The City Node provides the requested information over the Web Map Service

Expected results The user is provided with route suggestions that take into account car- and bike sharing

The user can see the location and the availability of car- and bike sharing options in the app

Use Case-ID LT-06

Use Case Title Request of secondary/alternative destinations or intermediate stops



- EMT - VBB- Other involved public transport companies (TIB companies in Mallorca)- user


51 / 69 51 / 69

Assumptions The user has installed the DORA app and a connection to the internet is available.

Pre-conditions The user has already selected a origin-destination trip and DORA has calculated an itinerary

The user has started the trip and suddenly wants to/needs to know how to get to a different location



DORA Web service

Trigger The user selects an alternative destination and taps on the “Refresh button” or “Calculate itinerary button”

The user selects and intermediate stop and taps on the “Refresh button” or “Calculate itinerary button”

Flow of Events The App sends the new request to the Intermodal Landside Router

The Intermodal Landside Router calculates a new itinerary based on user’s criteria

The different routes suggested are sent back to the DORA end-user application informing the user about his or her options

Expected results The results are presented to the user in the DORA end-user application

The user can now access to detailed public transport information (LT-2) or real time public transport information (LT-3)

Use Case-ID LT-07

Use Case Title Detailed guidance at transfer stations (public transport)



- VBB- CTM (Mallorca Transport Consortium)- user

Assumptions The (registered) user is inside an already configured building.

The mobile application is able to show and work with a georeferenced map

The mobile application has an active internet connection (Wi-Fi/data plan)

Pre-conditions The building has already been configured in the DORA platform. This implies deploying the Wi-Fi/BLE beacons and generating a RSSI Fingerprint Database (FPD).

The mobile app is able to provide RSSI values (to be later compared with the FPD)

Services involved Positioning Service

Trigger Initial trigger: the user opens the IPS tab (or a particular button in the app to be located on a map)


52 / 69 52 / 69

Flow of Events The user arrives at the transfer station (entrance) and uses the mobile app to self -locate on an indoor map. There is a special tab or a button in the app for this purpose

The mobile app gets the corresponding RSSI values from the detected Wi-Fi/BLE beacons and performs a request to the IPS. Optionally, the request can include the previous user’s position.

The IPS calculates the estimated position of the user based on the comparison of the given RSSI values with the FPD, and other conditions such as last given position and time since last request. The position is given as a georeferenced point

The mobile app shows the position on the georeferenced map

The positioning might be updated by the app performing periodical requests to the IPS service

Expected results The user is able to see his/her position on a map. The mobile app obtains the following values <lat,lon,floor_id> . The result includes a confidence level as the algorithm provides a list of the most probable nodes.

The mobile app provides guidance (via audio or visually on the mobile screen) towards the track/platform from which the rail/bus service departs

OPTIONAL: publicity of shops/cafes… at the station is shown (visual, audio) to the user if the option is selected

Use Case-ID LT-08

Use Case Title Airport Car Parking Information (Static and Dynamic)



- Mobility Service providers for car parking as data providers- Optional: Local Mobility Platform that has integrated car parking information

Assumptions The Intermodal Landside Router can take into account local car parking information in POI format for the landside routing. Static and dynamic information on car parking is furthermore integrated into the maps of the DORA applications.

Pre-conditions Mobility Service Providers for car parking need to be integrated into the local City Nodes (static and dynamic information)

For consideration in the door-to-door route calculation: POIs of Car Parking facilities need to be integrated into the Intermodal Landside Router

For the display of static and dynamic information in maps the car parking data needs to be integrated into the DORA Web Map Service (Coordinates, availability)



Web Map Service

Trigger For Route Calculation: Selection of car parking facilities in the app as part of the routing request

For display in map: Opening of map view in the app and clicking on car parking POIs for detailed information


53 / 69 53 / 69

Flow of Events For consideration in routing:

A DORA-User requests a route in the app which should take into account car parking facilities at the airport as destination/start

The app sends the routing request to the Door-to-Door-Journey Planner

The Door-to-Door Journey Planner sends a routing request to the Intermodal Landside Router for the landside part of the door-to-door route.

If car parking information is integrated into the Intermodal Landside Router for a test site, the calculated routes include options with car parking facilities as if parking spaces are available

For display of static and dynamic car parking information in map:

The DORA user opens the map view in an end-user application

The app requests detailed information on car parking from the City Node over the Open Application API

The City Node provides the requested information over the Web Map Service

Expected results The user is provided with route suggestions that take into account car parking facilities at the airports

The user can see the location and the availability of car parking facilities at the airport in the app

Use Case-ID LT-09

Use Case Title Buy public transport ticket in the DORA app (only Berlin)



VBB-backend for ticketing option in Berlin

VBB-app

Assumptions After the user has selected one of the suggested routes (TP-05), he is shown the detailed trip information. If the route to or from the airport includes a public transport trip, he has the option to buy the ticket for this trip directly in the app (in-app-solution). Attention should be paid to, that the user cannot prepay a PT-ticket for a later time or a later date. The user can only buy a ticket for the imminent next Bus or Tram or Train. Furthermore due to the fare regulation, the ticket must be bought before entering the Vehicles. After the selection of the ticketing option the user will be asked for his username and password of the public transport provider. After confirming the ticket purchase the DORA user will receive the ticket in his or her VBB-app.

Pre-conditions The DORA user selects the ticketing option for the selected public transport trip of the overall route.

The DORA user is a registered VBB-“Handyticket”-user or has a credit card for a non-registration purchase.

The DORA has access to the VBB-app (and an active mobile data connection) where he or she receives the e-ticket.




54 / 69 54 / 69


VBB ticketing backend system

Trigger The DORA user selects a route and clicks on the button “buy ticket” for the landside part of the trip (only Berlin)

Flow of Events The DORA user selects one of the suggested routes. If the landside part of the trip includes the use of public transport the user can click on the button “buy ticket”

But the user cannot prepay a PT-ticket for a later time or a later date.

The user can only buy a ticket for the imminent next Bus or Tram or Train.

Furthermore due to the fare regulation, the ticket must be bought before entering the Vehicles.

The user is asked to enter his username and password of his “VBB-Handyticket”-account directly in the DORA-app

The DORA app sends the ticket and user information to the VBB-backend

After purchasing the ticket, the user receives the ticket in the DORA app

Expected results Purchase and storing of public transport ticket directly in the DORA app

5.4 Indoor routing and positioning use cases

Use Case-ID IRP-01

Use Case Title Indoor Positioning

Use Case Cluster Indoor Positioning and Routing


User

Mobile app

Assumptions The (registered) user is inside an already configured building.

The mobile application is able to show and work with a georeferenced map

The mobile application has an active internet connection (Wi-Fi/data plan)

Pre-conditions The building has already been configured in the DORA platform. This implies deploying the Wi-Fi/BLE beacons and generating a RSSI Fingerprint Database (FPD).

The mobile app is able to provide RSSI values (to be later compared with the FPD)


Trigger Initial trigger: the user opens the IPS tab (or a particular button in the app to be located on a map)


55 / 69 55 / 69

Flow of Events 1. The user just arrives at the airport (entrance) and uses the mobile app to self-locate on an indoor map. There is a special tab or a button in the app for this purpose

2. The mobile app gets the corresponding RSSI values from the detected Wi-Fi/BLE beacons and performs a request to the IPS. Optionally, the request can include the previous user’s position.

3. The IPS calculates the estimated position of the user based on the comparison of the given RSSI values with the FPD, and other conditions such as last given position and time since last request. The position is given as a georeferenced point

4. The mobile app shows the position on the georeferenced map5. The positioning might be updated by the app performing periodical requests to the IPS

service

Expected results The user is able to see his/her position on an indoor map. The mobile app obtains the following values <lat,lon,floor_id> . The result includes a confidence level as the algorithm provides a list of the most probable nodes.

Use Case-ID IRP-02

Use Case Title Accessing Security Checkpoint



UserMobile appIntermodal Landside Router (ILR)AI- Airport Services (Waiting Time, Flight Information, etc.)

Assumptions The user has been properly guided to the right terminal (right floor - departures) via the Intermodal Landside Router (ILR)The user might have done online check-in but has to check the baggageThe user should be able to confirm/cancel events appearing in the mobile app during the navigation processThe user can configure a ‘buffer time’ as a threshold in his/her profile to indicate to the mobile app to generate alerts for ‘hurry up’

Pre-conditions The Flight ID is known by the mobile application

The user profile is known by the mobile application, as it may affect the navigation path/algorithm

Services involved Waiting Time (if available)

Positioning Service

Navigation Service

AI- Airport Services (Waiting Time, Flight Information, Status.)

Trigger Initial trigger: the user opens the INS tab

Intermediate trigger (stage 4): The user explicitly indicates the (post) check-in operation inthe mobile app. The flow can go to stage 5

Flow of Events 1. The user just arrives at the airport (entrance) and uses the mobile app to navigate to the Check-in point

2. The mobile app gets the corresponding Check-In point to go via the Airport Services3. The mobile app requests the IPS service for its position4. The mobile app requests for a path from the current position to the corresponding Check In


56 / 69 56 / 69

point. The INS service needs to map the Check In point as a text/number to a physical point (lat, lon, floor) within a graph node. The INS returns a list of nodes from origin to destination considering the user profile (e.g. impaired people will use elevator instead of stairs) and real time node status (e.g. broken escalator)

5. After confirming the check-in process, the mobile app requests a new navigation path to the security checkpoint

6. The INS service provides the shortest path considering both distance and average waiting queue time (and the general condition)

7. The user arrives at the security checkpoint

Expected results During the whole navigation process the user is positioned in the map as well as the navigation path.

If the current position is considered far away from the expected navigation node, the mobile app can alert the user and request a new navigation path.

The mobile app provides means to the user to toggle the navigation to a specific POI (e.g. toilet, restaurant). This triggers a new request to the ILN service.

The user reaches in time the proper gate

Use Case-ID IRP-03

Use Case Title Accessing the Boarding Gate



User Mobile app

AI- Airport Services (Flight Information)

Assumptions The user has successfully passed the security checkpoint

The user should be able to confirm/cancel events appearing in the mobile app during the navigation process (e.g. security passed)

The mobile app is able to handle multiple paths: a primary path refers to the boarding gate whereas a secondary path refers to visiting intermediate nodes (POIs)




Navigation Service

Trigger Initial trigger: the user clicks on the ‘security checked’ button on the mobile app

Intermediate trigger (stage 5): The user explicitly indicates to open a secondary path to a certain POI, interrupting the primary path to the boarding gate

Flow of Events 1. The user just passes the security checkpoint and uses the mobile app to navigate to the boarding gate

2. The mobile app gets the corresponding boarding gate to go via the Airport Services3. The mobile app requests the IPS service for its position (this might be already known)4. The mobile app requests for a path from the current position to the corresponding boarding

gate. The INS service needs to map the boarding gate as a text/number to a physical point (lat, lon, floor) within a graph node. The INS returns a list of nodes from origin to destination considering the user profile (e.g. impaired people will use elevator instead of stairs) and real


57 / 69 57 / 69

time node status (e.g. broken escalator)5. During the navigation towards the boarding gate, the user decides to buy sunscreen he/she

has forgotten. So he/she displays on the mobile app a layer with shops. The user selects a nearby drugstore, clicks on it and selects navigating there. The mobile app stops temporarily the current navigation and request a new navigation path from the user’s current position to the drugstore.

6. The INS service provides the shortest path to the drugstore7. The user buys the sunscreen and resumes to the primary navigation path in the mobile app to

see how to arrive at the boarding gate 8. The user arrives at the boarding gate in time



The mobile app provides means to the user to toggle the navigation to a specific POI (e.g. shop, toilet, and restaurant). This triggers a new request to the ILN service.

The mobile app sends an alert to the user if there is few time to achieve the boarding gate according to the distance

Use Case-ID IRP-04

Use Case Title Resting before boarding with alerts



User

Mobile app

AI- Airport Services (Flight Information)

Assumptions The user has successfully passed the security checkpoint

The user should be able to confirm/cancel events appearing in the mobile app during the navigation process (e.g. security passed)

The user is an experienced traveler that does not feel the need to continuously look at his/her smartphone. Consequently he/she may spend more time strolling around shops or he/she may not notice a gate change and may travel far away from the boarding gate.



The Mobile app is able to execute a vital set of functions with respect to planned trips while running in background

The Mobile app is able to keep updating user location probably at a lower rate while in background

The Mobile app can use among a number of ways for notifying the user for important issues (vibration, tones).

The Mobile app can evaluate the time required for correcting deviations from planned journey even if no detailed assistance has been selected.


Navigation Service

AI- Airport Services


58 / 69 58 / 69

Trigger The boarding gate changes

The user is found at a faraway location from the boarding gate inside the airport

Flow of Events 1. The user just passes the security checkpoint and uses the mobile app to navigate to the boarding gate

2. During the navigation the mobile app sends an alert to the user about a change in the departure time (a delay). The user has now more time and decides to go to the lounge clicking on the mobile app. The mobile app requests a new navigation path from the current position to the corresponding lounge.

3. The user enters the lounge and relaxes without noticing that there is little time left for accessing the boarding gate.

4. The mobile app still keeps track of the user’s current position and the distance to the boarding gate. If the time of boarding is approaching, and considering this distance, the mobile app sends an alert to the user in order to inform him/her to hurry up. In case the user seems not getting the regular notifications the mobile app starts using sound and vibrations so as to attract the attention of the user

5. The user checks the alert and restores the navigation towards the boarding gate. The mobile app shows the user the path from the lounge to the boarding gate

6. The user arrives at the boarding gate in time



The mobile app provides means to the user to toggle the navigation to a specific POI (e.g. shop, toilet, and restaurant). This triggers a new request to the ILN service.

The mobile app sends an alert to the user if there is few time to achieve the boarding gate according to the distance

Use Case-ID IRP-05

Use Case Title Arriving and getting the baggage



User

Mobile app

IPS (Indoor Positioning Service)

INS (Indoor Navigation Service)

AI- Airport Services (Flight Information, etc.)

Assumptions The user has accessed the airport building after getting off the plane

The user has to check the baggage

The user should be able to confirm/cancel events appearing in the mobile app during the navigation process




Navigation Service


59 / 69 59 / 69

Trigger Initial trigger: the user clicks on the ‘landed checked’ button on the mobile app and clicks on the ‘Get baggage’ button

Intermediate trigger (stage 5): The user explicitly indicates that the baggage has been got, continuing the path towards the exit node

Flow of Events 1. The user get off the plane, enters the airport building and uses the mobile app to navigate to the Baggage belt point

2. The mobile app gets the corresponding Baggage belt point to go via the Airport Services3. The mobile app requests the IPS service for its position4. The mobile app requests for a path from the current position to the corresponding Baggage

belt point. The INS service needs to map the Baggage belt point as a text/number to a physical point (lat, lon, floor) within a graph node. The INS returns a list of nodes from origin to destination considering the user profile and real time node status

5. After confirming the ‘got Baggage’ process, the mobile app requests a new navigation path to the security exit node. (This might have been performed previously while the user waits for the baggage)

6. The INS service provides the shortest path 7. The user exits the security node and enter the main hall



Use Case-ID IRP-06

Use Case Title Meeting point and exiting airport



User

Mobile app

IPS (Indoor Positioning Service)

INS (Indoor Navigation Service)

AI- Airport Services (Flight Information, etc.)

Assumptions The user has passed the security exit node

The user needs to go to a certain point in the airport before leaving (e.g. meeting point, information, tourist info)

The user should be able to confirm/cancel events appearing in the mobile app during the navigation process

Pre-conditions The user profile is known by the mobile application, as it may affect the navigation path/algorithm


Navigation Service

Trigger Initial trigger: the user clicks on the ‘security exit’ button on the mobile app

Intermediate trigger (stage 5): The user explicitly indicates that the baggage has been got, continuing the path towards the exit node


60 / 69 60 / 69

Flow of Events 1. The user exits the security exit node and enters the main hall. He/She has an arrangement with a couple of friends and the meeting point is close to the information point. The user opens the mobile app and looks for the information point (search by category). The user makes click on this POI to navigate there. The mobile app can either request for POIs or have them previously stored

2. The mobile app requests the IPS service for its position3. The mobile app requests for a path from the current position to the information point. The

INS returns a list of nodes from origin to destination considering the user profile and real timenode status

4. The user meets with his/her friends at the information node. They decide to go to the city by private transport. The user looks for car rental services in the mobile app (Search by category). The user makes click on a certain company (e.g. Avis, Europcar, etc.) to navigate there.

5. The mobile app (it already knows the current position) requests for a path from the current position to the car rental node. The INS returns a list of nodes from origin to destination considering the user profile and real time node status

6. The user and his/her friends rent a car and are able to access to the city



5.5 Waiting time information use cases

Use Case-ID WT-01

Use Case Title Estimation of waiting time at security check

Use Case Cluster Waiting time information


Mobile AppUserFlight InformationSecurity information

Assumptions The user (registered) has already registered his flight and has passed the check in (or is about to do so).The mobile device has access to a proper internet connection.

Pre-conditions The waiting time detection system is already configured at the airport

The boarding gate for the flight is already known

The security is able to inform the waiting time server of the number of gates opened for each checkpoint at any moment

Services involved Flight information Database

Web Service

API’s

Image analyzing system

Trigger The user opens the information page on his application, concerning his flight


61 / 69 61 / 69

Flow of Events The user opens the information page, which already knows which flight he is supposed to take

The server checks which security checkpoints can give access to the boarding gate

The waiting time detection system analyses the current waiting time for all of these gates

The server selects the best checkpoints given the waiting time

The application displays the location of the optimal checkpoint, and the time the user is supposed to wait

Expected results The user knows where it is better to pass the security, and how long it will take

Use Case-ID WT-02

Use Case Title Estimation of waiting time at check-in

Use Case Cluster Waiting time information


Mobile AppUserFlight InformationFlight company information

Assumptions The user (registered) has already registered his flight.The mobile device has access to a proper internet connection.

Pre-conditions The waiting time detection system is already configured on the airport

The flight company is already part of the DORA project

The check-in location is already known

The company is able to inform the waiting time server of the number of counters opened for each flight at any moment

Services involved Flight information Database

Web Service

API’s

Image analyzing system

Trigger The user opens the information page on his application, concerning his flight

Flow of Events The user opens the information page, which already knows which flight he is supposed to take

The server checks which check-in counters concern this flight

The waiting time detection system analyses the current waiting time for all of these counters

The application displays the time the user is supposed to wait for check-in

Expected results The user knows how long it will take him to check-in


62 / 69 62 / 69

5.6 Flight information use cases

Use Case-ID FI-01

Use Case Title Showing arrivals of a time period in a list

Use Case Cluster Flight Information


Mobile AppFlight Information database (airport)TravelersFamily, Friends and Service Provider (e.g. Taxi driver)Plane spotter

Assumptions The user has installed the app and a connection to the internet is available.The app could recognize the location/airport.

Pre-conditions The period for which arrivals will be displayed must be defined. (e.g. 1 h in the past and 6 h in the future)

Services involved location service (e.g. GPS)

Web service

Flight information database

Trigger A tap on the “Arrival Information”-Button will switch to a list of all flights landing during a defined period

Flow of Events The user chooses an airport of interest OR the app will recognize the geo location and is able to set the airport automatically. (resp. gives a recommendation)

After tapping the Arrival button a list of all arriving flights at the defined airport will be displayed.

Expected results All public arriving flights will be displayed in a list.

Use Case-ID FI-02

Use Case Title Showing departures of a time period in a list



Mobile AppFlight Information database (airport)TravelersFamily, Friends and Service Provider (e.g. Taxi driver)Plane spotter

Assumptions The user has installed the app and a connection to the internet is available.The app could recognize the location/airport.


63 / 69 63 / 69

Pre-conditions The period for which departures will be displayed must be defined. (e.g. 1 h in the past and 6 h in the future)

Services involved location service (e.g. GPS)

Web service

Flight information database

Trigger A tap on the “Departure Information”-Button will switch to a list of all flights starting during a defined period

Flow of Events The user chooses an airport of interest OR the app will recognize the geo location and is able to set the airport automatically. (resp. gives a recommendation)

After tapping the Departure button a list of all leaving flights at the defined airport will be displayed.

Expected results All public, leaving flights including a set of details will be displayed in a list.

Use Case-ID FI-03

Use Case Title Auto Updates of departure, arrival lists and details pages



Mobile AppFlight Information database (airport)Web service

Assumptions The user has installed the app and a connection to the internet is available.The departure list, arrivals list or flight details page is in use and displayed.

Pre-conditions The period between information updates/refreshing is defined. (e.g. 1 minute)

The web service is able to provide current information every minute or faster.

The app is able to handle info updates and will refresh the displayed details automatically.

Services involved Web service

(Push service)

Trigger Tap on a “Refresh button”

Auto update started by mobile app (an update is recognized by app)

Flow of Events A list of information is displayed

After a defined time the update process will start

The display will refresh if an update trigger appears

Expected results All current flight information including a set of details will be displayed in a list.


64 / 69 64 / 69

Use Case-ID FI-04

Use Case Title Bookmarking specific flights



Mobile AppTravelersFamily, Friends and Service Provider (e.g. Taxi driver)Plane spotter

Assumptions The user is interested in marking one or more flights to access details more quickly and enable special services, e.g. push service

Pre-conditions A list of relevant flight is shown or

A search field enables the user to find a specific flight

Services involved n/a

Trigger A specific flight has been chosen and a “Bookmark”-Button was tapped

Flow of Events The user chooses a flight

That flight is displayed in a list of all bookmarked flights (“favorites”)

The push service for that flight starts

Expected results All favorite flights are shown at one place within the app

If info updates appear push messages will be shown for all marked flights

Use Case-ID FI-05

Use Case Title Sharing flight details with third party and mobile OS



Mobile AppSocial NetworksTravelersFamily, Friends and Service Provider (e.g. Taxi driver)Plane spotter

Assumptions The user wants to share flight information with others and prefers common social networks and web services. The user want also to share flight information like times at the local system e.g. the calendar or send the information per email or messenger app.


65 / 69 65 / 69

Pre-conditions The social network/web service provider provides an API and embedded code for buttons

The mobile OS provides opportunities to log in/route to individual chosen social networks

The mobile OS provides a process to save information in other apps in the same system

Services involved APIs

Operating System

Trigger A “Share” button in the surrounding of a details page is used to choose a target provider to share defined information with Third Parties

Flow of Events The user choose a flight

The user tap the “Share” button

A selection of third party provider is shown

The user choose a provider and confirms information to be submitted

Expected results All favorite flights are shown at one place within the app

If info updates appear push messages will be shown for all marked flights

Use Case-ID FI-06

Use Case Title Search – Finding a specific flight



Mobile AppUser

Assumptions The user is looking for a specific flight and wants to find it directly by a text search.

Pre-conditions The user knows special details of the flight, e.g. flight number, airline, destination …

The user is able to type text into a text field or to use voice recognition

Services involved Web service/APIs

Operating System (voice recognition)

Trigger A search field which is displayed on several points within the app) will be filled with characters or numbers

Flow of Events The user starts to type letters or numbers

The app recommends results from 3 typed signs and more

The results list will improve with any extra sign

The user chooses a result from the list

Expected results The user will find the specific flight.

The probability of a perfect match increases with any additional character of the search word


66 / 69 66 / 69

Use Case-ID FI-07

Use Case Title Flight details and additional information



Mobile AppUserInformation providerAirlines

Assumptions The user opens the detail page of a search result and is looking for more details about the flight, but also about additional topics e.g. weather at destination, hotlines, time zone of destination etc.

Pre-conditions The user has chosen a specific flight

Services involved Flight information database

Web service

APIs

Trigger A tap on a search result or flights list (departure, arrival) will open the details page

The app will now load a package of additional information from web services or out of a cache

Flow of Events The user opens a details page of a specific flight by tapping on a search result or a list entry

The app loads information via web service / API or out of a preloaded cache

The detail page opens and displays the requested/expected information

Expected results The user will find all relevant information of a flight and around a flight on one single point of contact

5.7 Other use cases

Use Case-ID OT-01

Use Case Title Download of mobile application from app stores (for Android and iOS)

Use Case Cluster Other


Google Play Store

iTunes Store


67 / 69 67 / 69

Assumptions The DORA mobile application is one of the end-user-applications provided in the project. The app will be published for iOS and Android in the respective app stores for free.

Pre-conditions availability of mobile end-user device

Access to app stores

DORA mobile application made available in the app stores

iOS or Android operating systems

Services involved DORA mobile application

Trigger

Flow of Events Completion of DORA mobile application

Publishing of application in the app stores

Download of app by users

Expected results Installed DORA mobile application on mobile end-user devices


68 / 69 68 / 69

6 CONCLUSIONS

In this document, a description of the use cases that might be selected to be demonstrated

in DORA has been presented. They have been developed according to the methodology

explained in section 2.2. Moreover they have been structured in several clusters according

to the main features of the DORA system.

The list of use cases intends to cover all the possible situations and functionalities that DORA

system will provide to the main users involved (passengers, operation centres) but once the

system architecture and the services specifications will be defined in the forthcoming tasks,

a realistic yet feasible selection of the use cases to be demonstrated might be taken into

consideration.


69 / 69 69 / 69

References

[1] Usage Scenarios: An Agile Introduction.

http://agilemodeling.com/artifacts/usageScenario.htm#sthash.t6xnKQTZ.dpuf

[2] Use Cases. http://www.usability.gov/how-to-and-tools/methods/use-cases.html.

[3] Shrivathsan, Michael. Use Cases – Definition (Requirements Management Basics). 2009.

http://pmblog.accompa.com/2009/09/19/use-cases-definition-requirements-

management-basics/.

[4] Cockburn, Alistair. Writing Effective Use Cases. s.l. : Addison-Wesley Professional, 2000.

0-201-70225-8.

[5] Wikipedia. Use case. http://en.wikipedia.org/wiki/Use_case.

[6] Jacobson, Ivar. USE-CASE 2.0 The Definitive Guide. s.l. : Ivar Jacobson International,

2011.

[7] Bittner, Kurt y Spence, Ian. Use-Case Modeling. The definitive guide to creating use-

case models and writing good use cases. s.l. : Addison-Wesley Professional, 2002. ISbn-

10: 0201709139.

[8] Wikipedia. Use case diagram. https://en.wikipedia.org/wiki/Use_Case_Diagram.

[9] Use case diagram (UML use case diagram).

http://whatis.techtarget.com/definition/use-case-diagram

door to door information for air passengers€¦ · door to door information for air passengers d...

Documents