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."

  • Rust
  • C++
  • x86 · ARM · RISC-V
  • Sandbox
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

Evolution Stages

From browser runtime through the first server standards to the modular vehicle interface – WebAssembly evolved into a universal execution environment over ten years.

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.

OSxCAR Extensions

Within OSxCAR, extensions were developed that enable the combination of WIT interfaces with system-specific optimizations:

  • WIT + Hardware Optimization: Combining type-safe interfaces with platform-specific accelerators – without sacrificing portability or security boundaries
  • Zero-Copy Camera Pipeline: Extension for camera-based driver assistance systems – eliminates memory copies on the path from camera to ADAS module, reducing latency and overhead directly
  • OSxCAR
  • WIT
  • Zero-Copy
  • ADAS

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