中國電動車產業鏈商業報道全媒體平臺

首頁>BMS

BMS功能安全開發流程詳解

2018-05-23 · 來源: 129Lab 關注度:200460 次
分享到:
BMS
摘要:BMS即Battery Management System,電池管理系統。作為新能源汽車“三電”核心技術之一,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從需求開始,當中包括概念設計、軟硬件設計,直至最后的生產、操作,都提出了相應的功能安全要求,其覆蓋了汽車整個生命周期,從而保證安全相關的電子產品的功能性失效不會造成危險的發生。如下圖所示:

blob.png

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開發途徑。

blob.png

2)Fault, Errors and Failures Definitions

Fault(故障):可引起要素或相關項失效的異常情況

Errors (錯誤):計算的、觀測的、測量的值或條件與真實的、規定的、理論上正確的值或條件之間的差異

Failure(失效):要素按要求執行功能的能力的終止

基于上面的定義,他們之間存在一定的因果關系,故障會產生錯誤,而錯誤會引起功能或者系統的失效,如下圖。

blob.png

在ISO26262標準中,我們要區分兩類故障、錯誤和失效:隨機和系統性失效。系統性失效可以在設計階段通過合適的方法來避免,而隨機性失效只能降低到可接受程度。系統性甚至隨機性失效會發生在硬件當中,而軟件的失效更多的是系統性的失效。

失效同時還可以分為單點失效和多點失效。

單點失效:要素中沒有被安全機制所覆蓋,并且直接導致違背安全目標的故障

多點失效:由幾個獨立的故障組合引發,直接導致違背安全目標的失效。

在多點失效中有個特別的失效叫雙點失效。由兩個獨立故障組合引起的,直接導致違背安全目標的失效。

故障發生的時間關系如下圖所示:

blob.png

診斷測試時間間隔(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的概率等級。

blob.png

b. 對于每一個危害事件,應基于一個確定的理由預估駕駛員或其他潛在處于風險的人員對該危害事件的可控性。按照下表,應為可控性指定一個C0、C1、C2或C3的可控性等級。

blob.png

c. 對于每一個危害事件,應基于一個已確定的理由來預估潛在傷害的嚴重度。根據下表,應為嚴重度指定一個S0、S1、S2或S3的嚴重度等級。

blob.png

d. 每一個危害事件的ASIL等級應使用“嚴重度”、“暴露概率”和“可控性”這三個參數根據下表來確定。

blob.png

由于BMS屬于新能源汽車高壓電池系統的一部分,EUCAR定義了高壓電池系統的危害等級。

blob.png

當BMS不能夠很好的監測或者保護電芯時,上表中的危害事件就有可能發生。ISO26262的目標是保護乘客受到危害,因為上表Level 5以上就算是嚴重危害事件了。因此有必要定義一個電芯工作的最大允許危害級別,5以上時肯定不允許的。

(二):ASIL等級

1. 相關項定義,ASIL等級,安全目標

如下圖所示,第一步通過不同的駕駛情況,不同的環境來確定不同的場景;第二步分析不同場景下的事故所以引起的Hazard Situation. 第三步確定這些Hazard Situation的ASIL 等級,這一部分有很大的主觀因素,每個公司考慮問題的角度不一樣,針對不同的Hazard Situation設定的ASIL 等級也會不一樣。

比如有些OEM定義熱失控的ASIL LEVEL為C,有些OEM設定熱失控 ASIL LEVEL 為D,不過目前來看熱失控以后的ASIL LEVEL會是D,在知乎上看有人說以后大眾的高壓電池包的安全等級為D,他說的這個電池包應該是指電池包里面的電氣架構包括BMS。

blob.png

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電池包。

blob.png

a) Preliminary architecture of the hypothetical Li-ion battery system

b) Key elements and signals within the energy storage system

點畫線表示高壓電池系統的邊界線,高壓系統的與外界的交互信號分成了下表中的七大類。

blob.png

上面定義了不同類的子系統,下面這張圖是上圖中(connected modules)連接模組的框框圖。

blob.png

下面這張圖是上面連接模組的進一步分解的模組框框圖及信號流。

blob.png

這樣一層一層像剝洋蔥一樣分解系統,很方便追溯所有信號來源。系統與其他外部部件之間的聯系,系統內部之間的聯系,子系統之間的聯系,一目了然。

比如我們想追蹤溫度傳感器的信號流,首先可以從模組框框圖開始,temperature sensor 到 monitoring unit, monitoring unit 與外部的 internal communication交互信息,上一次的連接模組的 internal communication 與外界的 Junction box通過內部通訊交換信息Top level 的 junction box 與外界的整車控制器交互信息。

這篇文章里的Itemdefinition是針對高壓電池包,我直接引用。BMS系統沒有這么多子系統,但是在工作中發現,其實把高壓系統的電氣系統和BMS作為一個大系統,進行功能安全分析更全面,工作也更好展開。

(三):ASIL等級

a. ASIL等級

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

blob.png

Item definition,不僅需要將系統的功能描述清楚,同時也要將item的失效模式描述清楚,這樣才能清楚知道tiem應該是怎么樣,而不應該出現某些哪些表現形式。

在ISO26262-3中,Hazrad可以通過,brainstorm或者DFMEA等方法來確認,從整車級別分析這些危害會對車輛或者乘客造成的影響。這個階段的DFMEA我們可以不用考慮造成這些危害的可能原因有哪些,在后面的DFEMA工作中可以具體來分析造成這些hardzard的可能原因。

在第二篇的中的item defintion中,分析了過一個A00級別汽車的電池包。如下圖。

blob.png

下表是根據上圖HARA(Hazard Analysis and Risk Assessment)得到的。定義了93個功能和136個malfunction.

blob.png

在該文章中選取了6個路況,subterranean garage, small streets, middle streets, large streets, highway and motorway,同時選取了23個常見的駕駛工況,常見的天氣情況對場景的影響,最后得到了3128個可能性較大的危害事件。

3128還是個非常大的數字,如果一條一條的分析,是個巨大的工作。文章中提高,他們團隊有來不自不同部門的經驗豐富的工程師有整車部門,電芯部門,pack部門,EE等,最后團隊從這3128危害事件中選擇了142個進行進一步分析。

下表是電池系統幾個function與malfunction:

blob.png

在定義好了malfunction后,就可以根據Risk definiton中的三個參數S(Severity),E( Exposure), C(Controllability)來確定危害的ASIL 等級了。

下表是一個簡單的電芯過放的HARA分析。在這個表格里面,在城市道路上發生電芯熱失控導致車輛起火,定的ASIL Level是C;車輛在速度比較低的時候,定的ASIL Level是A。

blob.png

下表是另外一個文章中過放的HRAR分析:

blob.png

這兩個表格中參數C(Controllability)很大程度上取決于駕駛員將車輛停靠在安全位置的速度,車速越快,車速越快駕駛員需要更多的時間找一個安全位置將電芯熱失控的車輛安置好。這兩個表格中第二行S/E/C的值都是一樣,而ASIL LEVEL卻不一樣,怎么回事?

有個很簡單的公式來確定確定ASIL LEVEL。如果S+E+C的值小于7,那么ASIL LEVEL是A,詳細如下表。所以第二個表格中的ASIL LEVEL應該C,文章的小瑕疵。

blob.png

下表是一篇文章對一個高壓電池包HARA分析后給出的Safety Goal.同上面兩個對比,不同的公司或組織對相同的Malfunction給出的ASIL LEVEL是不同的,上面兩個表格對過充的ASIL LEVEL是C,下表為D。

blob.png

由Saftey Goal衍生出的安全目標應該考慮一下內容:

◆ 運行模式

◆故障容錯時間區間(間隔);或故障容錯時間

◆ 安全狀態

◆ 緊急操作時間區間

◆ 功能冗余(例如故障容錯)

應為每一個安全目標定義至少一項功能安全要求,盡管一個功能安全要求能夠cover不止一條安全目標,每一條FSR從相關SG繼承最高的ASIL。然后將FSR分配給相關項。比如下表中的SG1定義了兩個FSR。

blob.png

在ISO26262-9中定義了ASIL分解,為了降低安全目標實施成本,可以將一個高ASIL安全目標分解成兩個相互獨立的低一級安全目標。拿文中的SG1-預防過放作為一個例子,在這里我們假設負載只有驅動電機,可以通過將SG1分解成兩個獨立的FSR。FSR1.2a:在x ms內斷開高壓回路,FSR1.2a:通過CAN報文請求負載將需求功率降低為0。

blob.png

(四):技術安全要求導出

技術安全要求導出

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

blob.png

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

blob.png

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

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

a. 外部接口,如通訊和用戶接口,如果適用;

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

c. 系統配置要求。

在第三篇文章中,從安全目標道出了BMS的一個功能安全要求,圖3是對功能安全要求FSR1.2a導出的技術安全要求。

blob.png

系統設計

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

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

a. 系統設計的可驗證性

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

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

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

在系統設計階段,為了避免系統系失效,ISO26262針對不同的ASIL等級推薦了不同的分析方法,如FMEA,FAT等。如表1。由于內因或者外因而引起系統失效應當避免或者消除。

blob.png

為減少系統性失效, 宜應用值得信賴的汽車系統設計原則. 這些原則可能包括:

a. 值得信賴的技術安全概念的再利用;

b. 值得信賴的要素設計的再利用, 包括硬件和軟件組件;

c. 值得信賴的探測和控制失效的機制的再利用, 及

d. 值得信賴的或標準化接口的再利用。

為了確保值得信賴的設計原則或要素在新相關項中的適用性, 應分析其應用結果, 以及應在再利用之前檢查其基本設想。

ASIL A、B、C、D 規定:為避免高復雜性帶來的故障,架構設計應該根據表2 中的原則來展現下列的屬性:模塊化,層次化,簡單化。

blob.png

基于上面定義的TSR和概念階段定義的基本架構圖,圖4是精煉之后的BMS系統架構圖。

blob.png

下一步是定義系統架構,分配TSR給硬件和軟件,同時定義好軟件硬件接口HIS。

軟硬件接口規范應規定的硬件和軟件的交互,并與技術安全的概念是一致的,應包括組件的硬件設備,是由軟件和硬件資源控制支持軟件運行的。軟硬件接口規范應包括下面屬性:

a. 硬件設備的工作模式和相關的配置參數, 硬件設備的操作模式,如:缺省模式,

b. 初始化,測試或高級模式, 配置參數,如:增益控制,帶通頻率或時鐘分頻器。

c. 確保單元之間的獨立性和支持軟件分區的硬件特性

d. 共享和專用硬件資源,如內存映射,寄存器,定時器,中斷,I / O 端口的分配。

e. 硬件設備的獲取機制,如串口,并口,從,主/從

f. 每個涉及技術安全概念的時序約束

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

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

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

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

blob.png

(五):硬件系統功能安全設計

硬件的詳細安全需求來自于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要求的“潛伏故障度量”的定量目標值應基于下列參考目標值:

blob.png

對BMS系統來講,電池包電壓傳感器是一個非常重要的傳感器,因此針對不同的ASIL等級需要分析電池包電壓傳感器不同的失效模式。下表是不同的ASIL級別所需要覆蓋到失效模式。

blob.png

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

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

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

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

blob.png

在前面幾章分析過從HARA分析得到Safe Goal,從Safe Goal推導出FSR,從FSR推導出TSR。并以BMS的過充作為例子進行了詳細的介紹。

文章[1]選取了TI公司的BQ20Z80芯片,監控四個cell電壓,管理均衡。圖1是電路原圖(表示看不清,可以看參考文獻[2]的高清大圖),該電路的核心元器件是ICBQ20Z80,BQ2940是過充二級保護芯片。文章針對過充保護功能,選擇方法2展開對安全目標-“Battery overcharging shallbe prevented ”的隨機失效失效評估。該方法不僅考慮到錯誤發生的可能性同時還考慮到安全機制的有效性。文章評估了芯片BQ2940及采樣芯片BQ2931。

blob.png

ISO 26262標準中引入了失效率等級。硬件元器件失效率的失效率等級評級應按如下確定:

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

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

blob.png

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

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

blob.png

根據FSR可以推導出TSR,TSR見圖3。

blob.png

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

◆Overcharge condition shall be detectedwithin Y ms and,

◆ Current to the battery shall beinterrupted within Z ms.

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

blob.png

◆ 實施安全機制中需要用到的硬件元器件預估失效率(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%,針對不同的與之安全相關的部件。

blob.png

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

(六)汽車軟件開發

前面五部分介紹了基于ISO26262標準的開發BMS的系統及硬件部分,最后一部分介紹軟件部分。至此整個BMS的功能安全開發流程簡單梳理了一遍。這個月國家標準化管理委員會發布了功能安全的GB/T版本,雖是推薦標準,但是以后越來越多的OEM會對供應商列為強制標準,對零部件企業的電子電氣系統開發是個極大的挑戰。

blob.png

在汽車行業軟件開發一般遵循V模型,左邊是開發過程,右邊對應的測試過程。ISO26262第六部分推薦的軟件開發流程也V模型,如下圖所示,跟硬件的V模型開發流程基本一樣,需求-->架構-->詳細設計。

blob.png

1. 軟件架構設計

軟件開發流程跟硬件開發基本一樣,由軟件TSR和系統需求可以確定軟件基本架構。軟件安全要求需要與軟件架構一起實施,以及與安全相關的其它軟件要求。在軟件架構中, 由于軟件單元獲得了分配給他們的不同軟件安全性要求,因此考慮這些可能與不同ASILs的要求是否可以共存在同一軟件單元中也很重要。

如果不符合這些標準,則需要根據所有分配的安全要求的最高ASIL開發和測試軟件。 這些標準可能包括內存保護和保證的執行時間。

軟件架構包含靜態和動態方面的,靜態方面的主要和不同軟件單元之間的接口:1)軟件結構包括其分級層次; 2) 數據處理的邏輯順序; 3) 數據類型和它們的特征參數; 4) 軟件組件的外部接口; 5)軟件的外部接口及 約束(包括架構的范圍和外部依賴)。動態方面的涉及:1)功能性和行為; 2)控制流和并發進程;3) 軟件組件間的數據流;4) 對外接口的數據流時間的限制。為了說明這兩個方面,軟件架構所用到的標記法有,非正式標記法,半正式標記法,正式標記法,ASIL 等級越高,標記法越正式。

blob.png

在軟件架構設計中,需要重點考慮軟件的可維護性及可測試性。在汽車行業,軟件在整個產品周期內都應當考慮維護性,同時還要考慮軟件架構的設計測試的容易醒,在ISO 26262標準中,測試是非常重要的一方面,任何設計都應該同時考慮到測試的方便性。

為避免高度復雜性導致系統性故障, ISO26262列出來一些推薦的標準:

◆軟件層次性,軟件模塊的高內聚性,限制軟件模塊大小。

◆軟件模塊之間的接口應當盡量少且簡單。這個可以通過限制軟件模塊的耦合度實現。

◆軟件調度應當避免使用中斷,如果使用了中斷,要注意考慮中斷的優先級。目的是確保軟件單元執行時間。

在軟件架構層面,可以檢測不同軟件單元之間的錯誤。ASIL等級越高,要求的安全機制越多。下面是ISO26262中提到的一些安全機制,有些安全機機制之間可能有重復。

◆數據范圍檢查:數據在不同的軟件模組讀寫時,這個簡單方法可以確保數據在正常合理范圍之內。任何超出這個范圍的數據,都可以被認為是錯誤的數據,比如電池cell電壓超出5v,就可以認為這個數據是無效的。

◆真實性檢查:軟件模組之間的信號傳遞可以采用這種類型的合理性檢查。比如汽車在1s內從靜止狀態加速到100km/h,這個減速度在汽車上是不現實的。同時可以采用參考模型或者其他來源信息來評估信號的合理性。

◆數據錯誤檢查:有許多方法可以檢查數據的正確性,比如數據校驗(data checksums),冗余數據備份。

◆控制流監控:通過監控軟件單元的執行流程,可以檢測到某些故障,包括跳過的指令和軟件卡在無限循環中。

◆多樣化軟件設計:在軟件設計中使用多樣性設計可以高效的檢測軟件故障。 該方法是設計兩個不同的軟件單元進行互相監控; 如果二者行為不同,那么說明其中一個故障。 因為軟件設計師也犯了類似的錯誤并不罕見。 為了避免類似的錯誤,軟件功能越多樣化,這些類型的錯誤的可能性就越低。

一旦軟件錯誤被檢測到,應該有相應的錯誤處理機制。在軟件架構級別ISO26262詳列的錯誤處理安全機制如下:

◆靜態恢復機制:目的是從破壞的狀態回到可以繼續正常運行的狀態

◆適度降級:當發生故障時,該方法讓系統進去一個安全運行模式。汽車軟件的通常做法是亮起警示燈通知駕駛員某部件出現了問題,對高壓系統而言,如BMS檢測到輕度絕緣故障等。

◆獨立并行冗余:該安全機制可能會需要硬件冗余,因此成本相對而言較高。這個概念假設基于兩個冗余硬件同時發生錯誤的概率相對很低,并且有一個硬件一直處于正常無故障運行模式。

◆數據糾錯碼:對于數據錯誤,有機制可以糾正這些錯誤。 這些機制都是基于添加冗余數據來提供不同級別的保護。使用的冗余數據越多,可以更正的錯誤就越多。 這通常用于CD,DVD和RAM,但也可以在汽車領域使用。

一旦軟件架構設計結束后,就需要對軟件架構的需求進行測試。ISO26262詳列了一些方法:

◆設計走查:一種同行審查的形式,軟件架構設計者將這種架構描述為一組審查人員,目的是檢測任何潛在的問題。

◆設計檢查:與走查相比,檢查更正式。 它包括幾個步驟:規劃,離線檢查,檢查會議,返工和更改的后續工作。

◆仿真:如果軟件架構可以通過軟件進行仿真,那么仿真是一種有效的方法,特別是在架構的動態部分找到故障。

◆生成原型:與仿真一樣,原型設計對于動態部件來說也是非常有效的。 分析原型和預期目標之間的任何差異也是很重要的。

◆形式驗證:這種方法用數學證明或反駁正確性,很少用于汽車行業。 它可用于確保預期的行為,排除意外行為,并證明安全要求。

◆控制流分析:這種類型的分析可以用在在靜態代碼分析。目的是在架構層的軟件執行中找到任何安全關鍵路徑。

◆數據流分析:這種類型的分析可以用在在靜態代碼分析。目的是在軟件架構層面找到任何安全關鍵的變量

2. 軟件單元測試

一旦軟件安全要求確定了,單元級別的軟件架構已完成,那么就可以展看軟件單元的設計和實施。 ISO 26262支持手動編寫的代碼(manually written code)和自動生成的代碼。 如果生成代碼,則可以省略對軟件單元的要求,前提是使用的工具已經通過ASIL等級認證。 在本節中,重點將是人工編寫的代碼。

與軟件架構的規范一樣,ISO 26262規定了應用于軟件單元設計的符號。 ISO 26262要求適當組合所使用符號。并且始終強烈推薦自然語言。 此外,該標準建議使用非正式符號,半正式符號和正式符號。

關于軟件單元實施,ISO26262中提到的許多設計原則。 有些可能不適用,取決于開發過程。 有些也可能被使用的編碼指南所涵蓋:

子程序和函數采用一個入口和一個出口:多個出口點通過代碼使控制流復雜化,代碼難以理解和維護。

無動態對象或動態變量,在其產生過程中也沒有在線測試:動態對象和變量存在兩個主要挑戰,不可預測的行為和內存泄漏。 兩者都可能對安全產生負面影響。

變量初始化:沒有初始化變量,變量可能是任何值,包括不安全的和非法的值。這兩者都可能對安全產生負面影響。

不能重復使用變量名稱:使用相同名稱的不同變量有風險

避免全局變量,否則需證明對全局變量的使用是合理的:全局變量從兩個方面來說都是壞的: 它們可以被任何人讀取并被任何人寫入。開發安全相關的代碼,強烈建議從這兩個方面控制變量。有些時候,可能存在全局變量優先的情況,如果使用全局變量的相關風險的使用可以被證明安全,ISO 26262允許這些情況。網上文章說豐田的踏板事件中,28萬行代碼,有1w多個全局變量。

◆限制使用指針:使用指針的兩個重大風險是變量值的破壞和程序的崩潰; 兩者都應該避免。

◆無隱式類型轉換:即使編譯器支持某些編程語言,應避免這種情況,因為它可能導致意外的行為,包括數據丟失。

◆無隱藏數據流或控制流:隱藏的流程使代碼更難以理解和維護。

◆沒有無條件跳轉:無條件跳轉使得代碼更難以分析和理解

◆無遞歸:遞歸是一種強大的方法。 然而,它使代碼復雜化,使其難以理解和驗證。

在軟件單元設計和實現的時候,需要驗證硬件 - 軟件接口和軟件安全要求是否滿足安全需求。 此外,應確保軟件代碼符合編碼準則,軟件單元設計與預期硬件兼容。ISO推薦了的方法基本和軟件架構的一樣。

◆靜態代碼分析: 分析的基礎是調試源代碼而不執行它。 通常包括語法和語義的分析,檢查編碼指南,如MISRA-C,變量估計,控制流和數據流的分析。

◆語義代碼分析:該方法一般考慮到的是源代碼的語義方面,是一種靜態代碼分析。 可以檢測的示例包括未正確定義和以不正確方式使用的變量和函數。

凡本網注明“來源:高工電動車”的所有作品,版權均屬于高工電動車,轉載請注明來源:“高工電動車”。違反上述 聲明者,本網將追究其相關法律責任。 本網轉載自其它媒體的信息,轉載目的在于傳遞更多信息,并不代表本網 贊同其觀點和對其真實性負責。
混合过关竞猜计算器 11选5青海 千炮彩金捕鱼 组选包胆赢的机会大吗 魔域口袋版牛牛客服端 365彩票手机app下载 pk10免费永久计划app 大乐透官网体彩大乐透 江西时时彩开奖网站 内蒙古11选五开奖助手 pc蛋蛋幸运28稳赚 安卓手机免费单机麻将 黄大仙心水高手资料 江西快3开奖结果全部 福建福彩快三走势图 重庆欢乐生肖玩法规则 快乐十分十一选五体彩开奖结果