從功能安全視角看軟件架構設計
功能安全應該如何考慮軟件架構，什么樣的架構是符合功能安全標準要求的，對于軟件架構工程師和功能安全工程師，很難在兩個方面都說得明白，本篇來從功能安全的角度談談軟件架構設計的基本要求。
首先，功能安全軟件的架構設計是基于兩個層次的：
第一：選取和建立一個層次分明，易于理解的軟件架構；
第二：在第一條的基礎上，符合相應功能安全等級要求的軟件設計要求。
接下來，以汽車功能安全標準ISO26262-6和軌道交通軟件功能安全標準EN50128作為基準，談談標準是如何從以上兩個層次來做出規定的。
軟件架構階段的開始
軟件架構設計是軟件生命周期的第二個階段，前面的階段是軟件需求階段（software requirements specification）,在軟件需求設計時，把整個軟件當成一個黑盒處理，來確定該軟件的所有功能、性能，與硬件的接口定義，與外部其它系統的接口定義，而在軟件架構階段，需要設計一種架構來滿足軟件需求，通過層次化結構的方式來表示軟件架構的組件構成和他們之間的交互方式。以下圖為例，虛線框之外是軟件需求，虛線框內是軟件架構。
什么是軟件組件
上面這個圖用于解釋軟件架構所做的工作，將整個軟件劃分為功能和接口清晰的組件。在ISO26262-6和EN50128中都有軟件組件（component）這個概念，先來看看這個組件的定義：
很多人把組件理解成一個函數、或一個包括多個函數的文件，從標準中對組件的定義來看，組件作為一組軟件功能需求的集合，有點類似于面向對象語言中的類的概念，是在軟件架構中的一個個獨立的個體，可以單獨替換更新的基本元素。通過軟件組件的應用可以達到重復使用和替換的目的，它可以被單獨測試和版本管理。
軟件架構設計原則
如何設計軟件架構中的組件，在ISO26262-6中提出了以下設計原則：
設計原則從兩個方面來進行規定：
- 單個組件：限制組件的規模，限制接口的數量，有限的中斷使用，目的在于降低每個組件的復雜度，
- 多個組件：組件內強內聚，組件之間松耦合，組件之間的空間隔離，組件之間共用資源的沖突管理。
避免出現以下情況：
- 系統的一個功能分散在不同的組件中，代碼多個地方改變同一變量或狀態；
- 未對系統的中斷功能進行限制，多個中斷造成導致軟件的時間約束不受控；
- 組件不具備可維護性，不可能做到重構其中一個組件；
- 組件未做到良好的封裝或封裝不合理，對外的接口過于繁雜或內部狀態不可知；
- 組件設計缺乏可讀性，只有專家級人員才能看得懂；
軟件架構內容要點
劃分了層次化的組件后，軟件架構重點描述組件之間的關系：靜態關系和動態關系。靜態設計方面如組件之間的接口、與硬件的關系、組件的分層結構通常比較明確，容易忽視的是動態設計，軟件的動態行為需要考慮：
- 事件和行為的功能；
- 數據處理的邏輯順序；
- 控制流和并發進程；
- 通過接口和全局變量傳遞的數據流；
- 時間約束。
這些內容僅用文字表達容易造成歧義，難以描述準確，因此推薦使用建模和文字表達相結合的方式，下表是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；第三種是操作系統或虛擬化層對不同組件互不干擾的支持。
最后，回顧一下五方面主要內容：
- 軟件需求、軟件架構與組件的關系；
- 軟件架構需涵蓋的內容；
- 安全軟件應用技術；
- 如何應用已存在軟件；
- 不同安全等級軟件的影響分析
在不同標準中，架構設計還有各自側重的部分，ISO26262-6對軟件安全分析有相應要求，EN50128安全分析的工作放在系統層面進行，要求從系統功能和接口的角度進行分析。EN50128在架構設計階段對軟件設計方法（建模指南、設計指南和編碼規則）有更為詳細的定義，并需要在架構階段完成軟件集成測試規范和軟硬件集成測試規范。
