Self-Driving Cars Rattle Supply Chain

Automotive compute workloads are consolidating as carmakers push toward autonomous vehicles, but the changes necessary to make this all work are causing huge disruptions in an industry that has fine-tuned its supply chain over more than a century.

Consolidation is essential for a variety of reasons, including efficiency of the computations, complexity management, and lower deployment costs. And while this seems like a natural progression in markets like PCs and smartphones, it’s a whole new ballgame for automotive OEMs and their suppliers.

The automotive industry has been talking about the need for ECU consolidation for many years. But discussions typically have centered around physical space, the cost of silver boxes, the weight of the ECUs, and kilometers of wiring required to connect them all together.

“Broadly, consolidation is being driven by cost, flexibility and energy-efficiency, as well as evolving network architectures,” said Richard York, vice president of embedded marketing at ARM. “Combining functions into fewer ECUs simplifies the web of controllers in vehicles, aiding communications between the different systems. It contains ever-rising complexity. And it helps reduce energy consumption by lightening the vehicle weight. With more vehicles introducing ADAS and autonomous drive hardware, the compute performance demands and data rates on communications are also rising.”

The problem is how to get this done. So far there is no agreed upon approach. Much of this remains a work in progress, despite looming deadlines set by carmakers to put autonomous vehicles on the road sometime in the next four years.

How many brains?
“There is one class of design approach, usually driven by either a new platform or a newer car company, where the integrator—the actual vehicle company—says they want all of the ADAS software and all of functional safety qualification integrated into the main CPU, whereby everything is centered around one giant brain,” said Steve Roddy, senior group director for Tensilica marketing at Cadence. “There’s a countervailing approach that says there are multiple independent smart systems, and things should be kept isolated such that the vision processing can be localized where the camera or the radar or the LiDAR are. The higher-order commands are sent back to the central processing unit, which is more of a decision-maker and less of a number cruncher.”

Automotive electronic control units (ECUs) traditionally have been built around mechanical functions within a vehicle, such as engine control or braking or infotainment. But as cars become increasingly autonomous, those functions need to be integrated for for safety reasons.

“The current architecture is that each ADAS application has its own ECU,” said Ron DiGiuseppe, senior strategic marketing manager at Synopsys. “So the lane departure warning beeps when you drift out of your lane. That has an ECU. With the forward collision warning you get a beep, and that has an ECU, as well as an application like automatic emergency braking, which could detect a collision about to occur and apply the brakes for you. That has a different ECU, as well. Park assist has an ECU. Blindspot recognition has a separate ECU. Each one has its own module and its own ADAS processor, and it is very distributed. This is how the industry has been implementing the higher-level OEM architectures.”

Another consideration here is the fact that all of those distributed ECUs have different automotive networking. A lot of them use the legacy controller area network (CAN), and the impact to the wiring harness is that there is a lot of point-to-point wiring in the car. This is significant given that the wiring harness is the third heaviest system in the car, after the frame and the powertrain. There are literally kilometers of wiring, and to integrate these different modules the automotive network must move to a more advanced technology. Currently, that is Ethernet audio video bridging (AVB), with the Ethernet time-sensitive networking (TSN) technologies.

“Integrating all of these separate ECUs into a more modern network is good, and also integrating those ECUs to combine functions is the next set of architectural challenges,” DiGiuseppe said. “We see a trend in the industry where you would have something like a separate forward collision avoidance warning ECU getting merged with the automatic emergency braking ECU, because they’re both doing similar things, and there could be a consolidated module instead of separate ECUs on separate networks. We are seeing an integration of those distributed ECUs to a more centralized ECU.”

Fig. 1: ECU consolidation. Source: Mentor Graphics

At the same time, Roddy noted that things are not so clear-cut among the automotive OEMs. “There isn’t a breakdown where you can say traditional car companies do it this way, new car companies do it that way. The easiest thing would be to say the electric car/autonomous car startups are all doing the centralized version, and the legacy companies are doing it purely distributed. It tends to skew that way, but it’s not entirely that way. There are pros and cons to both. First, the platform maker has to decide whether they want multiple-gigabit high-speed networks running around inside the car. Some people think this is perfectly fine and dandy — they’re going to put gigabit-Ethernet automotive grade in, they’re going to have many different streaming high-definition video feeds and high-data-rate radar feeds pumping into one giant CPU. There are others who think that’s a recipe for disaster. So it may well be that that’s the primary determining factor of some people’s decisions—whether they fear or whether they embrace a large high-speed data network racing around the vehicle.”

Roddy also stressed the issue of integration complexity, particularly if a car manufacturer gets an integrated vision/radar proximity warning system from a Tier 1 supplier. “To some degree there’s value in doing it that way by having specialization of labor, because not every car company wants to have all the knowledge of all the systems all integrated together.”

The number of ECUs in a vehicle continues to grow at a fairly shocking pace. This is partly due to rising complexity, but it’s also partly due to the fact that automotive OEMs are new to electronic and software design.

“Every time they want a new function, the way their supply chains works is they describe the function on paper and they subcontract it to a Tier 1 to build,” said Glenn Perry, vice president and general manager of the Embedded Systems Division at Mentor Graphics and the head of Mentor Automotive. “And it results in yet another module for the vehicle. Then the modules take on a life of their own, and it turns out that technically speaking, there’s no real constraints in terms of the ability to consolidate these functions into fewer modules.”

The aviation industry went through this consolidation decades ago with the 787 and other advanced aircraft, Perry noted. What has limited consolidation in the automotive space is organizational structure, which spans from OEMs down to Tier-1s and Tier-2s, both in procurement and in engineering.

“Essentially, there is one group that’s responsible for clusters or driver information,” he said. “There’s another group responsible for IVI (in-vehicle infotainment). And neither wants to give up their position to the other, so they’ve remained in silos. And yet what we experienced a couple years back is that the Chinese OEMs said they didn’t really care if the people in their organizations were sensitive to collapsing those organizations. They were going to move forward and consolidate.”

Fig. 2: A different space. Source: Mercedes-Benz.

Change required on every level
Of course, consolidation becomes increasingly important for ADAS, especially the highest levels of ADAS, he said. “Coupled with that, the OEMs are under tremendous pressure to be able to deliver autonomous driving capabilities, and it’s one of those things where you’ve got an industry that’s a century old and has never had this kind of threat and disruption that it faces today. If the OEMs don’t figure this out, they’ve got giant tech companies that are trying to compete. There are many startups that can come in on an electric vehicle platforms, as well as the mobility companies. Meanwhile, the OEMs are not particularly well positioned themselves because they’ve always relied on their Tier 1 suppliers for the electronics and software. But it takes the OEM as the system integrator to really deal with autonomous driving.”

Further, no matter which ADAS function it is, architecturally they all work the same way.

“What’s fundamental is they are based on distributed computing architectures,” Perry said. “In the case of adaptive cruise control, for example, there is a radar, which is the actual sensor, and it generates raw data. That raw data, within that same edge sensor node, is then processed with a processing engine (a microprocessor or microcontroller), and a subset of the data is then transmitted over the vehicle bus to the actual ACC module where yet another processor does further analysis and operation on the data. And eventually it provides information that the safety controller uses to communicate over the CAN bus. The communication will either be some warning issued to the driver via the cluster, or some audio warning, and/or actual control of the brakes, acceleration or steering. The same is true whether it is a camera or radar or LiDAR. Fundamentally we do some of the processing out on the edge node, some of it in the control module itself.”

Still, there are inherent challenges with this architecture. Processing done at edge nodes incurs latency. In addition, there are additional bill of material costs for processing done at the edge nodes, and those devices consume power. And when they are done processing data, they need to transmit a subset of that data to a more centralized processing element in the vehicle.

So two systems in the control modules may have data that was collected from the same view, because they both were looking ahead at the same time. But the data typically is sparse, and neither data set knows anything about the other. As a single function, that may not cause a problem. But as the level of autonomous driving increases to the point where functions are consolidated and aggregated, this architecture begins to create problems.

“Part of the reason we got here as an industry goes back to the OEMs, which for each function write a spec, and the Tier 1s build a module,” Perry said. “Then when everybody was challenged to build autonomous driving capability, they said, ‘We need this collective set of functions.’ So it was literally a gluing together of these functions. And even if they all sat in the same module, the data flow would still look the same with all the same limitations that exist if they are in separate modules. Today’s systems aggregate a bunch of these functions into a single module, but the dataflow is still the same.”

Top-down or bottom-up?
This has set off a debate within the automotive industry of whether to use a top-down, clean-slate approach to ADAS Level 5, or whether it should be a bottom up approach or something in the middle.

Paolo Piacentini, applications engineering manager at Kilopass, sees the automotive industry moving toward a hybrid approach with a central controller and distributed intelligence. “Distributed intelligent sensors throughout the car such as tire pressure gauges, accelerometers in each of the wheels to detect motion, radar sensors to detect vicinity— each have their associated microcontroller to process data and send results rather than raw data back to the intelligent controller. With the increase in hacks of automobiles being demonstrated, each of these distributed microcontrollers will begin to incorporate encryption keys to prevent unauthorized tampering.”

At the same time, Kumar Venkatramani, vice president of business development at Silexica, noted that on the low-end of the spectrum, old simple ECUs (microcontrollers) are migrating to more complex multicore ECUs simply to take advantage of part count reduction, as well as power savings. “All the way on the high end, ADAS and autonomous driving systems are performing heavy-duty full-function computation using multiple CPUs, GPUs and DSP because of the very stringent latency constraints.”

This is being borne out in multiple scenarios. In a lot of cases, Tier 1s as well as OEMs are being handed multiple cores as part of their platforms, or as drop-in replacements, and these Tier 1s are having to come up to speed on how to take advantage of the many cores offered.

“This is hard to do, especially when a lot of their code traditionally has been written for sequential single-core systems,” Venkatramani said. Complicating matters, AUTOSAR, a very commonly used standard in the automotive marketplace, was put in place for OEMs to be able to mix-and-match components from different vendors. But AUTOSAR — now called AUTOSAR Classic — has been targeted at single-core systems, and both vendors and OEMs are asking for help to migrate AUTOSAR code onto these multicore systems.”

On the other end of the spectrum, potential vendors of these autonomous driving systems are dealing with hybrid compute systems made of many-core CPU, GPU and FPGA systems, which are hard to program. “If you have a traditional homogeneous multicore system, slapping an OS on top to do some amount of scheduling used to be enough, Venkatramani said. “But with the average power (particularly heat) constraints, heterogeneous systems are now being experimented with, and programming them is extremely hard. Simply running them on 2GHz CPUs or power-hungry GPUs is no longer competitive.”

The AUTOSAR consortium is now scrambling to put in place Adaptive AUTOSAR to address these challenges for multicore and autonomous driving requirements. And while consolidating workloads and having more powerful compute systems available will nudge toward single — or at least more consolidated — systems on the hardware side, this will not happen overnight. Automotive electronics have to undergo rigorous safety certifications, and given the time required to get these certifications, incumbent ECU hardware vendors will have an advantage. So while ADAS and autonomous driving systems may be considered optional in the first few releases, they will co-exist with the ECU vendors for a while, Venkatramani said.

Related Stories
LiDAR Completes Sensing Triumvirate
Technology will complement cameras and radar in autonomous vehicles.
Why Auto Designs Take So Long
A design for safety methodology is essential to trim automotive design costs, but at this point it’s a work in progress.
What Can Go Wrong In Automotive (Part 3)
Why power has become so important in car electronics; the challenges in making autonomous vehicles reliable enough; adding margin for safe modes of operation.
What’s New In Connected Autos
Internet of Things technology will be crucial to automobiles, but connectivity comes at a price.