吳 若,蘇 宇,劉 勝,蘇亞輝
(安徽大學 電氣工程與自動化學院,合肥 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的可靠運行提供技術保障。