城市軌道交通信息集中監控系統的設計與實現摘要：目前的城市軌道交通管理信息系統都是針對某具體系統或某類型設備進行管理與控制，且各條線路相互之間不通任何信息，是孤立的系統。無法對各線各系統運行情況特別是設備故障情況迅速準確把握。針對這種情況，整合現有資源，設計了軌道交通信息集中監控系統。該系統采集現有各系統設備故障信息進行處理和故障報告，并進行了綜合分析和預測，給集中監控增加了智能決策功能;且只需在原有的網管系統上提供或新增所需要的北向接口，并不需要改變原有網絡的拓撲結構，只要新增采集系統和集中監管系統，在實現上很簡潔，相對投資也不大。關健詞：城市軌道交通，信息集中監控，網絡管理 目前，城市軌道交通的信息管理系統一般分為傳輸、公務電話交換、調度電話、電源、無線調度、廣播、圖像監控(安防系統)、時鐘、自動售檢票等9大子系統;每個子系統的管理網絡自成體系，且都有自己相應的網管中心或數據采集系統。所以，目前的管理系統不能形成一個有機整體，宏觀控制管理能力弱，而且各條軌道交通線的信息系統間也都相對獨立。 針對上述網絡管理現狀，為提高城市軌道交通信息管理能力，提出信息集中監控的構想。即對所有軌道交通系統網絡設備實施統一監視與必要控制、管理。該方案不只針對某類單一系統設備的監控和管理，而是一個對各條軌道交通線上的上述9大子系統設備實施綜合監控和管理的系統。該方案也不是針對各系統的所有參數進行監控管理，而是初步對設備故障進行實時的監控管理。1 概述 對于各個系統，原有的管理網絡或維護方法不盡相同。象自動售檢票系統等管理系統就可將原有系統重新整合進解決方案。而象傳輸系統等，比如SDH(同步數字多級)設備，處在多廠商環境中，將涉及多廠商的SDH網管系統。這種網絡設備的多元化，加上有些不同廠家設備還不兼容，因此造成綜合網管的困難。所以，設計信息集中監控系統時，僅簡單地從原有網管系統進行整合還是不夠的。 對于把傳輸系統復雜的網管系統整合成集中監管，大致有三種途徑:①綜合化方法—在已有網管系統之上再加一級管理系統;②翻譯法—在有信息交互需求的網管系統之間進行兩兩翻譯;③標準化法—已有的各網管系統采用公共信息模型和功能集。 第二種方法有現成的支持標準(SNMP/CM IP /CORBA)互操作的靜態規范描述和動態交互式轉化方法，適用于信息量不大的情況。第三種方法是比較徹底的綜合網管方法，但需要將所有的網管系統被統一標準替換，故暫時還只是一個想法。本文提出的信息集中監控解決方案主要針對故障信息進行處理，而且為了避免各廠商間的交涉，將采用綜合化方法，做到與原有網管系統的平滑過渡;這也與那些通過簡單整合就可以實現集中監控的系統的做法很類似，系統也比較容易整合。這樣，在各系統原有管理系統或網管系統的基礎上再添一層管理者，在新的管理層上實現信息集中綜合監管，從而解決了各系統間的“信息孤島”問題。2 系統架構 系統架構分為三層:管理監控層、代理層和應用層(如圖I)。應用層是現有的各種硬件系統，比如傳輸系統、自動售檢票系統等。代理層是數據集中的中間層。包括數據采集硬件和軟件。管理監控層將對采集的所有數據進行綜合處理并形成新的業務模型。 架構中，上層管理者管理若干網絡體系、網絡協議異構的系統，異構子網各自維護一套專業管理信息庫。它們向綜合監管系統提供Q3,CORBA接口。 為了實現綜合監管的目標，利用代理層將原有系統(應用層)在數據接口上達到統一，這樣代理層加上應用層組成的新的網絡將是管理監控層所需要的“統一”網絡，在概念上可以想象成一個虛擬網絡。管理監控層通過由代理層組建的綜合數據庫，對大的方面(比如現在的告警系統，以后通過統一其他系統的數據接口就可以實現其他方面的監控)進行全局性調配與管理，細節留給原有系統的網管系統或者管理系統處理。各系統通過代理層的代理軟件(數據采集軟件)的映射，完成數據接口的統一。3 解決方案3.1 硬件系統解決方案 圖2是以某地鐵線為例的集中監控系統拓撲圖。其中A11是從傳輸網管NM11，采集數據的代理PC ; A12是從自動售檢票管理系統NM12采集數據的代理PC。所有系統經代理PC采集數據后，通過路由器R，把數據送到數據庫服務器DS。其他地鐵線的拓撲都與該線類似。MIS1 , MIS2，MIS3凡等是信息集中綜合監管系統。比如MIS1管理1一4號線，MIS2管理5一9號線，MIS3管理10一13號線。MIS1—MIS3對數據庫服務器中的數據進行綜合處理、顯示、告警，以及統計和分析。MIS1一MIS3放在一起，這樣在多個處理機上進行監管可以擴大可視范圍，也達到綜合監管的目的。 設備網管所提供的北向接口，有的是Q3接口，可以通過網口進行采集;有的是串口，可以通過串口接收。如果通過串口接收數據，可以根據圖3所示，用一個1-8多串口卡，使用一臺代理PC機進行多個串口數據收集。 上述方案的可靠性:如果原有設備的網管系統提供的北向接口是串行方式，那么通過圖3方式，一臺代理PC機就可以采集8臺網管的數據，但是串行方式的數據是通過重復機制來最大限度地確保信息的完整。所謂重復機制，是當信息沒有被接收就重新發送，如果三次沒有接收到就不再重發。這樣的數據采集方式很不可靠。而采用TCP/IP方式進行采集，如果數據包沒有被正確接收，將等待到可以正確接收的時候重新發送。所以在可能的情況下，此方案需要廠商提供網管軟件的Q3北向接口。 在安全性方面，整個系統并不通過公網，局域網能保證數據的安全、不被截獲、破壞等。3.2軟件解決方案 軟件解決方案中包括數據采集和數據處理。兩個獨立的體系，并通過數據庫使兩者形成整體。數據采集建立數據庫，數據處理管理數據庫。 數據采集部分是針對各個不同的分立系統對不同類型的數據進行收集。由于不同系統的數據存儲方式對外提供數據的方式不同，就算同一系統的不同廠商設備的網管系統所提供的北向接口也不同，所以數據采集部分將針對每個系統進行編程。數據采集方式的多樣性會導致軟件架構的雜亂無章。為避免不一致和保證軟件系統的易擴展及易維護性，應根據數據處理部分所感興趣的數據內容制定統一的數據接口。解決方案如圖4所示:數據采集平臺將根據不同系統不同設備加載特定的數據采集DLL(動態鏈接庫)。對于同一系統，數據采集平臺和DLL之間的數據接口相同，而且數據采集部分和數據處理部分也將以統一的數據接口進行數據匯總。這樣一旦有新增設備，數據采集系統只要針對新增設備編寫DLL,整個系統就具備良好的可擴展性。圖4中簡單列舉了數據采集DLL采集數據的三種方法:TCP/IP, RS232及直接讀取相關數據庫DB。這些差異性將在統一的數據接口處消失。 數據處理部分是軟件解決方案的核心，對匯總的數據進行分類處理并形成新業務邏輯。數據處理部分的主要功能如圖5所示。其中:安全管理系統是對使用該系統的所有用戶的權限管理;該模塊將保證系統的安全性。告警系統對采集系統收集的所有數據進行實時處理，對所有設備的現有故障進行報告，對消除的故障進行告警清除(使設備告警狀態復位)。收發文系統是在系統有新增設備故障告警時，在行政上上級對負責維護的部門進行派工單發放的業務處理模塊;相關部門維護完畢后對所收到的派工單進行回執，這樣可以明晰責任，實現了該解決方案的行政“監管”目的。統計報表系統是對故障告警歷史信息進行統計和簡單計算形成特定形式的報表。分析預測系統對故障告警歷史信息進行統計分析，采用經驗法和曲線擬合法對設備近階段的運行狀況進行預測告警，這樣可以對故障發生概率較高的設備進行重點維護，最大限度地避免運營事故。4結語 本文設計的系統，只是通過從現有網管系統的北向接口提取故障信息，或從現有的管理系統直接提取故障信息進行綜合。在原有的網管系統上提供或新增所需要的北向接口，并不需要改變原有網絡的拓撲結構，只要新增采集系統和集中監管系統，相對投資也并不大。數據的集中處理，能對運營的整個網絡系統的設備運行情況進行宏觀把握，并有現存管理系統所沒有的派工單業務流程，不僅對設備運行情況進行了集中監控，還能對設備維護進行統一調配和管理。系統的另一個價值在于，可以對綜合的數據進行智能分析和預測，可以根據預測進行有目的的檢修，增強整個系統運行的安全性和可靠性。參考文獻1郭軍.網絡管理與控制技術.北京:人民郵電出版社，1999. 42 -902孟洛明，楊正球.電信管理網.北京:人民郵電出版社，2000. 50 -1253王剛.電信網絡管理體系結構的發展.電信技術，2001(12):39-41