3、SOTIF概述：SOTIF定义、来源与背景、与功能安全（ISO26262）的区别与联系、标准ISO/PAS 21448简介
SOTIF（Safety Of The Intended Functionality，预期功能安全）是智能驾驶时代功能安全领域最核心的扩展方向之一。随着ADAS（高级驾驶辅助系统）和自动驾驶系统从L2向L3+演进，系统面临的威胁不再仅仅来自电子电气随机硬件失效或系统性设计缺陷，更多时候，危险来自于“功能本身设计得不够完善”——例如感知算法在暴雨中漏检行人、传感器融合在隧道出入口产生歧义、决策逻辑在复杂交互场景中做出不合理规划。这些问题的根源并非硬件损坏或代码实现错误，而是“预期功能”在特定场景下未能达到安全预期。本章将系统阐述SOTIF的定义、来源背景、与ISO 26262的关系，以及ISO/PAS 21448标准的核心框架，帮助学员建立清晰的SOTIF知识地图。
3.1 SOTIF的定义与核心内涵
SOTIF（Safety Of The Intended Functionality），即预期功能安全，是指在无故障（无电子电气硬件随机失效、无系统性软件实现错误）的情况下，由于预期功能或系统的性能局限、设计不足或可合理预见的用户误用，导致的不合理风险被消除或控制在可接受水平。简单来说，SOTIF关注的是“功能本身想做的事情是否足够安全”，而不是“功能是否按设计正确执行”。
从工程实践角度，SOTIF的核心内涵可以拆解为以下四个维度：
| 维度 | 说明 | 典型示例 |
|---|---|---|
| 性能局限 | 传感器、算法、执行器在标称工作范围内的能力边界 | 摄像头在逆光条件下动态范围不足，无法识别前方行人 |
| 设计不足 | 功能逻辑在特定场景下的决策不合理或未覆盖 | ACC在收费站场景误将静止车辆识别为可通行目标 |
| 可预见误用 | 用户以非预期但可合理预见的方式使用系统 | 驾驶员在L2级系统中长时间脱手脱眼，系统未及时干预 |
| 环境干扰 | 外部环境对系统感知或决策的负面影响 | 暴雨、大雪、隧道内光线剧变、电磁干扰等 |
核心原理辨析：SOTIF与ISO 26262最本质的区别在于风险来源。ISO 26262处理的是“系统坏了”或“实现错了”的问题，而SOTIF处理的是“系统没坏，但功能本身在特定场景下不够聪明”的问题。例如，一个AEB（自动紧急制动）系统，如果软件代码完全正确、硬件完全正常，但在雨天湿滑路面上制动距离不足导致碰撞，这就是SOTIF问题；如果AEB系统因为传感器供电故障而完全失效，则是ISO 26262问题。
3.2 SOTIF的来源与产业背景
SOTIF概念的提出并非偶然，而是智能驾驶产业发展的必然产物。2016年前后，全球多家OEM和Tier 1在ADAS开发中遇到了一个共同的困惑：按照ISO 26262完成了功能安全开发，系统也通过了所有安全验证，但在实际道路测试中仍然出现了多起与感知、决策相关的安全事故。这些事故的共同特征是：系统没有发生任何硬件故障或软件错误，但功能在特定场景下做出了错误或不合理的响应。
以2016年特斯拉Autopilot首起致命事故为例，系统在强光背景下将白色拖挂车误判为高空路牌，导致车辆未采取制动。从功能安全角度看，Autopilot的硬件和软件均未发生故障；但从预期功能角度看，感知算法在特定光照和背景对比度条件下存在性能局限，且系统设计未充分覆盖此类边缘场景。这一案例深刻揭示了传统功能安全方法的盲区。
SOTIF的产业驱动力可以归纳为以下几点：
- 感知技术的固有局限：摄像头、毫米波雷达、激光雷达各有物理边界，任何单一传感器都无法在所有环境条件下完美工作。
- 场景的无限性与测试的有限性：真实交通场景的组合空间接近无穷大，基于测试里程的安全验证无法穷尽所有可能场景。
- AI算法的不可解释性：深度学习模型的行为难以完全预测，在训练数据分布之外的输入可能产生不可控输出。
- 人机交互的复杂性：L2/L3级系统中驾驶员与系统的控制权切换过程存在大量灰色地带，用户行为难以精确建模。
经验提醒：在SOTIF开发中，不要试图“证明”系统在所有场景下安全，这是不可能完成的任务。正确的思路是：识别已知不安全场景并消除或降低风险，同时通过系统化的方法尽可能减少未知不安全场景，并将残余风险控制在可接受水平。
3.3 SOTIF与ISO 26262的区别与联系
理解SOTIF与ISO 26262的关系，是建立完整安全体系认知的关键。两者并非替代关系，而是互补关系，共同覆盖智能驾驶系统的全维度安全风险。
3.3.1 核心区别
| 对比维度 | ISO 26262 功能安全 | SOTIF 预期功能安全 |
|---|---|---|
| 风险来源 | 电子电气系统随机硬件失效、系统性设计/实现错误 | 功能性能局限、设计不足、可预见误用、环境干扰 |
| 系统状态 | 系统存在故障（Fault）或错误（Error） | 系统无故障，但功能行为未达预期 |
| 安全目标 | 避免因故障导致的安全 violation | 避免因功能不足导致的不合理风险 |
| 风险度量 | ASIL等级（A/B/C/D） | 可接受风险水平（基于场景分析） |
| 主要方法 | HARA、FMEA、FTA、FMEDA、安全机制设计 | 场景分析、触发条件识别、SOTIF评估、验证与确认 |
| 适用对象 | 所有E/E系统 | 以感知、决策、控制为核心的功能（ADAS/AD） |
3.3.2 内在联系
尽管两者关注的风险来源不同，但在实际工程中，SOTIF与ISO 26262存在紧密的交互关系：
- 安全目标的一致性：两者最终都服务于“将不合理风险降低到可接受水平”这一总目标。
- 危害分析的互补性：ISO 26262的HARA（危害分析与风险评估）关注故障导致的危害，而SOTIF的HARA关注功能不足导致的危害，两者需要联合进行才能覆盖完整风险谱。
- 安全机制的协同：SOTIF识别出的功能不足，往往需要通过ISO 26262的安全机制（如降级策略、冗余设计）来缓解。
- 开发流程的融合：在概念阶段和系统阶段，SOTIF活动与功能安全活动应并行开展、相互输入。
常见误区：很多团队将SOTIF视为ISO 26262的“附加章节”，在完成功能安全开发后再补做SOTIF分析。这种做法会导致大量返工，因为SOTIF分析可能揭示出需要修改系统架构或功能定义的问题，而这些问题在后期修改成本极高。正确的做法是在项目启动之初就将SOTIF与功能安全同步规划、同步实施。
3.4 ISO/PAS 21448标准简介
ISO/PAS 21448（Road vehicles — Safety of the intended functionality）是国际标准化组织（ISO）发布的关于SOTIF的规范文件。该标准最初于2019年1月以PAS（Publicly Available Specification，公开可用规范）形式发布，2022年6月发布了第二版，目前正在向正式国际标准（IS）方向演进。
3.4.1 标准定位与适用范围
ISO/PAS 21448适用于包含感知、决策、控制功能的道路车辆系统，特别是L2级以上的ADAS和自动驾驶系统。标准关注的焦点是：在系统无故障的前提下，如何确保功能的预期行为在各类场景下不会导致不合理风险。标准覆盖的范围包括：
- 功能定义与系统规格的充分性
- 传感器性能局限与环境干扰的影响
- 决策算法的逻辑合理性与场景覆盖度
- 人机交互（HMI）设计的可理解性与防误用能力
- 验证与确认策略的有效性
3.4.2 标准核心框架
ISO/PAS 21448的核心方法论围绕“场景”展开，将系统运行场景分为四个象限：
| 象限 | 场景类型 | 安全状态 | 处理策略 |
|---|---|---|---|
| 区域1 | 已知安全场景 | 安全 | 维持并持续验证 |
| 区域2 | 已知不安全场景 | 危险 | 通过功能改进或安全机制消除/降低风险 |
| 区域3 | 未知不安全场景 | 潜在危险 | 通过场景探索、测试和监控来识别并转化 |
| 区域4 | 未知安全场景 | 潜在安全 | 持续监控，防止退化为不安全场景 |
标准推荐的开发流程包括以下关键步骤：
- 功能定义与规格分析：明确功能的预期行为、运行设计域（ODD）、用户角色与交互方式。
- 危害识别与风险评估：基于场景分析识别功能不足可能导致的危害，评估风险等级。
- 触发条件分析：识别导致功能不足被触发的场景要素（如光照、天气、道路结构、交通参与者行为等）。
- 场景库构建：建立覆盖已知安全/不安全场景的测试场景库，包括真实道路数据、仿真场景和边缘案例。
- 功能改进与安全机制设计：针对已知不安全场景，通过算法优化、传感器融合、降级策略等手段降低风险。
- 验证与确认：通过仿真测试、封闭场地测试、道路测试等手段验证功能在各类场景下的安全性。
- 残余风险评估与接受：对无法完全消除的风险进行评估，确认其是否可接受，并形成安全论证。
3.4.3 标准实施案例拆解
以某OEM的L2+级导航辅助驾驶系统开发为例，该功能支持高速公路上的自动变道、自动超车和自动进出匝道。在SOTIF开发过程中，团队按照ISO/PAS 21448框架进行了以下工作：
背景与约束：系统采用“摄像头+毫米波雷达”融合方案，ODD限定为高速公路（无城市道路），设计最高车速120km/h。项目周期24个月，测试车队10辆，可用测试里程约200万公里/年。
初始现象与目标：在早期道路测试中，系统在雨天夜间场景下出现了3次误判——将路面积水反光识别为车道线，导致车辆异常转向。团队需要系统性解决此类问题，而不仅仅是修复单个bug。
关键输入数据：通过分析测试日志，发现误判均发生在“夜间+雨天+对向车道有来车”的组合条件下。摄像头图像中，积水反光区域与车道线的纹理特征相似度超过85%。毫米波雷达在此场景下无法提供有效的车道线信息。
分析判断过程：团队将“夜间+雨天+对向车灯照射”识别为触发条件，将其纳入场景库。通过仿真平台生成2000+个变体场景，量化评估了误判率与光照强度、积水面积、车速的关系。进一步分析发现，现有车道线检测算法对“镜面反射”缺乏鲁棒性。
实际操作步骤：① 在感知算法中增加“反射区域检测”模块，利用多帧时序信息和雷达点云进行交叉验证；② 在决策层增加“车道线置信度阈值”动态调整机制，当检测到反射条件时提高置信度要求；③ 在HMI层面增加“系统降级提示”，当感知置信度不足时提醒驾驶员接管；④ 更新场景库，将此类场景纳入回归测试集。
结果对比：改进后，在相同测试条件下，误判率从每千公里0.15次降低至0.002次，且未出现新的误判类型。系统在雨天夜间的可用性从82%提升至96%。
风险与代价：算法复杂度增加导致单帧处理时间增加约8ms，对芯片算力提出了更高要求；动态阈值机制在极端情况下可能增加不必要的接管请求，影响用户体验。
复盘经验：SOTIF问题的解决不能仅靠“打补丁”，需要建立从“场景发现→触发条件分析→算法改进→验证闭环”的完整流程。同时，场景库的持续积累是SOTIF开发的核心资产，需要建立跨项目共享机制。
3.5 SOTIF开发的常见误区与总结
在SOTIF的工程实践中，团队常犯以下错误，需要引起高度重视：
误区一：将SOTIF等同于“更多测试”。单纯增加测试里程无法系统性解决SOTIF问题。SOTIF的核心在于“场景的系统化识别与分析”，而非“测试数量的堆砌”。没有场景库支撑的测试，即使跑了几百万公里，也可能无法覆盖关键的不安全场景。
误区二：SOTIF只关注感知环节。虽然感知是SOTIF问题的重灾区，但决策逻辑的缺陷（如变道策略过于激进）、执行器的性能边界（如制动距离受路面附着系数影响）以及HMI设计不当（如接管请求时机不合理）同样属于SOTIF范畴。
误区三：SOTIF与功能安全割裂开发。两者在危害分析、安全目标定义、验证策略等方面存在大量重叠和交互。割裂开发会导致重复工作、安全目标冲突或覆盖空白。
总结复盘：SOTIF是智能驾驶安全体系不可或缺的组成部分。它从“功能是否足够好”的视角，补充了ISO 26262“功能是否按设计执行”的视角。ISO/PAS 21448提供了系统化的方法论，但其本质不是一套僵化的流程，而是一种“场景驱动、持续迭代”的安全思维方式。在实际项目中，建议将SOTIF活动嵌入到现有的功能安全开发流程中，形成统一的安全开发框架，同时建立跨项目的场景库共享机制，持续积累和复用SOTIF知识资产。