SSZTD02 Technical article

Madison Eaker

A zone architecture and Ethernet represent the future of networking in vehicles. New features in vehicles, as well as the shift to aggregating sensors and actuators into zonal modules, require a high-bandwidth and low-latency in-vehicle communication network. A zone architecture implementing Ethernet enables the growing trend of the software-defined vehicle.

Most vehicles today are built using a type of wiring and electronic control unit (ECU) architecture called a domain architecture. A domain architecture categorizes ECUs into domains based on specific functions, regardless of their physical location in the vehicle.

A zone architecture, in contrast to a domain architecture, organizes communication, power distribution and load control by location rather than by function, as shown in Figure 1. A zonal module behaves as a network data bridge between the vehicle’s computing system and local edge nodes like smart sensors and ECUs. To reduce cabling in the vehicle, a zonal module will also distribute power to different edge nodes (by implementing semiconductor smart-fuse capabilities), handle low-level computing and drive local loads like motors and lighting.

Figure 1 Example of a zone architecture

Zonal modules transfer data from various sensors and ECUs through an edge-node communication network and forward the combined sensor data to the central computing system through backbone communication. Similarly, the zonal modules transfer data received from the central computing system to various actuators, again through backbone communication, again through an edge-node communication network. This two-way communication between the central computing system and the zonal modules requires a high-bandwidth and low-latency communication backbone to handle the large amount of data generated by functions like multiple advanced driver-assistance system (ADAS) cameras, vehicle motion control and adaptive driving beams.

Bandwidth requirements in a zone architecture

To understand the value of using Ethernet in vehicles, let’s break down Ethernet use by application. The newly defined Single Pair Ethernet (SPE) supports speeds from 10 Mbps to 10 Gbps, defined through IEEE 802.3cg (10 Mbps), IEEE 802.3bw (100 Mbps), IEEE 802.bu (1 Gbps) and IEEE 802.3ch (10 Gbps). All of these new Ethernet technologies work over a single-pair cable and can communicate at distances as far as 15 meters, which is long enough to cover the longest link in a vehicle. Ethernet can also enable the time synchronization of sensor data using IEEE 802.1AS timestamping to achieve low latency.

While Ethernet is capable of extremely fast speeds, these speeds are not necessary in every context. For example, communicating with the door control module or the heating, ventilation and air-conditioning system does not require a 100-Mbps data rate. A 10-Mbps Ethernet PHY or alternative network protocol like Controller Area Network (CAN) is better for lower-speed and less bandwidth-intensive use cases, while it is better to reserve higher speeds for sending aggregated camera and autonomous-driving sensor data from the zonal modules to the central computing system. Figure 2 shows where to use different speeds of Ethernet in a zone architecture.

Figure 2 Ethernet in a zone architecture

Using Figure 2, let’s take a closer look at the communication speeds used for radar, LiDAR, camera and body applications. Typically, CAN is used to communicate radar data to the zonal module if the radar system-on-chip (SoC) performs the first level of data processing. Sending raw data to the central computing system for processing will extract more information through sensor fusion of various radar sensors. The transmission of such a large amount of raw data requires a higher bandwidth, creating a space for 100-Mbps to 1-Gbps Ethernet in radar and LiDAR.

For cameras, Flat Panel Display (FPD)-Link is the most appropriate protocol when a level of increased ADAS data requires all of the raw data from the front camera for post-processing.

If it is possible to compress the data from the front camera and you don’t need this increased level of ADAS data, 100-Mbps Ethernet is an alternative.

Body-domain modules like door-handle sensors, window-lift control modules and side-mirror control modules traditionally use the CAN and Local Interconnect Network (LIN) protocols to communicate, as a high bandwidth is not required. While designers will continue to use CAN and LIN, the increased use of Ethernet in vehicles also creates a place for 10-Mbps 10Base-T1S multidrop Ethernet. Ethernet is traditionally a point-to-point topology, but 10Base-T1S Ethernet is the first Ethernet standard enabling functionality over a bus topology.

Multi-gigabit Ethernet in a zone architecture

What is the potential evolution of the zone architecture? It begins with aggregating body-domain data, incorporating power distribution and centralizing computing. Over time, zone architectures will start aggregating data from other domains like ADAS. The end goal is to incorporate all domains into the zone architecture. Regardless of which domain the data belongs to, the zonal module and central computing system will still use the same backbone communication network to transfer data.

Body-domain functions require only 10 Mbps or less. But as ADAS functions like radar, LiDAR and cameras become incorporated into the zone architecture, the speed and bandwidth requirements must increase to accommodate the amount of sensor data. A radar sensor typically generates 0.1 Mbps to 15 Mbps. LiDAR generates 20 Mbps to 100 Mbps. Cameras generate the most: 500 Mbps to 3.5 Gbps. Today’s vehicles typically have four to six radar sensors, one to five LiDAR sensors and six to 12 cameras. If you consider the zone architecture, one zonal module could have two radar sensors, two LiDAR sensors and four cameras. Figure 3 shows how much data is generated by each sensor and the data generated when combining all of these sensors into one example zonal module.

Figure 3 Data generated in a zone architecture

It is the total data being generated that is causing the push for 2.5-Gbps, 5-Gbps and 10-Gbps Ethernet among original equipment manufacturers (OEMs). The zone architecture needs a backbone communication network capable of transmitting the enormous amount of data produced by ADAS sensors to the central computing system. Uncompressed camera data already goes beyond current Ethernet capabilities, and cameras continue increasing in resolution and pixel count. As vehicles continue toward autonomy, the number of sensors will increase. Thus, the bandwidth required to support increased camera resolution and sensors will grow correspondingly.

The Ethernet speeds that OEMs are requesting most likely differ because of the transition schedules for incorporating different functions into the zonal module. Overall, the more ADAS functions in zonal modules, the higher the bandwidth requirements.

Using Ethernet as the backbone for a zone architecture allows vehicles to transfer more data over the in-vehicle network when connecting to the internet or remote OEM servers. This enables subscription-based services and vehicle diagnostics through remotely performed firmware-over-the-air (FOTA) updates. FOTA updates allow for different hardware and software update cycles, which can be asynchronous as a result of the independence of sensors and actuators from the central computing node. A FOTA update can also push additional features and safety improvements instead of waiting for a new model or having to bring the vehicle in to be worked on. Both the OEM and the customer benefit, as the OEM has control over updating the vehicle with additional features after launch, and the consumer is less inconvenienced by trips to a dealer to update firmware.

PHYs in a zone architecture

Ethernet requires the use of PHYs to transmit and receive high-speed data. Automotive Ethernet PHYs eliminate many of the concerns with Ethernet as the backbone of the wiring in vehicles, such as poor signal quality in such a volatile environment. Ethernet PHYs from Texas Instruments (TI) are capable of operating at a range of temperatures from –40°C to 125°C, in compliance with AEC-Q100 Grade 1 standards.

Ethernet PHYs also have to pass Ethernet compliance standards, ensuring that they meet certain interoperability and reliability standards regarding electromagnetic compatibility and electromagnetic interference, as well as IEEE conformance as specified by Open Alliance TC1 and TC12 standards, to work in a vehicular environment. With advanced diagnostic features like signal-quality indication, time-domain reflectometry and electrostatic discharge (ESD) sensors, PHYs are capable of detecting when errors occur and can adjust accordingly. For example, in the event of ESD, the PHY sends an interrupt signal to the SoC/Media Access Control to alert it of the event and then checks other parts in the system.

Ethernet PHYs can also wake up remote ECUs over the SPE cable using the Open Alliance TC10 specification’s wake and sleep technology, which eliminates the need for a separate wire to wake the ECUs from sleep. IEEE 802.1AE Media Access Control Security (MACsec) could also be an important technology to enable the authentication of networking ECUs and to encrypt/decrypt data to avoid cyberattacks, as cyberattacks represent the biggest threat to automotive networking.

TI’s DP83TC812-Q1 and DP83TC814-Q1 100BASE-T1 PHYs have the next-generation features desirable in luxury vehicles, while the smaller DP83TC813-Q1 100BASE-T1 PHY may be appealing in situations when printed-circuit–board space is at a premium. The DP83TG720-Q1 can connect zonal modules to data-intensive features like the central computing system and telematics control unit, leaving headroom for the inclusion of additional features in later models without making intensive changes to the wiring harness. Combined, these PHYs open the door for more advanced and capable vehicles on the road.