Glenn Perry, general manager, embedded systems division, said Mentor’s interest in the automotive sector dates back to 1991, adding its software can now be found in more than 100million cars.
“What’s happened,” said Perry, “is that some OEMs feel they’ll be out of business if they don’t have ADAS or autonomous driving solutions. They’ve been taking lower level ADAS functions – such as adaptive cruise control (ACC) and lane departure warning systems – and cobbling them together to get ‘more ADAS’. Meanwhile, Ford and GM are spending billions to acquire the technology.”
In parallel is the growth in the number of ECUs. “There’s more than 100 ECUs in some cars and every time a new function is added, OEMs tend to add another ECU. It’s becoming unmanageable,” Perry contended.
Current ADAS systems take input sensors such as radar or LIDAR. However, initial processing is performed at the sensor and the result is transmitted via the car network to the ACC module, for example, for further processing.
“This arrangement has inherent challenges,” Perry argued. “There’s data processing latency at the edge nodes, as well as incremental cost and higher power consumption. But, at the end of the day, it’s a partial data set and if you have two or three other sensors, each will generate its own partial data set and doesn’t know about data from the other sensors.”
“We decided this architecture didn’t work, so we stepped back and started again with a clean slate, asking ‘how do you design the system?’.”
Mentor’s answer was to remove the edge processing operations, operating instead on raw data in a central unit – DRS360. “This approach removes latency, lowers cost and power consumption,” Perry said. “When you have a fused data set in one map, you can apply a neural network and machine learning. These will operate more efficiently than they would with separate data sets.”
The DRS360 solution has three elements: a Xilinx UltraScale+ MPSoC, for sensor processing and control and data fusion; an SoC, to handle ADAS and autonomous driving functionality; and an MCU, to connect with the vehicle network gateway. According to Perry, the system consumes 100W – ‘dramatically lower’ than other systems.
“We selected the MPSoC for a couple of reasons,” Perry observed. “We have focused on algorithms which do time and space data fusion; that’s complex to do, but efficient, and we accelerate that through hardware.
“It’s also a flexible architecture, because we can’t predict all the interfaces that will emerge. An FPGA means DRS360 can adapt to future needs, because customers always like to make modifications.”
DRS360 is an open architecture design, which means OEMs and Tier 1s can add their own algorithms or ‘tweak’ the system to get more acceleration. “But it’s 90% of the way to production,” Perry said, adding “we have also designed it so OEMs can retrofit other FPGAs if needed.”
Security is also a consideration. “The module has been designed to minimise the number of attack surfaces and to eliminate the need for an intermediate network that may be able to be attacked. It is also protected against attacks via V2X, short range comms or 5G,” Perry claimed.
He anticipates two use cases for DRS360. “While it’s designed for Level 5, users can scale it down and get processing power benefits, or they can focus on developing at the highest level.”
Vehicles featuring DRS360 are expected to appear in the early 2020s, Perry concluded.