基于Harmony系統工程的IMA應用開發

徐文，熊智勇，張國全

(航空電子系統綜合技術重點實驗室，上海 200233)

隨著航空電子技術的發展，在軍用和民用領域，越來越多的先進機型采用綜合模塊化航空電子(IMA)系統體系架構，如 F-22、A380 等［1］.相比傳統的聯合式架構，IMA系統提供一個統一的硬件平臺，飛機的功能由各個應用實現，每個應用宿主在各自的分區當中，相互獨立，互不干擾，提高了資源利用率，從而極大地減少了飛機的質量和開發成本［2］.Arinc 653規范定義了一種應用與IMA模塊操作系統的接口［3］，稱為 Application/Execution(APEX)接口，應用基于該接口規范進行開發，通過該接口實現與IMA模塊操作系統的數據通信，應用開發人員不需要考慮平臺本身，從而縮短了應用開發周期.美國風河公司開發的嵌入式實時操作系統VxWorks653滿足Arinc653規范，并提供了相應的集成開發環境Workbench.

傳統的基于文檔的開發方法將軟件的設計建立在對純文字需求的理解上，用戶只有在軟件開發的后期，通過系統測試階段的工作才能真正了解軟件的功能和性能是否滿足要求，這將導致修正設計錯誤或更改設計所需的開銷隨著工程階段的深入而成倍地增加.基于模型的開發方法是一種新的軟件開發方法［4］，可以對軟件進行快速的設計、開發、驗證和確認，提高軟件開發效率［5］.通過對軟件進行建模，將文字需求可視化，讓開發人員和用戶對所要開發的軟件這個“未來世界”達成共識［6］，建模過程也是軟件的設計過程，可以邊設計邊測試，當模型得到確認之后就可以進行軟件的實現.IBM公司基于 Rhapsody提出了Rational Harmony系統工程(SE)方法，先在Rhapsody中使用Harmony框架建立IMA應用的軟件模型，再基于此模型使用Workbench進行具體的軟件開發.

1 Harmony系統工程建模

Harmony系統工程方法將系統設計分為3個階段，需求分析階段、系統功能分析階段以及設計綜合階段［7］.建模的目的是讓軟件開發人員對軟件需求有更準確的理解，Harmony系統工程中邊設計邊測試的方法可以快速和清晰地讓一些潛在的設計問題暴露出來，以實現真正滿足需求的軟件設計.

本文結合某預研項目中的無人機控制管理(UAVM)系統介紹了使用Harmony方法的系統建模的實踐過程，軟件開發人員拿到軟件需求文檔，按照以下步驟進行建模:①根據需求分析結果構建系統用例圖;②針對每個用例，構建系統活動圖;③對于每個活動圖，生成時序圖和內部塊圖;④構建系統狀態圖;⑤運行并驗證模型.

1.1 系統用例圖的構建

系統用例圖是對軟件需求的提煉，將需求所要實現的功能進行分組形成用例.UAVM的用例圖如圖1所示.

圖1 UAVM系統用例圖Fig.1 UAVM system use case diagram

UAVM為IMA模塊中的一個分區應用，由無人機控制權交接管理(ConnectionManage)、無人機傳感器控制(SensorControl)、無人機飛行計劃管理(FlightPlanManage)、無人機載機信息處理(RUVInformationProcess)、健康監控管理(Health-Monitor)5個子功能模塊組成，與指揮中心(OC)、地面站(GCS)、目標數據處理(TDP)、無人機(RUV)、顯示處理單元(DPU)、狀態監控(HUM)這些外圍設備進行信息交互.

1.2 系統活動圖的構建

每個用例都有各自的活動圖，它描述的是典型的工作流程，某種意義上就是軟件流程圖，本文以第1個用例控制權管理為例，如圖2所示.

圖2 無人機控制權交接管理活動圖Fig.2 UAV control right transfer manage activity view

構建活動圖時應該關注其與外部系統間的信息交互，控制權管理模塊依次接受來自OC的演示場景編號指令、演示開始控制指令、組網指令、控制權交接指令，根據控制權交接指令確認交接對象，判斷是獲取無人機控制權還是交出無人機控制權，如果是獲取，同時發送控制權移交狀態報告給OC和 GCS，發送與無人機的連接狀態給DPU，反之等待GCS發送控制權移交狀態報告，發送與無人機的連接狀態給DPU.

1.3 系統時序圖的生成

系統時序圖描述的是系統與外部設備的交互的先后順序，時序圖可以根據構建的活動圖自動生成，需要注意的是，時序圖應遍歷活動圖中的每一個活動.用例控制權管理的時序圖如圖3所示.

1.4 系統內部塊圖的生成

內部塊圖反映的是該系統與外部設備之間通過端口連接表示的靜態交聯關系，也就是接口控制文檔(ICD)的圖形化體現，自動生成的內部塊圖如圖4所示.

內部塊圖可以清晰地反映用例與哪些外部系統有信息交互，以及信息交互的內容，以與OC的端口為例，可以看到有4條輸入的信息流和1條輸出的信息流.

圖3 時序圖Fig.3 Sequence diagram

1.5 系統狀態圖的構建與執行

狀態圖描述的是用例在不同場景下基于狀態的行為，根據活動圖和時序圖可以生成初始狀態圖，初始狀態圖主要反映信息的輸入和輸出，通過執行狀態圖，開發人員即可驗證所設計的功能是否和需求一致，用例無人機控制管理的狀態圖的執行如圖5所示.

圖5 系統狀態圖Fig.5 System state diagram

2 IMA系統開發角色

IMA系統主要由兩大構件組成:一是應用，二是IMA模塊［8］.Arinc 653規范中給出了一種IMA模塊結構，主要由以下幾個層次組成(如圖6所示):硬件層、操作系統層(RTOS)、Arinc 653應用程序接口層(APEX)、應用層［9］.

圖6 IMA模塊結構Fig.6 IMA module architecture

硬件層提供各種外圍設備接口，如AFDX、Arinc 429、CAN、離散量 I/O、模擬量 I/O 等，包含處理器、硬件時鐘、MMU、內存等.操作系統層管理各個分區和分區的通信，對分區來說，操作系統管理一個分區的進程.操作系統與硬件接口層相互作用，可以實現通信、調度、內存管理、定時和健康監控.Arinc 653應用程序接口層為航空電子應用軟件提供服務，可以實現應用之間的通信，VxWorks 653中由分區操作系統完成該項功能.應用軟件層由各個分區組成，每個應用可以宿主一個或多個分區，執行應用程序，實現飛機功能.配置表可供操作系統和硬件接口系統用于配置內存訪問、調度和通信等.

配置和構建一個IMA系統是一個復雜的過程，根據IMA系統架構，通常分為3種開發角色，分別是平臺開發人員、應用開發人員和系統綜合人員，3種角色互相協同，就系統需求和設計約束等進行協商.

平臺開發人員負責IMA平臺的開發，根據模塊核心操作系統、分區操作系統和共享庫的設計需求，向其他開發人員提供核心操作系統配置文件、共享庫配置文件以及相關的鏡像文件.應用開發人員負責IMA分區應用的開發，根據應用的設計需求，為其他開發人員提供應用配置文件及應用的鏡像文件.系統綜合人員負責將平臺和應用進行綜合從而形成一個完整的IMA系統，形式上表現為對系統配置表的開發，編譯生成IMA模塊的配置記錄和最終的系統鏡像文件，加載到IMA模塊當中.

3 IMA應用開發

雖然定義了3種開發角色，每個角色都有各自的分工，但是對于IMA應用開發人員來說，其他兩種角色的工作在其開發應用的過程中也是有所涉及的.對于VxWorks 653來說，IMA模塊的構建過程分為8個部分，分別是模塊操作系統的構建、認證環境代理的構建、分區操作系統的構建、共享庫的構建、共享數據的構建、用戶配置記錄的構建、應用的構建和綜合的構建，每個構建過程都是獨立的［10］，這8個構建過程并不都是必須的，結合某預研項目的例子，只涉及到了模塊操作系統的構建、分區操作系統的構建、應用的構建和綜合的構建，而這4個構建過程對任何一個IMA系統來說都是必須的.

3.1 模塊操作系統的構建

平臺開發人員已經提供了模塊操作系統的配置文件bsp.xml，應用開發人員在這個過程只需要通過該配置表生成一個鏡像文件即可，因此只需要編寫一個 Makefile文件即可［11］，主要內容如下:

該Makefile用來創建一個核心操作系統項目并最終編譯鏈接生成核心操心系統鏡像文件coreOS.sm.

VxWorks 653支持2種模式下3種鏡像文件的加載，2種模式包括調試模式和認證模式，3種鏡像包括網絡可加載鏡像、RAM駐留系統鏡像以及ROM駐留系統鏡像，這里通過shell編譯生成的是調試模式下的網絡可加載系統鏡像.

3.2 分區操作系統的構建

分區操作系統包含在VxWorks 653中的系統共享庫里面，非系統共享庫指的是開發人員自己定義的一些可以被其他分區共享的代碼，分區操作系統可以看成是分區應用與核心操作系統之間的一層中間件，Arinc 653所規定的API服務調用就是通過分區操作系統來實現的.分區操作系統某種程度也可以理解為VxWorks 5.5，因為它對VxWorks 5.5的API函數調用也是完全支持的，只不過使用VxWorks 5.5 API函數開發出來的應用，稱之為vThreads應用，不可以移植到其他平臺上;而用Arinc 653 API函數開發出來的應用，稱之為APEX應用，可以移植到任何滿足Arinc 653標準的平臺之上.

在分區操作系統的構建過程中，應用開發人員需要提供3個文件，即兩個配置表和一個Makefile文件，兩個配置表分別是共享庫描述文檔 uavm-pos.xml和共享庫 API文檔 pos-api.xml.

3.2.1 分區操作系統配置表的開發

共享庫描述文檔定義共享庫是否為系統共享庫(即分區操作系統)，共享庫虛擬地址以及共享庫需要占用的內存大小［12］，主要內容如下:

注意分區操作系統的虛擬地址VirtualAddress屬性值要和模塊配置表bsp.xml中的保持一致.

共享庫API文檔定義了該分區操作系統可以提供哪些API函數供應用調用，應用開發人員可以自定義這些API函數，主要內容如下:

導入的 vthreads.xml和 apex.xml配置表定義了具體的API函數，其中前者包括核心操作系統本身的系統調用函數，后者涵蓋了Arinc 653中所定義的服務程序.

3.2.2 分區操作系統Makefile的開發

分區操作系統的Makefile用來編譯生成分區操作系統鏡像文件 pos.sm以及其插樁文件pos-stubs.o，后者作為應用編譯的一個輸入文件，用來明確告知應用可以調用哪些API服務，該Makefile主要內容如下:

其中，sslMain.o文件用來初始化分區操作系統，vThreadsComponent.o 文件提供 vthreads.xml的 API函數功能，ApexComponent.o文件提供apex.xml的 API函數功能，pos-ept.o 是分區操作系統進入表，pos.lds是相應的鏈接文件.

3.3 應用的構建

應用的構建是應用開發人員的最主要工作，IMA應用的開發，歸根到底是源碼的開發和調試.在應用的構建過程中，需要一個應用配置表文件、源代碼文件以及一個Makefile文件，該配置表文件稱為應用描述文檔.

3.3.1 應用描述文檔的開發

應用描述文檔中定義了應用所需要的內存以及相應端口的配置，應用通過這些端口與外界進行通信，其主要內容如下:

Arinc 653標準中定義了兩種類型的端口，隊列端口(queuing port)和采樣端口(sampling port):隊列端口以消息隊列的形式緩存多條消息，即下一條傳輸消息并不立刻覆蓋當前消息，以“先進先出”的形式進行傳輸，當消息被讀取后，該消息在隊列中被清除;采樣端口的特點是當前消息會被下一條傳輸消息所更新.

配置表中定義了端口的名稱、類型、方向和大小，采樣端口還定義了其采樣率的值.隊列源端口的Protocol屬性定義了兩種端口協議，分別為SENDER_BLOCK 和 RECEIVE_DISCARD，二者是VxWorks 653單獨定義的，Arinc 653標準中并沒有規定.當從一個源端口向多個目的端口發送消息時，如果使用SENDER_BLOCK協議，當有一個目的端口滿棧了，則源端口停止向多有端口發送消息，如果使用RECEIVE_DISCARD協議，當有一個目的端口滿棧了，則源端口停止向該目的端口發送消息，但并不影響向其他端口發送消息.

通信端口在分區初始化階段生成，兩種端口只能進行單方向通信.

3.3.2 源程序的開發

在之前Rhapsody建模的過程中，應用開發人員已經理清了程序的設計思路，可以參照活動圖，也就是軟件流程圖設計程序，編寫代碼，所定義的函數功能塊名應與活動圖中定義的Action保持一致，便于對照查閱.

IMA應用一般由多個進程組成，進程在分區處于正常模式的時候運行，Arinc 653定義了每個分區有4種工作模式，分別是冷啟動模式(COLD_START)、熱啟動模式(WARM_START)、空閑模式(IDLE)和正常模式(NORMAL)，4種模式的轉換關系如圖7所示.

圖7 分區工作模式轉換Fig.7 Partition working modes transform

冷啟動和熱啟動模式主要用于分區初始化階段，包括創建通信端口和進程，其中冷啟動模式是IMA模塊從掉電狀態上電來創建分區的過程，而熱啟動則是由于遇到分區異常而重啟的狀況，熱啟動過程中，一些數據和代碼仍然保留，不像冷啟動過程全部需要重新創建［13］.當分區啟動異常或者分區正常運行時發生錯誤需要中止分區時，分區則會進入空閑模式，該模式中分區不創建任何通信端口，不運行任何進程，但是操作系統仍然會為其保留時間窗.正常模式是指該分區可以正常運行，被操作系統調度，執行飛機功能.

生成隊列端口和采樣端口的服務分別是CREATE_QUEUING_PORT和CREATE_SAMPLING_PORT，通過隊列端口發送和接受消息的服務分別為SEND_QUEUING_MESSAGE和RECEIVE_QUEUING_MESSAGE，通過采樣端口發送和接受消息的服務分別為WRITE_SAMPING_MESSAGE和READ_SAMPING_MESSAGE，部分源碼如下:

源碼中的端口參數必須和應用描述文檔中的保持一致，當改動一方，另外一方也必須改動.

應用開發人員可以通過調用服務GET_PARTITION_STATUS獲取分區運行狀態，調用服務SET_PARTITION_MODE設置分區工作模式，此外，VxWork653還額外增加了一個服務SET_SCHEDULE_MODE用來設置分區新的調度，比如是基于主時間框架的，當前分區時間窗的，還是下一個時鐘單元.

IMA應用的執行，歸根到底是進程的運行，分區相當于進程的容器.進程包括周期性進程和非周期性進程兩種類型，周期性進程在分區中以固定的周期運行，而非周期性進程通常伴隨著相應事件的觸發.進程也有4種工作狀態，分別是休眠、等待、準備和運行，其狀態轉移條件如圖8所示.

圖8 進程狀態轉移Fig.8 Process states transform

在分區處于冷/熱啟動模式時，調用CREATE_PROCESS服務創建進程，此時進程處于休眠狀態，調用START服務來啟動一個進程，此時進程一直處于等待狀態，當分區進入正常模式后，注意此時非周期進程會立刻進入準備狀態，如果被分配到CPU資源，會立刻運行，而周期性進程仍然是等待狀態，只有在下一個分區調度周期時會進入準備狀態.在創建進程之前要先定義好進程的屬性，部分源碼如下:

processTable中的進程參數依次為進程的名稱、入口函數、堆棧、優先級、進程的周期、進程的持續時間、進程的實時性.

分區中進程的調度主要采取優先級搶占的方式，低優先級的進程可以被高優先級的進程搶占，相同優先級的進程按照“時間先后”的原則分配CPU資源，如圖9所示.

圖9 進程調度Fig.9 Process schedule

圖中P2是周期性進程，P1、P3、HM(健康監控)是非周期性進程，優先級依次升高，周期2中，P2被P3搶占，導致P2未在截止時間內完成，會觸發HM進程，在下一個周期中恢復P2進程并完成.當然，開發人員可以調用“搶占禁止”服務來鎖住當前進程，使其不被其他高優先級的進程搶占，待其完成之后，再調用解鎖服務.

周期性進程在程序最后調用PERIODIC_WAIT或TIMED_WAIT服務通知系統進程運行結束，釋放CPU資源并等待下一次調度，非周期性進程調用STOP_SELF服務來結束進程釋放CPU資源.

對于進程間的通信，操作系統提供了兩種通信端口，稱為“緩存”(buffer)和“黑板”(blackboard)，緩存和黑板的功能分別類似于分區間通信的“隊列端口”和“采樣端口”，所不同的是通過二者之間的消息可以進行雙向傳輸.與分區間通信服務類似，開發人員可以創建緩存和黑板，定義其相關屬性，譬如身份標識、消息大小等，可以發送和接受消息，還可以獲取當前端口的信息，譬如有多少進程正在等待訪問該端口等.

對于進程間的同步，操作系統通過“信號量”(semaphore)和“事件”(event)實現.在VxWorks 653中采用計數信號量，其數值是一個非負整數，當多個進程需要訪問同一資源時，開發人員可以調用服務創建信號量，定義信號量身份標識，指定信號量數值大小，進程以什么樣的方式獲取信號量(“先進先出”或“優先級搶占”).進程需要獲取信號量才可以訪問資源，此時信號量數值減一，其他進程則處于等待狀態，進程完成之后則需要釋放信號量，此時信號量數值增一.“事件”則是進程觸發的某種條件，事件有兩種狀態，一種是“上(up)”，一種是“下(down)”.當事件處于up的狀態時，所有等待該事件的進程會進入準備狀態，開發人員在創建事件時初始狀態為down.

VxWorks 653的默認主函數名為usrAppInit()，無人機控制管理應用主函數源碼如下:

portC()用來創建分區間通信端口，createP()創建應用的進程，START函數啟動第一個進程，SET_PARTITION_MODE函數設置分區進入正常模式，進程開始運行.

3.3.3 應用Makefile文件的開發

應用的Makefile文件主要內容如下:

應用的鏡像 uavm.sm依賴于 vxMain.o、uavm.o、uavm.lds、pos-stubs.o 文件，其中 vxMain.o用于應用初始化，pos-stubs.o文件是應用于分區操作系統的接口，分區地址變量PARTADDR要與bsp.xml保持一致.

3.4 綜合的構建

綜合的構建主要是生成IMA模塊系統配置記錄文件configRecord.reloc，組合核心操作系統、分區操作系統、應用的系統鏡像文件，將它們加載到IMA平臺中運行.該過程的主要工作是模塊配置表的開發、分區描述配置表的開發以及需要一個Makefile文件，應用開發人員開發的模塊配置表與最終的系統開發人員開發的配置表內容是不一樣的，應用開發人員做綜合的目的是為了驗證自己應用的功能是否正確，而系統開發人員需要驗證所有分區上應用的功能.

3.4.1 模塊配置表的開發

模塊配置表中導入了之前核心操作系統配置表、分區操作系統描述文檔、應用描述文檔的信息，定義了分區的調度周期和持續時間、分區間通信通道、健康監控、需要加載的鏡像文件等信息，部分內容如下:

Schedule元素中各個分區的duration之和就是主時間框架［14］，Connections元素為各個分區之間架起通信的“橋梁”，Payload元素中列出了需要加載的鏡像.

3.4.2 分區描述文檔的開發

每個分區都有各自的配置表，稱為分區描述文檔，以分區uavm為例，其主要內容如下:

Application元素指定了該分區所宿主的應用，SharedLibraryRegion元素指定了該分區調用的共享庫為分區操作系統，RequiredMemorySize元素定義了分區所需要的內存大小.

3.4.3 綜合Makefile文件的開發

綜合過程中的Makefile文件用來將之前生成的模塊的各個鏡像組合在一起，本身也編譯生成一個配置記錄文件，主要內容如下:

其中Makefile.rules文件編譯生成鏡像加載列表文件 boot.txt、配置記錄表 configRecord.xml以及配置記錄鏡像configRecord.reloc文件，net表示編譯生成的是一個網絡可加載鏡像，如果換成ram和rom則分別表示生成的是RAM駐留系統鏡像和ROM駐留的系統鏡像，checkSize檢查系統的鏡像的大小是否超出預限值.

4 IMA應用測試

IMA應用的測試主要是功能和接口的測試，需要提供一個仿真的硬件平臺來運行應用，同時需要一些測試樁為被測應用提供相關仿真數據，譬如來自其他應用的數據，來自外部設備的數據.這就需要建立另一分區，編寫測試應用，仿真所需要的外部激勵和響應［15］.

4.1 測試應用的開發

建立另一分區，開發測試應用uavmTest，仿真外圍設備OC、GCS、RUV、DPU發送和接收數據，通過觀察數據內容正確與否，判斷UAVM與外界通信是否正常，如圖10所示.

圖10 應用測試框圖Fig.10 Application testing framework

測試應用與被測應用共享模塊操系統和分區操作系統，其應用描述文檔中的端口與被測應用的端口一一對應.針對用例圖中的第1個用例，對于無人機控制權交接管理模塊，在測試應用中實現以下功能:依次仿真發送來自OC的演示場景編號、演示開始控制、組網指令、控制權交接指令，仿真接收UAVM發送給OC和GCS的控制權移交狀態報告，仿真接收UAVM發送給DPU的與無人機連接狀態，仿真發送來自GCS的控制權移交狀態報告.

4.2 應用的加載

應用的鏡像需要連同核心操作系統鏡像、分區操作系統鏡像以及配置記錄一起加載到IMA平臺當中，也可以使用Workbench自帶的VxSim仿真器，后者需要修改相對應的虛擬地址.將鏡像加載到目標機中，部分運行結果如圖11所示.

IMA應用開發使用交叉式開發環境，在應用開發階段，為了便于調試，通常使用打印輸出的方式來直觀的顯示程序的運行結果，在最終的程序代碼中需要將其注釋.圖 11中，“Process1～Process8”語句代表應用創建進程成功，“Waiting for”語句代表應用等待外界相應事件，“Testing……”語句代表測試分區的應用在此刻發送相應仿真信息.

圖11 程序運行結果Fig.11 Application running result

5 結論

通過Harmony系統建模方法對IMA應用進行軟件開發，得出以下結論:

1)基于模型的軟件設計方法具有更高的可視化程度，可以在更高層次進行設計與驗證，使用該方法開發IMA應用可以減少出錯概率.

2)IMA應用的開發過程中，模塊操作系統的構建、分區操作系統的構建以及綜合的構建過程中所開發的文件在任何一個IMA應用開發過程中內容都是類似的，具有一定的共性，只有在應用的構建過程中所開發的文件是特別的，不同的應用有著不同的源碼，實現不同的功能，有著不同的內存配置和端口配置.

References)

［1］周慶，劉斌，余正偉，等.綜合模塊化航電軟件仿真測試環境研究［J］.航空學報，2012，33(4):723-733.Zhou Q，Liu B，Yu ZW，et al.A framework of simulation testing environment for integrated modular avionics software［J］.Acta Aeronautica et Astronautica Sinica，2012，33(4):722-733(in Chinese).

［2］張炯，呂紫旭，胡彥彥，等.虛擬化技術在綜合化航電系統中的應用［J］.北京航空航天大學學報，2010，36(2):128-130.Zhang J，Lü Z X，Hu Y Y，et al.Perspective view of virtualization technologies for avionics system［J］.Journal of Beijing University of Aeronautics and Astronautics，2010，36(2):128-129(in Chinese).

［3］鄭軍，劉暢，任占勇.綜合模塊化航空電子軟件測試環境［J］.計算機工程與設計，2011，32(8):2737-2738.Zheng J，Liu C，Ren Z Y.Integrated modular avionics software testing environment［J］.Computer Egineering and Design，2011，32(8):2737-2738(in Chinese).

［4］蒲小勃.現代航空電子系統與綜合［M］.北京:航空工業出版社，2013:354-356.Pu X B.Modern avionics system and integration［M］.Beijing:Aviation Industry Press，2013:354-356(in Chinese).

［5］ Hoffman H P.Rational Harmony for systems engineering deskbook，Release3.1［M］.Somers，NY:IBM Software Group，2010:45-50.

［6］王安生.軟件工程化［M］.北京:清華大學出版社，2014:136-138.Wang A S.Software engineering［M］.Beijing:Tsinghua University Press，2014:136-138(in Chinese).

［7］張彥，莊錫明.基于模型的開發方法在通信管理模塊軟件中的應用［J］.航空電子技術，2013，44(2):31-32.Zhang Y，Zhuang X M.Application of model-based development in communication management module［J］.Avionics Technology，2013，44(2):31-32(in Chinese).

［8］ RTCA DO-297.Integrated modular avionics(IMA)development guidance and certification considerations［S］.Washington，D.C.:RTCA，Inc.，2005:25-28.

［9］ ARINC Specification 653P1-3.Avionics application software standard interface part1-required services［S］.Maryland:Aeronautical Radio，Inc.，2010:35-37.

［10］ Wind River System，Inc.Vxworks653 configuration and build guide［EB/OL］.Alameda，CA:Wind River Systems，Inc，2007(2011-03-10)［2014-11-28］.http:∥www.windriver.com.

［11］ Free Software Foundation.GNU make［EB/OL］.Boston，MA:Free Software Foundation，2002(2014-07-01)［2014-11-28］.http:∥savannah.gnu.org/projects/make.

［12］張欣毅.XML簡明教程［M］.北京:清華大學出版社，2009:86-88.Zhang X Y.A concise course in XML［M］.Beijing:Tsinghua University Press，2009:86-88(in Chinese).

［13］ Wind River System，Inc.Vxworks 653 programmer’s guide［EB/OL］.Alameda，CA:Wind River Systems，Inc，2007(2011-03-10)［2014-11-28］.http:∥www.windriver.com.

［14］喬乃強，徐濤，谷青范.ARINC653分區調度算法的研究與改進［J］.計算機工程，2011，37(20):249-251.Qiao N Q，Xu T，Gu Q F.ARINC653 partition schedule research and improvement［J］.Computer Egineering，2011，37(20):249-251(in Chinese).

［15］ Aliki Ott.System testing in the avioincs domain［D］.Bremen:Bremen University，2007.