一種分層并行計(jì)算的軟件化雷達(dá)系統(tǒng)*

趙 幫，李武旭，趙浩然

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

0 引 言

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

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

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

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

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

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

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

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

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

2 節(jié)點(diǎn)間的任務(wù)級分布式計(jì)算

2.1 節(jié)點(diǎn)間的任務(wù)級分布式通信模型的設(shè)計(jì)

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

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

圖2 ZMQ分布式通信模型

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

2.2 節(jié)點(diǎn)間的任務(wù)級分布式計(jì)算的實(shí)現(xiàn)

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

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

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

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

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

圖3 分布式通信工作流程

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

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

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

圖4 RnPS的線程模式

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

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

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

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

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

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

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

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

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

(1)

(2)

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

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

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

array Device_SumBaseband_Amplitude;

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

array Device_SumBaseband_FrontShift;

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

array Front_CompareArray1;

//大于等于半電壓的下標(biāo)集合

array Front_CompareArray2;

//小于等于半電壓的下標(biāo)集合，且下標(biāo)加1

array Frontedge_Array;//前沿下標(biāo)

Device_SumBaseband_FrontShift =

0.5*shift(Device_SumBaseband_Amplitude,5);

//左移5個點(diǎn)，然后×0.5為半電壓

Front_CompareArray1=

where(Device_SumBaseband_Amplitude >=

Device_SumBaseband_FrontShift);

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

Front_CompareArray2=

where(Device_SumBaseband_Amplitude <=

Device_SumBaseband_FrontShift)+ 1;

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

Frontedge_Array =setIntersect

(CompareArray1,Front_CompareArray2+1,true);

//上面兩個特征的交集就是前沿集合的下標(biāo)

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

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

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

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

表1(續(xù))

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

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

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

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

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

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

圖7 對空目標(biāo)實(shí)時顯示

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

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

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

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

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

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

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

6 結(jié) 論

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