第4章功能安全概念（FSC）

第4章功能安全概念（FSC）：安全目标定义、功能安全需求导出、安全机制初步设计

好，我们进入功能安全概念阶段。说实话，这是整个安全开发中最关键的一环。很多项目出问题，都是因为FSC阶段没想清楚。我个人习惯把FSC比作「盖房子的设计图」——你后面所有的安全活动，都得按这张图来走。

4.1 安全目标定义——从危害到目标的转化

安全目标，说白了就是「我们要防止什么坏事发生」。它直接来源于HARA分析出来的危害事件。每个危害事件，至少对应一个安全目标。

举个例子。我在一个EPS项目中，HARA分析出「转向助力突然丧失」这个危害。对应的安全目标就是：「防止转向助力非预期丧失」。嗯，这里要注意，安全目标一定要用否定句式，强调「防止」什么。

安全目标的典型格式：

「防止 [危害事件] 发生，当 [触发条件] 时。」

安全目标需要定义三个核心属性：

ASIL等级：直接从HARA结果继承。比如「转向助力丧失」可能是ASIL D。
FTTI（故障容错时间间隔）：从危害发生到系统进入安全状态的最大允许时间。我见过有人把FTTI设得太宽松，结果安全机制来不及响应。避坑指南：FTTI一定要考虑执行器的响应时间。
安全状态：系统进入什么状态才算安全？比如「降级到50%助力」、「完全关闭助力」、「进入跛行模式」。

危害事件	安全目标	ASIL	FTTI	安全状态
转向助力非预期丧失	防止转向助力非预期丧失	ASIL D	100ms	降级至50%助力
制动踏板信号错误导致误制动	防止非预期制动	ASIL C	200ms	切断制动请求
电池过压导致热失控	防止电池过压	ASIL D	50ms	断开高压继电器

你想想看，如果FTTI设成500ms，但执行器响应就要300ms，留给诊断的时间只有200ms。万一诊断算法再慢一点，整个安全机制就失效了。所以FTTI一定要留余量。

4.2 功能安全需求导出——从目标到需求的细化

安全目标定义好了，下一步就是导出功能安全需求（FSR）。FSR是安全目标的细化，它描述了「系统应该做什么来满足安全目标」。

我建议用「需求分解树」的方法。每个安全目标，分解成3-5个FSR。比如「防止转向助力非预期丧失」这个目标，可以分解出：

FSR-01：系统应实时监控扭矩传感器信号的有效性，检测周期≤10ms。
FSR-02：当检测到扭矩传感器故障时，系统应在100ms内进入降级模式。
FSR-03：降级模式下，助力输出应限制在最大扭矩的50%。
FSR-04：系统应具备故障自恢复功能，当故障消失后自动退出降级模式。

这里有个坑。我曾经在一个项目中，FSR写得过于笼统，比如「系统应检测传感器故障」。结果开发团队不知道具体要检测什么故障、用什么方法检测。后来我要求每个FSR必须包含：

检测对象：检测什么信号或组件
检测方法：比如「基于模型比较」还是「基于信号范围检查」
时间约束：检测周期、响应时间
故障反应：进入什么安全状态

个人经验：FSR最好用「SHALL」句式，比如「系统SHALL在100ms内检测到扭矩传感器故障」。这样写出来的需求，测试团队可以直接写测试用例。

4.3 安全机制初步设计——把需求变成技术方案

FSR写好了，接下来就是设计安全机制。安全机制就是「用什么技术手段来实现FSR」。说白了，就是硬件和软件层面的具体方案。

我习惯把安全机制分成三类：

检测机制：比如看门狗、CRC校验、信号范围检查、合理性检查
响应机制：比如故障降级、安全状态切换、故障存储
冗余机制：比如双核锁步、传感器冗余、通信冗余

举个例子。对于FSR-01「监控扭矩传感器信号有效性」，我们可以设计：

// 扭矩传感器信号有效性检测伪代码
// 检测周期：10ms
void TorqueSensorMonitor(void)
{
    // 1. 信号范围检查
    if (TorqueRaw < TORQUE_MIN || TorqueRaw > TORQUE_MAX)
    {
        SetFault(TORQUE_SENSOR_RANGE_FAULT);
        return;
    }
    
    // 2. 信号变化率检查（防止卡滞故障）
    static uint16_t lastTorque = 0;
    uint16_t delta = abs(TorqueRaw - lastTorque);
    if (delta > TORQUE_DELTA_MAX)
    {
        SetFault(TORQUE_SENSOR_RATE_FAULT);
        return;
    }
    lastTorque = TorqueRaw;
    
    // 3. 双传感器交叉比较（如果有冗余传感器）
    if (abs(TorqueSensor1 - TorqueSensor2) > TORQUE_CROSS_THRESHOLD)
    {
        SetFault(TORQUE_SENSOR_CROSS_FAULT);
        return;
    }
    
    // 无故障，清除故障标志
    ClearFault(TORQUE_SENSOR_FAULT);
}

嗯，这里要注意。安全机制设计时，一定要考虑「故障覆盖率」。比如单传感器范围检查，覆盖率可能只有60%。加上变化率检查，能到80%。再加上双传感器交叉比较，能到95%以上。

避坑指南：我曾经在一个项目中，只用了单传感器范围检查，结果传感器输出缓慢漂移，范围检查根本检测不出来。后来加了变化率检查才解决。所以安全机制一定要组合使用，不能依赖单一机制。

安全机制初步设计完成后，需要输出一份「安全机制矩阵」。这个矩阵把每个FSR、对应的安全机制、故障覆盖率、响应时间都列出来。方便后续的验证和评审。

FSR编号	安全机制	故障覆盖率	响应时间	实现方式
FSR-01	信号范围检查 + 变化率检查 + 交叉比较	95%	10ms	软件
FSR-02	故障标志触发降级模式	100%	100ms	软件 + 硬件
FSR-03	扭矩限制器 + 看门狗监控	99%	50ms	硬件

你想想看，如果安全机制的响应时间比FTTI还长，那这个机制就是无效的。所以设计时一定要做时间预算，从故障发生到安全状态切换，每个环节的时间都要算清楚。

4.4 本章小结

功能安全概念阶段，说白了就是「定义问题、分解问题、设计方案」的过程。我个人觉得，这个阶段花的时间越多，后面开发阶段踩的坑就越少。我曾经见过一个项目，FSC阶段只用了两周，结果开发阶段改了六版需求，最后延期了三个月。

所以我的建议是：FSC阶段至少占整个安全开发周期的20%。把安全目标想清楚，把FSR写具体，把安全机制设计扎实。后面的事情，就水到渠成了。

下一章，我们会讲技术安全概念（TSC），也就是怎么把功能安全需求落地到具体的系统架构和软件架构中。到时候我会分享一些实际项目中的架构设计案例。

📚 课程目录