Challenges in designing automotive radar systems

Radar is cropping up everywhere in new car designs: sensing around the car to detect hazards and feed into decision making for braking, steering, and parking and in the cabin for driver and occupancy monitoring systems. Effective under all weather conditions, now high-definition radar can front-end AI-based object detection, complementing other sensor channels to further enhance accuracy and safety.

There’s plenty of potential for builders of high value embedded radar systems. However, competitively exploiting that potential can be challenging. Here we explore some of those challenges.

Full system challenges

Automotive OEMs aren’t simply adding more electronic features to new vehicles; they are driving unified system architectures for their product lines to manage cost, simplify software development and maintenance, and enhance safety and security.

AMD-Powered Advantech AIMB-723 Industrial Motherboard Future-Proofs AOI Deployments 


Nuvoton drives the EV market with its cutting-edge battery monitoring chipset solution


Improved Power Efficiency and AI Inference in Autonomous Systems


So, more compute and intelligence are moving into consolidated zonal controllers, communicating on one side between relatively small sensor units and processors within a small zone of the car, and on the other side, between zonal controllers and a central controller, managing overall decision making.

Suppliers aiming at automotive radar system markets must track their solution architectures with these changes, providing scalability between relatively simple processing for edge functions and more extensive capability for zonal or central controllers, while being flexible to adapt to different OEM partitioning choices.

One important implication is that however a solution might be partitioned, it must allow for significant amounts of data to be exchanged between edge, zonal, and central compute. Which raises the importance of data compression during transmission to manage latency and power.

In addition to performance, power and cost constraints, automotive systems must also factor in longevity and reliability. The full lifetime of a car may be 10, 20 or more years during which time software and AI model upgrades may be required to fix detected problems or to meet changing regulatory requirements.

Those constraints dictate a careful balance in radar system design between the performance/low power of hardware and the flexibility of software to adapt to changes. Nothing new there, but radar pipelines present some unique demands when compared to vision pipelines.

Pipeline challenges

A full radar system flow is shown in the figure below, from transmit and receive antennae all the way to target tracking and classification. Antennae configurations may run from 4×4 (Tx/Rx) for low-end detection up to 48×64 for high-definition radars. In the system pipeline following the radar front-end are FFTs for computing first range information and then Doppler information. Next is a digital beamforming stage to manage digital streams from multiple radar antennae.

A complete radar system pipeline spans from transmit/receive antennae all the way to target tracking and classification. Source: Ceva

Up to this point, data is still somewhat a “raw signal”. A constant false alarm rate (CFAR) stage is the first step in separating real targets from noise. Angle of Arrival (AoA) calculations complete positioning a target in 3D space, with Doppler velocity calculation adding a 4th dimension. The pipeline rounds out with target tracking, using for example an Extended Kalman Filter (EKF), and object classification typically using an OEM-defined AI model.

OK, that’s a lot of steps, but what makes these complex? First, the radar system must support significant parallelism in the front-end to handle large antennae arrays pushing multiple image streams simultaneously through the pipeline while delivering throughput of between 25 and 50 frames per second.

Data volumes aren’t just governed by the number of antennae. These feed multiple FFTs, each of which can be quite large, up to 1K bins. Those conversions stream data ultimately to a point cloud, and the point cloud itself can easily run to half a megabyte.

Clever memory management is critical to maximizing throughput. Take the range and Doppler FFT stages. Data written to memory from the range FFT is 1-dimensional, written row-wise. The Doppler FFT needs to access this data column-wise; without special support, the address jumps implied by column accesses require many burst-reads per column, dramatically dropping feasible frame rates.

CFAR is another challenge. There are multiple algorithms for CFAR, some easier to implement than others. The state-of-the-art option today is OS-CFAR—or ordered statistics CFAR—which is especially strong when there are multiple targets (common for auto radar applications). Unfortunately, OS-CFAR is also the most difficult algorithm to implement, requiring statistics analysis in addition to linear analysis. Nevertheless, a truly competitive radar system today should be using OS-CFAR.

In the tracking stage, both location and velocity are important. Each of these is 3-dimensional (X,Y,Z for location and Vx,Vy,Vz for velocity). Some EKF algorithms drop a dimension, typically elevation, to simplify the problem; this is known as 4D EKF. In contrast, a high-quality algorithm will use all 6 dimensions (6D EKF). A major consideration for any EKF algorithm is how many targets it can track.

While aircraft may only need to track a few targets, high-end automotive radars are now able to track thousands of targets. That’s worth remembering when considering architectures for high-end and (somewhat scaled down) mid-range radar systems.

Any challenges in the classification stage are AI-model centric, so not in range of this radar system discussion. These AI models will typically run on a dedicated NPU.

Implementation challenges

An obvious question is what kind of platform will best serve all these radar system needs? It must be very strong at signal processing and must meet throughput goals (25-50 fps) at low power, while also being software programmable for adaptability over a long lifetime. That argues for a DSP.

However, it also must handle many simultaneous input streams, arguing for a high degree of parallelism. Some DSP architectures support parallel cores, but the number of cores needed may be overkill for many of the signal processing functions (FFTs for example), where hardware accelerators may be more appropriate.

At the same time, the solution must be scalable across zonal car architectures: a low-end system for edge applications, feeding a higher end system in zonal or central applications. It should provide a common product architecture for each application and common software stack, while being simply scalable to fit each level from the edge to the central controller.

Tomer Yablonka is director of cellular technology at Ceva’s mobile broadband business unit.

Related Content

Source link