WebAssembly

Plattformunabhängige Software für das Software‑Defined Vehicle – Komponenten, Schnittstellen, Laufzeiten und Qualitätssicherung.

WebAssembly wurde entwickelt, um komplexe Programme portabel und sicher auszuführen – ursprünglich im Browser, heute auf Servern, Embedded-Systemen und im Fahrzeug. Für OSxCAR entscheidend: ein einziges kompiliertes Binary läuft unverändert auf x86, ARM und RISC-V – von der Simulation bis ins Zielsteuergerät.

Ein Binary – alle Architekturen

Quellcode in Rust, C++ oder Go wird einmalig zu einem Wasm-Binary kompiliert. Dieses Binary läuft ohne Änderung auf jedem Zielsystem – unabhängig von Prozessorarchitektur oder Betriebssystem. Kein Re-Compile, kein plattformspezifischer Glue-Code.

„Einmal kompiliert, überall lauffähig – von der Simulation bis ins Fahrzeug."

Schematisches Diagramm auf dunkelblauem Hintergrund: Drei Quellcode-Icons (Rust, C++, Go) auf der linken Seite laufen über leuchtende Verbindungslinien in ein zentrales Wasm-Hexagon-Icon zusammen. Von dort führen drei Linien nach rechts zu Chip-Icons für x86, ARM und RISC-V – das One-Binary-Prinzip von WebAssembly visualisiert.
Wasm-Kompilierungs- und Deployment-Pfad

Was macht OSxCAR mit WebAssembly?

Das WebAssembly Component Model liefert die Grundlage – aber für den Einsatz im Fahrzeug reicht der Standard allein nicht aus. OSxCAR erweitert Wasm um automotive-spezifische Fähigkeiten, die direkt in der Testbench validiert und über die SDV-Plattform deployt werden.

WIT-Schnittstellen mit Hardware-Optimierung

WIT definiert typsichere Schnittstellen zwischen Wasm-Komponenten – sprachunabhängig und portabel. OSxCAR kombiniert diese standardisierten Schnittstellen mit plattformspezifischen Beschleunigern: Eine Komponente kann z. B. SIMD-Befehle oder GPU-Offloading nutzen, ohne dass sich die WIT-Schnittstelle oder das Deployment ändert.

Ergebnis: Der Anwendungscode bleibt portabel, aber auf jedem Zielsystem läuft er mit der bestmöglichen Performance. Die KI-Optimierung entscheidet automatisch, welche Beschleuniger auf welcher Hardware aktiviert werden.

Darstellung der Verbindung zwischen WebAssembly-Modulen und Hardware-Beschleunigern
WIT-Schnittstellen mit Hardware-spezifischer Optimierung

Zero-Copy Kamera-Pipeline

Kamerabasierte Fahrerassistenzsysteme verarbeiten hochauflösende Bilddaten in Echtzeit. Normalerweise werden diese Daten auf dem Weg von der Kamera zum ADAS-Modul mehrfach im Speicher kopiert – jede Kopie kostet Latenz und Energie.

OSxCAR erweitert die Wasm-Laufzeit um eine Zero-Copy-Schnittstelle: Bilddaten fließen direkt vom Kameratreiber in die Wasm-Sandbox, ohne Zwischenkopien. Die Sandbox-Sicherheit bleibt gewahrt – der Zugriff ist readonly und wird bei Komponentenwechsel automatisch entzogen.

„Kameradaten direkt in die Sandbox – ohne Kopie, ohne Sicherheitsverlust."

Diagramm der Zero-Copy-Pipeline: Kameradaten fließen ohne Zwischenkopie direkt in das ADAS-Wasm-Modul
Zero-Copy-Pfad: Kamera → Wasm-Sandbox → ADAS-Modul

Sicherheitsmodell: Isolation & Attestation

Jedes Wasm-Modul läuft in einer eigenen Sandbox – mit strikt begrenztem Zugriff auf Speicher, Netzwerk und Peripherie. Das Capability-basierte Sicherheitsmodell erlaubt einem Modul nur genau die Rechte, die es zur Laufzeit benötigt. Ein fehlerhaftes oder kompromittiertes Modul kann andere Komponenten nicht beeinflussen.

Für OTA-Updates sicherheitskritischer Funktionen setzt OSxCAR auf kryptographische Modul-Attestation: Vor der Ausführung wird die Signatur jedes Moduls geprüft – manipulierte Binaries werden erkannt und abgelehnt, bevor sie Schaden anrichten können.

„Jedes Modul isoliert, jedes Update signiert – sichere Updates auch für Bremse und Lenkung."

Visualisierung der Sandbox-Isolation: Wasm-Module in getrennten Sicherheitsdomänen mit kontrollierten Schnittstellen
Capability-basierte Isolation auf Modulebene

AUTOSAR-Integration: Vom Monolith zum Modul

Bestehende Fahrzeugsoftware ist überwiegend im AUTOSAR-Ökosystem entwickelt. Ein Komplettumstieg auf WebAssembly wäre unrealistisch – deshalb setzt OSxCAR auf schrittweise Migration:

  • 🔹 Standardisierte Brücke: WASI 0.3 (Async & Streams) erlaubt es, AUTOSAR-Schnittstellen als WIT-Interfaces zu modellieren – Wasm-Module sprechen direkt mit dem bestehenden Stack
  • 🔹 Inkrementelle Modularisierung: Einzelne AUTOSAR-Softwarekomponenten werden schrittweise in Wasm-Module überführt – ohne das Gesamtsystem zu destabilisieren
  • 🔹 Rückwärtskompatibel: Legacy-Code bleibt unverändert lauffähig, neue Module profitieren sofort von Portabilität und Sandbox-Sicherheit
  • 🔹 Ergebnis: Weniger Migrationsbruch, schnellere Akzeptanz in etablierten Prozessen und Zertifizierungspfaden

Kurz gesagt

WebAssembly liefert das portable Binärformat, das WIT Component Model die modularen Schnittstellen – und OSxCAR ergänzt, was für den automotive Einsatz fehlt: Hardware-Optimierung ohne Portabilitätsverlust und latenzfreie Datenpfade für sicherheitskritische Sensorik.

  • 🔹 Plattform: Die SDV-Plattform nutzt Wasm-Components als Deployment-Einheit – ein Binary für alle Steuergeräte
  • 🔹 KI: Die KI-Optimierung entscheidet, welche Wasm-Module auf welcher Hardware laufen und welche Beschleuniger aktiviert werden
  • 🔹 Testbench: Die SDVA-Testbench führt Wasm-Komponenten auf heterogener Hardware aus – identische Binaries wie im Zielfahrzeug

Evolutionsstufen

2015
Browser-Support (Emscripten)

Alle großen Browser unterstützen WebAssembly – diese Plattform wird oft nach ihrem Compiler „Emscripten" benannt. Alle Interaktionen mit der Welt außerhalb des WebAssembly-Sandkastens finden über JavaScript-Funktionen statt, die von WebAssembly aus aufgerufen werden.

2017
Spezifikation 1.0

Die erste offizielle WebAssembly-Spezifikation legt das Fundament für ein portables, sicheres Binärformat – verabschiedet vom W3C als offener Standard.

2019
WASI Preview 1 (wasip1)

WebAssembly abstrahiert den Prozessor – für ein lauffähiges System ist aber auch ein Betriebssystem erforderlich. WASI standardisiert die Schnittstelle zwischen Programm und OS, z. B. um die aktuelle Zeit zu erfragen oder Dateien zu lesen. Damit läuft WebAssembly erstmals auf Servern. Wasip1 ist allerdings nicht modular und stark an POSIX orientiert – für kleinere Mikrocontroller weniger geeignet und nur aufwändig erweiterbar.

2022
Spezifikation 2.0

Weitere Befehle: Vektor- und schnelle Speicherfüll-Befehle (SIMD, Bulk Memory) sowie mehrere Ergebniswerte für Programmteile – deutliche Leistungssteigerung für rechenintensive Anwendungen.

2024
WASI 0.2 – Component Model

Standardisiert die Schnittstellenbeschreibungssprache WIT, mit der weitere Schnittstellen beschrieben werden können. Komplexe Datentypen lassen sich zwischen Programmiersprachen austauschen. Das modulare Design vereinfacht die Portierung auf Mikrocontroller erheblich – die Basis für den automotive Einsatz.

2025
Spezifikation 3.0

64-Bit-Unterstützung, mehrere Speicherbereiche, Unterstützung für Objekte außerhalb des linearen Speichers (Garbage Collection), effiziente Aufrufe einer Funktion am Funktionsende (Tail Calls) und Ausnahmebehandlung.

2026
WASI 0.3 – Async & Streams

Ermöglicht Datenströme, asynchrone Aufrufe und Ergebnisse. Gerade dies ist hilfreich, um AUTOSAR-Schnittstellen einfacher modellieren zu können – ein wichtiger Schritt für die Integration in bestehende automotive Stacks.

Weiteres zur Geschichte von WebAssembly auf den Seiten der ByteCodeAlliance.

Weitere Technologie-Seiten: SDV-Plattform · Künstliche Intelligenz · Testplattform · FAQ · Glossar