Enabling MaaS in the IP4 Ecosystem
Transcript of Enabling MaaS in the IP4 Ecosystem
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 1 of 40 08/06/2020
Enabling MaaS in the IP4 Ecosystem
D1.1 – TD4.2 Travel Shopping CREL Specification
Due date of deliverable: 31/10/2019
Actual submission date: 30/06/2020
Leader of this Deliverable: HaCon
Reviewed: Amadeus IT, Network Rail, INDRA
Project funded from the European Union’s Horizon 2020 research and innovation
programme
Dissemination Level
PU Public X
CO Confidential, restricted under conditions set out in Model Grant Agreement
CI Classified, information as referred to in Commission Decision 2001/844/EC
Start date of project: 01/11/2018 Duration: 31months
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 2 of 40 08/06/2020
Document status
Revision Date Description
00-00-00 04/2019 Initialization of the document
00-00-01 03/2019 First distribution to partners
00-00-02 05/2020 Second distribution to partners
00-00-03 05/2020 further detailed content and redistribution to partners
00-00-04 05/2020 Merged contributions of partners and redistribution
00-01-00 05/2020 Merged contributions to release candidate
00-01-01 06/2020 Merged contributions into release candidate
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 3 of 40 08/06/2020
EXECUTIVE SUMMARY
Within the Intelligent Transport1 challenge, the passenger is at the centre of all concerns. The rail
sector must therefore improve its performance by offering innovative solutions to meet this challenge.
In this context, the MaaSive project aims at setting up an efficient European transport system through
a single application offering activities to travellers in order to simplify the user experience, mask the
complexity of information and services and promote the local environment.
The overall objective of the project is to research and implement a transparent and interoperable
platform offering new levels of interaction between passengers and transport stakeholders based
upon Mobility as a service (MaaS), as well as a ubiquitous and innovative interface for the global
transport services ecosystem.
In this way, MaaSive’s WP1 specifies and implements enhancements to the Travel Shopping
functionalities of the Shift2Rail ecosystem. They include Demand-Responsive Transport, a better
integration of pure individual transport TSPs, and support Multi-User Capabilities. For this purpose,
and in order to guarantee the coherence with S2R projects, the system model is developed using
the Arcadia Capella design tool.
The purpose of this document is to consider the different components of the Travel Shopping for the
specification of MaaSive core release. It is organized as follows: Section 3 defines the operational
aspects to follow in order to define the Travel Shopping component structure as well as the use
cases. Section 4 describes the system analysis, describing the actors that interact with the system,
and the capabilities provided by the system through exchange scenarios between the system and
the actors. Section 5 contains the functional aspects, the system architecture and the components
that should be developed to provide the described capabilities. Section 6 deals with the functional
scenarios, describing all interactions between the components of the system. Finally, section 7
concludes the document
1 Transport in the European Union Current Trends and Issues March 2019 : https://ec.europa.eu/transport/sites/transport/files/2019-transport-in-the-eu-current-trends-and-issues.pdf
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 4 of 40 08/06/2020
TABLE OF CONTENTS
Executive Summary ........................................................................................................................ 3
Table of contents ............................................................................................................................ 4
List of Figures ................................................................................................................................. 5
List of Tables .................................................................................................................................. 5
List of Acronyms ............................................................................................................................. 6
1. Introduction ................................................................................................................................. 7
2. Referenced Documents .............................................................................................................. 8
3. Operational aspects .................................................................................................................... 9
Principles .............................................................................................................................. 9
Scope and Purpose ............................................................................................................... 9
Design Drivers..................................................................................................................... 10
Use cases ........................................................................................................................... 10
4. System analysis ........................................................................................................................ 11
System, Actors and functions .............................................................................................. 11
Actors ...................................................................................................................... 11
Functions ................................................................................................................. 12
Missions .................................................................................................................. 13
System exchange scenarios................................................................................................ 16
Itinerary Offers ......................................................................................................... 16
Mobility Packages .................................................................................................... 17
Ancillary Services .................................................................................................... 19
5. Functional Aspects .................................................................................................................... 22
Components and their Functions ......................................................................................... 22
Mobility Request Manager ....................................................................................... 23
Shopping Orchestrator ............................................................................................. 24
Travel Solution Aggregator ...................................................................................... 24
Meta-Network Builder .............................................................................................. 25
Meta-Network Explorer ............................................................................................ 25
Ancillary Services Orchestrator ................................................................................ 26
Mobility Package Orchestrator ................................................................................. 27
Contractual Management Market Place (CMMP) ..................................................... 27
Functional Architecture ........................................................................................................ 28
6. Capabilities: Functional Scenarios ............................................................................................ 30
Build Meta-Network ............................................................................................................. 30
Calculate Itinerary Offers ..................................................................................................... 32
General flow of the itinerary offer calculation ........................................................... 32
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 5 of 40 08/06/2020
Travel Shopping in Multi-User Capabilities ............................................................... 36
Shop a Mobility Package ..................................................................................................... 36
Shop Ancillary Services ....................................................................................................... 37
7. Conclusion ................................................................................................................................ 39
LIST OF FIGURES
Figure 1: Travel Shopping System Functions and Actors [SAB] TD4.2_TS_System ..................... 12
Figure 2: Mission to provide multi-modal Itineraries and Offers [MCB][MAA] TD4.2_Systems_Capabilities ................................................................................................ 14
Figure 3: Mission to assist group Travelling, Multi-User Capabilities [MCB][MAA] Multi_Users_Capabilities ....................................................................................................... 15
Figure 4: Flow of an Itinerary and its Offer [ES] Shop_Book_Issue an itinerary ............................. 16
Figure 5: Calculating Itinerary Offers on System Level [ES] TD4.2_TS_Calculate_Itinerary .......... 17
Figure 6: Flow of Mobility Package Offers [ES][MAA] Shop_Issue Mobility Package .................... 18
Figure 7: Shopping Mobility Packages on System Level [ES][MAA]TD4.2_Shop_Mobility_Package .............................................................................................................................................. 19
Figure 8: Flow of Ancillary Service Offers [ES][MAA] TD4.3_BT_Shop_Book_Issue_Ancillary_Services ................................................................ 20
Figure 9: Shopping Ancillary Service Offers on System Level [ES] TD4.2_TS_Shop_Ancillary_Services ..................................................................................... 21
Figure 10: Component Overview of Travel Shopping [LCBD] TD4.2_Travel_Shopping ................ 22
Figure 11: Functional Architecture Overview [LAB] TD4.2_TS_Logical_Architecture .................... 29
Figure 12: Build Meta-Network Sequence [ES] TD4.2_TS_Build_Meta-Network_Log ................... 31
Figure 13: Calculate Itinerary Offer – general sequence [ES][MAA] TD4.2_TS_CalculateItineraryOffers_Log_General ................................................................ 33
Figure 14: Calculate Itinerary Offers – Core sequence [ES][MAA] TD4.2_TS_CalculateItineraryOffers_Log_Core ..................................................................... 35
Figure 15: Shop a Mobility Package [ES][MAA]TD4.2_Shop_Mobility_Package ........................... 37
Figure 16: Shop Ancillary Services [ES][MAA] TD4.2_TS_Shop_Ancillary_Services .................... 38
LIST OF TABLES
Table 1: Referenced documents ..................................................................................................... 8
Table 2: Use Cases for TD4.2 – Travel Shopping CREL ............................................................... 10
Table 3: Actors of the TD4.2 – Travel Shopping ............................................................................ 12
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 6 of 40 08/06/2020
LIST OF ACRONYMS
Acronyms Meaning
BT Booking and Ticketing
CREL Core Release
CW Cloud Wallet
DRT Demand-Responsive Transport
FREL Final Release
IT Information Technology
IF Interoperability Framework
LBE Location Based Editor
MN Meta-Network
MNB Meta-Network Builder
MNE Meta-Network Explorer
MP Mobility Package
MPO Mobility Package Orchestrator
MUC Multi-User Capabilities
MUC-O Multi-User Capabilities Orchestrator
PA Personal Application
S2R Shift2Rail
TC Travel Companion
TS Travel Shopping
TSA Travel Solution Aggregator
TSP Travel Service Provider
TSR Travel Service Resolver
TT Trip Tracking
WP Work Package
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 7 of 40 08/06/2020
1. INTRODUCTION
The MaaSive project belongs to Innovation Program 4 (IP4) that is itself part of Shift2Rail (S2R), a
rail joint technology initiative focused on accelerating the integration of new and advanced
technologies into innovative rail product solutions. IP4 is focused on “IT solutions for attractive
Railway services”.
MaaSive continues and complements the work accomplished within previous IP4 projects,
ATTRACkTIVE and Co-Active, in the areas of travel shopping, trip tracking, booking and ticketing,
and the development of a travel companion. The project not only enhances and provides extra
functionalities to the existing IP4 ecosystem, but also enables the integration of intermodality and
MaaS (Mobility as a Service) into the proposed digital framework.
The MaaSive project is broken down into the following working packages: WP1 & WP2 dedicated to
Travel Shopping enrichment, WP3 & WP4 focused on Booking & Ticketing enhancement and
especially inspection and validation management, WP5 & WP6 aimed at developing the flexibility of
the Trip Tracker, a key component of the MaaS offer, WP7 & WP8 linked to the incorporation of
MaaS into the Travel Companion, WP9 & WP10 dedicated to Business and Contractual
management, WP11 & WP12 addressing technical coordination and WP13 related to dissemination
and communication.
Interoperability and the move to MaaS are key elements in the development of a sustainable mobility
in the perspective on the pan-European one-stop-shop ecosystem promoted by S2R-IP4. The
capability to integrate a wide range of mobility providers either public or private as well as the
proposal of attractive fare and integrated bundles will favour the move of passenger traffic from car
to low-carbon mobility solutions.
WP1 & WP2 address TD4.2 Travel Shopping within MaaSive and have the following objectives:
Enrich Journey Planning functionalities by introducing Multi-User Capabilities;
Enlarge the Travel Shopping by taking into account additional modes for the first and last miles,
esp. Demand Responsive Transport;
Develop Technology Demonstrators for all modes, esp. rail and urban domain with the addition
of the Demand Responsive Transport;
Refine the Travel Shopping with more information, alternatives and ancillary services;
Manage the failure cases at all stages.
WP1 is broken down into the following subtasks:
Task 1.1 – Orchestration enhancement
Task 1.2 – Demand Responsive Transport functionalities (specification and implementation)
WP1 includes the following deliverables:
D1.1 – TD4.2 CREL Specifications (this document)
D1.2 – TD4.2 CREL Implementation Report
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 8 of 40 08/06/2020
2. REFERENCED DOCUMENTS
Reference Number Title Revision Date
S2R-COA-WP1-D1.5 Co-Active: TD4.2 FREL Specifications 3.0 17/07/2019
MAS-S2R-D11-
1_CREL-Glossary
MaaSive Glossary Document 00.02.09 30/01/2020
MAS-S2R-D11-
1_CREL-UC
MaaSive Use Case Document 00.01.00 30/01/2020
MAS-S2R-D9-
1_CREL-Spec
MaaSive WP9 CREL Contractual Management
Specifications
00-01-01 28/01/2020
CONN-WP1-D1.7 Connective: D1.7 Services Integration C-REL 5.0 06/02/2019
MAS-S2R-D7-
1_CREL_Spec
MaaSive WP7 CREL Travel Companion
Specifications
1.0 20/12/2019
Table 1: Referenced documents
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 9 of 40 08/06/2020
3. OPERATIONAL ASPECTS
This section presents the underlined principles followed for the design of the Travel Shopping. Based
on some prerequisite drivers, the design of the Travel Shopping must comply with the Shift2Rail
ecosystem answering the user mobility needs by calculating itineraries and offers in an independent
and non-discriminating way. The scope and purpose define the frame of what is considered to be
part of the Travel Shopping and links Travel Shopping to the other Technical Demonstrators (TD) of
the Shift2Rail ecosystem. The Design Drivers state the rules and goals that are followed in order to
fulfil the objectives of the Travel Shopping in MaaSive.
PRINCIPLES
Work Package 1 (WP1) of MaaSive aims to enhance the existing Travel Shopping capabilities of the
Shift2Rail ecosystem to include more modes of transport and facilitate new functionalities for the
users. The Travel Shopping computes the door-to-door trips and offers according to travellers’ needs
and preferences and, thus, is the first step to achieve any other functionality of the Shift2Rail
ecosystem, such as Trip Tracking, Booking and Ticketing and others. The Travel Shopping has to
build upon the achievements of Co-Active and the work done in CONNECTIVE to ensure
compatibility and a sustainable solution for future work. It is also closely related to the Travel
Companion and its development in other Work Packages.
SCOPE AND PURPOSE
The Travel Shopping manages and orchestrates the Users demands for door-to-door travels across
Europe and the functionalities of the Travel Service Providers enabling such travels in a transparent
way for every involved actor. It makes use of the Travel Companion functionalities to interact with
the individual users and it uses the Interoperability Framework to interact with the Travel Service
Providers while also taking into account the Mobility Packages and contractual agreements between
Travel Service Providers formed via the Shift2Rail ecosystem.
The Travel Shopping uses the two-step journey planning and offer building process inherited from
Co-Active. It improves the Meta-Network building process and exploits the advances in
CONNECTIVE to automate the building process. The improvements of CONNECTIVE furthermore
enable a more dynamic and fine-tuned Travel Shopping process which also incorporates new modes
of transport. The Travel Shopping is further enhanced by the capability to incorporate Mobility
Packages into the offer building process.
The work from Co-Active is also enhanced by making the functions for ancillary services more
versatile in context of the lifetime of a travel. You are now able to shop ancillary services at any point
in time of a travel after it was shopped. Even during a travel, you may be able to shop for ancillary
services.
Multi-User Capabilities are a new feature of MaaSive which are integrated into the Travel Shopping
by enabling users to shop group travels as well as to shop travels for someone else as a Travel
Arranger. These functionalities exploit the more flexible definition of preferences with the addition of
profiles as a means to define varying preferences pre-sets for the different contexts of a travel, may
they be leisure travels or business travels for example. Additionally, anonymous users are now able
to use the Travel Shopping capabilities of the Shift2Rail ecosystem.
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 10 of 40 08/06/2020
DESIGN DRIVERS
Based on the Co-Active project the design of the Travel Shopping supports:
Use of shared concepts: to guarantee interoperability at the semantic level, the design of the Travel
Shopping relies on the concepts defined in the common Shift2Rail ontology.
Use of standard communication patterns: to guarantee interoperability at the technological level,
the Travel Shopping is designed to use patterns of interaction and of communication that are used
in standard technologies. As a result, the Travel Shopping follows a service-based approach when
it needs to provide information to external modules.
Authorisation: to emphasise security and privacy of the personal information of the traveller,
authentication and authorisation mechanisms are in place to allow only authorized parties to access
said information. This is especially relevant for the Multi-User Capabilities introduced in MaaSive.
Component-based design: the design of the Travel Shopping fosters a modular approach by
dividing the Travel Shopping into several components, which interact through interfaces both among
themselves and with external services.
Anonymous user: to enable users without a user profile to use basic Travel Shopping functionalities
of the Shift2Rail ecosystem.
Group Travelling: users are enabled to form groups and shop the travel together to provide the best
group travel experience.
Travel Arrangement: users may enable other users to shop travels on their behalf. In contrast to
the Group Travelling, the Travel Arranger does not travel but manages everything around the travel
for the Traveller.
USE CASES
This chapter lists the CREL Use Cases for the Travel Shopping. For more details, refer to the
MaaSive use cases document.
Use Case ID Use Case Name
UC_TD4.2_03 DRT: Journey Planning including DRT (at TSP level)
UC_TD4.3_05 Shop and Issue Ancillary Services at any time
UC_TD4.5_14 A user accesses the Travel Companion functionalities without being logged in
to the system
UC_TD4.5_18 MUC: A Travel Arranger manages a trip for someone else
UC_TD4.5_28 MUC: The Group Administrator shops the joint itinerary part of a group trip
UC_TD4.5_29 MUC: The Group Member shops an individual itinerary part to a group trip
Table 2: Use Cases for TD4.2 – Travel Shopping CREL
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 11 of 40 08/06/2020
4. SYSTEM ANALYSIS
The system analysis consists of the identification of actors and the needed functions for the Travel
Shopping. These functions are then depicted in high-level exchange scenarios.
SYSTEM, ACTORS AND FUNCTIONS
Actors
When shopping a travel, different parameters should be taken into account, whether for the traveller
who has to organize his journey or for the TSPs that contribute to the journey planning and offer
building process. This section describes these different actors involved in the Travel Shopping. Some
of these actors had already been defined in the ATTRACkTIVE and Co-Active projects and will be
used in this project as well. The list has been enhanced with new actors specific to MaaSive project
context.
Actor Description from the Glossary
Anonymous User User who interacts with the system without being registered and
logged in to the S2R-IP4 ecosystem.
Group Administrator Someone who is part of a group of travellers and has the role of
Administrator.
Group Member Someone who is part of a group of travellers which is administrated
by the Group Administrator.
Retailer
A retailer is an organization selling the Products of Travel Service
Provider(s) using the services of Distributors. A retailer may have a
direct relationship with a TSP whereby it acts as an appointed agent
and/or it may have an indirect relationship with a TSP whereby it uses
the services of a Commercial Distributor.
A TSP can play the role of a retailer in connection with both its own
products and those of a partner TSP by whom it is licensed. Retailer
is also called Travel Agent.
Travel Service Provider
(TSP)
Organization providing access to travel related services (e.g.
planning, booking and ticketing) to the public, without necessarily
being the actual provider of the physical transport services
themselves. This could include also travel experiences at stations and
vehicles and much more.
Travel Arranger Someone who plans and potentially also shops, books, and issues a
trip for another person that will be the traveller of the trip.
Traveller
The Traveller (see also “Passenger” when on-board of a vehicle) is
the person making a travel in accordance with the terms and
conditions of the entitlement(s).
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 12 of 40 08/06/2020
User
The user is the generic actor involved in the Shift2Rail environment.
Using the Personal Application on the internet enabled device, they
register and could make a mobility request, selects an Offer to create
their trip and potentially pays for the booking(s).
Table 3: Actors of the TD4.2 – Travel Shopping
Functions
The following figure describes the Travel Shopping functions of the Shift2Rail ecosystem and which
function of the different actors are linked to them.
Figure 1: Travel Shopping System Functions and Actors [SAB] TD4.2_TS_System
The Travel Shopping of MaaSive builds upon the results from Co-Active and enhances existing
functionalities while introducing additional features. Providing multimodal itinerary offers is the core
capability of Travel Shopping. It is reflected in the diagram via the function of the user to request
mobility solutions which are implemented in the Shift2Rail ecosystem by the function to process
mobility requests. This function uses the ability provided by the Travel Service Providers to process
their individual mobility requests. This core functionality is enhanced with the ability to include DRT
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 13 of 40 08/06/2020
(Demand-Responsive Transport) and a better integration of individual transport modes.
Furthermore, the enhanced Travel Shopping supports the Multi-User Capabilities.
Additionally, after the user decided on an itinerary offer, they may request ancillary services. This
functionality is also inherited from Co-Active but is now more versatile. While in Co-Active ancillary
services could only be shopped after an itinerary offer was booked, ancillary services can now be
shopped independently from the status of the itinerary offer.
MaaSive introduces support for Mobility Packages. Users can add Mobility Packages they already
own, shop for Mobility Packages to purchase or use the Mobility Package to purchase a ticket for a
trip.
For the Travel Service Providers (TSP), MaaSive adds the feature to form agreements in cooperative
tariffs with other TSPs. During this process, TSP are now enabled to be notified about changes on
the status of such an agreement or about new agreement proposals.
Retailers are a new actor in MaaSive. They are enabled to create Mobility Packages containing tariffs
from varying TSPs. They also use the functionality to form agreements via the Shift2Rail ecosystem.
Missions
The presented functions are the result of the missions’ analyses to achieve benefits for the defined
actors. This section presents the underlying mission with the derived capabilities and involved actors.
4.1.3.1 Provide Multi-modal Itineraries
Providing multi-modal itineraries is the main mission for the TD4.2 - Travel Shopping. This mission
relies upon the capabilities to calculate itineraries, to shop ancillary services, to manage contracts,
and to shop mobility packages.
The anonymous user is one of the new actors in MaaSive and initially should be able to calculate
itineraries via the Shift2Rail ecosystem.
Other registered, and therefore known, users, such as the traveller and the new actors travel
arranger, group member, and group administrator may additionally use the capabilities to shop
ancillary services, and to shop Mobility Packages in the TD4.2 – Travel Shopping.
Another group of actors are the Travel Service Providers. They provide the services to ultimately
calculate itineraries, to shop ancillary services and they use the capability to manage contracts to
define and offer Mobility Packages in the capability to shop Mobility Packages.
The new actor “retailer” is also able to create Mobility Packages by forming agreements and, thus,
contributes to the capabilities to shop Mobility Packages and manage contracts.
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 14 of 40 08/06/2020
Figure 2: Mission to provide multi-modal Itineraries and Offers [MCB][MAA] TD4.2_Systems_Capabilities
4.1.3.2 Assist Group Travelling (Multi-User Capabilities)
Multi-User Capabilities are a general topic within MaaSive which also impacts the Travel Shopping
functionalities. The figure below illustrates the identified capabilities to facilitate this mission. Most of
the listed capabilities rely on the results of Travel Shopping which is directly referenced by the
capability to calculate itineraries.
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 15 of 40 08/06/2020
Figure 3: Mission to assist group Travelling, Multi-User Capabilities [MCB][MAA] Multi_Users_Capabilities
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 16 of 40 08/06/2020
SYSTEM EXCHANGE SCENARIOS
The system exchange scenarios present the high-level system exchanges of the Travel Shopping
with the involved actors. Through the Capella modelling, the exchange scenarios are described for
each capability.
Itinerary Offers
The general functional flow for itinerary offers is depicted in the exchange scenario below. It
emphasises the role of Travel Shopping in Shift2Rail because it is the first step towards a multi-
modal itinerary offer. Afterwards, users may optionally decide to book and issue the itinerary offer.
The Shift2Rail ecosystem communicates with the Travel Service Providers involved in the itinerary
offer to book the itinerary offer. During the issuing process of the booked offer, the Shift2Rail
ecosystem also communicates with the user-chosen Payment Service Provider.
Figure 4: Flow of an Itinerary and its Offer [ES] Shop_Book_Issue an itinerary
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 17 of 40 08/06/2020
The following figure shows what is hidden behind the Travel Shopping reference ([ES]
TD4.2_TS_Calculate_Itineraries) from the previous figure. The User requests mobility solutions from
the Shift2Rail ecosystem. During the computation of the request, the Shift2Rail ecosystem requests
detailed partial mobility responses from the Travel Service Providers to aggregate them into mobility
solutions. The Shift2Rail ecosystem responds with the final result to the initial mobility request of the
user.
Figure 5: Calculating Itinerary Offers on System Level [ES] TD4.2_TS_Calculate_Itinerary
Mobility Packages
The mobility package is an agreement among a MaaS Operator and two or more transport service
providers who want to establish a product that includes trips and/or services of the different TSPs
included in it and make it available to the users through the Travel Companion. Once the Mobility
Packages are available in the Shift2Rail ecosystem, they can be shopped, booked and issued by a
user.
Figure 6 shows a complete flow where the user can shop, book and issue a mobility package. The
present document focuses on the first interaction: shop a mobility package.
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 18 of 40 08/06/2020
Figure 6: Flow of Mobility Package Offers [ES][MAA] Shop_Issue Mobility Package
Figure 7 illustrates the scenario when the user wants to retrieve the list of Mobility Packages, which
are stored in the ecosystem.
Through the Personal Application, the user sends a request to the Shift2Rail ecosystem where all
mobility packages are stored.
The Shift2Rail ecosystem replies to the request with a list of all available Mobility Packages. If the
user gives additional details about the Mobility Packages of interest, the Shift2Rail ecosystem
applies them as filters to the list to completely satisfy the user’s needs.
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 19 of 40 08/06/2020
Figure 7: Shopping Mobility Packages on System Level [ES][MAA]TD4.2_Shop_Mobility_Package
Ancillary Services
Ancillary Services are optional additions to the itinerary offer that revolve around the itinerary but are
not mandatory to its fulfilment. In MaaSive, these ancillary services may be added to the itinerary
offer at any point in time after the itinerary offer was shopped until the itinerary is over. The user may
request available ancillary services from the Shift2Rail ecosystem which uses the information from
the Travel Service Providers to answer that request. As with itinerary offers in the general itinerary
offer flow, ancillary service may optionally be booked and issued afterwards in the same manner.
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 20 of 40 08/06/2020
Figure 8: Flow of Ancillary Service Offers [ES][MAA] TD4.3_BT_Shop_Book_Issue_Ancillary_Services
The following figure illustrates the exchange scenario to shop ancillary services. The user sends a
request for available ancillary services to the Shift2Rail ecosystem which computes the results by
aggregating the available ancillary service offers. The result is presented to the user who may
proceed to book and issue ancillary service offer items.
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 21 of 40 08/06/2020
Figure 9: Shopping Ancillary Service Offers on System Level [ES] TD4.2_TS_Shop_Ancillary_Services
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 22 of 40 08/06/2020
5. FUNCTIONAL ASPECTS
The different actors identified in 4.1.1 interact with the system through different functions and use
these functions in different ways. The Travel Shopping is designed to facilitate each of those
scenarios in a general manner. To manage the complexity, the Travel Shopping consists of multiple
components which are listed and described in detail in this chapter.
COMPONENTS AND THEIR FUNCTIONS
The following figure shows an overview of the Travel Shopping and its components. These
components are all taken over from Co-Active, but further enhanced in their functionality.
Figure 10: Component Overview of Travel Shopping [LCBD] TD4.2_Travel_Shopping
Most components interact with other Technical Demonstrators (TD) to fulfil the objectives. The
following component descriptions go into more detail when and to which TD a component
communicates. In addition to these pure Travel Shopping components, there are components mainly
located in other TDs that also fulfil Travel Shopping functionalities:
• Ancillary Services Orchestrator (mainly TD4.3 – Booking and Ticketing)
• Mobility Package Orchestrator (mainly TD4.3 – Booking and Ticketing)
• Contractual Management Market Place (CMMP; mainly TD4.2 –Travel Shopping but
explained in WP9; s. Table 1: Referenced documents)
These components are also listed in this section, but only their contribution to the Travel Shopping
capabilities is described. Their detailed description is part of the specification of their main Technical
Demonstrators (TDs).
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 23 of 40 08/06/2020
Mobility Request Manager
Mobility Request Manager
The Mobility Request Manager is communicating with the components of the TD4.5 – Travel
Companion. It receives travel shopping requests (mobility requests) from the Personal Application,
retrieves additional preferences and user information from the Cloud Wallet and transforms that
into the shopping request for the Shopping Orchestrator. Eventually, the Mobility Request
Manager puts the travel shopping results into the Cloud Wallet and responds to the Personal
Application.
Input Output
• UserID of the requesting user • Itinerary offers
• UserIDToken of the requesting user
• Search Options
• Travel Parameters
• UserID of the traveller
This may be different from the requesting
user for functionalities related to Multi-User
Capabilities
• ProfileID
Provided functions
• Process mobility solution request • Store Offers in the Cloud Wallet
• Enrich mobility solution requests with
preferences and general user
information
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 24 of 40 08/06/2020
Shopping Orchestrator
Shopping Orchestrator
The Shopping Orchestrator is the central component of the Travel Shopping to manage calls to
each component of the Calculate Itinerary exchange scenarios. It receives the enriched shopping
request from the Mobility Request Manager and orchestrates the computation across the other
involved components of the Travel Shopping and other Technical Demonstrators.
Input Output
• Preferences • Itinerary offers
• Travel Parameters
Provided functions
• Orchestrate Travel Shopping
Travel Solution Aggregator
Travel Solution Aggregator
During the orchestration of the Shopping Orchestrator, the Travel Solution Aggregator is called to
request detailed partial travel solutions from the Travel Service Providers identified to be able to
contribute to the overall itinerary offer. After aggregating the partial travel solutions, the Travel
Solution Aggregator additionally requests the Contractual Management Market Place (CMMP) to
apply Business Rules that represent contractual agreements between involved TSPs.
Furthermore, the Travel Solution Aggregator requests the Mobility Package Orchestrator to add
itinerary offers that result from the application of Mobility Packages that the traveller owns.
Input Output
• Meta-Route • Itinerary offers
• Travel Parameters
• Preferences
• TSP_IDs of the involved TSPs
Provided functions
• Analyse Meta-Route • Calculate Routes
• Apply Business Rules
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 25 of 40 08/06/2020
Meta-Network Builder
Meta-Network Builder
The Meta-Network Builder is the component that integrates and simplifies the network data of all
registered TSPs in the Shift2Rail ecosystem that provide Travel Shopping functionality.
The Meta-Network Builder periodically retrieves new network data of the Travel Service Providers
from the Interoperability Framework, creates a new Meta-Network and distributes that Meta-
Network to the Meta-Network Explorer.
Input Output
• New network data from the TSPs in
GTFS where the individual location IDs
are replaced with global IDs
• Meta-Network
• Additional Meta-Network data
information (Stop Point Parents)
Provided functions
• Build Meta-Network • Process Network Data
Meta-Network Explorer
Meta-Network Explorer
The Meta-Network is the foundation for the first of the two-step approach of Travel Shopping to
calculate itinerary offers.
The Meta-Network is the result of the Meta-Network Building process and is imported into the
Meta-Network Explorer. The Meta-Network Explorer calculates a first but close set of
approximations to itineraries (Meta-Routes). The results of this function are handed over to the
Shopping Orchestrator which requests the Travel Solution Aggregator to do the second step of
calculating itinerary offers. The Travel Solution Aggregator request detailed information from the
TSPs according to the Meta-Routes computed by the Meta-Network Explorer.
Input Output
• Meta-Network • Meta-Routes
• Travel Parameters
• Preferences
Provided functions
• Find Meta-Routes • Reload Meta-Network
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 26 of 40 08/06/2020
Ancillary Services Orchestrator
Ancillary Services Orchestrator
The Ancillary Services Orchestrator is not a component of TD4.2 – Travel Shopping but of TD4.3
– Booking and Ticketing. However, in addition to other capabilities, it realizes the capability to
shop Ancillary Services and, thus, a functionality of Travel Shopping. The Personal Application
requests available Ancillary Services for a given Offer and Trip from the Ancillary Services
Orchestrator which retrieves the detailed information about the user, the trip, and the offer from
the Cloud Wallet and orchestrates the shopping process for ancillary services. It uses the
Interoperability Framework to identify relevant TSPs and to request available ancillary services
from these TSPs. It further aggregates the offer items and presents the result to the Personal
Application after the result is also stored in the Cloud Wallet of the requesting user.
Input Output
• OfferID • Offers
• TripID
• UserID
• UserIDToken
Provided functions
• Shop Ancillary Services
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 27 of 40 08/06/2020
Mobility Package Orchestrator
Mobility Package Orchestrator
The Mobility Package Orchestrator component aims to manage all the requests related to mobility
packages. Within Travel Shopping, this component provides the available mobility packages for a
given user request and identifies the Mobility Package ID to apply its correspondent advantages.
If details are provided by the user via mobility package parameters, this orchestrator first, retrieves
the preferences of the user from the cloud wallet and later on communicates with the CMMP in
order to satisfy the user’s request.
Input Output
• Offers • Additional Offers with applied Mobility
Packages
• Trip
• Preferences
• UserID
• UserIDToken
• Mobility Package Parameters
Provided functions
• Apply Business Rules
Contractual Management Market Place (CMMP)
Contractual Management Market Place (CMMP)
The CMMP provides the functionality to form and apply contractual agreements between TSPs
and mobility packages. Within Travel Shopping, this component applies the Business Rules that
are compatible with the itinerary offers that the Travel Solution Aggregator found, as it was
developed in Co-Active. In addition, in MaaSive the CMMP applies the Business Rules associated
with the Mobility Packages that the user has previously bought to identify additional itinerary offers.
Input Output
• Offer • Terms and Conditions
• Mobility Package ID • Offers
Provided functions
• Apply Business Rules
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 28 of 40 08/06/2020
FUNCTIONAL ARCHITECTURE
According to the components listed previously, this section2 describes the logical architecture of
these components and the interrelation between their functions.
As identified above, the main components are the Meta-Network Builder and the Explorer, the
Mobility Request Manager, the Shopping Orchestrator, and the Travel Solution Aggregator. The
figures below depict the architecture of the system.
2 The functional architecture presented in this document refers only to those different from the Co-Active ones.
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 29 of 40 08/06/2020
Figure 11: Functional Architecture Overview [LAB] TD4.2_TS_Logical_Architecture
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 30 of 40 08/06/2020
6. CAPABILITIES: FUNCTIONAL SCENARIOS
This chapter describes the detailed functional exchanges regarding the capabilities of Travel
Shopping.
BUILD META-NETWORK
The Travel Shopping uses a two-step approach to calculate an itinerary. The first step uses a Meta-
Network that is an abstracted simplification of the integrated network of all TSPs in the Shift2Rail
ecosystem.
This Meta-Network is built periodically by the Meta-Network Builder, independently from the
calculation of itineraries. The Meta-Network Builder retrieves the new network data for each TSP
from the Interoperability Framework. TSPs register themselves and manage their data in the
Shift2Rail ecosystem via components of the Interoperability Framework. The Interoperability
Framework integrates that data into its knowledge base and enriches the locations with global IDs.
Furthermore, the Interoperability Framework abstracts the input formats for network data per TSP
and converts them for the Meta-Network Builder into a common format, such as GTFS.
The Meta-Network Builder now integrates each network data set into a Meta-Network. During the
computation of the Meta-Network, the Meta-Network Builder may identify new meta-information for
some locations, called stop point parents, which it stores in the Interoperability Framework’s
knowledge base for future integrations. This ensures a reliable and deterministic Meta-Network.
Finally, the Meta-Network Builder publishes the new Meta-Network to the Meta-Network Explorer.
Upon reloading its Meta-Network, the Meta-Network Explorer now uses the new Meta-Network
during the following itinerary calculations.
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 31 of 40 08/06/2020
Figure 12: Build Meta-Network Sequence [ES] TD4.2_TS_Build_Meta-Network_Log
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 32 of 40 08/06/2020
CALCULATE ITINERARY OFFERS
Calculating itinerary offers is the primary objective of the TD4.2 – Travel Shopping. In this section, it
is described in two sequences: a general flow depicting the overall exchange scenario of the itinerary
offer calculation, and the core flow which focuses on the interaction with the TSPs. Additionally, this
section contains a description of the itinerary offer calculation in the contexts of Multi-User
Capabilities.
General flow of the itinerary offer calculation
The itinerary offer calculation starts from the Personal Application where the user request itinerary
offers. The Personal Application builds a mobility solution request with the information of the user
with his UserID and UserIDToken, with the ProfileID to be used and the TravelParameters.
Additionally, the Personally Application may include a UserID for the traveller if it differs from the
requesting user. More information on this detail can be found in the section about itinerary offer
calculation in the contexts of Multi-User Capability in 6.2.2.
The mobility solution request is received by the Mobility Request Manager which uses the
UserIDToken of the requesting User, and the UserID and ProfileID of the traveller to retrieve
personal preferences and mobility packages of the traveller’s Cloud Wallet. The Mobility Request
Manager enriches the mobility solution request with these preferences mobility package information
and forwards the preferences and travel parameters to the Shopping Orchestrator.
The Shopping Orchestrator starts by resolving the locations from the TravelParameters via the
Interoperability Framework to the stop places that can be found in the network data. Afterwards, for
the first step of the two-step travel shopping approach, the Shopping Orchestrator requests Meta-
Routes from the Meta-Network Explorer that conform to the TravelParameters and Preferences.
The Meta-Network Explorer operates on the most recently built Meta-Network and identifies Meta-
Routes as the first approximations of itineraries. During the computation, the Meta-Network Explorer
checks the availability of individual transport for potential individual transport segments of the Meta-
Routes via the Interoperability Framework. The resulting Meta-Routes are then sent back to the
Shopping Orchestrator for the second step of the two-step travel shopping approach which is
depicted in the next figure.
At the end of the second step, the Shopping Orchestrator replies to the initial mobility solution request
of the Mobility Request Manager with detailed itinerary offers. These offers are stored in the Cloud
Wallet of the Traveller and responded with to the Personal Application of the requesting user.
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 33 of 40 08/06/2020
Figure 13: Calculate Itinerary Offer – general sequence [ES][MAA] TD4.2_TS_CalculateItineraryOffers_Log_General
Figure 14 illustrates the second of the two-step approach of Travel Shopping. It is run for each Meta-
Route found within the first step of the two-step approach of Travel Shopping. Its goal is to find the
details and actual itinerary offers for the Meta-Routes with the help of the involved Travel Service
Providers.
The Shopping Orchestrator starts by using the Interoperability Framework to resolve potential Travel
Service Providers for the given Meta-Route that may contribute to a final itinerary offer. For each
Meta Travel Episode of the Meta-Route, Shopping Orchestrator uses optional filters, such as modes
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 34 of 40 08/06/2020
of transport, and requests Travel Service Providers that operate on start and destination of the Meta
Travel Episode from the Interoperability Framework.
The Shopping Orchestrator proceeds by requesting detailed itinerary offers from the Travel Solution
Aggregator by providing the TravelParameters, the Preferences, the MetaRoute, and the
previously identified TSP_IDs.
The Travel Solution Aggregator analyses the Meta-Route and starts the calculation of detailed
routes. For each potential TSP, the Travel Solution Aggregator generates a mobility request with
suitable TravelParameters and the Preferences towards the TSP via the Interoperability
Framework. The results from each TSP are aggregated to overall itinerary offers and the Travel
Solution Aggregator proceeds to apply business rules to the offer to include contractual agreements
between the TSPs and Mobility Packages that the user owns.
For each calculated and aggregated offer, the Travel Solution Aggregator requests the Contractual
Management Market Place (CMMP) to apply appropriate business rules to the Offer. Those
business rules reflect the contractual agreements of TSPs involved in the offer. The most likely
outcome of this process is a reduced price for the overall offer.
Afterwards, the Travel Solution Aggregator requests the Mobility Package Orchestrator to add offers
that result from the application of user-owned Mobility Packages. This request contains the overall
calculated Trip, Offer, and Preferences which contain the Mobility Packages of the user. The
Mobility Package Orchestrator extracts the Mobility Packages from the preferences and uses the
CMMP to apply the Mobility Packages representing business rules.
Finally, the Travel Solution Aggregator adds the results of the Mobility Packages Orchestrator to the
offers to enable the user to choose whether to consume Mobility Packages or not. The results are
forwarded to the Shopping Orchestrator. As described in the previous figure, the Shopping
Orchestrator either starts this second step of the two-step approach anew with the next Meta-Route
or, if all Meta-Routes went through this process, responds to the Mobility Request Manager with the
overall results of all offers and trips calculated in this two-step approach of Travel Shopping.
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 35 of 40 08/06/2020
Figure 14: Calculate Itinerary Offers – Core sequence [ES][MAA] TD4.2_TS_CalculateItineraryOffers_Log_Core
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 36 of 40 08/06/2020
Travel Shopping in Multi-User Capabilities
In addition to the more versatile integration of individual transport and mobility packages, the Travel
Shopping process also supports the Multi-User Capabilities mostly defined and implemented in
TD4.5 – Travel Companion. Now, there may be a difference between the requesting user and the
traveller. Setting the relationships and permissions prior to the Travel Shopping process is part of
the TD4.5 – Travel Companion specification. Afterwards, the requesting user may choose to request
itinerary offers in the name of another user, the traveller. In this case, the mobility solution request
from the Personal Application to the Mobility Request Manager contains the UserID and ProfileID
of the Traveller, but the other UserID and the UserIDToken belong to the requesting user. The first
UserID and the ProfileID identify the traveller and additional preferences including the Mobility
Packages – the resource – that the requesting user wants to use or access, while the UserIDToken
and the other UserID identify the requesting user and are used to authorise this access by the Cloud
Wallet when the Mobility Request Manager retrieves the resource.
The following process is independent from this Multi-User Capability support. At the end of the two-
step approach of Travel Shopping, the offers are stored in the Cloud Wallet of the Traveller by the
Mobility Request Manager. For the optional next steps of the other Technical Demonstrators, such
as Booking and Issuing, the authorisation of the access to the resource by the requesting user is
rechecked.
SHOP A MOBILITY PACKAGE
A new feature of the Shift2Rail ecosystem is the possibility to shop Mobility Packages. First, Mobility
Packages need to be created, agreed upon regarding the terms and conditions by the involved
parties. Eventually, they are stored in the Contractual Management Marketplace (CMMP). These
functionalities are part of Work Package 9 of MaaSive and details can be found in the respective
specification (s. Table 1: Referenced documents).
In order to shop a mobility package, a user uses the Personal Application to trigger the shopping
process with a mobility package request. The request is forwarded to the mobility package
orchestrator with the UserID, UserIdToken and MobilityPackageParameters. The mobility
package orchestrator first retrieves the preferences associated with the user from the cloud wallet in
order to completely satisfy the user requirements.
After collecting the preferences from the cloud wallet, the mobility package orchestrator forwards the
request to the CMMP where the mobility packages are stored.
The CMMP analyses the request and its details and provides a response to the mobility package
orchestrator with a list of the available mobility package that fulfils the requirements from the request.
Once it gathered the results, the mobility package orchestrator stores them in the private virtual
space of the user, the cloud wallet. To reidentify the mobility packages during their potential
application in coming processes, a mobility package ID is associated with the mobility packages.
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 37 of 40 08/06/2020
Figure 15: Shop a Mobility Package [ES][MAA]TD4.2_Shop_Mobility_Package
SHOP ANCILLARY SERVICES
The Travel Shopping not only contains the calculation of itinerary offers, but additionally enables
users to shop for mobility packages and even ancillary services for a given offer. The user may
request ancillary services at any time after the itinerary offer was shopped until the itinerary is
travelled. The User initiates the process by sending a request for Ancillary Services via the Personal
Application to the Ancillary Services Orchestrator. This request contains the UserID, the
UserIDToken, the OfferID, and the TripID. The Ancillary Services Orchestrator first retrieves the
offer and trip from the Cloud Wallet by providing the aforementioned parameters and it also retrieves
the user preferences from the Cloud Wallet.
For each TravelEpisode of the Trip, the Ancillary Services Orchestrator request potential Travel
Service Providers that may offer ancillary services along the Travel Episode from the Interoperability
Framework. The Ancillary Services Orchestrator proceeds by requesting ancillary services from the
just identified Travel Service Providers (TSP) via the Interoperability Framework. This request
contains the OfferItem, the TravelEpisodes that the OfferItem covers, the TSP_ID of the targeted
TSP, and the Preferences of the user.
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 38 of 40 08/06/2020
The Ancillary Services Orchestrator aggregates the offer items for the available ancillary services
and adds them to the original offer that covered the itinerary in the Cloud Wallet. The result is finally
forwarded to the Personal Application so that the user may choose from the available ancillary
services and optionally book and issue them.
Figure 16: Shop Ancillary Services [ES][MAA] TD4.2_TS_Shop_Ancillary_Services
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 39 of 40 08/06/2020
7. CONCLUSION
This document summarises the CREL Specification of Travel Shopping according to MaaSive
requirements. Within the document, constraints are defined throughout missions, capabilities and
functional aspects. The main components, the Shopping Orchestrator, the Travel Solution
Aggregator, the Mobility Request Manager, the Meta-Network Builder and Meta-Network Explorer,
are described to present their functions, inputs, and outputs. Finally, a description of the functional
architecture of the Travel Shopping is presented in depth.
This specification is the cornerstone of the CREL implementation. It also represents the basis for the
work that will be carried out in the next release. Taking this specification into account, we can validate
the architecture or adapt it for the future.
H2020 – Contract
No 826385 – MaaSive
S2R-MaaSive-D1.1-TD4.2 Page 40 of 40 08/06/2020
End of document