3. 安全生命周期

好，咱们进入正题。功能安全概念，说白了就是回答一个问题：系统怎么才能不出危险？

我个人习惯把FSC看作一座桥。桥的一头是HARA分析出来的危险事件，另一头是具体的技术方案。而桥本身，就是安全目标、功能安全概念、安全状态这些核心要素。

今天咱们就拆开这座桥，一块砖一块砖地看。

3.1 安全目标（Safety Goal）的定义

安全目标是什么？它是系统最高层级的安全要求。每个危险事件，最终都要对应到一个或多个安全目标上。

我举个例子。你想想看，一辆车的电子助力转向系统，如果突然失去助力，会发生什么？驾驶员需要花更大的力气打方向，在高速上可能就出事了。所以，一个典型的安全目标就是：“转向助力不能意外丧失”。

定义安全目标时，有几个关键要素必须写清楚：

• 危险事件描述：什么情况下会触发这个危险？
• 安全状态：系统进入什么状态才算安全？
• 容错时间间隔（FTTI）：从故障发生到系统进入安全状态，最多能等多长时间？
• ASIL等级：这个安全目标要满足哪个ASIL等级？

我在项目中遇到过一种情况：安全目标写得过于笼统。比如“系统要安全”，这等于没写。安全目标必须具体到可验证、可测试的程度。否则到了后期，你根本没法证明它是否满足。

3.2 功能安全概念（FSC）的导出

安全目标定好了，接下来就是怎么实现它。功能安全概念，就是把安全目标分解成具体的功能要求。

我习惯用“分配-分解-细化”三步法来做这件事。

3.2.1 分配

把安全目标分配到系统的各个组成部分。比如转向助力系统，安全目标“转向助力不能意外丧失”可以分配给：

• 电机控制器：实时监控电机状态
• 扭矩传感器：提供冗余信号
• 电源模块：保证供电稳定

3.2.2 分解

有时候一个安全目标太复杂，需要拆成几个子目标。比如：

• SG-01：转向助力不能意外丧失
• FSC-01.1：电机控制器应在10ms内检测到电机过流故障
• FSC-01.2：扭矩传感器应提供两路独立信号，偏差超过5%时触发报警
• FSC-01.3：电源模块应在20ms内切换到备用电源

3.2.3 细化

这一步最考验经验。你要把功能要求细化到具体的技术措施。比如：

• 用什么诊断机制？是软件自检还是硬件看门狗？
• 故障响应时间是多少？
• 系统进入安全状态后，怎么恢复？

3.3 安全状态与容错时间间隔

这两个概念是FSC的核心，也是很多工程师容易搞混的地方。

3.3.1 安全状态

安全状态，就是系统在检测到故障后，进入的一个不会导致危险的状态。

常见的几种安全状态：

安全状态类型	描述	示例
降级模式	系统以降低性能的方式继续运行	转向助力降低50%，但还能用
安全停机	系统完全停止工作	电机断电，机械锁止
故障静默	系统停止输出，不产生任何影响	传感器输出固定值，不再响应
冗余切换	切换到备用通道继续工作	主控制器故障，切换到从控制器

这里有个坑，我提醒一下：安全状态不是一成不变的。同一个系统，在不同工况下，安全状态可能不同。比如高速行驶时，突然切断转向助力可能更危险，所以降级模式比安全停机更合适。

3.3.2 容错时间间隔（FTTI）

FTTI，全称Fault Tolerant Time Interval。它定义了从故障发生到系统进入安全状态，所允许的最大时间。

这个时间怎么定？我一般从两个角度考虑：

• 物理极限：比如刹车系统，从踩下刹车到车辆停下，物理上需要多长时间？
• 人的反应时间：驾驶员发现异常到做出反应，通常需要0.5-1秒。

3.4 知识结构图

下面这张图，把FSC的核心逻辑串起来了。你可以把它当作一个检查清单，写FSC时对照着看。

3.5 避坑指南

最后，分享几个我踩过的坑：

• 安全状态定义不完整：只写了“系统停机”，但没写停机后怎么恢复。结果测试时发现，系统停机后无法重新启动，导致车辆趴窝。
• FTTI估算过于乐观：我见过有人把FTTI定在50ms，但实际诊断机制需要30ms，决策需要20ms，执行需要30ms，加起来80ms，超了。所以FTTI一定要留余量。
• 忽略多故障场景：FSC通常只考虑单点故障。但实际系统中，多个故障同时发生的情况并不少见。我建议在FSC中至少考虑两个故障同时发生的场景。

嗯，这一块内容就这些。你写FSC的时候，记得把这张图贴在工位上，对照着检查。少踩一个坑，项目就顺利一分。