雷達數據在空管自動化系統中的處理方法研究

劉邦強

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

0 引言

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

1 空管自動化系統雷達數據處理方法

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

2 方法研究

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

2.1 單雷達數據處理

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

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

2.2 改進型馬賽克算法

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

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

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

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

3 軟件的仿真與實現

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

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

//初始化CPU計數器

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

pcCpuLoad.MachineName="."；

pcCpuLoad.NextValue（）；

//CPU個數

m_ProcessorCount=Environment.ProcessorCount；

//獲得物理內存

ManagementClass mc = new ManagementClass（"Win32_ComputerSystem"）；

ManagementObjectCollection moc=mc.GetInstances（）；

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

圖1 仿真顯示圖

4 結束語

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