從幾起故障談集中監(jiān)測系統(tǒng)報警功能的改進

謝鶯燕

（南寧鐵路局調(diào)度所，工程師，廣西　南寧市青秀區(qū)佛子嶺路21號　郵編530029）

?

從幾起故障談集中監(jiān)測系統(tǒng)報警功能的改進

謝鶯燕

（南寧鐵路局調(diào)度所，工程師，廣西南寧市青秀區(qū)佛子嶺路21號郵編530029）

摘要：通過對幾起故障的分析，針對信號集中監(jiān)測系統(tǒng)軟件存在設備電氣特性超限不報警等問題，提出監(jiān)測系統(tǒng)軟件功能改進方案，完善監(jiān)測系統(tǒng)軟件功能，防止類似事件的發(fā)生，使之更好的發(fā)揮“預警機”的作用。

關鍵詞：信號集中監(jiān)測系統(tǒng)；報警；功能改進

10.13572/j.cnki.tdyy.2016.03.021

信號集中監(jiān)測系統(tǒng)是鐵路運輸?shù)闹匾熊囋O備，它既能實時將信號設備運用狀態(tài)、各種電氣特性反映出來，又能對設備以前的運行數(shù)據(jù)進行一定時間段的保存，以供設備維護管理人員對設備實時狀態(tài)及一段時間以來的運行狀況進行調(diào)閱分析，科學指導設備維修，及時發(fā)現(xiàn)設備問題隱患杜絕信號故障發(fā)生。

自2015年以來，南寧局管內(nèi)連續(xù)發(fā)生多起軌道電路和應答器故障，暴露出設備異常電氣特性超限時集中監(jiān)測系統(tǒng)報警功能缺陷問題，該問題在全路系統(tǒng)中均存在，本文結合現(xiàn)場運用情況，提出改進建議。

1　故障案例概述

案例1 2015年11月4日湘桂線南寧南一場130-132DG區(qū)段紅光帶故障，原因是扣件碰魚尾板（如圖1所示）。故障前130-132 DG調(diào)整狀態(tài)下電壓調(diào)整狀態(tài)下電壓為12.32 V低于下限值，長期嚴重超下限，集中監(jiān)測軟件未報警。

圖1　南寧南一場扣件碰魚尾板圖片

案例2 2015年12月21日南憑線瀨湍站3G車過后紅光帶不消失故障，影響貨車42082次。原因是XIII處兩邊鋼軌軌縫拉開后粘接式膠接絕緣破損造成（如圖2所示）。故障前本區(qū)段電壓在0～4 V、相鄰軌道區(qū)段2～4 DG電壓在5.3～14.4 V、2～4 DG1在5.8～14.5 V間波動，調(diào)整狀態(tài)下電壓III G電壓為15.6 V、2～4DG電壓為14.9V、2～4 DG1電壓為15.4 V，嚴重超下限（如圖3所示），集中監(jiān)測軟件未報警。

圖2　瀨湍站粘接式絕緣測試圖片

圖3　瀨湍站軌道電壓超限曲線

案例3 2016年1月8日高鐵貴廣線D 2801次貴陽至廣州南，在三江南站下行3道接車時ATP報“應答器異常，應答器丟失”輸出SB 7制動停車故障。影響D 2801次、D 3521次站內(nèi)非正常停車。原因是三江南站列控中心綜合柜內(nèi)LEU 3的S接口板2壞。故障前天窗點內(nèi)0:38:31發(fā)生的二級報警“LEU-3通信故障，端口1、2、3、4故障”，至天窗點結束后未恢復，故障發(fā)生后10:19:45才恢復。

2015年因工務病害造成軌道電路故障31件，因報警功能不完善，軟件邏輯設計不合理等問題造成報警不正確不及時，未能提前發(fā)現(xiàn)故障趨勢。

2　原因分析

2.1模擬量超限報警技術規(guī)范對于信號機電流、25 HZ軌道電壓、25 HZ軌道相位角、外電網(wǎng)相位角、ZPW 2000軌道電壓、軌道電流等幾類模擬量，一旦某一時間點的數(shù)字在設定的上下限范圍之外，即超限。

2.2模擬量超限報警邏輯超限報警的邏輯條件：1、相關的開關量條件符合（例如分析軌道電壓調(diào)整超限時、軌道繼電器狀態(tài)需是吸起狀態(tài)）；2、模擬量超出設定的上下限范圍；3、超限的時間保持5秒（可動態(tài)配置）或以上。以上3個條件必須同時滿足時發(fā)出報警。例如圖4所示的模擬量，一旦某一時間點的數(shù)值在設定的上下限范圍之外，即超限。程序并不會立即發(fā)生超限報警，而是要對該時刻之后5 s內(nèi)的數(shù)據(jù)進行綜合判斷，如果一直都維持為超上限或者是超下限狀態(tài)，則集中監(jiān)測才會確認為有效的超限報警。

圖4　模擬量超限報警邏輯示意圖

圖5　模擬量超限報警邏輯示意圖

設置這樣的邏輯的最主要的目的在于過濾事實上存在的數(shù)據(jù)毛刺，進一步減少誤報警和無效報警。具體情形如圖5所示2.3檢修狀態(tài)下的報警邏輯天窗修時在車站集中監(jiān)測系統(tǒng)中設置檢修狀態(tài)，期間發(fā)生的報警標注為檢修狀態(tài)，不向各調(diào)閱終端發(fā)送實時報警，天窗修結束后，期間發(fā)生的報警已經(jīng)恢復的檢修狀態(tài)不變，未恢復的報警只取消其標注的檢修狀態(tài)。具體情形如較圖6所示。

圖6　檢修狀態(tài)下報警邏輯示意圖

2.4存在問題

2.4.1超限報警邏輯錯誤條件“超上下限”和“持續(xù)超限時間”的關系為共同滿足才報警的關系。造成抖動狀態(tài)下的超限模擬量不報警。

2.4.2檢修狀態(tài)取消后報警缺陷天窗修結束后，檢修人員取消檢修狀態(tài)，天窗修期間發(fā)生的報警是否都已恢復需要人工確認，不能自動對未恢復的報警做出提醒，或再次報警，存在遺漏報警的隱患。

3　解決措施及建議

3.1修改微機監(jiān)測軟件將判斷邏輯修改成滿足其一就報警的關系，滿足在模擬量長期超限的情況下及時報警的目的。改進后增加以下編程內(nèi)容：

設置N長度的循環(huán)隊列：

m_lst［N］

m_sum=m_sum-m_lst（pointer_begin）；

moveon（pointer_begin）；

byte val_end=0；

If（開關量狀態(tài)符合，例如軌道繼電器吸起）

｛If（實測值＞上限or實測值＜下限）then

m_lst（pointer_end）=1；｝

moveon（pointer_end）；

m_lst（pointer_end）=val_end；

m_sum=m_sum+val_end；

if（m_sum≥Y）｛產(chǎn)生報警；｝

具體情形如圖7所示。

圖7　改進后的模擬量超限報警邏輯示意圖

3.2增加編程內(nèi)容 檢修狀態(tài)取消后，檢查期間報警是否恢復，對未恢復的報警再次報警或提醒的功能，防止人為失誤，遺留未恢復的報警。改進后增加以下編程內(nèi)容：

在天窗結束時，讀取該段時間內(nèi)的報警數(shù)據(jù)：

For（int i=0；i＜m_alarmlst.size（）；i++）

｛If（m_alarmlst（i）未恢復）

｛將報警上傳監(jiān)測服務器和生產(chǎn)指揮系統(tǒng) ｝｝

具體情形如圖8所示。

圖8　改進后的檢修狀態(tài)下報警邏輯示意圖

3.3檢修管理工作改進建議

1）結合調(diào)度指揮平臺的建設，研發(fā)專項軟件，對管內(nèi)天窗作業(yè)后，再次進行報警掃描，給工區(qū)、車間、段發(fā)出報警。

2）完善作業(yè)程序，規(guī)定檢修作業(yè)或施工配合等作業(yè)后必須人工調(diào)閱全站一、二、三級報警，全面檢查施工、維修涉及的設備電氣特性是否發(fā)生變化。

3）定期對信號集中監(jiān)測功能進行實測檢驗，排除監(jiān)測功能失效，維護人員長期不發(fā)現(xiàn)的頑疾。

4　結束語

通過以上分析，找到了監(jiān)測系統(tǒng)不報警的主要原因和改進措施；經(jīng)現(xiàn)場驗證應用效果良好，軟件升級后徹底解決了全路監(jiān)測軟件超限不報警問題；檢修狀態(tài)取消后報警缺陷問題，建議路局和設備廠家加強重視，不斷完善監(jiān)測軟件功能。

中圖分類號：U284.36+2

文獻標識碼：B

文章編號：1006-8686（2016）03-0058-03