预期功能安全（SOTIF）基础：ISO 21448标准核心概念、与功能安全（ISO 26262）的区别与联系

在智能驾驶系统开发中，功能安全（ISO 26262）解决的是“系统没有故障时是否安全”的问题，而预期功能安全（SOTIF，ISO 21448）则进一步回答“系统在没有故障但遇到预期外场景时是否安全”。随着L2+、L3级辅助驾驶系统大规模量产，大量事故并非源于硬件失效或软件缺陷，而是源于感知算法对罕见场景的误判、传感器性能受限、以及用户对系统能力边界的不当预期。本章将系统梳理ISO 21448的核心概念、与ISO 26262的边界划分，以及如何在开发流程中落地SOTIF分析。

2.1 SOTIF 的核心原理：从“无故障”到“无预期外风险”

ISO 21448（SOTIF）发布于2022年，其核心关注点并非系统是否发生故障，而是系统在无故障运行状态下，由于预期功能不足或可合理预见的人员误用所导致的不安全风险。要理解SOTIF，首先需要建立两个关键认知：其一，智能驾驶系统的感知、决策、执行链路中，算法模型对真实世界的理解永远存在“能力边界”；其二，用户对系统能力的认知偏差，本身就是一种需要被管理的风险源。

SOTIF标准将场景分为四个象限：已知安全场景（系统能正确处理且无风险）、已知不安全场景（系统处理不当但已被识别）、未知不安全场景（系统处理不当且尚未被识别）、未知安全场景（系统能正确处理但尚未被验证）。SOTIF的核心目标，就是通过系统化的场景识别、分析、验证与改进，将“未知不安全场景”转化为“已知不安全场景”，再通过算法优化或系统设计将其消除或降低到可接受水平。

2.2 SOTIF 与 ISO 26262 的边界划分与协同关系

ISO 26262与ISO 21448在适用范围、分析对象、风险来源、评估方法上存在显著差异，但两者在工程实践中必须协同工作。下表从多个维度对两者进行对比：

对比维度	ISO 26262 功能安全	ISO 21448 预期功能安全
风险来源	随机硬件失效、系统性故障（软件bug、硬件损坏）	功能不足、场景误判、合理可预见误用
系统状态	系统存在故障或失效	系统无故障，但能力不足以应对场景
分析对象	电子电气系统、软件、硬件	感知算法、决策逻辑、传感器性能、人机交互
安全等级	ASIL A/B/C/D	无直接等级，基于场景风险量化评估
核心方法	HARA（危害分析与风险评估）、FMEA、FTA	场景分析、ODD定义、SOTIF释放准则
验证手段	故障注入、硬件在环、软件测试	场景库测试、真实道路测试、仿真验证
适用阶段	全生命周期，侧重开发与生产	概念阶段、开发阶段、运营阶段持续迭代

在实际工程中，两者并非独立运行。例如，一个摄像头模组发生硬件故障（ISO 26262范畴），可能导致感知算法输入异常，进而引发功能不足（ISO 21448范畴）。因此，现代智能驾驶安全开发流程通常采用“双轨并行、交叉验证”的模式：功能安全团队负责硬件失效与软件故障的防护，SOTIF团队负责场景覆盖度与算法鲁棒性的验证。

2.3 SOTIF 分析的操作流程：从ODD定义到释放决策

ISO 21448标准推荐了一套系统化的SOTIF开发流程，其核心步骤可归纳为以下六个阶段：

1. 定义ODD（运行设计域）：明确系统设计运行的边界条件，包括道路类型、天气条件、光照强度、交通密度、速度范围等。ODD定义不清晰是SOTIF风险的首要来源。
2. 场景识别与分类：基于ODD构建场景库，将场景分为已知安全、已知不安全、未知安全、未知不安全四类。场景来源包括自然驾驶数据、事故数据库、法规标准场景、边缘案例生成等。
3. 风险分析与评估：对已知不安全场景进行危害分析，评估其严重度（S）、暴露率（E）、可控性（C），确定风险等级。对未知不安全场景，通过仿真和测试逐步识别。
4. 功能改进与优化：针对已识别的风险场景，优化感知算法、调整决策逻辑、增加冗余传感器、改进人机交互提示等。
5. 验证与确认：通过仿真测试、封闭场地测试、真实道路测试等手段，验证改进措施的有效性，并持续探索未知场景。
6. SOTIF释放准则评估：当已知不安全场景的风险降低到可接受水平，且未知不安全场景的残余风险低于阈值时，方可做出释放决策。

2.4 实战案例：AEB系统在雨天场景下的SOTIF分析

某主机厂在开发AEB（自动紧急制动）系统时，已完成ISO 26262功能安全认证，但在用户实际使用中仍收到多起“AEB未触发导致碰撞”的投诉。经过初步排查，系统硬件无故障、软件无bug，问题指向SOTIF范畴。

初始现象与目标：用户反馈在雨天夜间行驶时，AEB对前方静止车辆的识别率显著下降，部分场景下完全未触发制动。项目目标是将雨天场景下的AEB触发率从82%提升至95%以上，同时避免误触发率上升。

关键输入数据：团队采集了2000小时雨天自然驾驶数据，包含1200个AEB相关场景。分析发现：

• 雨滴对毫米波雷达的衰减导致目标回波信号减弱约30%；
• 摄像头在雨夜对车辆尾灯的识别距离从150米降至80米；
• 雨刮器摆动对摄像头视野的周期性遮挡导致目标丢失；
• 路面水膜反光造成视觉算法对车道边界的误判。

分析判断过程：团队按照ISO 21448流程，将雨天场景细分为“小雨白天”“中雨夜间”“暴雨夜间”三个子场景。通过仿真复现和实车测试，确认“暴雨夜间”场景属于已知不安全场景，而“中雨夜间”场景中部分工况属于未知不安全场景（此前未在测试中覆盖）。

实际操作步骤：

1. 重新标定毫米波雷达的雨天衰减补偿系数，将回波增益提升15%；
2. 在摄像头感知算法中增加雨滴噪声滤除模块，利用时序帧间差分法消除雨滴干扰；
3. 将雨刮器状态信号接入感知融合模块，在雨刮摆动期间对视觉目标进行“保持锁定”处理；
4. 增加“雨天模式”触发条件：当雨量传感器信号超过阈值且车速低于80km/h时，AEB的感知融合权重向毫米波雷达倾斜。

结果对比：经过三轮迭代优化后，暴雨夜间场景的AEB触发率从82%提升至96.5%，误触发率从0.8%降至0.3%。同时，团队新增了“暴雨夜间静止车辆”等12个边缘场景进入常态化回归测试库。

风险与代价：毫米波雷达增益提升后，在隧道内金属护栏场景下出现了2次误触发，团队通过增加“护栏几何特征识别”逻辑予以消除。整个优化周期耗时3个月，投入测试工程师8人，新增测试里程5万公里。

复盘经验：该案例表明，SOTIF分析不能仅依赖仿真，必须结合真实道路数据持续迭代。同时，AEB系统的SOTIF优化不能孤立进行，需要与功能安全团队协同——例如雷达增益调整后，需要重新评估硬件在极端温度下的性能余量。

2.5 常见误区与总结复盘

在SOTIF实施过程中，企业常陷入以下误区：

• 误区一：将SOTIF等同于“更多测试”。单纯增加测试里程并不能系统性地识别未知不安全场景，必须建立结构化的场景库和覆盖度指标体系。
• 误区二：SOTIF只在开发阶段进行。实际上，SOTIF是运营阶段持续迭代的过程，OTA升级、用户使用习惯变化、道路基础设施变更都会引入新的SOTIF风险。
• 误区三：SOTIF与功能安全完全独立。两者在传感器、执行器、决策算法层面存在大量交互，建议建立联合安全评审机制。
• 误区四：ODD定义越宽泛越好。ODD定义过宽会导致场景空间爆炸，验证成本不可控；ODD定义过窄则影响产品竞争力。合理的做法是采用“分层ODD”策略，区分“设计ODD”和“运营ODD”。

总结：ISO 21448为智能驾驶系统的安全性提供了从“故障安全”到“场景安全”的范式升级。其核心价值在于：将“未知的不安全”转化为“已知的不安全”，再通过系统化的工程手段将其消除或控制。在实际项目中，SOTIF分析应贯穿从概念设计到运营监控的全生命周期，并与ISO 26262功能安全形成互补协同。下一阶段，我们将深入探讨SOTIF场景库的构建方法，包括场景分类体系、数据采集策略和覆盖度评估指标。