Member: Vector Informatik GmbH
Featured Standard: ASAM OSI®
The approach for Simulation-based testing of assisted and automated driving (ADAS/AD) functions does not differ substantially from the one taken for other control functions: The system under test needs to be separated and embedded in a plausible Simulation of the remaining system. While most control functions can be interfaced on a signal-based approach, ADAS/AD functions typically require input from environment sensors – often in form of object lists. Although their content is widely comparable across different implementations, the structure of the complex data and the interpretation details differ significantly. This hampers the interfacing of Simulation tools to ADAS/AD functions and the exchange of object lists between different tools alike, because custom mappings are not only tedious to provide, but also error prone. ASAM OSI can help to overcome these hurdles, leading to an easier, more reliable and re-usable interfacing between different tools and with the system under test.
The ASAM standards do not only facilitate shaping a seamless toolchain from our own tools. They also help us to pursue our goal of delivering open tools that can be integrated easily into our customers’ development environments and workflows.
Dr. Stefan Krauß, Managing Director of Vector Informatik
Functions are typically developed and tested in different stages:
It is desirable to design tests only once and re-use them across these development stages. Therefore, the testing tool must allow flexible interfacing with the system under test independent of the currently available execution platform. CANoe with vTESTstudio are Vector’s tools for test design and test execution from MIL to HIL. The open interfaces allow the integration of ECU software in all development phases:
The remaining bus Simulation reflects the network communication realistically and enables the integration of the system under test. Using this interface for mere Stimulation of the system under test is often not sufficient, especially in the case of complex ADAS/AD functions that influence the driving behavior of the vehicle. Physical models for the vehicle and its environment are therefore needed to conduct closed-loop system tests in which the actuator commands are fed into the Simulation, which in return responds with realistic sensor feedback. Vector DYNA4 provides such models for virtual test drives including the driving dynamics of the vehicle under test, its environment sensors, and the static and dynamic environment. The seamless integration of the domain-specific tools CANoe and DYNA4 with the help of ASAM OSI will be explained in more detail in the following section.
While the exchange of basic actor and sensor signals between CANoe and DYNA4 is easy to accomplish with system variables, the handling of object lists from ADAS sensors proves complicated. The lack of an object model on the CANoe side made the representation of objects difficult as the user had to Map object information to the classical signal-based architecture. An internal object representation is therefore necessary. Instead of coming up with a proprietary definition, Vector decided to use ASAM OSI as a basis for CANoe’s object model. Object information from various sources can now be used to fill this object model with data. In this way, analysis features such as the visualization of objects, are enabled and tests can be re-used easily. These benefits are independent of the source of the object-lists and its support of ASAM OSI. Naturally, if the source does support the Standard, the interfacing becomes even easier. This holds true not only for the system under test, but also for coupled tools like DYNA4. Consequently, DYNA4’s traffic and object-based sensor models have been extended to provide ASAM OSI-compliant information. Prior to this development, feeding object list information from DYNA4 into CANoe required the unraveling of DYNA4’s proprietary object list structure and the re-packaging into structured variables for use in CANoe. This is now at your fingertips by simply transmitting the ASAM OSI stream from DYNA4 to CANoe. Figure 1 depicts the enhanced coupling of CANoe and DYNA4.
In an exemplary SIL setup (see Figure 2), the DYNA4 sensor model provides an ASAM OSI stream containing detected objects such as vehicles and pedestrians. This stream is received and managed in CANoe and is the basis for stimulating the system under test, in this example a C-coded autonomous emergency braking (AEB) function. Based on the object list, various AEB function tests can be executed and additionally automated in CANoe. Possible actuations of the AEB are fed back to the DYNA4 vehicle model via system variables, ultimately resulting in a closed-loop system test.
Further developments regarding the ASAM OSI support are underway for future releases. To name a few: DYNA4 will provide detected road features and less pre-processed sensor data like camera pictures or lidar point clouds. CANoe’s Scene Window will be extended to support the display of a wider range of object types. And above all, an easy-to-use API specifically for ADAS tests in CANoe is planned. This will allow to query the underlying ASAM OSI object model for the definition of tests, e.g. with CANoe’s script language CAPL or C# test nodes. This will be useful, for example, to trigger a desired action in case a moving object lies within a certain user-defined distance.
The integration of ASAM OSI into CANoe and DYNA4 contributes to the main goals of the Standard - an increase of modularity and integrability of Simulation components as well as a streamlined compatibility between automated driving functions and Simulation frameworks. More specifically, the ASAM OSI-based object representation does not only facilitate the interfacing between CANoe and the system under test. The user also saves a lot of time due to the re-usability of tests and analysis routines. These benefits persist, even if the system under test does not directly support ASAM OSI. In the case of DYNA4, the ASAM OSI integration helps to avoid mapping issues thus ensuring high quality, for example, when exchanging DYNA4’s integrated sensor models with custom sensor models. In this application story, the benefits for the individual tools have been combined, leading to an increased quality and time saving when using them jointly. As a result, more time and effort can be spent on the actual task – the development and comprehensive test of complex functions for assisted and automated driving.