趙 幫，李武旭，趙浩然

(四川九洲空管科技有限責任公司，四川 綿陽 621000)

0 引 言

雷達系統(tǒng)的主要技術發(fā)展階段大致可以分為模擬定制雷達、數(shù)字化雷達、軟件化雷達、智能化雷達四個階段[1]。隨著數(shù)字化技術的發(fā)展，雷達系統(tǒng)逐漸從傳統(tǒng)“以硬件為核心，功能單一”的開發(fā)模式發(fā)展到“以軟件為中心，面向?qū)嶋H需求”的開發(fā)模式。軟件化雷達系統(tǒng)具有標準化、模塊化、開放式的系統(tǒng)架構(gòu)，其系統(tǒng)功能由軟件定義、擴展、升級，具有開發(fā)周期短、費用低、維修升級方便等優(yōu)點。然而，實時性和數(shù)據(jù)處理能力作為軟件化雷達的兩個重要技術指標，也是軟件化雷達實現(xiàn)的難點。通常，處理的數(shù)據(jù)量越大，處理的時間越長，實時性就越差[2]。

已有大量研究和應用表明，在多核中央處理器(Central Processing Unit,CPU)和多處理器環(huán)境下，應用適當?shù)牟⑿杏嬎慵夹g能提高計算機系統(tǒng)的運算能力。當前并行技術主要有線程級的基于CPU的多線程并行計算[3-6]、數(shù)據(jù)級的基于圖形處理單元(Graphic Processing Unit,GPU)的并行加速計算[7-9]和系統(tǒng)級多節(jié)點的分布式架構(gòu)[10-12]。不過從這些文獻可知，目前大部分研究主要集中在單一模式或CPU加GPU的異構(gòu)并行設計，并沒有充分利用系統(tǒng)的硬件資源。

當前軟件化雷達系統(tǒng)的主要瓶頸之一就是對大量高速數(shù)據(jù)的實時處理能力。實際工程中，各類雷達系統(tǒng)的實時處理數(shù)據(jù)率在0.6～10 Gb/s，數(shù)據(jù)量遠沒達到海量的互聯(lián)網(wǎng)云計算級別，但僅靠一臺通用計算機又達不到實時處理要求，所以就需要設計一套小型的分布式并行計算系統(tǒng)。基于此，本文設計了一種基于任務級、線程級和數(shù)據(jù)級的三層并行運算系統(tǒng)，充分利用系統(tǒng)的CPU和GPU硬件資源，使得基于任務級，節(jié)點數(shù)可在線拓展；基于線程級，線程數(shù)可靈活配置；基于數(shù)據(jù)級，可充分發(fā)揮計算機GPU并行處理能力。

1 分層并行計算的軟件雷達系統(tǒng)架構(gòu)

軟件化雷達系統(tǒng)分層并行計算架構(gòu)如圖1所示，系統(tǒng)由射頻前端、數(shù)據(jù)服務器、譯碼、點跡和業(yè)務終端五個模塊組成。

圖1 分層并行計算系統(tǒng)架構(gòu)圖

雷達天線接收到信號后，傳輸給射頻前端。射頻前端接收機將射頻信號轉(zhuǎn)換為中頻信號，利用AD/DA高速采樣模塊對中頻信號進行采樣，每3 ms產(chǎn)生一個雷達報文的采樣數(shù)據(jù)，數(shù)據(jù)使用UDP(User Datagram Protocol)網(wǎng)絡協(xié)議通過萬兆光纖傳輸給數(shù)據(jù)服務器節(jié)點。數(shù)據(jù)服務器對采樣數(shù)據(jù)進行實時存儲和格式轉(zhuǎn)換，為提高數(shù)據(jù)發(fā)送效率，每收到10個雷達報文就發(fā)送一次。譯碼節(jié)點并行收取數(shù)據(jù)和處理數(shù)據(jù)，譯碼模塊和點跡模塊需要在30 ms內(nèi)完成雷達報文的并行處理，以達到目標的實時顯示。

數(shù)據(jù)服務器模塊、譯碼模塊、點跡模塊之間采用ZeroMQ技術[13]進行通信。譯碼模塊需要對高速的采樣數(shù)據(jù)進行實時處理分析運算，整個系統(tǒng)的運算量主要集中在譯碼模塊。為滿足系統(tǒng)實時性的要求，采用多節(jié)點分布式計算，以實現(xiàn)第一層任務級并行計算。數(shù)據(jù)服務器模塊、譯碼模塊、點跡模塊基于多線程編程技術，每個模塊分為輸入線程、處理線程和輸出線程。其中，處理線程根據(jù)處理數(shù)據(jù)的實時性要求采用多線程并行處理，實現(xiàn)第二層線程級并行計算。線程內(nèi)，為提高系統(tǒng)運算效率，采用GPU并行計算技術，實現(xiàn)第三層數(shù)據(jù)級并行計算。

業(yè)務終端模塊由顯示節(jié)點和管理節(jié)點組成，顯示節(jié)點主要是收取目標點跡報文和雷達勤務報文，在顯示終端上形成連續(xù)的目標點跡。管理節(jié)點主要對所有節(jié)點進行管理控制和監(jiān)控，并生成系統(tǒng)運行日志。

2 節(jié)點間的任務級分布式計算

2.1 節(jié)點間的任務級分布式通信模型的設計

為提高任務級并行計算能力，并解決節(jié)點間通信開銷大、延遲高、配置復雜的問題，本文引入ZeroMQ技術。ZeroMQ簡稱ZMQ，是一個消息處理隊列庫，有“史上最快的消息隊列”之稱，可在多個線程、內(nèi)核和主機節(jié)點之間彈性伸縮。ZMQ在Socket API之上做了一層封裝，將網(wǎng)絡通信、進程通信和線程通信抽象為統(tǒng)一的API接口，具有部署簡單、性能強大、通信延遲小的特征。該技術能確保系統(tǒng)在任意時間隨機加入或撤銷一個節(jié)點仍然能穩(wěn)定運行，非常方便開發(fā)者搭建屬于自己的分布式系統(tǒng)[14]。

ZMQ有簡單的請求回應通信模式、廣播式的發(fā)布訂閱通信模式和并行的管道通信模式(推拉模式)三種通信模式。本文采用并行的管道通信模式實現(xiàn)節(jié)點間任務級的分布式計算。管道通信模型由上游節(jié)點、工作節(jié)點和下游節(jié)點三部分組成。上游節(jié)點負責分發(fā)數(shù)據(jù)，工作節(jié)點負責處理數(shù)據(jù)，下游節(jié)點負責收集和匯總數(shù)據(jù)。數(shù)據(jù)服務器節(jié)點、譯碼節(jié)點和點跡節(jié)點分別對應其上游節(jié)點、工作節(jié)點和下游節(jié)點。其分布式通信模型如圖2所示。

圖2 ZMQ分布式通信模型

數(shù)據(jù)服務器節(jié)點為上游節(jié)點，與譯碼節(jié)點之間形成一對推拉模式。多個譯碼節(jié)點同時接入數(shù)據(jù)服務器節(jié)點后，數(shù)據(jù)服務器節(jié)點會以負載均衡的方式把數(shù)據(jù)等份地分給每個譯碼節(jié)點。譯碼節(jié)點屬于工作節(jié)點，與點跡節(jié)點之間形成一對推拉模式。譯碼節(jié)點之間采用公平的隊列形式進行數(shù)據(jù)收發(fā)，數(shù)據(jù)在譯碼節(jié)點上處理完后，將在點跡節(jié)點上完成數(shù)據(jù)融合。最終實現(xiàn)了數(shù)據(jù)在數(shù)據(jù)服務器節(jié)點、譯碼節(jié)點和點跡節(jié)點之間形成一種1∶N∶1的處理模式。工作過程中任一譯碼節(jié)點發(fā)生掉線，系統(tǒng)仍能正常運行，其數(shù)據(jù)將會重新分配到其他工作節(jié)點上進行處理。同時當節(jié)點負載過高時，本系統(tǒng)支持在任何時間加入譯碼節(jié)點降低節(jié)點負載。

2.2 節(jié)點間的任務級分布式計算的實現(xiàn)

節(jié)點間任務級分布式通信主要是通過數(shù)據(jù)服務器節(jié)點進行數(shù)據(jù)的分發(fā)，譯碼節(jié)點進行數(shù)據(jù)處理，點跡節(jié)點進行數(shù)據(jù)整合。

數(shù)據(jù)服務器節(jié)點構(gòu)成了原模型中的上游節(jié)點，具有數(shù)據(jù)分發(fā)、存儲和回放功能，工作在推模式。

譯碼節(jié)點構(gòu)成了原模型中工作節(jié)點。譯碼節(jié)點可以運行在多個計算機上，并且系統(tǒng)運行中任何時刻譯碼節(jié)點掉線或增加一個譯碼節(jié)點均不影響系統(tǒng)的正常運行。接收數(shù)據(jù)時工作在拉模式，發(fā)送數(shù)據(jù)時工作在推模式。

點跡節(jié)點作為下游節(jié)點，其主要作用是接收譯碼節(jié)點的數(shù)據(jù)，進行數(shù)據(jù)組合，形成點跡報文和勤務報文發(fā)送到顯示節(jié)點，工作在拉模式。

節(jié)點間通信工作流程具體實現(xiàn)如圖3所示。

圖3 分布式通信工作流程

3 節(jié)點內(nèi)線程級并行計算

分布式系統(tǒng)中節(jié)點間的通信是一種進程間的通信。理論上，節(jié)點的數(shù)量增加，系統(tǒng)的性能會成比例增長。然而事實上，由于節(jié)點之間存在通信開銷，隨著節(jié)點數(shù)的增長，系統(tǒng)負荷加重，網(wǎng)絡通信負載變大，系統(tǒng)數(shù)據(jù)處理能力反而無明顯變化。因此為增強系統(tǒng)的并行處理能力，而簡單粗暴的加入節(jié)點數(shù)并不是一種有效方案。對此本文從細粒度的角度考慮，繼續(xù)深挖系統(tǒng)單節(jié)點的硬件資源。當前多核CPU占主流，采用多線程技術可以充分利用計算機多核的特征，加強單節(jié)點的計算能力，從而滿足系統(tǒng)運算量大且實時性高的要求。

通過分析總結(jié)，系統(tǒng)的每一個節(jié)點都存在收數(shù)據(jù)、處理數(shù)據(jù)和發(fā)送數(shù)據(jù)的共性。因此，將一個節(jié)點分解成3個線程，采用流水線方式進行處理。然而通過試驗發(fā)現(xiàn)，通常情況下處理線程的數(shù)據(jù)運算量大且復雜，計算時間長，為整個節(jié)點的瓶頸所在。為提高系統(tǒng)并行效率，筆者將處理線程進一步分解為多個線程，設計了一種RnPS的線程模式，如圖4所示。其中，R表示收數(shù)據(jù)線程，P表示處理數(shù)據(jù)線程，S表示發(fā)送數(shù)據(jù)線程，n表示處理線程的個數(shù)。

圖4 RnPS的線程模式

進一步分析R收線程、P處理線程與S發(fā)送線程發(fā)現(xiàn)，R與P、P與S之間正好形成了一對經(jīng)典的生產(chǎn)者消費者模型：R與P之間，R線程作為生產(chǎn)者線程，P線程作為消費者線程；P與S之間，P線程作為生產(chǎn)者線程，S線程作為消費者線程。由此，每一個節(jié)點模型被分解成多個生產(chǎn)者消費者模型[15]。對于解決經(jīng)典的生產(chǎn)者消費模型的問題本文不再贅述。

此模型中，對于P線程，應重點考慮P線程的個數(shù)。P線程的個數(shù)主要由以下因素決定：R線程產(chǎn)生的數(shù)據(jù)量大小和速度；節(jié)點CPU核心數(shù)；節(jié)點需要處理數(shù)據(jù)的復雜度；節(jié)點分解到P線程的任務個數(shù)。

由此可見，P線程個數(shù)由系統(tǒng)環(huán)境等一系列外因決定，并不是一個固定值，系統(tǒng)設計者需要將每個節(jié)點的P線程個數(shù)設置為可配置狀態(tài)。在理想狀態(tài)下P線程所用的時間將與R線程、S線程時間相當。通常情況下，系統(tǒng)內(nèi)核CPU核心數(shù)是一定的，當R線程收到大量高速數(shù)據(jù)導致P線程來不及處理時，就不能一味地通過增加線程數(shù)解決系統(tǒng)延遲的問題了。對此本文下一節(jié)將討論如何利用系統(tǒng)GPU資源增強系統(tǒng)并行運算能力。

4 數(shù)據(jù)級GPU并行計算

CPU具有處理復雜邏輯和指令級并行的能力，而GPU更適合處理大數(shù)據(jù)量、高并行、邏輯控制簡單的數(shù)據(jù)。GPU具有大量的可編程內(nèi)核，可以支持大量的多線程，并且比 CPU 有著更高的峰值帶寬，因此，GPU在處理大規(guī)模浮點運算上擁有 CPU 無法比擬的優(yōu)勢[16]。

ArrayFire 平臺是 AccelerEyes 公司發(fā)布的快速開發(fā) GPU 應用程序的開源軟件，也是目前最方便、最穩(wěn)定的 GPU 應用程序開發(fā)工具包。ArrayFire 提供了簡單的高級矩陣抽象函數(shù)，可以讓使用者充分利用GPU的硬件優(yōu)勢[17]。

在軟件化雷達系統(tǒng)中，通常涉及到信號處理和數(shù)據(jù)處理的一些常規(guī)算法，例如脈沖檢測算法、脈沖壓縮算法、動目標檢測算法、恒虛警檢測算法等[18]。這些算法的計算往往就是簡單邏輯的大規(guī)模浮點運算?；谶@個特征，在譯碼節(jié)點上設計了第三層并行計算模型，采用Arrayfire技術實現(xiàn)了節(jié)點內(nèi)的數(shù)據(jù)級GPU并行計算，充分利用單個節(jié)點計算機硬件資源，增強系統(tǒng)計算能力和實時性。

本文以脈沖前沿檢測算法為例，介紹在Arrayfire環(huán)境下算法的設計實現(xiàn)過程。

在譯碼節(jié)點脈沖檢測過程中，首先需要識別出脈沖的前后沿，判斷脈沖的有效寬度。以二次雷達應答信號為例，標準脈沖寬度為0.45 μs，由于系統(tǒng)采樣率為20 MHz，因此標準脈沖的采樣點長度為9。采用延時線的方法，取當前采樣點延時半脈沖長度也就是延遲5個采樣點，那么脈沖前沿點具有以下特征：

(1)

(2)

用S(n)表示當前采樣值，用S(n+5)表示延時5個采樣點的值，S(n-1)表示前一個采樣點的值，n表示樣點個數(shù)，那么算式(1)與算式(2)的交集就是脈沖的前沿。樣本數(shù)n一般是一個非常大的值，以萬為單位，那么S(n)將是一個龐大的數(shù)組，一個龐大數(shù)組的串行計算將嚴重制約系統(tǒng)的性能。本文利用Arrayfire基于GPU的強大并行運算能力，將大的數(shù)組分解成小塊，在GPU上進行高速并行計算，實現(xiàn)數(shù)據(jù)的實時性。其程序設計流程如圖5所示。

圖5 基于ArrayFire脈沖前沿檢測算法的實現(xiàn)

在脈沖前沿檢測過程中，ArrayFire 程序只需要定義array就可以實現(xiàn)CPU到GPU的并行處理。其關鍵代碼如下：

array Device_SumBaseband_Amplitude;

//定義和通道電壓采樣幅度值

array Device_SumBaseband_FrontShift;

//采樣值，前移半脈沖并且降低半電壓

array Front_CompareArray1;

//大于等于半電壓的下標集合

array Front_CompareArray2;

//小于等于半電壓的下標集合，且下標加1

array Frontedge_Array;//前沿下標

Device_SumBaseband_FrontShift =

0.5*shift(Device_SumBaseband_Amplitude,5);

//左移5個點，然后×0.5為半電壓

Front_CompareArray1=

where(Device_SumBaseband_Amplitude >=

Device_SumBaseband_FrontShift);

//取和通道大于移位半電壓的下標，前沿就是下標的子集

Front_CompareArray2=

where(Device_SumBaseband_Amplitude <=

Device_SumBaseband_FrontShift)+ 1;

//取和通道小于移位半電壓的下標，然后下標集合加1

Frontedge_Array =setIntersect

(CompareArray1,Front_CompareArray2+1,true);

//上面兩個特征的交集就是前沿集合的下標

5 系統(tǒng)運行及測試分析

5.1 系統(tǒng)運行平臺

整個系統(tǒng)在某雷達站進行部署，通過采集真實數(shù)據(jù)進行測試驗證。系統(tǒng)包括一個射頻前端模塊、一個數(shù)據(jù)服務器節(jié)點、兩個譯碼節(jié)點、一個點跡節(jié)點、一個業(yè)務終端模塊和一臺萬兆交換機。系統(tǒng)運行環(huán)境參數(shù)如表1所示。

表1 系統(tǒng)運行環(huán)境參數(shù)

表1(續(xù))

5.2 系統(tǒng)運算處理能力測試

系統(tǒng)采用三層并行計算實現(xiàn)，針對節(jié)點級、線程級、數(shù)據(jù)級并行計算的不同數(shù)據(jù)處理特性，在處理不同的接收數(shù)據(jù)率情況下，分別對比了三層并行計算和單層并行計算的處理能力。測試結(jié)果如圖6所示,橫坐標表示接收數(shù)據(jù)的速率，縱坐標表示處理時間，也就是系統(tǒng)延時。

圖6 三層并行計算數(shù)據(jù)處理特性

從圖6中可以明顯看出,單層并行計算隨著數(shù)據(jù)率的增大處理時間急速增長，而三層并行計算的處理時間增長緩慢。這是由于隨接收數(shù)據(jù)率的增大系統(tǒng)的硬件處理能力達到飽和，此時三層并行處理能力的優(yōu)勢就顯而易見了。但在數(shù)據(jù)率低的時候，特別是數(shù)據(jù)率低于600 Mb/s時，采用單層并行計算的方式反而優(yōu)于三層并行計算方式。這主要由于三層并行計算相對單層并行計算方式系統(tǒng)更加復雜，所需初始化硬件資源占用大量的時間，系統(tǒng)高速計算處理能力并沒有發(fā)揮出來。從測試結(jié)果可得出，采用三層并行計算方式在處理高速的接收數(shù)據(jù)也就是大規(guī)模數(shù)據(jù)量時有明顯的優(yōu)勢，特別是數(shù)據(jù)率在1 000 Mb/s以上時，系統(tǒng)處理時間穩(wěn)定在30 ms以內(nèi)，完全符合雷達系統(tǒng)對大規(guī)模高速數(shù)據(jù)處理實時性的要求。

5.3 系統(tǒng)對空測試

系統(tǒng)在某雷達站部署完成后，進行實時數(shù)據(jù)處理分析，能形成連續(xù)的目標點跡，且與雷達站成熟的雷達系統(tǒng)形成的目標點跡一致。系統(tǒng)運行過程中所形成的部分點跡目標如圖7所示。

圖7 對空目標實時顯示

5.3.1 對空測試系統(tǒng)實時性分析

系統(tǒng)延時主要由前端采樣系統(tǒng)延時、數(shù)據(jù)在網(wǎng)絡中傳輸延時、數(shù)據(jù)譯碼和點跡顯示延時四部分組成。由于系統(tǒng)部署在一個局域網(wǎng)中，網(wǎng)絡傳輸延遲可以忽略不計。前端采樣系統(tǒng)以3 ms一個雷達報文周期為時間片段定時采樣傳輸，因此一個雷達報文延時為固定3 ms。數(shù)據(jù)服務器模塊每10個雷達周期發(fā)送一次數(shù)據(jù)，因此后續(xù)的譯碼模塊和點跡模塊必須保證在30 ms能處理完30 ms的數(shù)據(jù)(10個雷達周期)，那么系統(tǒng)就可以完成實時的處理。通過測試，使用單譯碼節(jié)點、單處理線程，系統(tǒng)在譯碼階段需要61 ms左右，數(shù)據(jù)處理出現(xiàn)明顯卡頓，系統(tǒng)有明顯延遲現(xiàn)象；若增加一個譯碼節(jié)點，使用雙線程進行處理，譯碼階段數(shù)據(jù)處理時間將下降到25 ms左右，整個系統(tǒng)運行流暢。

系統(tǒng)采用三層并行計算，那么系統(tǒng)的性能將取決于任務級、線程級和數(shù)據(jù)級每一層的性能。由于GPU硬件性能是不可變的，那么系統(tǒng)的性能就完全取決于任務級節(jié)點個數(shù)和線程級線程個數(shù)。分別配置不同的線程數(shù)和節(jié)點數(shù)，使用預先采集的一分鐘雷達真實數(shù)據(jù)進行回放測試。同樣系統(tǒng)環(huán)境下重復測試10次，記錄系統(tǒng)的延時時間并取平均值，如表2所示。

表2 不同模式下系統(tǒng)運行延遲

從表2中數(shù)據(jù)可以看出，采用單節(jié)點單處理線程，系統(tǒng)延遲非常明顯，高達61 ms；采用雙節(jié)點雙線程，系統(tǒng)延遲明顯下降到25 ms；不過繼續(xù)加大節(jié)點數(shù)和線程數(shù)，系統(tǒng)延遲將無法突破20 ms。這主要因為系統(tǒng)三層并行設計增加了系統(tǒng)的復雜性，導致系統(tǒng)初始化硬件資源占用時間較長，系統(tǒng)運行延遲占用時間接近20 ms。因此，為了保證系統(tǒng)性能并充分降低硬件成本，采用2節(jié)點、至少2線程的處理方式進行系統(tǒng)部署。

5.3.2 對空測試系統(tǒng)實時數(shù)據(jù)運算量分析

系統(tǒng)總的數(shù)據(jù)率為采樣頻率、通道數(shù)、IQ路數(shù)、數(shù)據(jù)位數(shù)的乘積。其中采樣頻率為20 MHz，通道數(shù)為3，IQ路數(shù)為2，數(shù)據(jù)位數(shù)為16 b，計算可得總數(shù)據(jù)率為1 920 Mb/s。由于數(shù)據(jù)服務器模塊每30 ms送出一包數(shù)據(jù)，數(shù)據(jù)量為1 920 Mb/s×30 ms,因此譯碼模塊需要在30 ms內(nèi)處理57.6 Mb的數(shù)據(jù)量。一個雷達周期為3 ms，雷達測距范圍為時間乘以光速除以2，計算得到理論雷達測距范圍為450 km，完全滿足雷達系統(tǒng)對測距指標的要求(至少為370.4 km)[19]。

6 結(jié) 論

為解決軟件化雷達系統(tǒng)的實時性和數(shù)據(jù)處理能力問題，本文設計了一種分層級并行計算的軟件化雷達實時處理系統(tǒng)，實現(xiàn)了基于任務級的分布式并行計算、基于線程級的多核并行計算和基于數(shù)據(jù)級的GPU并行計算。系統(tǒng)可以根據(jù)數(shù)據(jù)運算量和實時性要求，對節(jié)點數(shù)和線程數(shù)進行靈活配置和部署，有效解決了軟件化雷達系統(tǒng)中高實時和大數(shù)據(jù)量處理的瓶頸問題。在實際工程環(huán)境中進行部署測試，結(jié)果表明本系統(tǒng)具有良好的擴展性和廣闊的工程應用前景。