3. 功能安全概念（FSC）：安全目标定义、功能安全需求导出、安全机制分配、故障容错时间间隔

好，咱们进入功能安全概念阶段。说实话，这是整个BMS功能安全开发中最「烧脑」的环节之一。为什么？因为你要从一堆抽象的危险事件，落地成具体可执行的安全目标和需求。我见过不少团队，前面HARA做得漂漂亮亮，一到FSC就卡壳了。

FSC的核心任务就四个：定目标、导需求、分机制、定时间。咱们一个一个来拆。

3.1 安全目标定义：把「危险」翻译成「要求」

安全目标（Safety Goal, SG）是什么？说白了，就是针对每个危险事件，你要给出一个「不能发生什么」的硬约束。

举个例子。HARA分析出来一个危险事件：「BMS在充电过程中，因SOC估算错误导致电池过充，引发热失控」。那么对应的安全目标就是：「SG-01：BMS应防止电池在充电过程中发生过充，ASIL C」。

写安全目标时，我个人的习惯是遵循几个原则：

• 每个危险事件至少对应一个安全目标。但注意，一个安全目标可以覆盖多个危险事件，别搞成一一对应，那样需求会爆炸。
• 安全目标要描述「系统级行为」，不要写具体实现。比如「防止过充」是对的，「切断充电继电器」就是设计细节了，放后面再说。
• 必须带上ASIL等级。这个等级直接从HARA继承过来，不能降级，除非你有充分的「充分理由」。

3.2 功能安全需求导出：从「目标」到「怎么做」

安全目标定好了，接下来就是导出功能安全需求（Functional Safety Requirements, FSR）。这一步，很多人容易掉进「过度设计」的坑里。

FSR要回答的问题是：「为了实现这个安全目标，系统需要具备什么能力？」

拿上面的SG-01「防止过充」来说，你可能需要导出这些FSR：

• FSR-01：BMS应实时监测单体电池电压，检测到任一单体电压超过充电截止电压时，应在故障容错时间间隔内停止充电。（ASIL C）
• FSR-02：BMS应具备充电电流检测功能，当充电电流超过设计上限时，应在规定时间内限制电流或切断充电回路。（ASIL B）
• FSR-03：BMS应具备SOC校准机制，在充电过程中定期与参考值比对，偏差超过阈值时触发安全动作。（ASIL C）

嗯，这里要注意：FSR还是偏「功能层面」的描述，不要写「用ADC采样电压」这种硬件细节。那是技术安全需求（TSR）的事。

3.3 安全机制分配：把需求「分」给谁干

FSR写完了，接下来要决定：这些安全机制，到底由硬件实现，还是软件实现，还是软硬协同？

这就是安全机制分配。说白了，就是「分活」。我个人习惯画一张分配矩阵表，一目了然：

分配时，有几个坑要避开：

• 不要把鸡蛋放在一个篮子里。比如过压检测，如果全靠软件，万一MCU挂了怎么办？所以我会建议加一个硬件比较器做独立冗余。
• 注意ASIL分解。如果一个安全机制要求ASIL C，你可以拆成两个ASIL B的独立机制，但必须保证独立性。嗯，这个后面讲「ASIL分解」时会细说。

3.4 故障容错时间间隔：给安全机制「上闹钟」

故障容错时间间隔（Fault Tolerant Time Interval, FTTI），这个概念很多人觉得抽象。其实说白了就是：从故障发生，到系统进入安全状态，你最多能容忍多长时间？

你想想看，电池过充不是瞬间就热失控的。从电压超标到热失控，中间有一个时间窗口。FTTI就是在这个窗口内，你必须完成检测、判断、执行安全动作。

FTTI怎么定？我一般分三步走：

1. 查电池特性：从电芯供应商那里拿到「过压耐受时间曲线」。比如某电芯在4.25V下能坚持5秒，4.3V下只能坚持2秒。
2. 留安全余量：不能卡着极限值定。比如电芯能撑5秒，我定FTTI为3秒，留2秒余量。
3. 分解到各环节：FTTI不是给一个模块的，要分解到检测时间、判断时间、执行时间。比如：
   • 检测时间：1.5秒（包括采样、滤波、通信）
   • 判断时间：0.5秒（软件逻辑处理）
   • 执行时间：1.0秒（继电器动作、电流切断）
   • 合计：3.0秒 ≤ FTTI

最后，说一个容易被忽略的点：FTTI和故障检测时间（FDTI）的区别。FDTI是检测到故障的时间，FTTI是容忍的总时间。FDTI必须小于FTTI，否则你还没检测到，电池已经出事了。

好了，FSC阶段的内容就这些。总结一下：安全目标是「做什么」，功能安全需求是「怎么做」，安全机制分配是「谁来做」，FTTI是「多快做完」。这四个环节环环相扣，缺一不可。

下一章，咱们进入技术安全概念（TSC），看看怎么把功能需求落地成具体的技术方案。到时候我会分享一些硬件架构设计的实战经验，敬请期待。