一种车辆的行车控制方法、装置及系统与流程

本申请涉及交通调度控制技术领域，具体地，涉及一种车辆的行车控制方法、装置及系统，本申请的车辆是指prt车辆；其中，个人快速运输系统(英语：personalrapidtransit，简称prt)，个人快速运输系统是轨道宽度为600mm以下的悬挂式交通系统。

背景技术：

个人快速运输系统，由于其独特的架空轨道和悬挂小型车辆结构，已然形成了全新的个人出行交通形式。与现有轨道交通站站停不同，个人快速运输系统强调专人专车、一站直达目的地，采用全自动无人驾驶方式，无人值守站台，实现24小时运营，是其他公共交通方式的有益补充和完善，在人性化、环境匹配、建设周期和成本等方面具有突出的优势。

个人快速运输系统特殊的功能定位与运营场景也必然使其乘车控制方法有别于现有轨道交通系统，目前现有轨道交通车辆的行车控制无法直接移植到这样一个全新的个人快速运输系统中。

因此，现有技术的不足在于，现有轨道交通车辆的行车控制不能适用于个人快速运输系统。

技术实现要素：

本申请实施例提供了一种车辆的行车控制方法、装置及系统，以解决现有轨道交通车辆的行车控制不能适用于个人快速运输系统的技术问题。

本申请实施例提供了一种车辆的行车控制方法，所述方法包括：

行车控制服务器确定出发站台的发车位停靠有空载车辆；

根据接收到的有效的上车指令，生成并发送发车位车辆的车门打开控制指令，以控制发车位车辆的车门打开；

根据接收到的包括目的站的发车指令，生成并发送包括目的站的行车控制指令，以控制发车位车辆行驶至目的站。

本申请实施例还提供了一种车辆的行车控制装置，所述装置包括：

确定模块，用于行车控制服务器确定出发站台的发车位停靠有空载车辆；

生成模块，用于根据接收到的有效的上车指令，生成并发送发车位车辆的车门打开控制指令，以控制发车位车辆的车门打开；

控制模块，用于根据接收到的包括目的站的发车指令，生成并发送包括目的站的行车控制指令，以控制发车位车辆行驶至目的站。

本申请实施例还提供了一种车辆的行车控制系统，其特征在于，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上所述的车辆的行车控制方法。

本申请实施例由于采用以上技术方案，具有以下技术效果：

本申请实施例所提供的车辆的行车控制方法，装置及系统，基于交通独特的系统特征及运营场景，在确定出发站台的发车位停靠有空载车辆后，根据接收到的有效的上车指令，生成并发送发车位车辆的车门打开控制指令，以控制发车位车辆的车门打开，并在乘客上车后，根据接收到的包括目的站的发车指令，生成并发送包括目的站的行车控制指令，以控制发车位车辆行驶至目的站。可见，通过将检票系统设置在车辆的行车控制服务器侧，无需站台人员及设施投入，实现全自动行车控制方法，以满足人们多元个性化的交通出行需求。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例的车辆的行车控制方法的流程示意图；

图2为本申请实施例中车辆的行车控制方法的架构示意图；

图3为本申请实施例中车辆的行车控制方法的流程示意图；

图4为本申请实施例中车辆的行车控制装置的结构示意图；

附图标记说明：

401确定模块，402生成模块，403控制模块。

具体实施方式

为了使本申请实施例中的技术方案及优点更加清楚明白，以下结合附图对本申请的示例性实施例进行进一步详细的说明，显然，所描述的实施例仅是本申请的一部分实施例，而不是所有实施例的穷举。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

实施例一

图1为本申请实施例的车辆的行车控制方法的流程示意图，图2为本申请实施例中车辆的行车控制方法的架构示意图。

如图1和图2所示，本申请实施例的车辆的行车控制方法，包括：

步骤s101，行车控制服务器确定出发站台的发车位停靠有空载车辆。

实施中，所述站台包括按照预设顺序排列的多个车位，车位中最靠前的为发车位。

实施中，行车控制服务器确定出发站台的发车位停靠有空载车辆的步骤之前，还包括如下步骤：

接收订车信息，其中，所述订车信息包括出发站台和上车时间；

根据出发站台和发车时间，以及各个车辆的位置信息和运行信息，生成并发送车辆调度指令，以控制车辆在发车时间之前的预设时间调度到出发站台。

具体实施中，乘客通过移动终端订车app，订车服务器组成的订票系统购票，通信服务器接收订车信息并转发至应用服务器(即行车控制服务器)，应用服务器根据订车信息中的出发站台和发车时间，以及各个车辆的位置信息和运行信息，生成包含出发站台的车辆调度指令，并经由通信服务器发送至待调度的目标车辆，以保证目标车辆能够在发车时间之前的预设时间行驶至出发站台。

具体实施中，乘客通过订车app或线下(站台)购买车票，发送购票请求至订车服务器，订车服务器根据购票请求确定购票支付成功后，根据购票请求中的出发站台和上车时间生成二维码车票并发送给订车app或站台显示屏，并将与购票请求对应的订车信息经通信服务器发送给应用服务器，以便应用服务器根据订车信息调度目标车辆至出发站台。可见，基于个人快速运输系统的运营特征，车辆的售票方式支持订车app约车功能，即乘客按照预设的出行时间(上车时间)乘车，也可以在站台设置售票机或站台人工售票。

其中，应用服务器根据当前站台的有效上车指令(对应有效的订车信息)和对应的上车时间，以及乘客的订车信息，确定在乘客的订车信息的上车时间之前，当前站台的有效上车指令数量，即排队人数并发送至订车app；根据接收到的当前站台的停车资源申请，预估即将到站的车辆的进站时间，并发送至订车app或站台显示屏。

需要说明的是，乘客在站台候车区按照排队顺序乘车，即先到先得，车辆与乘客的订车信息之间无强关联关系，即没有一个订车信息仅仅能和特定的一辆车辆对应的关系，用于上车指令输入的检票系统(信息阅读器，例如二维码阅读器)对车票的识别功能上，车票与车辆没有一一对应的关系，且支持站台排队乘车优先于订票app约车，即，即便超过订车信息中的上车时间，该订车信息仍为有效的订车信息，该上车时间用于保证在一定时间内，该出发站台的车辆数量与订车信息数量一致，即根据订车信息生成相应的调度指令，以保证车等人、乘客随到随发，而不是人等车。

根据实际应用场景的需求，当接收到来自乘客订车app的退票或改签请求后，将退票或改签请求发送至订车服务器，订车服务器将退票或改签请求经通信服务器转发至应用服务器，应用服务器在确定该退票或改签请求对应的上车指令处于有效状态时，根据退票请求，将处于有效状态的上车指令修改为无效，并发送退票成功信息给订车app；或者，根据改签请求，将处于有效状态的上车指令中的出发站台和上车时间修改为改签请求中改签的出发站台和上车时间，并发送改签成功信息给订车app。

实施中，根据接收到的上车指令和预存的有效上车指令，确定上车指令是否有效。

由于乘客得到的作为上车指令的电子车票，存在因退票或改签等等原因导致的失效的情况的存在，为了防止失效的上车指令对行车控制造成干扰，需要对上车指令是否有效进行确定。

实施中，所述上车指令通过信息阅读器输入，并经车辆的车载主机发送至行车控制服务器；

其中，所述信息阅读器设置在车辆的外侧，和/或发车位侧；

所述发车指令通过车辆内的车载人机接口输入，并经车辆的车载主机发送至行车控制服务器。

信息阅读器设置在车辆的外侧的方式，就是将信息阅读器直接设置在了车辆之上，如车辆的门口位置。即将作为检票用的信息阅读器直接设置在车辆上，不再需要设置单独的检票系统。

信息阅读器设置发车位侧，则采用的单独设置作为检票用的信息阅读器，即设置了单独的检票系统。

实施中，在行车控制服务器确定出发站台的发车位停靠有空载车辆之后，还包括如下步骤：

接收上车指令；

所述方法还包括如下步骤：

在行车控制服务器确定出发站台的发车位没有停靠空载车辆，拒绝接受上车指令。

即上车指令只有在行车控制服务器确定出发站台的发车位停靠有空载车辆之后才能被接收，原因在于上车指令会控制车辆的车门。

所述方法还包括如下步骤：

在接收有效的上车指令之后且未驶离发车位时，拒绝接收新的上车指令。

这样，就实现了一车仅仅能对应一电子车票，是个人快速运输系统直达目的站实现基础。

具体实施中，当目标车辆根据调度指令行驶至出发站台，并确定出发站台中按照预设顺序排列的多个车位存在空闲车位后，停靠在空闲车位中顺序最靠前的车位。当目标车辆停靠在发车位时，接收乘客扫码检票，即来自乘客的上车指令，上车指令对应乘客的二维码车票，上车指令经信息阅读器(二维码阅读器)，车载主机，通信服务器发送至应用服务器，以便应用服务器对接收到的上车指令进行有效性验证，具体为，从预存的该出发站台的有效上车指令中查询该上车指令，若查询到，则该上车指令为该出发站台的有效上车指令，反之，则该上车指令为该出发站台的无效上车指令，应用服务器不进行相应操作，或生成无效上车信息经信息阅读器进行显示。

根据实际应用场景的需求，对于检票方式，检票系统可以设置在车辆的外侧，和/或发车位侧，若检票系统在车辆的外侧，则在站台增加检票屏蔽设施，以便车辆到站清客后，车门能够保持打开状态，并在乘客完成站台检票后，自动乘车。

此外，为保证一票一车，每张车票对应一个运行任务，一个车辆在同一时段内只接收并执行一个运行任务，并一站直达目的站。因此，只有在出发站台的发车位停靠有空载车辆时，才接收上车指令，并在接收上车指令，且并未驶离发车位的时间内，将不再支持其他乘客进行检票(即扫描二维码车票)。可见，一车只针对一张车票进行上车指令响应，一站直达。根据实际应用场景的需求，空载车辆从停车位行驶至发车位的时间内，同样拒绝接收上车指令，以避免车辆未停靠时，有乘客急于上车导致人身安全受到威胁。

步骤s102，根据接收到的有效的上车指令，生成并发送发车位车辆的车门打开控制指令，以控制发车位车辆的车门打开。

具体实施中，当应用服务器确定接收到的上车指令有效后，生成发车位车辆的车门打开控制指令并经通信服务器发送至车辆的车载主机，以便车载主机将车门打开控制指令发送至车门控制器，车门控制器控制车门打开。

步骤s103，根据接收到的包括目的站的发车指令，生成并发送包括目的站的行车控制指令，以控制发车位车辆行驶至目的站。

本申请实施例的行车控制方法，在出发站台的发车位停靠有空载车辆的情况下，先根据接收到的有效的上车指令，生成并发送发车位车辆的车门打开控制指令，实现对发车位车辆的车门的打开，便于乘客上车，即实现了有效的上车指令对发车位车辆的车门的控制；之后，根据接收到的包括目的站的发车指令，生成并发送包括目的站的行车控制指令，控制发车位车辆行驶至目的站，即实现了发车指令对发车位车辆的行车控制。本申请实施例的车辆的行车控制方法，是基于有效的上车指令和发车指令对车辆实现了行车控制，而上车指令和发车指令都是由乘客发起，发送给行车控制服务器的，由此实现了以乘客为中心的车辆的形成控制方法，尤其适用于以乘客的个性化需求为中心的系统的车辆的行车控制。

作为一种可选的方式，根据接收到的包括目的站的发车指令，生成并发送包括目的站的行车控制指令的步骤，包括如下步骤：

在接收到包括目的站的发车指令后，生成并发送发车位车辆的车门关闭控制指令，以关闭发车位车辆的车门；

在发车位车辆的车门关闭后，生成并发送包括目的站的行车控制指令，以控制发车位车辆行驶至目的站。

这样，发车位车辆的车门关闭时间和实际发车时间，是由接收到发车指令的时间决定的，更加符合个性化的需求。乘坐同一辆车辆的乘客可能是一个也可能是多个，在乘坐同一辆车辆的乘客都上车后，就由乘客发出发车指令，即用于乘客上车的时间是一个由乘客自己决定的时间。

作为另一可选的方式，根据接收到的包括目的站的发车指令，生成并发送包括目的站的行车控制指令的步骤之前，还包括如下步骤：

在发车位车辆的车门打开达到预设时间后，生成并发送发车位车辆的车门关闭控制指令，以关闭车门。

这样，实现了发车位车辆的车门的自动关闭。

具体实施中，乘客上车坐稳后，利用车载人机接口(车载hmi屏幕)生成确认出行信息，或倒计时结束(均对应包含目的站的发车指令)后，经车载主机，通信服务器，发送至应用服务器，以便应用服务器根据该发车指令生成发车位车辆的车门关闭控制指令，并经通信服务器，车载主机，发送至车门控制器，以便车门控制器关闭发车位车辆的车门。同时，反馈车门关闭成功信息至应用服务器，以便应用服务器生成包括目的站的行车控制指令至车载主机，以便车载主机控制发车位车辆启动并行驶至目的站。

根据实际应用场景的需求，若乘客的订车信息中包括目的站，则根据订车信息中的订单标识，获取目的站，并发送至车载hmi屏幕，以便用户确认包含目的站的出行信息，或倒计时结束默认订车信息中的目的站。此外，乘客可以利用车载hmi屏幕输入目的站，并生成包含目的站的确认出行信息，即支持乘客上车后对出行信息进行确认，此处不对目的站信息的获取方式进行具体限定。

其中，在发车位车辆的车门打开时开始倒计时，并在车载hmi屏幕上进行显示，当计时为零时，生成并发送发车位车辆的车门关闭控制指令至应用服务器，以便应用服务器生成发车位车辆的车门关闭控制指令，并发送至车门控制器，以便车门控制器关闭发车位车辆的车门。

实施中，根据接收到的包括目的站的发车指令，生成并发送包括目的站的行车控制指令的步骤之后，还包括如下步骤：

在行驶的车辆行驶时，获取行驶的车辆的当前位置信息；

根据行驶的车辆的当前位置信息和发车指令中的目的站，确定距离目的站的长度，并发送至行驶的车辆的车载人机接口进行显示。

这样，乘客能够对距离目的站的长度进行实时的了解，使得乘客对整个行程有了解。

实施中，根据行驶的车辆的当前位置信息和发车指令的目的站，确定距离目的站的长度的步骤之后，还包括如下步骤：

获取行驶的车辆的运行速度；

根据距离目的站的长度和所述运行速度，计算出预计到达时间，并发送至车辆的车载人机接口进行显示。

这样，乘客能够对预计到达时间进行了解，便于乘客对后续时间和行程的安排。

具体实施中，车辆的车载主机接收来自速度传感器的速度信息，确定车辆已启动运行，进一步车载主机接收来自轨旁信标的信标标识，确定车辆的当前位置并发送至应用服务器，以便应用服务器根据车辆的当前位置和发车指令中的目的站，确定主轨道的轨道路线，从而确定该轨道路线对应的距离目的站的长度，并发送至车辆的车载人机接口(车载hmi屏幕)进行显示。

此外，车辆的车载主机继续接收来自速度传感器的速度信息并发送至应用服务器，以便应用服务器确定车辆的当前运行速度或平均运行速度，并进一步根据确定的当前距离目的站的长度，计算出预计到达时间，并发送至车辆的车载人机接口进行显示。

与现有公交、地铁等基于购票场景的行车控制方法相比，通过应用本实施例提供的方法，基于个人快速运输系统特征及运营场景需求，智能化检票、乘车，并支持车等人、乘客随到随发，而不是人等车，可见，基于车辆的交通出行方式极大地满足了人们多元个性化的出行需求。

为了便于本申请的实施，下面以具体实例进行说明。

图3示出了本申请实施例中车辆的行车控制方法的流程示意图，包括：

步骤s301，乘客app订票。通过乘客移动终端订车app输入出行需求(对应购票请求)，包括出发站台，上车时间等，并在订车服务器确认支付成功后生成订车信息经通信服务器转发发送至应用服务器，执行步骤s303，同时根据订车信息生成二维码车票，并返回给乘客移动终端。

步骤s302，支持退票或改签。若接收到来自乘客移动终端订车app的退票请求，则直接结束流程；若接收到来自乘客移动终端订车app的改签请求，则执行步骤s303。

步骤s303，是否生成车辆调度指令。应用服务器根据接收到的订车信息或改签请求中的上车时间，以及当前无运行任务的车辆的位置信息和运行信息，确定是否生成车辆调度指令，若需要生成车辆调度指令，则执行步骤s304，若不需要生成车辆调度指令，则执行步骤s305。

步骤s304，车辆到站等待。车辆的车载主机接收经通信服务器转发的来自应用服务器的车辆调度指令，根据接收到的车辆调度指令，控制车辆行驶至相应站台，等待用车。

步骤s305，乘客扫码检票。当车辆处于发车位时，利用站台侧的二维码阅读器扫描乘客移动终端订车app中的二维码车票，完成扫码检票。

步骤s306，车票有效性验证。应用服务器对车辆的车载主机接收到的来自二维码阅读器的上车指令(对应二维码车票)进行有效性验证，若上车指令有效，则执行步骤s307，若上车指令无效，则执行步骤s309。

步骤s307，车门开启。若上车指令有效，则应用服务器生成发车位车辆的车门打开控制指令并发送至车门控制器，以使车门控制器根据发车位车辆的车门打开控制指令控制车门开启。

步骤s308，乘客确认/一定时间。乘客上车后通过hmi界面输入确认出行信息，经车辆的车载主机发送至应用服务器，以便应用服务器接收到确认出行信息，或确定距离车门开启达到一定时间后，执行步骤s309。

步骤s309，车门关闭。当应用服务器接收到确认出行信息，或确定距离车门开启达到一定时间后，生成发车位车辆的车门关闭控制指令并发送至车门控制器，以使车门控制器根据发车位车辆的车门关闭控制指令控制车门关闭；若上车指令无效，则保持车辆车门关闭。

步骤s310，车辆运行至目的站。应用服务器根据接收到的确认出行信息(发车指令)确定目的站，并根据目的站生成路径规划信息，以便将该路径规划信息发送至车载主机，以便车载主机按照该路径规划信息控制车辆运行至该目的站。

基于同一申请构思，本申请实施例中还提供了一种车辆的行车控制装置，由于这些设备解决问题的原理与一种车辆的行车控制方法相似，因此这些设备的实施可以参见方法的实施，重复之处不再赘述。

如图4所示，本申请实施例的车辆的行车控制装置，包括：

确定模块401，用于行车控制服务器确定出发站台的发车位停靠有空载车辆。

实施中，所述站台包括按照预设顺序排列的多个车位，车位中最靠前的为发车位。

生成模块402，用于根据接收到的有效的上车指令，生成并发送发车位车辆的车门打开控制指令，以控制发车位车辆的车门打开。

实施中，所述上车指令通过信息阅读器输入，并经车辆的车载主机发送至行车控制服务器；

其中，所述信息阅读器设置在车辆的外侧，和/或发车位侧；

所述发车指令通过车辆内的车载人机接口输入，并经车辆的车载主机发送至行车控制服务器。

控制模块403，用于根据接收到的包括目的站的发车指令，生成并发送包括目的站的行车控制指令，以控制发车位车辆行驶至目的站。

实施中，所述控制模块403，包括：

关门控制单元，用于在接收到包括目的站的发车指令后，生成并发送发车位车辆的车门关闭控制指令，以关闭发车位车辆的车门；

行车控制单元，用于在发车位车辆的车门关闭后，生成并发送包括目的站的行车控制指令，以控制发车位车辆行驶至目的站。

实施中，还包括：

关门控制模块，用于在发车位车辆的车门打开达到预设时间后，生成并发送发车位车辆的车门关闭控制指令，以关闭车门。

实施中，还包括：

调度控制模块，用于接收订车信息，其中，所述订车信息包括出发站台和上车时间；以及，

根据出发站台和发车时间，以及各个车辆的位置信息和运行信息，生成并发送车辆调度指令，以控制车辆在发车时间之前的预设时间调度到出发站台。

实施中，还包括：

判断模块，用于根据接收到的上车指令和预存的有效上车指令，确定上车指令是否有效。

实施中，还包括：

显示模块，用于在行驶的车辆行驶时，获取行驶的车辆的当前位置信息；以及，

根据行驶的车辆的当前位置信息和发车指令中的目的站，确定距离目的站的长度，并发送至行驶的车辆的车载人机接口进行显示。

实施中，所述显示模块，还用于：

获取行驶的车辆的运行速度；

根据距离目的站的长度和所述运行速度，计算出预计到达时间，并发送至车辆的车载人机接口进行显示。

实施中，还包括：

接收模块，用于在出发站台的发车位停靠有空载车辆时，接收上车指令；以及，

还用于在行车控制服务器确定出发站台的发车位没有停靠空载车辆，拒绝接受上车指令，

以及用于在接收有效的上车指令之后且未驶离发车位时，拒绝接收新的上车指令。

基于同一发明构思，本申请实施例中还提供了一种车辆的行车控制系统，由于这些设备解决问题的原理与一种车辆的行车控制方法，一种车辆的行车控制装置相似，因此这些设备的实施可以参见方法的实施，重复之处不再赘述。

所述车辆的行车控制系统，可以包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上所述的车辆的行车控制方法。

实施中，车辆的行车控制系统包括订车app，订车服务器，通信服务器，应用服务器，车载主机，二维码阅读器，车门控制器，车载hmi。

为了描述的方便，以上所述装置的各部分以功能分为各种模块或单元分别描述。当然，在实施本申请时可以把各模块或单元的功能在同一个或多个软件或硬件中实现。

本领域内的技术人员应明白，本申请的实施例可提供为方法，系统，或计算机程序产品。因此，本申请可采用完全硬件实施例，完全软件实施例，或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器，cd-rom，光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法，设备(系统)，和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框，以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机，专用计算机，嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。