從幾起故障談集中監測系統報警功能的改進

謝鶯燕

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

?

從幾起故障談集中監測系統報警功能的改進

謝鶯燕

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

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

關鍵詞：信號集中監測系統；報警；功能改進

10.13572/j.cnki.tdyy.2016.03.021

信號集中監測系統是鐵路運輸的重要行車設備，它既能實時將信號設備運用狀態、各種電氣特性反映出來，又能對設備以前的運行數據進行一定時間段的保存，以供設備維護管理人員對設備實時狀態及一段時間以來的運行狀況進行調閱分析，科學指導設備維修，及時發現設備問題隱患杜絕信號故障發生。

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

1　故障案例概述

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

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

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

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

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

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

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

2　原因分析

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

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

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

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

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

圖6　檢修狀態下報警邏輯示意圖

2.4存在問題

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

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

3　解決措施及建議

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

設置N長度的循環隊列：

m_lst［N］

m_sum=m_sum-m_lst（pointer_begin）；

moveon（pointer_begin）；

byte val_end=0；

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

｛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）｛產生報警；｝

具體情形如圖7所示。

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

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

在天窗結束時，讀取該段時間內的報警數據：

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

｛If（m_alarmlst（i）未恢復）

｛將報警上傳監測服務器和生產指揮系統 ｝｝

具體情形如圖8所示。

圖8　改進后的檢修狀態下報警邏輯示意圖

3.3檢修管理工作改進建議

1）結合調度指揮平臺的建設，研發專項軟件，對管內天窗作業后，再次進行報警掃描，給工區、車間、段發出報警。

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

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

4　結束語

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

中圖分類號：U284.36+2

文獻標識碼：B

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