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

1　引言

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

2　滬寧城際、滬杭高鐵開通初期運(yùn)用狀況

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

（1）CTC通信接口單元單板故障或關(guān)閉后維護(hù)終端沒有報(bào)警信息，滬寧城際18個(gè)車站都存在該問題。

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

（3）ZPW2000移頻機(jī)柜最后一個(gè)機(jī)柜內(nèi)設(shè)備故障時(shí)，列控維護(hù)機(jī)不報(bào)警，通過檢查，滬寧城際、滬杭高鐵39個(gè)站所都存在此問題。

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

合計(jì)超過了200次。

3　存在問題原因分析

3.1　CTC通信接口單元單板故障不報(bào)警原因分析

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

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

3.2　移頻柜兩層僅一個(gè)區(qū)段時(shí)接收器并機(jī)無(wú)監(jiān)測(cè)信息

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

3.3　最后一個(gè)移頻柜內(nèi)設(shè)備故障不告警

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

3.4　CAN通信中斷報(bào)警頻繁

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

4　問題處理

4.1　“CTC通信接口單元單板故障不報(bào)警”問題

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

圖1　與CTC通信顯示

4.2　“移頻柜兩層僅一個(gè)區(qū)段時(shí)接收器并機(jī)無(wú)監(jiān)測(cè)信息”問題

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

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

4.3　“最后一個(gè)移頻柜內(nèi)設(shè)備故障不告警”問題

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

圖3　最后一個(gè)移頻柜處理后報(bào)警圖

4.4　“CAN通信中斷報(bào)警頻繁”問題

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

5　結(jié)束語(yǔ)

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

[1]《高速鐵路信號(hào)技術(shù)》（中國(guó)鐵道出版社.2012年）.

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