基于互聯網的盾構遠程實時監控系統開發

孟祥波，徐受天，馬 強

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

0 引言

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

1 總體方案設計

1.1 總體框架設計

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

圖1 遠程監控系統總體框架Fig.1 Structure of remote monitoring system

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

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

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

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

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

1.2 通信方式選擇

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

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

項目部監控計算機，一方面要連接盾構PLC，一方面要連接互聯網，需要裝雙網卡。一個網卡接局域網，通過銅線接入技術和井下盾構局域網連接起來;另一個網卡接互聯網，通過編程軟件實現在監控計算機上接收到盾構監控數據后再轉發到互聯網上。這樣，地理位置處在很遠的遠程監控客戶端，可以通過互聯網接收數據。系統整體結構示意圖如圖2所示。

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

1.3 開發環境選擇

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

2 通信協議設計研究

2.1 通過C#連接OPC服務器

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

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

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

2.2 應用層通信協議設計

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

2.2.1 實時數據傳輸的協議設計

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

2.2.2 文件傳輸協議的設計

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

表1 實時數據文件頭Table 1 Header of real-time data transmission

2.2.3 HTTP 協議設計

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

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

3 監控系統設計

3.1 本地服務器的實時數據發送

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

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

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

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

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

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

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

3.3 遠程客戶端的界面設計

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

4 結論與討論

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

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

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

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

［1］ 周文波，胡珉.盾構隧道信息化施工智能管理系統設計及應用［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］ 沈立新.盾構實時遠程監控系統技術［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盾構刀盤遠程監控系統設計［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的盾構地面數據采集和監視系統設計［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在盾構控制系統檢測試驗臺的應用［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從基礎到項目實戰［M］.北京:化學工業出版社，2009:11－12.

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

［9］ 郭明磊.基于WEB的遠程監控系統研究［D］.沈陽:沈陽理工大學計算機應用技術專業，2009.

［10］ 陳元謀，吳長奇.基于Socket的遠程監控的通信系統實現［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))