CN113627743B - 一种公交车辆协同调度的方法及设备 - Google Patents

Abstract

本申请涉及公共交通技术领域，提供一种公交车辆协同调度的方法及设备，考虑到多条公交路线共同拥有的共有站点的客流量较大的特点，针对每一个共有站点，按照共有站点在当前时段对应的预设检测频率，获取当前时刻共有站点已停靠的车辆数量，若已停靠的车辆数量大于预设标准泊位数量，侧检测到共有站点发生车辆聚集事件，在满足车辆聚集事件的第一预设结束条件之前，持续向将要停靠共有站点的进站车辆发送提醒消息以协同调度进站车辆，从而减少因共有站点客流量较大导致车辆拥堵的情况，并且向将要停靠该共有站点的车辆发送了消息提醒以调度进站车辆，可以快速缓解车辆聚集事件，提高车辆调度的合理性。

Description

一种公交车辆协同调度的方法及设备

技术领域

本申请涉及公共交通技术领域，尤其涉及一种公交车辆协同调度的方法及设备。

背景技术

城市建设规划中，对于客流出行较大的公交线路，一般设置的车辆资源较多，因此，停靠同一个站点的车辆数较多，导致站外车辆无法进站停靠，或者站内停靠车辆由于站台拥堵无法出站等一系列问题，造成乘客出行体验差。

目前，车辆资源大多是基于公交线路协同调度的，而各个公交线路的车辆资源存在交叉，且各个公交线路之间的运营调度又互相独立，导致调度过程各个公交线路上的车辆资源容易发生聚集，引发路况拥堵。

发明内容

本申请实施例提供了一种公交车辆协同调度方法及设备，用以减少公交线路运营过程中的车辆聚集事件，提高车辆调度的合理性。

第一方面，本申请实施例提供一种公交车辆协同调度方法，应用于调度客户端，包括：

针对多条公交线路共同拥有的每一个共有站点，按照所述共有站点在当前时段对应的预设检测频率，获取当前时刻所述共有站点已停靠的车辆数量；其中，所述预设检测频率和经过所述共有站点的公交路线的数量呈正相关，且同一共有站点在不同时段对应的预设检测频率不同；

若获取的已停靠的车辆数量大于预设标准泊位数量，则检测到所述共有站点发生车辆聚集事件，在满足所述车辆聚集事件的第一预设结束条件之前，持续向将要停靠所述共有站点的进站车辆发送提醒消息以协同调度所述进站车辆。

上述实施例中，考虑到多条公交路线的共有站点的客流量较大，因此针对每一个共有站点，按照共有站点在当前时段对应的预设检测频率，获取当前时刻共有站点已停靠的车辆数量，并与预设标准泊位数量进行比较，根据比较结果检测是否发生车辆聚集事件，在共有站点发生车辆聚集事件时，在满足车辆聚集事件的第一预设结束条件之前，持续向将要停靠共有站点的进站车辆发送提醒消息以协同调度进站车辆，从而减少因共有站点车辆资源较多导致车辆拥堵的情况，并且向将要停靠该共有站点的车辆发送了消息提醒以调度进站车辆，可以快速缓解车辆聚集事件，提高车辆调度的合理性。

可选的，所述第一预设结束条件包括：

已停靠所述共有站点的车辆数量不大于预设标准泊位数量；或者

在所述车辆聚集事件的第一有效期内，未再次检测到车辆聚集事件。

上述实施例中，第一预设结束条件为已停靠所述共有站点的车辆数量不大于预设标准泊位数量时，根据当前的检测结果实时对车辆进行调度以减缓车辆拥堵状态，并且考虑到车辆聚集事件的持续性，第一预设结束条件还可以为在所述车辆聚集事件的第一有效期内，未再次检测到车辆聚集事件，从而减少下发提醒消息的次数。

可选的，在所述车辆聚集事件的第一有效期内，若再次检测到车辆聚集事件，则根据再次检测到的车辆聚集事件的时间，更新所述第一有效期。

上述实施例中，根据第一有效期内再次检测到的车辆聚集事件更新第一有效期，可准确确定车辆聚集事件的持续时间。

可选的，所述根据再次检测到的车辆聚集事件的时间，更新所述第一有效期，包括：

将再次检测到的车辆聚集事件的时间，与预设的初始有效期的和，确定为所述车辆聚集事件的第一有效期。

上述实施例中，公开了更新第一有效期的具体方式。

可选的，检测所述共有站点是否发生车辆聚集事件的过程中，还包括：

获取所述共有站点已关联的车辆上传的车辆数据；

当所述车辆数据发生变化时，更新进出所述共有站点的车辆明细记录；

根据更新后的车辆明细记录，更新当前时刻已停靠所述共有站点的车辆数量。

上述实施例中，在车辆上传的车辆数据发生变化时，更新车辆明细记录，进一步地，根据更新后的车辆明细记录更新共有站点已停靠的车辆数量，从而提高了车辆聚集事件检测结果的准确性。

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

获取预测时段内，预测得到的进出所述共有站点的车辆数据，所述预测时段为参考车辆预计到达所述共有站点所需的时间；

根据所述已停靠的车辆数量以及预测得到的车辆数据，预测所述参考车辆到达所述共有站点时，是否发生车辆聚集事件；

若预测发生车辆聚集事件，则在预测满足车辆聚集事件的第二预设结束条件之前，持续向预测得到的将要进入所述共有站点的进站车辆发送提醒消息。

上述实施例中，通过对车辆聚集事件的预测，提前做好车辆预警工作，从而避免共有站点发生车辆聚集事件，提高车辆调度的合理性。

可选的，所述第二预设结束条件包括：

预测到所述共有站点已停靠的车辆数量不大于预设标准泊位数量；或者

在预测到的车辆聚集事件的第二有效期内，未再次预测到车辆聚集事件。

上述实施例中，第二预设结束条件为预测到所述共有站点已停靠的车辆数量不大于预设标准泊位数量时，根据当前的预测结果实时对车辆进行调度以避免发生车辆拥堵，并且考虑到车辆聚集事件的持续性，第二预设结束条件还可以为在预测到的车辆聚集事件的第二有效期内，未再次预测到车辆聚集事件，从而减少下发提醒消息的次数。

可选的，在预测到的车辆聚集事件的第二有效期内，若再次预测到车辆聚集事件，则根据再次预测到的车辆聚集事件的时间，更新所述第二有效期。

上述实施例中，根据第二有效期内再次预测到的车辆聚集事件更新第二有效期，可准确预测车辆聚集事件的持续时间。

可选的，所述共有站点的换乘人数大于预设的换乘阈值。

上述实施例中，考虑共有站点客流量的多少，仅对换乘人数大于换乘阈值的共有站点进行车辆聚集事件的检测，降低资源消耗，提高检测效率。

第二方面，本申请实施例提供一种调度客户端，包括：

获取模块，用于针对多条公交线路共同拥有的每一个共有站点，按照所述共有站点在当前时段对应的预设检测频率，获取当前时刻所述共有站点已停靠的车辆数量；其中，所述预设检测频率和经过所述共有站点的公交路线的数量呈正相关，且同一共有站点在不同时段对应的预设检测频率不同；

检测模块，用于检测获取的已停靠的车辆数量是否大于预设标准泊位数量，若是，则检测到所述共有站点发生车辆聚集事件；

告警模块，用于在满足所述车辆聚集事件的第一预设结束条件之前，持续向将要停靠所述共有站点的进站车辆发送提醒消息以协同调度所述进站车辆。

第三方面，本申请提供一种计算机可读存储介质，计算机可读存储介质存储有计算机可执行指令，计算机可执行指令用于使计算机执行本申请实施例提供的公交车辆协同调度方法。

附图说明

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

图1示例性示出了本申请的实施例提供的系统架构图；

图2示例性示出了本申请的实施例提供的公交廊道示意图；

图3示例性示出了本申请的实施例提供的主干道设置示意图；

图4示例性示出了本申请的实施例提供的公交廊道协同调度方法流程图；

图5示例性示出了本申请实施例提供的更新共有站点的车辆数量示意图；

图6示例性示出了本申请实施例提供的共有站点的检测结果示意图；

图7示例性示出了本申请实施例提供的共有站点的另一检测结果示意图；

图8示例性示出了本申请的实施例提供的预测车辆聚集事件的方法流程图；

图9示例性示出了本申请的实施例提供的预测时段设置示意图；

图10示例性示出了本申请的实施例提供的公交廊道协同调度的界面图；

图11示例性示出了本申请的实施例提供的调度客户端的架构图。

具体实施方式

为使本申请的目的、实施方式和优点更加清楚，下面将结合本申请示例性实施例中的附图，对本申请示例性实施方式进行清楚、完整地描述，显然，所描述的示例性实施例仅是本申请一部分实施例，而不是全部的实施例。

基于本申请描述的示例性实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请所附权利要求保护的范围。此外，虽然本申请中公开内容按照示范性一个或几个实例来介绍，但应理解，可以就这些公开内容的各个方面也可以单独构成一个完整实施方式。

本申请中说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”等是用于区别类似或同类的对象或实体，而不必然意味着限定特定的顺序或先后次序，除非另外注明。应该理解这样使用的用语在适当情况下可以互换，例如能够根据本申请实施例图示或描述中给出那些以外的顺序实施。

此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖但不排他的包含，例如，包含了一系列组件的产品或设备不必限于清楚地列出的那些组件，而是可包括没有清楚地列出的或对于这些产品或设备固有的其它组件。

下面结合附图详细描述本申请的实施例。

图1示例性示出了本申请实施例提供的一种系统架构图，该系统架构可以包括计划客户端100、调度客户端200、公交服务中心300、车载终端400和数据库500。

其中，计划客户端100用于编制发车计划；调度客户端200加载发车计划执行发车调度，同时根据车辆位置和上报的数据进行车辆运行监控以及发车时刻调整等业务。公交服务中心300用于车载终端400和调度客户端200的数据交换以及车辆前后位置计算；车载终端400安装于公交车上，带有GPS模块和移动通信模块，通过3G/4G/5G等无线网络向后台上传车辆位置及报站等数据，并接收调度客户端200的发车指令等信息；数据库500用于存放线路、站点、车辆等基础数据以及它们的关系，同时存储用于发车的计划数据以及实际执行的发车数据等业务数据。

需要说明的是，上述图1所示的结构仅是一种示例，本发明实施例对此不做限定。

如图2所示，站1、站2和站3均可停靠126路和10路公交线路，站1、站2和站3为126路和10路公交线路的共有站点，乘客可在这三站进行换乘，客流较大。

本申请的实施例中，可将多条公交线路共同拥有多个共有站点的路段作为一个主干道。如图2示出的，站1至站3之间的路段作为主干道。

与实际公交线路营运一致，主干道也分为上行线路和下行线路、环形线路等。

在实际应用过程中，主干道上的共有站点也可以有其他的公交线路加入，如图3所示，在站2加入了232路公交线路，但是为了描述便捷，通常将主干道上行的开始和结束站点定义为站1和站3，而下行正好反过来(上下行表示车辆运行方向)。

本申请的实施例中，计划客户端编制发车计划。一般的，在满足多条公交线路各自发车间隔的前提下，使经过共有站点的不同公交线路车辆先后到达该站点，从而减少乘客换乘时的候车时长，并且还能有效降低该站点的停车拥挤度，有利于道路通行和安全，提升乘客出行体验。

由于一条公交线路上很多个共有站点都是换乘站点，因此，在编制行车计划时除了要控制车辆从首站出发和到末站结束的时间，还要控制车辆到达换乘站点的时间，使多条公交线路的车辆先后交错到达换乘站点，并保持换乘车辆的到达时间晚于当前停靠车辆的离开时间，从而控制多条公交线路的车辆在换乘站点均匀分布运行。

但在实际运行过程中，因为路况、红绿灯等其他因素，导致车辆并不能按照编制的发车计划均匀的进出换乘站点，导致车辆在共有站点发生车辆聚集事件，有的车辆无法停靠，有的车辆无法出站，严重影响乘客出行体验。

为了解决上述问题，本申请实施例提供一种公交车辆协同调度的方法及设备，针对多条公交线路共同拥有的每一个共有站点，实时检测是否在共有站点发生车辆聚集事件，若发生，则在满足车辆聚集事件的预设结束条件之前，持续向将要进站的车辆发送提醒消息以协同调度进站车辆，通过实时检测车辆聚集事件来合理的调度进站车辆，从而减少车辆聚集事件。

可选的，本申请的一些实施例中，计划客户端可基于共有站点的换乘人数编制发车计划。具体的，为经过换乘人数大于预设的换乘阈值的共有站点的多条公交线路编制发车计划。相应的，为了降低调度客户端的资源消耗，提高车辆聚集事件的检测效率，调度客户端仅就换乘人数大于换乘阈值的共有站点进行车辆聚集事件检测。

图4详细的示出了本发明实施例提供的一种公交廊道协同调度方法的流程，该流程可以由调度客户端执行。如图4所示，该流程具体包括：

S401：针对多条公交线路共同拥有的每一个共有站点，按照共有站点在当前时段对应的预设检测频率，获取当前时刻共有站点已停靠的车辆数量。

该步骤中，考虑到共有站点客流量较大的特点，以多条公交路线上的共有站点的路况进行车辆调度，相对于基于各个公交线路独立调度车辆的运行，提高了调度的合理性。

在S401中，预设检测频率和经过共有站点的公交路线的数量呈正相关，且同一共有站点在不同时段对应的预设检测频率不同。

例如，在早高峰7:00-9:00时段，设定共有站点1的检测频率为每分钟6次，即每10秒获取一次共有站点1已停靠的车辆数量，在平峰9:00-12:00时段，设定共有站点1的检测频率为每分钟2次，即每30秒获取一次共有站点1已停靠的车辆数量，在低峰12:00-4:00时段，设定共有站点1的检测频率为每分钟1次，即每60秒获取一次共有站点1已停靠的车辆数量。

再例如，假设经过共有站点1的公交路线为10路和126路，经过共有站点2的公交路线为10路、126路和232路，则设置共有站点1对应的检测频率为每分钟2次，设置共有站点2对应的检测频率为每分钟6次，也就是说，经过共有站点的公交路线的数量越多，获取共有站点已停靠的车辆数量的次数越多，进一步地，车辆聚集事件的检测频率越高。

S402：确定获取的已停靠的车辆数量是否大于预设标准泊位数量，若是，则执行S403，否则继续进行检测。

该步骤中，基于共有站点的预设范围内已停靠的车辆数量与预设标准泊位数量的比较结果，检测共有站点是否发生车辆聚集事件。具体的，获取当前时刻已停靠共有站点的车辆数量，若已停靠的车辆数量大于预设标准泊位数量，则检测到共有站点发生车辆聚集事件，否则共有站点发生未发生车辆聚集事件。

本申请的实施例中，由于公交车辆处于动态的运行状态，每个共有站点停靠的车辆数量随着车辆的运动而实时变化，因此，在检测共有站点是否发生车辆聚集事件的同时，可实时更新每个共有站点的车辆数量。

如图1示出的，公交车辆上安装的车载终端带有GPS模块和移动通信模块，通过3G/4G/5G等无线网络实时向后台上传车辆位置信息、所到站点信息等，基于上传的信息，实时更新共有站点的车辆数量。针对多条公交线路共同拥有的每一个共有站点，调度客户端获取共有站点已关联车辆的位置信息，根据获取的位置信息，更新当前时间共有站点已停靠车辆的数量。

图5为本申请实施例提供的更新共有站点的车辆数量示意图，如图5所示，共有站点拥有进站检测点和出站检测点，当车辆进入进站检测点时上传公交车辆的GPS信息，将上传的GPS信息与共有站点的GPS信息进行匹配，匹配成功则确定该公交车辆为进站车辆，同理，当车辆进入出站检测点时上传公交车辆的GPS信息，将上传的GPS信息与共有站点的GPS信息进行匹配，匹配成功则确定该公交车辆为出站车辆。可选的，为了避免车辆聚集事件，可扩大共有站点车辆聚集事件的检测范围，如图5中虚线范围所示，当车辆进入扩大后的聚集检测点时，上传车辆的GPS信息，根据该GPS信息可确定车辆到达共有站点附近，以便及时进行聚集事件预警工作。

S403：在满足车辆聚集事件的第一预设结束条件之前，持续向将要停靠共有站点的进站车辆发送提醒消息以协同调度进站车辆。

该步骤中，当检测到发生车辆聚集事件时，表明共有站点已停靠的车辆数量超过了预设标准泊位数量，站台处于拥堵状态，应减少进入共有站点的车辆数量，在拥堵状态消散前，向将要进站的车辆发送提醒消息，以使将要停靠的车辆降低速度以延迟进站时间。其中，将要停靠的进站车辆可以为与共有站点的距离小于设定距离阈值的车辆，也可以为共有站点与前一站点(包括共有站点和单独站点)之间的车辆，还可以为应经过共有站点但未进站的全部车辆。

在S403中，车辆聚集事件的第一预设结束条件包括已停靠共有站点的车辆数量不大于预设标准泊位数量，此时，表明共有站点不再拥堵，无需下发消息提醒，调度客户端按加载的编制车辆计划正常调度车辆运行即可。

图6为某一共有站点的检测时间轴及检测结果，其中″√″表示检测到车辆聚集事件，″×″表示未检测到车辆聚集事件，假设调度客户端每隔10秒检测一次是否发车辆聚集事件，该共有站点的预设标准泊位数量为3，在第1个10S，检测到已停靠共有站点的车辆数量为4，大于预设标准泊位数量，车辆聚集事件A开始，并开始向将要停靠共有站点的进站车辆发送提醒消息，在第2个10S，车辆聚集事件A仍在继续，继续向将要停靠共有站点的进站车辆发送提醒消息，在第3个10S，检测到已停靠共有站点的车辆数量为2，小于预设标准泊位数量，满足车辆聚集事件A的第一预设结束条件，车辆聚集事件A结束，则停止向将要停靠共有站点的进站车辆发送提醒消息，在第4个至第6个10S，检测到已停靠共有站点的车辆数量均不大于预设标准泊位数量，未发生车辆聚集事件，无需向将要停靠共有站点的进站车辆发送提醒消息，在第7个10S，检测到已停靠共有站点的车辆数量为5，大于预设标准泊位数量，车辆聚集事件B开始，开始向将要停靠共有站点的进站车辆发送提醒消息，在第8个10S，检测到已停靠共有站点的车辆数量为3，等于预设标准泊位数量，满足车辆聚集事件B的第一预设结束条件，车辆聚集事件B结束，则停止向将要停靠共有站点的进站车辆发送提醒消息。后续检测过程及检测结果类似，在此不再重复描述。

为了防止频繁的下发提醒消息，可设置车辆聚集事件的有效期，对有效期内检测到的车辆聚集事件进行合并，并根据有效期内检测到的车辆聚集事件的时间，更新车辆聚集事件的有效期，即更新车辆聚集事件的持续时间。其中，可基于检测车辆聚集的时间，确定事件合并的时间间隔，该时间间隔可作为车辆聚集事件的初始有效期。

可选的，在S403中，车辆聚集事件的第一预设结束条件还包括在车辆聚集事件的第一有效期内，未再次检测到车辆聚集事件。在车辆聚集事件的第一有效期内，若再次检测到车辆聚集事件，则根据再次检测到的车辆聚集事件的时间，更新第一有效期。具体的，将再次检测到的车辆聚集事件的时间，与初始有效期的和，确定为车辆聚集事件的第一有效期。

如图7所示，为车辆聚集事件合并后的调度示意图，其中″√″表示检测到车辆聚集事件，″×″表示未检测到车辆聚集事件。假设调度客户端每隔10秒检测一次是否发车辆聚集事件，时间间隔(初始有效期)为60秒。在第1个10S，检测车辆聚集事件D开始，并开始向将要停靠共有站点的进站车辆发送提醒消息，在第2个10S，检测得到的车辆聚集事件记为D’，由于D’为D的初始有效期内检测到的车辆聚集事件，因此，将车辆聚集事件D’合并为车辆聚集事件D，即认为D’和D为同一车辆聚集事件，D仍在继续，此时，D的第一有效期为70S(10S+60S)，在第3个10S，未检测到车辆聚集事件，但由于第3个10S仍位于车辆聚集事件D的第一有效期内，因此，认为车辆聚集事件D没有结束，继续向将要停靠共有站点的进站车辆发送提醒消息，第4个10S也位于车辆聚集事件D的第一有效期内，因此，还要继续向将要停靠共有站点的进站车辆发送提醒消息，在第5个10S，又检测到一车辆聚集事件D”，由于D”为D的第一初始有效期内检测到的车辆聚集事件，因此，将车辆聚集事件D”合并为车辆聚集事件D，即认为D”和D为同一车辆聚集事件，D仍在继续，根据D”更新D的第一有效期，更新后为110S(50S+60S)，在第6-10个10S均未检测到车辆聚集事件，即在更新后的第一有效期(110S)内，未检测到车辆聚集事件，因此，车辆聚集事件D结束并停止向将要停靠共有站点的进站车辆发送提醒消息。在13个10S，超过了车辆聚集事件D的第一有效期110S，因此，认为新的车辆聚集事件开始，记为车辆聚集事件E，并开始向将要停靠共有站点的进站车辆发送提醒消息，同理，在车辆聚集事件E的第一有效期内继续按设定的事件检测频率检测车辆聚集事件，与D类似，在此不再重复。

本申请的实施例中，公交车辆运行的过程中，车载终端实时上传车辆的位置信息、进站车辆的ID、进站时间、出站车辆的ID、出站时间、与其他进出站车辆的间距等车辆数据。调度客户端在检测是否发生车辆聚集的过程中，还会基于共有站点已关联的车辆上传的车辆数据，更新该共有站点的车辆明细记录，基于更新后的车辆明细记录，实时更新该共有站点已停靠的车辆数量，从而提高车辆聚集事件检测的准确性。

需要说明的是，只有在获取的共有站点的车辆数据发生变化时，才更新车辆明细记录，若只是检测时间发生了变化，则无需更新记录。

例如，在第1个10S，检测到已停靠共有站点的车辆为10路、210路、54路、625路，数量大于预设标准泊位数量，车辆聚集事件开始，在第2个10S，检测到已停靠共有站点的车辆为34路、210路、54路、625路，数量大于预设标准泊位数量，虽然车辆聚集事件仍在继续，但由于共有站点停靠的车辆发生了变化(10路出站、34路进站)，则调度客户端将更新共有站点的车辆明细记录。

又例如，在第1个10S，检测到已停靠共有站点的车辆为10路、210路、54路、625路，数量大于预设标准泊位数量，车辆聚集事件开始，在第2个10S，检测到已停靠共有站点的车辆为10路、210路、54路、625路，数量大于预设标准泊位数量，车辆聚集事件仍在继续，但由于共有站点停靠的车辆未发生了变化，则调度客户端无需更新共有站点的车辆明细记录。

可选的，本申请实施例中共有站点的换乘人数大于预设的换乘阈值。

本申请的上述实施例中，针对计划客户端针对各公交路线独立编制的发车计划，调度客户端考虑了考虑到共有站点客流量较大的特点，在共有站点换乘时容易产生车辆聚集，因此，以共有站点的路况为依据进行车辆调度，防止发生车辆聚集，提高了调度的合理性，并且，对运行过程中实际发生的车辆聚集事件进行检测，在发生车辆聚集时，及时告知将要停靠共有站点的车辆，以使将要停靠的车辆降低速度以延迟进行时间，缓解车辆的拥堵程度，避免车辆聚集事件的发生，提高了乘客的出行效率。

本申请的实施例中，针对多条公交线路共同拥有的每一个共有站点，除实时检测车辆的聚集事件外，还可对车辆聚集事件进行预测，以防止车辆聚集事件的发生。具体流程参见图8：

S801：获取预测时段内，预测得到的进出共有站点的车辆数据。

该步骤中，从经过共有站点的多条公交线路中选取一个参考车辆，将参考车辆预计到达共有站点所需的时间确定为预测时段。

如图9所示，假设对站1、站2、站3的车辆聚集事件进行预测，选取车1为参考车辆，以当前时间作为开始，将车1预计到达站1所需的时间作为预测时段1，将车1从站1预计到达站2所需的时间作为预测时段2，将车1从站2预计到达站3所需的时间作为预测时段3。

本申请实施例中，对参考车辆的选取不做限制性要求，可为未达到所要预测的共有站点的任一公交车辆。例如，还可以以图9中的车辆2为参考车辆，预测站1、站2、站3在未来是否会发生车辆聚集事件，还可以以图9中车辆4为参考车辆，预测站3在未来是否会发生车辆聚集事件。

在S801中，调度客户端根据当前时刻共有站点已停靠的车辆数量，以及在预测时段内，预测到的已停靠车辆的出站数量以及预计出站时间，以及进入共有站点的车辆的数量以及预计进站时间，得到进出共有站点的车辆数据。

S802：根据已停靠的车辆数量以及预测得到的车辆数据，预测参考车辆到达共有站点时，是否发生车辆聚集事件，若预测到发生车辆聚集事件，执行S803，否则继续进行预测。

该步骤中，基于当前时刻共有站点已停靠的车辆数量、预测出站的车辆数量、预测进站的车辆数量、相应车辆的预计出站时间、相应车辆的预计进站时间，预测参考车辆到达共有站点时，共有车站的停靠车辆数量，并将预测的停靠车辆数量与预设标准泊位数量进行比较，若预测的停靠车辆数量大于预设标准泊位数量，则预测发生车辆聚集事件，否则，预测不会发生车辆聚集事件。

S803：在预测满足车辆聚集事件的第二预设结束条件之前，向预测得到的将要进入共有站点的进站车辆发送提醒消息。

该步骤中，在预测到发生测量聚集事件时，可采取相应的调整措施以避免在未来发生车辆聚集事件，具体的，在预测满足车辆聚集事件的第二预设结束条件之前，向将要进入共有站点的进站车辆下发提醒消息，以使将要进站的车辆降低速度以延迟进站时间，从而避免发生车辆拥堵。

本申请的实施例中，预测到发生车辆聚集事件后，按照设定的预测频率，持续进行预测，与检测车辆聚集事件是否发生类似，预测的车辆聚集事件可能也是持续的。

在S803中，车辆聚集事件的第二预设结束条件包括在参考车辆到达共有站点时，预测到共有站点已停靠的车辆数量不大于预设标准泊位数量。

假设每10秒进行一次预测，共有站点的预设标准泊位数量为3，预测结果如表1所示，基于表1的预测结果，进行车辆调度的调整。

表1车辆聚集事件的预测结果

由表1可知，当预测到参考车辆到达共有站点时，共有站点已停靠的车辆数量不大于预设标准泊位数量，表明参考车辆到达共有站点时，不会发生车辆拥堵，无需向将要进站的车辆发送提醒消息，调度客户端按已编制的发车计划正常调控公交车辆即可。当预测到参考车辆到达共有站点时，共有站点已停靠的车辆数量大于预设标准泊位数量，表明参考车辆到达共有站点时，会发生车辆拥堵，可向将要进站的车辆发送提醒消息，以使将要进站的车辆延迟进站时间，从而避免车辆聚集事件。

为了防止频繁的下发提醒消息，可设置预测到的车辆聚集事件的预测有效期，对预测有效期内预测到的车辆聚集事件进行合并，并根据预测有效期内预测到的车辆聚集事件的时间，更新预测的车辆聚集事件的预测有效期，即更新预测的车辆聚集事件的持续时间。其中，可基于预测车辆聚集的时间，确定预测事件合并的时间间隔，该时间间隔可作为预测的车辆聚集事件的初始有效期。

可选的，在S803中，车辆聚集事件的第二预设结束条件还包括在预测到的车辆聚集事件的第二有效期内，未再次预测到车辆聚集事件。在预测到的车辆聚集事件的第二有效期内，若再次预测到车辆聚集事件，则根据再次预测到的车辆聚集事件的时间，更新第二有效期。具体的，将再次预测到的车辆聚集事件的时间，与初始有效期的和，确定为车辆聚集事件的第二有效期。

假设预测到的车辆聚集事件的初始有效期为30秒，具体预测结果参见表2。

表2车辆聚集事件的预测结果

如表2所示，在11:00:00预测到车辆聚集事件F开始，在11:00:10-11:00:30预测到车辆聚集事件F持续，在11:00:40和11:00:50虽然未预测到车辆聚集事件，但是由于位于在11:00:30预测到的车辆聚集事件F的第二有效期内，即预测到车辆聚集事件F未结束，因此，在11:00:40和11:00:50也向将要进入共有站点的车辆发送提醒消息以预防车辆聚集事件。在11:01:00预测到的车辆聚集事件与在11:00:30预测得到的车辆聚集事件F的时间间隔小于30S，即在11:01:00预测到的车辆聚集事件在11:00:30预测得到的车辆聚集事件F的第二有效期内，因此，将两个事件合并为一个事件，即预测到车辆聚集事件F未结束。在11:01:10-11:01:30虽然未预测到车辆聚集事件，但由于位于在11:01:00检测到的车辆聚集事件F的第二有效期内，因此，在11:01:10-11:01:30这段时间也要向将要进站的车辆发送提醒消息。在11:01:40和11:01:50未预测到车辆聚集事件，超过了车辆聚集事件F的第二有效期，无需向将要进站的车辆发送提醒消息。在11:02:00再次预测到车辆聚集事件，由于不在车辆聚集事件F的第二有效期内，因此，认为预测到新的车辆聚集事件G开始，并向将要进站的车辆发送提醒消息以预防车辆聚集事件的发生。

如表2示出的，在预测车辆聚集事件的同时，也实时预测进出站车辆的信息，在预测到进出站车辆信息发生变化时，更新预测车辆的明细记录。

本申请的上述实施例中，对廊道的实时运行过程中共有站点的车辆数据进行大数据仿真分析，预测站点未来是否会发生的车辆聚集事件，在预测到发生车辆聚集事件时，及时向将要进站的车辆发送提醒消息，以协同调控经过共有站点的公交车辆的运行情况，从而防止共有站点车辆聚集，减少车辆营运过程中乘客因出行体验差进行投诉的次数。

图10示例性输出了基于本申请实施例提供的公交车辆协同调度方法进行车辆调度的界面图，如图10所示，为火车站至龙镇政府站中一段主干道上的车辆调度情况，经过该主干道的公交路线有126路、10路、232路和316路，其中，共有站点设置的出站口和进站口，用表示，每一公交车辆在进站时上报进站时间，根据共有站点的停靠的车辆数量进行车辆聚集事件的告警和预警，如图10示出的，主干道的上行路线中，在″南师大附中南门″和″青年路振兴路口″两站(用虚线表示)预测到车辆聚集事件，对将要进入这两站的车辆进行预警以避免发生车辆聚集，在″翠洲家园南门″(用点画线表示)检测到车辆聚集事件，对将要进入这站的车辆进行告警以尽快缓解车辆聚集事件。同理，主干道的下行路线中，在″青年路迎宾路口BRT″(用虚线表示)预测到车辆聚集事件，对将要进入这站的车辆进行预警以避免发生车辆聚集，在″翠洲家园南门″(用点画线表示)检测到车辆聚集事件，对将要进入这站的车辆进行告警以尽快缓解车辆聚集事件。

如图示出的，在进行车辆聚集事件告警和预警的同时，还对公交车辆的运行状态进行监控，其中，″☆″表示车辆运行正常，″！″表示车辆运行异常，″×″表示车辆违规，通过对车辆运行状态的监控，以更准确的进行车辆调度，减少和避免车辆聚集事件的发生。

基于相同的技术构思，本申请实施例提供一种调度客户端，用以实现本申请实施例提供的公交廊道协同调度方法，且能达到相同的技术效果。

参见图11，该调度客户端包括获取模块1101、检测模型1102、告警模型1103；

获取模块1101，用于针对多条公交线路共同拥有的每一个共有站点，按照所述共有站点在当前时段对应的预设检测频率，获取当前时刻所述共有站点已停靠的车辆数量；其中，所述预设检测频率和经过所述共有站点的公交路线的数量呈正相关，且同一共有站点在不同时段对应的预设检测频率不同；

检测模块1102，用于检测获取的已停靠的车辆数量是否大于预设标准泊位数量，若是，则检测到所述共有站点发生车辆聚集事件；

告警模块1103，用于在满足所述车辆聚集事件的第一预设结束条件之前，持续向将要停靠所述共有站点的进站车辆发送提醒消息以协同调度所述进站车辆。

可选的，第一预设结束条件包括：

已停靠共有站点的车辆数量不大于预设标准泊位数量；或者

在车辆聚集事件的第一有效期内，未再次检测到车辆聚集事件。

可选的，还包括更新模块1104，用于：

在车辆聚集事件的第一有效期内，若再次检测到车辆聚集事件，则根据再次检测到的车辆聚集事件的时间，更新第一有效期。

可选的，更新模块1104具体用于：

将再次检测到的车辆聚集事件的时间，与预设的初始有效期的和，确定为车辆聚集事件的第一有效期。

可选的，更新模块1104还用于：

获取共有站点已关联车辆的上传的车辆数据；

当车辆数据发生变化时，更新进出共有站点的车辆明细记录；

根据更新后的车辆明细记录，更新当前时间已停靠共有站点的车辆数量。

可选的，还包括预警模块1105，用于：

获取预测时段内，预测得到的进出共有站点的车辆数据，预测时段为参考车辆预计到达共有站点所需的时间；

根据已停靠的车辆数量以及预测得到的车辆数据，预测参考车辆到达共有站点时，是否发生车辆聚集事件；

若预测发生车辆聚集事件，则在预测满足车辆聚集事件的第二预设结束条件之前，持续向预测得到的将要进入共有站点的进站车辆发送提醒消息。

可选的，第二预设结束条件包括：

预测到共有站点已停靠的车辆数量不大于预设标准泊位数量；或者

在预测到的车辆聚集事件的第二有效期内，未再次预测到车辆聚集事件。

可选的，更新模块1104还用于：

在预测到的车辆聚集事件的第二有效期内，若再次预测到车辆聚集事件，则根据再次预测到的车辆聚集事件的时间，更新第二有效期。

可选的，共有站点的换乘人数大于预设的换乘阈值。

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

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

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

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

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

Claims (8)

1.一种公交车辆协同调度方法，其特征在于，应用于调度客户端，包括：

针对多条公交线路共同拥有的每一个共有站点，按照所述共有站点在当前时段对应的预设检测频率，获取当前时刻所述共有站点已停靠的车辆数量；其中，所述预设检测频率和经过所述共有站点的公交路线的数量呈正相关，且同一共有站点在不同时段对应的预设检测频率不同；

若获取的已停靠的车辆数量大于预设标准泊位数量，则检测到所述共有站点发生车辆聚集事件；

判断所述车辆聚集事件是否满足第一预设结束条件；

当所述第一预设结束条件为在所述车辆聚集事件的第一有效期内未再次检测到车辆聚集事件时，若不满足，则将再次检测到的车辆聚集事件的时间与预设的初始有效期的和，确定为所述车辆聚集事件的第一有效期，并在所述车辆聚集事件满足所述第一预设结束条件之前，持续向将要停靠所述共有站点的进站车辆发送提醒消息以协同调度所述进站车辆；其中，所述初始有效期为：基于所述车辆聚集事件的检测时间确定的所述车辆聚集事件合并的时间间隔；

若满足，则不向将要停靠所述共有站点的进站车辆发送提醒消息。

2.如权利要求1所述的方法，其特征在于，所述持续向将要停靠所述共有站点的进站车辆发送提醒消息以协同调度所述进站车辆，包括：

持续向将要停靠所述共有站点的进站车辆发送提醒消息，以使将要停靠所述共有站点的进站车辆降低速度以延迟进站时间。

3.如权利要求1所述的方法，其特征在于，检测所述共有站点是否发生车辆聚集事件的过程中，还包括：

获取所述共有站点已关联的车辆上传的车辆数据；

当所述车辆数据发生变化时，更新进出所述共有站点的车辆明细记录；

根据更新后的车辆明细记录，更新当前时刻已停靠所述共有站点的车辆数量。

4.如权利要求1所述的方法，其特征在于，所述方法还包括：

获取预测时段内，预测得到的进出所述共有站点的车辆数据，所述预测时段为参考车辆预计到达所述共有站点所需的时间；

根据所述已停靠的车辆数量以及预测得到的车辆数据，预测所述参考车辆到达所述共有站点时，是否发生车辆聚集事件；

若预测发生车辆聚集事件，则在预测满足车辆聚集事件的第二预设结束条件之前，持续向预测得到的将要进入所述共有站点的进站车辆发送提醒消息。

5.如权利要求4所述的方法，其特征在于，所述第二预设结束条件包括：

预测到所述共有站点已停靠的车辆数量不大于预设标准泊位数量；或者

在预测到的车辆聚集事件的第二有效期内，未再次预测到车辆聚集事件。

6.如权利要求5所述的方法，其特征在于，在预测到的车辆聚集事件的第二有效期内，若再次预测到车辆聚集事件，则根据再次预测到的车辆聚集事件的时间，更新所述第二有效期。

7.如权利要求1-6中任一项所述的方法，其特征在于，所述共有站点的换乘人数大于换乘阈值。

8.一种调度客户端，其特征在于，包括：

获取模块，用于针对多条公交线路共同拥有的每一个共有站点，按照所述共有站点在当前时段对应的预设检测频率，获取当前时刻所述共有站点已停靠的车辆数量；其中，所述预设检测频率和经过所述共有站点的公交路线的数量呈正相关，且同一共有站点在不同时段对应的预设检测频率不同；

检测模块，用于检测获取的已停靠的车辆数量是否大于预设标准泊位数量，若是，则检测到所述共有站点发生车辆聚集事件；

所述检测模块，还用于判断所述车辆聚集事件是否满足第一预设结束条件；

告警模块，当所述第一预设结束条件为在所述车辆聚集事件的第一有效期内未再次检测到车辆聚集事件时，若不满足所述第一预设结束条件，则将再次检测到的车辆聚集事件的时间与预设的初始有效期的和，确定为所述车辆聚集事件的第一有效期，并在所述车辆聚集事件满足所述第一预设结束条件之前，持续向将要停靠所述共有站点的进站车辆发送提醒消息以协同调度所述进站车辆；若满足所述第一预设结束条件，则不向将要停靠所述共有站点的进站车辆发送提醒消息；其中，所述初始有效期为：基于所述车辆聚集事件的检测时间确定的所述车辆聚集事件合并的时间间隔。