4、功能不足与触发条件：功能不足的定义、触发条件的分类
各位工程师，咱们今天聊一个实车验证里最让人头疼的问题——功能不足。说白了，就是系统在某些场景下「该干活的时候没干好」。我做了这么多年自动驾驶测试，发现很多团队把精力都放在「系统误动作」上，却忽略了功能不足这个隐形杀手。
你想想看，一辆车在高速上遇到施工改道，系统没识别出锥桶，直接撞上去——这不是系统坏了，而是它压根就没学会处理这种场景。这就是典型的功能不足。
4.1 功能不足的定义
功能不足，英文叫 Function Insufficiency，指的是系统在特定运行域（ODD）内，由于算法、传感器或执行器的能力限制，无法完成预期功能。它跟系统故障不一样——故障是坏了，功能不足是「能力不够」。
核心判断标准：
- 系统没有违反设计规范，但输出结果不满足安全目标
- 在相同条件下，人类驾驶员可以安全完成操作
- 问题可复现，且与硬件故障无关
我记得有一次在高速测试，我们的感知系统在黄昏时分把路边的广告牌误识别成了卡车。你说系统坏了吗？没有。传感器数据正常，算法也没报错。但结果就是——系统一脚急刹，差点被后车追尾。这就是功能不足，而且是典型的感知能力不足。
功能不足通常分为三类：
| 类型 | 描述 | 典型例子 |
|---|---|---|
| 感知不足 | 传感器或感知算法无法正确理解环境 | 强光下无法识别交通标志 |
| 决策不足 | 规划算法在复杂场景下做出不合理决策 | 无保护左转时犹豫不决 |
| 执行不足 | 控制模块无法精确执行规划指令 | 湿滑路面制动距离超出预期 |
4.2 触发条件的分类
功能不足不会凭空出现，它需要特定的「导火索」。我习惯把触发条件分成三大类：系统触发、环境触发、驾驶员触发。这三类触发条件，在实车验证中一个都不能漏。
4.2.1 系统触发
系统触发，指的是车辆自身状态变化导致功能不足暴露。这类触发条件往往被团队忽略，因为大家习惯把注意力放在外部环境上。
常见的系统触发条件包括：
- 传感器退化：摄像头脏污、雷达遮挡、激光雷达衰减
- 计算资源不足：多任务并发导致算法延迟增加
- 系统降级模式：某个传感器失效后，系统切换到备份模式，但备份模式能力不足
- 软件版本变更：OTA升级后，新算法在旧场景上表现退化
我的经验：在实车验证中，一定要设计「传感器退化序列测试」。比如在测试过程中逐步遮挡摄像头，观察系统何时开始出现功能不足。我曾经发现，当摄像头遮挡超过30%时，车道保持功能就开始间歇性失效——这个阈值在仿真里根本测不出来。
4.2.2 环境触发
环境触发是最常见的，也是大家最熟悉的。但我想说的是，环境触发不只是「下雨」「黑夜」这么简单。
我习惯把环境触发条件细分为：
| 子类别 | 具体条件 | 影响的功能 |
|---|---|---|
| 光照条件 | 逆光、黄昏、隧道出入口、夜间无照明 | 视觉感知、目标检测 |
| 天气条件 | 大雨、大雾、雪、冰雹、沙尘 | 传感器探测距离、路面附着系数 |
| 道路条件 | 施工区域、无车道线道路、环形交叉口 | 车道保持、路径规划 |
| 交通参与者 | 异形车辆、行人突然横穿、非机动车混行 | 行为预测、决策规划 |
| 基础设施 | 信号灯故障、标志牌遮挡、V2X通信中断 | 交通规则理解、协同感知 |
嗯，这里要注意一个关键点——环境触发条件往往是组合出现的。比如「黄昏+小雨+施工区域」，这种组合场景才是真正的杀手。单一条件测试通过，不代表组合条件也能通过。
4.2.3 驾驶员触发
这一块容易被忽视。驾驶员触发，指的是驾驶员的操作行为导致系统功能不足暴露。说白了，就是「人机交互出了问题」。
常见的驾驶员触发条件：
- 接管时机不当：驾驶员在系统发出接管请求后，反应时间过长或过短
- 操作冲突：驾驶员和系统同时控制车辆，比如驾驶员踩油门的同时系统在制动
- 模式切换误操作：驾驶员在行驶中误触自动驾驶开关
- 预期功能误解：驾驶员以为系统能处理某个场景，实际上不能
避坑指南：我曾经在测试中遇到一个案例——驾驶员在系统激活状态下，手动调整了方向盘角度，系统检测到驾驶员干预后立即退出自动驾驶。但退出后车辆没有保持车道，直接偏向护栏。原因是系统退出时没有平滑过渡，而是瞬间释放了转向扭矩。这个问题的根因不是系统故障，而是「驾驶员触发退出」这个场景下，功能不足暴露了。
4.3 触发条件与功能不足的关系模型
搞清楚了定义和分类，咱们得把它们串起来。我画了一张图，展示功能不足和触发条件之间的关系：
从这张图你能看出来，功能不足是「果」，触发条件是「因」。同一个功能不足，可能由多种触发条件引起。比如车道保持功能失效，可能是传感器退化（系统触发），也可能是车道线磨损（环境触发），还可能是驾驶员误操作导致系统退出（驾驶员触发）。
4.4 实车验证中的设计要点
知道了这些，咱们在实车验证中该怎么设计场景？我总结了几个要点：
- 穷举触发条件组合：不要只测单一触发条件，重点测组合条件。比如「夜间+大雨+施工区域」这种三重组合。
- 设计退化测试序列：逐步增加触发条件的强度，找到功能不足的临界点。比如从10%遮挡开始，逐步增加到50%遮挡。
- 引入驾驶员行为变量：在测试场景中加入驾驶员的不同操作模式，比如快速接管、延迟接管、误操作等。
- 记录触发条件上下文：每次发现功能不足，必须记录完整的触发条件上下文，包括系统状态、环境参数、驾驶员操作序列。
我的习惯：在测试报告中，我会用「触发条件矩阵」来记录每次测试的触发条件组合。横轴是系统触发条件，纵轴是环境触发条件，深度维度是驾驶员触发条件。这样一眼就能看出哪些组合还没覆盖到。
好了，这一节的内容就到这里。功能不足和触发条件的关系，是SOTIF场景设计的核心逻辑。搞清楚了这些，你才能设计出真正能暴露问题的实车验证场景。