2. 自动驾驶计算平台概述
自动驾驶计算平台是承载感知、定位、预测、规划与控制算法的“车载数据中心”。它必须在有限功耗、散热与成本约束下，持续处理多路摄像头、激光雷达、毫米波雷达、IMU、GNSS 等传感器数据，并在毫秒级时间内输出安全可执行的车辆控制指令。理解计算平台的演进脉络、典型硬件架构以及传感器与计算单元之间的数据关系，是后续性能基准测试与调优工程的基础。
一、计算平台演进：从分布式 ECU 到中央计算
早期辅助驾驶功能由分布式 ECU 实现，每个功能对应一个独立控制器，例如 AEB 使用前向雷达与摄像头，LKA 使用前视摄像头。这种架构开发解耦、功能安全边界清晰，但算力分散、线束复杂、跨模块数据难以共享。随着 L2+ 与 L3 功能出现，多传感器融合需要统一时间基准与共享感知结果，计算平台开始向域控制器集中。
域控制器阶段通常划分为智能驾驶域、座舱域、车身域等，智能驾驶域控制器集成 SoC 与 MCU，承担多路传感器接入、融合感知与规控任务。进入 L4/L5 阶段，电子电气架构进一步向“中央计算 + 区域控制”演进：中央计算单元负责高算力 AI 推理与全局决策，区域控制器负责电源分配、低速信号采集与执行器驱动。其核心驱动力是软件定义汽车：算法迭代速度超过硬件换代速度，平台必须支持 OTA、算力弹性分配与多车型复用。
二、典型硬件架构：SoC、GPU、FPGA、ASIC
自动驾驶计算芯片并非单一类型，而是多种计算单元的组合。SoC 是主控核心，内部集成 CPU、GPU、NPU、ISP、DSP、安全岛与高速接口；GPU 擅长并行浮点计算，常用于点云处理、BEV 特征提取与训练侧；FPGA 具备可重构性，适合低延迟传感器预处理与原型验证；ASIC 则为特定算法定制，能效比最高，但灵活性最低、流片成本高。
| 计算单元 | 典型任务 | 优势 | 局限 |
|---|---|---|---|
| CPU | 任务调度、规控、状态机 | 通用性强、生态成熟 | 算力密度低、功耗效率一般 |
| GPU | BEV、点云、图像并行计算 | 吞吐高、编程模型成熟 | 功耗高、延迟抖动较大 |
| NPU | CNN/Transformer 推理 | 能效比高、定点优化好 | 算子支持受限、量化有精度损失 |
| FPGA | 传感器同步、预处理、原型 | 低延迟、可重构 | 开发门槛高、单位成本高 |
| ASIC | 量产固定算法加速 | 极致能效、成本可控 | 灵活性差、迭代周期长 |
实际平台中，这些单元通过片内总线、PCIe、MIPI、以太网等互联。例如摄像头经 MIPI CSI 进入 ISP，激光雷达经以太网进入 SoC，NPU 完成感知推理，CPU 运行规控，MCU 负责安全监控与执行器输出。性能调优必须关注数据搬运路径，因为瓶颈往往不在算力峰值，而在内存带宽与互联延迟。
三、传感器与计算单元关系
传感器与计算单元之间不是简单“插上即可”，而是存在严格的时序、带宽与同步关系。摄像头帧率通常为 30fps，激光雷达 10~20Hz，毫米波雷达 20~50Hz，IMU 可达 100~1000Hz。多传感器融合要求统一时间戳，通常由 PTP 或硬件触发同步。若时间偏差超过阈值，融合结果会出现目标“拖影”或位置跳变。
从图中可见，传感器数据先经过预处理与时间同步，再进入 NPU/GPU 进行感知推理，CPU 完成融合与规控，最终由安全岛 MCU 输出执行指令。任何一段带宽不足或同步失败，都会导致端到端延迟上升。
四、应用场景与性能挑战
不同应用场景对计算平台提出差异化要求。高速 NOA 强调远距离感知与低延迟规控；城市 NOA 面对复杂交通参与者，需要更大 BEV 模型与更密集的推理；自动泊车场景速度低，但对近距离障碍物检测与路径搜索实时性要求高；无人配送与 Robotaxi 则要求多传感器冗余与功能安全。
典型性能挑战：
- 算力与功耗矛盾：峰值算力提升往往伴随功耗上升，车载散热能力有限，需在 TOPS/W 上优化。
- 内存带宽瓶颈：大模型推理频繁访问权重与特征图，DDR 带宽可能先于算力饱和。
- 端到端延迟：从曝光到执行器响应需控制在 100ms 以内，否则高速场景制动距离显著增加。
- 时间同步与数据一致性：多传感器时间戳偏差会导致融合目标位置错误。
- 功能安全与冗余：安全岛需独立监控主 SoC，故障时实现降级运行。
五、案例与调优切入点
某 L2+ 域控制器在实车测试中出现“城市路口偶发漏检”。排查发现，8 路摄像头经 ISP 后写入共享内存，NPU 推理任务与 GPU 点云任务竞争 DDR 带宽，导致部分帧延迟超过 80ms，融合模块使用了过期帧。调优措施包括：将摄像头预处理下沉至 ISP 硬件，减少 CPU 拷贝；为 NPU 推理设置高优先级内存通道；调整 PTP 同步周期，确保时间戳对齐。优化后，端到端延迟从 120ms 降至 75ms，漏检率明显下降。
# 查看 SoC 各计算单元占用与内存带宽（示例）
cat /sys/kernel/debug/npu/load
cat /sys/kernel/debug/gpu/usage
cat /proc/meminfo | grep -E "MemTotal|MemAvailable"
# 查看传感器时间同步状态
ptp4l -m -i eth0
调优提示：先定位瓶颈在“算力、带宽、同步还是调度”，再选择量化、算子融合、内存对齐、任务优先级或硬件卸载等手段。不要盲目提升芯片频率，车载平台更关注持续稳定性能与能效比。
常见误区：把峰值 TOPS 当作实际可用算力；忽略内存带宽与互联延迟；只测平均延迟而不看 P99；在多传感器融合中忽视时间同步；将功能安全监控与主计算任务混在同一核上运行。
综上，自动驾驶计算平台是传感器、计算芯片、互联总线、安全监控与软件调度的综合体。只有理解其演进逻辑、硬件分工、数据流关系与场景约束，才能在后续基准测试中设计出有意义的指标，并针对真实瓶颈实施有效调优。