3. 功能安全基础
在自动驾驶系统中，电子电气（E/E）架构的复杂度、软件规模以及外部环境的不确定性都远高于传统汽车。功能安全（Functional Safety）关注的是：当系统发生随机硬件失效或系统性设计缺陷时，如何把风险控制在可接受范围内。ISO 26262 是道路车辆功能安全的国际标准，它为整车、系统、硬件、软件到半导体层面提供了一套贯穿全生命周期的安全工程框架。理解 ISO 26262，核心要抓住三条主线：风险分级（ASIL）、安全生命周期、危害分析与风险评估（HARA）。
一、ISO 26262 的定位与结构
ISO 26262 不是单一文档，而是由多个部分组成的标准族。它覆盖从概念阶段到产品退役的全过程，主要部分包括：
- Part 3 概念阶段：定义相关项（Item）、进行 HARA、确定 ASIL、制定功能安全概念（FSC）。
- Part 4 系统级：技术安全需求（TSR）、系统架构设计、安全验证。
- Part 5 硬件级：硬件安全需求、诊断覆盖率、失效模式与失效率指标。
- Part 6 软件级：软件安全需求、架构、单元设计与测试。
- Part 7 生产与运行：制造、维护、报废阶段的安全活动。
- Part 8 支持过程：配置管理、变更管理、验证确认、文档管理。
- Part 9 ASIL 导向与安全分析：FMEA、FTA、DFA 等方法要求。
- Part 10 指南：为标准的应用提供解释与示例。
- Part 11 半导体：针对芯片级功能安全的补充要求。
- Part 12 摩托车：面向两轮车的适配。
对自动驾驶而言，最常打交道的部分是 Part 3、4、5、6、9。概念阶段决定“要做多安全”，系统与软硬件阶段决定“如何做到这么安全”。
二、ASIL 等级：从 QM 到 ASIL D
ASIL（Automotive Safety Integrity Level）是 ISO 26262 用来表达安全完整性等级的分级，共分为 QM、ASIL A、B、C、D 五档，其中 ASIL D 要求最严。ASIL 由三个维度共同决定：
- 严重度 S（Severity）：S0 无伤害，S1 轻中度，S2 重度，S3 危及生命。
- 暴露率 E（Exposure）：E0 几乎不可能，E1 极低概率，E2 低概率，E3 中等概率，E4 高概率。
- 可控性 C（Controllability）：C0 完全可控，C1 简单可控，C2 一般可控，C3 难以控制。
三者组合后映射到 ASIL 等级。例如 S3 + E4 + C3 通常对应 ASIL D；S1 + E1 + C1 可能仅为 QM。ASIL 等级越高，对开发流程、验证方法、硬件失效率指标（如 SPFM、LFM）和软件架构约束的要求越严格。
关键理解：ASIL 不是对“系统整体”的一个标签，而是对每一条安全目标（Safety Goal）分别评定的。同一个自动驾驶相关项中，不同危害事件可能得到不同 ASIL 等级。
三、安全生命周期：从概念到退役
安全生命周期是 ISO 26262 的骨架，它把功能安全活动按时间顺序组织起来，确保安全需求可追溯、可验证、可维护。典型阶段包括：
- 相关项定义：明确系统边界、功能、接口、运行环境。
- HARA：识别危害事件，评估 S/E/C，确定 ASIL，导出安全目标。
- 功能安全概念（FSC）：把安全目标分解为功能安全需求，分配初步架构。
- 技术安全概念（TSC）：将功能安全需求细化为技术安全需求，落到系统、硬件、软件。
- 系统与软硬件开发：设计、实现、集成，并执行安全分析（FMEA、FTA、DFA）。
- 安全验证与确认：验证安全需求是否被满足，确认安全目标是否达成。
- 生产、运行、维护与退役：确保量产一致性、现场监控、变更管理与最终退役安全。
安全生命周期的关键不是“一次性通过”，而是双向追溯：从安全目标到需求、到设计、到测试用例，再反向回溯，任何变更都要重新评估影响。
四、HARA：危害分析与风险评估
HARA 是概念阶段最核心的活动，目标是回答三个问题：什么可能出错？后果有多严重？需要多高的安全完整性？其标准流程如下：
- 相关项定义与功能分析：列出功能、运行模式、边界条件。
- 危害识别：从功能失效出发，识别整车级危害事件，如非预期制动、转向失控、感知漏检。
- 场景与工况分析：结合道路类型、车速、交通参与者、天气等确定运行场景。
- S/E/C 评估：对每个危害事件分别评定严重度、暴露率、可控性。
- ASIL 确定：查表得到 ASIL 等级，QM 表示无需功能安全专项要求。
- 安全目标制定：为每个高 ASIL 危害事件定义安全目标，如“避免非预期最大制动减速度”。
- 安全状态与故障容错时间：定义系统进入安全状态的方式与可用时间。
下面这张图展示了 HARA 从功能失效到安全目标的完整推导链路，以及 ASIL 在其中的位置。
五、案例：自动紧急制动（AEB）的 HARA 片段
以 AEB 为例，假设相关项为“前方碰撞预警与自动紧急制动”。一个典型危害事件是“在无碰撞风险时触发非预期最大制动”。
| 评估维度 | 取值 | 理由 |
|---|---|---|
| 严重度 S | S3 | 高速下非预期急刹可能导致后车追尾，危及生命 |
| 暴露率 E | E4 | 高速公路行驶属于高频场景 |
| 可控性 C | C3 | 驾驶员难以在毫秒级时间内纠正误制动 |
| ASIL | ASIL D | S3 + E4 + C3 组合 |
| 安全目标 | 避免非预期最大制动 | 需通过冗余感知、制动使能条件、故障降级等实现 |
这个例子说明：ASIL D 并不是“整个 AEB 都是 ASIL D”，而是针对“非预期最大制动”这一条安全目标。AEB 的“漏触发”可能是另一个安全目标，其 ASIL 等级需要单独评估。
六、常见误区与复盘要点
误区一：把 ASIL 当成系统属性。ASIL 是安全目标的属性，不是 ECU 或软件的属性。一个系统可以同时承载 ASIL D、ASIL B 和 QM 的多条安全目标。
误区二：HARA 只做一次。当运行设计域（ODD）、功能定义、法规或架构发生变更时，HARA 必须重新评估。
误区三：只关注硬件失效率。ISO 26262 同样强调系统性失效，软件架构、需求质量、验证充分性同样决定功能安全成败。
误区四：忽略可控性论证。C 的取值需要人因工程、驾驶员反应时间、场景可干预性等证据支撑，不能凭感觉填写。
复盘建议：在项目早期建立“安全目标—ASIL—安全需求—验证用例”的追溯矩阵，并在每次架构变更后检查追溯链是否完整。对自动驾驶而言，HARA 还应与 SOTIF（预期功能安全）分析联动，区分“功能失效”与“功能不足”两类风险。
示例：安全目标追溯矩阵片段
SG-01 避免非预期最大制动 ASIL D
FSR-01.1 制动使能需满足多源确认
FSR-01.2 单点故障时进入降级制动
TSR-01.1 制动控制器双核锁步
TSR-01.2 感知融合结果需交叉校验
TC-01.1 注入误制动信号，验证降级时间 < 100 ms
TC-01.2 模拟单核失效，验证安全状态可达掌握 ISO 26262 的关键，不在于背诵条款，而在于理解“风险分级驱动开发严格度”这一逻辑。ASIL 决定投入多少安全活动，安全生命周期保证这些活动有序可追溯，HARA 则是整个安全工程的起点。对自动驾驶系统而言，只有把 HARA 做扎实，后续的系统架构、冗余设计、诊断覆盖和验证策略才有稳固的根基。