3. ISO 26262 功能安全基础：从概念到落地
功能安全，说白了就是「万一出错了，系统也不能伤到人」。ISO 26262 这个标准，就是给车规级电子系统定的一套安全开发流程。我最早接触它的时候，觉得这东西就是个文档游戏，后来真出了事才明白——每一条要求背后，都是血的教训。
这一章我们只聊四个核心概念：功能安全概念、ASIL 等级分解、安全目标、安全状态与 FTTI。搞懂了这些，你才算真正入了功能安全的门。
3.1 功能安全概念：你到底在防什么？
功能安全概念（Functional Safety Concept, FSC）回答一个问题：系统怎么才能安全地执行它的功能？
它不是让你把功能做得多花哨，而是让你想清楚——如果某个功能失效了，后果是什么，怎么兜底。
核心思路： 先定义「危险事件」→ 再定义「安全目标」→ 最后分解成「功能安全要求」。
举个例子。电动助力转向系统，如果助力突然消失，驾驶员还能不能把住方向盘？如果助力突然反向，那后果就严重了。功能安全概念要做的，就是针对这些失效模式，设计出对应的检测和响应机制。
我个人习惯，在项目启动阶段先拉一张表，把每个功能的失效模式、影响、可控性列清楚。这张表就是后面所有安全工作的起点。
3.2 ASIL 等级分解：A/B/C/D 到底怎么分？
ASIL（Automotive Safety Integrity Level）是 ISO 26262 里最出名的东西。它把安全等级分成 A、B、C、D 四级，D 是最严格的。
怎么定级？看三个维度：
- 严重度（Severity, S）：人员受伤的严重程度，S1~S3
- 暴露率（Exposure, E）：危险事件发生的概率，E1~E4
- 可控性（Controllability, C）：驾驶员能否避免危险，C1~C3
三个维度组合，查表得到 ASIL 等级。我见过不少新手直接拍脑袋定 ASIL，结果后面评审被打回来重做。嗯，这里要注意——ASIL 定级必须有依据，不能靠感觉。
| 严重度 (S) | 暴露率 (E) | 可控性 (C) | ASIL 等级 |
|---|---|---|---|
| S3 | E4 | C3 | ASIL D |
| S2 | E4 | C2 | ASIL B |
| S1 | E3 | C1 | ASIL A |
| S0 | — | — | QM（质量管理） |
你想想看，ASIL D 意味着什么？意味着系统失效一次，就可能造成多人死亡。所以 ASIL D 的系统，从硬件到软件，每个环节都要有冗余、有诊断、有证明。
3.2.1 ASIL 分解：把大石头敲碎
有时候一个功能要求 ASIL D，但单个组件根本做不到。这时候可以用 ASIL 分解。
举个例子。一个 ASIL D 的安全目标，可以分解成两个独立的 ASIL C 要求，分别分配给两个不同的组件。只要这两个组件是「相互独立」的，组合起来就能达到 ASIL D 的效果。
我的经验： 分解时一定要确认「独立性」。我曾经在一个项目里，两个组件用了同一个电源芯片，结果一个失效把另一个也拖下水了。独立性不是嘴上说说，要从供电、时钟、通信路径上逐一排查。
ASIL 分解的规则很简单：
- ASIL D → ASIL C(D) + ASIL C(D)
- ASIL D → ASIL B(D) + ASIL B(D) + ASIL B(D)
- ASIL C → ASIL B(C) + ASIL B(C)
- ASIL B → ASIL A(B) + ASIL A(B)
括号里的字母表示「这个分解出来的要求，最终要达到的原始等级」。说白了，就是每个子要求都要按原始等级来开发，但整体安全论证可以靠冗余来满足。
3.3 安全目标：系统的底线
安全目标（Safety Goal） 是功能安全的核心。它描述的是：系统在发生某种失效时，必须达到的最高层级安全状态。
安全目标的写法有固定格式：
「当 [危险事件] 发生时，系统必须 [安全行为]，以避免 [伤害类型]。」举个例子：
安全目标 SG-01：
当制动助力失效时，系统必须在 200ms 内切换到机械备份模式，
以避免车辆制动距离超出安全范围。每个安全目标都要有：
- ASIL 等级：从危害分析中得出
- FTTI：容错时间间隔
- 安全状态：系统最终要进入什么状态
- 容错机制：怎么检测、怎么响应
注意： 安全目标不是功能需求。功能需求说「系统要做什么」，安全目标说「系统不能出什么事」。两者有本质区别，评审时经常有人搞混。
3.4 安全状态与 FTTI：时间就是生命
安全状态（Safe State）是系统在检测到故障后，要进入的一个「不会造成伤害」的状态。比如：
- 切断动力输出
- 进入跛行模式（Limp Home）
- 切换到冗余通道
而 FTTI（Fault Tolerant Time Interval），就是「从故障发生到系统进入安全状态」的最大允许时间。
FTTI 怎么定？我一般这么算：
- 先分析危险事件从发生到造成伤害需要多长时间
- 减去驾驶员反应时间（如果有）
- 剩下的时间就是 FTTI
举个例子。如果制动助力失效后，驾驶员需要 500ms 才能意识到并踩下刹车，而危险会在 800ms 后发生，那 FTTI 就是 300ms。系统必须在这 300ms 内完成检测、决策、执行，进入安全状态。
关键点： FTTI 不是随便拍的数字。它必须基于物理分析和仿真验证。我见过一个项目，FTTI 写了 100ms，结果实际测试发现诊断算法就要跑 120ms——这就是典型的「纸上安全」。
3.4.1 安全状态转换流程
下面这张图展示了从故障发生到进入安全状态的完整流程：
3.5 避坑指南：我踩过的几个坑
做了这么多年功能安全，有些坑我是一路踩过来的。分享几个给你：
- ASIL 分解后忘了验证独立性——我曾经在一个项目里，两个 ASIL C 的组件共用了一个中断控制器，结果评审时被安全工程师当场指出。改设计花了三周。
- FTTI 只算理想情况——芯片温度高了，诊断时间会变长。我建议你在最恶劣工况下测 FTTI，而不是在实验室 25°C 下测。
- 安全目标写得太模糊——「系统应确保安全」这种话，评审时会被直接打回。安全目标必须可验证、可测试、可量化。
- 忽略了安全状态的退出条件——进入安全状态容易，但什么时候退出？怎么退出？退出后会不会再次触发故障？这些都要提前定义好。
一个小技巧： 我习惯在安全目标后面直接附上「验证方法」和「验收标准」。这样开发团队拿到安全目标就知道怎么测，不用来回沟通。比如：「SG-01 验证方法：注入制动助力失效故障，测量系统进入机械备份模式的时间，要求 ≤ 200ms。」
3.6 本章小结
功能安全不是写文档，是设计思维。ASIL 等级告诉你「要多严格」，安全目标告诉你「要防什么」，FTTI 和安全状态告诉你「要多快」。这三者串起来，就是一条完整的安全链。