3、功能不足与触发条件：功能不足的定义，功能不足如何导致触发条件，功能不足与危害事件的关系
好，我们进入第三个核心话题。功能不足与触发条件。
说实话，这个概念我刚开始接触SOTIF时也绕了好一阵。你想想看，功能不足听起来像是“功能没做好”，但ISO 21448里给它的定义其实更微妙。我个人习惯把它理解为：系统在特定场景下，能力不够用。
3.1 功能不足的定义
功能不足，英文叫functional insufficiency。它不是故障，不是硬件坏了，也不是软件跑飞了。它指的是：系统在设计和实现层面，对某些场景的应对能力存在缺口。
举个例子。我做过一个自动紧急制动项目。系统在白天、干燥路面下表现完美。但有一次测试，傍晚时分，阳光斜射，摄像头突然“瞎”了——不是坏了，是逆光导致对比度不够，目标漏检了。这就是典型的功能不足。
功能不足 vs 功能故障
- 功能故障：系统该做的事没做到，因为组件坏了（比如传感器断线）。
- 功能不足：系统设计时就没考虑这个场景，或者考虑不充分（比如没处理逆光）。
说白了，功能不足是“能力天花板”的问题。系统在它的设计范围内可能很好，但一出这个范围，就露怯了。
3.2 功能不足如何导致触发条件
好，那功能不足怎么就跟触发条件扯上关系了？
我个人理解是这样的：触发条件，就是那个把功能不足“激活”的外部因素。
你想想看，功能不足本身是静态的。它一直存在，但平时不惹事。直到某个特定的场景条件出现，这个不足才被“触发”，进而可能导致危害。
我画个简单的逻辑链：
功能不足（系统能力缺口）
↓ 遇到
触发条件（特定场景/环境/操作）
↓ 导致
系统行为异常（误动作/漏动作）
↓ 可能引发
危害事件举个例子。我记得有一次做泊车辅助系统。系统的功能不足是：对低矮障碍物（比如路沿、消防栓）的检测能力弱。这个不足平时没事，因为大部分场景下障碍物都高于20cm。但触发条件来了：停车场有一个15cm高的金属地锁。好，系统没检测到，直接压上去。危害事件就是车辆受损。
我的经验：分析触发条件时，别只盯着传感器。算法、执行器、甚至系统架构都可能存在功能不足。我曾经遇到一个案例，功能不足出在决策逻辑上——系统对“鬼探头”场景的预测模型太保守，导致频繁误刹车。触发条件就是“行人从停着的公交车前突然跑出”。
3.3 功能不足与危害事件的关系
这里我要强调一个关键点：功能不足 ≠ 危害事件。中间还隔着触发条件呢。
我见过不少工程师，一发现功能不足就紧张，觉得天要塌了。其实不用。功能不足是常态，任何系统都有能力边界。关键是：这个不足在真实世界中，会不会被触发？触发后后果有多严重？
我们可以用一个二维矩阵来思考：
| 功能不足严重程度 | 触发条件出现概率 | 危害事件风险等级 |
|---|---|---|
| 高（直接导致误判） | 高（常见场景） | 极高（必须处理） |
| 高（直接导致误判） | 低（罕见场景） | 中（可接受或需缓解） |
| 低（轻微偏差） | 高（常见场景） | 低（可接受） |
| 低（轻微偏差） | 低（罕见场景） | 极低（忽略） |
嗯，这里要注意。这个矩阵只是定性分析。实际项目中，我们还要结合危害的严重度（比如是否涉及人身安全）来综合判断。
避坑指南：我曾经犯过一个错误——只关注了“高严重度+高概率”的组合，忽略了“高严重度+低概率”的场景。结果呢？一个罕见的触发条件（比如大雪天+夜间+弯道）在实车测试中出现了，差点出事故。所以，低概率不等于零概率，尤其是涉及安全时。
3.4 小结与个人体会
总结一下今天的内容：
- 功能不足是系统的能力缺口，不是故障。
- 触发条件是激活这个缺口的“扳机”。
- 危害事件是功能不足+触发条件共同作用的结果。
我个人觉得，做SOTIF分析最核心的功夫，就是把功能不足和触发条件一一对应起来。这需要你对系统、对场景、对用户行为都有深刻理解。没有捷径，就是多跑场景、多积累数据、多复盘失败案例。
好，这一章就到这里。下一章我们聊聊怎么系统性地识别触发条件——那才是真正考验功力的地方。