第4章：安全目标定义：从HARA到安全目标、ASIL分解策略、安全状态定义
好，我们接着往下走。上一章我们聊了HARA怎么做，怎么识别出危险事件，怎么定ASIL等级。那拿到这些输出之后，下一步是什么？
说白了，HARA不是终点，它只是起点。HARA告诉你「哪些场景会出问题」，但没告诉你「怎么才算安全」。这个鸿沟，就需要靠安全目标来填。
4.1 从HARA到安全目标：这一步怎么跳？
我个人习惯，拿到HARA表格后，先做一件事：把每个危险事件，翻译成一条「系统级的安全要求」。这个要求，就是安全目标。
举个例子。HARA里有一条：
- 危险事件：车辆行驶中，安全气囊误点爆
- ASIL：ASIL D
那对应的安全目标怎么写？
安全目标示例：
「安全气囊系统应避免在非碰撞工况下产生点爆指令，ASIL D。」
你看，这里有几个关键要素：
- 明确的功能行为：避免误点爆
- 明确的触发条件：非碰撞工况
- 明确的ASIL等级：ASIL D
我在项目中遇到过，有些工程师写安全目标写成了「系统应可靠工作」。这种话说了等于没说。安全目标一定要可验证、可测试。你想想看，如果测试工程师拿到这条目标，他该怎么测？「可靠工作」怎么测？没法测。
我的小技巧：
写安全目标时，试着问自己三个问题：
- 这条目标能不能被测试？
- 测试通过的标准是什么？
- 如果失效，后果是什么？
三个问题都能回答，这条目标才算合格。
4.2 ASIL分解策略：怎么把D拆成Q、M、D？
好，安全目标有了，ASIL等级也定了。但问题来了——ASIL D的要求非常高，开发成本也高。有没有办法降低某个子系统的ASIL等级？
有。这就是ASIL分解。
ISO 26262允许你把一个ASIL D的安全目标，分解成两个独立的安全要求，每个要求承担一部分责任。比如：
| 分解前 | 分解后 | 说明 |
|---|---|---|
| ASIL D | ASIL D(D) + ASIL QM(D) | 一个承担D，一个承担QM，但组合起来仍满足D |
| ASIL D | ASIL C(D) + ASIL A(D) | 一个承担C，一个承担A，组合满足D |
| ASIL D | ASIL B(D) + ASIL B(D) | 两个都承担B，组合满足D |
嗯，这里要注意：分解不是随便拆的。它有一个核心原则——独立性。两个分解后的要求，必须由相互独立的要素来实现。如果它们共用同一个软件模块、同一个传感器、同一个电源，那独立性就不成立，分解也就无效。
我曾经踩过的坑：
有一次，我们把一个ASIL D的安全目标分解成ASIL B(D) + ASIL B(D)。一个用主MCU实现，一个用监控MCU实现。看起来独立对吧？结果审查时发现，两个MCU共用同一个电源芯片。一旦电源失效，两个MCU同时失效。独立性不成立，分解被驳回。
从那以后，我每次做分解都会画一张独立性矩阵，把共享的资源全部列出来，一个一个检查。
4.3 安全状态定义：系统出问题了，往哪退？
安全目标定义了「什么不能发生」，安全状态定义了「如果发生了，系统该怎么办」。
说白了，安全状态就是系统的最后一道防线。当故障被检测到，系统必须进入一个安全的状态，避免危险事件发生。
对于安全气囊系统，常见的安全状态有哪些？
- 禁用点爆回路：切断点火驱动芯片的供电，确保任何误触发都不会导致点爆
- 进入故障安全模式：系统降级运行，只保留基本诊断功能
- 完全关闭系统：彻底断电，等待维修
我个人习惯，每个安全目标都要对应至少一个安全状态。而且这个安全状态要可量化。比如：
安全状态定义示例：
「当检测到主MCU故障时，系统应在10ms内切断点火驱动芯片的供电，并进入故障安全模式。在故障安全模式下，系统不再响应任何点爆指令，但持续输出故障指示灯信号。」
你看，这里明确了：
- 触发条件：主MCU故障
- 响应时间：10ms内
- 具体动作：切断供电、进入故障安全模式
- 持续行为：输出故障指示灯信号
为什么响应时间这么重要？我举个例子。安全气囊的点爆回路，如果故障发生后不能及时切断，一个意外的电磁干扰就可能触发点爆。10ms这个时间，是我在项目中经过多次测试验证出来的——既保证足够快，又不会因为噪声导致误动作。
避坑指南：
定义安全状态时，别忘了考虑退出条件。系统进入安全状态后，什么时候能退出？是上电重启？还是需要维修人员手动复位？
我曾经见过一个项目，安全状态定义得很好，但没定义退出条件。结果系统进入安全状态后，一直卡在那里，客户投诉说「车坏了，修不好」。后来我们加了一条：安全状态只能通过钥匙电循环退出，且退出后必须重新执行完整的自检流程。
4.4 安全目标、ASIL分解、安全状态：三位一体
好，我们把这三块串起来，看看一个完整的例子：
| 要素 | 内容 |
|---|---|
| 危险事件 | 车辆行驶中，安全气囊误点爆 |
| 安全目标 | 避免在非碰撞工况下产生点爆指令，ASIL D |
| ASIL分解 | 主MCU：ASIL B(D)，监控MCU：ASIL B(D)，独立供电 |
| 安全状态 | 故障时10ms内切断点火驱动供电，进入故障安全模式 |
| 退出条件 | 钥匙电循环后，自检通过方可退出 |
你看，从HARA到安全目标，再到ASIL分解和安全状态，这是一条完整的链路。每一步都有明确的输入和输出，每一步都经得起推敲。
我记得有一次评审，客户问：「你们的安全状态为什么选这个？」我直接把HARA表格、安全目标、分解策略、测试报告摆出来，一条一条解释。客户听完只说了一句：「嗯，逻辑闭环。」
这就是我们要的效果。
好，这一章就到这里。下一章我们聊聊功能安全概念——怎么把安全目标落地到具体的系统架构和功能分配上。到时候我会分享一个我实际做过的案例，保证干货满满。