A software defined vehicle is one in which software, rather than fixed hardware, determines most of what the vehicle does, and in which that software can be changed after the vehicle has been built and sold. The term covers an engineering shift, from dozens of separate control units each running its own code to a few powerful computers running shared software, and a commercial shift, from a product that is finished at the factory gate to one that keeps changing for years.
This plain-English guide defines the main building blocks: centralised compute, zonal architecture, over-the-air updates and service-oriented software. It then sets out the regulatory frame that now applies to software updates in Great Britain and what the change means for manufacturers, suppliers, dealers and fleet operators. It draws heavily on the Advanced Propulsion Centre UK’s insight report on software defined vehicle value chains, published on 16 July 2026.
What makes a software defined vehicle
The APC’s software defined vehicle value chains report identifies several traits: functions are delivered and updated through software, features can change after start of production, software faults can be fixed remotely, and hardware and software are increasingly decoupled. The report describes the result as a vehicle that always has a next version in development, rather than a model that is released once and refreshed periodically.
Decoupling is the core idea. In a traditional vehicle, a function such as climate control or a driver assistance feature is tied to a specific electronic control unit supplied with its own embedded software. In a software defined design, the function becomes an application that can run on shared computing hardware, so it can be updated, improved or reused across models without changing the physical parts.
Central compute and zonal architecture
Two hardware changes make that decoupling possible. The first is central compute: the APC report describes a small number of high-performance computers acting as the main processing and orchestration layer, hosting demanding applications, running the operating system layers and coordinating safety and cyber security. It notes that vehicle makers are taking more ownership of this layer, in some cases by procuring custom semiconductors.
The second is zonal architecture. Instead of grouping electronics by function, such as body, chassis or infotainment, a zonal layout groups them by physical area of the vehicle. Zone controllers collect sensor and actuator signals, distribute power and act as gateways, while most decisions are made centrally. The APC report lists the benefits as less wiring, lower weight and fewer but more capable nodes, and observes that established manufacturers are often layering zonal concepts onto legacy designs, producing a transitional middle stage. Our article on how zonal architecture changes the integration bill looks at the cost side of that transition.
| Feature | Conventional architecture | Software defined architecture |
|---|---|---|
| Computing | Many single-purpose control units | A few central high-performance computers |
| Wiring layout | Organised by function | Organised by physical zone |
| Software | Embedded in each supplier’s unit | Applications on shared platforms |
| Change after sale | Workshop reflash, if at all | Over-the-air updates throughout life |
Over-the-air updates and service-oriented software
Over-the-air updating is the visible part of a software defined vehicle. The APC report explains that a telematics control unit links the vehicle to the cloud, and describes software updating as a controlled intervention rather than simple patching, with techniques such as installing to an inactive memory partition, activating overnight and protecting against failed updates by rolling back. Different variants of the same model may run different software versions at the same time, which adds management complexity.
Above the hardware, a service-oriented architecture splits software into services with standardised interfaces, so teams can develop and deploy parts of the system more independently. Middleware connects applications, operating systems and tools; real-time operating systems handle deterministic, safety-relevant tasks, while general-purpose systems run less time-critical functions. The APC report warns that this flexibility raises the need for integration discipline and system-level validation, especially when functions of different safety criticality share the same computer. Open, vendor-neutral efforts such as the Eclipse SDV working group, hosted by the Eclipse Foundation, are building shared software building blocks for these architectures.
The rules on software updates
Updating a vehicle after sale is regulated. UN Regulation No 156, published in the Official Journal of the EU on 9 March 2021, requires manufacturers to run a certified software update management system. Among other things, they must uniquely identify software versions, manage a software identification number for type-approval-relevant software, assess whether an update affects type-approved systems or safety, and inform users. For over-the-air updates, the vehicle must be able to recover or reach a safe state if an update fails, must have enough power to complete it, and must tell the user the purpose and expected duration beforehand and the outcome afterwards.
In Great Britain, the Vehicle Certification Agency announced that SI 2025 No. 1110, in force from 13 November 2025, added UN Regulation 155 on cyber security and UN Regulation 156 on software updates to GB type approval, with 1 June 2026 as the first mandatory date for new types of complete and base vehicles. Multistage and special purpose vehicles follow in later years. Our article on what an over-the-air programme needs covers the operational side of meeting those duties.
What the software defined vehicle means for business
The APC report argues that value shifts from a one-off product sale towards a connected platform, citing subscriptions, features on demand, paid upgrades, fleet services, predictive maintenance and usage-based services, and stressing that the opportunity lies in useful intelligence rather than raw data. It also notes that product and software teams must persist long after launch, and that skills in integration, validation, cyber security and data are in demand. The report identifies the UK’s strongest opening as high-value enabling capabilities, such as systems integration, virtual validation, cyber security and over-the-air governance, and specialist calibration and diagnostics services.
The effects reach beyond engineering:
- Suppliers may move from selling a control unit with embedded code to supplying hardware, software or services separately, with different contract and support terms.
- Dealers and workshops need to know which software version a vehicle is running before diagnosing it.
- Fleet operators should ask how updates are scheduled, how functions might change during the ownership period and what data the vehicle shares.
Key points for automotive businesses
- Treat a software defined vehicle as a product that changes after delivery, not a finished specification.
- Expect central compute and zonal layouts to change supplier roles and integration responsibilities.
- Check that over-the-air updates are covered by a certified software update management system under UN Regulation 156.
- Note that GB type approval has required UN Regulations 155 and 156 for new types of complete and base vehicles since 1 June 2026.
- Build software version awareness into diagnostics, fleet records and residual value assumptions.
Sources
- Advanced Propulsion Centre UK: Software Defined Vehicle Value Chains insight report
- Advanced Propulsion Centre UK: Software Defined Vehicle Value Chains report (PDF)
- EUR-Lex: UN Regulation No 156, software update and software update management system
- Vehicle Certification Agency: New GB type approval legislation, cyber security and software updates introduced
- legislation.gov.uk: The Road Vehicles (Type-Approval) (Amendment) (No. 3) Regulations 2025
- Eclipse Foundation: Eclipse SDV working group
Sources checked in November 2026. Rules, rates and schemes can change after publication, so check the linked official pages before acting.
