Available Public Deliverables

The goal of this deliverable is to give an insight to the current situation of mobility information solutions and analyse the market of door-to-door transport information services addressing air passengers. The outcomes of this document will inspire Task 2.3- Definition of Use Cases, and will be a required input in deliverable D.2.4- Technical and legal requirements. At the end, the global analysis of desk research findings, results of in-depth interviews with market experts, user surveys feedback and final conclusions of the SWOT analysis developed here, will later shape the DORA system requirements in a robust and well-structured way.

As a result of the SoA review, several existing mobility information services and technologies are already in place. However, current route planners lack many functions that will be developed and integrated within the DORA project, such as terminal processes, incident management, real-time traffic information, parking information at the terminal or user group specific information.

Existing techniques to analyse people count, queue length and waiting time have been reviewed and compared. As a result, in the DORA project, a video analysis system will be integrated in the airports to measure passenger’s behaviours and to deliver accurate and consistent data.

MORE Information:


This deliverable’s intention is to provide an overview of travel chains, mobility needs, mobility information needs and special requirements for people with physical impairment clustered into different groups of air travellers. Thus the deliverable will be an inventory of potential DORA user groups and their mobility behaviour and mobility information requirements and provide input information to specify DORA system and service.

The first part of the deliverable consists of a general introduction followed by the part describing the approach and methodology that was applied in preparing this deliverable.

The next (third) chapter contains an overview of existing approaches on how to identify and cluster different types of air passengers and people travelling to airports. This information is based on different criteria like travel motivation, social-demographic factors or transport mode preferences. This part also gives an overview about the travel motivations and passenger quantities of European air travellers.

In the third chapter are also included the results of the investigations of already defined travel chains, the respective mobility requirements, as well as descriptions of approaches and models to explain mobility behaviour that are influencing mode choices. This information is important to identify mobility options and the derived information needs for the journey to the airports of Berlin and Palma de Mallorca that are also described in this chapter. Both cities and their airports will be test sites of the developed DORA service later. For that reason a passenger survey has been carried out at both sites to validate and amend data regarding the socio-demographic, socio-economic and mode choice preferences of different air passenger mobility types.

Combining all three investigation products, carried out within the analytical part in chapter three of this deliverable of task 2.2, allowed to define the DORA user groups and their typical and possible travel chains. The user groups were divided in six user groups: four groups were defined for travelling for leisure purposes and two user groups for travelling for business purposes. Since mobility-impaired people have to be regarded in an inclusive way, persons with mobility impairments can belong to every traveller group. Following this approach special needs in regard to information and accessibility of mobility-impaired people have been formulated for each of the defined DORA traveller groups.

The results from the research carried out within DORA also show that even though possible travel alternatives are quite homogeneous for all of the groups, the information needs to vary since behavioural settings differ. Thus information requirements for mode choice processes are of different relevance to every potential user group. This also illustrates why these prerequisites are important basic information to define use cases and the design of the DORA service for the following work packages of the project.

MORE Information:

This deliverable D2.3 is the outcome of Task 2.3 Definition of Use Cases, whose aim is to define DORA scenarios and use cases that will lead to the DORA specifications. Therefore, the purpose of this document is to define the most relevant use cases in order to specify all the possibilities of the DORA system, to obtain a usable set of features for the development and to extract best scenarios to be deployed and demonstrated later on.

The outcomes of this deliverable will be a key input in deliverable D2.4 Technical and legal requirements, which consists of a report on the technical and legal issues to take into account for the development and integration of the components of DORA information system.

The document starts with the initial scenario descriptions, use case definition and purposes. The use case methodology here is adapted to the particular needs of the DORA purposes.

Next, a table with an overview of all the DORA use cases is presented, including the classification based in the DORA components. The relation of these use cases is shown at the use-case diagram.

Finally, the description of use cases is presented. Each use case is extensively developed using a specific template.
The document will end with a summary reflecting the main conclusions. The list of use cases intends to cover all the possible situations and functionalities that the DORA system will provide to the main users involved (passengers, operation centres) but once the system architecture and the services specifications will be defined in the forthcoming tasks, a realistic yet feasible selection of the use cases to be demonstrated might be taken into consideration.

MORE Information:

This deliverable D2.4 is the result of the requirement definition process in tasks 2.4 (Technical Requirement Analysis and Specification) and 2.5 (Legal and Regulatory Requirement Analysis and Specification). The objective of this report is to define all requirements that have to be taken into account for the upcoming specification activities in work package 3 (DORA Concept Specification).

The requirements are based on the use cases and use case scenarios defined in D2.3 and translate those into technical and legal framework conditions. The main outcome of this deliverable is a list of altogether 151 requirements (140 technical and 11 legal requirements) that were collected and coordinated with the help of the VOLERE requirement analysis tool. The VOLERE tool provides an iterative instrument to collect, validate and revise all requirements with the involvement of all developing partners. The different work stages of the VOLERE process were carried out between M4 and M9.

The definition of technical requirements shows that all partners have generally the same understanding of what each component has to perform and how different components interact with each other. However, different dependencies and conflicts between requirements as well as component-specific uncertainties could be identified. Based on the discussion supported by the VOLERE tool, these problems could be solved by clarifying or modifying certain requirements.

The legal requirement analysis mainly focuses on data protection topics as real-test users will be involved in the later stages of the project. Different data protection legislations on European and national level were analysed and translated into specific requirements that will be considered for the data protection concept of the project.
The main results of the mentioned tasks can be found in chapters 5 and 6 where the final and harmonised list of technical and legal requirements is presented.

MORE Information:

D3.1 Initial Specification of the DORA Architecture sets the starting point for the further specification of the DORA system. The document describes the methodological approach for the development of the DORA technologies and applications and provides a draft version of the overall architecture of the DORA system. The presented concept will be revised based on the finally defined use cases (D2.4), further elaborated and documented in D3.2.

The document summarizes the preceding technical discussions between the DORA partners. It outlines their joint view on the DORA system architecture and a methodological approach on how to realize the DORA system in its full complexity.

The DORA system will integrate services already existing in the test sites as well as new services that are going to be developed within the project. This is a particular challenge for the technical coordination of the project, as different development methods are required and have to be harmonized in an overall time plan. The results of the methodological discussions between the technical partners and the corresponding time line for the further specification and development activities are summarized in Chap. 2 of the document.

Due to the DORA scope to integrate the information services already available at the test sites a detailed status analysis of data, services and interfaces has been conducted for the Berlin cluster and the Palma de Mallorca cluster. The results and recommendations on what system components should be integrated in the cross-border DORA system is documented in Chap. 3.

Based on this a first draft of the DORA system architecture is depicted in Chap. 4. The overall system is described and the underlying services are initially described and the planned frontends of DORA system are outlined.

MORE Information:

This deliverable D3.2 DORA Architecture finalizes the task 3.1 on specifying the reference architecture, interfaces and data models. Taking up the previous work in this task started with deliverable D3.1, this report concludes the architecture and interfaces specification activities.

This deliverable illustrates that a wide range of different software tools have been used for specifying the architecture and publishing the interfaces. The main tools used are Enterprise Architecture for UML Modelling and architecture overviews and WSO2 as the API Gateway for DORA developers and third parties interested in accessing the DORA services.

Summarizing the final architecture specification it can be stated that a common data modelling and interface convention has been applied taking into account the previously defined architecture requirements of scalability and transferability. Furthermore the system architecture is illustrated in detail and checked against some of the main DORA use cases such as Trip Planning, Trip Monitoring, Indoor Positioning, Indoor Navigation or Ticketing.

To support the transferability of the DORA solution to other cities and airports, the DORA interfaces on the one hand support an easy integration of additional service and data providers into the DORA environment, and on the other hand provide interested third parties and their applications an easy access to the range of different central and city-node services. As a result of the specification of the interfaces including a detailed definition of the data model of each API function, a profound basis could be set for the following services and applications specification tasks and the subsequent development work.

MORE Information:

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.

MORE Information:

The present deliverable concludes the work carried out in task 3.3 on the specification of applications between months 9-14. It has been written in parallel to the specification of DORA services in deliverable 3.3 and represents the final report of work package 3.

This deliverable gives a detailed description on each application to be developed within DORA project. This is done with a comprehensive specification approach which defines the features that each application provides; each feature in turn consists of different so-called Functional Building Blocks which represent certain functionalities as part of a feature. The specification approach is concluded by providing different diagrams for each feature illustrating what processes happen inside the application and how the application interacts with other components in order to provide this particular feature. In addition the specification approach reflects the different use cases and requirements defined in tasks 2.3 and 2.4.

A total of 29 features and 110 Functional Building Blocks have been identified and described in this deliverable providing a comprehensive overview on what functions the applications have to include and how this will be achieved. By providing detailed sequence diagrams for each feature all required data and communication flows between the different applications and services are specified and agreed on. Graphical drafting of the UIs including wireframes and mock-ups will be done in WP4 and will be included in an agile manner in the realization of the applications. In summary it can be stated that with the results achieved in this deliverable all preconditions for the upcoming software and component development work are set.

MORE Information:

This report provides support for the exploitation and operation of the DORA solution by defining potential sustainable business and cooperation model options . D3.5 is the outcome of task 3.4. Establishment of Business and Cooperation models, the aim of which is to provide information regarding the selection criteria for DORA business model. The report describes business requirements and value elements of each key stakeholder involved to DORA platform and analyses their impact on the establishment of business and cooperation models. This includes the identification and analysis of potential benefits and sacrifices of the DORA systems within various stakeholder groups, other (external) restrictions and the interactions between the stakeholders as part of the ecosystem.

Platform-based ecosystems consist of networks of actors combining resources and capabilities to make business and as such are subject to certain idiosyncratic management challenges. Proactively responding to these common challenges requires making informed choices about ecosystem design, governance and health that also shape the business model options available. DORA is a mobility information integrator type of business within the MaaS (Mobility as a Service) provider tier of the value chain, where it creates value to the entire mobility ecosystem by exploiting, connecting and refining currently underutilized mobility information. However the benefits are distributed unequally across the platform participants leading to a need to employ business model structures that seek to align the costs borne and benefits enjoyed to a satisfactory degree. In changing established relative power structures on the mobility market and reshaping business models, the decision to join the platform is contingent on a number of business realities and restrictions that are discussed here as business requirements such as data security and effective contractual governance to mitigate risks of participation.

DORA can be exploited by utilizing multiple alternative and even complementary business models. We recommend an approach that combines three complementary business models operating on different time scales, value offerings and customer segment focuses. These are Technology licensing, API access and Platform integration. Some implications for exploitation, transferability and collaborative development of DORA are also provided.

MORE Information:

Deliverable 5.1 is the first release of the Implementation Plan for the pilots’ a rrangements before starting the DORA tests in Berlin and Palma de Mallorca and its outcomes will enable the forthcoming Task 5.3 “Pilot execution”.

At least 500 passengers departing or arriving to TXL and SXF and PMI airport will be the target users for the trials scheduled for one year duration. The DORA consortium has agreed an encouragement model to recruit them in order to ensure quality feedback on the use of the DORA Smartphone App during the trial period. Moreover, training activities have been forecasted for the potential DORA users.

This deliverable also describes the technical set-up in terms of hardware and software implementation to perform the project trials as specified.

D5.1 is the intermediate outcome of two tasks, namely Task 5.1 Technical set-up, and Task 5.2 Organizational and Operational set-up. The aim of this deliverable is to report on readiness to DORA pilot including technical set-up, organizational and operational aspects, both in Berlin and in Palma de Mallorca. Therefore, deliverable 5.1 is the first release of the Implementation Plan for the pilots’ arrangements before starting the DORA tests in Berlin
and Palma de Mallorca and its outcomes will enable the forthcoming Task 5 Pilot execution. The subsequent deliverable D5.2 Pilot implementation plan will be built on this document
and will update the description and timelines regarding the activities required to properly execute the trials.

Target users for the trials are, at least, 500 passengers departing or arriving to TXL and SXF and PMI airport. Trial period starts in June 2017 and will finish in May 2018, according to the schedule and the focus will be on testing the usage of the Smartphone App in three different phases, by means of several user questionnaires, even thought, the usage of the DORA web GUI and the Operation Center Application will be evaluated as well by other methods. The DORA Smartphone App will be available both, at Google Play Store (Android) and at Apple Store (Ios), for free download and several dissemination and marketing activities are forecasted to support the users recruitment process. Moreover, The DORA consortium has agreed an encouragement model to recruit participants to ensure quality feedback on the use of the DORA Smartphone App during the trial period. Training activities have been forecasted to train the potential users on how to use the DORA interfaces. The technical set-up description covers the software implementation both on service and application site, and the implementation of hardware components for indoor positioning and waiting-time detection at both trial airports so that the pilots are technically fully operational. It is shown also in this document the differences between implemented technologies,
services, applications in DORA versus what was planned in the DoA.

This deliverable includes also an overview of the status and the scheduled activities both from technical set-up perspective and from the technical and non-technical pilot related activities.

MORE Information:

This deliverable ‘6.1 Evaluation Plan’ starts with a general chapter on the background of evaluation in DORA and its purpose. It shows the relation of the DORA project to Horizon 2020 as the biggest EU Research and Innovation programme of the European Union and to the specific call ‘MG 1.3-2014: Seamless Air Mobility’.

It continues with describing the purpose of the deliverable which is to set the plan for all evaluation activities that will be carried out within the DORA project. It, moreover, describes the approach to the evaluation, presents a working plan for the evaluation activities and sets the frame for the responsibilities of the partners involved. Besides this clearly structured delineation of the evaluation framework, the evaluation plan also aims at providing explanations on methods and indicators to be used, as well as presenting guidelines for the application of specific methods by the partners involved in evaluation.

The following chapter summarises the aims of the project as they were described in the ‘Description of Work’ document. Aims are being understood as the realisation of single components of the DORA service and their final integration. The components being described are: “Design and Implementation of a DORA Service Platform (PLA) and a Long Term Door-to-Door Journey Planner (DJP)”, “Design and Implementation of End-User-Applications for Seamless Mobility Information (APP / SWA / WEB)”, “Implementation of Personal Information Services (FIS / ILR / SRS / TMS)”, “Implementation of an Incident and Information Management for Airports (MIM)”, “Design and Implementation of a System for Detection of Waiting Time in Airports (WTS)” and “Design and Implementation of an Indoor Location and Routing at the Terminal (IP / IR)”.

The following chapter (1.5) identifies and describes all objectives that will be evaluated within this project. The objectives being described are ordered along their corresponding task in Work Package 6. Together with the indications of the following chapter, that describe the frame conditions in the implementation sites in Berlin and Palma de Mallorca, the before mentioned objectives provide the basis for the description of those methods that will be applied to measure if – or to which extend – the objectives were reached.

Chapter 2 is dedicated to the description of the iterative DORA evaluation approach. It describes the evaluation activities and their relations to each other, and presents methods and information on how they can be applied. It contains detailed information on the four evaluation activities that will be carried out in DORA:

The Technical evaluation chapter (2.3.1) demonstrates how the evaluation of the technical features of DORA will be evaluated. The DORA developments are divided into three main categories: Services, Applications and Technology. Each category follows a different development methodology that is being described by giving information on methods and timelines for accomplishing them by orienting on the ‘Evaluation Roadmap’.

The chapter Usability evaluation (2.3.2) describes the main goal of the Usability Evaluation, which is to assess usability criteria in order to identify possible problems with the design of the interfaces at an early stage during the conceptual phase and during its integration phase. It also provides a description on how to realize three usability evaluations at each of the three development steps of the DORA system: Usability Evaluation of the Concept for the Web and App GUI / Usability Evaluation of the DORA Prototype / Usability Evaluation of the Integrated Final Product (DORA system Alpha Version). The end of this chapter consists of an overview on the operationalization of these evaluation activities, including information on methods to be applied, partners who are involved, or times for their conducts.

The chapter Results evaluation (2.3.3) focuses on the description of the evaluation activities related to the assessment of the results of the project. It comprises information related to Impact Evaluation and Evaluation of User Satisfaction. It, moreover, includes information on the application of impact evaluation, shows which indicators are being applied for the assessment of the objectives, describes why a control site approach is planned to be applied for two indicators, and shows which methods (user tests / surveys with questionnaire and interviews) will be applied for the assessment of ‘User Satisfaction’. Methods and remarks concerning the operationalization are summarized in tables.

The chapter Process evaluation (2.3.4) starts with an explanation of the intention of this evaluation activity, which is to understand what influences the project process in an either positive or negative way and how experiences gathered during the early phase of the project have supported the further process of the project. It looks at the strengths and weaknesses (drivers and barriers), thereby focusing on HOW an outcome or product is being realized rather than on how the impact from the project performs. This chapter also summarizes information concerning the operationalization of the three phases of this activity at the end of the chapter.

A major ambition of the DORA project, is to develop a system that is easily transferable to other cities and their airports in Europe. Thus, the following chapter 3, provides information on the relevance of the results from all evaluation activities that are being carried out within DORA for other cities that are considering to implement the system in their cities.

Being aware of the fact that every development or implementation process is constantly subject of changes and also risks, chapter 4 describes ‘Issues that can jeopardise the evaluation’. Since these risks are mainly related to the technical development of the components or to the integration of them (e.g.: incompatibilities of systems or a lack of information that is necessary for the development of the system), this chapter tries to foresee a range of possible risks in order to prepare for the case of their occurrence. Thus, also mechanisms to avoid or minimise the risks are being described.

The Evaluation Plan ends with chapter 5 “Operationalization / Roles and Responsibilities”. It provides a quick overview on the DORA objectives and the related Work Packages, shows the involvement of the partners in the tasks of Works Package 6 and the timeline for the deliverables of the single tasks as described in the DOW. It presents a table with an overview on all evaluation tasks and sub-tasks, the related methods for assessment and time frames for their accomplishment.

MORE Information:

This deliverable ‘6.3 Usability Assessment Report’ starts with a general chapter on the DORA project and its purpose. It continues with describing the purpose of the deliverable, which is to report on the Usability Assessment of DORA happened as part of the evaluation activities. It does so firstly by laying out the general methodological approach the Usability Assessment followed. Here, two underlying core concepts, user-based testing and of inspection-based evaluation, are being drawn upon.

The next chapter describes the development of the Usability Assessment approach from the DORA DoA to the more elaborated D6.1 Evaluation Plan. It then states the necessary changes and their causes which mainly were readjustments of the evaluation activities to the actual technical development process. Chapters 4 to 6 are dedicated to the actual conduct of the three evaluation phases in which the evaluation activities were embedded.
Chapter 4 describes the first evaluation phase, which had at its core an expert-based usability workshop in Palma de Mallorca. The workshop resulted in various, mostly minor, details being remarked and subsequently forwarded to the developers. These comments are summarised in Chapter 4 and included in the annex in full detail. The chapter concludes by listing the ‘lessons learnt’.

The second phase of Usability Assessment, which took part as two workshops – one in Germany and one in Spain – which consisted partly of experts and partly of user-group representatives, is described in chapter 5. It follows a similar structure as chapter 4. Comments made during the workshop are summarised in this chapter and in full length included in the annex.

Chapter 6 focuses on the third phase of Usability Assessment. Following the DoA and D 6.1 Evaluation Plan the usability assessment was planned to be completed with testing the DORA app prototype before the start of the DORA field trials. Due to the fact that the final version of the DORA app – the one that should be evaluated during the field trials – was completed by the beginning of June 2017, the evaluation team agreed with the other partners – to carry out this last usability assessment in June / July 2017. This last iteration was necessary to secure that the test users can test a product that sufficiently fulfills usability criteria.

Assessing the usability of the final prototype during a first two months lasting phase of the field trials (see D 5.1) gave the developing partners important feedbacks and the possibility to improve the prototype before the final public launch.

Thus, the last phase consisted of a friendly user-test, a crowd-testing and a workshop with user-group representatives. The operationalisation, implementation and results of each of these evaluation activities are described in the respective chapters. After having laid out the results of each evaluation step in the respective chapters, the deliverable concludes by summarising the overall results and by giving recommendation for the potential future  development of DORA and for those, who might want to replicate it.

MORE Information:

This report describes the DORA awareness and dissemination strategy and defines the approach, direction and objectives of the project dissemination. DORA awareness and dissemination activities concern market, transportation and tourism activities; therefore, they address a wide range of interested parties, such as public administrations and bodies, cultural, academic and research institutions. It follows that the dissemination and awareness strategy needs to have both broad coverage as well as focused effect. This deliverable report identifies the objectives of dissemination, information to disseminate, its target audiences and the communication channels for disseminating the information produced. Furthermore, it describes how dissemination is managed within the consortium and which tools are available for partners as well as providing a link to the exploitation of the results, which is covered more extensively in a separate report (D7.6 Exploitation plan) at the end of the project.

The DORA dissemination strategy seeks to best support generation of expected project impacts as well as create wide awareness to facilitate successful exploitation of the DORA solution post-project. The layered dissemination model builds around the core innovation and allows effectively matching dissemination targets to activities and managing parallel activities. Another key principle is proactive planning of individual activities and systematic monitoring of dissemination progress.

A variety of dissemination channels is used in parallel to address all the relevant stakeholder audiences that are identified in this report. The partners are provided with tools both off- and online along with guidelines on their targeted audiences and usage. A cloud-based software platform, Eurestools Dissemination Tracker, is utilized to support and control the dissemination process.

Dissemination management follows the principles of proactivity, timely information flow, systematic and objective-oriented action. The strategy explains the rules and agreed practices of dissemination management as well as describes the processes for planning and approving dissemination activities. Data management and exploitation topics are introduced but will be covered in detail in following deliverables D1.2 and D7.6, respectively.

MORE Information:

List of confidential and public Deliverables  with planned publication date

Contact Us

We're not around right now. But you can send us an email and we'll get back to you, asap.