許華陽(yáng) 李潤(rùn)錦

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

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

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

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

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

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

2) 數(shù)據(jù)利用率低。相關(guān)數(shù)據(jù) (如報(bào)警信息) 的利用場(chǎng)景單一，主要應(yīng)用于響應(yīng)故障，故障處理后的數(shù)據(jù)再利用率較低;并且數(shù)據(jù)在磁盤(pán)存放的周期較長(zhǎng)，一定程度上造成了資源浪費(fèi)。

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

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

另外，部分員工故障處理經(jīng)驗(yàn)不足，而且又缺乏全面的故障處理指引手冊(cè)，這也影響故障的處理效率。

2 信號(hào)監(jiān)測(cè)系統(tǒng)信息集成化平臺(tái)方案

2.1 解決方案

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

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

2.1.2 數(shù)據(jù)利用率過(guò)低問(wèn)題解決方案

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

2.1.3 信息傳遞效率過(guò)低問(wèn)題解決方案

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

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

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

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

2.1.4 故障處置指向性過(guò)低問(wèn)題解決方案

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

圖1 優(yōu)化后的故障分類(lèi)跟進(jìn)處理方式示意圖

2.2 關(guān)鍵技術(shù)方案

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

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

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

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

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

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

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

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

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

(2) 減少無(wú)關(guān)信息干擾。平臺(tái)通過(guò)Glink的開(kāi)發(fā)指令功能在Glink群上為每個(gè)故障設(shè)置一個(gè)指令，點(diǎn)擊相應(yīng)的指令則跳轉(zhuǎn)到相應(yīng)故障的對(duì)話框，每個(gè)指令下只回復(fù)相應(yīng)故障的信息。

3 應(yīng)用情況及分析

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

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

4 結(jié)語(yǔ)

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