The cars are becoming software-defined vehicles (SDVs). What changes for suppliers?

For decades, automotive development was organized primarily around hardware. A supplier delivered an ECU, sensor, control unit or subsystem, with software closely tied to the component it controlled. That model is changing. 

The software-defined vehicle (SDV) shifts more functionality into software platforms that can be updated and extended throughout the life of the car. Over-the-air updates, cloud connectivity, centralized computing and service-oriented architectures are becoming part of the core automotive technology stack. 

For Tier 1 and Tier 2 suppliers, this changes what OEMs expect from the companies developing systems around the vehicle. 

From distributed ECUs to centralized platforms 

Modern vehicles contain many electronic control units responsible for individual functions. As infotainment, connectivity, driver assistance, diagnostics and other digital capabilities have expanded, this distributed architecture has become increasingly complex. 

The industry is responding by consolidating computing power. 

New vehicle architectures increasingly use high-performance computers and zonal structures to manage multiple functions centrally. BMW’s Neue Klasse and Audi’s E3 architecture are examples of this broader movement toward centralized computing and software that can evolve after production. 

A component can no longer always be treated as an isolated part of the vehicle. Its software may need to interact with centralized platforms, shared services, cloud systems and functionality delivered by several other suppliers. Integration becomes as important as the individual feature. 

Start of production is no longer the end 

Traditionally, start of production represented a major finish line. With software-defined vehicles, it increasingly becomes another point in the software lifecycle. 

If vehicle functionality can be changed after the car leaves the factory, suppliers need reliable processes for building, testing, releasing and maintaining software over much longer periods. 

That means managing versions across vehicle configurations, maintaining reproducible development environments, automating tests and controlling releases. 

Rollback becomes important too. 

The question is no longer simply: 

Do the features work? 

It becomes: 

Can we safely update them, understand exactly what changed and recover if something goes wrong? 

That brings automotive software development closer to the DevOps and operational practices already common in modern cloud products. 

The cloud becomes part of the vehicle ecosystem 

Software-defined vehicles also extend beyond the physical car. Cloud infrastructure can support diagnostics, telemetry, fleet management, data processing, software distribution and connected services. 

That broadens the technical capabilities suppliers need. 

Embedded systems may now communicate with APIs, cloud applications, data platforms and deployment infrastructure. A problem in a backend service or release pipeline can potentially affect functionality consumed elsewhere in the vehicle ecosystem. 

The boundary between automotive software, cloud development and DevOps therefore becomes increasingly blurred. Suppliers do not necessarily need every capability internally. But they do need engineering partners who understand how these layers interact. 

Security and traceability become engineering requirements 

More connectivity and continuously updateable software also mean a larger security surface. 

Automotive organizations already operate within demanding cybersecurity and information-security frameworks. As vehicle software becomes more connected, controlled development processes become even more important. 

A software development partner becomes part of the supplier’s engineering and security chain. Weak documentation, uncontrolled access or inconsistent release processes can therefore create risks beyond the quality of the code itself. 

Modernization cannot stop the systems already working 

There is another important reality behind the transition to SDVs: automotive companies are not starting from zero. OEMs and suppliers already depend on internal platforms, engineering tools, data systems and software that may have evolved over many years. 

Those systems cannot simply be switched off while everything is rebuilt. Often, the real challenge is adding new functionality while protecting processes that engineers already depend on. 

This is something we have experienced directly at Ascendro through our automotive software work, including projects involving Audi and BMW environments. 

In our work around Audi’s BUSNET system, for example, the challenge involved an established internal application connected to vehicle electrical architecture. The objective was not to rewrite everything. 

We first had to understand the interconnected system, then introduce and optimize functionality without disrupting features that were already working. 

That experience reflects a broader reality of the SDV transition: modernization is rarely a choice between “old” and “new.” It is about building a safe bridge between them. 

What should suppliers expect from a development partner? 

As automotive systems become increasingly software-driven, technical headcount alone is not enough. 

A development partner should be able to work inside complex existing environments, understand a system before changing it and operate across software development, cloud infrastructure and DevOps where necessary. 

Documentation should be part of delivery. Access should be controlled and traceable. Releases should be reproducible. And teams should remain involved long enough to build genuine knowledge of the systems they support. 

At Ascendro, we combine custom software development with DevOps, cloud operations and long-term software maintenance. 

Our TISAX, ISO 27001 and ISO 9001-certified processes provide an additional foundation for automotive projects where information security, traceability and controlled processes matter.