CN113065921A - 出行订单分配和发起方法、装置、终端及存储介质 - Google Patents

Abstract

本发明提供出行订单分配和发起方法、装置、终端及存储介质，包括：接收出行订单；确定所述出行订单的出发地位置并查找预设直线距离内的车辆；生成各所述车辆从其当前位置到所述出发地位置的规划路径；根据所述规划路径计算各车辆到达所述出发地位置的预计耗时，并选取其中耗时最短的车辆匹配所述出行订单。本发明能够将订单推送从空车车辆推广至非空车车辆，提升匹配司机的基数，为出行订单选择最合适的车辆最优的司机。本发明摈弃了路程最短选择方法，改用预计耗时最短选择方法，为计算预计耗时所采用的速度取样方法为道路限速，并结合天气、路口数量、载客情况等进行计算，实现更精准的耗时计算，大大提升了出行订单的匹配效率和匹配质量。

Description

出行订单分配和发起方法、装置、终端及存储介质

技术领域

本发明涉及订单管理技术领域，尤其涉及出行订单分配和发起方法、装置、终端及存储介质。

背景技术

网约车，即网络预约出租汽车经营服务的简称，是指以互联网技术为依托构建服务平台，接入符合条件的车辆和驾驶员，通过整合供需信息，提供非巡游的预约出租汽车服务的经营活动。

在网约车领域，给用户指派司机时，需要一种方法来计算司机的接单时间，以便给用户找到最快能到达的司机。目前的网约车再给用户指派司机时，通常只考虑一定距离内的空车司机，但有时候空车司机并不一定是最佳选择。因此，如何采用一种技术方案进行判断和对比，选出接驾用时最少的司机并将乘客订单推送给司机，是本领域亟需解决的技术问题。

发明内容

有鉴于现有技术的上述缺陷，本发明所要解决的技术问题是如何采用一种技术方案进行判断和对比，选出接驾用时最少的司机并将乘客订单推送给司机。

为实现上述目的，本发明提供了一种出行订单分配方法，应用于服务器；所述方法包括：接收出行订单；确定所述出行订单的出发地位置并查找预设直线距离内的车辆；生成各所述车辆从其当前位置到所述出发地位置的规划路径；所述规划路径包括空车车辆从其当前位置到所述出发地位置的实际行驶路径，和/或非空车车辆完成进行中订单后再到所述出发地位置的实际行驶路径；根据所述规划路径计算各所述车辆到达所述出发地位置的预计耗时，并选取其中耗时最短的车辆匹配所述出行订单。

在本发明的较佳实施方式中，根据所述规划路径计算各车辆到达所述出发地位置的预计耗时，其过程包括：获取所述规划路径的平均限速，并按照车速修正系数来修正所述平均限速以得到各车辆的实际行车速度；根据所述规划路径的距离总长与所述实际行车速度计算得到平均耗时，并按照时间修正系数来修正所述平均耗时以得到各车辆的所述预计耗时。

在本发明的另一较佳实施方式中，所述车速修正系数关联于天气因素和/或出行时段因素；所述时间修正系数关联于交通灯数量因素和/或载客因素。

在本发明的另一较佳实施方式中，所述车速修正系数对所述实际行车速度向下修正的程度与天气因素不利于车辆出行的程度和/或出行时段的道路拥堵程度呈正相关。

在本发明的另一较佳实施方式中，所述时间修正系数对所述预计耗时向上修正的程度与左转路口数量、受交通灯控制的右转路口数量、单车道路口数量呈正相关；所述时间修正系数在车辆载客的情况下对预计耗时向上修正。

在本发明的另一较佳实施方式中，所述非空车车辆完成进行中订单后再到所述出发地位置的实际行驶路径，包括：所述非空车车辆从其当前位置到进行中订单的目的地位置后再到所述出发地位置的实际行驶路径；以及/或者，所述非空车车辆从其当前位置到进行中订单的出发地后，到进行中订单的目的地位置，再到所述出发地位置的实际行驶路径。

在本发明的另一较佳实施方式中，若查找预设直线距离内的车辆均为非空车车辆，则扩大预设直线距离，直至查找到空车车辆。

在本发明的另一较佳实施方式中，若匹配到多辆车辆，则按照如下方式处理：若匹配到的均为空车车辆，则根据司机画像选取最优车辆；若匹配到空车车辆和非空车车辆，则判断当前的出行订单量是否充足；若不充足，则将所述出行订单匹配给空车车辆；若充足且所述非空车车辆进行中订单的目的地位置与所述出行订单的出发地位置之间的距离小于预设阈值，则将所述出行订单匹配给非空车车辆。

为实现上述目的，本发明还提供一种出行订单发起方法，应用于用户终端；所述方法包括：响应于用户发出的出行请求，生成对应的出行订单；将所述出行订单发送至服务器，供所述服务器确定所述出行订单的出发地位置并查找预设直线距离内的车辆；生成各所述车辆从其当前位置到所述出发地位置的规划路径；所述规划路径包括空车车辆从其当前位置到所述出发地位置的实际行驶路径，和/或非空车车辆完成进行中订单后再到所述出发地位置的实际行驶路径；并根据所述规划路径计算各所述车辆到达所述出发地位置的预计耗时，并选取其中耗时最短的车辆匹配所述出行订单；接收所述服务器下发的匹配车辆信息。

为实现上述目的，本发明还提供一种出行订单分配装置，包括：订单模块，用于接收出行订单；查找模块，用于确定所述出行订单的出发地位置并查找预设直线距离内的车辆；路径模块，用于生成各所述车辆从其当前位置到所述出发地位置的规划路径；所述规划路径包括空车车辆从其当前位置到所述出发地位置的实际行驶路径，和/或非空车车辆完成进行中订单后再到所述出发地位置的实际行驶路径；匹配模块，用于根据所述规划路径计算各车辆到达所述出发地位置的预计耗时，并选取其中耗时最短的车辆匹配所述出行订单。

为实现上述目的，本发明还提供一种服务终端，包括：处理器及存储器；所述存储器用于存储计算机程序；所述处理器用于执行所述存储器存储的计算机程序，以使所述终端执行所述出行订单分配方法。

为实现上述目的，本发明还提供一种用户终端；包括：处理器及存储器；所述存储器用于存储计算机程序；所述处理器用于执行所述存储器存储的计算机程序，以使所述终端执行所述出行订单发起方法。

为实现上述目的，本发明还提供一种计算机可读存储介质，其上存储有第一计算机程序和/或第二计算机程序，所述第一计算机程序被处理器执行时实现所述出行订单分配方法；所述第二计算机程序被处理器执行时实现所述出行订单发起方法。

本发明提供的出行订单分配和发起方法、装置、终端及存储介质具有以下技术效果：本发明能够将订单推送从空车车辆推广至非空车车辆，提升匹配司机的基数，为出行订单选择最合适的车辆最优的司机。本发明摈弃了路程最短选择方法，改用预计耗时最短选择方法，为计算预计耗时所采用的速度取样方法为道路限速，并结合天气、路口数量、载客情况等进行计算，实现更精准的耗时计算，大大提升了出行订单的匹配效率和匹配质量。

以下将结合附图对本发明的构思、具体结构及产生的技术效果作进一步说明，以充分地了解本发明的目的、特征和效果。

附图说明

图1是本发明一实施例中出行订单分配方法的流程示意图。

图2A是本发明一实施例中非空车车辆行驶路径的示意图。

图2B是本发明一实施例中非空车车辆行驶路径的示意图。

图3是本发明一实施例中出行订单发起方法的流程示意图。

图4是本发明一实施例中出行订单分配装置的结构示意图。

图5是本发明一实施例中服务终端的结构示意图。

图6是本发明一实施例中用户终端的结构示意图。

具体实施方式

以下通过特定的具体实例说明本发明的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精神下进行各种修饰或改变。需说明的是，在不冲突的情况下，以下实施例及实施例中的特征可以相互组合。

如同在本文中所使用的，单数形式“一”、“一个”和“该”旨在也包括复数形式，除非上下文中有相反的指示。本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包含”、“包括”表明存在所述的特征、操作、元件、组件、项目、种类、和/或组，但不排除一个或多个其他特征、操作、元件、组件、项目、种类、和/或组的存在、出现或添加。应当进一步理解，此处使用的术语“或”和“和/或”被解释为包括性的，或意味着任一个或任何组合。因此，“A、B或C”或者“A、B和/或C”意味着“以下任一个：A；B；C；A和B；A和C；B和C；A、B和C”。仅当元件、功能或操作的组合在某些方式下内在地互相排斥时，才会出现该定义的例外。

需要说明的是，以下实施例中所提供的图示仅以示意方式说明本发明的基本构想，遂图示中仅显示与本发明中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制，其实际实施时各组件的型态、数量及比例可为一种随意的改变，且其组件布局型态也可能更为复杂。为了阐释的目的而描述了本发明的一些示例性实施例，需要理解的是，本发明可通过附图中没有具体示出的其他方式来实现。

如图1所示，展示了本发明一实施例中出行订单分配方法的流程示意图，主要包括步骤S11～S14。需说明的是，本实施例的出行订单分配方法应用于服务器，所述服务器可以根据功能、负载等多种因素布置在一个或多个实体服务器上，也可以由分布的或集中的服务器集群构成，本实施例不作限定。

步骤S11：接收出行订单。所述出行订单应至少包括如下基本信息：出发地位置、目的地位置信息、乘客画像信息(如乘客姓名、性别、联系方式、信誉度等)、出行人数信息等。

举例来说，用户通过手机APP注册时，会输入基本信息(如姓名、性别、联系方式等)，这些基本信息都会上传给服务器；用户每次使用手机APP生成订单时，需输入出发地位置和目的地位置；此外，用户每次完成一个订单都会产生相应的结果数据，通过这些结果数据可以生成该用户的信誉度，例如所有订单都顺利完成则可以判断该用户信誉度高，再例如用户多次无故取消订单则可能影响到该用户信誉度等等。应理解，服务器获取上述这些信息的方式并不仅限于此，以上举例仅用于解释说明，而非用于限制本发明的保护范围。

步骤S12：确定所述出行订单的出发地位置并查找预设直线距离内的车辆。具体而言，服务器在接收到出行订单后，从出行订单中提取用户的出发地位置信息，再根据出发地位置在地图软件(如高德地图、百度地图、谷歌地图等)中进行定位，随后距离该定位位置预设直线距离内的所有车辆。查找到的所有车辆，可能是空车车辆，也可能是非空车车辆；可通过驾驶员当前是否有进行中订单来确认该车辆是否是空车车辆，若某车辆仍有订单在进行中则说明是载客车辆，若没有订单在进行中则说明是空车车辆。

在一些优选的实施方式中，优选查找空车车辆，具体的查找方式如下：若查找预设直线距离内的车辆均为非空车车辆，则扩大预设直线距离，直至查找到空车车辆。例如，按照预设直线距离1km进行查找，即以所述出发地位置为圆心，1km为半径的圆形区域内查找所有空车车辆，若没有查找到任何车辆，那么扩大预设直线距离，如将范围扩大到2km，以此类推，直至查找到空车车辆为止。

步骤S13：生成各所述车辆从其当前位置到所述出发地位置的规划路径；所述规划路径包括空车车辆从其当前位置到所述出发地位置的实际行驶路径，和/或非空车车辆完成进行中订单后再到所述出发地位置的实际行驶路径。

需说明的是，在现有的网约车订单匹配方法中，通常仅定位空车车辆，安排距离最近的空车车辆前往接驾。但在实际运营中，一是空车车辆并不必然比非空车车辆更快地到达订单目的地位置，二是在忙碌时段不一定能定位到空车车辆，所以为了扩大车辆基数，本发明将定位车辆从空车车辆到非空车车辆，以提升车辆匹配效率和匹配质量。

在一些示例中，对于非空车车辆而言，其实际行驶路径是指从其当前位置到进行中订单的目的地位置后再到所述出发地位置的实际行驶路径。以图2A为例来说明，非空车车辆进行中订单的出发地位置为S1，目的地位置为S2，S1与S2之间的折线代表了进行中订单的规划路径；位置C示所述非空车车辆当前的位置；待匹配的出行订单的出发地位置为S3，目的地位置为S4，S3与S4之间的折线代表了该出行订单的规划路径。因此，非空车车辆的实际行驶路径是指从当前位置C1到S2，再从S2到达S3的实际行驶路径。

在一些示例中，非空车车辆的实际行驶路径是指从其当前位置到进行中订单的出发地后，到进行中订单的目的地位置，再到所述出发地位置的实际行驶路径。这种情况通常适用于非空车车辆的进行中订单的行驶路径非常短，虽然在载客中，但其实耗时非常短。以图2B为例来说明，非空车车辆进行中订单的出发地位置为S5，目的地位置为S6，目前位置为C2，正在赶往S5接驾的路上；待匹配的出行订单的出发地位置为S7，目的地位置为S8，S7与S8之间的折线代表了该出行订单的规划路径。因此，非空车车辆的实际行驶路径是指从当前位置C1到S5，再从S5到S6，S6到S7的实际行驶路程。

步骤S14：根据所述规划路径计算各车辆到达所述出发地位置的预计耗时，并选取其中耗时最短的车辆匹配所述出行订单。

值得注意的是，本发明将现有技术中常用的路程对比改为耗时对比，因为路程远可能实际耗时较少，给用户的实际体验接单更快；相反，有些路程虽短但实际耗时较长，反而给用户带来了不好的体验。

与此同时，计算预计耗时需要规划路径的距离总长和速度信息，速度信息可以取自该规划路径内历史订单的平均速度，但历史订单的平均速度显然不够准确，在实际应用中会因为各种因素而产生非常大的偏差，影响车辆匹配的精准度，从而使最终计算得到的耗时数据最符合实际的应用场景。

具体而言，根据所述规划路径计算各车辆到达所述出发地位置的预计耗时，其过程包括：获取所述规划路径的平均限速，并按照车速修正系数来修正所述平均限速以得到各车辆的实际行车速度；根据所述规划路径的距离总长与所述实际行车速度计算得到平均耗时，并按照时间修正系数来修正所述平均耗时以得到各车辆的所述预计耗时。

其中，获取所述规划路径的平均限速的方式如下：获取所述规划路径的各组成路段的限速数据，根据各组成路段的长度和限速数据来计算所述规划路径的平均限速。例如，规划路径由A路段和B路段组成，A路段总长10km，限速80km/h，B路段总长20km，限速100km/h，那么平均限速就是92.3km/h((10+20)/(10/80+20/100))。此外，由于计算所得的平均限速偏向于理论值，考虑到现实与理论之间的差距，本实施例在计算到平均限速后向下做一定的折算，例如：计算得到的平均限速理论值为V1’，则平均限速的实际取值为V1＝0.8*V1’。

在本实施例中，所述车速修正系数关联于天气因素和/或出行时段因素；所述时间修正系数关联于交通灯数量因素和/或载客因素，具体关联方式如下文所述。

车速修正系数对车速向下修正的程度与天气因素不利于车辆出行的程度和/或出行时段的道路拥堵程度呈正相关。也即，天气越是恶劣，车速向下修正越多；反之，天气越是利于出行，车速向下修正越少。

举例来说，若天气为特大暴雨(雪)，则修正速度为0.4*V1；若天气为大暴雨(雪)，则修正速度为0.5*V1；若天气为中雨(雪)，则修正速度为0.6*V1；若天气为小雨(雪)，则修正速度为0.7*V1。需说明的是，出于说明性目的而提供以上示例，并且以上示例不应被理解成是限制性的。

时间修正系数对预计耗时向上修正的程度与左转路口数量、受交通灯控制的右转路口数量、单车道路口数量呈正相关；所述时间修正系数在车辆载客的情况下对预计耗时向上修正。也即，规划路径中左转路口数量越多，则预计耗时向上修正越多，反之修正越少；规划路径中受交通灯控制的右转路口数量越多，则预计耗时向上修正越多，反之修正越少；规划路径中单车道路口数量越多，则预计耗时向上修正越多，反之修正越少；另外，若匹配车辆当前是载客状态，也需要相应修正预计耗时。

举例来说，统计到规划路径中左转路口数量为A，若每个需要左转的路口多耗时7秒，那么需要将预计耗时向上修正7*A秒。统计到规划路径中有右转红灯的路口数量为B，若每个有右转红灯的路口多耗时6秒，那么需要将预计耗时向上修正6*B秒。统计到规划路径中有单车道路口数量为C，若每个单车道路口多耗时5秒，那么需要将预计耗时向上修正5*C秒。若该车辆当前是载客状态，那么需要将预计耗时向上修正10秒。

为便于理解，现假设规划路径总长为S，平均限速计算值为V1’，实际行车速度为平均限速计算值的0.8，当前天气为小雨，规划路径内共有A个左转路口，B个右转受红绿灯控制的路口，C个单车道路口，每个路口都耗时5秒，且该司机正在载客，预计耗时的修正计算过程如下：

实际行车速度可按照V1’*0.8＝V1来计算；当前天气为小雨，那么车速修正系数相应取值为0.7，修正后的实际车速为0.7*V1。因此，修正前的预计耗时t可以表示为：t’＝S/(0.7*V1)。

按照A个左转路口，B个右转受红绿灯控制的路口，C个单车道路口，每个路口都耗时5秒，且该司机正在载客，那么修正后的预计耗时t可以表示为：t＝t’+(A+B+C)*5+10。

在一些示例中，考虑到可能出现同时匹配到两辆及以上符合条件的车辆，这种情况可能是这些车辆的预计耗时正好相等，或者预计耗时相差非常小。在这种情况下，还需进一步分析这些车辆当前的载客状态。

若匹配到的均为空车车辆，则根据司机画像选取最优车辆。需说明的是，司机画像是指基于网络应用和大数据，将司机的每个具体信息抽象成标签，利用这些标签将司机形象具体化，从而提供针对性的服务。本实施例中的司机画像至少包括司机基本信息(如姓名、性别、年龄、驾龄等)、司机评分(基于历史订单所进行的打分，打分项目通常包括服务态度、是否准时、是否绕道、是否疲劳驾驶、是否急停急开等)；本实施例为评分最高的司机最优先匹配出行订单，以形成良性循环。

若匹配到空车车辆和非空车车辆，则判断当前的出行订单量是否充足；若不充足，则将所述出行订单匹配给空车车辆；若充足且所述非空车车辆进行中订单的目的地位置与所述出行订单的出发地位置之间的距离小于预设阈值，则将所述出行订单匹配给非空车车辆。也即，在订单量不充足的情况下，优先为空车车辆匹配出行订单；在订单量充足的情况下，那么可以考虑非空车车辆进行中订单的目的地位置与出行订单的出发地位置是否很近，若很近，则将所述出行订单匹配给非空车车辆，这样就可以最大效率地管理出行订单，避免车辆需要空车行驶很长距离来接单，大大浪费了出行资源。

如图3所示，展示了本发明一实施例中出行订单发起方法的流程示意图，包括步骤S31～S33。需说明的是，本实施例的出行订单发起方法应用于用户终端，例如智能手机、平板电脑、智能手环、智能手表、智能头盔等。

步骤S31：响应于用户发出的出行请求，生成对应的出行订单。

以触摸控制的手机为例，用户通过对触摸屏的控制发起出行请求，用户终端相应于用户发出的出行请求，生成对应的出行订单。所述出行订单应至少包括如下基本信息：出发地位置、目的地位置信息、乘客画像信息(如乘客姓名、性别、联系方式、信誉度等)、出行人数信息等。

步骤S32：将所述出行订单发送至服务器，供所述服务器确定所述出行订单的出发地位置并查找预设直线距离内的车辆；生成各所述车辆从其当前位置到所述出发地位置的规划路径；所述规划路径包括空车车辆从其当前位置到所述出发地位置的实际行驶路径，和/或非空车车辆完成进行中订单后再到所述出发地位置的实际行驶路径；根据所述规划路径计算各车辆到达所述出发地位置的预计耗时，并选取其中耗时最短的车辆匹配所述出行订单。

在一些示例中，根据所述规划路径计算各车辆到达所述出发地位置的预计耗时，其过程包括：获取所述规划路径的平均限速，并按照车速修正系数来修正所述平均限速以得到各车辆的实际行车速度；根据所述规划路径的距离总长与所述实际行车速度计算得到平均耗时，并按照时间修正系数来修正所述平均耗时以得到各车辆的所述预计耗时。

在一些示例中，所述车速修正系数关联于天气因素和/或出行时段因素；所述时间修正系数关联于交通灯数量因素和/或载客因素。所述车速修正系数对车速向下修正的程度与天气因素不利于车辆出行的程度和/或出行时段的道路拥堵程度呈正相关。

进一步的，所述时间修正系数对预计耗时向上修正的程度与左转路口数量、受交通灯控制的右转路口数量、单车道路口数量呈正相关；所述时间修正系数在车辆载客的情况下对预计耗时向上修正。

步骤S33：接收所述服务器下发的匹配车辆信息。

因本实施例中出行订单发起方法的实施方式与上文实施例中出行订单分配方法的实施方式类似，因此不再赘述。

如图4所示，展示了本发明一实施例中出行订单分配装置的结构示意图。本实施例的出行订单分配装置400包括订单模块401、查找模块402、路径模块403、匹配模块404。

所述订单模块401用于接收出行订单；所述查找模块402用于确定所述出发地位置并查找预设直线距离内的车辆；所述路径模块403用于生成各所述车辆从其当前位置到所述出发地位置的规划路径；所述规划路径包括空车车辆从其当前位置到所述出发地位置的实际行驶路径，和/或非空车车辆完成进行中订单后再到所述出发地位置的实际行驶路径；所述匹配模块404用于根据所述规划路径计算各车辆到达所述出发地位置的预计耗时，并选取其中耗时最短的车辆匹配所述出行订单。

应理解以上装置的各个模块的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现；也可以全部以硬件的形式实现；还可以部分模块通过处理元件调用软件的形式实现，部分模块通过硬件的形式实现。例如，路径模块可以为单独设立的处理元件，也可以集成在上述装置的某一个芯片中实现，此外，也可以以程序代码的形式存储于上述装置的存储器中，由上述装置的某一个处理元件调用并执行以上路径模块的功能。其它模块的实现与之类似。此外这些模块全部或部分可以集成在一起，也可以独立实现。这里所述的处理元件可以是一种集成电路，具有信号的处理能力。在实现过程中，上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。

例如，以上这些模块可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个特定集成电路(Application Specific Integrated Circuit，简称ASIC)，或，一个或多个微处理器(digital signal processor，简称DSP)，或，一个或者多个现场可编程门阵列(Field Programmable Gate Array，简称FPGA)等。再如，当以上某个模块通过处理元件调度程序代码的形式实现时，该处理元件可以是通用处理器，例如中央处理器(Central Processing Unit，简称CPU)或其它可以调用程序代码的处理器。再如，这些模块可以集成在一起，以片上系统(system-on-a-chip，简称SOC)的形式实现。

如图5所示，展示了本发明一实施例中服务终端的结构示意图。本实施例的服务终端包括处理器51和存储器52；所述存储器52用于存储计算机程序；所述处理器51用于执行所述存储器存储的计算机程序，以使所述终端执行所述出行订单分配方法。

如图6所示，展示了本发明一实施例中用户终端的结构示意图。本实施例的用户终端包括处理器61和存储器62；所述存储器62用于存储计算机程序；所述处理器61用于执行所述存储器存储的计算机程序，以使所述终端执行所述出行订单发起方法。

上述提到的系统总线可以是外设部件互连标准(Peripheral ComponentInterconnect，简称PCI)总线或扩展工业标准结构(Extended Industry StandardArchitecture，简称EISA)总线等。该系统总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。通信接口用于实现数据库访问装置与其他设备(例如客户端、读写库和只读库)之间的通信。存储器可能包含随机存取存储器(Random Access Memory，简称RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(Digital Signal Processing，简称DSP)、专用集成电路(Application SpecificIntegrated Circuit，简称ASIC)、现场可编程门阵列(Field－Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

本发明还提供一种计算机可读存储介质，其上存储有第一计算机程序和/或第二计算机程序，所述第一计算机程序被处理器执行时实现所述出行订单分配方法；所述第二计算机程序被处理器执行时实现所述出行订单发起方法。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过计算机程序相关的硬件来完成。前述的计算机程序可以存储于一计算机可读存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

于本申请提供的实施例中，所述计算机可读写存储介质可以包括只读存储器、随机存取存储器、EEPROM、CD-ROM或其它光盘存储装置、磁盘存储装置或其它磁存储设备、闪存、U盘、移动硬盘、或者能够用于存储具有指令或数据结构形式的期望的程序代码并能够由计算机进行存取的任何其它介质。另外，任何连接都可以适当地称为计算机可读介质。例如，如果指令是使用同轴电缆、光纤光缆、双绞线、数字订户线(DSL)或者诸如红外线、无线电和微波之类的无线技术，从网站、服务器或其它远程源发送的，则所述同轴电缆、光纤光缆、双绞线、DSL或者诸如红外线、无线电和微波之类的无线技术包括在所述介质的定义中。然而，应当理解的是，计算机可读写存储介质和数据存储介质不包括连接、载波、信号或者其它暂时性介质，而是旨在针对于非暂时性、有形的存储介质。如申请中所使用的磁盘和光盘包括压缩光盘(CD)、激光光盘、光盘、数字多功能光盘(DVD)、软盘和蓝光光盘，其中，磁盘通常磁性地复制数据，而光盘则用激光来光学地复制数据。

综上所述，本申请提供出行订单分配和发起方法、装置、终端及存储介质，能够将订单推送从空车车辆推广至非空车车辆，提升匹配司机的基数，为出行订单选择最合适的车辆最优的司机。本发明摈弃了路程最短选择方法，改用预计耗时最短选择方法，为计算预计耗时所采用的速度取样方法为道路限速，并结合天气、路口数量、载客情况等进行计算，实现更精准的耗时计算，大大提升了出行订单的匹配效率和匹配质量。所以，本申请有效克服了现有技术中的种种缺点而具高度产业利用价值。

上述实施例仅例示性说明本发明的原理及其功效，而非用于限制本发明。任何熟悉此技术的人士皆可在不违背本发明的精神及范畴下，对上述实施例进行修饰或改变。因此，举凡所属技术领域中具有通常知识者在未脱离本发明所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本发明的权利要求所涵盖。

Claims (13)

1.一种出行订单分配方法，其特征在于，应用于服务器；所述方法包括：

接收出行订单；

确定所述出行订单的出发地位置并查找预设直线距离内的车辆；

生成各所述车辆从其当前位置到所述出发地位置的规划路径；所述规划路径包括空车车辆从其当前位置到所述出发地位置的实际行驶路径，和/或非空车车辆完成进行中订单后再到所述出发地位置的实际行驶路径；

根据所述规划路径计算各所述车辆到达所述出发地位置的预计耗时，并选取其中耗时最短的车辆匹配所述出行订单。

2.如权利要求1所述的出行订单分配方法，其特征在于，所述根据所述规划路径计算各所述车辆到达所述出发地位置的预计耗时，包括：

获取所述规划路径的平均限速，并按照车速修正系数来修正所述平均限速以得到各所述车辆的实际行车速度；

根据所述规划路径的距离总长与所述实际行车速度计算得到平均耗时，并按照时间修正系数来修正所述平均耗时以得到各所述车辆的所述预计耗时。

3.如权利要求2所述的出行订单分配方法，其特征在于，所述车速修正系数关联于天气因素和/或出行时段因素；所述时间修正系数关联于交通灯数量因素和/或载客因素。

4.如权利要求3所述的出行订单分配方法，其特征在于，所述车速修正系数对所述实际行车速度向下修正的程度与天气因素不利于车辆出行的程度和/或出行时段的道路拥堵程度呈正相关。

5.如权利要求3所述的出行订单分配方法，其特征在于，所述时间修正系数对所述预计耗时向上修正的程度与左转路口数量、受交通灯控制的右转路口数量、单车道路口数量呈正相关；所述时间修正系数在车辆载客的情况下对所述预计耗时向上修正。

6.如权利要求1所述的出行订单分配方法，其特征在于，所述非空车车辆完成进行中订单后再到所述出发地位置的实际行驶路径，包括：所述非空车车辆从其当前位置到进行中订单的目的地位置后再到所述出发地位置的实际行驶路径；和/或，所述非空车车辆从其当前位置到进行中订单的出发地后，到进行中订单的目的地位置，再到所述出发地位置的实际行驶路径。

7.如权利要求1所述的出行订单分配方法，其特征在于，若查找预设直线距离内的车辆均为非空车车辆，则扩大所述预设直线距离，直至查找到空车车辆。

8.如权利要求1所述的出行订单分配方法，其特征在于，若匹配到多辆车辆，则按照如下方式处理：

若匹配到的车辆均为空车车辆，则根据司机画像选取最优车辆；

若匹配到空车车辆和非空车车辆，则判断当前的出行订单量是否充足；若不充足，则将所述出行订单匹配给空车车辆；若充足且所述非空车车辆进行中订单的目的地位置与所述出行订单的出发地位置之间的距离小于预设阈值，则将所述出行订单匹配给非空车车辆。

9.一种出行订单发起方法，其特征在于，应用于用户终端；所述方法包括：

响应于用户发出的出行请求，生成对应的出行订单；

将所述出行订单发送至服务器，供所述服务器确定所述出行订单的出发地位置并查找预设直线距离内的车辆；生成各所述车辆从其当前位置到所述出发地位置的规划路径；所述规划路径包括空车车辆从其当前位置到所述出发地位置的实际行驶路径，和/或非空车车辆完成进行中订单后再到所述出发地位置的实际行驶路径；根据所述规划路径计算各所述车辆到达所述出发地位置的预计耗时，并选取其中耗时最短的车辆匹配所述出行订单；

接收所述服务器下发的匹配车辆信息。

10.一种出行订单分配装置，其特征在于，包括：

订单模块，用于接收出行订单；

查找模块，用于确定所述出行订单的出发地位置并查找预设直线距离内的车辆；

路径模块，用于生成各所述车辆从其当前位置到所述出发地位置的规划路径；所述规划路径包括空车车辆从其当前位置到所述出发地位置的实际行驶路径，和/或非空车车辆完成进行中订单后再到所述出发地位置的实际行驶路径；

匹配模块，用于根据所述规划路径计算各所述车辆到达所述出发地位置的预计耗时，并选取其中耗时最短的车辆匹配所述出行订单。

11.一种服务终端，其特征在于，包括：处理器及存储器；

所述存储器用于存储计算机程序；

所述处理器用于执行所述存储器存储的计算机程序，以使所述服务终端执行如权利要求1至8中任一项所述的出行订单分配方法。

12.一种用户终端，其特征在于，包括：处理器及存储器；

所述存储器用于存储计算机程序；

所述处理器用于执行所述存储器存储的计算机程序，以使所述用户终端执行如权利要求9所述的出行订单发起方法。

13.一种计算机可读存储介质，其上存储有第一计算机程序和/或第二计算机程序，所述第一计算机程序被处理器执行时实现权利要求1至8中任一项所述的出行订单分配方法；所述第二计算机程序被处理器执行时实现权利要求9所述的出行订单发起方法。

Images