动力电池bms功能安全开发过程包括哪些内容

描述

1.功能安全的定义

不存在因电气和电子系统故障而引起的不合理危险。因此,功能安全开发的首要任务是避免不可接受的风险。BMS作为车辆零部件,在开发功能安全时,一般在概念阶段从车辆层面的安全目标获得FSR(功能安全要求)。然后在概念阶段从FSR分析电气和电子层面的TSR(技术安全要求)。最后,分析裸金属服务器软硬件的功能安全要求。

概述

在ISO26262标准中,我们需要区分两种类型的故障和错误:随机故障和系统故障。在设计阶段可以通过适当的方法避免系统故障,而随机故障只能减少到可接受的水平。硬件上会发生系统性甚至随机故障,而软件故障则是更多的系统性故障。首先,根据安全目标,确定安全等级。对于每个危险事件,根据暴露概率E、可控性 C 和严重性 S 三个要素确定其 ASIL 级别。

根据ISO26262的发展流程,从需求出发,包括概念设计、系统设计、硬件设计、软件设计,直至最终的生产发布和售后维护,提出相应的功能安全要求。它覆盖了汽车的整个生命周期,从而保证了汽车电子产品功能的安全性和可靠性,即使功能出现故障,也不会造成危险。作为新能源汽车的关键,BMS的功能要求越来越复杂。BMS必须具有基本的采样功能,例如电压,电流和温度。同时,它可以实时监控电池的运行情况,并提供过压、欠压、过流、过温等保护功能。以及SOP、SOC、SOH、故障诊断、平衡控制、热管理、快慢充电管理等预测。将ISO26262标准的要求应用于BMS的开发,将大大提高BMS的安全性。

动力电池

ISO26262质量管理体系认证

如果将BMS视为脱离上下文的安全元件(独立安全单元),则独立安全单元的含义是在产品开发周期中暂时不考虑车辆中的其他元素。根据主机厂提供的安全目标,BMS开发商和供应商根据安全目标推导出安全要求,其次是系统设计、硬件设计、软件设计等。作为整车的一部分,整车上的一些功能会与电池系统相互作用,必须从相关项目的角度考虑其效果的结果。BMS是根据汽车电子的开发实践和V型的主要工艺开发的,主机厂将参与V车型右侧的测试部分。

3.相关术语定义

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

动力电池

车辆边界

4.开发过程从识别危险事件开始

根据不同的工况、不同的驾驶习惯、天气状况,分析大概率的危险事件,并将危险事件分配给系统的各个职能部门。在ISO26262-3中,Hazrad分析可以通过头脑风暴,DFMEA和其他方法进行确认。以单体电池过充电的危险事件为例,根据ASIL级别的三个要素确定危险事件的等级。下表是对电池过充电的简单HARA分析。在此表中,如果电池单元的热失控导致车辆在城市道路上着火,则
ASIL 级别设置为 C;当车辆处于相对较低的速度时,ASIL级别设置为A。 列出由于故障而导致功能故障的所有可能性;

动力电池

汇总所有功能和故障,根据运行模式进行区分,形成危险事件矩阵。通过危害分析和风险评估,定义危险事件的功能安全目标。结合同一危险事件在不同场景下的安全等级,用最高功能安全等级作为危险事件的安全等级。以避免危险事件的发生,进而形成安全目标。

可以从避免危险事件的角度考虑安全目标,也可以从避免故障的角度提出安全目标。例如,针对过放电引起的电池内部短路火灾的危险,提出了安全目标。从避免危险的角度提出安全目标,防止过放电引起的电池短路起火,从避免失效避免温度极限失效的角度提出安全目标。安全目标的ASIL级别是危险事件的最高级别。安全目标的推导,推导出的一些安全相关参数也需要指定,这些参数包括:工作模式、容错时间、安全状态、功能冗余、

动力电池

第二步是确定FSR的功能安全要求。每个安全目标至少定义一个功能安全要求。尽管功能安全要求可以涵盖多个安全目标,但每个 FSR 都从相关 SG
继承了最高的 ASIL。通过分层方法,安全目标来自风险评估和危害分析,功能安全要求来自安全目标。FSR 的功能安全级别自动继承安全目标的最高级别。

描述:为了防止电池因过放电引起的内部短路而着火,检测到过放电时应切断电流

5.从功能安全要求(FSR)中提取技术安全要求(TSR)

纵观整个开发生命周期,技术安全要求是落实功能安全概念的技术要求,其意图是从详细的单级功能安全要求走向系统级安全技术要求。下表是将功能安全要求转换为技术安全要求的栗子,仅供工艺参考。

动力电池

开发生命周期

第四步是系统设计阶段。系统和子系统需要实现上述技术安全要求,并需要反映上述定义的安全检测和安全机制。应将技术安全要求分配给系统设计要素,系统设计应完成技术安全要求。关于技术安全要求的实现,在系统设计中应考虑以下问题,定义系统架构,为硬件和软件分配TSR,同时定义软硬件接口HIS。硬件和软件接口规范应明确硬件和软件之间的交互,并与技术安全的概念保持一致,并应包括硬件设备的组件,这些组件由软件和硬件资源控制,以支持软件的运行。系统设计,标准中给出了三个原则:模块化、适当粒度和简单性。对于不同的安全级别,它强调不同方面的设计考虑。

5.硬件系统功能安全设计

硬件的详细安全要求来自TSR、系统架构和系统边界HSI。根据ISO
6-4硬件安全要求第2.26262.8章规范应包括所有与安全相关的硬件要求,硬件安全要求应按照ISO6-9第26262章和第8章的要求进行验证,以提供证据。硬件设计可以从硬件功能框图开始,并应显示硬件框图的所有元素和内部接口。然后设计并验证详细的电路图,最后通过演绎法(FTA)或电感法(FMEA)等方法验证硬件架构可能存在的故障。对于BMS系统来说,电池组电压传感器是非常重要的传感器,因此需要针对不同的ASIL水平分析电池组电压传感器的不同故障模式。有些故障模式可以通过硬件需求来预防,有些故障模式可以分为软件需求来预防。

如何设计每个技术安全要求与实际产品功能、技术开发水平、供应商水平等密切相关,是不同厂家产品差异化的出发点。产品的具体实现有其各有各的思路,有的不应用安全机制,直接要求元器件提高自身功能安全等级;有些选择增加监控机制或提供具有不同原则的冗余设计,以提高功能安全水平。

7.软件系统设计

汽车行业的软件开发一般遵循V模型,左侧是开发过程,右侧是相应的测试过程。BMS软件开发流程与ISO26262第六部分推荐的软件开发流程V模式基本吻合,如下图所示。在软件架构设计中,需要关注软件的可维护性和可测试性。在汽车行业,软件应该考虑整个产品周期的可维护性,同时考虑软件架构的设计和测试的难易程度。在ISO
26262标准中,测试是一个非常重要的方面,任何设计也应考虑测试的便利性。至此,该产品的设计开发工作已经完成。

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

方法

ASIL 水平

软件组件的层次结构

限制软件组件的大小

限制接口的大小

每个组件内的高内聚力

软件组件之间的低耦合

正确调度的属性

限制中断的使用

方法1b中的“有限”,lc le和1g表示最低水平,与其他设计考虑因素相平衡

例如,方法1d和le可以通过分离关注点来实现,这些关注点表示识别,打包和操作与特定想法,目标,任务或目的相关的软件部分的能力。

方法 1e 对软件组件外部耦合的限制 使用的任何中断都应基于优先级

软件架构级别标准推荐的错误处理机制如下:

静态恢复机制

适度降级

独立并行冗余

数据纠错码

静态恢复机制可能包括使用恢复块进行恢复、向后恢复、正向恢复和从备份恢复。

软件级别的适度降级是指对不同功能进行优先级排序,以尽量减少潜在故障对功能安全的不利影响。

独立的并行冗余可以通过每个并行路径中的不同软件来实现。

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分