基于對象模型的煤礦數據采集融合共享系統

尚偉棟， 王海力， 張曉霞， 王浩， 徐華龍

（1. 山西天地王坡煤業有限公司，山西 晉城 048021；2. 煤炭科學研究總院有限公司 礦山大數據研究院，北京 100013；3. 煤炭科學技術研究院有限公司，北京 100013）

0 引言

當前煤礦智能化發展尚處于初級階段[1]，其發展理念和技術體系還不夠成熟，“人、機、料、法、環”各個子系統通信協議、數據接口難以統一，數據難以融合，形成信息壁壘[2-4]。

數據采集、融合與共享是推動煤炭行業大數據技術發展的關鍵環節，有利于統一智能化煤礦的建設思路，眾多學者對此展開了研究。杜毅博等[5]提出了基于位號的煤礦數據編碼標準，便于后期處理過程中的數據關聯分析。韓安[6]提出了利用Kafka 消息隊列作為數據接入的協議，用Hadoop 作為數據存儲的載體；數據共享采用SDK 函數接口為應用提供數據訪問的方式。方乾等[7]提出了自動化系統采用EIP，Modbus，OPC，S7 協議采集數據，安全監測系統采用HTTP，WebSocket 等協議接入數據；關系型數據采用MySQL 存儲，非關系型數據采用HBase，InfluxDB 等存儲；數據共享采用WebService，Restful API，WebSocket 接口提供服務。

然而，隨著煤礦智能化建設推進，礦山對數據融合的數量和質量要求大幅度提高。目前，基于大數據平臺的數據融合系統在煤礦信息化發展過程中逐漸暴露出一定的局限性，主要表現如下。

1） 采用基于位號的煤礦數據編碼標準能對設備按照統一規則進行數字編碼，但編碼的使用是松散的，不是整體訪問的方式，更適合主數據管理場景使用，且對于查詢整個設備斷面數據的場景中，缺少設備對象化的標準。

2） 為了能夠采集各種類型設備數據，數據采集支持多種通信協議，但由于通信協議格式各異，直接按照采集的格式存儲數據，造成數據應用困難，大數據應用、分析數據需要多種語義解析才能實現相互理解。同時，數據采集規約實現大多基于Windows平臺實現，不能滿足煤炭行業基于Linux 內核國產化操作系統的要求。

3） 針對煤礦監控應用場景，從基于文件存儲的Hadoop 中獲取數據為監視界面提供實時刷新，但存儲方式為散點方式，不能滿足監視界面秒級數據刷新的要求。

4） 大部分基于互聯網思想建設的煤礦大數據平臺對歷史數據的存儲往往采用一種設備一張表模式，即為每一種設備設計一張表來存儲歷史數據，每一張表提供3 種接口（查詢、刪除、修改）訪問歷史數據。然而，由于煤礦設備種類繁多，該模式導致數據共享接口數量眾多，且對于數據的準確性和完整性缺少治理，導致數據共享效率低、效果差。

本文提出一種基于對象模型的煤礦數據采集融合共享系統，首先通過規約采集或其他采集方式接入數據，其次將松散數據經過對象化映射、數據治理后存儲到數據庫中，然后以對象方式提供共享接口，最后通過數據融合共享安全規范驗證及調用共享接口訪問數據，以實現煤礦數據高效采集、融合和共享。

1 系統架構

基于對象模型的煤礦數據采集融合共享系統架構如圖1 所示。設備層和感知層為系統提供數據源；數據接入層、數據融合層、數據共享層、應用層是系統的核心。

圖1 基于對象模型的煤礦數據采集融合共享系統架構Fig. 1 Architecture of coal mine data acquisition, fusion and sharing system based on object model

1） 數據接入層。該層通過各種協議接入感知層從設備層采集的多源異構數據，向數據融合層提供原始數據源。數據接入方式：① 規約采集。采用即插即拔的工業協議庫框架，支持常用的規約（如Modbus、S7、IEC101 和IEC104 等），可采集子系統（主要包括智能開采、智能掘進、智能主運、人員定位等系統）轉發的數據或直接采集設備（主要包括PLC、采集網關、邊緣終端等設備）的數據。② 其他采集。支持協議包括FTP、Restful API、視頻流、文本和消息隊列等，一般采集子系統（主要包括視頻監控、地質保障、手工填報、故障診斷、安全監測、三維可視化、圖像識別等系統）轉發的數據。

2） 數據融合層。該層首先對數據接入層的數據進行標準化處理，規約采集的數據按照設備對象模型進行映射，其他采集數據采用key-value 方式進行映射。其次，根據數據治理標準，對對象化數據進行治理。然后，將治理后的實時數據存儲到Redis 實時數據庫中。最后，將對象化數據進行歷史存儲，存儲方式分為2 種：① 規約對象方式。歷史數據存儲接口按照每個對象數據的采集周期從Redis 實時數據庫中遍歷及存儲對象數據。② key-value 對象方式。將數據接入到Kafka 消息隊列，通過Kafka 提供的組件直接存入MinIO 數據庫。

3） 數據共享層。該層提供實時數據共享、歷史數據共享和非結構數據共享3 種接口，為應用層提供數據服務。實時數據共享接口從分布式Redis 實時數據庫獲取數據，為應用層提供服務，由于實時監視對數據的訪問速度要求很高，需要秒級刷新界面，而很多設備數據在1 s 內基本變化不大，所以采用變化推送的方式向界面推送數據；歷史數據共享接口從ClickHouse 歷史數據庫獲取數據，為應用層提供Restful API 接口訪問服務；非結構數據共享接口從MinIO 數據庫中獲取數據，為應用層提供Restful API 接口訪問服務。根據數據融合共享規范安全要求，應用訪問需通過身份校驗才能登錄數據共享服務，通過權限校驗才能獲取具有授權的數據。

4） 應用層。該層是數據使用層，調用數據共享層提供的接口查詢數據進行使用。

2 系統關鍵技術

2.1 設備對象模型標準化

煤礦設備種類多，且每種設備生產廠家采用的工藝不同，導致設備參數存在不統一的現象[8-10]。雖然基于位號的煤礦數據編碼標準提供了設備和屬性點的命名規范，但缺少軟件層面的實現。為使設備能夠在軟件層面抽象表達，本文基于煤礦數據編碼標準設計設備對象模型，如圖2 所示。該模型可兼容設備參數之間的差異，具有可擴展性，靈活度高。

圖2 設備對象模型Fig. 2 Device object model

設備對象模型涵蓋公共信息和擴展信息。

1） 公共信息。用于定義煤礦設備的通用模型，包括基礎模型、通信模型、位置模型、屬性點模型：① 基礎模型包括設備的名稱、生產廠家、狀態、版本信息、銘牌參數等。② 通信模型包括設備聯網方式、網絡參數等。③ 位置模型包括位置描述、經度、緯度等。④ 屬性點模型包括類ID、屬性點ID、名稱、單位類型、數據類型、數據長度、讀寫標志等，其中類ID 和屬性點ID 是固定的。固定的類ID 有利于應用區分不同種類的設備，避免不同應用之間的語義轉換；在工程復制的場景中，由于屬性點ID 是固定的，復制源工程中的設備屬性生成目標工程中的設備屬性，不需要修改屬性點ID，減少工程開發工作量。

設備對象模型模版采用json 格式實現，描述如下：

其中，uuid 通過雪花算法自動生成，保證礦井設備的唯一性，避免設備識別錯誤，points 以數組的方式表示。

2） 擴展信息。因為不同廠家的設備除了具有公共信息模型的屬性外，還有一些個性化屬性，為保證設備對象模型的完整性，需將這些個性化屬性存放到擴展模型中。

2.2 數據接入

數據接入的方式分為工業規約采集、Restful API 問答式采集和文件數據采集。

1） 工業規約采集。煤炭行業部分廠家基于Windows 操作系統開發通信規約[10]，而近年煤炭行業規定要求使用基于Linux 內核的國產化操作系統，基于Windows 操作系統的通信規約采集不能運行在基于Linux 內核的操作系統中。本文采用跨操作系統的C++語言開發規約。工業規約采集實現關鍵技術：① 即插即拔機制。每一種規約封裝成動態庫，框架采用動態加載規約庫的方式實現即插即拔，由于每種操作系統的動態庫加載函數不一致，設計一個函數對描述操作系統的宏定義（如Windows 的宏定義為Win32）判斷，對不同的操作系統，調用對應的動態庫加載函數，實現動態庫的動態加載。② 報文解析。雖然每種工業規約都發布了標準，但設備廠家對不能滿足其要求的標準規約進行非標擴展，導致1 種規約產生多個變種。為兼容多個變種，標準部分定義基類，其他變種采用C++的繼承機制，繼承基類，重寫非標準部分的函數，為規約擴展提供了靈活的機制。③ 報文監視。上位機作為客戶端按照規約的規范從下位機采集數據，下位機作為服務端按照規約的規范為上位機提供數據轉發服務。當上位機和下位機規約通信出現數據不一致的問題后，需要查看報文才能快速排查錯誤。規約運行在基于Linux 內核的操作系統中，而報文監視工具為了方便查找問題，運行在Windows 操作系統中。雖然采用跨操作系統的C++語言實現報文解析， 但Windows 和Linux 存在字節存儲大小端的問題，如果不經過轉換，會導致數據不一致。為避免該錯誤，采用統一的網絡字節序進行數據交互。網絡字節序采用大端方式存儲數據，Windows 操作系統采用小端字節序存儲數據，需要調用函數將數據轉換成網絡字節序，而基于Linux 內核的操作系統采用大端字節序存儲數據，不需要轉換。工業規約采集框架如圖3 所示。

圖3 工業規約采集框架Fig. 3 Industrial protocol acquisition framework

2） Restful API 問答式采集。目前煤礦上位機采集下位機數據時，采用下位機向上位機post 的方式推送數據，其弊端是上位機不能快速定位數據傳輸異常原因是網絡中斷還是下位機程序崩潰。為避免該問題，采用“一問一答”方式，上位機調用Restful API 接口，周期查詢下位機數據，根據接口各響應狀態返回值（200，400，404，500 等）判斷通信異常情況。

3） 文件數據采集。圖片文件、地質保障文件、二進制文件（包括視頻流）等數據一般作為一個整體采集[10-12]，按照key-value 的方式存儲到MinIO 數據庫中。

2.3 數據融合

將接入的數據進行融合：首先對無序的數據進行設備對象模型映射，然后對模型化后的數據進行治理，最后對治理后的對象數據進行存儲。

2.3.1 設備對象模型映射

由于煤礦設備數量、種類眾多，數據類型多樣[13-14]，工業規約采集的數據不含描述信息，需要額外的信息來描述其語義[15-16]，導致數據的準確性、完整性、一致性和可靠性等方面存在問題，所以需要按照對象模型映射數據，確保融合后的數據按照標準化對象模型為數據應用提供服務。

通過規約采集的數據測點雜亂無章[17]，命名規范、數據內容、數據字典、數據格式不能在規約中體現，需要設計一個測點映射表。測點映射表包含源測點信息和目的映射信息：源測點信息包括規約的點號和數據長度；目的映射信息包括名字、映射的數據類型、數據長度、對象屬性ID 和單位。當數據標準化映射時，進程根據映射表的映射規則解析，將規約的點號映射到對象模型屬性點的點號中，同時，將采集值按照映射的目標類型和長度進行轉換，然后動態對轉換后的采集值進行對象化緩存，供下一步數據治理使用。

通過Restful API 采集的數據大多數是json 數據格式，這類數據帶有名稱、值等信息，但這些信息對于設備對象模型映射來說還不夠全面。需設計一個json 數據映射表，增加數據描述（包括名稱、數據類型、值、數據長度、單位），從而提供對象映射全量信息。當數據標準化映射時，進程根據映射表的映射規則解析，將源json 中key 和目標json 中key 匹配，將源json 中屬性值取出，按照映射的目標類型和長度進行轉換，寫入目標json 中屬性值，實現json 格式數據的對象化采集。

設備對象模型映射過程如圖4 所示。

圖4 設備對象模型映射過程Fig. 4 Device object model mapping process

2.3.2 數據治理

數據治理采用的方式主要包括公式計算和數據監視報警2 種。

1） 公式計算。煤礦采集的數據大多是原始數據，數據應用需要利用原始數據進行計算、統計、轉換等[18-21]。目前采用的方式是在數據使用時進行計算，但由于煤礦數據系統眾多、數據來源復雜、數據類型多樣，如果請求的數據量很大，會出現計算性能瓶頸問題，導致數據計算效率低。本文按照數據治理規則，在數據存儲之前對統一采集的數據進行公式計算和處理，提高數據的計算性能。公式計算的關鍵點是在規約解析后，在存儲之前對測點進行數學運算，主要包括加法、減法、乘法、除法等基本運算，以及開方、平方、取模等高級運算，還可對值進行取反計算。實現步驟：首先制定公式模板，其次將計算的采集點作為公式參數輸入到模板中，然后模板調用系統集成的Python math 數學庫，最后實現復雜的數學計算。采集的數據在存儲之前，按照配置的信息調用函數模板周期性執行計算，實現數據計算、統計、轉換的目的。

2） 數據監視報警。包括異常值和越限閾值報警：① 數據采集設備在長時間工作過程中可能出現異常值，此外由于網絡通信故障，不能保證采集數據的完整性。對異常、不完整的數據進行報警、刪除或更正，異常值不參與公式計算，確保最終結果可靠和準確[7]。② 設備運行參數受到約束條件的影響而不能超出一定范圍，如果測量參數超過了設定的極限值，需觸發越限報警信號，供用戶對設備工作狀態進行判斷。數據監視報警的步驟：先根據經驗配置數據異常值或越限閾值，采集的數據在存儲之前與閾值比較，如果超過閾值，產生相應的報警記錄并存到報警表中，為挖掘傳感器故障率和設備故障預警等分析提供數據支撐。

2.3.3 數據存儲

設備數據按照對象模型的方式存儲是指將采集的松散信息映射成對象模型后進行集中存儲，這是一種存儲海量數據的高速存儲方案，將設備多個參數1 次存儲，減少網絡訪問和數據存儲的操作次數，從而提高數據存儲效率，節省存儲空間。

數據存儲分為內存存儲和文件存儲，對于實時性要求高的監視類應用，將采集的數據存儲到內存數據庫中，將文件和視頻流（回放視頻）等實時性要求不高的數據存儲到基于文件的數據庫中。

1） 內存存儲。針對煤礦數據量大、處理速度快的需求，內存數據庫采用分布式部署的Redis。Redis分布式部署需要基于slot 計算存儲節點，采用CRC16 算法計算存儲節點，利用測點的key 對16 284取模，得到的結果就是對應的slot，調用Redis 分布式訪問接口Jedis，根據slot 位置把測點值存到Redis 庫中。采用Redis String 數據類型（key-value 方式）存儲設備對象化數據：對于測點的key，利用對象模型的優點，采用四維參數（即通道號、類ID、實例號、屬性點ID），同一通道的測點可分配到同一slot，提高數據訪問速度，滿足監控秒級數據刷新的要求；對于測點的value，則采用json 格式的對象數據。為提高存儲效率和節省存儲空間，動態變化的屬性點模型數據采用周期更新同一條記錄的方式，其他基礎模型、網絡模型、位置模型變化頻次較少，數據變化時才更新記錄。

2） 文件存儲。包括結構化數據和非結構化數據存儲：① 結構化數據一般存儲在ClickHouse 中，ClickHouse 采用分布式部署。針對煤礦數據規模大的需求，通常采用分表（即按照每日或每月一張表）的方式來存儲數據，對于跨年、跨月的數據查詢需要查詢多張表，效率非常低；此外，按照互聯網的方式，為每一種設備設計一張表存儲數據，導致數據庫表數量眾多，為數據使用帶來麻煩。為避免該情況，所有的對象數據用一張表存儲，這得益于ClickHouse分布式表具有分布式存儲數據的功能。需制定分布式存儲策略，采用對象模型設備ID 對ClickHouse 節點數取模的方法計算存儲節點，將對象存儲到相應的節點中。② 非結構化數據一般是文本文件、視頻流、二進制文件，采用MinIO 數據庫以整體方式存儲此類數據。MinIO 通過Kafka 接入流式數據，按照key-value 對象化方式存儲，采用分布式存儲和訪問的策略，提高數據存儲和訪問性能。

2.4 數據共享接口

系統提供對象化的數據共享接口，為應用層應用提供數據服務。鑒于非結構化的MinIO 數據共享接口直接通過key-value 方式訪問，比較簡單，所以本文重點介紹實時數據共享接口和歷史數據共享接口關鍵技術。

如果采用一種設備一張表存儲數據的方式[20]，由于煤礦設備種類多，數據服務接口至少有200 個，數據應用訪問與之匹配的接口也很多，給數據使用者增加了工作量。由于本文所有的對象數據存儲是基于一張表，所以對象化的數據共享接口可簡化到實時數據共享接口和歷史數據共享接口。

1） 實時數據共享接口。輸入參數為設備ID 數組。首先根據設備ID 進行權限校驗，如果通過權限校驗，對16 284 取模獲取數據存儲的slot，然后按照slot 查找到對應的Redis 節點，接著遍歷該節點的key 獲取value（對象化數據），最后返回對象化數據數組。如果設備數據不存在，用NULL 表示空值返回；如果沒有通過權限校驗，返回“沒有權限，獲取數據錯誤”。另外，對于實時性要求高的場景，采用Web Socket 服務端向客戶端推送數據的方式，減少客戶端和服務端的網絡通信時間，提高數據訪問性能。

2） 歷史數據共享接口。輸入參數為設備ID 數組、開始時間、結束時間。首先根據設備ID 進行權限校驗，如果通過權限校驗，對ClickHouse 節點數取模，然后根據取模結果得到存儲節點，接著結合輸入時間等條件查詢歷史數據，最后返回對象化數據數組。如果設備數據不存在，用NULL 表示空值返回。

對象化的數據共享接口具有查詢效率高的特點，僅需通過1 次查詢，即可將整個設備屬性數據以對象方式存儲到緩存中，再按照請求的屬性點從對象模型中抽取解析返回需要的數據，解決了松散式數據共享接口需多次查詢導致耗時長的問題。

3 系統應用

基于對象模型的煤礦數據采集融合共享系統目前在山西天地王坡煤業有限公司進行了工程實踐。在設計階段對全礦井設備進行了對象模型規劃，形成了全礦井的設備對象模型，實現了對象模型標準化建設，解決了數據采集和數據共享以對象模型交互的標準問題，顯著降低了數據使用過程中語義解析的難度。

通過工業規約對綜采工作面、綜掘工作面、主運輸系統、排水系統、通風系統、供電系統、智能污水處理系統、智能壓風系統、鐵路智能裝車系統和汽車智能裝運系統的設備進行數據采集，通過Restful API 方式對安全監測設備進行數據采集，通過私有協議對人員定位系統的設備和人員進行數據采集，通過二進制流式方式對視頻進行數據采集，并按照對象模型的映射標準，將各種設備數據以對象化方式進行融合和存儲，為智能化業務場景的指標分析、能耗計算、故障診斷、實時監視等提供對象化共享接口，為大數據分析提供保障。

目前煤礦數據采集融合共享系統接入2 000 多個生產設備，每日產生上億條生產數據，在設備對象模型管理和數據計算、統計、轉換等方面取得顯著效果。

在硬件配置和運行環境相同的條件下，收集現場應用過程數據進行如下對比測試。

1） 重復進行數據計算，數據存儲前和數據使用時計算性能對比見表1?？煽闯鰯祿鎯η坝嬎惚葦祿褂脮r計算的準確率稍有提高，且計算速率提高了4 倍。

表1 數據計算性能對比Table 1 Comparison of data calculation performance

2） 重復進行數據存儲，松散數據和對象數據存儲性能對比見表2?？煽闯鰧ο髷祿鎯λ俾时人缮祿鎯λ俾视酗@著提升，在Redis 數據庫中提升了9 倍，在ClickHouse 中提升了49 倍。

表2 數據存儲性能對比Table 2 Comparison of data storage performance

3） 重復進行全礦井數據查詢，松散數據和對象數據查詢性能對比見表3?？煽闯鰧ο髷祿樵兯俾时人缮祿樵兯俾视写蠓忍嵘?，在Redis 數據庫中提高了3 倍，在ClickHouse 中提升了9 倍。

表3 數據查詢性能對比Table 3 Comparison of data query performance

4 結論

1） 基于煤礦數據編碼標準設計設備對象模型，包括基礎模型、通信模型、位置模型、屬性點模型、擴展模型，可兼容設備參數之間的差異，具有可擴展性強、靈活度高的優點。

2） 利用跨操作系統的工業規約和Restful API 問答式接口，實現了設備數據接入，滿足煤礦操作系統國產化的發展趨勢，解決了采用post 方式采集數據不能判斷數據傳輸過程中異常情況的弊端。

3） 采集的數據經過設備對象模型映射、數據治理和數據存儲后，實現了數據融合。通過無序的數據標準化，解決了數據語義不統一的問題；通過數據治理，保證了數據的可靠性、準確性；通過設備數據對象化的存儲，提高了存儲效率，節省了存儲空間。

4） 對象化的數據共享接口可簡化為實時數據和歷史數據共享接口，通過1 次查詢整個對象數據，從中提取所需的屬性點，顯著提高了數據訪問性能。