2. SOTIF核心概念：功能不足、触发条件、危害事件、可控性、安全目标

好，咱们进入正题。SOTIF 这套方法论，说白了就是围绕五个核心概念转的。你把这五个概念吃透了，ISO 21448 落地就成功了一半。我个人习惯，每次给团队培训，都会先让大家把这五个词刻在脑子里。

2.1 功能不足（Functional Insufficiency）

什么是功能不足？别想复杂了。就是「这功能本身有缺陷，导致它没法正确应对它应该能应对的场景」。注意，这不是说硬件坏了，也不是软件有 bug，而是功能定义或实现上的局限性。

我举个例子。你车上的自动紧急制动（AEB），设计时假设前车是标准的轿车或 SUV。结果呢？前面是个拖着挂车的卡车，挂车底盘很高，AEB 的传感器从挂车底下穿过去了，没检测到。车没刹，撞了。这就是功能不足——传感器能探测到，算法也能算，但系统对「前方障碍物」的模型定义不够全。

功能不足通常分两类：

• 规格不足： 设计时就没考虑到某些场景。比如车道保持系统没考虑雨雪天车道线被覆盖的情况。
• 实现局限： 规格写了，但算法或传感器能力达不到。比如要求 100 米外识别行人，但实际只能稳定识别 50 米。

2.2 触发条件（Triggering Conditions）

功能不足本身不一定会出事。它得被「激活」。这个激活它的东西，就是触发条件。

你想想看，一个功能不足可能一直存在，但只有特定条件出现时，它才会导致危害。触发条件可以是：

• 环境条件： 暴雨、大雾、逆光、隧道出入口的明暗突变。
• 场景条件： 复杂路口、施工区域、突然窜出的动物。
• 系统状态： 传感器被泥巴遮挡、计算单元过载、定位精度下降。

我记得有一次做项目，发现一个自适应巡航（ACC）的功能不足：它在前车急减速时，制动介入太晚。但这个问题在干燥路面上几乎没影响，因为轮胎抓地力够。可一旦路面湿滑，触发条件来了——制动距离变长，追尾风险急剧上升。你看，同一个功能不足，触发条件不同，后果天差地别。

2.3 危害事件（Hazardous Event）

功能不足 + 触发条件 = 危害事件。就这么简单。

危害事件是「在特定运行场景下，功能不足被触发，导致人员受伤或财产损失的事件」。它必须包含三个要素：

1. 具体的危害： 比如「车辆意外加速」、「转向失控」、「制动距离过长」。
2. 具体的场景： 比如「在高速公路上以 120km/h 行驶时」。
3. 具体的后果： 比如「导致追尾，可能造成乘员颈部受伤」。

这里有个坑，我踩过。很多人写危害事件，只写「车辆失控」。这不行。失控在停车场和失控在高速上，严重程度完全不一样。危害事件必须把场景说清楚。

2.4 可控性（Controllability）

危害事件发生了，驾驶员能不能救回来？这就是可控性。

可控性评估的是「在危害事件发生时，典型的驾驶员（不是赛车手，也不是新手）有多大能力避免伤害」。ISO 21448 里可控性分三个等级：

• C0： 可控。驾驶员通常能轻松避免。比如 ACC 在畅通路上突然取消，驾驶员自己踩油门就行。
• C1： 简单可控。大部分驾驶员能避免，但需要一定反应。比如 AEB 误触发，但驾驶员能及时接管。
• C2： 难控。只有少数经验丰富的驾驶员能避免，或者需要极快的反应。比如高速上突然的转向干预。
• C3： 不可控。驾驶员基本没办法。比如在弯道内侧突然爆发出不合理的加速。

2.5 安全目标（Safety Goal）

最后，我们得给每个不可接受的危害事件定一个安全目标。安全目标就是一句话：「系统必须避免……发生」。它是顶层安全要求，不涉及具体实现。

安全目标的写法有讲究：

• 格式： 「系统应避免 [危害事件] 发生」或「当 [触发条件] 发生时，系统应确保 [安全状态]」。
• 粒度： 一个危害事件对应一个安全目标。别合并，也别拆分太细。
• 可验证： 安全目标要能通过测试或分析来确认是否满足。

举个例子：

• 危害事件： 在高速公路上以 120km/h 行驶时，ACC 在前车急减速后制动介入过晚，导致追尾。
• 安全目标： 系统应确保在高速工况下，ACC 对前车急减速的响应时间不超过 0.5 秒，以避免追尾。

你看，这个安全目标是可验证的——我可以通过测试来测响应时间。

2.6 五个概念的关系

这五个概念不是孤立的。它们是一条链：

这条链的逻辑是：

1. 先找到系统的功能不足。
2. 再分析什么触发条件会激活它。
3. 组合成具体的危害事件。
4. 评估危害事件的可控性。
5. 对不可接受的危害事件，制定安全目标。

嗯，这里要注意：不是所有危害事件都需要定安全目标。如果可控性评估结果是 C0 或 C1，且风险可接受，那可能就不需要额外的安全目标。但如果是 C2 或 C3，那必须定目标来降低风险。