如何进行BMS功能安全概念FSC的设计

对电动汽车或混合动力汽车来说，电池系统的功能安全主要落在了电池管理系统BMS身上，主流的开发方案是以ISO 26262（Road vehicles – Functional safety）来进行。

功能安全的整个开发主要涉及到3个主体的工作：下游客户的工作，系统自己本身的工作，上游供应商的工作。以电池系统的功能安全为例，根据笔者的经验，国内目前的工作层级划分如下：

（1）制定安全目标Safety Goal (SG)，包括HARA（危害分析和风险评估），通常由主机厂来主导，电池系统企业可以参与制定的过程，最后将得出的SG以需求的形式给到电池系统企业。

（2）系统级工作：这块是PACK/电芯企业的主要工作，主要是完成主机厂需求分解到设计中的工作。对应ISO 26262中的PART 3/4/5部分，以及后面相对应的验证部分，是整个标准的核心。这个阶段要制定功能安全概念FSC（Functional Safety Concept），得出功能安全需求FSR（FunctionalSafety Requirement），进一步制定TSC，得到技术安全需求规范TSR。

（3）软硬件级工作：这块主要是具体实现系统级需求的设计，以软硬件的需求为输入，进行软硬件级的设计工作。这个阶段得到对元器件和软件的一些要求，下放到供应商进行完成。

从上面的流程可以看，FSC的工作可以说是承上启下，它从一个比较高的纬度来定义了接下来整个功能安全的工作。FSC与FSR是联系在一起的，FSC可以理解为“从安全目标SG得到FSR，并将其分配给相关项的初步架构要素或外部措施”，简单地说FSC=FSR+功能安全属性（如ASIL等级）。

以FEV所做的某个欧洲混合动力卡车项目为例，来看下如何进行FSC的工作。首先，整个动力系统的系统架构如下图所示，这个项目也是多家的合作，可以看到三星SDI提供电池系统，博士提供的DC/DC等逆变器，麦格纳提供的电动转向等。

以下面两安全目标为例，通过故障树FTA分析得到可能违犯安全目标的故障（底事件），从这些底事件中提取出功能安全需求FSR。比如，对于防止电芯热失控来说（其安全状态为断开高压），至少可以得到两个FSR，一个是检测过程中的要求，一个是得到指令后将电池系统转移到安全状态的要求。

根据得到的FSR，将安全目标SG所具备的功能安全属性分配到每一个需求上如下所示，这里涉及到ASIL等级的分解；FTTI时间的制定和分配，也可以采用故障树。

到这个层面，基本就完成了FSC的设计。接下来，在后面还有两个重要的部分与此相关，一个是可追溯性，26262标准要求每一条需求都是可追溯的，另一个是如何验证，26262标准要求每一条需求都是可以验证的。

对于可追溯性，可以采用矩阵表的方案，如下，如果公司有需求管理工具（符号ISO26262的要求），直接用该软件来进行追溯管理即可。

对于验证，如果是以review的形式来展开，可以用checklist来进行，在cheklist制作过程中，将相关的证据以附件的形式连接在每一个需求上。

做过功能安全工作的朋友都会有一个感觉，这是一个系统性、非常严谨、非常细化的工作，的确，26262就是希望以科学的流程方法来保证安全的开发。

企业安全文化、标准流程、技术，可以说是ISO 26262的精髓所在!

---