BMS功能安全開發(fā)流程(六):汽車軟件開發(fā)
2017-12-22
上一篇介紹了《BMS功能安全開發(fā)流程(五):硬件系統(tǒng)功能安全設(shè)計》,后一部分介紹軟件部分。至此整個BMS的功能安全開發(fā)流程簡單梳理了一遍。這個月標(biāo)準(zhǔn)化管理委員會發(fā)布了功能安全的GB/T版本,雖是推薦標(biāo)準(zhǔn),但是以后越來越多的OEM會對供應(yīng)商列為強(qiáng)制標(biāo)準(zhǔn),對零部件企業(yè)的電子電氣系統(tǒng)開發(fā)是個極大的挑戰(zhàn)。
在汽車行業(yè)軟件開發(fā)一般遵循V模型,左邊是開發(fā)過程,右邊對應(yīng)的測試過程。ISO26262第六部分推薦的軟件開發(fā)流程也V模型,如下圖所示,跟硬件的V模型開發(fā)流程基本一樣,需求–>架構(gòu)–>詳細(xì)設(shè)計。
1. 軟件架構(gòu)設(shè)計
軟件開發(fā)流程跟硬件開發(fā)基本一樣,由軟件TSR和系統(tǒng)需求可以確定軟件基本架構(gòu)。軟件安全要求需要與軟件架構(gòu)一起實施,以及與安全相關(guān)的其它軟件要求。在軟件架構(gòu)中, 由于軟件單元獲得了分配給他們的不同軟件安全性要求,因此考慮這些可能與不同ASILs的要求是否可以共存在同一軟件單元中也很重要。 如果不符合這些標(biāo)準(zhǔn),則需要根據(jù)所有分配的安全要求的高ASIL開發(fā)和測試軟件。 這些標(biāo)準(zhǔn)可能包括內(nèi)存保護(hù)和保證的執(zhí)行時間。
軟件架構(gòu)包含靜態(tài)和動態(tài)方面的,靜態(tài)方面的主要和不同軟件單元之間的接口:1)軟件結(jié)構(gòu)包括其分級層次; 2) 數(shù)據(jù)處理的邏輯順序; 3) 數(shù)據(jù)類型和它們的特征參數(shù); 4) 軟件組件的外部接口; 5)軟件的外部接口及 約束(包括架構(gòu)的范圍和外部依賴)。動態(tài)方面的涉及:1)功能性和行為; 2)控制流和并發(fā)進(jìn)程;3) 軟件組件間的數(shù)據(jù)流;4) 對外接口的數(shù)據(jù)流時間的限制。為了說明這兩個方面,軟件架構(gòu)所用到的標(biāo)記法有,非正式標(biāo)記法,半正式標(biāo)記法,正式標(biāo)記法,ASIL 等級越高,標(biāo)記法越正式。
在軟件架構(gòu)設(shè)計中,需要重點考慮軟件的可維護(hù)性及可測試性。在汽車行業(yè),軟件在整個產(chǎn)品周期內(nèi)都應(yīng)當(dāng)考慮維護(hù)性,同時還要考慮軟件架構(gòu)的設(shè)計測試的容易醒,在ISO 26262標(biāo)準(zhǔn)中,測試是非常重要的一方面,任何設(shè)計都應(yīng)該同時考慮到測試的方便性。
為避免高度復(fù)雜性導(dǎo)致系統(tǒng)性故障, ISO26262列出來一些推薦的標(biāo)準(zhǔn):
- ? 軟件層次性,軟件模塊的高內(nèi)聚性,限制軟件模塊大小
- ??軟件模塊之間的接口應(yīng)當(dāng)盡量少且簡單。這個可以通過限制軟件模塊的耦合度實現(xiàn)
- ??軟件調(diào)度應(yīng)當(dāng)避免使用中斷,如果使用了中斷,要注意考慮中斷的優(yōu)先級。目的是確保軟件單元執(zhí)行時間
在軟件架構(gòu)層面,可以檢測不同軟件單元之間的錯誤。ASIL等級越高,要求的安全機(jī)制越多。下面是ISO26262中提到的一些安全機(jī)制,有些安全機(jī)機(jī)制之間可能有重復(fù)。
- 數(shù)據(jù)范圍檢查:數(shù)據(jù)在不同的軟件模組讀寫時,這個簡單方法可以確保數(shù)據(jù)在正常合理范圍之內(nèi)。任何超出這個范圍的數(shù)據(jù),都可以被認(rèn)為是錯誤的數(shù)據(jù),比如電池cell電壓超出5v,就可以認(rèn)為這個數(shù)據(jù)是無效的。
- 真實性檢查:軟件模組之間的信號傳遞可以采用這種類型的合理性檢查。比如汽車在1s內(nèi)從靜止?fàn)顟B(tài)加速到100km/h,這個減速度在汽車上是不現(xiàn)實的。同時可以采用參考模型或者其他來源信息來評估信號的合理性。
- 數(shù)據(jù)錯誤檢查:有許多方法可以檢查數(shù)據(jù)的正確性,比如數(shù)據(jù)校驗(data checksums),冗余數(shù)據(jù)備份
- 控制流監(jiān)控:通過監(jiān)控軟件單元的執(zhí)行流程,可以檢測到某些故障,包括跳過的指令和軟件卡在無限循環(huán)中。
- 多樣化軟件設(shè)計:在軟件設(shè)計中使用多樣性設(shè)計可以高效的檢測軟件故障。 該方法是設(shè)計兩個不同的軟件單元進(jìn)行互相監(jiān)控; 如果二者行為不同,那么說明其中一個故障。 因為軟件設(shè)計師也犯了類似的錯誤并不罕見。 為了避免類似的錯誤,軟件功能越多樣化,這些類型的錯誤的可能性就越低。
一旦軟件錯誤被檢測到,應(yīng)該有相應(yīng)的錯誤處理機(jī)制。在軟件架構(gòu)級別ISO26262詳列的錯誤處理安全機(jī)制如下:
- 靜態(tài)恢復(fù)機(jī)制:目的是從破壞的狀態(tài)回到可以繼續(xù)正常運(yùn)行的狀態(tài)
- 適度降級:當(dāng)發(fā)生故障時,該方法讓系統(tǒng)進(jìn)去一個安全運(yùn)行模式。汽車軟件的通常做法是亮起警示燈通知駕駛員某部件出現(xiàn)了問題,對高壓系統(tǒng)而言,如BMS檢測到輕度絕緣故障等。
- 獨立并行冗余:該安全機(jī)制可能會需要硬件冗余,因此成本相對而言較高。這個概念假設(shè)基于兩個冗余硬件同時發(fā)生錯誤的概率相對很低,并且有一個硬件一直處于正常無故障運(yùn)行模式。
- 數(shù)據(jù)糾錯碼:對于數(shù)據(jù)錯誤,有機(jī)制可以糾正這些錯誤。 這些機(jī)制都是基于添加冗余數(shù)據(jù)來提供不同級別的保護(hù)。使用的冗余數(shù)據(jù)越多,可以更正的錯誤就越多。 這通常用于CD,DVD和RAM,但也可以在汽車領(lǐng)域使用。
一旦軟件架構(gòu)設(shè)計結(jié)束后,就需要對軟件架構(gòu)的需求進(jìn)行測試。ISO26262詳列了一些方法:
- 設(shè)計走查:一種同行審查的形式,軟件架構(gòu)設(shè)計者將這種架構(gòu)描述為一組審查人員,目的是檢測任何潛在的問題。
- 設(shè)計檢查:與走查相比,檢查更正式。 它包括幾個步驟:規(guī)劃,離線檢查,檢查會議,返工和更改的后續(xù)工作
- 仿真:如果軟件架構(gòu)可以通過軟件進(jìn)行仿真,那么仿真是一種有效的方法,特別是在架構(gòu)的動態(tài)部分找到故障。
- 生成原型:與仿真一樣,原型設(shè)計對于動態(tài)部件來說也是非常有效的。 分析原型和預(yù)期目標(biāo)之間的任何差異也是很重要的。
- 形式驗證:這種方法用數(shù)學(xué)證明或反駁正確性,很少用于汽車行業(yè)。 它可用于確保預(yù)期的行為,排除意外行為,并證明安全要求。
- 控制流分析:這種類型的分析可以用在在靜態(tài)代碼分析。目的是在架構(gòu)層的軟件執(zhí)行中找到任何安全關(guān)鍵路徑。
- 數(shù)據(jù)流分析:這種類型的分析可以用在在靜態(tài)代碼分析。目的是在軟件架構(gòu)層面找到任何安全關(guān)鍵的變量
2. 軟件單元測試
一旦軟件安全要求確定了,單元級別的軟件架構(gòu)已完成,那么就可以展看軟件單元的設(shè)計和實施。 ISO 26262支持手動編寫的代碼(manually written code)和自動生成的代碼。 如果生成代碼,則可以省略對軟件單元的要求,前提是使用的工具已經(jīng)通過ASIL等級認(rèn)證。 在本節(jié)中,重點將是人工編寫的代碼。
與軟件架構(gòu)的規(guī)范一樣,ISO 26262規(guī)定了應(yīng)用于軟件單元設(shè)計的符號。 ISO 26262要求適當(dāng)組合所使用符號。并且始終強(qiáng)烈推薦自然語言。 此外,該標(biāo)準(zhǔn)建議使用非正式符號,半正式符號和正式符號。
關(guān)于軟件單元實施,ISO26262中提到的許多設(shè)計原則。 有些可能不適用,取決于開發(fā)過程。 有些也可能被使用的編碼指南所涵蓋:
- 子程序和函數(shù)采用一個入口和一個出口:多個出口點通過代碼使控制流復(fù)雜化,代碼難以理解和維護(hù)。
- 無動態(tài)對象或動態(tài)變量,在其產(chǎn)生過程中也沒有在線測試:動態(tài)對象和變量存在兩個主要挑戰(zhàn),不可預(yù)測的行為和內(nèi)存泄漏。 兩者都可能對安全產(chǎn)生負(fù)面影響。
- 變量初始化:沒有初始化變量,變量可能是任何值,包括不安全的和非法的值。這兩者都可能對安全產(chǎn)生負(fù)面影響。
- 不能重復(fù)使用變量名稱:使用相同名稱的不同變量有風(fēng)險
- 避免全局變量,否則需證明對全局變量的使用是合理的:全局變量從兩個方面來說都是壞的: 它們可以被任何人讀取并被任何人寫入。開發(fā)安全相關(guān)的代碼,強(qiáng)烈建議從這兩個方面控制變量。有些時候,可能存在全局變量優(yōu)先的情況,如果使用全局變量的相關(guān)風(fēng)險的使用可以被證明安全,ISO 26262允許這些情況。網(wǎng)上文章說豐田的踏板事件中,28萬行代碼,有1w多個全局變量。
- 限制使用指針:使用指針的兩個重大風(fēng)險是變量值的破壞和程序的崩潰; 兩者都應(yīng)該避免。
- 無隱式類型轉(zhuǎn)換:即使編譯器支持某些編程語言,應(yīng)避免這種情況,因為它可能導(dǎo)致意外的行為,包括數(shù)據(jù)丟失。
- 無隱藏數(shù)據(jù)流或控制流:隱藏的流程使代碼更難以理解和維護(hù)。
- 沒有無條件跳轉(zhuǎn):無條件跳轉(zhuǎn)使得代碼更難以分析和理解
- 無遞歸:遞歸是一種強(qiáng)大的方法。 然而,它使代碼復(fù)雜化,使其難以理解和驗證。
在軟件單元設(shè)計和實現(xiàn)的時候,需要驗證硬件 – 軟件接口和軟件安全要求是否滿足安全需求。 此外,應(yīng)確保軟件代碼符合編碼準(zhǔn)則,軟件單元設(shè)計與預(yù)期硬件兼容。ISO推薦了的方法基本和軟件架構(gòu)的一樣。
- 靜態(tài)代碼分析:?分析的基礎(chǔ)是調(diào)試源代碼而不執(zhí)行它。 通常包括語法和語義的分析,檢查編碼指南,如MISRA-C,變量估計,控制流和數(shù)據(jù)流的分析。
- 語義代碼分析:該方法一般考慮到的是源代碼的語義方面,是一種靜態(tài)代碼分析。 可以檢測的示例包括未正確定義和以不正確方式使用的變量和函數(shù)。
下一篇: 一文了解直流電機(jī)/交流電機(jī)/電子整流電機(jī)的差異