3. 硬件平台与计算单元：主流SoC架构与传感器数据通路
聊到自动驾驶的硬件，很多人第一反应就是“堆算力”。但说实话，我在这个行业摸爬滚打这么多年，见过太多“算力很高，但车就是跑不好”的案例。硬件平台的选择，远不止看TOPS（每秒万亿次运算）那么简单。
今天这一章，我们聚焦三个主流SoC架构：NVIDIA Orin、Qualcomm Snapdragon Ride、TI TDA4。我会结合我自己的项目经验，聊聊它们各自的脾气秉性，以及MCU和MPU到底怎么分工，传感器数据又是怎么流进来的。
3.1 主流SoC架构对比
先看一张表，快速了解这三款芯片的定位差异。我个人习惯把Orin比作“全能型选手”，Snapdragon Ride是“生态整合王”，而TDA4则是“务实派”。
| 特性 | NVIDIA Orin | Qualcomm Snapdragon Ride | TI TDA4 |
|---|---|---|---|
| 算力范围 | 254 TOPS（单芯片） | 30-700 TOPS（可扩展） | 8-32 TOPS（含DSP） |
| AI引擎 | Ampere架构GPU + DLA | Hexagon DSP + AI加速器 | C7x DSP + MMA加速器 |
| 典型应用 | L4级Robotaxi | L2+到L4量产车 | L2级ADAS及域控 |
| 功耗 | 15-60W | 5-65W | 5-20W |
| 安全等级 | ASIL-D（部分） | ASIL-D（整体） | ASIL-D（原生） |
3.1.1 NVIDIA Orin：性能猛兽，但要注意散热
Orin是我用得最多的平台。它的GPU算力确实强悍，跑复杂的BEV（鸟瞰视角）感知模型毫无压力。但这里有个坑——功耗和散热。
Orin的另一个特点是它的DLA（深度学习加速器）。我个人建议，如果模型是定点量化后的，尽量走DLA而不是GPU。DLA的能效比高很多，而且不占用GPU资源，可以留给其他视觉处理任务。
3.1.2 Qualcomm Snapdragon Ride：生态好，但别被“可扩展”迷惑
Snapdragon Ride的优势在于它的异构计算架构。Hexagon DSP不仅能跑AI，还能做信号处理。我有个朋友在Tier 1做量产项目，他们用Ride平台做L2+，说最爽的是软件生态——Qualcomm的SDK很完善，从感知到规划都有现成模块。
但要注意，“可扩展”听起来很美，实际做起来并不简单。你想想看，从单芯片30 TOPS扩展到多芯片700 TOPS，数据一致性和任务调度的复杂度是指数级上升的。我建议，如果项目目标明确是L2+，就老老实实用单芯片方案，别一开始就想着“以后升级”。
3.1.3 TI TDA4：务实之选，但别指望它跑大模型
TDA4是我个人很欣赏的一款芯片。它不追求极致算力，但安全性和实时性做得非常扎实。它的C7x DSP和MMA（矩阵乘法加速器）配合起来，跑轻量级CNN模型效率很高。
3.2 MCU与MPU的分工
很多新手会问：为什么自动驾驶系统里既有MCU又有MPU？直接用一个高性能MPU不就行了？
原因很简单：安全与实时性。MPU（比如Orin）跑Linux，功能强大但实时性差，万一系统卡死怎么办？MCU（比如Infineon TC397）跑裸机或RTOS，确定性极高，能在微秒级响应。
我习惯的分工是这样的：
- MPU（主处理器）：负责感知、规划、决策等计算密集型任务。跑Linux或QNX，用ROS 2或DDS通信。
- MCU（安全协处理器）：负责车辆控制、故障诊断、看门狗。跑AUTOSAR或裸机，用CAN/CAN FD通信。
举个例子，我在一个项目中，MPU负责识别前方障碍物，然后把“刹车”指令发给MCU。MCU收到指令后，必须独立验证这个指令是否合理——比如车速、距离、转向角是否匹配。如果MPU发了个“急刹车”但车速只有5km/h，MCU会认为这是异常，直接接管控制权。
3.3 传感器接口与数据通路
传感器数据怎么流进SoC？这里面的门道很多。我见过不少项目，算法模型写得很好，但数据通路设计不合理，导致延迟过高，最终系统表现拉胯。
3.3.1 常见传感器接口
| 传感器类型 | 接口 | 数据量 | 延迟要求 |
|---|---|---|---|
| 摄像头 | MIPI CSI-2 / GMSL | ~2 Gbps（每路1080p@30fps） | < 50ms |
| 激光雷达 | 以太网（UDP） | ~100 Mbps | < 100ms |
| 毫米波雷达 | CAN / CAN FD | ~1 Mbps | < 20ms |
| 超声波 | LIN / I2C | ~10 Kbps | < 200ms |
3.3.2 数据通路设计要点
数据通路说白了就是“数据怎么从传感器走到算法模块”。这里我分享三个经验：
- 摄像头数据走专用通道：别把摄像头数据和激光雷达数据混在一个以太网口上。我建议用GMSL（千兆多媒体串行链路）把摄像头数据直接送到ISP（图像信号处理器），然后通过DMA直接写入SoC的DDR。这样可以避免CPU干预，延迟最低。
- 激光雷达数据要打时间戳：激光雷达的数据包是异步到达的。我曾经踩过一个坑——没有给每个点云帧打硬件时间戳，结果融合时发现摄像头和激光雷达的数据差了50ms，导致目标匹配错位。后来我强制要求所有传感器数据在进入SoC前，必须由FPGA或MCU打上统一的PTP时间戳。
- 毫米波雷达走CAN FD：虽然毫米波雷达数据量不大，但它的实时性要求很高（尤其是AEB场景）。CAN FD的带宽足够，而且延迟确定。别为了省事把它转成以太网，那会增加不必要的协议开销。
3.4 小结
这一章我们聊了三个主流SoC的选型思路，MCU和MPU的分工逻辑，以及传感器数据通路的设计要点。嗯，内容不少，但都是我在项目里实打实踩过的坑。
最后说一句：硬件平台没有最好的，只有最合适的。选型时别光看算力，还要看功耗、散热、安全等级、生态支持。你想想看，一个L2级的项目，非要上Orin，那不是杀鸡用牛刀吗？
下一章，我们会深入聊聊实时操作系统（RTOS）与Linux的混合部署，这是嵌入式系统设计的核心难点。到时候我会分享一个我亲手调过的“双系统通信”案例，保证干货满满。