FAQ

OSxCAR (Optimized Software-defined Car Architectures) ist ein EFRE-gefördertes Forschungsprojekt (06/2024 – 05/2027, 5 Mio. €), das drei zentrale Engpässe der Automobilindustrie adressiert:

• Heterogenität — Vielfalt an Architekturen, Sprachen und Toolchains verhindert Software-Wiederverwendung
• Hohe Integrationskosten — Jede Plattformkombination erfordert eigene Portierung und Tests
• Lange Testzyklen — Physische Testaufbauten benötigen Wochen bis Monate

OSxCAR kombiniert eine WebAssembly-basierte SDV-Plattform, eine laufzeit-konfigurierbare Testbench und KI-gestützte Optimierung zu einem durchgängigen Ecosystem, das von der Simulation bis ins Fahrzeug mit einem einzigen Binary arbeitet.

→ Projektüberblick

OSxCAR ergänzt etablierte Stacks — es ersetzt sie nicht:

• AUTOSAR Adaptive definiert APIs und Softwarearchitektur, aber nicht die Ausführungsumgebung. OSxCAR nutzt WebAssembly als portables, sicheres Execution Layer — AUTOSAR-konforme Komponenten können in Wasm-Sandboxes laufen.
• Eclipse SDV ist ein Tooling-Ecosystem. OSxCAR liefert die Hardware-nahe Plattform (Testbench + Runtime + KI-Optimierung), die Eclipse-Tools als Deployment-Ziel nutzen können.
• Proprietäre Stacks erzeugen Vendor-Lock-in. OSxCAR setzt auf W3C-standardisierte WIT-Interfaces — sprachunabhängig, vendor-neutral, versionierbar.

Der Kern-Unterschied: “One Binary – Zero Porting” — dasselbe kompilierte WebAssembly-Modul läuft ohne Neukompilierung auf x86, ARM, RISC-V, MCUs und in der Cloud.

Der Fokus liegt auf Automotive, doch die Architektur ist branchenübergreifend übertragbar:

• Robotik — Autonome Systeme mit heterogener Hardware und echtzeitkritischer Software
• Avionik — Sicherheitskritische, zertifizierbare Softwaremodule in isolierten Sandboxes
• Medizintechnik — Vernetzte Medizingeräte mit strengen Safety- und Security-Anforderungen
• Cloud & Edge — Einheitliche Ausführungsumgebung vom Edge bis zum Datacenter

Überall dort, wo Software portabel, sicher und auf heterogener Hardware laufen muss, bietet der OSxCAR-Ansatz Vorteile.

→ Anwendungsfälle

Das zentrale Versprechen von OSxCAR: Eine einzige kompilierte WebAssembly-Komponente durchläuft den gesamten Entwicklungszyklus ohne Neukompilierung — von Model-in-the-Loop (MIL) über Software-/Hardware-in-the-Loop (SIL/HIL) bis zur Produktion im Fahrzeug.

• Kein plattformspezifischer Glue-Code
• Kein Re-Compile für verschiedene Architekturen (x86, ARM, RISC-V, MCUs)
• Identisches Verhalten in Simulation, auf der Testbench und auf der Zielhardware

Das eliminiert eine der größten Kostentreiber in der Fahrzeugsoftware-Entwicklung: die Portierung zwischen Plattformen.

→ SDV Plattform

Eine SDV-Plattform ermöglicht die flexible, softwaregesteuerte Konfiguration von Fahrzeugfunktionen. Statt fest verdrahteter ECUs werden Funktionen als Software-Module dynamisch verteilt und Over-the-Air aktualisiert.

OSxCAR unterstützt alle E/E-Architektur-Generationen: Legacy-Domain-ECUs, Zonal-Controller und zentrale HPC-Computer — inklusive Mischbetrieb von klassischen und SDV-basierten Komponenten.

→ SDV Plattform

WebAssembly (Wasm) kombiniert die Vorteile beider Welten:

• vs. Container (Docker): Die LightWeave-Runtime erzielt bis zu 90% geringere Laufzeitkosten. Kein OS-Layer nötig, Start in Mikrosekunden statt Sekunden, deutlich kleinerer Footprint auf MCUs.
• vs. Nativ: Ein einziges Binary läuft auf x86, ARM, RISC-V — ohne Cross-Compilation. Ahead-of-Time (AoT) Kompilierung liefert deterministische Latenzen für sicherheitskritische Systeme.
• Sicherheit: Strikte Sandbox-Isolierung (Memory Safety, Capability-basiert) — jede Komponente läuft in ihrer eigenen sicheren Umgebung.

→ WebAssembly im Fahrzeug

Das WebAssembly Component Model (W3C-Standard) definiert, wie Wasm-Module miteinander und mit dem Host-System kommunizieren. WIT (WebAssembly Interface Types) sind die maschinenlesbaren Schnittstellenbeschreibungen:

• Sprachunabhängig — Rust, C++ oder andere Sprachen erzeugen kompatible Komponenten
• Versionierbar — Interfaces tragen semantische Versionen (z.B. aptiv:antipinch/motor-driver-v2@0.1.0)
• Vendor-neutral — Kein proprietäres SDK, keine Plattform-Abhängigkeit
• Composable — Komponenten frei kombinierbar wie Lego-Bausteine

WIT-Interfaces sind das Fundament für ein offenes SDV-Ecosystem mit echtem Third-Party-Support.

→ SDV Plattform · Interaktive Demo

Jede Sprache, die nach WebAssembly kompilieren kann, ist nutzbar. Im OSxCAR-Projekt kommen primär zum Einsatz:

• Rust — Hauptentwicklungssprache für neue Komponenten. Memory Safety ohne Garbage Collector, eliminiert Buffer Overflows und Data Races zur Compile-Zeit.
• C++ — Integration bestehender Automotive-Codebases via Wasm
• Weitere Sprachen mit Wasm-Support (z.B. Go, Zig, Kotlin) sind ebenfalls nutzbar

Durch WIT-Interfaces können Komponenten in unterschiedlichen Sprachen nahtlos miteinander kommunizieren — die Sprache wird zum Implementierungsdetail.

→ Interaktive Demo · Publikationen

OSxCAR ist für heterogene Hardware konzipiert:

• CPUs: x86, ARM, RISC-V
• Accelerators: GPUs, FPGAs, ASICs
• MCUs: Mikrocontroller-kompatible WebAssembly-Container
• TEEs: Trusted Execution Environments für sicherheitskritische Anwendungen
• Formfaktoren: SMARC, COM-HPC, COM-Express (via t.RECS-Plattform)

Dasselbe Wasm-Binary läuft auf all diesen Targets — inklusive Betriebssystemen wie Bare Metal, Zephyr, Linux, VxWorks und QNX.

→ SDV Plattform · Demonstratoren

Die Software-Defined Vehicle Architecture Testbench ist eine laufzeit-konfigurierbare Hardware-Plattform, die verschiedene Fahrzeug-Topologien physisch nachbildet:

• Switch Matrix — Physische Schaltmatrix (8×8 bis 64×64 Ports), Topologie-Wechsel in < 1 ms, kritisch für TSN und Echtzeit-Tests (ADAS, Fahrdynamik-Regelung, Safety-kritische Pfade)
• Bus-agnostisch — Ethernet/TSN (100M–10G), CAN/CAN-FD, LIN
• RECS Microserver — Heterogene Rechenknoten (x86, ARM, RISC-V) mit GPU/FPGA-Erweiterung
• Remote-Zugriff — Cloud-basiert, weltweit nutzbar, mit Zeit-Slot-Reservierung
• GNN-Trainingsdaten — Die Bench liefert realistische Latenz-/Topologie-Daten für das Training der KI-Modelle (Graph Neural Networks)

→ Testbench

Von Monaten zu Minuten. Die laufzeit-konfigurierbare Schaltmatrix ermöglicht sofortige Topologie-Änderungen ohne Hardware-Umverdrahtung. Konfigurationen werden als Dateien definiert und bei Bedarf geladen — keine Techniker, kein Kabel-Umstecken.

Kostenreduktion: Eine zentrale, geteilte Bench ersetzt individuelle Hardware-Duplikate bei jedem Partner — mit messbaren CO₂-Einsparungen durch weniger Hardware-Produktion und -Versand.

→ Testbench

Ja, die SDVA-Testbench ist für Remote-Zugriff konzipiert:

• Cloud-basiertes Sharing mit Zeit-Slot-Reservierung — exklusiver Zugriff per Web-Interface während des gebuchten Slots
• Multi-Tenant-Isolierung via separate Namespaces, VLANs und TLS 1.3
• TISAX-Compliance (VDA ISA 6.0 Level 3) für sichere Datenverarbeitung in der Automotive-Lieferkette
• Audit-Trail — alle Zugriffe werden protokolliert; nur bench-generierte bzw. pseudonymisierte Test-Daten
• Telemetrie-Stack — Prometheus, Grafana, ELK-Stack, Jaeger für Monitoring und Tracing

Hinweis: TISAX- und Security-Elemente sind geplant, aber derzeit noch nicht vollständig umgesetzt.

→ Testbench

Die SDVA-Testbench kann ihre Netzwerktopologie im laufenden Betrieb ändern — ohne Hardware-Umverdrahtung, ohne Neustart:

• Physische Schaltmatrix schaltet Verbindungen zwischen Rechenknoten und Bussen in < 1 ms um
• Konfiguration als Code — Topologien werden in Dateien definiert, versioniert (Git) und bei Bedarf geladen
• Beliebige E/E-Architekturen — Domain, Zonal oder Central können in Sekunden nachgebildet werden

Das eliminiert den bisherigen Engpass: physisches Umstecken von Kabeln und wochenlange Aufbauzeiten.

→ Testbench

Die Testbench bildet alle gängigen Fahrzeug-Elektrik/Elektronik-Architekturen physisch ab:

• Legacy-Domänen — Dezentrale Steuergeräte nach Funktionen getrennt (Powertrain, Chassis, Infotainment)
• Zonen-Controller — Regional gruppierte Controller nach Fahrzeugbereichen (vorne, hinten, links, rechts)
• Zentral-Computer — Hochintegrierte Plattformen für L3+ Autonomie, alle Funktionen zentralisiert

Testbench-Vorteil: Alle drei Architekturstufen sind auf einer Plattform testbar — inklusive Migrations-Szenarien zwischen den Stufen. Das erlaubt OEMs, den Übergang von Legacy zu Zentral-Computer schrittweise zu validieren.

→ Testbench

RECS (Rack-based Embedded Computing System) ist eine modulare Hardwareplattform (t.RECS / u.RECS / RECSBox), die als Herzstück der SDVA-Testbench dient:

• SMARC — Ultra-Low-Power (ARM Cortex-A), ideal für Sensor-Nodes und Edge-Steuergeräte
• COM-HPC — High-Performance (x86, GPU-ready), für Zentral-Computer und ADAS-Anwendungen
• COM-Express — Industrial-Standard mit breiter Vendor-Unterstützung
• Heterogene Rechenknoten: x86, ARM, RISC-V auf einer Plattform, TSN-fähig
• Erweiterbar: GPU- und FPGA-Module für Beschleuniger-Szenarien
• Thermisch optimiert: t.RECS mit kompaktem Rack-Design für Dauerbetrieb im Lab

RECS-Module emulieren reale Fahrzeug-ECUs und ermöglichen Tests auf produktionsnaher Hardware — verschiedene Prozessor-Module sind einfach tauschbar.

→ Testbench · Glossar: RECS

• Bench (physisch): Nutzt reale Hardware (RECS, echte Bus-Systeme) und liefert realistische Latenz-/Jitter-Daten unter Produktionsbedingungen.
• Simulation (OMNeT++, Mininet): Rein software-basiert, skaliert besser für viele Szenarien, aber weniger realistische Timings.

Best Practice: Simulation für Exploration und breite Szenario-Abdeckung, Bench für finale Validierung und belastbare Messdaten. Die SDVA-Testbench unterstützt beide Pfade — Simulationsergebnisse können mit physischen Bench-Messungen verglichen und verifiziert werden.

→ Testbench · KI-gestützte Systeme

Das WebAssembly-Testframework ermöglicht durchgängige Qualitätssicherung über alle Teststufen:

• Identisches Binary in Browser, Cloud und auf der physischen Testbench ausführbar
• Deterministische Bench-Umgebung — AoT-Kompilierung (Ahead-of-Time) liefert reproduzierbare Latenz-Charakterisierung
• Mutation Testing — systematische Code-Mutationen decken Schwächen in der Testabdeckung auf
• Automatisierte Ergebnissammlung mit Visualisierung (Grafana) und ISO-26262-konformem Audit-Trail
• Reproduzierbare Ergebnisse von MIL über HIL bis zur Fahrzeugflotte

Wasm-Module laufen identisch auf Laptop, Bench und Zielhardware — die Bench liefert dabei die deterministische Referenzumgebung für belastbare Messergebnisse.

→ Anwendungsfälle · Testbench

Graph Neural Networks (GNNs) lernen aus der Topologie des Fahrzeugnetzwerks (ECUs = Knoten, Busse = Kanten, Latenzprofile = Gewichte):

• Latenzprognose — Vorhersage von Netzwerkverzögerungen für neue E/E-Architekturen, bevor Hardware existiert
• Software-Platzierung — Optimale Verteilung von Funktionen auf Rechenknoten
• Routingoptimierung — TSN-Priorisierung, VLAN-, TAS-Scheduling
• Bottleneck-Erkennung — Automatisierte Analyse, die Muster erkennt, die manueller Analyse entgehen

Bench-Integration: Die physische Testbench sammelt Topologie-Graphen und µs-genaue Latenz-Messungen — diese realen Daten fließen direkt ins GNN-Training. Validierung der KI-Empfehlungen erfolgt im Shadow-Mode auf der Bench.

Entscheidend: Keine KI-Empfehlung geht in Produktion ohne physische Bench-Validierung. Die Modelle lernen aus echten Messdaten — nicht aus synthetischen Simulationen.

→ KI-gestützte Systeme · Testbench

Erste GNN-Modelle (z.B. RouteNet) erreichen Genauigkeiten im einstelligen Prozentbereich für Latenzvorhersagen. Validierung erfolgt in einem geschlossenen Kreislauf:

1. Datenerhebung auf der physischen Testbench (µs-Präzision via FPGA-Timestamps)
2. Training der GNN-Modelle mit realen Messdaten (Jitter, Busauslastung, CPU/Energie pro Knoten)
3. Bench-Validierung jeder KI-Empfehlung durch physische Messung
4. Continuous Improvement mit wachsendem Datenbestand

→ KI-gestützte Systeme

OSxCAR basiert konsequent auf offenen Standards:

• W3C WebAssembly — Standardisierte Runtime und Binary-Format
• WASI / WIT — WebAssembly System Interface und Interface Types (Component Model)
• COVESA VSS — Vehicle Signal Specification für standardisierte Fahrzeug-APIs
• AUTOSAR Adaptive — Integration mit bestehender Automotive-Softwarearchitektur
• ISO 26262 — Funktionale Sicherheit (ASIL-Qualifizierung bis ASIL D)
• ISO/SAE 21434 — Cybersecurity für Fahrzeuge
• IEEE 802.1 TSN — Deterministische Netzwerkkommunikation

→ SDV Plattform

WebAssembly bietet mehrschichtige Sicherheit — by Design, nicht als Nachgedanke:

• Memory Safety — Keine Buffer Overflows oder Speicherfehler
• Sandbox-Isolierung — Apps können nur auf explizit freigegebene Ressourcen zugreifen (Capability-basiert)
• Freedom from Interference — Crash einer Komponente bleibt lokal (ISO 26262)
• Deterministische Ausführung — Vorhersagbares Verhalten für Safety-kritische Systeme
• Formale Verifikation — Geplant von Komponente bis Gesamtsystem

→ WebAssembly

Dynamic Homologation ermöglicht selektive Komponentenzertifizierung: Nur die geänderte Software-Komponente wird re-evaluiert — nicht das Gesamtsystem. Das verkürzt Feature-Rollouts von Monaten auf Wochen und ermöglicht risikofreie OTA-Updates.

Voraussetzungen dafür sind klar definierte WIT-Interfaces, Sandbox-Isolierung und automatisierte Safety-Evidenz-Generierung — alles Bestandteile der OSxCAR-Plattform.

→ SDV Plattform

Die WebAssembly-Sandboxes sind für ASIL-Qualifizierung bis ASIL D konzipiert und adressieren die Anforderungen von ISO 26262 (funktionale Sicherheit) und ISO/SAE 21434 (Cybersecurity). Die Qualifizierung erfolgt schrittweise: automatisierte Generierung von Safety-Evidenz ist Teil der Plattform-Roadmap.

→ SDV Plattform

OSxCAR unterstützt eine stufenweise Validierung, die vom reinen Software-Test bis zum Flottenbetrieb reicht:

• SIL (Software-in-the-Loop) — Rein software-basierte Validierung, bevor Hardware verfügbar ist. Schnelle Iteration, hohe Szenario-Abdeckung.
• HIL (Hardware-in-the-Loop) — Reale ECUs kombiniert mit simulierter Umgebung. Echte Hardware-Validierung mit reproduzierbaren Bedingungen.
• Shadow Mode (A/B Testing) — Neue Features laufen parallel zur Produktionslogik im Fahrzeug: Sie empfangen reale Daten, erzeugen Vergleichs-Outputs, greifen aber nicht in die Steuerung ein.

Stufenprogression: SIL → HIL → Shadow Mode → Production — jede Stufe baut auf der vorherigen auf. Das ermöglicht Fleet-Scale A/B-Testing als Brücke zwischen Labor und realem Fahrzeugbetrieb.

→ SDV Plattform · Testbench

• Kostenreduktion — Bis zu 50% Einsparungen durch Software-Wiederverwendung dank “One Binary”-Ansatz
• Schnellere Markteinführung — Feature-Rollouts in Wochen statt Monaten durch Dynamic Homologation
• CO₂-Reduktion — Bis zu 20% durch KI-Optimierung und effizientere Softwareausführung
• Qualitätssteigerung — Mutation Testing (RapidTest) + strukturierte Schnittstellen (WASI/WIT)
• Skalierbarkeit — Von MIL/SIL über HIL/VIL bis zur Produktion mit einem Binary

Ja — der Anti-Pinch-Einklemmschutz läuft als interaktive Demo direkt im Browser. Drei WebAssembly-Komponenten (in Rust geschrieben, via WIT verbunden) steuern eine realistische Fensterheber-Simulation — mit exakt denselben Binaries, die für den Einsatz auf ECUs vorgesehen sind.

Weitere Demonstratoren:

• Adaptive AUTOSAR + Rust/Wasm — Rust- und C++-Komponenten interoperieren via WIT
• Hardware-Agnostic Demo — Selbe Komponenten auf Bare Metal, Zephyr, Linux, VxWorks und QNX

→ Interaktive Demo · Alle Demonstratoren

Für Zulieferer / Tier-1:

• “Same Binary” eliminiert OEM-spezifisches Porting → schnellere Validierung, geringere Zertifizierungskosten
• Ein einziges Software-Paket für alle Kunden statt individueller Plattform-Varianten

Für System-Integratoren:

• Einheitliche Integration von MIL bis Fahrzeug mit WIT + Wasm als konsistenter Interface-Basis
• Weniger Bench-Varianten, parallele Nutzung durch verteilte Teams

→ Anwendungsfälle

OSxCAR wird im Programm EFRE/JTF NRW – NeueWege.IN.NRW gefördert. Projektträger: Projektträger Jülich (PTJ). Die Gesamtfördersumme beträgt 5 Millionen Euro über eine Laufzeit von Juni 2024 bis Mai 2027.

→ Förderung

• Interaktive Demo ausprobieren: Anti-Pinch WebAssembly Demo
• Kontakt für Fragen und Anfragen: Kontakt
• Publikationen und Konferenzbeiträge einsehen: Publikationen