两起时间戳引起的RBC移交典型案例分析

赵红霞，冯 飞

（中国铁路上海局铁路集团有限公司徐州电务段，江苏徐州 221000）

无线闭塞中心（RBC）是CTCS-3 级（简称C3）列控地面的核心设备，为列车提供行车许可。其中RBC 的移交是CTCS-3 级中非常重要的一个运行场景，移交过程中会牵涉到移交RBC、接受RBC 和列车三者的信息交互，过程复杂。过程中出现问题经常会引起列车常用制动，造成无线超时降级，甚至停车。所以分析清楚移交过程，找到列车降级原因，做好防范措施，对于维护人员具有重要意义。

1 RBC移交概况

根据C3 级列控总体技术方案[1]，RBC 移交目前有两种方式。一种是采用通过联锁间接联系，武广高铁就是采用的这种方式，移交场景如图1 所示。联锁与RBC 之间通信采用单点连接方式，当一个RBC 需要两个联锁信息时，另一个联锁信息通过车站TCC 传输至该联锁。该种方式是特殊情况下需要主管部门批准。

另外一种是RBC 之间通过信号安全数据网络通信，如图2 所示。每套RBC 均采用两套独立的安全数据网交换机，通过光电模块转换成光纤信号进入安全数据网络，与TSRS、相邻RBC 和CBI 通信，目前主要是采用这种直接通信方式。

图1 RBC间间接移交示意图Fig.1 Schematic diagram of indirect handover among RBC

图2 RBC间直接通信示意图Fig.2 Schematic diagram of direct communication among RBC

2 RBC移交场景过程分析

2.1 双电台正常的移交过程

列车以C3 等级在RBC1 范围内运行时，当MA终点达到RBC 移交边界时，RBC1 向RBC2 发送M201。RBC1 收到RBC2 的回复信息M205 后，申请进路信息M202，同样也需要接受RBC 确认。

RBC2 接收到M202 后，则根据控制范围内进路信息向RBC1 发送M221。

RBC1 收到M221 后，便可以将MA 延伸到RBC2 的范围。

期间两个RBC 之间保持通信，M202、M205、M221 3 个消息周期性的循环。如果RBC2 内进路有变化，要及时的发送给移交RBC1。

RBC1 判断列车距离向列车发送P131。

列车根据RBC1 提供的电话号码，启动电台2开始呼叫RBC2 并建立通信会话。列车与RBC2 建立连接后，要向RBC2 发送列车位置报告，在RBC2能够对列车准确定位后，可以向列车发送MA。

列车继续前行，在到达移交边界前，均受RBC1 控制。

当列车最大安全前端通过切换应答器，车载设备向两个RBC 发送基于该应答器的位置报告，同时车载设备应开始仅接受RBC2 控制。

如果RBC1 先收到位置报告，则向RBC2 发送移交通告信息，并停止向RBC2 请求进路信息，也丢弃RBC2 发送的进路信息；如果RBC1先收到RBC2 列车接管信息，则认为移交结束。

当列车最小安全末端通过切换应答器，车载设备向RBC1 发送位置报告，RBC1 将向车载设备发送消息终止通信会话（信息包42）[2-3]。

2.2 单电台正常的移交过程

此前移交过程和双电台一致，直到列车最大安全前端通过切换应答器，车载设备只会向RBC1 发送基于该应答器的位置报告[4-6]。

RBC1 收到位置报告后，向RBC2 发送移交通告信息。

列车尾部通过移交应答器组后，处于休眠模式的车载设备记录RBC2 的呼叫信息。

当列车最小安全末端通过切换应答器，车载设备向RBC1 发送基于该应答器的位置报告。

当RBC1 接收到位置报告后，将向车载设备发送消息终止通信会话（信息包42）。

根据RBC1 提供的电话号码，车载设备开始呼叫RBC2 并建立通信会话。

RBC2 发送MA 并监控列车运行，至此完成RBC1 到RBC2 的移交。

2.3 双电台和单电台过程对比

通过上述双电台移交和单电台移交的过程分析，可以发现这两个场景的RBC 移交过程的共同点是都需要经过3 个过程[7-8]：开始移交并获得跨越RBC 移交点的MA，注册到GSM-R 网络，脱离移交RBC 控制和接受接管RBC 控制。

第一个移交都是从MA 达到RBC 分界点开始，移交RBC 和接管RBC 开始启动移交程序。包括移交预告、应答、移交请求信息和授权相关信息，这样 MA 就可以延伸跨越分界点。

第二个都需要与接收RBC 建立连接并开始通话，建立连接首先需要注册到GSM-R 网络，由于在中国CTCS-3 级线路上所有无线闭塞中心（RBC）都连接到相同的GSM-R 无线网络上（同一个GSM-R 运营商网络），RBC 移交正常情况不需要考虑任何新的GSM-R 无线网络注册。然后都是根据RBC1 提供的P131 包中的信息获取RBC2 电话号码。

第三个都是需要有一个断开与移交RBC 的连接和与接管RBC 建立连接的过程。

不同点是双电台的移交过程中，当收到移交RBC 发来的P131 包以后，是有两个电台同时工作，一个与移交RBC 通信的同时，另一个与接管RBC通信。而单电台的移交过程中，由于只有一个电台，需要先与移交RBC 断开通话，再通过该电台建立与接收RBC 通话。并且双电台移交过程中当列车经过移交点后，就应该仅接受RBC2 的控制。而单电台移交是过了移交点后列车还是继续使用RBC1之前给的MA，直至与RBC1 断开连接。通过分析可以看出，双电台移交是可以保证列车一直与RBC通信通过移交点。但是单电台必然会在移交区出现列车降级现象，而且通过DMS 上可以看到该列车每次经过移交区都会出现降级现象。

3 典型案例分析

3.1 时间戳溢出导致移交超时

3.1.1 故障概况

2019 年在郑徐线路中，发生列车由CTCS-3 级降到CTCS-2 级现象。通过DMS 查看回放记录，发现降级点在K199-200 之间，处于郑徐RBC3 和京沪RBC7 的移交范围内。

3.1.2 故障分析

下载郑徐RBC3 的EVENTLOG 日志，对日志进行解析和筛选，筛选出所有移交日志，在日志类型中选中M201、M202、M203、M204、M205、M221、M222、M223 和stpdatatotrain、stpdatafromtrain，总共包含所有车地之间交互信息和RBC 移交的全部信息日志。根据降级时间查看相应时间段的日志可发现 ：

12:18:04 JHRBC7 向 ZXRBC3 发送 M201，启动 G1807 列车的移交信息，说明京沪RBC7 是移交RBC，向接管郑徐RBC3 发送了移交预告，标志着移交的启动开始；

之后JHRBC7 收到ZXRBC3 发送的M205确认，又向ZXRBC3 发送M202 进路申请信息，ZXRBC3 向JHRBC7 发送M221 信息，期间一直是M205,M221 循环发送，确保RBC 之间移交通信正常，也可以确保接管郑徐RBC 内如果进路信息发生变化可以及时传给移交京沪RBC。

12:23:44 JHRBC7 发 送M205 至ZXRBC3，nT_RBC = 4294967295；

12:23:44 JHRBC7 发 送M221 至ZXRBC3，nT_RBC = 0；

12:23:44 查看C 类报警，12:23:46 郑徐RBC3中出现alarmgrouprim_a 报警信息，显示Message discarded，表示郑徐RBC3 接受到信息校验不合格，进行丢弃；

12:23:49 ZXRBC3 通信计时器超时（RBC间通信时间超过5 s），导致列车由 JHRBC7 向ZXRBC3 移交失败，移交RBC 不在向列车发送任何消息，然后列车由于无线超时降级C2 运行。

3.1.3 故障原因

按照RBC-RBC 接口规范，RBC 移交连续消息中的时间戳应保持递增，时间戳不一定是真实时间，单位是10 ms，最大值是4 294 967 295。此次移交过程中京沪RBC 的nT_RBC=0，出现了时间戳溢出的现象，导致发给相邻 RBC 信息的时间戳跳变，相邻郑徐RBC 认为该消息不合法，丢弃该信息，引起正在移交的列车移交失败，无线超时转 C2运行。

3.1.4 解决措施

目前这个现象无法解决，需要更新RBC 版本才可以，但是为了避免以后再次出现这类现象，维护人员可以在大概497 天之内对双系RBC 进行重启，因为RBC 双系重启会清除所有的动态数据。

3.2 时间戳误判导致移交超时

3.2.1 故障概况

2019 年在郑徐线K203，处于郑徐RBC 向徐盐RBC 移交范围，11:56 郑徐RBC3（通号产品）与徐盐RBC1（铁科产品）移交超时，导致MA 缩短。

3.2.2 故障分析

由于该移交超时牵涉到两种厂家的RBC，所以需要分别下载通号和铁科日志进行分析。

11:52:44 铁科RBC 收到M201，说明移交开始启动，网络通信正常。

11:53:50 至11:55:50，郑徐RBC 和徐盐RBC都进行正常的时钟偏移更新，徐盐RBC 也做了应答。移交郑徐RBC3 已经把MA 延伸到徐盐RBC1管辖范围内。

11:56:04 郑徐RBC3 在安全连接断开前收到徐盐RBC1 发来的M221 消息，同时并回复M205 消息。

11:56:05，郑徐RBC3 向徐盐RBC1 发起断开连接信息stpdisconnectreq，同时徐盐RBC1 收到DI 断开连接消息。

11:56:06 在RBC 维护终端数据上查看NRBC连接状态是0x00，表明徐盐RBC 与郑徐RBC 断开连接。

11:56:07 徐盐RBC1 收到连接断开后，立即断开TCP 连接并重新建立TCP 重连，并三步握手成功。

11:56:08 徐盐RBC1 作为交权接收方，日志中取消原因是0x04,表明在一定时间内未收到NRBC消息，判断通信异常，取消3552 车的移交。

11:56:11 徐 盐RBC1 向 郑 徐RBC3 发 送 了AU1，建立安全连接，回复通信数据，并向郑徐RBC3 发送M204 消息。

11:56:13 重新连接成功后，郑徐RBC3 收到徐盐RBC1 的第一条信息是M204，即整个中断过程是9 s，超过RBC 间移交超时规定值，导致移交超时。

3.2.3 故障原因

这次导致MA 缩短的故障原因从日志角度分析是郑徐RBC 和徐盐RBC 移交超时，徐盐RBC1 向郑徐RBC3 断开连接后重连并发送M204 取消移交。深层次原因通过安全数据网抓包才发现的。目前中国铁路通信信号股份有限公司的RBC 和中国铁道科学研究院集团有限公司的RBC 都是采用RSSPII 协议中的TTS 通信方式，需要双方进行时钟偏移机制。通过抓包发现，徐盐RBC1 向郑徐RBC3 发送3 包应用数据（序号是22816,22824,22834），徐盐RBC1 发送的时钟偏移更新请求（序号22860），这四个包时间戳均为0x1c3919a9，在徐盐发出时钟偏移更新请求22860 的同时，郑徐RBC3 发送时钟偏移更新请求22874，由于在此之前已经收到需要RBC1 时间戳0x1c3919a9 的应用数据，22874中上一次接收方时间戳设置为0x1c3919a9，导致徐盐RBC1 误认为是郑徐RBC3 发送的22874 是对22860 的时钟偏移更新应答。而郑徐RBC3 发送的真正时钟偏移应答22877 又被徐盐RBC1 误认为是下一次时钟偏移请求，导致无法通过郑徐RBC3 的安全校验，经过多次这种请求信息和应答信息的误判，双方均不停的发送请求信息，而不处理应答信息，郑徐RBC 无法完成时钟偏移更新，最终导致郑徐RBC3 向徐盐RBC1 发送断开连接通知，两个RBC 间安全连接中断。但是时钟偏移引起的RBC间安全连接断开，如果安全连接断开后重新建立连接的时间小于RBC 判断应用超时的时间，该中断不会影响RBC 间通信，所以此时郑徐RBC 给列车的MA 不会缩短至移交边界，直到郑徐RBC3 收到徐盐RBC 发送的M204，郑徐RBC3 将MA 缩短至边界，造成列车ATP 紧急制动停车。

3.2.4 解决措施

针对以上问题，设备维护单位组织相关设备厂家进行分析讨论，提出以下两点解决措施。

一个是在故障分析中可以得知，11:56:07 徐盐RBC1 三步握手成功，但是11:56:11 徐盐RBC1 才向郑徐RBC3 发送了AU1 建立安全连接，中间过了4.1 s，如果在握手成功后立即发送AU1，则安全连接中断时间可以压缩到5 s。所以建议徐盐RBC 修改应用层判断超时时间，由原来的5 s 改为7 s，这样应用层不会判断异常，造成超时。

另一个是修改判断应用层连接超时后不发送M204 消息，这样即使发生RBC 通信中断的情况，列车会无线超时降至C2 级运行，不会触发紧急制动停车。

4 结束语

通过对RBC 移交过程的分析，总结出移交过程中关键点，并对双电台和单电台进行了对比。同时结合现场RBC 移交超时日志分析，对时间戳以及由于时间戳引起的故障进行说明分析，并提出解决措施，对此后维护人员分析移交中出现的降级现象提供借鉴。