面向對象的航天器遙測元數據信息交換技術

董房 楊同智 周汝志 盛開明

(上海衛星工程研究所，上海 201109)

元數據是描述數據的數據，是關于數據的組織、數據域及其關系的信息[1]，元數據廣泛應用于網絡資源、文獻資料、人文社科、博物藝術品、數字圖像、技術報告等各種場合，用于輔助用戶管理、維護與應用數據，同時元數據技術是下一代互聯網-語義網的核心技術之一[2]。遙測元數據是描述遙測數據的數據，用于指導遙測數據的解析與處理。

標準高效的遙測元數據在國外已展開應用，美國對象管理組織(Object Management Group，OMG)的空間領域任務工作組(Space Domain Task Force，STDF)、空間數據系統咨詢委員會(CCSDS)制定了一系列航天領域標準，旨在通過標準規范提升空間應用的互操作性，降低空間系統任務的風險與開銷[3]。OMG-STDF與CCSDS協調一致，2007年發布了用于描述測控數據的元數據樣式規范XTCE 1.1[4]，2019年發布了XTCE 1.2規范[5]，根據XTCE實際應用反饋，修正了標準附錄XML Schema Definition中的數據格式、報警重構、索引等近90項細節問題，標準正文的總體結構未更改。XTCE應用于詹姆斯-韋伯空間望遠鏡(JWST)、羅塞塔(Rosetta)號探測器、“冷衛星”(Cryosat)、“氣象業務衛星”(Metop)、普朗克衛星(Herschel-Planck)等的數據庫系統，如JWST是多國合作的下一代大型紅外線空間望遠鏡項目，共有24個單位參與，每個單位擁有一個數據庫，并且這些數據庫都會與JWST的主數據庫進行數據交換，按照XTCE標準對這些數據庫進行整合，統一數據交換接口，使得測控數據在不同單位間更容易交互[6]。法國國家太空研究中心(CNES)、美國Harris公司開發了BEST、OS/COMET XTCE ingest tool等面向對象的測控數據定義描述軟件工具[7]。此外，ESA的SCOS 2000 MIB、NASA的GovSat/AMMOS、開源YAMCS數據系統也均采用面向對象的遙測元數據設計模式[8-10]，服務于多個航天器。

目前，國內衛星總體設計與總體測試人員之間、衛星總體集成單位與單機研制單位之間、衛星研制單位與用戶之間大部分還是使用自己獨有的格式規范進行遙測元數據描述，當需要進行數據交換時，基本都是通過Word文檔、紙質文檔采用自然語言的方式進行描述[11]。當數據導入之后，還需要進行信息的集成、整合和校驗，非常繁瑣,而且這些工作大多依靠人工完成，既浪費工作人員的時間、精力，又容易因人為原因出錯。因此，標準高效的遙測元數據設計模式是當前必要的、急需的。

本文通過分析現有遙測元數據模式的不足，設計了面向對象的分層的遙測元數據組織模式，并應用于航天器研制的測控信息管理平臺，實現了從系統設計到集成測試的遙測信息一體化管控，減少了人工重復配置的開銷與錯誤，提升了整體研制效率。

1 現有遙測元數據模式分析

遙測數據處理通過軟件與配置文件完成，目前國內主流的做法是：遙測處理軟件通用化設計，常規處理通過遙測配置文件(遙測元數據文件)描述，特殊處理通過專用軟件模塊實現。現有的遙測元數據文件主要采用Excel和XML，典型示例如下。

(1)Excel描述方法示例見表1，一行為一個遙測參數，包含處理方式及序列信息。

表1 遙測處理配置表

注：位序中H表示高位序，L表示低位序；處理公式中的“5”代表公式y=k×x+b，公式系數表示公式中的k、b值；小數位數表示遙測物理量保留的有效小數位數，采用預警、報警兩級區間門限，利于提前發現問題。

(2)XML描述方法示例如下，一個TmPara元素為一個遙測參數(含處理信息)，多個TmPara元素組合表示一個遙測序列(如遙測包)，如圖1所示。

經分析，傳統的兩種遙測元數據表達方式在使用中存在以下不足。

(1)遙測參數類型、參數實例未分開定義：同類遙測的物理意義相近，且采用同一個模數變換(AD)采集，其遙測參數的信息重復度較高，如表1中的蓄電池單體電壓僅遙測名稱、代號、公式參數不同。在方式1的表格(見表1)及方式2的XML(見圖1)描述中，遙測參數的所有信息獨立定義與修改，存在較多重復配置，在測試中經常出現“單體3更改了，但單體9未同步更改”之類的問題，狀態不容易統一控制。建議先定義參數類型，完成遙測參數類的總體描述，再通過類的實例化繼承定義具體的遙測量，只重寫必要的信息(如公式參數)。總體信息(如字節序、單位、編碼方式、報警范圍等)需要修改時，只需更改類定義，不需更改每一個遙測量。遙測參數類定義提升了同類遙測量的批量管理能力，類定義集也可方便地移植到其他型號。

(2)遙測參數、遙測序列未分開定義，當同一遙測參數分布于多個遙測包、遙測幀區域時，若多包共用的遙測分開放置，會引起較多的重復填寫與修改；若多包共用的遙測集中放置，雖然實現了遙測參數的統一管理，減少了重復修改操作，但破壞遙測序列的可讀性，也不利于遙測元數據的裁剪、移植等應用。

(3)缺乏繼承、重寫機制，傳統的遙測元數據采用結構化描述，未采用面向對象的設計范式，缺乏遙測序列的繼承、動態重寫機制，當一段遙測參數集被多個包重用或重寫時，會引起較多的重復填寫與修改。

因此，傳統的遙測元數據模式將遙測參數類型、遙測參數實例、遙測序列定義混合在一起，其遙測信息描述的耦合性強，構架的靈活性、彈性不足，缺乏繼承、動態重寫機制，不利于測控信息的組織、裁剪與重用，不利于多用戶間遙測信息的互操作。針對傳統結構式遙測元數據模式的缺點，借鑒面向對象技術，設計具備派生、繼承、重寫等對象管理機制的遙測元數據設計模式，提高遙測元數據信息的表達能力與效率。

圖1 采用XML描述的傳統遙測元數據樣式Fig.1 Traditional telemetry metadata style in XML schema

2 面向對象的遙測元數據設計

遙測數據處理的關鍵信息是遙測元數據結構、遙測點的參數定義、遙測點的序列組合，元數據結構用于實現遙測配置文件的總體描述，參數定義用于實現遙測點的原碼與物理量的轉換處理，序列組合用于遙測幀、遙測包、遙測段到遙測點的結構解析，因此本節從遙測元數據的總體結構、遙測點的參數定義、遙測點的序列組合三方面展開描述。

2.1 總體結構

航天器系統采用分層組織結構，如圖2所示，由單機、分系統、航天器系統各個層級組成。為實現航天器研制全周期遙測元數據管理，航天遙測元數據應采用樹型分層結構[12]，方便聚合單機研制單位、分系統研制單位、航天器總承單位的遙測元數據信息。

圖2 航天器層次組織結構Fig.2 Spacecraft hierarchical structure

XML是元數據的常用構建方式[13]，XML文檔采用樹狀結構，較容易實現遙測元數據的分層組織，利于遙測元數據信息的聚合、裁剪與移植。在SpaceSystem中嵌套SpaceSystem，實現分層組織構架，如圖3所示。

圖3 基于XML的遙測元數據分層管理機制

為了克服傳統遙測元數據的不足，面向對象的遙測元數據將遙測參數類型、參數實例、遙測序列、算法獨立定義。基于類的設計理念，通過派生、實例化參數類型，定義遙測參數；通過序列容器的繼承與重寫，逐層聚合遙測參數、遙測序列，構建遙測包、遙測幀結構，從而實現遙測數據的彈性描述，提高遙測元數據信息的表達能力與效率。

遙測元數據的主要元素組成如圖4所示。遙測元數據主要要素的XML樣式描述見圖5。

圖4 遙測元數據主要元素構成

圖5 采用XML描述的遙測元數據要素Fig.5 Telemetry metadata primary element in XML schema

遙測元數據的元素組成與功能如下。

(1)參數類型集：定義遙測參數類型，包括數據類型、說明信息、報警閾值、工程單位、長度、位序、字節序、處理算法、編碼方式等，支持類型派生。

(2)參數集：通過實例化參數類型獲得，可以繼承參數類型的配置信息，也可在實例化時重寫報警閾值、算法參數等信息。

(3)算法集：遙測參數處理的基礎算法，可以是傳統的數學運算，也可通過腳本描述自定義算法。

(4)序列容器集：聚合遙測參數、其它序列容器構建遙測序列，可以描述分包遙測、復幀遙測序列，支持繼承、重寫、條件選擇等機制，實現遙測信息重用與分層構建。

(5)數據流集：用于描述遙測幀同步、幀結構、編碼信息，用于遙測組幀、解幀操作。

此外，還可定義消息集應用于信息服務中，如通過消息篩選出一類遙測序列(如與某信息相關的遙測包)，用于功能監視、問題排查等任務[14]。

2.2 面向對象的遙測參數

遙測參數、參數類型獨立定義。遙測參數類型作為一類進行定義，通過類封裝遙測參數的處理信息，支持類派生[15]，增強遙測信息統一管理能力。類屬性包括單位、位序、字節序、數據類型、報警閾值等，類方法包括遙測校準、遙測處理算法。遙測參數為類的實例化，通過ParameterTypeRef索引定義的類，繼承類的屬性與方法，在實例化時可以重寫繼承的方法。“某電池單體電壓”遙測參數類型的類“SingleBatType”定義如圖6所示。

圖6 遙測參數類型示例Fig.6 Telemetry parameter type example

遙測參數實例化示例見圖7，可以實例化“蓄電池單體電壓1”、“蓄電池單體電壓2”等多個單體電壓，通過一個類定義進行統一管理，每個實例可以重寫類成員，如“蓄電池單體電壓2”重寫了“SingleBatType”類的處理系數成員，提高遙測參量信息的利用率與靈活性。

圖7 遙測參數類型實例化Fig.7 Telemetry parameter type instantiation

常用的遙測類型ParameterType包括Float、String、Enumerated、Integer、Binary、Boolean、RelativeTime、AbsoluteTime、Array、Aggregate等參數類型，編碼方式DataEncoding包括Integer、Float、String、Binary四類。遙測量處理流程見圖8，逐步完成原碼類型轉換、有效范圍檢查、數值計算、遙測參數類型轉換、報警檢查，實現原碼到物理量的轉換與報警監視。

圖8 遙測參數的原碼與物理量轉換流程Fig.8 Conversion flow of telemetry parameters form origin code to physical value

2.3 基于序列容器的繼承設計

如圖9所示，遙測數據采用分層結構，由遙測參數段、遙測包、多路復用、虛擬信道、遙測幀逐級生成[16]。為了實現遙測信息的分層組織，需要引入繼承與動態重寫機制，實現遙測信息的高效定義與重用。

通過面向對象的序列容器設計實現遙測數據的分層構建。如下定義一個基容器，聲明一個遙測包頭序列格式，其中EntryList負責聚合2.2節中定義的遙測參數，通過parameterRef索引遙測參數，也可以通過containerRef索引其它序列容器，從而實現分層組織，如圖10所示。

圖9 遙測分層組織數據結構Fig.9 Telemetry hierarchical data structure

圖10 基容器示例Fig.10 Base container example

如下定義一段遙測參數序列“SecondaryHeader”，可以被其他序列容器引用。通過IncludeCondition條件(如比較條件Comparison parameterRef=“SecH” value=“1”)在序列實例化時重寫序列，從而支持動態序列容器(見圖11)。

圖11 遙測參數段的序列容器示例

通過BaseContainer支持容器繼承，并通過RestrictionCriteria匹配條件篩選，實現解幀、解包、解遙測參數段等操作指示(見圖12)。

圖12 容器繼承示例Fig.12 Container inheritance example

3 遙測元數據仿真應用

為了提升多用戶間遙測信息平滑交互能力，打通總體設計與綜合測試之間的遙測信息交互壁壘，減少低層次重復勞動，本文設計了一體化的測控信息管理系統，可面向于不同航天器不同分系統不同單機的遙測數據管理。通過調研國外遙測元數據及參考面向對象的設計技術，設計了上節所述的分層的面向對象的遙測元數據樣式，并應用于測控信息管理仿真系統。從設計頂層出發，將衛星綜合電子采集、下位機打包遙測信息納入單位信息化系統，在如圖13所示的測控信息管理仿真系統上，實現了衛星設計環節與測試環節的遙測信息一體化管控，減少了人工重復配置的開銷與錯誤，提升了整體研制效率。

圖13 測控信息管理系統軟件界面Fig.13 Software interface of TM&TC information management system

測控信息管理仿真系統采用模塊化的設計，系統模塊組成如圖14所示，由客戶端軟件和服務器軟件組成，客戶端軟件主要用于提供圖像化的編輯界面，供用戶進行數據、文檔操作，同時提供服務器管理界面，供系統管理員進行整個系統的配置；服務器軟件是為整個系統多個用戶提供在線的數據、文檔管理服務。

圖14 測控信息管理仿真系統模塊組成Fig.14 Module composition of TM&TC information management system

如圖15所示，通過圖形化的界面進行遙測元數據定義，一個單元格表征一個遙測參數，單元格屬性為遙測參數具體的內容定義，通過行列表格的形式進行遙測參數的序列容器定義。

國內航天器研制廠商、測控用戶、業務用戶均有成熟的、應用多年的電氣地面支持設備(Electrical Ground Support Equipment，EGSE)，全面應用面向對象的遙測元數據配置存在著技術換代風險，影響任務執行，因此可以如圖16所示，將公共的遙測元數據規范作為研制單位、用戶之間的遙測信息交換媒介，開發一套轉換軟件，完成本地遙測元數據與公共遙測元數據之間的轉換，如法國國家太空研究中心(CNES)開發了OASIS系統，完成了XTCE格式與本地XIF格式之間的轉換[17]。為了適應地面測控站的遙測元數據格式，開發了相應的格式轉換插件，將航天器研制單位的遙測元數據轉換為地面測控站的遙測數據格式，便于地面站直接應用，提升任務效率。

圖15 遙測元數據信息定義Fig.15 Definition of telemetry metadata

圖16 多用戶間遙測元數據應用示意Fig.16 Application schema of telemetry metadata among users

測控信息管理仿真系統可自動生成航天器測控軟件、地面測試系統及地面測控系統的遙測配置文件，極大減少了軟件配置更改、調試、驗證及錯誤。如表2所示，相比傳統人工管理模式，減少了90%以上的遙測大表配置、檢驗等低層次重復勞動，節約了72天·人，系統協作效率提升300%，配置錯誤率為0，有力提升了各個航天器測控、綜合測試、地面測控、在軌長管、應用用戶等相關方的系統協作效率，保障了任務。

表2 遙測元數據管理效率對比表

4 結束語

高效統一的遙測元數據信息交換技術有助于規范衛星研制單位與相關用戶間的遙測數據的交互格式，減少由于信息描述格式不同引起的軟件更改、調試、驗證及錯誤，提升不同衛星的遙測信息在多用戶間平滑交互的能力。本文借鑒國外成功經驗并結合我國航天器研制需求，設計了一種面向對象的遙測元數據樣式，具備遙測信息統一管理、繼承、派生、動態重寫等技術優點，可與當前主流的Java、C#等面向對象的設計語言實現良好互通，在航天器研制過程中，基于該元數據樣式構建了測控信息管理仿真系統，實現了衛星設計環節與測試環節的遙測信息一體化管控，提升了衛星研制的整體效率。

當前航天器各個研制階段的試驗測試數據格式不一致，遲滯阻礙了全周期大數據應用。標準、高效、性能優良的元數據信息技術可用于規范各個階段的試驗測試數據描述，有助于打通研制各階段的測試信息交互壁壘，聚合單機研制、AIT、發射、在軌等階段的航天器測控數據，進行全周期的大數據分析應用。后續將進一步開展元數據信息技術在全周期數據工程中的應用研究，為試驗鑒定、測試大數據分析應用提供前提保障，提升航天大系統的工程協作效率與信息共享性。