系统架构设计：硬件平台选型与软件分层

做智能座舱虚拟化，第一步不是写代码，而是选芯片、定架构。我见过不少团队，上来就开干，结果做到一半发现算力不够，或者外设驱动不兼容，只能推倒重来。说白了，架构设计就是给整个系统打地基，地基歪了，上面盖什么都白搭。

这一章，我们聊聊硬件怎么选、软件怎么分、域控制器和中央计算平台到底有什么区别。嗯，都是实战中绕不开的硬骨头。

硬件平台选型：ARM/SoC 的核心考量

智能座舱的 SoC，现在基本被 ARM 生态统治了。为什么？因为车规级芯片对功耗、散热、成本的要求，x86 很难满足。我个人习惯，选型时主要看三个维度：

• 算力：CPU 主频、核心数，GPU 的浮点性能，NPU 的 TOPS 值。别只看峰值，要看持续性能。我在项目中遇到过，某款芯片标称 8 TOPS，跑神经网络推理时温度一上来，直接降频到 3 TOPS，画面卡得不行。
• 虚拟化支持：硬件虚拟化扩展（如 ARM 的 GICv4、SMMU）、IOMMU、中断控制器。没有这些，你跑 Hypervisor 会非常痛苦。
• 外设接口：显示接口（DP、MIPI DSI）、摄像头接口（CSI）、音频总线、以太网（TSN）、PCIe。接口数量够不够？带宽够不够？

下面这张表，是我常用的选型对比框架：

软件分层架构：从底层到应用

软件分层，说白了就是「各司其职」。每一层只关心自己的事，层与层之间通过标准接口通信。这样做的好处是，换硬件时只需要改底层，上层代码基本不用动。

我习惯把智能座舱的软件分成四层：

1. 硬件层：SoC、内存、存储、外设。这是物理基础。
2. Hypervisor / 虚拟机监视器：负责隔离、调度、资源分配。比如 QNX Hypervisor、Xen、ACRN。嗯，这里要注意，Hypervisor 本身也要占用资源，选型时要算进去。
3. Guest OS / 客户操作系统：每个虚拟机里跑一个 OS。仪表盘通常跑 QNX 或 RT-Linux，中控娱乐跑 Android，Tbox 跑 Linux。为什么这么分？安全等级不同，你想想看，仪表盘死机了可是要出事的。
4. 应用层：HMI、导航、语音、车载应用。这一层最灵活，也最容易出问题。

下面这张 SVG 图，展示了典型的四层架构关系：

域控制器与中央计算平台

这两个概念，很多人容易搞混。我简单解释一下：

• 域控制器（Domain Controller）：按功能域划分，比如座舱域、智驾域、车身域。每个域有自己的控制器，负责该域内的功能。域之间通过以太网或 CAN 通信。
• 中央计算平台（Central Computing Platform）：把所有域的计算任务集中到一个或两个高性能 SoC 上。说白了，就是「一台电脑干所有事」。

你想想看，为什么会有这种趋势？因为传统分布式架构，一辆车上有几十个 ECU，线束重、成本高、升级困难。域控制器减少了 ECU 数量，中央计算平台更进一步，把算力集中起来，方便 OTA 升级和软件迭代。

下面这个表格，对比了两种架构的优缺点：

我个人更看好中央计算平台的方向，但前提是虚拟化技术要成熟。没有好的 Hypervisor，中央计算平台就是空中楼阁。你想想看，仪表盘和中控娱乐跑在同一个 SoC 上，如果娱乐系统崩溃了，仪表盘还能不能正常工作？这就是虚拟化要解决的问题。