铁路联锁与调度集中标准接口规范缺陷分析及升级研究

宋鹏飞

(1.中国铁道科学研究院通信信号研究所,北京 100080； 2.国家铁路智能运输系统工程技术研究中心,北京 100081)

计算机联锁系统(简称为“联锁”)是我国铁路系统关键的车站基础信号设备，调度集中系统(Centralized Train Control，简称为CTC)是高速铁路列车调度指挥、集中控制的重要技术装备。目前联锁系统与CTC系统之间的标准接口规范遵循的是《调度集中车站自律机与计算机联锁接口通信协议(V1.1)》(运基信号[2006]312号)[1]。两大信号系统接口通信的安全可靠性直接影响到列车调度指挥的安全及效率[2-3]。

随着高速铁路线路的广泛开通运营，二者之间的通信过程逐步暴露出部分问题[4]。本文主要探讨目前联锁与CTC系统的标准接口规范缺陷，分析二者之间的标准通信流程及交互信息流，对双方之间基于安全通信协议进行通信的可行性进行了设计研究。

1 既有接口协议介绍

既有的接口规范为《调度集中车站自律机与计算机联锁接口通信协议(V1.1)》，该规范于2005年由原铁道部组织联锁、CTC厂家统一讨论编制并试用，2006年正式发布，主要的传输逻辑包括以下5个方面。

(1)联锁与CTC之间通过串口建立通信。

(2)CTC作为通信的发起方，主动建立连接；联锁系统作为通信的应答方，被动响应连接请求。

(3)双方传输数据时，通过对数据帧的发送序号、接收确认序号进行逻辑检查，以判断是否丢帧重帧；通过信息中的循环冗余校验码(CRC)确定信息是否被篡改讹传。

(4)通信双方定时向对方发送心跳以维持通信链路的稳定。

(5)双方传输的主要应用数据主要包括：联锁向CTC发送站场表示、站场变化表示、自律请求、状态报告、时钟同步请求信息；CTC向联锁发送控制命令、自律同意、请求站场表示、时钟同步数据。

2 既有接口规范遇到问题及分析

既有接口规范制定的年代较早，在编制时单纯考虑了联锁与CTC如何以一个简单有效的逻辑进行交互应用数据，经过十多年的现场应用，遇到部分问题如下。

(1)既有接口协议不满足当前EN50159及GB/T 24339的要求。

联锁系统为SIL4级安全型设备，CTC系统为低等级的非安全信号设备。按照铁路信号系统的安全通信标准要求，安全相关设备的数据通信必须建立安全通信功能[3]。

随着我国铁路的高速发展，2009年国家正式颁布GB/T24339标准[5-7]，明确轨道交通领域通信信号的安全相关通信内容。此标准是源于欧洲铁路信号安全标准系列的安全通信标准EN50159，条款内容完全一致，可视为等价标准[8-10]。按照GB/T 24339要求，安全相关设备(联锁)与非安全相关设备(CTC)之间的通信，需要在安全相关报文(message)中增加安全编码(transmission code)，使安全相关和非安全相关的报文具有不同的结构，安全编码应能够保护系统达到要求的安全完整性等级(SIL 4级)。而目前联锁与CTC的标准接口规范协议不具备安全层的防护。

(2)接口规范对高铁线路的需求考虑不足。

既有接口规范原是为了普速线路及最初的客专线路制定，高铁线路大面积开通运营后接口规范并没有进行专门修订，只在既有基础上进行打补丁扩充，比如高铁线路中的“点灯”“灭灯”的显示及控制、“尖轨”“心轨”的操作等新需求均是联锁和CTC双方在应用中协商扩充，这导致了不同厂家在扩充时信息帧格式不尽相同。这也侧面表明原有规范在制订时对技术的适应性、前瞻性考虑不够，有损标准规范的权威性[11-12]。

(3)既有规范对联锁与CTC通信的安全校验及安全防护部分较为薄弱。

当前协议规范中，联锁与CTC通信双方根据发送序号(1字节)、接收确认序号(1字节)、CRC(2字节)对信息进行简单的安全确认，安全性卡控不足。分析协议可以得出接口规范的风险防御矩阵如表1所示。

表1 既有接口规范防御矩阵

注：√表示防御措施与威胁的应对关系

可以看出，风险防御的手段略有单薄[13-14]，基本全依靠一个字节的序号及2个字节的CRC校验进行防御。当前接口协议使用的是CRC16生成多项式，即G(x)=x16+x15+x2+1。CRC16的漏检率可以通过算法计算，按照当前16位CRC通过漏检率分析算法[15]，仍存在收到干扰数据的可能。

案例：2016年9月某铁路局现场运行过程中发生了CTC端站场显示异常，经分析CTC端收到的信息流如图1所示。

图1 异常信息流

现场数据流中出现了“断尾帧”的异常情况，串口接收器工作异常导致接收到的信息为半截，之后新的一帧数据与断尾帧进行了拼接，如图1所示，信息流1与信息流2的CRC校验值完全相同，均为0x1b 0x22。此次极端情况下发生CRC碰撞校验值相同，引起CTC端处理逻辑异常，从而导致了站场表示显示错误。

(4)接口规范在双方通信连接的维持上存在瑕疵，部分核心信息没有定时发送。

当前接口规范的逻辑下，双方通道没有主动释放的过程，只能被动的依赖超时。联锁与CTC双方在连接成功建立之后，任何一方的中断或退出，对方均无从悉知，只能被动等待超时。

在通信建立后没有应用数据时，双方仅发送心跳信息，而核心的状态信息没有定时发送，比如主备状态、是否允许转自律、当前控制状态等。

(5)既有规范对列车调度指挥系统(TDCS)系统与联锁接口适用性不足，无法做到单向数据传输。在联锁与TDCS等系统通信时，一般要求TDCS端不向联锁发送应用数据，只接收联锁端的应用数据，既有规范不支持此种场景。

(6)既有规范对工程实施时要求不严谨。通信接口时无法体现本机是A机还是B机，对方是I系还是II系，只能依靠工程实施布线时，强制指定。

3 安全通信协议研究及验证

目前我国针对铁路信号安全设备之间安全相关信息的交互流程，制定了铁路信号安全通信协议(RSSP)[7]，其中RSSP-I适用于封闭式传输系统，RSSP-II适用于开放式传输系统。对照协议，联锁与CTC之间可归类为典型的封闭式信号传输，即“连接的设备数量固定或最大数量固定，有已知且固定的特性的传输系统，对于此系统可以忽略非法访问的风险”。为此可分析考虑RSSP-I型安全通信协议是否适用，并进行可行性验证。

3.1 RSSP-I协议介绍

RSSP-I安全通信协议是从接收端角度设计的保护算法[16-17]，能够解决封闭环境下的信息安全传输。对封闭式传输系统而言，可存在的威胁包括：数据帧重复、数据帧丢失、数据帧插入、数据帧次序混乱、数据帧错误、数据帧传输超时。RSSP-I协议要求通信双方必须基于周期性交互，主要存在3种帧类型。

(1)实时安全数据帧RSD，通信双方将应用层的数据均封装在此RSD数据帧中，定时周期性发送。

(2)时序校正请求SSE，通信的任何一方在接收数据后检查到数据帧的时序错误时，触发式的向发送端发起时序校正请求。

(3)时序校正答复SSR，通信的一方收到对方的时序校正请求后，即时反馈时序校正应答。

RSSP-I的威胁防御矩阵如表2所示。

表2 RSSP-I协议防御矩阵

注：√表示防御措施与威胁的应对关系

基于RSSP-I安全通信协议开发联锁与CTC的通信接口规范[18-20]，需在3方面考虑可行性：安全性、工程性、业务性。

分析RSSP-I协议，可以得出在威胁防御方面RSSP-I能够满足GB24339和欧标EN 50159的要求，可解决既有接口规范遇到的安全性、工程性问题，主要包括：(1)双方通信接口能够实现安全数据通信，保证了数据报文的安全传输，异常情况下也可做到数据的安全卡控；(2)协议框架支持单向数据传输，联锁单向对TDCS传输数据可适配；(3)协议框架具有严谨的A机、B机区分，更符合工程实施规范。为此，需重点考虑基于RSSP-I协议框架对联锁与CTC之间数据业务的可行性，分析安全通信协议是否适配联锁与CTC之间当前传输的应用层数据要求[21]。

3.2 既有应用数据帧的安全协议适用分析

既有规范中联锁与CTC传输的数据分为2类：通信控制帧和数据传送帧。其中通信控制帧主要包括通信建立、维持的信息；数据传送帧主要包括应用层业务数据信息，如表3所示。

表3 帧类型及用途

通过表3可以看出，双方交互的信息帧类型繁多复杂，部分帧类型在现场应用时也是多余无用的(比如版本号错误帧、故障报告帧等)。双方连接建立是由CTC方主动发起连接，联锁被动响应；应用层的信息主动发送，并等待对方确认应答；部分与业务应用无关的数据比如时钟信息、请求信息、状态信息等，也通过帧类型进行交互。

为此需要分类处理，对业务数据和非业务数据进行差异化的分析。

3.2.1 通信建立相关帧

基于RSSP-I安全通信协议下，原有的通讯控制帧涉及的部分信息类型可以废弃，RSSP-I中的SSE、SSR数据帧完全替代原有的通信建立过程，另外，RSSP-I协议在传输中增加了身份源标识符SID来保证信息源头的真实性，SID与时间戳伪随机数经过异或运算结合在一起传输，能够对传输的报文进行安全的防护。

3.2.2 时钟数据相关帧

既有接口规范要求联锁系统定时(每天6：00、18：00整点)向CTC申请时钟，CTC反馈应答当前时钟。这种申请-应答的方式增加了双方通信的复杂度，可以通过CTC方在RSD封装的应用层消息的头部插入时钟信息块代替，CTC每一个周期性RSD消息均自带当前时钟信息，从而大幅简化交互流程。

3.2.3 状态报告帧

既有联锁与CTC的状态报告帧(RSR)包含2个字段，除了各自包括本端主备状态外，联锁发出的RSR帧包含“当前联锁的自律/站控工作模式”，CTC发出的RSR帧则包含“是否允许联锁转为自律模式”字段。既有规范对此信息要求有变化时主动发送，而此信息属于关键信息，一旦出现丢失则会引起中断甚至逻辑错误，在现场实施时联锁与CTC双方为了避免异常情况，一般均人为设定定时发送。为此，使用RSSP-I协议时双方可在RSD数据包中插入对应的RSR状态，周期性地发送。

3.2.4 控制命令帧及自律申请、自律同意帧

这一部分作为双方交互的核心信息非常重要，其中控制命令帧为CTC向联锁发送排路等控制命令；自律申请帧为联锁系统由站控申请切换为分散自律模式；自律同意帧为CTC收到申请后确认可以转为分散自律模式。这3类信息是双方传输的关键信息，既有协议中将此3类信息与其他普通信息类型同等对待不做特殊区分，在实际应用中颇受诟病。为此可对这部分信息增加命令ID(4字节)字段，信息的发送方在发送时填写唯一的命令ID，接收方收到此信息后以原ID反馈，确认收到此命令。

3.2.5 联锁站场表示相关信息

当现场车站信号设备状态发生变化时，由联锁系统主动触发发送站场表示信息及站场变化信息。RSSP-I协议框架下完整的一包RSD可容纳的应用层数据域最大长度为524字节，汇总当前几个联锁厂家对外接口数据，对一个标准站型的车站所有信号设备状态进行评估，得出如下结果：(1)对类似“4组股道、10组道岔”站型的车站，联锁全体站场表示信息一般为60字节左右；(2)迄今为止，最大站场下联锁的全体站场表示信息少于700字节；(3)既有接口规范中全体站场表示信息最大为1 013字节。综上，对任何一个车站的站场表示信息，均可由RSD数据帧封装发送；站型较大的车站可通过2包RSD覆盖。既有接口规范对双方通信时串口波特率选择的是19 200 bps，可粗略的视为1秒钟最快可传输2400字节数据；鉴于RSSP-I协议500 ms的周期性传输要求，而联锁与CTC机柜之间距离较短，可更改双方传输波特率为38 400 bps，更快的传输数据以节省双方串口通信耗时。

3.3 RSSP-I协议下接口协议设计

基于RSSP-I安全通信协议，联锁发往CTC的信息体格式可定义为表4协议蓝本。

表4 RSPP-I框架下联锁发送数据协议蓝本

CTC向联锁发送的数据流协议可以按照表5格式。

表5 RSPP-I框架下CTC发送数据协议蓝本

按照上述的协议蓝本，在RSSP-I协议框架下，联锁和CTC构建安全通信连接，以此协议传输业务数据。

4 基于RSSP-I协议测试验证

为了验证协议的适用性及稳定性[22]，选择一个标准站型、最大规模的2个车站进行测试，以北京铁路局津秦高铁唐山津秦场站(25组道岔、6组股道、17架进站及出站信号机)、北京铁路局枢纽区段动车段站(259组道岔、100组股道、405架进站出站调车信号机)为例进行仿真测试。联锁仿真与CTC自律机软件按照串口连接，波特率为38 400 bps。其中，唐山津秦场联锁的全体码位接口数据约180字节；动车段的全体码位接口数据约为690字节的数据，验证结果见表6。

表6 新旧接口协议耗时对比 ms

基于RSSP-I安全通信协议下，通信指标与既有接口规范均满足技术条件的要求，几大测试项差别不大，同时对协议进行预留扩充，满足后续新需求的扩充。测试发现，只有超大型车站站型下相比既有的接口规范略有延时，这是因为设计的RSSP-I协议蓝本每一次都发送了全站信息，且大型车站站场码位需要分2包依次发送，从而产生了部分耗时，而既有接口规范默认只发送变化的站场信息。后期可以优化调整接口协议蓝本，对标准站和大型站分别处理。

5 结语

随着高速铁路的走出去策略，我国铁路信号产品按照欧洲铁路信号安全标准进行认证并获取独立第三方资格认证，已成为必然趋势。本文根据我国GB体系、欧洲EN50159标准，对CTC与联锁系统之间的既有接口通信规范进行了分析，对接口协议升级为RSSP-I协议框架进行了设计研究，并在实验室仿真环境系下进行了测试验证，明确了双方之间可以按照RSSP-I协议升级，为进一步提高两大铁路信号系统之间的安全通信提供了一个方案。