上一篇我們已經(jīng)聊完了軟件安全需求SWSR相關(guān)內(nèi)容，接下來以此為基礎，我們需要對軟件架構(gòu)進行安全設計，將安全機制相關(guān)的SWSR應用于軟件架構(gòu)當中，為后續(xù)軟件詳細設計提供基礎，是軟件功能安全開發(fā)重要內(nèi)容。

01

軟件架構(gòu)安全設計任務

軟件安全架構(gòu)旨在刻畫出實現(xiàn)軟件功能安全基本的軟件框架，需要在系統(tǒng)架構(gòu)的基礎上，對其軟件部分進行進一步細化，開發(fā)滿足軟件功能安全要求的軟件架構(gòu)設計。 ?

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

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

軟件架構(gòu)要素的靜態(tài)設計方面，包括；

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

軟件架構(gòu)要素的動態(tài)設計方面，包括：

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

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

02

軟件架構(gòu)開發(fā)常見視圖

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

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

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

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

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

UML或SysML為描述架構(gòu)靜態(tài)和動態(tài)特性，分別引入了兩大類視圖： ?

1

結(jié)構(gòu)視圖:?描述架構(gòu)靜態(tài)結(jié)構(gòu)和接口。 常見的結(jié)構(gòu)視圖包括，類圖，組件圖，復合結(jié)構(gòu)圖，包圖等。

2

行為視圖: 描述架構(gòu)動態(tài)行為，例如數(shù)據(jù)流，控制流，不同狀態(tài)切換等。

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

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

?

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

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

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

1

圖比傳統(tǒng)語言，代碼更清晰，易懂。

2

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

3

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

4

為基于AUTOSAR的系統(tǒng)設計階段提供輸入和后續(xù)軟件詳細設計提供基礎。

03

軟件架構(gòu)安全設計

軟件架構(gòu)安全的設計的本質(zhì)是將和架構(gòu)相關(guān)的軟件安全需求SWSR應用于軟件架構(gòu)設計，初步確定軟件功能安全實現(xiàn)的基本框架和方式，為后續(xù)軟件詳細設計提供基礎。 ?

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

總體來講，根據(jù)不同的軟件分層，軟件架構(gòu)安全設計基本分為兩大部分：

功能監(jiān)控層安全設計

基礎軟件安全設計

?3.1 功能監(jiān)控層安全設計 ?

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

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

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

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

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

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

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

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

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

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

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

3.2 基礎軟件安全設計

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

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

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

3.2.1 全部依據(jù)最高ASIL等級開發(fā)

以AUTOSAR為例，如下圖所示，全部基礎軟件，包括OS，內(nèi)存分配，通訊等均統(tǒng)一按照最高ASIL等級開發(fā)。

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

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

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

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

3.2.2.1 FFI干擾類型

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

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

軟件在執(zhí)行和調(diào)度過程中出現(xiàn)的組件間的干擾主要包括:

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

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

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

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

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

其對應的安全機制包括:

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

─?程序監(jiān)控(Program Flow Monitor)

內(nèi)存(Memory)干擾

軟件組件內(nèi)存干擾類型主要包括:

─?內(nèi)容損壞(corruption of content)

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

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

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

其對應的安全機制包括:

─ 內(nèi)存分區(qū)，使用內(nèi)存保護單元(MemoryProtection Unit , MPU)來實現(xiàn)軟件分區(qū)。

信息交換(Exchange of information)干擾

發(fā)送方(Sender)和接收方(Receiver)之間的數(shù)據(jù)交換對系統(tǒng)的功能安全造成影響:

─?信息重復 (repetitionof information)

─?信息丟失 (lossof information)

─?信息延遲 (delayof information)

─?信息插入 (insertionof information)

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

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

─?信息損壞 (corruptionof information)

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

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

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

其對應的安全機制包括:

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

─?E2E保護?(End2End Protection)

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

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

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

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

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

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

1

軟件架構(gòu)細致程度應能夠承載SWSR。

2

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

3

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

4

HWSR應被分配至軟件架構(gòu)中的組件。

5

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

─ 按最高ASIL等級。

─ 要素共存FFI，例如軟件分區(qū)。

6

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

架構(gòu)設計約束詳細內(nèi)容及表格可以直接查看ISO 26262-6:2018 第7章節(jié)內(nèi)容，在此不再贅述。

審核編輯：劉清