軌道交通專用通信集中告警系統設計

李士東

(河北遠東哈里斯通信有限公司，河北石家莊 050200)

0 引言

隨著社會的飛速發展，交通擁擠問題日益突出，嚴重影響了人們的生活和國家經濟建設，軌道交通是緩解交通擁擠問題的一個強有力的交通工具。

軌道交通是一個復雜的系統，其可靠高效運營需要眾多相關系統相互協作和大力支持。專用通信系統在其中發揮舉足輕重的作用，它為地鐵運營提供通信保障。專用通信系統主要包括:傳輸、無線、公務電話、專用電話、閉路電視、時鐘、廣播、電源、集中告警等至少9個子系統［1］。

集中告警系統是軌道交通專用通信系統中一個重要的組成部分，它實時監控其他各子系統的運行狀況，為維護人員提供全網絡運行視圖，是專用通信系統的運維支撐系統。

1 總體設計

集中告警系統整體結構如圖1所示。

圖1 集中告警系統結構

集中告警系統采用分層設計，主要包括前置機、告警解析服務器、應用服務器和客戶端。

前置機負責采集各子系統的告警數據，將不同協議的告警數據轉換成系統內部統一格式并存入數據庫。

告警解析服務器根據不同設備類型的告警狀態匹配規則進行告警分析定位，將分析結果提交給應用服務器。

應用服務器將告警結果轉發給客戶端顯示，并響應客戶端的各種操作指令。

客戶端主要提供人機操作界面，通過監控拓撲視圖來顯示網絡及設備的運行狀態。

2 需要解決的難點問題

集中告警系統的建設難點在于:①管理設備類型眾多，接口協議繁雜;②監控場景視圖千變萬化。

專用通信系統至少包含8個子系統，不同的子系統由不同的設備供應商提供，各子系統告警接口協議一般都由設備供應商自己定義，而且多采用私有接口協議［3］。

不同子系統功能不同，設備組網方式及配置情況差異巨大，因此抽象出的監控場景視圖也不同，且隨時可能發生改變。

通常解決這種問題最簡單的方案就是定制系統，為每個項目開發一套集中告警系統，這樣做存在如下缺陷:①項目通用性差，不能一勞永逸解決同一個問題，每個項目都需要重新投入人力物力;②項目后期維護成本增加，版本管理困難，每個項目一個版本，對于共性的bug解決需要n份雷同工作。該系統要解決上述難點問題并避免定制系統帶來的缺陷［4］。

3 設計實現

3.1 前置機實現

前置機直接與被監控系統通信，采集設備告警，需要設計成接口可靈活擴充的軟件結構［5］。前置機軟件結果如圖2所示。

圖2 前置機軟件結構

前置機接口適配層設計成橫向可擴充結構，接口實體間沒有任何耦合，接入新協議只需橫向擴充一個全新接口實體即可［6］。接口實體將不同格式規約的告警數據轉換成內部可識別的統一格式，然后存入數據庫，并通知告警解析服務器。

前置機與告警解析服務器間采用面向連接TCP私有協議通信。

前置機各接口實體通過DLL的方式實現，前置機初始化時動態加載DLL。新增設備類型時只需增加一個全新的DLL接口實體。

3.2 告警解析服務器、應用服務器實現

前置機雖然將告警轉換成統一格式［7］，但不同設備的告警狀態匹配規則不同，有的通過告警級別匹配(如1～4級表示故障，5級表示恢復);有的通過“告警類/告警號”匹配(如“通信故障/1”表示故障，“通信故障/2”表示恢復)。

告警解析服務器主要根據不同設備類型的告警狀態匹配規則進行告警分析定位，產生內部告警數據結構，程序結構如圖3所示。

圖3 告警解析服務器軟件結構

告警解析服務器從數據庫提取告警數據，根據設備類型進行數據調度，把告警數據分發到對應的告警解析實體，告警解析實體通過DLL的形式實現，在程序初始化時動態加載進來。新增設備類型時除了前置機上增加一個DLL接口實體，告警解析服務器也需增加一個全新的DLL解析實體。

內部告警數據結構是一個內存鏈表，數據保存在數據庫中，程序啟動后加載到內存，其內按告警級別記錄著系統每個故障單元對應的故障告警個數及恢復告警個數。

告警解析實體根據告警狀態匹配規則進行告警分析。如為故障狀態告警則把對應故障單元的故障告警數加1;如為恢復狀態告警則清除之前存在的相匹配的故障告警(假設故障告警n個，n≥0)，把對應故障單元的故障告警數減n，恢復告警數加n+1，產生內部告警數據結構，將數據入庫并通知應用服務器。告警解析服務器與應用服務器間采用面向連接TCP私有協議通信。

應用服務器負責將內部告警數據結構轉發給在線客戶端;同時對客戶端提交的數據進行后臺分析處理并入庫，將處理結果返回給客戶端。

3.3 客戶端實現

客戶端可以實現系統告警的圖形化管理，告警可以定位到板卡或者端口級別。但不同集中告警系統管理的設備不同，設備外觀及配置也各不相同，這就為系統圖形化管理帶來了困難。為了不走定制路線，系統需要提供一個設備無關的拓撲場景［8］編輯工具，可以根據設備組網及配置情況利用各種形狀的圖元進行拓撲編輯。拓撲編輯原理如圖4所示。

圖4 拓撲編輯原理

一個監控拓撲由若干個圖層構成，圖層間有嚴格的隸屬關系，一個圖層可有多個子層，子層下還可再有子層，依此類推。拓撲編輯采用圖4所示的倒樹型拓撲編輯結構，由一個根節點可以擴充出不同的子圖層構成一個完整的監控拓撲。每個圖層有唯一的圖層索引，圖層索引代表了該圖層在整個拓撲中的位置信息。如1-1的父層是1;1-2-1的父層是1-2;1-1有2個子層1-1-1和1-1-2。

可以在一個圖層中添加設備網元，設備網元的屬性包括設備類型、設備名稱、目的圖層和通信參數等。在該圖層的子層中編輯設備的機架圖，每個設備網元都有一個目的圖層，目的圖層指向機架圖所在的圖層。這樣點擊設備網元就可以切換到目的圖層(機架圖)，一般機架圖層都是設備圖層的子層。機架圖層主要通過圖元的組合來描述設備的詳細構成，如模塊、板卡和端口等信息，機架圖層內的每個組成圖元代表一個故障單元，故障單元的屬性包括所屬設備、單元名稱和告警位置等。

系統通過圖層索引保存拓撲結構，通過圖元數據流保存圖層內數據信息，并提取圖層內的設備信息及故障單元信息另表保存。

系統初始化時讀取所有故障單元信息，依此建立內部告警數據結構內存鏈表，用來保存每個故障單元的告警個數。

客戶端收到服務器轉發的內部告警數據結構后，將對應的內存鏈表更新，然后根據新數據刷新監控拓撲上的告警指示，把指示定位到對應圖層的對應故障單元上，根據不同告警級別通過不同顏色來顯示告警狀態。告警顯示具有向上傳遞性，當一個故障單元產生告警后，會逐層反應到父層對應的網元上，直至最頂層拓撲。維護人員見到告警指示后，可以由設備網元點擊逐層深入，直到最底層查看具體的故障位置及故障詳細信息。

客戶端收到告警數據結構后除了在監控拓撲上進行顏色指示外，還可將告警信息送給告警箱，由告警箱進行燈光顯示及聲音提示;還可以通過聲卡播放告警提示音。

客戶端還為維護管理人員提供各種應用功能接口，如:告警清除、告警受理、告警查詢、告警打印、告警統計以及告警報表等。

4 系統性能測試

測試的目標是驗證通過上述設計方案實現集中告警系統的穩定性、可靠性及系統擴充能力。

測試設備的網絡配置結構如圖5所示。

圖5 集中告警系統測試結構

測試需要的設備包括:服務器、客戶端和各子系統接口測試Demo。為了簡化測試環境，在一個服務器上部署前置機程序、告警解析程序及應用服務器程序;各子系統接口測試Demo通常由子系統廠家提供，各接口測試Demo可以部署在同一臺計算機上，也可分開部署。

按照各子系統提供的組網及設備配置資料進行拓撲編輯測試，拓撲編輯工具可以靈活方便建立監控拓撲，形象描述設備網絡及設備機架圖。證明了該系統拓撲編輯的設備無關性與靈活性。

根據各子系統提供的接口協議文檔，在集中告警系統上擴充前置機的接口實體DLL和告警解析的解釋實體DLL。DLL實現后可以動態加載到集中告警平臺里，證明了接口管理的實用性與靈活性。

通過各子系統接口Demo向集中告警系統模擬發送告警，告警可以在監控拓撲上定位并正確顯示，可以驅動聲光告警。證明了接口實體DLL及解析實體DLL工作正常，與平臺結合良好。

各測試Demo定時1 ms向集中告警系統發送告警數據。系統沒有彈出異常，告警顯示準確，證明了系統的穩定性與可靠性。

測試結果證明，分層設計的集中告警系統穩定可靠，擴充能力極強，設計是可行的。

5 結束語

目前該集中告警系統在國內多條軌道交通系統上部署應用，取得了廣泛好評。實踐證明了該系統完全達到了預期效果，有效地避免了定制系統帶來的缺陷，大大減少了系統后期開發投入，降低了集中告警系統軟件維護成本。分層可擴展的架構設計提高了系統的生命力;監控場景動態繪制滿足了千變萬化的用戶現場環境。同時對其他網管類、監控類系統的實現具有很強的參考價值。

［1］陳桂漢.綜合電信管理解決方案［M］.北京:電子工業出版社，2002:10-230.

［2］徐海軍.電信網管發展的五大趨勢［N］.通信產業報，2004，第14期(第39版).

［3］李國寧，劉伯鴻.城市軌道交通綜合監控系統及集成［M］.北京:西南交通大學出版社，2011:20-330.

［4］張利彪.城市軌道交通信號與通信系統［M］.北京:人民交通出版社，2010:5-90.

［5］賈毓杰.城市軌道交通通信與信號［M］.北京:機械工業出版社，2009:45-160.

［6］李曉江.城市軌道交通技術規范實施指南［M］.北京:中國建筑工業出版社，2009:50-280.

［7］李千日.軟件體系結構設計［M］.北京:清華大學出版社，2008:30-370.

［8］田超.多技術網絡管理(TMF MTNM)體系綜述［J］.無線電工程，2005，31(4):25-29.