城市轨道交通CBTC智能故障分析系统设计

白广争 ，冯浩楠 ，滕 达 ，崔亦博 ，李 亮 ，郜洪民

（1.中国铁道科学研究院集团有限公司 通信信号研究所，北京 100081；2.中国铁道科学研究院集团有限公司 国家铁路智能运输系统工程技术研究中心，北京 100081)

0 引言

随着我国城市轨道交通基于通信的列车控制系 统(Communication Based Train Control System，CBTC)不断应用，该系统的国产化技术方案越来越成熟。CBTC系统由联锁子系统(CI)、列车调度监督子系统(ATS)、车载控制子系统(VOBC)、区域控制子系统(ZC)和数据通信子系统(DCS)等构成[1-2]。各子系统之间实时进行多种控制信息与采集信息的交互，子系统内部完成自身逻辑功能运算。而在CBTC系统实际现场应用前，需要进行全面的功能、数据、接口的测试验证，包括系统是否满足需求，是否存在安全隐患等。若在同一时期内存在多条轨道交通线路面临开通需求时，则项目中测试工作繁重，压力巨大。为了提高测试效率，加快投产，同时保证测试质量，研发一套能够对测试过程中的问题进行快速智能故障分析定位的系统具有十分重要的意义。

陈静梅[3]根据日志的时间特征、种类特征、严重等级、时空特征等方面分析了在城市轨道交通现场运营情况下，对信号设备进行智能诊断的可行性，并系统地构建了信号智能化维护模型。崔亦博等[4]设计了城市轨道交通 CBTC 系统仿真实验室的建设方案，为CBTC系统的室内测试环境奠定了基础。张娟娟等[5]在分析CBTC车载子系统在线故障诊断系统功能需求的基础上，设计了系统架构，从而实现对车载日志的快速获取及智能分析。孙晓光等[6]研发的CBTC系统测试环境对各接口之间维护数据进行监测，通过数据监测，为测试提供了除实物设备动作以外的观测点，然而该系统在故障的诊断处理方面功能偏弱。李叶等[7]设计的地铁信号系统室内集成仿真测试平台(FIVP)，引入了点对点的自动化测试功能，实现ZC-CI，VOBC-CI等接口测试在室内测试平台上自动化执行，大大节省了测试时间，同样该系统在故障分析诊断方面并未做深入的研究。

综上分析，对于城市轨道交通CBTC系统室内测试阶段的故障定位自动分析水平还有待深入研究。城市轨道交通CBTC系统的各子系统均具有数据记录功能，用于故障后的分析和定位，然而这些信息主要是基于本子系统的接口及逻辑处理给出，具有片面性，对于寻找故障的根源往往仅起到导向作用，仍需要人工参与才能完成系统故障的定位。若将各个子系统所维护的通信数据信息进行整合，模拟人的故障判断追踪过程，并固化为逻辑判断模块，实现故障的自动追踪定位，这对于提高故障检测的自动化和智能化水平大有裨益。

1 城市轨道交通CBTC智能故障分析系统设计

1.1 系统架构设计

在不影响城市轨道交通CBTC系统通信网络的情况下，城市轨道交通CBTC智能故障分析系统(以下简称“智能故障分析系统”)完成数据的采集与分析。在架构设计方面，利用交换机级联状态下的端口镜像技术，实现对CBTC系统接口数据的获取。利用VLAN划分技术实现不同内网数据的隔离。智能故障分析系统硬件框架图如图1所示。根据图1，智能故障分析系统利用抓包交换机对骨干网交换机和子系统内网交换机内的数据进行镜像获取，不仅能够实现对CBTC系统骨干网数据监测，同时也能够对各子系统的内网数据进行监测，从而获得较全面的数据，为故障分析与识别奠定基础。

图1 智能故障分析系统硬件框架图Fig.1 Hardware framework of intelligent fault analysis system

集群环境下智能故障分析系统网络拓扑结构图如图2所示，其中，swi表示第i个交换机。集群环境下CBTC系统的搭建原理如下。①CBTC各子系统，包括列车调度监督子系统(ATS)、联锁子系统(CI)、区域控制子系统(ZC)、车载VOBC和DCS分布在多台集群式管理服务器上，服务器之间数据通信采用3层交换机统一管理，如图2中sw1和sw2所示，2台交换机分别负责CBTC系统的a网和b网数据交互。②在集群服务器内部，通过创建虚拟交换机及虚拟服务器，搭建CBTC系统，并对虚拟交换机划分VLAN，实现不同子网的有效隔离；外部交换机与服务器，如sw1，sw2，sw3，sw4与服务器之间通过Trunk方式配置连接，从而实现不同VLAN之间数据利用同一链路进行跨交换机交互。③集群服务器与磁盘阵列之间通过光纤交换机实现数据交互，如图2中光纤交换机FC-sw7所示。sw3，sw4主要负责外部接口，与外部实物设备进行连接，并分别通过sw1，sw2交换机与集群服务器内虚拟系统进行数据交互。

在以上搭建的CBTC系统基础上，利用sw5，sw6作为数据监测交换机，分别负责监测网A和监测网B的数据：一方面通过镜像sw1和sw2内传输的数据，可获得CBTC系统a网和b网服务器之间的交互信息以及外部设备与集群服务器之间的交互信息；另一方面，利用虚拟交换机链路镜像技术将同一台服务器内部各系统之间的交互数据上传至实体交换机sw5，sw6，从而实现服务器内部数据的获取。图2中G0/0/1，G0/0/24分别表示交换机的1号和24号端口，作为交换机级联状态下端口镜像的源端口和目的端口。例如，sw1的G0/0/24口即为sw1进行端口镜像的目的端口，同时该口级联sw5的G0/0/24口，作为sw5中G0/0/1口的源端口，sw5的G0/0/1口为目的端口，具体端口选择可根据项目实际情况确定。

图2 集群环境下智能故障分析系统网络拓扑结构图Fig.2 Network topology of intelligent fault analysis system in cluster environment

1.2 实现功能及软件结构设计

智能故障分析系统软件主要完成对CBTC系统中通信数据的监测获取、数据解析与存储、故障的智能分析、界面显示及报警提示等功能。根据功能，软件结构设计如图3所示。

图3 软件结构设计图Fig.3 Software structure design

根据图3，智能故障分析系统的工作流程如下。①利用交换机的端口镜像技术获取CBTC系统网络中的通信数据，这些数据分为骨干网数据和子系统内网数据2类。其中骨干网数据主要包括VOBC与ZC，ZC与CBI，VOBC与CBI，以及VOBC与ATS之间的通信数据，这些数据囊括了CBTC系统大部分的接口测试对象；子系统内网数据主要指各子系统内部逻辑分析单元(LP)与维护终端(MT)之间交互的报警信息。②对这2类数据分别进行处理。对于骨干网数据，通过将通信协议转换为xml配置文件的方式，编制程序，进行数据包的自动解包，并根据需要将相关信息进行界面显示，以便于人对系统的当前运行状态进行更直观的了解[8]，另外，根据获得的实时骨干网数据，可用于判断CBTC各子系统之间的实时通断状态，给出图形化的报警显示；对于子系统内网数据，利用报警信息，结合对应子系统定义的报警码，以及当前骨干网内的信息，进行故障的智能分析。

2 智能故障分析系统关键模块设计

2.1 故障识别方案设计

故障识别可分为查询式故障报警和主动式故障报警2种方式处理。

（1）查询式故障报警是指测试员通过对现在的运行状态进行提问，从而查找出潜在的故障并给出报警的方式。查询式故障报警的总体分析思路为：针对所提问题，首先考虑最直接的影响因素，并采用二分法的思想，逐层排除推进，缩小问题范围，最终定位至某个模块或者某条报文。报警的精确程度根据不同的故障类型，可以分为报文级故障或者字段级故障等。例如，非CTC列车在线路中运行时，不能升级为CTC等级，则测试员通过向系统提问，由分析系统自动查找列车不能升级的原因并给出相应的提示，从而定位潜在的故障。

以列车不升级CTC等级为例，描述查询式故障报警的设计原理。通过检查当前时刻所有与列车升级相关的数据包字段，设计逻辑分析模块，得出存在的故障根源。列车不升级CTC等级故障检查项如表1所示，列车不升级CTC等级的报警分析示意图如图4所示。

图4 列车不升级CTC等级的报警分析示意图Fig.4 Alarm analysis for the train not upgrading CTC level

表1 列车不升级CTC等级故障检查项Tab.1 Failure check items for the train not upgrading CTC level

（2）主动式故障报警是指系统在正常运行过程中，出现了非预期的现象，而主动给出提示的故障报警方式。例如，CTC列车在正常运行过程中故障降级，智能故障分析系统能够主动查找导致降级的根源并给出报警，从而提高测试效率。主动式故障报警是通过网络抓包，并根据通信协议解析，获得各子系统逻辑部所产生的故障码信息，将这些故障码汇总后，结合骨干网内获得的部分信息作为辅助条件，通过设计故障模式匹配算法，查找预先定义的故障标签库来完成故障定位，并给出报警或提示信息。其中，故障标签由经验丰富的测试工程师或专家根据系统需求定义，提取共性，并制定统一的规则来完成。

2.2 故障标签库设计

2.2.1 故障标签与子系统报警码定义

故障标签是指根据测试经验，结合各子系统的报警码，对一些常见的故障，分析故障的标志属性，从而形成的一条用于判断该故障原因的规则。故障标签定义示意图如图5所示，故障标签由平台故障码和针对各子系统定义的报警码共同构成。在制定标签的过程中，模拟人对故障的分析判断过程，提取针对确定故障的标志性因素。将多个故障分别定义故障标签，并将这些标签汇总，最终形成故障标签库。

图5 故障标签定义示意图Fig.5 Fault tag definition

在进行实时数据分析时，若被分析的数据满足故障标签库中某个故障标签所定义的属性，即可判定发生了该故障。故障标签是对人的判断意识进行固化模拟，故障标签库的构建也是一个需要不断完善深入的过程。

各子系统的报警码定义格式根据子系统的具体情况确定。例如，ZC子系统报警码由系统自定义的模块号和报警号共同组成；车载子系统报警码则根据具体的故障原因，选择所需检查的字段定义组成；联锁子系统报警码也根据具体的报警类型，选择相关字段来定义报警号。

2.2.2 故障标签库的构建

在构建故障标签库时，按照城市轨道交通CBTC系统各子系统构成，ZC，VOBC，CI，ATS均存在多个故障码。若对这些故障码进行任意组合，则可能出现组合爆炸的现象，但实际上针对某一特定的故障，其故障报警码组合是确定的，即并非任意的故障码组合均具有测试分析意义。为此，针对各子系统的故障码进行分析分类，这些故障码可分为：子系统自身产生的应用逻辑故障码、程序执行过程错误故障码、提示信息类故障码。其中，程序执行过程错误故障码、提示信息类故障码对于集成测试均不具有分析意义。进行系统级的故障定位分析应主要针对应用逻辑故障码展开。根据这一思想，故障标签库构建示意如表2所示。

如表2中，对于000002故障，仅根据各子系统的故障码无法精确定位问题的根源，还需要额外检查一些辅助信息，以实现故障的更精确定位。由此，智能故障分析系统不仅完成将各子系统的报警码进行汇总分析的功能，而且在这些信息不足以定位故障的情况下，还能进一步收集其他相关接口信息进行更准确的故障定位，这些接口信息主要指骨干网内获取的相关数据。

表2 故障标签库构建示意Tab.2 Construction of fault tag library

对于辅助收集的接口故障信息，可分为针对单条通信数据的故障检测和多条通信数据的联合故障检测。单条通信数据监测是指对体现某些故障信息的关键字段进行实时检查，判断故障原因，再结合各子系统的故障码，最终给出精确的故障定位。多条数据的联合故障检测主要针对一些具有时序的通信数据包的故障分析。例如，RSSP-II安全协议的AU1，AU2和AU3通信序列故障检查；应用层时间戳的故障检查；VOBC与ZC的通信建立过程合法性检查；自动驾驶模式列车超速紧急制动检查；故障降级检查等。

2.3 主动式故障识别处理模块设计

通过对各子系统数据流分析和故障标签的定义，为故障智能识别奠定了基础，进一步设计故障识别逻辑判断程序。主动式故障识别处理流程如图6所示。①利用抓包模块获得原始数据，结合通信协议文件，解析得到各子系统的报警信息；②读取各子系统对应定义的报警码库，通过调用报警码判断模块及存储模块，完成数据的初步加工处理；③加载预先建立的故障标签库，结合报警码判断模块的处理结果，由故障码逻辑判断模块最终确定当前系统的故障码，得出系统故障原因；④利用存储模块将故障码存入数据库，以备历史信息的查询和统计，同时将该故障码对应的故障报警文本提示进行界面显示。

图6 主动式故障识别处理流程Fig.6 Active fault identification and processing

故障码逻辑判断模块是主动式故障识别处理的核心，该模块通过设计实时故障模式匹配算法完成。在算法设计过程中，需要考虑不同子系统之间通信接口数据的同步性、系统之间通信周期设置，以及系统对不同故障的响应时间等因素，制定模式匹配规则，从而既要保证故障定位识别的实时性，又要保证故障识别的准确性，避免误报漏报问题。

3 结束语

智能故障分析系统的研发，能够使测试人员更加直观地了解CBTC系统的运行状态，更快地发现CBTC系统中存在的缺陷，提高系统的故障定位能力，避免通过人工逐帧报文比对来定位故障，减少分析时间，降低测试人员的劳动强度。同时由于逻辑判断功能和故障标签库的建立过程中均融合了具有丰富经验的测试人员以及行业专家的智慧，能够适当降低对测试人员的自身素质要求。在后续的研究中，将重点针对故障标签库的扩充以及故障诊断智能算法的优化设计方面进行展开，从而进一步提升故障分析系统的智能化水平。