FAQ

OSxCAR (Optimized Software-defined Car Architectures) is an EFRE-funded research project (06/2024 – 05/2027, €5M) addressing three key bottlenecks in the automotive industry:

• Heterogeneity — Diverse architectures, languages and toolchains prevent software reuse
• High integration costs — Each platform combination requires separate porting and testing
• Long test cycles — Physical test setups take weeks to months

OSxCAR combines a WebAssembly-based SDV platform, a runtime-configurable testbench and AI-powered optimization into an end-to-end ecosystem that works from simulation to vehicle with a single binary.

→ Project overview

OSxCAR complements established stacks — it does not replace them:

• AUTOSAR Adaptive defines APIs and software architecture, but not the execution environment. OSxCAR uses WebAssembly as a portable, secure execution layer — AUTOSAR-compliant components can run in Wasm sandboxes.
• Eclipse SDV is a tooling ecosystem. OSxCAR delivers the hardware-close platform (testbench + runtime + AI optimization) that Eclipse tools can target for deployment.
• Proprietary stacks create vendor lock-in. OSxCAR uses W3C-standardized WIT interfaces — language-independent, vendor-neutral, versionable.

The core difference: “One Binary – Zero Porting” — the same compiled WebAssembly module runs without recompilation on x86, ARM, RISC-V, MCUs and in the cloud.

The focus is on automotive, yet the architecture is transferable across industries:

• Robotics — Autonomous systems with heterogeneous hardware and real-time-critical software
• Avionics — Safety-critical, certifiable software modules in isolated sandboxes
• Medical technology — Networked medical devices with strict safety and security requirements
• Cloud & Edge — Unified execution environment from edge to datacenter

Wherever software must run portably, securely and on heterogeneous hardware, the OSxCAR approach offers advantages.

→ Use cases

OSxCAR’s central promise: A single compiled WebAssembly component traverses the entire development cycle without recompilation — from Model-in-the-Loop (MIL) through Software-/Hardware-in-the-Loop (SIL/HIL) to production in the vehicle.

• No platform-specific glue code
• No recompilation for different architectures (x86, ARM, RISC-V, MCUs)
• Identical behavior in simulation, on the testbench and on target hardware

This eliminates one of the biggest cost drivers in vehicle software development: porting between platforms.

→ SDV Platform

An SDV platform enables flexible, software-controlled configuration of vehicle functions. Instead of hard-wired ECUs, functions are dynamically distributed and updated over-the-air as software modules.

OSxCAR supports all E/E architecture generations: legacy domain ECUs, zonal controllers and central HPC computers — including mixed operation of classical and SDV-based components.

→ SDV Platform

WebAssembly (Wasm) combines the best of both worlds:

• vs. Containers (Docker): The LightWeave runtime achieves up to 90% lower runtime costs. No OS layer needed, startup in microseconds instead of seconds, significantly smaller footprint on MCUs.
• vs. Native: A single binary runs on x86, ARM, RISC-V — without cross-compilation. Ahead-of-Time (AoT) compilation delivers deterministic latencies for safety-critical systems.
• Security: Strict sandbox isolation (memory safety, capability-based) — each component runs in its own secure environment.

→ WebAssembly in vehicles

The WebAssembly Component Model (W3C standard) defines how Wasm modules communicate with each other and with the host system. WIT (WebAssembly Interface Types) are the machine-readable interface descriptions:

• Language-independent — Rust, C++ or other languages produce compatible components
• Versionable — Interfaces carry semantic versions (e.g. aptiv:antipinch/motor-driver-v2@0.1.0)
• Vendor-neutral — No proprietary SDK, no platform dependency
• Composable — Components freely combinable like building blocks

WIT interfaces are the foundation for an open SDV ecosystem with genuine third-party support.

→ SDV Platform · Interactive demo

Any language that can compile to WebAssembly is usable. The OSxCAR project primarily uses:

• Rust — Primary development language for new components. Memory safety without garbage collector, eliminating buffer overflows and data races at compile time.
• C++ — Integration of existing automotive codebases via Wasm
• Additional languages with Wasm support (e.g. Go, Zig, Kotlin) are also usable

Through WIT interfaces, components in different languages can communicate seamlessly — the language becomes an implementation detail.

→ Interactive demo · Publications

OSxCAR is designed for heterogeneous hardware:

• CPUs: x86, ARM, RISC-V
• Accelerators: GPUs, FPGAs, ASICs
• MCUs: Microcontroller-compatible WebAssembly containers
• TEEs: Trusted Execution Environments for safety-critical applications
• Form factors: SMARC, COM-HPC, COM-Express (via t.RECS platform)

The same Wasm binary runs on all these targets — including operating systems like Bare Metal, Zephyr, Linux, VxWorks and QNX.

→ SDV Platform · Demonstrators

The Software-Defined Vehicle Architecture Testbench is a runtime-configurable hardware platform that physically replicates various vehicle topologies:

• Switch Matrix — Physical switching matrix (8×8 to 64×64 ports), topology changes in < 1 ms, critical for TSN and real-time tests (ADAS, vehicle dynamics control, safety-critical paths)
• Bus-agnostic — Ethernet/TSN (100M–10G), CAN/CAN-FD, LIN
• RECS Microservers — Heterogeneous compute nodes (x86, ARM, RISC-V) with GPU/FPGA expansion
• Remote access — Cloud-based, globally accessible, with time-slot reservation
• GNN training data — The bench provides realistic latency/topology data for training AI models (Graph Neural Networks)

→ Testbench

From months to minutes. The runtime-configurable switching matrix enables immediate topology changes without hardware rewiring. Configurations are defined as files and loaded on demand — no technicians, no cable swapping.

Cost reduction: A single shared bench replaces individual hardware duplicates at each partner — with measurable CO₂ savings through less hardware production and shipping.

→ Testbench

Yes, the SDVA Testbench is designed for remote access:

• Cloud-based sharing with time-slot reservation — exclusive access via web interface during booked slots
• Multi-tenant isolation via separate namespaces, VLANs and TLS 1.3
• TISAX compliance (VDA ISA 6.0 Level 3) for secure data processing in the automotive supply chain
• Audit trail — all access is logged; only bench-generated or pseudonymized test data
• Telemetry stack — Prometheus, Grafana, ELK Stack, Jaeger for monitoring and tracing

Note: TISAX and security elements are planned but not yet fully implemented.

→ Testbench

The SDVA Testbench can change its network topology during operation — without hardware rewiring, without restart:

• Physical switching matrix switches connections between compute nodes and buses in < 1 ms
• Configuration as code — Topologies are defined in files, version-controlled (Git) and loaded on demand
• Any E/E architecture — Domain, Zonal or Central can be replicated in seconds

This eliminates the previous bottleneck: physical cable swapping and weeks-long setup times.

→ Testbench

The testbench physically replicates all common vehicle electrical/electronic architectures:

• Legacy domains — Decentralized control units separated by function (powertrain, chassis, infotainment)
• Zone controllers — Regionally grouped controllers by vehicle area (front, rear, left, right)
• Central computer — Highly integrated platforms for L3+ autonomy, all functions centralized

Testbench advantage: All three architecture levels are testable on one platform — including migration scenarios between levels. This allows OEMs to validate the transition from legacy to central computer step by step.

→ Testbench

RECS (Rack-based Embedded Computing System) is a modular hardware platform (t.RECS / u.RECS / RECSBox) serving as the heart of the SDVA Testbench:

• SMARC — Ultra-low-power (ARM Cortex-A), ideal for sensor nodes and edge controllers
• COM-HPC — High-performance (x86, GPU-ready), for central computers and ADAS applications
• COM-Express — Industrial standard with broad vendor support
• Heterogeneous compute nodes: x86, ARM, RISC-V on one platform, TSN-capable
• Expandable: GPU and FPGA modules for accelerator scenarios
• Thermally optimized: t.RECS with compact rack design for continuous lab operation

RECS modules emulate real vehicle ECUs and enable testing on production-grade hardware — different processor modules are easily swappable.

→ Testbench · Glossary: RECS

• Bench (physical): Uses real hardware (RECS, real bus systems) and delivers realistic latency/jitter data under production conditions.
• Simulation (OMNeT++, Mininet): Purely software-based, scales better for many scenarios, but with less realistic timings.

Best practice: Simulation for exploration and broad scenario coverage, bench for final validation and reliable measurement data. The SDVA Testbench supports both paths — simulation results can be compared and verified with physical bench measurements.

→ Testbench · AI-powered systems

The WebAssembly test framework enables end-to-end quality assurance across all test levels:

• Identical binary executable in browser, cloud and on the physical testbench
• Deterministic bench environment — AoT compilation (Ahead-of-Time) delivers reproducible latency characterization
• Mutation testing — systematic code mutations uncover weaknesses in test coverage
• Automated result collection with visualization (Grafana) and ISO-26262-compliant audit trail
• Reproducible results from MIL through HIL to vehicle fleet

Wasm modules run identically on laptop, bench and target hardware — the bench provides the deterministic reference environment for reliable measurements.

→ Use cases · Testbench

Graph Neural Networks (GNNs) learn from the topology of the vehicle network (ECUs = nodes, buses = edges, latency profiles = weights):

• Latency prediction — Forecasting network delays for new E/E architectures, before hardware exists
• Software placement — Optimal distribution of functions on compute nodes
• Routing optimization — TSN prioritization, VLAN, TAS scheduling
• Bottleneck detection — Automated analysis detecting patterns that manual analysis misses

Bench integration: The physical testbench collects topology graphs and µs-precise latency measurements — this real data feeds directly into GNN training. Validation of AI recommendations occurs in shadow mode on the bench.

Crucially: No AI recommendation goes into production without physical bench validation. The models learn from real measurement data — not from synthetic simulations.

→ AI-powered systems · Testbench

Initial GNN models (e.g. RouteNet) achieve single-digit percentage accuracy for latency predictions. Validation occurs in a closed loop:

1. Data collection on the physical testbench (µs precision via FPGA timestamps)
2. Training of GNN models with real measurement data (jitter, bus utilization, CPU/energy per node)
3. Bench validation of every AI recommendation through physical measurement
4. Continuous improvement with growing data corpus

→ AI-powered systems

OSxCAR is consistently based on open standards:

• W3C WebAssembly — Standardized runtime and binary format
• WASI / WIT — WebAssembly System Interface and Interface Types (Component Model)
• COVESA VSS — Vehicle Signal Specification for standardized vehicle APIs
• AUTOSAR Adaptive — Integration with existing automotive software architecture
• ISO 26262 — Functional safety (ASIL qualification up to ASIL D)
• ISO/SAE 21434 — Cybersecurity for vehicles
• IEEE 802.1 TSN — Deterministic network communication

→ SDV Platform

WebAssembly offers multi-layered security — by design, not as an afterthought:

• Memory Safety — No buffer overflows or memory errors
• Sandbox isolation — Apps can only access explicitly released resources (capability-based)
• Freedom from Interference — A component crash stays local (ISO 26262)
• Deterministic execution — Predictable behavior for safety-critical systems
• Formal verification — Planned from component to complete system

→ WebAssembly

Dynamic Homologation enables selective component certification: Only the changed software component is re-evaluated — not the entire system. This shortens feature rollouts from months to weeks and enables risk-free OTA updates.

Prerequisites include clearly defined WIT interfaces, sandbox isolation and automated safety evidence generation — all integral parts of the OSxCAR platform.

→ SDV Platform

The WebAssembly sandboxes are designed for ASIL qualification up to ASIL D and address the requirements of ISO 26262 (functional safety) and ISO/SAE 21434 (cybersecurity). Qualification proceeds incrementally: automated generation of safety evidence is part of the platform roadmap.

→ SDV Platform

OSxCAR supports step-by-step validation ranging from pure software testing to fleet operation:

• SIL (Software-in-the-Loop) — Purely software-based validation before hardware is available. Fast iteration, high scenario coverage.
• HIL (Hardware-in-the-Loop) — Real ECUs combined with simulated environment. Real hardware validation with reproducible conditions.
• Shadow Mode (A/B Testing) — New features run parallel to production logic in the vehicle: They receive real data, produce comparison outputs, but do not intervene in control.

Stage progression: SIL → HIL → Shadow Mode → Production — each stage builds on the previous one. This enables fleet-scale A/B testing as a bridge between lab and real vehicle operation.

→ SDV Platform · Testbench

• Cost reduction — Up to 50% savings through software reuse with the “One Binary” approach
• Faster time-to-market — Feature rollouts in weeks instead of months through Dynamic Homologation
• CO₂ reduction — Up to 20% through AI optimization and more efficient software execution
• Quality improvement — Mutation Testing (RapidTest) + structured interfaces (WASI/WIT)
• Scalability — From MIL/SIL through HIL/VIL to production with one binary

Yes — the Anti-Pinch protection runs as an interactive demo directly in the browser. Three WebAssembly components (written in Rust, connected via WIT) control a realistic window lift simulation — with exactly the same binaries intended for deployment on ECUs.

Additional demonstrators:

• Adaptive AUTOSAR + Rust/Wasm — Rust and C++ components interoperate via WIT
• Hardware-Agnostic Demo — Same components on Bare Metal, Zephyr, Linux, VxWorks and QNX

→ Interactive demo · All demonstrators

For suppliers / Tier-1:

• “Same Binary” eliminates OEM-specific porting → faster validation, lower certification costs
• One single software package for all customers instead of individual platform variants

For system integrators:

• Unified integration from MIL to vehicle with WIT + Wasm as consistent interface basis
• Fewer bench variants, parallel use by distributed teams

→ Use cases

OSxCAR is funded through the EFRE/JTF NRW – NeueWege.IN.NRW program. Project coordinator: Projektträger Jülich (PTJ). Total funding amounts to 5 million euros over a duration of June 2024 to May 2027.

→ Funding

• Interactive demo to try: Anti-Pinch WebAssembly Demo
• Contact for questions and inquiries: Contact
• Publications and conference contributions: Publications