RBC维护与分析

1、整理ppt整理ppt目目 录录一、前言一、前言二、维护终二、维护终端的作用端的作用三、三、Log文文件的分析件的分析 四、结束语四、结束语 RBC即无线闭塞中心，是CTCS-3级列控系统的核心设备，RBC通过与联锁，CTC，TSRS等服务器的信息交互，将数据经由ISDN服务器通过GSM-R无线通信系统传输给车载子系统，从而实现列车在C3模式下的安全运行。合蚌RBC工区的成立是为了完成每天对合蚌管内动车组运行的盯控，通过Log文件的分析以及维护终端实时信息的比对，从而发现安全隐患，为列车的安全畅通运行打下坚实的基础。一、前言 2.1、合蚌RBC维护终端各模块作用 1、维护终端机模块 2、RBC_

2、T机模块 3、VIA监测模块 4、ISDN服务器监测模块 以上四个模块分别运行于维护终端、 RBC_T机、 VIA、 ISDN服务器，逻辑关系如下图：一、维护终端的作用RBC_T模块模块ISDN服务器监测模块服务器监测模块VIA 监测模块监测模块维护终端模块维护终端模块 2.1.1 ISDN服务器模块的作用 ISDN服务器模块用于监测ISDN卡的工作状态，并将其发送给监测机，再由监测机将信息发送给RBC维护终端。 通常ISDN卡在异常时会在/CapiWatch/目录下，出现如下报警： TRAP_INVALID， capiwatch_isdn 即监测程序自身异常。 TRAP_ADAPTERNOT

3、FOUND,监测到服务器未能正常识别ISDN卡。 同时维护终端的设备运行图中也会出现ISDN指示灯变为红色的情况。如下图所示： 2.1.2 监测机模块的作用 监测机模块用于监测RBC的工作状态以及各通信连接状态，并将这些状态以及ISDN卡的状态送给维护终端模块。 在RBC运行正常以及与各信息设备如联锁、TSR等设备通信正常的情况下，各设备的指示灯以及通信连线会显示绿色，如下图所示： 2.1.3 VIA模块的作用 VIA模块用于监测VIA与CTC、JRU的连接状态，并将这些状态发送给维护终端模块。 在RBC设备的日常维护中通常会出现VIA与CTC通信终端的报警，除了在RBC维护终端上有相应的信息

4、显示外，另外在VIA的Log日志中也会同步出现：CTC status refreshed的提示，即CTC状态更新，虽此类报警不影响设备使用，但也要长期记录，通过周期来判断其报警的具体原因。 2.1.4 维护终端模块的作用 维护终端模块将所获得的所有信息汇总并显示给维护人员使用，使维护人员能够了解动车组和设备的运行情况，实时掌握动态，维护终端共分为以下几个部分： 1、设备运行图，在此图上各设备之间的连接是由显示在设备上的状态灯，以及设备之间的连线表示。对于设备的连接状态而言，绿色表示连接正常，红色表示连接断开，灰色表示状态未知。白色只表示一种逻辑关系，不代表实际关系，其状态也不会变换。 2、列表

5、信息，共包括三个部分：列车信息、事件信息、警告信息，分别由3个Tab页表示。 列车信息显示的是当前注册到RBC上运行的列车如CTCSID、车次号、列车等级、模式、速度、无线通信状态、MA状态等。 事件信息与警告信息分为实时和历史两个Tab页，主要用来显示RBC设备本身以及与相邻信息设备间的异常信息。 3、线路运行图，用于显示当前线路状态以及运行于线路上的列车状态。 合蚌线上分别将合蚌RBC管内的由蚌埠南站分界口至合肥站内的列车占用信息、移动授权、管辖范围以及列车车次等信息在运行图中进行了显示。 在合蚌RBC的日常维护中，除了维护终端各种信息的调阅和处理之外，Log文件的分析则是工作中的重中之重

6、，合蚌线每天都要开行30多趟动车组，在维护终端发现列车降级和停车后，怎样利用分析软件结合所学知识快速找寻车地会话异常的原因，是考验RBC工区职工素质的关键，下面就日常工作中遇到的列车异常信息分析进行讲诉，让大家对Log文件的分析有一个初步的了解。三、Log文件的分析9:29:52 G264收到最后一条行车许可，其中链接信息的P5包中包含的应答器链接信息已经延伸至蚌埠南管内进站信号机内方，即MA已经延伸至进站信号机内方，说明MA延伸没有问题。9:31:10收到车地会话信息M136的P0包中包含NID_LRBG = 9113910通过工程数据表找到对应位置蚌埠南站管内K856+243处，即RBC1

7、与RBC8的交界处，并隶属于RBC8管内第一个区段，此时列车仍处于C3完全监督模式，列车速度为35Km/h。9:31:10RBC8向RBC1发送M205（只有列车最大安全前端已经通过RBC边界时才发送M205），即RBC移交通知RBC接收列车最大安全前端已经通过RBC边界。9:31:11收到M222即RBC8发给RBC1的移交接管职责，M204即RBC8发来的移交取消信息，此时观察回放界面G264已经进入RBC8管内。（在正常移交情况下才会出现M222，M205）综合上述信息，M204为正常的移交结束，RBC1作为移交RBC未出现异常。列车已C3完全监督模式进入RBC8管内，车地会话信息正常。

8、 13:19:34 G7284在中继5管内K938+565处收到最后一条车地会话信息，此时列车处于C3完全监督模式。 13:19:34 RBC发给联锁的信息InterlockingId （联锁ID）= 1, ObjectIdentifier （对象标识）= 68, TrainStatus （列车状态）= Train, MAStatus （MA状态）= Train Reserved MA Acknowledged, PositionOfTrain（列车位置） = 1614, TrainLength（列车长度） = 210, TrainSpeed （列车速度）= 305，通过以上信息，说明此时列车

9、位置为已知。 13:19:36 收到同步报警信息The train with saCEPID 4 is disconnecting. (即在saCEPID 4注册的列车即将丢失。) 13:19:52 在中继站5管内K936+629处收到P4包M_ERROR = 5，说明列车此时无线超时，此时列车处于C2SN模式。 13:19:52 收到同步报警信息RBC has received an error report: Radio consistency .RBC（收到一个错误报告：即无线一致性。）Investigate the error report to check what is repor

10、ted. （调查错误报告，从而检查错误报告的原因。）Inform train operator or infrastructure responsible depending on the result.（通知列车司机或设备责。任人找出错误报告的原因。） 13:19:52 收到M204，即移交结束。此时终止了RBC2向RBC1的移交。 13:19:52 收到P42包Q_RBC = 0则说明RBC与列车G7284终止通信会话。 综合上述信息，说明G7284在移交过程中无线超时导致移交结束，列车降级运行。 14:08:27 G265呼叫RBC1 14:08:29 与RBC1建立连接，此时列车为C3

11、-FS模式，速度155km/h.后正常运行。 14:28:11 RBC1log中出现报警：The supervision of active handing over session with RBC HBRBC2 timed out（表示与RBC2通信超时），后RBC1不再向G265发送任何信息，20S后G265车载ATP认为与RBC1通信超时。 14:28:46向RBC1报无线超时报警，此时列车已降为C2-SN模式，位置K918+126。 14:28:46 断开与RBC1连接，以C2模式运行。整理ppt 通过以上三个实例，可以看出通过Log文件的分析，能够及时有效的判断出车地异常信息的原因所在，从而为排除故障提供依据，当然在日常工作中Log文件的分析也不是万能的，像Log文件中经常出现的通信漏洞，移交时的突