CN109873725A - 一种铁路信号tdcs/ctc系统防止数据网络风暴的防护方法 - Google Patents

Abstract

本发明公开了一种铁路信号TDCS/CTC系统防止数据网络风暴的防护方法，该方法可实现对铁路信号TDCS/CTC系统复杂组网下，在错误的软件逻辑连接、异常的数据配置等情况时，通过软件逻辑防护，防止发生数据环回网络风暴，从而不影响TDCS/CTC系统整体数据传输可用性，并能及时对外告警，通知维护人员进行分析处理。

Description

一种铁路信号TDCS/CTC系统防止数据网络风暴的防护方法

技术领域

本发明涉及铁道科学技术领域，尤其涉及一种铁路信号TDCS/CTC系统防止数据网络风暴的防护方法。

背景技术

TDCS/CTC系统目前广泛应用于所有的铁路局集团公司，并在各个地方铁路亦有使用。TDCS系统主要实现对列车运行的监督，辅助行车调度人员对全线列车进行调度指挥；CTC系统则能够实现列车运行的集中控制、安全卡控、自动排路等功能；TDCS/CTC系统在提高铁路交通运输效率和保障运行安全方面起到了非常重要的作用。

在每个铁路局集团公司中，随着十几年的逐步建设、运营开通，TDCS/CTC系统网络结构和逻辑结构日趋复杂。铁路局一般会区分普速线路、客专高铁线路，从而对应普速线路TDCS网络(普速机房)、客专高铁CTC网络(高铁机房)，两个网络通常分别组网，再设立专门的接口网络设备进行通信。

既有TDCS/CTC系统随着十几年的演进，软件的总体逻辑结构变得越来越庞大。从最初简单的普速TDCS2.0、客专CTC2.0结构，逐渐改造升级。最初，TDCS/CTC系统的逻辑结构一般如图1所示。伴随新线路的开通，大量新的需求被提出，针对行车指挥，列车安全卡控、防错办、智能调整等功能得已实现，TDCS3.0、CTC3.0开始上线并被广泛应用，大大提高了运输指挥效率，间但系统间的网状交叉互连降低了整体软件的健壮性，部分现场逻辑结构所图2所示。随着高铁CTC3.0的安全控制、进路防护等功能日趋完善，铁路局运输组织人员希望在普速线路车站设置CTC3.0系统，但是由于线路设计、资金配比等问题，CTC3.0系统在普速线路车站使用时，经常会出现“插花式”设置，即一条线路中，有针对性的选择几个大站，升级为CTC3.0，其他车站维持既有TDCS2.0不进行改造。现场可能有部分逻辑结构如图3所示。

按照既有的调度指挥业务需要，调度台之间、车站与调度台之间、多个车站之间均存在业务数据通信；同时按照规定，中心调度台能够监控本调度区段所有的车站站场显示，且会基于本线路再外扩几个相邻的车站；车站之间同样会互相复视，且也会根据现场需求额外复视，比如车站A，一般需要复视车站B、车次C、车站D等多个车站的站场相关信息等。在TDCS/CTC系统软件层面，站场表示、车次显示、逻辑显示、列车报点等很多信息，对外输出时，是以广播方式发送。

然而，在TDCS/CTC各个版本系统并行融合运行时，系统内各个软件之间的逻辑结构耦合过紧，存在逻辑上成环的现象。信息广播与逻辑成环，这两个互相对立的条件，导致现场施工时需非常谨慎小心，需要根据线路需求，制作详细的数据配置文件，针对车站站码、调度区段编码、所需要的信息种类，制定严格的过滤规则和详细的转发策略。一旦数据配置错误，就可能导致信息成环，造成网络风暴、信息阻塞，从而影响调度指挥系统的使用。此外，随着CTC3.0/TDCS3.0“插花式”升级实施，工程实施时相关的数据配置更加繁杂易出错。

另一方面，在实际使用中，TDCS/CTC(2.0/3.0)各自有各自的数据通信协议。各个制式的软件，在内部严格按照各自数据通信协议所规定的帧格式或信息包格式，进行接收、发送、处理数据。

然而，TDCS2.0系统为约2000年左右开始在铁路局中部署开通的系统，TDCS2.0使用的数据通信协议帧格式、信息内容，与后来的CTC3.0、TDCS3.0兼容性不够，有较大的差异。因此在TDCS2.0与其他制式、其他版本软件信息交互时，需要接口通信服务器进行数据协议格式的转换。此外，TDCS3.0与CTC2.0/CTC3.0的通信协议层面差异不大，但随着CTC新功能的开发实现，增加了业务信息种类、扩充了部分信息的内容，传输的信息量也存在部分差异。在不同版本、制式的系统交互时，需要进行信息的过滤及检查。

发明内容

本发明的目的是提供一种铁路信号TDCS/CTC系统防止数据网络风暴的防护方法，可以防止发生数据环回网络风暴，从而不影响TDCS/CTC系统整体数据传输可用性。

本发明的目的是通过以下技术方案实现的：

一种铁路信号TDCS/CTC系统防止数据网络风暴的防护方法，包括，如下两个维度并行解决方案：

数据通信协议层面：在同一个制式系统下，为每一应用数据包增加跳点TTL字段，应用终端发出应用数据包时，相应的跳点TTL初始值为0；每一通信类服务器接收到应用数据包时先检查相应的跳点TTL值，若未超过设定的阈值T_max，则将相应跳点TTL值加1，再进行转发处理；若超过设定的阈值T_max，则将相应的应用数据包抛弃，并进行报警；

软件数据处理层面：多个制式融合的逻辑结构下，接收方维护一个信息校验单元的滑动窗口缓存，对于接收到的每一应用数据包均提取特定的字段构成信息校验块，并检查滑动窗口缓存中是否存在相同的信息校验单元，若有，则信息校验单元的计数加1，若没有，则生成相应的信息校验单元；当某一信息校验单元的计数小于设定的阈值N_count时，对应的应用数据包为合法数据，否则，视为重复数据，抛弃不处理，并择机对外报警。

由上述本发明提供的技术方案可以看出，可实现对铁路信号TDCS/CTC系统复杂组网下，在错误的软件逻辑连接、异常的数据配置等情况时，通过软件逻辑防护，防止发生数据环回网络风暴，从而不影响TDCS/CTC系统整体数据传输可用性，并能及时对外告警，通知维护人员进行分析处理。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他附图。

图1为本发明背景技术提供的简单的TDCS/CTC逻辑结构图；

图2为本发明背景技术提供的多制式的TDCS/CTC逻辑结构图

图3为本发明背景技术提供的多制式、多版本的TDCS/CTC逻辑结构图

图4为本发明实施例提供的一种铁路信号TDCS/CTC系统防止数据网络风暴的防护方法的流程图；

图5为本发明实施例提供的软件数据处理层面的原理图；

图6为本发明实施例提供的滑动窗口缓存轮询检查示意图。

具体实施方式

下面结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明的保护范围。

为了解决现有技术存在的问题，本发明实施例提供一种铁路信号TDCS/CTC系统防止数据网络风暴的防护方法，即使软件逻辑成环、数据配置错误，导致了数据环回，软件依据能够正确的防护、过滤，防止出现网络风暴，不影响既有业务传输，并及时向电务维修人员报警。如图4所示，主要包括两个维度并行解决方案：

一、数据通信协议层面。

在同一个制式系统下，为每一应用数据包增加跳点TTL字段，应用终端发出应用数据包时，相应的跳点TTL初始值为0；每一通信类服务器接收到应用数据包时先检查相应的跳点TTL值，若未超过设定的阈值T_max，则将相应跳点TTL值加1，再进行转发处理；若超过设定的阈值T_max，则将相应的应用数据包抛弃，并进行报警。

所述同一个制式系统包括：独立的TDCS系统或者独立的CTC系统；由于现场使用的TDCS的数据通信协议(数据通信规程)与CTC的数据通信规程存在差异，为此在各自制式系统内部进行第一步解决。

所增加的跳点TTL(Time To Live)字段(1个字节)，用于标识应用数据途径的内部通信服务类服务器的个数。所述通信服务类服务器可包括：应用服务器、前置通信服务器、车站通信机、邻站通信机等。

示例性的，根据TDCS、CTC的逻辑结构，T_max可设置为12-15。

本发明实施例中，通信类软件递增及校验信息中的跳点TTL，能够在一个独立制式范围内，有效地避免逻辑成环、信息风暴，比如单独的TDCS2.0、单独的TDCS3.0、单独的CTC2.0/3.0范围。

二、软件数据处理层面。

数据通信协议层面引入了TTL值，但是，TTL值的计算，只适合统一制式的系统内部使用，一旦在TDCS与CTC两个系统、跨版本之间传输时，由于通信协议、逻辑结构等不同，双方的TTL值无法互传，会被接口通信服务器重置。

另外，数据通信协议的修改，需要长时间的逐步更新升级软件，部分旧版的软件无法大面积的更换。为此核心的软件逻辑层，尤其是各个接口软件，需提前对可能出现的数据风暴进行防范。

本发明实施例中，无论TDCS(2.0/3.0)还是CTC(2.0/3.0)，核心的服务器软件在各自本范围传输数据时，以接收方的角度增加过滤防护算法，接收方对每一条通道接收到的数据，进行独立检查。

主要原理如图5所示，主要如下：多个制式融合的逻辑结构下，接收方维护一个信息校验单元(Data Check Unit)的滑动窗口缓存，对于接收到的每一应用数据包均提取特定的字段构成信息校验块(Data Check Block)，并检查滑动窗口缓存中是否存在相同的信息校验单元，若有，则信息校验单元的计数加1，若没有，则生成相应的信息校验单元；当某一信息校验单元的计数小于设定的阈值N_count时，对应的应用数据包为合法数据，可继续按照正常逻辑处理，否则，视为重复数据，抛弃不处理，并择机对外报警，提醒及时人工介入处理。

本发明实施例中，构成信息校验块的特定字段至少包括：信息源、信息目的、信息类型、信息长度、以及部分关键信息内容的MD5值。提取这部分字段，TDCS/CTC既能唯一确定一包信息，同时也能大幅度降低遍历匹配时的运算耗时。

本发明实施例中，所述接收方维护一个信息校验单元的滑动窗口缓存，每个T_cache秒，滑动窗口缓存整体向前滑动一次，清除旧窗口中的信息校验单元缓存；所述T_cache为缓存时间阈值。如图6所示，为滑动窗口缓存轮询检查过程，根据设定的阈值定期删除信息校验单元。

本发明实施例中，所述滑动窗口缓存中包括：若干信息校验单元、以及相应信息校验单元的初次创建时刻与接收计数。

示例性的，鉴于TDCS/CTC系统的信息一般为触发式、定时式两种方式工作，其中触发式是在现场状态有变化时，采集设备通过采集、或者其他外部系统主动发送，现场采样设备周期一般为200毫秒至500毫秒。定时式是指系统软件在逻辑状态没有改变时，定时对外发送，一般周期为5秒至15秒，为此T_cache可设定为5-15秒；

示例性的，分析TDCS/CTC业务数据流的频度，N_count阈值可设置为10-30，即相同的一包信息，在T_cache时间内，最多只能在同一个通信服务类软件中，转发处理N_count次。

本发明实施例上述方案主要获得了如下有益效果：

1)针对当前铁路信号TDCS/CTC系统既有的逻辑组网、数据传输方式，在数据配置错误、逻辑结构成环等情况下出现数据环回时，该方案能够防护网络风暴并及时对外报警通知，保证了TDCS/CTC系统的整体可用性。

2)涉及修改的软件少，对逻辑成环的某一个核心节点升级，即可避免网络风暴。

3)对既有老TDCS系统也完全兼容，由于当前铁路局大面积升级软件非常困难，该方案支持单点式、渐进式的无缝升级。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例可以通过软件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，上述实施例的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明披露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求书的保护范围为准。

Claims (5)

1.一种铁路信号TDCS/CTC系统防止数据网络风暴的防护方法，其特征在于，包括，如下两个维度并行解决方案：

数据通信协议层面：在同一个制式系统下，为每一应用数据包增加跳点TTL字段，应用终端发出应用数据包时，相应的跳点TTL初始值为0；每一通信类服务器接收到应用数据包时先检查相应的跳点TTL值，若未超过设定的阈值T_max，则将相应跳点TTL值加1，再进行转发处理；若超过设定的阈值T_max，则将相应的应用数据包抛弃，并进行报警；

软件数据处理层面：多个制式融合的逻辑结构下，接收方维护一个信息校验单元的滑动窗口缓存，对于接收到的每一应用数据包均提取特定的字段构成信息校验块，并检查滑动窗口缓存中是否存在相同的信息校验单元，若有，则信息校验单元的计数加1，若没有，则生成相应的信息校验单元；当某一信息校验单元的计数小于设定的阈值N_count时，对应的应用数据包为合法数据，否则，视为重复数据，抛弃不处理，并择机对外报警。

2.根据权利要求1所述的一种铁路信号TDCS/CTC系统防止数据网络风暴的防护方法，其特征在于，所述同一个制式系统包括：独立的TDCS系统或者独立的CTC系统；所增加的跳点TTL字段，用于标识应用数据途径的内部通信类服务器的个数。

3.根据权利要求1所述的一种铁路信号TDCS/CTC系统防止数据网络风暴的防护方法，其特征在于，构成信息校验块的特定字段至少包括：信息源、信息目的、信息类型、信息长度、以及部分关键信息内容的MD5值。

4.根据权利要求1所述的一种铁路信号TDCS/CTC系统防止数据网络风暴的防护方法，其特征在于，所述接收方维护一个信息校验单元的滑动窗口缓存，每个T_cache秒，滑动窗口缓存整体向前滑动一次，清除旧窗口中的信息校验单元缓存；所述T_cache为缓存时间阈值。

5.根据权利要求1或4所述的一种铁路信号TDCS/CTC系统防止数据网络风暴的防护方法，其特征在于，所述滑动窗口缓存中包括：若干信息校验单元、以及相应信息校验单元的初次创建时刻与接收计数。