秦 磊 林希佳 周 軒 郭 磊 王 路 吳成慶 王 娜

（江蘇金陵智造研究院有限公司，江蘇 南京 210001）

近年來，隨著信息化水平的不斷提升，不同類型的智能設備已經(jīng)廣泛應用于智能制造領域、智慧園區(qū)領域中，企業(yè)管理者對這兩大領域內(nèi)現(xiàn)場狀況的掌控要求越來越高。尤其是隨著工業(yè)互聯(lián)網(wǎng)、大數(shù)據(jù)及物聯(lián)網(wǎng)的蓬勃發(fā)展，迫切要求生產(chǎn)車間、工業(yè)園區(qū)提升信息化管理水平，為管理者掌控現(xiàn)場綜合情況提供助益。以工業(yè)園區(qū)為例，園區(qū)內(nèi)設備種類較多，但缺乏人與物、物與物間的智能聯(lián)動，且分散在各個地方，缺乏有效的狀態(tài)數(shù)據(jù)采集渠道，用戶無法直接與園區(qū)進行交互，缺乏有效的用戶體驗反饋渠道。對于工業(yè)園區(qū)行業(yè)的管理者來說，如何快速定位設備位置，如何查看設備使用情況，設備故障后如何快速定位設備故障點從而第一時間進行維修等，這些問題的深入研究及解決方法都需要以從設備采集大量實時數(shù)據(jù)為基礎。

工業(yè)園區(qū)現(xiàn)場，一般都會有來自不同廠商品牌的設備，且設備類型多元化，例如有各類傳感器、攝像頭、巡檢小車等等，通信方式各不相同，各種因素給園區(qū)信息化之路帶來不小的阻力。

針對這一現(xiàn)狀，本文研究探討一種多源設備大數(shù)據(jù)量實時數(shù)據(jù)采集存儲的方法。該方法結(jié)合我司項目實際情況開展，借助于互聯(lián)網(wǎng)，實現(xiàn)物聯(lián)網(wǎng)平臺與數(shù)千臺設備間的通信，設備大多數(shù)為模具狀態(tài)監(jiān)控設備，另含一部分傳感器、攝像頭及小車，遠程采集設備的相關坐標位置、耗電量、故障信息等數(shù)據(jù)，并實現(xiàn)數(shù)據(jù)的實時穩(wěn)定存儲，為后續(xù)借助互聯(lián)網(wǎng)平臺實現(xiàn)大數(shù)據(jù)分析提供數(shù)據(jù)支撐。

1 物聯(lián)網(wǎng)平臺數(shù)據(jù)采集方式

物聯(lián)網(wǎng)平臺類型繁多，主要包括以下四類：第一類是提供連接性管理的物聯(lián)網(wǎng)平臺；第二類是以提供云服務為主的應用開發(fā)平臺；第三類是以接入智能裝置為主的應用開發(fā)平臺；第四類是以大數(shù)據(jù)分析和機器學習為主的物聯(lián)網(wǎng)平臺?；诒疚难芯康膶嶋H情況，以第三類物聯(lián)網(wǎng)平臺為依托，接入多源設備進行實時采集存儲，為大數(shù)據(jù)分析提供數(shù)據(jù)支撐。數(shù)據(jù)采集方式主要分為以下兩類。

1.1 間接接入?，F(xiàn)場設備種類較多時，使用工業(yè)數(shù)據(jù)采集網(wǎng)關將設備按適配協(xié)議接入，網(wǎng)關使用Mqtt 服務進行數(shù)據(jù)傳輸，物聯(lián)網(wǎng)平臺端啟用Mqtt 服務端組件讀取網(wǎng)關傳輸?shù)臄?shù)據(jù)，數(shù)據(jù)流如圖1 所示。

圖1 間接接入方式

1.2 直接接入。直接接入方法使用現(xiàn)場設備通訊協(xié)議比較簡單且單一的情況，現(xiàn)場設備與物聯(lián)網(wǎng)平臺通過網(wǎng)線連接，以以太網(wǎng)方式傳輸數(shù)據(jù)至平臺端，平臺端開啟通信協(xié)議服務組件接收設備傳遞的數(shù)據(jù)，并利用Kafka 進行數(shù)據(jù)接收處理，數(shù)據(jù)流如圖2 所示。

圖2 直接接入方式

2 數(shù)據(jù)采集內(nèi)容與要求

2.1 數(shù)據(jù)實時性、準確性、穩(wěn)定性及安全性

對于實時采集的數(shù)據(jù)，以1s 的采集周期采集所需數(shù)據(jù)。對于更新速率較慢的數(shù)據(jù)，例如設備耗電量等數(shù)據(jù)，可采用15min的采集周期。

采集的數(shù)據(jù)確保與實際狀態(tài)數(shù)據(jù)一一對應，保證傳輸數(shù)據(jù)的準確性；穩(wěn)定性方面，采集的數(shù)據(jù)日丟失率不高于0.1%；安全性方面，通過鏈路加密協(xié)議等確保數(shù)據(jù)的安全。

2.2 采集的數(shù)據(jù)內(nèi)容

多類型設備數(shù)據(jù)采集，主要采集的設備類型如下所述：

2.2.1 國標/非國標攝像頭；

2.2.2 傳感器，例如溫濕度、壓力傳感器等；

2.2.3 其他類型設備，例如巡檢小車、模具狀態(tài)監(jiān)控設備等。

2.3 數(shù)據(jù)存儲要求及方式

支持PB 級以上數(shù)據(jù)存儲，可使用非關系型數(shù)據(jù)庫進行設備實時消息存儲，該類數(shù)據(jù)庫且支持行列混合存儲。

3 數(shù)據(jù)采集架構設計

為滿足大數(shù)據(jù)實時采集、存儲，本文使用一種響應式編程框架，提升數(shù)據(jù)采集性能，具體技術架構如圖3 所示。采集到的數(shù)據(jù)通過網(wǎng)關進行接收、推送、實時處理，最終存儲至數(shù)據(jù)庫中，數(shù)據(jù)庫采用redis+Elasticsearch+mysql 相結(jié)合的方式進行。

圖3 技術架構圖

3.1 Project Reactor 技術簡介

Project Reactor 是一個運行在JVM上的反應式編程基礎庫，以“背壓”的形式管理數(shù)據(jù)處理，提供了可組合的異步序列API Flux 和Mono。Reactor 大大降低了異步編碼難度，Reactor 反應庫擁有如下特點：

3.1.1 可組合性和可讀性；

3.1.2 以流的形式進行數(shù)據(jù)處理，為流中每個節(jié)點提供了豐富的操作性；

3.1.3 在Subscribe 之前，不會有任何事情發(fā)生；

3.1.4 支持背壓，消費者可以向生產(chǎn)者發(fā)出信號表面排放率過高；

3.1.5 支持兩種反應序列：hot 和cold。

3.2 數(shù)據(jù)采集框架設計

多源化設備接入及大數(shù)據(jù)量設備消息實時采集、存儲是本課題實現(xiàn)的核心，業(yè)務框架如圖4 所示。

圖4 業(yè)務架構設計圖

使用網(wǎng)絡組件管理各種網(wǎng)絡服務（MQTT、TCP 等），只負責接收/發(fā)送報文，不處理邏輯；使用接口協(xié)議進行自定義消息解析，處理報文數(shù)據(jù)；使用設備網(wǎng)關將設備接入，并將設備消息推送至事件總線；使用事件總線進行進程內(nèi)的數(shù)據(jù)轉(zhuǎn)發(fā)，可將數(shù)據(jù)轉(zhuǎn)發(fā)至數(shù)據(jù)庫或進行微信等消息推送。

3.3 自定義接口協(xié)議開發(fā)設計

協(xié)議主要由認證器（Authenticator）、消息編解碼器（DeviceMessageCodec）、消息發(fā)送攔截器（DeviceMessageSenderInt erceptor）組成。

3.3.1 認證器

不同網(wǎng)絡協(xié)議使用不同認證器，主要用于設備認證，接口定義如圖5 所示。

圖5 認證器接口設計

3.3.2 消息編解碼器

設備網(wǎng)關從網(wǎng)絡組件中接收到報文后，會調(diào)用對應協(xié)議包的消息編解碼器進行處理，接口定義如圖6 所示。

圖6 編解碼器接口設計

3.3.3 消息發(fā)送攔截器

使用攔截器攔截消息發(fā)送和返回的動作，通過修改參數(shù)等操作實現(xiàn)自定義邏輯，如：當設備離線時，將消息緩存到設備配置中，等設備上線時再重發(fā)，如圖7 所示。

圖7 消息發(fā)送攔截器接口設計

3.4 ReactorQL 實時數(shù)據(jù)處理

本課題利用一套使用SQL 進行實時數(shù)據(jù)處理的工具包，通過將SQL 翻譯為reactor 來進行數(shù)據(jù)處理，主要應用場景包括處理實時數(shù)據(jù)、聚合計算實時數(shù)據(jù)及跨數(shù)據(jù)源聯(lián)合數(shù)據(jù)處理。

例如，處理多個型號的設備數(shù)據(jù)，如圖8 所示。

圖8 數(shù)據(jù)處理

3.5 數(shù)據(jù)庫設計

本課題使用關系型及非關系型數(shù)據(jù)庫結(jié)合的方式進行實時大數(shù)據(jù)采集存儲，其中關系型數(shù)據(jù)庫MySQL 中存儲設備基礎信息，非關系型數(shù)據(jù)庫Elasticsearch 存儲設備消息，緩存及熱點數(shù)據(jù)存儲于redis。

3.5.1 MySQL 數(shù)據(jù)庫設計

其中設備實例信息存儲在dev_device_instance，設備產(chǎn)品存儲在dev_product， 協(xié)議存儲在dev_protocal，設備網(wǎng)關存儲在device_gateway，網(wǎng)絡組件配置存儲在network_config。

3.5.2 Elasticsearch 數(shù)據(jù)庫設計

本課題提供兩種Elasticsearch 存儲方案，默認使用行式存儲方案。

方案一：使用elasticsearch 行式存儲方案存儲設備數(shù)據(jù)，設備每一個屬性值都保存為一條索引記錄，其典型應用場景是設備每次只會上報一部分屬性，同時支持讀取部分屬性數(shù)據(jù)的時候，優(yōu)點在于幾乎滿足任意場景下的屬性數(shù)據(jù)存儲，缺點在于設備屬性個數(shù)較多時，數(shù)據(jù)量指數(shù)增長，可能會影響性能。

方案二：使用elasticsearch 列式存儲方案存儲設備數(shù)據(jù)，一個屬性作為一列，一條屬性消息作為一條索引記錄進行存儲，適合設備每次都上報所有的屬性值的場景，優(yōu)點是在屬性個數(shù)較多，且設備每次都會上報全部屬性時，系統(tǒng)性能更高，缺點是設備必須上報全部屬性。

4 設備數(shù)據(jù)采集管理

本課題接入多源設備，采集各類型設備數(shù)據(jù)，并監(jiān)控設備接入量對系統(tǒng)性能的影響以及內(nèi)存消耗情況。

4.1 測試準備

通過使用兩個本地Linux 虛擬機，一個作為服務端，另一個作為壓力測試客戶端，服務器選用ThinkSystem ST558，64G 內(nèi)存；服務器虛擬機：6 核30G 內(nèi)存，centOS；客戶端虛擬機：4 核10G 內(nèi)存，centOS；初始數(shù)據(jù)：200W 設備實例，使用模具狀態(tài)監(jiān)控設備作為物模型，進行設備連接數(shù)以及設備消息處理速度壓力測試。

4.2 測試結(jié)果

4.2.1 10W 設備連接，1000 并發(fā)請求連接，總計10W 連接，第一次CPU 平均使用率44%，JVM內(nèi)存4.58G；第二次CPU 平均使用率72%，JVM內(nèi)存4.89G；

4.2.2 30W 設備連接，1000 并發(fā)請求連接，總計30W 連接，第一次CPU 平均使用率64%，JVM內(nèi)存5.42G，第二次CPU 平均使用率78%，JVM內(nèi)存4.99G；

4.2.3 50W 設備連接，1000 并發(fā)請求連接，總計50W 連接，第一次CPU 平均使用率59%，JVM內(nèi)存5.46G，第二次CPU 平均使用率83%，JVM內(nèi)存7.92G。

5 模具狀態(tài)監(jiān)控設備接入管理

設備接入流程如圖9 所示，本文以模具狀態(tài)監(jiān)控設備為例，描述其接入流程。

5.1 協(xié)議開發(fā)

模具狀態(tài)監(jiān)控設備使用TCP 協(xié)議進行數(shù)據(jù)傳輸，因此針對TCP 報文類型進行自定義解析協(xié)議開發(fā)，解析完成打成jar 包導入平臺端，創(chuàng)建產(chǎn)品基本信息即可完成數(shù)據(jù)展示，部分核心代碼如圖10 所示。

5.2 數(shù)據(jù)展示

模具狀態(tài)監(jiān)控設備根據(jù)TCP 協(xié)議報文創(chuàng)建對應的實例信息并進行數(shù)據(jù)展示，如圖11 所示。

圖11 模具狀態(tài)監(jiān)控設備

6 結(jié)論

本文為滿足多類型、大數(shù)據(jù)量設備數(shù)據(jù)采集存儲，設計并實現(xiàn)了一套大數(shù)據(jù)采集的架構，在進行數(shù)據(jù)采集的基礎上增加了可行的緩存機制，實現(xiàn)了大數(shù)據(jù)實時監(jiān)控以及設備數(shù)據(jù)穩(wěn)定存儲的功能，為智能智造領域及智慧園區(qū)相關大數(shù)據(jù)分析和設備監(jiān)控提供了重要的數(shù)據(jù)依據(jù)，也為以后的信息化建設鋪平了道路。