System and method for aviation backup dispatch

Abstract

A method, system, and apparatus, including a computer program encoded on a computer storage medium, for obtaining input data including prediction data and backup duty pattern parameters. The operations include iteratively generating additional coverage columns for a backup demand coverage ratio (RDCR) matrix until a stopping criterion is met, wherein each iteration includes: selecting a set of coverage columns for the iteration by solving a set covering problem based on the set of coverage columns in the RDCR matrix and using a linear problem constraint to determine a shadow value of a marginal value indicating an incremental change in backup demand coverage for an air trip; generating a new backup duty pattern, the new backup duty pattern including an improvement value; and determining whether the improvement value of the new backup duty pattern meets the stopping criterion. When the improvement value of the new backup duty pattern does not meet the stopping criterion, the operations include: generating a new coverage column based on the new backup duty pattern; and appending the new coverage column to the RDCR matrix as an additional coverage column. If the improvement value of the new backup duty pattern does meet the stopping criterion, the operations include: stopping the iterative generation of the additional coverage columns and generating a final set of backup duty patterns based on the RDCR matrix.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of the filing date of U.S. Provisional Application No. 62 / 848,374, filed on May 15, 2019. The entire contents of U.S. Application No. 62 / 848,374 are incorporated herein by reference. Background Art

[0003] The present disclosure generally relates to set cover optimization. Set cover problems can be used to model problems in different disciplines and industries such as computer science, operations research, and logistics. There is a need for processes that improve the computational efficiency and accuracy of such modeling. Summary of the invention

[0004] The present specification relates to performing set cover optimization for complex logistics scheduling operations. This article describes the implementation with reference to the example context of airline reserve crew mode optimization. In general, the innovative aspects of the subject matter described in this specification can be embodied in a method including an operation of obtaining input data including forecast data and reserve duty mode parameters. The operation includes iteratively generating additional coverage columns of a reserve demand coverage ratio (RDCR) matrix until a stopping criterion is met, wherein each iteration includes: by solving a set cover problem based on a set of coverage columns within the RDCR matrix and using a linear problem constraint, determining a shadow value of a marginal value indicating an incremental change in reserve demand coverage for an air trip, selecting a set of coverage columns for iteration; generating a new reserve duty mode, the new reserve duty mode including an improved value; and determining whether the improved value of the new reserve duty mode meets the stopping criterion. When the improved value of the new reserve duty mode does not meet the stopping criterion, the operation includes: generating a new coverage column based on the new reserve duty mode, and appending the new coverage column to the RDCR matrix as an additional coverage column. If the improved value of the new backup duty pattern does meet the stopping criteria, the operation includes stopping the iterative generation of the additional coverage columns and generating a final set of backup duty patterns based on the RDCR matrix. Other implementations of this aspect include corresponding systems, apparatuses, and computer programs configured to perform the actions of the method encoded on a computer storage device.

[0005] In some implementations, generating a new backup duty mode includes: based on input data, determining multiple possible backup duty modes to cover multiple air trips; determining an improvement value for each possible backup duty mode, wherein each improvement value is determined based on a shadow value and a test coverage associated with each possible backup duty mode; and selecting a specific backup duty mode from the possible backup duty modes based on the specific backup duty mode having a corresponding improvement value that is the highest among all improvement values ​​of the possible backup duty modes.

[0006] In another general aspect, the innovative aspects of the subject matter described in this specification can be embodied in a method comprising an operation of obtaining input data including prediction data and backup duty mode parameters. The operation comprises iteratively generating additional coverage columns of a backup demand coverage ratio (RDCR) matrix until a stopping criterion is satisfied, each iteration comprising: for a set of coverage columns within the RDCR matrix, determining a shadow value, the shadow value indicating a marginal value of an incremental change in backup demand coverage for an air trip, selecting a set of coverage columns for the iteration; based on the input data, determining a plurality of possible backup duty modes to cover a plurality of air trips; determining an improvement value for each possible backup duty mode, wherein each improvement value is determined based on the shadow value and a trial coverage ratio associated with each possible backup duty mode; identifying a specific backup duty mode from the possible backup duty modes whose corresponding improvement value is the highest among all improvement values ​​of the possible backup duty modes; and determining whether the corresponding improvement value satisfies the stopping criterion. When the improvement value of the specific backup duty mode does not meet the stopping criteria, the operation includes: generating a new coverage column from the test coverage associated with the specific backup duty mode; and appending the new coverage column to the RDCR matrix as an additional coverage column. When the improvement value of the specific backup duty mode does meet the stopping criteria, the operation includes: stopping the iteration to generate the additional coverage column; and generating a final set of backup duty modes based on the RDCR matrix.

[0007] These and other implementations may optionally include one or more of the following features.

[0008] In some implementations, additional coverage columns of the RDCR matrix are generated using linear problem constraints.

[0009] In some implementations, integer problem constraints are used to generate the final set of backup duty patterns.

[0010] In some implementations, additional coverage columns of the RDCR matrix are generated using linear problem constraints, and wherein the final set of backup duty patterns is generated using integer problem constraints.

[0011] In some implementations, the forecast data associates a plurality of air itineraries with an expected reserve requirement value indicating a probability that each air itinerary will require reserve personnel coverage. In some implementations, the forecast data includes at least some of the expected reserve requirement values ​​associated with multi-day air itineraries. In some implementations, the forecast data includes unrounded expected reserve requirement values.

[0012] In some implementations, the backup duty mode parameters include the backup mode length and the minimum percentage of days for each backup block.

[0013] In some implementations, determining the shadow value includes solving a set covering problem based on a set of coverage columns within the RDCR matrix and using a linear problem constraint. In some implementations, generating a final set of backup duty patterns includes solving a set covering problem based on a final set of columns of the RDCR matrix and using an integer problem constraint.

[0014] In some implementations, operations include generating a revised set of reserve duty patterns by solving a set covering problem based on an RDCR matrix and hybrid forecast data, wherein the hybrid forecast data associates a first plurality of air trips with actual reserve demand data and associates a second plurality of air trips with expected reserve demand values ​​indicating a probability that each air trip will require coverage by reserve personnel.

[0015] In some implementations, the backup duty mode parameters include a limited number of special backup duty modes.

[0016] Details of one or more implementations of the subject matter described in this specification are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the subject matter will become apparent from the specification, drawings, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 An example system for performing implementations of the present disclosure is depicted.

[0018] Figure 2 Depicted is a flow diagram of an example reserve personnel optimization process that may be performed in accordance with implementations of the present disclosure.

[0019] Figure 3A An example of a simplified covering matrix is ​​depicted.

[0020] Figure 3B Describes from Figure 3A An example of a simplified set of backup duty patterns generated by the simplified coverage matrix.

[0021] Figure 4 Depicted is a sample trip schedule for a bidding month from a case study using real-world data.

[0022] Figure 5 Describes the Figure 4 An example matrix of expected backup demand data for a trip scheduling forecast.

[0023] Figure 6 Depicted are diagrams representing aspects of an overlay solution generated by an implementation of the present disclosure from a case study using real-world data.

[0024] Figure 7Depicted is a diagram representing a full coverage solution generated by an implementation of the present disclosure from a case study using real-world data.

[0025] Like reference symbols in the various drawings indicate like elements. DETAILED DESCRIPTION

[0026] This specification relates to performing set cover optimization on complex logistics scheduling operations. This article describes the implementation with reference to the example context of aviation reserve personnel mode optimization. However, the implementation may be applicable to optimization modeling of other complex logistics scheduling, such as warehouse operations, truck operations, package delivery, etc.

[0027] Specific implementations of the subject matter described in this specification can be implemented to achieve one or more of the following advantages. The implementation can provide a more complete and accurate set coverage solution for stochastic problems. For example, unlike the traditional method of generating a pattern to cover backup demand one-to-one, the pattern designed by the model covers the backup demand in a probabilistic manner with a many-to-many pattern. Each selected pattern is generated not only to cover a set of trips without overlap, but also to cover some possible trip sets with overlap between trips. In this way, even if the predicted backup demand for such a trip does not occur, the pattern can still be used to cover other backup demands. Compared with existing deterministic optimization techniques, the implementation can provide better fault tolerance. For example, the many-to-many coverage pattern can provide the model with high fault tolerance, which can reduce the negative impact of uncertainty when solving set coverage problems (such as aviation backup personnel scheduling). The implementation improves the accuracy of estimating backup demand scheduling. For example, the implementation adopts backup demand forecast data built on a trip-by-trip basis rather than on a daily basis; meaning that each backup demand estimate represents the expectation that the backup personnel will need to cover the entire trip, which may span multiple consecutive days. Additionally, backup demand data is not rounded, for example, to provide additional precision for scheduling.

[0028] Figure 1 An example system 100 for performing implementations of the present disclosure is depicted. System 100 includes an optimization system 102, a flight crew management system 104, a prediction system 106, and one or more user computing devices 108. Optimization system 102 communicates with flight crew management system 104, prediction system 106, and one or more user computing devices 108 via a network 110. Network 110 may include a larger network or combination of networks, such as a local area network (LAN), a wide area network (WAN), the Internet, a cellular network, a satellite network, one or more wireless access points, or any suitable combination thereof connecting any number of mobile clients, fixed clients, and servers.

[0029] Each of the optimization system 102, the flight personnel management system 104, and the prediction system 106 can be implemented using one or more computing systems (e.g., servers). The computing system can have internal or external storage components and can represent various forms of server systems, including but not limited to web servers, application servers, proxy servers, network servers, user account servers, or server farms. Although shown as separate computing systems, in some implementations, one or more of the systems 102, 104, and 106 can be integrated into a single system. For example, the operations of the optimization system 102, the flight personnel management system 104, and the prediction system 106 can all be performed by the same computing system (such as a common server system).

[0030] The user computing device 108 may include, but is not limited to, a laptop or desktop computer, a mobile phone, a smartphone, or a tablet computer.

[0031] As discussed herein, the optimization system 102 executes the set coverage optimization model described in the context of generating a set coverage pattern of reserve personnel for an airline. For example, in operation, the optimization system 102 can receive input data from the flight personnel management system 104 and the prediction system 106. The input data can include, but is not limited to, backup pattern parameters 112 and expected backup demand data 114. The optimization system 102 executes the set coverage optimization model described herein based on the input data to generate a set of reserve personnel duty patterns. A backup duty schedule 116 can be created based on the reserve personnel duty pattern and provided to the user computing device 108.

[0032] For example, the forecasting system 106 may execute a forecasting tool (e.g., a forecasting tool in the SAS Enterprise Guide) to estimate backup demand data associated with air itineraries scheduled over a particular time period (e.g., a bid month). Demand is the expected number of open time itineraries and is not necessarily an integer value. Implementations of the present invention do not round fractional backup demand numbers. For example, retaining unrounded backup demand estimates will retain valuable statistical information for use by the scheduling system described below. In addition, implementations employ backup need data that is organized on a per-trip basis rather than on a daily basis. That is, each value of expected backup demand is associated with regularly scheduled itineraries spanning consecutive days rather than with, for example, a single daily itinerary.

[0033] The backup demand data can be represented by a matrix D, with d as the index (e.g. Figure 5 ), including all types of trips from the forecasting tool. The backup demand data is an input to the optimization model. The columns of the matrix indicate the length l of the trip type, and the rows of the matrix indicate the start date t of the trip. The total number of days in the bidding month is T, and the elements n of the matrix dis the expected backlog demand for trip type (t, l) ∈ D. In some cases, multiple instances of the same type of trip are scheduled in a bidding month, and n d It can represent the combined expected backup demand (t, l) for all trips of the same type. d Can be a fraction and can be less than 1 or greater than 1.

[0034] For example, Figure 5 As shown, the trip (1, 3) (reference numeral 502) indicates that the trip is 3 days and starts from the first day of the bidding month. d is 0.313422774, indicating that there is about a 31% probability that a backup person will be needed to cover trip (1, 3). As another example, trip (16, 2) (reference numeral 504) indicates that the trip is 2 days and starts on the 16th day of the bidding month. d is 2.92138634, indicating that there is about a 292% probability that a backup crew will be needed to cover one of the trips (16, 2). In other words, in a given bidding month, there are multiple trips of type (16, 2). For example, there may be six trips of type (16, 2), each with about a 50% probability of needing coverage by a backup crew. Therefore, the combined expected backup demand for trip type (16, 2) in a given bidding month is about 292%. In short, of the six trips of type (16, 2), three of the six will need to be covered by a backup crew.

[0035] To facilitate checking whether a fallback mode i can cover the trip, the binary parameter is set to to indicate the number of on-duty days for trip d. If trip d includes day t as an on-duty day, then is 1, otherwise 0. The itinerary can be converted into a binary mode. Taking the itinerary (17, 9) of the bidding month of 28 days (T=28) as an example, the itinerary can be represented by the following vector: (0 00 0 0000000 0 0 0011111111100)

[0037] The goal is to build a collection of reserve patterns that meet these expected demand levels at the lowest possible cost. Unlike regular line dispatch trips, reserve patterns do not include any trips or pairs. Instead, they include blocks of consecutive on-duty days and blocks of consecutive off-duty days. The index P of the pattern indicates the maximum total number of on-duty days in one bidding period. Due to the special pay structure of reserve personnel, they will be paid at least the Reserve Line Guarantee (RLG) no matter how many days they operate, so it is expected that as many reserve days as possible will be included in the reserve pattern. Therefore, the pattern includes the maximum number of on-duty days. In other words, P indicates the length of the pattern unless the cost structure changes.

[0038] Traditionally, pattern types are defined to narrow the variable set. That is, in current systems, pattern types are usually defined by on-duty day groups and off-duty day groups. By determining the required number of each type of pattern, the variable set can be reduced and the solution speed can be increased, thereby improving the efficiency of the optimization system 102. However, the predetermined pattern type becomes a parameter of the model. At the same time, since it is difficult to list all types of patterns, there is also a limitation in the solution space. However, in the implementation of the present disclosure, the pattern is defined by more elements, which means that all legal pattern types can be included. For example, a pattern type is determined by a duty block type and an off-duty block type. The duty block type is described by a vector variable, in which the number of elements is determined by how many duty blocks there are in the pattern, and the value of the element is determined by the number of consecutive on-duty days in each block. The off-duty block is also a vector variable, in which the number of elements is determined by how many off-duty blocks there are in the pattern. In some implementations, the off-duty block vector variable is always equal to the number of elements in the duty block type plus one, because the duty block is located between two off-duty blocks. The value of the element in the off-duty block type is determined by the number of consecutive off-duty days in each block. The total value of the elements in the on-duty block type plus the total value of the elements in the off-duty block type equals the total number of days in the bidding period. By adjusting the value of the elements in the off-duty block, it is possible to design on-duty day block types with different numbers of elements.

[0039] Airlines can use different backup mode parameters 112 (e.g., rules) to construct legal backup modes. The backup mode parameters 112 typically include, but are not limited to, the length of the pattern P and the minimum duty day within a block MB. Let K represent the maximum number of duty blocks. Therefore, the number of off-duty blocks is K+1, which is indexed by k. Any block can be zero days, but not all off-duty blocks are allowed to be zero at the same time. K can be calculated by the user dividing by M and rounding it to an integer. For example, assuming that an airline allows a maximum length of 15 days for a pattern and a minimum duty day in a block of 4 days, K can be simply calculated by rounding down 15 / 4, which is equal to 3 after rounding. The element value y of the off-duty block type kis an integer including 0. The off-duty block type can be indicated as [y1, y2, ..., y K+1 ]. If y1 is 0, it means that the fallback mode starts on the first Monday of every month. K+1 is 0, the fallback mode ends on the last Sunday of the month. k --where k is neither equal to 0 nor equal to K+1 --is equal to 0, which means that the number of duty blocks is K-1. k — k is neither equal to 0 nor equal to K+1 — both equal to 0, then this means that the number of duty blocks is K-2 and the fourth to only one duty block exists in a pattern with P duty days. By this analogy, all duty block types with different numbers of elements from 1 to K can be identified. Let a k The element value representing the type of the on-duty block.

[0040] For each mode i, let the binary variable Indicates which day is a duty day and which day is a non-duty day in the mode. Mode i has a total of P duty days in a bidding period of T days. If day t is a duty day in mode i, then is 1, if day t is a day off, then is 0. An example duty mode vector, O i , as shown below: (0 0 1 1 1 1 0 0 0 1 1 1 1 0 0 0 0 0 1 1 1 1 1 1 0 0)

[0042] This example pattern includes three on-duty blocks and four off-duty blocks. The on-duty block type is [4, 4, 7] and the off-duty block type is [2, 3, 5, 2]. The pattern type is [4, 4, 7]_[2, 3, 5, 2].

[0043] The quality of the backup pattern is one aspect of controlling costs, because the uncovered cost rate of a trip is much higher than the backup cost rate. In general, longer backup blocks have higher availability when covering various open-time trips, but there are limitations. In existing scheduling models, no matter whether the probability of an open-time trip is large or small, when it is applied to the model as an input or parameter, it is always regarded as a demand with 100% probability, because the smallest non-zero integer is 1. The example shown in Table 1 (below) is used to illustrate this limitation.

[0044] Table 1. Example of trip coverage by mode

[0045]

[0046]

[0047] Trip 1 and Trip 2 are two open-time trips that need to be covered during the bidding period, and the first 8 days are shown in Table 1. Trip 1 is (2,3) and Trip 2 is (3,3). There are three different fallback blocks that can be used to build the fallback pattern. Block 1 can only cover Trip 1, and Block 2 can only cover Trip 2. Block 3 can cover both trips. However, the decision to use building block 3 may not be optimal. First, some assumptions need to be made.

[0048] Assumption 1: The three blocks have the same cost, although they support different duty days;

[0049] Assumption 2: Since trip 1 and trip 2 have the same length, their uncovered costs are the same;

[0050] Assumption 3: Trip 1 and Trip 2 have equal probability of exiting and becoming open-time trips.

[0051] Based on these three assumptions, we can say that if only one block can be chosen, block 3 is always the best choice. If trip 1 and trip 2 occur more than once and two blocks can be used, using block 3 to build both patterns may be a good decision.

[0052] However, in real-world practice, these assumptions may not always be met. For example, a pattern may include 12 days or more and additional duty blocks not shown in Table 1 may be used to cover additional trips starting after day 8. For example, assuming a 9-day trip starting on day 9 needs to be covered, if Block 1 or Block 2 is used, although a 3-day trip may not be covered, there are 9 duty days that can be built to cover this long trip. In contrast, Block 3 has the opportunity to cover Trip 1 and Trip 2, but if this block is selected, the remaining duty days are not enough to cover the 12-day trip, and it is not possible to cover both Trip 1 and Trip 2 in the same bidding period for daily operations. In this case, although the cost of the backup duty pattern is the same, the cost of the duty block is related to the block length.

[0053] An example with more complex conditions is shown in Table 2 (below). Trip 1 (2,3) and Trip 3 (4,5) are two possible open time trips. Blocks 1, 4, and 5 can be constructed to cover these two trips. Block 1 can only cover Trip 1, Block 4 can only cover Trip 3, and Block 5 can cover both trips.

[0054] Table 2. Another example of trip coverage by mode

[0055]

[0056]

[0057] Table 3. Example scenarios of likelihood of occurrence

[0058]

[0059] The length of the block varies with the length of the trip. In case 1, in the first column of Table 3, the probability of trip 1 occurring at the opening time is 90%, and the probability of trip 3 occurring is 20%. Is block 5 still the best choice? In other words, is it worth adding 4 days to the block to cover trip 3? Block 5 may be a better choice than block 4, and it is clearly a better choice than block 1. In case 2, in the second column, the probability of trip 1 occurring at the opening time is 40%, and the probability of trip 3 occurring is 80%. Is it worth adding 2 days to block 5 to cover trip 1? At least, in this case, the confidence of selecting block 5 is higher than in case 1, because 0.4×3 is greater than 0.2×5. In other words, the possible uncovered cost should be considered. In case 3, in the third column, the probability of both scenarios occurring is 50%. Selecting block 5 seems to be more reasonable than selecting block 1 or block 4. In case 4, in the fourth column, the probability of trip 1 occurring at the opening time is 80%, and the probability of trip 3 occurring is 70%. If the capacity of the backup staff allows, both block 1 and block 4 can be selected to cover trip 1 and trip 3. In case 5, in the last column, open time trip 1 has a 67% chance of occurring and trip 3 has a 58% chance of occurring. In this case, it is difficult to decide how to select the block without any mathematical model to support it. Real-time situations can be much more complex than the ones in this example because they require comparison of complete patterns, not just blocks. The scale of open time trips and patterns is much larger than the examples in Tables 1-3. The optimization model discussed below addresses these and other technical issues.

[0060] Figure 2 A flow chart of an example reserve personnel optimization process 200 that can be performed according to implementations of the present disclosure is depicted. In some implementations, the process 200 can be provided as one or more computer executable programs executed using one or more computing devices. In some examples, the process 200 is performed by a computer such as Figure 1 The optimization system 102 of the embodiment of the present invention is executed by the system of the optimization system 102. In some implementations, all or part of the process 200 can be performed on a local computing device, a desktop computer, a laptop computer, or a tablet computer. In some implementations, all or part of the process 200 can be performed on a remote computing device, a server system, or a cloud-based server system.

[0061] Process 200 represents an optimization model for solving the backup scheduling problem discussed above. Process 200 can reduce the total backup cost, which includes two main costs: one is the backup personnel cost, and the other is the cost of uncovered trips. Let c represent the cost of a mode, and s dis the unit cost of uncovered demand for trip d, which is related to the trip length. The cost of uncovered trip d(l,t) is s d ×l. This method integrates the backup forecasting phase into the optimization phase by maintaining the expected demand level. If the expected demand level is less than 1, it can be considered as a possibility or probability of occurrence. This information can improve the quality of the backup mode, such as in the daily operation phase, by increasing the availability when covering the open time trip.

[0062] To begin processing 200, the system obtains optimization model input data. For example, the system can receive expected backup demand data 114 from the forecasting system 106. As described above, the expected backup demand data can include, but is not limited to, forecasting data that associates multiple air trips with expected backup demand values, and is an expected backup demand value. For example, the expected backup demand data 114 can be an expected backup demand matrix that associates multiple air trips with expected backup demand values ​​that indicate the probability that each air trip will require backup personnel coverage. Similarly, the system can receive backup mode parameters 112 from the flight personnel management system 104. As described above, the backup mode parameters 112 can include, but are not limited to, a backup mode length (P) and a minimum number of duty days (MB) for each duty block.

[0063] The system generates a backup demand coverage matrix 202. For example, the system can introduce the matrix 202 into the optimization model, referred to as a "cover" or coverage 17,9 matrix 202. Figure 3A Simplified examples of coverage matrices 202 are depicted (eg, simplified coverage matrix 300). In general, coverage matrix 202 provides a probability (or rate) at which a given backup mode may be used to cover a corresponding trip.

[0064] For example, let J denote the covering matrix 202, which has the set of all possible covering covers for all open time trips, with j as the index. A covering column j is a vector of |D| elements (e.g., the total number of scheduled trips) in one-to-one correspondence with patterns. Each element of the covering matrix 202 is the probability (or rate) that pattern i (corresponding to column j of the covering matrix 202) can be used to cover the open time trip d, and is represented as The value of is in the range [0, 1]. This many-to-many coverage model can provide a more robust and effective backup coverage pattern. Specifically, the coverage matrix 202 allows many-to-many coverage. Many-to-many coverage means that more than one backup pattern can be used to cover a trip (according to the relevant coverage ratio), and that one backup pattern can provide partial (less than 100%) coverage for more than one trip on a given calendar day. For example, as shown in the simplified coverage matrix 300, the backup pattern based on coverage column 1 will be able to cover 100% of the time that trip 1 needs to be covered by a backup personnel, cover trip 2, 45% of the time that trip 2 needs to be covered by a backup personnel, cover trip 3, 35% of the time that trip 3 needs to be covered by a backup personnel, cover trip 4, 450% of the time that trip 4 needs to be covered by a backup personnel, and will not be able to cover trip 5.

[0065] Process 200 employs a column generation process 204 to construct qualified fallback patterns. Model input data 112, 114 and a coverage matrix 202 are applied as inputs to column generation process 204. Subproblems (described below) are constructed to ensure that all open time trips that can be covered by pattern i are considered in the optimization process. In addition, all patterns that can be used to cover open time trip d are compared in the process. d It is used to indicate the probability of pattern i covering trip d. Each possible pattern i is characterized by a vector with binary values T elements of .

[0066] Binary variable x j is equal to 1 to indicate that the coverage column j is selected, otherwise it is equal to 0. Non-negative variable u d represents the amount of uncovered open time travel demand d. The main problem of the optimization model can be described as follows:

[0067] Main Question :

[0068]

[0069] Submission

[0070]

[0071] x j ∈{0,1};u d ≥0 (1.3)

[0072] The main problem (1.1-1.3) is the set covering problem, which is always feasible because there exists u d The set of constraints (1.2) describes how the covering subsets cover the backup requirements. When the set J includes a sufficient number of all possible covering ranges, the main problem can produce an optimal solution. To make the problem tractable, the columns (with x jassociated) is created iteratively following the column generation process. When its linear relaxation (e.g., x j ∈[0,1]) is solved to its optimality, the shadow value (e.g., shadow price) of constraint d can be determined (in terms of w d express).

[0073] For each possible fallback mode, process 200 uses subproblems (defined below) to calculate the potential improvement value (v m -c), where c represents the cost of the additional fallback mode, and v m represents the reduction in the cost of uncovered trips that the backup mode m can provide. Improvement value (v m -c) represents the potential cost improvement that a given pattern will provide to the overall optimization model governed by the main set coverage problem. To reduce solution time, a set of all possible backup duty patterns is generated in the subproblem, I. The variable Used to locate all duty days in the bidding period. If day t is the fth duty day in this model, then is 1 if yes, 0 otherwise.

[0074] Sub-questions :

[0075]

[0076] Submission

[0077]

[0078]

[0079] Select the maximum v m to create a new column in the main problem with coefficient vector q d . m represents an element of the set M that includes all legal duty block types, for example, all duty block types that satisfy the minimum number of duty days (MB) per duty block. If mode i is selected as a potential cover for trip d, then constraint set (1.5) describes every duty day in trip d that is also a duty day in mode i. Constraint set (1.6) ensures that the coverage of trip d is no larger than its demand. The remaining constraints are all used to construct backup modes. Constraints (1.7) and (1.8) set the length and total off days of the backup mode. Constraint set (1.9) ensures that the fth duty day of the mode is located on only one day. Constraint set (1.10) is used to locate all duty days in the bidding calendar. Constraint set (1.11) has K constraint sets describing each duty block in mode i.

[0080] In brief, the overall algorithm can be described as follows.

[0081] Step 206: Solve the main problem (1.1-1.3), xj ∈[0, 1], we get W d .

[0082] Step 208: For all m (legal duty block types) ∈ I (all backup modes), solve all sub-problems (1.4-1.12) to obtain v m (improvement value for each mode type) to find the m The fallback mode with the maximum value of (identifies the new fallback mode with the highest value).

[0083] Step 210: If the maximum v m If it is not greater than c (the cost of the additional mode), stop and go to 218 .

[0084] Step 212: Insert into J to correspond to the maximum v m Q d (Test coverage of mode m) is the new coverage column of the feature, Go to step 206.

[0085] Step 218: Solve the main problem, x j ∈{0, 1}.

[0086] In more detail, the system determines an improved shadow value for the backup coverage (206). For example, the system may determine a shadow value (w ) for each trip type (d) of the backup demand matrix (D). d ). In some examples, the system can determine the shadow value by solving the above master problem using the relaxed constraints. For example, by using x j ∈[0, 1] instead of using x j ∈{0, 1} to relax x j In other words, by allowing x j The system can solve the master problem as a linear problem (LP) rather than an integer problem (IP) using linear values ​​in the range of 0 and 1. In some implementations, the system can execute the master problem and obtain the shadow values ​​by using an optimization solver (e.g., Gurobi solver, IBM ILOG CPLEX, and radix optimizer).

[0087] The system determines the possible backup duty mode with the greatest potential improvement in coverage (208). For example, the system can identify the possible backup duty mode from all potential (e.g., legal according to the backup duty mode parameters 112) backup duty modes that has the greatest potential improvement in coverage to add to the coverage matrix 202. For example, the system can perform the sub-problems discussed above to determine a plurality of possible backup duty modes. The system can calculate an improvement value (v) for each possible backup duty mode based on the shadow value determined from the main problem (e.g., step 206). mAs described in equation (1.4), the improvement value of each backup mode can be based on the corresponding shadow value of the potential trips covered by the backup mode and the trial coverage rate (q d The system can identify a specific backup duty mode with the highest improvement value from the possible backup duty modes.

[0088] In some implementations, the system uses a tiered approach to determine the possible backup duty mode with the greatest potential coverage improvement. For example, the system can loop through each legal duty block type m of the set M of all legal duty block types, identifying the highest value mode within each block type m.

[0089] For example, assume that the length of the backup mode is 15 days, so the total number of off-duty days is 28-15=13. Each duty block includes at least 4 backup days (e.g., MB=4), so the maximum number of duty blocks K is 3. There are 16 legal duty block types M, listed as follows: [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]; and

[15] . Each of these 16 legal block types can be distributed among the days of a given bidding month in a variety of different patterns.

[0090] The system can determine the pattern of block type m=1 that provides the greatest potential coverage improvement (e.g., block type [4,4,7]) and store that value as v1. For example, the system can calculate the improvement value for each possible pattern of block m=1 (e.g., block type [4,4,7]) using equation (1.4) and identify the pattern that provides the greatest value. The system can store the identified block type m=1 patterns and their associated improvement values ​​(e.g., v1). The system then performs the same process for block type m=2 (e.g., block type [4,7,4]), and so on, until all legal block types in set M have been evaluated.

[0091] The system compares the corresponding improvement value (v m ) to identify the possible backup duty mode with the greatest potential coverage improvement. In some implementations, the system compares all stored improvement values ​​(v m ) to identify the pattern with the largest improvement value. In some implementations, while evaluating each legal block type m, the system continuously compares the improvement value (v m). For example, after the second block type (m=2) is evaluated as an improved value (v2), the system can compare the stored improved value v1 with the value of v2. The system can store the greater of the two values ​​and the associated fallback mode. The system can then repeat the process for each subsequent legal block type; only the one with the higher improved value (v m ) until all legal duty block types in set M have been evaluated. The remaining stored fallback pattern will be the one with the largest improvement value (v m ) mode.

[0092] For example, the highest improvement value (e.g., maxv m ) is compared to a stopping criterion (210) to determine whether the column generation process 204 is complete and can be stopped, or whether additional columns should be generated. For example, the stopping criterion can be the cost of adding additional backup modes to the backup schedule (c). If the improvement value of the identified backup mode is greater than the cost of adding the backup mode to the backup schedule, the column generation process (204) proceeds to step (212). If the improvement value of the identified backup mode is less than the cost of adding the backup mode to the backup mode, the column generation process (204) is complete and the optimization process 200 proceeds to step (218).

[0093] At step (212), the coverage column associated with the backup mode having the highest improvement value is added to the coverage matrix 202. For example, the coverage matrix 202 is updated by adding the new coverage column. The updated version of the coverage matrix (e.g., updated coverage matrix 214) is then used at step 206 to perform a subsequent iteration of the column generation process (204). For example, referring to Figure 3A The improvement value of the fallback modes associated with coverage columns 2, 3, and 4 may already be greater than the cost of adding the associated fallback modes to the schedule. Therefore, during a corresponding iteration of the column generation process (204), each of coverage columns 2, 3, and 4 will be added to the simplified coverage matrix 300. For example, when a coverage column is added to the coverage matrix 202, the new coverage column (e.g., Figure 3A The second column of the simplified coverage matrix 300 in FIG. 20 is generated based on the test coverage of the selected backup pattern. That is, the selected backup pattern is the specific backup pattern identified as having the highest improvement value for the specific iteration of the column generation process ( 204 ).

[0094] In some implementations, the system can add multiple columns to the covering matrix 202. For example, the system can add multiple (e.g., two or more) new columns to the covering matrix 202 during each iteration of the subproblem as long as each of the added columns has an improved value that does not satisfy the stopping rule (e.g., v eachcolumnNo greater than c). In some examples, the system can add the best generated pattern for each legal pattern type as a new column in the coverage matrix 202. The best pattern for each legal pattern type can be evaluated as the pattern with the highest improvement value for each legal pattern type. In some implementations, the system can add a predetermined number of new patterns (e.g., 5, 10, 15, etc.). For example, the system can add the top five patterns as columns to the coverage matrix 202 (e.g., the patterns with the five highest improvement values).

[0095] At step (218), the system generates a final set of backup duty patterns using the final backup demand coverage matrix 216. For example, the final backup demand coverage matrix 216 is a matrix containing all coverage columns (e.g., Figure 3A 2-4 in the simplified matrix 300 of . For example, the system can use the final backup demand coverage matrix 216 to obtain the final backup demand coverage matrix 216 under the full constraints (e.g., x j ∈{0,1}) to perform the master problem to generate the final set of backup duty patterns.

[0096] For example, refer to Figure 3A , executing the master problem to generate the final backup duty pattern (218) may result in selecting cover columns 1, 2, and 4 from the simplified cover matrix 300 as the best backup cover solution. For example, when the master problem is solved as an integer problem under full constraints, such a solution to the master problem will generate x j Vector: [1 1 0 1]. The system may transform selected columns of the final version of the backup demand coverage matrix 216 to generate a final set of backup duty patterns.

[0097] For example, Figure 3B Describes from Figure 3A An example of a simplified set 354 of backup duty modes generated by the simplified coverage matrix 300. Graph 350 illustrates the coverage provided by backup duty modes 1, 2, and 4 for trips 1-5 over 10 calendar days. d), the selected backup duty mode 354 provides complete coverage for trip 352 in the simplified bidding month. For example, on days 1 and 2, each of backup duty modes 1-3 can be used to cover trip 1 if needed. On day 4, backup duty mode 1 can be used to cover trip 2 if needed. On day 5, backup duty mode 1 can be used to cover trips 2 and 3, with coverage ratios of 0.45 and 0.1, respectively. On calendar day 6, backup duty modes 1 and 2 can be used to cover trips 2, 3, and 4. More specifically, on day 6, backup duty mode 1 can be used to cover trips 2 and 3, with a total coverage ratio of 0.55, and can also be used to cover trip 4, with a coverage ratio of 0.45. However, the expected backup coverage for trip 4 is 1.25, so backup duty mode 2 can be used to cover trip 4, with a coverage ratio of 0.8. In other words, backup duty mode 2 will cover trip 4 80% of the time. On days 8-10, the backup duty mode can also be used for trip 5 with a coverage of 0.2, and the backup duty mode 4 can be used for trip 5 with a coverage of 0.95.

[0098] In some examples, the solution of the optimization process 200 includes not only the set of selected backup modes and uncovered trips, but also the set of open time trips covered by each selected mode and all modes that can be used to cover each open time trip. There may be two cases for the coverage of backup demand. One case is that the demand is covered by fewer modes, but has a sufficiently high probability compared to the value of the expected demand. Another case is that the open time trip can be covered by more modes, and the probability of coverage of each mode is relatively low. In this case, although the probability of coverage of a type is low, it can be covered by more modes, which makes it still have a good chance of being covered based on the expected demand level.

[0099] In some implementations, additional or alternative constraints can be added to the model based on different backup mode parameters (e.g., backup scheduling rules) for different airlines. For example, the capacity of the reserve personnel can be added to the main problem, and its formula is as follows. However, since the optimization model can give a set of backup modes to be assigned to the reserve personnel, it is not always necessary to include it. This set is the optimal solution found by the model, and the number of backup modes can be used as a suggestion for the scheduler, and they can adjust other personnel groups to find some personnel who can carry them. There are many ways to improve reserve personnel management. For example, if the management of reserve personnel is not good for a long time, it will affect the ability of reserve personnel in the pre-month planning stage. The optimal solution is limited by capacity.

[0100] Another example of improvement that can be given is the allocation strategy in daily operations. A good allocation strategy that fits the pattern design will favor the pattern coverage as much as possible. In some implementations, the master problem can be repeated using hybrid forecast data. For example, the master problem can be repeated during the bidding month to adjust the backup crew allocation as the bidding month progresses. The forecast data can be updated with actual trip data, as regularly scheduled trips are either executed as planned or are canceled and covered by backup crew. For example, refer to Figure 3B , if Trip 2 is flown as scheduled with the regularly scheduled personnel, the predicted data associated with Trip 2 may be replaced by actual data indicating that the trip was performed as scheduled (e.g., n of Trip 2 d 216 and the hybrid forecast data. In this case, the master problem can be run routinely (e.g., daily, weekly, etc.) using the final backup demand coverage matrix 216 and the hybrid forecast data. In this case, the master problem can be run as a fully constrained (e.g., x j ∈{0,1}), which reduces the computational resources and time required to generate the reallocation.

[0101]

[0102] A multi-stage stochastic optimization process is developed to decide whether any trip can be abandoned. When the daily operation phase begins, the reserve allocation process starts at the same time. For each day of the bidding period, the number of each open time trip type becomes known information. After allocating it to a person's reserve line, the parameter values ​​of the optimization model, such as the reserve demand matrix, can be updated. The set of patterns obtained from the column generation algorithm becomes fixed input data after removing the reserve days of the allocated trips and the reserve days released based on the charter.

[0103] Rerunning the optimization model with these updated parameters, the system can update the coverage to provide allocation suggestions for the next randomization phase. A list of allowed dropping reserve days is given, where the drop-off reserve days with higher coverage impact will be listed at the top. Higher-order patterns should be better protected. When a set of feasible reserve blocks is found and there are sufficiently long duty blocks covering the open time travel, several strategies can be considered in the allocation process:

[0104] 1) Choose the shortest one in this set. A perfect match is best.

[0105] 2) If there is more than one block that satisfies, then the block with more unused reserve days or fewer duty hours is selected.

[0106] 3) If there is more than one block that satisfies, consider whether the long pattern should be saved for long runs as having an associated higher probability.

[0107] Figure 4-Figure 7 represents data from an experimental case study conducted with a major US airline. A 4-week bidding month is randomly selected as the target. The total number of days in the bidding month, T, is 28. The trip lengths range from 1 to 1 3. The scheduled trips for this bidding period are stored in Figure 4 In the matrix shown, the matrix is ​​used as input to the backup prediction system 106. Figure 5 Shows that for Figure 4 The expected backup demand matrix D for the trip shown in the scheduling matrix.

[0108] For example, assume that the backup mode is 15 days long, so that the total number of off-duty days is 28-15=13. Each block of duty days includes at least 4 backup days (e.g., MB=4), so the maximum number of duty blocks K is 3. Legal duty block types M are listed as follows: [4, 4, 7]; [4, 7, 4]; [7, 4, 4]; [4, 5, 6]; [5, 4, 6]; [6, 5, 4]; and [5, 5, 5]. There are 4 off-duty blocks. When one block between two duty blocks is 0, the number of duty blocks is reduced to 2. If both off-duty blocks between the duty blocks are 0, the mode will become a 15-day long mode with only one duty block. By setting off-duty blocks, all eligible duty block types with less than 3 duty blocks are created in the model, such as: [4, 11]; [11, 4]; [7, 8]; [8, 7]; [6, 9]; [9, 6]; [5, 10]; [10, 5] and

[15] .

[0109] The cost of granting a fallback mode to a person is assumed to be 100, and the uncovered cost of daily trips is 15. The constraints used to generate the modes in the subproblems of the model are as follows:

[0110] y1+y2+y3+y4=13(1.14)

[0111]

[0112]

[0113] Figure 6The diagram 600 is one of the patterns in the solution. The columns represent the days of the 4-week bidding month. The first row is a pattern generated by the model, and its pattern type is [5,4,6]_[2,2,2,7]. Elements with 1 indicate duty days, and empty elements indicate off-duty days. Except for the first and last rows, each row indicates an open time trip that needs to be covered in the predicted backup demand. As shown in the figure, the pattern is predicted to cover 12 trips. For each duty day in the pattern, the total coverage stored in the row named "Utilization" is never greater than 1. The last column indicates the probability of covering the trip using the pattern. If the number of coverages is 1, there are no other trips in the matrix that overlap with it, such as trip (16,1), trip (17,1), and trip (20,2). If the coverage is less than 1, overlap is allowed and the total should be less than or equal to 1. There is overlap between trip (3,5) and trip (3,2), which indicates that there is a 15.28% chance that trip (3,5) can be covered using this pattern, and an 84.72% chance that trip (3,2) can be covered using this pattern. If both trips require fallback coverage, then pattern 1 can only be used to cover one of the trips, but there are other patterns that can cover them, such as Figure 6 Chart 602 and Figure 6 The total coverage of each trip is based on its predicted demand. When an open time trip occurs, all available modes that can cover the trip should be compared and selected.

[0114] Figure 7 Graph 700 shows the coverage solution generated by process 200 (discussed above), including 20 patterns (e.g., patterns rows 1-20 shown in rows 1-20) after the backup allocation process. The open time itineraries are from real historical data for the bidding month. The allocation process follows a timeline of allocating one itinerary per day. In some examples, the following criteria may be considered when allocating itineraries:

[0115] 1) When comparing all open-time trips starting on the same day, the long trips are allocated first;

[0116] 2) first allocate the one with more unused days;

[0117] 3) If a mode has a high probability of being used to cover long trips in the next few days, trips longer than one day are not assigned to the mode.

[0118] Each row, except the last, shows a backup mode (also referred to as a "mode row"). Except for the last two columns, the other columns indicate the days in the four-week bidding month. Chart cells with "1" indicate on-duty days, and chart cells with nothing indicate off-duty days. Dark shaded cells indicate unused backup days, and light shaded cells indicate backup days assigned to regularly scheduled trips. The bold boxes show the lengths of the assigned trips. The numbers in row 704 indicate the total available modes for each day of the bidding month, and the numbers in column 706 indicate the total unused days for the modes. As shown, the minimum number in column 706 is 0 and the maximum number is 5. Therefore, the utilization of each mode ranges from 67% to 100%. The total unused backup days are 57, which makes the average utilization of the backup modes 81%.

[0119] 50 days out of the 293 fallback requirements were decided not to be covered by the fallback model, so the final coverage is 82.935%. There are two reasons for not covering the pattern; one is that the probability is high, but too short to be covered using the 15-day model. The other is that the probability of occurrence is low.

[0120] Figure 7 Graph 702 shows the result after the predicted coverage and allocation of trips for mode 6 of the solution of the model. Mode 6 in the dashed box of graph 700 matches it. As shown in the figure, the use of mode 6 is almost perfect. Only the trip (10,2) that is predicted to occur is not assigned to it. In fact, the open time trip (10,2) needs to be covered in daily operation. The reason why it is not assigned to mode 6 is that when comparing all available modes, there are other modes that include more unused days in the past. In order to balance the vacancy rate, it is decided to assign this trip to mode 3.

[0121] For the case studies, the optimization model was run on an HP EliteBook 820 server running an i5-4300U CPU. Gurobi 6.0.4 was used to solve this test instance in Python. The linear (relaxed constraints) problem was solved in 227 minutes, generating 512 fallback patterns. The optimal cost was 2039.15. The integer problem provided a good solution in 1312 seconds with a cost of 2301.93. More case studies were performed for different fleets and bidding periods. The results are shown in Table 4.

[0122] Table 1. Case study solutions

[0123]

[0124] In some implementations, process 200 may perform refined master questions and sub-questions. For example, the refined master questions and refined sub-questions (defined below) take into account additional backup mode parameters. The refined master questions and refined sub-questions allow for backup coverage for trips that extend across two duty months (e.g., a flight transportation trip that begins at the end of one duty month but is not completed before the beginning of the next duty month).

[0125] Refined main problem :

[0126]

[0127] Submission

[0128]

[0129] x j ∈{0,1};u d ≥0 (2.5)

[0130] The main problem (2.1-2.5) is the set covering problem, and it is always feasible because there exists u d Constraints (2.2) and (2.5) are the same as constraints (1.2) and (2.5) above. Constraint (2.2) describes how the covered subset covers the fallback requirements. Constraint (2.3) defines the maximum number of fallback pattern rows (U) (e.g., Figure 7 For example, if the stuffing analysis predicts that only 25 reserve personnel will be available in the next bidding month, constraint (2.3) limits the total number of reserve patterns to 25 reserve lines (e.g., one line for each available reserve person).

[0131] Constraint set (2.4) allows for additional "special" backup mode parameters. Specifically, constraint set (2.4) is a check to confirm that the total number of "special" backup duty modes is limited to a certain percentage of the total duty modes. Special backup duty modes may include, but are not limited to: a pattern with a unique duty number of days less than the standard minimum duty number or greater than the standard maximum duty number; or a pattern that avoids weekend duty days. For example, an airline may allow a limited number of short duty times per duty month (e.g., a duty pattern containing fewer than the standard minimum duty number). In constraint set (2.4), δ j is a binary value indicating whether the backup mode is a "special" backup duty mode; it is set to 1 if the mode is a "special" mode (e.g., has fewer than the standard minimum number of duty days), and 0 otherwise. β represents the airline's desired limit on the number of "special" duty modes per bidding period; for example, β represents a maximum percentage of total backup duty modes (e.g., between 0 and 50%).

[0132] Similar to the main problem (1.1-1.3), in order to make the problem tractable, the columns (with x j associated) is created iteratively following the column generation process. When its linear relaxation (e.g., x j ∈[0,1]) is solved for its optimality, the shadow value (such as shadow price) of constraint d can be determined (open time travel demand, given by w d express).

[0133] For each possible fallback mode, process 200 uses subproblems (defined below) to calculate the potential improvement value (v m +w |D|+1 +(δ i -0.1)w |D|+2 -c), where w |D|+1 represents the shadow value associated with constraint (2.3), and (δ i -0.1)w |D|+2 represents the shadow value associated with constraint (2.4). The improvement value represents the potential cost improvement that a given mode will provide to the overall optimization model governed by the main set covering problem. To reduce solution time, a set of all possible backup duty modes is generated in the subproblem, I. The variable Used to locate all duty days in the bidding period. If day t is the fth duty day in this model, then is 1 if yes, 0 otherwise.

[0134] Refinement of sub-problems :

[0135]

[0136] Submission

[0137]

[0138]

[0139] The stopping condition of the refinement subproblem is also modified. After solving the subproblem, if v m +w |D|+1 +(δ i -0.1)w |D|+2 >c, the system will list q d Added to the coverage matrix J, with the cost coefficient in the objective function The new column will be assigned Otherwise, the system stops the subproblem and runs on the full integer constraint (e.g., x j ∈{0,1}) to solve the main problem (2.1-2.5).

[0140] As in the previous subproblem, in the refinement subproblem, the maximum v m is chosen to create a new column in the main problem, whose coefficient vector is q d m represents an element of the set M, including all legal duty block types (for example, all duty block types that satisfy the minimum number of duty days (MB) for each duty block). In the refined subproblem constraint set (2.6), v m The computation of has been modified from constraint set (1.4) above, and constraint sets (2.10) and (2.12) have been added to the refinement subproblem. The remaining constraint sets in the refinement subproblem remain unchanged.

[0141] v m The calculation of , constraint (2.6), has been modified to take into account the carry-over fallback mode. A carry-over fallback mode is a fallback mode that overlaps two bidding months. For example, the carry-over fallback mode starts at the end of the first bidding month and ends at the beginning of the next bidding month. From v m The additional cost item for duty mode days extending to the next bidding month in (2.6) is deducted from the calculation of Where T is the total number of days in the current bidding month, and T' is the total number of days in the next bidding month.

[0142] The constraint set (2.10) is obtained by comparing each duty mode O i The duty days in the tagged_trigger_schedule are checked to determine whether the pattern includes any duty periods extending from one bidding month (T) to the next bidding month (T'). Duty days are represented by 1 and off-duty days are represented by 0. i Carryover to the next bidding month, then the inequality will be true.

[0143] The constraint set (2.12) is used to check the "special" fallback mode for weekend duty. Represents the set of weekend days in the bidding month. If the duty mode does not include any "special" fallback mode, then is set to (empty set). The constraint set (2.12) is set by i Set to zero to prevent "special" backup mode from including weekend duty days.

[0144] The embodiments of the subject matter and operations described in this specification may be implemented in digital electronic circuits or in computer software, firmware or hardware, including the structures disclosed in this specification and their equivalents, or in one or more combinations thereof. The embodiments of the subject matter described in this specification may be implemented as one or more computer programs, i.e., one or more modules of computer program instructions, which are encoded on a computer storage medium to be executed by a data processing device or to control the operation of a data processing device. Alternatively or additionally, program instructions may be encoded on an artificially generated propagation signal, such as a machine-generated electrical, optical or electromagnetic signal, which is generated to encode information for transmission to a suitable receiver device for execution by a data processing device. The computer storage medium may be or be included in a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination of one or more of them. In addition, although the computer storage medium is not a propagation signal, the computer storage medium may be the source or destination of computer program instructions encoded in an artificially generated propagation signal. The computer storage medium may also be or be included in one or more separate physical components or media (e.g., multiple CDs, disks or other storage devices).

[0145] The operations described in this specification may be implemented as operations performed by a data processing device on data stored on one or more computer-readable storage devices or received from other sources.

[0146] The term "data processing apparatus" encompasses all kinds of apparatus, devices and machines for processing data, including, for example, a programmable processor, a computer, a system on a chip, or a plurality or combination of the foregoing. The apparatus may include dedicated logic circuits, such as an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). In addition to hardware, the apparatus may also include code that creates an execution environment for the computer program in question, for example, code that constitutes processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or a combination of one or more thereof. The apparatus and execution environment may implement a variety of different computing model infrastructures, such as network services, distributed computing, and grid computing architectures.

[0147] A computer program (also referred to as a program, software, software application, script, or code) may be written in any form of programming language, compiled or interpreted, declarative or procedural, and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for a computing environment. A program may, but need not, correspond to a file in a file system. A program may be stored as part of a file that holds other programs or data, such as one or more scripts stored in a markup language document, a single file dedicated to the program in question, or multiple coordinated files (e.g., files storing one or more modules, subroutines, or portions of code). A computer program may be deployed to be executed on one computer or on multiple computers located at one site or distributed across multiple sites and interconnected by a data communications network.

[0148] The processes and logic flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform actions by operating on input data and generating output. The processes and logic flows can also be performed by special purpose logic circuits, or devices can be implemented as special purpose logic circuits, such as an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).

[0149] For example, a processor suitable for executing a computer program can be based on general and special purpose microprocessors, and any one or more processors of any type of digital computer. Typically, the processor will receive instructions and data from a read-only memory or a random access memory or both. The elements of a computer may include a processor for performing operations according to instructions and one or more storage devices for storing instructions and data. Typically, the computer will also include or be operably coupled to receive data from one or more mass storage devices (e.g., magnetic, magneto-optical disks, or optical disks) for storing data or to transfer data to one or more mass storage devices or both. However, the computer does not have to have such devices. In addition, the computer can be embedded in another device, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device, such as a universal serial bus (USB) flash drive, to name a few. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and storage devices, including, for example, semiconductor storage devices, such as EPROM, EEPROM, and flash memory devices; disks, such as internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0150] To provide interaction with a user, embodiments of the subject matter described in this specification may be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user, as well as a keyboard and pointing device (e.g., a mouse or trackball, through which a user can provide input to the computer). Other kinds of devices may also be used to provide interaction with a user, for example, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user may be received in any form, including sound, voice, or tactile input. In addition, a computer may interact with a user by sending documents to and receiving documents from a device used by the user, for example, by sending a web page to a web browser on a user's device in response to a request received from the web browser.

[0151] Implementations of the subject matter described in this specification may be implemented in a computing system that includes a back-end component (e.g., as a data server) or includes a middleware component (e.g., an application server) or includes a front-end component (e.g., a client computer with a graphical user interface or a web browser through which a user can interact with an implementation of the subject matter described in this specification) or includes any combination of one or more such back-end components, middleware components, or front-end components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include local area networks ("LANs") and wide area networks ("WANs"), interconnected networks (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).

[0152] The computing system may include a client and a server. The client and the server are usually remote from each other and usually interact through a communication network. The relationship between the client and the server is generated by computer programs running on the respective computers and having a client-server relationship with each other. In some embodiments, the server sends data such as HTML pages to the user device, for example, for the purpose of displaying data to a user interacting with the device as a client and receiving user input therefrom. Data generated at the user device, such as the result of the user interaction, can be received from the device on the server.

[0153] Although this specification contains many specific implementation details, these details should not be interpreted as limitations on any invention or the scope of the claimed protection, but should be interpreted as descriptions of features specific to a particular embodiment of a particular invention. Specific features described in this specification in the context of a separate embodiment may also be implemented in combination in a single embodiment. On the contrary, the various features described in the context of a single embodiment may also be implemented in multiple embodiments or in any suitable sub-combination, respectively. In addition, although the features may be described above as working in a specific combination and even initially claimed as such, in some cases, one or more features in the claimed combination may be deleted from the combination, and the claimed combination may be used for a sub-combination or a variation of the sub-combination.

[0154] Similarly, although operations are depicted in a particular order in the accompanying drawings, this should not be understood as requiring that such operations be performed in the particular order shown or in a continuous order, or that all of the operations shown be performed to achieve the desired results. In certain circumstances, multitasking and parallel processing may be advantageous. In addition, the separation of various system modules and components in the above-described embodiments should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0155] Thus, particular implementations of the subject matter have been described. Other implementations are within the scope of the appended claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the particular order shown or sequential order to achieve the desired results. In some implementations, multitasking and parallel processing may be advantageous.

Claims

1. An aviation backup dispatch system, comprising: one or more processors; One or more tangible, non-transitory media operably connected to one or more processors and storing instructions that, when executed, perform operations including: obtaining input data including expected reserve demand data and reserve duty mode parameters from a reserve prediction system, wherein the expected reserve demand data includes forecast data associating a plurality of scheduled air trips with expected reserve demand values ​​indicating a probability that each air trip will require a reserve personnel to cover the trip; generating a reserve demand coverage ratio RDCR matrix to provide a probability of using a reserve mode in the mode set to cover the plurality of scheduled air trips, wherein each column of the RDCR matrix is ​​a vector of elements corresponding to a total number of trips in the plurality of scheduled air trips matching a reserve mode in the mode set, Iteratively generate additional coverage columns of the backup requirement coverage ratio RDCR matrix until the stopping criterion is met. Each iteration includes: For a set of coverage columns in the RDCR matrix, determining a shadow value indicating a marginal value of an incremental change in backup demand coverage of the plurality of scheduled air trips, selecting the set of coverage columns for iteration, wherein determining the shadow value comprises solving a set covering problem based on the set of coverage columns in the RDCR matrix and using a linear problem constraint; Based on the input data, determining a plurality of possible backup duty modes to cover a plurality of air itineraries; determining an improvement value for each possible backup duty mode, wherein each improvement value is determined based on the shadow value and a test coverage associated with each possible backup duty mode; identifying a specific backup duty mode from the possible backup duty modes, the specific backup duty mode having a corresponding improvement value that is the highest among all improvement values ​​of the possible backup duty modes; determining whether the corresponding improvement value satisfies a stopping criterion; and If the improvement value for a particular backup duty mode does not meet the stopping criteria: Generate new coverage columns based on the test coverage associated with a specific fallback mode, and Append the new coverage column to the RDCR matrix as an additional coverage column; If the improvement value for a particular backup duty mode satisfies a stopping criterion, then stopping the iteration to generate additional coverage columns; and Based on the RDCR matrix, a final set of backup duty patterns is generated, wherein generating the final set of backup duty patterns includes a final column set based on the RDCR matrix and using an integer problem constraint to solve a set covering problem.

2. The system according to claim 1, wherein: Use the linear problem constraints to generate additional coverage columns for the RDCR matrix.

3. The system according to claim 1, wherein: Use integer problem constraints to generate the final set of backup duty patterns.

4. The system according to claim 1, wherein: Linear problem constraints are used to generate additional coverage columns of the RDCR matrix, and wherein integer problem constraints are used to generate the final set of backup duty patterns.

5. The system according to claim 1, wherein: The forecast data includes at least some expected backup demand values ​​associated with the multi-day air itinerary.

6. The system according to claim 1, wherein: Forecast data include unrounded values ​​for expected backlog demand.

7. The system according to claim 1, wherein: The backup duty mode parameters include the backup mode length and the minimum number of duty days for each backup block.

8. The system according to claim 1, wherein: The operations also include generating a revised set of backup duty patterns by solving a set covering problem based on the RDCR matrix and hybrid forecast data, wherein the hybrid forecast data associates the first plurality of air trips with actual backup demand data and associates the second plurality of air trips with expected backup demand values ​​indicating a probability that each air trip will require a backup personnel to cover the trip.

9. The system according to claim 1, wherein: The backup duty mode parameters include a limited number of special backup duty modes.

10. An aviation backup dispatch method, comprising: obtaining input data including expected reserve demand data and reserve duty mode parameters from a reserve prediction system, wherein the expected reserve demand data includes forecast data associating a plurality of scheduled air trips with expected reserve demand values ​​indicating a probability that each air trip will require a reserve personnel to cover the trip; generating a reserve demand coverage ratio RDCR matrix to provide a probability of using a reserve mode in the mode set to cover the plurality of scheduled air trips, wherein each column of the RDCR matrix is ​​a vector of elements corresponding to a total number of trips in the plurality of scheduled air trips matching a reserve mode in the mode set, Iteratively generate additional coverage columns of the backup requirement coverage ratio RDCR matrix until the stopping criterion is met. Each iteration includes: For a set of coverage columns in the RDCR matrix, determining a shadow value indicating a marginal value of an incremental change in backup demand coverage of the plurality of scheduled air trips, selecting the set of coverage columns for iteration, wherein determining the shadow value comprises solving a set covering problem based on the set of coverage columns in the RDCR matrix and using a linear problem constraint; Based on the input data, determining a plurality of possible backup duty modes to cover a plurality of air itineraries; determining an improvement value for each possible backup duty mode, wherein each improvement value is determined based on the shadow value and a test coverage associated with each possible backup duty mode; identifying a specific backup duty mode from the possible backup duty modes, the specific backup duty mode having a corresponding improvement value that is the highest among all improvement values ​​of the possible backup duty modes; determining whether the corresponding improvement value satisfies a stopping criterion; and If the improvement value for a particular backup duty mode does not meet the stopping criteria: Generate new coverage columns based on the test coverage associated with a specific fallback mode, and Append the new coverage column to the RDCR matrix as an additional coverage column; If the improvement value for a particular backup duty mode satisfies a stopping criterion, then stopping the iteration to generate additional coverage columns; and Based on the RDCR matrix, a final set of backup duty patterns is generated, wherein generating the final set of backup duty patterns includes a final column set based on the RDCR matrix and using an integer problem constraint to solve a set covering problem.

11. The method according to claim 10, wherein: Use the linear problem constraints to generate additional coverage columns for the RDCR matrix.

12. The method according to claim 10, wherein: Use integer problem constraints to generate the final set of backup duty patterns.

13. The method according to claim 10, in, The forecast data includes at least some expected backup demand values ​​associated with the multi-day air itinerary, and The forecast data includes unrounded expected backup demand values.

14. The method according to claim 10, further comprising: A revised set of backup duty patterns is generated by solving a set covering problem based on the RDCR matrix and hybrid forecast data, wherein the hybrid forecast data associates a first plurality of air trips with actual backup demand data and associates a second plurality of air trips with expected backup demand values ​​indicating a probability that each air trip will require a backup personnel to cover the trip.

Images