基于綜合監(jiān)控系統(tǒng)的線網(wǎng)指揮中心構(gòu)建方案研究

楊承東 徐余明

(中鐵第四勘察設(shè)計院集團有限公司，430063，武漢∥第一作者，高級工程師)

城市軌道交通線網(wǎng)指揮中心(TCC)是近幾年發(fā)展起來的新興系統(tǒng)之一，位于運營管理系統(tǒng)的最高層，具有全線網(wǎng)監(jiān)控以及多線路運營協(xié)調(diào)、應(yīng)急指揮、信息共享、維護指導(dǎo)等功能。但是，由于系統(tǒng)體系、數(shù)據(jù)接口等的差異，使得TCC系統(tǒng)與底層數(shù)據(jù)的接駁變得比較困難，系統(tǒng)的構(gòu)建存在諸多問題。

基于綜合監(jiān)控系統(tǒng)的TCC構(gòu)建方案是指:通過各線路的綜合監(jiān)控系統(tǒng)將多個機電系統(tǒng)集成、互聯(lián)，實現(xiàn)了各系統(tǒng)信息匯集、協(xié)議統(tǒng)一;通過TCC與綜合監(jiān)控系統(tǒng)的連接，既實現(xiàn)了傳遞多系統(tǒng)的監(jiān)控信息的目的，又起到了簡化接口的作用;同時還可進一步實現(xiàn)綜合監(jiān)控系統(tǒng)與TCC共同管理底層數(shù)據(jù)的目的，實現(xiàn)互為備份。

1 綜合監(jiān)控系統(tǒng)數(shù)據(jù)采集的基本方式

一般來說，系統(tǒng)集成需要解決的首要問題是，如何處理集成系統(tǒng)與被集成子系統(tǒng)間基于不同的數(shù)據(jù)傳輸協(xié)議的數(shù)據(jù)通信問題。只有相互間的通信機制已經(jīng)建立，才有可能實現(xiàn)系統(tǒng)間信息的數(shù)據(jù)融合、數(shù)據(jù)共享以及數(shù)據(jù)綜合應(yīng)用。目前系統(tǒng)集成技術(shù)大致分為以下幾種:

(1)采用統(tǒng)一通信協(xié)議實現(xiàn)系統(tǒng)集成。這種集成方式要求集成系統(tǒng)和被集成各子系統(tǒng)必須全部采用同一種通信協(xié)議，以實現(xiàn)不同系統(tǒng)之間的數(shù)據(jù)交互。

(2)采用協(xié)議轉(zhuǎn)換的方式實現(xiàn)系統(tǒng)集成。一般可通過兩種方式實現(xiàn)協(xié)議轉(zhuǎn)換的功能:一種是利用硬件接口設(shè)備實現(xiàn)協(xié)議轉(zhuǎn)換功能。如通過前端處理器作為集成平臺的網(wǎng)關(guān)進行協(xié)議轉(zhuǎn)換。另一種是通過實時服務(wù)器軟件實現(xiàn)協(xié)議轉(zhuǎn)換功能。這種方式可減少硬件接口設(shè)備，但需額外增加服務(wù)器的接口通信功能，接口通信軟件大幅占用實時服務(wù)器CPU、內(nèi)存等系統(tǒng)資源，在大型綜合監(jiān)控系統(tǒng)中較少使用。

城市軌道交通的各機電系統(tǒng)，由于其專業(yè)特性不同，其軟件系統(tǒng)和硬件設(shè)備一般來自不同的供貨商，系統(tǒng)異構(gòu)現(xiàn)象普遍存在，因此很難實現(xiàn)理想化通信協(xié)議的統(tǒng)一。由此可見，實現(xiàn)集成系統(tǒng)間的協(xié)議轉(zhuǎn)換在所難免。

2 綜合監(jiān)控系統(tǒng)的數(shù)據(jù)采集和控制方式

國內(nèi)城市軌道交通綜合監(jiān)控系統(tǒng)一般采用以環(huán)調(diào)、電調(diào)為核心的集成方案。綜合監(jiān)控系統(tǒng)集成和互聯(lián)的各系統(tǒng)內(nèi)部通信網(wǎng)絡(luò)基本上都是基于TCP/IP的以太網(wǎng)絡(luò)，但內(nèi)部的通信協(xié)議只適用于自身系統(tǒng)。如果只單純地建立集成和互聯(lián)系統(tǒng)與綜合監(jiān)控系統(tǒng)在物理上的連接，就存在部分系統(tǒng)的突發(fā)性非預(yù)期網(wǎng)絡(luò)報文對綜合監(jiān)控系統(tǒng)網(wǎng)絡(luò)產(chǎn)生直接沖擊的可能。例如:在某系統(tǒng)網(wǎng)絡(luò)異常的情況下(包括人為攻擊)，大量的非預(yù)期的網(wǎng)絡(luò)報文會瞬間增加系統(tǒng)網(wǎng)絡(luò)負載，甚至導(dǎo)致整個系統(tǒng)和網(wǎng)絡(luò)的癱瘓。因此，需配置一套硬件設(shè)備對接入綜合監(jiān)控系統(tǒng)的各子系統(tǒng)進行有效隔離，防止突發(fā)性網(wǎng)絡(luò)報文對綜合監(jiān)控系統(tǒng)的影響，并通過協(xié)議轉(zhuǎn)換機制，把對方系統(tǒng)的異構(gòu)數(shù)據(jù)翻譯成自身系統(tǒng)能夠識別的數(shù)據(jù)，然后進入自身系統(tǒng)進行運算和存儲。

在綜合監(jiān)控系統(tǒng)的架構(gòu)中，前端處理器(FEP)作為特有的硬件設(shè)備，用于管理綜合監(jiān)控系統(tǒng)與各子系統(tǒng)的硬件接口，具有轉(zhuǎn)換硬件接口、軟件通信協(xié)議，有效地把綜合監(jiān)控系統(tǒng)與各子系統(tǒng)的數(shù)據(jù)進行隔離的作用。綜合監(jiān)控系統(tǒng)也通過FEP獲得各子系統(tǒng)的實時數(shù)據(jù)，同時，也可高效地通過FEP完成發(fā)往各子系統(tǒng)的數(shù)據(jù)和命令。

當采用FEP硬件時，綜合監(jiān)控系統(tǒng)獲取各子系統(tǒng)數(shù)據(jù)流的端點是車站FEP。無論是控制中心還是車站，所有的外部數(shù)據(jù)的起點均是車站FEP，控制中心和車站下達的命令，其終點也是車站FEP。這種基于硬件的協(xié)議轉(zhuǎn)換和控制方式可有效減少數(shù)據(jù)處理環(huán)節(jié)，提高數(shù)據(jù)的實時性和一致性，也是目前國內(nèi)大部分的綜合監(jiān)控系統(tǒng)集成商所采用的方式。綜合監(jiān)控系統(tǒng)的采集數(shù)據(jù)和控制方式如圖1所示。

當綜合監(jiān)控系統(tǒng)通過FEP完成各子系統(tǒng)的協(xié)議轉(zhuǎn)換后，各子系統(tǒng)的數(shù)據(jù)將全部轉(zhuǎn)變?yōu)榫C合監(jiān)控系統(tǒng)的內(nèi)部數(shù)據(jù)，在綜合監(jiān)控網(wǎng)絡(luò)中傳輸。這些內(nèi)部數(shù)據(jù)的傳輸機制是由綜合監(jiān)控系統(tǒng)廠商根據(jù)自身軟件平臺的特點優(yōu)化后定義的，與各子系統(tǒng)內(nèi)部通信協(xié)議一樣，同樣不具備通用性，只能適用于單一的綜合監(jiān)控系統(tǒng)的軟件體系。目前國內(nèi)綜合監(jiān)控系統(tǒng)與各接入子系統(tǒng)的通信協(xié)議一般采用基于TCP/IP的ModBus或IEC 104通信協(xié)議。協(xié)議轉(zhuǎn)換的軟件包定制安裝在綜合監(jiān)控系統(tǒng)的FEP上。

圖1 綜合監(jiān)控系統(tǒng)的采集數(shù)據(jù)和控制方式

3 基于綜合監(jiān)控系統(tǒng)的TCC集成方案

根據(jù)綜合監(jiān)控系統(tǒng)數(shù)據(jù)采集的特點，基于綜合監(jiān)控系統(tǒng)的TCC集成方案大致可分為層級化和扁平化兩種組建方式。

3.1 層級化方案

層級化方案是目前國內(nèi)TCC普遍采用的集成方案，監(jiān)控數(shù)據(jù)按系統(tǒng)架構(gòu)的層級關(guān)系進行匯集，數(shù)據(jù)采集的起點在車站FEP，終點在TCC。數(shù)據(jù)流匯集過程為“車站 FEP—綜合監(jiān)控系統(tǒng)中央級—TCC”。各條線路的綜合監(jiān)控系統(tǒng)中央級作為TCC數(shù)據(jù)收集和處理的核心，在收集全線數(shù)據(jù)后，優(yōu)化并轉(zhuǎn)發(fā)給TCC，同時也接收TCC的控制命令轉(zhuǎn)發(fā)到各車站FEP，以完成對現(xiàn)場設(shè)備的控制。TCC層級化數(shù)據(jù)采集控制方式如圖2所示。

圖2 TCC層級化數(shù)據(jù)采集控制方式

在較完整的城市軌道交通線網(wǎng)中，接入TCC的數(shù)據(jù)量約在300萬點左右。數(shù)據(jù)點規(guī)模對于大部分監(jiān)控系統(tǒng)的軟件平臺的影響較小，系統(tǒng)規(guī)模主要受硬件配置的制約。TCC的硬件配置一般可分為兩種方式:采用一套服務(wù)器集中處理全部線路數(shù)據(jù);分別按線路提供冗余的實時服務(wù)器，服務(wù)器間通過集群技術(shù)實現(xiàn)數(shù)據(jù)的互訪。

另外，由于TCC與綜合監(jiān)控系統(tǒng)中異構(gòu)平臺的存在，TCC的實時數(shù)據(jù)庫一般不允許數(shù)據(jù)的直接寫入，須通過“通信前置機”對數(shù)據(jù)進行轉(zhuǎn)換和處理。通信前置機的工作原理與FEP類似，所不同的是，由于需處理的全線數(shù)據(jù)的數(shù)據(jù)量極為龐大，一般只能由高性能的服務(wù)器設(shè)備替代。在TCC系統(tǒng)中，實時服務(wù)器只負責數(shù)據(jù)應(yīng)用的處理，不負責數(shù)據(jù)的采集工作，這樣可以提高系統(tǒng)的實時性和數(shù)據(jù)的可靠性。TCC層級化系統(tǒng)構(gòu)成如圖3所示。

圖3 TCC層級化系統(tǒng)構(gòu)成示意圖

3.1.1 層級化方案的優(yōu)點

(1)由于各線綜合監(jiān)控系統(tǒng)與TCC的數(shù)據(jù)接口在中央級，因此，各線綜合監(jiān)控系統(tǒng)架構(gòu)在組建前后受TCC系統(tǒng)建設(shè)的影響較小，便于各線綜合監(jiān)控系統(tǒng)的實施和擴展。

(2)TCC只存在與綜合監(jiān)控系統(tǒng)中央級的接口關(guān)系，接口界面清晰，接口相對簡單。即便TCC與綜合監(jiān)控系統(tǒng)的供貨商非同一廠商，系統(tǒng)協(xié)調(diào)的工作量也較小，方便系統(tǒng)的軟件開發(fā)和調(diào)試。

3.1.2 層級化方案的缺點

(1)TCC系統(tǒng)的穩(wěn)定性依賴于各線綜合監(jiān)控系統(tǒng)的中央級系統(tǒng)，一旦中央級系統(tǒng)數(shù)據(jù)采集出現(xiàn)故障將直接引起TCC的該單線系統(tǒng)的癱瘓。

(2)控制流程較多，需經(jīng)過多級轉(zhuǎn)發(fā)和控制，存在控制延時的可能，因此一般采用“只監(jiān)不控”的原則。

3.2 扁平化方案

扁平化方案是目前新興的一種TCC集成方案，一些新建軌道交通的城市正準備實施該方案。扁平化方案以各線車站的FEP作為數(shù)據(jù)通信的中心，采用扁平化的網(wǎng)絡(luò)結(jié)構(gòu)，監(jiān)控數(shù)據(jù)直接由車站FEP送到各線的LCC(線路控制中心)和TCC。匯集過程為“車站 FEP—綜合監(jiān)控中央級系統(tǒng)”或“車站FEP—TCC”。各線車站的FEP作為數(shù)據(jù)收集和處理的核心，將所收集的車站數(shù)據(jù)直接轉(zhuǎn)發(fā)給綜合監(jiān)控中央級系統(tǒng)和TCC系統(tǒng)，同時也接收來自綜合監(jiān)控中央級系統(tǒng)或TCC的控制命令。TCC扁平化數(shù)據(jù)采集控制方式如圖4所示。

圖4 TCC扁平化數(shù)據(jù)采集控制方式

在扁平化方案中，接口傳輸內(nèi)容和接口協(xié)議是系統(tǒng)實施成敗的關(guān)鍵。TCC與綜合監(jiān)控中央級系統(tǒng)所接收的數(shù)據(jù)內(nèi)容保持一致，分別由車站FEP統(tǒng)一上傳。TCC可以實現(xiàn)“全功能”替代線路中央級系統(tǒng)。所不同的是FEP上傳到線路綜合監(jiān)控中央級系統(tǒng)是基于綜合監(jiān)控內(nèi)部特殊通信規(guī)約，可直接實現(xiàn)，而上傳到TCC的通信協(xié)議則需要雙方進行約定和配合。TCC扁平化數(shù)據(jù)接口協(xié)議如圖5所示。

圖5 TCC扁平化數(shù)據(jù)接口協(xié)議

當進行TCC后期建設(shè)時，必須先對車站FEP的數(shù)據(jù)交換提出具體要求，綜合監(jiān)控設(shè)備商在車站FEP內(nèi)預(yù)留通用接口(必須制定通信規(guī)約，需與綜合監(jiān)控系統(tǒng)和TCC集成商間約定)和傳輸內(nèi)容，后期再對TCC開放數(shù)據(jù)結(jié)構(gòu)，由TCC完成數(shù)據(jù)讀取與寫入。

線路綜合監(jiān)控中央級系統(tǒng)和TCC都是同時采集數(shù)據(jù)，屬于熱備并存的2套系統(tǒng)，TCC癱瘓時應(yīng)通過類似于降級運營的方式將控制權(quán)下發(fā)到綜合監(jiān)控中央級系統(tǒng)。對于部分集成商的軟件平臺，權(quán)限表可直接放置在車站FEP中，由FEP自行判斷。同步方式一般為本地(車站、LCC、TCC等)的實時數(shù)據(jù)庫定期存儲到歷史數(shù)據(jù)庫。特殊情況，例如車站的操作記錄需要定期上傳到LCC的歷史數(shù)據(jù)庫，或TCC的歷史數(shù)據(jù)庫。TCC扁平化系統(tǒng)構(gòu)成如圖6所示。

3.2.1 扁平化方案的優(yōu)點

(1)各線綜合監(jiān)控系統(tǒng)與TCC的數(shù)據(jù)接口在車站的FEP，減少了網(wǎng)絡(luò)層級，提高了系統(tǒng)的實時性能。TCC具有與線路綜合監(jiān)控中央級系統(tǒng)相同的控制能力，可直接收集車站數(shù)據(jù)并下發(fā)控制命令到車站子系統(tǒng)。

(2)TCC與線路綜合監(jiān)控中央級系統(tǒng)所接收的數(shù)據(jù)相同，TCC的數(shù)據(jù)為全局數(shù)據(jù)，可方便TCC系統(tǒng)今后應(yīng)用服務(wù)的擴展。

3.2.2 扁平化方案的缺點

(1)FEP在滿足綜合監(jiān)控系統(tǒng)車站級、中央級系統(tǒng)數(shù)據(jù)傳輸?shù)耐瑫r，還需承擔來自TCC的數(shù)據(jù)傳輸壓力。車站FEP是極為關(guān)鍵的設(shè)備，對FEP硬件和軟件的要求很高。

(2)FEP與車站級、中央級系統(tǒng)同屬于綜合監(jiān)控系統(tǒng)的建設(shè)范疇，其內(nèi)部通信協(xié)議一致，易完成節(jié)點間的數(shù)據(jù)傳輸。但TCC與綜合監(jiān)控系統(tǒng)屬于不同集成商，車站FEP必需向TCC集成商開放內(nèi)部數(shù)據(jù)接口，這種接口的協(xié)調(diào)將非常困難。

(3)TCC在綜合監(jiān)控系統(tǒng)后期建設(shè)。當綜合監(jiān)控系統(tǒng)調(diào)試成功后，TCC再行建設(shè)，這種方式可基本不受子系統(tǒng)數(shù)據(jù)資料變動的影響，但存在TCC再次與子系統(tǒng)進行調(diào)試的過程，調(diào)試周期漫長，存在影響正常運營的可能。另外，由于軟件平臺機制的不同，TCC與子系統(tǒng)的調(diào)試過程可能產(chǎn)生有別于綜合監(jiān)控系統(tǒng)的矛盾和更改，這種更改又將影響到已完成調(diào)試的綜合監(jiān)控系統(tǒng)。

(4)TCC的建設(shè)存在逐站調(diào)試的過程，調(diào)試數(shù)據(jù)量巨大，等同于綜合監(jiān)控系統(tǒng)，因此工程造價比層級化方案大很多。

圖6 TCC扁平化系統(tǒng)構(gòu)成示意圖

3.3 方案比較

TCC層級化、扁平化方案對比見表1。

表1 TCC層級化、扁平化方案對比

4 結(jié)語

綜上所述，基于綜合監(jiān)控系統(tǒng)的層級化與扁平化集成監(jiān)控方案各存優(yōu)缺點，方案的選擇應(yīng)結(jié)合各城市線網(wǎng)規(guī)劃及TCC系統(tǒng)的運營定位予以確定。當線網(wǎng)建設(shè)初期按專業(yè)實施網(wǎng)絡(luò)化運營管理時，宜選用扁平化方案;當線網(wǎng)已形成規(guī)模，并采用TCC應(yīng)急調(diào)度、線路協(xié)調(diào)為主的管理模式時，宜選用層級化方案。

需要說明的是，TCC系統(tǒng)的建設(shè)不論選用那種集成方案，其接口的標準化是系統(tǒng)順利實施的關(guān)鍵，接口規(guī)則應(yīng)全線網(wǎng)統(tǒng)一。此外，標準化工作應(yīng)貫徹到各個專業(yè)，包括統(tǒng)一車站名稱、車站編號、設(shè)備編號、網(wǎng)絡(luò)地址規(guī)劃、數(shù)據(jù)結(jié)構(gòu)設(shè)計等。這些工作將有效支撐TCC乃至整個線網(wǎng)管理的實現(xiàn)。早規(guī)劃、早決策，將促使TCC項目建設(shè)少走彎路，順利實施，并確保聯(lián)網(wǎng)運營后有效發(fā)揮其重要職能。

［1］GB 50636—2010城市軌道交通綜合監(jiān)控系統(tǒng)工程設(shè)計規(guī)范［S］.

［2］魏曉東.城市軌道交通自動化系統(tǒng)與技術(shù)［M］.北京:電子工業(yè)出版社，2004.

［3］元進輝.北京市軌道交通路網(wǎng)指揮中心指揮系統(tǒng)(TCC)的設(shè)計和實施［J］.智能建筑電氣技術(shù)，2010，4(5):27.

［4］毛宇豐.地鐵控制中心設(shè)計［J］.都市快軌交通，2006，19(5):31.

［5］梁強升.城市軌道交通運營控制中心設(shè)置研究［J］.城市軌道交通研究，2008(7):17.

［6］程媛.軌道交通綜合監(jiān)控去云式構(gòu)成方案研究［J］.城市軌道交通研究，2011(3):44.