4、安全目标定义：安全目标的制定、安全状态定义、安全机制初步分配
好，我们进入功能安全开发中非常核心的一步——安全目标定义。
说实话，很多项目在这里栽过跟头。我个人习惯是，在 Hazard Analysis 做完之后，先别急着写代码，把安全目标想清楚再说。你想想看，如果目标本身是歪的，后面做再多也是白搭。
4.1 安全目标的制定
安全目标，说白了就是「为了防止危害事件发生，系统必须满足的安全要求」。它来源于 Hazard Analysis 和风险评估（HARA）的输出。
每个安全目标对应一个危害事件。比如，对于 EPS（电动助力转向）系统，一个典型的安全目标是：
安全目标示例：
「防止非预期的转向助力输出，导致车辆偏离预期行驶轨迹。」
ASIL 等级：ASIL D
我在项目中遇到过，有些团队把安全目标写成了功能需求。比如「转向助力必须在 50ms 内响应」。这不是安全目标，这是功能需求。安全目标关注的是「避免危害」，而不是「实现功能」。
制定安全目标时，我建议遵循以下几点：
- 每个危害事件对应一个安全目标——不要合并，不要遗漏
- 安全目标要描述「避免什么」，而不是「实现什么」
- 明确 ASIL 等级——从 HARA 中继承
- 安全目标要可验证——你总得知道怎么测试它吧？
小技巧：我个人习惯用「防止……导致……」的句式来写安全目标。这样能清晰区分「危害」和「后果」。
4.2 安全状态定义
安全状态，就是系统在发生故障时，能够进入的一个「不会造成危害」的状态。
嗯，这里要注意：安全状态不一定是「停机」。有时候停机本身反而更危险。比如，刹车系统的安全状态是「保持制动力」，而不是「断电释放」。
定义安全状态时，我通常会问自己三个问题：
- 故障发生时，系统应该做什么？——比如降级、限制输出、切换到备份
- 这个状态真的安全吗？——需要结合整车层面分析
- 如何进入这个状态？——需要哪些检测和触发条件
举个例子，对于 ACC（自适应巡航）系统：
| 故障场景 | 安全状态 |
|---|---|
| 车速传感器失效 | 退出 ACC，提示驾驶员接管，车辆滑行减速 |
| 制动执行器卡滞 | 限制加速度，请求驾驶员立即接管 |
| 雷达信号丢失 | 保持当前速度，提示驾驶员，限时接管 |
我曾经在一个项目中，安全状态定义得太简单了——「故障时系统关闭」。结果在实车测试时发现，关闭后方向盘突然变重，驾驶员根本反应不过来。嗯，从那以后，我再也不敢轻视安全状态定义了。
避坑指南：我曾经见过一个团队，把安全状态定义成「系统进入安全状态」。这等于没说。安全状态必须具体、可执行、可验证。比如「电机输出扭矩限制在 5Nm 以内，同时点亮故障灯」。
4.3 安全机制初步分配
安全机制，就是用来「检测故障」和「进入安全状态」的手段。
说白了，安全目标告诉你「要避免什么」，安全状态告诉你「出问题后去哪」，安全机制告诉你「怎么去」。
在概念阶段，我们做的是「初步分配」。不需要把每个细节都敲死，但大的方向要定下来。
常见的安全机制类型包括：
- 故障检测机制——比如自检、看门狗、冗余比较
- 故障响应机制——比如降级、切换、紧急停机
- 故障避免机制——比如物理隔离、多样性设计
举个例子，对于「防止非预期加速」这个安全目标：
| 安全机制 | 类型 | 说明 |
|---|---|---|
| 油门踏板信号合理性检查 | 故障检测 | 两个传感器信号偏差超过阈值时，报故障 |
| 看门狗定时器 | 故障检测 | 监控主控芯片是否正常运行 |
| 扭矩限制 | 故障响应 | 检测到故障后，限制最大输出扭矩 |
| 冗余路径 | 故障避免 | 关键信号采用双路冗余设计 |
我个人的习惯是，在初步分配时，先列出「每个安全目标至少需要 2-3 个安全机制」。一个负责检测，一个负责响应，一个作为后备。这样即使一个失效，还有另一个兜底。
经验之谈：初步分配时，不要追求完美。先搭框架，后面细化。我见过有人花了两周时间纠结一个安全机制的具体实现，结果评审时发现安全目标本身就有问题……嗯，先抓大方向。
4.4 小结
安全目标定义这一步，是整个功能安全开发的「地基」。地基歪了，后面盖的楼再漂亮也没用。
总结一下今天的内容：
- 安全目标——从 HARA 来，描述「避免什么危害」
- 安全状态——故障后的「避风港」，要具体可执行
- 安全机制——实现安全目标的手段，先搭框架再细化
下一章，我们会聊「功能安全概念」的构建。到时候，这些安全目标会变成更具体的技术方案。准备好了吗？