點擊上面 “電動知家”可以訂閱哦！

BMS功能安全開發流程詳解

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等級 -?ISO26262在BMS開發中的應用

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作為一個大系統，進行功能安全分析更全面，工作也更好展開。

在第二篇中，進行了概念階段的ite definition分析，item definition應當盡可能將系統的接口描述清楚。比如電池系統電壓分類，高壓線路的功率能力，CAN通信協議和其他信號的說明，信號電壓電流范圍，正常值等。

Item definition,不僅需要將系統的功能描述清楚，同時也要將item的失效模式描述清楚，這樣才能清楚知道tiem應該是怎么樣，而不應該出現某些哪些表現形式。在ISO26262-3中，Hazrad可以通過，brainstorm或者DFMEA等方法來確認，從整車級別分析這些危害會對車輛或者乘客造成的影響。這個階段的DFMEA我們可以不用考慮造成這些危害的可能原因有哪些，在后面的DFEMA工作中可以具體來分析造成這些hardzard的可能原因。

下表是根據上圖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個進行進一步分析。

在定義好了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。

技術安全要求導出

在第三篇中介紹了功能安全概念的目的是從安全目標(SR)中得出功能安全要求(FSR)，并將其分配給相關項的初步架構要素或外部措施。

技術安全要求導出

圖1說明了通過分層的方法，從危害分析和風險評估得出安全目標，再由安全目標得出功能安全要求。

圖1 安全目標和功能安全要求層級

圖2給出了ISO26262相應部分中的安全要求的結構和分布的說明。將功能安全要求分配給初步架構要素。

圖2 安全要求的結構

技術安全要求(TSR)是對功能安全要求(FSR)提煉，細化了功能安全的概念，同時考慮功能性的概念和初步的體系架構。通過分析技術安全需要來驗證符合功能安全需求。在整個開發生命周期，技術安全需求是要落實功能安全概念的技術要求，其用意是從細節的單級功能安全要求到系統級的安全技術要求。

技術安全要求應根據功能安全概念、相關項的初步架構設想和如下系統特性來定義：

a. 外部接口，如通訊和用戶接口，如果適用；

b. 限制條件，例如環境條件或者功能限制；以及

c. 系統配置要求。

系統設計

基于概念階段的基本系統架構，功能安全概念，技術安全要求和非功能性要求，按照ISO26262的下一步流程就是系統設計了。在這個階段，系統及子系統需要上面所定義的貫徹技術安全要求，需要反映前面定義的安全檢測及安全機制。

技術安全要求的應分配給系統設計要素，同時系統設計應完成技術安全要求，關于技術安全要求的實現，在系統設計中應考慮如下問題：

a. 系統設計的可驗證性

b. 軟件硬件的技術實現性

c. 系統集成中的執行測試能力

系統和子系統架構應該滿足各自ASIL 等級的技術安全需求，每個元素應實現最高的ASIL技術安全需求，如果一個系統包含的子系統有不同的ASIL 等級，或者是安全相關的子系統和非安全相關的子系統，那么這些系統應該以最高的ASIL等級來處理。

在系統設計階段，為了避免系統系失效，ISO26262針對不同的ASIL等級推薦了不同的分析方法，如FMEA,FAT等。如表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. 每個涉及技術安全概念的時序約束

硬件和其使用的軟件的相關診斷功能應在軟硬件接口規范中規定：

a. 硬件診斷功能應定義，例，檢測過流，短路或過熱

b. 在軟件中實現的硬件診斷功能

軟硬件接口規范在系統設計時制定，在硬件開發和軟件開發時被進一步細化。應使用表3列出的方法驗證系統設計對于技術安全概念的符合性和完備性。

硬件系統功能安全設計

硬件的詳細安全需求來自于TSR，系統架構及系統邊界HSI。

硬件系統功能安全設計

根據ISO 26262-8章節6.4.2 硬件安全需求規范應包括與安全相關的每一條硬件要求，包括以下：

a. 為控制要素硬件內部失效的安全機制的硬件安全要求和相關屬性，這包括用來覆蓋相關瞬態故障(例如，由于所使用的技術而產生的瞬態故障)的內部安全機制；

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 電池包電壓傳感器常見失效模式及覆蓋度

ISO26262推薦用兩個可選的方法以評估違背安全目標的殘余風險是否足夠低。

兩個方法都評估由單點故障、殘余故障和可能的雙點故障導致的違背安全目標的殘余風險。如果顯示為與安全概念相關，也可考慮多點故障。在分析中，對殘余和雙點故障，將考慮安全機制的覆蓋率，并且，對雙點故障也將考慮暴露持續時間。

第一個方法包括使用概率的度量，即“隨機硬件失效概率度量”(probabilisticmetric for random hardware failures-PMHF)，通過使用例如定量故障樹分析(FTA)或者(Failure Mode Effects and Diagnostic Analysis - FMEDA)及將此計算結果與目標值相比較的方法，評估是否違背所考慮的安全目標。

第二個方法包括獨立的評估每個殘余和單點故障，及每個雙點失效是否導致違背所考慮的安全目標。此分析方法也可被考慮為割集分析。在文章[1]中選用第二種方法來驗證BMS均衡電路的隨機失效，單點失效等。

在前面幾章分析過從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標準中引入了失效率等級。硬件元器件失效率的失效率等級評級應按如下確定：

a. 失效率等級1 對應的失效率應少于ASILD 的目標除以100(見表3)

b. 失效率等級2 對應的失效率應少于或等于10倍的失效率等級1 對應的失效率(見表4)

表4 失效率等級

如果單點失效違背ASILC的安全目標，那個對應的合適的失效率等級為FRC 1或者有其他額外測量的FRC2

采樣均衡電路的失效可能會導致電芯過充，進一步引起熱失控。因此根據SafetyGoal推導出的安全要求如圖2。

圖2 功能安全要求

這是安全目標所導出想系統的TSR，需要從中分離出單獨跟硬件相關的或者和軟件硬件都相關的TSR，因此硬件的TSR為：

· Overcharge condition shall be detectedwithin Y ms and,

· Current to the battery shall beinterrupted within Z ms.

· 根據上面的分析有兩條TSR分配給了硬件系統。在文檔[1]中歸納總結了安全目標的安全機制，見表5：

表5 分配給硬件的過充保護安全機制

· 實施安全機制中需要用到的硬件元器件預估失效率(failurein time- FIT)。用于確定硬件元器件失效率和失效模式分布的業界公認的來源包括IEC/TR62380, IEC 61709, MIL HDBK 217 F notice 2, RIAC HDBK 217 Plus, UTE C80-811,NPRD 95, EN 50129:2003, Annex C, IEC 2061:2005, Annex D, RIAC FMD97 和 MIL HDBK 338。文章[1]中選取數據庫MILHDBK 217和芯片供應商所提供的數據來評估安全機制。

· 文章[1]中采用AFEBQ2931(TI)作為過充二級保護芯片，表是對過充保護的安全機制的評估。從下表格可以看出，安全目標的失效模式覆蓋率為99%，針對不同的與之安全相關的部件。

表6 安全機制評估

· 一旦完成硬件架構的設計和樣件設計，與之對應的不同的元素，系統集成測試也應該定義好。在ISO26262-8中，針對不同的ASIL等級推薦了不同的測試方法。

電池管理系統(BMS)為什么那么重要？年薪可達百萬！

吉利剛上市首款轎跑SUV星越，剛提車就起火！

中國燃油車全面禁售時間表發布！

吉利降薪了？NO，人家漲薪了！

感人！假如你那一位是從事新能源汽車行業的······

?重磅！清華大學撤銷汽車工程系建制

東風董事長：中國汽車制造水平世界第一，你怎么看？

做好BMS？你必須懂得這些知識！

欠薪、欺騙、造假、不誠信，華泰汽車還能撐多久？！

極度困難！又一家新能源企業倒下！

電動知家，一個有價值的微信公眾號！

更多新能源電動汽車、無人駕駛最新行業資訊和專業知識，請關注“電動知家”微信公眾號(微信號ev_home)。

---

總結

以上是生活随笔為你收集整理的杂志订阅管理系统c++_电池管理系统BMS功能安全开发流程详解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。