Vehicle Networking Ethernet Accelerates the Transition to Software-Defined Vehicles

From Madison Ecklund * | Translated by AI 9 min Reading Time

Zone architectures and Ethernet are shaping the future of networking in vehicles. In view of the fact that new vehicle features, such as the bundling of sensors and actuators in zone control units, rely on a broadband and low-latency on-board communication network, an Ethernet-based zone architecture enables the implementation of the increasing trend towards software-defined vehicles.

Thanks in part to advances in the field of automotive Ethernet, car manufacturers can equip their vehicles with a wider range of functions.(Image: Texas Instruments)
Thanks in part to advances in the field of automotive Ethernet, car manufacturers can equip their vehicles with a wider range of functions.
(Image: Texas Instruments)

In most of today's vehicles, the wiring and electronic control units (ECUs) are structured in a domain architecture. The ECUs are grouped according to their respective functions—regardless of where they are installed in the vehicle.

In contrast to a domain architecture, the communication, power distribution and control of the individual consumers in a zone architecture are not organized according to their function, but depending on their arrangement in the vehicle (see Figure 1). A zone control module acts as a network data bridge between the computer system of the entire vehicle and locally positioned edge nodes, which include smart sensors and ECUs, for example. In order to reduce the amount of cabling in the vehicle, a zone control module not only distributes the power supply to the individual edge nodes (by implementing smart fuses with semiconductors), but also performs basic computing functions and controls local consumers such as motors and lighting elements.

Figure 1: Example of a zone architecture(Image: Texas Instruments)
Figure 1: Example of a zone architecture
(Image: Texas Instruments)

Zone control modules receive data from the various sensors and ECUs via an edge node communication network and forward the collected sensor data to the central computer system via a backbone communication network. Conversely, the zone control modules forward data that they receive from the central computer system to the various actuators. This also takes place via the backbone network and the edge node communication network. The bidirectional communication between the central computer and the zone control modules requires a broadband, low-latency communication backbone to handle the large amounts of data generated by functions such as multiple ADAS sensors, in-vehicle motion control and adaptive driving light systems.

How Much Bandwidth Do Zone Architectures Need?

In order to understand the benefits of Ethernet networks in vehicles, the individual applications will be broken down below. The recently defined single-pair Ethernet supports bandwidth requirements between 10 Mbit/s and 10 Gbit/s according to the IEEE standards 802.3cg (10 Mbit/s), 802.3bw (100 Mbit/s), 802.bu (1 GBbt/s) and 802.3ch (10 Gbit/s). All of these new Ethernet technologies are based on a single-pair cable and support transmission distances of up to 50 ft, which is sufficient for even the longest connections in a vehicle. Furthermore, Ethernet enables time synchronization of sensor data through timestamping via IEEE 802.1AS to achieve low latency.

Ethernet enables extremely high transmission rates, but these are not absolutely necessary in every context. For example, communication with a door control module or the heating, ventilation and air conditioning system does not require a data rate of 100 Mbps. A PHY designed for 10 Mbit/s such as the DP83TD555J-Q1 or an alternative network protocol such as CAN is better suited for applications with lower transmission rates and less bandwidth requirements, while the higher transmission rates are reserved for transmitting bundled camera data and sensor data for autonomous driving between the zone control modules and the central computer system. Figure 2 shows where the different transmission rates are used in a zone architecture.

Figure 2 provides a closer look at the transfer rates used for radar, lidar, camera and body applications. When a radar or lidar SoC processes its data, the data is usually transferred to the zone control module via CAN or Ethernet (10 or 100 Mbit/s). If the data processing only takes place on a first or second level, the radar or lidar data is transferred to the zone control module or the central computer via Ethernet at 100 Mbit/s or 1 Gbit/s. However, as soon as the unprocessed radar or lidar data is transferred to the central computer for further processing, more information can be extracted by merging data from several sensors. However, the transfer of this very extensive raw data requires more bandwidth, usually with a SerDes protocol or 2.5 Gbit/s plus Ethernet.

Figure 2: Ethernet use in a zone architecture(Image: Texas Instruments)
Figure 2: Ethernet use in a zone architecture
(Image: Texas Instruments)

In the case of cameras, a SerDes protocol such as FPD-Link is the best choice if the entire volume of raw data from the front camera needs to be transmitted for further processing for driver assistance functions. If it is possible to compress the data from the front camera and the increased volume of ADAS data is not required, Ethernet at 100 Mbit/s is an alternative.

For modules in the body domain, such as door handle sensors, window regulator control modules or exterior mirror control modules, the CAN or LIN protocol is traditionally used for communication, as neither requires a large bandwidth. CAN and LIN will continue to be used, but the increasing use of Ethernet in vehicles also opens up opportunities for multidrop Ethernet (10BASE-T1S with 10 Mbit/s). Although Ethernet is traditionally a point-to-point topology, 10BASE-T1S is the first Ethernet standard that is suitable for a bus topology.

Subscribe to the newsletter now

Don't Miss out on Our Best Content

By clicking on „Subscribe to Newsletter“ I agree to the processing and use of my data according to the consent form (please expand for details) and accept the Terms of Use. For more information, please see our Privacy Policy. The consent declaration relates, among other things, to the sending of editorial newsletters by email and to data matching for marketing purposes with selected advertising partners (e.g., LinkedIn, Google, Meta)

Unfold for details of your consent

Multi-Gigabit Ethernet in A Zone Architecture

How will zone architectures potentially evolve? It will start with pooling data from the body domains, including the power supply, and centralizing computing resources. Over time, the zone architectures will then start to bring together data from other domains such as ADAS and infotainment. The ultimate goal is to integrate all domains into the zone architecture. Regardless of which domain the data belongs to, the zone control module and the central computer system use the same backbone network for its transmission. Audio functions are a prime candidate for relocation to zone control modules, as audio video bridging standards make it possible to transmit audio data via Ethernet.

Body domain functions usually get by with 10 Mbit/s or less. However, when ADAS and on-board infotainment functions such as radar, lidar, audio and cameras are incorporated into the zone architecture, the speed and bandwidth requirements increase and the topology of the Ethernet backbone may change from a star to a ring structure to accommodate the large amount of safety-critical and time-sensitive sensor data.

Audio generates around 1.5 Mbit/s per channel, a radar sensor between 0.1 and 15 Mbit/s and lidar between 20 and 100 Mbit/s. For cameras, the values are between 500 Mbit/s and 3.5 Gbit/s. Modern vehicles are usually equipped with four to six radar sensors, one to five lidar sensors, 15 to 20 loudspeakers, 12 to 16 microphones and six to twelve cameras. Table 1 provides an overview of the data volume of the various sensors.

Table 1: Data volume in a zone architecture(Image: Texas Instruments)
Table 1: Data volume in a zone architecture
(Image: Texas Instruments)

It is this large volume of generated data that is prompting car manufacturers to switch to Ethernet at 2.5, 5 and 10 Gbit/s. A zone architecture requires a backbone communication network that can handle the enormous amounts of data that need to be transferred from ADAS sensors to the central computer. Uncompressed camera data already exceeds the capabilities of current Ethernet technology, and the resolution of the cameras continues to increase. The more vehicles are developed in the direction of autonomous driving, the more sensors are installed in them, so that the bandwidth requirements of the on-board networks increase accordingly.

The Ethernet transmission rates demanded by car manufacturers are likely to vary, as each manufacturer has its own plans for moving the various functions to the zone control module. Audio playback via the built-in speakers is likely to be one of the first cross-zone data types to be moved to the Ethernet backbone. This could be due to the comparatively low data volumes, as 20 audio channels only generate around 30 Mbit/s, meaning that an existing Ethernet backbone with 100 Mbit/s or 10 Gbit/s can easily cope with this audio data. Overall, the more functions with high data volumes are transferred to the zonal control modules, the greater the bandwidth requirement.

Ethernet as a backbone for a zone architecture enables vehicles to transmit more data via the on-board network when connected to the internet or the car manufacturer's servers. Subscription-based services or vehicle diagnostics can thus be implemented via firmware over-the-air (FOTA) updates. FOTA updates enable different update cycles for hardware and software, which can be carried out asynchronously thanks to the independence of the sensors and actuators from the central computer. FOTA updates can also be used to push additional features and safety improvements so that there is no need to wait for a model change or visit the workshop. This benefits manufacturers and end consumers alike: manufacturers can continue to upgrade their vehicles with additional features after delivery, while customers are spared the need to visit the workshop for firmware updates.

PHYs in A Zone Architecture

Ethernet requires PHYs to send and receive high-speed data. Ethernet PHYs designed for automotive applications eliminate many concerns about using Ethernet as a backbone in vehicles, such as poor signal quality in such a volatile environment. Texas Instruments Ethernet PHYs can operate at temperatures between −40°F to 260°F, which meets the requirements of AEC-Q100 Grade 1.

In addition, Ethernet PHYs must comply with Ethernet conformance standards to ensure that they meet interoperability and reliability requirements for electromagnetic compatibility (EMC) and electromagnetic interference (EMI). The same applies to IEEE conformity in accordance with Open Alliance TC1 and TC12 for use in vehicle environments. Advanced diagnostic features, including signal quality indication, time domain reflectometry and electrostatic discharge detection sensors, allow PHYs to detect and identify faults to enable the host system to respond proactively. For example, should an electrostatic discharge occur, the PHY sends an interrupt signal to the SoC and the Media Access Controller (MAC) and then checks other parts of the system.

Ethernet PHYs can also wake up remote ECUs over the single-pair Ethernet cable using Open Alliance TC10 wake and sleep technologies, eliminating the need for separate wires. IEEE 802.1AE Media Access Control Security (MACsec) can also be an important technology to support the authentication of network ECUs and the encryption and decryption of data to defend against cyber attacks. After all, cyber attacks are the biggest threat to vehicle networks.

Ethernet PHYs from TI

The DP83TC812-Q1, DP83TC815-Q1 and DP83TC814-Q1 100BASE-T1-PHYs are designed for luxury vehicles, while the smaller DP83TC813-Q1 100BASE-T1-PHY may be of interest for applications where PCB space is at a premium. The DP83TG720-Q1 and DP83TG721-Q1 can connect zone modules to data-intensive features such as the central computer system or the telematics control unit, which creates space for the integration of additional features in later models without having to make major changes to the cabling.

The portfolio of single-pair Ethernet PHYs is designed for footprint or pin compatibility with the company's 100BASE-T1 and 1000BASE-T1 PHYs. The use of a standardized PCB design allows the feature set or bandwidth to be upgraded in later versions without changes to the hardware. This concept allows development cycles to be shortened, the requirements of different car manufacturers to be met and time-to-market to be reduced, thereby lowering research and development costs.

The 10BASE-T1S Serial Peripheral Interface MAC PHY DP83TD555J-Q1 integrates into existing Ethernet backbones, eliminating the need for protocol converter gateways with their latencies and processing overhead when connecting traditional CAN/LIN edge nodes. Thanks to its support for Power over Data Line, the device can use the same twisted pair cable for data transmission and power supply, reducing cable weight and system costs. The built-in PHY Collision Avoidance also provides deterministic scheduling with guaranteed transmission opportunities for each network node, ensuring predictable communication timing. The larger payloads of the Ethernet frames allow larger amounts of data and more diverse data types to be extracted from the ECUs on the periphery of the vehicles, enabling advanced diagnostics and over-the-air updates while maintaining real-time characteristics. (se)