4. 安全目标与安全状态：从危害事件到可落地的安全要求
好，我们进入第四章。前面我们做了 HARA，拿到了危害事件和 ASIL 等级。但那些还是「风险描述」，不是「工程要求」。这一章我们要干的事，说白了就是：把危害事件翻译成安全目标，再把安全目标拆成能干活的技术指标。
我个人习惯把这一步叫做「从定性到定量的惊险一跃」。跳好了，后面开发顺风顺水；跳不好，评审的时候会被问得哑口无言。
4.1 从危害事件到安全目标
每个危害事件，至少对应一个安全目标。安全目标的句式很固定：「系统应避免 XXX 危害事件发生」，或者更精确地说——「系统应防止 XXX 危险事件」。你想想看，这其实就是在说：我们要给系统上个保险，不让那个坏场景出现。
安全目标的标准模板：
[系统/功能] 应避免 [危害事件描述]，在 [运行场景] 下，达到 [ASIL 等级]。
举个例子。我之前做过一个线控制动项目，HARA 里有一条危害事件：「高速行驶中制动主控失效，导致车辆无法减速」，ASIL D。对应的安全目标就是：
SG-01: 制动系统应避免因主控失效导致制动力完全丧失，
在高速行驶场景下，ASIL D。注意，一个危害事件可能衍生出多个安全目标。比如上面那个例子，如果失效模式是「单点失效」和「多点失效」分开，那就要分别写。我见过有些团队一个危害事件只写一个安全目标，结果漏掉了冗余路径的保护——嗯，评审时被安全专家追着问了三轮。
4.1.1 安全目标的属性
每个安全目标，除了描述和 ASIL，还要带上几个关键属性。我列个表，你照着填就行：
| 属性 | 说明 | 示例 |
|---|---|---|
| ID | 唯一编号，方便追溯 | SG-01 |
| 描述 | 清晰、无歧义的功能安全要求 | 制动系统应避免制动力完全丧失 |
| ASIL | 继承自危害事件的 ASIL | ASIL D |
| 关联危害事件 | 追溯回 HARA 的输出 | HZ-03 |
| 安全状态 | 达到安全时系统应处的状态 | 制动系统进入机械备份模式 |
| 容错时间间隔 | 从故障发生到进入安全状态的最大允许时间 | ≤ 500 ms |
一个小技巧： 安全目标的描述里不要出现「可能」「大概」「尽量」这类模糊词。评审的时候，这些词会被安全工程师一个一个揪出来。我曾经吃过这个亏，后来写目标时都逼着自己用「应」「必须」「不得」。
4.2 安全状态与容错时间间隔
安全目标写完了，但还不够。你得告诉开发团队：系统出问题后，要变成什么样子才算安全？ 以及 在多长时间内必须变成那个样子？
这就是安全状态和容错时间间隔（FTTI，Fault Tolerant Time Interval）。
4.2.1 安全状态
安全状态是系统在检测到故障后，主动进入的一个不会导致危害的状态。常见的几种：
- 降级模式： 部分功能关闭，但核心安全功能保留。比如制动系统从电子助力降级到机械备份。
- 关闭模式： 系统完全断电，但确保不会引发危险。比如碰撞后自动切断高压电池。
- 维持模式： 保持当前输出，不再响应新指令。比如转向系统保持最后角度。
- 替代模式： 切换到冗余通道。比如双 MCU 设计，主核挂了，从核接管。
我遇到过最头疼的情况是：安全状态本身可能引发新的危害。比如一个电动车，高压切断是安全状态，但如果切断发生在高速公路上，车辆突然失去动力反而更危险。所以定义安全状态时，一定要结合运行场景反复推敲。
避坑指南： 安全状态不是「拍脑袋」定的。每个安全状态都要做一次安全状态确认分析，证明这个状态本身不会导致新的不可接受的风险。我曾经见过一个项目，安全状态定义成「系统停机」，结果停机后车门锁死，乘员无法逃生——这就是典型的「安全状态不安全」。
4.2.2 容错时间间隔（FTTI）
FTTI 是从故障发生到系统进入安全状态的最大允许时间。这个时间怎么定？
说白了，就是问一个问题：从故障发生到危害发生，中间有多长的窗口期？
比如制动失效：如果故障发生 100ms 后车辆就开始失控，那你的 FTTI 必须小于 100ms。如果故障发生后 2 秒内还能安全减速，那 FTTI 可以放宽到 2 秒。
FTTI 的典型组成：
- 故障检测时间： 从故障发生到被诊断机制捕获。
- 故障响应时间： 从诊断出故障到执行安全动作。
- 安全执行时间： 从动作执行到系统真正进入安全状态。
这三段加起来，必须 ≤ FTTI。
一个实际案例： 我在做 EPS（电动助力转向）项目时，FTTI 定的是 400ms。其中故障检测用了 200ms（双核互检 + 软件自检），响应用了 100ms（中断处理 + 模式切换），执行用了 100ms（电机电流归零）。刚好卡线。后来硬件升级，检测时间缩短到 100ms，我们才松了口气。
4.3 安全目标分解与 ASIL 继承
安全目标定好了，但它是系统级的。接下来要把它分解到子系统、组件、甚至软件模块。这就是安全目标分解。
分解的核心原则：ASIL 可以降，但必须有理有据。
4.3.1 ASIL 分解规则
ISO 26262 允许通过冗余架构来降低单个元素的 ASIL 要求。规则很简单：
- ASIL D 可以分解为：ASIL D(D) + ASIL D(D) 或 ASIL C(D) + ASIL A(D) 或 ASIL B(D) + ASIL B(D)
- ASIL C 可以分解为：ASIL C(C) + ASIL C(C) 或 ASIL B(C) + ASIL A(C)
- ASIL B 可以分解为：ASIL B(B) + ASIL B(B) 或 ASIL A(B) + ASIL A(B)
- ASIL A 不能分解
括号里的 D/C/B/A 表示原始 ASIL，前面的数字是分解后的要求。注意：分解后的两个元素必须相互独立，不能有共因失效。
我的经验： 分解不是偷懒。你不能说「我把 ASIL D 分解成两个 ASIL B，然后每个 B 随便做做」。评审时安全专家会要求你提供独立性论证，证明两个通道不会同时因为同一个原因失效。我见过最狠的评审，直接要求做 FMEA 证明两个通道的供电、时钟、软件都不共享。
4.3.2 分解的典型架构
最常见的分解架构是 1oo2（1 out of 2）或 2oo2。我画个图帮你理解：
这个图展示的是 1oo2 架构：两个通道独立工作，只要有一个通道检测到故障，系统就进入安全状态。每个通道只需要满足 ASIL B，但加起来覆盖了 ASIL D 的安全目标。
4.3.3 分解的文档要求
分解不是画个图就完事了。你需要输出以下文档：
- 安全目标分解表： 列出每个子安全目标、来源、ASIL、分配到的组件。
- 独立性论证报告： 证明分解后的元素之间没有共因失效。
- 安全机制分配表： 每个子安全目标对应的安全机制（比如 E2E 保护、硬件冗余、软件自检）。
避坑指南： 我曾经见过一个团队，把 ASIL D 分解成两个 ASIL B 后，两个通道用了同一个供应商的同一款芯片。评审时被问到「如果芯片本身有系统性缺陷怎么办？」——答不上来。最后被迫重新设计，换了不同架构的芯片。所以独立性论证不是走形式，是真的要查供电、时钟、软件、甚至供应链。
4.4 本章小结
这一章我们走了三步：
- 从危害事件导出安全目标——用标准句式，带上 ASIL 和属性。
- 定义安全状态和 FTTI——安全状态要可执行，FTTI 要可测量。
- 安全目标分解与 ASIL 继承——分解可以降级，但必须独立。
嗯，到这里，你的安全要求已经从「可能发生什么坏事」变成了「系统应该怎么做」。下一步，这些要求就要交给系统架构师去设计具体方案了。但那是后面的事，先把这一章的内容消化掉。