4. 调度系统架构

在 AMR/AGV 仓储物流系统中，调度系统是连接“业务订单”与“机器人执行”的中枢。它决定谁去执行任务、走哪条路径、何时避让、如何与 WMS/WCS/MES 对接。理解调度系统架构，核心是回答三个问题：决策放在哪里、数据如何流动、任务如何被拆分与闭环。

一、集中式与分布式架构：决策权的两种放置方式

集中式架构由一台或一组主调度服务器统一维护全局地图、车辆状态、任务队列与交通管制。所有机器人上报位置与状态，服务器计算任务分配和路径，再下发指令。优点是全局最优性好、交通管制简单、状态一致性强；缺点是服务器是单点瓶颈，机器人数量增多时计算与通信压力大，网络抖动会直接影响全局。

分布式架构把部分决策下放到机器人或区域节点。机器人自主完成局部路径规划、避障和冲突协商，调度中心只负责宏观任务分配与区域协调。优点是扩展性强、单点故障影响小、响应快；缺点是全局一致性难保证，容易出现死锁或局部拥堵，调试和运维复杂度更高。

实际工程中更常见的是混合架构：任务分配、跨区交通管制由中心负责，局部避障、同区域让行由机器人或边缘节点自主完成。这样既保留全局可控性，又降低中心负载。

二、云边端协同：把算力放在最合适的位置

云边端协同的本质是分层决策。云端负责订单接入、全局任务编排、跨库区调度和大数据分析；边缘节点部署在仓库现场，负责区域内的任务分派、交通协商和实时性要求高的计算；端侧机器人负责定位、避障、执行动作和安全保护。

典型数据流是：WMS 下发出库单 → 云端拆解为搬运任务 → 边缘节点按区域分派给最近空闲车 → 机器人执行并持续上报位姿 → 边缘节点更新区域状态 → 云端汇总全局进度。这样，即使云端短时不可用，边缘节点仍可维持区域内运行，提升系统可用性。

三、通信协议：可靠、实时、可扩展

调度系统内部通信通常分为三层：云端与边缘节点之间、边缘节点与机器人之间、机器人与外围设备之间。常见协议选择如下：

协议选型要关注三点：消息可靠性（是否丢包重传）、实时性（端到端时延）、可扩展性（新增机器人或区域是否方便）。例如，位姿上报可用 MQTT 的 QoS1，控制指令则更适合 TCP 长连接，避免重复执行。

四、任务管理模块与系统集成方式

任务管理模块通常包含任务接入、任务拆解、任务分配、任务执行、任务监控和任务闭环六个环节。一个出库任务可能被拆成“去 A 货架 → 举升 → 搬运至 B 站台 → 放下 → 返回待命区”多个子任务，每个子任务都有状态机。

任务状态机示例：
CREATED → ASSIGNED → EXECUTING → ARRIVED → COMPLETED
              ↓            ↓
           CANCELED     EXCEPTION → 人工介入 → 重新分配

系统集成方式主要有三种：API 直连，调度系统暴露 REST/gRPC 接口，WMS 直接调用；消息中间件，通过 Kafka/MQTT 解耦，适合多系统异步协作；中间表/文件交换，适合老旧系统改造，但实时性较差。实际项目中常组合使用：订单用 API，状态用消息推送，异常用中间表兜底。

五、场景复盘：从集中式到混合架构的演进

某电商仓初期采用集中式调度，30 台 AGV 运行稳定。扩展到 120 台后，中心服务器 CPU 长期高于 85%，交通管制计算耗时增加，出现局部拥堵和任务超时。改造方案是：将仓库划分为 6 个区域，每个区域部署边缘节点，负责区域内任务分派和冲突协商；云端只保留全局任务池、跨区调度和 WMS 接口。改造后，中心负载下降约 60%，任务平均响应时间从 800ms 降至 260ms，单点故障也不再导致全仓停摆。

这个案例说明：架构选择不是“越集中越好”或“越分布越好”，而是要根据机器人规模、仓库分区、网络条件和业务实时性要求做权衡。小规模场景可先用集中式快速上线；规模扩大后，再通过边缘节点逐步下沉实时决策，形成云边端协同的混合架构。

落地时建议按以下清单检查：任务状态机是否完整、通信协议是否匹配实时性、边缘节点是否具备断网续跑能力、WMS 接口是否有幂等设计、异常任务是否有回滚与人工介入通道。把这些基础打牢，调度系统才能从“能跑”走向“稳定高效地跑”。