AIDC擴展系統的應用及常見故障分析

摘 要：伴隨著空中交通行業的不斷發展，航班量也快速增加，管制員的電話量在成倍的遞增，為減少當前航空管制人員的工作負荷，降低移交過程中人為錯誤率，提高航空管制效率，華東空管自主研發了AIDC擴展系統。然而在該系統的應用過程中曾多次出現因AIDC（ATC Interfacility Data Communications）報文未能及時流轉造成管制席位產生“U”告警和航班無法正常掛單問題。在出現大批航班告警的情況下，可能造成移交模式回退到以前的電話移交方式，這將造成管制保障等級降級，所以保證AIDC報文正確及時流轉的重要性可見一斑，為此該文結合日常值班中出現的故障，通過解析AIDC系統應用及其工作機制，以求提高保障部門對該類故障處理效率，保障管制工作更流暢有序地進行。

關鍵詞：AIDC報文 管制移交 U告警

中圖分類號：TP2文獻標識碼：A文章編號：1674-098X（2013）05（b）-0111-01

1 AIDC擴展系統介紹

1.1 AIDC（ATC Interfacility Data Communications）介紹

AIDC報文，國際民航組織推出的一種報文標準，在亞太地區相鄰管制中心之間實現自動化移交的電報協議。這種協議的執行必須基于雙方的空管自動化系統（管制系統）都具備處理該類電報的功能。AIDC信息種類主要有：預計邊界信息報（ABI），現行飛行計劃報（CPL），預計飛越報（EST），預先激活報（PAC），協調取消報（MAC），管制協調報（CDN），管制協調接受報（ACP）拒絕報（REJ），管制移交報（TOC），管制移交接收報（AOC），緊急報（EMG）邏輯確認報（LAM），邏輯拒絕報（LRM），多用途報（MIS），航跡定義報（TDM）。

AIDC的應用以逐步發送數據為基礎，并對應3個不同的階段：通知階段、協調階段、管制移交階段。管制AIDC功能在自動應用過程中具備人工隨時接管的功能和設置，且人工接管優先級高于自動功能。

1.2 華東空管AIDC擴展系統介紹及應用現狀

華東空管AIDC擴展系統是在華東航空管理局轄內的上海及周邊航空管制區域內，建成以自動化系統AIDC電報處理流程為核心的管制協調移交機制。現階段華東空管自動化系統（歐洲貓系統）的AIDC電報處理功能開啟，但若無相應的AIDC報文與之交互，無法實現自動移交還會產生告警，AIDC擴展系統的研發解決了以上問題。如圖1所示AIDC應用理想的方式是華東與華北空管自動化系統間的AIDC專線交互方式，只需要提供一條傳輸專線即可。而華東各省局的管制系統設備大部分都不具備AIDC電報處理功能，只能通過AIDC擴展系統模擬AIDC電報提供給上海自動化系統。

現階段AIDC擴展系統應用的結構拓撲如圖1所示：其中轉報系統是整個華東地區AFTN電報網流轉的核心系統，并接入全國AFTN網；自動化前置系統將歐洲貓需要的AFTN網的電報進行分類、篩選、整理后發往歐洲貓系統，同時轉發歐洲貓發出的電報。眾所周知電報對于管制系統就像血液對于人體一樣重要，而這些電報是由轉報系統收集經自動化前置處理，成為完全符合華東歐洲貓自動化系統（在用的自動化系統）要求的格式。AIDC擴展系統是通過轉報系統接入歐洲貓自動化系統提供其所需要的AIDC電報，目前主要完成杭州、南京方向航班自動移交。系統主要收發電報有：ABI，EST，ACP，TOC，AOC，LAM。

其中預計飛越報（EST）與管制協調接受報（ACP）；管制移交報（TOC）與管制移交接收報（AOC）邏輯上是成對關系。系統以收到的電文為基礎自動生成EST、ACP、TOC、AOC及LAM報。

系統在收到一份ABI、EST、ACP、TOC、AOC電報時，核實電報無誤的情況下，系統都會自動生存一份LAM報回給對方表示電報已經收到。否則回一份LRM報表示報文已收到但內容不正確。LAM/LRM報的責任響應時間一般為180 s（可配置參數）。超出這個時間視為超時。

系統在收到EST電報時，根據電文內容，自動生成相應的ACP報，由管制員人工確認發送或取消發送。ACP報的責任響應時間一般為5～9 min（可配置參數）。超出這個時間視為超時。

系統在收到TOC電報時，根據電文內容，自動生成相應的AOC報，由管制員人工確認發送或取消發送。LAM報的責任響應時間一般為5～9 min（可配置參數）。超出這個時間視為超時。

對于上海離港的航班，歐洲貓系統產生EST報文發給AIDC系統，AIDC系統恢復ACP等后續AIDC電報完成自動移交；對于將要移交至上海區域的（進港）航班，系統根據其從AFTN網收到的FPL報和DEP報內容，自動生成EST報文，在相應的時間內發給自動化系統。（這個時間由FLP和DEP報文內容決定）并且根據上海空管自動化系統的回應，進行后續AIDC報文交互。

2 AIDC擴展系統應用中出現的問題

2.1 故障案例

某個航路的航班產生U告警

案例1：2011年6月3日15：10，區管反映空管自動化系統出現U告警，經查實為空管自動化系統收不到相關的LAM（邏輯確認報）報導致，該電報由AIDC系統發出，經過轉報系統發送給空管自動化系統。檢查AIDC系統軟硬件正常，但是空管自動化系統無法收到AIDC系統發出的相關LAM報（主要為杭州航班），于是請求技術支持。16：00，維修中心術人員開始對AIDC系統進行深入檢查分析，發現無法激活LAM報的根本原因為無相關FPL報（領航計劃報）進入AIDC系統。技術人員發現14：00之后，由空管自動化系統前置經轉報系統發往AIDC系統的杭州FPL報（收電地址均為ZSAMAIDC，AIDC系統模擬地址），未能成功發送至AIDC系統，故造成LAM報激活失效。我方檢查相關FPL報后發現轉報系統14：00之后轉報路由指向錯誤，修改后恢復正常。

個別航班U型告警

案例2：5月2日18：30區管反映空管自動化系統某航班出現U告警，檢查發現TSTAIDC路15分鐘未收到相關ACP類電報，重啟AIDC處理進程窗口后恢復正常。

案例3：3月4日13：20區管反映空管自動化系統個別航班出現U告警。查看具體個別航班，發現轉報TSTAIDC信道中未收到相關ACP電報，且TSTAIDC信道超過1小時無ACP電報。重啟AIDC接口程序，仍無ACP電報接收。后重啟AIDC擴展系統OracleServiceAIDC服務項后恢復正常。

2.2 原因分析及對應解決辦法

案例1中因轉報系統至AIDC系統路有指向錯誤，導致系統收不到相應的FPL報文，使得相應航路出現告警。LAM報需要有EST報才能激活，而杭州的EST電報為AIDC系統自己生成，并不是由飛機起飛地發出，而自己生成EST報的必要條件是要有該航班的FPL報和DEP報，且該FPL報必須有由空管自動化系統前置系統發出（收電地址為ZSAMAIDC）經轉報系統至AIDC系統，而DEP報一般由飛機起飛地發出經轉報系統至AIDC系統，這樣AIDC系統才能自動生成相關EST電報發送至空管自動化系統，再由空管自動化系統回送至AIDC系統，才能順利激活LAM報。但AIDC系統并未收到相關的FPL電報。所以，值班員針對空管自動化系統出現杭州、南京方向航班U告警。不僅要查看有無相關航班的EST報發送至AIDC系統，還要查看有無空管自動化系統前置發出的相關航班的FPL報（收電地址為ZSAMAIDC）發送至AIDC系統。

案例2中AIDC系統時鐘或與轉報系統時鐘不同步。導致ACP電報超過其設置好的責任響應時間5～9 min，通過重啟AIDC系統服務重新同步時間來暫時解決問題。

案例3中AIDC系統Oracle Service AIDC服務故障造成，此時AIDC系統進程的監視窗口出現停滯，造成本該及時發送的ACP電報未能發出。

3 對AIDC擴展系統未來展望

對于AIDC電報自動移交的應用理想的方式是上海與華北空管自動化系統間的AIDC專線交互方式。然而目前華東各個省局還不能實現各管制系統間AIDC功能的統一，所以AIDC擴展系統將繼續應用。但AIDC擴展系統目前應用現狀比較復雜，系統接受FPL報和DEP報有些分來自歐洲貓前置系統，有些來自AFTN轉報機。并無規律可循。路由配置復雜，對排故不利，耗時長。對華東各個省局的AIDC電報模擬程度不一致，杭州、南京模擬整個移交過程中AIDC電報，對有些省局只模擬移交過程中部分AIDC電報，以上現狀和是系統設計初成時就開始延用至今造成的。若能將AIDC擴展系統的功能模塊化地合并到空管自動化系統前置系統，作為空管自動化系統前置的一部分。不僅可以解決路由配置復雜問題，而且解決不同系統減時間的同步及多套系統監視難的問題，減少值班員壓力。

參考文獻

[1]民用航空飛行動態固定格式電報格式（MH/T 4007—2006）.2006.

[2]中國民用航空行業標準（MH/T 4008—2000）.2000.