Application Story

Closed-Loop System Tests for Assisted and Automated Driving

Functions are typically developed and tested in different stages:

• Model-in-the-Loop (MiL) for function design,
• Software-in-the-Loop (SiL) for testing of electronic control unit (ECU) software without real hardware or,
• Hardware-in-the-Loop (HiL) for executing the function as embedded software on an ECU.

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:

• Integration of controller models, e.g. as Simulink models or FMUs (MiL)
• Integration of C-code with the SiL Adapter Builder or entire virtual ECUs with vVIRTUALtarget (SiL)
• Integration of real ECU hardware (HiL)

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.

Object Representation with ASAM OSI for Seamless Tool Integration

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.