從功能安全視角看軟件架構設計

功能安全應該如何考慮軟件架構，什麼樣的架構是符合功能安全標準要求的，對於軟件架構工程師和功能安全工程師，很難在兩個方面都說得明白，本篇來從功能安全的角度談談軟件架構設計的基本要求。

首先，功能安全軟件的架構設計是基於兩個層次的：

第一：選取和建立一個層次分明，易於理解的軟件架構；

第二：在第一條的基礎上，符合相應功能安全等級要求的軟件設計要求。

接下來，以汽車功能安全標準 ISO26262-6 和軌道交通軟件功能安全標準 EN50128 作爲基準，談談標準是如何從以上兩個層次來做出規定的。

軟件架構階段的開始

軟件架構設計是軟件生命週期的第二個階段，前面的階段是軟件需求階段（software requirements specification）, 在軟件需求設計時，把整個軟件當成一個黑盒處理，來確定該軟件的所有功能、性能，與硬件的接口定義，與外部其它系統的接口定義，而在軟件架構階段，需要設計一種架構來滿足軟件需求，通過層次化結構的方式來表示軟件架構的組件構成和他們之間的交互方式。以下圖爲例，虛線框之外是軟件需求，虛線框內是軟件架構。

什麼是軟件組件

上面這個圖用於解釋軟件架構所做的工作，將整個軟件劃分爲功能和接口清晰的組件。在 ISO26262-6 和 EN50128 中都有軟件組件（component）這個概念，先來看看這個組件的定義：

EN50128 對組件的定義

ISO26262 對組件的定義

很多人把組件理解成一個函數、或一個包括多個函數的文件，從標準中對組件的定義來看，組件作爲一組軟件功能需求的集合，有點類似於面嚮對象語言中的類的概念，是在軟件架構中的一個個獨立的個體，可以單獨替換更新的基本元素。通過軟件組件的應用可以達到重複使用和替換的目的，它可以被單獨測試和版本管理。

軟件架構設計原則

如何設計軟件架構中的組件，在 ISO26262-6 中提出了以下設計原則：

設計原則從兩個方面來進行規定：

1. **單個組件：**限制組件的規模，限制接口的數量，有限的中斷使用，目的在於降低每個組件的複雜度，

2. **多個組件：**組件內強內聚，組件之間松耦合，組件之間的空間隔離，組件之間共用資源的衝突管理。

避免出現以下情況：

• 系統的一個功能分散在不同的組件中，代碼多個地方改變同一變量或狀態；

• 未對系統的中斷功能進行限制，多箇中斷造成導致軟件的時間約束不受控；

• 組件不具備可維護性，不可能做到重構其中一個組件；

• 組件未做到良好的封裝或封裝不合理，對外的接口過於繁雜或內部狀態不可知；

• 組件設計缺乏可讀性，只有專家級人員才能看得懂；

軟件架構內容要點

劃分了層次化的組件後，軟件架構重點描述組件之間的關係：靜態關係和動態關係。靜態設計方面如組件之間的接口、與硬件的關係、組件的分層結構通常比較明確，容易忽視的是動態設計，軟件的動態行爲需要考慮：

• 事件和行爲的功能；

• 數據處理的邏輯順序；

• 控制流和併發進程；

• 通過接口和全局變量傳遞的數據流；

• 時間約束。

這些內容僅用文字表達容易造成歧義，難以描述準確，因此推薦使用建模和文字表達相結合的方式，下表是 EN50128 對建模方法的推薦表，雖然標準中僅要求至少使用一種，但從軟件架構需要表達的不同動態行爲上，強烈建議根據不同的行爲採用適合的建模方法。例如採用文字表達難以準確描述不同系統通信交互的時序關係，採用 Sequence Diagrams（序列圖）可以明確表示交互關係。

EN50128 Table A.17 建模技術

在上表中，常用的建模方法有：

數據流圖——描述數據如何由輸入逐步流向輸出的過程；

控制流圖——描述由輸入經過一系列控制動作到輸出的過程；

狀態機圖——描述系統不同狀態之間的轉換關係；

真值表——描述一個複雜的組合邏輯關係；

序列圖——描述不同組成部分通過信息交互的時序關係；

結構圖——描述組件之間的層次關係。

序列圖示例

這些軟件建模方法屬於軟件通用的設計方法，在 UML、SysML 軟件建模語言中就有上述建模方法，屬於半形式化類方法。

注意這些建模方法在項目中使用，需要讓項目中與軟件架構關聯的人理解一致，需要建立建模方法的使用指南，以規範其編寫要求。

以上作爲軟件架構的通用性要求，軟件缺陷爲系統性失效，不存在失效概率的問題，因此，如果寫的代碼沒有 bug，它百分之百是按照定義的需求去執行。但是，有兩個問題是安全軟件需要考慮的，第一，軟件不可避免會存在 bug；第二，軟件的實現與它所運行的硬件，與它所接口的外部系統相關聯，任何與它關聯的外部環境發生改變，都會對軟件的預期行爲產生影響，因此，安全軟件不僅要考慮正常情況下的預期行爲，也要考慮故障和干擾情況下的預期行爲。

軟件架構設計應用技術

在 EN50128 中的 A.3 表，列舉了軟件架構可供選擇的技術方法，其中

2-14,16 項是底層的安全設計技術，其中較爲常用的是 Fault detection & Diagnosis，與硬件或外部接口相關聯；Graceful degradation 作爲 fail-operational 的一種實現方式，用於確保故障情況下的功能依然保持一定的可用性。對於軟件的安全技術，應該適當地選擇使用，畢竟增加了軟件的複雜度，也加大了系統性失效的可能，而且安全技術往往難以兼顧可測試性。

防禦性編程作爲 SIL1-SIL4 都高度推薦使用的技術，是最常用的軟件安全技術，用於檢查軟件執行中不正確的數據流、控制流和數據值情況下的預期行爲，一種是防護軟件自身設計缺陷造成的問題，如變量的範圍檢查、檢查輸入值的可信性、程序入口檢查入參的類型、大小和範圍；另一種是防護外部環境輸入的不受控造成的問題，如檢查物理變量值輸入的有效性、濾波處理、配置數據的完整性和軟件自身的完整性。

EN50128 A.3

已存在軟件組件的使用

在 ISO26262 和 EN50128 中都規定了在安全軟件中如何複用一個已存在軟件組件，存在兩種情況，會使用已存在組件：

• 來自於公司外部的 CTOS 組件；

• 以前開發組件的再利用。

首先一個組件能夠被重複使用，它的接口必須能清晰識別，確定其應用環境，實現的規格也是明確的。在 EN50128 中，如果應用於 SIL3 和 SIL4，需要分析已存在軟件可能的失效對整體軟件的影響，以及檢測已存在軟件失效的策略，如包裝技術。在 ISO26262.8 中，第 12 章規定了對已存在組件的鑑定要求。兩個標準均要求對已存在軟件進行鑑定，確定可用的功能、組件版本與配置、應用環境的假設、關聯的安全完整性等級、組件殘餘缺陷情況，並對鑑定過程進行驗證。

軟件組件的相互影響

當軟件由不同安全完整性等級的組件組成時，在 EN50128 7.3.4.9 和 ISO26262-6 7.4.8 的要求一致：

除非有證據表明高級別組件和低級別組件之間彼此獨立，從時間分區和空間分區兩個維度，其它情況都應按照最高等級要求開發。

在 ISO26262-6 提出有兩種不同組件分區的方法，第一種是軟件分區，從執行時序、數據保護、組件之間的數據交互方面考慮組件之間的干擾影響，第二種是硬件保護機制的支持，如 MPU；第三種是操作系統或虛擬化層對不同組件互不干擾的支持。

最後，回顧一下五方面主要內容：

1. 軟件需求、軟件架構與組件的關係；

2. 軟件架構需涵蓋的內容；

3. 安全軟件應用技術；

4. 如何應用已存在軟件；

5. 不同安全等級軟件的影響分析

在不同標準中，架構設計還有各自側重的部分，ISO26262-6 對軟件安全分析有相應要求，EN50128 安全分析的工作放在系統層面進行，要求從系統功能和接口的角度進行分析。EN50128 在架構設計階段對軟件設計方法（建模指南、設計指南和編碼規則）有更爲詳細的定義，並需要在架構階段完成軟件集成測試規範和軟硬件集成測試規範。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/HralsBeCJ1SVmV9L24D-9g