The car becomes a data center on wheels

This is the first of a two-part series on the evolution of automotive networks

By: Yuichi Motohashi, Deputy Director of End Markets

The automotive industry is being reshaped by the Software-Defined Vehicle (SDV), a car whose functions and value are defined by software and continuously expanded even after sale through over-the-air (OTA) updates, much as a smartphone gains features after purchase. Delivering those updates forces a rethink of the in-vehicle electrical/electronic (E/E) architecture where computing must be consolidated into a small number of high-performance platforms so that hardware and software can be developed and evolved independently.

The conventional distributed architecture includes anywhere from tens to more than a hundred function-specific ECUs, each running a different supplier’s software which makes consistent, vehicle-wide updates difficult. A second force here is sensor fusion. As ADAS and autonomous driving mature, cameras, radar, LiDAR and ultrasonic sensors increasingly stream RAW or lightly-processed data to a central platform for integrated processing, rather than each reporting only its own local decisions. Both trends demand more bandwidth and more centralized computing, turning the modern car into a “data center on wheels.” This two-part series maps that evolution, from Distributed to Domain to Zonal architectures, tracking sensor, data format, SoC and network changes along the way while showing how SerDes and Ethernet get applied and eventually converge.

Distributed E/E: A forest of ECUs

In the first generation, ECUs were distributed per function and operated largely independently. Sensors were typically “smart sensors” co-located with their processing, so the network carried only low-bandwidth, processed information such as object-recognition results, distance, speed and warnings. Alongside CAN, LIN and FlexRay, 100 Mbps-class automotive Ethernet (100BASE-T1, IEEE 802.3bw) was enough to support many applications. But because functions and ECUs were tightly coupled, every new feature added ECUs, wire harnesses and software variants making whole-vehicle integration, updating and verification progressively harder. This was the essential limitation of the Distributed approach.

Domain E/E: Consolidation by function

To curb that complexity, the Domain architecture groups function into large areas including ADAS/AD, infotainment, body, chassis and powertrain. Each of these functions are managed by a Domain Control Unit (DCU) on a more powerful SoC, with a central Gateway relaying data between domains. This complexity heightened with the rise of advanced ADAS. Surround view, bird’s-eye-view generation, parking assistance and sensor fusion require treating the vehicle’s surroundings as a single integrated environmental model rather than isolated sensor outputs.

The role of sensors changed accordingly. With recognition moving to the DCU, cameras, LiDAR and radar became “satellite sensors” that output RAW or lightly processed streams. The meaning of “RAW or lightly processed” differs by sensor: camera data may be image RAW or video around the ISP, LiDAR may output point clouds or distance/intensity data and radar may range from ADC-level data to range/Doppler or detection points. To carry these high-bandwidth streams with low latency, CAN and 100 Mbps Ethernet were no longer sufficient. SerDes, already proven in camera and display links, became the high-speed, low-latency point-to-point connection from sensor to DCU. Domain E/E, however, still consolidates by function rather than physical location, so long cables still run from front, rear, left and right to distant DCUs, which pushes the industry toward Zonal.

Zonal E/E: Bundle by location, think at the center

Zonal E/E is often called the completed form after Domain, but in practice it is an ongoing, gradual migration. Instead of consolidating by function, it bundles I/O by its physical location, either front, rear, left/right and center. A Zone Controller in each zone gathers the nearby sensors, actuators and low-speed I/O and forwards what’s needed to a central Vehicle Controller or Central Computer.

During the transition, a Hybrid Zonal design dominates. Local, low-speed I/O such as lighting, doors, seats and HVAC consolidates into the nearest Zone Controller, where multidrop 10BASE-T1S (IEEE 802.3cg) suits the Zonal edge alongside CAN/LIN. High-bandwidth sensors like cameras, LiDAR and high-definition radar often connect directly to the Central Computer via SerDes, avoiding the bandwidth, power and complexity burden of relaying heavy streams through a Zone Controller. The biggest payoff is wire-harness reduction. Short links to a nearby Zone Controller, combined with a high-speed backbone to the center, cut total cable length, connector count and weight, while also reducing parts, assembly effort and points of failure. That’s especially valuable in EVs, where weight affects range.

This presents a larger question: why choose Ethernet for that backbone? Because the section connecting multiple Zone Controllers, the Central Computer, gateways and diagnostic/update functions is a true network, not a single point-to-point line. Ethernet brings mature TCP/IP, switching, addressing, diagnostics, security and network management, while Time-Sensitive Networking (TSN) and time synchronization add real-time determinism. It also aligns naturally with SDVs by separating hardware placement from software function. That leaves one question for part 2: how does the high-bandwidth, asymmetric sensor links, which is the domain of SerDes, combine with this Ethernet/IP backbone?