3. ISO 21448标准解读：核心思想、适用范围与关键术语
好，我们进入第三章。ISO 21448，也就是大家常说的SOTIF标准。说实话，我刚接触这个标准时，第一反应是：“这不就是功能安全的补充吗？”后来踩了坑才发现——事情没那么简单。
这一章，我会带你拆解ISO 21448的核心思想、它管什么不管什么、怎么和26262配合，以及那些绕不开的关键术语。嗯，咱们一个一个来。
3.1 核心思想：安全不是“不出错”，而是“没危险”
ISO 21448的核心思想，说白了就一句话：系统在没故障的情况下，也不能因为功能不足或场景触发导致危险。
你想想看，传统功能安全（ISO 26262）主要对付的是“系统坏了怎么办”——比如传感器短路、芯片死机。但SOTIF要对付的是“系统没坏，但就是干蠢事”。
核心区别一句话总结：
- ISO 26262：系统坏了，要安全。
- ISO 21448：系统没坏，也要安全。
我在项目中遇到过这样一个案例：一辆L2级辅助驾驶车，摄像头、雷达都正常，算法也没报错。但在一个逆光+路面湿滑的弯道，系统没识别出前方静止的工程车——直接撞上去了。硬件没坏，软件没崩，但就是没识别出来。这就是典型的SOTIF问题。
所以，ISO 21448的核心思想可以拆成三个层次：
- 功能不足：系统能力有限，比如摄像头在强光下看不清。
- 场景触发：某些场景恰好暴露了系统的短板。
- 危害事件：功能不足+场景触发=危险。
说白了，SOTIF就是逼着你去想：“我的系统在哪些场景下会犯傻？”
3.2 标准适用范围：管什么，不管什么
ISO 21448的适用范围，我习惯用一张表来记：
| 维度 | 适用（管） | 不适用（不管） |
|---|---|---|
| 系统状态 | 系统无故障（硬件/软件正常） | 系统有故障（归ISO 26262管） |
| 功能范围 | L1-L5级驾驶自动化功能 | 非驾驶功能（如信息娱乐） |
| 触发因素 | 场景、环境、算法局限 | 随机硬件失效、系统性软件bug |
| 安全目标 | 避免因功能不足导致的危害 | 避免因故障导致的危害 |
| 生命周期 | 开发、验证、量产后的持续监控 | 生产制造过程（归质量管理） |
这里有个容易混淆的点：ISO 21448并不完全独立于ISO 26262。实际上，两个标准是协同工作的。我个人的习惯是：先做26262的HARA（危害分析与风险评估），再做21448的场景分析。因为26262帮你找出“系统坏了会怎样”，21448帮你找出“系统没坏但场景不对会怎样”。
避坑指南： 我曾经在一个项目里，把SOTIF和功能安全完全分开做，结果发现很多危害事件既涉及故障又涉及场景。比如，摄像头被泥巴挡住——这既是“传感器故障”（26262），也是“场景触发”（21448）。后来我学乖了：两个标准要一起看，交叉分析。
3.3 与ISO 26262的协同：不是替代，是互补
很多人问我：“有了26262，为什么还要21448？”我的回答是：26262管的是“系统坏了”，21448管的是“系统没坏但不够聪明”。
来看一个对比表，你就明白了：
| 对比项 | ISO 26262 | ISO 21448 |
|---|---|---|
| 核心问题 | 系统故障怎么办？ | 系统能力不足怎么办？ |
| 分析对象 | 硬件随机失效、系统性故障 | 场景、环境、算法局限 |
| 安全目标 | 避免因故障导致的危害 | 避免因功能不足导致的危害 |
| 分析方法 | HARA、FMEA、FTA | 场景分析、触发条件分析 |
| 输出 | 安全需求、ASIL等级 | 功能不足清单、场景库 |
| 生命周期 | 开发到量产 | 开发到量产+持续监控 |
在实际项目中，我建议这样协同：
- 先做26262的HARA：找出所有故障相关的危害事件。
- 再做21448的场景分析：找出所有功能不足相关的危害事件。
- 交叉验证：有些危害事件可能同时涉及故障和场景，需要联合分析。
- 统一安全目标：把两个标准的输出合并，形成完整的安全需求。
我的经验： 别把两个标准当成两套独立的流程。我见过最成功的项目，是把26262和21448的团队合并，每周开一次联合评审会。这样既能避免重复工作，又能发现那些“灰色地带”的问题。
3.4 关键术语解析：这些词你必须懂
ISO 21448里有一堆术语，我挑几个最关键的给你讲透：
3.4.1 功能不足（Functional Insufficiency）
说白了，就是系统能力不够。比如：
- 摄像头在夜间看不清行人
- 雷达在隧道里信号衰减
- 算法在复杂路口决策犹豫
功能不足不是故障，而是系统设计时的固有局限。我习惯把它分成两类：
- 感知不足：传感器看不全、看不清、看错了。
- 决策不足：算法想不明白、想太慢、想错了。
3.4.2 触发条件（Triggering Condition）
触发条件就是“让功能不足暴露出来的场景因素”。比如：
- 逆光、雨雾、夜间——触发感知不足
- 复杂路口、突然切入的车辆——触发决策不足
我在项目中总结了一个规律：触发条件往往是“极端但合理”的场景。不是那种百年一遇的奇葩场景，而是日常驾驶中偶尔会遇到的情况。
3.4.3 危害事件（Hazardous Event）
功能不足 + 触发条件 = 危害事件。比如：
- 功能不足：摄像头在逆光下看不清行人
- 触发条件：下午4点，太阳正好在正前方
- 危害事件：车辆未减速，撞上行人
注意：危害事件必须同时包含危害（比如撞人）和事件场景（比如逆光+行人过马路）。
3.4.4 场景（Scenario）
场景是SOTIF分析的基本单元。ISO 21448把场景分为三个层次：
| 层次 | 定义 | 举例 |
|---|---|---|
| 功能场景 | 用自然语言描述的场景 | “车辆在高速公路上行驶，前方有静止车辆” |
| 逻辑场景 | 用参数范围描述的场景 | “车速80-120km/h，距离50-200m，静止车辆” |
| 具体场景 | 用具体数值描述的场景 | “车速100km/h，距离100m，静止车辆” |
我个人的习惯是：先写功能场景（让所有人都能看懂），再转成逻辑场景（用于分析），最后生成具体场景（用于测试）。
3.4.5 已知场景与未知场景
- 已知场景：标准里写了的、行业里常见的、你测试过的场景。
- 未知场景：还没被发现、还没被测试、但可能存在的场景。
SOTIF的核心挑战就是：如何发现并处理未知场景。嗯，这也是为什么SOTIF强调“持续监控”——量产之后还要不断收集数据，发现新的未知场景。
3.5 知识体系总览：一张图看懂ISO 21448
下面这张SVG图，把ISO 21448的核心逻辑串起来了。你可以把它当成本章的“思维导图”：
3.6 本章小结
好，我们来捋一下这一章的核心要点：
- ISO 21448的核心思想：系统没故障时，也要避免因功能不足导致的危害。
- 适用范围：L1-L5驾驶自动化，系统无故障状态，关注场景和算法局限。
- 与26262的协同：不是替代，是互补。先做HARA，再做场景分析，最后交叉验证。
- 关键术语：功能不足、触发条件、危害事件、场景（三层结构）、已知/未知场景。