One SoC. Two worlds. Zero compromise: How Red Hat In-Vehicle Operating System and DXC AMBER come together in a mixed-criticality software-defined vehicle solution

At ELIV 2026 in Baden-Baden, Red Hat and DXC are showcasing a software-defined vehicle (SDV) platform that brings together AD/ADAS and digital cockpit workloads on a single high-performance compute platform, with Red Hat In-Vehicle Operating System providing an ISO 26262 ASIL-B certified Linux foundation for the safety-relevant software domain.

The automotive industry has been exploring ADAS and IVI convergence for years. In collaboration with DXC, we are showcasing a production-grade implementation, running Android Automotive OS, an ASIL-B instrument cluster and AD/ADAS applications side by side on a single Qualcomm Snapdragon Ride Flex SA8775P, part of Qualcomm's Snapdragon Ride Flex family, which is designed to simultaneously support digital cockpit and ADAS workloads.

The key building blocks are Red Hat In-Vehicle Operating System at the heart of the safety-critical software domain and DXC’s AMBER middleware, communication and hardware enablement framework, providing the cross-domain SDV platform integration layer. A Type 1 hypervisor provides isolation between the Android and Red Hat In-Vehicle Operating System software domains, while the SoC’s ASIL-D safety island and an Infineon AURIX companion MCU provide additional safety and vehicle-interface capabilities.

A hybrid system architecture: hardware and OS-level isolation

The joint architecture combines hardware-level with OS-level isolation. A Type 1 hypervisor serves as the underlying partitioning mechanism that separates Android Automotive OS (AAOS) and Red Hat In-Vehicle Operating System into dedicated virtual machines (VMs), while containerization within Red Hat In-Vehicle Operating System provides isolation between safety-critical subsystems such as ADAS and the instrument cluster. In this implementation, running AAOS in its own VM also provides a complete, isolated Android environment aligned with the Google-compliant target configuration.

The following is a simplified view of the overall high-performance software environment, without the safety island and vehicle interface processor.

Figure 1. Overall Software Architecture, High-Performance Part

Safety workloads run in containers on safe Linux

Instead of running a separate VM for each safety-relevant domain, Red Hat In-Vehicle Operating System serves as a common host for the safety-relevant workloads in the DXC implementation. Linux-native isolation mechanisms provide temporal, spatial and resource isolation capabilities. For this forward-looking demo architecture, the ADAS/ACC application and the DXC AMBER instrument cluster, both targeted as ASIL-B workloads, run in separate containers within the same Red Hat In-Vehicle Operating System environment.

Android Automotive OS runs in its own virtual machine

Android Automotive OS runs in another dedicated VM, bringing its own kernel with specific features such as Binder IPC, Bionic C library, and its own service manager, HAL and graphics stack. This approach provides a clear separation from the safety-critical domain and complies with Google’s AAOS target configuration. It allows the Android environment to be integrated without being constrained through the underlying platform architecture. Deploying AAOS in this native way helps maintain performance of the infotainment system, while the Red Hat In-Vehicle Operating System VM remains focused on the safety-relevant and potentially other workloads.

The core ingredients: DXC AMBER and Red Hat In-Vehicle Operating System

DXC AMBER: The software-defined platform layer

DXC AMBER is DXC’s modular product layer built across the different automotive domains. It implements a hardware and hypervisor-agnostic SDV platform with full source-code transparency, customizable and portable to various hardware platforms. Launched at CES 2026, it is currently being deployed to production programs. Three core assets carry this platform:

• Cross-domain middleware: The underlying platform backbone across IVI, ADAS, cluster and real-time domains. It supports safe and secure inter-VM communication, network communication, diagnostics orchestration, software update and other cross-domain services such as power and state management, logging and health management, all in a SoC-agnostic and safety-compliant way.
• AAOS IVI stack: A pre-integrated Android Automotive OS stack including DXC enhancements, app store and OTA updates, running in its own VM on a Type 1 hypervisor.
• Digital instrument cluster: A high-performance UI engine with a safety-grade rendering layer for predictable real-time behaviour, together with a powerful toolchain and exemplary cluster designs, deployed as an ASIL-B container on Red Hat In-Vehicle Operating System.

Red Hat In-Vehicle Operating System: The safety-certified OS layer

At the core of the safety domain sits Red Hat In-Vehicle Operating System, a production-grade, open-source Linux platform certified as a Safety Element out of Context (SEooC) against ISO 26262 ASIL-B. Its current safety certificate includes a mixed-criticality claim, allowing safety-critical applications up to ASIL-B and quality-managed (QM) workloads to share a single ASIL-qualified Linux kernel. Linux-native isolation mechanisms and specialized configurations provide freedom from interference between the safety-critical and QM environments, reducing the need for separate guest operating systems and the associated virtualization overhead.

The architecture presented here takes this concept a step further as a forward-looking direction. It envisions the ADAS/ACC application and instrument cluster, both ASIL-B, running as separate containers within the same Red Hat In-Vehicle Operating System environment.

Figure 2. Red Hat and DXC in booth at ELIV