d1.2 – wp1 specifications crel

Grant Agreement No. 730846

S2R-CoA-WP1-D2.2 31/05/2018

Co-Active

D1.2 – WP1 Specifications CREL

Due date of deliverable: 28/02/2018

Actual submission date: 31/05/2018

Leader of this Deliverable: HaCon, Daniel Schmidt

Reviewed by: Shopping partners (INDRA / THALES / Network Rail)

Document status

Revision Date Description

0.0 01.06.2017 Shopping specification v0.0 – First version

1.1 20.06.2017 Shopping specification v0.1 – Updates for Actors,

Components and Functions

1.3. 26.06.2017 Indra review

1.4. 28.08.2017 Thales review

1.5. 30.08.2017 Review by all at conference call

1.6. 13.09.2017 Update by INDRA

1.7. 16.11.2017 Update during the workshop

1.8. 28.11.2017 Update HaCon

1.9. 12.12.2017 Updates during review meeting

1.10. 19.12.2017 Update HaCon

1.11 23.03.2018 Update HaCon

1.13 16.05.2018 Updates during final review meeting

2.0 31.05.2018 Final Version


S2R-CoA-WP1-D2.2 31/05/2018

This project has received funding from the Shift2Rail Joint Undertaking under Grant

Agreement 730822

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

Reviewed: YES

Start date of project: 01/09/2016 Duration: 28 months

This project has received funding from the European Union’s Horizon 2020 research and innovation

programme under grant agreement No 730846.


S2R-CoA-WP1-D2.2 31/05/2018

EXECUTIVE SUMMARY

This document is about the Shopping functions specification, their use cases, behaviour, their data

model and their external interfaces.

The content of other Work Packages are not detailed in this document because they are not in the

Shopping’s scope.

All terms and acronyms are defined in the Co-Active glossary.


S2R-CoA-WP1-D2.2 31/05/2018

TABLE OF CONTENTS

Executive Summary ........................................................................................................................ 3

List of Figures ................................................................................................................................. 6

List of Tables .................................................................................................................................. 7

List of Abbreviations ........................................................................................................................ 8

Introduction ................................................................................................................................. 9 1.

Referenced Documents ............................................................................................................ 10 2.

Operational aspects .................................................................................................................. 11 3.

3.1 Principles ............................................................................................................................ 11

3.2 Scope/Purpose.................................................................................................................... 12

3.3 Design Drivers..................................................................................................................... 13

3.3.1 Semantic Interoperability ......................................................................................... 13

3.3.2 Service Architecture ................................................................................................. 13

Actors and use cases ................................................................................................................ 14 4.

4.1 Actors .................................................................................................................................. 14

4.2 Context ............................................................................................................................... 15

4.3 Missions and Capabilities .................................................................................................... 15

4.4 Use Cases .......................................................................................................................... 17

List of Use Cases .................................................................................................................. 17

Design decisions and constraints .............................................................................................. 18 5.

Functional aspects .................................................................................................................... 19 6.

6.1 Components ........................................................................................................................ 19

6.1.1 TS Travel Shopping Components ............................................................................ 19

6.1.2 TS Travel Expert Components ................................................................................. 20

6.1.3 Contractual Management Market Place (CMMP) ..................................................... 20

6.2 Functions ............................................................................................................................ 20

6.3 functional architecture ......................................................................................................... 24

Capabilities: FuNctional Scenario ............................................................................................. 25 7.

7.1 Presentation ........................................................................................................................ 25

7.2 Capabilities specifications ................................................................................................... 25

7.2.1 CreateMetaNetwork ................................................................................................. 25

7.2.2 CalculateItineraries .................................................................................................. 25

7.2.3 CalculateOffers ........................................................................................................ 26

7.2.4 ManageContracts (CMMP) ...................................................................................... 26

Functional Exchanges ............................................................................................................... 28 8.

8.1 Functional Exchange Details ............................................................................................... 28


S2R-CoA-WP1-D2.2 31/05/2018

8.2 Data Model .......................................................................................................................... 28

8.3 Interfaces ............................................................................................................................ 28


S2R-CoA-WP1-D2.2 31/05/2018

LIST OF FIGURES

Figure 1: Components overview for TD4.2 Travel Shopping ......................................................... 19

Figure 2: Subcomponents of the Travel Solution Aggregator ........................................................ 20

Figure 3: Work flow of WP1 Travel Shopping ................................................................................ 22


S2R-CoA-WP1-D2.2 31/05/2018

LIST OF TABLES

Table 1: Referenced documents ................................................................................................... 10

Table 2: Design decisions table .................................................................................................... 18

Table 3: Travel Shopping used functions of other TDs .................................................................. 24


S2R-CoA-WP1-D2.2 31/05/2018

LIST OF ABBREVIATIONS

BI Broker Interface

BRE Business Rule Engine

CMMP Contractual Management Market Place

LR Location Resolver

MN Meta Network

MNB Meta Network Builder

MNE Meta Network Explorer

MRM Mobility Request Manager

OB Offer Builder

SO Shopping Orchestrator

TC – PA Travel Companion – Personal Application

TC – CW Travel Companion – Cloud Wallet

TE Travel Expert

TER Travel Expert Resolver

TS Travel Shopping

TSA Travel Solution Aggregator

TSP Transport Service Provider (see Travel Expert)


S2R-CoA-WP1-D2.2 31/05/2018

INTRODUCTION 1.

This document identifies the design decisions and specifications that shall be applicable for the

Travel Shopping (hereafter TS) process in the Shift2Rail ecosystem. TS is part of CO-ACTIVE

project which includes also Booking & Ticketing. It provides a functional architecture to all

stakeholders. It has been defined by the project “Travel Shopping” technical community and it is

used as a contribution for the detailed service specifications produced by the technical coordination

area. This document is a separate contribution and has been consolidated and aligned to form a

coordinated view of architecture and shared data interfaces.

The main results of the deliverable are a set of principles for a traveller centred approach for a

seamless travel experience, a single conceptual architecture, a description of functions, of their

data model and a description of messages exchanged involved in the Travel Shopping processes..

Therefore, this document specifies the main functions of the Travel Shopping process, and for

each of them, their functioning and external exchanges.


S2R-CoA-WP1-D2.2 31/05/2018

REFERENCED DOCUMENTS 2.

This section lists the document reference number, title, revision, and date of all documents

referenced in the specifications document.

Reference

Number

Title Revision Date

1 Grant Agreement-730846-Co-Active 1 08/08/2017

2 Co-Active: D2.2 – WP2 Booking & Ticketing - CREL

Specification 1.2 21/02/2018

3 IT2Rail: D2.2 – Travel Shopping Specifications –

FREL

2.0 17/11/2017

4 D1.1 - TD4.2 CREL Ontology (Glossary) 0.5 12/02/2018

6 Co-Active: “WP1 – WP2 Use Case Document” 1.1 16/02/2018

Table 1: Referenced documents


S2R-CoA-WP1-D2.2 31/05/2018

OPERATIONAL ASPECTS 3.

3.1 PRINCIPLES

The Travel Shopping establishes the basis for the Travel Shopping Technical Demonstrator for

SHIFT²RAIL IP4 contributing to its overall objectives. It establishes the architecture for managing

and aggregating distributed travel shopping and distributing journey planning.

It creates the basis for a one-stop shop for intermodal transport products and services whose

combinations can answer to door-to-door mobility queries.

It allows for the presentation of transport service attributes and facilities taking into account

Traveller preferences in connection with carbon footprint and ‘reduced mobility’ needs, among

others.

It interfaces with the “Interoperability Framework” to overcome interoperability obstacles, so

protecting the customer from the fragmentation of messaging and codification standards.

Co-Active will address the following points which are on top of IT2Rail:

• Journey Planning without Offers

• Introduction of new Modes: Shared and Personal Transport

• Itinerary validation

• Co-modal Availability & Pricing


S2R-CoA-WP1-D2.2 31/05/2018

3.2 SCOPE/PURPOSE

Travel Shopping will develop in two main areas, for a simplified possible implementation in

accordance with the Co-Active use case:

• A pre-search set of functions designed to establish the scope of the mobility query, the data

and journey planning expertise to be interrogated, and the setting of various filters and

parameters, to improve the efficiency of the search and to ensure compliance with

Customer preferences;

• The access of distributed data and journey planning expertise, as identified by the pre-

search functions, and their combination to produce a list of available travel solutions

answering to the Customer’s query.

In the pre-search stage, the application makes use of WP1-Location Resolver for decoding of the

mobility query to help build a meta-network of potential origins, destinations and mid-points, most

likely to yield the smartest results. Then it makes use of WP1-Travel Expert Resolver for identifying

the necessary data and journey planning resources to be accessed in order to build the travel

solutions.

The data access and combination stage uses service descriptors retrieved from the WP1 Service

Registry to format the queries according to the annotation attached to the services published by

each Travel Expert / Travel Expert Manager.

In summary, an eco-system of journey planning expertise is configured in real-time for each

Customer query, and interrogated to solve different portions of the Customer’s trip which are then

combined to produce a choice of valid travel solutions.

Some ‘placeholder’ work will be undertaken to establish a skeleton of the additional modules

required for development in Shift2Rail IP4 in order to handle intermodal availability and pricing

logic.

The whole is couched in a Mobility Request Manager component which assures the dialogue with

the Customer and/or his/her Travel Companion from whence the Customer’s shopping cart and

preferences are constructed or accessed, and to whom the final choice of travel solutions are

presented for comparison and selection, upon which Booking & Ticketing takes control for

subsequent booking, payment and ticketing processes.

The entire work is predicated upon the definition of a Travel Shopping Ontology persisting across

each deployable transport mode, and is split between specifications deliverables (benefitting from

multiple contributors’ participation) and implementation deliverables (assigned more pointedly

according to different contributor expertise and experience) in order to deliver the work package

Pilot components as a whole.


S2R-CoA-WP1-D2.2 31/05/2018

3.3 DESIGN DRIVERS

This chapter will present the concepts used by the work package to comply with its scope/purpose

according to the mentioned principles.

3.3.1 Semantic Interoperability

In order to interact with legacy systems Travel Shopping uses the Interoperability Framework.

Therefor all compliant systems need to provide additional information (e.g. an annotation) of their

services.

3.3.2 Service Architecture

The Shift2Rail service architecture promotes the following concepts:

• Service isolation: a provided service should be independent from the rest of the eco-system

• Loose coupling: a modification of a service should not impact or very little the other services

• Contractual interface: a service commits on its interfaces

• Implementation agnostic: a service definition is independent from its implementation.

Shift2Rail being by nature distributed, the use of an architecture based on service provides multiple

advantages. The first one is the possibility to interface legacy systems to the new eco-system with

minimal adaptation. Secondly, service architecture targets seamless integration with loose coupling

providing isolation of existing systems and enabling new business models.

The Shift2Rail specifications does not describe a single operational system but the way multiple

systems/services should cooperate to offer the best service possible to the end-user.


S2R-CoA-WP1-D2.2 31/05/2018

ACTORS AND USE CASES 4.

4.1 ACTORS

This paragraph describes the main actors, who are involved in the Co-Active shopping flow:

• The User is a generic actor for Customer, Traveller and Passenger.

• The Customer is the person who uses the Travel Companion – Personal Application

(TC – PA).

He/she will need to be registered in the TC – PA to be able to use it. Using the TC - PA

could make a mobility request, selects one or several segments (OfferItems from aan Offer)

to create his/her trip and maybe pays the booking (s). The Customer may not be the

Traveller.

• The Traveller is the person who travels from A to B.

The Traveller is using the smart device or physical tokens access to the transport network

and go from A to B through one or more Transport Service Providers services.

In many cases, the Customer and the Traveller will be the same person, though they could be

different people. As the Customer could check the offers for a Mobility request and gets the

Tokens and the Traveller could just use those tokens to travel.

In addition a number of other actors play a role in the Co-Active environment. These roles are

typically based in service providers (e.g. the providers of travel services).

• Travel Expert (TE) (or Transport Service Provider (TSP)) (IT2Rail). This actor provides

travel services (Travel Shopping, Booking & Ticketing, Trip Tracker and Business Analytics)

and corresponding products for purchase (Travel Shopping and Booking & Ticketing).

• Offer Provider (IT2Rail): this actor computes and provides offers, which correspond to the

mobility request of the customer.

• Itinerary Offer Item Provider (IT2Rail): this actor computes and provides parts offer items,

which correspond to a part of the mobility request of the customer. An Offer Provider

combines these items to get aggregated offers.

• Itinerary Provider (CoA: this actor computes and provides itineraries without offers, which

correspond to the mobility request of the customer.

• Itinerary Item Provider (CoA) (IT2Rail: Itinerary Offer Item Provider): this actor computes

and provides parts of itineraries without offer items, which correspond to a part of the

mobility request of the customer. An Itinerary Provider combines these items to get

aggregated iesitineraries.


S2R-CoA-WP1-D2.2 31/05/2018

• Interoperability Framework (IT2Rail): this actor provides the technical means that allow

devices, systems and applications of the eco-system or interacting with it to interoperate.

• Booking & Ticketing (IT2Rail): this actor provides booking and ticketing capabilities for

multimodal itineraries, including booking, issuing, payment, tapping, after sales etc.

• Trip Tracker (IT2Rail): This actor tracks disruptions and allows the traveller to build a new

itinerary.

• Business Analytics (IT2Rail): this actor aims at analyse the behaviour of the Shift2Rail

eco-system. This actor computes KPIs based on usage data.

• Travel Companion (Personal) Application (TC - PA) (IT2Rail): this actor provides a

Graphical User Interface (GUI) to the customer for interacting with the eco-system.

• Travel Companion Cloud Wallet (TC – CW) (IT2Rail): this actor stores all User related

information, e.g. the User’s preferences and the results from shopping.

4.2 CONTEXT

The Travel Shopping is the first step of the interaction with the user for all kind of travels.

The customer interacts with the Travel Shopping through the Travel Companion Application. The

Travel Companion provides the Travel shopping with customer’s mobility requests and with user

preferences and receives from the Travel Shopping a list of itineraries with or without offers

corresponding to each mobility request.

The Travel Shopping relies on the interoperability framework for the location and travel expert

identification and for the interaction with travel experts through the interoperability broker.

The Travel Shopping provides data to the • Booking & Ticketing process (itinerary offer details)

and to the business analytics (itineraries with or without offers) indirectly through the TC Cloud

Wallet.

The Travel Shopping provides the capability to calculate alternatives.

4.3 MISSIONS AND CAPABILITIES

Co-Active Travel Shopping is contributing to the Co-Active Mission and Capabilities.

The following capabilities are already introduced in IT2Rail and will be further developed in Co-

Active:

• CalculateOffers

• CreateMetaNetwork

In addition there are new capabilities introduced by Co-Active:

• CalculateItineraries

• ManageContracts


S2R-CoA-WP1-D2.2 31/05/2018

The main mission of WP1 “Travel Shopping” is:

• Planning and Shopping of “trips”


S2R-CoA-WP1-D2.2 31/05/2018

4.4 USE CASES

List of Use Cases

• UC_TD4.2_Task1.1_01: “Journey Planning of a public transport mode” (at TE level)

• UC_TD4.2_Task1.1_02: “Journey Planning of a shared transport mode” (at TE level)

• UC_TD4.2_Task1.1_03: “Journey Planning of a personal transport mode” (at TE level)

• UC_TD4.2_Task1.1_04: “Intermodal Journey Planning” (from User perspective)

• UC_TD4.2_Task1.1_11: “Provide MetaNetwork” (System view)

• UC_TD4.2_Task1.2_01: “Offer Building of a public transport mode” (at TE level)

• UC_TD4.2_Task1.2_02: “Offer Building of a shared transport mode” (at TE level)

• UC_TD4.2_Task1.2_03: “Offer Building of a personal transport mode” (at TE level)

• UC_TD4.2_Task1.2_04: “Intermodal Offer Building” (from User perspective)

• UC_TD4.2_Task1.2_11: “Provide Business Rules” (System view)

• UC_TD4.2_Task1.2_12: “Manage Business Rules” (System view) For details see the “Use Case Document”.


S2R-CoA-WP1-D2.2 31/05/2018

DESIGN DECISIONS AND CONSTRAINTS 5.

This chapter contains all the design decision that may arise from one work package and that may

affect other work packages.

The Travel Companion Personal Application is able to provide mobility requests to the Travel

Shopping. The Trip Tracker is able to provide a request for the calculation of alternatives using a

mobility request.

The Customer has to use the Travel Companion Personal Application to specify his mobility

request.

Travel Experts provide time table data in order to allow building the MetaNetwork (e.g. GTFS)

through the Interoperability Framework (TD4.1).

Travel Shopping and TE are interacting through the Interoperability Framework (TD4.1).

The Mobility Request Manager stores the shopping context (itineraries or itinerary offers) at the

TC–CW.

All Business Rules between TEs are modelled by using the CMMP. The TSA will use the BR in

order to build Itineraries and Itinerary Offers during the Shopping time.

Table 2: Design decisions table


S2R-CoA-WP1-D2.2 31/05/2018

FUNCTIONAL ASPECTS 6.

In order to provide a seamless purchasing experience for all aspects of travel shopping, a set of

functions are required that manage and aggregate distributed travel shopping data and distributed

Journey Planning and Offer Building expertise.

6.1 COMPONENTS

The Travel Shopping main components are:

• The TS Travel Shopping: this component aggregates the elements of a travel solution to

compose full itineraries with or without offers;

• The TS Travel Expert (TS TE) : this component provides the Travel Shopping with all

needed information for a single TE regarding the TE capabilities.

• Contractual Management Market Place (CMMP): this component manages and provides

business rules between travel experts.

Figure 1: Components overview for TD4.2 Travel Shopping

6.1.1 TS Travel Shopping Components

The TS Travel Shopping component is decomposed into four components:

• The Mobility Request Manager (IT2Rail)

o Interface to the TC–PA

o Collect the traveller preferences from the TC–CW and combines it with the SearchOptions

o Invokes the SO

o Stores the Itineraries and Offers at the TC-CW

• The Shopping Orchestrator (IT2Rail)

o Manage the shopping flow by calling the LR, MNE, TER and TSA

• The Meta Network Builder (IT2Rail: TS Build Network Reference Resource)

o Computes the Meta Network out of (condensed) time table data from all TE

• The Meta Network Explorer (IT2Rail: Meta Route Explorer)


S2R-CoA-WP1-D2.2 31/05/2018

o Calculates the Meta Routes

• The Travel Solution Aggregator (CoA) (IT2Rail: Offer Builder) incl. Business Rules Engine (BRE) and Broker Interface (BI):

o Creates the request for Itinerary Items / Itinerary Offer Items

o Applies the BR (BRE)

o Interfaces TE through the Broker (BI)

o Put the Itinerary Items / Itinerary Offer Items together to Itineraries / Itinerary Offers

Figure 2: Subcomponents of the Travel Solution Aggregator

6.1.2 TS Travel Expert Components

The TS Travel Expert component is decomposed into three components:

• The TS TE Network Provider (IT2Rail: Travel Expert Journey Planner)

o Provides time table information in order to build the Meta Network

• The TS TE Offer Builder (IT2Rail)

o Calculates Itinerary Offer Items

• The TS TE Journey Planner (CoA)

o Calculates Itinerary Items

6.1.3 Contractual Management Market Place (CMMP)

The CMMP component manages business rules that govern the business relationship between

TEs.

6.2 FUNCTIONS

The TS Travel Shopping is responsible of the Itinerary and Itinerary Offer computation. This computation is based on the following functions and corresponding components:

• CalculateItineraries (Mobility Request Manager): this function is called by the Travel

Companion to send the mobility request in order to calculate itineraries (without offers). It

aims at preparing the mobility request especially to handle the user preference before the

itinerary computation. It gets the mobility request from the Travel Companion application


S2R-CoA-WP1-D2.2 31/05/2018

and retrieves the customer preferences from the Travel Companion Cloud Wallet. The

Mobility Request Manager then provides the mobility request and the associated customer

preferences to the Shopping Orchestrator.

At the end of the shopping flow, the Mobility Request Manager provides the list of

Itineraries to the TC-PA (TD4.5) and the TC-CW (TD4.5).

• CalculateOffers (Mobility Request Manager): this function is called by the Travel

Companion to send the mobility request in order to calculate ItineraryOffers. It aims at

preparing the mobility request especially to handle the user preference before the itinerary

computation. It gets the mobility request from the Travel Companion application and

retrieves the customer preferences from the Travel Companion Cloud Wallet. The Mobility

Request Manager then provides the mobility request and the associated customer

preferences to the Shopping Orchestrator. At the end of the shopping flow, the Mobility

Request Manager provides the list of ItineraryOffers to the TC-PA (TD4.5) and the TC-CW

(TD4.5).

• CalculateItineraries (Shopping Orchestrator): this function is called by the MRM in order

to calculate itineraries (without offers). It aims at managing the shopping flow and at

coordinating all shopping modules. This function interacts with the Interoperability

Framework functions ResolveLocation and ResolveTravelExpert.

• CalculateOffers (Shopping Orchestrator): this function is called by the MRM in order to

calculate itinerary offers. It aims at managing the shopping flow and at coordinating all

shopping modules. This function interacts with the Interoperability Framework functions

ResolveLocation and ResolveTravelExpert.

• FindMetaRoutes (Meta Network Explorer): this function is called by the SO and aims at

defining the most relevant corridors, which are joining the origin and the destination

specified in the mobility request.

• CreateMetaNetwork (Meta Network Builder): this function works regularly and

asynchronously to the shopping flow and is based on (condensed) time table data (e.g. in

GTFS format) provided by each travel expert. This function aims at aggregating this data to

generate a single Meta Network.

• GetMetaNetwork (Meta Network Builder): this function is called by the MNE and provides

the Meta Network.

• BuildItineraries (Travel Solution Aggregator): this function this function is called by the

SO and aims at building itineraries (without offers) using itinerary items provided by

itinerary item providers.

• BuildOffers (Travel Solution Aggregator): this function is called by the SO and aims at

building itinerary offers using itinerary offer items provided by itinerary offer item providers.


S2R-CoA-WP1-D2.2 31/05/2018

Figure 3: Work flow of WP1 Travel Shopping

The TS Travel Expert component provides the following functions:

• GetNetworkData (TS TE Data Provision): this function provides time table data for the

construction of the Meta Network.

• CalcultaItineraryItems (TS TE Journey Planner): this function provides itinerary items

corresponding to the request coming from the TSA through the Interoperability Framework.

• CalcultaItineraryOfferItems (TS TE Offer Builder): this function provides itinerary offer

items corresponding to the request coming from the TSA through the Interoperability

Framework.

The CMMP component is decomposed into these functions:

• Register (CMMP): allows TE to register at the CMMP.

• ManageTE (CMMP): manages (create, delete, update, …) TE that could have an agreement with another TEs to agree on business rules.

• ManageAgreement (CMMP) manages initial agreements between 2 or more TEs.

• ManageContract (CMMP): manages signed agreements (contract) between 2 or more TEs.


S2R-CoA-WP1-D2.2 31/05/2018

• GetBusinessRules (CMMP): provide the business rules generated after a specific date.


S2R-CoA-WP1-D2.2 31/05/2018

6.3 FUNCTIONAL ARCHITECTURE

The Travel Shopping process involves some functions, which are provided by other TDs:

TD Used functions

Interoperability

Framework

This service is involved in the following use cases:

• Resolver Services

o ResolveLocation

o ResolveTravelExpert

• Semantic Broker

o GetNetworkData

o CalculateItineraryItems

o CalculateItineraryOfferItems

Travel Companion –

Cloud Wallet

This service is involved in the following use cases:

• GetPreferences

• StoreItineraries

• StoreItineraryOffers

Table 3: Travel Shopping used functions of other TDs


S2R-CoA-WP1-D2.2 31/05/2018

CAPABILITIES: FUNCTIONAL SCENARIO 7.

7.1 PRESENTATION

This section synthesizes all the capabilities of the Travel Shopping process. These specifications are written following the use cases methodology. Each use case is described with text and sequences diagram(s). The data exchanged across the actors and systems are then described in detail in the Interface specification document.

At this stage, only the “nominal / normal” scenarios are described in this release of this specification document. Failure cases will be described in a later release.

The following capabilities are handled in Co-Active WP1 Travel Shoping:

• CreateMetaNetwork

• CalculateItineraries

• CalculateOffers

• ManageContracts

7.2 CAPABILITIES SPECIFICATIONS

7.2.1 CreateMetaNetwork

The Meta Network is generated asynchronously using (condensed) timetable data provided by each Travel Experts..

This scenario uses the following functions:

• IF Resolver Service: Travel Expert Resolver

• IF Semantic Broker: GetNetworkData

• TE Data Provision: GetNetworkData (indirectly): Provide time table data of a Travel Epxert

for the MetaNetworkBuilder

This scenario realizes the following functional exchanges of the Shopping functions:

• CreateMetaNetwork: Starts the computation of the MetaNetwork.

• GetMetaNetwork: Provides the latest instance of the MetaNetwork.

7.2.2 CalculateItineraries

This scenario describes the shopping process: the customer specifies a mobility request through the TC-PA and gets as reply a list of Itineraries corresponding to the mobility request.

This scenario realizes the following functional exchanges of the Travel Shopping functions:

• The MobilityRequestManager makes use of the following functions:


S2R-CoA-WP1-D2.2 31/05/2018

o GetPreferences (TC-CW);

o CalculateItineraries (SO);

o StoreItineraries (TC-CW).

• The ShoppingOrchestrator makes use of the following functions:

o ResolveLocations (IF Resolver);

o findMetaRoutes (MNE);

o ResolveTravelExpert (IF Resolver);

o BuildItineraries (TSA).

• The TravelSolutionAggregator makes use of the following functions:

o CalculateItineraryItems (IF Broker);

o GetBusinessRules (CMMP);

7.2.3 CalculateOffers

This scenario describes the shopping process: the customer specifies a mobility request through the TC-PA and gets as reply a list of itineraryOffers corresponding to the mobility request.

This scenario realizes the following functional exchanges of the Travel Shopping functions:

• The MobilityRequestManager makes use of the following functions:

o GetPreferences (TC-CW);

o CalculateItineraryOffers (SO);

o StoreItineraryOffers (TC-CW).

• The ShoppingOrchestrator makes use of the following functions:

o ResolveLocations (IF Resolver);

o findMetaRoutes (MNE);

o ResolveTravelExpert (IF Resolver);

o BuildItineraryOffers (TSA).

• The TravelSolutionAggregator makes use of the following functions:

o CalculateItineraryOfferItems (IF Broker);

o GetBusinessRules (CMMP);

7.2.4 ManageContracts (CMMP)

This module manages business rules that govern the relationship between the travel services providers (TEs). It formalizes standard agreements on a marketplace, build upon the Shift2Rail specifications. It generates formal contracts, which involve the agreements, business rules and financial compensation that shall occur between the different stakeholders.


S2R-CoA-WP1-D2.2 31/05/2018

The module is based on TEs publishing offers that other TEs accept, building a contractual relationship that combines their services, generating a final offer for the user. This is also a first stage towards the definition of the contractual aspect of the co-modal journey that will be addressed in the coming calls. The CMMP provides the following functionalities to Travel Experts in order to configure and generate new contracts. These functionalities will be accessible by the CMMP Portal Web:

• Register

• ManageTE

• ManageAgreements (create, get, accept, reject, update and delete)

• ManageContracts (generate when the agreement was accepted and creates Business Rules)

In order to provide the Business Rules reflected wihtin the contracts, the CMMP system provides the following functionalities:

• GetBusinessRules


S2R-CoA-WP1-D2.2 31/05/2018

FUNCTIONAL EXCHANGES 8.

8.1 FUNCTIONAL EXCHANGE DETAILS

This chapter will details of each functional exchange at the FREL version.

8.2 DATA MODEL

This chapter will contain the functional / conceptual data model at the FREL version.

8.3 INTERFACES

This chapter will specify the interfaces of the functions at the FREL version.

End-of-document