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."
Evolutionsstufen
Von der Browser-Laufzeit über die ersten Serverstandards bis zur modularen Fahrzeugschnittstelle – WebAssembly hat sich in zehn Jahren zur universellen Ausführungsumgebung entwickelt.
- 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.
OSxCAR-Erweiterungen
Innerhalb von OSxCAR wurden Erweiterungen entwickelt, die die Kombination von WIT-Schnittstellen mit systemspezifischen Optimierungen ermöglichen:
- WIT + Hardware-Optimierung: Kombination typsicherer Schnittstellen mit plattformspezifischen Beschleunigern – ohne Einbußen bei Portabilität oder Sicherheitsgrenzen
- Zero-Copy Kamera-Pipeline: Erweiterung für kamerabasierte Fahrerassistenzsysteme – vermeidet Kopien des Bildes im Speicher und reduziert Latenz und Overhead direkt auf dem Pfad Kamera → ADAS-Modul
Weitere Technologie-Seiten: SDV-Plattform · Künstliche Intelligenz · Testplattform