2. SOTIF核心概念：功能不足与触发条件、已知与未知场景、安全接受准则
大家好，我是老张。今天咱们来聊聊SOTIF里最核心的几个概念。说实话，我刚接触SOTIF那会儿，也被这些术语绕得头晕。什么功能不足、触发条件、已知未知场景……听着都差不多，但实际用起来差别大了去了。
我个人的习惯是，先把这些概念拆开揉碎了，再串起来。咱们今天就干这件事。
2.1 功能不足：不是故障，是“能力不够”
先问大家一个问题：一辆车的摄像头在暴雨天看不清路，这是故障吗？
不是。摄像头没坏，传感器也没报错。它就是能力不够——在那种天气下，它的性能达不到安全要求。这就是典型的功能不足。
功能不足（Function Insufficiency），说白了就是系统在设计时就有“短板”。它不是硬件坏了，也不是软件崩溃了，而是系统在特定条件下，没法完成它该完成的任务。
我举个例子。有一次我在测试一个自动紧急制动系统，白天测了100次，全都稳稳刹停。结果一到黄昏，光线变暗，系统就开始“抽风”——有时候能刹住，有时候刹不住。你说这是故障吗？不是。传感器在弱光下的性能就是不够，这就是功能不足。
- 功能不足 ≠ 故障（故障是坏了，功能不足是“本来就不够”）
- 功能不足是设计阶段就存在的“先天缺陷”
- SOTIF主要解决的就是功能不足带来的风险
2.2 触发条件：压垮骆驼的最后一根稻草
功能不足本身不一定出问题。它需要一个“导火索”，这个导火索就是触发条件。
触发条件可以是环境因素，比如大雾、逆光、路面标线模糊；也可以是场景因素，比如突然窜出来的行人、前方车辆急刹。
我遇到过最典型的触发条件是什么？是“鬼探头”。一个小孩从路边停着的两辆车中间突然跑出来。系统从发现到决策，时间窗口可能只有0.3秒。你说系统反应慢？其实不是。是触发条件太极端，超出了系统设计时的预期。
所以，功能不足 + 触发条件 = 危险事件。这两个东西缺一不可。
2.3 已知场景 vs 未知场景：你永远不知道你不知道什么
这个概念很有意思。SOTIF把场景分成四类：
- 已知安全场景：系统能处理，且安全
- 已知危险场景：系统处理不了，但你知道它处理不了
- 未知安全场景：系统能处理，但你不知道它能处理
- 未知危险场景：系统处理不了，而且你根本不知道有这回事
你想想看，最可怕的是哪个？当然是未知危险场景。你连问题在哪都不知道，怎么修？
我记得有一次，我们在做高速公路领航功能的测试。所有已知场景都过了，结果车一进隧道，系统就开始“画龙”——左右摇摆。后来一查，是隧道里的灯光频闪干扰了摄像头。这个场景我们之前完全没想到，就是典型的未知危险场景。
所以SOTIF的核心工作之一，就是把未知变成已知。怎么变？靠测试、靠仿真、靠路采数据、靠分析。
2.4 安全接受准则：到底多安全才算安全？
这个问题，说实话，没有标准答案。但SOTIF给了我们一个框架。
安全接受准则，就是判断系统是否“足够安全”的标尺。它不是绝对的“零事故”，而是“风险可接受”。
怎么定义“可接受”？一般从两个维度看：
| 维度 | 说明 | 例子 |
|---|---|---|
| 严重度 | 事件造成的伤害程度 | 轻微剐蹭 vs 致命碰撞 |
| 发生频率 | 事件发生的概率 | 每百万公里一次 vs 每千公里一次 |
我个人的习惯是，先定一个“不可接受”的底线。比如：任何可能导致重伤或死亡的事件，发生频率必须低于某个阈值。这个阈值怎么定？参考行业标准，比如ISO 21448里提到的GAMAB（Globalement Au Moins Aussi Bon，整体至少同样好）原则——自动驾驶至少要比人类驾驶员安全。
但这里有个坑：人类驾驶员的安全水平本身就不稳定。有人开车十年不出事，有人天天剐蹭。所以安全接受准则不是死的，它需要根据实际运营数据不断调整。
2.5 知识体系总览
说了这么多，咱们用一张图把核心逻辑串起来。下面这张SVG图，是我自己画的结构图，帮你理清这几个概念之间的关系。
这张图的核心逻辑是：功能不足和触发条件共同导致危险事件。而危险事件是否可接受，需要放到场景分类里去看——是已知还是未知？安全还是危险？最后，用安全接受准则这把尺子去衡量，决定要不要采取措施。
嗯，这就是SOTIF最底层的逻辑。你把这个逻辑吃透了，后面再讲具体的方法论、工具链，就顺理成章了。