Due to limited resources, such as the availability and number of test tracks, and the high safety standards, testing under real conditions is complex, time-consuming, and costly. For these reasons, the aim is to carry out as many development, verification, and validation processes as possible in a simulated environment.

Test projects for autonomous driving are particularly complex. A large number of scenarios must be considered and tested. In order to implement this in a realistic timeframe, a rail vehicle was simulated in its operating environment in a project on Automatic Train Operation in Grade of Automation 4 (ATO-GoA-4). The simulation and the tools used for the simulation had to be qualified for testing safety-critical functions. In future, this will allow many tests to be transferred from the field to the laboratory.  

An ATO-GoA4 system in a rail vehicle takes over all the driver's actions. This includes rigging and de-rigging the traction unit, monitoring the passenger changeover, and driving. Responding to extraordinary situations such as objects on or alongside the track or critical weather conditions must also be covered.  

The main subsystems of such a system are the ATO onboard, i.e., the automation of the actual driving function (starting, accelerating, braking, stopping), the perception (PER) system, which is based on data from complex sensor systems, and the incident prevention management (IPM) system, which triggers a response based on the objects detected by the perception system. 

In order to examine what the simulation environment for testing an ATO GoA4 system could look like, a cooperation with dSPACE was set up. The first step in setting up the simulation environment was to carry out a proof of concept. The focus was on testing the new IPM subsystem. Deutsche Bahn provided a simplified IPM model for the proof of concept, which was put into operation in a closed loop with the dSPACE tool chain. For this purpose, all other necessary subsystems such as the perception system and other connected relevant onboard systems, such as brakes, drive, CCS onboard, as well as the train dynamics and the train environment must be simulated. 
 

Railway-Specific Simulation Environment

First of all, a simulation model was required that provides a representation of the train dynamics and takes into account the structure of different train formations. The aim was to implement a generic train dynamics model that initially focuses on longitudinal dynamics. Based on the ASM vehicle dynamics model from dSPACE, railway-specific model adaptations were made. The train dynamics model was parameterized with dSPACE ModelDesk. 

By importing railway-specific objects such as rails, catenary masts, and light signals, the basic road visualization was able to be replaced with a railway-like environment. For demonstration purposes, a railroad network was imported from OpenStreetMap into ModelDesk. However, since the dSPACE conversion tool is designed for importing road networks and their objects, some railway-specific elements such as rails, overhead lines, and platforms had to be added manually. Initially, MotionDesk and later AURELION were used for visualization (Figure 1). 

The next step was to integrate Deutsche Bahn's simplified IPM controller to form a closed control loop with the ASM model. The IPM controller was stimulated by a simulated perception system. To simplify matters, the object lists provided by the ASM Ground Truth sensor models were used. Based on the objects detected, the IPM controller determines whether the train must respond to the objects. The desired response, such as the triggering of warning signals or the execution of service or emergency braking, was transmitted back to the ASM train dynamics model, which executed this response. Figure 2 shows a schematic of the control loop.
 

Two Simulated Test Cases

Two use cases were created to test the suitability of the simulation environment and the dSPACE tool chain for Digital Rail Germany:

The first use case involves a situation in which a deer crosses the tracks. The deer is identified as a moving animal object using the 3D ground truth sensors and transferred to the IPM controller. IPM responds to the object in the area of the track bed by activating the signal horn as well as an optical warning signal and the emergency brake (EB). If the deer leaves the track area and is no longer detected, the train resumes regular operation. A second successfully developed use case involves a situation in which the train is approaching a level crossing where there is a car. In the simulation, the obstacle is detected, a visual warning and a horn warning as well as emergency braking are triggered so that the train comes to a halt in good time.

The two simulations provided insights into sensor positioning and object detection. The environment perception sensors create object lists with all objects in their cone-shaped observation area, which are passed on to the IPM model. However, if a safety-critical object disappeared from the observation range of the sensors, it was noticeable in the simulation that the simple IPM model always returned directly to normal operation. The objects and their relative movement are no longer taken into account by the control strategy. This shows that early simulation can help validate the system or controller design in a timely manner. In this example, both the sensor positioning and the control strategy had to be reconsidered and improved on the basis of the simulation results. As simulation makes it possible to gain this knowledge at an early stage of a development project, the costs for error correction can be kept low.
 

What’s Next? Simulation Environment for the Laboratory of Deutsche Bahn

The proof of concept shows that the dSPACE tool chain, which originates from the automotive environment, is suitable for use as a rail simulation environment for system testing in future rail projects following adaptations. As the proof of concept met the expectations, DB Netz AG and dSPACE are planning to intensify their cooperation. 

To further optimize the simulation, AURELION, the sensor simulation solution from dSPACE, was used instead of MotionDesk. This enables an even more realistic environment visualization and a physically realistic sensor simulation for camera, lidar, and radar sensors. This will be required if the perception system also becomes part of the system under test. Sensor effects such as deflection and multipath propagation with radar sensors or point cloud distributions and motion distortion effects with lidar sensors would then have to be taken into account. 
 

There are also already plans to use the simulation environment for software and hardware tests of the ATO-GoA4 system in the Deutsche Bahn laboratory. This laboratory will be used as part of the automated train project that has already been launched.

Authors: 
Dr. Dirk Spenneberg, DB Netz AG 
Niklas Kersting, dSPACE
Roa Al-Hashimi, DB Netz AG