全球航班跟蹤系統(tǒng)關鍵技術研究與實現(xiàn)

陳 敏 屈景怡 裴方瑞 喻益琳

1(中國民航大學天津市智能信號與圖像處理重點實驗室 天津 300300) 2(內(nèi)蒙古空管分局 內(nèi)蒙古 呼和浩特 010070) 3(中國國際航空股份有限公司 四川 成都 610000)

0 引 言

馬來西亞航空MH370航班自2014年失聯(lián)至今已逾五年，其間雖然經(jīng)過多次大規(guī)模搜索，但仍一無所獲[1]。MH370航班失聯(lián)事件在全球引起了巨大轟動，世界各國民航管理部門及機構(gòu)均開始著力于推進全球航班跟蹤能力建設。2015年，國際民航組織提出了全球航班追蹤的路線圖以及運行實施概念草案。2016年中國民航局成立了中國民航航空器追蹤監(jiān)控體系建設領導小組；2017年中國民航局發(fā)布了《中國民航航空器追蹤監(jiān)控體系建設實施路線圖》，明確提出分三個階段實現(xiàn)我國民用航空全球航班跟蹤體制的建設。因而亟需研發(fā)全球航班跟蹤系統(tǒng)及相關技術，增強我國航班的全球?qū)崟r跟蹤能力[2]。目前關于全球航班跟蹤技術及系統(tǒng)的研究較少。吳志軍等[3]研究了全球航班跟蹤系統(tǒng)中信息共享技術，并給出了一種集成網(wǎng)絡結(jié)構(gòu)設計方案；Wang等[4]對可能用于全球航班跟蹤的多種監(jiān)視數(shù)據(jù)源進行研究分析，并對各種監(jiān)視數(shù)據(jù)源中存在的問題進行了總結(jié)；Han等[5]使用了ACARS數(shù)據(jù)實現(xiàn)了對航班位置的實時追蹤，但沒有實現(xiàn)航班動態(tài)顯示；劉琳[6]使用北斗衛(wèi)星系統(tǒng)實現(xiàn)了對少量航班的追蹤；劉海濤等[7-8]對星基ADS-B監(jiān)視容量及其數(shù)據(jù)處理和顯示進行研究，其研究結(jié)果可應用于全球航班跟蹤，但其并未針對大批量航班數(shù)據(jù)處理進行優(yōu)化及測試。

全球航班跟蹤系統(tǒng)實時在線處理、跟蹤的航班數(shù)量最大超過10 000架次。大批量航班數(shù)據(jù)的并發(fā)式輸入容易導致系統(tǒng)處理過載、緩沖區(qū)溢出，從而產(chǎn)生航班數(shù)據(jù)丟失、延遲、航班飛行態(tài)勢顯示卡頓等異常。因而，在全球航班跟蹤系統(tǒng)的設計過程中，如何解決大批量、高并發(fā)航班數(shù)據(jù)的接入、處理及顯示問題，是一個不小的挑戰(zhàn)。

本文給出一種全球航班跟蹤系統(tǒng)設計方案，通過設計易于拓展、并行化的數(shù)據(jù)處理硬件架構(gòu)，構(gòu)建多線程并行化處理軟件架構(gòu)，以及使用內(nèi)存地址交換技術，充分利用服務器多核心處理能力，有效地解決了大批量、高并發(fā)航班數(shù)據(jù)處理帶來的問題。長時間的實際運行表明，設計方案有效可行，運行效果良好。

1 系統(tǒng)架構(gòu)設計

全球航班跟蹤系統(tǒng)是集監(jiān)視數(shù)據(jù)接入、校驗、解析、處理、跟蹤顯示于一體的自動化系統(tǒng)。全球航班跟蹤系統(tǒng)采用模塊化設計思想，系統(tǒng)由數(shù)據(jù)管理、前端數(shù)據(jù)處理、地理信息系統(tǒng)、航行情報資料顯示、航班跟蹤、顯示子系統(tǒng)組成。全球航班跟蹤系統(tǒng)架構(gòu)如圖1所示。

圖1 全球航班跟蹤系統(tǒng)框架

系統(tǒng)主要功能模塊有：

1) 前端數(shù)據(jù)處理模塊。通過局域網(wǎng)接入多源監(jiān)視數(shù)據(jù)，數(shù)據(jù)類型包括ACARS、SSR、地基ADS-B、星基ADS-B數(shù)據(jù)，完成對數(shù)據(jù)的解析(星基ADS-B數(shù)據(jù)解析參見文獻[9])、CRC校驗(校驗算法參見文獻[10])、異常數(shù)據(jù)濾除、坐標投影等處理后，實現(xiàn)對多源異構(gòu)監(jiān)視數(shù)據(jù)的融合處理。

2) 航班跟蹤及顯示。實現(xiàn)對全球航班的顯示及跟蹤，包括航班飛行態(tài)勢顯示、航班跟蹤、歷史尾跡顯示、飛行剖面顯示、實時油量剖面顯示，同時還具備有航班過濾、航班檢索等功能。

3) 地理信息(GIS)系統(tǒng)。地理信息系統(tǒng)以SHAPEFILE標準地理數(shù)據(jù)文件為數(shù)據(jù)源，具備對地理信息資料，包括行政區(qū)域、城市、道路、河流、水域等元素的載入、處理、投影、顯示、管理。

4) 航行情報資料顯示。同時支持對航行情報資料，包括航路航線、飛行情報區(qū)、機場、危險區(qū)、限制區(qū)、終端近進區(qū)等元素的載入、處理、顯示、管理。支持地圖的投影、放大、縮小、拖動平移等操作。

5) 數(shù)據(jù)管理。以SQLite為基礎，完成對航行情報資料數(shù)據(jù)庫、監(jiān)視數(shù)據(jù)數(shù)據(jù)庫等數(shù)據(jù)的存儲及管理，包括數(shù)據(jù)的查詢、增加、修改、刪除、導入導出等，同時提供各個功能的對外接口AIP函數(shù)，供其他功能模塊使用。數(shù)據(jù)管理子系統(tǒng)對各類監(jiān)視數(shù)據(jù)存儲周期超180天，同時支持場景回放。

2 系統(tǒng)關鍵技術實現(xiàn)

全球航班跟蹤系統(tǒng)可實現(xiàn)對我國范圍內(nèi)飛行的全部航班及在境外飛行的我國航班的實時顯示及跟蹤。由于系統(tǒng)跟蹤的航班數(shù)據(jù)量巨大，系統(tǒng)最大實時處理航班數(shù)超過10 000個。如何實現(xiàn)大批量、高并發(fā)航班數(shù)據(jù)的有效接入及實時處理是一個必須解決的問題。在前端數(shù)據(jù)處理子系統(tǒng)中，主要通過易于拓展的硬件架構(gòu)設計、多線程分級處理、結(jié)合多種優(yōu)化方法來解決大批量、高并發(fā)航跡數(shù)據(jù)的接入及處理問題。

2.1 可拓展硬件架構(gòu)設計

為了實現(xiàn)大批量、高并發(fā)航班數(shù)據(jù)有效的接入、處理、顯示，保證系統(tǒng)流程穩(wěn)定運行，前端數(shù)據(jù)處理子系統(tǒng)在進行架構(gòu)設計時，通過設立多臺前端數(shù)據(jù)處理服務器，對多路不同類型的數(shù)據(jù)源進行并行化處理，并行化處理后的結(jié)果在綜合顯示終端子系統(tǒng)進行整合。同時設立數(shù)據(jù)均衡服務器，通過周期性地檢測各個數(shù)據(jù)預處理服務器節(jié)點的CPU及內(nèi)存負載情況，進而調(diào)配不同服務器數(shù)據(jù)處理流量，避免出現(xiàn)單一服務器數(shù)據(jù)處理超載情況發(fā)生。不同數(shù)據(jù)預處理服務器可獨立完成功能完整的數(shù)據(jù)預處理流程，在全球航班跟蹤系統(tǒng)的實際運行過程中可以根據(jù)數(shù)據(jù)流量的變化，靈活增減數(shù)據(jù)預處理服務器的數(shù)量，拓展數(shù)據(jù)預處理能力。各個前端數(shù)據(jù)處理服務器通過NTP授時服務器統(tǒng)計校時，保證數(shù)據(jù)處理時間同步。前端數(shù)據(jù)處理子系統(tǒng)可拓展硬件架構(gòu)如圖2所示。

圖2 系統(tǒng)可拓展硬件架構(gòu)

2.2 前端數(shù)據(jù)處理

在進行大批量、高并發(fā)航班數(shù)據(jù)接入及處理時，為了充分利用高性能工作站的多核心處理能力，避免出現(xiàn)處理過載，減少數(shù)據(jù)處理延遲，前端數(shù)據(jù)處理模塊采用了多線程并行化軟件架構(gòu)，軟件架構(gòu)如圖3所示。不同線程間通過數(shù)據(jù)交換緩沖區(qū)來進行數(shù)據(jù)的交換。

圖3 多線程前端數(shù)據(jù)處理軟件架構(gòu)

針對不同類型的航跡數(shù)據(jù)源，分別設立不同的數(shù)據(jù)接入線程，各線程獨立運行。使用不同的線程來分別完成數(shù)據(jù)預處理過程中的不同環(huán)節(jié)，將CRC校驗及數(shù)據(jù)必備項檢測與數(shù)據(jù)解析及坐標投影分別使用兩個不同的線程來實現(xiàn)，并使用CRC校驗以及數(shù)據(jù)必備項檢測的結(jié)果來修正數(shù)據(jù)解析的結(jié)果。不同線程之間使用內(nèi)存數(shù)據(jù)緩沖區(qū)來進行數(shù)據(jù)的交換及共享。數(shù)據(jù)接入線程接入的數(shù)據(jù)存入數(shù)據(jù)交換緩沖區(qū)A中。CRC校驗及數(shù)據(jù)必備項檢測、數(shù)據(jù)解析及坐標投影線程則使用數(shù)據(jù)交換緩沖區(qū)B，多個CRC校驗線程以及數(shù)據(jù)解析及坐標投影線程分別從數(shù)據(jù)交換緩沖區(qū)B中提取數(shù)據(jù)，進行數(shù)據(jù)校驗、數(shù)據(jù)必備項檢測，數(shù)據(jù)解析及坐標投影。完成預處理后的航班數(shù)據(jù)存入到解碼數(shù)據(jù)交換緩沖區(qū)，解析后的不同類型的監(jiān)視數(shù)據(jù)均歸一化為相同結(jié)構(gòu)，方便進行多源異構(gòu)數(shù)據(jù)的融合及信息補全。

然而，當航班數(shù)據(jù)批量過大時，會導致大量航班數(shù)據(jù)在不同緩沖區(qū)間來回進行高頻交換，數(shù)據(jù)在不同緩沖區(qū)間的來回拷貝將會極大地占用系統(tǒng)硬件資源，降低系統(tǒng)處理效率。為了解決數(shù)據(jù)交換帶來的處理效率降低問題，系統(tǒng)使用了內(nèi)存地址交換方法，在進行數(shù)據(jù)交換時僅僅實現(xiàn)內(nèi)存地址的交換，而數(shù)據(jù)在內(nèi)存中的實際存儲位置并不發(fā)生變化。同時結(jié)合全局互斥鎖的同步使用，保證了各線程相互配合，協(xié)同完成數(shù)據(jù)預處理工作，同時避免了多線程間的訪問沖突的出現(xiàn)。基于內(nèi)存地址交換技術的大批量數(shù)據(jù)預處理技術處理流程如圖4所示。

圖4 前端數(shù)據(jù)預處理流程

數(shù)據(jù)接入線程接入在完成數(shù)據(jù)的接收與存入后即向后續(xù)數(shù)據(jù)處理線程發(fā)送數(shù)據(jù)到達事件消息。數(shù)據(jù)處理線程接收到達事件消息后，通過使用內(nèi)存地址交換技術，交換“數(shù)據(jù)交換緩沖區(qū)A”與“數(shù)據(jù)交換緩沖區(qū)B”的地址，對數(shù)據(jù)緩沖區(qū)B中的數(shù)據(jù)進行逐條處理。通過使用內(nèi)存地址交換技術，避免了直接交換內(nèi)存AB中的數(shù)據(jù)，節(jié)省了數(shù)據(jù)交換時間，提高了程序的數(shù)據(jù)處理能力。然而，此方法必須要保證多線程訪問數(shù)據(jù)緩沖區(qū)時嚴格同步，避免出現(xiàn)多個線程同時使用同一個數(shù)據(jù)緩沖區(qū)，同步避免了在進行數(shù)據(jù)緩沖區(qū)地址交換時出現(xiàn)線程訪問沖突的情況出現(xiàn)。通過使用C++中的全局鎖CRITICAL_SECTION以及EnterCriticalSection()和LeaveCriticalSection()函數(shù)的合理使用，保證各線程能協(xié)調(diào)使用各數(shù)據(jù)緩沖區(qū)，不會出現(xiàn)訪問沖突。

2.3 航班跟蹤及顯示處理

航班跟蹤及顯示是以GIS平臺為基礎，在地理信息平臺上通過疊加航班標識符、航班標牌、列表、速度剖面、油量剖面及高度剖面等跟蹤信息，實現(xiàn)航班飛行態(tài)勢的顯示。航班跟蹤及顯示子系統(tǒng)基于GDI繪圖庫構(gòu)建了大量的繪圖函數(shù)類，這些類分別完成飛行標識、飛行標牌等不同元素的繪制工作。航班跟蹤及顯示子系統(tǒng)通過接收來自定時器、MFC窗口界面、用戶操作等多種不同的消息，經(jīng)過消息處理中心處理后，實現(xiàn)對飛行態(tài)勢的動態(tài)更新顯示以及航班跟蹤。航班跟蹤處理流程如圖5所示。

航班跟蹤處理是基于“解碼數(shù)據(jù)交換緩沖區(qū)”來進行的，“解碼數(shù)據(jù)交換緩沖區(qū)”是一個靜態(tài)的全局的數(shù)據(jù)存儲緩沖區(qū)。前端數(shù)據(jù)處理功能模塊將經(jīng)過處理后的航班數(shù)據(jù)存入“解碼數(shù)據(jù)交換緩沖區(qū)”內(nèi)，航班跟蹤及顯示子系統(tǒng)則定期地從“解碼數(shù)據(jù)交換緩沖區(qū)”中提取航班數(shù)據(jù)，經(jīng)過坐標轉(zhuǎn)換后，將航跡數(shù)據(jù)坐標由WGS- 84大地坐標系轉(zhuǎn)換至屏幕坐標系下，通過各種顯示元素的繪圖類完成飛行態(tài)勢、標牌、速度、高度及油量剖面的繪制。

“解碼數(shù)據(jù)交換緩沖區(qū)”中存儲的數(shù)據(jù)經(jīng)過嚴格的維護以實現(xiàn)航班的跟蹤。由于系統(tǒng)接入的數(shù)據(jù)種類較多，包括ACARS、SSR、地基ADS-B、星基ADS-B數(shù)據(jù)，不同類型的監(jiān)視數(shù)據(jù)源中會存在著大量相同航班。因而，在完成航班數(shù)據(jù)的前端處理后，數(shù)據(jù)進入“解碼數(shù)據(jù)交換緩沖區(qū)”時必須進行數(shù)據(jù)關聯(lián)及融合。由于ACARS及ADS-B中的24位地址碼、航班號及機尾號(飛行國際登記號)均為航班關聯(lián)的唯一標識。而SSR以二次代碼(二次雷達代碼)為航班標識，但不同地區(qū)二次代碼可能出現(xiàn)重復，因而需要將二次代碼結(jié)合監(jiān)視數(shù)據(jù)源標識中的區(qū)域源代碼(SAC)及設備源代碼(SIC)字段才可完成航班關聯(lián)。完成關聯(lián)后的航班其狀態(tài)可以得到實時更新。

3 系統(tǒng)運行實例及性能測試

全球航班跟蹤系統(tǒng)實際運行狀態(tài)下系統(tǒng)部署情況如下：系統(tǒng)由三臺服務器、一臺高性能工作站組成，分別為一臺負載均衡服務器、兩臺前端數(shù)據(jù)處理服務器、一臺航班跟蹤及顯示工作站。負載均衡服務器完成數(shù)據(jù)接入及分發(fā)，同時監(jiān)控兩臺前端數(shù)據(jù)處理服務器的工作狀態(tài)和負荷情況，實時調(diào)整數(shù)據(jù)流量。兩臺前端數(shù)據(jù)處理服務器并行工作，分別處理一部分航班數(shù)據(jù)，同時互為備份，若其中一臺服務器出現(xiàn)異常，負載均衡服務器可以將數(shù)據(jù)計算分配至另外一臺前端數(shù)據(jù)處理服務器，以保證系統(tǒng)正常工作。系統(tǒng)引接一路二次雷達數(shù)據(jù)、一路地基ADS-B數(shù)據(jù)、一路ACRAS數(shù)據(jù)，實時在線監(jiān)視跟蹤國內(nèi)的所有航班及境外飛行的我國航班2 000余個。圖6為全球航班跟蹤系統(tǒng)實際運行界面截圖。

圖6 全球航班跟蹤系統(tǒng)運行效果

圖7為全球航班跟蹤系統(tǒng)在地理信息及航行情報資料顯示效果。顯示內(nèi)容包括行政區(qū)域邊界、河流、水域、路航線圖、飛行情報區(qū)地圖、機場地圖、危險區(qū)、限制區(qū)等。系統(tǒng)支持地圖的放大、縮小及平移操作。

圖7 系統(tǒng)地理信息及航行情報資料顯示

在實際運行的情況下對全球航班跟蹤系統(tǒng)的數(shù)據(jù)實時處理能力進行了測試。圖8為全球航班跟蹤系統(tǒng)在實際運行情況下，執(zhí)行一次數(shù)據(jù)處理所需要的時間，其中：橫坐標為系統(tǒng)完成一次數(shù)據(jù)處理時的數(shù)據(jù)量；縱坐標為數(shù)據(jù)處理所消耗的時間，消耗時間通過Windows操作系統(tǒng)API函數(shù)GetTickCount()函數(shù)獲取。

全球航班跟蹤系統(tǒng)在實際運行時，單批次處理的航班數(shù)據(jù)條數(shù)小于1 000條/次時，在進行小批量航跡數(shù)據(jù)處理時，由于系統(tǒng)流水線任務調(diào)度、線程同步等待等原因，每次處理數(shù)據(jù)平均耗時并不相同，但通常在50 ms以內(nèi)。當系統(tǒng)處理的數(shù)據(jù)量達到12 000條/次以上時，系統(tǒng)處理數(shù)據(jù)耗時也相應變長，但整體數(shù)據(jù)處理耗時均小于350 ms。測試結(jié)果表明系統(tǒng)整體數(shù)據(jù)處理延遲較小，能夠滿足全球航班跟蹤系統(tǒng)任務要求。

4 結(jié) 語

本文提出一種可行的全球航班跟蹤系統(tǒng)設計方案及各個關鍵功能單元的詳細架構(gòu)和處理流程設計，并針對全球航班跟蹤應用場景中面臨的大批量、高并發(fā)航班數(shù)據(jù)處理問題，給出了具體的優(yōu)化設計方法。通過設計可拓展的硬件處理架構(gòu)，同時結(jié)合多線程軟件處理架構(gòu)設計，保證了系統(tǒng)流暢穩(wěn)定運行。系統(tǒng)實際運行結(jié)果良好，實現(xiàn)了對我國境內(nèi)的所有航班以及在境外飛行的我國航班的跟蹤監(jiān)視，我國航班覆蓋率達到87%。系統(tǒng)操作流暢，運行穩(wěn)定，實時性高，滿足了對我國航班境內(nèi)飛行的所有航班及境外飛行的我國航班的全球跟蹤要求。