WebAssembly

Platform-independent software for the Software-Defined Vehicle – components, interfaces, runtimes and quality assurance.

WebAssembly was developed to run complex programs portably and securely – originally in the browser, today on servers, embedded systems, and in the vehicle. Key for OSxCAR: a single compiled binary runs unchanged on x86, ARM, and RISC-V – from simulation to the target ECU.

One Binary – All Architectures

Source code in Rust, C++, or Go is compiled once into a Wasm binary. That binary runs unchanged on any target system – regardless of processor architecture or operating system. No re-compile, no platform-specific glue code.

"Compiled once, runs everywhere – from simulation to in-vehicle deployment."

Schematic diagram on a dark navy background: Three source code icons (Rust, C++, Go) on the left feed into a central glowing Wasm hexagon icon via luminous connecting lines. From there three lines lead right to chip icons representing x86, ARM, and RISC-V – visualizing the WebAssembly one-binary principle.
Wasm compilation and deployment path

What does OSxCAR do with WebAssembly?

The WebAssembly Component Model provides the foundation – but the standard alone is not enough for in-vehicle use. OSxCAR extends Wasm with automotive-specific capabilities that are validated directly on the Testbench and deployed via the SDV Platform.

WIT Interfaces with Hardware Optimisation

WIT defines type-safe interfaces between Wasm components – language-agnostic and portable. OSxCAR combines these standardised interfaces with platform-specific accelerators: a component can use SIMD instructions or GPU offloading, for example, without changing the WIT interface or deployment process.

The result: application code stays portable, but runs at peak performance on every target system. AI-driven optimisation automatically decides which accelerators to activate on which hardware.

Visualisation of the connection between WebAssembly modules and hardware accelerators
WIT interfaces with hardware-specific optimisation

Zero-Copy Camera Pipeline

Camera-based driver assistance systems process high-resolution image data in real time. Normally, this data is copied multiple times in memory on the way from the camera to the ADAS module – each copy costs latency and energy.

OSxCAR extends the Wasm runtime with a zero-copy interface: image data flows directly from the camera driver into the Wasm sandbox without intermediate copies. Sandbox security is maintained – access is read-only and is automatically revoked on component switch.

"Camera data straight into the sandbox – no copy, no security trade-off."

Diagram of the zero-copy pipeline: camera data flows without intermediate copies directly into the ADAS Wasm module
Zero-copy path: Camera → Wasm Sandbox → ADAS Module

Security Model: Isolation & Attestation

Every Wasm module runs in its own sandbox – with strictly limited access to memory, network, and peripherals. The capability-based security model grants each module only the permissions it needs at runtime. A faulty or compromised module cannot affect other components.

For OTA updates of safety-critical functions, OSxCAR employs cryptographic module attestation: each module's signature is verified before execution – tampered binaries are detected and rejected before they can cause harm.

"Every module isolated, every update signed – safe updates even for brakes and steering."

Visualisation of sandbox isolation: Wasm modules in separate security domains with controlled interfaces
Capability-based isolation at module level

AUTOSAR Integration: From Monolith to Module

Most existing vehicle software is developed within the AUTOSAR ecosystem. A complete switch to WebAssembly would be unrealistic – so OSxCAR enables gradual migration:

  • 🔹 Standardised bridge: WASI 0.3 (Async & Streams) allows AUTOSAR interfaces to be modelled as WIT interfaces – Wasm modules communicate directly with the existing stack
  • 🔹 Incremental modularisation: Individual AUTOSAR software components are progressively migrated into Wasm modules – without destabilising the overall system
  • 🔹 Backward compatible: Legacy code continues to run unchanged; new modules immediately benefit from portability and sandbox security
  • 🔹 Result: Less migration disruption, faster acceptance in established processes and certification paths

In a nutshell

WebAssembly provides the portable binary format, the WIT Component Model the modular interfaces – and OSxCAR adds what is missing for automotive deployment: hardware optimisation without sacrificing portability, and latency-free data paths for safety-critical sensors.

  • 🔹 Platform: The SDV Platform uses Wasm components as its deployment unit – one binary for all ECUs
  • 🔹 AI: AI-driven optimisation decides which Wasm modules run on which hardware and which accelerators are activated
  • 🔹 Testbench: The SDVA Testbench executes Wasm components on heterogeneous hardware – identical binaries as in the target vehicle

Evolution Stages

2015
Browser Support (Emscripten)

All major browsers support WebAssembly – this platform is often named after its compiler "Emscripten." All interactions with the world outside the WebAssembly sandbox take place via JavaScript functions called from WebAssembly.

2017
Specification 1.0

The first official WebAssembly specification lays the foundation for a portable, secure binary format – adopted by the W3C as an open standard.

2019
WASI Preview 1 (wasip1)

WebAssembly abstracts the processor – but a running system also requires an operating system. WASI standardizes the interface between program and OS, e.g. to query the current time or read files. This allows WebAssembly to run on servers for the first time. However, wasip1 is not modular and strongly oriented towards POSIX – less suitable for smaller microcontrollers and only extensible with considerable effort.

2022
Specification 2.0

Additional instructions: vector and fast memory fill instructions (SIMD, Bulk Memory) as well as multiple return values for program sections – significant performance boost for compute-intensive applications.

2024
WASI 0.2 – Component Model

Standardizes the interface description language WIT, enabling the definition of additional interfaces. Complex data types can be exchanged between programming languages. The modular design significantly simplifies porting to microcontrollers – the foundation for automotive use.

2025
Specification 3.0

64-bit support, multiple memory regions, support for objects outside linear memory (Garbage Collection), efficient calls at the end of a function (Tail Calls), and exception handling.

2026
WASI 0.3 – Async & Streams

Enables data streams, asynchronous calls, and results. This is particularly useful for modeling AUTOSAR interfaces more easily – an important step for integration into existing automotive stacks.

More on the history of WebAssembly on the ByteCodeAlliance website.

More Technology Pages: SDV Platform · Artificial Intelligence · Test Platform · FAQ · Glossary