基于虛擬設備模型的工業協議轉換方法研究

卞志國，湯東陽，曹棟

（1.南京工業職業技術大學計算機與軟件學院，江蘇 南京 210023；2.江蘇省工業軟件工程技術研究開發中心，江蘇南京 210023）

1 引言

在工業生產領域，由于自動化設備廠商和相關國際標準化組織的不妥協，導致了現場總線和工業以太網均出現了多種標準共存的局面，標準之間互不兼容，導致不同的工控協議使用不同的實現方法，數據組織方式、語義表示也不盡相同[1-2]。針對當前工業互聯網邊緣計算基礎網關與軟件平臺多協議交互形式存在普適性低、缺乏自適應能力等問題[3-7]，本文研究并開發在工業互聯網邊緣計算場景下，多種工控協議的自適應協議交互模型，解決具有有限聯網能力的設備之間進行數據交互過程中存在的瓶頸問題，從而實現該類設備之間通過協議轉換進行數據交互。

2 研究與方法

2.1 協議轉換流程設計

本文設計了一種滿足讀、寫、訂閱/發布、設備狀態查詢等功能的普適性數據交互語義模型，并利用Golang語言實現跨平臺的交互數據協議轉換服務。該服務北向與標準化協議客戶端通過HTTP 協議進行交互，負責將獲取的標準化協議數據轉換為普適性數據交互語義模型，南向與非標準化協議的智能設備或邊緣云平臺進行交互，將獲取的非標準化協議數據（如智能傳感器、無線設備、智能工業云平臺）轉換為普適性數據交互語義模型，從而為客戶端提供統一的數據輸入/輸出協議，系統總體架構如圖1 所示。

圖1 跨平臺交互數據協議轉換服務數據流

協議轉換網關實現了web 服務功能，向客戶端提供RESTful 風格的API 接口，客戶端通過向協議轉換網關請求數據，從而實現設備數據的讀、寫、訂閱/發布。協議轉換網關接收到客戶端發送的請求后，通過查詢其管理的設備資源模型，進行相應的操作，并向客戶端返回響應。

2.2 設備資源模型

（1）資源模型文件 本文采用統一的設備資源模型描述文件定義終端設備的數據資源，支持JSON 和TOML兩種文件格式。以Modbus 設備為例，其中Name 定義了設備的名稱，DebiceId 定義設備的ID 號，對于連接到該網關的設備而言，該ID 號應該是唯一的，Protocol 定義了設備支持的工業協議，本文采用動態加載的方式，支持Modbus、OPC UA、MQTT 三種協議。BaseInfo 給出了該設備所特有的信息，如Modbus 設備要求給出設備IP、設備端口號、從設備號、寄存器節點信息，其中寄存器節點信息表Nodes 定義了該設備所有可訪問寄存器數據的信息，包括地址、數據類型、數據長度，BaseInfo 部分根據設備協議的不同定義相應的字段。

（2）插件式協議轉換模塊 本文采用插件模塊實現非標準工業協議的轉換，開發了OPC UA、Modbus、MQTT 三種常用協議轉換模塊。

本文采用Golang 作為系統開發工具，作為編譯型的開發語言，Golang 本身并不支持通過源代碼實現動態加載和更新。但Golang 官方提供了Plugin 技術，實現動態加載。即通過動態共享對象封裝操作系統底層接口，對外提供統一的調用接口，以供上層應用程序調用，相當于提供了一層兼容層。

首先定義插件模塊基類，在此基類的基礎上，派生出對應協議轉換模塊，插件模塊關系如圖2 所示。

圖2 插件模塊關系

在插件模塊基類中，定義了設備的基礎信息，如設備名稱、ID 號、是否在線等，定義了共性操作方法，如初始化模塊，斷開連接，處理WebSocket 請求，處理HTTP 請求等。非標準協議轉換插件均派生于該基類，并根據非標準協議的具體操作規程，增加協議特有的操作，改寫基類中相應的函數等。

其次，在轉換軟件啟動時，掃描插件模塊文件夾，依次加載對應的插件模塊，協議轉換軟件服務的總活動流程如圖3 所示。

圖3 協議轉換軟件服務的總活動流程

2.3 協議轉換軟件設計

協議轉換軟件服務有兩部分組成，一是協議轉換軟件網關主線程，二是掛載在該服務器的虛擬設備線程。

軟件主線程啟動后，首先加載協議轉換插件，獲取該服務支持的非標準協議類型；然后從配置文件加載設備資源模型，構建虛擬設備；最后啟動web 服務，等待客戶端請求。服務端接收到客戶端請求后，首先解析請求數據，將對應的請求分配到對應的虛擬設備，如果對應的虛擬設備不存在，則直接返回錯誤信息，否則將對應的服務請求轉發至對應的虛擬設備線程；接著，虛擬設備線程將基于普適協議的請求數據轉換為對應的設備協議數據，對相應的設備進行讀、寫、訂閱等操作，并獲取相應的返回數據；最后，將返回的非標準協議數據轉換為標準協議數據，并返回到請求客戶端。

3 測試與分析

按照上述總體架構搭建測試系統，其中協議轉換網關分別部署于PC 機和RaspberryPi 3B，PC 機配置運行于Intel（R）Core（TM）i7-10750H CPU @ 2.60GHz，32G內存機器上的WSL Ubuntu20.04 子系統；RaspberryPi 3B配 置BCM2835，ARMv7 Processor rev 4（v7l），內 存1G。

利用Postman 對服務器進行不間斷寫操作訪問100次，統計API 響應時間，其平均每次API 響應時間見表1。

表1 API 請求響應時間（單位：ms）

API 一次完整的寫操作時間包括三個部分：一是客戶端與web 服務器之間消耗的時間，二是web 服務器與設備之間消耗的時間，三是協議轉換的時間，如圖4 所示。

因此表1 中ping 的時間只有t1+t6，而訪問設備的時間包括t1+t2+t3+t4+t5+t6，所以平均一次協議轉換時間不超過（t3+t4+t5+t6）/2，在本次測試中，平均轉換時間見表2。

表2 平均轉換時間（單位：ms）

從表2 可以看出，Modbus 耗時最長，這是因為Modbus 設備端對寄存器的讀寫是串行的，對設備的訪問相對較耗時間；MQTT 耗時最短，因為MQTT 寫完后并不需要等待返回數據因此相對速度較快。

4 結束語

本文提出的協議轉換方案優點主要體現在五個方面：①Golang 語言開發，部署方便，并發效率高；②設備協議插件化，便于擴展新的設備協議；③利用多線程技術及設備描述文件虛擬化設備，系統適應性強，響應速度快；④系統采用RESTful API 接口和WebSocket 長連接設計，便于多種類型客戶端操作各類協議設備；⑤系統運行環境適應性強，可運行于普通計算機平臺或樹莓派等嵌入式系統。