列控系统通信中断问题的分析与思考

王先帅 中国铁路上海局集团有限公司电务部

目前，采用CTCS-3 级列控系统构建的错综复杂的高速铁路网已实现互联互通。但随着新线路的陆续开通，线路上不同厂家设备并存的现象越来越普遍，设备间的接口也越来越多，越来越复杂。我国高速铁路交叉成网、运输密度高、运营场景复杂，在某些特定的场景下，设备之间通信不匹配的问题偶有发生。笔者结合管内设备运行情况，对两起设备间通信中断问题进行分析与探讨。

1 故障一：相邻RBC 间通信中断

1.1 概况

徐盐铁路引入徐州东枢纽时，对徐州东枢纽地区的RBC管辖范围做过适应性调整，调整后的RBC 管辖情况见图1。

图1 徐州东枢纽RBC 管辖范围示意图

其中，徐盐RBC1 为铁科院产品，首次在管内运用。郑徐RBC3 为通号院产品，2015 年开通运用至今。两个RBC 的切换点位于徐兰高速徐州东线路所至铜山线路所之间。

徐盐RBC1 开通后，动车组在徐兰高速上行线运行，会偶发以下故障：当运行至郑徐RBC3（移交RBC）与徐盐RBC1（接收RBC）移交区时，由于两个RBC 之间通信中断，导致ATP 车载接收的MA 突然缩短，造成列车紧急制动停车。

1.2 原因分析

为切实找准故障原因，对安全层数据和应用层逻辑进行分析，以2019 年10 月24 日发生的故障为例进行探讨。

（1）安全层数据分析情况：双方RBC 采用RSSP-II 协议，使用TTS 通信方式。在TTS 通信方式下，相邻RBC 通过定期互相发送时钟偏移信息实现握手，其中时钟偏移请求和时钟偏移应答信息格式完全相同。

对故障时刻安全数据网的数据抓包见图2。

图2 安全数据网抓包数据

根据抓包数据，徐盐RBC1 发送3 包应用数据（抓包序号22816、22824 和 22834）后，随即发送了时钟偏移更新请求（抓包序号22860），经调阅分析，这四包数据的时戳均为0xlc3919a9。

在徐盐RBC1 发出时钟偏移更新请求（22860）的同时，郑徐RBC3 发送了时钟偏移更新请求（22874）。由于在此前已收到徐盐RBC1 时间戳为0xlc3919a9 的应用数据（22816、22824和 22834），（22874） 中“上一次接收方时间戳”设置为0xlc3919a9，导致徐盐 RBC1 误认为郑徐 RBC3 发送的（22874）是对（22860）的时钟偏移更新应答，徐盐RBC1 判断时钟偏移更新流程完成。而郑徐RBC3 发送的真正时钟偏移更新应答（22877）又被徐盐RBC1 认为是下一次时钟偏移请求，徐盐RBC1 针对误认的请求信息（22877）发送新的时钟偏移应答数据。由于存在这种错位误判，在后续的信息交互中，两RBC 均把对方RBC 发送的“应答信息”误判成“请求信息”，均认为对方RBC 不停的发送“请求信息”而不处理本RBC 发送出去的“应答信息”，郑徐RBC3 无法完成时钟偏移更新，直至郑徐RBC3 第五次发送“请求信息”超时后，向徐盐RBC1 发送中断通知（DI），两 RBC 通信中断。

（2）应用层逻辑分析情况：郑徐RBC3 与徐盐RBC1 通信中断后，郑徐RBC3 启动C3 降C2 流程；10S 后，徐盐RBC1发送AU1，重新建立安全连接，与郑徐RBC3 通信连接恢复正常，并向郑徐RBC3 发送“取消移交”指令；郑徐RBC3 采用“取消移交”指令，将MA 缩短至RBC 边界，造成ATP 车载设备接收的MA 突然缩短。

通过上述分析，可以看出问题的根本原因在于双方RBC均不能准确区分对方发送来的时钟偏移请求和时钟偏移应答信息。

实际上，为准确区分时钟偏移请求、时钟偏移应答信息，通号院RBC 和铁科院RBC 也均采取了相应措施。通号院RBC 通过优化协议栈的方式，区分同一周期内不同消息的时间戳；铁科院RBC 增加了对时钟偏移信息的防护机制。因此同型设备之间互相通信时，不会发生类似问题。但在互联互通场景中，两家设备间互相通信时，由于采取的措施不同，则无法准确区分对方发来的时钟偏移信息。

1.3 解决方案

鉴于平台原因及修改底层数据的难度，经通号院、铁科院通号所共同研究，双方RBC 在以下方面进行优化，以解决该问题。

（1）安全层方面，优化修改通号院RBC。目前通号RBC 与铁科RBC 配置的时钟偏移请求间隔均为2 min，通过调整通号RBC 发送时钟偏移请求间隔（如改为2 min30 s），将双方更新时钟偏移的周期错开，最大程度降低触发该场景的概率。

（2）应用层方面，优化修改铁科院RBC。一是修改重连时间参数和应用层超时时间，RBC 建立TCP 连接后立即启动安全连接建立，同时修改应用层判断超时时间，由5 s 修改为7 s；二是修改判断应用层连接超时后不发送“取消移交”M#204 消息，这样即使发生RBC 通信中断的情况，列车会无线超时降级C2 运行，不会触发紧急制动停车，增加了可用性。

2 故障二：RBC 与联锁通信中断

2.1 概况

沪杭高铁线，RBC 为通号院设备，计算机联锁为卡斯柯设备，自2010 年开通以来运用至今。2019 年下半年，沪杭RBC 2 与嘉兴南联锁偶发通信中断故障。

2.2 原因分析

以2019 年12 月10 日发生的故障为例，对相关数据及逻辑进行分析。

（1）联锁数据分析

2019 年 12 月 10 日，19：34：56.690，CBI（172.74.21.53）3.5秒内没有收到RBC 发送的应用层数据，因此向RBC（172.74.21.155/156）发送 DI（请求中断）数据包，RBC 收到后将通信中断，并进行重连，重连后恢复正常，联锁数据见图3。

图3 嘉兴南站联锁抓包数据截图1

进一步对联锁数据进行分析，发现RBC 向CBI 发送的数据包进行了拆包处理（见图4）。

图4 嘉兴南站联锁抓包数据截图2

（2）逻辑分析

沪杭高铁线于2010 年开通运营，RBC 与CBI 通信协议参照《铁路信号安全通信协议技术规范》（运基信号〔2010〕267号）执行，规范中明确“用户数据长度不超过1 000 字节”，因此当RBC 向CBI 发送的数据超过一定字节数时，需进行拆包处理。

其中通号院RBC 拆包逻辑为：当RBC 向CBI 发送的数据包字节数超过480 字节时，即进行拆包处理。

卡斯柯CBI 对RBC 发送来的拆包数据处理逻辑为：CBI默认RBC 只有在发送的数据包字节数超过1 000 字节时才会拆包，而对通号院RBC 发送的480 字节的拆包数据不识别，认为数据异常，CBI 应用层判断没有收到来自RBC 的有效信息。

《列控系统 RBC 接口规范》（运基信号〔2010〕533 号）第5.1.1.2 规定：如果CBI 在规定时间内未收到来自RBC 的有效信息，则认为与RBC 的通信中断。因此当RBC 拆包发送持续时间超过3.5 s 的情况时，CBI 应用层判断超时，发送DI 数据包，主动切断通信尝试重连。

通过上述分析，可以看出问题的根本原因是：在特殊场景下，当RBC 在同一周期内向CBI 发送的字节数较大时（大于480 字节），由于RBC、CBI 对拆包数据的处理方式不同，导致CBI 无法正确识别RBC 数据。

2.3 解决方案

解决该问题，可从两个方面考虑：（1）修改RBC 拆包逻辑，即当RBC 向CBI 发送的数据包字节数超过1000 字节时，再进行拆包处理；（2）修改CBI 对RBC 发送来的拆包数据的处理逻辑，即能够有效识别通号院RBC 发送的480 字节的拆包数据。

鉴于RBC 平台问题及参数修改难度，经通号院、卡斯柯共同研究，对CBI 的处理逻辑进行适应性修改。

3 两起故障的共性分析

3.1 两起故障的共同点

（1）相关设备供应商编制的软件都在标准体系框架内，没有突破规范，但由于各家对标准的理解不同，在执行时同一条款时，处理方式不尽相同，软件存在差异化，兼容性上并非完全匹配。

（2）上述问题都不是设备上道后立即出现，而是在设备运用一段时间甚至相当一段时间后，在某种特殊场景下出现。故障虽不是普遍发生，但十分典型。

3.2 反映的问题

（1）设备供应商在编制软件时，各自为战，缺少必要、全方位的沟通，对软件处理上的差异性相互之间没有做到全面交底，机器语言传送时，不能准确识别，设备上道后不能适应错综复杂的现场运用场景。

（2）设备上道前互联互通试验不充分，测试案例不全面，测试序列不详细，没有对软件的差异化处理进行全面的梳理与验证。

4 建议

（1）细化标准。主要是指CTCS-3 级列控系统标准体系中，通信语言中的消息类型、消息中各字段的含义和取值范围进行明确的定义，避免引起歧义、多义，杜绝不同设备供应商存在不同的理解。

（2）加强沟通与对接。主要是指在软件编制前，相关设备供应商之间对软件处理方式进行全面的技术交底，特别是接口间传递的消息和报文格式须具有统一的布局，统一的报文定义。

（3）全覆盖测试。主要是指设备上道之前进行的软件互联互通试验应严谨周详，编制全覆盖测试案例，再量化成详细的测试序列来验证预设测试案例的正确性。需要指出的是，建议不同设备供应商将软件存在的差异化处理进行列表，逐条确认测试序列是否覆盖，满足互联互通要求。

5 总结语

随着后续大批线路的开通和新型设备的上道使用，设备间通信不匹配的问题还会出现。通过细化标准、规范软件编制与测试可大大降低问题出现的概率。即便在运用中出现类似问题，积极对底层数据和处理逻辑进行分析，也会很快找到症结所在，制定出切实可行的解决方案。