CBTC接口转换应用层设计与实现

2014-11-29李玉兰李开成李骁宇陈思捷刘木齐

铁路计算机应用 2014年9期

李玉兰，李开成，李骁宇，陈思捷，刘木齐

（1.北京交通大学电子信息工程学院，北京 100044；2.北京交通大学轨道交通运行控制系统国家工程研究中心，北京 100044）

随着城市轨道交通的发展，CBTC–基于通信的列车运行控制系统得到广泛应用。由于用于CBTC系统设备研发和生产的统一规范还有待完善，使得各个厂商生产的设备之间存在较大差别，很多不同厂商的设备之间往往不能直接进行通信。在实际应用中，对于具体线路所使用的相关设备通常来自于不同的厂商，同时在实验室进行仿真实验时，也希望利用不同厂商的设备搭建一套CBTC最小系统。然而采用直接修改厂商设备接口以使各设备之间接口匹配的方式开发难度大、工期长。因此，设计可以用于CBTC系统各关键设备之间接口协议转换的接口转换应用层系统非常有意义。

本设计采用C#做后台代码开发工具，结合具体线路中参与运行的设备数量多，设备之间交互信息量大的实际特点，实现一种高效、实时的CBTC系统各个设备之间接口协议转换的接口转换应用层系统。

1 北京地铁运营仿真实验室设备简介

CBTC系统是基于通信的列车运行控制系统。一个典型的CBTC系统包括：列车自动监督系统（ATS，Automatic Train Supervision）、数据库存储单元（DSU，Database Storage Unit）、区域控制器（ZC，Zone Controller）、计算机联锁CI，Computer Interlocking）、车载控制器（VOBC，Vehicle 0n Board Controller）和数据通信系统（DCS，Data Communication System），包括骨干网、网络交换机、无线接入点以及车载移动无线设备。

北京地铁运营仿真实验室是利用北京地铁亦庄线数据搭建的一套CBTC最小系统，系统关键设备信息交互图如图1所示。

图1 CBTC系统关键设备信息交互图

在搭建的最小系统中，既有真实设备，也有仿真设备。仿真设备和仿真设备、仿真设备和真实设备、真实设备和仿真设备之间均存在信息交互。根据搭建系统所选择厂商的设备特点，图1中用虚线连接的部分在系统中不能直接通信，实线连接的部分可以直接通信。

在一套CBTC系统中CI、ZC、ATS、VOBC这4个子系统之间均存在信息交互，而接口转换系统的作用即为保证各个子系统之间信息交互正常。

2 接口转换系统设计

为了使系统正常运行，必须使不能直接通信的设备接口相互匹配。采用增加中间层（接口转换系统层）的方式，不仅开发难度小、工期短，还可以提高系统的可扩展性和可维护性。因此接口转换系统的开发将为CBTC最小系统的搭建，提供切实可行的方案。

为了使整个CBTC系统具有良好的可扩展性和可维护性，系统内部所有交互的信息均通过接口转换系统进行分发和处理。本文主要论述与CBTC系统中存在信息交互的CI、ATS、ZC和VOBC这4个核心子系统之间的信息交互。

接口转换系统由消息收发模块和消息处理模块两个部分组成，即应用层和网络层两个部分。系统的整体结构如图2所示。

系统消息交互流程为：由消息发送方设备（如CI）对应的数据网络层设备（CI数据网络层）接收原始消息，并将接收到的消息送入应用层进行处理，应用层将处理后的消息发送给接收方对应的数据网络层（如ATS数据网络层），再由数据网络层设备发送给对应的接收设备。

采用此分布式结构，可以将消息的收发环节和处理环节分开，使得在调试和维护的过程中便于故障定位，提高系统可维护性。同时使接口转换系统不受外围设备数量和类型的影响。外围设备数量的增加，只是带来接口转换系统处理消息量的增加，而外围设备类型的增加，只需要在原有接口转换系统的基础上增加该设备类型对应的网络层设备和应用层处理子模块即可，提高了系统的可扩展性和实用性。

本文主要针对接口转换系统的应用层进行设计和实现，以下简称应用层。

图2 系统整体结构图

3 应用层系统设计

应用层采用C#做后台代码开发工具，和网络层之间采用TCP/UDP协议进行通信。应用层由消息接收模块、消息处理模块和消息发送模块组成。其系统工作流程如图3所示。

3.1 消息接收模块

消息接收模块采用TCP/UDP协议实时接收来自网络层的消息。可行的消息接收方案有两种。

（1）采用多线程技术

当有消息到达时立即接收并存储；没有消息到达时，应用层正常的对接收到的消息进行后续处理。

（2）采用单条消息处理机制

接收到一条消息时，立即对该条消息进行处理，并在将接收到的消息发送给网络层之后，再接收下一条消息。

采用多线程技术，易使系统陷入死循环，且在满足系统要求的前提下，处理机制比采用单条消息处理的机制复杂。所以在本设计中采用方案2的消息处理机制。

图3 系统工作流程图

单条消息处理机制的工作流程如图4所示。

图4 单条消息处理机制工作流程图

3.2 消息处理模块

消息处理模块根据要搭建的CBTC系统要求，将接收到的原始消息，按照一定的规则进行处理，使其能被该条消息的接收设备所识别，从而保证CBTC系统各个设备之间通信正常。

在一套完整的CBTC系统中，参与工作的子系统多，交互的消息量大，使得消息处理模块作为应用层系统的核心模块，必须具备合理的消息处理机制，以快速、准确的对消息进行处理，同时还应具备一定的通用性和可扩展性，便于系统升级和后期维护。

同种类型的仿真设备和真实设备在与其它设备进行信息交互时，消息的内容和格式可能有所不同，从而需要应用层设备对其采用不同的处理机制。如ATS设备和仿真CI之间可以直接通信，而和真实CI之间不可以直接通信。所以对于消息处理模块，在对接收到的原始消息进行处理时，需要同时考虑消息方向，和与该条消息相关的发送设备和接收设备是仿真设备还是真实设备，从而选择正确的消息处理机制。

为了使消息处理模块满足性能要求，同时能有效地根据消息特征选择处理机制，将消息处理模块分为消息分类子模块、ATS_CI消息处理子模块、ATS_VOBC消息处理子模块、ATS_ZC消息处理子模块、CI_ZC消息处理子模块、CI_VOBC消息处理子模块、ZC_VOBC消息处理子模块、CI_CI消息处理子模块8个子模块。

在消息分类子模块中，首先根据消息的发送方设备和接收方设备类型，选择正确的处理机制，确定消息被送往的子模块。若消息由ATS发往CI，则该条消息将被送到ATS_CI消息处理子模块中进一步处理。

在消息处理子模块中完成对消息的解包、处理、组包操作，完成协议转换。

将消息处理模块进行子模块划分，应用层系统在数据处理的过程中即可以根据消息的来源和消息的去向灵活选择用于对消息进行处理的模块和处理方式。同时，当外部设备类型和数量增加时，只需要增加相应的消息处理子模块即可。

3.3 消息发送模块

消息发送模块采用TCP/UDP协议将转换完成后的消息发送给网络层，即系统根据消息的方向，从配置文件中找到网络层设备所在的IP和端口，并将转换完成后的消息利用TCP/UDP协议发往该端口，完成消息的发送。

4 应用层系统测试

在北京地铁运营仿真实验室平台的基础上，结合接口转换器应用层和网络层，对应用层系统的性能进行测试。

应用层系统测试指标主要有丢包率、误组包率和时延。根据搭建的最小系统的要求，应用层系统应满足的性能指标如表1所示。

表1 系统性能指标

其中亦庄线CBTC仿真实验室系统各设备周期如表2所示。

表2 亦庄线CBTC仿真实验室系统设备周期

在测试过程中系统各设备之间信息交互正常，各个设备均处于正常工作状态。统计各设备之间信息交互50 000次所得的丢包率、误组包率和时延测试结果如表3所示，时延测试柱状图如图5所示。

从系统测试的统计结果可以看出，接口转换应用层系统的最大丢包率为0.06‰（不包含由网络本身引起的丢包），即50 000条消息中，有3条消息被丢包，满足系统性能要求。误组包率为0。延时时间和消息包的长度，处理过程的复杂度以及处理CPU时间等均有关，从测试结果可以看出，系统最大时延出现在CI->ATS的过程中，这是由于在一条由CI->ATS的消息中，所包含的数据量最多，处理过程也最复杂。而对于ZC->ATS、VOBC->ZC、ZC->VOBC等过程，数据量小，数据量变化不大，也基本不需要处理，所以时延最小，且时延最大值和平均值相等。应用层时延满足系统性能需求。从系统的测试结果可以说明接口转换应用层系统满足设计要求。