具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

为了使得本领域技术人员能够使用本申请内容，结合特定应用场景“网约车打车场景”，给出以下实施方式。对于本领域技术人员来说，在不脱离本申请的精神和范围的情况下，可以将这里定义的一般原理应用于其他实施例和应用场景。虽然本申请主要围绕“网约车打车场景”进行描述，但是应该理解，这仅是一个示例性实施例。本申请可以应用于任何其他交通运输的交通工具，可以包括出租车、私家车、顺风车、公共汽车等，或其任意组合。本申请还可以包括用于网约车打车的任何服务系统。

实施例1

图1为本发明提供的基于预约订单的网约车派单方法所使用的场景示意图，如图1所示，包括服务器和至少两个终端，终端可以为能够与服务器通信连接的任意电子设备，包括但不限于手机、笔记本电脑、平台电脑、智能穿戴设备等。

其中，服务器上运行出行平台的服务端，终端上运行出行平台的客户端，终端包括司机端和用户端。乘客使用用户端在出行平台上发布预约订单后，司机可以使用司机端在出行平台上抢接该预约订单。

对于司机来说，预约订单属于优质订单，主观故意迟到的概率极低。而在网约车平台的派单策略中，在司机开始服务预约订单前，仍会向该司机派送其他实时订单；为保证司机有足够的时间抵达预约订单的接驾位置，网约车平台仅在预约订单的接驾时间前一段时间内，停止向司机派单。

由于预约订单在业务中占比较少，传统派单策略是在预约订单的出发时间之前，采用全局最优的派单策略，强制向司机派单。而在预约订单的出发时间之前的一个小时内，停止向司机派单，或者司机自行下线拒绝服务器强制性派单，此方式导致需要司机主观判断是否能及时抵达预约订单的出发地点。

网约车平台对预约订单的考量较少，对预约订单的派单策略并不完善，致使现有派单策略，容易使实时订单与预约订单发生时间冲突，导致可接单网约车司机不能如约完成承接的预约订单订单；又如当司机完成实时订单后，在预约订单的接驾途中可能会有各种不确定的原因导致司机迟到，比如事故、堵塞、天气等原因。

现有技术中，在司机迟到的情况下，乘客有三种应对方式，一种应对方式为乘客在出发地点继续等待，直到司机到达该出发地点，等待多久不确定；另一种应对方式为乘客取消该订单重新叫车，即重新进入排队序列，等待出行平台为新订单指派司机。再一种，乘客取消该订单，换用其他出行方式或网约车平台。

上述前两种应对方式下，均会导致乘客出行时间延迟，乘客可能会对司机进行差评，也就是说，即使是在非主观原因导致司机迟到的情况下，也会损害司机的个人好评度并被出行平台处罚，使得出行平台的用户体验降低。

本发明提供一种基于预约订单的网约车派单方法、装置及电子设备，通过出发地点和实时订单下车点筛选合适的实时订单，保证司机在服务预约订单前对应的空闲时间段内有单可接，同时亦保证司机在预约订单的合适距离范围内，避免司机迟到。通过预估服务实时订单的时长，判断实时订单和预约订单是否有时间冲突。若不存在时间冲突，从而司机端可以如约完成承接的实时订单和预约订单。且司机可快速达到预约订单的出发地点，避免乘客出行时间延迟，从而不会对司机的个人好评度造成损害，也避免了司机被出行平台处罚，综合提升网约车平台的乘客和司机的用户体验。

下面以具体地实施例对本发明的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

实施例2

图2为本发明提供的基于预约订单的网约车派单方法实施例的流程图，本实施例的执行主体可以为出行订单的处理装置，具体的，该装置可以以软件或硬件的方式设置于图1所示的服务器中。

如图1所示，本实施例的方法，可以包括：

S100：获取待派出的实时订单和可接单的司机端。

在本实施例中，待派出的实时订单是指根据乘客输入的用车信息生成的用车订单。

其中，实时订单是指乘客实时出发的用车订单，实时订单一般包括上车点(出发地址)和下车点(目的地址)。可接单的司机端是指在听单中的司机端，尚未进行用车订单服务的。

S200：识别当司机端标记有预约订单时，获取预约订单的出行信息，所述出行信息包括出发时间和出发地点。

S300：判断实时订单的下车点是否位于预设范围内，所述预设范围为以出发地点为圆心，按预设半径值确定的区域。

S400：当实时订单的下车点位于预设范围外，则重新获取待派出的实时订单；当实时订单的下车点位于预设范围内，执行下一步骤。

S500：获取司机端的当前位置，预估实时订单的服务时间，预估从实时订单下车点至预约订单出发地点的接驾时间；

S600：将当前时间叠加服务时间和第二接驾时间，得到最终时间；

S700：判断所述出发时间是否早于或等于最终时间，若是，则重新获取待派出的实时订单；若否，则将实时订单发送至司机端。

具体的，本实施例对上述各流程步骤作如下详细说明。

S100：获取待派出的实时订单和可接单的司机端。

在本实施例中，待派出的实时订单是指根据乘客输入的用车信息生成的用车订单。

其中，实时订单是指乘客实时出发的用车订单，实时订单一般包括上车点(出发地址)和下车点(目的地址)。可接单的司机端是指在听单中的司机端，尚未进行用车订单服务的。

S200：识别当司机端标记有预约订单时，获取预约订单的出行信息，所述出行信息包括出发时间和出发地点。

在本领域中，预约订单是指乘客预约时间出发的用车订单，预约订单一般包括出发地点、目的地址和出发时间，其中出发时间是指乘客预约的用车时间。

可选的，预约订单还可以包括指定提前到达时间，指定提前到达时间为乘客指定网约车提前到达的时间，例如，预约用车时间为9:30，指定提前到达时间为15分钟，则网约车需在9:15到达出发地址，9:15为出发时间。

S300：判断实时订单的下车点是否位于预设范围内，所述预设范围为以出发地点为圆心，按预设半径值确定的区域。

S400：当实时订单的下车点位于预设范围外，则重新获取待派出的实时订单；当实时订单的下车点位于预设范围内，执行下一步骤。

步骤S300～步骤S400，本发明通过出发地点和实时订单下车点筛选合适的实时订单，保证司机在服务预约订单前对应的空闲时间段内有单可接，同时亦保证司机在预约订单的合适距离范围内，避免司机迟到。

在一种实施中，所述预设半径值可以是10KM、15KM、20KM等。预设半径值不宜过大，否则距离越远，实际业务场景存在的不确定因素会增多，比如事故、堵塞、高峰时段等原因，这不利于司机在服务完实时订单后，准时抵达预约订单的出发地点。

本发明优选地，所述预设半径值，基于司机端在预约订单出发时间前的空闲时间段进行划分。例如，在出发时间的前1个小时内，预设半径值为10KM；在出发时间的前2个小时内，预设半径值为20KM。通过此设计，如在出发时间的前2个小时内，司机在接驾前还存在较多的空闲时间段，更好的保证全局最优派单和提高实时订单与司机的配对。

本发明优选地，在判断实时订单的下车点是否位于预设范围内之前，还包括：

S210：配置第一时间阈值和第二时间阈值，所述第一时间阈值早于第二时间阈值，第二时间阈值早于所述出发时间。

在一种可实施的实例中，实施第一时间阈值为出发时间的前2或3个小时的时间，所述第二时间阈值为出发时间的前半个小时或1个小时的时间。例如，例如，预约用车时间为9:00，则第一时间阈值为6:00或7：00，第二时间阈值为8：00或8：30。

具体的，本发明并不限定第一时间阈值和第二时间阈值的具体时间值，所述第一时间阈值和第二时间阈值是网约车平台根据业务场景或自身服务模式进行设置的。

S220：当判断当前时间早于第一时间阈值时，基于全局最优派单策略向司机端发送实时订单；

S230：当判断当前时间位于第一时间阈值与第二时间阈值的时间范围时，判断实时订单的下车点是否位于预设范围内之前；

S240：当判断当前时间晚于第二时间阈值时，停止向司机端发送实时订单，直至预约订单的服务结束。

步骤S220～S240提供了策略调整的方法，基于预约订单的出发时间前的空闲时间段，当前时间早于第一时间阈值时，基于全局最优派单策略向司机端发送实时订单，以此保证全局最优的派单策略。当前时间位于第一时间阈值与第二时间阈值的时间范围时，是准备服务预约订单的缓冲时期，一方面，保证司机持续接单，另一方面，执行S300步骤，筛选前往出发地点的实时订单，保证司机是往出发地点靠近的，极大减少司机迟到的问题。

S500：获取司机端的当前位置，预估实时订单的服务时间，预估从实时订单下车点至预约订单出发地点的接驾时间。

S600：将当前时间叠加服务时间和第二接驾时间，得到最终时间；

S700：判断所述出发时间是否早于或等于最终时间，若是，则重新获取待派出的实时订单；若否，则将实时订单发送至司机端。

步骤S500～S700通过预估服务实时订单的时长，判断实时订单和预约订单是否有时间冲突。若不存在时间冲突，从而司机端可以如约完成承接的实时订单和预约订单。且司机可快速达到预约订单的出发地点，避免乘客出行时间延迟，从而不会对司机的个人好评度造成损害，也避免了司机被出行平台处罚，综合提升网约车平台的乘客和司机的用户体验。

在一种实施中，预估实时订单的服务时间包括：司机端当前位置至实时订单上车点的预估接驾时间、实时订单上车点至下车点的预估行驶时间。预估时间的技术手段是本领域的技术人员可知晓的，在此不过多说明。

本发明优选地，在当判断所述出发时间晚于最终时间时，还包括：

S710：基于实时订单的出行信息生成第一行驶路径，生成当前定位至预约订单的出发地点的第二行驶路径；

S720：计算第一行驶路径和第二行驶路径的顺路匹配度；

S730：当顺路匹配度大于或等于预设匹配阈值时，将实时订单发送至司机端；当顺路匹配度小于预设匹配阈值时，将实时订单发送至司机端供司机确认是否接单。

步骤S710～S730用于牵引司机向预约订单的出发地点方向行驶，通过顺路匹配度，顺路匹配度大于或等于预设匹配阈值时，则表征该实时订单和司机接驾的路径相似，该实时订单是向预约订单方向行驶的。

在一种优选实施中，所述预设匹配阈值可以是30％、40％、50％。预设匹配阈值不宜过大，预设匹配阈值越高，匹配度越高，对应地，满足预设匹配阈值的网约车订单的数量越少，导致实时订单与司机端的匹配难度大，不利于司机在空闲时间段进行接单。

本发明优选地，所述预设匹配阈值，基于司机端在预约订单出发时间前的空闲时间段进行划分。例如，在出发时间的前1个小时内，预设匹配阈值为50％；在出发时间的前2个小时内，预设匹配阈值为30％。通过此设计，如在出发时间的前2个小时内，司机在接驾前还存在较多的空闲时间段，提高实时订单与司机的配对。

在该技术方案中，计算第一行驶路径和第二行驶路径的顺路匹配度，可基于订单与顺路匹配基准相比的绕路比、共乘比计算顺路匹配度，将第一行驶路径和第二行驶路径进行配对等，以实现能够满足相同行驶方向需求的订单的准确筛选。

实施例3

本实施例3还提供了基于预约订单的网约车派单方法的优选实施例，所述网约车派单方法在识别当司机端标记有预约订单时，还包括：

S810：配置第三时间阈值，第三时间阈值早于出发时间。

通过服务器预先设置的第三时间阈值，第三时间阈值可以是出发时间的前30分钟、40分钟或60分钟等。第三时间阈值和出发时间的间隔不宜太小，以预留足够时间给与乘客/司机决策应对。

S820：当判断当前时间位于第三时间阈值至出发时间的时间范围内时，按预设周期获取司机端的当前位置。

S830：计算当前位置至出发地点的接驾时间，判断司机能否根据出发时间抵达出发地点；若否，则向司机端发送提示信息，所述提示信息用于提示时间释放所述预约订单。

步骤S810～S830提供了判断司机是否会迟到且提醒司机处理的技术手段。本实施例通过计算司机当前位置至出发地点的行驶时间，是否早于出发时间。需要说明的是，判断司机是否会迟到的方法有多种，本实施例对此不作具体限定。一种可选的实施方式中，根据司机的当前位置与所述出发地点之间的距离、司机当前的运行时速、当前路况信息和历史时段路况信息等，预估司机由当前位置达到所述出发地点所需要的路程时间，然后根据当前时间和所述路程时间，判断司机能否在所述出发时间到达所述出发地点。

若判断司机能够在所述出发时间达到所述出发地点，则司机继续执行该预约订单，即继续前往所述出发地点接乘客。

若判断司机无法在所述出发时间达到所述出发地点，则可以向司机端发送提示信息，用于提示司机释放该预约订单。例如，司机终端中显示的提示信息可以为“根据当前位置与乘客上车点距离判断：您本次接乘客很可能会迟到，迟到会影响您的服务评价，为把您的损失降低到最小，同时避免影响乘客，建议您释放本次行程给其他师傅”。

司机看到该第一提示信息后，可以选择释放该预约订单。由于司机在出发时间之前释放了该预约订单，使得乘客或者网约车平台还可以采用其他方式保证乘客按时出行。例如，乘客通过用户端重新发布实时订单，由距离所述出发地点较近的其他司机端接单；或者，在司机端释放该预约订单后，网约车平台将该预约订单转移给距离所述出发地点较近的其他司机端。

可见，通过提示司机端释放该预约订单，可以避免乘客出行时间延迟，从而不会对司机的个人好评度造成损害，也避免了司机被出行平台处罚，提升了出行平台的用户体验。

实施例4

本实施例4还提供了基于预约订单的网约车派单方法的优选实施例，所述网约车派单方法在识别当司机端标记有预约订单时，还包括：

S810：配置第四时间阈值，第四时间阈值早于出发时间。

通过服务器预先设置的第四时间阈值，第四时间阈值可以是出发时间的前30分钟、40分钟或60分钟等。第四时间阈值和出发时间的间隔不宜太大，因司机在服务其他实时订单或预约订单，订单的下车点或许是远离乘客的，避免乘客对司机的服务行为产生不满或焦躁的情绪。

S820：当判断当前时间位于第四时间阈值至出发时间的时间范围内时，实时获取司机端的位置信息；

S830：将所述位置信息向用户端发送，并在用户端的电子地图上展示司机端的位置。

步骤S810～S830通过设置第四阈值时间，在该时间段内，司机基于实施例2的派单策略，已前往至乘客的附近一定范围内。通过将司机的位置显示在用户端上，将司机位置的可视化，以便于乘客放心出行，多方面提高预约订单的服务体验。

实施例5

图3为本发明提供的基于预约订单的网约车派单装置的组成图，具体的，该装置可以以软件或硬件的方式设置于图1所示的服务器中。网约车派单装置用于执行实施例2～4所述基于预约订单的网约车派单方法的步骤。

如图3所示，基于预约订单的网约车派单装置包括获取模块、识别模块、判断模块、时间预估模块、处理模块、策略调整模块、顺路匹配模块和订单释放模块。

其中，所述获取模块其用于获取待派出的实时订单和可接单的司机端。

所述识别模块其用于识别当司机端标记有预约订单时，获取预约订单的出行信息，所述出行信息包括出发时间和出发地点。

所述判断模块其用于判断实时订单的下车点是否位于预设范围内，所述预设范围为以出发地点为圆心，按预设半径值确定的区域；所述判断模块还用于当实时订单的下车点位于预设范围外，则重新获取待派出的实时订单；当实时订单的下车点位于预设范围内，则向时间预估模块发送指令。

所述时间预估模块其用于获取司机端的当前位置，预估实时订单的服务时间，预估从实时订单下车点至预约订单出发地点的接驾时间。

所述处理模块其用于将当前时间叠加服务时间和第二接驾时间，得到最终时间；所述处理模块还用于判断所述出发时间是否早于或等于最终时间，若是，则重新获取待派出的实时订单；若否，则将实时订单发送至司机端。

所述策略调整模块用于在当判断所述出发时间晚于预审时间时，执行如下步骤：

基于实时订单的出行信息生成第一行驶路径，生成当前定位至预约订单的出发地点的第二行驶路径；

计算第一行驶路径和第二行驶路径的顺路匹配度；

当顺路匹配度大于或等于预设匹配阈值时，将实时订单发送至司机端；当顺路匹配度小于预设匹配阈值时，将实时订单发送至司机端供司机确认是否接单。

所述顺路匹配模块用于在当判断所述出发时间晚于最终时间时，执行如下步骤：

基于实时订单的出行信息生成第一行驶路径，生成当前定位至预约订单的出发地点的第二行驶路径；

计算第一行驶路径和第二行驶路径的顺路匹配度；

当顺路匹配度大于或等于预设匹配阈值时，将实时订单发送至司机端；当顺路匹配度小于预设匹配阈值时，将实时订单发送至司机端供司机确认是否接单。

所述订单释放模块用于识别当司机端标记有预约订单时，执行以下操作：

配置第三时间阈值，第三时间阈值早于出发时间；

当判断当前时间位于第三时间阈值至出发时间的时间范围内时，按预设周期获取司机端的当前位置；

计算当前位置至出发地点的接驾时间，判断司机能否根据出发时间抵达出发地点；

若否，则向司机端发送提示信息，所述提示信息用于提示时间释放所述预约订单。

本发明还提供了一种电子设备，其特征在于，包括处理器和存储器，所述处理器与存储器连接，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述机器可读指令被所述处理器执行时执行如实施例2～4所述基于预约订单的网约车派单方法的步骤。

以上所述，仅是本发明的较佳实施例而已，并非对本发明作任何形式上的限制，故凡是未脱离本发明技术方案内容，依据本发明的技术实质对以上实施例所作的任何修改、等同变化与修饰,均仍属于本发明技术方案的范围内。