卫星采集的数据按位或者字节的形式存储，这些存储格式由地面预定义，下传数据的解析遵照预定义的格式进行。然而，卫星制造过程中，特别是卫星上载荷的研制过程中，这些格式时常发生变化，给数据解析带来很大麻烦。软硬件信息沟通不及时会影响工程进展。另一方面即使格式固定，软件端解析这些量也费时费力。比较预定义格式发现，它们的定义规则比较一致，设计一种软硬件接口和数据解析方式，降低软硬件沟通成本，同时能够自适应地进行数据解析。

数据解析一般按数据包进行，卫星下传数据包有很多种，按采集来源可以分为卫星平台采集的数据包、载荷采集的工程数据包和载荷采集的科学数据包^[1]。平台采集的数据包格式比较简单而且固定，比如定位数据包、姿态包及整星温度包等。载荷采集的工程数据包按时间采集，数据种类比较多，但总的数据量小，比如反映驱动时钟状态的包、工作模式包等，一个包大约几十到几百字节，有时硬件会在不同电子学或者仪器间轮换采集工程量，此时采集的工程量无论是格式还是长度可能都不一样，它们可以看为单独的包，这样工程数据可能存在一些嵌套包。科学数据量大，考虑到星上存储资源珍贵，有些物理量分为两部分存储，有些情况下，一个物理事例的表征需要采集多个过阈值通道，每次过阈值的通道数目不同，使得这种包长度不固定，比较重要的科学数据包有物理事例包、噪声基线包、时间进位包及全球定位系统脉冲包等，一个包占几个到几十个字节。这些原始数据包在星上进行编码、加扰和调制，通过数传或者遥测通道下传至地面，地面再通过解调、解扰、解密、去格式、分包等，将同一类型的包按文件存储，这些不同的文件都有表征其唯一性的字段，比如硬X射线调制望远镜卫星(Hard X-ray Modulation Telescope, HXMT)^[2]的文件名称采用应用过程标识符(Application Identifier, APID)表征。本文的分析对象是这些去格式分包后的数据文件。

已经发射的硬X射线调制望远镜卫星和天宫二号上的伽玛暴偏振探测仪(Gamma-ray Burst Polarimeter)^[3]，星上数据以高位在前、低位在后的形式存储，即对于一个字节，先传输高位，后传输低位。无论是星上还是地面，数据流顺序都是按先传输、先存储、先读取的方式进行。在处理多字节数据时，地面人员需要注意字节顺序与计算机内存实际顺序的对应关系，某些计算机字节顺序相反，比如本应该是字节A在字节B之前，但是内存中字节B在A之前，需要在解析时完成一次翻转。

本文主要介绍卫星下传数据的解析方法和软硬件接口方式，并将其纳入一个系统，希望方便各个卫星的调用，以节约软硬件交流成本，加速工程进度。

1 系统概述

系统主要以数据库为中心，有两大模块。图 1为系统框架，数据库的任务是存储解析格式，解析格式的形式按本文给出的解析规则书写。模块一为接口模块，硬件人员按照规则将解析格式写入数据库，并能够再次读取数据库并显示。模块二为数据解析模块，数据解析时，首先从数据库中读取解析格式，生成一系列配置文件，然后解析模块读取这些配置文件对数据进行解析。

数据库中存在两种类型的表格：一种为包性质表(注册表)，它包含一类或者一系列包的属性定义；另一种为包格式表(格式表)，每个包对应一个格式表，它指明包的解析格式。这样在解析一种数据包时，首先从注册表中找到该包的属性，包括长度、起止关键字等，然后查询需要的格式表，从而找出解析格式。配置文件的内容与相对应的数据库中表格类似，名称相同，可以看作数据库的一个副本，以下描述统称为数据库。

1.1 注册表介绍

注册表表征包的一些基本属性，它包括如下信息：

title：包名称，对应格式表名称，具有唯一性。

type：包类型，是识别包的关键信息。某一数据文件对应一个或者多个包，将它们的类型设为相同，可以快速得到该文件对应的包。比如对于硬X射线调制望远镜卫星，物理事例包、标定事例包的类型都是事例型。本文建议利用APID代表包类型。

header：表征数据包的起始点，它由起始位置、结束位置和值组成。其中，值可以有两个，这是因为有些载荷通过轮换header表征丢包信息，比如前一个包值为0x103B，而后一个则为0x183B；

mode：表征数据包的性质，相同类型的包性质可能不同，比如header表征事例包，而mode进一步表征该包为科学事例包或者标定事例包。它由起始位置、结束位置和值组成。

main：是否为主包，对于工程数据，一个文件对应一种主包，但是该包可以包含多个嵌套包。科学数据文件可能包含多种并列包，但是它们出现的频次不同，频次最高的包定义为主包，以方便高频次调用，同类型包只能存在一种主包。

length：它由起始位置、结束位置及预设值表征，如果位置存在，则位置所在的值为包长度，否则查看预设长度，如果预设长度存在，则该类型的包长度固定，否则为可变长度包。

tail：表征结尾，由起始位置、结束位置及预设值表征，如果包为可变长度包，起始及结束位置不存在，建议硬件端设置预设值，比如0xFFFF表征包结束。

validation：特殊位置及其值检查，一般设置两处(每一处包括起始位置、结束位置和值)可供选择。

crc^[4]：包校验位置和长度，对于可变长度包，建议硬件端将位置设在tail之前。

为了方便解析，length与tail必须存在其一，length可以只有预设值。嵌套情况下，嵌套包header和mode必须存在其一，且为整字节，硬件设计的嵌套不是简单地将一部分解析打包，而是与电子学读出有关，比如采集不同的电子学通道时，如果数据结构相同可以采用嵌套(即使数据结构不同，如果数据量相同，依然可以采用嵌套)。与之对应的是软件定义的嵌套，软件人员可以将一些数据结构定义为嵌套包，此时嵌套包不需要header/mode，只给出唯一的title即可。另外主包及嵌套包如果存在tail，需要设置不同的值来区分。非定长结构尽可能靠近包尾，并且尽量使一个包中仅有一个非定长结构。

其它的一些重要信息：type和header/mode确定唯一的格式表，title唯一，用于寻找格式表，validation和crc用于检查，一般而言，如果crc校验失败，则丢弃该包。

比较常见的包定义title，type，length，crc，而header，mode，tail，validation都可以不存在。如果不存在，硬件端可以将其属性值设为-1，比如mode不存在，则需要将其起始、结束位置及值均设为-1。起止位置为相对于包开始的位数或者字节数。

1.2 格式表介绍

格式表用于记录每种数据包的解析格式，对应注册表的一个记录信息。它包括：

id：待解析变量的序列，自0开始，用户可以通过id获得解析量。

title：待解析变量的名称，用户可以通过title获得解析量。

position：待解析变量的地址，可以存在两个位置，每个位置有起始位置、结束位置及标识表征，第一个位置为低位，后一个为高位。多数待解析变量只用一个位置表示，另一个位置的量可以设为-1，如果位置中仅有起始位置，而结束位置设为-1，则表示待解析量为不定长度。标识表征位置为绝对位置还是相对位置，前者表示自包开始的位置，后者表示相对于上一解析量(id-1)的位置，对于不定长数据结构，其末尾可以占据整数字节的任意位，相对位置不固定，这样要求非定长结构需要占用整数字节，如不够则对剩余位进行填补。

type：待解析变量类型，0表示一般变量或者连续型定长数组；1表示连续型非定长数组，所谓非定长数组是指数组长度不定，需通过解析其它信息获取；2表示间断型非定长数组，此数组在内存上不连续，而是相邻数组元素间隔一定的长度。一般几个数组交替出现，这种结构对应多通道或者多单体数据采集。对于type=0，position表示整个解析区间；对于type=1，2，position只表示数组第1个元素的位置；如果type为3，表示待解析为包类型。

reference：当type为3时使用，类型为字符串，其值为包名称，可以通过该值获取嵌套包解析格式。如果此处为空，表示该处可以放置多种嵌套包。

repeat：当type=0时，此值表示数组维数(数组为连续的，将position指定的区间分为repeat份)，对于非数组型，此值可以设为1；当type=2时，repeat表示间隔距离，比如第1个元素的位置为[a, b]，下一个元素的位置为[b+repeat+1, b+repeat+1+b-a]。

flag：表征解析单位为字节(Byte)还是位(Bit)。

本文主要提供两种可变长度，一种是连续性数组，另一种是间断型数组，特别是后者，它实际可以用于多通道/多单体数据采集。为了解析方便，规定定义的非定长包只能有一种非定长结构。非定长结构只能占用整数字节，不足整个字节则填充预设值。下一个变量相对于非定长结构的位置以字节结束为起始。

软件定义的嵌套包可以不按整数字节定义，但是需要有明确的引用，比如可以将非定长结构“ABCABCABC…..”中的“ABC”看为一个嵌套包，该结构就成为一个非定长数组结构。

2 接口模块

接口模块的主要任务是完成注册表和格式表的记录和显示，并生成解析文件。这一接口允许硬件端随意改变解析格式而不影响软件端的解析。接口的实现采用基于网络的设计和开发，以网站的形式向硬件和软件人员提供(或者QT^[5]也是不错的选择)。表 1为网站涉及的人员及权限。网站涉及的层次结构如图 2。一个卫星项目主要分为平台包和载荷包，载荷包可以分为很多类型，比如科学包和工程包，每种类别均对应一个注册表和若干格式表。

网站后台的数据库采用MYSQL^[6]，一个卫星项目可以对应其中的一个数据库，注册表和格式表对应其中的表格。数据库名称可以定义为卫星名称，注册表的命名构成为：卫星名称+ “_” +载荷名称+ “_” +数据类别名称，其中，数据类别包括科学数据、工程数据等。格式表命名构成为：卫星名称+ “_” +载荷名称+ “_” +数据类别名称+包名称。

解析模块读取的是配置文件，而不是数据库，这样做的好处：(1)将解析模块和数据库解绑，两者不直接相关；(2)利用配置文件进行版本控制，载荷格式更新后，可以保存配置文件并记录时间，这在数据追溯中比较重要。

3 解析模块

数据解析主要针对载荷测试数据和卫星下传数据，前者组织比较松散，主要与载荷有关。后者比较有组织性，但是涉及多个单位和部门，需要协调接口。本结重点介绍文件的识别、注册表的读取、格式表的解析及对特殊数据的解析处理。

卫星下传数据有表征数据类型的字段或者值，可以对应本文中的包类型。建议下传数据文件和测试数据文件的命名规则包含APID或者是其它表征包类型的关键字。如果输入文件采用APID命名，需要建立APID与包类型、数据类别、载荷的对应关系。当然更简单的方式是名称中有包类别、数据类别和载荷关键字。

文件解析时读入文件名称，解析出其包类别、数据类别及载荷等信息。确定查询的注册表，并得到需要解析的格式表，需要注意的是一种数据文件可能对应多个格式表。

数据的获取首先确定注册表查询结果中的主包，如果没有主包，则各个查询结果为并列结构。所谓并列结构，是指查询的各个格式表都可能出现，需要利用注册表中的关键字进行匹配，匹配成功者为这段数据需要的格式表。如果存在主包，首先进行关键字匹配，匹配成功则调用该包的格式表，不成功则需要对其它查询结果进行匹配。确定格式包后，可以完整地获取包信息，对于定长则取length关键字指定的位/字节/字数目，对于非定长则搜寻数据的tail关键字。

关键字匹配中需要考虑header，mode和validation等，对于crc校验不通过者可以将该包剔除。获取解析结果需要明确非定长结构的长度，即数组维数，一般情况下该包的数据长度已知，则可以计算非定长结构维数，更一般的情况是非定长结构与某些变量关联，即某变量的取值或者其位数表征非定长结构的长度，如果用户已知其对应关系，则会非常简单地对非定长数据进行处理。

本系统的驱动是文件驱动型，一旦检测到新文件传输完成，系统自动进行文件的解析工作，但是需要用户预先定义输出数据的结构、数据获取的接口及输出格式。系统不提供“文件-文件”式的解析方式，这是因为这些解析量不需要全部记录，而只记录用户感兴趣的。文件中可能有多种数据解析格式和多种嵌套方式，不容易自动完成输出格式的编排。有时一个原始文件还需要产生多个其它文件，这样做弥补一些设计缺陷，对于变量之间的关联，用户容易得到这些关系。数据获取主要是用户通过格式表中的title或者id得到解析后的变量，输出是FITS^[7]格式。需要注意的是，一个解析文件可能生成多个输出文件。

4 总结

数据解析系统是卫星数据产品生产中最先进行的一环，不同的卫星及载荷尽管在数据设计上不同，但是都遵循数据的可解析性，这就是本系统的依据。数据解析在地面测试中同样重要，而且随着载荷的推进，解析格式也发生变化，本系统可以适应这些变化。本系统解析结果的正确性是保障获得物理成果的基础，文[1]提到的通用数据解析方法实际上是本系统解析模块的一个简化版本，它成功应用于POLAR和HXMT中能望远镜(Medium Energy X-ray Telescope, ME)^[8]地面数据解析中。本系统采用通用的解析方法，避免了软件人员直接处理大量的数据文件，这也是保障获得物理成果的一个重要因素。

卫星数据按包解析，本系统不涉及解析后的数据处理和存储，而是需要用户自行定义数据存储的结构和格式，用户通过本系统的接口获取解析后的数据。当这些条件具备时，本系统即可自动运行并与后续的软件共同协作生成数据产品。