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 對軟件組件外部耦合的限制 使用的任何中斷都應基于優先級

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

靜態恢復機制

適度降級

獨立并行冗余

數據糾錯碼

靜態恢復機制可能包括使用恢復塊進行恢復、向后恢復、正向恢復和從備份恢復。

軟件級別的適度降級是指對不同功能進行優先級排序，以盡量減少潛在故障對功能安全的不利影響。

獨立的并行冗余可以通過每個并行路徑中的不同軟件來實現。