The Digital Navigator: How Route Setting Systems Manage Traffic

At 08:22 on a busy Monday morning at London Waterloo — the UK’s busiest terminus with 24 platforms — a Southwestern Railway service arrives 4 minutes late from Southampton. It is due to depart again in 8 minutes on a different platform road to allow a faster service to use its original platform. The Automatic Route Setting system, which has been tracking the train’s progress since it passed Woking, has already adjusted: it has amended the route for the late train, pre-set the revised platform road, checked for conflicts with three other trains using the same station throat in the next 12 minutes, resolved a minor priority conflict with a suburban service that was due into the adjacent platform, and set the signals for the approaching train — all without a single controller touching a button.

The controller at the Waterloo Integrated Control Centre saw the late running on their screen, observed the automatic resolution on the route display, and returned their attention to a freight train that had stopped unexpectedly in the Woking area. This is the Route Setting System in operation: not replacing human judgement, but handling the routine so that human attention is available for the exceptional.

What Is a Route Setting System?

A Route Setting System is the software layer that sits between human operators (or automated timetable systems) and the safety interlocking. Its function is to translate high-level operational instructions — “route this train from signal A to signal B” — into the specific low-level requests that the interlocking requires: move point 112 to the normal position, lock section T34, request signal 214 to clear. The interlocking independently verifies that these actions are safe before executing them — the RSS makes requests; the interlocking grants or refuses them.

The distinction is important. The interlocking is a safety-certified system (SIL 4) that cannot be bypassed. The RSS is an operational efficiency system that is typically certified at a lower safety integrity level — a failure in the RSS that causes an incorrect route request will be caught by the interlocking’s safety logic. The RSS cannot compromise safety; it can only improve operational efficiency.

The Evolution of Route Setting: From Levers to AI

NX (Entrance-Exit) Route Setting

The NX (eNtrance-eXit) interface has been the standard human-operator route setting method since the first large-scale relay interlocking installations of the 1950s. The concept is simple: each signal position on the geographic display panel has a button. To set a route, the operator presses the entrance button (at the signal protecting the start of the desired route) and the exit button (at the signal at the end of the desired route). The RSS calculates the appropriate path between those two points, determines which intermediate points need to move and to what position, requests those moves from the interlocking, and — when the interlocking confirms all conditions are met — clears the entrance signal.

The operator does not need to know which specific points lie between the entrance and exit, what position each should be in, or what the locking dependencies are. The route table in the RSS encodes this knowledge. A large junction with 50 possible routes might require an operator to know 50 entrance-exit button combinations — compared to pulling hundreds of individual levers in the correct sequence as the pre-NX systems required.

ARS: Automatic Route Setting

Automatic Route Setting extends the NX concept by connecting the RSS to the live timetable — the electronic train schedule that specifies which train should be at which location at which time. ARS reads the timetable, correlates it with the live train describer (the system that tracks each train’s position across the network), and automatically sets routes for each train as it approaches a point in the network where a route needs to be set.

The ARS decision cycle for each train movement:

1. Train describer reports train identity and location approaching junction X.
2. ARS looks up the timetable: this train is scheduled to take the left route at junction X.
3. ARS checks: is the desired route available (no conflicting route set, no conflicting train present)? Is it time to set the route (early enough to ensure the signal is clear when the train arrives)?
4. If conditions are met: ARS sends the route request to the interlocking; interlocking verifies safety and executes; signal clears.
5. If conditions are not met (conflicting train, occupied section): ARS either waits and retries, or escalates to the conflict resolution module or human operator.

On a well-operated busy mainline with ARS, the controller’s primary role shifts from route setting to exception management — handling the situations that ARS cannot resolve automatically: major disruptions, infrastructure failures, emergency situations, and the judgement calls that require knowledge of context beyond what the system holds.

Traffic Management Systems: Beyond Route Setting

A Traffic Management System (TMS) — also called an Operations Management System (OMS) or Operational Control Centre (OCC) system — extends the functionality of ARS to include network-wide traffic management. Where ARS sets routes reactively (when a train approaches a decision point), a TMS manages proactively — looking ahead in the timetable, predicting conflicts before they arise, and adjusting plans to minimise delay impact across the whole network.

Key TMS capabilities beyond basic ARS:

• Conflict detection: The TMS continuously compares the planned timetable positions of all trains with their actual positions. When two trains are predicted to require the same section simultaneously — a conflict — the TMS identifies this minutes in advance, before the trains physically reach the contested section.
• Conflict resolution: The TMS evaluates the options for resolving the conflict: which train to hold, which to expedite, whether to reroute one train via an alternative path. It calculates the knock-on delay impact of each option across the wider network and recommends (or automatically implements, depending on configuration) the resolution that minimises total delay.
• Regulation: On dense metro systems, the TMS can adjust train departure times at origins and intermediate stops — a technique called “regulation” — to redistribute headways, preventing the bunching that occurs when one late train accumulates passengers from subsequent stations, grows heavier, dwells longer, and falls further behind schedule.
• Service recovery: After a significant disruption (infrastructure failure, rolling stock failure, passenger incident), the TMS assists with re-establishing normal service — rescheduling trains, advising on cancellations versus delays, calculating the most efficient recovery sequence.

The RSS–Interlocking–TMS Architecture

AI in Traffic Management: The Next Frontier

The introduction of AI and machine learning into TMS is the most significant development in railway traffic management in decades. Traditional TMS conflict resolution algorithms use rules-based logic — pre-defined priority rules (express over local, freight over maintenance) applied in sequence to resolve conflicts. These rules work well for common scenarios but struggle with novel combinations of disruptions and constraints that fall outside the rule set.

AI-based TMS systems use reinforcement learning — where an algorithm learns optimal decision strategies by simulating millions of disruption scenarios — to develop more flexible and context-aware conflict resolution. Early operational deployments have demonstrated:

• Better delay recovery: AI systems identify recovery sequences that human dispatchers miss — holding patterns, revised stopping sequences, and rerouting options that collectively minimise total delay rather than optimising individual train performance.
• Consistency under pressure: Human dispatchers performing well under normal conditions may make suboptimal decisions under the cognitive load of a major disruption. AI performance is consistent regardless of incident complexity.
• Learning from historical data: AI systems can identify patterns in historical disruption data — which types of incidents on which sections at which times of day produce the worst cascade delays — and proactively adjust plans before disruptions escalate.

Network Rail’s Digital Railway programme has piloted AI-assisted TMS on the East Coast Main Line, with results showing improvement in delay management compared to dispatcher-only control during disrupted operations. Similar programmes are underway at DB Netz (Germany), Infrabel (Belgium), and ProRail (Netherlands).

Consolidation: From Local Signal Boxes to Integrated Control Centres

Modern RSS and TMS technology has enabled a dramatic consolidation of railway operations. In the pre-digital era, each junction and station had its own signal box, staffed by operators who could physically see the trains they were controlling. A busy 100 km mainline might have 15–20 separate signal boxes, each controlling a few kilometres of track.

Modern CBI and TMS technology enables a single Integrated Control Centre (ICC) or Rail Operating Centre (ROC) to control hundreds of kilometres of route from a single building, with operators monitoring geographic display screens rather than physical lineside visibility. Network Rail’s programme of ROC consolidation has reduced the number of separate signalling control locations on the GB national network from over 800 in 2010 to a target of approximately 14 ROCs by 2030, each controlling 500–2,000 route-kilometres.

The operational advantages are substantial: standardised systems, centralised expertise, improved resilience (no single signal box failure stops operations), better data integration, and the ability to respond to network-wide events from a single location. The challenges include the loss of local route knowledge (operators in a ROC may not have the visual familiarity with conditions on the route they control that a local signaller had), and the concentration of risk (a ROC failure or cyberattack affecting a single location could impact a far larger network area than a single traditional signal box).

Editor’s Analysis

Frequently Asked Questions

Q: What is the difference between ARS and a Traffic Management System?

ARS (Automatic Route Setting) is a specific function — it automatically sets routes for trains based on a timetable and live train positions, replacing the manual NX button-press that an operator would otherwise make. A Traffic Management System (TMS) is a broader platform that incorporates ARS as one of its functions, alongside conflict detection and resolution, network regulation, service recovery assistance, performance monitoring, and operator decision support. ARS is reactive — it sets the next route when a train approaches a decision point. TMS is proactive — it looks ahead across the whole network, predicts where conflicts will arise before they become acute, and plans how to resolve them. Some older installations have ARS without full TMS; modern installations typically integrate both into a unified operations management platform.

Q: Can a route setting system override the interlocking?

No — this is a fundamental architectural principle. The RSS (including ARS and TMS) sends route requests to the interlocking, but cannot override the interlocking’s safety logic. If the interlocking determines that a requested route is unsafe — because a point is not confirmed in position, a section is occupied, or a conflicting route is set — it will refuse the request, regardless of what the RSS or a human operator has requested. The operator and the TMS can see the refused request and the reason given by the interlocking, and may choose to investigate or take alternative action, but they cannot instruct the interlocking to execute an unsafe route. This architectural separation — operational efficiency systems above the safety layer, with no capability to penetrate the safety layer — is what makes modern interlocking systems trustworthy despite the complexity of the software layers above them.

Q: How does ARS know which train is which?

ARS correlates train identity with track position through the Train Describer (TD) system — the signalling infrastructure component that tracks a “headcode” (a four-character alphanumeric identifier) associated with each train movement. When a train enters a block section, the track circuit or axle counter detects its presence, and the TD system automatically steps the headcode forward through the network display, tracking the train’s position section by section. ARS reads the current headcode positions from the TD and matches them against the timetable database — each scheduled train movement has a headcode associated with it — to identify which train is approaching which junction and what route should be set for it. In ETCS Level 2 environments, train identity is reported directly by the onboard ETCS system to the RBC and thence to the TMS, providing more reliable and precise identification than traditional headcode stepping.

Q: What happens when ARS sets the wrong route — is there a safety risk?

An incorrect route request by ARS — requesting the wrong platform road, the wrong junction branch, or an operationally undesirable path — will be executed by the interlocking if it is safe. The interlocking does not know or care whether the requested route is the “correct” operational choice; it only verifies that it is safe (no conflicting trains, points in correct position, sections clear). An incorrect route that is operationally wrong but physically safe will be set, and the train will proceed on the wrong path. The consequence is operational — a train routed to the wrong platform, or taking a longer journey, or causing a conflict with a subsequent train — not a safety incident in the immediate sense. The operational consequence may be significant (a train that takes a longer route may conflict with another train, causing a delay cascade), which is why ARS systems have route validation logic to check that the requested route makes operational sense before sending it to the interlocking. A complete ARS failure — the system stops functioning — typically causes a degraded mode where operators revert to manual NX button-pressing, which they are trained and equipped for.

Q: What is a “train describer” and how does it work?

A Train Describer (TD) is the system that tracks each train movement across the signalling network, associating a train identity headcode with its current location and stepping it automatically from section to section as the train moves. In traditional signalling, each track circuit feeds into the TD system: when a train moves from track circuit A to track circuit B, the TD detects the exit from A and entry into B, and updates the headcode display to show the train’s identity in the new location. This appears on the controller’s geographic display as the headcode moving across the screen, following the train’s path. Modern TD systems are integrated with ARS and TMS — the headcode positions are the primary input that triggers ARS route setting decisions. Where ETCS Level 2 is deployed, the TD information comes from the RBC’s continuous train position data rather than from fixed track circuit boundaries, providing a more accurate and continuous position report.