The original idea for an automated interlocking test tool came from a realisation that Hitachi’s train movement simulator (TREsim) designed for signaller training, could also be used to test cross-boundary controls between adjacent interlockings. This is possible because the simulator can compile and run real interlocking data, including cross-boundary data.
The simulator already had facilities for monitoring the interlocking outputs and for setting inputs to particular states. This turned out to be a ready-made test harness. Developers then realised that tests could be automated using generic test scripts, with the parameters being defined for each specific test. By automatically reading the track layout from the simulator, it was possible to create a database containing all routes, listing the tracks and points in order through the post-to-post part of the route (or movement authority). From this foundation an automated interlocking testing tool was developed.
In the UK, there have been instances of potentially dangerous situations which have been disseminated within the industry, using initiatives such as Network Rail’s ‘Share with Pain’ / ‘Shared Learning’. This is perhaps most relevant to the UK due to the unique and often complex layouts.
The main problem that this tool is trying to solve is to ensure that the interlocking is safe (at locking level). Other tools are available to test new interlockings against requirements, in accordance with BS EN 50128.
Where does it fit into the Project Lifecycle?
The short answer is anywhere between draft initial design and decommissioning. There is a clear advantage to using the tool during design as it can cut down on test logs and re-work. Note that it is practical to provide full regression testing on “last minute” modifications, something that is often not possible manually due to timescales.
This gives re-assurance for testers as currently there is usually only time to manually test the areas believed to be affected. It is also practicable to retrospectively test previously commissioned interlockings if there are grounds for concern, for example after an alleged incident.
For an interlocking supplier we have found that performing at least some automated testing early in the design process produces the most benefit in terms of reducing errors and rework, which helps justify the additional cost to a project for something which is outside of the traditional process.
Conclusions
Applying the tool during the design phase helps create a better-quality design, which obviously reduces the effort involved in checking and testing re-work cycles. Feedback suggests that Principles Testers appreciate the re-assurance of the tool running in the background. Particularly when changes are made close to the commissioning, as it is possible to re-run all tests (rather than just the areas identified).
Finding faults and reporting them is quite practical. To be able to state categorically that no faults of a particular type exist. The tool is able to create a good picture of “features” within the interlocking that can be quite re-assuring. These features are due to peculiarities of the specific interlocking and so the tool is quite right to identify them as inconsistent with first principles and often the project’s human test team has raised the same issues.
It is difficult to argue against using automated tools that can find faults that have previously slipped through manual testing and into service. Hitachi has more than 70% of the UK rail network simulated and has tested the data for the areas highlighted in the Network Rail ‘share with pain’ reports. In all cases, the test was able to identify the fault.
For further information contact info@hitachi-infocon.com
0113 2082620
info@railbusinessdaily.com
15 Mariner Court, Wakefield WF4 3FL
