基于里程碑方法的空管信息動態(tài)擬合技術的設計與應用

蔣丹洋

摘 要：由于空管行業(yè)的特殊性，需要保證整個航班生命周期過程的安全，因此對實時生產(chǎn)運行系統(tǒng)的可靠性、可用性及安全性要求極高；而傳統(tǒng)的集中式或分布式數(shù)據(jù)庫架構(gòu)難以滿足相應運行系統(tǒng)的設計要求，基于這一問題，本文通過技術研究及模型的搭建，并于實際運行系統(tǒng)中進行應用與實踐，得出一套科學、合理、適應于空管實時運行系統(tǒng)的動態(tài)擬合技術設計，同時也為其他類似的實時生產(chǎn)系統(tǒng)提供一種可行的解決方案。

關鍵詞：里程碑；動態(tài)；擬合；空管

中圖分類號：TP393.08 文獻標識碼：A

Abstract：Air traffic control is indispensable for flight safety in civil aviation industry.The operating system is required to provide with reliability，feasibility and security.It is demonstrated that the traditional centralized and distributed database is not to meet the system operation demands.The essay states a new database structure，which has been utilized in practice and proved to be scientific，reasonable and applicable， and aims at putting forward a practicable resolution for other homogeneous systems.

Keywords：milestone；dynamic；fitting；air traffic control

1 引言（Introduction）

空中交通管制是對航空器的空中活動進行管理和控制的業(yè)務，包括空中交通管制業(yè)務、飛行情報和告警業(yè)務。它的任務是；防止航空器相撞，防止機場及其附近空域內(nèi)的航空器同障礙物相撞；維護空中交通秩序，保障空中交通暢通，保證飛行安全和提高飛行效率。隨著飛行活動的頻繁增加、飛行航程的加長、載客量的大幅增加以及飛行速度的增加，迫使空管系統(tǒng)快速發(fā)展，漸漸從單一系統(tǒng)發(fā)展成綜合性服務系統(tǒng)，并且系統(tǒng)所覆蓋的地域也由單一城市向地區(qū)型發(fā)展[1]。

機場協(xié)同決策（CDM）的核心要素是里程碑方法、事件驅(qū)動和資源（時間、空間）動態(tài)配置，圍繞這三大要素，對主要管理對象航空器需要建立以里程碑、事件和資源配置三位一體的信息模型，實現(xiàn)對航空器以事件驅(qū)動的全生命周期的動態(tài)管理；以CDM信息模型為基礎，建立支持機場的核心數(shù)據(jù)庫，數(shù)據(jù)庫性能、規(guī)?？筛采w和接管機場航班協(xié)同決策的業(yè)務。

系統(tǒng)通過一連串不同的被稱作“里程碑”的事件航班進程（航班進場、著陸、滑入、過站、滑出和離場）跟蹤航班進程，解釋更新下游信息的規(guī)則并定義預計值的目標準確度。機場的不同參與方將負責不同的里程碑，但目的都是將某航班的所有里程碑整合成統(tǒng)一無縫的過程，進一步提高所有參與方的共同情景意識，包括：（1）定義信息更新和觸發(fā)事件：新參數(shù)、下游預計值更新、告警電報、通告等。（2）根據(jù)移動時間窗口，從精確性、及時性、可靠性、穩(wěn)定性和可預測性方面規(guī)定數(shù)據(jù)質(zhì)量。（3）確保進場和離場航班的連接。（4）事件被干擾時，能及早做出決策。（5）提高信息質(zhì)量。每個里程碑之間的時效及其實時更新成為里程碑方法的基本參數(shù)，整個過程將實現(xiàn)信息動態(tài)擬合，連接形成飛行剖面，通過信息共享方式使各方及時反應、提高可預測性和效率。

2 問題提出（The proposing of question）

在整個航班生命周期從航班的計劃編制→計劃實施→統(tǒng)計的過程中，系統(tǒng)涉及了不同部門的協(xié)調(diào)、不同的數(shù)據(jù)其處理標準也不相同，某些數(shù)據(jù)對一致性要求較高、某些數(shù)據(jù)實時性較強；并且在實際工作中出現(xiàn)多種不可預見情況，要求做出動態(tài)的、可復制性的里程碑方法論，以下提出一些具體問題需要航班過程管控中時考慮和解決：

（1）目前機場容量、未來幾個小時內(nèi)機場容量（跑道容量、滑行道容量、停機門容量）的大小問題。

（2）運行的開始時間、結(jié)束時間，持續(xù)時間對進港航班延誤的影響程度。

（3）滑行延誤的具體表現(xiàn)方式以及延誤程度的考慮。

（4）進、出港航班延誤的原因以及預計的延誤的時間、地點和持續(xù)時間。

3 過站流程的里程碑模型設計（Milestone modeldesign of over station flow）

3.1 實現(xiàn)的目標和范圍

通過對過站流程實施里程碑方法可進一步改善航班動態(tài)信息的準確性。機場CDM平臺通過一連串不同的被稱作“里程碑”的事件跟蹤航班進程，解釋更新下游信息的規(guī)則并定義預計值的目標準確度。機場CDM的不同參與方可負責不同的里程碑，但目的都是將某航班的所有里程碑整合成統(tǒng)一無縫的過程。里程碑方法的主要目標是在航班進港和過站時，進一步提高所有參與方的共同情景意識。

（1）具體目標

a.確定重要事件并利用這些事件跟蹤航班進程，以及關鍵事件即里程碑的分布。

b.定義信息更新和觸發(fā)事件：新參數(shù)、下游預計值更新、告警電報、通告等。

c.根據(jù)移動時間窗口，從精確性、及時性、可靠性、穩(wěn)定性和可預測性方面規(guī)定數(shù)據(jù)質(zhì)量。

d.確保進場和離場航班的連接。

e.事件被干擾時，能及早做出決策。

f.提高信息質(zhì)量。

（2）里程碑方法的重點

a.沿航班進程（進場、著陸、滑入、過站、滑出和離場）選定一組里程碑，其中涉及不同的參與方。

b.時效性，對每個里程碑或兩個里程碑之間測量時效性。

上述過程連接形成飛行剖面，這樣每個里程碑之間的時效及其實時更新成為里程碑方法的基本參數(shù)。及時共享信息是使各方及時反應、實時更新里程碑的首要因素。這樣，各方一起行動來提高可預測性和效率，共享其帶來的益處。

一旦機場CDM平臺在收到空管飛行計劃后激活了某航班，就可以根據(jù)一般規(guī)則和本地規(guī)則為該航班添加一些默認值，如停機位號，可變滑行時間，預計撤輪擋時間和目標起飛時間。航空器運營人和地勤可查看并根據(jù)某些情況如旅客數(shù)量或聯(lián)程航班的進程情況更新某些默認值，以提高預測質(zhì)量[2]。

機場CDM對提高效能的重大貢獻之一就是目標撤輪擋時間?？赏ㄟ^測量目標撤輪擋時間的及時性、準確性和可預測性評估其質(zhì)量。對決策的信任度取決于目標撤輪擋時間質(zhì)量，目標撤輪擋時間又依賴其他一些里程碑，因此還需分析每個里程碑的準確度，以確定應改善哪項里程碑來提高目標撤輪擋時間的準確度。

自動監(jiān)視航班進程，隨著航班通過各里程碑，可增加和修改更多信息（即飛行計劃、ATFM措施、實際進程等），而且下游里程碑也得到相應更新，需要時會發(fā)出告警。進場延誤通常會影響使用同一航空器航班的離場階段，還會影響：（1）機組。（2）運送中轉(zhuǎn)旅客的航班。（3）登機門/停機位占用以及參與方之后的資源計劃。

如果航班延誤，航空器運營人將得到提示需重新計劃（如停機位和登機門變化）或調(diào)整相應離港航班及有關聯(lián)程航班的時間。

流程后分析不僅可使參與方檢查機場CDM的收益，還能幫助他們確定單個航班未能滿足里程碑要求的具體原因。未來可采取措施降低這些影響，甚至完全消除影響根源，如通過更新默認值的方法。

3.2 實施要求

該要素主要要求有：

（1）具備技術基礎設施，可實現(xiàn)信息共享并正常工作。

（2）具有本地協(xié)議，清楚需要何種流程提高過站事件可預測性。

（3）恰當顯示里程碑流程產(chǎn)生的輸出。

技術基礎設施功能基于信息共享的實現(xiàn)。如果以應用軟件的方式呈現(xiàn)，除了所需邏輯計算外，還需提供額外的數(shù)據(jù)輸入與輸出。里程碑的方法總共定義了16個基本里程碑，如圖1所示。

4 應用實現(xiàn)（ Application implementation ）

一架航空器過站通常包含一個進場航班和一個離場航班，這意味著該航空器與兩個飛行計劃相關。整體分為三個階段，即航班的準備階段、飛行階段、入港階段，從這三個階段的具體執(zhí)行過程，完成一輛航班的整個生命周期[3]。

4.1 航班的準備階段

對于協(xié)調(diào)運行機場，離港航班為已知?？衫蔑w行計劃更新某些信息如航空器機型信息。對于遠程航班，ELDT可能與機場時隙不同。對于非協(xié)調(diào)運行機場，利用飛行計劃開始實施離港航班。航班在不晚于計劃EOBT15分鐘內(nèi)做好準備。

對進港航班，在考慮航班實際進程的情況下，通過FUM電報提供的信息更新ELDT。如起飛機場距目的地機場飛行時間大于三小時，可從網(wǎng)絡運行部FUM或航空器運營人/地勤獲得ATOT。利用ATOT和FPL中的預計經(jīng)過時間可計算ELDT。如目的地機場在三小時飛行距離內(nèi)，網(wǎng)絡運行部利用ETFMS監(jiān)控航班進程，并發(fā)送航班更新電報（FUM）提供進程更新[4]。

ELDT的更新可觸發(fā)新的TOBT輸入，可由AO/GH輸入或機場CDM平臺自動計算得出。此階段ELDT的準確度極為重要，因下游需做出決策，如更換停機位/登機門/航空器，預測進場順序，準備地面操作，聯(lián)程旅客的安排。

4.2 航班的飛行階段

在此階段若不確定ELDT或其值不準確會增加做出錯誤決策或倉促決策以及內(nèi)擾的風險。為滿足減少在最后30分鐘改變停機位和登機門次數(shù)的目標，需要高度準確的離場和進場時間。因此，考慮到滑入時間（EXIT），不希望停機位或登機門在ELDT前30分鐘內(nèi)發(fā)生變化。在該里程碑之后，相關離場航班的TOBT被更新。在此時做出有關過站時間、聯(lián)程旅客等的決策且需保證其不會突然變化。利用ELDT和預計滑入時間可計算預計擋輪擋時間（EIBT）。

更新ELDT可確定新的TOBT。當航班到達該階段時，通常距著陸大約2至5分鐘（取決于空管設置的參數(shù)）。這就提示許多參與方應開始調(diào)配與航班相關的資源，如停機引導到位和地面服務就緒。ALDT的出現(xiàn)觸發(fā)更新下游預測值：根據(jù)離場航班確定的過站時間，自動更新TOBT和TTOT，或由航空器運營人/地服人工輸入更新?？筛鶕?jù)ALDT+EXIT確定更新EIBT。

最終TOBT的目的是對撤輪擋時間進行及時、準確和可靠的估計。在發(fā)生干擾的情況下（內(nèi)部或外部），可望獲得共享TOBT的最大益處。在這些情況下，EOBT（空管、網(wǎng)絡運行部和停機位/登機門管理共享）和TOBT的差異可能很重要。

4.3 航班的入港階段

在EOBT前t分鐘準確確定TOBT是空管建立推出/離場前順序的前提條件。強調(diào)一點，航空器運營人需整合其策略，為有關航班計算TOBT。收到TOBT后，空管系統(tǒng)將基于預計的交通負荷、登機門/停機位位置、使用跑道和在等待點的等待時間等計算并提供預計滑出時間（EXOT）。

將航班排入離場前順序。航空器運營人/地服與機組人員協(xié)調(diào)，可相應地管理過站流程。航班排定離場前順序。航空器運營人/地服與機組人員協(xié)調(diào)，可相應地管理過站流程。登機開始能向機場CDM參與方表明TOBT/TSAT是否能被遵守?？展苄拚x場前順序。駕駛員與地服（簽派員/監(jiān)督員/搬運工）協(xié)調(diào)后，在TSAT前申請開車。

空管向駕駛員證實TSAT，以便保證航空器在離場前的排序。假如航空器準時做好準備（ARDT），則由空管確保受限航班能遵守其CTOT。收到空管同意，航空器將開車、推出和開始滑行，考慮到EXOT，更新TTOT，發(fā)送FSA和MVT電報。

5 空管信息動態(tài)擬合技術結(jié)果分析（Dynamic fitting of air traffic control information result analysis）

5.1 里程碑擬合技術結(jié)構(gòu)

根據(jù)上述本系統(tǒng)的模型設計和應用設計，通過航班的實際飛行過程，將里程碑分為四個部分結(jié)構(gòu)，即航班計劃預處理計算、航班前站數(shù)據(jù)處理、航班本站飛行前運行流程和航班本站地面運行，如圖2所示。

5.2 調(diào)試方案

整個調(diào)試過程必須建立在運營者和參與者多方協(xié)作的基礎上，結(jié)合電報系統(tǒng)、一體化系統(tǒng)、CDM系統(tǒng)，以及基于ESB理念的系統(tǒng)架構(gòu)設計展開，如圖3所示。

6 結(jié)論（Conclusion）

本文提出了一套適應于空管實時動態(tài)信息運行的方法，該擬合技術設計通過實際應用滿足了系統(tǒng)安全性、可靠性的運行需求，同時也為其他類似實時運行系統(tǒng)的建設提供了一種可行的解決方案。

參考文獻（References）

[1] EUROCONTROL.Air Traffic Control CDM Operational[R].2006，23（3）：31-35.

[2] Ryan K.Stephens，et al.何玉潔，譯.Database Design[M].北京：機械工業(yè)出版社，2001.

[3] Blair G.S.，et al.The design and implementation of OpenORB[J].IEEE Distributed System，2001，2（6）：34-56.

[4] Kon Fobio，et al.The case for reflective middleware[J].Communications of the ACM，2002，45（6）：33-38.