01

ser scanners (LIDAR). The centerpiece of the ADAS sys-tems is the fusion controller, which takes all sensor data and computes a current environment model in real-time, which is then used to control all drive, steering and braking systems. Various technical solutions are used to log the sensor, ECU and communications data: Such highly-equipped vehicles combine automotive-compatible RAID storage devices de-signed for performance and continuous operation, a high-performance PC with automatic power manage-ment, raw data measuring equipment for video, radar and fusion controllers, additional context cameras, inertial measurement systems for precise vehicle positioning as well as numerous bus interfaces for Automotive Ethernet, CAN, CAN FD, FlexRay, etc.Generally, every sensor manufacturer offers a dedicated logging or debugging solution for their sensors. However, when numerous sensors from different manufacturers are combined in the vehicle (Figure 1), a universal solution is needed that supports all the necessary sensors and stores

The effort involved in testing and validating ADAS systems is enormous, and it continues to grow with increasing de-grees of automation. Automated vehicles must be able to handle any conceivable situation. Up to a million real test kilometers may be driven with a test fleet, depending on the purpose of the vehicles, which corresponds to a logging duration of more than 20,000 hours. Once it is recorded, the logged data can be used any number of times to test new software builds. In this process, high-end servers with thousands of computing cores are used to reduce the time required for the re-simulation, e.g., from 20,000 hours of test driving to three weeks (500 hours).

Autonomous Driving Is Inconceivable Without Realistic Tests

The vehicles that are used to log data are equipped with the sensors needed for their specific ADAS levels and nu-merous measuring technology components. The primary types of sensors are video cameras, radar sensors and la-

Overcoming Logging Challenges in ADAS Development ProjectsScalability and Flexibility Are Key Factors in Logging Sensor DataThe more tasks that driver assistance systems assume along the way to autonomous driving, the greater the number of sensors in the vehicle from different suppliers. Real road traffic provides the ideal reference data for testing – in endless variety. For this purpose, OEMs and system suppliers are sending test vehicles equipped with high-end data loggers onto the streets to collect data. That data is then used to precisely ”re-simulate“ certain traffic situations in the laboratory to test new or refined ADAS sensing and control logic. Instead of implementing numerous sensor-specific logging sys-tems, what is required are scalable approaches and strategies.

02

Technical Article / June 2019

the data, time-synchronously, in a uniform, standardized format like ASAM-MDF4.All of the measuring equipment must be designed to be mechanically robust and suitable for the automotive envi-ronment, and they must exhibit a high level of reliability against failure. Other requirements are: Temperature range suitable for automotive applications, low power consump-tion and reliable power management.

Scalable User Interface for Broad Range of User Skills

Ideally, the logging software should offer an adaptable user interface for visualizing, operating and monitoring. This interface should lend itself to fulfilling the various use profiles: from a simple operating panel on smartphones to complex visualizations for experts during the test drive, and for post-test analysis of the measured data. The recordings are labeled to enable better use of the logged data in later work processes (Figure 2). Labeling is performed either by a passenger during the drive or after the logging drive while viewing the measured data. Various display windows are needed to obtain meaningful representations of the sensor and fusion data. These in-clude status, signal and trace windows, object representa-tions from a bird’s eye view, video with object overlay, GPS map display and 3D Scene window (Figure 3). Most of the visualization requirements can easily be configured by using a graphic editor without programming effort, and complex representations can also be implemented by programming.

30 Terabytes of Logging Data per Day

In the vehicle, numerous measurement modules must be connected to the logger via 1 Gbit/s or 10 Gbit/s Ethernet ports. The total amount of data to be saved in a Level 2 set-up at 200 MByte/s is 6 TByte for one work day, and in a Level 3 setup at 1 GByte/s it is 30 TByte per work day. More than 100 TByte of data is acquired over 8 hours in Level 4 and Level 5 logging systems. The logged data volumes cannot be transferred via WLAN or mobile radio interfaces, so a means must be provided for removing the memory unit from the vehicle in a simple way. There are two approaches to transferring data to the com-puting center: In the case of smaller amounts of data, it is relatively cost effective to transfer the data to several HDDs and then ship them to the computing center. In the case of larger data volumes, on the other hand, SSD RAIDS are sent directly to the computing center. The computing center has ingestion stations that are adapted to the specific memory system and automatically transfer the data to data servers with petabyte capacities.

Demand for Implementations of Measuring Equipment That Can Handle Many Different Sensors

The data types that need to be logged are fundamentally determined by whether or not the sensor is an intelligent sensor. This applies equally to radar and video sensors. In the case of a simple sensor, the raw data might be trans-

Logger 3

Logger 4

Logger 5Logger 2

Logger 1FrontRadar

CornerRadar

FusionController

SideLIDAR

FrontCamera

ContextCamera

Figure 1: Example of an ADAS Level 3 setup with sensors from five different suppliers and five logging systems

03

Technical Article / June 2019

heavy CPU loading of the test computer, and therefore it is ideal to implement them in the hardware of the video mea-suring instrument. One widely used video image processor is the EyeQ chip from Mobileye. It transfers several MByte/s of debug data over the “TAPI protocol” and Ethernet. The TAPI protocol is advantageous for online evaluation, be-cause the developer immediately determines whether the supplied data satisfy the desired quality standard.Up to 10 context cameras are used in a vehicle to visually acquire or monitor the driving situation. Each camera gen-erates approx. 60 MByte/s of data, but this data volume can be reduced by up to a factor of 50, using a lossy H.264 video compressor. So this data rate is weighted less as an issue in logging.

Special Interface Support for Radar Sensors and Fusion Controllers

The raw data rates of today’s radar sensors range from 20 to 80 MByte/s, and this may multiply by a factor of 5 to 10 in upcoming generations of radar with 4D imaging. In addi-tion, up to 40 MByte/s of debug data can occur, which con-tains FFT, detection and tracking results. Along with the raw data interface, each radar chip generally also has an Aurora data trace interface. It can be used to extract the data from the radar processor at a high rate without inter-ference. The Aurora interface offers the option of routing every change in the RAM of a multicore microcontroller at speeds of up to 20 Gbit/s to a measuring instrument, which then continually generates a RAM image without the mi-crocontroller incurring any load. Essentially, it is a challenge to integrate the necessary measuring instrument into ra-dar sensors, because radar sensors are very small, and ide-ally the measuring instrument would be installed with in-

ferred to the fusion controller over broadband video inter-faces such as FPD link or GMSL. Here, the sensor measure-ment request consists exclusively of the logging of raw data. An intelligent sensor, on the other hand, processes the raw data and delivers object lists to a fusion controller via bus interfaces like CAN FD or Automotive Ethernet. However, these object lists by themselves are insufficient for an analysis or re-simulation. In addition to the raw data, internal microcontroller data must also be acquired.Video sensors generally attain the highest raw data rates, e.g., 100 MByte/s for a 1.7 million pixel camera and 500 MByte/s for an 8 million pixel camera. Since image process-ing algorithms require lossless compression, the raw data rate can only be reduced by around 40% using lossless vid-eo compressors. However, video compressors generate

Figure 2: Labeling of traffic situations for accelerated mea-surement data analysis can take place on a panel of the CANape measurement and calibration software, for example.

Figure 3: LIDAR point clouds representation and overlay of fusion results in the Scene window of CANape

04

Technical Article / June 2019

What is known as the DHPR (Distributed High Perfor-mance Recorder) concept from Vector has proven useful here. High-performance recorders that have been adapted to the specific sensors are linked via a plug-in interface. A DHPR receives the sensor data and saves it in a highly effi-cient and time-synchronous way. The CANape measure-ment and calibration software tool is used to control the DHPRs (start, stop, trigger) and to perform time synchro-nization. In addition, DHPR signals or objects can be ex-tracted from the sensor data, and they can be routed to the CANape central software for use in trigger conditions and in complex visualizations. Since CANape communi-cates with the DHPRs over IP, it is easy to interconnect mul-tiple computers to form a logging cluster which results in a fully scalable solution.With the entry of SOTA (Software Over The Air) into future vehicle architectures, and the general trend of opening up vehicles to the Internet and cloud services, data access is safeguarded by security certificates. This must also be con-sidered when integrating measurement technology.

Conclusions and Outlook

To meet the diverse and complex requirements for data logging of ADAS sensors, a universal and well-tuned solu-tion is necessary. Such a solution is available from Vector. To implement measurement and logger software with cer-tificate support, CANape is used along with individual sen-sor recorders with the help of DHPRs. ECU interfaces are

stallation space neutrality. In addition, the position of the radar must not be changed, and the energy input should be as low as possible. Due to its usual mounting position in the engine compartment, the measuring instrument must also be suitable for the temperature range and the harsh envi-ronment.Fusion controllers often consist of a microcontroller for safety-critical ASIL D applications and one or more micro-processors for high-performance computations. Typically, the controller has the previously described Aurora measur-ing instrument interface. Along with the Ethernet inter-face, the processor’s PCIe interface can also be used for very high data rates. To achieve a compact design of the measuring instrument, Aurora and PCIe data are acquired over a shared hardware device.

Scalable Test Equipment Interprets Manufacturer- Specific Protocols

Other sensors such as LIDAR, ultrasonic and inertial mea-surement sensors typically provide their raw data and de-bug data over bus interfaces via Ethernet and object lists. In many cases, sensor manufacturers use dedicated proto-cols for data transmission. Therefore, simply saving such data in the logger is inadequate. The logger must under-stand the protocol or at least parts of it. Consequently, it is necessary to adapt the logger software to the sensors. Since sensor development is in a continual state of evolu-tion, it is often impossible to coordinate integration of the sensor protocols with release cycles of the logger software.

Figure 4: Compact VX1161 measurement and calibration hardware for the ECU array with radar and video sensors, fusion controller and bus logging applications

05

Technical Article / June 2019

available with the scalable VX1000 hardware – from indi-vidual base modules to the compact VX1161 Multi Base modules for measuring and calibrating multiple ECUs in parallel or in a network. There are also network interfaces and Ethernet switches, logging computers based on BRICK CORE COM with copying stations for quick read-out of the logged data, and finally logger cloud solutions for configu-ration and for analyzing the measured data with vMDM. It is important to keep integration effort low here. This can be achieved with an individually customized service package from Vector.Based on extensive feedback from customers, Vector con-tinues to develop its current ADAS logging solution. Al-though more than 50 different sensors have already been integrated, more sensors will follow based on the projected schedules of OEMs and system suppliers. The modular VX1161 multi-measurement system, which will be available in summer 2019, combines measuring equipment for all sensor types within a single housing (Figure 4). This allows ADAS developers to significantly reduce the number of sys-tems and wiring effort while simultaneously accelerating the setup of measurement technology in the vehicle. The number of Automotive Ethernet interfaces and the necessary bandwidths will continue to increase in the fu-ture. With its 12 ports for 100/1000Base-T1, the VN5240 network interface meets this need, since the architecture is already designed for bandwidths greater than 1000Base-T1. The VX1161 and the VN5240 each get 2 x 10 Gbit/s Ethernet ports for cascading or for high-performance interfacing to the logger.

Author Alfred Kless (graduate engineer) has been working at Vector In-formatik in Stuttgart since 2004 as Business Development Man-ager for the “Measurement & Calibration” product line.

Translation of a German publication in magazine Hanser Automotive issue 6/2019

Image rights: Vector Informatik GmbH

Links Website Vector: www.vector.comProduct information CANape: www.vector.com/canapeProduct information VX1000: www.vector.com/vx1000General information Vector’s ADAS solution:www.vector.com/adas