用车调度方法、系统、服务器及计算机可读存储介质与流程

本申请涉及数据处理技术领域，特别是涉及一种用车调度方法、系统、服务器及计算机可读存储介质。

背景技术

随着移动通信技术的发展，基于移动互联网的订单服务得到了广泛的应用，例如订餐服务或打车(叫车)服务。一般来说，对于顾客或乘客的订单，系统通常会进行单独处理，例如乘客发起打车请求，系统通过响应生成叫车订单，并根据周边车辆情况将订单发给司机客户端，司机客户端通过点击确认按钮来接收乘客的叫车订单。然而，由于早晚高峰、天气等原因影响，区域供需不平衡的问题日益凸显。为缓解供需不平衡，打车平台会预测未来一段时间内区域的车辆需求，事先调度车辆到供不应求的区域。

在相关技术中，当平台从其他区域调度车辆时，一种情况为采用打表调度的方式，让需求量大的地区的用户承担调度所产生的费用，这必然降低一些人打车的意愿且不利于缓解需求量大的地区的人员疏散效率。另一种情况采用打车平台强制调度车辆的方式，这虽然利于疏散相应地区的人数，但调度所产生的成本转嫁于打车平台和驾驶员。

技术实现要素：

鉴于以上所述现有技术的缺点，本申请的目的在于提供一种用车调度方法、系统、服务器及计算机可读存储介质，以解决现有技术中车辆调度手段无法与用车成本相协调的问题。

为实现上述目的及其他相关目的，本申请的第一方面提供一种用车调度方法，包括以下步骤：获取一时间段内第一区域至第二区域之间的行车路线、行车时间及行车成本；所述第一区域和第二区域是基于地理位置对多个区域进行分区确定的；依据所述行车时间、行车成本、及获取的所述行车路线上用车需求的概率分布预测所述时间段内所述行车路线的用车价格；以及向位于所述第一区域或第二区域的司机用户发送所述时间段内包含有费用的订单信息，或/及向位于所述第一区域或第二区域的乘车用户提供所述时间段内包含有费用的预览信息；所述费用是基于所述用车价格调整获取的。

在所述第一方面的某些实施方式中，所述第一区域或第二区域中的至少一者为用车高需求区域，所述用车高需求区域是基于获取当前用车需求量确定的或者基于历史订单数据确定的。

在所述第一方面的某些实施方式中，所述行车成本包括能耗成本、车辆折旧成本、路桥费用、以及人工成本中的至少一种。

在所述第一方面的某些实施方式中，获取所述行车路线上用车需求的概率分布的步骤包括：获取所述第一区域至第二区域之间在一时间段内产生的历史订单数据，所述历史订单数据中包括订单价格；对所述历史订单数据进行预处理以获得待拟合订单数据；以及采用预设的拟合模型对所述待拟合订单数据进行拟合，并根据所述订单价格以确定所述第一区域至第二区域之间的行车路线上的用车需求的概率分布。

在所述第一方面的某些实施方式中，所述历史订单数据还包括：订单号、用户号、司机号、起点、终点、订单预估价格、以及订单生成时间戳的信息中的一种或多种信息。

在所述第一方面的某些实施方式中，所述拟合模型为对数正态拟合函数模型，所述采用预设的拟合模型对所述待拟合订单数据进行拟合的步骤为，采用预设的对数正态拟合函数模型对所述待拟合订单数据进行拟合，并根据价格以确定所述至少两个区域内用车需求的对数正态概率分布。

在所述第一方面的某些实施方式中，所述对所述历史订单数据进行预处理的步骤包括以下至少一种：对包含司机号的历史订单数据进行数据完善处理；以及依据历史订单数据中的预设字段，剔除无效的历史订单数据。

在所述第一方面的某些实施方式中，调整所述用车价格的步骤包括：在所述用车价格的基础上提升价格以获得所述费用或者在所述用车价格的基础上降低价格以获得所述费用。

在所述第一方面的某些实施方式中，在所述用车价格的基础上提升价格以获得所述费用包括加价、发放补贴、及积分奖励中的至少一种方式；在所述用车价格的基础上降低价格以获得所述费用包括降价、发放优惠券、及积分奖励中的至少一种方式。

本申请第二方面提供一种用车调度系统，包括：获取模块，用于获取一时间段内第一区域至第二区域之间的行车路线、行车时间及行车成本；所述第一区域至第二区域是基于地理位置对多个区域进行分区确定的；预测模块，用于依据所述行车时间、行车成本、及获取的所述行车路线上用车需求的概率分布预测所述时间段内所述行车路线的用车价格；以及发送模块，用于向位于所述第一区域或第二区域的司机用户发送所述时间段内包含有费用的订单信息，或/及向位于所述第一区域或第二区域的乘车用户提供所述时间段内包含有费用的预览信息；所述费用是基于所述用车价格调整获取的。。

在所述第二方面的某些实施方式中，所述第一区域或第二区域中的至少一者为用车高需求区域，所述用车高需求区域是基于获取当前用车需求量确定的或者基于历史订单数据确定的。

在所述第二方面的某些实施方式中，所述行车成本包括能耗成本、车辆折旧成本、路桥费用、以及人工成本中的至少一种。

在所述第二方面的某些实施方式中，所述预测模块包括：拟合单元，用于对所述第一区域至第二区域之间在一时间段内产生的历史订单数据进行预处理以获得待拟合订单数据；所述历史订单数据中包括订单价格；以及预测单元，用于采用预设的拟合模型对所述待拟合订单数据进行拟合，并根据所述订单价格以确定所述至少两个区域内的相同路线上的用车需求的概率分布。

在所述第一方面的某些实施方式中，所述历史订单数据还包括：订单号、用户号、司机号、起点、终点、订单预估价格、以及订单生成时间戳的信息中的一种或多种信息。

在所述第一方面的某些实施方式中，所述拟合模型为对数正态拟合函数模型，所述采用预设的拟合模型对所述待拟合订单数据进行拟合的步骤为，采用预设的对数正态拟合函数模型对所述待拟合订单数据进行拟合，并根据价格以确定所述至少两个区域内用车需求的对数正态概率分布。

在所述第二方面的某些实施方式中，所述拟合单元用于执行以下至少一种：对包含司机号的历史订单数据进行数据完善处理；以及依据历史订单数据中的预设字段，剔除无效的历史订单数据

在所述第二方面的某些实施方式中，所述费用为在所述用车价格的基础上提升价格后的费用；或者在所述用车价格的基础上降低价格后的费用。

在所述第二方面的某些实施方式中，在所述用车价格的基础上提升价格以获得所述费用包括加价、发放补贴、及积分奖励中的至少一种方式；或者在所述用车价格的基础上降低价格以获得所述费用包括降价、发放优惠券、及积分奖励中的至少一种方式。

本申请第三方面提供一种服务器，包括：存储器，用于存储程序代码；一个或多个处理器；其中，所述处理器用于调用所述存储器中存储的程序代码来执行第一方面提供的任一项所述的用车调度方法。

本申请第四方面提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得所述计算机执行上述第一方面提供的任一项所述的用车调度方法。

如上所述，本申请通过考虑用户的用车需求和司机的行车成本生成相应行车路线的用车价格，并根据调度策略对用车价格进行调整，由此实现了基于价格的车辆调度方案，由此有效解决现有技术中车辆调度手段无法与用车成本相协调的问题。

附图说明

图1显示为本申请的用车调度方法在一种实施方式中的流程图。

图2显示为本申请用车调度方法在又一实施方式中的流程图。

图3显示为按照各时间区间所对应的订单价格由小到大顺序排列将自第一区域至第二区域的各待拟合订单数据进行统计的统计图示。

图4显示为拟合图3中统计数据得到的对数正态拟合函数模型的函数曲线。

图5显示为本申请的用车调度系统在一实施方式中的架构示意图。

图6显示为本申请的服务器在一实施方式中的结构示意图。

具体实施方式

以下由特定的具体实施例说明本申请的实施方式，熟悉此技术的人士可由本说明书所揭露的内容轻易地了解本申请的其他优点及功效。

在下述描述中，参考附图，附图描述了本申请的若干实施例。应当理解，还可使用其他实施例，并且可以在不背离本申请的精神和范围的情况下进行机械组成、结构、电气以及操作上的改变。下面的详细描述不应该被认为是限制性的，并且本申请的实施例的范围仅由公布的专利的权利要求书所限定。

再者，如同在本文中所使用的，单数形式“一”、“一个”和“该”旨在也包括复数形式，除非上下文中有相反的指示。应当进一步理解，术语“包括”、“包括”表明存在所述的特征、步骤、操作、元件、组件、项目、种类、和/或组，但不排除一个或多个其他特征、步骤、操作、元件、组件、项目、种类、和/或组的存在、出现或添加。此处使用的术语“或”和“和/或”被解释为包括性的，或意味着任一个或任何组合。因此，“a、b或c”或者“a、b和/或c”意味着“以下任一个：a；b；c；a和b；a和c；b和c；a、b和c”。仅当元件、功能、步骤或操作的组合在某些方式下内在地互相排斥时，才会出现该定义的例外。

体育场地、会展中心、交通枢纽、以及企业园区附近是易出现用车需求和用车供给关系紧张的区域。以利用体育场地举办了一场演唱会为例，当演唱会结束时，大量听众集中退场易导致附近的公共交通无法快速分散。目前，出租车平台可采用强制性调度运力以帮助消化体育场地附近人群集及减少交通压力。除此之外，以网络叫车平台为代表的打车平台也推出了打表叫车服务，以向叫车需求急迫的用户提供打车服务。

然而，强制调度的方式易出现出租车辆过度调度或调度不足的问题。打表叫车服务并非大多数用户的打车需求，这种方式无法有效解决用车供需关系紧张的问题。基于上述示例并推及至其他地区的用车供求关系预测方面，本申请提供一种用车调度方法，旨在通过调整用车需求大于车辆供给的区域以及用车需求小于车辆供给的区域之间的用车价格来调度两区域之间的车辆，由此实现两个用车供需关系不平衡的地区采用打车方式进行车辆调度，有效解决局部地区交通疏导问题。

请参阅图1，显示为本申请的用车调度方法在一种实施方式中的流程图。其中，所述用车调度方法主要由打车平台来执行。所述打车平台可包含计算机设备中的软件和硬件。

在此，所述计算机设备包括但不限于：单台服务器、服务器集群、分布式服务器、或云服务端等。其中，所述云服务端包括公共云(publiccloud)服务端与私有云(privatecloud)服务端，其中，所述公共或私有云服务端包括software-as-a-service(软件即服务，saas)、platform-as-a-service(平台即服务，paas)及infrastructure-as-a-service(基础设施即服务，iaas)等。所述私有云服务端例如阿里云计算服务平台、亚马逊(amazon)云计算服务平台、百度云计算平台、腾讯云计算平台等。

在此，所述打车平台包括但不限于以下至少一种：基于互联网的打车平台，出租车调度平台等。其中，所述基于互联网的打车平台包括但不限于以下至少一种：顺风车打车平台、拼车打车平台、专车打车平台等。所述打车平台还包括基于历史订单数据进行数据分析的部分，以及基于打车请求进行车辆搜寻和向司机侧发送订单确认的部分等。

在一些实施方式中，所述打车平台基于预设时间间隔执行本申请的用车调度方法，以进行日常车辆调度。在又一些实施方式中，当基于事件所在区域而产生用车需求大于车辆供给时，所述打车平台基于本申请的用车调度方法进行车辆调度。其中，所述事件包括但不限于以下至少一种：如演唱会、展览活动、交通故障等孤立事件；如上下班、上下学等潮汐式的规律事件。

在步骤s110中，获取一时间段内第一区域至第二区域之间的行车路线、行车时间及行车成本；所述第一区域至第二区域是基于地理位置对多个区域进行分区确定的。在此，所述打车平台依据预先配置的待调度时间段与历史时间段的映射关系，获取相应历史时间段内第一区域和第二区域之间的行车路线、行车时间及行车成本。

其中，所述映射关系可以利用配置文件配置在软件程序中，也可以依据默认的程序设计规则反映于打车平台获取各信息的搜索条件中。例如，依据待调度的时间段，所述打车平台对应搜索相同时间段的历史数据。所述映射关系应宽泛理解，其可以是此前任意长时间段(如三周前)，也可以包括但不限于：基于一时刻分界的待调度时间段与历史时间段、待调度时间段与历史时间段之间相隔一时间间隔、待调度时间段与历史时间段相一致、基于事件而构建的待调度时间段所对应的历史时间段。例如，所述打车平台待调度的时间段为以当前时刻为起始时刻的一时间段t1，则用于获取所述行车路线、行车时间及行车成本的历史时间段为所述当前时刻之前的一时间段t1’。又如，所述打车平台待调度的时间段为未来的下班高峰时间段，则所述打车平台获取历史多个工作日的下班高峰时间段的行车路线、行车时间及行车成本等。再如，所述打车平台待调度的时间段为未来的演唱会散场时间段，则所述打车平台获取基于历史多次演唱会的散场时间段内的行车路线、行车时间及行车成本等。

其中，所述第一区域和第二区域是打车平台根据待调度时间段所对应的历史时间段所产生的各种数据预测而得到的。其中，所述第一区域和第二区域中的至少一者包括用车需求大于车辆供给的区域(或称为用车高需求地区)，和/或用车需求小于车辆供给的区域(或称为用车低需求地区)。例如，所述第一区域和第二区域可均为用车高需求区域。又如，第一区域和第二区域均为用车低需求区域。再如，第一区域和第二区域其中之一为用车低需求区域且另一各为用车高需求区域。

其中，在一些具体示例中，所述用车高需求区域是基于获取当前用车需求量确定的确定。例如，所述打车平台待调度的时间段为当前时刻开始的一时间段，则基于截止至当前时刻的一历史时间段内所获取的打车请求中起点和终点的地理位置分布情况确定对应的第一区域和第二区域。

在又一具体示例中，所述用车高需求区域是基于历史订单数据确定的。例如，所述打车平台待调度的时间段为演唱会开始之前两个小时，则基于数据库中存储的与所述演唱会相同场地且开始前两个小时的历史订单数据确定对应的第一区域和第二区域，其中，所述第一区域或第二区域为所述场地位置所在区域。

其中，所述历史订单数据是基于所获取的各类打车请求生成的。所述打车请求包括但不限于以下至少一种：拼车请求、出租车叫车请求、顺风车叫车请求。所述打车请求中包含有起点、终点、用车时间等。所生成的历史订单数据包括但不限于订单价格、起点、终点、以及行车时间等，还可以包含订单号、用户号、司机号中的至少一种。其中，所述订单价格包括订单预估价格和订单实际价格等。所述行车时间包括订单生成时间、车辆预约时间、订单完成时间等。例如，用户操作移动通信设备向所述打车平台发送出租车请求，并在乘坐所述打车平台所提供的车辆行驶到目的地时完成付费，打车平台生成一订单数据。又如，用户操作移动通信设备向所述打车平台发送出租车请求，并在司机接单后主动撤销，打车平台生成一订单数据。再如，用户操作移动通信设备仅向所述打车平台发送用于预览打车价格的请求，以期望查看打车价格，打车平台也生成一订单数据。

在此，在一些实施方式中，所述第一区域和第二区域可以是基于地理位置而预先划分得到的。在另一些实施方式中，所述打车平台基于上述任一种方式确定的时间段，获取所有行车路线，并基于各行车路线的起点和终点进行聚类处理，以得到多个区域，再根据供需关系、甚至根据事件所在地理位置选择第一区域和第二区域。其中，所述聚类处理举例包括将所统计的不同行车路线上的起点和/或终点之间的距离小于预设距离阈值的地理位置划分为一个区域。例如，所述打车平台选择任意两个不同供需关系的区域作为第一区域和第二区域。又如，所述打车平台根据产生事件的地理位置所在区域选择该区域和其他区域作为第一区域和第二区域。

按照上述任一种方式确定待调度时间段、第一区域和第二区域，所述打车平台获取第一区域至第二区域之间的行车路线、行车时间及行车成本。例如，所述打车平台基于上述任一种方式确定的时间段，获取起点位于所述第一区域内、终点位于所述第二区域内的所有行车路线，以及每个行车路线所对应的行车时间和行车成本等数据。又如，所述打车平台基于上述任一种方式确定的时间段，获取起点位于第二区域内、终点位于第一区域内所有行车路线，以及每个行车路线所对应的行车时间和行车成本等数据。再如，所述打车平台基于上述任一种方式确定的时间段，既获取起点位于所述第一区域内、终点位于所述第二区域内的各数据，又获取起点位于第二区域内、终点位于第一区域内的各数据。

在一些实施方式中，所述打车平台直接自数据库中获取第一区域至第二区域之间的行车路线、行车时间及行车成本等数据。

在又一些实施方式中，所述打车平台获取相应时间段的、第一区域至第二区域之间的历史订单数据，并通过对历史订单数据进行处理而获得第一区域至第二区域之间的行车路线、行车时间及行车成本等数据。其中，所述打车平台基于所获取的各历史订单数据中的起点和终点统计自第一区域至第二区域的行车路线，以及自第二区域至第一区域的行车路线。所述打车平台根据各历史订单数据中的订单预估价格或订单实际价格统计自第一区域至第二区域的行车时间及行车成本，和/或自第二区域至第一区域的行车时间及行车成本。在一些情况下，所述打车平台还可以获取对应时间段的路况信息，结合所述路况信息和历史订单数据统计自第一区域至第二区域的行车时间及行车成本，和/或自第二区域至第一区域的行车时间及行车成本。

在另一实施方式中，所述打车平台获取当前待调度时间段、第一区域至第二区域之间的打车请求，并根据当前的路况信息统计自第一区域至第二区域，以及自第二区域至第一区域的行车时间和行车成本。例如，所述打车平台基于最近获取的打车请求确定自当前时刻开始的待调度时间段内第一区域至第二区域之间的行车路线、行车时间及行车成本。

其中，所述行车成本包括能耗成本、车辆折旧成本、路桥费用、以及人工成本中的至少一种。所述打车平台可依据上述至少一种行车成本计算行车成本单价，根据第一区域与第二区域之间的行车路线和行车时间确定自第一区域至第二区域及自第二区域至第一区域各自的行车成本。

所述打车平台在获取到可用于预测待调度时间段内第一区域至第二区域之间的行车路线、行车时间和行车成本后，执行步骤s120。

在步骤s120中，依据所述行车时间、行车成本、及获取的所述行车路线上用车需求的概率分布预测所述时间段内所述行车路线的用车价格。

其中，所述用车需求的概率分布是经预先统计历史订单数据获得的。用于获得所述概率分布所使用的历史订单数据可与步骤s110中所使用的历史订单数据无关或相关。为此，为区别于前述步骤s110中所用到的历史订单数据，在后续描述中将用于确定用车需求的概率分布的历史订单数据称为第二历史订单数据。所述概率分布可基于数据库中所有第二历史订单数据统计得到的。

在一些实施方式中，所述用车需求的概率分布是基于行车路线起止点所在区域产生的第二历史订单数据统计而得的。其中，所述用车需求的概率分布包括：经统计自第一区域至第二区域的第二历史订单数据而确定的概率分布，以及经统计自第一区域至第二区域的第二历史订单数据而确定的概率分布。

为此，请参阅图2，其显示为本申请用车调度方法在又一实施方式中的流程图，其中，图2中所示的步骤s120中获取所述行车路线上用车需求的概率分布的步骤包括：步骤s101、s102、s103。需要说明的是，所述打车平台预先获取用车需求的概率分布，并在执行步骤s120时予以调用。其中，根据具体实现方案，所述步骤s101-s103可与步骤s110无必然的时序关系。例如，所述打车平台按照预先基于地理位置所划分的区域统计任意两个有行车方向的区域的用车需求的概率分布，使得在步骤s110中确定第一区域和第二区域时，打车平台获取自第一区域至第二区域以及自第二区域至第一区域的对应概率分布。又如，所述打车平台依据步骤s110中所确定的第一区域和第二区域通过执行步骤s101-s103获取自第一区域至第二区域以及自第二区域至第一区域的对应概率分布。

在步骤s101中，获取所述第一区域至第二区域之间在一时间段内产生的第二历史订单数据，所述第二历史订单数据中包括订单价格。其中，所述第二历史订单数据可以是以包含包含所述第一区域第二区域的搜索条件。其中，所获取的第二历史订单数据中的时间字段构成相应的时间段。所述第二历史订单数据还包含对应待调度时间段的历史时间段的搜索条件而获取的。

本领域技术人员应该理解上述获取第二历史订单数据的方式仅为举例而非对本申请的限制。根据后续步骤的数据分析需要而设置搜索条件，进而得到在一时间段内产生的第二历史订单数据。事实上，所获取的每条第二历史订单数据可以是数据库中完整的第二历史订单数据，也可以是根据搜索条件节选而得的第二历史订单数据。

在步骤s102中，对所述第二历史订单数据进行预处理以获得待拟合订单数据。在此，所获取的第二历史订单数据包含具有完整字段信息的订单数据，以及具有不完整的字段信息的订单数据。其中，具有不完整的字段信息的订单数据举例但不限于以下至少一种：缺少司机号的订单数据、缺少完成时间的订单数据、缺少终点的订单数据、实际行驶里程与叫车请求所对应的起点终点不符的订单数据等。为此，对所获取的第二历史订单数据进行预处理以对所有第二历史订单数据进行筛选、补充和修改中的至少一种处理，以便得到可供拟合处理的拟合订单数据。

在一些实施方式中，所述打车平台对包含司机号的第二历史订单数据进行数据完善处理。其中，所述数据完善处理包括数据补充和/或数据修改。在此，包含司机号的第二历史订单数据是指有司机接单的订单数据，通常来说，当司机接单后，在线下司机按照订单所指示的起止点承载乘客完成订单。然而，也有一些例外情况，比如乘客未按照订单约定，而是与司机另行约定终点，仅借助所述订单完成与司机的乘车交易，则所述订单数据中的订单价格与订单预估价格相差较大。又如，乘客在司机接单后取消订单，则所述订单数据中生成时间戳与完成时间戳之间的时长远小于按照实际行程所对应的时长。再如，司机完成订单后忘记点击订单完成按钮，致使订单数据中无完成时间戳。

在一些具体示例中，所述打车平台依据订单生成时间将包含同一司机号的第二历史订单数据中的订单进行排序；以及基于排序顺序补充至少一个订单的完成时间。在此，针对包含无完成时间的订单数据、或者前一订单数据中完成时间大于后一订单数据中订单生成时间的订单数据等情况，所述打车平台依据订单生成时间对同一个司机号进行订单排序，依据相邻订单数据中后一订单数据中的订单生成时间补充前一订单数据中订单的完成时间。例如，将相邻订单数据中后一订单数据中的订单生成时间作为前一订单数据中订单的完成时间，并更新前一订单数据中完成时间字段中。又如，将所述前一订单数据中的完成时间减去预设的打车时间间隔得到前一订单数据中完成时间并更新该前一订单数据的完成时间字段中，其中，所述打车时间间隔可以是经数据统计得到司机平均接单的时间间隔或其他预设值。

在又一些实施方式，所述打车平台依据第二历史订单数据中的预设字段，剔除无效的第二历史订单数据。其中，在一些具体示例中，所述预设字段可仅为单个字段。例如，所述打车平台依据司机号字段剔除无人接单的订单数据。在又一些具体示例中，所述打车平台预设基于多个字段依据订单数据中多个字段的组合确定无效第二历史订单数据。其中，所述多个字段的组合包括但不限于：起点、终点、订单预估价格、订单生成时间和完成时间字段中至少两个的组合。例如，所述打车平台依据订单预估价格、订单生成时间和订单完成时间分别确定：订单预估价格高于一预设价格且完成时间低于一预设时间的订单作为无效订单；订单预估价格低于一预设价格且完成时间高于一预设时间的订单作为无效订单。又如，所述打车平台依据起点、终点、订单生成时间和完成时间字段确定：预估的行程时长与实际订单持续时长相差至少n倍(n＞1)的订单作为无效订单。在此，所述打车平台将所确定的无效的第二历史订单数据予以剔除。

在再一实施方式中，所述打车平台对第二历史订单数据进行归类处理以便拟合出在不同单价机制下用户用车需求的概率分布。其中，所述打车平台可先按照前述实施方式对第二历史订单数据本身进行筛选和完善，再执行所述归类处理；还可以先执行所述归类处理再对无法归类或每个分类中的第二历史订单数据进行筛选和完善。

为了更精准地掌握相近起点和相近终点的用户的用车需求，所述打车平台自所述第二历史订单数据筛选出位于相同时间区间、第一区域内起点(或终点)、及第二区域内终点(或起点)的第二历史订单数据作为待拟合订单数据。

其中，所述相同时间区间可按照单价所对应的时间区间进行划分；也可以基于预设的单价区间所对应的时间区间进行划分。例如，将订单价格区间设置为[a-δ,a+δ]的无交叠区间，每个订单价格区间所对应的时间区间设置为相同时间区间，其中，a为订单价格，δ为订单价格上下浮动的区间阈值，所述δ可以为固定值或基于第二历史订单数据中其他字段而确定(如所述δ基于相同起点范围和相同终点范围而确定的行程而确定等)。所述相同时间区间还可以按照预设时间间隔将所获取的各第二历史订单数据的时间段进行划分而得的。

在此，所述第一区域和第二区域的确定方式可以借鉴步骤s110，在此不予赘述。

在步骤s103中，采用预设的拟合模型对所述待拟合订单数据进行拟合，并根据所述订单价格以确定所述第一区域至第二区域之间的行车路线上的用车需求的概率分布。

在此，所述打车平台基于各时间区间所对应的单价(或单价区间)将来自步骤s102的待拟合订单数据进行统计。经统计选取与所述统计图示趋势相似的拟合模型进行拟合处理，以得到所述至少两个区域之间行车路线上的用户用车需求的概率分布，利用所述概率分布便于预测当调整单价时，位于所述第二历史订单数据所反映的对应两区域之间行车路线上用户用车需求的变化，从而基于用户用车供需层面解决供需不匹配地区的用车问题。

在一些实施方式中，所述打车平台还执行通过一函数曲线表征所述第一区域至第二区域之间行车路线上的用车需求的概率分布的步骤。在此，所述打车平台将利用所拟合的对数正态拟合函数模型描述的用车需求的概率分布的函数曲线表征所统计的根据所述订单价格以确定两个区域之间行车路线上的打车数据。所述打车平台还可以将所述函数曲线与所对应的打车统计数据予以显示，以供技术人员检查拟合效果。

其中，依据统计所选取的拟合模型为对数正态拟合函数模型，所述步骤s103包括采用预设的对数正态拟合函数模型对所述待拟合订单数据进行拟合，并根据价格以确定所述至少两个区域内用户用车需求的对数正态概率分布。

请参阅图3和图4，其中图3显示为按照各时间区间所对应的订单价格由小到大顺序排列将自第一区域至第二区域的各待拟合订单数据进行统计的统计图示，图4显示为拟合图3中统计数据得到的对数正态拟合函数模型的函数曲线，其中，所述函数曲线的横坐标表征为订单价格，纵坐标表征为经统计的所述第一区域至第二区域的用车需求的概率。其中，由于行程路线相近，故每个相同时间区间内的订单价格反映了各时间区间的单价，图示中的每个柱状图形可视为各单价下自第一区域向第二区域打车人数或打车人数比例。以图3所示的统计图示为例，选取对数正态拟合函数模型进行拟合处理，其中，预设对数正态拟合函数模型中待确定的参数，利用所述待拟合订单数据对待确定的参数进行训练以使得经选取的参数而构建的对数正态拟合函数模型相对于所述统计图示中的统计数据拟合度达到最优条件，其中，所述最优条件包括但不限于：误差小于预设误差范围等。经拟合得到对应图3的自第一区域向第二区域在不同订单价格下用车需求的概率分布可如图4中的函数曲线表示。依据所得到的每对第一区域和第二区域的对数正态拟合函数模型预测待调度的订单价格所对应的用车需求的概率。

由此推及至更普遍地，所述打车平台可基于待调度的任意两个区域构建有行车方向的概率分布，以确定基于不同订单价格下：自低需求区域至高需求区域用户用车需求的概率分布，以及自高需求区域至低需求区域用户用车需求的概率分布。

所述步骤s120包括：依据所述行车时间、行车成本以及第一区域至第二区域之间用车需求的概率分布预测所述时间段内所述行车路线的用车价格。在此，所述打车平台在确保行车成本的基础上，根据所述行车时间和概率分布预测所述时间段内自第一区域至第二区域方向的用户意愿打车的用车价格。在一些具体示例中，在确保行车成本的基础上，所述打车平台依据预设的行车成本与行车时间的非线性对应关系以及依据所述概率分布，计算使得最大化满足用车需求情况下的用车价格。在另一些具体示例中，所述打车平台依据预先构建的行车成本、行车时间、第一区域的用车需求量、第二区域的用车需求量、待调度时间段等中的两个的对应关系，以及所述概率分布，构建使得最大化满足用户的用车需求情况下的用车价格。

在一些实施方式中，所述打车平台在此基础上进一步调整用车价格，其包括：在所述用车价格的基础上提升价格或者在所述用车价格的基础上降低价格，以获得可发送至司机用户和乘车用户查看的费用。其中，在所述用车价格的基础上提升价格以获得所述费用包括加价、发放补贴、及积分奖励中的至少一种方式；在所述用车价格的基础上降低价格以获得所述费用包括降价、发放优惠券、及积分奖励中的至少一种方式。例如，当待调度时间段内第一区域为用车高需求量且第二区域为用车低需求量时，所述打车平台在所得到的自第一区域向第二区域的行车路线的用车价格的基础上提高一价格比例，并将提高的至少部分价格以补贴方式(如电子代金券)提供给乘车用户。又如，当待调度时间段内第一区域为用车低需求量且第二区域为用车高需求量时，所述打车平台在所得到的自第一区域向第二区域的行车路线的用车价格的基础上降低一价格比例，并将降低的至少部分价格以补贴方式(如电子代金券)提供给司机用户。

需要说明的是，上述示例仅为举例，技术人员可根据调度策略设置打车平台调整用车价格的规则，在此不再逐一描述。

在步骤s130中，向位于所述第一区域或第二区域的司机用户发送所述时间段内包含有费用的订单信息，或/及向位于所述第一区域或第二区域的乘车用户提供所述时间段内包含有费用的预览信息；所述费用是基于所述用车价格调整获取的。

在此，所述打车平台通过解析来自乘车用户的打车请求、或者司机用户的预览请求确定在待调度的时间段自第一区域前往第二区域的行程信息，并将包含所计算的费用(若无价格调整则为用车价格)的订单信息发送给位于所述第一区域的司机用户(或反馈给司机用户)的移动通信设备。其中，根据请求的类型，所述订单信息还包括终点、甚至推荐路线等。例如，当乘车用户操作移动通信设备发出打车请求以期望司机用户提供乘车服务时，所述发送模块通过将包含所述费用的订单信息按相距乘客距离由近至远的顺序推送给处于空闲状态的司机用户，以待司机用户接受。其中所述处于空闲状态的司机用户是基于发送模块所登记的与司机用户唯一对应的司机号的属性为空闲而确定的，其中，所述空闲表示司机用户未处于正在载客中且能够接单。

所述打车平台通过解析来自乘车用户的打车请求确定在待调度的时间段自第一区域前往第二区域的行程信息，向所述乘车用户反馈包含有费用的预览信息，以供乘车用户预览打车费用。例如，当乘车用户操作移动通信设备发出打车请求以期望预览费用时，所述打车平台通过将包含所述费用的预览信息反馈给相应乘车用户所持的移动通信设备，以供乘车用户确认是否进一步发出用于打车邀请的打车请求。

需要说明的是，上述示例仅为举例而非对本申请的限制，事实上，乘车用户可能从第二区域打车至第一区域，所述打车平台依据所计算得到的从第二区域打车至第一区域的费用向乘车用户及司机用户发送相应的包含相应费用的预览信息和订单信息。由上述各示例并推及至对整个城市或地区的用车调度，所述打车平台可提供任意时间段和起点所在区域、终点所在区域的用车调度，在此不再赘述。

综上所述，本申请通过考虑用户的用车需求和司机的行车成本生成相应行车路线的用车价格，并根据调度策略对用车价格进行调整，由此实现了基于价格的车辆调度方案，由此有效解决决现有技术中车辆调度手段无法与用车成本相协调的问题。

另外，本申请所提供的用车需求预测方法通过构建用户需求和用车成本的概率分布来实现用车需求的预测，即在预测需求时结合价格因素，分析用户价格敏感度，有利于缓解供需不平衡，为打车平台定价和调度提供有效的可利用数据，由此解决现有技术中处理用车的供需不匹配的方式未考虑用户的用车需求，而造成的调度成本不易掌控的问题，另外，本方法仅需要拟合对数正太分布，参数少，拟合速度快，需要计算资源少。

本申请还提供一种用车调度系统。所述用车调度系统为运行在前述的打车平台中的软件和硬件。请参阅图5，其显示为本申请的用车调度系统在一实施方式中的架构示意图。所述用车调度系统1包括：获取模块11、预测模块12、发送模块13。其中，所述用车调度系统中的各模块可基于数据流向由运行服务器中的存储器、处理器、网络接口等硬件执行。

所述获取模块11用于获取一时间段内第一区域至第二区域之间的行车路线、行车时间及行车成本；所述第一区域至第二区域是基于地理位置对多个区域进行分区确定的。在此，所述获取模块11依据预先配置的待调度时间段与历史时间段的映射关系，获取相应历史时间段内第一区域和第二区域之间的行车路线、行车时间及行车成本。

其中，所述映射关系可以利用配置文件配置在软件程序中，也可以依据默认的程序设计规则反映于获取模块11获取各信息的搜索条件中。例如，依据待调度的时间段，所述获取模块11对应搜索相同时间段的历史数据。所述映射关系应宽泛理解，其可以是此前任意长时间段(如三周前)，也可以包括但不限于：基于一时刻分界的待调度时间段与历史时间段、待调度时间段与历史时间段之间相隔一时间间隔、待调度时间段与历史时间段相一致、基于事件而构建的待调度时间段所对应的历史时间段。例如，所述获取模块11待调度的时间段为以当前时刻为起始时刻的一时间段t1，则用于获取所述行车路线、行车时间及行车成本的历史时间段为所述当前时刻之前的一时间段t1’。又如，所述获取模块11待调度的时间段为未来的下班高峰时间段，则所述获取模块11获取历史多个工作日的下班高峰时间段的行车路线、行车时间及行车成本等。再如，所述获取模块11待调度的时间段为未来的演唱会散场时间段，则所述获取模块11获取基于历史多次演唱会的散场时间段内的行车路线、行车时间及行车成本等。

其中，所述第一区域和第二区域是获取模块11根据待调度时间段所对应的历史时间段所产生的各种数据预测而得到的。其中，所述第一区域和第二区域中的至少一者包括用车需求大于车辆供给的区域(或称为用车高需求地区)，和/或用车需求小于车辆供给的区域(或称为用车低需求地区)。例如，所述第一区域和第二区域可均为用车高需求区域。又如，第一区域和第二区域均为用车低需求区域。再如，第一区域和第二区域其中之一为用车低需求区域且另一各为用车高需求区域。

其中，在一些具体示例中，所述用车高需求区域是基于获取当前用车需求量确定的确定。例如，所述获取模块11待调度的时间段为当前时刻开始的一时间段，则基于截止至当前时刻的一历史时间段内所获取的打车请求中起点和终点的地理位置分布情况确定对应的第一区域和第二区域。

在又一具体示例中，所述用车高需求区域是基于历史订单数据确定的。例如，所述获取模块11待调度的时间段为演唱会开始之前两个小时，则基于数据库中存储的与所述演唱会相同场地且开始前两个小时的历史订单数据确定对应的第一区域和第二区域，其中，所述第一区域或第二区域为所述场地位置所在区域。

其中，所述历史订单数据是基于所获取的各类打车请求生成的。所述打车请求包括但不限于以下至少一种：拼车请求、出租车叫车请求、顺风车叫车请求。所述打车请求中包含有起点、终点、用车时间等。所生成的历史订单数据包括但不限于订单价格、起点、终点、以及行车时间等，还可以包含订单号、用户号、司机号中的至少一种。其中，所述订单价格包括订单预估价格和订单实际价格等。所述行车时间包括订单生成时间、车辆预约时间、订单完成时间等。例如，用户操作移动通信设备向所述获取模块11发送出租车请求，并在乘坐所述获取模块11所提供的车辆行驶到目的地时完成付费，获取模块11生成一订单数据。又如，用户操作移动通信设备向所述获取模块11发送出租车请求，并在司机接单后主动撤销，获取模块11生成一订单数据。再如，用户操作移动通信设备仅向所述获取模块11发送用于预览打车价格的请求，以期望查看打车价格，获取模块11也生成一订单数据。

在此，在一些实施方式中，所述第一区域和第二区域可以是基于地理位置而预先划分得到的。在另一些实施方式中，所述获取模块11基于上述任一种方式确定的时间段，获取所有行车路线，并基于各行车路线的起点和终点进行聚类处理，以得到多个区域，再根据供需关系、甚至根据事件所在地理位置选择第一区域和第二区域。其中，所述聚类处理举例包括将所统计的不同行车路线上的起点和/或终点之间的距离小于预设距离阈值的地理位置划分为一个区域。例如，所述获取模块11选择任意两个不同供需关系的区域作为第一区域和第二区域。又如，所述获取模块11根据产生事件的地理位置所在区域选择该区域和其他区域作为第一区域和第二区域。

按照上述任一种方式确定待调度时间段、第一区域和第二区域，所述获取模块11获取第一区域至第二区域之间的行车路线、行车时间及行车成本。例如，所述获取模块11基于上述任一种方式确定的时间段，获取起点位于所述第一区域内、终点位于所述第二区域内的所有行车路线，以及每个行车路线所对应的行车时间和行车成本等数据。又如，所述获取模块11基于上述任一种方式确定的时间段，获取起点位于第二区域内、终点位于第一区域内所有行车路线，以及每个行车路线所对应的行车时间和行车成本等数据。再如，所述获取模块11基于上述任一种方式确定的时间段，既获取起点位于所述第一区域内、终点位于所述第二区域内的各数据，又获取起点位于第二区域内、终点位于第一区域内的各数据。

在一些实施方式中，所述获取模块11直接自数据库中获取第一区域至第二区域之间的行车路线、行车时间及行车成本等数据。

在又一些实施方式中，所述获取模块11获取相应时间段的、第一区域至第二区域之间的历史订单数据，并通过对历史订单数据进行处理而获得第一区域至第二区域之间的行车路线、行车时间及行车成本等数据。其中，所述获取模块11基于所获取的各历史订单数据中的起点和终点统计自第一区域至第二区域的行车路线，以及自第二区域至第一区域的行车路线。所述获取模块11根据各历史订单数据中的订单预估价格或订单实际价格统计自第一区域至第二区域的行车时间及行车成本，和/或自第二区域至第一区域的行车时间及行车成本。在一些情况下，所述获取模块11还可以获取对应时间段的路况信息，结合所述路况信息和历史订单数据统计自第一区域至第二区域的行车时间及行车成本，和/或自第二区域至第一区域的行车时间及行车成本。

在另一实施方式中，所述获取模块11获取当前待调度时间段、第一区域至第二区域之间的打车请求，并根据当前的路况信息统计自第一区域至第二区域，以及自第二区域至第一区域的行车时间和行车成本。例如，所述获取模块11基于最近获取的打车请求确定自当前时刻开始的待调度时间段内第一区域至第二区域之间的行车路线、行车时间及行车成本。

其中，所述行车成本包括能耗成本、车辆折旧成本、路桥费用、以及人工成本中的至少一种。所述获取模块11可依据上述至少一种行车成本计算行车成本单价，根据第一区域与第二区域之间的行车路线和行车时间确定自第一区域至第二区域及自第二区域至第一区域各自的行车成本。

所述获取模块11在获取到可用于预测待调度时间段内第一区域至第二区域之间的行车路线、行车时间和行车成本后，执行预测模块12。

所述预测模块12用于依据所述行车时间、行车成本、及获取的所述行车路线上用车需求的概率分布预测所述时间段内所述行车路线的用车价格。

其中，所述用车需求的概率分布是经预先统计历史订单数据获得的。用于获得所述概率分布所使用的历史订单数据可与所述获取模块11中所使用的历史订单数据无关或相关。为此，为区别于前述获取模块11中所用到的历史订单数据，在后续描述中将用于确定用车需求的概率分布的历史订单数据称为第二历史订单数据。所述概率分布可基于数据库中所有第二历史订单数据统计得到的。

在一些实施方式中，所述用车需求的概率分布是基于行车路线起止点所在区域产生的第二历史订单数据统计而得的。其中，所述用车需求的概率分布包括：经统计自第一区域至第二区域的第二历史订单数据而确定的概率分布，以及经统计自第一区域至第二区域的第二历史订单数据而确定的概率分布。

为此所述预测模块12预先获取用车需求的概率分布，并价格预测时予以调用。其中，根据具体实现方案，所述预测模块12获取所述概率分布的步骤可与获取模块11获取行车路线、行车时间及行车成本的步骤无必然时序的执行。例如，所述预测模块12按照预先基于地理位置所划分的区域统计任意两个有行车方向的区域的用车需求的概率分布，使得在获取模块11中确定第一区域和第二区域时，预测模块12获取自第一区域至第二区域以及自第二区域至第一区域的对应概率分布。又如，所述预测模块12依据获取模块11中所确定的第一区域和第二区域通过获取自第一区域至第二区域以及自第二区域至第一区域的对应概率分布。在此，所述预测模块12包括拟合单元和预测模块12。

所述拟合单元用于获取所述第一区域至第二区域之间在一时间段内产生的第二历史订单数据，所述第二历史订单数据中包括订单价格。其中，所述第二历史订单数据可以是以包含包含所述第一区域第二区域的搜索条件。其中，所获取的第二历史订单数据中的时间字段构成相应的时间段。所述第二历史订单数据还包含对应待调度时间段的历史时间段的搜索条件而获取的。

本领域技术人员应该理解上述获取第二历史订单数据的方式仅为举例而非对本申请的限制。根据后续步骤的数据分析需要而设置搜索条件，进而得到在一时间段内产生的第二历史订单数据。事实上，所获取的每条第二历史订单数据可以是数据库中完整的第二历史订单数据，也可以是根据搜索条件节选而得的第二历史订单数据。

所述预测单元用于对所述第二历史订单数据进行预处理以获得待拟合订单数据。在此，所获取的第二历史订单数据包含具有完整字段信息的订单数据，以及具有不完整的字段信息的订单数据。其中，具有不完整的字段信息的订单数据举例但不限于以下至少一种：缺少司机号的订单数据、缺少完成时间的订单数据、缺少终点的订单数据、实际行驶里程与叫车请求所对应的起点终点不符的订单数据等。为此，对所获取的第二历史订单数据进行预处理以对所有第二历史订单数据进行筛选、补充和修改中的至少一种处理，以便得到可供拟合处理的拟合订单数据。

在一些实施方式中，所述预测模块12对包含司机号的第二历史订单数据进行数据完善处理。其中，所述数据完善处理包括数据补充和/或数据修改。在此，包含司机号的第二历史订单数据是指有司机接单的订单数据，通常来说，当司机接单后，在线下司机按照订单所指示的起止点承载乘客完成订单。然而，也有一些例外情况，比如乘客未按照订单约定，而是与司机另行约定终点，仅借助所述订单完成与司机的乘车交易，则所述订单数据中的订单价格与订单预估价格相差较大。又如，乘客在司机接单后取消订单，则所述订单数据中生成时间戳与完成时间戳之间的时长远小于按照实际行程所对应的时长。再如，司机完成订单后忘记点击订单完成按钮，致使订单数据中无完成时间戳。

在一些具体示例中，所述预测模块12依据订单生成时间将包含同一司机号的第二历史订单数据中的订单进行排序；以及基于排序顺序补充至少一个订单的完成时间。在此，针对包含无完成时间的订单数据、或者前一订单数据中完成时间大于后一订单数据中订单生成时间的订单数据等情况，所述预测模块12依据订单生成时间对同一个司机号进行订单排序，依据相邻订单数据中后一订单数据中的订单生成时间补充前一订单数据中订单的完成时间。例如，将相邻订单数据中后一订单数据中的订单生成时间作为前一订单数据中订单的完成时间，并更新前一订单数据中完成时间字段中。又如，将所述前一订单数据中的完成时间减去预设的打车时间间隔得到前一订单数据中完成时间并更新该前一订单数据的完成时间字段中，其中，所述打车时间间隔可以是经数据统计得到司机平均接单的时间间隔或其他预设值。

在又一些实施方式，所述预测模块12依据第二历史订单数据中的预设字段，剔除无效的第二历史订单数据。其中，在一些具体示例中，所述预设字段可仅为单个字段。例如，所述预测模块12依据司机号字段剔除无人接单的订单数据。在又一些具体示例中，所述预测模块12预设基于多个字段依据订单数据中多个字段的组合确定无效第二历史订单数据。其中，所述多个字段的组合包括但不限于：起点、终点、订单预估价格、订单生成时间和完成时间字段中至少两个的组合。例如，所述预测模块12依据订单预估价格、订单生成时间和订单完成时间分别确定：订单预估价格高于一预设价格且完成时间低于一预设时间的订单作为无效订单；订单预估价格低于一预设价格且完成时间高于一预设时间的订单作为无效订单。又如，所述预测模块12依据起点、终点、订单生成时间和完成时间字段确定：预估的行程时长与实际订单持续时长相差至少n倍(n＞1)的订单作为无效订单。在此，所述预测模块12将所确定的无效的第二历史订单数据予以剔除。

在再一实施方式中，所述预测模块12对第二历史订单数据进行归类处理以便拟合出在不同单价机制下用户用车需求的概率分布。其中，所述预测模块12可先按照前述实施方式对第二历史订单数据本身进行筛选和完善，再执行所述归类处理；还可以先执行所述归类处理再对无法归类或每个分类中的第二历史订单数据进行筛选和完善。

为了更精准地掌握相近起点和相近终点的用户的用车需求，所述预测模块12自所述第二历史订单数据筛选出位于相同时间区间、第一区域内起点(或终点)、及第二区域内终点(或起点)的第二历史订单数据作为待拟合订单数据。

其中，所述相同时间区间可按照单价所对应的时间区间进行划分；也可以基于预设的单价区间所对应的时间区间进行划分。例如，将订单价格区间设置为[a-δ,a+δ]的无交叠区间，每个订单价格区间所对应的时间区间设置为相同时间区间，其中，a为订单价格，δ为订单价格上下浮动的区间阈值，所述δ可以为固定值或基于第二历史订单数据中其他字段而确定(如所述δ基于相同起点范围和相同终点范围而确定的行程而确定等)。所述相同时间区间还可以按照预设时间间隔将所获取的各第二历史订单数据的时间段进行划分而得的。

在此，所述第一区域和第二区域的确定方式可以借鉴获取模块11确定所述第一区域和第二区域的方式，在此不予赘述。

所述预测单元还用于采用预设的拟合模型对所述待拟合订单数据进行拟合，并根据所述订单价格以确定所述第一区域至第二区域之间的行车路线上的用车需求的概率分布。

在此，所述预测单元基于各时间区间所对应的单价(或单价区间)将待拟合订单数据进行统计。经统计选取与所述统计图示趋势相似的拟合模型进行拟合处理，以得到所述至少两个区域之间行车路线上的用户用车需求的概率分布，利用所述概率分布便于预测当调整单价时，位于所述第二历史订单数据所反映的对应两区域之间行车路线上用户用车需求的变化，从而基于用户用车供需层面解决供需不匹配地区的用车问题。

在一些实施方式中，所述预测单元还执行通过一函数曲线表征所述第一区域至第二区域之间行车路线上的用车需求的概率分布的步骤。在此，所述预测单元将利用所拟合的对数正态拟合函数模型描述的用车需求的概率分布的函数曲线表征所统计的根据所述订单价格以确定两个区域之间行车路线上的打车数据。所述预测单元还可以将所述函数曲线与所对应的打车统计数据予以显示，以供技术人员检查拟合效果。

其中，依据统计所选取的拟合模型为对数正态拟合函数模型，所述步骤s103包括采用预设的对数正态拟合函数模型对所述待拟合订单数据进行拟合，并根据价格以确定所述至少两个区域内用户用车需求的对数正态概率分布。

请参阅图3和图4，其中图3显示为按照各时间区间所对应的订单价格由小到大顺序排列将自第一区域至第二区域的各待拟合订单数据进行统计的统计图示，图4显示为拟合图3中统计数据得到的对数正态拟合函数模型的函数曲线，其中，所述函数曲线的横坐标表征为订单价格，纵坐标表征为经统计的所述第一区域至第二区域的用车需求的概率。其中，由于行程路线相近，故每个相同时间区间内的订单价格反映了各时间区间的单价，图示中的每个柱状图形可视为各单价下自第一区域向第二区域打车人数或打车人数比例。以图3所示的统计图示为例，选取对数正态拟合函数模型进行拟合处理，其中，预设对数正态拟合函数模型中待确定的参数，利用所述待拟合订单数据对待确定的参数进行训练以使得经选取的参数而构建的对数正态拟合函数模型相对于所述统计图示中的统计数据拟合度达到最优条件，其中，所述最优条件包括但不限于：误差小于预设误差范围等。经拟合得到对应图3的自第一区域向第二区域在不同订单价格下用车需求的概率分布可如图4中的函数曲线表示。依据所得到的每对第一区域和第二区域的对数正态拟合函数模型预测待调度的订单价格所对应的用车需求的概率。

由此推及至更普遍地，所述预测单元可基于待调度的任意两个区域构建有行车方向的概率分布，以确定基于不同订单价格下：自低需求区域至高需求区域用户用车需求的概率分布，以及自高需求区域至低需求区域用户用车需求的概率分布。

所述预测单元依据所述行车时间、行车成本以及第一区域至第二区域之间用车需求的概率分布预测所述时间段内所述行车路线的用车价格。在此，所述预测单元在确保行车成本的基础上，根据所述行车时间和概率分布预测所述时间段内自第一区域至第二区域方向的用户意愿打车的用车价格。在一些具体示例中，在确保行车成本的基础上，所述预测单元依据预设的行车成本与行车时间的非线性对应关系以及依据所述概率分布，计算使得最大化满足用车需求情况下的用车价格。在另一些具体示例中，所述预测单元依据预先构建的行车成本、行车时间、第一区域的用车需求量、第二区域的用车需求量、待调度时间段等中的两个的对应关系，以及所述概率分布，构建使得最大化满足用户的用车需求情况下的用车价格。

在一些实施方式中，所述预测单元在此基础上进一步调整用车价格，其包括：在所述用车价格的基础上提升价格或者在所述用车价格的基础上降低价格，以获得可发送至司机用户和乘车用户查看的费用。其中，在所述用车价格的基础上提升价格以获得所述费用包括加价、发放补贴、及积分奖励中的至少一种方式；在所述用车价格的基础上降低价格以获得所述费用包括降价、发放优惠券、及积分奖励中的至少一种方式。例如，当待调度时间段内第一区域为用车高需求量且第二区域为用车低需求量时，所述预测单元在所得到的自第一区域向第二区域的行车路线的用车价格的基础上提高一价格比例，并将提高的至少部分价格以补贴方式(如电子代金券)提供给乘车用户。又如，当待调度时间段内第一区域为用车低需求量且第二区域为用车高需求量时，所述预测单元在所得到的自第一区域向第二区域的行车路线的用车价格的基础上降低一价格比例，并将降低的至少部分价格以补贴方式(如电子代金券)提供给司机用户。

需要说明的是，上述示例仅为举例，技术人员可根据调度策略设置预测单元调整用车价格的规则，在此不再逐一描述。

发送模块13用于向位于所述第一区域或第二区域的司机用户发送所述时间段内包含有费用的订单信息，或/及向位于所述第一区域或第二区域的乘车用户提供所述时间段内包含有费用的预览信息；所述费用是基于所述用车价格调整获取的。

在此，所述发送模块13通过解析来自乘车用户的打车请求、或者司机用户的预览请求确定在待调度的时间段自第一区域前往第二区域的行程信息，并将包含所计算的费用(若无价格调整则为用车价格)的订单信息发送给位于所述第一区域的司机用户(或反馈给司机用户)的移动通信设备。其中，根据请求的类型，所述订单信息还包括终点、甚至推荐路线等。例如，当乘车用户操作移动通信设备发出打车请求以期望司机用户提供乘车服务时，所述发送模块13通过将包含所述费用的订单信息按相距乘客距离由近至远的顺序推送给处于空闲状态的司机用户，以待司机用户接受。其中所述处于空闲状态的司机用户是基于发送模块13所登记的与司机用户唯一对应的司机号的属性为空闲而确定的，其中，所述空闲表示司机用户未处于正在载客中且能够接单。

所述发送模块13通过解析来自乘车用户的打车请求确定在待调度的时间段自第一区域前往第二区域的行程信息，向所述乘车用户反馈包含有费用的预览信息，以供乘车用户预览打车费用。例如，当乘车用户操作移动通信设备发出打车请求以期望预览费用时，所述发送模块13通过将包含所述费用的预览信息反馈给相应乘车用户所持的移动通信设备，以供乘车用户确认是否进一步发出用于打车邀请的打车请求。

需要说明的是，上述示例仅为举例而非对本申请的限制，事实上，乘车用户可能从第二区域打车至第一区域，所述发送模块13依据所计算得到的从第二区域打车至第一区域的费用向乘车用户及司机用户发送相应的包含相应费用的预览信息和订单信息。由上述各示例并推及至对整个城市或地区的用车调度，所述发送模块13可提供任意时间段和起点所在区域、终点所在区域的用车调度，在此不再赘述。

本申请还提供一种服务器。所述服务器用于运行本申请所述的打车平台，以及其他任意可执行前述用车需求预测方法的打车平台。请参阅图6，其显示为所述服务器在一实施方式中的结构示意图。所述服务器3包括存储器31以及一个或多个处理器32。

其中，所述存储器31可包括高速随机存取存储器，并且还可包括非易失性存储器，例如一个或多个磁盘存储设备、闪存设备或其他非易失性固态存储设备。在某些实施例中，存储器还可以包括远离一个或多个处理器的存储器，例如经由通信网络(未示出)访问的网络附加存储器，其中所述通信网络可以是因特网、一个或多个内部网、局域网(lan)、广域网(wlan)、存储局域网(san)等，或其适当组合。存储器还包括存储器控制器可控制设备的诸如cpu和外设接口之类的其他组件对存储器的访问。所述存储器用于存储程序代码。

所述处理器32可操作地与存储器31耦接。处理器可执行在存储器31中存储的程序代码，诸如与移动通信设备进行数据接收和发送的步骤，以及根据行程信息计算第一拼车价格和第二拼车价格的步骤等。更具体地，所述处理器用于调用所述存储器中存储的程序代码来执行用车调度方法。例如，所述处理器执行参照图1及所对应的文字描述而设计的用车调度方法，在此不予赘述。如此，处理器可包括一个或多个通用微处理器、一个或多个专用处理器(asic)、一个或多个现场可编程逻辑阵列(fpga)、或它们的任何组合。

所述处理器32还可操作地与网络接口耦接，以将所属计算设备以通信方式耦接至网络。例如，网络接口可将计算设备连接到广域网(wan、或注入4g、5g或lte蜂窝网络)。

另外需要说明的是，通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请的部分或全部可借助软件并结合必需的通用硬件平台来实现。基于这样的理解，本申请还提供一种计算机可读存储介质，所述存储介质存储有至少一个程序或指令，所述程序在被调用时执行前述的任一所述的用车调度方法。

基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可包括其上存储有机器可执行程序代码的一个或多个机器可读介质，这些程序代码在由诸如计算机、计算机网络或其他电子设备等一个或多个机器执行时可使得该一个或多个机器根据本申请的实施例来执行操作。例如执行叫车服务中的各步骤等。机器可读介质可包括但不限于，软盘、光盘、cd-rom、磁光盘、rom(只读存储器)、ram(随机存取存储器)、eprom(可擦除可编程只读存储器)、eeprom(电可擦除可编程只读存储器)、磁卡或光卡、闪存、或适于存储机器可执行程序代码的其他类型的介质/机器可读介质。其中，所述存储介质可位于机器也可位于第三方服务器中，如位于提供云存储的服务器中。

另外需要说明的是，通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请的部分或全部可借助软件并结合必需的通用硬件平台来实现。基于这样的理解，本申请还提供一种计算机可读存储介质，所述存储介质存储有至少一个程序，所述程序在被调用时执行前述的任一所述的用车调度方法。

基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可包括其上存储有机器可执行程序代码的一个或多个机器可读介质，这些程序代码在由诸如计算机、计算机网络或其他电子设备等一个或多个机器执行时可使得该一个或多个机器根据本申请的实施例来执行操作。例如执行叫车服务中的各步骤等。机器可读介质可包括但不限于，软盘、光盘、cd-rom、磁光盘、rom(只读存储器)、ram(随机存取存储器)、eprom(可擦除可编程只读存储器)、eeprom(电可擦除可编程只读存储器)、磁卡或光卡、闪存、或适于存储机器可执行程序代码的其他类型的介质/机器可读介质。其中，所述存储介质可位于机器人也可位于第三方服务器中，如位于云服务端中。在此对具体应用商城不做限制，如阿里云、华为的云服务端等等。

本申请可以在由计算机执行的计算机可执行程序代码的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

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