3、预期功能安全基础：ISO 21448标准概述、SOTIF触发条件、功能不足与性能局限
预期功能安全（SOTIF，Safety Of The Intended Functionality）解决的是“没有故障，但系统依然可能不安全”的问题。ISO 21448 标准为智能驾驶系统在预期功能范围内因功能不足或性能局限导致的风险提供了系统化的分析框架。与 ISO 26262 关注“电子电气系统随机硬件失效和系统性故障”不同，ISO 21448 关注的是“功能本身的设计缺陷”和“场景覆盖不足”。本章将围绕 ISO 21448 的核心概念、SOTIF 触发条件、功能不足与性能局限的识别方法展开，帮助学员建立从标准条款到工程落地的完整认知。
上图展示了 ISO 21448 的核心逻辑框架：功能不足与性能局限是 SOTIF 风险的根源，触发条件将这些根源转化为实际危害场景，最终通过风险分析流程进行量化评估与安全措施设计。下面我们将逐一展开每个模块的工程实践方法。
3.1 ISO 21448 标准概述与核心原理
3.1.1 标准定位与适用范围
ISO 21448 于 2022 年正式发布，其全称为《Road vehicles — Safety of the intended functionality》。该标准针对的是没有电子电气故障的情况下，由于预期功能的功能不足或性能局限导致的不合理风险。它适用于 L1-L5 级驾驶辅助和自动驾驶系统，包括感知、决策、执行全链路。与 ISO 26262 的互补关系在于：ISO 26262 处理“系统是否按设计工作”的问题，而 ISO 21448 处理“设计本身是否足够安全”的问题。
| 对比维度 | ISO 26262 | ISO 21448 |
|---|---|---|
| 风险来源 | 硬件随机失效、系统性故障 | 功能不足、性能局限 |
| 分析对象 | 电子电气系统 | 预期功能（含软件算法） |
| 核心方法 | ASIL 等级划分、安全机制 | SOTIF 场景分析、触发条件识别 |
| 验证重点 | 故障注入、安全机制测试 | 场景覆盖度、边界条件测试 |
| 生命周期 | 概念→开发→生产→运行 | 概念→开发→验证→运行→退役 |
3.1.2 安全目标与风险可接受原则
ISO 21448 的核心安全目标是确保系统在预期功能范围内不存在不合理风险。所谓“不合理风险”需要结合两个维度判断：一是危害事件的严重度（S），二是该危害发生的暴露概率（E）和可控性（C）。标准要求企业建立自己的风险可接受准则，通常采用 ALARP（As Low As Reasonably Practicable）原则，即在合理可行的范围内将风险降至最低。实际操作中，企业需要定义 SOTIF 风险矩阵，明确哪些风险必须消除、哪些可以接受、哪些需要持续监控。
3.2 SOTIF 触发条件：识别与分类方法
3.2.1 触发条件的定义与分类
SOTIF 触发条件是指导致功能不足或性能局限被激活，从而引发危害事件的特定场景要素组合。触发条件可以分为四大类：
- 场景复杂性触发：包括交通参与者异常行为（如行人突然横穿）、复杂道路结构（如无标线路口）、恶劣天气（暴雨、大雾、逆光）。
- 环境干扰触发：包括电磁干扰、传感器脏污、光学噪声（如太阳直射摄像头）、声学噪声（如紧急车辆警笛）。
- 合理可预见误用触发：驾驶员过度依赖系统、错误操作（如误踩油门）、未按说明使用（如超载）。
- 系统交互触发：V2X 通信延迟或丢包、高精地图数据过期、云端服务中断。
3.2.2 触发条件的识别流程
触发条件的识别需要系统化的方法，推荐采用以下五步流程：
- 场景收集：从自然驾驶数据库、事故数据库、法规场景库中收集目标运行区域的场景数据。
- 场景分类：按道路类型、交通参与者、环境条件、动态任务四个维度对场景进行结构化分类。
- 功能边界分析：明确系统的 ODD（运行设计域），分析功能在 ODD 边界内外的表现差异。
- 触发条件假设：基于功能不足和性能局限的初步分析，提出可能的触发条件假设。
- 验证与确认：通过仿真、封闭场地测试、道路测试验证触发条件假设的有效性。
3.2.3 案例拆解：雨天 AEB 行人误触发
背景与约束：某 OEM 的 AEB 系统在雨天城市道路测试中，出现多次行人误触发（无行人时紧急制动）。系统配置为前视摄像头 + 前向毫米波雷达，ODD 覆盖城市道路，设计最高车速 60km/h。
初始现象：测试车辆在雨天以 40km/h 行驶，前方无行人，但 AEB 突然触发紧急制动，导致车辆急停，后方车辆险些追尾。
关键输入数据：
- 摄像头图像：雨滴附着在镜头表面，形成局部模糊区域。
- 雷达点云：雨滴反射产生杂波点，密度约为正常天气的 3 倍。
- 车辆 CAN 数据：AEB 触发时，目标列表中存在一个“虚拟行人”目标，置信度 0.85。
分析判断过程：通过回放数据发现，摄像头在雨滴模糊区域将路边的交通锥桶误识别为行人，雷达在相同区域检测到密集杂波，融合算法将两者关联后输出了高置信度的行人目标。进一步分析发现，融合算法中“摄像头目标与雷达目标距离小于 1.5m 即关联”的阈值在雨天杂波环境下过于宽松。
实际操作步骤：
- 在仿真环境中复现雨天场景，调整雨量参数（小雨、中雨、大雨）和车速参数。
- 对融合算法增加“目标置信度动态阈值”逻辑：当雷达杂波密度超过设定值时，提高关联阈值至 2.5m。
- 增加摄像头图像质量评估模块，当检测到镜头污损时，降低视觉目标的置信度权重。
- 在封闭场地进行 50 组雨天场景验证，确认误触发率从 12% 降至 0.5%。
结果对比：优化后，雨天 AEB 误触发率显著下降，同时真实行人场景的检出率保持 98% 以上。代价是算法复杂度增加，需要额外的图像质量评估算力约 5% CPU 占用。
复盘经验：触发条件识别不能仅依赖单一传感器数据，必须结合多传感器交叉验证。同时，融合算法的关联阈值需要根据环境状态动态调整，而非固定值。
3.3 功能不足与性能局限的工程识别
3.3.1 功能不足的识别方法
功能不足是指系统在规格定义或算法实现层面存在缺陷，导致无法完成预期功能。识别方法包括：
- 规格审查：对照系统需求规格书，逐条审查功能定义是否完整、无歧义、可验证。
- 算法边界分析：对感知、决策、控制算法进行边界条件分析，找出输入参数超出设计范围的情况。
- 场景遍历测试：使用场景库对系统进行大规模遍历测试，发现未覆盖的场景类型。
- 误用分析：分析驾驶员可能的不当操作，评估系统是否具备足够的容错能力。
3.3.2 性能局限的量化评估
性能局限是指系统在特定条件下无法达到设计性能指标。量化评估需要建立性能指标体系：
| 性能维度 | 典型指标 | 局限示例 |
|---|---|---|
| 感知性能 | 检测距离、识别准确率、响应时间 | 夜间检测距离从 150m 降至 80m |
| 计算性能 | 帧率、延迟、资源占用率 | 复杂场景下帧率从 30fps 降至 15fps |
| 执行性能 | 制动响应时间、转向精度 | 低温下制动响应延迟增加 200ms |
| 通信性能 | 带宽、延迟、丢包率 | 隧道内 V2X 信号丢失 |
3.3.3 功能不足与性能局限的关联分析
在实际工程中，功能不足和性能局限往往相互交织。例如，感知算法在雨天性能下降（性能局限），但算法本身对雨滴噪声的鲁棒性不足（功能不足）。因此，ISO 21448 要求采用系统化方法同时分析两者，而不是割裂处理。推荐使用“功能-场景-性能”三维矩阵进行关联分析，将每个功能在不同场景下的性能表现进行量化评分，识别出风险最高的组合。
3.4 常见误区与总结复盘
3.4.1 常见误区
- 误区一：认为 SOTIF 只适用于 L3 以上自动驾驶。实际上，L2 级辅助驾驶同样存在 SOTIF 风险，例如 ACC 在弯道中误识别目标。
- 误区二：将 SOTIF 分析等同于“多测试几个场景”。SOTIF 需要系统化的场景分类、触发条件假设和验证闭环，而非随机测试。
- 误区三：忽视“合理可预见误用”。ISO 21448 明确要求考虑驾驶员误用场景，例如驾驶员在系统激活时打瞌睡。
- 误区四：认为 SOTIF 分析一次完成即可。随着系统升级、场景扩展，SOTIF 分析需要持续迭代。
3.4.2 总结复盘
本章的核心知识点可以归纳为：
- ISO 21448 解决的是“功能设计本身不安全”的问题，与 ISO 26262 形成互补。
- SOTIF 触发条件是功能不足/性能局限被激活的“导火索”，需要系统化识别。
- 功能不足是“设计缺陷”，性能局限是“能力边界”，两者需要关联分析。
- 工程落地需要建立场景库、触发条件库、风险矩阵三大基础设施。
- 验证与确认是 SOTIF 闭环的关键环节，需要结合仿真、场地测试和道路测试。