2011R0454 — EN — 08.12.2013 — 002.001

---

This document is meant purely as a documentation tool and the institutions do not assume any liability for its contents

►B	COMMISSION REGULATION (EU) No 454/2011 of 5 May 2011 on the technical specification for interoperability relating to the subsystem ‘telematics applications for passenger services’ of the trans-European rail system (Text with EEA relevance) (OJ L 123, 12.5.2011, p.11)

Amended by:

		Official Journal
		No	page	date
M1	Commission Regulation (EU) No 665/2012 of 20 July 2012	L 194	1	21.7.2012
►M2	Commission Regulation (EU) No 1273/2013 of 6 December 2013	L 328	72	7.12.2013

---

▼B

COMMISSION REGULATION (EU) No 454/2011

of 5 May 2011

on the technical specification for interoperability relating to the subsystem ‘telematics applications for passenger services’ of the trans-European rail system

(Text with EEA relevance)

Article 1

1.  The Technical Specification for Interoperability (hereinafter ‘TSI’) relating to the element ‘applications for passenger services’ of the subsystem ‘telematics applications’ of the trans-European rail system referred to in Article 6(1) of Directive 2008/57/EC is set out in Annex I.

2.  The TSI shall apply to the element ‘applications for passenger services’ of the subsystem ‘telematics applications’ as defined in Section 2.5 of Annex II to Directive 2008/57/EC.

3.  With regard to rail passenger services operated from or to third countries, compliance with the requirements of this TSI is subject to the availability of information from actors outside the EU unless bilateral agreements provide information exchange compatible with the TSI.

Article 2

This TSI shall be implemented in three phases:

Article 3

1.  The European Railway Agency shall publish on its website the technical documents listed in Annex III and shall keep them up to date. It shall implement a change management process for the technical documents as specified in Section 7.5.2 of Annex I. It shall report to the Commission on the progress of these documents. The Commission shall inform the Member States through the Committee established under Article 29 of Directive 2008/57/EC.

2.  The European Railway Agency shall publish on its website the reference files referred to in Section 4.2.19 of Annex I and shall keep them up to date. It shall implement a change management process for such files. It shall report to the Commission on the progress of these documents. The Commission shall inform the Member States through the Committee established under Article 29 of Directive 2008/57/EC.

3.  The European Railway Agency shall submit its recommendation on the open points listed in Annex II to this Regulation by 31 March 2012.

▼M2

Article 4

Railway undertakings, infrastructure managers, station managers, ticket vendors and the Agency shall support the works of phase 2 as specified in Section 7.3 of Annex I by providing functional and technical information and expertise.

Article 5

The representative bodies from the railway sector acting at European level as defined in Article 3(2) of Regulation (EC) No 881/2004 of the European Parliament and of the Council ( 5 ) together with a representative of ticket vendors and a representative of European passengers, shall further develop the Telematic Applications for Passenger Services subsystem as specified in Section 7.3 of Annex I. The phase 1 deliverables (Application guides, Architecture, Governance and Master plan) shall be made publicly available by the European Railway Agency on its website.

Article 6

Member States shall ensure that railway undertakings, infrastructure managers, station managers and ticket vendors are informed of this Regulation and shall designate a national contact point (NCP) for the follow-up of its implementation. The role of the NCPs is described in Annex VI.

Article 7

1.  The Regulation shall be amended taking into account the results of phase 2 referred to in Section 7.3 of Annex I.

2.  The European Railway Agency shall amend technical document B.60 (Architecture) taking into account the results of phase 1 and by applying the procedure of Article 3.

▼B

Article 8

This Regulation shall enter into force on the day following its publication in the Official Journal of the European Union.

This Regulation shall be binding in its entirety and directly applicable in all Member States.

---

ANNEX I

1.   INTRODUCTION

1.1.    Technical scope

This Technical Specification for Interoperability (hereinafter referred to as the TSI) concerns the element ‘applications for passenger services’ of the subsystem ‘telematics applications’ of the trans-European rail system referred to in Article 6(1) of Directive 2008/57/EC. It is included in the functional area of the list in Annex II to Directive 2008/57/EC.

1.2.    Geographical scope

The geographical scope of this TSI is the trans-European rail system as defined in Article 2(a) of Directive 2008/57/EC.

1.3.    Content of this TSI

The content of this TSI is in accordance with Article 5 of Directive 2008/57/EC.

This TSI also comprises, in Chapter 4, the operating and maintenance rules specific to the technical and geographical scope.

2.   DEFINITION OF THE SUBSYSTEM/SCOPE

2.1.    Subsystem

This TSI covers:

It includes the provision of information on the following aspects:

2.1.1.    Providing passengers with information before and during the journey

Annex II to Regulation (EC) No 1371/2007 on rail passengers’ rights and obligations lists the minimum information to be provided to passengers by railway undertakings and/or by ticket vendors.

2.1.2.    Reservation and payment systems

Information will be exchanged between the reservation and ticketing systems, and the payment systems of the different ticket vendors and railway undertakings in order to enable the passenger to pay for the above tickets, reservations and supplements for the journey and service chosen by the passenger.

2.1.3.    Luggage management

Information will be provided to the passenger relating to the complaints procedures in the event of registered luggage being lost during the journey. Moreover, passengers will be provided with information about sending or picking up registered luggage.

2.1.4.    Issuing of tickets via ticket offices or ticket selling machines or telephone or Internet or any other widely available information technology

Information will be provided between railway undertakings and ticket vendors in order to enable the latter to issue, where available, tickets, through tickets, and supplements, and to make reservations.

2.1.5.    Management of connections between trains and with other modes of transport

A standard is proposed for the provision of information to and exchange of information with other modes of transport.

3.   ESSENTIAL REQUIREMENTS

3.1.    Compliance with the essential requirements

In accordance with Article 4(1) of Directive 2008/57/EC, the trans-European rail system, subsystems and interoperability constituents must meet the essential requirements set out in general terms in Annex III to the Directive.

Within the scope of the present TSI, fulfilment of relevant essential requirements quoted in Chapter 3 of this TSI will be ensured for the subsystem by compliance with the specifications described in Chapter 4: Characterisation of the subsystem.

3.2.    Aspects relating to general requirements

The relevance of the general requirements to the telematics applications subsystem for passengers is determined as follows:

3.2.1.    Safety

The safety-related essential requirements that apply to the telematics applications subsystem for passengers are the following: essential requirements 1.1.1, 1.1.2, 1.1.3, 1.1.4, 1.1.5 of Annex III to Directive 2008/57/EC. These essential requirements are not relevant to the telematics applications subsystem.

3.2.2.    Reliability and availability

The essential requirement 1.2 of Annex III to Directive 2008/57/EC is met by the following sections:

3.2.3.    Health

Essential requirements 1.3.1 and 1.3.2 of Annex III to Directive 2008/57/EC are not relevant to the telematics applications subsystem.

3.2.4.    Environmental protection

Essential requirements 1.4.1, 1.4.2, 1.4.3, 1.4.4 and 1.4.5 of Annex III to Directive 2008/57/EC are not relevant to the telematics applications subsystem.

3.2.5.    Technical compatibility

Essential requirement 1.5 of Annex III to Directive 2008/57/EC is not relevant to the telematics applications subsystem.

3.3.    Aspects relating specifically to the telematics applications for the passenger services subsystem

The relevance of the general requirements to the telematics applications for the passenger services subsystem is determined as follows:

3.3.1.    Technical compatibility

Essential requirement 2.7.1 of Annex III to Directive 2008/57/EC is met in particular by the following sections:

3.3.2.    Reliability and availability

Essential requirement 2.7.2 of Annex III to Directive 2008/57/EC is met in particular by the following sections:

However, this essential requirement, especially the method of use to guarantee the efficiency of these telematics applications and the quality of the service, is the foundation for the complete TSI and is not restricted only to the sections mentioned above.

3.3.3.    Health

Regarding essential requirement 2.7.3 of Annex III to Directive 2008/57/EC, this TSI does not specify any requirements in addition to existing national and European rules related to minimum rules on ergonomics and health protection of an interface between these telematics applications and users.

3.3.4.    Safety

Essential requirement 2.7.4 of Annex III to Directive 2008/57/EC is met by the following sections:

4.   CHARACTERISATION OF THE SUBSYSTEM

4.1.    Introduction

Taking all the applicable essential requirements into account, the telematics application for passenger services subsystem is characterised by the following basic parameters which are described in the following sections.

4.2.    Functional and technical specifications of the subsystem

▼M2

4.2.1.    Exchange of timetable data

This basic parameter lays down how the railway undertaking shall perform the exchange of timetable data.

This basic parameter shall ensure that timetables comprising the data elements defined below shall be made available.

This basic parameter shall further ensure that each railway undertaking shall provide accurate and up-to-date timetable data.

The provisions of this basic parameter shall apply to the passenger services of the railway undertaking.

This basic parameter shall have the following process:

▼B

4.2.1.1.   The railway undertaking makes available its own timetable data to other railway undertakings and to third parties

The railway undertaking shall make available all of its timetable data for which the railway undertaking is responsible as sole or joint carrier and which are related to transport services which are available for purchase by the public by guaranteeing access to all railway undertakings, to third parties and to public bodies. The railway undertaking shall ensure that the timetable data are accurate and up-to-date. The timetable data shall be kept available at least for 12 months after such data have expired.

Where a railway undertaking operates a transport service for which it is one of the Joint carriers, the railway undertaking shall ensure, together with all the other Joint carriers, that its part of the timetable are accurate and up-to-date.

The main content of the timetable data shall be:

For those transport services over which the railway undertaking has sole control, the annual timetable shall be made available at least 2 months before that timetable comes into force. For the remaining transport services, the railway undertaking shall make the timetable available as soon as possible.

The railway undertaking shall make available any changes to the annual timetable in a series of timetable updates at least 7 days before those changes take effect. This obligation shall apply only if the change is known to the railway undertaking seven or more days in advance of it taking effect.

The above process and the information used therefor shall comply with the technical document(s):

▼M2

4.2.2.    Exchange of tariff data

This basic parameter lays down how the railway undertaking shall perform the exchange of tariff data.

This basic parameter shall ensure that tariff data in the format defined below shall be made available.

The provisions of this basic parameter shall apply in respect of all passenger tariffs of the railway undertaking for domestic, international and foreign sales.

This basic parameter shall have following process:

4.2.2.1.   The railway undertaking makes available its own tariffs to other railway undertakings, authorised public bodies and third parties

Without prejudice to passenger rights and in accordance with distribution agreements, each railway undertaking shall make available its tariffs (including fare tables) by guaranteeing access to railway undertakings to which it grants authorisation to sell, third parties to which it grants authorisation to sell, and to authorised public bodies. The railway undertaking shall ensure that the tariff data are accurate and up-to-date. Where a railway undertaking operates a transport service for which it is one of the joint carriers, the railway undertaking shall ensure, together with all the other joint carriers, that the tariff data are accurate and up-to-date.

The main content of tariff data intended for international or foreign sales shall be as defined in Annex IV.

Tariff data intended for international or foreign sales shall be made available at least as far in advance as provided for in Annex IV.

The above process and the information used for it shall be compliant for tariff data intended for international or foreign sales with the technical document(s):

The above process and the information used for it in respect of tariff data intended for domestic sales shall comply with the technical documents to be developed by the Agency (see Annex II).

▼B

4.2.3.    Handling of information on contact details of the railway undertaking

This basic parameter lays down how the railway undertaking shall provide information about its official website from which customers can obtain accurate information.

The provisions of this basic parameter shall apply to all railway undertakings.

This basic parameter shall have following process:

4.2.3.1.   The railway undertaking makes available a dataset of its contact details

The railway undertaking shall make available to other railway undertakings, to the Agency, to third parties and to public bodies a dataset that includes its carrier name, carrier code and its official website. The official website referred to in this basic parameter shall be machine readable and compliant with web content accessibility guidelines. If a railway undertaking operates a joint business unit with (an)other railway undertaking(s), the name of the joint business unit, carrier codes and official website shall be made available to the other railway undertakings.

When a railway undertaking makes its timetable information available to other railway undertakings pursuant to Section 4.2.1.1, it shall ensure that the carrier name in the timetable delivery has a corresponding carrier name in this dataset. If changes have occurred, the railway undertaking shall update the content of the dataset as soon as possible.

4.2.4.    Handling of information concerning conditions of carriage

This basic parameter lays down how the railway undertaking shall handle information concerning conditions of carriage.

This basic parameter shall ensure that conditions of carriage are available on the official website of the railway undertaking.

The provisions of this basic parameter shall apply to the passenger services of the railway undertaking.

This basic parameter shall entail the following process:

4.2.4.1.   The railway undertaking publishes information relating to conditions of carriage

The railway undertaking shall publish information relating to:

at least on its official website. This website shall comply with web content accessibility guidelines which take into account the needs of people with auditory and/or visual impairment.

This process shall be performed for the first publication not later than 6 months after this TSI comes into force. Changes to this information shall be published at least 6 days before they enter into force. The railway undertaking shall list the articles which have been changed compared to the previous version. On each such occasion the railway undertaking shall maintain the earlier version of this information on its official website.

4.2.5.    Handling of information concerning carriage of registered luggage

This basic parameter lays down how the railway undertaking shall ensure the provision of information for the carriage of registered luggage if the service is offered by the railway undertaking. If the service is not offered, the railway undertaking shall provide the information that the service is not offered.

This basic parameter shall ensure that information on the handling of registered luggage shall be available to the passenger.

This basic parameter shall entail the following process:

4.2.5.1.   The railway undertaking publishes conditions for the handling of registered luggage

The railway undertaking shall publish for the attention of passengers the conditions for the handling of registered luggage where the railway undertaking offers such handling. Where the service is not offered, the railway undertaking shall publish information to that effect. This information shall be published at least on the official website of the railway undertaking. This website shall comply with web content accessibility guidelines which take into account the needs of people with auditory and/or visual impairment.

This process shall be performed for the first publication not later than 6 months after this TSI comes into force. Changes to this information shall be published at least 6 days before the modification enters into force. The railway undertaking shall list the articles which have been modified compared to the previous version. The railway undertaking shall on each such occasion maintain the previous version of this information on its official website.

4.2.6.    Handling of information concerning carriage and assistance of persons with reduced mobility (PRM)

This basic parameter lays down how the railway undertaking, ticket vendor, and/or station manager must ensure the provision of information on the carriage and assistance of PRMs.

This basic parameter shall ensure that information on the carriage and assistance of PRMs shall be available to the passenger. If the railway undertaking uses IT communication for the purposes of sending an availability/reservation request for PRM assistance, the system to which it is addressed shall at least be able to handle messages according to the protocol specified in the technical document B.10 (see Annex III). In addition, the system shall issue a confirmation number for the assistance reservation — this is essential in order to provide the customer/passenger with the guarantee and confidence that the assistance will be provided and to establish accountability and responsibility for the provision of assistance. Those messages contain all the information needed in order for the railway undertaking, ticket vendor and/or station manager to issue to the PRM a confirmation number (for each departure and arrival of each journey) to reserve assistance.

The provisions of this basic parameter shall apply as follows: the handling of information concerning the carriage of PRM shall be applied in respect of the passenger services of the railway undertaking. ►M2  ————— ◄

This basic parameter shall entail the following processes:

4.2.6.1.   The railway undertaking publishes information on the accessibility of rail services and on the conditions of access to rolling stock

The railway undertaking shall publish the following information:

at least on its official website. ►M2  This website shall be accessible to persons with disabilities. ◄

This process shall be performed for the first publication at the latest 6 months after this TSI comes into force. Any modifications to this information shall be published at least 6 days before the modification enters into force. The railway undertaking shall list the articles which have been modified compared to the previous version. On each occasion the railway undertaking shall maintain on its official website the previous version of this information.

▼M2

4.2.6.2.   If the railway undertaking or ticket vendor uses IT communication for the purposes of sending an availability/reservation request for PRM assistance, such request must comply with the relevant provisions

The requesting distribution system shall send to the system requests for the relevant train availability/reservation in respect of the specified type of assistance.

The main types of requests shall be:

This process shall be performed following a request from a customer transmitted to the system of the railway undertaking or ticket vendor.

The data elements and the information content of the message used to meet the obligations shall comply:

▼B

4.2.6.3.   Addressed system sends an availability/reservation response for PRM assistance

If the railway undertaking uses IT communication for the purposes of sending of an availability/reservation response for PRM assistance, it shall abide by the terms and conditions of this process.

If a request for reservation of PRM assistance has been properly formulated according to the process described above, the addressed system shall send to the requesting system an availability/reservation response for the requested assistance type.

The main types of reservation responses shall be:

This process shall be performed in response to an incoming request received by the system to which it is sent according to the process described above.

The data elements and the message information contents used to meet the obligations shall comply:

according to the protocol used by the requesting system.

4.2.7.    Handling of information concerning the carriage of bicycles

This basic parameter lays down how the railway undertaking shall ensure the provision of information concerning the carriage of bicycles.

This basic parameter shall ensure that information for the carriage of bicycles shall be available to the passenger. The attributing system shall be able to handle at least messages according to the protocol specified in technical document B.5 (see Annex III).

The provisions of this basic parameter shall apply as follows: the handling of information concerning the carriage of bicycles shall be applied in respect of the passenger services of the railway undertaking where carriage of bicycles is offered. The provisions of this basic parameter regarding an electronic request/confirmation shall be applied if there is an agreement between the requesting and the attributing parties for the provision of services where such carriage may be reserved or is subject to compulsory reservation.

This basic parameter shall have the following processes:

4.2.7.1.   The railway undertaking publishes conditions for handling of bicycles

The railway undertaking shall publish for the attention of passengers the conditions for carriage of bicycles where such carriage is offered by the railway undertaking. This information shall be published at least on the railway undertaking’s official website. This website shall meet web content accessibility guidelines which take into account the needs of people with auditory and/or visual impairment. These conditions shall list at least:

The first publication of these conditions shall take place not later than 6 months after this TSI comes into force. Changes to this information shall be published at least 6 days before the change comes into force. The railway undertaking shall list the articles which have been changed compared to the previous version. The railway undertaking shall in all cases maintain the previous version of this information on its official website.

4.2.7.2.   A railway undertaking or ticket vendor sends an availability/reservation request for bicycles to the attributing reservation system

The possibility of making a reservation shall be subject to the existence of a commercial agreement between the carrier(s) and distributor(s) involved. Such agreements can include charges, technical and safety standards, specific limitations in terms of trains, origins/destinations, tariffs, sales channels, etc.

If the railway undertaking or ticket vendor uses IT communication for the purposes of sending a request for availability/reservation for the carriage of bicycles, such communication shall conform to the requirements of this process.

Subject to an agreement between the parties involved, the requesting distribution system shall send requests for the specified bicycle carriage to the attributing system concerning the availability/reservation of the train concerned.

The main types of reservation requests shall be:

This process shall be performed following a request from a customer sent to the distribution system of the railway undertaking.

The data elements and the information content of the message used to meet the obligations shall be compliant:

4.2.7.3.   Attributing reservation system sends availability/reservation response for bicycles

If the railway undertaking uses IT communication for the purposes of sending of an availability/reservation answer for the carriage of bicycles, it shall follow the relevant instructions of this process.

If a request for reservation of bicycle spaces has been correctly formulated according to the process above described, the attributing system shall send to the requesting distribution system an availability/reservation response for the requested train.

The main types of reservation responses shall be:

This process shall be performed in response to an incoming request arriving at the attributing system according to the process described above.

The data elements and the information content of the message used to meet the obligations shall comply:

according to the protocol used by the requesting attributing system.

4.2.8.    Handling of information concerning the carriage of cars

This basic parameter lays down how the railway undertaking shall ensure the provision of information for the carriage of cars/motorcycles (in the following, the word ‘cars’ includes motorcycles) if it is offered by the railway undertaking.

This basic parameter shall ensure that information on the carriage of cars shall be available to the passenger. The attributing system shall be able to handle at least messages according to the protocol specified in technical document B.5 (see Annex III).

The provisions of this basic parameter shall apply as follows: the handling of information concerning the carriage of cars shall be applied in respect of the passenger services of the railway undertaking where carriage of cars is offered. The provisions of this basic parameter regarding electronic request/confirmation shall apply if there is an agreement between the requesting and the attributing parties for services where such carriage may be reserved or is subject to mandatory reservation.

This basic parameter shall apply as follows:

4.2.8.1.   The railway undertaking publishes conditions for the handling of cars

The railway undertaking shall communicate to the passenger the conditions for carriage of cars where this is offered by the railway undertaking. This information shall be published at least at the railway undertaking’s official website. This website shall comply with web content accessibility guidelines which take into account the needs of people with auditory and/or visual impairment.

These conditions shall list at least:

The first publication shall take place at the latest 6 months after this TSI comes into force. Changes to this information shall be published at least 6 days before they enter into force. The railway undertaking shall list the articles which have been amended. The railway undertaking shall on each occasion keep the previous version of this information on its official website.

4.2.8.2.   The railway undertaking or ticket vendor sends an availability/reservation request for cars to the reservation system

The possibility of making a reservation shall be subject to the existence of a commercial agreement between the carrier(s) and distributor(s) involved. Such agreements may include charges, technical and security standards, specific limitations in terms of trains, Origins/Destinations, tariffs, sales channels, etc.

If the railway undertaking or ticket vendor uses IT communication for the purpose of sending availability/reservation requests for the carriage of cars, such communication shall comply with the provisions governing this process.

Subject to an agreement between the parties involved, the requesting distribution system shall send to the attributing system for the relevant train availability/reservation requests for the specified carriage of cars.

The main types of reservation requests shall be:

This process shall be performed following a request transmitted by a customer to the distribution system of the railway undertaking.

The data elements and the information content of the message used to meet the obligations shall be compliant:

4.2.8.3.   Attributing reservation system sends availability/reservation response for cars

If the railway undertaking uses IT communication for the purpose of sending availability/reservation responses for the carriage of cars, it shall adhere to the rules laid down in respect of this process.

If a request for reservation of cars has been properly formulated according to the process described above, the attributing system shall send an availability/reservation response for the requested train to the requesting distribution system.

The main types of reservation responses shall be:

This process shall be performed in response to an incoming request arriving at the attributing system according to the process described above.

The data elements and the information content of the message used to meet the obligations shall comply:

according to the protocol used by the requesting distribution system.

4.2.9.    Handling of availability/reservation

This basic parameter lays down the manner in which the railway undertakings shall deal with reservations for the accommodation of passengers. All of the various types of accommodation (such as seats, couchettes, sleepers, priority seats, wheelchair spaces, universal sleeping compartments (see PRM TSI Section 4.2.4)) will be designated hereinafter as ‘places’, unless more specific information is needed. Reservations for the carriage of bicycles, cars and for assistance of PRM, are described in separate basic parameters in separate sections.

Reservation of places may simply concern the booking of accommodation, in addition to the transport contract, or may be part of a combined transaction which includes both accommodation and a transport contract.

This basic parameter shall ensure that the issuing and attributing railway undertakings shall exchange appropriate availability and reservation information. The attributing system shall be able to handle at least messages according to the protocol specified in the technical document B.5 (see Annex III).

The provisions of this basic parameter shall be applied if an agreement between the requesting and the attributing parties exists in respect of services which may be reserved or are subject to mandatory reservation.

This basic parameter shall involve the following processes:

4.2.9.1.   The railway undertaking or ticket vendor sends an availability/reservation request to the attributing reservation system

The possibility of making a reservation shall be subject to the existence of a commercial agreement between the involved carrier(s) and distributor(s). Such agreements can include charges, technical and safety standards, specific limitations in terms of trains, origins/destinations, tariffs, sales channels, etc.

Subject to an agreement between the parties involved, the requesting distribution system shall send requests to the attributing system in respect of the relevant train availability/reservation for the specified accommodation type.

The main types of reservation requests are:

This process shall be performed following a request from a customer transmitted to the distribution system of the railway undertaking.

The data elements and the information contained in the message used to meet the obligations shall comply:

4.2.9.2.   Attributing reservation system sends availability/reservation response

If a request for reservation of places has been validly formulated according to the process described above, the attributing system shall send an availability/reservation response for the requested train to the requesting distribution system.

The main types of reservation responses shall be:

This process shall be performed in response to an incoming request arriving at the attributing system according to the process described above.

The data elements and the message information contents used to meet the obligations shall be compliant:

according to the protocol used by the requesting distribution system.

4.2.10.    Handling of security elements for product distribution

This basic parameter specifies the manner in which the attributing railway undertaking shall generate security elements for the distribution of its products.

This basic parameter must ensure that railway undertakings and passengers shall, at the appropriate time, obtain from the attributing railway undertaking the security information and references needed for the various ticket types.

This basic parameter shall entail the following processes:

4.2.10.1.   Attributing system creates security element for electronic delivery

If a railway undertaking issues CIV compliant ticket/reservation, the staff of the rail ticket office/agency/retailer or the distribution system of the railway undertaking shall generate the security information to be inserted in the ticket/reservation.

This process shall be performed as soon as the booking status and sales transaction data have been successfully sent to the distribution system of the agreed railway undertakings.

The above process and the information used for it shall comply with:

4.2.10.2.   Attributing system creates a dossier reference for the railway undertaking for electronic delivery

If a railway undertaking issues CIV compliant ticket/reservation, the staff of rail ticket office/agency/retailer or the distribution system of the railway undertaking shall produce a dossier reference to retrieve the ticket/reservation and shall enter all information concerning the ticket into its own distribution system.

This process shall be performed as soon as the booking status and sales transaction data have been successfully sent to the distribution system of the agreed railway undertakings.

The above process and the information used for it shall be compliant with:

4.2.10.3.   Attributing system creates a dossier reference for the passenger for electronic delivery

If a railway undertaking issues a CIV compliant ticket/reservation, the staff of the rail ticket office/agency/retailer or the distribution system of the railway undertaking shall generate a dossier reference and shall enter it on the ticket/reservation.

This process shall be performed as soon as the booking status and sales transaction data have been successfully sent to the distribution system of the agreed railway undertakings.

The above process and the information used for it shall be compliant with:

4.2.11.    Delivery of the product to the customer after its purchase (fulfilment)

This basic parameter sets out all the possible direct and indirect fulfilment methods which are linked to the ticket and/or reservation and to the kind of media (e.g. paper).

This basic parameter shall ensure that the issuer or ticket vendor shall issue tickets according to standards that ensure interoperability between railway undertakings. For the purposes of issuing tickets for international and foreign sales, railway undertakings shall use at least one of the fulfilment types listed in Section 4.2.11.1 Fulfilment — direct — for international and foreign sales and in Section 4.2.11.2 Fulfilment — indirect — for international and foreign sales.

The provisions of this basic parameter shall be applied at least in respect of the tariffs for international and foreign sales.

4.2.11.1.   Fulfilment — direct — for international and foreign sales

This process shall be an alternative to process 4.2.11.2 Fulfilment — indirect — for international and foreign sales.

The railway undertakings shall at least accept tickets according to the definition in technical document B.6 (see Annex III), except where the ticket is not appropriate for the journey being undertaken, where the railway undertaking has reasonable grounds to suspect fraud and where the ticket is not being used in accordance with the conditions of carriage according to Section 4.2.4.

The main types of issued tickets are specified in technical document B.6 of Annex III:

The above process and the information used for it shall be compliant with the technical document(s):

4.2.11.2.   Fulfilment — indirect — for international and foreign sales

This process shall be an alternative to process 4.2.11.1 Fulfilment — direct — for international and foreign sales

If the railway undertaking makes sales using indirect fulfilment on one of the following methods, it must use the following standards:

The main types of above issued tickets shall be:

The above process and the information used for it shall be compliant with the following technical document(s):

4.2.11.3.   Fulfilment — direct — domestic sales

This is an open point (see Annex II).

4.2.11.4.   Fulfilment — indirect — domestic sales

This is an open point (see Annex II).

4.2.12.    Handling of information provision in the station area

This basic parameter lays down how the station manager shall provide the customer with train running information within the station area.

The provisions shall apply only if there has been a renewal, major upgrade or new installation of voice announcements and/or display systems.

The provisions of this basic parameter shall apply at least in respect of stations at which trains performing international service stop.

This basic parameter shall entail the following processes:

4.2.12.1.   Station manager informs customers within the station

With regard to information on train departures, station managers shall provide the following departure information on trains to customers in stations:

In the event of deviation from this information for departing trains, station managers shall provide, in stations, at least the following train information:

As regards information on terminating trains, the station manager shall provide at least the following train information:

In the case of deviation for terminating trains, the station manager shall provide at least the following information for such trains:

Deviations from plan comprise:

The station manager decides according to agreements with the railway undertakings and/or infrastructure managers on:

In accordance with a contractual agreement, information about deviations shall be delivered by railway undertakings and/or Infrastructure managers in due time to the station manager.

4.2.13.    Handling of information provision in the vehicle area

This basic parameter lays down how the railway undertaking shall provide train running information within the vehicle area.

The provisions shall apply to new or renewed or upgraded rolling stock, if information systems (voice announcements and/or displays) are renewed or installed.

The provisions of this basic parameter shall apply to at least all those trains performing international service.

This basic parameter shall have the following processes:

4.2.13.1.   The railway undertaking informs passengers in the train

The railway undertakings shall provide passengers in the train:

Before arrival at all intermediate station stops:

Before arrival at major intermediate station and destination station:

The railway undertaking decides on:

4.2.14.    Train preparation

This basic parameter lays down the manner in which the railway undertaking must inform the infrastructure manager that the train is ready to access the network when train departure tasks as defined in OPE TSI Section 4.2.3.3 have been carried out or when the train number has changed.

The provisions of this basic parameter shall apply to all trains of the railway undertaking.

This basic parameter shall entail the following processes:

4.2.14.1.   ‘Train ready’ message for all trains

The railway undertaking shall send a ‘train ready’ message to the infrastructure manager every time a train is ready to access the network for the first time, unless under national rules the infrastructure manager accepts the timetable as a ‘train ready’ message. In the latter case, the railway undertaking shall inform the infrastructure manager and, if applicable, the station manager if the train is not ready as soon as possible.

Messages shall consist at least of:

Other items, such as:

may be transmitted in the same message.

The above process and the information used for it shall at least comply with the ‘train ready’ message of the technical document(s):

In addition, other existing standards may be used for the same purpose if the parties involved have concluded a specific agreement allowing these standards to be used.

4.2.15.    Train running information and forecast

This basic parameter lays down the train running information and train running forecast. It must prescribe how the dialogue between infrastructure manager and railway undertaking, as well as between railway undertaking and station manager, are to be maintained in order to exchange train running information and train running forecasts.

This basic parameter lays down how the infrastructure manager must, at the appropriate time, send train running information to the railway undertaking and the next neighbouring infrastructure manager involved in the operation of the train.

The train running information serves to provide details of the current status of the train at contractually agreed reporting points.

The train running forecast is used to provide information about the estimated time at contractually agreed forecast points. This message shall be sent from the infrastructure manager to the railway undertaking and the neighbouring infrastructure manager involved in the run. The information about the train running forecast shall be delivered to the station manager in due time by the railway undertakings and/or infrastructure managers according to a contractual agreement.

The path contract specifies Reporting Points for the train’s movement.

This basic parameter describes the content of the message and does not prescribe the process for generating the train running forecast.

The provisions of this basic parameter shall apply to all trains of the railway undertaking.

This basic parameter shall entail the following processes:

4.2.15.1.   Train running information for all trains

The infrastructure manager shall send a ‘train running information’ message to the railway undertaking. This process shall be performed as soon as the train reaches contractually agreed reporting points at which to deliver train running information. An agreed Reporting Point can be, among others, a handover point, a Station or the final destination of the train.

The message shall consist at least of the following:

Other items, such as:

may be transmitted in the same message.

The above process and the information used for it shall comply at least with the ‘TrainRunningInformationMessage’ of the technical document(s):

In addition, other existing standards may be used for the same purpose if there is a specific agreement between the parties involved to allow the use of these standards.

4.2.15.2.   Train running forecast for all trains

The infrastructure manager shall send a ‘train running forecast’ message to the railway undertaking.

This process shall be performed as soon as the train reaches contractually agreed Reporting Points to deliver a forecast. An agreed forecast point can be, among others, a handover point or a Station. A train running forecast can also be sent before the train starts running. For additional delays occurring between two Reporting Points, a threshold has to be contractually defined between the railway undertaking and the infrastructure manager to which an initial or a new forecast has to be sent. If the delay is not known, the infrastructure manager has to send a ‘service disruption message’ (see Section 4.2.16 Service disruption information).

The train running forecast message must give the forecast time for agreed forecast points.

Information on the train running forecast shall be delivered by the railway undertakings and/or infrastructure managers in due time to the station manager under a contractual agreement.

The infrastructure manager shall send this message to the next neighbouring infrastructure manager involved in the train run.

The message must consist at least of:

Other items, such as:

may be sent in the same message.

The above process and the information used for it shall at least be compliant with the ‘Train RunningForecastMessage’ of the technical document(s):

In addition, other existing standards may be used for the same purpose if a specific agreement to that effect has been signed between the parties involved that allows the use of these standards.

4.2.16.    Service disruption information

This basic parameter lays down how service disruption information is handled between the railway undertaking and the infrastructure manager.

The provisions of this basic parameter shall apply to all trains of the railway undertaking.

For the purpose of dealing with passengers’ complaints, service disruption data shall be kept available for railway undertakings, ticket vendors and/or authorised public bodies for at least 12 months after such data has expired.

This basic parameter shall entail the following processes:

4.2.16.1.   General remarks

The railway undertaking shall inform the infrastructure manager of the operational status of the trains, as defined in OPE TSI Section 4.2.3.3.2.

If train running is interrupted, the infrastructure manager shall send a ‘train running interrupted’ message as specified below.

4.2.16.2.   Train Running Interrupted message for all trains

If train running is interrupted, the infrastructure manager issues this message to the neighbouring infrastructure manager and to the railway undertaking(s).

If the length of the delay is known, the infrastructure manager must send a train running forecast message (see Section 4.2.15.2 Train running forecast).

The main data elements in this message are:

The above process and the information used for it shall at least comply with the ‘TrainRunningInterruptionMessage’ of the technical document(s):

In addition, other existing standards may be used for the same purpose if a specific agreement has been concluded between the parties involved which allows the use of these standards.

4.2.17.    Handling of short term timetable data for trains

This basic parameter lays down how Short notice Path Requests should be handled between the ‘Access Party’ (AP) and the infrastructure manager. These requirements are valid for all Short Notice Path Requests.

This BP does not include Traffic Management issues. The time limit between Short Term paths and Traffic Management path changes is subject to Local Agreements. It has to be possible, where short-notice transport needs are concerned (e.g. special train, additional train), to request a Short Term path. To this end, the AP requesting a Short Term path must provide the infrastructure manager with all necessary information indicating when and where a train is required to run and the data relating thereto.

No minimum time frame is specified at European level. The network statement may specify minimum time frames.

Each infrastructure manager is responsible for the suitability of a path on their infrastructure, and the railway undertaking is obliged to check the train characteristics against the values given in the details of its contracted path.

The various possible scenarios are set out below:

In both scenarios the allocation procedure for a Short Notice Path Request takes the form of a dialogue between AP and infrastructure manager, which contains the following messages:

In the case of train movements for which a path has already been requested and issued, it is not necessary to repeat the request for a path unless delays exceeds a value that is contractually agreed between the railway undertaking and the infrastructure manager or if the train composition is changed in such a way that it renders the existing path request invalid.

The provisions of this basic parameter shall apply to path handling for all trains of the railway undertaking, but only if the parties involved use telematics applications within the meaning of Annex II to Directive 2001/14/EC of the European Parliament and of the Council ( 6 ) for Short Notice Path Requests.

In such a case, this basic parameter shall involve the following processes:

4.2.17.1.   Path Request message

This message is sent to the infrastructure manager by the AP with the following main content:

The above process and the information used for it shall at least comply with the ‘PathRequestMessage’ of the technical document(s):

In addition, other existing standards may be used for the same purpose if there is a specific agreement between the parties involved that allows the use of these standards.

4.2.17.2.   Path Details message

The infrastructure manager sends this message with the following main content to the requesting AP in reply to that AP’s path request:

The above process and the information used for it shall at least comply with the ‘PathDetailsMessage’ of the technical document(s):

In addition, other existing standards may be used for the same purpose if a specific agreement is concluded between the parties involved to allow the use of these standards.

4.2.17.3.   ‘Path Not Available’ message

The infrastructure manager sends this message to the requesting AP in reply to the AP’s path request in the event of no path being available:

At the same time as this message, or as soon as possible, the infrastructure manager must send an alternative proposal without requiring any further request from the railway undertaking (Path Details message).

The above process and the information used for it shall at least comply with the ‘PathNotAvailableMessage’ of the technical document(s):

In addition, other existing standards may be used for the same purpose if there is a specific agreement between the parties involved that allows the use of these standards.

4.2.17.4.   Path Confirmed message

The requesting AP uses this message to book/confirm the path proposed by the infrastructure manager:

The above process and the information used for it shall be compliant at least with the ‘PathConfirmedMessage’ of the technical document(s):

In addition, other existing standards may be used for the same purpose if there is a specific agreement between the parties involved allowing the use of these standards.

4.2.17.5.   Path Details Refused message

The requesting AP uses this message to reject the path details proposed by the relevant infrastructure manager:

The above process and the information used for it shall be compliant at least with the ‘PathDetailsRefusedMessage’ of the technical document(s):

Other existing standards may also be used for the same purpose if there is a specific agreement between the parties involved that allows the use of these standards.

4.2.17.6.   Path Cancelled message

This message is used by an AP to cancel a path it has booked:

The above process and the information used for it shall be compliant at least with the ‘PathCancelledMessage’ of the technical document(s):

In addition, other existing standards may be used for the same purpose if there is a specific agreement between the parties involved allowing the use of these standards.

4.2.17.7.   ‘Receipt Confirmation’ message

This message is exchanged between infrastructure managers and APs when the required response to any of the above messages cannot be made available within 5 minutes:

The above process and the information used for it shall be compliant at least with the ‘ReceiptConfirmationMessage’ of the technical document(s):

In addition, other existing standards may be used for the same purpose if there is a specific agreement between the parties involved that allows the use of these standards.

4.2.17.8.   ‘Booked Path No Longer Available’ message

The infrastructure manager uses this message to let the AP know that a path which has been booked is no longer available. The path has ceased to be available for an important reason, e.g. a major disruption. Content of message:

The above process and the information used for it shall be compliant at least with the ‘PathNotAvailableMessage’ of the technical document(s):

In addition, other existing standards may be used for the same purpose if there is a specific agreement between the parties involved that allows the use of these standards.

4.2.18.    The quality of the data and information related to this TSI

4.2.18.1.   The requirements

In order to meet the requirements of this TSI, the following shall be applied as regards data and information quality throughout the whole TSI.

All those to whom this TSI is addressed shall be responsible for making available up-to-date, coherent, accurate and complete data at the appropriate time and in the appropriate format to other railway undertakings, or to infrastructure managers, or to a third party. Each actor addressed by this TSI shall be responsible for publishing up-to-date, coherent, accurate and complete information at the appropriate time and in the appropriate content to the customers (passengers), or to other railway undertakings, or to infrastructure managers, or to a third party.

Where data or information are used in order to meet the requirements of several basic parameters of this TSI at the same time, the actors to whom this TSI is addressed shall ensure that the data or information shared between those basic parameters is used in a coherent manner (e.g. coherence i) between timetable and tariff information or ii) between tariff and reservation information shall be ensured).

Where information or data are provided by several actors addressed by this TSI, the actors shall together ensure that the parts of the common data or information provided are up-to-date, coherent, accurate, complete and compatible (example: deliveries of timetable information for railway undertaking A and railway undertaking B must be coherent in order to ensure that they match at the border, etc.).

Where reference data or reference information is used in order to meet the requirements of this TSI, the actors addressed by this TSI shall guarantee the coherence between the reference data or reference information and the data or information used in the basic parameters of this TSI (examples: coherence (i) between location reference codes and train running information or (ii) between railway undertaking reference codes and fulfilment shall be ensured, etc.).

The quality of data or information provided by the actors for the purposes of this TSI shall be such that it enables the actors to whom this TSI is addressed to issue tickets as set out in Article 10 of the Regulation on Rail Passengers’ Rights and Obligations.

The quality of data or information provided by the actors for the purposes of this TSI shall achieve a level which makes it possible for the actors addressed by this TSI to provide the information as set out in Article 10 and in Annex II to the Regulation on Rail Passengers’ Rights and Obligations.

4.2.19.    Various reference files and databases

4.2.19.1.   Reference files

For the operation of passenger trains on the European network, the following reference files must be available and accessible to all service providers (infrastructure managers, railway undertakings, authorised third parties and station managers). The data must represent the actual status at all times.

The European Railway Agency will centrally store and maintain unique codes for the following reference data:

Where a reference file is in common use with the TAF TSI, its development and use shall be as close as possible to the implemented TAF TSI in order to achieve optimum synergies.

4.2.19.2.   Additional requirements concerning databases

The additional requirements which must be supported by the various databases are listed below. They are:

1.   Authentication

A database must support the authentication of users of the systems before they can gain access to the database.

2.   Security

A database must support security aspects in terms of controlling access to the database. The possible encryption of the database contents itself is not required.

3.   ACID

A database selected shall support the ACID principle (Atomicity, Consistency, Isolation, Durability).

4.   Access control

A database must allow access to the data by users or systems that have been granted permission. The access control shall be supported down to a single attribute of a data record. The database shall support configurable, role based access control for the insertion, update or deletion of data records.

5.   Tracing

A database must support the logging of all actions applied to the database to allow the detail of the data entry to be traced (Who, What, When did the contents change?).

6.   Locking strategy

A database must implement a locking strategy which allows access to the data even when other users are engaged in editing records.

7.   Multiple access

A database must ensure that data can be accessed simultaneously by several users and systems.

8.   Reliability

The reliability of a database must support the required availability.

9.   Availability

A database must have the necessary availability level for the nature of the data and the business cases based on it.

10.   Maintainability

The maintainability of the database must support the required availability.

11.   Safety

Databases themselves are not safety related. Hence, safety aspects are not relevant. This is not to be confused with the fact that the data — e.g. incorrect or not up-to-date data — may have an impact on the safe operation of a train.

12.   Compatibility

A database must support a data manipulation language that is widely accepted, such as SQL or XQL.

13.   Import facility

A database shall provide a facility that allows the import of formatted data that can be used to fill the database instead of manual input.

14.   Export facility

A database shall provide a facility that allows the contents of the complete database or part thereof to be exported as formatted data.

15.   Mandatory fields

A database must support mandatory fields that are required to be completed before the relevant record is accepted as input to the database.

16.   Plausibility checks

A database must support configurable plausibility checks before accepting the insertion, update or deletion of data records.

17.   Response times

A database must have response times that allow users to insert, update or delete data records in a timely manner.

18.   Performance aspects

The reference files and databases shall support in a cost effective manner the queries necessary to allow the effective operation of all relevant train runs that are covered by the provisions of this TSI.

19.   Capacity aspects

A database shall support the storage of the relevant data for all passenger wagons and/or the network. It shall be possible to extend the capacity by simple means (i.e. by adding more storage capacity and computers). The extension of the capacity shall not require replacement of the subsystem.

20.   Historical data

A database shall support the management of historical data by making data available that have been already transferred into an archive.

21.   Back-up strategy

A back-up strategy shall be in place to ensure that the complete database contents for a period of up to 24 hours can be recovered.

22.   Commercial aspects

The database system used shall be available commercially off-the-shelf (COTS-product) or be available in the public domain (Open Source).

23.   Privacy aspects

A database has to fulfil the privacy policy requirements of the Member State in which the company performing the service is domiciled.

4.2.20.    Electronic transmission of documents

The description in Section 4.2.21 — Networking and communication — presents the communication network to be used for data exchange. This network and the described security handling allow any type of network transmission, such as e-mail, file transfer (Ftp, Http), etc. The parties involved in the information exchange can then decide on the type to choose, thereby ensuring the electronic transmission of documents, for example, via FTP.

4.2.21.    Networking and communication

4.2.21.1.   General architecture

Over time this subsystem will see the growth and interaction of a large and complex telematics rail interoperability community with thousands of participating actors (railway undertakings, infrastructure managers, third parties such as retailers and public authorities, etc.), which will compete and/or cooperate in serving the market’s needs.

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’:

The Information Exchange Architecture favours a mostly Peer-to-Peer type of interaction between all actors, while guaranteeing the overall integrity and consistency of the rail interoperability community by providing a set of centralised services.

A Peer-to-Peer interaction model allows the best distribution of costs between the different actors, based on actual usage and, in general, will pose fewer scalability problems.

4.2.21.2.   Network

The network shall ensure the necessary level for security, redundancy, traffic control, statistics tools, bandwidth growth, user accessibility and efficient management.

‘Network’ in this context means the method and philosophy of communication and does not refer to the physical network.

Rail interoperability is based on a common ‘Information Exchange Architecture’, known and adopted by all participants, thus encouraging and lowering barriers for new entrants, especially customers.

First, the central Repository is approached to obtain meta-information, such as the identity of the peer (actor) on which information is stored, or to verify security credentials. Afterwards, Peer-to-Peer communication takes place between the actors involved.

4.2.21.3.   Protocols

Only protocols belonging to the Internet Protocol Suite (commonly known as TCP/IP, UDP/IP, etc.) may be used for developments.

4.2.21.4.   Security

On top of the security level guaranteed at the level of the network (see Section 4.2.21.2 Network), an additional level of security can be achieved for sensitive data by using a combination of encryption, certification scheme and VPN technologies.

4.2.21.5.   Encryption

Either asymmetric or symmetric encryption can be used for data transmission and storage, depending on the business requirements. For this purpose a public key infrastructure (PKI) is to be implemented.

4.2.21.6.   Central repository

The central repository must be able to handle:

Where the Central Repository is in use in conjunction with the TAF TSI, development and changes shall be performed as closely as possible to the implemented TAF TSI in order to achieve optimum synergies.

4.2.21.7.   Common interface for RU/IM communication

The common interface is mandatory for each actor in order to join the rail interoperability community.

The common interface has to be able to handle:

Each instance of the common interface will have access to all the data required according to the TSI within each railway undertaking, infrastructure manager, etc., whether the relevant databases are central or individual. Based on the results of verification of the authenticity of incoming messages, a minimum level of message acknowledgement can be implemented:

The common interface uses the information in the Central Repository in order to manage the above tasks.

If an actor implements a local ‘mirror’ of the Central Repository, that actor must then — by its own means — ensure that the local ‘mirror’ is an accurate and up to date copy of the Central Repository.

Where the Common Interface is in common use with the TAF TSI, the development and changes shall take place as closely as possible to the implemented TAF TSI, in order to achieve optimum synergies.

4.2.22.    Management of connection with other modes of transport

In order to manage the connection with other modes of transport, the following standard should be applied for the provision of information to and exchange of information with other modes of transport:

4.3.    Functional and technical specifications of the interfaces

From the standpoint of technical compatibility, the interfaces of the subsystem ‘telematics applications for passenger services’ with the other subsystems are as described in the following paragraphs.

4.3.1.    Interfaces with the Rolling Stock Subsystem

4.3.2.    Interfaces with the Telematics Applications for Freight Subsystem

4.4.    Operating rules

In the light of the Essential Requirements in Chapter 3, the operating rules specific to the subsystem concerned by this TSI are as follows:

4.4.1.    Data quality

For the purposes of data quality assurance, the originator of any TSI message will be responsible for the correctness of the data content of the message at the time when the message is sent. Where the source data for data quality assurance purposes are available from the databases provided as part of the TSI, the data contained within those databases must be used for data quality assurance.

Where the source data for data quality assurance purposes is not supplied by the databases provided as part of this TSI, the originator of the message must carry out the data quality assurance check from their own resources.

Data quality assurance will include comparison with data from databases provided as part of this TSI as described above, plus — where applicable — logic checks to assure the timeliness and continuity of data and messages.

Data are of high quality if they are fit for their intended uses, which means that they:

—	are error-free : accessible, accurate, timely, complete, consistent with other sources, etc.,

—	possess the desired features : relevant, comprehensive, proper level of detail, easy-to-read, easy-to-interpret, etc.

The main characteristics of data quality are:

Accuracy

The information (data) required needs to be captured as economically as possible. This is only feasible if the Primary Data only are recorded, if possible, on one single occasion. Therefore, the Primary Data should be introduced into the system as close as possible to its source, so that they can be fully integrated into any subsequent processing operation.

Completeness

Before sending out messages, the completeness and syntax must be checked using the Metadata. This also avoids unnecessary information traffic on the network.

All incoming messages must also be checked for completeness using the Metadata.

Consistency

Business rules must be implemented in order to guarantee consistency. Double entry should be avoided and the owner of the data should be clearly identified.

The type of implementation of these business rules depends on their complexity. For simple rules, database constraints and triggers are sufficient. In the case of more complex rules, which require data from various tables, validation procedures must be implemented which check the consistency of the data version before interface data are generated and the new data version becomes operational. It must be ensured that transferred data are validated against the defined business rules.

Timeliness

Providing information right on time is important. Insofar as the trigger for data storage or for message sending is event driven directly from the IT system, timeliness is not a problem if the system is designed properly and according the needs of the business processes. However, in most cases, the sending of a message is initiated by an operator or is at least based on additional input from an operator. To fulfil the timeliness requirements, the data must be updated as soon as possible, also in order to guarantee that the actual data content of the messages is current when these messages are sent out automatically by the system.

The response time for enquiries must be addressed for the various applications and user types within the detailed IT specifications. All data updates and exchanges shall be carried out as soon as possible.

Data quality metrics

The detailed IT specifications shall define appropriate percentages for:

4.4.2.    Operating the central repository

The functions of the Central Repository are defined in Section 4.2.21.6 Central repository. For the purpose of data quality assurance, the entity operating the Central Repository shall be responsible for the updating and quality of the Metadata and the directory, and also for the administration of the access control. The quality of the Metadata in terms of completeness, consistency, timeliness and accuracy shall enable appropriate functioning for the purposes of this TSI.

4.5.    Maintenance rules

In the light of the Essential Requirements in Chapter 3, the maintenance rules specific to the subsystem concerned by this TSI are as follows:

The quality of the transport service must be guaranteed, even if the data were corrupted or if the data processing equipment were to suffer a complete or partial breakdown. It is therefore advisable to install duplex systems or computers with a particularly high degree of reliability, and for which uninterrupted operation during maintenance is ensured.

The maintenance aspects of the various databases are mentioned in Section 4.2.19.2 — Additional requirements on the databases, points 10 and 21.

4.6.    Professional qualifications

The professional qualifications of the staff required to operate and maintain the subsystem and for implementing the TSI are as follows:

The implementation of this TSI does not require a complete new system in terms of hardware and software with new staff. Achieving the requirements of the TSI results only in those changes, upgrades or functional enlargements of the operation which are already being made by the existing staff. Therefore, there are no requirements in addition to the existing national and European rules on professional qualifications.

If necessary, add-on training of staff should not consist solely of showing them how to operate equipment. Staff members must know and understand the specific role they have to play in the overall transportation process. Staff must, in particular, be aware of the requirement to maintain a high level of working performance, since this is decisive for the reliability of the information which is to be processed at a later stage.

The professional qualifications needed for the composition and operation of trains are defined in the TSI for Operation and Traffic Management.

4.7.    Health and safety conditions

The health and safety conditions of staff required for the operation and maintenance of the subsystem concerned and for the implementation of the TSI are as follows:

There are no requirements in addition to existing national and Union health and safety rules.

4.8.    Registers of authorised types of vehicles and of infrastructure

Pursuant to Article 34(1) of Directive 2008/57/EC, ‘The Agency shall set up and keep a register of types of vehicles authorised by the Member States for placing in service on the Community rail network’. Pursuant to Article 35(1) of Directive 2008/57/EC, ‘Each Member State shall ensure that a register of infrastructure is published and updated’.

Due to the annual updating and publication of these registers they cannot be used for the Telematics Applications subsystem for passengers. Therefore, this TSI has nothing to do with these registers.

5.   INTEROPERABILITY CONSTITUENTS

5.1.    Definition

According to Article 2(f) of Directive 2008/57/EC, ‘interoperability constituents’ means any elementary component, group of components, subassembly or complete assembly of equipment incorporated or intended to be incorporated into a subsystem, upon which the interoperability of the rail system depends directly or indirectly. The concept of a ‘constituent’ covers both tangible objects and intangible objects such as software’.

5.2.    List of constituents

The interoperability constituents are covered by the relevant provisions of Directive 2008/57/EC.

No interoperability constituents are determined as far as the subsystem ‘Telematics applications for passengers’ is concerned.

Only standard IT equipment is needed in order to fulfil the requirements of this TSI, without any specific aspects for interoperability in the railway environment. This is valid both for hardware components and for the standard software used, such as the operating system and databases. The application software is individual to each user and can be adapted and improved according the individual’s actual functionality and needs. The proposed ‘application integration architecture’ assumes that applications might not have the same internal information model. Application integration is defined as the process of making independently designed application systems work together.

5.3.    Constituents’ performances and specifications

See Section 5.2, not relevant for the TSI Telematics Applications for passenger services.

6.   ASSESSMENT OF CONFORMITY AND/OR SUITABILITY FOR USE OF THE CONSTITUENTS AND VERIFICATION OF THE SUBSYSTEM

6.1.    Interoperability constituents

6.1.1.    Assessment procedures

Not relevant for the TSI Telematics Applications for passenger services.

6.1.2.    Module

Not relevant for the TSI Telematics Applications for passenger services.

6.2.    Subsystem Telematics Applications for passenger services

According to Annex II to Directive 2008/57/EC, the subsystems are broken down into structural and operational areas. The conformity assessment is obligatory for TSIs in the structural area. The subsystem Telematics Applications for passenger services belongs to the functional area and this TSI does not determine any modules for conformity assessment.

7.   IMPLEMENTATION

7.1.    Introduction

This TSI concerns the subsystem telematics applications for passenger services. This subsystem is functional according to Annex II to Directive 2008/57/EC. The application of this TSI therefore does not rely on the notion of new, renewed or upgraded subsystem, as is customary in the case of TSIs related to structural subsystems, except where it is specified in the TSI.

The TSI will be implemented in phases:

7.2.    Phase one — detailed IT specifications, governance and master plan

Phase one has three objectives:

7.2.1.    Project governance of Phase one

The Commission shall establish a steering committee not later than 1 month after the publication of this Regulation in the Official Journal of the European Union, which shall consist of:

This steering committee shall be co-chaired by (a) the Commission and (b) a person nominated by the rail sector representative bodies. The Commission assisted by the members of the steering committee shall draft the rules of procedure of this steering committee, on which the steering committee shall agree. The decisions taken shall be transparent and shall be accompanied by a sound technical and economic justification.

The members of the steering committee may propose to the steering committee that other organisations be included as observers where there are sound technical and organisational reasons for doing so.

7.2.2.    Roles and responsibilities

7.2.2.1.   Stakeholders

7.2.2.2.   European Railway Agency

7.2.2.3.   Commission

▼M2

7.2.3.    Deliverables

The phase 1 deliverables include the following:

▼B

7.2.4.    Milestones

▼M2

7.3.    Phase 2 — Development

All actors concerned shall develop the system following the provisions of the phase 1 deliverables as follows:

▼B

7.4.    Phase 3 — Deployment

All actors concerned shall deploy the system following the amendment of the present TSI.

7.5.    Change Management

7.5.1.    Change Management Process

Change management procedures shall be designed to ensure that the costs and benefits of change are properly analysed and that changes are implemented in a controlled way. These procedures shall be defined, put in place, supported and managed by the European Railway Agency and shall include:

The Change Control Board (CCB) shall be composed of the European Railway Agency, rail sector representative bodies, a ticket representative body, a passenger representative body and Member States. Such an affiliation of the parties shall ensure a perspective on the changes that are to be made and an overall assessment of their implications. The CCB ultimately shall be brought under the aegis of the European Railway Agency.

7.5.2.    Specific Change Management Process for technical documents published by the European Railway Agency

Technical documents quoted in Chapter 4 of this TSI (except for the standards which are linked to open issues) and listed in Annex III to this Regulation are technical documents published by the European Railway Agency pursuant to Article 5(8) of Directive 2008/57/EC.

The change control management for these technical documents shall be established by the European Railway Agency in accordance with the following criteria:

Where change control management affects elements which are in common use within the TAF TSI, the changes shall be made so as to remain as close as possible to the implemented TAF TSI in order to achieve optimum synergies.

7.6.    Specific cases

7.6.1.    Introduction

The following special provisions are permitted in the specific cases below:

(a)	‘P’ cases : permanent cases;

(b)

‘T’ cases : temporary cases, where it is recommended that the target system is reached by 2020 (an objective set out in Decision No 1692/96/EC of the European Parliament and Council of 23 July 1996 on Community guidelines for the development of the trans-European transport network ( 7 ), as amended by Decision No 884/2004/EC ( 8 ).

7.6.2.    List of specific cases

There are no specific cases indicated for this TSI.

8.   GLOSSARY

The definitions in this glossary refer to the use of terms in this TSI.

---

ANNEX II

LIST OF OPEN POINTS

In accordance with Article 5(6) of Directive 2008/57/EC, the following open points are identified:

▼M2

---

ANNEX III

▼B

---

ANNEX IV

LIST OF TARIFFS MEANT FOR INTERNATIONAL OR FOREIGN SALES

▼M2

C.1.    NRT Tariffs

The main content of NRT tariff data shall be:

NRT tariffs shall be made available in advance according to their sales conditions.

▼B

C.2.    IRT Tariffs

The main content of IRT tariff data shall be:

IRT tariffs shall be made available in advance according to their sales conditions.

C.3.    Special Tariffs

The main content of the special tariff data shall be:

Special tariffs shall be made available in advance according to its sales conditions.

▼M2

---

ANNEX V

---

ANNEX VI

Tasks to be undertaken by the TAF/TAP National Contact Point (NCP)

---

( 1 ) OJ L 191, 18.7.2008, p. 1.

( 2 ) OJ L 110, 20.4.2001, p. 1.

( 3 ) OJ L 64, 7.3.2008, p. 72.

( 4 ) OJ L 315, 3.12.2007, p. 14.

( 5 ) OJ L 164, 30.4.2004, p. 1.

( 6 ) OJ L 75, 15.3.2001, p. 29.

( 7 ) OJ L 228, 9.9.1996, p. 1.

( 8 ) OJ L 167, 30.4.2004, p. 1.