汽車功能安全軟件開發階段軟件架構安全設計

上一篇我們已經聊完了軟件安全需求SWSR相關內容，接下來以此為基礎，我們需要對軟件架構進行安全設計，將安全機制相關的SWSR應用于軟件架構當中，為后續軟件詳細設計提供基礎，是軟件功能安全開發重要內容。

01

軟件架構安全設計任務

軟件安全架構旨在刻畫出實現軟件功能安全基本的軟件框架，需要在系統架構的基礎上，對其軟件部分進行進一步細化，開發滿足軟件功能安全要求的軟件架構設計。 ?

一般來講，軟件架構設計需要同時考慮安全相關和非安全相關的軟件要求，安全相關的需求甚至很大程度上決定了軟件架構的形式，例如，是否需要分層設計，軟件分區等。 ?

對于分層式軟件架構設計，功能安全架構部分可以相對獨立進行設計。但不管安全或非安全相關軟件架構的設計，其任務都在于描述： ?

軟件架構要素的靜態設計方面，包括；

?─?分級層次的軟件結構； ?─?數據類型和它們的特征參數； ?─?軟件組件的外部接口； ?─?嵌入式軟件的外部接口； ?─?全局變量； ?─?包括架構的范圍和外部依賴的約束。 ?

軟件架構要素的動態設計方面，包括：

?─?事件和行為的功能鏈； ?─?數據處理的邏輯順序； ?─?控制流和并發進程； ?─?通過接口和全局變量傳遞的數據流； ?─?時間的限制。 ?

所以，不管系統還是軟件架構，都包含靜態和動態特性，這兩方面特性描述越全面，越利于后續軟件詳細設計，在實際應用中可根據需要選擇。 ?

02

軟件架構開發常見視圖

為了描述軟件架構靜態和動態特性，ISO 26262對軟件架構設計的標記法進行明確規定，包括: 自然語言，非半形式，半形式(偽代碼，UML,SysML，Simulink等)，形式記法(可運行代碼)，其中對于ASIL等級C和D軟件安全需求對應的架構設計強烈推薦采用半形式法進行。 ?

在實際架構設計過程中，一般采用通用化建模語言UML或SysML，目前大部分架構設計軟件都支持這兩種設計語言，如Enterprise Architect， Cameo等。 ?

此外，這些架構設計語言及軟件和后續軟件設計一脈相承，可以將相應的軟件架構視圖直接導入AUTOSAR或SIMULINK等軟件開發工具，以此為基礎直接用于軟件詳細設計。

當然，也可以直接采用AUTOSAR等軟件開發工具鏈進行，進行軟件架構設計，形成ARXML描述文件，其圖形化設計語言也屬于半形式標記法。 ?

為了刻畫軟件架構靜態和動態特性，往往需要采用不同的軟件視圖，即從不同的角度，描述軟件架構的行為。 ?

UML或SysML為描述架構靜態和動態特性，分別引入了兩大類視圖： ?

1

結構視圖:?描述架構靜態結構和接口。 常見的結構視圖包括，類圖，組件圖，復合結構圖，包圖等。

2

行為視圖: 描述架構動態行為，例如數據流，控制流，不同狀態切換等。

常見的行為視圖包括，用例圖，活動圖，時序圖，狀態圖，交互縱覽圖等。

如下圖所示，一般來講，UML和SysML視圖類型存在部分重疊，也存在一定差異，例如需求及參數視圖屬于SysML獨有。二者在視圖語言規則類似，UML多用于軟件架構設計，而SysML多用于系統設計，二者可以混合使用。

?

在實際應用過程中，可根據需要，采取不同視圖，描述軟件架構的不同特性，之后可以專門給朋友們聊聊UML和SysML視圖。

以一個組件為例，其UML組件圖如下圖所示，用于描述組件內部子組件及其接口關系。

疑問解答:?在軟件定義汽車，為應對不斷增加的軟件復雜度，架構的重要性毋庸置疑，但很多朋友可能會好奇，為什么非要采取UML/SysML等半形式標記法描述架構，真的有必要嗎?

1

圖比傳統語言，代碼更清晰，易懂。

2

ISO?26262?對架構設計標記法明確，對于ASIL C和D的系統，強烈推薦使用半形式標記法，即UML或SysML。

3

圖可以描述復雜系統或者過程，統一建模語言及視圖統一了各種方法對不同類型的系統、不同開發階段以及不同內部概念的不同觀點，從而有效的消除了各種建模語言之間不必要的差異。

4

為基于AUTOSAR的系統設計階段提供輸入和后續軟件詳細設計提供基礎。

03

軟件架構安全設計

軟件架構安全的設計的本質是將和架構相關的軟件安全需求SWSR應用于軟件架構設計，初步確定軟件功能安全實現的基本框架和方式，為后續軟件詳細設計提供基礎。 ?

除經典AUTOSAR的軟件架構，將軟件整體分為應用層，TRE通訊層，基礎軟件層外，為實現軟件功能安全，還會將功能安全和非功能安全軟件進行分層設計。例如E-Gas三層架構，將軟件整體分為功能層，功能監控層和控制器監控層，其中功能層和功能監控層均屬于AUTOSAR中應用軟件層，控制器監控層為基礎軟件層，二者相互統一，并不矛盾。 ?

總體來講，根據不同的軟件分層，軟件架構安全設計基本分為兩大部分：

功能監控層安全設計

基礎軟件安全設計

?3.1 功能監控層安全設計 ?

對于軟件監控層架構安全設計而言，主要是將軟件架構相關的SWSR，即錯誤探測和錯誤處理安全機制，應用于軟件監控層的架構設計。 ?

功能監控層屬于獨立于軟件功能實現的功能安全開發內容，一般按照相應ASIL等級進行獨立開發，對功能層中功能安全相關部分進行監控，包括輸入輸出診斷，邏輯監控，故障分類及故障優先級仲裁等。 ?

在功能監控層軟件架構設計，主要是將和架構相關的錯誤探測和錯誤處理等安全機制，應用于功能監控層架構設計。雖然根據不同類型的控制器，其安全機制具體實施有所差別，但總體而言，主要包含以下安全機制： ?

用于錯誤探測的安全機制包括：

─?輸入輸出數據的范圍檢查； ─?合理性檢查(例如，使用期望行為參考模型、斷言檢查、或不同來源信號比較)； ─?數據錯誤探測（例如，檢錯碼和多重數據存儲）； ─?外部要素監控程序執行，例如，通過專用集成電路（ASIC）或者其他軟件要素來執行看門狗功能。監控可以是邏輯監控或時間監控，或者兩者的結合； ─?程序執行的時間監控； ─?設計中的異構冗余；或 —在軟件或硬件中實施的訪問沖突控制機制，與授權訪問或拒絕訪問安全相關共享資源有關。 ?

用于錯誤處理的安全機制可能包括：

─?為了達到和維持安全狀態的功能關閉； ─?靜態恢復機制（例如，恢復塊、后向恢復、前向恢復以及通過重試來恢復）； ─?通過劃分功能優先級進行平穩降級，從而最小化潛在失效對功能安全的不利影響； ─?設計中同構冗余，主要側重于控制運行相似軟件的硬件中瞬態故障或隨機故障的影響(例如，軟件在時間上的冗余執行)； ? 具體來講，在功能監控層架構設計過程中，可以根據具體監控的功能，進行相應的異構冗余計算，對其輸入，輸出，進行范圍及合理性檢查，異構冗余計算程序執行過程進行時內部或外部要素的時間或邏輯監控，一旦發現錯誤，通過錯誤處理機制，將系統導入安全狀態。 ?

實例：以整車控制器加速踏板信號為例，其ASIL等級要求一般為D，為了實現該安全需求，需要從軟件和硬件兩個方面著手:?硬件安全方面主要是加速度傳感器本身冗余及雙路冗余采樣等。軟件安全方面主要是以上述安全機制的具體應用，例如，兩路加速踏板傳感器信號自身故障診斷，信號電壓范圍是否在有效范圍內，和制動踏板信號之間的合理性檢驗，雙路信號是否同步等等。 ?

同樣，在軟件開發過程中，ISO 26262并沒有也沒辦法明確哪個ASIL等級應該采取哪些軟件安全機制，根據個人經驗，一般存在以下兩種方式可以進行參考： ?

ISO 26262第5部分硬件開發附件中對不同類型安全機制診斷覆蓋率進行高中低分類，可以依據安全機制覆蓋率的中高低分別應用于ASIL D，C，B類型的安全需求。

依靠以往開發經驗，一般對于ASIL D或C的安全需求，需要根據適用性采取目前State of Art的所有或大部分安全機制，對于ASIL B或A的安全需求，則沒有明確要求。

3.2 基礎軟件安全設計

基礎軟件多和控制器硬件相關，是保證上層軟件(應用層，功能監控層)正常運行基本條件。

在經典的AUTOSAR軟件平臺，為實現獨立于控制器硬件，多平臺軟件復用，采用了RTE層和基礎軟件層，通過標準化接口規范，逐級對硬件進行抽象，對上提供統一訪問接口，以此實現軟硬件分離。

對于基礎軟件安全設計而言，主要是對基礎軟件提出的更高的功能安全方面的需求，從ISO 26262角度而言，依據非或不同ASIL等級要素共存原則，基礎軟件開發存在兩種方式：

3.2.1 全部依據最高ASIL等級開發

以AUTOSAR為例，如下圖所示，全部基礎軟件，包括OS，內存分配，通訊等均統一按照最高ASIL等級開發。

優點: 安全性能高，軟件主體為功能安全組件，之間無需額外安全機制保護，運行效率高。

缺點: 底層模塊需按ASIL等級開發，成本高，但隨著軟件復雜度不斷提高，為降低開發復雜度和增加軟件可靠性，逐漸成為趨勢。

3.2.2 采用Partition，使用免于干擾(FFI)，要素共存措施

為降低開發成本，目前基于功能安全和非功能安全的Partion類型開發也尤為常見。為了實現非或不同ASIL等級要素共存，除了在功能監控層對其開發進行區別對待外，還需要在基礎軟件部分采用相應的安全措施，避免高ASIL等級軟件受到低ASIL等級或QM軟件的干擾，進而破壞安全需求，具體如下圖所示:

3.2.2.1 FFI干擾類型

ISO 26262共定義以下三種類型的干擾:?

執行和時序(Timing &Execution)干擾

軟件在執行和調度過程中出現的組件間的干擾主要包括:

─?執行阻塞?(blocking of execution):?一個任務有CPU控制，阻塞了另外一個任務。

─?死鎖?(deadlocks):?每一個處于等待狀態的任務相互等待釋放已經被鎖定的資源。

─?活鎖?(livelocks) :??進程狀態不斷變化，但仍相互依賴，永遠無法完成它們的任務。

─?執行時間的不正確分配?(incorrect allocation of execution time)。

─軟件要素間的不正確同步?(incorrect synchronization between software elements)。

其對應的安全機制包括:

─?內外部看門狗(Internal/External Watchdog)

─?程序監控(Program Flow Monitor)

內存(Memory)干擾

軟件組件內存干擾類型主要包括:

─?內容損壞(corruption of content)

─?數據不一致(inconsistent data (e.g. due to update during data fetch))

─?堆棧溢出或下溢(stack overflow or underflow)

─?對已分配給其他軟件要素的內存進行讀寫訪問(read or write access to memoryallocated to another software element)

其對應的安全機制包括:

─ 內存分區，使用內存保護單元(MemoryProtection Unit , MPU)來實現軟件分區。

信息交換(Exchange of information)干擾

發送方(Sender)和接收方(Receiver)之間的數據交換對系統的功能安全造成影響:

─?信息重復 (repetitionof information)

─?信息丟失 (lossof information)

─?信息延遲 (delayof information)

─?信息插入 (insertionof information)

─?信息次序不正確 (incorrectsequence of information)

─?信息偽裝或不正確尋址(masquerade or incorrectaddressing of information)

─?信息損壞 (corruptionof information)

─?從發送方傳送到多個接收方的信息不對稱(asymmetric information sent from a senderto multiple receivers)

─?發送方發送的信息只能被部分接收方接收(information from a senderreceived by only a subset of the receivers)

─?通信信道阻塞(blocking access to a communicationchannel)。

其對應的安全機制包括:

─?循環冗余校驗(cyclic redundancy check)

─?E2E保護?(End2End Protection)

3.2.2.2 要素共存(FFI)解決方案

看完這些FFI干擾類型，大家先不要慌，基礎軟件多標準化開發，在不同軟件平臺直接采用開發工具鏈配置即可。

例如，Vector提供AUTOSAR的ECU解決方案，包括源代碼MICROSAR和DaVinci系列配置工具，其中和功能安全相關的軟件模塊 MICROSAR Safe如下圖所示:

針對FFI不同干擾類型以及安全機制，分別對應相應的基礎軟件安全模塊，包括:

Safe OS，SafeRTE， SafeWDG，SafeE2E等等，具體使用需要根據相應開發工具鏈進行配置就可，但相對成本也較高。

除此之外，ISO 26262對功能安全相關的軟件架設計，還根據不同ASIL等級，提出了其他相關約束，包括: ?

1

軟件架構細致程度應能夠承載SWSR。

2

軟件架構設計原則，包括:?適當分層，限制軟件組件規模和復雜度，限制接口規模，組內高內聚，組間低耦合，限制中斷使用等。

3

軟件架構設計驗證方法，包括:?設計走查，設計檢查，控制流，數據流分析，仿真，快速原型等。

4

HWSR應被分配至軟件架構中的組件。

5

不同或非ASIL等級軟件組件開發需滿足以下原則之一:

─ 按最高ASIL等級。

─ 要素共存FFI，例如軟件分區。

6

對SWSR和具體實施之間的可追溯性。

架構設計約束詳細內容及表格可以直接查看ISO 26262-6:2018 第7章節內容，在此不再贅述。

審核編輯：劉清