Is the automotive industry SDV-ready?
Trends in electronics hardware for software-defined vehicles
Software-defined vehicles (SDV) are shifting differentiation from mechanical performance and feature content at start of production to software capability over the vehicle life, delivered through frequent updates, feature activation, and continuous improvement.
That shift has a direct hardware consequence: while still able to serve basic vehicles, distributed ECU architectures still used today were not designed for changes in software once the platform was fixed and the vehicle had entered the market. Now, many OEMs are migrating the software in existing ECUs to a larger controller with high performance computing capability and using zonal E/E architectures to communicate with the decision-making computer and edge sensors and actuators over high-bandwidth buses (increasingly Ethernet).
This article reviews the key hardware building blocks required to support an SDV and how zonal and centralized architectures enable efficient OTA and digital experiences. It also examines how OEMs are adopting different business models to execute the transition. Finally, it considers how propulsion mix (BEV vs. ICE/HEV/PHEV) and portfolio breadth can constrain hardware roadmaps, forcing parallel »new and old architecture« decisions for legacy automakers.
What is a software-defined vehicle?
While the phrase SDV is now well established, it’s actual meaning and especially how it can be measured will differ. S&P global offers its definitions – developed to be able to both characterize and quantify SDV-readiness by different OEMs with different vehicles – as a combination of a company’s software capability, the hardware type deployed and degree of over-the air updatability. S&P Global tracks all these aspects and can combine datasets to provide a vehicle score and »SDV Readiness« ranking (see table).
Table showing a ranking of leading SDV brands in 2026 as measured using a scale with a level from 1 up to a maximum of 5. The ranking was developed by S&P Global and is based on a combination of software capability, hardware type and degree of over-the air updatability.
This ranking table balances certain criteria to determine how vehicle architecture, software integration, cybersecurity, and OTA capability are implemented in production programs. Briefly, the benchmark evaluates E/E architecture type, backbone network, zonal controller configuration, degree of unified Auto operating system (OS) maturity, domain-level service orientation, cybersecurity depth across ECU and backend layers, and vehicle-wide OTA authority.
Examining the ranking, the obvious takeaway is the domination of start-up EV makers from China like Nio, LI and Xpeng and North America like Tesla, all of which are reaching SDV levels of at least 4 and even 5 as of March 2026.
What is interesting is that among the incumbents in this list, Volvo is positioned second place after Nio with level 5. Both these companies score very high in the SDV index based on the combinations of efficient software and hardware design, in addition to advanced OTA, for example, to provide updates based on fleet-learning to consistently develop and distribute new features to new and equipped on-the-road vehicles on a regular cadence. Both have advanced hardware and appropriate efforts on continual software innovation.
Volvo’s first vehicle with a ranking of SDV 5 will come in the early part of 2026 with the EX60, which launches with a central computer and advanced zones (e.g. managing a mix of non- and safety-critical cross-domain functional control) on what its calls its Generation 2 SDV platform. Volvo has shifted focus to software. Like Nio and Tesla, it pools fleet data it has collected to develop and pump-out new features to vehicles in the market via OTA.
Among the other legacy players, BMW enters the list at SDV level 4 based on its new NK platform vehicles that began to launch in October 2025, and which feature hardware and software upgrades compared to previous platforms.
Parameters developed by S&P Global Mobility for the determination of a level of »SDV-readiness« at an OEM.
Core SDV building blocks in hardware
SDV-enabling E/E architecture hardware consolidates into fewer, larger ECUs the compute and software control algorithms that were earlier housed in smaller, distributed ECUs. The main blocks are:
Domain controllers: Master controllers with more processing power than ECUs coordinate several ECUs in a common domain like chassis or body. In E/E terms these controllers elevate simple distributed architecture ECU to “domain architecture” that reflects increased communication complexity and data processing requirements, e.g., from ADAS sensors or advanced cockpits. Domain controllers can deploy silicon microprocessors or MCUs based on the type of data to be handled.
Zone controllers: ECUs that are physically located in vehicle areas like left and right doors or front and back to aggregate local CAN and LIN I/O signals from “edge networks” (sensors, actuators, etc.). Zone ECUs forward the aggregated data over a single cable to the main decision ECUs, whether domain controllers or already a central computer. Zones have one or more MCUs for local management and can also support the main domain controllers to offload processing demands and can also provide local electrical management and power distribution – a key feature of harness optimization. EE architecture with zone controllers is called zonal architecture and is a significant departure from the distributed and domain type designs.
Central computers: a more aggregated ECU combining at least two domains is called a central computer. A central computer will usually deploy one or more high-performance microprocessors (systems-on-chip or SoC) depending on the domain coverage and typically (but not always) host infotainment and ADAS workloads and enable more centralized decision-making and orchestration.
In practice, efficient SDV architectures will be supported by zonal architecture, although some Japanese OEMs may forgo zonal designs while still developing SDV functionality.
The diagram shows the adoption of zonal architecture as the significant hardware in support of efficient SDV designs.
The adoption of zonal architecture as a key building block of future efficient SDV-ready vehicles.
How does zonal architecture support the design of an SDV?
Zonal architecture is frequently described as a wiring and ECU reduction strategy; equally important, it is a data distribution and software deployment strategy. As OTA penetrates deeper into the vehicle, more endpoints require secure update capability, consistent diagnostics, and reliable rollback. A zonal approach simplifies deployment by moving complexity into a smaller number of powerful nodes closer to the endpoints—reducing update coordination overhead.
Other key advantages comprise efficient data distribution via high-speed backbones that are increasingly based on Ethernet and that can carry aggregated sensor data and control messages between zones and central compute with less protocol translation. And by aggregating I/O and relocating compute from edge modules to zonal controllers or central computers, OEMs can reduce the number of existing ECUs, connectors, and harness branches.
One trade-off is that domain/HPC compute and Ethernet backbones can be expensive. Cost, redundancy requirements, thermal design, and manufacturing complexity rise—particularly challenging for OEMs with large, price-sensitive segments. Indeed, it is possible to see that while some OEMs make demonstrable progress towards SDV-readiness, ambitious E/E roadmaps of other car makers have suffered at the hands of these challenges, and not least from issues like company structure, legacy portfolio and overall culture. We illustrate these aspects with examples of how some manufacturers have differed in their business models.
To make or to buy?
OEMs are increasingly deciding that SDV hardware—and the software stack that sits on it—is too strategic to outsource entirely. But the market shows several viable models, each with different risks and timelines.
Nio is an example of a company that develops everything in-house, similar to Tesla or Rivian. Nio’s 2022 domain architecture ranked as an SDV level 2. In just two more years the architecture had evolved to a central computer with two powerful zone controllers capable of running mixed-criticality workloads spanning safety and body functions. As of 2025 S&P Global listed Nio as the first vehicle to reach SDV level 5 ahead of Tesla and other major China BEV makers.
Like Tesla, Nio now also designs its own zonal and central computer ECUs and ADAS processor. Hardware upgrades progress much more quickly than at most incumbent OEMs. If there is a downside, its that development of all aspects leads to a heavy R&D burden that eats into profit margins if vehicle volumes are low, as they are for Nio. And for this reason, Nio at different business models such as licensing technology deals, as Leapmotor and Xpeng have done with service contracts with Stellantis and Volkswagen, respectively.
Another impressive example of a rapid E/E architecture iteration is Leapmotor, which has used zones and a central computer with control of four domains to reduce a kilometre of heavy wiring and remove 20 ECUs.
The rapid gains in vehicle hardware consolidation via central computer and zonal architecture design as demonstrated by Leapmotor.
The efforts of General Motors and Ford to further develop SDV on their own are of course laudable but highlight that aspects of SDV design around software and hardware carry a high financial burden in terms of engineering costs and managed portfolio alignment. In the same way, OEMs like Volkswagen, Stellantis, Renault, and Toyota also must provide affordable cars for different vehicle segments, markets and with propulsion types, and it is all but impossible to scale a new E/E architecture that will fit all.
This multiplicity of architectures will necessarily persist, diluting scaling benefits. But the additional costs are deemed acceptable in the belief that the SDV will provide the next generation of smart vehicles that appeal to customers and that for the manufacturer, break the chain of slow-moving fixed development platforms.
Ford’s 2025 strategy correction resulted after the company had spent too much money for little progress in developing just such an SDV hardware – software combination that could fit the range of vehicles in the line up. The original plan (Ford Networked Vehicle version 4 or FNV4) intended a more unified SDV approach but was finally trimmed back to target just a few only smaller BEVs due starting 2027 using a “Tesla-like” zonal approach. The remainder of the fleet—including high-volume products such as F-150 Lightning—will remain on a flexible domain architecture.
For its part, General Motors is running a year or so late with its first zonal design, which will be fitted to the Cadillac Escalade around 2028 or 2029. GM has done the first new E/E designs for central computers in-house and demonstrates how OEMs work to reduce the classic tier-1s role to merely contract manufacturing rather than control of the complete product development.
Partnering as the way ahead
Volkswagen has chosen joint ventures to remedy the delays accrued by its software subsidiary CARIAD in developing software for its long delayed SSP platform for BEVs. For markets outside of China, the Volkswagen partners with Rivian. The latter company will provide a base SDV software paired with zonal hardware for Volkswagen, Audi and other vehicles planned to start on SSP.
VW Group is a diverse range of four brands with different powertrains and market segmentations. While suited to BEV cars, the issue of SDV variants for hybrids, range extended-BEVs and ICE propulsion systems is still an open question, and not a Rivian focus.
The first Rivian zonal E/E architecture will appear this year on the Rivian RT2 and the first Volkswagen SDV in the ID.1, anticipated in 2027. VW’s SSP platform will eventually start 2028 or 2029, two to three years behind the original schedule, and is anticipated to be with the ID.Golf.
For China markets, VW China operates independently and is outsourcing SDV development to Xpeng, which will use its own China Electronic Architecture based on zones and central computing and a China based supply chain for the key semiconductors. This design accelerates time-to-market for VW tuned to China market expectations, e.g., L2+ with urban navigation and advanced infotainment and frequent updates.
Finally, BMW has remained on track with its stated SDV introduction goals by prudently building on an already advanced E/E foundation. The upgraded E/E design for Neue Klasse platform includes four domain controllers and two simple zone controllers for body functions, in addition to e-fuses to improve harness weight, while 600m of wiring was shaved-off compared to previous models. One takeaway is that a conservative, scalable architecture can be an advantage over a disruptive E/E redesign if it can be deployed across the fleet sooner and/or more widely.
Conclusions
The SDV requires new hardware to accommodate an E/E architecture no longer fixed in the original manufacturing platform sense. This places new demands on OEMs to scale with sufficient compute headroom to manage future features, to continually evolve the software and to provide continual cybersecurity protection from attack. This partners with a network topology that avoids updating dozens of distributed ECUs independently.
The SDV race will be won by those who align hardware consolidation with software execution. But due to the demands of cybersecurity, it is a race that never ends. OEMs are therefore entering a new, exciting and above all disruptive phase in their development from mechanical-system to software-driven system. As this article demonstrates, each player must deal with certain baggage that they inevitably bring on the ride, and which determines the success rate of their SDV-readiness.
The authors
Richard Dixon
is Senior Principal Analyst at S&P Global Mobility.
Manuel Tagliavini
is Principal Analyst at S&P Global Mobility.
