Software-Defined Radar Is First Leap On SDV Path

Software-defined vehicles (SDVs) have had car company marketers in a veritable tizzy for several years, and while they generally agree on the direction, they differ on the speed and route to adoption.

For most OEMs, a wholesale change in vehicle architecture, from hood ornament to trunk-latch, is easier said than done. Legacy systems, both hardware and software, are the millstone around OEMs’ necks. And unless a tech company suddenly takes up carmaking — as Tesla did in 2003 and as China’s Xiaomi is now doing — companies that have been in the business for decades cannot make a clean, simple switch overnight to SDV architectures.

As a result, the “software-defined” vehicle concept is likely to emerge in bite sizes — one sensor, one domain, or one zonal controller at a time.

Software-defined radar is a case in point. Hardware-agnostic software-defined radars, as it turns out, are one of the key elements that traditional carmakers need in order to meet the Automatic Emergency Braking (AEB) mandate finalized last year by the U.S. Department of Transportation’s National Highway Traffic Safety Administration (NHTSA).

The new rule, FMVSS No. 127, forces automakers to feature AEB and Pedestrian AEB (P-AEB) on all passenger cars and light trucks by September 2029 for both daylight and nighttime. The rule also requires the system to apply the brakes automatically at speeds up to 90 mph when a collision with a lead vehicle is imminent, and up to 45 mph when a pedestrian is detected.

Whether the new mandate and deadline will remain under the new U.S. administration is unclear. But politics don’t alter the technical challenges facing automotive engineers tasked with meeting AEB/P-AEB safety requirements sooner or later.

The conventional solution for complying with FMVSS No. 127 is for OEMs to throw more hardware at their vehicles. Carmakers today already have myriad options for implementing NHTSA’s new rule. These range from adding new types of sensors like thermal (i.e. Teradyne Flir, Owl Autonomous Imaging), which is best for night-time vision, or devising a new generation of higher-performance imaging radar (i.e. Arbe, Uhnder, NXP Semiconductors, Texas Instruments). Another option is to deploy smarter camera-radar fusion solutions enabled by high-performing SoCs from companies like Ambarella and Mobileye.

Software-defined radars, meanwhile, add potentially lower-cost and scalable solutions to meet FMVSS No. 127. These hardware-agnostic software-defined algorithms are promising because they aren’t designed to run on a specific piece of hardware.

The challenges created by the AEB/P-AEB rule have opened opportunities for startups focused on developing software that can be layered on top of existing hardware. This includes such newcomers as Neural Propulsion Systems (NPS) of Pleasanton, Calif., and PercivAI, a spin-off of Delft University of Technology’s Intelligent Vehicles Group.

The rise of software-defined radars dovetails with “the transformation we are already seeing in the automotive industry — a shift to software-defined vehicles,” said Pierrick Boulay, senior analyst at Yole Group.

Scalability
Given that the new regulation applies to entire fleets, from low- to high-end models, software-defined radars could answer some cost concerns that nag OEMs. While high-end vehicles might be able to afford additional sensors or higher-performance sensor fusion processors, software-defined radars can target “entry to mid-tier cars” through a lower-cost implementation of FMVSS No. 127, observed Hassan Saleh, senior RF technology and market analyst at Yole Group.

One notable software-defined radar proponent is NPS, established in 2018. Heeding CEO Behrooz Rezvani’s conviction that all automakers are today focused on radars, NPS plans to deliver a hardware-agnostic software-defined radar. The rationale is that if cameras can’t discern objects in bad weather, they won’t get any better by adding horsepower to camera processing.

“You need radar. But traditional radar systems have been highly unreliable,” said Rezvani, adding that software-defined radars will offer clearer resolution, enable faster detection time, and reduce false positives.

The heart of NPS’ technology is a mathematical framework called Atomic Norm Software, which is based on work from Caltech and MIT. “It has taken us seven years to get here,” he said. “We can detect a pedestrian next to a car a tenth of a mile ahead.”

Establishing the appropriate distance for activation is critical. Radar that detects a pedestrian too late — or not at all — won’t prompt the car to slow down in time.

Black box?
How NPS’ atomic norm formulation works, and the exact math behind it, are still secret. “Apparently they don’t need to talk to customers, said veteran automotive industry analyst Egil Juliussen. “NPS appears to be already closely working with General Motors.”

As it turns out, Larry Burns, GM’s former corporate vice president of R&D, vetted NPS’ technology and recommended it to Rick Wagoner, a former GM CEO, who is now an investor. Last year, NPS’ $17.5 million in series B funding was led by Cota Capital, with key investments from GM Ventures and RTX Ventures.

Meanwhile, PercivAI approaches reliable radar perception from a slightly different angle. While NPS strives to improve radar data, PercivAI’s stated mission is to take sensor output and make its data “digestible” by vehicles, according to Andras Palffy, PercivAI’s co-founder. “Our job is to use the radar data better.”

Current-generation radars offered by tier-one suppliers suffer from ghost objects and misclassifications. PercivAI claims its AI-driven radar perception software running on the same hardware can generate a clean, accessible output.

But when the initial radar sensor output is bad, how do you avoid the “garbage-in and garbage-out” syndrome? What processes are necessary to make mediocre radar data digestible?

“We take multiple steps,” said Palffy, noting that top priority is very advanced point-cloud segmentation. Given dirty data, PercivAI’s software detects and estimates points that might be noise or ghost targets bouncing in space, which are then filtered out. The software also distinguishes between parts of a scene that are static and those that are moving. It then measures the Doppler rate of objects moving at different velocities.

Finally, PercivAI extracts features at the point-cloud level. “As we start thinking at the scene level, we argue what it is that the sensor is seeing,” Palffy said. “We take into consideration types of reflections, power, and kind of velocity measured.”

The company claims its software outperforms traditional radar data perception, with help from AI methods and data. The software has gone into series production in drones, but automakers have yet to sign up.

PercivAI, based in Delft, is still young. It secured 2.5 million euros in seed funding in December, led by DayOne Capital and Keen Venture Partners, and joined by Vinci Venture Capital.

‘Paradigm shift’
Transitioning from hardware-based radar to software-based radar poses big changes to a hardware-centric industry with a supply chain built on a vertical structure. In the current ecosystem, semiconductor companies function as tier twos. Tier ones develop “a box” that contains tightly integrated software and hardware, and OEMs select the box they want.

But with hardware-agnostic software, this hierarchy of relationships begins to unravel. Software-defined radar vendors are eager to work with different tiers across the whole automotive ecosystem.

NPS’ Rezvani noted that software licensing agreements can be executed directly with either tier ones or OEMs. PercivAI’s Palffy similarly noted that his company will talk to system companies as well as semiconductor vendors that make radar chips.

“Big paradigm changes are coming to the supply chain,” said Paul Baumgartner, software engineer at Siemens Digital Industries Software, pointing to the emergence of new opportunities for the engineering community driven by safety goals. “Radar is maybe one of the best places where a huge change [of SDV] starts to happen.”

Siemens’ approach involves developing more sensor fusion algorithms by bringing data — potentially raw data — into the combined processing unit. Baumgartner said the automotive industry has yet to reach the so-called hardware-agnostic phase, but a shift from object data to point cloud, and ultimately to more raw data, is coming. “I’ve also seen architectures where they stream the ADC data directly to domain controllers,” he said.

Now that it’s possible to move gigabits per second of data, instead of megabits, data can go to different devices inside a vehicle. This would allow OEMs to change where the data processing takes place.

Platform approach
Meanwhile, many new startups are popping up to develop and train data for carmakers to use. Those startups are coming up with nouvelle algorithms for software-defined radars, and automotive semiconductor suppliers like NXP see opportunities to pitch a platform approach to run software-defined radars.

Matthias Feulner, ADAS marketing chief at NXP, acknowledged that one of its partners — Zendar, a California developer of advanced automotive radar software — has demonstrated how its software can run on NXP’s radar silicon.

“We have been doing a lot of our internal work on software-defined radar that can leverage the new capabilities of distributed radar sensor systems,” Feulner said. NXP’s Purple Box, for example, is a proof-of-concept development platform for customers to analyze distributed radar. While enabling carmakers to do raw radar data streaming architecture analysis, it also lets them investigate new processing capabilities for zonal computing and AI.

Deciding where software-defined radar software should run is up to customers, said Feulner. Presumably, one can optimize it to run on specific hardware. But the point of offering customers software-defined radars is flexibility. The software can run in early radar fusion, or customers can evaluate the software in central and zonal radar processing.

NXP’s goal is to “make customers’ decision and adoption easier, while allowing them to add their own differentiation,” Feulner explained.

Who owns the software?
Software ownership could become complicated, however. For software-defined radar companies, there are multiple ways to skin the cat. But for OEMs, it’s a strategic issue that affects their future roadmaps, and carmakers often insist on owning certain parts of a vehicle system.

“We have come to learn that our customers want to control, tailor, and modify their software-defined solutions,” NXP’s Feulner explained. However, for other parts of these systems, “they would rather have us provide a baseline that they can build upon in order to accelerate their time to market and reduce their efforts in doing the system integration.”

Similarly, Paula Jones, segment director for ADAS at Infineon Technologies, sees different models emerging for software ownership at the vehicle level. “For radar, it is traditionally a Tier One,” she said. “But it can be a Tier 1.5 or OEM, as well.”

Infineon sees its role not necessarily as a supplier of just its radar chips, but as a provider of tools that make radar software development easier for customers. As a semiconductor provider, Infineon is agnostic on software ownership,” Jones said.

“We offer tools to get started on radar software development,” she explained. “With our imaging radar, Infineon makes available a radar reference design CARKIT with software source code to get our customers up and running and enable quicker development. This kit supports transmission of raw ADC data, intermediate processed data, or radar detections via Gigabit Ethernet interface.”

But where, ideally, should the software run? “In today’s market, the software is typically running in the radar module,” Jones said. “However, architectures are evolving to where the processing of the radar data is completed can end up in different locations, such as a centralized computer or an intermediary ECU.”

Even in these various architectures, front-end processing is needed at each radar module to reduce the network bandwidth needed to transmit radar data for further centralized processing, Jones noted. “Infineon’s AURIX microcontroller is a standard in the market for processing data in radar modules, and our latest microcontroller also includes a special parallel processing unit (PPU), a type of AI accelerator to assist in front-end AI processing.”

Fig. 1: Infineon’s radar development kit. Source: Infineon

Conclusion
Despite the auto industry’s obvious desire to transition to SDV, the “revolution” is more likely to happen in baby steps. Software-defined solutions could buy carmakers flexibility and scalability while installing potentially higher-performance radar more cheaply, but cost becomes an issue for managing software updates, adopting the software that needs compensating the eventual degradation of sensors.

Related Reading
Radar, AI, And Increasing Autonomy Are Redefining Auto IC Designs
Adding more intelligence into vehicles is increasing reliance on some technologies that were sidelined in the past.
ADAS Adds Complexity To Automotive Sensor Fusion
Advancements in combining sensors enabling intelligent, distributed processing and standardized communication of object data.
Auto Ecosystem Begins Shift To Software-First
Carmakers and traditional tiered automotive suppliers are still grappling with how and when to move to software-first vehicle architectures.