3. 虚拟化技术概述

系统架构设计，说白了就是决定「谁管谁、谁用谁、谁跟谁说话」。

智能座舱的虚拟化架构，核心要解决三个问题：隔离、共享、通信。我见过不少项目，前期架构没想清楚，后期联调时天天吵架——仪表黑屏怪中控抢内存，中控卡顿怪网关占带宽。嗯，咱们今天就把这三个坑提前填上。

3.1 多域隔离架构：为什么必须「分家」？

传统座舱是一个 SoC 跑一个系统，仪表和中控各用各的芯片。现在要合在一起，但安全等级完全不同——仪表关乎生命，中控关乎体验。混在一起，万一中控死机把仪表拖下水，那就出大事了。

多域隔离架构，就是把不同安全等级的功能，放在独立的「域」里运行。每个域有自己的 CPU/GPU 资源、内存空间、外设访问权限。域之间通过虚拟化层硬性隔开。

3.1.1 典型域划分

域名称	功能范围	安全等级	实时性要求
仪表域	车速、转速、报警灯、ADAS 警示	ASIL-B	< 100ms
娱乐域	导航、音乐、视频、语音助手	QM	< 500ms
连接域	蓝牙、Wi-Fi、T-Box、OTA	QM	< 1s
车身域	车窗、空调、灯光、门锁	ASIL-A	< 200ms

我在一个量产项目里遇到过，娱乐域 OTA 升级时把整个系统搞重启了，仪表黑屏了 3 秒。客户直接投诉到车厂。后来我们强制把仪表域跑在独立的物理核上，升级期间完全不受影响。这就是隔离的价值。

3.1.2 隔离实现方式

• 物理隔离：每个域用独立的 SoC，成本高，但最安全。多见于高端车型。
• 虚拟化隔离：一个 SoC 跑多个 VM，通过 Hypervisor 隔离。成本低，但需要硬件支持（GIC、SMMU）。
• 容器隔离：共享内核，通过 Namespace/Cgroup 隔离。性能好，但安全隔离弱，不适合仪表域。

3.2 硬件资源池化：别让算力「闲着」

多域隔离听起来很好，但有个问题：每个域都独占资源，那 GPU、NPU 这些贵重的硬件，利用率会很低。你想想看，仪表域大部分时间只显示几个数字，GPU 闲着；娱乐域看视频时 GPU 满载，但仪表域的 GPU 还是闲着。

硬件资源池化，就是把 GPU、NPU、DSP、编解码器等硬件，做成一个「共享池」。哪个域需要，就动态分配。但前提是——不能影响安全域的实时性。

3.2.1 资源池化架构

我习惯把资源池化分成三层：

1. 物理层：硬件本身支持虚拟化（如 GPU 的 SR-IOV、Intel GVT-g）。
2. 中间层：资源调度器，负责分配和回收。支持 QoS 和优先级。
3. 应用层：域内的中间件或驱动，向调度器申请资源。

3.2.2 典型资源池化方案对比

方案	适用硬件	隔离强度	性能损耗	典型场景
SR-IOV	GPU、网卡	强	< 5%	仪表 + 中控共享 GPU
GVT-g	Intel GPU	中	< 10%	娱乐域多 VM 共享
硬件分区	NPU、DSP	强	< 2%	语音 + 视觉 NPU 共享
软件调度	CPU、内存	弱	< 15%	非实时任务共享

3.3 通信中间件选型：域之间怎么「说话」？

域隔离了，资源池化了，但域之间还得通信。仪表要从中控拿导航信息，中控要从车身域拿空调状态。怎么传？

直接共享内存？不安全。走网络协议栈？延迟太高。所以需要一套通信中间件，专门解决跨域通信的可靠性、实时性和安全性。

3.3.1 主流中间件对比

中间件	通信模型	实时性	安全认证	适用场景
SOME/IP	服务发现 + RPC	中	AUTOSAR	传统车载网络
DDS	发布/订阅	高	DO-178C	实时控制、ADAS
Zenoh	发布/订阅 + 存储	高	发展中	边缘计算、异构通信
MQTT	发布/订阅	低	无	非实时、云端通信

我个人比较推荐 DDS 作为座舱内部的主干通信。原因有三：

• 支持 QoS，可以给仪表域设置最高优先级。
• 去中心化，没有单点故障。
• 跨语言、跨平台，C++ 和 Java 都能用。

3.3.2 通信架构设计要点

1. 域内通信：用共享内存或本地 Socket，延迟 < 1ms。
2. 域间通信：用 DDS 或 SOME/IP，延迟 < 10ms。
3. 跨车通信：用 MQTT 或 HTTP，延迟 < 100ms。
4. 安全通信：必须加密 + 认证，防止伪造消息。

3.4 整体架构图

下面这张图，是我在多个项目中沉淀下来的多域隔离 + 资源池化 + 通信中间件的整体架构。你可以把它当成座舱虚拟化的「标准模板」来用。

3.5 选型决策建议

说了这么多，到底怎么选？我列一个简单的决策树：

• 如果项目要求 ASIL-B 认证：必须用虚拟化隔离 + DDS 通信。别省钱。
• 如果项目是纯娱乐座舱：容器隔离 + SOME/IP 就够了。成本低，开发快。
• 如果项目要支持 OTA 和云端：在 DDS 基础上，加一层 MQTT 桥接，专门处理云端通信。
• 如果项目是异构 SoC（比如 R-Car + i.MX）：用 Zenoh 做跨芯片通信，延迟比 DDS 低，资源占用也更小。