周 晔

（南宁铁路局南宁电务段，助理工程师，广西 南宁 530001）

铁路列车调度指挥系统（Train operation Dispatching command System，简称TDCS）是实现铁路各级运输调度对列车运行透明指挥、实时调整、集中控制的现代化信息系统，实现了铁路运输组织的科学化、现代化，且增加运能、提高效率，减轻了调度人员的劳动强度，改善了调度指挥的工作环境。由于TDCS系统发生故障后对行车调度影响很大，所以有必要研究如何压缩TDCS故障延时的措施，以减少故障对行车的影响。

1 故障延时长的主要原因

南宁铁路局管内有湘桂、黔桂、黎湛、焦柳、南昆、南凭、河茂、益湛8条铁路线，运营里程3 237.4 km，TDCS设备遍布274个车站的运转室、站调、外勤及机务段等机构。况且目前维护劳力缺乏，技术底子薄弱，所以故障延时长一直都是电务部门难以攻克的难题。压缩TDCS故障处理延时，最重要的是查找主观因素方面的原因。

1.1 故障处理流程多故障受理及处理流程主要有3个步骤：1）发现问题。主要通过现场电务人员和TDCS中心对设备的巡视，及使用部门的申告实现。但实际存在巡视不到位、通知不及时、使用部门无暇申告，造成延时。2）查找原因。由于现场作业人员对设备不熟悉，需要TDCS中心的电话指导。故障信息和指导信息的频繁交互，往往会因通讯障碍、表达障碍等因素变得相当的耗时。3）故障处理。由于在处理故障时没有把故障处理的详细经过和经验记录下来，形成故障处理的规范，在处理类似故障时仍需边回忆边处理。不准确的回忆，必然造成又一次的延时。

1.2 故障信息采集滞后且不准确在故障发生后，故障实际处理人即现场电务人员并未在第一时间获得故障信息，而是由TDCS中心通过电话通知。因此，存在通知障碍和沟通障碍等延时因素。通知障碍包括电话故障、电话长时间占线、电话无人接听等情况。沟通障碍则包括电话信号不良、采用方言不同及对设备故障点的理解不同等。这些因素都会造成TDCS中心和故障处理人之间信息传递滞后和信息不对称，出现故障延时。

1.3 故障处理方式落后TDCS系统设备包括：网络处理单元（NPC）、车务终端（STPC）、应用服务器，调度指挥终端（GPC）等。目前，针对TDCS故障处理的方式比较落后。

1.3.1 NPC故障 网络处理单元（NPC）就是将站场信息以码位的形式解析，再将相关数据送给其处理，并以网络的方式传递。整个单元的内部芯片采用Linux Redhat的系统平台，外部配与单网卡来实现网络传输。把网卡与本站局域网内网IP地址捆绑，并采用双机热备的方式以实现网络传输预处理。但在一些雷害频发的地区，双套NPC同时被雷击坏经常发生，这给铁路系统尤其是电务部门带来了极大的困扰和经济损失。而现场电务人员恰恰缺乏故障处理的技术能力，必须由相关的电子综合部门根据本站实际情况重新编写芯片程序，再发往故障现场。而电子综合部门只设在南宁、柳州、桂林三地，如此一去一回，使故障延时长。

1.3.2 STPC故障 现行的车务终端（STPC）采用传统的双机热备方式。其原理是基于磁盘块的复制方式，当某个磁盘块静止不动，软件发现改动，才进行复制拷贝，这时候如果磁盘有坏道，损坏的数据也随之覆盖备机完好的数据，这就形成了3种不理想结果：1）数据不能即时同步；2）数据容易丢失；3）每次停机都有较长的初始化过程，数据再覆盖一遍。这正是主备机不能正常切换，磁盘无数据、数据丢失，故障延时长的重要原因。

1.3.3 应用服务器故障 应用服务器是TDCS系统的核心设备，也采用双机热备的方式。在发生故障时，由人工切换。问题在于当故障发生突然且严重时，应用服务器不能自动切换。比如当网络误码率大于7%时，程序依然运行，但数据已经开始丢失；部分车站收不到阶段计划、调度命令，以及运行线不全等故障症状开始慢慢体现。所以，人工切换应用服务器的故障解决方式明显落后，造成故障延时长。

1.3.4 GPC故障 调度指挥终端（GPC）是一客户端，其数据要写入数据服务器中的IBM DB2数据库。如果数据服务器瘫痪，行调员绘制的运行图、下发的调度命令、记事等诸多数据将无法存储，后果很严重。而数据服务器故障点查找难，恢复慢，影响时间长。针对数据服务器二取一平行的存储方式，当主、备服务器同时发生故障时，不仅仅是故障处理时间延长，甚至难以恢复原功能。

1.4 软件缺乏人性化在实际TDCS故障处理中，除了硬件发生故障以外，也不乏软件故障。软件如果缺乏人性化及规范化，故障延时可能比硬件故障更长。比如TDCS程序对设备故障不能自动报警、GPC程序不能自动切换联网模式和单机模式、程序配置文件多且没有封装等都是软件缺乏人性化的具体表现。针对这些表现，必须人工巡视设备、人工切换模式、人工检查配置。而这些都依赖于人的技术水平高低和责任心的强弱，会带来故障延时，并且这种延时是不可控的。

2 压缩故障延时的措施

鉴于上述分析，应在弄清故障原因的基础上，通过优化处理流程，利用Unix环境参数优化，数据库间的转换及系统底层缓存拦截和智能识别来达到压缩故障延时的目的。

2.1 优化故障处理流程在信号微机监测系统中，故障可以通过采集值直观地反映出来，并通过网络传输到达监测调阅终端，调度员发现声音报警后，直接通知相关人员前去处理。针对这一点，TDCS系统是可以借鉴和进一步优化。通信前置服务器就类似监测服务器，可以在通信前置服务器上加装一通讯设备，将TDCS设备故障信息以手机短信群发的形式，发送到相关负责人的手机。这样故障信息可以跨越通知障碍和沟通障碍，在第一时间准确无误地传达到故障处理人。这样既可以节省故障通知时间，又能弥补机房巡视人员由于工作疏忽而遗漏的设备隐患。

但仅仅压缩了故障通知的时间是远远不够的，故障处理事件往往由于TDCS中心人员没有亲眼目睹故障现象和故障位置，以及现场电务人员不熟悉TDCS设备的双重原因，造成故障点误判以致延时。鉴于此情况，对于一些业务不熟悉的现场作业人员有必要配带轻便的摄像设备，以辅助TDCS中心人员指挥其确认故障点并顺利排除故障。而故障视频信息可以通过TDCS网络传递到TDCS中心并予以保存。

2.2 增强故障处理方式的科学性因为TDCS系统使用范围广，遍布全局管辖所有车站，且电务人员劳力不足，对TDCS技术不熟悉，所以改变故障处理方式落后的现状，对压缩故障延时，提高行车效率有重要和深远的意义。

2.2.1 NPC故障处理方式的优化 NPC故障处理时间长，是因为NPC只配备了单网卡，且只捆绑了单IP。如果从邻站调用一套NPC，其IP地址与路由不在同一子网，无法通信。其实，Unix最多可以支持255个IP别名。如果给单网卡绑定好相应邻站和本站的IP地址，电务人员在发生故障时，只需将邻站事先配置好多IP地址的NPC备机，换到本站安装好即可。这样可以省去远距离来回递送NPC的时间，可压缩故障延时80%以上。而这些要通过优化Uinx环境参数来实现，实现方法如下：

假设需要绑定多IP的网卡是eth0，则在/etc/sysconfig/network-scripts目录里面创建一个名为ifcfg-eth0：0的文件，内容样例：

device=“eth0：0”//device为设备的名称

ipaddr=198.12.163.5//ipaddr为此设备的ip地址

netmask=255.255.255.0//netmask为子网掩码

broadcast=198.12.163.255//onboot表示在系统启动时自动启动

onboot=yes//表示在系统启动时自动启动

bootproto-none

如果需要再多绑定一个IP地址，只需要把文件名和文件内的device中的eth0：x加1，然后把ipconfig eth0：1 198.12.164.5 broadcast 198.12.255.255 netmask 255.255.255.0加在启动自运行文件（/etc/rc.d/rc.local）里面即可〔1〕。此方法通过优化Unix环境参数，改变了传统模式，使故障延时大大降低。

2.2.2 STPC故障处理方式的优化 对于目前STPC采用的传统双机热备方式带来的不理想结果，建议采用双机双软热备的方案，从而使用了新的软件架构，改变传统数据同步模式，即使用单程序而后台运行双进程的方式，使数据在本地磁盘先备份及数据识别，然后才进行双机热备的数据同步工作。其原理是基于系统底层的缓存拦截，加上智能数据识别，同步锁定等功能，数据有稍微的改动，经过缓存都会在备机及本机其它分区执行相同操作。如果采用此方案，STPC的故障预防性可得以提高，自我恢复能力将得到加强。

2.2.3 应用服务器故障处理方式的优化 在应用服务器程序中添加对网络状态自动判断的语句模块。当网络误码率大于7%时，程序自动退出，此时备机程序则自动成为主用。这样就解决了因网络丢包而造成的不经意间数据丢失。

2.2.4 GPC故障处理方式的优化 在调度指挥终端（GPC）建立一个类似ACCESS，MYSQL的小型数据库。ACCESS的数据库如图1所示。

图1ACCESS数据库表

在图1中，ACCESS数据库表由IBM数据服务器的DB2数据库转换而来。当数据服务器瘫痪时，启动本地数据库。待数据服务器恢复正常工作时，再将本地数据库的数据回送到数据服务器中，从而即使双机冗余的数据服务器都出现故障，行调员依旧可以正常地指挥行车，不存在故障延时。

3 结束语

TDCS系统自投入使用以来，不仅给行车调度指挥工作带来了极大的便利，也为铁路系统创造了良好的经济效益和社会效益。但与此同时，随着TDCS系统的不断升级，也对TDCS设备维护提出了更高的要求和标准。通过Unix环境参数的优化，数据库间的转换及系统底层缓存拦截和智能识别，有效地实现了压缩故障延时的目的。对主要耗时故障，缩短延时达50%以上，提高了行车指挥的工作效率和安全性。

〔1〕尤晋元.UNIX环境高级编程〔M〕.北京：机械工业出版社，2002.