3、预期功能安全（SOTIF）基础：ISO 21448标准介绍、SOTIF与ISO 26262的关系、触发事件与功能不足
3.1 为什么我们需要SOTIF？
做ADAS的工程师，应该都有过这种经历：明明功能逻辑没问题，代码也通过了MISRA检查，但车在路上就是会莫名其妙地来个急刹车。我2018年做AEB标定时就遇到过，前方明明是个静止的广告牌，系统却把它识别成了行人。你说这是功能失效吗？硬件没坏，软件没崩，但就是不该刹车的时候刹了。
这就是典型的预期功能安全问题。说白了，系统本身没坏，但它的能力不足以应对真实世界的复杂性。ISO 21448这个标准，就是专门来解决这类问题的。
核心定义：预期功能安全（SOTIF）关注的是系统在无故障情况下，由于功能不足或触发事件导致的不合理风险。
3.2 ISO 21448标准介绍
ISO 21448的全称是“Road vehicles — Safety of the intended functionality”。它发布于2022年，专门针对L2及以上自动驾驶系统。我个人习惯把它看作是“功能安全的另一半”。
标准的核心逻辑其实很简单：
- 功能不足：系统能力有限，比如摄像头在逆光下看不清
- 触发事件：外部环境或场景触发了这个不足，比如正好在隧道出口遇到强光
- 不合理风险：两者结合，导致危险发生
嗯，这里要注意，ISO 21448不是要替代ISO 26262，而是补充。26262管的是“系统坏了怎么办”，21448管的是“系统没坏但不够聪明怎么办”。
3.3 SOTIF与ISO 26262的关系
很多新人会搞混这两个标准。我建议用一张图来理解：
你看，左边是26262管的硬件失效和系统故障，右边是21448管的功能不足和触发事件。两者加在一起，才算是完整的安全覆盖。
我的经验：在做项目时，我建议先跑一遍26262的HARA，再跑一遍21448的场景分析。两个结果合并，才能得到完整的安全需求列表。我曾经在一个项目中只做了26262，结果路测时发现大量误触发，后来补了21448的分析才解决。
3.4 触发事件与功能不足
这两个概念是SOTIF的核心。我分开来讲。
3.4.1 功能不足
功能不足就是系统的“短板”。你想想看，任何传感器都有局限性：
- 摄像头：逆光、夜间、雨雾天，性能会大幅下降
- 毫米波雷达：对静止目标不敏感，容易漏检
- 激光雷达：受灰尘、雨雪影响大
- 算法：对罕见场景（比如动物横穿）识别率低
我记得有一次做泊车功能，超声波雷达在雨天就经常误报。后来分析发现，雨水滴在传感器上产生了回波干扰。这就是典型的功能不足——传感器设计时没考虑雨天场景。
3.4.2 触发事件
触发事件是“导火索”。它本身不是问题，但遇到功能不足就会出问题。常见的触发事件包括：
| 触发事件类型 | 示例 | 可能导致的后果 |
|---|---|---|
| 环境条件 | 强光、雨雪、大雾 | 传感器性能下降，目标丢失 |
| 道路条件 | 急弯、坡道、施工区域 | 路径规划异常，误判车道线 |
| 交通参与者行为 | 行人突然横穿、车辆加塞 | 响应不及时或误触发 |
| 系统自身状态 | 传感器遮挡、计算负载高 | 性能降级，响应延迟 |
避坑指南：我曾经在一个项目中，只考虑了“正常驾驶场景”下的触发事件，忽略了“极端天气+特殊道路”的组合。结果在山区隧道出口遇到暴雨，系统直接退出了自动驾驶。后来我们花了两个月补全了组合场景的测试用例。所以，触发事件一定要考虑组合情况。
3.5 如何识别功能不足和触发事件？
我个人习惯用“场景分析法”。具体步骤是：
- 列出所有可能的运行场景（ODD内的所有情况）
- 对每个场景，分析系统可能存在的功能不足
- 找出可能触发这些不足的外部事件
- 评估组合后的风险等级
举个例子，做ACC自适应巡航时：
- 场景：高速公路上，前车突然变道
- 功能不足：毫米波雷达对突然切入的车辆响应延迟
- 触发事件：前车变道速度很快，且距离很近
- 风险：可能无法及时减速，导致追尾
嗯，这里要注意，识别出来的每个组合都要记录到安全案例中。我建议用表格来管理：
| ID | 场景描述 | 功能不足 | 触发事件 | 风险等级 | 缓解措施 |
|---|---|---|---|---|---|
| SOTIF-001 | 隧道出口强光 | 摄像头动态范围不足 | 光照突变 | 高 | 增加HDR模式，融合雷达数据 |
| SOTIF-002 | 雨天夜间行驶 | 摄像头噪点增加 | 雨滴+低照度 | 中 | 启用雨刮，提升ISO，融合激光雷达 |
| SOTIF-003 | 施工区域锥桶 | 算法未训练锥桶识别 | 锥桶出现在车道内 | 高 | 增加锥桶训练数据，加入超声波辅助 |
小技巧：我建议在项目早期就建立这个表格，随着测试和路测不断补充。不要等到最后才做，那时候改设计成本太高了。
3.6 本章小结
ISO 21448解决的是“系统没坏但不够聪明”的问题。它和ISO 26262是互补关系，两者缺一不可。核心就是识别功能不足和触发事件，然后想办法消除或缓解风险。
做SOTIF分析，说白了就是“把系统可能犯的蠢事都列出来，然后想办法让它别犯”。这需要工程师对传感器、算法、场景都有深入理解。我建议多跑路测，多收集真实场景数据，这些才是SOTIF分析的基础。