为飞行程序生成「数字孪生」_风闻
李及李-李及李数据分析公司创始人-数据驱动，分析导向， 为航空和汽车竭尽全力。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 上扩展飞行信息）。
为此，参与试验的航空公司需要和空管当局密切合作。我们很高兴能够和客户一起参与到这一过程中，也希望能和世界其它地方的民航当局共同沟通，改进繁忙区间的空管效率，降低空管工作压力。