孟祥波，徐受天，馬 強

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

0 引言

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

1 總體方案設計

1.1 總體框架設計

要實現(xiàn)遠程的管理和技術支持，首先要對盾構狀態(tài)信息和歷史數(shù)據(jù)有一個全面、及時和準確的掌握，再通過先進的分析手段，才能對盾構施工進行指導。為完成盾構數(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)視客戶端(簡稱“遠程客戶端”)。從中心服務器獲取指定盾構項目的數(shù)據(jù)并通過友好的界面展示給遠程監(jiān)視用戶，包括實時數(shù)據(jù)顯示、歷史數(shù)據(jù)曲線圖和表格顯示、報警信息顯示等。

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

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

1.2 通信方式選擇

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

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

項目部監(jiān)控計算機，一方面要連接盾構PLC，一方面要連接互聯(lián)網，需要裝雙網卡。一個網卡接局域網，通過銅線接入技術和井下盾構局域網連接起來;另一個網卡接互聯(lián)網，通過編程軟件實現(xiàn)在監(jiān)控計算機上接收到盾構監(jiān)控數(shù)據(jù)后再轉發(fā)到互聯(lián)網上。這樣，地理位置處在很遠的遠程監(jiān)控客戶端，可以通過互聯(lián)網接收數(shù)據(jù)。系統(tǒng)整體結構示意圖如圖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#主流面向對象語言。其中，C#作為新推出的一種編程語言，幾乎集中了所有關于軟件開發(fā)和軟件工程研究的最新成果，面向對象、類型安全、組件技術、自動內存管理、跨平臺異常處理、版本控制和代碼安全管理［7］。綜合以上考慮，使用當前普遍使用的快速開發(fā)語言C#。

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

2.1 通過C#連接OPC服務器

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

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

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

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

本系統(tǒ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)網上的另一臺機器上;UDP是一個不可靠的、無連接的協(xié)議。盾構的實時數(shù)據(jù)傳輸對實時性要求較高，在網絡條件不好的情況下丟棄一部分“過時”的數(shù)據(jù)，以保證數(shù)據(jù)總是比較新的;而歷史數(shù)據(jù)傳輸對安全性要求較高。因此，采用TCP負責配置文件、歷史數(shù)據(jù)、圖片等文件的傳輸;采用UDP負責實時數(shù)據(jù)的傳輸。

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

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

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

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

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

2.2.3 HTTP 協(xié)議設計

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

AJAX全稱為“Asynchronous JavaScript and XML”，是指一種創(chuàng)建交互式網頁應用的網頁開發(fā)技術。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ù)，然后通過因特網采用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。不論用戶是否已經真的收到了實時數(shù)據(jù)，本地服務器總是向在線用戶列表中的主機定時發(fā)送。本地服務器界面如圖4所示。

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

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

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

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

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

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

3.3 遠程客戶端的界面設計

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

4 結論與討論

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

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

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

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

［1］ 周文波，胡珉.盾構隧道信息化施工智能管理系統(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］ 沈立新.盾構實時遠程監(jiān)控系統(tǒng)技術［J］.鐵道建筑技術，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盾構刀盤遠程監(jiān)控系統(tǒng)設計［J］.電腦知識與技術，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的盾構地面數(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在盾構控制系統(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］ 張學武.對盾構法地鐵隧道施工引起的地表變形探討［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］.沈陽:沈陽理工大學計算機應用技術專業(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))