enabling maas in the ip4 ecosystem

H2020 – Contract

No 826385 – MaaSive

S2R-MaaSive-D1.1-TD4.2 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


S2R-MaaSive-D1.1-TD4.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


S2R-MaaSive-D1.1-TD4.2 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

https://ec.europa.eu/transport/sites/transport/files/2019-transport-in-the-eu-current-trends-and-issues.pdf

H2020 – Contract


S2R-MaaSive-D1.1-TD4.2 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


S2R-MaaSive-D1.1-TD4.2 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


S2R-MaaSive-D1.1-TD4.2 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


S2R-MaaSive-D1.1-TD4.2 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


S2R-MaaSive-D1.1-TD4.2 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


S2R-MaaSive-D1.1-TD4.2 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


S2R-MaaSive-D1.1-TD4.2 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


S2R-MaaSive-D1.1-TD4.2 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


S2R-MaaSive-D1.1-TD4.2 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


S2R-MaaSive-D1.1-TD4.2 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


S2R-MaaSive-D1.1-TD4.2 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


S2R-MaaSive-D1.1-TD4.2 of 40 08/06/2020

Figure 3: Mission to assist group Travelling, Multi-User Capabilities [MCB][MAA] Multi_Users_Capabilities

H2020 – Contract


S2R-MaaSive-D1.1-TD4.2 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


S2R-MaaSive-D1.1-TD4.2 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


S2R-MaaSive-D1.1-TD4.2 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


S2R-MaaSive-D1.1-TD4.2 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


S2R-MaaSive-D1.1-TD4.2 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


S2R-MaaSive-D1.1-TD4.2 of 40 08/06/2020

Figure 9: Shopping Ancillary Service Offers on System Level [ES] TD4.2_TS_Shop_Ancillary_Services

H2020 – Contract


S2R-MaaSive-D1.1-TD4.2 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


S2R-MaaSive-D1.1-TD4.2 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


S2R-MaaSive-D1.1-TD4.2 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


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


• Preferences

• TSP_IDs of the involved TSPs

Provided functions

• Analyse Meta-Route • Calculate Routes

• Apply Business Rules

H2020 – Contract


S2R-MaaSive-D1.1-TD4.2 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


• Preferences

Provided functions

• Find Meta-Routes • Reload Meta-Network

H2020 – Contract


S2R-MaaSive-D1.1-TD4.2 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


S2R-MaaSive-D1.1-TD4.2 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


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


H2020 – Contract


S2R-MaaSive-D1.1-TD4.2 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


S2R-MaaSive-D1.1-TD4.2 of 40 08/06/2020

Figure 11: Functional Architecture Overview [LAB] TD4.2_TS_Logical_Architecture

H2020 – Contract


S2R-MaaSive-D1.1-TD4.2 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


S2R-MaaSive-D1.1-TD4.2 of 40 08/06/2020

Figure 12: Build Meta-Network Sequence [ES] TD4.2_TS_Build_Meta-Network_Log

H2020 – Contract


S2R-MaaSive-D1.1-TD4.2 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


S2R-MaaSive-D1.1-TD4.2 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


S2R-MaaSive-D1.1-TD4.2 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


S2R-MaaSive-D1.1-TD4.2 of 40 08/06/2020

Figure 14: Calculate Itinerary Offers – Core sequence [ES][MAA] TD4.2_TS_CalculateItineraryOffers_Log_Core

H2020 – Contract


S2R-MaaSive-D1.1-TD4.2 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


S2R-MaaSive-D1.1-TD4.2 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


S2R-MaaSive-D1.1-TD4.2 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


S2R-MaaSive-D1.1-TD4.2 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


S2R-MaaSive-D1.1-TD4.2 of 40 08/06/2020

End of document