4. 安全目标定义：从危害到目标的转化
好，咱们进入第四讲。前面我们做了HARA，识别了危害事件，也定了ASIL等级。接下来这一步，就是把那些危害分析的结果，转化成实实在在的安全目标（Safety Goal, SG）。
说白了，安全目标就是一句话：“系统必须避免某某危害发生”。它是功能安全开发的顶层要求，所有后续工作都得围着它转。
4.1 安全目标的制定原则
我个人习惯，写安全目标时遵循三个原则：
- 每个危害事件对应一个SG：一个危害事件至少有一个安全目标。但有时候一个SG可以覆盖多个类似危害。
- 语言要简洁明确：避免模糊表述。比如“系统应避免非预期的加速”，而不是“系统要安全”。
- ASIL等级继承：SG的ASIL等级直接继承自对应的危害事件。如果多个危害合并到一个SG，取最高ASIL。
举个例子：
危害事件：车辆在高速行驶时，EPS（电动助力转向）非预期施加转向力矩，导致车辆偏离车道。
对应的安全目标：“EPS系统应避免在车速>30km/h时，非预期输出大于5Nm的转向力矩。” [ASIL D]
嗯，这里要注意：SG里最好带上可验证的量化指标。比如“大于5Nm”、“持续时间小于100ms”。这样后面做测试时才有据可依。
4.2 安全状态定义
每个安全目标，都必须定义对应的安全状态（Safe State）。安全状态就是系统在检测到故障后，要进入的一个“不会造成危害”的状态。
我遇到过一些项目，工程师只写了SG，却忘了定义安全状态。结果测试时发现，故障触发了，但系统不知道往哪儿跑——这就尴尬了。
安全状态通常有几种：
- 降级模式：比如EPS降级为纯机械转向，助力消失但还能控制方向。
- 关闭/停止：比如BMS检测到电池过温，直接切断高压继电器。
- 维持当前状态：比如ADAS系统故障时，保持最后一次有效的控制输出，然后提示驾驶员接管。
- 紧急操作：比如制动系统故障时，触发紧急制动直至停车。
| 安全目标示例 | 安全状态 | 退出条件 |
|---|---|---|
| 避免非预期加速 | 切断油门信号，进入跛行模式 | 故障消除且驾驶员重启 |
| 避免转向锁死 | 维持当前转向角度，提示接管 | 故障消除或车辆停止 |
| 避免电池热失控 | 断开高压，启动冷却系统 | 电池温度降至安全阈值以下 |
我的经验：定义安全状态时，一定要考虑故障容错时间间隔（FTTI）。比如某个故障必须在100ms内进入安全状态，那你的安全状态切换逻辑就得在这个时间内完成。我曾经有个项目，安全状态定义得很好，但切换时间超了，结果重新改架构——费时费力。
4.3 安全机制的初步分配
有了SG和安全状态，接下来就要想：怎么检测故障？怎么进入安全状态？这就是安全机制的初步分配。
安全机制（Safety Mechanism）是技术手段，用来检测、控制或缓解故障。在SG阶段，我们不需要把每个细节都定死，但要做初步分配——也就是把大方向定下来。
常见的分配思路：
- 检测机制：比如用自检、看门狗、冗余比较来发现故障。
- 响应机制：比如故障时切换到冗余通道、触发安全状态。
- 避免机制：比如通过硬件隔离、软件多样性来防止故障传播。
举个例子，还是那个EPS系统：
安全目标：避免非预期转向力矩 [ASIL D]
初步分配的安全机制：
1. 扭矩传感器信号合理性检查（检测）
2. 电机电流监控与冗余比较（检测）
3. 看门狗监控主控芯片运行（检测）
4. 故障时切断电机驱动电源（响应）
5. 进入机械转向模式（安全状态）
避坑指南：我曾经见过一个团队，在SG阶段就把安全机制设计得特别细，连寄存器配置都写好了。结果后面做系统设计时发现架构变了，所有机制都得重来。所以，初步分配只定方向和原则，具体实现留给系统设计和硬件软件阶段。
4.4 安全目标文档化
最后，所有SG、安全状态、初步分配的安全机制，都要写进安全计划或安全案例里。格式可以参考ISO 26262-3的模板。
我个人习惯用表格来管理：
| SG ID | 安全目标描述 | ASIL | 安全状态 | 初步安全机制 | FTTI |
|---|---|---|---|---|---|
| SG-01 | 避免非预期加速 | D | 跛行模式 | 油门信号合理性检查 | 100ms |
| SG-02 | 避免转向锁死 | D | 维持当前角度 | 电机位置传感器冗余 | 50ms |
| SG-03 | 避免电池过温 | C | 断开高压 | 温度传感器自检 | 200ms |
嗯，到这里，安全目标定义这块就差不多了。说白了，就是把HARA的结果翻译成工程语言，定好目标、状态和初步手段。后面几章我们会深入讲安全机制的详细设计，以及怎么验证这些SG是否被满足。
你想想看，如果这一步没做好，后面所有工作都可能白费。所以，花时间把SG写清楚、写完整，绝对值得。