CBI与RBC接口规范中的特殊点解析

赵晓东

(北京全路通信信号研究设计院有限公司，北京 100073)

CBI与RBC接口规范中的特殊点解析

赵晓东

(北京全路通信信号研究设计院有限公司，北京 100073)

针对CTCS-3级列控系统中计算机联锁设备与无线闭塞中心设备在接口适配过程中，针对接口规范中几项具有代表性的问题进行探讨分析，给出相应的解析说明。

接口规范；计算机联锁；无线闭塞中心

1 研究背景

在从CTCS-2(以下简称C2)级列控系统迈入CTCS-3(以下简称C3)级列控系统时,增加了一种全新的设备——无线闭塞中心(RBC), RBC用于实时计算列车移动授权并通过无线指挥行车,其所需基础线路信号授权信息来自于核心地面信号控制设备——计算机联锁(CBI),因此CBIRBC这两套设备间接口在C3级列控系统中起着极其重要的作用。铁道部为此发布了两部暂行标准规范:《CBI-RBC接口规范(V1.0)》和《RSSP-II铁路信号安全通信协议(V1.0)》,这两部规范分别从CBI-RBC接口的应用协议和安全协议两个角度制定,本文结合CBI-RBC接口适配过程中规范应用方面的部分问题进行研究。

2 规范中的部分特殊点解析

1) 通用应用层

由于RBC的制式不同,《CBI-RBC接口规范(V1.0)》中应用协议规范实际为两个协议,目前,应用协议一在国内客运专线中使用较多,如武广、京沪、沪宁、沪杭、哈大等高铁线路均使用此协议,应用协议二在郑西、广深港高铁线路中使用。从协议内容层面上看,应用协议一与应用协议二看似差别很大,但实际仅仅是对线路信息描述方式与格式不同,其所传达的本质信息是相同的。应用协议一与协议二相比,其最大的差别是多出一个协议层,称为通用应用层(GAL层)。GAL层需要将对象数据包(OP)按一定长度限制分为若干条消息(Message),然后将同一执行周期生成的所有消息合成一个消息组(Batch),如图1所示。

图1 GAL层分包示意图

通用应用层在规范中是明确提出的,但是很多人不理解为什么要在应用层之上增加一个GAL层,也不清楚在具体工程实施中如何将应用层数据限制为不超过480 Byte。

因此有必要在此解释说明一下,由于CBIRBC通信是建立在TCP/IP协议基础上的安全协议,因此它需要受TCP/IP协议的制约,IP链路层具有最大传输单元MTU的限制特性,它限制了数据帧的最大长度,不同的网络类型都有一个上限值,局域网的MTU最大限制为1 500 Byte。如果IP层数据包传送的请求长度超过了MTU上限,那么IP层就要对数据包进行分片(fragmentation)操作,使每一片的长度都小于或等于MTU。假设要传输一个数据包,一般IP首部为20 Byte,TCP首部为20 Byte,数据的净荷(payload)部分预留是1 500-40=1 460 Byte。当用户数据长度大于1 460 Byte,IP协议就会出现自动分片行为。

针对这一特点可知,当传输的用户数据太长时必然被分割成若干片传送,接收端则需要将所有片聚齐以后才可以接收解析。一旦传输过程中某一分片出现错误或丢失,则依照TCP/IP协议,整个协议数据单元必须全部重传,这样一来存在两个风险:一是大量数据重传可能会加重网络拥堵几率,另一方面会加大信息延时。铁路信号控制领域信息的时效性是很重要的一项指标,也就是说,即使重传成功,数据可能已经过时失效了。总之,基于TCP/IP构建安全通信协议的要求是避免TCP/IP协议带来的影响,数据拆分合并的功能应该由应用业务实现,而不要被底层进行过度干预,从而达到安全可控。

为了实现这个目标,我们需要为应用层预留出充足的安全层附加信息余量后,限制用户数据最大长度,其原理实质是依靠人为的应用层分包来避免IP底层分包动作,这样做的好处就是即使传输过程中丢了一小包,则TCP/IP协议处理只会重传这一小包的内容,不至于重传分组后的其他子包。所以当用户数据超过此限制时,必须在应用层用户数据交付安全层处理之前预处理分包,这就需要加入一个中间子层——GAL层。

按照《RSSP-II铁路信号安全通信协议(V1.0)》安全协议来说,各协议层帧头(包括帧尾)附加长度为56 Byte,即应用层的长度为不大于1 460-56=1 404 Byte即不会引起IP分片, 但《RSSP-II铁路信号安全通信协议(V1.0)》安全协议规范为了扩展预留了足够的帧头帧尾附加域尺寸,规定了应用数据包最长不超过1 000 Byte。

在实际工程使用中,考虑到RBC可能连接无线广域网,其链路MTU最大限制为576 Byte,去掉TCP/IP首部后为536 Byte,因此在使用《RSSP-II铁路信号安全通信协议(V1.0)》安全协议去掉各协议层帧头(包括帧尾)附加长度56字节后,应用数据最大长度限制为480 Byte。CBIRBC接口虽不属于无线广域网链路,但为了软件处理一致性,因此应用层提交安全层处理之前,统一规定每包数据不超过480 Byte。

2) “进路状态”与“降级状态”

接口开发之初,在信号授权信息(SA信息)帧中,其中有两项概念内容不容易区分,即“进路状态RouteStatus”与“降级状态DegradedStatus”,其中“进路状态”取值有“降级”状态一项,而同时规范中说明,当“进路状态”为“降级”状态时,将“降级状态”也置为“设置降级”,否则为无降级。

这个表述方法给人的直观感觉就是“降级状态”中的设置降级完全取决于“进路状态”,也就是说“降级状态”看不出任何意义,“进路状态”已经完全涵盖了它的信息。这样理解是没有错误的。但问题就在于既然“降级状态”字段没有用处,为什么SA帧结构中还要单独设“降级状态”一项,在此做一下解释说明。

C3级列控系统的RBC技术引进于欧洲的ETCS-2列控技术(以下简称E2)。在原始的E2技术中存在“联合缩短移动授权”的功能,该功能可以大大缩减联锁系统的解锁时间,进而提高系统的执行效率。具体来讲,该功能是指CBI在进路降级(即对已给出信号授权的进路取消或人解)时需要征得RBC的许可,方可执行降级动作,完成进路解锁。因此,比如值班员取消或人解进路时,CBI先会将“降级状态”一项置为“设置降级”,以表示向RBC提交降级申请,假如该进路SA已经被RBC分配给列车,则RBC还会将CBI降级请求转给列车,在确定列车可以在解锁进路信号机前停车后, RBC会告知CBI准予降级;否则,列车仍有可能闯入需要解锁的进路,所以RBC不予降级。综上, CBI提出申请,并经RBC许可后方可将进路状态置为“降级”状态。

在E2技术引进时,由于我国铁路运输的复杂性,要求C3制式线路要后备兼容C2甚至C0技术,对CBI子系统的功能独立性要求非常高,尽可能的不用其他子系统的功能去约束国内成熟的CBI控制技术,因此目前CBI不使用RBC的任何应用信息,在CBI进行取消进路等操作时,不会等待RBC回应,直接将“进路状态”与“降级状态”置为“降级”。但协议为了保留其成熟格式以及预留日后技术的更新扩展,在信息帧中还是做了保留。

3) 保护区段状态

“保护区段状态”在帧结构中的位置是替代了E2规范中“危险点(danger point)”字段,用于股道长度较短导致列车无法全部进入股道的场合。在我国C3级列控系统中,“危险点”的概念尚无实际意义,因此将其替换为“保护区段状态”,但对RBC、CBI来说,“保护区段”设置原则、使用规则等相关细则尚未制定,所以目前仅作为预留功能在帧结构中保留其位置,实际工程中暂不启用。

4)主备系网络发送问题

对于二乘二取二系统平台来说,分主备二重系,在《CBI-RBC接口规范(V1.0)》中4.1.1.6条规定:“CBI主备系均向RBC发送应用层消息,RBC仅主系向CBI发送应用层消息。”针对该条款的疑问,笔者认为该条款表述不准确。

实际情况是目前国内所有客专线路中不管哪种平台制式的RBC、CBI,接口中通信双方均为仅主系发送应用层消息,主备系均接收对方应用层信息。

对于此条款形成的原因,有其特殊背景,在使用从庞巴迪引进的RBC平台中发现,虽然开发引进之初规定仅主系发送应用层消息,但后来发现RBC平台的双系以太网通道均有应用层信息送出,看似RBC主备系均向CBI发送应用层信息,然而实际情况是,RBC主系为了最大限度实现冗余网络的优势,不仅使用自身的网络通道,也使用了备系的网络通道,即发送时看似备系通道发出来的数据,实质是主系生成的数据经由备系通道也送出去,并非备系生成的数据发送了出去。同理,在接收方面, RBC主系也会同时利用备系通道收回数据,即使主系与某个设备的双通道均中断,仍可以利用备系通道收到对方主系信息。

因此为了消除歧义,可能原文想表达成RBC主备系均向CBI发送应用层消息,CBI仅主系向RBC发送应用层消息,结果由于笔误造成诸多误会。此处笔者只想说明一下实际情况是通信双方均只有主系发送应用数据,这一点是不容置疑的。

5)EC与TTS

在《RSSP-II铁路信号安全通信协议(V1.0)》规范中,描述了两种时延防护手段,即3倍时间戳(TTS)方式与执行周期计数(EC)方式。

TTS防护技术不需要设定固定通信周期,通过时钟偏移估算而达到信息时效性的判定,适用范围广,既可用在非周期性通信的系统上,又可用于周期性通信的系统上。其计时分辨率为10 ms,在实践中多用于非周期性通信,如事件触发式通信时使用。另外,该技术方案与IEEE1588的符合性很高,可以看作是IEEE1588在铁路通信技术中的一个应用实例。

EC防护技术顾名思义是以执行周期来计数的,因此其计数值非绝对时间计数,是按照通信周期时长来累加的,对周期性通信的系统,执行周期计数是一种便捷有效的时延防护方式。

《RSSP-II铁路信号安全通信协议(V1.0)》最初源于RBC-RBC之间通信协议,RBC之间仅存在列车跨区切换时才需要交互信息,所以信息发送方式采用事件触发式,并非周期性交互信息,设计TTS防护技术,即在于不需要设定固定通信周期,因此在对信息时效性的判定上《RSSP-II铁路信号安全通信协议(V1.0)》提出两种方式可选,但互相排斥,即不可同时使用。

3倍时间戳的计数值是以10 ms为精度的,虽然适用范围广,但防护运算方式复杂,对系统平台特性依赖性强,要求较高。而EC则是按照系统运行周期计数的,延迟威胁的检测通过对接收到的消息中的EC计数值和本地计算的EC计数期望值进行比较实现。因此在CBI-RBC接口中,由于采用周期性通信方式,故选择了更加便捷的EC防护技术。

有一点特别需要注意的是,规范中规定,使用EC后,帧结构中TTS域仍然保留,对应的TTS3个时间戳位置均填0。这是对发送方规定的,但不少开发人员对此误读,在接收端对对方的此信息域是否为0进行校验。如不是,则认为是非法数据。

实际上,这是一种误读,TTS技术是防护时效性的,既然不使用此技术,则不应该对此域进行校验,TTS域填0只是觉得既然保留了位置,就需要有个值填进去,对开发人员来说,给出了一个常规缺省处理方法,但并不要求接收方检查此域。实际上发送方将此处填写其他任意值,接收方都不能认为是非法信息。这在《RSSP-II铁路信号安全通信协议(V1.0)》规范中是有明确规定的,只是不容易引起开发人员注意,在此强调一下。

本文结合CBI-RBC接口适配工程实际开发过程中反映较多的几项问题进行分析,希望能与同行共同探讨、共同进步,如有不当之处敬请指正。

In the process of interface adaptation between computer-based interlocking (CBI) equipment and radio block center (RBC) in CTCS-3 System, there are several typical problems in the interface specification. And the paper analyzes and discusses these problems and gives the corresponding explanation.

interface specification; CBI; RBC

10.3969/j.issn.1673-4440.2014.04.031

2014-06-13）