淺析空管自動化系統(tǒng)備降延誤報引發(fā)的典型案例

劉子園

【摘 要】本文以南京萊斯空管自動化系統(tǒng)為例，介紹了空管自動化系統(tǒng)報文處理流程，并總結(jié)了日常維護(hù)工作中系統(tǒng)接收處理CPL（現(xiàn)行飛行變更報）報和DLA（延誤報）報引發(fā)的典型案例及分析過程。

【關(guān)鍵詞】空管自動化系統(tǒng)；報文處理；備降；延誤

0 引言

空管自動化系統(tǒng)通過處理多雷達(dá)信號、飛行計劃和動態(tài)電報，為空中交通管制員提供飛行態(tài)勢顯示、飛行相關(guān)動態(tài)信息和各項告警功能等，協(xié)助管制員完成空中交通指揮和疏導(dǎo)工作。隨著民航事業(yè)的發(fā)展，國內(nèi)航班量快速增長，空管自動化系統(tǒng)在空中交通管理體系中越來越突顯其重要地位，有效地確保了管制轄區(qū)內(nèi)的飛行安全，提高了飛行效率。

因為天氣或者其它不可抗拒原因，使得一些航班返航、備降或者延誤?？展茏詣踊到y(tǒng)在處理這類報文時，有時會遇到由于報文時間、報文內(nèi)容或者其它因素導(dǎo)致航班狀態(tài)有異或其它問題，本文結(jié)合筆者所在單位使用的南京萊斯空管自動化系統(tǒng)，介紹系統(tǒng)處理報文機(jī)制及遇到此類問題時的分析過程。

1 萊斯空管自動化系統(tǒng)報文處理流程

萊斯空管自動化系統(tǒng)接收AFTN網(wǎng)（航空固定電信網(wǎng)）的民航電報，處理系統(tǒng)飛行計劃有關(guān)的數(shù)據(jù)。系統(tǒng)能夠處理AFTN格式電報、SITA（國際航空電信公司）格式電報，獲取氣象電報、航行通告的機(jī)場信息。系統(tǒng)能夠處理AIDC（空中交通管制設(shè)施間數(shù)據(jù)通信）電報，實現(xiàn)管制中心間管制數(shù)據(jù)的協(xié)調(diào)和移交。系統(tǒng)能夠自動或手工向外輸出飛行電報，實現(xiàn)飛行數(shù)據(jù)的動態(tài)輸出。

系統(tǒng)對接收的報文進(jìn)行分類處理，氣象電報移交至氣象數(shù)據(jù)處理模塊單獨處理，AFTN電報、AIDC電報和SITA報進(jìn)行報文解析處理，經(jīng)處理后的正確報文，由主處理機(jī)發(fā)送到各席位的飛行計劃顯示席顯示，并保存到數(shù)據(jù)庫中；特殊報文（錯報、部分SITA 報等）送至飛行計劃處理席等待人工處理，人工處理后，保存至數(shù)據(jù)庫中。

系統(tǒng)接收返航、備降CPL報處理過程：在系統(tǒng)分析報文后，若存在與報文相關(guān)的原計劃，則修改原計劃的落地計劃，按CPL的航路修改計劃的航路；若不存在原計劃，則系統(tǒng)創(chuàng)建新計劃。

2 典型案例

2.1 案例一

2.1.1 問題反饋

站調(diào)值班員反映NOK6320（曼谷-石家莊）航班備降太原，在進(jìn)港動態(tài)列表看不到該航班信息，但在飛越動態(tài)列表中看得到該航班信息。同是備降航班，HBH3220（虹橋-石家莊）航班備降太原，卻在進(jìn)港動態(tài)列表和飛越動態(tài)列表中都能看到該航班信息。

2.1.2 問題分析

查看NOK6320航班收到的CPL報文，該報文第18編組中含有“RMK/ALTERNATE”標(biāo)記，說明該CPL報文為備降報，編組16中的目的機(jī)場為新的備降機(jī)場。自動化系統(tǒng)在解析該報文后會將NOK6320航班的落地機(jī)場修改為備降機(jī)場，并將該航班計劃移到飛越動態(tài)列表中。

查看HBH3220航班收到的CPL報文，該報文第18編組中無“RMK/ALTERNATE”標(biāo)記。自動化系統(tǒng)在解析該報文后，認(rèn)為不是該航班的備降報，會保持該航班原計劃不變，即該計劃仍在進(jìn)港動態(tài)列表中，同時系統(tǒng)會在飛越動態(tài)列表中再新建一個航班號同為HBH3220的計劃，因此在進(jìn)港動態(tài)列表和飛越動態(tài)列表中都能看到該航班信息。

2.2 案例二

2.2.1 問題反饋

塔臺管制員反映CUA5928航班，備降到石家莊，在管制過程中未自動相關(guān)。

2.2.2 問題分析

查看CUA5928航班相關(guān)報文，發(fā)現(xiàn)只收到一份CPL報，系統(tǒng)收到該報文時間為UTC（世界協(xié)調(diào)時）時間0601，因無FPL報或DEP（起飛報）報等其它報文，系統(tǒng)將收到CPL報的時間判斷為起飛時間，與航班實際起飛時間超出2小時。而系統(tǒng)判斷自動相關(guān)機(jī)制中有一條為“推算出航跡將要到達(dá)最近的計劃航路報告點的時刻，與計劃中的預(yù)測時刻比較，誤差在1小時之內(nèi)”，2小時已超出了這個設(shè)定值，因此航跡不會自動相關(guān)。

2.3 案例三

2.3.1 問題反饋

進(jìn)近管制員反映CBJ5533（?？?石家莊）航班沒有自動打印進(jìn)程單，也沒有自動相關(guān)。

2.3.2 問題分析

查看CBJ5533航班相關(guān)報文，該航班收到DLA報，報中預(yù)計起飛時間為UTC1820，而收到DEP報的時間為UTC1025，比DLA報中預(yù)起時間早了近八個小時。系統(tǒng)設(shè)定預(yù)起時間前兩個小時后收到的DEP報才有效，即UTC1620后收到DEP報才有效。所以收到的DEP報不被系統(tǒng)承認(rèn)，自然不能打印進(jìn)程單。系統(tǒng)設(shè)定進(jìn)入管制區(qū)前90分鐘計劃進(jìn)入預(yù)激活狀態(tài)，而由報文中預(yù)起時間UTC1820可知，飛機(jī)實際起飛時計劃遠(yuǎn)沒到預(yù)激活狀態(tài)，因而也不能自動相關(guān)。

2.4 案例四

2.4.1 問題反饋

進(jìn)近管制員反映KZU6425（出港航班、外航）航班打印出兩份進(jìn)程單，其中的機(jī)型和巡航高度信息有誤。

2.4.2 問題分析

查看KZU6425航班相關(guān)報文和進(jìn)程單，F(xiàn)PL報中的起飛落地機(jī)場為：ZBSJ-UNNT。兩份DLA報中，一份起飛落地機(jī)場為ZBSJ-UATT，一份起飛落地機(jī)場為ZBSJ-UNNT。

起飛落地機(jī)場為ZBSJ-UATT的計劃打印進(jìn)程單是因為當(dāng)時臨時計劃庫里有這份計劃，DLA報激活了此計劃，并引用了城市航線班機(jī)對航路里的機(jī)型B767，因為城市航線班機(jī)對航路里無巡航高度，所以引用了默認(rèn)高度9000。而起飛落地機(jī)場為ZBSJ-UNNT的計劃雖然收到了FPL報，但此份FPL報不是由我們的站調(diào)值班員發(fā)的，這樣的報文是無效的。城市航線班機(jī)對航路里的機(jī)型和FPL報里的一樣，都是A310，但巡航高度沒有，所以也默認(rèn)9000。

2.5 案例五

2.5.1 問題反饋

塔臺管制員反映兩個備降石家莊的航班已落地，但在飛行計劃欄中仍顯示為起飛狀態(tài)。

2.5.2 問題分析

查看兩個航班相關(guān)報文，發(fā)現(xiàn)這兩個航班均為收到ARR（落地報）報后，才收到CPL報。系統(tǒng)處理機(jī)制為航班落地后系統(tǒng)收到ARR報，計劃將變?yōu)榻K止?fàn)顟B(tài)。但只要航班收到CPL報，系統(tǒng)仍會將航班狀態(tài)變?yōu)槠痫w狀態(tài)，只是計劃狀態(tài)不變，仍是終止?fàn)顟B(tài)。

3 結(jié)束語

通過對系統(tǒng)接收處理CPL報和DLA報引發(fā)的幾個典型案例的分析，只有深入了解系統(tǒng)處理報文流程，航班狀態(tài)機(jī)制，了解各種報文格式及編組，才能在日常工作中遇到相應(yīng)問題時，迅速找到問題所在并解決問題，為管制部門提供更好的保障服務(wù)。

[責(zé)任編輯：薛俊歌]