通用指挥显示数据引擎架构及应用设计

周 宇，尹志锋，李林峰，周 淦

(中国电子信息产业集团有限公司第六研究所，北京100083)

0 引言

随着信息技术的高速发展，我国航天发射试验任务已经进入以数据为中心的时代，高效易扩展的数据交换、管理是数据展示以及数据应用得以实现的基础。当前，航天发射场的测发、测控、气象等系统已经可以在网络中完成数据的交互传递，且各发射场均已独立实现了将各大业务系统信息初步融合的“一体化”试验任务测发指挥监控系统，但是由于发射场原有业务系统之间并没有统一规划互联、互通，实现方式方法各异，且在扩展性方面存在一定的不足，以及系统间的数据综合服务需求各异，与航天发射场未来一体化发展目标具有一定差距。

本文通过总结发射场指挥显示数据流转过程和使用处理需求，提炼了包含数据收发、解析处理、存储获取共三大关键要素的发射场指挥显示数据引擎“服务簇”，同时也引入了双工、日志、网络代理等配套服务。通过提出的高灵活、可扩展、统一服务的通用数据引擎架构，定义了标准服务间数据交互接口，可以有效实现服务灵活调度的同时，还实现对各发射场内外部不同数据协议、流程的高扩展支持。系统将有效推进我国航天发射场指挥显示系统的“一体化”实现。

针对提出的面向试验任务指挥显示的通用数据引擎架构，本文从总体结构、工作原理、应用模式几个方面进行了阐述。

1 航天试验任务测发指挥监控系统

航天试验任务测试发射指挥监控系统简称测发指挥监控系统，是航天发射任务指挥的支撑技术平台。测发指挥监控系统针对的对象是“航天器的测试、发射”，实现的功能是“指挥”、“监控”，即汇集信息、监视显示、辅助决策、指挥调度[1]。

1.1 综合指挥显示信息

航天发射场测试发射指挥员和各专业专家，通过指挥监控系统显示的各系统的测试信息，了解当前火箭、卫星、航天器以及地面勤务系统的工作状态，指挥测试发射进程[2-3]。在由航天员参加的发射任务中，还需要显示航天员系统的相关信息。为此测发指挥监控系统需要汇集的信息包含任务的进程信息、航天器的无线测试信息、航天器的下传测控信息、运载火箭的有线测试信息、运载火箭的遥测信息、航天员的生理信息、发射场的气象信息、发射场的发射支持设备信息、发射场的通信和测控系统设备工作信息以及各关键部位的视频信息等。先进的测发指挥监控系统还将提供运载火箭、发射场发射支持设备、待发段航天员逃逸等故障诊断系统以及任务进程辅助系统，相关信息也将便于专家和指挥人员更加深入地掌握系统状态。

1.2 “一体化”发展目标

目前航天发射场指挥决策系统是由大业务功能驱动下的多模块、多系统集成的应用系统。指挥监控“一体化”是实现试验任务高效、灵活、可靠开展的必然发展路线。“一体化”包括：业务分系统监测数据展示一体化，业务分系统监测数据管理应用一体化，任务配置、组件共享一体化，系统部署、升级、维护的运营一体化，以及更进一步的各发射场任务统一管理一体化。

部分发射场已经实现了现有业务分系统监测数据展示一体化，但并未真正实现监测数据的一体化接入，一方面体现在部分数据展示仅通过页面嵌入方式接入，无法形成有效的风格统一，也无法对接入的数据进行有效的管理；另一方面也体现在现有数据接入方式无法有效适应未来更加丰富的接入模式，也意味着无法向监测数据管理应用(数据治理)一体化迈进。对发射场现有各业务分系统进行升级改造无疑是条长远而艰巨的发展道路，当前可行且长远的指挥监控一体化发展解决方案将围绕指挥显示展开，其首要解决的问题是构建指挥显示通用数据引擎[4]，从而支撑统一的指挥显示数据的接入、存储、管理与平台显示[5-6]。

2 数据引擎架构研究

考虑能够满足发射场各类岗位人员的多样需求以及能够满足未来新的指显数据接入需要，通用指挥显示数据引擎采用“平台+组件”的模式来支持对航天发射任务中指显数据的多类任务、多个阶段、多种形式的兼容[7-8]。其架构研究主要考虑以下两点：

(1)统筹当前需求，实现平台一体化

结合发射场和北京中心的指挥显示需求以及当前指挥显示相关系统建设情况，统筹考虑各类型发射任务，发射场各业务分系统特点，数据接入、管理、存储、显示需求，实现一体化。

(2)适应长远发展，支持扩展开发

综合考虑航天器、运载火箭等系统的不断升级变化以及发射场基础设施的新建、改造，数据引擎还要具备扩展开发支持能力，以组件、辅助工具升级为主要方式，以平台升级改造为特殊手段，使系统具备长期适应能力。

2.1 开放式平台

通用指挥显示数据引擎采用“平台+组件”的设计思想[9-11]，由主框架(平台)及(可扩展)组件构成，架构如图1所示。

图1 数据引擎“平台+组件”可扩展架构设计

(1)组件层：数据引擎支持通用组件以及专用组件的接入，以满足不同任务、不同类用户的需求。各类组件是支撑数据引擎各项服务的重要组成部分，负责相关服务的具体实现。对于数据引擎而言，需要实现数据解析服务，外部数据收发服务，数据存取服务以及双工、日志、网络代理等相关配套服务。

(2)服务层：数据引擎的服务层介于组件层与逻辑层之间，服务层是对组件实现的抽象，是对系统行为的定义，为业务逻辑层提供相关功能服务。服务层将具体的业务逻辑需求与具体的功能实现进行解耦，使得系统具有较高的可扩展性，有利于系统的升级。

(3)逻辑层：数据引擎的逻辑层是整个平台稳定运行的核心，是航天发射任务指挥显示数据流转管理逻辑的具体实现。具体功能包括平台初始化、运行中数据管理、状态统计、服务调度等。

(4)交互层：数据引擎的交互层是与系统管理者直接交互的窗口。通过可视化或通信接口的方式，实现对各类服务的配置、运行管理、状态统计等功能，数据引擎响应各类事件，驱动各类服务。

在数据引擎的架构中，组件是一个独立可替代的模块，它是对逻辑的封装，隐藏了内部实现，只提供输入输出接口。组件化设计遵循独立、完整、自由组合。“组件”式建模的优势在于将整个指挥显示数据的接入、管理等化简为繁，各组件单独开发与测试，极大降低系统的维护难度和模块间的耦合度，并有效地提高系统的复用性和可扩展性，满足一体化指挥监控系统快速灵活的服务要求。

2.2 数据引擎服务定义及使用

通用指挥显示数据引擎的通用化依赖于数据引擎内部各类服务(组件)的标准接口以及服务调度的管理实现。而各类服务之间的标准接口主要依赖于一种能够在各服务间进行流转的通用数据表达方式。在通用指显数据引擎中，各类服务的接口主要依赖于定义为“通用数据包”的数据组织进行信息传递。

2.2.1 通用数据包类

通用数据包是一种可直接在各服务间流转的通用数据组织表达，各类服务将根据服务属性配置以及通用数据包的各类属性完成相关服务提供。通用数据包属性如表1所示。

表1 通用数据包属性

2.2.2 外部数据收发服务

数据引擎支持外部系统接口配置绑定对应的外部数据收发服务，当外部数据收发服务接收到所绑定接口接收到的数据后，生成一个通用数据包，并填充数据包管理标识、接口标识信息，提交给平台进行数据管理以及服务调度。当需要数据收发服务将源码向外转发时，从通用数据包中取出数据包原始数据进行发送。当需要对数据包原始数据进行关键字段替换等处理时，则需要实现外部数据收发服务的二次开发，并需要向数据引擎暴露相关配置接口(详见第2.2.5节)。

2.2.3数据解析服务

数据引擎支持外部系统接口绑定对应的数据解析服务，数据引擎在收到外部数据收发服务提交的通用数据包时，根据接口标识信息获取接口所绑定的数据解析服务，并将通用数据包交由数据解析服务进行进一步处理。数据解析服务根据所绑定/内置的解析规则，将通用数据包中的源码数据进行解析，转换为解析后的数据集，并填充到通用数据包中。当接口有校验配置时，在解析前进行校验，并填充通用数据包对应字段对。另外，当数据引擎仅作为数据分发使用时，通常不需要调用数据解析服务，这种情况下，数据引擎直接将通用数据包交由数据收发及存取服务进行转发和存储。

对于数据引擎而言，数据解析服务以读写方式操作通用数据包，而数据存取服务、转发服务以只读方式操作数据包，也即数据转发服务以及数据存储服务需在数据解析服务完成后进行，并可以并行进行。而通用数据包的销毁则由数据引擎平台来进行管理。

2.2.4 数据存取服务

数据引擎支持外部系统接口绑定对应的数据存取服务，数据引擎在进行数据解析后，根据接口所绑定的数据解析服务，将通用数据包交由数据存储服务进行数据存储相关操作。数据存储服务根据所配置/内置的存储规则，将通用数据包中的源码或解析后的数据集进行存储。

2.2.5 服务插件扩展属性配置

数据引擎对各类服务提供相关配置功能，其一方面依赖于对各类服务的核心功能抽象，另一方面也依赖各类服务的具体实现。数据引擎平台的通用性，主要依赖于相关服务基本接口的通用性。

以数据存取服务为例，对于测发指挥监控系统而言，通常需要支持两类数据存取服务，一类为源码存储，需要配置文件存储根目录等信息；另一类为关系数据库存储，需要配置关系数据库地址、用户名、密码、驱动等信息。显然数据引擎需要两个数据存储服务的子类来对数据存储服务进行配置管理区分。而所有数据存取服务均可配置容量告警这一属性。考虑未来出现新的指显数据存储需求，数据引擎可能需要为新引入的数据存取服务，并需要提供更多的配置接口给用户，在数据引擎各类服务的标准接口中，均包含“获取额外配置项”以及“应用额外配置项”的接口，当服务需要非标准配置时，需要各服务实现以上两个接口。数据引擎将通过“获取额外配置项”接口获取相关服务非标准配置需求，并提供人机交互窗口，将配置结果使用“应用额外配置项”接口交由对应服务进行初始化。

2.3 数据引擎工作原理

通用指挥显示数据引擎基于“平台+组件”的设计思想实现，在平台服务调度的组织下，实现指挥显示数据的接入、解析、存储、分发及实时管理的全流程调度[12]。数据引擎的服务调度具体实现依赖于监听者/观察者方式，以外部系统状态数据为例，当接收/获取到一组外部数据时，产生相关事件，而通过对相关接口的配置，实现数据转发、解析、统计以及存储相关组件对其事件进行响应[13-14]。

通用指挥显示数据引擎主要涉及的交互及相关处理如下，其工作原理示意如图2所示。

图2 数据引擎工作原理示意

(1)外部业务系统：外部业务系统包括中心机系统、火箭测试系统、地面系统等系统，相关系统主要通过组播、可靠连接、网站访问等方式提供各类系统业务相关数据。而数据引擎通过加载相关收发及解析组件实现外部业务系统的接入及转换。

(2)各类指挥显示软件：数据引擎为各类指挥显示类软件提供数据支持服务，数据引擎提供数据订阅、数据查询以及数据分发三种数据支持子服务。其中无论是数据订阅[15]、查询还是分发，数据引擎与各类指挥显示软件均采用统一的接口以及统一的数据标识定义。数据标识定义在单一的域中唯一，其中域可使用发射场、任务ID等进行定义。

(3)其他同域数据引擎：引擎间通信主要实现指挥显示数据的分发、交互以及可能出现单点故障时的数据恢复、热备等，对于不同的数据引擎应用模式(详见第3节)，引擎间通信内容略有区别。

(4)存储系统：数据引擎将内外部接收处理的数据进行存储管理，并为指挥显示软件提供数据查询服务。

(5)管理维护及控制接口：数据引擎配置管理维护与控制接口，以实现整个试验任务信息系统的统一监控管理。

3 数据引擎应用模式

航天试验任务指挥显示数据引擎需要综合考虑现有发射场业务系统建设情况以及当前软硬件环境，指显数据引擎能够支持集中式、分布式（及单点式）以及混合式三种试验任务指挥显示数据接入模式。其中混合式应用模式仅需现有环境做部分资源调整即可实现，同时也是更好支持发射场测发指挥监控系统向落实“一体化”迈进的一种应用模式。

3.1 集中式应用模式

数据引擎集中式应用模式的主要特点体现在外部显示相关的数据在集中的机器上完成数据汇集、处理、存储、分发等工作，而用户显示终端主要为系统使用人员提供多元的数据显示并提供各类人机交互的接口，集中式应用模式如图3(a)所示。

在集中式应用模式下，一般采用一组互为热备的高性能服务器作为数据引擎的承载机器。通过这种方式，可以减轻用户显示终端的处理压力，并可以有效保障内外部系统的解耦，方便保障系统各类数据的一致性。但另一方面，集中式应用模式在扩展性支持方面较弱，同时对集中式节点的数据依赖较高。

3.2 分布式/单点式应用模式

数据引擎分布式/单点式应用模式的主要特点体现在外部显示相关的数据直接在各用户显示终端上完成数据汇集、处理、存储等工作，显示终端同时为系统使用人员提供多元的数据显示并提供各类人机交互的接口，分布式/单点式应用模式如图3(b)所示。

在分布式应用模式下，各显示终端均配置完整的数据引擎，在单节点出现故障时不会影响其他终端用户使用。分布式应用架构对用户显示终端计算性能有一定的要求，在数据存储上存在一定的冗余，同时由于缺乏集中的分发处理，数据一致性以及内部数据差异化分发较弱。

3.3 混合式应用模式

数据引擎混合式应用模式的主要特点体现在外部显示相关的数据可以差异化地在各用户显示终端上完成数据汇集、处理、存储等工作，同时在集中的节点上实现试验任务的全量数据管理，显示终端可以直接为系统使用人员提供多元的数据显示并提供各类人机交互的接口，也可依赖于集中节点完成全量数据的查询。混合式应用模式如图3(c)所示。

图3 数据引擎应用模式

混合式应用模式下，在集中节点部署完整配置的数据引擎，而在各指显终端，可以通过组件的灵活组合配置及不同需求，部署差异化配置的数据引擎。在正常运行情况下，指显终端可以快速地从本地获取所需数据，同时由于差异化的部署可以在一定程度上降低对指显终端的计算性能需求，而在终端异常或需要额外的数据时，可向集中节点部署的数据引擎请求相关数据。除满足基本试验任务指显数据需求保障的情况下，在数据一致性、扩展性方面均存在一定的优势。

4 结论

通用指挥显示数据引擎将发射场指挥显示数据接入、存储、转发等功能转变为具有一定功能、可替代的服务构件，在统一标准、统一服务、统一接口的基础上，以“搭积木”的方式灵活构建出目前和未来所需的数据治理平台。

该架构有效解决了各发射场内外部协议不统一、数据接入难以及数据应用扩展性差的问题。目前，该通用指挥显示数据引擎架构已成功应用于某指挥显示系统，对我国航天发射场的信息“一体化”发展具有重要的应用价值。