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