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

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

1. 軟件架構設計

軟件開發流程跟硬件開發基本一樣，由軟件TSR和系統需求可以確定軟件基本架構。軟件安全要求需要與軟件架構一起實施，以及與安全相關的其它軟件要求。在軟件架構中， 由于軟件單元獲得了分配給他們的不同軟件安全性要求，因此考慮這些可能與不同ASILs的要求是否可以共存在同一軟件單元中也很重要。 如果不符合這些標準，則需要根據所有分配的安全要求的高ASIL開發和測試軟件。 這些標準可能包括內存保護和保證的執行時間。

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

在軟件架構設計中，需要重點考慮軟件的可維護性及可測試性。在汽車行業，軟件在整個產品周期內都應當考慮維護性，同時還要考慮軟件架構的設計測試的容易醒，在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中提到的許多設計原則。 有些可能不適用，取決于開發過程。 有些也可能被使用的編碼指南所涵蓋:

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

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

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