CTC 与CTCS2 交互流程及实际问题分析

杜丽霞，曹 岩

(兰州交通大学 电子与信息工程学院，甘肃 兰州730070)

0 引 言

在客专铁路运营中，CTCS 系统实现对列车运行速度的控制，CTC 系统实现远程排路、设置、取消临时限速这样的工作模式，使列车在高速运行的同时，列车运行安全也有了保障。

1 CTC 与CTCS2 交互流程

通 过 CTC［1-4］与 技 术 咨 询 中 心(Technology Consultancy Center，TCC)的通信数据分析［5-7］可以看出，双方传输的“临时限速数据块”为核心内容。通过接口协议［8-9］，可以看出，CTC 向TCC 发送一条临时限速命令中，核心部分如下，如表1 所示。

表1 CTC 发送的核心数据

发往列控中心的一个完整的限速命令中，“限速命令号”、“执行标记”、“线路号”均是发令者(或车站执行者)较为容易理解，而“起点覆盖标志”、“终点覆盖标志”字段则需要CTC 进行计算，即CTC 需要对公里标进行归档，当限速区域超出该列控中心管辖范围时，CTC 需要增加左右覆盖标志，用以告知列控中心，这部分计算对CTC 来说较为复杂，若CTC 归档将此标志左右搞反后，则会造成列控中心限速区域出错。

下面举例说明CTC 的左右覆盖标志计算方式，一般而言车站列控中心的限速范围［10-15］如图1 所示。

图1 限速范围示意图

图1 中，B 站列控中心管辖范围为K603 +772-K654 +336 ，而C 站列控中心管辖范围为K619 +780-K679 +667，如果限速区域如上图所示，限速公里标为:K619 +100-K656 +600，此时CTC 需要对此限速公里标归档计算，输入的参数包括:线路号(下行线);起点里程标系符(K);起点公里标(619 +100);结束里程标系符(K);结束公里标(656 + 600);限速速度值(120 km/h)。

通过输入参数，需要计算该限速命令对每一个列控中心(B、C)的分解命令对应的覆盖标志。根据下行线，公里标范围为递增趋势，比较输入的开始和结束公里标，对比每个列控中心的管辖范围，计算如下。

发往B 站列控中心的限速数据需要为:开始公里标K619 +100，覆盖标志0，结束公里标K656 +600，覆盖标志01。

发往C 站列控中心的限速数据需要为:开始公里标K619 +100，覆盖标志2，结束公里标K656 +600，覆盖标志0。

计算流程大致如图2 所示。

图2 计算流程图

以上为简单的公里标覆盖标志说明，当一条线路存在多种里程标系时，计算尤为复杂。以成都局达成线实际为例，如图3 所示。

图3 成都局达成线公里标示意图

正常情况中，下行线路公里标均为由小至大，上行线路由大至小。但是在实际特殊的枢纽线路区、疏解线路区，就会存在不同的里程标系，比如上述成都局达成线中。其中K1 +809-K129 +521 的下行线为普通的“达成下行线路”，公里标由小至大，但在“石板滩”车站则存在里程标系切换点，为IIK 里程标系(成渝线里程标系)，范围为IIK18 +762-IIK12 +215，此里程标系虽然为下行线路，公里标却由大至小。同样，K129+476-K2 +143 里程为普通的“达成线上行线”里程标系，而从“龙潭寺”至“石板滩”段，公里标范围为IK0+210-IK6 +640，在“石板滩”存在里程切换点，IK 里程标系为“成渝疏解线”里程，虽然为上行线路，公里标却为递增。在下达限速时，整条线路从“遂宁”-“龙潭寺”为拉通线路，即允许下达“下行线”K128 +100-IIK13 +200 这样的临时限速命令。

通过上述实际应用，在复杂线路中，计算覆盖标志时需要将整个线路拉通，对不同的里程标系拉通计算转换［16］。

2 实际中覆盖标志出现的问题

通过上述描述，CTC 通过对限速公里标、每个列控管辖范围进行计算，得出对每个列控中心的左右覆盖标志。这意味着CTC 必须计算正确。也意味着CTC要配置整条线路的列控数据。实际的工程实施中，由于每条线路可能存在诸多特殊性，以及整条线路中，CTC 需要配置的列控数据相当庞大且繁杂，一旦配置错误，可能会导致计算错误。

下面以实际工程应用中出现的问题为例，主要分析覆盖标志单方面计算时出现的问题，最后给出对策。

2.1 试验出现问题

客运专线甬台温在线路拉通试验时，需要下达限速命令测试。试验的限速区段为上行线路K654 +300-K654 +400 区域。而此限速范围跨越了福鼎站和鳌江站的TCC 管辖范围边界，既然跨了2 个TCC 列控中心管辖范围，则CTC 向列控发送的限速命令具体数据中会有覆盖标志，而CTC 系统因为覆盖标志计算不正确，下达给列控中心后，列控中心将原信息反馈给CTC 并通知执行成功，CTC 系统内部界面显示的限速与实际列控执行的限速区域不一致。此时在CTC 终端中的界面显示表征找不到任何问题。限速初始示意图如图4 所示。

图4 测试限速示意图

在图4 中，黄色区域即为“预期限速区域”，公里标范围为K654 +300-K654 +400。通过上面，也知道初始的列控中心管辖范围为:福鼎站上行管辖范围为K654 + 336----K709 + 824;苍南站上行管辖范围为K619 + 780----K679 + 667;鳌江站上行管辖范围为K603 +772----K654 +336。

以上数据为每个列控中心的初始数据。此时CTC下达限速命令，输入的参数为:开始公里标K654 +400，结束公里标K654 +300，限速120 km/h。在实际应用中，部分列控中心可能需要归档，但是实际CTCS2中一般不需要CTC 对此公里标归档，为此本文对归档不作详细说明。通过上面的图示可以看出目标限速区域跨越了鳌江站TCC 的反响管辖边界和福鼎站TCC的正向管辖边界，而对苍南站TCC 而言，目标限速区域在苍南站TCC 的管辖范围之内。在当时试验时，CTC 系统经过计算后发给各个列控中心的限速命令数据核心部分如下。

福鼎站列控中心:开始公里标K654 +400，覆盖标志0，结束公里标K654 +300，覆盖标志2。

苍南站列控中心:开始公里标K654 +400，覆盖标志0，结束公里标K654 +300，覆盖标志0。

鳌江站列控中心:开始公里标K654 +400，覆盖标志1，结束公里标K654 +300，覆盖标志0。

根据上面的通信协议，覆盖标志位为1 时表示其对应公里标在该列控中心TCC 正向管辖范围之外，覆盖标志位为2 表示其对应公里标在该列控中心TCC的反向管辖范围之外。所以上述的核心数据部分有错误，正确的应该为:

福鼎站列控中心:开始公里标K654 +400，覆盖标志0，结束公里标K654 +300，覆盖标志1。

苍南站列控中心:开始公里标K654 +400，覆盖标志0，结束公里标K654 +300，覆盖标志0。

鳌江站列控中心:开始公里标K654 +400，覆盖标志2，结束公里标K654 +300，覆盖标志0。

在发生了错误数据之后，各个列控中心对接收到的限速命令中的公里标数据进行执行，执行结果如下:

福鼎站列控中心开始公里标K654 +400，覆盖标志0，结束公里标K654 +300，覆盖标志2 的命令执行如图5 所示。

福鼎站的开始公里标K654 +400 的覆盖标志为0，该福鼎站列控中心认为该公里标在其管辖范围之内(实际也的确在其管辖范围)。而结束公里标K654 +300 的覆盖标志为2，列控此时不校验该覆盖标志2 是否与结束公里标的方向一致，而直接认定反向覆盖，即列控中心直接对从公里标K654 +400 开始到反向(上行方向为正向)管辖范围边界的区域进行限速，如上图的黑色框部分即为实际执行限速。

福鼎站的正确公里标数据开始公里标K654 +400，覆盖标志0，结束公里标K654 +300，覆盖标志1，正确执行的限速图例应该如图6 所示。

苍南站收到的数据开始和结束公里标均没有覆盖标志，而且目标限速预期完全在苍南站的管辖范围之内，所以苍南站的实际执行区域与欲执行区间完全一致。即如图7 所示。

图5 福鼎实际示意图

图6 福鼎站正确图例

图7 苍南站执行限速图示

鳌江站列控中心对开始公里标K654 +400，覆盖标志1，结束公里标K654 +300，覆盖标志0 的限速命令执行如图8 所示。

这是因为鳌江站对接收的数据中，结束公里标K654 +300 的覆盖标志为0，列控认为其在鳌江列控中心的管辖范围之内(实际该公里标同样也的确在其管辖范围)。而开始公里标K654 +400 的覆盖标志为1，列控中心没有校验覆盖标志1 是否与开始公里标的方向一致，而直接对从正向管辖范围到结束公里标的K654 +300 的区域直接限速，如图8 所示。

而鳌江的正确公里标数据应该为开始公里标K654 +400，覆盖标志2，结束公里标K654 +300，覆盖标志0 ，对应的限速区域应该如图9 所示。

各个列控中心对各自接收到的限速执行成功后，将CTC 系统发送给TCC 的限速数据(起始公里标、结束公里标、覆盖标志)反馈给CTC，CTC 根据该执行范围计算在各个终端应该显示的限速黄色带区域。

图8 正确的示意图

图9 实际执行范围图

通过上图可以看出，CTC 端看不出任何问题，CTC从TCC 接收到的数据认为限速区域即为原预期要限速的区域，而3 站列控中心的限速区域却将限速执行范围远远扩大，将原只100 m 的限速范围，执行为限速了几十公里，同时由于3 个列控中心发送的限速范围不一致，向对应的应答器发送限速数据包内容不一致，导致机车紧急制动。

2.2 问题处理

实际中出现问题的原因即因为CTC 系统虽然给出了正确的公里标，但没有给出正确的公里标覆盖标志，而列控中心TCC 不校验公里标及覆盖标志，直接将CTC 系统计算的覆盖标志用来限速，导致了上述出现的问题，即列控实际限速与CTC 不一致。

CTC 系统这种计算错误经查即为工程数据的配置中出现错误，导致了系统计算出现问题。CTC 系统的覆盖标志的错误影响的是整个列控中心管辖的整条线路范围，而不仅仅是限速输入的目标限速区域，一旦出现错误，所有公里标覆盖跨越的TCC 的限速均会不正确执行，而非预期效果。

由于CTC 系统需要对整条线路的区间数据进行配置，数据量非常庞大，且没有自动工具，只能人工录入，可能导致配置错误。此类似问题在成都局的达成线CTC 中同样出现过，在其他铁路局中同样也出现过。为了防止这类问题的发生，CTC 系统必须配合列控，对所有的列控中心至少进行跨越管辖范围的限速测试，每个列控中心至少试验2 条限速，分别有一个公里标不在该列控的管辖范围之内。即对某列控中心A，2 条限速公里标起止应该测试。

(1)起始公里标在A 的管辖范围内，结束公里标在A 的正向管辖范围外。

(2)起始公里标在A 的管辖范围内，结束公里标在A 的反向管辖范围外。

3 结 语

上述的试验方案在新建线路时，可以有充裕的时间对列控中心及各种公里标进行测试试验，而在已经上线使用的线路中，尤其是在改造的车站中，施工时间点紧迫，没有充裕的时间进行测试，就会出现问题。成都局达成线在改造某一CTC 车站的列控中心时，由于只给了1 个小时的施工点，测试没有完全，仍然发生了类似上述的问题。要从根本上解决此类问题，分析后可以有如下方案:

CTC 系统在每一次改动后同列控配置对各种情况的限速进行完全遍历性测试试验，然后再上线使用，如果工程施工时间不够，则双方在试验环境中进行模拟测试。目前，由于铁路应用的特殊性，各个铁路局一直沿用此方案，由各个厂家负责对数据的完整测试。

［1］ DU Lixia，CAO Yan. Drug Utilization Knowledge Discovery Using Self-organizing Map and Rough Set Theory ［J］. Journal of Computational Information Systems，2008，4(2):553-558.

［2］ DU Lixia，CAO Yan. The application of A Markov Chain Model of Algorithmic Efficiency in termination time of TV shows［J］.Proceedings IEEE，2008(3):1580-1582.

［3］ ALSTOM. FSFB/2 Safety Protocol Requirements Specification［S］.1999，Version B.2.

［4］ CENELEC. EN 50129 Railway applications--- Communication，signalling and processingsystems ---Safety related electronic systems for signaling［S］.2003(2).

［5］ IEC 61850. Communication Networks and Systems in Substations［S］.2004.

［6］ 李长林，高 洁.Visual C + + 串口通信技术与典型实例［M］.北京:清华大学出版社，2006.

［7］ 科技运［2008］127 号. 中国列车控制系统CTCS 名词术语(V1.0)［M］.北京:中国铁道出版社，2008.

［8］ 科技运［2008］151 号. 客运专线列控系统临时限速技术规范(V1.0)［M］.北京:中国铁道出版社，2009.

［9］ 科技运［2004］15 号.分散自律调度集中(CTC)技术条件(暂行修订稿)［M］.北京:中国铁道出版社，2004.

［10］ 许 诚，王安平. 繁忙铁路干线调度集中调试开通方案的研究［J］.铁道通信信号，2007(6):56-60.

［11］ 张宏林.精通Visual C+ +串口通信技术与工程实践［M］.3 版.北京:人民邮电出版社，2008.

［12］ ALSTOM. FSFB/2 Safety Protocol Requirements Specification［S］.1999，Version B.2.

［13］ CENELEC. EN 50129 Railway applications --- Communication，signalling and processingsystems ---Safety related electronic systems for signaling［S］.2003(2).

［14］ ALSTOM. 000-801-S-01-SW001-B-002-088 FSFB/2 safety protocol requirements specification［S］.France:ALSTOM，2002.

［15］ 吴文麒. 国外铁路信号新技术［M］. 北京:中国铁道出版社，2000.

［16］ 岳朝鹏. 40.10_08.04.25_客专列控中心接口协议_V037［S］.2008.