3. 智能座舱系统架构
智能座舱从“多颗独立ECU”走向“单域控制器 + 多操作系统共存”，本质是把仪表、中控、HUD、后排娱乐、语音与车控交互收敛到一颗高算力SoC上。架构设计的关键不再是“功能能不能做”，而是安全域与开放域如何隔离、算力与带宽如何分配、启动与恢复如何满足量产一致性。本章围绕域控制器、SoC选型、Hypervisor、QNX与Android/Linux共存以及典型量产拓扑展开。
一、核心原理：域控制器与“一芯多屏多系统”
座舱域控制器（CDC）通常由主控SoC、MCU安全岛、电源管理、音视频桥接、显示与摄像头接口、车载以太网/ CAN 网关等组成。其核心思想是：用硬件分区与软件虚拟化，把不同安全等级、不同生态的负载放在同一硬件平台上。仪表、HUD等涉及行车安全的模块要求高实时、高可靠，通常运行在QNX等RTOS上；中控娱乐、导航、语音、应用生态则运行在Android或Linux上。
典型资源划分包括：CPU核绑定、GPU分时/分片、内存预留、显示图层归属、音频通道路由、存储分区与网络虚拟接口。若划分不当，会出现“娱乐域卡顿拖垮仪表”“Android重启导致QNX侧服务超时”等量产问题。
架构判断准则：安全相关功能优先放在QNX侧并拥有独立显示层与看门狗；非安全功能放在Android/Linux侧；跨域通信必须经过受控的Hypervisor通道或标准IPC，不允许直接共享内存裸访问。
二、SoC选型：算力、隔离能力与量产成熟度
SoC选型不能只看跑分。座舱SoC需要同时评估CPU/GPU/NPU算力、硬件虚拟化支持（如ARM EL2、SMMU、中断虚拟化）、显示与摄像头接口数量、内存带宽、功能安全等级（ASIL-B及以上能力）、车规认证与长期供货。常见方案包括高通SA8155/8295、瑞萨R-Car H3/M3、TI Jacinto、NXP i.MX8系列等，不同平台在Hypervisor支持、GPU虚拟化和生态适配上差异明显。
| 评估维度 | 关键问题 | 量产影响 |
|---|---|---|
| 算力与带宽 | CPU/GPU/NPU是否满足多屏+AI语音+DMS | 决定能否一芯多屏，避免后期降规 |
| 虚拟化支持 | 是否支持SMMU、中断直通、GPU分片 | 决定QNX与Android隔离质量 |
| 功能安全 | 是否具备ASIL-B能力与安全岛 | 决定仪表能否通过功能安全审查 |
| 接口资源 | MIPI DSI/CSI、PCIe、以太网、CAN数量 | 决定外设扩展与拓扑复杂度 |
| 生态与供货 | QNX BSP、Android Automotive适配、生命周期 | 决定开发周期与量产维护成本 |
三、Hypervisor方案：Type-1为主，QNX Hypervisor常见
Hypervisor负责在硬件与多个Guest OS之间做资源抽象与隔离。量产座舱以Type-1（裸金属）为主，常见形态是QNX Hypervisor：QNX作为Host或安全Guest，Android/Linux作为Guest。其关键能力包括vCPU调度、内存分区、设备直通与虚拟设备、共享显示与音频、跨Guest通信。
# 典型QNX Hypervisor配置关注项（示意）
vdev = virtio-net, virtio-blk, virtio-gpu
guest = qnx_ivy: vCPU 0-1, mem 512MB, display layer 0
guest = android: vCPU 2-7, mem 4GB, display layer 1
shared = audio: qnx_mixer -> android_pcm
ipc = shmem + doorbell, 仅允许白名单通道
watchdog = qnx_ivy 独立喂狗，android 异常不影响仪表需要特别关注启动时序：仪表必须在规定时间内点亮，因此QNX侧通常先启动并接管显示，Android随后启动。若Android启动失败，系统应降级为“仪表可用、娱乐受限”，而不是整机黑屏。
四、QNX与Android/Linux共存架构与典型量产拓扑
共存架构一般分为三层：硬件层（SoC、PMIC、显示、音频、网络）、虚拟化层（Hypervisor + 驱动分区）、系统层（QNX安全域 + Android开放域）。跨域通信常用共享内存+中断、virtio、SomeIP或自定义IPC。音频需要统一混音策略，显示需要图层管理，网络需要虚拟网卡与防火墙策略。
典型量产拓扑中，域控制器通过车载以太网连接T-BOX、ADAS、车身域，通过CAN/LIN连接车控与灯光，通过LVDS/MIPI驱动多块屏幕。部分车型采用“座舱域+智驾域”双域架构，座舱域负责HMI与娱乐，智驾域负责感知与规控，两者通过以太网交换数据。
五、案例与误区复盘
案例：某量产车型在Android侧启动导航时，仪表出现短暂卡顿。排查发现GPU未做分片，Android的3D渲染与仪表图层争抢GPU。整改方案是将仪表显示层绑定到QNX侧独立GPU上下文，并限制Android的GPU时间片。
常见误区：
- 只关注SoC峰值算力，忽略内存带宽与SMMU隔离能力，导致后期虚拟化性能不达标。
- 把Android和QNX的启动顺序做成“同时启动”，仪表无法满足快速点亮要求。
- 跨域通信直接使用共享内存裸读写，缺少权限与超时保护，Android异常会拖垮QNX。
- 音频没有统一混音策略，导航播报与媒体声音互相打断，用户体验差。
量产提醒：Hypervisor配置一旦冻结，后期修改分区与直通关系成本极高。建议在架构设计阶段就完成启动时序、显示归属、音频路由、网络策略和降级方案的评审，并预留至少一个可动态调整的Guest资源配额。
综上，智能座舱系统架构的核心是“以安全域为锚点，以Hypervisor为边界，以SoC资源为约束，以量产拓扑为落地”。只有把域控制器、SoC、Hypervisor、QNX与Android共存关系以及典型拓扑放在同一张图上审视，才能在性能、安全与成本之间取得可量产的平衡。