2. 座舱电子架构演进

座舱电子架构的演进，本质上是一场围绕“算力集中化”与“功能软件化”的持续重构。理解这条演进主线，是理解 Hypervisor 为何出现在座舱中、以及它究竟解决什么问题的前提。本节将沿着分布式 ECU → 域控制器 → 中央计算平台三个阶段，梳理硬件形态、软件部署方式与通信机制的变化，并明确 Hypervisor 在其中的定位。

一、核心原理：三个阶段的结构性差异

第一阶段是分布式 ECU 架构。每个功能由独立 ECU 承载，例如仪表 ECU、中控 ECU、空调 ECU、HUD ECU 各自拥有独立的 MCU/SoC、独立电源、独立线束。功能之间通过 CAN、LIN、FlexRay 等总线交互。其优点是故障隔离天然存在、开发解耦；缺点是算力孤岛、线束臃肿、跨功能协同困难，且 OTA 升级几乎无法统一。

第二阶段是域控制器架构。按功能域划分，座舱域控制器（CDC）将仪表、中控、HUD、后排娱乐等整合到一颗高性能 SoC 上。硬件上从“多芯多板”变为“一芯多屏”，软件上开始出现多操作系统共存的需求：仪表要求高实时、高可靠，中控要求丰富生态与快速迭代。此时，Hypervisor 作为 Type-1 裸金属虚拟化层首次成为座舱的关键基础设施。

第三阶段是中央计算平台架构。座舱、智驾、车控进一步向中央计算单元（HPC）收敛，形成“中央计算 + 区域控制”的拓扑。此时虚拟化不再只服务于座舱内部的多系统隔离，而是承担跨域资源分区、安全隔离与算力动态调度的角色。Hypervisor 从“座舱内的隔离器”升级为“整车计算资源的底座”。

二、方法流程：Hypervisor 在座舱中的定位

在域控与中央计算阶段，Hypervisor 的定位可以概括为“硬件之上的资源仲裁者”。它直接运行在 SoC 的 EL2 异常级别（以 ARM 为例），向下管理 CPU 核、内存、GPU、显示控制器、音频 DSP、网络等物理资源，向上为多个客户机操作系统（Guest OS）提供虚拟化视图。

1. 资源分区：将 CPU 核静态或半静态分配给不同 VM，例如将 2 个 A 核给仪表 RTOS，4 个 A 核给 Android。
2. 内存隔离：通过 Stage-2 页表为每个 VM 建立独立物理地址空间，防止越权访问。
3. 设备虚拟化：对 GPU、显示、音频等共享设备进行虚拟化，或通过直通（Passthrough）方式分配给关键 VM。
4. 中断与调度：管理虚拟中断注入与 vCPU 调度，保障仪表等实时 VM 的确定性。
5. 安全启动与度量：作为最先启动的软件层，承担镜像校验与可信链建立。

三、案例场景：一芯多屏下的隔离需求

某车型座舱域控制器采用单颗 8 核 SoC，需要同时运行仪表、中控、副驾娱乐三个系统。若采用传统单 OS 方案，中控应用崩溃可能拖垮仪表显示，存在安全风险。引入 Hypervisor 后：

• 仪表运行在独立 RTOS VM 中，分配 2 个专用核与独立显示通道，满足 ASIL-B 级功能安全要求；
• 中控与副驾娱乐运行在 Android VM 中，共享剩余算力，崩溃时不影响仪表；
• GPU 通过虚拟化分时复用，Hypervisor 负责命令队列隔离与优先级仲裁；
• OTA 升级可针对单个 VM 进行，仪表升级与中控升级互不阻塞。

这一场景说明：Hypervisor 的价值不仅是“跑多个系统”，更是在共享硬件上重建故障隔离边界。

四、误区与复盘

复盘来看，架构演进的核心矛盾始终是“算力集中带来的收益”与“故障集中带来的风险”之间的平衡。Hypervisor 正是这一平衡的技术支点：它让集中化的硬件重新获得分布式架构才有的隔离性，同时保留软件定义与统一 OTA 的收益。

五、三阶段关键特征对比