第2章：ISO 21448标准解读——标准范围与目标、核心术语定义、标准框架与章节结构
好，咱们直接进入正题。ISO 21448这个标准，圈内人习惯叫它SOTIF。说实话，我第一次接触这个标准是在2019年，当时项目上出了个诡异的问题——车在暴雨天把路边的垃圾桶识别成了行人，一脚急刹差点让后车追尾。嗯，这就是典型的SOTIF问题：功能本身没坏，但场景超出了设计预期。
今天我就带你把标准的核心骨架拆开来看。别怕，标准原文确实有点枯燥，但我会用我踩过的坑帮你把重点拎出来。
2.1 标准范围与目标
ISO 21448的目标很明确：解决“功能正常但系统不安全”的问题。你想想看，传统功能安全（ISO 26262）管的是“硬件坏了怎么办”、“软件跑飞了怎么办”。但SOTIF管的是另一码事——传感器没坏、算法没崩，可就是识别错了，怎么办？
标准范围覆盖了L1到L5所有级别的自动驾驶系统，但重点在L3及以上。我个人习惯把它的应用场景分成三类：
- 感知局限：摄像头被强光晃瞎、雷达被雨雪衰减、激光雷达打不到黑色高光物体
- 算法局限：模型没见过这种异形车、分类器把广告牌上的车当真车
- 系统局限：多传感器融合时时间戳对不上、决策模块在边缘场景下死循环
核心目标一句话：把“不知道什么时候会出问题”变成“知道在什么条件下会出问题，并且有应对方案”。
我在项目中遇到过最典型的案例：某款L2级车在隧道出口处，阳光从背后直射摄像头，导致车道线检测丢失，车辆直接往墙上偏。你说传感器坏了吗？没有。算法崩溃了吗？也没有。就是光照条件超出了设计范围——这就是SOTIF要管的事。
2.2 核心术语定义
标准里定义了一堆术语，但真正干活时你只需要记住这几个。我按重要程度排个序：
| 术语 | 定义 | 我的理解 |
|---|---|---|
| 功能不足 | 系统在特定场景下无法完成预期功能 | 说白了就是“能力不够”。比如摄像头在夜间看不清行人 |
| 触发条件 | 导致功能不足被激活的具体场景因素 | 比如“夜间+无路灯+行人穿深色衣服”就是一组触发条件 |
| 危害行为 | 功能不足被触发后，系统做出的危险动作 | 比如“未减速、未报警、直接撞上去” |
| 已知危险场景 | 已经被识别出来的、可能触发危害行为的场景 | 这些是我们测试和验证的重点 |
| 未知危险场景 | 还没被发现、但实际存在的危险场景 | 这是SOTIF最难啃的骨头，也是标准的核心关注点 |
避坑指南：我曾经在项目评审会上，有人把“功能不足”和“功能失效”混为一谈。记住：功能失效是“坏了”，功能不足是“本来就这样，只是不够好”。这两个概念对应的解决路径完全不同。
还有一个术语必须提——合理可预见的误用。标准要求你不仅要考虑正常使用，还要考虑“用户可能会怎么瞎搞”。比如司机把一杯咖啡洒在中控台上，或者用脚去够掉落的手机。嗯，这些都要纳入分析范围。
2.3 标准框架与章节结构
ISO 21448的章节结构，说白了就是一条从“发现问题”到“解决问题”的流水线。我画了张图帮你理清逻辑：
这张图我建议你保存下来。每次做SOTIF分析时，对照着看自己走到哪一步了。我当年第一次做完整流程时，就是在第7章“危害识别”阶段漏掉了一个关键场景——车辆在雪地中车道线被覆盖的情况。结果冬天路测时果然出了问题。
2.4 各章节核心内容速览
标准正文有14章加7个附录，但真正干活时你重点关注这几个：
- 第5-6章（功能定义）：这里要明确你的系统“应该做什么”和“不应该做什么”。我建议把ODD（运行设计域）写得越细越好，别怕啰嗦。比如“白天”要细化到“光照强度≥100 lux”这种程度。
- 第7章（危害识别）：这是最花时间的章节。要用HAZOP、STPA等方法系统性地找场景。我曾经带团队用脑暴法，三天列出了2000多个场景，最后筛出87个关键场景。
- 第10章（功能改进）：发现功能不足后怎么改？标准给了三条路：改进算法、增加传感器、或者干脆限制ODD。我个人最推荐第三条——别贪心，承认系统有边界，比硬撑出事强。
- 第11-12章（验证确认）：这里要回答“你怎么证明系统在已知场景下安全，在未知场景下风险可接受”。实车测试、仿真测试、形式化方法，三管齐下。
注意：第14章“发布后的持续监控”经常被忽略。标准要求你上市后还要持续收集数据，发现新场景就要迭代。我见过有公司产品上市后就不管了，结果第二年出了个新场景导致事故，被罚得倾家荡产。
2.5 与ISO 26262的关系
这个问题几乎每次培训都有人问。我直接说结论：两者是互补关系，不是替代关系。
ISO 26262管的是“系统坏了怎么办”，ISO 21448管的是“系统没坏但不够聪明怎么办”。一个完整的自动驾驶安全体系，两个标准都要过。我在实际项目中通常这样分工：
- 硬件故障、软件随机失效 → 归ISO 26262管
- 传感器感知局限、算法决策错误、场景覆盖不足 → 归ISO 21448管
- 两者交界处（比如传感器部分失效导致感知降级）→ 两个标准都要分析
标准附录G专门讲了两者的交互，建议你仔细看看。我记得有一次做ASIL分解时，发现一个功能既涉及26262的硬件随机失效，又涉及21448的感知局限，最后两个团队坐在一起开了三天会才理清楚边界。
2.6 我的实战建议
最后给你几条实在的建议：
- 别试图一次性覆盖所有场景。标准也允许你分阶段发布，先覆盖80%的常见场景，剩下的通过OTA持续改进。
- 文档要写得让测试工程师看得懂。我见过太多SOTIF分析报告写得像天书，最后测试团队根本不知道怎么转化成测试用例。
- 仿真测试不是万能的。标准明确要求仿真+实车结合。我踩过的坑：仿真里完美的感知模型，到了真实道路上被雨滴反射搞得一塌糊涂。
- 尽早引入SOTIF分析。别等到系统快开发完了才做，那时候改设计的成本高得吓人。
一个小技巧：做危害识别时，拉上测试、算法、系统、硬件四个团队的人一起脑暴。不同视角能发现你一个人根本想不到的场景。我上次就是这么发现了一个“无人机投影在挡风玻璃上被误识别为障碍物”的奇葩场景。
好了，ISO 21448的标准框架就讲到这里。记住核心逻辑：定义功能 → 找场景 → 评风险 → 做改进 → 验证确认 → 持续监控。这个循环跑通了，SOTIF就算入门了。
公众号:蓝海资料掘金营，微信deep3321