Software Defined Vehicle — value chain in transition

In the classic vehicle, value creation sat in powertrain, body and mechanical systems. In the software defined vehicle it shifts into software, data processing and the services built on top. That much is largely accepted.

Less attention is paid to the asymmetry of the transition: the revenue shift happens faster than the cost structure can be rebuilt. Vertical integration, plant footprint and supplier relationships are configured for the old value chain and cannot be adjusted at the same pace.

A characteristic earnings gap follows: investment in software competence ramps up while the hardware cost base is still fully carried. Companies that do not plan this phase explicitly finance the transformation out of earnings that are simultaneously under pressure.

Centralized E/E architectures with domain or zone controllers are the technical precondition for software to be updated and extended independently of the component. Without them, every function stays bound to a control unit — and therefore to its lifecycle.

The commercial significance lies in decoupling. Only once function and hardware are separated can functions be added across the vehicle's life, variants reduced, and development effort reused across model ranges.

Planning logic thereby shifts from the vehicle project to the platform. Decisions that used to be taken per model range are now taken once for several generations — with correspondingly higher risk if the design is wrong.

The classic Tier-1 delivered systems: hardware, software and integration responsibility in one package. That package is precisely what OEMs are currently unbundling as they bring software and platform competence in-house.

Three possible positions emerge for suppliers: component supplier with a defined interface and correspondingly lower value share; software or function supplier inside the OEM platform; or system partner for areas where the OEM does not build its own depth.

Choosing between these positions is not a sales question but an investment question. It determines which competences are built, held and wound down — and it cannot be reversed in the medium term.

Vehicle development was tied for decades to multi-year product cycles. Software follows a different logic: competitiveness comes from the ability to ship, correct and extend functions at short notice.

The two cadences are not readily compatible. They require separate development, release and quality processes for hardware and software — including a validation logic that permits short release cycles without compromising functional safety.

Where that separation fails, the slower cadence dominates. The result is a software organization that formally exists but operates at the rhythm of hardware development, losing the very advantage it was built for.

The expectation of downstream revenue — functions on demand, subscriptions, data-based services — is a material part of the investment case for the software defined vehicle. Those revenues, however, cannot be retrofitted.

They require that the vehicle platform already contains the relevant hardware, that data capture and rights management are cleanly defined, that update capability is secured over the life of the vehicle, and that the contractual and data protection basis is in place. All four are architecture decisions taken in the vehicle project.

The practical sequence follows: define the platform and data strategy first, then build the business model on it. The reverse produces revenue expectations that cannot be technically delivered.