列控系统通信中断问题的分析与思考
2020-06-19王先帅中国铁路上海局集团有限公司电务部
王先帅 中国铁路上海局集团有限公司电务部
目前,采用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 总结语
随着后续大批线路的开通和新型设备的上道使用,设备间通信不匹配的问题还会出现。通过细化标准、规范软件编制与测试可大大降低问题出现的概率。即便在运用中出现类似问题,积极对底层数据和处理逻辑进行分析,也会很快找到症结所在,制定出切实可行的解决方案。