航天器在轨基线控制系统设计与实现

储海洋

(北京空间飞行器总体设计部，北京 100094)

0 引言

掌握航天器在轨状态是地面飞行控制的前提，通过遥测数据对航天器状态进行判读是最常见也是最直接的方法，但是航天器测控技术的发展[1]使得遥测信息量爆发式增长，对于设计师人工审阅而言，这种传统的状态管理方法愈发显得过于细节，不能帮助设计师从宏观上快速掌握航天器的在轨状态。

随着我国在轨航天器数量的快速增加，采用信息化的方法，提纲挈领的快速掌握在轨航天器状态，并让其在设计师之间透明无歧义，已经成为减轻设计师人工阅读航天器在轨状态工作负担、提升状态管理水平的研究方向。在轨航天器的状态包括诸如能源、姿态、单机工作状态、软件运行状态等各个方面，在航天器的飞行过程中，地面对其状态有一个明确的预期，这个预期可被定义为基线状态[2]，而航天器在轨的实际状态则可以称为飞行状态，若飞行状态与基线状态相符，表明航天器在轨飞行正常，若出现不符，则说明出现了异常情况，需要设计师提高警惕和处置。

目前，如何对在轨航天器的状态进行全面而准确的描述仍然是一个值得研究的课题。在轨管理的设计师初步从以下四个方面对航天器在轨飞行状态进行结构化描述和判读。(1)单机工作状态：描述星上单机及其模块的工作状态，比如“开机”、“关机”等；(2)软件版本状态：描述每个星载软件的版本及补丁情况；(3)运行模式状态：以分系统为单位，描述卫星所处的运行模式，比如遥控处于“明态”，姿态处于“三轴稳定”；(4)自主功能状态：描述卫星每项自主功能的使能/禁止状态，比如：GPS自主校时处于使能状态等。以此为基础，提出了航天器在轨基线控制系统的研制需求，本文对设计师的任务需求进行了分析，设计和开发了航天器在轨基线控制系统，定义当前的预期工作状态作为基线状态，然后通过实时遥测结合预定义规则判定飞行状态，将航天器基线状态与飞行状态实时比对，进行状态监控和报警，快速发现航天器飞行状态异常；记录航天器在轨基线变更历史，形成航天器基线变更履历，实现航天器基线状态变更有记录、可追溯。

表1 单机状态管理示意表

表2 软件状态管理示意表

1 任务需求

1.1 功能需求

对任务进行分析，主要包括以下四方面功能需求:

1)选定一个在轨航天器，能够查看其当前的基线状态和飞行状态。

2)能够实时对照飞行状态与基线状态的一致性，当发现飞行状态与基线状态不一致时，系统进行报警，由设计师进行处置。

3)记录基线状态的变更历史，实现基线变更留记录，可追溯。

4)变更数据分析和挖掘，研究挖掘基线变更数据与航天器在轨寿命、产品质量等因素之间的关联关系。

其中，基线状态指地面预期，飞行状态指通过实时遥测判定的实际工作状态。内容包括以下四个方面。

(1)单机及模块的工作状态：

为了更加准确的描述单机的工作状态，将单机状态管理的粒度细化到模块级别,每个模块具有若干可能的工作状态，这些状态能够通过遥测反应确定，在轨飞行中，地面对模块的状态预期构成单机的状态基线，通过遥测判定各个模块的飞行状态，管理示意如表1。状态判定采用逻辑表达式描述，若实时遥测使判定表达式为真，则单机或者模块处于该状态。

(2)软件版本状态：

每台单机或者模块下可以装载软件，对于每个软件记录其版本号和补丁情况作为基线状态，示意如表2所示。

某些软件版本号会通过实时遥测下传本文根据当前遥测解析的实际情况，按照一个遥测参数标识软件版本号中一位的参数解析模式，对下传的遥测版本号与基线版本号比对方式做如下规定：

①一个完整的软件版本号需要多个遥测参数进行标识，参数间使用‘.’进行分割。

②版本比对从低位向高位比对，若高位无对应的遥测，则默认高位一致。

③若存在版本号遥测复用，则使用逻辑与符号(&&)对条件和版本进行分割，比如软件A的版本号关联遥测为：‘VEP==0&&VER001.VER002.VER003’，表示当参数VEP为0时，VER001.VER002.VER003的值是软件A的版本号，参数VEP不为0，则VER001.VER002.VER003可能是其他软件的版本号。

(3)运行模式状态：

运行模式是一个抽象概念，宏观地描述航天器所处的状态，比如遥测遥控的明密态模式，航天器的姿态模式等，每个运行模式有若干个可能的运行状态，在航天器飞行过程中，地面控制系统对其同样有明确的预期状态作为基线，管理示意表如表3。运行模式的判定规则与单机及模块的状态判定规则类似，采用逻辑表达式描述。

表3 运行模式状态管理示意表

(4)自主功能状态：

随着航天器智能化程度的提高，航天器上自主功能项越来越多，每个自主功能项都有使能和禁止两种状态，也纳入系统管理的范围，管理示意表如表4所示。

表4 自主功能状态管理示意表

图1 航天器在轨基线控制系统架构图

1.2 设计约束

1)系统需面向多航天器任务开发，能够支持不少于200颗航天器的在轨基线控制。

2)以秒为单位，实时完成遥测数据的接收、状态判定、显示和报警。

3)系统采用BS模式实现，设计师只需要通过浏览器即可访问，不需要额外安装任何客户端软件。

2 系统设计

2.1 方案设计

以消息总线为本系统与遥测接收解析系统的边界，用户通过浏览器完成基线及状态判定规则设定，系统从消息总线获取实时遥测，从数据库中加载状态判定规则进行判定，将判定结果分发到各终端用户的浏览器上监视和报警，整体方案如图1所示。

2.2 功能设计

对系统功能进行详细设计，框图如图2所示，整体上分为四个部分：系统管理、基线管理、监控报警和数据分析。

图2 航天器在轨基线控制系统功能框图

系统管理和一般系统的系统管理功能差别不大，不做多余介绍。

基线管理，在每个航天器内，以分系统为单位进行数据组织和管理，其包含三个方面的内容：(1)基线信息管理，编辑航天器基线的基础信息，如产品名称、代号等，并支持导入导出以提升编辑效率；(2)判定规则管理，对每一个可能状态的判定规则进行设定；(3)基线变更管理，随着航天器状态的变化，地面需要对基线状态进行及时调整和变更，需要记录每一次变更的申请单、变更内容、变更时间、操作人等信息，形成航天器在轨飞行时的基线变更履历，以供后续分析。

监控报警包括状态监控和状态报警两个部分，针对每一个航天器，设计状态监控页，显示航天器当前的基线状态和飞行状态，从而能够对航天器状态进行全面详细的了解。鉴于航天器上单机、软件、自主功能数量众多，为便于设计师工作，系统设计报警页，可以将基线状态与飞行状态不一致的情况进行集中显示和报警，提供单机报警、软件报警、运行模式报警、自主功能报警、单型号报警、多型号集中报警等多个层次的集中报警功能。

在基线变更数据记录汇集之后，可以从时间、分系统、单机及模块、软件、运行模式、自主功能等多个维度进行统计分析，比如分析各单机的基线变更次数，为单机质量评价提供参考；分析软件的基线变更次数，查看软件版本升级与补丁情况等，进一步可以将多航天器的基线变更数据汇总分析，例如查看一年内各航天器的基线变更情况，分析变更次数与航天器在轨寿命的关联性等。

2.3 性能设计

2.3.1 数据库检索性能设计

数据层一般采用数据库系统实现，以往系统在处理多型号数据时，多采用数据库内索引加外键的模式完成，将所有型号的数据存入一个逻辑数据库中, 这种模式简单快捷,但是各型号之间数据的逻辑隔离性差,因此,本文采用一个索引库加若干型号库的多数据库模式, 一个型号一个独立的逻辑数据库，整个系统一个索引库，索引库记录各个型号库地址和其它公用信息。通过索引库的管理，能够快速完成型号数据在本系统中的挂载和卸载，如图3所示。

图3 两种数据库处理多型号数据模式

与单数据库模式相比，多数据库模式具有以下优势：

1)型号间数据逻辑隔离，一个型号内的数据出现逻辑错误，不会影响到其它型号。

2)索引库数据量及其有限，各型号数据在其寿命期内也是有限的，不会像单数据库模式那样随着型号数量的增长，导致系统数据库中数据量的爆发增长，从而影响检索速率。

3)以型号为单位组织逻辑数据库，便于数据的迁移、备份和还原，有利于进行系统运维。

其劣势在于，查询多个型号数据进行横向比对时，需要跨库检索，操作稍显麻烦，但是这种应用场景相对较少，其劣势可以接受。

2.3.2 数据判读监视性能设计

1)在浏览器端，通过Web Socket维持前后台数据长连接，以订阅发布的模式[3]，由终端根据当前呈现的内容需要，向后台服务订阅数据，后台服务在收到遥测更新后，仅将需求的数据转发，数据量极大减少，能够有效保证系统响应性能。

2)在服务端，随着型号数量的增加，实时遥测数据量激增，状态判定、监控报警的实时性能压力将快速提升，为此，首先将状态判定服务和消息分发服务的功能分解，独立成两个服务，分别部署，以减轻服务压力。在此基础上，将状态判定服务按照型号分解，每个型号的状态判定服务独立部署，以解决型号数量增加可能带来的性能瓶颈。消息分发服务主要是将消息总线上的消息按照各终端需求转发，其不需要缓存任何消息总线上的数据，其性能压力主要在于终端请求数量，采用分布式部署和负载均衡，减少每个服务需要处理的请求数量，以缓解终端请求数量增加的压力。

3)按照上述设计，系统在处理多型号任务时,其性能瓶颈将主要受制于消息总线的吞吐能力。目前比较典型的分布式消息总线包括Microsoft MSMQ、RabbitMQ、ActiveMQ以及Kafka等[4]，其中Kafka在消息派发方面有着独特的优势，它以可水平扩展、可靠性高、可异步通信和高吞吐率等特性而被广泛使用[5]，测试数据表明，在3节点(物理机配置：32核CPU、64 G内存、千兆网卡)Kafka系统中，向一个6分区，1副本的主题发送消息时，吞吐率可达50 MB/s[6]，而航天器的实时遥测速率一般不超过50 Kb/s[7]，解析后，实时遥测数据速率不大于200 kB/s，按照200颗航天器计算，总速率不超过40 MB/s，系统性能余量已经足够充裕，每秒可无延迟完成遥测数据的接收、状态判定、显示和报警，满足性能要求。当型号数量继续增长，一个消息总线的容量不能满足要求时，可对型号进行分类挂载到不同的消息总线上，以进行横向扩展。

3 实验结果与分析

设计完成后，按照软件工程化的方法进行开发和实现，开发语言及环境选型如下：开发语言：node.js[8]，V12.13.1；消息总线：Kafka，V2.4.1；数据库：Mongodb[9], V3.4.24；Web框架：Thinkjs[10], V3.2.10；服务运行环境：Centos 7 X64, V7.4.1708；客户端环境：Chrome浏览器 V80.0.3987.149。经过需求分析、概要设计、详细设计、编码实现、测试验证等一系列工程活动后，最终完成了系统的研制，并部署使用。

系统部署后，选择19颗北斗三号组网卫星(包括GEO卫星、IGSO卫星、MEO三种轨道类型)的模型及实际遥测数据进行应用验证，结果表明，基线模型信息化管理正确，飞行状态实时判定延迟小于200 ms，无漏判，系统运行效果良好。

终端呈现效果参考图4所示。

图4 基线监控首页(数据为填充数据)

4 结束语

本文围绕航天器在轨状态管理和控制，设计并研发了航天器在轨基线控制系统和平台，从单机、软件、运行模式和自主功能四个方面对航天器的基线和飞行状态进行描述，实现了基线状态的变更控制，飞行状态的实时监控及其与基线的实时比对报警，为地面进行飞行控制提供了基线参考。飞行状态的实时监控是对传统遥测监视的有益补充，其更加宏观、简洁。消息总线和基于Web Socket订阅发布模式实现了浏览器端的数据实时监控，也为后续遥测监控系统的研制提供了新的思路和参考。

下一步，还需要继续深化和拓展航天器在轨状态描述的内容和方法，延伸基线的内涵，比如热控控温阈值、航天器自身温度场状态、软件运行时状态、所处空间环境等，然后将这些不同纬度不同来源的数据挂载到基线控制平台上，更加全面准确的描述航天器在轨基线状态和飞行状态，并通过基线控制平台使其在设计师之间透明，为航天器飞行控制的科学决策提供依据。