基于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］，且沒能將目標航跡點的速度、水平高度、監測設備誤差等因素考慮在內，當航跡分叉、交叉航跡點少等情況難以處理，關聯操作存在不足。