在汽车安全领域，SOTIF（Safety of the Intended Functionality，预期功能安全）与功能安全是自动驾驶必须同时满足的两大关键标准。ISO 21448:2022《道路车辆 —— 预期功能安全》标准的发布，标志着汽车安全从传统的 “故障安全” 范式向 “性能安全” 范式的重要扩展。
　　要理解 SOTIF 的必要性，需先认识 ISO 26262 的局限性。ISO 26262 假设系统设计意图正确，安全风险仅源于 E/E 系统的随机硬件故障和系统性故障。然而在自动驾驶场景中，即便传感器、控制器和执行器按设计规格工作，系统仍可能因感知性能不足、决策算法局限、可合理预见误用和人机交互缺陷而产生不安全行为。这些风险并非 “系统坏了”，而是 “系统不够好”，这正是 SOTIF 关注的问题。SOTIF 旨在通过系统化工程方法，识别、评估并降低因性能不足和可合理预见误用导致的安全风险。
　　功能安全（ISO 26262）与 SOTIF（ISO 21448）在多方面存在本质区别。从风险来源看，功能安全聚焦 E/E 系统故障，而 SOTIF 处理性能不足、可合理预见误用和算法局限性等问题。在分析方法上，功能安全采用 FMEA、FTA、FMEDA 等聚焦故障模式，SOTIF 则采用性能限制分析、场景分析等聚焦功能不足导致危险的场景。解决方法方面，功能安全通过安全机制等维持或进入安全状态，SOTIF 则通过传感器融合等降低风险。验证方法上，功能安全通过故障注入测试等确认安全机制有效性，SOTIF 通过多种场景测试验证系统性能。
　　尽管存在区别，功能安全与 SOTIF 高度互补。一个完整的自动驾驶系统安全开发流程必须同时满足 ISO 26262 和 ISO 21448 的要求。例如，自动驾驶系统的感知模块既需满足 ISO 26262 的 E/E 故障安全要求，也需满足 ISO 21448 的性能安全要求。
　　SOTIF 的工程实践遵循 “识别 - 评估 - 改进 - 验证” 的闭环流程。ISO 21448 将场景分为四类：已知安全场景、已知不安全场景（触发条件已知）、未知不安全场景（触发条件未知）和未知安全场景。SOTIF 的目标是将 “已知不安全场景” 转化为 “已知安全场景”，将 “未知不安全场景” 转化为 “已知场景”，终使残余的未知不安全场景风险降至可接受水平。在 SOTIF 开发中，ODD（Operational Design Domain，设计运行域）的定义至关重要，它明确了系统安全运行的条件范围，当实际运行条件超出 ODD 时，系统必须采取安全退出策略。
　　以下为相关图片：

　

　　图片来源：Automotive IQ

　

　　图片来源：Model Engineers (MES)