01

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

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

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

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

02

DO-178和DO-297

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

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

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

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

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

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

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

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

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

●從另一個(gè)應(yīng)用竊取運(yùn)行時(shí)間；

●使處理器崩潰；

●破壞I/O;

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

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

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

●在向新分區(qū)進(jìn)行上下文切換時(shí)引入時(shí)間抖動(dòng)。

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

03

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

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

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

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

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

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

●共享I/O

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

04

幾個(gè)關(guān)鍵的分區(qū)設(shè)計(jì)和驗(yàn)證活動(dòng)

● 分區(qū)分析

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

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

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

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

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

內(nèi)存、輸入/輸出的競(jìng)爭(zhēng)；

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

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

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

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

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

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

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

程序覆蓋；

緩沖區(qū)順序；

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

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

● RTOS SVA分析

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

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

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

● 評(píng)審Checklist

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

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

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

共享數(shù)據(jù)是否會(huì)被不恰當(dāng)使用？

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

函數(shù)參數(shù)是否會(huì)被不恰當(dāng)使用？

配置數(shù)據(jù)是否會(huì)無(wú)效？

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

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

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

全局?jǐn)?shù)據(jù)是否會(huì)被非預(yù)期的函數(shù)錯(cuò)誤地寫？

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

硬件寄存器是否會(huì)被不恰當(dāng)?shù)厥褂茫?/p>

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

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

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

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

控制流相關(guān)：

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

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

中斷是否會(huì)引起錯(cuò)誤的行為？

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

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

資源是否會(huì)被不恰當(dāng)?shù)胤峙洌?/p>

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

初始化順序是否會(huì)不正確？

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

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

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

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

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

同步是否會(huì)被錯(cuò)誤的比較或錯(cuò)誤的等待影響？

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

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

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

●分區(qū)機(jī)制的測(cè)試

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

05

總結(jié)

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