1. ISO 26262 概述：功能安全背景、标准发展历程、ASIL等级定义与分解
1.1 为什么我们需要功能安全？
先聊点实际的。你想想看，一辆车上现在有多少个电子控制单元？从几十个到上百个不等。这些ECU控制着转向、制动、动力总成，甚至自动驾驶。如果某个软件bug或者硬件失效导致刹车失灵，后果是什么？
我入行那会儿，功能安全在国内还是个新鲜词。大家更关注“功能能不能实现”，很少有人问“如果它坏了会怎样”。直到2010年前后，丰田的“ unintended acceleration ”事件闹得沸沸扬扬，整个行业才开始认真审视这个问题。
说白了，功能安全就是回答三个问题：
- 系统会不会失效？ —— 概率问题
- 失效了会怎样？ —— 危害分析
- 怎么防止它失效，或者失效后怎么保证安全？ —— 安全机制
核心观点：功能安全不是“不出故障”，而是“故障发生时，系统仍然处于安全状态”。
1.2 ISO 26262 标准发展历程
ISO 26262 这个标准，全称叫“Road vehicles — Functional safety”。它脱胎于工业领域的 IEC 61508，但专门针对汽车行业做了定制。
我记得2011年第一版发布时，很多工程师是懵的。那会儿大家连“ASIL”是什么都搞不清楚。到了2018年第二版，标准成熟了很多，加入了半导体、自动驾驶等新内容。现在第三版也在路上了。
简单梳理一下时间线：
| 版本 | 发布年份 | 主要变化 |
|---|---|---|
| 第一版 (ISO 26262:2011) | 2011 | 覆盖乘用车，10个部分，基础框架建立 |
| 第二版 (ISO 26262:2018) | 2018 | 扩展至卡车、巴士、摩托车；新增半导体指南；引入“安全异常”概念 |
| 第三版 (预计) | 2025+ | 聚焦自动驾驶、AI、网络安全与功能安全的融合 |
我的建议：如果你现在开始做项目，直接按2018版来。但要注意，很多主机厂已经在用第三版的草案做预研了。
1.3 ASIL 等级定义 —— 风险到底有多高？
ASIL，全称 Automotive Safety Integrity Level，汽车安全完整性等级。它不是一个技术指标，而是一个风险等级。
怎么定级？标准给了三个参数：
- Severity (S) —— 伤害的严重程度。S0（无伤害）到 S3（致命）
- Exposure (E) —— 暴露于危险场景的概率。E0（几乎不可能）到 E4（非常高）
- Controllability (C) —— 驾驶员或其他人能否控制住局面。C0（完全可控）到 C3（几乎不可控）
然后查表，得出 ASIL 等级：
| 严重度 (S) | 暴露率 (E) | 可控性 (C) | ASIL 等级 |
|---|---|---|---|
| S3 | E4 | C3 | ASIL D |
| S3 | E3 | C2 | ASIL B |
| S1 | E2 | C1 | ASIL A |
| 任何组合不满足 ASIL A/B/C/D | QM (质量管理) | ||
举个例子。电动助力转向系统如果失效，车辆可能突然失去转向能力。S 是 S3（高速下致命），E 是 E4（每次开车都可能遇到），C 是 C3（驾驶员几乎无法控制）。所以转向系统通常是 ASIL D。
避坑指南：我曾经见过一个团队，把“驾驶员可以踩刹车”作为可控性高的理由，把C定成了C1。这是典型的错误。可控性评估的是“在危险发生瞬间，普通人能否避免伤害”，而不是“理论上能不能”。
1.4 ASIL 分解 —— 把大目标拆成小目标
ASIL D 的要求非常高。硬件失效率要低于 10 FIT（1 FIT = 10⁻⁹ 失效/小时），软件要满足非常严格的开发流程。很多团队发现，直接做 ASIL D 太痛苦了。
这时候，标准给了你一条路：ASIL 分解。
什么意思？就是把一个 ASIL D 的安全目标，拆成两个独立的安全要求。比如：
- 要求 A：ASIL C
- 要求 B：ASIL A
只要这两个要求是相互独立的，并且同时满足，那么整体就达到了 ASIL D 的效果。
分解规则是这样的：
| 原始 ASIL | 分解方案 1 | 分解方案 2 | 分解方案 3 |
|---|---|---|---|
| ASIL D | ASIL C(D) + ASIL A(D) | ASIL B(D) + ASIL B(D) | ASIL D(D) + QM(D) |
| ASIL C | ASIL B(C) + ASIL A(C) | ASIL C(C) + QM(C) | — |
| ASIL B | ASIL A(B) + ASIL A(B) | ASIL B(B) + QM(B) | — |
| ASIL A | ASIL A(A) + QM(A) | — | — |
注意括号里的字母，表示这个分解后的要求源自哪个原始等级。比如 ASIL C(D) 表示这个要求是从 ASIL D 分解出来的，它本身要满足 ASIL C 的开发流程。
关键点：分解不是“降级”。你不能说“反正我分解了，ASIL D 就变成 ASIL C 了”。分解的前提是独立性——两个部分不能有共因失效。否则，分解无效。
1.5 知识体系总览
下面这张图，把本章的核心逻辑串起来了。从“为什么要做功能安全”，到“标准怎么发展”，再到“ASIL 怎么定、怎么拆”。
1.6 本章小结
这一章我们聊了三件事：
- 功能安全背景 —— 为什么汽车电子必须考虑失效场景
- 标准发展历程 —— ISO 26262 从 2011 到 2018 再到未来的演进
- ASIL 等级定义与分解 —— 如何通过 S/E/C 定级，以及如何通过分解降低开发难度
我个人觉得，理解 ASIL 分解是入门功能安全的第一道坎。很多新手会问：“我分解了，是不是就可以少做点测试？” 不是的。分解改变的是开发流程的严格度，而不是安全目标的完整性。该做的验证测试，一个都不能少。
一个小技巧：当你拿到一个安全目标，先别急着分解。先问自己：“这个功能如果失效，最坏情况是什么？” 如果答案是“人员伤亡”，那它至少是 ASIL B 起步。别在 QM 上浪费时间。