工業物聯網數據采集系統的開發

何圣華

摘要 針對工業物聯網在智能制造中的重要地位和目前工業物聯網數據采集遇到的問題，本文提出一種基于OPC UA的工業物聯網數據采集框架，概述了OPC UA的體系結構和應用優勢，分析了優化OPC UA數據傳輸實時性的方法，最后分別介紹了基于Open62541開發包的服務器開發方法和基于.net的OPC UA SDK的客戶端開發方法。

【關鍵詞】工業物聯網 數據采集 OPC UAOpen62541 0PC UA SDK

1 引言

1.1 工業物聯網數據采集的意義

德國的工業4.0計劃拉開了全球第四次工業革命的序幕，工業4.0的主要特征是基于物理和信息系統深度融合的高度網絡化和智能化的新一代制造系統。這個新一代的智能制造系統由很多重要的子系統組成，其中，工業物聯網就是智能制造系統的基石，工業物聯網可以幫助傳統工業提升到智能化的新階段。智能制造系統的建造從工業物聯網開始，而工業物聯網的性能和質量則決定了智能制造系統建造的高度。工業物聯網的數據以及數據流，就像智能制造系統大廈的能源和照明系統，有了工業物聯網的數據采集和數據傳輸，智能制造系統才有了動力的保障。所以說，工業物聯網是工業4.0的基礎，工業物聯網的數據采集、數據傳輸和數據利用是構建物理信息系統和實現智能制造的必要條件。

1.2 工業物聯網數據采集面臨的困難

工業物聯網的數據采集對于智能制造的實現尤為重要，但是，目前工業物聯網的數據采集和傳輸卻存在不少的困難，嚴重影響著智能工廠建設的信心和進程。這些工業物聯網數據采集的困難主要表現在三個方面：第一個困難是由于歷史上不同廠商的競爭和利益保護的原因，工業物聯網的數據采集無論是網絡層的還是傳輸層的協議都非常多，導致數據采集系統的集成難度大、管理成本高;第二個困難是在智能制造系統的不同層之間，采集和傳輸過程中的數據語義無法統一，難以實現數據的集成和模型的集成，造成數據難于被智能工廠的其他層所利用;第三個困難是智能制造系統建設過程中，針對不同設備和不同協議的數據采集程序的開發難度大、開發門檻高，阻礙智能制造系統的建設。

針對上述問題，本文第二部分重點介紹一個基于OPC UA協議的工業物聯網數據采集的框架方案，然后討論基于這個框架的OPC UA的數據采集優化方法，最后，本文第三部分還將介紹這個數據采集方案中相關的服務器與客戶端開發技術，希望能夠為工業物聯網數據采集和智能制造系統的建設提供一點參考。

2 工業物聯網數據采集框架研究

2.1 基于OPC UA的工業物聯網數據采集框架

為了應對上一節提到的工業物聯網數據采集中面臨的問題，本文提出如圖1所示的基于OPC UA的工業物聯網數據采集框架：

如圖1所示，這個數據采集框架被劃分為四層。底層是有由泛在化的生產加工設備、生產輔助設備和傳感器組成的設備傳感層，在這層里，設備的基礎數據和狀態數據先是被封裝到OPC UA服務器里，然后通過OPC UA的訂閱/發布或者是查詢的模式自動地向更高層的應用傳輸。

數據采集框架中的第二層網絡聯接層負責把工廠底層的設備與工廠的信息化系統、把企業外部的互聯網和各種云應用聯接起來。網絡聯接層促使企業內部的組織和管理結構扁平化，同時，網絡聯接層的設備控制網和企業信息網也向著合二為一的方向發展。

第三層是企業信息化層，這一層的特點是在業務過程數字化的基礎上，把設備傳感層的數據通過OPC UA的客戶端進行采集，然后保存到本地數據庫、云端數據庫或者是傳輸到企業內部的其他應用系統之中，從而實現ERP、MES等業務系統的集成化以及生產上下游的管控一體化。

最上面的一層是智能制造與云制造層，這一層主要的特征是產品的個性化、設計的社會化和制造的智能化。在圖1的數據采集框架中我們可以看出，OPC UA不僅僅是工業領域通用的數據傳輸標準，而且，它還通過信息模型的封裝實現了智能制造各個層之間的數據語義統一性，因此，OPC UA被稱為工業4.0的基礎，基于OPC UA的工業物聯網數據采集方案具有重要的意義和良好的可行性。

2.2 0PC UA的體系結構

本文介紹的工業物聯網數據采集方案以OPC UA協議為基礎。OPC UA （OPC UnifiedArchitecture）發展自傳統的OPC協議，是目前工業通信的主要通信協議。IEC 62541對OPC UA協議進行了標準化。通過IEC 62541系列標準，我們可以更好地理解OPC UA的規范和體系結構。IEC 62541系列分為13部分，這13個部分可以分為三大類：

2.21 核心類規范

核心類規范給出了地址空間、信息模型，訂閱、通知、服務集等重要概念的解釋，描述了OPC UA典型的目標應用、系統架構、服務架構和客戶端架構。核心規范的第四部分服務和第七部分子集協議規定了服務器和客戶端可以調用的服務集，這些服務集包括發現服務集、安全通道服務集、節點服務集、屬性服務集、查詢服務集等10個服務集。這些服務集中的服務可供OPC UA的服務器、客戶端和其他終端節點調用。

2.2.2 訪問類型規范

訪問類型規范規定了如何通過OPC UA進行不同類型的數據訪問（DA、A&E、HAD等），OPC UA這種一致、完整的地址空間和服務模型，解決了過去同一系統的信息不能以統一方式被訪問的問題，使得OPC UA的配置時間和整個工程的時間也因此可以大大縮短。

2.2.3 應用類規范

應用類規范包括Discovery和Aggregates兩部分，它們規定了OPC UA在實際應用中如何解決一些具體技術問題。

2.3 0PC UA體系的幾個優勢

OPC UA之所以能成為工業通信和數據交互的標準，除了它有完整的體系架構外，還因為它有幾個突出的優勢，使它成為一個更安全、更易集成、更加標準化、更易擴展的標準和應用框架：

2.3.1 跨平臺

OPC UA不再基于分布式組件對象模型（DCOM），而是以面向服務的架構（SOA）為基礎，這使得OPC UA具有與其他系統更好的兼容性它不僅可以運行于windows平臺，還可以運行于各種Linux和嵌入式平臺。這種基于服務的架構使得它與傳統的OPC，相比，可以突破局域網的限制，拓展為基于英特網的數據訪問。

2.3.2 訪問統一性

OPC UA有效地將原有的OPC規范（DA、A&E、HDA、命令、復雜數據和對象類型）集成進來，并且提供了一致、完整的地址空間和服務模型，解決了過去同一系統的信息不能以統一方式被訪問的問題。為了提高傳輸性能，OPC UA消息可以被編碼成XML文本格式或是二進制格式，可以使用TCP或是HTTP傳輸協議進行傳輸，使得OPC UA客戶端對于服務器的訪問更加靈活方便。

2.3.3 可靠的安全認證

OPC UA訪問規范明確提出了標準安全模型，每個OPC UA應用都必須執行OPC UA安全協議，這在提高互通性的同時降低了工程維護和額外配置費用。OPC UA的數據可靠性來源于幾個方面：一是基于Session的可靠通信機制，能夠保證服務器和客戶端的長時間穩定連接;二是數據的安全性通過用戶鑒權、簽名和加密傳輸等技術來保障，保證了消息的完整性，也防止信息的泄漏;三是OPC UA對數據通信和數據異常有良好的魯棒性，如可配置的超時、數據冗余、自動錯誤檢查和自動恢復等機制來預防數據丟失、數據異常，從而實現高可用性。

2.3.4 完善的服務集

OPC UA服務集一共包含10個，如用于發現和注冊OPC UA服務器的發現服務集;用于打開和關閉通道的安全通道服務集等等。這10個服務集為構建面向服務的OPC UA數據通信架構奠定了良好的基礎。

2.3.5 統一的信息模型

OPC UA的地址空間組織方式使得OPCUA可以對外提供統一的信息模型。OPC UA的某個具體應用的信息模型是開發者為了實現特定任務而對數據所進行的標準封裝。OPCUA的地址空間由一系列節點組成，服務器可以在它們的地址空間中自由地組織它們選擇的節點。節點間引用的使用，允許服務器可以把地址空間組織成分層結構，網狀節點結構，或任何可能的結構混合。地址空間中的節點用來代表真實對象，以及它們的定義和相互之間的引用?？蛻舳丝梢酝ㄟ^使用OPC UA服務（接口和方法）來訪問節點。此外，統一對象模型允許把數據訪問，事件報警，和歷史數據訪問功能集成到一個單一的OPC UA服務器中。

2.3.6 良好的可擴展性

OPC UA良好的可擴展性體現在兩個方面：一是OPC UA與其他的工業標準具有良好的兼容性。除了已經納入到OPC UA架構下的等之外，OPC UA還支持行業自定義的信息模型。這些自定義的信息模型包含了基礎信息模型、行業信息模型，也包括制造商自定義的信息模型，它們為OPC UA的應用提供了良好的可擴展性;OPC UA可擴展性的第二個方面是OPC UA用面向對象的編程方法支持類的定義、集成和實例化，可以方便地進行擴展。

2.3.7 通過OPC UA相關的SDK降低開發成本

OPC基金會和IEC組織都提供了一些OPC UA服務器端和客戶端軟件開發的SDK工具，這些SDK可以幫助開發商降低開發成本，供應商也可將更多的精力關注在為客戶提供更有價值的產品上。

基于上述原因，OPC UA已經成為工業4 0時代工業大數據采集的重要實現技術。

2.4 提高OPC UA實時性的方法研究

工業現場對于數據采集的實時性有很高的要求，因此，對于智能制造而言，研究如何提高工業物聯網數據采集的實時性和效率有重要的意義。我們在2.2節已經大致了解了OPCUA的體系結構，本小節將進一步討論OPCUA的數據傳輸過程，并討論如何提高OPCUA數據傳輸的實時性。圖2表示了OPC UA數據傳輸過程的模型。

在圖2我們可以看出，基于OPC UA的數據采集和傳輸過程從采集物理設備的模擬量和數字量開始，到OPC UA的客戶端接收到相關的變量值的過程一共可以分為三個階段：

第一階段是物理量的采集過程。在這個過程之中，服務器中的實時采樣線程周期性地采集物理設備的數字信號和模擬信號，因此，物理量的采樣周期大小是影響OPC UA數據采集實時性的第一個因素;

第二個階段是服務器中數據監控項的采樣過程?？蛻舳擞嗛喠四硞€服務器的數據監控項后，服務器中就產生對應這個監控項的一個訂閱，這個訂閱也周期性地刷新物理量采樣周期獲得的內存數據映射的值，這個周期稱為監控項的采樣周期。顯而易見，這個監控項的采樣周期也會影響OPC UA的整體數據采集的實時性。在監控項采樣過程階段，我們可以設置監控項的死角，死角設置得小，客戶端對于監控項的數據變動就敏感，但是死角的值設置得太小則會造成過于頻繁地向客戶端發送通知消息，因此，合理設置監控項的死角在實際應用過程中非常重要。

第三個階段是訂閱數據的發布過程，這個過程中，服務器會向客戶端定期地發送訂閱中的通知信息，而這個發送的周期就是訂閱數據的發布周期。同樣，這個周期也會影響OPCUA服務器和客戶端之間的數據傳輸的實時性。

從圖2的OPC UA數據傳輸模型我們可以看出，物理量的采樣周期、監控項的采樣周期、訂閱數據的發布周期以及監控項的死角都會影響OPC UA的數據傳輸實時性，這些周期設置得過大的話不能實時反映數據的變化，周期設置得過小的話，會增加采集過程的設備計算壓力和網絡帶寬壓力。同樣，監控項的死角參數設置也需要注意這樣的問題。因此，我們需要在實際的工程項目中合理配置和動態設置這些參數。

3 0PC UA服務器與客戶端開發

前面我們提出了基于OPC UA的工業物聯網數據采集的框架，探討了OPC UA的體系結構和優化方法，下面簡單介紹一下基于OPC UA相關開發工具的服務器和客戶端開發方法。

3.1 0PC UA服務器開發

IEC組織不僅制定了IEC62541的OPCUA標準，而且為方便開發者開發OPC UA相關的服務器與客戶端，還提供了一個名為Open6254的SDK。Open6254是一個基于c語言的開發OPC UA服務器和客戶端的開源實現工具。采用C語言開發包開發的程序運行速度快，而且對操作系統和硬件設備的配置要求低，可以運行于嵌入式設備和微型計算機系統中。圖3簡要表示了基于Open62541進行服務器開發的技術模型。

Open62541以函數調用的方式提供服務器配置、服務器生命周期管理、節點管理、引用管理、節點讀寫、方法管理等功能，例如我們可以調用上圖服務器生命周期管理模塊中的UA_Server_run_startup，UA Server_run， UA Server run iterate， UA Server runshutdown、UA Server_ delete等函數來實現服務器的啟動、運行和關閉、刪除等功能。我們可以用Attribute Service Set，NodeManagementService Set，Monitoredltem等服務集之中的函數來實現屬性管理、節點管理、監控項管理等功能。在Server Configuration中，UAUsemamePasswordLogin結構體包含了連接該服務器的賬號和密碼以保證通信的安全。此外，在變量與物理過程映射模塊，在運行的過程中有三種更新設備變量的方法：

（1）手動更新變量;

（2）通過回調函數更新變量;

（3）通過數據源來更新變量。OPC UA客戶端通過接收服務器發布的通知來獲得最新的數據。

3.2 0PC UA客戶端開發

在上述的數據采集與監控方案中，OPCUA客戶端起到向下采集底層設備的狀態、向上與企業層生產計劃和管理軟件相聯系的作用。我們可以在PC端工作站中利用.net的OPC UA SDK來開發和部署客戶端。

OPC UA SDK（OPC UA軟件開發包）是一套可以讓人在NET開發環境中快速開發UA應用的開發接口庫和可執行程序。OPCUA SDK包含客戶端開發和配置工具。OPCUA SDK實現了IEC 62541中定義的所有服務、協議棧、消息終端、安全協議和傳輸協議。

如圖4所示，我們可以用OPC UA SDK來開發Client、Server和Webservice。OPCUA SDK的結構如下圖虛線框中部分所示，它由四部分組成：Comlnterop提供了傳統的OPC和OPC UA之間的無縫的互操作性。ConfigurationTool用作UA應用的安全和COM互操作性的配置工具。Stack是.NET環境的OPC UA協議棧庫。SDK包含了六個部分：其中，Controls是一組控件，我們在開發客戶端程序的時候可以直接使用這些控件，例如在Common控件組中，我們可以使用DiscoveredServerListCtrl控件來列出某個地址主機的上的server，用ConnectServerCtrl控件來連接server等。Client lib則是我們在開發客戶端程序時可以使用的一些類和函數，例如創建監控項的Monitoredltem類和創建訂閱的Subscription類。由此可見，有了這個OPCUA SDK，我們無需自己去實現OPC UA的底層通信協議，而只要使用控件和調用相應的client development toolkits就可以實現數據的采集與監控方面的應用。

使用上述工具和方法來開發OPC UA客戶端，客戶端與服務器的平臺性質無關，ConfigurationTool組件保證了客戶端訪問的安全性，Stack中的UA Core lib實現了IEC62541標準中的底層棧和協議，具有很好的通用性。client development toolkits中用面向對象方法設計的類既可以被繼承，也可以根據需要來被重構。通過Net平臺的OPC UASDK，我們還可以面向企業級應用來開發相應的Webservice，從而滿足智能制造系統在數據采集與監控方面的更多的需求。

4 小結

智能制造是世界各國工業發展計劃的目標，然而工業物聯網底層數據的采集、傳輸過程中遇到的協議不統一、實時性有待提高、相關程序開發難度大等也是業界普遍遇到的問題。本文從這些解決這些實際問題出發，提出基于OPC UA的工業物聯網數據采集框架，介紹了框架中包含的各個層的內容和框架中采用的數據協議與數據接口。本文還以OPC UA的體系結構分析為基礎，探討了OPC UA數據采集和傳輸實時性的優化方法，最后分別介紹了基于Open62541開發包的服務器開發方法和基于net的OPC UA SDK的客戶端開發方法。

參考文獻

[1]鄭樹泉，工業物聯網大數據平臺架構與應用[J].軟件產業與工程，2016 （06）：15-18.

[2]康世龍，杜中一，雷詠梅等，工業物聯網研究概述[J].物聯網技術，2013 （06）： 80-82.

[3]謝青松.面向工業大數據的數據采集系統[D].華中科技大學，2016.

[4]貝加萊.OPC UA-智能制造的數據基礎[J].國內外機電一體化技術，2017 （06）： 40-41.