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

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:

• — Path Number for the purpose of identifying the path,

• — section of the journey to be cancelled,

• — indication that the path is being cancelled,

• — original path departure point: train’s point of departure on the path,

• — Path destination point,

• — Time of departure from original start point of path: time for which the path was requested,

• — original end point of path: train’s destination on the requested path,

• — Time of arrival at original end point of path: time at which the proposed train was due to arrive at its destination.

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

• — B.30 (see Annex III).

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:

• — Receipt Confirmation message: indicates that its sender has received the message and will act upon it as necessary.

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

• — B.30 (see Annex III).

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:

• — Path Number,

• — Train number of the scheduled train for which the path is no longer available (if already known to the infrastructure manager),

• — Original path departure point: train’s point of departure on the path,

• — Path destination point,

• — Time of departure from original start point of path: time for which the path was requested,

• — Original end point of path: train’s destination on path requested,

• — Time of arrival at original end point of path: time when the proposed train was due to arrive at its destination,

• — Indication of the cause.

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

• — B.30 (see Annex III).

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:

• — reference file of the coding for all infrastructure managers, railway undertakings, station managers, service provider companies,

• — reference file of the coding of locations,

• — reference file of all existing train control systems,

• — reference file of all different locomotive types,

• — reference file of all European maintenance workshops,

• — reference file for European reservation systems,

• — reference file of codes for timetable exchange purposes,

• — reference file of codes for tariff exchange purposes,

• — message-dataset catalogue,

• — directory of code list,

• — any other files and code lists that are needed for the use of the technical document(s) in the annexes (these will be defined during phase one).

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

• — 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.

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:

• — metadata — structured data describing the content of messages,

• — list of electronic addresses where the actors addressed by this TSI allow other actors to obtain information or data according to the provisions of this TSI,

• — encryption,

• — authentication,

• — directory (phonebook) — it contains all necessary information on those participating in exchanging messages and data.

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:

• — message formatting of outgoing messages according to the metadata,

• — signing and encryption of outgoing messages,

• — addressing of outgoing messages,

• — authenticity verification of incoming messages,

• — decryption of incoming messages,

• — conformity checks of incoming messages according to the metadata,

• — handling the single common access to the various databases.

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:

• (i) positive: send ACK;

• (ii) negative: send NACK.

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:

• — For the exchange of timetable information between railway undertakings and other modes of transport: norms EN 12896 (‘Transmodel’) and EN TC 278 WI 00278207 (‘IFOPT — Identification of Fixed Objects in Public transport’),

• — For the exchange of specific timetable data, the XML technical standards and protocols based on Transmodel, in particular norm EN 15531 (‘SIRI’) for the exchange of real-time timetables and norm EN TC 278 WI 00278207 (‘IFOPT’) for the exchange of ‘stop/station’ data.

• — For the exchange of tariff data: this standard is still an open point (see Annex II — List of open points).

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

Table 1

Interfaces with the Rolling Stock subsystem

Interface	Reference Telematics Applications for passengers TSI	Reference Conventional Rail Rolling Stock TSI’s
Board device display	4.2.13  Handling of information provision in vehicle area	4.2.5  Customer information (PRM)
Automatic voice and announcement	4.2.13  Handling of information provision in vehicle area	4.2.5  Customer information (PRM)
Automatic voice and announcement	4.2.13  Handling of information provision in vehicle area	4.2.5.2  Public address system

4.3.2.   Interfaces with the Telematics Applications for Freight Subsystem

Table 2

Interfaces with the Telematics Applications for Freight subsystem

Interface	Reference Telematics Applications for passengers TSI	Reference Conventional Rail Telematics Applications for Freight TSI
Train ready	4.2.14.1  Train ready message for all trains	4.2.3.5  Train ready message
Train running forecast	4.2.15.2  ‘Train running forecast’ message for all trains	4.2.4.2  Train running forecast message
Train running information	4.2.15.1  ‘Train running information’ message for all trains	4.2.4.3  Train running information
Train running interrupted to RU	4.2.16.2  ‘Train running interrupted’ message for all trains	4.2.5.2  Train running interrupted
Handling of short term timetable data	4.2.17  Handling of short term timetable data for trains	4.2.2  Path Request
Common Interface	4.2.21.7  Common interface for RU/IM communication	4.2.14.7  Common interface for RU/IM communication
Central Repository	4.2.21.6  Central repository	4.2.14.6  Central repository
Reference Files	4.2.19.1  Reference files	4.2.12.1  Reference files

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,

• — completeness,

• — consistency,

• — timeliness.

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:

• — the completeness of data (percent of data fields having values entered into them) and the consistency of data (percent of matching values across tables/files/records),

• — the timeliness of data (percent of data available within a specified threshold time frame),

• — the required accuracy (percent of stored values that are correct when compared to the actual value).

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:

• — phase one: detailed IT specifications, governance and master plan,

• — phase two: development,

• — phase three: deployment.

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

Phase one has three objectives:

• 1. To define the data exchange system (hereinafter referred to as ‘the system’) consisting of common components and of the interconnection of information and communication systems of stakeholders able to fulfil the requirements of this Regulation.

• 1. To confirm such a system from the viewpoint of technical and economic feasibility.

• 1. To draw up a roadmap of the activities deemed necessary in order to implement the system, including appropriate milestones for the monitoring of the progress of its implementation by the Commission, the European Railway Agency, the Member States and the stakeholders concerned.

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:

• — the representative bodies from the railway sector acting on a European level as defined in Article 3(2) of Regulation (EC) No 881/2004 (the rail sector representative bodies),

• — a representative of ticket vendors,

• — a representative of European passengers,

• — the European Railway Agency, and

• — the Commission.

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

• 1.A project team established by the rail sector representative bodies and including a ticket vendor representative shall develop the detailed IT specifications, the governance and the master plan on the basis of a work programme to be approved by the steering committee.

• 2.The project team shall set up the necessary working groups bringing in expertise from the European Railway Agency, railway undertakings, infrastructure managers, station managers, ticket vendors workers’ representatives and passenger representatives.

• 3.The project team shall conduct the whole project transparently, and all minutes, documents and deliverables of the project team and its working groups shall be made permanently and fully accessible to the Commission and the European Railway Agency.

• 4.The project team shall send monthly progress reports to the steering committee and shall take full account of the latter’s decisions. The structure and content of the progress report shall be approved by the steering committee at the kick-off meeting.

• 5.The project team shall provide information to railway undertakings, infrastructure managers, station managers, ticket vendors and passenger representatives, and shall consult them. It shall pay particular attention to small railway undertakings and railway undertakings that are not members of rail sector representative bodies, and shall keep them informed and consult them.

• 6.Railway undertakings, infrastructure managers, station managers, ticket vendors and passengers’ representatives shall support the project by providing information, and functional and technical expertise, as and when requested by the project team.

7.2.2.2.   European Railway Agency

• 1.The European Railway Agency shall monitor and assess the development of the detailed IT specifications, governance and master plan with a view to determining whether the objectives pursued have been achieved.

• 2.The European Railway Agency shall submit to the Commission a recommendation on the detailed IT specifications, governance and master plan.

7.2.2.3.   Commission

• 1.The Commission shall indicate to the project team the list of bodies to be involved in the project.

• 2.Upon reception of the detailed IT specifications, governance and master plan, the Commission shall assess them on the basis of the recommendation of the European Railway Agency and, in the light of this assessment, shall take the necessary measures to amend the current TSI.

• 3.The Commission will keep the Member States informed via the committee established in accordance with Article 29(1) of Directive 2008/57/EC.

7.2.3.   Deliverables

The phase 1 deliverables include the following:

• (1) Application guides describing functional, technical and performance specifications, the associated data, the interface requirements, the security and the quality requirements.

• (2) The outline of the global architecture of the system.

• (3) The master plan including:
• — The identification of the activities necessary to achieve the implementation of the system.
• — A migration plan which includes a set of phases that is conducive to intermediate and verifiable tangible results, from the current framework of stakeholders’ information and communication systems to the system itself.
• — A detailed milestone plan.
• — A risk assessment of the crucial phases of the master plan.
• — An assessment of the total lifecycle costs (LCC) associated with the deployment and operation of the system, together with a subsequent investment plan and the relevant cost-benefit analysis.

• (4) The governance deliverable which includes the identification of the appropriate governance structures, methods and procedures to support the development and validation of the system and subsequently its deployment and its field operation and management throughout its lifetime (including dispute management between the parties involved under the provisions of this TSI).

7.2.4.   Milestones

• 1.A kick-off meeting between the project team and the steering committee shall take place not later than 2 months after the publication of this Regulation in the Official Journal of the European Union.

• (a) At the kick-off meeting, the project team shall present a project description and a project work programme including a timetable. The project description shall explain the understanding of the tasks, the project organisation, the roles and responsibilities and the project method, including the process of consulting and informing all stakeholders.

• (b) At the kick-off meeting, the content and level of detail of the intermediate report and of the monthly progress report referred to in Section 7.2.2.1 will be discussed and agreed between the project team and the steering committee.

• 2.The project team shall submit the intermediate report to the steering committee not later than 5 months after the kick-off meeting.

• 3.The deliverables shall be submitted to the Commission and the European Railway Agency not later than 10 months after the kick-off meeting.

• 4.The European Railway Agency shall submit a recommendation on deliverables submitted to the Commission not later than 2 months after receiving them.

7.3.   Phase 2 — Development

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

• (a) Project governance In order to guarantee the appropriate development of the system the governance structure as described in technical document B.61 (see Annex V) shall be progressively implemented by the actors. Roles and responsibilities of all actors shall evolve with the implementation of the new governance structure as described in technical document B.61. The steering committee set up under phase 1 will be maintained in phase 2 until the governance structure described in technical document B.61 is fully operational. Its rules of procedure will be updated also to take into account its new role which is to monitor progress of implementation of the new governance structure, the architecture developed in phase 1 and the development of the system by individual companies taking particularly into account the adherence to the application guides published and maintained by ERA. Before recognising the end of phase 2 the Steering Committee will issue an opinion on the legal status and ownership of the Application Guides. Full compliance with technical document B.61 will be considered as a presumption of conformity of the new governance structure with the requirements of this Regulation. However due to the nature of the document and the continuous need for alignment of the governance structure to the real needs of the market, any deviation from its provisions should be immediately reported to the Steering Committee which will assess the deviation and decide if the technical document and/or its legal status needs to evolve at the end of phase 2.

• (b) Master Plan In order to guarantee the appropriate development of the system all actors concerned shall cooperate and implement the system in full adherence to the master plan as specified in ERA technical document B.62 (see Annex V).

• (c) Development of the system All actors concerned shall cooperate and develop the retail architecture of the system according to the architecture provisions as described in ERA technical document B.60 (see Annex V). All concerned actors shall cooperate and develop the system and its parts as to be as much as possible compliant with the Application Guides as described in the technical documents: B.50 (see Annex III) B.51 (see Annex III) B.52 (see Annex III) B.53 (see Annex III) B.54 (see Annex III) B.55 (see Annex III) B.56 (see Annex III). Full compliance with these technical documents will be considered as a presumption of conformity of the system with the technical requirements of this Regulation. Any deviation from the Application Guides shall be reported to the Steering Committee which will assess it in the context of its role described under item (a). As the Application Guides B.50 to B.56 referred to in Annex III are not mandatory specifications, they are not subject to the Change Control Management.

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 Agency and shall include:

• — the identification of the technical constraints underpinning the change,

• — a statement of who takes responsibility for the change implementation procedures,

• — the procedure for validating the changes to be implemented,

• — the policy for change management, release, migration and roll-out,

• — the definition of the responsibilities for the management of the detailed specifications and for both its quality assurance and configuration management.

The Change Control Board (CCB) shall be composed of the Agency, rail sector representative bodies, a ticket vendor 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 Agency.

7.5.2.   Specific Change Management Process for documents listed in Annex III to this Regulation

The change control management for the documents listed in Annex III to this Regulation shall be established by the Agency in accordance with the following criteria:

• 1. The change requests affecting the documents are submitted either via the Member States or via the representative bodies from the railway sector acting on a European level as defined in Article 38(4) of Regulation (EU) 2016/796 of the European Parliament and of the Council ([^E0003]), or the ticket vendors' representative or via the International Union of Railways (UIC) for error corrections in relation to specifications originally developed by UIC or via the TAP TSI Steering Committee.

• 1. The Agency shall gather and store the change requests.

• 1. The Agency shall present the change requests to the dedicated ERA working party, which will evaluate them and prepare a proposal accompanied by an economic evaluation, where appropriate.

• 1. Afterwards the Agency shall present each change request and the associated proposal to the change control board that will or will not validate or postpone the change request.

• 1. If the change request is not validated, the Agency shall send back to the requester either the reason for the rejection or a request for additional information about the draft change request.

• 1. If the change request is validated, the technical document shall be amended.

• 1. If no consensus about the validation of a change request can be reached, the Agency shall submit to the Commission a recommendation to update the documents listed in Annex III together with the draft new version of the document, the change requests and their economic evaluation and shall make these documents available on their web site.

• 1. The new version of the technical document with the validated change requests shall be made available at the site of the Agency. The Agency will keep the Member States informed via the Committee established in accordance with Article 29(1) of Directive 2008/57/EC.

• 1. If a change request would require a change of the legal text of the TAP TSI, the Agency shall send a request to the European commission to request a revision of the TAP TSI and/or request the technical opinion from the Agency.

Where change control management affects elements which are in common use within the TAF TSI, the changes shall be made so as to remain compliant 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 ([^E0004]), as amended by Decision No 884/2004/EC ([^E0005]).

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.

Term	Description
Access party	Means either a licensed railway undertaking or, to the extent authorised by each Member State, another party seeking to procure a train path in the working timetable for the operation of railway service on its territory with commercial or public-service intent. Examples of such authorised parties may be public authorities, or any other party having an access contract or an international group of such parties, which is also known as an applicant group or access party group
ACID	Stands for Atomicity, Consistency, Isolation, Durability These are the four primary attributes common to any transaction: Atomicity. In a transaction involving two or more discrete pieces of information, either all of the pieces are committed or none are Consistency. A transaction either creates a new and valid state of data or, if any failure occurs, returns all data to the state before the transaction was started Isolation. A transaction in process and not yet committed must remain isolated from any other transaction Durability. Committed data are saved by the system so that, even in the event of a failure and system restart, the data are available in their correct state The ACID concept is described in ISO/IEC 10026-1:1992 Section 4. Each of these attributes can be measured against a benchmark. In general, however, a transaction manager or monitor is designated to implement the ACID concept. In a distributed system, one way to achieve ACID is to use a two-phase commit (2PC), which ensures either that all involved sites must commit to completing the transaction or that none do, and the transaction is rolled back
Arrival date/time, actual	Means the actual date (And time) of arrival of means of transport
Arrival date/time, estimated	Means the date (And time) of arrival of means of transport based on the current forecast
Arrival date/time, planned	Means the date (And time) of arrival of means of transport in the timetable
Arrival delay, expected	Means the time difference between the arrival date/time Estimated and the arrival date/time Planned
Arrival delay, actual	Means the time difference between the arrival date/time actual and the arrival date/time Planned
At the discretion of	Means that the railway undertaking can decide based on its experience and its needs
Attributing system	Means an electronic system hosting the catalogue of transport services for which a transport service provider authorises distributors to issue travel documents
Attributor	Means a company managing an attributing system. May be a carrier
Authorised Public Body	Means a public authority having a statutory obligation or right to provide members of the public with travel information and also refers to the public authority which is responsible for the enforcement of Regulation (EC) No 1371/2007 pursuant to Article 30(1) of the Regulation
Availability	Means the information (transport service, type of offer, tariff, other service) that can actually be obtained by a passenger at a given point in time, for a specific train. Not to be confused with offer, indicating that a (transport service, type of offer, tariff, other service) is offered in the initial planning, but could be sold out and is therefore not obtainable by a passenger at a given time point, for a specific train
Basic parameter	Means any regulatory, technical or operational condition which is critical to interoperability and requires a decision in accordance with the procedure laid down in Article 21(2) before any development of draft TSIs by the joint representative body
Booking (selling)	Means the selling of a ticket with or without a reservation
Carrier	Means the contractual railway undertaking with whom the passenger has concluded a transport contract or a series of successive railway undertakings which are liable on the basis of such a contract
Carrier, Joint	Means a carrier linked by a cooperation agreement to one or more other carriers for the operation of a transport service
Carrier, Sole	Means a carrier that operates a transport service independently of other carriers
Channel	Means the method (such as ticket office machine, on-train media, public web services, telesales, mobile ticketing) by which a service (information, ticket sale, ticket refund, response to complaints, etc.) is provided to the passenger by a railway undertaking
Coach ID	Means the unique identification number of a coach
Commission	Means the European Commission
COTS-product	Means commercial off-the-shelf products
Customer	Means a person who intends to buy, is buying, or has bought a railway product for him/herself or for other person(s). May therefore be different from passenger (see passenger)
Decryption	Means the converting of encrypted data back into their original form
Delay	Means the time difference between the time the passenger was scheduled to arrive according to the published timetable and the time of his/her actual or expected arrival
Delta deviation	Means the operational ‘lateness or earliness’ in relation to the booked scheduled time
Departure date/time, actual	Means the actual date (And time) of departure of means of transport
Departure date/time, estimated	Means the date (And time) of departure of means of transport based on current forecast
Departure date/time, planned	Means the date (And time) of departure of means of transport in the timetable
Directive 2008/57	Means Directive 2008/57/EC of the European Parliament and of the Council of 17 June 2008 on the interoperability of the rail system within the Community
Departure delay, actual	Means the time difference between the actual departure date/time and the Planned departure date/time
Departure delay, expected	Means the time difference from the departure date/time and the expected departure date/time
Display	Means any dynamic visual device located either in Stations or on the inside/outside of trains for the purpose of informing passengers
Distributor	Means an undertaking providing legal and technical capacity to issuers to sell rail products or to provide on line-facilities to customers to buy rail products. Besides, the distributor can offer services to issuers by assembling O-Ds carried out by different carriers into complete journeys as required by the traveller. The distributor may be a carrier
Domestic journey	Means a passenger journey by rail whereby a passenger does not cross a border of a Member State
Domestic rail passenger service	Means a rail passenger service which does not cross a border of a Member State
Encryption	Means the encoding of data
ERA	See European Railway Agency
Essential requirements	Means all the conditions set out in Annex III to Directive 2008/57/EC which must be met by the trans-European rail system, the subsystems, and the Interoperability Constituents including interfaces
ETA	Means the Estimated time of arrival (of the train at the station)
ETH	Means the Estimated time of Handover (of a train from one infrastructure manager to another)
ETI	Means the Estimated time of Interchange (of the train from one railway undertaking to another)
European Railway Agency	Means the Agency established pursuant to Regulation (EC) No 881/2004/EC of the European Parliament and of the Council of 29 April 2004 establishing a European Railway Agency
Fare	Means a charge to be paid for transportation or service
Forecast	Means the best estimate of an event (e.g. arrival, departure or passing time of a train)
Forecast point	Means a target point for which the forecast is generated. It may relate to arrival, departure, passage or handover
Foreign rail passenger service	Means a rail passenger service which was purchased by the passenger in a country, but is performed in a country different from the country of purchase
Foreign sale	Means the sale of a train ticket by an issuer which is not (one of) the carrier(s) operating the train where the ticket will be used. The issuer is located in a country different from the country of the carrier(s)
FTP	Means the File Transfer Protocol A protocol to transfer files between computer systems in the TCP/IP network
Fulfilment	Means the process which delivers the Product to the customer after its purchase
General Conditions of Carriage	Means the conditions of the carrier in the form of general conditions or tariffs legally in force in each Member State and which have become, through the conclusion of the contract of carriage, an integral part of it
Global price train	Means a train that a passenger can board only having purchased a global price ticket
Handover point	Means the point where the responsibility changes from one infrastructure manager to another
HTTP	Means the Hypertext Transfer Protocol The client/server protocol used to connect to servers on the Web
IM	Means any body or undertaking that is responsible in particular for establishing and maintaining railway infrastructure. This may also include the management of infrastructure control and safety systems. The functions of the infrastructure manager on a corridor or part of a corridor may be allocated to different bodies or undertakings
Infrastructure manager (IM)	See IM
Integrated Reservation Tickets — IRT	Means a kind of train ticket restricted to a specific train on a specific date/time. A IRT ticket can only be sold by means of an online transaction between the sales terminal and the attributing system where the relevant train is hosted
Interchange between Carriers	Means the transfer of control from one railway undertaking to another for practical operational, safety and liability reasons. Examples are: — successive railway undertakings, — trains with substitute carriers, — the transfer of information between different railway undertakings
Interchange point	Means the location where the control of the train is transferred from one railway undertaking to another railway undertaking Regarding a train running, the train is taken over from one railway undertaking by the other railway undertaking, which now owns the path for the next section of the journey
Intermediate point	Means the location which defines the start or end point of a journey section. This may be an interchange, handover or handling point, for example
International rail passenger service	Means a rail passenger service which crosses a border of at least one Member State
International journey	Means a passenger journey by rail crossing the border of at least one Member State
International sale	Means the sale of a train ticket for an international journey
Interoperability constituent	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 trans-European rail system directly or indirectly depends. The concept of a constituent covers both tangible objects and intangible objects, such as software
IP	Means the Internet Protocol
Issuer	Means an undertaking selling the ticket and receiving payment. May be a carrier and/or a distributor. The issuer is the undertaking indicated on the ticket with its code and possibly its logo
Journey	Means the movement of a passenger (or several passengers travelling together) from a location A to a location B
Journey planner	Means an IT system able to propose journey solutions A journey solution is a set of one or more commercial transport services answering at least the question ‘How can I go from location A to location B at a given departure/arrival date And time?’. The question could contain more complex additional criteria, such as ‘in the fastest way’, ‘in the cheapest way’, ‘with no changes’, etc. The passenger can build the journey solutions by him/herself, consulting different information sources, or the solution can be offered to him/her by a journey Planner
Keeper	Means the person who, being the owner of a vehicle or having the right to use it, exploits such vehicle economically in a permanent manner as a means of transport and is registered as such in the Rolling Stock Register
Loco ID	Means the unique identification number of a traction unit
Make available	Means the publishing of information or data where access control may be applied
Manifest on list	Means a fulfilment method where the customer makes its purchase in advance (e.g. at home) and receives only a confirmation, usually with a reference code. The undertaking performing this kind of sale provides the TCO with a list of all passengers (and reference codes) admitted on the specific train. The passenger simply manifests his/her desire to be admitted on the train before/after departure at the TCO. TCO checks whether the passenger is allowed to embark/stay on the train
Market price	See Global price
Metadata	This term simply means data about data. It describes data, software services, and other components contained in the enterprise information systems. Examples of the types of Metadata include standard data definitions, location and routing information, and synchronisation management for distributing shared data
Notified bodies	Means the bodies which are responsible for assessing the conformity or suitability for use of the Interoperability Constituents or for appraising the EC procedure for verification of the subsystems
NRT train	Means a train that a passenger can board having bought a NRT ticket, in the case of international or foreign sales
NRT	Non-integrated reservation tickets — This is a way of selling train tickets meant for international or foreign sales, where the issuer can produce the ticket locally, without any online transaction with an attributing system. The NRT tickets are always open tickets, i.e. the contract of carriage is valid on any NRT train serving the route marked on the ticket, within a defined validity period. To issue a NRT ticket the issuer needs a list of OD’s (series) and one or more tables of prices corresponding to distance ranges. Reservations can (in some cases must) be purchased together with the ticket
Offer	See availability
Official website	Means the company’s public website where commercial information is released to the customer. The website shall be machine readable by respecting web content accessibility guidelines
One stop shop	An international partnership between rail infrastructure managers providing a single point of contact for rail customers for the purposes of: ordering specified train paths in international freight traffic, monitoring the movement of the entire train, generally also invoicing track access charges on behalf of infrastructure managers
Passenger	Means a person who intends to make, or is making, or has made a journey using the transport services and other services of one or more railway undertakings May be different from customer (see customer)
Path	Means the infrastructure capacity needed to run a train between two places over a given time-period (route defined in time and space)
Path number	Means the number of the defined train path
Payment	Means the transfer of wealth from one party (such as a customer) to another (such as a distributor). A payment is usually made in exchange for the provision of transport or service
Peer-to-Peer	Means a class of systems and applications that employ distributed resources to perform a critical function in a decentralised manner
Person with reduced mobility (PRM)	Means any person whose mobility when using transport is reduced due to any physical disability (sensory or locomotory, permanent or temporary), intellectual disability or impairment, or any other cause of disability, or as a result of age, and whose situation needs appropriate attention and adaptation to its particular needs of the service made available to all passengers
Platform	Means the area at a station to alight from/board trains
Primary data	Means the basic data as reference data input for messages or as the basis for functionality and calculation of derived data
PRM	See Person with reduced mobility
Product	Means a type of train with determined types of services (e.g. high speed, bicycle storage places, PRM accommodation, couchette and/or sleeping cars, dining cars, take-away facilities, etc.) which are linked to relevant prices and may be linked to specific conditions
Publish	Means the publishing of information or data where no access control shall be applied
Rail system	Means (as in ‘trans-European rail system’) the structure, as described in Annex I (Directive 2008/57/EC), composed of lines and fixed installations, of the trans-European transport network, built or upgraded for conventional rail transport and combined rail transport, plus the rolling stock designed to travel on that infrastructure
Railway undertaking	Means any public or private undertaking the principal business of which is to provide services for the transport of goods and/or passengers by rail, with a requirement that the undertaking must ensure traction; this also includes undertakings which provide traction only
Regular vs. Short Term processes	Regular means a process when performed within a period which is equal to or more than 7 days Short term means a process when performed within a period which is less than 7 days
Reporting point	Means either passing points used by an infrastructure manager to provide train running information (only) or points where forecasts are generated
Repository	Means the storage of data similar to a database and data dictionary; however, it usually encompasses a comprehensive information management system environment. It must include not only descriptions of data structures (i.e. entities and elements), but also Metadata of interest to the enterprise, data screens, reports, programs, and systems
Reservation	Means an authorisation on paper or in electronic form giving entitlement to a service (transportation or assistance) subject to a previously confirmed personalised transport arrangement
Reservation system	Means a computerised system used to store and retrieve information and conduct transactions related to travel. A reservation system is capable of keeping inventory correct in real time, and is accessible to agents/retailers around the world
Retailer	Means a person or an undertaking that sells to the customer a ticket without or with a reservation for a rail service. A retailer can be a railway undertaking (agent) or an accredited travel agent
Route	Means the geographical line to be taken from a starting point to a point of destination
Route section	Means a part of a route
RU	See Railway undertaking
Selling	See Booking
Service	See Transport service
Service provider	Means the responsible entity providing any services linked to the transport of passengers
Shall	Means that the definition is an absolute requirement of the specification
Short Term processes	See Regular vs. Short Term processes
Short notice path request	Means the individual request for a path according to Article 23 of Directive 2001/14/EC due to additional transport demands or operational needs
SQL	Means Structured Query Language A language devised by IBM, then standardised by ANSI and ISO, which is used for creating, managing and retrieving data in relational databases
Stakeholders	Means any person or organisation with a reasoned interest in train service delivery e.g.: — Railway undertaking, — Locomotive provider, — Coach provider, — Driver/train crew provider, — Infrastructure manager (IM), — Fleet manager, — Ferry boat operator, — Worker, — Ticket vendor, — Passenger
Station	Means a railway location where a passenger train can start, stop or end
Station manager	Means an organisational entity in a Member State, which has been made responsible for the management of a railway station and which may be the infrastructure manager
Substitute carrier	Means a railway undertaking, which has not concluded a transport contract with the passenger, but to whom the railway undertaking that is party to the contract has entrusted, in whole or in part, the performance of the transport by rail
Tariff	Means a specific set of fares available on a given train, on a given day for a given O-D leg of the journey. Tariffs may be grouped in different categories (such as public fares, Group fares, etc.)
TCO	Means Ticket Controlling Organisation. This is an organisation empowered to inspect passenger tickets. Mostly a carrier. If necessary, the TCO is to deliver security certificates for the International Rail Ticket for Home Printing (IRTHP) to the distributors
Technical Document	Means any technical document published by the European Railway Agency pursuant to Article 5(8) of Directive 2008/57
Technical Specification for Interoperability	Means a specification adopted in accordance with Directive 2008/57/EC by which each subsystem or part subsystem is covered in order to meet the Essential Requirements and ensure the interoperability of the rail system
TETA	See train Estimated time of arrival
Third party	Means any public or private undertaking, which is not a railway undertaking or infrastructure manager and provides services ancillary to, or in connection with, the services/transport services
Through ticket	Means a ticket or tickets representing a transport contract for successive railway services operated by one or more railway undertakings
Ticket	Means a material or immaterial registration entitling a passenger to contractually use one or more commercial transport services offered by one or more railway undertakings
Ticket On departure	Means a fulfilment method where the customer makes its purchase in advance (e.g. at home) and collects the ticket in the departure Station, at a ticket counter or vending machine
Ticket vendor	Means any retailer of rail transport services concluding transport contracts and selling tickets on behalf of a railway undertaking or for its own account
Timetable	Means the list of commercial transport services offered by a railway undertaking during a given time interval
TOD	See Ticket On Departure
Tour Operator	Means an organiser or retailer, other than a railway undertaking, within the meaning of Article 2, points (2) and (3) of Directive 90/314/EEC
Train Estimated time of Arrival	Means the Estimated time of arrival of a train at a specific point, e.g. handover point, interchange point, train destination
Train path	Means the train route defined in time and space
Train running interrupted	Means that the continuation of the train is unknown based on local circumstances at the time and in the opinion of the parties involved. If the Delay is known, the infrastructure manager sends a train running forecast message
Trans-European rail network	Means the rail network as described in Annex 1 to Directive 2008/57/EC
Transport contract	Means a contract of carriage for consideration or free of charge between a railway undertaking or a ticket vendor and the passenger for the provision of one or more transport services
Transport mode	Means a generic type of vehicle capable of transporting passengers (train, plane, bus, etc.)
Transport service	Means a commercial transport service or transport service under public service contract linking two or more locations, offered by a railway undertaking according to a published timetable. A transport service is normally performed with a specific transport mode
Transport service provider	Means any private or public company authorised to transport people in domestic or international passenger traffic. A ‘transport service provider’ accepts travel documents issued by the accredited sales points of its distributors. It plays the role of the contractual carrier with which the passenger has entered into a contract of carriage. Execution of the transport service may be entrusted, in part or in full, to a substitute carrier
TSI	See Technical Specification for Interoperability
XML	Means the Extended Mark-up Language
XQL	Means the Extended Structured Query Language

ANNEX II

LIST OF OPEN POINTS

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