In-Vehicle Infotainment: Enhancing the Driving Experience

Modern vehicles are software platforms as much as they are mechanical ones. The infotainment stack sitting behind the centre console is one of the most complex embedded systems in a production car today, and getting it right involves trade-offs that touch hardware selection, OS architecture, connectivity standards, and safety certification.

What Does a Modern IVI Stack Actually Look Like?

At the core, an in-vehicle infotainment (IVI) system is a real-time embedded platform running a combination of a hypervisor, one or more guest operating systems, and a middleware layer that brokers communication between applications and the vehicle's CAN/LIN/Ethernet network.

The dominant OS choices are Android Automotive OS (AAOS), QNX Neutrino, and Linux-based stacks built on Yocto/AGL (Automotive Grade Linux). Each makes a different bet.

OS	Licensing	Safety cert	App ecosystem	Typical OEM fit
Android Automotive OS	Open-source (Apache 2.0)	None natively	Google Play for Cars	Mass-market, Google integration priority
QNX Neutrino 7.1	Proprietary	ISO 26262 ASIL D capable	Limited, OEM-built	Premium, safety-critical clusters
AGL (Yocto-based)	Open-source	Partial, depends on config	OEM + community	Tier-1 suppliers building custom stacks

AAOS is not Android for phones ported to a car. It drops the Google Mobile Services layer and replaces it with vehicle-aware APIs: CarPropertyManager, CarAudioManager, and the Vehicle HAL that sits between the OS and the ECU network. OEMs can ship without Google services entirely.

Hypervisor Use

Most Tier-1 hardware today runs a Type-1 hypervisor (Green Hills INTEGRITY Multivisor or Mentor Automotive's Hypervisor are common) to isolate the safety-critical instrument cluster domain from the infotainment domain. AUTOSAR Adaptive Platform handles the safety partition; QNX or AGL handles media and navigation. The partition boundary is enforced in hardware via IOMMU, and the inter-VM communication is typically done over shared memory with a secure channel defined in AUTOSAR's SoAd or SOME/IP.

How Is Vehicle Data Exposed to Infotainment Applications?

This is where a lot of IVI projects run into trouble. The vehicle's sensor and actuator data lives on CAN FD or Automotive Ethernet (100BASE-T1, 1000BASE-T1) networks. The infotainment stack needs read access to some of that data (speed for navigation, door status for UI state) but must not be able to write into safety-critical nodes.

COVESA's Vehicle Signal Specification (VSS) has become the practical standard for abstracting this. VSS defines a tree of signals (Vehicle.Speed, Vehicle.Powertrain.FuelLevel, etc.) and the W3C VISS (Vehicle Information Service Specification) v2.0 protocol exposes them over WebSocket and REST to in-vehicle apps. This gives application developers a clean, hardware-agnostic API while the gateway ECU enforces access control at the signal level.

The alternative is going direct to the CAN DBC file. This works, but it ties your application code to a specific wiring harness. Any revision to the DBC breaks the app. VSS/VISS avoids that coupling.

Over-the-Air Updates

OTA for IVI involves two separate pipelines. The first is full OS image updates, handled by UPTANE-compliant update managers (e.g., HERE OTA Connect, or open-source Aktualizr). The second is application-layer updates, which in an AAOS system can follow a standard APK delivery pipeline scoped to the vehicle's headunit.

UPTANE is worth the complexity. It protects against a compromised update server by requiring metadata from both the image repository and a separate director repository before a client accepts an image. Without it, you're one compromised CDN away from a fleet-wide brick event.

What Does Android Automotive OS Actually Give You Over a Custom Linux Build?

Faster time-to-market, mainly. The CarPropertyManager API, the PermissionController for vehicle permissions, and the Media session framework are already written and tested. You're not rebuilding the Bluetooth HFP stack or the USB audio routing logic.

The cost is opacity. When something breaks in the Vehicle HAL or in the audio policy engine, you're debugging inside a large, partially documented codebase. Google's Car UI Library enforces certain UI patterns that OEMs sometimes fight against. And the Google services dependency, even in the reduced AAOS form, is a non-starter for OEMs in markets with regulatory restrictions on Google.

AGL gives you more control and is genuinely well-maintained. The AGL SPEC (Specification for Automotive Linux) is now at version 13. The downside is that your application framework is Wayland/weston-based and you'll build more middleware from scratch. Developer tooling is less polished than AAOS.

For an OEM building a premium product with a strong in-house software team, AGL is defensible. For a startup building a connected aftermarket headunit, AAOS is almost always the right call.

Connectivity: Balancing Cellular, Wi-Fi, and V2X

A production IVI system typically manages four radio domains simultaneously: cellular (4G LTE or 5G Sub-6GHz), Wi-Fi 6 (802.11ax) for tethering and parking-area connectivity, Bluetooth 5.x for hands-free and audio profiles, and DSRC or C-V2X for vehicle-to-infrastructure communication.

Qualcomm's SA8155P and SA8295P are the SoCs that power most premium IVI systems shipping today. The SA8295P supports 5G, Wi-Fi 6E, and has dedicated DSPs for active noise cancellation and acoustic echo removal, which matters more than it sounds when you're doing voice recognition in a moving vehicle at 100 km/h with road noise.

C-V2X (Cellular V2X, 3GPP Release 14 and later) is gaining over DSRC/802.11p in most new deployments because it reuses the cellular modem infrastructure and has a longer range for direct mode (PC5 interface) than 802.11p in real-world tests. The US NHTSA's 2023 position moved toward C-V2X, which effectively signals the direction for North American OEMs.

Security Is Not a Bolt-On

The threat surface on an IVI system is large. It has a cellular modem (remote attack surface), a Bluetooth stack (proximity attack surface), USB ports (physical attack surface), and it sits on a network shared with the powertrain ECUs.

UN Regulation No. 155 (UNECE WP.29) now mandates cybersecurity management systems for vehicle type approvals in the EU, Japan, and Korea. ISO/SAE 21434 defines the engineering process. Practically, this means threat analysis and risk assessment (TARA) must be documented for every interface, and penetration testing is expected before homologation.

At the implementation level: secure boot using a hardware root of trust (TPM 2.0 or an OEM-specific HSM), signed OTA manifests, and MAC (Mandatory Access Control) via SELinux or SMACK on Linux-based stacks. SMACK is simpler to configure than SELinux for resource-constrained embedded environments and is what AGL defaults to.

Conclusion

IVI is a genuine systems engineering problem. The OS choice, the vehicle data abstraction layer, the OTA pipeline, the connectivity stack, and the security architecture all interact. Getting one wrong creates debt that compounds fast once you're at production scale.

If you're at the point of scoping an IVI programme, the first concrete step is a signal access audit: map every vehicle signal your infotainment application actually needs, validate that your gateway ECU can enforce read-only access to those signals, and build your VSS tree from that list. Everything else flows from knowing exactly what data you need and what you must not touch.

---

FAQ

What is the difference between Android Auto and Android Automotive OS? Android Auto runs on a user's phone and mirrors to the car's display. Android Automotive OS runs directly on the vehicle's headunit hardware with no phone required. They share some UI conventions but are entirely different software stacks with different APIs and deployment models.

Is QNX required for ISO 26262 compliance? No. QNX Neutrino is certified to ASIL D, which simplifies the path to compliance, but it is not the only route. Linux can be used in a mixed-criticality architecture where the safety partition runs on a separately certified RTOS and Linux handles the non-safety infotainment domain. The hypervisor isolation has to be demonstrably sufficient.

How long does an OTA update take for a full IVI image? Typical full OS images for an IVI headunit are between 2 GB and 8 GB compressed. On an LTE connection with delta updates (binary diffs using tools like bsdiff or casync), most production systems can deliver incremental updates in under 15 minutes in the background. Full image swaps take longer and are usually scheduled for parking events.

What does UNECE WP.29 Regulation 155 require in practice? It requires OEMs and their supply chain to operate a certified Cybersecurity Management System (CSMS) covering the full vehicle lifecycle, from design through decommission. For IVI specifically, this means documented TARA for every external interface, defined incident response processes, and the ability to push security patches post-sale via OTA.

Can aftermarket IVI units connect to a vehicle's CAN bus safely? Technically yes, but the access model is different from OEM-integrated systems. Aftermarket units typically use OBD-II (ISO 15765-4) for read access to a limited set of signals. They generally cannot access body or chassis CAN segments without a proprietary gateway bypass, which voids safety assumptions. For a production product, this is a significant constraint to understand early.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.