面向对象的航天器遥测元数据信息交换技术

董房 杨同智 周汝志 盛开明

(上海卫星工程研究所，上海 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、发射、在轨等阶段的航天器测控数据，进行全周期的大数据分析应用。后续将进一步开展元数据信息技术在全周期数据工程中的应用研究，为试验鉴定、测试大数据分析应用提供前提保障，提升航天大系统的工程协作效率与信息共享性。