01

Cooperative information sharing between vehicles (V2V = Vehicle to Vehicle) and with local traffic infrastruc-ture (V2I = Vehicle to Infrastructure) is one of the most im-portant factors in advancing future mobility. This develop-ment will benefit existing driver assistance systems that are already on the market by improving performance and expanding their functional scope.

Limitations of Today’s Driver Assistance SystemsWhen driving on a road with heavy traffic, if a car breaks down ahead – but is hidden by a curve and is very difficult to see – there is a risk that road users who are following will not recognize the situation until it is too late or will not de-tect it at all, resulting in a collision. Even vehicles with ad-vanced radar-based ADAS (Advanced Driving Assistance Systems) reach their limits in such situations, because they cannot access any information about traffic events beyond their range of vision. However, vehicles equipped with V2X are able to inform all traffic users in the vicinity, via radio messages, so that they can react in a timely manner.

V2X can also overcome other limitations of current ADAS components. Today, road signs and traffic light phases can already be detected with cameras, for example. However, detection may be limited by fog or heavy precipitation. Fur-thermore, today’s driver assistance systems can only react to situations. They cannot “predict” when a traffic light will change, for instance. Radio-based V2X systems, on the oth-er hand, offer predictive support. They enable the assis-tance systems to “see” around corners and through build-ings, so to speak, and they know much sooner whether they should react, and if so when. Nonetheless, this additional information from the V2X “sensor” increases the complexi-ty of a driver assistance system and therefore testing ef-fort. The sections that follow explain how test tools can help a test engineer in testing V2X-based driver assistance systems efficiently and reproducibly, and they explain new added requirements for test tools.

Testing V2X-Based Driver Assistance Systems

The development and testing of V2X applications poses entirely new challenges to automotive OEMs and suppliers, be-cause test procedures not only need to address the vehicle’s own electrical/electronic system, but other participants in the V2X network as well. Appropriate tools allow test engineers to implement testing and validation of complex V2X scenarios effectively, as explained in this article.

02

Testing V2X-Based Driver Assistance Systems / November 2018

To maintain an overview of such complex driving scenarios, it is helpful to visualize the position, driving direction and status of each object on a map. Then development and test engineers can see at a glance whether the interrelation-ships are correct, e.g. the distances between vehicles, and whether the position parameters in the V2X message have been set correctly. It is also possible to visualize the time point at which event-specific messages were sent by the ECU. The same applies to V2X messages arriving from in-frastructure equipment such as a traffic light unit. Without graphic representation, it is very difficult to understand the layout of an intersection or the signal status of specific traffic lights at the moment a vehicle reaches the intersec-tion (Figure 1).

Security SupportValid V2X communication is only achieved when the V2X messages are accepted by all ECUs participating in the communication. This is the case if V2X messages are signed based on the same Public Key Infrastructure (PKI). Control units reject V2X messages that do not have this valid signa-ture, and they do not route them to the application layer. This prevents an unauthorized sender such as a “virtual stone thrower” from disrupting the assistance systems with message transmissions.To stimulate ECUs, V2X messages from the test tool must be signed based on the certificates of the PKI. The test tool must therefore be able to handle certificates, support the

Handling V2X Messages and Their ContentsFirst generation V2X ECUs contain a transmit and receive unit, the V2X communication stack and V2X-based driver assistance functions. To test these functionalities in black box tests over the ECU’s externally accessible interfaces, a test tool must be able to transmit and receive V2X messag-es. This requires that the test system have a measurement interface to the physical medium to enable easy configura-tion of the communications behavior and the display of physical parameters such as the Tx/Rx performance in the test tool. In addition, the communications protocols of the higher layers must be supported and interpreted in a clear and understandable way. Another requirement of test tools is that they must be able to interpret application-spe-cific messages which transport the actual relevant infor-mation such as vehicle position and sensor information.

Positioning – How the Tester Gains a Comprehensive PerspectiveA closer look at the mode of operation of driver assistance systems reveals that an important role is played by the geographic positioning of individual traffic users in relation to one another. For instance, a brake assistant is only acti-vated when the distance to a vehicle ahead and its braking deceleration lie within a range defined as critical. Functions in the ECU compute the distances between vehicles at spe-cific time points, whether they are driving in the same or opposing directions and whether there is a risk of collision.

Figure 1: Visualization in CANoe .Car2x of vehicles, events and intersection information of a V2X-capable traffic light unit in Ludwigsburg.

03

Testing V2X-Based Driver Assistance Systems / November 2018

mapped to an environment model. This environment model represents an overall picture of the environment and is the data foundation for safety functions. Data from the sensors themselves is supplied over Ether-net, CAN (FD) and FlexRay networks. When V2X technolo-gy is used, this adds another source of supplemental infor-mation about the environment. This data is also incorpo-rated into the sensor fusion algorithms and is then passed to the applications. A V2X test tool must therefore be able to handle a wide variety of data from different networks. Stimulation of ADAS functions also requires the ability to generate, time synchronously, the entire data traffic for all networks used by the ADAS ECU. Another challenge for V2X test systems is that the time stamps of the data received by the measurement interface are synchronized for all networks so that the various data can be evaluated in relation to one another. This is especial-ly important when analyzing the positions of objects de-tected by the various sensors at a defined time point and having the fusion algorithm compute location results based on them.

Creating and Executing Application TestsA big challenge in testing V2X-based applications is gener-ating suitable V2X environments which provide reproduc-ible scenarios and test parameters. To test safety functions such as the Traffic Jam Ahead Warning, Slow Vehicle

associated cryptographic algorithms and generate the rel-evant security header in the V2X package. Since the stan-dard provides for certificate switching, the test tool should also offer the option of switching between valid as well as invalid certificates during the application test. This also makes it possible to test whether invalid messages which have been received by the ECU are actually rejected. Test tools with the ability to generate certificates have an addi-tional advantage. These certificates may be used during the test phase; in later production vehicles, V2X messages signed using these certificates would be ignored based on their test root. It is also helpful to manage and display the root certificate as well as intermediate and pseudonym certificates (au-thorization tickets). The related security algorithms for ver-ification of the certificates permits immediate checking of incoming messages for a valid signature and, if necessary, recording of the results in a test report.

V2X – An Additional Data Source for Driver Assistance SystemsToday’s driver assistance systems compute a map of the environment (environment model) based on data from cameras and from radar and lidar sensors. This data mate-rial serves as the foundation for what are known as sensor fusion algorithms. This means that the objects detected by the individual sensors are interrelated, weighted and finally

Figure 2: Creating and executing V2X-based application tests with CANoe .Car2x and the VN4610 V2X test interface.

04

Testing V2X-Based Driver Assistance Systems / November 2018

Warning (slow vehicle ahead) or Emergency Electronic Brake Light (brake warning), V2X communication must be generated which stimulates the application on the ECU. Important here: The generated scenario must not lack any aspects of a real driving situation. The distances between vehicles, their speeds, acceleration and deceleration rates and the contents of application messages must be very ac-curate. Very helpful at this point are tools which make it possible to interrelate vehicles and parameterize the be-havior in the scenario over time. The Car2x Scenarios Editor contained in the CANoe.Car2x test tool from the company Vector Informatik is such an editing tool, and it offers the option of creating test scenarios via a graphic user inter-face. The editor assists in creating routes which are defined by waypoints. Vehicles and stationary transmitting units may be placed on these routes, and the vehicles can be put into motion. It is also possible to configure the behavior of the vehicles, e.g. their speeds along the route and thereby their relationships to other vehicles, transmission of V2X events as a function of place and time and whether a turn signal or accelerator pedal has been activated.Afterwards, the CANoe .Car2x test tool lets users load the created test scenario, and it generates valid V2X communi-cation. This makes it possible to create and execute appli-cation tests easily and quickly (Figure 2).

ConclusionTest engineers are faced with several special challenges in analyzing, stimulating and testing a V2X-based driver as-sistance function. A good test tool supports the engineer with a relevant range of functions. It includes measure-ment hardware with physical interfaces for transmitting and receiving. The test tool must also support V2X-specific communication protocols and interpret domain-specific application messages. Without security support of the test tool, it would be impossible to stimulate the ECU under test or test its security functionality. Since internal vehicle networks influence the behavior of assistance functions, it is also necessary for the test tool to handle data from networks such as Ethernet and CAN (FD) so that they can be incorporated into the tests. Also extremely helpful to test engineers is support in creating test scenarios, because configurations of complex scenari-os are very difficult to create and maintain systematically. Support of test automation is mandatory; it ensures that the tests created initially can be extended later and that the ECU can be stimulated and tested with different pa-rameter configurations.

Jens Buttgereit, M.Sc.,is a software developer at Vector Informatik GmbH. He works in the area of test tool development for V2X communications and ADAS.

Translation of a German publication inHanser Automotive, issue 11-12/2018

Image rights: Vector Informatik GmbH

Dipl.-Ing. (FH) Thomas Löffler,is a team leader at Vector Informatik GmbH in the area of “Net-works and Distributed Systems” and is Product Manager for CANoe .Car2x.