4、功能安全概念（FSC）：功能安全需求导出、安全机制分配、故障容错时间间隔（FTTI）

好，咱们进入功能安全概念阶段。说白了，FSC 就是告诉你：系统到底要做什么来保证安全？

我见过不少团队，上来就写代码、画板子，安全需求根本没想清楚。结果呢？后期改得痛不欲生。所以，FSC 这一步，千万别跳。

4.1 功能安全需求导出

功能安全需求从哪来？从危害分析和风险评估（HARA）来。HARA 告诉你「什么场景会出问题」，FSC 告诉你「怎么解决这些问题」。

我个人习惯，把安全需求分成两类：

• 安全目标（Safety Goal）：顶层的、系统级的安全要求。比如「电池过充时，必须在 100ms 内切断充电回路」。
• 功能安全需求（FSR）：对安全目标的细化。比如「BMS 应监测单体电压，当任意单体电压超过 4.25V 时，触发过充保护」。

举个例子，我在一个储能项目中遇到过这样的情况：

你想想看，如果没有这些细化的需求，工程师怎么知道该做什么？

4.2 安全机制分配

安全需求有了，接下来就是分配安全机制。说白了，就是「谁来干活」的问题。

安全机制可以分配到：

• 硬件：比如硬件看门狗、冗余传感器、独立的安全芯片。
• 软件：比如软件自检、数据校验、状态机监控。
• 系统层面：比如双通道架构、故障降级策略。

我建议，分配时要遵循一个原则：独立性。什么意思？就是安全机制不能依赖它自己保护的对象。

分配时，还要考虑 ASIL 等级。ASIL D 的功能，可能需要多重冗余。ASIL A 的，可能一个简单的诊断就够了。

安全机制	分配对象	典型 ASIL	备注
电压监测	硬件 + 软件	ASIL C	硬件比较器 + 软件交叉校验
电流监测	硬件	ASIL D	双霍尔传感器，冗余设计
温度监测	软件	ASIL B	NTC 采样，软件滤波
通信故障	系统	ASIL C	CRC 校验 + 超时检测

4.3 故障容错时间间隔（FTTI）

FTTI，全称 Fault Tolerant Time Interval。嗯，这个名字有点绕。说白了，就是「从故障发生到系统进入安全状态，最多能容忍多长时间」。

为什么这个参数重要？因为不是所有故障都需要立即处理。有些故障，系统可以扛一会儿。但扛多久，得有个上限。

我举个例子：

• 过压故障：电池电压从 4.2V 升到 4.3V，可能 100ms 内就会损坏电芯。所以 FTTI 必须小于 100ms。
• 通信中断：CAN 总线丢一帧数据，系统可能还能用上一帧的值。但丢 10 帧，就不行了。所以 FTTI 可能是 100ms。
• 温度过高：温度上升比较慢，FTTI 可以放宽到 1 秒甚至更长。

FTTI 的分配，要分解到各个安全机制上。比如：

FTTI_total = FTTI_detection + FTTI_reaction + FTTI_execution

其中：
- FTTI_detection：故障检测时间（传感器采样 + 诊断算法）
- FTTI_reaction：决策时间（安全机制判断 + 仲裁）
- FTTI_execution：执行时间（继电器动作、切断电源等）

举个例子，假设总 FTTI 是 100ms：

• 检测时间：30ms（每 10ms 采样一次，连续 3 次确认故障）
• 决策时间：20ms（软件判断 + 冗余校验）
• 执行时间：50ms（继电器动作时间）

加起来刚好 100ms。嗯，这里要注意，实际项目中，继电器动作时间往往比想象中长。我遇到过标称 10ms 的继电器，实际动作要 30ms。所以，一定要实测。

4.4 小结

功能安全概念阶段，核心就是三件事：

1. 导出安全需求：从 HARA 到 FSR，层层细化。
2. 分配安全机制：硬件、软件、系统，各司其职，保持独立。
3. 定义 FTTI：给每个故障定个时间上限，别让系统扛太久。

我个人觉得，FSC 做得好不好，直接决定了后续开发的顺畅程度。你想想看，如果安全需求都没想清楚，后面做设计、写代码、做测试，那不都是瞎忙活吗？

好，这一章就到这。下一章，咱们聊聊技术安全概念（TSC），看看怎么把安全需求落地到具体的技术方案里。