3、安全目标定义：安全目标的制定、安全状态定义、安全机制初步分配

好，我们进入第三个关键环节——安全目标定义。

说实话，很多工程师觉得 Hazard Analysis 做完就万事大吉了。其实不是。真正的硬仗，从安全目标定义才开始。你想想看，分析出风险只是第一步，怎么把它转化成可执行、可验证的工程要求，这才是功力所在。

3.1 安全目标的制定

安全目标，说白了就是一句话：「系统必须避免某个危害事件发生」。但这句话怎么写，大有讲究。

我个人习惯用这个模板：

「当 [触发条件] 时，系统应确保 [安全行为]，以避免 [危害事件]。」

举个例子，针对制动系统常见的「非预期制动」危害：

「当车辆正常行驶时，系统应确保不产生超过 0.3g 的减速度，以避免非预期制动导致追尾。」

这里要注意几个要点：

• 量化指标：不要写「避免突然制动」，要写「减速度不超过 0.3g」。我在项目中遇到过，早期写得太模糊，结果测试团队和开发团队吵了三个月——什么叫「突然」？后来改成量化指标，大家都没话说了。
• 明确触发条件：是「车辆静止时」还是「行驶中」？是「驾驶员踩下制动踏板」还是「系统自主决策」？条件不同，安全机制完全不同。
• ASIL 等级：每个安全目标都要继承 Hazard Analysis 中分配的 ASIL。嗯，这里要提醒一下，ASIL 等级不能随便降，必须有充分的「ASIL 分解」理由。

3.2 安全状态定义

安全状态，是安全目标实现后的「理想状态」。但更重要的，是定义「当系统发生故障时，应该进入什么状态」。

我见过最典型的错误，就是只定义了「正常工作的安全状态」，没定义「故障后的安全状态」。结果系统一报错，直接死机——这比不报错还危险。

制动系统的安全状态，通常包括：

安全状态	描述	典型触发条件
正常制动	系统按驾驶员意图提供制动力	无故障
降级制动	部分功能受限，但基础制动可用	传感器单点故障
安全停机	系统停止输出，进入安全静默状态	严重内部故障
跛行回家	限制车速，允许车辆低速行驶到维修点	非关键故障

这里有个坑，我曾经踩过：

定义安全状态时，一定要问自己三个问题：

1. 这个状态真的安全吗？——从整车层面看，不是从子系统层面看。
2. 进入这个状态需要多长时间？——制动系统通常要求 < 100ms。
3. 退出这个状态的条件是什么？——是自动恢复，还是需要维修介入？

3.3 安全机制初步分配

安全机制，就是用来「确保安全目标达成」和「在故障时进入安全状态」的具体手段。

初步分配阶段，我们不需要把每个细节都敲死。但至少要回答：「用什么方式来实现安全？」

常见的制动系统安全机制包括：

• 冗余设计：双通道制动回路、双传感器、双 MCU。我习惯在架构层面就预留冗余接口，不然后期加冗余，成本翻倍。
• 监控机制：看门狗、CRC 校验、信号合理性检查。比如制动踏板信号，我会用两个独立传感器，一个线性输出，一个开关输出，互相校验。
• 故障响应：故障检测后的降级策略、故障存储、警告灯点亮。
• 诊断覆盖：每个安全机制都要有对应的诊断手段，确保故障能被及时发现。

举个例子，针对「非预期制动」这个安全目标：

安全目标	安全状态	安全机制	ASIL
避免非预期制动	降级制动（保留基础助力）	制动踏板信号双冗余 + 合理性校验	ASIL D
		制动指令超时监控（看门狗）	ASIL D
		制动压力传感器反馈校验	ASIL B

你可能会问：为什么同一个安全目标，不同安全机制的 ASIL 等级不一样？

嗯，这就是 ASIL 分解的妙处。如果一个安全机制能独立检测并防止故障，那它就可以承担更高的 ASIL。如果多个机制共同作用，可以适当降低单个机制的要求。但前提是——它们必须相互独立，不能有共因失效。

最后，我想强调一点：安全机制不是越多越好。我见过一个项目，为了追求 ASIL D，给制动系统加了 7 层冗余。结果呢？系统复杂度爆炸，故障率反而上升了。安全工程是门平衡的艺术——够用就好，过度设计是另一种风险。

好，这一节就到这里。下一节我们讲「安全架构设计」，到时候我会分享一个我踩过的「架构级大坑」，保证让你印象深刻。