3. 危险行为识别：实车验证中的常见危险行为与触发条件
实车验证做到一定阶段，你会发现一个规律：大部分危险行为其实就那几类。我这些年跑过的测试里程加起来也有小十万公里了，踩过的坑、见过的险情，归纳下来无非是感知漏检、决策误判、执行偏差这三条主线。
这一章，咱们就掰开揉碎聊聊：危险行为长什么样？什么条件下会冒出来？最终会导致什么危害？
3.1 感知类危险行为：系统「看不见」或「看错」
感知出问题，说白了就是车没「看见」该看见的东西，或者「看错了」。这是实车验证里最常见、也最难穷举的一类。
3.1.1 漏检：目标物存在但系统未识别
漏检的典型场景我列几个，你对照着想想自己的测试用例里有没有：
- 小目标漏检：比如路中间一个掉落的轮胎、一个锥桶、一只横穿的小动物。摄像头像素不够、雷达回波弱，系统直接忽略。
- 部分遮挡目标：行人从停着的公交车头前突然走出，车辆只看到上半身——很多系统在这个场景下会「丢帧」。
- 低对比度目标：灰色水泥路上的灰色石墩、白色雪地上的白色行人。我在北方冬季测试时就遇到过，雪地里的行人，激光雷达点云稀疏，摄像头也几乎分不清。
- 极端光照：进出隧道瞬间、逆光、夜间无路灯路段。摄像头动态范围不够，直接「瞎」一两秒。
3.1.2 误检：系统「看见」了不存在的东西
误检的危害有时候比漏检还大。为什么？因为系统会基于错误的目标做出错误的决策。
| 误检类型 | 典型触发条件 | 实车表现 |
|---|---|---|
| 鬼影误检 | 路面水渍反光、桥下阴影边界 | 系统识别为障碍物，触发急刹 |
| 广告牌/海报误检 | 大型广告牌上的人像/车辆图案 | 系统误认为真实目标，减速或变道 |
| 隧道出口误检 | 隧道出口的亮斑被识别为前车尾灯 | 系统跟「假目标」保持车距，车速异常 |
| 雷达多径反射 | 隧道内、高架桥下、金属护栏旁 | 雷达检测到虚假目标位置，导致误制动 |
我建议你在设计SOTIF场景时，专门建一个「感知对抗库」——把各种容易引发误检的环境条件组合起来，形成专项测试用例。
3.2 决策类危险行为：系统「想错了」
感知没问题，目标都看见了，但决策层做出了错误的判断。这类问题在实车验证中往往更隐蔽，因为系统「看起来在正常工作」。
3.2.1 行为预测错误
系统预测其他交通参与者的意图，但猜错了。举个例子：
- 行人站在路边看手机，系统预测他会继续停留，结果他突然起步横穿。
- 相邻车道车辆打了转向灯但未立即变道，系统以为他要变道于是减速，结果对方又关掉了转向灯。
- 自行车在路口减速，系统预测他会停车，结果他只是减速观察然后继续骑行。
这类问题的触发条件，说白了就是人类行为的不确定性。你想想看，连人类驾驶员都经常猜错其他司机的意图，何况是算法？
3.2.2 路径规划冲突
多目标博弈时，系统陷入「死锁」或做出反直觉的路径选择。我遇到过这样一个案例：
3.2.3 功能边界误判
系统对自己的能力边界认知不清。明明已经超出ODD（运行设计域），但系统没有及时发出接管请求，或者发出了但留给驾驶员的反应时间不够。
常见的触发条件：
- 道路曲率逐渐增大，系统没有提前减速，直到弯中才发现「过不去了」。
- 天气从晴朗逐渐转为小雨，雨量传感器触发阈值设置不合理，系统在「可用」和「不可用」之间反复切换。
- 高精地图数据陈旧，前方施工改道，系统仍按旧地图规划路径。
3.3 执行类危险行为：系统「做不了」或「做不对」
决策做完了，指令发出去了，但执行层没跟上。这类问题在实车验证中往往和硬件、通信、时间相关。
3.3.1 响应延迟
从决策到执行，中间有太多环节可能引入延迟：
- 通信延迟：CAN总线负载高时，制动指令可能延迟几毫秒到几十毫秒。别小看这几毫秒，60km/h车速下，50ms延迟意味着近1米的制动距离差异。
- 执行器响应：线控制动系统的建压时间、转向电机的响应时间，在低温或低电量条件下会显著变差。
- 系统降级：某个ECU故障触发降级模式，降级后的控制周期变长，响应变慢。
3.3.2 控制精度不足
指令发了，但执行结果和预期有偏差。比如：
- 横向控制：系统要求转向5°，实际转向4.2°或5.8°，在高速行驶时会导致车辆逐渐偏离车道中心。
- 纵向控制：要求减速度3m/s²，实际只有2.2m/s²，导致跟车距离过近或制动不及。
- 复合工况：同时要求转向和制动，两个执行器之间的协调出现问题，导致车辆出现非预期的横摆。
3.4 危害事件分析：从危险行为到实际后果
识别出危险行为和触发条件之后，下一步就是分析它们会导致什么危害。我一般用下面这个表格来梳理：
| 危险行为 | 触发条件 | 危害事件 | 严重度 |
|---|---|---|---|
| 行人漏检 | 夜间+逆光+行人穿深色衣服 | 车辆未减速，与行人碰撞 | S3（致命） |
| 鬼影误检 | 路面水渍反光+阳光角度 | 系统急刹，后车追尾 | S2（重伤） |
| 预测错误 | 路口+行人突然折返 | 车辆启动后与行人刮擦 | S2（重伤） |
| 执行延迟 | 低温+低电量+紧急制动 | 制动距离超标，追尾前车 | S2（重伤） |
| ODD误判 | 雨天+系统未降级 | 车辆在湿滑路面失控 | S3（致命） |
做完这个分析，你就能清楚地知道：哪些场景必须优先验证，哪些场景可以放在后面。严重度S3的场景，一个都不能漏。
3.5 实车验证中的危险行为捕捉方法
最后聊点实操层面的东西。在实车验证中怎么高效地捕捉这些危险行为？我总结了几条经验：
- 数据驱动的异常挖掘：跑完测试后，用工具扫描所有「接管事件」「AEB触发事件」「车道偏离事件」，把这些事件对应的传感器数据、决策日志、执行器响应全部拉出来分析。
- 边缘场景专项测试：针对已知的触发条件，设计专门的测试用例。比如「隧道进出连续10次」「夜间无路灯路段5公里」「雨天+积水路面紧急制动」。
- 随机化测试：在安全可控的封闭场地内，引入随机因素——突然出现的假人、随机移动的目标车、随机变化的照明条件。这类测试往往能发现你「没想到」的危险行为。
- 交叉验证：同一个场景，换不同的驾驶员、不同的天气条件、不同的车辆负载重复测试。你会发现，很多危险行为只在特定组合下才会出现。
嗯，这一章的内容就到这里。危险行为识别是SOTIF场景设计的基石，你花多少功夫在这上面，后面的验证工作就会有多顺利。