第2章：SOTIF标准解读：ISO 21448标准框架、核心术语
大家好，我是老张。今天咱们聊聊ISO 21448这个标准。
说实话，我第一次接触这个标准时，头都是大的。满篇的术语，什么功能不足、触发事件、危害事件...读起来像天书。但干这行十几年了，我慢慢摸出了门道。
ISO 21448，说白了就是告诉你：“你的车在正常开的时候，会不会因为一些意想不到的情况出问题？”
嗯，这里要注意，它跟ISO 26262不一样。26262管的是硬件随机失效和系统故障，而21448管的是“功能本身没问题，但环境或场景导致的问题”。我打个比方：
- ISO 26262：刹车踏板断了，这是硬件失效。
- ISO 21448：刹车没问题，但路面结冰了，你踩刹车ABS介入，车还是滑出去了。这是功能不足。
明白了吧？一个是“坏了”，一个是“不够好”。
2.1 标准框架：一张图看懂ISO 21448
先看这张框架图，我亲手画的。它把整个标准的核心逻辑串起来了。
这张图我反复改过很多版。你看，从左到右，从上到下，逻辑非常清晰：
- 先定义功能：你的系统要干什么？比如自动紧急制动（AEB）。
- 找功能不足：这个功能在哪些情况下表现不够好？
- 找触发事件：什么场景会暴露这个不足？
- 组合成危害事件：不足 + 触发 = 危害。
- 评估风险：这个危害有多严重？概率多大？
- 验证确认：怎么证明它安全了？
我个人习惯，做项目时先把这张图贴在白板上。团队开会时，指着图说：“我们现在卡在第二步，功能不足还没找全。” 大家一下就明白了。
2.2 核心术语：功能不足
功能不足，英文叫functional insufficiency。这是ISO 21448里最核心的概念。
什么意思呢？就是你的系统本身没坏，但在某些条件下表现不够好。
举个例子。我参与过一个AEB项目，系统在白天、晴天、干燥路面下表现完美。但有一次测试，傍晚时分，夕阳直射摄像头，系统居然没检测到前方静止的车辆！
这不是摄像头坏了，也不是算法有bug。而是在强逆光条件下，感知算法的性能下降了。这就是功能不足。
功能不足的常见类型：
- 感知不足：传感器在雨雾、黑夜、强光下性能下降
- 算法局限：目标检测模型对罕见物体（如翻倒的卡车）识别率低
- 执行器限制：制动系统在冰雪路面无法达到预期减速度
- 决策边界：系统在复杂路口无法做出合理决策
我记得有一次评审，一个年轻工程师说：“我们的算法在99%的场景下都OK。” 我问他：“那剩下的1%是什么？你找出来了吗？” 他愣住了。
嗯，这里要注意：功能不足不是bug，不是失效，而是“能力边界”。你不可能让系统在所有场景下都完美，但你必须知道它的边界在哪里。
2.3 核心术语：触发事件
触发事件，英文triggering event。它指的是导致功能不足被暴露的那个场景或条件。
还是刚才那个AEB的例子：
- 功能不足：摄像头在强逆光下感知性能下降
- 触发事件：傍晚时分，夕阳直射摄像头，前方有静止车辆
你看，没有触发事件，功能不足可能永远不会导致问题。但一旦触发事件出现，危害就来了。
触发事件可以分成几类：
| 类别 | 举例 | 说明 |
|---|---|---|
| 环境条件 | 雨、雪、雾、强光、夜间 | 传感器性能受天气影响 |
| 道路场景 | 急弯、隧道、施工区、无车道线 | 系统无法理解复杂场景 |
| 用户行为 | 驾驶员突然接管、误操作 | 人机交互边界不清晰 |
| 其他交通参与者 | 行人突然横穿、非机动车逆行 | 预测算法无法处理异常行为 |
| 系统自身状态 | 传感器脏污、定位精度下降 | 系统退化但未完全失效 |
我曾经犯过一个错误。在一个项目中，我们只考虑了“典型”触发事件，比如雨天、夜间。结果实车测试时，一个洒水车经过，水雾导致激光雷达误检，系统来了个急刹车。乘客差点飞出去。
从那以后，我养成了一个习惯：找触发事件时，要“变态”一点。想想最极端、最离谱的场景。因为现实世界永远比你想象的更复杂。
2.4 核心术语：危害事件
危害事件，英文hazardous event。它是功能不足 + 触发事件组合后，导致人员受伤或财产损失的事件。
注意，不是所有“功能不足 + 触发事件”都叫危害事件。只有真正导致安全后果的才算。
举个例子：
- ACC自适应巡航在隧道内丢失目标（功能不足）
- 隧道内前车减速（触发事件）
- ACC未及时减速，导致追尾（危害事件）
但如果隧道内没有前车，或者驾驶员及时接管了，那就没有危害事件。所以，危害事件 = 功能不足 + 触发事件 + 安全后果。
避坑指南：
我曾经见过一个团队，把“功能不足”和“危害事件”混为一谈。他们列了一堆功能不足，然后直接说“这些都要解决”。结果工作量巨大，根本做不完。
正确的做法是：先分析功能不足，再找触发事件，最后评估危害事件的严重性。只有那些严重性高、发生概率大的危害事件，才需要优先处理。
2.5 标准框架的五个阶段
ISO 21448把整个SOTIF活动分成了五个阶段。我用自己的话总结一下：
- 阶段一：功能定义与规范
- 明确系统要做什么
- 定义功能边界和性能指标
- 我习惯在这个阶段就列出“已知的不足”
- 阶段二：危害分析与风险评估
- 找功能不足
- 找触发事件
- 组合成危害事件
- 评估风险等级
- 阶段三：功能改进
- 针对高风险项，改进算法或增加冗余
- 比如加个毫米波雷达，弥补摄像头在雨雾天的不足
- 阶段四：验证与确认
- 仿真测试、实车测试、场景库测试
- 证明风险已经降低到可接受水平
- 阶段五：运行阶段监控
- 车卖出去后，还要持续监控
- 发现新的触发事件，及时OTA更新
这五个阶段不是线性的。你可能会在验证阶段发现新的功能不足，然后回到阶段二重新分析。说白了，这是个迭代的过程。
2.6 我的实战心得
最后，分享几个我踩过的坑：
Tip 1：别只盯着标准条文
ISO 21448给了你框架，但没告诉你具体怎么做。我见过有人把标准背得滚瓜烂熟，但一做项目就懵。记住：标准是地图，不是路。你得自己走。
Tip 2：场景库是核心资产
找触发事件，说白了就是找场景。我建议每个团队都建一个场景库，把测试中遇到的所有异常场景都记录下来。这个库越丰富，你的SOTIF分析就越扎实。
Tip 3：别追求100%安全
你不可能覆盖所有场景。ISO 21448也说了，目标是“合理可预见的”场景。所以，把精力放在那些发生概率高、后果严重的场景上。剩下的，靠运行阶段监控来兜底。
好了，这一章就到这里。ISO 21448的核心术语和框架，说白了就是：知道你的系统在什么情况下不够好，然后想办法让它更好。就这么简单，也这么难。
公众号:蓝海资料掘金营，微信deep3321