New EEAs for the Connected, Autonomous Future

OEMs and their Tier-1 partners are revamping vehicle electronic and electrical architectures with “über brain” central computers and real-time Ethernet to feed tomorrow’s data-hungry cars and trucks.

January 1, 2017

Lindsay Brooke

For engineers creating next-generation EEAs, the challenge goes well beyond incorporating “only” 20 electrified subsystems as shown in this Ford Fusion Hybrid illustration.

The connected, electrified and eventually driverless vehicle revolution has a less publicized but equally important back story — the development of next-generation electrical and electronic architectures. The new scalable, global EEAs in the pipeline at major OEMs are considered vital for supporting the ever-ravenous data-processing needs of future cars and trucks.

EEAs historically have been evolutionary technology. Their significant rethinking has been a long time coming — over 30 years, in fact. The last real game-changer was the advent of CAN, the Controller Area Network protocol launched by Bosch in 1983. Introduced into the market by BMW on its 1986 850 coupe, the CAN bus has been the EEA’s workhorse — a centralized network bus which broadcasts all of a vehicle’s data traffic and allows the various controllers and sensors to communicate.

The oncoming tidal wave of vehicle-data throughput is a major driver behind next-gen electrical architectures.

The move to CAN buses improved system efficiency, interoperability and helped reduce complexity, which in turn enabled a reduction in wiring, saving up to 100 lb (45 kg) per vehicle and freeing up critical package space.

“CAN and LAN [Local Area Network] are stable technologies that have given us a lot of flexibility in the design,” noted Kevin Layden, Ford’s Director of Electrified Powertrain Engineering. “But while we’re seeing more features being put onto the CAN network, we also have far more sensor inputs and high-draw features today.”

Layden and other experts say CAN-bus architectures suffer from lack of bandwidth and throughput to cope with the data traffic-handling, cybersecurity and eventually machine-learning capabilities needed for future vehicles.

Bosch North America VP Tim Frazier sees the industry moving from today’s domain architectures to zone-type configurations that will help reduce wiring-harness mass by up to 20%. (Lindsay Brooke photo)

“The huge data-processing requirements that come from fusing data from multiple sensors for automated driving are pushing the limits of available microprocessor technology that’s been developed for automotive applications,” explained Tim Frazier, Bosch North America President of automotive electronics.

Experts who spoke with Automotive Engineering for this article say CAN will continue to play a role in EEA subnets. But its fast-rising competitor Ethernet offers 1,000 times more bandwidth. Also known as IEEE 802.3 protocol, Ethernet “is gaining ground for high-speed, high-capacity applications such as active safety because it’s so well proven — it’s in every house and PC,” said Andy Whydell, Global Engineering Director at ZF TRW.

Whydell considers Ethernet to be a supplemental technology “because it’s running in parallel with CAN,” he explained. “Where you don’t have high-bandwidth needs, it’s still cheaper to use CAN as the basis rather than upgrade to Ethernet. It also means you’re not filling up your Ethernet bus with low-priority traffic such as seat-adjustment commands. So we can break out more critical safety-related systems for Ethernet and keep more comfort-related ones on the CAN.”

One of many experts who is bullish on Ethernet, Whydell notes that another protocol, FlexRay, also is faster than CAN but more expensive.

Big processing, centralized control

Currently OEMs use a distributed-type architecture where a plethora of sub-net ECUs work across each other to offer features and functions to the driver. But they’re “reaching the tipping point in terms of capability,” explained Matt Schroeder, GM Executive Director, Vehicle System Engineering.

Bosch’s strategic view of the technology march toward future EEAs.

He noted that GM, currently developing its new ‘Global-B’ architecture due in 2019, is “looking at how to do things differently to allow a broader set of even more advanced features to work with each other in a distributed fashion—and also protect the customer from a cybersecurity aspect.”

Domain controllers will remain a consistent corner-stone of all the architectures, Schroeder said. He noted that the nature of distributive architecture “will only increase as you start to blend navigation with active safety features. The system fundamentals aren’t that much different, but the needs on the customer end are far greater.”

Processing rates of 1 GB per second and faster offered by 1-Gbit real-time Ethernet are envisioned by autonomous-driving system planners. Schroeder comments: “In terms of capability it’ll be like putting a mainframe computer, hardened to automotive specification, into the vehicle.”

Moving to such massively powerful central computers to handle the new data-processing regime in conjunction with broadband data communication with the cloud, was a hot topic among engineers at the 2016 SAE Convergence conference. Delphi CTO Jeff Owens calls the trend “both evolutionary and revolutionary.” The evolutionary part is driven by higher data for specific-zone applications — for example, the need for more current for a hybrid overlay on an existing architecture.

The revolutionary part is rethinking the architecture using a multi-domain controller (MDC) — an “über brain,” he calls it — designed to do the same work as multiple ECUs to reduce system complexity, cost and mass. Delphi, ZF TRW, Bosch and other suppliers have such hardware in production or in the works.

Andy Whydell at ZF TRW likens the powerful new central vehicle processors to “automotive smart phones” that will be customized by OEMs and Tier 1s for various applications.

VW-Audi is on such a course. Its ‘Zed Faust’ (Z-Fast) program is rethinking the EEA for their active-safety domain which includes the vehicle’s radar, LiDAR, vision systems, driver-state monitoring and various related sensors and actuators. There’s a lot of high-speed processing going on. This led Audi to design an architecture for the future that brings a “heavy lifting” central processor to serve as an arbitrator and decision-maker between the subystems, into an MDC.

Unveiled on an autonomous A8 concept in 2014, the Zed-Faust’s compact main board, powered by an Nvidia K1 chip with 192-core GPU, processes dozens of sensor inputs to calculate how the vehicle should safely navigate and drive according to road and traffic conditions. The next-generation central vehicle computer, expected to enter production by 2019, will feature a higher degree of hardware integration and greater scalability.

“What Audi is doing with this is future-proofing their architecture,” Owens observed. The idea is that a succeeding generation of sensors will arrive dramatically smaller and because the heavy-lifting data processing will be done centrally, the front-end processing — including ‘time-of-flight’ information, thermal management — allows engineers to avoid high-end microprocessors in each of the sensors, making them more affordable.

While some current systems can be reflashed for upgrades, most don’t have memory headroom — old data must be off-loaded before they’ll accept more. With an MDC there’s enough memory headroom and processing speed that Audi will be able to add features for a long time. Owens believes that “the really forward-thinking OEs see this [central vehicle controllers] as an architectural shift for the future.”

Reconfigurable designs

Engineers developing the next-generation EEAs say they’re aiming for a standardized hardware platform that, as GM’s Schroeder put it, “can expand and contract appropriately to meet the capability and cost needs up and down the product portfolio. Creating unique architectures is expensive.”

Dr. Alberto Vincentelli, noted E/E and computer science professor at the University of California-Berkeley, agrees. He told an SAE Convergence panel discussion that “the key metrics for architecture to take care of new requirements are flexibility and reconfigurability. If you start a new architecture it can be reconfigured dynamically which extends its practical life,” Dr. Vincentelli asserted. “Design is one issue — but more important is adapting,” he said.

Who would have authority over the central processor in terms of vehicle integration — Tier 1 or OEM? That depends, said ZF TRW’s Whydell.

“We’re in production with some already and I describe them as like ‘an automotive smart phone,’” he said. “Like the processor in your phone you can customize it with various apps to do your own configuration. So, for example, ZF would provide the processor and the OEM would then decide where to get the ‘apps,’ so to speak. They could also buy them from us or write them themselves, or contract a software-specialist company to develop some of the functions that goes into that box.”

Greater inter- and intra-system flexibility is a goal of AUTOSAR, the Automotive Open System Architecture development partnership. Its Adaptive Platform, expected to be completed this year, is designed to help engineers create more flexible architectures. AUTOSAR Adaptive will provide a software framework for more complex systems and help engineers increase band-width by implementing Ethernet.

The AUTOSAR Adaptive Platform, currently set for completion in 2017, is designed to help engineers create more flexible architectures. AUTOSAR Adaptive will provide a standardized software framework for more complex systems and help engineers increase bandwidth by implementing Ethernet. Not a replacement for AUTOSAR, the new standard will likely see its first application in ADAS. It can also aid infotainment system development by providing a more seamless integration into a standard operating system with more connectivity and graphics computing power. According to GM’s Schroeder, AUTOSAR 4.x serves as the foundation of the new Global-B EEA.

Architectural flexibility is a keyword at Bosch, whose electrical engineering teams have various next-gen EEA solutions underway to meet customer requests. “The technology is moving incredibly quickly,” noted Tim Frazier. He sees EEAs progressing from the incumbent distributed architectures to a cross-domain (APAS, powertrain, body and infotainment head unit) configuration, using a building-block approach and propelled by 1-Gbit Ethernet.

“Zone architectures are the future,” Frazier asserted. Moving to them from the domain architecture environment (see chart) will eliminate 15-20% of wiring harness weight, he maintained.

On to the cloud

“We currently have a ‘split technology’ between the cloud and the vehicle — do we need a revolutionary architectural breakthrough, or can we manage it with the architectures we’ve got?” asked Elliot Garbus, Intel VP of IoT Solutions Group and the Transportation Solutions Div., during his keynote at the 2016 SAE Convergence.

Real-time computing won’t be done in the cloud. But looking longer term, Garbus sees a new architectural model enabling “highly reliable, real-time wireless connectivity that’s ubiquitous.” But he doesn’t see it coming any time soon, not even with 5G.

“What we’ll continue to see is significant computing in the vehicle that enables it to operate autonomously, with the cloud used for non-real-time activities as well as the near-real-time coordination around traffic conditions, weather developments, etc.,” he explained. And security will be rooted largely in firmware and software over-the-air updates (FOTA and SOTA).

In any security attack the hackers are looking for the weak link and those links will shift and the threat model will likely evolve over time. “This requires a systematic design approach — hardware and software working together across the entire vehicle and up through what’s happening in the cloud,” Garbus said.