中國民用航空華北地區(qū)空中交通管理局 張宇昊

大興國際機場塔臺空管系統(tǒng)主要包括自動化系統(tǒng)、高級地面引導系統(tǒng)和流量管理系統(tǒng)等。筆者從技術保障角度，對高級地面引導系統(tǒng)（文中簡稱ASMGCS系統(tǒng)）進行了故障處置分析。按照故障現(xiàn)象、排故思路、排故步驟、排故操作、排故總結(jié)的順序針對故障處置作出了詳細的介紹，以點概面，在日后針對相似故障現(xiàn)象時能快速排故作為參考。

大興機場2019年9月25日投運以來，已兩年有余，空管自動化設備運行逐步平穩(wěn)，筆者針對大興ASMGCS系統(tǒng)出現(xiàn)的三例故障做了詳細的故障處置分析記錄，案例一介紹了席位硬件方面故障處置過程，案例二針對ASMGCS系統(tǒng)與流量管理系統(tǒng)(文中簡稱CDM系統(tǒng))交互故障情況分析，案例三介紹了ASMGCS系統(tǒng)無法創(chuàng)建進離港計劃問題，與THALES自動化系統(tǒng)交互情況分析。

1 案例一：單個席位出現(xiàn)觸摸屏不靈敏現(xiàn)象

1.1 故障現(xiàn)象

地西席位ASMGCS系統(tǒng)電子進程單界面觸摸屏觸摸不靈敏，使用鼠標操作正常。

1.2 排故思路

硬件方面，檢查觸摸屏到主機之間各部分硬件設備以及線纜是否正常；軟件方面，考慮到鼠標可以正常使用，懷疑該席位觸摸屏軟件配置未更新、系統(tǒng)有報錯或者需要重新校準屏幕。如圖1所示為觸摸屏到主機之間硬件連接情況。

圖1 觸摸屏到主機之間硬件連接Fig.1 Hardware connection between the touch screen and the host

1.3 排故步驟

（1）直連線路排查。依次分別緊固、更換連接觸摸屏的三根線纜，屏幕電源線、串口數(shù)據(jù)線、DVI線纜，測試故障是否恢復。

（2）軟件排查。檢查該席位觸摸屏軟件配置，檢查是否有軟件報錯以及檢查版本號是否為最新版本。登陸該席位節(jié)點root用戶，檢查/home/version/current目錄下atc包是否為最新版本；查看該席位/home/atc/bin下是否生成core文件，core文件里有系統(tǒng)報錯信息；按照校屏操作步驟重新校準觸摸屏屏幕。直連設備排查，重啟共享器，更換共享器，測試故障是否恢復。

（3）觸摸屏硬件排查。檢查與ASMGCS系統(tǒng)共享觸摸屏的EFS系統(tǒng)（ASMGCS系統(tǒng)的備份系統(tǒng)）故障現(xiàn)象是否一致。更換觸摸屏屏幕，使用備件屏幕測試故障是否恢復。

（4）查看共享器與兩系統(tǒng)主機相連分別接了串口線和DVI線，兩套主機以及線纜同時故障的幾率較小。若（1）（2）（3）（4）步不能解決故障，再繼續(xù)排故，依次更換兩系統(tǒng)線纜和主機，測試故障能否恢復。

1.4 排故操作

執(zhí)行到排故步驟（3）后，故障現(xiàn)象消失，觸摸屏屏幕恢復正常，測試備用觸摸使用靈敏。

1.5 故障件檢查測試

在測試平臺測試換下屏幕，故障現(xiàn)象重現(xiàn)，左側(cè)屏幕觸摸不靈敏。檢查觸摸屏屏幕表面無壓痕無受損情況，屏幕顯示清晰正常；觀察其他正常觸摸屏，發(fā)現(xiàn)故障觸摸屏非顯示部分邊框左上角貼有席位標簽，撕下該標簽后，故障屏幕觸摸恢復正常。后測試將相同標簽貼至備用測試正常觸摸屏，故障現(xiàn)象能復現(xiàn)。

1.6 故障點

觸摸屏在未顯示部分的黑色屏幕邊框也會有少量觸摸感應模塊，由于標簽粘貼位置不當導致屏幕左側(cè)觸摸單元被非正常接觸，進而導致在使用時不靈敏。

1.7 排故總結(jié)

觸摸屏在黑色屏幕邊框未顯示部分也會有少量觸摸感應模塊，后續(xù)檢查各個在用席位觸摸屏是否仍有標簽貼在屏幕邊框的情況，排除故障隱患。技術人員在設備維護時需熟知席位整體硬件連接結(jié)構，當發(fā)生故障后，及時對各個在用故障設備進行備件更換，在測試平臺對故障模塊進行檢測測試，發(fā)現(xiàn)故障原因，做好故障總結(jié)，積累排故經(jīng)驗。

2 案例二：ASMGCS系統(tǒng)顯示內(nèi)容與CDM系統(tǒng)顯示不一致

2.1 故障現(xiàn)象

ASMGCS系統(tǒng)中顯示的流控信息為（2358-0802 [OMDEK]T=10’ Via：OMDEK-VARDU-ZHHHACC），CDM系統(tǒng)中流控時間北京時間0930-1730，兩系統(tǒng)流控時間不一致；同時CSN6720航班CTOT時間為UTC時間0002未在ASMGCS系統(tǒng)上未掛上限制信息。

2.2 排故思路

查詢原始流控內(nèi)容，原始內(nèi)容源自CDM系統(tǒng)，查看相關日志找到原始報文。查詢系統(tǒng)配置，根據(jù)接收CDM系統(tǒng)限制情況，在ASMGCS系統(tǒng)會有經(jīng)驗值時間轉(zhuǎn)換。根據(jù)CDM系統(tǒng)原始報文，查詢該航班是否受限制。CDM系統(tǒng)傳輸兩類數(shù)據(jù)，一類是流控信息;另一類是航班限制信息。

2.3 排故步驟

（1）解讀流控顯示內(nèi)容，流控時間范圍是UTC時間23:58到08:02期間，從OMDEK走廊口出發(fā)經(jīng)過VADRU到鄭州區(qū)調(diào)。查詢原始流控內(nèi)容，在RTP服務器主機/home/atc/log/resp_log目錄下對應時間的RESP_ RecvResInfo日志中，查找該限制信息，搜索關鍵字“VARDU”，可得到該流控信息的開始結(jié)束時間（北京時間）“BEGTIME202112270930”“ENDTIME202112271730”，即CDM流控時間為北京時間0930-1730，此時間為華北流量系統(tǒng)傳遞的原始報文時間。

（2）查看配置，找到時間轉(zhuǎn)換配置。AMGCS系統(tǒng)做時間轉(zhuǎn)換的作用是：CDM系統(tǒng)給出的時間是航班流控時間，在ASMGCS系統(tǒng)上塔臺管制員指揮，需要一個時間轉(zhuǎn)換倒推出出港航班在未起飛時刻時是否會即將進入流控時間內(nèi)。在任一節(jié)點/home/atc/config/CETC/srst_data目錄下打開如圖2所示RESP_config.xml文件，搜索關鍵字“VARDU”，顯示“time=90”即90分鐘作為時間轉(zhuǎn)換的依據(jù)，可用“接收到的CDM時間”減去“經(jīng)驗值90分鐘”計算出在ASMGCS系統(tǒng)中顯示該流控的時間，即上述“北京時間0930-1730”減“90分鐘”得到“北京時間0800-1600”。為了補償誤差值，開始時間和結(jié)束時間均外擴2分鐘，即可得到0758-1602，換算成UTC時間即為“2358-0802”。根據(jù)接收CDM系統(tǒng)時間，以及對應的ASMGCS系統(tǒng)的配置信息，可以算出ASMGCS系統(tǒng)顯示的流控時間無誤。

圖2 RESP_config.xml文件Fig.2 RESP_config.xml file

（3）找到原始航班限制信息，在FDP服務器主機/home/atc/log/afdp_log目錄，打開對應時間的如圖3所示AFDP日志，搜索該航班號CSN6720，看該航班的CTOT時間為0002，在ASMGCS系統(tǒng)計算的2358—0802時間范圍內(nèi)；但查詢該航班的流控標識：Restrict 1（0：不受控；1：受控），流控標識為CDM系統(tǒng)計算傳輸，為了確保單個航班限制的準確性，ASMGCS系統(tǒng)處理機制為優(yōu)先處理CDM系統(tǒng)以是否掛上流控標識為準。

圖3 AFDP日志Fig.3 AFDP log

2.4 排故分析

依次執(zhí)行以上（1）（2）（3），發(fā)現(xiàn)兩個系統(tǒng)流控時間顯示不一致是因為ASMGCS系統(tǒng)根據(jù)經(jīng)驗時間進行轉(zhuǎn)換，轉(zhuǎn)換時間正確，此狀況屬于正常情況。而航班是否受限，ASMGCS系統(tǒng)處理機制是根據(jù)華北流控的原始報文進行處理，有無限制情況均直接源自CDM系統(tǒng)，該航班顯示未受限制屬于正常情況。

2.5 排故總結(jié)

根據(jù)原始報文以及配置文件查詢可以有效判斷系統(tǒng)計算流控時間是否正確，根據(jù)航班原始報文可以查詢航班受限制情況。ASMGCS系統(tǒng)處理CDM系統(tǒng)流控情況和航班限制情況是單獨的兩類數(shù)據(jù)，其中的流控時間轉(zhuǎn)換可能會造成誤差值，導致看似航班應該在流控時間內(nèi)，實際情況應以航班是否掛有流控標識為準，以CDM系統(tǒng)流控信息為準。技術人員應熟悉系統(tǒng)對CDM系統(tǒng)信息處理機制，參考日志內(nèi)容對日常運行中出現(xiàn)的問題作出排查。

3 案例三：ASMGCS系統(tǒng)無法創(chuàng)建進離港計劃問題分析

3.1 故障現(xiàn)象

ASMGCS系統(tǒng)離港計劃（例如CES5149）進入預激活狀態(tài)后，未在放行席彈出電子進程單；THALES自動化系統(tǒng)正常，無此故障現(xiàn)象。

3.2 排故思路

查詢相關日志以及與THALES自動化系統(tǒng)交互日志。

3.3 排故步驟及分析

（1）查 看ASMGCS系 統(tǒng)fdp_log目 錄 下 的All.log日志，離港計劃CES5149創(chuàng)建失敗，顯示為"EXTERN_PLAN::CES5149 -ZBAD- ZSNB.Source [THALES].Identifier[5942].Failed."。

（2）查看IODE日志，ASMGCS系統(tǒng)通過IODE鏈路接收THALES系統(tǒng)發(fā)送的原始計劃信息如圖4所示。IODE進程將原始計劃信息由報文格式轉(zhuǎn)換為內(nèi)部統(tǒng)一格式，檢查內(nèi)容與IODE日志一致。

圖4 CES5149原始計劃信息Fig.4 CES5149 original plan information

（3）查看fdp_log目錄下的Extern.log日志，為FDP進程接收到的計劃信息。

（4）IODE進程對于從THALES系統(tǒng)接收的原始計劃信息（ITEM-UPDATE報文），將其從報文格式轉(zhuǎn)換為內(nèi)部統(tǒng)一格式，同時判斷報文是IFPL/IDEL類報文，再根據(jù)不同類型報文按照不同接口發(fā)送給FDP模塊，報文類型及判斷方法如下：

1）IFPL報文：數(shù)據(jù)類型 datasource=“FPL”，消息類型為ITEM-UPDATE且Item mode=“UPDATE”；

2）IDEL報文：數(shù)據(jù)類型 datasource=“FPL”，消息類型為ITEM-UPDATE且Item mode=“DELETION”；

內(nèi)部統(tǒng)一格式計劃信息中，TITLE字段的值為IODE進程判斷報文類型的結(jié)果。

FDP進程對接收的內(nèi)部統(tǒng)一格式計劃信息進行解析，并將其與內(nèi)部計劃進行匹配，匹配原則如下：

首先，根據(jù)外部計劃唯一號匹配，對于THALES系統(tǒng)發(fā)送的原始計劃信息，UID字段的值為外部計劃唯一號，內(nèi)部統(tǒng)一格式計劃信息中，PLAN IDENTIFIER字段的值為外部計劃唯一號；

其次，根據(jù)外部計劃唯一號匹配失敗后，再根據(jù)航班號，起飛機場，降落機場，SOBT或EOBT時間匹配，外部計劃的SOBT或EOBT時間需在系統(tǒng)內(nèi)部計劃SOBT或EOBT時間的前2小時或后6小時范圍內(nèi)。

對于IFPL報文，若匹配不成功，則創(chuàng)建新計劃。系統(tǒng)根據(jù)外部來源創(chuàng)建計劃時，會進行狀態(tài)過濾，對于離港計劃，只有外部計劃狀態(tài)為INAC/PREA/COOR時，才能創(chuàng)建計劃；對于進港計劃，只有外部計劃狀態(tài)為ACT/CONT時，可創(chuàng)建計劃。

（5）對于CES5149離港計劃，IODE進程將原始計劃信息由報文格式轉(zhuǎn)變?yōu)閮?nèi)部統(tǒng)一格式，并判斷為IFPL類型報文，IODE進程將內(nèi)部統(tǒng)一格式計劃信息發(fā)送給FDP進程，F(xiàn)DP進程對接收信息進行解析，并根據(jù)該信息創(chuàng)建計劃，但由于該離港計劃狀態(tài)為CONT，因此創(chuàng)建計劃失敗，放行席無法彈出電子進程單。

（6）查看THALES自動化系統(tǒng)的IODE日志，MAE服務器發(fā)送的原始計劃信息與ASMGCS系統(tǒng)接收的原始計劃信息一致，故為THALES自動化系統(tǒng)發(fā)送計劃信息不正確導致。

3.4 排故總結(jié)

遇到ASMGCS系統(tǒng)與外系統(tǒng)交互時出現(xiàn)符合本系統(tǒng)軟件設計的“故障”，要從本系統(tǒng)日志處理查起，熟知系統(tǒng)處理機制，查看收到的原始報文，最后查詢外系統(tǒng)發(fā)送的原始報文，根據(jù)判斷是否符合系統(tǒng)處理機制來排查故障[1]。

4 結(jié)語

隨著大興國際機場航班量的穩(wěn)定增長，空管設備保障也成為至關重要的一環(huán)，設備的正常運轉(zhuǎn)大大提高了機場運行效率，也為管制員提供了更便捷的手段，更為管制部門提供了更加高效、實用、可靠的空管系統(tǒng)和工具。因此，故障分析與總結(jié)起到了重要的作用，本文為ASMGCS系統(tǒng)中出現(xiàn)類似故障問題時提供參考借鑒。

引用

[1]趙航.北京大興國際機場A-SMGCS系統(tǒng)常見故障淺析[J].裝備維修技術,2021(3):158+161.