華泰自動化系統塔臺分區數據同步異常情況分析

陸少輝

(中國民用航空珠海空中交通管理站,廣東 珠海 519040)

0 引言

近10年來,中國民航欣欣向榮、發展迅猛,民航客機流量日益攀升,這對空中交通管制員來說是個不小的挑戰。空管自動化系統被譽為管制員的“千里眼”,同時也是通信導航監視“五大關鍵設備”之一,不僅緩解了管制員的工作壓力,更在促進空中交通安全、高效、有序運行方面發揮著重要作用。

由于塔臺管制區域與進近管制區域的分離,在安裝空管自動化系統的過程中需要設立不同的分區。塔臺分區在系統正常運行的情況下需要向進近分區同步更新數據,因此確保不同分區之間同步數據的準確性、時效性是維護空管自動化系統穩定、有效的必要前提。本文通過系統日志復盤、分析華泰空管自動化系統在運行過程中所發生的分區數據同步異常狀況,理清了華泰空管自動化系統在不同分區之間數據同步轉發的機理及系統現有缺陷,在廠家正式發布系統補丁之前提供了一種突發情況下的應急手段。這對其他空管單位對華泰空管自動化系統的運行維護過程中遇到類似情況時有著積極的借鑒意義。

1 不正常情況排查過程

1.1 情況回顧

某日,塔臺管制員反映在用華泰自動化系統[1]偶發進港航班管制接收(Accept,ACC)失敗,且界面有相似航班號(Similar Callsign,SC)告警。值班員立即檢查華泰自動化設備狀態,發現各節點軟、硬件均正常。隨后,值班員聯系珠海進近排查其分區設備,對方答復設備正常。值班員通過在華泰自動化系統上進行回放,發現管制員ACC失敗的航班均沒有相關的飛行計劃。值班員嘗試切換塔臺分區的通信服務器主備機,但未能解決問題。此后,值班員依照廠家建議進行塔臺分區設備重啟。重啟后,值班員卻發現珠海塔臺分區此時已丟失由珠海進近傳輸過來的正常綜合航跡——Normal航跡。此外,珠海塔臺分區所有席位均處于DEGD狀態且值班員無法通過人工操作將其恢復到Normal狀態。我方立即聯系珠海進近協同排查。最終,在珠海進近重新分發離線數據和切換珠海進近分區通信服務器主備機[2]后,華泰自動化系統恢復正常。

通信服務器為華泰自動化系統在珠海進近與珠海塔臺之間進行數據交互的重要服務器,也是塔臺分區的中心節點。而華泰自動化系統重要模塊如MST、FDP、SNMP等的數據都是通過通信服務器的CDP模塊在不同分區之間進行轉發。華泰自動化系統在珠海進近與珠海塔臺之間的數據交互拓撲如圖1所示。

圖1 珠海進近與珠海塔臺華泰自動化系統數據交互拓撲

1.2 排查經過

1.2.1 查詢FDP001模塊狀態

值班員對系統進行重啟后,發現珠海塔臺分區與珠海進近分區數據通信出現異常。為進一步查找系統異常原因,值班員在終端節點zhrttksupli上遠程登錄到中心節點zhrtcdp1ali,在后臺終端窗口輸入命令“start bnsio-vt”,進入狀態查詢程序,然后再輸入命令“get FDP001_OPER _STATUS”以獲取FDP001進程狀態的信息。經多次查詢,結果顯示均為“NONE”。上述查詢結果表明此時珠海塔臺分區的中心節點zhrtcdp1ali已無法獲取珠海進近FDP001模塊的狀態信息,珠海塔臺分區與珠海進近分區之間處于通信異常狀態。

在協調珠海進近完成CDP001模塊主備機切換后,值班員再次按照上述步驟查詢FDP001模塊的狀態信息,結果則為“OPOK”。此外,值班員發現此時珠海塔臺分區所有席位已經能正常顯示Normal航跡,華泰自動化系統也能通過人工操作升級到正常狀態。由此可以進一步確定此次事件就是由CDP001模塊的數據同步通信[3]存在異常而引起的。

1.2.2 查詢CDP001模塊的日志信息

由1.2.1可知,珠海塔臺分區數據出現異常的原因在于CDP001模塊。通過與華泰廠家協作,值班員通過查詢華泰自動化系統CDP001模塊的相關日志進行更為深入的調查。通過在CDP001模塊相關日志中搜索關鍵字“buffer at in index”發現,傳輸到珠海塔臺buffer的index持續增長到34 247后,重新變為0,但此后index停止增長,可知后續新增的數據都放在了index為0的位置。

在珠海進近完成CDP001模塊服務器的主備切換后,buffer的index由0開始恢復增長,且增長至一定值(該值遠小于34 247)后便會自動清0,然后再重復該過程。

1.2.3 理清華泰自動化系統的分區數據轉發機制

經向華泰廠家開發人員進行了解,值班員得知在華泰自動化的通信處理機制中,從珠海進近分區轉發給珠海塔臺分區的數據,會首先存放到一個緩存區(buffer),在符合觸發條件后才會轉發給珠海塔臺分區。而該觸發條件,由兩個控制因素決定:一是緩存區中報文的數量,二是時間。這兩個控制因素對應的離線參數,在CDP001模塊的服務器中的cdp.cfg文件里有詳細的定義與配置,分別與之對應的是SYNC_LOW_THRES_SEC(同步最低時間門限)和 TBUF_MAX_SIZE(同步報文最大數量)。

其中,SYNC_LOW_THRES_SEC的值為1 s,TBUF_MAX_SIZE的值為1 000。而以珠海塔臺分區現有的航班量來分析,珠海塔臺分區在1 s時間內收到1 000份同步報文的可能性極低。但在上述日志查詢過程中,卻出現了緩存區腳標為34 247的記錄,這明顯不符合離線參數設置的值。并且index在增長到34 247后,接下來新增的數據均存放在緩存區腳標為0的位置即腳標不再有增長,這表明當前華泰自動化系統CDP001模塊的緩存區處理機制存在一定缺陷。

2 原因分析

由華泰廠家開發人員提供的信息可知,34 247為系統緩存區buffer的極限容值。由緩存區buffer的index增長到34 247后新增數據均存儲在index=0位置的現象,可以判斷出緩存區buffer已發生溢出[4]。

在計算機系統中,當數據量存滿存儲分區而未做清理時,新進的數據都會存儲在最大值的下一個值,但因為位數不夠,即表現為存儲在index為0的位置。例如:一個4位二進制,最大值為1111,此時新進數據按照邏輯應該存儲在10000,但因為位數只有4位,最高位的1會被丟掉,故表現為0000。而因為4位二進制的最大值為1111,所以若程序設計中不做清零處理,那么訪問到的值將永遠都是1111,也就是說無論后續新增了多少條數據,新進的數據都只會存儲在1111的下一個位置,即10000,表現出來就是一直存儲在index為0000的位置。

所以,在此次異常情況中,緩存區buffer的值在達最大值34 247后,因華泰自動化系統在程序設計中未做清零處理設計,而導致后續需要從珠海進近分區轉發到珠海塔臺分區的新數據均存儲在index為0的位置。如此一來,只要1 s內需要發送的報文份數超過1,就會出現數據因未及時被轉發即被覆蓋,從而導致珠海塔臺分區數據異常現象的出現。

3 改進措施及建議

(1)對此次事件排查出的問題,廠家已建立PCR;技術保障部將持續跟進華泰廠家問題調查及解決情況,若廠家一個月內未能找到問題根本原因,則按廠家建議采取臨時緊急補丁(即判斷buffer到達最大值后進行清理)修復此問題。

(2)基于現有的系統分區數據同步機制的缺陷,建議在修復bug的過程中考慮增大緩存區buffer的存儲空間或者引入腳標異常增長檢測機制,一旦系統檢測到異常,應當立即對緩存區腳標清零。

4 結語

隨著中國民航的快速發展,空中流量急劇增多,空管自動化系統在管制運行指揮過程中發揮的作用變得舉足輕重。作為通信導航監視“五大關鍵設備”之一,空管自動化系統出現故障時所要求的應急響應速度和時效更是檢驗每一個運維人員技能水平高低的指標。針對“塔進分離”的自動化系統使用現場,尤其是塔臺分區,在日常運行保障的過程中,值班員應當時刻高度關注空管自動化系統通信服務器轉發過來的數據同步狀況。在突發情況下,切換進近分區通信服務器的主備機可作為臨時應急手段解決故障,優先保障管制指揮不中斷。除此之外,值班員應當加強業務培訓,提升個人技能水平,要深入理解系統工作原理,能通過分析系統日志查找關鍵信息,快速鎖定系統的故障點,然后制定恢復系統功能的合理方案。