Vehicle OS

Vehicle OS describes an OEM’s complete software platform for its vehicles: the operating systems on the central computers, the middleware and APIs above them, the development toolchain, and usually the connected cloud backend. Mercedes-Benz’s MB.OS, Hyundai Motor Group’s Pleos, Volkswagen’s CARIAD stack and comparable programs at Toyota (Arene), NIO (SkyOS) and others all compete in this category.

A vehicle OS is not a single kernel. Under the brand name sits a mixed stack: QNX or Linux for safety and application domains, often Android Automotive OS for infotainment, AUTOSAR components, hypervisors separating criticality levels, and proprietary glue. The term is best read as a platform strategy — one software base spanning an OEM’s model lines — rather than an operating system in the computer-science sense.

What counts as a vehicle OS

The label is used loosely, so it helps to separate three things that get called an OS in vehicles. At the bottom are the actual operating systems — Linux, QNX, real-time kernels, Android Automotive OS — which OEMs license or adopt rather than write. In the middle are middleware stacks and runtimes, standardized or commercial, covered separately under middleware. A vehicle OS in the sense OEMs use the term is the top-level construct: the integrated combination of those pieces plus the OEM’s own APIs, application framework, update pipeline and cloud services, presented as one branded platform.

The scope is what distinguishes the category. A vehicle OS is expected to cover every domain — infotainment, body, driver assistance, propulsion — and to persist across vehicle generations, so that software written for it outlives any single model. That ambition is why these programs are measured in billions and years.

Inside the stack

A representative vehicle OS layers as follows. Hypervisors partition the central computers so that safety-certified software and consumer-grade software share silicon without sharing failure modes. Safety-relevant domains run on real-time operating systems and AUTOSAR Adaptive or Classic runtimes; the infotainment domain typically runs Android Automotive OS or a Linux-based system. Above the operating systems sits the middleware — service-oriented communication, hardware abstraction, diagnostics, update handling — and above that the OEM’s API surface: the vehicle functions exposed to application developers, both internal and third-party. A cloud backend mirrors the fleet for updates, telemetry, and increasingly for digital twin-style development workflows.

Little of this is written from scratch. The OEM’s real work is selection, integration and the API contract — and keeping all of it stable enough that applications survive hardware changes underneath.

Android Automotive OS and the infotainment distinction

Android Automotive OS (AAOS) is Google’s operating system built to run in the vehicle itself, and it is frequently confused with Android Auto, which merely projects a phone’s interface onto the car’s screen. AAOS runs natively on the infotainment computer with no phone required; OEMs may additionally license Google Automotive Services (Maps, Assistant, Play) or ship AAOS without Google services and supply their own.

The distinction that matters for this entry is between an infotainment OS and a full vehicle OS. AAOS governs the cabin experience — media, navigation, apps — but not braking, propulsion or driver assistance. Many OEMs therefore embed AAOS as one component inside their vehicle OS: Google supplies the infotainment layer while the OEM retains the safety domains, the vehicle APIs and the update pipeline. Whether that boundary holds, or whether technology companies extend further down the stack, is one of the sector’s standing strategic questions.

Build, buy or partner

OEMs justify vehicle OS investment through control points. Whoever owns the platform defines the APIs third parties build on, controls the update pipeline and the customer relationship it enables, and decides which suppliers become interchangeable. Ceding those points to a technology company or a supplier is, in the standard argument, ceding the profitable layer of the future vehicle.

Executing on that argument has been hard. Volkswagen’s CARIAD became the most widely reported example of delay and restructuring, and Volkswagen subsequently moved a substantial part of its future architecture into a joint venture with Rivian — an acknowledgment that buying access to a software-native stack can beat building one. Other OEMs have scaled ambitions to match capacity: keeping the API layer and update pipeline in-house while sourcing lower layers from suppliers or open-source projects such as Eclipse SDV. Mercedes-Benz’s MB.OS, developed with selected partners per domain, reached its first production vehicles in the mid-2020s and represents the own the architecture, source the components middle path.

What to watch

Three threads carry most of the news in this category. First, consolidation: full-stack independence is expensive, and more OEM pairings, joint ventures and shared platforms are likely. Second, the China dynamic, where OEMs such as NIO and Xpeng iterate vehicle platforms on consumer-electronics timelines and increasingly license technology to Western incumbents rather than the reverse. Third, the boundary with Big Tech: each expansion of AAOS or of chip-vendor software offerings tests how much of the software-defined vehicle stack OEMs will actually keep.