航天器遥测信息传递通用接口设计

张海威 郭江 匡冬梅 张江 任登高

(西安卫星测控中心，宇航动力学国家重点实验室，西安 710043)

在航天器的设计、研制、使用过程中，仿真、测试、载荷、测控等系统之间各自使用不同的接口定义，导致系统间需要交互的遥测信息格式和方式千差万别；同时，由于航天器设计、制造、测试使用的集成测试数据库和由用户使用的飞行任务数据库二者相互隔离，导致同样用来监控航天器状态的遥测信息数据库重复配置，带来了大量的重复工作和无谓的经费浪费，增加了任务准备时间，并引入了不必要的任务风险。

目前，NASA、ESA的航天器系统中广泛应用空间数据系统咨询委员会(CCSDS)的基于可扩展标记语言的遥测遥控信息交换(XTCE)标准。XTCE[1-5]是CCSDS于2005年发布的一种标准化语言，其目标是完整、准确地描述遥测遥控信息，实现同构或异构航天任务的遥测遥控信息在各系统、各部门乃至各个国家的航天局之间实现无缝对接、交换。中法合作空间资源监测卫星项目的地面系统探讨了XTCE技术的应用；文献[6-9]中研究了基于XTCE的遥测组帧技术，但工程应用不足。本文在上述工作的基础上，参照CCSDS的XTCE标准中航天器遥测信息交互通用接口，设计遥测信息从总体结构到各层次本身的属性、再到各元素的详细信息，并采用关口支持型解决方案。通过对国内各航天器研制方与测控中心遥测信息处理软件作适应性改进，可实现双方的遥测信息快速传递。工程实践表明，本文设计的通用接口有利于提高航天器设计制造、测控管理和应用效能。

1 遥测信息传递通用接口

考虑到国内各航天器研制方与测控中心在遥测信息处理解析过程中的通用和一致性要求，实现各航天器研制方遥测信息从设计测试到测控中心使用管理的精确有效传递，本文设计了航天器遥测信息传递通用接口，目标是：①规范国内各航天器研制方与测控中心间遥测数据的描述方法和格式，使设计、测试数据可以有效应用于航天器运行和操控，提高工作效能；②考虑到与国内各航天器研制方现有遥测信息传递的通用性，采用关口支持型解决方案实现接口设计，尽可能减少当前各航天器研制方遥测信息系统的更动；③鉴于CCSDS的XTCE标准对多种遥测信息的定义和处理的适应性过于灵活，为保证信息处理传递的规范、准确和易于理解，规避XTCE标准对同一数据格式的多种描述方式，在现有基础上实现各航天器研制方与测控中心间的接口统一规范；④统一航天器研制到使用监控之间的数据库交换，打通遥测信息流动通道，缩短任务周期。

1.1 通用接口结构

目前，国内各航天器研制方主要采用分包遥测体制进行航天器遥测设计，包括固定格式的包头信息、部分关键的插入区数据信息、可变内容的数据区及校验区信息等[7]。实际使用过程中，航天器按照分系统遥测信息采集的优先级进行组帧、组包，然后下传至测控中心。测控中心将接收到的原始遥测数据进行预处理，区分航天器名称代号等基础信息，验证校验信息的正确性，进而对遥测数据进行分系统分类处理，随后对遥测参数进行解析，计算得到相应的物理量，从而实现对航天器各分系统运行状态的分析判断。因此，本文通过分析国内各航天器研制方采用的遥测体制与协议，提取各方遥测系统的设计共性，参考XTCE标准，提出基于分层模型的遥测信息传递通用接口结构，如图1所示。

注：CRC为循环冗余校验。

图1 通用接口结构

Fig.1 Universal interface structure

1.2 通用接口模型

以遥测包结构为例，基于原始遥测数据X的包协议映射函数Y满足

(1)

式中：n为虚拟信道个数；Dij为第i个虚拟信道下的第j个包数据；mi为第i个虚拟信道的包个数；G为参数对应的处理方法集合。

进一步考虑包数据域中各个子元素的位置信息，则有

(2)

式中：E为信息提取函数;Mi为包数据域中的位置矩阵；Pi为位置向量；Ci为元素提取条件判断函数。

(3)

式中：s为航天器第i个分系统出现的条件个数；V为第i个分系统第j个出现条件判据向量；ri为多航天器中第i个分系统的出现条件。

由此可见，通过定义航天器各分系统信息提取位置向量P、条件判断向量V、出现条件关系r和处理方法集合G等，就可以方便地实现航天器从顶层至底层元素间的映射。

1.3 通用接口设计

利用上述分析结果，本文采用分层模型构建遥测信息传递通用接口，见图2。它包括航天器名称(Satellite)、遥测帧的说明(TmFrames/TmFrame)、插入域的处理定义(InsertZone)、分系统的名称定义(Subsystems/Subsystem)、航天器遥测包格式的定义和数据包的具体定义(TmPackets/TmPacket)、遥测参数的定义(TmPara)、通用和自定义处理方法库(TmFuncs)及预留非标准处理的库文件(InputTypes)。其中：航天器名称(Satellite)为根节点，用于表示具体航天器任务的相关信息；遥测帧(TmFrames)、插入域(InsertZone)、分系统(Subsystems)、通用和自定义处理方法库(TmFuncs)及预留非标准处理的库文件(InputTypes)为二级节点，用于描述整个遥测信息的结构；单一的遥测帧(TmFrame)、分系统(Subsystem)等为三级节点，用于表征分系统及单帧遥测结构；以此类推，直至达到表征单一具体遥测信息的TmParam。

图2 通用接口分层模型

按照上述分层模型将遥测信息填充到XML各节点，可定义全格式的航天器包遥测XML统一协议。每个遥测解码文件具备独有的所属航天器信息(Satellite)，利于多个航天器(Satellites,如星座、星群等)共用服务器和接口文件传递，而航天器只使用自身的XML解码文件，通过该树形结构即可实现最终端的遥测信息解析。

1.3.1 航天器信息(Satellite)

航天器信息是整个XML有效内容的根节点，作为一级结构，具有名称、航天器代号和识别码属性；元素包括文件版本(Revision)、遥测帧结构(TmFrames)、包格式(TmPktHeader)、分系统(SubSystems)、函数库(TmFuncs)等。

1)标签

，用于表示航天器任务的相关信息。

2)属性

code：航天器代号，如XX-1；name：航天器名称，如“XX航天器”；projectName：航天器工程代号。

航天器信息示例见图3。接口文件的版本包含版本信息和修改日期两方面的内容，即Version和Date，示例见图4。

图3 航天器信息

图4 版本信息

1.3.2 航天器帧结构信息

1)遥测帧结构信息(TmFrames)

该部分内容用来描述航天器遥测帧总体结构信息。由于不同航天器间遥测信息差异较大，考虑通用性要求，定义如下格式：帧长、码速率、同步字、航天器标志、帧计数、首导头、数据区、校验区等。遥测帧结构对上述信息进行项目角色定义，通过子元素描述整个遥测帧的总体结构，同时各子元素作为帧结构元又具有不同的属性描述，成为二级结构。

子元素属性定义如下。name：项目名称；bitLen：数据位长度；startBitLocation：起始位置；value：值属性，可选；role：项目角色，可选，用于标示该项目在遥测帧中代表的预定义角色，取值范围为“SynCode”、“FrameCounter”、“FirstHeaderPointer”、“InsertZone”、“PacketZone”、“CheckZone”。

通用分包遥测体制的遥测帧结构定义见图5，给出了1024 byte长度遥测的结构实现形式。

2)插入区信息(InsertZone)

插入区单独作为非包结构的遥测解析规则，是固定格式的遥测数据，用于存在帧结构复用的情况，其解码一般配合帧计数FrameCounter使用。其下属的子元素为。因此，各航天器需要将帧计数角色的帧结构元处理为遥测工程值。具体示例见图6。

图6 插入区信息

3)分系统结构信息(SubSystems)

该部分子元素为各个分系统的具体遥测解码相关信息SubSystem，子元素SubSystem具有name属性。具体示例见图7。

图7 分系统结构逻辑包含关系

4)通用处理方法集合信息(TmFuncs)

它主要描述函数库的信息，给出库中全部函数的接口描述信息。本部分具有子元素遥测处理方法TmFunc，用于定义处理方法的全部描述信息和格式。

属性：name，遥测参数处理方法名称，如“曲线拟合、温度计算”；code，遥测参数处理方法代号，如“C0001、F0501”；dreturnType，处理方法的返回值类型，具有“无符号整数、补码整数、单精度浮点数、双精度浮点数”等可选项。

子元素：InputModulu，遥测处理方法的输入系数；InputTmPara，遥测处理方法的输入遥测参数。

InputModulu和InputTmPara属性：name，名称，对应系数或参数的名称；code，遥测参数代号，输入系数无此属性；type，类型，对应输入数据的类型。

考虑到各航天器研制方与测控系统数据库配置的灵活性和通用性要求，对TmFuncs的定义和调用，采用关口支持型方案，通过构建处理方法数据库进行映射的方式予以实现。通过对常用的处理方法约定特定处理方法代号，实现通用处理方法的高度复用，降低系统接口的复杂度，同时进一步降低系统的耦合程度，提高处理效率。

1.3.3 航天器包信息

1)包头信息(HeaderItems)

遥测包头的结构，是遥测包识别的前提和依据。

属性：name，项目名称；bitLen，数据位长度；startBitLocation；role，项目角色，可选，用于标示该项目在包头中代表的预定义角色，取值范围为“包长度”、“包序列计数”、“包识别符”。

标签：遥测包TmPkt，是进行遥测包识别的依据，由包头项构成。

Condition：用于描述本包的解析条件；元素Anded和Ored：表示“与”、“或”的逻辑关系；Criterion：作为判据，判断参数Tmpara的出现条件。

2)遥测参数信息(TmPara)

它定义有关遥测参数的全部内容，主要包括解码、显示和公式处理相关全部内容。具体子元素定义见图8。实现的遥测包数据描述见图9。

图9 TmPara遥测包数据实现

1.4 通用接口实现

在明确遥测参数信息传递接口模型后，要进一步理清其与测控中心的处理对应关系和约束，才能实现信息的正确、无损转换传递。接口文件中包含的信息分布在遥测元数据，即XTCE标准对遥测元数据的规定(参数类型集合ParameterTypeSet、参数集合ParameterSet、信息容器集合ContainerSet、消息集合MessageSet、数据流集合StreamSet、算法集合Algorithmset等)中。其组织信息的方式是由小到大，先生成参数定义，由参数的组合生成容器，由容器生成消息和数据流，处理方法则贯穿于整个解析过程中；测控中心遥测信息处理的方式是由大到小，首先对遥测数据进行合理性检验(如航天器信息检查、CRC等)，随后将遥测数据帧分解为数据类集合(解帧)，数据类分解为参数集合(解包)，最后进行具体的参数处理，并对处理结果进行可信性分析(如位置确认、合理性区间分析)，处理方法同样贯穿于整个解析过程中。

2 设计验证

通过上述分析，编制航天器遥测信息接口分析与验证软件，以实现各航天器研制方遥测处理信息在测控中心的自动导入和验证功能。

(1)软件通过实现航天器研制方与测控中心间定义的遥测处理信息交换协议，实现兼容包括高级在轨系统(AOS)遥测、CCSDS包遥测等多种遥测协议的遥测信息自动导入功能。

(2)软件可按照遥测协议分层结构不同粒度提供遥测帧、副帧、遥测包、遥测参数、处理方法、显示等信息分析、校验、显示、查询和修改，用于测控中心航天器任务遥测信息处理准备与实施。

实际航天发射测控任务中，比对了遥感、“北斗”等多个系列卫星的测试数据库中遥测数据和测控中心采用接口软件生成解析遥测数据。结果表明：软件实现了数万个遥测参数的“一键导入、快速生成、自主校验”功能，具备了遥测信息导入、校验及错误识别定位告警功能(见图10)，具有较好的使用效果。

图10 通用接口软件处理结果

3 结束语

为解决我国航天器研制与应用不同阶段间遥测信息交换不统一导致大量重复工作、不适应当前我国航天快速高密度发射形势的需求问题，本文参照CCSDS的XTCE标准，结合当前我国航天器研制方与测控中心遥测信息传递实际，提出了通用规范的航天器遥测信息传递通用接口。其中：构建了航天器遥测信息分层模型，明确了航天器各分系统的分支节点，完成了航天器遥测文件元素定义；规范了航天器遥测信息交换的通用数据处理方法,实现了测控中心遥测信息传递通用接口软件。该通用接口已经过多个航天器研制与应用的实践检验，可推广使用。