萊斯空管自動化系統雷達航跡與飛行計劃無法自動相關典型案例分析

路 雯

（民航河北空管分局，河北 石家莊 050802）

0 引言

在日常工作中，筆者經常接到管制部門反映的一些問題，其中包括自動相關問題、進程單打印問題、自動發報問題等等，在這些問題中，雷達航跡和飛行計劃自動相關問題占有相當大的比重。若某個航班不能實現自動相關，此時需要管制員在飛行動態顯示席屏幕上找到與計劃二次代碼一致的航跡，并手動進行相關，這會浪費管制員一定的時間和精力。因此，自動相關功能非常重要。本文就雷達航跡與飛行計劃無法自動相關這類問題選出幾個典型案例進行分析講解，供大家參考。

1 雷達航跡和飛行計劃相關的定義及限制條件

所謂雷達航跡和飛行計劃相關是指在雷達數據融合后的綜合航跡和飛行計劃功能產生的飛行計劃之間建立一種鏈接關系，從而在飛行動態顯示席（下文統稱SDD）為雷達航跡掛上全標牌，為管制員提供航空器的位置、航班號等信息。這種鏈接關系可以通過系統的自動相關功能來實現，也可以通過管制員的人工干預來完成。

為了避免自動相關出錯，進行配對判斷時，雷達航跡和飛行計劃需同時滿足如下檢查條件，才認為兩者應該進行配對，有一條不滿足則不會自動相關：

(1)計劃的狀態不屬于靜止、未來、取消、終止之一。

(2)航跡以前沒有被人工相關、去相關過。

(3)航跡位于飛行情報區內，并且已經穩定更新了3個周期以上。

(4)航跡與飛行計劃都具有二次代碼，并且兩個二次代碼相同。

(5)和計劃的二次代碼相同的航跡同時只存在一個；和航跡的二次代碼相同的計劃同時只存在一個。

(6)航跡位置在飛行計劃所描述的計劃航路附近40公里以內。

(7)推算出航跡將要到達最近的計劃航路報告點的時刻，與計劃中的預測時刻比較，誤差在1小時之內。

(8)航跡的飛行方向與本段計劃航路的指向相差在70度之內。

在值班過程中，比較常見的影響雷達航跡和飛行計劃自動相關的案例經筆者總結，大致有如下幾種：

(1)未收到計劃的相關報文或者相關報文格式錯誤系統無法解析，導致計劃的狀態未能及時更新，不符合自動相關條件。

(2)有其他雷達航跡正在使用相同二次代碼，導致計劃找航跡失敗；有其他計劃正在使用相同二次代碼，導致航跡找計劃失敗。

(3)有其他符合自動相關條件且具有相同二次代碼的雷達航跡提前使用了航班計劃，導致正常航班起飛時計劃已經結束。

除上述常見案例，筆者也遇到一些比較特殊的案例，下面就這些案例進行分析說明，供大家參考。

2 典型案例分析

2.1 案例一

案例重演：UTC（下文統用此時間）時間10：15，塔臺管制員反映出港航班HBH3209/A3023起飛幾分鐘后才自動相關。反映時刻距此航班起飛已經過了40多分鐘。筆者在SDD查看，發現此航班已經飛出管制區，在飛行計劃處理席（下文統稱FDOP）查看，發現計劃狀態為終止。

案例的實際分析處理過程：首先，筆者將管制員手動拍發起飛報中的實際起飛時間設為初始時刻，在SDD上進行回放，發現09：30時，SDD上出現二次代碼為3023的雷達航跡，但是一直到09：33此航跡才與計劃自動相關。

繼續分析未及時自動相關的原因。首先考慮是否存在相同二次代碼的其他航跡或計劃導致航跡與計劃匹配失敗。觀察SDD上是否有此航班的二次代碼重復告警，在FDOP查找是否有相同二次代碼的其他航班的計劃，結果均未找到，初步排除因存在相同二次代碼的航跡或計劃導致此航班未能自動相關。

借助系統日志分析。切換到系統后臺，打開終端窗口并遠程登錄主用飛行數據處理服務器（下文統稱FDP），進入計劃日志目錄，找到相關日志并查看09：30時刻的記錄，所用命令如下：

通過閱讀日志，發現此航班在起飛時刻計劃狀態處于正常的預激活狀態，排除計劃狀態未處于預激活狀態而導致不能自動相關這個原因。日志原文如下所示，其中“status=PREA”字段表示計劃處于預激活狀態：

遠程登錄到主用雷達數據處理服務器（下文統稱RDP），進入雷達日志目錄，找到相關日志并查看09：30時刻的記錄，所用命令如下：

通過閱讀日志，發現3023航跡在被雷達掃描到的時刻，航跡找計劃，提示“在多份中沒有找到合適的計劃”。說明確實有重復二次代碼的計劃存在。日志原文如下所示：

返回計劃日志，查找有關二次代碼3023的記錄。命令如下：

從日志的09：30記錄往回看，發現此條記錄，日志原文如下所示：

此記錄說明，在09：24時，管制員修改TWB9602航班的二次代碼為3023。于是查找FDOP中有關TWB9602航班的報文。但發現此航班的起飛報中的二次代碼已改為A3020，由此推測管制員在此航班起飛前再次修改了二次代碼。為驗證此推測，繼續查找日志的相關記錄，命令如下：

從09：24時刻往后看，發現在09：32時刻，果然有一條管制員修改TWB9602航班二次代碼為3020的記錄，日志原文如下所示：

由上面一系列日志證實，確實是因為HBH3209航班在雷達掃描到的時刻，存在相同二次代碼的計劃，系統不能確定使用哪條計劃，從而導致航跡與計劃不能自動相關。后來管制員在09：32時更改TWB9602航班計劃的二次代碼為A3020，航跡3023重新搜尋并找到唯一匹配的計劃，從而在09：33時自動相關上了。

案例總結：上述案例是一個二次代碼重復導致無法自動相關的特殊案例。因為一般遇到的二次代碼重復的情況，都是可以很直觀的在SDD或FDOP中查出。而此案例，因為管制員在筆者接到問題時，已經更改了TWB9602航班的重復二次代碼，從而給后續分析帶來些許困難。此案例也反應出管制員正確填寫二次代碼的重要性。

2.2 案例二

案例重演：08：50，管制員反映一架出港航班B9719/A4110未自動相關，另一架出港航班B9563/A4122未相關對正確的計劃。

案例的實際分析處理過程：接到問題后，筆者立刻查看SDD，此時兩架航班已經起飛且高度超過1000米。其中，B9719航班的標牌處于簡標牌狀態，B9563航班的標牌正常相關但是落地機場是石家莊機場。

查看FDOP，發現這是兩架轉場航班，從邯鄲飛來石家莊，再飛回邯鄲。兩航班出港計劃的二次代碼仍延用進港計劃的二次代碼，計劃處于激活狀態，收到的飛服值班員手動拍發的落地報和起飛報時間正確，格式正確。

通過回放發現，這兩架航班在進近時大概下降到幾十米，未經著陸，即又爬升，整個過程未曾從SDD上消失，上升時仍掛著進港時的全標牌。于是判斷，航班起飛后仍相關著進港時的計劃，是因為雷達沒有探測到兩航班航跡消失，系統不認為計劃結束，因而起飛時仍然掛著進港標牌。繼續回放發現，B9719航班在08：42：00時去相關了，于是遠程登錄到主用FDP，進入計劃日志目錄，查找有關相關的記錄，所用命令如下：

查到的日志原文如下所示：

由日志我們可以看到，08：42分時，管制員進行了操作，“flag=4”，說明是人工去相關。系統對于人工去相關的航跡是不會再去搜索計劃與其相關了，所以，從管制員反映情況到現在，B9719一直未再自動相關，是正常的。

再繼續回放發現，B9563航班在09：06：18時由進近管制員進行了一次釋放，一次釋放之后，標牌立刻由全標牌變為簡標牌，下一秒又自動相關，變為正確的出港計劃的全標牌。針對這一現象，繼續查找計劃日志，命令如下：

grep B9563 AllLog2014010909.log|grep 201401090906<== 查找有關B9563航班的在1月9日09：06分的日志記錄

查到的管制員進行一次釋放操作的日志原文如下所示：

管制員一次釋放后航跡與計劃自動相關的日志原文如下所示：

由日志我們了解到，在09：06：18時，由于管制員的一次釋放操作，使得B9563航班的進港計劃自動結束，與此同時，航跡與進港計劃自動去相關（flag=2）。去相關后的航跡開始尋找與之匹配的計劃，七秒之后，與之有相同二次代碼的出港計劃與航跡自動相關（flag=1）。

B9563航班直到管制員一次釋放后才結束進港計劃并自動去相關，是因為系統對于處于管制狀態的計劃是不會自動結束的，即使它已經收到了飛服值班員人工拍發的落地報。

案例總結：筆者在此次案例的處理過程中，通過查看回放錄像，找到事件轉變的關鍵時間點，一步步的尋找日志中的記錄，從而找到回放錄像中發生的一系列現象的原因。可見，有時通過回放錄像來分析也不失為一個快捷的途徑。通過此案例，也可以看到管制員操作的不妥之處，對于此類特殊飛行的航班，管制員若想自動相關，正確的作法是對航班進行一次釋放，或者聯系飛服值班員人工結束進港計劃，而不是人工去相關。

2.3 案例三

案例重演：04：45,管制員反映JAA830/A0767普吉—石家莊進港航班無法自動相關。

案例的實際分析處理過程：經筆者查看，此航班已經進入飛行情報區，但計劃狀態仍為靜止狀態，靜止狀態的計劃是不能與航跡自動相關的。在系統設置里，計劃航跡距離管制區邊界90分鐘時，會使計劃由靜止狀態轉變為預激活狀態。顯然，此航班的計劃沒有按正常生命周期進入預激活狀態。

04：48時，觀察到計劃狀態轉變為預激活狀態，但是航跡與計劃仍然沒有自動相關。此時航班按正常航路飛行，并未偏航，于是，借助RDP里的相關日志進行分析，命令如下：

日志原文如下所示：

語句“tdob_time=81149(must<==3600 or>=24*3600-3600)”意為計劃航跡與實際航跡的距離超出1小時的系統設定值。

由此我們可以看到，當04：48計劃轉變為預激活狀態時，航跡找到了計劃，但是因為計劃航跡與實際航跡的距離超出了1小時的系統設定值，因此不能自動相關。此種情況一般是航班偏航或者系統計算過點時間錯誤所致。此航班已經觀察到未偏航，因此，推斷系統計算過點時間錯誤。而過點時間計算錯誤，一般要從收到FPL報的首次過點時間計算開始查找原因。用以下命令查找日志記錄：

通過查找發現如下解析過點時間的日志：

由日志可以看到在解析第二個航路點“NOB”時，上一個點到此點的時間和此點到下一個點的時間都是一個多小時，這是不正常的。在數據庫中查找NOB點的坐標，與航圖上坐標對比，發現坐標確實與實際不符。分析到此，即可解釋此航班沒有正常預激活并自動相關的原因了，是因為數據庫中的航路點坐標不正確。

案例總結：此案例中通過航班沒有正常預激活與自動相關，推斷出過點時間計算錯誤，并由此查找到了數據庫中收錄數據的錯誤。由此可見，無法自動相關也可能是系統數據不完善造成。分析自動相關案例，可以找到數據庫中收錄數據的不足。

3 結論與建議

通過上述三個案例，我們可以了解到，遇到雷達航跡與飛行計劃無法自動相關的情況，一般有如下幾種分析方法：

(1)在FDOP看此航班的報文是否齊全且正確。

(2)在SDD席位看有無與此航班二次代碼相同的航跡。

(3)在FDOP看計劃條或報文里有無與此航班二次代碼相同的計劃。

(4)在FDOP看航班的計劃狀態是否滿足自動相關的條件。

(5)分析FDP服務器中的計劃日志和RDP服務器中的相關日志，來找到關鍵事件的記錄。

(6)觀看回放錄像，查找關鍵時間點是否有事件發生，再結合日志進行分析。

上述三個案例，我們也可以總結出影響雷達航跡與飛行計劃自動相關的比較特殊的因素有如下幾點：

(1)管制員填入的二次代碼不正確或者填入的時機不對。

(2)航空器在做某些特殊的飛行，致使其航跡不能滿足自動相關的條件。

(3)管制員對軟件運行機制不太熟悉，未能使用正確的方法來使航跡與計劃自動相關。

(4)系統數據庫里的資料不準確或者不完善。

鑒于雷達航跡與飛行計劃自動相關的重要性，作為維護空管自動化系統的技術人員，必須深入學習雷達航跡與飛行計劃相關的條件機制。只有對每一例無法自動相關案例認真剖析、總結，才能在日常工作中遇到類似的情況時及時、準確的處理解決。管制員作為軟件的使用者，也應該時常復習軟件操作手冊，按照軟件的使用說明，在正確的時間用正確的方法對軟件進行操作。同時，雙方也應加強交流溝通，把各自的經驗和心得進行分享與傳授，這樣，才能更好的保障飛行安全。

［1］萊斯自動化系統現場值班維護手冊[Z].南京萊斯信息技術股份有限公司,2013.