01

軟件分區(qū)的推動力

與如今汽車電子架構(gòu)的演變歷程一樣，航空電子架構(gòu)也曾經(jīng)歷了從分布式到中央計算+域控的進化，只不過完成進化的時間更早：早在上個世紀末，IMA（Integrated Modular Avionics，集成模塊化航空電子設(shè)備）的設(shè)計理念就已融入到了大型民航客機的研制。在這種架構(gòu)設(shè)計下，從安全等級最高的顯控系統(tǒng)、到最低的娛樂系統(tǒng)在內(nèi)的幾十項應(yīng)用，都被高度集成在一個中央計算機內(nèi)，由同一個微處理器統(tǒng)一調(diào)配運行。我們所熟悉的波音787、空客A380等飛機均采取了這種設(shè)計理念。

航電系統(tǒng)的這種架構(gòu)進化能夠有效降低各種使用成本，包括機艙空間、能耗、線束、重量、冷卻、安裝、維護等各方面。對于對每一克航油的節(jié)省都錙銖必較的航空公司，IMA平臺相較舊有的分布式架構(gòu)帶來了顯著的成本優(yōu)勢。然而，這無疑也會帶來安全性問題，在一個集成了不同安全等級應(yīng)用的計算平臺中，類似顯控系統(tǒng)、飛控系統(tǒng)等高安全等級軟件，必須避免被低安全等級的應(yīng)用所干擾。軟件分區(qū)則是實現(xiàn)這一目標的核心工作。

在汽車功能安全領(lǐng)域，ISO26262和AutoSAR等相關(guān)標準都提到了軟件安全分區(qū)的一些設(shè)計原則。而航電系統(tǒng)也在數(shù)十年的研發(fā)和審定過程中，針對軟件分區(qū)形成了許多寶貴的經(jīng)驗，值得我們思考和借鑒。

02

DO-178和DO-297

《民用航空機載軟件適航標準（DO-178）》是由歐美航空組織于80年代初編制、用于保證航空機載軟件符合飛行安全要求（即“適航性”）的規(guī)范性文件。在DO-178C的2.4.1中明確提出：不論軟件分區(qū)是通過分配軟件組件到不同的硬件資源、還是在一個硬件上運行多個軟件組件來實現(xiàn)的，都應(yīng)該滿足以下安全分區(qū)的需求[1]：

●一個分區(qū)的軟件組件不應(yīng)被允許破壞另一個分區(qū)的軟件組件的代碼、輸入/輸出（I/O）、或數(shù)據(jù)存儲區(qū)域。

●一個分區(qū)的軟件組件應(yīng)當只有在其得到調(diào)度的執(zhí)行時段中，才被允許使用共享處理器的資源。

●一個分區(qū)的軟件組件獨有的硬件失效不應(yīng)對其他分區(qū)的軟件組件產(chǎn)生不利影響。

●任何提供分區(qū)（機制或服務(wù)）的軟件，應(yīng)當具有與分配給任何分區(qū)中最高安全等級軟件組件相同或更高的安全等級。

●任何提供分區(qū)的硬件應(yīng)當?shù)玫较到y(tǒng)級安全評估，以確保它不會對安全性產(chǎn)生不利影響。

而隨著上世紀90年代，IMA逐漸應(yīng)用于航電系統(tǒng)架構(gòu)，《集成模塊化航空電子設(shè)備 (IMA) 開發(fā)指南和認證問題（DO-297）》提出IMA平臺需要提供分區(qū)的服務(wù)，以便為平臺上所承載的共享平臺資源的應(yīng)用提供足夠的分隔和隔離，并且在一旦發(fā)生失效導(dǎo)致分區(qū)機制被破壞時，能夠檢測到失效并采取失效響應(yīng)措施，以最終實現(xiàn)“健壯分區(qū)（Robust Partitioning）”[2]。

如果分區(qū)沒有被正確實現(xiàn)，會導(dǎo)致直接影響安全性問題，包括了：

●錯誤地寫數(shù)據(jù)到錯誤的區(qū)域；

●從另一個應(yīng)用竊取運行時間；

●使處理器崩潰；

●破壞I/O;

●破壞輸入數(shù)據(jù)；

●獨占內(nèi)部通信通道；

●破壞共享的閃存文件系統(tǒng)；

●在向新分區(qū)進行上下文切換時引入時間抖動。

顯而易見，要實現(xiàn)良好的軟件分區(qū)設(shè)計，絕不是僅僅靠軟件工程師能完成的。分區(qū)設(shè)計是一項高度復(fù)雜的系統(tǒng)工程，需要設(shè)計人員對系統(tǒng)、硬件和軟件體系結(jié)構(gòu)具備深刻的理解。在波音或空客等OEM中，軟件分區(qū)設(shè)計的往往由首席電子架構(gòu)專家主導(dǎo)完成。

03

分區(qū)設(shè)計的三大方面

無論是汽車還是航空，要實現(xiàn)所謂的“Robust Partitioning”，主要在計算平臺的三個子系統(tǒng)中進行分區(qū)設(shè)計：內(nèi)存、中央處理器（CPU）和I/O。

●共享內(nèi)存（空間分區(qū)設(shè)計）

空間分區(qū)的根本在于阻止一個分區(qū)中的功能破壞或覆蓋另一個分區(qū)中的某功能的數(shù)據(jù)空間。一般通過硬件和軟件兩種方式實現(xiàn)對共享內(nèi)存的空間分區(qū)設(shè)計?；谟布姆绞酵ㄟ^CPU自帶的MMU或MPU來實現(xiàn)內(nèi)存訪問的權(quán)限控制。另一種通過軟件的方式則是在每個內(nèi)存訪問點上，對代碼加入邏輯校驗，通過檢查地址寄存器中的內(nèi)容，確保所訪問的內(nèi)存是正確的[4]。

●共享CPU（時間分區(qū)設(shè)計）

時間分區(qū)的目標是確保一個分區(qū)中的功能不干擾另一個分區(qū)中的事件的時間。除了對使用CPU的訪問時長、運行速率、延遲、抖動等進行精密地設(shè)計外，為確保絕對安全，ARINC 653標準對涉及安全的不同分區(qū)采取強制的輪轉(zhuǎn)制度，采用指定的運行時長和周期[3]。而在單個分區(qū)內(nèi)部，則采用其它的調(diào)度器。此外，中斷設(shè)計不當會對時間分區(qū)進行破壞，比較保守的方法包括徹底禁止中斷來確保安全組件的運行。其他容易破壞時間分區(qū)的因素還包括了調(diào)度溢出、計時器損壞、控制流缺陷或軟件缺陷等。這些因素都需要經(jīng)安全分析后被識別并驗證。

●共享I/O

共享I/O的種類和作用繁多，包括串口、交換機在內(nèi)的各種端口、設(shè)備、通道都可能被多個分區(qū)所共享。共享I/O分區(qū)需要同時考慮時間分區(qū)和空間分區(qū)。ARINC653對于共享I/O提供了取樣（Sampling）和隊列（Queuing）的操作機制，確保端口被有序使用。

04

幾個關(guān)鍵的分區(qū)設(shè)計和驗證活動

● 分區(qū)分析

DO-297要求應(yīng)開展完整的分區(qū)分析（Partitioning Analysis），來表明滿足了整個系統(tǒng)的分區(qū)要求。該分析過程和系統(tǒng)安全分析類似，分區(qū)分析工程師可以通過FTA或FMEA的形式，分析出分區(qū)失效鏈，證明所有影響分區(qū)需求的系統(tǒng)性失效或硬件隨機失效被識別、分類和控制。DO-297從系統(tǒng)性失效的角度，例舉了影響分區(qū)設(shè)計的潛在失效，從而更好的幫助設(shè)計人員自底向上的分區(qū)分析[2]：

中斷和中斷禁止（軟件和硬件）；

循環(huán)，例如無限循環(huán)或間接無終止地調(diào)用循環(huán)；

實時通信，如時間幀溢出、實時時鐘干涉、計數(shù)器/計時器破壞、流水線和高速緩存，以及確定性調(diào)度；

控制流，例如不正確地從一個分支進入一個分區(qū)或受保護地區(qū)域、一個跳轉(zhuǎn)表地破壞、處理器順序控制地破壞、返回地址地破壞，以及不可恢復(fù)地硬件狀態(tài)破壞（如屏蔽和關(guān)機）；

內(nèi)存、輸入/輸出的競爭；

數(shù)據(jù)標志共享；

軟件陷阱，例如被零除、未實現(xiàn)的指令、特定的軟件中斷指令、不識別的指令，以及遞歸終止；

停頓的命令，即性能障礙；

輸入或輸出數(shù)據(jù)丟失；

輸入或輸出數(shù)據(jù)破壞；

內(nèi)部數(shù)據(jù)破壞，例如直接或間接內(nèi)存寫入、表溢出、不正確的鏈接、涉及時間的計算，以及破壞高速緩存；

延遲的數(shù)據(jù)；

程序覆蓋；

緩沖區(qū)順序；

外部設(shè)備交互，例如數(shù)據(jù)丟失、數(shù)據(jù)延遲、不正確數(shù)據(jù)、以及協(xié)議停機等。

分區(qū)分析從本質(zhì)上是系統(tǒng)安全分析的擴展，需要與系統(tǒng)安全工程師保持密切協(xié)調(diào)；并且，與系統(tǒng)安全分析一樣，需要在分區(qū)開發(fā)初期就進行分區(qū)分析，并根據(jù)開發(fā)進展不斷更新迭代分區(qū)分析結(jié)果，直到每一個被識別出的分區(qū)失效根因都被完整識別、分析和緩解。

● RTOS SVA分析

分區(qū)設(shè)計和RTOS是緊密相關(guān)的，而操作系統(tǒng)軟件本身的“脆弱性（Vulnerability）”，通常也會成為導(dǎo)致分區(qū)失效的因素之一。RTOS的脆弱性可以是作為軟件本身的一些固有缺陷，如果集成方應(yīng)對不當，則會對數(shù)據(jù)一致性、任務(wù)、調(diào)度、中斷、內(nèi)存訪問等造成不利影響。因此，一個完整的分區(qū)分析，還需要建立在對操作系統(tǒng)的“軟件脆弱性分析（Software Vulnerability Analysis）”的仔細評估的基礎(chǔ)上。SVA清單一般都能從RTOS供應(yīng)商處獲得，如航空領(lǐng)域廣泛使用的風河VxWorks653。對于分區(qū)分析工程師來說，需要將SVA作為分區(qū)分析的重要輸入之一，識別并分析出RTOS SVA中所述的操作系統(tǒng)異常是否會對分區(qū)效果產(chǎn)生潛在的不利影響。

● 數(shù)據(jù)流/控制流分析

數(shù)據(jù)流/控制流分析往往和分區(qū)分析是兩個活動，但卻有著微妙的聯(lián)系：即便分區(qū)機制做的再完善，一旦數(shù)據(jù)流/控制流分析不到位，那不論是不同分區(qū)間必要的數(shù)據(jù)交互、抑或是單個分區(qū)內(nèi)部的數(shù)據(jù)交互，都可能引入共因失效或級聯(lián)失效。因此，軟件分區(qū)不能保證避免數(shù)據(jù)或控制的耦合出現(xiàn)問題；反之，數(shù)據(jù)/控制流問題也不意味著分區(qū)機制有著缺陷。一個建立在完整數(shù)據(jù)流/控制流分析之上的分區(qū)分析，往往會更有價值。

● 評審Checklist

詳細的分區(qū)設(shè)計評審是必需的，并且需要保證評審的獨立性。美國聯(lián)邦航空局的審定專家Leanna Rierson提出了建議的分區(qū)評審清單[4]，便于從數(shù)據(jù)流和控制流兩個維度對分區(qū)設(shè)計進行檢查。

數(shù)據(jù)流相關(guān)：

分區(qū)是否會被數(shù)據(jù)流破壞？

共享數(shù)據(jù)是否會被不恰當使用？

消息是否會被不正確發(fā)送或接收？

函數(shù)參數(shù)是否會被不恰當使用？

配置數(shù)據(jù)是否會無效？

數(shù)據(jù)是否會被不正確傳遞？

數(shù)據(jù)是否會被不正確地初始化？

全局數(shù)據(jù)是否會被不正確地讀或?qū)懀?/p>

全局數(shù)據(jù)是否會被非預(yù)期的函數(shù)錯誤地寫？

全局數(shù)據(jù)是否會未初始化或者不正確地再次初始化？

硬件寄存器是否會被不恰當?shù)厥褂茫?/p>

鏈接器是否會不正確地組裝數(shù)據(jù)或代碼？

數(shù)據(jù)是否會變得陳腐或無效嗎？數(shù)據(jù)會丟失？

是否會發(fā)生對數(shù)據(jù)的錯誤比較的不正確響應(yīng)？

是否會出現(xiàn)非預(yù)期的浮點值？

控制流相關(guān)：

分區(qū)是否會被控制流破壞？

函數(shù)是否會在一個特征內(nèi)或特征之間被不恰當?shù)卣{(diào)用？

中斷是否會引起錯誤的行為？

硬件故障或失效是否會影響數(shù)據(jù)完好性或執(zhí)行順序？

模式間的轉(zhuǎn)換是否會不正確地實現(xiàn)？

資源是否會被不恰當?shù)胤峙洌?/p>

非激活代碼是否會被不經(jīng)意地激活？

初始化順序是否會不正確？

是否會發(fā)生對異常的不恰當響應(yīng)？

故障處理程序是否會動作不恰當(例如,丟失故障或失效，或者不正確地處理故障或失效）？

是否會發(fā)生內(nèi)存重疊？

是否會讀或?qū)懖徽_的硬件地址？

在復(fù)位時是否會發(fā)生不恰當?shù)捻憫?yīng)？

同步是否會被錯誤的比較或錯誤的等待影響？

不正確的上下文切換是否會引起錯誤的數(shù)據(jù)或計時？

是否會生成任何非預(yù)期的異常？

函數(shù)是否會以不正確的速率或時間執(zhí)行？

●分區(qū)機制的測試

針對分區(qū)機制的測試可以通過仿真或臺架測試來完成，通過故障注入來制造破壞時間分區(qū)和空間分區(qū)的情況，從而來證明分區(qū)的完好性。嚴格來說，測試的工作量往往取決于前期識別得到的分區(qū)失效根因的數(shù)量。但在工程實踐中，諸多涉及硬件細節(jié)或底層設(shè)備驅(qū)動的故障難以通過測試來進行，部分將納入到分區(qū)分析中，以安全性分析的形式完成驗證。

05

總結(jié)

軟件分區(qū)設(shè)計所面對的絕大部分失效根因，都屬于系統(tǒng)性失效。因此，一個優(yōu)秀的分區(qū)設(shè)計除了對人員的技術(shù)能力有著極高要求，更要求企業(yè)具備完整的電子軟硬件開發(fā)流程，缺乏體系基礎(chǔ)的分區(qū)設(shè)計往往是空中樓閣。航空制造業(yè)在漫長的適航安全審定過程中，逐漸建立了嚴密的研發(fā)流程體系。在對安全日益重視的汽車行業(yè)，這也必將是國內(nèi)各汽車OEM的發(fā)展方向。