項 穎

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

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

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

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

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

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

圖1 CRH1B-1059型動車組部分網絡通信故障數(shù)據(jù)

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

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

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

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

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

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

2 結合現(xiàn)車模擬試驗對故障進行分析

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

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

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

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

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

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

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

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

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

現(xiàn)車模擬故障時通過DCUTerm軟件進行相關狀態(tài)的監(jiān)控如圖4所示。

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

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

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

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

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

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

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

圖6 “釋放聯(lián)鎖”信號被屏蔽

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

圖7 釋放聯(lián)鎖功能被激活

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