We’ve all been there – waiting for a train that is steadily getting later and later. When will it arrive? Surely it can’t be that hard to know where trains are?
In this post, originally given as a presentation at the inaugural UKRRIN student conference, I’m going to introduce three case studies in train operations, train forecasting and railway condition monitoring. I’ve identified five frames-of-reference that are used for reporting train position. We’ll discuss the challenges that face the UK in reaching knowledge of train position to an accuracy of 2 metres (Durazo-Cardenas et al. 2014).
About me
I’m a PhD Researcher looking at next generation railway track condition monitoring. In my work I’m taking data from train-mounted inertial sensors and using it to estimate the geometry of railway track. My research focuses on the benefits and challenges of instrumenting more and more passenger and freight trains.
Early on in the PhD I, along with Dr Chris Morris, helped to build the acumen Operational Decision Support Tool at Network Rail. I later joined Network Rail full-time as an Operations Interface Manager and am now responsible for the ongoing support and maintenance of acumen alongside our wrong route tool, aSIST, which alerts signallers to incorrectly set routes.
Case Studies
- Train Operations
The first case study relates to the routing of trains through signals and points. While some of this is automated through Automated Route Setting (ARS) systems, signallers still have to manually set routes and signal aspects in areas without it, and they occasionally have to switch ARS off in times of perturbation.
While many systems are helping to reduce the workload of signallers, there is not always the right information available for them to make optimal decisions on routing trains, especially when it comes to prioritising certain trains at a junction or making decisions to re-platform a train. Real-time data from signalling systems is publicly available from the open Train Describer feeds though it is very difficult to work with without accompanying reference data. Individual signalling areas, stations and routes have unique local geography and data is frequently isolated from other areas.
2. Train Forecasting
The second case study is on estimating the arrival time of trains at stations. This will be familiar to most of you as this is the information that is displayed on departure boards!
The information that drives these departure boards comes from the Darwin system, run by National Rail Enquiries and Rail Delivery Group. Darwin updates the forecasted arrival time for trains based on operations data from Train Describers (see above) and TRUST, a mainframe system which reports train arrival and departure times and lateness.
Other industry systems perform forecasting of trains – Traffic Management Systems and Operational Decision Support Tools such as acumen incorporate their own forecasting algorithms. However, there is not always sufficient information from running train services (e.g. GPS position and train speed) to provide real-time updates, and TRUST is only capable of reporting train movements to the nearest minute (rounded down).
3. Condition Monitoring
The third and final case study looks at track and infrastructure condition monitoring. This is a vital task for infrastructure managers like Network Rail, and a key business challenge is identifying and mitigating a developing fault before it causes line closure.
Network Rail operate a fleet of Track Recording Vehicles to inspect the condition of railway track geometry. You can read more about the New Measurement Train, which operates in the fleet, on the Network Rail website.
This fleet is expensive to operate and can usually measure tracks once per month, at best. Researchers around the world have been working to augment inspection data from Track Recording Vehicles through attaching sensors to in-service passenger and freight trains, and here in Birmingham a spin-off company, MoniRail, was formed to take railway track condition monitoring forward (Entezami et al. 2019).
However, there are challenges with ensuring that repeated measurements of the same track line up with each other – especially for data from in-service vehicles, as we don’t always know where they are supposed to be going!
Where is my train?
I’ve identified five different layers in which the position of a train can be reported. These are all used in standard industry processes, but it can be quite tricky to relate a position in one layer to a position in another. They are:
- Timetabling, in which trains are reported at discrete locations (timing points) as denoted in their timetable
- Signalling, in which trains are reported as entering or leaving block sections protected by a signal
- Geospatial, in which positions of trains are identified from sensor readings from satellite navigation systems such as GPS devices
- Track Map, in which trains are reported at points along surveyed track centreline links
- Engineering, in which trains are reported at distances along a track section denoted by its Engineer’s Line Reference
Timetabling Layer
This is the layer in which train timetables are constructed. A timetable is made up of a sequence of Timing Point Locations (TIPLOCs) that includes both stations – used by passengers for boarding and alighting – as well as other locations such as junctions.
More information is available in the working timetable, which includes non-passenger trains and locations. Timetable rows also include platform numbers and line indicators, though these are subject to change when the train is on the move!
When trains are running, their performance against the timetable is monitored through the TRUST mainframe system. TRUST uses Station Number (STANOX) codes instead of TIPLOCs – these can be converted relatively easily. There are many other location code reference systems in uses, see Identifying Locations for more information.
Signalling Layer
This is the layer which signallers use to control the movement of trains. In fixed-block signalling, which is still in use in the majority of the UK, only one train can occupy a section of track at a time – these sections of track are referred to as berths. The movement of trains in and out of these sections is controlled by signal aspects:
- red indicates that the next section is occupied;
- yellow that the next section is clear but the following section after that is occupied;
- double yellow that the next two sections are clear but the third section is occupied;
- green that the next three sections are clear.
Signallers are responsible for setting signal aspects and directions of points to ensure that trains are correctly routed according to their timetable. A signaller on shift will be responsible for many signals within a train describer area – each area is a discrete, self-contained system.
Train Describers record information about their operation – which trains are occupying which berths, which signal aspects are displayed, direction of points, routes set, track circuit occupations etc. This information is published over the S Class and C Class data feeds which are publicly available, however the reference data required to decode it – signalling scheme plans, Serial Output Tables and stepping tables – are not public.
Geospatial Layer
This layer will be familiar to any of you who have ever used a handheld GPS device to record a cycle ride or similar. It allows the location of the device to be reported in a globally identifiable way. Devices may be fitted to trains or attached to lineside equipment.
The main issue with collecting geospatial data is the high volume and poor semantics. As you can see from the graphic above, there is a high variation in the absolute location of data points, and it can be difficult to associate them directly with a point on a specific track section in a track map.
Other issues are variable uncertainty of the location of each point and poor or non-existent signal quality in tunnels.
Track Map Layer
This layer is a geographical map of track connections, approximating the centreline of individual railway links. This is typically surveyed through aerial Lidar imagery or lineside surveying equipment, which give the location of individual nodes of a line in the Geospatial Layer. There is uncertainty associated with these positions (Grosch and Crespillo 2020).
While this is a ‘graph’ network model (similar to the TPS network model in the Timetabling Layer and individual signalling scheme plans in the Signalling Layer), individual nodes and edges of the different models cannot be directly linked together to relate locations from different models, as they are missing common attributes due to their different business purposes.
Engineering Layer
The final layer in which a train position can be reported in is in mileages along a designated track section (identified by its Engineer’s Line Reference code). The master reference for all track sections is the National Electronic Sectional Appendix (NESA). An extract from the PDF version is displayed above. The underlying data is CAD-based.
Locations in this layer are recorded as distances along the track from its origin. This was historically reported in miles and chains, though locations are now mostly reported in metres. Lineside assets such as bridges, many of which were constructed in Victorian times, may have their track mileage displayed on their structure in the form of a location designation.
This layer is the basis for track geometry data reports (see Condition Monitoring). The New Measurement Train reports variation of track geometry in this layer, as distances along the track section in question.
Conversions Between Layers
It can be quite difficult to convert positions reported in one layer into positions reported in another layer.
Some transformations have standard industry processes which enable conversion.
Signalling ↦ Timetabling (standard process)
Positions within signalling berths can be converted to timing point locations through looking up the STANOX code for the berth step in the SMART database extract. This is a standard process used for automated reporting of trains via the TRUST mainframe.
Timetabling ↦ Geospatial (standard process)
Approximate geographical position of TIPLOCs is reported in the BPLAN geography database. This can be used to give approximate locations of these stations.
Other conversions are possible, but are not standardised. They typically rely either on additional information which is not publicly available, or on making assumptions about the quality of underlying reference data.
Timetabling ↦ Signalling
This would allow the planned route of trains through a signalling scheme, i.e. the sequence of signals and berths that are traversed, to be known in advance from its timetable.
While there is a lot of information in the Train Planning Network Model that could be used for this purpose, the model is not documented.
This transformation is the function performed by route setting subsystems, as well as by the aSIST wrong route tool, in order to determine which route should be set for a train based on its timetable. This typically requires detailed knowledge of the timetabling rules for the location in question as well as the signalling geography.
Geospatial ↦ Timetabling
This allows the identification of stations that trains are approaching or waiting at from GPS coordinates. These coordinates may come from sensors fitted to the train, but they can also be taken from mobile phones.
The figure above shows Voronoi polygons drawn around the geographical locations of stations based on their TIPLOC codes. Any point within a polygon is closer to that station than any other station. This can be used to estimate the closest station at any GPS coordinate and detect when a train passes a station (at which point it will start getting further away) or becomes closer to the next station than the previous (by passing the boundary between polygons).
Geospatial ↦ Signalling
The signalling layer is logically, rather than geographically, defined – think London Underground map. We can get a geographical view of berth boundaries by comparing timestamps for berth step messages with GPS samples. This gives us an estimate of where the boundary between berths is located.
Geospatial ↦ Track Map
A GPS point taken from a train can be related to the track map via a process known as map matching. This takes the nearest point on a line in a map to the coordinates of the GPS point, and fixes the position of that point onto the line.
Due to the error inherent in GPS coordinates, this method has significant limitations. It is easy to select the wrong line and position the train incorrectly. There is a lot of research in this area aiming to improve the matching process, but it will always be an estimation due to the inherent uncertainty in both the GPS measurements and the track map accuracy (Crespillo, Heirich, and Lehner 2014; Heirich 2016).
Track Map ↦ Geospatial
Going the other way, and getting a GPS coordinate from a position within the track map, has similar issues. All positions of a train within a track map (which is, internally, stored as a poly-line of nodes and edges) are reported as a proportional distance along that line. We can interpolate this position to get a GPS coordinate of that point along the line. However, the line cannot fully represent the true geography and the interpolated point may have an error compared with the true position of the actual point in geospatial coordinates.
Track Map ↦ Engineering
Both the track map and the Sectional Appendix are concerned with physical railway infrastructure, and they both with a common system of reference codes – Engineer’s Line Reference codes (ELRs) and Track IDs (TRIDs). A given segment of track in the track map network model can be identified by its ELR and TRID, which can be related to the Sectional Appendix.
There are issues when it comes to converting between positions. Due to the uncertainty inherent in representing geographical data, the length of a poly-line representing a track in the track map may have a different length to the surveyed engineering track length reported in the Sectional Appendix. We can, however, convert between them by treating the distance along a poly-line in the track map as a distance from the origin of a line of route (LOR) in the Sectional Appendix.
Engineering ↦ Geospatial
A final conversion requires measurements of track geometry that have already been base-lined against the engineering layer. Track geometry reports from the New Measurement Train are given in metres from the origin of the Line of Route. If GPS samples are also available, we can determine the geospatial position (accounting for uncertainty) of a specific feature in the track such as a curve or set of points.
Bonus: Timetabling ⇄ Track Map
While not on the diagram, theoretically the track centreline network model (part of the Track Map layer) and the train planning system network model (part of the Timetabling layer) are isomorphic graphs. This means that, in theory, each node or edge in TPS can be related to a node or edge in the track centreline map, though this would be a hard problem to solve given the size of the graphs and lack of common attributes.
If solved, it would allow a direct relationship between nodes and edges in both databases. For example, any track segment in TPS could be annotated with its Engineer’s Line Reference.
Improving Train Operations
Many of the challenges of positioning trains for operational purposes are solved through modern signalling deployments like ETCS, and signalling upgrades are improving the quality of reference data where they are taking place
However, there are many lines in the UK that are not likely to receive significant upgrades in the near future, and fixed-block signalling will continue until at least 2050 (Aoun, Quaglietta, and Goverde 2023).
There is a lot more that we can already do given data already available from Train Describers. Being able to link operational data to engineering data such as the track map would enable greater understanding of signalling geographies and facilitate improved interfaces for operational staff. For example, linking berth and signal number attributes directly to the track map would allow the position of a train to be reported directly in that layer.
Improving Train Forecasting
A big gap in capability here is the lack of nationwide real-time GPS data from train services. With GPS data it is possible to estimate the position and speed of a train which, in combination with the track map network model, can give greatly improved forecasts of sectional running time. This data is already available but is not universal.
Significant improvements can also be made here by improving the quality of signalling data e.g. geographical berth locations and distances would contribute to knowing how far a train has to travel. If done in a joined-up way, this could be used to improve the reference information that is used for train planning and provide evidence to support changes to section timings and distances.
Finally, improving the underlying data to support forecasting would allow better systems to be built to support route controllers and station staff in tactical decision making e.g. train re-routing or re-platforming.
Improving Condition Monitoring
With increasing volumes of data available on the condition of track and surrounding assets, it is critical to have a consistent frame of reference for all reports and to be able to relate subsequent reports to one another in order to observe the evolution of asset condition.
Information from other layers e.g. timetables and train movements from the timetabling layer and signal locations and berth movements from the signalling layer can be used to enrich asset condition data. If timetables can be related to the track map and ELR codes, estimates could be made of the loading pattern of a section of track to assist in planning maintenance interventions. Track geometry reports could be directly related to geographic coordinates and signal numbers to assist in managing temporary speed restrictions.
Finally, increasing interest in fitting sensors to in-service vehicle provides a valuable source of live GPS and inertial data for other use-cases such as train forecasting. This has potential benefits beyond condition monitoring, such as providing accelerometer data to understand braking profiles, detecting stopped or stranded vehicles, or identifying vehicle faults.
Conclusions
I’ve only briefly touched on the three case studies here. Each one of them is a critical business process that is part of the running of the railway.
However, the data that supports each of these business processes does not exist in isolation. The railway is a big and complicated system and it is easy to look at only one part of it – if I’m a track engineer, I’m not interested in signals, if I’m a signaller, I’m not using ELR codes or mileage to set routes for trains.
Information from different business areas can be valuable even outside of that area – knowledge of traffic patterns from operations helps track engineers in understanding how track gets loaded, knowledge of track sections from engineering helps operators in knowing how far trains have to travel. By working to better integrate existing data sources together we can work towards solving some of the big challenges facing the railway today.
Of course, we could solve this by starting from scratch – but is that likely to happen?
Bibliography
Aoun, Joelle, Egidio Quaglietta, and Rob M.P. Goverde. 2023. “Roadmap Development for the Deployment of Virtual Coupling in Railway Signalling.” Technological Forecasting and Social Change 189: 122263. doi:10.1016/j.techfore.2022.122263.
Crespillo, O. G., O. Heirich, and A. Lehner. 2014. “Bayesian GNSS/IMU Tight Integration for Precise Railway Navigation on Track Map.” In 2014 IEEE/ION Position, Location and Navigation Symposium – PLANS 2014, 999–1007. doi:10.1109/PLANS.2014.6851465.
Durazo-Cardenas, I., A. Starr, A. Tsourdos, M. Bevilacqua, and J. Morineau. 2014. “Precise Vehicle Location as a Fundamental Parameter for Intelligent Self-Aware Rail-Track Maintenance Systems.” Procedia CIRP 22: 219–24. doi:10.1016/j.procir.2014.07.002.
Entezami, Mani, Clive Roberts, Edward Stewart, Graeme Yeo, Alfredo Peinado Gonzalo, Mick Hayward, and Peter Ainsworth. 2019. “Continuous Railway Track Monitoring Using Passenger Trains.” In World Congress on Railway Research.
Grosch, Anja, and Omar García Crespillo. 2020. “Impact of Unknown Digital Map Errors on Satellite-Based Navigation in Railway.” In 2020 European Navigation Conference (ENC), 1–12. doi:10.23919/ENC48637.2020.9317448.
Heirich, Oliver. 2016. “Bayesian Train Localization with Particle Filter, Loosely Coupled GNSS, IMU, and a Track Map.” JS 2016: e2672640. doi:10.1155/2016/2672640.
Image References
- Case Study 1 – Train Operations: https://www.networkrailmediacentre.co.uk/news/220m-scheme-signals-rail-progress-in-the-valleys
- Case Study 2 – Train Forecasting: https://www.flickr.com/photos/hhhumber/2080638312/
- Case Study 3 – Condition Monitoring: https://www.networkrail.co.uk/running-the-railway/looking-after-the-railway/our-fleet-machines-and-vehicles/new-measurement-train-nmt/
- Timetabling Layer: TPS (see https://wiki.openraildata.com/index.php/Reference_data#Train_Planning_Network_Model), West Midlands Railway (see https://www.westmidlandsrailway.co.uk/travel-information/journey-planning/timetables)
- Signalling Layer: acumen (see https://blog.bham.ac.uk/bcrre/2020/07/06/automating-data-into-useful-information-to-support-decision-making/)
- Geospatial Layer: ITED (see https://www.railengineer.co.uk/enabling-better-performance/), OpenStreetMap (see https://www.openstreetmap.org/)
- Track Map Layer: NWR Track Model (see https://raildata.org.uk/dataProduct/P-d6c0c7ee-6743-4999-9b9e-d2dd39585bdb/documentation)
- Engineering Layer: https://sacuksprodnrdigital0001.blob.core.windows.net/sectional-appendix/Sectional%20Appendix%20full%20PDFs%20December%2024/London%20North%20Western%20(South)%20Sectional%20Appendix%20December%202024.pdf