Software-Defined Vehicles Why Electronics Architecture Is the New Battleground

The software-defined vehicle is turning traditional vehicle development on its head: No longer are individual control units the foundation for new features and continuous software updates—instead, it is networked, centralized electronic architectures. This is increasing the pressure on development processes, data management, and variant management.

The car is becoming a moving computer. This statement has become so commonplace that it obscures rather than explains the complexity behind it. And that is precisely the problem: While the industry talks about Software-Defined Vehicles (SDV), development teams struggle daily with a reality that still lags far behind this vision. Control units don’t communicate with each other, requirements are managed in Excel spreadsheets, and software versions are no longer fully traceable by anyone.

The real bottleneck is the E/E architecture on which the software runs, and the way it is developed. It determines whether functions exist side by side in a distributed manner or can work together as a networked, updatable system.

From Distributed Hardware to Centralized Platforms

For decades, vehicle development followed a tried-and-true pattern. Every function was assigned its own electronic control unit (ECU), whether it was a window regulator or a powertrain control system. Everything was separate, and everything was hardwired. As a result, modern vehicles today contain up to 150 ECUs, which are connected to one another by kilometers of wiring harnesses. However, this model can no longer accommodate the growing complexity. New vehicle functions can no longer be easily implemented by simply adding another control unit, while at the same time the requirements for

Over-the-Air Updates and Functional Safety are on the Rise

The industry’s response to these growing demands is centralization: high-performance computing platforms are taking on tasks that were previously distributed across dozens of ECUs, zone architectures are replacing functional domains, and software is being decoupled from hardware as much as possible. In practice, however, this transformation represents a profound shift in existing development processes. Without a consistent data foundation, it is easy to lose track of the big picture before the vehicle even hits the road.

The Real Problem: Fragmented Development Landscapes

Established OEMs and Tier 1 suppliers work with complex tool landscapes that have evolved over many years, in which requirements, system architecture, and software development exist in separate systems. Manual handoffs and interface documents arise between these worlds, which, in the worst case, can lead to inconsistencies that only become apparent during vehicle testing.

At its core, this is an architectural problem. As long as Application Lifecycle Management (ALM) and Product Lifecycle Management (PLM) are not seamlessly integrated, gaps will inevitably arise. If a requirement changes, the affected system components often go undetected, and updated software versions lose their traceability back to the original requirement. For safety-critical systems, this is no small matter. ISO 26262 and ASPICE require seamless traceability, and anyone who tries to ensure this with manual processes pays a high price in terms of time and error risk.

End-to-End Engineering as the Foundation

To overcome this fragmentation, OEMs and Tier 1 suppliers need an end-to-end digital database that serves as a single source of truth and links requirements, system architecture, and validation evidence. This is the only way to avoid data discontinuities between ALM and PLM and reduce manual handoffs between disciplines.

Model-Based Systems Engineering (MBSE) is the tool that enables development teams to describe system behavior, visualize dependencies, and assess the impact of changes early on. Anyone who maintains a system model that is synchronized with requirements and the current software version can answer a question that often remains unresolved in traditional processes: namely, what happens when a requirement changes.

This is particularly relevant in the context of the software-defined vehicle, because over-the-air updates mean that software continues to be developed after the vehicle goes into production. Without end-to-end traceability, it is impossible to reliably assess whether an update affects a system’s functional safety.

Variant Management: The Underestimated Challenge

Variant management often takes a back seat in SDV discussions, yet it is one of the most complex challenges in vehicle development. A modern vehicle program encompasses hundreds of variants across different markets, trim levels, and powertrain concepts, and each variant has its own combination of hardware and software. In fragmented development environments, this means that requirements, architectures, and software versions must be maintained separately for each variant. The effort scales linearly with the number of variants—and so do errors.

End-to-end engineering solves this problem through configuration management at the model level. Variants are treated as configurations of a common system model, so that changes are made once and then propagated in a controlled manner to all affected variants.

What This Means for Development Teams

The transition to a centralized E/E architecture is not a one-time project. It is an ongoing process that actively changes the way teams work and make decisions. Anyone who still manages requirements manually today and makes architectural decisions without comprehensive documentation will no longer be able to understand tomorrow why decisions were made in favor of certain systems. Automated change management is therefore evolving from a mere convenience feature to a necessity, because given the complexity of modern vehicle programs, manual impact analyses are simply no longer scalable. This also applies to the integration of ALM and PLM: Those who continue to operate these two worlds separately create silos that will sooner or later become a problem in the context of the SDV.

What the SDV Really Needs

The software-defined vehicle is, above all, a matter of development infrastructure. Anyone who transforms the E/E architecture without simultaneously modernizing development processes and the data infrastructure creates new complexity instead of resolving old issues. MBSE, integrated ALM and PLM, and variant management are proven approaches that are already delivering results in practice: They provide transparency regarding requirements, architectures, and software versions, reduce manual handoffs, and make variants manageable. The challenge lies in their consistent implementation across disciplines and organizational boundaries. Those who succeed will have a robust foundation for the software-defined vehicle. Those who do not will find that the next generation of software is built on the same problems as the last. 

*Michele Del Mondo is Global Advisor Automotive at PTC

Software-Defined Vehicle

Nissan and Honda Are Jointly Developing SDV Components