Radar is everywhere in new vehicle designs. HD radar can now function in all weather conditions and can be used as a front-end for AI object detection, complementing other sensor channels to further improve accuracy and safety. There is huge potential for manufacturers of high-value embedded radar systems. However, it can be a challenge to realise this potential against the competition.
System-wide challenges
Automotive OEMs are not just adding more electronic features to new cars, they are also driving a unified system architecture for their product lines to manage costs, simplify software development and maintenance, and improve security and security.
Thus, more computing and intelligence are shifting to integrated regional controllers, on the one hand communicating between relatively small sensors and processors in the small area of the car and between the regional and central controllers on the other hand to manage overall decisions.
Vendors facing the automotive radar systems market must adapt their solution architecture to these changes, providing scalability between relatively simple edge function processing and broader regional controller or central controller functionality, while flexibly adapting to different OEM partition options.
An important implication is that the exchange of large data, among of edges, regions, and central computing must allow whatever the solution partitions. This raises the importance of squeezing data during transmission to manage latency and power consumption.
In addition to performance, power and cost limitations, automotive systems must be considered for service life and reliability. The entire service life of the vehicle may be 10,20 years or more, during which software and AI models may need to be upgraded to fix detected problems or meet changing regulatory requirements.
These constraints require a careful balance in radar system design between high performance/low power in hardware and flexibility in software to adapt to changes. This is not new, but radar pipelines present some unique requirements compared to vision pipelines.
Assembly line challenge
The complete radar system flow is shown in the figure below, from the transmitting antenna and the receiving antenna to the target tracking and classification. The antenna configuration can be 44 (Tx/Rx) and 4864 for HD radar. In the system pipeline after the radar front end, the fast Fourier transform (FFT) of distance information is calculated first, and then the FFT of Doppler information is calculated. This is followed by a digital beamforming phase used to manage digital flow from multiple radar antennas.
A complete radar system pipeline extends from transmit / receive antennas all the way to target tracking and classification.(Source: Ceva)
So far, the data remains to some extent, a "raw signal". The constant false alarm rate (CFAR) phase is the first step to separate the real target from the noise. The arrival angle (AoA) calculation completes the positioning of the target in the 3D space, while the Doppler velocity calculation adds a fourth dimension. Finally, the pipeline ends with target tracking (e. g. using the extended Kalman filter EKF) and object classification (usually using AI models defined by OEM).
First, the radar system must support effective parallelism at the front end to process large antenna arrays, pushing multiple image streams simultaneously through the pipeline and simultaneously providing a throughput of 25 to 50 frames per second.
The amount of data does not only depend on the number of antennas. They will feed into multiple FFT, each FFT can be very large, up to 1K windows (bin). These transformations will eventually transfer the data to a point cloud, which itself can easily reach half a byte.
Clever memory management is essential to maximize throughput. Take the two stages of distance FFT and Doppler FFT as an example. The data written to memory from the distance FFT is 1 D data, written by row. Doppler FFT requires access to this data by column, and without special support, the address jump implied by column access requires multiple burst reads for each column, thus greatly reducing the viable frame rate.
The CFAR is another challenge. CFAR has multiple algorithms, and some algorithms are easier to implement than others. The state-of-the-art algorithm today is orderly statistics CFAR (OS-CFAR), which is particularly powerful when multiple targets exist (common in automotive radar applications). Unfortunately, OS-CFAR is also the most difficult algorithm to implement, requiring statistical analysis in addition to linear analysis. Still, all truly competitive radar systems today should use OS-CFAR.
During the tracking stage, both position and speed are important. They are all three-dimensional (X, Y, Z for position, Vx, Vy, Vz speed). Some EKF algorithms abandon a dimension (usually altitude) to simplify the problem, which is called 4 D EKF. In contrast, high-quality algorithms use all six dimensions (6 DEKF). The main consideration for all EKF algorithms is how many targets it can track.
While aircraft may only need to track a few targets, high-end car radars are now capable of tracking thousands of targets. This is worth keeping in mind when considering the architecture of high-end and (slightly smaller) medium-range radar systems.
All challenges in the classification phase are centered on the AI model and are not within the scope of this radar system. These AI models will usually be run on a dedicated NPU.
Implement the challenge
An obvious question is, what platforms can best meet the needs of all of these radar systems? It must have strong signal processing capability, must meet the throughput target (25-50 fps) at low power consumption, and must also be software programmable to be adaptable over a longer service life. This requires a DSP.
However, it must also process multiple input streams simultaneously, which requires a high degree of parallelism. Some DSP architectures support parallel cores, but for many signal processing functions (such as FFT), the number of cores required may be too many, and the hardware accelerator may be more appropriate.
At the same time, the solution must be able to expand across regional automotive architectures: low-end systems for edge applications, providing data for high-end systems in regional or central applications. It should provide a common product architecture and a common software stack for each application, while simply expanding to accommodate all levels from the edge to the central controller.
