焊接機器人數據采集與管控系統

蔡新奇，王學武，范曄平，徐德進

(1.華東理工大學,能源化工過程智能制造教育部重點實驗室，上海 200237；2.上海廣為焊接設備有限公司，上海 200241；3.上海騰焊智能科技有限公司，上海 200241)

0 前言

隨著科技的迅猛發展，焊接技術作為傳統制造加工行業中不可或缺的一個重要領域，同樣迎來了智能化發展的新浪潮。傳統的人工監督的方式逐漸不能滿足當今生產制造的需要，而且根據本人在國內幾個中大型焊接制造現場調研可知，目前雖然國內機器人焊接設備占有率不斷提升，但是除了車廠等傳統大型離散化生產企業，機器人實際使用效率并不高。而且部分中大型企業購置的機器人設備分散在不同車間，且由不同的機器人供應商提供，各自完成相應的焊接工作，不便于統一管理。除此之外，目前對于生產線的監管多數仍局限于車間控制層面，機器人和外界的數據交互并沒有完全暢通，但是網絡技術的發展正在逐步解決這樣的問題[1-3]。

目前，國內外在焊接數據采集與運用方面已有很多成果。美國肯塔基大學的Zhang等人[4]通過傳感器等方式采集到焊接的過程數據，結合動態建模和深度學習算法，實現了能夠在焊接過程中實時修正焊接參數的自適應焊接制造。澳大利亞聯邦科學與工業研究組織的Syrek等人[5]自行設計了閃光對焊監視器，用于采集車輪生產過程中的焊接生產數據，通過后續的數據處理，預測車輪生產的缺陷情況。此外，德國HKS公司研發的焊接物聯網綜合采集、監控與分析系統，以及日本安川電機有限公司旗下的焊接機器人物聯網系統YASKAWA Cockpit，均有很高的知名度。

北京石油化工學院的周燦豐等人[6]將采集到的焊接機器人過程數據和虛擬現實技術相結合，實現對危險環境下遙操作焊接機器人的監視。哈爾濱焊接研究院有限公司的李榮等人[7]針對機器人焊接激光制造，開發了數字化的控制系統，能夠完成各種焊接數據采集，并提供數據接口供企業平臺使用。中車青島四方機車車輛股份有限公司的李亞南等人[8]將焊接群控系統運用到高速列車轉向架的生產中，能夠在線監控轉向架的焊接生產狀態并優化生產過程。文獻[9]和文獻[10]介紹了唐山松下產業機器有限公司開發的智能焊接云管理系統——iWeldCloud，并將其運用到高速列車焊接生產車間中，提高了生產過程的智能化水平。

機器人本體的健康狀態也是一個十分重要的因素，機器人定期維護可以很大程度上減少機器人故障對生產質量和生產效率的影響。一般地，機器人維護按照時間維度劃分可以分為日、周、月和年檢查等，不同焊接工藝、不同品牌的機器人需檢修的項目各有差別，需要根據實際情況綜合確定,統一管理各種機器人維護信息便具有很高的實際價值[11-12]。

綜上所述，雖然目前各大機器人廠商基本都有推出支持各自機器人的焊接數據采集系統，但是費用昂貴。且目前對機器人數據采集系統的研究也多局限于單一品牌的機器人設備，難以同時兼容其他品牌，不能滿足采用“多機器人廠商、中小生產規模”為焊接生產模式的企業的要求。此時需要一個能夠兼容不同廠商機器人的管控系統，迅速接入生產現場已有或新采購的機器人設備。該系統著重研究如何開發一個通信系統基礎框架，配合機器人管控系統，能夠靈活、高效、快速地接入不同廠商的機器人設備，完成焊接機器人生產狀態實時監控和相關管理，一定程度上可以提高焊接機器人使用率和生產效率。

1 焊接機器人數據采集與管控系統架構

焊接機器人數據采集與管控系統由硬件和軟件兩部分組成，硬件主要包括現場的各個品牌的工業機器人、焊機、PLC、工控機和變位機等焊接系統相關設備,以及支持現場數據通信的各個采集計算機。軟件主要包括數據通信系統和機器人管控系統，實現數據通信、設備基本信息錄入、歷史生產數據回溯、實時狀態監控、設備定期維護和通信模塊更新等功能。系統結構組成如圖1所示。

圖1 焊接機器人數據采集與管控系統結構

數據采集與管控系統架構圖如圖2所示，系統首先通過通信子程序采集到不同車間的各個焊接機器人的過程數據，隨后將采集到的數據處理、轉發并存儲，最后通過系統應用層面開發，將數據組織、處理、加工，并按照需求展示。數據的來源包括但不限于機器人控制柜、PLC、焊接電源或工控機等現場硬件設備。

圖2 焊接機器人數據采集與管控系統架構

該系統的數據通信模塊從不同品牌的焊接機器人通信接口不同等實際問題出發，針對不同的焊接工藝方式，首先提取出不同焊接工藝所共有的數據，例如焊接電流，并制定一份基礎的傳輸協議。該協議預留相應的數據位，用于存放不同品牌機器人或不同焊接方式特有的數據，例如激光焊接的離焦量。將常用的機器人通信接口，例如OPC UA等，每個接口開發唯一的數據通信子程序，即所有采用OPC UA通信接口的機器人，采用相同的通信子程序。每個機器人都會單獨編寫一個配置文件，通信子程序通過配置文件完成初始化，按要求完成通信任務，也方便后續通信程序的遠程更新。數據通信模塊采用C/S架構開發，通過Netty框架搭建NIO服務器，采用TCP/IP協議接收各個現場設備發送過來的實時數據。實時數據主要包括焊接電流、焊接電壓、送絲速度、焊接速度、氣體流量、狀態信息、故障信息和計件信息等。

機器人管控系統的服務器采用B/S架構開發，通過Spring MVC框架搭建機器人管控系統，局域網內的客戶機通過瀏覽器可訪問系統，實現對機器人設備基本信息的統一管理、機器人狀態實時監控、歷史生產數據展示和機器人維修與故障管理等。

除此之外，由于現場設備隨著運行時間的增加，產生的數據量會逐漸增大，采用支持分布式存儲的列式數據庫ClickHouse存儲實時數據，該數據庫在聚合查詢等方面效率非常高，方便后續的集群擴展和實時分析處理。機器人基本信息等數據通過傳統的關系型數據庫MySQL存儲。同時采用物聯網領域常用的MQTT協議的消息隊列，為機器人實時監控頁面提供實時數據，以及傳遞相關控制指令等。

2 焊接機器人管控系統硬件設計

系統硬件部分由各個不同的焊接機器人系統和便攜式PC組成，如圖3所示。其中機器人系統主要包含機器人本體、焊接電源、機器人控制柜、工控機和變位機等相關配套設備。每臺機器人設備都會額外配備便攜式的PC，數據通信子程序運行于該便攜式PC上。將數據通信的軟件環境和機器人自身運行的軟件環境分離，便于調試。該便攜式PC具有雙網口，其中一個接入機器人內部局域網，完成數據的上傳和下載，另一個接入到車間局域網，將每臺機器人設備的數據發送到遠程服務器，并且接收遠程服務器下發的指令。現場采用雙屏蔽網線連接各個設備，最大程度保持通信不受現場惡劣的環境干擾。

圖3 焊接機器人工作間示意圖

除此之外，每個車間可根據需求分配相應數量的管理計算機，管理計算機一方面可供現場管理員查看機器人工作狀態，另一方面可以中轉接收本車間的各個現場設備的數據，并將數據預處理后統一轉發到服務器端進行持久化存儲。避免了大量TCP長連接直接連接到采集服務器，減輕了服務器的壓力。

整個系統的服務器出于安全性要求，部署在內網，外網無法訪問，所有接入內網的終端設備根據各自用戶權限登錄，實現對現場設備的遠程管理與監控。服務器主要負責接收、存儲并處理從機器人采集到的數據，響應各個客戶機的請求，完成不同功能的數據展示。

3 焊接機器人管控系統軟件設計

焊接機器人管控系統軟件部分是整個系統的核心，合理規劃軟件各個模塊的功能設計，才能更好地完成系統的開發，系統軟件設計主要由以下幾個模塊組成。

3.1 數據通信模塊設計

數據通信模塊在該系統中扮演非常重要的角色，是軟件與各個機器人之間數據通信的橋梁，主要負責完成軟件與各個現場機器人通信。整個通信模塊可以分為3層，如圖4所示。

圖4 數據通信模塊架構

第1層包含所有與各個機器人直接通信的子程序，每個機器人的子程序單獨部署，運行在圖3中便攜式PC上。通過該子程序和配置文件，解決不同品牌機器人接口協議和數據存儲格式差異的問題，并將統一結構的數據發送到第2層。此外，第1層和第2層之間采用TCP長連接并加入心跳機制，確保連接的穩定性。第2層和第3層均采用Java語言開發的基于Netty框架實現NIO服務器，分開部署，用于非阻塞地接收其上游的通信子程序發送過來的實時數據。其中第2層主要完成數據預處理等工作，可為每個從指定第2層軟件中轉的數據加上對應的標簽，方便后續對數據聚合計算等；第3層將實時數據批量持久化存儲到ClickHouse數據庫，也負責接收上位機指令，并下發到機器人對應的通信子程序上。除此之外，第3層軟件還將實時數據及時發布到MQ，為實時監控頁面提供實時數據源。

將通信模塊第2層和第3層分開設計便于后續擴展，將維持大量現場設備TCP長連接的任務分配到第2層，而第2層可根據要求，動態地擴展軟件數量。通過上述方案能夠更高效、更穩定地完成軟件與機器之間的通信。

為了統一化通信子程序的開發流程，編寫了常用工業通信協議的通信子程序模板，包括但不限于TCP/IP，OPC和OPC UA等。可通過配置文件配置所需采集的數據和格式，采用軟件的方式去差異化。與此同時，機器人管控系統集成了通信子程序更新模塊，能夠遠程更新各個機器人通信子程序，方便程序的更新維護。

3.2 機器人管控系統數據庫模塊設計

該系統主要涉及到2類數據的存儲，分別為實時數據和關系型數據，其中實時數據存儲在ClickHouse數據庫，其余數據的均存儲于MySQL數據庫。

3.2.1實時數據

實時數據指焊接機器人每秒上傳的過程數據，包含焊接電流、焊接電壓和工作狀態等。隨著設備的增加和運行時間的積累，數據量會很大。并且對于故障次數統計等類似功能，需要查詢所有歷史數據。綜合各方面考慮，采用支持在線分析處理查詢的ClickHouse列式數據庫存儲實時數據，該數據庫聚合查詢效率非常高，能夠高效完成查詢計劃，同時支持分布式擴展。

ClickHouse建表時采用MergeTree引擎，數據按日期分區，并采用時間，設備編號聯合字段進行排序，處于開機狀態的每臺設備每秒會被采集1條數據，隨后按照設定時間間隔，統一將實時數據批量寫入數據庫，完成數據持久化存儲。ClickHouse的實時數據表結構設計為列式數據庫常用的“大寬表”的形式，即將所有實時數據字段設計在一張表中。表設計之初盡可能地包含了焊接和機器人可能涉及的各種數據，并且提前預留了部分字段，方便后續擴展。實時數據表結構見表1，由于原表中包含的字段數量很多，此處選取了其中部分不同類型的字段展示。

表1 實時數據表

3.2.2關系型數據

關系型數據涉及范圍廣，主要包括用戶登錄和用戶權限等管理系統的功能信息，以及機器人基本信息、故障信息、檢修維修、人員信息等焊接機器人應用的相關功能信息，將上述信息存儲在關系型數據庫MySQL中。由于涉及的表較多且復雜，文中以機器人基本信息表中部分字段為例，介紹表的設計思路和功能實現，機器人基本信息數據見表2。表中類似于設備狀態這類字段存儲的int值，通過關聯MySQL其他數據表可以查到狀態的具體內容。

表2 機器人基本信息數據

除此之外，為了提高查詢性能，將機器人劃分為焊接、待機、故障、示教和待檢修5個狀態，并對應地在MySQL中建立5張運行狀態表。后臺通過定時任務，以30 min為1個周期，將存放在ClickHouse的實時數據,以機器人編號維度進行聚合，將各個機器人不同的狀態信息統計并存儲到MySQL的上述5個表中。狀態表中的字段根據生產數據模塊需要展示的內容確定。以焊接狀態為例，可統計出表3中的數據,用于初步統計該30 min內的焊接狀態的數據。

表3 焊接狀態

將機器人實時數據分別統計到指定的狀態表中，一方面精簡了數據量，即在每一個狀態表中，每臺設備每30 min只有1條數據；另一方面對于3.3.2節中，一部分歷史數據回溯功能的實現可以直接通過查詢MySQL中的狀態表完成。因為實時數據存放的Click House數據庫并發性能不高，需處理各種數據查詢。將聚合查詢頻率較高的相關數據按30 min間隔預先查詢，并存儲到各個MySQL狀態表中。上述方法一定程度可緩解ClickHouse并發性能不足導致的問題，同時將處理后的數據存儲到MySQL，與其他關系型數據進行聯合查詢時能有更高的查詢效率。

3.3 機器人管控系統服務器軟件設計

機器人管控系統服務器軟件對采集到的機器人的數據進行匯總和展示，通過各個功能模塊相互協調工作，實現具體的業務功能。機器人管控系統采用B/S架構，使用Java語言根據Spring MVC框架開發，系統的數據層由Mybatis持久層框架構建，基于Tomcat容器運行，前后端數據通過異步JavaScript和XML技術(AJAX)的方式完成交互，數據采用JSON格式進行傳輸。機器人管控系統主要軟件模塊的調用關系如圖5所示。

圖5 管控系統主要模塊調用關系

3.3.1機器人基本信息錄入模塊

機器人基本信息主要包括設備信息和維護信息，其中設備信息主要包括機器人廠商、機器人型號、班組和機器人IP等機器人基本信息，用于記錄機器人基本屬性，便于統一管理；而維護信息又可以分為2部分，分別為故障信息和檢修信息。故障信息包括每個型號機器人故障代碼信息和對應故障解決方案等。故障信息在機器人入廠聯網的時候可以手動或excel導入，后面通過實時數據中故障代碼可以定位到故障原因和解決方案。而檢修信息用于機器人定期檢修模塊，可以為每個型號的機器人設定不同的定期檢修時間間隔，可以包括日常、周、月、年等自定義時間粒度，為定期維護模塊提供時間基準。

3.3.2機器人生產數據模塊

機器人生產數據模塊主要包括機器人歷史數據回溯模塊和機器人實時狀態監控模塊。其中，機器人歷史數據回溯模塊用來查詢過去某一時段內，各個機器人產生的各種生產數據，以報表的形式展示出來。主要包括機器人的焊接時間、開機時間、焊接效率、焊絲消耗、電能消耗、氣體消耗和生產計件等焊接生產數據。除此之外，還能對所有機器人歷史時間內出現的故障進行統計，并能夠定位到故障發生的具體時間，方便后續排查。

機器人實時狀態監控模塊用來遠程監控所有機器人的實時工作狀態，管理人員可以通過生產大屏進行實時監控。可以實現現場所有聯網機器人的匯總監控，通過點擊其中的某一個機器人可對該設備具體數據進行實時展示，包括實時焊接數據，機器人實時運行數據，故障記錄和機器人基本信息等。除此之外，當機器人出現故障或待檢修狀態時，會在監控頁面的設備列表中置頂展示，便于管理者重點排查。

3.3.3機器人維護模塊

機器人維護模塊可以細分為定期檢修和故障維修2個部分。其中，機器人定期檢修系統能夠實時統計各個廠商的機器人是否到達各自設定的檢修時間點，統一管理所有機器人設備的定期檢修信息。此模塊根據實際錄入的檢修的相關數據，可以查看每個機器人距離下次檢修時間的剩余時長。當機器人工作時間到達設定的強制檢修時限時，系統會發送鎖定信號。機器人執行完當前任務后會進入待檢修狀態，該狀態會鎖定機器人，直至檢修人員在現場完成檢修，即可重置機器人狀態。因此需要將檢修人員的數據錄入系統，為指定機器人分配檢修人員。存在需要檢修的機器人時，指定的維修人員登錄到系統可以查看當天需要檢修的設備，根據對應的設備檢修手冊對設備進行檢修。檢修完成之后，在現場每個機器人的便攜式PC上輸入自己的確認密碼，后臺對比密碼無誤后，發送指定命令修改機器人狀態，同時記錄維修人員相關信息，方便后續追溯。

故障維修模塊實現原理和定期檢修模塊類似，唯一區別在于處于故障維修中的每臺機器人是不可預見的。當機器人運行過程中遇到故障，采集系統將機器人狀態更新為故障，記錄相關故障信息，并將該設備添加到維修人員待維修設備中，可通過電子郵件的方式實現通知。維修人員登錄系統能夠看到當前需要該維修人員定期檢修或故障維修的設備，系統能直觀地展示出當前維修人員的任務量。

3.3.4機器人通信程序更新模塊

縱觀以往通信程序維護的方式，對于每個機器人通信子程序的維護，需要工程師到現場按要求將程序更新到每個機器人的便攜式PC上，隨著機器人數量和種類的增加該過程會變得異常繁瑣。機器人通信程序更新模塊可在服務器端，遠程更新每臺機器人配套使用的便攜式PC上的通信子程序，能夠很大程度提高工程師更新、維護程序的效率。

更新各個機器人通信子程序主要包括2步驟，第1步先將待更新的程序上傳至服務器，服務器通過TCP/IP協議，將最新的數據通信程序發送到圖4中所示的所有數據通信軟件第2層。收到發送成功的反饋后，將需要更新程序的機器人編號通過MQ指定主題發布，各個處于第2層的數據通信軟件會訂閱該主題，從而確定與其連接的哪幾臺機器人需要更新程序；第2步就是處于第2層的各個數據通信軟件將最新的程序通過TCP/IP協議，發送到所有需要更新程序的各個機器人便攜式PC上，也就是圖4所示的第1層。并通過遞增序號的方式命名文件，運行在各個現場設備的第1層數據通信程序在下次啟動時，會自動尋找最新的程序運行，實現程序更新。如果需更新程序的便攜式PC成功接收文件，則會通過MQ發布消息，通知上位機程序更新成功，否則提示更新失敗的設備編號。

4 焊接機器人管控系統實現

該系統主要用于對不同廠商的焊接機器人進行統一的遠程管控，包含內網服務器1臺，機器人若干，現場采集PC若干。主服務器采用Windows Server 2012系統，機器人廠商主要包括KUKA，OTC，AMET和焊研威達等，現場采集PC主要采用Windows 10操作系統，每個PC包含至少2個以太網接口，機器人管控系統主要界面如圖6所示。

圖6 焊接機器人管控系統界面

5 結論

(1)系統的數據通信模塊能夠接入不同品牌的焊接機器人，也能夠接入PLC等現場設備。通過開發的模塊化基礎通信框架，可靈活、快速地適配新入廠的設備，高效地、穩定地完成數據的采集。并且能實現通信程序遠程更新功能，方便工程師維護管理。

(2)機器人管控系統可對不同品牌、不同通信協議的機器人進行統一管理和實時狀態監控。除此之外，系統還具有歷史數據的分析展示和機器人定期維護等功能。根據實際使用效果來看，系統能夠長時間穩定運行，提高了現場設備管理效率，降低機器人故障發生的次數，一定程度上提高了生產率。