CN115298519A - 用于按需运输的可配置服务时间 - Google Patents

Abstract

用于调度车队的系统和方法包括确定车辆的行程的总时间期望。总时间期望包括与第一行程的行驶时间不同的服务时间期望。方法还包括接收用于新行程的一个或多个请求，并至少部分基于行程的总时间期望确定是否将新行程分配给车辆。在一些实施例中，基于历史数据或用户偏好确定服务时间期望。在一些实施例中，服务时间期望由使用历史数据训练的模型生成。

Description

用于按需运输的可配置服务时间

技术领域

本公开的实施例一般涉及用于提供具有可定制服务时间的运输(例如，按需或其他)的系统和方法。

背景技术

近年来，按需运输快速发展。今天，通勤者有各种各样的按需交通选择，包括网约车、拼车，以及传统的按需交通，诸如豪华轿车和出租车服务。此外，这种服务可以由驾驶员控制车辆或使用自主车辆(AV)提供。成功的按需车辆车队的重要方面是快速和高效的车队调度和路由。

随着开发人员开发核心自主技术，并开始扩大按需运输车队的规模，无论是出售给个人消费者还是运营自己的拼车车队，这些开发人员将需要有效、高效的调度和路由技术。这场竞赛的赢家和输家将取决于哪些公司运营的网络效率最高，车辆利用率最高。

发明内容

准确估计行程时间对于提供车队中车辆的有效调度和路由至关重要。不同类型的按需运输有不同的要求，并且因此，需要车队组织系统，其可以基于车队的特征以及车队管理者的需要和每次行程的要求进行定制。例如，网约车服务可能需要不同的时间来完成穿越相同路线或行驶距离的行程，这取决于一天的时间(例如，交通状况)或基于调度的车辆类型(例如，驾驶员控制的车辆与自主车辆)。因此，可以考虑各种可能影响总行程时间的因素的车队组织系统更准确地预测行程时间，并从而更有效地对车辆进行路由。

可以通过增加额外的和可定制的步骤到车队组织系统而在行程规划中考虑这些因素。例如，行程规划可以包括所有行程中共有的几个固定的步骤，诸如“到达上车位置的行驶时间”和“行程行驶时间”。可以在这些行程中添加额外的步骤，例如，“上车等待时间”或“行程后清洗时间”，通过考虑与行程相关的因素的持续时间或可以估计的公司规定的政策(如“每次行程后必须清洗车辆”)的持续时间，从而提供对总行程时间的更准确的估计。如本文所述，这些持续时间可以由车队管理者和/或通过分析历史数据来指定。

根据一些实施例，用于调度车队的方法包括确定第一车辆的第一行程的第一总时间期望。第一总时间期望包括与第一行程的行驶时间不同(例如，分离)的第一服务时间期望(例如，可配置服务时间期望)。方法还包括接收与第一行程不同的新行程的一个或多个请求，包括接收请求的上车位置和请求的下车位置。方法进一步包括，至少部分基于第一行程的第一总时间期望，确定是否将新行程分配给第一车辆，以及将新行程分配给第一车辆。方法还包括将第一车辆路由到与请求的上车位置相对应的上车位置，以及将第一车辆从上车位置路由到与请求的下车位置相对应的下车位置。

在一些实施例中，方法进一步包括响应确定将新行程分配给第一车辆，生成新行程的估计开始时间(例如，上车时间估计)。估计开始时间至少部分基于第一行程的第一总时间期望。

在一些实施例中，确定第一总时间期望包括确定第一服务时间期望。

在一些实施例中，第一服务时间期望对应于从由以下组成的组中选择的服务类型：清洗时间；加油时间；充电时间；维修时间；上车等待时间；下车等待时间；行程后审查时间；以及行程确认时间(例如，驾驶员接受行程到开始行程之间的延迟)。

在一些实施例中，方法进一步包括分析多个行程的历史数据，以确定第一服务时间期望。对历史数据的分析包括，对于多个行程中的相应的行程，观察服务类型(例如，上车等候时间)的相应的持续时间(例如，2分钟)，并观察相应的行程的行程特征(例如，早上五时前上车)。方法还包括确定行程特征(如上午/下午/晚上)与服务类型(例如上车等待时间)的观察到的持续时间(例如，人们上午花约3分钟，以及下午花<1分钟)之间的相关性。方法还包括确定第一行程的第一服务时间期望，其中第一服务时间期望至少部分基于第一行程的行程特征。

在一些实施例中，方法进一步包括接收第一行程的多个行程特征，其中基于第一行程的多个行程特征(例如上车位置为郊区，下车位置为机场，上车时间为晚上)确定第一服务时间期望。

在一些实施例中，方法进一步包括接收与第一行程不同的第二行程的行程特征。第二行程的行程特征与第一行程的行程特征不同(例如，第一行程发生在达拉斯，而第二行程发生在多伦多)。方法还包括确定第二行程的第二可配置服务时间期望(例如，第二服务时间期望)，并且第二可配置服务时间期望至少部分基于第二行程的行程特征。第一服务时间期望和第二可配置服务时间期望对应于相同的服务类型(例如，下车等待时间)，以及第二可配置服务时间期望与第一服务时间期望不同(例如，具有不同的持续时间)。

在一些实施例中，基于历史数据(例如，包括标记有不同特征(诸如，不同的上车/下车位置、一天的时间等)的观察到的服务时间的历史数据，这样，不同的特征可以与历史观察到的服务时间相关)确定第一服务时间期望。

在一些实施例中，基于实时数据确定第一服务时间期望(例如，实时数据可能表示按需运输的需求激增，并且响应于实时数据中示出的需求变化，可以更改服务时间期望)。

在一些实施例中，由使用历史数据训练的模型生成第一服务时间期望。

在一些实施例中，第一服务时间期望从用户偏好确定。

在一些实施例中，方法进一步包括接收指示用于第一车队的车辆的第一可配置服务时间期望的第一持续时间的第一用户偏好，并将第一车队的车辆分配为具有与第一持续时间相对应的第一可配置服务时间期望。方法还包括接收指示用于第二车队的车辆的第二可配置服务时间期望的第二持续时间的第二用户偏好，并将第二车队的车辆分配为具有与第二持续时间相对应的第二可配置服务时间期望。第二可配置服务时间期望与第一可配置服务时间期望对应于相同的服务类型，并且第二持续时间与第一持续时间不同。

在一些实施例中，方法进一步包括接收指示用于第一车队的车辆的第一服务类型的第一持续时间的第一用户偏好，并针对第一服务类型，将第一车队的车辆分配为具有与第一持续时间相对应的第一服务时间。方法还包括接收指示用于第一车队的车辆的第一服务类型的第二持续时间的第二用户偏好，第二持续时间与第一持续时间不同。方法还包括更新第一车队的第一服务时间，以使第一服务时间对应于第二持续时间。

在一些实施例中，方法进一步包括确定第一行程的估计结束时间，并且估计结束时间至少部分基于总服务时间期望确定。

在一些实施例中，方法进一步包括对车队中的多个车辆进行路由，其中包括基于新行程的特征(例如，基于与新行程的特征相对应的服务时间预期)对第一车辆进行路由。

在一些实施例中，对车队中的多个车辆进行路由包括在将新行程分配给第一车辆后对第二车辆进行路由。

此外，还可以包括其他可定制的特征，以帮助车队组织系统进行行程规划。例如，车辆可以查询一组经策划的停车位，以找到可用作上车或下车位置的停车位，以便提供更有效的上车和下车体验。在某些情况下，诸如在城市的繁忙区域或大路上，叫车服务和拼车服务可能很难找到停车的地方来让乘客上车或下车。在某些情况下，诸如与人类驾驶员在一起时，驾驶员可能会采取危险或非法的操作，诸如在街道上双排停车，或在禁止停车区或消防栓前停车，以便让乘客上车或下车。这样的操作是不可取的，因为它们会带来不必要的安全风险。与此同时，由于可用停车位的不可预测性，取消这种操作可能会对路线规划产生负面影响。允许可定制的上车和下车位置减少了这种对乘客、驾驶员和车辆安全造成的不必要风险，并提高了上车和下车时间的效率，从而提供了更好的上车和下车体验。如本文所述，这些定制的上车和下车位置可以指定，例如，由车队管理者通过一组经策划的已知停车位指定。

根据一些实施例，一种调度车队的方法包括接收新行程的第一乘客的请求的上车位置，查询一组经策划的停车位以找到与请求的上车位置相对应的一个或多个第一停车位，并分配一个或多个第一停车位中的第一停车位作为第一乘客的上车位置。方法还包括接收新行程的第一乘客的请求的下车位置，查询一组经策划的下车位置以找到与请求的下车位置相对应的一个或多个第二停车位，并将一个或多个第二停车位中的第二停车位分配为第一乘客的下车位置。方法进一步包括将车队中的车辆分配到新行程，并为第一行程路由车辆，包括路由车辆在指定的上车位置接第一乘客，以及路由车辆在指定的下车位置让第一乘客下车。

在一些实施例中，一组经策划的停车位包括基于历史数据识别的停车位。

在某些情况下，方法包括确定是否有相应的停车位可用作上车位置或下车位置。例如，与相应停车位对应的历史数据可用于确定相应停车位可用(例如，未被占用、未使用、可访问)的概率(例如，可能性)。

在一些实施例中，一组经策划的停车位包括由车队中的车辆捕获的一个或多个图像识别的停车位。

在一些实施例中，方法进一步包括选择一个或多个第一停车位中的第一停车位作为第一乘客的上车位置，以及选择一个或多个第二停车位中的第二停车位作为用于第一乘客的下车位置。至少基于第一停车位与请求的上车位置的邻近性来选择第一停车位，并且至少基于第二停车位与请求的下车位置的邻近性来选择第二停车位。

在一些实施例中，一组经策划的停车位中的每个停车位包括一个或多个特征。至少基于第一停车位的特征分配第一停车位，并且至少基于第二停车位的特征分配第二停车位。本公开的一些实施例提供了包括一个或多个处理器和存储一个或多个程序的存储器的计算机系统(例如，诸如图4B所示的第一服务器系统400或第二服务器系统402的服务器系统)。一个或多个程序存储指令，当指令由一个或多个处理器执行时，导致计算机系统执行本文所述的任何一种方法。

本公开的一些实施例提供了存储指令的非暂时性计算机可读存储介质，指令在由具有一个或多个处理器的计算机系统执行时，导致计算机系统执行本文所述的任何方法。

通过提供可添加到行程中的额外定制步骤，这些实施例改进了车队组织系统，从而使车辆调度和路由系统中使用的行程时间估计更加准确。因此，这些实施例通过实现更准确的行程时间预测，提高了车队组织系统的准确性、有效性和效率。

附图说明

本文公开的实施例通过示例而不是通过限制在附图的图中进行说明。相似的附图标记贯穿整个附图表示相应部分。

图1是示出了根据一些实施例的行程时间线的框图。

图2A-2H示出了根据一些实施例为车辆分配行程的方法的流程图。

图3A示出了根据一些实施例的具有可定制步骤和时间的时间线。

图3B示出了根据一些实施例的基于历史信息更新图3A中所示的时间线中的可定制步骤和时间。

图4A-4B是示出了根据一些实施例的车辆路由引擎的架构的框图。

图5是示出了根据一些实施例的客户端-服务器环境的框图。

具体实施方式

这些系统和方法通过提供行程时间的更好的估计，改进了按需运输的车队调度和路由系统。在路由和调度车队时，需要考虑一些服务时间。这些服务时间的示例包括清洗时间、加油时间、车辆等待乘客上车的时间(例如，最大允许等待时间)等等。这些服务时间不仅影响整个车队对行程时间的估计(预计到达时间、预计出发时间)，还影响路由。例如，在一些实施例中，拼车共享网络在决定将哪些车辆安排给哪些乘客以及沿着哪些路线路由车辆(因为将乘客分配给任何特定车辆会影响车队中当前运行的其他车辆的路线)时考虑服务时间。此外，本实施例允许这些服务时间是可配置得，例如由用户(例如车队管理者)或通过机器学习、通过使用历史数据和/或通过使用实时数据进行配置。在一些实施例中，服务时间可以针对不同的行程特征(一天中的时间、位置等)进行不同的配置，针对不同的车队进行不同的配置，以及或针对车队中的不同车辆或车辆类别进行不同的配置。在一些实施例中，根据可配置(或配置的)的服务时间对车辆的车队进行路由和/或做出调度决策。

通过为这些车队组织系统提供更准确和/或可配置的服务时间，调度和路由系统可以更有效地规划当前和未来的行程(包括预先规划的行程和新的行程请求)。因此，本文描述的系统和方法可以提供更准确的行程时间预测或路由，从而提高按需运输车队的调度和路由系统的效率和有效性。更高效和有效的车队调度和路由可以减少车辆的磨损，提高燃油经济性和/或电池寿命等。

请注意，虽然本文中描述的一些实施例是关于按需运输的，但本公开的某些原则也适用于定期运输(例如，人员的定期乘坐、货物和服务的投递等)

图1是根据一些实施例示出行程时间线100的框图。图1中示出的步骤可以分为三类：1)保持固定(例如，不变)的步骤，用实线示出；2)受驾驶员的速度(例如驾驶员清洗速度、驾驶速度)影响的步骤，用点线表示；3)由于车队管理者的偏好而变化的步骤(例如，可以定制的步骤)，用虚线表示。可选的步骤(诸如多站，其可能存在于某些类型的乘车，但不存在于其他类型(例如，多目的地乘车，诸如拼车或合伙乘车需要多站步骤，但单目的地乘车不需要附加的停车或多站步骤))被标记出来。

行程可以分为三个部分：对应行程的调度、分配和确认的乘车前部分110；对应包括乘客的交互(例如，接乘客上车、驾驶和送乘客下车)的乘车部分120；以及对应乘车后的步骤的乘车后部分130，诸如在下一次行程可以开始、被分配或接受之前的清洗或加油。

如图1所示，乘客(例如，如图4B所示的乘车人、乘客404)发出的乘车请求140触发行程的开始。在行程的乘车前部分110中，由乘车服务142接收乘车请求140，并将其转发给配对服务144(例如，调度服务或系统)。配对服务144将乘车请求140转发给驾驶员，驾驶员确认146(例如，接受或拒绝)乘车。一旦乘车被接受，乘车请求被转发给收到确认148的乘客(例如，“您的乘车已确认”)。配对服务144还向指定的驾驶员或车辆160发送警报。警报可以包括诸如上车位置这样的信息，以便驾驶员可以开始行程(例如，移动到上车位置150)。警报被转发给乘客，显示有关分配的车辆152的信息。在某些情况下，乘客还可以收到车辆的当前位置以及车辆的预计到达时间和上车位置。

在行程的乘车部分120，车辆到达上车位置(步骤160)，并等待乘客进入车辆(步骤162)。在一些实施例中，车辆具有乘客到达车辆的最大允许等待时间，这是本文所述的可配置服务时间的示例。一旦乘客进入车辆164，行程的行驶部分(如驾驶)开始。在某些情况下，诸如在多站乘车中，行程包括附加的步骤168，对应于行程期间的一个或多个附加的站点。一旦车辆到达行程的最终目的地(步骤170)，车辆必须等待乘客下车(步骤172)，然后才开始行程的乘车后部分(可配置服务时间的另一个示例)。

行程的乘车后部分130包括乘客下车后、车辆准备接受或开始另一段行程前的步骤(步骤174)。

在一些实施例中，如所示，行程可包括附加的可选步骤(例如，可选步骤174和176)。例如，第一车队(例如，诸如图4B所示的车队管理者403)可能有政策，要求车队中的所有车辆在行程之间进行清洗。因此，第一车队的车辆所进行的行程的行程时间线包括清洗步骤174(可配置服务时间的另一个示例)。相比之下，第二车队(例如，与图4B中所示的车队管理者403类似)可能没有清洗政策，并且因此，第二车队的车辆所进行的行程的行程时间线可能不包括清洗步骤。在另一个示例中，第三车队(例如，诸如图4B所示的车队管理者403)可能要求驾驶员在每次乘坐后填写乘车后检查表。因此，第三车队的车辆的行程可能包括在车辆准备进行新行程178之前的乘车后步骤176。一旦车辆准备好开始新的行程，配对服务收到车辆可用的通知180。

在一些实施例中，管理车队车辆的车队管理者可以选择将哪些步骤包括在分配给车队的车辆并由车队的车辆完成的行程时间线中。例如，管理第一车队车辆的车队管理者可以确定每次出行都需要进行清洗步骤(例如，在乘客下车后和根据新的行程请求搭载新乘客之前)。相比之下，与第一车队车辆不同(例如，区别)的管理第二车队车辆的车队管理者可能在乘车之间省略清洗步骤。

在一些实施例中，车队管理者可以经由用户界面定义行程时间线(例如，定义在行程时间线中包括哪些步骤)。

在一些实施例中，时间线内分配给一个或多个步骤的时间可由车队管理者定制(例如，经由用户界面)。例如，车队管理者可以分配3分钟等待乘客进入车辆(步骤162)。

在一些实施例中，时间线内分配给一个或多个步骤的时间至少部分基于车辆的车队的历史信息来确定。例如，有关由车辆的车队完成的行程的历史信息可能表明，乘客往往需要2分15秒进入车辆。因此，可以调整行程时间线，以便分配3分钟用于等待乘客进入车辆(步骤162)。

在一些实施例中，时间线内分配给一个或多个步骤的时间至少部分基于车辆的车队的历史信息确定，并可以基于行程条件(例如，一天的时间、一周的天、上车位置、下车位置)而变化。例如，关于由车辆的车队完成的行程的历史信息可能表明，当行程目的地在机场时，乘客往往需要更长的时间(例如3分42秒)下车。因此，可以调整行程时间线，以便在行程目的地是机场(或其他运输港口，如火车站)时，分配5分钟等待乘客下车(步骤162)。

在一些实施例中，时间线内分配给一个或多个步骤的时间随着新行程的完成而更新，并且在历史信息中可以获得关于每个步骤的服务时间的更多数据。

图2A-2H示出了根据一些实施例的调度车辆的车队的方法200的流程图。方法200在电子设备(例如，车队组织系统，诸如图4B所示的第一服务器系统400或第二服务器系统402，其中包括车辆调度服务器和/或车辆路由服务器)上执行。虽然下面的讨论描述了车队组织系统执行方法的200步骤的实现，但在其他实施例中，一个或多个(例如，所有)步骤由另一个电子设备执行，诸如车辆(例如，具有存储用于执行方法的指令的非暂时性存储器以及用于执行指令的一个或多个处理器的车辆上的计算机系统)或与车辆路由服务器不同的服务器系统。此外，方法200中的一些操作是可选的、组合的和/或某些操作的顺序可选地被更改。在一些实施例中，方法200的部分或全部操作是自主执行的(例如，无需人工干预)。

方法200包括确定(210)第一车辆的第一行程的第一总时间期望。第一总时间期望包括与第一行程的行驶时间不同的第一可配置服务时间期望(例如，第一服务时间期望)。方法200还包括接收(220)与第一行程不同的新行程的请求，包括接收与新行程相对应的请求的上车位置和请求的下车位置。方法200进一步包括至少部分基于行程的第一总时间期望确定(230)是否将新行程分配给第一车辆。根据将新行程分配给第一车辆的确定，方法200还包括将(232)新行程分配给第一车辆，将第一车辆路由(234)到与请求的上车位置相对应的上车位置，以及将第一车辆从上车位置路由(236)到与请求的下车位置相对应的下车位置。

例如，车队管理者可以接收关于新行程的多个请求，每个请求包括请求的上车位置和请求的下车位置。在确定车队的哪些车辆分配到哪些行程(或哪些行程分配给哪些车辆)时，车队管理者确定车队的车辆目前正在完成的行程的总时间期望，并至少部分基于确定的车队车辆完成的行程的总时间期望来分配车辆到行程(或分配行程到车辆)。

在某些情况下，上车位置与请求的上车位置相同。可替代地，上车位置可以与请求的上车位置不同，并与请求的上车位置保持预定的距离内(例如，100米以内、城市街区以内、步行3分钟以内)。

在某些情况下，下车位置与请求的下车位置相同。可替代地，下车位置可以与请求的下车位置不同，并与请求的下车位置保持预定的距离内(例如，50米以内，两个城市街区以内，步行5分钟以内)。

在一些实施例中，将第一车辆分配到新行程包括从车队的车辆中选择第一车辆并将第一车辆分配到新行程。例如，对于接收到的每个行程请求，调度管理者或调度服务选择车队中的车辆并将其分配给接收到的行程请求。

在一些实施例中，方法200还包括确定(211)第一可配置服务时间期望。

在一些实施例中，(212)第一可配置服务时间期望对应于服务类型。服务类型从由以下组成的组中选择：清洗时间、加油时间、充电时间、维修时间、上车等待时间、下车等待时间、行程后审查时间和行程确认时间。

在一些实施例中，(213)基于历史数据确定第一可配置服务时间期望。

在一些实施例中，(214)由使用历史数据训练的模型(例如，神经网络)生成第一可配置服务时间期望。例如，包括行程特征(例如，用行程特征标记)和记录的一个或多个服务类型的持续时间的历史数据可以用来训练一个或多个模型，以基于行程特征预测服务类型的服务时间期望。在一些实施例中，基于行程特征的服务类型的预测服务时间期望应用于新行程。在某些情况下，机器学习可以用来训练一个或多个模型。

在一些实施例中，(215)根据用户偏好确定第一可配置服务时间期望。例如，用户(例如图4B中所示的车队管理者403)可以为服务类型提供固定的持续时间，诸如用于清洗的固定5分钟持续时间。在第二示例中，用户可以提供2分钟的乘车后调查的持续时间。在某些情况下，用户可以基于行程特征为同一服务类型提供多个持续时间。例如，用户可以为早上的行程的上车等待时间提供2分钟的持续时间，并且为晚上的行程的上车等待时间提供4分钟的持续时间。

在一些实施例中，(216)基于实时数据确定第一可配置服务时间期望。例如，用于按需运输的实时数据跟踪需求可能显示需求增加。响应于实时数据中显示的需求增长，服务时间期望可以被缩短，以允许更多的车辆可供乘坐，或允许车辆在乘车之间有更快的周转时间。

在一些实施例中，在第一车辆完成第一行程后，将第一车辆路由到与请求的上车位置对应的上车位置。

在一些实施例中，新行程和第一行程是同一个拼车的一部分。在这种情况下，在完成第一行程之前，第一车辆可以被重新路由到与新行程相对应的上车位置(例如，车队管理者可以更新第一车辆的路线)。在这种情况下，方法200进一步包括更新第一行程的第一总时间期望，以考虑与将新行程添加到车辆路线相应的附加步骤。

在一些实施例中，方法200包括响应于将新行程分配给第一车辆的确定而生成(240)新行程的估计开始时间。估计开始时间至少部分基于第一总时间期望。

在一些实施例中，方法200包括确定(242)第一行程的估计结束时间。估计结束时间至少部分基于总服务时间期望来确定。

在一些实施例中，方法200包括对车队中的多个车辆进行路由(244)，包括基于第一行程的特征对第一车辆进行路由。在一些实施例中，车辆的车队按照美国专利No.10，563，993中描述的任何路由方法进行路由，该专利通过引用整体并入本文中。在一些实施例中，使用多个乘客和车队的状态图表示对车辆的车队进行路由。本文中描述的各种服务类型在状态图表示中以状态的形式表示，并且服务时间期望应用于状态图，这样通过状态图遍历特定路径的成本在一定程度上取决于服务时间期望。

在一些实施例中，方法200包括在将新行程分配给第一车辆后对第二车辆进行路由(246)。例如，如上所述，使用本文中描述的可配置服务时间期望对车辆的车队进行路由

在一些实施例中，方法200包括对多个行程的历史数据进行分析(250)，以确定服务时间期望。分析包括，对于多个行程中的相应的行程，观察服务类型的相应的持续时间，并观察相应的行程的行程特征。方法200还包括确定(252)服务类型的观察到的持续时间和行程特征之间的相关性，并确定(254)第一行程的第一可配置服务时间期望。第一行程的第一可配置服务时间期望至少部分基于第一行程的行程特征。例如，对于下车等待时间服务类型，975个持续时间可被记录，每个记录的持续时间对应于不同行程的下车等待时间(例如，总共975行程)。除每次行程的下车等待时间的持续时间外，每次行程也可记录一个或多个行程特征。例如，对于第一行程，行程特征可包括上车位置类型(例如，郊区)，下车位置类型(城市)，上车时间：上午8：35，乘车人人口统计(例如，男性，28岁，需要特殊帮助：否)。在第二示例中，对于第二行程，行程特征可包括上车位置类型(例如，郊区)、上车时间：上午11：55，以及乘车人人口统计(例如，男性，72岁，需要特殊帮助：是)。

在一些实施例中，操作250-254可以针对多种不同的服务类型(例如，上述的服务类型)执行。例如，除了记录上述示例中所描述的975个行程中的每一个行程的行程特征和下车等待时间的持续时间外，还可记录其他服务类型的持续时间，诸如例如上车等待持续时间、重新加油持续时间(如果有)和/或清洗时间(如果有)。

在一些实施例中，方法200包括接收(260)第一行程的多个行程特征。基于第一行程的多个行程特征确定第一可配置服务时间期望。例如，请求的行程可以有以下行程特征：上车时间＝上午4：45，上车位置类型＝城市，下车位置类型＝机场，乘车人年龄＝57，乘车人性别＝女性，乘车人需要特殊帮助？＝否。基于一天的时间(例如，清晨)和上车位置类型(例如，城市)，可以确定上车等待时间期望为30秒。相比之下，可基于下车位置类型(例如机场，不允许空闲)确定清洗时间期望为10分钟。

在一些实施例中，方法200包括接收(262)与第一行程不同的第二行程的行程特征。第二行程的行程特征不同于第一行程的行程特征。方法200还包括至少部分基于第二行程的行程特征确定(264)第二行程的第二可配置服务时间期望。第一可配置服务时间期望和第二可配置服务时间期望对应于相同的服务类型，并且确定的第二可配置服务时间期望与确定的第一可配置服务时间期望不同。例如，第一行程可以具有包括在德克萨斯州达拉斯的行程位置的行程特征，以及第二行程可以具有包括在宾夕法尼亚州匹兹堡的行程位置的行程特征。上车等待时间期望可以基于行程发生的城市来确定。因此，可以确定上车等待时间期望为5分钟，并可以确定第二行程的上车等待时间期望为3分钟。

在一些实施例中，方法200包括接收(270)表示第一车队的车辆的第一可配置服务时间期望的第一持续时间的第一用户偏好，并分配(272)第一车队的车辆具有与第一持续时间对应的第一可配置服务时间期望。方法200还包括接收(274)指示与第一车队不同的第二车队的车辆的第一可配置服务时间期望的第二持续时间的第二用户偏好。第二可配置服务时间期望与第一可配置服务时间期望对应于相同的服务类型。第二持续时间与第一持续时间不同。方法200还包括将第二车队的车辆分配(276)为具有对应于第二持续时间的第二可配置服务时间期望。例如，设计为需要特殊帮助的乘客可进入的第一车队车辆的车队管理者可以分配第一车队中的车辆具有5分钟的下车等待时间，以考虑到每名乘客可能需要的特殊帮助，诸如轮椅坡道或帮助他们到门口。相比之下，不具备容纳需要特殊帮助的乘客的能力并且只在城市环境中运行的第二车队车辆的车队管理者可以将下车等待时间设置为15秒，因为大多数下车是在未经批准的停车位(例如，消防栓前、双排停车等)。

在一些实施例中，方法200包括接收(280)指示用于第一车队的车辆的第一服务类型的第一持续时间的第一用户偏好，并为第一车队的车辆分配(282)具有与第一持续时间对应的第一服务类型的第一可配置服务时间期望。方法200还包括接收(284)指示第一车队车辆的第一服务类型的与第一持续时间不同的第二持续时间的第二用户偏好，并将第一可配置服务时间期望更新为与第二持续时间对应。例如，车辆的车队的车队管理者可以为车辆加油设置10分钟的加油服务持续时间。然而，由于车队大多在农村地区操作，驾驶员通常需要驾驶至少5-10分钟到最近的加油站。根据此反馈，车队管理者可以将加油服务持续时间更改为15分钟。加油服务时间期望基于车队管理者做的更改从10分钟更新到15分钟。

根据一些实施例，方法200进一步包括接收查询(290)一组经策划的停车位，以寻找与请求的上车位置相对应的一个或多个第一停车位，以及(292)分配一个或多个第一停车位中的第一停车位作为第一乘客的上车位置。方法200还包括查询(294)一组经策划的停车位以寻找与请求的下车位置相对应的一个或多个第二停车位，并分配(296)一个或多个第二停车位中的第二停车位作为第一乘客的下车位置。因此，将第一车辆路由到上车位置包括将第一车辆路由(298)到第一停车位，以及将第一车辆从上车位置路由到下车位置包括将第一车辆从第一停车位路由到第二停车位。

在一些实施例中，方法200进一步包括接收新行程的第一乘客的请求的上车位置，查询一组已策划的停车位以找到与请求的上车位置相对应的一个或多个第一停车位，并将一个或多个第一停车位中的第一停车位分配为第一乘客的上车位置。方法200还包括接收新行程的第一乘客的请求的下车位置，查询一组经策划的停车位以找到与请求的下车位置相对应的一个或多个第二停车位，并分配一个或多个第二停车位中的第二停车位作为第一乘客的下车位置。方法200进一步包括将车辆的车队中的车辆分配到新的行程，并为车辆的第一行程进行路由，包括路由车辆在指定的上车位置接第一乘客和路由车辆在指定的下车位置让第一乘客下车。例如，用户可以请求从郊区到繁忙的市中心位置的乘车。车队规划器查询由车队管理者提供的一组经策划的已知停车位，以找到让车辆停下来让乘客上车和下车的停车位。车队规划器识别与用户的请求的上车位置在同一街区的公共公园停车场，并导航车辆在识别的公共公园停车场的特定停车位接乘客。乘客的上车位置被更新并呈现给乘客，以便乘客可以在指定的停车位与车辆会面。车队规划器还从一组经策划的已知停车位中识别在乘客的目的地附近路边的上车/下车位置。车队规划器将车辆路由到识别的上车/下车位置，让乘客在繁忙的市中心安全地下车。

在一些实施例中，方法进一步包括，在查询一组经策划的停车位之前，生成一组经策划的停车位。生成一组经策划的停车位包括收集关于停车位的数据(例如，直接经由第一方流程或从第三方合作伙伴处)，以及生成包括有关停车位的信息的数据存储(例如，公共数据存储)。例如，对于每个停车位，数据存储可以包括以下任何信息：位置，运行时间，特征(例如，残疾人专用车位，电动车辆或拼车专用车位，有限的停车时间，装载专用车位，用户必须使用楼梯进入)，所有者(例如，由A公司私人拥有的车位，是私人停车场的车位，是公共车位)，以及停车位的受欢迎程度(例如，在有很多行人和车辆交通的人口密集的地区，或在不是很受欢迎的偏远的地区)。在一些实施例中，生成一组经策划的停车位还包括对数据执行质量评估，以删除和/或纠正不良、不完整或不正确的数据。

在一些实施例中，一组经策划的停车位包括基于历史数据识别的停车位。例如，策划的停车位可以包括在过去的行程中已知可用的停车位，或已知在特定日期和/或时间可用的停车位。

在一些实施例中，一组经策划的停车位包括通过由车辆的车队中的车辆捕获的一个或多个图像识别的停车位。例如，策划的停车位可以包括经由自主车辆在街道上行驶时捕获的图像识别的停车位。

在一些实施例中，方法进一步包括选择一个或多个第一停车位中的第一停车位作为第一乘客的上车位置，以及选择一个或多个第二停车位中的第二停车位作为第一乘客的下车位置。至少基于第一停车位与请求的上车位置的邻近性来选择第一停车位，并且至少基于第二停车位与请求的下车位置的邻近性来选择第二停车位。例如，选择确定离请求的上车位置最近的经策划的停车位，并将其分配为上车位置。在另一个示例中，被确定为到请求的上车位置具有最短步行路线距离的经策划的停车位被选择并分配为上车位置。

在一些实施例中，一组经策划的停车位的每个停车位包括一个或多个特征。至少基于第一停车位的特征分配第一停车位，并且至少基于第二停车位的特征分配第二停车位。例如，如果乘客发现他需要残疾人专用车辆，那么为上车位置和下车位置选择的经策划的停车位被选择，因为这些停车位被确定为残疾人专用的(例如，具有此特征)。在一些实施例中，所选择的停车位可能不是最接近请求的上车位置和下车位置的，而是由于停车位具有与乘客提供的偏好或要求相匹配的特征而被选择的。

在一些实施例中，方法还包括确定是否有相应的停车位可用作上车位置或下车位置。根据确定有相应的停车位可用(在某些情况下，与其他标准相匹配)，将可用的停车位分配为上车或下车位置。

在某些情况下，确定相应的停车位是否可用作上下车位置包括访问对应于相应停车位的历史数据，并确定相应停车位可用(例如，未被占用、未使用、可访问)的概率(例如，可能性)。可替代地或除了访问历史数据之外，方法还可以包括基于与车辆的车队中的车辆相关联的一个或多个相机确定是否有相应的停车位。例如，如果估计的上车时间是上午11点50分，车队管理者可以自主访问在接近上午11点50分(例如，在上车时间前5分钟的时间窗口内)经过被分配给上车的停车位的车队车辆的相机捕获的直播、视频记录或图像。使用最近经过分配的停车位的车辆的相机捕获到的信息，车队管理者可以确定分配的停车位是否可用，并在需要时更新第一车辆的路由(例如，如果确定分配的停车位不可用，更新路由到不同的上车位置)。在一些实施例中，在查询一组经策划的停车位之后，并在将停车位指定为上车或下车位置之前执行此过程。在一些实施例中，在查询一组经策划的停车位之后并将第一停车位分配为上车位置之后，执行此过程。在一些实施例中，此过程是实时执行的。

图3A示出了根据一些实施例的具有可定制步骤和时间的时间线。时间线对应于由车辆的车队中的车辆完成的每次行程中所采取的步骤。例如，时间线对应于从用户接收到的行程请求。调度服务派出车辆的车队中的车辆310来完成这次行程。车辆310在时间t0被派出，并且车辆310在时间t1到达出发地。在此示例中，分配给乘客加载的时间320(例如，分配给乘客312等待进入车辆310的时间，步骤162)为3分钟。因此，预计车辆310将在时间t2离开出发地(例如，上车位置)，这比到达出发地的时间t1晚不到3分钟。乘客加载完成后，在时间t3车辆310导航到目的地(例如，下车位置)。在此示例中，给乘客312卸载的分配时间322为1分钟(例如，分配给乘客等待离开车辆310的时间，步骤172)。在所有乘客下车后，此时间线包括清洗车辆的可选步骤(例如，步骤174)。分配给清洗车辆310的时间324为4分钟(例如，分配给清洗车辆的时间，步骤174)。在车辆310被清洗后(例如，在步骤174中)，在时间t4时，该行程被认为完成，并且车辆310准备开始另一次行程。请注意，通过更准确地估计整个行程时间，调度车辆的能力(例如，在他们完成之前的行程之前)得到了提高。

在一些实施例中，时间线内一个或多个步骤的分配时间(例如，允许时间)由管理车辆的车队的车队管理者确定(例如，设置，预定义)。例如，车队管理者可以确定所有的行程时间线具有1分钟的乘客卸载时间的分配的时间322。在某些情况下，针对不同的车辆或不同的行程类型，特定步骤的分配时间可能会有所不同。例如，车队管理者可以确定，与叫车行程相对应的时间线具有分配给乘客加载的时间为3分钟，而与拼车行程相对应的时间线分配给乘客加载的时间为2分钟。在另一个示例中，车队管理者可以确定具有运输港口(例如，火车终点站、机场)的行程的时间线具有分配给乘客卸载的时间为3分钟，因为目的地在运输港口的行程往往包括携带行李的乘客，因此，与其他类型目的地的行程相比，乘客可能需要更多的时间下车并卸下行李。

图3B示出了根据一些实施例，基于历史信息更新图3A所示的时间线上的可定制的步骤和时间。由车队的车辆310完成的行程的时间线基于同一车队的车辆已经完成的行程的历史信息被更新。例如，历史信息可能示出，大多数乘客(例如，>80％的乘客)下车用时不到1分钟，平均时间为19秒。因此，历史信息可以用于根据历史信息更新乘客卸载的分配时间322(例如，乘客卸载的分配时间322基于同一车队的车辆之前完成的行程的历史信息被更新)。

在此示例中，基于指示乘客通常需要比以前允许用于加载更多的时间的历史信息，更新后的乘客加载的分配时间340从原来的乘客加载的分配时间320更新为4分钟。更新后的乘客卸载的分配时间342也基于历史信息从原来的乘客卸载的分配时间322进行了改变，历史信息指示乘客不需要如先前分配的那么长时间。因此，与原来的乘客卸载的分配时间322为1分钟相比，更新后的乘客卸载的分配时间342为30秒。清洗车辆的分配时间324也基于历史信息进行了更新。在此示例中，历史信息指示驾驶员在行程之间平均花费2分钟清洗车辆310。因此，用于清洗车辆的分配时间324被更改为2分钟的用于清洗车辆的更新分配时间344。

图4A-4B是根据一些实施例示出车辆路由引擎的架构的框图。例如，客户端430是待被路由的车辆(例如，自主车辆或与自主车辆相关的电子设备、非自主车辆、远程操作车辆诸如投递机器人)。在另一个示例中，客户端430是由车队管理者管理(例如，操作)的车队。

实时数据更新440包括服务器系统，其接收和/或跟踪实时交通442、历史交通444和事件446，并包括历史信息441，并处理和转发信息给路由引擎438。在一些实施例中，路由引擎438还使用信息为客户端430创建和/或更新路线。路由引擎438还使用从路由地图436接收到的信息(可以包括来自道路级别地图432和/或车道级别地图434的信息)为客户端430创建/更新路线。

图4B示出了车辆的车队的另一种示例性架构(例如，所谓的“堆栈”)。图4B所示的示例性架构的特征可以选择性地补充、替换，或与图4A所描述的架构的特征相结合。在一些实施例中，车辆车队是包括自主车辆(例如，自主车辆408)和非自主车辆(例如，非自主车辆406)的混合车队。在某些情况下，车队包括不同车辆类型的混合(例如，汽车、自行车、摩托车和/或投递机器人)。在某些情况下，车队通过将乘坐者从第一位置运送到第二位置来为乘客(例如，乘坐者/消费者404)提供服务。在某些情况下，车队为其他消费者提供服务，例如，通过向消费者投递物品(例如，从餐馆送餐，从零售商店送包裹)。

为了方便使用混合车队提供这些服务，堆栈包括第一服务器系统400，提供车队管理服务和路由信息。第一服务器系统400包括一个或多个处理器(例如，CPU)和存储用于参照第一服务器系统(例如，地图匹配/定位模块416、路由引擎410、地理空间筒仓数据库412和规范化数据结构414)描述的模块的指令的存储器。第一服务器系统400与第二服务器系统402上的车队管理器403接口。在如图所示的示例架构中，第二服务器系统402充当第一服务器系统400的客户端，而乘坐者、消费者(例如，乘坐者/消费者404，乘客)和车辆(例如，非自主车辆406和/或自主车辆408)充当第二服务器系统402的客户端。

在一些实施例中，第二服务器系统402是与第一服务器系统400分开的、不同的服务器系统。第二服务器系统402包括一个或多个处理器(例如，CPU)和存储用于参照第二服务器系统402(例如，车队管理者403)描述的模块的指令的存储器。指令由一个或多个处理器执行。在某些情况下，车队管理者403是由第一服务器系统400服务的多个车队管理者之一。例如，车队管理者403可以是特定公司车队的车队管理者，而第一服务器系统400可以为多个公司的车队提供服务。

第一服务器系统400包括路由引擎410，为自主车辆408和非自主车辆406提供路线、距离和估计到达时间。在一些实施例中，为每个车队实例化路由引擎的不同实例。

第一服务器系统包括存储地理空间数据(例如，存储有相应地理位置，诸如纬度和经度的数据)的一个或多个地理空间简仓数据库412。地理空间筒仓数据库412包括从地图数据提供商420接收的地图数据(例如，诸如街道位置/几何图形、街道名称的数据)。地图数据提供商的示例是OpenStreetMap。在一些实施例中，地理空间数据进一步包括从地图数据提供商420接收的用于自主车辆408的自主操作的诸如车道级数据(例如，车道位置/几何图形，关于允许从哪个车道进行哪些机动的信息)的“高清晰度”数据。地理空间数据进一步包括来自其他数据提供商422的数据，诸如从市政当局接收的关于建设和道路封闭的信息、实时数据、交通数据和其他数据。此外，地理空间简仓数据库412存储不同车队的车辆的位置(例如地图匹配位置)。

在一些实施例中，地理空间简仓数据库412存储覆盖同一地理区域的多个不同数据实例。例如，地理空间筒仓数据库412存储覆盖同一区域的多个地图(例如，地理空间数据叠加在这些地图上)。在某些情况下，不同的地图将包括适合特定车队的车辆的数据(例如，车队将包括自主车辆和投递机器人，以及地理空间简仓数据库412将存储具有适合车队的车辆类型的信息的一个或多个地图)。地图的某些实例可以对任何客户端是公开的(例如，任何车队管理者)，而地图的其他版本可以对某些客户端(例如，某些车队管理者)是私有的。例如，相应的车队可以从相应的高清地图数据提供商获得数据许可。因此，由相应的高清地图数据提供商提供的数据属于相应车队的车队管理者(例如，车队管理者403)的筒仓和私有。

第一服务器系统400进一步包括地图匹配/定位模块416，将从车辆接收的位置数据与地图位置(例如，存储在地理空间筒仓数据库412中的地图的位置)相匹配。例如，一些车辆生成位置数据(例如GPS数据或来自其他定位系统(诸如GLONASS、伽利略或北斗)的数据)。在一些情况下，这些数据是有噪声的，并且可能使车辆偏离其实际位置，例如，在人行道上或建筑物中。地图匹配/定位模块416接收来自相应车辆的位置数据(例如，通过与第一服务器系统400接口的车队管理者403)，将有噪声的位置数据匹配到可能的道路位置和/或车道位置，并更新在地理空间筒仓数据库412中的“地图匹配的”车辆位置(例如，更新匹配的位置)。此外，地图匹配的位置被提供给车队管理者403，用于各种目的(例如，监控车队)。

如上所述，堆栈包括第二服务器系统402，可选地与第一服务器系统400不同和独立。第二服务器系统402包括车队管理者403，充当第一服务器系统400的客户端(例如，路由引擎的客户端)。车队管理者403调度车辆(例如，非自主车辆406和/或自主车辆408)，为车辆分配路线，并为相应车队内的车辆分配补给位置(例如，使用由路由引擎提供的信息和路线)。此外，车队管理者403与乘坐者/消费者404接口(例如，经由乘坐者的智能手机或其他设备上的移动应用)。车队管理者403经由他们的移动设备向乘坐者/消费者404(例如乘客)提供诸如估计到达时间和行程费用的信息。在一些实施例中，车队管理者403还接收来自单个车辆的数据，诸如车辆位置(例如，位置，包括可选的车道特定的位置和方向(例如，车辆指向的道路))。

在一些实施例中，自主车辆包括自主车辆(AV)平台，用作自主车辆的自主功能的操作系统和框架。自主车辆包括一个或多个处理器(例如，CPU)和存储用于参考自主车辆描述的模块(例如，接口模块、AV平台、传感器/控制器的驾驶员)的指令的存储器。指令由一个或多个处理器执行。AV平台的示例是开源的机器人操作系统。车队管理者(例如，车队管理者403)通过接口模块与自主车辆(例如，自主车辆408)进行交互，接口模块在AV平台上运行，为AV平台提供路线，并接收来自自主车辆的传感器的数据。例如，在某些情况下，由路由引擎的开发人员提供接口模块，作为第一服务器系统和自主车辆的机器人之间的联络。AV平台从自主车辆的传感器接收传感器数据，并在某些情况下，使得传感器数据对于车队管理者可用，从而使传感器数据进一步向下对堆栈可用，例如，到地图匹配/位置模块。在一些实施例中，AV平台通过线控系统向自主车辆的控制发送命令(例如，加速命令，中断命令，转向命令等)。

图5是根据一些实施例示出客户端-服务器环境的框图。客户端-服务器环境500包括车辆510(例如510-1，510-2，…，510-n)，其通过一个或多个网络614连接到车辆路由服务器520。在一些实施例中，车辆510与车辆406或408类似(如图4B所示)。在某些情况下，车辆510作为车辆路由服务器520的客户端。一个或多个网络514可以是任何网络(或网络的组合)，诸如因特网、其他广域网、局域网、城域网、VPN、点对点、ad-hoc连接等等。

非自主车辆510-1是典型的人类驾驶车辆(例如汽车、卡车或摩托车)。在一些实施例中，非自主车辆510-1是或类似于非自主车辆406(图4B)。在一些实施例中，非自主车辆510-1包括仪表盘相机512(例如，行车记录仪512)，获取相机图像并将相机图像发送到车辆路由服务器520，车辆路由服务器可以从仪表盘相机图像(以及来自自主车辆的自主车辆相机传感器数据，诸如从自主车辆中的传感器502)自动识别道路状况。

自主车辆510-2(例如汽车、卡车或摩托车)包括非暂时性存储器504(如非易失性存储器)，为一个或多个客户端路由应用506存储指令。在一些实施例中，自主车辆510-2是或类似于自主车辆408(图4B)。客户端路由应用506由自主车辆510-2上的一个或多个处理器(例如，CPU)508执行。在一些实施例中，客户端路由应用506向车辆路由服务器520发送对路线的请求，并从车辆路由服务器520接收选择的路线。在一些实施例中，客户端路由应用506引导自主车辆510-2沿所选择的路线行驶。客户端路由应用506可以体现为程序、固件、操作系统或自主车辆510-2的其他逻辑或物理方面的任何适当组合。自主车辆510-2还可选择地包括一个或多个网络接口和一个或多个通信总线，用于互连这些组件。自主车辆510-2进一步包括车辆组件，诸如发动机/马达，转向机制，灯，信号机制等，其中一些或所有可以由存储在存储器504的程序(例如，客户端路由应用504)控制。

在某些情况下，车辆的车队，例如直到车辆510-n)与车辆路由服务器520通信。车队可以是自主驾驶和人类驾驶的车辆的混合，也可以是完全自主驾驶的车辆。

车辆路由服务器520包括非暂时性存储器516(例如，非易失性存储器)，为一个或多个服务器路由应用518(有时被称为“路由引擎”)存储指令。车辆路由服务器520进一步包括一个或多个处理器(例如CPU)522，用于执行服务器路由应用518。服务器路由应用518可体现为程序、固件、操作系统或自主车辆510-2的其他逻辑或物理方面的任何适当组合。车辆路由服务器520还可选地包括用于互连这些组件的一个或多个网络接口和一个或多个通信总线。

上述识别的应用对应于执行本文所述功能的指令集。应用不需要作为单独的软件程序、过程或模块来实现，并且因此这些指令的各种子集可以在各种实施例中组合或以其他方式重新排列。

也应理解，尽管在某些情况下，术语“第一”、“第二”等在本文用于描述各种元素，但这些元素不应受这些术语的限制。这些术语仅用于区分一个元素与另一个元素。例如，第一车辆可以被称为第二车辆，同样地，第二车辆也可以被称为第一车辆，这将改变描述的意义，只要“第一车辆”的所有出现都被一致重命名，而第二车辆的所有出现都被一致重命名。第一车辆和第二车辆都是车辆，但它们不是同一车辆(例如，第二车辆是另一车辆)。

本文使用的术语仅用于描述特定的实施例，并不意在限制权利要求。正如在实施例和所附权利要求项的描述中使用的，单数形式“一个”、“该”和“所述”也应包括复数形式，除非上下文明确另有指示。也应理解，本文使用的术语“和/或”指的是并包含一个或多个相关列出项目的任何和所有可能的组合。进一步理解，术语“包括”和/或“包含”在此说明书中使用时，指定了所述特征、整数、步骤、操作、元素和/或组件的存在，但不排除一个或多个其他特征、整数、步骤、操作、元素、组件和/或其组的存在或添加。

本文使用的术语“如果”，可选地解释为“当”或“在”或“响应确定”或“根据确定”或“响应检测”，根据上下文确定所述条件先例为真。类似地，短语“如果它被确定(陈述的条件先例为真)”或“如果(陈述的条件先例为真)”或“当(陈述的条件先例为真)”，可选地解释为“根据确定”或“响应确定”或“根据确定”或“根据检测”或“响应检测”所陈述的条件先例为真，这取决于上下文。

上述描述包括体现说明性实施例的示例系统、方法、技术、指令序列和计算机器程序产品。为了解释的目的，提出了许多具体细节，以提供对本发明主题的各种实施例的理解。然而，这将是很明显的，对于本领域技术人员来说，主题的体现是可选的，没有这些具体的细节的实践。一般来说，众所周知的指令实例、协议、结构和技术没有被详细地展示。

为了便于解释，前面的描述参照具体实施例进行了描述。然而，上述说明性讨论并不旨在穷举或将实施例限制为所公开的精确形式。选择和描述实施例是为了最好地解释原理和它们的实际应用，从而使本领域的其他技术人员能够最好地使用实施例和具有适合于预期的特定用途的各种修正的各种实施例。

Claims (18)

1.一种调度车队的方法，所述方法包括：

确定第一车辆的第一行程的第一总时间期望，其中所述第一总时间期望包括与所述第一行程的行驶时间不同的第一可配置服务时间期望；

接收与所述第一行程不同的新行程的一个或多个请求，包括接收与所述新行程相对应的请求的上车位置和请求的下车位置；

至少部分基于所述第一行程的所述第一总时间期望，决定是否将所述新行程分配给所述第一车辆；

根据确定将所述新行程分配给所述第一车辆，将所述新行程分配给所述第一车辆；

将所述第一车辆路由到与所述请求的上车位置相对应的上车位置；以及

将所述第一车辆从所述上车位置路由到与所述请求的下车位置相对应的下车位置。

2.根据权利要求1所述的方法，其中：

确定所述第一总时间期望包括确定所述第一可配置服务时间期望。

3.根据权利要求1所述的方法，其中所述第一可配置服务时间期望对应于从由以下组成的组中选择的服务类型：

清洗时间；

加油时间；

充电时间；

维修时间；

上车等待时间；

下车等待时间；

行程后审查时间；以及

行程确认时间。

4.根据权利要求3所述的方法，进一步包括分析多个行程的历史数据以确定所述第一可配置服务时间期望，所述分析包括：

对于多个行程中的相应的行程：

观察服务类型的相应的持续时间；以及

观察相应的行程的行程特征；

确定所述行程特征与所述服务类型的观察到的所述持续时间之间的相关性；以及

对于所述第一行程，至少部分基于所述第一行程的行程特征确定所述第一可配置服务时间期望。

5.根据权利要求1所述的方法，进一步包括：

接收所述第一行程的多个行程特征，其中基于所述第一行程的所述多个行程特征确定所述第一可配置服务时间期望。

6.根据权利要求1所述的方法，进一步包括：

接收第二行程的行程特征，其中：

所述第二行程与所述第一行程不同；以及

所述第二行程的所述行程特征不同于所述第一行程的所述行程特征；以及

至少部分基于所述第二行程的所述行程特征确定第二可配置服务时间期望，其中：

所述第一可配置服务时间期望和所述第二可配置服务时间期望对应于相同的服务类型；以及

所述第二可配置服务时间期望与所述第一可配置服务时间期望不同。

7.根据权利要求1所述的方法，其中基于历史数据确定所述第一可配置服务时间期望。

8.根据权利要求1所述的方法，其中所述第一可配置服务时间期望由使用历史数据训练的模型生成。

9.根据权利要求1所述的方法，其中所述第一可配置服务时间期望从用户偏好确定。

10.根据权利要求1所述的方法，进一步包括：

接收指示用于第一车队的车辆的所述第一可配置服务时间期望的第一持续时间的第一用户偏好；

将所述第一车队的车辆分配为具有与所述第一持续时间相对应的所述第一可配置服务时间期望；

接收指示用于第二车队的车辆的第二可配置服务时间期望的第二持续时间的第二用户偏好，其中：

所述第二可配置服务时间期望与所述第一可配置服务时间期望对应于相同的服务类型；以及

所述第二持续时间与所述第一持续时间不同；以及

将所述第二车队的车辆分配为具有与所述第二持续时间相对应的所述第二可配置服务时间期望。

11.根据权利要求1所述的方法，进一步包括：

接收指示用于第一车队车辆的第一服务类型的第一持续时间的第一用户偏好；

针对所述第一服务类型，将所述第一车队的车辆分配为具有与所述第一持续时间相对应的所述第一可配置服务时间期望；

接收指示用于所述第一车队的车辆的第一服务类型的第二持续时间的第二用户偏好，所述第二持续时间与所述第一持续时间不同；以及

更新所述第一车队的所述第一可配置服务时间期望，以使所述第一可配置服务时间期望对应于所述第二持续时间。

12.根据权利要求1所述的方法，进一步包括：

确定所述第一行程的估计结束时间，其中所述估计结束时间至少部分基于所述第一可配置服务时间期望确定。

13.根据权利要求1所述的方法，进一步包括：

响应于确定将所述新行程分配给所述第一车辆：

生成所述新行程的估计开始时间，所述估计开始时间至少部分基于所述第一行程的所述第一总时间期望。

14.根据权利要求13所述的方法，进一步包括：

对车队中的多个车辆进行路由，包括：

基于所述新行程的特征对所述第一车辆进行路由。

15.根据权利要求14所述的方法，其中对车队中的多个车辆进行路由进一步包括在将所述新行程分配给所述第一车辆后对第二车辆进行路由。

16.根据权利要求1所述的方法，进一步包括：

查询一组经策划的停车位，以找到与所述请求的上车位置接近的一个或多个第一停车位；

将所述一个或多个第一停车位中的第一停车位分配作为所述新行程的上车位置；

查询一组经策划的停车位，以找到与所述请求的下车位置接近的一个或多个第二停车位；

将所述一个或多个第二停车位中第二停车位分配作为所述新行程的下车位置，其中：

将所述第一车辆路由至所述上车位置包括将所述第一车辆路由至所述第一停车位；以及

将所述第一车辆从所述上车位置路由至所述下车位置包括将所述第一车辆从所述第一停车位路由至所述第二停车位。

17.一种计算机系统，包括：

一个或多个处理器；以及

存储一个或多个程序的存储器，所述一个或多个程序存储指令，当由所述一个或多个处理器执行所述指令时，使所述一个或多个处理器执行根据权利要求1-16中任一项所述的方法。

18.一种存储指令的非暂时性计算机可读存储介质，当所述指令由具有一个或多个处理器的计算机系统执行所述指令时，使所述计算机系统执行根据权利要求1-16中任一项所述的方法。

Images