滬寧城際和滬杭高鐵列控維護終端問題分析及處理

張培德　上海鐵路局上海高鐵維修段

1　引言

列控系統(tǒng)是高鐵信號系統(tǒng)核心設備之一，控制著軌道電路編碼、報文發(fā)送、發(fā)碼方向控制以及與聯(lián)鎖、CTC及相鄰站列控中心等其他系統(tǒng)進行大量信息交換，與行車安全關系密切，通過發(fā)揮列控維護終端的各種功能，能夠實現(xiàn)對列控系統(tǒng)有效監(jiān)控，及早發(fā)現(xiàn)設備隱患，指導設備維修工作。但是滬寧城際、滬杭高鐵開通時間較早，維護終端功能及相關配置等不能滿足維護需求，存在較多問題。

2　滬寧城際、滬杭高鐵開通初期運用狀況

滬寧城際、滬杭高鐵自2010年開通以來，我們通過對列控維護終端信息的瀏覽分析發(fā)現(xiàn)并解決了不少設備問題，對預防設備故障起到了很大作用，但是在日常的設備維修養(yǎng)護中發(fā)現(xiàn)列控維護終端功能不全，主要存在以下幾個方面的典型問題：

（1）CTC通信接口單元單板故障或關閉后維護終端沒有報警信息，滬寧城際18個車站都存在該問題。

（2）當某個移頻柜上下層僅一個區(qū)段時，維修機上對應的ZPW2000接收器并機沒有監(jiān)測信息，即沒有納入維修機監(jiān)測。滬寧城際、滬杭高鐵有28個此種區(qū)段都是如此。

（3）ZPW2000移頻機柜最后一個機柜內設備故障時，列控維護機不報警，通過檢查，滬寧城際、滬杭高鐵39個站所都存在此問題。

（4）CAN通信中斷報警頻繁。僅滬寧城際在開通第一年的一個季度該類報警就有178次之多，滬寧城際、滬杭高鐵

合計超過了200次。

3　存在問題原因分析

3.1　CTC通信接口單元單板故障不報警原因分析

列控中心與CTC通過兩塊通信接口單元CI-GS板進行通信，并且采用冗余的CAN總線通信方式。每塊CI-GS板通過兩個RS422串口以交叉冗余方式與CTC設備通信，CI-GS板采用內部通信協(xié)議將CAN總線數(shù)據(jù)與RS422串口數(shù)據(jù)進行協(xié)議轉換，因此兩塊CI-GS板分別同時與CANA、CANB進行通信。

通過與廠家溝通，檢查發(fā)現(xiàn)滬寧城際列控中心設備在針對CAN總線報警的邏輯是，只要CAN總線（CANA、CANB）有數(shù)據(jù)且校驗通過即視為通道正常，否則報通道中斷。當單塊CI-GS板故障或關閉一塊CI-GS板時，CAN總線（CANA、CANB）由于是冗余總線通道，總線上實際仍有正確的CTC設備數(shù)據(jù)流，故不會輸出報警。因此不報警的原因就是滬寧城際列控中心軟件不檢查CI-GS板的每一路通信狀態(tài)，所以維護終端不會有報警信息。

3.2　移頻柜兩層僅一個區(qū)段時接收器并機無監(jiān)測信息

針對此種情況，一是在常州城際檢查了現(xiàn)場配線，發(fā)現(xiàn)因沒有發(fā)送器等設備，相關通信數(shù)據(jù)不能通過正常配線直接溝通并送給CANC總線；第二聯(lián)系協(xié)調讓廠家檢查相關車站配置文件，發(fā)現(xiàn)此類區(qū)段列控維護終端配置數(shù)據(jù)不全，對上下僅有一個區(qū)段的僅僅配置了一個區(qū)段的數(shù)據(jù)信息，沒有配置接收并機的數(shù)據(jù)信息，所以沒有監(jiān)測信息。

3.3　最后一個移頻柜內設備故障不告警

在設備維護時偶然發(fā)現(xiàn)常州城際場最后一個移頻柜設備故障，列控維護終端不報警。針對此，對照圖紙檢查了常州城際CANC通信線，發(fā)現(xiàn)配線正確。于是在常州城際、無錫新區(qū)等站做了試驗，將不報警的數(shù)據(jù)信息拷貝發(fā)給通號設計院售后分析，通過廠家分析，發(fā)現(xiàn)列控維護終端已收到了來自軌道電路通信接口單元的所有移頻柜狀態(tài)信息（包括故障信息），但是確實沒有報警信息。再協(xié)調通號維護終端軟件研發(fā)人員到現(xiàn)場檢查，同時分析軟件問題，最后發(fā)現(xiàn)為維護終端軟件存在缺陷，導致最后一個移頻柜設備問題不報警。

3.4　CAN通信中斷報警頻繁

滬寧城際、滬杭高鐵開通后一年多，列控維護終端CAN通信報警頻繁。經(jīng)檢查，總共有兩類，一類是報警后沒有人工干預不會恢復，一類是在數(shù)秒后自動恢復，甚至一秒都不到就恢復。特別是滬寧中繼5和滬杭高鐵余杭站報警非常頻繁。一開始，采取重啟維護終端軟件，但是幾天后又會報警，后來對列控維護終端進行斷電重啟后連續(xù)一個多月都不報警。因此開始懷疑硬件或硬件驅動有問題。為此聯(lián)系上海電務段，詢問京滬高鐵有否類似問題，得到否定回答后，協(xié)調廠家對比滬寧城際、滬杭高鐵與京滬高鐵列控維護終端相關配置、硬件、軟件、硬件驅動等進行分析對比，發(fā)現(xiàn)京滬高鐵CAN卡驅動程序同滬寧城際、滬杭高鐵不一致，其它相關配置、軟、硬件都相同。基本確定了頻繁報警原因是CAN驅動程序不匹配導致。

4　問題處理

4.1　“CTC通信接口單元單板故障不報警”問題

通過上面的分析，此問題出現(xiàn)的原因是滬寧城際列控中心設備軟件與CTC通信報警機制引起。要求廠家修改列控中心軟件和列控維護終端軟件，對與CTC通信的（CI-GS板）的每一路通道都進行檢查，只要有一路發(fā)生問題就進行報警。在蘇州園區(qū)站進行了試驗，同時要求廠家將列控維護終端有原兩個指示燈改成與LEU通信一致的四路通道顯示方式（見圖1），使通信狀態(tài)情況更加直觀。并且結合后續(xù)列控軟件修改進行同步修改，目前滬寧城際該問題已全部解決，滬杭高鐵結合區(qū)間邏輯檢查軟件修改也已完成了5個站的問題克缺。

圖1　與CTC通信顯示

4.2　“移頻柜兩層僅一個區(qū)段時接收器并機無監(jiān)測信息”問題

圖2　接收并機數(shù)據(jù)信息

針對檢查分析原因，一方面排查所有僅有一個區(qū)段的接收器并機CANC線有沒有跳通，通過排查發(fā)現(xiàn)存常州城際、余杭、鎮(zhèn)江城際等共有6個站通信線沒有跳通，在通信工廠的指導下進行了跳通；另一方面協(xié)調廠家對列控維護終端的的相關數(shù)據(jù)配置文件進行了修改、測試，并配合廠家在現(xiàn)場進行了更換，經(jīng)過試驗確認，原28個沒有監(jiān)測信息的接收器并機在列控維護終端都有了數(shù)據(jù)信息（見圖2），且故障時都有報警，被監(jiān)測功能。

4.3　“最后一個移頻柜內設備故障不告警”問題

針對分析發(fā)現(xiàn)問題的原因，協(xié)調廠家研發(fā)修改列控維修機軟件，在廠家修改并完成內部測試后，首先在滬寧城際無錫新區(qū)站進行了試點，經(jīng)試驗最后一個移頻柜內設備故障列控維修機能報警（見圖3）。運用2周無異常后，在滬寧城際、滬杭高鐵進行推廣實施，徹底解決了最有一個移頻柜內設備故障無報警問題，完善了列控維護終端功能。

圖3　最后一個移頻柜處理后報警圖

4.4　“CAN通信中斷報警頻繁”問題

根據(jù)上面的分析，通過供應商與CAN卡生產(chǎn)溝通協(xié)調，以及供應商內部測試確認了原CAN卡驅動程序在列控維護終端軟件運行一定時間后，由于維護終端軟件存取數(shù)據(jù)原因會造成CAN通信中斷。為此，又調閱分析了列控維護終端報警數(shù)據(jù)，發(fā)現(xiàn)90%以上CAN通信中斷報警都是在列控維護終端數(shù)據(jù)定時存儲時發(fā)生。于是果斷更新了滬寧城際、滬杭高鐵所有列控維護終端CAN卡驅動程序。同時對維護終端尾纖進行了擦拭，對檢查發(fā)現(xiàn)生產(chǎn)日期較早，報警特別頻繁的（如滬杭高鐵余杭站、滬寧城際中繼5站等）CAN卡進行了更換。第三，在分析配置時，通號廠家發(fā)現(xiàn)滬寧城際、滬杭高鐵針對CAN通信主備數(shù)據(jù)一致性延時時限不一致，有1s、2s、5 s幾種，統(tǒng)一按照京滬高鐵的5s進行了修正，從一定程度上也解決了不少無效報警。采取上述措施處理后，CAN通信中斷報警有開通初期的每個季度200多次到目前每個季度偶發(fā)一兩次，報警數(shù)量大幅度降低。

5　結束語

通過以上分析和處理，滬寧城際、滬杭高鐵列控維護終端問題功能得到了完善，同時減少了很多無效報警，維護終端的設備穩(wěn)定性也到了提高。但是還有不少未知的問題，如偶發(fā)移頻柜通信中斷刷屏問題等，還需和設備廠家一起進行深入分析，來發(fā)現(xiàn)問題原因，以更好的為列控設備維修提供可靠依據(jù)。

[1]《高速鐵路信號技術》（中國鐵道出版社.2012年）.

[2]《高速鐵路信號維護規(guī)則》（中國鐵道出版社.2016年）.