Closed User Group Simulation

_{(4 min read)}

Every two years at the end of September the largest railway and transportation technology trade fair takes place in Berlin: The InnoTrans. And every two years GEONATIVES pays a visit to see what is going on in the railway domain. We already saw that the railway domain is wired differently. There is still some room for synergies in order to open data silos and improve collaboration. This year, we wanted to throw a closer look into railway simulation and related data and interfaces.

First thing we realized: Only few companies were displaying simulation applications for driving simulation as opposed to simulation for Advanced Driver Assist Systems and Automated Driving (for sure, there are many hardware-in-the-loop test bench providers out there). It seems that simulation is now a common tool for driver training, not worth advertising it too much. Nevertheless, we had the chance to talk to the French company CORYS – even though you would get similar answers from companies such as SIM Factor or Zusi. CORYS is featuring various driving simulators spanning from cab replicas with motion systems over compact desk simulators to cloud-based applications for tablet and virtual reality usage. The latest update on their side is the usage of the Unreal Engine as image generator which is being utilized in various state-of-the-art simulation applications in recent years. But, we were interested more in data and interfaces and less in eye-candy visualization (which nevertheless can support the immersion).

When it comes to the main users of such simulation applications, we talk about large state-owned companies, often operating trains, stations as well as the railroad-network and energy supply themself. Nevertheless – especially for regional and freight traffic – more and more private enterprises have established competing business. All of them need some kind of driver training capacity but the training is often focused on specific railroad lines (getting combined into a local railroad network).

We already saw that converting existing geodata representing rail infrastructure can be cumbersome because of deviations in accuracy and asset representation as well as usage of different identifiers not related across different data sources. Therefore, the simulation industry is still doing manual work to build new datasets, starting with publicly available data you would get from OpenStreetMap as well as OpenRailwayMap, instead of trying to convert data from different customer formats (if available at all; sometimes the data belong to a different department or even to a different company). After that, artists add 3d environment elements and engineers include the signaling infrastructure and the job is done.

You could ask yourself if such datasets are re-used by different stakeholders because different train operators are running on the same railroad network. But, we are talking about closed customer groups and nobody sees a benefit in sharing their assets: If shared, the state-owned companies would support their private competitors and the simulation tool provider would not be able to sell one item multiple times. Therefore, proprietary data formats are used in the applications. There is also no “need” to have open interfaces to share/access data.

Interfacing is done if third-party applications and/or hardware have to be connected to the simulations. In this case the asset that will get connected will deliver the interface and the simulation software will use it – not the other way around. The application will get a new feature that you may sell to the other customers as well.

Due to the fact that the user group is limited with respect to the total number of customers there is no real competition or collaboration happening. Additionally, often the customers have large budgets available for investing into training simulation and therefore look for turnkey solutions, which replace old solutions or are the initial installation. There is no “need” of integrating the new simulation into an existing ecosystem. The simulators do not have to get connected to other driving or traffic simulations. The scope is often just a “stand-alone” use case. Due to the fact of silo responsibilities there is also little possibility to interchange data in order to support building of more sophisticated simulation environments (see above).

We see the contrary being state of the art in the automotive sector. Collaboration among stakeholders in varying combinations is daily business. A large focus lies on research and development systems that need open (standardized) interfaces since their configuration changes frequently, and devices and assets from different stakeholders have to be integrated. Also, the typical development cycle and lifespan of automotive vehicles is much shorter, thus creating a need for frequent reconfiguration of the simulation systems and a chance to pick different suppliers at each step. In summary, the ecosystem of automotive driving simulation is far larger and more diverse than in the railroad sector. Just the right basis for data exchange and standardization.

At the end there is only little stimulus to change the game in the railroad sector. Trains are still running on their tracks and accelerate slowly. Thus, we assume that at the next InnoTrans we won’t see anything disrupting in the simulation domain. But, these insights open a room for speculations about future development in the digital railway sector. Will the automotive domain act as a trendsetter where the railway domain could learn from? Are the recently pursued automotive’s data interoperability concepts interoperable with the railway ecosystem? Who will bridge the gap? The foundation of all is not hocus-pocus but logically linked spatial data and if spatial data is managed well, the superimposed application gets less sophisticated and ideally even exchangeable. This is where we are looping back to the topic of digital twins of (urban) connected environments.