AGV调度：综述

        这是我在参与AGV调度系统开发工作中形成的一些认识，是我的个人观点，想到什么写到什么。我自己也在学习，有不同观点可以一起讨论，文章内容仅供参考。

        AGV调度系统，一般也叫RCS系统（下称RCS），主要是进行AGV车辆调度的系统，RCS需要根据上层系统提交的任务订单，对任务进行拆分、规划、配车和下发并处理任务执行过程中出现的场景交互和交管问题。其核心在于调度车辆时的交通管制模块，这也是目前业内面临的最难处理的问题。除车辆交通管制外，一般还会有车辆模块、规划模块、任务模块、接口模块、场景模块、库位模块和自动策略模块（自动待命与自动充电等）。

图来自网络，侵删

        目前各家的RCS大差不差，用的东西和有的东西都差不多。在交管算法上没有突破之前，其实各家的技术壁垒并不高，更多是比拼运营、实施经验和品控（包括RCS系统本身的稳定性）等因素。目前RCS所追求的核心方向是调度的车辆车型更多、适用的场景更全面、项目的部署更高效、任务的分配更合理（更快代价更小）和多车调度不出现拥堵（出现拥堵快速解困）。

        在应用场景上面，RCS面临的主要是仓储业务（库-库）、存取业务（库-人）和生产业务（制程-制程），这些业务的不同通常影响的不是任务模块，更多的是其交通管制模块，不同的业务，其采取交管策略可能会有所不同。但是交管模块追求的就是统一所有的场景，或者使得不同的场景表现给实施维护人员相同的操作，尽可能降低对实施人员的要求。而交管的优化通常离不开地图编辑器（地图生成器）的优化。

        RCS通常会与地图编辑器以及仿真系统（包括车辆、任务和场景的仿真）一起出现，并且RCS是依赖于地图编辑器的，而仿真系统一般有车辆仿真就可以先用着了（通常不会直接上真车）。

 

        RCS通常作为服务端处于整体系统的中间层，它的下层是车辆，通常在架构上调度系统不会因为车型的不同导致太大的区别，多数适配工作会被隔离在车辆模块的适配层，在车辆模块的调度业务层面就基本不会因为车型的不同出现分离。除非部分业务差别太大导致车辆的任务分配业出现差异，如四向穿梭车和一般的其他AGV车型差别就比较大，但是这部分的差异也会被隔离在车辆模块，不会再传递到其他模块。

        而RCS的上层通常是后台管理、WMS或者MES系统之类的系统。RCS可以直接对外部客户，也可以不直接对外部客户。不对外的RCS通常会增加一层定制化开发比较多的中间层，以适配各种客户千奇百怪的内部系统。这个时候RCS的接口层就可以不用太多设计工作。而如果直接对外，那么就要兼容各种协议并需要完善的接口文档，接口层设计上也要花些心思，尽量各种不同的协议最后都路由到同一套接口实现上。​​​​​​​