New architectures promise faster communications and lower costs, but not everything will change quickly.
In-vehicle networks are starting to migrate from domain architectures to zonal architectures, an approach that will simplify and speed up communication in a vehicle using fewer protocols, less wiring, and ultimately lower cost.
Zonal architectures will partition vehicles into zones that are more manageable and flexible, but getting there will take time. There is so much legacy technology in vehicles today that carmakers must support an alphabet-soup collection of protocols. For example, vehicles may support Bluetooth, USB, LTE support mobile devices for infotainment, along with some internally-developed protocols. For cameras, MIPI is the predominant protocol. And for real-time control of ADAS, ECUs, and sensor fusion, they likely will support controller area networks (CANs), local interconnect networks (LINs), Ethernet, and others.
One of the key elements for enabling this shift is faster communications. Several years ago, 93% of automotive networks ran at speeds below 100Mbps, and much of that isn’t likely to change overnight. In fact, it’s likely that 10/100/1000BASE-T1 Automotive Ethernet and low-speed buses, such as CAN and its variants, will continue to serve most low-speed communications. But multi-gigabit speeds will be added into vehicles over time for rapid movement of data as cars begin making more consequential decisions based on input from the various zones.
Fig. 1: Comparison of various types of automotive network technologies. Source: Keysight
“The auto industry expects that Automotive Ethernet will not replace all legacy connectivity,” said Jae Yong, solution architect and planner for Automotive Ethernet technologies at Keysight. “Instead, we will continue to see a mix of different communication protocols and methods. The giant cluster of stars in the top right of Figure 1 is the most dynamic, and it’s where a lot of innovation is happening. As we know from physics, higher baud rates increase electrical interference, noise sources, reflections, attenuations, and other losses that impact signals and the data carried within those signals. The faster the data rates are, the more challenging and critical it is to test before deployment. We expect that multi-gigabit Automotive Ethernet will drive the needs of higher-speed communication based on IEEE 802.3ch and IEEE 802.3cy standards. For example, there is a new multigigabit optical automotive Ethernet standard that was recently released from the IEEE 802.3cz group. It is an interesting time for automotive networking, and we should expect many challenges and innovations ahead.”
Others agree, citing faster communication as more of an evolutionary direction rather than an all-at-once changeover. But the advantages of this shift are significant nonetheless.
David Fritz, vice president of hybrid and virtual systems at Siemens Digital Industries Software, points to Automotive Ethernet as the likely leader in this area. “The bandwidth will very soon support all implementations of L4 and L5 autonomy. Furthermore, CAN frames can be transmitted over the Ethernet network, allowing gateways to manage local CAN and CAN FD zonal networks supporting existing ECUs. The weight and power aspects of Automotive Ethernet are far superior to conventional CAN networks. Can FD is emerging as a competitor to Ethernet, and the jury is still out on which will prevail. However, one hint is that we are seeing sensor, actuator, and ECU providers directly supporting Automotive Ethernet because of the properties mentioned above.”
Automotive Ethernet is the entrenched choice. “One of the goals here is to replace proprietary solutions, instead using as many standardized networking technologies — protocols, controllers and PHYs — as possible,” said Robert Schweiger, group director of automotive solutions at Cadence. “Reducing the variety of different networking technologies to create a more homogenous network architecture is another objective. Doing so requires leveraging Automotive Ethernet, e. g., 10BASE-T1, 100BASE-T1, 1000BASE-T1, 10G BASE-T1.”
Key for zonal architectures will be a significant increase in the overall bandwidth and efficiency of the in-vehicle network, Schweiger noted, with zonal architecture mainly relying on Automotive Ethernet, ASA Motion-Link/MIPI A-PHY, MIPI CSI2, MIPI DSI, POF, CAN and LIN. “Of course, this might vary from OEM to OEM, with some proprietary solutions still in the mix.”
Fig. 2: Zonal architecture simplifies traditional domain approach. Source: Marvell
Nothing changes overnight in automotive design, of course. Design cycles typically last at least several years, and designs for some components and sub-systems may stay in the market for much longer than that. As a result, the automotive network landscape will continue to be a mixture of protocols and application-dependent schemes. Some will serve non-real-time applications, such as infotainment and in-cabin occupant behavior monitoring. Other protocols will support safety and other real-time applications.
“For instance, drivers will be alerted if children or pets are left unattended as the driver leaves the vehicle,” noted Kevin Kershner, solution architect and planner, Automotive SerDes Technologies at Keysight. “OEMs are working to simplify the design of real-time applications while increasing performance and communications speed, especially in autonomous driving.”
In addition, electric and electronic (E/E) architectures in the automotive industry are evolving to support increasingly complex requirements, including the role of sensor-based driver assistance systems (ADAS) and autonomous driving (AD) applications.
“Abundant display technology is inside and around the vehicle, including high-resolution dash panels, side-view mirror panels, and infotainment options comparable to consumer electronic device services,” Kershner said. “Many sensors, including cameras, lidar, and radar, capture the high-resolution data, then transmit or aggregate it with other sensor data for further processing by an ADAS/AD application.”
As for surround-view camera systems, multiple cameras also may feed video to displays inside the vehicle. “Here, it is the application requirements that drive the choice of E/E, including the total number of sensors and the bandwidth necessary to transfer the data,” he said. “This means the choice of communication technology is truly application-dependent. Low-speed functions must not use ‘over-engineered’ high-speed buses due to the cost, complexity, and power consumption of higher-speed devices. Certain technologies are point-to-point, while others support the efficiency of multi-drop nodes. Some high-speed links are symmetrical, supporting bi-directional communication between high-power compute nodes. In contrast, others are designed to be asymmetrical in support of applications that require high throughput in a single direction (e.g., camera output downstream, command and control upstream).
From domain to zonal architecture
ECUs are basic building blocks for vehicles. They control various functions such as engine operation, transmission, emergency braking, and other monitoring functions such as tire pressure and in-cabin climate control. Unlike a zonal architecture, a domain architecture groups various functions into domains without considering the physical location of those domains. In domain architectures, ECUs supporting each domain may be spread out within the vehicle. As a result, long cable harnesses may be needed to connect to these domains.
Traditionally, OEMs used domain architecture in their designs. The primary network protocols used in a domain architecture are the controller area network (CAN) and the local interconnect network (LIN), both of which have been used by OEMs to perform real-time control of various functions. CAN (ISO 11898-1:2003) is a serial network protocol that supports three different speeds:
CAN has proved to be dependable and relatively low cost for supporting distributed real-time control and multiplexing devices, including ECUs. LIN (ISO 17987-2), which complements CAN, is also a serial network protocol. It supports a lower data speed of 19.2 Kbit/s, and is typically used in cabin light control, such as dimming.
As the industry moves toward incorporating more software and electronics to support software-defined vehicles and autonomous driving, the demand for higher speed communication increases. While opinions vary, some experts suggest future autonomous driving would require data transfer speeds in the range of 50Gbps to support various real-time ADAS and ECU functions. Today, Ethernet is capable of 100 Gbps, with the potential of reaching tera bits per second in the next few years, according to the Ethernet Alliance.
This may change as new technologies and new features evolve. In recent years, automotive networks have been moving from domain-based to automotive Ethernet-based zonal architecture.
Amir Bar-Niv, vice president of marketing for automotive at Marvell, said the total weight of cable harnesses within an electrical vehicle rank just behind the weight of a car engine and chassis. Reducing the length and number of cables decreases a vehicle’s total weight, increases fuel efficiency (or range in an electric vehicle), and simplifies the manufacturing process.
There is an effort to simplify communications, as well. Currently, individual networks must support a range of bandwidth and a variety of different protocols. ADAS, for example, will drive the need to increase the bandwidth of the networking protocols.
Wireless communication can help, in part because much of this has been developed and refined outside of automotive. “Because wireless protocols are typically not automotive-specific, they will be further integrated to enable consumer electronic devices support,” said Bernhard Rill, director of automotive partnerships, automotive line of business at Arm explained. “Across the industry, there is work to determine how these wireless protocols can be used for future automotive-specific use cases. Cars use a large volume of networks today, spurring a trend to consolidate communication. There is a strong focus on networking when it comes to E/E architectures. Automotive OEMs are looking toward CAN-FD and Ethernet-based networks such as 10BASE-T1S. Furthermore, interoperable 2.5Gbps backbone Ethernet needs to be hardened for mass production usage, and high-speed connections will use PCIe for coherent silicon designs.”
Zonal versus domain architecture
The idea of zonal architecture that uses higher-speed Ethernet is gaining momentum because it is simpler and easier to manufacture compared with domain architecture. This technology approach uses multiple zonal switches to control various functions.
Fig. 3: In zonal architecture design, multiple zonal switches of different speeds are used to control various functions in a vehicle. Source: Keysight
The middleware stacks which sit between the operating system and the hardware will become increasing important in the zonal architecture, and many autonomous driving functions such as ADAS and emergency braking are performed by middleware. Quality of service is key in middleware, including the prioritization of mission-critical, real-time, and time-sensitive traffic over streaming of music.
Arm’s Rill sees clear indications that automotive E/E architectures will change to zonal moving forward. He noted that Arm is actively working with ecosystem partners to determine how zonal controllers can be used and what functions can be hosted there, including ADAS and digital cabin-related use cases in addition to body applications. “Given the long development cycles in automotive, the transition to zonal architecture will take time.”
The legacy factor
Nevertheless, with many of the legacy network protocols currently in use by OEMs, transforming to zonal architecture using Ethernet may be more difficult than it sounds. Any new design will need to function at least as well as the old ones after replacing the legacy protocols. The real challenge is implementing a smooth transition without impacting new product introductions. As a result, OEMs may have different degrees of zonal transformation and timetables.
“Most applications have a latency and/or payload requirement that support the vehicle’s operational aspects such as real time operation, e.g. LIN for high latency/low payload, Ethernet for low latency/high payload.,” said Ray Notarantonio, senior director for the vehicle user experience segment for the Americas at Infineon Technologies. In general, networks are sized to those needs, and this supports the best cost-to-performance ratio per application. It assures that networks are neither over nor under-utilized by design.
On the other hand, OEMs that plan to move to a software-defined vehicle approach will opt for a zonal architecture. “This heavy zonalization would include introducing a multi-Gb, highly engineered Ethernet backbone connecting more safety/security-oriented zonal modules, able to achieve a full isolation of systems, which are sharing the same physical resources,” noted Meindert van den Beld, senior vice president and general manager for In-Vehicle Networking at NXP.
As such, startups or new OEMs may have more flexibility in adopting a zonal architecture than OEMs with legacy designs.
“The introduction of zonal architecture strongly depends on individual OEM strategies,” said Sam Gold, director of product marketing for Renesas‘ High Performance Computing, Analog, and Power Solutions Group. “New players are freer to modify existing architectures, or are even able to start from scratch to implement new architecture concepts. On the other hand, established OEMs may face strong legacy dependencies and have a huge variety of car models with strong interdependence. This leads to the fact that only marginal or evolutionary changes of the network topology or architecture can be applied. The overall goal to reduce cost, complexity, and weight of the harness is shared by all OEMs. Here, also, the aspect of automated versus manual fabrication of the harness is a big cost factor.”
Zonal security concerns
Security remains a big concern in automotive, and while a zonal architecture in theory is easier to police, the transformation stage in which there may be a combination of CAN, LIN, Ethernet and other technologies can create new vulnerabilities. That means much more work on the part of OEMs to reduce the risk of cyber attacks.
“Complexity is the new normal as the automotive industry adapts to accommodate increasingly intricate displays and connectivity demands,” said Carrie Browen, autonomous vehicles business line product manager at Keysight. “As networks within the vehicle become faster and more intricate, they demand a higher level of testing to ensure consistent functionality. It’s not merely a luxury, but a necessity to ensure that every interface is safeguarded against cyber threats. With more connections in the car via CAN, Bluetooth, Automotive Ethernet, SerDes, wireless, cellular, for example, there is a greater chance for the corruption of information and as a potential threat interface. Therefore, compliance with regulations (ISO/SAE 21434 and UN-R155) and validation of the networks themselves are necessary during design, validation, and production.”
Infineon’s Notarantonio agreed. “Network security has been standard on vehicles for a number of years now. Messages are authenticated with hardware security modules and dedicated software in a secure domain. CAN and CAN-FD networks were among the first to add security, and this has only expanded since that time. Choices are being made today to protect new networks like Ethernet on vehicles, some select MACSEC other IPSEC, but nothing is left unsecured.”
At the same time, with more and more connectivity to the vehicle, automotive networks must be designed with mandatory cybersecurity risk management.
“OEMs should develop a defense in depth, but also enable crypto agility,” Renesas’ Gold said. “Defense in depth should take into consideration protection of the external vehicle communication (e.g., TLS, external I/F authentication) and protection of the internal communication (e.g., IDS/IPS, TLS, MACsec, IPsec, SecOC.) The security logs of the above protection mechanisms can be analyzed by a vehicle security operations center that can, if necessary, deploy security patches via firmware-over-the-air to mitigate the cyber threats to the vehicle automotive networks. Crypt agility should be considered to support automotive network protocol updates due to longer key length and/or cryptosystems being broken. Post-quantum crypto is under consideration as a next generation algorithm. Appropriate architectures should be defined to prevent security bottlenecks (e.g., distributed security processing).”
OEM adoption
While it is difficult to predict when exactly OEMs will be implementing 100% Ethernet networks, most OEMs are moving toward using Ethernet in current and future designs. Marvell’s Bar-Niv suggested that the adoption rate will accelerate over the next few years.
Fig. 4: Zonal architecture adoption is expected to accelerate over the next few years. Source: Marvell
In fact, adoption already has begun. BMW was among the first to incorporate Ethernet in its vehicles. In 2021, it introduced the Gigabit Ethernet in its production model BMW iX. Today, Ethernet is used in all production models.
Hyundai, like all other OEMs, reported that it uses the hybrid model of CAN and Ethernet. Its Kona and Santa Fe are examples of models using Ethernet to support OTA. Mercedes-Benz uses a combination of Ethernet and CAN/LIN. In 2013, its 222 (S-Class) models used CAN and LIN 2.1 for most controls while using Ethernet for the signaling lights. By 2020, Mercedes-Benz’s line of 223 (S-Class) models was using Ethernet for communication between major domains. Starting in 2024, Audi will introduce an entirely new E/E architecture (E3) based on the decentralized Premium Platform Electric, which will expand Ethernet technology using including a high-speed backbone.
While most OEMs are incorporating Ethernet in their designs, Toyota models do not support Ethernet at this time.
Meanwhile, U.S. OEMs are moving toward zonal architectures. “Part of the zonal approach is connecting the high-performance computing centers to all the functions that make a car a car, and doing it by integrating more functions into a single zone,” Infineon’s Notarantonio observed. “The integration can help with reducing material cost and wire harness complexity.”
Further, these OEMS are moving beyond simply adding a function, or adding an ECU, as this is a major contributor to wire harness and software complexity, he said.
In Japan, the goals are similar. But there, OEMs have selected domain-based architectures to build their vehicles. “In either instance, they allow for most updates in the central nodes and limited updates in zones or domains but software-defined vehicles are the future path to reduce software and wire harness complexity,” Notarantonio said.
Future vision
Based on what OEMs are doing today, it’s safe to assume that zonal architectures will continue to gain momentum. Besides simplifying the automotive design, a zonal automotive architecture creates new opportunities for the supply chain.
“A potential solution to reduce automotive network complexity, zonal architecture lets OEMs simplify wiring and communication pathways by organizing a vehicle’s electronic systems into zones, with each zone handling specific functions to achieve cost savings, increased efficiency, and improved reliability,” noted Mei Ching (Maggie) Lim, autonomous vehicle business line solution support at Keysight. “A primary objective, reducing cable harness weight and complexity, is at odds with the demand to increase data throughput using higher-speed communication technologies.”
Also, demanding communication channel operation over longer distances, using inline connectors to join multiple network segments, places strict requirements on electrical performance. “This means emerging standards must rigorously define permitted channel loss, and test methods must validate performance,” Lim said. “Application requirements determine the E/E architecture choice. Aggregating various sensors onto a single link to reduce cable weight and cost leads to higher throughput requirements. Increasing efficiency and reliability, as well as reducing weight, are significant drivers. However, whether the zonal architecture becomes predominant depends on a number of factors, including technological advancements, industry adoption, and the automotive ecosystem’s evolving needs. The level of autonomy, connectivity requirements, and cost considerations are factors. The industry is dynamic, and the evolution of automotive architecture will depend on ongoing technological developments and the successful implementation of these concepts in real-world applications.”
Additionally, zonal architectures promise scalability, in addition to ECU, network, and UTP/STP wiring consolidation, helping reduce overall costs compared with a distributed/domain-based architecture. “OTA software upgrades enable OEMs to provide additional features or services during a vehicle’s life cycle, and zonal architectures will significantly improve the OTA process,” Cadence’s Schweiger added.
Fig. 5: In the near future, domain and zonal architectures will coexist. Source: Infineon
While zonal architectures are widely considered to be the future, the transformation will take time. Some OEMs are charging ahead full speed, while others continue to support domain architectures. As a result, there likely will continue to be a mixture of network protocols used in automotive design for the foreseeable future.
Further Reading
For SDVs, Software Is The Biggest Challenge
Issues will grow exponentially as software-defined vehicles gain traction.
Automotive Complexity, Supply Chain Strength Demands Tech Collaboration
Relationships in the automotive ecosystem stretch to deep technical developments as the industry pivots to electrification and autonomy.
 |
 |
 |
 |
 |
 |
Leave a Reply