从几起故障谈集中监测系统报警功能的改进

谢莺燕

（南宁铁路局调度所，工程师，广西　南宁市青秀区佛子岭路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