CN109635985A - 订单分配方法、分配系统及计算机可读存储介质 - Google Patents

Abstract

本发明提供了一种订单分配方法、分配系统及计算机可读存储介质，订单分配方法，包括以下步骤：基于预定订单请求，获取订单起点、订单终点和预定时间；获取以订单起点为中心，预设距离为半径的划定区域内司机信息；筛选车牌符合订单请求指向的订单城市的限号规则，形成第一车辆组；筛选车辆的所属地匹配订单起点和/或订单起点所属地的车辆，形成第二车辆组；广播预定订单请求至第二车辆组内的运营司机，接收运营司机针对预定订单请求的优先接单响应，以确定车辆为接单车辆；将预定订单请求和接单车辆的信息交互至生成预定订单请求的用户和接单车辆的运营司机。由此网约车的行程更为顺畅，且可节省用户的等待时间，提高网约车的运营效率。

Description

订单分配方法、分配系统及计算机可读存储介质

技术领域

本发明涉及车辆运营领域，尤其涉及一种订单分配方法、分配系统及计算机可读存储介质。

背景技术

随着共享经济的快速发展，对于社会资源的发掘和利用已上升到一新高度。其中，尤属顺风车、快车等网约车的发展最为迅速。其利用已有车辆的同行、同路资源，一方面可节省对于道路资源的利用，另一方面也生成了新一代的运营和消费方式。

在现有的网约车领域中，不少网约车的运营商为快速占领市场，对于网约车实际场景中的复杂情况考虑较少，为用户随机分配司机，同时也不考虑订单行程中可能经过的地点是否对于行驶有要求。由此带来不少网约车对于用户侧和司机侧的糟糕体验，使得用户对于网约车失去信息。

此外，不少网约车也为用户提供了预定网约车的服务，但对于未来时间内行程的执行，网约车司机受到的监管及行程是否可准时开始执行、顺利执行完成等欠缺，使得用户在享受预定网约车服务时，遭受到许多不佳的体验。

因此，需要一种在预定网约车订单形成时智能分配用户和司机的订单分派方法和系统，解决行驶过程中可能出现的极端情况，降低采用电动车进行网约车服务时的电量耗尽风险，提升用户和司机的使用体验。

发明内容

为了克服上述技术缺陷，本发明的目的在于提供一种订单分配方法、分配系统及计算机可读存储介质，使得预定网约车的行程更为顺畅，提高订单的准时执行率，节省用户的等待时间，提高网约车的运营效率。

本发明公开了一种订单分配方法，包括以下步骤：

基于一预定订单请求，获取所述预定订单请求指向的订单起点、订单终点和预定时间；

获取以所述订单起点为中心，一预设距离为半径的划定区域内运营司机的司机信息；

筛选所述运营司机驾驶的车辆的车牌符合所述订单请求指向的订单城市的限号规则，形成第一车辆组；

筛选所述第一车辆组中车辆的所属地匹配所述订单起点和/或所述订单起点所属地的车辆，形成第二车辆组；

广播所述预定订单请求至所述第二车辆组内的每一运营司机，接收任一运营司机针对所述预定订单请求的优先接单响应，以确定所述车辆为匹配所述订单请求的接单车辆；

将所述预定订单请求和接单车辆的信息交互至生成所述预定订单请求的用户和所述接单车辆的运营司机。

优选地，将所述预定订单请求和接单车辆的信息交互至生成所述预定订单请求的用户和所述接单车辆的运营司机的步骤后，还包括：

于所述预定时间前的冗余时间所述车辆发送当前的剩余电量和/或剩余里程至一服务端；

所述服务端计算车辆行驶所述订单起点至所述订单终点间的行驶距离的期望电量，并比较所述期望电量及剩余电量；

和/或

所述服务端比较所述行驶距离及剩余里程；

当所述期望电量小于所述剩余电量的车辆，和/或所述行驶距离小于所述剩余里程的车辆，服务端向所述运营司机发送充电提醒。

优选地，所述服务端计算车辆行驶所述行驶距离的期望电量，并比较所述期望电量及剩余电量的步骤，和/或所述服务端比较所述行驶距离及剩余里程的步骤中，所述行驶距离包括：所述车辆行驶至所述订单起点的第一距离、所述车辆自所述订单起点行驶至所述订单终点的第二距离及所述车辆自所述订单终点至距所述订单终点最近的充电位置的第三距离。

优选地，所述服务端计算车辆行驶所述订单起点至所述订单终点间的行驶距离的期望电量，并比较所述期望电量及剩余电量的步骤还包括：

所述服务端比较所述期望电量及所述剩余电量的预设百分比；

和/或

所述服务端比较所述行驶距离及剩余里程的步骤包括：

所述服务端比较所述行驶距离及剩余里程与一冗余里程的差值。

优选地，将所述预定订单请求和接单车辆的信息交互至生成所述预定订单请求的用户和所述接单车辆的运营司机的步骤后，还包括：

于所述预定时间的设定时域前，发送停止接单指令至所述接单车辆；

运营司机根据所述停止接单指令放弃所述预定订单请求外的任意行程订单以执行所述预定订单请求。

优选地，筛选所述第一车辆组中车辆的所属地匹配所述订单起点和/或所述订单起点所属地的车辆，形成第二车辆组的步骤后，还包括：

根据所述第二车辆组中运营司机的评价等级降序排列，形成第三车辆组；

广播所述预定订单请求至所述第二车辆组内的每一运营司机的步骤替换为：

根据所述第三车辆组的车辆排列顺序，依次发送所述预定订单请求至所述第三车辆组内的每一运营司机。

优选地，基于一预定订单请求，获取所述预定订单请求指向的订单起点、订单终点和预定时间的步骤后，还包括：

判断所述订单起点和/或订单终点是否位于服务区域；

当所述订单起点和/或订单终点位于服务区域内时，执行后续步骤；

当所述订单起点和/或订单终点位于服务区域外时，发送一订单请求停止消息至发出所述预定订单请求的用户端。

优选地，所述订单分配方法还包括以下步骤：

当所述第一车辆组和/或第二车辆组形成失败时，发送一订单请求停止消息至发出所述预定订单请求的用户端。

本发明还公开了一种订单分配系统，所述订单分配系统包括：

订单接收模块，接收一预定订单请求，获取所述预定订单请求指向的订单起点、订单终点和预定时间；

处理模块，与所述订单接收模块连接，接收所述预定订单请求，其中所述处理模块包括：

第一筛选单元，获取以所述订单起点为中心，一预设距离为半径的划定区域内运营司机的司机信息；

第二筛选单元，筛选所述运营司机驾驶的车辆的车牌符合所述订单请求指向的订单城市的限号规则，形成第一车辆组；

第三筛选单元，与筛选所述第一车辆组中车辆的所属地匹配所述订单起点和/或所述订单起点所属地的车辆，形成第二车辆组；

广播模块，与所述处理模块连接，广播所述预定订单请求至所述第二车辆组内的每一运营司机，接收任一运营司机针对所述预定订单请求的优先接单响应，以确定所述车辆为匹配所述订单请求的接单车辆；

派单模块，与所述广播模块连接，将所述预定订单请求和接单车辆的信息交互至生成所述预定订单请求的用户和所述接单车辆的运营司机。

本发明又公开了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上所述的订单分配方法的步骤。

采用了上述技术方案后，与现有技术相比，具有以下有益效果：

1.考虑到行驶的车辆为纯电动车，提前提醒司机接单后续航能力不够的问题，降低中途滞留问题的风险；

2.快速地为用户筛选司机，减少用户的等待时间；

3.提前筛除不符合运营标准的车辆，防止订单行程时为规避交通规定而造成的驾驶风险。

附图说明

图1为符合本发明一实施例中订单分配方法的流程示意图；

图2为符合本发明一优选实施例中订单分配方法的流程示意图；

图3为符合本发明另一优选实施例中订单分配方法的流程示意图；

图4为符合本发明又一优选实施例中订单分配方法的流程示意图；

图5为符合本发明一优选实施例中订单分配系统的结构示意图。

具体实施方式

以下结合附图与具体实施例进一步阐述本发明的优点。

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

在本公开使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本公开。在本公开和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本公开可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本公开范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

在本发明的描述中，需要理解的是，术语“纵向”、“横向”、“上”、“下”、“前”、“后”、“左”、“右”、“竖直”、“水平”、“顶”、“底”“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。

在本发明的描述中，除非另有规定和限定，需要说明的是，术语“安装”、“相连”、“连接”应做广义理解，例如，可以是机械连接或电连接，也可以是两个元件内部的连通，可以是直接相连，也可以通过中间媒介间接相连，对于本领域的普通技术人员而言，可以根据具体情况理解上述术语的具体含义。

在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明的说明，其本身并没有特定的意义。因此，“模块”与“部件”可以混合地使用。

参阅图1，为符合本发明一优选实施例中订单分配方法的流程示意图。在该实施例中，在网约车运营领域，一用户为从某一起点至一终点，将向网约车的运营商发出行程要求，对于用户的需求，将执行以下步骤以实现对于该行程要求的车辆派发：

S100：基于一预定订单请求，获取所述预定订单请求指向的订单起点、订单终点和预定时间

由于网约车的业务模式为将用户从某一起点通过车辆驾驶的方式运送至另一终点。因此，用户将发送一预定订单请求至运营有该网约车的运营商处，如运营商搭建的服务器端。服务器端根据该预定订单请求，将读取用户生成该预定订单请求时确定的订单起点和订单终点。可以理解的是，该预定订单起点可以是用户当前所处位置，或用户希望行驶行程开始的位置。而订单终点是用户期望的行程结束的位置，订单起点或订单终点均可以道路、标志性建筑、标志性场景等方式表现。

在该实施例中，预定订单请求为以发出该预定订单请求为基准的未来某时刻下，用户期望有车辆执行网约车服务的请求表现。因此，预定订单请求中包括有用户希望该订单执行的开始时间的预定时间。该预定时间可以是某一具体时刻，亦或是某一具体时刻的前后时间段内的任意时刻。由于该预定订单请求为未来的订单请求，因此订单起点可以与用户发出预定订单请求时所处位置不同或相同。一优选实施例中，预定订单请求在时域上可延伸的时间为72小时，即预定时间可以是在发出预定订单请求的当前时刻下后推72小时内的任意时刻，以满足用户尽早确定来接车辆。

S200：获取以订单起点为中心，一预设距离为半径的划定区域内运营司机的司机信息

为减少发起用车的订单请求的用户的等待时间，对于订单请求可派发对象与发出订单请求的用户距离将作为订单分配的筛选标准，具体地，将以发起订单起点的用户当前位置为中心，或当订单请求的属性为替他人代叫用车时，以用户期望上车地点，即订单起点为中心，向其四周以一预设距离为半径划定的区域作为可分配订单区域。也就是说，划定区域的形状为圆形或接近于圆形。预设距离的设置可以是网约车运营商经过调研后得到的用户通常可接受等待时长，及车辆运行速度综合得到的距离。例如，预设距离可以是4km，控制运营司机自接单或被分配到订单后至前往到订单起点的时间在10-15分钟内。可以理解的是，在不同的路况、划定区域内运营司机的数量下，预设距离可以是浮动的，例如，在早高峰时，可以以接送用户为先，将预设距离设定的较大，则用户可能虽需等待的时间较长，但可保证有运营司机被分配到订单；在路况较好时，也可将预设距离设定的较大，保留数量较多的运营司机；在初始划定区域内已有足够数量的运营司机时，可逐渐减少预设距离，以减少用户等待时间为先。

在得到该划定区域后，将获取该划定区域内所有当前正在运营的运营司机、或是常活跃于该划定区域内的运营司机，或是注册时登记住所在划定区域内的运营司机，以及每一被划入该划定区域内的运营司机的司机信息，如车牌号、车辆类型、司机年龄、驾龄、常活跃区域、车辆剩余电量(车辆为电动车时)等，以作为后续逐层筛选的标准。

同样可以理解的是，在该步骤中，划定区域的划分可以是多次的，例如，在根据运营商后台设定的预设距离所确定的划定区域内，无法获取任何运营司机时，可逐级提高预设距离，以扩大划定区域，如以每级0.5km的范围逐渐增大，一方面保证每一订单请求皆可获得响应，另一方面可保证该订单请求的最终被分配方为最为靠近用户的运营司机所驾驶的运营车辆，最小化用户所需的等待时间。

S300：筛选所述运营司机驾驶的车辆的车牌符合所述订单请求指向的订单城市的限号规则，形成第一车辆组

考虑到不少城市为保证路况的良好通行，常设有限行、限号的规则，如在指定时间内，仅允许车牌号末尾为单数、双数或指定数字的车辆运行，为防止被分配订单的车辆为上述规则的受限车辆，导致行程中途被喊停、截止的风险，因此，在已筛选的运营司机所驾驶的车辆中，将筛选出符合订单请求所指向的订单城市的限号规则的车辆，形成第一车辆组。

可以理解的是，上文所说的订单请求所指向的订单城市，包括了订单起点所在的城市、订单终点所在的城市及订单起点至订单终点中行程可能经过的城市，如一用户发出订单请求，从A城市前往B城市，则需同时考虑到A城市在当天的限号规则，及B城市在当前的限号规则，两者同时考量和筛选后形成第一车辆组。

S400：筛选第一车辆组中车辆的所属地匹配订单起点和/或订单起点所属地的车辆，形成第二车辆组

考虑到网约车的实际运营中，常出现用户需从某城市前往另一城市的运营需求，而车辆的驾驶过程中，可能部分城市对于车辆的车牌有部分的限制，如订单起点或订单终点位于两城市的交界处，一城市不允许另一城市的车牌注册城市有运行限制，则在该情况下，更应将订单分配给该城市允许运行的车辆。鉴于此，将对第一车辆组中车辆的所属地匹配订单起点和/或订单起点所属地进行筛选，满足上述城市边界要求的车辆挑选出后，形成第二车辆组。通过该实施例中订单分配规则的设置，可将网约车实际运营时可能出现的阻碍情况清除，在网约车订单形成后，不会出现影响行程的情况。

S500：广播预定订单请求至第二车辆组内的每一运营司机，接收任一运营司机针对预定订单请求的优先接单响应，以确定车辆为匹配订单请求的接单车辆

分别经过划定区域、限号规则、所属地匹配后所筛得的第二车辆组内的车辆由于符合接收预定订单请求的条件，因此，该预定订单请求将被发送至第二车辆组内的每一车辆对应的运营司机处，供所有符合条件的运营司机抢先接取该预定订单请求。首位确认可接收该预定订单请求的运营司机将被视为对于该预定订单请求的优先接单响应，即在众多运营司机中“抢”到订单请求，则该预定订单请求将被派发给发出优先接单响应的运营司机，同时确定其所驾驶的车辆为匹配预定订单请求的接单车辆。

通过公平派单优先接取制度，可调动运营司机接取预定订单请求的积极性，减少用户的等待时间。同时，公平制度可对每一运营司机一视同仁，运营司机在保证后台派单的订单时，也可增加额外的其他订单，提高自身收入，增加运营司机提供网约车服务的热情。

S600：将预定订单请求和接单车辆的信息交互至生成预定订单请求的用户和接单车辆的运营司机

后台确定该接单车辆后，会将该接单车辆的车辆信息发送至发出订单请求的用户端，通知用户其订单请求已被分配至某一运营司机处，该运营司机将将在预定时间前往订单起点执行行程。而同时反向地，也会将用户的信息发送至接单车辆的运营司机，告知运营司机前往何处执行订单，以及告知司机该订单的终点在何处，方便在司机提前规划行程路线。

具有上述配置后，基于各步骤的订单分配方法，一方面控制筛选条件下的计算量，不会给后台造成通信堵塞或负载过大，增加了订单分配的效率，另一方面，考虑到电动车行程过程中可能遇到的风险及突发情况，提前规避，以增强用户对于电动车网约车的乘坐体验。

参阅图2，一优选实施例中，将预定订单请求和接单车辆的信息交互至生成预定订单请求的用户和接单车辆的运营司机的步骤后，还包括：

S700：于预定时间前的冗余时间车辆发送当前的剩余电量和/或剩余里程至一服务端；

S800：服务端计算车辆行驶订单起点至订单终点间的行驶距离的期望电量，并比较期望电量及剩余电量，和/或服务端比较行驶距离及剩余里程；

S900：当期望电量小于剩余电量的车辆时，和/或行驶距离小于剩余里程的车辆，服务端向运营司机发送充电提醒

为配合节能减排的号召及绿色环保城市的构建，运营司机所驾驶的车辆均为电动车，若电动车在驾驶行程中电量耗尽，不再具有行驶能力，将对发起订单请求的用户造成时间和财力上的双重损失。因此，为保证订单执行时电动车辆的电量足以支撑整个行程，将在订单开始前提前判断车辆的剩余电量，或是车辆剩余电量可继续行驶的剩余里程。具体地，以预定时间为时间基准，向前倒退一冗余时间，如2小时、1小时、半小时等，向车辆发送数据获取请求，或车辆主动发送数据信息至服务端。根据该数据获取请求，后台将获得车辆上传的当前的剩余电量或剩余里程。在获取车辆的剩余电量或剩余里程后，同时将计算订单起点与订单终点间的行驶距离，并根据每公里耗电量、或驾驶经验计算对于每一预定订单请求的行驶距离，续航该行驶距离所需电量为期望电量，仍可继续驾驶的行程为剩余里程。当期望电量大于车辆的剩余电量时，则表示车辆目前电量充足，足够支撑整个行程；当期望电量小于车辆的剩余电量时，则表示车辆具有在行程中途电量耗尽的风险，需要充电以提高剩余电量。在此情况下，服务端将向运营司机发送充电提醒，提醒运营司机在开始执行预定订单请求前，先行将车辆的电量充满或充够，以降低在中途滞留的风险。

该实施例中，更为具体的实现方式为：

对于运营司机所驾驶的车辆的剩余电量和/或剩余里程的获取方式，可采用对车辆内实时预存有剩余电量和/或剩余里程的设备读取的方式获得。例如，或剩余电量和/或剩余里程信息存储在车辆MCU内，则通过车辆内的通信模块自MCU获得后主动地转发至服务端；亦或是剩余电量和/或剩余里程信息存储在一单独设备内，该单独设备包括有存储模块及通信模块，其响应于服务端向运营司机驾驶的车辆发送的数据获取请求，将实时获取的剩余电量和/或剩余里程信息发送至服务端。由于该剩余电量信息为车辆内MCU或单独设备实时地向车辆的电池组获取的，因此，在向服务端发送该信息时，也为当前时刻下电池组实际具有剩余电量，保证初始信息的准确性。服务端，亦可称为网约车辆运营商所搭建的服务后台，在获取到车辆的剩余电量前，或获取到车辆的剩余电量和/或剩余里程后，计算与车辆行驶所需行程距离匹配的期望电量，并将所获得的期望电量与车辆具有的剩余电量作比较，确定期望电量是否小于剩余电量，行驶距离是否小于剩余里程，即车辆具有的续航能力需可支撑该行程。可以理解的是，在该实施例中，所需行程距离的获得，可根据订单起点至订单终点的最短行驶路径、或最短行驶时长、最少高速公路收费、最少监控探头等不同用户喜好路径确定。同时，期望电量的计算所得方式，也可根据每单位公里下耗电量计算所得，或是其他用户的相似历史行程的实际耗电量的经验所得。

进一步地，在上述实施例中，服务端计算车辆行驶行驶距离的期望电量，并比较期望电量及剩余电量的步骤，和/或所述服务端比较所述行驶距离及剩余里程的步骤S320中，行驶距离具体地包括：预定时间的冗余时间的该时刻下，车辆行驶至订单起点的第一距离、车辆自订单起点行驶至订单终点的第二距离及车辆自订单终点至距订单终点最近的充电位置的第三距离。其中，第一距离即为运营司机当前时刻下前往订单起点的所需距离；第二距离即为执行订单行程的所需距离；第三距离为考虑到司机侧若在订单执行完后，车辆剩余电量耗尽，造成司机被滞留在路上的恶劣情况，为避免该情况的发生，车辆的剩余电量除需要支撑行驶完全程外，还需支撑司机将车辆开往充电位置。因此，行驶距离包括上述三种距离后，对于期望电量的消耗考虑将从订单分配开始至运营司机驾驶至充电位置为止，同时保证用户和司机均不会由于电量不够而导致被滞留在行驶路程中。

另一优选或可选实施例中，服务端计算车辆行驶行驶距离的期望电量，并比较期望电量及剩余电量的步骤还包括：服务端比较期望电量及剩余电量的预设百分比。在服务端内，预设有一预设百分比，在比较期望电量与剩余电量时，不将两者直接比较，而是比较剩余电量的部分。具体地，剩余电量与预设百分比相乘所得的积为与期望电量比较的比较对象。预设百分比可以是60％、80％等不超过100％的值。通过预设百分比的设置，使得对于剩余电量的考量留有部分冗余量。上述配置主要考虑到电动车在行驶过程中，电量的消耗将受外部环境温度、消耗方式、行驶速度等多方面的影响，冗余量的额外设置，可进一步避免电动车滞留在行程中途的情况发生。

或采用另一种以距离为比较标准的比较方式：服务端比较行驶距离及剩余里程。

由于不同车辆对于电量的消耗及电池的损耗不同，以期望电量作比可能出现误判的情况。因此可以结合电量比较或单独使用以行驶距离及剩余里程为比较对象的方式，获取车辆仍可继续驾驶的剩余里程(由该车内处理设备根据本车的历史电量消耗所得)，并将剩余里程与行驶距离比较。

一优选实施例中，步骤S200与S300间，还将先行筛选当前正在运营的运营司机，即部分通过应用程序操作，将自身定义为允许接收实时接单服务的司机，以符合司机的自身期望。例如，司机利用应用程序将自身状态切换为允许接收实时订单或预约订单，或两种皆可。在选择接受预约订单时，需要选择可以接受的时间窗口，比如早上9:00至上午12:00。那么在筛选司机的时候需要筛选已切换为在预定时间内为允许接单的司机为运营司机。

参阅图3，将预定订单请求和接单车辆的信息交互至生成预定订单请求的用户和接单车辆的运营司机的步骤S600后，还包括：

S700’：于预定时间的设定时域前，发送停止接单指令至接单车辆；

S800’：运营司机根据停止接单指令放弃预定订单请求外的任意行程订单以执行预定订单请求

为保证提前发出预定订单请求指令的用户可在预定时间准时开始执行行程，在该优选实施例中，将限制运营司机在预定时间前的额外接单。因此，以预定时间为时间基准，向前倒推的设定时域前，如预定时间前30分钟、15分钟等，发送停止接单指令至接单车辆，一方面提醒司机尽快前往订单起点接取用户，另一方面后台也将限制其他任何形式的订单请求(即时订单请求或预定订单请求)在该设定时域段内被发送至接单车辆的运营司机处。运营司机根据该停止接单指令的限制，将放弃预定订单请求外的任意行程订单以执行预定订单请求，保证接单车辆对于预定订单请求的服务专注度，提高用户接收服务时的用户体验。

另一优选或可选实施例中，筛选第一车辆组中车辆的所属地匹配订单起点和/或订单起点所属地的车辆，形成第二车辆组的步骤S400后，还包括：

S500’：根据第二车辆组中运营司机的评价等级降序排列，形成第三车辆组；

广播预定订单请求至第二车辆组内的每一运营司机的步骤替换为：

根据第三车辆组的车辆排列顺序，依次发送预定订单请求至第三车辆组内的每一运营司机。

在该一优选实施例中，将额外设置一对于司机运营服务的优先规则。具体地，在用户完成行程后，可对于被分配订单的运营司机进行打分，则每一运营司机具有自身的评分或评级的评价系统，根据该评价系统进行排列，使得每一运营司机接收到的预定清单请求的起始时间并不一致，通过差异化的配置刺激运营司机对每一行程提供优质的服务。举例来说，第三车辆组内的所有车辆对应的运营司机按照评价等级排列后，后台广播预定订单请求也将间隔性地按照由高到低的顺序发送，如在发送预定订单请求至排列第一位的运营司机后，间隔1秒再发送预定订单请求至排列第二位的运营司机，再间隔1秒发送预定订单请求至排列第三位的运营司机，由此类推，使得运营司机为提早接收到预定订单请求，需提高自身的评价等级，间接提高运营司机对于行程的重视度。也就是说，优先将抢单机会分配给预设排名，如前5、前3的司机的车辆，一方面可保证用户享受到的为高质量的网约车服务，另一方面可激励司机为每一用户提供高质量的网约车服务，形成一良性闭环，对于整个网约车的质量作大幅提升。

参阅图4，在又一优选或可选实施例中，基于一预定订单请求，获取所述预定订单请求指向的订单起点、订单终点和预定时间的步骤S100后，还包括：S210：判断订单起点和/或订单终点是否位于服务区域；S220：当订单起点和/或订单终点位于服务区域内时，执行后续步骤；S230：当订单起点和/或订单终点位于服务区域外时，发送一订单请求停止消息至发出预定订单请求的用户端。在该实施例中，考虑到部分城市或地区对于社会车辆可运行区域的限制，在订单分配和筛选前，将进行区域过滤，即判断订单起点和/或订单终点是否位于服务区域，如已办理网约车牌照的城市或区域、军事管理区域、限行区域等，若订单起点和/或订单终点位于服务区域外时，发送一订单请求停止消息至发出订单请求的用户端，提前通知用户不会匹配相关的运营车辆，或更换订单起点和/或订单终点，重新发起订单请求。在服务端，优先确定是否可执行订单，可节省服务端的负载资源，保证其他正常订单请求的快速配置和执行。

在上述任一实施例中，订单分配方法还包括以下步骤：S1000：当第一车辆组和/或第二车辆组形成失败时，发送一订单请求停止消息至发出预定订单请求的用户端。也就是说，当划分区域内不具有运营车辆时，将告知用户无匹配车辆及订单请求停止的信息。或告知用户是否可接收加收调度费，优先安排运营车辆，或主动扩大划分区域，增加满足条件的运营车辆的选择概率。

可以理解的是，上述任一实施例中对于运营车辆的筛选步骤，可在实施例中单独执行或结合执行，即根据实际场景确定选择一种或多种筛选的条件。上文中对不同实施例的介绍，并不限制筛选条件的相互结合使用。此外，对于步骤的数字标定，并不代表步骤的执行顺序，仅用于方便标记不同的筛选条件。

参阅图5，本发明还公开了一种订单分配系统，订单分配系统包括：

订单接收模块，接收一订单请求，该订单请求由用户根据自身的需要在智能终端的应用程序内操作形成，或通过电话、网络、短信等方式发起；

处理模块，与订单接收模块连接，接收订单请求，其中处理模块包括：

第一筛选单元，获取以订单起点为中心，一预设距离为半径的划定区域内运营司机的司机信息；

第二筛选单元，筛选运营司机驾驶的车辆的车牌符合订单请求指向的订单城市的限号规则，形成第一车辆组；

第三筛选单元，与筛选第一车辆组中车辆的所属地匹配订单起点和/或订单起点所属地的车辆，形成第二车辆组；

上述第一筛选单元、第二筛选单元、第三筛选单元可集成在同一模块、组件内或分开设立，并不作限制。

广播模块，与处理模块连接，广播预定订单请求至第二车辆组内的每一运营司机，接收任一运营司机针对预定订单请求的优先接单响应，以确定车辆为匹配订单请求的接单车辆；

派单模块，与广播模块连接，将预定订单请求和接单车辆的信息交互至生成预定订单请求的用户和接单车辆的运营司机。

本发明还公开了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现如上所述的订单分配方法的步骤。处理器可以是安装在智能终端内的处理器，如CPU等。

智能终端可以以各种形式来实施。例如，本发明中描述的终端可以包括诸如移动电话、智能电话、笔记本电脑、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、导航装置等等的智能终端以及诸如数字TV、台式计算机等等的固定终端。下面，假设终端是智能终端。然而，本领域技术人员将理解的是，除了特别用于移动目的的元件之外，根据本发明的实施方式的构造也能够应用于固定类型的终端。

应当注意的是，本发明的实施例有较佳的实施性，且并非对本发明作任何形式的限制，任何熟悉该领域的技术人员可能利用上述揭示的技术内容变更或修饰为等同的有效实施例，但凡未脱离本发明技术方案的内容，依据本发明的技术实质对以上实施例所作的任何修改或等同变化及修饰，均仍属于本发明技术方案的范围内。

Claims (10)

1.一种订单分配方法，其特征在于，包括以下步骤：

基于一预定订单请求，获取所述预定订单请求指向的订单起点、订单终点和预定时间；

获取以所述订单起点为中心，一预设距离为半径的划定区域内运营司机的司机信息；

筛选所述运营司机驾驶的车辆的车牌符合所述订单请求指向的订单城市的限号规则，形成第一车辆组；

筛选所述第一车辆组中车辆的所属地匹配所述订单起点和/或所述订单起点所属地的车辆，形成第二车辆组；

广播所述预定订单请求至所述第二车辆组内的每一运营司机，接收任一运营司机针对所述预定订单请求的优先接单响应，以确定所述车辆为匹配所述预定订单请求的接单车辆；

将所述预定订单请求和接单车辆的信息交互至生成所述预定订单请求的用户和所述接单车辆的运营司机。

2.如权利要求1所述的订单分配方法，其特征在于，将所述预定订单请求和接单车辆的信息交互至生成所述预定订单请求的用户和所述接单车辆的运营司机的步骤后，还包括：

于所述预定时间前的冗余时间所述车辆发送当前的剩余电量和/或剩余里程至一服务端；

所述服务端计算车辆行驶所述订单起点至所述订单终点间的行驶距离的期望电量，并比较所述期望电量及剩余电量；

和/或

所述服务端比较所述行驶距离及剩余里程；

当所述期望电量小于所述剩余电量的车辆，和/或所述行驶距离小于所述剩余里程的车辆，服务端向所述运营司机发送充电提醒。

3.如权利要求2所述的订单分配方法，其特征在于，

所述服务端计算车辆行驶所述行驶距离的期望电量，并比较所述期望电量及剩余电量的步骤，和/或所述服务端比较所述行驶距离及剩余里程的步骤中，所述行驶距离包括：所述车辆行驶至所述订单起点的第一距离、所述车辆自所述订单起点行驶至所述订单终点的第二距离及所述车辆自所述订单终点至距所述订单终点最近的充电位置的第三距离。

4.如权利要求2所述的订单分配方法，其特征在于，

所述服务端计算车辆行驶所述订单起点至所述订单终点间的行驶距离的期望电量，并比较所述期望电量及剩余电量的步骤还包括：

所述服务端比较所述期望电量及所述剩余电量的预设百分比；

和/或

所述服务端比较所述行驶距离及剩余里程的步骤包括：

所述服务端比较所述行驶距离及剩余里程与一冗余里程的差值。

5.如权利要求1所述的订单分配方法，其特征在于，

将所述预定订单请求和接单车辆的信息交互至生成所述预定订单请求的用户和所述接单车辆的运营司机的步骤后，还包括：

于所述预定时间的设定时域前，发送停止接单指令至所述接单车辆；

运营司机根据所述停止接单指令放弃所述预定订单请求外的任意行程订单以执行所述预定订单请求。

6.如权利要求1所述的订单分配方法，其特征在于，

筛选所述第一车辆组中车辆的所属地匹配所述订单起点和/或所述订单起点所属地的车辆，形成第二车辆组的步骤后，还包括：

根据所述第二车辆组中运营司机的评价等级降序排列，形成第三车辆组；

广播所述预定订单请求至所述第二车辆组内的每一运营司机的步骤替换为：

根据所述第三车辆组的车辆排列顺序，依次发送所述预定订单请求至所述第三车辆组内的每一运营司机。

7.如权利要求1所述的订单分配方法，其特征在于，

基于一预定订单请求，获取所述预定订单请求指向的订单起点、订单终点和预定时间的步骤后，还包括：

判断所述订单起点和/或订单终点是否位于服务区域；

当所述订单起点和/或订单终点位于服务区域内时，执行后续步骤；

当所述订单起点和/或订单终点位于服务区域外时，发送一订单请求停止消息至发出所述预定订单请求的用户端。

8.如权利要求1所述的订单分配方法，其特征在于，

所述订单分配方法还包括以下步骤：

当所述第一车辆组和/或第二车辆组形成失败时，发送一订单请求停止消息至发出所述预定订单请求的用户端。

9.一种订单分配系统，其特征在于，所述订单分配系统包括：

订单接收模块，接收一预定订单请求，获取所述预定订单请求指向的订单起点、订单终点和预定时间；

处理模块，与所述订单接收模块连接，接收所述预定订单请求，其中所述处理模块包括：

第一筛选单元，获取以所述订单起点为中心，一预设距离为半径的划定区域内运营司机的司机信息；

第二筛选单元，筛选所述运营司机驾驶的车辆的车牌符合所述订单请求指向的订单城市的限号规则，形成第一车辆组；

第三筛选单元，与筛选所述第一车辆组中车辆的所属地匹配所述订单起点和/或所述订单起点所属地的车辆，形成第二车辆组；

广播模块，与所述处理模块连接，广播所述预定订单请求至所述第二车辆组内的每一运营司机，接收任一运营司机针对所述预定订单请求的优先接单响应，以确定所述车辆为匹配所述订单请求的接单车辆；

派单模块，与所述广播模块连接，将所述预定订单请求和接单车辆的信息交互至生成所述预定订单请求的用户和所述接单车辆的运营司机。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1-8任一项所述的订单分配方法的步骤。