隧道掘進設備多源異構數據采集系統(tǒng)設計開發(fā)與應用

徐受天, 游宇嵩, 葉 蕾, 趙嚴振, 徐劍安

(中鐵工程裝備集團有限公司, 河南 鄭州 450016)

0 引言

隨著隧道施工機械自動化程度不斷發(fā)展，采用全斷面隧道掘進機施工成為當前隧道施工的主要工法。本文中隧道掘進設備主要指全斷面隧道掘進機，包括盾構(用于城市軟土地層掘進)和TBM(用于山嶺隧道硬巖掘進)。根據工作原理不同，盾構分為土壓平衡盾構和泥水平衡盾構，TBM分為敞開式、雙護盾式和單護盾式[1-3]。全斷面隧道掘進機掘進時工作環(huán)境惡劣，高頻振動、電磁干擾等現(xiàn)象嚴重[4]，采集設備一般集中部署，位于掘進設備的主控室內，通過網絡連接到設備各處感知端。傳統(tǒng)盾構/TBM的相關監(jiān)控系統(tǒng)主要限于對PLC數據的采集。隨著隧道施工機械化、數字化、Wi-Fi、5G及大數據技術的發(fā)展，對數據的獲取提出了更高的要求[5]。除傳統(tǒng)盾構/TBM外，隧道施工專用設備、礦用機械也越來越多地投入使用。不同種類的控制器數據、高頻率振動數據、工業(yè)相機照片、三維激光掃描點云圖等通過數據挖掘后，在指導施工、改進裝備設計上發(fā)揮的作用越來越大。當前智能傳感、物聯(lián)網、大數據、無線通信、工業(yè)互聯(lián)網等技術發(fā)展迅速，對于盾構/TBM智能化起到了推動作用[6]。同時，國內外各大廠家均在產品智能化方面開展了大量研究，隧道施工數據的種類與數量與日俱增，無疑對海量多源異構數據的采集、存儲也提出了更高的要求。

張靜等[7]采用地上地下部署工控機，利用光纖網絡傳輸的方式，采集PLC的數據到Web服務器，進而實現(xiàn)可視化；但這種方式僅實現(xiàn)了接入PLC的數據獲取。陳剛等[8]采用基于云平臺的盾構數據采集系統(tǒng)，通過OPC協(xié)議循環(huán)讀取PLC地址，根據用戶設置的配置文件，將PLC記錄信息按照類型逐條區(qū)分處理，然后調用Web API接口，將數據同步發(fā)送到云服務器的數據庫中；這種方式不用進行終端部署，但仍僅采集接入PLC的數據。周奇才等[9]針對盾構施工地層損失監(jiān)測，設計了一種基于Modbus協(xié)議和RS485總線的數據采集系統(tǒng)；但該種方式采集數據較為單一，只針對RS485接口傳感器進行采集。于祥濤[10]以昆明市軌道交通5號線施工為項目依托，利用亞控科技的采集盒子進行數據采集，盒子自帶RS232、RS485、以太網口3種接口，采集的數據主要是PLC數據、電表、水表、電瓶車狀態(tài)等；這種方式利用現(xiàn)有產品進行采集，優(yōu)點是可以快速實現(xiàn)，缺點是不便于拓展，對于其他接口的傳感器無法采集。

針對國內外市面上存在的大量數據采集終端或數據網關，樹根互聯(lián)、上海自動化儀表、Woodhead等公司產品能兼容國內外主流PLC和控制器，但是普遍存在以下問題：1)只能采集主流的、標準的物聯(lián)設備，對隧道施工中類似工業(yè)相機、振動傳感器、點云掃描、激光/雷達探測等設備產生的數據無法采集，可擴展性較差；2)鼓勵數據存儲于開發(fā)廠商的公有云，數據的靈活讀取和二次利用較困難，也不利于數據安全，如果私有化則需要高額的定制費用且后期運維成本極高。因此，有必要開發(fā)可以同時采集隧道施工中產生的大量多源異構數據的專用數據采集系統(tǒng)，本文以此展開研究。

1 總體方案設計

1.1 系統(tǒng)目標及需求

在進行隧道施工專用多源異構數據采集系統(tǒng)研究時，需要提前將系統(tǒng)所應達到的指標明確化、具體化。系統(tǒng)所應達到的目標如下。

1.1.1 多數據源支持

在一個物理終端上支持同時采集多種類型數據源的數據，彼此獨立，互不干擾；同種類型支持多通道數據傳輸，如支持同時采集多個同類型的PLC數據。

1.1.2 多協(xié)議解析

支持多種常用協(xié)議的解析，如西門子PLC的S7協(xié)議、OPC UA、Modbus TCP等。支持多種硬件設備數據的采集，如西門子S7-200/300/400/1200/1500系列PLC、易福門控制器、TBM刀盤磨損檢測裝置、線陣/面陣工業(yè)相機、高頻振動傳感器等。

1.1.3 實時和歷史數據傳輸

按實時數據和歷史數據2種途徑同時傳輸數據。實時數據每次僅傳輸當前時刻最新的數據。歷史數據傳輸頻率相對較小，每次打包傳輸多條數據。遇到網絡、故障等原因，則按時間順序續(xù)傳，確保數據不丟失。

1.1.4 數據預處理和邊緣計算

支持在終端上進行簡單預處理和邊緣計算：將明顯異常的數據進行過濾或處理，將結構化/半結構化數據或占用空間較大的數據轉換為簡單、小巧的結構化數據，具體處理或計算方法可以隨時進行遠程調整等。

1.1.5 現(xiàn)場數據接口

為終端的上位機、第三方信息化智能化系統(tǒng)提供統(tǒng)一的數據接口。提供數據接口的目的是：1)防止第三方直接讀取現(xiàn)場設備，破壞設備數據的保密性，及造成設備數據輸出負載增大；2)減少上位機和第三方軟件的復雜數據處理過程。

1.1.6 數據源動態(tài)擴展

在不影響其他程序的情況下，支持快速定制化開發(fā)擴展新組件，以支持新類型數據源的接入。當新類型的數據源接入后，無需刷機、固件升級和新增硬件，而是通過遠程管理的形式進行功能擴展。

1.1.7 本地Web管理及遠程監(jiān)控接口

終端不開發(fā)基于平臺的圖像界面，采用Web方式進行可視化圖形管理頁面開發(fā)。維護人員使用另外一臺計算機通過Web瀏覽器打開終端管理網頁，進行現(xiàn)場終端管理。系統(tǒng)提供對終端進行遠程監(jiān)控的接口，主要包括：查看終端操作系統(tǒng)狀態(tài)(CPU、內存、外存)；查看和結束進程；查看和設置網絡連接；瀏覽操作系統(tǒng)文件系統(tǒng)；上傳、下載文件；查看和配置數據源參數；查看運行日志文件等。

1.2 系統(tǒng)架構設計

系統(tǒng)總體架構設計決定了后期維護的便捷性、可拓展性以及施工單位、業(yè)主等用戶的使用體驗[11]。本文所述多源異構數據采集系統(tǒng)采用一主多從的架構，每個數據源作為獨立從設備，與其他設備互不干擾，主從設備之間通過Socket套接字進行通信，基于TCP/IP協(xié)議可實現(xiàn)數據源的快速接入。管理者可以通過遠程或者在本地以插件形式添加、刪除、修改從設備，在不影響其他鏈路的前提下，實現(xiàn)數據源的靈活配置、簡單部署。采集終端在采集到數據之后，通過MQTT等協(xié)議進行數據的上傳，數據以結構化存儲在本部的大數據中心。多源異構數據采集系統(tǒng)總體架構設計如圖1所示，當前所接入的數據源為基于Snap7協(xié)議的PLC數據源、基于Modbus RTU協(xié)議的刀盤滾刀監(jiān)測數據源、基于Http協(xié)議的Python邊緣計算數據源、基于Socket套接字通信的振動監(jiān)測數據源、基于千兆網通信的線陣相機圖像采集數據源以及基于OpcUA、Modbus TCP協(xié)議的國產PLC數據源等。服務器位于數據中心，用于收集來自所有終端的數據，并集中統(tǒng)一管理。終端安裝于各隧道施工現(xiàn)場。每個終端由1個主模塊和若干個數據源模塊組成。每個數據源模塊啟動1個獨立進程，對應1種類型的數據源采集。

圖1 多源異構數據采集系統(tǒng)總體架構設計

1.3 系統(tǒng)軟件方案

1.3.1 運行環(huán)境及關鍵技術應用

本文所述多源異構數據采集系統(tǒng)中，服務器運行環(huán)境為基于x86架構的64位標準Linux-CentOS操作系統(tǒng)。采集終端可以實現(xiàn)跨平臺部署運行，適用于基于ARM或x86的Linux操作系統(tǒng)、Windows操作系統(tǒng)，同時支持32位和64位。本系統(tǒng)開發(fā)語言根據語言特性進行選定，采用多種語言共同開發(fā)。其中，服務器、終端主模塊和數據源模塊的主體部分選用Go語言；Web前端部分選用JavaScript、HTML5語言；終端Web后端使用Go語言；服務器Web后端使用Java或Go語言；邊緣計算、部分數據源的前置輸入視情況選用C/C++或Go語言。

1.3.2 終端交互設計

終端主模塊與數據源模塊的交互流程如圖2所示。TCP連接成功后，開始針對不同數據源配置相應的硬件參數，連接硬件成功后，配置相應的映射表讀取數據。

圖2 終端主模塊與數據源模塊的交互流程

終端主模塊與服務器的交互流程如圖3所示。終端上電后，檢查數據源列表，查看哪些數據源在線，然后開始進行各個數據源服務，與各個數據源建立獨立連接和映射關系，進而周期性發(fā)送采集到的設備數據。在發(fā)生連接錯誤時，發(fā)布廣播消息，通知服務器連接錯誤，不再發(fā)送數據。

圖3 終端主模塊與服務器的交互流程

針對歷史數據傳輸，終端每隔指定時間讀取多條數據進行打包，將數據包通過網絡傳遞給服務器。在終端傳送前，提前與服務器約定好數據包大小、歷史數據時間段信息、數據量以及采樣頻率等。

1.3.3 終端通信設計

本系統(tǒng)根據各數據源與終端特性進行相應的通信設計。為了保證統(tǒng)一性，終端采用多接口設計，多接口接入的數據統(tǒng)一進行無縫協(xié)議轉換，最終輸出到終端主進程數據均是按照TCP/IP協(xié)議進行數據接收處理。通信設計依據如下：

1)為方便代碼維護，服務器與終端主模塊之間、終端模塊與各數據源模塊之間采用統(tǒng)一的通信模塊。

2)采用TCP長連接方式和RPC形式，即一問一答。通信伙伴對每個請求都必須響應且只響應1次。

3)密鑰交換使用標準TLS，保證通信過程中數據不會被破譯和篡改[12]。無需再設計其他形式的加密算法。

4)終端主進程與服務器之間、終端主模塊與數據源模塊均基于C/S架構方案，相對于B/S架構，C/S架構具有響應速度快、與現(xiàn)場設備通信頻率高等特點[13]。

建立TCP連接后的所有通信過程，都按1個請求嚴格對應1個響應的方式展開。每個請求稱為1個“請求幀”，每個響應稱為1個“響應幀”，如圖4所示。

圖4 通信過程

當1個TCP連接建立后，同時開啟2個隊列Channel，一個是Send Loop隊列，另一個是Receive Loop隊列。TCP是基于流的可靠連接，但仍需要考慮多線程及多協(xié)程時數據的正確性[11]。

1.4 服務器設計方案

服務器端的方案設計由高性能服務程序、數據傳輸與存儲2部分組成。

1.4.1 高性能服務程序

高性能服務程序要求能夠達到處理高并發(fā)、高數據吞吐量的網絡數據的能力。服務器的資源包括網絡帶寬、包吞吐量、CPU資源、內存資源等[14-15]。

本系統(tǒng)采用Go語言，其語言特性對異步提供了良好的支持，用Goroutine(協(xié)程)+Channel的模式構造服務程序。Goroutine是在線程之上封裝的協(xié)程，每個協(xié)程都有自己的堆棧，協(xié)程間使用Channel進行相互通信。服務程序采用網絡連接池、線程池和內存池，實現(xiàn)了多任務多線程的異步處理。

1.4.2 數據傳輸與存儲

數據傳輸與存儲是利用事先定義好的數據傳輸策略，在服務器接收到數據后進行存儲。數據遠程傳輸分為實時數據傳輸和歷史數據傳輸2部分。實時數據可盡可能保證數據的實時性，但不能保證數據不丟失；歷史數據可保證數據在時間上的完整性，但不能保證數據實時性。

實時數據是按照指定時間間隔從已緩存的內存中獲取當前最新數據，直接推送到遠程數據中心。歷史數據是從緩存數據庫中查詢指定數量的最老數據，按照時間順序打包，然后發(fā)送至數據中心。當數據發(fā)送成功后，便將該數據從緩存數據中刪除，如圖5所示。

圖5 數據遠程傳輸示意圖

2 管理平臺設計

2.1 遠程數據管理平臺

多源數據采集系統(tǒng)遠程數據管理平臺采用B/S架構，以Java SpringBoot技術為基礎，利用MyBatis、Vue、WebSocket等技術相結合進行開發(fā)，使用WebSocket標準協(xié)議在客戶端和服務端之間進行雙向數據傳輸。數據采集系統(tǒng)的數據管理平臺集權限管理、項目管理、設備管理、網關管理、實時監(jiān)控、數據存儲等功能于一體，能夠實現(xiàn)從數據實時通訊到應用的完整處理流程。系統(tǒng)具有簡潔大方的用戶交互界面，能夠提供最低1 000臺設備的并發(fā)接入能力與即時的數據推送呈現(xiàn)體驗。

盾構遠程數據管理平臺的網址鏈接為：https://tmain.tbmcloud.com.cn/#/login?redirect=%2Fscreen。用戶可直接登錄進行查看。

2.1.1 監(jiān)控中心

多源數據采集系統(tǒng)監(jiān)控中心界面如圖6所示。系統(tǒng)總覽頁面展示當前用戶權限下所有的網關數據源的信息，包括設備總數、在線數量、所在位置；實時數據頁面可選擇展示某個數據源遠程傳輸的實時數據點位數值信息；歷史數據查詢頁面可查詢某個數據源一段時間范圍的歷史數據，展示選定點位的數據連續(xù)情況。

圖6 多源數據采集系統(tǒng)監(jiān)控中心界面

2.1.2 管理中心

多源數據采集系統(tǒng)管理中心界面如圖7所示，能夠實現(xiàn)項目管理、設備管理、網關管理、角色管理、用戶管理等功能。項目管理用于管理數據采集終端應用的項目信息，包括項目名稱、負責人、項目地址等信息；設備管理用于管理數據采集終端應用的掘進設備信息，包括與采集終端網關的關聯(lián)與拆解、項目調度，以及相關聯(lián)終端網關的數據源的基本參數、采集頻率、點位信息的遠程設置等功能；網關管理用于管理終端網關信息，包括網關的名稱、網關的編號、網關遠程連接的密碼等信息；角色管理頁面將用戶分成不同的角色，角色對應功能模塊的管理權限；用戶管理可以對用戶進行查詢、新增、修改、刪除操作，關聯(lián)到不同的角色，由角色確定用戶的管理權限。

圖7 多源數據采集系統(tǒng)管理中心界面

2.2 終端本地管理平臺

多源數據采集系統(tǒng)終端本地管理平臺采用Web B/S架構，Web后臺使用Go開發(fā)，Web頁面使用HTML編寫[16]，實現(xiàn)了對數據采集網關的系統(tǒng)運行環(huán)境信息監(jiān)控、連接遠程服務器的通訊配置、數據源的增減及參數配置、數據源的數據采集監(jiān)控等功能。針對本地管理平臺從以下幾個方面進行闡述：

1)終端狀態(tài)可視化。終端狀態(tài)實現(xiàn)了對網關硬件運行環(huán)境的信息展示，包括運行時間、CPU占用率、磁盤占用率等信息，有助于分析采集網關的運行效率和系統(tǒng)的健壯性、可靠性。

2)參數設置。參數設置頁面實現(xiàn)了配置數據采集網關與遠程服務器通訊的IP地址、端口信息、選擇性是否接入外網等功能。

3)數據源管理。數據源頁面實現(xiàn)了配置數據源的通訊地址和通訊協(xié)議、采集頻次、歷史數據傳輸的數量、導入導出點位變量表等信息展示，如圖8所示。

圖8 采集終端管理平臺數據源界面

4)數據實時監(jiān)控。實時監(jiān)控頁面實現(xiàn)了實時顯示網關采集數據源的點位變量數據，數據顯示刷新頻率為1 s，在數據源斷開或者延遲過大時，實時監(jiān)控數據將不再刷新，由此得知數據源出現(xiàn)通信問題，界面如圖9所示。

圖9 采集終端管理平臺實時監(jiān)控界面

3 數據源模塊設計與現(xiàn)場測試

隧道施工時的網絡部署主要是以以太網為主，各感知端通過以太網接入到主控室的交換機上，而后接入采集終端，其中，設備數據源的采集頻率一般為缺省值，如PLC采集速率一般為1次/s，且用戶可進行自定義設置。

3.1 西門子PLC數據源

3.1.1 采集模塊設計

目前PLC廠商的OPC服務器通常只能運行在Windows平臺上，且體積龐大，占用資源多[17]。因考慮到兼容ARM開發(fā)，宜選用直接利用PLC的內部協(xié)議，用以太網進行連接。西門子S7-200/300/400等均支持S7協(xié)議。選用開源的Snap7函數庫可以對S7協(xié)議進行解析，相對OPC、OPC UA等其他方式，具有跨平臺、通信效率高、占用資源少的優(yōu)點，缺點是開發(fā)難度較大[18]。

由于每臺設備的PLC地址不盡相同，需要事先定義PLC的點位表，存儲于本地數據庫中，只有在點位表中存在的地址才進行讀取，避免不必要的CPU和帶寬資源浪費。在S7協(xié)議中，PLC數據存儲于I、Q、M、DB等不同的區(qū)域，需要分別讀取，而且每次讀取時只能讀取一段連續(xù)存儲區(qū)域。連續(xù)區(qū)域中，部分地址可能是未定義的[19]。通過優(yōu)化算法，既保證每次讀取的連續(xù)區(qū)域足夠大以減少讀取次數，又避免讀取到過多的無用數據。

以圖10為例，1個灰色格子表示1個需要采集的PLC變量，白色格子表示不需要采集的PLC變量。圖中列舉了3種讀取方式，其中，A方式保證每次只讀取需要采集的變量，但是讀取了3次；C方式僅讀取1次，但是讀取了過多無需采集的數據；而B方式兼顧了讀取次數和讀取總數量，更加合理。

圖10 PLC連續(xù)區(qū)域讀取示意圖

3.1.2 現(xiàn)場部署測試

2020年7月31日，在廣州地鐵11號線盾構上進行了PLC接入測試，如圖11所示。該項目通訊機柜內的內外網網口相對容易排查，交換機是比較常規(guī)的網口布局，內外網網口分別在交換機不同的區(qū)域。在查找到內網及外網網口后，進行系統(tǒng)部屬測試，數據實時回傳至服務器。

(a)內網、外網網口

3.2 振動監(jiān)測數據源

3.2.1 采集模塊設計

主機振動監(jiān)測系統(tǒng)由加速度傳感器、信號采集與傳輸、信號處理與顯示3個模塊組成，系統(tǒng)架構如圖12所示。

圖12 主機振動監(jiān)測系統(tǒng)架構

加速度傳感器可獲取主驅動電機、中心艙、刀盤隔板等位置的振動信號，信號采集儀將采集到的加速度數據通過TCP/IP通信協(xié)議接入數據采集終端，對傳感器數據進行采集與存儲，最后傳輸到上位機。

3.2.2 現(xiàn)場部署測試

2020年12月，在云南大瑞鐵路高黎貢山隧道TBM上搭載了所設計的振動監(jiān)測數據源，并進行了現(xiàn)場部署測試。采集儀部署如圖13(a)所示，位于人艙出口后方主梁底部位置。數據采集終端部署如圖13(b)所示，位于主控室操作臺上方。上位機運行圖見圖13(c)，為采集到的數據在上位機上的可視化顯示。經過本次測試，振動數據設置采集頻率為240 Hz，數據可實時回傳及存儲，系統(tǒng)運行正常。

(a)采集儀部署

3.3 渣片監(jiān)測數據源

3.3.1 采集模塊設計

在TBM掘進時，由掘進出渣情況可以從側面反映當前掌子面的情況。渣片圖像分割系統(tǒng)搭載的主要目的是識別TBM施工時渣片的粒徑大小并進行分組。在TBM施工時，滾刀與巖層間存在多種形式的作用力，根據力的相互作用進行巖層的切割，形成渣片后利用皮帶機進行出渣。在掘進過程中，正常的渣片粒徑長邊為10～15 cm(工程經驗所得)，當出現(xiàn)較大粒徑時，說明滾刀與巖層間存在切割異常。為了避免刀具異常磨損，此時渣片分割系統(tǒng)發(fā)出預警信號，一方面提示前方的地質情況可能發(fā)生突變，另一方面提醒總推進力可能過大，需要司機及時調整掘進參數，為TBM安全施工提供一定的保障。在進行渣片粒徑分級識別中，由于皮帶機速度≥3 m/s，普通相機拍出的渣片圖像模糊且無法準確分辨，故本數據源所采用的渣片相機為線陣相機，最高行寬為4 096 pt，最高行頻為28 000 pt，所生成的無損圖像大小≥40 MB，利用激光進行補光處理后，無需外加燈光。

渣片狀態(tài)在線監(jiān)測系統(tǒng)設計方案如圖14所示。硬件部分傳輸采用千兆網口，采用直連或者接千兆交換機的方式，將相機端接入到數據采集終端，相機采用獨立電源/POE供電。軟件部分網絡傳輸基于TCP/IP協(xié)議，通過相機廠家提供的API接口和數據解析格式進行相機的查找、連接、拍攝及數據傳輸。

圖14 渣片狀態(tài)在線監(jiān)測系統(tǒng)設計方案

3.3.2 現(xiàn)場部署測試

在進行渣片監(jiān)測數據源測試時，同樣選擇云南大瑞鐵路高黎貢山隧道TBM進行了相機搭載、通信測試等。如圖15所示，回傳的圖像數據在上位機上顯示，圖像采集頻率為0.7 FPS，圖像大小平均為30 MB。

(a)相機現(xiàn)場部署

4 結論與討論

本文主要論述了專用的隧道掘進設備多源異構數據采集系統(tǒng)的設計方案、實現(xiàn)方法及現(xiàn)場應用情況。采用一主多從的系統(tǒng)架構，按照“微服務”的設計思想，設計了數據源接入接口統(tǒng)一以及數據源進程相互獨立的程序架構，開發(fā)出安全、穩(wěn)定、高性能、高并發(fā)、低帶寬占用的統(tǒng)一數據傳輸協(xié)議的程序框架，提出了一種以插件形式組織數據源接入，進行快速定制化程序開發(fā)并遠程更新終端程序的方法。

通過隧道施工數據智能采集系統(tǒng)在工程項目中的具體應用，數據采集網關先后接入PLC數據、振動監(jiān)測數據、渣土改良數據、刀盤磨損數據等10多種異構類型的數據源，解決了隧道施工中各種異構數據采集的難題。

由于本文所述的多源數據采集網關的邊緣計算能力有限，內存資源有限，從而在同時接入多個大密度數據源進行傳輸時速率有所降低，因此，如何優(yōu)化多個大密度數據源傳輸策略是今后需要研究的重點內容。