卫星工程数据低流量推送系统的设计与实现

2018-04-02卢山，胡钛，李虎

电子设计工程 2018年3期

卢山，胡钛，李虎

（1.中国科学院国家空间科学中心卫星运控技术实验室，北京100190；2.中国科学院大学北京100049）

现有的主流科学卫星任务系统中的数据推送子系统采用 C/S（Client/Server）、B/S（Browser/Server）架构共存的系统方案。C/S架构中的消息传递机制是由服务器基于CCSDS协议数据格式与处理方法进行下行数据包解析后统一组播发送数据包给客户端，客户端接收处理得到所有的工程数据，然后客户端应用根据配置显示关注的参数数据。在B/S架构中，Web服务器接收组播消息得到所有工程数据，用户通过Web应用选取感兴趣的参数通过HTTP协议推送实时获取所选工程参数。

移动应用采用C/S架构的消息传递机制缺点是推送而来的大量冗余工程参数数据造成的流量浪费。另外在B/S架构中，HTTP协议推送是建立在长连接的基础上[1]，其通信效率比较低，依赖于服务器与浏览器之间的严格持久连接要求[2]。

目前 MQTT（Message Queue Telemetry Transport）协议在即时移动通讯系统中有较多应用[3-5]。本文通过将科学卫星工程参数名进行编码，生成固定长度的字符串作为主题名的方法，大大减少了MQTT协议接收“发布”控制报文时的可变报头空间。进一步降低数据推送的流量消耗。

1 移动端平台的推送机制现状

目前的推送技术分为两类，一类是基于HTTP的Ajax技术[6]与HTML5规范的 WebSocket技术[7-9]；另一类是基于TCP协议的通用消息中间件技术，比如XMPP协议、SIMPLE协议等[10-11]。但是它们在流量、功耗、传输方面都未充分考虑移动互联网与物联网的特点。

MQTT是IBM提出的基于TCP协议的轻量级发布订阅模型的协议。MQTT起初是IBM在开发物联网设备时使用的简单消息中间件协议，通过不断发展完善并将其开源。在2014年11月，MQTT v3.1.1版本成为OASIS标准，并在同年6月正式纳入ISO标准体系。

2 MQTT协议介绍

MQTT是封装在TCP协议基础上的点对点应用层协议[12]。MQTT的控制报文包括CONNECT报文、CONNACK报文、PUBLISH报文、PUBACK报文、PUBREC报文、SUBSCRIBE报文等，共14种控制报文。MQTT所有控制报文的报文结构都分为四部分，包括固定报头、剩余长度、可变报头和有效载荷部分[2]，如图1所示。

图1 MQTT控制报文格式

MQTT协议的控制报文都包含固定长度为1字节的固定报头，从第2字节开始，最长到第五个字节结束[13]。剩余长度部分最长为4字节的字段标识剩余长度值，表示当前MQTT协议控制报文的剩余部分字节数，包括可变报头和有效载荷部分，但不包括用于编码剩余长度字段本身的字节数。剩余长度字段采用变长度编码方案，当剩余字节数小于127时，剩余长度用1字节标识。当剩余字节数大于127时，每字节的低7位用于表示数据，最高位标识是否延续。可变报头位于剩余长度标识字节与有效载荷之间，可变报头的内容根据报文类型而不同，包含报文标识符、协议级别、协议名、连接标志位、遗嘱标志位、QOS等级位、遗嘱保留位、用户名标志、密码标志和连接保持标志位等。其中“发布”报文的主题名为主要部分。

3 系统设计与实现

考虑到兼容性，在不影响现有任务支持系统基础上，本文设计的MQTT协议的科学卫星工程数据推送系统分为三部分，分别为MQTT服务端、工程数据适配器端和移动端应用，并在MQTT协议的可变报头位置进行了主题名优化处理。具体架构方案如图2所示。

图2 MQTT协议的科学卫星工程数据推送总体架构图

3.1 系统需求功能描述

空间科学卫星运行系统主要包括测控系统、科学应用系统、任务支持系统、数传地面接收站系统。空间科学先导专项运行系统按照运控计划实施接收数据接收工作，主要有来自测控系统的下行遥测数据和来自数传地面接收站的下行数传科学数据，任务支持系统按照数据包格式约定将这些数据进行预处理及加工得到用户需要的工程数据。

用户在移动端应用进行勾选感兴趣参数操作，在轨卫星过境时或者工程参数回放时，用户可以进入可视化界面等待MQTT服务器推送的数据进行可视化。

3.2 服务端器部署

本文中的MQTT服务端[6，14]主要分3个层次，分别是MQTT协议层、应用层、数据持久层。第一层是MQTT协议层，是MQTT协议的控制报文生成与发送层，它通过使用套接字对TCP协议按照控制报文格式进行封装并通信。第二层是应用层，包括话题统计模块、服务器状态监视模块、连接状态监视模块、用户管理模块、数据库模块等，这一层完成整个服务器端的逻辑工作。第三层是数据持久层，数据持久层通过配置文件或者命令行的方式进行配置的初始化。初始化后，为应用层中的数据库模块提供方法调用，实现在文件中存储数据与读取数据。

3.3 工程数据适配器设计实现

3.3.1 工程数据适配器设计

工程数据适配器功能与BS端架构的Web服务器类似。主要完成3个功能：一是根据XML配置文件解析并完成参数主题名的优化，最后存入哈希表中；二是接收来自任务运行系统的组播数据并根据哈希表中的相关参数解析每个组播数据包中的工程参数；三是将每个工程参数封装为MQTT协议的“发布”报文后以优化的主题名进行消息推送。以上功能设计主要考虑UDP组播格式、工程参数配置文件和MQTT主题名设计。

1）UDP组播格式说明：

组播数据包的格式如图3，每个组播数据包为一个逻辑参数包。组播数据包中的参数序号、源码、物理量、阈值合法性对应不同的参数，随着参数的增多，组播数据包变大。

图3 组播数据包格式说明

2）工程参数配置文件说明：

任务支持系统将经预处理得到的工程数据后，先进行解包操作得到各工程参数数据，然后按照工程参数配置文件进行打包转发到工程参数数据输出端。配置文件有两种形式，一种是记录式文本配置文件，另一种为XML格式配置文件。本文涉及系统选用XML格式作为配置文件，其结构如图4所示。

图4 XML格式配置文件

XML文件的根节点为Satellite，它的子节点为多个Package节点，Package节点对应组播UDP包中的逻辑数据包标识，name为其属性；Package节点的子节点为一个Set节点，该节点对应工程数据的一类集合；Set节点的子节点为多个Parameter节点，该节点的内容为每一项参数的描述信息；其中，Parameter子节点中的No节点对应组播UDP包中的参数序号，Length节点对应物理量长度，Size节点对应源码长度。

工程数据适配器通过源码长度值与物理长度值确定组播数据包中每个参数的数据段范围完成解析数据包操作。

3）MQTT主题名优化策略：

由于参数名和逻辑数据包名为中文字符串，一般采用GBK或者UTF-8编码。如果直接使用参数名或逻辑数据包名作为主题名，这种情况下由于“发布”报文的可变报头部分包含主题名，这会增加传输可变报头时的数据流量。

本文通过将参数名与逻辑数据包名进行重新编码形成主题名的策略，减少主题名在报文中空间使用。本文将可变长的参数名与逻辑数据包名空间映射到固定长度主题名空间，从而达到MQTT协议主题名优化目的。每次客户端与服务器端进行订阅、发布只需要通过优化后的主题名列表进行信息交互，降低服务器端向客户端推送数据的流量使用。

因此工程数据适配器以编码后的参数名、逻辑数据包名命名主题会大大减少可变报头大小，实现更低流量的推送与接收。

3.3.2 工程数据适配器实现

工程数据适配器在初始化阶段完成第一个功能。首先进行XML配置文件初始化参数配置哈希表容器，遍历XML文件中的Package节点，通过Parameter节点下的ParaCode节点获得逻辑数据包标识，并保存到Package结构体，每遍历完一个Parameter节点将其添加到Parameter的哈希表中，每个Parameter的哈希表中分别保存着参数序号、源码长度、物理量长度、参数名、主题名的结构体信息。当所有参数遍历完成之后将Parameter的哈希表头节点添加到Package的哈希表中。同理，依次添加其他Package节点。。最后哈希表保存了工程数据适配器从XML文件中解析后获得的配置信息。

当接收到来自任务支持系统的组播UDP数据后，根据组播UDP包中的逻辑数据包标识查找Package哈希表对应的Package，然后根据组播UDP数据包中的参数序号查找Parameter哈希表中对应的参数以获得源码长度和物理量长度。如果参数物理量长度为0，则只推送源码，否侧只向主题名推送物理量。由于每个逻辑数据包中的参数代号为0的参数处于保留状态。所以将每个组播UDP数据包的星上时推送到对应逻辑数据包标识中对应的0参数序号的主题名上。完成单个组播UDP数据包的解析与向对应主题的发布后，接收组播UDP的socket进入阻塞状态等待接收下次组播UDP数据包的到达。

3.4 移动端应用

本文的移动端应用基于Android MVC框架模式[4，15]。控制层通过主要完成封装MQTT协议与发送、接收MQTT报文，并操作模型层。模型层根据可视化层中数据的类型的需要，通过单例模式实现模型层。视图层主要是通过依赖基于Java Canvas控件开发的开源框架实时完成曲线的绘制。

在可视化界面中，每个参数的星上时作为横坐标轴，参数的物理量作为纵坐标。参数对应星上时来自逻辑参数逻辑包对应星上时主题，物理量来自参数对应主题。

在每次客户端初始化时，必须先订阅解码表所在主题，并设置工程数据适配器推送解码表时采用Retain的方式，以便所有客户端订阅编码表主题时都能获得解码表。

4 系统测试及结果分析

本文的测试通过模拟在线任务支持系统向工程数据适配器发送一段时长约10分钟的工程数据包进行测试。这段测试数据源是由科学卫星过站时在轨运行任务支持系统从测控系统接收到的遥测工程数据，再由任务支持系统发送的组播UDP包，最后进行本地保存的方式获得。测试系统通过模拟任务支持系统发送组播UDP数据包实现科学卫星过站时的下行科学卫星工程数据流程。

由于任务支持系统发送的是组播UDP数据包，系统测试必须考虑由于发送频率过高导致UDP的丢包问题[16]。任务支持系统发送的UDP数据包是按照将地面接收系统或测控接收系统发出的TCP数据流进行解包再打包的流程操作的，因此会有时间间隔。只要工程数据适配器在时间间隔内完成UDP包的解包与推送操作就可以将程序导致UDP丢包的问题解决。测试系统播放的是一段时长为10分钟的遥测工程数据文件。如果在10分钟内回放完毕所推送的数据量，与在更短的时间内回放完毕所推送的数据量一致，就可以认为工程数据适配器没有因为程序在解包与推送时耗时过长造成UDP数据包丢失。

4.1 测试方法

本地保存的UDP数据为连续的UDP数据包流，为了模拟任务支持系统发送的组播UDP包，需要根据任务支持系统内的约定格式进行发送，即一个UDP数据包为一个逻辑数据包并包括其下所有参数。实际每个组播UDP数据包的结构进行拆包后再发送。

测试系统通过拆包后发送UDP数据包的方式模拟任务支持系统发出的组播UDP包。工程数据适配器收UDP包后进行解包与推送到服务端，同时移动端应用订阅感兴趣主题。当服务端收到工程适配器的发布消息后推送到移动端应用，最后由移动端应用完成可视化操作。

4.2 测试结果与分析

4.2.1 功能测试

如图5、6所示。图5左截图为移动端应用的订阅参数界面，右截图为勾选“星务采集母线电压”工程参数界面。

图5 移动端应用界面

图6所示为参数可视化界面的截图，可视化界面采用曲线的方式进行显示。

从上面的测试结果可以看出移动端应用与系统的订阅功能、推送功能、可视化功能良好。

4.2.2 性能测试

表1与表2所示的数据为测试文件由测试系统回放完后，通过统计工程数据适配器的日志信息得来的数据。

性能测试共3个测试项目，分别是1分钟回放完数据、5分钟回放完数据、与采用未优化主题名时1分钟回放完数据。

图6 参数可视化界面

表1 接收测试统计表

从表1中可以看出，长约10分钟的数据源文件，1分钟回放完数据与用约5分钟回放完数据，两次推送的剩余字节数一致。从两次的对比可以看出，工程数据适配器没有产生丢包。

表2 优化测试统计表

从表2中的前两个测试可看出采用优化主题名的推送的剩余字节数为3 650 390字节。第三个测试直接采用主题名与工程参数名一致的方式进行推送的剩余字节数为23 808 212字节。对比可以看出主题名的优化带来6倍以上的流量优化。因为用户一般不会订阅所有主题，因此这无法代表用户通过移动端应用订阅感兴趣主题时节省的流量，但可以反应出平均的优化效果。