4、SOTIF与功能安全（ISO 26262）的协同：两者在安全生命周期中的分工、接口、互补关系及常见误区
SOTIF（ISO 21448）与功能安全（ISO 26262）是智能驾驶安全领域的两大支柱，但二者并非替代关系，而是面向不同风险来源的互补体系。ISO 26262主要针对系统性故障和随机硬件故障，其前提是“已知且可预期的危害场景”；而ISO 21448则聚焦于预期功能不足、合理可预见的误用以及外部干扰所引发的危害，其核心挑战在于“未知或不完全已知的场景”。在实际工程中，若将两者割裂实施，往往导致安全分析重复、安全目标冲突或验证验证活动冗余。本章将系统阐述两者的分工边界、接口机制、互补逻辑及常见误区，帮助学员建立统一的安全生命周期视图。
4.1 核心原理：两类风险、两条生命周期的本质差异
ISO 26262与ISO 21448的根本差异在于风险来源的假设前提。ISO 26262假设系统设计本身是“正确”的，即功能规范能够覆盖所有预期运行场景，安全风险主要来自：①硬件随机失效（如芯片老化、位翻转）；②系统性设计缺陷（如软件逻辑错误、需求遗漏）。而ISO 21448则承认，即使系统完全按照规范实现，功能本身在特定场景下可能产生不安全行为——例如AEB系统在雨天对金属井盖的误识别、LCC系统在车道线模糊时的错误转向。
从安全生命周期看，ISO 26262遵循经典的V模型，从相关项定义出发，经过HARA确定ASIL等级，逐级分解安全需求，最终通过测试和评估确认安全目标达成。而ISO 21448则采用迭代式场景分析方法，从ODD（运行设计域）定义开始，通过“场景识别→功能不足分析→安全措施设计→验证评估”的循环，持续降低未知不安全场景的风险。两者的关键区别在于：ISO 26262的验证目标是“证明系统在已知故障模式下是安全的”，而ISO 21448的验证目标是“证明系统在未知场景中不会产生不可接受的风险”。
4.2 判断方法与操作流程：安全生命周期中的接口定义
在实际项目中，两个标准的安全活动并非完全独立，而是通过明确的接口相互衔接。下表展示了两个标准在安全生命周期各阶段的分工与接口关系：
| 生命周期阶段 | ISO 26262 活动 | ISO 21448 活动 | 接口与协同点 |
|---|---|---|---|
| 概念阶段 | 相关项定义、HARA、安全目标定义 | ODD定义、场景识别、SOTIF相关危害事件分析 | 共享危害事件列表，统一安全目标表述 |
| 系统设计 | 功能安全概念（FSC）、技术安全概念（TSC） | 功能不足分析、触发条件识别、安全措施定义 | 安全措施需同时满足ASIL要求和SOTIF性能要求 |
| 硬件/软件实现 | 硬件FMEDA、软件架构设计、安全机制实现 | 算法优化、感知融合策略、降级逻辑实现 | 安全机制与功能降级策略需协调设计 |
| 验证与确认 | 故障注入测试、安全机制验证、ASIL覆盖确认 | 场景库测试、仿真验证、实车路测、里程积累 | 测试用例共享，验证结果互相引用 |
| 生产与运行 | 生产安全、运维安全、FUSA监控 | OTA更新、场景数据回传、SOTIF性能监控 | 运行数据同时用于故障监控和场景更新 |
在具体操作层面，两个标准的协同需要建立以下关键接口机制：
- 危害事件统一管理：HARA中的危害事件（如“车辆非预期加速”）与SOTIF中的危害事件（如“AEB误触发导致追尾”）应纳入同一数据库，统一编号、统一评估风险等级。
- 安全目标双向追溯：ISO 26262的安全目标（Safety Goal）与SOTIF的安全相关性能指标（如“误触发率<1次/百万公里”）应建立双向追溯关系，确保任何安全措施的变更都能同时评估对两个标准的影响。
- 验证活动联合规划：在测试策略制定时，应同时考虑故障注入测试（ISO 26262）和场景测试（ISO 21448），避免重复测试或遗漏关键场景。
- 安全案例整合：最终的安全案例（Safety Case）应包含两个标准的论证内容，形成统一的安全论证框架。
4.3 案例拆解：AEB系统安全开发的协同实践
以自动紧急制动（AEB）系统为例，说明两个标准的协同过程。某OEM开发面向L2+级别的AEB系统，目标是在2025年实现Euro NCAP五星评级。
背景与约束：系统采用前视摄像头+毫米波雷达融合方案，ODD定义为“高速公路及城市道路，白天/夜间，无雨雪天气”。项目周期24个月，团队包含功能安全工程师、SOTIF工程师、算法工程师和测试工程师。
初始现象与目标：在概念阶段，功能安全团队通过HARA识别出“AEB在高速行驶时误触发导致后车追尾”这一危害事件，评定为ASIL B。SOTIF团队则通过场景分析发现，在隧道出口强光切换场景下，摄像头可能短暂失效，导致AEB漏触发。两个团队分别定义了各自的安全目标：功能安全要求“误触发概率低于某一阈值”，SOTIF要求“在隧道场景下的漏触发率低于某一阈值”。
关键输入数据与参数：场景库包含1200个典型场景，其中隧道场景占8%；传感器融合算法在隧道场景下的目标检测置信度平均为0.82，低于正常场景的0.95；AEB系统从检测到目标到完全制动的响应时间为0.6秒。
分析判断过程：两个团队在联合评审中发现，功能安全的安全机制（如传感器自检、故障降级）与SOTIF的安全措施（如场景自适应阈值调整）存在冲突。例如，功能安全要求在传感器故障时立即降级为“仅警告不制动”，但SOTIF分析表明，在隧道场景下即使传感器置信度较低，也应保持部分制动能力以降低碰撞风险。
实际操作步骤：
- 建立联合工作小组，统一危害事件列表，将“隧道场景漏触发”和“传感器故障误触发”合并为同一安全目标下的两个子目标。
- 重新设计降级策略：当传感器置信度低于0.7时，系统进入“受限制动模式”（最大减速度3m/s²），同时触发驾驶员接管提醒；当传感器完全失效时，才执行功能安全要求的“仅警告”策略。
- 联合制定验证计划：功能安全团队负责故障注入测试（模拟传感器失效、CAN通信中断），SOTIF团队负责场景测试（包含120个隧道场景变体），双方共享测试车辆和测试场地。
- 在实车测试中，发现隧道场景下的误触发率仍高于目标值，SOTIF团队通过调整融合算法的置信度阈值，将误触发率从0.8次/万公里降至0.3次/万公里，同时功能安全团队确认该调整不影响ASIL B的安全目标。
结果对比与复盘：最终AEB系统通过了Euro NCAP测试，同时满足ISO 26262 ASIL B和ISO 21448的SOTIF要求。项目复盘发现，早期联合评审节省了约3个月的返工时间，但初期两个团队对“安全目标”的理解差异导致了两轮需求变更。经验表明，在概念阶段就建立统一的安全目标数据库是协同成功的关键。
4.4 常见误区与总结复盘
在实际工程中，SOTIF与功能安全的协同存在以下常见误区：
总结复盘：SOTIF与ISO 26262的协同本质上是“故障安全”与“功能安全”的统一。前者确保系统在故障时不会造成危害，后者确保系统在正常工作时不会因功能局限造成危害。两者的协同需要从概念阶段就开始，通过统一的安全目标管理、联合的场景分析、协调的安全措施设计和整合的验证活动，最终形成完整的安全论证。忽视任何一个标准，都可能导致安全漏洞，而错误的协同方式则会造成资源浪费和项目延误。在智能驾驶系统日益复杂的今天，建立两个标准的深度融合机制，是确保系统安全性的必要条件。