3、SOTIF标准概览：ISO 21448的发布背景、标准结构、适用范围、与其他功能安全标准的接口
ISO 21448《道路车辆—预期功能安全（SOTIF）》于2022年正式发布，是继ISO 26262《道路车辆—功能安全》之后，汽车安全领域又一具有里程碑意义的国际标准。如果说ISO 26262解决的是“系统没有故障时是否安全”的问题，那么ISO 21448则聚焦于“系统在无故障情况下，因功能不足、性能局限或可合理预见的人为误用而导致的不安全风险”。本章将系统梳理ISO 21448的发布背景、标准结构、适用范围及其与ISO 26262、ISO/SAE 21434等标准的接口关系，帮助学员建立SOTIF标准的整体认知框架。
3.1 发布背景：从功能安全到预期功能安全的演进逻辑
3.1.1 核心原理：为什么需要SOTIF标准
传统功能安全标准ISO 26262基于“系统存在故障（Fault）”这一前提，通过避免系统性失效和控制随机硬件失效来保障安全。然而，随着高级驾驶辅助系统（ADAS）和自动驾驶系统（ADS）的快速发展，行业逐渐认识到：即使系统没有任何故障，仍然可能因为功能设计不足、性能局限或使用场景超出设计边界而导致安全事故。例如，一个完全正常的摄像头在强逆光条件下无法识别行人，系统本身没有故障，但结果仍然是不安全的。这种“无故障但不安全”的状态，正是SOTIF所要解决的核心问题。
从时间线来看，ISO 21448的制定经历了以下关键节点：
| 时间 | 里程碑事件 | 意义 |
|---|---|---|
| 2018年1月 | ISO/DIS 21448草案发布 | 首次以国际标准草案形式公开SOTIF方法论 |
| 2019年1月 | ISO/PAS 21448（公开可用规范）发布 | 为行业提供早期应用指南，积累实践经验 |
| 2022年6月 | ISO 21448:2022正式发布 | 成为国际公认的SOTIF标准，替代PAS版本 |
推动标准发布的深层驱动力来自三个方面：技术层面，传感器融合、机器学习等新技术的引入使得系统行为不再完全可预测；事故层面，多起涉及ADAS的交通事故被归因于“系统未识别障碍物”而非硬件故障；监管层面，UN R157（自动车道保持系统法规）等法规明确要求制造商证明预期功能安全性。
3.1.2 判断方法：如何区分功能安全与SOTIF
在实际工程中，工程师经常混淆两类安全活动。判断的关键在于危害根因分析：
- 故障引发：如果危害源于硬件随机失效、软件系统性缺陷（如代码错误、逻辑漏洞），则属于ISO 26262范畴。
- 功能不足引发：如果危害源于传感器性能局限（如探测距离不足）、算法能力边界（如场景识别错误）、合理可预见的人为误用（如驾驶员过度依赖系统），则属于ISO 21448范畴。
- 混合场景：实际事故往往是两类因素叠加。例如，摄像头因脏污（故障）导致识别失败，同时算法对雨雾场景鲁棒性不足（功能不足）。此时需要两个标准协同应用。
3.1.3 案例拆解：从事故到标准需求
2016年至2018年间，多起涉及特斯拉Autopilot和Uber自动驾驶测试车的事故，成为推动SOTIF标准加速制定的重要催化剂。以2018年Uber亚利桑那州事故为例：
- 背景与约束：测试车辆搭载激光雷达、摄像头、毫米波雷达等多传感器融合系统，在夜间城市道路进行自动驾驶测试。
- 初始现象：车辆在时速约65km/h下未能识别横穿马路的行人，碰撞前1.3秒系统已检测到目标但将其分类为“其他物体”而非“行人”。
- 关键输入数据：日志显示，激光雷达点云数据完整，但感知算法对“行人推自行车”这一非常规姿态的置信度评分低于阈值，导致未触发紧急制动。
- 分析判断过程：事故调查发现，系统硬件无故障、软件无代码错误，问题出在感知模型的训练数据覆盖不足——训练集中缺乏夜间横穿马路且携带异物的行人样本。
- 结果与复盘：该事故被定性为典型的SOTIF问题，直接推动了行业对“场景覆盖度”和“算法边界”的重视，也成为ISO 21448中“已知不安全场景”和“未知不安全场景”分类方法的现实依据。
3.1.4 常见误区与总结复盘
总结：SOTIF标准的诞生是汽车安全理念从“防故障”向“防不足”演进的必然结果。理解这一背景，是正确应用标准的前提。
3.2 标准结构与核心条款解读
3.2.1 核心原理：ISO 21448的章节架构
ISO 21448:2022共包含11章正文和若干附录，整体遵循“V模型”思路，与ISO 26262的框架保持一致性。其结构可归纳为四个层次：
| 层次 | 章节 | 核心内容 | 关键输出物 |
|---|---|---|---|
| 基础层 | 第1-3章 | 范围、规范性引用文件、术语定义 | 统一的术语体系 |
| 框架层 | 第4-5章 | SOTIF总体框架、规范定义（功能规范、系统规范） | 功能/系统规范、SOTIF相关项定义 |
| 核心活动层 | 第6-8章 | 危害识别与风险评估、安全措施设计、验证与确认 | 危害清单、安全措施、验证报告 |
| 运行与发布层 | 第9-11章 | 运行阶段活动、发布准则、附录 | 运行监控计划、SOTIF释放声明 |
其中，第6章（危害识别与风险评估）和第7章（安全措施设计）是标准的核心，它们共同构成了SOTIF的“双环迭代”方法论：第一环针对“已知不安全场景”进行优化，第二环针对“未知不安全场景”进行探索与验证。
3.2.2 操作流程：SOTIF活动的V模型映射
标准推荐将SOTIF活动嵌入到系统开发的全生命周期中，具体操作流程如下：
- 功能与系统规范定义：明确系统的功能边界、性能指标和使用场景，识别潜在的SOTIF相关危害。
- 危害识别与风险评估：基于场景分析，识别危害事件，评估严重度（S）、暴露率（E）和可控性（C），确定风险等级。
- 已知不安全场景优化：针对已识别的场景，通过改进功能设计、增加冗余或限制使用条件来降低风险。
- 未知不安全场景探索：通过仿真、场地测试和实际道路测试，发现未知的不安全场景。
- 验证与确认：验证安全措施的有效性，确认残余风险在可接受范围内。
- 发布与运行监控：制定发布准则，建立运行阶段的数据监控和反馈机制。
3.2.3 案例拆解：SOTIF活动在AEB系统中的应用
以自动紧急制动（AEB）系统为例，展示SOTIF活动的具体落地：
- 功能规范：AEB应在车速10-80km/h范围内，对前方静止或移动的车辆和行人触发制动。
- 危害识别：识别出“在雨天夜间，系统未能识别横穿马路的行人”这一危害场景，评估S=3（严重伤害）、E=2（低暴露）、C=2（可控性差），风险等级为中等。
- 已知场景优化：针对上述场景，改进感知算法，增加雨雾天气的传感器融合策略，并调整制动触发阈值。
- 未知场景探索：通过仿真平台生成10000个随机场景，发现“行人穿着全黑服装且携带黑色雨伞”时系统识别率下降至60%，属于新的未知不安全场景。
- 验证确认：在封闭场地复现该场景，验证优化后的算法识别率提升至95%，残余风险可接受。
- 发布监控：车辆上市后，通过OTA收集真实事故数据，持续更新场景库。
3.2.4 常见误区与总结复盘
总结：ISO 21448的结构设计体现了“系统安全”的完整闭环，从规范定义到运行监控，每一环节都不可或缺。
3.3 适用范围与边界条件
3.3.1 核心原理：哪些系统适用SOTIF
ISO 21448的适用范围明确为“包含感知、决策、执行功能的电气/电子（E/E）系统”，尤其适用于涉及环境感知和自动驾驶功能的系统。具体包括：
- 驾驶自动化系统：L1-L5级ADAS/ADS，如ACC、LKA、NOA、Robotaxi等。
- 感知系统：摄像头、毫米波雷达、激光雷达、超声波传感器及其融合算法。
- 决策规划系统：路径规划、行为决策、运动控制算法。
- 人机交互系统：驾驶员监控系统（DMS）、HMI交互逻辑。
同时，标准也明确了不适用范围：纯粹的机械系统（如制动盘磨损）、非E/E系统（如传统液压转向）、以及已由ISO 26262覆盖的故障相关安全问题。
3.3.2 判断方法：SOTIF适用性评估
在项目立项时，可通过以下问题快速判断是否需要应用SOTIF：
| 判断维度 | 关键问题 | 若答案为“是” |
|---|---|---|
| 环境感知 | 系统是否依赖传感器感知外部环境？ | 需要SOTIF |
| 算法决策 | 系统是否包含基于机器学习或复杂算法的决策逻辑？ | 需要SOTIF |
| 人为交互 | 系统是否允许驾驶员干预或存在可预见的人为误用？ | 需要SOTIF |
| 运行边界 | 系统是否在开放道路或复杂场景下运行？ | 需要SOTIF |
3.3.3 案例拆解：SOTIF在L2+与L4系统中的差异化应用
以某车企的L2+级领航辅助系统和L4级Robotaxi项目为例：
- L2+系统：适用范围限定于高速公路场景，ODD（运行设计域）明确。SOTIF活动聚焦于传感器性能边界（如雨雾天气）、驾驶员误用（如双手长时间脱离方向盘）和系统降级策略。
- L4系统：运行域扩展至城市道路，SOTIF活动需覆盖更复杂的交通参与者交互、极端天气、施工区域等长尾场景。此时，未知不安全场景的探索成为核心工作，需要大规模仿真和路测数据支撑。
- 对比结论：L2+系统SOTIF活动以“已知场景优化”为主，L4系统则以“未知场景探索”为主，两者在资源投入和方法论侧重点上有显著差异。
3.3.4 常见误区与总结复盘
总结：明确SOTIF的适用范围和边界条件，是高效开展安全活动的前提。企业应根据自身产品定位，合理裁剪SOTIF活动的深度和广度。
3.4 与其他功能安全标准的接口关系
3.4.1 核心原理：三大安全标准的协同框架
现代汽车安全体系由三大国际标准共同支撑：ISO 26262（功能安全）、ISO 21448（预期功能安全）和ISO/SAE 21434（网络安全）。三者既有明确分工，又存在紧密接口：
| 标准 | 关注对象 | 核心问题 | 主要方法 |
|---|---|---|---|
| ISO 26262 | 系统故障（Fault） | 硬件失效、软件缺陷是否导致危害？ | ASIL等级、安全机制、故障注入测试 |
| ISO 21448 | 功能不足（Gap） | 无故障时，功能是否足够安全？ | 场景分析、SOTIF等级、验证确认 |
| ISO/SAE 21434 | 网络攻击（Attack） | 恶意攻击是否导致危害？ | TARA分析、安全架构、渗透测试 |
三者之间的关系可以概括为：ISO 26262保证“系统不坏”，ISO 21448保证“系统够好”，ISO/SAE 21434保证“系统不被攻击”。在实际开发中，三类安全活动需要共享危害分析结果、共用测试资源、协同制定安全措施。
3.4.2 操作流程：SOTIF与ISO 26262的接口衔接
在项目实践中，SOTIF与ISO 26262的接口主要体现在以下环节：
- 危害分析阶段：ISO 26262的HARA（危害分析与风险评估）与SOTIF的危害识别应共享场景库，避免重复分析。建议建立统一的“危害登记册”，标注每个危害的归属标准。
- 安全需求分配：ISO 26262的安全需求（Functional Safety Requirements）与SOTIF的安全措施（SOTIF Measures）应统一管理，确保不冲突、不遗漏。
- 验证与确认：ISO 26262的故障注入测试与SOTIF的场景测试可共用测试台架和测试车辆，但测试用例设计需分别覆盖“故障条件”和“非故障条件”。
- 安全档案管理：建议建立统一的安全案例（Safety Case），将功能安全、SOTIF和网络安全证据整合，便于整体评估和监管沟通。
3.4.3 案例拆解：多标准协同在ADAS项目中的实践
以某L2+级自动紧急转向（AES）系统开发为例，展示三大标准的协同应用：
- 项目背景：系统在检测到前方静止障碍物且驾驶员未响应时，自动执行转向避让。开发团队需同时满足ISO 26262、ISO 21448和ISO/SAE 21434要求。
- ISO 26262活动：对转向执行器进行ASIL D等级设计，增加冗余电机和位置传感器，通过故障注入测试验证单点故障覆盖率。
- ISO 21448活动：识别出“系统在湿滑路面转向时可能引发侧滑”这一SOTIF风险，通过限制转向力矩和增加ESC（电子稳定控制）协同来降低风险。
- ISO/SAE 21434活动：对转向控制信号进行加密和完整性校验，防止恶意注入虚假转向指令。
- 协同效果：三类安全活动共享了同一套仿真场景库，但分别从故障、功能不足和攻击三个维度生成测试用例。最终，系统在满足所有安全要求的同时，开发周期缩短了约15%。
3.4.4 常见误区与总结复盘
总结：ISO 21448不是孤立的标准，而是汽车安全体系中的重要一环。企业应建立“统一安全视角”，将功能安全、SOTIF和网络安全有机整合，才能构建完整的安全防线。