綜合監控系統遷移技術在深圳地鐵的應用

吳嘉勇 黃 路

(1.北京和利時系統工程有限公司 北京100176;2.深圳地鐵集團運營公司 廣東深圳518000)

1 遷移背景及需求

深圳地鐵1號線綜合監控系統分二期建設，一期工程于2004年底投入運行，二期工程于2011年6月開通。一期工程綜合監控系統(integrated supervision control system，ISCS)是國內第一套成功運行的深度集成綜合監控系統，采用10 Mbit/s帶寬的邏輯獨立通道，將車站、控制中心、車輛段連接起來，搭建了一個大型分層、分布式的自動化監控系統。二期工程綜合監控系統除包含一期的三大系統外，還要互聯多個地鐵核心系統(信號、屏蔽門、售檢票、乘客資訊等)。1號線二期工程綜合監控系統是在既有一期工程基礎上的升級，采用了更為強大的軟件平臺和更為友好的人機界面。

運營控制中心(operation control center，OCC)主要對一期機電設備監控系統(equipment monitoring control system，EMCS)、火災自動報警系統(fire alarm system，FAS)和電力監控系統(supervisory control and data acquisition，SCADA)三大系統進行整體遷移，是在對既有系統沒有影響的前提下進行的，同時還要保證遷移后系統的安全性、連續性、穩定性。

如上所述，1號線分兩期工程完成，雖然采用了同一軟件平臺，但二期工程在完全保留了一期數據庫平臺的基礎上，對系統的界面、操作風格進行了重新設計，更好地滿足了用戶對集成系統和互聯系統的使用需求。

2 遷移內容及方案設計

從工程實施的層面劃分，一期既有系統向二期系統遷移的內容主要包括:一期既有系統(EMCS/SCADA/FAS)監控內容和系統功能的遷移，一期系統歷史數據/用戶管理系統/對時功能的遷移與合并;從數據層面劃分，遷移內容可分為實時數據、歷史數據、HMI(human machine interface)畫面、管理數據、維護數據。

2.1 典型站遷移設計

為確保遷移工作順利，需進行典型站的遷移測試，測試的目的是為了對OCC遷移方案的可行性進行驗證，并根據測試結果分析、制訂下一步遷移的詳細方案，測試主要包括EMCS/SCADA/FAS模擬遷移測試、系統功能模擬遷移測試等。

2.2 遷移設計

結合一期工程的規模和功能實現程度，以及典型站遷移測試的驗證結果，進行一期工程OCC遷移的詳細設計，主要包括一期中心/車站軟件的遷移、OCC遷移后的試運行等。二期工程采用新版的系統平臺，與一期相比，不僅顯示分辨率從1024×768(像素)提高到1280×1024(像素)，而且還提供了更為美觀、合理的人機交互界面。

為了充分發揮新平臺的特性，同時最大限度地保留一期工程的組態，OCC遷移方案僅對中心的一期系統軟件進行修改，對既有車站的配置保持不變，僅對其中的部分軟件參數進行重新設置。

首先，將一期中心系統的所有頁面(見圖1)全部修改為二期的頁面樣式(見圖2)，修改過程不對一期圖形的內容進行改動，僅將原來的圖形內容居中放置。同時，保留一期所有的信息窗口、控制面板，基本保留一期系統的操作習慣。而報警、事件、趨勢功能，統一采用二期的頁面和功能。

圖1 一期系統HMI風格

圖2 二期系統HMI風格

本著盡量不修改車站軟件的原則，對于一期工程車站級軟件只做部分參數性的修改，可以看作是一次升級操作。修改完成后，需要對車站的所有工作站、服務器重啟一次。

由于一期中心軟件在遷移試運行期間仍處于運行狀態，為了保證與車站級軟件的一致性，同樣需要對一期的中心軟件進行修改，修改的內容與車站級軟件一樣，也可以看作是一次升級操作，修改完成后同樣需要重新啟動服務器和調度工作站。

OCC遷移完成后的試運行采取新舊并行的運行方式，即在控制中心設置新的調度工作站，仍保留一期的調度工作站，同時運行新舊兩個版本的軟件。由于軟件平臺支持新舊兩個版本的并行運行方式，所以可以很好地對新版軟件進行對比測試、驗證。

試運行結束后，將撤銷一期的中心服務器和調度工作站，系統將在重新部署的新版軟件平臺上運行。

3 系統軟件架構及部署

軟件平臺建立在3個層次上:第1層是采集和通信層，主要用于數據采集，完成與外部系統之間的數據交換;第2層是數據管理層，用于數據管理和高級應用，通過一個實時數據庫和一個關系數據庫，實現報警、報表和趨勢服務;第3層是應用層，主要用于實現HMI功能和外部接口。基于上述的軟件結構，軟件平臺可以進行靈活部署，如圖3所示。可以看出，整個系統通過內部總線可以實現靈活的軟件配置和軟件連接。

圖3 軟件部署

一期的軟件部署如圖4所示，二期的軟件部署，如圖5所示。可以看出，兩者采用了相同的軟件部署思想和結構，僅在操作系統、工作站的數量上稍有不同，且每個車站、中心的每個功能塊或服務塊均可以通過網絡靈活配置和調用。

4 遷移實施

4.1 實驗室驗證

所有遷移準備工作均在實驗室進行針對性的測試與運行，包括頁面組態、參數配置等工作。在遷移工作實施前，需要對所有的修改系統進行逐一驗證，保證修改的準確性。同時，在實驗室環境中，還要充分考慮現場環境的特殊性，以及對遷移工作實施的影響。

圖4 一期軟件部署方案

圖5 二期軟件部署方案

4.2 備份及準備工作

在遷移工程實施前，對一期系統每臺計算機上的文件及配置進行備份，以保證在遷移實施過程中出現異常時能快速地恢復到原來的運行狀態。

4.3 硬件、軟件的安裝與配置

在控制中心搭建2臺服務器(冗余配置)作為報警及歷史服務器，安裝新版本軟件并配置相應的軟件環境。

1)搭建2臺調度工作站，作為新版中心調度工作站，安裝新版本軟件，配置相應的軟件環境。

2)搭建2臺核心交換機(冗余配置)，作為新搭建中心服務器和工作站的網絡接入設備，并配置服務器和工作站相應的網絡環境。

3)通過跳線將一期核心交換機和新交換機連通，作為新版中心服務器獲取一期IO數據源的數據通道。

4)在控制中心安裝1臺網絡防病毒軟件服務器，在新版中心服務器和工作站部署網絡防病毒軟件客戶端。

4.4 現場遷移

在夜間列車停運后，通過OCC依次遠程登錄一期車站工作站，對車站軟件進行修改，并重新啟動運行。隨后，更新一期系統OCC的服務器和調度工作站軟件，并重新啟動運行。待一期全線系統全部啟動成功、恢復功能后，對升級后的一期系統在線觀察，確認運行穩定后，再運行新搭建的兩臺中心服務器及調度工作站，按車站分批將一期車站接入新系統。此時，原一期的中心服務器和調度工作站與新搭建的系統并機運行。

5 遷移的難點與創新

5.1 難點

1)本次遷移是在既有系統正常運行的情況下進行的一次無擾切換，其中針對OCC特有的全線匯總頁面的遷移是在一期系統的基礎上添加了二期的車站內容，而二期的控制設備和數據結構都有所改變，涉及的內容較多，所以這部分內容是OCC遷移的難點之一。

2)從運營管理角度來看，遷移完成后針對系統各項功能測試與驗證工作的組織與協調，也是確保遷移成功的必要條件。

5.2 創新

1)首次引入人因工程概念(human factor)，從“人、機、環境”3個方面對系統人機界面進行規劃，在總體界面風格保持統一的前提下，以“人”為核心元素進行設計，最大限度地滿足運營需求。

2)一期既有SCADA電力監控系統的遷移是復雜程度最高、對運營影響最大的環節，為了最大限度地減輕對運營的影響，遷移由簡至繁，先降壓變電所，后混合變電所，采取分批接入、控制接入規模與節奏的策略，以對正常運營影響最小為前提，最終完成整個遷移工作。

6 結語

筆者從系統遷移的設計、測試、實施等方面，闡述了綜合監控系統的遷移技術。伴隨著地鐵建設的高速發展，網絡化運營與資源共享勢必要求控制中心的綜合監控系統是一個多線路、多系統的軟件平臺。如何實現不同線路、不同架構的綜合監控系統軟件的遷移和整合，將是今后所面臨的一個新課題。

［1］魏曉東.城市軌道交通自動化系統與技術［M］.北京:電子工業出版社，2011.

［2］曲立東.城軌交通環境與設備監控系統的結構比較［J］.都市快軌交通，2006，19(3):90-92.

［3］魏曉東.現代自動化技術在城市軌道交通中的應用［J］.北京:自動化博覽，2003，20(4):6-11.

［4］王開滿，王軍，張慎明.城市軌道交通自動化綜合監控系統的集成模式［J］.城市軌道交通研究，2007(3):57-62.

［5］彭輝，徐志修.城市軌道交通智能綜合監控系統設計［J］.鐵道工程學報，2006(1):15-18.

［6］魏曉東.地鐵綜合監控系統建設的關鍵問題分析［J］.北京:自動化博覽，2009(5):14-37.

［7］GB 50636—2010城市軌道交通綜合監控系統工程設計規范［S］.北京:中國計劃出版社，2010.

［8］GB 50157—2003地鐵設計規范［S］.北京:中國計劃出版社，2003.

［9］深圳地鐵一號線續建工程綜合監控系統技術要求［G］.深圳，2006.