eVTOL多机队排班：从约束建模到动态调度实战-平芜编程栈

低空经济最热闹的时候，大家聊的都是 eVTOL 原型机、电机功率和航程数据。但真正开始跑运营之后，第一个让我失眠的问题其实很朴素：好几架飞机同时挂在几条航线上，航班表到底怎么排？

这个问题的复杂度远超一般人的想象。它不是简单的“几架飞机轮流飞”，而是要在续航限制、充电时长、站点容量、机组工时和客流波动之间找平衡。排得好，机队利用率能翻一倍；排不好，再先进的载人飞行器也只能停在起降点上晒太阳。

这篇文章我想聊的，就是多架 eVTOL 排班这件事。既包含我参与过的实际项目里摸出来的约束条件和参数，也包括一套可以落地的排班算法路径，最后是排班系统上线后容易踩的坑。适合正在做低空运营方案的朋友，也适合准备入行的算法工程师、产品经理参考。

要理解排班问题，得先接受一个前提：eVTOL 不是“会飞的出租车”这么简单，它更像是资源密集型公共交通系统里的一个节点。飞机本身是资源，电池是可耗竭资源，起降点是有限资源，机组是受限资源。所有资源叠加在一起，才构成排班问题。

1.1 四个硬约束：续航、充电、站点、机组

先看一组我常用的典型参数。不同机型的数值会有差异，但整体量级差不多：

参数	典型数值	对排班的影响
满载续航	200-300 km	决定最大任务环长度
巡航速度	150-200 km/h	决定航段飞行时间
标准座位数	4-6 座	决定单位运力
电池快充时间	30-40 分钟	决定周转间隔
安全电量阈值	SOC 20% 以下禁飞	决定飞机可用窗口
起降点停机位	单站 2-6 个	决定并发航班上限

这里最容易被忽略的，是安全电量阈值。很多初做排班的人看到 250 公里续航，下意识就按“飞 200 公里还剩 20%”来排。但实际运营中你会发现，电池在低温、高载重、大功率爬升等场景下，掉电极快。所以我习惯用“可用巡航里程 = 理论续航 × 0.75”这个经验系数。也就是说，标称 250 公里的飞机，单次任务环我只会按 180-190 公里去排。

充电策略同样关键。eVTOL 普遍没有换电条件，只能等充电。这就意味着飞机落地后不是结束任务，而是进入另一个排队队列。如果起降点只有两个充电桩，同时降下来三架飞机，第三架就得干等。这种排队关系会让整个调度表瞬间失效。

1.2 排班到底在优化什么：从“排得出来”到“排得好”

初版排班方案一般追求两个字：能用。也就是每架飞机按固定时刻表飞固定航线，确保不会出现电量耗尽或起降点冲突。但一旦进入多航线、多机队阶段，“能用”就远远不够了。

我在项目里会把排班目标拆成四个层次，按优先级排列：

安全红线：任何情况下，飞机不能在航段中触发低电量告警。
准点率：乘客对低空出行的预期和民航一样，延误 15 分钟以上就算事故。
资产利用率：每天每架飞机的飞行小时数，能不能从 4 小时拉到 6 小时，直接决定单机盈利模型。
电池寿命：锂电循环次数固定，同样的 SOC 区间，放电深度越浅，电池衰减越慢。

这四个目标并不总是统一。比如追求高准点率，就需要每架飞机多留电量余量，压缩任务环长度，这又会拉低利用率。追求高利用率，又可能让电池始终在极限 SOC 区间往返，几个月后容量衰减明显。

所以排班本质上是一个多目标优化问题，而且约束比目标更硬。项目启动时，我和运营团队花了大量时间梳理约束条件，而不是急着写算法。因为约束定义不清晰，后面所有优化都是空中楼阁。

2. 排班算法选型：为什么纯贪心会崩，工程上该用什么

排班问题摆出来后，第一反应通常是写个贪心：航班需求按时间排序，有空闲飞机就派出去，电量不足就排队充电。这个思路在机队规模小、航线固定、运力远大于需求的时候完全够用。但一旦进入真实运营场景，贪心方案会在三个地方翻车。

第一个翻车点是并发冲突。当多个航班需求在同一时间窗口内出现，而可用的飞机和起降点都不够时，贪心策略只会按“先到先得”处理。结果可能是优先级低的航线占用了稀缺资源，后续高价值航班被迫延误，整体损失更大。你排出来的解合法，但远不是最优。

第二个翻车点是不确定性。低空飞行对气象条件非常敏感。一阵侧风超过飞行包线，原定 10 分钟后的航班就得取消。贪心算法一旦遇到这种扰动，只能重新排队，而且重排的结果往往跟之前的航班链冲突，造成大面积延误。

第三个翻车点是任务链断裂。贪心默认每个航班是独立的，但在实际调度里，飞机飞完 A 到 B，往往要继续飞 B 到 C，形成一条航班链。如果中间某个航段延误，整条链上后续所有航班全部受影响。贪心不会做全局补偿，它只是机械地往后顺延，导致延误指数级扩散。

2.1 工程上更稳的方案：规则约束 + 元启发式 + 滚动修正

我后来在项目里采用的方案，是三层结构的组合：

第一层：规则约束。把所有安全约束、站点容量约束、机组工时约束写成硬规则，任何候选解先过规则筛子，不满足的直接淘汰。
第二层：元启发式优化。在满足规则的前提下，用禁忌搜索或模拟退火迭代优化航班链，目标是最大化运行效率和准点裕度。
第三层：滚动时域修正。每 10-15 分钟用实时数据重排一次“未来 2 小时”的调度计划，吸收延误、临时取消和新增需求。

为什么不用更复杂的深度强化学习？说实话，低空运营场景的数据量还远远不够训练一个稳定的智能体。我在试点项目里测过类似思路，效果受数据噪声影响极大，现场排障也很痛苦。元启发式方法虽然听起来不如深度学习“高级”，但胜在可解释、可调参、易于人工兜底。工程上，优先选可控性强的方案，而不是选听起来最前沿的方案。

2.2 从数学上理解排班问题：它为什么是 NP 难的

排班问题在学术上属于“带资源约束的车队调度问题”，可以归约为多旅行商问题的一个变种。每架飞机是一个旅行商，每个航段是一个访问节点，而充电、站点容量、机组工时就相当于资源约束。解空间随着飞机数和航段数指数膨胀。

我在做方案评审时常举一个例子：假设一个枢纽站点有 5 架 eVTOL，每天要飞 120 个航段，每个航段可以分配给任意一架满足电量约束的飞机。粗略估算，组合数量级就已经超过了普通穷举能处理的范围。所以工程上都会采用“先找可行解，再在邻域内逐步改进”的思路，而不是一股脑追求全局最优。

禁忌搜索在这里的优势是：它维护了一张禁忌表，避免反复回到刚搜索过的局部最优区域。配合邻域操作，比如“把航班链上某两架飞机的后续航段互换”，能在十几分钟内得到一个质量不错的次优解，这已经足够驱动一天的前期排班表。

3. 一套可落地的排班方案设计（含参数与实现流程）

下面聊具体怎么落地。这个方案基于我在某低空运营试点项目里的真实实践，包含完整的流程、参数和关键逻辑。你可以直接拿去做方案原型，也可以根据自身机型数据调整细节。

3.1 数据准备：先把输入字段定义清楚

排班系统跑得再准，前提是输入数据准确。我梳理过一套必须提前收集的字段清单，缺了任何一个都会在运行时出问题：

航班需求表：航班号、起降点对、计划起飞时刻、预计乘客数、优先级。
机队状态表：飞机编号、当前 SOC、最大续航、已飞行小时、电池健康度 SOH。
起降点能力表：站点 ID、可用停机位数、充电桩数量、高峰时段排队规则。
机组排班表：机长/副驾资质、连续执勤时长、剩余休息时间。

这里有一个经验：SOC 数据的采集频率建议做到 5 秒一次，而不是每分钟一次。因为 eVTOL 爬升阶段的功率变化很快，如果数据粒度太粗，排班系统拿到的是一个“平均电量”，算出来的续航余量误差可能达到 8%-12%，这在低空飞行里是相当危险的误差。

3.2 核心排班流程：从预排到发布分成四步

完整的排班流程我拆成四步。第一步是航段合并与航班环构建，第二步是电量可行性校验，第三步是站点容量冲突检测与消解，第四步是滚动重排。

航段合并这一步，目的是把点对点航班拼成“航班链”。比如一架飞机从枢纽 A 出发，依次飞 A-B、B-C、C-A，最后回到 A，这就是一条闭环航线。拼链的核心原则是衔接时间要大于最小周转时间，同时保证整条链的电量消耗不超过可用电量。

电量可行性校验我用的公式比较保守：

预测耗电 = 飞行时间 × 平均功率 + 起降阶段额外耗电 × 起降次数 可用电量 = (当前 SOC - 安全阈值) × 电池容量 要求：预测耗电 ≤ 可用电量 × 0.9（额外留 10% 余量）

平均功率怎么定？我会用该机型的历史飞行数据统计，而不是出厂理论值。因为在真实低空飞行中，风速、温度、载重都会拉高实际功率。我见过最夸张的一例，某个航段的实际耗电比理论值高出 23%，原因是遇上持续逆风，这也是低空排班必须看实时气象模型的原因。

3.3 站点容量冲突消解：滑动时间窗法

站点容量是最容易在静态排班里被忽视的约束。两个航班计划在同一时刻到达同一站点，但站点只有两个停机位，就必然有一个需要空中等待或绕飞，这会额外消耗电量并影响准点率。我采取的做法是滑动时间窗检测：

def check_slot_conflict(schedule, station, window_minutes=15): # 将航班按计划到达时刻排序 arrivals = [f for f in schedule if f.arrival_station == station] arrivals.sort(key=lambda x: x.arrival_time) # 滑动窗口检查重叠 stack = [] for f in arrivals: while stack and f.arrival_time >= stack[0].departure_time: stack.pop(0) stack.append(f) if len(stack) > station.slots: return f # 返回第一个冲突航班 return None

这段逻辑做的事，是把每个站点的到达航班放进一个 15 分钟的时间窗，窗口内同时占用停机位的航班数不能超过物理停机位数。一旦发现冲突，就触发重排：优先调整低优先级航班的起飞时刻，或者在起飞前延长地面滑行等待时间，尽量把到达冲突化解在空中阶段之前。

我在实际项目里发现一个很反直觉的现象：站点容量问题没有出现在高峰时刻，而是出现在返程晚高峰。早上出发的航班和下午返程的航班在枢纽站高度重叠，导致停机位被占满，返程飞机只能在空中盘旋等待。后来我们调整了策略，把部分返程航班错峰 15-20 分钟，站点利用率明显改善。

3.4 动态扰动处理：延误、插单和天气变化

静态排班表只是起点，上线运行后大概率会被各种扰动打乱。我总结了三种高频扰动，以及对应的处理策略。

第一种是单航班延误。处理动作是重新计算延误航班所属航班链上的所有后续航段。如果延误小于 15 分钟，通常只需要把后续航段整体顺延；如果延误超过 30 分钟，那就需要考虑从备用机队里调其他飞机顶替后续航段，避免延误扩大。

第二种是临时新增航班。低空包机业务经常会有临时需求。我的做法是建立“热备用”机制：在枢纽站常备一架电量在 90% 以上、机组状态满足起飞条件的飞机。虽然这会牺牲一点利用率，但换来的是对临时订单的即时响应能力，综合收益更高。

第三种是恶劣天气导致的大范围禁飞。这种情况下，所有航班链直接冻结，系统进入“恢复模式”。恢复模式的逻辑是按优先级重新排序：先飞高优先级航班，同时利用地面时间给所有飞机补电，制造充裕的电量余量，等天气窗口打开时可以连续执行多个航班。

4. 我踩过的坑：排班系统上线后最容易翻车的三个环节

任何排班系统从开发到稳定运行，都会经历一段“每天排故障”的时期。下面这几个坑不是教科书上写的，都是一线现场真实发生的事情。

4.1 电池仿真模型过于乐观，导致大面积临场改签

第一版电量模型用的是“容量 × 等效电路”仿真，充电曲线、放电曲线都是标准数据。结果上线第一天就出现两架飞机同时低电量告警。排查后发现，模型没有考虑电池内阻随温度和 SOC 变化的影响。在高温天气下，电池内阻增加，实际放电容量比标称少了近 12%。

从那以后，我在电量模型里增加了一个温度修正系数：

有效容量 = 标称容量 × 温度系数 × (1 - SOH衰减率) 温度系数 = 1 - 0.004 × abs(当前温度 - 25)

不同电池化学体系对应的温度系数差异很大，我当时这个系数是在统计了两个月实测数据后拟合出来的。做排班系统时，如果厂商给了电池模型，也建议自己再跑一遍多温度压测，别直接拿来即用。

4.2 航班链断裂引发级联延误，比单点延误更头疼

单航班延误，系统重排一下就完事。真正麻烦的是延误传导。有一次某个枢纽站因为充电桩故障，原定 14:00 起飞的飞机推迟到 14:30。表面看只是晚了 30 分钟，但这架飞机后面的三段航程全被波及，到达终点站的时间超过了停运窗口。最后只能取消末段航班，乘客改签，损失很大。

处理这类问题的核心思路，是给每条航班链设置“延误熔断阈值”。我定的规则是：如果某个航段的延误预期超过 20 分钟，就启动断链重组，而不是继续顺延。具体操作是把后续航段拆出来，分配给其他电量足够、时间窗口匹配的飞机。这样单点故障不会拖垮整条链，代价可能是某架飞机多飞一段，但整体准点率更有保障。

4.3 数据链路时延过长，导致调度决策基于 3 分钟前的状态

eVTOL 本身传感器数据链路上云再下发，通常有数秒到数十秒的时延。排班系统判断“飞机当前可飞”用的是云端最新数据，但如果时延超过 30 秒，飞机可能已经进入爬升状态，电量和位置都变了。调度指令发出后，往往跟不上实际状态。

后来我们把关键决策数据改成“本地边缘节点 + 云端同步”双路结构。起降点现场的调度终端直接读取本场飞机的实时遥测数据，云端只负责跨站点协调。这个改动让决策时延从 3-5 秒降到 300 毫秒以内，效果立竿见影。

4.4 常见问题速查表

故障现象	可能原因	排查与解决
飞机低电量告警比预期早	电量模型未考虑温度修正	增加温度系数、降低可用电量余量
同站多个航班空中等待	静态排班未预检站点容量	加滑动时间窗容量检测
某条航班链连续多个航班延误	单点延误未及时断链	设置延误熔断阈值，触发断链重组
调度指令滞后严重	云端数据时延过长	关键决策改为边缘节点读取遥测
低优先级航班长期被插队	优先级权重设置不合理	把优先级拆成“单程收益+准点影响”两个维度