基于ZeroMQ消息通讯的多源空中目标跟踪处理平台设计

张 杰，王丽娜，赵 媛，吕海燕

(海军航空大学航空基础学院，山东烟台 264001)

0 引言

今年来，无论是在军事作战准备还是民航飞行安全中，空中目标监控与跟踪一直是空中情报领域研究的热点，随着科学技术的发展，种类更多、性能更优的各类传感器不断产生，各种面向复杂应用背景的多传感器系统也大量涌现，基于单一源的空中目标跟踪与定位受限于探测范围、探测性能、空间分辨能力等因素，存在诸多不足之处，而基于多源传感器的空中目标跟踪在目标的发现性能、定位精度和识别能力等方面均具有明显改善［1］，同时，多源探测节点的异构性主要表现:监测设备既可以是同类传感器，也可以是异类传感器;既可以是单一的地基平台，还包括在特殊的探测任务背景和作战需求下的不同传感器的组合，如有源雷达、无源雷达、光电、红外、声探测传感器等［2］。

随着空中目标监控数据日益增长，各个源探测节点(传感器)需经过某种网络的组件，传输到多源目标跟踪处理平台，通过对信息的深入挖掘，最大提升信息价值，掌握瞬息万变的战场态势，本文提出了使用ZeroMQ消息库完成多源信息传输，通过平台设计的目标航迹构建、目标航迹裁剪、目标关联融合、融合数据转发等模块，以达到减少冗余、综合互补和捕捉协同信息的目的，完成多源空中监控数据的融合与转发 (存储)，为更高层次的数据处理、目标识别、态势评估以及智能决策等提供可靠数据基础。

1 系统总体设计

多源监测节点、设备或软件普遍存在以下特点［3］:

(1)异构性:监测设备的多样性使得空中监测数据传输方式必须具备跨平台特性;

(2)自治性:多源监测设备都是可以独立完成监测任务的个体，同时可相互之间具有替代性和分时工作等特点;

(3)动态性:监测设备可随时根据任务等需要动态地加入和退出;

针对上述分析，结合ZeroMQ消息通信库具备数据传输共享的实时性和可靠性等特点，同时可降低网络编程的复杂性，且与平台无关、接口实现相对简单、可行等优势，本文提出使用ZeroMQ建立一个高效、可靠、透明、跨平台的数据通信平台，从空中目标监测数据中抽象出核心数据格式，采用一种轻量级的数据交换格式Json完成多源监测设备与平台的数据传输。

图1 多源目标跟踪处理平台设计框架

平台功能模块主要包括:

(1)监测航迹数据发送、接收、转发模块:目标监测源 (设备)动态加入、退出，统一规范传输数据格式，通过ZeroMQ消息发送、接收、融合后转发航迹点数据，支持源监测节点动态接入与退出;

(2)航迹预处理:依据航迹关联计算形成的知识库，接收的航迹信息经过预处理完成航迹信息融合;

(3)航迹构建:按照航迹数据来报源探测节点 (传感器)建立缓存航迹，获取空中目标航迹数据，并依据航迹数据的目标编号进行航迹缓存，并实时更新缓存航迹信息，为后续航迹裁剪与关联操作提供数据来源;

(4)航迹裁剪:为提升航迹关联计算效率，当缓存航迹持续时间较长、航迹点数较多时，实现航迹点的裁剪，当缓存的航迹在长时间未收到新的航迹点，能够判定航迹终结，执行从航迹缓存容器中移除操作

(5)航迹关联:实现同一目标多源航迹的关联，生成不同批号同一目标关联关系对照表，进行关联操作，并将关联计算结果实时反馈至航迹预处理模块，后续航迹信息能够依据关联知识库进行融合。

2 实现关键技术

跟踪处理平台核心功能集成各个异构目标监测节点数据通讯，通过航迹数据信息关联等操作，并将融合后数据转发，实现关键技术主要包括:

2.1 监测目标数据交换

由于多源监测节点的异构性，监测目标数据交换应采用一种完全独立于编程语言的文本格式来存储和表示，Json恰恰是一种轻量级的数据交换格式，简洁和清晰的层次结构且易于对象序列化操作等优势［4］，使得 Json成为理想的数据交换语言。同时JSON易于阅读和编写、机器解析和生成，并有效地提升网络传输效率［5］。

通过分析航迹监测数据，抽象出与航迹关联及后续态势评估密切相关的参数和属性，并生成统一的监测数据交换Json格式，格式定义如表1。

表1 数据交换格式

2.2 多源目标消息通讯

为保障源探测节点与跟踪处理平台通讯的实时性与可靠性，且支持多源节点实时加入与退出，平台采用ZeroMQ消息通信库完成监测数据的通讯。ZeroMQ是一种基于消息队列的多线程网络库，其对套接字类型、连接处理、帧、甚至路由的底层细节进行抽象，提供跨越多种传输协议的套接字。ZeroMQ是网络通信中介于应用层和传输层之间(按照TCP/IP划分)，是一个可并行运行的伸缩层，分散在分布式系统间，相对于MSMQ、ActiveMQ和RabbitMQ等同类中间件在部署时需要专门的一个服务器［6］，ZeroMQ只需要让应用程序引用消息库，即可完成多个进程间进行消息发送，使得部署起来非常简单。

ZeroMQ提供了以下3种基本工作模式:

1)Request－Reply问答模式，特点是要求严格同步，必须请求端首先发起请求，等待回应端应答，并且一个请求必须对应一个回应，从请求端的角度来看是发－收配对，从回应端的角度是收－发对，主要用于远程调用及任务分配等场景。

2)Pub－Sub发布订阅模式，发布端单向分发数据，且不保证是否把全部信息发送给订阅端。如果发布端开始发布信息时，订阅端尚未连接，则这些信息会被直接丢弃，订阅端只负责接收，而不能反馈，且在订阅端消费速度慢于发布端的情况下，会在订阅端堆积数据。

3)Push－Poll推拉模式，当有多个Pull端同时连接到Push端时，则Push端会在内部做一个负载均衡，采用平均分配算法，将所有消息均衡发布到Pull端上;当有多个Push端同时连接到Pull端，称这种结构为公平队列，即可将Pull端理解为一个队列，各个Push端持续不断地向队列发送数据，与发布订阅模型相比，推拉模型在没有消费者的情况下，发布的消息不会被消耗掉 (Push端会阻塞);在消费者能力不够的情况下，能够提供多消费者并行消费解决方案，主要用于多任务并行处理。

图2 ZeroMQ3种基本工作模式

2.3 目标关联融合处理

航迹关联是将代表同一目标的传感器数据与目标航迹进行关联，将传感器数据按照目标进行分类，由于每条航迹都是由航迹点组成，且每个航迹点都包含准确的时间、位置、速度等信息［7］，在诸多已有的目标关联方法中基于位置信息是最基本也是最成熟的关联方法［8］，本文采用欧式距离的最小二乘法二次曲线拟合方法进行航迹关联初步判断，航迹关联判断流程如图3所示。

图3 航迹关联流程

基于欧式距离的最小二乘法二次曲线拟合方法判断航迹关联性的基本思想是:

1)设定航迹点为三元组tp=(t，lon，lat)，分别由位置时间、经度、纬度组成，首先两条航迹t1和t2应存在交叉时间△t(且△t＞阈值T)，选取航迹点较为密集的航迹t1(假定)在△t内的K个航迹点进行最小二乘法二次曲线拟合得到经度和纬度关于时间的二次方程:

2)选取航迹t2的在△t内的K个航迹点，求得一组二维向量集α，将航迹t1和t2的航迹点经度和纬度组成的向量集使用矩阵表示:

3)求解上述二维向量集α和б中相应向量间的欧式距离，使用矩阵表示:

当γ中每项都小于阈值M时，航迹t1和t2确定为同一条航迹。

4)由于监测设备限于探测范围、探测性能、空间分辨能力，从某一监测设备角度而言，可能存在航迹间的断续，多源监测可通过航迹关联关系之间传递，该操作称之为关联聚的构造［9］，例如航迹t1与航迹t2已成功关联，航迹t2与航迹t3已成功关联，则航迹t3与航迹t1存在关联，并通过航迹属性确定主航迹。

3 系统软件设计与实现

当使用ZeroMQ消息库实现跟踪处理平台与各个源监测节点通讯时，考虑到监测点或设备实时接入与退出，且能够保证当监测数据较大时仍然能够及时进行航迹计算处理，平台通讯模块综合了Request－Reply问答模式与Push－Poll推拉模式实现，首先新接入的监测设备应先使用Request－Reply问答模式请求接入平台，待服务端响应后执行接入操作，并开始发送数据 (Push－Poll推拉模式)，同时服务端登记新接入的设备 (节点)编号，数据经融合处理后以Pub－Sub消息订阅模式发布出去，供其他系统或平台订阅。

为了提高数据并发处理能力，通讯模块采用多线程实现Push－Poll推拉模式。

当新的监测设备接入时，创建线程后注册设备编号并发送给注册服务，等待注册服务返回确认消息后可进行目标监测数据发送。

接人设备端线程主要实现代码如下:

ZMQ．Context context=ZMQ．context(1);

//Request－Reply问答模式注册设备编号

Device device=new Device();

device．setDeviceCode("K1");

ZMQ．Socket requester=context．socket(ZMQ．REQ);

requester．connect("tcp://"+ip+":"+port);

requester．send(device．getJson()．getBytes()，0);

图4 平台数据传输设计

byte［］reply=requester．recv(0);

checkReply(reply);//验证注册返回码

requester．close();

//开始连接并Push－Poll推拉模式发送数据

ZMQ．Socket push=context．socket(ZMQ．PUSH);

push．bind("ipc://fjs");

while(Device．isSend){

String senddata=device．getData();

push．send(senddata．getBytes());

}

push．close();

context．term();

跟踪处理平台首先完成接入设备注册操作，同时，持续接收各个接入设备发送的数据并进行融合处理，其中，平台数据接收主要实现代码如下:

ZMQ．Context context=ZMQ．context(1);

ZMQ．Socket pull=context．socket(ZMQ．PULL);

pull．bind("tcp://"+ip+":"+port);

while(true){

String message=new String(pull．recv());

chkDeviceOpt(message);//接入设备校验

fusionOpt(message);//航迹关联操作入口

}

4 实验分析

为了测试平台的数据吞吐量，我们实验中接入10个监测设备与跟踪处理平台进行数据传输与交互，每个检测设备通过发送1 000 000个0.5 kb大小的Json格式数据的消息，并且计算两边发送和接收消息的时间，实验表明:单个发送端数据速度可超过10万/s条数据，接收端满负荷数据处理速度可达到10万/秒条，且当接入设备发送数据速度远大于综合平台数据处理与接收能力时，接收设备端的数据发送Push线程出现阻塞，尽管可增大ZeroMQ数据缓冲区大小，在一定程度上缓解线程阻塞出现频率，但随着更多监测设备的接入，设备发送端线程阻塞出现更加频繁，数据接受延迟会不断增大，针对这个问题，我们通过使用增加通讯模型中的Pull端线程进行并行接收处理，此外ZeroMQ消息库还提供了批量消息接收处理接口，可大大提升数据传输能力。

5 结束语

鉴于目标多源监测设备存在异构性、位置分散，且监测原始数据格式不够统一、数据生成速度各不相同，为了保证各个目标监测节点与跟踪处理平台之间数据高速通信，本文提出了一种基于ZeroMQ消息库的通信模式，综合ZeroMQ消息库3种工作模式，从传输数据中抽取关键信息并采用Json进行数据交换，建立多线程Push－Poll数据推拉模式，支持各源监测点实时接入与退出，大大提高了数据交互处理能力，上述方法在处理数据量大、实时性要求高的数据交互和通讯的应用中具有一定的通用性，此外，本文采用欧式距离的最小二乘法二次曲线拟合方法进行航迹关联操作，此方法在处理航迹连续性较好、航迹间存在时间交叉情况时关联成功率高，该算法实现简单但前提假设过于严苛［10］，且没能将目标航迹点的速度、水平高度、监测设备误差等因素考虑在内，当航迹分叉、交叉航迹点少等情况难以处理，关联操作存在不足。