第二章：自动驾驶系统架构与故障模型
大家好，我是你们的老朋友。今天咱们聊聊自动驾驶的“骨架”——系统架构，以及它身上可能出现的“毛病”——故障模型。
说实话，我刚入行那会儿，觉得自动驾驶就是个“摄像头+算法+油门”的简单组合。后来踩了坑才发现，这玩意儿复杂得像个精密的瑞士钟表。任何一个齿轮卡壳，车都可能“罢工”。
2.1 感知层：车的“眼睛”和“耳朵”
感知层负责收集环境信息。说白了，就是让车知道“我在哪”、“周围有啥”。
常见的传感器包括：
- 摄像头：识别车道线、交通标志、行人。我遇到过最头疼的问题——逆光时摄像头直接“失明”。
- 激光雷达（LiDAR）：生成3D点云，测距精准。但雨雪天性能会打折扣，这个坑我踩过。
- 毫米波雷达：擅长测速和测距，不受天气影响。但分辨率低，分不清“静止的卡车”和“路边的广告牌”。
- 超声波雷达：近距离泊车用。便宜，但探测距离短。
关键点：感知层故障，往往不是传感器坏了，而是“数据质量”出了问题。比如摄像头被泥巴糊住，或者激光雷达被强光干扰。
2.2 决策层：车的“大脑”
决策层接收感知数据，然后做出判断：“现在该加速还是刹车？要不要变道？”
它通常包含：
- 预测模块：预测周围车辆、行人的轨迹。我见过一个案例——预测模块把“正在减速让行”的车，误判为“准备加速抢行”，结果系统急刹车，差点追尾。
- 规划模块：生成行驶路径。包括全局路径（从A到B）和局部路径（接下来几秒怎么走）。
- 控制模块：把规划结果转化为方向盘转角、油门/刹车信号。
个人经验：决策层的故障，很多时候是“逻辑冲突”。比如“避让行人”和“保持车道”同时触发，系统就懵了。我曾经调试过一个bug——车在十字路口反复横跳，就是因为两个规划目标打架。
2.3 执行层：车的“手脚”
执行层负责把决策层的指令，变成真实的机械动作。包括：
- 线控转向：电子信号控制方向盘转动。
- 线控制动：电子信号控制刹车卡钳。
- 线控油门：电子信号控制发动机/电机输出。
执行层的故障，往往最危险。因为它是“最后一公里”。
注意：执行层故障，不一定是硬件坏了。可能是通信延迟——你想想看，决策层说“刹车”，但信号在CAN总线上堵了200毫秒，车已经撞上去了。我在项目中遇到过，线控刹车的响应时间从100ms漂移到500ms，排查了三天才发现是线束接触不良。
2.4 常见故障类型与模型
搞清楚了架构，咱们再来看看故障。我习惯把故障分成三类：
| 故障类型 | 描述 | 举例 |
|---|---|---|
| 永久性故障 | 坏了就是坏了，不会自己恢复 | 摄像头被撞碎、激光雷达烧毁 |
| 间歇性故障 | 时好时坏，随机出现 | GPS信号受高楼遮挡，时断时续 |
| 瞬态故障 | 瞬间发生，很快消失 | 电磁干扰导致CAN报文丢帧 |
针对这些故障，我们建立了对应的故障模型：
- 传感器故障模型：比如“摄像头图像冻结”、“激光雷达点云缺失”、“雷达信号衰减”。
- 通信故障模型：比如“CAN总线丢包”、“以太网延迟抖动”、“信号超时”。
- 计算故障模型：比如“CPU过载导致规划延迟”、“内存泄漏导致系统崩溃”。
- 执行器故障模型：比如“转向卡死”、“制动失效”、“油门不回位”。
避坑指南：我曾经犯过一个错误——只测试了“单个传感器故障”，忽略了“多个传感器同时故障”的场景。结果有一次测试中，摄像头和激光雷达同时被泥巴糊住，系统直接“裸奔”，差点撞上护栏。从那以后，我坚持做“组合故障注入”。
2.5 故障注入的切入点
知道了故障模型，怎么注入呢？我建议从三个层面入手：
- 数据层面：修改传感器数据流。比如给摄像头图像加噪点、给激光雷达点云加随机偏移。
- 通信层面：模拟网络延迟、丢包、报文篡改。我常用一个工具叫“CANoe”，可以轻松注入CAN总线故障。
- 计算层面：模拟CPU负载过高、内存不足。比如在测试时，后台跑一个“死循环”程序，看看决策层会不会超时。
小技巧：故障注入不是“乱搞”。一定要有明确的“故障模型”和“预期行为”。比如你注入“摄像头图像冻结”，预期行为应该是“系统切换到雷达为主传感器，并降速行驶”。如果系统直接崩溃，那就是bug。
好了，这一章就聊到这儿。下一章咱们会深入讲“故障注入工具链”，包括怎么搭建自动化测试环境。嗯，到时候我会分享一个我亲手写的Python脚本，专门用来批量注入传感器故障。
最后提醒一句：故障注入测试，一定要在仿真环境或封闭场地进行。千万别在开放道路上搞，那是拿命开玩笑。我见过有人直接在高速上拔传感器插头...嗯，后果很严重。