COMMISSION REGULATION (EU) No 1305/2014

12.12.2014 | EN | Official Journal of the European Union | L 356/438 ---|---|---|--- * * * COMMISSION REGULATION (EU) No 1305/2014 of 11 December 2014 on the technical specification for interoperability relating to the telematics applications for freight subsystem of the rail system in the European Union and repealing the Regulation (EC) No 62/2006 (Text with EEA relevance) THE EUROPEAN COMMISSION, Having regard to the Treaty on the Functioning of the European Union, Having regard to 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 (1), and in particular Article 6(1) thereof, Whereas: (1) | Pursuant to Article 2(e) of Directive 2008/57/EC, the rail system is subdivided into structural and functional subsystems. Each of the subsystems should be covered by a technical specification for interoperability (TSI). ---|--- (2) | Commission Regulation (EC) No 62/2006 (2) has established the technical specifications for interoperability relating to the telematics applications for freight subsystem of the trans-European rail system. ---|--- (3) | The European Railway Agency (the Agency) received a mandate in 2010 to review the technical specifications for interoperability (TSI) for the ‘telematics applications for freight’ (TAF) subsystem in accordance with Article 6(1) of Directive 2008/57/EC. ---|--- (4) | On 10 December 2013, the Agency issued a recommendation ERA/REC/106 — 2013/REC to update Annex A to Regulation (EC) No 62/2006. ---|--- (5) | The TSI TAF should not require the use of specific technologies or technical solutions except where this is necessary for the interoperability of the European rail system. ---|--- (6) | The rail sector representative bodies have defined the Master plan for the implementation of the TSI TAF. This Master plan indicates the stages required to move from a fragmented national approach to a seamless information exchange across the European rail system. ---|--- (7) | The TSI TAF is based on the best available expert knowledge. Technological and operational developments could however make further amendments to this TSI TAF necessary. A Change Control Management process should therefore be devised to consolidate and update the requirements of the TSI TAF. ---|--- (8) | All players, especially small freight operators not members of European railway sector representative bodies, should be informed of their obligations in relation with the TSI TAF. ---|--- (9) | Regulation (EC) No 62/2006 should therefore be repealed. ---|--- (10) | The measures provided for in this Regulation are in accordance with the opinion of the Committee established in accordance with Article 29(1) of Directive 2008/57/EC, ---|--- HAS ADOPTED THIS REGULATION: Article 1 Subject matter The technical specification for interoperability (TSI) relating to the ‘telematics applications for freight’ subsystem of the European rail system as set out in the Annex, is hereby adopted. Article 2 Scope 1\. The TSI shall apply to the subsystem ‘telematics applications’ of the rail system in the European Union as defined in Section 2.6(b) of Annex II to Directive 2008/57/EC. 2\. The TSI shall apply to the following networks: (a) | the trans-European conventional rail system network as defined in Annex I, Section 1.1 of Directive 2008/57/EC; ---|--- (b) | the trans-European high-speed rail system network as defined in Annex I, Section 2.1 of Directive 2008/57/EC; ---|--- (c) | other parts of the network of the rail system in the Union. ---|--- The TSI shall not apply to the cases referred to in Article 1(3) of Directive 2008/57/EC. 3\. The TSI shall apply to networks with the following nominal track gauges: 1 435 mm, 1 520 mm, 1 524 mm, 1 600 mm and 1 668 mm Article 3 Update and reporting on technical documents The Agency shall make available via its website the Location codes and Company codes as referred to in point 4.2.11.1 (items b and d) and the technical documents referred to in Section 7.2 of the Annex and shall report to the Commission on their progress. The Commission shall inform the Member States about this progress through the Committee established in accordance with Article 29(1) of Directive 2008/57/EC. Article 4 Compliance with networks in non-EU countries With regard to railway freight services operated from or to third countries, compliance with the requirements of the TSI set out in the Annex is subject to the availability of information from entities outside the European Union unless bilateral agreements provide information exchange compatible with that TSI. Article 5 Implementation 1\. The Agency shall assess and oversee the implementation of this Regulation to determine whether the agreed objectives and deadlines have been achieved and shall provide an assessment report to the TAF steering committee referred to in Section 7.1.4 of the Annex. 2\. The TAF steering committee shall assess the implementation of this Regulation, based on the assessment report provided by the Agency, and shall take the appropriate decisions for further actions to be taken by the sector. 3\. Member States shall ensure that all railway undertakings, infrastructure managers operating and wagon keepers registered on their territory are informed of this Regulation and shall designate a National Contact Point for the follow-up of its implementation as described in Appendix III. 4\. Member States shall send to the Commission a report on the implementation of this Regulation by 31 December 2018. This report shall be discussed in the Committee established in accordance with Article 29(1) of Directive 2008/57/EC. Where appropriate, the TSI set out in the Annex to this Regulation shall be adapted. Article 6 Repeal Regulation (EC) No 62/2006 is repealed from the entry into force of this Regulation. Article 7 Entry into force and application This Regulation shall enter into force on the twentieth day following that of its publication in the Official Journal of the European Union. It shall apply from 1 January 2015. This Regulation shall be binding in its entirety and directly applicable in all Member States. Done at Brussels, 11 December 2014. For the Commission The President Jean-Claude JUNCKER * * * (1) OJ L 191, 18.7.2008, p. 1. (2) Commission Regulation (EC) No 62/2006 of 23 December 2005 concerning the technical specification for interoperability relating to the telematic applications for freight subsystem of the trans-European conventional rail system (OJ L 13, 18.1.2006, p. 1). * * * ANNEX TABLE OF CONTENTS 1. | INTRODUCTION | 443 ---|---|--- 1.1. | Abbreviations | 443 ---|---|--- 1.2. | Reference Documents | 444 ---|---|--- 1.3. | Technical scope | 445 ---|---|--- 1.4. | Geographical Scope | 445 ---|---|--- 1.5. | Content of this TAF TSI. | 445 ---|---|--- 2. | DEFINITION OF SUBSYSTEM AND SCOPE | 446 ---|---|--- 2.1. | Function within the scope of the TSI | 446 ---|---|--- 2.2. | Functions outside the scope of the TSI | 446 ---|---|--- 2.3. | Overview of the subsystem description | 446 ---|---|--- 2.3.1. | Involved Entities | 446 ---|---|--- 2.3.2. | Considered Processes | 448 ---|---|--- 2.3.3. | General remarks | 449 ---|---|--- 3. | ESSENTIAL REQUIREMENTS | 450 ---|---|--- 3.1. | Compliance with the essential requirements | 450 ---|---|--- 3.2. | Essential requirements aspects | 450 ---|---|--- 3.3. | Aspects relating to general requirements | 451 ---|---|--- 3.3.1. | Safety | 451 ---|---|--- 3.3.2. | Reliability and availability | 451 ---|---|--- 3.3.3. | Health | 451 ---|---|--- 3.3.4. | Environmental protection | 451 ---|---|--- 3.3.5. | Technical compatibility | 451 ---|---|--- 3.4. | Aspects relating specifically to the Telematics Applications Subsystem for Freight | 451 ---|---|--- 3.4.1. | Technical compatibility | 451 ---|---|--- 3.4.2. | Reliability and availability | 451 ---|---|--- 3.4.3. | Health | 452 ---|---|--- 3.4.4. | Safety | 452 ---|---|--- 4. | CHARACTERISATION OF THE SUBSYSTEM | 452 ---|---|--- 4.1. | Introduction | 452 ---|---|--- 4.2. | Functional and technical specifications of the subsystem | 452 ---|---|--- 4.2.1. | Consignment Note data | 453 ---|---|--- 4.2.2. | Path Request | 454 ---|---|--- 4.2.3. | Train Preparation | 455 ---|---|--- 4.2.4. | Train Running Forecast | 456 ---|---|--- 4.2.5. | Service Disruption Information | 457 ---|---|--- 4.2.6. | Shipment ETI/ETA | 458 ---|---|--- 4.2.7. | Wagon Movement | 459 ---|---|--- 4.2.8. | Interchange Reporting | 460 ---|---|--- 4.2.9. | Data Exchange for Quality Improvement | 461 ---|---|--- 4.2.10. | The Main Reference Data | 462 ---|---|--- 4.2.11. | Various Reference Files and Databases | 463 ---|---|--- 4.2.12. | Networking & Communication | 466 ---|---|--- 4.3. | Functional and technical specifications of the interfaces | 468 ---|---|--- 4.3.1. | Interfaces with the TSI Infrastructure | 468 ---|---|--- 4.3.2. | Interfaces with the TSI Control/Command and Signalling | 468 ---|---|--- 4.3.3. | Interfaces with the rolling stock subsystem | 468 ---|---|--- 4.3.4. | Interfaces with the TSI operation and traffic management | 468 ---|---|--- 4.3.5. | Interfaces with the Telematics Applications for Passenger Services | 469 ---|---|--- 4.4. | Operating rules | 469 ---|---|--- 4.4.1. | Data quality | 469 ---|---|--- 4.4.2. | Operating the central repository | 471 ---|---|--- 4.5. | Maintenance rules | 471 ---|---|--- 4.6. | Professional qualifications | 471 ---|---|--- 4.7. | Health and safety conditions | 471 ---|---|--- 5. | INTEROPERABILITY CONSTITUENTS | 471 ---|---|--- 5.1. | Definition | 471 ---|---|--- 5.2. | List of Constituents | 471 ---|---|--- 5.3. | Constituents' Performances and Specifications | 472 ---|---|--- 6. | ASSESSMENT OF CONFORMITY AND/OR SUITABILITY FOR USE OF THE CONSTITUENTS AND VERIFICATION OF THE SUBSYSTEM | 472 ---|---|--- 6.1. | Interoperability Constituents | 472 ---|---|--- 6.1.1. | Assessment Procedures | 472 ---|---|--- 6.1.2. | Module | 472 ---|---|--- 6.1.3. | Subsystem Telematics Applications for Freight | 472 ---|---|--- 7. | IMPLEMENTATION | 473 ---|---|--- 7.1. | Modalities of Application of this TSI | 473 ---|---|--- 7.1.1. | Introduction | 473 ---|---|--- 7.1.2. | Phase one — detailed IT specifications and master plan | 473 ---|---|--- 7.1.3. | Phases 2 and 3 — Development and deployment | 473 ---|---|--- 7.1.4. | Governance, roles and responsibilities | 473 ---|---|--- 7.2. | Change Management | 475 ---|---|--- 7.2.1. | Change Management Process | 475 ---|---|--- 7.2.2. | Specific Change Management Process for documents listed in Appendix I to this Regulation | 475 ---|---|--- Appendix I: | List of technical documents | 476 ---|---|--- Appendix II: | Glossary | 477 ---|---|--- Appendix III: | Tasks to be undertaken by the TAF/TAP National Contact Point (NCP) | 488 ---|---|--- 1\. INTRODUCTION 1.1. Abbreviations Table 1 Abbreviations Abbreviation | Definition ---|--- ANSI | American National Standards Institute CI | Common Interface CR | Change Request EC | European Commission ERA | European Railway Agency (also referred to as Agency) ERTMS | European Rail Traffic Management System ETCS | European Train Control System IM | Infrastructure Manager ISO | International Organisation for Standardisation LAN | Local Area Network LCL | Less than Container Loads LRU | Lead Railway Undertaking ONC | Open Network Computing OTIF | Intergovernmental Organisation for International Carriage by Rail PVC | Permanent Virtual Circuit RISC | Rail Interoperability and Safety Committee RU | Railway Undertaking TAF | Telematics Applications for Freight TAP | Telematics Applications for Passengers TCP/IP | Transmission Control Protocol/Internet Protocol TEN | Trans European Network TSI | Technical Specification for Interoperability WK | Wagon Keepers WP | Working Party organised by ERA 1.2. Reference Documents Table 2 Reference documents Ref. No | Document Reference | Title | Last Issue ---|---|---|--- (1) | Directive 2008/57/EC | 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 (OJ L 191, 18.7.2008, p. 1). | 17.6.2008 (2) | TAP TSI Regulation (EU) No 454/2011 | 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 (OJ L 123, 12.5.2011, p. 11). | 5.5.2011 (3) | Directive 2012/34/EU | Directive 2012/34/EU of the European Parliament and of the Council of 21 November 2012 establishing a single European railway area (OJ L 343, 14.12.2012, p. 32). | 21.11.2012 (4) | ERA-TD-105 | TAF TSI — ANNEX D.2: APPENDIX F — TAF TSI DATA AND MESSAGE MODEL. | 22.3.2013 (5) | TAF TSI Regulation No 62/2006 | Commission Regulation (EC) No 62/2006 of 23 December 2005 on the technical specification for interoperability relating to the telematics applications for freight subsystem of the trans-European conventional rail system (OJ L 13, 18.1.2006, p. 1). | 18.1.2006 (6) | Commission Regulation (EU) No 280/2013 | Commission Regulation (EU) No 280/2013 of 22 March 2013 amending Regulation (EC) No 62/2006 concerning the technical specification for interoperability relating to the telematics applications for freight subsystem of the trans-European conventional rail system (OJ L 84, 23.3.2013, p. 17). | 22.3.2013 (7) | Commission Regulation (EU) No 328/2012 | Commission Regulation (EU) No 328/2012 of 17 April 2012 amending Regulation (EC) No 62/2006 concerning the technical specification for interoperability relating to the telematic applications for freight subsystem of the trans-European conventional rail system (OJ L 106, 18.4.2012, p. 14). | 17.4.2012 (8) | C(2010)2576 final | Commission Decision of 29 April 2010 concerning a mandate to the European Railway Agency to develop and review Technical Specifications for Interoperability with a view to extending their scope to the whole rail system in the European Union. | 29.4.2010 (9) | Directive 2004/49/EC | Directive 2004/49/EC of the European Parliament and of the Council of 29 April 2004 on safety on the Community's railways and amending Council Directive 95/18/EC on the licensing of railway undertakings and Directive 2001/14/EC on the allocation of railway infrastructure capacity and the levying of charges for the use of railway infrastructure and safety certification (Railway Safety Directive) (OJ L 164, 30.4.2004, p. 44). | 28.11.2009 (10) | Directive 2001/13/EC | Directive 2001/13/EC of the European Parliament and of the Council of 26 February 2001 amending Council Directive 95/18/EC on the licensing of railway undertakings (OJ L 75, 15.3.2001, p. 26). | 26.2.2001 1.3. Technical scope This Technical Specification for Interoperability (hereinafter referred to as the TAF TSI) concerns the element ‘applications for freight services’ of the subsystem ‘telematics applications’ included in the functional area of the list in Annex II to Directive 2008/57/EC (1). The purpose of this TAF TSI is to ensure the efficient interchange of information by setting the technical framework, to achieve a transport process that is as economically viable as possible. It covers the applications for freight services and the management of connections with other modes of transport which means that it concentrates on the transport services of an RU in addition to the pure operation of trains. Safety aspects are only considered as far as the existence of data elements; values will have no impact on the safe operation of a train and compliance with TAF TSI requirements cannot be regarded as compliance with safety requirements. TAF TSI also has an impact on the conditions of use of rail transport by users. In this respect the term users means not only infrastructure managers or railway undertakings but also all other service providers such as wagon companies, intermodal operators and even customers. The technical scope of this TSI is further defined in Article 2(1) and 2(3) of this Regulation. 1.4. Geographical Scope The geographical scope of this TSI is the network of the whole rail system, composed of: — | the trans-European conventional rail system network (TEN) as described in Annex I Section 1.1 ‘Network’ of Directive 2008/57/EC (1), ---|--- — | the trans-European high-speed rail system network (TEN) as described in Annex I Section 2.1 ‘Network’ of Directive 2008/57/EC (1), ---|--- — | other parts of the network of the whole rail system, following the extension of scope as described in Annex I Section 4 of Directive 2008/57/EC (1). ---|--- The cases referred to in Article 1(3) of Directive 2008/57/EC (1) are excluded. 1.5. Content of this TAF TSI The content of this TAF TSI is in accordance with Article 5 of Directive 2008/57/EC (1). This TSI also comprises, in Chapter 4 the characterisation of the subsystem, the operating and maintenance requirements specific to the scope indicated in paragraphs 1.1 (Technical scope) and 1.2 (Geographical Scope). 2\. DEFINITION OF SUBSYSTEM AND SCOPE 2.1. Function within the scope of the TSI The subsystem Telematics Applications for Freight is defined in Annex II of the Directive 2008/57/EC (1), Section 2.5 (b). It includes in particular: — | applications for freight services, including information systems (real-time monitoring of freight and trains), ---|--- — | marshalling and allocation systems, whereby under allocation systems is understood train composition, ---|--- — | reservation systems, whereby here is understood the train path reservation, ---|--- — | management of connections with other modes of transport and production of electronic accompanying documents. ---|--- 2.2. Functions outside the scope of the TSI Payment and invoicing systems for customers are not within the scope of this TSI, nor are such systems for payment and invoicing between various service providers such as railway undertakings or infrastructure managers. The system design behind the data exchange in accordance with Chapter 4.2 (Functional and technical specifications of the subsystem), however, provides the information needed as a basis for payment resulting from the transport services. The long term planning of the timetables is outside the scope of this Telematics Applications TSI. Nevertheless at some points there will be reference to the outcome of the long term planning in so far as there is a relationship with the efficient interchange of information required for the operation of trains. 2.3. Overview of the subsystem description 2.3.1. Involved Entities This TSI takes into account the present service providers and the various possible service providers of the future involved in freight transport such as (this list is not exhaustive): — | Wagons ---|--- — | Locomotives ---|--- — | Drivers ---|--- — | Switching and Hump shunting ---|--- — | Slot selling ---|--- — | Shipment management ---|--- — | Train composition ---|--- — | Train Operation ---|--- — | Train monitoring ---|--- — | Train controlling ---|--- — | Shipment monitoring ---|--- — | Inspections & Repair of Wagon and/or Locomotive ---|--- — | Customs clearance ---|--- — | Operating Intermodal Terminals ---|--- — | Haulage management ---|--- Some specific service providers are defined explicitly in Directives 2012/34/EU (3), 2008/57/EC (1) and 2004/49/EC (9). Since these directives have to be taken into account, this TSI considers in particular the definition of: | Infrastructure Manager (IM) (Directive 2012/34/EU (3)) means any body or firm responsible in particular for establishing, managing and maintaining railway infrastructure, including traffic management and control-command and signalling; the functions of the infrastructure manager on a network or part of a network may be allocated to different bodies or firms. Where the infrastructure manager, in its legal form, organisation or decision-making functions, is not independent of any railway undertaking, the functions referred to in Sections 2 and 3 of Chapter IV shall be performed respectively by a charging body and by an allocation body that are independent in their legal form, organisation and decision-making from any railway undertaking; Based on this definition, this TSI regards an IM as the service provider for the allocation of paths, for controlling/monitoring the trains and for train/path related reporting. ---|--- | Applicant (Directive 2012/34/EU (3)) means a railway undertaking or an international grouping of railway undertakings or other persons or legal entities, such as competent authorities under Regulation (EC) No 1370/2007 and shippers, freight forwarders and combined transport operators, with a public- service or commercial interest in procuring infrastructure capacity; ---|--- | Railway Undertaking (Directive 2004/49/EC (9)) means railway undertaking as defined in Directive 2001/14/EC, and any other public or private undertaking, the activity of which is to provide transport of goods and/or passengers by rail on the basis that the undertaking must ensure traction; this also includes undertakings which provide traction only;. Based on this definition, this TSI regards the RU as the service provider for operating trains. ---|--- Regarding the allocation of a train path for running a train Article 38 of the Directive 2012/34/EU (3) also has to be taken into account: Infrastructure capacity shall be allocated by an infrastructure manager. Once allocated to an applicant, it shall not be transferred by the recipient to another undertaking or service. Any trading in infrastructure capacity shall be prohibited and shall lead to exclusion from the further allocation of capacity. The use of capacity by a railway undertaking when carrying out the business of an applicant which is not a railway undertaking shall not be considered as a transfer. In relation to the communication scenarios between infrastructure managers and applicants in the execution mode of a transport, only the IM and the RU have to be considered and not all types of applicants, which may be relevant for the planning mode. In the execution mode a defined IM — RU relationship is always given, for which the message exchange and the information storage is specified in this TSI. The definition of an applicant and the resulting path allocation possibilities remain uninfluenced. Various services have to be provided for a freight transport. One for example is the provision of wagons. This service can be related to a fleet manager. If this service for a transport is one of the services offered by the RU, the RU acts also as fleet manager. A fleet manager again can manage his own wagons and/or wagons from another keeper (another service provider for freight wagons). The needs for this kind of service provider are taken into account independent of whether the legal entity of the fleet manager is an RU or not. This TSI does not create new legal entities and does not oblige an RU to involve external service providers for services which the RU itself offers but it does name, where necessary, a service by the name of a related service provider. If the service is offered by an RU, the RU acts as the service provider for that service. When taking into account the needs of a customer, one of the services is to organise and manage the transport line according to the commitment to the customer. This service is provided by the Lead Railway Undertaking (Lead RU or LRU). The LRU is the single point of contact for the customer. If more than one railway undertaking is involved in the transport chain, the LRU is also responsible for the co-ordination with the other railway undertakings. This service can also be undertaken by a forwarder or by any other entity. The involvement of an RU as LRU can differ from one type of transport flow to another. In the Intermodal business the managing of capacity in block trains and the preparing of waybills is done by an Intermodal service integrator, who could then be customer for the LRU. The main point, however, is that the RUs and the IMs and all other Service Providers (in the sense as defined in this Annex) must work together, either through cooperation and/or open access, as well as through efficient interchange of information, to deliver seamless services to the customer. 2.3.2. Considered Processes This TSI for the railway freight transport industry is limited in accordance with Directive 2008/57/EC (1) to IMs and RUs/LRUs with reference to their direct customers. Under contractual agreement the LRU shall provide information to the Customer in particular: — | Path information. ---|--- — | Train Running Information on agreed reporting points, including at least departure, interchange/handover and arrival points of the contracted transport. ---|--- — | Estimated Time of Arrival (ETA) to the final destination including yards and intermodal terminals. ---|--- — | Service Disruption. When the Lead RU learns about a service disruption, it shall deliver to the Customer in due time. ---|--- For the delivery of this information, the respective TAF compliant messages are defined in Chapter 4. In the operation of freight services, the activity of an LRU, regarding a consignment, starts with the receipt of the consignment note from its customer and, for example, for wagon loads with the release time of the wagons. The LRU creates a preliminary trip plan (based on experience and/or contract) for the transport journey. If the LRU intends to have the wagon load in a train under Open Access mode (the LRU operates the train for the complete journey), the preliminary trip plan is per se the final one. If the LRU intends to put the wagon load in a train which involves the cooperation of other RUs, he first has to find out which RUs he should address and at what time an interchange between two successive RUs can occur. The LRU then prepares the preliminary consignment orders individually for each RU as subsets of the full consignment note. The consignment orders are specified in Chapter 4.2.1 (Consignment Note data). The addressed RUs check the availability of the resources for the operation of the wagons and the availability of the train path. The responses from the various RUs enable the LRU to refine the trip plan or to start the interrogation anew — perhaps even with other RUs — until the trip plan finally fits customer requirements. The RUs/LRUs must in general have, at minimum, the capability of, — | DEFINING: services in terms of price and transit times, wagon supply (where applicable), wagon/Intermodal unit information (location, status and the wagon/Intermodal unit related estimated time of arrival ‘ETA’), where shipments can be loaded on empty wagons, containers etc., ---|--- — | DELIVERING: the service that has been defined in a reliable, seamless manner through the use of common business processes and linked systems. There must be a capability for RUs, IMs and other service providers and stakeholders such as customs to exchange information electronically, ---|--- — | MEASURING: the quality of the service delivered compared to what was defined. i.e. billing accuracy against price quoted, actual transit times against commitments, wagon ordered against supplied, ETAs against actual arrival times, ---|--- — | OPERATING: in a productive manner in terms of utilisation: train, infrastructure and fleet capacity through the use of business processes, systems and data exchange required to support wagon/Intermodal unit and train scheduling. ---|--- The RUs/LRUs as an applicant must also provide (through contracts with IMs) the required train path and must operate the train within their journey section. For the train path they may use already booked paths (in planning mode) or they have to request an ad hoc train path from the infrastructure manager(s) (IMs) relevant for the journey section(s) over which the RU operates the train. In Appendix I an example is given for the path request scenario. The path ownership is also important for the communication during the train running between IM and RU. The communication must always be based on train and path number, whereby the IM communicates with the RU, who has booked the train path on his infrastructure (see also Appendix I). If an RU provides the complete journey A — F (Open Access by RU, no other RUs are involved), then each IM involved communicates directly with this RU only. This ‘open access’ by the RU can be realised by booking the train path via ‘One Stop Shop’ or in sections with each IM directly. The TSI takes both cases into account as it is shown in Chapter 4.2.2.1: Path Request, Preliminary remarks. The dialogue process between RUs and IMs for establishing a train path for a freight train is defined in Chapter 4.2.2 (Path Request). This function refers to Article 48(1) of Directive 2012/34/EU (3). The dialogue process excludes obtaining the licence for an RU providing services in accordance with Directive 2001/13/EC (10), the certification according to Directive 2012/34/EU (3) and access rights according to Directive 2012/34/EU (3). In Chapter 4.2.3 (Train Preparation) the information exchange relating to the train composition and the train departure procedure is defined. The data exchange during the running of a train in the case of normal operation is given in Chapter 4.2.4 (Train Running Forecast) and for exceptions the messages are defined in Chapter 4.2.5 (Service Disruption Information). All these messages are exchanged between RU and IM and based on trains. For a customer the most important information is the estimated time of arrival (ETA) for his shipment. From the information exchange between LRU and IM (in case of Open Access) an ETA can be calculated. In the case of cooperation mode with various RUs, the ETA and also the estimated times of interchange (ETIs) can be determined from the message exchange between RUs and IMs and provided to the LRU by the RUs, (Chapter 4.2.6 Shipment ETI/ETA). Also based on the information exchange between IM and RU, the LRU knows for example: — | when the wagons departed from or arrived at a yard or at defined locations (Chapter 4.2.7 Wagon Movement), ---|--- — | when the responsibility for the wagons was transferred from one RU to the next RU in the transport chain (Chapter 4.2.8 Interchange Reporting). ---|--- Based not only on the data exchange between IM and RU, but also from the data exchange between RUs and LRU, various statistics may be evaluated — | for — in the medium term — planning the production process in greater detail, and ---|--- — | for — in the long term — carrying out strategic planning exercises and capacity studies (e.g. network analyses, definition of siding and marshalling yards, rolling stock planning), but above all ---|--- — | for improving the quality of the transport service and productivity (Chapter 4.2.9 Data Exchange for Quality Improvement). ---|--- The handling of empty wagons takes on particular relevance when considering interoperable wagons. In principle there is no difference in the handling of loaded or empty wagons. The transport of empty wagons is also based on consignment orders, whereby the fleet manager for these empty wagons must be considered as a customer. 2.3.3. General remarks An information system is only as good as the reliability of the data within it. Therefore the data that plays a decisive role in the forwarding of a consignment, a wagon or a container must be accurate and captured economically — which means that the data should be entered into the system only once. Based on this, the applications and messages of this TSI avoid the multiple manual data input by access to already stored data e.g. the rolling stock reference data. The requirements regarding the rolling stock reference data are defined in Chapter 4.2.10 (The Main Reference Data). The specified Rolling Stock Reference Databases must allow easy access to the technical data. The contents of the databases must be accessible, based on structured access rights depending on privilege, to all IMs, RUs and Fleet managers, in particular for purposes of fleet management and rolling stock maintenance. They must contain all transport critical technical data such as: — | Identification of rolling stock, ---|--- — | Technical/design data, ---|--- — | Assessment of compatibility with the infrastructure, ---|--- — | Assessment of relevant loading characteristics, ---|--- — | Brake relevant characteristics, ---|--- — | Maintenance data, ---|--- — | Environmental characteristics. ---|--- In the Intermodal transport business at various points (called Gateways) a wagon is not only connected to another train, but also the Intermodal unit may be moved from one wagon to another. As a consequence it is not sufficient to work with only a trip plan for wagons and therefore a trip plan for the Intermodal units must also be drawn up. In Chapter 4.2.11 (Various Reference Files) some reference files and various databases are listed, among them, the Wagon and Intermodal Unit Operational Database. This database contains the operational status data of the rolling stock, the weight and dangerous goods information, information related to Intermodal units and the location information. The TSI for Telematics Applications subsystem for freight services defines the required information, which has to be exchanged between the different partners involved in a transport chain, and permits a standard mandatory data exchange process to be installed. It shows also the architecture strategy for such a communication platform. This is outlined in Chapter 4.2.12 (Networking & Communication) which takes into account: — | the interface to the subsystem Operation and Traffic Management referred to in Article 5(3) of Directive 2008/57/EC (1), ---|--- — | the requirements for the content of the Network Statement, which are set out in Directive 2012/34/EU (3), Article 27 and Annex IV, ---|--- — | the information available on the freight wagon rolling stock and the requirements regarding maintenance from the Rolling Stock TSI. ---|--- There is no direct data transmission from the subsystem Telematics Applications for Freight Services into the train, to the driver or to parts of the Control Command and Signalling subsystem and the physical transmission network is a completely different one from the network used by the Command Control and Signalling subsystem. The ERTMS/ETCS system is using GSM-R. In this open Network the ETCS specifications clarify that safety is achieved with the appropriate management of open networks hazards in the EURORADIO protocol. The interfaces to the structural subsystems Rolling Stock and Control Command are only given via the Rolling Stock Reference Databases (Chapter 4.2.10.2: The Rolling Stock Reference Databases), which are under the control of the keepers. The interfaces to the subsystems Infrastructure, Control Command and Energy are given with the path definition (Chapter 4.2.2.3: Path Details message) from the IM, where infrastructure related values for the train are specified, and with the information provided by the IMs regarding restrictions in the infrastructure (Chapter 4.2.2 Path Request and Chapter 4.2.3 Train Preparation). 3\. ESSENTIAL REQUIREMENTS 3.1. Compliance with the essential requirements According to Article 4(1) of Directive 2008/57/EC (1), the Trans-European Rail System, subsystems and their interoperability constituents must meet the essential requirements set out in general terms in Annex III of that Directive. In the scope of the present TSI, the fulfilment of relevant essential requirements listed in Chapter 3 will be ensured for the subsystem by the compliance with the specifications described in Chapter 4: Characterisation of the subsystem. 3.2. Essential requirements aspects The essential requirements concern: — | Safety, ---|--- — | Reliability and Availability, ---|--- — | Health, ---|--- — | Environmental protection, ---|--- — | Technical compatibility. ---|--- According to Directive 2008/57/EC (1), the essential requirements may be generally applicable to the whole Trans-European Rail System or be specific to each subsystem and its constituents. 3.3. Aspects relating to general requirements The relevance of the general requirements to the Telematics Applications Subsystem for Freight is determined as follows: 3.3.1. Safety The essential requirements 1.1.1, 1.1.2, 1.1.3, 1.1.4 and 1.1.5 of Annex III to Directive 2008/57/EC (1) are not relevant to the Telematics Applications subsystem. 3.3.2. Reliability and availability ‘The monitoring and maintenance of fixed or movable components that are involved in train movements must be organised, carried out and quantified in such a manner as to maintain their operation under the intended conditions.’ This essential requirement is met by the following chapters: — | Chapter 4.2.10: The Main Reference Data, ---|--- — | Chapter 4.2.11: Various Reference Files and Databases, ---|--- — | Chapter 4.2.12: Networking & Communication. ---|--- 3.3.3. Health The essential requirements 1.3.1 and 1.3.2 of Annex III to Directive 2008/57/EC (1) are not relevant to the Telematics Applications subsystem. 3.3.4. Environmental protection The 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 (1) are not relevant to the Telematics Applications subsystem. 3.3.5. Technical compatibility The essential requirement 1.5 of Annex III to Directive 2008/57/EC (1) is not relevant to the Telematics Applications subsystem. 3.4. Aspects relating specifically to the Telematics Applications Subsystem for Freight 3.4.1. Technical compatibility Essential requirement 2.7.1 of Annex III to Directive 2008/57/EC (1): ‘The essential requirements for Telematics Applications guarantee a minimum quality of service for passengers and carriers of goods, particularly in terms of technical compatibility. Steps must be taken to ensure: — | that the databases, software and data communication protocols are developed in a manner allowing maximum data interchange between different applications and operators, excluding confidential commercial data, ---|--- — | easy access to the information for users.’ ---|--- This essential requirement is specially met by the following chapters: — | Chapter 4.2.10: The Main Reference Data, ---|--- — | Chapter 4.2.11: Various Reference Files and Databases, ---|--- — | Chapter 4.2.12: Networking & Communication. ---|--- 3.4.2. Reliability and availability Essential requirement 2.7.2 of Annex III to Directive 2008/57/EC (1): ‘The methods of use, management, updating and maintenance of these databases, software and data communication protocols must guarantee the efficiency of these systems and the quality of the service.’ This requirement is specially met by the following chapters: — | Chapter 4.2.10: The Main Reference Data, ---|--- — | Chapter 4.2.11: Various Reference Files and Databases, ---|--- — | Chapter 4.2.12: Networking & Communication. ---|--- This essential requirement, especially the method of use to guarantee the efficiency of these Telematics applications and the quality of the service, is the foundations for the complete TSI and not restricted to the Chapters 4.2.10, 4.2.11 and 4.2.12. 3.4.3. Health Essential requirement 2.7.3 of Annex III to Directive 2008/57/EC (1): ‘The interfaces between these systems and users must comply with the minimum rules on ergonomics and health protection.’ This TSI does not specify any additional requirements 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.4.4. Safety Essential requirement 2.7.4 of Annex III to Directive 2008/57/EC (1): ‘Suitable levels of integrity and dependability must be provided for the storage or transmission of safety-related information.’ This requirement is met by the following chapters: — | Chapter 4.2.10: The Main Reference Data, ---|--- — | Chapter 4.2.11: Various Reference Files and Databases, ---|--- — | Chapter 4.2.12: Networking & Communication. ---|--- 4\. CHARACTERISATION OF THE SUBSYSTEM 4.1. Introduction The rail system, to which Directive 2008/57/EC applies and of which the Telematics Applications Subsystem is a part, is an integrated system whose consistency must be verified. This consistency must be checked in particular with regard to the specifications of the subsystem, its interfaces vis-à-vis the system in which it is integrated, as well as the operating and maintenance rules. Taking into account all the applicable essential requirements, the Telematics Application Subsystem for Freight is characterised by: 4.2. Functional and technical specifications of the subsystem In light of the essential requirements in Chapter 3 (Essential requirements), the functional and technical specifications of the subsystem cover the following parameters: — | Consignment Note data, ---|--- — | Path Request, ---|--- — | Train Preparation, ---|--- — | Train Running Forecast, ---|--- — | Service Disruption Information, ---|--- — | Wagon/Intermodal unit ETI/ETA, ---|--- — | Wagon Movement, ---|--- — | Interchange Reporting, ---|--- — | Data Exchange for Quality Improvement, ---|--- — | The Main Reference Data, ---|--- — | Various Reference Files and Databases, ---|--- — | Networking & Communication. ---|--- The detailed data specifications are defined in the complete Data Catalogue. The mandatory formats of the messages and the data of this Catalogue are defined in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed Appendix I. 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 in particular on the territories of EU Member States having a border with third countries. General remarks on the message structure The messages are structured into two data sets: — Control data: defined through the mandatory message header of the messages of the catalogue. — Information data: defined by the mandatory/optional content of each message and mandatory/optional data set in the catalogue. If a message or a data element is defined as optional in this Regulation, the involved parties decide on using it. The application of these messages and data elements must be part of a contractual agreement. If in the data catalogue optional elements are mandatory under certain conditions this has to be specified in the data catalogue. 4.2.1. Consignment Note data 4.2.1.1. Customer Consignment Note The Consignment Note has to be sent by the Customer to the Lead RU. It must show all the information needed to carry a consignment from the consignor to the consignee according to ‘Uniform Rules Concerning the Contract of International Carriage of Goods by Rail (CIM)’, ‘Uniform Rules concerning Contracts of Use of Vehicles in International Rail Traffic (CUV) and valid national rules’. The LRU must supplement additional information. A subset of the consignment note data including the additional ones, are described in Appendix I, TAF TSI — ANNEX D.2: APPENDIX A (WAGON/ILU TRIP PLANNING) and Appendix I, TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model (4))) listed in the table in Appendix I of this Regulation. In the case of Open Access the Lead RU contracting with the customer has all the information after the supplement of the data available. No message exchange is needed with other RUs. These data are also the basis for a path request on short notice, if this is required for the execution of the consignment note. The following messages are for the case of non-Open Access. The content of these messages may also be the basis for the path requests on short notice, if required for the execution of the consignment note. 4.2.1.2. Consignment orders The consignment order is primarily a subset of the Consignment Note information. It must be forwarded to the RUs involved in the transport chain by the LRUs. The content of the Consignment order must show the relevant information which is needed for an RU to effect transportation during its responsibility until handover to next RU. Therefore the content is dependent on the role to be performed by the railway undertaking: Origin-, Transit- or Delivery RU. The mandatory data structure of the consignment order and detailed formats of this message are listed in the ‘Consignment Order Message’ in in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I The main contents of these consignment orders are: — | Consignor and consignee information, ---|--- — | Routing information, ---|--- — | Consignment identification, ---|--- — | Wagon information, ---|--- — | Place and time information. ---|--- Selected data of the consignment note data must also be accessible for all partners (e.g. IM, Keeper, etc.) in the transport chain including customers. These are especially per wagon: — | Load weight (Gross weight of the load), ---|--- — | CN/HS Number, ---|--- — | Dangerous goods information, ---|--- — | Transportation unit. ---|--- Exceptionally a paper version can be used only if this information cannot be sent using the messages defined above. 4.2.2. Path Request 4.2.2.1. Preliminary remarks The Path defines the requested, accepted and actual data to be stored concerning the path and the characteristics of the train for each segment of that path. The following description presents the information which must be available to the infrastructure manager. This information must be updated whenever a change occurs. The information of the annual path therefore needs to allow the retrieval of the data for short term amendments. In particular, the Customer, in case he is impacted, must be informed by LRU. Path Request on short notice Due to exceptions during the train running or due to transport demands on a short time basis, a railway undertaking must have the possibility to get an ad hoc path on the network. In the first case, immediate actions have to be started, whereby the actual train composition based on the train composition list is known. In the second case, the railway undertaking must provide the infrastructure manager with all necessary data concerning when and where the train is required to run together with the physical characteristics in so far as they interact with the infrastructure. The basic parameter ‘Short notice Path Requests’ should be handled between the RU and the infrastructure manager (IM). In this basic parameter the term IM can refer to IMs and if applicable to Allocation Bodies (see Directive 2012/34/EU (3)). These requirements are valid for all Short Notice Path Requests. This Basic Parameter (BP) does not include Traffic Management issues. The time limit between Short Term paths and Traffic Management path changes is subject to Local Agreements. The Railway Undertaking (RU) must provide the Infrastructure Manager (IM) with all necessary data concerning when and where the train is required to run together with the physical characteristics in so far as they interact with the infrastructure. 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 the contracted path. Without prejudice to the conditions for the usage of a path in the Network Statements or to the responsibilities in case of any restrictions in the infrastructure explained in the TSI Operation and Traffic Management, the RU must know before preparing the train, whether there are any restrictions on the line segments or stations (nodes) affecting its train composition described in the path contract.

The Path agreement for a train movement at short notice is based on a dialogue between RUs and IMs. Requests for infrastructure capacity may be made by applicants. In order to use such infrastructure capacity, applicants shall appoint a railway undertaking to conclude an agreement with the infrastructure manager in accordance Directive 2012/34/EU (3). The dialogue will involve all RUs and IMs involved in moving the train along the desired path but maybe with different contribution to the path finding process. 4.2.2.2. Path Request message This message is sent to the infrastructure manager (IM) by the RU in order to request a path. The definition of the mandatory structure of this message and the elements to be followed are described in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I. 4.2.2.3. Path Details message The IM sends this message to the requesting RU in response to their path request. The definition of the mandatory structure of Path Details message and the elements to be followed are described in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I. 4.2.2.4. Path Confirmed message The requesting RU uses this message to book/confirm the path proposed by the IM. The definition of the mandatory structure of Path Confirmed message and the elements to be followed are described in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I. 4.2.2.5. Path Details Refused message The requesting RU uses this message to reject the path details proposed by the relevant infrastructure manager. The definition of the mandatory structure of Path Details Refused message and the elements to be followed are described in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I. 4.2.2.6. Path Cancelled message This message is used by an RU to cancel all or part of a path that has been booked. The definition of the mandatory structure of Path Cancelled message and the elements to be followed are described in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I. 4.2.2.7. Path Not Available message The IM sends this message to the contracted RU in the event that the RU's booked path is no longer available, The definition of the mandatory structure of Path Not Available message and the elements to be followed are described in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I. 4.2.2.8. Receipt Confirmation message This message is sent from the recipient of the message to the originator of the message in order to acknowledge that its legacy system has received the message within a specified time interval. The definition of the mandatory structure of Receipt Confirmation message and the elements to be followed are described in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I. 4.2.3. Train Preparation 4.2.3.1. General Remarks This basic parameter describes the messages which must be exchanged during the train preparation phase until the start of the train. Train preparation includes compatibility check between the train and the route. This check is done by the RU on basis of information provided by concerned IMs on infrastructure description and infrastructure restrictions. During train preparation the RU must send the train composition to the next RUs. According to contractual agreements this message must also be sent from the RU to the IM(s) with whom it has contracted a path section. If the train composition is changed at a location, this message must be exchanged once more with information updated by the RU responsible. For the preparation of the train, the RU must have access to the infrastructure restriction notices, to the technical wagon data (Rolling Stock Reference Databases, Chapter 4.2.10.2: The Rolling Stock Reference Databases), to the information on dangerous goods and to the current, updated information status on the wagons (Chapter 4.2.11.2: Other Databases: The Wagon and Intermodal Unit Operational Database). This applies to all wagons on the train. At the end the RU must send the train composition to the next RUs. This message must also be sent from the RU to the IM(s) with whom it has booked a path section, when requested by the Conventional Rail TSI Operation and Traffic Management or by the contract(s) between RU and IM(s). If the train composition is changed at a location, this message must be exchanged once more with information updated by the RU responsible. At each point, e.g. origin and interchange point, where the responsibility changes on the RU side, the start procedure dialogue between IM and RU ‘Train ready — Train Running Information’ is obligatory. 4.2.3.2. Train Composition message This message must be sent from the RU to the next RU, defining the composition of the train. According to network statement this message is also to be sent from the RU to the IM(s). Whenever there is a change in the composition during the journey of a train, the RU that makes the change has to update this message to LRU, which informs all parties involved. The definition of the mandatory structure of Train Composition message and the elements to be followed are described in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I. Minimum elements to be delivered for the message exchange between RU and IM for the purpose Train Composition are defined in Chapter 4.2.2.7.2 of Decision 2012/757/EU, OPE TSI. 4.2.3.3. Train Ready message The railway undertaking shall send a ‘train ready’ message to the infrastructure manager every time a train is ready to start after train preparation, unless under national rules the infrastructure manager accepts the timetable as a ‘train ready’ message. The definition of the mandatory structure of Train Ready message and the elements to be followed are described in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I. 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.4. Train Running Forecast 4.2.4.1. General Remarks 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, 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 subsequent 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. Contractual agreements shall specify Reporting Points for the train's movement. This information exchange between RUs and IMs always takes place between the IM in charge and the RU, who has booked the path on which the train is actually running. Under contractual agreement the LRU will provide Customer the Train Running Forecast and Train Running Information. The reporting points will be agreed by both parties within the contract. 4.2.4.2. Train Running Forecast message This message must be issued by the IM to the RU, who is running the train, for handover points, interchange points and for the train destination as described in Chapter 4.2.4.1 (Train Running Forecast, General Remarks). In addition, the message must be issued by the IM to the RU for other reporting points according the RU/IM contracts (e.g. for handling point or 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 extend of delay is not known, the infrastructure manager has to send a ‘service disruption message’ (see Section 4.2.5 Service disruption information). The train running forecast message must give the forecast time for agreed forecast point. The definition of the mandatory structure of Train Running Forecast message and the elements to be followed are described in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I. 4.2.4.3. Train Running Information message and Train Delay Cause Message. This message must be issued by the IM to the RU running the train upon: — | Departure from departure point, arrival at destination, ---|--- — | Arrival and departure at handover points, interchange points and at agreed reporting points based on contract (e.g. handling points). ---|--- If the cause for the delay (first assumption) is provided it must be sent in the separate Train Delay Cause Message. The definition of the mandatory structure of Train Running Information message and Train Delay Cause Message and the elements to be followed are described in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I. 4.2.5. Service Disruption Information 4.2.5.1. General Remarks This basic parameter lays down how service disruption information is handled between the railway undertaking and the infrastructure manager. When the RU learns about a service disruption during the train running operation for which it is responsible, it must immediately inform the IM concerned (this may be done orally by the RU). If train running is interrupted, the infrastructure manager shall send a ‘train running interrupted’ message to the contracted RU and the next neighbouring IM involved in the train run. If the length of the delay is known, the infrastructure manager must send a train running forecast message instead 4.2.5.2. Train Running Interruption message If the train is interrupted the IM issues this message to the next neighbouring IM involved in the train run and to the RU. The definition of the mandatory structure of Train Running Interruption message and the elements to be followed are described in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I. 4.2.6. Shipment ETI/ETA 4.2.6.1. Preliminary remark Chapter 4.2.2 (Path Request) has mainly described the communication between the RU and the IM. The individual monitoring of wagons or Intermodal units is not covered by this information exchange. This is done on the RU/LRU level based on the train related messages and is described in the following Chapters 4.2.6 (Shipment ETI/ETA) to 4.2.8 (Interchange Reporting). The wagon or Intermodal unit related information exchange and updating are essentially supported by storage of ‘trip plans’ and ‘wagon movements’ (Chapter 4.2.11.2: Other Databases). As already mentioned in Chapter 2.3.2 (Considered processes), for a customer the most important information is always the estimated time of arrival (ETA) for its shipment. The wagon related ETA as well as the ETI is also the basic information in the communication between LRU and RU. This information is the main instrument for the LRU to monitor the physical transport of a shipment and to check it against the commitment to the customer. The forecasted times in the train related messages are all related to an arrival of a train at a certain point, which may be a handover point, interchange point, the train destination or another reporting point. These are all Train Estimated Times of Arrivals (TETA). For the various wagons or Intermodal units in the train, such a TETA may have different meanings. A TETA for an interchange point, for example, may be an estimated time of interchange (ETI) for some wagons or Intermodal units. For other wagons remaining in the train for further transportation by the same RU, the TETA might have no relevance. It is the task of the RU receiving the TETA information to identify and process that information, store it as a wagon movement in the Wagon and Intermodal Unit Operational Database and communicate it to the LRU, if the train is not running in Open Access mode. This is now considered in the following chapters. Under contractual agreement the LRU will provide Customer the estimated time of arrival (ETA) and estimated time of interchange (ETI) at shipment level. The level of detail will be agreed by both parties within the contract. For intermodal transport, the data messages containing the identifiers of the loading units (e.g. containers, swap-bodies, semi-trailers) will use either a BIC- or an ILU-Code according to ISO 6346 and EN 13044 respectively. 4.2.6.2. ETI/ETA calculation The ETI/ETA calculation is based on the information from the infrastructure manager in charge, which sends, within the Train Running Forecast message, the Train Estimated Time of Arrival (TETA) for defined reporting points (in any case for handover, interchange, or arrival points including Intermodal terminals) on the agreed train path e.g. for the handover point from one IM to the next IM (in this case TETA is equal to ETH). For the interchange points or for other defined reporting points on the agreed train path, the RU must calculate for the next RU in the transport shipment chain, the estimated time of interchange (ETI) for the wagons and/or Intermodal units. As an RU may have wagons with different journeys and from various LRUs within the train, the interchange point for the ETI calculation for the wagons may be different. (The pictorial representation of these scenarios and examples are given in the document ‘TAF TSI — Annex A.5: Figures and Sequence Diagrams of the TAF TSI messages’ Chapter 1.4, listed in Appendix I and the sequence diagram based on example 1 for the interchange point C is shown in the document ‘TAF TSI — Annex A.5: Figures and Sequence Diagrams of the TAF TSI messages’ Chapter 5, listed in Appendix I). The next RU, based upon the ETI input of the preceding RU, calculates for its part the wagon related ETI for the next interchange point. These steps are effected by each succeeding RU. When the last RU (e.g. RU n) in the transport chain of a wagon receives the ETI from his preceding RU (e.g. RU n-1) for the interchange of the wagon between RU n-1 and RU n, the last RU (RU n) must calculate the estimated time of arrival of the wagons at the final destination. This is to cater for the placement of the wagons according to the consignment order and in line with the commitment of the LRU to his customer. This is the ETA for the Wagon and must be sent to the LRU. It must be electronically stored along with wagon movement. The LRU must provide his relevant data to the customer according to contractual conditions. Remark on Intermodal units: For the Intermodal units on a wagon, the wagon ETIs are also ETIs for the Intermodal units. Regarding the ETAs for Intermodal units it should be noticed, that the RU is not in the position to calculate such an ETA beyond the rail transportation part. Therefore the RU can only deliver ETIs related to the Intermodal terminal. The Lead RU is responsible for the comparison of the ETA with the commitment to the customer. Deviations of the ETA against the commitment to the customer must be handled in accordance with the contract and may lead to an alert management process by the LRU. For the transmission of information on the result of this process is foreseen the Alert message. As a basis for the Alert management process the LRU must have the possibility for a wagon related enquiry on deviations. This enquiry of an LRU and the response from an RU is also specified below. 4.2.6.3. Wagon ETI/ETA message The purpose of this message is to send ETI or updated ETI from one RU to the next in the transport chain. The last RU in the transport chain of the wagons sends the ETA or updated ETA to the LRU. The definition of the mandatory structure of Wagon ETI/ETA message and the elements to be followed are described in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I. 4.2.6.4. Alert message Following the comparison between ETA and commitment to the customer, the LRU may send an Alert message to the RUs involved. The definition of the mandatory structure of Alert message and the elements to be followed are described in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I. Remark: In case of Open Access the calculation of ETI and ETA is an RU internal process. In this case the RU is the lead RU itself. 4.2.7. Wagon Movement 4.2.7.1. Preliminary Remarks For the reporting of the movement of a wagon, data included in these messages must be stored and electronically accessible. They must be also exchanged within message on contractual base to authorised parties. — | Wagon Release notice ---|--- — | Wagon Departure notice ---|--- — | Wagon Yard arrival ---|--- — | Wagon Yard departure ---|--- — | Wagon Exceptions message ---|--- — | Wagon Arrival notice ---|--- — | Wagon Delivery notice ---|--- — | Wagon Interchange reporting, will be described separately in Chapter 4.2.8: Interchange Reporting ---|--- Under contractual agreement the LRU must provide to the Customer the wagon movement information using the messages described below. 4.2.7.2. Wagon Release Notice message The Lead RU is not necessarily the first RU in the transport chain. In this case the LRU must tell the RU in charge that the wagon is ready for pull at the customer sidings (Place of departure according to the LRU commitment) at the given release time (date and time of departure). These events must be stored in the Wagon and Intermodal Unit Operational Database. The definition of the mandatory structure of Wagon Release Notice message and the elements to be followed are described in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I. 4.2.7.3. Wagon Departure Notice message The RU must inform the LRU of the actual Date and Time that the wagon has been pulled from the place of departure. These events must be stored in the Wagon and Intermodal Unit Operational Database. With this message exchange the responsibility for the wagon changes from customer to the RU. The definition of the mandatory structure of Wagon Departure Notice message and the elements to be followed are described in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I. 4.2.7.4. Wagon Yard Arrival message The RU must inform the LRU, that the wagon has arrived at its yard. This message can be based on a ‘Train running information’ message from Chapter 4.2.4 (Train Running Forecast). This event must be stored in the Wagon and Intermodal Unit Operational Database. The definition of the mandatory structure of Wagon Yard Arrival message and the elements to be followed are described in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I. 4.2.7.5. Wagon Yard Departure message The RU must inform the LRU, that the wagon has left its yard. This message can be based on a ‘Train running information’ message from Chapter 4.2.4 (Train Running Forecast). This event must be stored in the Wagon and Intermodal Unit Operational Database. The definition of the mandatory structure of Wagon Yard Departure message and the elements to be followed are described in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I. 4.2.7.6. Wagon Exception message The RU must inform the LRU if something unexpected occurs to the wagon, which might have an impact for the ETI/ETA, or requires any additional action. This message requires in most of the cases also a new ETI/ETA calculation. If the LRU decides to have a new ETI/ETA, it sends a message back to the RU, which has sent this message together with the indication ‘ETI/ETA requested’ (message: Wagon Exception message New ETI/ETA Request). The new ETI/ETA calculation must follow the procedure of Chapter 4.2.6 (Shipment ETI/ETA). This information must be stored in the Wagon and Intermodal Unit Operational Database. The definition of the mandatory structure of Wagon Exception message and the elements to be followed are described in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I. 4.2.7.7. Wagon Arrival Notice message The last RU in a wagon or Intermodal unit transport chain must inform the LRU that the wagon has arrived at its yard (RU location). The definition of the mandatory structure of Wagon Arrival Notice message and the elements to be followed are described in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I. 4.2.7.8. Wagon Delivery notice message The last RU in a wagon transport chain must inform the LRU that the wagon has been placed at the consignee's sidings. Remark: In the case of Open Access the described wagon movement is a RU (LRU) internal process. Nevertheless all calculations and data storage must be executed by it as the LRU having a contract with and a commitment to the customer. The sequence diagram for these messages based on example 1 for the ETI calculation for the wagons 1 and 2 (see Chapter 4.2.6.2 ETI/ETA calculation) is integrated in the diagram for interchange reporting in the document ‘TAF TSI — Annex A.5:Figures and Sequence Diagrams of the TAF TSI messages’ Chapter 6, listed in Appendix I. 4.2.8. Interchange Reporting 4.2.8.1. Preliminary remark The interchange reporting describes the messages attached to the transfer of responsibility for a wagon between two railway undertakings, which occurs at interchange points. It also commands the new RU to make an ETI calculation and to follow the process as described in Chapter 4.2.6 (Shipment ETI/ETA). The following messages must be exchanged: — | Wagon Interchange Notice, ---|--- — | Wagon Interchange Sub Notice, ---|--- — | Wagon Received At Interchange, ---|--- — | Wagon Refused At Interchange. ---|--- The information data of these messages must be stored in the Wagon and Intermodal Unit Operational Database. In case of any deviation a new ETI/ETA must be generated and communicated according to the process described in Chapter 4.2.6: Shipment ETI/ETA. The sequence diagram for these messages is shown in connection with the wagon movement messages in the document TAF TSI — Annex A.5:Figures and Sequence Diagrams of the TAF TSI messages' listed in Appendix I. The wagon interchange notices and the wagon interchange notices/sub as well as the wagon received messages may be transferred as a list for various wagons, especially if these wagons are all within one train. In this case all the wagons may be listed within one message transfer. In the case of Open Access there are no interchange points. At a handling point the responsibility for the wagons does not change. Therefore there is no special message exchange needed. But derived from the Running Information of the train at this reporting point, the wagon or Intermodal unit related information — regarding location and date/time of arrival and departure — must be processed and stored in the Wagon and Intermodal Unit Operational Database. Under contractual agreement the LRU must provide to the Customer the interchange reporting information using the messages described below. The definition of the mandatory structure of these messages is given in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I. 4.2.8.2. Wagon Interchange Notice message With the ‘Wagon Interchange Notice’ message a railway undertaking (RU 1) asks the next railway undertaking (RU 2) in the transport chain whether it accepts the responsibility for a wagon. With the ‘Wagon Interchange Notice/Sub’ message the RU 2 informs its IM, that it has accepted the responsibility. The definition of the mandatory structure of Wagon Interchange Notice message and the elements to be followed are described in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I. 4.2.8.3. Wagon Interchange Sub Notice message With the ‘Wagon Interchange Notice/Sub’ message the RU 2 informs the IM, that it has taken over the responsibility of a particular wagon. The definition of the mandatory structure of Wagon Interchange Sub Notice message and the elements to be followed are described in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I. 4.2.8.4. Wagon Received at Interchange message With the ‘Wagon Received at Interchange’ message the RU 2 informs RU 1 that it accepts the responsibility for the wagon. The definition of the mandatory structure of Wagon Received at Interchange message and elements to be followed are described in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I. 4.2.8.5. Wagon Refused at Interchange message With the ‘Wagon Refused at Interchange’ message the RU 2 informs RU 1 that it is not willing to take over the responsibility for the wagon. The definition of the mandatory structure of Wagon Refused at Interchange message and elements to be followed are described in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I. 4.2.9. Data Exchange for Quality Improvement To be competitive the European Railway Industry must deliver higher service quality to its customers (see also Annex III, Article 2.7.1 to the Directive 2008/57/EC (1)). A measurement process is an essential post trip process to support quality improvements. In addition to measuring the service quality delivered to the customer, LRUs, RUs and IMs must measure the quality of the service components that in total make up the product delivered to the customer. The process involves the IMs and the RUs (especially if they are Lead RUs) selecting an individual quality parameter, a route or location and a measurement period in which actual results are to be measured against predetermined criteria and which normally have been set out in a contract. The results of the measurement process must clearly show the achievement level against the target which has been agreed upon between the contracting parties. 4.2.10. The Main Reference Data 4.2.10.1. Preface The Infrastructure Data (the Network Statements and the infrastructure restriction notices ) and Rolling Stock Data (in the Rolling Stock Reference Databases and in the Wagon and Intermodal Unit Operational Database) are the most important data for the operation of freight trains on the European network. Both types of data together allow an assessment of the compatibility of the rolling stock with the infrastructure, help to avoid multiple data input, which increase especially the data quality, and they give a clear picture on all available installations and equipment at any time for fast decisions during the operation. 4.2.10.2. The Rolling Stock Reference Databases The keeper of a rolling stock is responsible for the storage of the rolling stock data within a Rolling Stock Reference Database. The Information that must be included in the individual Rolling Stock Reference Databases is described in detail in Appendix I, Appendix C. They must contain all items for: — | Identification of rolling stock, ---|--- — | Assessment of the compatibility with the infrastructure, ---|--- — | Assessment of relevant loading characteristics, ---|--- — | Brake relevant characteristics, ---|--- — | Maintenance data, ---|--- — | Environmental characteristics. ---|--- The Rolling Stock Reference Databases must allow easy access (a single common access provided via the common interface) to the technical data to minimise the volume of data transmitted for each operation. Contents of the Databases must be accessible, based on structured access rights depending on privilege to all Service Providers (IMs, RUs, Logistic providers and Fleet managers) in particular for purposes of fleet management and rolling stock maintenance. The entries in the Rolling Stock Reference Database can be grouped as follows: — | Administrative data, related to certification and registration items such as reference to the EC registration file, id of the notified body, etc.; this may include historical data related to ownership, rental, etc. Additionally, according to Commission Regulation EU 445/2011, article 5, the Wagon Keepers may store the ECM certification identification number in the individual Rolling Stock Reference Databases. The following steps have to be taken into account: | — | EC certification, ---|--- — | Registration in the ‘home’ State, ---|--- — | Date put into service in the state of registration, ---|--- — | Registration in other countries for the use on their national network, ---|--- — | Safety certification for all Rolling Stock which does not comply with the Rolling Stock TSI. ---|--- The keeper is obliged to ensure that these data are available and the processes behind have been conducted. — | Design data, which shall include all constitutive (physical) elements of the rolling stock, including characteristics related to the environment, and all information that is expected to remain valid throughout the life of the rolling stock — this part may contain a history of major modifications, major maintenance, overhaul, etc. ---|--- 4.2.10.3. The Rolling Stock Operational Data Beside the reference data for rolling stock, the data representing the actual status of the rolling stock is the most important data for operational purposes. This data shall include temporary data, such as restrictions, current and projected maintenance actions, km and fault counters, etc.; and all data that could be considered as ‘status’ (temporary speed restrictions, brake isolated, needs for repair and fault description, etc.). For use of the operational rolling stock data three different entities must be considered taking into account the different parties responsible for rolling stock during transport operation: — | Railway Undertaking as Duty holder during its transport control, ---|--- — | Keeper of rolling stock, and ---|--- — | User (Hirer) of rolling stock. ---|--- For all three different parties the operational rolling stock data must be accessible by the authorised user, down to his predefined authorised level, using the single key given by the wagon id (wagon number). The operational rolling stock data is a part of the Wagon and Intermodal Unit Operational Database as described in Chapter 4.2.11.2 Other Databases. 4.2.11. Various Reference Files and Databases 4.2.11.1. Reference Files For the operation of freight trains on the European network the following reference files must be available and accessible to all service providers (IMs, RUs, logistic providers and fleet managers). The data must represent the actual status at all times. Where a reference file is in common use with the TAP TSI (2), the development and changes must be in line with TAP TSI (2), in order to achieve optimum synergies. Locally stored and administrated: (a) | Reference File of the emergency services, correlated to type of hazardous goods. ---|--- Centrally stored and administrated: (b) | Reference File of the Coding for all IMs, RUs, Service provider companies; ---|--- (c) | Reference File of the Coding for Freight Transport Customers; ---|--- (d) | Reference File of the Coding of Locations (Primary and subsidiary), ---|--- The European Railway Agency will save a copy of the Reference File for the Locations Codes and Company Codes. On individual request and without prejudice to intellectual property rights, this data shall be available for public consultation. Other code lists are defined in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I. 4.2.11.2. Other Databases To allow for the tracking of train and wagon movements, the following databases, updated at each relevant event in real time, must be installed. Authorised entities such as keepers and fleet managers must have access to the data relevant to fulfil their functions, according to bilateral agreements. — | Wagon and Intermodal Unit Operational Database, ---|--- — | Trip plan for wagon/Intermodal unit. ---|--- These databases must be accessible via the Common Interface (4.2.12.1: General Architecture and 4.2.12.6: Common Interface). For intermodal transport, the data messages containing the identifiers of the loading units (e.g. containers, swap-bodies, semi-trailers) will use either a BIC- or an ILU-Code according to ISO 6346 and EN 13044 respectively. Wagon and Intermodal unit Operational Database The communication between the Lead RU and RUs in the cooperation mode is based on wagon and/or Intermodal unit numbers. Therefore an RU, which communicates with the IMs at train level, must break down this information into wagon and Intermodal unit related one. This wagon and Intermodal unit related information must be stored in the Wagon and Intermodal Unit Operational Database. The information on train movement leads to new entries/updates in the Wagon and Intermodal Unit Operational Database for customer information. The movement part for a wagon or Intermodal unit in the database is set up at the latest when receiving the release time for the wagons or Intermodal unit from the customer. This release time is the first movement entry for a wagon into the Wagon and Intermodal Unit Operational Database related to an actual transport journey. The messages for the wagon movement are defined in the Chapters 4.2.8 (Wagon Movement) and 4.2.9 (Interchange Reporting). This database must be accessible via the Common Interface (4.2.12.1: General Architecture and 4.2.12.6: Common Interface). The Wagon and Intermodal Unit Operational Database is the most important one for the tracking of wagons and therefore for the communication between the RUs involved and the Lead RU. This database shows the movement of a wagon and of an Intermodal unit from departure through to final delivery at customer sidings with ETIs and actual times at different locations until the final delivery time ETA. The database also shows the different status of the rolling stock such as: — | Status: loading of the rolling stock This status is required for the information exchange between the RU and the IMs and to other railway undertakings involved in the transport journey. ---|--- — | Status: loaded wagon on journey This status is required for the information exchange between the IM and the RU, with other infrastructure managers and with other railway undertakings involved in the transport journey. ---|--- — | Status: empty wagon on journey This status is required for the information exchange between the IM and the RU, with other infrastructure managers and railway undertakings involved in the transport journey. ---|--- — | Status: unloading of rolling stock This status is required for the information exchange between the RU at destination and the Lead RU for the transport. ---|--- — | Status: empty wagon under fleet management control This status is required to get the information about availability of a vehicle of defined characteristics. ---|--- Wagon Trip Plan Databases Trains may be composed of wagons from various Customers. For each wagon the Lead RU (RU acting as Service Integrator) must establish and update a trip plan which corresponds to the train path at train level. New train paths for a train — e.g. in case of service interruptions — lead to revised trip plans for the wagons concerned. The creation time for the trip plan is the receipt of the consignment note from the customer. The Wagon Trip Plans must be stored by each LRU in a database. These databases must be accessible via the Common Interface (4.2.14.1: General Architecture and 4.2.12.6: Common Interface). Remark: In addition to the mandatory databases mentioned above, at each IM side a train database may be installed. This infrastructure manager train database corresponds to the movement part of the Wagon and Intermodal Unit Operational Database. The main data entry is the train related data of the train composition message from the RU. All train events result in an update of this train related database. An alternative storage possibility for these data is the path database (Chapter 4.2.2: Path Request). These databases must be accessible via the Common Interface (4.2.12.1: General Architecture and 4.2.12.6: Common Interface). 4.2.11.3. Additional Requirements on the Databases Under the following points are listed additional requirements which must be supported by the various databases. These 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 the security aspects in the meaning of controlling access to the database. The possible encryption of the database contents itself is not required. ---|--- 3. | Consistency A database selected shall support the ACID principle (Atomicity, Consistency, Isolation and Durability). ---|--- 4. | Access Control A database must allow access to the data to 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 insertion, update or deletion of data records. ---|--- 5. | Tracing A database must support logging all actions applied to the database to allow for tracing the detail of the data entry (Who, What, When did the contents change). ---|--- 6. | Lock strategy A database must implement a locking strategy which allows access to the data even when other users are currently editing records. ---|--- 7. | Multiple access A database must support 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 an availability on demand of at least 99,9 %. ---|--- 10. | Maintainability A 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. wrong or not actual data — may have 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 to export the contents of the complete database or its part as formatted data. ---|--- 15. | Mandatory Fields A database must support mandatory fields that are required to be filled 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 and wagon movements that are covered by the provisions of this TSI. ---|--- 19. | Capacity aspects A database shall support the storage of the relevant data for all freight wagons respectively 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 in the meaning of making of data available that has 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 up to a 24 hour period can be recovered. ---|--- 22. | Commercial aspects A database system used shall be available commercially off-the-shelf (COTS-product) or be available in the public domain (Open Source). ---|--- Remarks: The above requirements must be handled by a standard Database Management System (DBMS). The usage of the various databases is embedded into various work flows described here before. The general workflow is a request/response mechanism, where an interested party requests information from the database through the Common Interface (4.2.12.1: General Architecture and 4.2.12.6: Common Interface). The DBMS responds to this request either by providing the requested data or by responding that no data can be made available (no such data exists or access is refused due to access control). 4.2.12. Networking & Communication 4.2.12.1. General Architecture This subsystem will see, over time, the growth and interaction of a large and complex Telematics rail interoperability community with hundreds of participating players (RUs, IMs, etc.), which will compete and/or cooperate in serving the market's needs. The Network & Communication infrastructure supporting such rail interoperability community will be based on a common Information Exchange Architecture, known and adopted by all participating players. The proposed Information Exchange Architecture: — | is designed to reconcile heterogeneous information models by semantically transforming the data that is exchanged between the systems and by reconciling the business process and application-level protocol differences, ---|--- — | has minimum impact on the existing IT architectures implemented by every actor, ---|--- — | safeguards IT investments made already. ---|--- The Information Exchange Architectures favours a mostly Peer-to-Peer type of interaction between all players, while it guarantees 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 cost distribution between the different players, based on actual usage and it will present, in general, lesser scalability problems. A pictorial representation on the general architecture is given in the document ‘TAF TSI — Annex A.5 Figures and Sequence Diagrams of the TAF TSI messages’, Chapter 1.5, listed in Appendix I. 4.2.12.2. Network Networking in this case means the method and philosophy of communication and does not mean 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. The security issue will therefore be addressed not by the network (VPN, tunnelling, etc.), but by exchanging and managing inherently secure messages. A VPN network is therefore not required (the administration of a large VPN network will be complex and costly to manage), thus avoiding problems with responsibilities and ownership allocation. Tunnelling is not considered as a necessary means for achieving the appropriate security level. In any case if some players already have or want to implement various degrees of security on selected partitions of the network, they can do so. Over the public Internet network it is possible to implement a hybrid Peer to Peer model with a common interface at each actor's node and a central certificate authority. Afterwards, a Peer to Peer communication is performed between involved players. The peer-to-peer communication is based on technical standards for the common Interface described in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I. 4.2.12.3. Security To achieve a high level of security, all messages must be self-contained, which means that the information in the message is secured and the receiver can verify the authenticity of the message. This may be solved by using an encryption and signing scheme similar to email encryption. 4.2.12.4. Encryption Either asymmetric encryption or a hybrid solution based on symmetric encryption with public key protection must be used, due to the fact that sharing a common secret key among many players will fail at some point. A higher level of security is easier to achieve if every actor takes responsibility for its own pair of keys, even though a high level of integrity of the central repository (the key server) is required. 4.2.12.5. Central Repository The Central Repository must be able to handle: — | metadata — structured data describing the content of messages, ---|--- — | Public Key Infrastructure (PKI), ---|--- — | Certification Authority (CA), ---|--- The management of the central repository should be under the responsibility of a non-commercial co-European organisation. Where the Central Repository is in use in conjunction with the TAP TSI (2), development and changes must be in line with TAP TSI (2) in order to achieve optimum synergies. 4.2.12.6. Common Interface A Common Interface is mandatory for each actor in order to join the rail interoperability community. A 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 the outgoing messages, ---|--- — | authenticity verification of the incoming messages, ---|--- — | decryption of incoming messages, ---|--- — | conformity checks of incoming messages according to metadata, ---|--- — | handling the single common access to various databases. ---|--- Each instance of a Common Interface will have access to all the data required according the TSI within each Wagon keeper, LRU, RU, IM, etc., whether the relevant Databases are central or individual (see also document ‘TAF TSI — Annex A.5: Figures and Sequence Diagrams of the TAF TSI messages’, Chapter 1.6, listed in Appendix I). Where a Common Interface is in common use with the TAP TSI (2), the development and changes must be in line with TAP TSI (2), in order to achieve optimum synergies. Based on the results of authenticity verification of incoming messages, a minimum level of message acknowledgement can be implemented: (i) | positive send ACK; ---|--- (ii) | negative send NACK. ---|--- A common interface uses the information in the central repository in order to manage the above tasks. An actor may implement a local ‘mirror’ of the central repository to shorten response times. 4.3. Functional and technical specifications of the interfaces In light of the essential requirements in Chapter 3, the functional and technical specifications of the interfaces are as follows: 4.3.1. Interfaces with the TSI Infrastructure The infrastructure subsystem includes traffic management, tracking, and navigation systems:

technical installations for data processing and telecommunications intended for long-distance passenger services and freight services on the network in order to guarantee the safe and harmonious operation of the network and efficient traffic management. The subsystem Telematics Applications for Freight uses the data required for operational purposes as given by the path contract, possibly completed by infrastructure restriction data, as provided by the IM. Thus no direct interface exists between this TSI and the TSI for infrastructure. 4.3.2. Interfaces with the TSI Control/Command and Signalling The only connection to control command and signalling is via the — | Path contract, where within the line segment description the relevant information about usable command control and signalling equipment is given, and ---|--- — | various Rolling Sock Reference Databases, where the command control and signalling equipment of the rolling stock must be stored. ---|--- 4.3.3. Interfaces with the rolling stock subsystem The subsystem Telematics Applications for freight identifies the technical and operational data, which must be available for the rolling stock. The rolling stock TSI specifies the characteristics of a wagon. If the characteristics changes for a wagon, this must be updated in the Rolling Stock Reference Databases within the normal maintenance process for the database. Thus no direct interface exists between this TSI and the TSI for rolling stock. 4.3.4. Interfaces with the TSI operation and traffic management The subsystem Operation and Traffic Management specifies the procedures and related equipment enabling a coherent operation of the different structural subsystems, both during normal and degraded operation, including in particular train driving, traffic planning and management. The subsystem Telematics Applications for Freight mainly specifies applications for freight services including real-time monitoring of freight and trains and the management of connections with other modes of transport. In order to ensure consistency between both TSIs, the following procedure applies. When the specifications of the TSI Operation and Traffic Management related to the requirements of this TSI will be written and/or will become subject to amendments, then the body in charge of this TSI must be consulted. In the case that the specifications of this TSI related to operational requirements specified in the TSI Operation and Traffic Management should be subject to any amendment, the body in charge of the TSI Operation and Traffic Management must be consulted. 4.3.5. Interfaces with the Telematics Applications for Passenger Services Interface | Reference Telematics Applications for Freight TSI | Reference Telematics Applications for passengers TSI ---|---|--- Train ready | | 4.2.3.3 | Train ready message ---|--- | 4.2.14.1 | Train ready message for all trains ---|--- Train running forecast | | 4.2.4.2 | Train running forecast message ---|--- | 4.2.15.2 | ‘Train running forecast’ message for all trains ---|--- Train running information | | 4.2.4.3 | Train running information ---|--- | 4.2.15.1 | ‘Train running information’ message for all trains ---|--- Train running interrupted to RU | | 4.2.5.2 | Train running interrupted ---|--- | 4.2.16.2 | ‘Train running interrupted’ message for all trains ---|--- Handling of short term timetable data | | 4.2.2 | Path Request ---|--- | 4.2.17 | Handling of short term timetable data for trains ---|--- Common Interface | | 4.2.12.6 | Common Interface ---|--- | 4.2.21.7 | Common interface for RU/IM communication ---|--- Central Repository | | 4.2.12.5 | Central Repository ---|--- | 4.2.21.6 | Central repository ---|--- Reference Files | | 4.2.11.1 | Reference files ---|--- | 4.2.19.1 | Reference files ---|--- 4.4. Operating rules In 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 data quality assurance purposes, 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 is 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 provided from the databases provided as part of this TSI, the originator of the message must make 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 they — | are Error free: accessible, accurate, timely, complete, consistent with other sources, etc., and ---|--- — | possess desired features: relevant, comprehensive, proper level of detail, easy-to-read, easy-to-interpret, etc. ---|--- The data quality is mainly characterised by: — | 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 is only recorded, if possible, on one single occasion for the whole transport. Therefore the primary data should be introduced into the system as close as possible to its source, so that it can be fully integrated into any later 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 the complexity of the rule. For simple rules, database constraints and triggers are sufficient. In 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 guaranteed that transferred data are validated against the defined business rules. Timeliness: The provision of information right in time is an important point. As far as the triggering for data storage or for message sending is event driven directly from the IT system the timeliness is not a problem if the system is designed in well manner according the needs of the business processes. But in most of the cases the initiation of sending a message is done by an operator or at least is based on additional input from an operator (for example the sending of the train composition or the actualising of train or wagon related data). To fulfil the timeliness requirements the updating of the data must be done as soon as possible also to guarantee, that the messages will have the actual data content when sending out automatically by the system. Data quality Metrics For the completeness (Per cent of data fields having values entered into them) of mandatory data and for the consistency of data (Per cent of matching values across tables/files/records) a percentage of 100 % must be reached. For the Timeliness of data (Per cent of data available within a specified threshold time frame) a percentage of 98 % must be reached. As far as threshold values are not defined in this TSI, these values must be specified in the contracts between the involved parties. The required accuracy (Per cent of stored values that are correct when compared to the actual value) must be above 90 %. The exact value and the criteria must been set out in the contracts between the involved parties. 4.4.2. Operating the central repository The functions of the central repository are defined in Chapter 4.2.12.5 Central Repository. For the purpose of data quality assurance, the entity operating the central repository shall be responsible for the updating and the quality of the metadata and also for the administration of the access control. Regarding 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 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 processing equipment were to break down in full or in part. It is therefore, advisable to install duplex systems or computers with a particularly high degree of reliability, and for which the uninterrupted operation during maintenance is ensured. The maintenance aspects regarding the various databases are mentioned in Chapter 4.2.11.3 (Additional Requirements on the Databases), points 10 and 21. 4.6. Professional qualifications The professional qualifications of staff required for the operation and maintenance of the subsystem and for implementing the TSI are as follows: The implementation of this TSI does not require a complete new system in hardware and software with new staff. The realisation of the requirements of the TSI leads only to changes, upgrades or functional enlargements of the operation as it is already done by the existing staff. Therefore, there are no additional requirements to the existing national and European rules on professional qualifications. If necessary, an add-on training of staff should not just consist of showing them how to operate equipment. The member of staff must know and understand his specific role to be played in the overall transportation process. Staff must in particular be aware of the requirement to maintain a high working performance level, since this is a decisive factor for the reliability of the information to be processed at a subsequent stage. The professional qualifications needed for the composition and operation of trains are defined in the TSI 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 (or the technical scope as defined in paragraph 1.1) and for the implementation of the TSI are as follows: There are no additional requirements to existing national and European rules on health and safety. 5\. INTEROPERABILITY CONSTITUENTS 5.1. Definition According to Article 2(f) of Directive 2008/57/EC (1): Interoperability constituents are ‘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 (1). There are no interoperability constituents determined as far as the subsystem Telematics Applications for Freight is concerned. For the fulfilment of the requirements of this TSI only standard IT equipment is needed, without any specific aspects for interoperability in the railway environment. This is valid for hardware components and for the standard software used like operating system and databases. The application software is individual on each user's side and can be adapted and improved according the individual 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 Chapter 5.2, not relevant for the TSI ‘Telematics Applications for Freight’. 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 The assessment procedure for conformity or suitability for use of interoperability constituents must be based on European specifications or specifications approved in accordance with Directive 2008/57/EC (1). In the case of suitability for use, these specifications will indicate all the parameters to be measured, monitored or observed, and will describe the related testing methods and measuring procedures, whether in a test-bench simulation or tests in a real railway environment. Procedures for assessing conformity and/or suitability for use: List of specifications, description of the testing methods: Not relevant for the TSI Telematics Applications for Freight. 6.1.2. Module At the request of the manufacturer or his representative established in the Community, the procedure is carried out by a notified body in accordance with the provisions of the pertinent modules of Commission Decision 2010/713/EU as set out, amended and supplemented in the Appendix to this TSI. The modules should be combined and used selectively according to the particular constituent. Not relevant for the TSI Telematics Applications for Freight. 6.1.3. Subsystem Telematics Applications for Freight At the request of the awarding authority or its representative established in the Community, the notified body carries out EC verification in accordance with Annex VI to Directive 2008/57/EC (1). According to Annex II of the Directive 2008/57/EC (1), the subsystems are broken down into structural and functional areas. The conformity assessment is obligatory for TSIs in the structural area. The Subsystem Telematics Application for Freight belongs to the functional area and this TSI does not determine any modules for conformity assessment. However the central repository and a common interface at each actor's node are the backbone of the application integration. The exchange information model is held in the centralised application integration repository, which holds the interface metadata in one physical location. The metadata contains information about the communication content (what is in the data being sent), the touch point identities of the senders and receivers, and the interaction process mechanics application-level business protocols. The following points are highlighted: — | The central repository also contains the certification authority (Open CA PKI). This is mainly an administration act, which is physically implemented. Wrong entries become obvious immediately. No assessment procedure needed. ---|--- — | The central repository contains the message metadata (according to document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’, listed in Appendix I) as the basis for message exchange in a heterogeneous information environment. The metadata must be administrated and updated in the central repository. Any incompatibility in the message structure or content of the messages for sending or receiving data will be recognised immediately and the transfer will be refused. No assessment procedure needed. ---|--- — | The common interface at each actor's node contains mainly the local ‘mirror’ of the central repository for shortening the response time and reducing the load on the repository. It must be ensured, that the data versions in the central repository and in the common interface are always the same. Therefore the data update must be done on the central level and new versions must be downloaded from there. No assessment procedure needed. ---|--- 7\. IMPLEMENTATION 7.1. Modalities of Application of this TSI 7.1.1. Introduction This TSI concerns the subsystem telematics applications for freight services. This subsystem is functional according to Annex II to Directive 2008/57/EC (1). 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 is implemented in phases: — | phase one: detailed IT specifications and master plan; ---|--- — | phase two: development; ---|--- — | phase three: deployment. ---|--- 7.1.2. Phase one — detailed IT specifications and master plan The functional requirement specifications which shall be used as basis for above technical architecture during the development and deployment of the computerised system are in the appendices A to F listed in Appendix I to this Regulation. The mandatory master plan from-concept-to-delivery of the computerised system, based on the Strategic European Deployment Plan (SEDP) prepared by the rail sector, includes the core architecture components of the system and the identification of the major activities which shall be executed. 7.1.3. Phases 2 and 3 — Development and deployment Railway undertakings, infrastructures managers and wagon keepers shall develop and deploy the TAF computerised system in accordance with the provisions of this chapter. 7.1.4. Governance, roles and responsibilities The development and deployment shall be put under a governance structure with following players. The Steering Committee The Steering Committee shall have following roles and responsibilities: The Steering Committee shall provide for the strategic management structure to efficiently manage and coordinate the work for implementing the TAF-TSI. This shall involve setting the policy, the strategic direction and prioritisation. In doing so, the steering committee shall also take into account the interests of small undertakings, new entrants, and railway undertakings providing specific services. The Steering Committee shall monitor the implementation progress. It shall regularly report to the European Commission about the progress achieved compared with the master plan, at least four times a year. The Steering Committee shall make the necessary steps to adjust above development in the case of a deviation from the master plan. 1. | The Steering Committee shall be composed 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’), ---|--- — | the European Railway Agency, and ---|--- — | the Commission. ---|--- 2. | 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. ---|--- 3. | 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. ---|--- The Stakeholders The railway undertakings, infrastructure managers and wagon keepers shall set up an efficient project governance structure which enables the TAF system to be efficient developed and deployed. Above stakeholders shall: — | provide the necessary efforts and resources needed for the implementation of this Regulation, ---|--- — | comply with the principles of access to the TAF TSI common components which shall be available to all market participants at a unified, transparent and lowest possible service cost structure, ---|--- — | ensure that all market participants have access to all data exchanged required for fulfilling their legal obligations and for the performance of their functions in accordance with the TAF TSI functional requirements, ---|--- — | protect the confidentiality of customer relationships, ---|--- — | set-up a mechanism which will enable ‘late comers’ to join the TAF development and to profit from achieved TAF developments related to the common components in a way which is satisfactory both for above stakeholders and for the ‘new comers’ in particular with view to fair cost sharing, ---|--- — | report of progress with implementation plans to the TAF Steering Committee. This reporting includes also — where appropriate — deviations from the master plan. ---|--- The Representative Bodies The Representative Bodies from the railway sector acting on a European level as defined in Article 3(2) of Regulation (EC) No 881/2004 of the European Parliament and of the Council (1) shall have following roles and responsibilities: — | represent their individual stakeholder members at the TAF-TSI Steering Committee, ---|--- — | raise awareness of their members on their obligations related to the implementation of the present regulation, ---|--- — | ensure current and complete access for all above stakeholders to status information on the work of the Steering Committee and any other groups in order to safeguard each representative's interests in the implementation of TAF-TSI in a timely manner, ---|--- — | ensure the efficient information flow from their individual stakeholder members to the TAF Steering Committee so that the stakeholders' interest is duly taken into account for decisions affecting the TAF development and deployment, ---|--- — | ensure the efficient information flow from the TAF Steering Committee to their individual stakeholder members so that the stakeholders are duly informed about decisions affecting the TAF development and deployment. ---|--- 7.2. Change Management 7.2.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 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 European Railway Agency, rail sector representative bodies and national safety authorities. 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 Commission may add further parties to the CCB if their participation is seen to be necessary. The CCB ultimately shall be brought under the aegis of the European Railway Agency. 7.2.2. Specific Change Management Process for documents listed in Appendix I to this Regulation The change control management for the documents listed in Appendix I to this Regulation shall be established by the European Railway Agency in accordance with the following criteria: 1. | The change requests affecting the documents are submitted either via the National Safety Authorities (NSA) or via the representative bodies from the railway sector acting on a European level as defined in Article 3(2) of Regulation 881/2004/EC, or via the TAF TSI Steering Committee. The Commission may add further submitting parties if their contribution is seen to be necessary. ---|--- 2. | The European Railway Agency shall gather and store the change requests. ---|--- 3. | The European Railway Agency shall present change requests to the dedicated ERA working party, which will evaluate them and prepare a proposal accompanied by an economic evaluation, where appropriate. ---|--- 4. | Afterwards the European Railway Agency shall present the change request and the associated proposal to the change control board that will or will not validate or postpone the change request. ---|--- 5. | If the change request is not validated, the European Railway Agency shall send back to the requester either the reason for the rejection or a request for additional information about the draft change request. ---|--- 6. | The document shall be amended on the basis of validated change requests. ---|--- 7. | The European Railway Agency shall submit to the Commission a recommendation to update the documents listed in Appendix I together with the draft new version of the document, the change requests and their economic evaluation. ---|--- 8. | The European Railway Agency shall make the draft new version of the document and the validated change requests available on its web site. ---|--- 9. | Once the update of the documents listed in Appendix I is published in the Official Journal of the European Union, the European Railway Agency shall make the new version of the document available on its web site. Where change control management affects elements which are in common use within the TAP TSI (2), the changes shall be made so as to remain as close as possible to the implemented TAP TSI (2) in order to achieve optimum synergies. ---|--- * * * (1) Regulation (EC) No 881/2004 of the European Parliament and of the Council of 29 April 2004 establishing a European Railway Agency ( OJ L 164, 30.4.2004, p. 1) Appendix I List of technical documents No | Reference | Title | Version | Date ---|---|---|---|--- 1 | ERA-TD-100 | TAF TSI — ANNEX A.5:FIGURES AND SEQUENCE DIAGRAMS OF THE TAF TSI MESSAGES | 2.0 | 17.10.2013 2 | ERA-TD-101 | TAF TSI — Annex D.2: Appendix A (Wagon/ILU Trip Planning) | 2.0 | 17.10.2013 3 | ERA-TD-102 | TAF TSI — Annex D.2: Appendix B — Wagon and Intermodal Unit Operating Database (WIMO) | 2.0 | 17.10.2013 4 | ERA-TD-103 | TAF TSI — Annex D.2: Appendix C — Reference Files | 2.0 | 17.10.2013 5 | ERA-TD-104 | TAF TSI — Annex D.2: Appendix E — Common Interface | 2.0 | 17.10.2013 6 | ERA-TD-105 | TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model | 2.0 | 17.10.2013 Appendix II Glossary Term | Description ---|--- ACID | Atomicity, Consistence, Isolation, Durability These are the four primary attributes ensured 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 its 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 is saved by the system such that, even in the event of a failure and system restart, the data is available in its 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 designed to realise the ACID concept. In a distributed system, one way to achieve ACID is to use a two-phase commit (2PC), which ensures that all involved sites must commit to transaction completion or none do, and the transaction is rolled back. Allocation body | see IM. Applicant | means a railway undertaking or an international grouping of railway undertakings or other persons or legal entities, such as competent authorities under Regulation (EC) No 1370/2007 and shippers, freight forwarders and combined transport operators, with a public-service or commercial interest in procuring infrastructure capacity (Directive 2012/34/EU (3)). For Allocation body: see IM definition. Block train | A specific form of a direct train with only as much wagons as needed, running between two transhipment points without intermediate marshalling. Booking | The process of making a reservation for space on a means of transport for the movement of goods. CA | Certification Authority CN-code | 8-digit Code list for products used by customs. Combined road — rail transport | Intermodal transport where the major part of the European journey is by rail and any initial and/or final legs carried out by road are as short as possible. Consignee | Party by whom the goods are to be received. Synonym: Goods receiver Consignment | Freight sent under a single contract of carriage. In combined transport, this term may be used for statistical purposes, to measure loading units or road vehicles. Consignment note | A document which evidence a contract for the transportation by a carrier of one consignment from a named place of acceptance to a named place of delivery. It contains details of the consignment to be carried. Consignor | Party which, by contract with a Service Integrator, consigns or sends goods with the carrier, or has them conveyed by him. Synonyms: Shipper, Goods sender. Cooperation mode | Mode of train operation where various RU cooperate under the leadership of one RU (LRU). Each involved RU contracts the needed path for the transport journey on its own. COTS-product | Commercially off-the-shelf products Customer | is the entity which has issued the consignment note to the Lead RU. Departure date/time, actual | Date (and time) of departure of means of transport. Direct train | A train with related wagons which runs between two transhipment points (initial source — final destination) without intermediate marshalling. Duty holder | Any individual or legal entity responsible for the risk which he imports onto the network, i.e. the RU. Encryption | Encoding of messages Decryption: converting encrypted data back into original form Essential requirements | Essential requirements means all the conditions set out in Annex III of the Directive 2001/16/EC of the European Parliament and of the Council (*1) which must be met by the Trans-European conventional rail system, the subsystems, and the interoperability constituents including interfaces. ETA | Estimated Time of Arrival. ETH | Estimated Time of Handover of a train from one IM to another. ETI | Estimated Time of Interchange of wagons from one RU to another. Forecast Time | Best estimate of arrival, departure or passing time of a train. FTP | File Transfer Protocol A protocol to transfer files between computer systems in the network TCP/IP. Gateway | Station within the journey of a train with Intermodal units, where the load changes the wagons. GGP | Gateway to Gateway Protocol See also IP Gross weight of load | Booked/actual total weight (mass) of goods, including packing but excluding the carrier's equipment. Handling point | Station where the RU may change the train composition, but where it remains responsible for the wagons, no change of responsibility. Handover point | Point where the responsibility changes from one IM to another. Haulage | Transport by road Hirer | Any individual or other legal entity designated as such by the keeper/owner of a wagon. HS code | 6-digit Code list for products used by customs, identically to the first 6 digits of the CN Code. HTTP | Hypertext Transfer Protocol The client/server protocol used on connect to servers on the Web. ICMP | Internet Control Message Protocol (ICMP) Occasionally a gateway (see GGP) or destination host (see IP) will communicate with a source host, for example, to report an error in datagram processing. For such purposes this protocol, the Internet Control Message Protocol (ICMP), is used. ICMP, uses the basic support of IP as if it were a higher level protocol, however, ICMP is actually an integral part of IP, and must be implemented by every IP module. ICMP messages are sent in several situations: for example, when a datagram cannot reach its destination, when the gateway does not have the buffering capacity to forward a datagram, and when the gateway can direct the host to send traffic on a shorter route. The Internet Protocol is not designed to be absolutely reliable. The purpose of these control messages is to provide feedback about problems in the communication environment, not to make IP reliable. There are still no guarantees that a datagram will be delivered or a control message will be returned. Some datagrams may still be undelivered without any report of their loss. The higher level protocols that use IP must implement their own reliability procedures if reliable communication is required. The ICMP messages typically report errors in the processing of datagrams. To avoid the infinite regress of messages about messages etc., no ICMP messages are sent about ICMP messages. Also ICMP messages are only sent about errors in handling fragment zero of fragmented datagrams. (Fragment zero has the fragment offset equal zero). IM | Infrastructure Manager means some body or firm responsible in particular for establishing, managing and maintaining railway infrastructure, including traffic management and control-command and signalling; the functions of the infrastructure manager on a network or part of a network may be allocated to different bodies or firms. Where the infrastructure manager, in its legal form, organisation or decision-making functions, is not independent of any railway undertaking, the functions referred to in Sections 2 and 3 of Chapter IV shall be performed respectively by a charging body and by an allocation body that are independent in their legal form, organisation and decision-making from any railway undertaking. (Directive 2012/34/EU (3)). Infrastructure manager (IM) | See IM Interchange | The Transfer of control from one railway company to another for practical operational and safety reasons. Examples are: | — | Mixed services, ---|--- — | Services with shared haulage responsibility, ---|--- — | The transfer of information between different railway administrations, ---|--- — | The transfer of information between wagon owners/keepers and train operators. ---|--- Interchange point | Location where the transfer of responsibility for the wagons of a train goes from one RU to another RU. Regarding a train running, the train is taken over from one RU by the other RU, which owns now the path for the next journey section. Intermediate point | Location which defines the start or end point of a journey section. This may be e. g. an interchange, handover or handling point. Intermodal operator | Any entity which concludes a multimodal transport contract and assumes the whole responsibility for the transport of intermodal loading units. Intermodal Service Integrator | Any body or undertaking, which has the contract with customers for the transport of Intermodal units. He is preparing waybills, managing capacity on block trains etc. Intermodal terminal | Location which provides the space, equipment and operational environment under which the loading units (freight containers, swap bodies, semi-trailers or trailers) transfer takes place. Intermodal transport | The movement of goods in one and the same loading unit or vehicle which uses successively several modes of transport without handling of the goods themselves in changing modes. Intermodal Unit | A Load Unit which can be transported by different modes e.g. container, swap body, semi-trailer, trailer. Internet | | — | Any large network made up of several smaller networks; ---|--- — | A group of networks that are interconnected so that they appear to be one continuous large network, and can be addressed seamlessly at the OSI model Network Layer through routers; ---|--- — | The industry name for the network, used as reference resource for e-mail and an on-line chat room for users around the world. ---|--- 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 conventional rail system depends directly or indirectly. The concept of a constituent covers both tangible objects and intangible objects such as software. IP | The Internet Protocol The Internet Protocol (IP) is used for host-to-host datagram service in a system of interconnected networks. The network connecting devices are called Gateways. These gateways communicate between themselves for control purposes via a Gateway to Gateway Protocol (GGP). Journey | A ‘journey’ denotes the spatial forwarding of a loaded or empty wagon from the forwarding station to the destination station. Journey section | Is the part of the journey which takes place on one infrastructure sector of an infrastructure manager or Part of the journey from the entry handover point to the exit handover point of the infrastructure of one infrastructure manager. Keeper | The person, who being the owner or having the right to dispose of it, exploits a vehicle economically in a permanent manner as a means of transport and is registered as such in the Rolling Stock Register. Lead Railway Undertaking | Responsible RU, which organises and manages the transport line according to the customer's commitment. It is the single point of contact for the customer. If more than one Railway Undertaking is involved in the transport chain, the LRU is responsible for the co-ordination of the various Railway Undertakings. A customer may be especially for Intermodal transport an Intermodal service integrator. Loco ID | Unique identification number of a traction unit LRU | See Lead Railway Undertaking MAY | This word, or the adjective ‘OPTIONAL’, means that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option. MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides). Metadata | Simply put, is 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. MUST | This word, or the terms ‘REQUIRED’ or ‘SHALL’, mean that the definition is an absolute requirement of the specification. MUST NOT | This phrase, or the phrase ‘SHALL NOT’, means that the definition is an absolute prohibition of the specification. NFS | The Network File System (NFS) is a distributed file system protocol. The Network File System (NFS) protocol provides transparent remote access to shared file systems across networks. The NFS protocol is designed to be machine, operating system, network architecture, and security mechanism, and transport protocol independent. This independence is achieved through the use of Remote Procedure Call (RPC) primitives built on top of an external Data Representation (XDR). Notified bodies | 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. (Directive 91/440/EC (1)). One Stop Shop (OSS) | 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 entire train movement, ---|--- — | Generally also invoicing track access charges on behalf of IMs. ---|--- Open Access mode | Mode of train operation where only one RU is involved, which runs the train on various infrastructures. This RU contracts the needed paths with all involved IMs. OSI | Open Systems Interconnection Describes a communication protocol of open systems based on the OSI reference model. Open systems are capable of communicating independent of proprietary solutions. OSI reference model | Standard description of how messages should be transmitted between any two points in a network. The OSI model defines 7 layers of functions that take place at each end of a communication. These layers are the only internationally accepted framework of standards for communication. OSS | One Stop Shop Path | 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 assembly | Joining up of individual train paths to extend path in terms of time and space. Path number | Number of the defined train path Peer-to-Peer | The term ‘peer-to-peer’ refers to a class of systems and applications that employ distributed resources to perform a critical function in a decentralised manner. The resources encompass computing power, data (storage and content), network bandwidth, and presence (computers, human, and other resources). The critical function can be distributed computing, data/content sharing, communication and collaboration, or platform services. Decentralisation may apply to algorithms, data, and metadata, or to all of them. This does not preclude retaining centralisation in some parts of the systems and applications if it meets their requirements. PKI | Public key infrastructure Place of delivery | Place where the delivery happens (departure rail station to be given). a place where responsibility for the wagon is changed. Place of departure | Place from which a means of transport is scheduled to depart or has departed. Place of destination | Place at which the means of transport is due to arrive or has arrived. Synonym: Place of arrival Pre-departure Period | is the delta time before the scheduled time of departure. The pre-departure period starts at scheduled time of departure minus delta time and ends at the scheduled time of departure. Primary data | Basic data as reference data input for messages or as the basis for functionality and calculation of derived data. Put into Service | A procedure dependent on the technical approval of a wagon and a contract for use with a RU which allows commercial operation of the wagon. Railway Undertaking (RU) | Railway undertaking (Directive 2004/49/EC) (9): means railway undertaking as defined in Directive 2001/14/EC, and any other public or private undertaking, the activity of which is to provide transport of goods and/or passengers by rail on the basis that the undertaking must ensure traction; this also includes undertakings which provide traction only. RAMS | See Reliability, Availability, Maintainability, Safety. RARP | Reverse Address Resolution Protocol (RARP) Release date/time | Date/time when the goods are expected to be released or were released by the customer. Release time for wagons | Date and time when the wagons are ready to be pulled from the named place on the customer siding. Reliability, Availability, Maintainability, Safety (RAMS) | Reliability— The ability to start and continue to operate under designated operating conditions for a designated period expressed mathematically; Availability— The time in operation compared to the time out of service expressed mathematically; Maintainability— The ability of a system to be put back into service after a failure expressed mathematically; Safety— The probability of a hazardous event being initiated by the system expressed mathematically. Reporting point | Location on the train journey, where the responsible IM has to issue a ‘train running forecast message’ with TETA to the path contracted RU. Repository | A repository is 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. Typically it includes and internal set of software tools, a DBMS, a metamodel, populated metadata, and loading and retrieval software for accessing repository data. RIV | Regulations governing the reciprocal use of wagons in international traffic. Regulations governing the reciprocal use of loading tackle, container and pallets in international traffic. Route | The geographical way to be taken from a starting point to a point of destination. Route section | A part of a route RPC | Remote Procedure Call The RPC protocol is specified in the Remote Procedure Call Protocol Specification Version 2 (RFC1831). RU | See Railway Undertaking Scheduled time of departure | Date and Time of departure for which the path is requested. Scheduled Timetable | Chronologically defined occupation of rail infrastructure for a train movement on open line or in stations. Changes to the timetables will be supplied by the IM s at least 2 days before the commencement of the day when the train departs from its origin. This timetable applies to a specific day. Known in some countries as the Operational Timetable. Service Provider | Responsible carrier for this specific transport stage. Party who receives and handles the booking. Shipment | A package of goods from one consignor to one consignee, which is loaded in one or more complete intermodal loading units or which is loaded on one or more complete wagons. e.g.: Short notice path request | Individual request for a path according Directive 2001/14/EC Article 23 due to additional transport demands or operational needs. SHOULD | This word, or the adjective ‘RECOMMENDED’, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. SHOULD NOT | This phrase, or the phrase ‘NOT RECOMMENDED’ mean that there may exist valid reasons in particular circumstances when the particular behaviour is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behaviour described with this label. SMTP | Simple Mail Transfer Protocol SNMP | Simple Network Management Protocol SQL | 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 | Any person or organisation with a reasonable interest in train service delivery e.g.: | | Railway Undertaking (RU), ---|--- | Shipment monitoring provider, ---|--- | Locomotive provider, ---|--- | Wagon provider, ---|--- | Driver/Train crew provider, ---|--- | Hump yard provider, ---|--- | Switch move provider, ---|--- | Service integrator, ---|--- | Slot provider (IM), ---|--- | Train controller (IM), ---|--- | Traffic manager, ---|--- | Fleet manager ---|--- | Ferry boat provider, ---|--- | Wagon, locomotive inspector, ---|--- | Wagon, locomotive repair provider, ---|--- | Shipment manager, ---|--- | Switching & humping provider, ---|--- | Logistic provider, ---|--- | Consignee, ---|--- | Consignor, ---|--- For Intermodal in addition: | Container Provider, ---|--- | Intermodal terminal operator, ---|--- | Drayage provider/Haulage company, ---|--- | Steam ship, ---|--- | Barge lines. ---|--- TCP | Transmission Control Protocol (TCP) Technical Specification for Interoperability | means the specifications by which a subsystem or part subsystem is covered in order to meet the essential requirements and ensure the interoperability of the Trans-European conventional rail system.

TETA | See Train Estimated Time of Arrival Tracing | Activity at request of finding and reconstructing the transport history of a given consignment, vehicle, equipment, package or cargo. Tracking | Activity of systematically monitoring and recording the present location and status of a given consignment, vehicle, equipment, package or cargo. Train Estimated Time of Arrival | Estimated Time of Arrival of a train at a specific point, e.g. handover point, interchange point, destination of the train. Train path | Train route defined in time and space. Train Path/Slot | A definition of a train's route in terms of time and the locations (marker points) at which it will originate and terminate along with details of those locations en-route at which it will either pass or call. The detail might also include any activities that the train will perform en-route for example train crew, locomotive or other consist changes. Trans-European rail network | Rail network as described in Annex 1 to the Directive 2001/16/EC of the European Parliament and of the Council (*1). Transhipment | The operation of moving intermodal loading units from one means of transport to another. Trip plan | For wagon or Intermodal unit shows the planned reference trip of the wagon/Intermodal unity. TSI | See Technical Specification for Interoperability Tunnelling | A process whereby private IP packets are encapsulated within a public IP packet. UDP | User Datagram Protocol Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators (NATs) (STUN) is a lightweight protocol that allows applications to discover the presence and types of NATs and firewalls between them and the public Internet. It also provides the ability for applications to determine the public Internet Protocol (IP) addresses allocated to them by the NAT. STUN works with many existing NATs, and does not require any special behaviour from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure. UIC | UIC is the international railway union. UITP | UITP is the International Union for Public Transport. UNIFE | UNIFE is an organisation that takes care of the interests of the suppliers to the railway sector. Currently approximately 100 suppliers and subcontractors are directly represented and about 1 000 indirectly through national organisations. Unit capacity used | Code to indicate to which extent the equipment is loaded or empty. (e.g. full, empty, LCL). Unit Load | A number of individual packages bonded, palletised or strapped together to form a single unit for more efficient handling by mechanical equipment. Unit train | A freight train dispatched with only one consignment note and only one type of goods and composed of uniform wagons running from a consignor to a consignee without intermediate marshalling. VPN | Virtual Private Network The term Virtual Private Network has been used to describe almost any type of remote connectivity system, such as the public telephone network and Frame Relay PVCs. With the introduction of the Internet, VPN has become synonymous with remote IP-based data networking. Simply put, a VPN consists of two or more private networks that communicate securely over a public network. VPN can exist between an individual machine and a private network (client-to-server) or a remote LAN and a private network (server-to-server). The private networks are able to connect by tunnelling. A VPN commonly uses the internet as an underlying transport network, but encrypts the data being sent between a VPN client and VPN gateway to ensure that it cannot be read even if intercepted in transit. Wagon load | A unit load whereas the unit is a wagon. Consignment order | A subset of the consignment note which shows the relevant information for a RU, needed to carry on the transportation during its responsibility until handover to a next RU. Instruction for the transportation of a wagon consignment. Waybill | The document made out by the carrier or on behalf of the carrier evidencing the contract for the transport of cargo. Web | World wide Web: An internet service that links documents by providing hypertext links from server to server so a user can jump from document to related document no matter where it is stored on the internet. XDR | External Data Representation The XDR protocol is specified in External Data Representation Standard (RFC1832). XDR is a standard for the description and encoding of data. It is useful for transferring data between different computer architectures,. XDR fits into the ISO presentation layer, and is roughly analogous in purpose to X.409, ISO Abstract Syntax Notation. The major difference between these two is that XDR uses implicit typing, while X.409 uses explicit typing. XDR uses a language to describe data formats. The language can only be used only to describe data; it is not a programming language. This language allows one to describe intricate data formats in a concise manner. The alternative of using graphical representations (itself an informal language) quickly becomes incomprehensible when faced with complexity. The XDR language itself is similar to the C language. Protocols such as ONC RPC (Remote Procedure Call) and the NFS (Network File System) use XDR to describe the format of their data. The XDR standard makes the following assumption: that bytes (or octets) are portable, where a byte is defined to be 8 bits of data. A given hardware device should encode the bytes onto the various media in such a way that other hardware devices may decode the bytes without loss of meaning. XML-RPC | XML-RPC is an Extensible Mark-up Language-Remote Procedure Calling protocol that works over the Internet. It defines an XML format for messages that are transferred between clients and servers using HTTP. An XML-RPC message encodes either a procedure to be invoked by the server, along with the parameters to use in the invocation, or the result of an invocation. Procedure parameters and results can be scalars, numbers, strings, dates, etc.; they can also be complex record and list structures. This document specifies a how to use the Blocks Extensible Exchange Protocol (BEEP) to transfer messages encoded in the XML-RPC format between clients and servers. XQL | Extended Structured Query Language * * * (*1) Directive 2001/16/EC of the European Parliament and of the Council of 19 March 2001 on the interoperability of the trans-European conventional rail system (OJ L 100, 20.4.2001, p. 1). (1) Council Directive 91/440/EEC of 29 July 1991 on the development of the Community's railways (Official Journal L 237, 24.8.1991, p. 25). Appendix III Tasks to be undertaken by the TAF/TAP National Contact Point (NCP) (1) Act as point of contact between ERA, the TAF/TAP Steering Committee and railway players (Infrastructure Managers, Railway Undertakings, Wagon Keepers, Station Managers, Ticket Vendors, Intermodal Operators, Rail Freight Customers and relevant associations) in the Member State in order to ensure that the railway players are engaged with TAF and TAP and are aware of general developments and decisions of the Steering Committee. (2) Communicate the concerns and issues of the railway players in the Member State to the TAF/TAP Steering Committee via the co-chairs. (3) Liaise with the Member State Railway Interoperability and Safety Committee (RISC) member ensuring that the RISC member is briefed on national issues relating to TAF/TAP prior to each RISC meeting and ensuring that RISC decisions relating to TAF/TAP are communicated appropriately to affected railway players. (4) The Member State ensures that all licensed Railway Undertakings and other railway players (Infrastructure Managers, Railway Undertakings, Wagon Keepers, Station Managers, Intermodal Operators, Rail Freight Customers and relevant associations) are contacted and provided with NCP details and advised to make contact with the NCP if contact is not already established. (5) To the extent that railway players in the Member State are known, make them aware of their obligations under the TAF and TAP regulations and that they must comply with them. (6) Work with the Member State to ensure that an entity is appointed to be responsible for populating the Central Reference Domain with primary location codes. The identity of the appointed entity shall be reported to DG MOVE for appropriate distribution. (7) Facilitate information sharing between the Member States' railway players (Infrastructure Managers, Railway Undertakings, Wagon Keepers, Station Managers, Ticket Vendors, Intermodal Operators, Rail Freight Customers and relevant associations) in the Member State. * * *