AGV调度 订单层软件设计思路

AGV调度 订单层设计思路

从典型订单流程、任务分类、订单取消逻辑、订单恢复逻辑、任务逻辑复用及通用化设计、性能考虑几个方面对AGV调度订单层的软件实现进行设计。

名词解释

任务：指AGV执行的搬运任务、相关的资源操作、系统或设备交互过程等一个独立的步骤。
订单：由若干个任务组成，任务间有一定关系的任务流程。如实现一次货物转移过程，或者包含多agv配合、设备交互等更多的任务流程。

典型订单流程

典型订单流程如上：一个订单的任务组成，可能会有串行、并行、分支判断、包含关系。
一个订单流程的组织，首先就是要保证订单的任务流正常执行完成。

任务分类

任务执行对象，任务可以分为动作型、资源型、条件等待型.
动作型：可以独立执行的动作，如AGV搬运任务、导航任务、旋转任务、DO信号、向某软件系统发送数据包等
资源型：涉及资源占用，如查找并锁定一个空位置、查找并锁定一个托盘、锁定一个上料呼叫。
条件等待型：判断满足条件后继续，如延时5S、判断某个信号。

任务关系

串行、并行、分支、绑定

取消订单

可以将订单流程的每个任务进行封装，每一个步骤可以叫action
每个action有自己的do()方法，实现自己的实际动作
每个action有自己的undo()方法，实现自己的撤销动作
每个action有自己的is_finish()方法，实现自己的判断完成逻辑
每个action有自己的set_finish()方法，实现自己的设置完成逻辑

模板action:do()完成后，action自动存储undo()时需要释放的资源；finish()后自动移除undo逻辑。

每个订单对应一个action集合。取消订单触发时，即对该集合中的action触发其undo方法，进而释放此订单占用的所有资源；假如有至少一个action undo方法调用失败时，取消逻辑应能够实现事务型回滚，即整体取消失败，订单流程继续执行。

恢复订单

订单恢复逻辑如果要针对不同订单流程，定制去写对应的订单恢复逻辑，容易出错，不易维护。所以要考虑订单内部状态的统一性，从而统一恢复逻辑。

任务逻辑复用

暂时不考虑应用行业

从agv搬运货物的场景来看，有些比较独立的任务或任务组合是可能可以复用的，如从一个位置取货、从一个区域取某种类型货物（考虑多agv搬运时先后到冲突的逻辑）、到一个位置卸货、到一个区域找一个空位放某种类型托盘（考虑多agv搬运时先后到冲突的逻辑）、考虑起点终点位置是否需要换向过程、库位管理逻辑等。

再考虑更大一点的应用场景

如简单的点到点搬运、工位上下料独立呼叫结合流转过程中的缓存场景、支持工位屏蔽功能、流转区域可配置、进出工位的设备握手逻辑等。这些场景具有一定的通用性。

通用化设计思路

• 1.封装函数
• 2.封装类
• 3.封装库
• 4.通过数据库设计抽象
• 5.其他设计模式应用

性能考虑

考虑大订单量情况下（如1000个以上并行执行），订单执行效率问题

协程的应用

命令模式结合主键的队列，线程池触发订单状态机

以上为本人目前对agv调度订单层的初步设计思路，目前用C++实现了一部分，欢迎有兴趣人士一起学习交流。