本发明是一种主要用于航天测运控中心和地面站监控系统的持续可扩展的对异构设备和子系统的接入及其监控数据处理的解决方案。
背景技术：
随着航天科技发展的速度越来越快，航天地面站设备的升级、变动越来越多，监控数据类型越来越多样化，航天中心通过管理众多的地面站来执行越来越多的各种航天任务。地面测控站数量多、分布广、站网资源建设时间和建设主体不同，各个站网资源的链路配置、生产厂商、设备单机型号、生产年份不同，软硬件和数据接口未遵循统一标准，设计的通讯协议、帧定义不一致。当航天地面站有设备更新或新增时，现有地面站监控系统需要等待任务空闲期修改配置并重启相应的监控服务端程序，很多时候还需要升级程序才能支持新设备。为此航天地面站需要一种解决方案，实现设备资源的动态接入管理，并能兼容各类异构设备的监控数据格式，提高业务的实时性和安全性。航天中心需要提供针对上百个航天器的任务管理，包含了高、中、低轨航天器任务和深空任务，任务密集，同一时间有多个设备执行任务。现有系统未能对站网资源进行集中监控，目前主要从站网的角度查看任务，没有从航天器的角度监视任务执行。采用的是一套站网资源或一个地面站使用一个客户端的监控方式，客户端由各自的设备总承方提供，界面设计各不相同，且管理分散，不易集中。由于任务配置参数异构，当增加一个航天器任务时，无法快速地分析可支持新任务的设备，无法快速地生成各个站网资源的任务配置参数。为此航天中心需要一种解决方案，实现资源的统一调度，兼容各类异构资源的数据格式，满足数据流转和融合处理需求，提高业务的实时性和安全性，满足不断发生变动的地面测控站，以及不断增加的航天任务的需求。
现有航天中心系统控制中心提供远程监视和远程控制接口,整个监控系统由站内所有被控设备、串口服务器、主机服务器、操作机和网络交换机组成。控制中心内部配有大型监控与数据服务器,通过数据通信网接收各测控站的站监控、测距、测角、在轨测试等数据,实时监控并存储。在远程工作站上,控制中心用远程监控软件通过该站的监控系统直接远程监视与控制该站的各个设备。虽然可对监控设备进行远程控制，但仍然存在如下不足之处：
航天中心系统采用测控网络对站网资源的监控方式，服务端采用的是一套站网资源或一个地面站使用一个客户端在软件各个结构层之间进行远程对象访问的监控方式。调用对象被称为客户端,而被调用对象则被称为服务器或者服务器对象。简而言之,它就是.net平台上实现分布式对象系统的框架。虽然是远程的,但未能实现远程集中监控需求，不能适应跨平台的应用。由于站网资源建设时间和建设主体不同，各个站网资源的链路配置、生产厂商、设备单机型号、生产年份不同，而且设备、仪表的数量大,分布在全站各个角落。软硬件和数据接口未遵循统一标准，设计的通讯协议、帧定义不一致；串口传输数据存在传输距离短、连线多；任务配置参数异构。当增加一个航天器任务时，无法快速地分析可支持新任务的设备，无法快速地生成各个站网资源的任务配置参数。
技术实现要素：
本发明的目的是针对上述现有技术的不足之处，提供一种能够改善参数异构，能快速响应地面设备变化，适应性更强，应用范围更广的航天测运控异构资源监控数据处理方案。
本发明的上述目的可以通过下述技术方案予以实现：一种航天测运控异构资源监控数据处理方法，具有如下技术特征：首先，根据设备或子系统的监控接口协议建立描述一个节点所管理的每一类设备的通信接口协议的json格式数据帧结构模型，每个数据帧结构模型由描述模型的json文件以及扩展解析打包算法的jar包组成，它们按规定目录结构存放在ftp服务器上，其次，在分布式平台的配置中心对实体设备按分片方式管理，一个分片对应一组实体设备，每个分片对应一个配置信息文件，配置信息将实体设备的通信配置和数据帧结构模型id信息关联起来；然后，配置中心触发服务节点更新设备信息，建立与实体设备的通信服务，配置中心触发服务节点更新设备信息和建立与实体设备的通信，根据设备数据帧模型信息实现通信数据帧和设备参数的相互转换；当配置中心上实体设备的配置信息发生变动，服务节点根据变动的配置信息执行相应实体设备连接的上下线和数据帧结构模型更新操作，完成更新后的微服务节点将继续对各实体设备数据进行正确处理；解析设备数据帧后，将设备上报的状态参数存放在key-value数据库redis中供实时查询，将设备控制回令等非状态信息通过消息队列发送给观察者服务处理。
本发明相比于现有技术具有如下有益效果：
本发明根据设备或子系统的监控接口协议建立json格式数据帧结构模型，描述每一类设备的监控参数和可以引用jar包对解析打包算法进行扩展的接口通信协议，对所有站网资源信息进行统一的建模，采用完全独立于编程语言的文本格式来存储和表示数据。简洁并且层次清晰的json格式易于人阅读和编写，同时也易于机器解析和生成，并有效地提升网络传输效率。数据帧结构模型描述信息可配合jar包进行扩展，适应性更强，应用范围更广。
本发明对数据帧结构进行了统一建模，后续业务处理面对的是统一建模的参数，使得参数异构的问题得到极大改善。能对不同时期、不同类型、不同厂商研制的多套航天测运控设备进行监控和管理，本发明将数据帧结构模型和实体设备配置信息分开管理，充分利用分布式平台的配置中心的变动通知功能，在分布式平台的配置中心对实体设备按分片方式管理，一个分片对应一组实体设备，每个分片对应一个配置信息文件，配置信息将实体设备的通信配置和数据帧结构模型id等信息关联起来；当设备发生变动时，只需更新模型再修改实体设备配置信息，即可适应设备变化。
本发明利用配置中心触发服务节点更新设备信息，建立与实体设备的通信服务，根据设备数据帧模型信息实现通信数据帧和设备参数的相互转换；能在服务端不停机、不修改代码的情况下快速响应设备变化，实现系统重构。不仅仅是新增设备，还能关闭老设备，升级老设备。从设计上满足了航天测运控系统对设备变更的要求。
本发明基于微服务的设计思想，将设备上报的状态参数存放在key-value数据库redis中供实时查询，将设备控制回令等非状态信息通过消息队列发送给观察者服务处理；充分利用redis和消息队列的特性，将实时状态查询和写数据库等调用频率高或执行时间长的功能从设备数据处理服务中剥离了出来由其他微服务完成，再通过合理的服务节点部署，不仅可以更容易分摊节点压力，还可以轻松实现服务节点高可用的需求。
本发明基于分布式环境，可以直接应用到各类航天地面测控站、航天运管中心及航天遥感接收站。
附图说明
图1是本发明航天测运控异构资源监控数据处理方案的整体结构图。
图2是本发明航天测运控异构资源监控数据处理方案的流程图。
图3是图1中数据帧模型描述的目录层次结构示意图。
图4是图1中数据帧模型所描述的一个数据帧协议格式的基本结构示意图。
图5是图1中设备数据处理服务的初始化流程图。
图6是图1中设备数据处理服务的接收解析流程。
图7是图1中设备数据处理服务的打包发送流程。
具体实施方式
参阅图1。根据本发明，首先，根据设备或子系统的监控接口协议建立描述一个节点所管理的每一类设备的通信接口协议的json格式数据帧结构模型，每个数据帧结构模型由描述模型的json文件以及扩展解析打包算法的jar包组成，它们按规定目录结构存放在ftp服务器上，其次，在分布式平台的配置中心对实体设备按分片方式管理，一个分片对应一组实体设备，每个分片对应一个配置信息文件，配置信息将实体设备的通信配置和数据帧结构模型id信息关联起来；然后，配置中心触发服务节点更新设备信息，建立与实体设备的通信服务，配置中心触发服务节点更新设备信息和建立与实体设备的通信，根据设备数据帧模型信息实现通信数据帧和设备参数的相互转换；当配置中心上实体设备的配置信息发生变动，服务节点根据变动的配置信息执行相应实体设备连接的上下线和数据帧结构模型更新操作，完成更新后的微服务节点将继续对各实体设备数据进行正确处理；解析设备数据帧后，将设备上报的状态参数存放在key-value数据库redis中供实时查询，将设备控制回令等非状态信息通过消息队列发送给观察者服务处理。
本发明的解决方案采用微服务方式设计，包含三个核心服务：数据帧结构模型管理服务、设备数据处理服务、设备实时状态查询服务。
在数据帧结构模型管理服务中，每个数据帧结构模型都对应一个目录，存放在ftp服务器上，数据帧模型目录下有数据帧模型描述文件以及配套的扩展jar包；数据帧模型管理服务从ftp服务器获取数据帧模型描述文件后为设备数据处理服务提供数据帧模型信息；在设备数据处理服务中，根据数据帧结构模型信息，从ftp服务器获取相应的扩展jar包，用于数据帧打包解包；
在设备数据处理服务中，配置中心对实体设备按分片方式管理，一个分片对应一组实体设备，每个分片对应一个配置信息文件，配置信息将实体设备的通信配置和数据帧结构模型id等信息关联起来。设备数据处理服务节点根据配置中心上实体设备通信配置信息建立与实体设备和子系统的通信服务，根据设备数据帧模型信息实现通信数据帧和设备参数的相互转换；解析设备数据帧后，将设备上报的状态参数存放在redis中供实时查询，将设备控制回令等非状态信息通过消息队列发送给观察者服务处理。当配置中心上实体设备的配置信息发生变动，服务节点会根据变动的配置信息执行相应实体设备连接的上下线和数据帧结构模型更新操作。
在设备实时状态查询服务中，根据设备状态参数的key值命名规则直接读取redis中的设备实时状态返回给服务接口调用者。
参阅图2。本发明是基于统一数据模型工作的方案，首先编辑数据帧模型对数据帧进行建模，配置设备信息将实体设备的通信配置和数据帧结构模型id等信息关联起来，之后服务初始化，设备上线收发数据帧和解析打包数据帧；当设备发生变动时，管理员编辑数据帧结构模型，配置设备信息，服务判断数据帧结构模型或设备配置信息是否变更，是则关闭下线设备，重新服务初始化设备上线，否则继续对设备数据进行解析打包。在数据帧解析服务中，读取数据帧结构模型信息，配合jar包对数据帧打包解包算法进行扩展，对数据帧和控制命令进行解析打包。当配置中心上的配置信息发生变更，则触发配置变动的设备下线，读取新的配置信息进行服务初始化。
参阅图3。每个数据帧结构模型对应一个目录，数据帧结构模型目录结构下包括数据帧结构模型json文件和多个按解析位置划分的打包解包扩展jar文件，第一级目录分为全帧结构frame和数据域datafields，全帧结构frame目录下包含jar残帧处理文件和全帧结构扩展jar文件，数据域datafields目录下包含一个数据域扩展jar文件和1…n个设备类型devtype子目录，每个设备类型devtype子目录含有1…n个命令帧扩展jar文件。数据帧结构模型json文件对用于描述帧格式的数据元素、枚举定义、数据帧字段进行了详细的描述，帧格式的描述是基于每个数据帧由多个字段拼接而成，每个字段根据其不同类型有不同的定义和描述方式，字段中通过引用数据元素和枚举定义进一步详细说明。数据帧结构模型配合打包解包扩展jar文件能更灵活的适应各种数据帧结构。全帧结构frame是整个数据帧结构，其中将数据域视为一个整体，不做细节描述，在数据域datafield中才具体描述数据域的数据。
参阅图4。此图描述的是数据帧结构模型能够描述的一个通信端口中帧协议格式基本结构。通常情况下一个帧是由帧头、数据域和帧尾组成的。帧头中的数据类型决定了数据域的类型，数据长度决定了数据域的长度，因此二者是不能缺少的(用*号标注)。数据域按类型分为命令请求、控制响应、控制回令，以及其他自定义类型，其中的命令码是用于确定具体命令帧的字段(不可缺少，除非一种数据域类型只对应一种命令帧格式)。
参阅图5。在设备数据处理服务的初始化流程中，设备数据处理服务从配置中心读取配置信息，解析出所管理的全部设备信息、数据帧结构模型id、设备类型和通讯配置，然后从数据帧结构模型管理服务获取相应的数据帧结构模型信息，仅下载数据帧结构模型对应ftp目录中的扩展jar包，初始化数据域扩展jar包的实例，创建通讯端口和接收线程池。
参阅图6。在设备数据处理服务的接收解析流程中，每个通信端口对应一个独立的完整帧缓冲区。服务收到数据帧后，先通过消息队列(mq)发送数据帧源码，然后判断是否有残帧处理扩展，有则进行残帧处理提取完整数据帧，无则说明收到的数据帧已是完整数据帧，之后按通讯端口缓存完整数据帧后通知处理线程；在数据帧处理线程中，从缓存区取一帧数据，解析外帧头，解析数据域，得到key-value方式的解析结果。此过程中要保证每个通信端口上的数据的处理是有序的、串行的。
参阅图7。在设备数据处理服务的包发送中，查看对应通信端口是否有最低发送间隔要求，如果有则获取通信端口的分布式锁，该锁的超时时间为最低发送间隔时间，服务通过判断是否成功获取锁来确保发送最低间隔时间，获取成功后，先将命令参数打包成数据域字符数组，再添加外帧头，形成完整数据帧，通过通信管理模块发送数据帧，否则短暂时延后重试，可以中途放弃重试，结束程序。
主节点选举机制：设备数据处理服务根据高可靠要求部署多个服务节点管理同一组设备时，这些节点都能收到设备发出的数据帧，但是只有主节点可以通过消息队列mq向外发出消息和将设备状态写入redis数据库，主节点只有一个，确定主节点的方法是通过将redis的一个键值对作为超时锁，抢先得到这个锁的节点成为主节点。假设我们认为当主节点失去响应3秒后立即重新选择主节点，则设置用于竞争的键值对的锁的超时时间为3秒，key就是监控服务的服务名，value是当前拥有锁的节点的ip。拥有该锁的节点成为主节点，只有它能通过mq向外消息，如果主节点当机，或者负载太重，3秒之内没有再次获取锁，则锁自动释放，触发全部仍然存活的节点来抢这把锁，抢到的成为主节点。
节点部署方案：当设备数量很多，为了均衡分配资源能力，预先手动对设备进行分组，每组设备称为一个设备分片，由不同的节点集群管理不同的设备分片。每个集群对应一个设备分片的配置文件，放置在配置中心，如果配置文件发生变动，整个集群上的设备数据处理服务节点都会触发更新配置的动作。
设备实时状态查询服务：响应对设备状态的查询请求，通过直接读取redis中的最新设备状态信息快速返回结果。
显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
1.一种航天测运控异构资源监控数据处理方法，具有如下技术特征：首先，根据设备或子系统的监控接口协议建立描述一个节点所管理的每一类设备的通信接口协议的json格式数据帧结构模型，每个数据帧结构模型由描述模型的json文件以及扩展解析打包算法的jar包组成，并且按规定目录结构存放在ftp服务器上，其次，在分布式平台的配置中心对实体设备按分片方式管理，一个分片对应一组实体设备，每个分片对应一个配置信息文件，配置信息将实体设备的通信配置和数据帧结构模型id信息关联起来；然后，配置中心触发服务节点更新设备信息，建立与实体设备的通信服务，配置中心触发服务节点更新设备信息和建立与实体设备的通信，根据设备数据帧模型信息实现通信数据帧和设备参数的相互转换；当配置中心上实体设备的配置信息发生变动，服务节点根据变动的配置信息执行相应实体设备连接的上下线和数据帧结构模型更新操作，完成更新后的微服务节点将继续对各实体设备数据进行正确处理；解析设备数据帧后，将设备上报的状态参数存放在key-value数据库redis中供实时查询，将设备控制、控制响应和回令信息通过消息队列发送给观察者服务处理。
2.如权利要求1所述的航天测运控异构资源监控数据处理方法，其特征在于：基于统一数据模型工作的方案，首先编辑数据帧模型对数据帧进行建模，将实体设备的通信配置和数据帧结构模型id信息关联起来配置设备信息，之后服务初始化，设备上线收发数据帧和解析打包数据帧；当设备发生变动，修改数据帧结构模型和设备配置信息；服务运行过程中会判断数据帧结构模型或设备配置信息是否变更，是则关闭下线设备，重新服务初始化设备上线，否则根据数据帧模型信息持续对设备数据进行解析打包，其中部分打包解包算法由模型信息指定jar包进行扩展。
3.如权利要求1所述的航天测运控异构资源监控数据处理方法，其特征在于：当配置中心上的配置信息发生变更，则触发配置变动的设备下线停止收发数据帧，读取新的配置信息进行服务初始化。
4.如权利要求1所述的航天测运控异构资源监控数据处理方法，其特征在于：数据帧结构模型目录结构下包括：数据帧结构模型json文件和多个按解析位置划分的打包解包扩展jar文件，第一级目录分为全帧结构frame和数据域datafields，全帧结构frame目录下包含jar残帧处理文件和全帧结构扩展jar文件，数据域datafields目录下包含一个数据域扩展jar文件和1…n个设备类型devtype子目录，每个设备类型devtype子目录含有1…n个命令帧扩展jar文件。
5.如权利要求1所述的航天测运控异构资源监控数据处理方法，其特征在于：数据帧结构模型json文件为了描述数据帧结构，先是分别对数据元素、枚举定义、数据帧字段进行了描述之后，对帧格式的描述是基于每个数据帧由多个字段拼接而成，每个字段根据其不同类型有不同的定义和描述方式，其中部分字段引用了数据元素的定义和枚举定义。
6.如权利要求1所述的航天测运控异构资源监控数据处理方法，其特征在于：设备数据处理服务从配置中心读取配置信息，解析出所管理的全部设备信息、数据帧结构模型id、设备类型和通讯配置，然后从数据帧结构模型管理服务获取相应的数据帧结构模型信息，从ftp下载数据帧结构模型对应的jar包目录，初始化数据域扩展jar包的实例，创建通讯端口和接收线程池。
7.如权利要求1所述的航天测运控异构资源监控数据处理方法，其特征在于：每个通信端口对应一个独立的完整帧缓冲区，服务收到数据帧后，先通过消息队列(mq)发送数据帧源码，然后判断是否有残帧处理扩展，有则进行残帧处理提取完整数据帧，无则说明收到的数据帧已是完整数据帧，之后按通讯端口缓存完整数据帧后通知处理线程。
8.如权利要求1所述的航天测运控异构资源监控数据处理方法，其特征在于：在保证每个通信端口上的数据处理是有序的、串行的前提下，数据帧处理线程每次从缓存区取一帧数据，解析外帧头，解析数据域，得到key-value方式的解析结果。
9.如权利要求1所述的航天测运控异构资源监控数据处理方法，其特征在于：在设备数据处理服务的包发送中，查看对应通信端口是否有最低发送间隔要求，如果有则获取通信端口的分布式锁，该锁的超时时间为最低发送间隔时间，服务通过判断是否成功获取锁来确保发送最低间隔时间，获取成功后，先将命令参数打包成数据域字符数组，再添加外帧头，形成完整数据帧，通过通信管理模块发送数据帧，否则短暂时延后重试，可以中途放弃重试，结束程序。
10.如权利要求1所述的航天测运控异构资源监控数据处理方法，其特征在于：设备数据处理服务根据高可靠要求部署多个服务节点管理同一组设备时，这些服务节点都能收到设备发出的数据帧，只有主节点通过消息队列mq向外发出消息和将设备状态写入redis数据库，确定主节点的方法是通过在redis中创建一个带超时属性的键值对作为超时锁，抢先得到这个锁的节点成为主节点。
技术总结