About Offsets

This is the first of two posts posted today about offsets, the other is ‘A Study in Offsets: Aviemore’, an example of the work that we’ve done to add a new station to our Train Describer tables.

There are several different mechanisms in which train services may receive real-time reports about its progress through an area. For areas without a Train Describer (TD) this is entered manually into TRUST. In some areas, with appropriately fitted trains, the data may originate from GPS via the industry GPS gateway. In areas with TD data, this data is calculated by SMART. The process of updating what Network Rail know as ‘Berthing Offsets’ in SMART, to calculate the times, is slow.

The real-time data in TRUST is a key component in the process in which Network Rail and operators compensate each other for delay known as Schedule 8. The Performance Data Accuracy Code (PDAC) details to some degree the level of interest in this area and the processes which Network Rail must take for these updates.

Realtime Trains started developing its own offsets in August 2013. It began by covering my then commute between Southampton Airport Parkway and Bournemouth and slowly extended to cover the rest of the Wessex division by the end of that year. At the time of writing in November 2019, Realtime Trains now has detailed coverage of over 4000 locations with 41,000 individual records. By contrast, the last extract of SMART I had received has 3,000 locations with just shy of 30,000 individual records.

There are several ground rules in collecting the data to generate offsets followed by Network Rail:

• Use a timing device calibrated with a radio time signal
• Capture wheels stop and start times for arrivals and departures respectively
• Passing times captured in the midpoint of a platform or entering a junction
• Capture each potential move multiple times, with different rolling stock types where possible

Realtime Trains follows the same rules except we consider the ‘average train’ where possible as opposed to multiple types of train. We will perform analysis before measuring to identify the types we need to measure in order to achieve an average train measurement. For example, a line that sees a 50/50 mix between four and eight carriages trains will have an average train of 6 carriages and, as a consequence, we will measure an even balance of four and eight car trains to provide the appropriate offset.

The final rule for Network Rail is to review offsets every five years or on request by the industry. Realtime Trains, by contrast, reviews offsets at major locations at least once a year and the entire Train Describer population is checked at least every two years… by a team of two people.

How an offset gets calculated

Pictured above is a diagram showing one track of a double track railway with signals and stations. There is a distinct home and starter signal for each station. What follows is a worked example of what we do to generate offsets.

This line has an hourly four car EMU service which calls at xx02 at station A and xx07 at station B. No rail-head adhesion issues were noted as we visited in summer. If we are aware of rail-head adhesion issues then we discard data as it is not worthwhile using for a general case. The same case generally applies if there is a short term temporary speed restriction that slows the trains down adversely for a general case - if we have no data to begin with, we will continue the measurement and calculation and note the location for a remeasurement as soon as is reasonably practical.

Due to the nature of the service at these stations, we visited both stations on three days across two weeks and the trains were essentially running normally. In some cases, we may develop a plan to shuttle between stations on board services if this allows for more rapid coverage.

It should be noted that this is predominantly an activity performed on a voluntary basis by a select few individuals and I gratefully appreciate their time and assistance. Realtime Trains funds this privately and will reimburse travel and hotel costs where necessary¹ - we have no external support in any respect from the industry. We are reliant on the service running broadly to plan and following the Working Timetable service plan as we strategically target areas where possible. Network Rail’s approach does allow for requests to be made for specific routes to be taken for measurement making their job in that respect easier.

The reason for visiting multiple times allows us to reduce the statistical bias towards specific conditions on a given day which may result in different driver behaviour in terms of interacting with the station.

There are four distinct steps that can be produced from this diagram:

• 0003 to 0005, creating an arrival offset to station A
• 0005 to 0007, creating a departure offset from station A
• 0007 to 0009, creating an arrival offset to station B
• 0009 to 0011, creating the departure offset from station B

We’ll look at station A. The below table shows an example of trains measured at station A:

The first thing to note from these values are that there are some noticeable outliers. The arrival offset has a large variance which can be for various reasons but the primary factors are the speed of the train on approach and the preferred braking profile. Arrival differences normally show a greater variance than departures and this station is no different. All data would be considered valid for our purposes in this case and therefore an average would be taken of all values. Therefore, the calculated offsets for this station would be:

• Arrival, step 0003 to 0005: +42 seconds
• Departure, step 0005 to 0007: -5 seconds

Those calculated offsets will then be taken and put into our Offsetstore system. I’ll touch more on that in the future but it is our data warehouse for anything and everything that we can get hold of about the rail network. For SMART, the PDAC process means that it will then be sent to all interested parties for agreement (or dispute) and then continue through multiple layers until it becomes reality in that system.

As mentioned previously, you can find a real world example of Aviemore in detail from start to finish of in the other post today. We continue to develop our work around the Train Describer and offsets and the Highland Main Line is pioneering our work in this area. I believe this area of work will radically improve realtime reported times when we begin to roll it out across the country.

On a final note, this is a really interesting topic for myself, and for various people I talk to in the industry (I spent five hours talking about Train Describers and offsets to various people on Friday!), so if you’d like to ask more information please get in touch! You can contact me personally on Twitter, on the Realtime Trains page on Facebook or via our feedback email. If you’re part of the industry and would like to know more or work with us, please see our contact page.