基于ZeroMQ消息通訊的多源空中目標(biāo)跟蹤處理平臺設(shè)計

張 杰，王麗娜，趙 媛，呂海燕

(海軍航空大學(xué)航空基礎(chǔ)學(xué)院，山東煙臺 264001)

0 引言

今年來，無論是在軍事作戰(zhàn)準(zhǔn)備還是民航飛行安全中，空中目標(biāo)監(jiān)控與跟蹤一直是空中情報領(lǐng)域研究的熱點，隨著科學(xué)技術(shù)的發(fā)展，種類更多、性能更優(yōu)的各類傳感器不斷產(chǎn)生，各種面向復(fù)雜應(yīng)用背景的多傳感器系統(tǒng)也大量涌現(xiàn)，基于單一源的空中目標(biāo)跟蹤與定位受限于探測范圍、探測性能、空間分辨能力等因素，存在諸多不足之處，而基于多源傳感器的空中目標(biāo)跟蹤在目標(biāo)的發(fā)現(xiàn)性能、定位精度和識別能力等方面均具有明顯改善［1］，同時，多源探測節(jié)點的異構(gòu)性主要表現(xiàn):監(jiān)測設(shè)備既可以是同類傳感器，也可以是異類傳感器;既可以是單一的地基平臺，還包括在特殊的探測任務(wù)背景和作戰(zhàn)需求下的不同傳感器的組合，如有源雷達(dá)、無源雷達(dá)、光電、紅外、聲探測傳感器等［2］。

隨著空中目標(biāo)監(jiān)控數(shù)據(jù)日益增長，各個源探測節(jié)點(傳感器)需經(jīng)過某種網(wǎng)絡(luò)的組件，傳輸?shù)蕉嘣茨繕?biāo)跟蹤處理平臺，通過對信息的深入挖掘，最大提升信息價值，掌握瞬息萬變的戰(zhàn)場態(tài)勢，本文提出了使用ZeroMQ消息庫完成多源信息傳輸，通過平臺設(shè)計的目標(biāo)航跡構(gòu)建、目標(biāo)航跡裁剪、目標(biāo)關(guān)聯(lián)融合、融合數(shù)據(jù)轉(zhuǎn)發(fā)等模塊，以達(dá)到減少冗余、綜合互補和捕捉協(xié)同信息的目的，完成多源空中監(jiān)控數(shù)據(jù)的融合與轉(zhuǎn)發(fā) (存儲)，為更高層次的數(shù)據(jù)處理、目標(biāo)識別、態(tài)勢評估以及智能決策等提供可靠數(shù)據(jù)基礎(chǔ)。

1 系統(tǒng)總體設(shè)計

多源監(jiān)測節(jié)點、設(shè)備或軟件普遍存在以下特點［3］:

(1)異構(gòu)性:監(jiān)測設(shè)備的多樣性使得空中監(jiān)測數(shù)據(jù)傳輸方式必須具備跨平臺特性;

(2)自治性:多源監(jiān)測設(shè)備都是可以獨立完成監(jiān)測任務(wù)的個體，同時可相互之間具有替代性和分時工作等特點;

(3)動態(tài)性:監(jiān)測設(shè)備可隨時根據(jù)任務(wù)等需要動態(tài)地加入和退出;

針對上述分析，結(jié)合ZeroMQ消息通信庫具備數(shù)據(jù)傳輸共享的實時性和可靠性等特點，同時可降低網(wǎng)絡(luò)編程的復(fù)雜性，且與平臺無關(guān)、接口實現(xiàn)相對簡單、可行等優(yōu)勢，本文提出使用ZeroMQ建立一個高效、可靠、透明、跨平臺的數(shù)據(jù)通信平臺，從空中目標(biāo)監(jiān)測數(shù)據(jù)中抽象出核心數(shù)據(jù)格式，采用一種輕量級的數(shù)據(jù)交換格式Json完成多源監(jiān)測設(shè)備與平臺的數(shù)據(jù)傳輸。

圖1 多源目標(biāo)跟蹤處理平臺設(shè)計框架

平臺功能模塊主要包括:

(1)監(jiān)測航跡數(shù)據(jù)發(fā)送、接收、轉(zhuǎn)發(fā)模塊:目標(biāo)監(jiān)測源 (設(shè)備)動態(tài)加入、退出，統(tǒng)一規(guī)范傳輸數(shù)據(jù)格式，通過ZeroMQ消息發(fā)送、接收、融合后轉(zhuǎn)發(fā)航跡點數(shù)據(jù)，支持源監(jiān)測節(jié)點動態(tài)接入與退出;

(2)航跡預(yù)處理:依據(jù)航跡關(guān)聯(lián)計算形成的知識庫，接收的航跡信息經(jīng)過預(yù)處理完成航跡信息融合;

(3)航跡構(gòu)建:按照航跡數(shù)據(jù)來報源探測節(jié)點 (傳感器)建立緩存航跡，獲取空中目標(biāo)航跡數(shù)據(jù)，并依據(jù)航跡數(shù)據(jù)的目標(biāo)編號進行航跡緩存，并實時更新緩存航跡信息，為后續(xù)航跡裁剪與關(guān)聯(lián)操作提供數(shù)據(jù)來源;

(4)航跡裁剪:為提升航跡關(guān)聯(lián)計算效率，當(dāng)緩存航跡持續(xù)時間較長、航跡點數(shù)較多時，實現(xiàn)航跡點的裁剪，當(dāng)緩存的航跡在長時間未收到新的航跡點，能夠判定航跡終結(jié)，執(zhí)行從航跡緩存容器中移除操作

(5)航跡關(guān)聯(lián):實現(xiàn)同一目標(biāo)多源航跡的關(guān)聯(lián)，生成不同批號同一目標(biāo)關(guān)聯(lián)關(guān)系對照表，進行關(guān)聯(lián)操作，并將關(guān)聯(lián)計算結(jié)果實時反饋至航跡預(yù)處理模塊，后續(xù)航跡信息能夠依據(jù)關(guān)聯(lián)知識庫進行融合。

2 實現(xiàn)關(guān)鍵技術(shù)

跟蹤處理平臺核心功能集成各個異構(gòu)目標(biāo)監(jiān)測節(jié)點數(shù)據(jù)通訊，通過航跡數(shù)據(jù)信息關(guān)聯(lián)等操作，并將融合后數(shù)據(jù)轉(zhuǎn)發(fā)，實現(xiàn)關(guān)鍵技術(shù)主要包括:

2.1 監(jiān)測目標(biāo)數(shù)據(jù)交換

由于多源監(jiān)測節(jié)點的異構(gòu)性，監(jiān)測目標(biāo)數(shù)據(jù)交換應(yīng)采用一種完全獨立于編程語言的文本格式來存儲和表示，Json恰恰是一種輕量級的數(shù)據(jù)交換格式，簡潔和清晰的層次結(jié)構(gòu)且易于對象序列化操作等優(yōu)勢［4］，使得 Json成為理想的數(shù)據(jù)交換語言。同時JSON易于閱讀和編寫、機器解析和生成，并有效地提升網(wǎng)絡(luò)傳輸效率［5］。

通過分析航跡監(jiān)測數(shù)據(jù)，抽象出與航跡關(guān)聯(lián)及后續(xù)態(tài)勢評估密切相關(guān)的參數(shù)和屬性，并生成統(tǒng)一的監(jiān)測數(shù)據(jù)交換Json格式，格式定義如表1。

表1 數(shù)據(jù)交換格式

2.2 多源目標(biāo)消息通訊

為保障源探測節(jié)點與跟蹤處理平臺通訊的實時性與可靠性，且支持多源節(jié)點實時加入與退出，平臺采用ZeroMQ消息通信庫完成監(jiān)測數(shù)據(jù)的通訊。ZeroMQ是一種基于消息隊列的多線程網(wǎng)絡(luò)庫，其對套接字類型、連接處理、幀、甚至路由的底層細(xì)節(jié)進行抽象，提供跨越多種傳輸協(xié)議的套接字。ZeroMQ是網(wǎng)絡(luò)通信中介于應(yīng)用層和傳輸層之間(按照TCP/IP劃分)，是一個可并行運行的伸縮層，分散在分布式系統(tǒng)間，相對于MSMQ、ActiveMQ和RabbitMQ等同類中間件在部署時需要專門的一個服務(wù)器［6］，ZeroMQ只需要讓應(yīng)用程序引用消息庫，即可完成多個進程間進行消息發(fā)送，使得部署起來非常簡單。

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

1)Request－Reply問答模式，特點是要求嚴(yán)格同步，必須請求端首先發(fā)起請求，等待回應(yīng)端應(yīng)答，并且一個請求必須對應(yīng)一個回應(yīng)，從請求端的角度來看是發(fā)－收配對，從回應(yīng)端的角度是收－發(fā)對，主要用于遠(yuǎn)程調(diào)用及任務(wù)分配等場景。

2)Pub－Sub發(fā)布訂閱模式，發(fā)布端單向分發(fā)數(shù)據(jù)，且不保證是否把全部信息發(fā)送給訂閱端。如果發(fā)布端開始發(fā)布信息時，訂閱端尚未連接，則這些信息會被直接丟棄，訂閱端只負(fù)責(zé)接收，而不能反饋，且在訂閱端消費速度慢于發(fā)布端的情況下，會在訂閱端堆積數(shù)據(jù)。

3)Push－Poll推拉模式，當(dāng)有多個Pull端同時連接到Push端時，則Push端會在內(nèi)部做一個負(fù)載均衡，采用平均分配算法，將所有消息均衡發(fā)布到Pull端上;當(dāng)有多個Push端同時連接到Pull端，稱這種結(jié)構(gòu)為公平隊列，即可將Pull端理解為一個隊列，各個Push端持續(xù)不斷地向隊列發(fā)送數(shù)據(jù)，與發(fā)布訂閱模型相比，推拉模型在沒有消費者的情況下，發(fā)布的消息不會被消耗掉 (Push端會阻塞);在消費者能力不夠的情況下，能夠提供多消費者并行消費解決方案，主要用于多任務(wù)并行處理。

圖2 ZeroMQ3種基本工作模式

2.3 目標(biāo)關(guān)聯(lián)融合處理

航跡關(guān)聯(lián)是將代表同一目標(biāo)的傳感器數(shù)據(jù)與目標(biāo)航跡進行關(guān)聯(lián)，將傳感器數(shù)據(jù)按照目標(biāo)進行分類，由于每條航跡都是由航跡點組成，且每個航跡點都包含準(zhǔn)確的時間、位置、速度等信息［7］，在諸多已有的目標(biāo)關(guān)聯(lián)方法中基于位置信息是最基本也是最成熟的關(guān)聯(lián)方法［8］，本文采用歐式距離的最小二乘法二次曲線擬合方法進行航跡關(guān)聯(lián)初步判斷，航跡關(guān)聯(lián)判斷流程如圖3所示。

圖3 航跡關(guān)聯(lián)流程

基于歐式距離的最小二乘法二次曲線擬合方法判斷航跡關(guān)聯(lián)性的基本思想是:

1)設(shè)定航跡點為三元組tp=(t，lon，lat)，分別由位置時間、經(jīng)度、緯度組成，首先兩條航跡t1和t2應(yīng)存在交叉時間△t(且△t＞閾值T)，選取航跡點較為密集的航跡t1(假定)在△t內(nèi)的K個航跡點進行最小二乘法二次曲線擬合得到經(jīng)度和緯度關(guān)于時間的二次方程:

2)選取航跡t2的在△t內(nèi)的K個航跡點，求得一組二維向量集α，將航跡t1和t2的航跡點經(jīng)度和緯度組成的向量集使用矩陣表示:

3)求解上述二維向量集α和б中相應(yīng)向量間的歐式距離，使用矩陣表示:

當(dāng)γ中每項都小于閾值M時，航跡t1和t2確定為同一條航跡。

4)由于監(jiān)測設(shè)備限于探測范圍、探測性能、空間分辨能力，從某一監(jiān)測設(shè)備角度而言，可能存在航跡間的斷續(xù)，多源監(jiān)測可通過航跡關(guān)聯(lián)關(guān)系之間傳遞，該操作稱之為關(guān)聯(lián)聚的構(gòu)造［9］，例如航跡t1與航跡t2已成功關(guān)聯(lián)，航跡t2與航跡t3已成功關(guān)聯(lián)，則航跡t3與航跡t1存在關(guān)聯(lián)，并通過航跡屬性確定主航跡。

3 系統(tǒng)軟件設(shè)計與實現(xiàn)

當(dāng)使用ZeroMQ消息庫實現(xiàn)跟蹤處理平臺與各個源監(jiān)測節(jié)點通訊時，考慮到監(jiān)測點或設(shè)備實時接入與退出，且能夠保證當(dāng)監(jiān)測數(shù)據(jù)較大時仍然能夠及時進行航跡計算處理，平臺通訊模塊綜合了Request－Reply問答模式與Push－Poll推拉模式實現(xiàn)，首先新接入的監(jiān)測設(shè)備應(yīng)先使用Request－Reply問答模式請求接入平臺，待服務(wù)端響應(yīng)后執(zhí)行接入操作，并開始發(fā)送數(shù)據(jù) (Push－Poll推拉模式)，同時服務(wù)端登記新接入的設(shè)備 (節(jié)點)編號，數(shù)據(jù)經(jīng)融合處理后以Pub－Sub消息訂閱模式發(fā)布出去，供其他系統(tǒng)或平臺訂閱。

為了提高數(shù)據(jù)并發(fā)處理能力，通訊模塊采用多線程實現(xiàn)Push－Poll推拉模式。

當(dāng)新的監(jiān)測設(shè)備接入時，創(chuàng)建線程后注冊設(shè)備編號并發(fā)送給注冊服務(wù)，等待注冊服務(wù)返回確認(rèn)消息后可進行目標(biāo)監(jiān)測數(shù)據(jù)發(fā)送。

接人設(shè)備端線程主要實現(xiàn)代碼如下:

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

//Request－Reply問答模式注冊設(shè)備編號

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 平臺數(shù)據(jù)傳輸設(shè)計

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

checkReply(reply);//驗證注冊返回碼

requester．close();

//開始連接并Push－Poll推拉模式發(fā)送數(shù)據(jù)

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();

跟蹤處理平臺首先完成接入設(shè)備注冊操作，同時，持續(xù)接收各個接入設(shè)備發(fā)送的數(shù)據(jù)并進行融合處理，其中，平臺數(shù)據(jù)接收主要實現(xiàn)代碼如下:

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);//接入設(shè)備校驗

fusionOpt(message);//航跡關(guān)聯(lián)操作入口

}

4 實驗分析

為了測試平臺的數(shù)據(jù)吞吐量，我們實驗中接入10個監(jiān)測設(shè)備與跟蹤處理平臺進行數(shù)據(jù)傳輸與交互，每個檢測設(shè)備通過發(fā)送1 000 000個0.5 kb大小的Json格式數(shù)據(jù)的消息，并且計算兩邊發(fā)送和接收消息的時間，實驗表明:單個發(fā)送端數(shù)據(jù)速度可超過10萬/s條數(shù)據(jù)，接收端滿負(fù)荷數(shù)據(jù)處理速度可達(dá)到10萬/秒條，且當(dāng)接入設(shè)備發(fā)送數(shù)據(jù)速度遠(yuǎn)大于綜合平臺數(shù)據(jù)處理與接收能力時，接收設(shè)備端的數(shù)據(jù)發(fā)送Push線程出現(xiàn)阻塞，盡管可增大ZeroMQ數(shù)據(jù)緩沖區(qū)大小，在一定程度上緩解線程阻塞出現(xiàn)頻率，但隨著更多監(jiān)測設(shè)備的接入，設(shè)備發(fā)送端線程阻塞出現(xiàn)更加頻繁，數(shù)據(jù)接受延遲會不斷增大，針對這個問題，我們通過使用增加通訊模型中的Pull端線程進行并行接收處理，此外ZeroMQ消息庫還提供了批量消息接收處理接口，可大大提升數(shù)據(jù)傳輸能力。

5 結(jié)束語

鑒于目標(biāo)多源監(jiān)測設(shè)備存在異構(gòu)性、位置分散，且監(jiān)測原始數(shù)據(jù)格式不夠統(tǒng)一、數(shù)據(jù)生成速度各不相同，為了保證各個目標(biāo)監(jiān)測節(jié)點與跟蹤處理平臺之間數(shù)據(jù)高速通信，本文提出了一種基于ZeroMQ消息庫的通信模式，綜合ZeroMQ消息庫3種工作模式，從傳輸數(shù)據(jù)中抽取關(guān)鍵信息并采用Json進行數(shù)據(jù)交換，建立多線程Push－Poll數(shù)據(jù)推拉模式，支持各源監(jiān)測點實時接入與退出，大大提高了數(shù)據(jù)交互處理能力，上述方法在處理數(shù)據(jù)量大、實時性要求高的數(shù)據(jù)交互和通訊的應(yīng)用中具有一定的通用性，此外，本文采用歐式距離的最小二乘法二次曲線擬合方法進行航跡關(guān)聯(lián)操作，此方法在處理航跡連續(xù)性較好、航跡間存在時間交叉情況時關(guān)聯(lián)成功率高，該算法實現(xiàn)簡單但前提假設(shè)過于嚴(yán)苛［10］，且沒能將目標(biāo)航跡點的速度、水平高度、監(jiān)測設(shè)備誤差等因素考慮在內(nèi)，當(dāng)航跡分叉、交叉航跡點少等情況難以處理，關(guān)聯(lián)操作存在不足。