Rail Reporting Messagees Structure Analysis

Published Date: 02 Nov 2017

1. Rail Reporting Specifications 2

1.1. Introduction 2

1.2. Scope 2

1.3. Stakeholders 3

1.4. Business Processes / Functions 4

1.5. Architecture Overview 6

1.6. Deployment/ Implementation 7

1.7. Information requirements 7

1.7.1. Database definitions 7

1.7.2. Coding and standards used 9

1.7.3. Message Structures 10

1.8. Coding and standards used 10

1.8.1. Rail reporting Messages 11

1.9. Deployment/ Implementation 12

1.10. Rail reporting Messages 12

1.11. Rail Reporting Messagees Structure Analysis 13

1.11.1. Train Running Forecast 14

1.11.2. Service Disruption Information 17

1.11.3. Train Location 18

1.11.4. Shipment ETI / ETA 20

1.11.5. Wagon Movement 23

1.11.6. Interchange Reporting 26

1.12. References 28

Rail Reporting Specifications

Introduction

The purpose of this study is to provide the context of detailed rail reporting requirements for wagons and intermodal units. The refere

Goals & Objectives

In order to achieve this

as identified in technical specifications for interoperability regarding telematic applications for freight (TAFTSI).

TAFTSI

Technical specifications for interoperability regarding

is the EC directive for interoperability in the railway industry that is used as a reference

that is the reference for

These requirements are part of the assessment regarding vehicle (transport means) and cargo reporting, irrespective of transport mode, required to promote co-modality and the concept of Single Window within e-Freight project.

The is the tool that is used as a reference in this study.

Which are the objectives, goals of this study and the methodology that we are using

++++

The structure of this report

Scope

TAFTSI has originated from the European Directive 2001/16/ that asked to establish the conditions for interoperability of the trans-European rail system within the European Community, and can also be applied to the complete freight transport network of EU member states with the restriction that these requirements are not mandatory for freight transport heading to or coming from third countries.

Interoperability according to EC, should be achieved in the following thematic areas groups:

Structural areas

Infrastructure, i.e. The track, points, engineering structures (bridges, tunnels, etc.), associated station infrastructure (platforms, zones of access, including the needs of persons with reduced mobility, etc.), safety and protective equipment.

Energy including electrification system, overhead lines and current collectors

Control, command and signalling, the equipment ensuring safety, command control and movement of trains which are authorised to travel on the network

Traffic operation and Management, the procedures and equipment used for train driving, traffic planning and management, including cross-border services

Rolling stock. For Rolling stock include systems for command and control train equipment (breaking, coupling, running gear, suspension doors, etc), active or passive devices and conditions for ensuring passenger and staff security / health.

Operational areas

Maintenance including procedures, equipment and infrastructure (e.g. logistics centers) for maintenance work allowing the preventive and corrective maintenance to ensure interoperability and performance required.

Telematic applications for passenger and freight services

The last item (telematic applications) was addressed by the European Association of Railway Interoperability (AEIF), submitted and approved by EC as the Commission Regulation 62/2006. Specifically for the freight services, where TAFTSI focus, the telematic applications identified may include information systems that perform reatime freight/ train monitoring, marshalling and resources allocation, reservation, production of electronic (accompanying) documents.

An overview of TAFTSI is presented in the following paragraphs.

Stakeholders

The regulation obliges all stakeholders in the European rail freight market to adhere to data exchange rules in order to offer seamless end-to-end transportation services. This integration allows diverse stakeholders (Infrastructure Managers, Railway Undertakings, Fleet Managers and others, analysed below) to better plan and execute their transportation services.

The major stakeholders in TAFTSI include:

Infrastructure Managers (IM): "any body or undertaking that is responsible, in particular, for establishing and maintaining railway infrastructure. This may also include the management of infrastructure control and safety systems. The functions of the infrastructure manager on a network or part of a network may be allocated to different bodies or undertakings". Thus an Infrastructure Manager is the service provider that allocates paths (i.e. transport capacity of the infrastructure for a specific time period) in the network, controls and monitors trains and makes reporting regarding trains and related paths.

The body or undertaking to which the path is allocated is an Applicant, or according to Directive 2001/14/EC: "a licensed railway undertaking and/or an international grouping of railway undertakings, and, in Member States which provide for such a possibility, other persons and/or legal entities with public service or commercial interest in procuring infrastructure capacity, such as public authorities under Regulation (EEC) No 1191/69 and shippers, freight forwarders and combined transport operators, for the operation of railway services on their respective territories"

Trading and transfer of the infrastructure capacity that has been already allocated to an Applicant by an Infrastructure Manager is prohibited (Article 13 of the Directive 2001/14/EC)

Railway Undertaking is defined as "any public or private undertaking, licensed according to applicable Community legislation, the principal business of which is to provide services for the transport of goods and/or passengers by rail with a requirement that the undertaking must ensure traction; this also includes undertakings which provide traction only"

The Railway undertaking (RU) acts as a Fleet Manager that provides and manages his own wagons or wagons provided by another service provider (e.g. RU)

The Lead Railway Undertaking (LRU) provides services for organizing and managing the transport according to the commitments set by the customer.

From the customer perspective the LRU is the single point of contact, meaning that if more that one RUs are involved in the transport chain the LRU performs the required coordination.

Intermodal Service Integrator: under specific cases (e.g. multimodal transport chains) the undertaking responsible for managing block trains capacity, issuing waybills and having the contract with the customers is the Intermodal Service Integrator who could also be a customer of the LRU.

TAFTSI emphasises on these relationships between IMs and RUs/ LRUs with relation to their customers as defined per message in the following paragraphs.

Business Processes / Functions

Telematic applications related to TAFTSI may include:

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.

Payment invoicing for customers as well as timetable long term planning are outside the scope of TAFTSI.

Regarding the processes they can be grouped into planning and execution phases.

Planning

The process starts from a consignment note submitted to LRU from a customer indicating 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. The LRU may operate a train on his own for a complete trip (Open Access mode) or alternatively may have to collaborate with other RUs. In the first case no other planning activity is required in the latter case the LRU find the appropriate RUs, prepare and submit preliminary wagon orders to each RU as subsets of the full consignment note.

In addition, in the case of multiple RUs, each one of them checks the availability of the resources for the operation of the wagons and the availability of the train path. The responses from the RUs enable the LRU to refine the trip plan or to find alternative RU(s) until the trip plan meets the customer requirements.

The RUs / LRUs have the obligation to provide the required train path, through agreements and bookings established with IMs, during the planning phase. Alternatively they can request ad hoc train paths during the execution phase.

If an RU/LRU provides the complete journey, then each IM involved communicates directly with this RU/LRU only. This "Open Access" by the RU/LRU can be realised by booking the train path via "One Stop Shop" or in sections with each IM directly. TAFTSI takes into account both cases.

Finally during this stage information is exchanged between RUs and IMs to prepare the train (train composition) with the wagon details.

Execution

After the departure of the train data exchange between RUs and IMs include running details of a train and wagons (running forecasts), exceptions (Service Disruption Information) or tracing information regarding train location.

In addition for the customer the estimated time of arrival (ETA) of his shipment may be provided, from the information exchange between LRU and IM, in case of Open Access. Alternatively, in the case of co-operation 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 respective RUs.

The LRU is also informed of the wagons departed from or arrived at a yard or at defined locations (wagon movement) as well as when the responsibility for the wagons was transferred from one RU to the next RU in the transport chain (interchange reporting).

Finally various statistics may be generated to measure the service quality, such as transit Time, ETA, train performance and train ETAs, path availabilities, train composition quality, etc

Within the context of Single Windows, we will focus on the reporting requirements as indentified in the Execution phase, above.

Architecture Overview

The logical architecture favours a de-centralised approach for peer-to-peer interaction between actors while it guarantees the integrity and consistency of rail interoperability by providing a set of centralised services.

However the regulation itself does not enforce how the interoperability will be realised. It is up to each stakeholder to follow the guidelines and requirements imposed using the technological solution of his choice.

The proposed information exchange it is designed to handle heterogeneous information models by supporting semantic transformations between systems and at the same time tries to have minimum impact on existing IT systems and technological investments.

The communication backbone supporting the data exchange comprises of the following separate elements:

The Common Metadata and the Metadata Management System, whose purpose is to describe other data: its definitions, structure and relationships. The TAFTSI metadata defines the syntax of how the data is represented, how it is structured, the order of the elements, constraints, required data quality conditions and any business rules. The Metadata also contains carefully defined semantic relationships so that the data is clearly understood by each actor in the same context. The Metadata Management system distributes the Metadata to all stakeholders who are exchanging data

The Common Interface. Each stakeholder exchanging TAFTSI messages has one or more instances of the Common Interface. The role of the Common Interface is that it provides functionality between the TAFTSI messages and all target systems. Taking the requirements of the TSI, the Common Interface provides secure peer-to-peer communications

The Location and Company Reference Files. To ensure data quality, the TAFTSI defines the need for centrally stored and administered reference files as a repository for commonly used codes. These codes and reference files ensure consistency of data interpretation across various application systems. For the efficient operation of rail freight on the European network, reference files for all Railway Locations and Stakeholders must be established. These reference files must be available and accessible to all entitled participants subject to the data exchange specified in the TAFTSI. The data must represent the actual status at all times (to be up to date) and be distributed with the Common Metadata to each instance of the Common Interface (locally).

Deployment/ Implementation

TAFTSI also foresees the deployment/ implementation requirements for interoperability, through SEDP.

The Strategic European Deployment Plan (SEDP) defines the target system to be achieved together with its rollout plan. The purpose of the SEDP is to provide the approach for the implementation, to qualify this approach from a technical and economic feasibility perspective and establish a roadmap of the activities required to realise it.

Information requirements

Database definitions

A series of databases are supported by TAFTSI which are accessible via the Common Interface.

Infrastructure Restriction Notice DB

It contains information regarding the infrastructure managed by the infrastructure managers (IMs). Infrastructure is depicted in the information model as:

Line segments operated by an Infrastructure Manager, describing restriction reasoning (e.g. maintenance work) for specified time periods. In addition other characteristics and current status of line infrastructure (such as max train speed, max train length for freight, train weight, max axle weight, gauging, dangerous goods transport support, etc)

Stations again operated by an Infrastructure Manager. Data are grouped in restriction related (e.g. reason for operative restriction, max train length for freight, loading at wagon floor level) and current station status (e.g. temporarily speed restriction , maintenance work performed, other exceptions)

Responsibility/Access

The IM is obliged for managing the above data within its zone of responsibility, while the RU is obliged to take into account all restrictions that affect its train running until the pre-departure period. The standard pre-departure period starts one hour before the planned train departure date/time, except otherwise defined in the RU-IM contract. During the pre-departure period it is the IM’s responsibility to notify the RU for potential changes in the DB affect the train running.

Rolling Stock Reference DB

Provides data regarding the compatibility of the rolling stock with the infrastructure. The data kept in this database may be grouped in two groups:

Administrative, containing data related to certification and registration of the equipment including: EC certification, registration in the "home" state, date put into service, registration in other countries for use on their national network, safety certification.

Design, containing characteristics of the rolling stock, physical as well as environmental, restrictions (e.g. loading restrictions , geographical limitations, etc), history of major modifications and major maintenance.

The purpose of this database is to provide the appropriate input for identifying the rolling stock, assess its compatibility with the infrastructure and its characteristics (physical, environmental, maintenance, restrictions)

Responsibility/Access

All service providers (IMs, RUs, Logistic providers and Fleet managers) may have access for fleet management and rolling stock maintenance according to each user’s privilege.

Rolling Stock Operational DB

The operational rolling stock data is a part of the European wide Wagon and Intermodal Unit Operational Database.

It provides information regarding the actual status of the rolling stock. The data stored can be grouped into:

Temporary restriction including restriction due to temporary events (damages, etc)

Operational containing current and projected maintenance actions, km and fault counters, etc

Responsibility/Access

Railway Undertaking as Duty holder, Keepers and users (hirers) of rolling stock should have access to this DB. Access will be according to the predefined authorised level, using the single key given by the wagon id (wagon number).

Other Databases

Other DBs are used to facilitate the tracking of train and wagon movements.

Wagon and Intermodal Unit Operational Database

It 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.

Trip plan for wagon / Intermodal unit Database

The Wagon Trip Plans must be stored by each LRU in a database. These databases must be accessible via the Common Interface. 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.

Coding and standards used

The Coding supported in TAFTSI include:

Coding for all IM’, RUs, Service provider companies,

Coding for Transport Customers,

Coding of Locations (Primary, subsidiary and zone-track-spot),

Coding for customer locations,

Reference File of all existing train control systems,

Reference File of Hazardous goods, UN and RID numbers,

Reference File of all different locomotive types,

Reference File of all CN and HS codes for goods,

Reference File of all European maintenance workshops,

Reference File of all European audit bodies,

Reference File of all European licensed operators including respective list of national safety certificates granted.

The coding standards of IMs, RUs, Transport Organisations and companies including transport Customers as well as locations are still pending, though some proposals have been identified (To be verified).

Reference

Standard used

Reference

Codes for the

Representation of Names of

Countries and their

Subdivisions

ISO 3166-1

UIC Leaflet 920-14,

Locations

CEN Workshop Agreement

on Coding for Railway

Business Locations *

UIC Leaflet 920-2

Companies

CEN Workshop Agreement

for Coding For Railway

Undertakings, Infrastructure

Managers And Other

Companies Involved In The

Rail Transport Chain *

UIC Leaflet 920-1

* CEN Workshop Agreements (CWAs) can be migrated later into formal European Norms (ENs). CWAs offer a fast track approach and provide the flexibility needed to put these standards into place to meet the needs of the developers before implementation of the TSI TAF. The following CWAs have been produced:

CWA 15538:2006 Coding for customers in the rail transport chain

CWA 15539:2006 Numbering of and coding system for trains

CWA 15540:2006 Coding for railway undertakings, infrastructure managers and other companies, involved in the rail transport chain

CWA 15541:2006 Coding for railway business locations

Message Structures

TAFTSI supports different elements for message composition, i.e. native elements, application oriented and complex elements. The native elements are showing the values and coding, the application oriented elements are related to these native elements. The complex elements are the composition of various application oriented elements.

The messages proposed by TAFTSI are:

Consignment Note data

Path Request

Train Preparation

Train Running Forecast

Service Disruption Information

Train Location

Shipment ETI / ETA

Wagon Movement

Interchange Reporting

Data Exchange for Quality Improvement

All messages are structured into two data sets:

Control data: The control data includes transmission control data such as the status of the message (e.g. "New", "Alteration", "Deletion"), message type, date and time, message no relation to a previous message, if any, Sender, Recipient etc

Information data: the information that is analysed per message

Rail reporting Messages

Taking into account the context of Single Window in e-Freight, an analysis of the information exchange in TAFTSI concerning rail monitoring will be provided in the following paragraphs.

In particular the following messages will be addressed:

Train Running Forecast

Service Disruption Information

Train Location

Shipment ETI / ETA

Wagon Movement

Interchange Reporting

The reporting messages can be grouped in two major groups:

Messages exchanged between Railway Undertakers (RUs) and Infrastructure Managers (IMs). Train monitoring and control is mainly performed by the Infrastructure managers. These actors are the providers of train status related messages including: Train Running forecast, Service disruption information and Train location.

Messages exchanged between RUs. Wagon and intermodal unit monitoring is performed in TAF TSI on the RU/ LRU level. Wagon and intermodal unit status reporting is the main input that facilitates Railway Undertaker to monitor the progress of a shipment, check the level of fulfilment to the contractual agreements and inform the customer of transport evolvement. The messages concern monitoring regarding wagons and intermodal units include Shipment ETI, Wagon movement and Interchange reporting.

Rail Reporting Messages Analysis

An analysis of the structures and elements used per message is provided in a separate technical document. In this presentation native and application oriented elements are grouped as Simple Elements to make the understanding easier.

The technical element description of the rail monitoring messages is based on an extensive analysis and consolidation of the original TAFTSI documentation. In this chapter we provide detailed information regarding the methodology used for decoding the message structures as well as the description and meaning of each field presented in the Excel. An indicative example of message decomposition may be provided to familiarise the reader.

To be completed

TRY SELLING YOUR WORK BY EXPLAINING WHY YOU DO IT, HOW YOU HAVE DONE IT, SOME CONCLUSIONS OF THE WORK, AN EXAMPLE OF THE WORK/METHODOLOGY ETC. PRODUCE 5 PAGES FROM THAT.

Which are the steps

Methodology

Conclusions

Example of the work and methodology followed

Train Running Forecast

Purpose

Train running forecast exchange always takes place between the IM in charge and the RU, who has booked the path on which the train is actually running. There are two subtypes of the running forecast message type:

Train Running Forecast: It is issued:

From the IM to the neighbouring IM upon departure from an agreed point or prior to reaching the first reporting point. It is sent in the case of a delay, if the train has not reached the bilaterally agreed initial running time.

From the IM to the RU when, at the next stopping or handling station, out-of-schedule running is anticipated that exceeds the threshold agreed with the RU responsible for the train

From the IM to RU for handover and interchange points, the destination point and for each other reporting point predefined by RU/IM contracts

Train Running Information: This message is issued upon:

Arrival, departure or run-through in agreed reporting points.

Attainment of the agreed initial running time and/or divergence between nominal and actual in case the agreed threshold value is exceeded

Scenarios

Depending on the scenario supported different approaches may be followed. The scenarios may involve the following collaboration models:

The Railway Undertaking (RU) contacts all involved Infrastructure Managers (IMs) directly or via a single contact point (see OSS, in Glossary) to organise and control the paths of the complete journey (Figure 1 -1, Figure 1 -2)

Each RU involved in the transport journey contacts the local IMs (directly or via OSS) to request a path for a journey section on which it operates the train (Figure 1 -3)

Figure 1‑1

Figure 1‑2

Figure 1‑3

Train Approaching a Handling Point of an RU

This case is only applicable to collaboration model A (see above).

A handling point is defined as a Station where the RU may change the train composition, but where it remains responsible for the wagons, no change of RU responsibility.

For these points the IM in charge sends a Train Running Forecast message to RU with a Train Estimated Time of Arrival (TETA), depending on the contract agreements.

If a handling point is also a handover point (from IM 1 to IM 2), then IM 1 must send the Train Running Forecast message after departure from the departure point, or from the previous interchange, to IM 2 with the estimated handover time (ETH). This message is also sent to the RU. For the RU the ETH is equal to the TETA at the Handling Point.

When the train arrives at the Handling Point, the IM must send a Train Running Information with the actual time of arrival at this point to the RU.

Train approaching an Interchange point between RU 1 and the next RU 2

This case is only applicable to collaboration model B (see above).

Interchange points are defined as locations in the train path where the transfer of responsibility for the wagons of a train goes from one RU to another RU. In that case the new RU now owns the path for the next journey section.

Once the train leaves a reporting point, the IM in charge sends a Train Running Forecast message for the interchange point to the contracted RU (RU1), with the train estimated time of arrival (TETA). The same message may be sent to the next RU (RU2) and depending on the collaboration contracts to the Lead RU (LRU) for the transport.

If the interchange point is also a handover point between two Infrastructure Managers (e.g. IM1, IM2), then IM1 sends a Train Running Forecast to IM 2 with the estimated handover time (ETH). The same message is also sent to the RU (RU1) having contracted the path who transfers the message to its neighbour RU (RU2) and to the Lead RU depending on the collaboration contracts

Finally when the train arrives at an interchange point, the IM must send a Train Running Information message to his path contracted RU, for example RU 1, with the actual time of the arrival at that point.

Train Approaching a Handover Point between IM n1 and his neighbour IM n2

Departure point is called the start point of the path, whereas the handover point is the end point of the path, where the next Infrastructure Manager takes control.

Thus after the train departure from a departure point IM n1 sends a Train Running Forecast message to IM n2 with the estimated handover time (ETH). This message is simultaneously sent to the RU.

When the train leaves the infrastructure of IM n1 at the handover point this IM sends a Train Running Information with the actual handover time at this point to its path contracted RU.

Finally when the train arrives on the infrastructure of IM n2 at the handover point this IM sends a Train Running Information message with the actual handover time for this point to the path contracted RU.

Train Arrival at destination

By the time the train arrives at its destination the IM responsible sends a Train Running Information message to the path contracted RU, to describe the actual arrival time.

Message contents

Train Running Forecast

The main data elements are:

Path number and Train number,

Scheduled departure Date and Time at IM location (or scheduled handover time to next IM),

Reporting Point identification,

Forecasted Date/Time at Reporting Point.

Train Running Information

This message must be issued 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).

The main data elements are:

Path number and Train number,

Scheduled departure Date and Time at IM location,

Most recent reporting point identification,

Actual Time at reporting point,

Train Reporting Point Status (Arrival, Departure, Passage, Not Specified, Departure from Origin, Arrival at Destination),

Arrival track at location,

Departure track from location,

Booked Scheduled Time Delta deviation minutes,

current schedule if multiple re-schedules,

For each deviation from Booked Scheduled Time at that reporting location

Reason code (perhaps multiple),

Deviation time for this reason code (multiple reasons may be posted per reporting point),

May add free Text about deviation.

A detailed analysis of the structures and elements of the above messages is provided in a separate technical document.

Service Disruption Information

Purpose

The Service Disruption Function is a push message coming from the IM to the RU that defines that an exception has occurred during the running of a train. The message along with the train details it also contains the interruption details (e.g. the reason, description the location that the exception has occurred, etc).

Scenarios

A series of interactions take place depending on which party generated the message.

RU is responsible for the disruption

The RU must inform IM immediately (no IT message, e.g orally by the driver)

IM is responsible for the disruption:

IM must send the RU a train running forecast message relating to the next reporting

If the delay exceeds x minutes (This value must be defined in the contract between RU and IM) the IM concerned must send to the RU a train running forecast message relating to the next reporting point.

If the train is cancelled, the IM sends a train running interrupted message as specified below.

The RU updates the Wagon and Intermodal Unit Operational Database where the IM updates the infrastructure with the disruption details (Infrastructure Restriction Notice Database). Finally IM should also notify and update its internal database system related to train/ path data.

Contents

The main data elements in this message are:

Path and train number,

Location identification,

Scheduled Departure Date and Time at this location,

Interruption reason,

Interruption description.

Train Location

Purpose

Train location message provides tracing information related to a train location. The particular message uses a request reply approach. IN this approach the Railway Undertakers makes a request (or enquiry) to the Infrastructure Manager about its trains. The IM will reply depending on the request the available information regarding the train status.

There is no constraint regarding the time that the RU may request this information, i.e. can enquire IM any time. The particular message supports different sub-cases meaning that a RU may request information regarding:

the running of the train (last recorded location, delays, delay reasons),

a train’s performance (delays, delay reasons, delay locations),

all identifiers of a specified train,

train forecast at a specified location,

all train running forecasts for a specified location.

Scenarios

All potential usages of the train location message are provided in the table, below.

Message

Description

Train Running

A Railway undertaker requests an IM on the last recorded status of a specific train. IM provides information about the most recent location, timestamp, status of the train collected on its infrastructure

Train delay/ performance

A Railway Undertaker requests an IM on the delays of a specific train. IM provides delays for all points on its infrastructure that have generated reports for the particular train

Train Identifier

A Railway Undertaker requests an IM on all train identifiers (i.e. train numbers). IM provides train identifiers (current and past) of the trains

Train Running Forecast

A Railway Undertaker requests an IM the estimated time of arrival (forecast time) for a specific train at a specific reporting location. The reporting location is optional and if omitted the IM responds the forecast for the last point (handover point) where the next IM takes responsibility of the train

Trains at Reporting location

A Railway Undertaker requests an IM about his trains at a specific location. IM provides train information of all trains

delays for all points on its infrastructure that have generated reports for the particular train

Contents

Message

Request (RU)

Response (IM)

Train Running

Train running number

IM identifier

Scheduled departure Date and Time at IM location

Most recent reporting location

Actual Time at reporting point

Train Reporting Point Status (Arrival, Departure, Passage, etc)

Arrival/ Departure track at location,

Booked Scheduled Time, and delta delay

Re-scheduled Time (against current schedule if multiple re-schedules)

For each delay at that reporting location:

Reason code and Delay time for this reason code

Train delay/ performance

Train running number

IM identifier

Scheduled departure Date and Time at IM location

Same as in Train Running (not only for the most recent point but for each reporting point in the infrastructure)

Train Identifier

Known train running number

IM identifier

Scheduled departure Date and Time at IM location

For current train identifier:

Train running number

Scheduled departure Date and Time at the IM location

For each other train identifier:

Train running number

Scheduled departure Date and Time at the IM location

Train Running Forecast

Train running number

Scheduled departure Date and Time at IM location

The reporting location for which the forecast is required (optional)

IM code

Reporting point identification

Forecasted Date/Time at Reporting Point

Trains at Reporting location

IM code

The reporting location for which the forecast is required (optional)

For each of this enquirer’s Trains:

Train running number

Scheduled departure Date and Time at IM location or scheduled handover time

IM code

Reporting point identification,

Forecasted Date/Time at Reporting Point

Shipment ETI / ETA

Purpose

Shipment ETI (Estimated Time of Interchange of wagons from one RU to another) / ETA (Estimate Time of Arrival of Wagons to the customer side) is one of the messages that provide monitoring information of individual wagons, rather than trains. The ETI/ ETA is calculated by using the output of the train running forecast information provided by Infrastructure manager in charge of the transport.

Shipment ETI/ETA is a group of messages including:

Wagon ETI/ETA

Alerts

Enquiries/Responses about deviations

Scenarios

Wagon ETI/ ETA

The RU calculates the estimated time of Interchange for each wagon/ intermodal unit and notifies the next RU in the chain to be responsible for the wagon’s transport.

If a RU handles wagons that belong to different journeys and from various LRUs, the calculated ETI/ETA for interchange points, may be different for some wagons. In this case the RU should calculate the appropriate ETI for each wagon and notify the respective RU/LRU.

The next RU calculates for its part of the journey the related ETI for the wagon until the next interchange point and this is done by all consecutive RUs. When the last RU receives the ETI/ETA from its preceding RU it calculates the estimated time of arrival to the end destination. This ETI/ETA is submitted to the LRU who notifies the customer accordingly.

Indicative Example

An indicative example of how ETIs are calculated and the respective parties are notified is shown in the figure below (Figure 1 -4).

In this example Railway Undertaker (RU1) handles wagons 1 and 2 from Lead Railway Undertaker LRU1 and wagon 3 from LRU2. At interchange point C the transport for the wagons 3 to 5 will be done by RU3, whereas the wagons 1 and 2 will remain in the train of RU1 up to interchange point E where the responsibility passes to RU2. In this case RU1 must calculate the ETI for interchange point C for wagons 3,4,5 and send these values to LRU2. Interchange point C for wagons 1 and 2 is not a relevant point. For these wagons he must calculate the ETI for point E and send these values to LRU1.

Figure 1‑4

Alerts

The ETI/ETA of intermodal units loaded is the same as the wagons ETI/ETA for the interchange points. It is important to note that RU cannot calculate the ETI/ETA beyond the rail transport segment. It is the LRU responsibility to compare the ETI/ETA with the commitment to the customer. Deviations from the predefined agreements will trigger an alert management in the LRU to send alert messages to the RU in charge and to all following RUs involved in the transport chain to indicate the revised ETI/ETA in relation to the commitment to the customer.

Deviations

An LRU may enquire about deviations an RU regarding wagon ETI, using deviations messages. These messages follow an enquiry/ response model similar to the one presented in the train location messages.

Contents

Message

Contents

Wagon ETI/ETA

RU identification which has produced the ETI or ETA,

Departure or previous interchange station (ETI or departure time at origin station),

Train number starting from departure or previous interchange station (from ETI or departure time at origin station),

Actual departure date and Time of the train,

Arrival or next interchange station (ETI/ETA end),

Train number arriving at the ETI /ETA end station (Arrival or next interchange station),

Arrival Date and Time of the wagon (ETI or ETA).

Alert

Wagon number,

Commitment to the customer: Arrival Date and hour,

Actual ETA: Date and Time

Enquiry about wagon deviation

Request (LRU)

Response (RU)

Wagon number

LRU identifier

For each reporting point

Reporting location

Wagon reporting point status (departure, yard arrival, yard departure, interchange arrival, arrival at destination yard)

Responsible RU at reporting location and according wagon reporting point status

Re-scheduled time (against current schedule if multiple reschedules)

ETI, if Reporting point is an interchange point,

Actual time at reporting point

For each deviation at that reporting point…

Reason code and delay time for this reason

Wagon Movement

Purpose

Wagon movement is provided by a set of messages exchanged RUs and LRUs, including:

Wagon Release notice

Wagon Departure notice

Wagon Yard arrival

Wagon Yard departure

Wagon Exceptions message

Wagon Arrival notice

Wagon Delivery notice

Wagon Delivery confirmation

Scenarios

Message

Description

Wagon Release notice

This message is sent from a LRU to a RU and it is used to tell the RU in charge that the wagon is ready for pull at the customer sidings (i.e. place of departure according to the LRU commitment) at the given release time (date and time of departure). Apart from the message elements required (see contents), RU and LRU will have to access TAFTSI databases to get details regarding transportation unit details (id, size, type), capacity, total weight, dangerous good information

Wagon Departure notice

This message is submitted from the RU to LRU to inform of the actual Date and Time that the wagon has been pulled from the place of departure. The LRU store this event in the Wagon and Intermodal Unit Operational Database. With this message exchange the responsibility for the wagon changes from customer to the RU. Apart from the message elements required (see contents), RU and LRU will have to access TAFTSI databases to get details regarding transportation unit details (id, size, type), capacity, total weight, dangerous good information

Wagon Yard arrival

This message is submitted from the RU to LRU to notify that the wagon has arrived at its yard. This message may be produced based on the results of a "Train running information" message. The LRU must store this event in the Wagon and Intermodal Unit Operational Database

Wagon Yard departure

This message is submitted from the RU to LRU to notify that the wagon has left its yard. This message may be produced based on the results of a "Train running information" message. The LRU must store this event in the Wagon and Intermodal Unit Operational Database

Wagon Exceptions message

The RU informs the LRU of unexpected events occurring in the wagon that might affect the ETI/ETA. These events may require additional action bt the LRU and usually require a new ETI/ETA calculation. If the LRU decides to have a new ETI / ETA, sends a message back to the RU, with the indication "ETI/ETA requested". The new ETI / ETA calculation must follow the procedure described earlier (see Shipment EIT/ETA). The LRU must store this event in the Wagon and Intermodal Unit Operational Database. Apart from the message elements required (see contents), RU and LRU will have to access TAFTSI databases to get details regarding transportation unit details (id), and dangerous good information

Wagon Exceptions message New ETI / ETA Request

The LRU sends this message to the actual RU, which has sent the Exception message, to request for new ETI / ETA calculation. The LRU sends this message also to all following RUs to inform them about the deviations. The need for a new ETI / ETA calculation is up to the LRU and is not necessary in any cases. RU and LRU must have to access TAFTSI databases to get details regarding transportation unit details (id), and dangerous good information

Wagon Arrival notice

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).

Wagon Delivery notice

The last RU in a wagon transport chain must inform the LRU that the wagon has been placed at the consignee’s sidings

Wagon Delivery confirmation

The last RU in a wagon transport chain may send a second time a Wagon Delivery Notice to confirm the delivery to the customer, including this time the customer identification details. This message is sent as a Wagon Delivery Confirmation.

Contents

Message

Contents

Wagon Release notice

Wagon number,

Place, Date and Time of departure (Place from which a transport is scheduled to depart).

Wagon Departure notice

Wagon number,

Place, Date and Time of departure (Place from which a transport is scheduled to depart

Wagon Yard arrival

Wagon number,

Yard of arrival identification,

Date and Time of arrival at the yard.

Wagon Yard departure

Wagon number,

Yard of departure identification,

Date and Time of departure from the yard.

Wagon Exceptions message

Wagon number,

Place, Date and Time of disruption (Place where something unexpected happens during the transport),

Reason / Disruption code

Wagon Exceptions message New ETI / ETA Request

Wagon number,

Place, Date and Time of disruption (Place where something unexpected happens during the transport),

Reason / Disruption code,

New ETI / ETA request

Wagon Arrival notice

Wagon number,

Identification of Yard of the RU,

Date and Time of arrival

Wagon Delivery notice

Wagon number,

Identification of placement on consignee sidings (location, zone, track, slot),

Date and Time of placement

Wagon Delivery confirmation

Wagon number,

Identification of placement on consignee sidings (location, zone, track, slot),

Date and Time of placement

Customer identification

Interchange Reporting

Purpose

Interchange reporting includes a set of messages related to the transfer of responsibility for a wagon between two railway undertakings. This responsibility transfer occurs at interchange points. It also commands the new RU to make an ETI calculation and to follow the process described Shipment ETI / ETA.

The messages to be exchanged include:

Wagon Interchange Notice

Wagon Interchange Notice / Sub

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. 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 and 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.

Scenarios

Message

Description

Wagon Interchange Notice

With the "Wagon Interchange Notice" 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" the RU 2 informs its IM, that it has accepted the responsibility.

Wagon Interchange Notice / Sub

With the "Wagon Interchange Notice / Sub" the RU 2 informs the IM, that it has taken over the responsibility of a particular wagon

Wagon Received At Interchange

With the "Wagon Received At Interchange" message the RU 2 informs RU 1 that it accepts the responsibility for the wagon

Wagon Refused At Interchange

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.

Contents

Message

Contents

Wagon Interchange Notice

Wagon number

Train number (only if the wagon is in a train)

Location; date and time of interchange

Wagon Interchange Notice / Sub

Wagon number

Train number (only if the wagon is in a train)

Location; date and time of interchange

Wagon Received At Interchange

Wagon number

Location; date and time of interchange

Wagon Refused At Interchange

Wagon number

Location; date and time of interchange

Reason code for the refuse

Further Description (optional)