EV Architectures Evolving For Communication, Connectivity

Electric vehicle architectures are rapidly evolving to accommodate multiple forms of connectivity, including in-vehicle, vehicle-to-vehicle, and vehicle-to-infrastructure communication. But so far, automotive OEMs have yet to come to a consensus on the winning technologies or the necessary standards — all of which will be necessary as cars become increasingly autonomous and increasingly interactive.

Sharing critical data between vehicles, and between vehicles and infrastructure, sounds straightforward enough. But not all connections are robust or last long enough to completely transfer that data. In addition, there are concerns about who owns what data, whether that data is secure, and how quickly that data can be processed by different vehicles from different vehicles made by different vendors.

And for all the purported intelligence in vehicles, even the smartest car available today is unable to complete an activity that has been successfully executed by both geese and racing cyclists — platooning. Also known as flocking, this occurs when multiple parties coordinate their positions en route to decrease drag and increase efficiency. This type of activity requires V2V systems that will, at least, talk to one another. Manufacturers currently are researching a variety of competing technologies, but so far there is no obvious resolution.

Similar challenges arise when considering the V2I interactions with smart cities, such as a vehicle connecting to and communicating with a traffic signal. While a simple transfer of data is possible, such as a transponder communicating with a toll system, moving lots of data requires higher-frequency wireless technology. In the case of 5G millimeter wave, or 6G technology, those signals may be unreliable in bad whether or in heavy traffic, where signals may be interrupted by other signals. And even in perfect conditions, with minimal noise, there needs to be some normalized way of communicating motion vectors within a three-dimensional world.

“A stoplight would communicate objects in exactly the same way an onboard camera would communicate them,” said David Fritz, vice president of hybrid and virtual systems at Siemens Digital Industries Software. “The decision-making within the car could be consuming all that information from other vehicles, from the stoplight, from the top of the building, from the cameras onboard. That means the protocols of that data, whether it’s generated on board or generated from another vehicle, have to be defined, and they don’t really exist yet.”

Until vehicles are able to connect with the cars and objects around them for additional information, and possibly well beyond that, EVs must generate all of the necessary information about their environment and then find ways for those various systems to communicate. The lack of industry standardization is just one factor contributing to the increased on-board compute requirements that system and chip architects must accommodate, but it’s an important one Currently, that evolution includes more chips developed at advanced process nodes, a combination of local and longer-distance processing, ECU consolidation, and the use of hypervisors to manage one or more SoCs.

Architectural changes
EV designs include a growing number and diversity of sensors. And while those sensors increase reliability and improve safety, they also generate more data that needs to be processed, and in some cases routed and stored.

Companies within the automotive ecosystem handle this in a few different ways. “Using more advanced process technology allows us to put more transistors on the chips and do more compute,” said Marc Greenberg, Cadence’s product marketing group director for DDR, HBM, flash/storage and MIPI IP. “You can get a lot of compute done on a single die at 5nm. There are also multi-die systems where the die is put together in the same package, or multiple die are put in multiple packages on a PCB.”

But this also can get extremely complicated. Some data is collected and processed locally, while other data needs to be routed back to a central hub, or even sent to servers on the edge or in the cloud.

“Right now, both of those solutions are valid, though where we go in the future is a bit undecided,” Greenberg said. “Some of the things enabling that are higher-speed automotive interconnects that have the capability of transmission distances up to 10 or 15 meters, so you can go from a headlight cluster to a central processor in a truck. It’s long compared to what you would do on a PCB. We’re starting to see new standards develop, like MIPI, and Automotive Ethernet, which is commonly used, along with a number of different industry standards groups’ efforts. However, we’re not converging on a single solution for the problem of, say, how to transmit a high-bandwidth signal of 15 meters through a vehicle with high reliability.”

Fig. 1: Technologies for connectivity within a vehicle. Source: Cadence

Architecturally, these big picture changes are significant, and there are repercussions for any changes to the in-vehicle chip architecture.

More software, different challenges
“The first thing that’s happening is that with the direction toward ADAS, toward autonomous driving, more of those functions are being brought together and interacting with each other,” said Marc Serughetti, senior director for embedded software solutions and systems at Synopsys. “The second change is in the hardware architecture. The challenge of putting one function on one ECU means that if you’re trying to bring in 100 functions, you need 100 ECUs. That’s not scalable. As such, the underlying compute architecture to support this increasing number of functions, and the increasing amount of data that is exchanged through the car, is changing. This is illustrated with the move toward a zonal architecture, which evolved from a domain approach, and is continuing to evolve toward centralized compute.”

Add to this a software-defined approach, which reduces obsolescence and keeps vehicles up-to-date with various standards, but which opens the door to an almost perpetual series of updates.

“Now that you have a software-defined vehicle, you want to have that software because you want to do those updates all the time,” Serughetti said. “So now you’re also in a mode where you need to continuously and constantly have means to validate software updates and upgrades that you want to do. That also has an impact on the architecture, because you need a hardware architecture that enables you to do those upgrades and updates in a way that’s manageable. If we go back to the concept that you would have 100 ECUs with 100 functions, and if you have to upgrade all of them one by one, that’s challenging. You would have to bring the car in the shop for that. You cannot do it over the air, which is the direction the industry is heading.”

Changes are coming to both electric vehicles and those powered by internal combustion engines. While the fuel sources and power sources are different, both have shifted from a distributed to a centralized domain architecture, and more recently to a zonal architecture. But with EVs, and particularly data-driven EVs, there is more integration required in areas such as the powertrain subsystem and battery management systems.

“What we’re seeing across the board is companies trying to merge different aspects of controlling an EV together,” Fritz said. “Whereas you may have had half a dozen printed circuit boards, now we’re seeing those merging onto one system with an overall reduction in power consumption. With what is essentially a single system on silicon, the connectivity is faster, the power is lower, and the weight ratio is far lower than wire harnessing and connecting all those printed circuit boards together.”

The essential ingredient here is data, and that data needs to be prioritized so that when an ECU needs to communicate with another ECU, it happens quickly enough to respond and avoid a problem. This is where Automotive Ethernet and other high-speed communications technologies come into play.

“There are a lot of solutions out there that are 1 Gigabit Ethernet communication. There are several that are 5 Gigabit, and several more coming in the next few years that are 10 Gigabit,” Fritz said. “That type of connectivity bandwidth opens up a whole new set of possibilities. One of those possibilities is new software architecture that overlays the consolidated system. This new consolidation and high-speed connectivity allows you to split the functionality up. Generally, what we’re seeing is a hypervisor running which allows different operating systems to run on different parts of the SoC, because some tasks are time intensive while others are more safety-related and immediately critical. Every direction that we look essentially represents a communication layer across the different operating systems that are functioning underneath the hypervisor. The connectivity across those highly complex systems of systems rolled up into the larger system has really changed how the software and hardware is architected.”

When it comes to safety, OEMs are trying to figure out the correct combination of redundancy and reliability in their communication systems. “I see some manufacturers building in safety and reliability for their autonomous driving systems through redundancy, and that’s not a bad thing,” said Greenberg. “It’s been a solution in airplanes for decades. I have seen similar types of architectures in some vehicle systems where they will take a device, make duplicate copies of the same hardware, and compare the result. The other approach is to take a single system and make it highly reliable. Both approaches have their pros and cons.”

Other issues
When, where, and how that data moves opens the door to other potential problems. Security is a persistent problem in any connected electronic device, and the problem only becomes more challenging with V2X, which also includes using a public charger.

“An attacker could try to compromise this system because it can be accessed physically, unless it is installed inside a closed garage,” said Maarten Bron, managing director at Riscure. “Even residential EV charging stations pose a safety and security risk. The system can be connected to WiFi, and any WiFi device can be subject to an attempted attack by a hacker. There’s also a potential for safety issues if an attacker compromises the EV charging point and starts a fire or overcurrent.”

Bi-directional charging adds another security risk, as vehicles are connected to the grid. In the future, automotive OEMs will need to find a consistent way to address such security risks in their EV architectures.

Fritz also noted that power considerations are reaching a pivotal point as the changing architectures accommodate increasingly advanced activities. “There’s an intermediate step we have no choice but to go through, and that is to have some other method of augmenting the batteries — unless somebody discovers an unbelievable battery technology that drains slower, charges faster, and weighs less,” he said. “It doesn’t matter if we go down to 4nm if we’re still consuming way more power than one would like. It’s already to the point where, if you’re driving an autonomous vehicle, you can actually see the battery gauge move.”