第2章 ISO 26262标准精讲：标准架构、ASIL等级定义、功能安全生命周期
好，咱们直接进入正题。ISO 26262这个标准，说实话，刚接触的时候会觉得它又厚又绕。我当年第一次翻开它，心里就一个想法：这玩意儿怎么落地？
但干久了你会发现，它其实就三根柱子：标准架构长什么样、ASIL等级怎么定、生命周期怎么走。今天我就把这三点掰开揉碎了讲。
2.1 标准架构：别被10个Part吓到
ISO 26262总共分10个部分，从Part 1到Part 10。你想想看，一个标准能写10本，是不是有点夸张？
但说白了，核心就三个维度：
- 管理维度（Part 2）：项目计划、评审、跟踪。嗯，这部分最容易被忽略，但出问题也最多。
- 开发维度（Part 3~Part 7）：从概念设计到硬件、软件、再到生产。这是咱们工程师的主战场。
- 支持维度（Part 8~Part 10）：工具认证、配置管理、安全文化。我习惯叫它“后勤保障”。
我个人习惯：拿到一个新项目，先看Part 3（概念阶段）和Part 6（软件层面）。这两个地方最容易踩坑。
举个例子，Part 6里关于软件单元测试的要求，很多人以为就是跑个覆盖率。其实它要求的是基于需求的测试，而且每个测试用例都要追溯到安全目标。我在项目中遇到过，有人把单元测试做成了“为了测试而测试”，结果评审时被怼得哑口无言。
2.2 ASIL等级定义：你的系统有多“危险”？
ASIL，全称是Automotive Safety Integrity Level。翻译成人话就是：你的系统如果挂了，后果有多严重？
它分四个等级：ASIL A、B、C、D。D是最严的，A是最松的。还有一个QM（Quality Management），意思是“不需要按功能安全流程做，按质量管理就行”。
怎么定等级？看三个参数：
| 参数 | 含义 | 取值 |
|---|---|---|
| Severity (S) | 伤害的严重程度 | S0~S3 |
| Exposure (E) | 暴露在危险场景的概率 | E0~E4 |
| Controllability (C) | 驾驶员能否控制住 | C0~C3 |
然后查表：
ASIL = f(S, E, C)
例如：S2 + E3 + C2 → ASIL B
S3 + E4 + C3 → ASIL D避坑指南：我曾经见过一个团队，把E值定得很低，理由是“这个场景很少发生”。结果评审时被安全专家质疑：你凭什么说它很少发生？有没有统计数据？所以，E值的确定一定要有依据，不能拍脑袋。
另外，ASIL等级还会影响你的开发方法。比如ASIL D要求代码覆盖率必须达到100%的MC/DC（修正条件/判定覆盖），而ASIL A可能只要求语句覆盖。说白了，等级越高，你付出的工作量就越大。
2.3 功能安全生命周期：从摇篮到坟墓
功能安全生命周期，听起来很玄乎。其实就是从你开始想这个产品，到它报废，整个过程怎么管安全。
我把它分成三个阶段：
- 概念阶段：定义功能、识别危险、制定安全目标。这个阶段最怕“想当然”。
- 开发阶段：把安全目标分解到系统、硬件、软件。嗯，这里最容易出现“分解不到位”。
- 生产与运维阶段：生产控制、售后监控、报废处理。很多人以为开发完就结束了，其实后面还有一堆事。
举个例子，概念阶段要做HARA（危险分析与风险评估）。我刚开始做HARA时，总觉得把危险列出来就行了。后来发现，每个危险都要对应一个安全目标，而且安全目标要可验证。比如“刹车不能失效”这个目标，你怎么验证？你得写清楚：在什么条件下、多长时间内、失效概率是多少。
注意：生命周期不是一条直线走到底。它有很多迭代。比如你在软件测试时发现了一个新的危险，就得回头去更新HARA。我见过一个项目，因为没做迭代，最后安全目标漏了，导致重新走了一遍流程，浪费了三个月。
最后，我想说一句：ISO 26262不是束缚你的枷锁，而是帮你避坑的地图。你想想看，如果没有这个标准，每个公司都按自己的理解做安全，那车还敢开吗？
好，这一章就到这里。下一章咱们聊聊HARA的具体做法，我会拿一个真实案例来拆解。