BMS功能安全开发流程详解

精品文档 1欢迎下载 BMS 功能安全开发流程详解 2017 11 01 一 一 BMSBMS 和和 ISO26262ISO26262 最近在了解学习关于 ISO26262 看了一些文章 本身从事 BMS 相关的工作 想做一个关于 BMS 功能安全开发流程的笔记 分三篇文章 第一篇是关于 BMS 和 ISO26262 的简介 BMSBMS ISO26262ISO26262 简介简介 BMS 即 Battery Management System 电池管理系统 作为新能源汽车 三 电 核心技术之一 BMS 在新能源车上扮演十分重要的作用 按照新能源汽车对 电池管理的需求 BMS 具备的功能包括电压 温度 电流采样及相应的过压 欠 压 过温 过流保护 SOC SOH 估算 SOP 预测 故障诊断 均衡控制 热管理 和充电管理等 为了保证汽车电子电气的可靠性设计 在 2011 年发布了 IS0 26262 道路 车辆功能安全标准 IS0 26262 标准是源于工业功能安全标准 IEC61508 1 目前许多汽车企业和零部件企业在控制器开发过程中采用 ISO26262 这个标准 ISO26262 包括了汽车电子电气开发中与安全相关的所有应用 制定了汽车整个 生命周期中与安全相关的所有活动 ISO 26262 从需求开始 当中包括概念设 计 软硬件设计 直至最后的生产 操作 都提出了相应的功能安全要求 其 覆盖了汽车整个生命周期 从而保证安全相关的电子产品的功能性失效不会造 成危险的发生 如下图所示 精品文档 2欢迎下载 1 1 范围及相关项范围及相关项 ISO26262 适用于最大总质量不超过 3 5 吨的量产成用车上的包含一个或多 个电子电气系统的与安全相关的系统 在这部分 ISO26262 和 FMEA 还是比较相 似的 第一步是确定 Scope 那些是研究范围之内的 对高压电池系统而言 ISO26262 适用于电池包电气系统及 BMS 系统 而不适用于电池包的电芯及机械 结构件等 精品文档 3欢迎下载 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 错误 计算的 观测的 测量的值或条件与真实的 规定的 理 论上正确的值或条件之间的差异 精品文档 4欢迎下载 Failure 失效 要素按要求执行功能的能力的终止 基于上面的定义 他们之间存在一定的因果关系 故障会产生错误 而错 误会引起功能或者系统的失效 如果下图 在 ISO26262 标准中 我们要区分两类故障 错误和失效 随机和系统性失 效 系统性失效可以在设计阶段通过合适的方法来避免 而随机性失效只能降 低到可接受程度 系统性甚至随机性失效会发生在硬件当中 而软件的失效更 多的是系统性的失效 失效同时还可以分为单点失效和多点失效 单点失效 要素中没有被安全机制所覆盖 并且直接导致违背安全目标的 故障 多点失效 由几个独立的故障组合引发 直接导致违背安全目标的失效 在多点失效中有个特别的失效叫双点失效 由两个独立故障组合引起的 直接导致违背安全目标的失效 故障发生的时间关系如下图所示 精品文档 5欢迎下载 诊断测试时间间隔 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 的概率等级 精品文档 6欢迎下载 b 对于每一个危害事件 应基于一个确定的理由预估驾驶员或其他潜在 处于风险的人员对该危害事件的可控性 按照下表 应为可控性指定一个 C0 C1 C2 或 C3 的可控性等级 c 对于每一个危害事件 应基于一个已确定的理由来预估潜在伤害的严 重度 根据下表 应为严重度指定一个 S0 S1 S2 或 S3 的严重度等级 d 每一个危害事件的 ASIL 等级应使用 严重度 暴露概率 和 可控性 这三个参数根据下表来确定 精品文档 7欢迎下载 由于 BMS 属于新能源汽车高压电池系统的一部分 EUCAR 定义了高压电池 系统的危害等级 当 BMS 不能够很好的监测或者保护电芯时 上表中的危害事件就有可能发 生 ISO26262 的目标是保护乘客受到危害 因为上表 Level 5 以上就算是严重 危害事件了 因此有必要定义一个电芯工作的最大允许危害级别 5 以上时肯 定不允许的 二 二 ASILASIL 等级等级 精品文档 8欢迎下载 BMS 和功能安全作为当下新能源的两个当红炸子鸡实在是绕不开的话题 蹭个热点 继续聊聊 ISO26262 在 BMS 开发中的应用 1 1 相关项定义 相关项定义 ASILASIL 等级 安全目标等级 安全目标 如下图所示 第一步通过不同的驾驶情况 不同的环境来确定不同的场景 第二步分析不同场景下的事故所以引起的 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 精品文档 9欢迎下载 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 电池包 精品文档 10欢迎下载 a Preliminary architecture of the hypothetical Li ion battery system b Key elements and signals within the energy storage system 点画线表示高压电池系统的边界线 高压系统的与外界的交互信号分成了 下表中的七大类 上面定义了不同类的子系统 下面这张图是上图中 connected modules 连接模组的框框图 精品文档 11欢迎下载 下面这张图是上面连接模组的进一步分解的模组框框图及信号流 精品文档 12欢迎下载 这样一层一层像剥洋葱一样分解系统 很方便追溯所有信号来源 系统与 其他外部部件之间的联系 系统内部之间的联系 子系统之间的联系 一目了 然 比如我们想追踪温度传感器的信号流 首先可以从模组框框图开始 temperature sensor 到 monitoring unit monitoring unit 与外部的 internal communication 交互信息 上一次的连接模组的 internal communication 与外界的 Junction box 通过内部通讯交换信息 Top level 的 junction box 与外界的整车控制器交互信息 这篇文章里的 Itemdefinition 是针对高压电池包 我直接引用 BMS 系统 没有这么多子系统 但是在工作中发现 其实把高压系统的电气系统和 BMS 作 为一个大系统 进行功能安全分析更全面 工作也更好展开 a ASIL 等级 在第二篇中 进行了概念阶段的 ite definition 分析 item definition 应当尽可能将系统的接口描述清楚 比如电池系统电压分类 高压线路的功率 能力 CAN 通信协议和其他信号的说明 信号电压电流范围 正常值等 精品文档 13欢迎下载 Item definition 不仅需要将系统的功能描述清楚 同时也要将 item 的失 效模式描述清楚 这样才能清楚知道 tiem 应该是怎么样 而不应该出现某些哪 些表现形式 在 ISO26262 3 中 Hazrad 可以通过 brainstorm 或者 DFMEA 等 方法来确认 从整车级别分析这些危害会对车辆或者乘客造成的影响 这个阶 段的 DFMEA 我们可以不用考虑造成这些危害的可能原因有哪些 在后面的 DFEMA 工作中可以具体来分析造成这些 hardzard 的可能原因 在第二篇的中的 item defintion 中 分析了过一个 A00 级别汽车的电池包 如下图 下表是根据上图 HARA Hazard Analysis and Risk Assessment 得到的 定义了 93 个功能和 136 个 malfunction 精品文档 14欢迎下载 在该文章中选取了 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 等级了 精品文档 15欢迎下载 下表是一个简单的电芯过放的 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 精品文档 16欢迎下载 由 Saftey Goal 衍生出的安全目标应该考虑一下内容 运行模式 故障容错时间区间 间隔 或故障容错时间 安全状态 紧急操作时间区间 功能冗余 例如故障容错 应为每一个安全目标定义至少一项功能安全要求 尽管一个功能安全要求 能够 cover 不止一条安全目标 每一条 FSR 从相关 SG 继承最高的 ASIL 然后 将 FSR 分配给相关项 比如下表中的 SG1 定义了两个 FSR 精品文档 17欢迎下载 在 ISO26262 9 中定义了 ASIL 分解 为了降低安全目标实施成本 可以将 一个高 ASIL 安全目标分解成两个相互独立的低一级安全目标 拿文中的 SG1 预防过放作为一个例子 在这里我们假设负载只有驱动电机 可以通过将 SG1 分解成两个独立的 FSR FSR1 2a 在 x ms 内断开高压回路 FSR1 2a 通过 CAN 报文请求负载将需求功率降低为 0 精品文档 18欢迎下载 四 技术安全要求导出 四 技术安全要求导出 在第三篇中介绍了功能安全概念的目的是从安全目标 SR 中得出功能安 全要求 FSR 并将其分配给相关项的初步架构要素或外部措施 技术安全要求导出技术安全要求导出 图 1 说明了通过分层的方法 从危害分析和风险评估得出安全目标 再由 安全目标得出功能安全要求 精品文档 19欢迎下载 图 1 安全目标和功能安全要求层级 图 2 给出了 ISO26262 相应部分中的安全要求的结构和分布的说明 将功能 安全要求分配给初步架构要素 精品文档 20欢迎下载 图 2 安全要求的结构 技术安全要求 TSR 是对功能安全要求 FSR 提炼 细化了功能安全的 概念 同时考虑功能性的概念和初步的体系架构 通过分析技术安全需要来验 证符合功能安全需求 在整个开发生命周期 技术安全需求是要落实功能安全 概念的技术要求 其用意是从细节的单级功能安全要求到系统级的安全技术要 求 技术安全要求应根据功能安全概念 相关项的初步架构设想和如下系统特 性来定义 a 外部接口 如通讯和用户接口 如果适用 精品文档 21欢迎下载 b 限制条件 例如环境条件或者功能限制 以及 c 系统配置要求 在第三篇文章中 从安全目标道出了 BMS 的一个功能安全要求 图 3 是对 功能安全要求 FSR1 2a 导出的技术安全要求 图 3 系统设计系统设计 基于概念阶段的基本系统架构 功能安全概念 技术安全要求和非功能性 要求 按照 ISO26262 的下一步流程就是系统设计了 在这个阶段 系统及子系 统需要上面所定义的贯彻技术安全要求 需要反映前面定义的安全检测及安全 机制 技术安全要求的应分配给系统设计要素 同时系统设计应完成技术安全要 求 关于技术安全要求的实现 在系统设计中应考虑如下问题 a 系统设计的可验证性 精品文档 22欢迎下载 b 软件硬件的技术实现性 c 系统集成中的执行测试能力 系统和子系统架构应该满足各自 ASIL 等级的技术安全需求 每个元素应 实现最高的 ASIL 技术安全需求 如果一个系统包含的子系统有不同的 ASIL 等 级 或者是安全相关的子系统和非安全相关的子系统 那么这些系统应该以最 高的 ASIL 等级来处理 在系统设计阶段 为了避免系统系失效 ISO26262 针对不同的 ASIL 等级 推荐了不同的分析方法 如 FMEA FAT 等 如表 1 由于内因或者外因而引起系 统失效应当避免或者消除 表 1 为减少系统性失效 宜应用值得信赖的汽车系统设计原则 这些原则可能 包括 a 值得信赖的技术安全概念的再利用 b 值得信赖的要素设计的再利用 包括硬件和软件组件 c 值得信赖的探测和控制失效的机制的再利用 及 d 值得信赖的或标准化接口的再利用 为了确保值得信赖的设计原则或要素在新相关项中的适用性 应分析其应 用结果 以及应在再利用之前检查其基本设想 ASIL A B C D 规定 为避免高复杂性带来的故障 架构设计应该根据 表 2 中的原则来展现下列的属性 模块化 层次化 简单化 精品文档 23欢迎下载 基于上面定义的 TSR 和概念阶段定义的基本架构图 图 4 是精炼之后的 BMS 系统架构图 图 4 下一步是定义系统架构 分配 TSR 给硬件和软件 同时定义好软件硬件接 口 HIS 精品文档 24欢迎下载 软硬件接口规范应规定的硬件和软件的交互 并与技术安全的概念是一致 的 应包括组件的硬件设备 是由软件和硬件资源控制支持软件运行的 软硬 件接口规范应包括下面属性 a 硬件设备的工作模式和相关的配置参数 硬件设备的操作模式 如 缺省模式 b 初始化 测试或高级模式 配置参数 如 增益控制 带通频率或 时钟分频器 c 确保单元之间的独立性和支持软件分区的硬件特性 d 共享和专用硬件资源 如内存映射 寄存器 定时器 中断 I O 端口的分配 e 硬件设备的获取机制 如串口 并口 从 主 从 f 每个涉及技术安全概念的时序约束 硬件和其使用的软件的相关诊断功能应在软硬件接口规范中规定 a 硬件诊断功能应定义 例 检测过流 短路或过热 b 在软件中实现的硬件诊断功能 软硬件接口规范在系统设计时制定 在硬件开发和软件开发时被进一步细 化 应使用表 3 列出的方法验证系统设计对于技术安全概念的符合性和完备性 五 硬件系统功能安全设计 五 硬件系统功能安全设计 硬件的详细安全需求来自于 TSR 系统架构及系统边界 HSI 硬件系统功能安全设计硬件系统功能安全设计 根据 ISO 26262 8 章节 6 4 2 硬件安全需求规范应包括与安全相关的每一 条硬件要求 包括以下 a 为控制要素硬件内部失效的安全机制的硬件安全要求和相关属性 这 包括用来覆盖相关瞬态故障 例如 由于所使用的技术而产生的瞬态故障 的内 部安全机制 精品文档 25欢迎下载 b 为确保要素对外部失效容错的硬件安全要求和安全机制的相关属性 c 为符合其它要素的安全要求的硬件安全要求和安全机制的相关属性 d 为探测内外部失效和发送失效信息的硬件安全要求及安全机制的相关 属性 及 e 没有定义安全机制的硬件安全要求 硬件安全要求应按照 ISO26262 8 第 6 章和第 9 章的要求进行验证 以提供 证据证明 硬件设计可以硬件功能方块图开始 硬件方块图的所有的元素和内 部接口应当展示出来 然后设计和验证详细的电路图 最后通过演绎法 FTA 或者归纳法 FMEA 等方法来验证硬件架构可能出现的故障 对系统设计来讲最大的挑战是满足 ISO26262 硬件架构度量 针对 ASIL C 或 D ISO26262 强烈推荐计算单失效和潜在失效概率 具体计算法见 ISO26262 8 附件 针对单点故障 SPF single point faults 被称为单点故障 度量 single pointfault metric SPFM 针对潜在失效故障 被称为潜在故 障度量 latent faultmetric LFM 对于每一个安全目标 由 ISO26262 要 求的 潜伏故障度量 的定量目标值应基于下列参考目标值 表 1 SPFM 和 LFM 推荐值 对 BMS 系统来讲 电池包电压传感器是一个非常重要的传感器 因此针对 不同的 ASIL 等级需要分析电池包电压传感器不同的失效模式 下表是不同的 ASIL 级别所需要覆盖到失效模式 表 2 电池包电压传感器常见失效模式及覆盖度 精品文档 26欢迎下载 ISO26262 推荐用两个可选的方法以评估违背安全目标的残余风险是否足够 低 两个方法都评估由单点故障 残余故障和可能的双点故障导致的违背安全 目标的残余风险 如果显示为与安全概念相关 也可考虑多点故障 在分析中 对残余和双点故障 将考虑安全机制的覆盖率 并且 对双点故障也将考虑暴 露持续时间 第一个方法包括使用概率的度量 即 随机硬件失效概率度量 probabilisticmetric for random hardware failures PMHF 通过使用例 如定量故障树分析 FTA 或者 Failure Mode Effects and Diagnostic Analysis FMEDA 及将此计算结果与目标值相比较的方法 评估是否违背所考 虑的安全目标 第二个方法包括独立的评估每个残余和单点故障 及每个双点失效是否导 致违背所考虑的安全目标 此分析方法也可被考虑为割集分析 推荐的随机失 效目标值如下表 3 在文章 1 中选用第二种方法来验证 BMS 均衡电路的随机失 效 单点失效等 表 3 随机失效目标值 精品文档 27欢迎下载 在前面几章分析过从 HARA 分析得到 Safe Goal 从 Safe Goal 推导出 FSR 从 FSR 推导出 TSR 并以 BMS 的过充作为例子进行了详细的介绍 文章 1 选 取了 TI 公司的 BQ20Z80 芯片 监控四个 cell 电压 管理均衡 图 1 是电路原 图 表示看不清 可以看参考文献 2 的高清大图 该电路的核心元器件是 ICBQ20Z80 BQ2940 是过充二级保护芯片 文章针对过充保护功能 选择方法 2 展开对安全目标 Battery overcharging shallbe prevented 的随机失效失 效评估 该方法不仅考虑到错误发生的可能性同时还考虑到安全机制的有效性 文章评估了芯片 BQ2940 及采样芯片 BQ2931 图 1 电芯电压采样均衡架构图 ISO 26262 标准中引入了失效率等级 硬件元器件失效率的失效率等级评 级应按如下确定 精品文档 28欢迎下载 a 失效率等级 1 对应的失效率应少于 ASILD 的目标除以 100 见表 3 b 失效率等级 2 对应的失效率应少于或等于 10 倍的失效率等级 1 对应 的失效率 见表 4 表 4 失效率等级 如果单点失效违背 ASILC 的安全目标 那个对应的合适的失效率等级为 FRC 1 或者有其他额外测量的 FRC2 采样均衡电路的失效可能会导致电芯过