空管自動化航跡丟失分析與雷達融合機制探討

宮昕昱

摘? 要：雷達融合處理是ATC自動化系統最核心的功能，也是自動化系統穩定運行的根本。文章以民航二所空管公司的AirNet自動化系統在實際運行中發生的一起航跡丟失案例，深入分析了異常發生的過程及導致異常的原因。在此基礎上對自動化系統的雷達融合機制進行了一定程度的探討，提出了一些建議。

關鍵詞：雷達融合處理;AirNet自動化系統;航跡丟失

中圖分類號：V355.1? ? ? ? 文獻標志碼：A? ? ? ? ?文章編號：2095-2945（2019）27-0017-04

Abstract： Radar fusion processing is the core function of ATC automation system， and is also the basis of stable operation of automation system. In this paper， a case of track loss occurred in the actual operation of AirNet automation system of air traffic control （ATC） companies of civil aviation is taken as an example， and the process of abnormal occurrence and the causes of abnormal occurrence are analyzed in depth. On this basis， the radar fusion mechanism of automation system is discussed to a certain extent， and some suggestions are put forward.

Keywords： radar fusion processing; AirNet automation system; track loss

引言

ATC空管自動化系統是空中交通管制員最主要的手段之一[1]。雷達融合處理是自動化系統最核心的功能，其穩定性極大程度決定了一套自動化系統在實際運行中的性能表現和用戶體驗。近年來，隨著終端區飛行流量急速增長，以及高空移交區管中心，自動化上的雷達航跡呈現出更加復雜高低扇飛行姿態。雷達航跡在位置上的接近，給自動化雷達融合處理增加了難度。而單雷達信號由于覆蓋范圍、雷達頭故障、傳輸等原因帶來的信號不穩定，也對自動化系統雷達處理的穩定性和強健度提出了考驗。

2015年5月，民航二所空管公司AirNet自動化系統在中國民航空中交通管理局下屬的包括重慶、廈門在內的九地空管分局和空管站投入運行。本文基于多年對該系統的保障維護實踐，以2015年9月30日在重慶空管分局發生的一起較為典型又極具研討價值的AirNet系統航跡丟失案例展開分析，進一步探討了自動化系統中雷達融合相關機制的目標與方向。為下一步AirNet系統的軟件改進，以及其他空管單位的AirNet系統運行提供一些建議與參考。

1 AirNet雷達航跡丟失現象

2015年9月30日20：06，重慶區域（區調）管制席位反映AirNet自動化中，從恩施ENH的進港航班CHB6252標牌（計劃應答機為A5670）與實際應答機為A5070的目標進行了錯誤相關，而實際應答機A5670的目標（航班號本應為CDG8792）的雷達航跡在AirNet自動化上沒有出現。而在Telephonics自動化中，兩個目標的雷達航跡均顯示正常。對目標丟失過程進行回放與梳理如下。

在多雷達下，19：53：00，應答機為A5070（高度8400米）和A5670（高度7800米）的兩個航班同時從東面向本場飛行，高度差為600米，水平間隔為5公里。其中A5070應屬于成都區管高扇指揮，A5670為武漢移交過來的低扇航班。19：56：09，航跡A5670完成與其計劃CHB6252自動相關。而A5070未能正常完成自動相關，如圖1所示。

19：56：35，多雷達下，A5670航跡的二次碼突然變為A5070，系統出現DUPE告警。隨后系統將兩個目標判斷為A5070這一個航跡，從圖2可以看到，19：56：44，5070和5670的航跡均進入推測航跡狀態，同時A5670的航跡位置跳變至A5070的位置上去，而原A5670的尾跡點已經中斷。

19：56：57，航跡結束推測狀態，此時系統徹底將兩個航跡判斷為A5070這一個航跡并將其融合，同時重新開始跟蹤這個新的A5070的航跡位置;在圖3可以看到，A5070之前的尾跡點消失，證明這個航跡是重新開始計算的。同時，原本屬于的標牌CHB6252也錯誤相關至A5070，如圖3所示。

19：57：12，區調管制員根據標牌航班號CHB6252將目標接管。此時，管制員在SDD上接管的其實是不該屬于他指揮的A5070目標，他并不知道真正該他指揮的A5670目標其實就在A5070下方600米處，但在15秒前已經丟失。

2 航跡丟失原因分析

從上述的異常過程可見，9月30日的航跡丟失是一起連環性的自動化系統處理異常案例，而不僅僅只是單個航跡因為雷達信號原因導致的短時間航跡丟失。對該異常情況根據時間順序進行分解，可以拆分為以下四個方面的問題：

（1）為何A5070沒有正常自動相關？

（2）為何多雷達下，A5670的二次碼會突變為A5070？

（3）為何兩個目標二次碼一致后，存在那么明顯的高度差，系統卻將兩個目標判斷為了一個航跡？

（4）為何在融合出現錯誤后，A5670對應的CHB6252飛行計劃與標牌會錯誤相關至A5070？

根據異常情況的4個方面問題，對異常原因進行逐級的分析。

2.1 A5070自動相關異常

首先需要分析的是：為何A5070沒有正常完成與飛行計劃的自動相關？AirNet系統對進港航班的自動相關機制為：進港航班在收到DEP起飛報后，將報中的二次代碼自動填入計劃;當進港航班的航跡進入相關區（或外擴區）后，觸發相關判斷，完成自動相關。

A5070與A5670從東面幾乎同時進入外擴相關區，那么按照機制兩個目標也應該幾乎同時完成與計劃的相關。對A5070的DEP報文進行查詢，其報文內容如圖4所示。

從DEP報文可以看到，報文中的二次代碼填寫格式存在錯誤。根據AirNet系統FDP的處理情況提示“編組7[5070]不是5為的SSR模式和編碼，解析中止”可知，報文錯誤格式的二次代碼填寫，導致系統對該DEP報解析失敗，A5070對應的飛行計劃中沒有二次碼，從而造成A5070目標無法正常相關。

2.2 A5670融合航跡二次碼突變

本次異常情況的直接原因是在多雷達融合下，目標A5670的二次碼突變為A5070。多雷達融合信號是單雷達信號融合處理后的結果，多雷達出現異常往往與單雷達有關。基于此思路，對單雷達信號依次進行回放。

根據目標位置，在出現信號丟失的前后時間段中，可以發現目標的單雷達為：恩施雷達（ES）、張家界雷達（ZJJ）和銅仁雷達（TR）。其中恩施雷達和銅仁雷達在故障時刻及其前后時間段中信號均正常。但張家界雷達信號出現問題。

首先，在異常時刻之前19：53：45，張家界雷達信號下，目標A5670發生第一次突變，二次碼變為A5470，高度跳變為7290，如圖5所示;然后目標二次碼保持在A5470，直至19：55：10，才又重新恢復為5670。

19：56：34，張家界單雷達的A5670目標發生第二次突變，二次碼變為了A5070（如圖6所示）。1秒后，多雷達的A5670目標二次碼也變為A5070，單雷達信號突變時間與多雷達融合信號突變時間完全吻合。可以確定多雷達信號二次碼突變就是張家界單雷達信號導致。

2.3 A5070與A5670錯誤判定與融合

解決了二次碼突變的原因后，接下來需要分析的是，為什么二次碼突變成一樣，系統就會將兩個目標判定并融合為一個航跡？

目前在AirNet自動化系統中，為了抑制目標分裂，系統通過一個區域配置文件associate.cfg中劃設的區域及其參數設置，去對“兩個相同二次碼航跡是否為同一個目標”進行判斷。發生異常時的associate.cfg設置為：在3500-8500高度層中，兩個目標必須滿足水平距離小于8公里，垂直距離小于250米，才會判斷為同一目標。從發生異常時的兩個目標的高度差和水平距離看，雖然水平距離（5公里）小于8公里，但垂直距離（600米）并未小于250米，因此按照此機制執行，不應該將兩個目標判斷為一個目標。

但當筆者進一步觀察associate.cfg設置的區域邊界時，發現associate.cfg區域并沒有覆蓋到異常發生時的目標位置，如圖7所示。因此可以判斷，9月30日異常發生時，兩個目標沒有進入associate.cfg區域，因此上述判斷機制沒有生效。系統按照默認值水平距離8公里，垂直距離300米去進行融合判斷，從而將兩個航跡融合為了一個航跡。

2.4 CHB6252標牌錯誤相關

由于發生了融合錯誤，系統將兩個目標判斷為了一個目標。因此系統將A5607的航跡號賦予給了A5070。FDP處理時，發現已經相關的飛行計劃CHB6252，雖然二次碼有變化，但航跡號未變，因此沒有去相關，而保持相關。從而導致CHB6252錯誤相關在A5070上。

3 雷達融合機制探討

根據原因分析的四個方面，除了第一點的未正常相關是由于報文內容有誤，其余三點均與AirNet系統的軟件處理機制，尤其是雷達融合機制及其配置有關。在高空移交后的高低扇運行模式下，9月30日這樣的兩架航班上下層同向飛行的飛行姿態經常存在。那么自動化系統需要什么樣的處理機制，去有效地避免同類異常情況再次出現？根據上述異常原因，分別從多雷達融合選擇機制，相近航跡判定，計劃與航跡號的關聯這三個環節展開探討。

3.1 多雷達融合的二次代碼選擇

在9月30日的異常案例中，AirNet系統在多雷達融合處理中存在一個明顯的問題：在異常時刻三部單雷達覆蓋目標，而恩施和銅仁兩部雷達的二次碼都是正常的情況下，融合處理為什么偏偏會采納不正常的張家界的單雷達信號？這一問題涉及多雷達融合的二次碼選擇機制。

在多雷達的融合處理中，需要對航跡位置、二次碼、高度、速度這四項進行融合處理[2]。其中，航跡位置可以參照多部雷達的位置最終判斷出一個中間值;高度可以對比多部雷達的高度差進行平均計算;速度可以通過單獨計算融合信號的速度來規避單雷達的影響。唯有二次碼，多雷達融合時只能是選擇某一部單雷達提供的二次碼數值。根據自動化系統的處理機制，系統在目標出現的第一時間，會選擇首先探測到該目標的單雷達提供的二次碼。那么當這部雷達的二次碼出現錯誤時，要如何確保融合雷達的二次碼不受影響？

筆者認為，在多重雷達覆蓋且所有單雷達平均權重前提下，“少數服從多數”的二次碼選擇機制是確保融合雷達正常的正確處理方式。多雷達在航跡更新時，判斷當前選擇的單雷達二次代碼與其他單雷達二次碼是否一致，若不一致則選擇其他單雷達的二次碼作融合使用。這樣，一個航跡只要在三重雷達覆蓋下，且兩部單雷達不同時出現二次碼跳變，則基本可以確保該航跡融合信號的二次碼正確穩定。這也是雷達多重覆蓋的存在意義之一。如圖8所示，對9月30日的情況在該機制下進行模擬，即使張家界雷達出現二次碼突變，融合雷達信號也不會受到影響。而融合信號二次碼若不發生突變，便不會有后面的融合和相關一系列錯誤發生。

3.2 位置相近航跡的融合判斷

在AirNet自動化系統中，對于兩個航跡位置接近的目標，系統會根據配置管理DBM上的一個區域配置文件associate.cfg里設置的融合條件，去判斷兩個目標究竟是兩個真實的航跡，還是一個航跡產生的分裂。這一機制的引入，很大程度地避免了雷達航跡分裂和假目標的出現。

從另一方面，雖然AirNet系統提供給用戶這樣一個可以靈活配置的文件，但associate.cfg的區域應該如何配置，參數如何設置才能滿足運行要求，才能避免出現本文案例的類似問題？可以從以下幾點考慮。

（1）由于區調，進近，塔臺的航空器的間隔不一致，因此在一個管制區內建議劃分多個associate區域分別為區進塔使用。這些associate區組合起來盡量能夠包含管制區所有區域范圍。同時，結合不同管制室各自的航空器安全間隔參數，對各自的associate區域的判定條件進行設置。

（2）將區調范圍的associate區域進行外擴，從而盡量避免本文案例的相近航班在associate區域外出現航跡錯誤融合的情況。

（3）associate區域不可能無限外擴，所以AirNet系統仍然需要對默認的判定值進行調整，可以考慮將其調整為與區調的設定值相同。

3.3 計劃與航跡號的關聯

從上述原因分析可知，在AirNet系統中，飛行計劃與雷達航跡相關后，會與該雷達航跡的航跡號（這個航跡號是系統在建立航跡時在后臺自動分配的編號）產生關聯。一旦該航跡的二次代碼發生變化，飛行計劃會通過與航跡號的關聯，從而保持與該航跡的相關。

這一機制的作用是：當航空器在空中由于飛行員或其他原因導致應答機二次碼改變后，自動化系統中航跡不會與飛行計劃相關。這時，AirNet系統提供了一個DS告警，提示管制員當前目標的二次碼與飛機計劃中的二次碼不一致。該功能在管制指揮中發揮了良好的作用。

但是，從本文案例中可知，一旦航跡出現融合錯誤后，飛行計劃可能會跟隨其關聯的航跡號，錯誤相關至其他航跡上去，為管制員帶來更大的誤導。在這種情況下，飛行計劃與航跡號的關聯反而成為束縛。那么這一機制是否具有存在的必要？筆者認為該問題具有進一步探討的空間。但如果能夠將各種異常狀況，有效地控制在多雷達融合選擇和相近航跡判定這前兩個環節中，那么飛行計劃與航跡號關聯便不會成為束縛，可以考慮保留。

4 結束語

雷達融合處理是ATC自動化系統的核心功能，也是自動化系統穩定運行的根本。9月30日出現的航跡丟失案例是一起典型的由于系統處理機制及其他外部原因，從而突破了系統的各個判定條件，最終導致系統處理異常的設備不正常情況。其可能帶來的風險值得我們關注。本文以該案例為契機，在對案例進行詳細梳理和深入分析的基礎上，對AirNet系統雷達融合相關機制展開了研究和探討，提出了一些建議。希望為未來AirNet系統的軟件改進，以及其他空管單位的AirNet系統運行提供一些參考與幫助。

參考文獻：

[1]賴欣，黃邦菊.空管自動化系統信息安全評估研究[J].計算機科學，2014，41（S1）：474-476.

[2]蔣乃欣，張軍，羅喜伶，等.空管多雷達數據融合系統的設計與實現[J].航空電子技術，2004，35（2）：33-35.