The project began in summer of 2015, when the ERTMSFormalSpecs team met with the Braking Curves team of the Thales EVC development project. Thales had begun testing their braking curve calculations, but were not fully satisfied with the methods they were using.
They had designed unit tests to pinpoint testing of specific functions. This is a great method for testing specific parts of the software. But the requirements of braking curves are so vast and inter-related that it requires more than unit testing to reach a sufficient level of confidence on the software.
Thales had also developed a set of integration tests. Each test was defined as a complete scenario, created by hand, to ensure that a specific behavior is respected. The checks are defined for specific moments in the scenario, using the ERA Braking Curves tool to compute the expected values. This approach has several limitations:
- The ERA Braking Curves tool is created for version 3.3.0 of the specification. At the time, no new version had been released along with Subset-026 version 3.4.0.
- The ERA Braking Curves tool can only be used for simple cases with a single target, leaving out situations where multiple braking curves could restrict the train’s speed.
- The ERA Braking Curves tool does not allow for the verification of the displayed permitted and intervention speed.
- The precision of the ERA Braking Curves tool turned out to be insufficient if braking curves for very low deceleration values had to be calculated.
- The checks are performed at specific locations in the scenario, whereas it could be interesting to compute the expected results dynamically – at each evaluation cycle of the OBU – for instance, to determine as soon as possible the reason why a deviation occurs.
ERTMSFormalSpecs braking curves comparison tool
The idea came to use ERTMSFormalSpecs model to check Thales’ OBU results because it is maintained up-to-date with the latest version of the specifications and models completely the braking curves as described in Subset-026.
The two teams met in August of 2015 to define the objectives, the scope and the methodology of this project: we would use the logs of existing integration tests of the Thales EVC as input data for ERTMSFormalSpecs, then compare the outputs of both systems over the entire course of the scenario. For the same inputs, both system should provide similar results. This approach allows to handle the dynamic aspect of the problem, since output computations can be compared after each execution cycle, and find deviations as soon as possible.
Then came the long task of matching results between ERTMSFormalSpecs and Thales. Each time the results were incompatible, the teams had to draw from their knowledge of the specifications, and on the detailed information that ERTMSFormalSpecs provided for every calculation. It was possible to explain any results, step by step, from the speed, position and train parameters, to any of the outputs for ERTMSFormalSpecs. This allowed the teams to communicate constructively about each problem that arose and reach joint conclusions on any changes required to proceed.
One of the reasons for discrepancies was because different constraints where applicable on both systems, and some hypothesis have been taken by both development teams, which were not always compatible. We had to adapt the ERTMSFormalSpecs model needed to match some behaviors of the Thales OBU. The ERTMSFormalSpecs’ update mechanism was used to change these functions, without altering the main model, used in our other projects. These functions are related to the application of SB and EB and the traction cutoff, and the interface with the odometry.
From conception to delivery, the first version of this tailor made application was delivered to Thales in only three months. The results of these tests confirmed that both systems produced very similar results for the compared values:
- Operated Level and Mode
- Speed and Distance Monitoring Type
- Speed and Distance Supervision Status
- Brake commands and Traction Cut-Off command
- Release Speed computation.
This objective was reached, despite the fact that both systems have been developed by completely distinct teams. Software diversification has reinforced the confidence of both teams in their interpretation of the ERTMS/ETCS specifications.
Since then, the scope of the project has been expanded to compare
- The information displayed to the driver
- The supervised target (in addition to the most restrictive displayed target)
- The LRBG
This method of testing is now applied as night build tests by the Thales Braking Curves development team.