2. 车载系统基础

在智能座舱开发中，首先要厘清两个极易混淆的术语：Android Automotive OS（AAOS）与Android Auto。前者是运行在车载硬件上的完整操作系统，后者则是手机投屏的映射协议。理解二者的本质差异，是进入车载显示与HMI开发的第一道门槛。本章将从系统架构、硬件域划分、显示单元（IVI与Cluster）三个维度，建立车载系统的基础认知框架。

2.1 Android Automotive OS与Android Auto的本质区别

核心原理

Android Automotive OS（AAOS）是Google为车载环境从零构建的完整操作系统，它直接运行在车机SoC上，拥有独立的Linux内核、系统服务、应用框架和HAL层。AAOS不依赖手机，可以独立完成导航、语音、媒体播放、车辆控制等功能。而Android Auto本质上是一个投屏协议，手机是计算主体，车机屏幕仅作为远程显示终端，通过USB或Wi-Fi将手机界面投射到车载屏幕上。

从开发视角看，AAOS应用是使用Android SDK开发的独立APK，运行在车机本地；Android Auto应用则是手机端应用的扩展，通过Auto SDK将界面适配到车载屏幕。两者的包结构、生命周期、权限模型完全不同。

判断方法

• 运行载体：AAOS运行在车机硬件上；Android Auto运行在手机上。
• 网络依赖：AAOS可完全离线运行（除在线服务外）；Android Auto需要手机持续连接。
• 系统更新：AAOS通过OTA升级车机系统；Android Auto通过手机应用商店更新。
• 硬件访问：AAOS可直接访问车辆CAN总线、传感器、多屏输出；Android Auto只能访问手机自身硬件。
• 应用生态：AAOS支持车机专用应用（如车辆设置、空调控制）；Android Auto仅支持经过认证的媒体和通讯类应用。

2.2 车载系统架构分层详解

核心原理

现代车载系统普遍采用分层架构，从下至上依次为：硬件平台层、Linux内核层、硬件抽象层（HAL）、系统服务层、应用框架层和应用层。这种分层设计使得上层应用与底层硬件解耦，便于OEM和Tier1进行模块化开发和迭代。

在AAOS中，最关键的分层是Vehicle HAL（VHAL）。它定义了车辆属性（如车速、车门状态、空调温度）的标准接口，上层CarService通过VHAL读取和设置车辆状态。VHAL屏蔽了不同车型的CAN协议差异，使得应用开发者无需关心具体硬件实现。

各层职责与关键组件

1. 硬件平台层：包括SoC（高通8155/8295、英伟达Orin）、GPU/DPU、显示接口（DSI/LVDS/DP）、内存、存储、电源管理IC。该层决定了系统性能上限。
2. Linux内核层：提供进程调度、内存管理、设备驱动、网络协议栈。AAOS基于Linux 5.x内核，增加了车载相关驱动（如CAN、以太网AVB）。
3. HAL层：将内核驱动封装为稳定的C++接口。关键HAL包括：Vehicle HAL、Audio HAL（支持多音区）、Display HAL（支持多屏独立渲染）、Camera HAL（用于DMS/AVM）。
4. 系统服务层：运行在SystemServer进程中，包括CarService（车辆属性管理）、ActivityManager、WindowManager、AudioService、DisplayService等。CarService是AAOS特有的核心服务。
5. 应用框架层：提供Android SDK API和Car API（如CarPropertyManager、CarAudioManager）。开发者通过Car API访问车辆数据。
6. 应用层：包括系统应用（Launcher、SystemUI、设置）和第三方应用（导航、音乐、视频）。

案例拆解：VHAL在空调控制中的工作流程

假设用户通过中控屏调节空调温度，整个链路如下：

1. 用户点击温度+按钮
2. 应用层调用 CarPropertyManager.setProperty(
       VehiclePropertyIds.HVAC_TEMPERATURE_SET, 
       zoneId, value)
3. CarService接收请求，校验权限
4. CarService调用 VHAL 的 setProperty() 接口
5. VHAL将属性值转换为CAN信号（如0x1A2字节3）
6. CAN总线将信号发送至空调控制器（HVAC ECU）
7. HVAC ECU执行压缩机/风门动作
8. 状态回传：HVAC ECU通过CAN返回当前温度
9. VHAL上报属性变化，CarService广播回调
10. 应用层刷新UI显示

这个流程体现了分层架构的价值：应用层和HAL层完全解耦，即使更换空调硬件供应商，只要VHAL接口不变，应用代码无需修改。

2.3 IVI与Cluster概念解析

核心原理

IVI（In-Vehicle Infotainment）即车载信息娱乐系统，通常指中控台的大屏区域，承担导航、媒体、电话、车辆设置、空调控制等非驾驶关键功能。Cluster（仪表盘）则是驾驶员正前方的显示单元，显示车速、转速、油量/电量、警示灯、ADAS状态等驾驶关键信息。两者的核心区别在于安全等级：Cluster信息直接影响驾驶安全，因此对实时性、可靠性、抗干扰能力要求远高于IVI。

在AAOS架构中，IVI和Cluster可以运行在同一SoC的不同显示输出上，也可以由独立SoC驱动。前者称为单芯片多屏方案（如高通8155驱动IVI+Cluster），后者称为多芯片方案（如英伟达Orin驱动Cluster，高通8295驱动IVI）。

IVI与Cluster的显示特性对比

实战场景：单芯片双屏显示的实现要点

以高通8155为例，它支持3个Display Pipe，可同时驱动IVI（1080p）和Cluster（720p或1080p）。在AAOS中，通过VirtualDisplay或Multi-Display API实现双屏独立渲染。关键配置包括：

// 在device_config.xml中定义双屏
<display id="0" type="primary" width="1920" height="1080"/>
<display id="1" type="cluster" width="1280" height="480"/>

// 在SystemUI中为Cluster创建独立窗口
WindowManager.LayoutParams clusterParams = new WindowManager.LayoutParams(
    WindowManager.LayoutParams.MATCH_PARENT,
    WindowManager.LayoutParams.MATCH_PARENT,
    WindowManager.LayoutParams.TYPE_CLUSTER_ALERT,
    WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE,
    PixelFormat.RGBA_8888);

实际开发中，Cluster应用通常使用SurfaceView或TextureView进行渲染，并采用硬件合成器（HWC）将Cluster图层直接合成到对应Display接口，避免经过GPU合成带来的延迟。

2.4 常见误区与总结复盘

误区一：将Android Auto当作AAOS的简化版

这是最普遍的认知错误。Android Auto是手机投屏，车机端没有运行任何Android应用；AAOS是完整的车载操作系统。如果产品需求是“车机必须支持CarPlay和Android Auto”，那么车机系统可以是AAOS，也可以是非Android系统（如QNX），因为Android Auto只是协议。

误区二：Cluster必须使用实时操作系统（RTOS）

虽然传统Cluster使用QNX或GreenHills，但现代AAOS通过Trusty TEE、安全启动、分区隔离等技术，已经可以满足ASIL-B要求。关键在于将Cluster应用放入独立的安全域（如Android的isolatedProcess），并限制其访问网络和外部存储。

误区三：IVI和Cluster必须使用同一套HMI框架

实际上，IVI可以使用AAOS的Jetpack Compose或CarUI，而Cluster为了性能和安全，往往使用更轻量的渲染方案（如Qt for MCU或自研OpenGL渲染器）。两者可以共存于同一SoC，但需要明确资源分配和优先级。

总结复盘

• AAOS与Android Auto是“操作系统”与“投屏协议”的关系，开发模式完全不同。
• 车载系统分层架构的核心是VHAL，它实现了车辆硬件与上层应用的解耦。
• IVI与Cluster的安全等级差异决定了技术选型：IVI追求功能丰富，Cluster追求实时可靠。
• 单芯片多屏方案是当前主流，但需要精细管理Display Pipe、VSync和内存带宽。
• 在HMI设计时，必须考虑Cluster的驾驶安全约束（如最小字体高度、对比度、闪烁频率限制）。