IATF16949质量体系

搜索

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

[复制链接]
admin 发表于 2019-12-23 07:21:14 来自手机 | 显示全部楼层 |阅读模式
admin
2019-12-23 07:21:14 163 0 看全部
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;车辆在速度比较低的时候,定的ASIL Level 是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 标准中,测试是非常重要的一方面,任何设计都应该同时考虑到测试的方便性。至此,产品的设计开发环节已经全部完成。

参考文献
1、基于功能安全的BMS设计_韩豫萍
2、符合ISO_26262标准的安全完整性等级评估方法的研究_何波
3、基于ISO26262的BMS概念阶段开发概述_田星
4、基于功能安全的BMS设计方法及其可靠性的研究_印凯
5、GB∕T 34590.3-2017 道路车辆 功能安全 第3部分:概念阶段
6、GB∕T 34590.4-2017 道路车辆 功能安全 第4部分:产品开发:系统层面
7、GB∕T 34590.5-2017 道路车辆 功能安全 第5部分:产品开发:硬件层面
8、GB∕T 34590.6-2017 道路车辆 功能安全 第6部分:产品开发:软件层面
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册 |

本版积分规则 返回列表

admin当前离线
管理员

查看:163 | 回复:0

官方微信

手机版

微信公众号

联系QQ:190495174 | Copyright © IATF16949质量体系版权所有 | 免责声明:本网站内容部分源于网络,版权归原作者所有,如涉及作品版权问题,请及时联系我们,我们将删除内容以保证您的权益!
Copyright © 2001-2019 16949tx.com Inc. All Rights Reserved.   Powered by IATF16949质量体系 X3.2
快速回复 返回顶部 返回列表