王燦達，李 悅，李 鋒

(東華大學 計算機科學與技術學院，上海201620)

0 引 言

伴隨著《中國制造2025》戰(zhàn)略計劃的不斷推進，學術界與工業(yè)界將越來越多的目光投向了智能制造的研究與實踐。為了生產數(shù)據實時處理的需要，數(shù)據在邊緣側處理后，再與云計算中心進行交互，這種云邊協(xié)同的模式是智能制造發(fā)展的一個新趨勢［1］。保證生產信息的收集、存儲與傳輸，使得云中心能快速方便地獲取到來自于生產設備的信息，是實現(xiàn)云邊協(xié)同的關鍵因素。但目前生產設備種類繁多，通訊接口協(xié)議各異，上層應用系統(tǒng)需針對各類設備單獨開發(fā)子模塊用于數(shù)據交互，這無疑增大了開發(fā)的難度，阻礙了智能制造的發(fā)展［2］。OPC統(tǒng)一架構即OPCUA，定義了一組高可用、高性能和跨平臺的數(shù)據交互規(guī)范［3］。基于OPCUA技術所開發(fā)的網關可屏蔽不同設備的通訊細節(jié)，對外部系統(tǒng)訪問生產設備數(shù)據提供統(tǒng)一標準的接口［4］。在實際生產中，網關處于生產設備邊緣，由于現(xiàn)場網絡的不確定性較高，通訊不穩(wěn)定，存在數(shù)據丟失的風險。而在工業(yè)生產中，網關所傳輸?shù)臄?shù)據涉及到設備主要生產指標以及控制數(shù)據，對數(shù)據的完整性要求較高。因此，OPCUA網關中應具備數(shù)據存儲能力，遇到網絡中斷時，網關可繼續(xù)準確采集，并將數(shù)據存儲到非易失設備中，當網絡恢復正常時，其它第三方平臺可從網關中獲取完整數(shù)據。這就保證了可靠的數(shù)據服務，提高了系統(tǒng)的魯棒性與容錯性［5］。

目前，在智能制造網關的研究中，學者大多關注于不同協(xié)議之間的轉換［6］、信息通訊的安全性［7］以及網關的邊緣計算能力［8］等方面，部分學者注意到了網關對于數(shù)據的存儲能力，但現(xiàn)有的數(shù)據庫系統(tǒng)仍是其不二選擇。文獻［9］在對基于OPCUA的工控信息化數(shù)據網關的研究中采用了SQLite；文獻［10］在設計家庭看護系統(tǒng)的智能網關時選擇了MongoDB。此外MySQL、HBase也廣受學者們的青睞［11］。由于數(shù)據庫的運行需要較多的系統(tǒng)資源，這就對硬件配置提出了較高的要求，而網關設備硬件資源緊張，運行數(shù)據庫軟件較為困難。此外，操作數(shù)據庫需要建立網絡連接、傳輸數(shù)據、關閉連接等一系列耗時步驟，這會導致網絡I／O速度成為系統(tǒng)運行效率的瓶頸?，F(xiàn)有的數(shù)據庫軟件為追求更廣泛的應用場景，其存儲與查詢設計具有一定的通用性，并不會針對OPCUA網關程序做專門的優(yōu)化?；谏鲜霈F(xiàn)狀，本文設計了一套內存與外存協(xié)同的數(shù)據存儲系統(tǒng)（Storage System Based On Ram And External Storage Data，簡稱RES），專用于對OPCUA網關數(shù)據的存儲。RES只保留了核心的數(shù)據存儲與查詢功能，抹除了事務、存儲過程等額外的數(shù)據庫功能，故其資源占用率小，硬件要求低；另外RES可直接嵌入到OPCUA應用程序中，二者之間的互操作不再需要占用網絡I／O資源，大幅度提升了程序運行效率。

1 OPCUA網關總體架構

OPCUA網關采集設備信息并存儲，對外部呈現(xiàn)OPCUA數(shù)據接口。在邏輯上，網關系統(tǒng)分為3層，分別為采集層、存儲層與服務層，如圖1所示。采集層讀取生產設備數(shù)據，整合目前采集生產數(shù)據常用的接口（如RS485、RS232、USB等），并針對不同的通訊方式開發(fā)不同的驅動程序完成數(shù)據的采集，之后將數(shù)據寫入到存儲層。存儲層為服務層提供數(shù)據支撐，分為內存存儲與外存存儲兩部分。外部系統(tǒng)通過OPCUA客戶端與網關服務層建立安全連接。連接成功的客戶端可瀏覽服務層地址空間，訪問結點的當前數(shù)據與歷史數(shù)據，還可以對節(jié)點進行訂閱，當數(shù)據更新時自動獲取。

圖1 網關整體架構Fig.1 Gateway architecture

2 內外存協(xié)同的數(shù)據存儲

數(shù)據庫可劃分為二種，一種是傳統(tǒng)的關系數(shù)據庫，主要以外存作為存儲介質，如Oracle、MySQL等，數(shù)據的訪問會同時涉及磁盤I／O與網絡I／O，速度較慢；另一種是實時數(shù)據庫，主要以內存作為存儲介質，如Redis、Memcached等，此類數(shù)據庫直接基于內存操作，速度較快，但受限于內存資源，其存儲容量有限。若將二者結合，外存型數(shù)據庫用于持久化存儲“冷數(shù)據”，即訪問頻次較低的數(shù)據；內存型數(shù)據庫緩存“熱數(shù)據”，即訪問頻次較高的數(shù)據，可揚長避短提升系統(tǒng)性能。本文的RES就是基于上述思想所設計，用以適應OPCUA網關中采樣數(shù)據管理，在有限的硬件資源下可保證數(shù)據的讀寫速率與存儲容量。

2.1 內存儲結構設計

生產過程中設備數(shù)據具有數(shù)值和時間屬性，本文采用OPCUA標準中的DataValue數(shù)據對象來表示。DataValue的各屬性見表1。

表1 DataValue屬性Tab.1 Datavalue property

DataValue對象可描述某個節(jié)點在某一時刻的具體值，對其按照時間順序存儲，則可記錄某一節(jié)點數(shù)據隨時間的變化情況。由于數(shù)組可滿足對元素的有序存儲，故本文為每個節(jié)點建立一個固定長度的DataValue數(shù)組，在內存中存儲該節(jié)點的時序數(shù)據。為建立起節(jié)點與數(shù)組的對應關系，方便根據節(jié)點的唯一標識符（nodeId）對數(shù)組進行查找，本文引入哈希集合作為最外層容器。哈希集合以鍵值對的方式進行數(shù)據映射與存儲，每個節(jié)點的nodeId作為鍵，與節(jié)點對應的數(shù)組作為值共同存儲在哈希集合之中。內存存儲結構如圖2所示。

圖2 內存存儲結構Fig.2 RAM storage structure

2.2 外存存儲結構設計

外存存儲結構三要素為:記錄、數(shù)據頁、索引，如圖3所示。記錄是節(jié)點數(shù)據在外存中最基本的存儲形式，每行記錄包含3個字段見表2，分別是nodeNumber、value、timeStamp。為方便對記錄排序，本文對OPCUA模型中所有節(jié)點重新編號并與其nodeId一一對應。

圖3 外存存儲結構Fig.3 External storage structure

表2 記錄字段Tab.2 Record field

數(shù)據頁保存著記錄，可分為3部分:頭信息、頁目錄與記錄。頭信息是為生成索引服務的，包含數(shù)據頁所有記錄中最早時間的時間戳與最晚時間的時間戳；每個節(jié)點所對應的記錄在此數(shù)據頁的位置區(qū)間存放于頁目錄之中，通過查閱頁目錄可高效地根據節(jié)點編號鎖定想要的數(shù)據。為方便對數(shù)據頁的組織管理，數(shù)據頁大小固定且以阿拉伯數(shù)字順序從1開始逐個編號，越晚生成的數(shù)據頁其頁號越大。索引頁只記錄數(shù)據頁頁號及此數(shù)據頁的頭信息，在查詢所需數(shù)據時遍歷索引，可快速定位目標數(shù)據頁。

2.3 數(shù)據的寫入與訪問機制

2.3.1 數(shù)據寫入機制

設備數(shù)據從網關采集層寫入網關存儲層的流程如圖4所示。首先會在OPCUA地址空間中更新此節(jié)點的當前值，之后根據此值封裝一個DataValue對象放入與該節(jié)點對應的數(shù)組，用于在內存中緩存節(jié)點的“熱數(shù)據”。若數(shù)據量超出了數(shù)組的容量，則會按照時間順序對早期放入數(shù)組的數(shù)據進行清除，確保內存中總是緩存設備新產生的數(shù)據，在實際生產中新數(shù)據被訪問的頻次大于舊數(shù)據。

圖4 數(shù)據寫入流程Fig.4 Data writing process

為確保節(jié)點數(shù)據的完整性以及整個系統(tǒng)的魯棒性，當數(shù)據更新時還會生成一條記錄，用于在外存中持久化存儲?？紤]到外存I／O耗時較長，此記錄并不會立即同步至外存，而是先放入位于內存的記錄暫存區(qū)，等待時機批量寫入，以減少I／O次數(shù)，從而提升系統(tǒng)性能。記錄由暫存區(qū)寫入外存的條件:一是每隔固定的時間間隔進行一次數(shù)據同步，二是暫存區(qū)數(shù)據量達到規(guī)定數(shù)目，滿足任意一個即可。

記錄從暫存區(qū)寫入外存過程如下:

（1）獲取待寫入數(shù)據的數(shù)據頁。計算最晚生成的即頁號最大的數(shù)據頁的長度，若超過規(guī)定的長度則創(chuàng)建新的數(shù)據頁，否則直接寫入到此數(shù)據頁中。

（2）更新數(shù)據頁的頭信息。取暫存區(qū)中最晚記錄的時間戳來更新頭信息的最晚時間。若頭信息中已有最早時間則無需更新，否則取暫存區(qū)最早記錄的時間戳來設定頭信息的最早時間。

（3）記錄排序。將暫存區(qū)的記錄與數(shù)據頁中原有的記錄混合，并按照編號與時間戳這2個字段進行升序排列。

（4）更新數(shù)據頁的頁目錄。遍歷排序后的記錄值，得出每個節(jié)點所對應的記錄的位置區(qū)間，最后生成新的頁目錄。

（5）將頭信息、頁目錄、有序記錄寫入數(shù)據頁，并在索引中更新此數(shù)據頁的頭信息。

（6）清空記錄暫存區(qū)。

2.3.2 數(shù)據訪問機制

各類外部系統(tǒng)通過網關服務層對數(shù)據進行訪問分為兩種情況:一是對于節(jié)點當前值的讀取，這種方式比較簡單直接依據OPCUA規(guī)范返回對應數(shù)據即可；另一種是對于節(jié)點在某段時間范圍內歷史數(shù)據的讀取，此時需要查詢RES以獲取數(shù)據。3個關鍵查詢信息分別為nodeId、開始時間、結束時間。詳細步驟如下，流程如圖5所示。

圖5 數(shù)據讀取流程Fig.5 Data reading process

（1）根據nodeId在哈希集合中查找到存放DataValue對象的數(shù)組。

（2）遍歷數(shù)組，若滿足查詢條件則返回對應數(shù)據，若不滿足則查找位于外存的記錄。

（3）根據開始時間與結束時間遍歷索引，得到滿足條件的若干個數(shù)據頁。

（4）逐一處理數(shù)據頁，由nodeId所對應的編號去查詢頁目錄定位并獲取數(shù)據。

（5）把此次在外存中查找到的數(shù)據放入內存對應的數(shù)組中。即“冷數(shù)據”升級為“熱數(shù)據”，提升下次查詢的速率。

（6）將在內存與外存中查找到的數(shù)據一并返回給客戶端。

3 方案測試

本文以染整車間中定型機為基礎搭建OPCUA網關，以對RES進行測試。定型機包含多個監(jiān)控單元，每個監(jiān)控單元監(jiān)控某項指標。如，烘房溫度、布面含潮率，同時也對應著OPCUA地址空間中的一個節(jié)點。網關采集層通過RS485接口從定型機的監(jiān)控單元獲取數(shù)據存入RES，網關服務層接收OPCUA客戶端的請求并返回相應數(shù)據。

網關的硬件平臺基于Raspberry Pi 3B，其CPU配置為64位1.2 GHz四核心，內存1 G、外存32 G。本文選取了以外存為存儲介質的關系型數(shù)據庫MySQL和以內存為存儲介質的鍵值對數(shù)據庫Redis作為RES的比較對象，來評測RES的各項性能指標。在MySQL中建立數(shù)據表存儲節(jié)點數(shù)據，具體字段信息見表3。為提升數(shù)據查詢的速率，在該表中以update＿time與node＿id字段建立了索引。

表3 MySQL數(shù)據表信息Tab.3 MySQL data table information

節(jié)點數(shù)據在Redis中以hash表的方式進行存儲，每一個OPCUA節(jié)點對應于Redis中的一個hash表，即Redis中的每一個hash表都以OPCUA節(jié)點的nodeId當做鍵值。在hash表中該節(jié)點數(shù)據以更新時刻的時間戳作為字段名稱，這一時刻節(jié)點的值當做與該字段對應的值，具體存儲結構如圖6所示。

圖6 Redis存儲結構Fig.6 Redis storage structure

為測試不同存儲方案下數(shù)據的寫入速率，本文隨機模擬定型機在運行時所產生的數(shù)據，以連續(xù)寫入1 000條數(shù)據為起始，步長為1 000，遞增到10 000條。每個量級寫入5次，并計算出平均寫入時間，具體結果如圖7所示。MySQL寫入數(shù)據所用時間最多，且隨著數(shù)據量的增大，所用時間的增幅也非常明顯；Redis與RES寫入速度較MySQL有明顯的提升，數(shù)據量增大時，所用時間的增幅趨于平緩；Redis的寫入速率略高于RES。在寫入時MySQL、Redis、RES這3種方案CPU的平均使用率為38%，32%，29%；內存平均使用率為35%，28%，27%。

圖7 不同方案寫入數(shù)據所用時間Fig.7 Data writing time of different schemes

對于數(shù)據讀取速度的測試，本文首先在MySQL、Redis、RES中分別存入10 000條記錄，并隨機讀取某個節(jié)點在某個時間段內的歷史數(shù)據。統(tǒng)計讀取100次，以100為步長遞增到1 000次不同方案所用的時間，具體結果如圖8所示。MySQL對于SQL語句有著很好的支持，一條簡單的SQL語句即可完成查詢，雖操作方便但速度并不理想；Redis對于數(shù)據的操作方式較少，且其內部并不會對數(shù)據按照時間排序，故只能采用遍歷的方式篩選出合格的記錄；RES在寫入時對數(shù)據建立了索引與頁目錄，并且數(shù)據全部按照時間順序排列，使其在查詢時無需遍歷，可以直接查找到所需記錄，大幅度提升了查詢效率。在查詢時MySQL、Redis、RES這3種方案CPU的平均使用率為30%，29%，28%；內存平均使用率為38%，45%，29%。

圖8 不同方案查詢數(shù)據所用時間Fig.8 Data query time of different schemes

在實際工業(yè)生產中數(shù)據量巨大，在千萬級別的數(shù)據量下RES仍有較好的表現(xiàn)。寫入性能方面，MySQL與RES寫入10 000 000條數(shù)據分別用時約30.91 h、2.24 h。由于網關硬件資源有限，內存只有1 GB，當Redis的數(shù)據寫入量達到60 000 000左右時，則已達到其容量瓶頸不能繼續(xù)操作。數(shù)據查詢方面，基于千萬級數(shù)據量隨機查詢100次MySQL、RES所用時間分別為9 282.89 s、1 722.16 s。

4 結束語

本文對網關中的數(shù)據存儲進行了研究，設計并實現(xiàn)了內存與外存協(xié)同的數(shù)據存儲系統(tǒng)，內存做數(shù)據緩存，外存做持久化存儲，兼顧了數(shù)據存儲容量與操作效率，在計算資源限的開發(fā)板上，相比傳統(tǒng)的數(shù)據庫MySQL與Redis有更好的性能表現(xiàn)。OPCUA網關解決了不同生產設備之間、生產設備與外部系統(tǒng)之間難以互聯(lián)互通的問題，對于OPCUA網關的進一步發(fā)展具有一定的參考意義。