4、安全目标（Safety Goal）与安全状态：安全目标的定义与分解，功能安全概念（FSC），安全状态与容错时间间隔（FTTI）
好，咱们今天聊点硬核的。安全目标、安全状态、FTTI，这几个词你肯定听过。但真正在项目里把它们落地，很多人就懵了。我见过不少团队，安全目标写得天花乱坠，一追问「你这个目标到底怎么分解到系统里的？」——答不上来。
说白了，安全目标不是写文档交差的。它是整个功能安全设计的「宪法」。所有后续的硬件、软件、测试，都得围着它转。今天我就把这块掰开了讲，顺便聊聊我踩过的坑。
4.1 安全目标：从危害到目标的「翻译」
还记得上一章我们做的HARA吗？HARA输出的是「危害事件」和「ASIL等级」。但危害事件太具体了，比如「车辆在高速上突然无制动」。工程师没法直接拿这个去设计系统。我们需要把它翻译成一句工程语言——这就是安全目标。
安全目标的定义：一个最高层级的安全要求，用于避免或减轻某个特定的危害。它回答的是「系统必须做到什么，才能保证安全」。
举个例子：
- 危害事件：车辆在高速行驶（>80km/h）时，制动系统失效，导致无法减速，引发碰撞。
- 安全目标：在车辆行驶速度 > 5km/h 时，制动系统必须能在驾驶员踩下制动踏板后的 500ms 内，产生至少 0.6g 的减速度。（ASIL D）
看到了吗？安全目标里要有：触发条件、功能要求、性能指标、时间约束、ASIL等级。缺一不可。
我个人习惯：写安全目标时，我会用「如果...那么...否则...」的句式来检查逻辑。比如：「如果驾驶员踩下制动踏板，那么系统必须在500ms内产生0.6g减速度，否则车辆将无法避免碰撞。」这样一写，漏洞自己就冒出来了。
4.2 安全目标的分解：把大目标拆成小任务
一个安全目标往往对应整个系统。但系统是由传感器、控制器、执行器组成的。你不能要求「整个系统」去实现一个目标，你得把它拆开。
分解的原则很简单：每个子系统或组件，只承担它该承担的那部分责任。
还是拿制动系统举例。安全目标是「500ms内产生0.6g减速度」。我们怎么拆？
- 传感器：必须能在 100ms 内检测到制动踏板位移，并输出有效信号。（ASIL D）
- 控制器：必须在收到信号后的 50ms 内，计算出所需制动压力，并输出控制指令。（ASIL D）
- 执行器（制动卡钳）：必须在收到指令后的 350ms 内，建立足够的制动压力，产生 0.6g 减速度。（ASIL D）
你看，总时间 100+50+350 = 500ms，刚好对上。每个组件都有自己的时间预算和ASIL等级。这就是分解。
避坑指南：我曾经在一个项目里，把安全目标分解得太粗。比如「控制器必须可靠工作」。结果设计评审时，大家吵了半天什么叫「可靠」。后来我学乖了，每个分解项必须包含：功能、性能、时间、ASIL、故障容错行为。少一个都不行。
4.3 功能安全概念（FSC）：把安全目标变成系统设计
安全目标分解完了，接下来要回答一个更实际的问题：系统到底怎么设计，才能满足这些目标？这就是功能安全概念（FSC）要做的事。
FSC不是代码，也不是电路图。它是一组功能层面的安全机制。说白了，就是「当故障发生时，系统靠什么来兜底」。
常见的FSC元素包括：
- 故障检测机制：比如监控模块、看门狗、信号合理性检查。
- 故障响应机制：比如降级模式、安全状态切换、冗余切换。
- 故障容错机制：比如双通道比较、三模冗余（TMR）。
- 驾驶员警告机制：比如仪表盘报警、声音提示、HMI交互。
举个例子，对于制动系统的安全目标，FSC可能这样写：
- 当主制动通道发生故障（如传感器失效）时，系统必须在 50ms 内检测到故障。
- 检测到故障后，系统必须在 100ms 内切换到冗余制动通道。
- 切换后，系统必须向驾驶员发出视觉和声音警告。
- 如果冗余通道也失效，系统必须进入安全状态（如主动减速至停车）。
嗯，这里要注意：FSC里写的每个「必须」，后面都要有对应的技术方案去实现。不能只写「系统应可靠」，那是废话。
4.4 安全状态：系统出问题后该去哪？
安全状态，就是系统在发生故障后，要进入的一个风险可接受的状态。它不是「关机」，也不是「继续跑」，而是经过设计的、能保证人员安全的特定状态。
常见的自动驾驶安全状态包括：
| 安全状态 | 描述 | 适用场景 |
|---|---|---|
| 最小风险策略（MRM） | 系统主动减速并靠边停车 | L3/L4 系统主控制器失效 |
| 降级模式 | 限制功能（如限速、禁止变道） | 传感器部分失效 |
| 安全停机 | 切断动力，保持制动 | 制动系统完全失效 |
| 被动安全状态 | 系统不动作，但不会引发危险 | 泊车辅助等低速场景 |
设计安全状态时，有几个关键点：
- 可验证性：安全状态必须是可测试、可验证的。你不能说「系统进入安全状态」，然后没法测。
- 可恢复性：有些安全状态是可恢复的（比如降级模式），有些是不可逆的（比如切断动力）。设计时要考虑。
- 时间约束：从故障发生到进入安全状态，必须在规定时间内完成。这个时间就是FTTI。
我踩过的坑：有一次，我们设计的安全状态是「系统减速至0并驻车」。但没考虑场景——如果车辆在高速路中间呢？减速停车反而更危险。后来我们加了一条：安全状态必须结合当前场景动态选择。比如高速上优先靠边，低速下直接停车。
4.5 容错时间间隔（FTTI）：和时间赛跑
FTTI，全称 Fault Tolerant Time Interval。翻译过来就是「容错时间间隔」。它定义了：从故障发生，到系统进入安全状态，中间允许的最大时间。
为什么这个参数这么重要？因为很多故障不是瞬间致命的。比如制动压力缓慢下降，前几秒可能还能刹住，但10秒后就完全失效了。FTTI就是那个「最后期限」。
FTTI的组成通常包括：
- 故障检测时间：从故障发生到被检测到。比如看门狗超时检测，可能需要几个周期。
- 故障响应时间：从检测到故障到开始执行安全措施。比如切换通道、发出警告。
- 安全状态到达时间：从执行安全措施到真正进入安全状态。比如减速到0需要几秒。
FTTI = 故障检测时间 + 故障响应时间 + 安全状态到达时间
举个例子：
- 制动主控制器故障，FTTI要求 500ms。
- 故障检测：看门狗在 100ms 内检测到无心跳。
- 故障响应：系统在 50ms 内切换到冗余控制器。
- 安全状态到达：冗余控制器在 350ms 内建立制动压力。
- 总时间：100+50+350 = 500ms ✅
如果任何一个环节超时，整个安全设计就失效了。所以FTTI是牵一发动全身的参数。
我的建议：在项目初期，就要把FTTI分配到每个组件上。然后让硬件、软件、算法团队各自认领。谁超时谁负责。别等到集成测试时才发现时间不够，那时候改架构就晚了。
4.6 知识体系总览
下面这张图，是我自己总结的本章知识体系。你可以把它当作一个「思维导图」来用。
这张图把本章的核心逻辑串起来了。从安全目标出发，经过分解、FSC设计，最终落到安全状态和FTTI。每一步都有输入输出，每一步都影响后续设计。
好了，这一章的内容就到这。安全目标不是写出来就完事的，它要贯穿整个开发流程。下次你写安全目标时，记得问自己一句：这个目标，我的系统真的能实现吗？
公众号:蓝海资料掘金营，微信deep3321