為飛行程序生成「數字孿生」_風聞
李及李-李及李数据分析公司创始人-数据驱动，分析导向， 为航空和汽车竭尽全力。2021-11-15 10:42
文 | 李瀚明一李及李
最近非常巧的是業界對空管管制程序優化頗為關心——梁老師在「羽田機場的新航路」文下留言，問我能否具體解釋羽田機場的新飛行程序；黎老師發文提及了「自適應的管制」系統；同時，在這一次的上海之旅中，也很榮幸向有識者解釋KSFO的飛行程序。
我們總結了我們和外國空管當局為 RJTT 和 KORD、KSFO、KEWR 探討飛行程序改進方法時的核心思路——為機場及其附近的進離場程序及管制控制系統建立「數字孿生」，通過與之配套的數學模型提供服務。
在設計管制控制系統的時候，控制的自變量很好理解——進近區域內的各種情況（例如天氣等）。但是控制的因變量是什麼？
如果將控制的因變量設置為每一班即將進離場的飛機接下來的軌跡，你會發現決策高度複雜——因為軌跡由若干個首尾相連的線組成。對軌跡建模有兩種方法：一種是描述飛行過程，基於慣性導航的矢量線段（距離、航向角、俯仰角、速度）；另一種是描述飛行結果，基於 GNSS 的四維點（經度、緯度、海拔、時間）。
無論是哪一種做法，系統都需要計算每一班航班的每一個控制點。在大量航班的背景下，這樣的成本是非常離譜的——即使是 FAA 也無力負擔這樣的系統。
因此，我們必須將飛行程序與其對應的軌跡枚舉化。此時，因變量中涉及空間的部分縮小為飛行程序對應的枚舉索引，得以大大降維。
我們以最簡單的按照風向決定跑道的系統舉例。這個系統只有一個決策層：吹北風的時候，使用飛行程序 ILS 36；吹南風的時候，使用飛行程序 ILS 18。更復雜的決策因素包括時間（在夜間使用減噪程序）、飛行方向（獨立平行運行時跑道的分工），雲層（決定細分飛行程序）等。
但是，因變量中涉及時間的部分怎麼辦呢？我們從一張顯示飛機落地時間的時刻表開始：
我們可以將其轉變為小時定圖：
從西向、南向，按 0、10、20、30、40、50 的頻率，每 10 分鐘一班；
從東向，北向，按 5、15、25、35、45、55 的頻率，每 10 分鐘一班；
假設每架飛機佔用資源 1 分鐘，熟悉信號處理的朋友，應該可以立馬將其頻率化：
西向南向遵循一個頻率為 6 班/小時，初相為 0 分鐘，佔空為 1 分鐘的方波；
東向北向遵循一個頻率為 6 班/小時，初相為 5 分鐘，佔空為 1 分鐘的方波。
從而可以對其進行傅立葉變換。因此一連串的飛機的時間因素，就簡化成了兩個變量：
飛機之間的間隔（頻率）
第一架飛機的到達點（初相）
此時，波可以方便地進行合成——例如，在只有一條跑道的時候，兩個方向的「飛機波」就合成為一個頻率為 12 班/小時，初相為 0 分鐘，佔空為 1 分鐘的方波。
可以看到的是，因變量縮小為每個飛行程序兩個要素：其中一個（頻率）對應的是小時容量，而另外一個（相位）則用於處理突發情況。
例如，當大霧使得小時容量降低到了 6 班/小時，我們就需要進行頻率過濾：
一部分飛機（6 班）可以繼續進近，按照頻率為 6 班/小時，初相為 0 分鐘，佔空為 1 分鐘的方波繼續運行；
另一部分飛機（6 班）則無法進近，則需要按照另一個方波進行盤旋、復飛、備降等操作。
而當降落飛機延遲 1 分鐘離開跑道時，所有後續飛機都需要延遲 1 分鐘落地。此時相當於初相延後 1 分鐘。這樣的話，在進近程序點就可以對所有飛機統一執行特定進近程序：
需要改變初相時，可以通過迂迴（抄近路縮短，繞遠路延長）調整飛機集羣中間的頻率和間隔（而不影響集羣內部的頻率和間隔）。「長五邊」和「短五邊」就是一個例子。
需要改變頻率時，可以通過 Missed Approach 等方法令飛機離開進近程序。
接下來，我們需要為優化算法準備飛行程序。可以看到的是，對優化算法而言，輸出頻率和相位（而非每一架飛機的具體飛行軌跡）降低了模型設計的工作量。但是，在管制實踐中，始終還是需要通過指揮飛機調整頻率和相位的。因此，我們需要將空路「鐵路化」。
在鐵路行業的實踐中，有被稱之為 PTC（程序化交通控制，Programmed Traffic Control，包括自動列車車速控制、自動道岔進路控制、延誤恢復三大系統）的列車運行控制系統。列車運行控制系統的其中一個核心，是對道岔之間的鐵路路段（相當於民航運行中，同一航路上各航路點之間執行特定飛行程序的路段）的精確建模（也即現在俗稱的「數字孿生」）：
該路段有多長？限速多少？
列車（飛機）以特定速度通過該路段需要多久？
該路段在不同的限速下，能同時容納幾架列車（飛機）？
因此，鐵路系統可以通過 CTC（集中交通控制 Centralized Traffic Control）下發速度指令，由 ATO（自動列車運行系統）調整列車的速度，通過PRC（程序進路控制 Programmed Route Control）調整道岔（也即列車的行車路徑），從而調整列車之間的相互間隔和相位。在這樣的情況下，在較簡單的鐵路系統中，列車甚至可以不設置駕駛員（例如國內有上海地鐵 10 號線、15 號線等）。
對於飛行程序路段而言，除了第三條不適用以外模式基本相同。但是，飛行程序的管制仍然無法使用 CTC 和 PRC 等程序化手段，而必須依靠管制員進行（CTC 的職能由管制員調速代替，而 PRC 功能則由雷達引導代替）。換言之，這就有一個問題——我們什麼時候能夠迎來程序化的航空管制？
我們在和美日空管單位的合作中共同對程序化管制進行了不少研究。目前而言，程序的設計不是問題（剛剛的全文基本已經講清楚了程序設計的思路），但是程序的告知和執行問題很大。我們正在評估多種告知和執行的方法。
一種方法是 ACARS 法：空管將當前飛行程序通過 ACARS 上行數據報文發送給機組，機組將數據報輸入 FCU / FMS 完成程序執行。這種方法的優點在於時間靈活——可以在航班離港前輸入預報，並在進入進近管制區前更新最新的現報。但是缺點也很明顯——要同時通報大量飛機。
另一種稍微方便一點，可以向多架飛機的是 ATIS 方法——但 ATIS 方法基於語音這一非結構化數據而非結構化數據包，會成為非常巨大的問題。
因此，在程序化的航空管制中，飛機和空管單位之間的結構化數據傳輸網絡非常重要。這個系統需要以結構化為載體，並支持複雜的網絡拓撲（例如廣播 Broadcast、單播 Unicast）。同時，在其上傳輸的結構化數據還需要能夠導入包括FCU在內的飛行電腦中，從而減少飛行關鍵階段的人工操作。
這並不是一個容易的事情——事實上，這一標準的制定者會在未來至少十年中，享受作為領頭人的技術紅利。ADS-B in 是一個重要的技術突破——但是 ADS-B in 傳輸的信息太單一，將信息限制在了飛行器的位置等原始數據，缺乏對決策數據的支持。FIS-B（Flight Information Services-Broadcast）或許是一個擴展性的解決方案（在既有的 ADS-B 上擴展飛行信息）。
為此，參與試驗的航空公司需要和空管當局密切合作。我們很高興能夠和客户一起參與到這一過程中，也希望能和世界其它地方的民航當局共同溝通，改進繁忙區間的空管效率，降低空管工作壓力。