The testing and setup phase of a Zelra Driver Advisory System (DAS) deployment can be perceived as the least visible aspect of implementation. The contract is signed, the technical scope has been agreed, and then a gap exists prior to the system go-live. For rail operators considering a new procurement, it is valuable to know what to expect from DAS testing during this important period.
Before Zelra’s DAS solution can go live on your fleet it needs to go through a rigorous testing procedure. This process happens in stages, with each building upon the last.
Each stage narrows the gap between a system that works in principle and one that’s proven to be ready for day-to-day service.
Safety comes first at every stage, so briefing and induction takes place before testing begins. Dynamic testing typically runs over multiple days and brings together several stakeholders:
The test follows an agreed specification that is developed collaboratively between Zelra, the operator, and the original equipment manufacturer (OEM) over the preceding months. This includes selecting representative routes that allow the system’s capability to be fully demonstrated.
Testing can take place on a dedicated test train or on a live passenger service. Each of these options has trade-offs that are important to understand.
Using a live passenger service means the operator doesn’t need to withdraw an additional train from service to use as the dedicated test train. The trade-off is less control, since the test must fit around the live timetable and any network disruption that might occur and without routing support from route control and signalling.
A dedicated test train offers the opportunity to fully demonstrate the capabilities of DAS in a more controlled environment, although it can still be subject to the wider network’s activity and potential delays.
Live testing surfaces problems that can’t always be resolved on the spot. When that happens, test data is used by Zelra’s engineers to diagnose the cause in collaboration with the operator and manufacturer.
Issue resolution begins with identifying where it sits. If it is within the DAS system itself, Zelra resolves it directly, and similarly the manufacturer takes the lead on issues within their own software.
Where a problem arises at the interface between two systems, such as a mismatch that only appears at the point when the systems are integrated, resolution relies on close collaboration between the technical teams using their experience of how the two systems interact in practice.
Importantly, this is also why the working relationship between those teams matters as much as the technology itself. Data preparation before a test often spans months, and the teams are already familiar with each other’s systems and processes by the time testing begins.
Once every criterion in the DAS test specification has passed, Zelra’s team compiles a comprehensive report. Any outstanding issues are tracked and resolved at this stage. A fix within the DAS system can often be turned around quickly by Zelra’s engineers, while one that touches the OEM’s own onboard systems typically must go through their software release process before it can be deployed.
In some cases, a second dynamic test follows to confirm that the changes have taken effect. This also serves as a practical demonstration for the operator and OEM to show the system working as intended before wider rollout.
Where a particular train type runs with DAS for the first time, a first-in-class test is required with driver union representatives who assess the system from a driver safety perspective before it can be rolled out more broadly. The operator might also choose to perform additional validation runs to confirm their route data is free from errors.
When all testing is concluded, the report goes back to the operator who commissions the system across the fleet in batches sized to suit their operational needs.
The standalone mode of DAS is not the end point of a DAS deployment. Rather, it establishes the operational baseline that Zelra’s Connected DAS (C-DAS) is built upon. Testing C-DAS adds a further layer of validation, because the system receives live operational data from a Traffic Management System (TMS) during the journey.
This work starts at mobilisation, well before the first test run. Zelra must confirm:
The infrastructure manager and TMS provider are accountable for delivering the feeds, while Zelra consumes and validates them.
On the UK rail network C-DAS uses LINX, Network Rail’s standard integration layer connecting TMS and DAS. Data ingestion is validated in shadow mode, alongside live TMS outputs, before any connected advice reaches a driver. Each supported update category is then tested in turn, covering schedule updates, stopping pattern modifications, route diversions, cancellations, and reinstatements.
Testing of degraded operation follows a similar pattern, ensuring the system moves into C-DAS where validated feeds are available and reverts to standalone mode where they are not. This process occurs without requiring any driver action or a system restart.
Because C-DAS is activated route by route as TMS capability becomes available, our connected testing is a repeating activity rather than a single milestone.
The structure of Zelra’s testing and setup phase exists to ensure our DAS solution works reliably in the exact operational conditions it will run in every day, before it is rolled out at scale. Every operator’s combination of routes, rolling stock, and existing systems is unique, and that shapes how the testing phase with Zelra will be planned and executed.
Want to discuss DAS and C-DAS deployment requirements in more detail? Get in touch with our team of experts today.
Blogs
Freight Rail, Passenger Rail
Driving Advice System (DAS)
Australia/New Zealand, European Union, United Kingdom
6 minutes