汽車功能安全之軟件架構設計

談思汽車 2024-02-02 11:35

4周搞定BLE/Wi?Fi/NFC，從選型到首例工程 一站式破解芯片研發(fā)全流程痛點，西門子 EDA Forum 2026等你來

?智能汽車安全新媒體?

什么是軟件架構設計？

在20世紀60年代，戴克斯特拉這位上古大神就已經(jīng)提出軟件架構這個概念了，但軟件架構真正流行卻是從20世紀90年代開始的，由于在Rational和Microsoft內部的相關活動，軟件架構的概念開始越來越流行了。

卡內基·梅隆大學的瑪麗·肖（Mary Shaw）和戴維·加蘭（David Garlan）對軟件架構做了很多研究，他們在1994年的一篇文章《軟件架構介紹》（An Introduction to Software Architecture）中寫到：

“When systems are constructed from many components, the organization of the overall system-the software architecture-presents a new set of design problems.”

簡單翻譯一下：隨著軟件系統(tǒng)規(guī)模的增加，計算相關的算法和數(shù)據(jù)結構不再構成主要的設計問題；當系統(tǒng)由許多部分組成時，整個系統(tǒng)的組織，也就是所說的“軟件架構”，導致了一系列新的設計問題。

這段話很好地解釋了“軟件架構”為何先在Rational或者Microsoft這樣的大公司開始逐步流行起來。因為只有大公司開發(fā)的軟件系統(tǒng)才具備較大規(guī)模，而只有規(guī)模較大的軟件系統(tǒng)才會面臨軟件架構相關的問題，例如：

系統(tǒng)規(guī)模龐大，內部耦合嚴重，開發(fā)效率低；
系統(tǒng)耦合嚴重，牽一發(fā)動全身，后續(xù)修改和擴展困難；
系統(tǒng)邏輯復雜，容易出問題，出問題后很難排查和修復。

而在功能安全標準中的定義——軟件架構設計是指全部軟件組件及其在層次結構中的交互。靜態(tài)方面，如所有軟件組件間的接口和數(shù)據(jù)路徑；動態(tài)方面，如進程順序和定時行為，都得到描述。

軟件架構設計不必局限于某個微控制器或電控單元，它關系到技術安全概念和系統(tǒng)設計。軟件架構設計并不是功能安全獨有的要求，只是功能安全在原有的基礎上疊加了很多安全方面的設計和考量標準，這使得軟件架構設計變得更全面更安全，同時為開發(fā)既實現(xiàn)軟件安全要求又實現(xiàn)非安全要求的軟件架構設計，通常來說安全和非安全性要求應在同一開發(fā)過程中處理。軟件架構設計提供了實施軟件安全要求和管理軟件開發(fā)復雜性的方法。

軟件架構設計依賴關系

軟件架構設計要求和建議

軟件架構設計描述方法

為確保軟件架構設計獲取必要信息以允許后續(xù)開發(fā)活動得到正確且有效的執(zhí)行，下表列出的軟件架構設計的標記法，對軟件架構設計進行恰當抽象層級的描述。

解釋：

自然語言：可以補充符號的使用，例如，一些主題更容易用自然語言表達，或者為符號中捕獲的決策提供解釋和理由，使抽象的設計更容易被理解。
非正式標記法：通常不作為標準的標記方法，描述上比較模糊。
半正式標記法：包括偽代碼或使用UML、SysML、Simulink或Stateflow建模。
正式標記法：包括數(shù)學或物理學表達式，通常是被證明過的嚴謹?shù)谋磉_式

軟件架構設計必要的性質

軟件架構設計的可驗證性；（這表明軟件架構設計和軟件安全要求之間的雙向可追溯性）

可配置軟件的適用性；

軟件單元設計和實現(xiàn)的可行性；

軟件集成測試中，軟件架構的可測性；

軟件架構設計的可維護性。

避免高度復雜性原則

為避免因高度復雜性導致的失效，應遵循下表列出的原則設計軟件架構：

1a.軟件需要采用分層架構，分層架構比較清晰

1b.每個軟件模塊或組件都不要太大，太大了不好維護，容易出bug

1c.接口的數(shù)量不要太多，降低軟件組件間的依賴關系

1d.1e.軟件盡量模塊化，這個顆粒度需要自己根據(jù)實際的產品把握

1f.調度合理，沒啥可說的，必須要合理

1g.少使用中斷，如果用中斷必須定義優(yōu)先級

1h.內存分區(qū)隔離保護

1i.適用于共享硬件資源以及共存情況下的共享軟件資源。這種資源管理可以以軟件或硬件來實現(xiàn)，并且包括防止對共享資源的沖突訪問的安全機制和/或過程措施以及檢測和處理對共享資源的沖突訪問的機制。

其實原則很很簡單，就是盡量避免高復雜性，高復雜性包括：

高度分支的控制或數(shù)據(jù)流；
分配給單一設計元素的需求數(shù)量過多；
一個設計元素的接口數(shù)量過多或設計元素之間的交互數(shù)量過多；
類型復雜或參數(shù)數(shù)量過多；
全局變量數(shù)量過多；
難以提供錯誤檢測和處理的適用性和完整性的證據(jù)；
難以達到所需的測試覆蓋率
只有少數(shù)專家或項目參與者才能理解。

軟件架構設計描述

為確定動態(tài)行為（如任務、時間片和中斷），需要考慮不同的運行狀態(tài)（如開機、關機、正常運行、標定和診斷）并且定義通訊關系和所分配的系統(tǒng)硬件（如 CPU 和通訊通道）。

軟件分區(qū)

共享資源的使用方式應確保軟件分區(qū)免于干擾；
一個軟件分區(qū)內的任務彼此之間不能免于干擾。
一個軟件分區(qū)不能改變其它軟件分區(qū)的代碼或數(shù)據(jù)，也不能訪問其它軟件分區(qū)的非共享資源。
一個軟件分區(qū)從共享資源獲取的服務不能被另一個軟件分區(qū)影響。這包括相關資源的性能，以及計劃訪問資源的使用率、延遲、抖動和持續(xù)時間。
由專用的硬件功能或等效方法來支持軟件分區(qū)（該要求適用于 ASIL D）
執(zhí)行軟件分區(qū)的軟件部分，按照分配給軟件分區(qū)要求的相同 ASIL等級進行開發(fā)，或按照比分配給軟件分區(qū)要求的最高 ASIL等級更高的一個ASIL等級進行開發(fā)；且一般來說操作系統(tǒng)提供支持軟件分區(qū)。
在軟件集成和測試過程中執(zhí)行軟件分區(qū)的驗證。

軟件組件

每個與安全相關的軟件組件應被歸類為下述之一：

新開發(fā)的，需要按照功能安全標準開發(fā)。
修改后使用的，需要按照功能安全標準修改。
未經(jīng)修改復用的。，對未經(jīng)修改重用的安全相關軟件組件進行鑒定。

如果在新的設計中引入了新的危害沒有被現(xiàn)有的安全目標覆蓋，應按照的變更管理流程在危害分析和風險評估中對它們進行介紹和評估。

未體現(xiàn)在安全目標中的新識別危害，通常是非功能性危害。如果這些非功能性危害超出了本標準的范疇，那么建議在危害分析和風險評估中用以下聲明“因不屬于功能安全的范疇，而未對該危害分配 ASIL”來標注它們，然而，為了參考，允許對其分配一個 ASIL 等級。

功能安全等級

應將軟件安全要求分配給軟件組件。因此，每個軟件組件應按照分配給它的要求中最高的 ASIL等級來進行開發(fā)。根據(jù)這一分配，進一步細化軟件安全要求可能是必要的。

如果嵌入式軟件不得不實現(xiàn)不同 ASIL等級的軟件組件，或實現(xiàn)安全相關及非安全相關的軟件組件，除非軟件組件符合功能安全標準中定義的兼容性準則，否則全部嵌入式軟件必須按照最高 ASIL等級來處理。

如果在新的設計中引入了新的危害沒有被現(xiàn)有的安全目標覆蓋，應按照的變更管理流程在危害分析和風險評估中對它們進行介紹和評估。

安全機制

當分配給軟件的技術安全要求沒有對軟件安全機制的使用進行直接要求時，那么應在系統(tǒng)層面對軟件安全機制的使用進行評審，以分析對系統(tǒng)行為的潛在影響。
輸入和輸出數(shù)據(jù)的范圍檢查；
合理性檢查（例如，使用所需行為的參考模型、斷言檢查或比較來自不同來源的信號）；
數(shù)據(jù)錯誤檢測（例如錯誤檢測代碼和多重數(shù)據(jù)存儲）；
通過外部元件（例如 ASIC 或其他軟件元件）監(jiān)控程序執(zhí)行執(zhí)行看門狗功能。監(jiān)控可以是邏輯監(jiān)控或時間監(jiān)控或兩者兼而有之；
程序執(zhí)行的時間監(jiān)控；
設計中存在多種冗余；
在與授予或拒絕對安全相關共享資源的訪問有關的軟件或硬件中實現(xiàn)的訪問沖突控制機制。

故障處理機制