Addressing the Vehicular Electrical and Electronic Architecture

Vehicular electrical and electronic (E/E) architecture is about to undergo a significant change, says, Michael Crane, Vice President, Body & Security for the North American region of Continental’s Automotive Interior Division, for a variety of reasons, not the least of which include market demands of various types. For example, there is the issue of highly automated driving, which may simply be your car being delivered to you valet-like, sans the guy behind the wheel, or something higher on the SAE levels. Which leads to a need for connectivity, especially going forward to a 5G environment. This connectivity serves a number of needs, ranging from navigation (useful for more automated vehicles, in terms of up-to-date mapping data) to recreational activities, like streaming Netflix. Because a vehicle is likely to be more sensor-intensive, Crane points out, it can be a node, in effect, on the network of vehicles, such as providing weather information to other vehicles. And it just may be that information like this, as it is valuable, could become a source of monetization.

Of course, all of these things present challenges to the OEMs as they try to provide what Crane describes as a “new holistic user experience,” one that is predicated on expectations that consumers have developed through their mobile on-line experiences—with “mobile” being in the context of hand-held, not on-the-road. These challenges include managing complexity as regards the architecture, providing the ability to have updates (as in what occurs on an iPhone. . .or for a Tesla), implementing cybersecurity, and providing flexibility and scalability as regards the hardware and software. And let’s not forget cost and weight reduction (factors that play a huge role well beyond E/E).

According to Crane, what’s required for all this are high bandwidth and low latency.

Too Much Distribution

Crane explains that today the current vehicle E/E architecture is one that is predicated on distributed functionality, distributed hardware that is matched to specific software to achieve that functionality, and extensive wiring and communications. “Today,” Crane says, “there are 100 or more ECUs distributed around the vehicle.” Which explains all of those wires and networks. That’s today.

Going forward a few years, to about 2025, he says another architecture will become more prevalent, this one that includes high performance computers (HPCs) and connection to the cloud. In this approach, for example, there could be one high performance computer managing human-machine interface (HMI), body, powertrain, and chassis. There is a connection to an ECU that is responsible for latency and safety-critical functions, as well as “zone” ECUs that are connected to sensors and actuators. There would also be an additional HPC and ECU that would be available for purposes of redundancy should there be a failure of the first set. Crane calls this arrangement a “server architecture with zone ECUs.” In this arrangement, there is centralized functionality and consolidated hardware, and the hardware is separate from the software. A cloud component here could handle all functions with the exception of vehicle control, which, of course, includes safety relevant functions, where there really can be no latency.

A Fast, Clean Architecture

Moving forward to 2030 there could be what he calls a “standardized server architecture,” which is something of a plug-and-play approach to the hardware, with less different types of processors being involved in the setup, which would help facilitate dynamic software allocation. Here the cloud could handle all functions except for those that are safety-relevant. It is worth noting, however, that in this setup Crane is talking about operating at 5,000 kDMIPS, so this is a 50x increase compared with today.

 

The evolution of E/E architecture in vehicles has gone to a place where there needs to be a re-think such that as the capabilities of vehicles increase, the complexity of the topology doesn’t commensurately grow.

Fundamental to the change is the HPC, which provides more centralized processing power and handles a variety of domain-specific tasks (e.g., Crane shows an architecture that includes three HPCs—one for controlling the base vehicle, one for automated driving tasks, one for infotainment/multimedia—and four zone controllers, with the zone controllers being linked to a few sensors and actuators. Crane suggests that the HPC-based arrangement is analogous to a server-based IT structure, but it goes beyond that as it provides a variety of other functions, including handling updates and upgrades for the vehicle, acting as a platform for third-party software integration, and providing cybersecurity for the vehicle.

While the HPC is a key element, Crane suggests that the zone controller ECUs shouldn’t be underestimated because they help manage and organize the system rather than having a multitude of sensors and actuators wired directly to the HPC. While there has been more intelligence installed in sensors and actuators over the past few years, Crane thinks that they will become “dumber,” with the smarts going to the zone controllers.

Savings in Vehicle Wiring 

And on the subject of wiring, which is a non-trivial matter in vehicles, especially as there is an increase in processing power, Crane points out that Continental ran an analysis of wiring harnesses as they exist today in a small SUV and what they are in an HPC-zone controller topology. The savings are significant.

That is, the number of wires today is approximately 1,000. This would go to 750, for a potential savings of 25 percent.

The length of wires now is about 2,250 meters; it would go down to about 1,400 meters. That is a savings of 37 percent.

And what is probably the most remarkable (and important): the weight of wires in a vehicle today is approximately 20 kg. That would be reduced to 13.5 kg, or a 32 percent weight save.

Cloud (and Fog) Computing for Auto

While changing the compute architecture in the vehicle is important, as previously mentioned, Crane says that the cloud will play a role. What’s more, so will the “fog,” or that “edge of the cloud.”

The cloud will be where there are what are considered “backend” operations performed, such as keeping track of the vehicle’s status and providing information about the weather on the road ahead (which may seem trivial, but certainly not if this is an automated vehicle).

The fog is where more local information is contained: a local HD map; local road conditions and accident formation. This local fog-based information is particularly important, Crane says, in urban areas, where it is important that there be fast downloads of up-to-date information.

This transformed topology is something that seems almost inevitable, given the increasing levels of automation of vehicles. Let’s face it: you could string more wires and add a panoply of smart devices but that would result in crazy complexity.

One of the things that the HPC/zone controller architecture provides, Crane points out, is overall simplification, which is something that cannot be overstated in importance. There are a number of other benefits, he cites, as well, such as reducing time to market with new functions and capabilities, software component reuse, and the ability to develop data-based business models.

And then there is that all-important weight save, too.