车辆运行品质安全监测系统报警车辆联网监控的研究及实现

史晓磊，蒋 荟

（中国铁道科学研究院集团有限公司 电子计算技术研究所， 北京 100081）

车辆运行品质轨边动态监测系统（TPDS）是利用安装在铁路正线直线段上的检测平台，对货车运行安全进行动态检测的轨边监测系统，重点检测货车脱轨系数、轮重减载率等轮轨间的动力学参数，为保障车辆安全运行发挥了十分重要的作用。由于TPDS探测设备数量有限，设备间距较长，未处理报警车辆不能及时处理，存在严重的安全隐患。文献[1] 提出全路红外轴温探测设备分布、数量与列检隶属关系，为TPDS报警车辆联网监控研究提供了重要思路。文献[2] 详细介绍了红外轴温探测系统数据采集流程，为本研究提供了数据接取时机和节点。本文针对TPDS探测站数量较少、部分报警车辆不能及时处理等问题，借助红外线轴温探测系统，当车辆通过红外线轴温探测设备时，自动匹配TPDS探测报警数据，实时向前方列检推送TPDS报警车辆信息，以提高报警车辆处理率。

1 联网监控方案实现

红外线轴温探测系统（THDS）[1]是5T安全监测系统的重要组成部分，具有设备数量多，分布密集的特点。借助THDS这一特点，将未处理的TPDS检测报警车辆复示给后方列检作业场，及时处理问题车，实现联网监控目标。具体思路是：将全路TPDS探测站检测到的未处理报警车辆实时汇总到铁路总公司（简称：总公司）数据库服务器，形成全路报警车辆名单，定期下发至18个铁路局数据库服务器；当列车通过列检作业场前方红外线轴温探测设备时，由部署在铁路局服务器上的WebService服务器获取THDS检测信息[2]，并与铁路局级报警车辆名单进行匹配，再复示给列检作业场。

1.1 数据流程

由18个铁路局服务器实时上传未处理的TPDS报警车辆数据[3]到总公司服务器，形成全部报警车辆名单，总公司服务器定期同步到各个局服务器。数据流程图如图1所示。

图1 TPDS检测未处理报警车辆数据流程

TPDS数据库服务器定时获取THDS检测数据，并与报警车辆名单进行匹配入库，由TPDS复示给列检作业场，数据流程如图2所示[4]。

图2 TPDS报警数据与THDS检测数据匹配流程

1.2 相关规则

1.2.1 报警车辆预报规则

根据列检作业场是否有TPDS探测设备，分为有TP列检和无TP列检，采用本地探测和联网报警推送两种模式复示报警车辆。对于有TP列检，采用两种模式进行推送（本地探测中已有且报警时间在10 h内的报警车辆不在联网推送名单中出现）；对于无TP列检，只推送联网报警车辆。

本地探测模式根据列检作业场与TPDS测点所属关系推送最近10 h内报警车辆；联网报警模式推送最近2 h内通过THDS测点的报警车辆。

建立列检作业场字典，包括编码、名称、所属铁路局、所属车辆段、有无TPDS测点；建立列检作业场与入口THDS测点[5]关系字典，用于复示联网报警车辆。

1.2.2 报警车辆销号规则

对于联网推送的报警车辆，如果列检作业场已经处理，需要及时销号，避免重复推送给下一个列检作业场，具体销号规则如表1所示。

表1 联网推送报警车辆销号规则

依照上述规则，销号流程为：（1）对作业列检对应的铁路局报警名单销号；（2）对总公司报警名单销号；（3）由总公司服务器将销号数据分发到其他铁路局服务器，更新相应的报警车辆名单。

2 功能设计

2.1 实时监控

（1）本地探测模式推送的列车信息，以列车为单位，包含列车基本信息、踏面损伤[6]、运行状态预警、超偏载报警辆数以及报警车辆处理回填入口。

（2）以踏面损伤轮位或者运行状态预警车辆为单位，联网报警模式推送的报警车辆信息包括：TPDS[7]测点检测到的报警信息，列检入口THDS测点和检测列车信息，处理回填入口[8]。实时监控界面图如图3所示。

图 3 实时监控界面

2.2 报警处理反馈

报警处理反馈提供对通过列车全部的踏面损伤和运行状态预警车辆批量回填功能，根据业务规则，对回填信息进行校验。界面如图4所示。

图 4 报警车辆信息反馈

2.3 联网监控历史查询

历史查询提供对联网推送历史报警车辆查询，可以通过车号、首尾车号、预警时间等条件组合查询。

2.4 报警提示配置

当有新的报警车辆出现时，实时监控功能会弹出报警车辆提示框，用户可以通过报警提示配置功能，自定义报警种类、等级、提示时间等，满足个性化需要。

2.5 报警车辆处理查询

报警车辆处理查询提供对报警车辆处理结果查询功能，包括本地探测和联网报警推送的报警车辆处理信息，同时对处理轮数、运行状态预警量数进行统计，铁路局、车辆段管理层用户可以查看同一报警车辆的不同列检的作业情况。界面如图5所示。

图 5 TPDS联网报警车辆处理信息查询

2.6 统计报表

统计报表包括18点运用日报和货车运用报告两种报表，18点运用日报根据用户级别统计下级单位在本地探测和联网报警两种模式下检测列数、辆数、踏面损伤和运行状态预警处理辆数和件数等信息；货车运用报表提供不统计级别单位的日报、月报、季报以及年报报表。界面如图6所示。

图 6 TPDS 18点运用日报

3 现场测试与问题反馈

3.1 现场测试

本系统在北京铁路局丰台车辆段管内13个运用车间中的22个列检作业场进行了10天的测试。试用期间，共计推送报警列车1 668列，报警车辆462辆，扣车21辆，其中，踏面损伤一级报警3辆，踏面损伤二级报警5辆，踏面损伤三级报警13辆。具体数据汇总如表2所示。

表2 丰台车辆段报警车辆推送汇总

3.2 问题反馈

（1）多个列检作业场推送时间比列车实际到达时间晚，一般相差20～30 min，值班员不能及时通知外勤列检员。延时较为严重的是丰西一场，延时5～10 min占30%，延时20～30 min占70%。

（2）部分以直通车为主的列检作业场，实际技检作业辆数非常少，以沙城作业场为例，实际作业占报警辆次的1.71%，石景山作业场实际作业辆数为0，绝大多数报警车辆需要人工回填为通过，增加了列检作业量。

4 方案改进及测试

4.1 原因分析

经过分析发现，现场反馈的第一个问题主要是因为TPDS报警车辆与THDS过车数据匹配时间过长导致延时，其数据匹配过程为：THDS探测站采集过车信息上传至铁路局监控主机，通过接口服务器上传至THDS三级联网服务器（这一过程需要5 min），由部署在5T服务器上的服务定期从THDS三级联网服务器获取THDS过车数据与TPDS报警数据进行匹配（一般需要5 min），实时监控功能刷新数据时间为2 min。由此估算，自过车通过THDS探测站至预报给列检至少需要12 min，考虑网络延时等问题，实际延时可达到20 min左右。

以沙城、石景山南、三家店为代表的3个列检作业场，80%的列车为通过车，不进行技检作业，大量通过车需要人工标注直通，耗时耗力。

4.2 方案改进

（1）改进数据匹配过程，THDS过车数据经过探测站上传到铁路局监控主机，由监控主机利用JWMQ将THDS探测站的ATIS车号报文直接转发给铁路局5T服务器，再由5T系统进行解析、匹配和入库。

（2）在现有的列检字典增加是否直通列检属性，对于直通列检当前时间距离THDS过车时间超过4 h且未回填的报警车辆，系统自动标注到达情况为直通，并记录填写单位和时间等信息。

4.3 测试

改进后的系统在北京铁路局丰台车辆段再次测试，系统共预报2 216次，通过THDS探测站到预报全部在5 min内完成，其中，自THDS过车时间到铁路局5T服务JWMQ接收入库时间（传输时间）2 min以内占比94%；自JWMQ接收入库时间到预报时间1 min以内占比为87%；全部完成时间在3 min以内占比为89%，剩余11%在3～5 min以内预报。实践证明，改进后的方案能够很大程度上减少传输耗时，满足列检作业需要。

5 结束语

通过借助THDS探测站数量多、分布广泛的优势，建立前方THDS探测站与列检对应关系，当列车途经THDS探测站时，系统自动匹配未处理的预警数据，并复示给前方列检，实现TPDS预警车辆联网监控。该方案在北京铁路局丰台车辆段成功试用，经过测试，系统功能得到优化和完善，故障车辆得到及时处置，有效避免了行车事故的出现，具有广阔的应用前景。