劉邦強

（中國民用航空三亞空中交通管理站，海南三亞 572000）

0 引言

空管雷達數(shù)據(jù)融合及處理是空管自動化系統(tǒng)設計的關鍵模塊。隨著民航的快速發(fā)展，空域內的飛行量也隨之增大，空中交通管制的要求更加苛刻，要求空管自動化系統(tǒng)在整個管制空域內實現(xiàn)雷達數(shù)據(jù)處理的無縫多重覆蓋。處理量的增加和保持高精度要求是系統(tǒng)穩(wěn)定設計的一個矛盾。實際上，由于空域的高度層和特定現(xiàn)場運行情況的不同，在具體空域中，目標的運行狀態(tài)和常見數(shù)量在一定時間段內不會產生突變，并且對雷達處理有個性化要求。航空器的運行狀態(tài)（平飛、上升、下降或機動）系統(tǒng)的算法實時性和精度要求也不一樣。本文從實際出發(fā)，提出一種多樣化配置的空管自動化雷達數(shù)據(jù)處理方案，在一個管制中心內對不同區(qū)域、不同運行狀態(tài)的航空器采用不同的雷達數(shù)據(jù)處理方式，實現(xiàn)雷達數(shù)據(jù)的靈活配置處理，最終在C#平臺上進行仿真驗證。

1 空管自動化系統(tǒng)雷達數(shù)據(jù)處理方法

當前，空管自動化系統(tǒng)主要采用單一的雷達數(shù)據(jù)處理方式，如南京萊斯系統(tǒng)采用的馬賽克處理方式、Telephonics系統(tǒng)采用的加權系數(shù)融合方式。馬賽克處理方法將系統(tǒng)界面范圍內的空域劃分為網格馬賽克，根據(jù)實際經驗值，在固定的馬賽克方框內采用某一路雷達數(shù)據(jù)作為融合的主要代表，這種處理方法在高度的融合上非常常見，系統(tǒng)運行開銷較小，而且如若經驗值得當，運行效果也較為合理（實際雷達站的部署會造成雷達數(shù)據(jù)在不同區(qū)域有不同的質量情況）。但是其也存在不少問題，以高度為例，如若目標在跨越網格，系統(tǒng)將會出現(xiàn)雷達數(shù)據(jù)切換，從當前雷達切換到另一個雷達，容易出現(xiàn)高度跳變[1]。加權系數(shù)融合適用性較強，但是無法降低系統(tǒng)的開銷，算法運行復雜、穩(wěn)定性較弱，容易牽一發(fā)動全身。同時，雖然系統(tǒng)的運行較為平滑，但是可能出現(xiàn)系統(tǒng)計算結果和實際目標飛行狀態(tài)有差異的情況。當然，這些算法在整個區(qū)域內采用統(tǒng)一的算法計算方式，在大多數(shù)情況下確實能夠滿足現(xiàn)場運行，但隨著未來中國空域改革，如果管制區(qū)域范圍增大，這種配置顯然無法滿足實際運行。在某些區(qū)域的某些時段，系統(tǒng)的運行可能會出現(xiàn)不可預見的效果，這對于萬無一失的管制工作要求來說是不可接受的。在航路飛行監(jiān)視上，系統(tǒng)的覆蓋范圍較大，所需處理的目標數(shù)量也較大，對雷達處理的目標數(shù)量要求較高，而對比其他區(qū)域的管制，由于間隔不同，系統(tǒng)對于精度的要求可以適當降低；在終端區(qū)和塔臺，通常在某一時刻，系統(tǒng)需要處理的目標數(shù)量不多，但是對具體目標的精度要求卻更高。因此，單一的馬賽克或加權系數(shù)的處理不適合實際運行。

2 方法研究

綜上所述，空管雷達數(shù)據(jù)處理實際需要兩個層面的設計，一是對單雷達數(shù)據(jù)的處理；二是多雷達數(shù)據(jù)融合處理。前者是后者的基礎，也是空管自動化系統(tǒng)旁路依賴的信息；后者則是空管自動化系統(tǒng)的最終顯示基礎[2]。

2.1 單雷達數(shù)據(jù)處理

單雷達數(shù)據(jù)處理主要處理雷達站發(fā)送到自動化系統(tǒng)的點、航跡信息。在實際處理上，雷達數(shù)據(jù)是以扇區(qū)為單位發(fā)送的，由于航空器是時刻移動的，因此必然存在有處于扇區(qū)交接的點、航跡數(shù)據(jù)，正常的算法需要考慮該扇區(qū)和相鄰2個扇區(qū)、3個扇區(qū)內部的點跡信息，扇區(qū)角度達到67.5h。這樣的處理算法雖然滿足平滑要求，但卻降低了算法效率。實際上，當前性能最好的民用航空器以最大的速度飛行也不可能在5 s內移動超過11.5h。因此，在數(shù)據(jù)處理上可以將其分為點跡扇區(qū)和航跡扇區(qū)。前者分為16個扇區(qū)，后者則為前者旋轉半個扇區(qū)（11.5h）。利用這種機制，可以實現(xiàn)原來3個扇區(qū)內部的數(shù)據(jù)處理縮減為2個扇區(qū)內部的數(shù)據(jù)處理，算法開銷降低33%。這種旋轉處理需要根據(jù)實際進行延遲補償，如增加旋轉周期一半的時間延遲等，以確保數(shù)據(jù)的同步完整性。

在雷達的航跡相關和新建上，對扇區(qū)A的航跡處理時需要遍歷該扇區(qū)內部已經建立的航跡，對于每個航跡的相關都需要遍歷相鄰兩個點跡扇區(qū)的所有點跡。為了提高算法效率，算法可以設計一個動態(tài)自適應窗口進行第一步的過濾。航跡的新建，系統(tǒng)如若遍歷完畢沒有找到相關的航跡，則將生成一個新的航跡，并將該航跡定義為臨時航跡，算法設置判斷參數(shù)為3，3次同時接受到該航跡，并且臨時航跡與點跡的相似值都在相關門限下則可以新建航跡。

2.2 改進型馬賽克算法

在馬賽克算法的處理上可以做以下改進：依次計算系統(tǒng)單雷達航跡和馬賽克單元以及相鄰單元的所有航跡的近似值，最后確定雷達航跡是否已和現(xiàn)有航跡相關，如若可以，則將所有航跡信息更新到該相關航跡上；一個系統(tǒng)航跡的數(shù)據(jù)結構設計可以包含3部雷達的航跡信息；根據(jù)正?？展茏詣踊到y(tǒng)的顯示周期設計（4～5 s），算法可以將航跡列表中的所有雷達外推到系統(tǒng)更新的時間，并經過動態(tài)反饋檢查，所有系統(tǒng)航跡相關的雷達進行加權平均得出最優(yōu)值。在位置和速度的處理上可以有：

式中：i∈[1，3]為不同的雷達信號；k為可自定義的雷達優(yōu)先等級；M為單雷達信號質量參數(shù)；MTQ為系統(tǒng)單雷達航跡與系統(tǒng)航跡近似參數(shù)。

由于信號延遲補償?shù)膯栴}，系統(tǒng)需要至少3個雷達周期才能形成新的航跡，再處理能夠得到扇區(qū)的所有信號，對收到的信號進行雷達周期一半的延遲加上計算和傳輸?shù)难舆t，一個航跡至少需要2.5 s才能新建。因此，算法可以繼續(xù)改進。設一個航空器轉向，另一個航空器正常飛行，由于雷達原因暫時無法接收到信號，算法必須在處理時預測兩個目標，計算航跡的質量系數(shù)，輸出質量好的航跡。這種情況，系統(tǒng)將對轉向的狀態(tài)進行判斷（主要是機動的狀態(tài)、位置變化速度），如若機動較快突破設計的閾值，系統(tǒng)將采用三維卡爾曼濾波對其進行預測計算，否則繼續(xù)采用馬賽克算法。這種設計的優(yōu)點還體現(xiàn)在精度的處理上。由于馬賽克算法的信息基礎是經過單雷達處理后的雷達航跡信息，除了雷達源帶來的誤差，還有單雷達處理帶來的誤差[3]，而上述算法主要針對點跡處理，加上三維卡爾曼濾波處理，算法處理精度更高，符合航空器機動的監(jiān)視情況。大多數(shù)情況下，航空器是以固定的速度和高度進行巡航，除了在終端區(qū)，航跡基本是平飛或者上升下降，機動狀態(tài)較少。這種設計可以使得系統(tǒng)在算法計算上，大部分計算都是采用馬賽克算法，小部分計算是依賴三維卡爾曼濾波。三維卡爾曼濾波雖然處理實時性強、精度高，但確實無法避免開銷較大的問題。算法的設計能從全局方面平衡兩者之間的矛盾，取得精度計算和計算量控制之間的有效配合。

在區(qū)域的分配設計上，對于區(qū)域管制系統(tǒng)將按照上述思路對目標雷達數(shù)據(jù)進行處理。對于終端區(qū)，管制對于數(shù)據(jù)的處理精度要求更高，航空器的機動情況也更多，更適合采用三維卡爾曼濾波的處理。如果完全按照上述的處理，容易造成多次處理判斷，造成無謂的系統(tǒng)開銷。因此，算法將從系統(tǒng)中獲取具體的終端區(qū)范圍，在該區(qū)域內采用三維卡爾曼濾波為預測算法。

3 軟件的仿真與實現(xiàn)

為了測試算法的預測性能和占用資源，采用C#編寫軟件，軟件實現(xiàn)對現(xiàn)場配置的5路雷達測試信號的接入、軌跡的多重同時繪制、不同算法下軟件CPU占用率的檢測，最終通過圖形界面展現(xiàn)[4-8]。

雷達數(shù)據(jù)的接入需要考慮對不同區(qū)域的多重覆蓋，并將多路雷達的HDLC信號格式轉換為UDP網絡格式，通過不同的UDP端口實現(xiàn)對不同雷達信號的區(qū)分，最終通過網絡接口進行處理。為了實現(xiàn)對比，系統(tǒng)采用4臺HPZ420工控機，其中3臺為處理終端，分別部署本方案算法驗證處理、普通馬賽克處理和正常三維卡爾曼濾波處理仿真軟件；另一臺則為顯示終端，用于對比顯示最終的處理結果。所有工控機采用一樣的硬件配置、仿真軟件在雷達數(shù)據(jù)接收處理模塊上的設計一致，以滿足系統(tǒng)對資源占用的對比。雷達數(shù)據(jù)通過協(xié)議轉換后接入局域網交換機，整個測試將基于該局域網進行模擬仿真。處理終端除了向顯示終端發(fā)送實時的軌跡處理信號，也向其發(fā)送程序的CPU占用率和內存占用的相關資源情況（參數(shù)可切換）。C#上實現(xiàn)部分代碼如下：

//初始化CPU計數(shù)器

pcCpuLoad=new PerformanceCounter（"Processor"，"%Processor Time"，"_Total"）；

pcCpuLoad.MachineName="."；

pcCpuLoad.NextValue（）；

//CPU個數(shù)

m_ProcessorCount=Environment.ProcessorCount；

//獲得物理內存

ManagementClass mc = new ManagementClass（"Win32_ComputerSystem"）；

ManagementObjectCollection moc=mc.GetInstances（）；

以某終端區(qū)的實時雷達信號處理為例，如圖1所示。從圖中可以看出，本算法計算的軌跡介于普通馬賽克算法和正常三維卡爾曼濾波算法軌跡之間，模擬程度較為均衡。而在系統(tǒng)開銷上，本算法只需要13.2%，甚至比普通馬賽克算法29%還低，這是由于該目標當前處于終端區(qū)，該區(qū)域雷達覆蓋較多，馬賽克算法也需要進行多重計算和切換。另一方面，正常三維卡爾曼濾波的開銷是三者之中最高的，這主要因為終端區(qū)目標機動情況較多?？傊?，可以看出，在仿真效果上，算法能較為均衡地計算處理雷達數(shù)據(jù)，并且資源開銷降低。

圖1 仿真顯示圖

4 結束語

本文從實際出發(fā)，基于傳統(tǒng)的雷達數(shù)據(jù)處理設計算法，提出一種改進的雷達數(shù)據(jù)處理方法。通過針對目標的實際情況進行靈活地分類處理，使得系統(tǒng)的處理開銷小、算法軌跡計算較為準確。方案最終通過C#進行設計仿真，效果如設計預想，可為空管自動化雷達數(shù)據(jù)處理方面的研究提供參考，也為空管自動化系統(tǒng)日常保障的數(shù)據(jù)處理分析提供思路。