Skip to content

Automotive Grade Linux & In-Vehicle Infotainment

Last updated: 2026-04-11

Recent Finds

Mixed-Criticality IVI Demo at Embedded World 2026: Android + Safety Linux on Same SoC (April 7, 2026)

Kernkonzept, Telechips, and Elektrobit demonstrated a production-oriented cockpit at Embedded World 2026 running Android infotainment and EB corbos Linux for Safety Applications in strict isolation on the same Telechips Dolphin5 SoC (Arm automotive CPU + Mali-G78AE GPU). Kernkonzept's L4Re hypervisor handles hardware-assisted GPU virtualization between the safety and non-safety VMs — each gets isolated GPU time slices without shared memory channels that could violate ASIL-B separation. This is the supply-chain proof that the SoDeV architecture works on shipping silicon: Tier-1 middleware (Elektrobit), hypervisor (Kernkonzept), and SoC (Telechips) are all production-ready for consolidated cockpit domains. Key implication: the "one SoC for instrument cluster + IVI" design that AGL SoDeV targets is no longer theoretical — it was demoed in hardware at Embedded World April 2026.

AGL Launches SoDeV: Open Source Software-Defined Vehicle Reference Platform (Linux Foundation, Dec 2025)

AGL's biggest announcement in years: SoDeV (Software Defined Vehicle) is a full SDV reference implementation led by Honda and Panasonic Automotive Systems, combining the AGL Unified Code Base (UCB) with VirtIO, Xen hypervisor, Linux Containers, Zephyr RTOS, and ELISA (safety-critical Linux). The SDV pivot means AGL is no longer just an IVI platform — it is positioning for ECU consolidation: multiple vehicle domains running as virtual machines on a single high-compute SoC. VirtIO provides a hardware-abstraction interface so software can be developed and tested on cloud processors or virtual environments before porting to automotive SoCs (Renesas, NXP, Qualcomm). Available early 2026 for virtual environments; automotive SoC target later in 2026. Contributors include Toyota, Mazda, AISIN, Renesas.

FPT Software Joins Automotive Grade Linux and the Linux Foundation

FPT Software's entry into the AGL ecosystem signals continued momentum for standardized embedded Linux in automotive. AGL is now a Linux Foundation project with Toyota, Panasonic, Renesas, and major Tier 1 suppliers. FPT's focus is connected vehicle development — over-the-air (OTA) updates, telematics, and cloud-to-car APIs. Shows the supply chain is building AGL expertise beyond traditional automotive ECU suppliers.

Toyota's Linux Journey (It's FOSS)

Toyota committed fully to AGL for IVI across all Toyota and Lexus vehicles globally — a landmark OEM decision that validated AGL over proprietary IVI stacks. The article traces Toyota's transition from QNX-based systems through GENIVI to AGL, and explains why standardization reduces per-model software cost by sharing a common middleware stack. AGL competes directly with Android Automotive OS (used by GM, Volvo, Polestar) and Apple CarPlay-integrated RTOS solutions.

AGL Software Architecture for Automotive Infotainment (Semantic Scholar)

Five-layer AGL architecture: App/HMI → Application Framework → Services → OS → Hardware. The framework layer (Wayland/Weston compositor, AGL Application Framework with security policies, WebKit for web-based HMI) sits above a hardened Linux kernel with Yocto Project build system. Integration with AUTOSAR-compliant ECUs occurs via CAN bus, LIN, and Automotive Ethernet (AVB/TSN). Key design principle: safety-critical functions remain on dedicated microcontrollers; the Linux IVI domain is isolated.

Core Concepts

AGL Architecture

┌─────────────────────────────────────┐
│   HMI Apps (Qt, HTML5/WebKit, EGL)  │  ← App Layer
├─────────────────────────────────────┤
│  AGL App Framework (security, APIs) │  ← Framework
├─────────────────────────────────────┤
│  Services (audio, BT, navigation,   │  ← Services
│  vehicle signals, telephony)        │
├─────────────────────────────────────┤
│  Linux Kernel + Yocto BSP           │  ← OS
├─────────────────────────────────────┤
│  SoC Hardware (Renesas R-Car, etc.) │  ← Hardware
└─────────────────────────────────────┘
         ↕ CAN / Ethernet AVB
┌─────────────────────────────────────┐
│  AUTOSAR ECUs (powertrain, ADAS)    │
└─────────────────────────────────────┘

Key Technologies

  • Yocto Project: Build system producing custom Linux distros for embedded targets. AGL uses Yocto layers to support multiple SoC families (Renesas R-Car, NXP i.MX8, Qualcomm SA8155P).
  • Wayland/Weston: Display server replacing X11 in automotive. Compositor enforces HMI policies (instrument cluster overlay priority, ADAS camera feeds cannot be occluded).
  • KUKSA.val / VSS: Vehicle Signal Specification — standardized API for accessing vehicle data (speed, fuel level, ADAS status) from the Linux domain.
  • SOME/IP + DDS: Service-oriented middleware for intra-ECU and inter-domain communication on Automotive Ethernet.
  • Automotive Ethernet (BroadR-Reach / 100BASE-T1, 1000BASE-T1): Unshielded, single-pair Ethernet replacing CAN for high-bandwidth domains (cameras, displays, LiDAR).

AUTOSAR Integration

  • Classic AUTOSAR: RTOS-based, for safety-critical ECUs (powertrain, brakes, airbags). MISRA C compliance, functional safety (ISO 26262 ASIL-D).
  • Adaptive AUTOSAR (AP): POSIX-compliant, C++14, for high-compute domains (ADAS, autonomous driving). Runs on Linux or QNX.
  • Integration point: AGL IVI communicates with Classic AUTOSAR ECUs via gateway ECUs translating CAN ↔ Ethernet.

Competitive Landscape (IVI Platforms, 2026)

Platform Backing Key Users Notes
AGL Linux Foundation Toyota, Suzuki, Mazda Open source, Yocto-based
Android Automotive OS Google GM, Volvo, Polestar, BMW Full Google Play, GAS licensed
BlackBerry QNX Blackberry/QNX Many OEMs (safety OS) POSIX RTOS, ASIL-D capable
Elektrobit (EB) Continental BMW, VW Group Commercial, AUTOSAR stack
GENIVI Defunct → AGL — Merged into AGL ecosystem

Functional Safety (ISO 26262)

  • ASIL-A through ASIL-D: Automotive Safety Integrity Levels based on severity × exposure × controllability.
  • IVI systems typically ASIL-A or QM (no safety requirement) — but must not interfere with ASIL-D systems.
  • Hardware/software partitioning ensures Linux domain cannot cause safety-critical failures.

Open Questions

  • Will Android Automotive OS eventually dominate due to Google's app ecosystem, or will OEMs resist data dependency?
  • How does Adaptive AUTOSAR over Linux compare to AGL for the ADAS domain — are they converging?
  • What is the long-term strategy for OTA security on AGL systems (signed updates, rollback, key management)?
  • How does AGL handle mixed-criticality scheduling when instrument cluster and IVI share the same SoC?
  • SoDeV uses Xen for hypervisor-based isolation — how does this compare to AUTOSAR AP's approach to domain isolation? Is Xen safety-certifiable to ISO 26262 ASIL-B/D?
  • Will Zephyr RTOS within SoDeV become the AGL-standard approach for safety-critical bare-metal ECU functions co-existing on the same silicon?