How C-DAS closes the gap between a restriction being issued and a driver acting on it

The context in which we publish this blog series has recently changed. On 19 June 2026, two East Midlands Railway services collided near Elstow in Bedfordshire. Train driver Shaun Burton died and 162 passengers were injured. Our thoughts are with everyone affected by this tragic event.

The Rail Accident Investigation Branch (RAIB) is currently investigating the collision, and it would be wrong to draw any conclusions before this work is complete. We make no suggestion that the Elstow collision was the result of overspeeding and note the RAIB’s interim report finding that Mr Burton’s train was travelling below the maximum permissible speed at this location.

---

In our previous blog, we set out that the UK’s overspeed problem is not a technology gap. It is an information gap.
Speed restrictions exist. The process for getting them to drivers, in a usable form and at the right moment, is where the system is vulnerable.

This blog looks at the mechanism. How does a digital in-cab system actually close that gap, and why does the architecture of the solution matter as much as the intent behind it?

The answer matters for operators and procurement teams alike. Choosing to adopt an in-cab guidance platform is one decision. Understanding what makes a particular Driver Advisory System (DAS) more resilient, more deployable, and more future-ready than the others is where the real evaluation lies.

The information chain, and where it breaks

Our first blog covered this in detail. In summary, when a speed restriction is imposed on the GB network, it enters a communication chain. That chain depends on processes that are largely paper-based and reliant on human memory. There is often no verification that the information has reached the person who needs it.

The South Wales Main Line, Grantham South Junction, and Cambridge Junction incidents documented by RAIB in 2025 presented several failure patterns across those processes:

• A blanket speed restriction that did not reach drivers or signallers before the restriction point
• Drivers approaching diverging junctions without timely, unambiguous information about the lower speed limit that applied
• Controls put in place after one incident that failed to prevent a near-identical recurrence at the same location

In each case, the restriction existed. The failure was in transmission of that restriction.

A digital in-cab system such as DAS addresses the chain directly. It delivers restriction information to the cab continuously, automatically, and ahead of the point where it matters.

What DAS does, and how it works

Zelra’s DAS is an in-cab decision support tool. It does not control the train, and it does not replace the driver.

It provides the driver with a continuously updated picture of how to operate the planned service, with speed restriction information built into that picture from the start of each journey. The driver always retains full authority over the train.

The advisory engine uses a physics-based algorithm to calculate an optimal speed profile. It draws on route topography, the planned timetable, train performance characteristics, and live GPS positioning. This runs continuously throughout the journey and updates in real time as conditions change. The result is a single, clear advisory output on an in-cab tablet or screen.

That output resolves the competing demands of timetable, speed limits, gradient, and energy management into one reference the driver can act on.

From a speed management perspective, the critical feature is anticipatory guidance. Upcoming speed restrictions are shown in advance, with the distance to onset and the extent of the restriction. The system calculates a smooth approach profile and shows a clear recovery point back to line speed.

The driver is not reacting to a restriction at the point of encounter. They are managing the approach from the moment it appears on the display, well before the train reaches it. The interface is designed for minimal cognitive load. The current advisory state, the target speed, the next restriction, and the distance to key events are presented in a stable, glanceable layout.

The driver can read what they need without diverting attention from the line ahead. Permanent, temporary, emergency, and blanket speed restrictions are all handled within the same framework.

One platform, two modes

Zelra’s DAS is delivered as a single platform that operates in two modes. Connected operation is the destination, because that is where the fullest safety and performance benefits are realised. Standalone operation is the first step on the way to this destination.

S-DAS, or Standalone DAS, delivers the full advisory capability using timetable, route, and train performance data configured in advance. It requires no Traffic Management System, no live data feed, and no external integration. An operator can deploy S-DAS across a fleet immediately, giving drivers forward-looking speed restriction guidance from day one while the groundwork for connection is put in place.

C-DAS, or Connected DAS, is where the platform reaches its full potential. It adds live operational data from Traffic Management Systems, so journey profiles recalculate dynamically as actual running conditions change. In the UK, Zelra’s C-DAS integration uses standards-based interfaces, including LINX and RIS-0711-CCS, connecting to a common layer rather than using bespoke connections to individual networks.

This is the difference that matters. S-DAS advises according to a fixed plan, while C-DAS considers the live state of the network.

When the timetable slips, a restriction is imposed, or conflicts arise, connected guidance stays accurate to the real situation the driver is in. That is why the benefit multiplies with connection, and why the centre of the industry now treats connected operation as the objective.

Why architecture matters as much as intent

Operators are increasingly familiar with the case for digital in-cab guidance. The more consequential question is which architecture delivers it reliably, and which creates new dependencies in the process.

The critical point is this. C-DAS is the objective, and the route to it is incremental rather than disruptive.

The transition from S-DAS to C-DAS does not require a platform change, driver retraining, or disruption to established workflows. The driver interface is identical in both modes, so C-DAS activates as an extension of the deployed S-DAS, route by route, as integration capability becomes available.

Operators do not have to choose between acting now and reaching the connected destination. They start with S-DAS to gain immediate value, then progress to C-DAS to realise the full benefit. The stepping stone and the goal are part of one continuous path.

This connects directly to the RSSB Train Protection Strategy published in November 2025. That strategy frames the years before comprehensive ETCS fitment as an interim period in which residual overspeed and Signal Passed at Danger risk still needs managing.

A platform that delivers proven advisory guidance today, and extends to connected operation without re-platforming, matches the shape of that interim period. It provides value now while remaining ready to enable a more connected railway.

In service across the UK

Zelra’s DAS is not a paper concept. ScotRail, Greater Anglia, and GWR each run it across mixed fleets in live service today, as do SNCF in France and KiwiRail in New Zealand. GWR has active C-DAS operating in revenue service on selected fleets, with real-time timetable updates applied during live journeys.

The information gap described in our first blog is one this system is already helping to narrow, on the routes where it is deployed. For operators who have not yet deployed, the question is not whether the technology is ready. It is whether the pace of deployment is keeping up with the pace of the problem.

That question does not have a purely technical answer. It depends on governance, data sharing, and the interface between infrastructure managers and train operators. We look at that in our final blog.

You can read it here, return to the first blog in this series, or get in touch with our team to start the conversation.