This week I’m covering how major timetable changes, such as the biggest change to the Great Western Main Line in decades, and the rollout of new fleets of trains affect Realtime Trains and what we do to manage it.
This post was suggested by Chris Boots on Twitter in response to a call for suggestions:
What impact does a new Timetable have on RTT (especially the GWR one where IETs will start running to their new timings instead of the old HST ones)?
On the face of it, Realtime Trains downloads open timetable data from Network Rail and then displays it. We apply the real-time data from the same sources on top of those schedules on the day and then we’re done with it. The reality is somewhat different for major changes.
Minor timetable changes which involve tinkering around the edges of paths and minor timing alterations do not really require us to worry much. Changes such as Virgin High Frequency on the WCML in 2008, East Coast’s Eureka on the ECML in 2011 and the forthcoming change on the GWML require us to pay more attention. Realtime Trains has only been around since 2012 so this marks our first major change of this nature.
The change on GWR is considerable, the timetable is not just changing but also marks substantially accelerated timings taking advantage of the performance characteristics of the Hitachi train fleet. The East Coast Main Line is also seeing much the same changes in the latter respect with the introduction of the LNER fleet, as well as the forthcoming replacement of 180s with 802s by Hull Trains, making Intercity Express Trains and AT300s the main fleets in use for intercity service on both lines.
From a starting point in terms of displaying schedules, nothing really changes. In the case of replacement fleets, we may see changes such as the power type and timing loads. The HST timing load is out and replaced with values like DMU800 and EMU800. In the case of Greater Anglia, we now see DMU755, EMU755 and EMU745. For Northern, we now see D195 (really should be DMU195). One lurking issue is that we do not currently show changes of timing loads en route which will be fixed before the start of the new timetable.
Previous specifications of the timetable data implied a data limitation for DMU power types to a small selection of letters, but as you can see above they now may offer a wider variety of values. Other examples are EMU506 which is a Class 350 EMU timed at 110mph. I should make it clear that a power type and timing load combination is not advice of what is planned to operate on a train, although it can be a good indicator, it is merely what the service is timed for - any rolling stock with similar performance characteristics should perform just as well. The site is designed to replace information such as this so that it is easier to understand.
Real-time train reporting on the day on the network is done through a variety of mechanisms. The primary ‘as it happens’ for most industry systems are using berth offsets, which internally we know as step offsets, which are a reactive process to a train progressing through Train Describer enabled areas. TRUST receives its real-time updates through a system called Signal Monitoring and Reporting to TRUST (SMART) and Darwin, the RDG ‘One Version of the Truth’ system, has its own set of these offsets too. You can see the source of any report on Realtime Trains by placing your mouse over any time in the real-time column - on mobile and tablets just tap the time. We’ll cover step offsets in more detail in a future post.
The introduction of new rolling stock results in new characteristics we need to consider for the case of step offsets. An offset is typically calculated, for us, on the basis of the consideration of a ‘typical train’. With new rolling stock with improved acceleration and braking characteristics, this will normally shorten the offset measurement. Without changing the offset measurement, dwell times will appear to artificially decrease and, in some cases, sometimes report a calculated departure time before the arrival time. RTT has a mechanism if both times are reported via the same source (e.g. TD or TRUST) and the times are the ‘wrong way around’ (departure before arrival) then it will consider the train as to have not stopped at the location in question.
To mitigate these issues, we1 will actively remeasure stations with significant operational features to assess the variance between old and new rolling stock. We will also do the same if a ‘typical train’ is assessed to have changed, for instance if the average train length changes. If we find a new train has sufficiently changed the offset value at these locations, we will create a plan to remeasure the entire affected area. We have so far spent six months remeasuring for the introduction of the 80x fleet and will revisit the key locations after the December change to ascertain whether we need to make further changes for the shortened running times and consequential required driving performance changes.
The question that comes from the back of all this is probably “why?” The answer is simple – I want Realtime Trains to be the most accurate source of data possible for real-time running information, within the constraints of available data.
This week’s blog photo is of GWR 800316 and LNER 800111 at Reading station on 7th May 2019 is provided by Jamie Hunter.
-
There is a small group of people who measure and manage the step offsets and we alter them at least once a week. We currently have just shy of 40,000 step offsets across the network. ↩︎