吴 若,苏 宇,刘 胜,苏亚辉
(安徽大学 电气工程与自动化学院,合肥 230601)
近年来,随着我国制造业对AGV需求的不断增大,AGV监控与管理系统作为整套AGV系统的核心之一,逐渐在国内受到了重视[1]。吴继超[2]与张丹丹[3]等人所设计的AGV调度管理平台,虽然能够完成AGV的路径规划与任务调度等基本功能,但是存在不足之处在于无法对AGV参数数据进行实时更新和对于多种类型的AGV无法同时兼容问题。
鉴于在实际制造业环境中存在对多种不同种类AGV实时监控管理的功能需求。本文在分析现状的基础上,针对现有解决方案的不足,重点研究基于openTCS的监控与管理系统[4]。此系统以AGV为载体,编写车辆驱动程序,提供接口接收上位机控制指令集,并将任务指令集打包发送至AGV,使内核完成对多AGV的任务分配、路径规划和动态协同调度,其次开发OPC-UA服务器,完成对AGV的数据采集,并通过无线局域网将数据传输至openTCS内核,最后实现上位机系统对AGV的监控与管理。
系统开发需要进行精确的市场需求分析以及可行性的系统方案设计。通过建立基于openTCS的AGV监控与管理系统,给管理者和员工提供简单明了的AGV实时监控管理平台。根据对实际场景的调研分析,总结出了该场景下的难点与需求,并给出系统提供的解决方案。具体规划分析如表1所示。
表1 规划分析
系统模块架构主要包含openTCS、车辆驱动与OPCUA服务器三部分。其中openTCS(开源交通控制系统)是用于小车路径规划与任务调度的开源系统,主要包含三大模块,分别为内核(Kernel)、终端(plant overview)与内核控制中心(Kernel Control Center),其中内核负责路径规划与任务调度,终端与内核控制中心主要负责提供可视化界面,方便人员监控管理AGV。车辆驱动负责接收内核的任务指令,并将任务指令通过通讯网网络发送至AGV,另外还包含有接收OPC-UA服务器数据的接口,当监听到OPC-UA服务器采集完AGV数据后,负责为openTCS调度系统实时传输AGV参数数据。系统模型架构如图1所示。
在本系统中,将AGV小车本体设置为OPC-UA服务端,AGV调度系统即openTCS作为OPC-UA客户端[4],如图2所示,这样设计的好处如下。
图2 通信模块架构[6]
1)如果AGV本体是OPC-UA客户端,那对AGV本体的数据字段或者数据格式的修改,也一定需要伴随着 OPC-UA服务端的修改,这不利于开发与后期维护,增加了工作量。
2)方便使用第三方OPC-UA客户端读取AGV的数据[1]。
2.1.1 车辆驱动结构
内核本身拥有任务分配、路线规划与动态调度的默认实现,但是本文结合实际应用场景需要修改默认实现,在这种情况下,本文注册自定义Guice模块来添加了车辆驱动程序来完成对实体小车的实际控制与调度。通过在openTCS源程序中自定义车辆驱动程序,实现车辆驱动程序与特定车辆的通信,因此可以在内核和车辆之间进行中介。具体车辆驱动结构如图3所示。
图3 驱动结构
图2车辆驱动模块一共包含四大功能模块。交互模块主要负责发送各项指令给实际小车,包括向小车发送任务电报、设置车辆怠速标志、适配器空闲超时命令、启用/禁用日志、禁用周期性状态请求、适配器在连接丢失后重新连接、设置适配器请求间隔、设置车辆终止节点;虚拟面板的作用是实现车辆控制与数据的可视化;OPC-UA通信适配器面板用于创建特定项目通信知配器的实例工厂模型;状态面板用于监控车辆状态的变化与更新通信知配器的连接状态。OPC-UA模块主要负责与外部OPC-UA服务端进行交互,完成信息的接受与发送。其中包括OPCUA客户端类、密钥库器与OPC-UA客户频道管理。仿真小车方便开发人员在实际车辆还未使用时测试小车驱动模块是否能够满足特定情况下的需求。通过对不同种类的小车与运行环境对仿真小车对象进行建模,完成仿真小车与OPC-UA服务端或车辆驱动的交互。动作模块主要实现执行任务订单时的所有动作,包括发送订单请求/接受小车回应、针对小车状态请求与接受小车状态回应。
2.1.2 车辆驱动工作流程设计
在系统自动搬运过程中,AGV小车通过通信系统接收openTCS任务指令与报告自己的状态。车辆驱动模块主要作用是负责openTCS与AGV设备之间对接,其工作流程如下。
第一步:建立与车辆连接,判断vehicleChannelManager是否为空,若为空则发出警报;若不为空,调用vehicleChannelManager的connect方法并将将字符串vehicleEndPointUrl作为参数传入,完成与小车建立连接。
第二步:发送订单请求指令,调用sendCommand方法并将MoveCommand类型的参数cmd传入,判断cmd是否为空,若为空则抛出空指针异常,若不为空,通过调用vehicleChannelManager的sendOrderRequest方法创建OrderResponse对象,完成发送订单请求指令。
第三步:检查车辆位置更新,将当前位置currentState与previousState作为参数传入checkForVehiclePositionUpdate方法中,分别判断其positionId的值是否相等,若不想等,则代表位置已经改变,并在进程模型对象中重新设置车辆所在点的位置。
第四步:检查订单是否完成,将当前位置currentState与previousState作为参数传入checkOrderFinished方法中,首先获得currentState的lastFinishedOrderId的值,若为0,则所有订单均已完成,完成方法。若不为0,则继续判断currentState的lastFinishedOrderId的值是否与previousState的lastFinishedOrderId值是否相等,若相等,则订单完成,完成方法。若以上均不满则,方法进入while循环,将MoveCommand集合作为循环判断条件,若集合不为空,继续执行运动等相关指令。
第五步:断开与车辆连接,判断vehicleChannelManager是否为空,若为空则发出警报;若不为空,调用vehicleChannelManager的disconnect方法,结束。
工作流程如图4所示。
图4 工作流程图
传统的OPC协议只能对AGV小车的参数进行单一采集,以小车属性为例,只能采集到小车编号,而不能同时获取到小车型号、电池电压、运行状态等参数数据。本文所采用的OPC-UA协议可以对信息数据项进行多种类型的描述,通过对AGV小车进行数据建模,可以获取小车某一参数的详细信息,同时也可以获取小车所有参数来进行综合评估与分析[7]。极大的简化了AGV小车综合数据信息的获取。本文基于信息规范,针对AGV小车的功能需求分析与业务特点,对信息进行建模。过程如图5所示。
图5 信息模型构建
以本文研究的AGV小车为模型,建立信息模型对象,并根据小车参数信息进行分类,设置相关参数的NodeId、含义、数据类型等信息。部分重要信息如表2、表3所示。
表2 基本数据类型
表3 硬件与小车动作状态
建立OPC-UA服务器,将已经建立的信息模型文件整合到服务器中,通过NodeId将AGV小车信息与数据模型进行关联,当AGV小车信息改变时,对相应节点信息进行更新[8],openTCS通过OPC-UA客户端访问服务器读取信息模型中的各项信息。主要流程如下,系统开始运行后主控进程负责读取配置文件,连接成功后创建OPC UA服务器进程与服务器数据节点NodeID,服务器监听是否有客户端读取NodeID,若有,则读取并返回共享内存中的信息;若没有,进一步判断主进程是否结束,若未结束,则继续监听,若结束则数据采集结束。整体流程如图6所示。
图6 AGV数据采集流程
根据对实际运行中AGV的类型进行解析与建模[9],创建了模拟AGV类,车辆驱动负责与模拟AGV进行对接,openTCS经由车辆驱动使用TCP/IP协议和AGV或OPCUA开展通讯,以保证上位机能够顺利接收模拟AGV运动状态和参数数据包并完成相应逻辑运算,其中不同的车辆驱动能够兼容对应型号的AGV,openTCS默认适配器为Loopback Adapter,图7中的MyTestAdapter适配器是为模拟小车仿真测试而创建的一类适配器。适配器Adapter的实现如图7所示。
图7 车辆驱动
此处采用模拟通信的形式,使用模拟AGV进行多AGV批量任务的仿真验证,完成车辆驱动程序与OPCUA服务器的编写后,建立openTCS调度系统与AGV或OPC-UA服务端的Socket通信,设置小车ip地址为127.0.0.1,端口为4001,对模拟小车与调度系统进行调试,实现仿真小车的参数数据与任务状态实时跟踪。图8为运行时AGV参数实时显示,图9展示了模拟运行时实时任务状态监控。
图8 仿真小车参数
图9 任务状态监控
本文设计了基于openTCS的多台不同种类AGV协同工作的监控与管理系统,首先使用openTCS提供的API开发其车辆驱动模块,其次数据采集方法选择了OPC-UA协议并开发了其服务器,完成构建面向局域网的通讯模块,最后实现了系统对AGV的监控与管理。仿真表明,本系统操作简单、稳定性与可扩展性高,能够为AGV的可靠运行提供技术保障。