A System of Operating Systems: E/E Architecture, the Vehicle OS and the AI-Defined Vehicle

Abstract

“Vehicle OS” has become a word every carmaker that wants to be called software-defined must own. Yet the things called “OS” are not the same kind of thing at all. This article starts with an ontology cleanup: a cockpit OS is not a vehicle OS, a domain OS is not a vehicle OS, and a runtime is not an OS. Every vehicle OS in production today — MB.OS, NIO SkyOS, Li Auto HaloOS, Pleos Vehicle OS — is a multi-kernel assembly governed by a single vehicle-wide control plane. We break that control plane into three observable parts — contract, orchestration and lifecycle — and from them derive a six-dimension Vehicle OS Capability Matrix (VOCM), which we use to give 15 carmakers an initial assessment, set against D2’s AR scores.

The core of the article is a causal structure. The E/E architecture sets the boundary of what a vehicle OS can be; but once functions become software, causality reverses — software workloads begin to design the next E/E architecture (the Architecture–OS Co-Evolution Loop). On top of that, we argue that autonomous driving is the stress test of whether a vehicle OS is real; that AI thins the top half of the OS and thickens its bottom half; and that what the industry is actually standardizing is the vehicle API, the data model and the runtime contract — not “one automotive OS.” The conclusion delivers three judgments and one warning, with five revision triggers.

---

A Note on Genre

This article belongs to the Deep Dive track, not the Working Paper track. The dividing line is not length but level of commitment:

• Working Papers (D1–D4, Zenodo DOIs) = locked claims. Never silently revised; built to survive five years of citation.
• Deep Dives (this track) = disciplined observations. Revisable, refutable, explicitly labeled “this is what we see right now,” outside the DOI system.

This article inherits the Working Papers’ epistemic discipline — source tiering, traceable evidence, mandatory counter-arguments and failure modes — but not their finality. It does not revise any published conclusion of D1–D4; the D2 scores it cites are those of the published version. Evidence grades are marked in the text as [T1], [T2], [T3] and [inference]; see Appendix A. Its conclusions carry their own revision triggers (Chapter 10); if any trigger fires, a revised edition will be published with changes marked.

---

Introduction: a word everyone uses and no one defines

In June 2025, the first CLA running MB.OS rolled off the line at Mercedes-Benz’s Rastatt plant [T1]. In the same period NIO called its SkyOS a “full-domain vehicle operating system,” Li Auto open-sourced HaloOS under Apache 2.0, Toyota launched Arene with the new RAV4, and Hyundai split Pleos into two brands, “Vehicle OS” and “Connect.” By 2026, “vehicle OS” had become a word every carmaker that wants to be called software-defined must own.

The problem is that the things called “OS” are not the same kind of thing at all.

Android Automotive is an OS. BMW Operating System X is called an OS. NVIDIA DriveOS is called an OS. AUTOSAR is sometimes mistakenly called an OS. MB.OS, SkyOS, HaloOS and Pleos Vehicle OS are all OSes too. Put them in one table and rank them, and you are comparing apples, oranges and orchards.

This research series has touched the word three times without stopping to define it. D1 listed the OS as C3 among seven architectural control points, wrote RTOS, AUTOSAR and middleware into the software layer of E/E architecture, and argued in §3.4 that the hypervisor is the bridge between open ecosystems and hard real-time. D2, in its Mercedes profile, explicitly separated MMA (the hardware platform) from MB.OS (the software operating system) and warned readers not to conflate them. DD-08, The Driver Exits, argued that once the human driver leaves the fallback chain, fail-operational turns from a premium option into a condition of entry.

All three point to the same empty slot: between “electrical and electronic topology” and “intelligence,” which layer turns a pile of controllers into a machine that can be programmed, can keep evolving, and can eventually carry autonomous driving and AI?

That is the question this article answers. There is a single master question:

Under what conditions does an E/E architecture stop being merely an electronic topology and become the platform of a “programmable car”?

Our answer compresses into four sentences, which also form the skeleton of the article:

E/E is the substrate. The control plane is the OS. AI is the adaptive intelligence. Autonomy is the stress test.

Unpacked, they become six judgments:

• T1 | Definition: The vehicle OS is not one operating system but a “system of operating systems” governed by a vehicle-wide control plane. Control plane = contract + orchestration + lifecycle.
• T2 | Precondition: Without a sufficiently decoupled E/E architecture there is no vehicle OS. The ceiling of software abstraction is set by the physical architecture.
• T3 | Reversal: Once functions become software, causality reverses — software workloads begin to design the next E/E architecture. This is the article’s core original contribution: the Architecture–OS Co-Evolution Loop.
• T4 | Stress test: Autonomous driving is not the vehicle OS; it is the workload that tests whether a “vehicle OS” deserves the name.
• T5 | Governance: AI will not eliminate the OS. It thins the OS’s top half and thickens its bottom half — probabilistic intelligence must run inside deterministic governance.
• T6 | Point of convergence: What the industry is actually standardizing is not “one automotive OS” but “vehicle API + data model + runtime contract.” Kernels are commoditizing, and control point C3 is being squeezed from both sides by C2 (silicon) and C4 (middleware).

Let us start with the most basic task: cleaning up the word.

---

1. The Naming Problem: not everything called “OS” is an OS

1.1 An ontology cleanup

In computer science, “operating system” has a fairly clear meaning: the layer of software that manages hardware resources and gives the programs above it abstraction and isolation. Linux, QNX and the various RTOSes all fit. The trouble is that the auto industry applies the same word to at least four different levels:

• Kernel-level OS: QNX, Linux, the Classic AUTOSAR OS, RTOSes, microkernels. They manage one chip or one ECU.
• Runtime and middleware: AUTOSAR Adaptive Platform, SOME/IP, DDS, ROS 2. They define communication, service discovery and execution management, but they themselves run on top of a kernel — the Adaptive Platform’s target hardware runs a POSIX PSE51-compliant operating system, and AP is built on top of it [T2].
• Domain OS: Android Automotive, BMW OS X, NVIDIA DriveOS, the HarmonyOS cockpit. They manage one functional domain, such as the cockpit or the driving computer.
• What OEMs call the “vehicle OS”: MB.OS, SkyOS, HaloOS, Pleos Vehicle OS. They claim to manage the whole car.

The first three levels have clear engineering boundaries. The fourth does not. It is a brand name, an organizational commitment, and a body of software spanning multiple kernels, domains and chips. The whole of this article is an attempt to give that fourth level a testable definition.

1.2 Three discrimination rules

Before defining it, we offer three negative rules. Their job is to rule out what does not count as a vehicle OS.

Rule 1: cockpit OS ≠ vehicle OS.

BMW Operating System X is AOSP-based and handles the display, interaction and digital experience of Panoramic iDrive [T2]; the actual vehicle architecture of the Neue Klasse is four “superbrains” — for infotainment, automated driving, driving dynamics and basic functions — plus zonal controllers [T1–T2]. Hyundai’s split is even cleaner: Pleos Connect is an Android Automotive-based infotainment system, scheduled for launch in Q2 2026; Pleos Vehicle OS is a vehicle-control OS built on a high-performance vehicle computer and zonal controllers [T2–T3]. That a company splits the two into separate brands is itself the best evidence: the system that looks best on the cockpit screen is not the system that can control the car.

Rule 2: domain OS ≠ vehicle OS.

NVIDIA DriveOS is an operating system and runtime for accelerated computing, sensor integration, automated driving and the AI cockpit; DriveOS 6.0 has been certified to ISO 26262 ASIL D by TÜV SÜD [T2]. It is one of the strongest products in its field. But what it manages is the DRIVE compute domain, not the vehicle-wide functions that include body, thermal, energy and chassis.

Rule 3: runtime ≠ OS.

AUTOSAR Adaptive defines behavior: execution management, communication, storage, security. It depends on a POSIX kernel below and on OEM integration above. Calling it “an OS” is like calling TCP/IP the network itself.

The three rules share one implication: the name is not a criterion. What is called an OS may not be a vehicle OS (BMW OS X is not); what is not called an OS may in fact be a vehicle-wide platform (Tesla has never given its software stack an OS brand, and neither has Rivian). Toyota’s shifting vocabulary makes the point sharper: in April 2023 Toyota officially described Arene as “a comprehensive software platform and vehicle operating system” [T1]; by the time it reached production with the new RAV4 in 2025, Toyota and the press more often called it a “software development platform” [T2]. This is not wordplay. It raises a question Chapter 4 returns to: does the control point of a vehicle OS lie in the runtime, or in the software lifecycle?

1.3 China’s taxonomy: an answer backed by national standards

On the question of definition, China has gone further than any other region, because it has written the answer into national standards.

In 2019, the National Technical Committee of Auto Standardization published the Vehicle Operating System Standard System, dividing vehicle operating systems into two classes: vehicle-control operating systems and in-vehicle operating systems [T1]. Vehicle-control OSes are further split into safety vehicle-control OSes (powertrain, chassis, body — with the strictest real-time and safety requirements) and intelligent-driving OSes (for driving domain controllers); in-vehicle OSes serve the center console, instrument cluster and T-box.

On March 31, 2026, this taxonomy became two recommended national standards, effective July 1 of the same year [T1]:

• GB/T 47351-2026: vehicle-control operating systems, defining Type I (intelligent-driving OS) and Type II (safety vehicle-control OS).
• GB/T 47341-2026: technical requirements and test methods for in-vehicle operating systems. According to excerpts of a commercial translation, it defines the in-vehicle OS as “the set of software that provides intelligent connected vehicles with services other than the implementation of driving-automation functions,” and recommends ASIL B or higher for in-vehicle OSes supporting high-real-time scenarios such as cluster warnings [T3: commercial translation, not the standard text].

According to public reports, the list of drafting organizations is itself an industry map: Huawei (Yinwang), Horizon Robotics, Qualcomm, NIO, BYD, Li Auto, Mercedes-Benz China and Volkswagen China are among them [T2].

The value of the national standards is that they split operating systems by functional-safety attribute rather than by brand. But they also leave a gap: there is a vehicle-control OS and an in-vehicle OS, but no “vehicle OS.” Of the four-way split common in academia and industry — safety vehicle-control OS, intelligent-driving OS, intelligent-cockpit OS and the cross-domain “central computing OS” — the fourth has no counterpart in the standards. [inference] That gap is exactly where the marketing concept of the “vehicle OS” lives, and exactly what this article sets out to pin down with the idea of a control plane.

1.4 So is the vehicle OS a false proposition?

Let us put the sharpest objection on the table first: strip away the brand layer and the so-called vehicle OS is just QNX + Linux + AUTOSAR + a hypervisor + a pile of middleware — all of which existed ten years ago. What is left?

Our answer: as a brand, it is overstated; as an engineering entity, it is real. What remains is not any single kernel, but the thing that organizes multiple kernels, domains and chips into one car — a unified service contract, orchestration across criticality levels, and an update-and-validation system that spans the vehicle’s whole life. The next chapter takes it apart.

---

2. A System of Operating Systems: taking a “vehicle OS” apart

2.1 Every production vehicle OS is a multi-kernel assembly

Open up any vehicle OS in production and you find not one kernel but a family.

NIO SkyOS uses a “1+4+N” structure [T2]: the “1” is SkyOS-H, a hypervisor managing heterogeneous compute; the “4” are four kernels for different scenarios — the vehicle-control kernel is based on the formally verified seL4 microkernel, and the cockpit kernel on a deeply customized Android; the “N” are in-house middleware components for cross-domain coordination and lifecycle upgrades. [T3: sources differ on the exact division of labor among the remaining sub-kernels; we do not go into it here.] SkyOS was fully released on July 27, 2024 and runs at full scope on NT3-platform models [T2].

Li Auto HaloOS is a three-part set: a vehicle-control OS, an intelligent-driving OS and a communication middleware [T2]. On March 27, 2025, Li Auto announced it would open-source the system; it released 0.1.0 in April (safety real-time RTOS plus a lightweight communication bus), 1.0.0 on June 30, and subsequently opened its virtualization engine [T2]. Li Auto says it invested more than 200 people and over RMB 1 billion, shipped the first production version in 2024, and cut chip adaptation from 3–6 months to four weeks [T2, company claim].

Hyundai Pleos splits vehicle-control OS and cockpit OS into two brands (see 1.2). GB/T 47351 splits the vehicle-control OS itself into Type I and Type II.

There is only one conclusion, and it is the article’s first thesis:

T1 | The vehicle OS is not one operating system, but a “system of operating systems” governed by a vehicle-wide control plane.

2.2 A six-layer stack model: S0–S5

To put different vendors’ products into one picture, we propose a six-layer stack model (Figure 2.1).

Around it sits an outer ring that is not on the vehicle but decides what the vehicle can do: cloud, OTA, the data loop, DevSecOps, and the newly emerging model lifecycle.

Figure 2.1 — A System of Operating Systems: the S0–S5 stack and the outer ring. Reading note: the vehicle OS is not any single layer in the figure but S4’s unified governance of S1–S3; S0 decides how much S4 can govern; the outer ring decides whether S4 can keep evolving after the car is sold.

2.3 The three parts of the control plane: contract, orchestration, lifecycle

“Control plane” is borrowed from network engineering: the data plane forwards each packet, the control plane decides where packets should go. In a car, the data plane is the processes, tasks and signals actually running in S1–S3; the control plane is the layer that decides who may run where, at what priority, through which interface, and under what conditions it may be replaced.

We break the vehicle control plane into three parts:

1. Contract: service interfaces, the vehicle API, signal and data semantics. It promises that “functions are decoupled from the physical location of ECUs” — an HVAC control service does not need to care which chip it ends up running on.
2. Orchestration: mixed-criticality scheduling, proof of isolation (freedom from interference), function migration, resource arbitration. It decides how an ASIL D braking function and QM-level music playback share one chip without interfering.
3. Lifecycle: OTA, rollback, diagnostics, DevSecOps, and now the model lifecycle. It decides how much the car can still be changed after it leaves the factory, how fast, and under what safety argument.

Seen through these three parts, the rules in 1.2 become much clearer: a cockpit OS has a contract only for the cockpit domain; a domain OS has strong orchestration but only within one domain; a runtime specifies contracts but takes no responsibility for vehicle-wide orchestration or lifecycle. We call something a vehicle OS only when contract, orchestration and lifecycle together cover the vehicle’s main domains.

This definition has one immediate advantage: it is observable. If a carmaker claims to have a vehicle OS, we need only ask three questions — which domains does its vehicle API cover? What certification level has its mixed-criticality integration reached? Which domains can its OTA update? The VOCM scoring in Chapter 5 unfolds these three questions into six dimensions.

2.4 An underrated fact: extreme concentration at the bottom, extreme fragmentation at the top

Project each vendor’s products onto S0–S5 and a stark picture emerges:

• At S1, the market is extremely concentrated. BlackBerry’s FY2026 annual report discloses that QNX is embedded in more than 275 million vehicles, up 20 million year on year, working with 45+ automakers and covering the top 10 OEMs and 24 of the top 25 EV OEMs [T1]. QNX OS for Safety and QNX Hypervisor for Safety are both certified to ISO 26262 ASIL D [T1].
• At S4, the market is extremely fragmented. More than ten carmakers each claim their own vehicle OS, none compatible with the others.

This is D1’s two-layer convergence–divergence model reappearing at the software layer: infrastructure converges at the bottom, control semantics diverge at the top. It also foreshadows the contest Chapter 7 discusses — if S1 and S2 are bound to commoditize, where does the value go?

---

3. The Road Before the Car: E/E sets the boundary of what an OS can be

3.1 Why no vehicle OS grows on a distributed architecture

Picture a conventional car with 100 ECUs. Each runs its own OSEK or Classic AUTOSAR, each comes from a different Tier 1, each has its own software version, calibration data and flashing process. In such a car a vehicle OS is physically impossible — there is no place for a unified runtime to live, and no channel wide enough for a service contract to cross ECU boundaries.

This is the article’s second thesis:

T2 | Without a sufficiently decoupled E/E architecture there is no vehicle OS. The ceiling of software abstraction is set by the physical architecture.

3.2 Five enablers

As E/E architecture moved from distributed to domain-based and then to zonal plus central compute, five things made the vehicle control plane possible in engineering terms (mapping to the Bosch six-stage framework in D1, Chapter 2):

Of the five, the first four decide whether the control plane can be unified; the fifth decides whether it can be trusted. Without the first four there is no vehicle OS; without the fifth, the vehicle OS stays in the fail-soft world — a point Chapter 6 develops.

3.3 The generation matrix: which layer each E/E generation can host

Cross S0–S5 with E/E generations (Figure 3.1) and a simple pattern appears:

• Distributed: S1 only (each ECU’s own RTOS).
• Domain: S2 and S3 appear — Android in the cockpit, Linux / QNX for driving, intra-domain SOA. But each domain runs its own show; most “vehicle OS” claims of this generation were marketing.
• Cross-domain fusion: partial S4 appears — two or three domains begin to share contracts; cockpit–driving integration is tried.
• Zonal + central compute: S4 truly becomes engineering reality.
• Central + AI-native: S5 begins to appear.

Figure 3.1 — What each E/E generation can host. The x-axis is the E/E generation (distributed → domain → cross-domain fusion → zonal + central → central + AI-native); the y-axis is S1–S5. Each cell is marked “not feasible / partial / in production / emerging.” Reading note: S4’s “in production” cells appear only from the zonal + central column onward; most products labeled “vehicle OS” before that actually sit in S3.

The matrix yields a falsifiable corollary: if someone builds a control plane covering the vehicle’s main domains without changing the E/E generation, T2 must be revised. We list it as one of the revision triggers (Chapter 10).

---

4. Causality Reversed: when software starts designing hardware

4.1 From “E/E supports the OS” to “the OS designs the E/E”

Chapter 3 described one direction: E/E first, OS after. It is the story the industry tells most often — and the less complete half.

The other half: once a carmaker has truly built a vehicle control plane, it starts deciding the next E/E architecture in return.

GM offers a rare example published by the carmaker itself. It says its 2028 central computing platform brings 10× the OTA capability, 1,000× the bandwidth and 35× the AI compute [T1, company claim]. None of these three numbers is defined from “better hardware”; all of them are hardware specifications derived backward from what the software must do.

Leapmotor’s Tech Day in September 2026 offered a second, more detailed example. Leapmotor presents its E/E evolution as a clear generational line:

• LEAP 3.0: the “Four-Leaf Clover” centrally integrated architecture, launched in 2023.
• LEAP 4.0: single-chip cockpit–driving integration on the D platform [T3].
• LEAP 5.0: the upcoming “Four-Leaf Clover 5.0,” with three changes [T2–T3]:
  • Control: centrally integrated control.
  • Power: a 48V vehicle-wide supply, total wiring under 500 meters, harness weight cut by up to 50%, and — per the company — wiring heat loss reduced to 1/16.
  • Network: vehicle-wide Ethernet with an asymmetric bandwidth scheme — 10G downstream, 100M upstream.
• Production: first models in 2027 [T2].

The last network item deserves a pause. Symmetric bandwidth is the logic of a general-purpose network; asymmetric bandwidth means the network is designed around how data actually flows — which direction carries heavy traffic and which only carries control and status. [inference] This is a network topology defined by software and data flows: first know how the control plane must move data, then decide how to lay the wires. The 48V supply and the shorter harness follow the same logic — central control lets power distribution and wiring be reorganized around “one brain plus a few zones” instead of “one box per function.”

This is the article’s core thesis:

T3 | Once functions become software, causality reverses: software workloads begin to design the next E/E architecture.

Put the two directions together and you get a closed loop (Figure 4.1):

E/E architecture → vehicle control plane → workloads / data / AI → next-generation E/E architecture

We call it the Architecture–OS Co-Evolution Loop.

Figure 4.1 — The Architecture–OS Co-Evolution Loop. Reading note: the loop’s upper half (E/E → OS) is the “possibility boundary,” made of Chapter 3’s five enablers; its lower half (OS → E/E) is “reverse design,” made of the six classes of requirement in the table above. Whether a carmaker has entered the software-defined stage is judged not by whether it has an OS brand but by whether the lower half has started turning.

To be clear, this loop is not yet another maturity ladder. The series already has AR0–AR5 (capability thresholds of the designed system) and AI²-ML (maturity of the toolchain). The co-evolution loop describes a causal structure, not a grade.

4.2 The dumbing-down spectrum: a disagreement about trust

The most visible expression of the loop’s lower half is how far zonal controllers are “dumbed down” — whether critical control logic stays in the zones or moves to the center.

At one end is GM. Its zonal “aggregators” explicitly “execute no control logic”; all intelligence — sensor fusion, control arbitration, machine-learning inference — sits in the central computer [T1]. This is the fully dumbed-down route.

At the other end is BMW. The Neue Klasse puts driving dynamics on a dedicated high-performance computer called the “Heart of Joy,” ten times faster than a conventional ECU [T2]; infotainment, automated driving and basic functions each have their own superbrain. This is the “critical control stays out of the center” route.

Further out still is the conventional architecture with control logic spread across many ECUs.

Figure 4.2 — The dumbing-down spectrum of zonal controllers. Left to right: distributed ECUs → BMW-style “critical control on independent compute” → GM-style “aggregators only forward; all intelligence in the center.” Reading note: the x-axis is not “how advanced” but “how much trust is placed in the central control plane to carry the ASIL D execution chain.”

[inference] The disagreement looks like a dispute over hardware topology; in substance it is a question of trust: is the determinism of the central control plane already good enough to be trusted with the ASIL D execution chain? GM’s answer is “yes,” BMW’s is “not entirely.” There is no standard answer, but the direction of causality is clear — it is a judgment about the OS’s capability that is deciding the E/E topology.

4.3 An observable proxy: OTA granularity

The coverage of a control plane is hard to observe from outside — carmakers do not publish their vehicle API catalogs. But one thing is observable: which domains OTA can update.

The new Toyota RAV4 is a clean example: with Arene, the cockpit and ADAS can be updated over the air, but body and dynamics functions cannot yet [T2]. [inference] This indicates that Arene’s contract does not yet cover the vehicle-control domain. Conversely, a carmaker that can update brake or powertrain calibration over the air has brought the safety-critical execution chain under lifecycle management.

We therefore use OTA granularity as an external proxy for “control-plane contract coverage,” and use it in VOCM dimension V5 (Chapter 5). It is not perfect — being OTA-capable is not the same as being well architected — but it is one of the few indicators verifiable from public information.

4.4 The other face of Conway’s law: E/E and OS delivered by one organization

D3 discussed Tesla’s merger of its FSD and Optimus teams, using organizational structure to shape technical architecture. On the E/E–OS relationship there is newer and more direct public evidence.

In its 2026 proxy statement, Rivian defines RV Tech, its joint venture with Volkswagen Group, as an “electrical architecture technology company with a focus on software, electronic control units and related network architecture” [T1]. In other words, E/E topology, ECUs and software are one deliverable in this company.

Rivian’s FY2025 figures show the economic weight of that deliverable: software and services gross profit rose from USD 7 million in 2024 to USD 576 million, driven mainly by “vehicle electrical architecture and software development services” related to the joint venture [T1].

[inference] The significance of these numbers lies not in the amount but in the unit of pricing: “E/E + OS” can now be priced and traded as a whole. Once an architecture can be sold on its own, it is no longer an accessory of a car but an asset. Here the co-evolution loop acquires a balance-sheet counterpart.

Volkswagen Group goes further still: it runs two E/E architectures delivered by different organizations at the same time — RV Tech in the Western Hemisphere and CEA in China. Section 5.5 returns to this.

4.5 Backward compatibility: the price of the loop, and the acid test of the contract

The co-evolution loop has an easily overlooked side effect: while the next E/E is being redesigned by software needs, the previous generation of cars is still on the road. Can they keep receiving new software? This leads to a stricter question than “can it do OTA?”:

Can a vehicle OS be backward compatible — letting cars on the previous, or even the one before, hardware generation keep gaining new-generation software capabilities over the air?

Our answer: backward compatibility is the strictest external test of whether hardware–software decoupling is real; but it should be judged by whether the contract is stable, not by whether features are equal. There are four reasons.

First, it is the only form of decoupling that can be tested from outside. Every carmaker says it has decoupled hardware and software. But if new software runs only on new hardware, the “decoupling” is really “re-integrating every generation.” Decoupling is proven only when new-generation software can be deployed to old hardware through the same contract.

Second, the installed fleet is the denominator of the software economy. Software subscriptions, paid features and the data loop all scale with the number of vehicles that can receive updates. Cut off old cars at every generation and the denominator of software revenue periodically resets to zero.

Third, regulation has already written compatibility into the update process. Paragraph 7.1.1 of UN R156 requires a manufacturer’s software update management system to include a set of processes, among them: identifying the target vehicles of an update (7.1.1.6), confirming the compatibility of an update with the target vehicle configuration before it is issued (7.1.1.7), identifying interdependencies of the updated system with other systems (7.1.1.5), and maintaining the RXSWIN software identification before and after an update (7.1.1.3) [T1]. Backward compatibility is not just a user-experience question; it is an item the update management system must answer.

Fourth, it exposes the tension in the loop. If the next E/E must keep the same contract for older cars, the contract locks in the E/E’s evolutionary path — exactly where the value and the cost of a control plane appear together. Drop the contract and you give up the installed fleet; keep it and the new architecture carries old interfaces.

But backward compatibility cannot mean feature parity. Compute, sensor sets and redundancy are physical facts that OTA cannot change. D3 already discussed the generational break between Tesla’s HW3 and newer FSD versions: when the hardware gap is too large, even the most aggressive software-defined player cannot make old hardware run every new capability.

A better way to judge borrows from the smartphone industry — contract stability under capability tiering:

Leapmotor’s Tech Day offered a public example of Level 3: its LWM world-model driver assistance reportedly cuts code volume by 90%, can be deployed on 200, 640 and 1,280 TOPS compute tiers, and comes with a commitment of free upgrades and lifetime free use for all LiDAR-equipped vehicles — around 350,000 existing cars according to press reports [T3, company claim]. [inference] “One model, multiple compute tiers” is itself a design for backward compatibility — it turns capability differences from “have or have not” into “more or less.”

We therefore fold backward compatibility into the scoring rubric of VOCM’s V2 (hardware–software decoupling; Appendix B): V2 can score 4 or higher only when software capability is shown to be deliverable across hardware generations. It is not a seventh dimension because it is essentially a test of decoupling rather than an independent capability.

4.6 Summary: to tell whether a carmaker has a vehicle OS, look at the lower half

This chapter’s conclusion doubles as a practical test:

Do not ask whether a carmaker “has a vehicle OS.” Ask whether its lower half has started turning — is its next E/E specification being defined by the needs of the current generation’s software?

If yes, it has entered the software-defined era. If not, whatever its OS brand is called, it is still at the stage of “hardware-defined, software-filled.”

There is a second question: is the previous generation of cars still on the same contract? The faster the lower half turns, the sharper this question becomes.

---

5. The Table in 2026: who is doing what, and how far they have got

5.1 Don’t ask “is it mature?” — ask “which layer is mature?”

“Is the vehicle OS mature?” has no answer, because the layers are an era apart.

The overall judgment:

2026 is the year the vehicle OS moved from “architectural ambition” into “early production reality.” It is no longer a slide, but it is far from a stable industry paradigm like Android / iOS.

By production status, the main players fall into four tiers. Note that this is a descriptive tiering, not a new maturity ladder:

• M1 Infrastructure at scale (hundreds of millions / millions of vehicles): QNX, Classic AUTOSAR, the HarmonyOS cockpit, Android Automotive.
• M2 OEM full-domain control plane in production: MB.OS (CLA), SkyOS (NT3 platform), HaloOS, BMW Neue Klasse, Tesla.
• M3 First launch or partial-domain production: Toyota Arene (RAV4; body and dynamics not yet OTA-updatable) [T2]; Hyundai Pleos Connect (first launch Q2 2026, infotainment only) [T2–T3]; Rivian’s second-generation platform.
• M4 On the roadmap or being restructured: GM’s central computing platform (2028, debuting on the Cadillac Escalade IQ) [T1]; Stellantis STLA Brain (originally due for integration by end-2024, now first integrated with the STLA One platform in 2027) [T1–T2]; the Volkswagen Group × Rivian RV Tech architecture (winter testing completed in Q1 2026, debuting with the ID.EVERY1 in 2027) [T1]; Hyundai Pleos Vehicle OS and its centralized zonal architecture (2030 target) [T3].

Volkswagen Group’s China architecture, CEA, is already past this tier: it entered production in Anhui at the end of 2025 and launched with the ID. UNYX 07 in January 2026, with whole-vehicle OTA support according to the company [T1] — an M3 case.

A recurring pattern is worth noting: almost every carmaker in M4 is behind its own original schedule. Volkswagen Group’s software subsidiary CARIAD is the most closely watched example: the unified software platform it was meant to deliver slipped repeatedly, the company went through major restructuring and job cuts from 2025 [T3], and the next-generation Western architecture is now delivered by RV Tech. [inference] The cause of delay is rarely the kernel or the chip; it is usually the organization — turning dozens of functional silos into one platform organization is far harder than writing a hypervisor. Chapter 9 returns to this.

5.2 By role, not by brand: nine kinds of player

Players with entirely different roles sit at the vehicle OS table. Ranking by brand mixes them up; classifying by architectural role shows who is actually competing with whom.

5.3 VOCM: scoring the vehicle control plane on six dimensions

To measure players in roles ① to ④ with one ruler, we propose the Vehicle OS Capability Matrix (VOCM). It unfolds Section 2.3’s “contract + orchestration + lifecycle” into six dimensions, each scored 0–5, for a maximum of 30. The rubric is in Appendix B.

How VOCM relates to the series’ existing frameworks — this must be stated clearly to avoid double counting:

• AR0–AR5 measures the architectural capability thresholds of the designed system (the vehicle), mainly hardware topology and system integration; VOCM measures only the software control plane. They are orthogonal: a carmaker may score high on AR and low on VOCM or vice versa — and that mismatch is precisely where the analytical value lies.
• AI²-ML measures the maturity of architecture toolchains — a different object altogether. VOCM’s V2 and V5 resemble AI²-ML’s D2 (HW/SW decoupling) and D3 (OTA) in name, but the former look at software in the car, the latter at the tools used to design the car.
• VOCM is not a maturity ladder and defines no “VOCM levels.” It is a six-dimension capability profile.

5.4 Initial assessment

The table below gives VOCM’s initial assessment, set against D2’s AR snapshot scores (Snapshot 2026.1.31, five-dimension total out of 25, cited here, not re-scored).

Scores rest on public sources only. Confidence H / M / L reflects evidence strength: H = most dimensions directly supported by Tier 1–2 evidence; M = some dimensions rely on company claims; L = most dimensions rely on secondary sources or inference. As in D2, for carmakers whose flagship architecture is in production but whose fleet has largely not switched, the table scores the latest production architecture and says so in the notes.

Not scored (insufficient evidence this round): Ford, Lucid, Geely, GWM, SAIC, Stellantis, Renault, Kia.

Leapmotor is not among D2’s 22 OEMs, so it has a VOCM score but no AR score and does not appear in the Figure 5.1 scatter. Basis for its score:

• V1, V3: centrally integrated architecture since LEAP 3.0; single-chip cockpit–driving integration in LEAP 4.0 [T3].
• V2: its world model can be deployed across three compute tiers, with free delivery promised to existing LiDAR-equipped vehicles [T3, company claim].
• V6: vehicle–cloud AgentOS [T3].
• The remaining dimensions rest on secondary reporting; confidence is low.

The score will be updated once LEAP 5.0 reaches production in 2027.

Notes:

• Mercedes is scored on MB.OS as first launched in the CLA.
• Volkswagen Group is scored on its China CEA architecture (ID. UNYX 07). Public basis: zonal control with quasi-central computing, roughly 30% fewer control units, whole-vehicle OTA support, coverage of all powertrains — battery-electric, hybrid and combustion [T1]; a new CEA generation every two years (2.0 in 2027, spanning A- to D-segment models), with driving compute planned on both XPeng’s Turing chip and a CARIZON solution (Volkswagen’s joint venture with Horizon Robotics) [T3]. CEA was co-developed with XPeng and inherits its architecture lineage, so where public information on V1, V3, V4 and V5 is thin, the scores reference XPeng’s [inference] — the same-lineage exception to Appendix B’s “no higher than 2 without evidence” rule. V6 sits one point below XPeng: driving compute comes from two suppliers, and public sources do not show XPeng’s end-to-end / VLA joint scheduling with the OS running on CEA.
• The RV Tech architecture is not yet in production (2027) and is not scored this round; it will be updated after launch. The company says “powerful modular central computers control all vehicle functions” [T1]. If that holds in production, its V1 would reach 4–5 directly.

Figure 5.1 — E/E architecture × vehicle OS capability. X-axis: D2’s AR snapshot total (/25); y-axis: VOCM total (/30). One point per carmaker; hollow points indicate low confidence. The dashed line is the parity diagonal (equal share of each scale’s maximum); the shaded band is the sample trend line ±2.5 points (fitted without VW CEA). Reading note: carmakers inside the trend band have control planes evolving in step with their E/E; the points clearly off the band are the ones worth questioning.

5.5 Reading the chart: four findings

Finding 1: AR and VOCM move closely together, but the control plane trails by half a step. Apart from VW CEA, the 13 points in Figure 5.1 almost form a straight line: the fitted slope is about 1.2 — exactly the ratio of the two scales’ maximums (30/25) — and every point lies within 3 points of the trend. This is itself evidence for T2 — wherever the E/E has got to, the control plane has roughly got there too. But the trend line as a whole sits about 3 points below the parity diagonal: normalized to each scale’s maximum, the industry’s control planes generally trail its E/E by about a tenth. [inference] This matches the co-evolution loop: its upper half (E/E setting the possibility boundary) has been turning for years, while its lower half (software reverse-designing the E/E) has only just started. Among carmakers with an AR score below 15, only VW CEA has a VOCM above 15; Finding 4 explains why.

Below the trend band are the carmakers whose “E/E leads the control plane”: Toyota most clearly, with Rivian at the lower edge of the band. [inference] For Toyota this means the hardware architecture has moved first while Arene’s contracts have not yet caught up — consistent with the OTA-granularity observation in 4.3. Rivian is different: its E/E is among the most aggressive in the sample, but public disclosure of its software stack is the thinnest; its lower score reflects missing evidence (low confidence) more than missing capability.

Finding 2: Chinese new entrants score generally high on V4 and V2. Li Auto’s open-sourcing of HaloOS, Huawei’s cross-brand ecosystem and Xiaomi’s “human–car–home” ecosystem all treat openness as strategy. [inference] This fits China’s environment of standards-first, supply-chain co-building — when interfaces are standardized, the cost of opening them falls and the benefit rises.

Finding 3: within the same AR tier, Mercedes has the highest control-plane score. Mercedes and BYD are both AR2.5 (17 points) in D2, but MB.OS’s initial VOCM (20) is 3 points higher than BYD’s (17), sitting on the upper edge of the trend band. This needs careful reading: D2’s AR snapshot scores the group as a whole, while MB.OS first landed on a single model, the CLA. [inference] The more likely explanation is that Mercedes is building the control plane first on a flagship model and letting the E/E catch up on later models — exactly what it looks like when the lower half of the co-evolution loop starts turning. If this is right, its next-generation models will show a markedly higher AR; if not, MB.OS’s contract coverage has been overestimated (which safety-critical actuators actually sit under MB.OS has not been publicly disclosed).

Finding 4: Volkswagen Group answered the vehicle OS question with “one carmaker, two architectures, two outside partners.” This is the most unusual point in the sample and deserves separate discussion.

• CEA in China: co-developed by Volkswagen Group China Technology Company, CARIAD China and XPeng, taking only 18 months from concept to production — the fastest timeline Volkswagen Group has ever achieved for an all-new electronic architecture, according to the company; development costs for new models fall by up to 50% in selected key projects [T1, company claim].
• RV Tech in the West: a joint venture with Rivian, with more than 1,500 employees across the US, Canada, Sweden, Serbia and Berlin [T1].

The two routes have one thing in common: neither of Volkswagen Group’s new-generation vehicle control planes was delivered independently by the group’s own software subsidiary; both were co-built with a new entrant already ahead on the control plane.

[inference] The significance goes beyond Volkswagen. It shows that a vehicle control plane can now be “imported” across companies — not by buying a kernel or a middleware, but by bringing in a complete E/E topology, software stack and development method. CEA’s 18 months is the speed at which the loop’s lower half can be “borrowed” and set turning. The cost is just as clear: one group must maintain two architectures, two partners and two bodies of software facing different interface regimes (Chinese national standards and the Western standards ecosystem). Normalized to each scale’s maximum, CEA’s initial VOCM (20/30) is clearly higher than the group-wide AR snapshot (13/25), making it the only point in Figure 5.1 far above the trend band. Part of this is a matter of scope — as with Mercedes, AR scores the group as a whole while VOCM scores the newest architecture; [inference] but the main reason is that the control plane was imported wholesale together with a same-lineage architecture, arriving ahead of the group’s E/E as a whole. CEA is only one new architecture for China, and the gap between it and the group’s installed platforms in Europe is the more important thing to track. Once RV Tech reaches production, Volkswagen Group will be the only legacy carmaker in the sample with a separate zonal + central-compute control plane in each of two markets. Whether that is a transitional form or will become the norm for multinational carmakers is the question of Section 7.6.

---

6. The Stress Test: the cockpit tests whether an OS can run apps; autonomy tests whether it can run the car

6.1 Autonomous driving is not an OS

This sounds redundant, yet the industry often conflates the two — calling a company’s driving software stack its “OS.”

T4 | Autonomous driving is not the vehicle OS. It is the most demanding workload running on the control plane — and the best stress test of whether a “vehicle OS” deserves the name.

In one sentence:

The cockpit tests whether an OS can run applications; autonomous driving tests whether a vehicle OS can run the vehicle.

6.2 The ladder of failure consequences

Why is autonomous driving the stress test? Because it raises the cost of failure step by step, until no human is left to catch it.

Figure 6.1 — Autonomy as the stress test of a vehicle OS. Reading note: left to right, the cost of failure rises from “inconvenience” to “vehicle-level fallback,” and the demand on the control plane rises from “can reboot” to “can prove it still operates safely under partial failure.” The step between L3 and L4 is the highest — that is where the human leaves the fallback chain.

This is the watershed DD-08, The Driver Exits, discussed: once the driver exits, redundant hardware, the safety case, runtime monitoring and OTA validation are no longer add-ons but the system’s capability itself. This article adds one perspective to DD-08: all of these requirements ultimately land on the control plane. Redundant compute units need an orchestration layer that can switch between them; OTA needs a lifecycle system that can prove “this update will not break the safety case”; runtime monitoring needs a deterministic base that can isolate, observe and, when necessary, take over from the AI workload.

[inference] So a “vehicle OS” that has never carried L3-or-higher responsibility has not yet had its vehicle-wide character tested. It may excel in cockpit, body and energy, but only when the safety-critical execution chain is brought into the same control plane and put through the fail-operational test does the word “vehicle” truly apply.

6.3 The OS’s new job: from “managing resources” to “proving isolation”

The core job of a traditional operating system is managing resources: allocating CPU, memory and I/O. On a mixed-criticality automotive compute platform this job changes in kind — the OS must prove that workloads of different criticality do not interfere with one another.

In 2026 this is already production reality:

• Qualcomm calls Snapdragon Ride Flex “the industry’s first commercialized mixed-criticality platform,” running QM, ASIL B and ASIL D workloads on a single SoC, in production in eight global programs [T2, company claim].
• NVIDIA Halos OS uses a hypervisor to isolate safety-critical functions from AI workloads and provides safety-certified CUDA and TensorRT [T2].

In engineering terms, “proving isolation” means spatial, temporal and memory-bandwidth partitioning in the hypervisor, plus formal or certification-grade arguments for those partitions. NIO’s use of the formally verified seL4 microkernel for its vehicle-control kernel [T3] is an attempt to push “proof” all the way to mathematics.

6.4 What end-to-end models demand of the OS

The spread of end-to-end driving models and VLA (vision–language–action) models puts three new kinds of pressure on the control plane:

1. Memory-bandwidth contention: large-model inference consumes heavy DDR bandwidth and can squeeze real-time tasks on the same chip.
2. Latency jitter: the uncertainty of GPU inference time conflicts by nature with the determinism of control loops.
3. Accelerator preemption: when the driving model and the cockpit large model share accelerators, who has priority?

NVIDIA’s Halos SDK explicitly sells “deterministic scheduling, zero-copy inter-process communication” [T2] — a sign these problems have moved from research topics to product requirements.

6.5 Cockpit–driving integration: isolation turns from option into precondition

When the cockpit and driving functions are placed on the same chip or the same central computer, they enter the same hardware fault domain. In a distributed architecture, a cockpit crash cannot affect braking because the two are physically separate; in an integrated architecture that “natural isolation” disappears and must be rebuilt in software by the control plane.

[inference] Cockpit–driving integration turns isolation from an “optional optimization” into a “safety precondition.” That is why mixed-criticality consolidation (V3) is a dimension of its own in VOCM.

6.6 Robotaxis: the dual-channel structure

In L4 driverless fleets, [inference: public disclosure by Waymo, Baidu Apollo, Pony.ai, WeRide and others of how their software stacks are implemented is limited] a common structure is “AI main stack + an independent safety monitor and redundant compute” — the main stack drives, while a second channel continuously supervises it and, on anomaly, brings the vehicle to a minimal-risk condition. This dual-channel structure is the fail-operational contract expressed in software, and the most extreme form of the control plane’s orchestration duty.

---

7. Horizontal Platforms at the Door: Google, the chipmakers and the fight over interfaces

7.1 A new battlefield

In the smartphone era, Apple and Google ate the operating system and handset makers retreated to hardware and brand. For the past decade the auto industry’s consensus has been: carmakers will never let that happen in the car.

In 2026, that consensus faces its first substantive challenge.

T6 | What the industry is actually standardizing is not “one automotive OS” but the vehicle API, the data model and the runtime contract. Kernels are commoditizing, and control point C3 (OS) is being squeezed from both sides by C2 (silicon) and C4 (middleware).

7.2 Google: Android walks out of the cockpit

On March 24, 2026, Google published the SDV extension of Android Automotive OS (AAOS SDV) on the Android Developers Blog under a blunt title: Beyond Infotainment [T2]. The verified facts:

• Form: a “lightweight, fast-booting headless Android foundation (SDV Core, similar to Microdroid),” running as a virtual machine on a VirtIO-capable hypervisor; service interfaces are defined in Google’s VSIDL plus protobuf and connect to external ECUs over SOME/IP, VirtIO sockets, Ethernet and more; an SDV Gateway sits on the cockpit side [T1: source.android.com, documentation last updated 2026-09-24, for Android 17 and above].
• Domains covered: Google lists “Core Compute, Body Controls, and Cluster domains,” with example functions including seat actuators, instrument cluster, climate control, lighting, cameras, mirrors and telemetry [T2]. The official materials do not mention chassis or ADAS.
• Safety boundary: neither the documentation nor the blog makes any ASIL claim. The only safety-related content is Display Safety (cluster displays such as speed and tell-tales), plus a safety design toolchain and a reference Safety Monitor [T1–T2].
• Adopters: Qualcomm announced at CES 2026 a pre-integrated AAOS SDV stack on Snapdragon Digital Chassis; the first production program is a Renault light commercial vehicle, due for production at the end of 2026 [T2]. Google says AAOS SDV will enter AOSP within 2026.

[inference] These facts draw a clear boundary line: the horizontal platform has crossed the cockpit into the body-comfort and cluster domains, but it remains within QM to low-ASIL territory and has not yet touched the safety-critical execution chains of chassis, braking, steering and automated driving. Whether this line keeps moving down is one of the most important industry signals to watch over the next five years (Chapter 10, revision trigger 4).

7.3 The chipmakers: C2 absorbs C3

If Google presses from the top down, the chipmakers wrap from the bottom up.

• NVIDIA: DriveOS (ASIL D-certified) + Halos OS (hypervisor isolating AI workloads from safety functions) + Halos SDK (deterministic scheduling, zero-copy IPC) [T2]. GM’s 2028 central computing platform is based on NVIDIA Thor [T1].
• Qualcomm: the Ride Flex mixed-criticality platform + a pre-integrated AAOS SDV stack [T2].

[inference] What chipmakers deliver is no longer a chip but a package of “chip + hypervisor + safety-certified runtime + part of the middleware.” For a carmaker, choosing a chip increasingly means choosing S1 and S2 — even part of S3 — at the same time. Among D1’s seven control points, this is C2 (SoC) absorbing C3 (OS).

7.4 Middleware and “Vehicle OS vendors”: C4 expands

Another force comes from middleware and third-party Vehicle OS vendors.

• Applied Intuition supplies a Vehicle OS to carmakers. In May 2026 Stellantis announced an expanded collaboration with it on STLA Brain [T1]; the company says 18 of the world’s top 20 automakers use its solutions [T2, company claim].
• Eclipse S-CORE: in June 2025, 11 companies signed the VDA memorandum of understanding on open-source SDV collaboration (BMW, Continental, ETAS, HELLA, Mercedes-Benz, Qorix, Bosch, Valeo, Vector, Porsche, ZF) [T1]; according to a VDA press release of January 7, 2026, signatories expanded to 32 [T1–T2]. S-CORE 0.5 was released in November 2025, with the reference platform first demonstrated on QNX and Qualcomm hardware [T2].

[inference] When a European carmaker uses open-source S-CORE for S2, QNX for S1, the chipmaker’s hypervisor for isolation, and buys a third-party Vehicle OS for part of S4, what does it actually still own? The answer: vehicle semantics, safety responsibility, and the capability to integrate, validate and run the data loop.

7.5 The fight is over interfaces, not kernels

Put the three forces together and an underrated fact emerges: what all sides are really fighting over — and really standardizing — is the interface layer.

[inference] Together these efforts point to one conclusion: what is heading for standardization is not “one automotive OS” but “vehicle API + data model + runtime contract.” That corresponds precisely to the first of the control plane’s three parts in Section 2.3 — the contract.

This yields a corollary about where value sits:

The contract layer is converging; orchestration and lifecycle are the remaining space for carmaker differentiation.

7.6 Horizontal platform vs. OEM control plane: what is the endgame?

So will the industry converge on a horizontal vehicle OS, or will carmakers keep the vehicle control plane?

[inference] Our judgment: it is not either/or. Infrastructure at the bottom (S1, S2 and contract-layer standards) will keep converging; vehicle semantics, ownership of safety responsibility and brand differentiation (orchestration, lifecycle, the data loop) will keep diverging. This is the second reappearance of D1’s two-layer convergence–divergence model at the software layer.

Four kinds of carmaker will reach four different endgames:

1. Vertical integrators (Tesla, Huawei, NIO): own C2, C3 and C4 together; the control plane is entirely their own. They are the strongest counterexample to T6 — for them the OS is not something being commoditized but part of the moat.
2. Federated control planes: several control planes built by region or even by partner, sharing brand, supply chain and part of the base, but not pursuing a single global software stack. Volkswagen Group is the clearest example today: CEA co-built with XPeng in China, RV Tech co-built with Rivian in the West (see Finding 4 in 5.5). The advantages are speed and local fit — 18 months to production, direct alignment with Chinese national standards and the local driving ecosystem. The risk is that economies of scale get split: two architectures mean two validation regimes, two OTA operations, two talent pipelines and long-term integration costs. [inference] The endgame of the vehicle OS need not be “one kernel to rule them all”; a federated control plane may be the rational choice for multinationals facing diverging standards in China and the West — but whether the federation can converge into one in the next generation decides whether this route ends up a “transition” or a “liability.”
3. Platform consumers: buy third-party solutions even at S4 (Applied Intuition, Google, chipmaker packages) and concentrate differentiation on brand, design and channel.
4. Control-plane exporters: export their own vehicle control plane — together with the E/E topology and development method — as a product to other carmakers. This is the newest form, emerging in 2025–2026, and its protagonists are almost all Chinese carmakers:
   • XPeng co-built CEA with Volkswagen (5.5);
   • at its 2026 Tech Day, Leapmotor said its electronic systems now work with five partners and that it provides vehicle-level technology enablement to FAW, Stellantis and others [T3];
   • Huawei’s HarmonyOS cockpit and Qiankun cover 25 brands [T2].

[inference] The fourth form changes the picture T6 paints. Control point C3 is not only squeezed from above and below by chipmakers (C2) and middleware / horizontal platforms (C4); it is also being contested sideways by another kind of carmaker. For the importer, bringing in a control plane is much faster than building one: CEA went from concept to production in 18 months. For the exporter, the control plane becomes a second revenue curve and an amplifier of scale — Leapmotor’s claimed 90% platform commonality is exactly what makes a control plane replicable for export [T3, company claim]. Stellantis working with both Applied Intuition (third-party Vehicle OS) and Leapmotor (vehicle-level technology) shows that one carmaker can be a “platform consumer” and a “control-plane importer” at once, in different markets and models.

None of the four forms is superior; each is a different bet on where the control point should sit.

---

8. When AI Enters the Operating System: the hourglass and deterministic governance

8.1 Putting a large model in the car is not AI entering the OS

The most common — and shallowest — discussion of “AI and the vehicle OS” is about which large model sits in the car: Gemini, GPT, DeepSeek, Pangu or Grok. That is AI as an application. The real change happens deeper, and comes in three stages.

Stage B carries an easily overlooked but far-reaching corollary: the model becomes a first-class software artifact. Today an OTA update delivers “software package v3.7”; tomorrow it will deliver a bundle of “software + model + policy + agent graph + safety envelope.” The object of lifecycle management expands from code to probabilistic products.

The industry is already moving toward Stage B:

• Mercedes’ MBUX Virtual Assistant integrates AI from both Microsoft and Google and builds an automotive AI agent on Gemini [T2].
• Hyundai’s Gleo AI agent arrives with Pleos Connect; Hyundai frames the shift as moving from SDV to “AIDV” (AI-defined vehicle) [T2].
• NIO calls SkyOS a “full-domain vehicle operating system for AI” [T2].
• At its 2026 Tech Day, Leapmotor launched a “vehicle–cloud AgentOS”: core agents on the vehicle handle low-latency and privacy-sensitive tasks; cloud agents handle complex reasoning and long-term memory [T3]. [inference] This is a design that “splits intelligence by trust and latency” — and it maps neatly onto the control plane’s outer ring (cloud, OTA, data loop): the agent itself is divided into a “deterministic part in the car” and an “extended part in the cloud.”
• In October 2025, China’s automotive basic-software ecosystem committee (AUTOSEMO) published its China Automotive Basic Software Development Report 6.0, focusing on AIOS and proposing an architecture of “compute abstraction — data fusion — function servitization” [T2].

8.2 Will the OS get thinner or thicker?

Will AI absorb the operating system? Both views have merit.

The thinning side: interaction, application orchestration and functional logic are being absorbed by large models and agents. HMI flows, menu hierarchies and rule engines that once had to be hard-coded are being replaced by a model that understands intent. End-to-end driving models have also absorbed middleware that used to be split into separate perception, prediction and planning modules. Seen this way, the top half of the OS is getting thinner.

The thickening side: the more uncertain the model, the more it needs a deterministic skeleton. Resource isolation, temporal determinism, safety monitoring, provable fallback paths, and the AI-lifecycle evidence chain required by ISO/PAS 8800 must all sink into the OS layer. NVIDIA makes “a hypervisor that isolates safety-critical functions from AI workloads” the core selling point of Halos OS [T2]. Seen this way, the bottom half of the OS is getting thicker.

Our answer: both are happening at once.

T5 | AI will not eliminate the vehicle OS; it will polarize it: the top half (interaction, orchestration) thins, the bottom half (determinism, isolation, proof) thickens, and the service contract in between becomes the narrow waist. Probabilistic intelligence must run inside deterministic governance.

Figure 8.1 — The hourglass: how AI reshapes the vehicle OS. The wide top: interaction, orchestration and functional logic absorbed by models. The narrow waist: the control plane’s service contract. The wide base: the thickening deterministic layer (isolation, scheduling, safety monitoring, fallback, evidence chain). The right side shows how the software artifact evolves: “code” → “code + model + policy + agent graph + safety envelope.”

This is fully consistent with D3’s judgment that “AI is a faculty of language, not a brain”: the language faculty moves up into the model; the safety “brainstem” — the deterministic skeleton — stays in the OS. The two do not contradict each other; they are two sides of the same thing.

8.3 A falsifiable prediction

“Polarization” is easy to criticize as a hedge that “both sides are right.” To avoid that, we offer a clear prediction that facts could overturn:

[inference] Before 2030, there will be no production passenger car in which a large language model or general-purpose agent directly gains control of ASIL D actuators. Agents may suggest, request and call authorized vehicle services, but final control over safety-critical actuators such as braking and steering will still be adjudicated by the deterministic control plane.

If this prediction is overturned, T5 must be revised (Chapter 10, revision trigger 3).

8.4 Standards and regulation: the constraints on AI in the OS have taken shape

Whether AI enters the vehicle OS is not decided by technology alone. The rule system that constrains it has already taken shape:

• ISO 26262 (functional safety) and ISO 21448 (SOTIF, safety of the intended functionality) [T1].
• ISO/PAS 8800:2024 (Road vehicles — Safety and artificial intelligence), published in December 2024, tailoring relevant clauses of ISO 26262 Parts 4, 6 and 8 [T1]. In August 2025, SGS-TÜV Saar awarded Geely the world’s first ISO/PAS 8800 process certification [T2].
• UN R155 / R156 (cybersecurity management system / software update management system), and China’s corresponding mandatory standards GB 44495 / 44496 / 44497, in force since January 1, 2026 [T1].

[inference] The combined effect of these standards: the more AI, the heavier lifecycle management becomes. Every model update may require an updated safety case; every agent granted vehicle-action rights needs an auditable permission model. These burdens cannot be carried by the model itself; only the control plane can carry them.

One question remains unanswered: how does AI-generated OS code enter an ISO 26262 safety argument? D4 already showed that in architecture toolchains, “AI generation” capability has decoupled from “reasoning autonomy.” At the vehicle OS level, as of this article’s data cut-off, we have found no public production case of AI-generated code entering an ASIL argument. It is a gap worth watching.

---

9. Roadmap 2026–2035: from software-defined to AI-defined

9.1 Five stages

The table distinguishes observed states from research hypotheses. The first three stages are observed; the last two are hypotheses.

Note: Stage V shares its name with L8 “AI-Defined Vehicle” in this series’ eight-level EEA evolution taxonomy, but the two describe different objects: the eight-level taxonomy describes the form of the vehicle’s EEA; this table describes the form of the software control plane. The two dimensions are orthogonal and must not be mixed.

9.2 What actually separates Stages III, IV and V

The last three stages are the easiest to confuse. In one sentence: Stage III turns functions into software, Stage IV turns software into schedulable resources, and Stage V lets models take part in deciding what gets scheduled.

The evolution of the data center offers a ready analogy:

• Stage III is like the virtual-machine era: servers are virtualized, but what each VM runs and where it sits are configured in advance by operations.
• Stage IV is like the Kubernetes era: workloads are packaged into standard units and placed into a resource pool by a scheduler according to rules; they can migrate, scale and be replaced.
• Stage V is like the AI-native era: above the scheduler sits a layer of models that understand intent, so the system can compose, on the fly, flows that nobody wrote in advance.

Each of Stage IV’s six characteristics has a concrete shape:

1. Dynamic function placement. When the main compute unit fails, the orchestrator migrates non-safety-critical functions to a backup unit; or the same function is deployed to different nodes depending on vehicle configuration.
   • One limit must be stressed: ASIL D functions will not be “dynamically” scheduled in the foreseeable future. Their migration paths are redundancy switchovers designed and certified in advance. What is truly dynamic is mainly QM and low-ASIL workloads.
2. Shared compute. When the car is parked, most of the driving chip’s compute sits idle. A Stage IV platform can lend it to the cockpit’s large model, to visual analysis in sentry mode or to on-board data preprocessing, and take it back by priority once the car moves. Stage III cannot do this, because cockpit and driving belong to two domains with two software stacks.
3. Cross-domain services. In Stage III, a “camping mode” is a purpose-built feature requiring changes to HVAC, display, battery-management and door-lock code. In Stage IV it is simply a composition of existing services. Chinese carmakers’ “scene orchestration” features are already heading this way, though most still stay at the cockpit level and have not reached deep into vehicle control [inference].
4. Cloud–vehicle development parity. The same software container finishes regression on a virtual car in the cloud before being deployed to a real one. Google’s AAOS SDV documentation states explicitly that running in a virtual machine “facilitates testing and integration in the cloud” [T1].
5. Mixed-criticality consolidation as the norm. Today Ride Flex lets ASIL D and QM workloads share a chip in eight production programs [T2] — still a “first wave”; in Stage IV it becomes the default configuration of new platforms rather than a selling point.
6. Standardized model lifecycle. Versioning, validation and rollback of driving models move from each company’s own tooling onto the same pipeline as software, constrained by ISO/PAS 8800 and R156. Leapmotor’s “one model deployed across three compute tiers” [T3] is an early example of making deployment decisions by hardware tier.

The boundary between Stages IV and V lies in who writes the rules. However clever the Stage IV orchestrator, it executes rules engineers wrote. In Stage V, models and agents begin to take part in the decision. Compare:

• Stage IV: the user says “turn on camping mode,” and the system executes a pre-built service composition.
• Stage V: the user says “I’m spending the night in the mountains and need to drive back to the city tomorrow morning.” The agent checks remaining charge against the return distance, works out how much energy the HVAC can use, sets a battery reserve floor, dims the screens and finds charging stations along tomorrow’s route. No engineer ever wrote this composition; it is generated on the fly within the permission model and the safety envelope.

Leapmotor’s AgentOS, Hyundai’s Gleo AI and Mercedes’ Gemini-based agent are all still at the “AI becomes an OS service” stage described in Chapter 8: they understand intent, but the range of vehicle services they can call, and their permissions, remain limited.

How will we know the industry has entered Stage IV? Watch four observable signals:

1. production cars with functions that migrate between compute units without a new software release;
2. the same software container, validated in the cloud, deployed across multiple hardware tiers;
3. new platforms that share an SoC between ASIL D and QM workloads by default;
4. model updates entering a unified, regulated pipeline with rollback.

The signals of Stage V are production cars with agents that call vehicle services through a permission model, and function compositions that were not pre-coded but generated from user intent.

[inference] The boundaries between the three stages are blurry; the same carmaker often straddles two stages. The table describes a shift in center of gravity, not a clean cut.

9.3 The migration of control points

[inference] Between now and 2030, the three of D1’s seven control points relevant here will change as follows:

• C2 (SoC): keeps absorbing upward, delivering the full stack of “chip + hypervisor + certified runtime + part of the middleware.”
• C3 (OS): kernels and base runtimes commoditize; independent value shifts to the control plane’s orchestration and lifecycle.
• C4 (middleware): open source (S-CORE, HaloOS) and standards (VSS, Chinese national standards) accelerate convergence; the contract layer gradually becomes a commons.

Figure 9.1 — Squeezing C3: where vehicle OS value migrates. Reading note: C3 is squeezed by forces from above and below; what remains the carmaker’s own is orchestration, lifecycle and the data loop (C5).

9.4 China’s route: in-house, open source and national standards in parallel

China’s vehicle OS evolution has a distinctive structure: in-house development, open source and national standards advance in parallel and reinforce one another.

• In-house: NIO SkyOS, Huawei’s HarmonyOS cockpit and Qiankun, XPeng, Xiaomi and others are building their own software stacks [T2].
• Open source: Li Auto open-sourced HaloOS under Apache 2.0 (2025), turning in-house work into an industry commons [T2].
• National standards: GB/T 47351 / 47341-2026 took effect on July 1, 2026; the three mandatory standards GB 44495 / 44496 / 44497 took effect on January 1, 2026, harmonized with UN R155 / R156 [T1].

[inference] One important consequence of the national standards: they become an interface that every carmaker selling in China — foreign carmakers included — must align with. Mercedes-Benz China and Volkswagen China appearing among the drafting organizations shows foreign carmakers have recognized this. It may also be one structural reason why “federated control planes” are appearing worldwide: the same carmaker may need to maintain software stacks facing different interface regimes in China and elsewhere.

9.5 Economics and organization: the real bottleneck

Economically, a vehicle OS pays back in four ways: lower bill-of-materials cost for ECUs and wiring, software reuse across models, amortization of platform cost, and software revenue after the car is sold. Rivian’s software and services gross profit jumping from USD 7 million to USD 576 million in FY2025 [T1] shows that the value of “E/E + OS” as an asset can already appear in financial statements.

Organizationally, its cost is often underestimated. Section 5.1 noted that almost every carmaker in the roadmap tier (M4) has slipped. [inference] The cause is rarely technology and usually organization:

• turning dozens of function-based departments into one platform organization;
• changing Tier 1 contracts from “black-box ECU” units to “software module + integration responsibility” units;
• building the next-generation platform while keeping current models shipping.

This is Conway’s law applied to the vehicle OS: your control plane will look like your organization. A carmaker still divided into “body, chassis, powertrain and cockpit” departments will struggle to build a control plane that spans all four domains.

To sum up this chapter in one sentence:

Centralization removes local complexity by creating system complexity. It eliminates the fragmentation among 100 ECUs, but brings a larger blast radius, a more concentrated attack surface, more complex validation — and an organization that must reorganize itself before it can reorganize the car.

---

10. Putting the Knife to Our Own Throat: counter-arguments and revision triggers

10.1 Seven counter-arguments

Counter-argument 1: the vehicle OS is just a marketing concept. Strip away the brand layer and what is left is QNX + Linux + AUTOSAR + a hypervisor. Response: this is exactly where T1 starts. We do not claim the vehicle OS is a new kernel; we claim it is the control plane governing several kernels. The brand is indeed overstated, but its three parts — contract, orchestration and lifecycle — are real, observable and scorable.

Counter-argument 2: central compute may not pay off. The overhead of virtualization, redundancy and liquid cooling may cancel out the savings from fewer ECUs. Response: we draw no conclusion here. Economics depend on vehicle volume and software revenue, and public data are insufficient to judge. We only note that “centralization trades local complexity for system complexity” — whether the trade pays depends on the carmaker.

Counter-argument 3: a vehicle OS actually increases systemic risk. Response: agreed. This is precisely Chapter 6’s argument: centralization turns isolation from a natural property into one that must be proven. Whether the risk is controlled depends on how well V3 (mixed criticality) is done.

Counter-argument 4: standardized APIs will wipe out carmaker differentiation. Response: differentiation at the contract layer will indeed shrink (T6), but orchestration, lifecycle and the data loop remain spaces for differentiation. Differentiation will not vanish; it will migrate.

Counter-argument 5: AI agents should never enter the safety-critical control path. Response: our position is more specific: agents may enter the control plane, but only under deterministic governance; final control over ASIL D actuators will not be handed to agents in the foreseeable future (the prediction in 8.3).

Counter-argument 6: regionalized software stacks will prevent a global vehicle OS. Response: agreed — and this may be not a problem but the endgame. The “federated control plane” discussed in 7.6 develops exactly this judgment.

Counter-argument 7: L4 will ultimately need its own OS, not a part of the vehicle OS. Response: this is an open question. The dual-channel structure (6.6) may mean that the L4 safety-monitoring channel is logically independent of the vehicle control plane. If L4 fleets widely adopt software stacks entirely separate from the passenger-car vehicle OS, T4 should be restated as “autonomous driving tests the contract between the vehicle OS and the safety channel.”

10.2 Five revision triggers

If any of the following occurs, the corresponding thesis must be revised:

---

11. Conclusion: three judgments and one warning

Back to the title. “A system of operating systems” is not a figure of speech — it is the most accurate description of that layer in every software-defined car. It has been called by so many “OS” names that no one stopped to ask what it actually is.

Our answer: it is a control plane made of contract, orchestration and lifecycle, governing a set of operating systems — not any one operating system itself.

Judgment 1: the vehicle OS is a system of operating systems, and its boundary is drawn by the E/E architecture. What is called an OS may not be a vehicle OS, and what is not called one may be. The test is not the brand name but which domains the contract covers, whether orchestration can prove isolation, and which layers the lifecycle can update. How far those three can go depends first on which generation the E/E architecture has reached.

Judgment 2: the real watershed is the reversal of causality. The mark of a carmaker entering the software-defined era is not whether it has an OS brand but whether the lower half of the co-evolution loop has started turning — whether its next E/E specification is defined by the needs of the current generation’s software. GM’s “10× / 1,000× / 35×,” the BMW–GM split over how far to dumb down zonal controllers, and Rivian selling “E/E + OS” as a whole are all signs that the loop has started turning.

Judgment 3: AI makes the operating system more important, not less. AI will absorb the top half of the OS but make its bottom half thicker. The more probability, the more precious determinism becomes. Autonomous driving is the stress test of this: the cockpit only tests whether an OS can run applications, while a car without a driver tests whether a vehicle OS can run the vehicle.

One warning: do not treat “owning an OS” as the finish line. Kernels are commoditizing, contracts are standardizing, and chipmakers and horizontal platforms are squeezing from both ends. For most carmakers the real question is not “should we build our own OS?” but “in which part of the control plane must we have the final say?” Orchestration, lifecycle, the data loop, and ultimate ownership of safety responsibility — these are what still belong to the carmaker after the wave of standardization.

The vehicle OS contest will not end with one system winning. It will end with a plainer question: when every layer of a car can be bought, which layer is the one you cannot buy? This article has laid the coordinate system on the table; where to place the bet was always the reader’s own decision.

---

Appendix A | Evidence grades and main sources

A.1 Evidence grades

Note: all future dates (GM 2028, STLA One 2027, Hyundai 2030, etc.) are company plans or targets, not facts, and there are precedents of delay.

A.2 Main sources (by topic, selected)

• QNX installed base: BlackBerry FY2026 10-K — https://www.sec.gov/Archives/edgar/data/1070235/000107023526000039/bbry-20260228.htm
• MB.OS start of production: Mercedes-Benz Group, CLA production start in Rastatt — https://group.mercedes-benz.com/company/production/production-network/start-of-production-cla-rastatt.html
• NIO SkyOS: NIO official (full-stack technology: full-domain vehicle OS) — https://www.nio.cn/smart-technology/20251215002 ; IT Home — https://www.ithome.com/0/720/560.htm
• Li Auto HaloOS open source: TechNode — https://cn.technode.com/post/2025-03-29/lixiang-xinghuan-os/
• Chinese national standards: National Public Service Platform for Standards Information — https://std.samr.gov.cn/gb/search/gbDetailed?id=0BBF0FBBBE1AE46FE06397BE0A0AD1FD ; https://std.samr.gov.cn/gb/search/gbDetailed?id=D33BADAFBDDF2CD0E05397BE0A0A113C
• GB/T 47341-2026 commercial translation (T3) — https://www.chinaautoregs.com/archives/7587
• GM central computing platform: GM press release, 2025-10-22 — https://news.gm.com/home.detail.html/Pages/news/us/en/2025/oct/1022-SDV-GM-centralized-vehicle-computer-platform-electric-gas-vehicles.html
• BMW Neue Klasse superbrains: https://www.bmwgroup.com/en/news/general/2025/superbrains.html
• Toyota Arene / RAV4: https://pressroom.toyota.com/three-two-one-toyota-debuts-amazing-all-new-rav4/ ; https://insideevs.com/news/775729/2026-toyota-rav4-phev-arene-software-ev/
• Toyota Arene (2023 wording): Toyota press release, 2023-04-11 — https://global.toyota/en/newsroom/corporate/39070846.html
• Hyundai Pleos: https://www.hyundainews.com/releases/4774 ; S&P Global Mobility — https://www.mobilityglobal.com/en-us/automotive-insights/blog/hyundai-pleos-software-launch-shifts-mobility-game
• Rivian / RV Tech: Rivian FY2025 8-K — https://www.sec.gov/Archives/edgar/data/1874178/000187417826000007/ex-991pressrelease4q25earn.htm ; DEF 14A — https://www.sec.gov/Archives/edgar/data/0001874178/000187417826000023/rivn-20260427.htm
• RV Tech progress: Volkswagen Group press release, 2025-11-12 — https://www.volkswagen-group.com/en/press-releases/one-year-after-its-founding-joint-venture-between-volkswagen-group-and-rivian-shows-strong-progress-19980 ; winter testing — https://www.electrive.com/2026/03/27/vw-and-rivian-conclude-winter-testing-programme/
• Volkswagen Group CEA: Volkswagen Group press release, 2026-01-28 — https://www.volkswagen-group.com/en/press-releases/volkswagen-group-china-starts-production-of-its-first-locally-developed-zonal-electronic-architecture-20144 ; CarNewsChina — https://carnewschina.com/2026/01/29/volkswagen-starts-production-of-xpeng-co-developed-cea-architecture-five-new-models-due-in-2026/ ; CarNewsChina, 2025-12-10 — https://carnewschina.com/2025/12/10/volkswagen-and-xpengs-first-joint-vehicle-id-unyx-07-nears-production-after-just-18-month-chinese-led-development/ ; IT Home — https://www.ithome.com/0/903/897.htm
• CARIAD restructuring (T3): https://allthingstalent.org/volkswagen-to-cut-1600-jobs-at-cariad-software-division-in-major-restructuring-move/2025/03/13/
• Leapmotor LEAP 5.0: Stellantis Media (Leapmotor Tech Day 2026, 2026-09-30) — https://www.media.stellantis.com/uk-en/leapmotor/press/leapmotor-unveils-next-generation-vehicle-architecture-battery-technology-at-tech-day-2026 ; Gasgoo — https://autonews.gasgoo.com/articles/ev/leapmotor-counters-tech-peak-theory-with-one-architecture-and-three-systems-2101156419729817601 ; Sina Auto, 2026-09-16 — https://auto.sina.cn/news/2026-09-16/detail-inirzwqt4627345.d.html
• Qualcomm Ride Flex: TechInsights — https://www.techinsights.com/blog/qualcomm-integrates-cockpit-adas
• NVIDIA Halos: https://www.nvidia.com/en-us/ai-trust-center/halos/autonomous-vehicles/
• Google AAOS SDV: Android Developers Blog, 2026-03-24 — https://android-developers.googleblog.com/2026/03/Beyond-Infotainment-Extending-Android-Automotive-OS-for-Software-defined-Vehicles.html ; AAOS SDV system architecture — https://source.android.com/docs/automotive/sdv/sdv-system-architecture
• Stellantis × Applied Intuition: https://www.stellantis.com/en/news/press-releases/2026/may/stellantis-and-applied-intuition-expand-collaboration-with-stla-brain-to-advance-vehicle-software-and-enhance-customer-experience
• VDA / Eclipse S-CORE: https://blogs.eclipse.org/post/sara-gallian/eclipse-sdv-2025-all-roads-lead-open-source ; https://www.adt.media/software-defined-vehicles/vda-and-eclipse-foundation-expand-sdv-software-ecosystem/2587652
• SOAFEE: https://www.globenewswire.com/news-release/2026/04/22/3279060/0/en/here-joins-soafee-to-bring-expertise-in-ai-powered-mapmaking-into-open-software-defined-vehicle-platforms.html ; Open AD Kit — https://autoware.org/open-ad-kit-the-first-soafee-blueprint-powering-open-collaboration-in-autonomous-driving/
• Eclipse Open Vehicle API: https://projects.eclipse.org/projects/automotive.openvehicle-api/reviews/eclipse-open-vehicle-api-2026.08-progress-review
• AUTOSAR Adaptive and POSIX: UL Solutions — https://www.ul.com/sis/blog/autosar-part-2-adaptive-platform
• UN R156 (paragraph 7.1.1 text): EUR-Lex — https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:42021X0388
• ISO/PAS 8800: UL — https://www.ul.com/sis/blog/safety-related-systems-road-vehicles-artificial-intelligence-are-addressed-isopas-88002024 ; Geely certification (SGS) — https://www.sgs.com/en-hk/news/2025/08/geely-auto-awarded-first-global-ai-safety-certification-for-road-vehicles
• Huawei HarmonyOS cockpit / Qiankun installed base: https://news.qq.com/rain/a/20260908A0664N00
• AUTOSEMO Report 6.0: Reach Auto (Neusoft) press release, October 2025, publishing the report on behalf of AUTOSEMO — https://www.reachauto.com/en/2025/10/

---

Appendix B | VOCM scoring rubric

Each dimension is scored 0–5. Scores rest on public sources only; a dimension with insufficient evidence may score no higher than 2, or be marked n.a.

Confidence: H = Tier 1–2 evidence directly supports most dimensions; M = some dimensions rely on company claims; L = most dimensions rely on secondary sources or inference.

Same-lineage exception: a platform co-developed with an already-scored carmaker and inheriting the same architecture lineage (such as VW CEA with XPeng) may reference that carmaker’s scores on dimensions where its own public information is thin. Each such dimension must be named in the notes, and confidence is capped at L.

---

Appendix C | Abbreviations