The ETA Train functionality now fully live: trial period begins!

This release note is intended for the Traction suppliers

The ETA Train functionality is divided into two parts:

1. Insight into the train’s location in the hinterland.
2. Insight into the train’s arrival and departure times and the progress of operations at the deep-sea terminals in the Port of Rotterdam.

ETA Train in the hinterland
To retrieve the train’s location in the hinterland, the rail operator must provide the incoming and/or outgoing train number and the first departure date and/or outgoing first departure date in the rotation. If these details are not provided correctly, no match can be made with the train location data from the hinterland provided by an external party.

Once the details have been entered correctly, ETA Train data can be retrieved for the remaining timetable points that the train will pass on its way to the Port of Rotterdam and/or from the Port of Rotterdam back into the hinterland. These points, and therefore the data for each point, only become visible once the train has passed them. By default, these are the point of departure in the hinterland, the Dutch border crossing, Barendrecht Vork and the freight yards at the terminals.

ETA Train data cannot be retrieved retrospectively. This means that if the required details are only provided correctly by the rail operator from Barendrecht Vork onwards, the ETA Train information for the point of departure in the hinterland and the Dutch border crossing can no longer be retrieved.

Use the Tracking API to retrieve train location data from the hinterland. This specifically concerns the trainLocationReports, which is a voyage-level list. Each report contains the following fields: operationalTrainNumber, startDate, direction, trainAccessPointType, terminalShortName, trainLocationStatus, trainLocation, locationDateTime, bookedLocationDateTime, referencedLocationDateTime, trainDelay.

Please note: the Tracking API can be used to receive real-time updates on voyages, visits and (detached) handlings. To enable these real-time updates, the API uses a mechanism known as ‘long polling’. When you submit a request to listen for updates, you will immediately receive an update if one has occurred since your last request. If there is no update, the request will wait until an update occurs or will time out when the maxTimeout you specified is reached. Once the API-response has been returned and your client has finished processing the updates, you must always update your position. This ensures that the next time you request updates, the API searches for updates occurring after that position in the eventlog. This mechanism also enables batching, as you receive all updates as quickly as you can process them.

With regard to the trainLocationReports, it is important to be aware that you receive updates showing the before-and-after situation, containing only the changes. This means that if only one handling has changed, you will receive only that handling within the visit within the voyage, rather than all containers and visits. The same delta per item applies to the trainLocationReports of a rail voyage: each update contains only the reports that have been added or changed, not the reports that you have already received in previous updates.

Please refer to the Hinterland Notification API Changelog for more information.

ETA Train in the port of Rotterdam

This part of the functionality provides visibility per pre-announced visit into the arrival and departure times, as well as the progress of operations. It includes the fields listed below. All of these fields can be retrieved by all parties involved in the visit.

1. Estimated time of arrival (ETA) 
   • Submit
     • Rail operator: submits the ETA when creating a visit. When timetable slots are used, the slot start time is automatically adopted as the ETA. Both the ETA and the timetable slot can be updated later.
     • Terminal & traction supplier: can update the ETA.
   • Retrieve
     • The rail operator, traction supplier and terminal can retrieve the ETA communicated by the other parties via the Tracking API

2. Delay reason
   • Submit
     • Traction supplier: can provide the reason for a train delay.
   • Retrieve
     • Using the delay reason, the terminal and rail operator can better assess the expected duration and impact of the delay. Both parties can retrieve the delay reason via the Tracking API.

3. Actual time of arrival (ATA) 
   • Submit
     • Rail operator, terminal and traction supplier: can provide the ATA and update ATA values previously shared by other parties.
   • Retrieve
     • The rail operator, terminal and traction supplier can retrieve the ATA communicated by the other parties via the Tracking API.

4. Planned start of operations 
   • Submit
     • Terminal: can provide and update the expected moment when loading/unloading of the first container will start, until the first CODECO has been received.
   • Retrieve
     • The rail operator and traction supplier can retrieve the planned start of operations shared by the terminal via the Tracking API.

5. Actual start of operations 
   • Retrieve
     • The actual start of operations is populated automatically when the first loading/unloading CODECO for the visit is received in HCN Rail and can be retrieved via the Tracking API.

6. Planned finish of operations 
   • Submit
     • Terminal: can provide and update the expected moment when loading/unloading of the last container will be completed, until the last CODECO has been received.
   • Retrieve
     • The rail operator and traction supplier can retrieve the planned finish of operations shared by the terminal via the Tracking API.

7. Actual finish of operations 
   • Retrieve
     • The actual finish of operations is populated automatically when the last loading/unloading CODECO for the visit is received in HCN Rail and can be retrieved via the Tracking API.

8. Estimated time of departure (ETD) 
   • Submit
     • Rail operator: submits the ETD when creating a visit. When timetable slots are used, the slot end time is automatically adopted as the ETD.
     • Terminal & traction supplier: can update the ETD.
   • Retrieve
     • The rail operator, traction supplier and terminal can retrieve the ETD communicated by the other parties via the Tracking API.

9. Actual time of departure (ATD)  
   • Submit
     • Rail operator, terminal and traction supplier: can provide the ATD and update ATD values previously shared by other parties.
   • Retrieve
     • The rail operator, terminal and traction supplier can retrieve the ATD communicated by the other parties via the Tracking API.

Submit

Retrieve

The table below should be read as a guide to retrieving data provided by the parties listed in the columns. For example, use Tracking API | Listen to ALL updates | visits.requestedVisitData.eta to retrieve the ETA shared by the rail operator.