door to door information for air passengers · 2016. 8. 1. · dora deliverable d3.3 3/ 78...

Door to Door Information for Air Passengers

D3.3 DORA Service Specification

Editor: Santiago Martínez, German Martínez, Patricia Bellver, ETRA

Deliverable nature: Report (R)

Dissemination level: Public (PU)

Date: planned | actual 31 July 2016 29 July 2016

Version | no. of pages Version 1.0 78

Keywords: Services, design and definition, specifications

DORA Deliverable D3.3

2 / 78

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 3 VMZ

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

Copyright notice

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


3 / 78

Executive Summary

D3.3 is the outcome of task 3.2 Design of DORA Services, whose aim is to concretize the

new services for the two pilot sites to be integrated in the overall DORA system. Using the

input of task 2.4 and task 3.1, concrete functions for the different services have been

defined.

The final version of the DORA Architecture was provided in deliverable D3.2 DORA

Architecture, where the overall system was extensively explained. The DORA services are

classified as City Node Services and Central Services, depending on the fact that the DORA

components can be located in a cloud environment since it is independent from local

infrastructure and hardware. The DORA Central Services include the D2D Journey Planner

component, the Flight Routing Service, the Indoor Routing Service, the Intermodal

Landside Router, the Indoor Location Service, the Maps Service and finally, the Trip

Monitoring Service. The entire communication between all frontends, Central and City

Node Services is realized through the API Gateway via the two open DORA interfaces:

Open Application API and Open Service API. The open source tool WSO2 API Manager

allows internal and external developers to access the DORA Central and City Node

Services.

In this deliverable, the DORA Central Services and the DORA City Node Services are

described, but with different levels of detail. First, the detailed specification of the DORA

Central Services, in which all functionalities are described and illustrated in an Enterprise

Architect diagram showing the connection of each functionality to involved external

components, internal modules, and technical requirements. Afterwards, the different

internal modules required in order to provide all functionalities are described. And finally,

the functionalities of the Central Service are illustrated via sequence diagrams, showing

the interdependencies between different components, in addition to the information

flows and the detailed processes required to fulfil the mentioned functionality of the

service. Each functionality of the Central Service is illustrated in a separate sequence

diagram. In contrast, the City Node Services are described roughly with reference to the

developer API, in order to shorten the extent of this deliverable. In addition, the related

DORA requirements (see deliverable D 2.4 Technical and Legal Requirements for more

details) are listed for each City Node Service.


4 / 78

List of Authors

Organisation Authors Main organisations’ contributions

ETRA

Santiago Martínez

German Martínez

Patricia Bellver

Executive summary; Table of contents;

Section 1, 2, 3.5, 4, 5

VMZ Jan-Niklas Willing Section 3.1, 3.3, 3.4, 3.9, Internal Review

CSEKonstantinos

KoutsopoulosSection 3.6

UPV Benjamin Molina Section 3.2, 3.6, 3.8

EUREVA Philippe Martineau Section 3.7, 4.15


5 / 78

Table of contents

1 INTRODUCTION................................................................................................ 11

1.1 Background......................................................................................................11

1.2 Purpose of the Document.................................................................................12

1.3 Structure of the Document ...............................................................................12

2 APPROACH AND METHODOLOGY .....................................................................13

2.1 Vocabulary and definitions...............................................................................13

2.2 Approach for the Specification of Services ........................................................ 13

2.2.1 Central Services ................................................................................................... 15

2.2.2 City Node Services................................................................................................ 16

2.3 Methodology for the Specification of Services ..................................................20

3 SPECIFICATION OF DORA CENTRAL SERVICES....................................................21

3.1 Intermodal Landside Router .............................................................................21

3.1.1 General Description ............................................................................................. 21

3.1.2 Functionalities Overview...................................................................................... 21

3.1.3 Internal view and modules ................................................................................... 23

3.1.4 Sequence Diagrams of service procedures ........................................................... 26

3.2 Indoor Routing .................................................................................................30





3.3 Maps Service....................................................................................................35



3.3.3 Internal View and Modules .................................................................................. 37

3.3.4 Sequence Diagrams of Service Procedures ........................................................... 38

3.4 Trip Monitoring................................................................................................ 41


6 / 78





3.5 Flight Information Service ................................................................................49





3.6 Indoor Location................................................................................................ 56





3.7 Waiting Time Detection....................................................................................60




3.7.4 Sequence Diagram of service procedures............................................................. 63

3.8 Indoor Navigation ............................................................................................ 64

3.9 D2D Journey Planner........................................................................................ 66




3.9.4 Sequence Diagrams of Service Procedures ........................................................... 70

4 SPECIFICATION OF CITY NODES SERVICES ......................................................... 73

4.1 Overview on City Node Services in City Node Berlin and Palma ......................... 73

4.2 Departures.......................................................................................................73


7 / 78

4.3 Arrivals ............................................................................................................73

4.4 Carsharing........................................................................................................73

4.5 Geocoding........................................................................................................74

4.6 Bikesharing ......................................................................................................74

4.7 Parking ............................................................................................................74

4.8 Airports ...........................................................................................................75

4.9 Electric Vehicle Charging ..................................................................................75

4.10 Incidents ..........................................................................................................75

4.11 Public Transport ............................................................................................... 75

4.12 Taxi..................................................................................................................76

4.13 Weather ..........................................................................................................76

4.14 Routing ............................................................................................................76

4.15 Waiting Time ...................................................................................................76

4.16 Rental ..............................................................................................................76

4.17 Fuel Stations ....................................................................................................77

5 CONCLUSIONS..................................................................................................78


8 / 78

List of Figures

Figure 1: Dora Components to be developed................................................................... 14

Figure 2: API Gateway ..................................................................................................... 15

Figure 3: DORA Central Services ...................................................................................... 16

Figure 4: City Node Berlin Services .................................................................................. 17

Figure 5: City Node Palma Services .................................................................................. 19

Figure 6: Functionalities of the Intermodal Landside Router ............................................ 22

Figure 7: Functionalities of the Intermodal Landside Router............................................ 22

Figure 8: Intermodal Landside Router – internal view and interdependencies ................. 25

Figure 9: Intermodal Route Calculation – Sequence Diagram........................................... 27

Figure 10: Pre-processing of Route Calculation – Sequence Diagram............................... 28

Figure 11: Integration of Local Modal Routers – Sequence Diagram ................................ 29

Figure 12: Integration of Location Based Services – Sequence Diagram ........................... 30

Figure 13: Functionalities of the Indoor Routing Service .................................................. 31

Figure 14: Functionalities of the Indoor Routing Service .................................................. 32

Figure 15: Indoor Routing Service– internal view and interdependencies ........................ 33

Figure 16: Indoor Routing - Sequence Diagram................................................................ 34

Figure 17: Functionalities of the Maps Service................................................................. 36

Figure 18: Overview on Functionalities of the Maps Service ............................................ 36

Figure 19: Maps Service – internal view and interdependencies...................................... 38

Figure 20: Integrate indoor POIs – Sequence Diagram ..................................................... 39

Figure 21: Integrate landside POIs – Sequence Diagram .................................................. 39

Figure 22: Cache indoor and landside POIs – Sequence Diagram ..................................... 40

Figure 23: Provide images to frontends – Sequence Diagram .......................................... 41

Figure 24: Functionalities of the Trip Monitoring Service................................................. 42

Figure 25: Overview on functionalities of the Trip Monitoring Service ............................. 43


9 / 78

Figure 26: Trip Monitoring Service – Internal view and interdependencies...................... 45

Figure 27: Monitor a not yet started trip – Sequence Diagram ........................................ 46

Figure 28: Monitor an already started trip – Sequence Diagram. ..................................... 47

Figure 29: Update Trip Information – Sequence Diagram ................................................ 48

Figure 30: Trigger a rerouting – Sequence Diagram ......................................................... 49

Figure 31: Functionalities of the Flight Information Service ............................................. 50

Figure 32: Overview on functionalities of the Flight Information Service ......................... 51

Figure 33: Flight Information Service – Internal view and interdependencies .................. 52

Figure 34: Scheduled information about flights– Sequence Diagram ............................... 53

Figure 35: Connection among Flights – Sequence Diagram .............................................. 54

Figure 36: Real time flight information– Sequence Diagram ............................................ 55

Figure 37: Functionalities of the Indoor Location Service................................................. 56

Figure 38: Functionalities of the Indoor Location Service................................................. 57

Figure 39: Indoor Location Service– internal view and interdependencies....................... 58

Figure 40: Calculate Location - Sequence Diagram........................................................... 59

Figure 41: Fingerprinting Database Maintenance - Sequence Diagram ............................ 60

Figure 42: Functionalities of the Waiting Time Service..................................................... 61

Figure 43: Waiting Time - Sequence Diagram .................................................................. 63

Figure 44: Real-Time Waiting Time - Sequence Diagram .................................................. 64

Figure 45: Indoor Navigation - Sequence diagram ........................................................... 66

Figure 46: Functionalities of the Door to Door Journey Planner ....................................... 67

Figure 47: Overview on Functionalities of the Door to Door Journey Planner .................. 68

Figure 48: Door to Door Journey Planner – internal view and interdependencies ............ 69

Figure 49: Calculation of Door to Door Route – Sequence Diagram ................................. 70

Figure 50: Cache the User Profile – Sequence Diagram.................................................... 71

Figure 51: Cache the Trip Input Parameters – Sequence Diagram.................................... 72


10 / 78

Abbreviations

Abbreviation Explanation

API Application Interface

APP DORA App

BER Berlin-Brandenburg Airport

BLE Bluetooth Low Energy

D Deliverable

D2D, DJP Door-to-Door Journey Planner

DORA Door to Door Information for Airports and Airlines

EV Electric Vehicle

FIS Flight Information Service

GUI Graphical User Interface

HTTP Hypertext Transfer Protocol

ILR Intermodal Landside Router

IR Indoor Routing

JPEG Joint Photographic Experts Group

MAC Media Access Control

MIM Mobility and Incident Management Panel

OGC Open Geospatial Consortium

OSM Open Street Maps

PNG Portable Network Graphics

POI Point of Interest

REST Representational State Transfer

RSSI Received Signal Strength Indication

SWA DORA Smart Watch App

TMS Trip Monitoring Service

TMS Tile Map Service

WMS Web Map Service

WP Work Package

WTS Waiting Time Service


11 / 78

1 INTRODUCTION

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

project and of the deliverable D3.3 DORA Service Specification. The contents of the

deliverable are summarized in this section and navigation guidelines are provided as well.

1.1 Background

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

With regard to the technical realization the DORA basic system components and their

integration in the overall system will be specified and their adaption according to the pilot

specific requirements will be described in WP3. Main input for this work will come from

an assessment of the systems available at the sites and new services to be deployed.

Based on a specification and priorization of the use cases at the pilots (as result of WP2)

the system components and services will be identified and interdependencies, interfaces

and data flows will be specified.

Apart from the technical challenges DORA has to find new ways of cooperation of the

partners. For that the operative and business requirements will be elaborated and a

business and cooperation model will be set up.

Outcomes of WP3 are:

A detailed software and hardware architecture which will be the basis for the

integration of the pilot-site specific services and system components and the

development of new services

Specification of services for Indoor-Location, Waiting time detection and Door-to-

Door-Routing


12 / 78

Concept for Operation Centre Application

Identification of interdependency between services, specification of interfaces and

data exchange

Specification of the end-user applications

Business and Cooperation Model

Five deliverables are planned in the WP3, namely:

D3.1 Initial specification of DORA Architecture

D3.2 DORA Architecture

D3.3 DORA Service Specification

D3.4 Specification of DORA Applications

D3.5 Analysis of Suitable Cooperation and Business models

1.2 Purpose of the Document

D3.3 is the outcome of Task 3.2- Design of DORA Services, whose aim is to concretize the

new services for the two pilot sites to be integrated in the overa ll DORA systems. Using

the input of task 2.4 and task 3.1, concrete functions for the different services will be

defined. Moreover, the hard- and software requirements for testing of the systems

indoor location and waiting time will be specified.

1.3 Structure of the Document

The following document has been structured based on the DORA description of action ,

discussion with VMZ partners in order to use the same approach both in D3.3 and D3.4,

and finally, approved by project partners involved in task 3.2.

The document is roughly clustered into five sections. The first and current part deals with

the introduction chapters. The next chapter 2 focuses on the methodological approach

describing which methods have been used to reach the formulated target of specifyi ng

the DORA services. The third part consists of the detailed specification of the DORA

central services in which all functionalities are described and illustrated via sequence

diagrams. In the fourth section of the document the city node services are desc ribed

roughly with reference to the developer API. Finally, the fifth section of the deliverable

provides a conclusion and an outlook to the upcoming software development processes

in WP4.


13 / 78

2 APPROACH AND METHODOLOGY

2.1 Vocabulary and definitions

Service

Within the DORA project consortium the concept “service” stands for a backend

component which is in charge of providing data or functionalities that can be used by an

application or other DORA internal service.

Application

An application is a user front end, UI or App (abbreviation) for end users like passengers

or travellers (DORA Smartphone App, DORA Smartwatch App, and DORA Web GUI). In

addition, the front end for operation centre managers (Incident and Information

Management Panel) is also considered an application.

Functionality

In information technology, a functionality is the sum or any aspect of what a product can

do for a user.

2.2 Approach for the Specification of Services

The specification process of backend services and front ends is distinguished since the

work program was described as part of the Description of Action (DoA) document.

However it has been planned from the beginning that both processes are streamlined and

run in parallel during the same period of time. Regarding this, the general concept and

approach of how the specification process will be done, both for the services and the

applications, follow the same ideas.

The final version of the DORA Architecture was provided in deliverable D3.2 DORA

Architecture. Here the overall system was extensively explained. The below presented

figure includes the DORA architecture which will be realized during the project lifetime in

both City Nodes Palma and Berlin. Based on a previous task of identifying available

services and data, this view is used to show what kind of components are completely

new, which components already exist (and will be extended) and what is out of scope per

City Node.


14 / 78

Figure 1: Dora Components to be developed

The entire communication between all frontends, Central and City Node Services is

realized through the API Gateway via the two open DORA interfaces: Open Application

API and Open Service API. The open source tool WSO2 API Manager allows internal and

external developers to access the DORA Central and City Node Services.


15 / 78

Figure 2: API Gateway

The DORA Architecture foresees three end user applications which will be developed

during the project lifetime: DORA Smartphone Application, Smartwatch Application which

needs the communication between the wearable and the Smartphone and the responsive

website DORA Web GUI. Furthermore the two operation centre applications will be

realized. But they are designed for operation and control centre managers and not for

passengers or travellers. The last to be developed application - the so called DORA 3rd

Party App - is not a DORA internal front end. It is an external front end or application

provided by airlines, airports or cities. If potential 3rd parties are interested in the use of

DORA results, they can have access to the internal DORA systems by using the Open

DORA APIs.

2.2.1 Central Services

The Central Services aim is that the DORA components can be located in a cloud

environment since it is independent from local infrastructure and hardware. This means

that every component which is a Central Service has to interact through the API Gateway

with the applications and City Node services through the open interfaces. Therefore, it is

not required that all involved components are running in the same environment or at the

same physical place.

The DORA Central Services include the D2D Journey Planner component. This complex

component is in charge of calculation of the entire door-to-door route from starting point

A to the final destination B including the flight information and indoor situations at the

airport. Therefore, it is provided with data from other single components from the

Central Services and the local City Node Services. At Central Service level the Intermodal

Landside Router, the Flight Routing Service and the Indoor Routing Service are involved to

provide the airport related routing results to the D2D Journey Planner.

The Intermodal Landside Router does not require a complete new software development.

It is based on a VMZ Berlin development called Intermodal Router (IMR). This component

calculates intermodal routes for all relevant inner urban transport modes (walk, (own)


16 / 78

bike, car, public transport, car sharing and bike sharing).

The Indoor Location Service provides all indoor positioning related data for both airports

Berlin and Palma.

The Maps Service is in charge of the provision of map tiles and the related drawing

procedures for icons and maps.

Trip Monitoring Service will be developed to supervise and control a chosen complete

door to door journey in cases of disruptions or disturbances.

In summary, except of some parts of the Intermodal Landside Route all components are

new DORA software developments.

Figure 3: DORA Central Services

2.2.2 City Node Services

Before entering in detail with the city specific services, it should be clarified the main

differences among the Central Services and the City Node Services. The first ones are

services available for every city node connected to the DORA system, as well accessi ble

for third party libraries. They provide general information that affect to every user or

entity of the DORA system.

The information related to the different City Nodes is provided by the services that will be

explained below: the City Node Services.

City Node Berlin

In Berlin, most of the services are in place and will be used or need to be extended for the

use in DORA. The variety of car and bike sharing as well as ride sharing options allows the

provision of data for all relevant modes of transportation. Through the use of the DORA

APIs the needed and requested data will be provided by each relevant service in the

defined DORA format.


17 / 78

Figure 4: City Node Berlin Services

A Geocoding service is available and will be extended for the use in the project. The

routing service is available as well. To be more precise, at the Berlin cluster there are

single modal routers for car, bike, walk and public transport available and will be matched

in the local routing service. Services for more conventional transport modes like public

transportation and or taxi are available as well. Regarding near mobility services like fuel

stations, EV charging stations and parking available services will be adapted to the DORA

concept too. Here real time data are available for occupied parking places or currently

used charging stations. In addition, real time prices for the fuel stations are available

through a service too.

Incident data for the landside transport can be provided by an adapted service as well.

The data basis for this is the Berlin Traffic Information Centre. Here the VMZ Berlin is in

charge of the operation for the Senate Department for Urban Development and the

Environment and has access to this data.


18 / 78

An existing weather data service will be adapted for delivering real time weather

information.

The local Incident and Information Management system (AIRVIS) will be extended for the

use at Berlin Schönefeld airport because of the fact that the former AIRVIS system has

been planned for the new airport BER only. Since it is fixed that after the opening of the

new BER the old Berlin Schönefeld airport will be used in parallel, the ARIVIS system has

to be adapted.

In addition, complete new services have to be developed regarding arrival and departures

for all public transport services and airport related flight data. Regarding the indoor

location airport data a new service for the positioning has to be developed. In parallel the

new waiting time service for calculation waiting times at the queues need to be installed.

Finally, a local rental service for the provision of static rental service data will be installed

at the Berlin City Node.

City Node Palma

For the City Node of Palma, the DORA services to be implemented are the ones related to

the airport (Arrival, Departures, Airport Data and Waiting Time). Although the Strategic

Routing Service won't be implemented, it is being covered by the new DORA Incident and

Information Management System. On the other hand, an Incidents service will be

integrated. Moreover, a new routing service will be implemented and will cover this

feature for the different modes of transport available in Palma de Mallorca.


19 / 78

Figure 5: City Node Palma Services

Most of the services will be adapted from already existing ones, or extended. The

Geocoding service could be covered using Nominatium, a service based in OSM.

Regarding Bikesharing and Parking services, they will offer dynamic information, but not

the capability of booking bikes neither car parking positions. In the Rental service for

Palma, available static information will be offered. Something similar happens with Taxi

service; only static information such as the geolocation of taxi stands will be available. By

the end of the year 2016 it is expected that the MobiPalma App offers geolocation of EV

Charging stations, so this service will be offered in DORA too, as well as the static

information on available Fuel Stations in Palma. Public Transport dynamic information

and incidents will be also a key part of the DORA Palma City Node. Weather, as well as in

Berlin, will be implemented using weather.com existing services.

Lastly, Carsharing and Ridesharing are out of the scope in the DORA Palma City Node

because there are no service providers offering this kind of mobility options.


20 / 78

2.3 Methodology for the Specification of Services

In the next two sections of the deliverable, both the DORA Central Services and the DORA

City Node Services will be described, but with different levels of detail.

In section 3, it can be found the detailed specification of the DORA Central Services in

which all functionalities are described in the subsection Functionalities Overview. These

functionalities are illustrated in an Enterprise Architect diagram showing the connecti on

of each functionality to involved external components, internal modules, and technical

requirements that need to be taken into account. Afterwards, the different internal

modules, which can be different pieces of software or other involved technical

components as part of the Central Service required in order to provide all functionalities

(illustrated previously). And finally, the functionalities of the Central Service are

illustrated via sequence diagrams. In addition to the static diagrams presented in the

previous subchapters, sequence diagrams not only show the interdependencies between

different components, but also the information flows and the detailed processes required

to fulfil the mentioned functionality of the service. Each functionality of th e Central

Service is illustrated in a separate sequence diagram.

In contrast, in the fourth section of this document the City Node Services are described

roughly with reference to the developer API, in order to shorten the extent of this

deliverable extension. In addition, the related DORA requirements (see deliverable D 2.4

Technical and Legal Requirements for more details) are listed for each City Node Service.


21 / 78

3 SPECIFICATION OF DORA CENTRAL SERVICES

3.1 Intermodal Landside Router

3.1.1 General Description

The Intermodal Landside Router is the central service providing the landside parts of the

overall trip to the Door-to-Door Journey Planner. The Intermodal Landside Router will

consist of two instances: One for each of the test sites Palma de Mallorca and Berlin. It is

the central routing service for integrating all car, taxi, bike, carsharing and public

transport routers which are part of the DORA city nodes. The main task is to combine the

different modal routing results to intermodal routes and provide these to the Door to

Door Journey Planner over the DORA Service API when requested.

3.1.2 Functionalities Overview

The intermodal Landside Router contains different major functionalities that are

necessary in order to provide all required data and information to other services of the

DORA system. The first service functionality is the Integration of local modal routers

which are provided by the local city nodes in a modal routing platform which is one of the

internal modules of this central service. This integration process ensures that the modal

routing results are in the correct format for the further route combination steps. The

second functionality is the preprocessing of certain parts of a route. The preprocessing

especially covers certain walking routes, e.g. from starting point to the nearest public

transport stops or carsharing vehicles. The preprocessing is being carried out in parallel to

the actual route calculations and supports the overall performance of the route

calculation and shortens the response time by providing pre-calculated route elements.

The third functionality is the integration of the location based services from the city

nodes. In this later described integration module of the Intermodal Landside Router the

location based information from the DORA city nodes such as location and availability of

carsharing vehicles, public transport stops etc. is cached and provided to the intermodal

route calculation functions. The central functionality of the Intermodal landside router is

the intermodal route calculation based on the combination of the different modal

routers and preprocessed route elements. The final route recommendations are then

provided to the Door to Door Journey Planner.


22 / 78

Figure 6: Functionalities of the Intermodal Landside Router

In the figure below the named functionalities of the Intermodal Landside Router are

illustrated in an Enterprise Architect diagram showing the connection of each

functionality to involved external components, internal modules, and te chnical

requirements that need to be taken into account. This schematic representation is

analogous to the feature tree of the application specification in deliverable 3.4.

Figure 7: Functionalities of the Intermodal Landside Router


23 / 78

3.1.3 Internal view and modules

The Intermodal Landside Router consists of different internal modules which can be

different pieces of software or other involved technical components as part of the

Intermodal Landside Router required in order to provide all functionalities as illustrated

above. There are namely four different internal modules of the ILR which can be

identified.

Modal Routing Platform

To integrate the local modal routers provided by both DORA city nodes (Routing/car,

Routing/bike, Routing/walk, Routing/urbanPublicTransport) the Intermodal Landside

Router contains a modal routing platform which converts the routing results into the

correct format for the core service of the ILR. The routing results of the local modal

routers in the city nodes are requested over the DORA service API. Northbound the modal

routing platform is connected to two other modules of the ILR, the preprocessing module

and the ILR core module for the actual combination of the different modal routes.

POINT Module

The POINT module integrates all location based services from both city nodes in one piece

of software and provides this information to the ILR core module and the preprocessing

module for route calculation purposes. The location based data from the city nodes

includes the location and availability of different mobility options. The DORA City node

services which are requested to provide data to the POINT module are carsharing,

bikesharing, EVChargin, fuelStations, incidents, parking, publicTransport, rental, and taxi.

The POINT module contains a caching functionality in order to store the location based

data for a certain amount of time and provide this information to the preprocessing

module and the ILR core module when requested. The current locations of geo-localized

incidents, of free-floating carsharing vehicles or charging stations and their availabilities

are important for the ILR core module to calculate sensible routes based on real -time

locations and availabilities of different mobility services.

Preprocessing Module

The purpose of the preprocessing module is to shorten the overall route calculation time

of the ILR core module by providing simple route elements based on the walk router of

the modal routing platform and the location based services stores in the P OINT module.

Basic routes elements such as walking from the current location to the next transport

stop, carsharing vehicle or bikesharing stations can be calculated in parallel to the actual

intermodal route calculation in the ILR core module. The preproc essing module


24 / 78

continuously provides these routes bit by bit to the ILR core module so that these

elements can be added to the combined intermodal routes.

ILR Core Module

The ILR core module represents the central piece of software of the ILR. This module is

supported by the three other internal modules of the ILR. It receives simple pre -

calculated routing elements by the preprocessing module, the availabilities and locations

of mobility services by the POINT system and the modal routing functions by the mo dal

routing platform. Based on the input parameters and personal mobility preferences and

constraints received by the Door to Door Journey Planner, the ILR core module combines

the modal routing results to intermodal route combinations and provides the mos t

suitable results to the Door to Door Journey Planner.

The following diagram illustrates which internal modules are located inside the

Intermodal Landside Router highlighted in red, how they interact with each other and

with which other external components of the DORA system the Intermodal Landside

Router is interconnected. The service procedures of the ILR including the information

which data is processed over which interfaces, will be illustrated in more detail in 3.1.4.


25 / 78

Figure 8: Intermodal Landside Router – internal view and interdependencies


26 / 78

3.1.4 Sequence Diagrams of service procedures

In this subchapter the four functionalities of the Intermodal Landside Router are

illustrated via sequence diagrams. In addition to the static diagrams presented in the

previous subchapters, sequence diagrams not only show the interdependencies between

different components but also the information flows and the detailed processes required

to fulfil the mentioned functionality of the service. Each functionality of the ILR is

illustrated in a separate sequence diagram.

The central functionality, the intermodal route calculation, is presented in the diagram

below. The ILR core module of the Intermodal Landside Router receives an intermodal

routing request by the Door to Door Journey Planner. In order to start the intermodal

route calculation the ILR needs to receive three different inputs from the other internal

modules of the ILR. First he requests the pre-calculated simple route elements from the

preprocessing module. Secondly the ILR core module requests the different modal routes

for walking, biking, public transport and car by the modal routing platform. And thirdly

the core module requests the locations and availability of the different mobility services

in each test site from the POINT module. The three different requests are sent shortly

after one other so that the requested modules are able to work in parallel.


27 / 78

Figure 9: Intermodal Route Calculation – Sequence Diagram

The preprocessing functionality is carried out in the following way. The ILR Core Module

requests the preprocessed route elements by the preprocessing module. In order to do

the preprocessing the module requests the modal routing platform for the differe nt

modal routes with a focus on walking routes. Secondly it requests the POINT module for

the current locations and, where applicable, availabilities of different mobility services

and data such as incidents or carsharing vehicles. Based on the modal routi ng results in

combination with the data on location based services, the preprocessing module pre -

calculates different route elements, such as walking to the closest bikesharing station,

and provides this data to the ILR core module.


28 / 78

Figure 10: Pre-processing of Route Calculation – Sequence Diagram

The ILR functionality for integrating local modal routers involves the internal modules ILR

core and the modal routing platform. The ILR core module requests the modal routes

from the modal routing platform. This module in turn receives the test site specific

routing results from the modal routing service within each city node. Based on the

bundled routing data, the routing platform responses to the ILR core module for further

intermodal route calculation.


29 / 78

Figure 11: Integration of Local Modal Routers – Sequence Diagram

In the last sequence diagram the integration of Location Based Services is illustrated. The

ILR Core module requests the POINT module for bundled locations and availabilities of

mobility services or incidents. The POINT module receives this information from the

different services within both city nodes. These services include, as shown in chapter

3.1.3, carsharing, bikesharing, EVCharging, fuelStations, incidents, parking, public

transport, rental and taxi.


30 / 78

Figure 12: Integration of Location Based Services – Sequence Diagram

3.2 Indoor Routing


The Indoor Routing Service is a central service aimed to be used by the D2D Journey

Planer libraries in order to obtain indoor paths with time estimations to be merged with

the outdoor paths and thus be able to generate a global path for the traveler. There will

be one instance of the service accessible by the D2D Journey Planer via the API Gateway.

The main task of the service is to generate optimal indoor paths considering the status of

the airport, waiting queues, boarding gates (if this item of information is available) and

user profile. This calculation is performed offline (the event will occur in the future) and

thus any returned path must be considered as a draft estimation; the accuracy is

supposed to be better for indoor navigation (see corresponding section). The Indoor


31 / 78

Routing and the Indoor Navigation are very similar services, as will be described.


The Indoor Routing service is a complex service that has to provide indoor paths in a

similar way as done for outdoor paths, considering various variables that separate the

overall process in different functionalities. Four separate main functionalities have been

defined. The first service functionality is related to getting the mean queuing values, at

least for the security checks. As this is a prediction, the WTS (Waiting Time Service) has to

provide a mean value based on a model, or at least provide a worst case value. The

second functionality considers the user profile in order to avoid, for example, stairs for

people that need wheelchair. The third functionality is responsible for updating the

navigation graph from the results obtained in the two previous functionalities. Finally,

the fourth functionality calculates the route from one origin node to a destination node

from the generated graph.

Figure 13: Functionalities of the Indoor Routing Service

In the figure below the Indoor Routing Service is presented in an Enterprise Architect

diagram showing the connection of each functionality with the involved internal

components and technical requirements that need to be taken into account.


32 / 78

Figure 14: Functionalities of the Indoor Routing Service


The Indoor Routing service contains six internal modules that are presented in the

following paragraphs.

Route Calculator

This module contains the implementation of the route calculation based on a provided

graph from one node to a destination node. The result is a set of different paths based on

the request.

REST Module

The REST module implements the API functionality through which both administrative

tasks and user service requests can be submitted.

Queuing Time Element

This module is responsible for interacting with the Waiting Time Service in order to obtain


33 / 78

an estimated/predicted mean value.

Graph Element

This module updates the navigation graph on a per request basis depending on the

various parameters to consider.

User profile Element

The module parses the user profile and indicates the adjustments to be performed on the

navigation graph.

Airport Data Element

The module parses data from available airport services and indicates the adjustments to

be performed on the navigation graph. This module will typically not be available for

offline Indoor Routing, but for the Indoor Navigation. Anyway, in the case that this

information is not provided, it can be given in a different way in the request API.

Figure 15: Indoor Routing Service– internal view and interdependencies


34 / 78


The sequence diagram for the Indoor Routing Service is presented in this paragraph.

The sequence starts with the user through its web UI making use of the D2D Journey

Planner. It is this service which interacts with the Indoor Routing Service, e.g. it is not

directly visible from the user. The D2D Journey Planner uses the REST API to get indoor

paths. The request is passed to the ‘Calculate Route’ that requires a valid navigation

graph to start performing the calculation. The Graph Element updates the graph based on

two fundamental parameters: user profile and Queuing Time. As commented before,

airport data is possible but will realistically feasible for online indoor navigation.

Figure 16: Indoor Routing - Sequence Diagram


35 / 78

3.3 Maps Service


The Maps Service is the central service which provides the DORA frontends with rendered

images in WMS or TMS standards. To be able to display the real -time locations and

statuses of different POIs and other location-based information, the Maps Service needs

to be provided with the respective data by the city node services airports and the POINT-

Module of the Intermodal Landside Router in which the landside PIOs are bundled. To

provide the frontends with the required images, the Maps Service needs to receive the

information by the end-user applications as part of the request which POIs and layers

should be included in the images.


The Maps Service consists of four different functionalities which will be des cribed in this

subchapter. The first functionality is to integrate the airport-related indoor POIs. This is

done by receiving the respective information by the airports service which is part of the

city nodes. The airports service provides the locations of the integrated airport POIs as

well as their status, if applicable (e. g. elevators, doors etc.). Over the change status

management as described in D3.2 only the changes are updated. The same approach

applies for the second functionality, which is to integrate landside POIs. This is done by

the Maps Service requesting the landside transport related POIs from the POINT module

of the Intermodal Landside Router in which the POIs are bundled and available. The third

functionality is to cache the POIs in order to store them temporarily for the downstream

processes. The caching includes both the indoor as well as the landside POIs. The fourth

and most important functionality is to provide the images to the DORA frontends. This

functionality includes the actual rendering of the images in WMS and TMS standards as

well as the delivery of these images according to the request by the end -user

applications.


36 / 78

Figure 17: Functionalities of the Maps Service

In the following figure the functionalities of the central Maps Service are illustrated by

indicating which internal and external components they require and which technical

requirements need to be taken into account for the implementation.

Figure 18: Overview on Functionalities of the Maps Service


37 / 78

3.3.3 Internal View and Modules

The central Maps Service consists of four internal modules that provide the above

mentioned functionalities.

Cache for POIs

This internal cache stores the POIs which are necessary for rendering th e images to be

provided. After receiving the POIs are their statuses from the airports service and POINT

module of the ILR, the POIs are cached for the following rendering process. If the Maps

service receives the request to provide an image, the service c an take the required POI

information from the internal cache.

Maps Core Module

This module represents the central piece of software in the Maps Service. The core

module processes the requests received by the DORA frontends. Based on the requests it

decides which images have to be rendered. The core module subsequently requests POI

information from the cache and decides if the WMS or the TMS module should start the

rendering process with which map material and with which exact information to be

included.

WMS Module

Web Map Service is an OGC standard and provides a simple HTTP interface for requesting

geo-registered map images from one or more distributed geospatial databases. A WMS

request defines the geographic layer(s) and area of interest to be processed. The

response to the request is one or more geo-registered map images (returned as JPEG,

PNG, etc.) that can be displayed in a browser application. The interface also supports the

ability to specify whether the returned images should be transparent so that layers from

multiple servers can be combined or not. WMS delivers one image per request. The Maps

Core Module decides if the WMS or the TMS Module should render the required image

depending on which is more suitable for a given situation.

TMS Module

The TMS Module fulfils the same role as the WMS Module but uses the TMS standard.

The TMS delivers tiles. Main advantage of tiles is that they can be pre -rendered on the

server side, and cached on the client side. This will reduce waiting time for the data and

bandwidth.

The diagram below shows the different internal modules of the Maps service, their


38 / 78

interdependencies and connections to external components.

Figure 19: Maps Service – internal view and interdependencies

3.3.4 Sequence Diagrams of Service Procedures

In this subchapter the four functionalities of the Maps Service are illustrated with

sequence diagrams

The first functionality is to integrate the indoor POIs into the Maps service. For this

purpose the Maps Core Module initially requests the POIs from the airports service. Once

integrated the POIs, the further integration process works over the status change

management system. The airports service alerts the Maps Core Module that updates on

the POIs are available. The Maps Core Module subsequently requests the updates and

receives the updated POIs from the airports service.


39 / 78

Figure 20: Integrate indoor POIs – Sequence Diagram

The second functionality is the integration of landside POIs which works similar ly as for

the indoor POIs.

Figure 21: Integrate landside POIs – Sequence Diagram


40 / 78

The third functionality is the caching of the received POIs for following processes of the

Maps Service. The Maps Core Module receives the POIs and their updates by the POINT

Module and the airports service. These POIs are forwarded to the cache of the Maps

Service where they are kept available for the following image rendering processes as

background information.

Figure 22: Cache indoor and landside POIs – Sequence Diagram

The fourth and central functionality is the provision of rendered images to the DORA

frontends. The sequence is started by one of the DORA frontends which requests the

images from the Maps Core Module. Based on the image request the Maps Core Module

requests in turn the current POI information from the cache of the Maps Service. The

Core Module then decides if the image should be rendered in WMS or TMS standard. The

Core Module initiates the rendering process by sending a corresponding request with

information on POIs to be included, map material to be chosen, image sizes or geographic

information such as boundary boxes to either the WMS or the TMS module. The rendered

images are finally sent directly by these modules to frontend which started the process.


41 / 78

Figure 23: Provide images to frontends – Sequence Diagram

3.4 Trip Monitoring


The Trip Monitoring Service (TMS) is the central service for supervising a rout e selected

by a DORA user. The TMS receives the route selected from the DORA Smartphone

Application and stores it in a database. The main functionality of the TMS is to regularly

validate the selected trip against the connected DORA routing services based on real-time

data. If there are any deviations from the monitored trip the TMS either updates the trip

information or alerts the user that his selected connection is no longer suitable for

arriving at the airport or the final destination on time and a rerouting is needed. This

validation process takes place both before the trip has started as well as during the actual

execution of the trip. The different functionalities and service procedures of the TMS are

illustrated and specified in the following subchapters.


42 / 78


The Trip Monitoring Service contains four different main functionalities that will be

described at this point. The two main functionalities are the actual monitoring of the

selected route carried out in two different ways. The first monitoring functionality is

applied when the trip has not started yet. Even a few days before the trip starts a user

can receive updated trip information for instance if a terminal changes or the check -in

counter information is available. For this use case the Trip Monitoring Service validates

the route to be monitored by requesting routes from the connected routing services

(Intermodal Landside Router, Indoor Routing Service, and Flight Routing Service) based on

the initial input parameters of the monitored trip. This validation process is repeated in

large intervals (e. g. one validation per two hours, or in slightly shorter intervals when the

start of the trip gets closer). The routes are then being compared to the trip to be

monitored. If there are updates for any part of the overall trip, this information is sent to

the smartphone app (see sequence diagrams in 3.4.4). The second and very similar

functionality is the monitoring of a selected trip which has already started. The only

difference to the previous mentioned functionality is the interval of the validation

process. For trips already started the interval will be much shorter since the user needs to

know promptly if an incident or a delay affects his chosen and currently performed route.

The third functionality is to update the trip information of the monitored route when

applicable. The trip information is updated if there are delays or changes in the

monitored trip but the overall connection is still suitable for arriving at the airport or the

final destination in an acceptable timeframe. The route updates are sent to the

smartphone application. The last functionality is to trigger a rerouting. This applies for

the cases when the chosen route is affected by a delay or an incident which critically

endangers the timely arrival at the airport and an alternative route is necessary. In this

case the TMS alerts the Smartphone app via Push notification.

Figure 24: Functionalities of the Trip Monitoring Service


43 / 78

In the following diagram the functionalities are listed including their interdependencies.

Furthermore, for each of the functionalities the involved internal modules, external

system components and applicable technical requirements are listed.

Figure 25: Overview on functionalities of the Trip Monitoring Service


The Trip Monitoring Service consists of the following internal modules which will be

described below.

TMS Database

The Trip Monitoring Service contains a database where the trips to be monitored are

centrally stored. After the trip to be monitored is sent by the smartphone app to the Trip

Monitoring Service it is initially added to the database. The TMS Core Module, responsible

for the actual supervision of the trip, has access to this REST database and receives the

different routes for the further processing.


44 / 78

TMS Core Module

The TMS Core Module is the central module containing the monitoring functions of the

TMS. It is connected to the TMS database from which it receives the routes to be

supervised. The TMS Core Module is on the other side connected to the central services

Intermodal Landside Router, Indoor Routing Service and Flight Routing Service. The TMS

Core Module validates the monitored trip by requesting partial routes from the named

routing services and comparing those to the saved trip information. This validation

process is illustrated in more detail in the following sequence diagrams of this chapter.

TMS Messaging Module

The Messaging Module is responsible for sending updated trip information or Push

notifications to the smartphone app if applicable. This happens if the TMS Core Module

detects any deviations from the monitored trip plan. If there are critical delays or

disruptions affecting the overall connection to the airport, the TMS Messaging Module

informs the smartphone app via push notification and can trigger a rerouting. Push

notifications are also sent if important information has been updated, e.g. gate or check -

in-counter changes.

The Trip Monitoring Service and its intermodal modules as well as their connections to

external components are illustrated in the following diagram.


45 / 78

Figure 26: Trip Monitoring Service – Internal view and interdependencies


The four mentioned functionalities of the Trip Monitoring Service are described in more

detail in the following sequence diagrams explaining how the different components

communicate with each other in chronological order and which data is exchanged.

The first functionality described here is the monitoring of a trip that has not started yet.

To start the monitoring process the trip that the user has selected for monitoring is sent

from the smartphone to the TMS database from which it is being forwarded to the TMS

Core Module. The TMS Core Module starts the monitoring of the trip by requesting the

parts of the overall trip chain from the different routing services based on the input

parameters with which the user requested his initial door to door route. The TMS Core

Module compares the received routes with the route to be monitored. If the connection

is still valid and no changes or problems have occurred for this particular trip, no further

action is needed. This validation process, requesting routes and comparing it against the

trip to be supervised, is repeated in time intervals still to be defined. Since the route has

not started it is not necessary to loop this validation process as often as necessary for

routes which have already started.


46 / 78

Figure 27: Monitor a not yet started trip – Sequence Diagram

The sequence of monitoring a trip which has already started follows the same approach

as for the previous functionality. The only difference is the t ime interval in which the

described validation process is repeated. For already started a much shorter time interval

is needed in order to inform the user about any deviations or incidents as early as

possible and trigger a rerouting if necessary. A possible time interval for the validation

loop could be every 5 minutes. After the user has reached the airport according to his

monitored trip plan, the Intermodal Landside Router for his departure will no longer be

requested for validation but only the Indoor Routing Service for the departure airport and

the Flight Routing Service.


47 / 78

Figure 28: Monitor an already started trip – Sequence Diagram.

The third functionality of the Trip Monitoring Service is to update the trip currently

monitored based on real-time data. If during the validation process updates for the

monitored route are detected, this information will be sent to the smartphone app so

that the user will be informed about any delays or changes. This functionality comes into

operation if there are updates for the monitored route which are not critical in terms of

making it impossible for the DORA user to arrive at the airport on time. This could be a

delay in the public transport system or road congestion which don´t affect t he overall

timely arrival. In this case the updated trip information is sent from the Trip Monitoring

Service, more precisely the TMS Messaging Module, to the smartphone application. If

there is important information such as a flight delay, or a newly avai lable gate- or check-

in-counter-number, this info will be additionally sent via push notification to the DORA

user.


48 / 78

Figure 29: Update Trip Information – Sequence Diagram

The fourth functionality of the Trip Monitoring Service is to trigger a rerouting. If the

validation process detects that the chosen and monitored connection is affected in a way

that the passenger cannot arrive on time at the airport in order to catch his or her flight

(maximus arrival time before flight departs still has to be defined), a rerouting is

triggered. In this case the TMS Core Module notifies the TMS Messaging Module that a

rerouting is needed. The TMS Messaging Module sends a push notification to the user

that he or she should start a rerouting in the app.


49 / 78

Figure 30: Trigger a rerouting – Sequence Diagram

3.5 Flight Information Service


The Flight Information Service is a Central Service providing real time information (as it

can be the timetables and delays) and the expected one (as the status of the flights, their

tracking and any incident).


The Flight Information Service provides different kind of interesting information about all

the things that surround a flight. First of all it provides expected information as the

schedule of the flights and the expected delays.

For the scheduled information it will offer a simple lookup service that delivers

information on direct flights between and origin and destination. Due to all the flights are

not direct, for the connections it will offer a more robust service that delivers information

on both direct flights as well as connecting flight options between the origin and

destination.

About the expected delays, the service will provide some predicted information with a


50 / 78

reasonable level of confidence which can be very valuable, for example for visualizing the

air traffic system in advance of actual flights, understanding the impact of flight networks

on ground transportation networks, and optimizing revenue and reducing costs during

times of disruption.

Figure 31: Functionalities of the Flight Information Service

For the real time information, the Flight Information Service will provide the expected

information as it can be the status of the flights, the current position of each one, and

any incident that happens.

The status of the flights includes scheduled, estimated and actual departure/arrival

times, equipment type, delay calculations, terminal, gate, and baggage carousel. The

positional information allows to track flights by flight number or by airport, providing the

current position of flights, along with altitude, speed, course, and other details including

flight plan waypoints, irregular operations information, and status details. Flight Alerts

will monitor a single flight segment and pushes alerts when the status changes.


51 / 78

Figure 32: Overview on functionalities of the Flight Information Service


The Flight Information Service will be composed by two main modules, one providing the

expected information, and a second module informing of the current situation of the

flights. This second module will provide feedback to the Trip Monitoring Service Module.

Expected Information Module

The expected information that the system will provide are the schedules of the flights,

the connections among flights, and delays on them according with some predictions

done.

The schedules offers information on future scheduled flights f iltering the information by

the carrier and flight number, the departing or arriving date and/or airport.

The connections among flights are useful when the trip involves more than one flight and

it is needed to know the time between flights of the same trip. In this case the system will

provide direct flights if they exist, or the connecting flights if not. For that specific

information it can be ordered based on the selected preference, which can be "First Flight

In" or "Last Flight Out".

Delays will provide the expected delay on affected flights by an already known delay that

involves some others, or because of external reasons as it can be the expected weather.

Current Information Module

The current information that will be offered will be real information about the current


52 / 78

status of each flight informing about if the flight is on time, how long is the delay, if it has

been cancelled, the departures or arrival gates and terminal, and the type of plane used

on that flight.

It will also provide a real time tracking information, which consists of positional

information and updates needed to create flight tracking application s and answers

questions such as what is the planned flight for a specific flight, where is the flight now,

here has it been up to now, offering data such as position (lat/long), previous positions,

altitude, bearing, speed and route.

It also will alert of flight status information. Alerts are based on flight segments and can

be triggered on a variety of conditions and status changes. The service will allows to

create, retrieve, and delete Alert rules.

Figure 33: Flight Information Service – Internal view and interdependencies


The six mentioned modules of the Flight information Service are described in more detail

in the following sequence diagrams explaining how the different components

communicate with each other in chronological order and which data is exchanged.


53 / 78

The first of the modules is the one offering the list of available flights, for departures and

arrivals, filtering for date, flight number and route.

Figure 34: Scheduled information about flights– Sequence Diagram

The other modules related with the timetables of the flights is the one used when the trip

involves more than one flight, so the user can have a sequence of flights according with

some criteria. The system will offer the user four manners of checking flights depending

of their arrival time or departure time. That means they can search flight with these

criteria:

Flights that arrive as soon as possible before a given date

Flights that leave as soon as possible before a given date

Flights that arrive as close as possible to the given date

Flights that leave as late as possible before a given date

The system will return to the user a list of flights, quantity that can be configured on the

request.


54 / 78

Figure 35: Connection among Flights – Sequence Diagram

The other group of modules, the one offering actual information, can be joined on a

single diagram. Current status of a flight, tracking, and incidents are information about

the flights, so the flight itself can provide that information.

The status of the Flight can be requested because the user wants to know it, or because

the system is checking if it has suffer any change, and if that change affects the trip, then

the Trip Monitoring Service must be warned.

The position of the Flight is requested under demand of the user. If its current position

can affect the planned trip, then the incident detection module will be triggered with that

incident and the Trip Monitoring Service module will be warned.


55 / 78

Figure 36: Real time flight information– Sequence Diagram


56 / 78

3.6 Indoor Location


The Indoor Location Service is a central service aimed to be used by Smartphone

Application libraries in order to resolve the indoor location of the user based on the Wi-Fi

and/or BLE RSSI measurements but also to assist for georeferencing purposes, especially

for the proper transition from outdoors to indoors where the means for user location

calculation have to switch from GPS to Beacon based methods. There will be one instance

of the service accessible by the Dora Application via the API Gateway. The main task of

the service is to process information provided by the user according to the implemented

location algorithms and in comparison against the content of the fingerprinting database

for the as much as possible accurate resolution of the user location so that this

information can be used in the context of other application features and service

functionalities.


The Indoor Location service is a simple service that is normally used as a lookup endpoint

for the proper resolution of the user location. It is not, therefore, decomposed into

several functionalities and it is not interacting with other services in the context of any

complex processing scenario. Two separate main functionalities have been defined. The

first service functionality is the Location Calculation during runtime which is invoked and

consumed by the DORA Smartphone Application whenever adequate Wi-Fi or BLE Beacon

Data have been collected and need to be processed for updating the user location in the

Application runtime so that it can be used for the purposes of navigation, route re -

calculation, alerts, etc. The second functionality is the Fingerprinting Database

Maintenance and regards the population of the database with RSSI measurement data

for buildings where indoor location calculation can be offered. This functionality is used

whenever a new building or indoor infrastructure should be covered by Indoor Location

Service.

Figure 37: Functionalities of the Indoor Location Service

Fingerprinting Data

Maintenance

Calculate Location


57 / 78

In the figure below the named functionalities of the Indoor Location Service are

presented in an Enterprise Architect diagram showing the connection of each

functionality to involved internal components, use cases and technical requirements that

need to be taken into account.

Figure 38: Functionalities of the Indoor Location Service


The Indoor Location service contains three internal modules that are presented in the

following paragraphs.

Fingerprinting DB

This is the database holding all the RSSI measurements and related location information

that are required for the algorithms to properly calculate the current user location based

on the RSSI measurements and Beacon identifiers (MAC addresses and UUIDs) that the

user equipment is currently reporting. The Fingerprinting DB is storing items of data (RSSI

measurements, MAC addresses and location coordinates, among others) collected when

an indoor infrastructure is to be integrated under the DORA Indoor Location Service.

Algorithms Module

This module contains the implementation of the positioning algorithms that have to be

applied over the user reported data and the related stored information in order to


58 / 78

produce an as much as possible accurate estimation of the user indoor position. The

position of the user can be used for display purposes but also for triggering further

processing in the overall DORA application context.

REST Module

The REST module implements the API functionality through which both administrative

tasks and user service requests can be submitted.

Figure 39: Indoor Location Service– internal view and interdependencies


59 / 78


The sequence diagrams for the two functionalities of the Indoor Location Service are

presented in this paragraph.

Regarding the Calculate Location functionality, the first step in initiated by the user (client

library) as it has to collect RSSI measurements (and additionally, store the last location).

After that, this information is sent the REST Module, acting as interface for the Algorithms

Module. This module performs the calculation based on the input provided by the user

(client library) on the one hand and the data available in the Fingerprinting database on

the other hand. The estimation is then returned to the user.

Figure 40: Calculate Location - Sequence Diagram

Regarding the FPD Maintenance functionality three main primitives apply:

Add or register a place, which typically relates to an airport. This includes general

information about the zone (airport), involved buildings and floors.

Insert measured data on each point of the FP grid. This is done floor by floor, and

even including some outdoor areas

Update FP data. This is typically done if a beacon is not working any longer. When

a new beacon is added to an existing place, FP data can be included in the

database either via an insert primitive or an update primitive.


60 / 78

Figure 41: Fingerprinting Database Maintenance - Sequence Diagram

3.7 Waiting Time Detection


The Waiting Time Detection service is a central service providing real-time information on

the queues covered by the DORA project and forecast. Real-time information is based on

image analysis and forecast is a mix of real-time information and historical and other data

provided by the airports.


The Waiting Time Detection service provides information about the measured time in the

queues and the forecasted waiting time in the queues.


61 / 78

The Real-Time waiting time is the current waiting time in a given queue, with a degree of

confidence that can be valuable to the overall DORA service as queue time can be

growing or diminishing, light conditions unfavorable, etc. When a queue waiting time

calculation grows unexpectedly, incident reporting will also be performed.

The expected waiting time is the forecasted information in a given queue, obtained either

by compounding the measured waiting time and the forecasted waiting time queues for

short term forecasts (i.e. within the coming hour(s)) or by providing expected waiting

time on a historical data, when forecast request is not short term.

Figure 42: Functionalities of the Waiting Time Service


The Waiting Time Detection service will be composed of four main modules, aggregated

in a single API. The frequency of results updates will be defined, to avoid unnecessary

changes.

The main module is to calculate Real Time waiting time in a given queue and to provide

the current waiting time of a given queue, the second module is to provide the expected

waiting time of a given queue, by comparing the real-time information with the historical

information and the forecasted time of the arrival at the entrance of queue. When the

forecast will be above a few hours, it is expected we rely mainly on the historical

information, rather than the real-time measurement.

Real-time waiting time

Depending on camera placement and airport constraints (i.e. cameras are able to face

queue entrances and exits or not) we have two possible ways to perform waiting time

detection.

- Image recognition based waiting time

This type of waiting time is performed when the cameras are able to face queue

entrances and exits. Overall there is good degree of confidence in the obtained

results, except when queues are mixed (i.e. when users enter and exit through the


62 / 78

same camera but proceed at very different speed).

- Zone detection based waiting time

Zone detection waiting time is performed by analyzing the queue as a whole, and

the person occupancy in a given area. This type of waiting time is performed when

cameras are placed on the ceiling and do not face queue entrances or exits. The

degree of confidence in the obtained results is lower, especially if no counter

status information is provided, and/or if no entrance and exit zones are clearly

defined, and/or camera placement is above a highly reconfigurable queue.

- External waiting time information

To ensure consistency of the information, we will aggregate external waiting time

information, when relevant to the project and when it can be provided by the

airport. (i.e. this information may be needed for the project, while Dora camera

placement is not possible for logistic or security reasons).

The Real-Time waiting time will then be calculated by compounding the above

information, when available.

Expected waiting time according to current information

In this module, we will compound data issued from real-time waiting time, historical data

and external airport data.

The information is compounded mainly for the coming hour(s), when the Real Time

Waiting Time information is relevant to the forecast.

It is also to be noted that the discrepancy increase between real-time and historical data,

may decrease the level of confidence of the information given and then generate real -

time incident reporting.

Incident reporting (Real-Time)

The only type of incident reporting the Waiting Time Service is able to perform is real -

time. It occurs when the when current waiting time is abnormal by a multiplication factor

between historical data an current waiting time. Real-time incident reporting will be

added to queries, even if query forecast is in the future (i.e. there is an ongoing incident

on queue x, but waiting time of queue x by tomorrow is y minutes).


63 / 78

3.7.4 Sequence Diagram of service procedures

The sequence diagram for the Waiting Time Service is presented in this paragraph.

Regarding the Waiting Time Service, the first step in initiated by a Waiting Time Request

giving the expected date and time of Waiting Time calculation.

It is to be noted that if the waiting time information requested is real -time, the historical

and external information will only influence the degree of confidence of the information

provided, if the information requested is in the future by more than a few hours, the

information will mainly rely on the historical data. The estimation can then be returned to

the user.

Figure 43: Waiting Time - Sequence Diagram

The Real-Time Waiting Time calculation is then detailed in the following sequence

diagram:


64 / 78

Figure 44: Real-Time Waiting Time - Sequence Diagram

Regarding the Real Time Waiting Time Service, the first steps are to get real-time Waiting

Time information that can be provided by various services (when available: Image

recognition, Zone detection and other external information). This information is then

compounded to return a real-time Waiting Time value and a degree of reliability of the

data.

3.8 Indoor Navigation

The indoor navigation service is very similar to the Indoor Routing Service, thus it is

unnecessary to repeat the same description process and figures. Instead, it is more

relevant to highlight the (small) differences between them:

The offline route is invoked when the user plans to make a journey, several days

(maybe weeks) beforehand, whereas online navigation is performed in real time.

Thus the accuracy of the calculation is expected to be better with o nline

navigation, as real time values are more reliable than mean values from a

simplified model.

Offline Route is not directly invoked by the user, but by the D2D Journey Planner


65 / 78

through the Open Service API of the API Gateway. On the other hand, the Onli ne

Navigation is invoked by the mobile app (navigation library) through the Open

Application API of the API Gateway.

The Navigation Library for online navigation also uses the Location service in order

to track the user and monitor if the traveler is following correctly the path or is

getting lost. Note that for Offline Routing, there is no need to contact the Location

Service.

Airport data regarding the status of some infrastructure nodes (e.g. lifts, stairs,

etc.) might be available in real time for online navigation, but not for offline

routing (e.g. it is not possible to predict if a lift is out of order). In the same way,

information of additional waiting times (besides security checks) might be added

(e.g. at the desk counters).

The online navigation might potentially use a geocoding service in order to better

map specific nodes (geographical coordinates) with user-friendly Points of Interest

(POIs). Note that a geocoding service applies also for outdoor routes (e.g. a street

name or an address maps to a geographical coordinate)

All previous implications can be visible in the component diagram already depicted for

Indoor Routing. In the case of the sequence diagram (see figure below) there are some

small remarks compared to (offline) Indoor Routing:

The user profile treatment remains intact in both services. With every request, the

user profile affects the resulting navigation graph.

The Waiting Time and Airport Data Elements perform periodical updates (e.g.

every 5 minutes) in order to avoid changes/updates on a per user request. This

scales better and minimizes unnecessary traffic among components. Note that the

Waiting Time Service may update every 10 minutes and the Airport Data Services

(if any) might be updated each 5 minutes.


66 / 78

Figure 45: Indoor Navigation - Sequence diagram

3.9 D2D Journey Planner


The Door to Door Journey Planner is one of the core services in the DORA system since it

combines the routes provided by the different routing subservices to overall door to door

route recommendations. For the calculation of the overall route the Door-to-Door

Journey Planner integrates the three routers for the intermodal landside part, the indoor

part and the flight part of the trip. The Door to Door Journey Planner needs to be able to

process all routing parameters selectable in the end-user applications and pass these on

towards the connected routing subservices. The combined door to door route


67 / 78

recommendations are finally sent back to the DORA frontends.


The Door to Door Journey Planner contains one core functionality and two subordinate

functionalities. The core functionality is the actual combination of the intermodal

landside route, the indoor route and the flight route to the ove rall door to door

connection. For this calculation of door to door routes the D2D Journey Planner needs to

consider the different input parameters of the routing request which consist, among

others, of start and arrival time, departure and arrival locations, preferred transport

modes, mobility constraints, etc. Based on these parameters the D2D Journey Planner

calculates different trip recommendations based on the partial routes received from the

routing subordinate routing services and provides the most suitable ones to the end-user

applications. How many routes are suggested to the user is defined by the end -user

applications. The second functionality is to cache the user profile of a route request

which form the personal mobility input parameters as for example mobility constraints,

availability of a public transport season ticket, need for luggage check in etc. The third

functionality is to cache the trip input parameters such as arrival time, starting

destination, transport modes to be considered etc. Both these parameters which are

transmitted as part of the routing request are cached in order to be able to repeat any

routing request towards the subordinate routing services in case it is necessary.

Figure 46: Functionalities of the Door to Door Journey Planner

As in the previous chapters the three functionalities of the D2D Journey Planner are listed

including information on which technical requirements have to be considered and which

internal modules and external components are involved.


68 / 78

Figure 47: Overview on Functionalities of the Door to Door Journey Planner


The Door to Door Journey Planner consists of three different internal modules which are

necessary to provide the described functionalities of this service: The D2D Core Module, a

cache for the user profile and a cache for the different trip input parameters.

Cache for User Profile

This internal cache has the purpose of extracting the input parameters regarding the

personal mobility settings from the incoming door to door routing request and storing

these parameters in case a routing process has to be re-initiated. These input parameters

include personal mobility constraints such as inability to walk long distances or us e stairs,

availability of public transport season tickets, preferred modes of transport, preferred

buffer time at the airport, need to check-in luggage etc.


69 / 78

Cache for trip input parameters

This cache stores the remaining input parameters of a routing request with the same

purpose as the user profile cache. The trip input parameters cover all basic and not

directly personal routing parameters such as departure and destination addresses,

departure and arrival time, transport modes to be considered, available flight number etc.

D2D Core Module

This module is responsible for the main functionality of the Door to Door Journey Planner,

which is the calculation of the overall door to door route. Based on the routing request

received from a DORA end-user application, the Door to Door Journey Planner in turn

requests the partial routes from the subordinate routing services and combines the

results to overall trip recommendations. This sequence will be illustrated in more detail in

the following chapter.

The diagram below shows the internal modules of the Door to Door Journey Planner, how

they interact which each other and with which other DORA components they

communicate in order to provide the overall door to door route recommendations.

Figure 48: Door to Door Journey Planner – internal view and interdependencies


70 / 78

3.9.4 Sequence Diagrams of Service Procedures

In this subchapter the three functionalities of the service are illustrated with sequence

diagrams as for the services in the previous chapters.

The main functionality – the calculation of the door to door route – is illustrated below.

The Smartphone Application sends the routing request initiated by the DORA user to the

D2D Journey Planner and more precisely to the D2D Core Module. This rout ing request

contains all input parameters set by the user. The D2D Core Module first requests a

suitable flight connection in case the user has not preselected an already booked flight.

Based on the flight details received the D2D Core Module then requests suitable indoor

routes and landside routes from the Indoor Routing Service and the Intermodal Landside

Router. The three routing results from the mentioned subordinated routing services are

finally combined to different door to door route suggestions which are sent back to the

DORA frontends in a response.

Figure 49: Calculation of Door to Door Route – Sequence Diagram

The second functionality is the caching of the user profile. Parallel to requesting the


71 / 78

indoor, flight and landside routes, the D2D Core Module forwards the user profile input

parameters to the dedicated cache. The specific input parameters are temporarily stored

in case an unexpected problem occurs during the door to door route calculation process.

In this case the D2D Core Module can request the cache for the user profile parameters in

order to reactivate the routing procedure (Figure 50).

The same procedure applies for caching the trip input parameters which are temporar ily

stored separately (Figure 51).

Figure 50: Cache the User Profile – Sequence Diagram


72 / 78

Figure 51: Cache the Trip Input Parameters – Sequence Diagram


73 / 78

4 SPECIFICATION OF CITY NODES SERVICES

4.1 Overview on City Node Services in City Node Berlin and

Palma

Please refer to previous section 2.2.2 of this document to have an overview on the City

Node Services for both pilot sites in DORA: Berlin and Palma de Mallorca.

In the below sections, the named City Node Services are going to be described following

the methodology advanced in section 2.3.

4.2 Departures

This service will provide the list of departures for Public Transport (coach, train or urban),

and Flights in general. For requesting them the most common is to provide the latitude

and longitude of a point and the radius covered by that area, so all departures under it

will be retrieved. The other way to retrieve them is providing just the bounding box.

For more information check the developer’s API here.

It covers DORA requirements: FIS_001, FIS_002, FIS_003 and FIS_006.

4.3 Arrivals

This service will provide the list of arrivals for Public Transport (coach, train or urban), and

Flights in general. For requesting them the most common is to provide the latitude and

longitude of a point and the radius covered by that area, so all arrivals under it will be

retrieved. The other way to retrieve them is providing just the bounding box.


It covers DORA requirements: FIS_001, FIS_002, FIS_003 and FIS_006.

4.4 Carsharing

These services will cover the most common operations about carsharing. Information

about the different operators, about each one of the existing carsharing stations, and

about the cars themselves.

As it can be expected, operations for handling the bookings are also available, operations

like booking a car, cancel a booking, or getting the information about it.


74 / 78


It covers DORA requirements: APP_011.

4.5 Geocoding

These three operations will provide the coordinates of a given place, or the name of the

place that fits the coordinates, depending if the provided entry are coordinates or a place.


It covers DORA requirements: APP_009, APP_010, IR_002.

4.6 Bikesharing

These services will cover the most common operations about bikesharing. Information

about the different operators, about each one of the existing bikesharing stations, and

about the bikes themselves.


like booking a bike, cancel it, or getting the information about it.


It covers DORA requirements: ILR_001, ILR_002.

4.7 Parking

These services will cover the most common operations about parking. Information about

the different operators, about each one of the existing carparks and about the spaces

available.


like booking or cancelling a place, or getting information about them.


It covers DORA requirements: ILR_002.


75 / 78

4.8 Airports

In addition with the list of available airports, these services will offer functionalities for

almost all important POIs that can be found inside an airport as it can be: baggage claims,

the different buildings of the airport, elevators, entrances, escalators, gates, mobility

impaired, restaurants, security checks, shops, waiting time, and the stations for hired

busses to move people from the airport to some critical points of the city (shuttle busses).

Also it will offer relevant information for physical people as the travellers and the

personal assists of the airport; and the most relevant coupons related with that airport

and everything inside it.


It covers DORA requirements: ILR_002.

4.9 Electric Vehicle Charging

This services will provide information about the different operators providing charging

infrastructure. It will also offer information on each operator, their charging stations, and

the respective dispensers available.

As expected, this service will also offer methods for booking operations.


4.10Incidents

This API will offer the services for listing the different incidents about accessibility,

regarding indoor, public transport and on the streets.


It covers DORA requirements: APP_006, SWA_004, ILR_003, MIM_003, MIM_005,

MIM_006, MIM_008, MIM_009, MIM_010, MIM_011, TMS_003, TMS_004, TM S_005,

TMS_006, TMS_008, TMS_009

4.11Public Transport

This API grants operations for being able to check stations, operators and public transport

networks in the respective city. It also provides operations for handling the tickets

needed for using this kind of transport.


76 / 78


It covers DORA requirements: APP_012, ILR_001, MIM_007

4.12Taxi

This API only provides services for checking taxi stations in a city and a list of the vehicles.


It covers DORA requirements: MIM_007

4.13Weather

The two operations of this service provide information of the current weather and a

forecast for the next few days.


4.14Routing

This API provides information about the different routing proposals and different routers.

It offers modal routing results which are used by the Intermodal Landside Router and,

subsequently, the Door to Door Journey Planner.


It covers DORA requirements: APP_007, APP_008, DJP_001 to DJP_006, IP_004, ILR_001

to ILR_009

4.15Waiting Time

The waiting time API will provide information about waiting time location based objects.

4.16Rental

This API will provide the basic information about Rental services such as the list of car

rentals and the availability of their vehicles.



77 / 78

4.17Fuel Stations

This API will provide very basic information about the nearest Fuel Stations. The basic

information needed for that is the exact location of the Fuel Station and the operator.


78 / 78

5 CONCLUSIONS

This deliverable concretizes the new services for the two pilot sites to be integrated in the

overall DORA system. This is a key input for the subsequent WP4 Software Development

and Integration, as it will pave the way for DORA software developments according to the

DORA Architecture provided in deliverable D3.2 DORA Architecture, where the overall

system was extensively explained.

In this deliverable, the DORA Central Services and the DORA City Node Services are

described, but with different levels of detail. The DORA Central Services have been widely

described (functionalities, internal modules, etc. and supported by Enterprise Architect

diagrams. Whereas the City Node Services are described in lower detail with reference to

the developer API, in order to shorten the extent of this document.

These specifications mean an important step towards the development of the DORA

system and are of crucial importance for the following deliverables in work package 4.

When specifying a particular service all architectural and communicational requirements

can, as a result, be taken into account from the very beginning and considered

accordingly.

door to door information for air passengers · 2016. 8. 1. · dora deliverable d3.3 3/ 78...

Documents