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 结束语

本文从现场实际发生故障案例出发，总结分析形成判断故障范围、分析故障成因方法，针对故障类型梳理出管内及局间各种不同情况下站间透明的信息交互方式，提出正确故障处理流程，对指导现场有关单位和人员准确、迅速排除此类故障，促进安全运输生产具有积极意义。