The In-Vehicle Infotainment system is the interface through which the occupant experiences the digital half of the vehicle. Navigation, music, phone calls, vehicle settings, ADAS camera feeds, climate control HMI, and increasingly, app ecosystems, voice assistants, and streaming services all converge on the IVI display. For most drivers, the quality of the IVI system is one of the most tangible differentiators between vehicles in the same segment.
The engineering challenge behind this experience is formidable. The IVI ECU must simultaneously run a sophisticated operating system capable of handling rich multimedia and third-party applications, maintain seamless connectivity with the driver's smartphone ecosystem, bridge the vehicle's low-level CAN network with higher-level software services, meet automotive environmental and EMC requirements, and do all of this reliably across a 10–15 year vehicle lifetime, while the underlying technology it depends on (smartphone protocols, streaming services, map data) evolves rapidly.
The gap between a consumer tablet and an automotive IVI system is not primarily computational, modern IVI SoCs are as powerful as mid-range smartphone processors. The gap is environmental, temporal, and architectural: the IVI must survive -40°C cold starts, pass CISPR automotive EMC limits, operate safely without distracting the driver, maintain vehicle protocol connectivity for its entire lifetime, and receive over-the-air software updates years after the initial production.
This article examines the IVI ECU architecture, hardware platform, operating system choices, display and connectivity interfaces, vehicle network gateway function, and OTA update architecture.
| Input | Description |
|---|---|
| Driver touch / rotary input | Touchscreen, physical knobs, steering wheel controls |
| Smartphone (USB/Bluetooth/Wi-Fi) | CarPlay, Android Auto, media streaming, contacts |
| Vehicle CAN bus | Speed, gear, ADAS alerts, climate status, door/seat status |
| GPS/GNSS antenna | Vehicle position for navigation |
| Microphone array | Voice recognition - built-in assistant and hands-free calls |
| Rear/surround cameras | Parking camera, 360-degree surround view display |
| FM/DAB antenna | Broadcast radio reception |
| 4G/5G modem (TCU link) | Connected services, OTA updates, streaming |
Operating Modes
| Mode | Description |
|---|---|
| Normal Operation | Full IVI functionality - all apps, connectivity, navigation active |
| Safe Driving Mode | Restrictions on app interaction while vehicle moving above threshold speed |
| Pre-conditioning | Remote access via app - climate/navigation pre-set before driving |
| Firmware Update | OTA update download and installation - background or manual |
| Valet Mode | Limited functionality - navigation history and contacts hidden |
| Diagnostic | UDS diagnostics - DTC readout, software version, EOL calibration |
SoC - The IVI Compute Platform
The IVI ECU is built around a high-performance automotive-grade System-on-Chip. The dominant options in current production vehicles are the Qualcomm SA8155P and SA8295P (Snapdragon Ride), Renesas R-Car H3/M3 series, and NXP i.MX 8 series. These SoCs combine multi-core ARM Cortex-A application processor clusters (4–8 cores) with a GPU for rendering, a hardware video codec for camera and media processing, and DSP cores for audio processing.
The Qualcomm SA8295P, used in vehicles like the BMW iX and Mercedes EQS, provides 12 ARM Cortex-A cores, an Adreno GPU, and an AI engine, delivering a compute level comparable to a high-end smartphone in an automotive-qualified package. The Renesas R-Car H3, widely used by Japanese and European OEMs, provides a similar capability profile with the advantage of Renesas's deep automotive ecosystem relationships and long-term supply commitment.
Unlike most automotive ECUs where the MCU is the only compute element, IVI ECUs typically have two compute components: the main application SoC for the IVI software, and a separate safety-capable MCU for managing the ECU's power state, watchdog supervision, and vehicle network gateway functions that must remain operational even when the main SoC is in sleep or reset state.
Memory
LPDDR4/LPDDR5 RAM: 4–16 GB. The IVI operating system, active apps, map data cache, media buffers, and camera frame buffers collectively consume gigabytes of RAM in a fully loaded system. RAM sizing is one of the most impactful decisions in IVI platform selection, insufficient RAM creates visible performance degradation as the OS begins swapping.
eMMC or UFS Storage: 32–256 GB for OS, applications, map data, and OTA update staging. UFS 3.1 is increasingly preferred over eMMC for its higher sequential read speeds, critical for map tile loading and application launch times. A minimum of two storage partitions (A and B) is required for OTA updates to enable rollback.
Display Interface
IVI display interfaces have evolved significantly as screen sizes and resolutions have increased. Current production systems use:
LVDS (Low Voltage Differential Signalling): The legacy standard, supporting resolutions up to 1080p at moderate refresh rates. Still widely deployed in 7–10 inch single-display IVI systems.
MIPI DSI (Display Serial Interface): The preferred interface for high-resolution displays, supporting 4K resolution and 60+ Hz refresh rates. Used in premium vehicles with large central displays (15 inches and above). Requires shorter cable runs than LVDS, typically confined to single-unit cockpit assemblies.
HDMI / Automotive HDMI: Used in some implementations for rear entertainment displays or where the IVI ECU must drive multiple displays across longer cable runs.
GMSL2 / FPD-Link III: Serialiser/deserialiser links allowing display signals to be transmitted over a single coaxial cable across the vehicle, enabling the IVI ECU to drive displays positioned far from the head unit, rear headrest screens, passenger seat displays.
Connectivity Hardware
Bluetooth (5.x): For hands-free phone, A2DP audio streaming, PBAP contact sync, and MAP message access. Dual-mode classic Bluetooth and BLE required simultaneously.
Wi-Fi (802.11ac/ax): For Wi-Fi Direct (iPhone-based CarPlay), Android Auto wireless, software updates over WLAN, and tethering.
USB: For wired CarPlay and Android Auto, media device connection, and diagnostic access. USB 3.0 for adequate bandwidth with newer smartphones.
Cellular: Connected IVI systems receive location-based services, real-time traffic, OTA updates, and remote access via a shared cellular connection with the vehicle's TCU. The IVI communicates with the TCU via the vehicle Ethernet backbone.
Operating System Choices
Android Automotive OS (AAOS): Google's automotive variant of Android, distinct from Android Auto (which mirrors a phone). AAOS runs natively on the IVI SoC, the vehicle's infotainment system IS an Android device. This enables access to the Google Play Store (with OEM approval), Google Maps, Google Assistant, and the broad Android developer ecosystem. BMW, GM, Volvo, Renault, and Honda have adopted AAOS. Its primary advantages are ecosystem access and developer familiarity. Its primary challenges are the Google dependency, OTA update cadence tied to Android release cycles, and the integration complexity of a Google-supplied OS with an OEM's proprietary vehicle systems.
QNX Neutrino (BlackBerry QNX): The safety-grade real-time microkernel OS. QNX provides ISO 26262 ASIL B certified OS components and is preferred by OEMs who need deterministic behaviour, strong process isolation, and a proven safety case. QNX-based IVI systems typically use a QNX RTOS core with a Linux or Android container for the application layer, the safety-critical display rendering runs on QNX while the application sandbox runs in an isolated Linux environment. Mercedes-Benz, Audi, and BMW have used QNX-based IVI platforms.
Automotive Linux (AGL - Automotive Grade Linux): An open-source, collaborative Linux distribution maintained by the Linux Foundation with Toyota, Honda, and others as members. AGL provides a standardised Linux-based IVI platform without Google dependency, using Wayland/Weston for display composition. The advantage is full OEM control over the software stack; the challenge is building and maintaining the ecosystem of applications and connectivity features that users expect.
Vehicle Network Gateway Function
The IVI ECU is not just an entertainment computer. It is also a bridge between the vehicle's CAN network - where speed, ADAS alerts, door status, and climate data live, and the application layer software that needs to display this information.
This gateway function is typically implemented in a separate software partition (or the companion safety MCU) that reads CAN bus signals and exposes them as software services to the IVI application via a defined API. The separation between the gateway partition and the application partition ensures that a misbehaving app cannot corrupt safety-relevant vehicle signals.
On modern vehicle architectures, the IVI ECU connects to the vehicle Ethernet backbone (100BASE-T1 or 1000BASE-T1) and receives vehicle data as SOME/IP services from the central gateway ECU, rather than directly accessing the CAN bus. This decoupling further isolates the IVI software from the safety-critical vehicle network.
CarPlay and Android Auto Integration
Apple CarPlay and Google Android Auto are the dominant smartphone integration protocols, present in virtually every new passenger vehicle. Both work on the same principle: the smartphone runs the navigation, calling, and media applications; the IVI displays and controls them through a standardised protocol.
Wired CarPlay uses USB 2.0 with a custom Apple protocol. Wireless CarPlay uses Wi-Fi Direct (802.11ac) after a Bluetooth pairing handshake. Android Auto wired uses USB 3.0 with the Android Open Accessory (AOA) protocol; Android Auto wireless uses the same Wi-Fi Direct approach as wireless CarPlay.
The IVI software must implement the display rendering for both protocols (rendered frames arrive from the phone and must be composited into the IVI display with the correct touchscreen input routing), the audio routing (phone audio streams replace IVI audio), and the USB device management for switching between charging and data modes.
OTA Update Architecture
IVI ECUs are updated over-the-air more frequently than any other automotive ECU, map data monthly, application updates quarterly, and OS security patches as needed. The OTA architecture must satisfy several constraints simultaneously:
A/B partition scheme: The storage must have two complete software partitions. OTA downloads to the inactive partition while the vehicle runs from the active partition. On the next ignition cycle, the system boots from the newly updated partition. If the update fails or is incomplete, the system falls back to the known-good previous partition.
Background download: Map and application updates must download in the background without interrupting IVI usage. Bandwidth management, limiting download rate during driving, prioritising updates when plugged in and connected to home Wi-Fi, is essential for user acceptance.
Cryptographic verification: Every update package must be cryptographically signed and verified before installation. The verification chain must ultimately root to a hardware key stored in the companion MCU or a secure element, not software-only verification. The OEM controls the signing keys; even if an attacker intercepts the download, they cannot install a fraudulent update.
Safety and Compliance Considerations
ASIL Rating: The IVI ECU itself is typically QM or ASIL A, infotainment failure is not a safety hazard. However, two IVI functions carry higher ASIL requirements: the display rendering of ASIL-relevant information (such as ADAS camera feeds for parking and reversing) must satisfy requirements defined by the safety architects of those ADAS functions, and the driver distraction prevention function (blocking certain HMI interactions above speed thresholds) may carry a safety requirement.
Driver Distraction: Multiple jurisdictions regulate IVI HMI to prevent driver distraction, NHTSA guidelines in the US, EC Regulation 2021/1958 in Europe. The IVI ECU must enforce these requirements in software, typically by disabling destination entry in navigation, preventing video playback (other than camera feeds), and limiting text display length while the vehicle is moving above a defined speed threshold.
The IVI is becoming the centre of gravity of the in-vehicle software experience. As Software Defined Vehicle architectures mature, the IVI is expanding its remit from entertainment to feature delivery, OTA-delivered driving assistance features, subscription services, personalisation profiles linked to digital identity, and eventually the primary interface through which OEMs monetise the post-sale vehicle relationship.
Large-format curved displays occupying the full dashboard width, pioneered by Mercedes-Benz with the MBUX Hyperscreen, are removing the distinction between instrument cluster and IVI, merging both into a single display managed by a unified cockpit compute platform. This converged cockpit architecture dramatically changes the ECU topology, the safety partitioning challenges, and the display technology requirements simultaneously.
Embien has hands-on experience in IVI and digital cockpit development across the full stack, from hardware platform bring-up on Renesas R-Car and Qualcomm SA8xxx SoCs through Android Automotive OS integration, Sparklet-based custom HMI development, CAN-to-SOME/IP gateway software, and OTA update framework integration. We have delivered instrument cluster and infotainment systems for automotive OEM programs and have expertise in CarPlay/Android Auto integration, MIPI DSI and LVDS display interface bring-up, and automotive Linux BSP customisation.
To discuss your IVI ECU or digital cockpit development requirements, reach out to the Embien team.
Embien's Digital Transformation Services accelerate connected vehicle experiences through intelligent software, cloud connectivity, and OTA-enabled platforms.
Embien's Multimedia on Embedded Systems expertise enables high-performance audio, video, graphics, and HMI solutions for next-generation IVI platforms.
A case study on developing a PCIe multi-channel video mixer using NVIDIA Tegra K1 and Intel Arria V FPGA for high-performance, low-latency video processing and multimedia applications.