How Automotive OEMs Are Rearchitecting Software-Defined Vehicle Development

For most of the past three decades, automotive electrical and electronic architecture followed a predictable logic: add a new feature, add a domain controller. Infotainment got its ECU. Advanced driver assistance got its own processing stack. Body electronics, chassis, powertrain—each domain accreted its own control hardware, its own software stack, its own supplier relationship, and its own validation process. By the time a modern mid-segment vehicle reached production, it might carry 70 to 100 ECUs connected by a heterogeneous bus network that no single engineer fully understood.

That architecture is now being dismantled across the industry, deliberately and at significant cost, because it cannot support software-defined vehicles. The shift to central compute and zonal architectures is not primarily a hardware decision. It is a systems engineering decision—and it is exposing, faster than most OEMs expected, whether their internal engineering processes and tooling are adequate for the complexity they are now managing.

What Is Actually Changing in E/E Architecture

The domain-controller model consolidated ECUs into functional domains—but only partially. A “domain controller” for ADAS might still coordinate 12 downstream processors. The buses connecting them were proprietary, the interfaces were hard-coded into supplier deliverables, and the software update model was—at best—a dealer visit.

Zonal architecture replaces functional grouping with physical grouping. Zone controllers handle all electronics within a physical region of the vehicle—front-left, rear, center—and communicate with a small number of high-performance central compute nodes over high-bandwidth Ethernet backbones. Software for any feature can, in principle, run anywhere on the compute fabric. Hardware and software are intentionally decoupled.

Central compute (sometimes called “Vehicle Computers” or “High-Performance Computers”) goes further, consolidating ADAS, infotainment, and vehicle dynamics into a handful of powerful processors running hypervisors that partition workloads in real time.

The consequences for systems engineering are significant:

Interface count and type change radically. A domain-controller architecture might have a few hundred well-defined interfaces, largely managed by supplier contracts and AUTOSAR Classic configurations. A zonal plus central-compute architecture can have thousands of software-defined service interfaces—many of which are dynamic, version-dependent, and cross-partition boundaries in ways that create safety and security implications that must be analyzed, traced, and validated.

The OTA update model changes the validation regime. When software can change post-production, requirements must carry temporal context. “Requirement X was met at Job 1” is no longer sufficient. The safety case must survive across software versions, which means traceability cannot be a one-time artifact.

Integration responsibility moves inward. When a domain was outsourced to a Tier 1, the interface was relatively clean and the integration problem was bounded. When the OEM owns the central compute platform and the zonal controllers, integration complexity is internalized—and the OEM’s systems engineering practice becomes the integration mechanism.

What the Major OEMs Are Actually Doing

The reorganizations at Volkswagen, Toyota, and Hyundai are worth examining precisely because they show how similar the structural problem is across very different organizations.

Volkswagen created CARIAD as a software subsidiary in 2020, then spent several years learning how hard the problem is. The difficulties with the ID.3 software launch, subsequent CARIAD restructuring, and the Rivian partnership announced in 2023 all point to the same root cause: the gap between software intent and systems engineering execution. VW’s current approach consolidates software development into fewer platform layers built around a defined vehicle computer architecture, with the stated goal of reusing 80% of software across platforms. That goal is only achievable if requirements and interface definitions are maintained at the platform level with genuine traceability to vehicle-level behavior—not in per-model documents that diverge on contact with reality.

Toyota has reorganized its Woven City and Woven by Toyota operations to function as the central software and systems engineering competence, while simultaneously restructuring its vehicle development organization around “software-first” programs. Toyota’s challenge is compounding complexity: it must evolve the E/E architecture across multiple regional markets, powertrain variants (BEV, PHEV, HEV), and vehicle classes simultaneously. The interface surface is enormous. Toyota has historically relied on highly disciplined document-based processes—TOYOTA’S internal engineering standards are famously detailed—but those processes were designed for hardware specification cadences, not continuous software integration.

Hyundai has taken an arguably more aggressive approach through its SDV Task Force and the development of the ccOS platform (Connected Car Operating System) for deployment across Genesis, Hyundai, and Kia brands. Hyundai’s central vehicle computer architecture targets a significant reduction in ECU count while enabling over-the-air software updates across safety-relevant domains—which immediately creates ISO 26262 and SOTIF complexity that requires systematic management, not ad-hoc documentation.

Across all three, the pattern is the same: the architectural decision to centralize compute and adopt zonal topology has been made. The hard work of managing the resulting systems engineering complexity is ongoing and, in most cases, visibly straining existing processes.

The Interface Complexity Problem Is Not Linear

It is tempting to treat the increase in interface complexity as an incremental problem—more interfaces, more columns in the interface control document, more reviewers on the change request. That framing is wrong.

In a domain-controller architecture, interfaces are largely bounded by the domain. A change to the ADAS domain controller’s software has a bounded impact on other domains because the inter-domain interfaces are explicit and relatively stable. In a zonal or service-oriented architecture built on SOME/IP, DDS, or AUTOSAR Adaptive, a change to one service can affect any consumer of that service across the vehicle—including consumers in safety-critical partitions. The impact set is not bounded by physical topology; it is bounded by the subscription model of the software architecture.

This creates a graph problem. The set of “what does this requirement affect” and “what affects this requirement” is not a tree structure you can manage in a requirements document with numbered sections and a traceability matrix spreadsheet. It is a directed graph with cycles, version labels, and conditional edges that depend on software configuration. The architecture and requirements exist simultaneously at multiple levels of abstraction, and changes at any level propagate in ways that are not obvious without active tooling.

OEMs that are still managing this with Word documents, Excel traceability matrices, and IBM DOORS installations configured for domain-controller-era workflows will not scale. This is not a criticism of those tools’ original design intent—DOORS was built for a different problem, and it solved that problem well. The problem has changed.

Requirements and Architecture Management as a Strategic Differentiator

The consequence of this analysis is that systems engineering tooling is no longer a back-office process choice. It is a competitive capability.

Consider two OEM programs managing the same central compute architecture. Program A has coherent, machine-readable requirements with bidirectional traceability to architecture models, safety cases, and test evidence—maintained automatically as the design evolves. Program B has requirements in a document management system, architecture in SysML models that are not synchronized with requirements, and a traceability matrix that was last reconciled at a program gate six months ago. When a software supplier changes a service interface, Program A’s systems engineers can immediately assess the impact on safety-relevant requirements and identify affected test cases. Program B’s engineers spend weeks in meetings attempting to reconstruct the impact manually.

At a vehicle development cadence of 30-36 months, that difference in decision speed compounds. It determines whether a program recovers from integration surprises or slips. At scale across multiple vehicle programs, it determines whether the OEM can actually exploit the platform reuse that justified the architectural investment.

The tools that address this problem share several characteristics: they model requirements and architecture as connected graphs rather than documents; they support automated impact analysis across requirement-to-architecture-to-test traceability chains; they accommodate the pace of continuous software development rather than annual gate reviews; and they expose model state and gaps through AI-assisted analysis rather than requiring engineers to manually audit large requirement sets.

Flow Engineering is one example of a tool built with exactly this problem in mind—AI-native requirements and architecture management designed for the connectivity and change velocity that hardware and systems engineering teams now face. Rather than retrofitting AI features onto a document-centric foundation, its data model is graph-based from the start, which means queries like “show me all safety requirements that are potentially affected by this interface change” are first-class operations rather than expensive customizations. For OEM systems teams managing service-oriented architectures across multiple vehicle programs, that structural difference matters.

The legacy tools—Polarion, DOORS Next, Jama Connect—are not standing still. Each has added model-based and AI-assisted capabilities. But the architectural debt of document-centric data models limits how far those additions can go. Adding AI-powered search to a requirements document does not give you impact analysis across a bidirectional architecture graph.

The Honest Assessment

The software-defined vehicle transition is real, the architectural shift is underway, and the major OEMs are committed to it regardless of the near-term financial pressure from EV margin challenges. The question is not whether zonal and central-compute architectures will dominate new programs—they will. The question is which OEMs will execute the transition with sufficient engineering rigor to capture the software reuse, update, and differentiation benefits, versus which will build technically impressive hardware platforms that are difficult to validate, slow to update, and expensive to maintain.

The answer depends less on compute silicon and more on whether the systems engineering practice can match the complexity of the architecture. Document-based requirements management, domain-siloed architecture tools, and manual traceability reconciliation are not adequate to that challenge.

OEMs investing now in graph-based requirements and architecture management—tooling that treats the vehicle as an interconnected system model rather than a collection of domain documents—are building an engineering capability that will compound over multiple programs. Those who delay because the legacy toolchain is familiar and the migration is disruptive will find themselves facing the same integration surprises at each program gate, just with more expensive consequences as central compute platforms carry more safety-critical workloads.

The architectural decision to go zonal is largely made. The systems engineering decision—how to manage the complexity that results—is still open. For most OEMs, that is where the race is actually happening.