课程导入:SOTIF的起源、ISO 21448的定位、与ISO 26262的关系、课程学习目标与适用人群

当一辆搭载高级驾驶辅助系统(ADAS)的车辆在晴朗天气下将白色货车误判为天空而径直撞上时,当一辆自动驾驶出租车在夜间面对翻倒的卡车因无法识别而紧急制动失败时,我们面对的并非传统意义上的“功能故障”,而是系统在预期功能范围内因性能局限或场景理解不足所引发的安全风险。这类事故的根源,恰恰指向了功能安全标准ISO 26262覆盖之外的空白地带——预期功能安全(SOTIF)。本章作为《道路车辆预期功能安全(SOTIF)ISO 21448深度解读》的开篇,将系统梳理SOTIF的诞生背景、ISO 21448的标准定位、其与ISO 26262的协同关系,并明确本课程的学习目标与适用人群,为后续章节的深入展开奠定坚实的认知框架。

SOTIF与ISO 21448定位全景图 SOTIF起源 • 2018年ISO 21448第一版发布 • 源于L2+级ADAS事故频发 • 传感器性能局限与场景理解 • 算法边界与用户误用 • 2024年发布第二版修订 ISO 21448核心 • 预期功能安全(SOTIF) • 功能不足与触发条件分析 • 场景识别与风险评估 • 验证与确认策略 • 安全性能释放与改进 ISO 26262 • 功能安全(Functional Safety) • 系统性失效与随机硬件失效 • ASIL等级与安全完整性 • 开发流程与安全文化 • 2011年第一版,2018年第二版 ISO 21448与ISO 26262的协同关系 • 互补关系:ISO 26262处理“系统故障”,ISO 21448处理“性能不足” • 共同目标:降低整车安全风险,覆盖从L1到L4+的自动驾驶场景 课程学习目标 ① 理解SOTIF核心概念与标准框架 ② 掌握场景分析与风险评估方法 ③ 学会制定验证与确认策略 ④ 能够落地实施SOTIF开发流程

一、SOTIF的起源:从功能安全到预期功能安全的必然演进

1. 核心原理:为什么需要SOTIF?

传统功能安全(ISO 26262)聚焦于系统故障——即电子电气系统的硬件随机失效、软件系统性缺陷或人为操作失误。然而,随着ADAS和自动驾驶技术的快速发展,一个更为隐蔽且高频的风险源浮出水面:系统本身设计良好、无任何故障,但其预期功能在特定场景下表现不足。例如,摄像头在逆光条件下无法识别交通标志,毫米波雷达对静止目标的漏检,或算法在罕见交通场景中的决策失误。这类问题不涉及“故障”,而是源于功能性能局限与场景理解不完整,这正是SOTIF要解决的范畴。

SOTIF(Safety of the Intended Functionality)的概念最早由ISO/TC 22/SC 32/WG 8工作组提出,旨在补充ISO 26262的覆盖盲区。2018年,ISO 21448第一版正式发布,2024年发布第二版修订,进一步明确了SOTIF在自动驾驶安全论证中的核心地位。

2. 判断方法:如何识别SOTIF相关风险?

SOTIF风险识别需从三个维度展开:

  • 功能不足(Functional Insufficiency):系统在感知、决策、执行环节的性能局限,如传感器探测距离不足、算法对遮挡目标的误判。
  • 触发条件(Triggering Conditions):导致功能不足被激活的特定场景要素,如天气、光照、道路类型、交通参与者行为等。
  • 可预见误用(Reasonably Foreseeable Misuse):用户对系统能力的错误假设或不当操作,如过度依赖自动驾驶而分心驾驶。
经验提醒:在项目早期建立“场景-功能-风险”映射矩阵,将已知和未知场景分类管理,是SOTIF分析的第一步。建议使用GAS(Guideword Analysis)和STPA(System-Theoretic Process Analysis)等系统性方法辅助识别。

3. 案例拆解:特斯拉Autopilot与白色货车事故

2016年,美国佛罗里达州一辆特斯拉Model S在Autopilot模式下与一辆白色半挂卡车相撞,驾驶员死亡。事故调查显示:

  • 初始现象:摄像头将白色货车车厢误判为天空,毫米波雷达未将静止目标列为优先处理对象。
  • 关键输入数据:晴朗天气、高对比度光照、货车横穿公路、车速约110km/h。
  • 分析判断过程:系统融合策略中,摄像头置信度高于雷达,导致目标被过滤;同时,系统对“静止大型物体”的决策逻辑存在缺陷。
  • 实际操作步骤:事后特斯拉更新了雷达信号处理优先级,并增加摄像头对“非标准形状物体”的识别训练。
  • 结果对比:后续版本中类似场景的误判率显著下降,但该事件暴露了SOTIF分析的紧迫性。

这一案例深刻说明:没有故障的系统也可能导致致命事故,SOTIF分析必须贯穿于系统定义、设计、验证的全过程。

4. 常见误区与总结复盘

风险提示:许多团队将SOTIF视为“功能安全的补充文档”,仅在项目后期进行“补课式”分析。这种做法会导致场景覆盖不足、验证策略缺失,最终在监管审查或事故调查中面临重大风险。

总结复盘:SOTIF的起源并非学术空想,而是源于真实事故的惨痛教训。其核心价值在于将安全分析从“系统是否故障”扩展到“系统是否足够好”,从“已知风险”扩展到“未知风险”,从“设计意图”扩展到“实际使用场景”。

二、ISO 21448的定位:标准框架与核心概念

1. 核心原理:ISO 21448在安全标准体系中的位置

ISO 21448《道路车辆—预期功能安全》为SOTIF活动提供了系统化的方法论框架。其核心定位包括:

  • 覆盖范围:适用于L1-L4级驾驶辅助及自动驾驶系统,包括感知、决策、执行全链路。
  • 生命周期:覆盖概念阶段、开发阶段、验证阶段、生产与运行阶段的全生命周期。
  • 核心活动:包括SOTIF相关危害识别、风险评估、功能不足分析、验证与确认策略制定、安全性能释放等。
维度 ISO 26262(功能安全) ISO 21448(预期功能安全)
风险来源 系统性故障、随机硬件失效 功能性能不足、场景理解局限
分析对象 电子电气系统架构、软件、硬件 感知算法、决策逻辑、执行机构、使用场景
安全等级 ASIL A-D 无直接等级,基于风险接受准则
验证方法 故障注入、FMEA、FTA 场景库测试、仿真、实车验证
生命周期 从概念到退役 从概念到运行阶段持续监控

2. 判断方法:ISO 21448的核心工作流程

  1. 场景定义与分类:建立场景库,区分已知安全场景、已知不安全场景、未知不安全场景。
  2. 危害识别与风险评估:基于场景分析,识别潜在危害并评估其严重度、暴露概率和可控性。
  3. 功能不足分析:针对每个危害场景,分析系统功能不足的具体表现和触发条件。
  4. 验证与确认策略:制定仿真、台架、实车测试计划,覆盖已知场景并探索未知场景。
  5. 安全性能释放:通过迭代优化,将残余风险降低到可接受水平。
关键要点:ISO 21448强调“安全性能释放”概念,即系统在特定运行设计域(ODD)内达到可接受的安全水平。这要求企业在开发过程中持续收集运行数据,不断优化系统性能。

3. 案例拆解:Waymo的SOTIF实践

Waymo在凤凰城的自动驾驶出租车服务中,建立了完善的SOTIF管理体系:

  • 背景与约束:运营区域覆盖城市道路、高速公路、施工区等复杂场景,需满足亚利桑那州监管要求。
  • 关键输入数据:累计超过2000万英里的真实路测数据,以及数百万英里的仿真测试数据。
  • 分析判断过程:通过场景挖掘工具自动识别“边缘案例”,如异常车辆行为、极端天气、道路施工等。
  • 实际操作步骤:建立“场景-功能-风险”数据库,每周更新风险矩阵,并针对高风险场景进行专项算法优化。
  • 结果对比:其脱离接管率(MPI)从早期的每千英里数次提升至每万英里不足一次。

Waymo的实践表明,SOTIF不是一次性的分析活动,而是需要持续投入的工程能力建设。

4. 常见误区与总结复盘

风险提示:部分企业将ISO 21448视为“文档合规”任务,仅生成分析报告而不指导实际开发。这种“两张皮”的做法无法真正提升系统安全性,反而可能因虚假安全感导致更严重的后果。

总结复盘:ISO 21448的定位是“方法论指南”而非“技术规范”,它不规定具体的技术方案,而是提供一套系统化的分析框架。企业需要根据自身产品特点,将标准要求转化为具体的工程实践。

三、与ISO 26262的关系:互补与协同

1. 核心原理:两大标准的边界与交集

ISO 26262和ISO 21448共同构成了道路车辆电子电气系统安全的完整体系。两者的关系可以概括为:

  • 互补性:ISO 26262处理“系统是否按设计工作”,ISO 21448处理“设计本身是否足够安全”。
  • 重叠区:在系统架构设计、安全分析、验证策略等方面存在交叉,需要统一协调。
  • 协同性:ISO 21448的SOTIF分析结果可作为ISO 26262安全案例的输入,反之亦然。

2. 判断方法:如何整合两大标准

开发阶段 ISO 26262活动 ISO 21448活动 整合要点
概念阶段 HARA分析、安全目标定义 场景定义、SOTIF危害识别 共享场景库,统一风险接受准则
系统设计 技术安全概念、FMEA 功能不足分析、触发条件识别 将SOTIF约束纳入系统架构设计
验证阶段 故障注入测试、可靠性测试 场景库测试、仿真验证 统一测试用例管理,共享测试资源
运行阶段 售后监控、OTA更新 运行数据收集、性能持续优化 建立联合监控机制,协同改进

3. 案例拆解:某OEM的整合实践

某主流OEM在开发L3级高速公路领航辅助系统时,建立了“双轨并行、统一管理”的安全开发体系:

  • 背景与约束:项目周期24个月,需同时满足ISO 26262 ASIL-B和ISO 21448要求。
  • 关键输入数据:系统包含6个摄像头、5个毫米波雷达、3个激光雷达,算力平台为双英伟达Orin。
  • 分析判断过程:初期团队将两大标准分开执行,导致重复工作和资源浪费。后调整为统一的安全分析团队,共享场景库和风险数据库。
  • 实际操作步骤:建立“安全分析工作台”,将HARA与SOTIF危害识别合并进行,统一输出安全需求。
  • 结果对比:分析效率提升40%,安全需求覆盖率提升25%,并通过了第三方审核。

这一案例说明,两大标准的整合不是简单的文档合并,而是需要从组织架构、流程方法、工具链等多个层面进行系统性融合。

4. 常见误区与总结复盘

风险提示:一种常见误区是“用ISO 26262替代ISO 21448”,认为只要功能安全做得好,SOTIF自然满足。另一种误区是“完全割裂”,将两大标准视为独立的合规任务。这两种做法都无法实现真正的系统安全。

总结复盘:ISO 26262与ISO 21448的关系是“一体两翼”——功能安全是基础,预期功能安全是延伸。企业应建立统一的安全管理体系,将两大标准的要求融入产品开发的全生命周期。

四、课程学习目标与适用人群

1. 核心原理:本课程能带来什么价值?

本课程旨在帮助学员建立完整的SOTIF知识体系和实践能力,具体目标包括:

  • 理论层面:深入理解ISO 21448标准条款、核心概念和最新修订动态。
  • 方法层面:掌握场景分析、风险评估、验证策略等关键方法。
  • 实践层面:能够独立开展SOTIF分析项目,制定符合标准要求的开发计划。
  • 战略层面:理解SOTIF对自动驾驶商业化落地和监管合规的战略意义。

2. 判断方法:你是否适合学习本课程?

角色 学习重点 预期收益
功能安全工程师 SOTIF与功能安全的整合方法 拓展安全分析能力,提升职业竞争力
自动驾驶算法工程师 功能不足分析与场景优化 从安全视角审视算法设计,减少事故风险
系统架构师 SOTIF对系统设计的影响 设计更安全、更可靠的自动驾驶系统
测试验证工程师 场景库构建与验证策略 制定更有效的测试计划,提升测试覆盖率
项目管理人员 SOTIF开发流程与资源规划 合理规划项目资源,确保合规交付
监管与认证人员 标准解读与审核要点 提升审核能力,把握监管趋势

3. 案例拆解:不同角色的学习路径

以一位功能安全工程师为例,其学习路径可能包括:

  • 第一阶段:系统学习ISO 21448标准条款,理解SOTIF核心概念。
  • 第二阶段:掌握场景分析工具(如GAS、STPA)和风险评估方法。
  • 第三阶段:参与实际SOTIF分析项目,积累实战经验。
  • 第四阶段:深入研究SOTIF与功能安全的整合方法,成为复合型安全专家。

4. 常见误区与总结复盘

经验提醒:学习SOTIF不能仅停留在标准条文的理解上,必须结合真实案例和工程实践。建议学员在学习过程中,同步关注行业动态(如NHTSA、EU GSR等监管要求),并参与开源场景库(如NuScenes、Waymo Open Dataset)的实践。

总结复盘:本课程将采用“理论讲解+案例拆解+实战演练”的教学模式,帮助学员在30个章节中系统构建SOTIF知识体系。无论您是安全工程师、算法开发者还是项目管理者,都能在本课程中找到与自身工作紧密结合的实用内容。