3. 功能安全基础
在自动驾驶系统量产验证中，功能安全不是“附加项”，而是决定系统能否合法上路、能否被整车厂接受、能否通过第三方审核的基础门槛。ISO 26262 是道路车辆功能安全的国际标准，它把“避免因电子电气系统失效而导致不可接受风险”这一目标，拆解为可管理、可验证、可追溯的工程活动。理解 ISO 26262 的关键，不是背条款，而是掌握三条主线：风险如何定级（ASIL）、安全活动如何贯穿生命周期、危害如何被系统识别与评估。
一、ISO 26262 的定位与核心思想
ISO 26262 面向量产乘用车，覆盖从概念设计到报废的完整安全生命周期。它的核心思想是：安全不是靠单点冗余堆出来的，而是靠“危害分析—安全目标—安全需求—安全机制—验证确认”的闭环推导出来的。标准将系统划分为硬件、软件、系统三个层面，并要求每个层面都建立对应的安全需求与验证证据。
在自动驾驶场景中，ISO 26262 主要处理的是 E/E 系统的功能失效，例如传感器误判、控制器输出错误、通信丢帧、执行器卡滞等。需要特别注意的是，ISO 26262 并不直接覆盖“性能局限”导致的危险，例如摄像头在强光下识别率下降，这类问题更多由预期功能安全（SOTIF，ISO 21448）处理。因此，量产验证中通常需要 26262 与 21448 并行推进。
关键区分：ISO 26262 管“失效”，ISO 21448 管“性能不足”。自动驾驶系统两者都要管，缺一不可。
二、ASIL 等级：风险定量的核心标尺
ASIL（Automotive Safety Integrity Level）是 ISO 26262 中用于衡量风险严重程度的安全完整性等级，分为 A、B、C、D 四个等级，D 最高，A 最低，另有 QM（质量管理）表示无需专门功能安全活动。ASIL 由三个维度共同决定：
- 严重度 S（Severity）：伤害程度，S0 无伤害到 S3 致命伤害；
- 暴露率 E（Exposure）：场景发生的概率，E0 极低到 E4 高概率；
- 可控性 C（Controllability）：驾驶员或其他人员避免伤害的可能性，C0 完全可控到 C3 难以控制。
三者组合后通过标准中的查表关系确定 ASIL 等级。例如 S3 + E4 + C3 通常对应 ASIL D，而 S1 + E1 + C1 可能仅为 QM。ASIL 等级直接决定开发过程的严格程度：ASIL D 要求更高的诊断覆盖率、更严格的开发流程、更完整的验证证据，以及更低的失效率目标。
| ASIL 等级 | 典型场景示例 | 硬件失效率目标（参考） | 开发严格度 |
|---|---|---|---|
| QM | 车内氛围灯控制 | 无专门要求 | 常规质量管理 |
| ASIL A | 后视镜调节 | 较低 | 基础安全活动 |
| ASIL B | 仪表盘显示 | 中等 | 中等安全活动 |
| ASIL C | 自适应巡航 | 较高 | 较高安全活动 |
| ASIL D | 自动紧急制动、转向控制 | 极高 | 最高安全活动 |
在自动驾驶中，涉及横向和纵向运动控制的功能通常被定为 ASIL D，例如 AEB、LKA、ACC 的核心控制链路。感知融合、规划决策等模块则根据具体失效模式和场景暴露率进行分解，可能采用 ASIL B(D) 或 ASIL C(D) 的分解策略，即通过冗余架构把高等级需求分解为两个较低等级独立实现。
三、安全生命周期：从概念到报废的闭环
ISO 26262 将安全生命周期划分为多个阶段，每个阶段都有明确的输入、输出和验证要求。核心阶段包括：
- 相关项定义：明确系统边界、功能、接口和运行环境；
- 危害分析与风险评估（HARA）：识别危害事件，确定 ASIL 等级，导出安全目标；
- 功能安全概念：将安全目标分解为功能安全需求，分配至架构元素；
- 技术安全概念：将功能安全需求细化为硬件和软件技术安全需求；
- 系统开发与集成：实现安全机制，完成软硬件集成；
- 安全验证与确认：通过测试、分析、评审证明安全目标达成；
- 生产、运行、服务与报废：确保量产一致性，处理现场失效与更新。
安全生命周期的关键不是“走完流程”，而是可追溯性：每一个安全目标都能追溯到危害事件，每一个安全需求都能追溯到安全目标，每一个测试用例都能追溯到安全需求。量产审核时，审核员最关注的就是这条追溯链是否完整、是否有证据支撑。
四、危害分析与风险评估的实操要点
HARA 是 ISO 26262 中最具技术含量的环节之一。它的输出直接决定后续所有安全活动的强度。实操中常见的做法是：先定义相关项的功能和边界，再通过 HAZOP 引导词或 STPA 方法系统性地识别危害事件，然后对每个危害事件进行 S/E/C 评估，最后导出安全目标。
以“自动紧急制动（AEB）误触发”为例：危害事件是车辆在无碰撞风险时突然制动。严重度 S 可能为 S3（后车追尾导致致命伤害），暴露率 E 为 E4（高速跟车场景常见），可控性 C 为 C3（驾驶员难以在毫秒级纠正）。组合后通常定为 ASIL D。对应的安全目标可能是：“AEB 不应在无碰撞风险时触发制动”，并进一步分解为感知置信度校验、执行器使能条件、故障降级策略等技术安全需求。
常见误区：把 HARA 当成一次性文档任务，写完就归档。实际上 HARA 是活文档，随着 ODD 扩展、传感器配置变更、现场失效数据积累，必须定期复审和更新。否则安全案例会与实际系统脱节，量产审核时极易被挑战。
五、量产验证中的落地建议
在自动驾驶量产项目中，建议把 ISO 26262 的安全活动与系统工程流程合并管理，而不是并行两套文档。具体做法包括：
- 用需求管理工具建立“危害—安全目标—安全需求—测试用例”的双向追溯矩阵；
- 对 ASIL D 功能采用冗余架构，并明确冗余通道的独立性论证；
- 把安全机制的有效性纳入 HIL 和实车测试用例，而不是只做纸面分析；
- 在安全案例中明确列出假设、边界和残余风险，避免过度承诺。
功能安全不是让系统“绝对不出错”，而是让风险被识别、被量化、被控制、被证明。ISO 26262 提供的正是这套可审核、可追溯、可量产的工程语言。掌握 ASIL 定级逻辑、安全生命周期闭环和 HARA 方法，是自动驾驶安全验证工程师的基本功。