ADAS or Autonomous Vehicles?

Engineers and software specialists around the world are, right now, developing the next generation of radar sensors, which will increasingly enable vehicles to see and comprehend their surroundings. To be able to produce such sensors in a manner that is compatible with practical demands and also optimised for cost, maximally integrated controllers have to be used. They combine suitable interfaces for multi-channel radar signal recognition with the required storage capacity for the volume of raw data generated and ensure the availability of sufficient computer speeds for on-chip data analysis. Hence, an on-chip AD-converter digitises, processes and analyses the radar antenna signals at speeds of up to 320Mb/s. The radar echo does not leave the chip until it has been converted into an abstract form that can be forwarded without any problems - even through slow interfaces such as CAN. 

Nevertheless, as elegant and efficient as the fully integrated structure may be in the final product, it is quite a daunting task for the development teams: the already very challenging requirement of optimally programming such a complex chip is further complicated by the problem that the raw radar data never leave the chip. The chips do not have a communications interface available that would be fast enough to transfer this data stream in real time. So how can developers come up with an algorithm for the preparation of data, and most importantly verify it, if the related raw data cannot be externally analysed?

Actual test drives provide many pertinent insights for the development cycle. Testing the solution under actual conditions is the only way to verify whether the sensors do actually have the ability to recognise, classify and track all relevant objects within their recognition range. Is the hardware sensitive enough to deliver raw data that can be effectively analysed? Are the algorithms sufficiently fine-tuned to not only recognise vehicles in the proximity, but also objects located at a greater distance from them? How effective is the distinction between adjacent objects? And how significant is the impact of the weather on the results?

The test vehicles travel for several hours to make certain that they pass through a sufficient number of critical situations. While it is possible to evaluate the recognition rates of the sensors on a point-by-point basis, a test drive will not deliver any additional results. If an object is not recognised - or not properly recognised - the development team will basically have to rely on guesses as to where the error in the analysis may have occurred. What makes matters even worse is that once the algorithms have been corrected, it is not possible to reenact the same driving scenario.

A tailored solution

To ensure that the development teams can finally work with results that are as transparent as they have to be, innovative systems, such as the DP²4R data logger (direct prototyping data processor for radar systems) have to be used. From the start, this system was designed specifically to record and centrally store distributed automotive environment data with a high bandwidth and to make it available for offline processing. In conjunction with the use of up to four sensor units, the DP²4R allows the simultaneous acquisition of random data and its transfer to the central DP² controller where it is stored, and to analyse it externally upon conclusion of the drive. During this process, 320Mbit/sec can be recorded per sensor.

However, the system not only records the sensor data. It is also possible to automatically document the test drive. If needed, both, the GPS coordinates and a camera video recording of the driving situations can also be continuously stored. The benefit is that it facilitates the subsequent analysis of the data as it shows what occurred on the road.

How can such a system handle all these functions? The solution: the structural division of the DP²4R system and its seamless integration into the sensor hardware. A special, decentralised recording head (DP²4R Head Unit) is mounted on every radar sensor system. Its dimensions are compact; about 40x60mm. It comes with both an FPGA for data recording and formatting and a local RAM as an interim memory. The layout of the recording head is specifically adapted to the main printed circuit board of the radar sensor and mounted on top of it as a piggy-back solution. It connects to the high speed debug interface (e.g. Nexus/Aurora) of the central microcontroller. As a consequence, it is possible to continuously acquire the raw radar data as well as other essential information via the debug interface.

The DP² controller is the core component of the DP²4R data logger. It is responsible for the storage of the data and for the complete control of the system. The data collected is transferred to the DP² controller by the recording heads as a serial LVDS current; the connection lines may be up to 7m long. As many as four head units can be connected to one DP² controller. In other words, it is possible to simultaneously and synchronously collect the data from four radar sensors and store them in exchangeable SSD mass storage components.

Offline analysis

The data collected is archived in SSD mass storage units. However, the analyses are performed on external computers. The data transfer to these computers is possible via Ethernet (1Gb/s). Another feasible option is the good old ‘sneakernet’ the SSD mass storage units can easily be removed from the DP² controller and inserted into the external slots of computers used to perform the analyses. As a result (depending on the distance between the vehicle and the computer performing the analysis), it is possible to attain transfer rates of 2TB every 15 seconds or 1Tb/s. After that, the busy work begins: from hours of recorded material, developers now have to extract those scenarios that have to be examined in more detail. The full documentation of time stamps and camera logs of the test drives make this job easier. Based on this data, the development teams are able to supply the original simulation models with the relevant raw data and verify the sensor behaviour. This will also make it possible to tune the analysis algorithms to be more effective in the future.

An adapted software update gets the sensors ready for the subsequent tests. The DP²4R does have another ace in the hole here: if the system is used in the ‘injection mode’, it is possible to feed the originally recorded radar data back into the sensors. In a process akin to ‘virtual reality’, the sensors pass through previously experienced scenarios a second time; however, they can now demonstrate what they have learned as a result of the software update. This is a critically helpful tool for the systematic verification of the systems, especially since it enables users to build a data library of critical driving situations over time.

Thanks to its decentralised concept and performance capacity, the DP²4R data logger provides the level of transparency development teams need for efficient and targeted sensor optimisation. The only question that remains is the one we posed at the beginning: ADAS or AV? The future remains an exciting endeavour!