This is the third in a series of posts about offsets. The first two, posted last week, are about offsets and a worked example at Aviemore. This week, we’re covering why we use offsets. This post is about the here and now and doesn’t particularly discuss future work that may adjust how the process works, it’s merely an explainer as to why offsets are where we are.
As mentioned before, there are multiple methods in which a real-time train report may arrive into TRUST. On Realtime Trains, you can see the source of any report by rolling your mouse over the time in the realtime column, or tapping it on a mobile device, and it’ll bring up a small tooltip. Reports include manual entry via SDR or TRUST DA or automatically through the industry GPS gateway or using offsets via SMART.
The first question to be answered is “what constitutes the arrival and departure of a train service on the network?” For passenger services at a station, this is probably the time at which the doors are released and closed at a station platform. For all other services, it’s probably the time at which the wheels stop and start moving. By comparison in the airline industry, this typically is represented by brakes on and off and is reported automatically from the aircraft, where possible, to the airline systems.
In an ideal world, we would have a different set of data points to represent the difference between passenger and operational realtime reporting. In extreme scenarios, the doors may not release on a train service for minutes after arrival at a station which could be the difference between whether a passenger receives delay compensation or not. Delay compensation is currently derived from data sources using offsets and therefore would not permit issues such as this unless there was manual intervention. Back to the airlines, when a flight is considered potentially eligible for EC261/2004 the time at which the first door is opened is also tracked - this is considered the important time for an arrival.
In order to compute the actual doors release and close times of a passenger train, there would realistically need to be a train-borne mechanism to report timings. When offsets were first introduced the concept of internet connectivity onboard was still in its infancy, if even that, and you could still find pay phones on board meaning options were limited. These days, most rolling stock can now report back On Train Monitoring Recorder (OTMR) data in real-time, faults, position, etc, and this data could be fed back into the system to create a passenger centric view when connected together with other sources. That doesn’t always work though and it isn’t installed to all fleets so we have to find another route to fill the gap.
Operational reporting is important for performance and links back into Schedule 8, the mechanism in which operators and Network Rail compensate each other for delay, so having accurate timings is important. If we cannot always rely on train-borne information, and offsets are an old concept, then we must consider elements further down in the chart and the natural answer then becomes signalling.
Signalling equipment is able to provide information about the progress of a train service through an area - and therefore loosely where a train is. Timetabling and reporting is done on a level slightly higher than that in that we time based on locations between signals. Achieving timing data about a location, rather than a signal, could be done by applying an offset value to the time at which a train passes the signal. It’s a simple idea, and doesn’t allow for many additional factors in its current implementation, but is a simple and effective solution to the problem.
