CN109782733A - 一种互联互通cbtc***的交叉测试方法及平台 - Google Patents

Abstract

本发明实施例公开了一种互联互通CBTC***的交叉测试方法及平台，方法包括：构建互联互通CBTC***的交叉测试平台；判断当前情况是否满足测试入口条件；若满足测试入口条件，则通过所述交叉测试平台对所述互联互通CBTC***进行交叉测试；其中，所述交叉测试包括工程接口测试、功能确认测试和工程数据确认测试。本发明实施例通过互联互通CBTC***的交叉测试平台的搭建、室内交叉测试与管理以及现场测试调试与管理，能够有效的组织互联互通的验证，保障互联互通技术工程应用的顺利实施。

Description

一种互联互通CBTC***的交叉测试方法及平台

技术领域

本发明实施例涉及轨道交通技术领域，具体涉及一种互联互通CBTC***的交叉测试方法及平台。

背景技术

随着我国国民经济的快速发展，城镇化建设步伐的加快，城市交通拥堵和大中小城市与小城镇之间的交通连接问题已越来越成为各大城市在快速发展过程中迫切需要解决的问题。

加快发展轨道交通建设，不仅能够很好的解决广大人民群众关心的拥堵问题，满足老百姓出行方便的意愿，而且还能极大的带动轨道交通上下游产业链的发展，推动当地国民经济的快速发展。

早期我国城市轨道交通CBTC信号***主要依赖于进口，且客流需求不强烈，线路资源有限，从实际需求和技术实现等方面，都不具备实现互联互通CBTC信号***条件。随着城市轨道交通的发展，客流分布不均衡，资源共享率低，换乘压力增加等问题也暴露出来，因此对城市轨道交通CBTC***互联互通的呼声也越来越强烈。近几年国家对技术装备产业的发展进行了大力支持，国内路网已成规模，CBTC信号***的核心技术也已被国内部分顶尖的供货商掌握，已具备实现互联互通的实际需求和技术条件。

CBTC互联互通信号***技术复杂，我国要实现其自主化，需在核心技术、关键设备、***设计与集成、标准规范等方面持续攻关并取得实质性突破。重庆市轨道交通(集团)有限公司将重庆环线、4号线、5号线、十号线作为国家互联互通示范工程线，开启中国城市轨道交通的CBTC互联互通之路。为推动轨道交通行业和全自动运行***的长期健康发展，为轨道交通CBTC互联互通信号***建设和运营提供决策依据和指导，缺少相对于传统CBTC***的新增测试方法点。

发明内容

由于现有方法存在上述问题，本发明实施例提出一种互联互通CBTC***的交叉测试方法及平台。

第一方面，本发明实施例提出一种互联互通CBTC***的交叉测试方法，包括：

构建互联互通CBTC***的交叉测试平台；

判断当前情况是否满足测试入口条件；

若满足测试入口条件，则通过所述交叉测试平台对所述互联互通CBTC***进行交叉测试；

其中，所述交叉测试的类型包括互联互通接口测试阶段、互联互通功能确认测试阶段与互联互通工程数据确认阶段。

可选地，所述测试入口条件包括地面方入口条件、车载方入口条件、数据入口条件和涉及变更后的回归测试入口条件；

其中，所述地面方入口条件包括本线地面功能测试通过和本线线路数据测试通过；

所述车载方入口条件包括本线车载功能测试通过；

所述数据入口条件包括测试双方公有数据版本匹配一致；

所述涉及变更后的回归测试入口条件包括遵循变更控制管理。

可选地，所述判断当前情况是否满足测试入口条件之前，还包括：

对所述CBTC***的各组成部分进行厂家自测试。

可选地，所述若满足测试入口条件，则通过所述交叉测试平台对所述互联互通CBTC***进行交叉测试之后，还包括：

对所述CBTC***进行现场测试；

其中，所述现场测试包括单车测试和多车测试，所述多车测试包括正常运营追踪测试和追踪故障测试。

可选地，所述对所述互联互通CBTC***进行交叉测试的过程中，采用共线测试、跨线测试、多车测试或不涉及车载测试的方式；

其中，所述共线测试由共线车载方主导，所述跨线测试由即将进入的跨线线路地面方进行主导，所述多车测试或不涉及车载测试由地面方主导。

可选地，所述交叉测试的具体内容包括：交互接口测试、交互功能测试、多车专项测试、故障恢复测试、按照运营场景测试、运行指标测试和工程线路数据验证测试。

第二方面，本发明实施例还提出一种互联互通CBTC***的交叉测试平台，包括：车载设备层、车辆仿真层、轨旁设备仿真层、车站设备层和控制中心层；

所述控制中心层主要包括中心列车自动监控***ATS设备和数据服务单元DSU设备；

所述车站设备层主要包括区域控制器ZC设备、连锁CI设备；

所述轨旁设备仿真层用于模拟轨旁的信号设备，所述轨旁的信号设备包括道岔、应答器、计轴、信号机、地面电子单元LEU设备；

所述车辆仿真层用于驾驶台的仿真以及车辆动力学模型的仿真，包括驾驶台仿真器及动力学模型仿真器；

所述车载设备层包括四套真实车载控制器VOBC设备以及多媒体交互***MMI。

可选地，还包括：

信号红网和信号蓝网，所述信号红网和信号蓝网用于传输ZC\DSU\CI设备的信息；

ATS红网和ATS蓝网，所述ATS红网和ATS蓝网用于传输ATS信息；

仿真平台网，用于传输仿真软件交互信息；

维护网，作为预留的网络；

所述信号红网、信号蓝网、ATS红网、ATS蓝网、仿真平台网和维护网分别部署交换机，根据不同供应商的要求在交换机上进行配置，实现网络划分。

可选地，还包括：

ZC\ATS相关接口，所述ZC\ATS相关接口包括：VOBC与ZC/ATS接口、ZC-ZC接口和ATS-ATS接口；

CI接口，所述CI接口包括：与真实设备接口和与测试平台接口；

VOBC接口适配，用于实现各厂家VOBC信号的生成以及硬线接口的快速接入。

由上述技术方案可知，本发明实施例通过互联互通CBTC***的交叉测试平台的搭建、室内交叉测试与管理以及现场测试调试与管理，能够有效的组织互联互通的验证，保障互联互通技术工程应用的顺利实施。

附图说明

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

图1为本发明一实施例提供的一种互联互通CBTC***的交叉测试方法的流程示意图；

图2为本发明一实施例提供的CBTC***的交叉测试平台的结构示意图；

图3为本发明一实施例提供的车载设备层与接口适配层的架构示意图；

图4为本发明一实施例提供的调理插箱的结构示意图；

图5为本发明一实施例提供的总体设备连接的结构示意图；

图6为本发明一实施例提供的测试平台固定部署的结构示意图。

具体实施方式

下面结合附图，对本发明的具体实施方式作进一步描述。以下实施例仅用于更加清楚地说明本发明的技术方案，而不能以此来限制本发明的保护范围。

图1示出了本实施例提供的一种互联互通CBTC***的交叉测试方法的流程示意图，包括：

S101、构建互联互通CBTC***(基于通信的列车自动控制***)的交叉测试平台。

具体地，本实施例构建的互联互通CBTC***的交叉测试平台如图2所示，包括：车载设备层、车辆仿真层、轨旁设备仿真层、车站设备层和控制中心层。

所述控制中心层主要包括中心列车自动监控***ATS设备和数据服务单元DSU设备。

所述车站设备层主要包括区域控制器ZC设备、连锁CI设备。

所述轨旁设备仿真层用于模拟轨旁的信号设备，所述轨旁的信号设备包括道岔、应答器、计轴、信号机、地面电子单元LEU设备。

所述车辆仿真层用于驾驶台的仿真以及车辆动力学模型的仿真，包括驾驶台仿真器及动力学模型仿真器。

所述车载设备层包括四套真实车载控制器VOBC设备以及多媒体交互***MMI。

本实施例通过互联互通CBTC***的交叉测试平台的搭建、室内交叉测试与管理以及现场测试调试与管理，能够有效的组织互联互通的验证，保障互联互通技术工程应用的顺利实施。

进一步地，CBTC***的交叉测试平台还包括：

信号红网和信号蓝网，所述信号红网和信号蓝网用于传输ZC\DSU\CI设备的信息。

ATS红网和ATS蓝网，所述ATS红网和ATS蓝网用于传输ATS信息。

仿真平台网，用于传输仿真软件交互信息。

维护网，作为预留的网络。

所述信号红网、信号蓝网、ATS红网、ATS蓝网、仿真平台网和维护网分别部署交换机，根据不同供应商的要求在交换机上进行配置，实现网络划分。

ZC\ATS相关接口，所述ZC\ATS相关接口包括：VOBC与ZC/ATS接口、ZC-ZC接口和ATS-ATS接口。

CI接口，所述CI接口包括：与真实设备接口和与测试平台接口。

VOBC接口适配，用于实现各厂家VOBC信号的生成以及硬线接口的快速接入。

本实施例搭建的互联互通的交叉测试平台整体按照“硬件最小化，功能最大化”的最小***的思想，提取城市轨道交通列车运行控制***中的核心设备和典型设备作为最小***的雏形，选取功能和接口全覆盖的最小子集作为最小***的首选模型，采用功能接口全部预留和增量式的整体架构，按照车载设备层、车辆仿真层、轨旁设备仿真层、车站设备层、控制中心层构建仿真测试平台架构，模拟互联互通***各种运营场景，并满足互联互通运行控制测试大纲的验证测试。

控制中心层主要包括中心ATS设备、DSU设备等设备组成。

车站设备层主要包括ZC设备、CI设备。由于需要在实验室内搭建一个与现场实际车站架构一致的环境，因此在车载设备层需要各条线路的供应商分别提供一套真实ZC和真实CI设备,并各自提供两套单机ZC和单机CI来模拟邻站ZC和CI。

轨旁设备仿真层主要用于模拟轨旁的信号设备，如道岔、应答器、计轴、信号机、LEU等设备，其核心设备为轨旁仿真器。

车辆仿真层主要用于驾驶台的仿真以及车辆动力学模型的仿真，主要设备包括驾驶台仿真器及动力学模型仿真器。

车载设备层主要包括四套真实VOBC设备以及MMI等，分别由每条线路对应的供应商提供，以保证与现场实际设备的一致性。

为了各供应商设备接入方式达到统一，测试平台共构建六个网络，包括：

信号红网，信号蓝网，用于传输ZC\DSU\CI等设备的信息。

ATS红网，ATS蓝网，用于传输ATS信息。

仿真平台网，用于传输仿真软件交互信息。

维护网，预留。

六个网络分别部署交换机，可以根据不同供应商的要求在交换机上进行配置，达到网络划分的目的。

ZC\ATS相关接口包括：VOBC与ZC/ATS接口，ZC-ZC接口，ATS-ATS接口，按照互联互通形成的接口规范开发。网络接入方式采用现场实际网络架构，通过以太网进行通信收发。

CI接口分为两部分：

与真实设备接口，包括CI-VOBC接口、CI-CI接口，按照互联互通形成的接口规范开发。网络接入方式采用现场实际网络架构，通过以太网进行通信收发。

与测试平台接口，包括CI与仿真LEU接口、CI与仿真IO接口，均采用网络发送。

测试平台提供统一的硬件接口平台及接线盒，满足各厂家VOBC各信号的生成以及硬线接口的快速接入。车载设备层与接口适配层架构图如图3所示：

车载适配器是一个基于PC的成熟平台，适用于测量和自动化***。它提供了电源、冷却和通信总线来支持同一机箱内的多个仪器模块。

车载适配器提供了丰富的板卡可供选择，满足不同的适配需求，包括：

串口：串口卡(包括RS232/RS422/RS485)；

速度脉冲：信号发生器卡；

电流：模拟量采集卡；

网络：网卡；

操作***：实时操作***(PharLap ETS)或普通的WINDOWS操作***；

线缆接口：由于各厂商采用的接口不统一，平台统一配置调理插箱，如图4所示。各厂商在各公司内部完成配线，实验室只需要对接即可完成连接。

需要说明的是，一套车载适配器适配两个车载设备。

总体设备连接结构图如图5所示，包括了不同厂家的真实车载VOBC。互联互通测试平台可同时满足4个厂商的地面和车站设备的互联互通测试。举例来说，根据前期与各厂家的沟通，测试平台固定部署参见图6。

S102、判断当前情况是否满足测试入口条件。

其中，所述测试入口条件包括地面方入口条件、车载方入口条件、数据入口条件和涉及变更后的回归测试入口条件。

所述地面方入口条件包括本线地面功能测试通过和本线线路数据测试通过。

所述车载方入口条件包括本线车载功能测试通过。

所述数据入口条件包括测试双方公有数据版本匹配一致。

所述涉及变更后的回归测试入口条件包括遵循变更控制管理。

不同于传统CBTC测试，本实施例中涉及的厂家众多，测试组合也复杂。故要求进入测试的入口条件与传统CBTC测试相比严格且复杂。测试版本由于由各家发起，对于版本的有效配合控制也提出了新的要求。

测试入口条件即启动测试的基础条件，交叉测试主要为各家车载设备在其他家地面区域进行交叉验证，为了保证交叉测试时的效率，要求交付到交叉测试平台的软件或数据需满足的测试入口条件如下表所示：

以上入口条件需要各家提供相应的测试报告、调试报告或软件、数据发布单作为证据支撑。被测软件在交叉测试平台调试未通过，不允许进行交叉测试。

测试版本管理的确定是测试工作开展的必要前提条件，互联互通交叉测试平台应需对各厂家软件、数据以及车载电子地图公共数据进行整体版本管理。室内测试平台每一轮测试标签要求包含各厂家软件、数据以及互联互通线路的车载电子地图公共数据，且要求各厂家使用的其他厂家车载电子地图公共数据一致。仅在版本校核正确后，交叉测试方可开始。交叉测试过程中，任何厂家不得擅自进行软件、数据升级，如有升级需求，需放到下一个版本进行。对版本管理的强制项及其说明如下表所示：

进一步地，S102之前，还包括：

S1012、对所述CBTC***的各组成部分进行厂家自测试。

S103、若满足测试入口条件，则通过所述交叉测试平台对所述互联互通CBTC***进行交叉测试。

在室内测试之后，还需对所述CBTC***进行现场测试。

其中，所述现场测试包括单车测试和多车测试，所述多车测试包括正常运营追踪测试和追踪故障测试。

对所述互联互通CBTC***进行交叉测试的过程中，采用共线测试、跨线测试、多车测试或不涉及车载测试的方式。

所述共线测试由共线车载方主导，所述跨线测试由即将进入的跨线线路地面方进行主导，所述多车测试或不涉及车载测试由地面方主导。

互联互通CBTC***由多个厂家的软硬件组成，在交叉测试进行时由于各家车载***要在不同厂家地面线路上进行测试，故应明确相关测试工作的主导责任方。本实施例以行车为核心的指导思路，按如下方式进行测试：

对于测试执行工作主导方管理如下：

共线测试：由共线车载方主导；

跨线测试：由即将进入的跨线线路地面方进行主导；

多车测试或不涉及车载测试：由地面方主导。

对于测试执行活动产生的测试记录，还有测试报告编制工作的管理如下：

由每次测试执行的主导方完成测试记录的汇总与报告编制工作；

测试执行记录需参与各方签字确认，相应测试报告需测试执行参与各方共同评审并签字确认；

测试缺陷管理如下：

缺陷管理推荐采用统一的缺陷管理平台，测试主导方负责测试缺陷的记录。

另外，在交叉测试过程中，测试案例设计是非常重要的一个环节，测试输入项的完整程度直接影响测试案例的完整程度。与传统CBTC项目不同，互联互通的测试案例设计主要遵守协会的两个测试规范要求：首先，需要通过对协会标准测试规范梳理分析识别，互联互通交叉测试验证的核心工作应着眼于不同厂家之间的信息交互功能上，其余规范要求的非交互互联互通功能应作为信号厂商内部验证工作，不在室内测试重点验证范围之内。其次，需要结合实际工程特点，增加交互验证功能点，以及工程性能指标类验证点。

互联互通测试工作主要完成集成测试工作与确认测试工作(含工程数据确认测试)，根据梳理工作输出《互联互通交叉测试_接口测试需求表》、《互联互通交叉测试_实验室功能测试需求表》两个表作为指导交叉测试接口、功能测试案例设计的基础。

所述交叉测试的具体内容包括：交互接口测试、交互功能测试、多车专项测试、故障恢复测试、按照运营场景测试、运行指标测试和工程线路数据验证测试，具体描述如下：

交互接口测试：

依据满足接口规范要求的接口文件，进行各厂家交互***的接口测试。主要验证***接口信息帧格式、内容是否满足接口设计要求。

接口测试需求表示意如下：

交叉测试需进行各厂家车载***与地面***交互相关的功能测试，例如：点式列车升级测试、屏蔽门联动测试、CBTC列车升级测试、CBTC列车ZC集中区切换测试、列车折返测试等。

交互功能测试：

功能测试需求表示意如下：

由以上功能识别表产出相关测试案例，而且同时对互联互通运营场景图、以及制定的相应运营需求进行梳理，保证互联互通运营场景均被覆盖，并作为测试案例的设计基础。

考虑到互联互通***“列车可在互联互通任意线路共线运行、可与互联互通***内任意厂家列车任意追踪”的特点，实验室环境内测试应考虑多车共线追踪测试，对不同情况的多车追踪组合进行专项测试案例设计；同时，测试还应关注故障导向安全和故障恢复时的各项测试案例设计。最后为了满足***的工程应用应进行各线车载电子地图数据的确认测试。

多车专项测试：

交叉测试需将各厂家的真实车载***模拟放到某一厂家线路上进行各种前后追踪组合的多车追踪测试，各测试项及其说明如下表所示：

故障恢复测试：

考虑到各厂家***故障恢复时的处理原则存在差异，另一方面许多故障场景较难在真实环境下得以验证，故需要对关键运行场景进行相关故障以及故障恢复测试，各测试项如下表所示：

序号	测试项
		1	同计轴双车追踪(一车故障)
2	相邻计轴双车追踪(一车故障)
		3	间隔计轴双车追踪(一车故障)
4	同计轴三车追踪故障
		5	相邻计轴三车追踪故障
6	列车与移交、接管ZC通信中断
		7	列车退行防护

按照运营场景测试：

除规范要求测试验证之外，***应满足其他交互类运营场景要求，各测试项如下表所示：

运行指标测试：

在有条件的基础上应考虑不同厂家车载***在不同厂家地面的运行指标测试，各测试项如下表所示：

序号	测试项
		1	最小运营间隔
2	折返能力测试
		3	旅行速度测试

工程线路数据验证测试：

在验证各厂家软件满足互联互通规范要求，以及实现工程应用要求的前提下，还需要对各互联互通线路工程应用的车载电子地图做功能数据确认测试工作。该项测试产出一个基于被测互联互通线路的测试数据表格，通过在数据表格中指定的地点或条件进行逐个功能验证确认测试，各测试项如下表所示：

序号	测试项
		1	每条进路的点式与CBTC级别升级测试
2	每个站台的站台门开关测试
		3	每个折返点的折返测试

以上形成的案例主要为交叉实验室室内工程测试的案例集，相对于现场交叉测试案例的设计仅在确认测试案例中进行部分选取，保证每一类型的功能在某一种控制等级下至少进行过一次测试，例如列车开关门测试，在点式或CBTC级别可只进行一次测试验证。对于工程线路数据验证测试，现场测试场景与室内仿真测试场景硬件环境不同的，需要逐一测试，例如列车停车精度的确认测试；若无环境差异的，可进行抽测。

基于以上的案例分类，当一个城市已经完成某几条线互联互通测试后，再增加一条互联互通线路时，应主要增加工程线路数据验证的数据，而接口测试案例与功能测试案例等，不应受到影响，并可复用使用。其他各城市建设互联互通线路时，由于互联互通示范工程的案例成果是基于行业的规范要求设计，以及经过互联互通示范工程的实践检验，应复用使用互联互通示范工程的接口案例、功能案例成果，主要修订符合本地要求的运营场景案例、运行指标案例、以及当地工程线路数据验证的数据。

测试执行主要分为三个阶段：厂家自测试阶段、交叉测试平台测试阶段、现场测试阶段。

第一阶段、厂家自测试阶段

厂家自测试要求厂家在自家的平台完成相应的工作，需厂家进行自身产品测试、互联互通工程应用线路***测试以及工程线路数据测试，测试后要求软件无缺陷或满足软件、数据出口要求，以保证符合互联互通标准设计功能。

第二阶段、交叉测试平台测试阶段

在完成了厂家自测试之后，满足测试入口条件且按照版本管理发布软件与数据到交叉测试平台，进行交叉测试平台的测试工作。

在交叉测试平台测试阶段，主要验证各厂家车载***在其他家地面***的共线运营，以及跨线运营。测试工作分为互联互通工程接口测试阶段、互联互通工程功能确认测试阶段与互联互通工程数据确认测试阶段这几个阶段。为保障交叉测试的顺利进行，互联互通各信号厂商应提供至少两个集中区作为样本段进行初期测试，后期根据项目进度逐渐补齐其余集中区。

工程接口测试阶段

需要每一家车载***与每一家地面***进行一对一的接口测试，本家车载与地面的接口测试不在交叉测试范围内。还需要对地面之间有接口的两家地面***进行接口间的接口测试。接口测试遵循一份设计文档，验证双方发送报文信息是否与接口设计一致，包括，列车进站时、列车折返时、列车在地面管辖区切换时等各种状态下的接口信息一致性。其中对于安全通信协议由各自厂家负责测试，测试过程中出现的相关问题，修改后仍由各自厂家对此负责。测试完成后能够确保任意厂家车载在任意厂家地面***进行正常信息交互。

功能确认测试阶段

需要每一家车载***与每一家地面***依据编制完成的测试大纲案例内容，进行逐条的功能确认。功能确认测试可选取任意地点与场景进行，要确认功能交互双方的状态的正确性，本家车载与地面的功能确认测试不在交叉测试范围内。测试完成后能够确保任意厂家车载在任意厂家地面***进行正常的功能实现。

工程数据确认测试阶段

根据测试大纲识别的需要逐个相同场景进行确认的功能，逐一在场景地点进行确认，形成对工程实施数据正确性的验证。数据确认测试要将满足功能实现的所有地点进行确认，本家车载与地面的工程数据测试不在交叉测试范围内。测试完成后能够确保任意厂家车载在任意厂家地面***各种地点场景下进行正常的功能实现。

本实施例通过互联互通CBTC***的交叉测试平台的搭建、室内交叉测试与管理以及现场测试调试与管理，能够有效的组织互联互通的验证，保障互联互通技术工程应用的顺利实施。

进一步地，在上述方法实施例的基础上，所述方法还包括：

S104、通过所述交叉测试平台对所述互联互通CBTC***进行单车测试和多车测试。

其中，所述多车测试包括正常运营追踪测试和追踪故障测试。

具体地，测试执行过程中的第三阶段为现场交叉测试调试阶段，在完成了测试平台的交叉测试之后，按照版本管理发布软件与数据到现场，进行现场交叉测试调试工作。

现场测试按照项目阶段不同，分为单车测试、多车测试。开展互联互通现场测试时，要求各信号厂商只针对首列车进行互联互通功能测试。后续列车主要是进行***性能相关测试(开关车门，停车精度等)。

单车测试需要在试车线完成静动调后，并通过第三方安全认证机构取得本线车辆在它线地面的单车测试授权及它线地面允许它线车辆单车测试授权，方可进入正线进行单车测试。

单车测试信号***相关要在现场验证实验室仿真的车辆部分的正确性。列车在每个站台的开关门情况，停车情况等。单车测试不仅关注信号***的功能，更应关注列车进行测试后，轨道磨损状态，道岔贴合情况，线路限界情况。

多车测试的前提条件是完成现场单车测试及测试报告，并通过第三方安全认证机构取得本线车辆在它线地面的多车测试授权及它线地面允许它线车辆多车测试授权。基于上述条件开始启动多车测试工作。

多车测试主要进行两类测试：

第一类，正常运营追踪测试，根据现场的时间条件，尽可能多进行不同厂家列车前后追踪测试验证，时间紧张时，可分上下行分别调换前后列车追踪次序，以减少时间因素对测试组合的影响。最终实现各家车载之间的追踪行车未出现非预期的紧急制动等影响运营情况。

第二类，追踪故障测试，本项测试要求所有前后车组合均要进行前车各种情况下故障对后车的影响确认。最终实现列车追踪故障时满足各家设计原则，且导向安全无问题。

通过测试平台的搭建、室内交叉测试与管理以及现场测试调试与管理，能够有效的组织互联互通的验证，保障互联互通技术工程应用的顺利实施。

总结来说，在进行互联互通CBTC***的交叉测试的过程中，主要分为以下三步：

第一步：测试管理，包括测试入口条件与测试版本管理和测试执行管理；

第二步：测试设计，包括编制互联互通交叉测试案例和搭建交叉测试平台；

第三步：测试执行，包括厂家自测试、室内交叉测试(又分为互联互通接口测试阶段、互联互通功能确认测试阶段与互联互通工程数据确认阶段)以及现场交叉测试。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (9)

1.一种互联互通CBTC***的交叉测试方法，其特征在于，包括：

构建互联互通CBTC***的交叉测试平台；

判断当前情况是否满足测试入口条件；

若满足测试入口条件，则通过所述交叉测试平台对所述互联互通CBTC***进行交叉测试；

其中，所述交叉测试包括互联互通接口测试阶段、互联互通功能确认测试阶段与互联互通工程数据确认阶段。

2.根据权利要求1所述的方法，其特征在于，所述测试入口条件包括地面方入口条件、车载方入口条件、数据入口条件和涉及变更后的回归测试入口条件；

其中，所述地面方入口条件包括本线地面功能测试通过和本线线路数据测试通过；

所述车载方入口条件包括本线车载功能测试通过；

所述数据入口条件包括测试双方公有数据版本匹配一致；

所述涉及变更后的回归测试入口条件包括遵循变更控制管理。

3.根据权利要求1所述的方法，其特征在于，所述判断当前情况是否满足测试入口条件之前，还包括：

对所述CBTC***的各组成部分进行厂家自测试。

4.根据权利要求1所述的方法，其特征在于，所述若满足测试入口条件，则通过所述交叉测试平台对所述互联互通CBTC***进行交叉测试之后，还包括：

对所述CBTC***进行现场测试；

其中，所述现场测试包括单车测试和多车测试，所述多车测试包括正常运营追踪测试和追踪故障测试。

5.根据权利要求1所述的方法，其特征在于，所述对所述互联互通CBTC***进行交叉测试的过程中，采用共线测试、跨线测试、多车测试或不涉及车载测试的方式；

其中，所述共线测试由共线车载方主导，所述跨线测试由即将进入的跨线线路地面方进行主导，所述多车测试或不涉及车载测试由地面方主导。

6.根据权利要求1所述的方法，其特征在于，所述交叉测试的具体内容包括：交互接口测试、交互功能测试、多车专项测试、故障恢复测试、按照运营场景测试、运行指标测试和工程线路数据验证测试。

7.一种互联互通CBTC***的交叉测试平台，其特征在于，包括：车载设备层、车辆仿真层、轨旁设备仿真层、车站设备层和控制中心层；

所述控制中心层主要包括中心列车自动监控***ATS设备和数据服务单元DSU设备；

所述车站设备层主要包括区域控制器ZC设备、连锁CI设备；

所述轨旁设备仿真层用于模拟轨旁的信号设备，所述轨旁的信号设备包括道岔、应答器、计轴、信号机、地面电子单元LEU设备；

所述车辆仿真层用于驾驶台的仿真以及车辆动力学模型的仿真，包括驾驶台仿真器及动力学模型仿真器；

所述车载设备层包括四套真实车载控制器VOBC设备以及多媒体交互***MMI。

8.根据权利要求7所述的交叉测试平台，其特征在于，还包括：

信号红网和信号蓝网，所述信号红网和信号蓝网用于传输ZC\DSU\CI设备的信息；

ATS红网和ATS蓝网，所述ATS红网和ATS蓝网用于传输ATS信息；

仿真平台网，用于传输仿真软件交互信息；

维护网，作为预留的网络；

所述信号红网、信号蓝网、ATS红网、ATS蓝网、仿真平台网和维护网分别部署交换机，根据不同供应商的要求在交换机上进行配置，实现网络划分。

9.根据权利要求7所述的交叉测试平台，其特征在于，还包括：

ZC\ATS相关接口，所述ZC\ATS相关接口包括：VOBC与ZC/ATS接口、ZC-ZC接口和ATS-ATS接口；

CI接口，所述CI接口包括：与真实设备接口和与测试平台接口；

VOBC接口适配，用于实现各厂家VOBC信号的生成以及硬线接口的快速接入。