The case study is introduced here.

The ICAR goal is derived here.

The ICAR problem can be specified as follows:

Find a set of feasible crew pairings and aircraft strings such that:

a. every flight in the LEG schedule is covered exactly once by an aircraft string

b. every flight in the LEG schedule is covered exactly once by a crew pairing

c. any string and pairing is used no more than once (let's denote the non-zero pairings and strings as 'active')

d. the total cost is minimized

e. if an active crew pairing contains a connection

f. Maximally satisfy a reliability measure that is proportional to the tightness and the number of the synchronized connections in T. For the purpose of illustration in this post, we specify that a certain minimum count (

g. The active strings belonging to a sub-fleet should form a Hamiltonian circuit. This is a maintenance requirement that tries to ensure equal wear-and-tear across the fleet. There are other constraints that are also interesting topics in their own right, but we'll ignore them here for brevity.

Our main focus here is on requirement (f). We provide some sample approaches to handling synchronization in large-scale scheduling:

a) Within the subproblem:

Really tight day-connections

b) Within the Master program:

Let

Note that

∑

The bilinear terms in the reliability constraint can be linearized in a straightforward manner. A personal favorite is the reformulation-linearization technique (RLT).

The ICAR goal is derived here.

**Model**The ICAR problem can be specified as follows:

Find a set of feasible crew pairings and aircraft strings such that:

a. every flight in the LEG schedule is covered exactly once by an aircraft string

b. every flight in the LEG schedule is covered exactly once by a crew pairing

c. any string and pairing is used no more than once (let's denote the non-zero pairings and strings as 'active')

d. the total cost is minimized

e. if an active crew pairing contains a connection

*t*(*i*→*j*) in T, and there is also some active aircraft string that also contains*t,*then we say that the crew turns with the aircraft and is thus synchronized. Downstream systems can ensure that the actual crew assigned to flights*i*and*j*remain with the actual aircraft tail number that flies*i*and then*j*.f. Maximally satisfy a reliability measure that is proportional to the tightness and the number of the synchronized connections in T. For the purpose of illustration in this post, we specify that a certain minimum count (

*m*)*of the connections in T be synchronized. The aim here is to be smart about picking the right airports and connections to synchronize to boost reliability as well as utilization.*g. The active strings belonging to a sub-fleet should form a Hamiltonian circuit. This is a maintenance requirement that tries to ensure equal wear-and-tear across the fleet. There are other constraints that are also interesting topics in their own right, but we'll ignore them here for brevity.

**Resource Synchronization Modeling**Our main focus here is on requirement (f). We provide some sample approaches to handling synchronization in large-scale scheduling:

a) Within the subproblem:

Really tight day-connections

*t*in T can be directly enforced by restricting*t*to be the only valid connection out of*i*and into*j*(*i*→*j*) in the flight network. Thus any pairing or string that comes of the subproblem that covers flight*i*will subsequently cover*j.*However, we cannot apply this idea to all connections in T since that is likely to be overly restrictive.b) Within the Master program:

Let

*p*(*t*)*= sum of all pairing variables that contain connection**t**q*(*t*)*= sum of all string variables that contain connection**t*Note that

*p*and*q*will be no more than 1.0. We can impose the following synchronization constraint:∑

_{T}*p*(*t*)*q*(*t*) ≥*m*The bilinear terms in the reliability constraint can be linearized in a straightforward manner. A personal favorite is the reformulation-linearization technique (RLT).

*z*(*t*) ≡*p*(*t*)*q*(*t*) ⇒
∑

_{T}*z*(*t*) ≥*m*,*z*(*t*) ≤*p*(*t*),*z*(*t*) ≤*q*(*t*),*z*(*t*) ≥*p*(*t*) +*q*(*t*) - 1
Thus, by adding O(T) very sparse constraints and continuous variables

1. The cardinality of set T be manageable in the context of the application.

2. Synchronizing two resources is easier than juggling three or more. We can see from the synchronization constraint that if the

*z*, we can model the synchronization component of ICAR without requiring any approximation, and the resulting formulation remains tractable. The RLT can be applied in a similar manner to synchronize three or more resources as well. The keys for this 'frontal assault' to work are:1. The cardinality of set T be manageable in the context of the application.

2. Synchronizing two resources is easier than juggling three or more. We can see from the synchronization constraint that if the

*p*-variable*s*are fixed, the*z*-variables can be eliminated, leaving us with just the*q*-variables. This 'two variable per constraint' structure makes life much easier during column generation. The synchronization duals associated with the connections in T tend to work much more effectively in generating string-pairing pairs that cover a beneficial subset of common turns in T.**Epilogue**

The ICAR solutions that were actually implemented (different from the illustrative version presented here) significantly improved upon the existing approach. It reduced business cycle time, greatly increased reliability, and reduced costs. The success of the ideas employed to tackle ICAR spurred the development of new, algorithmic techniques to solve the next-generation integrated crew scheduling problems that went on to save the LEG carrier many million bottom-line dollars annually during some difficult economic times. As far as the competition with LCA was concerned (for which this solution was designed): LEG had incurred enough losses and pulled the plug. Operations Research successful, patient dead.

This is cool!

ReplyDelete