第3章：预期功能安全标准ISO 21448详解
3.1 标准背景：为什么会有SOTIF？
说实话，我刚接触功能安全那会儿，心里一直有个疑问：ISO 26262不是已经把安全讲得很清楚了吗？为什么还要搞个ISO 21448？
后来在项目里吃了亏，才真正明白。ISO 26262处理的是系统故障——硬件坏了、软件写错了，这些它能管。但自动驾驶遇到的情况不一样。你想想看，传感器没坏，算法也没bug，可就是识别不出前方白色卡车——因为阳光太强，摄像头过曝了。
这就是典型的SOTIF问题。系统本身没坏，但功能表现不够好。
ISO 21448就是在这样的背景下诞生的。它专门处理「功能不足」导致的风险。我参与过一个L2级项目，测试时发现毫米波雷达对静止目标的检测率只有60%多。你说雷达坏了吗？没有。但这就是功能不足，必须用SOTIF的方法去解决。
核心区别一句话总结：
- ISO 26262 → 系统坏了怎么办（故障安全）
- ISO 21448 → 系统没坏但不够聪明怎么办（功能不足）
3.2 SOTIF的定义与范围
SOTIF，全称是Safety Of The Intended Functionality。翻译过来就是「预期功能的安全」。嗯，这个名字其实挺绕的。我习惯这么理解：你设计这个功能的时候，预期它能安全地工作。但现实世界总有意外。
ISO 21448明确说了，它覆盖的是：
- 功能不足：系统能力有限，处理不了某些场景
- 触发事件：导致功能不足暴露出来的具体条件
- 可合理预见的误用：用户可能犯的、你能想到的错误操作
我记得有个项目，客户问：「驾驶员把手伸到方向盘外面算不算误用？」我说：「算，但你要区分。如果驾驶员故意把手伸出去，那是滥用。如果他不小心碰到方向盘导致偏离车道，那叫可合理预见的误用——你得考虑进去。」
我的经验：判断一个场景是否属于SOTIF范围，就问自己三个问题：
- 系统本身有没有故障？没有 → 进入SOTIF
- 功能表现是否低于预期？是 → 功能不足
- 这个场景在真实路上会发生吗？会 → 必须处理
3.3 功能不足与触发事件
这两个概念是SOTIF的核心。说白了，功能不足是「病根」，触发事件是「导火索」。
功能不足（Functional Insufficiency）：
- 感知能力有限：摄像头看不清雨夜、雷达测不准静止目标
- 算法局限性：决策模型没见过某种场景
- 系统设计缺陷：比如变道策略过于保守，导致永远变不过去
触发事件（Triggering Event）：
- 环境条件：暴雨、逆光、隧道出入口的光线突变
- 道路条件：车道线模糊、施工区域、急弯
- 其他交通参与者：突然加塞的车辆、横穿的行人
我做过一个很有意思的案例。某款车的AEB功能，在晴天测试表现完美。但一到雨天，制动距离明显变长。一开始大家以为是传感器问题，后来发现是算法对湿滑路面的摩擦系数估计不足。这就是典型的「功能不足+触发事件」组合。
避坑指南：我曾经见过一个团队，把所有测试失败的案例都归为「触发事件」，却不去深挖背后的功能不足。结果就是修了一个又一个场景，永远修不完。记住：触发事件是表象，功能不足才是根源。
3.4 安全性能释放
安全性能释放（Safety Performance Release），是SOTIF落地的最后一步。它回答一个问题：你的系统到底安不安全？能不能上路？
ISO 21448给出了两条路径：
| 路径 | 方法 | 适用场景 |
|---|---|---|
| 路径一 | 通过已知场景的充分验证，证明风险可接受 | 功能不足已被充分识别和缓解 |
| 路径二 | 通过未知场景的探索，证明残余风险足够低 | 存在大量未知场景（如L3以上） |
我个人更倾向于两条腿走路。先做路径一，把已知场景跑透。再用路径二的方法，去发现那些你没想到的场景。
安全性能释放的核心指标是：
- 场景覆盖率：你测试了多少种场景？覆盖了哪些边缘情况？
- 风险接受准则：什么样的风险水平是可以接受的？
- 验证证据链：你的测试数据、仿真结果、分析报告是否完整？
一个实用的判断标准：
如果你能回答以下问题，安全性能释放就基本到位了：
- 「这个场景为什么不会发生？」——有数据支撑
- 「如果发生了，系统会怎么反应？」——有应对策略
- 「最坏情况下的后果是什么？」——有风险评估
3.5 我的落地建议
做了这么多SOTIF项目，我总结了几条经验：
- 别等到最后才做SOTIF。我见过太多项目，功能开发完了才开始分析SOTIF，结果发现一堆问题，改都改不动。最好在概念阶段就启动SOTIF分析。
- 场景库要持续迭代。SOTIF不是一次性工作。你跑的路越多，发现的场景就越多。我建议每季度更新一次场景库。
- 仿真和实车要结合。纯仿真不够真实，纯实车成本太高。我习惯的做法是：用仿真跑覆盖率，用实车验证关键场景。
- 文档要跟上。ISO 21448要求你证明「我做了分析、我做了验证、我接受了风险」。没有文档，等于没做。
一个小技巧：做SOTIF分析时，我习惯用「如果...会怎样」的句式来挖掘触发事件。比如：「如果前方车辆突然急刹，同时后方有大货车，系统会怎样？」「如果车道线被积雪覆盖，同时GPS信号丢失，系统会怎样？」这样能帮你快速找到功能不足的盲区。
好了，这一章的内容就到这里。下一章我们会深入讲SOTIF的具体分析方法，包括HARA、STPA这些工具怎么用。到时候我会分享一些实际项目中的踩坑经历，保证让你少走弯路。