动力电池BMS涉及功能安全的开发流程

2019-12-10 13:05:45 来源：网络，如有侵权请联系我们！

导读：

1、功能安全定义

功能安全：不存在由电子电气系统的故障而引起的危害导致不合理的风险。因此，功能安全开发的首要任务是要避免不可接受的风险。BMS 作为整车零部件，进行功能安全开发时一般由整车层面的Safety Goal 得到概念阶段的FSR（Function safety requirements），再由概念阶段的FSR 分析出电子电气层面的TSR（Technical safety requirements）, 最后分析出BMS

的软件和硬件的功能安全需求。下图是ISO26262 开发过程示意图。

2、概述

在ISO26262 标准中，我们要区分两类故障、错误和失效：随机和系统性失效。系统性失效可以在设计阶段通过合适的方法来避免，而随机性失效只能降低到可接受程度。系统性甚至随机性失效会发生在硬件当中，而软件的失效更多的是系统性的失效。首先根据安全目标，确定安全等级。对于每个危害事件，根据其暴露概率E、可控性C、严重度S 三要素，确定其ASIL 等级。

依据ISO26262 的开发流程，从需求开始，当中包括概念设计、系统设计、硬件设计、软件设计，直至最后的生产发布、售后维护，都提出了相应的功能安全要求，其覆盖了整个汽车的生命周期，从而保证汽车电子产品的功能安全可靠，即使功能失效也不会造成危险的发生。BMS 作为新能源汽车的关键，对其功能要求越来越复杂，BMS 必须具备电压、电流、温度等基本的采样功能，同时对电池的运行过程实时监督，过压、欠压、过流、过温等保护功能，同时SOP、SOC、SOH 的预测，故障诊断、均衡控制、热管理、快慢充管理等。把ISO26262 标准要求，应用到BMS 的开发中，将会大大提高BMS 的安全性。

如果将BMS 视为一个safety element out of context（独立安全单元），独立安全单元的意思在在产品的开发周期内，暂时不考虑整车内其它要素（element）。根据主机厂提供的Saftety Goal，BMS 开发商供应商根据Satety Goal 导出Saftety Requirements，接着是系统设计，硬件设计，软件设计等。

而作为整车的一部分，整车上的一些功能会与电池系统发生相互作用，就要从相关项的角度考虑其作用的结果。

BMS依据汽车电子电气的开发惯例，按照V模型的主体流程进行开发，主机厂会参与到V 模型右边的测试部分。

3、相关项定义

电池高压系统主要由接线盒、模组、电池均衡连接器，高压连接器模块，BMS 等组成。BMS 通过传感器采集电压、温度等数据进行处理，计算电池的SOC/SOH，故障诊断等。同时，通过整车CAN 与VCU 进行信息交互。进行相关项定义时，要分析电池系统组成部分，界定功能安全分析的范围。下图是电池系统结构和原理框图。对于BMS所承接的功能安全目标，是在整车相关项层面得到的。在此基础上，进行BMS产品的开发和验证。

4、开发流程

首先确定危害事件。根据不同的工况、不同驾驶习惯过、天气情况分析出可能性较大的危害事件，针对危害事件，分配到系统工作的各个职能部门。在ISO26262-3，Hazrad 分析可以通过brainstorm、DFMEA等方法来确认。以单体过充危害事件为例，根据ASIL 等级的三要素，确定危害事件的等级。下表是一个简单的电芯过充的HARA分析。在这个表格里面，在城市道路上发生电芯热失控导致车辆起火，定的ASIL Level是C；车辆在速度比较低的时候，定的ASILLevel是A。

罗列功能因故障失效的全部可能性；

汇总全部功能和故障，按照运行模式区分，形成危害事件的矩阵。通过危害分析和风险评估，界定危害事件的功能安全目标。合并不同场景下的同一个危害事件的安全等级，用最高的功能安全等级作为该危害事件的安全等级。为了避免危害事件的发生，进而形成安全目标。

可以从避免危害事件发生的角度考虑安全目标，也可以从避免故障发生的角度提出安全目标。例如：对过放导致内部短路电池起火这个危害提出安全目标，从避免危害发生的角度提出安全目标为防止过放导致短路电池起火，从避免故障的角度提出安全目标则为避免温度限制发生故障。安全目标的ASIL 等级则为危害事件的最高的等级。

安全目标的得出，衍生出一些安全相关的参数也需要做规定，这些参数包括：运行模式，故障容错时间，安全状态，功能冗余等。

第二步，确定功能安全需求FSR，每一个安全目标定义至少一项功能安全要求，尽管一个功能安全要求能够cover 不止一条安全目标，每一条FSR 从相关的SG 继承最高的ASIL。通过分层的方法，从风险评估和危害分析得出安全目标，再由安全目标得出功能安全要求。FSR 的功能安全等级，自动继承安全目标的最高等级。

第三步，由功能安全需求（FSR）提炼技术安全需求（TSR），在整个开发生命周期，技术安全需求是要落实功能安全概念的技术要求，其用意是从细节的单级功能安全要求到系统级的安全技术要求。下表为功能安全需求转化成技术安全需求的栗子，仅供流程上的参考。

第四步，系统设计阶段，系统及子系统需要上面所定义的贯彻技术安全要求，需要反映前面定义的安全检测及安全机制。技术安全要求的应分配给系统设计要素，同时系统设计应完成技术安全要求，关于技术安全要求的实现，在系统设计中应考虑如下问题，定义系统架构，分配TSR 到硬件和软件，同时定义好软件硬件接口HIS。软硬件接口规范应规定的硬件和软件的交互，并与技术安全的概念是一致的，应包括组件的硬件设备，是由软件和硬件资源控制支持软件运行的。

系统设计，标准中给出三个方面的原则：模块化、适当的颗粒度和简单。针对不同的安全等级，强调关注不同侧面的设计考量。

技术安全要求，直接或者经过进一步细化后，分配给硬件和软件。

系统设计完成后，还需要考虑设计验证。功能安全目标越高，越倾向于实物验证的方式。

第五步，硬件系统功能安全设计。硬件的详细安全需求来自于TSR，系统架构及系统边界HSI。根据ISO 26262-8 章节6.4.2 硬件安全需求规范应包括与安全相关的每一条硬件要求，硬件安全要求应按照ISO26262-8 第6 章和第9 章的要求进行验证，以提供证据证明。硬件设计可以硬件功能方块图开始，硬件方块图的所有的元素和内部接口应当展示出来。然后设计和验证详细的电路图，最后通过演绎法（FTA）或者归纳法（FMEA）等方法来验证硬件架构可能出现的故障。对BMS 系统来讲，电池包电压传感器是一个非常重要的传感器，因此针对不同ASIL 等级需要分析电池包电压传感器不同的失效模式。一部分失效模式可以通过硬件的需求防范，一部分失效模式可以被分离为软件需求去防范。

每个技术安全要求怎样设计，与实际产品功能、技术发展水平，供应商水平等密切相关，是不同厂家产品差异性的起点。而产品具体实施，有自己不同的思路，有的是不适用安全机制，直接要求零部件提高自身功能安全等级；有的则选择增加监测机制或者提供不同原理的冗余设计，用以提高功能安全等级。

标准推荐的硬件设计验证原则如下表：

第六步，软件系统设计。在汽车行业软件开发一般遵循V 模型，左边是开发过程，右边对应的测试过程。BMS 软件开发流程，基本与ISO26262 第六部分推荐的软件开发流程V 模型相吻合，如下图所示。在软件架构设计中，需要重点考虑软件的可维护性及可测试性。在汽车行业，软件在整个产品周期内都应当考虑维护性，同时还要考虑软件架构的设计测试的容易实现，在ISO 26262 标准中，测试是非常重要的一方面，任何设计都应该同时考虑到测试的方便性。至此，产品的设计开发环节已经全部完成。

标准推荐的软件架构设计原则如下：