基于智慧礦山平臺(tái)的人員定位系統(tǒng)關(guān)鍵技術(shù)

胡宏澤，杜志剛，儲(chǔ) 楠，羅 克

（1.中煤科工集團(tuán)常州研究院有限公司，江蘇常州 213015；2.天地（常州）自動(dòng)化股份有限公司，江蘇常州 213015）

當(dāng)今社會(huì)正處于數(shù)字化礦山向智慧礦山發(fā)展的重要過渡階段[1-3]，智慧礦山平臺(tái)的建設(shè)要求包括人員定位系統(tǒng)在內(nèi)的多異構(gòu)系統(tǒng)之間能夠?qū)崿F(xiàn)多元數(shù)據(jù)融合和信息共享，特別強(qiáng)調(diào)了在緊急情況下的多系統(tǒng)之間的應(yīng)急處理、預(yù)警和告警能力[4-7]。

現(xiàn)有的人員定位系統(tǒng)所采用的設(shè)計(jì)框架，業(yè)務(wù)模塊大多集成在統(tǒng)一的項(xiàng)目框架中，同時(shí)為了實(shí)現(xiàn)數(shù)據(jù)共享和同步，各個(gè)模塊之間的耦合性極強(qiáng)，任一業(yè)務(wù)功能的擴(kuò)展往往會(huì)“牽一發(fā)而動(dòng)全身”[8]。隨著業(yè)務(wù)邏輯的不斷深化和復(fù)雜化，項(xiàng)目規(guī)模會(huì)變得非常龐大，使得維護(hù)成本越來(lái)越高。通過對(duì)智慧礦山進(jìn)行調(diào)研后發(fā)現(xiàn)，在我國(guó)大部分煤礦的人員定位系統(tǒng)中數(shù)據(jù)處理能力依然不足，特別對(duì)于人員實(shí)時(shí)軌跡、歷史軌跡的信息顯示依然存在著反應(yīng)慢的問題，同時(shí)系統(tǒng)主數(shù)據(jù)結(jié)構(gòu)仍然束縛在本系統(tǒng)之內(nèi)，智慧礦山平臺(tái)中其他系統(tǒng)若想調(diào)用本系統(tǒng)的數(shù)據(jù)往往需要進(jìn)行二次設(shè)備部署和開發(fā)，這無(wú)疑對(duì)平臺(tái)實(shí)現(xiàn)多系統(tǒng)的融合造成了極大的困難[9]。為此，通過對(duì)現(xiàn)有的人員定位系統(tǒng)存在的問題進(jìn)行分析，提出了一種基于微服務(wù)架構(gòu)的設(shè)計(jì)方案，引入時(shí)序數(shù)據(jù)庫(kù)[10]和系統(tǒng)軟總線結(jié)構(gòu)，實(shí)現(xiàn)業(yè)務(wù)層級(jí)和系統(tǒng)層級(jí)間的輕量級(jí)通信機(jī)制，極大提高了人員定位系統(tǒng)在智慧礦山平臺(tái)中的可擴(kuò)展性和可移植性。

1 現(xiàn)有的人員定位系統(tǒng)架構(gòu)

現(xiàn)有的人員定位系統(tǒng)中業(yè)務(wù)一般采用集中式管理，系統(tǒng)維護(hù)著一個(gè)統(tǒng)一的關(guān)系型數(shù)據(jù)庫(kù)，各個(gè)業(yè)務(wù)模塊之間的數(shù)據(jù)交互都是以這個(gè)數(shù)據(jù)庫(kù)為中心進(jìn)行?，F(xiàn)有的人員定位系統(tǒng)架構(gòu)如圖1。現(xiàn)有的人員定位系統(tǒng)主要存在以下幾個(gè)問題：1）業(yè)務(wù)之間耦合性強(qiáng)，可擴(kuò)展性差。因?yàn)椴捎梅忾]式的系統(tǒng)架構(gòu)，所有業(yè)務(wù)大多固化在一個(gè)復(fù)雜的單體應(yīng)用中，隨著業(yè)務(wù)需求的不斷增加和處理邏輯的不斷深化，項(xiàng)目中的代碼的耦合度會(huì)越來(lái)越嚴(yán)重，每一個(gè)功能的開發(fā)都需要開發(fā)人員理清相關(guān)業(yè)務(wù)之間的邏輯關(guān)系，甚至極大可能會(huì)產(chǎn)生重復(fù)開發(fā)工作，這將使得系統(tǒng)的水平擴(kuò)展性難以滿足要求。

圖1 現(xiàn)有的人員定位系統(tǒng)架構(gòu)Fig.1 System architecture of current personnel positioning platform

2）無(wú)法彈性部署，難以維護(hù)。因?yàn)槊旱V企業(yè)的業(yè)務(wù)需求往往千差萬(wàn)別，所以開發(fā)人員需要針對(duì)不同的煤礦企業(yè)的業(yè)務(wù)需求對(duì)人員定位系統(tǒng)進(jìn)行私有化定制，這就導(dǎo)致同一個(gè)人員定位系統(tǒng)會(huì)存在非常多的系統(tǒng)版本，開發(fā)人員需要花費(fèi)大量的精力進(jìn)行版本控制，而且每一個(gè)功能模塊的更改，都需要對(duì)整個(gè)項(xiàng)目重新打包、編譯和部署，維護(hù)工作變得極其復(fù)雜。

3）數(shù)據(jù)庫(kù)成為系統(tǒng)運(yùn)行效率的瓶頸。系統(tǒng)中所有業(yè)務(wù)訪問同一個(gè)關(guān)系數(shù)據(jù)庫(kù)，每一個(gè)業(yè)務(wù)的處理能力都受到了數(shù)據(jù)庫(kù)承載能力的制約。隨著智能礦山平臺(tái)的推進(jìn)，現(xiàn)有的數(shù)據(jù)庫(kù)結(jié)構(gòu)顯然已經(jīng)成為制約著系統(tǒng)數(shù)據(jù)處理能力的關(guān)鍵因素。

4）多系統(tǒng)數(shù)據(jù)共享、融合能力差。外部系統(tǒng)對(duì)本系統(tǒng)訪問的數(shù)據(jù)大多來(lái)自公共數(shù)據(jù)和實(shí)時(shí)數(shù)據(jù)，針對(duì)不同的數(shù)據(jù)訪問需求，系統(tǒng)需要對(duì)現(xiàn)有數(shù)據(jù)進(jìn)行結(jié)構(gòu)化處理，往往會(huì)牽扯到過多的業(yè)務(wù)邏輯。

2 基于微服務(wù)架構(gòu)的系統(tǒng)設(shè)計(jì)方案

2.1 微服務(wù)

微服務(wù)架構(gòu)的核心思想是將一個(gè)復(fù)雜的單體應(yīng)用，按照業(yè)務(wù)邏輯和使用頻次拆分為多個(gè)公共服務(wù)和私有業(yè)務(wù)服務(wù)，每個(gè)服務(wù)之間都是松耦合的，可以獨(dú)立部署，最終達(dá)到徹底的組件化、服務(wù)化和去中心化[11-12]。

因?yàn)闃I(yè)務(wù)按照微服務(wù)進(jìn)行分散管理，所以開發(fā)人員在開發(fā)私有業(yè)務(wù)過程中，可以快速訪問系統(tǒng)公共資源，無(wú)需考慮其他業(yè)務(wù)的影響，不僅減少了大量重復(fù)性工作，而且開發(fā)過程變得更為規(guī)范。同時(shí)，每一個(gè)服務(wù)都具備強(qiáng)大的水平擴(kuò)展能力，針對(duì)不同煤礦企業(yè)的私有化定制需求，開發(fā)人員不僅可以對(duì)系統(tǒng)中的服務(wù)進(jìn)行動(dòng)態(tài)裁剪，而且還可以對(duì)每個(gè)微服務(wù)單獨(dú)進(jìn)行升級(jí)和部署，使得維護(hù)難度大大降低。

2.2 系統(tǒng)架構(gòu)

針對(duì)現(xiàn)有的人員定位系統(tǒng)水平擴(kuò)展性差、維護(hù)困難且無(wú)法滿足智慧礦山平臺(tái)對(duì)多異構(gòu)系統(tǒng)間的數(shù)據(jù)融合和共享的需求的情況，從主流的微服務(wù)架構(gòu)設(shè)計(jì)思想作為出發(fā)點(diǎn)，提出了一種基于微服務(wù)架構(gòu)的人員定位系統(tǒng)設(shè)計(jì)方案。系統(tǒng)架構(gòu)主要分為主引擎、硬件層、數(shù)據(jù)驅(qū)動(dòng)層、軟總線、服務(wù)層、接口層和交互層。

1）主引擎。主引擎是一個(gè)輕量級(jí)的應(yīng)用服務(wù)引擎，主要提供公共服務(wù)、數(shù)據(jù)存儲(chǔ)服務(wù)、部署管理和服務(wù)管理的功能。公共服務(wù)包括系統(tǒng)日志、權(quán)限管理、文件同步等系統(tǒng)公共業(yè)務(wù)；數(shù)據(jù)存儲(chǔ)提供統(tǒng)一的數(shù)據(jù)庫(kù)訪問規(guī)范；部署管理提供平臺(tái)無(wú)關(guān)性、一鍵化和自動(dòng)化部署的支持；服務(wù)管理實(shí)現(xiàn)對(duì)服務(wù)的控制和服務(wù)間的數(shù)據(jù)共享。

2）硬件層。硬件層主要包括定位基站、網(wǎng)關(guān)、定位卡、接收器等設(shè)備。

3）數(shù)據(jù)驅(qū)動(dòng)層。數(shù)據(jù)驅(qū)動(dòng)層實(shí)現(xiàn)數(shù)據(jù)采集、數(shù)據(jù)接入、數(shù)據(jù)優(yōu)化算法和控制命令解析的功能。數(shù)據(jù)采集就是根據(jù)不同的通信協(xié)議（Modbus-RTU、TCP/UDP等）將采集的信息進(jìn)行解析和接收；數(shù)據(jù)接入是將接收的數(shù)據(jù)進(jìn)行拆解，并且按照統(tǒng)一數(shù)據(jù)規(guī)范寫入軟總線中；數(shù)據(jù)優(yōu)化算法主要提供高精度的定位算法和數(shù)據(jù)壓縮算法等；控制命令解析負(fù)責(zé)將接收到的命令信息解析成硬件設(shè)備能夠識(shí)別的命令字段，并且下發(fā)到硬件層。

4）軟總線。軟總線提供了數(shù)據(jù)訪問、數(shù)據(jù)緩存、數(shù)據(jù)融合以及控制命令通道的功能。數(shù)據(jù)訪問提供統(tǒng)一的數(shù)據(jù)訪問接口，規(guī)范化數(shù)據(jù)訪問格式。數(shù)據(jù)融合是將系統(tǒng)中重用性和共享性高的數(shù)據(jù)進(jìn)行結(jié)構(gòu)化統(tǒng)一構(gòu)建；數(shù)據(jù)緩存存儲(chǔ)公共數(shù)據(jù)、實(shí)時(shí)數(shù)據(jù)以及數(shù)據(jù)融合的結(jié)構(gòu)化數(shù)據(jù)，并且按照統(tǒng)一的存儲(chǔ)規(guī)范將數(shù)據(jù)存儲(chǔ)到數(shù)據(jù)庫(kù)；控制指令通道用于提供低延時(shí)、獨(dú)立的指令傳送機(jī)制。

5）服務(wù)層。服務(wù)層以微服務(wù)的方式加載和運(yùn)行各個(gè)私有業(yè)務(wù)，例如唯一性檢測(cè)、位置服務(wù)、井口大屏、GIS 服務(wù)、多系統(tǒng)融合、考勤管理和聯(lián)網(wǎng)上傳等私有模塊。各個(gè)微服務(wù)之間是水平排列關(guān)系，開發(fā)人員在開發(fā)過程中，不僅可以從主引擎獲取公共服務(wù)接口，而且還可以從軟總線獲取公共數(shù)據(jù)、實(shí)時(shí)數(shù)據(jù)以及數(shù)據(jù)融合的結(jié)構(gòu)化數(shù)據(jù)，無(wú)需關(guān)心下層和數(shù)據(jù)庫(kù)的具體實(shí)現(xiàn)細(xì)節(jié)，大大減少了重復(fù)性工作。同時(shí)，各個(gè)私有服務(wù)可在托管平臺(tái)中，以Docker 鏡像方式獨(dú)立部署，實(shí)現(xiàn)服務(wù)之間的松耦合。

6）接口層。接口層主要包括公有業(yè)務(wù)的接口、私有業(yè)務(wù)的接口和多系統(tǒng)融合接口，為交互層提供了各類功能的WebAPI 接口和gRPC。其中公有業(yè)務(wù)接口由主引擎提供，私有業(yè)務(wù)接口由服務(wù)層各個(gè)私有服務(wù)提供，多系統(tǒng)融合接口由系統(tǒng)融合服務(wù)提供。

7）交互層。交互層包括移動(dòng)端、PC 端和融合平臺(tái)的用戶交互?？刹捎们昂蠖朔蛛x的開發(fā)技術(shù)[13]，利用主流的Angular、Vue 等框架，最終實(shí)現(xiàn)一次開發(fā)，多平臺(tái)運(yùn)行，極大提高了開發(fā)人員的開發(fā)效率。

2.3 系統(tǒng)部署

在微服務(wù)的架構(gòu)中，開發(fā)人員可將自己開發(fā)的業(yè)務(wù)、運(yùn)行環(huán)境以及依賴包打包成Docker 鏡像文件，系統(tǒng)中所有已經(jīng)開發(fā)完成的業(yè)務(wù)則可以鏡像文件的形式存放在鏡像倉(cāng)庫(kù)中。微服務(wù)是基于云原生的技術(shù)，具備快捷的云端部署能力。因此不僅可在本地服務(wù)器上通過拷貝等方式獲取全部的鏡像文件，也可在云端的托管平臺(tái)中通過Docker 命令的方式從鏡像倉(cāng)庫(kù)中拉取所需的鏡像文件。系統(tǒng)部署流程如圖2。

圖2 系統(tǒng)部署流程圖Fig.2 System deployment process

開發(fā)人員在部署的過程中，可根據(jù)拉取的鏡像文件創(chuàng)建和啟動(dòng)Docker 容器作為服務(wù)運(yùn)行的載體。系統(tǒng)在啟動(dòng)時(shí)，首先運(yùn)行系統(tǒng)框架中的主引擎模塊，其中公共服務(wù)、數(shù)據(jù)存儲(chǔ)服務(wù)等平臺(tái)支撐的功能模塊已經(jīng)固化在了主引擎中；接著主數(shù)據(jù)、融合數(shù)據(jù)等會(huì)依次導(dǎo)入軟總線數(shù)據(jù)緩存中；最后主引擎會(huì)加載所有容器中的私有服務(wù)，私有服務(wù)通過主引擎和系統(tǒng)軟總線的接口實(shí)現(xiàn)對(duì)公共數(shù)據(jù)、實(shí)時(shí)數(shù)據(jù)和融合數(shù)據(jù)的訪問。用戶可通過Docker 的映射地址訪問具體的業(yè)務(wù)模塊，最終所有的服務(wù)都可動(dòng)態(tài)配置和彈性部署，使得整個(gè)系統(tǒng)滿足復(fù)雜化應(yīng)用場(chǎng)景的需求。

3 關(guān)鍵技術(shù)

3.1 數(shù)據(jù)融合技術(shù)

智慧礦山平臺(tái)的建設(shè)要求包括人員定位系統(tǒng)在內(nèi)的各個(gè)子系統(tǒng)之間能夠?qū)崿F(xiàn)數(shù)據(jù)融合及信息共享。大多數(shù)煤礦企業(yè)中各個(gè)子系統(tǒng)都是由不同廠家開發(fā)和部署，因此不同系統(tǒng)之間的數(shù)據(jù)結(jié)構(gòu)大多不同，這就導(dǎo)致了融合過程往往需要大量的重復(fù)性翻譯工作。

設(shè)計(jì)了一種系統(tǒng)軟總線結(jié)構(gòu)。軟總線確定了公共數(shù)據(jù)、實(shí)時(shí)數(shù)據(jù)和融合數(shù)據(jù)的描述規(guī)則和存儲(chǔ)規(guī)范，它將人員定位系統(tǒng)中的共享性、公共性、重用性高的數(shù)據(jù)進(jìn)行抽象和結(jié)構(gòu)化存入數(shù)據(jù)緩存，并且為各個(gè)服務(wù)提供統(tǒng)一的數(shù)據(jù)訪問接口和控制命令通道。同時(shí)軟總線采用數(shù)據(jù)的訂閱發(fā)布機(jī)制，數(shù)據(jù)的發(fā)布者稱為生產(chǎn)者，接收數(shù)據(jù)的服務(wù)稱為消費(fèi)者，系統(tǒng)中各個(gè)服務(wù)都可通過軟總線提供的接口訂閱感興趣的數(shù)據(jù)?？刂泼钔ǖ来鎯?chǔ)生產(chǎn)者發(fā)布、消費(fèi)者訂閱的控制命令信息，這種異步消息傳遞機(jī)制確保了控制命令傳遞過程中的低時(shí)延和獨(dú)立性。對(duì)于融合數(shù)據(jù)的訪問接口，開發(fā)人員可根據(jù)融合平臺(tái)需求創(chuàng)建融合接口服務(wù)，將軟總線打包供融合平臺(tái)調(diào)用，這樣就可從軟總線獲取融合后的數(shù)據(jù)信息。

3.2 基于時(shí)序數(shù)據(jù)庫(kù)的數(shù)據(jù)分類存儲(chǔ)技術(shù)

現(xiàn)有的人員定位系統(tǒng)架構(gòu)都是將系統(tǒng)主數(shù)據(jù)、融合數(shù)據(jù)、歷史數(shù)據(jù)等存放在統(tǒng)一的關(guān)系數(shù)據(jù)庫(kù)中。隨著業(yè)務(wù)需求越來(lái)越多，統(tǒng)一的數(shù)據(jù)庫(kù)存儲(chǔ)逐漸制約著系統(tǒng)對(duì)數(shù)據(jù)的處理能力。

InfluxDB 是一個(gè)由InfluxData 開發(fā)的開源時(shí)序型數(shù)據(jù)庫(kù)，著力于高性能地查詢與存儲(chǔ)時(shí)序型數(shù)據(jù)[14]，被廣泛應(yīng)用于存儲(chǔ)系統(tǒng)的監(jiān)控?cái)?shù)據(jù)。為了提高人員定位系統(tǒng)數(shù)據(jù)處理的時(shí)效性，可引入時(shí)序數(shù)據(jù)庫(kù)對(duì)數(shù)據(jù)進(jìn)行分類存儲(chǔ)。例如MySQL+InfluxDB 的存儲(chǔ)方案，將系統(tǒng)主數(shù)據(jù)、融合數(shù)據(jù)存入MySQL 中，并且同步軟總線數(shù)據(jù)緩存。歷史數(shù)據(jù)結(jié)構(gòu)簡(jiǎn)單可存入InfluxDB 中，將極大地加快對(duì)歷史報(bào)警信息、人員歷史軌跡、設(shè)備歷史狀態(tài)等業(yè)務(wù)的查詢速度。MySQL 和InfluxDB 查詢速度對(duì)比見表1。

表1 MySQL 和InfluxDB 查詢速度對(duì)比Table 1 Comparison of data query speeds of MySQL and InfluxDB

3.3 容器虛擬化技術(shù)

傳統(tǒng)的虛擬化技術(shù)是通過中間層將1 臺(tái)或者多臺(tái)獨(dú)立的機(jī)器虛擬運(yùn)行與物理硬件之上，而容器則是直接運(yùn)行在操作系統(tǒng)內(nèi)核之上的用戶空間。容器作為微服務(wù)運(yùn)行的載體，就像是一個(gè)完整的宿主機(jī)一樣，不僅具備獨(dú)立的用戶空間和運(yùn)行環(huán)境，真正做到服務(wù)之間的隔離和松耦合，而且還支持網(wǎng)絡(luò)端口映射、數(shù)據(jù)持久化以及資源管理功能[15]。Docker 是一個(gè)開源的應(yīng)用容器引擎，開發(fā)人員可將自己開發(fā)的業(yè)務(wù)模塊和依賴包進(jìn)行打包，創(chuàng)建Docker 鏡像文件，1 個(gè)Docker 鏡像擁有完整的文件系統(tǒng)結(jié)構(gòu)。當(dāng)需要對(duì)業(yè)務(wù)進(jìn)行部署時(shí)，開發(fā)者只需要在宿主機(jī)中根據(jù)Docker 鏡像創(chuàng)建并運(yùn)行Docker 容器，Docker容器類似于1 個(gè)鏡像文件的運(yùn)行實(shí)例，包含特定應(yīng)用的代碼及所需的依賴文件，最終用戶即可根據(jù)容器的網(wǎng)絡(luò)映射端口訪問具體的業(yè)務(wù)模塊。

4 結(jié) 語(yǔ)

1）基于微服務(wù)的人員定位系統(tǒng)架構(gòu)，依托主引擎提供的公共服務(wù)、數(shù)據(jù)存儲(chǔ)服務(wù)等基礎(chǔ)支撐功能，實(shí)現(xiàn)了私有業(yè)務(wù)之間的按需分配，具備敏捷開發(fā)、彈性部署和維護(hù)簡(jiǎn)單的優(yōu)勢(shì)。

2）人員定位系統(tǒng)、安全監(jiān)控系統(tǒng)等多源異構(gòu)系統(tǒng)之間的數(shù)據(jù)融合、信息共享和大數(shù)據(jù)處理能力是實(shí)現(xiàn)智慧礦山平臺(tái)的重要前提。軟總線結(jié)構(gòu)構(gòu)建了統(tǒng)一的數(shù)據(jù)的接入和存儲(chǔ)規(guī)范，引入時(shí)序數(shù)據(jù)庫(kù)實(shí)現(xiàn)了對(duì)海量歷史數(shù)據(jù)的高效查詢，以Docker 容器作為運(yùn)行載體的微服務(wù)之間相互隔離，方便開發(fā)人員可對(duì)融合接口服務(wù)進(jìn)行獨(dú)立升級(jí)和部署。