航天地面軟件系統是支撐航天器全生命周期所有地面軟件系統的集合，是一個復雜大系統。隨著航天器種類和數量越來越多，航天地面軟件系統的規模和復雜性也在大幅度增加。航天器生命期中有2個重要的階段，即地面研制階段和運行控制階段。傳統的方法是為每一個航天器研制一套地面測試系統，一套地面運行控制中心，這種方法在早期航天器數量很少的情況是很正常的。但是，隨著每年發射的航天器數量大幅度增加，且需要管理的在軌航天器數量越來越多時，這種情況就無法滿足任務的需求。

1基于開放平臺的航天地面軟件系統發展

航天地面軟件系統第一次大的變革是20世紀90年代，隨著計算機體系結構從基于主機的系統，向基于網絡的系統發展，1993年美國航空航天局開始采用開放標準，如Unix操作系統平臺、TCP/IP協議和以太網絡作為控制中心的基礎平臺，研制國際空間站地面控制中心軟件系統。國際空間站地面控制中心和航天飛機地面控制中心相鄰，但物理上不連接，2個中心的前端處理部分相同，其他部分不同，控制員可以很容易地在2個任務之間進行切換，整個系統的設備量比原來控制中心減少了一半，節省了大量經費。

歐空局在航天地面軟件系統采用開放平臺的時間基本上和上面相似，比較典型的系統是歐空局一直使用的航天器控制操作系統（SpacecraftControlOperationSystem,SCOS）軟件，這套軟件就是建立在開放系統上的。該軟件從20世紀90年代初的SCOSI、II,發展到SCOS2000,計劃2016年推出SCOS3000.這套軟件在歐空局航天系統項目中應用的非常廣泛，該軟件最大的應用是歐洲伽利略導航衛星項目，可以支持多達50顆衛星，運行平臺是SuSELinuxEnterprise9和SUNSolaris10.國內航天地面軟件系統采用開放系統平臺是從航天器地面測試系統開始的?！暗孛鏈y試系統”,歐空局稱為地面電氣支持設備（ElectricGroundSupportEquipment,EGSE），早先國內通過從法國引進的一套地面測試系統建立起比較系統的航天器地面測試體系，用于“東方紅三號”衛星的測試。該系統硬件采用MicroVAXII,操作系統是MicroVMS,采用字符終端，測試設備采用串口連接。

1996年3月，裝備學院承擔了國內第一套基于開放平臺的衛星綜合測試軟件系統---“XX型號衛星”地面測試總控軟件系統的設計和開發工作。該系統采用Solaris操作系統、TCP/IP和以太網絡作為測試系統平臺，1996年7月該系統參加了“XX型號衛星”地面測試工作。

通過改進該系統參加了從1996年10月開始的“神舟一號”飛船地面測試的全過程，以及后續神舟飛船系列型號地面測試。改進后的系統采用的是HP-UX操作系統，除了系統的規模更大一些，還增加了一些飛船特有的功能，如工程遙測處理等，其他內容基本相同。隨后該成果又推廣到“海洋星”等一系列衛星型號項目的研制中。

航天器控制中心任務控制軟件和航天器地面測試系統所采用的軟件系統，在功能上有一定的相似性，因此，歐空局從TEAM和YES衛星項目開始，嘗試研制低成本的、可移植的、通用的MCS/EGSE系統。系統采用了1997年2月推出的SCOS-II,系統在實施過程中取得了很多有益的經驗。隨后在Herschel/Planck衛星項目中，又進行了進一步的嘗試，該項目采用了SCOS2000作為系統核心。從實驗的結果看，確實可以縮短項目研制周期，降低費用。國內在一些衛星項目上也進行過相似的嘗試，即將地面測試軟件系統作為地面站軟件使用。

由于歐洲航天器研制、運行控制往往都是多國、多機構同時參與，而不同國家、機構在航天器生命周期的不同階段使用的軟件系統都不相同，給合作帶來了很大的問題，研制統一的歐洲航天地面操作軟件（EuropeanGroundOperationSoft-ware,EGOS）勢在必行。因此，歐空局提出了建立統一的航天地面軟件系統建設的計劃。

EGOS包括航天任務控制系統（MissionControlSys-tem,MCS）、任務規劃系統（MissionPlanningSystem,MPS）、飛行動力學系統（FlightDynamicSystem,FDS）、航天器電氣地面支持設備軟件系統，地面站軟件系統、各種航天仿真軟件系統、航天地面數據庫系統等。前3項是航天地面控制中心的核心組成部分。這一計劃的主要內容包括：

①子系統和層次之間的接口定義；②地面操作軟件的參考模型；③核心體系結構；④部件間的接口標準；⑤采用統一的平臺和操作系統、語言和標準；⑥采用統一的開發模型和工具；⑦統一的配置管理。

2002年成立了委員會，進行系統間接口定義，主要定義了MCS、MPS、FDS3個子系統之間的接口關系。隨著研究工作的深入，發現統一的航天地面軟件系統設想太大，很難辦到。而且，隨著各種新技術的不斷出現，如面向服務的體系結構、云計算、虛擬化等，如何將這些技術應用到航天地面軟件中，還有很多需要探討的問題。

因此，從2009年開始，歐空局將這方面的工作重點轉到歐洲地面系統公共核心（EuropeanGroundSystems-CommonCore,EGS-CC）和航天數據系統基礎設施上。

2航天地面軟件系統公共平臺

歐洲地面系統公共核心（EGS-CC）項目[1]的目標是開發一種通用的歐洲航天任務監視控制基礎設施，能夠無縫覆蓋從航天器組裝、集成和測試到任務控制的所有階段，通過共享開發、維護和保障來減低全系統費用，降低航天項目的風險，實現EGSE和MCS系統的現代化，在整個組織之內共享先進的軟件技術。

EGS-CC的主要功能是支持所有航天任務類型和階段，采用開放的、基于組件的和面向服務的體系結構，具有通用性、可擴充性、高性能和可擴展性，采用層次實現方式，系統監視控制內核的通用功能和專用功能的分離，支持二進制兼容、標準接口，盡量隱藏技術細節，適應航天器的長期管理。

EGS-CC的體系結構如圖1所示。
其中，斜紋底方框部分代表測試程序參考實現，灰色方框部分代表核心功能，網狀底紋方框為核心擴展功能和接口的參考實現。

核心的基本功能包括兩方面：應用支撐層及監視與控制組件。應用支撐層包括運行時支持框架、系統管理和執行、訪問控制、時間同步和數據歸檔等。監視與控制組件包括監視和控制模型、控制活動有效性驗證、調度執行和確認、命令（TC功能）、過程執行、報告參數處理情況、時間處理、支持在線、回放、檢索和重放等處理模式。

核心擴展功能和接口的參考實現包括4個方面：適配層、用戶應用、離線工具和外部接口。適配層包括：遙測遙控數據處理、監視和控制適配器，如遙測遙控接收和發送，專用控制操作設備接口等，建立監視和控制服務模型、空間和地面時間校對。用戶應用包括：用戶桌面系統、用戶自定義的顯示、監視和控制應用、系統管理顯示、監視控制模型瀏覽。離線工具包括：初始化準備工具、事后處理和報告工具。外部接口包括：剪裁、配置、歸檔數據導入導出、監視和控制服務等。

目前項目已經完成了階段A的所有工作，產生了一系列規范和文檔，包括領域分析、用戶用例、用戶需求、名詞收集、系統概念、概念體系結構、外部接口確定、主要技術評估。階段B剛剛開始，正在進行軟件需求工程和體系結構設計，概念演示驗證。階段C/D采用基于增量和迭代方式進行開發，在目標環境中不斷地集成和驗證相關技術和產品，最初的應用預計在2015-2016年。理想的目標是將歐空局地面軟件的所有內容都放在一起，包括航天器、運載器、地面站、任務控制系統、飛行動力學系統、任務規劃系統、調度執行系統、數據分發系統、仿真系統等，形成一個類似蘋果公司的航天應用商店，可為不同的任務選取合適的應用。

3航天任務數據系統

航天任務數據系統基礎設施[2]是從傳統的任務數據系統發展來的，最初主要支持遙測遙控數據的歸檔和分發等基本功能。隨著航天任務的擴展，數據系統的支持功能不斷增長，如歐空局的伽利略項目，不僅具有導航功能，同時，還具備空間態勢感知（SpaceSituationAwareness,SSA）功能，包括空間目標監視和跟蹤（SpaceSurveillanceTracking,SST）、空間氣象環境（SpaceWeatherEnvironment,SWE）、近地目標監視（NearEarthObject,NEO）3大功能。為此，歐空局專門采用面向服務的體系結構設計了一個數據中心。

3.1面向服務體系結構的航天數據系統

如果采用傳統的方法來設計航天地面應用系統，每個地面系統都是獨立的，但是，結構又很相似，而且，有很多相同的功能。圖2表示采用傳統的方法設計的空間氣象環境（SWE）和近地目標監視（NEO）應用系統。而采用面向服務的體系結構設計方式，可以將這些相似的功能，如安全、用戶管理、數據歸檔、數據發布等，可以用服務的方式提供出來，圖3所示。
采用新技術，包括可視化、云計算等技術[3-6],以及開源軟件開發，可以提升歐洲工業在全球市場的競爭力，降低經費、風險和開發時間。這些新技術如何在航天地面系統中應用，往往選取數據系統作為實驗的突破口，因為數據系統的功能比較適合面向服務的體系結構。任務控制系統由于有比較嚴格的實時性和安全性方面的要求，需要進行更深入的研究。

3.2航天數據系統數據模型

隨著空間軍事應用的進一步發展，對航天數據系統基礎設施的要求又進一步深入，以美軍聯合作戰任務系統（JointMissionSystem,JMS）項目為例，該項目以面向聯合作戰形成集成的、網絡中心化的空間態勢感知和指揮控制能力為目的，能夠快速檢測、跟蹤和識別相關目標，提供及時的聯合作戰空間效果時間顯示，支持傳統的和非傳統的目標識別和發現，支持用戶自定義的作戰圖像和空間作戰命令，提供空間威脅分析等。

空間數據系統只是聯合作戰數據系統中的一個方面，但這個系統又是各軍兵種都感興趣的，因此，空間數據系統的建立必須統籌考慮作戰部隊的需求，需要在指揮控制態勢感知公共框架（C2SSACOI）下進行研究，在國防部元數據注冊名字空間結構框架（DODMDRNAMESPACE）下，建立相應的產品。

JMSEnterpriseDataModelv1.0企業數據模型就是這種產品。

JMSDataModelv1.0是從已經批準的美國空軍JMS需求模型中導出的，JMS需求模型是基于國防SSA任務主線，經過5年的努力從概念模型開始建立的。

JMS需求模型中的所有能力都能映射到JMSCDD項目需求中，JMS需求概念模型用于建立數據條目、屬性和關系的邏輯UML模型。邏輯UML模型用于產生JMS數據模型的物理模型（XML方案）。

實現公共數據模型的好處是能夠使數據元素規范化，減少了冗余，提供了一致性的元數據結構來支持可靠的決策支持；消除了數據結構的不一致性，消除了數據轉換，支持分布式數據存儲和更有效的虛擬機分配；基于公共數據的Web服務能夠利用程序結構的高效性，獲得更好的系統性能；一種公共的企業數據框架能夠支持數據的精確性和系統能力的擴展。

實現公共數據模型的關鍵是必須鼓勵采用開放和合作的方法，必須定期召開面對面的會議進行溝通，需要建立一支高水平的隊伍，成員包括國防部、政府部門、民間和商業領域、國土安全部門、地方政府、大學、聯邦成員。從任務需求開始，提供一個全面的解決方案，將主要精力放在證明模型的可實現性上，支持實際地面應用，提供最基本的產品集，提供能夠管理大量信息的工具。

4航天器自動管理和地面測控站網絡

隨著在軌航天器的日益增多，航天器地面管理的工作也越來越復雜，地面控制站網絡的優化管理面臨著很多挑戰[7].歐洲航天局跟蹤地面站核心網絡（EuropeanSpaceTrackingStationNet-work,ESTRACK）[8],是分布在全球的地面站網絡，如圖4所示。
早期的EMS（ESTRACKManagementSys-tem），每個地面站基本上都是為歐洲航天局的一個固定任務服務，地面站獨立運行，采用人工進行地面站規劃（有少量工具支持）。目前的情況是整個地面站網絡系統已經有相當規模，功能比較強，也很復雜。這些地面站同時支持多個任務，同時，還能支持歐空局以外的任務。整個網絡有一個統一的調度表。未來的發展是提高不同任務交叉支持的程度，充分利用網絡以及地面站的能力，提高系統的可擴充性。

EMS是歐空局地面站網絡自動化規劃和協調中央控制系統，由3部分組成：規劃子系統、調度子系統、協調子系統，規劃和調度子系統已經投入運行4年，在線協調系統正在開發。

ESTRACK規劃和調度系統在2005年就能夠支持10個用戶，規劃系統能在3h之內完成2周的全部規劃工作。全部規劃要求所有的任務要求都能夠滿足，所有的限制條件都經過了檢驗。

到了2008年，系統能夠支持20個用戶，規劃工具能夠支持10顆衛星在3周限制滑動窗口下，在6h內完成6個月的規劃工作，在36h之內完成一年的規劃工作。

2011年的情況是在6h之內完成15顆星6個月的規劃任務。

ESTRACK協調子系統（ESTRACKCoordi-nationSystem,ECS）是一個在線控制模塊，由一個操作員來監視所有的地面站和網絡健康情況，監視調度的執行情況。將所有監控信息歸檔在中央存儲系統中，將地面站監視參數發送給任務控制系統。

ESTRACK功能組成如圖5所示。
ESTRACK軟件的實現采用重用策略，主要利用歐洲地面操作軟件EGOS中已有的部件，如自動化任務系統、數據歸檔工具、文件歸檔工具、監視引擎，采用面向服務的體系結構與任務控制系統接口。

EMS已經作為歐空局地面站網絡的規劃和調度系統成功地運行，地面站自動分配目標已經實現，但是，還需要協調來確保各個任務能夠重新更新計劃。協調系統將進一步增強當前系統的能力，期望未來能夠有更好的互操作性和更高的自動化水平。

5結束語

航天地面軟件系統在航天任務中的作用越來越重要，同時航天地面軟件系統的復雜性也越來越高，除了大量采用面向服務的體系結構、云計算技術以外，國外已經開始采用體系結構DoDAF方法來設計航天地面軟件系統。國內航天地面軟件系統發展情況和歐洲前幾年的情況很相似，也是多個部門分別開發各種功能相似、互不通用的軟件系統，自動化程度還比較低，對航天地面軟件系統的研究不夠深入全面，缺乏統一的規劃和管理。歐空局的做法可以為我們提供管理和技術方面的借鑒，特別是目前國內正在采用國產軟硬件系統來設計和實現新的航天地面軟件系統，歐空局采用的統一的信息基礎設施、面向服務的數據系統、航天數據模型、地面站自動控制等技術，可以為我們設計新一代航天地面軟件系統提供參考。

參考文獻（References）

[1]PECCHIOLIM,CARRANZAJM.ThemainconceptsoftheEuropeangroundsystems-commoncore（EGS-CC）[EB/OL].[2014-09-12]

[2]MERRIM.Futureevolutionofmissiondatasystems[EB/OL].[2014-09-12]

[3]MURATOREJ.Spacegroundsystems:let'shavemorefun![EB/OL].[2014-09-12]

[4]PARSONSP,WALSHT.SOA4GDS:evaluatingthesuita-bilityofemergingservice-basedtechnologiesingrounddatasystems[EB/OL].[2014-09-12].