D1.2 – WP1 Specifications CREL
Transcript of D1.2 – WP1 Specifications CREL
Grant Agreement No. 730846
S2R-CoA-WP1-D2.2 Page 1 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
Grant Agreement No. 730846
S2R-CoA-WP1-D2.2 Page 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.
Grant Agreement No. 730846
S2R-CoA-WP1-D2.2 Page 3 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.
Grant Agreement No. 730846
S2R-CoA-WP1-D2.2 Page 4 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
Grant Agreement No. 730846
S2R-CoA-WP1-D2.2 Page 5 31/05/2018
8.2 Data Model .......................................................................................................................... 28
8.3 Interfaces ............................................................................................................................ 28
Grant Agreement No. 730846
S2R-CoA-WP1-D2.2 Page 6 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
Grant Agreement No. 730846
S2R-CoA-WP1-D2.2 Page 7 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
Grant Agreement No. 730846
S2R-CoA-WP1-D2.2 Page 8 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)
Grant Agreement No. 730846
S2R-CoA-WP1-D2.2 Page 9 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.
Grant Agreement No. 730846
S2R-CoA-WP1-D2.2 Page 10 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
Grant Agreement No. 730846
S2R-CoA-WP1-D2.2 Page 11 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
Grant Agreement No. 730846
S2R-CoA-WP1-D2.2 Page 12 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.
Grant Agreement No. 730846
S2R-CoA-WP1-D2.2 Page 13 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.
Grant Agreement No. 730846
S2R-CoA-WP1-D2.2 Page 14 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.
Grant Agreement No. 730846
S2R-CoA-WP1-D2.2 Page 15 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
Grant Agreement No. 730846
S2R-CoA-WP1-D2.2 Page 16 31/05/2018
The main mission of WP1 “Travel Shopping” is:
• Planning and Shopping of “trips”
Grant Agreement No. 730846
S2R-CoA-WP1-D2.2 Page 17 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”.
Grant Agreement No. 730846
S2R-CoA-WP1-D2.2 Page 18 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
Grant Agreement No. 730846
S2R-CoA-WP1-D2.2 Page 19 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)
Grant Agreement No. 730846
S2R-CoA-WP1-D2.2 Page 20 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
Grant Agreement No. 730846
S2R-CoA-WP1-D2.2 Page 21 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.
Grant Agreement No. 730846
S2R-CoA-WP1-D2.2 Page 22 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.
Grant Agreement No. 730846
S2R-CoA-WP1-D2.2 Page 23 31/05/2018
• GetBusinessRules (CMMP): provide the business rules generated after a specific date.
Grant Agreement No. 730846
S2R-CoA-WP1-D2.2 Page 24 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
Grant Agreement No. 730846
S2R-CoA-WP1-D2.2 Page 25 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:
Grant Agreement No. 730846
S2R-CoA-WP1-D2.2 Page 26 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.
Grant Agreement No. 730846
S2R-CoA-WP1-D2.2 Page 27 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
Grant Agreement No. 730846
S2R-CoA-WP1-D2.2 Page 28 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