With the trend of increasing technological complexity, software content and mechatronic implementation, there are increasing risks from systematic failures and random hardware failures. ISO 26262 includes guidance to avoid these risks by providing appropriate requirements and processes.
-- ISO26262-1 Introduction
就如ISO26262陳述的一樣，隨着系統技術復雜度、軟件規模、機電部件的不斷增加，由系統性失效和硬件隨機失效導致的風險也在增加。
系統性失效和硬件隨機失效的比較見博文系統性失效和隨機失效。
所有的軟件失效都是系統性失效，不能用統計方法描述其概率，不能定量分析，只能定性地分析和得出定性的結論。
為什么軟件失效不能定量地描述？
你可以嘗試回答下面兩個問題，感受一下定量描述軟件失效有多難。
1） 你能准確估計一個軟件有多少個bug嗎？ （一定要准確估計，粗略估計是定性地分析）
2） 你能估計出這些bug對系統功能安全的影響嗎？
很難估計的原因是因為系統失效是人為失誤造成的。如果你能定量描述軟件失效，那你也能預測明天股票漲跌幾個點了。
如何將軟件失效及其導致的風險控制在可接受的范圍？
解決方法是引入一套開發流程，規范人的行為，減少人為失誤。比如：
1）關鍵的設計、文檔等需要他人審查（review）。多個人同時犯錯的可能性比一個人犯錯概率地低幾個數量級；
2）每個功能性需求必須有測試驗證。
ISO26262是一套汽車行業認可的功能安全標准，它包含一套用於功能安全系統的軟件的開發流程和要求。
下面就介紹ISO26262對軟件的要求。
ISO26262對軟件的要求主要在第6部分，它指定了用於汽車的軟件開發的要求。
軟件不是系統內獨立的部件，他和硬件、生產軟件的工具（比如編譯器、代碼檢查工具）都有密切聯系。
一部分軟件安全機制需要硬件支持。比如ISO26262在軟件架構級別提出了錯誤檢測機制。
其中的方案需要硬件支持。
“1c 數據錯誤檢測”的一種方案是使用硬件支持的ECC（Error Correcting Code）碼。
“1d 外部監測設備”的一種方案是使用在微處理器（CPU）外部的，在在ASIC上的看門狗。
所有用於功能安全相關的軟件開發工具都需要功能安全認證。
ISO26262按照V開發模型，將軟件開發分為以下幾個階段：軟件功能需求、軟件架構設計、軟件單元設計和實現、軟件單元測試、軟件集成測試、軟件需求測試。
下面詳細介紹這幾個階段。
軟件功能安全需求。
軟件安全需求的目標是：
1） 指定軟件功能安全需求，它們是從功能安全技術規范或者系統設計導出。所有的和功能安全相關的軟件功能都應該被考慮到。
2）完善軟硬件接口需求
3）驗證軟件功能安全需求、軟硬件接口需求是否與功能安全技術規范、系統設計一致
軟件功能安全需求考慮了硬件的限制及其對軟件的影響。比如NVM有位反轉隨機失效。
軟件架構設計
軟件架構設計的目標是：
1）建立能實現軟件功能安全需求的架構；
2）驗證軟件架構設計。
軟件架構設計用一個層級結構表示軟件模塊和它們之間的交互，包括靜態交互和動態交互。靜態交互比如軟件模塊間的接口和數據路徑；動態交互比如流程順序和時間行為。
軟件架構設計提供一種實現軟件安全需求和管理軟件開發復雜的復雜性。
軟件架構設計需要包含足夠的信息，以方便軟件實現。ISO26262對軟件架構語言的要求如表2。
UML（Unified Modeling Language）就是一種半正式符號語言（semi-formal notation），也是常用的軟件架構設計語言。
為了避免高復雜度導致的失效，軟件架構設計應該展現以下屬性。
1）模塊化
2）封裝
3）簡化
可以通過表3中的原則實現上面3個屬性。
表3中的1d指軟件模塊內部應高內聚，1e指軟件模塊之間應該低耦合。
在軟件層級應該做功能安全分析，目的是為了
1）識別或確認和功能安全相關的軟件部分；
2）支持指定和驗證功能安全機制的有效性。這里的功能安全機制能處理硬件隨機失效和軟件故障。
更具軟件架構層級功能安全分析的結構，表4中的錯誤檢測機制應該被適用，以便指定必須的軟功能安全機制。
軟件架構設計驗證
軟件架構驗證的方法見表6。
軟件架構設計應該滿足如下屬性：
1）符合軟件功能安全需求；
2）和目標硬件兼容；
3）遵循設計准則。
軟件單元設計和軟件實現。
第一個目標是根據軟件體系結構設計和相關的軟件安全要求指定軟件單元。
第二個目標是實現指定的軟件單元。
第三個目標是靜態驗證軟件單元的設計及其實現。
在軟件架構設計的基礎上，對軟件單元進行了詳細設計。在進入軟件單元測試階段之前，對軟件單元設計和實現進行了靜態驗證。
ISO26262對軟件單元設計的語言要求見表7。
在源代碼級別的軟件設計和實現應滿足如下屬性：
1）基於軟件架構，子程序和函數在軟件單元內執行順序正確；
2）軟件單元之間結構的一致性；
3）軟件單元內部和軟件單元之間的數據流和控制流的正確性；
4）簡單；
5）可讀性和可理解性
6）魯棒性； 例子：防止不真實的值、執行錯誤、除零、數據流和控制流錯誤
7）適用軟件修改；
8）可測性
為了實現以上屬性，表8中的原則應該被遵守。
軟件單元設計和實現的驗證
軟件單元設計和實現應滿足如下屬性：
1）滿足軟硬件結構需求；
2）滿足軟件單元的軟件功能安全需求
3） 源代碼與編碼准則的一致性
4）軟件單元實現與目標硬件的兼容性
為了驗證以上屬性，表9中定義的方法應該被遵循。
軟件測試
單元測試、模塊測試、集成測試、需求測試。
單元測試
目標是證明軟件單元符合軟件單元設計規范，並且不包含不需要的功能。
其中“不需要的功能”是指沒有對應的軟件需求的功能。
軟件單元測試方法如表10。
為了評估測試用例的完整性，並證明沒有非預期的功能，應在軟件單元層級確定需求的覆蓋度，並根據表 12 中列出的指標衡量軟件代碼的結構覆蓋率。
集成測試
第一個目標是集成軟件元素。
第二個目標是證明軟件架構設計已通過嵌入式軟件實現。
在此子階段中，將根據軟件架構結構設計測試特定的集成級別和軟件元素之間的接口。軟件元素的集成和測試步驟直接對應於軟件的層次結構。
在此子階段中，根據軟件架構設計對特定的集成級別和軟件元素之間的接口進行測試。對軟元素的集成和測試的步驟直接對應於軟件的分層架構結構。
需求測試
驗證軟件功能安全需求的目的是證明嵌入式軟件滿足目標環境的需求。測試應該在表16中的環境中進行。
版權聲明： 本文為作者原創，未經許可禁止轉載。原文地址：https://www.cnblogs.com/byronsh/p/functional-safety-software-development.html
本文的數字簽名如下：
MGYCMQDvrxf3rkOGdx8rLD+p9IOIUm2ruhQNPde2GCmAqq0vbhuY4gSbcRboMJAAGvpdfIkCMQDmGEWps0K4qNQ1z0PvzSPVuYlwoy2C6vnyU00fe0pIjSLk+K3+ExAtB5z5lUGTxJg=
--- 2019-7-20 17:41:35