Over the past five years, the automotive industry has done something remarkable. Most OEMs now ship vehicles with large central displays, over-the-air updates, connected services and a growing amount of AI in their driver-assistance systems. On paper, the building blocks of the software-defined vehicle are already in place.
Yet the gap between the fastest players and everyone else keeps widening. Some manufacturers take a new vehicle from concept to production in well under two years and improve it every month after launch. Others still plan software around the model year. The difference is rarely the technology inside the car. It is how the organisation builds, releases and learns from the software that runs on it.
On 30 September 2026, I presented a framework on this topic at the SDV & AV Technology Summit Europe in London. I call it PROPEL: six pillars of cloud-native and AI-native practice, held together by one operating model and one continuous loop. This article is the complete version of that talk — the reasoning behind the framework, each pillar in detail, a maturity self-check, and a practical path to adoption.
Necessary, but not sufficient
It is worth starting with what the industry has already achieved, because it is considerable. Most of us have shipped five ambitious capabilities only a few years ago: a large central screen, over-the-air (OTA) updates, an in-car app store, AI in advanced driver-assistance systems, and a portfolio of connected services. Each one took years of engineering effort, and each one matters to customers.
The challenge is that each of these is a first step rather than a destination. A central screen is valuable, but the real prize is decoupling the software behind it from the hardware. OTA is valuable, but mostly used for fixes rather than new features. An app store opens one domain, when the opportunity is to open the whole vehicle through well-defined APIs. AI in ADAS is one application of AI, but it could accelerate the entire development lifecycle. And connected services generate data that rarely flows back into the next release.
In other words, we have the basics. Getting to a true software-defined vehicle, and then to an AI-defined one, requires a leapfrog in how we work — not another feature on the roadmap.
What actually defines a software-defined vehicle
The term “software-defined vehicle” is now used so widely that it risks losing its meaning. I find it useful to apply five structural criteria. If a vehicle programme misses any one of them, the car is software-enabled rather than software-defined.
The first is decoupled hardware and software: new features can be delivered to vehicles already on the road, without a hardware change. The second is centralised compute, with a small number of central computers and zonal input/output replacing dozens of single-purpose ECUs. The third is continuous OTA, used to deliver new features, not just fixes. The fourth is a closed data loop, where fleet data directly shapes the next release. The fifth is a software-first organisation, in which teams own features end to end rather than handing work across functional silos.
The fifth criterion is the one most programmes underestimate. Architecture and tooling can be bought; ownership and ways of working cannot.
From software-defined to AI-defined
The software-defined vehicle is not the end state. The industry is already moving towards the AI-defined vehicle (AIDV), in which the car and the systems around it improve with use.
A helpful way to see this progression is that each step adds a new feedback loop, not just a new feature. A connected vehicle adds a telemetry loop: the car reports its status. An updatable vehicle adds a release loop: it can be fixed and improved over the air. A software-defined vehicle adds a product loop: features evolve beyond the model year. An AI-defined vehicle adds a learning loop: the car, and the engineering system behind it, get better with every mile driven.
The implication is important. An organisation that cannot run the lower loops quickly and reliably will not be able to run the learning loop at all.
Why speed matters now
Three data points explain why this is urgent rather than aspirational.
First, new Chinese EV makers now take a vehicle from concept to production in around 18 months, against 48+ months or more for established OEMs (McKinsey, 2025).
Second, 99.2% of Tesla’s 2024 recalls were resolved over the air (NHTSA recall data, 2024), which means continuous correction is already a customer expectation.
Third, since July 2024, UN R155 and R156 on cybersecurity and software updates have been mandatory for all new vehicles in the EU, so regulated, auditable updates are now a condition of market access.
Taken together, speed, continuous correction and regulated updates are no longer differentiators. They are the baseline.
Speed also compounds. A team that releases every month learns twelve times a year; a team that releases once per model year learns once. Over three years, the gap is no longer incremental — the two organisations are effectively competing in different races.
AI creates value through the loop, not the features
This is the central idea behind PROPEL. AI does not create lasting value because we add AI features to a car. It creates value when it works at every stage of a closed development loop — and when every turn of that loop makes the AI itself better.
The loop has six stages. In Build, AI co-pilots help engineers write and review code. In Validate, AI generates test scenarios and synthetic data. In Release, AI monitors the health of each rollout wave. In Operate, edge AI and in-vehicle agents act on behalf of the driver. In Observe, intelligent data triggers capture the moments that matter from the fleet. And in Learn, models are retrained on that data, so the next build starts from a better place.
Two effects reinforce each other here. AI in the loop speeds up each stage — code, tests, releases and in-car decisions. The loop for AI feeds each model with fresh, relevant data on every cycle. Together they form a flywheel in which every release makes the next one better.
Why cloud-native must come first
There is an uncomfortable corollary. A loop can only turn as fast as the pipeline beneath it. AI multiplies whatever system it lands on: applied to a slow, manual, hardware-bound process, it simply produces a faster way to wait.
The contrast between the two operating models is stark. In a hardware-bound organisation, releases are tied to the model year, testing happens late on physical benches, critical software sits inside supplier black boxes, data is pulled only after failures, compliance is audited at the end, and AI lives in side pilots. In a cloud-native organisation, releases continue well after start of production, testing is virtual-first and early, interfaces are owned and built on an open core, data drives every decision, compliance is built into the pipeline, and AI is part of the loop itself.
The sequence therefore matters. Cloud-native is the precondition; AI is the multiplier.
Lessons from industries that have already made the move
Automotive is not the first industry to face this transition, and it would be a mistake to treat it as a problem without precedent. Three sectors, each with its own demands for reliability and safety, have already changed how they build, release and deploy software.
In telecom, the 5G core network now runs as cloud-native software (3GPP TS 23.501). The lesson is that high availability and cloud-native practice are not in conflict; done well, they reinforce each other. In aerospace and defence, aircraft software has been updated in flight (US Air Force, October 2020). The lesson is to isolate what is safety-critical and move quickly on everything else. In consumer electronics, a single operating system now spans phone, home and car (Xiaomi, 2024). The lesson is that vehicle software can follow a device rhythm rather than a model-year rhythm.
Six cloud-native principles for the vehicle
“Cloud-native” is often misunderstood as moving servers to a public cloud. In practice, it is a set of engineering principles. The clearest summary remains the Twelve-Factor App, written by Adam Wiggins in 2011. Not every factor translates directly to a vehicle, but six of them do most of the work.
One codebase, owned — every variant is built from source the organisation controls.
Declared dependencies — every dependency is pinned and scanned, and every release carries a software bill of materials (SBOM).
Configuration over code — one binary serves many markets, trims and variants through configuration rather than code forks.
Build once, promote everywhere — the artefact that was tested is exactly the artefact that ships.
Offline-first and disposable — software works without connectivity and restarts cleanly to a safe state.
Observable by default — health, logs and metrics are available everywhere, in the car and in the cloud.
The fifth principle deserves a note. A web service can assume a network connection; a car cannot. That is why the vehicle version of this principle is offline-first rather than the original stateless.
Above these six principles sits one further commitment: to be AI-native — with AI built into the system by design, not bolted on afterwards.
Introducing PROPEL
If the principles describe what cloud-native means for vehicle software, PROPEL describes how to put it into practice. It is a framework of cloud-native and AI-native practices for the software-defined vehicle, organised as six pillars, one operating model and one loop.
The six pillars are Platform, Release, Observe, Protect, Engineer and Learn. Each pillar is examined through two lenses. The cloud-native lens describes how the capability should be built and operated. The AI-native lens describes how AI is designed into it from the start. Put simply, the pillars tell you where to act; the two lenses tell you how.
Above the pillars sits the data–AI flywheel, the principle that every release should make the next one better. Beneath them sits the operating model that makes the pillars sustainable: empowered product teams, a shared platform team, an architecture the OEM owns, and an open core for everything that does not differentiate.
The sections that follow walk through each pillar in turn. For each one, I describe what good looks like, the two practices, a practical first move, the most common trap, and a single measure that tells you whether it is working.
The six pillars of PROPEL
1. Platform — decouple software from hardware
The Platform pillar sits in the Operate stage of the loop. In a mature organisation, hardware is abstracted behind standard vehicle APIs, safety-critical and non-safety workloads are isolated on the same compute, and non-safety services run as containers that can be updated independently of everything else.
The cloud-native practice is containers and declarative, API-first services running on central compute. The AI-native practice is to expose vehicle APIs that models and agents can use safely — through defined, permissioned interfaces rather than back doors. An API-first platform is precisely what allows edge models and in-vehicle agents to use vehicle data without compromising safety or security.
The recommended first move is to define one vehicle API layer and publish it inside the company; COVESA VSS is a sensible starting point. Then containerise one non-safety workload end to end, and use open cores such as Eclipse SDV and SOAFEE wherever you do not differentiate. The trap to avoid is treating a full E/E architecture redesign as a precondition for everything else. PROPEL is designed to work on domain, zonal or central architectures alike. The measure that matters is the number of features shipped without a hardware change.
2. Release — ship continuously, over the air
The Release pillar governs how change reaches the fleet. Good practice means one pipeline and one signed artefact, from commit to vehicle. Rollouts are staged — internal fleet first, then a canary wave, then progressively larger waves — with automatic stop and rollback at every step. OTA is used to deliver new features across domains, not only fixes to infotainment.
The cloud-native practice is CI/CD, GitOps and progressive delivery. The AI-native practice is to release models and agents exactly like software — versioned, staged and reversible — with AI monitoring the health of each wave and flagging anomalies before the next wave begins.
Crucially, release cadence should be set by risk, not by the model year. A map update and a brake-system update should not move at the same speed, and a good pipeline makes that distinction explicit. The value of automated gates is shown by a real incident in which an OTA update from one OEM sent the wrong software build to some of its vehicles and left their infotainment screens inoperative. The OEM handled the incident openly, and the lesson applies to every manufacturer: staged rollouts and automated promotion gates exist precisely because such mistakes can happen to anyone.
The first move is to take one domain beyond infotainment onto staged OTA and automate the promotion gates between every stage. The trap is using OTA only for fixes, with manual steps in between. The measure is the time from an approved change to full-fleet deployment, expressed in days.
3. Observe — turn fleet data into insight
Connected services already give most OEMs a data backbone. The Observe pillar is about using it deliberately: collecting the right data, on purpose, and turning it into engineering insight quickly.
In practice, this means event-triggered collection that captures what matters — including rare ADAS edge cases — rather than streaming everything. It means one signal catalogue and one data platform shared by engineering and AI teams. And it means every release ships with its own health metrics, in the car and in the cloud, so the organisation knows within days whether a change is working.
The cloud-native practice is observability by default, built on telemetry and event-driven data pipelines. The AI-native practice is to treat data as a product, with on-board models selecting the moments worth sending. Data volumes stay small while the value of each sample stays high.
The first move is to deploy data triggers on a development fleet — triggers that can be changed without a new software release — and to route curated edge cases into the test scenario library, so virtual tests replay what the road actually presents. Privacy and consent, including GDPR and the EU Data Act, should be designed in from day one. The trap is collecting everything “just in case”, or leaving data locked in supplier silos. The measure is the time from a field event to an engineering insight.
4. Protect — safety and security by design
In most vehicle programmes, functional safety and cybersecurity are still treated as an aftermath: a large design effort at the start, followed by a documentation effort at the end, both far removed from the code. The Protect pillar, which applies to every stage of the loop, shifts both disciplines left into a continuous practice that lives alongside the software.
In a mature organisation, safety and security requirements sit in the same repository as the code and are traced to the tests that prove them. Every change runs safety, security and SBOM checks in CI. Evidence for ISO 26262, ISO 21448 (SOTIF) and ISO/SAE 21434 is generated with every release rather than assembled by hand before an audit, and the same pipeline feeds the UN R155 and R156 management systems.
The cloud-native practice is DevSecOps and policy-as-code, with SBOM, signing and evidence built into CI. The AI-native practice is governance for models and agents, with AI drafting hazard and threat analyses (HARA and TARA) and proposing traceability links, while engineers review and sign off.
One point needs to be stated clearly: speed never bypasses the safety case. What changes is that the safety case becomes continuous. It grows with every change instead of being written once at the end, and accountability always remains with people.
The first move is to bring safety and security requirements into the repository, linked to tests, and then add a single safety and security gate to CI — static analysis, an SBOM scan and a traceability check. The trap is treating safety and security as end-of-programme paperwork. The measure is the share of safety and security evidence produced automatically with each release.
5. Engineer — go virtual-first
The Engineer pillar covers the Build and Validate stages. Simulation and virtualisation tools already do much of the heavy lifting in modern vehicle development; the pipeline around them is what makes that investment pay off.
Good practice means most integration testing runs on virtual ECUs and digital twins in the cloud, and the same binary runs in the cloud and in the car. Hardware-in-the-loop testing becomes the final gate, not the first.
The cloud-native practice is infrastructure-as-code, on-demand test environments and virtual ECUs. The AI-native practice is AI that co-writes code and tests and generates scenarios and synthetic data for validation.
The first move is to take one flagship function and run it end to end on a virtual target inside CI, then build one shared cloud test farm for all teams rather than one per project. The trap is waiting for prototype hardware before integration can start. The measure is the share of tests run on virtual targets.
6. Learn — AI and agents that improve with every turn
Observe brings the data; Learn turns it into better models and agents, both in the car and in engineering. Every model and agent follows the same disciplined path: curated data from the fleet is used to train, then evaluated in simulation, then run in shadow mode in the fleet, then activated in waves, and finally monitored and retrained.
Learn serves two audiences. For the customer, in-vehicle agents — an assistant, an energy coach, a proactive service advisor — act through vehicle APIs, and each agent has scoped permissions defining what it may read and what it may do. For engineering, agents triage field issues, generate tests and scenarios, and propose fixes; they work inside the same pipeline as everyone else, and humans approve every change.
The cloud-native practice is elastic cloud compute for training, evaluation and simulation at fleet scale. The AI-native practice is a disciplined MLOps and AgentOps lifecycle, in which every model and agent is versioned, shadow-tested and permission-scoped.
The first move is to deploy one agent, shadow-tested in the fleet, with scoped permissions and human approval for any safety-relevant action. The trap is agents with unbounded access. The measure is the time from an insight to an improved model running in the fleet.
The PROPEL mindset
Six pillars need a consistent way of thinking behind them, or they become six disconnected improvement programmes. In the spirit of the Agile Manifesto, PROPEL captures that mindset as seven trade-offs. The items on the right still have value; the items on the left matter more.
Loops over launches
Virtual-first over hardware-first
Automated, declared releases over manual integration
Fleet evidence over lab assumptions
Security built in over security bolted on
A shared open core over rebuilt plumbing
Owned interfaces over supplier black boxes
How PROPEL-ready is your organisation?
A framework is only useful if it tells you where to start. PROPEL includes a simple maturity model with three levels for each pillar. At Level 1 (Manual), work is hardware-bound and done by hand. At Level 2 (Automated), pipelines are in place but the loop is still open. At Level 3 (Closed-loop), the pillar feeds the loop continuously — this is the PROPEL target.
To use it, select the level that is true for most of your programmes, not your best one; if in doubt, choose the lower level. The total score ranges from 6 to 18. The score itself matters less than its shape, because your lowest pillar sets your speed. A loop can only turn as fast as its slowest stage.
Consider an illustrative OEM — not a real company — that scores Level 2 on Platform, Release, Protect and Engineer, but Level 1 on Observe and Learn, for a total of 10 out of 18. The profile shows exactly where its loop is broken: it cannot see its fleet clearly, and it cannot learn from what it sees. The first move follows directly — data triggers on a development fleet, and one model shadow-tested through the pipeline. The score is best used to track an organisation’s own progress over time, not to compare companies.
Adopting PROPEL in 30, 90 and 300 days
The most common failure mode for frameworks like this is to launch them as a large transformation programme. PROPEL is designed to be adopted the other way round: start small, prove one loop, then scale it.
In the first 30 days — See, score your PROPEL maturity, choose one function and one fleet to work with, name a platform owner, and create an SBOM. By 90 days — Prove, that function should be tested on a virtual target in CI, you should have run one signed, staged OTA release with rollback, and one data trigger should be feeding insight back into engineering. By 300 days — Scale, the same pattern should be running across more teams, staged OTA should be reaching customer vehicles, and safety and security evidence should be produced with every release.
Throughout, safety-relevant domains keep their own validation and homologation cadence. PROPEL accelerates the pipeline around them; it does not change the rules they must meet.
The car that learns fastest wins
The automotive industry does not lack technology. What it often lacks are fast, closed loops between the fleet, the engineering organisation and the next release.
The car that learns fastest wins. Cloud-native builds the loop. AI makes it learn.
PROPEL offers a practical route to get there — on the architecture you have today, with the teams you have today. My recommendation is simple: do not begin with a transformation programme. Begin with one function, one fleet and one loop, and let the results make the case for scaling.
I would welcome your perspective. Where does your organisation sit on the maturity model, and which pillar is holding your loop back?
The PROPEL framework was first presented at the SDV & AV Technology Summit Europe 2026 in London. It is vendor-neutral; the open standards and projects mentioned are illustrative examples, not endorsements. The views expressed are the author’s own.
© 2026 Vaisakh Venugopal · vaisakhvenugopal.com
References
Industry data
McKinsey & Company (2025) — concept-to-production timelines of new Chinese EV makers versus established OEMs.
NHTSA recall data (2024) — share of Tesla recalls resolved over the air.
UNECE — UN Regulation No. 155 (Cybersecurity) and No. 156 (Software Update); mandatory for all new EU vehicles from July 2024.
Cross-industry examples
3GPP TS 23.501 — System architecture for the 5G System.
US Air Force (October 2020) — in-flight software update of an operational aircraft.
Xiaomi (2024) — single operating system across phone, home and car.
Engineering methods
Adam Wiggins (2011) — The Twelve-Factor App, 12factor.net.
Kevin Hoffman (2016) — Beyond the Twelve-Factor App, O’Reilly.
Manifesto for Agile Software Development (2001), agilemanifesto.org.
Standards and regulations referenced in the pillars
ISO 26262 (functional safety), ISO 21448 (SOTIF) and ISO/SAE 21434 (cybersecurity engineering).
General Data Protection Regulation (GDPR) and the EU Data Act.
Open projects referenced in the pillars
COVESA Vehicle Signal Specification (VSS), Eclipse SDV and SOAFEE.