AirNet空管自動化系統中的飛行計劃及雷達數據故障處理

中國民用航空東北地區空中交通管理局黑龍江分局 鞠涵

空管自動化系統能夠接收處理多部雷達數據，接收處理各種報文，實現雷達目標與飛行計劃的相關，提供面向管制員的雷達數據綜合顯示及飛行計劃顯示服務。近年來，民航業飛速發展，航班流量不斷增長，空中交通管制的壓力隨之加大，為了確保雷達數據及飛行計劃數據及時準確的集成顯示給管制員，空管自動化系統的維護是至關重要的一環，進而保障管制員指揮航班高效穩定飛行。因此，規范自動化系統的維護流程，優化自動化系統結構及工作方式，分析空管自動化系統飛行計劃處理、雷達數據處理、軟硬件及附屬設備的常見問題，對保障空管安全運行具有重要意義。

黑龍江空管分局現有兩套自動化系統，一是AirNet主用空管自動化系統又稱AirNet7.5系統，二是AirNet備用空管自動化系統又稱AirNet5.8系統，均由成都民航科技發展有限公司即民航二所開發，擁有完全的自主知識產權，符合中國民航相關行業標準。本文結合實際工作案例,主要介紹系統維護中經常出現的兩種典型的數據處理故障。

1 AirNet系統結構（以主用自動化AirNet7.5系統為例）

AirNet空管自動化系統的服務器配置及席位配置，系統基于三網架構，服務器主要有SDFP(監視數據前端處理子系統)、MSDP（監視數據處理子系統）、FDP(飛行數據處理子系統)、DRP（數據記錄和回放子系統）、DCP（數據同步子系統）、FMP（流量處理子系統）、BSDP(旁路監視數據處理子系統)、DBM(參數配置終端)、SDD(綜合數據顯示子系統)、FDD(飛行計劃顯示子系統)、SMC(系統監控終端)、SDQS(雷達數據質量檢測終端)、一組核心交換機、一組接口交換機、四組區調席位交換機、一組塔臺席位交換機、一組進近席位交換機分別部署在航管樓三樓小機房，九樓設備間，三樓值班室及各個管制現場。

2 故障分析處理

2.1 飛行計劃處理有關故障描述

故障：AirNet5.8自動化系統情報區配置異常導致飛越航班過點時間解析錯誤。

具體現象：2021年3月20日流量席反映飛越航班CCA058安克雷奇-北京，系統計算進交接點時間不準確。FPL領航報文中到情報區邊界時間項為0633，該航班實際起飛時間為0709，按照領航報文計算該航班的進境時間為13:42，而系統計算進交接點時間為12:59。當日值班員查看系統配置MAGIT點未勾選情報區邊界點，建議流量席適當調整PANCZBAA城市對進邊界點時間，有助于系統計算過點時間準確性，并勾選SIMLI、ARGUK、MAGIT為情報區邊界點；21日流量席反映所有飛越航班計算進交接點時間與實際相差過大。值班員查看航班計劃及更改動態觀察情況一致，隨即展開處理并聯系工程師協助排查，查看DBM界面系統參數配置發現系統情報區配置為空，配置情報區為ZYSH發布參數并重啟進程后恢復。

問題分析與改進：首先當時在用的AirNet5.8自動化系統計算進交接點時間是根據情況不同會優先采用不同來源的時間數據項進行計算，使用規則如表1所示。

表1 AirNet5.8自動化系統計算交接點時間數據項使用規則Tab.1 AirNet5.8 rules for the use of time data items for automatic system calculation of handover point

20日情況解析：對于航班CCA058，對照優先級：（1）由于基礎資料中MAGIT點未勾選為情報區邊界點，故系統未使用編組18EET項進行計算；（2）系統檢查經驗數據中記錄的PANC到MAGIT點的時間數據為350min；（3）基礎資料城市對中到進交接點時間為330min，兩者時間差值未超過45min使用經驗數據，CCA058的實際起飛時間07:09，推算得出進交接點時間為12:59。

20日故障處理：據此當日值班員告知流量席同事適當調整PANCZBAA城市對進邊界點時間，有助于系統計算過點時間準確性，并建議流量席修改SIMLI、ARGUK、MAGIT為情報區邊界點。

21日情況解析：流量席反映大量飛越航班出現系統計算進交接點時間與實際相差過大。

以航班KAL8040為例，航班實際起飛時間04:49，實際起飛到情報區邊界時間應為672min，以此推算航班KAL8040到邊界點SIMLI時間應在16:01分左右。21日系統計算到SIMLI點時間為05:15，按照系統計算航班起飛僅用26min就飛到邊界點SIMLI，這顯然是錯誤的。

通過分析日志，比對該航班FPL報文發現：系統計算到情報區邊界點時間錯誤的使用了FPL報文編組18EET項的第一個到情報區邊界時間KZMP0026，未能正確解析并使用ZYSH1112。技術人員查看系統參數配置，發現自動化系統DBM中情報區參數配置項缺失，導致系統未能正確識別情報區ZYSH，并且系統軟件存在BUG，當系統未識別到配置的情報區編碼，默認使用編組18的第一組到情報區邊界時間，該邊界點不是管制所需要的，導致系統解析飛越航班到情報區邊界點時間錯誤。

21日故障處理：通過配置AirNet5.8系統系統情報區為ZYSH后發布重啟FCS進程,系統能夠提取FPL報文18組中的EET項的ZYSH情報區數據，同流量室確認過點時間解析已正常。

改進意見：（1）由于自動化系統數據處理計算量較大，配置參數條目與種類冗多，因此參數的配置與更改流程需更加嚴謹，技術人員在修改參數配置時應進行充分的隱患梳理，避免出現類似修改一個參數配置出現一系列的系統錯誤或BUG等問題。（2）與成都民航空管科技發展有限公司溝通對情報區參數識別進行優化，DBM情報區參數配置為空時，應不使用編組18中到情報區邊界時間，故障情形中默認使用第一組到情報區邊界時間的邏輯會導致不必要的錯誤，存在一定運行隱患。

2.2 雷達數據處理有關故障描述

故障：AirNet7.5自動化系統航跡高度融合處理異常導致目標高度跳變。

具體現象：2022年2月15日（北京時間），區調反映CES6093出現高度跳變，經回放，7.5系統融合信號受長春單雷達影響，11:14:28由8900跳變9140，5.8系統融合信號正常。通過優化高度融合算法解決目標跳變問題。

問題分析與改進：分析雷達原始數據及監視數據處理相關日志，如表2所示。

表2 雷達原始數據及監視數據處理相關日志Tab.2 Relevant logs of radar raw data and monitoring data processing

經過日志分析發現AirNet7.5自動化系統現場運行過程中高度融合存在異常，高度融合算法存在一定漏洞，技術人員調整高度融合算法，如表3所示。

表3 高度融合算法Tab.3 High fusion algorithm

通過添加少數服從多數過濾掉少數數據，結合上述場景，優化后處理結果為如表4所示。

表4 優化后處理結果Tab.4 Optimized post-processing results

改進意見：（1）建議廠家技術人員優化高度融合算法，修改在所有單監視源均與系統航跡爬升狀態不一致時，不直接選信任雷達的高度，避免后續由于單雷達不穩定數據產生跳變。（2）監視數據處理異常對管制運行有較大風險隱患，極端情況下可能影響管制員對航空器飛行態勢的判斷，技術保障部門應對類似問題保持敏感度，發現問題及時聯系廠家工程師共同排查，必要時申報技術中心和地區通導部，通過緊急補丁解決。

3 結語

作為國民生產支柱產業之一的交通業，民航業飛速發展意味著空管飛行流量驟增，必須在不斷發展的過程中保障空中管制的準確高效，空管自動化系的維護與故障處理是空管技術人員最重要的課題，只有熟悉了解運行現場的系統結構與工作原理，才能更好地處理突發故障，本文針對飛行數據及雷達數據的信息處理兩大重要方面中出現的問題，通過流程分析，定位故障原因，提出解決方案及優化建議，更好地維護自動化系統安全運行，保障空管安全。