TAP TSI Masterplanning Item 3:

TAP TSI Masterplanning Item 3: Company individual implementationplans – definitions, objectives, timelines … Masterplanning Kick-off Brussels, 25 September 2012

Agenda • Introduction - Background • Obligations related to the implementation of Commission Regulation (EU) No 454/2011 • TAP master plan and company individual implementation plans: definitions, objectives, timelines, tools and baseline documents • Introduction • Retail obligations • Retail architecture • RU/ IM obligations and architecture • Organisational matters • Relation to existing TAF master plan (implementation of Commission Regulation (EC) 62/2006) • Adjournment

Retail RU/ IM (Closely linkedwith TAF TSI) The TAP TSI regulation consists of Basic Parameters (provisions) relating to both Retail data and RU/IM communication Annex III:ERA TechnicalDocuments(TDs) withIT specs 4.2.x = Basic Parameters (BP) of the Regulation

TAP TSI will be implemented in three phases – concepts and specs were delivered mid-May 2012 by the multi-stakeholder Phase One project Implementation Phases Phase One:Preparation Phase Two:Development Phase Three: Deployment  May 2011 13 May 2012 Approx mid-2014 tbd • Multi-stakeholder Steering Committee,co-chaired by EU Commission and sector • Core Project Team of railway and ticket vendor representatives, operational since July 2011 • Railways, infrastructure managers and ticket vendor experts in supporting work groups • Commission co-funding, ongoing monitoring by European Railway Agency (ERA) • Main deliverables: • Detailed IT specifications, architecture concept • Governance concept • Best estimate master plan Milestones: • Monthly: Progress report1 • 13 November 2011:RUs to publish certain information on their websites • 8 December 2011: Intermediate report1 • 13 May 2012: Deliverables submitted1 • Over the summer 2012:ERA recommendation on deliverables to Commission 1) Available on http://tap-tsi.uic.org

Phase One deliverables in a nutshell • Enrichment of TAF TSI concepts with passenger RU requirements • De-centralised IT architecture, based on legacy • Limited new but relatively inexpensive common IT • Lean governance entity providing central services needed for regulatory compliance • Common IT components for retail available approx early 2016; already available for RU/IM • Time for stakeholders to prepare thoroughly: Railways to assess their individual timelines in Q4 2012 • Better mutual understanding of traveller, ticket vendor and railway requirements • Agreement for private industry follow-up activities complementing the regulatory framework Phase One deliverables

Overall TAP TSI masterplan as delivered by the Phase One project

By the end of this year railways will have to provide their plans when they will be compliantwith the Regulation. Implicated railways now need to establish their individual implementation plans • The TAP TSI Regulation requires RUs and IMs to prepare an implementation plan • The plan has to show when each of the obligations in the Regulation will be met – when the RU or IM will be compliant • The Phase One project has defined in detail how the obligations can be met by RUs and IMs • It is therefore possible for individual RUs and IMs to prepare their plans with confidence • These plans are to be assembled by the Phase Two project into a consolidated plan • The consolidated plan will be used by the project to monitor progress during implementation

TAP TSI reference documents Reg. 454/2011 Other documents1 • ERA Technical Documents • B.1 Timetables • … • B.10 PRM2assistance booking • Directory of passenger code lists • Implementation Guides (IT3specs) • Timetables • Tariffs • Reservation • Direct fulfilment • Indirect fulfilment • PRM assistance booking Text Annex I … Ann. IV Ch. 1 … Ch. 4 … Ch. 8 Characterisation of the subsystem 4.1 4.2 4.8 Functional and technical spec. of the subsystem • Can be found on: • http://www.era.europa.eu/Document-Register/Pages/TAP-TSI.aspx (versions prior to ongoing Change Control process) • http://tap-tsi.uic.org/What-s-new,4.html Retail Basic Parameters 4.2.1 … 4.2.11 … 4.2.22 (2) Persons with Reduced Mobility (3) Information Technology

TAP TSI retail obligations overview (1) Numbers refer to subdivisions of chapter 4.2 (2) Ticketing on Departure, Manifest on List (3) Railway Undertaking

Obligations concerning Timetables(for details see Timetables IG on http://tap-tsi.uic.org/What-s-new,4.html) Reference docs: TD (1) B.4, Timetable IG (2) Unconditional Make available (not send) schedules data and stations data Both files (SKDUPD and TSDUPD) in EDIFACT Make available to all stakeholders (not to public) Include all services, also buses and ferries if existing Services operated by the RU alone or jointly with others Annual timetable 2 months before change date, if sole control Intermediate changes 7 days in advance, if known Keep available expired data for 12 months IG defines how to deal with special cases (1) Technical Document (2) Implementation Guide

Obligations concerning Tariffs(for details see Tariffs IG on http://tap-tsi.uic.org/What-s-new,4.html) • Reference docs: TDs B.1, B.2, B.3, Tariff IG • Immediate obligation concerns international or foreign sales • Conditional, only if international or foreign sales allowed • When open point is closed, domestic sales unconditional • Make available (not send) tariffs and fares • Tariffs are terms & conditions, fares are prices • 3 types of tariffs: NRT (1), IRT (2), Special Offers • Each type consists of a set of flat text files • Make available to all PAs (3) + authorised RUs and TVs (4) (not to public) • NRT data to be made available 3 months before application • IRT and Special Offers data according to commercial rules (1) Non-integrated Reservation Ticket (2) Integrated Reservation Ticket (3) Public Authority (4) Ticket Vendor

Obligations concerning Reservation(for details see Reservation IG on http://tap-tsi.uic.org/What-s-new,4.html) • Reference docs: TD B.5, Reservation IG • Conditional, only if RU offers or requests reservations • Full commercial freedom (what to offer and to whom) • Concerns transport of persons, cars, bicycles • Only reservation or reservation included in ticket (IRT) • Implies the existence of a requesting system and an attributing one • Each RU can play one or both (or none) of those roles • B.5 defines a standard set of messages, but different ones can be used on bilateral agreement • B.5 messages are bit oriented, IG explains how to build them with detailed examples

Obligations concerning Fulfilment (for details seeIndFulfiment & DirFulfilment IGs on http://tap-tsi.uic.org/What-s-new,4.html) • Reference docs: TD B.6, B.7, Direct fulfilment IG, Indirect fulfilment IG • Immediate obligation concerns international or foreign sales • Conditional, only if international or foreign sales allowed • When open points are closed, domestic sales unconditional (?) • Full commercial freedom (what to offer and to whom) • Direct fulfilment makes use of value paper (guarantee background) • B.6 defines a standard set of ticket layouts, but different ones can be used on bilateral agreement • 3 types of indirect fulfilment foreseen : A4, ToD, MoL • ToD and MoL still open points, only A4 defined in B.7 • 3 possible implementation methods for A4, RU can choose one

Obligations concerning PRM assistance(for details see PRM Assistance IG on http://tap-tsi.uic.org/What-s-new,4.html) • Reference docs: TD B.10, PRM assistance booking IG • Conditional, only if IT is used for exchange of assistance requests • Subject to agreement between requester and provider of assistance • Providers can be other RU or IM (1) or SM (2) • Accepted assistance requests must be given a reference number to be communicated to the customer • B.10 defines a standard set of messages for dialogue between requester and provider, but different ones can be used on bilateral agreement • B.10 messages are in XML (3) (1) Infrastructure Manager (2) Station Manager (3) eXtended Markup Language

Global Architecture The architecture requirements are defined in one of the Basic Parameters of the Regulation Retail RU/ IM (Closely linked with TAF TSI) 4.2.x = Basic Parameters (BP) of the Regulation

Retail Architecture requirements in the Regulation “Outline of the global architecture of the system based on the analysis of the system configurations capable of integrating the legacy IT facilities (…)” Basic Parameter 4.2.21.1 The network and communication infrastructure supporting such a rail interoperability community will be based on a common ‘Information Exchange Architecture’, known and adopted by all those participating in it. The proposed ‘Information Exchange Architecture’: • is designed to reconcile heterogeneous information models by semantically transforming the data that are exchanged between the systems and by reconciling the differences in business processes and application- level protocols, • has a minimal impact on the existing IT architectures implemented by each actor, • safeguards IT investments already made.

Designing the architecture involved multiple stakeholders The following architecture has been designed with the active participation of experts from Railway Undertakings and Ticket Vendors. 36 representatives of Railway Undertakings1 and Ticket Vendors2 participated in 11 architecture workgroup sessions and intermediate work. 1) UIC members2) ETTSA and ECTAA members

Information Exchange Architecture description All data types are considered as Resources (timetables, fares, reservations…) Distributed solution: the architecture is based on Resource Producers (RUs) and Resource Consumers (RUs, TVs, PAs)exchanging data directly between themselves, not through a central service nor using a common interface A Registry provides accurate and essential information so that Consumers know where the resources are located Three components constitute the common services of the architecture: • A Registry keeps track of all the resources, acting as an address book • A Data Quality Management tool is available to ensure Timetables and Fares Resources are of good quality • The Retail Reference Data provide locations, code lists, company and country codes to all

The Registry can answer to the following type of questions: “Where and how can I get Estonian Railway’s timetable data?” “Where and how can I get Eurostar’s IRT fare data?” “What is the commercial contact for RENFE” 1) Common Component: Registry • The registry has a list of consumers that are interested in given resources (notification service) • Each time a Producer updated a resource, it notifies the Registry • The Registry will in turn notify the subscribed Consumers • This component is new: it will be created and procured, managed by the governance entity once created

Helps Producers to ensure Timetable and Fares/Tariffs Resources are compliant with expected quality criteria of TAP Relies on quality rules listed in Implementation Guides Gives guidance to Producers on detected errors Gives Consumers the possibility to double-check quality of Resources 2) Common Component: Data Quality Management (DQM) tool

Hassle-free access to reference data: RRD will offer a simple interface to Resource Producers and Consumers: Hiding the difficulties to get those data from different sources Ensuring consistencies when data are used in different areas Delivering the most updated data Controlling access by a single sign-on per User Triggering the notification service of the Registry after changes 3) Common Component: Retail Reference Data (RRD)

Governance Entity will procure the three common components Architecture related activities in Phase Two comprise: Tender launch Provider(s) selection Development of Common Components User acceptance test Future governance of Common Components

TAP Phase Two is also about: Development by RUs in order to have their systems compliant with the Regulation User acceptance test by RUs with the 3 common components Access to Registry to inform of any changes in Resources Access to RRD Access and Use of DQM Use of the notification service to automate the downloading of selected Resource updates RU activities regarding the Common Components

New Retail Reference Data Location codes • Company codes Country codes Passenger code Lists RRD RU FTP FTP FTP DataQualityMgt. DQM FTP Registry FTP FTP FTP FTP FTP FTP RU RU RU RU3 RU4 RU5 RU6 RU7 RU2 RU1 Summary: TAP TSI Retail Architecture –A distributed solution with three common components PA TV 1 TV 2 FTP FTP FTP IP Network RU = Railway Undertaking TV = Ticket Vendor (3rd party) PA = Public Authority

TAP RU/ IM functions take into account different stakeholders than TAF, with an overlap on the IM side The goal of TAP RU/ IM standards is providing interoperability… … for Passengers … for Rail Companies • Providing passengers with important travel information on all rail journeys  This is different to TAF • Involved actors: • Infrastructure Managers • Passenger RUs • Station Managers • Railway companies can – with the same standards for domestic and interoperable services - • order train paths • control and manage their train services • improve passenger information • Station Managers (SMs) in the sense of TAP are entities responsible for passenger information in the stations • SMs and Passenger RUs are actors that fall under TAP and have had limited or no implication by TAF

TAP RU/ IM functions are close to TAF RU/ IM Communication Overview of TAP RU/ IM functions Functions Content Relation to TAF • Dialogue between RU and IM to order or modify paths • Very close to TAF Short Term Path Requests • Info from RU to IM that train is ready/not ready • Close to TAF • Other TAF functions not relevant1 Train Preparation • Info from IM to RU and SM about punctuality • Close to TAF • Involving SMs • Other TAF functions not relevant2 Train Running Info + Forecast • Info from IM to RU/SM that train stopped and continuation is unclear • Close to TAF • Triggers further communication Service Disruption 1) TAF functions for Train Preparation not relevant for TAP: Train Accepted, Train Composition, Train Not Suitable, Train Position, Train at Start 2) TAF functions for Train Running not relevant for TAP: all Enquiries and Enquiry Responses

TAP RU/ IM functions are clustered for the MasterplanningDescription in the Regulation and the Implementation Guide Reference of TAP RU/ IM functions Reference TAP Regulation RU/IM Implementation Guide1 • BP 4.2.17 • Chapter 12 Short Term Path Requests • BP 4.2.14 • Chapter 13 Train Preparation • BP 4.2.15 • Chapter 14, 18 Train Running Info + Forecast • BP 4.2.16 • Chapter 15, 18 Service Disruption • The RU/IM IG contains a “Who should read what”-section that is advised to be consulted. All general chapters (Part A and D) should be read for all clusters. The RU/IM Implementation Guide is available at http://tap-tsi.uic.org/IMG/pdf/20120629_tap_ru_im_implementation_guide_v53c.pdf

Some TAP RU/ IM functions are new and not relevant for TAF Additional TAP RU/ IM functions Functions Content Relation to TAF • Info from IM to RU/ SM about platform • Passenger information; not relevant for TAF Change of Track • Info during operation from IM/ RU to SM that train is rerouted, cancelled etc. • Passenger information; not relevant for TAF Train Journey Modified • Info from SM to customer (content only) • Passenger information; not relevant for TAF Info in stations • Info from RU to passenger (content only) • Passenger information; not relevant for TAF Info in vehicles

TAP RU/ IM functions are clustered for the MasterplanningDescription in the Regulation and the Implementation Guide Reference to TAP RU/ IM functions Reference TAP Regulation RU/IM Implementation Guide1 • BP 4.2.12 • Chapter 16, 19 Change of Track • BP 4.2.12 • Chapter 17, 19 Train Journey Modified • BP 4.2.12 • Chapter 19 Info in stations • BP 4.2.13 • Chapter 19 Info in vehicles 1) The RU/IM IG contains a “Who should read what”-section that is advised to be consulted. All general chapters (Part A and D) should be read for all clusters.

Standard interfaces to allow communication between stakeholdersvia standard data networks General architecture of the RU/IM communication illustrative RU 1 RU 2 CUS IM = Infrastructure Manager RU = Railway Undertaking SM= Station Manager CI CI CI IM 1 CI = Common Interface CUS = Commonly Used System CI IP Network CI Common Reference data. • Location-ID • Company-ID CI CI IM 2 CI RU 3 SM 1

TAP RU/ IM prerequisites are very close to TAF TSI Overview of TAP RU/ IM prerequisites Functions Content Relation to TAF • Data on Locations, Countries, Companies • Very close to TAF Reference Files • Tools to allow interoperable message exchange • CCG CI is available • Individual solutions possible1 Common Interface • Unambiguous identification for IT applications • Not replacing rail operational numbers • Phased approach using existing identifiers is developed in collaboration with TAF2 Train Identifiers • Availability of rules for standards and common elements • Not specified yet Governance 1) Companies can implement own solutions conform to the reference CI, allowing the exchange of TAP messages 2) Start using TAP messages with existing identifiers, move towards technical identifiers as developed by TAF, partners need to agree on migration

TAP RU/ IM prerequisites are very close to TAF TSI Reference to TAP RU/ IM prerequisites Reference TAP Regulation RU/IM Implementation Guide1 • BP 4.2.19 • Chapter 9 Reference Files • BP 4.2.21 • Chapter 6 Common Interface • n/a • Chapter 8 and Train ID handbook2) Train Identifiers • n/a • Chapter 23 Governance • The RU/IM IG contains a “Who should read what”-section that is advised to be consulted. All general chapters (Part A and D) should be read for all clusters. • The Train ID Handbook is available at http://www.uic.org/IMG/pdf/111122_wg_10_handbook_final.pdf

Reference data is technically speaking done centrally, but code allocation needs to be organised per country Questions mainly for Infrastructure Managers and National Contact Points • When will your company/country • identify the Code Allocation Entity in your country ? proposed is that the largest IM in a country should execute this role or take care that this role is defined within their country • be able to populate the reference file ? • sign up to be registered on Reference File System (CRD) to execute tests ?https://crd.tsi-cc.eu/CRD/onlineUser/signUp.action

The RU/IM Implementation Guide together with the message catalogue is the main result of Phase One and the basis for implementation

Specifications • TAP RU/ IM standards have been finalised by May 2012; going through CCM now Usability • Ability of companies to use the standards needs to be known via TAP Masterplan Commercial solutions outside the TAP legal framework are being prepared by some sector organisations Availability of support from stakeholder groups Commercial/voluntary support of activities outside the legal TSI frame • Related initiatives such as PCS1 can support IMs and RUs on a voluntary basis • Activities to implement TAP in these initiatives will take place after the final specifications and the ability of users become clear • The reference implementation of the Common Interface is available and can be used. More information: ccg-dt@uic.org 1) Path Co-ordination System

Future: Both mandatory RU/IM work to fulfil the regulation as well as useful work to fulfil stakeholder requirements will start immediately A common TAP and TAF RU/ IM Work Stream will deal with these topics. The results will add to the existing baseline/standards. Sector driven Regulation driven • Create a wagon ordermessage for passenger information • This is relevant for TAP only • Enhance work on Train Identification (see also previous slide) • Create technical messages needed for TAF and TAP • to accommodate passenger specific requirements • Check the external specifications of the reference implementation of the CI (CCG CI). Relevant for TAF and TAP • Clarify stakeholder questions on deliverables • Check/enhance messages for Short Term Path Request for • Annual Path Requests • One Stop Shops • Coach Group (through coaches) • Code list maintenance Most points are valid forboth TAF and TAP

Reference documents for RU/IM communication The following links host the reference documents for RU/IM communication • RU/IM Implementation Guide http://tap-tsi.uic.org/IMG/pdf/20120629_tap_ru_im_implementation_guide_v53c.pdf • Annexes to the RU/IM Implementation Guide http://tap-tsi.uic.org/What-s-new,4.html • Train ID handbook http://www.uic.org/IMG/pdf/111122_wg_10_handbook_final.pdf The following links host additional information or orientation from TAF Masterplanning with RU/IM relevance • TAF Masterplan results http://www.era.europa.eu/Document-Register/Documents/TAF-TSI%20Preliminary%20Master%20Plan.pdf • General TAF links and information http://www.uic.org/spip.php?article446

Passenger RUs need to consider two parts of the implementation plan One will be for RU/IM and will be linked to the TAF plan; passenger RUs are therefore advised to check the existing RU/IM plan with the IMs who they use and judge if it is suitable or not for them The other will be for Retail and will be a TAP only plan Passenger RUs can develop their own retail implementation plans independently of other RUs IMs may consider re-using the timelines submitted to the TAF masterplan, including the TAP-only functions Masterplanning principles

Each RU and IM needs to set up a TAP TSI implementation planning project and to nominate a point of contact Resources need to be allocated by the RU or IM so that the planning project can start now and can be completed by the end of 2012 The RU or IM point of contact needs to know what is to be done After today’s meeting, the TAP TSI project team will be able to provide some support to RU and IM single points of contact Documentation and advice will be provided on the project website http://tap-tsi.uic.org/What-s-new,4 If required, Q&A sessions on planning completion can be run Available dates are 6/7, 15/16 November (locations tbd) Member States will also provide information on the regulatory requirements What do RUs and IMs need to do? What support will be provided?

Railways are asked to document the outcome of their individual implementation planning in an Excel template (available on website) Company & company details Structured documentation of individual timelines Each area of regulatory obligation is specified Reference document/ chapters

The TAP Phase One project deliverables provide sufficient information for RUs and IMs to do their individual implementation planning The return of individual plans is due by 31 December 2012 If you would like to attend a Q&A session or have any queries, please send a request to the project team at tap-masterplanning@uic.org Review and consolidation of plans will take place in early 2013 Essentially project team task, with on-demand interaction with respondents Supervision and guidance by TAP TSI Steering Committee The consolidated plans will be delivered to the Commission by30 April 2013 TAP TSI implementation plan project timetable

Most incumbent Passenger RUs are already exchanging data as defined in the ERA Technical Documents It has been assumed in the Phase One plan that these RUs can be largely compliant by 2016 Where this date cannot be met by an RU this will normally be for a reason permitted in the Directive 2008/57 Member States will be requested to ensure their licensed RUs are compliant according to the Directive The Governance entity will record the positions stated by RUs as regards compliance with the Basic Parameters It will also provide support to RUs through the provision of regulatory services Retail implementation monitoring

Full compliance of RU/IM obligations will take several years The European TAP TSI project team will not be responsible for or be able to direct individual RUs or IMs The European TAP TSI project team will record the positions stated by RUs and IMs as regards compliance with the Basic Parameters It will also provide support to RUs and IMs through the provision of regulatory services RU/IM implementation monitoring

Masterplanning timeline allows for assistance to companies inproducing solid plans with a possibility for alignment with partners (1/2) Milestones for companies’ individual planning 2012 Today • Informing RUs, IMs, SMs about work • Start of planning within each company (each RU, IM, SM) Kick-off25 Sep. 2012 • 1st Q&A session for companies’ experts, focus on TAP Retail obligations (suggestion) 6/7 Nov. 2012 • 2nd Q&A session for companies’ experts, focus on TAP RU/IM obligations (suggestion) 15/16 Nov. 2012 • Each company submits a solid, near-final plan to the European TAP project team. Timelines given shall be the realistic times of the company 31 Dec. 2012

Milestones for companies’ individual planning 2013 Masterplanning timeline allows for assistance to companies inproducing solid plans with a possibility for alignment with partners (2/2) • TAP team issues first analyses of individual companies input • Actors that are (potential) partners get input for potential alignment 31 Jan. 2013 • Each company submits the final, binding individual companies implementation plan (that might be different to the December version due to alignment with partners) 5 Apr. 2013 • European TAP project team – following clearance by TAP TSI Steering Committee – submits final overall plan to DG MOVE, taking individual companies plans into account 30 Apr. 2013

Summary of roles and responsibilities: TAP actors with obligations need to deliver a company individual implementation plan TAP masterplanning roles Note: Actors might play more than one role or have overlapping competencies.

TAP TSI Masterplanning Item 3: