列车测试方法、系统、存储介质及电子设备

技术领域

本公开涉及轨道交通技术领域，具体地，涉及一种列车测试方法、系统、存储介质及电子设备。

背景技术

列车运行图是用以表示列车在轨道区间运行及在车站到发或通过时刻的技术文件，是全路组织列车运行的基础。通常在线路开通前，会按照开通后的列车运行图在仿真测试平台进行全线模拟运行。跑图测试能够持续优化各系统的稳定性、可靠性和安全性，为开通做好充足的准备。

相关技术中，需要人工监控跑图测试过程中各列车的状态，无法及时发现异常状态，测试效率低。

发明内容

本公开的目的是提供一种列车测试方法、系统、存储介质及电子设备，以提高列车跑图测试的测试效率。

为了实现上述目的，本公开的第一方面提供一种列车测试方法，所述方法包括：

根据预设列车运行图，确定目标车次信息以及所述目标车次信息对应的目标列车；

基于所述目标车次信息对所述目标列车进行跑图测试，并监控所述跑图测试过程中所述目标列车的目标状态；

根据所述目标状态对所述跑图测试进行控制。

可选地，所述根据所述目标状态对所述跑图测试进行控制，包括：

在所述目标状态表征所述目标列车出现可恢复故障的情况下，在所述目标列车恢复正常状态后，控制所述目标列车继续进行所述跑图测试；或，

在所述目标状态表征所述目标列车出现不可恢复故障的情况下，控制所述目标列车停止所述跑图测试。

可选地，所述在所述目标状态表征所述目标列车出现不可恢复故障的情况下，控制所述目标列车停止所述跑图测试，包括：

在所述目标状态表征所述目标列车出现以下至少一种不可恢复故障的情况下，控制所述目标列车停止所述跑图测试：

所述目标列车处于降级状态；

所述目标列车处于非降级状态、且紧急制动超过预设时长；

所述目标列车处于异常停车状态、且不满足预设发车条件；

所述目标列车处于所述非降级状态、且早晚点时间超过预设时间阈值；以及，

所述目标列车与列车自动监控系统通信中断、且所述通信中断的次数大于预设次数阈值。

可选地，所述在所述目标状态表征所述目标列车出现可恢复故障的情况下，在所述目标列车恢复正常状态后，控制所述目标列车继续进行所述跑图测试，包括：

在所述目标状态表征所述目标列车处于紧急制动的情况下，若所述目标列车在预设时长后自动解除所述紧急制动，则控制所述目标列车继续进行所述跑图测试；或，

在所述目标状态表征所述目标列车处于所述紧急制动的情况下，响应于针对所述紧急制动的解除指令，若所述目标列车解除所述紧急制动，则控制所述目标列车继续进行所述跑图测试。

可选地，所述在所述目标状态表征所述目标列车出现可恢复故障的情况下，在所述目标列车恢复正常状态后，控制所述目标列车继续进行所述跑图测试，包括：

在所述目标列车处于异常停车状态的情况下，若所述目标列车处于站台位置且在预设停站时间内未进行开关门操作，则控制所述目标列车重新发车，继续进行所述跑图测试；或，

在所述目标列车处于所述异常停车状态、且满足预设发车条件的情况下，控制所述目标列车重新发车，继续进行所述跑图测试。

可选地，所述根据所述目标状态对所述跑图测试进行控制，包括：

在所述目标状态表征所述跑图测试的测试环境出现异常的情况下，重启所述跑图测试的测试环境。

可选地，在所述监控所述跑图测试过程中所述目标列车的目标状态之后，所述方法还包括：

在所述目标状态表征所述目标列车完成所述跑图测试的情况下，解除所述目标列车与所述目标车次信息的对应关系，并将所述目标列车加入预设空闲列车列表中。

可选地，所述基于所述目标车次信息对所述目标列车进行跑图测试，包括：

获取当前时间；

根据所述当前时间和所述目标车次信息，确定所述目标列车对应的目标加车时间和目标加车地点；

在所述目标加车时间和所述目标加车地点满足预设加车条件的情况下，基于所述目标车次信息对所述目标列车进行所述跑图测试。

可选地，所述在所述目标加车时间和所述目标加车地点满足预设加车条件的情况下，基于所述目标车次信息对所述目标列车进行所述跑图测试，包括：

在所述目标加车时间和所述目标加车地点满足所述预设加车条件的情况下，对所述目标列车进行预设加车操作；

若所述目标列车满足加车成功的预设判断条件，则根据所述目标车次信息确定所述目标列车对应的目标运行计划，并基于所述目标运行计划对所述目标列车进行所述跑图测试。

可选地，所述在所述目标加车时间和所述目标加车地点满足所述预设加车条件的情况下，对所述目标列车进行预设加车操作，包括：

在所述目标加车时间和所述目标加车地点满足所述预设加车条件的情况下，基于所述目标列车的定位信息，将所述目标列车从待机模式升级至全自动驾驶模式，并获取所述目标列车的移动授权。

可选地，所述方法还包括：

若所述目标列车未满足所述加车成功的预设判断条件，则确定所述目标列车的目标状态为表征所述目标列车出现不可恢复故障的状态。

可选地，所述目标车次信息的数量为多个，所述基于所述目标车次信息对所述目标列车进行跑图测试，并监控所述跑图测试过程中所述目标列车的目标状态，包括：

针对每一所述目标车次信息，基于所述目标车次信息以及所述目标车次信息对应的目标列车创建测试子进程进行子进程跑图测试，并获取所述子进程跑图测试过程中所述目标列车的子进程状态；

所述根据所述目标状态对所述跑图测试进行控制，包括：

根据所述子进程状态对所述子进程状态对应的所述子进程跑图测试进行控制。

本公开的第二方面提供一种计算机可读存储介质，其上存储有计算机程序指令，该程序指令被处理器执行时实现上述第一方面中任一项所述方法的步骤。

本公开的第三方面提供一种电子设备，包括：

存储器，其上存储有计算机程序；

处理器，用于执行所述存储器中的所述计算机程序，以实现上述第一方面中任一项所述方法的步骤。

本公开的第四方面提供一种列车测试系统，包括上述第三方面中所述电子设备。

通过上述技术方案，本公开可以根据预设列车运行图确定目标车次信息以及目标车次信息对应的目标列车，然后基于目标车次信息对目标列车进行跑图测试，并监控跑图测试过程中目标列车的目标状态，最后根据目标状态对跑图测试进行控制。采用上述方法，通过监控跑图测试过程中列车的状态，可以及时发现跑图测试是否出现异常，并且还可以基于列车状态对跑图测试进行控制，从而根据实际情况及时调整跑图测试，实现自动化跑图测试，有效提高跑图测试的测试效率。

本公开的其他特征和优点将在随后的具体实施方式部分予以详细说明。

附图说明

附图是用来提供对本公开的进一步理解，并且构成说明书的一部分，与下面的具体实施方式一起用于解释本公开，但并不构成对本公开的限制。在附图中：

图1是本公开实施例提供的一种列车测试方法的流程示意图；

图2是本公开实施例提供的一种自动化测试平台的示意图；

图3是本公开实施例示出的另一种列车测试方法的流程示意图；

图4是本公开实施例示出的一种自动化测试系统的示意图；

图5为本公开实施例提供一种自动化跑图的主进程的流程图；

图6为本公开实施例提供一种自动化跑图的子进程的流程图；

图7是本公开实施例示出的一种电子设备的框图。

具体实施方式

以下结合附图对本公开的具体实施方式进行详细说明。应当理解的是，此处所描述的具体实施方式仅用于说明和解释本公开，并不用于限制本公开。

相关技术中，基于通信的列车自动控制（Communication Based Train Control，CBTC）系统，在进行跑图测试时，首先在车辆段（存车区）加车，通常列车默认为STB模式（Standby mode，待机模式），因此需要将列车升级为RM模式（Restricted Manual Mode，限制人工驾驶模式），再升级成CM模式（Coded Mode，列车自动防护模式），最后再升级为FAM模式（Full ATO Mode，全自动驾驶模式），升级完成后，通过派班计划或给列车匹配一个转换轨的头码，将列车出库到转换轨，然后在转换轨匹配运行计划，并在匹配运行计划后对列车运行状态进行监控以及故障再处理。在这个过程中，需要结合加车升级到FAM模式所需时间、列车运行至转换轨所需时间以及运行计划中列车的发车时间来确定加车时间。但是在升级过程中可能因为一些人为的误操作导致升级失败，导致对列车的升级时间把握不准确，加车时间过早，列车会提前行驶到转换轨匹配运行计划，然后需要等待很长时间，从而影响测试效率，若运行计划中列车的发车时间已经开始，但列车还未行驶至转换轨，则会造成列车晚点。

并且，通过人工监控跑图测试过程中各列车的状态，无法及时发现并处理多辆列车的异常状态，例如列车运行过程中的一些异常状态如丢失一个应答器或超过全常用制动速度等会有报警提示，但是需要手动记录发生异常的时间和位置信息，效率较低。此外，若根据列车的异常状态确定列车出现故障，需要及时对故障进行处理，否则会出现堵车风险导致跑图测试无法继续进行。例如由于某种原因导致列车发生故障，未及时删车和清理测试环境，会导致后车无法驶入该进路，长时间未处理会导致列车堵车。或者测试人员及时发现了故障的列车，进行手动删车、清理测试环境，再根据列车运行图重新加车并进行跑图测试，但是整个过程操作复杂，且耗时耗力。

有鉴于此，本公开实施例提供一种列车测试方法、系统、存储介质及电子设备，以解决上述技术问题。

在介绍本公开提供的列车测试方法、系统、存储介质及电子设备之前，首先对本公开各个实施例所涉及的应用场景进行介绍。该应用场景中的列车可以是任一种按照预设轨道运行的列车，例如：火车、地铁、轻轨、有轨电车等，可以在线路开通前进行跑图测试，以持续优化各系统的稳定性、可靠性和安全性，为线路开通做好充足的准备。

为了实现上述目的，本公开实施例提供一种列车测试方法，参照图1，该方法包括：

S101、根据预设列车运行图，确定目标车次信息以及目标车次信息对应的目标列车。

其中，目标车次信息包括至少一个车次号。

示例地，车次信息即车次表，可以从预设列车运行图中获取，一个车次表对应一辆列车。车次表包括列车从运行开始到运行结束的全部车次号，每一车次号表示一次列车从运行线路起点运行到运行线路终点的过程，通过车次号可以查询列车从运行线路起点运行到运行线路终点的过程中，途经每个站台的进站时间、出站时间、站台信息等等列车运行所需的信息。以地铁为例，某条运行线路包括多辆列车，每一列车从地铁开始运营时间到地铁结束运营时间，需要在运行线路上进行多次折返，单程运行对应一个车次号，全部折返运行对应一个车次表。列车运行图中包括多个车次表，并通过唯一标识进行区分，例如车次表编号，本公开对此不作限制。

示例地，可以设置轮询时间对预设列车运行图进行查询，例如每分钟查询一次预设时间内要出发的车次，轮询时间和预设时间可以根据需求设置，本公开对此不作限制。比如列车运行图包括车次表1、车次表2、车次表3，车次表1的最早出发时间（最早出发的车次号对应的发车时间）为6:00，车次表2的最早出发时间为6:10、车次表3的最早出发时间为6:15，设置每分钟查询一次4分钟内要出发的车次，则5:56查询到车次表1，从列车空闲列表中选择一空闲列车的车组号（列车ID）与车次表1匹配并进行跑图测试，进而在6:06查询到车次表2，以此类推。

S102、基于目标车次信息对目标列车进行跑图测试，并监控跑图测试过程中目标列车的目标状态。

S103、根据目标状态对跑图测试进行控制。

采用上述方法，通过监控跑图测试过程中列车的状态，可以及时发现跑图测试是否出现异常，并且还可以基于列车状态对跑图测试进行控制，从而根据实际情况及时调整跑图测试，实现自动化跑图测试，有效提高跑图测试的测试效率。

图2为本公开实施例提供的一种用于跑图测试的自动化测试平台的示意图。自动化测试平台通过通信协议与ATS（Automatic Train Supervision System，列车自动监控系统）服务器建立通信，通过指令下发达到操作目的，模拟ATS-HMI（Human MachineInterface，人机界面）的界面端的操作，通信协议可以是websocket协议，具体可以根据实际应用场景设置，本公开对此不作限制。自动化测试平台操作的服务器涉及ATS服务器、CI（Computer Interlocking，计算机联锁）、ZC（Zone Controller，区域控制器）、VOBC（Vehicle On-board Controller，车载控制器）等等子系统，涉及对子系统的封装、连接、操作、获取、返回、判断等多种操作。其中，CI和VOBC可以通过ATE（Automatic TestEnvironment，自动测试环境）仿真软件模拟工作状态。在进行跑图测试之前，需要提前搭建好自动化测试环境，准备好电子地图、联锁表、码位顺序表等工程数据并转化成自动化测试平台可读的格式，如JSON格式，最后启动测试环境。

图3为本公开实施例提供的另一种列车测试方法的流程示意图，参照图3，该方法包括：

S301、自动化一键加车升级至FAM模式。

S302、列车出库到转换轨。

S303、列车匹配运行计划。

S304、列车运行状态监控。

S305、故障再处理。

在可能的方式中，基于目标车次信息对目标列车进行跑图测试，可以包括：获取当前时间；根据当前时间和目标车次信息，确定目标列车对应的目标加车时间和目标加车地点；在目标加车时间和目标加车地点满足预设加车条件的情况下，基于目标车次信息对目标列车进行跑图测试。

示例地，以某一列车A对应的车次信息包括车次号1（9:00-10:00）、车次号2（11:00-12:00）、车次号3（13:00-14:00）、车次号4（15:00-16:00）为例。一般在第一个车次出发之前进行加车，或者因故障导致跑图测试被终止后重新加车，因此可以根据当前时间查找到距离最近的未出发车次号或者正在运行的车次号，基于当前时间可以确定该车次号对应的跑图测试是首次跑图测试还是重启的跑图测试。

示例地，以车次号1的信息包括：站台A（进站时间9:00；出站时间9:03）、站台B（进站时间9:10；出站时间9:13）、站台C（进站时间9:20；出站时间9:23）为例，若当前时间为8:55，车次号1并未发车，说明是首次跑图测试，则加车地点应为转换轨（从存车区转换至列车运行正线的转换轨道），并应当在车辆段（存车区）加车出库运行至转换轨，加车时间可以结合车次号1开始运行时间（首发站台A的进站时间）和列车进行加车准备以及运行到转换轨所需的时间进行设置，例如在8:58开始加车，本公开对此不作限制。

示例地，若当前时间为9:15，按照正常情况列车应当运行在站台B和站台C之间，说明是重启的跑图测试，则在该列车对应的车次表中匹配与当前时间往后1分钟（时间可设置）最接近的列车进站时间和站台，例如可以将下一个距离最近的站台C作为加车地点，加车时间可以是9:19，本公开对此不作限制。

在可能的方式中，在目标加车时间和目标加车地点满足预设加车条件的情况下，基于目标车次信息对目标列车进行跑图测试，可以包括：在目标加车时间和目标加车地点满足预设加车条件的情况下，对目标列车进行预设加车操作；若目标列车满足加车成功的预设判断条件，则根据目标车次信息确定目标列车对应的目标运行计划，并基于目标运行计划对目标列车进行跑图测试。

示例地，在到达加车时间时，需要判断加车地点是否空闲，加车地点一般用逻辑区段表示，因此这里是对逻辑区段对应的物理区段是否空闲进行判断，若加车地点空闲则可以进行预设加车操作，否则需要重新获取加车时间和加车地点。例如针对首次跑图测试判断转换轨是否被占用，或者针对重启的跑图测试，判断加车站台的物理区段的锁闭状态，如果物理区段未锁闭则直接加车，若物理区段处于锁闭状态，则说明物理区段在使用中，需要重新获取加车时间和加车地点。

在可能的方式中，在目标加车时间和目标加车地点满足预设加车条件的情况下，对目标列车进行预设加车操作，可以包括：在目标加车时间和目标加车地点满足预设加车条件的情况下，基于目标列车的定位信息，将目标列车从待机模式升级至全自动驾驶模式，并获取目标列车的移动授权。

示例地，在目标加车时间和目标加车地点满足预设加车条件的情况下，利用CI故障注入功能将加车地点所在的物理区段的状态修改为进路锁闭状态，调用ATE添加车组号对应的已有定位信息的目标列车（列车在STB模式时依据列车模拟软件发送的定位信息进行列车定位），随后启动VOBC系统，并根据列车的运行方向激活列车相应端的驾驶室，列车从待机模式升级至全自动驾驶模式，进而通过ATS下发列车头尾筛命令以使列车匹配进路并获取MA（移动授权），自此完成列车的加车操作，具体可以根据列车所需的加车步骤进行操作，例如地铁和高铁的加车步骤可能存在区别，本公开对此不作限制。

值得说明的是，列车通过一键加车从STB模式直接升级至FAM模式，减少了加车时间，并且相较于相关技术从STB模式升级为RM模式、再升级成CM模式、最后升级为FAM模式的方式，不容易受人为因素的影响，可以准确把握加车时间，避免列车过早或过晚到达加车地点。

进而，若为首次跑图测试，处于车辆段的FAM模式列车会匹配一个出库的转换轨头码，并将联锁区的进路交自动控制，列车即可自动触发运行前方的进路，自动发车行驶至转换轨，运行至转换轨的列车，在距离发车时间的两分钟内（时间可设置），会自动匹配运行计划，根据运行计划自动触发运行前方的进路，未到达发车时间的列车会在原地等候，到达发车时间的列车则会自动发车。

示例地，若为重启的跑图测试，在目标加车时间和目标加车地点满足预设加车条件的情况下，则可以将列车前方进路交人工控制，目的是为了防止列车匹配运行计划后直接触发前方进路，影响前方站台加车，降低加车效率。加车成功后，可以自动匹配运行计划，但是为了避免匹配错误也可以接收手动下发的运行计划，并且给该列车添加对应的车次表以及对应的车次号并等待发车时间，到达发车时间后将列车前方进路交自动控制，进路自动触发，列车自动发车。

在可能的方式中，该方法还包括：若目标列车未满足加车成功的预设判断条件，则确定目标列车的目标状态为表征目标列车出现不可恢复故障的状态。

示例地，需要对列车是否加车成功进行判断，加车成功判断条件可以包括从ATS获取列车运行模式为FAM、列车无EB状态（紧急制动）、列车有MA、加车物理区段未被占用状态，等等，可以根据需求设置，本公开对此不作限制。若满足上述加车成功判断条件，则匹配运行计划，加车失败则确定目标列车的目标状态为表征目标列车出现不可恢复故障的状态，后续可以进行删车、资源清理操作，然后终止该列车的跑图测试。

示例地，列车加车成功以后，需要实时监控并更新列车的运行状态。运行状态包括但不局限于列车与中心（ATS）通信状态、运行模式、运行方向、清客状态、停稳停准状态、紧急制动状态、早晚点状态、车头所在的逻辑区段、车头所在的物理区段、车头所在的进路、车头所在的联锁区、逻辑区段使用列表、进路使用列表、物理区段使用列表、列车占用的站台门、故障报警等信息。

在可能的方式中，根据目标状态对跑图测试进行控制，可以包括：在目标状态表征目标列车出现可恢复故障的情况下，在目标列车恢复正常状态后，控制目标列车继续进行跑图测试；或，在目标状态表征目标列车出现不可恢复故障的情况下，控制目标列车停止跑图测试。

示例地，列车在跑图测试过程中如果发生故障，则记录发生故障的列车的车次表和车组号、时间、所处的逻辑区段以及偏移量、物理区段、进路以及所处的联锁区等信息。故障无法恢复则进行删车处理，并清理列车故障导致的设备故障状态（清理资源），以便后续再次加车，重新进行新的跑图测试。

示例地，在清理设备故障状态时，需要识别列车所占用的设备资源。首先需要将列车使用的进路列表取消自动触发属性交人工控制，以免进路误触发，进而通过CI的故障注入功能将列车使用的物理区段进行故障解除，再将进路交回自动控制。此外，若列车使用了站台门资源，则需要判断站台门的状态，如果站台门处于打开状态，则需要远程下发关闭站台门的命令将站台门关闭，等等，具体可以根据实际情况进行清理。

在可能的方式中，根据目标状态对跑图测试进行控制，可以包括：在目标状态表征跑图测试的测试环境出现异常的情况下，重启跑图测试的测试环境。并且，在监控跑图测试过程中目标列车的目标状态之后，该方法还包括：在目标状态表征目标列车完成跑图测试的情况下，解除目标列车与目标车次信息的对应关系，并将目标列车加入预设空闲列车列表中。

示例地，可以设置状态标识对列车状态进行区分，例如列车的状态标识为0，则表示该列车的车次表已下线（车次表中所有车次已运行结束），列车已完成任务并空闲，将完成的车次表与车组号从已匹配的对应关系（或者字典）中删除，即解除车次表与车组号的对应关系，并将列车的车组号插回空闲列车列表中。如果列车的状态标识为1，则表示该列车出现不可恢复故障并已经进行了删车处理与状态清理（停止跑图测试），可以重新加车进行新的跑图测试。如果列车的状态标识为2，则表示测试环境出错，例如子系统宕机等情况，需要重启测试环境，具体可以根据需求进行设置，本公开对此不作限制。

在可能的方式中，在目标状态表征目标列车出现不可恢复故障的情况下，控制目标列车停止跑图测试，可以包括：在目标状态表征目标列车出现以下至少一种不可恢复故障的情况下，控制目标列车停止跑图测试：目标列车处于降级状态；目标列车处于非降级状态、且紧急制动超过预设时长；目标列车处于异常停车状态、且不满足预设发车条件；目标列车处于非降级状态、且早晚点时间超过预设时间阈值；目标列车与列车自动监控系统通信中断、且通信中断的次数大于预设次数阈值。

在可能的方式中，在目标状态表征目标列车出现可恢复故障的情况下，在目标列车恢复正常状态后，控制目标列车继续进行跑图测试，可以包括：在目标状态表征目标列车处于紧急制动的情况下，若目标列车在预设时长后自动解除紧急制动，则控制目标列车继续进行跑图测试；或者，在目标状态表征目标列车处于紧急制动的情况下，响应于针对紧急制动的解除指令，若目标列车解除紧急制动，则控制目标列车继续进行跑图测试。

在可能的方式中，在目标状态表征目标列车出现可恢复故障的情况下，在目标列车恢复正常状态后，控制目标列车继续进行跑图测试，可以包括：在目标列车处于异常停车状态的情况下，若目标列车处于站台位置且在预设停站时间内未进行开关门操作，则控制目标列车重新发车，继续进行跑图测试；或者，在目标列车处于异常停车状态、且满足预设发车条件的情况下，则控制目标列车重新发车，继续进行跑图测试。

应当理解的是，上述不可恢复故障、可恢复故障以及相应的处理方式，具体可以根据需求进行设置，本公开对此不作限制。

示例地，列车发生降级的场景包括但不限于：列车发生空转打滑补偿失败、列车位置不确定性超过允许值（定位误差大于误差允许阈值）、车辆完整性丢失等，若监控到列车降级，可以记录时间、位置、列车信息、故障信息“列车降级”等，删除列车并清理占用资源，并确定列车的状态标识为1。列车发生EB的场景包括但不限于：ATO任务超时故障、ATP任务超时故障等，若列车未降级且EB后跑图测试程序在预设时长内EB状态无法解除，则可以记录时间、位置、列车信息、故障信息“列车EB无法解除”等，删除列车并清理占用资源，并确定列车的状态标识为1。

示例地，列车EB可解除的场景包括但不限于：车速超过紧急制动触发速度、溜逸超速触发EB（溜逸距离未超过规定值）等，若检测到列车EB状态，记录时间、位置、列车信息、列车EB原因等。待列车停稳后判断EB是否自动解除，如果自动解除则继续跑图测试。或者响应于远程下发的解除指令，如果解除成功则继续跑图测试。其中，可以在列车停稳后远程下发解除指令，也可以在不能自动解除的情况下，远程下发解除指令，本公开对此不作限制。

示例地，列车处于异常停车状态（未紧急制动）的场景包括但不限于：列车在站台停车时间结束后未自动发车、区间停车无法发车等。若列车在站台停车，则检测列车使用站台门的状态，如果列车到站停稳停准后，在停站时间内未进行开关门操作，后续将不会自动发车，则可以下发远程发车命令让列车继续运行，并记录时间、位置、列车信息、站台信息等，并对导致列车无法自动开关门的故障原因进行分析，例如是否VOBC与CI通信中断等。

示例地，列车在站台停车且停稳的情况下，若列车未在开关门过程且列车停稳时间超过停站时间，则认为列车停车时间异常。或者，列车在区间停车的情况下，若列车停稳时间超过预设区间停车时间，则认为列车停车时间异常。进而判断列车是否满足预设发车条件，首先判断列车前方进路状态是否办理，若已办理则检查信号机是否开放，若信号机开放则下发发车指令，若发车成功则记录“列车有MA未自动发车”，若发车失败则删除列车并清理占用资源，确定列车的状态标识为1，并记录故障信息“列车有MA未自动发车且手动发车失败”。若信号机未开放则重启信号机，若信号机开放则重新下达发车指令并进行后续判断过程，并记录故障信息“列车前方信号机异常关闭”。若信号机重启失败则记录故障信息“列车前方信号机异常关闭且重启失败”等，删除列车并清理占用资源，确定列车的状态标识为1。若列车前方进路未办理，则判断前方进路的控制状态是否为自动控制，若为人工控制则将进路交自动控制，若已经是自动控制则记录故障信息“进路自动触发失败”，删除列车并清理占用资源，确定列车的状态标识为1。

示例地，列车未EB发生运行异常的场景包括但不限于：列车运行过程中出现早晚点现象、空转打滑等。正常情况下，列车早点或晚点时间在允许时间内（如5分钟内），会自动调整运行等级使列车尽量正点运行，超过允许时间则不再进行自动调整。若检测到列车早点时间或晚点时间超过允许时间，则记录早点情况或晚点情况，远程下发紧急制动命令让列车停下来，删除列车并清理占用资源，并确定列车的状态标识为1。

值得说明的是，可以监控列车的早晚点状态变化，如果列车每次经过折返轨，折返完成后都会晚点，说明给列车配置的折返时间不足，则记录该情况并输出提示重新调整列车运行图中的折返时间。如果列车每次到达某个站台都会早点，则记录该情况并输出提示修改运行计划的区间运行时间，等等，本公开对此不作限制。此外，还可以监控列车是否收到空转打滑的报警，列车正常运行不应该出现空转打滑，如果出现空转打滑，则记录该情况并输出提示，关注ATE动力学参数配置是否合理等。

示例地，监控列车与ATS的通信状态，如果通信中断次数连续累计超过预设次数（例如5次），则记录故障信息“列车与ATS通信中断”，删除列车并清理占用资源，确定列车的状态标识为1。

进一步地，如果多辆列车与ATS的通信中断，则可以确定测试环境出现问题，确定列车的状态标识为2，需要重启测试环境。

示例地，列车已跑完车次表中所有车次并到达终点，则认为该车次表已下线，列车变为空闲列车，后续不再进行跑图测试，确定列车的状态标识为0。

在可能的方式中，目标车次信息的数量为多个，基于目标车次信息对目标列车进行跑图测试，并监控跑图测试过程中目标列车的目标状态，可以包括：针对每一目标车次信息，基于目标车次信息以及目标车次信息对应的目标列车创建测试子进程进行子进程跑图测试，并获取子进程跑图测试过程中目标列车的子进程状态。根据目标状态对跑图测试进行控制，可以包括：根据子进程状态对子进程状态对应的子进程跑图测试进行控制。

示例地，通常跑图测试会包括多个车次表及其对应的列车，为了避免不同车次表之间的测试互不打扰，可以通过一个主进程和多个子进程（表示一个车次表及其对应的列车）的方式进行跑图测试。如图4所示，本公开实施例提供一种自动化测试系统，整个系统由一个主进程与多个子进程组成，其中主进程包含两个线程，主线程负责监控子进程（列车）发送过来的消息并根据消息内容做出相应的处理，子线程负责车次表的更新与新的子进程的开启。每一个子进程代表一个上线的车次表以及与其匹配的列车，子进程负责列车从加车、监控、故障分析到删车的整个过程，每新增一辆匹配车次表的列车即开启一个子进程。

图5为本公开实施例提供的自动化跑图主进程的简要流程图，如图5所示，首先可以根据配置文件配置的时间，开启主进程，开启主进程时间可以根据需求配置，本公开对此不作限制。然后在启动测试环境之前，需要先清理测试环境：判断是否存在CI、ZC、VOBC及ATE子系统状态残留，如果存在则先关闭。接着依次打开ATE子系统，CI子系统，ZC子系统，并将ZC上电解锁、取消临时限速和雨雪模式、连接ATS、删除车次窗，然后开始做全联锁区上电解锁，最后抬起全联锁区的SPKS（Staff Protection Key Switch，人员防护开关）按钮，以上操作结束后，测试环境启动完成，具体操作可以根据测试环境的启动要求设置，本公开对此不作限制。

进一步地，加载列车运行图，获取车次表（每一车次表至少包括一个车次号），并获取列车运行图的结束时间，作为后续结束主进程的依据。然后开启车次表更新子线程，参照图4，初始化空闲列车列表，然后以每分钟一次的频率（可设置）循环进行以下动作：根据当前时间，将即将上线运行的车次表加入上线车次表的列表中（若已存在则不做任何动作），并在空闲列车的列表中取出一辆空闲列车的车组号与车次表相匹配，然后开启该车次表与车组号的列车子进程。进而通过消息管道，监控是否有子进程发送的列车状态标识，并根据汇报消息进行分类处理，如果列车的状态标识为0，则认为该列车的车次表已下线，列车已完成任务并空闲，将完成的车次表与车组号从已匹配的字典中删除，并将列车的车组号插回空闲列表中。如果列车的状态标识为1，则表示该列车出现不可恢复故障并已经进行了删车处理与状态清理（停止跑图测试），可以重新进行新的跑图测试。如果列车的状态标识为2，则表示测试环境出错例如子系统宕机等情况，需要重启测试环境，具体可以根据需求进行设置，本公开对此不作限制。

最后，判断是否到达下线时间，如果当前时间已晚于列车运行图的末班车下线时间，且所有车次表均已下线，若无多日的测试计划则结束主进程。如果当前时间未晚于列车运行图的末班车下线时间，则继续监控子进程管道消息。或者如果当前时间已晚于列车运行图的末班车下线时间，但还有列车未完成任务（可能出现晚点），则延长一定时间（可配置）继续监控子进程管道消息。

图6为本公开实施例提供的自动化跑图子进程的简要流程图，如图6所示，首先开启列车子进程周期，通常是主进程在车次表和列车的车组号匹配后创建该子进程，或者是列车故障后向消息管道传递故障消息并自我关闭，主进程实时监控消息管道，判断是否有子进程发送的列车状态标识，监控到列车故障状态标识时，重启列车子进程周期。进而列车子进程根据当前时间，结合列车运行图（列车运行图中的车次信息），获取加车信息（加车时间和地点）。然后到达加车时间时，开始判断是否满足加车条件，如果加车区段为转换轨，则说明是刚上线的车次表，需在车辆段加车出库运行至转换轨。如果加车区段为非转换轨，则需要获取待加车逻辑区段所在的物理区段的使用情况，如果物理区段未使用则满足加车条件，如果物理区段被使用了则需要重新获取加车信息，待新的加车时间到达重新进行加车判断。

进一步地，在满足加车条件后进行加车操作，并对加车是否成功进行判断，加车操作和判断条件具体可以参考上述实施例中的预设加车操作和预设判断条件，本公开在此不再赘述。如果加车成功则进行下一步的列车匹配运行计划，加车失败则进行删车、资源清理操作，并向消息管道汇报故障信息，然后关闭列车子进程。其中，在转换轨加车时，列车会自动匹配运行计划，在非转换轨加车，为了防止列车匹配错误的运行计划，会向列车手动下发一次运行计划。然后实时更新列车的状态，并对列车状态进行分析和判断，当列车正常运行时实时更新列车的状态，当列车发生故障时对故障进行分类，并对故障类型进行分析判断，进而对发生故障的列车所占用的资源进行清理，然后关闭列车子进程周期，故障类型具体可以参考上述实施例中的可恢复故障和不可恢复故障，本公开在此不再赘述。

采用上述技术方案，通过主进程负责车次表的更新与新的子进程的开启，以及监控子进程的消息并进行相应处理，然后通过子进程代表一个上线的车次表以及与其匹配的列车，并且子进程负责列车从加车、监控、故障分析到删车的整个过程，各子进程独立运行，当其中一个子进程发生故障时，不影响其他子进程继续跑图测试。

基于同一发明构思，本公开实施例提供一种计算机可读存储介质，其上存储有计算机程序指令，该程序指令被处理器执行时实现上述列车测试方法的步骤。

基于同一发明构思，本公开实施例提供一种电子设备，包括：

存储器，其上存储有计算机程序；

处理器，用于执行所述存储器中的所述计算机程序，以实现上述列车测试方法的步骤。

基于同一发明构思，本公开实施例提供一种列车测试系统，包括上述电子设备。

图7是根据一示例性实施例示出的一种电子设备700的框图，参照图7，电子设备700包括处理器701，其数量可以为一个或多个，以及存储器702，用于存储可由处理器701执行的计算机程序。存储器702中存储的计算机程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理器701可以被配置为执行该计算机程序，以执行上述的列车测试方法。

另外，电子设备700还可以包括电源组件705和通信组件703，该电源组件705可以被配置为执行电子设备700的电源管理，该通信组件703可以被配置为实现电子设备700的通信，例如，有线或无线通信。此外，该电子设备700还可以包括输入/输出（I/O）接口704。电子设备700可以操作基于存储在存储器702的操作系统，例如Windows Server

在另一示例性实施例中，还提供了一种包括程序指令的计算机可读存储介质，该程序指令被处理器执行时实现上述的列车测试方法的步骤。例如，该非临时性计算机可读存储介质可以为上述包括程序指令的存储器702，上述程序指令可由电子设备700的处理器701执行以完成上述的列车测试方法。

在另一示例性实施例中，还提供一种计算机程序产品，该计算机程序产品包含能够由可编程的装置执行的计算机程序，该计算机程序具有当由该可编程的装置执行时用于执行上述列车测试方法的代码部分。

以上结合附图详细描述了本公开的优选实施方式，但是，本公开并不限于上述实施方式中的具体细节，在本公开的技术构思范围内，可以对本公开的技术方案进行多种简单变型，这些简单变型均属于本公开的保护范围。

另外需要说明的是，在上述具体实施方式中所描述的各个具体技术特征，在不矛盾的情况下，可以通过任何合适的方式进行组合，为了避免不必要的重复，本公开对各种可能的组合方式不再另行说明。

此外，本公开的各种不同的实施方式之间也可以进行任意组合，只要其不违背本公开的思想，其同样应当视为本公开所公开的内容。