CN114331645A - 一种提升网约车的运力利用率的方法及系统 - Google Patents

Abstract

本发明公开一种提升网约车的运力利用率的方法及系统，其中方法包括：将启动网约车应用程序的乘客端标记为潜在乘客端，获取潜在乘客端的历史信息；分别对潜在乘客端的历史信息进行虚拟下单条件的命中判别；为命中虚拟下单条件的乘客端建立相应的虚拟订单；获取真实订单、虚拟订单以及可指派车辆的实时位置信息，对真实订单和虚拟订单进行全局决策；基于全局决策的结果进行配对，将真实订单指派至配对的车辆，对虚拟订单所配对的车辆的运力暂时保留；在预设时间内若虚拟订单兑现为真实订单，则将真实订单指派至配对的车辆。本发明通过设置虚拟订单，对车辆的指派作出预判，以提高网约车的运力利用率。

Description

一种提升网约车的运力利用率的方法及系统

技术领域

本发明涉及网约车的运力管理方法的技术领域，具体涉及一种提升网约车的运力利用率的方法及系统。

背景技术

随着互联网的高速发展，网约车服务随之出现并成为一种人们常用的出行方式。网约车，即网络预约出租汽车经营服务的简称，是指以互联网技术为依托构建服务平台，接入符合条件的车辆和驾驶员，通过整合供需信息，提供非巡游的预约出租汽车服务的经营活动。网约车平台在获取乘客的网约车服务请求的网约车订单后，需要根据指派至附近的车辆，以使车辆接驾完成网约车服务。

现有的网约车平台所采用的指派方法，在指派车辆时，若网约车订单同时与多个车辆适配，可以指派到多个车辆，但是最终指派的车辆与在后发起的网约车订单的唯一适配的车辆冲突了，而在先的网约车订单未指派的车辆与在后的网约车订单并不适配，使得在后的网约车订单无法获得及时的车辆指派，而未受指派的车辆继续空载，使得运力浪费。

发明内容

为了克服上述现有的网约车在特定情况下，运力利用不够充分的技术缺陷，本发明提供一种提升网约车的运力利用率的方法及系统。

为了解决上述问题，本发明按以下技术方案予以实现的：

第一方面，本发明公开一种提升网约车的运力利用率的方法，包括如下的步骤：

将启动网约车应用程序的乘客端标记为潜在乘客端，获取潜在乘客端的历史信息；

分别对潜在乘客端的历史信息进行虚拟下单条件的命中判别；

为命中虚拟下单条件的乘客端建立相应的虚拟订单；

获取真实订单、虚拟订单以及可指派车辆的实时位置信息，对真实订单和虚拟订单进行全局决策；

基于全局决策的结果进行配对，将真实订单指派至配对的车辆，对虚拟订单所配对的车辆的运力暂时保留；

在预设时间内若虚拟订单兑现为真实订单，则将真实订单指派至配对的车辆。

结合第一方面提供第1种优选实施方式，所述虚拟下单条件的命中判别，具体包括：

对潜在客户端的历史信息进行分析后，对乘客端的历史信息进行虚拟下单条件的逐级判别，具体包括：

最近3小时内并未启动过网约车应用程序；

网约车应用程序中不存在进行中的网约车订单；

最近一个月内3分钟内完成下单的行为超过额定次数；

对同时符合所有判别条件的乘客端标记为命中虚拟下单条件。

结合第一方面提供第2种优选实施方式，所述对真实订单和虚拟订单进行全局决策，具体包括：

进行数据分析后获取真实订单的上车点和虚拟订单的上车点，启动全局决策引擎；

将真实订单的上车点、虚拟订单的上车点以及可指派车辆的实时位置信息输送至全局决策引擎中；

将其中预计能在额定时间完成接驾的可指派车辆与对应的真实订单进行匹配度运算，以获取对应的匹配度数值，以形成“订单-车辆对”的带有匹配度数值的配对关系；

将其中预计能在额定时间完成接驾的可指派车辆与对应的虚拟订单匹配后，形成匹配度数值为1的“订单-车辆对”的配对关系；

建立配对关系列表，依据匹配度将配对关系在配对关系列表中依次进行排列；

以匹配结果能保留最多“订单-车辆对”成功指派为前提，进行订单配对指派，以形成一一对应的真实订单或虚拟订单及其配对车辆。

结合第一方面提供第3种优选实施方式，所述以匹配结果能保留最多“订单-车辆对”成功指派为前提，进行订单配对指派，具体包括：

获取配对关系列表后，基于最有原则通过匈牙利指派算法，将真实订单所指派至匹配度最高的可指派车辆，使所有指派成功的“订单-车辆对”分数总和最大化，具体为，获取其中所对应的“订单-车辆对”的数量大于1的真实订单，取消其中与虚拟订单存在配对关系的车辆的配对，以降低真实订单指派车辆的匹配度为手段，保留虚拟订单的“订单-车辆对”的指派成功数量；

验证配对关系列表的时间戳字段，若超过了额定时间，则重新进行全局决策，以更新配对关系列表。

结合第一方面提供第4种优选实施方式：所述虚拟订单仅包括乘客端信息和上车点，不包括下车点和行程路径；

所述历史信息包括历史订单信息；

所述虚拟订单中的上车点，选取自历史订单信息中，乘客端当前位置所处区域内的历史订单中的上车点，若存在多个历史订单的上车点，则选取其中频率最高的历史上车点作为虚拟订单的上车点。

结合第一方面提供第5种优选实施方式：在所述虚拟订单兑现时，需要验证最终上车点与虚拟订单上车点是否一致，若不一致则进行相应的上车点修改，并新增下车点和具体行驶路径，完善网约车订单以指派至所配对的车辆。

第二方面，本发明还提供一种提升网约车的运力利用率的系统，包括潜在标记模块、命中判别模块、虚拟下单模块、全局对策模块、订单匹配模块和订单兑现模块，其中：

潜在标记模块，用于将启动网约车应用程序的乘客端标记为潜在乘客端，获取潜在乘客端的历史信息；

命中判别模块，用于分别对潜在乘客端的历史信息进行虚拟下单条件的命中判别；

虚拟下单模块，用于为命中虚拟下单条件的乘客端建立相应的虚拟订单；

全局对策模块，用于获取真实订单、虚拟订单以及可指派车辆的实时位置信息，对真实订单和虚拟订单进行全局决策；

订单匹配模块，用于基于全局决策的结果进行配对，将真实订单指派至配对的车辆，对虚拟订单所配对的车辆的运力暂时保留；

订单兑现模块，用于在预设时间内若虚拟订单兑现为真实订单，则将真实订单指派至配对的车辆。

结合第二方面提供第1种优选实施方式，所述命中判别模块在运行时，具体执行：

对潜在客户端的历史信息进行分析后，对乘客端的历史信息进行虚拟下单条件的逐级判别，具体包括：

最近3小时内并未启动过网约车应用程序；

网约车应用程序中不存在进行中的网约车订单；

最近一个月内3分钟内完成下单的行为超过额定次数；

对同时符合所有判别条件的乘客端标记为命中虚拟下单条件。

结合第二方面提供第2种优选实施方式，所述全局决策模块在运行时，具体执行：

进行数据分析后获取真实订单的上车点和虚拟订单的上车点，启动全局决策引擎；

将真实订单的上车点、虚拟订单的上车点以及可指派车辆的实时位置信息输送至全局决策引擎中；

将其中预计能在额定时间完成接驾的可指派车辆与对应的真实订单进行匹配度运算，以获取对应的匹配度数值，以形成“订单-车辆对”的带有匹配度数值的配对关系；

将其中预计能在额定时间完成接驾的可指派车辆与对应的虚拟订单匹配后，形成匹配度数值为1的“订单-车辆对”的配对关系；

建立配对关系列表，依据匹配度将配对关系在配对关系列表中依次进行排列；

以匹配结果能保留最多“订单-车辆对”成功指派为前提，进行订单配对指派，以形成一一对应的真实订单或虚拟订单及其配对车辆。

结合第二方面提供第3种优选实施方式，所述全局决策模块运行时，具体还包括：

获取配对关系列表后，基于最有原则通过匈牙利指派算法，将真实订单所指派至匹配度最高的可指派车辆，使所有指派成功的“订单-车辆对”分数总和最大化，具体为，获取其中所对应的“订单-车辆对”的数量大于1的真实订单，取消其中与虚拟订单存在配对关系的车辆的配对，以降低真实订单指派车辆的匹配度为手段，保留虚拟订单的“订单-车辆对”的指派成功数量；

验证配对关系列表的时间戳字段，若超过了额定时间，则重新进行全局决策，以更新配对关系列表。

与现有技术相比，本发明的有益效果是：

本发明所述的提升网约车的运力利用率的方法，其通过标记潜在乘客端，并对潜在乘客端进行判别后，后台自动为符合相关条件的潜在乘客端进行虚拟订单的建立和下发，以在后续的全局决策中，在真实订单与虚拟订单的指派车辆之间存在冲突时，虚拟订单的存在影响真实订单的最终指派选择。从而避免了潜在乘客在下单后出现无车辆可指派，且原真实订单可指派而未指派的车辆，因与潜在客户的订单不相容而继续空载的情况。本发明通过设置虚拟订单，使得网约车的运力得到更为合理的分配和利用。

附图说明

下面结合附图对本发明的具体实施方式作进一步详细的说明，其中：

图1是本发明的提升网约车的运力利用率的方法的流程示意图；

图2是本发明的提升网约车的运力利用率的系统的结构示意图；

附图的具体说明详见具体实施方式。

具体实施方式

下面将参照附图更详细地描述本公开的优选实施例。虽然附图中显示了本公开的优选实施例，然而应该理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

在本文中使用的术语“包括”及其变形表示开放性包括，即“包括但不限于”。除非特别申明，术语“或”表示“和/或”。术语“基于”表示“至少部分地基于”。术语“一个示例实施例”和“一个实施例”表示“至少一个示例实施例”。术语“另一实施例”表示“至少一个另外的实施例”。术语“第一”、“第二”等等可以指代不同的或相同的对象。下文还可能包括其他明确的和隐含的定义。

访问设备和服务器可以通过有线或无线通信方式进行直接或间接地连接。访问设备可以是终端，也可以是服务器。访问设备上运行了目标应用。目标应用是能够向服务器发起数据请求的应用程序，如社交应用、支付应用、游戏应用等。服务器可以是目标应用提供服务的应用服务器，也可以是区别与目标应用所对应应用服务器的代理服务器。服务器用于识别每个访问设备是否属于恶意设备，对来自恶意设备的数据报文进行拦截。当服务器为代理服务器时，代理服务器将不属于来自恶意设备的数据报文转发至应用服务器。终端具体可以是台式终端或移动终端，移动终端具体可以智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。服务器与服务器分别可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。

实施例1

如图1所示，第一方面，本发明公开一种提升网约车的运力利用率的方法，其中，可指派车辆为车辆上具有安装网约车平台应用程序的司机端，且当前状态为空载或即将完成当前订单可尽快进行接驾的车辆，乘客端为安装有相应的网约车应用程序的移动终端，司机端与乘客端分别通过网络与服务器连接。本发明所述的方法具体包括如下的步骤：

步骤S1：将启动网约车应用程序的乘客端标记为潜在乘客端，获取潜在乘客端的历史信息。

具体地，服务器通过网络获取最近启动过网约车应用程序的乘客端的列表，将列表中的乘客端简单地进行标记，以标记为潜在乘客端，并从服务器的数据库中获取潜在乘客端的历史信息。

步骤S2：分别对潜在乘客端的历史信息进行虚拟下单条件的命中判别。

具体地，服务器分别对潜在乘客端的历史信息进行分析，并下载获取最新的虚拟下单条件，基于分析后的乘客端历史信息的数据进行虚拟下单条件的命中判别。其中，所述虚拟下单条件的命中判别，具体包括：

对潜在客户端的历史信息进行分析后，对乘客端的历史信息进行虚拟下单条件的逐级判别，具体包括：

最近3小时内并未启动过网约车应用程序；

网约车应用程序中不存在进行中的网约车订单；

最近一个月内3分钟内完成下单的行为超过额定次数；

对同时符合所有判别条件的乘客端标记为命中虚拟下单条件。

步骤S3：为命中虚拟下单条件的乘客端建立相应的虚拟订单。

具体地，服务器获取命中虚拟下单条件的乘客端信息，并自动为各命中的乘客端建立相应的虚拟订单，所述虚拟订单仅包括乘客端信息和上车点，不包括下车点和行程路径，所述历史信息包括历史订单信息，所述虚拟订单中的上车点，选取自历史订单信息中，乘客端当前位置所处区域内的历史订单中的上车点，若存在多个历史订单的上车点，则选取其中频率最高的历史上车点作为虚拟订单的上车点。虚拟订单的上车点还可通过现有技术的各种常规手段获得，在此不作具体的限定。

步骤S4：获取真实订单、虚拟订单以及可指派车辆的实时位置信息，对真实订单和虚拟订单进行全局决策。

具体地，所述对真实订单和虚拟订单进行全局决策，具体包括：

进行数据分析后获取真实订单的上车点和虚拟订单的上车点，启动全局决策引擎；

将真实订单的上车点、虚拟订单的上车点以及可指派车辆的实时位置信息输送至全局决策引擎中；

将其中预计能在额定时间完成接驾的可指派车辆与对应的真实订单进行匹配度运算，以获取对应的匹配度数值，以形成“订单-车辆对”的带有匹配度数值的配对关系；

将其中预计能在额定时间完成接驾的可指派车辆与对应的虚拟订单匹配后，形成匹配度数值为1的“订单-车辆对”的配对关系；

建立配对关系列表，依据匹配度将配对关系在配对关系列表中依次进行排列；

以匹配结果能保留最多“订单-车辆对”成功指派为前提，进行订单配对指派，以形成一一对应的真实订单或虚拟订单及其配对车辆。

其中，所述以匹配结果能保留最多“订单-车辆对”成功指派为前提，进行订单配对指派，具体包括：获取配对关系列表后，基于最有原则通过匈牙利指派算法，将真实订单所指派至匹配度最高的可指派车辆，使所有指派成功的“订单-车辆对”分数总和最大化，具体为，获取其中所对应的“订单-车辆对”的数量大于1的真实订单，取消其中与虚拟订单存在配对关系的车辆的配对，以降低真实订单指派车辆的匹配度为手段，保留虚拟订单的“订单-车辆对”的指派成功数量；验证配对关系列表的时间戳字段，若超过了额定时间，则重新进行全局决策，以更新配对关系列表。

进一步具体地，若乘客A与乘客B同时执行网约车真实订单的下单，乘客C和乘客D启动了网约车应用程序，但尚未下单，1分钟后乘客C和乘客D下单。存在同时可指派的车辆A、车辆B和车辆C，车辆A与乘客A的匹配度数值为50，车辆B与乘客B的匹配度数值为90，车辆C与乘客B的匹配度数值为40，车辆A可接驾乘客D，车辆B可接驾乘客C。

若基于传统的运力指派方式，乘客C和乘客D尚未下单，不予理会，订单会优先指派到匹配度更高的车辆，因此，乘客A与车辆A配对，乘客B与车辆B配对，车辆C空驶，当乘客C和乘客D下单后，由于不匹配，车辆C无法完成指派，因此，乘客C和乘客D均需要等待新的可指派车辆，同时车辆C空驶浪费运力。

通过本发明的方法，乘客C和乘客D会在打开网约车应用程序后建立虚拟订单，虚拟订单与车辆的匹配度数值为1，在全局决策时，虽然乘客B与车辆B的匹配度更高，但是若乘客B指派到车辆C，则可为乘客C暂时保留车辆B的运力，在乘客C兑现虚拟订单后，将乘客C的订单指派到车辆B，使得车辆A、车辆B和车辆C的运力均得到了充分的应用，乘客D的虚拟订单不会影响仅有唯一适配指派的乘客A的正常出行。

步骤S5：基于全局决策的结果进行配对，将真实订单指派至配对的车辆，对虚拟订单所配对的车辆的运力暂时保留。

步骤S6：在预设时间内若虚拟订单兑现为真实订单，则将真实订单指派至配对的车辆。

在所述虚拟订单兑现时，需要验证最终上车点与虚拟订单上车点是否一致，若不一致则进行相应的上车点修改，并新增下车点和具体行驶路径，完善网约车订单以指派至所配对的车辆。

综上所述，本发明所述的提升网约车的运力利用率的方法，其通过标记潜在乘客端，并对潜在乘客端进行判别后，后台自动为符合相关条件的潜在乘客端进行虚拟订单的建立和下发，以在后续的全局决策中，在真实订单与虚拟订单的指派车辆之间存在冲突时，虚拟订单的存在影响真实订单的最终指派选择。从而避免了潜在乘客在下单后出现无车辆可指派，且原真实订单可指派而未指派的车辆，因与潜在客户的订单不相容而继续空载的情况。本发明通过设置虚拟订单，使得网约车的运力得到更为合理的分配和利用。本发明能够解决在特定的情况下，车辆重合时的车辆指派选择使得后下单的乘客无车辆可指派，部分车辆无单可接的状况，能同时提升司乘双方的体验。

本实施例所述的提升网约车的运力利用率的方法的其它步骤参见现有技术。

实施例2

如图2所示，第二方面，本发明实施例公开一种提升网约车的运力利用率的系统，包括潜在标记模块M1、命中判别模块M2、虚拟下单模块M3、全局对策模块M4、订单匹配模块M5和订单兑现模块M6，其中：

潜在标记模块M1用于将启动网约车应用程序的乘客端标记为潜在乘客端，获取潜在乘客端的历史信息；

命中判别模块M2用于分别对潜在乘客端的历史信息进行虚拟下单条件的命中判别；

虚拟下单模块M3用于为命中虚拟下单条件的乘客端建立相应的虚拟订单；

全局对策模块M4用于获取真实订单、虚拟订单以及可指派车辆的实时位置信息，对真实订单和虚拟订单进行全局决策；

订单匹配模块M5用于基于全局决策的结果进行配对，将真实订单指派至配对的车辆，对虚拟订单所配对的车辆的运力暂时保留；

订单兑现模块M6用于在预设时间内若虚拟订单兑现为真实订单，则将真实订单指派至配对的车辆。

作为优选实施方式，所述命中判别模块M2在运行时，具体执行：对潜在客户端的历史信息进行分析后，对乘客端的历史信息进行虚拟下单条件的逐级判别。具体包括：最近3小时内并未启动过网约车应用程序；网约车应用程序中不存在进行中的网约车订单；最近一个月内3分钟内完成下单的行为超过额定次数；对同时符合所有判别条件的乘客端标记为命中虚拟下单条件。

所述全局决策模块在运行时，具体执行：进行数据分析后获取真实订单的上车点和虚拟订单的上车点，启动全局决策引擎；将真实订单的上车点、虚拟订单的上车点以及可指派车辆的实时位置信息输送至全局决策引擎中；将其中预计能在额定时间完成接驾的可指派车辆与对应的真实订单进行匹配度运算，以获取对应的匹配度数值，以形成“订单-车辆对”的带有匹配度数值的配对关系；将其中预计能在额定时间完成接驾的可指派车辆与对应的虚拟订单匹配后，形成匹配度数值为1的“订单-车辆对”的配对关系；建立配对关系列表，依据匹配度将配对关系在配对关系列表中依次进行排列；以匹配结果能保留最多“订单-车辆对”成功指派为前提，进行订单配对指派，以形成一一对应的真实订单或虚拟订单及其配对车辆。

所述全局决策模块运行时，具体还包括：获取配对关系列表后，基于最有原则通过匈牙利指派算法，将真实订单所指派至匹配度最高的可指派车辆，使所有指派成功的“订单-车辆对”分数总和最大化，具体为，获取其中所对应的“订单-车辆对”的数量大于1的真实订单，取消其中与虚拟订单存在配对关系的车辆的配对，以降低真实订单指派车辆的匹配度为手段，保留虚拟订单的“订单-车辆对”的指派成功数量；验证配对关系列表的时间戳字段，若超过了额定时间，则重新进行全局决策，以更新配对关系列表。

综上所述，本发明实施例所述的提升网约车的运力利用率的系统在运行时，能执行实施例1中所述的提升网约车的运力利用率的方法的全部步骤，以实现基于预判并建立虚拟订单，保留部分冲突的运力，在不影响真实订单正常完成的前提下，使运力的分配更为合理，避免不必要的运力浪费。

本实施例所述的提升网约车的运力利用率的系统的其它结构参见现有技术。

实施例3

本发明还公开一种电子设备，至少一个处理器，以及与所述至少一个处理器通信连接的存储器，其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，所述至少一个处理器执行指令时，具体实现以下的步骤：将启动网约车应用程序的乘客端标记为潜在乘客端，获取潜在乘客端的历史信息；分别对潜在乘客端的历史信息进行虚拟下单条件的命中判别；为命中虚拟下单条件的乘客端建立相应的虚拟订单；获取真实订单、虚拟订单以及可指派车辆的实时位置信息，对真实订单和虚拟订单进行全局决策；基于全局决策的结果进行配对，将真实订单指派至配对的车辆，对虚拟订单所配对的车辆的运力暂时保留；在预设时间内若虚拟订单兑现为真实订单，则将真实订单指派至配对的车辆。

实施例4

本发明还公开一种存储介质，存储有计算机程序，所述计算机程序被处理器执行时，具体实现以下步骤：将启动网约车应用程序的乘客端标记为潜在乘客端，获取潜在乘客端的历史信息；分别对潜在乘客端的历史信息进行虚拟下单条件的命中判别；为命中虚拟下单条件的乘客端建立相应的虚拟订单；获取真实订单、虚拟订单以及可指派车辆的实时位置信息，对真实订单和虚拟订单进行全局决策；基于全局决策的结果进行配对，将真实订单指派至配对的车辆，对虚拟订单所配对的车辆的运力暂时保留；在预设时间内若虚拟订单兑现为真实订单，则将真实订单指派至配对的车辆。

本公开可以是方法、装置、系统和/或计算机程序产品。计算机程序产品可以包括计算机可读存储介质，其上载有用于执行本公开的各个方面的计算机可读程序指令。

计算机可读存储介质可以是可以保持和存储由指令执行设备使用的指令的有形设备。计算机可读存储介质例如可以是――但不限于――电存储设备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或者上述的任意合适的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、静态随机存取存储器(SRAM)、便携式压缩盘只读存储器(CD-ROM)、数字多功能盘(DVD)、记忆棒、软盘、机械编码设备、例如其上存储有指令的打孔卡或凹槽内凸起结构、以及上述的任意合适的组合。这里所使用的计算机可读存储介质不被解释为瞬时信号本身，诸如无线电波或者其他自由传播的电磁波、通过波导或其他传输媒介传播的电磁波(例如，通过光纤电缆的光脉冲)、或者通过电线传输的电信号。

这里所描述的计算机可读程序指令可以从计算机可读存储介质下载到各个计算/处理设备，或者通过网络、例如因特网、局域网、广域网和/或无线网下载到外部计算机或外部存储设备。网络可以包括铜传输电缆、光纤传输、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。每个计算/处理设备中的网络适配卡或者网络接口从网络接收计算机可读程序指令，并转发该计算机可读程序指令，以供存储在各个计算/处理设备中的计算机可读存储介质中。

用于执行本公开操作的计算机程序指令可以是汇编指令、指令集架构(ISA)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、或者以一种或多种编程语言的任意组合编写的源代码或目标代码，上述编程语言包括面向对象的编程语言—诸如Smalltalk、C++、Java等，以及常规的过程式编程语言—诸如“C”语言或类似的编程语言。计算机可读程序指令可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络—包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。在一些实施例中，通过利用计算机可读程序指令的状态信息来个性化定制电子电路，例如可编程逻辑电路、现场可编程门阵列(FPGA)或可编程逻辑阵列(PLA)，该电子电路可以执行计算机可读程序指令，从而实现本公开的各个方面。

这里参照根据本公开实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本公开的各个方面。应当理解，流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合，都可以由计算机可读程序指令实现。

这些计算机可读程序指令可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理单元，从而生产出一种机器，使得这些指令在通过计算机或其它可编程数据处理装置的处理单元执行时，产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读程序指令存储在计算机可读存储介质中，这些指令使得计算机、可编程数据处理装置和/或其他设备以特定方式工作，从而，存储有指令的计算机可读介质则包括一个制造品，其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。

也可以把计算机可读程序指令加载到计算机、其它可编程数据处理装置、或其它设备上，使得在计算机、其它可编程数据处理装置或其它设备上执行一系列操作步骤，以产生计算机实现的过程，从而使得在计算机、其它可编程数据处理装置、或其它设备上执行的指令实现流程图和/或框图中的一个或多个方框中规定的功能/动作。

附图中的流程图和框图显示了根据本公开的多个实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或指令的一部分，上述模块、程序段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

以上已经描述了本公开的各实施方式，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施方式。在不偏离所说明的各实施方式的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施方式的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其他普通技术人员能理解本文披露的各实施方式。

Claims (10)

1.一种提升网约车的运力利用率的方法，其特征在于，包括以下步骤：

将启动网约车应用程序的乘客端标记为潜在乘客端，获取潜在乘客端的历史信息；

分别对潜在乘客端的历史信息进行虚拟下单条件的命中判别；

为命中虚拟下单条件的乘客端建立相应的虚拟订单；

获取真实订单、虚拟订单以及可指派车辆的实时位置信息，对真实订单和虚拟订单进行全局决策；

基于全局决策的结果进行配对，将真实订单指派至配对的车辆，对虚拟订单所配对的车辆的运力暂时保留；

在预设时间内若虚拟订单兑现为真实订单，则将真实订单指派至配对的车辆。

2.根据权利要求1所述的提升网约车的运力利用率的方法，其特征在于，所述虚拟下单条件的命中判别，具体包括：

对潜在客户端的历史信息进行分析后，对乘客端的历史信息进行虚拟下单条件的逐级判别，具体包括：

最近3小时内并未启动过网约车应用程序；

网约车应用程序中不存在进行中的网约车订单；

最近一个月内3分钟内完成下单的行为超过额定次数；

对同时符合所有判别条件的乘客端标记为命中虚拟下单条件。

3.根据权利要求1所述的提升网约车的运力利用率的方法，其特征在于，所述对真实订单和虚拟订单进行全局决策，具体包括：

进行数据分析后获取真实订单的上车点和虚拟订单的上车点，启动全局决策引擎；

将真实订单的上车点、虚拟订单的上车点以及可指派车辆的实时位置信息输送至全局决策引擎中；

将其中预计能在额定时间完成接驾的可指派车辆与对应的真实订单进行匹配度运算，以获取对应的匹配度数值，以形成“订单-车辆对”的带有匹配度数值的配对关系；

将其中预计能在额定时间完成接驾的可指派车辆与对应的虚拟订单匹配后，形成匹配度数值为1的“订单-车辆对”的配对关系；

建立配对关系列表，依据匹配度将配对关系在配对关系列表中依次进行排列；

以匹配结果能保留最多“订单-车辆对”成功指派为前提，进行订单配对指派，以形成一一对应的真实订单或虚拟订单及其配对车辆。

4.根据权利要求3所述的提升网约车的运力利用率的方法，其特征在于，所述以匹配结果能保留最多“订单-车辆对”成功指派为前提，进行订单配对指派，具体包括：

获取配对关系列表后，基于最有原则通过匈牙利指派算法，将真实订单所指派至匹配度最高的可指派车辆，使所有指派成功的“订单-车辆对”分数总和最大化，具体为，获取其中所对应的“订单-车辆对”的数量大于1的真实订单，取消其中与虚拟订单存在配对关系的车辆的配对，以降低真实订单指派车辆的匹配度为手段，保留虚拟订单的“订单-车辆对”的指派成功数量；

验证配对关系列表的时间戳字段，若超过了额定时间，则重新进行全局决策，以更新配对关系列表。

5.根据权利要求1所述的提升网约车的运力利用率的方法，其特征在于：

所述虚拟订单仅包括乘客端信息和上车点，不包括下车点和行程路径；

所述历史信息包括历史订单信息；

所述虚拟订单中的上车点，选取自历史订单信息中，乘客端当前位置所处区域内的历史订单中的上车点，若存在多个历史订单的上车点，则选取其中频率最高的历史上车点作为虚拟订单的上车点。

6.根据权利要求5所述的提升网约车的运力利用率的方法，其特征在于：

在所述虚拟订单兑现时，需要验证最终上车点与虚拟订单上车点是否一致，若不一致则进行相应的上车点修改，并新增下车点和具体行驶路径，完善网约车订单以指派至所配对的车辆。

7.一种提升网约车的运力利用率的系统，其特征在于，包括：

潜在标记模块，用于将启动网约车应用程序的乘客端标记为潜在乘客端，获取潜在乘客端的历史信息；

命中判别模块，用于分别对潜在乘客端的历史信息进行虚拟下单条件的命中判别；

虚拟下单模块，用于为命中虚拟下单条件的乘客端建立相应的虚拟订单；

全局对策模块，用于获取真实订单、虚拟订单以及可指派车辆的实时位置信息，对真实订单和虚拟订单进行全局决策；

订单匹配模块，用于基于全局决策的结果进行配对，将真实订单指派至配对的车辆，对虚拟订单所配对的车辆的运力暂时保留；

订单兑现模块，用于在预设时间内若虚拟订单兑现为真实订单，则将真实订单指派至配对的车辆。

8.根据权利要求7所述的提升网约车的运力利用率的系统，其特征在于，所述命中判别模块在运行时，具体执行：

对潜在客户端的历史信息进行分析后，对乘客端的历史信息进行虚拟下单条件的逐级判别，具体包括：

最近3小时内并未启动过网约车应用程序；

网约车应用程序中不存在进行中的网约车订单；

最近一个月内3分钟内完成下单的行为超过额定次数；

对同时符合所有判别条件的乘客端标记为命中虚拟下单条件。

9.根据权利要求7所述的提升网约车的运力利用率的系统，其特征在于，所述全局决策模块在运行时，具体执行：

进行数据分析后获取真实订单的上车点和虚拟订单的上车点，启动全局决策引擎；

将真实订单的上车点、虚拟订单的上车点以及可指派车辆的实时位置信息输送至全局决策引擎中；

将其中预计能在额定时间完成接驾的可指派车辆与对应的真实订单进行匹配度运算，以获取对应的匹配度数值，以形成“订单-车辆对”的带有匹配度数值的配对关系；

将其中预计能在额定时间完成接驾的可指派车辆与对应的虚拟订单匹配后，形成匹配度数值为1的“订单-车辆对”的配对关系；

建立配对关系列表，依据匹配度将配对关系在配对关系列表中依次进行排列；

以匹配结果能保留最多“订单-车辆对”成功指派为前提，进行订单配对指派，以形成一一对应的真实订单或虚拟订单及其配对车辆。

10.根据权利要求9所述的提升网约车的运力利用率的系统，其特征在于，所述全局决策模块运行时，具体还包括：

获取配对关系列表后，基于最有原则通过匈牙利指派算法，将真实订单所指派至匹配度最高的可指派车辆，使所有指派成功的“订单-车辆对”分数总和最大化，具体为，获取其中所对应的“订单-车辆对”的数量大于1的真实订单，取消其中与虚拟订单存在配对关系的车辆的配对，以降低真实订单指派车辆的匹配度为手段，保留虚拟订单的“订单-车辆对”的指派成功数量；

验证配对关系列表的时间戳字段，若超过了额定时间，则重新进行全局决策，以更新配对关系列表。

Images