优化后备人员模式的制作方法

本申请要求2019年5月15日提交的第62/848,374号美国临时申请的提交日期的利益。通过引用将第62/848,374号美国申请的全部内容并入本文。

背景技术

本公开一般涉及集合覆盖优化。集合覆盖问题可以用于对在诸如计算机科学、运筹学和物流的不同学科和行业中存在的问题进行建模。需要改进此类建模的计算效率和准确性的过程。

技术实现要素：

本说明书涉及对复杂物流调度操作执行集合覆盖优化。本文参考航空公司后备人员(reserve crew)模式优化的示例上下文描述实现。通常，本说明书中描述的主题的创新方面可以被体现在包括获得包括预测数据和后备值勤模式参数的输入数据的操作的方法中。操作包括迭代生成后备需求覆盖率(RDCR)矩阵的附加覆盖率列，直到满足停止准则为止，其中，每次迭代包括：通过基于RDCR矩阵内的覆盖率列的集合并使用线性问题约束解决集合覆盖问题，确定指示航空行程的后备需求覆盖的增量变化的边际值的影子值，为迭代而选择覆盖率列的集合；生成新后备值勤模式，所述新后备值勤模式包括改进值；以及确定新后备值勤模式的改进值是否满足停止准则。当新后备值勤模式的改进值不满足停止准则时，操作包括：基于新后备值勤模式生成新覆盖率列，并将新覆盖率列附加到RDCR矩阵作为附加覆盖率列。如果新后备值勤模式的改进值确实满足停止准则，则操作包括停止迭代生成附加覆盖率列，并基于RDCR矩阵生成后备值勤模式的最终集合。该方面的其他实现包括相应的系统、装置和计算机程序，其被配置为执行在计算机存储设备上编码的方法的动作。

在一些实现方式中，生成新后备值勤模式包括：基于输入数据，确定多个可能后备值勤模式以覆盖多个航空行程；确定每个可能后备值勤模式的改进值，其中，每个改进值基于影子值和与每个可能后备值勤模式相关联的试验覆盖率来确定；以及基于具有在可能后备值勤模式的所有改进值中最高的相应改进值的特定后备值勤模式，从可能后备值勤模式中选择特定后备值勤模式。

在另一一般方面中，本说明书中描述的主题的创新方面可以被体现在包括获得包括预测数据和后备值勤模式参数的输入数据的操作的方法中。操作包括迭代生成后备需求覆盖率(RDCR)矩阵的附加覆盖率列，直到满足停止准则为止，每次迭代包括：对于RDCR矩阵内的覆盖率列的集合，确定影子值，影子值指示航空行程的后备需求覆盖的增量变化的边际值，为迭代选择覆盖率列的集合；基于输入数据，确定多个可能后备值勤模式以覆盖多个航空行程；确定每个可能后备值勤模式的改进值，其中，每个改进值基于影子值和与每个可能后备值勤模式相关联的试验覆盖率来确定；从可能后备值勤模式中识别特定后备值勤模式，其相应改进值在可能后备值勤模式的所有改进值中最高；确定相应改进值是否满足停止准则。当特定后备值勤模式的改进值不满足停止准则时，操作包括：从与特定后备值勤模式相关联的试验覆盖率生成新覆盖率列；以及将新覆盖率列附加到RDCR矩阵作为附加覆盖率列。当特定后备值勤模式的改进值确实满足停止准则时，操作包括：停止迭代生成附加覆盖率列；并且基于RDCR矩阵，生成后备值勤模式的最终集合。

这些和其他实现方式都可以选择性地包括以下一个或多个特征。

在一些实现方式中，RDCR矩阵的附加覆盖率列是使用线性问题约束生成的。

在一些实现方式中，使用整数问题约束生成后备值勤模式的最终集合。

在一些实现方式中，RDCR矩阵的附加覆盖率列是使用线性问题约束生成的，并且其中后备值勤模式的最终集合是使用整数问题约束生成的。

在一些实现方式中，预测数据将多个航空行程与指示每个航空行程将需要后备人员覆盖的概率的预期后备需求值相关联。在一些实现方式中，预测数据包括与多日航空行程相关联的至少一些预期后备需求值。在一些实现方式中，预测数据包括未四舍五入的预期后备需求值。

在一些实现方式中，后备值勤模式参数包括后备模式长度和每个后备区块的最小占比天数。

在一些实现方式中，确定影子值包括基于RDCR矩阵内的覆盖率列的集合并使用线性问题约束来解决集合覆盖问题。在一些实现方式中，生成后备值勤模式的最终集合包括基于RDCR矩阵的最终列集合并使用整数问题约束来解决集合覆盖问题。

在一些实现方式中，操作包括通过基于RDCR矩阵和混合预测数据解决集合覆盖问题来生成修订的后备值勤模式集合，其中，混合预测数据将第一多个航空行程与实际后备需求数据相关联，并将第二多个航空行程与指示每次航空行程将需要后备人员覆盖的概率的预期后备需求值相关联。

在一些实现方式中，后备值勤模式参数包括有限数量的特殊后备值勤模式。

本说明书中描述的主题的一个或多个实现的细节在附图和下面的描述中阐述。从说明书、附图和权利要求书中，主题的其他特征、方面和优点将变得显而易见。

附图说明

图1描绘了用于执行本公开的实现的示例系统。

图2描绘了可根据本公开的实现方式执行的示例后备人员优化处理的流程图。

图3A描绘了简化覆盖矩阵的示例。

图3B描绘了从图3A的简化覆盖矩阵生成的后备值勤模式的简化集合的示例。

图4描绘了来自使用真实世界数据的案例研究的投标月份的示例行程调度。

图5描绘了对图4的行程调度预测的预期后备需求数据的示例矩阵。

图6描绘了表示从使用真实世界数据的案例研究通过本公开的实现方式生成的覆盖解决方案的各方面的图表。

图7描绘了表示从使用真实世界数据的案例研究通过本公开的实现方式生成的全覆盖解决方案的图表。

各种附图中的相似参考符号表示相似的元件。

具体实施方式

本说明书涉及对复杂物流调度操作执行集合覆盖优化。本文参考航空后备人员模式优化的示例上下文描述实现。然而，实现可能适用于其他复杂物流调度的优化建模，诸如仓库操作、卡车操作、包裹交付等。

可以实现本说明书中描述的主题的特定实现，以实现以下一个或多个优点。实现可以为随机问题提供更完整和准确的集合覆盖解决方案。例如，与生成模式以一对一覆盖后备需求的传统方法不同，该模型设计的模式以概率方式以多对多模式覆盖后备需求。生成每个选定模式不仅是为了覆盖一个没有重叠的行程集合，而且是为了覆盖行程之间具有重叠的一些可能行程集合。这样，即使此类行程的预测后备需求不会发生，该模式仍可以用于覆盖其他后备需求。与现有的确定性优化技术相比，实现方式可以提供更好的容错性。例如，多对多覆盖模式可以为模型提供高容错性，这可以减少在解决集合覆盖问题(诸如航空后备人员调度)时不确定性的负面影响。实现方式提高估计后备需求调度的精度。例如，实现方式采用基于逐行程构建的而不是基于每日构建的后备需求预测数据；意味着每个后备需求估计值表示后备人员将需要覆盖整个行程的预期，这可能会跨越多个连续天。此外，后备需求数据未四舍五入，例如，为调度提供额外精度。

图1描绘用于执行本公开的实现的示例系统100。系统100包括优化系统102、飞行人员管理系统104、预测系统106和一个或多个用户计算设备108。优化系统102通过网络110与飞行人员管理系统104、预测系统106和一个或多个用户计算设备108通信。网络110可以包括大型网络或网络组合，诸如局域网(LAN)、广域网(WAN)、互联网、蜂窝网络、卫星网络、一个或多个无线接入点或连接任意数量的移动客户端、固定客户端和服务器的其任何适当组合。

优化系统102、飞行人员管理系统104和预测系统106中的每个可以使用一个或多个计算系统(例如，服务器)来实现。计算系统可以具有内部或外部存储组件，并且可以表示各种形式的服务器系统，包括但不限于web服务器、应用服务器、代理服务器、网络服务器、用户帐户服务器或服务器场。尽管示出为单独的计算系统，但在一些实现中，系统102、104和106中的一个或多个可以集成到单个系统中。例如，优化系统102、飞行人员管理系统104和预测系统106的操作都可以由相同的计算系统(诸如公共服务器系统)执行。

用户计算设备108可以包括但不限于膝上型计算机或台式计算机、移动电话、智能手机或平板计算机。

如本文所讨论的，优化系统102执行在为航空公司生成后备人员集合覆盖模式的上下文中描述的集合覆盖优化模型。例如，在操作中，优化系统102可以从飞行人员管理系统104和预测系统106接收输入数据。输入数据可以包括但不限于后备模式参数112和预期后备需求数据114。优化系统102基于输入数据执行本文描述的集合覆盖优化模型，以生成后备人员执勤(duty)模式集合。后备值勤调度116可以根据后备人员执勤模式创建并被提供给用户计算设备108。

例如，预测系统106可以执行预测工具(例如，SAS企业指南中的预测工具)来估计与在特定时间段(例如，投标月)上调度的航空行程相关联的后备需求数据。需求是开放时间行程的预期数量，不一定是整数值。本发明的实现不会对分数的后备需求数字进行四舍五入。例如，保留未四舍五入的后备需求估计值将保留有价值的统计信息，供下文所述的调度系统使用。此外，实现采用基于每个行程组织而不是基于每天组织的后备需要数据。也就是说，预期后备需求的每个值与跨越连续几天的定期调度行程相关联，而不是与例如单个每日行程相关联。

后备需求数据可以用矩阵D表示，具有d作为指数(如图5所示)，包括来自预测工具的所有类型的行程。后备需求数据是优化模型的一个输入。矩阵的列指示行程类型的长度l，且矩阵的行指示行程的开始日期t。投标月的总天数为T，且矩阵的元素nd是行程类型的预期后备需求(t,l)∈D。在某些情况下，同一类型行程的多个实例在投标月内被调度，并且nd可以表示相同类型的所有行程的组合预期后备需求(t,l)。因此，nd可以是分数，并且可以小于1或大于1。

例如，如图5所示，行程(1,3)(附图标记502)指示行程为3天，并且从投标月的第1天开始。行程(1,3)的nd为0.313422774，指示约有31％的可能性需要后备人员来覆盖行程(1,3)。作为另一个示例，行程(16,2)(附图标记504)指示行程为2天，并且从投标月的第16天开始。行程(16,2)的nd为2.92138634，指示约有292％的可能性需要后备人员来覆盖行程(16,2)之一。换句话说，在给定投标月内，有多个类型(16,2)的行程。例如，可能有六个类型(16,2)的行程，每次有约50％的可能性需要后备人员的覆盖。因此，给定投标月的行程类型(16,2)的组合预期后备需求约为292％。简言之，在六个类型(16，2)的行程中，六个中的三个将需要由后备人员覆盖。

为了方便检查是否一个后备模式i可以覆盖行程，二进制参数被设置为，以指示行程d的值班(on-duty)天数。如果行程d包括天数t作为值班天数，则是1，否则为0。基于，行程可以被转换为二进制模式。以28天(T＝28)的投标月份的行程(17，9)为例，行程可以用以下向量表示：

(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 0 0)

目标是建立后备模式集合，以尽可能低的成本满足这些预期的需求水平。与常规线路调度行程不同，后备模式不包括任何行程或配对。相反，它们包括连续值班日的块和连续休班日的块。模式的索引P指示一个投标期内的最大总值班天数。由于后备人员的特殊薪酬结构，无论运营多少天，他们都将至少获得后备线保证(Reserve Line Guarantee，RLG)的报酬，所以期望将尽可能多的后备天数包括在后备模式中。因此，该模式包括最大值班天数。换句话说，P指示模式的长度，除非成本结构发生更改。

传统上定义模式类型以缩小变量集。也就是说，在目前的系统中，模式类型通常由值班日分组和休班日分组来定义。通过确定每种类型模式的所需数量，可以减少变量集并提高求解速度，从而提高优化系统102的效率。然而，预先决定的模式类型成为模型的参数。同时，由于很难列出所有类型的模式，因此也存在解决方案空间的限制。然而，在本公开的实现中，模式由更多的元素定义，这意味着可以包括所有合法的模式类型。例如，一种模式类型由值班块类型和休班块类型确定。值班块类型由向量变量描述，其中元素的数量由模式中有多少值班块决定，并且元素的值由每个块中的连续值班天数决定。休班块也是向量变量，其中元素的数量由模式中有多少休班块决定。在一些实现中，休班块向量变量始终等于值班块类型中的元素数加上一，因为值班块位于两个休班块之间。休班块类型中的元素的值由每个块中的连续的休班天数确定。值班块类型中元素的总值加上休班块类型中元素的总值等于投标期内的总天数。通过调整休班块中的元素值，可以设计具有不同元素数量的值班日块类型。

航空公司可以使用不同的后备模式参数112(例如，规则)来构建合法的后备模式。后备模式参数112通常包括但不限于模式P的长度以及一个块MB内的最小值班日。令K表示值班块的最大数量。因此，休班块的数量为K 1，其索引为k。任何块都可以为零天，但并非所有休班块都被允许同时为零。K可以通过用P除以M且将其四舍五入为整数来计算。例如，假设一个航空公司允许模式的最大长度为15天且一个块中的最小值班日为4天，K可以简单地通过向下四舍五入15/4来计算，四舍五入后等于3。休班块类型的元素值yk是包括0的整数。休班块类型可以被指示为[y1，y2，...，yk 1]。如果y1为0，则意味着后备模式从每月的第一个星期一开始。如果yk 1为0，则表示后备模式在该月的最后一个星期日结束。如果一个yk——其中，k既不等于0也不等于K 1——等于0，则这表示值班块的数量为K-1。如果两个yk——k既不等于0也不等于K 1——均等于0，则这表示值班块的数量为K-2且第四个直到只有一个值班块存在于具有P个值班日的模式中。通过这种类比，可以识别具有从1到K的不同元素数量所有值班块类型。令ak表示值班块类型的元素值。

对于每种模式i，令二进制变量表示在模式中哪一天是值班日和哪一天是休班日。模式i在具有T天的投标期内具有总共P个值班日。如果t日在模式i中是值班日，则是1，如果t日是休班日，则是0。一个示例值勤模式向量，Oi，，如下所示：

(0 0 1 1 1 1 0 0 0 1 1 1 1 0 0 0 0 0 1 1 1 1 1 1 1 0 0)

此示例模式包括三个值班块和四个休班块。值班块类型为[4，4，7]，休班块类型为[2，3，5，2]。模式类型为[4，4，7]_[2，3，5，2]。

后备模式的质量是控制成本的一个方面，因为行程的未覆盖成本率远高于后备成本率。通常，更长的后备块在覆盖各种开放时间行程时具有较高的可用性，但有其局限性。在已有的调度模型中，无论开放时间行程发生的可能性是大还是小，当它作为输入或参数被应用于模型时，总是被视为具有100％可能性的需求，因为最小的非零整数是1。表1(下文)所示的示例用于描述该限制。

表1.按模式的行程覆盖的示例

行程1和行程2是需要在投标期内覆盖的两个开放时间行程，前8天如表1所示。行程1为(2,3)，行程2为(3,3)。有三种不同的后备块可用于构建后备模式。块1只能覆盖行程1，块2只能覆盖行程2。块3可以覆盖两个行程。然而，决定使用构建块3可能不是最优的。首先需要设定一些假设。

假设1：这三个块的成本相同，尽管它们支持不同的值班日；

假设2：由于行程1和行程2的长度相同，因此其未覆盖成本相同；

假设3：行程1和行程2退出并成为开放时间行程的可能性相等。

根据这三个假设，可以说，如果只能选择一个块，则块3始终是最佳选择。如果行程1和行程2发生不止一次，并且可以使用两个块，则使用块3构建两个模式可能是一个好的决策。

然而，在现实世界实践中，这些假设可能并不总是得到满足。例如，模式可能包括12天或更长时间以及表1中未示出的其他值班块，可以用于覆盖第8天之后开始的其他行程。例如，假设从第9天开始的一个9天行程需要覆盖，如果使用块1或块2，则尽管一个3天行程可能没有覆盖，但还有9个值班日，可以构建以覆盖该长行程。相反，块3有机会覆盖行程1和行程2，但如果选择该块，则剩余的值班日不足以覆盖12天的行程，并且无法在日常运营的同一投标期内同时覆盖行程1和行程2。在这种情况下，尽管后备值勤模式的成本相同，但值班块的成本与块长度相关。

具有更复杂条件的示例如表2(下文)所示。行程1(2,3)和行程3(4,5)是两种可能的开放时间行程。可以构建块1、块4和块5来覆盖这两个行程。块1只能覆盖行程1，块4只能覆盖行程3，且块5可以覆盖这两个行程。

表2.按模式的行程覆盖的另一示例

表3.发生可能性的示例情况

行程的长度不同，块的长度也不同。在情况1中，在表3的第一列中，开放时间行程1发生的可能性为90％，行程3发生的可能性为20％。块5仍然是最好的选择吗？换言之，是否值得在块中增加4天来覆盖行程3？块5可能是比块4更好的选择，而且显然是比块1更好的选择。在情况2中，在第二列，开放时间行程1发生的可能性为40％，行程3发生的可能性为80％。是否值得块5的2天增加以覆盖行程1？至少，在这种情况下，选择块5的置信度高于情况1，因为0.4×3大于0.2×5。换句话说，应考虑可能的未覆盖成本。在情况3中，在第三列，两种情况发生的可能性均为50％。选择块5似乎比选择块1或块4更合理。在情况4中，在第四列，开放时间行程1发生的可能性为80％，行程3发生的可能性为70％。如果后备人员的能力允许，可以选择块1和块4二者以覆盖行程1和行程3。在情况5中，在最后一列，开放时间行程1发生的可能性为67％，行程3发生的可能性为58％。在这种情况下，如果没有任何数学模型的支持，很难决定如何选择块。实时情况可能比本示例中的情况复杂得多，因为它们需要比较完整的模式，而不仅仅是块。开放时间行程和模式的规模远大于表1-3中的示例。下面讨论的优化模型解决这些和其他技术问题。

图2描绘了可以根据本公开的实现执行的示例后备人员优化处理200的流程图。在一些实现中，可以将处理200提供为使用一个或多个计算设备执行的一个或多个计算机可执行程序。在一些示例中，处理200由诸如图1的优化系统102的系统执行。在一些实现中，处理200的全部或部分可在本地计算设备、台式计算机、膝上型计算机或平板计算机上执行。在一些实现中，处理200的全部或部分可在远程计算设备、服务器系统或基于云的服务器系统上执行。

过程200表示用于解决上面讨论的后备调度问题的优化模型。过程200可以降低总后备成本，其中包括两个主要成本：一个是后备人员成本，另一个是未覆盖行程的成本。令c表示一种模式的成本，并且sd是行程d的未覆盖需求的单位成本，这与行程长度有关。未覆盖行程d(l,t)的成本是sd×l。该方法通过保持预期的需求水平，将后备预测阶段集成到优化阶段。如果预期需求水平小于1，则可将其视为发生可能性或概率。该信息可以提高后备模式的质量，诸如在日常运营阶段，通过增加覆盖开放时间行程时的可用性。

为了开始处理200，系统获得优化模型输入数据。例如，系统可以从预测系统106接收预期后备需求数据114。如上所述，预期后备需求数据可以包括但不限于将多个航空行程与预期后备需求值相关联的预测数据，并且是预期后备需求值。例如，预期后备需求数据114可以是预期后备需求矩阵，其将多个航空行程与指示每个航空行程将需要后备人员覆盖的概率的预期后备需求值相关联。类似地，系统可以从飞行人员管理系统104接收后备模式参数112。如上所述，后备模式参数112可以包括但不限于后备模式长度(P)和每个值勤块的最小值班天数(MB)。

系统生成后备需求覆盖矩阵202。例如，系统可以在优化模型中引入矩阵202，被称为“覆盖”或覆盖矩阵202。图3A描绘了覆盖矩阵202的简化示例(例如，简化覆盖矩阵300)。通常，覆盖矩阵202提供一种概率(或速率)，以该概率(或速率)，给定后备模式可以被用于覆盖对应的行程。

例如，令J表示覆盖矩阵202，其具有所有开放时间行程的所有可能覆盖覆盖的集合，j作为索引。一个覆盖列j是与模式处于一一对应的|D|个元素(例如，调度行程的总数)的向量。覆盖矩阵202的每个元素是模式i(对应于覆盖矩阵202的列j)可以被用于覆盖开放时间行程d的概率(或速率)，并被表示为的值在范围[0，1]内。这种多对多覆盖模型可以提供更健壮和有效的后备覆盖模式。具体地，覆盖矩阵202允许多对多覆盖。多对多覆盖是指能够使用多于一个后备模式来覆盖行程(根据相关的覆盖率)，并且能够让一个后备模式为给定日历日的多于一个行程提供部分(小于100％)覆盖。例如，如简化覆盖矩阵300所示，基于覆盖列1的后备模式将能够覆盖行程1的、行程1需要后备人员覆盖的时间的100％，覆盖行程2的、行程2需要后备人员覆盖的时间的45％，覆盖行程3的、行程3需要后备人员覆盖的时间的35％，覆盖行程4的、行程4需要后备人员覆盖的时间的450％，且将无法覆盖行程5。

处理200采用列生成处理204来构建合格的后备模式。模型输入数据112、114和覆盖矩阵202被应用为列生成处理204的输入。构建子问题(如下所述)，以确保在优化处理中考虑能够被模式i覆盖的所有开放时间行程。此外，所有模式能够被用于覆盖开放时间行程d在处理中比较。qd用于指示模式i对行程d的覆盖的可能性。每种可能模式i以向量为特征，具有二进制值的T个元素。

二进制变量xj等于1以表示覆盖列j被选择，否则等于0。非负变量ud表示未覆盖开放时间行程需求d的量。优化模型的主问题可以被描述如下：

主问题：

服从于

xj∈{0，1}；ud≥0 (1.3)

主问题(1.1-1.3)是集合覆盖问题，它总是可行的，因为存在ud。约束集(1.2)描述了覆盖子集如何覆盖后备需求。当集合J包括足够数量的所有可能的覆盖范围，主问题可以产生最佳的解决方案。为了使问题易于处理，列(与xj相关联)遵循列生成过程以迭代方式创建。当其线性松弛(例如，xj∈[0,1])被求解为其最优性时，可以确定约束d的影子值(例如，影子价格)(以wd表示)。

对于每个可能的后备模式，处理200使用子问题(定义如下)来计算模式的潜在改进值(vm-c)，其中，c表示附加后备模式的成本，且vm表示后备模式m可以提供的未覆盖行程的成本的减少量。改进值(vm-c)表示给定模式将向由主集合覆盖问题控制的总体优化模型提供的潜在成本改进。为了缩短求解时间，在子问题中生成所有可能的后备值勤模式的集合，I。变量用于定位投标期内的所有值班日。如果t日在此模式中是第f值班日，则是1，否则为0。

子问题：

服从于

选择最大vm以在主问题中创建新列，其系数向量为qd。m表示包括所有合法值班块类型的集合M的元素，例如，满足每个值勤块的最小值班天数(MB)的所有值班块类型。如果模式i被选择为对行程d的潜在覆盖，则约束集(1.5)描述行程d中的每个值勤日，也是模式i中的值班日。约束集(1.6)确保行程d的覆盖不大于其需求。其余的约束都用于构建后备模式。约束(1.7)和(1.8)设置后备模式的长度和总休班日。约束集(1.9)确保模式的第f值班日仅定位在一天。约束集(1.10)用于定位投标日历中的所有值班日。约束集(1.11)具有描述模式i中的每个值班块的K个约束集。

简言之，整体算法可以被描述如下。

步骤206：求解主问题(1.1-1.3)，xj∈[0,1]，得到wd。

步骤208：对于所有m(合法值班块类型)∈I(所有后备模式)，求解所有子问题(1.4-1.12)，得到vm(每种模式类型的改进值)，以找到具有vm的最大值的后备模式(识别具有最高值的新后备模式)。

步骤210：如果最大vm不大于c(附加模式的成本)，则停止并转至218。

步骤212：向J插入以对应于最大vm的qd(模式m的试验覆盖率)为特征新覆盖列，新转至步骤206。

步骤218：求解主问题，xj∈{0,1}。

更详细地，系统确定后备覆盖的改进的影子值(206)。例如，系统可以确定后备需求矩阵(D)的每个行程类型(d)的影子值(wd)。在一些示例中，系统可以通过使用松弛约束求解上述主问题来确定影子值。例如，通过用xj∈[0,1]而不是用xj∈{0,1}来松弛对xj的约束。换言之，通过允许xj采用0和1范围内的线性值，系统可以将主问题求解为线性问题(LP)，而不是整数问题(IP)。在一些实现中，系统可以通过使用优化求解器(例如，Gurobi求解器、IBM ILOG CPLEX和基数优化器)执行主问题并获得影子值。

系统确定具有最大潜在覆盖改进的可能后备值勤模式(208)。例如，系统可以从所有潜在(例如，根据后备值勤模式参数112是合法的)后备执勤模式中识别可能后备值勤模式，其具有最大的潜在覆盖改进以添加到覆盖矩阵202。例如，系统可以执行上面讨论的子问题，以确定多个可能后备值勤模式。系统可以基于从主问题(例如，步骤206)确定的影子值对每个可能后备值勤模式计算改进值(vm)。如等式(1.4)所述，每个后备模式的改进值可以基于由后备模式覆盖的潜在行程的相应影子值和后备模式将覆盖潜在行程的试验覆盖率(qd)来确定。系统可以从可能后备值勤模式中识别出具有最高改进值的特定后备值勤模式。

在一些实现中，系统使用分层方法(tiered approach)来确定具有最大潜在覆盖改进的可能后备值勤模式。例如，系统可以在所有合法值班块类型的集合M的每个合法值班块类型m中循环，识别每个块类型m内的最高值模式。

例如，假设后备模式的长度为15天，因此总休班天数为28-15＝13。每个值班块包括至少4个后备日(例如，MB＝4)，因此值班块的最大数量K是3。共有16个合法值班块类型M，如下所列：[4,4,7]；[4,7,4]；[7,4,4]；[4,5,6]；[5,4,6]；[6,5,4]；[5,5,5]；[4,11]；[11,4]；[7,8]；[8,7]；[6,9]；[9,6]；[5,10]；[10,5]；和[15]。这16个合法块类型中的每一个可以在给定投标月的天内以多种不同的模式分布。

系统可以确定提供最大潜在覆盖改进的块类型m＝1的模式(例如，块类型[4,4,7])，并将该值存储为v1。例如，系统可以使用等式(1.4)计算块m＝1的每个可能模式(例如，块类型[4,4,7])的改进值并识别提供最大值的模式。系统可以存储已识别的块类型m＝1模式及其相关的改进值(例如，v1)。然后，系统对块类型m＝2(例如，块类型[4,7,4])执行相同处理，以此类推，直到集合M中的所有每个合法块类型已被评估为止。

系统比较每个合法块类型的相应改进值(vm)，以识别具有最大潜在覆盖改进的可能后备值勤模式。在一些实现中，系统在比较所有存储的改进值(vm)之前完成每个合法块类型的评估，以识别具有最大改进值的模式。在一些实现中，在评估每个合法块类型m时，系统持续比较改进值(vm)。例如，在第二块类型(m＝2)被评估为改进值(v2)之后，系统能够将存储的改进值v1与v2的值进行比较。系统能够存储两个值中的更大值以及相关的后备模式。然后，系统可以对每个后续的合法块类型重复处理；仅存储具有更高改进值(vm)的模式，直到集合M中的所有合法值班块类型被评估为止。剩下的存储的后备模式则将是具有最大改进值(vm)的模式。

例如，可以将最高改进值(例如，maxvm)与停止准则进行比较(210)，以确定列生成处理204是否完成并且可以停止，或者是否应该生成附加列。例如，停止准则可以是向后备调度添加附加后备模式的成本(c)。如果所识别的后备模式的改进值大于将后备模式添加到后备调度的成本，则列生成处理(204)前进到步骤(212)。如果所识别的后备模式的改进值小于将后备模式添加到后备模式的成本，则列生成处理(204)完成，并且优化处理200前进至步骤(218)。

在步骤(212)，将与具有最高改进值的后备模式相关联的覆盖列添加到覆盖矩阵202。例如，通过添加新覆盖列来更新覆盖矩阵202。然后在步骤206中使用覆盖矩阵的更新版本(例如，更新的覆盖矩阵214)来执行列生成处理(204)的后续迭代。例如，参考图3A的简化覆盖矩阵300，与覆盖列2、3和4相关联的后备模式的改进值可能已经大于将相关联的后备模式添加到调度的成本。因此，在列生成处理(204)的相应迭代期间，覆盖列2、3和4中的每一个将被添加到简化覆盖矩阵300。例如，当覆盖列被添加到覆盖矩阵202时，新的覆盖列(例如，图3A中的简化覆盖矩阵300的第2列)根据所选择的后备模式的试验覆盖率生成。也就是说，所选择的后备模式是被识别为对于列生成处理(204)的特定迭代具有最高改进值的特定后备模式。

在一些实现中，系统可以向覆盖矩阵202添加多个列。例如，系统可以在子问题的每次迭代期间向覆盖矩阵202添加多个(例如，两个或更多)新列，只要添加的列中的每一个具有不满足停止规则的改进值(例如，veach column不大于c)。在一些示例中，系统可以将关于每个合法模式类型的最佳生成模式添加为覆盖矩阵202中的新列。每个合法模式类型的最佳模式可以被评估为每个合法模式类型中具有最高改进值的模式。在一些实现中，系统可以添加预定数量的新模式(例如，5、10、15等)。例如，系统可以将前五个模式作为列添加到覆盖矩阵202(例如，具有五个最高改进值的模式)。

在步骤(218)，系统使用最终后备需求覆盖矩阵216来生成后备值勤模式的最终集合。例如，最终后备需求覆盖矩阵216是包含在列生成处理(204)期间已经添加的所有覆盖列(例如，图3A的简化矩阵300中的列2-4)的覆盖矩阵202。例如，系统可以使用最终后备需求覆盖矩阵216通过在完全约束下(例如，xj∈{0,1})执行主问题来生成后备值勤模式的最终集合。

例如，参考图3A的简化覆盖矩阵300，执行主问题以生成最终后备值勤模式(218)可以导致从简化覆盖矩阵300中选择覆盖列1、2和4作为最佳后备覆盖解决方案。举例来说，当主问题在完全约束下作为整数问题被求解时，主问题的这样的解决方案将生成xj向量：[1 1 0 1]。系统可以转换后备需求覆盖矩阵216的最终版本的选定列，以生成后备值勤模式的最终集合。

例如，图3B描绘了从图3A的简化覆盖矩阵300生成的后备值勤模式的简化集合354的示例。图表350图示了后备值勤模式1、2和4在10个日历日内为行程1-5提供的覆盖。同时，根据每个行程(nd)的相应预期后备需求，选定的后备值勤模式354在简化投标月中为行程352提供了完整的覆盖。例如，在第1天和第2天，如果需要，后备值勤模式1-3中的每一个可用于覆盖行程1。在第4天，如果需要，后备值勤模式1可用于覆盖行程2。在第5天，后备值勤模式1可用于覆盖行程2和行程3，覆盖率分别为0.45和0.1。在日历的第6天，后备值勤模式1和2可用于覆盖行程2、3和4。更具体地，在第6天，后备值勤模式1可用于覆盖行程2和行程3，总覆盖率为0.55，并且也可用于覆盖行程4，覆盖率为0.45。然而，行程4的预期后备覆盖为1.25，因此后备值勤模式2可用于覆盖行程4，覆盖率为0.8。换言之，后备值勤模式2将覆盖行程4 80％的时间。在第8-10天，后备值勤模式也可用于行程5，覆盖率为0.2，并且后备值勤模式4可用于行程5，覆盖率为0.95。

在一些示例中，该优化处理200的解决方案不仅包括所选后备模式的集合和未覆盖行程，而且还包括由每个所选模式覆盖的开放时间行程的集合以及可用于覆盖每个开放时间行程的所有模式。后备需求的覆盖可能存在两种情况。一种情况是需求被较少的模式覆盖，但与预期需求的值相比，具有足够高的可能性。另一种情况是开放时间行程可以被更多的模式覆盖，每个模式覆盖的可能性相对较低。在这种情况下，虽然一种覆盖的可能性低，但它可以被更多的模式覆盖，这使得它仍然有很好的机会基于预期需求水平被覆盖。

在一些实现中，可以基于不同航空公司的不同后备模式参数(例如，后备调度规则)向模型添加附加或替代约束。例如，后备人员的能力可以被添加到主问题中，其公式如下。然而，由于优化模型可以给出待分配给后备人员的后备模式集合，因此并不总是需要包括在内。该集合是模型找到的最优解，后备模式的数量可以作为调度器的建议，并且它们可以调整其他人员组，以找到达到(carry)它们的一些人员。存在很多方式来改进后备人员管理。例如，如果后备人员的管理长期不好，则会影响后备人员在月前规划阶段的能力。最优解受能力的限制。

另一个可以给出的改进示例是日常操作中的分配策略。适合模式设计的好的分配策略将尽可能有利于模式的覆盖效果。在一些实现中，可以使用混合预测数据来重复主问题。例如，主问题可以在投标月期间重复，以随着投标月的进展调整后备人员分配。可以使用实际行程数据来更新预测数据，因为定期调度的行程或者按计划执行，或者被取消并由后备人员覆盖。例如，参考图3B，如果行程2与定期调度的人员一起按调度飞行，则与行程2相关联的预测数据可以被指示行程按调度执行的实际数据替换(例如，行程2的nd可以被零替换，指示该行程不需要由后备人员覆盖)。行程2的实际数据释放对用来可能覆盖行程2的后备模式(RD模式1)的需求，从而使其用于可覆盖其他行程。因此，重新运行主问题将RD模式1重新分配给可能仍需要后备覆盖的另一个行程。为了在投标月期间重新分配行程，可以使用最终后备需求覆盖矩阵216和混合预测数据来例行运行主问题(例如，每日、每周等)。在这种情况下，主问题可以作为完全约束(例如，xj∈{0,1})下的整数问题被运行，这减少了生成重新分配所需的计算资源和时间。

开发多阶段随机优化处理来决定是否可以放弃任何行程。当日常运营阶段开始时，同时开始后备分配处理。对于投标期的每一天，每个开放时间行程类型的数量成为已知信息。在将其分配给某人员的后备线(reserve line)之后，可以更新优化模型的参数值，诸如后备需求矩阵。从列生成算法获得的模式集合在去除已分配行程的后备日和基于章程被释放的后备日之后成为固定输入数据。

使用这些更新的参数重新运行优化模型，系统可以更新覆盖，以为下一个随机阶段提供分配建议。给出了允许的下降(dropping)后备日的列表，其中将在顶部列出具有较高覆盖影响而下降的后备日。高阶的模式应得到更好的保护。当找到可行的后备块的集合且有足够长的值班块覆盖开放时间行程时，在分配处理中，可以考虑一些策略：

1)选择此集合中最短的一个。完美匹配是最好的。

2)如果存在多于一个的块满足，则选择之前具有更多未使用后备日或更少值勤小时的块。

3)如果存在多于一个的块满足，则考虑该长模式是否应该对于长行程被保存为具有相关较高可能性。

图4-图7代表来自美国主要航空公司进行的实验案例研究的数据。随机选择一个4周的投标月作为目标。投标月的总天数T是28。行程长度的范围为1至13。该投标期的调度行程被存储在如图4所示的矩阵中，该矩阵用作后备预测系统106的输入。图5示出了对于在图4的调度矩阵中所示的行程的预期后备需求矩阵D。

例如，假设后备模式的长度为15天，从而总的休班天数为28-15＝13。每个值班日块至少包括4个后备日(例如，MB＝4)，从而值班块的最大数量K是3。合法值班块类型M如下所列：[4,4,7]；[4,7,4]；[7,4,4]；[4,5,6]；[5,4,6]；[6,5,4]；和[5,5,5]。有4个休班块。当两个值班块之间的一个块为0时，值班块的数量减少到2。如果值班块之间的两个休班块均为0，则模式将变为只有一个值班块的15天长模式。通过设置休班块，在模型中创建具有少于3个值班块的所有合格值班块类型，诸如：[4,11]；[11,4]；[7,8]；[8,7]；[6,9]；[9,6]；[5,10]；[10,5]和[15]。

将一个后备模式授予人员的成本假设为100，且每日行程的未覆盖成本为15。模型的子问题中用于生成模式的约束如下所示：

y1 y2 y3 y4＝13 (1.14)

图6的图表600是解决方案中的模式之一。列表示4周投标月的日。第一行是由模型生成的模式，其模式类型为[5,4,6]_[2,2,2,7]。带1的元素指示值班日，且空着的元素指示休班日。除第一行和最后一行外，每行都指示需要在预测的后备需求中被覆盖的一个开放时间行程。如图所示，预测该模式将覆盖12个行程。对于模式中的每个值班日，被存储在名为“利用率”的行中的总覆盖从不大于1。最后一列指示使用模式覆盖该行程的可能性。如果覆盖的数量为1，则该矩阵中没有其他行程与之重叠，诸如行程(16,1)、行程(17,1)和行程(20,2)。如果覆盖小于1，则允许存在重叠，且总数应小于等于1。行程(3,5)和行程(3,2)有重叠，这指示使用该模式覆盖行程(3,5)的可能性为15.28％，且使用该模式覆盖行程(3,2)的可能性为84.72％。如果两个行程都需要后备覆盖，则模式1只能用于覆盖其中一个行程，但是存在其他模式可以覆盖它们，如图6的图表602和图6的图表604所示。每个行程的总覆盖基于其预测需求。当发生一个开放时间行程时，应当比较能够覆盖该行程的所有可用模式并选择。

图7的图表700示出了由处理200(上文讨论的)生成的覆盖解决方案，包括后备分配处理之后的20个模式(例如，在第1-20行中所示的模式行1-20)。开放时间行程来自该投标月的真实历史数据。分配处理遵循每天分配一个行程的时间线。在某些示例中，当分配行程时可以考虑以下准则：

1)当比较同一天开始的所有开放时间行程时，首先分配长行程；

2)首先分配更多未使用日的一个；

3)如果模式具有较高可能被用于覆盖未来几天的长行程，则不将超过一天的行程分配给该模式。

除最后一行外，每一行示出一个后备模式(也被称为“模式行”)。除最后两列外，其他列指示四周的投标月中的日。带有“1”的图表单元格指示值班日，且不带任何内容的图表单元格指示休班日。深色阴影单元格指示未使用的后备日，且浅色阴影单元格指示分配给定期调度行程的后备日。粗体框示出分配的行程的长度。行704中的数字指示投标月的每天的总可用模式，且列706中的数字指示模式的总未使用日。如图所示，列706中的最小数字为0，且最大数字为5。因此，每个模式的利用率在67％到100％的范围内。总未使用后备日为57，这使得后备模式的平均利用率为81％。

293后备需求中的50天被决定不被后备模式覆盖，因此最终覆盖率为82.935％。未覆盖模式有两个原因；一个是可能性很高，但太短以致无法使用15天模式来覆盖。另一个是发生可能性低。

图7的图表702示出模型的解的模式6的预测覆盖和分配行程之后的结果。图表700的虚线框中的模式6与之匹配。如图所示，模式6的使用几乎是完美的。只有预测会发生的行程(10,2)未分配给它。实际上，日常操作中需要覆盖开放时间行程(10,2)。没有分配给模式6的原因是，在比较所有可用模式时，还存在其他模式包括在先更多未使用日。为了平衡空置率，决定将此行程分配给模式3。

对于案例研究，优化模型在运行i5-4300U CPU的HP EliteBook 820服务器上运行。Gurobi6.0.4用于在Pyhthon中解决此测试实例。线性(松弛约束)问题在227分钟内被解决，生成512个后备模式。最优成本为2039.15。整数问题在1312秒内提供了很好的解决方案，成本为2301.93。针对不同的fleet和投标期进行了更多的案例研究。结果如表4所示。

表1.案例研究的解决方案

在一些实现中，处理200可以执行细化的主问题和子问题。例如，细化主问题和细化子问题(定义见下文)考虑了附加后备模式参数。细化的主问题和细化的子问题允许跨两个值勤月扩展的行程(例如，在一个值勤月结束时开始但在下一个值勤月开始前未完成的班机运输行程)的后备覆盖。

细化的主问题：

服从于

xj∈{0，1}；ud≥0 (2.5)

主问题(2.1-2.5)是集合覆盖问题，并且它总是可行的，因为存在ud。约束集(2.2)和(2.5)与上述约束集(1.2)和(2.5)相同。约束集(2.2)描述覆盖的子集如何覆盖后备需求。约束集(2.3)定义最大数量的后备模式行(U)(例如，图7中的后备模式行1-20)。例如，如果填充分析(stuffing analysis)预测下个投标月只有25名后备人员可用，则约束(2.3)将后备模式的总数限制为25个后备线(例如，每个可用后备人员一个线)。

约束集(2.4)允许附加的“特殊”后备模式参数。具体而言，约束集(2.4)是用于确认“特殊”后备值勤模式的总数限于总值勤模式的特定百分比的检查。特殊后备值勤模式可以包括但不限于：唯一值班天数小于标准最低值班天数或大于标准最高值班天数的模式；或避免周末值班日的模式。例如，航空公司可能允许每个值勤月有有限数量的短期值勤时间(例如，值勤模式包含少于标准最低值班天数)。在约束集(2.4)中，δj是二进制值，指示后备模式j是否为“特殊”后备值勤模式；如果模式j是“特殊”模式(例如，具有少于标准最低值班天数)，则被设置为1，否则为0。β表示航空公司对每个投标期的“特殊”值勤模式的数量的期望限制；例如，β表示总后备值勤模式的最大百分比(例如，介于0和50％之间)。

与主问题(1.1-1.3)类似，为了使问题易于处理，列(与xj相关联的)遵循列生成过程以迭代方式创建。当其线性松弛(例如，xj∈[0,1])被求解其最优性时，可以确定约束d的影子值(如影子价格)(开放时间行程需求，由wd表示)。

对于每个可能的后备模式，处理200使用子问题(定义如下)来计算模式的潜在改进值(vm w|D| 1 (δi-0.1)w|D| 2-c)，其中，w|D| 1表示与约束(2.3)相关联的影子值，且(δi-0.1)w|D| 2表示与约束(2.4)相关联的影子值。改进值表示给定模式将向由主集合覆盖问题控制的总体优化模型提供的潜在成本改进。为了缩短求解时间，在子问题中生成所有可能的后备值勤模式的集合，I。变量用于定位投标期内的所有值班日。如果t日在此模式中是第f值班日，则是1，否则为0。

细化子问题：

服从于

细化子问题的停止条件也被修改。在求解子问题之后，如果vm w|D| 1 (δi-0.1)w|D| 2>c，则系统将列qd添加到覆盖率矩阵J，在目标函数中具有成本系数系统将为新列分配否则，系统停止子问题，并在全整数约束(例如，xj∈{0,1})下求解主问题(2.1-2.5)。

与前面描述的子问题一样，在细化子问题中，最大vm被选择以在主问题中创建新列，其系数向量为qd。m表示集合M的元素，包括所有合法值班块类型(例如，满足每个值勤块的最小值班天数(MB)的所有值班块类型)。在细化子问题约束集(2.6)中，vm的计算已从上面的约束集(1.4)修改，并且约束集(2.10)和(2.12)已被添加到细化子问题。细化子问题中的其余约束集不变。

vm的计算，约束条件(2.6)，已被修改为考虑结转(carry-over)后备模式。结转后备模式是重叠两个投标月的后备模式。例如，结转后备模式在第一个投标月结束时开始并且在后一个投标月开始中结束。从vm的计算中扣除在(2.6)中对于扩展至后一个投标月的值勤模式日的附加成本项其中，T为当前投标月的总天数，且T’为后一个投标月的总天数。

约束集(2.10)通过比较每个值班模式Oi中的值班日来检查结转行程，以确定该模式是否包括从一个投标月(T)扩展到下一个投标月(T’)的任何值班期。值班日用1表示，且休班日用0表示。如果执勤模式Oi结转到下一个投标月，则不平等性将为真。

约束集(2.12)用于检查周末值勤的“特殊”后备模式。表示投标月中的周末日的集合。如果值勤模式不包括任何“特殊”后备模式，则被设置为(空集)。约束集(2.12)通过将不允许的值勤模式Oi设置为零，来防止“特殊”后备模式包括周末值勤日。

本说明书中描述的主题和操作的实施例可以在数字电子电路中或在计算机软件、固件或硬件中实现，包括本说明书中公开的结构及其等同结构，或以其一种或多种的组合来实现。本说明书中描述的主题的实施例可以被实现为一种或多种计算机程序，即，计算机程序指令的一个或多个模块，其被编码在计算机存储介质上以由数据处理装置执行或控制数据处理装置的操作。可选地或附加地，程序指令可以被编码在人工产生的传播信号上，例如机器产生的电，光或电磁信号，其被产生以对信息进行编码用于传输到合适的接收器装置由数据处理装置执行。计算机存储介质可以是或包括在计算机可读存储设备、计算机可读存储基板、随机或串行访问存储器阵列或设备或它们中的一个或多个的组合中。此外，虽然计算机存储介质不是传播信号，但是计算机存储介质可以是以人工生成的传播信号编码的计算机程序指令的源或目的地。计算机存储介质还可以是一个或多个单独的物理组件或介质(例如，多个CD、磁盘或其他存储设备)或包括在其中。

本说明书中描述的操作可以被实现为由数据处理设备对存储在一个或多个计算机可读存储设备上或从其他源接收的数据执行的操作。

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

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

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

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

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

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

计算系统可以包括客户端和服务器。客户端和服务器通常彼此远离，并且通常通过通信网络进行交互。客户端和服务器之间的关系通过在相应计算机上运行并彼此具有客户端-服务器关系的计算机程序产生。在一些实施例中，服务器例如为了向与作为客户端的设备交互的用户显示数据并从中接收用户输入的目的，向用户设备发送例如HTML页面的数据。可以在服务器上从设备接收在用户设备处生成的数据，例如，用户交互的结果。

尽管本说明书包含许多特定实现细节，但是这些细节不应被解释为对任何发明或所要求保护的范围的限制，而应解释为对特定发明的特定实施例而言特定的特征的描述。在单独的实施例的上下文中在本说明书中描述的特定特征也可以在单个实施例中组合实现。相反，在单个实施例的上下文中描述的各种特征也可以分别在多个实施例中或以任何合适的子组合来实现。此外，尽管上面可以将特征描述为以特定组合起作用并且甚至最初如此宣称，但是在一些情况下，可以从组合中删除所要求保护的组合中的一个或多个特征，并且可以将所要求保护的组合用于子组合或子组合的变型。

类似地，尽管在附图中以特定顺序描绘了操作，但是这不应理解为要求以所示的特定顺序或以连续的顺序执行这样的操作，或者执行所有示出的操作以实现期望的结果。在特定情况下，多任务和并行处理可能是有利的。此外，上述实施例中的各种系统模块和组件的分离不应被理解为在所有实施例中都需要这种分离，并且应当理解，所描述的程序组件和系统通常可以一起集成在单个软件产品或打包成多个软件产品。

因此，已经描述了主题的特定实现。其他实现在所附权利要求的范围内。在某些情况下，权利要求中记载的动作可以以不同的顺序执行，并且仍然实现期望的结果。此外，附图中描绘的处理不一定需要所示的特定顺序或连续顺序来实现期望的结果。在某些实现中，多任务和并行处理可能是有利的。