Small delays, or subthreshold delays as they are called in the rail industry, are the cause of many services arriving late at stations. Previous modelling for the Rail Safety and Standards Board with Greater Anglia showed that on time arrivals can reduce by up to 23% when services suffer from this type of subthreshold delay. This is a relatively large drop in performance, and the challenge for the rail industry is finding the cause of these delays and eliminating them to improve performance.
Timetabled arrival times are matched to the capability of the trains delivering the services, but may sometimes be challenging for some stops, and if this is the case then the risk of lateness is increased. This is just one of the possible causes of lateness, and could be resolved at these stations by making small changes to timetable timings.
“For subthreshold delays we have no where to go…” Marc Ware, Performance Manager, Greater Anglia
What we did
Risk Solutions delivered a detailed modelling exercise involving Network Rail and four Anglia route operators; Greater Anglia, C2C, ARL and MTR Elizabeth Line. The objective was to identify hotspot locations where there might be an increased risk of lateness due to challenging timetable timings.
To do this we used SaviRPM to model the fastest possible train movements along their journeys, using their physical power and weight (and other technical characteristics), adding time for driving style and other small timing variations – these dynamic run timings (DRTs) represented realistic journeys but without any large delays due to typical operational incidents. We compared these realistic journeys with a second set of modelled journeys, but this time using the expected (timetable) train movement times. In both cases we added typical small delays to see how well the services performed under stress.
We were looking for locations where trains were less likely to arrive on time using the realistic journey times, compared with the expected time according to the timetable and train planning rules. These hotspot locations would be where it is potentially more difficult to meet the timetable arrival times.
What we found
Modelling services using SaviRPM helped operators identify the locations where timetable timings were particularly challenging, given the capability of the railway stock used for each service. After finding these hotspot locations Risk Solutions were able to model services with some carefully chosen adjustments to timetable timings – some timetable tuning. This demonstrated that it is possible to improve on time arrivals by approximately 10-20% at hotspot locations, with an overall improvement to on time arrivals of between 2% and 4% for affected service groups. These figures may appear like marginal gains, but to train operators they represent a valuable improvement in performance, and worth pursuing.
Collaboration through a joint modelling exercise once again proved to be a powerful way for railway operators and Network Rail to understand performance issues and identify where joint effort should be focussed to deliver improvements.
“The modelled performance improvement is worth pursuing in the next timetable update” Ben Squires, Performance Manager, C2C
What operators do with this information
Operators have used the modelling results to evidence hotspot issues and discuss with Network Rail how train planning rules can be adjusted, tuning timetable timings, to improve performance.
A key benefit of this process of timetable tuning is being able to identify not only where a timetable might be challenging, but also where timings are achievable without any risk of lateness. And therefore if services are experiencing lateness then there are likely to be other operational causes to explore and resolve.
Being able to separate timetable risk from other operational risks is a unique piece of intelligence offered by modelling using SaviRPM.
“The model conclusions correlate with what we see on a day-to-day basis” Marc Ware, Performance Manager, Greater Anglia
“This is really useful evidence to support our discussions with Network Rail about designing a better timetable” Mark Walker, Performance Manager, ARL
We enhanced SaviRPM to model train movements using the technical capability of stock (Technical Running Times, TRTs) adjusted by typical driving style to create Dynamic Running Times, DRTs. This included analysing historic train timing data and GPS data to be able to characterise driving styles and calibrate modelled service timings.
Train journeys were modelled using these dynamic timings, and compared with journeys using the train planning rules used to construct timetable timings. In both cases low levels of random delays (sub three minutes) were used to disrupt trains, and were calibrated to reproduce typical good service performance. Multiple model simulations of the same timetable produced a range of performance results for analysis.
The on time station arrival performance of the simulated dynamic timings were compared with the train planning rule timings, by location and train service group. Locations were highlighted as hotspots if there was a higher risk of lateness using the dynamic timings compared with the train planning rules. The root causes of the performance issues were identified, and a potential solution developed involving adjusting timetable timings by 30 seconds or so at various locations. Adding time where there was a high risk of lateness, removing time where there was low risk.
The modelling was repeated with the adjusted timetable the overall improvement in performance was measured.
Dynamic running times can be used to adjust (or tune) timetabled timings to improve performance of services
Timetable tuning could help improve the percentage of services arriving on time at hotspot locations by 15-20%
Timetable tuning could help improve on time arrivals for a route by 1-2%
We would be delighted to hear from you if you are interested in finding out how SaviRPM could help you understand the drivers of good performance. Please get in contact.
We have published more information about SaviRPM and some case studies here: SaviRPM demonstration