01

軟件分區的推動力

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

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

在汽車功能安全領域，ISO26262和AutoSAR等相關標準都提到了軟件安全分區的一些設計原則。而航電系統也在數十年的研發和審定過程中，針對軟件分區形成了許多寶貴的經驗，值得我們思考和借鑒。

02

DO-178和DO-297

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

●一個分區的軟件組件不應被允許破壞另一個分區的軟件組件的代碼、輸入/輸出（I/O）、或數據存儲區域。

●一個分區的軟件組件應當只有在其得到調度的執行時段中，才被允許使用共享處理器的資源。

●一個分區的軟件組件獨有的硬件失效不應對其他分區的軟件組件產生不利影響。

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

●任何提供分區的硬件應當得到系統級安全評估，以確保它不會對安全性產生不利影響。

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

如果分區沒有被正確實現，會導致直接影響安全性問題，包括了：

●錯誤地寫數據到錯誤的區域；

●從另一個應用竊取運行時間；

●使處理器崩潰；

●破壞I/O;

●破壞輸入數據；

●獨占內部通信通道；

●破壞共享的閃存文件系統；

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

顯而易見，要實現良好的軟件分區設計，絕不是僅僅靠軟件工程師能完成的。分區設計是一項高度復雜的系統工程，需要設計人員對系統、硬件和軟件體系結構具備深刻的理解。在波音或空客等OEM中，軟件分區設計的往往由首席電子架構專家主導完成。

03

分區設計的三大方面

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

●共享內存（空間分區設計）

空間分區的根本在于阻止一個分區中的功能破壞或覆蓋另一個分區中的某功能的數據空間。一般通過硬件和軟件兩種方式實現對共享內存的空間分區設計。基于硬件的方式通過CPU自帶的MMU或MPU來實現內存訪問的權限控制。另一種通過軟件的方式則是在每個內存訪問點上，對代碼加入邏輯校驗，通過檢查地址寄存器中的內容，確保所訪問的內存是正確的[4]。

●共享CPU（時間分區設計）

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

●共享I/O

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

04

幾個關鍵的分區設計和驗證活動

● 分區分析

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

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

循環，例如無限循環或間接無終止地調用循環；

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

控制流，例如不正確地從一個分支進入一個分區或受保護地區域、一個跳轉表地破壞、處理器順序控制地破壞、返回地址地破壞，以及不可恢復地硬件狀態破壞（如屏蔽和關機）；

內存、輸入/輸出的競爭；

數據標志共享；

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

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

輸入或輸出數據丟失；

輸入或輸出數據破壞；

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

延遲的數據；

程序覆蓋；

緩沖區順序；

外部設備交互，例如數據丟失、數據延遲、不正確數據、以及協議停機等。

分區分析從本質上是系統安全分析的擴展，需要與系統安全工程師保持密切協調；并且，與系統安全分析一樣，需要在分區開發初期就進行分區分析，并根據開發進展不斷更新迭代分區分析結果，直到每一個被識別出的分區失效根因都被完整識別、分析和緩解。

● RTOS SVA分析

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

● 數據流/控制流分析

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

● 評審Checklist

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

數據流相關：

分區是否會被數據流破壞？

共享數據是否會被不恰當使用？

消息是否會被不正確發送或接收？

函數參數是否會被不恰當使用？

配置數據是否會無效？

數據是否會被不正確傳遞？

數據是否會被不正確地初始化？

全局數據是否會被不正確地讀或寫？

全局數據是否會被非預期的函數錯誤地寫？

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

硬件寄存器是否會被不恰當地使用？

鏈接器是否會不正確地組裝數據或代碼？

數據是否會變得陳腐或無效嗎？數據會丟失？

是否會發生對數據的錯誤比較的不正確響應？

是否會出現非預期的浮點值？

控制流相關：

分區是否會被控制流破壞？

函數是否會在一個特征內或特征之間被不恰當地調用？

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

硬件故障或失效是否會影響數據完好性或執行順序？

模式間的轉換是否會不正確地實現？

資源是否會被不恰當地分配？

非激活代碼是否會被不經意地激活？

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

是否會發生對異常的不恰當響應？

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

是否會發生內存重疊？

是否會讀或寫不正確的硬件地址？

在復位時是否會發生不恰當的響應？

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

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

是否會生成任何非預期的異常？

函數是否會以不正確的速率或時間執行？

●分區機制的測試

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

05

總結

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