1. 课程导入
1.1 为什么我们需要功能安全？
先聊点实际的。你想想看，一辆车上现在有多少个ECU？从几十个到上百个不等。这些电子系统控制着刹车、转向、油门，甚至自动驾驶。如果某个系统在关键时刻“抽风”了，会发生什么？
我入行那会儿，功能安全在国内还是个新鲜词。很多工程师觉得“软件不出bug就行了”。但现实是——电子系统失效带来的风险，远比我们想象的大。
核心观点：功能安全不是“不出故障”，而是“故障发生时，系统仍然安全”。
举个例子：刹车系统的电子控制器如果失效，不能导致刹车完全失灵。系统必须能检测到自身故障，并进入安全状态（比如启用机械备份）。这就是功能安全要解决的问题。
说白了，功能安全就是一套方法论——识别风险、控制风险、证明风险已被控制。
1.2 ISO26262标准体系结构
ISO26262脱胎于工业领域的IEC61508，专门针对汽车电子电气系统。标准分12个部分，我习惯把它们分成三大块：
| 类别 | 部分编号 | 内容 |
|---|---|---|
| 基础与概念 | Part 1 ~ Part 3 | 术语、功能安全管理、概念阶段 |
| 产品开发 | Part 4 ~ Part 6 | 系统级、硬件级、软件级开发 |
| 支持与生产 | Part 7 ~ Part 12 | 生产运行、支持流程、ASIL分解、半导体指南 |
标准的核心逻辑是V模型。左边是需求定义和设计，右边是验证和确认。我在项目中见过不少团队只关注“开发”，忽略了“验证”，结果评审时被问得哑口无言。
我的建议：刚开始学ISO26262，别急着啃全部12个部分。先把Part 3（概念阶段）、Part 4（系统级）、Part 6（软件级）吃透，这些是日常工作中最常用的。
下面这张图展示了ISO26262标准各部分之间的关系：
1.3 ASIL等级定义与分解
ASIL（Automotive Safety Integrity Level）是ISO26262里最核心的概念之一。它定义了系统需要达到的安全等级。
ASIL有四个等级：A、B、C、D。D是最严格的，A是最宽松的。还有一个QM（Quality Management），表示不需要功能安全措施，做好质量管理就行。
| ASIL等级 | 严重度（S） | 暴露概率（E） | 可控性（C） | 典型应用 |
|---|---|---|---|---|
| QM | S0 | E0-E1 | C0-C1 | 车窗升降、座椅调节 |
| ASIL A | S1 | E2 | C2 | 尾灯控制 |
| ASIL B | S2 | E3 | C2 | 制动灯、雨刮器 |
| ASIL C | S2 | E3 | C3 | 自适应巡航（ACC） |
| ASIL D | S3 | E4 | C3 | 制动系统、转向系统、安全气囊 |
ASIL等级由三个参数决定：
- S（Severity）：伤害的严重程度（S0~S3）
- E（Exposure）：暴露在危险场景中的概率（E0~E4）
- C（Controllability）：驾驶员或其他人员控制风险的能力（C0~C3）
计算公式：ASIL等级 = f(S, E, C)。三个参数组合查表得到最终等级。
举个例子：刹车系统失效，可能导致严重伤害（S3），几乎每次开车都会用到（E4），驾驶员很难控制（C3）。查表得到ASIL D。
1.4 ASIL分解——降低开发成本的利器
ASIL D的开发成本很高。你想想看，所有流程、工具、测试都要达到最高等级。有没有办法降低要求？
有！ASIL分解。
标准允许将一个ASIL D的需求，分解成两个独立的需求，比如ASIL C(D) + ASIL A(D)。括号里的D表示原始等级。两个独立部分各自满足较低等级，组合起来仍然满足ASIL D。
我的经验：我在一个ADAS项目中，把ASIL D的制动请求分解成ASIL B(D) + ASIL B(D)。两个独立的MCU各自处理一半逻辑，互相校验。评审时专家认可了这种方案，开发成本降低了约30%。
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分解不是“偷懒”。分解后的两个部分必须相互独立，不能有共因失效。我曾经见过一个团队把ASIL D分解成两个ASIL B，但两个部分跑在同一个MCU上——这明显不满足独立性要求，评审直接被驳回。
下面这张图展示了ASIL分解的典型架构：
1.5 避坑指南
我曾经踩过的坑：
- ASIL分解后忘记标注原始等级——评审时专家问“你这个ASIL B是从哪来的？”答不上来。正确做法：在需求文档里写清楚“ASIL B(D)”，括号里的D表示原始等级。
- 把ASIL分解当成“降级”——分解不是降低安全目标，而是通过架构设计让每个部分更容易实现。安全目标不变。
- 忽略共因失效分析——两个通道如果共用同一个电源、同一个时钟、同一个编译器，那分解就失去了意义。
1.6 本章小结
这一章我们聊了：
- 功能安全为什么重要——不是不出错，而是出错后仍然安全
- ISO26262标准体系——12个部分，V模型开发流程
- ASIL等级——由S、E、C三个参数决定，D最严格
- ASIL分解——通过独立冗余降低开发成本，但必须保证独立性
嗯，这些是功能安全的基础。后面的章节我们会深入每个阶段的具体做法。记住一句话：功能安全不是文档游戏，而是工程实践。