3. 功能安全基础
在L3自动驾驶系统中，电子电气架构的复杂度急剧上升，单点故障可能导致不可接受的整车级危害。ISO 26262作为道路车辆功能安全的国际标准，为自动驾驶冗余与安全架构提供了从概念到退役的全生命周期方法论。理解其核心概念，是设计任何冗余机制之前必须完成的基础功课。
一、核心概念：从“零缺陷”到“可接受风险”
ISO 26262并不追求绝对安全，而是要求将风险降低到可接受的水平。其核心概念包括：
- 安全（Safety）：避免因E/E系统失效导致的危害，区别于“信息安全（Security）”。
- 功能安全（Functional Safety）：通过功能与架构设计，使系统在失效时仍能进入安全状态。
- 相关项（Item）：实现车辆功能的系统或系统组合，如L3自动驾驶功能。
- 危害（Hazard）：可能造成伤害的潜在来源，如非预期转向。
- 安全目标（Safety Goal）：针对危害设定的顶层安全要求，如“避免非预期转向”。
- 功能安全概念（FSC）：将安全目标分解为功能层面的安全需求与初步架构。
关键逻辑：危害 → 安全目标 → 功能安全需求 → 技术安全需求 → 硬件/软件安全需求。每一层都必须可追溯。
二、ASIL等级：风险量化与开发强度
ASIL（Automotive Safety Integrity Level）由三个维度决定：严重度（S）、暴露率（E）和可控性（C）。三者组合后映射为QM、ASIL A、B、C、D五个等级，D为最高。
| 维度 | 等级 | 含义 |
|---|---|---|
| 严重度 S | S0~S3 | 无伤害到致命伤害 |
| 暴露率 E | E0~E4 | 极低概率到高概率暴露 |
| 可控性 C | C0~C3 | 完全可控到难以控制 |
| ASIL | QM/A/B/C/D | 开发严格度递增 |
例如，L3自动驾驶中“非预期制动”若在高速场景下发生，S3、E4、C3，则对应ASIL D。ASIL等级直接决定开发流程、验证方法、硬件失效率目标（如ASIL D要求随机硬件失效概率小于10^-8/h）以及软件架构约束。
三、安全生命周期：从概念到退役
ISO 26262定义了完整的安全生命周期，主要阶段包括：
- 相关项定义：明确功能边界、接口、运行环境。
- 危害分析与风险评估（HARA）：识别危害、评估ASIL、制定安全目标。
- 功能安全概念：分配安全目标到架构元素，定义功能安全需求。
- 技术安全概念：将功能需求转化为技术方案，包括冗余、监控、降级策略。
- 系统开发与集成：硬件、软件按ASIL要求开发并集成。
- 安全验证与确认：测试、分析、评审，证明满足安全目标。
- 生产、运行、退役：确保量产一致性，现场监控与退役管理。
每个阶段都有对应的输出物和工作产品，且必须建立双向追溯关系。对于L3系统，安全生命周期还需与预期功能安全（SOTIF）协同，处理性能局限和误用问题。
四、危害分析与风险评估（HARA）方法
HARA是功能安全的起点，通常按以下步骤执行：
1. 定义相关项功能与边界
2. 识别功能失效模式（如丢失、错误、非预期激活）
3. 分析整车级危害（如非预期加速、转向失控）
4. 评估S/E/C，确定ASIL
5. 制定安全目标（SG）
6. 导出功能安全需求（FSR）
以L3自动变道为例：若变道过程中目标车道有车，系统未识别并执行变道，可能导致碰撞。S3、E4、C3 → ASIL D。安全目标可定义为“避免在目标车道有车时执行非预期变道”。功能安全需求则包括“变道前必须确认目标车道安全”等。
HARA不是一次性活动，当系统功能、运行场景或架构发生变更时，必须重新评估。
五、安全目标与功能安全概念
安全目标是危害的最高层安全要求，必须满足：
- 针对每个危害至少一个安全目标；
- 包含ASIL等级；
- 不涉及具体技术方案；
- 可验证、可追溯。
功能安全概念（FSC）则将安全目标分解为功能安全需求，并分配到初步架构元素。例如，安全目标“避免非预期转向”可分解为：
- FSR1：系统应能检测转向指令的合理性；
- FSR2：系统应具备独立于主转向路径的冗余监控；
- FSR3：检测到异常时，应在规定时间内进入安全状态。
这些需求进一步导出技术安全需求，如“双绕组电机冗余”“独立扭矩监控”“安全状态切换时间≤100ms”等。
六、案例与误区复盘
案例：某L3车型在高速巡航时，因单目摄像头误识别导致非预期制动。HARA分析：S3、E4、C3 → ASIL D。安全目标为“避免非预期制动”。功能安全概念要求增加毫米波雷达冗余感知，并设计独立制动监控模块。技术安全需求包括：双通道制动指令校验、失效时降级为人工驾驶并发出接管请求。
常见误区：
- 把ASIL等级当作“质量等级”，忽略其与开发流程的强绑定；
- HARA只做一次，变更后不更新；
- 安全目标写成技术方案，如“使用双MCU”，导致无法追溯；
- 忽略可控性评估，导致ASIL定级偏低；
- 功能安全概念与系统架构脱节，需求无法落地。
正确做法是：先完成HARA，再定义安全目标，然后逐层分解为功能安全需求和技术安全需求，并确保每一层都有验证方法和追溯矩阵。对于L3自动驾驶，还需特别关注降级策略、人机接管接口和最小风险状态（MRM）的设计。
掌握ISO 26262的核心概念、ASIL定级逻辑、安全生命周期、HARA方法以及安全目标与功能安全概念的分解关系，是后续设计L3自动驾驶冗余架构、监控机制和降级策略的理论基石。只有将安全需求逐层落实到硬件与软件，才能构建真正可接受风险的系统。