4. 中央计算平台设计：高性能计算平台（HPC）的硬件选型与资源调度
中央计算平台，说白了就是整车的“大脑”。它要处理来自四面八方——摄像头、雷达、激光雷达、车身传感器——的海量数据，还要实时做出决策。这个平台选不好，后面的软件架构再牛也跑不起来。
我个人习惯把中央计算平台的设计拆成三个核心问题：选什么芯片、怎么调度算力、怎么跟区域控制器配合。咱们一个一个聊。
4.1 高性能计算平台（HPC）的硬件选型
目前市面上主流的车规级高性能 SoC，基本就是三家争霸：NVIDIA、高通、英飞凌。它们定位不太一样，我分别说说我的看法。
4.1.1 NVIDIA Orin 系列
NVIDIA Orin 是我在项目中用得最多的芯片。它主打的是高算力和完善的生态。Orin 系列从 Orin NX（70 TOPS）到 Orin AGX（254 TOPS），覆盖了从入门到旗舰的需求。
核心优势：
- CUDA 生态成熟，算法迁移成本低。我在一个 L2+ 项目中，直接把 PC 上的感知模型跑在 Orin 上，几乎没改代码。
- 硬件级安全岛（Safety Island）符合 ASIL-D 要求，可以跑监控和降级逻辑。
- 支持多芯片级联，适合做超大算力平台。
注意： Orin 的功耗不低。AGX 版本峰值功耗能到 60W+，散热设计一定要跟上。我曾经在一个项目中因为散热器选型保守，导致芯片降频，感知帧率直接掉了一半。嗯，后来换了均温板才解决。
4.1.2 高通 Snapdragon Ride 系列
高通的 Ride 平台，我最早接触是在 2021 年。它的特点是CPU 性能强、AI 引擎效率高，而且跟座舱芯片同源，容易做舱驾融合。
| 特性 | NVIDIA Orin | 高通 Snapdragon Ride |
|---|---|---|
| AI 算力 | 70-254 TOPS | 30-700+ TOPS（Flex 架构） |
| CPU 核心 | Cortex-A78AE（12核） | Kryo（最多 16 核） |
| GPU | Ampere 架构（2048 CUDA） | Adreno 架构 |
| 安全等级 | ASIL-D（Safety Island） | ASIL-D（安全微控制器） |
| 典型功耗 | 15W-60W | 5W-65W |
| 生态成熟度 | 高（CUDA） | 中（QNX/Android Automotive） |
高通的优势在于CPU 单核性能。你想想看，很多逻辑决策、路径规划还是跑在 CPU 上的，CPU 强了，整个系统的响应速度就快。我在一个项目中对比过，同样跑 A* 路径规划，高通的 Kryo 比 Orin 的 A78AE 快了大约 15%。
4.1.3 英飞凌 TC4xx 系列
英飞凌 TC4xx 跟上面两家不太一样。它不是用来跑 AI 的，而是做实时控制和功能安全的。TC4xx 系列是 TC3xx 的升级版，增加了 PPU（并行处理单元），可以分担一些轻量级的 AI 推理任务。
我一般把 TC4xx 放在中央计算平台里做安全协处理器。比如，Orin 跑感知和规划，TC4xx 负责车辆控制、故障诊断、降级策略。这样分工明确，安全等级也容易满足。
我的选型建议：
- 如果项目追求极致算力和生态，选 Orin。
- 如果项目注重 CPU 性能和舱驾融合，选高通 Ride。
- 如果项目对功能安全要求极高，或者需要独立的实时控制单元，加一颗 TC4xx。
4.2 异构计算：CPU + GPU + NPU 的资源调度
选好了芯片，下一步就是怎么用好它。中央计算平台里，CPU、GPU、NPU 各司其职，但资源是有限的。怎么调度才能不打架？
4.2.1 各单元的分工
- CPU：跑操作系统、逻辑决策、路径规划、通信协议栈。它适合处理串行、分支多的任务。
- GPU：做图像渲染、传统视觉算法、并行计算。它适合处理大规模并行、数据密集的任务。
- NPU：专门跑深度学习推理，比如目标检测、语义分割。它比 GPU 更省电，效率更高。
4.2.2 调度策略
我在项目中总结了一套“三级调度”策略，你可以参考一下：
- 任务级调度：在应用层，把任务按类型分配到不同的计算单元。比如，感知任务绑到 NPU，路径规划绑到 CPU，可视化绑到 GPU。
- 帧级调度：在中间件层，用时间触发的方式，确保每个计算单元在固定时间窗口内完成工作。比如，NPU 每 33ms 出一帧感知结果，CPU 每 10ms 做一次控制计算。
- 硬件级调度：在驱动层，利用硬件虚拟化或硬件隔离，确保安全任务不受干扰。比如，把 TC4xx 的实时任务放在独立核心上，跟 Orin 的 Linux 系统完全隔离。
一个实际案例：
我曾经在一个项目中，NPU 跑 YOLOv5 做目标检测，GPU 跑 BEV 融合，CPU 跑规划和控制。结果发现 GPU 和 NPU 抢内存带宽，导致 NPU 推理时间从 20ms 涨到 35ms。
解决办法是：在硬件层面，给 NPU 分配独立的内存通道；在软件层面，把 GPU 的 BEV 融合任务优先级降低，错峰执行。调整后，NPU 推理时间稳定在 22ms 以内。
4.3 中央网关与区域控制器（Zonal）的协同
中央计算平台不是孤岛。它要跟区域控制器（Zonal）配合，才能控制整车的执行器。
4.3.1 架构分层
我习惯把协同架构分成三层：
- 中央层：中央计算平台（HPC），负责感知、决策、全局规划。
- 区域层：区域控制器（Zonal），负责区域内的传感器/执行器接入、电源管理、数据转发。
- 边缘层：智能传感器/执行器，比如摄像头、雷达、电机控制器。
4.3.2 协同的关键点
中央网关和区域控制器怎么协同？我总结了三个关键点：
- 数据路由：区域控制器把传感器数据打包，通过千兆以太网发给中央计算平台。中央计算平台处理完后，把控制指令发回区域控制器，由区域控制器转发给执行器。
- 电源管理：区域控制器可以独立控制区域内的设备供电。比如，车辆休眠时，区域控制器可以关掉摄像头和雷达的电源，只保留 CAN 唤醒电路。这个功能我在项目中用过，整车静态电流从 50mA 降到了 5mA。
- 故障隔离：如果某个区域内的传感器坏了，区域控制器可以本地诊断并上报，不影响其他区域。中央计算平台收到故障信息后，可以降级运行，比如关闭自动泊车功能，但保留自适应巡航。
避坑指南： 我曾经在一个项目中，中央计算平台和区域控制器之间的通信协议没对齐。中央平台发的是 SOME/IP 服务发现，区域控制器只认 DDS。结果两边互相收不到数据，车机直接黑屏。后来统一用了 SOME/IP + DDS 桥接才解决。所以，通信协议一定要在架构设计阶段就定死。
4.4 小结
中央计算平台的设计，说白了就是选对芯片、用好算力、管好通信。NVIDIA Orin 适合高算力场景，高通 Ride 适合舱驾融合，英飞凌 TC4xx 适合安全控制。异构计算的关键是让 CPU、GPU、NPU 各司其职，别抢资源。跟区域控制器的协同，核心是数据路由、电源管理和故障隔离。
嗯，这些经验都是我在项目里一点点踩坑踩出来的。你设计的时候，多想想实际场景，别光看参数表。