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

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

1. 軟件架構(gòu)設計

軟件開發(fā)流程跟硬件開發(fā)基本一樣，由軟件TSR和系統(tǒng)需求可以確定軟件基本架構(gòu)。軟件安全要求需要與軟件架構(gòu)一起實施，以及與安全相關(guān)的其它軟件要求。在軟件架構(gòu)中， 由于軟件單元獲得了分配給他們的不同軟件安全性要求，因此考慮這些可能與不同ASILs的要求是否可以共存在同一軟件單元中也很重要。 如果不符合這些標準，則需要根據(jù)所有分配的安全要求的高ASIL開發(fā)和測試軟件。 這些標準可能包括內(nèi)存保護和保證的執(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ā)進程；3） 軟件組件間的數(shù)據(jù)流；4） 對外接口的數(shù)據(jù)流時間的限制。為了說明這兩個方面，軟件架構(gòu)所用到的標記法有，非正式標記法，半正式標記法，正式標記法，ASIL 等級越高，標記法越正式。

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

為避免高度復雜性導致系統(tǒng)性故障， ISO26262列出來一些推薦的標準：

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

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

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

一旦軟件錯誤被檢測到，應該有相應的錯誤處理機制。在軟件架構(gòu)級別ISO26262詳列的錯誤處理安全機制如下：

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

一旦軟件架構(gòu)設計結(jié)束后，就需要對軟件架構(gòu)的需求進行測試。ISO26262詳列了一些方法：

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

2. 軟件單元測試

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

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

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

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

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

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