車輛運行品質安全監測系統報警車輛聯網監控的研究及實現

史曉磊，蔣 薈

（中國鐵道科學研究院集團有限公司 電子計算技術研究所， 北京 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預警車輛聯網監控。該方案在北京鐵路局豐臺車輛段成功試用，經過測試，系統功能得到優化和完善，故障車輛得到及時處置，有效避免了行車事故的出現，具有廣闊的應用前景。