路线规划的方法和设备与流程

相关申请的交叉引用

本申请要求于2018年1月8日提交的美国临时专利申请号62/614,951的权益和优先权，其全部内容通过引用合并于此。

所公开的技术总体上涉及路线调度系统，并且尤其涉及用于将用户请求的行程调度到运输(transit)路线上的系统和方法。

附图的简要说明

图1示出了根据共同上车区域分类的多个行程请求。

图2示出了根据共同下车区域分类的多个行程请求。

图3示出了可以添加的行程的例子，因为它正在通往另一个请求的行程的途中。

图4示出了根据所公开技术的一些示例的行程请求的簇(cluster)，该簇通常在相同方向上并且具有在该簇的种子(seed)行程的预设距离之内的上车位置。

图5示出了根据所公开的技术的一些示例的包含一些相同的行程请求的两个簇的例子。

图6示出了一组行程请求，其中行程中的至少一个乘客(rider)需要轮椅。

图7是示出了根据所公开技术的一些示例的多种行程是否可以组合成单个分组的表。

图8示出了根据所公开技术的一些示例，如何将具有三个不同的上车位置和三个不同的下车位置的三个行程请求组合成代表单个复合行程的单个分组。

图9是示出根据所公开技术的一些示例，是否可以将复合行程(例如，分组)链接在一起的表格。

图10显示了如何将不同的复合行程(分组)链接在一起以形成一条路线，以及如何扩展每个复合行程/分组中的个体行程，以定义该路线的个体行程。

图11a是根据所公开技术的一些示例的多个所请求的行程的表示，每个所请求的行程具有用于存储在计算机存储器中的多个行程属性的数据。

图11b是根据所公开技术的一些示例的多条路线的表示，每条路线具有存储在计算机存储器中的用于多个车辆属性的数据。

图12示出了根据所公开的技术如何将多个行程组合以形成满足预定搭乘(ride)质量标准的分组。

图13示出了根据所公开的技术如何将所请求的行程分类为一个簇。

图14示出了根据所公开的技术，在将行程分配给分组时，如何将簇内的行程分类为分组，以及如何更新每个簇的行程的表。

图15示出了示例性计算机系统，其可以根据所公开的技术来产生用于所请求的行程的路线调度表。

具体实施方式

如将在下面详细描述的，所公开的技术涉及调度系统，并且尤其涉及用于产生服务于用户请求的行程的路线调度表的系统。尽管针对辅助运输(paratransit)所请求的行程描述了该技术，但是应当理解，该技术可应用于其中单个行程或货物在共享的承运交通工具处组合的任何类型的调度系统。此类行程可能用于拼车或包裹/食品递送等。

在辅助运输系统中，用户请求在特定时间窗口内从上车位置到下车位置的搭乘。用户可以表示他们将与客人或助手一起行驶，并且他们可能有特殊的需求，例如需要轮椅等。调度系统的工作是以有效的方式为可以服务于请求的行程的车辆的车队开发路线，以使每个(或大多数)行程都以一定的质量参数被完成。质量标准的例子可以是运输时间，该运输时间小于某个最大值(例如45分钟)，调度的上车时间和下车时间接近于请求的时间，进行行程的车辆被有效地使用(不能在空载的情况下行驶距离太远或长途行驶)，没有太长的路线(例如，驾驶员加班)，没有过多的空闲时间等。系统操作员可以将特定的质量标准设置为将行程合并为如下所述的路线的规则。

创建路线调度表的常规方式是通过测试行程的添加是否会导致路线中的其他行程违反行程的质量标准，来将请求的行程插入到多个路线之一中。如果是这样，则无法将行程添加到路线中。如果没有，则可以插入行程。这种一对一插入方法的问题在于，它始终会导致一个或多个行程违反某些质量指标。

与逐个行程插入方法相反，所公开的技术使用计算机将多个(例如，一个或多个)行程分类为定义满足所有定义的质量度量的复合行程的分组。然后将分组/复合行程组合或链接起来，以定义特定车辆上的路线。尽管可以在确定路线时将分组以不同的组合方式链接起来，但是，一旦定义了分组/复合行程，便无法将其他行程添加到分组中，从而始终满足分组中行程的质量标准。

图11a—15提供了所公开的技术的更一般的概述，而结合伪代码描述了图1—10，其示出了利用编程的计算机系统来实现所公开的技术的一种方式。

如本领域普通技术人员将理解的，调度系统存储从用户接收的多个行程请求的记录。有多种请求行程的方式。例如，用户可以向呼叫中心呼叫行程请求。或者，乘客可以在网站上输入行程请求或在用于移动计算装置的应用上输入行程请求。行程请求的数据通常包括请求的上车时间和请求的下车时间，上车位置和下车位置，出行的乘客人数，乘客的任何特殊需求(例如，需要轮椅或特殊医疗需求)。为请求的行程确定的其他行程属性是其距离和预期行驶时间。在一个示例中，美国专利号10,094,676中描述的技术用于确定两个位置之间的预计行驶时间，并且通过引用将其全部内容合并于此。在一个示例中，计算机系统还确定并存储行程的行驶方向，作为从其上车和下车位置的角度方向(angularheading)。也可以为行程请求输入和存储其他行程参数，例如纬度和经度的上车和下车坐标。

行程请求作为记录存储在调度计算机的存储器中。计算机系统可能需要存储多达50,000个必须在任何给定日期调度的行程请求，这并不罕见。图11a示出了存储在计算机系统存储器中的行程请求及其对应属性的表1100。图11b示出了存储在调度系统计算机的存储器中的车辆属性表1120。每个车辆记录存储特定车辆的属性。示例性属性可以包括车辆类型(例如轿车或厢型车)，车辆可携带多少轮椅或非固定座位(ambulatory)乘客，轮班起止时间，车辆的提供者或操作员，车库的位置(经度和纬度)，驾驶员id，可用于确定车辆驾驶员是否具有任何特定的医学培训或专门知识。也可以存储其他或不同的属性(例如，如果是电动的，则车辆的范围等)。

在系统的截止时间，计算机分析行程请求(也更简单地称为“行程”)，并将其放置在由特定车辆服务的路线上。行程的属性必须与服务车辆的属性匹配。例如，不能将需要轮椅的行程放在不能接受轮椅的轿车服务的路线上。一旦所有行程都与特定车辆相关联，就会生成路线调度表，以通知驾驶员要服务的每个行程的上车和下车位置。

图12是根据公开的技术如何调度行程的简化图示。在此例子中，存在簇1200或多个请求的行程t1—t6的分类，每个行程具有特定的行程属性。在一个示例中，行程被分类为一个簇，因为它们都起始于行程之一(种子行程)的某个预定地理半径之内并且通常朝向相同方向。簇中满足所有请求者上车时间和下车时间要求并可由车队中的一辆车提供服务的行程组合为一个行程“分组”。分组p1包括行程t1，t2。分组p2包括行程t3，t4，t5。

如本文中所使用的，行程的“分组”是满足行程的运输系统的所有质量度量的一个或多个行程的逻辑分类。为分组分配了多个行程后，它将被锁定，并且无法将其他行程添加到分组中。以这种方式，调度额外的请求的行程将不会导致先前调度的行程违反其任何行程质量度量。

然后，行程分组被组合或链接以形成路线。例如，路线r1包含分组p1，p4，p7中包含的行程，而路线r2包含分组p2，p6，p123，p216等中包含的行程。组合的分组中包含的每个行程均不违反组合中任何其他行程的标准以及组合的分组中的所有行程都可以由同一车辆为该路线服务。

在所公开技术的一些示例中，仅当行程通常朝向相同方向时，行程才被组合成分组。给定行程的上车和下车位置，可以从地图程序中计算出行驶方向。在一个示例中，如果两个行程与第一行程在限定的角度内行驶，则称它们在同一方向上。如图4所示，计算机定义了与第一行程的角度范围400(例如45度)，并确定另一行程的上车和下车位置是否在该角度范围所定义的地理区域内。如果是这样，则认为行程沿相同方向行驶。可以使用除45度以外的其他角度。

图13示出了以个体行程为中心的多个簇1300。每个簇1302—1314具有种子行程，该种子行程是在距离种子行程的上车位置的确定半径内的任何行程中最长的(例如1/4英里)。在所示的示例中，每次行程都需要轮椅。一旦定义了行程的簇，就可以分析簇中的行程以确定它们是否可以组合为单个分组。

在一个示例中，将具有附近上车或下车位置并且沿相同的大致方向行驶的行程合并在簇c中。然后，对簇中的行程进行分析以确定它们是否可以合并为单个分组的行程。图14示出了存储在计算机系统的存储器中的表1400，示出了多个簇c1—c5中的行程。如果簇中的任何行程满足车队中的一辆车辆的容量，则有可能将其合并为一个分组。例如，簇5具有三个行程t5，t1和t7。如果所有三个行程都需要轮椅，并且车队中任何车辆一次能容纳的轮椅的最大数量为两个，则不能将一个行程与其他两个行程包含在同一分组中。在该例子中，分组p1被定义为行程t5和t1，并且行程t7被排除。在分析簇时会更新行程表。如图所示，在簇的第二遍处理中，从任何簇中删除行程t1和t5，然后进行处理以查看是否可以将簇定义的其余行程组合为分组。在一个示例中，首先处理具有最大数量的个体行程的簇。如果两个簇具有相同的行程次数，则使用第二个条件，依此类推，如启发式规则所定义。

如上所述，一旦行程被包括在分组中，它们就被“锁定”，并且在处理后续的行程请求时，不能将附加的行程添加到分组中。然后将分组分配给可以服务于分组中的行程的车辆的路线。

在一个示例中，可能被分类在一起的行程由行程请求确定(identified)，该行程请求在每个行程的预定地理半径内开始并且朝相同的总体方向前进。如图1所示，这称为“共同上车(commonpick)”。然后分析每个簇中的行程请求，以确定它们是否可以包含在单个分组中。

确定可能被分类在一起的行程的另一种方法包括，确定具有位于种子行程的下车位置的预定半径内的下车位置且从同一大致方向到达的行程(通常与行程的行驶方向成180度)。这称为“共同下车(commondrop)”，如图2所示。然后分析行程簇，以确定哪些行程可以组合到单个分组中。

确定可能被分类在一起的下车的另一种方式是在另一次行程的“在途中”的行程，如图3所示。可以分析这些行程的簇以确定是否可以将这些行程组合为一个分组。

在一个示例中，首先根据共同上车对行程进行分类，然后分析可能包含在单个分组中的行程，接着通过共同下车进行分类，然后进行分析，然后根据在途中进行分类和分析。

不能通过共同上车，共同下车或在途中标准进行分类的行程是单独进行分析的单例(singleton)行程，可以放置在其自己的分组中以便与其他分组中包含的行程进行链接。因此，一个分组可能只包含一个行程。

在大多数情况下，以共同上车，共同下车，在途中和单例行程中的顺序执行处理。但是，如果需要，可以更改顺序。

可以基于分组中包括的任何行程的第一上车时间和最后一个下车时间来分析单个分组中包括的行程。这有效地减少了将行程分配给路线时需要比较的开始和停止时间数据值的数量。例如，如果一个分组包含5个行程，则只需要分析两个开始/停止值(第一上车和最后一下车时间)，而不是10个数据值。这具有减少系统运行时间的效果。当减少了用于分析的单个上车和下车时间时，分组中包含的行程可称为复合行程。

在一个示例中，如果要将两个复合行程链接在一起，则复合行程的下车时间必须在另一复合行程的上车时间之前。这样可以加快处理速度。可以应用其他启发式规则，使得车辆必须在第二次复合行程的上车时间之前至少预定时间到达，但不能过早以至于车辆超过最大空载时间。用于链接分组的规则可以取决于用户定义的启发式规则。还可能在第一个复合行程的下车时间之前分析可用的座位数，以查看是否可以添加第二个复合行程。但是，这可能涉及更多的计算。

如将在下面解释的，将复合行程链接在一起与将行程添加到分组以几乎相同的方式执行。在一个示例中，存储在计算机系统中的表格示出了复合行程可以链接到的所有复合行程以及能够链接到特定复合行程的所有复合行程。可以以任何顺序进行处理，但是在一个示例中，该表以行程长度的降序列出了复合行程(例如，首先处理较长的复合行程，然后处理较短的复合行程)。表格随着复合行程被链接在一起而发生变化。此外，随着复合行程被分配给特定车辆，车辆可用性表也会更新。

图10示出了多个链接的复合行程1002，1004，1006的例子，这些行程被组合以形成路线101。在处理了所有请求的行程之后，计算机系统扩展了路线101的单独上车位置和下车位置。上车和下车时间形成行程调度表的一部分，该行程调度表被分给被分配该路线的车辆操作员。

如将在下面详细解释的，所公开的技术的调度系统提供了比逐个行程插入方法显著更快的操作的技术优势，因为它考虑(take)了25,000—50,000个行程难题并将其分解为多组(平均)10—30个行程难题。行程请求的总数被分为数量要少得多的行程的簇，这些数量要少得多的行程可以可能被组合到一条路线上。通过分析行程包含在分组中，前提是它们满足所有成员行程质量标准，满足其请求的上车和下车时间，可以由单个车辆提供服务并满足由操作员设置的其他标准(例如，最小空车(deadhead)行程长度，最小车辆空载时间等)，可以调度多个簇中包括的较少数量的行程。一旦定义了一个分组，它就是一条微型清单(manifest)或一条微型路线，不会被随后的所请求行程集合中的其他行程请求的后续处理所改变。然后，将由分组定义的微型清单链接在一起，以形成可能由车辆服务的较大路线。下面列出了行程请求数据的实际运行时间改进。

一种全局视图分组和链接的实际使用的应用模型

在辅助运输需求响应模型中，每天将多达25,000次或更多行程的行程请求集合被提交给调度系统，以产生有效的调度表，该调度表将路线的停靠点(驾驶员轮班和车辆)按服从于多个约束排序。这些约束包括在每次行程要求的30分钟上车窗口或30分钟约定下车窗口内进行上下车，不超过车辆非固定座位和轮椅座位容量，满足轮椅lifo装卸，满足驾驶员轮班的开始和结束时间，使用根据一天的时间段不同的速度，在不同的地理速度区域使用不同的速度，依此类推。行程集合每天都不同，因此调度问题每天都是新的。

需求响应调度的现有技术—“逐个行程插入”方法

可用于辅助运输需求响应行业的主要系统是基于“逐个行程插入”方法。通过一次将一组行程请求插入到称为“路线”的车辆班次中来构建调度表。每个行程都有一个上车地址和一个下车地址，以及一个请求上车时间或一个请求下车(预约)时间。

给定请求的7:00上车时间，将上车窗口独立设置为[7:00，7:30]。必须在此窗口内进行上车。如果从上车到下车的直接行驶时间为45分钟，则下车窗口被从属地计算为[7:00+45，7:30+45]＝[7:45，8:15]。但是从属的下车窗口的末尾扩展了一个余量以允许拼车(ridesharing)(例如60分钟)，因此下车窗口变为[7:45，8:15+60]＝[7:45，9:15]。必须在此窗口内下车。

给定请求的下车时间16:00，下车窗口被独立地设置为[15:30，16:00]。必须在此窗口内下车。如果从上车到下车的直接行驶时间是45分钟，则上车窗口被从属地计算为[15:30—45，16:00—45]＝[14:45，15:15]。但是从属的上车窗口的开始被扩展了一段余量以允许拼车(例如60分钟)，因此上车窗口变为[14:45—60，15:15]＝[13:45，15:15]。必须在此窗口内进行上车。

每个调度周期分为三个级别的决策：

下一个要调度哪个行程？

要将行程放在哪条路线上？

在路线上的何处插入上车和下车？

服务提供商选择每个决策级别的关键属性。通过在每个决策级别考虑所有合法候选者并选择“最佳”候选者来做出决策。

有两种众所周知的计算机科学技术来进行这样的选择：

加权评分函数

加权评分函数(wsf)基于每个关键属性的候选者值，为每个候选者创建单一分数。

可以通过重要性因子对每个关键属性进行加权，以放大其对最终分数的贡献。

给定一组候选者，将wsf应用于每个候选者，并选择得分最高的候选者。

以下是wsf决定“下一个要调度哪个行程？”的例子。

关键属性是：

triptype轮椅＝1，非固定座位＝0

tripriders<计数>

triplength<英里>

wsf是分数＝10*triptype+8*tripriders+1*triplength

行程101轮椅，1个乘客，10英里

行程202非固定座位，2个乘客，20英里

得分(行程101)＝10*1+8*1+1*10＝28

得分(行程202)＝10*0+8*2+1*20＝36

选择行程202作为接下来要调度的行程。

启发式过滤堆栈(hsf)：

下面是一个hfs用于确定“要将行程放在哪条路线上？”的例子。

关键属性是：

routetype能够轮椅＝0，轿车＝1

routeshiftlength<小时>

routetripcount<计数>

过滤器堆栈为：优选轿车路线

优选轻载路线(0至5个行程)

优选短轮班路线(0到8小时)

trip202可以插入的合法路线是route3001，route4001，和route5001。

route3001货车，8小时的轮班，已经调度了在车上的5次行程

route4001轿车，9小时的轮班，已经调度了在车上的5次行程

route5001轿车，8小时的轮班，已经调度了在车上的3次行程

候选者—进入过滤器候选—出来

{3001，4001，5001}优选轿车路线{4001，5001}

{4001，5001}优选轻载路线{5001}

停车点

优选短轮班路线已为行程202调度选择路线5001。

辅助运输需求响应行业中可用的大多数系统在“逐个行程插入”过程中将wsf用作其选择机制。一种商业系统在“逐个行程插入”过程中将hfs作为其选择机制。

“逐个行程插入”方法存在一些固有的弱点，这些弱点在需求响应调度的历史中始终表现出来，但至今尚未解决。对于每个服务提供商来说，这些都是每天都会发生的问题。

根本原因是，在较晚的周期中插入行程可能会对在较早的周期中插入的行程产生负面影响—在较早的周期中无法预见的影响。在周期1中插入的行程会受到在周期2至25,000中插入的影响。在周期2中插入的行程可能会受到在周期3至25,000中插入的影响，依此类推。

客户服务问题：

客户搭乘时间太长—假设在调度周期2000中将行程101调度到路线5001上。在周期24,011的下游，将选择行程879作为下一个被插入的最佳行程。由于调度选项在整个调度过程中单调递减，因此路线5001恰好是行程879的唯一合法候选者。但是插入行程879以满足其上车时间窗口要求将行程101的客户，以及当时在车上的无论任何人，保留在车上更长的时间。被长时间留在车上的客户会向服务提供商投诉。

“驶过我的停留站”—假设上述情况不会使行程101的客户的搭乘太长。但是，在目的地处放下行程101的客户将需要5分钟的时间下车。这将导致对行程879的上车较晚，因此路线会选择首先不停车而对行程879的客户进行上车。但是驾驶到行程879的上车地址正好通过行程101的下车地址，而不会停车。将客户驾驶经过他/她的站点，并且必须加倍返回以使其下车，这将导致客户向服务提供商投诉。这是每个服务提供商经常遇到的问题。如果驾驶员决定停下来而进行下车，则行程879的客户很可能会上车迟到。上车迟到的客户向服务提供商投诉。

按时性能问题：

估计到达时间(eta)在时间窗口中晚了—假设在调度周期2000中将行程101插入到路线5001上时，进行上车的eta是在30分钟上车窗口的前5分钟内。但是在调度周期3001中，将行程535的上车插入到行程101的上车之前，作为最佳的构造步骤。将行程535的上车调度到路线5001上，会将行程101的上车eta推到其合法上车窗口的最后一分钟。这是完全合法的，但是在服务之日，没有延迟的余量。如果在行程101的上车之前进行任何停车而造成延迟，无论是由于交通拥堵还是比计划的上客或下客更长的时间，都将延迟行程101的上车。上车迟到的客户向服务提供商投诉。直到最后一个调度周期之后，才会完全确定eta。eta在其窗口中的晚到更容易有在其服务日晚到的风险。

长空车—如前所述，在整个调度过程中，调度选项单调减少。靠近最后，行程可能只剩下一条可选择的路线，但是该路线必须在服务区域内空载行驶20英里(即“空车”)才能上车。调度系统将做出该决定，而不是将那些行程作为“不可调度”放入等待列表。较长的空车在多个街区中的长度更容易受到交通拥堵的影响，因此增加了上车迟到的可能性。

效率问题：

驾驶很长的路来上车—在上面的空车描述中，存在第二个弱点。空车英里和空车驾驶时间无法有效利用车辆的服务能力。对于市区，平均速度可能为每小时10英里。驾驶20英里进行上车会浪费2个小时的车辆服务时间。额外的20英里会导致车辆“磨损”，并加快维护服务的需求。

1辆车足够时，而发送2辆车—假设从家到老年中心的行程101，调度在调度周期2000在轿车路线5001上。稍后在调度周期3011，从家到与老年中心位于同一社区的康复设施的行程367被选作被调度的下一个行程。行程367的客户住在行程101的客户的隔壁，并要求与行程101的客户大约在同一时间成行。但是行程367是为轮椅乘客准备的，因此不能调度在轿车路线5001上。相反，货车路线6002与轿车5001同时到达同一社区，以完成这两个上车。货车6002具有空的非固定座位座椅可以容纳行程101的客户。轿车路线5001的可避免的服务里程和服务时间浪费了本可以合理使用的服务能力。路线5001上的其他客户也不便利，因为其搭乘的时间也比必要的长。

过度拥挤(over-packed)和未充分使用运能(under-packed)路线—调度完成后，可能混合了充分运能(well-packed)路线，过度拥挤路线，和未充分使用运能路线。就像eta一样，直到最后一个调度周期之后才完全确定，直到最后一个调度周期之后才完全知道路线的密度。过度拥挤的路线要求清单(manifest)得到完美执行。在较早的停车点上任何轻微的减速都会导致其余停车点有迟到的危险。没有延迟的余量。在服务当天，这迫使调度员实时采取纠正措施。经验上，如果没有时间考虑这些操作的后果，效率就会丧失。“每服务小时的行程”是效率的主要指标。服务日期结束后的“每服务小时的行程”可能比服务日开始之初的“每服务小时的行程”低25％。未充分使用运能的路线通常在早期工作和后期工作之间有很大的空闲时间间隔。这些间隙是浪费的服务时间，其中驾驶员坐着而车辆空载。

需求响应调度的全局视图分组和链接

所公开的技术涉及用于需求响应调度的“逐个行程插入”的替代方法。新方法提供了解决服务提供商在客户服务，准时性能，和效率方面反复出现的问题的解决方案，而这些问题是“逐个行程插入”所固有的。

新方法可以使用wsf或hfs进行决策。hfs在下文中用于说明决策。

该方法是一个两步过程：

全局视图分组

全局链接

全局视图分组

与通过将个体的行程请求插入到多个路线上来确定行程调度表的系统相反，所公开的技术在考虑将分组调度到哪个个体的路线上之前将行程请求分类到分组中。除非将行程合在一起满足为每个成员行程定义的质量度量，否则行程不会被合并。在一个示例中，除非所请求的行程具有彼此相对靠近的上车位置，具有在时间上彼此相对靠近的上车窗口，彼此都朝向相同的大致方向(角度方向)，并构造了满足所有约束条件的停站事件的顺序—停站窗口内的eta，某些车辆的轮班和容量，lifo的上客和下客，行驶速度等，否则请求的行程不会被组合成组。因此，分组被存储在计算机的内存中作为一组行程，其具有特定的停车事件顺序，以确保满足每个成员行程的所有客户质量度量。一旦将行程合并到分组中，就不会将其他行程添加到分组中，从而确保以后添加不会导致性能下降。任何后续的分组操作都不会影响任何先前构造的分组。

一旦确定了分组，就将它们链接在一起以形成路线。在一个示例中，仅在满足确定的质量度量的情况下才将分组链接在一起。例如，如果组合在分组的链接中引入了过多的空车时间，则不合并分组—即，从一个分组中最后一次下车会花费很长时间才能到达下一个分组的第一个上车。另外，如果将它们链接在一起所需空车的行程距离(例如，无乘客的车辆驾驶的距离)太大，则不会合并分组。允许的空车时间和空车距离是服务提供商要设置的参数。它们防止可能是“合法的”但不是“好的”的链接，因为驾驶空车时的时间和距离实际上是未使用的资源。

一旦分组将个体行程组合成分组，并且链接仅需要与分组一起使用，则调度问题的大小被有效地减小，从而提供减少必须执行的计算数量并减少计算解决方案调度表所需的时间的技术效果。例如，分组可以将25,000个行程组合成12,500个分组以进行链接。

替代在路线上通过“逐个行程插入”来构造调度表，分组根本不将任何行程分配给任何路线。取而代之的是，分组在全局范围内考虑要调度的所有行程，以从可扩展的行程—分类模式库中搜索满足模式的实例。根据它们的定义，这些模式提供了积极的拼车(效率)，eta牢牢地锁定在其时间窗口的中间(客户服务和otp保护)，为每个客户提供几乎直接搭乘服务(客户服务)。

库中的模式包括：

共同上车模式(图1)—共同上车组100是一组行程，它们的上车在相同的小社区中，具有大约相同时间的上车窗口，并沿大致相同的行驶方向向外行驶。这些行程应被分组为尽可能少的组(分组)，以便在分组后最终调度到路线上。如果车辆配置要求，则“后进先出”(lifo)停靠顺序是所有上车，然后是所有下车：上车—上车…—下车—下车。

共同下车模式(图2)—共同下车组200是一组行程，它们的下车在相同的小社区内，具有大致相同时间的下车窗口，并从大致相同的行驶方向向内行驶。这些行程应分组为尽可能少的组(分组)，以便在分组后最终调度到路线上。如果车辆配置要求，则lifo停靠顺序为所有上车，然后是所有下车：上车—上车…—下车—下车。

在途中模式(图3)—在途中组300是主人(host)行程，可以在自己的上车和下车之间使客人行程上车和下车，但要花费一些额外的里程。客人的行程的行驶方向大致相同，只有几英里的路程(积极的共乘，positiveridesharing)的“几乎免费乘坐”。客人行程可以递归地主持(host)自己的客人行程，依此类推。lifo停靠点的顺序是所有上车，然后是所有下车：上车—上车…—下车—下车。

在分组中考虑模式的顺序是可配置的，并且可以由服务提供商进行排序。从实际的角度来看，标准顺序是“共同上车”，“共同下车”，和“在途中”。这是由于经验所致，这些模式是根据每日行程集合中来自许多辅助运输站点的样本中出现的经验频率来排序的。如果车辆可以为其他行程请求分类提供服务并满足所有行程质量度量，则模式库(例如，如何组合行程)是可扩展的。

预分组—变量初始化(在下面以伪代码参考)：

每个行程tx具有适当设置的关键属性，例如：

t_wc需要轮椅座位

t_amb需要非固定座椅

t_pwin_st上车窗口开始时间

t_pwin_en上车窗口结束时间

t_dwin_st下车窗口开始时间

t_dwin_en下车窗口结束时间

t_pd_direct上车到下车“行驶方向”

t_dp_direct下车到上车“行驶方向”

t_length从上车到下车的直接行驶里程

t_dirride从上车到下车的直接搭乘时间(行驶+上客+下客时间)

t_petaeta上车的eta(如果请求的是上车时间，则初始化为t_pwin_st；如果请求的是下车时间，则初始化为t_dwin_st-t_dirride)

t_detaeta下车的eta(如果请求的是上车时间，则初始化为t_pwin_st+

t_dirride；如果请求的是下车时间，则初始化为t_dwin_st)

每个行程tx还具有要由簇填充的变量：

cluster_set包含可能在带有tx的当前模式中的行程的数组

cs_counttx的cluster_set的大小

每个cluster_set具有一组关键属性，这些属性将用于选择在分组构建期间要处理的下一个cluster_set。所有属性都初始化为适当的初始值。一些例子是：

cs_wcs轮椅成员计数(初始化为0)

cs_ambs非固定座位成员计数(初始化为0)

cs_longest成员之间的最长行程(初始化为0)

cs_earliest最早的成员上车时间(初始化为24:00)

每个行程tx还具有用于分组构建的变量。如果packet_id＝0，则tx尚未提交给任何分组—即，它“可用”于簇和分组—构建：

packet_id分组id(初始化为0)

packet_type分组类型(初始化为0)

packet_set包含在具有tx的分组中的行程的数组

pk_counttx的packet_set的大小

pk_lengthpacket_set中最长成员的长度

status分组—构建过程中的状态

在预分组后，依次对每个patternpx分两个步骤进行分组：

簇(px)

分组—构建(px)

因此，按照模式“共同上车”，“共同下车”，和“在途中”的顺序进行分组将是：

簇(共同上车)

分组—构建(共同上车)

簇(共同下车)

分组—构建(共同下车)

簇(在途中)

分组—构建(在途中)

步骤1—成簇的方法(模式px)

将每个行程作为“种子行程ts”，从其余行程中选择那些可能在带有ts的px模式中的行程。这称为ts的cluster_set(图4)。根据定义，ts也是其自己的cluster_set的成员。

此后，使用共同上车模式来说明成簇。

某些分组模式中的要求：

tc的直接行驶里程<＝ts的直接行驶里程(即，种子行程被要求为簇中最长的行程)。是一种可选项，以减小cluster_set的大小，而不会减少可以被分组—构建所构建的可能分组的空间。如果tc(例如，要添加到簇中的潜在行程)的直接行驶里程超过了ts的，则tc不包含在ts的cluster_set中。但是，如果依次将tc视为种子行程，ts满足此要求，并且如果满足所有其他条件，则ts可以包含在tc的cluster_set中。因此，此要求并未消除将tc和ts选择在同一分组中的可能性。

此可选要求加快了分组过程。为成簇方法实现的程序将其包含为条件函数，并带有可由操作员设置的开/关参数开关。

步骤2—分组—构建的方法(模式px)

分组—构建根据模式px逐一处理cluster_set，以构建分组。一旦构建了分组，每个成员行程的packet_id就会被相同的id填充(来自id生成器，为每个新分组增加一次)，并且每个成员的packet_type被设置为px。从而，对于每个新分组的所有成员行程，对于相同模式的后续cluster_set，以及对于按照处理顺序的后续模式的后续cluster_set，对分组—构建呈现为“不可用”。

启发式确定的处理模式的顺序以及每个模式内的处理cluster_set的顺序确定了所构建的分组的集合。所公开技术的调度系统没有指定处理模式的最佳顺序，也没有指定处理每个模式内的cluster_set的最佳顺序。后者被实现为启发式过滤堆栈(hsf)机制。

未处理的cluster_set的关键属性必须在处理cluster_set之后更新，因为它们的某些或全部成员可能包含在为最后一个cluster_set构建的分组中，因此不再可用。

仅将cs_count>1的cluster_set提交到分组—构建。

分组—构建创建满足需求响应服务的所有约束的“工作片”(piecesofwork，即，“最小清单”)，但是不考虑应将其调度到的特定路线。这些限制包括在每次行程的请求的30分钟上车窗口和/或30分钟约定下窗口内进行上车和下车，不超过所有路线车辆的非固定座位和轮椅座位容量，满足轮椅lifo的上客和下客要求，并在一天的时间段内使用不同的速度，在不同的地理速度区域中使用不同的速度，等等。每个分组都有至少一个可以分配给它的路线，以在服务之日被服务。

分组—构建可以从cluster_set构建一个以上的分组(图6)。例如，假设cluster_set600包含六个成员行程，而所有六个都是单人轮椅行程。假设车辆有两个轮椅座位。然后，可能从cluster-set由分组—构建生成多达三个分组。

在一个示例中，没有考虑的仅有的约束是是否存在可以服务所有分组的足够的路线。但这对任何辅助运输调度都是同样的问题。无法调度的行程或分组将被放入等待列表中以进行特殊处理，例如，发送至出租车或tnc(诸如uber或lyft之类的运输网络公司)等非专用提供商，或随着行程取消被呼入而插入到服务日期中。

此后，使用共同上车模式来说明分组—构建。

由于cluster_set的成员行程符合“共同上车模式”，因此每个客户的乘车时间几乎都是直接搭乘(客户服务)，每个客户的上车eta和下车eta都可舒适且可控地远离其各自的时间窗口的末端(时间保护的otp)，并通过模式的性质最大程度地提高了成员行程的积极拼车(效率)。形成分组后，任何后续调度操作都无法将其他上车或下车操作插入分组中。成员行程的eta被锁定，每个客户的客户体验也被锁定。消除了“逐个行程插入”。

对于当前模式中的后续簇集合以及后续模式中的簇集合，未被“分组—构建”放入分组的cluster_set中的行程对于分组—构建仍“可用”。它们的packet_id保持为0，packet_type保持为0。

分组—构建(共同上车)

如果还有cs_count>1的未处理cluster_set，请选择下面的hfs_p1用于分组—构建的下一个cluster_set。

将在cluster_set中的每个行程的status标记为in。

初始化每个行程的packet_set以包含其自身，并且pk_count＝1。

通过cluster_set中的所有行程来构建cluster_set中的所有行程的表“t1cancovert2”(图7)。示例的表700在图7中示出。

如果以下情况，“t1cancovert2”：

临时组合t1和t2packet_set，并按成员t_length排序(降序)。

与成员建立一个lifo序列—上车—…—上车—下车—...—下车。

测试lifo序列中的所有eta停靠点是否从窗口结束起至少有<3>分钟的缓冲时间。

测试是否有路线：

t1和t2所需的轮椅座位和非固定座位加在一起不超过某些路线车辆可用的轮椅和非固定座位。

lifo序列适合该路线的班次。

如果t1和t2通过所有测试，则t1可以覆盖t2。

如果t1可以覆盖t2，则表[t1，t2]＝yes，否则表[t1，t2]＝no。

注意：以下，当tx的状态＝in和ty的状态＝in时，才考虑tx和ty。

当仍然有表[tx，ty]＝yes：

选择下面的由hfs_p2可以覆盖某些ty的tx(表[tx，]的行有一些yes)。

选择下面的tx由hfs_p3可以涵盖的ty中的ty。

将ty的packet_set添加到tx的packet_set中，并添加tx的更新的pk_count。

按成员t_length(降序)对tx的packet_set进行排序。

用tx的packet_set构建lifo序列—上车—…—上车—下车—...—下车，并更新：

tx的t_wc和t_amb以代表分组

t_pwin_st和t_pwin_en＝在lifo序列中的第一个上车

t_dwin_st&t_dwin_en＝在lifo序列中的最后一个下车

pk_length＝最长的成员。

更新每个成员行程的t_peta和t_deta。

标记tyout并设置表[ty，]的行＝no和表[，ty]的列＝no。

更新表[tx，]的行和表[，tx]的列：如果yes，重新测试以查看是否仍然yes(如果no，则仍然是no)。

对于status＝in且pk_count>1(即，分组)的所有tx，标记成员的packet_id＝idnext并且packet_type＝px。

通过更新cluster_set以排除不再“可用”的成员，更新cs_count，和所有关键属性以反映更新的成员身份，来更新剩余的所有未处理cluster_set的信息。

转到步骤1。

hfs_p1—选择下一个用于分组—构建的cluster_set进行处理：

在所有剩余的候选cluster_set(cs_count>＝max_count-2)中，优选成员数在最大成

员计数的<2>之内的cluster_set。max_count是在此过滤器中被动态地计算。

在所有剩余候选cluster_set(cs_wcs>＝max_wc-1)中，优选其轮椅成员在最大轮椅成员的<1>之内的cluster_set。max_wc在此过滤器中被动态地计算。

在所有剩余的候选cluster_set(cs_longest>＝max_length-2)中，优选具有最长成员在距离最长成员<2>英里以内的cluster_set。max_length在此过滤器中被动态地计算。

选择一个。

hfs_p2—选择可以覆盖某些ty的tx：

优选具有最高pk_count的tx。

优选最长pk_length的tx。

最好使用t_wc>0的tx。

选择一个。

hfs_p3—在tx可以覆盖的ty中选择ty：

优选具有最长pk_length的ty。

优选具有最高pk_count的ty。

优选t_wc>0的ty。

选一个。

存在类似的分组—构建(共同下车)和分组—构建(在途中)函数。

在针对所有模式的分组—构建完成之后，已经构造了所有多个行程分组。通过分配每个“可用”行程的packet_id＝idnext和packet_type＝singleton，将其余“可用”行程制成单个行程分组。每个“可用”行程的状态仍为in，并且t_peta和t_deta从初始化开始已适当设置。

将被链接到路线中的实体的总数已经大大减少，通常减少到原始行程数的一半。

全局链接

对于链接，每个分组导致创建分配给它的复合行程800(复合者,composite)(图8)。复合者的id设置为与分组的id相同。复合者的上车是分组的lifo序列的第一个上车，复合者的下车是分组的lifo序列的最后一个下车。上车和行程都有窗口和地址。复合者的服务时间是通过来自分组的lifo序列的复合者的下车的eta减去复合者的上车的eta来计算的。轮椅客户数为t_wc，一直保持为该分组中任何时间车载的轮椅客户的最大数量的当前值(current)。非固定座位客户计数为t_amb，保持为该分组内任何时间车载非固定座位客户的最大数量的当前值。

从全局视图的角度来看，链接是通过将成对的复合者连续地链接在一起来构造路线的。预链接—复合者的关键属性的变量初始化(在下面的伪代码中引用)：

每个复合者都有适当设置的关键属性，例如：

c_id复合者id(初始化为分配给它的分组的packet_id)

c_packet_set在复合者中包含分组的数组(初始化为1个分组)

c_pk_countc_packet_set的大小(初始化为1)

c_pick在c_packet_set中第一分组的第一上车

c_drop在c_packet_set中最后一个分组的最后一个下车

c_eta_stc_packet_set中第一个分组的第一个上车的eta

c_eta_enc_packet_set中最后一个分组的最后一个下车的eta

c_span复合者的跨度＝c_eta_en-c_eta_st

c_wcc_packet_set分组中所需的最大wc座位

c_ambc_packet_set分组中所需的最大amb座位

c_routeld复合者被分配的路线(初始化为0)

c_status链接期间的状态(初始化为in)

每个路线/车辆都有适当设置的关键属性，例如：

r_shift_st轮班开始

r_shift_en轮班结束

r_shift_lengthr_shift_en-r_shift_st

r_wc轮椅座位

r_amb非固定座椅

r_status链接期间的状态(初始化为in)

在一示例中，要链接三个关键控制参数。第一个是maxdeadhead＝链接两个复合者的最大允许连接空车英里。第二个是maxwait＝在预期的被链接者上车以链接两个复合者时允许的最大等待时间。第三个是minwait＝在预期被链接者上车以链接两个复合者所需的最短等待时间。

在一个示例中，链接创建所有复合者x所有复合者的链接表900(图9)。每个条目表[cf,ct]包含两个值—cf和ct之间的连接的空车，以及ct处的连接的等待时间。

作为选择的链接的结果，另一个复合者可能会失去其最后的候选链接，而该候选链接本来是一个被链接者，从而成为头部(head)。它将被分配给可用的路线作为下一个构建周期的第一步。如果没有可用的路线，则将其标记为“不可调度”，并将其放在等待列表中。该过程一直持续到链接表为空。然后调度完成。那时，等待列表由高效的“工作件”组成，可以向溢出容量资源招标，例如经纪人，出租车，和诸如uber和lyft之类的tnc。

对于每个链接周期，完成(commit)链接者和被链接者之间的链接。必须更新链接表以反映该完成，以支持在下一个周期中的下一个完成是基于清晰而完整的信息的。

新复合者的上车是链接者的第一个上车，而组合的复合者的上车是被链接者的最后一个下车。两者都有窗口和地址。组合的复合者的服务时间是通过复合者的下车的eta减去复合者的上车的eta来计算的。轮椅客户数是链接者和被链接者之间的较大数。非固定座位计数是链接者和被链接者之间的较大计数。

全局视图链接的方法

分组的数量明显小于原始行程的数量。对于25,000个行程的测试行程集合，可以看到分组者最多可以创建四个成员行程的分组。

链接()：

如果有新的头部

对于每个头部，确定具有可以分配给它的r_status＝in的路线的集合。

如果头部没有这样的路线，请将其放在等待列表中(设置c_status＝waitlist)。选择具有c_status＝in的头部hx，由下面的hsf_c1分配路线。

为hx选择具有r_status＝in的ry，ry将由下面的hsf_c2被分配。

将hx分配给ry—将c_routeid设置为ry并设置ry的r_status＝out。

更新每个剩余头部可以被分配的路线集合(ry不可用)。

如果还有头部剩余，转到步骤b。

注意：下面，仅考虑c_status＝in的复合者。

虽然链接表中仍有链接：

选择具有下面由hsf_c3分配给路线的被链接者的链接者ch。

在下面通过hsf_c4为ch选择被链接者ct。

将ct的1个分组的c_packet_set添加到ch的c_packet_set的末尾，并更新c_pk_count。更新ch的关键属性(c_packet_set中的分组的顺序为“清单”时间顺序)。

c_pick和c_drop

c_eta_st和c_eta_ed

c_span

c_wc和c_amb

标记ct的c_status＝out并为connectivedeadhead和connectivewait设置表[ct,]的行＝-1和表[,ct]的列＝-1。

更新表[ch,]的行和表[,ch]的列：如果不为-1，则重新测试以查看是否仍不是-1(如果为-1，则仍为-1)。

如果在链接表中还剩下任何链接，请转到步骤1。

hsf_c1—选择头部：

优选具有大多数分组(c_pk_count)的头部。

优选最早的上车eta(c_eta_st)的头部。

优选需要最多数轮椅座位(c_wc)的头部。

选一个。

hsf_c2—为头部选择路线：

优选具有最少空车的路线(动态计算)。

优选具有最短等待时间的路线(动态计算)。

优选没有轮椅承载能力的路线(r_wc)。

选一个。

hsf_c3—选择链接者ch：

优选具有最早上车eta(c_eta_st)的链接者。

优选具有需要最多轮椅座位(c_wc)的链接者。

优选具有最多分组(c_pk_count)的链接者。

优选具有较少候选被链接者的链接者(动态计算)。

选一个。

hsf_c4—选择被链接者ct：

优选需要最多轮椅座位的被链接者(c_wc)。

优选具有最多分组(c_pk_count)的被链接者。

优选具有最小connectivedeadhead的被链接者。

优选具有最小connectivewait的被链接者。

优选具有较少候选链接者的被链接者(动态计算)。

选一个。

当链接停止时，所有具有c_status＝waitlist的复合者都在等待列表中。所有具有c_status＝in的复合者都是路线。每个路线的清单都在成员资格c_packet_set中，并按时间顺序排序。通过将每个这样的分组扩展到其lifo停靠点序列(将每个分组的packet_set按t_length降序以生成其lifo停靠点序列)，可以恢复行程停靠清单(图10)。

解决的客户服务问题

客户搭乘时间太长—分组模式排除了这一点。例如，对于共同上车分组，由于行程方向相同，并且上车时间窗口重叠，因此行程不会过长。eta被可控地位于时间窗中间的事实证明，所有成员上车的搭乘时间都不会过长。由于在链接过程中不会影响分组的完整性，因此成员行程的搭乘时间将被锁定，并在遍及其余调度过程中保持不变。

“驶过我的停靠站”—分组模式排除了这一点。例如，对于在途中分组，客人行程的上车和下车在主人上车和下车地址所定义的矩形内。通过测试trip1是否覆盖trip2，可以递归构造共同上车分组，因此trip2的上车和下车位于t1的上车和下车地址所定义的矩形内。由于在链接过程中分组的完整性没有受到影响，因此分组的停靠顺序被锁定，并在遍及其余调度过程中保持不变。

处理了按时性能问题

eta在时间窗口中较迟—分组模式排除了这一点。每个分组模式都明确构造了停靠的顺序，并测试，确保每个eta在其时间窗口结束时都具有最小的缓冲区。由于在链接过程中分组的完整性没有受到影响，因此成员停靠站的eta被锁定，并且在遍及其余调度过程中保持不变。

长的空车—明确的链接控制参数maxdeadhead＝链接两个复合者(因此是分组)所允许的最大连接性空车英里数排除了这一点。服务提供商明确指定了最长允许的空车。

处理了效率问题

驾驶了很长的路来进行上车—分组模式和显式链接控制参数maxdeadhead都排除了这一点。

当1辆车足够时发送2辆车—分组模式排除了这一点。在考虑将分组分配给哪条路线之前，将属于一起的行程在分组模式中被放在一起。

过度拥挤和未充分使用运能的路线—分组模式和链接控制参数minwait都排除了过度拥挤的路线。这些分组都是个体地被良好地使用运能(packed)，具有eta在其时间窗口的中间。minwait＝在链接两个复合者(因此是分组)的预期的被链接者的上车所需的最短等待时间。因此，由调度过程产生的任何路线都不会具有紧密的连接且没有错误余地。链接控制参数maxwait排除了未充分使用运能不足的路线。服务提供商明确指定最长允许的空闲时间间隔。

计算优势

在“逐个行程插入”方法中，所有行程都是下一次插入的候选。在构建路线中，可以在确定最佳插入点时调用行驶时间源来计算从任何候选行程的上车和下车到任何车载的路线停靠点的行驶时间。这是按以下顺序进行的：访问具有50,000个地址x50,000个地址的上限的非常大的停靠站到停靠站的矩阵，以建立路线(实际上，存在较少的地址，因为几次行程可能要去老年中心或医疗机构等)。但是分组一次仅考虑一次行程的cluster_set。由于cluster_set通常少于30个行程，因此停靠站到停靠站的矩阵最多为60个地址x60个地址以构建分组。当在普通的膝上型计算机上进行基准测试时，这有助于使在此公开的技术的方法比“逐个行程插入”快一个数量级。

类似地，分组解决了最多30个行程的数千个小难题，而不是解决巨大的25,000的行程难题。

要将新行程插入到已调度的20个停靠点的路线上，可以将上车插入21个候选插入点(在每个停靠点之前，加上最后一个停靠点之后)。对于上车的第一个候选插入点，也可以将下车插入到21个候选插入点—必须在上车之后。对于上车的第二个候选插入点，也可以将下车插入到20个候选插入点中，依此类推。因此，有21+20+19+…+1＝231个可能的插入对，可以通过质量度量测试合法性和“最佳”插入对。现在将第二条新行程插入路线，已经调度了22个停靠点，共有23+22+21+…+1＝276个可能的插入对。现在将第3个新行程插入路线，并已调度24个停靠站，共有25+24+23+…+1＝325个可能的插入对。

要将3个行程的新分组插入到已调度了20个停靠站的路线上，请注意，这20个停靠站可能由10个已调度的分组代表。新的分组只能放置在11个候选插入点中(每个分组之前，和最后一个分组之后)，以通过质量度量测试合法性和“最佳”插入。将3个行程的分组的11个候选插入与3个个体行程的231+276+325＝832个插入对进行比较。这说明了本公开技术的方法的另一贡献，是当在普通的膝上型计算机上进行基准测试时，比“逐个行程插入”快一个数量级。

在基于所公开技术的新程序与也使用hfs来做决策的“逐个行程插入”的产品的基准测试中，使用5年历史的具有单个处理器的台式机进行优化，每个新程序每5天每天大约25,000次行程的运行时间平均为144秒＝2.4分钟。在多核生产服务器上进行优化的“逐个行程插入”产品平均需要743秒＝12.4分钟。新程序在速度较慢的计算机上运行速度快了5倍，并且产生了更好的度量(请参见下文)。

额外优势

在“逐个行程插入”方法中，等待列表由单次行程组成。在本技术的方法中，等待列表由分组组成，这些分组是有效的工作。这些可以更有效率地招标非专用资源，例如经纪人(brokers)，出租车，以及uber和lyft之类的tnc，也许可以以打折的成本。

独行客(loner)行程在时间或地理位置上与要调度的行程集合中的其他行程隔离，并且是服务提供商最昂贵的行程。在“逐个行程插入”方法中，除非对其进行明确测试，否则可能将它们选择为下一次调度的最佳行程。从定义上讲，独行客行程驾驶到上车和从下车驾驶需要更长的空车，从而导致服务里程和服务时间的使用不佳。在本技术的方法中，独行客行程自然成为单次行程的分组。链接控制参数maxdeadhead将排除太远以至于无法将其进入任何路线的独行客分组。为最佳链接者选择最佳被链接者的策略将通过过滤器“优选具有最少空车英里的被链接者”来避免出现独行客分组。独行客适当地落在等待名单上，并被发送到非专用资源，这些资源不收取到上车或从下车的空车费用。

基准测试—一周的成果(production)测试数据集合

在连续的五个工作日中，进行了由美国东北大城市使用的基于hfs的“逐个行程插入”产品与基于在此公开技术的工具(engine)之间的“同一基准”的比较("applestoapples"comparison)。结果总结在下表中：

周一的行程

周二的行程

周三的行程

周四的行程

周五的行程

注意：在此公开的调度工具确实比现有技术调度具有更多的在等待名单上的行程(71个更多的在等待名单上的行程代表了要调度的总行程的0.3％)。

本说明书中描述的主题和操作的示例可以在数字电子电路中，或在计算机软件，固件，或硬件中实施，包括在本说明书中公开的结构及其等同结构，或以它们的一种或多种的组合来实施。本说明书中描述的主题的示例可以被实现为一种或多种计算机程序，即，计算机程序指令的一个或多个模块，其被编码在计算机存储介质上以由数据处理装置执行或控制数据处理装置的操作。

计算机存储介质可以是，或可以被包含在计算机可读存储装置，计算机可读存储衬底，随机或串行访问存储器阵列或装置，或它们中的一个或多个的组合中。此外，尽管计算机存储介质不是传播信号，但是计算机存储介质可以是以人工生成的传播信号中的编码的计算机程序指令的源或目的地。计算机存储介质也可以是，或可以包含在，一个或多个单独的物理组件或介质(例如，多个cd，磁盘，或其他存储装置)中。本说明书中描述的操作可以被实现为由数据处理设备在存储在一个或多个计算机可读存储装置上或从其他源接收的数据上执行的操作。

图15示出了可以用来实现所公开的技术的类型的代表性计算机系统。该计算机包括处理器1502，该处理器1502被配置为执行存储在计算机可读介质上或存储在存储器1504中的编程指令，以接收和处理行程请求并将该请求分配到车辆路线上。该计算机系统可以包括被配置为提供用户可以在其中输入行程请求的网页的网络服务器(未示出)。在其他示例中，处理器执行指令以接收由另一计算机系统编译的行程请求列表1506。处理器还接收关于车队中可用于服务行程请求的路线和车辆数量的数据1508。

处理器与行驶时间预测系统1510交互作用(或实施行驶时间预测算法)，例如在美国专利10,094,676中讨论的那样，以确定每个请求行程的预期长度和持续时间。另外，计算机系统产生行程调度表1512的硬拷贝或电子拷贝，该行程调度表1512通知系统中每个车辆的驾驶员，对于他们的车辆所调度的每个行程，多个上车和下车地点是何处，以及该行程被服务的顺序。在一些示例中，处理器经由有线连接或有线通信链路(例如，lan，wan，互联网，802.11等)连接到其他处理器。提供包括键盘，鼠标，触摸屏或其他输入装置的用户界面1514，以供操作员查看行程调度表，调整乘坐质量度量，下车组合的启发式规则并执行其他功能。

术语“处理器”涵盖用于处理数据的所有种类的设备，装置，和机器，例如包括可编程处理器，计算机，片上系统，或前述中的多个或组合。该设备可以包括专用逻辑电路，例如fpga(现场可编程门阵列)或asic(专用集成电路)。除了硬件之外，该设备还可以包括为所讨论的计算机程序创建执行环境的代码，例如，构成处理器固件，协议栈，数据库管理系统，操作系统，跨平台运行时环境，虚拟机，或它们的一个或多个的组合的代码。设备和执行环境可以实现多种不同的计算模型基础设施，例如网络服务，分布式计算和网格计算基础设施。

计算机程序(也称为程序，软件，软件应用，脚本，或代码)可以用任何形式的编程语言(包括编译或解释语言，声明性或过程语言)编写，并且可以部署为任何形式，包括独立程序或模块，组件，子例程，对象，或适合在计算环境中使用的其他单元。计算机程序可以，但不必对应于文件系统中的文件。程序可以存储在保存其他程序或数据的文件的一部分中(例如，存储在标记语言文档中的一个或多个脚本)，专用于所讨论的程序的单个文件中，或多个协调文件(例如，存储一个或多个模块，子程序，或部分代码的文件)。可以将计算机程序部署为在一台计算机上执行，或者在位于一个站点上或分布在多个站点上并通过通信网络互连的多台计算机上执行。

本说明书中描述的过程和逻辑流程可以由一个或多个可编程处理器来执行，该一个或多个可编程处理器执行一个或多个计算机程序以通过对输入数据进行操作并生成输出来执行动作。过程和逻辑流程也可以由专用逻辑电路执行，并且设备也可以以专用逻辑电路，例如fpga(现场可编程门阵列)或asic(专用集成电路)，实现。

适合于执行计算机程序的处理器包括，例如，通用微处理器和专用微处理器，以及任何种类的数字计算机的任何一个或多个处理器。通常，处理器将从只读存储器或随机存取存储器或两者接收指令和数据。计算机的基本元件是用于根据指令执行动作的处理器和用于存储指令和数据的一个或多个存储装置。通常，计算机还将包括，或可操作地耦合以从一个或多个用于存储数据的大容量存储装置(例如，磁盘，磁光盘，或光盘)接收数据或将数据传输到一个或多个用于存储数据的大容量存储装置，或这两者。但是，计算机不必具有此类装置。此外，计算机可以被嵌入到另一个装置中，例如，移动电话，个人数字助理(pda)，移动音频或视频播放器，游戏机，全球定位系统(gps)接收器，或便携式存储装置(例如，通用串行总线(usb)闪存驱动器)，仅举几例。适用于存储计算机程序指令和数据的装置包括所有形式的非易失性存储器，介质和存储装置，包括例如半导体存储装置，例如eprom，eeprom，和闪存装置；磁盘，例如内部硬盘或可移动磁盘；磁光盘；以及cd-rom和dvd-rom磁盘。处理器和存储器可以由专用逻辑电路补充或并入专用逻辑电路中。

为了提供与用户的交互，可以在具有显示装置的计算机上实现本说明书中描述的主题的示例，该显示装置例如为lcd(液晶显示器)，led(发光二极管)，或oled(有机发光二极管)显示器，用于向用户显示信息以及键盘和指示装置，例如鼠标或轨迹球，用户可以通过该指示装置向计算机提供输入。在一些实施方式中，触摸屏可以用于显示信息并从用户接收输入。其他种类的装置也可以用于提供与用户的交互。例如，提供给用户的反馈可以是任何形式的感觉反馈，例如视觉反馈，听觉反馈，或触觉反馈；并且可以以任何形式接收来自用户的输入，包括声音，语音，或触觉输入。另外，计算机可以通过向用户使用的装置发送文档以及从用户使用的装置接收文档来与用户进行交互；例如，通过响应从网页浏览器收到的请求，将网页发送到用户客户端装置上的网页浏览器。

本说明书中描述的主题的示例可以在包括后端组件(例如，作为数据服务器)，或者包括中间件组件(例如，应用服务器)，或者包括前端组件(例如具有图形用户界面或网页浏览器的客户端计算机)，用户可以通过该这些与本说明书中描述的主题的实现方式，或者一个或多个此类后端，中间件，或前端组件的任意组合进行交互。系统的组件可以通过数字数据通信的任何形式或介质(例如，通信网络)互连。通信网络的例子包括局域网(“lan”)和广域网(“wan”)，网际网络(例如互联网)和对等网络(例如点对点(adhoc)对等网络)。

计算系统可以包括任意数量的客户端和服务器。客户端和服务器通常彼此远离，并且通常通过通信网络进行交互。客户端和服务器之间的关系是通过在各自计算机上运行并彼此具有客户端—服务器关系的计算机程序产生的。在一些示例中，服务器将数据(例如，html页面)发送到客户端装置(例如，出于向与客户端装置交互的用户显示数据并从中接收用户输入的目的)。可以在服务器处从客户端装置接收在客户端装置处生成的数据(例如，用户交互的结果)。

根据前述内容，将理解的是，出于说明的目的，本文已经描述了所公开的技术的特定示例，但是在不脱离本发明的范围的情况下可以进行多种修改。因此，除了所附权利要求书，本发明不受限制。