Aerotrac空管自動化系統RDP進程假死問題的診斷與分析

姜鵬

摘 要：自動化系統作為空管雷達設備中的核心系統，是管制員實施雷達管制所依賴的“千里眼”。目前國內多家空管單位所使用的Aerotrac空管自動化系統由美國Telephonics生產，配備多臺冗余服務器以及多條冗余網絡，具有處理能力強、安全系數高、運行穩定等優點。其雷達處理服務器（以下簡稱RDP）負責處理各路引接的雷達信號，通過濾波、加權融合，輸出平滑穩定的高精度雷達航跡，因此RDP運行穩定與否，從某種程度上決定了雷達管制能否順利有效的實施。文章，作者通過對RDP運行模式以及網絡數據包的分析，作者所在單位（以下稱某單位）RDP進程假死故障的診斷和分析，透析Aerotrac自動化系統RDP運作模式。

關鍵詞：空管自動化系統；RDP進程；假死

1 RDP網絡架構及工作原理

目前筆者所在單位Aerotrac自動化共配有3臺RDP以及3條互為冗余的網絡，每臺RDP連接其中的兩條網絡，同時只有一臺RDP處于主用狀態（Online），其他RDP處于備用狀態（Backup），主用RDP負責在其連接的兩個網上對外廣播處理后的融合航跡，備用RDP負責將主用RDP廣播的融合航跡轉發到第三個網上。

其中RDP01-03擁有依次遞減的上線優先級，即RDP01的優先級最高，RDP02優先級次之，RDP03優先級最低；3臺RDP之間通過傳遞心跳信息實現通信，RDP對外廣播的心跳信息是其他RDP判明其工作狀態的唯一依據。通過對RDP廣播的網絡包進行分析，RDP心跳數據的16進制標準格式如下：

00 03 13 00 42 00 00 00 00 53 00 00

字節1-2：本條指令的長度/4

字節3：本條指令的功能號（13代表該條指令為RDP心跳信息）

字節5：代表RDP工作的狀態，4F/42/58分別代表online/backup/loading

字節10：代表RDP的編號以及該臺RDP所接網絡的情況；其中bit0-3為RDP編號，bit4-6為各臺RDP所接網絡情況，接為1，不接為0，因此RDP01為31，RDP02為62，RDP03為53

2 RDP進程假死的故障診斷

2.1 故障現象

2016年11月27日19：09-19：10某單位Telephonics主用自動化系統故障，DP上目標中斷約9秒鐘；事發前各臺RDP工作狀態為：BOB，即RDP02為主用服務器，RDP01和03為備用服務器。故障前后經過如下：

19：09：01 RDP狀態顯示消失，并提示：PlayBack Halted，DP上大部分目標丟失

19：09：10 RDP狀態：O*B，提示RDP02掉線，RDP01變為主用，目標逐步恢復

19：10：03 RDP狀態：OOB，RDP02重新上線變為主用，目標正常

19：10：10 RDP狀態：O*B，RDP02又提示掉線，目標正常

19：10：43 值班人員手動啟動RDP02進程，RDP狀態恢復為OBB*B

2.2 故障診斷及分析

事后筆者分析了故障前后19：08：50-19：10：04期間Aerotrac系統A、B網上的網絡數據包。

階段一：即故障發生前，RDP02為主用，RDP01、RDP03為備用，RDP02廣播主用心跳及航跡數據，RDP01、03廣播備用心跳，RDP狀態：OBB，正常情況下網絡數據包在100-200之間。

階段二： RDP02故障下線，RDP02停止廣播心跳以及航跡數據，RDP01、03繼續廣播備用心跳，此時系統內沒有處于主用狀態的RDP，RDP狀態：B*B，網絡數據包驟減。

階段三： 由于RDP01上線優先級最高，當RDP01檢測不到RDP02主用心跳后，RDP01上線，廣播主用心跳及航跡數據，RDP03廣播備用心跳，RDP狀態：O*B，網絡數據包數量恢復正常。

階段四： RDP02再次上線，重新廣播主用心跳及航跡數據，此時RDP01繼續廣播主用心跳及航跡數據，RDP03廣播備用心跳，RDP狀態OOB，兩臺RDP同時在線，網絡數據包數量翻倍。

階段五：由于RDP01的上線優先級高于RDP02，因此RDP01將RDP02 kill掉，RDP02離線，RDP01繼續廣播主用心跳及航跡數據，RDP03廣播備用心跳，RDP狀態：O*B。

基于上述分析，我們可以得出，故障之前RDP02為主用狀態，因RDP02異常導致未能向外廣播航跡以及心跳信息，根據優先級情況，RDP01嘗試上線作為主用，此時RDP02進程并未真正退出，但由于RDP01優先級較高，RDP01發現RDP02狀態仍為Online時將RDP02殺掉，此后RDP02進程處于離線狀態。從RDP02非正常切換至RDP01期間，目標出現丟失。

可能原因一：RDP02或因接收到錯誤的雷達數據等未知原因導致進程卡死，停止對外廣播心跳信息及雷達航跡信息。在11.27日19：09：00與19：09：01這兩秒中網絡中出現了大量異常網絡數據，且均由RDP02發出，很有可能是RDP02工作異常產生。

可能原因二：RDP02或因網絡連接出現異常，導致心跳信息及航跡數據無法正常廣播到網絡中。

3 監測程序的設計

由于Aerotrac自動化系統故障日志管理方面的薄弱，系統在出現RDP假死時未能保留足夠的日志供技術人員參考，基于這種情況，為了排查上述兩種可能導致RDP假死的原因，筆者利用Shell腳本編寫了監測腳本，為了減少監測腳本對RDP運行的影響，筆者將該腳本運行在飛行計劃處理服務器（FDP）上，通過UNIX系統rsh遠程訪問指令，實現對RDP狀態的監測，腳本主要功能如下：

（1）定時監測RDP01、RDP02的網絡連接情況。

（2）定時監測RDP01、RDP02 mrt、u_rcvr等進程CPU以及內存占用情況。

4 結束語

筆者針對目前珠海進近Aerotrac自動化系統RDP假死的情況進行了診斷和分析，得出了可能造成RDP假死的兩種原因，有針對性的編寫了Shell腳本實現對RDP進程以及網絡連接情況的監測，以彌補Aerotrac系統自身日志管理方面的不足。限于筆者知識經驗所限，本文介紹的內容未免有錯漏之處，懇請同行批評指正。

參考文獻

[1]張明偉，靳學梅，白紅利.下一代管制自動化系統研究與設想[J].航空計算技術，2015（04）.

[2]謝玉蘭.大區域空管自動化系統發展探索[J].空中交通管理，2011（01）.

[3]呂躍玲.航管主備自動化系統電子移交功能切換的實現[J].電子技術與軟件工程，2016（19）.