地鐵綜合監(jiān)控系統(tǒng)數(shù)據(jù)信息量及服務器配置方式討論

楊洪

（西安市地下鐵道有限責任公司運營分公司，陜西西安 710043）

地鐵綜合監(jiān)控系統(tǒng)數(shù)據(jù)信息量及服務器配置方式討論

楊洪

（西安市地下鐵道有限責任公司運營分公司，陜西西安 710043）

本文主要在論述地鐵綜合監(jiān)控系統(tǒng)理論與實際信息數(shù)據(jù)量的基礎上，分析西安地鐵2號線數(shù)據(jù)存儲處理典型問題，并對綜合監(jiān)控系統(tǒng)中央級以及車站級服務器配置方式進行討論。綜合監(jiān)控系統(tǒng)信息傳輸，信息存儲處理必須通過科學的設計，以及現(xiàn)代先進通信傳輸技術的應用，有效提高系統(tǒng)數(shù)據(jù)信息轉(zhuǎn)發(fā)傳輸?shù)膶崟r性、可靠性和準確性，確保地鐵運營、監(jiān)控、維護等能夠達到預期目標。

綜合監(jiān)控系統(tǒng) 信息數(shù)據(jù)存儲處理能力 中央級服務器 站點式分布服務器設置

1 綜合監(jiān)控系統(tǒng)概述

西安地鐵2號線（簡稱地鐵2號線）綜合監(jiān)控系統(tǒng)是一個具有多功能性的信息集成互聯(lián)系統(tǒng)。綜合監(jiān)控系統(tǒng)采用集成、互聯(lián)的方式將地鐵2號線各關聯(lián)子系統(tǒng)聯(lián)接成一個有機的整體，形成統(tǒng)一的監(jiān)控硬件平臺和軟件平臺，從而實現(xiàn)對地鐵主要弱電設備的集中監(jiān)控和管理功能，實現(xiàn)對列車運行情況和客流統(tǒng)計數(shù)據(jù)的關聯(lián)監(jiān)視功能，最終實現(xiàn)相關各系統(tǒng)之間的信息共享和協(xié)調(diào)互動功能。綜合監(jiān)控系統(tǒng)使控制中心OCC通過綜合監(jiān)控軟件平臺完成地鐵2號線各關聯(lián)系統(tǒng)設備的信息的互聯(lián)互通，大大提高了故障的處理效率，實現(xiàn)了跨專業(yè)的（各子系統(tǒng)）的信息共享和聯(lián)動，為西安地鐵2號線自動化調(diào)度管理提供了重要依據(jù)。

西安地鐵2號線綜合監(jiān)控系統(tǒng)集成的主要接口系統(tǒng)有電力監(jiān)控系統(tǒng)（PSCADA）；環(huán)境與設備監(jiān)控系統(tǒng)（BAS）、火災自動報警系統(tǒng)（FAS）、屏蔽門（PSD）；互聯(lián)系統(tǒng)有：信號系統(tǒng)（SIG）、自動售檢票系統(tǒng)（AFC）、廣播系統(tǒng)（PA）、閉路電視監(jiān)視系統(tǒng)（CCTV）、乘客信息系統(tǒng)（PIS）、綜合網(wǎng)絡管理系統(tǒng)（TNMS）、時鐘系統(tǒng)（CLK）。綜合監(jiān)控系統(tǒng)（ISCS）的構建，為西安地鐵2號線安全、可靠、經(jīng)濟、適用的運營提供了重要技術保障（如圖1，2）。

圖1 綜合監(jiān)控系統(tǒng)集成與互聯(lián)系統(tǒng)圖

2 綜合監(jiān)控系統(tǒng)數(shù)據(jù)量的計算

2.1 綜合監(jiān)控系統(tǒng)數(shù)據(jù)量的理論計算

綜合監(jiān)控系統(tǒng)網(wǎng)絡通常分為骨干網(wǎng)和局域網(wǎng)兩個層次。骨干網(wǎng)是連接車站和中央的主干傳輸網(wǎng)絡，車站和車輛段的站級綜合監(jiān)控系統(tǒng)則由局域網(wǎng)構成，各局域網(wǎng)通過骨干網(wǎng)有機地形成整體，以滿足系統(tǒng)的需求。綜合監(jiān)控系統(tǒng)的骨干網(wǎng)上傳輸?shù)臄?shù)據(jù)包括各接入系統(tǒng)用于監(jiān)控和維修管理的實時數(shù)據(jù)，這些數(shù)據(jù)按類型可分為開關量（I/O數(shù)據(jù)）、模擬量和SOE量。由于綜合監(jiān)控系統(tǒng)的監(jiān)控主要以I/O數(shù)據(jù)為主，模擬量和SOE量較少，對骨干網(wǎng)的帶寬要求將基于實時監(jiān)控的I/O數(shù)據(jù)量和維修數(shù)據(jù)量來估算。

綜合監(jiān)控系統(tǒng)傳輸數(shù)據(jù)以上行為主，下行的命令數(shù)據(jù)很少可以忽略不計。系統(tǒng)采用基于TCP/IP的以太網(wǎng)，TCP/IP是一組協(xié)議的總稱，IP協(xié)議是包括TCP、UDP、FTP、SMTP等等，其中TCP適合文件傳輸，但不適合于實時數(shù)據(jù)傳輸，工業(yè)控制系統(tǒng)大多采用UDP協(xié)議。

以太網(wǎng)每個數(shù)據(jù)幀前導碼8個字節(jié)，目的地址和源地址各6字節(jié)，數(shù)據(jù)長度2個字節(jié)，幀校驗序列4個字節(jié)，數(shù)據(jù)46-1500個字節(jié)。必須的幀頭尾開銷共26字節(jié)。

IP協(xié)議需要20個字節(jié)的固定開銷，采用UDP協(xié)議需要12個字節(jié)的固定開銷。

對于I/O數(shù)據(jù)，每個點按2字節(jié)計算，每個信息包承載10個點，加上各層封裝的開銷，則每個包長度為：

L1=26+20+12+10×2=78byte=624bit

對于模擬量數(shù)據(jù)，每個點按10字節(jié)計算，每個信息包承載10個點，加上各層封裝的開銷，則每個包長度為：

L2=26+20+12+10×10=158byte=1264bit

對于SOE量數(shù)據(jù)，每個點按15字節(jié)計算，每個信息包承載10個點，加上各層封裝的開銷，則每個包長度為：

L3=26+20+12+15×10=208byte=1664bit

圖2 綜合監(jiān)控系統(tǒng)集成與互聯(lián)的區(qū)別

西安地鐵2號線一期共17座車站，1座車輛段，2座主變共20座站點。綜合監(jiān)控系統(tǒng)總監(jiān)控點數(shù)按34萬點計算。其中按數(shù)字量約占總監(jiān)控點數(shù)的85%，SOE量約占總數(shù)的12%，模擬量約占總數(shù)的3%計算。根據(jù)集中分布式監(jiān)控數(shù)據(jù)的傳輸網(wǎng)鏈路容量估算公式：監(jiān)控數(shù)據(jù)的傳輸網(wǎng)鏈路容量C=綜合監(jiān)控系統(tǒng)總監(jiān)控點數(shù)×信息包長度/信息單向傳遞延時。

則數(shù)字量傳輸鏈路容量為：

C1=（340000×0.85÷10）×624÷0.5=36.1Mbps

則模擬量傳輸鏈路容量為：

C2=（340000×0.03÷10）×1264÷0.5=2.6Mbps

則SOE量傳輸鏈路容量為：

C3=（340000×0.12÷10）×1664÷0.5=13.4Mbps

此外由于綜合監(jiān)控系統(tǒng)傳輸數(shù)據(jù)還包括各相關系統(tǒng)維修信息應以事件觸發(fā)的方式主動上傳至維修中心，單個子系統(tǒng)的維修信息量不會超過5Mbps，同時考慮到大部分設備同時發(fā)生故障的可能性很小，因此各集成系統(tǒng)維修信息所需傳輸網(wǎng)鏈路容量c約為30Mbps。

綜合監(jiān)控系統(tǒng)傳輸鏈路總?cè)萘緾=C1+C2+C3+c=82.1Mbps（監(jiān)控數(shù)據(jù)鏈路容量C+維修信息所需鏈路容量c）。

2.2 西安地鐵2號線綜合監(jiān)控數(shù)據(jù)量統(tǒng)計

表1 綜合監(jiān)控系統(tǒng)站級服務器典型車站數(shù)據(jù)點表類別

西安地鐵2號線綜合監(jiān)控系統(tǒng)中（典型車站服務器）各接口子系統(tǒng)點表信息如表1：

西安地鐵2號線綜合監(jiān)控系統(tǒng)中（典型車站服務器）各接口系統(tǒng)數(shù)據(jù)點數(shù)量如表2：

從上述表中可以看出，按照地鐵運營生產(chǎn)的實際需求，西安地鐵2號線綜合監(jiān)控系統(tǒng)車站級服務器數(shù)據(jù)庫數(shù)據(jù)點具有子系統(tǒng)分類多，設備信息點詳細，數(shù)據(jù)量龐大等特點。

西安地鐵2號線中央級綜合監(jiān)控系統(tǒng)單日數(shù)據(jù)信息量統(tǒng)計表如表3：

表3數(shù)據(jù)表明（上述數(shù)據(jù)量為隨機提取7日內(nèi)每日事件數(shù)據(jù)總量），地鐵2號線目前日數(shù)據(jù)信息量平均約為162139條。

2.3 綜合監(jiān)控系統(tǒng)數(shù)據(jù)處理能力的主要問題

按照上述綜合監(jiān)控系統(tǒng)數(shù)據(jù)信息量的計算與實際的數(shù)據(jù)量統(tǒng)計分析，地鐵2號線采用通信系統(tǒng)提供的獨立信道（100Mbps）能夠滿足地鐵2號線的信息傳輸需求。但綜合監(jiān)控系統(tǒng)功能的實現(xiàn)，一方面依賴于信息傳輸通道，另一方面取決于中央級以及車站級服務器和相關系統(tǒng)硬件，軟件設備的信息存儲處理能力，完成如故障信息報警，設備運行狀態(tài)，趨勢圖等數(shù)據(jù)信息統(tǒng)計分析功能。按照現(xiàn)有的地鐵2號線數(shù)據(jù)信息量進行計算，地鐵2號線中央級綜合監(jiān)控系統(tǒng)磁盤陣列（容量為2.4T）實際存儲周期為20天左右，設計存儲周期為3個月。故中央以及車站級綜合監(jiān)控服務器數(shù)據(jù)信息存儲處理能力可能因數(shù)據(jù)量過大成為全線綜合監(jiān)控系統(tǒng)數(shù)據(jù)傳輸、信息處理的瓶頸。目前西安地鐵因此類問題出現(xiàn)的典型問題為：中央級或車站級綜合監(jiān)控服務器事件信息丟失問題。

表2 綜合監(jiān)控系統(tǒng)站級服務器典型車站（行政中心站）數(shù)據(jù)點數(shù)量統(tǒng)計

表3 綜合監(jiān)控系統(tǒng)日事件信息總量統(tǒng)計表

中央級或車站級綜合監(jiān)控服務器事件丟失是指綜合監(jiān)控系統(tǒng)服務器（中央級，車站級）由于數(shù)據(jù)存儲量超過系統(tǒng)軟件設定的上限值（依據(jù)硬盤容量設定）而數(shù)據(jù)更新動作發(fā)生意外使綜合監(jiān)控系統(tǒng)所集成互聯(lián)系統(tǒng)的數(shù)據(jù)信息只存儲于車站級服務器內(nèi)存中，無法進入中央級調(diào)度工作站，車站級工作站信息更新，出現(xiàn)工作站信息刷新不顯示、不更新的故障現(xiàn)象。因車站綜合監(jiān)控服務器內(nèi)存只能存儲2個小時的接口系統(tǒng)的數(shù)據(jù)信息，故信息事件丟失故障會出現(xiàn)兩種故障現(xiàn)象，其一為在2個小時內(nèi)恢復數(shù)據(jù)更新動作，中央級以及車站級綜合監(jiān)控工作站能夠恢復之前所有未刷新信息的顯示。其二為在2個小時內(nèi)未恢復數(shù)據(jù)更新動作，中央級以及車站級綜合監(jiān)控工作將永久丟失部分數(shù)據(jù)信息無法恢復。需進一步提高中央級以及車站級綜合監(jiān)控系統(tǒng)服務器數(shù)據(jù)傳輸、數(shù)據(jù)存儲處理能力，滿足地鐵運營的實際需求。

3 綜合監(jiān)控系統(tǒng)服務器配置討論

因綜合監(jiān)控系統(tǒng)中央級服務器，車站級服務器主要承擔車站機電設備的數(shù)據(jù)傳輸、數(shù)據(jù)存儲處理任務。故本次對中央級與車站級綜合監(jiān)控系統(tǒng)服務器配置進行討論。

3.1 站點分布式服務器設置

所謂站點分布式設置方案就是指綜合監(jiān)控系統(tǒng)在各站點（含控制中心）皆設置實時服務器及分布式歷史數(shù)據(jù)庫，各站點被監(jiān)控對象的實時監(jiān)控數(shù)據(jù)都上傳到相應站點的服務器中進行處理，并在本地歷史數(shù)據(jù)庫中進行存儲和管理。在日常工作期間，如果車站工作站需要查詢本區(qū)域范圍內(nèi)的數(shù)據(jù)，則只在本地調(diào)取相應區(qū)域數(shù)據(jù)庫中的相關數(shù)據(jù)即可。如果網(wǎng)絡上某個節(jié)點上的綜合監(jiān)控系統(tǒng)需要查詢其它站點范圍內(nèi)的相關數(shù)據(jù)，則只須通過網(wǎng)絡調(diào)取相應站點數(shù)據(jù)庫中的相關數(shù)據(jù)即可。

控制中心作為一個特殊站點考慮，控制中心的實時服務器與車站服務器采用相同的配置。控制中心服務器負責對綜合監(jiān)控各互聯(lián)系統(tǒng)的數(shù)據(jù)采集、報警分析、運算控制、事件記錄等事務，并承擔互聯(lián)系統(tǒng)信息的存儲和管理。此外，由于電力監(jiān)控系統(tǒng)對實時響應要求較高，且站間聯(lián)系較為緊密，因此將PSCADA數(shù)據(jù)接入控制中心服務器，各車站和車輛段接入的變電所綜合自動化系統(tǒng)監(jiān)控信息也實時傳送至控制中心服務器進行集中處理、存儲和管理，有利于對全線的變電所綜合自動化系統(tǒng)信息的調(diào)用訪問和顯示，也便于控制中心電力調(diào)度人員對整個地鐵供電系統(tǒng)進行統(tǒng)一調(diào)度。另外，為方便運營部門進行全線歷史數(shù)據(jù)的統(tǒng)一集中管理，也可以在網(wǎng)絡非繁忙期間，在指定時間內(nèi)，將各站服務器存儲的數(shù)據(jù)通過骨干網(wǎng)一次性匯總上傳到中央服務器進行鏡像備份。

站點分布式服務器設置方案具有如下特點：

（1）適合分布式的管理與控制。實現(xiàn)全局數(shù)據(jù)在本地錄入、查詢、維修，這時由于計算機資源靠近用戶，可以降低通信代價，在涉及其它站點數(shù)據(jù)庫中的數(shù)據(jù)只是少量的情況下，可以大大減少骨干網(wǎng)絡上的信息傳輸量，此外，存取的數(shù)據(jù)在本地數(shù)據(jù)庫中，在一定條件下提高了響應速度。

（2）系統(tǒng)經(jīng)濟，可靠性高，可用性好。與一個大型計算機支持一個大型的集中式數(shù)據(jù)庫再加一些本地和遠程終端相比，由超級微型計算機或超級小型計算機支持的分布式數(shù)據(jù)庫系統(tǒng)往往具有更高的性價比、實施靈活性和較高可用性。由于數(shù)據(jù)分布在多個場地并有許多復制數(shù)據(jù)，在個別場地或個別通信鏈路發(fā)生故障時，不致于導致整個系統(tǒng)的崩潰，而且系統(tǒng)的局部故障不會引起全局失控。

（3）可擴展性好，易于擴充。與站點分布式服務器配置方案所匹配的分布式數(shù)據(jù)庫技術可以非常方便的支撐對系統(tǒng)的擴展，可增加站點的情況下，通過增加分布式數(shù)據(jù)庫的辦法，迅速擴充已有的分布式數(shù)據(jù)庫系統(tǒng)。這比重建一個大型數(shù)據(jù)庫系統(tǒng)要簡單，且節(jié)省了修改軟件所需要的時間和費用。

（4）采用站點分布式設置的實時服務器，僅負擔本站（控制中心）所轄范圍內(nèi)數(shù)據(jù)處理級存儲業(yè)務，服務器負荷適中，且對傳輸網(wǎng)絡的依賴性較小。由多個分布式服務器及小型數(shù)據(jù)庫構成的系統(tǒng)對服務器性能要求較低，且有利于降低對系統(tǒng)服務器及數(shù)據(jù)庫的投資。但該方案若采用傳統(tǒng)的直接存儲技術則需要所有站點服務器具備足夠的存儲容量，將增加了重復的存儲成本投入。

3.2 中央集中與站點分布相結(jié)合的服務器設置

中央集中與站點分布式相結(jié)合的配置方案是指在各車站設置實時服務器，主要用于監(jiān)控，負擔本站所轄范圍內(nèi)的數(shù)據(jù)采集、報警分析、運算控制、事件記錄等事務。車站不設歷史數(shù)據(jù)庫，數(shù)據(jù)以文件形式存儲，歷史數(shù)據(jù)的存儲、整理、統(tǒng)計、分析等數(shù)據(jù)管理工作不在車站級實現(xiàn)。在中央設置全局的實時和歷史服務器，全線所有站點的被監(jiān)控對象的實時監(jiān)控數(shù)據(jù)都通過綜合監(jiān)控系統(tǒng)骨干網(wǎng)傳輸傳送到中央來進行集中處理、存儲和管理。中央實時服務器性能要求需高于車站實時服務器。如果某個站點需要查詢相關數(shù)據(jù)，則必須通過綜合監(jiān)控系統(tǒng)主干網(wǎng)絡來遠程調(diào)取中央全局歷史數(shù)據(jù)庫中的相關數(shù)據(jù)，傳輸網(wǎng)絡的依賴性較大。該服務器配置方式有利于數(shù)據(jù)的多重保護和歷史數(shù)據(jù)的集中管理，但系統(tǒng)投資較大，目前地鐵建設較多采用此種方式。

綜上所述，對于地鐵線路長站點多以及綜合監(jiān)控系統(tǒng)接口系統(tǒng)多，接口數(shù)據(jù)量較大的情況，宜采用站點分布式服務器配置方案以緩解服務器數(shù)據(jù)存儲處理符合，提高綜合監(jiān)控系統(tǒng)運行效率。

4 結(jié)束語

地鐵2號線綜合監(jiān)控系統(tǒng)數(shù)據(jù)的高效轉(zhuǎn)發(fā)共享是地鐵綜合監(jiān)控自動化的重要組成部分，對地鐵安全可靠、節(jié)能經(jīng)濟運營有著非常重要的影響。綜合監(jiān)控系統(tǒng)信息傳輸，信息存儲處理必須通過科學的設計，以及現(xiàn)代先進通信傳輸技術的應用，有效提高系統(tǒng)數(shù)據(jù)信息轉(zhuǎn)發(fā)傳輸?shù)膶崟r性、可靠性和準確性，確保地鐵運營、監(jiān)控、維護等能夠達到預期目標。

［1］徐忠.地鐵綜合監(jiān)控系統(tǒng)中的數(shù)據(jù)交互共享方案研究.信息安全與技術.2012年3月.