航空電子系統的云計算模型研究

段海軍， 郭勇， 陳福

(1.沈陽飛機設計研究所揚州協同創新研究院有限公司, 揚州 225006; 2.中國航空工業集團公司西安航空計算技術研究所, 西安 710119)

航空電子系統涵蓋了飛機的通信、導航、雷達、電子戰、飛行控制和管理等電子子系統，同時也包括這些系統間用于信息交換和資源共享的信息綜合系統，航空電子系統的發展經歷了分布式、聯合式、綜合化模塊化的階段[1-5]，現已進入分布式綜合化模塊化的發展階段，即分布式綜合化模塊化航空電子系統(distributed integrated modular avionics，DIMA)。DIMA采用分布式系統架構和高容錯的實時通信網絡，將分布于整個飛機范圍內的分布式模塊化電子(distributed modular electronics，DME)相連接，為系統提供存儲、計算和網絡通信等功能[6-8]。

隨著計算機硬件、軟件和網絡等技術的飛速發展，航空電子系統對平臺管理提出了更高的要求。云技術可以提高機載資源的利用率，同時提升軟件的復用能力。云技術整合了局域網內的網絡技術、信息技術、整合技術、管理平臺技術和應用技術等，組成資源池，按需使用，靈活便利。

航空電子云計算的關鍵技術有：計算虛擬化、網絡虛擬化、存儲虛擬化及平臺管理等技術。針對虛擬化技術，文獻[9-13]將航空電子云分為多層結構，一般包括基礎設施層、平臺服務層和應用軟件層。資源管理技術目前研究針對負載均衡，文獻[14]提出一種邊緣計算環境下聯合云模型的任務處理方法HEELS，解決了任務高效部署的問題，促進云邊各計算節點的負載均衡；文獻[15]提出了分布式在線優化算法，通過時間解耦將多核并行云計算中復雜的資源調度問題解耦為處理器內核的CPU時間分配和電壓配置、服務器之間以及服務器內部不同處理器內核之間的數據分發調度三個子問題分別同時優化，實現云計算中心能源效率最高；文獻[16]設計了一種基于EEMD方法和自回歸整合移動平均模型相結合的短期預測算法，解決突發非穩定的資源需求；文獻[17]提出一種基于分布式架構管理模式的延遲敏感在線負載分配與任務調度算法，其通過對云霧計算系統整體任務處理過程的優化，降低云霧計算系統的任務服務延遲；文獻[18-19]提出一種基于強化學習的資源優化分配策略構建方法，實現實施響應用戶負載動態變化。針對分布式存儲系統的研究，文獻[20]設計一種面向多機協同的分布式航空云文件存儲系統，實現航空計算存儲資源的跨機整合和海量數據的多機協同；文獻[21]將區塊鏈融入到端邊云架構中，使多參與方之間進行可信的數據交互。針對云平臺故障檢測的研究，文獻[22]設計了云計算平臺故障檢測與恢復能力測評體系，用于評估云計算平臺。當前航空電子(或嵌入式電子)云模型為概念模型，并沒有結合相關的行業標準對其進一步細化，缺少對工程應用的指導。本文結合行業標準，對航空電子云模型進一步細化，并從航空電子系統中資源虛擬化、平臺管理和應用軟件接納等角度，對航空電子云模型進行了研究。

現分析行業內的相關標準(ARINC653標準和FACE標準)，結合相關標準設計多層次架構航空電子云；針對計算虛擬化、存儲虛擬化和網絡虛擬化等關鍵的虛擬化技術提出具體的方案；結合工程實踐，設計云平臺的平臺管理方案；最后對應用軟件的接納展開研究。

1 行業標準

1.1 ARINC653標準

ARINC653是針對綜合化模塊化航空電子系統(integrated modular avionics, IMA)的需求而提出的一種多分區操作系統接口標準。通過抽象的應用運行接口(APplication/EXecutive, APEX)保障應用軟件和操作系統之間的松耦合，提高軟件的可重用性；時間/空間分區管理保障航空電子系統軟件相互獨立，避免軟件故障蔓延。基于ARINC653標準的軟件架構如圖1所示。ARINC653通過內存管理單元(memory management unit,MMU)保證空間分區的空間隔離，通過嚴格的時間周期輪轉調度訪問完成時間分區調度，在分區內可實現優先級調度或者輪轉調度策略。

圖1 基于ARINC653標準的軟件架構Fig.1 Software architecture based on ARINC653 standard

一個分區是一個獨立的應用環境，由數據、上下文關系、配置屬性和其他項組成，所有分區共享系統資源，分區的運行要滿足時間和空間的要求。分區在時間調度上是固定的，按照調度算法預先確定，并按照固定周期重復執行，而分區之間是沒有優先級的。分區之間所占用的存儲空間是獨立，一個分區的執行并不會影響到其他分區。

可將多個應用軟件按照功能劃分為多個分區，一個分區可有一個或多個進程。依據二進制配置文件為分區分配執行所需的時間資源和空間資源，從而保證每個應用軟件擁有獨立的計算資源和存儲資源。分區操作系統可以配置不同的客戶操作系統(VxWorks、天脈、Windows、Linux)，從而保障了應用軟件的多樣性和可移植性。

1.2 FACE標準

FACE標準是由開放組織(The Open Group)發布和管理的未來機載能力環境(future airborne capability environment, FACE)標準,主要解決美軍航電軟件重用性和可移植性不高的問題，用于開發軟件通用操作環境開發的技術標準，從而在整個軍事航空界推進軟件可移植性以及軟件產品線的建立。

基于分段的思想，將系統中的軟件劃分為5個段：可移植組件段(portable components segment, PCS)、特定平臺服務段(platform-specific services segment, PSSS)、傳輸服務段(transport services segment, TSS)、IO服務段(input/output services segment, IOSS)和操作系統段(operating system segment, OSS)。各段之間依據FACE標準定義的接口進行銜接和數據交互[23-24]，如圖2所示。

圖2 FACE系統架構Fig.2 Face system architecture

可移植組件段由功能或業務邏輯的軟件組件組成，與硬件和傳感器無關。這些組件不與任何數據傳輸或操作系統綁定，以滿足可操作性和互操作的要求。可移植組件段可在任意不同的硬件計算平臺和軟件環境中部署，最多只需進行重新編譯，或者軟件庫、編程語言運行時需對庫以及應用框架進行重新鏈接。

傳輸服務段由通信服務組成，從軟件組件中抽象傳輸機制和數據訪問，便于將不同的傳輸機制集成到不同的體系結構和平臺中。為可移植組件段和特定平臺服務段提供標準TS接口，負責可移植組件或特定平臺服務之間的數據分發。其功能包括但不限于軟件接口信息的分布和路由、優先級、可尋址性、關聯、抽象、轉換和組件狀態持久性。傳輸服務段可用第三方傳輸組件實現,包括DDS、CORBA。

特定平臺服務段由平臺通用服務、平臺設備服務和圖形服務組成。平臺通用服務由高級別的服務組成，包括日志服務、設備協議中間服務、流媒體、健康監控、故障管理及配置管理組成。平臺設備服務負責平臺接口控制文件(interface control document,ICD)與FACE數據模型之間數據的管理和轉換，充當平臺硬件設備的軟件抽象，消除PCS中平臺設備的可變性，為PCS提供數據和控制能力。圖形服務負責平臺的顯示管理，從軟件組件中抽象出GPU或其他圖形設備的接口。

IO服務段將供應商提供的硬件設備驅動的接口進行規范，為特定平臺服務段提供硬件和設備驅動的抽象接口，從而平臺服務段只需關注接口數據，而不需要關注硬件和設備驅動。用于隔離不同廠商驅動可能給特定平臺服務段軟件帶來影響，在廠商驅動發生變化時，只需修改對應的IO服務組件即可。

操作系統段為其他各個段提供和控制對計算平臺和軟件環境的訪問。包括操作系統、應用軟件運行框架、編程軟件運行框架、操作系統級健康監控和故障管理、配置服務、外部網絡功能、生命周期管理等。操作系統段須支持分區，包括時間分區和空間分區；須支持POSIX和ARINC653。

2 航空電子云架構

2.1 航空電子云概念模型

航空電子云通過高速交換網絡整合機內所有電子模塊的計算資源、存儲資源和網絡資源，實現資源的統一分配、任務統一部署，如圖3所示。

圖3 航空電子云概念模型Fig.3 Avionics cloud conceptual model

將航空電子系統中的通信系統平臺(硬件和平臺軟件)、核心處理系統平臺、飛機管理系統平臺、導航系統平臺、綜合顯示系統平臺、機載維護系統平臺及其他子系統平臺的通過數據交換系統對其硬件資源進行整合，統一為各應用軟件分配資源和部署軟件。各應用軟件作為可移植組件不在固定的部署在某個子系統平臺上，可以部署在任意子系統的平臺上，應用軟件共享航空電子系統計算資源、網絡資源和存儲資源。

2.2 航空電子云層次結構

依據商業云模型的系統架構，結合航空電子系統的特點將系統分為5層：物理資源層、本地資源管理層、資源虛擬化層、平臺管理層和應用功能層，如圖4所示。

圖4 航空電子云層次結構Fig.4 Avionics cloud hierarchy

物理資源包括飛機內所有電子模塊的計算資源、存儲資源、網絡資源及其他資源，作為航空電子任務運行的載體。

本地資源管理負責對電子模塊的資源管理和任務調度。其包括操作系統、文件系統、網絡驅動、存儲驅動、數據庫、操作系統級的健康監控和故障管理及其他的操作系統組件。

資源虛擬將航空電子系統的資源虛擬成多個計算池、存儲池和網絡池，為應用軟件提供運行平臺。提供的服務有虛擬化存儲服務(分布式文件系統和分布式數據庫)、虛擬化網絡服務、虛擬化計算服務。

平臺管理對計算池、存儲池和網絡池進行管理，包括資源分配、平臺健康監控和故障管理等。

應用功能由一組組軟件功能構件組成，執行平臺通用服務功能或具體的航空電子任務，如GPS、雷達、火控管理、飛行控制、數據融合、遠程通信和精確導航等。

2.3 FACE標準航空電子云系統結構

依據FACE分段的思想，結合航空電子云模型各組件功能和可移植性的特點，將其組件部署在FACE系統架構不同的段內，其航空電子云層次結構與FACE標準的對應關系如圖5所示。

圖5 FACE標準的航空電子云Fig.5 Face standard avionics cloud

本地資源管理的任務調度、存儲資源管理及設備驅動軟件(操作系統、文件系統、網絡驅動、存儲驅動、數據庫、OS級的健康監控和管理管理及其他組件)部署于操作系統段內，對本地設備的管理功能則部署于IO服務段中。

資源虛擬化的計算資源虛擬化功能部署于操作系統段中，由其對本地的計算資源進行虛擬化，形成多個計算池，為應用軟件提供獨立的計算平臺；存儲資源虛擬化功能部署于特定平臺服務段中的通用服務中，將存儲資源虛擬成多個存儲池，由分布式文件系統和分布式數據庫實現對存儲池的數據訪問，為每個應用提供獨立的數據存儲區域；網絡虛擬化則部署于傳輸服務段，將網絡總線虛擬成網絡池組，為每個應用提供獨有的網絡通信地址和通信資源。

平臺管理則部署于特定平臺段中通用服務中，對整個航空電子云進行管理。

應用功能層則根據軟件功能，提供平臺設備服務的部署于特定平臺段的設備服務中，提供平臺圖形服務的則部署于特定平臺段的圖形服務中，其他的部署在可移植組件段中。

2.4 航空電子云在分區操作系統中的部署

在航空電子云模型中，機內的電子模塊上部署著符合ARINC653標準的分區操作系統。其航空電子云的平臺管理功能在每個模塊上的都有部署，并且獨占一個分區；虛擬化功能則在每個分區上都有部署，如圖6所示。模塊上的平臺管理功能負責對本模塊的資源管理和任務調度，同時通過高速網絡與其他模塊平臺資源管理功能進行信息交互，協同完成航空電子云平臺的管理；虛擬化功能將分區內的軟件所需計算資源、存儲資源和網絡資源虛擬成獨立運行的資源，為分區內應用軟件的運行提供平臺。

圖6 航空電子云在分區操作系統中的部署Fig.6 Deployment of avionics cloud in partitioned operating system

3 虛擬化技術

3.1 計算虛擬化

計算虛擬化將應用軟件運行所需要的處理器、內存、NVRAM、FLASH等資源虛擬化，為每個應用軟件提供獨立的計算平臺。利用ARINC653標準的分區操作系統的機制，時間分區將處理器資源虛擬成多個獨立的虛擬處理單元，空間分區將內存、NVRAM、FLASH等資源劃分成獨立多個塊，為虛擬處理單元提供基本的運行資源，如圖7所示。

圖7 航空電子系統的計算資源虛擬化Fig.7 Virtualization of computing resources in avionics systems

分區是嚴格按照時間片輪轉調度的，當一個分區的時間片消耗完畢后，不管分區任務是否完成，都會強制切換到下一個分區的程序。分區在時間內獨占處理器的資源，則依據分區個數將處理器資源虛擬成多個虛擬處理單元，虛擬的處理單元在時間片內運行。ARINC653的分區操作系統將計算所需要的內存、NVRAM和FLASH等資源劃分成許多小塊，通過MMU保障各小塊的空間的獨立性，為分區應用軟件的運行提供了所需的資源。一個虛擬處理單元及其對應的內存、NVRAM和FLASH等資源組成一個計算池。機內所有電子模塊的計算池組成了航空電子云所需要的計算池組。

分區內的客戶操作系統提供不同操作系統(包括VxWorks、天脈、Windows、Linux、翼輝等操作系統)和應用軟件所需要的接口庫，便于將運行在不同操作系統上的應用軟件部署在航空電子云系統中。

計算資源的虛擬化利用了ARINC653標準的分區操作系統機制，既能保證關鍵任務的執行，同時在分區內提供了APEX接口，符合FACE標準對接口的要求。

3.2 存儲虛擬化

由于航空電子系統中存儲資源分布不均，只有部分電子模塊上擁有大容量存儲介質，其他模塊需要通過分布式存儲方式存儲數據。將擁有大容量存儲介質的模塊集中起來，形成存儲集群，通過分布式文件系統和分布式數據庫，為各應用軟件提供海量數據存儲和查詢的功能。每個計算池應擁有獨立的存儲空間，通過分布式文件系統為計算池虛擬存儲空間，用以存儲數據；分布式數據庫為計算池提供快速查找和修改數據的能力。將集群中的存儲資源劃分為多個存儲塊，為每個計算池提供虛擬的存儲塊，以滿足應用軟件對存儲的要求，如圖8所示。

圖8 虛擬存儲池Fig.8 Virtual storage pool

存儲集群中的大容量存儲模塊使用文件系統分區功能將大容量存儲器分割成多個存儲塊，為每個存儲塊依次分配文件系統的盤符。分布式文件系統的客戶端掛載(mount)服務器上的文件系統，服務器是以盤符為最小單位掛載單位，保障客戶端的存儲空間獨立性。客戶端將服務器的文件系統掛載到本地虛擬的C盤下，每個客戶端擁有自己獨立的C盤存儲空間，為應用軟件提供數據存儲功能，如圖9所示。計算池需要共享文件時，可在客戶端增加虛擬盤符，用于掛接服務器上共享的文件盤符，多個計算池可訪問同一個文件。分布式文件系統客戶端對外提供標準的文件操作接口，符合FACE標準對接口的要求。

圖9 分布式文件系統原理Fig.9 Principle of distributed file system

分布式數據庫為航空電子云系統提供高效的數據檢索和修改能力。由存儲集群提供數據庫，為各個計算池提供分布式數據檢索和修改的服務。為提高數據的檢索速率，在每個計算池的內存資源充足的情況，允許在內存中存儲數據庫的副本(部分或全部副本)，如圖10所示。

圖10 分布式數據庫原理Fig.10 Principle of distributed database

分布式數據庫客戶端的全局數據庫管理解析應用軟件命令，判斷本地是否有副本，如果有則訪問本地的副本，否則訪問遠程服務器的主本；遠程數據庫管理提供遠程訪問遠程數據庫的主本能力，并保持主副本的數據同步。分布式數據庫服務器響應客戶端的數據庫訪問請求，并時刻與客戶端的副本數據保持同步；提供訪問控制功能，檢查用戶的身份，用戶只能訪問已授權的數據庫。使用數據庫的訪問控制功能可以使每個計算池擁有自己獨立的數據庫，同時又可以共享部分數據庫。

3.3 網絡虛擬化

網絡虛擬化將物理網絡資源(包括FC、1553B、模擬量、離散量、RS422等通信總線或網絡)進行抽象形成虛擬網卡(網絡池)，滿足各計算池對網絡資源的分割，如圖11所示。在航空電子系統中的通信網絡由主通信網絡(FC網絡)和特有通信網絡或總線組成，其中大部分設備通過FC網絡相連接，組成主通信網絡，部分設備通過特有通信資源(模擬量、離散量、1553B等)與主網絡中的設備相連，組成了覆蓋全航空電子系統的數據通信網絡,其虛擬化網絡體系架構如圖12所示。

圖11 網絡虛擬化Fig.11 Network virtualization

圖12 虛擬化網絡體系架構Fig.12 Virtualized network architecture

虛擬網卡為計算池提供了數據交換的服務，其中包括數據通信服務、發布/訂閱服務、QOS服務等，如圖13所示。虛擬網卡為應用軟件提供了符合FACE標準的通信接口，應用軟件通過TS接口訪問虛擬網卡，可以接收或發送任意總線的數據。虛擬化網卡將應用軟件和物理總線進行邏輯隔離，應用軟件并不需要關心數據傳輸的路徑和物理總線，僅需關注數據內容，降低了應用軟件與部署模塊的耦合度，增強了軟件的移植性。

圖13 虛擬交換Fig.13 Virtual switch

虛擬網絡支持數據的發布訂閱，發布方的應用軟件通過虛擬網卡發布主題數據，虛擬交換網絡將數據路由到所有訂閱方的虛擬網卡，訂閱方的應用軟件通過虛擬網卡收取主題數據。為保證虛擬網路數據的準確性、可靠性和實時性，虛擬網絡支持QOS服務，提供了可靠傳輸、截止期、時間過濾、存活性等服務質量。

數據發布訂閱關系表建立了主題發布方和訂閱方的關系，格式如表1所示。

表1 發布訂閱關系表Table 1 Publish subscribe relationship table

系統動態建立的發布訂閱關系，在應用軟件使用虛擬網卡發布主題時，將虛擬網卡的地址和主題信息存儲在本地的發布訂閱關系表中；訂閱主題時，向虛擬網絡中廣播訂閱的主題和網卡地址；虛擬交換機的發布訂閱關系維護功能接收到訂閱主題時，查找本地的發布訂閱關系表中是否有發布的主題，在主題和QOS一致的情況下，將訂閱者的通信地址在發布訂閱關系表中更新。網絡數據路由接收到應用軟件發布的主題數據時，依據發布訂閱關系表獲取所有訂閱者的網絡地址，將其主題數據發送給所有的訂閱者。

每個計算池擁有一個虛擬網卡，每個網卡擁有一個獨立的通信地址，計算池依據網卡的通信地址進行通信，虛擬交換機依據數據路由配置表對其數據路由，實現模塊內及模塊間計算池的數據通信，其數據路由配置表如表2所示。

表2 數據路由配置表Table 2 Data routing configuration table

針對航空電子系統的通信資源分布不均的特點，虛擬交換機支持對本節點特有通信資源(除主通信網絡之外的資源)的管理，虛擬交換機從內存或主通信網絡中訂閱需要通過本模塊特有通信資源發送的主題數據，并將數據通過對應的物理總線發送；從總線上收取數據，并在內存或主通信網絡中發布相關主題數據。依據物理鏈路配置表管理主題與總線的對應關系，在主題數據物理傳輸路徑發生變化時，只需修改主題與總線的對應關系。

物理鏈路配置表管理著主題數據與實際物理鏈路的對應關系，格式如表3所示。物理鏈路配置表是由系統開發人員靜態配置，虛擬交換機的特有設備管理器在系統加電后，訂閱物理鏈路配置表中的發送主題，發布物理鏈路配置表中的接收主題；在系統運行過程中，將訂閱到的主題數據依據物理鏈路配置表中主題對應的物理鏈路和參數，通過相應的總線發送數據；從主題對應的物理鏈路上接收主題數據，并將其通過虛擬網絡發布主題數據。

表3 物理鏈路配置表Table 3 Physical link configuration table

在航空電子云模型中，一個計算池對應一個分區，計算池只有一個虛擬網卡。分區操作系統的時間分區機制保證虛擬網卡對FC網絡的訪問時間，不受其他虛擬網卡的影響，有效的對網絡資源進行分割，保證了虛擬網卡的獨立性。

4 平臺管理技術

4.1 平臺管理架構

航空電子云系統的平臺管理分為兩級，系統級和模塊級，系統級平臺管理部署在某個電子模塊上負責航空電子云系統平臺的管理，模塊級平臺管理在每個電子模塊上均有部署，負責電子模塊的管理，模塊級平臺管理接受系統級的統一管理，如圖14所示。

圖14 平臺管理架構Fig.14 Platform management architecture

模塊級平臺管理負責本模塊計算池的資源分配、任務調度、健康監控和故障管理；系統級平臺管理通過與模塊級的信息交互，獲取系統所有計算池的資源、任務和健康情況，統一為應用軟件調度和分配航空電子云平臺中的資源。

為避免系統級平臺管理失效導致云平臺失控，系統級平臺管理采取了主從熱備份的方式。主系統級平臺管理擁有平臺的控制權；從系統級平臺管理只能獲取平臺的資源信息，并沒有平臺的控制權。從系統級平臺管理實時監控主系統級平臺管理的狀態，在主系統級失效后，從系統級切換為主系統級平臺管理，接管系統平臺的控制權。主系統級和從系統級平臺管理應部署在不同子系統中，增強系統的抗風險能力。

4.2 資源管理

航空電子云平臺提供了多個具有一定資源的計算池，在部署應用軟件時依據軟件所需資源情況，選擇合適的計算池運行應用軟件。系統開發人員為計算池的分配資源，形成計算池信息表，如表4所示。

表4 計算池信息表Table 4 Compute pool information table

系統初始化時依據計算池信息表創建計算池，并為其分配存儲資源和網絡資源。各模塊的平臺管理軟件依據計算池表中本模塊的計算池的資源為其創建計算池(分區)，分配內存、NVRAM、FLASH等資源，計算池啟動時掛載遠程的存儲器和數據庫，如圖15所示。

圖15 系統初始化流程Fig.15 System initialization process

計算池的操作系統既是ARINC653標準操作系統的分區操作系統；計算資源的大小是由本模塊的處理能力乘以計算池在本模塊運行的時間比，依據計算資源的大小，分配分區調度表中，每個分區的時間片，將分區時間片在總時間框內的占比達到對計算池處理能力的要求；內存、NVRAM、FLASH等資源則是由ARINC653標準操作系統的配置工程進行劃分，依據所需要資源的大小，為本模塊上每個計算池在配置工程里分配合符合要求的物理空間。在配置ARINC653標準操作系統的配置時，依據計算池中的信息進行靜態配置。計算池的創建則利用操作系統創建分區的功能，操作系統創建分區和啟動分區既是完成了計算池的創建和啟動。

存儲集群中的大容量存儲模塊依據計算池中信息，初始化本地的文件系統并按照其存儲大小和盤符要求將其分區，并完成分布式文件系統服務器端的初始化。計算池在初始化分布式文件系統的客戶端時使用MOUNT協議掛載所對應的大容量存儲模塊的設備盤，為本計算池創建虛擬的存儲盤。大容量存儲模塊依據計算池信息表中的創建本地數據庫，并初始化分布式數據庫的服務器端；計算池在初始化時完成分布式數據庫客戶端的初始化。

系統級平臺管理軟件在接收到應用軟件時，依據應用軟件對計算資源、操作系統、NVRAM等資源的需求，從未使用的計算池中查找符合要求的計算池。在找到合適的計算池時，將應用軟件映像發送給相應的模塊級平臺管理軟件，由模塊級平臺管理軟件使用分區的動態加載技術，將應用軟件加載到相應的計算池中，完成應用軟件的加載和啟動。系統級平臺管理將已分配出的計算池的使用標志設置為已使用。應用軟件在啟動過程中，使用TS接口發布主題和訂閱主題，在計算池中創建虛擬網卡，啟動后則可以與其他系統或者應用軟件進行通信。

4.3 健康監控

健康監控負責對計算池、網絡池和存儲池等資源的健康情況進行監控。模塊級健康監控負責對模塊內資源狀態進行監控；系統級健康監控負責對航空電子云平臺資源狀態進行監控。健康監控的軟件架構如圖16所示。

圖16 健康監控軟件架構Fig.16 Health monitoring software architecture

模塊級健康監控的方式有BIT(自檢測)、OS級健康監控、網絡檢測、電壓檢測和狀態集采等方式。BIT檢測電子模塊的CPU、內存、NVRAM、FLASH等資源；網絡檢測負責檢測通信網絡或總線資源，包括FC網絡、RS422、1553B、模擬量、離散量等資源；狀態采集監控模塊的模塊、光電收發器的功率、及模塊的電流電壓等；OS-HM負責監控本模塊所有計算池(分區)的異常信息。在BIT、網絡檢測和狀態采集發現故障后，則該模塊的上所有計算池故障；OS-HM監測到某個計算池故障，則為單個計算池故障。

系統級健康監控通過查詢模塊級健康監控的生命消息和收集其故障信息監控平臺的健康狀態。系統級健康監控周期性的向模塊級健康監控發送查詢生命消息的命令，在規定的時間內沒有接收到模塊級健康監控回復的生命消息，則認為該模塊上的所有計算池故障；模塊級健康監控在監測到本模塊計算池故障后，將其故障信息上報給系統級健康監控。系統級健康監控監測到某個計算池故障后，則將計算池信息表中該計算池的狀態設置為故障。

4.4 故障管理

故障管理在接收到健康監控檢測到故障信息后，負責對該故障進行處理，如圖17所示。對本模塊內計算池的故障處理，無法處理的故障則上報給系統級故障處理；系統級故障管理負責對平臺所有的故障進行處理。模塊級故障管理有OS級故障處理、故障信息記錄等；系統級故障管理有應用軟件遷移、故障信息記錄等。

圖17 故障管理Fig.17 Fault management

OS-FM提供豐富的故障處理動作，包括分區重啟、分區掛起、任務重啟等，可以用于對計算池故障進行處理；故障信息記錄將系統所產生的故障以故障日志的形式記錄在系統中，便于系統維護人員解析故障，維護系統；在某個計算池故障，無法繼續承擔計算任務后，將其應用軟件遷移到其他計算池中繼續運行。

應用軟件在遷移時，由系統級故障管理向故障計算池所在的模塊級故障管理發送計算池掛起命令；模塊級故障管理將該計算池掛起；系統級管理管理從計算池信息表中查找符合應用軟件需求的、未使用的計算池，將應用軟件加載到新計算池中。為保證任務執行的連續性，在計算池啟動后，掛載原計算池的存儲空間和數據庫。應用軟件遷移工作原理如圖18所示。

圖18 應用軟件遷移原理圖Fig.18 Schematic diagram of application software migration

4.5 其他管理功能

航空電子云系統提供日志管理功能和配置管理功能。日志管理功能記錄系統中的事件、故障信息及應用軟件部署情況，模塊級日志管理功能將本模塊內的日志信息記錄在本地的NVRAM中，系統級日志管理功能將系統的日志信息記錄在大遠程的大容量存儲模塊上。日志管理功能便于系統開發人員分析平臺的運行情況，依據日志信息快速的定位故障。

配置管理功能可配置計算池的運行的應用軟件。對于某些對特定通信資源實時性要求高的應用軟件，可以使用配置管理功能將其固定部署在具有相應資源模塊的計算池中運行。其他應用軟件則由平臺的資源管理根據系統情況部署應用軟件。

5 應用軟件接納

航空電子云系統未提供虛擬化操作界面，用戶無法通過界面操作選擇所需的資源、部署和運行應用軟件。用戶需將應用軟件所需資源、軟件映像、數據庫及其他特殊需求提供給系統開發人員。系統開發人員依據應用軟件所需的資源生成應用軟件需求表，其內容如表5所示。

表5 應用軟件需求表Table 5 Application software requirement table

系統開發人員將應用軟件需求表、計算池信息表、軟件映像、數據庫及其他文件通過FTP上傳給航空電子云平臺的某個大容量存儲模塊上。平臺的系統級資源管理功能從服務器中獲取相關文件，對平臺資源是否滿足應用軟件需求進行檢查，在不滿足的情況下，通過串口打印或其他方式提醒系統開發人員。系統開發人員對計算池信息表進行調整，以滿足應用軟件的需求。應用軟件接納的過程如圖19所示。

圖19 應用軟件接納原理Fig.19 Application software acceptance principle

平臺的系統級資源管理功能確認平臺資源能夠滿足應用軟件的需求，則應用軟件被接納，否則不被接納。在應用軟件被接納后，資源管理功能首先查找由特殊需求的應用軟件，為其分配計算池，然后為其他的應用軟件分配計算池。平臺級資源管理功能將其計算池的分配信息傳送給各模塊級資源管理功能，由各模塊級資源管理功能獲取軟件映像，并加載到相應的計算池中，啟動應用軟件。

6 結論

結合行業標準和工程經驗，對航空電子云模型進行了研究。

(1)分析了航空電子領域的ARINC653標準和FACE標準，結合行業標準設計了航空電子云模型。

(2)研究了虛擬化技術，設計了計算虛擬化、網絡虛擬化、存儲虛擬化的方案。

(3)討論了平臺管理技術，設計了航空電子云系統的資源管理、健康管理和故障處理的方案。

后續計劃針對航空電子云存儲、服務器的負載均衡等技術進一步研究。