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

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

1　引言

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

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

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

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

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

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

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

合計超過了200次。

3　存在問題原因分析

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

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

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

3.2　移頻柜兩層僅一個區段時接收器并機無監測信息

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

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

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

3.4　CAN通信中斷報警頻繁

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

4　問題處理

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

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

圖1　與CTC通信顯示

4.2　“移頻柜兩層僅一個區段時接收器并機無監測信息”問題

圖2　接收并機數據信息

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

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

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

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

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

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

5　結束語

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

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

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