3. 功能安全与预期功能安全入门
在自动驾驶安全验证体系中，ISO 26262 与 ISO 21448 是两套最常被同时引用的标准。前者关注由电子电气系统故障引发的功能安全（Functional Safety, FuSa），后者关注在没有系统故障时，因性能局限、场景理解不足或合理可预见误用而引发的预期功能安全（Safety of the Intended Functionality, SOTIF）。理解两者的边界、互补关系以及安全生命周期，是后续危害分析、验证确认和故障工程工作的共同语言。
一、核心原理：故障安全与预期功能安全的分工
ISO 26262 的核心假设是：系统本身按设计工作，但硬件随机失效、软件系统性失效或外部干扰可能导致功能异常。它通过 ASIL（Automotive Safety Integrity Level，A～D）分级，要求对危害进行风险降低，使残余风险可接受。典型手段包括冗余、监控、安全状态切换、故障响应时间约束等。
ISO 21448 则处理另一类风险：系统没有故障，但功能本身不够完善。例如摄像头在逆光下漏检、毫米波雷达对静止金属板误判、感知模型对异形车辆识别置信度不足，或驾驶员过度信任自动辅助驾驶而分心。SOTIF 的目标不是消除所有失效，而是把由性能局限和可预见误用导致的危害降低到可接受水平。
一句话区分：ISO 26262 问“系统坏了怎么办”；ISO 21448 问“系统没坏，但能力不够或场景没覆盖到，怎么办”。
二、安全生命周期：从概念到运行的主线
两套标准都强调“安全生命周期”而非一次性测试。ISO 26262 的安全生命周期通常包括：相关项定义、危害分析与风险评估、安全目标与功能安全概念、技术安全概念、系统与软硬件开发、集成验证、安全确认、生产运行与退役。ISO 21448 则围绕 SOTIF 活动展开：功能与场景定义、危害识别、风险评价、功能不足与触发条件分析、改进措施、验证与确认、运行阶段监控。
在工程实践中，二者常被整合为一条主线：先由 HARA 识别危害并分配 ASIL，再由 SOTIF 分析补充“无故障但性能不足”的场景，最后统一进入验证确认。下面这张图展示了 FuSa 与 SOTIF 在安全生命周期中的并行与交汇关系。
三、关键术语与对比清单
两套标准术语容易混淆，下表给出工程中最常用的对照关系。理解这些术语，有助于在危害分析、需求分解和测试用例设计中保持一致的语义。
| 术语 | 所属标准 | 含义 | 工程落点 |
|---|---|---|---|
| ASIL | ISO 26262 | 汽车安全完整性等级，A～D，D 最高 | 决定开发流程严格度与验证强度 |
| 安全目标 | ISO 26262 | 针对危害事件需达到的最高安全要求 | 分解为功能安全需求与技术安全需求 |
| 安全状态 | ISO 26262 | 系统发生故障后可进入的低风险运行模式 | 降级、限速、靠边停车、请求接管 |
| ODD | ISO 21448 | 设计运行域，功能可安全运行的条件集合 | 定义场景边界与退出策略 |
| 触发条件 | ISO 21448 | 使功能不足暴露为危害的场景或环境因素 | 逆光、雨雾、异形障碍物、施工区 |
| 已知不安全 | ISO 21448 | 已识别但尚未完全消除的风险场景 | 通过改进或限制 ODD 降低风险 |
| 未知不安全 | ISO 21448 | 尚未识别、可能存在的风险场景 | 靠场景挖掘、现场监控与数据闭环发现 |
四、案例场景：AEB 逆光误判如何同时触发两套标准
假设一辆具备 AEB 功能的车辆在傍晚逆光下行驶，前方有一辆静止的白色货车。摄像头因高动态范围不足，未能及时识别目标；毫米波雷达将货车后部金属板误判为地面杂波。此时系统没有发生硬件故障，但感知性能不足导致制动过晚，形成碰撞风险。
- ISO 26262 视角：需要确认是否存在传感器失效、通信丢帧或制动执行器响应异常；若存在随机硬件失效，则按 ASIL 分配安全机制，如传感器冗余、心跳监控、制动回路自检。
- ISO 21448 视角：需要分析逆光、白车、静止目标、金属反射等触发条件，评估感知算法在 ODD 边界内的性能局限，并通过场景库补充测试、算法改进或限制使用条件来降低风险。
- 共同落点：无论哪条主线，最终都要形成可验证的安全需求，并在集成测试、场地测试和道路测试中确认残余风险可接受。
工程提示：不要把 SOTIF 当作“功能安全之外的补充文档”。在自动驾驶项目中，感知、规划、控制各层的性能局限都应进入 SOTIF 分析；而故障检测、冗余切换、安全状态则属于 FuSa 的核心设计对象。两者在系统架构上往往共享同一套监控与降级机制。
五、常见误区与复盘
误区一：认为没有故障就没有安全问题。自动驾驶大量风险来自“系统正常工作但能力不足”，例如对锥桶、动物、异形车辆的识别失败。这类问题必须用 SOTIF 方法处理。
误区二：把 ASIL 等级直接等同于 SOTIF 风险等级。ASIL 针对故障危害，SOTIF 关注性能局限与误用，两者评价维度不同，不能简单互换。
误区三：只做测试，不做场景定义与触发条件分析。没有 ODD 和场景库，测试覆盖无法度量，未知不安全区域也无法收敛。
误区四：忽略运行阶段监控。安全生命周期不止于量产发布。现场数据回流、影子模式、OTA 改进和事件复盘，是持续降低 SOTIF 风险的关键环节。
安全生命周期最小闭环示例：
1. 定义相关项与 ODD
2. HARA + SOTIF 危害识别
3. 分配 ASIL 与安全目标
4. 设计安全机制与性能改进措施
5. 集成验证 + 场景确认
6. 运行监控与数据闭环
7. 复盘并更新危害分析与场景库
掌握 ISO 26262 与 ISO 21448 的分工与交汇，是后续开展危害分析、安全需求分解、测试验证和故障工程的基础。功能安全解决“坏了怎么办”，预期功能安全解决“不够好怎么办”，而安全生命周期把两者统一到从概念到运行的全过程管理中。