基于FFFIS 编码的列控中心应答器报文生成软件优化设计

温 强

（中铁第五勘察设计院集团有限公司，北京 102600）

0 引言

应答器是车地之间基于电磁耦合原理传输信息的点式信号设备。列控中心（Train Control Center，TCC）具有应答器报文组帧和编码功能，根据联锁系统的进路信息和调度集中（Centralized Traffic Control，CTC）下发的限速命令生成应答器报文。应答器功能复杂，报文数据加密涉及到透明传输的防恐安全保护机制。目前，我国的应答器报文编码和译码算法参考欧洲FFFIS 标准执行，具有较高的安全性[1]。

目前，已有众多学者针对应答器报文生成方面做了大量的研究。文献[2]提出将具有不等差错保护特性的数字喷泉码作为欧洲高速铁路应答器报文编码方案。文献[3]研究了列控中心中央处理器接收到进路信息之后，匹配对应的目标报文模板，根据接收的临时限速信息更改模板中临时限速信息并实时生成用户数据的方法。文献[4]通过构造反向查询的字母表、减少检查字母表条件的字数、优选指标与整形约束条件检查同时进行的方式优选报文。以上研究对应答器报文生成方案做了大量理论研究，但是对整个列控系统没有进行全面的实物仿真分析。

本文针对现场列控系统全天候工作、功能复杂、接口众多等特点[5]，在计算机联锁系统、临时限速系统、CTC 等系统建好的硬件和软件平台条件下进行了实物仿真，软件实现符合功能接口规范（Form Fit Function Interface Specification，FFFIS）编码改进算法。在进路信息和临时限速的命令下，完成列控中心应答器编码译码、接口通信等软件设计，完善CTCS-3 级列控仿真培训系统功能设计[6]。

1 列控中心接口功能需求

列控中心是列控系统的核心设备之一，系统接口复杂[7]。本文只介绍列控中心到地面电子单元（Line side Electronic Unit，LEU）的“S”接口和LEU 到应答器的“C”接口。列控中心接口如图1所示，其中S接口负责TCC和LEU之间的有线通信。外部信息发生变化时，LEU 向应答器发送新的数据报文；C 接口是应答器与LEU 的通信接口，其作用是将更新的数据信息传送给应答器[8]。

图1 列控中心部分接口示意

2 应答器报文编译码设计

2.1 应答器报文格式

本文采用的应答器报文编码、解码标准与欧洲铁路信号组织规定的应答器报文编码、解码标准一致，应答器报文标准为UNSIG SUBSET-036 标准[9]。其报文格式如表1 所示。

表1 应答器报文格式

用户报文起始块是一组整形数据，长报文包含913 位，即b1022…b110；整形位后是3 位控制位（Control bit，Cb），即（b109、b108、b107），其中b109 是反转控制位，其值设置为“0”；b108，b107分别设置值为0 和1；12 位的加扰位（Scrambling bits，Sb）即b106…b95，是对用户信息加扰；10 位额外整形位（Extra shaping bit，Esb）即b94…b85是对校验位进行整形限制；最后是85 位的CRC 校验位。

按照UNISIG SUBSET-036 标准规定，整个报文编码的流程如图2 所示。译码则是按照编码的逆过程编写代码，由于篇幅有限，此处不再赘述。

图2 应答器报文编码流程

2.2 编码算法优化软件设计

在FFFIS 编码标准的基础上对报文编码算法进行优化设计，采用Visual Studio 2013 软件，流程如图3 所示。控制位（Cb）固定为001，在选取加扰位时，需达到以下要求：10 位数的转化表转化为11 位数，11 位数的转化表高8 位为Sb，低3 位为Cb；12 位的加扰位分为高8 位和低4 位，低4 位和额外整形位组成10 位数据的数组，整形数据83组10 位一组的数据转成83 组11 位的数据，能够自动满足字母表转换条件[10]。优化后的FFFIS 编码算法可以改进加扰位的选择，在编码各环节中进行字母表条件和整形约束条件检查，减少了无效报文的生成，进一步提高了编码效率。

图3 报文优化编码流程

2.2.1 加扰处理

加扰处理过程分为以下3 步。

（1）将830 bit 长报文statebit830[]用户数据从左到右分成83 组数据，并将83 组数据存到数组statebitmsg[][]。分组之后，对最高位的10 位数据即第83 组数据按照式（1）进行函数运算：

式中：Uk-1为经过分组之后的、函数运算之后的第83 组数据。

其他82 组数据不变，这样就得到了新的830位数据，并存储在msg1024bit 中。

（2）创建12 bit 加扰位数组scramblebit12，并将其转换成十进制存储在B 中。

（3）将得到的S 转化成32 bit 比特流，按照图4 所示方法，对用户数据通过线性反馈移位寄存器进行加扰。

图4 32 bit 线性反馈移位寄存器

加扰代码设计如下：

2.2.2 10 位数向11 位数的转换

经过2.2.1 小节算法预处理后，输出的分组结果与输入的分组结果一一对应。原始输入数据相邻的10 个比特数据分为一组，经过上述算法处理，输出的为相邻的11 个比特数据为一组，由此完成了10 位向11 位数据的转化。具体步骤如下：

（1）令变量sum=0；

（2）每10 个比特为一组的数据求和；

（3）令步骤（2）中的和转化为整数I；

（4）在转换表中，从0 开始查找第I 个数，令sum=0；

（5）重复步骤（2），第83 组数据分别计算完之后，则转换为11 bit 的分组。

2.2.3 计算校验位

通过以上步骤进行加扰变换后，从中选出额外整形Esb（Extra shaping bit，Esb），然后对候选报文进行确定，之后对校验位b84～b0进行公式计算。校验位的计算过程如下所示：

式中：f(x)，g(x)以及o(x)的多项式形式取决于报文的帧格式。长报文f(x)=fL(x)，g(x)=gL(x)，o(x)=oL(x)，以下是多项式的计算式：

通过程序编写设计可计算出f(x)，g(x)。f(x)定义为数组1，g(x)定义为数组2，CRC=f(x)·g(x)。

2.2.4 测试候选报文

通过以上几个步骤计算之后能够生成完整的候选报文。生成完整的候选报文之后，需满足以下4 个条件才能被应答器传输模块（Balise Transmission Module，BTM）接收。此时可以通过2种方法得到新的候选报文：第一种方法是改变额外整形位（Extra shaping bit，Esb），第二种方法是改变加扰位得到新的候选报文。对通过以上两种方法得到的候选报文进行条件判断，判断条件如下。

（1）字母表条件。在整个编码过程中，通过10 to 11 bit转换，用户数据从每组10位变为每组11位，得到的任意一个11 位字记为bi-1…bi-11，如果其中i是11 的整数倍，则判定为合法的字，字母表对于整个候选报文的所有组成部分均应满足。

（2）同步解析条件。同步解析条件是测试11位字组成的序列（bi-1…bi-11）…（bi-12…bi-22），当变量i不满足11 的整数倍，则整个序列中合法字的数目应该满足以下2 个条件：第一，若i+1、i-1 是11的倍数，长报文中m_CStiaojian2_flag 应小于等于2；第二，若i+1、i-1 不是11 的整数倍，长报文中m_CStiaojian2_flag 应小于等于10 且短报文满足小于等于6。以上2 个条件需要对整个候选报文进行测试，需整个报文全部满足。

（3）针对长报文的非周期条件。该条件仅只适用于长报文，目的是保证长报文不会被译成短帧格式，具体用于两个被34 位分开的11 位字序列之间的汉明距离的测试。对于满足任意一个是11 倍数的整数i，bi-1…bi-22和bi-341-1…bi-341-22的汉明距离应满足不小于3 的条件；对于每个k(k=+1，-1，+2，-2，+3，-3)，bi-341-k-1…bi-341-k-22和bi-1…bi-22之间的汉明距离必须满足不小于2 的条件。

（4）欠采样条件。欠采样情况的发生主要是由于硬件的缺陷，因此需要对候选报文进行逐一检测，确保通过欠采样变换后的码字与字母表条件冲突[1]。详细过程为，对候选报文每两位取一位进行采样，采样后候选报文变为bn-3，bn-4，…，bn-1，bn-3，…b2，b0，通过采样之后的新报文是循环码的另一个码字，通过欠采样判断候选报文是否满足条件。

3 测试验证

将通过Visual Studio 2013 软件设计的应答器报文编码软件安装在实验室中列控中心的工控机上，通过列控中心维护终端仿真界面，将应答器报文数据通过实际的LEU 设备发送给应答器。实验培训系统还包括联锁、CTC、临时限速服务器，将编写好的编码软件部署在列控中心工控机，培训系统的每一条用户报文的底层编码结果可视化界面如图5 所示。将用户报文经过编码算法生成1023位的报文，将底层编码完成的报文数据以4 个一组的报文输入格式发给应答器，基于对话框的报文发送输入格式界面如图5 所示。该界面是列控中心向LEU 传输数据的通信模块子界面，列控中心操作维护终端可以选择帧格式、波特率等参数内容，将编译好的长、短报文经过LEU 发给应答器。

图5 报文发送输入格式界面

FFFIS 测试规范存在18 条编码的合法测试报文和每条报文对应的译码报文，虽然报文经过译码后没有明确含义，但规范中的测试报文可对报文编译码过程进行检验[10]。经过所有示例测试报文验证，均与subset-085 的最终报文一致。此处随意选取规范中的一条长报文为例，分析编码软件的正确性。

表2 是规范定义的编码未加密报文，表3 是规范定义的编码加密后的报文。通过优化后的FFFIS编码算法设计的软件，对该用户报文进行编码加密，生成的用户报文即编码软件结果如图6 所示。

表2 未加扰的用户报文

表3 加扰后的测试报文

从图6 可以看出，当初始用户数据和规范定义一致，其输出结果同样也一致。通过此方法对规范定义的18 条测试报文进行逐一测试，每一条报文均通过测试。

图6 编码软件结果

4 报文编制培训应用

本文将基于FFFIS 编码的应答器报文生成优化软件应用在列控仿真教学培训系统中。本次设计的报文编码软件作为列控中心的一个子模块软件，配合已经搭建好的联锁仿真培训子系统、CTC仿真培训子系统、临时限速仿真培训子系统进行数据交互。依据计算机联锁、CTC 等系统数据和CTCS-3 级列控系统规范，对应答器组中不同应答器信息包进行编码解码。通过解码为简单明了的用户信息，可以帮助现场操作人员加深理解。现场人员按照线路数据要求，通过改变相应的数据信息，显示为可交互的人机界面信息，练习编制报文，模拟报文的发送和接收，将整个过程通过操作界面可视化。

报文解码时，通过BTM 将编码后的数据解码成十六进制的用户报文，再将用户报文最终解码成培训学习人员可以理解的报文信息及其相对应的含义，能够进一步加深操作人员的理解，仿真线路数据译码结果如图7 所示。

图7 报文的编译码数据测试结果

临时限速由调度所集中管理，通过CTC 经临时限速服务器（Temporary Speed Restriction Server，TSRS）发送到列控中心。列控中心收到临时限速命令后，对该命令进行可执行性验证，将验证后的结果向CTC 反馈，以此提醒值班员对该命令进行批准[11]。列车通过应答器时，由于应答器报文信息包种类较多，并不能一一进行测试分析，故本次研究仿真主要采用ETCS-2 临时限速信息包，列控中心根据进路信息和临时限速信息生成应答器传输报文。车载设备软件根据应答器传输模块BTM 译码，通过译码后，数据会传输给车载安全计算机。列车收到限速命令后限速曲线会产生相应的变化。

临时限速曲线实验室仿真结果如图8 所示。其中，X轴为追踪距离，Y轴为列车速度，当前阶段列车运行的允许速度为350 km·h-1。当追踪距离在10 000～12 000 m，允许速度由350 km·h-1逐渐下降到150 km·h-1，此刻执行第1 个临时限速命令。TSR 长度及列车车尾保持结束后，列车速度恢复到250 km·h-1。TSR2 为50 km·h-1、TSR3为200 km·h-1，限速执行过程同理，允许速度最后恢复到350 km·h-1。通过列控仿真测试系统完成了列控中心应答器临时限速信息包数据的组帧、编码、译码到最后的线路数据应用仿真研究。

图8 临时限速曲线实验室仿真结果

5 结语

本文基于既有的实验室列控仿真测试平台，验证了基于FFFIS 编码的应答器报文生成软件的可用性以及优化算法的正确性，设计了列控中心对临时限速与线路数据处理的应答器报文生成软件。培训学习人员可以通过用户界面了解应答器报文从编制到最终被车载BTM 译码接收的全过程。该列控仿真培训系统已经在中国铁路成都局集团有限公司、中国铁路青藏集团有限公司等部分段以及高校投入使用，便于铁路局新员工和在校大学生对不同种类的应答器报文信息包的应用、应答器的设置原则、应答器报文编制形成清晰的认识。经现场人员反馈，使用效果良好。