Software-defined vehicles are projected to account for 90% of global vehicle production by 2029, up from just 3.4% in 2021. This shift is already reshaping how vehicles are built, updated, and sold today.
For most original equipment manufacturers (OEMs), this raises one question: how do you turn a legacy E/E architecture into a software-defined one without disrupting the supplier relationships and validated systems already built around it?
Answering that means solving three problems. Why does a legacy E/E architecture, built on decentralised ECUs and fragmented CAN and LIN protocols, struggle to support software-defined capability? Why do the usual fixes, a full rebuild or an extended wait, fail to close that gap? And what architecture, fragmented to domain-based to zonal to centralised, actually closes it?
Quess helps OEMs navigate this transition across architecture, engineering infrastructure, and validation.
Why Legacy Architecture Is Under Strain
Decentralised vehicle architecture made sense when systems operated largely independently, with each electronic control unit (ECU) designed for a specific function.
Modern vehicles work differently. According to McKinsey research, automotive software complexity has grown roughly four times over the past decade, while development productivity has grown only one to one and a half times. Global OEMs spent close to $38 billion on software in 2024, up from $26 billion in 2021, a roughly 14% annual increase.
This widening gap between software complexity and development capacity is placing greater pressure on validation timelines, system integration, software reuse, and the speed at which new capabilities can reach the road.
For OEMs, the question is no longer whether legacy architectures can be extended. It is how long they can be extended without limiting the vehicle’s software-defined potential.
Why the Common Extremes Fall Short
That decision comes down to two common extremes.
One option is to rebuild the software and E/E stack from the ground up. While this may create a cleaner long-term architecture, it can also require significant changes across supplier contracts, certified subsystems, tooling, engineering processes, and safety validation. Programs that have taken this route have seen defect counts spike just months before start of production, with warranty costs running into the billions industry-wide.
The second is to wait, extending the current architecture a little longer. It feels safer, but with software-defined vehicles on track to dominate global production before the decade is out, momentum increasingly favours whoever moves first.
Neither extreme fully addresses the practical realities facing established OEMs.
A more workable path is to evolve the architecture progressively, modernising selected platforms, domains, functions, or vehicle programmes while retaining validated legacy capabilities where they continue to deliver value.
Architecture Evolution: From Fragmented to Centralised
That transition starts with separating hardware from software, so capability can be added and updated without touching the systems underneath every time.
In a fragmented architecture (common in modern vehicles), individual ECUs manage specific functions independently. A domain-based architecture groups those controllers by function, such as powertrain, chassis, or infotainment, under a shared domain controller, cutting redundancy while keeping each function’s logic intact. A zonal architecture consolidates further by region of the vehicle, reducing wiring complexity and enabling coordination across functions regardless of domain. Centralised architecture completes the shift with a unified compute layer that unlocks over-the-air updates, AI-enabled features, and software-first business models.
Each stage delivers value on its own, so OEMs can evolve zone by zone rather than all at once. None of these stages move on their own, though. They depend on infrastructure to carry them from cloud to vehicle, and on a method to validate them along the way. That is where Quess’s role in this shift begins.
How Quess Is Navigating the Next Shift in SDV
A software update typically begins on a cloud-based over-the-air platform, moves through the OEM backend for eligibility checks and scheduling, reaches the vehicle through a secure gateway, and is installed on the relevant zonal or central compute system. Encryption, authentication, version control, rollback mechanisms, and controlled deployment support every step. Once installed, the vehicle sends telemetry back to the cloud, closing the loop between development, deployment, and real-world performance.
Delivering that pipeline reliably, without disrupting what already runs, depends on changing how validation is done.
Road-to-rig testing moves selected on-road validation into hardware-in-the-loop (HIL) environments, allowing systems such as ADAS, braking, and powertrain controls to be tested under controlled and repeatable conditions.
Rig-to-desktop testing replaces physical rigs with software-in-the-loop (SIL) environments and virtual ECUs, enabling software to be validated at scale without depending on physical hardware for every test cycle.
Road-to-desktop testing uses vehicle models and digital twins to simulate broader system behaviour before physical testing begins. This allows software, integration, and performance issues to be identified earlier in the development process.
The same shift, from reactive to predictive, applies to the architecture itself.
Middleware layers decouple software from hardware, allowing code to move across compute platforms instead of being rebuilt for each one. Gateway ECUs bridge legacy protocols such as CAN and LIN with Ethernet-based zonal networks, helping connect old and new systems without requiring a full replacement. Virtual ECUs reproduce legacy functions in software, preserving existing functionality while more processing moves towards centralised compute. CI/CD-compatible pipelines bring legacy tooling into modern DevOps workflows, supporting a more unified delivery model across both environments. Data abstraction and edge analytics layers create greater visibility into diagnostics, vehicle performance, and predictive maintenance.
Testing catches earlier what might otherwise surface later in development. Architecture absorbs change that might previously have required a wider rebuild. Both move in the same direction: from reacting after the fact to identifying issues before they reach production or the road.
Where the Decade Splits
The 2030 shift towards software-defined vehicles will increasingly separate OEMs that remain dependent on late-stage physical validation from those that move more testing, integration, and development into virtual environments.
The difference will not come from centralised compute alone. It will come from the ability to test earlier, update securely, reuse software across platforms, and identify integration risks before they become production problems.
That shift from reactive to predictive will play a significant role in determining who leads the next decade of mobility.
Quess helps build that shift into the architectures and engineering environments OEMs already operate today, one platform, one system, and one validated step at a time.
The evolution can begin wherever the legacy E/E architecture stands right now.
Research and Data References
- Infosys, Automotive Industry Outlook 2025
https://www.infosys.com/iki/research/automotive-industry-outlook2025.html - McKinsey & Company, “When Code Is King: Mastering Automotive Software Excellence”
https://www.mckinsey.com/industries/automotive-and-assembly/our-insights/when-code-is-king-mastering-automotive-software-excellence - Roland Berger and SDVerse study, 2024
https://content.rolandberger.com/hubfs/07_presse/24_358_MKT_SoftwareCommercialization.pdf
Share on
