今天試圖整理動力鋰電池BMS功能安全開發流程相關資料，在驗證部分的資料不太充分，后面有機會再進行補充。

1、功能安全含義

功能安全：不存在由電子電氣系統的故障而引起的危害導致不合理的風險。因此，功能安全開發的首要任務是要防止不可接受的風險。BMS作為整車零部件，進行功能安全開發時一般由整車層面的SafetyGoal得到概念階段的FSR（Functionsafetyrequirements），再由概念階段的FSR分析出電子電氣層面的TSR（Technicalsafetyrequirements）,最后分析出BMS的軟件和硬件的功能安全需求。下圖是ISO26262開發過程示意圖。

2、概述

在ISO26262標準中，我們要區分兩類故障、錯誤和失效：隨機和系統性失效。系統性失效可以在設計階段通過合適的方法來防止，而隨機性失效只能降低到可接受程度。系統性甚至隨機性失效會發生在硬件當中，而軟件的失效更多的是系統性的失效。首先根據安全目標，確定安全等級。關于每個危害事件，根據其暴露概率E、可控性C、嚴重度S三要素，確定其ASIL等級。

依據ISO26262的開發流程，從需求開始，當中包括概念設計、系統設計、硬件設計、軟件設計，直至最后的生產公布、售后維護，都提出了相應的功能安全要求，其覆蓋了整個汽車的生命周期，從而保證汽車電子產品的功能安全可靠，即使功能失效也不會造成危險的發生。BMS作為新能源汽車的關鍵，對其功能要求越來越復雜，BMS必須具備電壓、電流、溫度等基本的采樣功能，同時對電池的運行過程實時監督，過壓、欠壓、過流、過溫等保護功能，同時SOP、SOC、SOH的預測，故障診斷、均衡控制、熱管理、快慢充管理等。把ISO26262標準要求，應用到BMS的開發中，將會大大提高BMS的安全性。

假如將BMS視為一個safetyelementoutofcontext（獨立安全單元），獨立安全單元的意思在在產品的開發周期內，暫時不考慮整車內其它要素（element）。根據主機廠供應的SaftetyGoal，BMS開發商供應商根據SatetyGoal導出SaftetyRequirements，接著是系統設計，硬件設計，軟件設計等。

而作為整車的一部分，整車上的一些功能會與電池系統發生相互用途，就要從相關項的角度考慮其用途的結果。

BMS依據汽車電子電氣的開發慣例，按照V模型的主體流程進行開發，主機廠會參與到V模型右邊的測試部分。

3、相關項含義

電池高壓系統重要由接線盒、模組、電池均衡連接器，高壓連接器模塊，BMS等組成。BMS通過傳感器采集電壓、溫度等數據進行處理，計算電池的SOC/SOH，故障診斷等。同時，通過整車CAN與VCU進行信息交互。進行相關項含義時，要分析電池系統組成部分，界定功能安全分析的范圍。下圖是電池系統結構和原理框圖。關于BMS所承接的功能安全目標，是在整車相關項層面得到的。在此基礎上，進行BMS產品的開發和驗證。

4、開發流程

首先確定危害事件。根據不同的工況、不同駕駛習慣過、天氣情況分析出可能性較大的危害事件，針對危害事件，分配到系統工作的各個職能部門。在ISO26262-3，Hazrad分析可以通過brainstorm、DFMEA等方法來確認。以單體過充危害事件為例，根據ASIL等級的三要素，確定危害事件的等級。下表是一個簡單的電芯過充的HARA分析。在這個表格里面，在城市道路上發生電芯熱失控導致車輛起火，定的ASILLevel是C；車輛在速度比較低的時候，定的ASILLevel是A。

羅列功能因故障失效的全部可能性：

匯總全部功能和故障，按照運行模式區分，形成危害事件的矩陣。通過危害分析和風險評估，界定危害事件的功能安全目標。合并不同場景下的同一個危害事件的安全等級，用最高的功能安全等級作為該危害事件的安全等級。為了防止危害事件的發生，進而形成安全目標。

可以從防止危害事件發生的角度考慮安全目標，也可以從防止故障發生的角度提出安全目標。例如：對過放導致內部短路電池起火這個危害提出安全目標，從防止危害發生的角度提出安全目標為防止過放導致短路電池起火，從防止故障的角度提出安全目標則為防止溫度限制發生故障。安全目標的ASIL等級則為危害事件的最高的等級。

安全目標的得出，衍生出一些安全相關的參數也要做規定，這些參數包括：運行模式，故障容錯時間，安全狀態，功能冗余等。

第二步，確定功能安全需求FSR，每一個安全目標含義至少一項功能安全要求，盡管一個功能安全要求能夠cover不止一條安全目標，每一條FSR從相關的SG繼承最高的ASIL。通過分層的方法，從風險評估和危害分析得出安全目標，再由安全目標得出功能安全要求。FSR的功能安全等級，自動繼承安全目標的最高等級。

第三步，由功能安全需求（FSR）提煉技術安全需求（TSR），在整個開發生命周期，技術安全需求是要落實功能安全概念的技術要求，其用意是從細節的單級功能安全要求到系統級的安全技術要求。下表為功能安全需求轉化成技術安全需求的栗子，僅供流程上的參考。

第四步，系統設計階段，系統及子系統要上面所含義的貫徹技術安全要求，要反映前面含義的安全檢測及安全機制。技術安全要求的應分配給系統設計要素，同時系統設計應完成技術安全要求，有關技術安全要求的實現，在系統設計中應考慮如下問題，含義系統架構，分配TSR到硬件和軟件，同時含義好軟件硬件接口HIS。軟硬件接口規范應規定的硬件和軟件的交互，并與技術安全的概念是一致的，應包括組件的硬件設備，是由軟件和硬件資源控制支持軟件運行的。

系統設計，標準中給出三個方面的原則：模塊化、適當的顆粒度和簡單。針對不同的安全等級，強調關注不同側面的設計考量。

技術安全要求，直接或者經過進一步細化后，分配給硬件和軟件。

系統設計完成后，還要考慮設計驗證。功能安全目標越高，越傾向于實物驗證的方式。

第五步，硬件系統功能安全設計。硬件的詳細安全需求來自于TSR，系統架構及系統邊界HSI。根據ISO26262-8章節6.4.2硬件安全需求規范應包括與安全相關的每一條硬件要求，硬件安全要求應按照ISO26262-8第6章和第9章的要求進行驗證，以供應證據證明。硬件設計可以硬件功能方塊圖開始，硬件方塊圖的所有的元素和內部接口應當展示出來。然后設計和驗證詳細的電路圖，最后通過演繹法（FTA）或者歸納法（FMEA）等方法來驗證硬件架構可能出現的故障。對BMS系統來講，電池包電壓傳感器是一個非常重要的傳感器，因此針對不同ASIL等級要分析電池包電壓傳感器不同的失效模式。一部分失效模式可以通過硬件的需求防范，一部分失效模式可以被分離為軟件需求去防范。

每個技術安全要求怎么樣設計，與實際產品功能、技術發展水平，供應商水平等密切相關，是不同廠家產品差異性的起點。而產品具體執行，有自己不同的思路，有的是不適用安全機制，直接要求零部件提高自身功能安全等級；有的則選擇新增監測機制或者供應不同原理的冗余設計，用以提高功能安全等級。

標準推薦的硬件設計驗證原則如下表：

第六步，軟件系統設計。在汽車行業軟件開發一般遵循V模型，左邊是開發過程，右邊對應的測試過程。BMS軟件開發流程，基本與ISO26262第六部分推薦的軟件開發流程V模型相吻合，如下圖所示。在軟件架構設計中，要重點考慮軟件的可維護性及可測試性。在汽車行業，軟件在整個產品周期內都應當考慮維護性，同時還要考慮軟件架構的設計測試的容易實現，在ISO26262標準中，測試是非常重要的一方面，任何設計都應該同時考慮到測試的方便性。至此，產品的設計開發環節已經全部完成。

標準推薦的軟件架構設計原則如下：

軟件架構層面標準推薦的錯誤處理機制如下：

標準推薦的軟件設計驗證方法如下表：

參考文獻

1、基于功能安全的BMS設計_韓豫萍

2、符合ISO_26262標準的安全完整性等級評估方法的研究_何波

3、基于ISO26262的BMS概念階段開發概述_田星

4、基于功能安全的BMS設計方法及其可靠性的研究_印凱

5、GB∕T34590.3-2017道路車輛功能安全第3部分：概念階段

6、GB∕T34590.4-2017道路車輛功能安全第4部分：產品開發：系統層面

7、GB∕T34590.5-2017道路車輛功能安全第5部分：產品開發：硬件層面

8、GB∕T34590.6-2017道路車輛功能安全第6部分：產品開發：軟件層面