宋征宇

北京航天自動控制研究所，北京100854

1 概述

嵌入式操作系統(tǒng)是否適合運載火箭飛行控制的應用，一直存在不同意見。一種觀點認為，現(xiàn)有的“中斷+循環(huán)”的運行方式能夠滿足任務需求，而采用操作系統(tǒng)會增加軟件的復雜性，軟件應越簡單越好。而隨著技術發(fā)展，飛行軟件發(fā)揮的作用在增加，因為能簡化硬件設計，并增加系統(tǒng)的靈活性，因此在傳統(tǒng)控制功能外增加了諸如故障診斷與重構、總線通訊、數(shù)據(jù)管理等功能，同時數(shù)字化導致智能設備增多，多任務的特點愈發(fā)明顯，操作系統(tǒng)的研究開始受到重視。

操作系統(tǒng)在國外航天器中已經(jīng)得到了應用，如美國［1－3］火星探測、彗星撞擊以及運載火箭等均有采用，類型包括了VxWorks，ThreadX 以及早期的RTEMS 等。國內(nèi)航天系統(tǒng)也開展了操作系統(tǒng)的研究［4］，但還未形成廣泛的應用，尤其在運載火箭領域。在航空系統(tǒng)，相關研究所與美國Wind River 公司在上海聯(lián)合建立了“嵌入式實時操作系統(tǒng)應用開發(fā)實驗室”，用于推廣操作系統(tǒng)的應用［5］。本文將結合我國運載火箭的實際情況，對是否需要操作系統(tǒng)、如何使用操作系統(tǒng)等問題進行探討。

2 飛行軟件的現(xiàn)狀及操作系統(tǒng)應用優(yōu)劣分析

2.1 飛行軟件的發(fā)展

早期的飛行控制軟件，主要從事制導計算，屬“計算型”的軟件。隨著數(shù)字控制方案的普及，機電式程序配電器等設備逐漸被電子式時序控制器替代，飛控軟件增加了分離、調(diào)姿等控制功能，軟件發(fā)展為“計算+控制”型，但控制功能相對簡單，主要是固定時間間隔的指令控制，上述情況下由于功能以及速度等的要求，均未采用操作系統(tǒng)。隨著載人航天工程的發(fā)展，各種冗余設計技術廣泛采用，軟件在故障檢測與管理中發(fā)揮了重要作用，這部分代碼量開始增加?；仡欉^去展望未來，軟件的發(fā)展面臨著以下情況:

1)硬件接口種類增多，且有智能化的趨勢

接口智能化，意味著主處理器與接口電路之間不再適用單條I/O 指令的控制，存在著通訊、應答以及時序要求，響應時間也不再是確定不變的，取決于智能接口當時的狀態(tài)。

2)有優(yōu)先級要求的中斷和任務增多

各個智能設備按自身的節(jié)拍來工作及通訊，整個系統(tǒng)本質(zhì)上是異步的。為了保證對各設備控制的實時性，中斷會逐漸增多。同時，信號的重要程度有優(yōu)先級之分，原有多數(shù)任務順序執(zhí)行的基礎已不再存在。

3)軟件配置項之間的交互增多

數(shù)字化帶來軟件配置項大增，要保證軟件間信息交互的完整性、同步性和實時性，避免資源的沖突和死鎖等。

4)故障診斷的工作量增多

軟件在冗余系統(tǒng)中發(fā)揮重要的故障診斷工作，但增加了軟件的復雜性，降低了軟件固有可靠性。

上述4個方面均導致軟件復雜度和代碼量增加，并又帶來了以下2個方面的特點:

1)傳統(tǒng)飛行控制代碼量所占比例70%以下

I/O 管理、冗余管理、總線通訊等非傳統(tǒng)的飛行控制代碼量達到或突破總量的30%。

2)傳統(tǒng)飛行控制代碼的測試用例數(shù)量所占比例50%以下

以某軟件為例，采用“中斷+循環(huán)”模式，只統(tǒng)計圈復雜度超過10 和扇出數(shù)大于7 的模塊，因為這些模塊基本決定了測試用例的分布，如表1 所示。

表1 某軟件靜態(tài)分析結果及測試用例統(tǒng)計

表1 中前3 項在圈復雜度所占總數(shù)達到了38.17%，扇出數(shù)所占總數(shù)達到了83%，這意味著將有大量的測試用例花費在這些功能上;而另一方面，計算模塊路徑單一，例如，18個通用制導計算模塊以及22個姿控計算模塊中的20個，圈復雜度均低于10。從實際測試用例數(shù)量上看，與控制功能密切相關的測試用例只占53.22%。

以上分析雖是一個具體的案例，但具有代表性。進一步考慮未來應用，諸如上面級長時間在軌飛行等，故障恢復、并行處理等需求會逐漸增加，非傳統(tǒng)控制功能的代碼量和測試用例所占比例還會增多。鑒于此，本文將上述6個特征作為采用操作系統(tǒng)的基本前提條件。

2.2 操作系統(tǒng)的優(yōu)劣分析

隨著硬件產(chǎn)品性能的提高，操作系統(tǒng)的大小及對運算速度的影響等因素不再顯得那么突出，評價其優(yōu)劣的主要出發(fā)點還是對軟件可靠性的影響。從這方面其優(yōu)點有以下幾方面:

1)能夠顯著降低軟件質(zhì)量問題

根據(jù)控制系統(tǒng)2006 ～2011年的不完全統(tǒng)計，軟件典型質(zhì)量問題分布如下表所示。硬件初始化、I/O的管理、中斷管理、共享資源的管理等均是較為適合操作系統(tǒng)完成的工作，如果操作系統(tǒng)是成熟的，將會顯著降低上表中“初始化”、“中斷使用錯誤”、“接口不匹配”、“并發(fā)與競爭類錯誤”等問題的發(fā)生，這類問題占目前總質(zhì)量問題的49.1%。

表2 軟件典型質(zhì)量問題分類及分布

上述問題的主要起因，是由于不同項目組重復開發(fā)，設計經(jīng)驗與教訓沒有得到充分利用，既浪費資源，也帶來眾多質(zhì)量風險以及測試驗證工作。如果用操作系統(tǒng)來統(tǒng)籌上述功能，將能減少這些錯誤的發(fā)生，同時更多型號的應用能夠進一步提高操作系統(tǒng)的成熟度。

2)提高軟件的重用度

操作系統(tǒng)自身的功能不用重新開發(fā)(當然可能會隨著硬件的變化進行增補)，這體現(xiàn)了重用的一方面;另一方面，操作系統(tǒng)還能使應用軟件實現(xiàn)對底層硬件的不相關性，促使飛行軟件設計人員將各種算法的編程與其他功能很好地剝離出來，降低不同功能之間的耦合性，有利于重用。此外這也可以減少“平臺相關錯誤”，與前述統(tǒng)計合計，操作系統(tǒng)可以解決的問題已超過了問題總數(shù)的50%。

3)分散技術風險

傳統(tǒng)飛行軟件的功能和風險將由應用軟件和操作系統(tǒng)共同承擔;隨著操作系統(tǒng)設計的專業(yè)化、廣泛的推廣應用以及成熟度的不斷提升，這部分的風險也在降低，從而分散和降低了技術風險。

上述分析的出發(fā)點均是在操作系統(tǒng)已較為成熟的基礎上，否則其自身仍然存在表2 所體現(xiàn)的各類問題，例如，操作系統(tǒng)底層硬件驅動的初始化問題、接口不匹配問題，中斷處理考慮不周等。此外，由于我國在自主設計操作系統(tǒng)方面的技術積累仍較薄弱，其劣勢還體現(xiàn)在以下方面:

1)操作系統(tǒng)的成熟度還不高，影響了其自身的質(zhì)量和推廣;

2)操作系統(tǒng)與應用軟件的界面不夠清晰，增加了編程的復雜度;

3)操作系統(tǒng)還不能以通用化的產(chǎn)品來滿足各類應用，這增加了定制的工作量及技術風險。

3 操作系統(tǒng)的基本功能

3.1 典型應用對象介紹

在介紹操作系統(tǒng)功能前，先對其應用對象進行簡要介紹。圖1(a)是較為典型的三冗余箭載計算機的功能框圖，飛行軟件通過1553B 總線完成慣組信息的錄取與關機指令、姿態(tài)控制指令的發(fā)送。軟件的運行過程如圖1(b)所示，主功能為20ms 周期任務，錄取慣組信息、進行同步處理、開始控制運算，并將控制指令通過總線發(fā)送到執(zhí)行設備。當接近有效載荷分離時刻，為提高關機控制的精度，啟動1ms中斷，在1ms 任務中實現(xiàn)關機控制。

3.2 操作系統(tǒng)的基本功能

綜合國內(nèi)關于航天器操作系統(tǒng)的研究［6－8］，可以梳理出操作系統(tǒng)最基本的功能，分以下幾方面:

1)初始化功能，含初始化后的自檢功能

初始化工作確保各接口電路處于安全的初態(tài)，自檢結果要傳輸?shù)綔y發(fā)控系統(tǒng)的監(jiān)控終端。

2)I/O 管理，包括內(nèi)部與外部各種接口

向飛行軟件提供統(tǒng)一的、與設備無關的用戶接口，實現(xiàn)對底層硬件設備的安裝、創(chuàng)建設備驅動，以及設備使用過程中的打開、關閉、讀、寫、控制(擴展)等操作。以本項目為例，包括1553B，ICU，MSU(RS－485，RS －422)，BMU，DRU 等設備以及擴展的三機同步信息交換等。

圖1 飛行軟件運行環(huán)境及流程示例

3)故障與設備狀態(tài)管理

對箭上各類設備的狀態(tài)進行管理，向飛控軟件提供故障檢測、設備狀態(tài)維護、查詢等功能，涵蓋CPU，I/O 設備以及系統(tǒng)自定義功能3個層面。對絕大部分智能通訊接口而言，是否通訊正?？赏ㄟ^其控制字或狀態(tài)字來判別，這類故障的診斷可以不用應用軟件參與(當然，對于慣組數(shù)據(jù)的合理性判斷，仍只能由應用軟件來完成)。上述功能將在下面作重點介紹。

4)中斷管理

5)任務管理

6)其他必需的輔助功能，指一般操作系統(tǒng)均必備的基本功能，包括上述5 項功能中可能用到的支撐技術，如任務和二值信號量管理功能、計時管理、內(nèi)存管理功能等。

3.3 故障與設備狀態(tài)管理

隨著對可靠性要求的提高，冗余設計的復雜性也在增大，故障檢測、隔離與重組(FDIR)的代碼量不斷增大。這部分工作可以由操作系統(tǒng)和應用軟件共同完成，其中，利用操作系統(tǒng)完成故障檢測與隔離，由應用軟件實現(xiàn)故障后的重組，既統(tǒng)一且明確了操作系統(tǒng)與應用軟件的界面，也可以緩解飛行軟件的復雜度。故障的檢測往往采用硬件設備提供的各種狀態(tài)檢查功能，或冗余部件的相互對比，從而實現(xiàn)故障定位(隔離)，這部分功能可以集成在底層硬件驅動函數(shù)中。而故障的重組因故障類型而異，在很大程度上屬于系統(tǒng)設計范疇，這部分功能設計在應用軟件的接口處理函數(shù)中。

3.3.1 通用設備狀態(tài)管理

通用設備狀態(tài)管理模塊為飛控軟件提供統(tǒng)一的設備管理架構，如圖2 所示，其工作包括:

1)注冊設備狀態(tài)觀測字;

2)定義設備狀態(tài)觀測字的閾值;

3)定義閾值超限時的處理函數(shù)接口，操作系統(tǒng)可以提供缺省的處理函數(shù)，用戶也可以重新定義，尤其涉及系統(tǒng)層面的故障重組時;

4)定義處理函數(shù)的觸發(fā)模式，如果是輪詢觸發(fā)模式，則作為一個低優(yōu)先級的任務，周期性地輪詢該觀測字，并在滿足條件時觸發(fā)處理函數(shù);如果是立即觸發(fā)模式，且在該觀測字達到設定的閾值時立即調(diào)度處理函數(shù)。

采用上述機制，基本滿足了各種故障(異常)的處理要求。

圖2 通用設備管理原理圖

3.3.2 CPU 異常檢測與處理

CPU 異常是嚴重的錯誤，由于火箭飛行時間短、實時性強，且沒有遙控功能，一般在CPU 異常后難以采取諸如復位等故障恢復措施，只能靠硬件的冗余來達到容錯的目的，因此，飛行中CPU 的異常是要盡量防止的，其異常檢測與處理更多的是為后續(xù)避免此類問題和查找原因提供足夠的信息，其處理流程一般如下:

1)首先使系統(tǒng)進入安全模式，例如測試模式，避免異常的擴散或復位;

2)在預定義的地址中記錄異常發(fā)生時的指令寄存器、故障狀態(tài)寄存器、故障地址寄存器、復位和錯誤狀態(tài)寄存器、測試控制寄存器、系統(tǒng)軟件的執(zhí)行路徑、健康狀況等信息;

3)為不立即復位的異常進行計數(shù)，提供異常狀態(tài)字，并提供查詢函數(shù)接口;

4)通過郵箱向外發(fā)出第2)和3)項的信息;

5)如果用戶注冊異常處理函數(shù)則調(diào)用執(zhí)行，否則退出。

CPU 的異常因處理器而異，一般包括復位、取指出錯、非法指令、不使能FPU 時使用浮點指令、協(xié)處理器未使能異常、內(nèi)存地址不對齊訪問、FPU 異常、可校正的EDAC 錯誤異常、數(shù)據(jù)訪問異常等。不管用戶是否新注冊處理函數(shù)，上述步驟1)～4)均要執(zhí)行。

3.3.3 I/O 的異常檢測與處理

按照3.3.1 節(jié)的介紹完成注冊和處理函數(shù)的設計，在I/O 的操作中更新狀態(tài)觀測字，主要依據(jù)各I/O 驅動的狀態(tài)字或控制字來進行診斷;當設備狀態(tài)管理模塊判斷觀測字超閾值時，激活處理函數(shù)。處理函數(shù)可以由操作系統(tǒng)提供缺省處理方式，也可以用戶定義，這也主要通過重新設置I/O 驅動的控制字或狀態(tài)字來實現(xiàn)，由此可見，故障與設備管理與I/O 管理要配合使用。

例如，當1553B 故障時，可以在A 通道重發(fā);重發(fā)若不成功，則切換到B 通道再重發(fā)。如果重發(fā)次數(shù)達到閾值，通過處理接口函數(shù)直接設置在B 通道發(fā)送;如果B 通道再次發(fā)生故障且達到閾值，則可以通過處理函數(shù)設置錯誤標志并直接返回。但后續(xù)也可以根據(jù)需要重新激活相關設備。

3.3.4 系統(tǒng)級的異常檢測與管理

在所有故障中，CPU 的故障是處理器事先定義的，其故障處理以中斷形式觸發(fā);I/O 的故障可通過接口電路的各種寄存器或狀態(tài)字來查詢，其故障處理通過I/O 管理來實現(xiàn)。上述2 類異常處理操作系統(tǒng)可以不需要應用軟件參與獨自完成。但還有一些異常無法直觀地通過硬件自身來診斷，屬于系統(tǒng)冗余管理的范疇，也可以結合操作系統(tǒng)來實現(xiàn)，本文以時鐘故障檢測與處理來舉例說明。

時鐘故障導致計時基準產(chǎn)生很大偏差，導航計算以及時序控制均會出錯。僅靠本機的計時器是無法判別故障的，但可以利用各種總線通訊信息中所帶的時標信號進行對比，例如，當前后2 次總線通訊自帶時標的時間差與此段間隔內(nèi)計時器的計數(shù)值不一致時，說明存在故障;用1553B，485，422 等多種總線消息中的時標進行多數(shù)表決可定位故障，并更新觀測字。而定位出時鐘故障后具體如何處理，可以由系統(tǒng)設計人員編寫特定的處理函數(shù)并在設備狀態(tài)管理中注冊。

4 操作系統(tǒng)的應用

與“中斷+循環(huán)”不同，對操作系統(tǒng)使用方式不同，產(chǎn)生的應用效果也不同［9－12］。本文首先針對3.1節(jié)介紹的應用對象，提出了飛行控制軟件的基本架構，盡管只用到了操作系統(tǒng)最基本的功能，如任務調(diào)度，但在解決不同優(yōu)先級任務的資源沖突方面已體現(xiàn)出了優(yōu)勢，本文以示例進行說明。

4.1 飛行控制軟件的基本框架

操作系統(tǒng)在飛行控制軟件中的主要應用，是將傳統(tǒng)的中斷服務程序轉化為多任務管理［13－15］。本文也給出了一種利用操作系統(tǒng)劃分多任務的飛行軟件功能框圖，如下圖表示。

圖3 基于嵌入式操作系統(tǒng)的飛行軟件功能示意圖

圖中深色方框內(nèi)的任務屬于應用軟件的范疇，淺色方框表示的是外部中斷，其他功能均屬于操作系統(tǒng)的范疇。其中任務的優(yōu)先級可以有不同的設置，任務本身還可以根據(jù)需要進一步細分。

通過中斷激發(fā)一個“任務”，該任務可以看作是傳統(tǒng)的中斷服務程序。將傳統(tǒng)中斷服務程序中的功能劃分為多個優(yōu)先級的任務，例如“控制任務”優(yōu)于“遙測任務”，可以解決20ms 周期計算余量不足的問題。即若在某一個周期20ms 遙測任務超時，下一中斷產(chǎn)生后20ms 控制任務會搶占運行，關鍵任務不會受到任何影響。20ms控制任務運行結束，任務切換回20ms 遙測任務繼續(xù)執(zhí)行。

“任務”由“中斷”激發(fā)，這些都在操作系統(tǒng)內(nèi)核的調(diào)度下完成。軟件對硬件接口的控制，均通過操作系統(tǒng)調(diào)用驅動實現(xiàn)。操作系統(tǒng)在進行具體I/O 操作時，會同步完成對個接口功能的檢測，如故障則將更新該設備的錯誤計數(shù)器。當達到閾值且該故障模式被設置為“立即觸發(fā)”時，立即激發(fā)用戶在初始化時注冊的故障處理程序，這也將被作為一個“任務”來調(diào)度;用戶也可以將該故障模式設置為“輪詢”，則由操作系統(tǒng)的一個低優(yōu)先級任務輪詢到超過閾值時觸發(fā)，或者由應用軟件通過查詢故障計數(shù)器并自行決定如何處理。

操作系統(tǒng)的使用是較為復雜的設計，不同的設計方案使得操作系統(tǒng)和應用軟件發(fā)揮的功能不盡相同，限于篇幅，本文以共享資源的管理介紹如何發(fā)揮操作系統(tǒng)的作用，其他內(nèi)容不一一涉及。

4.2 共享資源管理的示例

4.2.1 因共享資源而帶來的不同步

在存在多個中斷的系統(tǒng)中，每個中斷可能對同一硬件進行操作，存在共享資源的管理問題。當?shù)蛢?yōu)先級的中斷占用資源時，即使高優(yōu)先級的中斷被觸發(fā)，也無法強制接管該資源，并會影響到多機冗余系統(tǒng)的同步性。以圖4 為例，1ms 中斷優(yōu)先級高于20ms 中斷。在20ms 中斷中需要通過1553B 總線采樣慣組數(shù)據(jù)，并進行三機的同步處理;而在1ms 中斷中，當需要關機時，通過1553B 總線將關機信號發(fā)送到綜合控制器實時關機控制。在這過程中，2個中斷程序均會對1553B 總線進行控制。

圖4 共享資源管理示意圖

三機按各自時鐘工作，僅20ms 中斷是三機同步產(chǎn)生，但此時每個CPU 當前正在執(zhí)行的指令(PC值)存在若干個指令周期誤差，加上三機的1ms 中斷源未進行同步處理，因此1ms 中斷發(fā)生的時間點相對于當前指令之間會存在微秒級的偏差。

在圖4(a)中，假設CPU3、CPU2 運行速度較快，完成了20ms 任務中的1553B 總線錄取工作，此時1ms 中斷到來，進入1ms 中斷處理，并通過1553B 總線發(fā)送關機指令;1ms 任務結束后，返回20ms 中斷繼續(xù)處理，并發(fā)出同步控制指令。而對CPU1 而言，當1ms 到來時，20ms 任務中的1553B 操作還未結束，盡管1ms 優(yōu)先級高，但總線資源被20ms 任務占用，于是切換至20ms 任務，待1553B 總線資源釋放后，再重新切換回1ms 任務，完成總線控制;待1ms任務結束后，再返回20ms 任務，并執(zhí)行后續(xù)的同步控制。從圖中可以看出，由于CPU1 多增加了兩次任務的切換，導致CPU1 發(fā)出同步控制時已嚴重滯后于CPU2 和CPU3，在某些場合，這種不同步是不允許的。

4.2.2 多任務管理

前文沒有區(qū)分中斷與任務的概念，中斷只負責計時并喚醒任務，而任務實際上是傳統(tǒng)的中斷服務程序，將中斷與中斷服務程序(即任務)區(qū)分開是避免中斷長期占用資源，增強響應的實時性。因此，將圖3 中“任務”繼續(xù)細分，例如將20ms 控制任務分解為總線錄取與同步任務TSK_20_BUS_SYN 以及導航、制導與控制任務TSK_20_CTL。1ms 中斷ISR_1喚醒1ms 任務TSK_1_BUS，20ms 中斷ISR_20喚醒TSK_20_BUS_SYN 和TSK_20_CTL，優(yōu)先級從高到低依次為:

ISR_1;

ISR_20;

TSK_20_BUS_SYN;

TSK_1_BUS;

TSK_20_CTL。

以圖4(b)為例，盡管1ms 中斷在TSK_20_BUS_SYN 的不同時刻到來，但因為1ms 中斷喚醒的任務TSK_1_BUS 優(yōu)先級低于TSK_20_BUS_SYN，該任務不會被打斷，進入同步區(qū)間時基本沒有偏差;在完成TSK_20_BUS_SYN 任務后，切換至TSK_1_BUS任務，此時總線資源已經(jīng)被釋放，不存在沖突;TSK_1_BUS 任務完成后，進入TSK_20_CTL 任務。圖3(a)中CPU1 多增加的2 次任務切換得以避免，三機基本上仍能保持同步。

上述任務分級的另一個好處是，總線被占用的時間最長為TSK_20_BUS_SYN 任務的時間，遠低于傳統(tǒng)編程中20ms 中斷服務程序的時間，這提高了關機的時間精度。

5 結束語

回答是否需要操作系統(tǒng)，應用發(fā)展的眼光來看，例如，如果軟件還停留在簡單計算型的應用，確實不需要操作系統(tǒng);從簡單計算型發(fā)展到“計算+控制”型，軟件的功能增加了，采用中斷也能處理。而未來的應用，已顯現(xiàn)出計算密集型、控制多樣性和信息集成化的特點，此時就必須有專業(yè)的操作系統(tǒng)支持。計算密集型會帶來并行計算的要求，控制多樣性使得多任務的需求愈發(fā)迫切，而信息集成化則賦予了控制系統(tǒng)更多的職責，可能用“信息系統(tǒng)”來描述原有概念上的“控制系統(tǒng)”更為適合。在這種背景下，應適時地開展操作系統(tǒng)的應用研究，基礎性的工作要提前打牢。

本文提出了可以考慮采用操作系統(tǒng)的6個條件，以某飛行控制為對象，對操作系統(tǒng)在故障與設備狀態(tài)管理、共享資源管理中的作用進行了較為深入的分析?？梢钥闯?，即使采用同樣的操作系統(tǒng)，不同的使用方式也會產(chǎn)生不同的使用效果，那些較為合理的設計，能夠簡化應用軟件的復雜性，使得應用軟件更能專注于飛控的核心功能。而隨著操作系統(tǒng)成熟度的不斷提高，整個軟件系統(tǒng)的可靠性也隨著增加，操作系統(tǒng)的作用將能得到真正的體現(xiàn)。

［1］EDN China. 風河為NASA 運載火箭提供操作系統(tǒng)［EB/OL］. http://www. ednchina. com/ART_76375_29_20026_NT_363ff7f9.HTM，2009，12，23.

［2］EDN China. 美國撞擊彗星計劃揭密ThreadX 實時操作系統(tǒng)擔當重任［EB/OL］. http://www.ednchina.com/ART_8985_29_20023_NT_b8f86eea.HTM，2005，8，9.

［3］EDN Chian. NASA 好奇號火星車安度”恐怖7 分鐘”，Wind River VxWorks 再建奇功［EB/OL］.http://www.ednchina.com /ART_8800507449_29_20026_NT_91cc6927.HTM，2012，8，7.

［4］程勝，蔡銘.航天高可靠嵌入式實時操作系統(tǒng)原理與技術［M］.中國宇航出版社，2012，8.

［5］EDN China (EDN China 電子技術設計網(wǎng)站).風河與中國航空無線電電子研究所成立聯(lián)合實驗室［EB/OL］. http://www. ednchina.com/ART_53867_20_0_NT_facc8737.HTM，2008，12，30.

［6］喬磊，彭飛，趙瑋，孫越，楊樺，劉波.航天器嵌入式操作系統(tǒng)研究與設計［J］.空間控制技術與應用，2011，37(5):31-35，41.(QIAO Lei，PENG Fei，ZHAO Wei，SUN Yue，YANG Hua，LIU Bo. Aerospace Control and Application，Embeded Operating System Research and Design for Sapcecraft［J］. Aerospace Control and Application，2011，37(5):31-35，41.)

［7］楊牧，王昊，張鈺，鄭偉，鄭陽明，金仲和.抗輻射加固的皮衛(wèi)星用實時操作系統(tǒng)設計［J］. 浙江大學學報(工 學 版)，2011，45(6)，1021-1026. (YANG Nu，WANG Hao，ZHANG Yu，et al. Design of Radiationhardened Real-time Operating System for Picosatellites［J］.Journal of ZHEJIANG University(Engineering Science)，2011，45(6)，1021-1026.)

［8］李林，王向暉，陶利民，張猛.航天器用實時操作系統(tǒng)設計［J］. 計算機測量與控制，2012，20(4):1026-1028，1032. (LI Lin，WANG Xianghui，TAO Li，ZHANG Meng. Type of Reali-Time Systems Designing Which Applied in Aeroships［J］.Computer Measurement＆ Control，2012，20(4):1026-1028，1032.)

［9］劉錫祥，徐曉蘇，馮丹瓊，劉建娟. VxWorks 環(huán)境下捷聯(lián)慣導系統(tǒng)的軟件設計［J］，中國慣性技術學報，2006，14(2)，1-4.(Design of Software Structure of SINS on VxWorks［J］.Journal of Chinese Inertial Technology，2006，14(2)，1-4.)

［10］李化云.嵌入式實時操作系統(tǒng)在航天器軟件中的應用研究［J］.微計算機信息，2012，(8)，73-74.

［11］冉漢政.嵌入式實時操作系統(tǒng)μC/OS 在控制工程中的應用［J］.現(xiàn)代電子技術，2003，(13):84-86. (Application of μC/OS in Controling System［J］.Modern Electronics Technique，2003，(13):84-86.)

［12］胡劍華.基于ARM-LINUX 實時嵌入式飛行控制系統(tǒng)設計與實現(xiàn)［D］.南京航空航天大學，2010.

［13］雷杰，文順安.嵌入式實時多任務操作系統(tǒng)在強實時系統(tǒng)中的應用［J］. 戰(zhàn)術導彈控制技術，2002，(4)，37-40.

［14］劉宗玉，王瑋，陳明，田洪波，綜合導航系統(tǒng)中的實時多任務軟件設計［J］. 計算機工程與應用，2004，40(27)，185-187. (LIU Zongyu，WANG Wei，CHEN Ming，TIAN Hongbo. Design of Real-time Multitask Software of Integrated Navigation System［J］. Computer Engineering and Applications，2004，40(27)，185-187.)

［15］曹寧.組合導航系統(tǒng)中實時多任務的軟件設計［J］.導航，2007，(2)，35-40.