ASAM and other standards make it easier for Cruden and its customers to integrate engineering tools with a DIL simulator, as Edwin de Vries, chief technology officer, explains.
Welcome to the latest article in our Tool Integration Series. In previous instalments, we’ve seen how the client’s engineering needs can be met, and development cost and time saved, by integrating a wide variety of engineering tools with a driver-in-the-loop (DIL) simulator. These might include vehicle or tyre models, traffic simulation tools or a HIL test system for ADAS development, or even biometric tools for human factors investigations.
As part of its open architecture approach, Cruden supports integration with common industry standards. Examples are the file formats overseen by ASAM that enable different tools to work together on the same set of road models. These standards include OpenDRIVE for road definition, OpenCRG to describe the geometry of a road and OpenSCENARIO for the dynamic content in driving and traffic simulators.
The ASAM OpenDRIVE standard provides a common road definition in Cruden’s driving simulators and third-party engineering tools. This is particularly important for traffic simulations such as VIRES VTD, dSPACE ASM and SUMO, which receive OpenDRIVE layers from Cruden’s own 3D environments.
To achieve this, we create an OpenDRIVE definition of the road network of the 3D virtual environment designed for highly immersive DIL simulation. This OpenDRIVE layer is the basis for customers to run in their preferred tool. They can then, for example, simulate traffic in their traffic simulation tool of choice and pass information back to the Cruden simulator about the position, direction and speed of vehicles, so that traffic can also be shown the driver at high levels of detail. By providing information on the ego-vehicle from the simulator, the traffic simulation responds directly and naturally to the driver’s manoeuvres.
A further use case lies in Cruden’s integration with MathWorks (formerly VectorZero) RoadRunner, an interactive editor to design 3D scenes for simulating and testing automated driving systems. Since RoadRunner also generates OpenDRIVE layers, it is very easy to use customer-generated RoadRunner content in a DIL simulator.
Audi and Hyundai MOBIS are among the OEMs for whom Cruden has integrated a driving simulator with the VIRES VTD traffic simulator. Meanwhile a recent installation at the Technical University of Munich integrated SUMO as a traffic engine.
Administered by ASAM since 2002, the OpenDRIVE standard is now well established and well understood, which makes the integration process even easier. ASAM’s software libraries – which implement the specifications of the standard – assist us, and our customers, in both creating and making use of OpenDRIVE layers in a DIL simulator. Using these libraries reduces the risk of different providers interpreting the standard in a different way and having inconsistencies in the co-simulation.
Elsewhere, the FMI (functional mockup interface) standard facilitates co-simulations in MATLAB Simulink environments. Like the ASAM standards, it enables simulator customers to handle much more of the tool integration process themselves, while Cruden’s engineers can be called in if needed to take care of a more complex file exchange where no standard is supported. That leads to a more cost-effective and efficient simulator implementation.
It’s worth noting that the open-interface approach that characterizes engineering tool integration extends to the simulator’s visual systems. Not only do Cruden’s graphic designers sometimes create a new 3D environment from an OpenDRIVE layer that defines the road profile, but the creation of new environments is also supported by the use the popular Unity software to asset bundles for road models.
In some instances, Cruden or its customers need to take virtual environments from third-party sources and quickly convert them into a form that will render in Unity. Helpfully, the Unity editor is also open to integrating content from many different content generation tools and 3D design programs which generate Unity Asset bundles. Once a road model is imported in the Unity editor, its asset store then makes it easy to enhance the virtual environment with gas stations, trees and other elements.
This flexibility in using different engineering tools around the driving simulator, and creating its virtual environments from different sources, provides great benefit to customers, resulting in cost and time savings in vehicle development. And if a client decides to switch to a different engineering tool or implement an additional one for certain research or development work, it can do so without having to create a new solution to link the two.
Standardisation is a fantastic enabler for integration in a driving simulator, but the absence of a standard is no reason to abandon attempts to integrate a preferred engineering tool. Switching to a different tyre model for example, simply because your regular one is harder to integrate, prioritizes the simulator over your tyre or chassis development process, which should never be the case.
For its part, Cruden has yet to encounter a tool that it could not integrate. Our approach is to make the integration work in the easiest possible way, which is why we embrace any standardization initiative. In the absence of a standard, the integration of a new tool might take a little more effort, but we will still get the job done!
For more information, please contact Dennis Marcus via firstname.lastname@example.org or on +31 20 707 4646.
If you think a colleague would be interested in receiving the articles in this series, you can sign them up to our newsletters here.
Links to subsequent articles will be added below as they are published.
View all articles in our Tool Integration series of articles: here.