中国汽车工程师之家--聚集了汽车行业80%专业人士 

论坛口号:知无不言,言无不尽!QQ:542334618 

本站手机访问:直接在浏览器中输入本站域名即可 

您当前所在位置: 新能源车 > 查看内容

BMS功能安全开发流程详解

文章作者头像
发布:liuxianglong 来源: 电动知家
PostTime:13-5-2018 21:47
BMS即Battery Management System,电池管理系统。作为新能源汽车“三电”核心技术之一

以下为文章全文:(本站微信公共账号:cartech8)


汽车零部件采购、销售通信录       填写你的培训需求,我们帮你找      招募汽车专业培训老师

(一):BMS和ISO26262

BMS & ISO26262简介

BMS即Battery Management System,电池管理系统。作为新能源汽车“三电”核心技术之一,BMS在新能源车上扮演十分重要的作用。按照新能源汽车对电池管理的需求,BMS具备的功能包括电压/温度/电流采样及相应的过压、欠压、过温、过流保护,SOC/SOH估算、SOP预测、故障诊断、均衡控制、热管理和充电管理等。

为了保证汽车电子电气的可靠性设计, 在2011年发布了IS0 26262道路车辆功能安全标准), IS0 26262 标准是源于工业功能安全标准(IEC61508)[1]。目前许多汽车企业和零部件企业在控制器开发过程中采用ISO26262这个标准,ISO26262包括了汽车电子电气开发中与安全相关的所有应用,制定了汽车整个生命周期中与安全相关的所有活动,ISO 26262从需求开始,当中包括概念设计、软硬件设计,直至最后的生产、操作,都提出了相应的功能安全要求,其覆盖了汽车整个生命周期,从而保证安全相关的电子产品的功能性失效不会造成危险的发生。如下图所示

1. 范围及相关项

ISO26262适用于最大总质量不超过3.5吨的量产成用车上的包含一个或多个电子电气系统的与安全相关的系统。在这部分ISO26262和FMEA还是比较相似的,第一步是确定Scope,那些是研究范围之内的。对高压电池系统而言,ISO26262适用于电池包电气系统及BMS系统,而不适用于电池包的电芯及机械结构件等。

1)Function Safety Definition

功能安全:不存在由电子电气系统的功能异常而引起的危害而导致不合理的风险。

为了保证避免不可接受的风险,功能安全开发流程在在ISO262262标准中进行了详细的阐述。概念阶段的function safety requirements应当能够满足整车层面的Safety Goal,电子电气层面的开发出来的technical safety requirements同时也应该满足概念阶段的function safety requirements,最后一步是确定零部件级别的软件和硬件的功能安全需求。下图是ISO26262开发途径。

2)Fault, Errors and Failures Definitions

Fault(故障):可引起要素或相关项失效的异常情况

Errors (错误):计算的、观测的、测量的值或条件与真实的、规定的、理论上正确的值或条件之间的差异

Failure(失效):要素按要求执行功能的能力的终止

基于上面的定义,他们之间存在一定的因果关系,故障会产生错误,而错误会引起功能或者系统的失效,如果下图。

在ISO26262标准中,我们要区分两类故障、错误和失效:随机和系统性失效。系统性失效可以在设计阶段通过合适的方法来避免,而随机性失效只能降低到可接受程度。系统性甚至随机性失效会发生在硬件当中,而软件的失效更多的是系统性的失效。

失效同时还可以分为单点失效和多点失效。

单点失效:要素中没有被安全机制所覆盖,并且直接导致违背安全目标的故障

多点失效:由几个独立的故障组合引发,直接导致违背安全目标的失效。

在多点失效中有个特别的失效叫双点失效。由两个独立故障组合引起的,直接导致违背安全目标的失效。

故障发生的时间关系如下图所示

诊断测试时间间隔(diagnostic test interval):通过安全机制执行在线诊断测试时间间隔

故障响应时间(fault reaction time):从故障探测到进入安全状态的时间间隔

3)Risk Definition

风险可以看成一个功能函数F,一个变量frequency of occurrence (f),controllability (C),potential severity (S)功能函数

其中f是Exposure(E)危害时间发生概率λ的函数

ISO26262标准中分别对E,C,S进行了相应的定义

a. 对于每一个危害事件,应基于确定的理由预估每个运行场景的暴露概率。按照下表,应为暴露概率指定一个E0、E1、E2、E3或E4的概率等级。

b. 对于每一个危害事件,应基于一个确定的理由预估驾驶员或其他潜在处于风险的人员对该危害事件的可控性。按照下表,应为可控性指定一个C0、C1、C2或C3的可控性等级。

c. 对于每一个危害事件,应基于一个已确定的理由来预估潜在伤害的严重度。根据下表,应为严重度指定一个S0、S1、S2或S3的严重度等级

d. 每一个危害事件的ASIL等级应使用“严重度”、“暴露概率”和“可控性”这三个参数根据下表来确定

由于BMS属于新能源汽车高压电池系统的一部分,EUCAR定义了高压电池系统的危害等级。

当BMS不能够很好的监测或者保护电芯时,上表中的危害事件就有可能发生。ISO26262的目标是保护乘客受到危害,因为上表Level 5以上就算是严重危害事件了。因此有必要定义一个电芯工作的最大允许危害级别,5以上时肯定不允许的。

(二):ASIL等级

1. 相关项定义,ASIL等级,安全目标

如下图所示,第一步通过不同的驾驶情况,不同的环境来确定不同的场景;第二步分析不同场景下的事故所以引起的Hazard Situation. 第三步确定这些Hazard Situation的ASIL 等级,这一部分有很大的主观因素,每个公司考虑问题的角度不一样,针对不同的Hazard Situation设定的ASIL 等级也会不一样。比如有些OEM定义热失控的ASIL LEVEL为C,有些OEM设定热失控 ASIL LEVEL 为D,不过目前来看热失控以后的ASIL LEVEL会是D,在知乎上看有人说以后大众的高压电池包的安全等级为D,他说的这个电池包应该是指电池包里面的电气架构包括BMS。

ISO 26262-3 Scheme ©TüV Süd

第四步根据上一步确定的不同的故障模型Harzard Situation ASIL的最大ASIL等级。第五步根据上一步确定的最大ASIL等级就可以设定Safety Goal了。在上篇文章中简单介绍了功能安全的开发途径,在开发途径中,Safety Goal是Top Level的Safety Requirements,直接来自于HARA(hazard analysis and risk assessment)。第七步,根据Safety Goal就可以导出 Saftety Requirements。

因为ISO26262涉及到产品的整个开发周期,那么谁该负责这整个流程,主机厂还是供应商?如果BMS是由供应商开发提供给主机厂,那么理论上前5步都应该是主机厂来主导分析,输出Saftety Goal给供应商,供应商根据Satety Goal导出Saftety Requirements,接着是系统设计,硬件设计,软件设计等。同时主机成也会参与到V模型右边的测试部分。

根据上面的分析,我们将BMS最为一个safety element out of context(独立安全单元),独立安全单元的意思在在产品的开发周期内,不用考虑整车内其它要素(element)。

a. Item Definition

Item dedinition首先要确定item的scope,item的边界及与item相关的部件,确定item与外界部件的交互接口,CAN信号,传感器信号等等。一般通常采用方框来表示item的elements,通过这些elements和elements之间的信息交互,就能够确定这个系统的大致架构。

如果下图a是一个电池系统的方块图,电池高压系统主要有Junction box,Modules,cell balance interconnect circuit, HV contactor module, BMS等。BMS通过将传感器采集的数据进行处理,计算电池SOC/SOH,故障诊断等,同时通过整车CAN与VCU进行信息交互。b图是a图所对应的item defintion。一个A00级的BEV电池包。

a) Preliminary architecture of the hypothetical Li-ion battery system

b) Key elements and signals within the energy storage system

点画线表示高压电池系统的边界线,高压系统的与外界的交互信号分成了下表中的七大类。

上面定义了不同类的子系统,下面这张图是上图中(connected modules)连接模组的框框图。

下面这张图是上面连接模组的进一步分解的模组框框图及信号流。

这样一层一层像剥洋葱一样分解系统,很方便追溯所有信号来源。系统与其他外部部件之间的联系,系统内部之间的联系,子系统之间的联系,一目了然。比如我们想追踪温度传感器的信号流,首先可以从模组框框图开始,temperature sensor 到 monitoring unit, monitoring unit 与外部的 internal communication交互信息,上一次的连接模组的 internal communication 与外界的 Junction box通过内部通讯交换信息Top level 的 junction box 与外界的整车控制器交互信息。

这篇文章里的Itemdefinition是针对高压电池包,我直接引用。BMS系统没有这么多子系统,但是在工作中发现,其实把高压系统的电气系统和BMS作为一个大系统,进行功能安全分析更全面,工作也更好展开。

(三):ASIL等级

a. ASIL等级

在第二篇中,进行了概念阶段的ite definition分析,item definition应当尽可能将系统的接口描述清楚。比如电池系统电压分类,高压线路的功率能力,CAN通信协议和其他信号的说明,信号电压电流范围,正常值等。

Item definition,不仅需要将系统的功能描述清楚,同时也要将item的失效模式描述清楚,这样才能清楚知道tiem应该是怎么样,而不应该出现某些哪些表现形式。在ISO26262-3中,Hazrad可以通过,brainstorm或者DFMEA等方法来确认,从整车级别分析这些危害会对车辆或者乘客造成的影响。这个阶段的DFMEA我们可以不用考虑造成这些危害的可能原因有哪些,在后面的DFEMA工作中可以具体来分析造成这些hardzard的可能原因。

在第二篇的中的item defintion中,分析了过一个A00级别汽车的电池包。如下图。

下表是根据上图HARA(Hazard Analysis and Risk Assessment)得到的。定义了93个功能和136个malfunction.

在该文章中选取了6个路况,subterranean garage, small streets, middle streets, large streets, highway and motorway,同时选取了23个常见的驾驶工况,常见的天气情况对场景的影响,最后得到了3128个可能性较大的危害事件。3128还是个非常大的数字,如果一条一条的分析,是个巨大的工作。文章中提高,他们团队有来不自不同部门的经验丰富的工程师有整车部门,电芯部门,pack部门,EE等,最后团队从这3128危害事件中选择了142个进行进一步分析。

下表是电池系统几个function与malfunction:

在定义好了malfunction后,就可以根据Risk definiton中的三个参数S(Severity),E( Exposure), C(Controllability)来确定危害的ASIL 等级了。下表是一个简单的电芯过放的HARA分析。在这个表格里面,在城市道路上发生电芯热失控导致车辆起火,定的ASIL Level是C;车辆在速度比较低的时候,定的ASIL Level是A。

下表是另外一个文章中过放的HRAR分析:

这两个表格中参数C(Controllability)很大程度上取决于驾驶员将车辆停靠在安全位置的速度,车速越快,车速越快驾驶员需要更多的时间找一个安全位置将电芯热失控的车辆安置好。这两个表格中第二行S/E/C的值都是一样,而ASIL LEVEL却不一样,纳尼???

有个很简单的公式来确定确定ASIL LEVEL。如果S+E+C的值小于7,那么ASIL LEVEL是A,详细如下表。所以第二个表格中的ASIL LEVEL应该C,文章的小瑕疵。

下表是一篇文章对一个高压电池包HARA分析后给出的Safety Goal.同上面两个对比,不同的公司或组织对相同的Malfunction给出的ASIL LEVEL是不同的,上面两个表格对过充的ASIL LEVEL是C,下表为D。

由Saftey Goal衍生出的安全目标应该考虑一下内容

· 运行模式

· 故障容错时间区间(间隔);或故障容错时间

· 安全状态

· 紧急操作时间区间

· 功能冗余(例如故障容错)

应为每一个安全目标定义至少一项功能安全要求,尽管一个功能安全要求能够cover不止一条安全目标,每一条FSR从相关SG继承最高的ASIL。然后将FSR分配给相关项。比如下表中的SG1定义了两个FSR。

在ISO26262-9中定义了ASIL分解,为了降低安全目标实施成本,可以将一个高ASIL安全目标分解成两个相互独立的低一级安全目标。拿文中的SG1-预防过放作为一个例子,在这里我们假设负载只有驱动电机,可以通过将SG1分解成两个独立的FSR。FSR1.2a:在x ms内断开高压回路,FSR1.2a:通过CAN报文请求负载将需求功率降低为0。

(四):技术安全要求导出

技术安全要求导出

图1说明了通过分层的方法,从危害分析和风险评估得出安全目标,再由安全目标得出功能安全要求。

图1 安全目标和功能安全要求层级

图2给出了ISO26262相应部分中的安全要求的结构和分布的说明。将功能安全要求分配给初步架构要素。

图2 安全要求的结构

技术安全要求(TSR)是对功能安全要求(FSR)提炼,细化了功能安全的概念,同时考虑功能性的概念和初步的体系架构。通过分析技术安全需要来验证符合功能安全需求。在整个开发生命周期,技术安全需求是要落实功能安全概念的技术要求,其用意是从细节的单级功能安全要求到系统级的安全技术要求。

技术安全要求应根据功能安全概念、相关项的初步架构设想和如下系统特性来定义:

a. 外部接口,如通讯和用户接口,如果适用;

b. 限制条件,例如环境条件或者功能限制;以及

c. 系统配置要求。

在第三篇文章中,从安全目标道出了BMS的一个功能安全要求,图3是对功能安全要求FSR1.2a导出的技术安全要求。

图3

系统设计

基于概念阶段的基本系统架构,功能安全概念,技术安全要求和非功能性要求,按照ISO26262的下一步流程就是系统设计了。在这个阶段,系统及子系统需要上面所定义的贯彻技术安全要求,需要反映前面定义的安全检测及安全机制。

技术安全要求的应分配给系统设计要素,同时系统设计应完成技术安全要求,关于技术安全要求的实现,在系统设计中应考虑如下问题:

a. 系统设计的可验证性

b. 软件硬件的技术实现性

c. 系统集成中的执行测试能力

系统和子系统架构应该满足各自ASIL 等级的技术安全需求,每个元素应实现最高的ASIL技术安全需求,如果一个系统包含的子系统有不同的ASIL 等级,或者是安全相关的子系统和非安全相关的子系统,那么这些系统应该以最高的ASIL等级来处理。

在系统设计阶段,为了避免系统系失效,ISO26262针对不同的ASIL等级推荐了不同的分析方法,如FMEA,FAT等。如表1。由于内因或者外因而引起系统失效应当避免或者消除。

表1

为减少系统性失效, 宜应用值得信赖的汽车系统设计原则. 这些原则可能包括:

a. 值得信赖的技术安全概念的再利用;

b. 值得信赖的要素设计的再利用, 包括硬件和软件组件;

c. 值得信赖的探测和控制失效的机制的再利用, 及

d. 值得信赖的或标准化接口的再利用。

为了确保值得信赖的设计原则或要素在新相关项中的适用性, 应分析其应用结果, 以及应在再利用之前检查其基本设想。

ASIL A、B、C、D 规定:为避免高复杂性带来的故障,架构设计应该根据表2 中的原则来展现下列的属性:模块化,层次化,简单化

基于上面定义的TSR和概念阶段定义的基本架构图,图4是精炼之后的BMS系统架构图。

图4

下一步是定义系统架构,分配TSR给硬件和软件,同时定义好软件硬件接口HIS。

软硬件接口规范应规定的硬件和软件的交互,并与技术安全的概念是一致的,应包括组件的硬件设备,是由软件和硬件资源控制支持软件运行的。软硬件接口规范应包括下面属性:

a. 硬件设备的工作模式和相关的配置参数, 硬件设备的操作模式,如:缺省模式,

b. 初始化,测试或高级模式, 配置参数,如:增益控制,带通频率或时钟分频器。

c. 确保单元之间的独立性和支持软件分区的硬件特性

d. 共享和专用硬件资源,如内存映射,寄存器,定时器,中断,I / O 端口的分配。

e. 硬件设备的获取机制,如串口,并口,从,主/从

f. 每个涉及技术安全概念的时序约束

硬件和其使用的软件的相关诊断功能应在软硬件接口规范中规定:

[文章纠错]

文章网友提供,仅供学习参考,版权为原作者所有,如侵犯到

你的权益请联系qchjl_admin@126.com,我们会及时处理。

会员评价:

0 发表评论

渝公网安备 50010802001066号

QQ|手机版|小黑屋|Archiver|汽车工程师之家 ( 渝ICP备18012993号-1 )

GMT+8, 29-3-2024 00:36 , Processed in 0.353774 second(s), 24 queries .

Powered by Discuz! X3.5

© 2001-2013 Comsenz Inc.