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
DORA Deliverable D3.3
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.
DORA Deliverable D3.3
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
DORA Deliverable D3.3
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.2.1 General Description ............................................................................................. 30
3.2.2 Functionalities Overview...................................................................................... 31
3.2.3 Internal view and modules ................................................................................... 32
3.2.4 Sequence Diagrams of service procedures ........................................................... 34
3.3 Maps Service....................................................................................................35
3.3.1 General Description ............................................................................................. 35
3.3.2 Functionalities Overview...................................................................................... 35
3.3.3 Internal View and Modules .................................................................................. 37
3.3.4 Sequence Diagrams of Service Procedures ........................................................... 38
3.4 Trip Monitoring................................................................................................ 41
DORA Deliverable D3.3
6 / 78
3.4.1 General Description ............................................................................................. 41
3.4.2 Functionalities Overview...................................................................................... 42
3.4.3 Internal View and Modules .................................................................................. 43
3.4.4 Sequence Diagrams of service procedures ........................................................... 45
3.5 Flight Information Service ................................................................................49
3.5.1 General Description ............................................................................................. 49
3.5.2 Functionalities Overview...................................................................................... 49
3.5.3 Internal View and Modules .................................................................................. 51
3.5.4 Sequence Diagrams of service procedures ........................................................... 52
3.6 Indoor Location................................................................................................ 56
3.6.1 General Description ............................................................................................. 56
3.6.2 Functionalities Overview...................................................................................... 56
3.6.3 Internal view and modules ................................................................................... 57
3.6.4 Sequence Diagrams of service procedures ........................................................... 59
3.7 Waiting Time Detection....................................................................................60
3.7.1 General Description ............................................................................................. 60
3.7.2 Functionalities Overview...................................................................................... 60
3.7.3 Internal View and Modules .................................................................................. 61
3.7.4 Sequence Diagram of service procedures............................................................. 63
3.8 Indoor Navigation ............................................................................................ 64
3.9 D2D Journey Planner........................................................................................ 66
3.9.1 General Description ............................................................................................. 66
3.9.2 Functionalities Overview...................................................................................... 67
3.9.3 Internal View and Modules .................................................................................. 68
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
DORA Deliverable D3.3
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
DORA Deliverable D3.3
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
DORA Deliverable D3.3
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
DORA Deliverable D3.3
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
DORA Deliverable D3.3
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
DORA Deliverable D3.3
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.
DORA Deliverable D3.3
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.
DORA Deliverable D3.3
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.
DORA Deliverable D3.3
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)
DORA Deliverable D3.3
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.
DORA Deliverable D3.3
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.
DORA Deliverable D3.3
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.
DORA Deliverable D3.3
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.
DORA Deliverable D3.3
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.
DORA Deliverable D3.3
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.
DORA Deliverable D3.3
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
DORA Deliverable D3.3
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
DORA Deliverable D3.3
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.
DORA Deliverable D3.3
25 / 78
Figure 8: Intermodal Landside Router – internal view and interdependencies
DORA Deliverable D3.3
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.
DORA Deliverable D3.3
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.
DORA Deliverable D3.3
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.
DORA Deliverable D3.3
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.
DORA Deliverable D3.3
30 / 78
Figure 12: Integration of Location Based Services – Sequence Diagram
3.2 Indoor Routing
3.2.1 General Description
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
DORA Deliverable D3.3
31 / 78
Routing and the Indoor Navigation are very similar services, as will be described.
3.2.2 Functionalities Overview
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.
DORA Deliverable D3.3
32 / 78
Figure 14: Functionalities of the Indoor Routing Service
3.2.3 Internal view and modules
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
DORA Deliverable D3.3
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
DORA Deliverable D3.3
34 / 78
3.2.4 Sequence Diagrams of service procedures
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
DORA Deliverable D3.3
35 / 78
3.3 Maps Service
3.3.1 General Description
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.
3.3.2 Functionalities Overview
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.
DORA Deliverable D3.3
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
DORA Deliverable D3.3
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
DORA Deliverable D3.3
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.
DORA Deliverable D3.3
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
DORA Deliverable D3.3
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.
DORA Deliverable D3.3
41 / 78
Figure 23: Provide images to frontends – Sequence Diagram
3.4 Trip Monitoring
3.4.1 General Description
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.
DORA Deliverable D3.3
42 / 78
3.4.2 Functionalities Overview
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
DORA Deliverable D3.3
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
3.4.3 Internal View and Modules
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.
DORA Deliverable D3.3
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.
DORA Deliverable D3.3
45 / 78
Figure 26: Trip Monitoring Service – Internal view and interdependencies
3.4.4 Sequence Diagrams of service procedures
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.
DORA Deliverable D3.3
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.
DORA Deliverable D3.3
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.
DORA Deliverable D3.3
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.
DORA Deliverable D3.3
49 / 78
Figure 30: Trigger a rerouting – Sequence Diagram
3.5 Flight Information Service
3.5.1 General Description
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).
3.5.2 Functionalities Overview
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
DORA Deliverable D3.3
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.
DORA Deliverable D3.3
51 / 78
Figure 32: Overview on functionalities of the Flight Information Service
3.5.3 Internal View and Modules
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
DORA Deliverable D3.3
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
3.5.4 Sequence Diagrams of service procedures
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.
DORA Deliverable D3.3
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.
DORA Deliverable D3.3
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.
DORA Deliverable D3.3
55 / 78
Figure 36: Real time flight information– Sequence Diagram
DORA Deliverable D3.3
56 / 78
3.6 Indoor Location
3.6.1 General Description
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.
3.6.2 Functionalities Overview
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
DORA Deliverable D3.3
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
3.6.3 Internal view and modules
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
DORA Deliverable D3.3
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
DORA Deliverable D3.3
59 / 78
3.6.4 Sequence Diagrams of service procedures
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.
DORA Deliverable D3.3
60 / 78
Figure 41: Fingerprinting Database Maintenance - Sequence Diagram
3.7 Waiting Time Detection
3.7.1 General Description
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.
3.7.2 Functionalities Overview
The Waiting Time Detection service provides information about the measured time in the
queues and the forecasted waiting time in the queues.
DORA Deliverable D3.3
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
3.7.3 Internal View and Modules
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
DORA Deliverable D3.3
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).
DORA Deliverable D3.3
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:
DORA Deliverable D3.3
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
DORA Deliverable D3.3
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.
DORA Deliverable D3.3
66 / 78
Figure 45: Indoor Navigation - Sequence diagram
3.9 D2D Journey Planner
3.9.1 General Description
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
DORA Deliverable D3.3
67 / 78
recommendations are finally sent back to the DORA frontends.
3.9.2 Functionalities Overview
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.
DORA Deliverable D3.3
68 / 78
Figure 47: Overview on Functionalities of the Door to Door Journey Planner
3.9.3 Internal View and Modules
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.
DORA Deliverable D3.3
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
DORA Deliverable D3.3
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
DORA Deliverable D3.3
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
DORA Deliverable D3.3
72 / 78
Figure 51: Cache the Trip Input Parameters – Sequence Diagram
DORA Deliverable D3.3
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.
For more information check the developer’s API here.
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.
DORA Deliverable D3.3
74 / 78
For more information check the developer’s API here.
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.
For more information check the developer’s API here.
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.
As it can be expected, operations for handling the bookings are also available, operations
like booking a bike, cancel it, or getting the information about it.
For more information check the developer’s API here.
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.
As it can be expected, operations for handling the bookings are also available, operations
like booking or cancelling a place, or getting information about them.
For more information check the developer’s API here.
It covers DORA requirements: ILR_002.
DORA Deliverable D3.3
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.
For more information check the developer’s API here.
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.
For more information check the developer’s API here.
4.10Incidents
This API will offer the services for listing the different incidents about accessibility,
regarding indoor, public transport and on the streets.
For more information check the developer’s API here.
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.
DORA Deliverable D3.3
76 / 78
For more information check the developer’s API here.
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.
For more information check the developer’s API here.
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.
For more information check the developer’s API here.
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.
For more information check the developer’s API here.
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.
For more information check the developer’s API here.
DORA Deliverable D3.3
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.
DORA Deliverable D3.3
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.