一种跨操作系统的中心化发布订阅通信中间件

文档序号:31732989发布日期:2022-10-05 02:31阅读:46来源:国知局
一种跨操作系统的中心化发布订阅通信中间件

1.本发明涉及软件化雷达以及中间件技术领域,具体涉及跨操作系统的中心化发布订阅通信中间件技术。


背景技术:

2.为满足信息化作战系统快速适应复杂作战环境、灵活应对多样目标对象、动态重构新功能等需求,软件化雷达系统应运而生。针对传统的雷达设备通信实时性差、系统扩展不够灵活,数据传输可靠性不足等问题,为提高系统互联能力,实现系统内各种信息交换和共享,并解决应用软件之间的数据通信等问题,软件化雷达通信环境技术的研究具有重要意义。
3.通信中间件屏蔽了分布式系统中各组成部分之间软硬件环境的差异,能提供统一标准的通信接口,将所有的异构平台互联并实现信息交互,是装备系统开放式架构的关键组成部分。其中,发布订阅模型是通信中间件中的一种基本模型,适用于分布式系统的消息传递,将客户端与服务器转变为发布者与订阅者。发布订阅节点之间通过匿名通信的主题信息发布和订阅数据,只关心所需发布和订阅的数据,耦合性低,增强了通信的灵活性和实时性。当前成熟的通信中间件技术包括数据分发服务dds(data distribution service)、通用对象请求代理体系结构corba(common object request broker architecture)等。dds作为一种发布订阅模型下的通信中间件,支持高码率、高可靠的通信方式,具备多种qos策略,广泛应用于国防、航空、工业自动化、机器人等多个领域;针对当前软件化雷达以及其他军用设备跨操作系统和处理器平台的通信需求,dds技术是一种可选的通信方案,但其本身对于面向服务的系统不适用,对于某些特殊场景或业务下的通信需求不能很好地满足,需要根据不同需求对dds模型进行扩展。
4.公开号为cn110704070a的发明专利提出了一种区分实时操作系统下dds通信中间件的构建方法,该方法主要是利用vxworks653-linux gnu工具编译适配dds链接库,并在相应的wind river平台进行开发,在vxworks系统下通过配置dds支持环境来完成通信中间件的构建。该方法仅适用于实时操作系统vxworks,并且利用了rti-dds产品和各种配置工具和环境,局限性较高,不适合不同操作系统环境下的节点间通信。
5.公开号为cn111400228a的发明专利提出了一种dds通信中间件集成rapidio传输的方法及系统,基于dds-rtps协议实现rapidio的描述模型。该方法将dds-rtps协议所支持的udp与rapidio相结合,实现了在dds通信中间件中基于rapidio和udp协议的数据传输。该方法中的dds通信中间件基于rtps协议,验证了在rapidio以及udp协议下能够提升通信效率,但该通信中间件系统的配置和实现过程繁琐,且不能保证对于其他传输协议能够有良好的支持,可能存在系统适配性不足的问题。


技术实现要素:

6.本发明所要解决的技术问题是,为克服分布式异构系统的应用节点之间通信效率
低、灵活性、扩展性不足等缺陷,提供一种跨操作系统的中心化发布订阅通信中间件模型,利用该模型能够实现具有实时性、可扩展性以及跨操作系统性的通信中间件。
7.本发明为解决上述技术问题所采用的技术方案是,一种跨操作系统的中心化发布订阅通信中间件,从上层到下层分别包括发布订阅层、通信链路层和操作系统适配层;
8.发布订阅层用于与上层应用组件交互,依据dds规范为上层应用组件提供用户接口;
9.通信链路层用于对链路协议进行标准封装并选择最优的链路协议进行数据传输,为发布订阅层提供协议接口;
10.操作系统适配层位于操作系统之上,利用posix标准接口统一各操作系统调用,利用boost asio库统一各操作系统的输入输出机制以及网络服务接口,结合跨操作系统的宏定义映射至各操作系统;
11.发布订阅层的接口包括:发布订阅初始化接口、发布订阅连接建立接口和发布订阅数据收发接口;
12.发布订阅初始化接口用于初始化通信上下文,建立以数据为中心的发布订阅模型dcps(data-centric publish-subscribe);
13.发布订阅连接建立接口用于维护中心化管理节点,并通过该中心化管理节点全局管控每个通信节点的主题发布和订阅,实现主题匹配并建立连接;所述中心化管理节点存储有系统拓扑结构、主题信息和每个通信节点的通信状态;
14.发布订阅数据收发接口是上层应用组件读取和写入数据的用户接口,在主题匹配完成后实现数据收发。
15.针对分布式节点之间通信需要寻址的问题,本发明利用发布订阅模型中基于主题的匿名通信方式,发布者和订阅者无需知道对方的地址信息,只要通过主题知晓所传输何种数据就能通过发布订阅模型完成通信,降低了节点之间耦合性;
16.通过发布订阅连接建立接口中的中心化管理节点实现对不同通信节点信息的管控,完成主题的匹配和通信连接,增强了通信可扩展性和灵活性;
17.针对分布式通信节点可能所处的异构系统环境以及跨操作系统的需求,本发明通过posix和boost asio对不同系统相关的函数接口进行封装统一,实现了跨操作系统通信,增强了通信中间件模型的可移植性;
18.本发明基于发布订阅模型和数据分发服务规范构建了一种跨操作系统的中心化发布订阅通信中间件模型,该模型支持数据在分布式节点间的高效、实时传输,降低了各功能模块之间以及通信节点之间的耦合性;用户可以根据不同的应用场景,灵活选择或扩展不同的数据传输协议;屏蔽了底层操作系统的多样性,实现了通信中间件模型代码在不同系统平台上的复用和可移植性,简化了开发难度,便于系统其他功能的更新和扩展。
19.本发明的有益效果包括:
20.通过构建发布订阅层,利用中心化管理节点对不同通信节点的状态信息的监测、主题信息的发现和匹配,使得节点之间自动建立通信连接,支持在任意时刻节点的动态加入或离开,降低节点之间的耦合性,实现了数据的实时传输和多样化方式传输。
21.通过构建通信链路层,封装不同的链路协议,用户可结合不同的应用场景调用底层不同的通信协议,实现了对传输协议的自适应扩展,增强了数据传输的灵活性。
22.通过构建操作系统适配层,实现对不同操作系统的适配和兼容,提高了通信中间件模型的可移植性,解决不同操作系统之间难以实现有效通信的问题。只需调用相应的系统接口就能对应到不同的操作系统,从而无需根据不同操作系统修改代码便能实现在不同系统节点间的数据通信。
附图说明
23.图1为本发明的整体模型示意图;
24.图2为本发明的具体模块示意图;
25.图3为基于主题的中心化发布订阅模型示意图;
26.图4为基于主题的中心化发布订阅实现流程图;
27.图5为操作系统适配层的封装设计示意图;
28.图6为跨操作系统通信实施例。
具体实施方式
29.下面结合附图和实施例对本发明作进一步的说明。
30.本发明实施例分别基于linux的ubuntu 18.04平台和基于vxworks的飞思卡尔lys-imx6q处理板,实现两者节点间的数据通信。本发明所述模型利用c/c++语言进行编程实现,并通过相应系统下的编译环境或手段完成编译。
31.这里的节点包括应用节点、通信节点、中心化管理节点等指的可以是单个应用程序或进程、单个应用组件、单个载有某操作系统的处理器或处理板。
32.图1为本发明所述的一种跨操作系统的中心化发布订阅通信中间件整体模型示意图。整体模型图包括:应用组件层、通信中间件层和操作系统层。通信中间件层位于应用组件层和操作系统层之间,是本发明的核心。通信中间件层从上往下包括:发布订阅层、通信链路层和操作系统适配层。
33.图2为本发明所述的一种跨操作系统的中心化发布订阅通信中间件具体模型示意图,在图1通信中间件层的基础上进行具体化。发布订阅层位于所述通信中间件模型的最上层,与上层应用组件交互。该层依据dds规范为用户提供一套通用的接口调用,实现整个系统中心化的发布订阅过程。发布订阅层按照接口可分为:发布订阅初始化接口、发布订阅连接建立接口和发布订阅数据收发接口;发布订阅初始化接口用于初始化通信上下文,建立dcps实体模型;发布订阅连接建立接口维护一个包含系统拓扑结构、主题信息和通信状态的中心化管理节点,通过该节点全局管控每个通信节点的主题发布和订阅,通过对dcps实体的操作完成基于主题的发现和匹配,建立发布订阅连接;发布订阅数据收发接口是用户调用的读取和写入数据的接口,通过传输协议在主题匹配完成后实现数据的收发。
34.发布订阅层的主要接口函数设计如表1所示,通过c++语言进行面向对象编程,每个dcps实体作为c++中的类来实现。接口函数名称中的表述方式为:
35.返回值类名::函数名(函数参数);
36.其中,returncode_t为dds规范中对应各种错误异常的返回值。
37.表1发布订阅层的接口设计
[0038][0039][0040]
图3为基于主题的中心化发布订阅模型示意图,是图2所示发布订阅层实现的基础。发布订阅模型通常分为中心式和分布式,中心式模型具有一个中心管理节点,该节点收集其他通信节点的主题信息,各通信节点需要向中心管理节点请求主题对应的通信另一方
的信息,再在中心节点完成路由匹配和通信连接。路由是指通过主题定位发现各个参与通信的节点,匹配是指通过主题来进行发布订阅方的两两匹配。同时,中心管理节点实现对系统各个通信节点的状态监测和管理。
[0041]
在图3的基础上,实现如图4所示的中心化发布订阅模型实现流程图。包括以下步骤:
[0042]
步骤1、发布方和订阅方各自依据表1所示的发布订阅初始化接口完成对dcps实体的创建和通信环境的初始化,并向中心化管理节点发送状态数据包;
[0043]
步骤2、中心化管理节点开启监听线程,通过select多路io监听各通信节点的通信状态,通过对状态数据包的解析,将表征节点状态的属性存入状态监测表;
[0044]
步骤3、发布方和订阅方在通信状态正常的前提下,将自身需要发布或订阅的主题信息通过udp传播给中心化管理节点,完成对主题信息的注册;
[0045]
步骤4、中心化管理节点接收每个节点的主题相关信息并解析为相应的数据结构,通过创建发布主题表和订阅主题表,来保存各通信节点的主题信息。同时,维护更新一个全局主题信息结构,用来保存系统中所有主题的发布订阅信息;
[0046]
步骤5、中心化管理节点通过发布和订阅主题表对当前加入的节点主题信息进行查询,利用key值为主题名的键值对数据结构进行复杂度为o(logn)的查询;
[0047]
步骤6、中心化管理节点将查找到的同一主题名的发布方和订阅方完成主题匹配,将数据传输所需的信息反馈给匹配成功的发布方和订阅方,建立通信连接。
[0048]
对图4中心化发布订阅模型实现流程图中的设计流程和数据结构作如下进一步说明:
[0049]
中心化管理节点的状态监测:中心化管理节点对于系统中通信节点的监听采用select多路io机制,同时基于tcp/ip协议传输状态数据包,保证了监测过程的稳定和高效。状态数据包为一个结构体,其中包含节点实时的端口号、连接状况、是否存在故障等通信状态属性,可自定义扩展。
[0050]
状态监测表:在中心化节点监测过程中,当有节点加入系统中时,监听线程接收到此节点的状态数据包便立刻反馈给该节点一个唯一的端口号;状态监测表根据状态数据包来保存所有节点的状态属性,采用的键值对数据结构的形式进行存储,其中key值对应的是端口号,value值对应的是通信状态属性。
[0051]
中心化节点的主题发现和匹配:发布方和订阅方将获取到的自身主题信息,通过udp协议传输给中心化管理节点,在中心化管理节点处解析主题信息结构,完成主题注册,并按照发布/订阅主题表和全局主题信息结构表的内容进行保存。匹配过程根据关联容器multimap底层红黑树的实现,构造用于查询和匹配的multimap,查询、插入和删除操作所耗费的时间复杂度均为o(logn)。
[0052]
注册的主题信息结构如下:
[0053][0054]
发布/订阅主题表如下:
[0055][0056]
用于查询和匹配的multimap容器:
[0057]
multimap《string,topic_context》//[key主题名,value主题表内容]
[0058]
全局主题信息结构:
[0059][0060][0061]
如图2所示,通信链路层实现了对现有的通信链路协议tcp、udp、共享内存等进行了统一封装,屏蔽了底层不同协议的通信细节。以udp协议为例说明通信链路层对协议实现
封装的过程,包括以下步骤:
[0062]
步骤1、创建通信链路类,将需要封装的协议作为该类的成员函数。
[0063][0064]
步骤2、将每个协议对应的成员函数与原始协议进行映射,如udp协议是基于socket的sendto()和recvfrom()等接口实现,在相应的成员函数中调用该接口来完成底层的数据传输;
[0065]
步骤3、在数据收发接口中传入协议选择参数trans_type,如udp协议则传入字符’u’。采用switch(trans_type)语句,调用通信链路类commlinktype中的子线程协议;
[0066]
在实际数据传输时,用户可根据不同的应用环境,通过通信链路层来实现对不同链路协议的选择,降低了上层应用与底层通信细节之间的耦合度。
[0067]
图5为操作系统适配层的封装设计示意图,是图2所示的操作系统适配层的具体实现。操作系统适配层主要实对不同操作系统进行适配和兼容。通过posix对系统调用进行封装,通过boost asio库对网络通信相关的io机制进行统一。具体包括:
[0068]
利用posix标准支持的系统调用,解决不同操作系统下基本系统调用的适配,包括:统一的线程控制pthread接口、统一的进程调度接口、统一文件读写接口和时钟、定时器设置等。用户使用posix标准下的系统调用能直接在不同的系统平台上进行编程;
[0069]
利用boost asio对网络通信服务接口进行抽象,不同操作系统下提供的io分发机制不同,boost asio能通过io_service这个类提供统一的io分发机制接口,该接口就是对上提供的统一封装。如图5所示,由于boost asio与windows系统下输入输出完成端口iocp模式相似,因此可先通过io_service接口分为在windows和非windows系统下的io分发机制实现。进一步,通过task_io_service类对非windows系统的其他操作系统的io分发服务进行封装,当调用task_io_service接口时,通过xxx_reactor定义不同的io分发机制,如:select模式、epoll模式、kequeue模式等。在接口内部采用对应系统提供的io分发机制完成io事件;
[0070]
利用跨操作系统机制的头文件设置,使用宏定义的方式来设计,用户在不同的操作系统上开发时选择相应的宏定义即可,它们都被包含到了共同的头文件当中。这样,用户可以在不同的操作系统上,利用共同的系统调用函数、映射到相应系统内部的网络通信接口和io分发服务机制,实现一系列的通信操作。
[0071]
图6为一个跨操作系统通信的实施例,基于本发明所述的通信中间件模型对通信中间件进行设计,将其分别运行在linux和vxworks系统,以linux系统所在的ubuntu节点为发布方,vxworks系统所在的lys-imx6q处理板节点为订阅方,基于以太网下的udp协议进行数据传输。图6中深色部分(左侧)为linux系统的发布方所发送数据的通信时延,浅色部分(右侧)为vxworks系统的订阅方所接收到的具体字节数据,实现数据在不同操作系统节点之间的实时传输。
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1