4. 安全目标与安全状态定义：从危害到安全目标的推导

好，咱们进入正题。上一章我们聊了HARA怎么做，拿到了危害事件和ASIL等级。但光有危害还不够，你得告诉系统：「嘿，这个危害不能发生，你得给我守住底线！」这个底线，就是安全目标。

我个人习惯把安全目标看作是「系统对危害事件的零容忍承诺」。说白了，它就是一条红线。系统再怎么出幺蛾子，也不能越过这条线。

4.1 从危害到安全目标的推导

推导过程其实不复杂，但容易踩坑。我见过不少团队，把危害事件直接抄成安全目标，结果后面验证阶段根本没法测。

举个例子：

• 危害事件：车辆在高速行驶时，非预期的动力中断导致追尾。
• 安全目标：车辆在行驶过程中，不得发生非预期的动力中断。

你看，这俩看起来差不多，但安全目标更强调「系统要做什么」或「系统不能做什么」。它是对系统行为的约束。

推导时，我一般遵循三步走：

1. 提取危害场景中的关键行为：比如「非预期加速」、「转向失效」、「制动丧失」。
2. 转化为系统级要求：用「应避免」、「应防止」、「应确保」这类词。
3. 明确时间约束：比如「在100ms内响应」、「在故障发生后200ms内进入安全状态」。

我在一个ADAS项目中遇到过，团队写了个安全目标：「系统应避免碰撞」。这目标太模糊了。什么碰撞？前向？后向？侧向？速度范围是多少？后来我们改成了：「在车速30-120km/h范围内，系统应避免与前方静止或同向移动的车辆发生追尾碰撞，响应时间不超过500ms。」这样就好测多了。

4.2 安全状态的定义与示例

安全目标定好了，接下来就是：当系统发现不对劲时，它该躲到哪里去？这个「躲」的地方，就是安全状态。

安全状态，说白了就是系统在发生故障后，能进入的一个「相对安全」的模式。注意，我说的是「相对安全」，不是绝对安全。因为有时候故障本身已经造成了部分功能丧失，你只能两害相权取其轻。

常见的几种安全状态：

安全状态类型	描述	示例
降级模式	部分功能受限，但核心安全功能保留	ACC系统故障时，退出巡航但保留AEB功能
安全停机	系统完全关闭，进入休眠或断电状态	BMS检测到电池过温，切断高压继电器
故障容错	系统继续运行，但使用冗余通道	转向系统主控制器失效，切换到备份控制器
紧急操作	系统执行预设的紧急动作	驾驶员监测系统发现驾驶员失能，自动靠边停车

嗯，这里要注意：安全状态不是拍脑袋定的。你得考虑故障发生后，系统进入安全状态需要多长时间？这个时间能不能被用户接受？会不会引发新的危害？

定义安全状态时，我建议你问自己三个问题：

• 这个状态真的安全吗？有没有副作用？
• 系统能在规定时间内进入这个状态吗？
• 用户能理解这个状态吗？会不会引起恐慌？

4.3 安全目标的分解与分配

安全目标定好了，但它是系统级的。你得把它拆开，分给各个子系统、硬件、软件去执行。这个过程，我称之为「化整为零」。

举个例子，安全目标：「车辆在行驶过程中，不得发生非预期的加速。」

这个目标怎么分解？

• 传感器层面：油门踏板位置传感器必须能检测到故障，并在故障时输出安全值。
• 控制器层面：VCU必须能识别到传感器信号异常，并在10ms内进入安全状态。
• 执行器层面：电机控制器必须能响应VCU的降级指令，限制输出扭矩。
• 软件层面：应用层软件必须包含故障诊断模块，监控层软件必须能覆盖诊断模块的失效。

你看，一个安全目标，拆成了四个子目标，每个子目标又对应不同的技术要素。这就是分解。

分配的时候，我习惯用一张表格来梳理：

安全目标ID	安全目标描述	ASIL等级	分配对象	安全机制
SG-001	防止非预期加速	ASIL D	VCU、MCU、传感器	传感器信号合理性检查、扭矩监控、看门狗
SG-002	防止非预期转向	ASIL D	EPS控制器、转向电机	双通道比较、扭矩限制、位置传感器校验
SG-003	防止非预期制动	ASIL C	ESC、制动踏板传感器	信号冗余、制动请求仲裁、故障诊断

你想想看，如果不做这个分解，直接扔给软件团队一个「防止非预期加速」的目标，他们根本不知道从何下手。分解之后，每个团队都清楚自己该干什么。

最后，我想强调一点：安全目标的分解不是一次性的。随着设计深入，你可能会发现新的约束条件，需要调整分解方案。保持迭代，保持灵活。

好了，这一章的内容就到这里。记住，安全目标是系统的底线，安全状态是系统的避难所，分解分配是落地的关键。这三者缺一不可。