Ein System von Betriebssystemen: E/E-Architektur, Fahrzeug-OS und das KI-definierte Fahrzeug

Zusammenfassung

„Fahrzeug-OS“ ist zu einem Begriff geworden, den jeder Hersteller besitzen muss, der als softwaredefiniert gelten will. Doch die Dinge, die „OS“ heißen, sind keineswegs dieselbe Art von Ding. Dieser Beitrag beginnt mit einer ontologischen Bereinigung: Ein Cockpit-OS ist kein Fahrzeug-OS, ein Domänen-OS ist kein Fahrzeug-OS, und eine Laufzeitumgebung ist kein OS. Jedes heute in Serie befindliche Fahrzeug-OS — MB.OS, NIO SkyOS, Li Auto HaloOS, Pleos Vehicle OS — ist ein Verbund aus mehreren Kerneln, der von einer einzigen fahrzeugweiten Steuerungsebene regiert wird. Wir zerlegen diese Steuerungsebene in drei beobachtbare Teile — Vertrag, Orchestrierung und Lebenszyklus — und leiten daraus eine sechsdimensionale Vehicle OS Capability Matrix (VOCM) ab, mit der wir 15 Hersteller einer ersten Bewertung unterziehen, gegenübergestellt den AR-Werten aus D2.

Den Kern des Beitrags bildet eine kausale Struktur. Die E/E-Architektur setzt die Grenze dessen, was ein Fahrzeug-OS sein kann; doch sobald Funktionen zu Software werden, kehrt sich die Kausalität um — Software-Workloads beginnen, die nächste E/E-Architektur zu gestalten (der Architektur–OS-Koevolutionskreislauf). Darauf aufbauend argumentieren wir, dass autonomes Fahren der Belastungstest dafür ist, ob ein Fahrzeug-OS real ist; dass KI die obere Hälfte des OS dünner und die untere dicker macht; und dass die Branche tatsächlich die Fahrzeug-API, das Datenmodell und den Laufzeitvertrag standardisiert — nicht „ein Automobil-OS“. Das Fazit liefert drei Urteile und eine Warnung sowie fünf Revisionsauslöser.

---

Hinweis zur Textgattung

Dieser Beitrag gehört zur Deep-Dive-Kategorie, nicht zur Working-Paper-Kategorie. Die Trennlinie liegt nicht in der Länge, sondern im Grad der Verbindlichkeit:

• Working Papers (D1–D4, Zenodo-DOIs) = festgeschriebene Thesen. Niemals stillschweigend revidiert; gebaut, um fünf Jahre Zitation zu überstehen.
• Deep Dives (diese Kategorie) = disziplinierte Beobachtungen. Revidierbar, widerlegbar, ausdrücklich gekennzeichnet als „das sehen wir gerade“, außerhalb des DOI-Systems.

Dieser Beitrag übernimmt die epistemische Disziplin der Working Papers — Quellenstufung, nachvollziehbare Belege, obligatorische Gegenargumente und Fehlermodi —, nicht aber ihre Endgültigkeit. Er revidiert keine veröffentlichte Schlussfolgerung von D1–D4; die zitierten D2-Werte sind die der veröffentlichten Fassung. Evidenzgrade sind im Text als [T1], [T2], [T3] und [Inferenz] markiert; siehe Anhang A. Die Schlussfolgerungen tragen eigene Revisionsauslöser (Kapitel 10); greift einer davon, wird eine revidierte Fassung mit gekennzeichneten Änderungen veröffentlicht.

---

Einleitung: ein Begriff, den alle benutzen und niemand definiert

Im Juni 2025 lief im Mercedes-Benz-Werk Rastatt der erste CLA mit MB.OS vom Band [T1]. Im selben Zeitraum nannte NIO sein SkyOS ein „Full-Domain-Fahrzeugbetriebssystem“, Li Auto stellte HaloOS unter Apache 2.0 als Open Source bereit, Toyota brachte Arene mit dem neuen RAV4 auf den Markt, und Hyundai teilte Pleos in zwei Marken auf: „Vehicle OS“ und „Connect“. 2026 war „Fahrzeug-OS“ zu einem Begriff geworden, den jeder Hersteller besitzen muss, der als softwaredefiniert gelten will.

Das Problem: Die Dinge, die „OS“ heißen, sind keineswegs dieselbe Art von Ding.

Android Automotive ist ein OS. BMW Operating System X heißt OS. NVIDIA DriveOS heißt OS. AUTOSAR wird mitunter fälschlich OS genannt. MB.OS, SkyOS, HaloOS und Pleos Vehicle OS sind ebenfalls OS. Stellt man sie in eine Tabelle und bildet eine Rangfolge, vergleicht man Äpfel, Orangen und Obstplantagen.

Diese Forschungsreihe hat den Begriff dreimal berührt, ohne innezuhalten und ihn zu definieren. D1 führte das OS als C3 unter sieben architektonischen Kontrollpunkten, schrieb RTOS, AUTOSAR und Middleware in die Softwareschicht der E/E-Architektur und argumentierte in §3.4, dass der Hypervisor die Brücke zwischen offenen Ökosystemen und harter Echtzeit ist. D2 trennte im Mercedes-Profil ausdrücklich MMA (die Hardwareplattform) von MB.OS (dem Software-Betriebssystem) und warnte davor, beides zu vermengen. DD-08, Der Fahrer tritt ab, argumentierte, dass Fail-operational von einer Premiumoption zur Zugangsvoraussetzung wird, sobald der menschliche Fahrer die Rückfallkette verlässt.

Alle drei verweisen auf dieselbe Leerstelle: Welche Schicht zwischen „elektrischer und elektronischer Topologie“ und „Intelligenz“ macht aus einem Haufen Steuergeräte eine Maschine, die programmierbar ist, sich weiterentwickeln kann und schließlich autonomes Fahren und KI tragen kann?

Diese Frage beantwortet der vorliegende Beitrag. Es gibt eine einzige Leitfrage:

Unter welchen Bedingungen hört eine E/E-Architektur auf, bloß eine elektronische Topologie zu sein, und wird zur Plattform eines „programmierbaren Autos“?

Unsere Antwort lässt sich in vier Sätze fassen, die zugleich das Gerüst des Beitrags bilden:

E/E ist das Substrat. Die Steuerungsebene ist das OS. KI ist die adaptive Intelligenz. Autonomie ist der Belastungstest.

Ausgefaltet ergeben sich sechs Urteile:

• T1 | Definition: Das Fahrzeug-OS ist kein einzelnes Betriebssystem, sondern ein „System von Betriebssystemen“, das von einer fahrzeugweiten Steuerungsebene regiert wird. Steuerungsebene = Vertrag + Orchestrierung + Lebenszyklus.
• T2 | Vorbedingung: Ohne eine hinreichend entkoppelte E/E-Architektur gibt es kein Fahrzeug-OS. Die Obergrenze der Softwareabstraktion setzt die physische Architektur.
• T3 | Umkehr: Sobald Funktionen zu Software werden, kehrt sich die Kausalität um — Software-Workloads beginnen, die nächste E/E-Architektur zu gestalten. Das ist der originäre Kernbeitrag dieses Textes: der Architektur–OS-Koevolutionskreislauf.
• T4 | Belastungstest: Autonomes Fahren ist nicht das Fahrzeug-OS; es ist der Workload, der prüft, ob ein „Fahrzeug-OS“ diesen Namen verdient.
• T5 | Steuerung: KI wird das OS nicht abschaffen. Sie macht die obere Hälfte des OS dünner und die untere dicker — probabilistische Intelligenz muss innerhalb deterministischer Steuerung laufen.
• T6 | Konvergenzpunkt: Was die Branche tatsächlich standardisiert, ist nicht „ein Automobil-OS“, sondern „Fahrzeug-API + Datenmodell + Laufzeitvertrag“. Kernel werden zur Massenware, und der Kontrollpunkt C3 wird von beiden Seiten durch C2 (Silizium) und C4 (Middleware) in die Zange genommen.

Beginnen wir mit der grundlegendsten Aufgabe: den Begriff zu bereinigen.

---

1. Das Namensproblem: nicht alles, was „OS“ heißt, ist ein OS

1.1 Eine ontologische Bereinigung

In der Informatik hat „Betriebssystem“ eine recht klare Bedeutung: die Softwareschicht, die Hardwareressourcen verwaltet und den darüberliegenden Programmen Abstraktion und Isolation bietet. Linux, QNX und die diversen RTOS passen dazu. Das Problem ist, dass die Automobilbranche dasselbe Wort auf mindestens vier verschiedene Ebenen anwendet:

• OS auf Kernel-Ebene: QNX, Linux, das Classic-AUTOSAR-OS, RTOS, Mikrokernel. Sie verwalten einen Chip oder ein Steuergerät.
• Laufzeitumgebung und Middleware: AUTOSAR Adaptive Platform, SOME/IP, DDS, ROS 2. Sie definieren Kommunikation, Service Discovery und Ausführungsverwaltung, laufen selbst aber auf einem Kernel — die Zielhardware der Adaptive Platform betreibt ein POSIX-PSE51-konformes Betriebssystem, und AP baut darauf auf [T2].
• Domänen-OS: Android Automotive, BMW OS X, NVIDIA DriveOS, das HarmonyOS-Cockpit. Sie verwalten eine Funktionsdomäne, etwa das Cockpit oder den Fahrrechner.
• Was OEMs „Fahrzeug-OS“ nennen: MB.OS, SkyOS, HaloOS, Pleos Vehicle OS. Sie beanspruchen, das ganze Auto zu verwalten.

Die ersten drei Ebenen haben klare technische Grenzen. Die vierte nicht. Sie ist ein Markenname, eine organisatorische Verpflichtung und ein Softwarebestand über mehrere Kernel, Domänen und Chips hinweg. Dieser ganze Beitrag ist der Versuch, dieser vierten Ebene eine prüfbare Definition zu geben.

1.2 Drei Unterscheidungsregeln

Vor der Definition stellen wir drei negative Regeln auf. Ihre Aufgabe ist es, auszuschließen, was nicht als Fahrzeug-OS zählt.

Regel 1: Cockpit-OS ≠ Fahrzeug-OS.

BMW Operating System X basiert auf AOSP und übernimmt Anzeige, Interaktion und digitale Erlebnisse des Panoramic iDrive [T2]; die eigentliche Fahrzeugarchitektur der Neuen Klasse besteht aus vier „Superbrains“ — für Infotainment, automatisiertes Fahren, Fahrdynamik und Basisfunktionen — plus Zonensteuergeräten [T1–T2]. Hyundais Aufteilung ist noch klarer: Pleos Connect ist ein Infotainmentsystem auf Basis von Android Automotive, geplant für Q2 2026; Pleos Vehicle OS ist ein Fahrzeugsteuerungs-OS, das auf einem Hochleistungs-Fahrzeugrechner und Zonensteuergeräten aufbaut [T2–T3]. Dass ein Unternehmen beides in getrennte Marken aufteilt, ist selbst der beste Beleg: Das System, das auf dem Cockpit-Bildschirm am besten aussieht, ist nicht das System, das das Auto steuern kann.

Regel 2: Domänen-OS ≠ Fahrzeug-OS.

NVIDIA DriveOS ist Betriebssystem und Laufzeitumgebung für beschleunigtes Rechnen, Sensorintegration, automatisiertes Fahren und das KI-Cockpit; DriveOS 6.0 ist von TÜV SÜD nach ISO 26262 ASIL D zertifiziert [T2]. Es gehört zu den stärksten Produkten seines Feldes. Doch was es verwaltet, ist die DRIVE-Rechendomäne, nicht die fahrzeugweiten Funktionen einschließlich Karosserie, Thermomanagement, Energie und Fahrwerk.

Regel 3: Laufzeitumgebung ≠ OS.

AUTOSAR Adaptive definiert Verhalten: Ausführungsverwaltung, Kommunikation, Speicherung, Sicherheit. Es hängt unten von einem POSIX-Kernel und oben von der OEM-Integration ab. Es „ein OS“ zu nennen, ist, als nenne man TCP/IP das Netzwerk selbst.

Die drei Regeln haben eine gemeinsame Konsequenz: Der Name ist kein Kriterium. Was OS heißt, muss kein Fahrzeug-OS sein (BMW OS X ist keines); was nicht OS heißt, kann faktisch eine fahrzeugweite Plattform sein (Tesla hat seinem Software-Stack nie eine OS-Marke gegeben, Rivian ebenso wenig). Toyotas wechselndes Vokabular schärft den Punkt: Im April 2023 beschrieb Toyota Arene offiziell als „a comprehensive software platform and vehicle operating system“ [T1]; als es 2025 mit dem neuen RAV4 in Serie ging, sprachen Toyota und die Presse häufiger von einer „software development platform“ [T2]. Das ist kein Wortspiel. Es wirft eine Frage auf, zu der Kapitel 4 zurückkehrt: Liegt der Kontrollpunkt eines Fahrzeug-OS in der Laufzeitumgebung oder im Software-Lebenszyklus?

1.3 Chinas Taxonomie: eine Antwort mit nationalen Normen im Rücken

In der Definitionsfrage ist China weiter gegangen als jede andere Region, denn es hat die Antwort in nationale Normen geschrieben.

2019 veröffentlichte das Nationale Technische Komitee für Automobilnormung das Normensystem für Fahrzeugbetriebssysteme, das Fahrzeugbetriebssysteme in zwei Klassen teilt: Fahrzeugsteuerungs-Betriebssysteme und Bord-Betriebssysteme [T1]. Fahrzeugsteuerungs-OS werden weiter unterteilt in sicherheitsrelevante Fahrzeugsteuerungs-OS (Antrieb, Fahrwerk, Karosserie — mit den strengsten Echtzeit- und Sicherheitsanforderungen) und OS für intelligentes Fahren (für Fahrdomänen-Steuergeräte); Bord-OS bedienen Mittelkonsole, Kombiinstrument und T-Box.

Am 31. März 2026 wurde diese Taxonomie zu zwei empfohlenen nationalen Normen, in Kraft seit dem 1. Juli desselben Jahres [T1]:

• GB/T 47351-2026: Fahrzeugsteuerungs-Betriebssysteme, mit Typ I (OS für intelligentes Fahren) und Typ II (sicherheitsrelevantes Fahrzeugsteuerungs-OS).
• GB/T 47341-2026: technische Anforderungen und Prüfverfahren für Bord-Betriebssysteme. Laut Auszügen einer kommerziellen Übersetzung definiert sie das Bord-OS als „die Gesamtheit der Software, die intelligenten vernetzten Fahrzeugen Dienste außerhalb der Umsetzung von Fahrautomatisierungsfunktionen bereitstellt“, und empfiehlt ASIL B oder höher für Bord-OS, die hochechtzeitkritische Szenarien wie Warnungen im Kombiinstrument unterstützen [T3: kommerzielle Übersetzung, nicht der Normtext].

Öffentlichen Berichten zufolge ist schon die Liste der beteiligten Organisationen eine Branchenkarte: Huawei (Yinwang), Horizon Robotics, Qualcomm, NIO, BYD, Li Auto, Mercedes-Benz China und Volkswagen China gehören dazu [T2].

Der Wert der nationalen Normen liegt darin, dass sie Betriebssysteme nach funktionalem Sicherheitsattribut statt nach Marke einteilen. Sie lassen aber auch eine Lücke: Es gibt ein Fahrzeugsteuerungs-OS und ein Bord-OS, aber kein „Fahrzeug-OS“. Von der in Forschung und Industrie üblichen Vierteilung — sicherheitsrelevantes Fahrzeugsteuerungs-OS, OS für intelligentes Fahren, OS für das intelligente Cockpit und das domänenübergreifende „Zentralrechner-OS“ — hat das vierte kein Gegenstück in den Normen. [Inferenz] Genau in dieser Lücke lebt das Marketingkonzept „Fahrzeug-OS“, und genau das will dieser Beitrag mit der Idee einer Steuerungsebene fassen.

1.4 Ist das Fahrzeug-OS also eine Scheinthese?

Legen wir den schärfsten Einwand zuerst auf den Tisch: Ohne die Markenschicht bleibt vom sogenannten Fahrzeug-OS nur QNX + Linux + AUTOSAR + ein Hypervisor + ein Haufen Middleware — alles schon vor zehn Jahren vorhanden. Was bleibt übrig?

Unsere Antwort: Als Marke ist es überzeichnet; als technische Einheit ist es real. Was bleibt, ist nicht ein einzelner Kernel, sondern das, was mehrere Kernel, Domänen und Chips zu einem Auto organisiert — ein einheitlicher Servicevertrag, Orchestrierung über Kritikalitätsstufen hinweg und ein Aktualisierungs- und Validierungssystem, das das ganze Fahrzeugleben umspannt. Das nächste Kapitel nimmt es auseinander.

---

2. Ein System von Betriebssystemen: ein „Fahrzeug-OS“ zerlegt

2.1 Jedes Serien-Fahrzeug-OS ist ein Mehrkernel-Verbund

Öffnet man ein beliebiges Fahrzeug-OS in Serie, findet man keinen einzelnen Kernel, sondern eine Familie.

NIO SkyOS nutzt eine „1+4+N“-Struktur [T2]: Die „1“ ist SkyOS-H, ein Hypervisor zur Verwaltung heterogener Rechenressourcen; die „4“ sind vier Kernel für unterschiedliche Szenarien — der Fahrzeugsteuerungs-Kernel basiert auf dem formal verifizierten Mikrokernel seL4, der Cockpit-Kernel auf einem tiefgreifend angepassten Android; die „N“ sind eigenentwickelte Middleware-Komponenten für domänenübergreifende Koordination und Lebenszyklus-Updates. [T3: Die Quellen weichen bei der genauen Arbeitsteilung der übrigen Teilkernel voneinander ab; wir gehen hier nicht darauf ein.] SkyOS wurde am 27. Juli 2024 vollständig ausgerollt und läuft auf Modellen der NT3-Plattform im vollen Umfang [T2].

Li Auto HaloOS ist ein dreiteiliges Paket: ein Fahrzeugsteuerungs-OS, ein OS für intelligentes Fahren und eine Kommunikations-Middleware [T2]. Am 27. März 2025 kündigte Li Auto die Offenlegung als Open Source an; im April erschien 0.1.0 (sicherheitsgerichtetes Echtzeit-RTOS plus leichtgewichtiger Kommunikationsbus), am 30. Juni 1.0.0, danach wurde die Virtualisierungs-Engine geöffnet [T2]. Li Auto gibt an, mehr als 200 Mitarbeitende und über 1 Mrd. RMB investiert, 2024 die erste Serienversion ausgeliefert und die Chip-Anpassung von 3–6 Monaten auf vier Wochen verkürzt zu haben [T2, Unternehmensangabe].

Hyundai Pleos teilt Fahrzeugsteuerungs-OS und Cockpit-OS in zwei Marken (siehe 1.2). GB/T 47351 teilt das Fahrzeugsteuerungs-OS selbst in Typ I und Typ II.

Es gibt nur einen Schluss, und er ist die erste These des Beitrags:

T1 | Das Fahrzeug-OS ist kein einzelnes Betriebssystem, sondern ein „System von Betriebssystemen“, das von einer fahrzeugweiten Steuerungsebene regiert wird.

2.2 Ein sechsschichtiges Stapelmodell: S0–S5

Um die Produkte verschiedener Anbieter in ein Bild zu bringen, schlagen wir ein sechsschichtiges Stapelmodell vor (Abbildung 2.1).

Darum liegt ein äußerer Ring, der nicht im Fahrzeug sitzt, aber bestimmt, was das Fahrzeug kann: Cloud, OTA, der Datenkreislauf, DevSecOps und der neu entstehende Modell-Lebenszyklus.

Abbildung 2.1 — Ein System von Betriebssystemen: der S0–S5-Stapel und der äußere Ring. Lesehinweis: Das Fahrzeug-OS ist keine einzelne Schicht der Abbildung, sondern die einheitliche Steuerung von S1–S3 durch S4; S0 bestimmt, wie viel S4 steuern kann; der äußere Ring bestimmt, ob S4 sich nach dem Verkauf des Autos weiterentwickeln kann.

2.3 Die drei Teile der Steuerungsebene: Vertrag, Orchestrierung, Lebenszyklus

„Steuerungsebene“ (Control Plane) stammt aus der Netzwerktechnik: Die Datenebene leitet jedes Paket weiter, die Steuerungsebene entscheidet, wohin Pakete gehen sollen. Im Auto ist die Datenebene die Prozesse, Tasks und Signale, die tatsächlich in S1–S3 laufen; die Steuerungsebene ist die Schicht, die entscheidet, wer wo laufen darf, mit welcher Priorität, über welche Schnittstelle und unter welchen Bedingungen er ersetzt werden darf.

Wir zerlegen die Fahrzeug-Steuerungsebene in drei Teile:

1. Vertrag: Serviceschnittstellen, die Fahrzeug-API, Signal- und Datensemantik. Er verspricht, dass „Funktionen vom physischen Ort der Steuergeräte entkoppelt sind“ — ein Klimaregelungsdienst muss sich nicht darum kümmern, auf welchem Chip er am Ende läuft.
2. Orchestrierung: Scheduling gemischter Kritikalität, Nachweis der Isolation (Freedom from Interference), Funktionsmigration, Ressourcenzuteilung. Sie entscheidet, wie eine ASIL-D-Bremsfunktion und eine QM-Musikwiedergabe einen Chip teilen, ohne sich zu stören.
3. Lebenszyklus: OTA, Rollback, Diagnose, DevSecOps und nun der Modell-Lebenszyklus. Er entscheidet, wie stark das Auto nach Verlassen des Werks noch verändert werden kann, wie schnell und unter welchem Sicherheitsargument.

Durch diese drei Teile betrachtet, werden die Regeln aus 1.2 viel klarer: Ein Cockpit-OS hat einen Vertrag nur für die Cockpit-Domäne; ein Domänen-OS hat starke Orchestrierung, aber nur innerhalb einer Domäne; eine Laufzeitumgebung spezifiziert Verträge, übernimmt aber keine Verantwortung für fahrzeugweite Orchestrierung oder Lebenszyklus. Wir nennen etwas nur dann ein Fahrzeug-OS, wenn Vertrag, Orchestrierung und Lebenszyklus gemeinsam die Hauptdomänen des Fahrzeugs abdecken.

Diese Definition hat einen unmittelbaren Vorteil: Sie ist beobachtbar. Behauptet ein Hersteller, ein Fahrzeug-OS zu haben, müssen wir nur drei Fragen stellen — Welche Domänen deckt seine Fahrzeug-API ab? Welche Zertifizierungsstufe hat seine Integration gemischter Kritikalität erreicht? Welche Domänen kann sein OTA aktualisieren? Die VOCM-Bewertung in Kapitel 5 faltet diese drei Fragen zu sechs Dimensionen aus.

2.4 Eine unterschätzte Tatsache: extreme Konzentration unten, extreme Zersplitterung oben

Projiziert man die Produkte aller Anbieter auf S0–S5, ergibt sich ein scharfes Bild:

• Auf S1 ist der Markt extrem konzentriert. Laut BlackBerrys Geschäftsbericht für das Geschäftsjahr 2026 ist QNX in mehr als 275 Millionen Fahrzeugen eingebettet, 20 Millionen mehr als im Vorjahr, arbeitet mit über 45 Herstellern und deckt die Top-10-OEMs sowie 24 der 25 größten EV-OEMs ab [T1]. QNX OS for Safety und QNX Hypervisor for Safety sind beide nach ISO 26262 ASIL D zertifiziert [T1].
• Auf S4 ist der Markt extrem zersplittert. Mehr als zehn Hersteller beanspruchen jeweils ein eigenes Fahrzeug-OS, keines mit den anderen kompatibel.

Das ist D1s zweischichtiges Konvergenz-Divergenz-Modell, das auf der Softwareebene wiederkehrt: Die Infrastruktur konvergiert unten, die Steuerungssemantik divergiert oben. Es kündigt auch den Wettstreit an, den Kapitel 7 behandelt — wenn S1 und S2 zwangsläufig zur Massenware werden, wohin wandert der Wert?

---

3. Erst die Straße, dann das Auto: die E/E-Architektur setzt die Grenze des Möglichen

3.1 Warum auf einer verteilten Architektur kein Fahrzeug-OS wächst

Man stelle sich ein konventionelles Auto mit 100 Steuergeräten vor. Jedes betreibt sein eigenes OSEK oder Classic AUTOSAR, jedes stammt von einem anderen Tier 1, jedes hat eigene Softwareversion, Kalibrierdaten und Flash-Prozess. In einem solchen Auto ist ein Fahrzeug-OS physisch unmöglich — es gibt keinen Ort, an dem eine einheitliche Laufzeitumgebung leben könnte, und keinen Kanal, breit genug, damit ein Servicevertrag Steuergerätegrenzen überqueren könnte.

Das ist die zweite These des Beitrags:

T2 | Ohne eine hinreichend entkoppelte E/E-Architektur gibt es kein Fahrzeug-OS. Die Obergrenze der Softwareabstraktion setzt die physische Architektur.

3.2 Fünf Wegbereiter

Als sich die E/E-Architektur von verteilt zu domänenbasiert und weiter zu zonal plus Zentralrechner entwickelte, machten fünf Dinge die Fahrzeug-Steuerungsebene technisch möglich (entsprechend dem sechsstufigen Bosch-Rahmen in D1, Kapitel 2):

Von den fünf entscheiden die ersten vier, ob die Steuerungsebene vereinheitlicht werden kann; der fünfte entscheidet, ob man ihr vertrauen kann. Ohne die ersten vier gibt es kein Fahrzeug-OS; ohne den fünften bleibt das Fahrzeug-OS in der Fail-soft-Welt — ein Punkt, den Kapitel 6 ausführt.

3.3 Die Generationenmatrix: welche Schicht jede E/E-Generation tragen kann

Kreuzt man S0–S5 mit den E/E-Generationen (Abbildung 3.1), zeigt sich ein einfaches Muster:

• Verteilt: nur S1 (das eigene RTOS jedes Steuergeräts).
• Domäne: S2 und S3 erscheinen — Android im Cockpit, Linux / QNX fürs Fahren, SOA innerhalb der Domäne. Aber jede Domäne macht ihr eigenes Ding; die meisten „Fahrzeug-OS“-Ansprüche dieser Generation waren Marketing.
• Domänenübergreifende Fusion: teilweise S4 erscheint — zwei oder drei Domänen beginnen, Verträge zu teilen; Cockpit-Fahr-Integration wird erprobt.
• Zonal + Zentralrechner: S4 wird wirklich technische Realität.
• Zentral + KI-nativ: S5 beginnt zu erscheinen.

Abbildung 3.1 — Was jede E/E-Generation tragen kann. Die x-Achse ist die E/E-Generation (verteilt → Domäne → domänenübergreifende Fusion → zonal + zentral → zentral + KI-nativ); die y-Achse ist S1–S5. Jede Zelle ist markiert als „nicht machbar / teilweise / in Serie / im Entstehen“. Lesehinweis: Die „in Serie“-Zellen von S4 erscheinen erst ab der Spalte zonal + zentral; die meisten Produkte, die vorher „Fahrzeug-OS“ hießen, sitzen tatsächlich in S3.

Die Matrix liefert eine falsifizierbare Folgerung: Baut jemand eine Steuerungsebene, die die Hauptdomänen des Fahrzeugs abdeckt, ohne die E/E-Generation zu wechseln, muss T2 revidiert werden. Wir führen das als einen der Revisionsauslöser (Kapitel 10).

---

4. Die Kausalität kehrt sich um: wenn Software beginnt, Hardware zu gestalten

4.1 Von „E/E trägt das OS“ zu „das OS gestaltet die E/E“

Kapitel 3 beschrieb eine Richtung: erst E/E, dann OS. Es ist die Geschichte, die die Branche am häufigsten erzählt — und die unvollständigere Hälfte.

Die andere Hälfte: Sobald ein Hersteller wirklich eine Fahrzeug-Steuerungsebene aufgebaut hat, beginnt er im Gegenzug, die nächste E/E-Architektur zu bestimmen.

GM liefert ein seltenes, vom Hersteller selbst veröffentlichtes Beispiel. Seine zentrale Rechenplattform für 2028 soll die 10-fache OTA-Fähigkeit, die 1.000-fache Bandbreite und die 35-fache KI-Rechenleistung bringen [T1, Unternehmensangabe]. Keine dieser drei Zahlen ist aus „besserer Hardware“ abgeleitet; alle sind Hardwarespezifikationen, die rückwärts aus dem abgeleitet wurden, was die Software leisten muss.

Leapmotors Tech Day im September 2026 lieferte ein zweites, detaillierteres Beispiel. Leapmotor stellt seine E/E-Entwicklung als klare Generationenlinie dar:

• LEAP 3.0: die zentral integrierte „Four-Leaf Clover“-Architektur, eingeführt 2023.
• LEAP 4.0: Cockpit-Fahr-Integration auf einem einzigen Chip auf der D-Plattform [T3].
• LEAP 5.0: das kommende „Four-Leaf Clover 5.0“ mit drei Änderungen [T2–T3]:
  • Steuerung: zentral integrierte Steuerung.
  • Energie: fahrzeugweite 48-V-Versorgung, Gesamtverkabelung unter 500 Metern, Kabelbaumgewicht um bis zu 50 % reduziert und — laut Unternehmen — Leitungswärmeverluste auf 1/16 gesenkt.
  • Netzwerk: fahrzeugweites Ethernet mit asymmetrischer Bandbreite — 10G downstream, 100M upstream.
• Serie: erste Modelle 2027 [T2].

Der letzte Netzwerkpunkt verdient einen Moment Aufmerksamkeit. Symmetrische Bandbreite ist die Logik eines Allzwecknetzes; asymmetrische Bandbreite heißt, dass das Netz danach ausgelegt ist, wie Daten tatsächlich fließen — welche Richtung schweren Verkehr trägt und welche nur Steuerung und Status. [Inferenz] Das ist eine von Software und Datenflüssen definierte Netzwerktopologie: erst wissen, wie die Steuerungsebene Daten bewegen muss, dann entscheiden, wie die Leitungen verlegt werden. Die 48-V-Versorgung und der kürzere Kabelbaum folgen derselben Logik — zentrale Steuerung erlaubt es, Energieverteilung und Verkabelung um „ein Gehirn plus einige Zonen“ neu zu organisieren statt um „eine Box pro Funktion“.

Das ist die Kernthese des Beitrags:

T3 | Sobald Funktionen zu Software werden, kehrt sich die Kausalität um: Software-Workloads beginnen, die nächste E/E-Architektur zu gestalten.

Fügt man beide Richtungen zusammen, entsteht ein geschlossener Kreislauf (Abbildung 4.1):

E/E-Architektur → Fahrzeug-Steuerungsebene → Workloads / Daten / KI → E/E-Architektur der nächsten Generation

Wir nennen ihn den Architektur–OS-Koevolutionskreislauf.

Abbildung 4.1 — Der Architektur–OS-Koevolutionskreislauf. Lesehinweis: Die obere Hälfte des Kreislaufs (E/E → OS) ist die „Grenze des Möglichen“, gebildet aus den fünf Wegbereitern aus Kapitel 3; die untere Hälfte (OS → E/E) ist die „Rückwärtsauslegung“, gebildet aus den sechs Anforderungsklassen der obigen Tabelle. Ob ein Hersteller in die softwaredefinierte Phase eingetreten ist, entscheidet sich nicht daran, ob er eine OS-Marke hat, sondern daran, ob sich die untere Hälfte zu drehen begonnen hat.

Um es klar zu sagen: Dieser Kreislauf ist keine weitere Reifegradleiter. Die Reihe hat bereits AR0–AR5 (Fähigkeitsschwellen des gestalteten Systems) und AI²-ML (Reife der Werkzeugkette). Der Koevolutionskreislauf beschreibt eine kausale Struktur, keine Stufe.

4.2 Das Spektrum der „Verdummung“: ein Streit über Vertrauen

Der sichtbarste Ausdruck der unteren Kreislaufhälfte ist, wie weit Zonensteuergeräte „verdummt“ werden — ob kritische Steuerlogik in den Zonen bleibt oder ins Zentrum wandert.

An einem Ende steht GM. Seine zonalen „Aggregatoren“ führen ausdrücklich „keine Steuerlogik aus“; alle Intelligenz — Sensorfusion, Steuerungsarbitrierung, Inferenz maschinellen Lernens — sitzt im Zentralrechner [T1]. Das ist der Weg der vollständigen Verdummung.

Am anderen Ende steht BMW. Die Neue Klasse legt die Fahrdynamik auf einen eigenen Hochleistungsrechner namens „Heart of Joy“, zehnmal schneller als ein konventionelles Steuergerät [T2]; Infotainment, automatisiertes Fahren und Basisfunktionen haben je ein eigenes Superbrain. Das ist der Weg „kritische Steuerung bleibt außerhalb des Zentrums“.

Noch weiter außen liegt die konventionelle Architektur mit über viele Steuergeräte verteilter Steuerlogik.

Abbildung 4.2 — Das Spektrum der Verdummung von Zonensteuergeräten. Von links nach rechts: verteilte Steuergeräte → BMW-Stil „kritische Steuerung auf unabhängigem Rechner“ → GM-Stil „Aggregatoren leiten nur weiter; alle Intelligenz im Zentrum“. Lesehinweis: Die x-Achse misst nicht „wie fortschrittlich“, sondern „wie viel Vertrauen in die zentrale Steuerungsebene gesetzt wird, die ASIL-D-Ausführungskette zu tragen“.

[Inferenz] Der Streit sieht aus wie eine Debatte über Hardwaretopologie; in der Sache ist es eine Vertrauensfrage: Ist der Determinismus der zentralen Steuerungsebene bereits gut genug, um ihr die ASIL-D-Ausführungskette anzuvertrauen? GMs Antwort lautet „ja“, BMWs „nicht ganz“. Es gibt keine Standardantwort, aber die Richtung der Kausalität ist klar — es ist ein Urteil über die Fähigkeit des OS, das die E/E-Topologie bestimmt.

4.3 Ein beobachtbarer Indikator: OTA-Granularität

Die Abdeckung einer Steuerungsebene ist von außen schwer zu beobachten — Hersteller veröffentlichen ihre Fahrzeug-API-Kataloge nicht. Doch eines ist beobachtbar: welche Domänen OTA aktualisieren kann.

Der neue Toyota RAV4 ist ein sauberes Beispiel: Mit Arene lassen sich Cockpit und ADAS drahtlos aktualisieren, Karosserie- und Fahrdynamikfunktionen noch nicht [T2]. [Inferenz] Das deutet darauf hin, dass Arenes Vertrag die Fahrzeugsteuerungsdomäne noch nicht abdeckt. Umgekehrt hat ein Hersteller, der Brems- oder Antriebskalibrierung drahtlos aktualisieren kann, die sicherheitskritische Ausführungskette unter Lebenszyklusverwaltung gebracht.

Wir verwenden daher die OTA-Granularität als externen Indikator für die „Vertragsabdeckung der Steuerungsebene“ und setzen ihn in der VOCM-Dimension V5 ein (Kapitel 5). Er ist nicht perfekt — OTA-Fähigkeit ist nicht dasselbe wie gute Architektur —, aber er gehört zu den wenigen Indikatoren, die sich aus öffentlichen Informationen überprüfen lassen.

4.4 Das andere Gesicht von Conways Gesetz: E/E und OS aus einer Organisation

D3 behandelte Teslas Zusammenlegung der FSD- und Optimus-Teams, bei der die Organisationsstruktur die technische Architektur formt. Zum Verhältnis von E/E und OS gibt es neuere und direktere öffentliche Belege.

In seiner Proxy-Erklärung 2026 definiert Rivian RV Tech, sein Joint Venture mit dem Volkswagen-Konzern, als „electrical architecture technology company with a focus on software, electronic control units and related network architecture“ [T1]. Mit anderen Worten: E/E-Topologie, Steuergeräte und Software sind in diesem Unternehmen ein einziges Liefergut.

Rivians Zahlen für das Geschäftsjahr 2025 zeigen das wirtschaftliche Gewicht dieses Lieferguts: Der Bruttogewinn aus Software und Services stieg von 7 Mio. USD 2024 auf 576 Mio. USD, getrieben vor allem von „vehicle electrical architecture and software development services“ im Zusammenhang mit dem Joint Venture [T1].

[Inferenz] Die Bedeutung dieser Zahlen liegt nicht im Betrag, sondern in der Preiseinheit: „E/E + OS“ lässt sich inzwischen als Ganzes bepreisen und handeln. Sobald eine Architektur für sich verkauft werden kann, ist sie kein Zubehör eines Autos mehr, sondern ein Vermögenswert. Hier bekommt der Koevolutionskreislauf ein Gegenstück in der Bilanz.

Der Volkswagen-Konzern geht noch weiter: Er betreibt gleichzeitig zwei E/E-Architekturen, die von verschiedenen Organisationen geliefert werden — RV Tech in der westlichen Hemisphäre und CEA in China. Abschnitt 5.5 kommt darauf zurück.

4.5 Abwärtskompatibilität: der Preis des Kreislaufs und die Feuerprobe des Vertrags

Der Koevolutionskreislauf hat eine leicht übersehene Nebenwirkung: Während die nächste E/E-Architektur von Softwarebedürfnissen neu gestaltet wird, ist die vorige Fahrzeuggeneration noch auf der Straße. Können diese Fahrzeuge weiterhin neue Software erhalten? Das führt zu einer strengeren Frage als „kann es OTA?“:

Kann ein Fahrzeug-OS abwärtskompatibel sein — sodass Fahrzeuge der vorigen oder sogar vorvorigen Hardwaregeneration weiterhin drahtlos Softwarefähigkeiten der neuen Generation erhalten?

Unsere Antwort: Abwärtskompatibilität ist der strengste externe Test dafür, ob die Entkopplung von Hardware und Software real ist; beurteilt werden sollte sie aber danach, ob der Vertrag stabil ist, nicht danach, ob die Funktionen gleich sind. Dafür gibt es vier Gründe.

Erstens ist sie die einzige Form der Entkopplung, die sich von außen prüfen lässt. Jeder Hersteller sagt, er habe Hardware und Software entkoppelt. Läuft neue Software aber nur auf neuer Hardware, bedeutet die „Entkopplung“ in Wahrheit „jede Generation neu integrieren“. Bewiesen ist die Entkopplung erst, wenn Software der neuen Generation über denselben Vertrag auf alte Hardware gebracht werden kann.

Zweitens ist die Bestandsflotte der Nenner der Softwareökonomie. Software-Abos, kostenpflichtige Funktionen und der Datenkreislauf skalieren mit der Zahl der Fahrzeuge, die Updates empfangen können. Schneidet man bei jeder Generation die alten Autos ab, fällt der Nenner der Softwareerlöse periodisch auf null.

Drittens hat die Regulierung Kompatibilität bereits in den Aktualisierungsprozess geschrieben. Absatz 7.1.1 von UN R156 verlangt, dass das Software-Update-Managementsystem eines Herstellers eine Reihe von Prozessen umfasst, darunter: die Zielfahrzeuge eines Updates zu identifizieren (7.1.1.6), vor Freigabe die Kompatibilität eines Updates mit der Konfiguration der Zielfahrzeuge zu bestätigen (7.1.1.7), Abhängigkeiten des aktualisierten Systems von anderen Systemen zu identifizieren (7.1.1.5) und die RXSWIN-Softwarekennung vor und nach einem Update zu pflegen (7.1.1.3) [T1]. Abwärtskompatibilität ist nicht nur eine Frage des Nutzererlebnisses; sie ist ein Punkt, den das Update-Managementsystem beantworten muss.

Viertens legt sie die Spannung im Kreislauf offen. Muss die nächste E/E-Architektur für ältere Autos denselben Vertrag beibehalten, legt der Vertrag den Entwicklungspfad der E/E-Architektur fest — genau hier zeigen sich Wert und Kosten einer Steuerungsebene zugleich. Verzichtet man auf den Vertrag, gibt man die Bestandsflotte auf; behält man ihn, schleppt die neue Architektur alte Schnittstellen mit.

Abwärtskompatibilität kann aber nicht Funktionsgleichheit bedeuten. Rechenleistung, Sensorausstattung und Redundanz sind physische Tatsachen, die OTA nicht ändern kann. D3 hat bereits den Generationenbruch zwischen Teslas HW3 und neueren FSD-Versionen behandelt: Ist der Hardwareabstand zu groß, kann selbst der aggressivste softwaredefinierte Akteur alte Hardware nicht jede neue Fähigkeit ausführen lassen.

Eine bessere Beurteilung entlehnt den Ansatz der Smartphone-Branche — Vertragsstabilität bei abgestuften Fähigkeiten:

Leapmotors Tech Day lieferte ein öffentliches Beispiel für Stufe 3: Seine LWM-Fahrerassistenz auf Basis eines Weltmodells soll das Codevolumen um 90 % senken, lässt sich auf Rechenstufen von 200, 640 und 1.280 TOPS einsetzen und kommt mit der Zusage kostenloser Upgrades und lebenslang kostenloser Nutzung für alle Fahrzeuge mit LiDAR — Presseberichten zufolge rund 350.000 Bestandsfahrzeuge [T3, Unternehmensangabe]. [Inferenz] „Ein Modell, mehrere Rechenstufen“ ist selbst eine Auslegung für Abwärtskompatibilität — es verwandelt Fähigkeitsunterschiede von „vorhanden oder nicht“ in „mehr oder weniger“.

Wir integrieren Abwärtskompatibilität daher in die Bewertungsmatrix der VOCM-Dimension V2 (Hardware-Software-Entkopplung; Anhang B): V2 kann nur dann 4 oder mehr erreichen, wenn nachgewiesen ist, dass Softwarefähigkeiten über Hardwaregenerationen hinweg geliefert werden können. Sie ist keine siebte Dimension, weil sie im Kern ein Test der Entkopplung ist und keine eigenständige Fähigkeit.

4.6 Zusammenfassung: Ob ein Hersteller ein Fahrzeug-OS hat, zeigt die untere Hälfte

Die Schlussfolgerung dieses Kapitels taugt als praktischer Test:

Fragen Sie nicht, ob ein Hersteller „ein Fahrzeug-OS hat“. Fragen Sie, ob seine untere Hälfte sich zu drehen begonnen hat — wird seine nächste E/E-Spezifikation von den Bedürfnissen der Software der aktuellen Generation definiert?

Wenn ja, ist er in die softwaredefinierte Ära eingetreten. Wenn nicht, befindet er sich — wie auch immer seine OS-Marke heißt — noch im Stadium „hardwaredefiniert, softwaregefüllt“.

Es gibt eine zweite Frage: Ist die vorige Fahrzeuggeneration noch im selben Vertrag? Je schneller sich die untere Hälfte dreht, desto schärfer wird diese Frage.

---

5. Der Tisch 2026: wer was tut und wie weit er gekommen ist

5.1 Nicht fragen „ist es reif?“, sondern „welche Schicht ist reif?“

„Ist das Fahrzeug-OS reif?“ hat keine Antwort, denn die Schichten liegen eine Ära auseinander.

Das Gesamturteil:

2026 ist das Jahr, in dem das Fahrzeug-OS von der „architektonischen Ambition“ in die „frühe Serienrealität“ übergegangen ist. Es ist keine Folie mehr, aber weit entfernt von einem stabilen Branchenparadigma wie Android / iOS.

Nach Serienstatus lassen sich die wichtigsten Akteure in vier Stufen einteilen. Achtung: Das ist eine beschreibende Einteilung, keine neue Reifegradleiter:

• M1 Infrastruktur im großen Maßstab (Hunderte Millionen / Millionen Fahrzeuge): QNX, Classic AUTOSAR, das HarmonyOS-Cockpit, Android Automotive.
• M2 Full-Domain-Steuerungsebene des OEM in Serie: MB.OS (CLA), SkyOS (NT3-Plattform), HaloOS, BMW Neue Klasse, Tesla.
• M3 Markteinführung oder Serie in Teildomänen: Toyota Arene (RAV4; Karosserie und Fahrdynamik noch nicht per OTA aktualisierbar) [T2]; Hyundai Pleos Connect (Markteinführung Q2 2026, nur Infotainment) [T2–T3]; Rivians Plattform der zweiten Generation.
• M4 auf der Roadmap oder in Umstrukturierung: GMs zentrale Rechenplattform (2028, Debüt im Cadillac Escalade IQ) [T1]; Stellantis STLA Brain (ursprünglich Integration bis Ende 2024, nun erstmals mit der Plattform STLA One 2027 integriert) [T1–T2]; die RV-Tech-Architektur von Volkswagen-Konzern × Rivian (Wintertests im Q1 2026 abgeschlossen, Debüt mit dem ID.EVERY1 2027) [T1]; Hyundai Pleos Vehicle OS und seine zentralisierte Zonenarchitektur (Ziel 2030) [T3].

Die China-Architektur des Volkswagen-Konzerns, CEA, ist bereits über diese Stufe hinaus: Ende 2025 ging sie in Anhui in Serie, im Januar 2026 kam sie mit dem ID. UNYX 07 auf den Markt, laut Unternehmen mit Unterstützung für Gesamtfahrzeug-OTA [T1] — ein M3-Fall.

Ein wiederkehrendes Muster verdient Beachtung: Fast jeder Hersteller in M4 liegt hinter seinem ursprünglichen Zeitplan. Die Software-Tochter des Volkswagen-Konzerns, CARIAD, ist das meistbeachtete Beispiel: Die einheitliche Softwareplattform, die sie liefern sollte, verzögerte sich wiederholt, das Unternehmen durchlief ab 2025 eine tiefgreifende Umstrukturierung mit Stellenabbau [T3], und die westliche Architektur der nächsten Generation liefert nun RV Tech. [Inferenz] Ursache der Verzögerung ist selten der Kernel oder der Chip; meist ist es die Organisation — Dutzende funktionale Silos in eine Plattformorganisation umzubauen ist weit schwerer, als einen Hypervisor zu schreiben. Kapitel 9 kommt darauf zurück.

5.2 Nach Rolle, nicht nach Marke: neun Arten von Akteuren

Am Tisch des Fahrzeug-OS sitzen Akteure mit völlig unterschiedlichen Rollen. Eine Rangfolge nach Marke vermengt sie; eine Einteilung nach architektonischer Rolle zeigt, wer tatsächlich mit wem konkurriert.

5.3 VOCM: die Fahrzeug-Steuerungsebene in sechs Dimensionen bewerten

Um Akteure der Rollen ① bis ④ mit einem Maßstab zu messen, schlagen wir die Vehicle OS Capability Matrix (VOCM) vor. Sie faltet „Vertrag + Orchestrierung + Lebenszyklus“ aus Abschnitt 2.3 in sechs Dimensionen aus, jeweils mit 0–5 Punkten, maximal 30. Die Bewertungsmatrix steht in Anhang B.

Wie sich VOCM zu den bestehenden Rahmenwerken der Reihe verhält — das muss klar gesagt werden, um Doppelzählungen zu vermeiden:

• AR0–AR5 misst die architektonischen Fähigkeitsschwellen des gestalteten Systems (des Fahrzeugs), vor allem Hardwaretopologie und Systemintegration; VOCM misst nur die Software-Steuerungsebene. Beide sind orthogonal: Ein Hersteller kann bei AR hoch und bei VOCM niedrig liegen oder umgekehrt — und genau in dieser Abweichung liegt der analytische Wert.
• AI²-ML misst die Reife von Architektur-Werkzeugketten — ein ganz anderer Gegenstand. VOCMs V2 und V5 ähneln dem Namen nach AI²-MLs D2 (HW/SW-Entkopplung) und D3 (OTA), doch erstere betrachten die Software im Auto, letztere die Werkzeuge, mit denen das Auto gestaltet wird.
• VOCM ist keine Reifegradleiter und definiert keine „VOCM-Stufen“. Es ist ein sechsdimensionales Fähigkeitsprofil.

5.4 Erste Bewertung

Die folgende Tabelle zeigt die erste VOCM-Bewertung, gegenübergestellt den AR-Snapshot-Werten aus D2 (Snapshot 2026.1.31, Fünf-Dimensionen-Summe von 25, hier zitiert, nicht neu bewertet).

Die Werte beruhen ausschließlich auf öffentlichen Quellen. Die Konfidenz H / M / L spiegelt die Belegstärke: H = die meisten Dimensionen direkt durch Tier-1–2-Belege gestützt; M = einige Dimensionen beruhen auf Unternehmensangaben; L = die meisten Dimensionen beruhen auf Sekundärquellen oder Inferenz. Wie in D2 bewertet die Tabelle bei Herstellern, deren Flaggschiff-Architektur in Serie ist, deren Flotte aber größtenteils noch nicht umgestellt hat, die jüngste Serienarchitektur und vermerkt dies.

Nicht bewertet (unzureichende Belege in dieser Runde): Ford, Lucid, Geely, GWM, SAIC, Stellantis, Renault, Kia.

Leapmotor gehört nicht zu den 22 OEMs aus D2; es hat daher einen VOCM-Wert, aber keinen AR-Wert, und erscheint nicht im Streudiagramm von Abbildung 5.1. Grundlage der Bewertung:

• V1, V3: zentral integrierte Architektur seit LEAP 3.0; Cockpit-Fahr-Integration auf einem Chip in LEAP 4.0 [T3].
• V2: Das Weltmodell lässt sich auf drei Rechenstufen einsetzen, mit zugesagter kostenloser Auslieferung an Bestandsfahrzeuge mit LiDAR [T3, Unternehmensangabe].
• V6: Fahrzeug-Cloud-AgentOS [T3].
• Die übrigen Dimensionen beruhen auf Sekundärberichten; die Konfidenz ist niedrig.

Die Bewertung wird aktualisiert, sobald LEAP 5.0 2027 in Serie geht.

Anmerkungen:

• Mercedes wird anhand von MB.OS in seiner Erstauslieferung im CLA bewertet.
• Der Volkswagen-Konzern wird anhand seiner China-Architektur CEA (ID. UNYX 07) bewertet. Öffentliche Grundlage: Zonensteuerung mit quasi-zentralem Rechnen, rund 30 % weniger Steuergeräte, Unterstützung für Gesamtfahrzeug-OTA, Abdeckung aller Antriebsarten — batterieelektrisch, hybrid und Verbrenner [T1]; alle zwei Jahre eine neue CEA-Generation (2.0 im Jahr 2027, vom A- bis zum D-Segment), mit Fahr-Rechenleistung geplant sowohl auf XPengs Turing-Chip als auch auf einer CARIZON-Lösung (Volkswagens Joint Venture mit Horizon Robotics) [T3]. CEA wurde gemeinsam mit XPeng entwickelt und übernimmt dessen Architekturlinie; wo öffentliche Informationen zu V1, V3, V4 und V5 dünn sind, orientieren sich die Werte daher an XPeng [Inferenz] — die Ausnahme für dieselbe Architekturlinie zur Regel „ohne Belege höchstens 2 Punkte“ aus Anhang B. V6 liegt einen Punkt unter XPeng: Die Fahr-Rechenleistung stammt von zwei Lieferanten, und öffentliche Quellen zeigen auf CEA keine gemeinsame Planung von Ende-zu-Ende / VLA mit dem OS, wie XPeng sie hat.
• Die RV-Tech-Architektur ist noch nicht in Serie (2027) und wird in dieser Runde nicht bewertet; eine Aktualisierung folgt nach Markteinführung. Laut Unternehmen „powerful modular central computers control all vehicle functions“ [T1]. Bestätigt sich das in Serie, erreicht ihr V1 unmittelbar 4–5 Punkte.

Abbildung 5.1 — E/E-Architektur × Fähigkeit des Fahrzeug-OS. x-Achse: D2-AR-Snapshot-Summe (/25); y-Achse: VOCM-Summe (/30). Ein Punkt pro Hersteller; hohle Punkte bedeuten niedrige Konfidenz. Die gestrichelte Linie ist die Paritätsdiagonale (gleicher Anteil am jeweiligen Skalenmaximum); das schattierte Band ist die Trendlinie der Stichprobe ±2,5 Punkte (ohne VW CEA angepasst). Lesehinweis: Hersteller innerhalb des Trendbands entwickeln Steuerungsebene und E/E im Gleichschritt; die Punkte deutlich abseits des Bands sind die, die Fragen aufwerfen.

5.5 Das Diagramm lesen: vier Befunde

Befund 1: AR und VOCM bewegen sich eng zusammen, doch die Steuerungsebene hinkt einen halben Schritt hinterher. Abgesehen von VW CEA bilden die 13 Punkte in Abbildung 5.1 nahezu eine Gerade: Die angepasste Steigung beträgt etwa 1,2 — genau das Verhältnis der beiden Skalenmaxima (30/25) —, und jeder Punkt liegt höchstens 3 Punkte vom Trend entfernt. Das ist selbst ein Beleg für T2 — wo die E/E-Architektur steht, steht ungefähr auch die Steuerungsebene. Doch die Trendlinie liegt insgesamt etwa 3 Punkte unter der Paritätsdiagonalen: Normiert auf das jeweilige Skalenmaximum hinken die Steuerungsebenen der Branche ihrer E/E im Allgemeinen um etwa ein Zehntel hinterher. [Inferenz] Das passt zum Koevolutionskreislauf: Seine obere Hälfte (die E/E setzt die Grenze des Möglichen) dreht sich seit Jahren, seine untere Hälfte (Software, die die E/E rückwärts gestaltet) hat sich gerade erst in Bewegung gesetzt. Unter den Herstellern mit einem AR-Wert unter 15 hat nur VW CEA einen VOCM-Wert über 15; Befund 4 erklärt, warum.

Unterhalb des Trendbands liegen die Hersteller, bei denen „die E/E der Steuerungsebene vorauseilt“: am deutlichsten Toyota, mit Rivian am unteren Rand des Bands. [Inferenz] Für Toyota heißt das, dass die Hardwarearchitektur vorangegangen ist, während die Verträge von Arene noch nicht aufgeholt haben — passend zur Beobachtung der OTA-Granularität in 4.3. Rivian ist anders gelagert: Seine E/E gehört zu den aggressivsten der Stichprobe, doch die öffentliche Offenlegung seines Software-Stacks ist am dünnsten; sein niedrigerer Wert spiegelt eher fehlende Belege (niedrige Konfidenz) als fehlende Fähigkeit.

Befund 2: Chinesische Newcomer erzielen bei V4 und V2 durchweg hohe Werte. Li Autos Open-Sourcing von HaloOS, Huaweis markenübergreifendes Ökosystem und Xiaomis „Mensch–Auto–Zuhause“-Ökosystem behandeln Offenheit als Strategie. [Inferenz] Das passt zu Chinas Umfeld aus normengetriebenem Vorgehen und gemeinsamem Lieferkettenaufbau — sind Schnittstellen standardisiert, sinken die Kosten ihrer Öffnung und steigt ihr Nutzen.

Befund 3: Innerhalb derselben AR-Stufe hat Mercedes den höchsten Steuerungsebenen-Wert. Mercedes und BYD liegen in D2 beide bei AR2.5 (17 Punkte), doch MB.OS’ erster VOCM-Wert (20) liegt 3 Punkte über dem von BYD (17) und sitzt am oberen Rand des Trendbands. Das ist vorsichtig zu lesen: D2s AR-Snapshot bewertet den Konzern als Ganzes, während MB.OS zuerst in einem einzigen Modell, dem CLA, landete. [Inferenz] Die wahrscheinlichere Erklärung ist, dass Mercedes die Steuerungsebene zuerst an einem Flaggschiffmodell aufbaut und die E/E-Architektur in späteren Modellen nachziehen lässt — genau so sieht es aus, wenn sich die untere Hälfte des Koevolutionskreislaufs zu drehen beginnt. Stimmt das, zeigen seine Modelle der nächsten Generation einen deutlich höheren AR-Wert; wenn nicht, wurde die Vertragsabdeckung von MB.OS überschätzt (welche sicherheitskritischen Aktoren tatsächlich unter MB.OS liegen, ist öffentlich nicht offengelegt).

Befund 4: Der Volkswagen-Konzern hat die Fahrzeug-OS-Frage mit „ein Hersteller, zwei Architekturen, zwei externe Partner“ beantwortet. Das ist der ungewöhnlichste Punkt der Stichprobe und verdient eine eigene Betrachtung.

• CEA in China: gemeinsam entwickelt von der Volkswagen Group China Technology Company, CARIAD China und XPeng, in nur 18 Monaten vom Konzept zur Serie — laut Unternehmen der schnellste Zeitplan, den der Volkswagen-Konzern je für eine völlig neue Elektronikarchitektur erreicht hat; die Entwicklungskosten neuer Modelle sinken in ausgewählten Schlüsselprojekten um bis zu 50 % [T1, Unternehmensangabe].
• RV Tech im Westen: ein Joint Venture mit Rivian, mit mehr als 1.500 Beschäftigten in den USA, Kanada, Schweden, Serbien und Berlin [T1].

Beide Wege haben eines gemeinsam: Keine der neuen Fahrzeug-Steuerungsebenen des Volkswagen-Konzerns wurde von der konzerneigenen Software-Tochter allein geliefert; beide entstanden gemeinsam mit einem Newcomer, der bei der Steuerungsebene bereits vorne lag.

[Inferenz] Die Bedeutung reicht über Volkswagen hinaus. Sie zeigt, dass sich eine Fahrzeug-Steuerungsebene inzwischen unternehmensübergreifend „importieren“ lässt — nicht durch den Kauf eines Kernels oder einer Middleware, sondern durch die Übernahme einer vollständigen E/E-Topologie, eines Software-Stacks und einer Entwicklungsmethode. Die 18 Monate von CEA sind die Geschwindigkeit, mit der sich die untere Kreislaufhälfte „ausleihen“ und in Drehung versetzen lässt. Die Kosten sind ebenso klar: Ein Konzern muss zwei Architekturen, zwei Partner und zwei Softwarebestände pflegen, die unterschiedlichen Schnittstellenregimen gegenüberstehen (chinesische nationale Normen und das westliche Normenökosystem). Normiert auf das jeweilige Skalenmaximum liegt CEAs erster VOCM-Wert (20/30) deutlich über dem konzernweiten AR-Snapshot (13/25) und ist damit der einzige Punkt in Abbildung 5.1 weit oberhalb des Trendbands. Teils ist das eine Frage des Bezugsrahmens — wie bei Mercedes bewertet AR den Konzern als Ganzes, VOCM dagegen die neueste Architektur; [Inferenz] der Hauptgrund ist aber, dass die Steuerungsebene zusammen mit einer Architektur derselben Linie als Ganzes importiert wurde und so der E/E des Gesamtkonzerns vorausläuft. CEA ist nur eine neue Architektur für China, und der Abstand zwischen ihr und den Bestandsplattformen des Konzerns in Europa ist das, was es eher zu verfolgen gilt. Geht RV Tech in Serie, wird der Volkswagen-Konzern der einzige etablierte Hersteller der Stichprobe mit je einer eigenen Steuerungsebene aus Zonen und Zentralrechner in zwei Märkten sein. Ob das eine Übergangsform ist oder zur Norm für multinationale Hersteller wird, ist die Frage von Abschnitt 7.6.

---

6. Der Belastungstest: Das Cockpit prüft, ob ein OS Apps ausführen kann; Autonomie prüft, ob es das Auto führen kann

6.1 Autonomes Fahren ist kein OS

Das klingt überflüssig, doch die Branche vermengt beides oft — und nennt den Fahrsoftware-Stack eines Unternehmens sein „OS“.

T4 | Autonomes Fahren ist nicht das Fahrzeug-OS. Es ist der anspruchsvollste Workload auf der Steuerungsebene — und der beste Belastungstest dafür, ob ein „Fahrzeug-OS“ diesen Namen verdient.

In einem Satz:

Das Cockpit prüft, ob ein OS Anwendungen ausführen kann; autonomes Fahren prüft, ob ein Fahrzeug-OS das Fahrzeug führen kann.

6.2 Die Leiter der Ausfallfolgen

Warum ist autonomes Fahren der Belastungstest? Weil es die Kosten eines Ausfalls Stufe um Stufe erhöht, bis kein Mensch mehr da ist, der auffangen kann.

Abbildung 6.1 — Autonomie als Belastungstest eines Fahrzeug-OS. Lesehinweis: Von links nach rechts steigen die Kosten eines Ausfalls von „Unannehmlichkeit“ zu „Rückfall auf Fahrzeugebene“, und die Anforderung an die Steuerungsebene steigt von „kann neu starten“ zu „kann nachweisen, dass es bei Teilausfällen weiterhin sicher arbeitet“. Die Stufe zwischen L3 und L4 ist die höchste — dort verlässt der Mensch die Rückfallkette.

Das ist die Wasserscheide, die DD-08, Der Fahrer tritt ab, behandelte: Sobald der Fahrer abtritt, sind redundante Hardware, Safety Case, Laufzeitüberwachung und OTA-Validierung keine Zusätze mehr, sondern die Fähigkeit des Systems selbst. Dieser Beitrag ergänzt DD-08 um eine Perspektive: Alle diese Anforderungen landen letztlich auf der Steuerungsebene. Redundante Recheneinheiten brauchen eine Orchestrierungsschicht, die zwischen ihnen umschalten kann; OTA braucht ein Lebenszyklussystem, das nachweisen kann, „dieses Update bricht den Safety Case nicht“; Laufzeitüberwachung braucht eine deterministische Basis, die den KI-Workload isolieren, beobachten und nötigenfalls übernehmen kann.

[Inferenz] Daher gilt: Bei einem „Fahrzeug-OS“, das noch nie L3- oder höhere Verantwortung getragen hat, ist der fahrzeugweite Charakter noch nicht geprüft. Es mag bei Cockpit, Karosserie und Energie glänzen, doch erst wenn die sicherheitskritische Ausführungskette in dieselbe Steuerungsebene geholt und dem Fail-operational-Test unterzogen wird, trifft das Wort „Fahrzeug“ wirklich zu.

6.3 Die neue Aufgabe des OS: von „Ressourcen verwalten“ zu „Isolation nachweisen“

Die Kernaufgabe eines klassischen Betriebssystems ist die Ressourcenverwaltung: CPU, Speicher und I/O zuteilen. Auf einer automobilen Rechenplattform mit gemischter Kritikalität ändert sich diese Aufgabe grundlegend — das OS muss nachweisen, dass Workloads unterschiedlicher Kritikalität sich nicht gegenseitig stören.

2026 ist das bereits Serienrealität:

• Qualcomm nennt Snapdragon Ride Flex „the industry’s first commercialized mixed-criticality platform“; sie führt QM-, ASIL-B- und ASIL-D-Workloads auf einem einzigen SoC aus und ist in acht globalen Programmen in Serie [T2, Unternehmensangabe].
• NVIDIA Halos OS isoliert sicherheitskritische Funktionen per Hypervisor von KI-Workloads und bietet sicherheitszertifiziertes CUDA und TensorRT [T2].

Technisch bedeutet „Isolation nachweisen“ räumliche, zeitliche und Speicherbandbreiten-Partitionierung im Hypervisor sowie formale oder zertifizierungsfähige Argumente für diese Partitionen. Dass NIO den formal verifizierten Mikrokernel seL4 für seinen Fahrzeugsteuerungs-Kernel nutzt [T3], ist der Versuch, den „Nachweis“ bis in die Mathematik zu treiben.

6.4 Was Ende-zu-Ende-Modelle vom OS verlangen

Die Verbreitung von Ende-zu-Ende-Fahrmodellen und VLA-Modellen (Vision–Language–Action) setzt die Steuerungsebene auf drei neue Arten unter Druck:

1. Konkurrenz um Speicherbandbreite: Inferenz großer Modelle verbraucht viel DDR-Bandbreite und kann Echtzeit-Tasks auf demselben Chip verdrängen.
2. Latenz-Jitter: Die Unsicherheit der GPU-Inferenzzeit kollidiert naturgemäß mit dem Determinismus von Regelkreisen.
3. Verdrängung am Beschleuniger: Wenn Fahrmodell und großes Cockpit-Modell sich Beschleuniger teilen — wer hat Vorrang?

NVIDIAs Halos SDK wirbt ausdrücklich mit „deterministic scheduling, zero-copy inter-process communication“ [T2] — ein Zeichen dafür, dass diese Probleme von Forschungsthemen zu Produktanforderungen geworden sind.

6.5 Cockpit-Fahr-Integration: Isolation wird von der Option zur Vorbedingung

Werden Cockpit- und Fahrfunktionen auf denselben Chip oder denselben Zentralrechner gelegt, gelangen sie in dieselbe Hardware-Fehlerdomäne. In einer verteilten Architektur kann ein Cockpit-Absturz das Bremsen nicht beeinträchtigen, weil beides physisch getrennt ist; in einer integrierten Architektur verschwindet diese „natürliche Isolation“ und muss von der Steuerungsebene in Software neu aufgebaut werden.

[Inferenz] Cockpit-Fahr-Integration macht Isolation von einer „optionalen Optimierung“ zu einer „Sicherheitsvorbedingung“. Deshalb ist die Konsolidierung gemischter Kritikalität (V3) in VOCM eine eigene Dimension.

6.6 Robotaxis: die Zweikanalstruktur

In fahrerlosen L4-Flotten ist [Inferenz: Waymo, Baidu Apollo, Pony.ai, WeRide und andere legen die Umsetzung ihrer Software-Stacks nur begrenzt offen] eine verbreitete Struktur „KI-Hauptstack + unabhängige Sicherheitsüberwachung und redundante Rechner“ — der Hauptstack fährt, ein zweiter Kanal überwacht ihn fortlaufend und bringt das Fahrzeug bei Anomalien in einen risikominimalen Zustand. Diese Zweikanalstruktur ist der Fail-operational-Vertrag in Softwareform und die extremste Gestalt der Orchestrierungsaufgabe der Steuerungsebene.

---

7. Horizontale Plattformen vor der Tür: Google, die Chiphersteller und der Kampf um Schnittstellen

7.1 Ein neues Schlachtfeld

Im Smartphone-Zeitalter haben Apple und Google das Betriebssystem vereinnahmt, und die Gerätehersteller zogen sich auf Hardware und Marke zurück. Der Konsens der Automobilbranche in den vergangenen zehn Jahren lautete: Hersteller werden nie zulassen, dass sich das im Auto wiederholt.

2026 steht dieser Konsens erstmals vor einer substanziellen Herausforderung.

T6 | Was die Branche tatsächlich standardisiert, ist nicht „ein Automobil-OS“, sondern die Fahrzeug-API, das Datenmodell und der Laufzeitvertrag. Kernel werden zur Massenware, und der Kontrollpunkt C3 (OS) wird von beiden Seiten durch C2 (Silizium) und C4 (Middleware) in die Zange genommen.

7.2 Google: Android verlässt das Cockpit

Am 24. März 2026 veröffentlichte Google im Android Developers Blog die SDV-Erweiterung von Android Automotive OS (AAOS SDV) unter einem unverblümten Titel: Beyond Infotainment [T2]. Die geprüften Fakten:

• Form: eine „lightweight, fast-booting headless Android foundation (SDV Core, similar to Microdroid)“, die als virtuelle Maschine auf einem VirtIO-fähigen Hypervisor läuft; Serviceschnittstellen werden in Googles VSIDL plus Protobuf definiert und verbinden sich über SOME/IP, VirtIO-Sockets, Ethernet u. a. mit externen Steuergeräten; auf der Cockpitseite sitzt ein SDV Gateway [T1: source.android.com, Dokumentation zuletzt aktualisiert am 24.09.2026, für Android 17 und höher].
• Abgedeckte Domänen: Google nennt „Core Compute, Body Controls, and Cluster domains“, mit Beispielfunktionen wie Sitzaktoren, Kombiinstrument, Klimaregelung, Beleuchtung, Kameras, Spiegel und Telemetrie [T2]. Die offiziellen Unterlagen erwähnen weder Fahrwerk noch ADAS.
• Sicherheitsgrenze: Weder Dokumentation noch Blog erheben irgendeinen ASIL-Anspruch. Der einzige sicherheitsbezogene Inhalt ist Display Safety (Anzeigen im Kombiinstrument wie Geschwindigkeit und Kontrollleuchten) sowie eine Toolchain für Sicherheitsdesign und ein Referenz-Safety-Monitor [T1–T2].
• Anwender: Qualcomm kündigte auf der CES 2026 einen vorintegrierten AAOS-SDV-Stack auf Snapdragon Digital Chassis an; das erste Serienprogramm ist ein leichtes Nutzfahrzeug von Renault, Serienstart Ende 2026 [T2]. Laut Google kommt AAOS SDV noch 2026 in AOSP.

[Inferenz] Diese Fakten ziehen eine klare Grenzlinie: Die horizontale Plattform hat das Cockpit überschritten und ist in die Domänen Karosseriekomfort und Kombiinstrument vorgedrungen, bleibt aber im Bereich QM bis niedriges ASIL und hat die sicherheitskritischen Ausführungsketten von Fahrwerk, Bremse, Lenkung und automatisiertem Fahren noch nicht berührt. Ob diese Linie weiter nach unten wandert, gehört zu den wichtigsten Branchensignalen der nächsten fünf Jahre (Kapitel 10, Revisionsauslöser 4).

7.3 Die Chiphersteller: C2 absorbiert C3

Drückt Google von oben nach unten, so umhüllen die Chiphersteller von unten nach oben.

• NVIDIA: DriveOS (ASIL-D-zertifiziert) + Halos OS (Hypervisor, der KI-Workloads von Sicherheitsfunktionen isoliert) + Halos SDK (deterministisches Scheduling, Zero-Copy-IPC) [T2]. GMs zentrale Rechenplattform 2028 basiert auf NVIDIA Thor [T1].
• Qualcomm: die Plattform Ride Flex für gemischte Kritikalität + ein vorintegrierter AAOS-SDV-Stack [T2].

[Inferenz] Was Chiphersteller liefern, ist kein Chip mehr, sondern ein Paket aus „Chip + Hypervisor + sicherheitszertifizierte Laufzeitumgebung + Teil der Middleware“. Für einen Hersteller bedeutet die Wahl eines Chips zunehmend, zugleich S1 und S2 — sogar Teile von S3 — zu wählen. Unter D1s sieben Kontrollpunkten heißt das: C2 (SoC) absorbiert C3 (OS).

7.4 Middleware und „Vehicle-OS-Anbieter“: C4 expandiert

Eine weitere Kraft kommt von Middleware und Drittanbietern von Vehicle OS.

• Applied Intuition liefert Herstellern ein Vehicle OS. Im Mai 2026 kündigte Stellantis eine ausgeweitete Zusammenarbeit bei STLA Brain an [T1]; das Unternehmen gibt an, dass 18 der 20 größten Autohersteller der Welt seine Lösungen nutzen [T2, Unternehmensangabe].
• Eclipse S-CORE: Im Juni 2025 unterzeichneten 11 Unternehmen das VDA-Memorandum zur Open-Source-Zusammenarbeit im SDV-Bereich (BMW, Continental, ETAS, HELLA, Mercedes-Benz, Qorix, Bosch, Valeo, Vector, Porsche, ZF) [T1]; laut VDA-Pressemitteilung vom 7. Januar 2026 stieg die Zahl der Unterzeichner auf 32 [T1–T2]. S-CORE 0.5 erschien im November 2025; die Referenzplattform wurde zuerst auf QNX- und Qualcomm-Hardware demonstriert [T2].

[Inferenz] Wenn ein europäischer Hersteller Open-Source-S-CORE für S2, QNX für S1 und den Hypervisor des Chipherstellers für die Isolation nutzt und ein Drittanbieter-Vehicle-OS für einen Teil von S4 kauft — was besitzt er dann eigentlich noch? Die Antwort: Fahrzeugsemantik, Sicherheitsverantwortung und die Fähigkeit, zu integrieren, zu validieren und den Datenkreislauf zu betreiben.

7.5 Gekämpft wird um Schnittstellen, nicht um Kernel

Fügt man die drei Kräfte zusammen, tritt eine unterschätzte Tatsache hervor: Worum alle Seiten wirklich kämpfen — und was wirklich standardisiert wird —, ist die Schnittstellenschicht.

[Inferenz] Zusammen weisen diese Bemühungen auf einen Schluss: Was auf Standardisierung zusteuert, ist nicht „ein Automobil-OS“, sondern „Fahrzeug-API + Datenmodell + Laufzeitvertrag“. Das entspricht genau dem ersten der drei Teile der Steuerungsebene aus Abschnitt 2.3 — dem Vertrag.

Daraus folgt eine Folgerung darüber, wo der Wert liegt:

Die Vertragsschicht konvergiert; Orchestrierung und Lebenszyklus sind der verbleibende Raum für Differenzierung der Hersteller.

7.6 Horizontale Plattform vs. OEM-Steuerungsebene: Wie sieht das Endspiel aus?

Konvergiert die Branche also auf ein horizontales Fahrzeug-OS, oder behalten die Hersteller die Fahrzeug-Steuerungsebene?

[Inferenz] Unser Urteil: Es ist kein Entweder-oder. Die Infrastruktur unten (S1, S2 und Normen der Vertragsschicht) wird weiter konvergieren; Fahrzeugsemantik, Zuständigkeit für Sicherheitsverantwortung und Markendifferenzierung (Orchestrierung, Lebenszyklus, Datenkreislauf) werden weiter divergieren. Das ist das zweite Wiederauftreten von D1s zweischichtigem Konvergenz-Divergenz-Modell auf der Softwareebene.

Vier Arten von Herstellern werden vier verschiedene Endspiele erreichen:

1. Vertikale Integratoren (Tesla, Huawei, NIO): besitzen C2, C3 und C4 zusammen; die Steuerungsebene gehört ganz ihnen. Sie sind das stärkste Gegenbeispiel zu T6 — für sie ist das OS nichts, was zur Massenware wird, sondern Teil des Burggrabens.
2. Föderierte Steuerungsebenen: mehrere Steuerungsebenen, gebaut nach Region oder sogar nach Partner, mit gemeinsamer Marke, Lieferkette und teilweise gemeinsamer Basis, aber ohne einen einzigen globalen Software-Stack anzustreben. Der Volkswagen-Konzern ist heute das klarste Beispiel: CEA gemeinsam mit XPeng in China, RV Tech gemeinsam mit Rivian im Westen (siehe Befund 4 in 5.5). Die Vorteile sind Geschwindigkeit und lokale Passung — 18 Monate bis zur Serie, direkte Ausrichtung auf chinesische nationale Normen und das lokale Fahrökosystem. Das Risiko ist die Aufspaltung der Skaleneffekte: zwei Architekturen bedeuten zwei Validierungsregime, zwei OTA-Betriebe, zwei Talentpipelines und langfristige Integrationskosten. [Inferenz] Das Endspiel des Fahrzeug-OS muss nicht „one kernel to rule them all“ sein; eine föderierte Steuerungsebene kann für multinationale Hersteller angesichts divergierender Normen in China und im Westen die rationale Wahl sein — doch ob die Föderation in der nächsten Generation zu einer zusammenwachsen kann, entscheidet, ob dieser Weg am Ende ein „Übergang“ oder eine „Belastung“ ist.
3. Plattformkonsumenten: kaufen selbst bei S4 Drittlösungen ein (Applied Intuition, Google, Pakete der Chiphersteller) und konzentrieren die Differenzierung auf Marke, Design und Vertrieb.
4. Exporteure der Steuerungsebene: exportieren ihre eigene Fahrzeug-Steuerungsebene — zusammen mit E/E-Topologie und Entwicklungsmethode — als Produkt an andere Hersteller. Das ist die jüngste Form, entstanden 2025–2026, und ihre Protagonisten sind fast ausnahmslos chinesische Hersteller:
   • XPeng hat CEA gemeinsam mit Volkswagen gebaut (5.5);
   • auf seinem Tech Day 2026 gab Leapmotor an, dass seine Elektroniksysteme inzwischen mit fünf Partnern zusammenarbeiten und dass es FAW, Stellantis und anderen Technologie auf Fahrzeugebene bereitstellt [T3];
   • Huaweis HarmonyOS-Cockpit und Qiankun decken 25 Marken ab [T2].

[Inferenz] Die vierte Form verändert das Bild, das T6 zeichnet. Der Kontrollpunkt C3 wird nicht nur von oben und unten durch Chiphersteller (C2) und Middleware / horizontale Plattformen (C4) in die Zange genommen; er wird auch seitlich von einer anderen Art von Hersteller umkämpft. Für den Importeur ist die Übernahme einer Steuerungsebene viel schneller als der Eigenbau: CEA ging in 18 Monaten vom Konzept zur Serie. Für den Exporteur wird die Steuerungsebene zur zweiten Erlöskurve und zum Verstärker von Skaleneffekten — Leapmotors angegebene Plattformgleichteilquote von 90 % ist genau das, was eine Steuerungsebene exportfähig macht [T3, Unternehmensangabe]. Dass Stellantis sowohl mit Applied Intuition (Drittanbieter-Vehicle-OS) als auch mit Leapmotor (Technologie auf Fahrzeugebene) zusammenarbeitet, zeigt, dass ein Hersteller in verschiedenen Märkten und Modellen zugleich „Plattformkonsument“ und „Importeur der Steuerungsebene“ sein kann.

Keine der vier Formen ist überlegen; jede ist eine andere Wette darauf, wo der Kontrollpunkt sitzen soll.

---

8. Wenn KI in das Betriebssystem eintritt: die Sanduhr und deterministische Steuerung

8.1 Ein großes Modell im Auto heißt noch nicht, dass KI ins OS eingetreten ist

Die verbreitetste — und flachste — Diskussion über „KI und Fahrzeug-OS“ dreht sich darum, welches große Modell im Auto sitzt: Gemini, GPT, DeepSeek, Pangu oder Grok. Das ist KI als Anwendung. Die eigentliche Veränderung geschieht tiefer und verläuft in drei Stufen.

Stufe B birgt eine leicht übersehene, aber weitreichende Folgerung: Das Modell wird zum erstklassigen Software-Artefakt. Heute liefert ein OTA-Update „Softwarepaket v3.7“; morgen liefert es ein Bündel aus „Software + Modell + Richtlinie + Agentengraph + Sicherheitshülle“. Der Gegenstand der Lebenszyklusverwaltung erweitert sich von Code auf probabilistische Erzeugnisse.

Die Branche bewegt sich bereits auf Stufe B zu:

• Mercedes’ MBUX Virtual Assistant integriert KI von Microsoft und Google und baut auf Gemini einen automobilen KI-Agenten [T2].
• Hyundais KI-Agent Gleo AI kommt mit Pleos Connect; Hyundai beschreibt den Wandel als Schritt vom SDV zum „AIDV“ (KI-definiertes Fahrzeug) [T2].
• NIO nennt SkyOS ein „Full-Domain-Fahrzeugbetriebssystem für KI“ [T2].
• Auf seinem Tech Day 2026 stellte Leapmotor ein „Fahrzeug-Cloud-AgentOS“ vor: Kernagenten im Fahrzeug übernehmen latenzarme und datenschutzsensible Aufgaben; Cloud-Agenten übernehmen komplexes Schlussfolgern und Langzeitgedächtnis [T3]. [Inferenz] Das ist eine Auslegung, die „Intelligenz nach Vertrauen und Latenz aufteilt“ — und sie bildet sich sauber auf den äußeren Ring der Steuerungsebene ab (Cloud, OTA, Datenkreislauf): Der Agent selbst wird in einen „deterministischen Teil im Auto“ und einen „erweiterten Teil in der Cloud“ geteilt.
• Im Oktober 2025 veröffentlichte Chinas Ökosystem-Komitee für automobile Basissoftware (AUTOSEMO) seinen China Automotive Basic Software Development Report 6.0, mit Fokus auf AIOS und einer vorgeschlagenen Architektur aus „Rechenabstraktion — Datenfusion — Funktionsservitisierung“ [T2].

8.2 Wird das OS dünner oder dicker?

Wird KI das Betriebssystem absorbieren? Beide Sichtweisen haben etwas für sich.

Die Seite des Ausdünnens: Interaktion, Anwendungsorchestrierung und Funktionslogik werden von großen Modellen und Agenten absorbiert. HMI-Abläufe, Menühierarchien und Regel-Engines, die früher fest codiert werden mussten, werden durch ein Modell ersetzt, das Absichten versteht. Ende-zu-Ende-Fahrmodelle haben auch Middleware absorbiert, die früher in getrennte Module für Wahrnehmung, Prädiktion und Planung zerfiel. So gesehen wird die obere Hälfte des OS dünner.

Die Seite des Verdickens: Je unsicherer das Modell, desto mehr braucht es ein deterministisches Gerüst. Ressourcenisolation, zeitlicher Determinismus, Sicherheitsüberwachung, nachweisbare Rückfallpfade und die von ISO/PAS 8800 geforderte Belegkette über den KI-Lebenszyklus müssen alle in die OS-Schicht absinken. NVIDIA macht „einen Hypervisor, der sicherheitskritische Funktionen von KI-Workloads isoliert“ zum zentralen Verkaufsargument von Halos OS [T2]. So gesehen wird die untere Hälfte des OS dicker.

Unsere Antwort: Beides geschieht gleichzeitig.

T5 | KI wird das Fahrzeug-OS nicht abschaffen; sie wird es polarisieren: Die obere Hälfte (Interaktion, Orchestrierung) wird dünner, die untere Hälfte (Determinismus, Isolation, Nachweis) dicker, und der Servicevertrag dazwischen wird zur schmalen Taille. Probabilistische Intelligenz muss innerhalb deterministischer Steuerung laufen.

Abbildung 8.1 — Die Sanduhr: wie KI das Fahrzeug-OS umformt. Die breite Oberseite: Interaktion, Orchestrierung und Funktionslogik, absorbiert von Modellen. Die schmale Taille: der Servicevertrag der Steuerungsebene. Die breite Basis: die sich verdickende deterministische Schicht (Isolation, Scheduling, Sicherheitsüberwachung, Rückfall, Belegkette). Rechts ist zu sehen, wie sich das Software-Artefakt entwickelt: „Code“ → „Code + Modell + Richtlinie + Agentengraph + Sicherheitshülle“.

Das steht vollständig im Einklang mit dem Urteil aus D3, dass „KI ein Sprachvermögen ist, kein Gehirn“: Das Sprachvermögen wandert nach oben ins Modell; der sicherheitsrelevante „Hirnstamm“ — das deterministische Gerüst — bleibt im OS. Beides widerspricht sich nicht; es sind zwei Seiten derselben Sache.

8.3 Eine falsifizierbare Vorhersage

„Polarisierung“ lässt sich leicht als Absicherung kritisieren, nach der „beide Seiten recht haben“. Um das zu vermeiden, geben wir eine klare Vorhersage ab, die Fakten widerlegen könnten:

[Inferenz] Vor 2030 wird es kein Serien-Pkw geben, in dem ein großes Sprachmodell oder ein Allzweckagent direkt die Kontrolle über ASIL-D-Aktoren erhält. Agenten dürfen vorschlagen, anfragen und autorisierte Fahrzeugdienste aufrufen, doch die letztliche Kontrolle über sicherheitskritische Aktoren wie Bremse und Lenkung wird weiterhin von der deterministischen Steuerungsebene entschieden.

Wird diese Vorhersage widerlegt, muss T5 revidiert werden (Kapitel 10, Revisionsauslöser 3).

8.4 Normen und Regulierung: Die Grenzen für KI im OS haben Gestalt angenommen

Ob KI in das Fahrzeug-OS eintritt, entscheidet nicht die Technik allein. Das Regelwerk, das sie begrenzt, hat bereits Gestalt angenommen:

• ISO 26262 (funktionale Sicherheit) und ISO 21448 (SOTIF, Sicherheit der Sollfunktion) [T1].
• ISO/PAS 8800:2024 (Straßenfahrzeuge — Sicherheit und künstliche Intelligenz), veröffentlicht im Dezember 2024, passt einschlägige Klauseln von ISO 26262 Teil 4, 6 und 8 an [T1]. Im August 2025 erteilte SGS-TÜV Saar Geely die weltweit erste Prozesszertifizierung nach ISO/PAS 8800 [T2].
• UN R155 / R156 (Cybersecurity-Managementsystem / Software-Update-Managementsystem) sowie Chinas entsprechende Pflichtnormen GB 44495 / 44496 / 44497, in Kraft seit dem 1. Januar 2026 [T1].

[Inferenz] Die gemeinsame Wirkung dieser Normen: Je mehr KI, desto schwerer wird die Lebenszyklusverwaltung. Jedes Modellupdate kann einen aktualisierten Safety Case erfordern; jeder Agent mit Rechten für Fahrzeugaktionen braucht ein prüfbares Berechtigungsmodell. Diese Lasten kann das Modell nicht selbst tragen; tragen kann sie nur die Steuerungsebene.

Eine Frage bleibt offen: Wie gelangt KI-generierter OS-Code in ein Sicherheitsargument nach ISO 26262? D4 hat bereits gezeigt, dass sich in Architektur-Werkzeugketten die Fähigkeit zur „KI-Generierung“ von der „Schlussfolgerungsautonomie“ entkoppelt hat. Auf Ebene des Fahrzeug-OS haben wir bis zum Datenstand dieses Beitrags keinen öffentlichen Serienfall gefunden, in dem KI-generierter Code in ein ASIL-Argument eingegangen ist. Das ist eine Lücke, die es zu beobachten gilt.

---

9. Roadmap 2026–2035: von softwaredefiniert zu KI-definiert

9.1 Fünf Stufen

Die Tabelle unterscheidet beobachtete Zustände von Forschungshypothesen. Die ersten drei Stufen sind beobachtet; die letzten beiden sind Hypothesen.

Hinweis: Stufe V teilt ihren Namen mit L8 „AI-Defined Vehicle“ in der achtstufigen EEA-Evolutionstaxonomie dieser Reihe, doch beide beschreiben unterschiedliche Gegenstände: Die achtstufige Taxonomie beschreibt die Form der Fahrzeug-EEA; diese Tabelle beschreibt die Form der Software-Steuerungsebene. Die beiden Dimensionen sind orthogonal und dürfen nicht vermischt werden.

9.2 Was die Stufen III, IV und V tatsächlich trennt

Die letzten drei Stufen werden am leichtesten verwechselt. In einem Satz: Stufe III macht Funktionen zu Software, Stufe IV macht Software zu planbaren Ressourcen, und Stufe V lässt Modelle mitentscheiden, was geplant wird.

Die Entwicklung des Rechenzentrums bietet eine fertige Analogie:

• Stufe III gleicht der Ära der virtuellen Maschinen: Server sind virtualisiert, aber was jede VM ausführt und wo sie sitzt, legt der Betrieb vorab fest.
• Stufe IV gleicht der Kubernetes-Ära: Workloads werden in Standardeinheiten verpackt und von einem Scheduler nach Regeln in einen Ressourcenpool gelegt; sie können migrieren, skalieren und ersetzt werden.
• Stufe V gleicht der KI-nativen Ära: Über dem Scheduler sitzt eine Schicht von Modellen, die Absichten verstehen, sodass das System spontan Abläufe zusammensetzen kann, die niemand vorab geschrieben hat.

Jedes der sechs Merkmale von Stufe IV hat eine konkrete Gestalt:

1. Dynamische Funktionsplatzierung. Fällt die Hauptrecheneinheit aus, migriert der Orchestrator nicht sicherheitskritische Funktionen auf eine Ersatzeinheit; oder dieselbe Funktion wird je nach Fahrzeugkonfiguration auf unterschiedliche Knoten verteilt.
   • Eine Grenze muss betont werden: ASIL-D-Funktionen werden auf absehbare Zeit nicht „dynamisch“ geplant. Ihre Migrationspfade sind vorab entworfene und zertifizierte Redundanzumschaltungen. Wirklich dynamisch sind vor allem QM- und Workloads mit niedrigem ASIL.
2. Geteilte Rechenleistung. Wenn das Auto parkt, liegt der Großteil der Rechenleistung des Fahrchips brach. Eine Plattform der Stufe IV kann sie an das große Cockpit-Modell, an die Bildanalyse im Wächtermodus oder an die Datenvorverarbeitung an Bord verleihen und sie nach Priorität zurückholen, sobald das Auto fährt. Stufe III kann das nicht, weil Cockpit und Fahren zu zwei Domänen mit zwei Software-Stacks gehören.
3. Domänenübergreifende Dienste. In Stufe III ist ein „Campingmodus“ eine eigens gebaute Funktion, die Änderungen am Code von Klimaanlage, Anzeige, Batteriemanagement und Türschloss erfordert. In Stufe IV ist er schlicht eine Zusammensetzung vorhandener Dienste. Die „Szenen-Orchestrierung“ chinesischer Hersteller geht bereits in diese Richtung, bleibt aber meist auf Cockpit-Ebene und reicht noch nicht tief in die Fahrzeugsteuerung [Inferenz].
4. Entwicklungsparität zwischen Cloud und Fahrzeug. Derselbe Software-Container durchläuft die Regression an einem virtuellen Fahrzeug in der Cloud, bevor er auf ein reales ausgerollt wird. Googles AAOS-SDV-Dokumentation hält ausdrücklich fest, dass der Betrieb in einer virtuellen Maschine „facilitates testing and integration in the cloud“ [T1].
5. Konsolidierung gemischter Kritikalität als Norm. Heute lässt Ride Flex ASIL-D- und QM-Workloads in acht Serienprogrammen einen Chip teilen [T2] — noch eine „erste Welle“; in Stufe IV wird das zur Standardkonfiguration neuer Plattformen statt zum Verkaufsargument.
6. Standardisierter Modell-Lebenszyklus. Versionierung, Validierung und Rollback von Fahrmodellen wandern von den eigenen Werkzeugen jedes Unternehmens in dieselbe Pipeline wie Software, begrenzt durch ISO/PAS 8800 und R156. Leapmotors „ein Modell über drei Rechenstufen“ [T3] ist ein frühes Beispiel für Deployment-Entscheidungen nach Hardwarestufe.

Die Grenze zwischen Stufe IV und V liegt darin, wer die Regeln schreibt. Wie klug der Orchestrator der Stufe IV auch sein mag, er führt Regeln aus, die Ingenieure geschrieben haben. In Stufe V beginnen Modelle und Agenten, an der Entscheidung mitzuwirken. Ein Vergleich:

• Stufe IV: Der Nutzer sagt „Campingmodus einschalten“, und das System führt eine vorgefertigte Dienstkombination aus.
• Stufe V: Der Nutzer sagt „Ich übernachte heute in den Bergen und muss morgen früh in die Stadt zurückfahren.“ Der Agent gleicht die Restladung mit der Rückfahrstrecke ab, berechnet, wie viel Energie die Klimaanlage verbrauchen darf, setzt eine Batteriereserve-Untergrenze, dimmt die Bildschirme und sucht Ladestationen entlang der morgigen Route. Diese Kombination hat nie ein Ingenieur geschrieben; sie entsteht spontan innerhalb des Berechtigungsmodells und der Sicherheitshülle.

Leapmotors AgentOS, Hyundais Gleo AI und Mercedes’ Gemini-basierter Agent stehen alle noch auf der in Kapitel 8 beschriebenen Stufe „KI wird zum OS-Dienst“: Sie verstehen Absichten, doch das Spektrum der Fahrzeugdienste, die sie aufrufen können, und ihre Berechtigungen bleiben begrenzt.

Woran erkennen wir, dass die Branche in Stufe IV eingetreten ist? Achten Sie auf vier beobachtbare Signale:

1. Serienfahrzeuge mit Funktionen, die ohne neue Softwareversion zwischen Recheneinheiten migrieren;
2. derselbe Software-Container, in der Cloud validiert, auf mehreren Hardwarestufen ausgerollt;
3. neue Plattformen, die standardmäßig einen SoC zwischen ASIL-D- und QM-Workloads teilen;
4. Modellupdates, die in eine einheitliche, regulierte Pipeline mit Rollback eingehen.

Die Signale der Stufe V sind Serienfahrzeuge mit Agenten, die Fahrzeugdienste über ein Berechtigungsmodell aufrufen, und Funktionskombinationen, die nicht vorab codiert, sondern aus der Nutzerabsicht erzeugt wurden.

[Inferenz] Die Grenzen zwischen den drei Stufen sind unscharf; derselbe Hersteller steht oft mit einem Bein in zwei Stufen. Die Tabelle beschreibt eine Verlagerung des Schwerpunkts, keinen sauberen Schnitt.

9.3 Die Wanderung der Kontrollpunkte

[Inferenz] Von heute bis 2030 werden sich die drei für diesen Beitrag relevanten von D1s sieben Kontrollpunkten wie folgt verändern:

• C2 (SoC): absorbiert weiter nach oben und liefert den kompletten Stack aus „Chip + Hypervisor + zertifizierte Laufzeitumgebung + Teil der Middleware“.
• C3 (OS): Kernel und Basis-Laufzeitumgebungen werden zur Massenware; der eigenständige Wert verlagert sich auf Orchestrierung und Lebenszyklus der Steuerungsebene.
• C4 (Middleware): Open Source (S-CORE, HaloOS) und Normen (VSS, chinesische nationale Normen) beschleunigen die Konvergenz; die Vertragsschicht wird allmählich zum Gemeingut.

Abbildung 9.1 — C3 in der Zange: wohin der Wert des Fahrzeug-OS wandert. Lesehinweis: C3 wird von Kräften von oben und unten zusammengedrückt; was dem Hersteller bleibt, sind Orchestrierung, Lebenszyklus und der Datenkreislauf (C5).

9.4 Chinas Weg: Eigenentwicklung, Open Source und nationale Normen parallel

Chinas Entwicklung des Fahrzeug-OS hat eine eigentümliche Struktur: Eigenentwicklung, Open Source und nationale Normen schreiten parallel voran und verstärken sich gegenseitig.

• Eigenentwicklung: NIO SkyOS, Huaweis HarmonyOS-Cockpit und Qiankun, XPeng, Xiaomi und andere bauen eigene Software-Stacks [T2].
• Open Source: Li Auto stellte HaloOS unter Apache 2.0 bereit (2025) und machte Eigenentwicklung zum Gemeingut der Branche [T2].
• Nationale Normen: GB/T 47351 / 47341-2026 traten am 1. Juli 2026 in Kraft; die drei Pflichtnormen GB 44495 / 44496 / 44497 am 1. Januar 2026, harmonisiert mit UN R155 / R156 [T1].

[Inferenz] Eine wichtige Folge der nationalen Normen: Sie werden zu einer Schnittstelle, an der sich jeder in China verkaufende Hersteller — ausländische eingeschlossen — ausrichten muss. Dass Mercedes-Benz China und Volkswagen China unter den beteiligten Organisationen erscheinen, zeigt, dass ausländische Hersteller dies erkannt haben. Es könnte auch ein struktureller Grund sein, warum weltweit „föderierte Steuerungsebenen“ entstehen: Derselbe Hersteller muss womöglich Software-Stacks pflegen, die in China und anderswo unterschiedlichen Schnittstellenregimen gegenüberstehen.

9.5 Ökonomie und Organisation: der eigentliche Engpass

Ökonomisch zahlt sich ein Fahrzeug-OS auf vier Wegen aus: geringere Materialkosten für Steuergeräte und Verkabelung, Wiederverwendung von Software über Modelle hinweg, Amortisation der Plattformkosten und Softwareerlöse nach dem Verkauf des Autos. Dass Rivians Bruttogewinn aus Software und Services im Geschäftsjahr 2025 von 7 Mio. USD auf 576 Mio. USD sprang [T1], zeigt, dass der Wert von „E/E + OS“ als Vermögenswert bereits in Finanzberichten erscheinen kann.

Organisatorisch werden seine Kosten oft unterschätzt. Abschnitt 5.1 stellte fest, dass fast jeder Hersteller der Roadmap-Stufe (M4) in Verzug geraten ist. [Inferenz] Die Ursache ist selten die Technik und meist die Organisation:

• Dutzende funktionsbasierte Abteilungen in eine Plattformorganisation umbauen;
• Tier-1-Verträge von der Einheit „Blackbox-Steuergerät“ auf die Einheit „Softwaremodul + Integrationsverantwortung“ umstellen;
• die Plattform der nächsten Generation bauen, während die aktuellen Modelle weiter ausgeliefert werden.

Das ist Conways Gesetz, angewandt auf das Fahrzeug-OS: Ihre Steuerungsebene wird aussehen wie Ihre Organisation. Ein Hersteller, der noch in die Abteilungen „Karosserie, Fahrwerk, Antrieb und Cockpit“ gegliedert ist, wird sich schwertun, eine Steuerungsebene über alle vier Domänen zu bauen.

Dieses Kapitel in einem Satz:

Zentralisierung beseitigt lokale Komplexität, indem sie Systemkomplexität erzeugt. Sie beseitigt die Zersplitterung zwischen 100 Steuergeräten, bringt aber einen größeren Explosionsradius, eine konzentriertere Angriffsfläche, komplexere Validierung — und eine Organisation, die sich erst selbst umbauen muss, bevor sie das Auto umbauen kann.

---

10. Das Messer an die eigene Kehle: Gegenargumente und Revisionsauslöser

10.1 Sieben Gegenargumente

Gegenargument 1: Das Fahrzeug-OS ist nur ein Marketingkonzept. Ohne die Markenschicht bleibt QNX + Linux + AUTOSAR + ein Hypervisor. Antwort: Genau hier setzt T1 an. Wir behaupten nicht, das Fahrzeug-OS sei ein neuer Kernel; wir behaupten, es sei die Steuerungsebene, die mehrere Kernel regiert. Die Marke ist tatsächlich überzeichnet, aber ihre drei Teile — Vertrag, Orchestrierung und Lebenszyklus — sind real, beobachtbar und bewertbar.

Gegenargument 2: Zentralrechner zahlen sich womöglich nicht aus. Der Overhead aus Virtualisierung, Redundanz und Flüssigkeitskühlung könnte die Einsparungen durch weniger Steuergeräte aufzehren. Antwort: Wir ziehen hier keine Schlussfolgerung. Die Wirtschaftlichkeit hängt von Stückzahlen und Softwareerlösen ab, und die öffentlichen Daten reichen für ein Urteil nicht aus. Wir halten nur fest, dass „Zentralisierung lokale Komplexität gegen Systemkomplexität tauscht“ — ob sich der Tausch lohnt, hängt vom Hersteller ab.

Gegenargument 3: Ein Fahrzeug-OS erhöht in Wahrheit das systemische Risiko. Antwort: Zugestimmt. Genau das argumentiert Kapitel 6: Zentralisierung macht Isolation von einer natürlichen Eigenschaft zu einer, die nachgewiesen werden muss. Ob das Risiko beherrscht wird, hängt davon ab, wie gut V3 (gemischte Kritikalität) umgesetzt ist.

Gegenargument 4: Standardisierte APIs werden die Differenzierung der Hersteller auslöschen. Antwort: Die Differenzierung auf der Vertragsschicht wird tatsächlich schrumpfen (T6), doch Orchestrierung, Lebenszyklus und Datenkreislauf bleiben Räume der Differenzierung. Differenzierung verschwindet nicht; sie wandert.

Gegenargument 5: KI-Agenten sollten niemals in den sicherheitskritischen Steuerungspfad gelangen. Antwort: Unsere Position ist spezifischer: Agenten dürfen in die Steuerungsebene, aber nur unter deterministischer Steuerung; die letztliche Kontrolle über ASIL-D-Aktoren wird ihnen auf absehbare Zeit nicht übergeben (die Vorhersage in 8.3).

Gegenargument 6: Regionalisierte Software-Stacks werden ein globales Fahrzeug-OS verhindern. Antwort: Zugestimmt — und das ist womöglich kein Problem, sondern das Endspiel. Die in 7.6 behandelte „föderierte Steuerungsebene“ entfaltet genau dieses Urteil.

Gegenargument 7: L4 wird letztlich ein eigenes OS brauchen, nicht einen Teil des Fahrzeug-OS. Antwort: Das ist eine offene Frage. Die Zweikanalstruktur (6.6) könnte bedeuten, dass der L4-Sicherheitsüberwachungskanal logisch unabhängig von der Fahrzeug-Steuerungsebene ist. Setzen L4-Flotten verbreitet Software-Stacks ein, die vollständig vom Pkw-Fahrzeug-OS getrennt sind, sollte T4 umformuliert werden zu „autonomes Fahren prüft den Vertrag zwischen Fahrzeug-OS und Sicherheitskanal“.

10.2 Fünf Revisionsauslöser

Tritt einer der folgenden Fälle ein, muss die entsprechende These revidiert werden:

---

11. Fazit: drei Urteile und eine Warnung

Zurück zum Titel. „Ein System von Betriebssystemen“ ist keine Redefigur — es ist die genaueste Beschreibung jener Schicht in jedem softwaredefinierten Auto. Sie wurde mit so vielen „OS“-Namen belegt, dass niemand innehielt, um zu fragen, was sie eigentlich ist.

Unsere Antwort: Es ist eine Steuerungsebene aus Vertrag, Orchestrierung und Lebenszyklus, die eine Menge von Betriebssystemen regiert — nicht ein einzelnes Betriebssystem selbst.

Urteil 1: Das Fahrzeug-OS ist ein System von Betriebssystemen, und seine Grenze zieht die E/E-Architektur. Was OS heißt, muss kein Fahrzeug-OS sein, und was nicht so heißt, kann eines sein. Der Test ist nicht der Markenname, sondern welche Domänen der Vertrag abdeckt, ob die Orchestrierung Isolation nachweisen kann und welche Schichten der Lebenszyklus aktualisieren kann. Wie weit diese drei reichen können, hängt zuerst davon ab, welche Generation die E/E-Architektur erreicht hat.

Urteil 2: Die eigentliche Wasserscheide ist die Umkehr der Kausalität. Das Kennzeichen eines Herstellers, der in die softwaredefinierte Ära eintritt, ist nicht, ob er eine OS-Marke hat, sondern ob sich die untere Hälfte des Koevolutionskreislaufs zu drehen begonnen hat — ob seine nächste E/E-Spezifikation von den Bedürfnissen der Software der aktuellen Generation definiert wird. GMs „10× / 1.000× / 35ד, der Streit zwischen BMW und GM darüber, wie weit Zonensteuergeräte verdummt werden sollen, und Rivians Verkauf von „E/E + OS“ als Ganzes sind alles Zeichen dafür, dass der Kreislauf sich zu drehen begonnen hat.

Urteil 3: KI macht das Betriebssystem wichtiger, nicht unwichtiger. KI wird die obere Hälfte des OS absorbieren, aber seine untere Hälfte dicker machen. Je mehr Wahrscheinlichkeit, desto kostbarer wird Determinismus. Autonomes Fahren ist der Belastungstest dafür: Das Cockpit prüft nur, ob ein OS Anwendungen ausführen kann, während ein Auto ohne Fahrer prüft, ob ein Fahrzeug-OS das Fahrzeug führen kann.

Eine Warnung: „ein OS besitzen“ ist nicht die Ziellinie. Kernel werden zur Massenware, Verträge werden standardisiert, und Chiphersteller wie horizontale Plattformen drücken von beiden Enden. Für die meisten Hersteller lautet die eigentliche Frage nicht „sollen wir ein eigenes OS bauen?“, sondern „in welchem Teil der Steuerungsebene müssen wir das letzte Wort haben?“ Orchestrierung, Lebenszyklus, Datenkreislauf und die letztliche Übernahme der Sicherheitsverantwortung — das ist es, was nach der Welle der Standardisierung noch dem Hersteller gehört.

Der Wettstreit um das Fahrzeug-OS wird nicht damit enden, dass ein System gewinnt. Er wird mit einer schlichteren Frage enden: Wenn sich jede Schicht eines Autos kaufen lässt, welche ist die eine, die Sie nicht kaufen können? Dieser Beitrag hat das Koordinatensystem auf den Tisch gelegt; wo die Wette platziert wird, war immer die Entscheidung der Lesenden selbst.

---

Anhang A | Evidenzgrade und Hauptquellen

A.1 Evidenzgrade

Hinweis: Alle künftigen Termine (GM 2028, STLA One 2027, Hyundai 2030 usw.) sind Pläne oder Ziele der Unternehmen, keine Tatsachen, und es gibt Präzedenzfälle für Verzögerungen.

A.2 Hauptquellen (nach Thema, Auswahl)

• QNX-Installationsbasis: BlackBerry FY2026 10-K — https://www.sec.gov/Archives/edgar/data/1070235/000107023526000039/bbry-20260228.htm
• Serienstart MB.OS: Mercedes-Benz Group, Produktionsstart CLA in Rastatt — https://group.mercedes-benz.com/company/production/production-network/start-of-production-cla-rastatt.html
• NIO SkyOS: NIO offiziell — https://www.nio.cn/smart-technology/20251215002 ; IT Home — https://www.ithome.com/0/720/560.htm
• Li Auto HaloOS als Open Source: TechNode — https://cn.technode.com/post/2025-03-29/lixiang-xinghuan-os/
• Chinesische nationale Normen: Nationale öffentliche Serviceplattform für Normeninformationen — https://std.samr.gov.cn/gb/search/gbDetailed?id=0BBF0FBBBE1AE46FE06397BE0A0AD1FD ; https://std.samr.gov.cn/gb/search/gbDetailed?id=D33BADAFBDDF2CD0E05397BE0A0A113C
• Kommerzielle Übersetzung GB/T 47341-2026 (T3) — https://www.chinaautoregs.com/archives/7587
• GM-Zentralrechnerplattform: GM-Pressemitteilung, 22.10.2025 — 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 (Formulierung 2023): Toyota-Pressemitteilung, 11.04.2023 — 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
• Fortschritt RV Tech: Pressemitteilung Volkswagen-Konzern, 12.11.2025 — https://www.volkswagen-group.com/en/press-releases/one-year-after-its-founding-joint-venture-between-volkswagen-group-and-rivian-shows-strong-progress-19980 ; Wintertests — https://www.electrive.com/2026/03/27/vw-and-rivian-conclude-winter-testing-programme/
• CEA des Volkswagen-Konzerns: Pressemitteilung Volkswagen-Konzern, 28.01.2026 — 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, 10.12.2025 — 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
• Umstrukturierung CARIAD (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, 30.09.2026) — 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, 16.09.2026 — 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, 24.03.2026 — https://android-developers.googleblog.com/2026/03/Beyond-Infotainment-Extending-Android-Automotive-OS-for-Software-defined-Vehicles.html ; AAOS-SDV-Systemarchitektur — 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 und POSIX: UL Solutions — https://www.ul.com/sis/blog/autosar-part-2-adaptive-platform
• UN R156 (Wortlaut von Absatz 7.1.1): 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-Zertifizierung (SGS) — https://www.sgs.com/en-hk/news/2025/08/geely-auto-awarded-first-global-ai-safety-certification-for-road-vehicles
• Installationsbasis HarmonyOS-Cockpit / Qiankun: https://news.qq.com/rain/a/20260908A0664N00
• AUTOSEMO-Bericht 6.0: Pressemitteilung von Reach Auto (Neusoft), Oktober 2025, Veröffentlichung im Namen von AUTOSEMO — https://www.reachauto.com/en/2025/10/

---

Anhang B | VOCM-Bewertungsmatrix

Jede Dimension wird mit 0–5 Punkten bewertet. Die Werte beruhen ausschließlich auf öffentlichen Quellen; eine Dimension mit unzureichenden Belegen darf höchstens 2 Punkte erhalten oder wird als n. a. markiert.

Konfidenz: H = Tier-1–2-Belege stützen die meisten Dimensionen direkt; M = einige Dimensionen beruhen auf Unternehmensangaben; L = die meisten Dimensionen beruhen auf Sekundärquellen oder Inferenz.

Ausnahme bei derselben Architekturlinie: Eine Plattform, die gemeinsam mit einem bereits bewerteten Hersteller entwickelt wurde und dieselbe Architekturlinie übernimmt (etwa VW CEA mit XPeng), darf sich in Dimensionen, in denen ihre eigenen öffentlichen Informationen dünn sind, an den Werten dieses Herstellers orientieren. Jede solche Dimension muss in den Anmerkungen benannt werden, und die Konfidenz ist auf L begrenzt.

---

Anhang C | Abkürzungen