第二章 硬件架构选型：传感器套件与计算平台的量产抉择
各位同学，大家好。这一章我们聊聊硬件选型。说实话，这是量产落地中最「烧钱」也最「烧脑」的环节。我见过太多团队，传感器堆得满满当当，结果车规级认证过不了；也见过算力拉满，结果功耗把热管理搞崩了。今天我就把这些年踩过的坑，掰开了讲给你们听。
2.1 传感器套件：四类传感器的选型与对比
先问大家一个问题：为什么量产车很少用 128 线激光雷达？
答案很简单——成本与可靠性的博弈。我曾在 2019 年参与过一个项目，当时为了追求「全场景覆盖」，上了 5 颗 64 线激光雷达。结果呢？冬天一场大雪，雷达视窗结冰，整个系统直接降级。从那以后，我养成了一个习惯：选传感器，先看它的「生存能力」。
2.1.1 摄像头：视觉的「眼睛」
摄像头是唯一能提供语义信息的传感器。红绿灯、车道线、交通标志，都得靠它。但它的短板也很明显——怕黑、怕逆光、怕雨雾。
| 参数 | 典型量产方案 | 我的建议 |
|---|---|---|
| 分辨率 | 200万~800万像素 | 前视至少 800 万，侧视 200 万够用 |
| 帧率 | 30~60 fps | 高速场景建议 60fps，否则运动模糊严重 |
| 动态范围 | 120~140 dB | 低于 120dB 的，隧道进出直接过曝 |
2.1.2 激光雷达：精度与成本的博弈
激光雷达的选型，说白了就是「你要多远的探测距离」和「你愿意花多少钱」。目前量产主流是 96 线或 128 线，但注意——线数不是越高越好。
- 机械式：精度高，但旋转部件寿命是硬伤。我见过跑 5000 小时就出现磨损的。
- 固态式（MEMS/Flash）：车规级首选，但视场角有限。一般需要 3~5 颗拼接。
- 补盲激光雷达：近场必备，尤其是侧向和后方。别省这个钱，我吃过亏。
2.1.3 毫米波雷达：全天候的「老黄牛」
毫米波雷达最大的优势是——不怕雨雪雾。但它的分辨率低，无法区分行人还是自行车。我习惯把它当作「距离传感器」来用，而不是「目标分类器」。
选型时重点关注两个参数：
- 角分辨率：4D 毫米波雷达能做到 1° 以内，传统 3D 雷达一般在 5°~10°。
- 速度分辨率：0.1 m/s 以下才能准确检测静止目标。
嗯，这里要提一句。我曾经在高速上遇到过毫米波雷达把路牌当障碍物，导致急刹车。后来排查发现，是雷达的「多径反射」没处理好。所以，选雷达一定要看它的抗干扰算法。
2.1.4 超声波雷达：近场泊车的「最后一道防线」
超声波雷达便宜、可靠，但只能用于低速近场。量产车上一般装 8~12 颗，覆盖前后保险杠。
我个人习惯用超声波来做「近距离冗余」。比如，当摄像头被泥巴糊住时，超声波还能告诉你「前面 30 厘米有墙」。别小看这个功能，我见过有车在自动泊车时，因为超声波失效，直接怼上了柱子。
2.2 计算平台：域控制器的算力与功耗平衡
算力不是万能的，但没有算力是万万不能的。但问题在于——算力每提升 1 TOPS，功耗可能增加 0.5~1 瓦。而量产车的散热能力是有限的。
我给大家一个经验公式：实际可用算力 ≈ 标称算力 × 0.7。为什么？因为芯片降频、内存带宽瓶颈、软件开销，都会吃掉一部分性能。
| 算力等级 | 典型芯片 | 功耗范围 | 适用场景 |
|---|---|---|---|
| 30~50 TOPS | TDA4、Orin NX | 15~30W | L2+ 基础智驾 |
| 100~200 TOPS | Orin、Snapdragon Ride | 45~75W | L2++ 城市领航 |
| 500+ TOPS | Thor、Drive AGX | 150~300W | L3/L4 高阶自动驾驶 |
2.2.1 功耗平衡的「三把尺」
怎么平衡？我总结了三把尺子：
- 热设计功耗（TDP）：芯片的持续功耗，决定了散热器的大小。别只看峰值功耗，那没意义。
- 能效比（TOPS/W）：每瓦能提供多少算力。目前主流在 2~5 TOPS/W 之间。
- 实际负载功耗：跑真实算法时的功耗。我建议用「城市领航」场景来测，因为这是最耗算力的工况。
举个例子。Orin 标称 75W，但实际跑 BEV 感知 + 规划控制时，功耗在 55~65W 之间。如果你按 75W 设计散热，那还有 10W 的余量。但如果你按 100W 设计，那就是浪费成本和空间。
2.3 硬件冗余设计原则：别让一个故障毁了整个系统
硬件冗余，说白了就是「如果这个坏了，还有另一个顶着」。但冗余不是简单的「双倍堆料」，而是有策略的。
2.3.1 传感器冗余：异构 vs 同构
我建议采用异构冗余。什么意思？就是摄像头、激光雷达、毫米波雷达，三种传感器互相备份。比如，摄像头看不清时，激光雷达还能顶上；激光雷达坏了，毫米波雷达还能提供距离信息。
同构冗余（比如装两个一样的摄像头）也有用，但只能应对「硬件故障」，不能应对「环境失效」。你想想看，如果大雾天，两个摄像头都看不清，那冗余还有意义吗？
2.3.2 计算平台冗余：主备切换
域控制器一般设计成「双芯片」或「双板卡」。一个主控，一个备份。切换时间要控制在 100ms 以内，否则车辆会进入「安全降级」状态。
我曾经遇到过一个问题：主芯片死机后，备份芯片启动需要 2 秒。这 2 秒里，车辆完全失控。后来我们加了「看门狗」和「快速启动」机制，才把切换时间压到 50ms。
2.3.3 通信冗余：CAN、以太网双备份
传感器到域控制器的通信链路，也要冗余。一般用 CAN 总线做低速控制，以太网做高速数据传输。两条链路互相独立，一条断了，另一条还能工作。
嗯，这里要注意。CAN 总线的带宽只有 1 Mbps，只能传控制指令，不能传原始点云。所以，激光雷达和摄像头的数据，一定要走以太网。CAN 只是「保底」用的。
2.4 总结：选型就是做「减法」
说了这么多，其实就一句话：硬件选型不是选最好的，而是选最合适的。
我见过太多团队，一开始什么都想要，结果成本爆炸、散热爆炸、可靠性还不行。真正量产落地的方案，往往是「够用就好，留有余地」。
最后送大家一句话：硬件架构决定了系统的上限，而冗余设计决定了系统的下限。上限可以慢慢优化，但下限一旦失守，就是安全事故。
好，这一章就到这里。下一章我们聊聊「软件架构设计」，到时候我会讲讲怎么把算法部署到域控制器上，以及那些年我遇到的「内存泄漏」惨案。
公众号：蓝海资料掘金营，微信 deep3321