特殊场景下RBC移交过程中导致MA无法延伸问题的优化

2018-10-22中国铁路上海局集团有限公司电务处

上海铁道增刊 2018年3期

李砾中国铁路上海局集团有限公司电务处

众所周知，我国高速铁路营业里程在不断增长，高速铁路在我国进入了黄金发展阶段，CTCS-3级列控系统在我国高速铁路上广泛运用，其主要特点是基于GSM-R无线通信实现车-地信息双向传输，无线闭塞中心（RBC）生成行车许可（MA），轨道电路实现列车占用检查，应答器实现列车定位，并具备CTCS-2级功能的列车运行控制。

RBC是CTCS-3级列控系统地面核心设备，根据联锁、临时限速服务器、其他地面设备和车载设备提供的信息，生成列车行车许可，并通过无线通信方式发送给车载设备，以控制列车的安全追踪运行。由于单个RBC处理能力有规定限度，因此按照高速铁路运营里程的不同，每条线设置的RBC数量也不同，RBC与RBC之间需要进行信息移交，但是RBC之间在进行移交过程中，由于运营场景的特殊性，偶尔会发生在RBC移交过程中，其发给车载设备的MA会无法延伸，从而导致动车组列车停车。现以合福高铁RBC1（通号RBC-TH型）与合蚌高铁RBC2（通号RBC-TH型）之间移交过程中，特殊场景下两个RBC之间移交时MA无法延伸问题为例，来分析问题的优化解决方案。

1 问题描述

2017年6月12日,G272次 (合肥南-北京南，CRH380B-3721动车组00端担当,300T型ATP车载设备)在合肥南合福场始发后，18∶30因ATP显示运行速度为零，停在合肥西合福场至合肥北城站间上行线K980+070处，司机改目视行车后，18∶37开车，运行一个闭塞分区后恢复正常。

经对RBC记录日志并结合ATP车载设备JRU记录数据综合分析发现，CRH380B-3721动车组00端担当G7418次运营交路17∶11∶59抵达合肥南站后，计划接开G272次自合肥南站开往北京南站。此时ATP一直保持开机状态，且处于C3等级完全监控模式。17∶57∶41司机进行列车数据的输入，此时输入车长为210 m，17∶58∶00司机再次进行列车数据的输入，此时输入车长为420 m，至信号开放（出站信号于18：11：56开放）前，司机未再次对ATP进行操作。18∶11∶56出站信号开放，根据RBC逻辑，G272次列车MA达到RBC移交启动条件，此时开始启动合福RBC1向合蚌RBC2移交过程。但是，18∶15∶25司机第三次进行列车数据的输入，此时输入车长为210 m。18∶17∶06 发车，运行至 18∶29∶39 停车。

图1 场景示意图

如图1所示，列车停于站内，当发车信号机开放后，列车的MA延伸致RBC边界（K979+886处），移交RBC（合福RBC1）从而启动与接收RBC（合蚌RBC2）的移交。

从RBC日志中看，18∶12∶45，列车的行车许可延伸至移交边界，MA长度为19.541 km。

NID_MESSAGE=3, L_MESSAGE=202,T_TRAIN=1117136,M_ACK=1,NID_LRBG=5786966,NID_PACKET=15,Q_DIR=1,L_PACKET=88,Q_SCALE=1,V_LOA=0,T_LOA=1023,N_ITER=0,L_ENDSECTION=19541,Q_SECTIONTIMER=0,Q_ENDTIMER=0, Q_DANGERPOINT=1, D_DP=0,V_RELEASEDP=127,Q_OVERLAP=0,…

由于在RBC软件配置的MA最大长度参数为20 km，因此，移交启动后，合蚌RBC2向合福RBC1发送的授权相关信息请求（M202）的长度为459 m（即请求的长度=MA最大长度-移交RBC范围内的MA长度=20000-19541=459）；

nid_message= Route Related Information Request,nRbcNID_C=597,nNID_RBC=1,nNID_ENGINE=337212,nBg－NID_C=698,nNID_BG=2820,nT_RBC=1311025156,nM_ACK=1,nD_REMAINDISTANCE=459,nN_REMAINEOAINTERVALS=31,…

合蚌RBC2收到该授权相关信息请求后，判断请求的长度小于其管辖范围内第一个闭塞分区（即RBC边界顺着列车运行方向前方第一个闭塞分区，长度为1 949 m）的长度，因此，发送长度为0 m的授权相关信息（M221），列车的行车许可终点仍然为移交边界。

此后，18∶15∶25司机第三次进行列车数据的输入，修改列车车长为210 m，列车向移交RBC重新发送列车数据消息（M129），合福RBC1向列车发送确认列车数数据消息M8。

2 原理分析

RBC-TH型RBC之间取消与重新启动移交的设计逻辑和接口规范如下∶

（1）待移交RBC收到M8消息的确认后，应向列车发送SMA，终点缩短到边界;

（2）待收到SMA的确认后，移交RBC向接收RBC发送M204取消移交。

（3）移交取消后，移交RBC收到列车的位置报告后，重新启动移交，并向接收RBC发送新的移交预告消息（M201），该消息中将最新的列车数据告知接收RBC；（注：列车数据（P11包）只能随M201消息发送给接收RBC，且只在移交启动时发送一次）。

此时，合福RBC1收到车载发送M8确认消息后，应向列车发送SMA，将MA终点缩短到RBC边界，但是实际上合福RBC1未发送SMA，根据上述 RBC设计逻辑和接口规范第1、2条，合福RBC1就无法向合蚌RBC2发送M204取消移交消息，最终导致列车的MA一直停留在RBC移交边界。

正常情况下，移交RBC与ATP、接收RBC之间的消息交互流程如图2所示。

图2 RBC与ATP、接收RBC之间的消息交互流程图

但此时由于列车行车许可的终点恰好是移交边界，即与待发的SMA的终点相同，合福RBC1没有向列车发送SMA。而按照当前RBC的设计逻辑，在列车运行模式、等级未发生变化的情况下，只有收到列车对SMA的确认的情况下，才会取消移交。而在上述场景中，由于未发送SMA，也因此无法触发发送M204的机制，移交无法取消。

6月12日，合福高铁RBC1与合蚌高铁RBC2实际之间的消息交互流程如图3所示。

图3 本特殊场景下RBC与ATP、接收RBC之间的消息交互流程图

移交无法取消，导致新的列车数据无法告知接收RBC，而列车长度又是一个涉及安全的参数，因此，移交RBC不向接收RBC发送新的授权相关信息请求消息（M202），接收RBC仍然按照之前收到的M202消息中的参数发送RRI，即长度一直为0。

3 原因分析

因此，通过上述分析，不难得出上述特殊场景下RBC移交过程中导致MA无法延伸问题的原因：

（1）技术层面（直接原因）：一是合福RBC1收到车载M8消息的确认后，未向列车发送SMA，后续RBC之间的移交流程无法取消，导致新一轮重新移交流程无法启动。二是RBC软件配置的MA最大长度参数为20 km，当MA正好跨一个闭塞分区且RBC边界点正好在该闭塞分区入口处时，导致MA终点与RBC边界点重合。

（2）操作层面（间接原因）：在合肥南站24道出站信号开放前后，司机在ATP设备DMI上频繁修改列车长度数据，尤其在信号开放后仍在修改列车长度数据引发了上述RBC技术层面的问题。

4 处置措施

在原因清楚的基础上，制定解决该问题的措施就十分清晰了：

（1）修改RBC逻辑，即当合福RBC1收到车载M8消息的确认后，不论列车行车许可的终点是否在移交边界，都应向ATP车载设备发送SMA消息，从而可以启动后续重新移交的流程。

（2）修改RBC配置的MA最大长度，及将20 km的MA长度适当延长或缩短，使其能够覆盖RBC移交边界点前后一个闭塞分区长度。

（3）明确司机在ATP设备DMI上修改列车数据的时机，在C3完全模式下，尽量不要修改列车数据，如果需修改列车数据，应重启ATP设备后再进行修改。

综合评估对比上述三条措施：虽然第3 条措施不涉及设备修改工作，只是通过司机操作来避免问题的发生，但是由于设备问题给司机操作带来了不必要的多余操作，站在机务专业角度看，不具备可实施性；第1 条措施涉及到RBC 软件逻辑功能的修改，软件变动内容较大，带来的不可预知风险会增；第2 条仅修改RBC 的MA 最大长度参数，参数修改工作量小，实施便捷，风险小。因此，上述第2条措施为最佳措施。