TDCS/CTC系統站間透明方式及信息中斷故障分析

王文芳

（中國鐵路呼和浩特鐵路局集團有限公司，工程師，內蒙古 呼和浩特，010057）

列車調度指揮系統（以下簡稱TDCS系統）/調度集中系統（以下簡稱CTC系統）采用三層結構，第一層為中國鐵路集團總公司調度中心，第二層為鐵路局集團公司調度中心，第三層為鐵路局集團公司所屬車站子系統；三層結構相互依存緊密銜接構成覆蓋全國鐵路的調度指揮網絡。車站子系統采用專線方式、環形結構組網，TDCS車站每8至15個車站有一套通道返回TDCS/CTC中心，CTC車站每5至10個車站有一套通道返回TDCS/CTC中心。每個車站要顯示本站和鄰站及區間信號設備狀態信息。本站信息由本站聯鎖、列控、區間信息采集設備提供，鄰站信息通過網絡來傳遞。由于中國鐵路呼和局集團公司管內TDCS系統、CTC2.0系統、CTC3.0系統共存，所以車站間信息傳遞存在多種方式。

1 TDCS/CTC系統站間透明方式

1.1 同一個網絡同一個環當車站同在TDCS網內或CTC網內，且同在一個環里，站間表示信息交互通過站間通道實現。如圖1所示：

圖1 同網同環網絡結構圖

圖1 中5個車站形成一個環。新安莊本站要看鄰站豐鎮和紅砂壩車站信息，豐鎮和紅砂壩通過站間通道傳遞信息。新安莊車站NPC將信息通過站間通道傳遞到紅砂壩車務終端。同樣的，紅砂壩車站NPC將信息通過站間通道傳遞到新安莊車務終端，完成站間透明。

1.2 同一個網絡不同環當車站同TDCS網里或CTC網里，但是不在同一個環里，站間信息交互需回到TDCS/CTC中心通過核心交換機實現。如圖2所示：

圖2 同網不同環網絡結構圖

由圖2可知紅砂壩和土貴烏拉互為鄰站，但是兩個車站不在同一個環里。紅砂壩站為抽頭站，車站信息從NPC經車站路由器送到TDCS核心路由器B,TDCS核心路由器B將信息送到核心交換機A或核心交換機B,路由器會計算最優路徑選擇其中的一條來走。核心交換機A和核心交換機B之間由萬兆光纖連接，信息流向TDCS核心路由器A，再由TDCS核心路由器A送到土貴烏拉車站路由器，流向土貴烏拉車務終端，實現鄰站信息的傳遞。同理，土貴烏拉的信息也是通過上述通道送給紅砂壩。

1.3 不同網絡不同的環呼和局集團公司管內有的線路按照CTC系統建設，有的線路按照TDCS系統建設，這樣就存在CTC車站和TDCS車站信息交互的問題，簡稱CT交互。按照《列車調度指揮系統（TDCS）、調度集中系統（CTC）組網方案和硬件配置標準》運基信號［2009］676號文件要求，CTC車站通過CTC核心路由器回中心,TDCS車站通過TDCS核心路由器回中心，CTC核心路由器和TDCS核心路由器相對獨立。CTC系統和TDCS系統軟件體系結構不同,信息需通過中心服務器傳遞。網絡連接如圖3所示，數據流向如圖4所示。

圖3 不同網不同環網絡結構圖

圖4 CT交互數據流圖

葫蘆和八蘇木互為鄰站，葫蘆為CTC車站，八蘇木為TDCS車站。八蘇木車站信息由NPC通過網絡傳遞給八蘇木站所屬通信前置機，該通信前置機里同時配置葫蘆站的站號，最終將車站信息傳到通信服務器。通信服務器按照葫蘆站站號尋找葫蘆站所屬CTC通信前置機并將信息傳至CTC通信前置機，再傳遞到葫蘆站自律機里，從而在葫蘆站CTC車務終端上顯示。同理，葫蘆站自律機中配置八蘇木站站號，葫蘆站將車站信息通過自律機傳遞給葫蘆所屬CTC通信前置機，然后傳遞給通信服務器。通信服務器按照八蘇木站站號尋找所屬TDCS通信前置機并將信息傳至八蘇木所屬站通信前置機，再傳遞到八蘇木站車務終端。完成CT間信息的交互。

對于TDCS車站與CTC3.0車站之間站間透明，也是通過上述方式進行，從而實現對鄰站車站信息的顯示。

1.4 局間車站站間透明局間車站網絡連接如圖5所示，數據流如圖6所示。

圖5 局間車站網絡結構圖

圖6 局間車站交互數據流圖

局間車站交互通過TDCS中心局間接口服務器完成，再由中心傳遞到車站。

2 信息中斷故障案例分析

2.1 故障案例一

2.2.1 故障現象包惠線巴彥高勒站看不到鄰站杭錦旗站車務終端站場信息，杭錦旗站看不到鄰站巴彥高勒站車務終端站場信息。

2.1.2 故障分析及處理通過查看網管軟件，巴彥高勒站和杭錦旗站屬于同網同環的車站，車站表示信息通過站間通道傳遞。故障范圍鎖定在兩站及之間的通道，兩站均可以看到本站信息，排除車站NPC設備故障。判斷為網絡設備及通道故障，登錄巴彥高勒站車站路由對杭錦旗方向進行PING包測試，發現網絡通道質量不良，多次發生丟包現象。通信、信號人員使用環回測試法進一步判定故障點，結果為在巴彥高勒站打近環可見環、打遠環時有時無，判斷故障點在杭錦旗站。信號人員檢查杭錦旗站TDCS網絡設備指示燈，發現杭錦旗對巴彥高勒站協議轉換器的告警指示燈時好時壞，信號人員要點更換該協議轉換器后故障恢復。

2.2 故障案例二

2.2.1 故障現象陶思浩對中心的通道中斷，薩拉齊車務終端不能顯示薩拉齊集裝站場圖。圖7為車站網絡結構圖。

圖7 車站網絡結構圖

2.2.2 故障分析及處理：

1）根據網絡拓撲結構并結合圖7分析，薩拉齊在包頭東-陶思浩環內，當通道完好時，薩拉齊車站信息從陶思浩回TDCS/CTC中心核心路由B，由TDCS/CTC中心核心路由B送到薩拉齊集裝站路由器，最終顯示到車務終端。

2）當陶思浩回中心的通道中斷時，正常情況下薩拉齊站路由倒切從包頭東回TDCS/CTC中心核心路由A,再送到核心交換機A，核心路由B,找到薩拉齊集裝，將信息送到薩拉齊集裝。

3）現場故障實際情況是陶思浩對中心的通道中斷，薩拉齊車務終端不能顯示薩拉齊集裝站場圖。TDCS/CTC中心人員登錄薩拉齊路由，tracert薩拉齊集裝路由器IP地址，數據包走到TDCS核心路由A斷了。經分析查找發現上述兩個環所處的域不同，包頭東路由器沒有配置指向薩拉齊集裝的靜態路由，數據包失去了路徑指向，造成薩拉齊車務終端不能顯示薩拉齊集裝站場圖，廠家技術人員遠程登錄包頭東路由器配置一條指向薩拉齊集裝的靜態路由后故障恢復。

3 信息中斷故障判定流程

當發生信息中斷的故障，主要表現為車站站場圖無表示。網絡通道中斷、網絡設備故障、車站設備故障、軟件數據配置錯誤均會導致車站站場圖無表示。近幾年呼和局集團公司管內發生的車務終端站場信息中斷故障中，網絡通道中斷或丟包導致本站無法顯示鄰站站場圖占絕大多數。發生信息中斷故障后按照以下流程進行判定。

1）通過網管軟件查看故障點網絡結構，先判斷兩個車站交互方式屬于以上哪種情況，從而確定故障范圍。

2）通過網管維護工具查看中心設備和車站設備狀態并查看日志確定故障類型，屬于軟件故障、硬件故障還是網絡通道故障。無法直接鑒定故障類型時，采用排除法縮小故障范圍。

3）軟件故障由廠家技術人員負責處理，硬件故障更換配件、板卡或整臺設備。若是網絡通道故障，需要通信部門協助共同確定故障點并及時處理恢復設備正常使用。

4）網絡通道故障時，可登錄到確定范圍之內的路由器，查看協議、接口重置次數等信息，鎖定故障兩端到故障點，用替換排除法確定準確的故障點及故障原因。常用到的方法是環回測試法，該法操作要領和原理是，將被測設備收發端短接，通過接收被測設備發出的信號判斷線路或端口是否存在斷點。

4 結束語

本文從現場實際發生故障案例出發，總結分析形成判斷故障范圍、分析故障成因方法，針對故障類型梳理出管內及局間各種不同情況下站間透明的信息交互方式，提出正確故障處理流程，對指導現場有關單位和人員準確、迅速排除此類故障，促進安全運輸生產具有積極意義。