基于互聯(lián)網(wǎng)的盾構(gòu)遠程實時監(jiān)控系統(tǒng)開發(fā)

孟祥波，徐受天，馬 強

(中鐵隧道裝備制造有限公司，鄭州 450016)

0 引言

隨著地下空間開發(fā)技術(shù)的發(fā)展，一個大型的地下工程施工企業(yè)往往會面臨多個工地同時施工及工地分布非常分散等局面。由于人員有限，如何有效管理這些工程和提供全面的技術(shù)支持，成為當前急需解決的問題［1］。目前國內(nèi)外著名的盾構(gòu)生產(chǎn)商(如海瑞克、羅威特、小松、羅賓斯、上海隧道)都有自己的地面數(shù)據(jù)采集系統(tǒng)，但是大多數(shù)地面監(jiān)控系統(tǒng)都只能安裝在1臺計算機上，不支持多個用戶同時訪問，不能通過互聯(lián)網(wǎng)方式進行實時監(jiān)控，無法實現(xiàn)多臺盾構(gòu)集中監(jiān)控的功能。文獻［1］代表了上海隧道開發(fā)的盾構(gòu)監(jiān)控系統(tǒng)，其重點在于用先進控制算法優(yōu)化施工數(shù)據(jù)，不強調(diào)多臺盾構(gòu)的集中監(jiān)控;文獻［2］代表了完全從底層開發(fā)的監(jiān)控系統(tǒng)，盾構(gòu)是個系統(tǒng)工程，完全從數(shù)據(jù)采集板卡開發(fā)難度較大，也不利于實現(xiàn)盾構(gòu)所有參數(shù)都加入監(jiān)控系統(tǒng);文獻［3］代表采用組態(tài)軟件開發(fā)監(jiān)控系統(tǒng)，這類系統(tǒng)不利于后期功能擴展，且系統(tǒng)安裝設置都比較復雜，即多用戶訪問盾構(gòu)監(jiān)控系統(tǒng)時必須安裝龐大而復雜的客戶端軟件。從以上文獻可以看出，多用戶通過互聯(lián)網(wǎng)對多臺盾構(gòu)進行集中監(jiān)控的功能還不多見。綜上，盾構(gòu)研發(fā)制造是一個長期的過程，花更多的時間和精力開發(fā)出具有自己特點、具有自主知識產(chǎn)權(quán)的能實時獲取施工信息進而能提供施工指導的盾構(gòu)遠程實時監(jiān)控系統(tǒng)成為必要。本文設計的基于互聯(lián)網(wǎng)的盾構(gòu)遠程實時監(jiān)控系統(tǒng)，即是為實現(xiàn)多臺盾構(gòu)集中監(jiān)控、多用戶訪問和遠程故障診斷等功能而開發(fā)的。

1 總體方案設計

1.1 總體框架設計

要實現(xiàn)遠程的管理和技術(shù)支持，首先要對盾構(gòu)狀態(tài)信息和歷史數(shù)據(jù)有一個全面、及時和準確的掌握，再通過先進的分析手段，才能對盾構(gòu)施工進行指導。為完成盾構(gòu)數(shù)據(jù)的遠程監(jiān)視，將整個系統(tǒng)分為5個相對獨立的軟件項目，分別位于不同的計算機上，彼此通過TCP或UDP進行通信。系統(tǒng)框架如圖1所示。

圖1 遠程監(jiān)控系統(tǒng)總體框架Fig.1 Structure of remote monitoring system

1)本地服務器。讀取PLC的實時數(shù)據(jù)和人機界面上的歷史數(shù)據(jù)并存儲，再將這些數(shù)據(jù)發(fā)送至中心服務器。

2)中心服務器。從來自各個項目部的本地服務器讀取實時數(shù)據(jù)和歷史數(shù)據(jù)并存儲，再根據(jù)遠程客戶端的請求發(fā)送其需要的數(shù)據(jù)。

3)遠程C/S監(jiān)視客戶端(簡稱“遠程客戶端”)。從中心服務器獲取指定盾構(gòu)項目的數(shù)據(jù)并通過友好的界面展示給遠程監(jiān)視用戶，包括實時數(shù)據(jù)顯示、歷史數(shù)據(jù)曲線圖和表格顯示、報警信息顯示等。

4)WEB瀏覽器客戶端。從中心服務器獲取數(shù)據(jù)并通過網(wǎng)頁形式顯示實時數(shù)據(jù)和歷史數(shù)據(jù)。

5)本地地面客戶端(簡稱“本地客戶端”)。從本地服務器獲取數(shù)據(jù)并通過友好的界面展示給項目部工作人員。

1.2 通信方式選擇

系統(tǒng)主要包括2部分:一部分是從盾構(gòu)到項目部監(jiān)控計算機，另一部分是從項目部監(jiān)控計算機通過互聯(lián)網(wǎng)到遠程計算機。通信方式的選擇主要是確定項目部監(jiān)控計算機和盾構(gòu)PLC之間的通信(即PC機與PLC之間的通信)，它將會影響整個設計思路，必須優(yōu)先考慮。PLC選用西門子S7－400系列，S7－400按功能強弱排序，主要提供MPI、Profibus和工業(yè)以太網(wǎng)等通訊子網(wǎng)［4］。在這幾種通信方式中，工業(yè)以太網(wǎng)具有成本低廉、通用性極好、速度快和可靠等特點，本系統(tǒng)的通信采用工業(yè)以太網(wǎng)方式［5］。

工業(yè)以太網(wǎng)最常用的傳輸介質(zhì)是RJ45(普通網(wǎng)線)，其最大傳輸距離是100 m［6］。當盾構(gòu)正常掘進時，從地面辦公室到盾構(gòu)PLC的連接線若超過網(wǎng)線支持的最大距離，就必須要使用相應的通信設備進行距離延伸。光纖和電話線均可以傳輸長距離的信號，光纖的傳輸質(zhì)量較好，電話線成本較低，二者的選擇可以綜合項目的距離和成本等因素來考慮。目前2種連接方式在不同項目上都有使用。本系統(tǒng)以電話線連接為例。

項目部監(jiān)控計算機，一方面要連接盾構(gòu)PLC，一方面要連接互聯(lián)網(wǎng)，需要裝雙網(wǎng)卡。一個網(wǎng)卡接局域網(wǎng)，通過銅線接入技術(shù)和井下盾構(gòu)局域網(wǎng)連接起來;另一個網(wǎng)卡接互聯(lián)網(wǎng)，通過編程軟件實現(xiàn)在監(jiān)控計算機上接收到盾構(gòu)監(jiān)控數(shù)據(jù)后再轉(zhuǎn)發(fā)到互聯(lián)網(wǎng)上。這樣，地理位置處在很遠的遠程監(jiān)控客戶端，可以通過互聯(lián)網(wǎng)接收數(shù)據(jù)。系統(tǒng)整體結(jié)構(gòu)示意圖如圖2所示。

圖2 通信硬件連接Fig.2 Real connection of communication

1.3 開發(fā)環(huán)境選擇

遠程監(jiān)控系統(tǒng)屬于地面監(jiān)控的擴展，使用組態(tài)軟件開發(fā)相對困難，而且每臺客戶端安裝龐大的組態(tài)軟件也不合適。除此之外，目前軟件業(yè)界存在C++，Java和C#主流面向?qū)ο笳Z言。其中，C#作為新推出的一種編程語言，幾乎集中了所有關于軟件開發(fā)和軟件工程研究的最新成果，面向?qū)ο?、類型安全、組件技術(shù)、自動內(nèi)存管理、跨平臺異常處理、版本控制和代碼安全管理［7］。綜合以上考慮，使用當前普遍使用的快速開發(fā)語言C#。

2 通信協(xié)議設計研究

2.1 通過C#連接OPC服務器

由于西門子S7－400沒有公布通過工業(yè)以太網(wǎng)方式連接PC的數(shù)據(jù)報格式，不能通過編程直接控制PLC。西門子的解決方案是采用其提供的驅(qū)動程序，將PC與PLC的通信標準化為OPC。OPC(用于過程控制的OLE)是一種用于自動化領域內(nèi)組件的被絕大多數(shù)PLC支持的新通訊標準。目前盾構(gòu)所用到的PLC(如西門子、三菱、施耐德、AB等)都有專門的軟件來實現(xiàn)其OPC接口。因此，用OPC設計出來的系統(tǒng)可以很輕易地移植到其他盾構(gòu)或PLC平臺上。

在系統(tǒng)的5大模塊中，只有本地服務器是直接與PLC連接的。中心服務器、本地客戶端、遠程客戶端與瀏覽器客戶端的實時數(shù)據(jù)都是直接或間接來自于本地服務器。在本地服務器所在的主機上，同時安裝有OPC服務器和 OPC客戶端。OPC服務器(Simatic NET)是由PLC廠商提供的類似于設備驅(qū)動程序的軟件，它通過PLC廠商私有的通信協(xié)議讀取PLC中的數(shù)據(jù)，并將其轉(zhuǎn)化為與OPC規(guī)范兼容的數(shù)據(jù)結(jié)構(gòu)［8］。在微軟.NET平臺下本地服務器編寫OPC客戶端讀取OPC服務器中的數(shù)據(jù)，存儲于內(nèi)存和數(shù)據(jù)庫，并將實時數(shù)據(jù)通過因特網(wǎng)傳送至位于總部的中心服務器。中心服務器再將處理后的實時數(shù)據(jù)或歷史數(shù)據(jù)轉(zhuǎn)發(fā)給遠程客戶端。C#與OPC服務器的連接原理如圖3所示。

圖3 C#連接OPC服務器原理圖Fig.3 Principle of C#connecting with OPC server

2.2 應用層通信協(xié)議設計

本系統(tǒng)基于以太網(wǎng)，即TCP/IP協(xié)議。在TCP/IP模型中，傳輸層有 TCP(Transfer Control Protocol，傳輸控制協(xié)議)和UDP(User Datagram Protocol，用戶數(shù)據(jù)報協(xié)議)2種協(xié)議。TCP是一個可靠的、面向連接的協(xié)議，允許從一臺機器發(fā)出的字節(jié)流準確無誤地遞交到互聯(lián)網(wǎng)上的另一臺機器上;UDP是一個不可靠的、無連接的協(xié)議。盾構(gòu)的實時數(shù)據(jù)傳輸對實時性要求較高，在網(wǎng)絡條件不好的情況下丟棄一部分“過時”的數(shù)據(jù)，以保證數(shù)據(jù)總是比較新的;而歷史數(shù)據(jù)傳輸對安全性要求較高。因此，采用TCP負責配置文件、歷史數(shù)據(jù)、圖片等文件的傳輸;采用UDP負責實時數(shù)據(jù)的傳輸。

2.2.1 實時數(shù)據(jù)傳輸?shù)膮f(xié)議設計

系統(tǒng)內(nèi)各部分之間的實時傳輸使用UDP協(xié)議通信，但是還不夠，因為UDP是一種工業(yè)標準，很籠統(tǒng)，適用性很廣，沒有也不可能規(guī)定盾構(gòu)數(shù)據(jù)采集以及OPC通信方面的細節(jié)，所以還必須在UDP基礎上開發(fā)出專門用于本系統(tǒng)實時傳輸?shù)膮f(xié)議。為使內(nèi)容更加緊湊且出于執(zhí)行效率考慮，所有UDP數(shù)據(jù)報均采用二進制形式，它們具有統(tǒng)一的文件頭(見表1)。

2.2.2 文件傳輸協(xié)議的設計

文件傳輸通常都采用TCP方式。目前已經(jīng)有比較成熟的FTP和HTTP協(xié)議，但這二者都需要架設較為復雜的專用服務器，而且難以與現(xiàn)有項目有機集成。隧道內(nèi)人機界面、本地服務器、中心服務器都有成為文件傳輸服務器的需求。如果采用FTP或HTTP，需為其設置一個公網(wǎng)端口，對位于項目部現(xiàn)場局域網(wǎng)內(nèi)的本地服務器是難以做到的。為此，設計了一個自定義的文件傳輸協(xié)議，使中心服務器向本地服務器或遠程客戶端向中心服務器下載歷史數(shù)據(jù)和配置文件變得更加靈活、更加易于控制。協(xié)議流程一般是:申請傳輸歷史數(shù)據(jù)—傳送文件綜合信息—根據(jù)文件大小分塊—傳輸文件塊—組合文件。不論是文件信息還是塊內(nèi)容都需要設置文件頭和校驗，傳輸時還需要考慮“粘包處理”。

表1 實時數(shù)據(jù)文件頭Table 1 Header of real-time data transmission

2.2.3 HTTP 協(xié)議設計

客戶端也可以通過瀏覽器來訪問中心服務器，兩者間使用標準的HTTP進行通信。客戶端不能直接訪問服務器，而必須通過WEB服務器中轉(zhuǎn)。WEB服務器由微軟的IIS(Internet信息服務)充當。IIS一方面作為客戶端從中心服務器的緩存讀取OPC數(shù)據(jù)，另一方面又作為WEB服務器響應WEB瀏覽器的HTTP請求。

AJAX全稱為“Asynchronous JavaScript and XML”，是指一種創(chuàng)建交互式網(wǎng)頁應用的網(wǎng)頁開發(fā)技術(shù)。AJAX應用可以僅向服務器發(fā)送并取回必需的數(shù)據(jù)，它使用SOAP或其他一些基于XML的Web Service接口，并在客戶端采用JavaScript處理來自服務器的響應［9］。由于在服務器和瀏覽器之間交換的數(shù)據(jù)大量減少，應用的響應更快;同時，很多的處理工作可以在發(fā)出請求的客戶端機器上完成，所以Web服務器的處理時間也減少了。使用AJAX定時請求Web服務器，并實現(xiàn)默認1 s/次的無閃爍數(shù)據(jù)更新。

3 監(jiān)控系統(tǒng)設計

3.1 本地服務器的實時數(shù)據(jù)發(fā)送

如圖3所示，本地服務器首先直接讀取PLC的實時數(shù)據(jù)，然后通過因特網(wǎng)采用UDP協(xié)議將數(shù)據(jù)傳送至中心服務器。為保證高效傳輸實時數(shù)據(jù)，服務器通過接收客戶端發(fā)來的“心跳信息”來確定其是否在線，然后按指定的時間間隔不斷地往客戶端發(fā)送實時數(shù)據(jù)。由于“心跳信息”的發(fā)送頻率遠遠沒有實時數(shù)據(jù)的發(fā)送頻率高，故可以減少客戶端向服務器發(fā)送數(shù)據(jù)包的帶寬。一般將發(fā)送“心跳”的時間間隔設置為20～120 s，而發(fā)送實時數(shù)據(jù)的間隔是0.5～2 s。不論用戶是否已經(jīng)真的收到了實時數(shù)據(jù)，本地服務器總是向在線用戶列表中的主機定時發(fā)送。本地服務器界面如圖4所示。

圖4 本地服務器界面(模擬)Fig.4 Simulated interface of local server

3.2 中心服務器的在線項目維護

中心服務器必須位于有獨立公網(wǎng)IP的專業(yè)服務器上，是實現(xiàn)盾構(gòu)遠程數(shù)據(jù)監(jiān)控的核心部分［10］。本地服務器和遠程客戶端啟動后，會嘗試連接中心服務器，發(fā)送項目標識號和口令請求中心服務器的驗證。驗證通過后，本地服務器以一定的時間間隔不斷地給中心服務器發(fā)送實時數(shù)據(jù)。中心服務器通過項目標識為索引在內(nèi)存中建立多個項目的實時數(shù)據(jù)列表，其中包括本地服務器和遠程客戶端的IP地址和端口號。中心服務器定時遍歷在線用戶“心跳信息”，如果超過指定值，就認為該用戶已經(jīng)掉線，將其從在線用戶列表中清除。如果有新的客戶端登陸成功，則將其加入到在線用戶列表。

盾構(gòu)是定制性產(chǎn)品，其對應的監(jiān)控系統(tǒng)界面是不完全相同的，要實現(xiàn)多臺盾構(gòu)集中監(jiān)控和多用戶訪問，就要求系統(tǒng)的遠程客戶端界面不是一成不變的。為方便在盡可能不重新編譯的情況下可以修改這些設置，采用配置文件的形式設計。

配置文件在客戶端的顯示方面有很大影響。配置文件保存的內(nèi)容主要有頁面元素屬性、數(shù)據(jù)綁定關系、報警文本映射表等。不同的項目有不同的配置文件，但有相同的遠程客戶端程序。遠程客戶端要顯示多個項目，就只能依賴配置文件來區(qū)分。遠程客戶端在連接中心服務器后，需首先請求要監(jiān)控的項目的配置文件。配置文件傳輸過程見圖5。

圖5 配置文件的傳輸Fig.5 Transmission of configuration file

3.3 遠程客戶端的界面設計

如前所述，盾構(gòu)的個性化設計導致的客戶端界面設計的不確定性由配置文件解決。同一個客戶端程序依賴不同的配置文件即可顯示不同的界面。客戶端程序相當于一個框架，根據(jù)頁面元素屬性配置文件中控件的位置、大小、字體、顏色等信息顯示出相應的控件?？丶@示成功之后，界面的數(shù)據(jù)實時更新用到了數(shù)據(jù)綁定技術(shù)。依據(jù)的數(shù)據(jù)來自一個數(shù)據(jù)綁定關系配置文件。數(shù)據(jù)綁定關系配置文件中保持的是控件名與OPC變量名、數(shù)據(jù)顯示位的對應關系。簡言之，界面先通過頁面元素屬性配置文件顯示畫面，再與數(shù)據(jù)綁定配置文件匹配定時更新數(shù)據(jù)值。遠程客戶端界面見圖6(按設計要求和盾構(gòu)操作界面相似)。

4 結(jié)論與討論

該系統(tǒng)在大連地鐵103標和201標等項目應用中取得了良好的效果，任意授權(quán)用戶在驗證用戶名和密碼后，通過安裝簡易客戶端或者直接由WEB瀏覽器均可遠程訪問這2臺盾構(gòu)，查看盾構(gòu)的即時參數(shù)、調(diào)閱歷史數(shù)據(jù)曲線圖和遠程診斷PLC故障等，整個系統(tǒng)操作簡易，界面友好。

基于互聯(lián)網(wǎng)的盾構(gòu)遠程實時監(jiān)控系統(tǒng)實現(xiàn)了多臺盾構(gòu)集中監(jiān)控、多用戶互聯(lián)網(wǎng)訪問和遠程故障診斷等功能，經(jīng)驗證各項功能(實時界面顯示、歷史數(shù)據(jù)傳輸、賬戶管理)都滿足設計要求，解決了大型施工單位多臺盾構(gòu)同時施工時技術(shù)人員不足的困難，提高了管理效率，節(jié)約了管理成本，具有很好的推廣價值。

圖6 遠程客戶端界面Fig.6 Interface of remote client

目前存在的問題有:1)數(shù)據(jù)傳輸受網(wǎng)絡環(huán)境影響較大，大量歷史數(shù)據(jù)集中傳輸耗時較多;2)對歷史數(shù)據(jù)的后期處理現(xiàn)在僅做到了顯示曲線圖和數(shù)據(jù)表格，還可以根據(jù)需要進一步處理，有待于進一步的研究。

［1］ 周文波，胡珉.盾構(gòu)隧道信息化施工智能管理系統(tǒng)設計及應用［J］.巖石力學與工程學報，2004(S2):460－465.(ZHOU Wenbo，HU Min.Design and application of intelligent management system of digitalized construction in a shield-driven tunnel［J］.Chinese Journal of Rock Mechanics and Engineering，2004(S2):460 －465.(in Chinese))

［2］ 沈立新.盾構(gòu)實時遠程監(jiān)控系統(tǒng)技術(shù)［J］.鐵道建筑技術(shù)，2010(8):38 －42.(SHEN Lixin.A real-time vision system used for shield machine［J］.Railway Construction Technology，2010(8):38 －42.(in Chinese))

［3］ 高勇.基于WinCC盾構(gòu)刀盤遠程監(jiān)控系統(tǒng)設計［J］.電腦知識與技術(shù)，2011(18):208 －210.(GAO Yong.Remote monitoring system designs based on the WinCC shield cutter［J］.Computer Knowledge and Technology，2011(18):208 －210.(in Chinese))

［4］ 徐受天，蒲曉波.基于OPC的盾構(gòu)地面數(shù)據(jù)采集和監(jiān)視系統(tǒng)設計［J］.隧道建設，2009，29(6):674 －677.(XU Shoutian，PU Xiaobo.Design of data acquisition and visualization system of shield machine based on OPC［J］.Tunnel Construction，2009，29(6):674 －677.(in Chinese))

［5］ 蒲曉波.西門子PLC在盾構(gòu)控制系統(tǒng)檢測試驗臺的應用［J］.隧道建設，2009，29(1):132 － 134.(PU Xiaobo.Application of Siemens PLC in test-bed for shield machine control system［J］.Tunnel Construction，2009，29(1):132 －134.(in Chinese))

［6］ 張學武.對盾構(gòu)法地鐵隧道施工引起的地表變形探討［J］.建材與裝飾:下旬刊，2008(6):312 －314.

［7］ 李海濤，史愛松，孫更新.C#3.0從基礎到項目實戰(zhàn)［M］.北京:化學工業(yè)出版社，2009:11－12.

［8］ Siemens A G.SIMATIC NET工業(yè)通訊的 IT解決方案［K］.新鄉(xiāng):中鐵隧道集團設備制造有限公司，2002.

［9］ 郭明磊.基于WEB的遠程監(jiān)控系統(tǒng)研究［D］.沈陽:沈陽理工大學計算機應用技術(shù)專業(yè)，2009.

［10］ 陳元謀，吳長奇.基于Socket的遠程監(jiān)控的通信系統(tǒng)實現(xiàn)［J］.計算機安全，2011(3):63 －65.(CHEN Yuanmou，WU Changqi.Based on the Socket of remote monitoring communication system implementation［J］.Computer Security，2011(3):63 －65.(in Chinese))