From wires to software: How an ethernet backbone reshapes vehicle architecture

By: Yong Kim, Distinguished Systems Engineer - Embedded Platform and Gary Cygan Jr, Director of Vehicle Software and Electronics Engineering

Modern vehicles need more than faster networks. Higher bandwidth alone does not deliver the determinism, scalability, and software flexibility that modern vehicle architectures require. They need cleaner boundaries between hardware, software and connectivity. Automotive Ethernet has been available to original equipment manufacturers (OEMs) since 2004, but it became a practical architectural foundation only after open international standards matured and suitable Ethernet physical-layer devices (PHYs) arrived around 2008.

In parallel, Time Sensitive Networking (TSN) introduced deterministic, time-aware capabilities that provide latency and bandwidth guarantees. With TSN support, Ethernet can create virtual wires that preserve the essential end-to-end behavior of dedicated physical connections, including predictable propagation delay and delivery jitter.

Those capabilities turned Ethernet from a communications technology into the backbone for a new kind of vehicle architecture-one that can separate software from hardware while supporting the deterministic performance modern vehicle systems require.

This blog explores why that shift matters, how Ethernet and TSN enable it, and why clean abstraction is becoming central to modern vehicle design. It also examines the architectural choices behind distributed and centralized models, and why GM believes a centralized compute approach creates a stronger foundation for future software-defined vehicles.

Zonal motivation

Traditional domain-based electrical architectures served the industry well for many years. Most vehicle functions could be developed and managed within well-defined domain boundaries, with each domain handling its own hardware, software, and data. But that separation has become harder to maintain. Advanced driver assistance systems (ADAS) and automated-driving features depend on data from sensors and actuators across the vehicle. Infotainment systems are also more tightly connected to cloud services, connectivity features, and vehicle controls. Even body systems such as doors, windows, lighting, locks, and seats have become more sophisticated and increasingly need to share data and coordinate behavior across domains.

As those demands increase, the central gateway that connects domains becomes either more complex or limiting. It must support increased traffic, coordination, and cross-domain interaction, or it begins to constrain services such as sensor sharing and broader system integration. In that environment, the traditional domain model starts to lose the simplicity that once made it effective.

That is one reason the industry has moved toward zonal thinking. Instead of organizing the vehicle primarily around functional domains, zonal architectures aggregate input/output (I/O) based on physical location in the vehicle and use the network backbone to connect that I/O to compute resources. This creates a more flexible structure for managing sensors, actuators, and other endpoints as vehicle complexity continues to grow.

Distributed or central?

Once zonal aggregation is introduced, the next question is where compute should live. Some architectures pair zonal I/O with distributed compute, while others use zonal aggregation to feed a more centralized compute model. Both approaches can be made to work. In a distributed zonal architecture, much of the relevant I/O attaches directly to compute in its local zone. In a centralized model, I/O is aggregated in the zones and carried over the network to central compute.

The more important question, however, is which architecture creates the cleanest abstraction between I/O, compute hardware, and systems software. A distributed model can still introduce significant complexity because applications often need access to both local and remote resources. A door-control function, for example, may reside in one zone but still require coordinated access to all doors across the vehicle. Once applications span zones, the system must manage both local and remote compute interactions as well as local and remote I/O dependencies.

A centralized approach can provide a cleaner abstraction. When the network behaves like a set of deterministic virtual wires, I/O can be separated from the compute that consumes it. That gives hardware, systems software, and applications more freedom to evolve independently, without forcing unnecessary changes across neighboring components. In practice, there will always be a category of functions that are not in scope, such as local reflex functions such as pinch detection and handling. But as a broader architectural principle, cleaner abstraction creates a stronger foundation for scale, modularity, and faster iteration.

A distributed zonal architecture can initially appear to be a set of central-compute architectures with an added layer of aggregation. But that view is incomplete. While most I/O remains local to its zone, some applications still need access beyond it. A simple ingress-control function for all doors, for example, might reside in the compute of one zone, while still requiring control access across the entire vehicle (see diagram below).

That is where the complexity of a distributed model becomes more apparent. Once applications must interact with both local and remote resources, the architecture has to manage not only local and remote compute, but also local and remote I/O.

A central zonal model offers a cleaner abstraction. It separates compute hardware, I/O, and systems software more clearly, allowing the network to act like a set of deterministic virtual wires between them as shown at the right. In practice, there will always be exceptions, including local reflex functions such as pinch detection and handling. But as a broader architectural approach, that cleaner abstraction creates a more stable interface, allowing each layer to innovate and iterate with less impact on neighboring systems.

Argument for the central and clean abstraction

When a domain-based architecture that served the industry for decades no longer meets modern vehicle requirements, the next architecture must begin with clean, well-defined interfaces. These interfaces create the necessary separation between hardware, software, and networking layers, allowing each to evolve, optimize, and innovate more independently.

The importance of clean abstraction also increases as an architecture is scaled across a broader vehicle portfolio. For a single vehicle program, abstraction is less critical because reuse is limited and the solution only needs to support one product. For a portfolio as diverse as GM's - spanning multiple segments, propulsion types, and vehicle architectures - clean abstraction becomes essential. It enables software reuse across programs, reduces integration complexity, and supports faster delivery of higher-quality features at enterprise scale.

This is a key factor in our architectural direction and why we place a higher priority on abstraction than organizations supporting smaller portfolios or more narrowly scoped product lines. Our objective is not simply to build a great software-defined vehicle, but to build a software-defined platform that can efficiently power every GM vehicle. By establishing the right interfaces today, we create a foundation where capabilities can be developed once, deployed broadly, and continuously improved over time - delivering greater speed, quality, and value to every GM customer.

General Motors' central compute approach

GM plans to launch its new centralized electrical architecture and compute platform in 2028, supporting both electric- and gas-powered vehicles. Debuting first on the Cadillac ESCALADE IQ, the new architecture represents a fundamental shift in how GM vehicles are designed, connected, and updated over time. By centralizing more functions on a common platform, GM aims to unlock greater performance, scalability, and software efficiency.

At the core of the new platform is a unified computing system that consolidates dozens of electronic control units and coordinates vehicle subsystems in real time. Connected through a high-speed Ethernet backbone, systems including propulsion, steering, braking, infotainment, and safety can work together more seamlessly. The result is an architecture designed not just to support today's vehicle functions, but to adapt more effectively as software capabilities continue to expand.

For customers, that can mean more frequent software updates, faster delivery of new features, and significantly greater bandwidth for connectivity, entertainment, and future AI-enabled experiences. For engineers, it creates the opportunity to build software and vehicle systems on a more capable, scalable foundation - one designed to support real-time intelligence, faster iteration, and continuous improvement across millions of vehicles.