第3章：安全目标定义——SG制定、安全状态与安全机制分配
大家好，我是你们的老朋友。今天我们来聊聊功能安全开发中最核心的一步——安全目标定义。
说实话，很多工程师觉得HARA做完就万事大吉了。其实不然。HARA只是告诉你「哪里有风险」，而安全目标才是真正开始「怎么防风险」。我见过不少项目，HARA报告写得漂漂亮亮，一到安全目标就含糊其辞，最后评审被怼得哑口无言。
好，我们直接进入正题。
3.1 安全目标（SG）的制定
安全目标，说白了就是一句话：「为了防止某个危害事件，系统必须做到什么」。
它来源于HARA中每个危害事件的最高ASIL等级。注意，不是每个危害事件都要单独写一个SG，而是把同类危害合并。我个人的习惯是：一个危害事件对应一个SG，但如果多个危害事件有相同的安全要求，可以合并。
举个例子，在高压电池系统中：
- 危害事件：电池过充导致热失控
- 安全目标：防止电池单体电压超过4.25V（ASIL C）
- 危害事件：电池过放导致内部短路
- 安全目标：防止电池单体电压低于2.5V（ASIL B）
你看，这两个SG就不能合并，因为过充和过放的危害等级不同，安全机制也不同。
SG制定的核心原则：
- 每个SG必须对应一个或多个危害事件
- SG的ASIL等级取所有关联危害事件的最高等级
- SG必须可验证、可测试
- SG不能包含具体实现方案（那是后面的事）
嗯，这里有个坑。我曾经遇到一个项目，工程师把SG写成「BMS应具备过充保护功能」。这其实是安全机制，不是安全目标。安全目标应该是「防止电池过充」，至于用什么方法实现，那是安全机制的事。你想想看，如果写成「BMS应具备过充保护功能」，那万一BMS失效了，是不是就没办法了？但如果你写「防止电池过充」，你还可以用硬件熔断器、继电器断开等其他手段。
3.2 安全状态定义
安全目标定好了，接下来要回答一个问题：「当系统出故障时，它应该变成什么样子才算安全？」 这就是安全状态。
安全状态是系统在检测到故障后，主动进入的一种不会导致危害的状态。对于高压系统来说，常见的安全状态有：
| 安全状态 | 描述 | 适用场景 |
|---|---|---|
| 高压断开 | 主正/主负继电器断开，高压回路切断 | 过流、绝缘故障、碰撞 |
| 降功率运行 | 限制充放电功率，比如降到10kW以下 | 温度过高、SOC异常 |
| 紧急放电 | 通过泄放电阻快速消耗高压能量 | 碰撞后、维修模式 |
| 维持当前状态 | 不改变当前操作，但禁止新操作 | 某些通信故障 |
我个人习惯，每个SG至少要定义1个安全状态，最好定义2个——一个主安全状态，一个降级安全状态。为什么？因为有时候直接进入主安全状态可能带来新的风险。比如在高速行驶时突然断开高压，可能导致车辆失控。这时候降级安全状态就派上用场了。
避坑指南：我曾经在一个项目中，安全状态只定义了「高压断开」。结果在高速工况下触发故障，继电器直接断开，车辆瞬间失去动力，差点出事故。后来我们增加了「降功率运行」作为过渡安全状态，先限功率再断开，问题就解决了。
定义安全状态时，还要明确：
- 进入条件：什么故障触发这个状态？
- 退出条件：什么情况下可以退出？需要人工复位吗？
- 容错时间：从故障发生到进入安全状态，允许的最长时间是多少？
3.3 安全机制初步分配
安全目标和安全状态都有了，接下来就是「怎么实现」的问题。安全机制就是用来检测故障、防止违反安全目标、或者引导系统进入安全状态的具体手段。
注意，这里说的是「初步分配」。什么意思？就是在系统设计早期，我们先大致想一下用哪些安全机制，不要求细化到具体电路或代码。后面在系统设计和详细设计阶段还会不断迭代。
安全机制通常分为三类：
- 检测机制：发现故障。比如电压传感器冗余、看门狗、CRC校验。
- 响应机制：故障后的动作。比如继电器断开、报警、降功率。
- 避免机制：从设计上避免故障发生。比如物理隔离、冗余设计。
拿高压电池过充这个SG来举例：
| 安全机制 | 类型 | 说明 |
|---|---|---|
| 电压传感器冗余（2路独立采样） | 检测 | 防止单点故障导致电压误判 |
| 充电电流限制 | 避免 | 硬件限流，防止过充 |
| 过充保护阈值（硬件比较器） | 检测+响应 | 超过阈值直接触发继电器断开 |
| 充电继电器断开 | 响应 | 进入安全状态 |
这里有个关键点：安全机制的ASIL等级必须不低于它要覆盖的SG的ASIL等级。如果SG是ASIL C，你用一个ASIL A的传感器去检测，那是不行的。为什么？因为ASIL A的传感器本身可能失效，导致检测不到故障。
注意：安全机制本身也会失效！所以安全机制也需要被监控。比如你用了电压传感器冗余，那这两个传感器之间的比较逻辑本身也要有诊断覆盖。这就是所谓的「安全机制的安全机制」，有时候会嵌套好几层。我在做项目时，一般会画一个安全机制依赖图，把每层关系理清楚。
初步分配安全机制时，我建议用表格形式记录下来，包含：
- 安全机制名称
- 关联的SG编号
- 安全机制类型（检测/响应/避免）
- 分配的ASIL等级
- 初步实现方案（一句话描述）
- 备注（比如是否有依赖关系）
这个表格在后面做FMEA和FTA时会反复用到，所以一开始就整理好，能省很多事。
小结
好，我们来捋一下今天的重点：
- 安全目标：从HARA来，描述「防止什么危害」，ASIL取最高级
- 安全状态：故障后系统变成什么样才算安全，要定义进入/退出条件和容错时间
- 安全机制初步分配：先大致想好用什么手段来检测和响应故障，后面再细化
这三个东西是功能安全开发的「铁三角」。SG定不好，后面全白干；安全状态定义不清，测试没法做；安全机制分配不合理，成本翻倍还过不了评审。我见过太多项目在这上面栽跟头，所以希望大家能重视起来。
下一章我们聊聊功能安全概念阶段的具体输出物——功能安全概念（FSC）。到时候会讲怎么把今天的安全机制细化成具体的技术要求。咱们下期见。