3. 安全目标(Safety Goal)定义：安全目标撰写规范、安全状态定义、安全机制关联、安全目标示例
好，我们进入第三讲。前面两讲我们聊了危害分析和风险评估，也就是 HARA。做完 HARA，你手里会有一堆危害事件，每个都带着 ASIL 等级。那下一步干什么？
就是把最严重的那些危害，转化成安全目标。说白了，安全目标就是一句顶级的、系统级的安全要求。它告诉整个开发团队：这辆车/这个系统，绝对不允许出现什么情况。
核心定义：安全目标（Safety Goal）是源自危害事件的、最高层级的安全要求。它必须满足：
- 每个危害事件至少对应一个安全目标
- 安全目标的 ASIL 等级继承自对应的危害事件
- 安全目标必须包含安全状态和故障容错时间间隔
3.1 安全目标撰写规范
我见过很多新手写的安全目标，读起来像散文。什么“系统应确保车辆安全”、“避免发生事故”。这种话说了等于没说。安全目标必须可验证、可测试、无歧义。
我个人习惯用这个模板来写：
SG-xxx：[系统/功能] 应避免 [具体危害]，在 [触发条件] 下，
通过 [安全机制] 进入 [安全状态]，并在 [FTTI] 内完成。拆开来看，每个要素都不能少：
| 要素 | 说明 | 反面案例 | 正面案例 |
|---|---|---|---|
| 系统/功能 | 明确是哪个系统 | 系统应避免非预期加速 | ACC 系统应避免非预期加速 |
| 具体危害 | 描述车辆级危害 | 避免发生碰撞 | 避免因非预期加速导致车辆与前方障碍物碰撞 |
| 触发条件 | 什么场景下 | （缺失） | 在 ACC 激活且目标车辆减速时 |
| 安全机制 | 靠什么来保证 | 系统应自动处理 | 通过监控油门踏板传感器和轮速信号一致性 |
| 安全状态 | 出问题后变成什么 | 系统应退出 | ACC 退回到待机模式，请求驾驶员接管 |
| FTTI | 多长时间内完成 | （缺失） | 在 100ms 内 |
我的经验：写安全目标时，试着让一个没参与过项目的测试工程师读一遍。如果他看完能直接写测试用例，那这个目标就写到位了。如果他问“这个‘安全’是什么意思？”，那就得重写。
3.2 安全状态定义
安全状态，是安全目标里最容易被忽略的部分。很多人觉得“出问题了就停机呗”。但现实没这么简单。
我曾经在一个 EPS（电动助力转向）项目里，安全目标写的是“系统应进入安全状态”。结果测试的时候，ECU 检测到故障直接切断电机供电。方向盘瞬间变重，驾驶员在高速上差点出事。你看，这个“安全状态”本身就不安全。
定义安全状态，要回答三个问题：
- 系统做什么？——是降级、退出、还是维持当前输出？
- 驾驶员感知到什么？——有没有报警灯？有没有声音提示？
- 系统什么时候恢复？——是锁死直到维修，还是下次上电自动恢复？
常见的几种安全状态：
| 安全状态类型 | 适用场景 | 示例 |
|---|---|---|
| 降级模式 | 功能部分可用 | ACC 退回到普通巡航，不自动跟车 |
| 退出模式 | 功能完全关闭 | EPS 切断助力，但保留机械转向 |
| 维持模式 | 保持最后有效输出 | 线控制动保持当前制动力 |
| 紧急操作 | 主动执行安全动作 | 触发自动紧急制动 |
注意：安全状态不是一成不变的。同一个系统，不同故障可能对应不同的安全状态。比如传感器故障可以降级，但执行器故障可能必须退出。一定要在安全目标里写清楚。
3.3 安全机制关联
安全目标定好了，安全状态也定义了。那怎么保证系统真的能进入安全状态？靠安全机制。
安全机制是具体的技术手段。它可以是硬件冗余、软件自检、看门狗、CRC 校验、多核锁步……等等。每个安全目标，背后都要有一组安全机制来支撑。
我习惯用一张表来建立关联：
| 安全目标 ID | 安全机制 | 检测对象 | 响应动作 | ASIL |
|---|---|---|---|---|
| SG-01 | 传感器信号合理性检查 | 油门踏板位置传感器 | 请求降级模式 | ASIL C |
| SG-01 | 看门狗监控主芯片运行 | 主控 MCU | 触发系统复位 | ASIL C |
| SG-02 | 制动踏板信号二选一 | 制动开关 | 维持当前制动 | ASIL D |
你看，同一个安全目标可能需要多个安全机制来覆盖。而且每个安全机制本身也有 ASIL 等级要求。这个等级通常和安全目标一致，但有时候可以降级——前提是你有充分的独立性论证。
避坑指南：我曾经在一个项目里，安全机制写得天花乱坠，但没考虑这些机制本身会不会失效。比如看门狗如果和主芯片共用同一个电源，那电源失效时看门狗也挂了。这就是所谓的“共因失效”。做安全机制关联时，一定要做独立性分析。
3.4 安全目标示例
光说理论太干。我拿一个实际项目里的例子给你看看。
假设我们做一个电动尾门（Power Liftgate）系统。HARA 做出来有一个危害事件：尾门在关闭过程中，如果防夹功能失效，可能夹伤人员。ASIL 评出来是 B。
对应的安全目标可以这样写：
SG-001：电动尾门系统应避免在关闭过程中因防夹功能失效
导致夹伤人员。
- ASIL：B
- 安全状态：尾门停止运动并反向打开至全开位置
- FTTI：200ms
- 安全机制：
1. 霍尔传感器信号周期监控（检测堵转）
2. 电流阈值监控（检测过流）
3. 主控芯片自检（检测逻辑错误）再写一个：
SG-002：电动尾门系统应避免在开启过程中因意外解锁
导致尾门掉落伤人。
- ASIL：B
- 安全状态：尾门锁止机构保持锁止，电机断电
- FTTI：100ms
- 安全机制：
1. 门锁位置传感器双重采样
2. 电机驱动电路独立监控你看，每个安全目标都清清楚楚。测试团队拿到这个，直接就能写测试用例：
- 用例1：模拟防夹传感器失效，尾门关闭中遇到障碍物，验证 200ms 内反向打开
- 用例2：模拟门锁传感器故障，验证尾门电机断电且锁止机构保持
这才叫落地。
3.5 知识结构图
下面这张图，把安全目标定义的核心逻辑串起来了。你可以把它当作本章的思维导图：
3.6 本章小结
嗯，这一讲内容不少。我帮你捋一下重点：
- 安全目标是 HARA 到技术实现的桥梁，必须写得像法律条文一样精确
- 安全状态不是简单的“停机”，要结合系统特性和使用场景来定义
- 安全机制要和目标一一关联，并且要考虑机制本身的独立性
- 写完之后，拿给测试同事看一眼——他能看懂，才算合格