基于openTCS的多種AGV通信適配與實時監(jiān)控管理系統(tǒng)設(shè)計與實現(xiàn)

吳 若，蘇 宇，劉 勝，蘇亞輝

（安徽大學(xué) 電氣工程與自動化學(xué)院，合肥 230601)

0 引言

近年來，隨著我國制造業(yè)對AGV需求的不斷增大，AGV監(jiān)控與管理系統(tǒng)作為整套AGV系統(tǒng)的核心之一，逐漸在國內(nèi)受到了重視[1]。吳繼超[2]與張丹丹[3]等人所設(shè)計的AGV調(diào)度管理平臺，雖然能夠完成AGV的路徑規(guī)劃與任務(wù)調(diào)度等基本功能，但是存在不足之處在于無法對AGV參數(shù)數(shù)據(jù)進(jìn)行實時更新和對于多種類型的AGV無法同時兼容問題。

鑒于在實際制造業(yè)環(huán)境中存在對多種不同種類AGV實時監(jiān)控管理的功能需求。本文在分析現(xiàn)狀的基礎(chǔ)上，針對現(xiàn)有解決方案的不足，重點研究基于openTCS的監(jiān)控與管理系統(tǒng)[4]。此系統(tǒng)以AGV為載體，編寫車輛驅(qū)動程序，提供接口接收上位機(jī)控制指令集，并將任務(wù)指令集打包發(fā)送至AGV，使內(nèi)核完成對多AGV的任務(wù)分配、路徑規(guī)劃和動態(tài)協(xié)同調(diào)度，其次開發(fā)OPC-UA服務(wù)器，完成對AGV的數(shù)據(jù)采集，并通過無線局域網(wǎng)將數(shù)據(jù)傳輸至openTCS內(nèi)核，最后實現(xiàn)上位機(jī)系統(tǒng)對AGV的監(jiān)控與管理。

1 需求分析與模型構(gòu)建

1.1 設(shè)計需求

系統(tǒng)開發(fā)需要進(jìn)行精確的市場需求分析以及可行性的系統(tǒng)方案設(shè)計。通過建立基于openTCS的AGV監(jiān)控與管理系統(tǒng)，給管理者和員工提供簡單明了的AGV實時監(jiān)控管理平臺。根據(jù)對實際場景的調(diào)研分析，總結(jié)出了該場景下的難點與需求，并給出系統(tǒng)提供的解決方案。具體規(guī)劃分析如表1所示。

表1 規(guī)劃分析

1.2 系統(tǒng)模型構(gòu)建

系統(tǒng)模塊架構(gòu)主要包含openTCS、車輛驅(qū)動與OPCUA服務(wù)器三部分。其中openTCS（開源交通控制系統(tǒng)）是用于小車路徑規(guī)劃與任務(wù)調(diào)度的開源系統(tǒng)，主要包含三大模塊，分別為內(nèi)核（Kernel）、終端（plant overview）與內(nèi)核控制中心（Kernel Control Center），其中內(nèi)核負(fù)責(zé)路徑規(guī)劃與任務(wù)調(diào)度，終端與內(nèi)核控制中心主要負(fù)責(zé)提供可視化界面，方便人員監(jiān)控管理AGV。車輛驅(qū)動負(fù)責(zé)接收內(nèi)核的任務(wù)指令，并將任務(wù)指令通過通訊網(wǎng)網(wǎng)絡(luò)發(fā)送至AGV，另外還包含有接收OPC-UA服務(wù)器數(shù)據(jù)的接口，當(dāng)監(jiān)聽到OPC-UA服務(wù)器采集完AGV數(shù)據(jù)后，負(fù)責(zé)為openTCS調(diào)度系統(tǒng)實時傳輸AGV參數(shù)數(shù)據(jù)。系統(tǒng)模型架構(gòu)如圖1所示。

在本系統(tǒng)中，將AGV小車本體設(shè)置為OPC-UA服務(wù)端，AGV調(diào)度系統(tǒng)即openTCS作為OPC-UA客戶端[4]，如圖2所示，這樣設(shè)計的好處如下。

圖2 通信模塊架構(gòu)[6]

1）如果AGV本體是OPC-UA客戶端，那對AGV本體的數(shù)據(jù)字段或者數(shù)據(jù)格式的修改，也一定需要伴隨著 OPC-UA服務(wù)端的修改，這不利于開發(fā)與后期維護(hù)，增加了工作量。

2）方便使用第三方OPC-UA客戶端讀取AGV的數(shù)據(jù)[1]。

2 調(diào)度系統(tǒng)與AGV的通訊

2.1 車輛驅(qū)動設(shè)計

2.1.1 車輛驅(qū)動結(jié)構(gòu)

內(nèi)核本身擁有任務(wù)分配、路線規(guī)劃與動態(tài)調(diào)度的默認(rèn)實現(xiàn)，但是本文結(jié)合實際應(yīng)用場景需要修改默認(rèn)實現(xiàn)，在這種情況下，本文注冊自定義Guice模塊來添加了車輛驅(qū)動程序來完成對實體小車的實際控制與調(diào)度。通過在openTCS源程序中自定義車輛驅(qū)動程序，實現(xiàn)車輛驅(qū)動程序與特定車輛的通信，因此可以在內(nèi)核和車輛之間進(jìn)行中介。具體車輛驅(qū)動結(jié)構(gòu)如圖3所示。

圖3 驅(qū)動結(jié)構(gòu)

圖2車輛驅(qū)動模塊一共包含四大功能模塊。交互模塊主要負(fù)責(zé)發(fā)送各項指令給實際小車，包括向小車發(fā)送任務(wù)電報、設(shè)置車輛怠速標(biāo)志、適配器空閑超時命令、啟用/禁用日志、禁用周期性狀態(tài)請求、適配器在連接丟失后重新連接、設(shè)置適配器請求間隔、設(shè)置車輛終止節(jié)點；虛擬面板的作用是實現(xiàn)車輛控制與數(shù)據(jù)的可視化；OPC-UA通信適配器面板用于創(chuàng)建特定項目通信知配器的實例工廠模型；狀態(tài)面板用于監(jiān)控車輛狀態(tài)的變化與更新通信知配器的連接狀態(tài)。OPC-UA模塊主要負(fù)責(zé)與外部OPC-UA服務(wù)端進(jìn)行交互，完成信息的接受與發(fā)送。其中包括OPCUA客戶端類、密鑰庫器與OPC-UA客戶頻道管理。仿真小車方便開發(fā)人員在實際車輛還未使用時測試小車驅(qū)動模塊是否能夠滿足特定情況下的需求。通過對不同種類的小車與運行環(huán)境對仿真小車對象進(jìn)行建模，完成仿真小車與OPC-UA服務(wù)端或車輛驅(qū)動的交互。動作模塊主要實現(xiàn)執(zhí)行任務(wù)訂單時的所有動作，包括發(fā)送訂單請求/接受小車回應(yīng)、針對小車狀態(tài)請求與接受小車狀態(tài)回應(yīng)。

2.1.2 車輛驅(qū)動工作流程設(shè)計

在系統(tǒng)自動搬運過程中，AGV小車通過通信系統(tǒng)接收openTCS任務(wù)指令與報告自己的狀態(tài)。車輛驅(qū)動模塊主要作用是負(fù)責(zé)openTCS與AGV設(shè)備之間對接，其工作流程如下。

第一步：建立與車輛連接，判斷vehicleChannelManager是否為空，若為空則發(fā)出警報；若不為空，調(diào)用vehicleChannelManager的connect方法并將將字符串vehicleEndPointUrl作為參數(shù)傳入，完成與小車建立連接。

第二步：發(fā)送訂單請求指令，調(diào)用sendCommand方法并將MoveCommand類型的參數(shù)cmd傳入，判斷cmd是否為空，若為空則拋出空指針異常，若不為空，通過調(diào)用vehicleChannelManager的sendOrderRequest方法創(chuàng)建OrderResponse對象，完成發(fā)送訂單請求指令。

第三步：檢查車輛位置更新，將當(dāng)前位置currentState與previousState作為參數(shù)傳入checkForVehiclePositionUpdate方法中，分別判斷其positionId的值是否相等，若不想等，則代表位置已經(jīng)改變，并在進(jìn)程模型對象中重新設(shè)置車輛所在點的位置。

第四步：檢查訂單是否完成，將當(dāng)前位置currentState與previousState作為參數(shù)傳入checkOrderFinished方法中，首先獲得currentState的lastFinishedOrderId的值，若為0，則所有訂單均已完成，完成方法。若不為0，則繼續(xù)判斷currentState的lastFinishedOrderId的值是否與previousState的lastFinishedOrderId值是否相等，若相等，則訂單完成，完成方法。若以上均不滿則，方法進(jìn)入while循環(huán)，將MoveCommand集合作為循環(huán)判斷條件，若集合不為空，繼續(xù)執(zhí)行運動等相關(guān)指令。

第五步：斷開與車輛連接，判斷vehicleChannelManager是否為空，若為空則發(fā)出警報；若不為空，調(diào)用vehicleChannelManager的disconnect方法，結(jié)束。

工作流程如圖4所示。

圖4 工作流程圖

2.2 OPC-UA的信息模型

傳統(tǒng)的OPC協(xié)議只能對AGV小車的參數(shù)進(jìn)行單一采集，以小車屬性為例，只能采集到小車編號，而不能同時獲取到小車型號、電池電壓、運行狀態(tài)等參數(shù)數(shù)據(jù)。本文所采用的OPC-UA協(xié)議可以對信息數(shù)據(jù)項進(jìn)行多種類型的描述，通過對AGV小車進(jìn)行數(shù)據(jù)建模，可以獲取小車某一參數(shù)的詳細(xì)信息，同時也可以獲取小車所有參數(shù)來進(jìn)行綜合評估與分析[7]。極大的簡化了AGV小車綜合數(shù)據(jù)信息的獲取。本文基于信息規(guī)范，針對AGV小車的功能需求分析與業(yè)務(wù)特點，對信息進(jìn)行建模。過程如圖5所示。

圖5 信息模型構(gòu)建

以本文研究的AGV小車為模型，建立信息模型對象，并根據(jù)小車參數(shù)信息進(jìn)行分類，設(shè)置相關(guān)參數(shù)的NodeId、含義、數(shù)據(jù)類型等信息。部分重要信息如表2、表3所示。

表2 基本數(shù)據(jù)類型

表3 硬件與小車動作狀態(tài)

2.3 數(shù)據(jù)采集流程

建立OPC-UA服務(wù)器，將已經(jīng)建立的信息模型文件整合到服務(wù)器中，通過NodeId將AGV小車信息與數(shù)據(jù)模型進(jìn)行關(guān)聯(lián)，當(dāng)AGV小車信息改變時，對相應(yīng)節(jié)點信息進(jìn)行更新[8]，openTCS通過OPC-UA客戶端訪問服務(wù)器讀取信息模型中的各項信息。主要流程如下，系統(tǒng)開始運行后主控進(jìn)程負(fù)責(zé)讀取配置文件，連接成功后創(chuàng)建OPC UA服務(wù)器進(jìn)程與服務(wù)器數(shù)據(jù)節(jié)點NodeID，服務(wù)器監(jiān)聽是否有客戶端讀取NodeID，若有，則讀取并返回共享內(nèi)存中的信息；若沒有，進(jìn)一步判斷主進(jìn)程是否結(jié)束，若未結(jié)束，則繼續(xù)監(jiān)聽，若結(jié)束則數(shù)據(jù)采集結(jié)束。整體流程如圖6所示。

圖6 AGV數(shù)據(jù)采集流程

3 系統(tǒng)功能實現(xiàn)

3.1 多種AGV通信適配

根據(jù)對實際運行中AGV的類型進(jìn)行解析與建模[9]，創(chuàng)建了模擬AGV類，車輛驅(qū)動負(fù)責(zé)與模擬AGV進(jìn)行對接，openTCS經(jīng)由車輛驅(qū)動使用TCP/IP協(xié)議和AGV或OPCUA開展通訊，以保證上位機(jī)能夠順利接收模擬AGV運動狀態(tài)和參數(shù)數(shù)據(jù)包并完成相應(yīng)邏輯運算，其中不同的車輛驅(qū)動能夠兼容對應(yīng)型號的AGV，openTCS默認(rèn)適配器為Loopback Adapter，圖7中的MyTestAdapter適配器是為模擬小車仿真測試而創(chuàng)建的一類適配器。適配器Adapter的實現(xiàn)如圖7所示。

圖7 車輛驅(qū)動

3.2 多AGV參數(shù)與任務(wù)狀態(tài)實時監(jiān)控

此處采用模擬通信的形式，使用模擬AGV進(jìn)行多AGV批量任務(wù)的仿真驗證，完成車輛驅(qū)動程序與OPCUA服務(wù)器的編寫后，建立openTCS調(diào)度系統(tǒng)與AGV或OPC-UA服務(wù)端的Socket通信，設(shè)置小車ip地址為127.0.0.1，端口為4001，對模擬小車與調(diào)度系統(tǒng)進(jìn)行調(diào)試，實現(xiàn)仿真小車的參數(shù)數(shù)據(jù)與任務(wù)狀態(tài)實時跟蹤。圖8為運行時AGV參數(shù)實時顯示，圖9展示了模擬運行時實時任務(wù)狀態(tài)監(jiān)控。

圖8 仿真小車參數(shù)

圖9 任務(wù)狀態(tài)監(jiān)控

4 結(jié)語

本文設(shè)計了基于openTCS的多臺不同種類AGV協(xié)同工作的監(jiān)控與管理系統(tǒng)，首先使用openTCS提供的API開發(fā)其車輛驅(qū)動模塊，其次數(shù)據(jù)采集方法選擇了OPC-UA協(xié)議并開發(fā)了其服務(wù)器，完成構(gòu)建面向局域網(wǎng)的通訊模塊，最后實現(xiàn)了系統(tǒng)對AGV的監(jiān)控與管理。仿真表明，本系統(tǒng)操作簡單、穩(wěn)定性與可擴(kuò)展性高，能夠為AGV的可靠運行提供技術(shù)保障。