01

also the AD functions – requires a far from trivial testing and validation procedure.

Validation Methodology for AD FunctionsAccording to a number of estimates, test drives of millions or even billions of kilometers will be required for the valida-tion of AD functions – most of this in traffic on the public highway. If other aspects are also considered, such as the risk to other road users and the reproducibility of the tests, then it becomes clear that this test scope is practically un-achievable in real traffic environments using test and pro-totype vehicles. Consequently, it is necessary to move the tests into the laboratory, that is to say into a virtual envi-ronment that is suitable for the system to be tested. At the same time, it would be wrong to do away with real tests on the public highway altogether because the simulation models used in the laboratory can only provide an approxi-mation to the real world.Various steps and methodologies may be involved in trans-ferring the tests from the road to the laboratory. To inte-grate the actual ECU, and possibly also the actual sensors, in a simulated vehicle environment (hardware-in-the-loop) it is necessary to establish an electrical connection

Autonomous Driving (AD) is providing significant stimulus for innovative technologies and methods in ECU develop-ment for the automotive sector. Different types of high-performance sensors such as cameras, radar and lidar are now used in vehicles. At the same time, many of these sensors are needed in order to detect the vehicle’s environ-ment as accurately as possible and under all (weather) conditions. The data delivered by these sensors is processed in real time and, increasingly, after the fusion of the sensor data. This is achieved by means of high-performance pro-cessors and graphic chips. This type of AD ECU typically runs under a POSIX operating systems such as QNX, PikeOS or INTEGRITY OS. These platforms make it possible to use software environments from other IT domains that have not previously been used in the field of automotive ECU development. For example, it is now also possible to use frameworks for artificial intel-ligence and machine learning, such as TensorFlow or ROS (Robot Operating System), when implementing autono-mous driving functions. This complex hardware and software environment raises the question of how release processes for AD systems can be designed. Even just the software itself – and therefore

When heading at full speed into the new ADAS world, it is better if there is no risk to any of the parties involved. How do we handle the current IT paradigm change in a way that makes the testing of all the functions truly reliable? Do we need more complex or completely different tools? Or would the skillful use of existing tools be a suitable approach?

Skillful Use of the Toolbox

Combining Forces for ADAS Testing

02

Technical Article / September 2018

between the ECU and sensors and a correspondingly high-performance real-time simulation system, such as Vector’s VT System.Since the ECU software is of such significance, in particular in AD systems, the considerations set out below focuses on software testing without the ECU hardware (software-in-the-loop). This approach also makes it easy to run tests in parallel and to automate the conduct of the tests, with the result that it is also possible to perform tests at night or at the weekend.To test the ECU software in the laboratory it is necessary, on the one hand, to run the ECU software without the real hardware. On the other, it is necessary to simulate the environment of the software that is to be tested, i.e. the vehicle and its behavior, as well as the environment outside of the vehicle and the employed sensors. It is also necessary to cover other requirements, for example test automation. Specialized tools from various manufacturers are available for the individual subtasks and these encapsulate a great deal of experience and expert knowledge. Therefore it seems sensible to combine these specialized tools to form a complete test environment. When linking these tools to-gether, standardized interfaces, such as the Functional Mock-up Interface (FMI), are extremely valuable. Most im-portantly, these free the user from the need to cope with the technical details of the communications between the tools.Below, a prototypical setup is presented in which the System Under Test (SUT) is simulated in a virtual environ-ment and which indicates the possibilities and tools that are available for this. The test setup is described on the basis of various scenarios for testing an emergency braking function. Vector’s PREEvision process tool, for example, is a suitable solution for requirements and test data management. This manages the test specifications and the test results. By contrast, the actual test design, that is to say the creation of the test cases, is performed using vTESTstudio. This is used to generate so-called executable test units which are

then loaded into CANoe for execution. Alongside this run-time environment for the tests, CANoe also provides the remaining bus simulation for the target. Once the tests have been performed, the test reports are created and stored in the test data management system. This approach ensures end-to-end traceability from the requirement through to the test result (Figure 1).The SUT is an ECU in which an emergency braking function is implemented. It communicates with the sensors and ac-tuators via SOME/IP and is present under Linux as an AU-TOSAR Adaptive ECU. The overall system consists of a sen-sor gateway that communicates with the emergency brak-ing ECU via SOME/IP. This sensor gateway receives data from the speed sensor and the distance sensor. The emer-gency braking ECU also uses SOME/IP to communicate with the actuator gateway, which controls the brake and accelerator pedal (Figure 2). Both the sensor gateway and the actuator gateway are present as simulated nodes in the CANoe simulation.

Figure 2: System setup consisting of ECU emulation, sensor/actuator simu-lation and environment/scenario simu-lation

Figure 1: Tool chain for testing an ADAS system, including the con-nection to a requirements and test management system

Insert figure

03

Technical Article / September 2018

These expected values must now be translated into execut-able test steps that are to be tested under the framework conditions presented above. To do this, the overall test is subdivided into three phases. The constraint governing the first phase is that the distance to the obstacle is greater than the critical distance. In this context, the critical dis-tance means the distance at which a collision would occur if no emergency braking were performed. The test descrip-tion for this phase is: “Vehicle travels with accelerator pedal depressed 50 % and a brake pressure of 0 bar. Emergency braking is deactivated.” The second phase covers the case where the distance to the obstacle is less than the critical distance. In this case, the test vehicle should brake, with a brake pressure of 150 bar. The accelerator pedal signal is 0 %. Emergency braking is activated. In the third phase, the ob-stacle vehicle starts moving as soon as the test vehicle has braked to a stop. In this third phase – exactly as in the first phase – the test vehicle should continue to travel with an accelerator pedal setting of 50 percent and a brake pres-sure of 0 bar. Emergency braking is deactivated.

Interaction Between the ToolsThe tasks are distributed between the participating tools in such a way that the environmental simulation is provided using scenarios from TASS’s PreScan tool, while CANoe performs communication with the ECU, on the one hand, and executes the test, on the other. The simulation time is given by CANoe, which acts as the timing master. More detailed models of the vehicle environment, the vehicle and the driver are calculated in PreScan and, based consistently on this, the radar sensor for distance detection is simulated. Here, it is possible to choose the sensor models in different levels of detail – from idealized through to based on physical reality. In addition, the entire scenario is visualized in PreScan

(Figure 3). Another tool used in this configuration is vTESTstudio. This constitutes the develop-ment environment for the test design and makes it possible to develop tests in CAPL, .NET or graphically. An approach based on the Functional Mock-up Interface (FMI) is chosen for communi-cation between CANoe and PreScan. This approach encap-sulates the actual communica-tion layer that is implemented via named Windows pipes. A separate program acts as a container for the various Func-tional Mock-up Units (FMU) and as server for the named

Test Case for Emergency Braking FunctionThe ADAS test environment consists of a virtual test vehi-cle and a virtual test driver, driving on a simulated, straight test track. The driver drives for twenty seconds along the flat road without making any steering maneuvers. He drives at an initial speed of 26 m/s (~ 93 km/h); the acceler-ator pedal is depressed by 50 percent. At the start of the test drive, another vehicle is present as an obstacle outside of the test vehicle’s radar range. The vehicle which constitutes this obstacle is initially stationary and then accelerates with the accelerator pedal fully de-pressed as soon as the test vehicle first reaches the speed of 0 m/s. The “obstacle vehicle” drives in the same direction as the test vehicle.The following expected values are formulated for the tests:1. There will be no collision within 20 seconds2. Before the test vehicle comes to a stop:

> As long as the test vehicle is further away from the obstacle than the “critical” distance, the brake pres- sure signal received by the actuator gateway is 0 bar and the received accelerator pedal signal is 50 %.

> As soon as the test vehicle falls below the critical distance, the brake pressure signal becomes 150 bar and the accelerator pedal signal 0 % (emergency brak- ing functionality overrides control signal from driver).

3. After the test vehicle comes to a stop: > As long as the test vehicle is below the critical

distance to the obstacle, the brake pressure signal continues to be 150 bar and the accelerator pedal signal 0 %.

> As soon as the distance between the test vehicle and the obstacle is greater than the critical distance, the brake pressure signal is 0 bar and the accelerator pedal signal is 50 % (control signal from driver).

Figure 3: Visualization of the driving situation and environment with PreScan

04

Technical Article / September 2018

Windows pipes. Here, the individual FMUs represent PreScan experiments that can easily be switched between by load-ing the corresponding FMU (Figure 4). What makes the FMI solution so attractive is the fact that the standard feature scope of both CANoe and PreScan enables them to load FMUs and execute them in their re-spective processor spaces. The FMU container is the only component specifically designed for this project.

OutlookAs soon as the virtual testing of ADAS/AD systems be-comes necessary, the required sensor and actuator data should be available in simulated form. Because very many different types of data have to be processed in the case of such systems, an efficient, reliable coupling of the tools is required.In addition, ADAS/AD functions can be implemented distributed across multiple ECUs. From the test engineer’s perspective, this means that the software, that is to say the application, will become more the focus of attention, while the ECU, a closed-off black box, will become less visible. A Service-Oriented Architecture (SOA) will provide the communication infrastructure for the individual func-tional elements. Testing these systems will be the crucial challenge for future tools. Thanks to SOA, what in tradi-tional networks is a remaining bus simulation finally becomes a simulation of the overall residual system. Mock-ups are required for reciprocal service providers or consum-ers, support for complex data types, serialization on different (Ethernet) protocols and, ultimately, also the sim-ulation of the traditional networks.

Translation of a German publication in Elektronik autmo-tive, September 2018

Image rights Figures 1, 2, 4: Vector Informatik Figure 3: TASS International

Figure 4: : Software architecture consisting of CANoe as the platform for test execution, ECU emulation, PreScan for environment simulation, and a Named Pipe Server for switching between the individual scenarios

Dominik Skanda studied physics at Heidelberg University. Since 2016, he has been working in Vector`s Research and Development for Embedded Software department with a particular focus on ADAS-related topics.

Francisco Gonzálezcompleted a master’s degree in Embedded Systems at Stuttgart University, Germany, and works in the field of research and devel-opment for embedded software/ADAS-related topics at Vector.

Jochen Neuffer studied telecommunications technology at Esslingen University of Applied Sciences, Germany. Since 2002, he has been working at Vector as Product Management Engineer in the field of Tools for Network and Distributed Systems.

Oliver PhilippTASS International, studied mathematical engineering at Darm-stadt Technical University. Since then, he has worked in various positions in the field of vehicle, environment and sensor simula-tions and, as of 2018, has been Market Development Manager at TASS International.