AGV + 协同调度：把“卡在电梯口”这件事彻底做没
你在现场最常见到的“系统性堵点”，往往不是 AGV 不够快，也不是提升机速度不够，而是 AGV 与提升机的协同调度没做成一个系统：
车到了、门不开；门开了、车没来；上层在等、下层在堵；一堵就全线掉效率。
这篇文章把“AGV + 提升机协同调度”拆成一套客户也能听懂、工程也能落地的关键点：
你只要抓住这些点，就能把吞吐、等待、拥堵、故障恢复、扩容成本一次性管住。
01 先把问题说透：为什么“电梯口”最容易爆炸？
在多楼层立体物流里，提升机（或货梯/垂直输送）天然是稀缺资源：
- 提升机是单通道服务台：一次只能服务有限的请求（上/下、单车/多车、单层/多层）。
- AGV 是多主体并发：车越多、调度越频繁，越容易把“稀缺点”挤爆。
- 跨楼层导致不确定性放大：门禁联锁、对位、层门开闭、站台空满、网络时延，都让“预计时间”变得不准。
所以协同调度的本质只有一句话：
把提升机从“被动响应”变成“可预约、可预测、可控的产能资源”。
02 协同调度的目标不是“跑起来”，而是 4 个指标
很多项目调度做完能跑，但效率长期上不去。因为目标没定义清楚。
建议你把协同调度目标明确成 4 个 KPI（越清晰越不扯皮）：
- 吞吐（Throughput）：每小时跨楼层完成的搬运任务数（单梯/全系统）
- 等待（Wait Time）：AGV 在电梯口平均等待时间、P95 等待时间
- 拥堵（Congestion）：电梯口队列长度、阻塞时长、死锁次数
- 恢复（Recovery）：故障发生后恢复时间、任务回滚与重派成功率
现场一句话判断：
平均值看上去不错不算赢，P95/P99 一烂就会“现场天天吵”。
03 系统架构：谁是“大脑”？三种主流模式
协同调度必须先回答：谁来统一决策？
模式 A：WCS/调度平台统一下发（推荐）
- WMS/WES 发任务 → WCS 统一编排 → AGV 调度 + 提升机 PLC/控制系统协同
- 风险：WCS 设计要足够强，否则会变成“单点瓶颈”
模式 B：AGV 调度主导，提升机被动配合
- 风险：提升机能力、站台容量、跨楼层规则难以全局优化，容易“局部最优导致全局堵”
模式 C：提升机系统主导，AGV 适配
- 风险：AGV 侧需要深度改造，生态不如 A 模式顺
工程建议：
做长期可扩展项目，优先选 A。
临时改造/单梯小规模，B 也能跑，但要把“堵点预案”写死。
04 协同调度的“关键点清单”：别讲概念，讲控制点
下面这些是决定你能不能“稳定高效”的控制点。
4.1 资源建模：把提升机当成可计算产能
至少要建模这些参数（不建模=只能靠感觉调）：
- 单次服务周期：进梯 → 对位 → 门开闭 → 出梯 的标准时间
- 上/下行切换代价：方向切换损耗、回程策略（是否空跑）
- 可并行能力：是否支持双工位/双入口/双出口/双层站台缓冲
- 约束条件：门禁联锁、层门互锁、人员安全区、限位与急停逻辑
结论：提升机不是“一个点”，而是一个“有限状态机”。
4.2 预约机制：没有预约，就只有排队和骂人
协同调度一定要做 Elevator Slot（时隙预约）：
- AGV 申请：
请求跨楼层 + 预计到达时间 ETA + 任务优先级 - 提升机回执：
确认时隙 + 指定入口/层站 + 超时策略
核心要点：
- 没有“超时释放”，就会出现“资源被幽灵任务占用”。
4.3 电梯口的“缓冲区设计”：这是效率的保险丝
电梯口不是越小越好，关键看峰值与波动：
- 最少要有“等待缓冲位”：避免 AGV 停在主干道上
- 要有“溢出策略”：队列过长时，AGV 去哪里等？去哪个分区绕行？
- 要有“回退位”：门不开/对位失败/有人进入安全区时，AGV 如何撤离？
现场经验：
90% 的拥堵不是梯里堵，是梯口堵；
90% 的梯口堵不是车不够聪明，是没有缓冲设计。
4.4 任务分流：不是所有跨楼层都该抢同一台梯
当系统有多台提升机或多条垂直通道时：
调度规则要写成“可解释”：
客户最怕黑盒，一旦效率掉了没人能解释原因。
4.5 优先级体系：别用“拍脑袋优先级”
优先级建议至少分三层：
- 系统优先级（效率）：减少空跑、减少方向切换、减少长等待
关键：
业务优先级不能无限压系统优先级，否则会出现“紧急单拖死全场”的灾难。
4.6 死锁与拥堵：要在“发生前”就阻断
常见死锁链路：
必须具备的机制：
4.7 异常处理：协同调度的“分水岭”
能跑和能稳定跑，差在异常处理。
建议把异常分成三类并固化策略：
轻微异常（可自愈）：通讯抖动、轻微延迟、短暂占用
→ 自动重试、时隙延长、局部绕行
中度异常（需要回滚）：对位失败、门禁触发、入口占用超时
→ 任务取消/回滚、释放时隙、重派到其他梯或延后
重度异常（系统降级）：提升机故障停机、安全回路触发、关键传感器失效
→ 跨楼层任务冻结、人工介入流程、备用通道启用、恢复后任务一致性校验
你要盯住一句话：
异常发生时，系统有没有“自动释放资源”的能力。
没有的话，现场会把故障从“1 台设备”放大成“全线瘫痪”。
05 调度策略怎么选？给你 5 种可落地策略（按成熟度排序）
策略 1：先到先服务（FCFS）
策略 2：方向优先（Directional Batch）
- 风险：另一方向可能被饿死 → 必须加“最大等待阈值”
策略 3：时隙预约 + ETA 校准（推荐起步）
策略 4：分区队列 + 动态改派（高效）
策略 5：全局优化（仿真/求解器/强化学习等）
- 风险：上线周期长、解释成本高，建议先用策略 3/4 打底
06 接口与数据：你要什么“最小闭环”？
要协同调度，最少要打通这些信号/数据（缺一个都会变成黑洞）：
AGV → 调度/提升机
提升机 → 调度/AGV
调度平台必须沉淀的日志
没有日志就没有复盘。
没有复盘就没有持续提升。
07 验收怎么验？别只验“能跑”，要验“峰值与故障”
建议把验收场景写进测试计划（否则后期扯皮）：
- 峰值压力测试：模拟高峰订单，队列是否爆，P95 等待是否超标
- 通讯抖动测试：短时网络异常，时隙是否释放，任务是否回滚
- 故障恢复测试：提升机停机后，跨楼层任务如何冻结与重派
- 人工介入测试：现场人员介入后，系统如何一致性对账（货在哪、任务在哪）
08 客户最关心的 6 个问题（你可以直接拿去做销售沟通）
“车多了会不会更堵？”
关键看是否有时隙预约 + 队列上限 + 缓冲区设计。车多不一定更快，没设计会更堵。
“一台提升机能扛多少产能？”
用“服务周期”估算：单次跨楼层平均耗时 × 峰值请求量，给出吞吐与冗余建议。
“故障会不会导致全线停？”
看有没有资源释放、任务回滚、备用通道与降级策略。没有就会“一故障全瘫”。
“要不要上复杂算法？”
先把预约、缓冲、异常闭环做对，效率能上一个台阶；复杂算法是锦上添花，不是救命稻草。
“后期扩容怎么做？”
关键在架构模式与接口标准化。A 模式扩容最便宜，B/C 模式扩容容易被供应商锁死。
“怎么保证安全？”
安全联锁永远优先于效率；调度必须理解门禁/互锁/急停逻辑，否则必出事故隐患。
09 一页结论：你只要盯住这 10 条就不会跑偏
10 如果你正在选型/改造：我建议你这样提需求（模板）
你可以把下面这段直接丢给供应商，能快速筛掉“只会说概念”的：
1）请给出 AGV+提升机协同调度的架构模式（WCS 主导/AGV 主导/提升机主导）与边界责任；
2）必须提供时隙预约机制：申请、确认、取消、超时释放、改派；
3）必须给出电梯口缓冲区方案：容量、回退位、溢出策略；
4）必须提供死锁预防策略：入口互斥、队列上限、出梯口空满校验；
5）必须提供异常分级与恢复策略：自愈/回滚/降级；
6）必须提供全链路日志字段与报表：吞吐、平均等待、P95 等待、拥堵时长、故障恢复时间；
7）验收测试必须覆盖峰值与故障恢复场景，明确指标阈值。
最后一句话
AGV+提升机协同调度，拼的不是“算法名词”，而是把 预约、缓冲、互斥、异常释放、日志复盘 这些硬功夫做扎实。
你把这些关键点抓牢，系统就不会在“电梯口”崩盘，产能也能持续爬坡。
