Software-Defined Vehicle Platform

Open SDV platform for standardized, secure and flexible vehicle architectures with dynamic homologation

The Software Defined Vehicle Platform provides a unified, open, and hardware-independent foundation for modern vehicle software. It combines secure, modular software components with a standardized execution environment – reproducible, portable, and updatable throughout the entire lifecycle.

Through open interfaces, isolated runtime environments, integrated shadow mode validation, and formal safety mechanisms, the platform becomes the foundation for scalable, cross-manufacturer SDV architectures.

Open & Standardized

Wasm Component Model, language-independent WIT interfaces, consistent interoperability.

Secure & Isolated

Sandbox runtime, Freedom from Interference, automated safety evidence up to ASIL D.

Hardware Agnostic

x86, ARM, RISC-V, GPU, FPGA – identical binaries from simulation to the vehicle.

Dynamically Certifiable

Component-level homologation, selective OTA updates, shorter release cycles.

From Domains to Central Computers

The vehicle’s E/E architecture is evolving from decentralized domain ECUs through zonal controllers to central high-performance computers. The OSxCAR platform supports every stage of this evolution – and enables mixed operation of classic and SDV-based components.

“One platform for all generations – from legacy ECUs to L3+ central computers.”

Illustrated timeline of E/E architecture evolution: On the left, decentralized domain ECUs for Powertrain, Chassis, and Body; in the center, regionally grouped zone controllers with reduced wiring harnesses; on the right, a central high-performance computer for L3+ autonomy. Arrows indicate the direction of development from left to right.
SDV Architecture Evolution

01 – Open & Standardized Architecture

The platform is built on open standards such as the WebAssembly Component Model and language-independent interfaces (WIT). This creates consistent interoperability between software building blocks – regardless of programming language, operating system, or hardware.

Components can be freely combined, versioned, reused, or replaced, reducing integration costs and accelerating innovation.

Why Open Standards?
Proprietary stacks create dependencies. WIT + Component Model decouple manufacturer, language, and platform – every component becomes exchangeable, every interface versionable.
  • Component Model
  • WIT
  • Language-Independent
  • Versionable
  • Interoperable

02 – Secure, Isolated Execution

Memory-safe runtime environments and sandbox mechanisms ensure that components run strictly isolated from one another (Freedom from Interference). This enables the secure execution of both safety-critical functions and experimental or AI-based modules – without endangering the overall system.

  • Memory Safety: No uncontrolled access between modules – capability-based isolation
  • Fault Isolation: A module crash remains locally contained, the overall system keeps running
  • Safety Evidence: Automated evidence generation for certification processes up to ASIL D
  • Formal Verification: Planned mechanisms from component to overall system

Isolation as a Safety Principle

Each component runs in its own sandbox with minimal permissions. Memory access, system calls, and communication channels are strictly controlled – a fault in Module A can never affect Module B.

“Freedom from Interference – not as a concept, but as a runtime guarantee.”

Technical illustration on a dark navy background: Three glowing translucent cubes stand side by side, symbolizing isolated software sandboxes. Each cube contains a different symbol – gear, shield, code brackets. Thin connecting lines between the cubes show controlled, strictly limited communication channels.
Capability-based Sandbox Isolation

03 – Flexible & Hardware Agnostic

The platform supports all relevant compute architectures – x86, ARM, RISC-V, MCUs, GPUs, FPGAs, and domain-specific accelerators.

Thanks to the “One Binary” approach, identical software modules run across all validation stages:

  • MIL / SIL: Early validation purely in simulation – without hardware
  • HIL: Real ECUs with simulated signals – real timing, controlled environment
  • VIL: Integration in the vehicle context – physical interfaces, real bus systems
  • On-Vehicle: Identical code in the target vehicle – developed once, runs everywhere
One Binary – Zero Porting: The same compiled component passes through simulation, test bench, and vehicle. No recompile, no platform-specific glue code, zero porting effort.

One Binary – All Platforms

Whether x86 server, ARM-based zone controller, or RISC-V microcontroller – the compiled Wasm component remains identical. No recompile, no platform-specific glue code.

“Developed once, runnable everywhere – from simulation to test bench to vehicle.”

  • x86
  • ARM
  • RISC-V
  • GPU
  • FPGA
Schematic illustration on a dark navy background: Five processor chip icons in a horizontal row represent different architectures (x86, ARM, RISC-V, GPU, FPGA). Above them, a single translucent abstraction layer connects all five chips with glowing horizontal lines, visualizing the One Binary principle.
Heterogeneous Compute Architecture

04 – Dynamic Homologation

Instead of recertifying the entire vehicle software, individual components can be selectively updated and reassessed. Dynamic homologation thus becomes the key to SDV lifecycles.

  • Selective: Only changed components are reassessed – the rest remains certified
  • Fast: Feature rollouts in weeks instead of months
  • Efficient: Lower certification costs per release cycle
  • Flexible: Low-risk OTA updates and continuous architecture evolution

From Monolith to Module

Classic homologation requires recertification of the entire system with every change. Dynamic homologation breaks this process apart: only the actually changed component is reassessed – the rest remains certified.

“Component-level certification enables feature rollouts in weeks instead of months.”

Side-by-side comparison of two certification approaches: On the left, a massive monolithic block with a red prohibition sign symbolizing full-system recertification. On the right, a set of modular interlocking puzzle pieces with green checkmarks representing selective component certification. A diagonal arrow shows the transformation from left to right.
Monolithic vs. Component-Level Certification

05 – Shadow Mode – In-Vehicle Validation

New features run in parallel with production logic, receiving real vehicle data and generating comparison outputs without interfering with vehicle functions. Shadow Mode bridges the gap between lab tests and the real vehicle world.

  • Fleet Validation: Testing under real conditions across thousands of vehicles
  • A/B Testing: Risk-free comparison of new algorithms against production logic
  • Data-Driven Optimization: Real driving data as the basis for iterative improvement
  • OTA Preparation: Secure validation before productive rollout
From Bench to Vehicle: Shadow Mode complements test bench validation: What works on the SDVA Test Bench is finally assured in Shadow Mode under real fleet conditions – without production risk.

From Lab to Fleet

What works on the SDVA Test Bench is finally assured in Shadow Mode under real fleet conditions. New algorithms run in parallel with production – risk-free validation across thousands of vehicles before a single OTA update goes live.

“Feature rollouts in weeks instead of months – selectively updated, component-level certified.”

Technical illustration of two vehicles in motion on parallel lanes: The left vehicle is rendered as a solid, complete model representing the vehicle software in production. The right vehicle appears as a transparent wireframe model – visualizing the Shadow Mode: a parallel software layer that observes real vehicle behavior without interfering with any vehicle functions.
Shadow Mode – Risk-Free Fleet Validation

06 – Roadmap – Future Extensions

The platform’s further development focuses on five priorities:

Safety Formal Proof Towards ASIL D

Introduction of formal methods and automated safety analysis for the highest safety requirements. The goal is end-to-end, tool-supported evidence generation from component level to the overall system – as the basis for certification of safety-critical SDV functions.

  • ASIL D
  • Formal Verification
  • ISO 26262
Testing ReSim + End-to-End Test Framework for ADAS

End-to-end evaluation of complex ADAS systems from simulation to driving operation. Re-simulation enables the replay of real scenarios in a controlled environment – for reproducible, scalable validation.

  • ReSim
  • ADAS
  • End-to-End
Deployment Fleet-Ready OTA Path

Signed, versioned, and modular OTA updates for scalable SDV fleets. Component-level updates instead of monolithic releases – with integrated rollback, audit trail, and dynamic homologation.

  • OTA
  • Signed
  • Rollback
  • Fleet Scaling
AI AI-Optimized Networking

GNN-based optimization of latency, path selection, and software placement in heterogeneous vehicle networks. Trained on real bench data, validated in Shadow Mode.

  • GNN
  • Latency Optimization
  • Software Placement
Outlook WebAssembly Proof of Concept

Demonstration of a fully portable, secure, and OEM-agnostic execution environment based on the WebAssembly Component Model. Proof of practical viability for automotive use cases.

  • Wasm
  • Component Model
  • POC

Fleet Updates, Not Solo Missions

Signed, versioned OTA packages reach thousands of vehicles simultaneously. Component-level updates instead of monolithic releases – with integrated rollback, audit trail, and dynamic homologation as safeguards.

“From cloud build to vehicle – continuously signed, versioned, and traceable.”

Minimalist illustration on a dark navy background: A stylized cloud at the top sends narrow beams of light downward to five abstract vehicle silhouettes. Each vehicle shows a circular progress indicator at a different fill level, illustrating a staggered OTA rollout across a fleet.
Fleet-Ready OTA Deployment

Suitable for Every E/E Architecture

Whether legacy domain architecture, zonal topology, or central high-performance computers – the platform flexibly adapts to every vehicle generation and enables mixed operation of classic and SDV-based components.

Legacy Domains

Decentralized ECUs separated by function: Powertrain, Chassis, Infotainment. Proven, widely deployed – the platform integrates seamlessly.

Zone Controllers

Regionally grouped controllers by vehicle area. Reduced wiring, higher efficiency – the transition to software-defined architecture.

Central Computers

Highly integrated platforms for L3+ autonomy. All functions centralized, maximum computing power – the future of E/E architecture.

In Brief

The SDV platform creates a foundation where:

  • Modularity: Software is secure, reusable, and independently combinable
  • Portability: Hardware is no longer a barrier – one binary for all target platforms
  • Agility: Homologation works dynamically and at the component level
  • Intelligence: AI and ReSim are directly integrated into development and validation
  • Speed: OTA, Shadow Mode, and safety automation drastically shorten release cycles

A modern, open foundation for the next-generation Software Defined Vehicle.

More Technology Pages: Artificial Intelligence · WebAssembly · Test Platform