汽車功能安全 - 軟件開發

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

數字簽名驗證方法