1 工業通信與OPC UA國內外對于OPC UA協議規范已經有了很多研究，國外西門子、ABB等公司均已推出了支持OPC UA規范的產品，也有很多成熟的OPC UA SDK，國內對于OPC UA研究較晚，但已有較多應用。為了解決工廠設備和協議多樣帶來的數據采集和上位機開發難題，本文設計了基于OPC UA的數據采集系統，實現工業設備協議到OPC UA協議的轉換，通過驅動開發和簡單配置就可以實現設備的兼容。本文設計了系統的總體方案，該系統由3部分構成：<01>本地工業設備網絡<02> 本地監控服務器<03> 云端數據處理服務器系統以本地監控服務器為核心，向下采集工業設備網絡數據并進行OPC UA協議轉換，建立OPC UA服務器和本地監控，向上結構化存儲工業設備數據到云端服務器。首先根據功能需求設計本地監控服務器，基于OPC UA SDK搭建OPC UA服務器，采用接口的方式標準化數據采集驅動和數據解析插件，實現工業機器人協議到OPC UA的轉換，同時使用WPF設計可視化本地監控和配置界面；然后基于Redis和MySQL建立云端數據庫，便于進一步進行數據開發和基于機器學習算法進行故障預測性分析；Zui后基于UR5和ABB120設計數據采集驅動和數據解析插件，使用開源的OPC UA客戶端和虛擬調試技術測試建立的本地監控服務器的完整性和可行性。2 系統需求分析與總體方案設計本文設計的基于OPC UA的數據采集系統，旨在為所有未提供OPC UA協議功能的設備建立通用的OPC UA轉換機制，實現不同工業設備通信協議到OPC UA協議的轉換。通過針對不同的工業設備設計標準的數據采集驅動，將工業設備采集的數據進一步分解加工為含有語義信息的OPC UA 格式信息，從而映射建立OPC UA地址空間，為不具備OPC UA功能的工業設備建立OPC UA服務器，實現設備協議標準化，建立設備的互通信，降低工廠設備和協議多樣帶來的上位機統一監控難題。圖1 系統總體構成圖Fig.1 Overall system composition diagram系統的總體構成如圖1所示，主要包括多種工業設備組成的工業設備網絡、實現協議轉換核心功能的本地監控服務器以及對采集數據存儲并處理的云端數據處理服務器。本地監控服務器通過以太網與工業設備網絡連接，以工業設備網絡為服務端，搭載本地監控服務器的PC機為客戶端，構成C/S(Client/Server)結構的本地數據采集和監控系統。采用多線程分別采集各工業設備數據，將采集的數據解析后映射到建立好的OPC UA地址空間，建立工業設備的OPC UA服務器。以本地監控服務器為服務端與遠程監控客戶端構成C/S結構的遠程監控系統。采集轉換后的數據上傳至云端服務器，云端服務器對數據進行結構化存儲以便進一步分析處理，實現故障預測。為滿足不同需求，云端服務器基于Redis和Mysql建立數據庫架構存儲設備數據，通過關系型數據庫存儲了設備的歷史數據以及設備間的層級關系，提高歷史數據的查找效率;采用Redis緩存實時數據，解決了實時數據訪問的速度問題以及系統并發請求的效率問題。本地監控服務器采用WPF設計監控界面，使用MVVM（Model View View Model）框架實現界面和后臺程序的分離，便于系統的拓展。通過任意具備OPCUA客戶端功能的設備可以直接訪問建立的OPC UA服務器從而達到遠程監控。3 本地監控服務器的設計本地監控服務器為整個系統的開發核心，為簡化其開發邏輯，根據本地監控服務器的各部分軟件調用分層，將其設計為5個主要功能塊：數據采集驅動開發、協議轉換、OPC UA服務器搭建、數據庫存儲、UI交互，如圖2所示，然后將各功能塊進一步劃分，細化系統的功能開發。圖2本地監控服務器功能圖Fig.2 Function diagram of local monitoring server圖3 本地監控服務器的功能連接Fig.3 Function-connection of local monitoring server如圖3為本地監控服務器各主要功能模塊連接圖。以UI交互界面為起點，首先進行系統的節點配置和解析配置，分別生成兩個XML文件保存配置信息，節點配置XML文件保存設備分類節點樹，解析配置XML文件保存所有數據請求的解析規則，即請求數據的信息(數據類型、語義、長度、索引)。數據采集部分讀取節點配置XML文件獲來取設備連接信息和數據請求信息，調用相應的數據采集驅動實現對工業設備的數據采集；數據解析部分讀取解析配置XML文件，將采集的設備數據轉換為具體的溫度、電壓、電流、關節等直觀可視數據。對每個設備都采用獨立的線程進行數據采集和數據解析。基于OPCUASDK建立的OPCUA服務器加載節點配置和解析配置XML文件，將工廠樹節點模型映射為自己的地址空間，建立OPC UA設備節點和值節點。解析后的數據填入建立好的OPC UA地址空間，完成OPC UA數據采集服務器的搭建，同時解析后的數據通過存儲模塊上傳到云端服務器實現持久化，便于進一步數據處理，此外解析后的數據通過MVVM框架不斷更新本地端UI界面顯示，實現本地對數據的實時監控。3. 1 OPC UA服務器的構建OPC UA服務器的構建主要有兩種方式，即根據OPC UA目前的13種規范[10-12]直接開發或者使用成熟的SDK間接開發。前者可以根據實際需要選擇性地實現相應功能，避免程序的冗余，但是需要深入理解OPC UA服務器的實現原理，比較耗時；后者基于已有的SDK開發，SDK包含了 OPC UA服務器所需要的全部方法，不需要開發人員對OPC UA有較深的理解，可以實現快速搭建。本文的OPCUA服務器就是基于OPC UA官方SDK開發，建立OPCUAServer類，在該類構造函數OpcUaServer（string url）中通過SDK給出的API接口對OPC UA服務器進行初始化并創建地址空間[13-14]，在服務器啟動時，通過建立OPCUAServer對象開啟服務器。其搭建流程如圖4所示。圖4 OPC UA服務器搭建流程Fig.4 OPC UA server setup process服務器初始化主要使用SDK中的接口Applicationin-stance, ApplicationConfiguration和StandardServer。首先通過Applicationinstance建立應用實例application;接著對應用實例進行基礎配置,即對ApplicationConfiguration進行初始化賦值，利用生成的xml節點文件和StandardServer生成服務器的地址空間，從而建立服務器對象server；Zui后利用應用實例開啟服務器對象運行服務器application.Start (server)。通過配置界面生成的XML文件結合SDK接口實現地址空間的建立是服務器構建的關鍵，在設備配置和解析配置界面建立的節點模型會存儲為XML文件，通過加載該XML節點模型文件，遍歷每個節點，使用SDK提供的接口將節點模型映射為OPC UA節點，并對每一個節點建立對應的NodelD和Description，從而完成地址空間的建立。通過數據采集解析后的數據根據OPC UA節點名稱一一存入OPC UA地址空間的值節點中構成完整的OPC UA服務器，OPC UA客戶端可以通過瀏覽服務器端的地址空間直接查看對應數據。3.2 數據采集與解析模塊的設計數據采集與解析模塊采用C#語言，基于Visual Studio 和.net Framework 框架設計構建。首先對整體程序需求進行分析，數據采集分為設備連接和數據請求。設備連接即通過獲取配置的設備IP地址和端口號等信息初始化設備數據采集驅動，建立與設備的Socket連接；數據請求則需要知道一次數據讀取的字節數或者寄存器數目以及讀取數據的起始地址等關鍵信息。解析模塊則是將每次數據請求獲取的原始字節碼數據流分割為獨立的數據，再將每個獨立數據進行數據類型轉換，轉為標準的可直觀理解數據，因此需要數據流中數據的數目 以及每個數據的數據類型。由于不同的工業設備所使用的通訊協議以及官方提供的SDK各不相同，并且設備中存儲數據的編碼格式略有差別，需要對工業設備分別設計數據采集和解析程序。為了對眾多的驅動程序實現統一管理和調用，采用接口的方式規范驅動的調用。根據需求分別建立設備接口和解析接口，設備接口主要實現設備連接和數據讀取方法，解析接口則實現數據類型轉換方法，不同的設備獨立實現接口方法。以UR5工業機器人為例，采用Modbus協議與其通信，基于Modbus協議設計UR5的數據采集和數據解析模塊。繼承設備接口實現UR5設備的數據采集驅動程序URDeviceBase，在 URDeviceBase中實現接口Connect，Read，Discon-nect和StartEngine等方法。Connect方法通過Socket與UR5建立連接，連接所需要的IP地址和端口號等屬性信息通過加載配置界面生成的XML文件獲取。Read方法根據參數“起始地址”和“字節長度”打包數據讀取的報文，通過建立的Socket通道發送到UR5工業機器人控制器，返回字節數組數據，Disconnect則斷開Socket連接通道，同時結束整個線程釋放所有資源。StartEngine方法首先建立新的線程，接著調用Connect方法建立連接，連接成功后不斷執行Read方法，并且將返回的字節數組除去報文頭存入屬性Data字節數組中。通過Modbus協議獲取的每個UR5數據都占用兩個字節，而標準的數據類型中Int占用4字節，Float占用4字節，Double占用8字節,因此在數據類型轉換方法中以0補滿缺省字節位，從而建立UR5的Modbus協議數據轉換規則，使用對應的數據轉換規則Transform將Data中的數據按照配置的解析規則分解轉換為具體的電壓、電流、關節等數據，Zui終轉換的數據以鍵值的形式存入設備的數據詞典DictionaryData中。3.3 UI交互界面的設計UI交互界面的主要功能是配置和監控顯示，可實現系統通用功能、方便使用者操作該系統。本文基于WPF框架設計了 UI交互界面，WPF是微軟推出的基于Windows的用戶界面框架，真正分離了界面設計與開發，分別利用Xmal語言和C#語言設計純圖形界面和建立后臺事件，采用MVVM模式Zui大限度降低界面Xmal文件與后臺CS文件的耦合度，使得界面的大幅修改不會對邏輯代碼產生較大影響。UI交互界面核心是配置功能，即節點配置、解析配置和OPC UA服務器配置，并且根據界面配置生成Xml文件。圖5為設備節點配置界面，圖5()為節點配置界面，其中左側框通過TreeView控件根據實際工廠建立樹節點模型，即添加分類節點和設備節點，添加的每一個節點都要配置基礎信息，右側框顯示選中的節點配置信息。圖5(b)對普通分類節點配置基本描述Description和名稱Name。圖5(c)對設備節點進行參數配置，包括連接工業機器人設備基本的端口號Pot、IP地址IpAddress和超時時間TimeOut以及通用的節點描述和節點名稱。通過以上3 個界面實現基本的樹節點模型建立和節點信息配置，其中設備節點的配置用來建立系統和設備的Socket連接通道，而后臺實現一次數據采集操作，發送的報文信息要包括基本的寄存器起始地址、采集數據長度（字節數或寄存器數，一個寄存器包含兩字節數據）和數據請求超時時間。圖5(d)界面對設備添加數據請求并且配置數據請求的起始地址和字節長度，其中解析規則即建立的數據解析配置，每個數據請求都要提前建立其數據解析，即對采集的數據段添加描述，以便將其劃分為具體的單個數據。圖5設備節點配置界面Fig.5 Device node configuration interface解析規則配置界面是對數據請求的字節數組數據進行配置，由于數據地址在設備寄存器中多是連續的，每次數據請求都需要通過Socket通道發送一次數據讀取的命令，采用一個數據發送一次命令的方式耗時過多，因此一次讀取連續的一串數據，讀出的數據如圖6所示是一串字節數組，為了將一次數據請求讀取的連續字節數組數據劃分為具體的電壓、電流、開關狀態等值數據，需要知道每段值節點在該數據請求獲取的字節數組的索引值以及該值節點的字節長度、語義(電壓、電流)、數據類型(Float.Bool)等。而這些信息都因通信協議的不同而不同，需要從官方所支持的該通信協議文檔中獲取。圖6 數據請求示意圖Fig.6 Data request diagram根據官方的說明文檔將字節數組數據劃分為單個值節點數據，并且配置好各值節點的數據名稱、數據類型、字節長度等，以便解析模塊通過該配置信息解析采集的工業機器人數據。圖7()為解析規則配置界面，界面左側為數據請求以及各請求所包含的值節點名稱，右側展示一次數據請求所包含的值類型、長度和名稱，圖7(b)為具體的值節點配置界面。圖7 解析配置界面Fig.7 Analytic configuration interface4 云端數據處理系統設計云端數據處理系統設計為數據存儲和數據分析兩部分，通過合理的數據庫選型和存儲結構搭建，將工業設備運行數據結構化存儲在云端服務器，并利用云服務器的計算能力，結合機器學習算法對大量的歷史數據和實時數據計算分析，實現一定程度的故障預測，減少突然停機帶來的風險和損失。 除此之外，基于云端數據存儲，結合Web技術可以建立B/S（Browser/Server）結構的工業設備遠程監控系統，利用存儲的工業設備數據做進一步開發。本系統的數據存儲部分主要存儲工業設備運行數據和工業設備相關參數信息，而且要具備一定的拓展性，除此之外，成本和使用便捷性也在考慮之列，結合實際需求，本文綜合考慮ElasticSearch，Redis，MySQL，MongoDB 等4個數據庫的 優缺點進行數據存儲系統選型。由于系統基于.NET平臺開發，而且要具有一定的存儲容量，因此排除了使用ElasticSearch和Redis來存儲工業設備的運行數據；再對比MySQL和MongoDB，雖然MySQL的部署、管理和配置較為復雜，但是它的穩定的讀寫能力以及高可用、支持在線擴容等優點很符合本系統需求，因此選擇MySQL作為系統的主體數據存儲數據庫。除了使用MySQL存儲工業設備大量的運行數據外，本系統還采用了非關系型數據庫Redis作為系統的外部緩存，以提高系統熱點數據的讀取速度。Redis數據庫能夠自動執行持久化操作，避免了服務器崩潰帶來的熱數據丟失，同時可以在服務器重啟后自行恢復數據。本系統采用MySQL和Redis相結合的數據存儲方式，數據存儲時經底層采集解析后的數據分別存入Redis和MySQL中。由于設備數據已由協議轉換部分全部轉換為OPC UA節點形式，每一個數據都有唯一的節點標識NodelD，以NodelD為Key，以值節點為Value，將所有數據以List列表形式存入Redis中，同時對存入Redis中的數據設定過期時間和內存釋放策略，基于時間局部性原理清除使用頻率較低的數據，避免內存占用過高。數據在MySQL中的存儲以分類節點建立表結構，中間表按照設備進行分類建立，Zui后以值節點的各屬性值單獨建立數據表。通過各表之間的關系清晰地反映節點的層次結構，以便上層軟件的數據庫查詢操作。由于高訪問的熱點數據被轉存在Redis中，數據查詢時，首先從Redis中查找，Redis查詢無果則轉向MySQL中搜索。5 實驗驗證5.1 OPC UA客戶端測試基于OPC UA的數據采集和處理系統旨在實現多種工業設備數據的采集到OPC UA協議的轉換，以達到使用同一個OPC UA客戶端集中監控的目的，同時對采集的數據建立云端存儲體系，便于進一步利用大量的工業設備運行數據實現故障預測分析。本文以UR5和ABB120兩臺工業機器人為研究對象，驗證整個系統的完整性、可靠性。針對UR5和ABB120分別采用Modbus協議和PC SDK按照系統的標準開發數據采集驅動和數據解析模塊，將驅動裝載入本地監控服務器端。首先設置IP地址，在機器人控制器中將UR5設置為192. 168. 10. 10,ABB120 則設置為 192. 168. 10. 11，搭載本地監控系統的主機IP設置為192. 168. 10.1，從而使得三者在同一局域網內。如圖5在節點配置界面中配置好UR5和ABB120設備節點的連接參數，并且分別添加六關節電流的數據請求，以UR5為例，數據請求的起始地址為290，總長度為6個寄存器即12字節，在解析規則配置界面對該數據請求 的12字節數據進行語義配置，設置其數據類型為Float。如圖8所示對OPC UA服務器系統進行設置，包括基本的登錄用戶名和密碼、服務器地址以及安全代理“ SecurityPolicyNone”，接著運行服務器。圖8 系統配置Fig.8 System colfiguration圖9 OPC UA客戶端Fig.9 OPC UA client如圖9所示，通過官方開發完備的OPC UA客戶端連接OPC UA服務器測試服務器的可靠性和完整性。在Address地址欄填入服務器的URL地址，建立連接成功后，客戶端右側框中顯示服務器端配置的節點信息，選中UR5設備節點，查看設備的配置信息和數據請求的六關節電流數據，由此可以驗證OPC UA服務器搭建成功，數據采集驅動和數據解析模塊設計可行，系統可以實現工業機器人協議到OPC UA的轉換，可以實現OPC UA客戶端的遠程監控功能。5.2 基于虛擬調試系統的測試結合虛擬調試系統，測試數據采集系統采集數據和存儲數據的準確性 、完整性。虛擬調試用以測試運行在物理系統的程序邏輯，提高程序實際運行的安全性。在實驗中，通過數據采集系統獲取實際工業設備的運行數據，首先將其存儲在云端數據庫，然后虛擬調試系統從云端數據庫獲取實際工業設備全部的運行數據，通過這些數據驅動虛擬設備運行，觀察虛擬設備是否能完成物理設備完整的操作。采用如圖10所示的虛擬調試系統，通過界面配置，首先連接虛擬設備，通過輸入配置連接Redis,獲取數據采集系統采集的物理設備數據，通過輸出配置將采集的物理設備數據導入虛擬設備中運行，對比虛擬設備和物理設備的運行情況。在RoboDK中導入機器人和車床的模型，然后構建虛擬平臺，如圖11所示。圖10虛擬調試系統配置Fig.10 Virtual debug system colfiguration圖11 RoboDK虛擬設備Fig.11 RoboDK virtual equipment通過物理設備的簡單取件操作來測試系統，操作流程是機器人從倉庫取出工件并放置于車床的卡盤上，然后車床門關閉。如圖12所示，可以看到仿真機器人及時準確地從Re-dis中獲取到了真實機器人的位置數據，并準確將工件放置在了卡盤上，虛擬設備通過采集的物理設備數據準確地復現了物理設備的操作，說明數據采集系統能準確完整地采集并且轉換物理設備數據。圖12虛擬設備運行結果Fig.12 Virtual equipment running results6 結束語 本文設計并且實現了基于OPC UA的數據采集系統，旨在實現不同工業設備協議到OPC UA標準協議的轉換，以達到使用任意具有OPC UA客戶端功能的設備就可以實現對工廠所有工業設備數據的遠程查看和監控。本文通過設計數據采集接口來標準化工業設備不同協議的數據采集驅動。針對任意工業設備，只要按照標準接口設計好相應的驅動，在本地監控界面做簡單的配置，就可以實現到OPC UA協議的轉換。除此之外，本系統還建立了基于Redis和MySQL的云端數據存儲結構，二者都具有良好的擴展性，存儲的工業設備運行數據結合機器學習算法可以實現一定程度的故障預測分析，減少了設備突然停機帶來的危害和損失。本文通過UR5和ABB120工業機器人驗證了系統的可行性和完整性。所提系統解決了工業設備和協議多樣帶來的上位機軟件多樣化問題，具有較強的通用性。