綜合監控系統雪崩功能設置必要性分析

鄒 艷

(蘇州軌道交通有限公司運營分公司 江蘇 蘇州 215101)

1 綜合監控系統的構架理念

綜合監控系統是通過現代控制系統集成技術構建起來的大型自動化系統，它采用開放的形式，無縫地將城市軌道交通各個自動化專業的子系統接入。綜合監控系統對子系統的無縫接入在實踐中產生了兩類方式，一類是對子系統集成，另一類是對子系統互聯。

1.1 子系統集成與互聯的概念

所謂對子系統集成，是指開放系統將被集成子系統完全融入其中，使之成為綜合監控系統的一部分。被集成子系統的全部功能都由綜合監控系統實現，除了管理意義外，被集成子系統構成了綜合監控系統的主體。所謂對子系統互聯，是指被互聯子系統作為一個獨立運行的系統，具有自身的完整結構，綜合監控系統通過外部接口與子系統進行必要的信息交互，以支持信息共享平臺的構建。互聯子系統獨立運行，實現自己的功能，也向綜合監控系統提供交互數據，支持綜合監控系統互聯功能的實現。

1.2 綜合監控系統的主要構架形式

就目前的發展來看，城市軌道交通綜合監控系統的構架形式主要分為兩類:一類是以環調、電調為構建核心的綜合監控系統，它以機電設備監控為主體，是軌道交通線路的數字信息共享平臺，主要集成了電力監控系統(SCADA)和機電設備監控系統(BAS);另一類是以行車調度指揮為核心的綜合監控系統，其標志是集成了軌道交通運營的主專業系統——列車自動監控系統(ATS)。下面對這兩種構架形式進行比較，如表1所示。

表1 綜合監控系統的主要構架形式比較

1.3 蘇州軌道交通1號線綜合監控系統構架

根據以上的分析對比，不難解釋蘇州1號線綜合監控系統為何采用以環調和電調(PSCADA、BAS)為核心的設計方案。該方案將PSCADA和BAS子系統在車站級納入綜合監控系統，其中央級、車站級功能由綜合監控系統完成，對CCTV(閉路電視系統)、PA(廣播系統)、PIS(乘客信息顯示系統)、PSD(屏蔽門系統)、FG(防淹門系統)、FAS(火災自動報警系統)、AFC(自動售檢票系統)、ACS(門禁系統)、ATS(信號系統)、CLK(時鐘系統)10 個子系統進行互聯。雖然該方案集成度不如以行車調度指揮為核心的方案高，但在目前的技術條件和人員條件下，對于剛建設第一條線的蘇州來說應該是比較合適的選擇。

2 設置雪崩功能的必要性

2.1 雪崩功能的設置

在城市軌道交通綜合監控系統中，一般集成、互聯的子系統達到10個以上，系統需要接收和處理的數據量很大，所以軟件設計時會考慮在處理大量狀態信息變化時采用雪崩處理，以防止任何數據的丟失。蘇州軌道交通1號線的綜合監控系統集成和互聯了12個子系統，需要處理的數據量達到了30萬點，因此在搭建整個系統框架時也考慮設置了雪崩功能模塊。

2.2 雪崩功能的驗證

1號線綜合監控系統建成后，為了驗證雪崩功能的實際作用和效果，組織了一次真實的故障試驗。

2.2.1 觸發條件

經過前期設計測算和國內同行的經驗，最有可能引發大量狀態信息變化、造成大量數據上傳的極端情況一般出現在主變電所解列退出時，所以把雪崩功能驗證的觸發條件定義為一座主變電所故障斷電并整所退出。

2.2.2 評判依據

按照上述觸發條件，為驗證雪崩功能的效果，主要考察控制中心(OCC)綜合監控實時服務器在主所斷電時的運行性能和OCC綜合監控工作站在主所斷電時的監控能力。

2.2.3 評判標準

按照上述評判依據，在主所退出時，信號、通信、SCADA、AFC、BAS、FAS等系統由于失電而在同一時間內向ISCS傳遞，由于掉電或轉為不間斷電源系統(UPS)供電的接口數據信息，此時OCC綜合監控實時服務器應該保持正常的數據處理能力，兩臺冗余服務器數據處理的主從狀態不應產生變化;在服務器運行正常的情況下，工作站可以保持正常的監控功能，各系統事件、報警、圖頁均保持實時更新，人機界面可以正常監控，無刷新緩慢、卡阻等現象。

3 雪崩功能的驗證結果

3.1 服務器主從狀態檢測與分析

OCC兩臺實時服務器互為冗余，在同一時間由一臺服務器負責關鍵進程的數據處理，在聯調過程中選取前置處理器(FEP)和SCADA兩個關鍵進程作為服務器的狀態檢測對象，判斷主從狀態。如圖1所示，通過檢測FEP和SCADA兩個關鍵進程，停送電前后均運行在服務器1(綠色顯示)上，可以判斷服務器的主從工作狀態未發生切換。

圖1 服務器進程狀態

3.2 實時服務器CPU使用率分析

OCC由實時服務器1和2負責數據的處理，與FEP和工作站進行通信。因此，從停電前到停電后分為5個時間節點進行檢測，實測中央處理器(CPU)使用率如表2所示。

表2 OCC實時服務器CPU使用率記錄 %

按照表2記錄的數據，可繪制出服務器1和2的CPU使用率趨勢(見圖2)，同時進行分析。

圖2 服務器CPU使用率趨勢

1)服務器1和2的CPU使用率在整個停送電過程中均小于2%，負載較低。雖然此時車站及正線處于夜間停運狀態，但即使是在運營狀態，以加多2倍的數據處理推算，服務器CPU使用率約為5%，服務器依然可以正常運轉。

2)服務器1比服務器2的CPU使用率高0.3% ～0.7%，因為服務器1一直處于主服務器狀態，處理關鍵進程多，負載相對較高。

3)在停電瞬間，服務器使用率相對提高了0.1% ～0.5%，主要是停送電時的設備狀態變位相對較多、上傳數據量增加的緣故，但增加的使用率幅度較小，不會影響服務器程序的運行。

從以上圖表及分析可以得出，OCC實時服務器1(主)和服務器2(從)在主所斷電退出時，CPU使用率比較穩定，受影響不大。

3.3 實時服務器內存占用檢測與分析

與CPU使用率相同，對于服務器內存占用情況，主要將停電前到停電后分為5個時間節點進行檢測，實測內存占用情況如表3所示。

表3 OCC實時服務器內存占用記錄 GB

按照表3數據，可繪制出主從服務器內存占用柱狀對比圖(見圖3)，同時進行分析。

圖3 主從服務器內存占用對比

1)主從服務器的內存占用比較平均，在整個停送電過程中，服務器1和2的內存占用相差不大。

2)在停送電瞬間，服務器1和2的內存占用比較穩定，波動的范圍不大于0.2 GB，相對于服務器16 GB的內存來講，影響基本可以忽略。

從以上圖表及分析可以得出，OCC實時服務器1(主)和服務器2(從)在主所斷電退出時，內存占用比較穩定。

綜合以上主從狀態、CPU使用率、內存占用3個方面的分析，在主所停電退出導致各系統接口產生變位數據時，綜合監控服務器能保持在正常的工作狀態。

3.4 OCC工作站監控能力評定

對于工作站監控能力，主要從事件報警刷新、界面操作速度進行檢測分析，按照提前設計的記錄表格進行記錄和檢測，匯總整理后發現:在聯調過程中，各接口專業在停送電期間均能正常監控，事件報警能正常上傳;在停送電時，在OCC電調、環調工作站進行頁面切換及點擊圖面時，操作速度正常，無緩慢、卡阻等現象。綜合以上分析得出，在主所退出時，各系統事件、報警、圖頁均能正常更新，無刷新緩慢、卡阻現象，工作站可以保持正常的監控功能。

3.5 雪崩測試的結論

通過這次對綜合監控系統雪崩功能驗證的數據分析，得出結論:在一個主所故障退出時，各接口系統均能正常上傳數據，綜合監控系統OCC工作站及服務器都能保持正常工作。

4 結語

蘇州軌道交通1號線綜合監控采用了以環調、電調為核心的構架方案，集成和互聯了12個子系統，接入數據量達到30萬點。在此前提下，測試了比較極端的故障情況，即一座主變電所整體解列退出運行，斷電范圍達到了12個站及區間(全線共24個站點)。測試結果表明，并沒有發生數據量激增而導致系統處理速度變慢甚至死機的現象，相反中央服務器的CPU使用率和內存占用率都非常富余，整個系統的處理能力在測試過程中沒有受到任何影響。因此，可以得出以下結論:基于蘇州1號線綜合監控系統的構架方式，只要系統的硬件配置參數和冗余度不低于目前國內主流設計標準，雪崩功能設置就可以考慮取消。

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

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

［3］湛維昭.地鐵機電系統綜合集成平臺的設計［J］.都市快軌交通.2006，19(2):81-84.

［4］顧明星，董德存.城市軌道交通信息通信系統技術［J］.城市軌道交通研究，2003(6):27-30.

［5］曲立東.城市軌道交通環境與設備監控系統設計與應用［M］.北京:電子工業出版社，2008.

［6］蘇州軌道交通有限公司.蘇州軌道交通1號線綜合監控系統招標文件［G］.蘇州，2009.

［7］柳彥青，朱志平.城市軌道交通綜合監控系統淺述［J］.上海電器技術，2006(4):33-36.

［8］靳守杰.城市軌道交通綜合自動化系統研究［J］.城市軌道交通研究，2007(5):8-11.