電機(jī)控制器 | 叉車控制器 | 電動(dòng)車配件 | 其他              

BMS功能安全開(kāi)發(fā)流程(六):汽車軟件開(kāi)發(fā)

2017-12-22

上一篇介紹了《BMS功能安全開(kāi)發(fā)流程(五):硬件系統(tǒng)功能安全設(shè)計(jì)》,后一部分介紹軟件部分。至此整個(gè)BMS的功能安全開(kāi)發(fā)流程簡(jiǎn)單梳理了一遍。這個(gè)月標(biāo)準(zhǔn)化管理委員會(huì)發(fā)布了功能安全的GB/T版本,雖是推薦標(biāo)準(zhǔn),但是以后越來(lái)越多的OEM會(huì)對(duì)供應(yīng)商列為強(qiáng)制標(biāo)準(zhǔn),對(duì)零部件企業(yè)的電子電氣系統(tǒng)開(kāi)發(fā)是個(gè)極大的挑戰(zhàn)。

在汽車行業(yè)軟件開(kāi)發(fā)一般遵循V模型,左邊是開(kāi)發(fā)過(guò)程,右邊對(duì)應(yīng)的測(cè)試過(guò)程。ISO26262第六部分推薦的軟件開(kāi)發(fā)流程也V模型,如下圖所示,跟硬件的V模型開(kāi)發(fā)流程基本一樣,需求–>架構(gòu)–>詳細(xì)設(shè)計(jì)。

1. 軟件架構(gòu)設(shè)計(jì)

軟件開(kāi)發(fā)流程跟硬件開(kāi)發(fā)基本一樣,由軟件TSR和系統(tǒng)需求可以確定軟件基本架構(gòu)。軟件安全要求需要與軟件架構(gòu)一起實(shí)施,以及與安全相關(guān)的其它軟件要求。在軟件架構(gòu)中, 由于軟件單元獲得了分配給他們的不同軟件安全性要求,因此考慮這些可能與不同ASILs的要求是否可以共存在同一軟件單元中也很重要。 如果不符合這些標(biāo)準(zhǔn),則需要根據(jù)所有分配的安全要求的高ASIL開(kāi)發(fā)和測(cè)試軟件。 這些標(biāo)準(zhǔn)可能包括內(nèi)存保護(hù)和保證的執(zhí)行時(shí)間。

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

在軟件架構(gòu)設(shè)計(jì)中,需要重點(diǎn)考慮軟件的可維護(hù)性及可測(cè)試性。在汽車行業(yè),軟件在整個(gè)產(chǎn)品周期內(nèi)都應(yīng)當(dāng)考慮維護(hù)性,同時(shí)還要考慮軟件架構(gòu)的設(shè)計(jì)測(cè)試的容易醒,在ISO 26262標(biāo)準(zhǔn)中,測(cè)試是非常重要的一方面,任何設(shè)計(jì)都應(yīng)該同時(shí)考慮到測(cè)試的方便性。

為避免高度復(fù)雜性導(dǎo)致系統(tǒng)性故障, ISO26262列出來(lái)一些推薦的標(biāo)準(zhǔn):

  • ? 軟件層次性,軟件模塊的高內(nèi)聚性,限制軟件模塊大小
  • ??軟件模塊之間的接口應(yīng)當(dāng)盡量少且簡(jiǎn)單。這個(gè)可以通過(guò)限制軟件模塊的耦合度實(shí)現(xiàn)
  • ??軟件調(diào)度應(yīng)當(dāng)避免使用中斷,如果使用了中斷,要注意考慮中斷的優(yōu)先級(jí)。目的是確保軟件單元執(zhí)行時(shí)間

在軟件架構(gòu)層面,可以檢測(cè)不同軟件單元之間的錯(cuò)誤。ASIL等級(jí)越高,要求的安全機(jī)制越多。下面是ISO26262中提到的一些安全機(jī)制,有些安全機(jī)機(jī)制之間可能有重復(fù)。

  • 數(shù)據(jù)范圍檢查:數(shù)據(jù)在不同的軟件模組讀寫時(shí),這個(gè)簡(jiǎn)單方法可以確保數(shù)據(jù)在正常合理范圍之內(nèi)。任何超出這個(gè)范圍的數(shù)據(jù),都可以被認(rèn)為是錯(cuò)誤的數(shù)據(jù),比如電池cell電壓超出5v,就可以認(rèn)為這個(gè)數(shù)據(jù)是無(wú)效的。
  • 真實(shí)性檢查:軟件模組之間的信號(hào)傳遞可以采用這種類型的合理性檢查。比如汽車在1s內(nèi)從靜止?fàn)顟B(tài)加速到100km/h,這個(gè)減速度在汽車上是不現(xiàn)實(shí)的。同時(shí)可以采用參考模型或者其他來(lái)源信息來(lái)評(píng)估信號(hào)的合理性。
  • 數(shù)據(jù)錯(cuò)誤檢查:有許多方法可以檢查數(shù)據(jù)的正確性,比如數(shù)據(jù)校驗(yàn)(data checksums),冗余數(shù)據(jù)備份
  • 控制流監(jiān)控:通過(guò)監(jiān)控軟件單元的執(zhí)行流程,可以檢測(cè)到某些故障,包括跳過(guò)的指令和軟件卡在無(wú)限循環(huán)中。
  • 多樣化軟件設(shè)計(jì):在軟件設(shè)計(jì)中使用多樣性設(shè)計(jì)可以高效的檢測(cè)軟件故障。 該方法是設(shè)計(jì)兩個(gè)不同的軟件單元進(jìn)行互相監(jiān)控; 如果二者行為不同,那么說(shuō)明其中一個(gè)故障。 因?yàn)檐浖O(shè)計(jì)師也犯了類似的錯(cuò)誤并不罕見(jiàn)。 為了避免類似的錯(cuò)誤,軟件功能越多樣化,這些類型的錯(cuò)誤的可能性就越低。

一旦軟件錯(cuò)誤被檢測(cè)到,應(yīng)該有相應(yīng)的錯(cuò)誤處理機(jī)制。在軟件架構(gòu)級(jí)別ISO26262詳列的錯(cuò)誤處理安全機(jī)制如下:

  • 靜態(tài)恢復(fù)機(jī)制:目的是從破壞的狀態(tài)回到可以繼續(xù)正常運(yùn)行的狀態(tài)
  • 適度降級(jí):當(dāng)發(fā)生故障時(shí),該方法讓系統(tǒng)進(jìn)去一個(gè)安全運(yùn)行模式。汽車軟件的通常做法是亮起警示燈通知駕駛員某部件出現(xiàn)了問(wèn)題,對(duì)高壓系統(tǒng)而言,如BMS檢測(cè)到輕度絕緣故障等。
  • 獨(dú)立并行冗余:該安全機(jī)制可能會(huì)需要硬件冗余,因此成本相對(duì)而言較高。這個(gè)概念假設(shè)基于兩個(gè)冗余硬件同時(shí)發(fā)生錯(cuò)誤的概率相對(duì)很低,并且有一個(gè)硬件一直處于正常無(wú)故障運(yùn)行模式。
  • 數(shù)據(jù)糾錯(cuò)碼:對(duì)于數(shù)據(jù)錯(cuò)誤,有機(jī)制可以糾正這些錯(cuò)誤。 這些機(jī)制都是基于添加冗余數(shù)據(jù)來(lái)提供不同級(jí)別的保護(hù)。使用的冗余數(shù)據(jù)越多,可以更正的錯(cuò)誤就越多。 這通常用于CD,DVD和RAM,但也可以在汽車領(lǐng)域使用。

一旦軟件架構(gòu)設(shè)計(jì)結(jié)束后,就需要對(duì)軟件架構(gòu)的需求進(jìn)行測(cè)試。ISO26262詳列了一些方法:

  • 設(shè)計(jì)走查:一種同行審查的形式,軟件架構(gòu)設(shè)計(jì)者將這種架構(gòu)描述為一組審查人員,目的是檢測(cè)任何潛在的問(wèn)題。
  • 設(shè)計(jì)檢查:與走查相比,檢查更正式。 它包括幾個(gè)步驟:規(guī)劃,離線檢查,檢查會(huì)議,返工和更改的后續(xù)工作
  • 仿真:如果軟件架構(gòu)可以通過(guò)軟件進(jìn)行仿真,那么仿真是一種有效的方法,特別是在架構(gòu)的動(dòng)態(tài)部分找到故障。
  • 生成原型:與仿真一樣,原型設(shè)計(jì)對(duì)于動(dòng)態(tài)部件來(lái)說(shuō)也是非常有效的。 分析原型和預(yù)期目標(biāo)之間的任何差異也是很重要的。
  • 形式驗(yàn)證:這種方法用數(shù)學(xué)證明或反駁正確性,很少用于汽車行業(yè)。 它可用于確保預(yù)期的行為,排除意外行為,并證明安全要求。
  • 控制流分析:這種類型的分析可以用在在靜態(tài)代碼分析。目的是在架構(gòu)層的軟件執(zhí)行中找到任何安全關(guān)鍵路徑。
  • 數(shù)據(jù)流分析:這種類型的分析可以用在在靜態(tài)代碼分析。目的是在軟件架構(gòu)層面找到任何安全關(guān)鍵的變量

2. 軟件單元測(cè)試

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

與軟件架構(gòu)的規(guī)范一樣,ISO 26262規(guī)定了應(yīng)用于軟件單元設(shè)計(jì)的符號(hào)。 ISO 26262要求適當(dāng)組合所使用符號(hào)。并且始終強(qiáng)烈推薦自然語(yǔ)言。 此外,該標(biāo)準(zhǔn)建議使用非正式符號(hào),半正式符號(hào)和正式符號(hào)。

關(guān)于軟件單元實(shí)施,ISO26262中提到的許多設(shè)計(jì)原則。 有些可能不適用,取決于開(kāi)發(fā)過(guò)程。 有些也可能被使用的編碼指南所涵蓋:

  1. 子程序和函數(shù)采用一個(gè)入口和一個(gè)出口:多個(gè)出口點(diǎn)通過(guò)代碼使控制流復(fù)雜化,代碼難以理解和維護(hù)。
  2. 無(wú)動(dòng)態(tài)對(duì)象或動(dòng)態(tài)變量,在其產(chǎn)生過(guò)程中也沒(méi)有在線測(cè)試:動(dòng)態(tài)對(duì)象和變量存在兩個(gè)主要挑戰(zhàn),不可預(yù)測(cè)的行為和內(nèi)存泄漏。 兩者都可能對(duì)安全產(chǎn)生負(fù)面影響。
  3. 變量初始化:沒(méi)有初始化變量,變量可能是任何值,包括不安全的和非法的值。這兩者都可能對(duì)安全產(chǎn)生負(fù)面影響。
  4. 不能重復(fù)使用變量名稱:使用相同名稱的不同變量有風(fēng)險(xiǎn)
  5. 避免全局變量,否則需證明對(duì)全局變量的使用是合理的:全局變量從兩個(gè)方面來(lái)說(shuō)都是壞的: 它們可以被任何人讀取并被任何人寫入。開(kāi)發(fā)安全相關(guān)的代碼,強(qiáng)烈建議從這兩個(gè)方面控制變量。有些時(shí)候,可能存在全局變量?jī)?yōu)先的情況,如果使用全局變量的相關(guān)風(fēng)險(xiǎn)的使用可以被證明安全,ISO 26262允許這些情況。網(wǎng)上文章說(shuō)豐田的踏板事件中,28萬(wàn)行代碼,有1w多個(gè)全局變量。
  6. 限制使用指針:使用指針的兩個(gè)重大風(fēng)險(xiǎn)是變量值的破壞和程序的崩潰; 兩者都應(yīng)該避免。
  7. 無(wú)隱式類型轉(zhuǎn)換:即使編譯器支持某些編程語(yǔ)言,應(yīng)避免這種情況,因?yàn)樗赡軐?dǎo)致意外的行為,包括數(shù)據(jù)丟失。
  8. 無(wú)隱藏?cái)?shù)據(jù)流或控制流:隱藏的流程使代碼更難以理解和維護(hù)。
  9. 沒(méi)有無(wú)條件跳轉(zhuǎn):無(wú)條件跳轉(zhuǎn)使得代碼更難以分析和理解
  10. 無(wú)遞歸:遞歸是一種強(qiáng)大的方法。 然而,它使代碼復(fù)雜化,使其難以理解和驗(yàn)證。

在軟件單元設(shè)計(jì)和實(shí)現(xiàn)的時(shí)候,需要驗(yàn)證硬件 – 軟件接口和軟件安全要求是否滿足安全需求。 此外,應(yīng)確保軟件代碼符合編碼準(zhǔn)則,軟件單元設(shè)計(jì)與預(yù)期硬件兼容。ISO推薦了的方法基本和軟件架構(gòu)的一樣。

  • 靜態(tài)代碼分析:?分析的基礎(chǔ)是調(diào)試源代碼而不執(zhí)行它。 通常包括語(yǔ)法和語(yǔ)義的分析,檢查編碼指南,如MISRA-C,變量估計(jì),控制流和數(shù)據(jù)流的分析。
  • 語(yǔ)義代碼分析:該方法一般考慮到的是源代碼的語(yǔ)義方面,是一種靜態(tài)代碼分析。 可以檢測(cè)的示例包括未正確定義和以不正確方式使用的變量和函數(shù)。
上一篇:
下一篇: