Aptiv Centralizing Computing Power to Speed Autonomous Vehicle Development

December 11, 2019

Lindsay Brooke

The software-intensive, electrified and increasingly automated vehicle will define the 2020s. Its rise is driving both the industry-wide re-thinking of electrical architectures and the growth of engineering employment behind it. At the forefront of this trend is Aptiv, the technology Tier 1 spun off from Delphi in 2017. It now has more than 19,000 engineers among its 160,000 staff, comprising one of the highest engineer-to-employee ratios among large suppliers.

“We’ve been adding about 1,500 engineers per year, primarily in software and systems engineering, at our 15 major technical centers,” said CTO Glen DeVos. These resources, he noted, will help Aptiv accelerate its customers’ development of new vehicle platforms with greater active-safety capability, including automated-driving functionality.

The OEMs want full upgradeability of software (FOTA; firmware over the air) and SOTA (software over the air) capabilities, DeVos explained. He noted they’ll also want centralization of compute – moving from today’s multiple ECUs to a few domain controllers – and zonal control, all with reduced complexity and cost.

DeVos called this broad trend “a blank-sheet approach to move away from traditional architectures” to more advanced, open-sourced ones. “We formed our Smart Vehicle Architecture group a little over two and a half years ago when we saw a trend developing: The massive content occurring in SAE Levels 1, 2 and 3 vehicles that is creating pain points for our OEM customers,” he said. More features, more data and not just for Level 4. “It’s across the board,” he said. “We realized that to pack everything they wanted and that we were thinking about into a Level 4 vehicle, there was no way to do it economically without a fundamental architecture change.”

Based on its booked orders, Aptiv expects deployment to begin 2022 in premium vehicles, ramping up steadily from 2025. And while the company has multiple programs developing SAE Level 4 self-driving functionality with customers aimed at commercial geo-fenced operations, such performance is not anticipated to be ready in consumer-level vehicles until the 2030 timeframe, DeVos said.

“We’ve always talked about automated driving being on the continuum of active safety,” said DeVos, who while at Delphi was part of the pioneering work on Jaguar’s first Active Cruise Control launched in 1998. “Going from Level 2 to 3 and ultimately to Level 4 and 5 is all on the continuum. We want to take the technologies we’re developing for Levels 4/5 and apply it to Levels 2/3 as the next generation of advanced capabilities and features. It’s important to think how we can bring both ends of the spectrum together.”

Focus on SAE Level 2/3

SAE Level 2 to Level 3 is currently Aptiv’s main focus for automated-driving systems development. “We know Level 0 and Level 1 systems, with the progression of Euro and U.S. NCAP [impact safety] requirements, is going to be the baseline by 2025,” DeVos says. “You won’t have cars that are significantly de-contented from Level 2. That’s where the market is moving. It’s our ‘sweet spot.’”

An ADAS domain controller provides the fusing and perception modelling, the “brains” that DeVos compares to having a fileserver on board. In the new architectures, consolidating from the dozens of discrete ECUs on today’s vehicles to up to five powerful central compute controllers, will drive a change to smaller “decontented” cameras and radars with less processing capacity and thus lower cost. The controllers would be responsible for active safety, the user experience (UX), propulsion and chassis systems.

“We’re seeing costs getting ‘democratized’ for those [up to SAE Level 2] systems,” DeVos noted. “But as you go from Level 2 to Level 3, however, there’s an inflection point. This is driven by everything that supports the driver being out of the loop. In our view, Level 3 is advanced driver assistance where the car is basically in control. It’s able to make decisions with the driver disengaged.”

That brings the need for fail-operational and safe-stop capability, and the need for redundancies. “Power systems, controls, everything that avoids a single-point failure,” DeVos explained. “With a Level 2 system, the driver is that redundancy. With Level 3, it drives a lot of additional components in today’s architectures.” He said that includes driver sensing and some level of mapping, the latter typically provided by lidars which are still expensive.

Then there’s the reality of what DeVos describes as “just more sensors.” While for SAE Level 2 the vehicle may have forward looking cameras with 360-deg. radar – a cost-effective approach – going to a Level 3 system may include an array of 360-deg. camera, 360-deg. radar and a lidar sensor. “360 vision systems add a lot more complexity and drive a lot more processing,” DeVos said. “The compute requirements go up dramatically. The domain controller would have a lot more capability than your previous Level 2-plus controller, and you need a secondary controller in case that fails. Adding those pieces together the cost adds up.”

Driving down costs

Driving the cost curve down on ADAS technologies will take some time and will be a function of volume and systems cost optimization, DeVos said. Then ultimately it will be a function of vehicle architecture, because today’s Level 3 systems basically are an overlay on the Level 2 architectures. The redundancy is an add. “But with the next-gen 2025 architectures, there are things we can do to bring the cost and complexity down. That will be helpful in terms of market adoption,” he noted.

A key aspect of Aptiv’s new approach to system architecting is what engineers call ‘Safe Dynamic Partitioning’. A traditional operating system (OS) would never mix Infotainment (typically a Linux- or Android-based platform) with anything that has functional safety aspects such as ADAS. Each has its separate ECU. And both are typically underutilized.

“The industry norm is not to use any more than 80% of a box at peak load,” DeVos said. “But when I add all that up and look at the total loading, I’m grossly underutilizing the silicon that’s in the vehicle. And I’m paying for each box, over and over again.” He said that Safe Dynamic Partitioning allows design engineers to take a general compute platform and put on it whatever they want – infotainment or functional safety, each partitioned and managed safely.

“I don’t need two boxes; I can consolidate them. Without the ability to have this mixed criticality, you end up with a lot of redundant boxes,” DeVos explained. “For example, you can use the infotainment compute as a backup (such as if a failure were to occur) and put my Level 3 ADAS controls on it. If I architect the product right, I can get redundancy and fail-operational capability without duplication.”

The advent of purpose-built EV architectures entering volume production this decade can help reduce cost and the speed to market of Level 3, DeVos said. Properly architected they will not require add-in duplication to get redundancy. Instead, it can be accomplished through more effective sharing among controllers. “We’ll have capability for moving processes from a failed controller to another, as opposed to just duplication which is where we are today,” he said.

An agnostic approach

Aptiv’s ‘smart vehicle architecture’ approach is based on lessons learned from mobile computing (smart phones) and other industries where software is embedded and inseparably connected to the hardware in purpose-built machines, each one separate from the other from one generation to the next. The lessons include:

• Abstracting software from hardware means decoupling software development from the underlying ECU or component development. DeVos admits that today it is a massively complex task in getting everything to work properly. Proof of that came in 2014, the first year that warranty costs for software at the OEMs became greater than those for hardware. The situation will only worsen as today’s distributed architectures proliferate, according to DeVos.
• Separating I/O from computing – with all the sensors, actuators and data that’s flowing around the vehicle, with hard connections back to each of the compute platforms, changing those sensors and actuators at new-model time requires changing everything – rearchitecting the compute, the sensor interfaces. It’s unmanageable.

“And that’s not how servers operate,” DeVos said. “Servers abstract compute from the I/O. All the I/O comes in standard format to that server so it’s managed very carefully. And that’s the third important point: enabling the ‘serverization’ of the platform.” This involves aggregating compute into several modules that support all the features of the vehicle and doing it more effectively. “Essentially what we want to do is make the compute agnostic and independent from all those sensors and actuation,” he explained. “For us it’s not reinventing the wheel; it’s applying this separation to the automotive space.”

---