4、安全目标定义：转向系统安全目标制定、安全状态定义、安全机制分配

好，咱们进入第四章。前面我们做了危害分析与风险评估（HARA），拿到了ASIL等级和危害事件。但光有这些还不够——你得告诉开发团队：“到底要做到什么程度才算安全？”

这就是安全目标（Safety Goal）要做的事。说白了，安全目标就是把HARA里那些抽象的危害，翻译成具体、可验证的工程要求。

我个人习惯把这一步叫做“从危害到需求的桥梁”。你想想看，HARA里写的是“车辆非预期转向导致碰撞”，这没法直接写代码。但安全目标会说：“转向系统在单点故障下，必须能在100ms内进入安全状态。”——这就清晰多了。

4.1 安全目标的制定原则

制定安全目标时，我一般遵循三个原则：

• 每个危害事件至少对应一个安全目标——不能遗漏，也不能合并过度。
• 安全目标必须是可验证的——如果写出来没法测试，那这个目标就是废纸。
• ASIL等级向下兼容——安全目标的ASIL取该危害事件的最高等级。

举个例子，我在一个线控转向项目里遇到过这样的情况：HARA分析出来一个危害——“转向指令丢失导致车辆偏离车道”，ASIL C。对应的安全目标怎么写？

危害事件	安全目标编号	安全目标描述	ASIL
转向指令丢失导致车辆偏离车道	SG-01	转向系统必须检测到主路通信链路故障，并在50ms内切换至冗余通信路径	C
非预期转向扭矩输出	SG-02	转向执行器在未收到有效指令时，输出扭矩不得超过5Nm，持续时间不超过200ms	D
电源失效导致转向功能丧失	SG-03	在主电源失效时，备用电源必须在20ms内接管，并维持系统工作至少3秒	C

看到没？每个安全目标都绑定了具体的数值和时限。这就是可验证的基础。

4.2 安全状态定义

安全目标里提到了“进入安全状态”。那什么是安全状态？

我见过不少团队在这个问题上翻车。他们觉得安全状态就是“系统关机”。但你想，高速公路上行驶时，转向系统突然关机——这本身就是一个新的危害。

所以，安全状态必须结合车辆运行场景来定义。

线控转向系统常见的安全状态包括：

1. 降级模式（Degraded Mode）——主通道失效，切换到冗余通道，性能可能下降但功能保持。
2. 故障响应模式（Fail-Response Mode）——检测到不可恢复故障，系统主动限制输出扭矩，并提示驾驶员接管。
3. 安全停机（Safe Shutdown）——仅在车辆静止或极低车速下允许。

我习惯用一张状态机图来定义安全状态之间的转换关系。下面是我画的一个简化版：

4.3 安全机制分配

有了安全目标和安全状态，接下来就是分配安全机制。这一步是把“要做什么”变成“怎么做”。

我通常把安全机制分为三类：

• 检测机制——发现故障（如：看门狗、CRC校验、信号合理性检查）
• 响应机制——执行安全动作（如：切换冗余通道、限制扭矩、触发报警）
• 避免机制——防止故障发生（如：冗余设计、降额设计、物理隔离）

下面是一个实际项目中的分配示例：

安全目标	检测机制	响应机制	分配模块	覆盖的故障类型
SG-01：通信链路故障	CRC校验 + 超时监控	切换至冗余CAN总线	通信管理模块	数据损坏、链路中断
SG-02：非预期扭矩输出	扭矩传感器交叉校验	切断执行器供电	执行器驱动模块	传感器漂移、指令错误
SG-03：电源失效	电压监控 + 欠压检测	切换至备用电源	电源管理模块	主电源掉电、电压跌落

这里有个容易踩的坑——安全机制的独立性。我曾经在一个项目里，检测机制和响应机制跑在同一个MCU上。结果那个MCU挂了，检测和响应一起失效。后来我们强制要求：检测和响应必须分配在不同的硬件单元上，或者至少使用不同的时钟域和电源域。

4.4 安全目标与安全机制的追溯性

最后说一句，安全目标不是写完了就完事了。你得建立完整的追溯链：

1. 危害事件 → 安全目标
2. 安全目标 → 安全机制
3. 安全机制 → 具体实现（硬件/软件需求）
4. 具体实现 → 测试用例

这个链条断了，功能安全审核就过不了。我习惯用一个工具（比如DOORS或Jama）来维护这个追溯矩阵，但小项目用Excel也能搞定——关键是别漏掉任何一条链路。