城市軌道交通信號系統(tǒng)在線監(jiān)測系統(tǒng)信息集成化平臺方案研究

許華陽 李潤錦

(廣州鐵科智控有限公司，510308，廣州//第一作者，助理工程師)

目前，我國城市軌道交通信號系統(tǒng)的在線監(jiān)測系統(tǒng)呈現(xiàn)多樣化發(fā)展趨勢。為了建設信息集成化平臺(以下簡稱“平臺”)，實現(xiàn)對各監(jiān)測系統(tǒng)分散異構的數(shù)據(jù)源進行統(tǒng)一訪問，本文通過對現(xiàn)有的監(jiān)測模式進行改良升級，利用不同通信接口、多線程并發(fā)技術實時采集不同信號監(jiān)測系統(tǒng)的數(shù)據(jù)，并將數(shù)據(jù)按前期數(shù)據(jù)庫設計統(tǒng)一整合到研究上。本文所提出的監(jiān)測模式打破了原模式中各在線監(jiān)測系統(tǒng)的封閉性，使用戶能夠更便捷高效地獲取信息。

1 信號監(jiān)測系統(tǒng)現(xiàn)狀分析

不同信號系統(tǒng)廠商的信號在線監(jiān)測系統(tǒng)的信息格式定義雖然各不相同，但其都是對生產網內信號專業(yè)設備進行監(jiān)測。信號專業(yè)傳統(tǒng)故障監(jiān)測模式為：故障信息只顯示在特定工控機上；設置OCC(運營控制中心)調度和值班人員全天候值守觀察；監(jiān)測系統(tǒng)一旦出現(xiàn)故障提示，調度員或值班人員通過手持電臺或電話通知現(xiàn)場維修人員，現(xiàn)場維護人員收到通知后對現(xiàn)場故障進行確認、處理、跟進。

城市軌道交通信號系統(tǒng)傳統(tǒng)故障監(jiān)測模式主要存在以下不足：

1) 監(jiān)測系統(tǒng)較為封閉。各監(jiān)測系統(tǒng)相互獨立，相關信號系統(tǒng)的數(shù)據(jù)只存活在封閉的生產網絡中，一些用戶 (如使用辦公網的管理人員) 想獲取數(shù)據(jù)，必須到現(xiàn)場工控機上查看。隨著線路增多，及時獲取所有線路實時監(jiān)測數(shù)據(jù)將變得十分困難。

2) 數(shù)據(jù)利用率低。相關數(shù)據(jù) (如報警信息) 的利用場景單一，主要應用于響應故障，故障處理后的數(shù)據(jù)再利用率較低;并且數(shù)據(jù)在磁盤存放的周期較長，一定程度上造成了資源浪費。

3) 現(xiàn)場信息傳遞效率低。監(jiān)測系統(tǒng)信息數(shù)據(jù)的傳遞方向是單方向性的，即用戶從系統(tǒng)獲取信息。故障信息與現(xiàn)場故障處理人員故障處理信息的傳遞通道上多了調度員和值班人員一環(huán)，這消耗了一定的信息傳輸時間，導致信息傳輸成本增大、時效性降低。

4) 對故障處理的指向性不高。傳統(tǒng)監(jiān)測模式下的故障處置流程主要為：值班人員通過在Glink(地鐵內部通信軟件) 生產群上人工填報故障信息，現(xiàn)場維修人員處理后在群上匯報進度以便相關人員跟進。若出現(xiàn)生產群信息較多 (特別是一定時間段多起故障發(fā)生時)的情況，生產群上的其他信息會對跟進某個特定故障的用戶造成干擾。

另外，部分員工故障處理經驗不足，而且又缺乏全面的故障處理指引手冊，這也影響故障的處理效率。

2 信號監(jiān)測系統(tǒng)信息集成化平臺方案

2.1 解決方案

2.1.1 監(jiān)控系統(tǒng)封閉性問題解決方案

通過自主研發(fā)、與廠商合作等方式開發(fā)相關接口，將各監(jiān)控系統(tǒng)的數(shù)據(jù)整合到平臺上，實現(xiàn)生產網內的數(shù)據(jù)實時傳輸?shù)睫k公網絡。用戶無需在本地安裝其他軟件，通過瀏覽器登錄平臺、驗證身份后即可獲取用戶想要的信息，大大提高了數(shù)據(jù)獲取的便捷性。

2.1.2 數(shù)據(jù)利用率過低問題解決方案

在實現(xiàn)在線應急響應的基礎上，平臺能夠實時地、智能地將有價值的數(shù)據(jù)傳送給相關的分析系統(tǒng)或其他應用系統(tǒng)，進行信息的進一步智能分析管理 (如可靠性評估、專家診斷等)。通過對現(xiàn)有設備的可靠度進行評估，找出設備存在的薄弱環(huán)節(jié)，然后有針對性地制定預警機制、維修策略及整改措施來提升設備質量和服務可靠度。

2.1.3 信息傳遞效率過低問題解決方案

1) 方案1。監(jiān)測系統(tǒng)自發(fā)地向用戶推送信息，用戶手機等便捷移動終端可實時接收到新消息。該方案的優(yōu)點是：減少了調度員和值班人員這個中間環(huán)節(jié)，用戶可以更及時地獲取報警信息，降低了傳輸成本。該方案的缺點：對原有系統(tǒng)改動較大；因數(shù)據(jù)量較大，因此有大量的非關鍵信息需要用戶篩選，增加了用戶的操作成本。

2) 方案2。實現(xiàn)信息的多向傳遞。重點關鍵信息主動向用戶推送，用戶亦可從監(jiān)測系統(tǒng)獲取其他想要的信息。該方案的優(yōu)點是：監(jiān)測系統(tǒng)主動將信息推送給用戶；而且已對數(shù)據(jù)做好分類，免去用戶篩選信息的過程，提高了數(shù)據(jù)的時效性。該方案的缺點是：需前期制定相關信息推送規(guī)則；因數(shù)據(jù)處理量較大，因此對服務器的處理性能要求較高。

方案1和方案2都是監(jiān)測系統(tǒng)主動向用戶推送信息，使得信息源就在用戶身邊， 用戶可以非常方便地獲取到信息。綜合考慮，方案2不過多地改變原有模式，而是在原有的成熟模式下進行優(yōu)化，因此更貼合實際工作需求，有助于提高企業(yè)效益。

接送端通過辦公網將串口或網絡接口收到的數(shù)據(jù)上傳到服務器，考慮到實時數(shù)據(jù)量較大，服務器的數(shù)據(jù)處理速度可能跟不上傳輸速度，因此需要設置一定的緩存機制。服務器端一般已有一些成熟的緩存機制(如Redis等)，通過多線程并發(fā)建立數(shù)據(jù)隊列線程及處理線程， 利用本地內存或磁盤做緩存，以避免傳輸過程中的數(shù)據(jù)丟失。

2.1.4 故障處置指向性過低問題解決方案

通過研究發(fā)現(xiàn)：可與移動通信軟件建立接口，實現(xiàn)故障自動推送；可通過優(yōu)化人員配置提高信息傳達準確度。本文提出了故障處理分類跟進的新思路：在對話窗口的每條故障皆為一個指令，點擊指令可跳轉到相應的對話框中；每個指令對話框只討論該故障，降低了無關信息對技術人員判斷故障的干擾；針對每個故障會自動推送相應的故障處理指南，供處理故障的技術人員參考；采集相關故障處理進度信息。優(yōu)化后的故障分類跟進處理方式如圖1所示。

圖1 優(yōu)化后的故障分類跟進處理方式示意圖

2.2 關鍵技術方案

本次研究的關鍵技術方案包括跨網通信、在線監(jiān)測、推送方式、多終端展示和應急等方案。

1 )跨網通信。針對不同線路特征，不同網絡間數(shù)據(jù)的傳輸方式主要包括串口通信和HTTP(超文本傳輸協(xié)議)通信。

(1) 串口通信。對于一些版本較舊、擴展性較差的系統(tǒng)，升級整套信號系統(tǒng)的成本巨大，因此可以另外開發(fā)一套發(fā)送端程序，用以監(jiān)測本地數(shù)據(jù)變化，當有新增數(shù)據(jù)通過串口時將該數(shù)據(jù)傳送給接受端程序。

(2) HTTP通信。對于一些擴展性較高的系統(tǒng)，通過合作開發(fā)網絡接口，使接收端程序能夠直接訪問對應的IP及端口，從而獲取數(shù)據(jù)。

2) 在線監(jiān)測技術方案。用戶想通過客戶端實時獲取數(shù)據(jù)，需要與服務端建立連接，通過客戶端與服務端互相通信以獲得最新的數(shù)據(jù)?？蛻舳伺c服務器網絡通信的技術目前主流的有AJAX和WebSocket。WebSocket是一種長連接，對一些只需請求一次的操作，保持長連接會占用資源；對服務器的配置要求較高，不支持舊版本瀏覽器。AJAX作為一種成熟的技術，有較多框架支持，相對更加通用，可以進行與服務器異步通信；在請求數(shù)據(jù)的時候不刷新整個頁面，可進行其他操作；數(shù)據(jù)返回后只改變局部內容。因此，本項目在線監(jiān)測系統(tǒng)頁面客戶端與服務器選擇AJAX輪詢的方式進行通信。

3) 推送方式技術方案。用戶獲取信息的主要載體是手機和郵箱?；诂F(xiàn)有的平臺，研究將服務器與郵箱接口、手機APP程序接口進行對接，當服務器接收到新數(shù)據(jù)時，通過相關索引找到相應的聯(lián)系人及聯(lián)系方式，然后進行推送。采用這種推送方式可實現(xiàn)外網實時接收故障信息。

4) 多終端展示技術方案。在線實時監(jiān)測系統(tǒng)的客戶端可通過 CSS3的 Media Query和頁面的 Viewport實現(xiàn)不同尺寸的終端展示不同的布局樣式。一些界面交互控制可通過Javascript腳本進行操作。數(shù)據(jù)圖表采用Html5的Canvas畫布實現(xiàn)取代Flash，通過操作Canvas可實現(xiàn)響應的縮放。

5) 應急技術方案。故障應急處置是現(xiàn)場最有意義的一環(huán)，是最能改善企業(yè)效益的關鍵點?？赏ㄟ^以下方式優(yōu)化原有模式的故障處理流程。

(1) 加強故障的指向性。監(jiān)測系統(tǒng)對故障類型進行關聯(lián)索引，當收到相應故障信息時，除了推送故障信息之外，同時推送相應故障的處理指南，方便依照規(guī)范處理故障。

(2) 減少無關信息干擾。平臺通過Glink的開發(fā)指令功能在Glink群上為每個故障設置一個指令，點擊相應的指令則跳轉到相應故障的對話框，每個指令下只回復相應故障的信息。

3 應用情況及分析

本文所研究的城市軌道交通信號系統(tǒng)在線監(jiān)測信息集成化平臺目前已應用于廣州地鐵5號線，試運行至今效果明顯：故障數(shù)據(jù)及列車狀態(tài)等信息能在界面上實時正確地顯示；報警信息能及時推送到用戶終端上，有效提高了技術人員與管理人員對現(xiàn)場情況的把控；現(xiàn)場維修人員也能及時收到故障處理指南推送，提升了故障處理的時效性。本研究改善優(yōu)化了原有的信號系統(tǒng)監(jiān)測模式， 平臺具有靈活性、擴展性等特點，目前處于示范應用階段，平臺將陸續(xù)接入廣州地鐵4、6、7號線的數(shù)據(jù)。

平臺的科學性、先進性和創(chuàng)新性主要體現(xiàn)在：①可通過PC、平板、手機等終端實時獲取信號系統(tǒng)的相關信息；②能夠采集整合不同線路信號系統(tǒng)的故障信息，典型關鍵設備的故障信息采集準確率達到92%以上；③故障信息推送至用戶手機和郵箱，用戶可實時接收到最新的故障通知；④推送故障信息的同時推送故障處理指南，并針對每個故障建立了相應的故障對話指令，便于跟蹤故障情況。

4 結語

本研究解決了城市軌道交通信號系統(tǒng)各監(jiān)測系統(tǒng)的封閉性問題，實現(xiàn)了管理信息共享，提高了各級組織內部的有效協(xié)作性和快速反應能力。通過多接口、多線程、多終端等技術實現(xiàn)了主動向用戶推送故障信息的監(jiān)測新模式，減少了用戶的信息篩選時間，優(yōu)化了人員配置，提高了信息傳送準確度。利用大數(shù)據(jù)技術可開展故障點分析、設備可靠性評估、優(yōu)化應急處置等研究。平臺目前仍處于不斷優(yōu)化調整階段，數(shù)據(jù)源龐大，開發(fā)難度高，因此實現(xiàn)城市軌道信號系統(tǒng)在線監(jiān)測平臺化需要各信號系統(tǒng)廠商積極配合，以不斷創(chuàng)新監(jiān)測模式。