A premium car a decade ago shipped with around 150 million lines of code. The software-defined vehicles now on OEM roadmaps are projected to run 200 to 300 million. That is not a bigger version of the same problem. When the car becomes a computing platform that happens to have wheels, the hard part stops being any single subsystem and becomes the relationships between all of them: which requirement drives which function, which function lands on which compute node, and what breaks when any of that changes. That coordination problem is exactly what model-based systems engineering is supposed to own.
What "software-defined" actually changes
The phrase gets thrown around loosely, so it helps to be specific. In a software-defined vehicle (SDV), features are delivered and updated in software rather than fixed in hardware at the factory. The car you buy is expected to gain capability over its life through updates, which means the architecture has to be designed for change instead of frozen at start of production.
That ambition has teeth. IoT Analytics' 2026 adoption work reports that 45% of OEMs now rank SDV strategy as their top priority, ahead of both autonomous driving and electrification. The reason is partly defensive. The code base is growing faster than the old development model can absorb, and a documents-and-spreadsheets approach to system definition does not scale to hundreds of millions of lines spread across dozens of suppliers.
Why the E/E architecture forces the issue
The clearest signal of the shift is the move from domain-based to zonal electrical and electronic architecture. Instead of grouping electronic control units by function, zonal designs group them by physical location in the car and route them to a few central compute units. The payoff is concrete: reported wiring-length reductions of around 25%, lower build cost, and easier sensor fusion within each zone. Volkswagen's Scalable Systems Platform is targeting a full zonal architecture that cuts ECU count by more than half and wiring by 40%, and analysts expect the zonal ECU market to reach $12 billion by 2030.
Here is the catch for systems engineers. When you collapse fifty function-specific ECUs into a handful of zonal computers, the functions do not disappear. They get virtualized and consolidated onto shared hardware, so the mapping between "what the car does" and "where it runs" becomes many-to-many and genuinely hard to hold in your head. A model that keeps that mapping explicit stops being a nice-to-have.
Traceability is the part that pays the bills
Automotive teams do not adopt MBSE because models are elegant. They adopt it because ISO 26262 mandates end-to-end traceability of safety requirements, and that chain is where audits usually go sideways. Every layer, from the customer feature down to the software component on a specific ECU, tends to live in its own tool and its own format, and the chain fractures right at the organizational boundary between OEM and supplier.
A model-based approach attacks that directly. SysML models can be linked to the AUTOSAR software components that implement them, so a safety goal can be traced from the hazard analysis through the logical architecture down to the code unit and the test that verifies it. The division of labor is worth stating plainly: AUTOSAR standardizes the software architecture, ISO 26262 supplies the safety requirements and methods, and the system model is what keeps the two connected as both sides change. When traceability is a query against a model instead of a manual reconciliation across spreadsheets, the compliance evidence is a byproduct of doing the work rather than a separate project.
The tooling is converging on this use case
The vendor landscape reflects how central automotive has become. Dassault Systèmes' Cameo (CATIA Magic) and IBM Rhapsody are long-standing SysML environments with deep automotive footprints and links into requirements and AUTOSAR toolchains. Eclipse Capella, built on the Arcadia method, is used by teams that want an open, method-driven approach to architecture. Newer SysML v2-native tools such as Dalus build on the updated language and its standard API, which is aimed at making models easier to exchange between tools. The practical question for an automotive program is less about which tool is "best" and more about how cleanly it connects to the requirements management, safety analysis, and software toolchains the program already runs on.
What MBSE won't solve for SDVs
It is worth being honest about the limits, because oversold MBSE has burned automotive teams before.
A model does not write or verify your software. It describes the system and its constraints; the 200-plus million lines of code still have to be developed, integrated, and tested with their own toolchains. MBSE narrows the gap between intent and implementation, but it does not close it.
It also does not survive a half-committed rollout. Traceability only holds if the model is the live source of truth. The moment teams keep the "real" architecture in slide decks and treat the model as documentation written after the fact, you get the worst of both worlds: maintenance cost without the payoff. Cultural adoption across OEM and supplier boundaries is harder than any modeling notation.
And the migration is not free. Connecting a SysML model to AUTOSAR, requirements tools, and safety analysis takes real integration work, and the SysML v2 ecosystem, while promising on interoperability, is still maturing. Teams should plan for tool gaps and version churn rather than assuming a seamless pipeline on day one.
The bottom line
Software-defined vehicles break the old way of defining systems mainly through scale and rate of change. With code bases heading toward 300 million lines and architectures consolidating onto zonal compute, the binding problem is keeping features, requirements, functions, and hardware in sync as all of them move. MBSE is the discipline aimed squarely at that problem, and ISO 26262 traceability gives teams a hard reason to invest. It will not write the software or fix a weak adoption culture, but for managing the relationships in a system this large, the alternative of documents and spreadsheets stopped being viable several million lines of code ago.