關于CRH1型動車組TCMS系統故障分析方法的應用

項 穎

(青島四方龐巴迪鐵路運輸設備有限公司 市場和檢修部，山東 青島 266111)

隨著動車組技術的飛速發展，越來越多的動車組行駛在祖國的大江南北。動車組列車每天運行時間長、里程長，在運行過程中不可避免地會遇到各種各樣的故障。因此，對故障進行快速診斷、及時分析出故障發生的根本原因并針對性地及時處理解決所發生的故障是確保動車組可靠運行的根本保障。故障原因分析根據故障發生的性質、位置、現象等不同的維度有各種不同的分析方法，本文主要介紹CRH1型動車組列車網絡控制系統(TCMS系統)所報故障的一些典型的故障原因分析方法。

CRH1型動車組TCMS系統采用MITRAC電腦系統，用于列車的通信和控制。MITRAC電腦系統是一種分布式電腦系統，是由龐巴迪公司為地鐵、動車組等所設計的通用電腦系統。MAVIS軟件是針對MITRAC系統所設計的一款離線故障分析軟件，所分析的數據是由車載診斷系統(TDS)所記錄的車載故障/環境數據(ODBS)。MAVIS軟件對車載ODBS數據進行的是基礎分析，提供了故障發生的位置、時間、描述以及故障發生前后相關的環境數據等信息。然而有很多故障還需要結合其他的手段進行綜合分析，才能找到問題的根本原因。下面介紹2種比較典型的TCMS系統故障分析方法的應用。

1 結合ODBS數據和列車網絡拓撲原理圖對故障進行分析

動車組列車有一類比較典型的故障是網絡通信故障，往往此類故障的故障點可能很小，但給動車組造成的影響卻較大。

例如，2019年1月25日，CRH1B-1059型動車組在漢口站停靠時發生列車網絡通信故障，經主控復位、蓄電池接觸器斷電復位、網絡電源斷路器復位后，仍然不能恢復正常。列車回庫后，通過MAVIS軟件對下載的ODBS數據分析發現，自12:49:42開始至12:51:28這段時間內，1、2、5、6、7、8車報出大量MVB網絡設備通信故障，部分數據節選見圖1。

圖1 CRH1B-1059型動車組部分網絡通信故障數據

結合列車網絡設備拓撲原理圖以及MAVIS軟件對故障發生期間ODBS數據進行分析。分析發現，在這段時間內，6、7、8車共有24個設備發生了MVB網絡通信故障，具體見圖2中標黃的設備。從圖2可以初步看出，故障可能發生在標記紅色箭頭線路的區段之內。

DX.數字量輸入輸出單元；VC.列車控制單元；BCC.充電機控制單元；AX.模擬量輸入輸出單元；BCU.制動控制單元；DCU95/96.外門控制單元；ACU.空調控制單元；GW.網關；DCU49/M1、DCU4C/M2.電機變流器；DCU41/L1.網側變流器；DCU51/A1.輔助變流器。

由于MVB網絡通信受干擾所報出的故障通常為閃報，即受影響的設備故障時而發生時而結束，無法準確判斷故障點的位置。通過對一個小區段故障數據的進一步梳理，發現有一些設備的網絡通信故障一直沒有結束，因此可以嘗試把故障已經結束的和沒有結束的設備進行區分以進行進一步分析。圖3為故障已結束和未結束的設備區分，在12:49:42—12:51:28內，MVB網絡通信故障未結束的設備被標記為紅色。

由圖3可以發現，從6車DX7A以后，所有設備均發生MVB網絡通信故障，且故障持續存在，說明故障點很有可能在DX7A或DX7A與DCU93之間的連接電纜上，這樣就在大量的網絡通信故障中縮小了故障點的范圍，為后續的故障查找大大節約了時間。后續經過對現車仔細檢查發現，故障是由于DX7A的MVB插頭X2的1點虛接導致，驗證了之前的分析是合理的。

圖3 MVB網絡通信故障已結束和未結束的設備區分

結合ODBS數據和列車網絡拓撲原理圖對故障進行分析，是調查故障原因通常所采用的思路。這需要對整車系統的原理有較好的理解，同時也要不斷在動車組運用維修過程中積累大量的實踐經驗，才能為后續的故障調查提供有力的技術保障。

2 結合現車模擬試驗對故障進行分析

某些故障只在特定的情況下發生，通過分析ODBS數據很難發現觸發故障的原因，因為故障可能跟當時列車的工況、司機或機械師的操作等其他狀態密切相關。這種情況下，可以通過在現車做一些試驗對故障進行模擬和再現，同時利用監控軟件DCUTerm實時記錄列車相關參數的變化，以便為后續的故障分析提供數據支持。

例如，2017年4月24日20時03分，CRH1E-1061型動車組在運行途中發生15車2軸軸溫超溫A類報警(故障代碼：2225)，列車因軸溫超溫停車，機械師下車點溫正常，司機發現智能顯示單元(IDU)上顯示該軸軸溫已恢復正常。按照《應急故障處理手冊》要求，司機按下IDU軸溫界面的“復位報警器”按鈕后解除A類報警，同時緩解了最大常用制動。在發車之前，該軸再次報出軸溫超溫報警故障，30 s后TCMS系統自動施加最大常用制動。司機點擊IDU軸溫界面的“釋放聯鎖”按鈕后，“釋放聯鎖”按鈕顯示被激活，最大常用制動緩解，司機繼續行車。后續途中再次發生2次因溫超溫故障導致動車組施加最大常用制動停車的情況，第3次停車后司機主控復位，再次點擊“釋放聯鎖”按鈕后，緩解最大常用制動，繼續后續交路運行。

按照動車組對軸溫超溫的控制邏輯，當“釋放聯鎖”按鈕顯示被激活后，后續再發生因該軸超溫故障將不再施加最大常用制動。此次故障造成較大影響是因為后續途中該軸又連續2次發生軸溫超溫報警，司機雖然按照《應急故障處理手冊》要求在IDU上操作“釋放聯鎖”按鈕，而且“釋放聯鎖”按鈕也顯示處于被激活狀態，但實際動車組最大常用制動并沒有被真正旁路掉，而直接導致動車組后續在途中2次被迫停車。

動車組回庫后，通過ODBS數據記錄及相關環境數據無法分析出“釋放聯鎖”按鈕被激活后動車組仍然施加最大常用制動的原因。鑒于此類問題可能跟列車的工況、司機的操作等因素密切相關，因此考慮通過現車模擬故障再現的方法進一步調查故障原因。

使用DCUTerm軟件對動車組的運行速度、15車2軸的軸溫信號進行更改，使動車組故障與運行途中一致，并試驗“釋放聯鎖”按鈕的各種工況。經模擬發現，不同工況下使用“釋放聯鎖”按鈕會出現以下不同的情況：

(1) 當動車組軸溫尚未達到超溫值或者達到超溫值尚未觸發報警時(超溫持續超過30 s后報警)，按“釋放聯鎖”按鈕無效，“釋放聯鎖”按鈕灰色維持不變；

(2) 軸溫超溫觸發報警，但尚未觸發常用制動時(報警后30 s觸發)，按下“釋放聯鎖”按鈕，“釋放聯鎖”按鈕由灰色變為白色(表示“釋放聯鎖”按鈕被激活)，報警后30 s仍然觸發最大常用制動，并且軸溫下降到正常溫度后，最大常用制動依舊無法緩解；

(3) 當軸溫超溫觸發最大常用制動后，且軸溫仍在超溫范圍時，按下“釋放聯鎖”按鈕，可以解除制動聯鎖，“釋放聯鎖”按鈕由灰色變為白色(表示“釋放聯鎖”按鈕被激活)，后續無論該故障軸溫如何變化均不會引起動車組自動觸發最大常用制動；

(4) 當軸溫超溫觸發最大常用制動的同時按下“釋放聯鎖”按鈕，“釋放聯鎖”按鈕由灰色變為白色(表示“釋放聯鎖”按鈕被激活)，軸溫下降到正常溫度后，常用制動緩解。當該軸軸溫再次超溫時，再次觸發最大常用制動，此模擬試驗結果與動車組運行途中發生的故障現象一致。

現車模擬故障時通過DCUTerm軟件進行相關狀態的監控如圖4所示。

F2225.超溫報警；F2273.軸溫預警；PLFSBHB.施加最大常用制動；PLRELIDU.IDU“釋放聯鎖”按鈕激活；PLRELINT.釋放聯鎖(主控)；PLXRELIN.釋放聯鎖(本地)；PLXRELLK.IDU“釋放聯鎖”按鈕；PLOVTTRN.軸溫超溫狀態；PLXNEWOT.列車有新的軸溫超溫報警；PLXSPD0.列車速度為0；PLFSB505.下降沿延時；PLFSB510.上升沿延時；CTAI2204.軸溫；BLXPRS11.制動缸壓力。

軟件邏輯中關于“釋放聯鎖”解除、激活及施加最大常用制動的邏輯見圖5。

PLFSBPX.互鎖及常用制動模塊；PLXRESET.主控復位；PLOVTMM. 列車超溫警報。

通過上述軟件邏輯分析可知，如果需要緩解由于軸溫超溫所施加的最大常用制動需要滿足以下任意一個條件：

(1) 在列車靜止狀態下，故障軸超溫的狀態持續恢復正常；

(2) 通過點擊IDU“釋放聯鎖”按鈕，激活釋放聯鎖功能并被鎖存。

由于故障軸的軸溫有時處于超溫狀態，有時又恢復正常狀態，第1條與實際情況不符。因此只有通過點擊IDU“釋放聯鎖”按鈕來激活釋放聯鎖功能并鎖存。結合模擬試驗的結果發現，在車速為0、軸溫仍然處于超溫狀態且恰好有新的軸溫超溫報警工況條件下，在軸溫超溫報警后第31～36 s內操作“釋放聯鎖”按鈕，此時雖然IDU顯示釋放聯鎖被激活，但控制系統內的釋放聯鎖功能并未真正激活，下降沿延時和上升沿延時會通過RS鎖存器屏蔽IDU“釋放聯鎖”按鈕的信號，此時施加最大常用制動的指令仍一直顯示被激活，因此無法實現旁路后續超溫導致的最大常用制動的功能，如圖6所示。( )

圖6 “釋放聯鎖”信號被屏蔽

如果在有新的軸溫超溫報警后第36 s以后操作“釋放聯鎖”按鈕，釋放聯鎖功能被激活并鎖存，施加最大常用制動的指令也同時被取消，列車最大常用制動被緩解，如圖7所示。

圖7 釋放聯鎖功能被激活

通過結合現車模擬試驗和深入分析，不僅找到了故障的根本原因，還發現了軟件邏輯設計中存在的一些缺陷，也為軟件優化設計提供了實踐檢驗的結果和優化方案。因此，通過現車模擬試驗查找故障或者是進行功能驗證的方法也值得大力提倡。