OR IN AIRLINE INDUSTRY

OR INDUSTRY
IN AIRLINE

EDITED BY
Gang YU
University of Texas at Austin
Austin, Texas, USA

KLUWER ACADEMIC PUBLISHERS

Boston/London/Dordrecht
 CONTRIBUTORS

Erik Andersson
Carmen Systems AB
Odinsgatan 9
S-411 03 Gothenburg
Sweden
Efthymios Housos
Department of Electrical &
Computer Engineering
University of Patras
Rio
Greece 26500
Niklas Kohl
University of Copenhagen &
COWIconsult
Parallelvej 15
DK-2800 Lyngby
Denmark
Dag Wedelin
Department of Computing Science
Chalmers University of Technology
S-412 96 Gothenburg
Sweden
 1
CREW PAIRING OPTIMIZATION
Erik Andersson, Efthymios Housos*,
Niklas Kohl** and Dag Wedelin***
Carmen Systems AB, Gothenburg, Sweden
* University of Patras, Greece
** University of Copenhagen & COWIconsult, Denmark
*** Chalmers University of Technology, Gothenburg, Sweden

ABSTRACT
Next to fuel costs, crew costs are the largest direct operating cost of airlines. There-
fore much research has been devoted to the planning and scheduling of crews over
the last thirty years. The planning and scheduling of crews is usually considered as
two problems: the crew pairing problem and the crew assignment (rostering) prob-
lem. These problems are solved sequentially. In this paper we focus on the pairing
problem. The aim of the paper is twofold. First, we give an overview of the crew
pairing problem and synthesize the optimization methods that have been published
previously. Second, we present the Carmen pairing construction system which is in
operation at most major European airlines. Our purpose is to identify the particular
properties of the Carmen system that have made this system the preferred decision
support system for crew pairing optimization in Europe.

1 INTRODUCTION TO CREW PAIRING

OPTIMIZATION
1.1 The resource planning in airlines
The planning and scheduling of aircraft and crews in large airlines is a very
complex task, and is therefore usually divided into several planning stages. The
planning process is illustrated in gure 1, which shows the logical sequential
order of these stages, where the solution from one stage denes the data for the
next. In reality, however, the four stages are typically assigned to four dierent
1
2 Chapter 1

departments which simultaneously work on their part of the resource planning

problem. These departments communicate in order to adjust their plans to
each other and to update each other with changes. The rst draft of plans for
a given planning period may be updated several times until the nal plans are
xed and published. In the operational phase these plans may still be changed.
For example ights may be cancelled or delayed and crew may report sick.
Airlines tackle these problems by having some buer resources (for example
stand-by crew) and by using robustness of the plans as one of the issues to be
optimized.
Construct Timetable Fleet Assignment Crew Pairings Crew Assignment

Figure 1 The resource planning process in airlines.

First, the timetable is produced. Here the objective is to match the expectations
of the marketing department with the available eets and with constraints on
the network, for example the time slots available for the airline at dierent
airports. The output of this process is a number of ight legs (non-stop ights)
which the airline decides to operate.
Second, one must decide on the allocation of aircraft to the ight legs. The
expected revenue of a particular ight leg depends on the size of the aircraft used
on the leg. Also some aircraft may not be able to operate from some airports.
The primary issue is to ensure feasibility of the timetable given the available
eet. If this is not possible, the timetable must clearly be changed. Given
feasibility the objective is to maximize the expected revenue less operating
costs. Usually one assumes that the timetable is completely xed but there has
been some attempts to optimize the exact departure time of each leg (within a
rather small time interval) while solving the eet assignment problem [8].
Third, pairings are constructed. A pairing is a sequence of ight legs for an
unspecied crew member starting and ending at the same crew base. The crew
member will usually be working on these legs, but a pairing may also contain so
called deadheads, where the crew member is not working but is just transported
as a passenger. Legs are naturally grouped in so called duty periods (working
days), which are separated by lay-overs (overnight stops). In short and medium
haul problems a pairing may consist of one up to about ve duty periods. In
long haul problems, longer pairings are often permitted. Legal pairings must
satisfy a large number of governmental regulations and collective agreements
which vary from airline to airline.
Crew Pairing Optimization 3

The fourth planning problem is to assign pairings to named individuals. This

problem is denoted as the crew assignment or rostering problem. The objective
is to cover all work (pairings) as well as training requirements, vacations etc.
while satisfying work rules and regulations. Also, crew costs are to be mini-
mized. If crew are paid a xed salary (which is usually the case in Europe) one
tries to maximize the utilization of crew in order to minimize the number of
crew members.
Next to fuel costs, crew costs constitute the largest direct operating cost of
airlines. In 1991 American Airlines reported spending $1.3 billion on crew [1].
The corresponding gure for Northwest Airlines (1989) has been reported to
$1.05 billion [4] and United Airlines (1993) spent $0.6 billion just on pilots [15].
For major European airlines the gures are of the same magnitude. The crew
costs depend on the quality of the solution to the pairing problem as well as the
assignment problem, but since it is not possible to make up for poor pairings in
the assignment problem, it is reasonable to expect that savings in the pairings
problem will lead to savings in total crew costs.

1.2 Characteristics of the crew pairing

problem
The crew pairing problems varies somewhat between dierent airlines. Obvi-
ously the problem of small airlines is much simpler than the problem of larger
airlines, but there are also major dierences between the problems in North
America and the problems arising in Europe and elsewhere. The problem of
North American airlines is well described in the literature, for example [1], [4]
and [15]. Here we will highlight some of the dierences between the situation
in North America and Europe.
Crew category
On any ight leg there is a need for a given number of crew of the dierent
categories (captains, rst ocers, pursers, hostesses etc.). Crew in one category
can usually not substitute crew in another category and dierent rules apply
for each category, so the pairing problem decomposes by crew category. Within
the same crew category dierent rules may apply for dierent crew members.
This is for example the case for the Scandinavian airline SAS for crew members
from dierent countries. There are however some links between the dierent
crew categories since the robustness of the pairings speaks in favor of changing
crew (on the airplane) for all crew categories at the same point. This issue can
4 Chapter 1

be addressed by solving the problem for one crew category rst and trying to
use the airplane changes selected for the other crew categories as well.
Fleet
Cockpit crew (pilots) are usually only qualied to y one type of aircraft.
Therefore this problem also decomposes by eet. The number of daily ights
for major airlines is typically more than 100 for the smallest eet and between
500 and 1000 for the largest. Cabin crew are often qualied to y several types
of airplanes. United Airlines decompose the cabin crew problem in to three
problems: wide body, narrow body and narrow body with more than three
ight attendants [15]. The largest of these problems consist of 1716 daily legs
where the corresponding gure for cockpit crew is 622. The pairing problem
for cabin crew is also larger than for cockpit crew in the sense that each leg
usually requires one captain and one rst ocer but several hostesses. Still,
the cockpit crew problems are the most important ones due to the high salaries
for these crews.
Network Structure
Major North American airlines operate a so called hub and spoke network.
A few airports (the hubs) are regularly connected to each other and to many
other airports (the spokes). The timetable is constructed such that passengers
arriving at a hub can make connections to many outgoing ights without much
delay. In practice this means that a large number of ights arrive at the hub
within a short time interval. Shortly after, a large number of ights leave the
hub. This enables the airline to oer transportation between most spokes via
the hub with minimal waiting time. It is easy to realize that this kind of net-
work structure creates extremely many possible pairings. [15] notes that "each
arrival into Chicago can have more than 100 possible departures. It is also not
uncommon for a pairing to pass through Chicago more than once and each time
the combinatorials multiply". In Europe the hub and spoke network structure
is not (yet) predominant, so incoming crew can only continue on a relatively
small number of ights. Therefore the number of possible pairings tends to be
smaller in typical European problems than in typical North American problems.
Rules and Regulations
To be legal, pairings must respect governmental rules and collective agreements.
In United States the Federal Aviation Administration (FAA) regulations tend
to be the most important rules. These limit the length of duty periods and
specify the rest necessary between duty periods. There are exceptions to the
Crew Pairing Optimization 5

rules permitting violation of some limits if some extra rest is given, but still the
rules are relatively simple and identical for all airlines. Airline specic collective
agreements change this picture slightly, but the structure of the problem is the
same for all major North American airlines. In Europe, collective agreements
are usually much stronger than governmental regulations. The collective agree-
ments are typically very detailed and change often. Also, the rules are quite
dierent from airline to airline. Furthermore, the rules actually used are often
poorly documented compared to North America where the rules give a much
better description of the actual solution space.
Regularity of the timetable
North American airlines typically operate the same ights Monday to Friday.
During the weekend a subset of these ights are operated. The timetables of
European airlines vary much more from day to day. It is for example very
common to operate particular legs one, two or three times a week.
Cost structure
In North America crews are usually paid on the basis of so called credit hours.
These are calculated as the maximumof actual ying time and some guaranteed
minimum hours (for example a minimum of 5 hours per duty period). The
quality of a solution to the pairing problem is given by the ratio between credit
hours and ying time. For good solutions this ratio is one plus a few per cent.
European crews are often paid a xed salary, but still crew utilization is an
important factor.
The main similarities and dierences between the crew pairing problems faced
by North American and European airlines are summarized in table 1.

2 REVIEW OF EXISTING
OPTIMIZATION METHODS
2.1 The daily, weekly and fully dated
problems
A solution to a pairing problem (for a given crew category and eet) is a number
of pairings such that all ights in the planning horizon are covered as many
6 Chapter 1

North America Europe

Crew Problem decomposes by crew category since crew of one
category category can generally not substitute another category.
Fleet For cockpit crew the problem decomposes by eet type.
For cabin crew the problem does not necessarily decompose,
since cabin crews are qualied to y several types of airplanes.
Network Hub and spoke structure. Less structure.
structure Timetable constructed to
make many connections possible.
Rules and FAA regulations are the Complicated collective
regulations most important. agreements which
change often.
Regularity Same timetable from Monday Less regularity from
of the to Friday. Reduced day to day.
timetable timetable in weekends.
Cost Payments based on Crews are paid a xed salary.
structure credit hours.

Table 1 Similarities and dierences between Europe and North America.

times as needed. We will denote this as a fully dated solution since it species
particular days for the operation of the pairings. This problem is not attacked
directly, since the number of ight legs within a planning horizon of for example
one month is many thousands. Instead one solves a sequence of three problems
of which the rst two are approximations of the fully dated problem.
The daily problem
The assumption of the daily problem is that the timetable is the same every
day, and almost all published research on crew pairing focusses on this problem.
The implicit assumption is that a good daily solution is the hardest part of the
problem. This may be appropriate in North America, but is more questionable
in Europe due to the irregularities of the ight schedules.
A solution to the daily problem consists of a number of pairings such that every
leg is covered on one (arbitrary) day. From this solution one can construct a
fully dated solution which repeats itself daily, covering all legs on all days as
demonstrated in the following example.
Crew Pairing Optimization 7

Leg number From To Departure Arrival

1 A B 6.30 13.30
2 B A 14.30 21.30
3 B C 10.15 11.45
4 C B 12.15 13.45
5 B C 14.15 15.45
6 C B 16.15 17.45

Table 2 A small example with six ights.

P1 1-lo-2 (2) P7 5-6 (1) P13 3-lo-4-5-6 (2)

P2 1-lo-3-4-2 (2) P8 3-4-5-6 (1) P14 3-4-5-lo-4 (2)
P3 1-5-lo-4-2 (2) P9 2-lo-1 (2) P15 3-4-5-lo-4-5-6 (2)
P4 1-5-6-lo-2 (2) P10 2-lo-1-5-6 (2) P16 5-lo-4 (2)
P5 3-4 (1) P11 3-lo-4 (2) P17 5-lo-4-5-6 (2)
P6 3-6 (1) P12 3-lo-6 (2)

lo: layover

Table 3 All possible pairings for the problem of table 2. The cost of each
pairing is given in brackets.

An example
Consider the timetable given in table 2, and assume the following rules. Feasible
pairings start and end at one of the two crew bases located in A and B. They
may consist of at most two duty periods. Each duty period must have a duration
of at most 12 hours. The layover of a two duty period pairing must be at least
9 hours, or 1.5 times the length of the rst duty period if this is longer, and
at most 32 hours. The crew is paid a xed salary, so we can assume that the
cost of any legal pairing is proportional to the number of duty periods in the
pairing. Because of the small size of the problem, one can enumerate all feasible
pairings, see table 3.
Covering leg 1 and 2 requires a two duty period pairing, but this pairing can
cover no more than two of the remaining four legs. Therefore a second pairing
of one duty period is needed, so the cost of a daily solution can not be less
than three (duty periods per day). One example of an optimal solution to the
8 Chapter 1

daily problem is pairing P1 and P8. In order to construct pairings covering all
legs on all days, pairing P8 is operated every day. Clearly this covers leg 3, 4,
5 and 6 every day. Pairing P1 is operated by two crews every day. The rst
crew covers the rst duty period (in this case leg number 1). The second crew
covers the second duty period (in this case leg number 2). The next day the
rst crew covers the second duty period of the pairing while a new crew covers
the rst duty period etc. The daily cost of operating this schedule is equal to
the cost of the daily solution, in this case three duty periods per day. Figure 2
gives a graphical representation of the solution.
6 10 14 18 22 6 10 14 18 22 6 10 14 18 22

3 4 5 6

1 2

3 4 5 6

1 2

3 4 5 6

Day k-1 Day k Day k+1

Figure 2 An optimal solution to the daily problem with a cost of three duty
periods per day. Each line represents a pairing.
It is interesting to note that the assumption that the timetable is identical for
all days, does not imply that the duty periods should be the same every day.
This is an implicit consequence of solving the problem as a daily problem -
the problem itself does not require identical duty periods every day. Therefore
solving the daily problem optimally may not produce the best possible solution.
In fact we can produce a cheaper solution to the problem considered above, see
gure 3. This solution requires 2.5 crews per day on average. Pairings are not
repeated daily but with a cycle of two days. The solution exploits the fact that
the two day pairing, which cover the two long legs (1 and 2), can cover two of
the four short legs (3, 4, 5 and 6) either on the rst day of the pairing or on
the second day of the pairing. By letting the two day pairing alternate between
covering two short legs on the rst day and on the second day, we manage to
Crew Pairing Optimization 9

cover all short legs every other day, thus saving one duty period every other
day.
6 10 14 18 22 6 10 14 18 22 6 10 14 18 22

3 4 2

1 5 6 2

3 4 5 6

1 3 4 2

1 5 6

Day k-1 Day k Day k+1

Figure 3 A better solution using only 2.5 duty periods per day.
The weekly problem
The assumption of the weekly problem is that the timetable repeats itself every
week. Here one must construct pairings such that all ights within a week are
covered by one pairing. The starting point for solving the weekly problem is
typically the solution to the daily problem. This solution is however not feasible
on a weekly basis and the degree of infeasibility depends on the regularity of
the timetable. In North America the weekly problem is denoted the weekly
exceptions problem, since the task is restricted to modifying the daily solution
to the weekend exceptions. In Europe there are much more exceptions and the
daily solution may not be a very good starting point at all.
The fully dated problem
To construct a fully dated solution one must take care of the dierences between
weeks. There are two major sources of such dierences: change of timetable
and holidays. Due to varying demand, airlines change timetable several times
a year. This gives rise to the so called transition or cross-over problem. The
eect of holidays are typically that some ights that would usually have been
operated are cancelled. Also, extra ights may have been introduced. This
clearly also destroys the feasibility of a weekly solution. Due to the increased
competition between airlines and the development of computer based systems
that can reschedule fast, one must expect that timetables will become less
regular in the future.
10 Chapter 1

2.2 The Set Partitioning / Covering model

The main diculty in modeling the crew pairing problem is that the set of
feasible pairings is very dicult to characterize mathematically in any other
way than by enumeration. In addition, the cost of a pairing is usually a com-
plex function of its components. Therefore, all published methods attempt
to separate the problem of generating pairings from the problem of selecting
the best subset of these pairings. The remaining optimization problem is then
modelled under the assumption that the set of feasible pairings and their costs
are explicitly available, and can be expressed as follows:

minimize
Xc x subject to
p p
pX
2P
aip xp = ni 8i 2 I
pX
2P
b x
jp p  mj 8j 2 J
p2P
xp  0 and integer

The set of feasible pairings is denoted P and xp; p 2 P; is an integer decision

variable determining how many times pairing p is used. The cost of pairing p is
denoted cp , so the objective is to minimize total costs of the pairings used. The
set of legs is denoted I and pairing p covers leg i 2 I aip times. The number of
times leg i must be covered is ni . For cockpit crew this is typically 1, but for
cabin crew it may depend on the expected number of passengers, the priority
of the leg and other issues. The rst constraint set expresses that each leg must
be covered exactly the desired number of times. In some cases it is permitted
to over-cover a leg, implying that some of the crew are deadheading on the leg.
In this case a Set Covering type problem is obtained. Partitioning solutions
are preferred, because deadheading incurs extra costs and are unpopular with
the crew. Therefore many airlines do not accept deadheads in the solution to
the daily problem.
The second constraint set represents the set of other global constraints and are
denoted J. These may be base constraints requiring the workload of each base
to be within specied limits. In this case bjp is the workload assigned to the
base corresponding to constraint j if pairing p is used. The maximal possible
workload is given by mj . Also constraints on the number of pairings of various
lengths can be modeled this way.
Crew Pairing Optimization 11

The Set Partitioning type model is valid for as well the daily problem as the
weekly problem and the fully dated problem. For the example considered in
section 2.1 the daily problem is:

minimize 2x1 + 2x2 + 2x3 + 2x4 + x5 + x6 + x7 + x8 + 2x9 + 2x10

+2x11 + 2x12 + 2x13 + 2x14 + 2x15 + 2x16 + 2x17 s:t:
x1 + x2 + x3 + x4 + x9 + x10 =1
x1 + x2 + x3 + x4 + x9 + x10 =1
x2 + x5 + x6 + x8 + x11 + x12 + x13 + x14 + x15 =1
x2 + x3 + x5 + x8 + x11 + x13 + 2x14 + 2x15 + x16 + x17 =1
x3 + x4 + x7 + x8 + x10 + x13 + x14 + 2x15 + x16 + 2x17 =1
x4 + x6 + x7 + x8 + x10 + x12 + x13 + x15 + x17 =1
x1; x2; x3; x4; x5; x6; x7; x8; x9; x10; x11; x12; x13; x14; x15; x16; x17 2 f0; 1g

This problem has several optimal solutions with an objective function value
of 3, for example x1 = x8 = 1 and xi = 0 for all other variables. Note that
the numbering of the variables corresponds to the numbering of the pairings
in table 3, so this solution corresponds to the solution displayed in gure 2.
One optimal solution to the continuous (linear programming) relaxation of the
problem is x2 = x4 = x8 = 1=2 and xi = 0 for other variables with an objective
function value of 2.5. This is equivalent to using pairing P2, P4 and P8 every
other day which happens to be what the solution displayed in gure 3 does.
In general the continuous relaxation gives a lower bound on the best non-daily
solution, but this bound is not always tight.
A main problem with the Set Partitioning type model is that the number of
feasible pairings jP j is extremely large even for relatively small problems, so
even generating the data of the optimization problem is often impossible. In
[4] a 71 leg problem is reported to permit more than a quarter of a million
pairings. Large daily problems with several hundred legs may easily permit
several billions of pairings [20]. To some extent, this problem can be overcome
by considering a small subset of P 0  P of pairings only. Generation of pairings
and solving the Set Partitioning type problem is then done iteratively. In
each Set Partitioning iteration one selects the best solution from the pairings
in P 0. In each generation iteration new pairings are generated and included
in P 0. Some of the old pairings in P 0 are deleted, but one keeps at least
the pairings used in the last solution to the Set Partitioning type problem.
Therefore the solution can never get worse in the course of iterations. The
12 Chapter 1

number of iterations performed usually depends on the computer time available

and whether progress is being made.
Another diculty is that the resulting Set Partitioning problems are very large
and dicult to solve. Even when only the rst constraint set is present and
ni = 1 for all i, the problem is NP -hard [19], so it is very unlikely that there
exists an ecient algorithm which will always solve the problem optimally. This
is usually addressed by solving the problem with some heuristic.

2.3 Methods for the generation problem

In this section we describe methods for generating pairings. Total generation of
all pairings is only possible for small problems. For larger problems generation
must be restricted to a limited part of the problem, or to partial generation for
all ight legs. Also, a combination is clearly possible - partial generation for a
limited part of the problem.
Total generation for a limited part of the problem
The traditional approach has been to apply local optimization on an initial
solution. One limits the attention to a small number of pairings in the current
solution. These pairings can be chosen more or less randomly. The objective
is to nd an optimal solution for the subproblem chosen. First a number of
pairings in the current solution are selected. Then all possible pairings for the
legs on selected pairings are generated. Finally a set partitioning problem, with
variables corresponding to the pairings generated and the pairings of the old
solution, is solved. The solution obtained, which can clearly not be worse than
the old solution, is maintained for the next iteration. Alternatively one may
keep a larger number of good pairings for the next iteration.
Examples of systems using this approach includes the TRIP system [1] which
has been used by American Airlines and Continental Airlines, the TPACS sys-
tem [15] previously used by United Airlines and the ALLPS system marketed
by Unisys and previously used at Northwest Airlines and USAir. Since it is
only possible to generate all pairings for a rather small number of legs, the
outlined method may well end in a local minimum. To avoid this one may,
in some iterations, accept a new solution which does not decrease costs. [1]
describes other heuristic techniques to avoid local minima.
Crew Pairing Optimization 13

Published research has focussed on limiting the size of the subproblem by con-
sidering only a few pairings, but the number of possibilities can be reduced in
many other ways. Some of the possibilities are to:

Maintain the solution outside a specied time interval (for example one
day) and generate all possibilities within this time interval.
Limit the number of connections at the hubs.
Impose extra constraints to forbid pairings which are not likely to be used
in good solutions.

The rst possibility is generally applicable, while the other two possibilities
require the knowledge of an experienced planner to be most ecient. The
Carmen system (to be described in more detail in section 3) implements these
and other subproblem reduction methods.
Partial generation for all legs
The idea in these methods is to generate good pairings considering all legs at
the same time. A key question is what characterizes a good pairing. To some
extent, the linear programming theory gives an answer to this. Consider the
continuous relaxation of the Set Partitioning type problem. If this relaxation is
very good, which is commonly the case, it is reasonable to assume that pairings
used in the continuous solution (i.e. variables for which xp > 0) will be useful
to obtain an integer solution as well.
If one were to solve the continuous relaxation one would start out with a basis,
calculate reduced costs for all variables (pairings) and introduce the variable
with smallest reduced cost in the basis. This is not computationally feasible,
due to the extremely large number of variables, but it is actually possible
to solve the continuous relaxation, by exploitation of the so called column
generation technique (see [10] for a review of applications of column generation
in time constrained routing and scheduling). The idea is to nd the pairing
with smallest reduced cost as the column generation problem, without explicitly
calculating the reduced cost of all the variables. In the crew pairing context
it turns out that this problem is a constrained shortest path problem. The
approach was introduced in [17] and is implemented in the ALTITUDE system
marketed by Ad Opt Technologies. This system is used at Air Transat and at
a large U.S. carrier and has been tested at Air France [9].
14 Chapter 1

A more heuristic implementation of the same idea is to solve the constrained

shortest path problem heuristically, that is to use heuristics that can come up
with pairings with low reduced cost. This idea is sketched in [1] and seems to
be implemented in the new pairing optimization system developed by IBM and
Sabre Decision Technologies, used at American Airlines and USAir [20], and the
RALPH system developed for Delta Air Lines [18]. However, no details have
been reported. Even though none of these systems have been well documented
in the literature it seems reasonable to conclude that the trend (at least in North
America) is to use partial generation for all legs instead of total generation for
a limited part of the problem.

2.4 Methods for the Set Partitioning type

problem
Due to the many applications of the Set Partitioning and Set Covering prob-
lems, a large number of papers have treated these problems and many exact and
heuristic algorithms have been proposed. Space does not allow a comprehensive
review of this research, so we will only focus on the main ideas.
Methods for solving these problems often depend on the ecient solution of
their continuous relaxation, which for Set Partitioning and Set Covering type
problems is known to be dicult and highly degenerate [2]. Recent advances in
LP-technology have reduced this problem somewhat. Especially the emergence
of interior point methods have improved problem solving capability drastically.
[12] has tested the CPLEX [7] primal simplex, dual simplex and interior point
algorithm on the seven problems solved in [22]. On the smaller problems (less
than 100,000 non-zeros in the coecient matrix) the solution time is small for
all algorithms, but the largest problem with more than 500,000 non-zeros in
the coecient matrix was solved in 364 seconds by the interior point algorithm,
where primal simplex needed about one hour and dual simplex needed more
than two hours. [2] reports solving a 837 constraint, 5.5 million variable problem
to LP-optimum in about one hour using the so called SPRINT (partial pricing)
approach. [20] reports solving problems with even more variables. It seems
reasonable to conclude that a large number of variables is no longer a problem
for the LP-technology, but still problems arise when the number of constraints
increase much above 1000.
Exact algorithms
Crew Pairing Optimization 15

Most exact optimization approaches for the Set Partitioning problem are based
on Branch-and-Bound. Lower bounds are usually calculated by solving the
continuous relaxation but Lagrangean relaxation may also be used. Upper
bounds can be calculated using any heuristic.
Computational experiments show that the gap between the optimal objective
of the continuous relaxation and the optimal objective of the integer program
is very small. Small problems often have integer solutions but may have a
gap of up to a few per cent. Larger problems rarely have integer solutions to
the continuous relaxation, but the gap is always extremely small. Of the 11
problems with more than 100 constraints considered in [16] the largest gap was
0.7%. In a study of over one hundred large problems from several European
airlines, the gap was almost always less than 0.5% and for the largest problems
(more than one million non-zeros in the coecient matrix) the typical gap was
0.1% [12].
Branching on single variables is generally very inecient. [2] reports some
success using the "follow-on" branching strategy proposed by [21]. Either leg
number j follows after leg number i for a pairing in the solution or it does not.
Using this fact may eliminate a large number of variables in both branches.
[16] proposes a Branch-and-Cut algorithm for the Set Partitioning problem.
First the LP-relaxation is solved. If the optimal solution is fractional a violated
valid inequality is generated if possible. Several classes of strong valid inequal-
ities are used. Solutions are reported for a large number of relatively small
problems provided by dierent North American airlines. The largest problem
solved had about one million variables and 145 constraints. It consisted of all
feasible pairings (in the daily problem) for the smallest eet of a major North
American airline. This problem was solved to proven optimality in less than a
half hour on a CONVEX model C-220. No branching was necessary but 389
valid inequalities had to be inserted to obtain an integer solution.
Heuristic algorithms
Many heuristics have been proposed. One possibility is to use a Branch-and-
Bound based method but to stop before proven optimality. The simplest im-
plementation of this idea is to x the largest fractional xi value from the LP-
solution to 1. This eliminates the constraints covered by this variable and all
other variables covering these constraints. The procedure is applied until the
remaining problem is of manageable size. [2] reports reasonable results for
smaller problems using this approach. One may think of the methods as a
16 Chapter 1

partial evaluation of the branching tree and it will work with any branching
strategy.
The diculty of the LP can be avoided by attacking the problem from the dual
side. A natural way to do this is by Lagrangean Relaxation. One associates
a Lagrangean multiplier i with each constraint i of the problem. This multi-
plier can be interpreted as a price given for covering the associated constraint.
Pairings are used (that is xp = 1) if the cost is less than or equal toPthe sum
of multipliers of the constraint covered by the pairing, that is if cp  i aip i .
quiring that the reduced cost cp
Pi aipprogramming)
This is equivalent to the simplex (linear optimality criterion re-
i , where i is a simplex multiplier,
is non-positive for all basis variables.
Lagrangean Relaxation yields an integer solution but some constraints may be
multiply covered P and some may not be covered at all. Therefore multipliers
are adjusted. If p aip xp is more than P ni , i must be reduced to make it
less attractive to cover the constraint. If p aip xp is less than ni , i must be
increased.
One can show that there exist multipliers yielding an optimal feasible solution if
and only if the continuous relaxation has an optimal integer solution [19]. This
is rarely the case, so one must apply so called Lagrangean heuristics to modify
the solution and obtain feasibility. In a recent benchmark between Italian
universities on Set Partitioning problems arising in train crew scheduling the
two most successful approaches ([5] and [6]) were both based on the Lagrangean
Relaxation idea. Another dual approach has been suggested by Wedelin [22].
This is the method used in the Carmen system and is described further in
section 3.1.

3 THE CARMEN PAIRING

CONSTRUCTION SYSTEM
The Carmen system comprises a complete set of tools for editing pairings and
rules, as well as fully automatic generation of complete optimized schedules.
Both pairing construction and roster generation can be handled by the system,
although we will here focus on the former. Figure 4 gives an overview of the
main components of the system.
Crew Pairing Optimization 17

flights Graphical Automatic

crew data editing and scheduling
control system

Rule
rules compiler
external tables

Report pairings etc.

report specifications generator statistics

Figure 4 Overview of the Carmen system.

The graphical system provides the user interface, with editing and data han-
dling functionality, and is the standard means of accessing and controlling the
system. Data about ights, crews, etc. can be loaded into the system, and the
problem can be solved manually with the graphical editing and rule-checking
tools. For automatic scheduling, any part of the problem can be selected, op-
timization parameters can be set, and the resulting problem can be sent o to
the separate optimization module. It is also possible to monitor the progress of
all running optimization jobs, and to load the solutions back to the graphical
system for subsequent editing and examination.
An important and unique feature of the Carmen system is that the usually
complicated rules for feasible pairings are not hardwired into any part of the
system, but are input as any other data, written and maintained by the airlines
themselves. The rules are entered in an application specic rule language to
a separate module, the rule compiler, which provides a consistent interface for
testing whether a given pairing, or part of a pairing, is feasible or not. Also the
cost function for optimization is entered in this way. The main user advantages
of using a rule language is that only one description of all rules have to be
written, they can be easily changed and maintained, and it is easy to perform
18 Chapter 1

various what-if analyses. Also, it becomes possible for the users to control the
automatic pairing generation process in a exible way.
In addition, there is a report generator, which interprets a rule language, where
formatted output of pairings, rosters and statistics can easily be dened.

3.1 The Carmen automatic scheduling

module
Figure 5 gives an overview of the automatic scheduling algorithm in the Carmen
system. The design re ects the desire to limit the combinatorial explosion for
both generation and optimization. To enable planning periods of one or several
weeks, an overall local search is therefore added, where an initial solution is
created, and where subproblems of reasonable size are then repeatedly selected
for reoptimization. In the pairing generator, basically consisting of a depth-rst
search, the search tree is pruned to avoid massive generation of useless pairings.
Also, to handle the large problems created by the generator, a new type of set
covering optimizer is used. These dierent parts will now be considered in
detail.
Subproblem selection
A common size for a large weekly problem is around 4000 legs/week, and with
typically 3-5 legs per day in a pairing, this would give an intractable depth of
the search tree in the generator. However, for a weekly problem it turns out
to be a reasonable heuristic to solve daily subproblems. A partial explanation
is that during the day it is usually best to nd very tight connections, and in
particular simply to follow the aircraft: the crew is already in place, if there is
a delay the crew and the plane is synchronized etc. Overnight however, it is
usually better to nd a connection giving the crew a rest time as close to the
average as possible, and many reasonable connections are possible. We note
also that it is highly desirable to be able to solve a whole day at a time, since
it can be very dicult to nd good subproblem selection heuristics for daily
problems.
Given some initial solution, a daily window is then opened as a subproblem and
optimized in the hope of nding an improvement. With this technique, called
split-improve, each day is optimized in turn, creating small improvements until
a local optimum is reached. Typically, the days will be traversed 3-5 times.
Note also that selecting dierent daily subproblems in a weekly problem is not
Crew Pairing Optimization 19

crew and flight data

generate subproblem
initial
solution

pairing rule system

generator

initial
solution

set covering
optimizer

subproblem
selection subproblem solution

complete solution

Figure 5 Overview of the Carmen scheduling algorithm.

the same as solving the daily problem of section 2.1, which assumes a daily
regularity of the timetable.
An initial solution is created by creating a schedule from left to right, adding
one day at a time using the ordinary generator but with other parameters than
for the subsequent reoptimization process. We here note that it is important
to make the initial solution as good as possible, since local reoptimization may
not be able to change global properties of the solution.
For some problems it is can be useful to select the subproblems with a dierent
strategy, known as k-opt. Here, a limited number of pairings in a given solution
are opened over the whole planning period, and re-optimize the subproblem
20 Chapter 1

created by the legs in these pairings only. Clearly, these dierent subproblem
selection strategies can also be used interchangeably, to reach a better solution
than with any single strategy. For a more thorough discussion of subproblem
heuristics we refer to [11].
A dicult issue signicantly adding to the complexity of dening the subprob-
lems, is the problem of deadheading, and a considerable proportion of the code
deals with this problem. Unfortunately, it is usually not sucient to use only
the ights to be scheduled as connections, but passive transfers of crews, or
so called deadheads, on other ights are necessary to obtain solutions of high
quality. In a deadhead preprocessing step a limited number of additional ights
must be added to the chosen subproblem solely for this purpose. In the genera-
tion, these ights will be used just as any other ights, but in the optimization
step, there will be no requirement for these legs to be covered.
Since it is impossible to add all existing ights (possibly even with other air-
lines!) to a particular problem, it also turns out to be useful to examine the
subproblem solution in a heuristic postprocessing step, trying to replace the
chosen passive connections (corresponding to over-covers in the set covering
problem) by better combinations, and trying to analyze what deadheads might
be useful in the next iteration. One example is to compare pairs of pairings,
to see if a crossover of the pairings is possible so that sequences of deadhead
ights can be replaced by one single other deadhead ight.
The pairing generator
The basic and conceptually simple algorithm for generation is a depth rst
search in a search tree determined by the connection matrix representing all
legal connections between legs. This approach, in contrast to the column gen-
eration approach, has been consciously chosen to enable separation of the rules
from the algorithms. Search always begins from the subset of legs known as
start legs, being legs directly from a crew base, or connecting to a xed part of
a pairing (outside of the subproblem selected) from such a base. Analogously,
stop legs leading back to the crew base can be identied.
To make the generator reasonably ecient, the depth-rst search is restricted
in several dierent ways:

The search is limited by a maximum branching width on the search tree.

Typically this width is around 5-8 connections.
Crew Pairing Optimization 21

It is possible to indicate a preference for which connection or connections

should be searched rst, such as following the aircraft, in order to increase
the chance that good pairings will in fact be found within the limited
search width. Another possibility is to solve matching problems for each
airport, and use this as a guide to good connections.
in every step of the depth rst search, the pairing built so far is checked
for legality, the only interface to the rules being a test function telling if
the given legs violate any of the rules. If it is illegal, this branch is not
investigated further. It is important to note that since the legality rules are
programmable by the end user, they can also be used to actively enforce
not only genuine legality rules but also additional rules for the purpose of
pruning the search. For specic problems, an experienced user will often
be able to know that some connections are useless etc, and this information
can be very useful.

The optimizer
Since one wants to generate a large number of pairings in the generation step,
for the Carmen system typically between 10000 and 1000000 pairings, the op-
timization problems are very large, and also high quality solutions are clearly
necessary. Using standard techniques, the optimizer therefore easily becomes
a bottleneck in the system. In some systems, this is handled by restricting
the number of pairings generated, and by using a more complicated optimiz-
ing generator. However, it is then very dicult to separate the rules from the
generator, which is a signicant design advantage of the Carmen system.
As a rst step, preprocessing is applied to reduce the size of the problem. This
preprocessing is quite straightforward algorithmically, and consists of repeated
application of simple and well known reduction rules, see e.g. [13]. However,
the problems will still be very large, and to solve this, the Carmen system
uses a new type of optimizing algorithm. This optimizer has been described
elsewhere, and we refer to [22] for a full technical description. However, we will
outline some basic principles and ideas. The main design objective has been to
solve large problems, with as high quality as possible. This makes branching
strategies less attractive, and instead the following design strategy was chosen:

Approximation, in the sense of explicit deviation from exact, optimization

methods should be actively used as an algorithmic design principle.
22 Chapter 1

Only very simple operations with low complexity should be allowed, to

ensure a low complexity of the algorithm. Also, computational structure
should be emphasized, to allow for possible parallelization.

In addition, the optimizer has been designed without any problem specic
heuristics, to ensure the exible application of the algorithm and its implemen-
tation to 0-1 integer programs in general.
The basic strategy is to manipulate the cost function (and hereby the reduced
costs) using the invariants given by the constraints, until the solution can be
easily determined. To ensure low complexity of the operations, a central oper-
ational design aspect of the algorithm is that the changes of the costs are done
for one constraint at a time.
We now outline how the algorithm works for the Set Covering problem, that
is ni = 1 and there are only covering constraints present, cf. section 2.2.
As for a Lagrangean Relaxation algorithm, the aim is to nd multipliers such
that all constraints are covered and over-covered constraints have multiplier 0.
Mathematically, this corresponds to nding a set of multipliers   0 such that
the function '() is maximized, where
'() = min (0xp 1) [
X c x + X  (1 X a
p p i ip xp )]
p i p
The algorithm attempts to nd multipliers that maximize ', where the multi-
pliers should also have the property to give a unique solution in the x-variables.
If this is possible, then an optimal feasible integer solution to the original prob-
lem has also been found. However, this is rarely the case, so straightforward
iteration of the multipliers i usually converges to a lot of zeros in the reduced
costs, violating the desired uniqueness in the solution.
The critical idea of the algorithm is therefore to allow some manipulation of the
cost function that is not invariant, so that a relaxation with these properties
can be found. This is done by treating positive and negative reduced costs
dierently, eectively pushing them away from the value of zero. Clearly, this
disturbance should be as small as possible, so that the problem that is actually
solved will have a solution that is also good for the original problem. Therefore,
the amplitude of the disturbances are successively increasing during iteration,
until convergence occurs.
The details of this algorithm are described in [22], and it is also shown that for
dierent amplitudes the algorithm can be interpreted in terms of linear pro-
Crew Pairing Optimization 23

gramming, dynamic programming, and as a greedy algorithm. The increasing

amplitude therefore eectively achieves an interpolation between these dierent
algorithmic design principles.
In practice, it turns out that for set covering, the optimizer can easily and
predictably solve very large set covering problems up to about two million vari-
ables (with 5-10 times as many non-zeros in the coecient matrix), the limiting
factor being not running time but memory. When the algorithm was imple-
mented in 1992 it was signicantly faster than commercial linear programming
and Branch-and-Bound based optimizers such as CPLEX [22] also for moder-
ately sized problems, while the solution quality was about the same. A recent
study [12] has shown that if the integrallity gap is small enough, CPLEX can
be competitive on smaller problems with up to about one million non-zeros in
the coecient matrix.

3.2 The rule system

All rules and cost functions for the Carmen system are written in the rule
language, designed to be as convenient as possible for specifying rules. The
restrictions of the language and the design of the compiler also makes it impos-
sible to crash the system through rule programming errors.
When a rule set has been written it is compiled and linked, and can then be
used by any part of the system. At present, the compilation target is C code
that is linked dynamically into the system. Compilations can be tailored to
either manual or automatic rule checking, and can be specialized to specic
constraints by partial evaluation. Empirically, only a small set of the rules
are actually applicable to any particular problem, and such optimizations can
therefore speed up the rule checking process considerably.
The rule language
The rule language is a highly specialized and strictly type checked functional
language, sharing many general properties with such languages, the fundamen-
tal exception being that recursion is not allowed. General information about
functional languages can be found elsewhere, and we will here outline some
specic properties of the rule language.
The basic purpose of a rule set is to determine the conditions under which a
line of work for an individual is legal or not. The language provides a large
24 Chapter 1

number of predened access functions for accessing the data in a line of work.
New expressions and functions operating on this data can be dened, and a
rule program is simply a collection of such functions and expressions. The
top level construct is the rule, which in its basic form is a boolean function,
its value determining whether this rule is violated or not. The language itself
does not specify the order in which rules are called, and any repetitions of rule
checks, looping over dierent lines of work etc. are handled automatically by
the system.
The lowest level of the line of work is the leg, or other similar activity such
as training. However, for easy and convenient access to the data, the legs
are clustered on several predened levels. Such clustering includes "rotation",
"rotation day" i.e. all rotations in a particular day, and "line of work" which
is the top level. Most access functions refer to individual legs, such as "aircraft
type", "departure" etc, but some refer directly to a higher level. The language
contains predened constructs for working on these higher levels, so that for
example the total ying time on a working day can easily be expressed.
In addition, the rule language provides a lot of specialized functionality to
facilitate the description of rules, some examples being:

data types and functions for easy handling of time calculations

internal and external tables for additional data
external parameters for modifying the rules without recompilation
consistent handling of inadequate data with the "void" value
facilities for grouping and activation of rules and rule sets
numerical penalties and exceptions to enable soft rules and temporary rule
relaxation

As an example of what an actual rule might look like, we give the following
source code for maximum work time in a duty period:

rule max_duty_a =

%fdp_length% <= %max_duty_acclimatized%;

Crew Pairing Optimization 25

remark "Maximum scheduled FDP acclimatized";

end

%fdp_length% = last(leg, arrival) - first(leg, departure) + 2:00;

%max_duty_acclimatized% = matrix m_max_duty_acclimatized;

matrix m_max_duty_acclimatized =

%landings%, %local_checkin% -> %max_duty_acclimatized%;

(0,1), 2, 3, 4, 5, - ;
(06:00,07:59); 12:00, 11:45, 11:00, 10:15, 9:00, 0:00;
(08:00,12:59); 12:00, 12:00, 12:00, 11:45, 10:15, 0:00;
(13:00,17:59); 12:00, 12:00, 11:30, 10:45, 9:15, 0:00;
(18:00,21:59); 12:00, 11:15, 10:30, 9:45, 9:00, 0:00;
(22:00,05:59); 11:00, 10:15, 9:30, 9:00, 9:00, 0:00;

end

In this code, the rule %max duty a% species that the expression %fdp length%
must be less than or equal to the expression %max duty acclimatized%. These
expressions are then dened, %fdp length% by accessing some data in the line of
work, and %max duty acclimatized% by the use of a "matrix", whose (scalar)
value is determined by table lookup based on the values of %landings% and
%local checkin%.

4 PRACTICAL EXPERIENCE WITH THE

CARMEN SYSTEM
The Carmen system is now in production at Alitalia, KLM, Lufthansa and
SAS. These airlines use the Carmen system for cockpit as as well as for cabin
crew. Currently the system is being modied for railway crew scheduling. This
new system is planned to go into production at the Swedish Railways during
1996.
The airlines using the Carmen system today operate 3000 to 10000 ight legs
a week. The total set of crew pairings have to cover 2-3 cockpit positions,
and 3 to 20 cabin crew positions. To create and manage this set of pairings
26 Chapter 1

through all stages of planning an airline needs a team of 2-5 full time system
users. It is also common that the airline keeps a full time person assigned to
writing rules and report specications. The fact that the Carmen system is
highly programmable strongly in uences how the system is actually used, and
a number of qualitatively new issues have appeared.
Dening the rules
For many European airlines, the rule set is not strictly dened, and rules are
developed in a feedback process where they are modied after inspecting the
optimized schedules. For example, the rule writer can implement proposed
rule modications, allowing easy evaluation of the cost and other aspects of
these changes, and this information is used in union negotiations. It has been
estimated by one airline that the capability to control the cost impact of rule
changes gives even higher savings than optimization only, given the original set
of rules. Airlines using the Carmen system have raised pairing productivity by
3 - 10 percent during the period the system has been in use.
It is also common that the hard legal and contractual rules are much less
restrictive than the rules actually applied by a planner. If, for instance, it is
allowed to work 12 hours a day the planner may still have good reasons not to
create longer days than 10 hours. One reason for this could be that another rule
prohibits work more than 42 hours in 7 days so "too long" duty periods will
be useless in rostering. Another reason could be that the planner knows that
crews will call sick on too hard working days so the gain in the early planning
stage will be lost later on. The way this is usually handled in the system is by
strong penalties on pairings coming close to the rule limits.
Diculties of rule programming
Giving control to the user through the rule system, some issues that otherwise
would occur only as implementation problems appear at the user level, and it
becomes necessary and sometimes dicult to enforce the skill and discipline in
writing the rules. This is true especially since the rules will typically be called
very many times in the pairing generator, and the rule checking can easily
dominate the total running time.
First, it turns out that a complete rule implementation covering all eets,
longhaul, shorthaul, all crew categories, dierent union agreements, schedul-
ing standards etc. is very large. It is not uncommon that these complete rule
sets contain 10 - 20 times as many rules as are relevant for a single optimization
problem. Managing the large rule set becomes a problem in itself which is often
Crew Pairing Optimization 27

in con ict with the need to optimize rules for each specic planning problem.
It has therefore been non-trivial to obtain production performance comparable
to the performance of much simpler test programs used in initial tests. One
solution has been to develop the partial evaluator, that eectively lters out
aspects of the rules that are not relevant for a particular problem.
While the rule language can be used to create more or less arbitrary rules, care
must also be taken so that the feasible set of pairings dened by the rules has
the property that any part of a legal pairing is also legal. If not, the search
algorithm in the generator will have diculties in nding legal pairings. For in-
stance, a rule can be phrased: "it is allowed to have a rest time shorter than 10
hours if the crew member returns to base within 8 hours after the termination
of that rest time". If all pairings which do not return to base within 8 hours
are illegal, the generator may not nd any pairings returning to base because
the rst leg on the route back will always be illegal. In the Carmen system this
problem is handled by detection mechanisms giving warning messages in run-
time. That way the rule writer gets feedback about these subchain illegalities
and can correct her rules. In the example above, she would rephrase the rule
to allow all pairings with duty periods shorter than 8 hours after a short rest
time.
Rules to control generation
Another aspect of rule writing is that rules can be added to the rule set to
actively reduce the search space for the generator. This is important in practice,
and makes it possible to exploit user experience and the special characteristics
of individual problems.
For example, there are problems where one day pairings are preferred but where
also a few ve day pairings are necessary. Almost all of the computing time
would probably be spent on nding those few 5 day pairings, if nothing is
done specically to focus the search on shorter pairings. With the system, this
problem is handled by inventing rules dening the conditions under which the
intractable pairings are allowed. For instance: "5 day pairings are only allowed
if destinations ATH or BEY are touched". Many heuristic rules like this have
to be invented to make the system ecient for large problems. This, of course,
requires that the person responsible for writing rules has a good understanding
of how the generation process works.
A way to build know-how on smart rule writing is to encourage users from
dierent airlines and railways to meet and exchange ideas and experiences.
Such a user group for Carmen has been formed recently. Perhaps also, as the
28 Chapter 1

European airline community gets more accustomed to automatic scheduling,

the hard rules will evolve to more accurately dene the solution space.
Deadheading
Another dicult issue is deadheading. Although deadheads are intractable and
good pairing solutions only contain a few, it may require more work to nd
those few deadheads than to search connections for on-duty ights. A small
charter problem with 500 on-duty legs, may require intelligent search in a set of
20000 potential deadhead legs. Sometimes deadheading on other airlines, trains
or limousines are preferred. Double deadheading is not unusual on irregular
longhaul schedules. The end user therefore needs to tune a number of deadhead
search parameters to nd a good compromise between speed and the program's
ability to nd appropriate deadheads. Obviously, a more extensive deadhead
search can be aorded on the small charter problem than on a big shorthaul
problem.
The fact that the Carmen system uses a set covering approach to select pairings
adds another problem dimension to deadheading. Deadheads can be created by
the set covering optimizer because it is cheaper to cover a leg twice. If a pairing
turns illegal when an on-duty leg is changed to a deadhead leg, the set covering
solution may be useless. A good example of this problem is the Alitalia MD80
eet of 1993, when all crews were based in Rome. A large number of ights
departed from Milan and deadheading between Rome and Milan was necessary.
However, the minimum connection time in Milan was 10 minutes longer if one
arrived to Milan by a deadhead ight. Therefore, when the set covering opti-
mizer created deadheads out of legs with short (and ecient) connections those
pairings became illegal. This problem can be attacked in two ways. First, the
rule writer has to avoid unnecessary rules to restrict deadheading and replace
such rules with penalties. Secondly, the heuristic reshuing of deadheads dur-
ing the solution process, together with explicit search for deadhead alternatives
can minimize this problem.

5 CONCLUSIONS AND FUTURE

DEVELOPMENTS
The pairing optimization problem is a key problem in the resource management
of airlines. A number of systems developed and used in North America have
been described in the literature. In Europe most major airlines have chosen to
Crew Pairing Optimization 29

use the Carmen pairing construction system. We believe that the success of this
system is mainly due to the integration of manual and automatic scheduling,
robust and high quality optimization, and a unique degree of user programma-
bility.
The Carmen system is continuously being developed and improved. Cur-
rently the rule language is being revised to improve both rule writing and rule
checking. Also a major development project in cooperation with Lufthansa,
Chalmers University of Technology, Gothenburg, Sweden and University of Pa-
tras, Greece has just been launched. This project is supported by the Esprit
program of the European Community and the objective is to further develop
the modeling and optimization techniques of the Carmen system. In addition,
parallel implementations will be investigated, to enable further reduction of the
planning cycles.

REFERENCES
[1] Anbil, R., E. Gelman, B. Patty and R. Tanga (1991) "Recent Advances in
Crew-Pairing Optimization at American Airlines", Interfaces, vol. 21. no.
1, pp. 62-74.
[2] Anbil, R., R. Tanga and E.L. Johnson (1992), "A global approach to crew-
pairing optimization", IBM Systems Journal, vol. 31, no. 1, pp. 71-78.
[3] Anbil, R., C. Barnhart, L. Hatay, E.L. Johnson and V.S. Ramakrishnan
(1993), "Crew-pairing Optimization at American Airlines Decision Tech-
nology", Optimization in Industry, eds.: Ciriani, T.A. and R.C. Leachman,
John Wiley and Sons Ltd..
[4] Barutt, J. and T. Hull (1990), "Airline Crew Scheduling: Supercomputers
and Algorithms", SIAM News, vol. 23, no. 6, pp. 1 and 20-22.
[5] Caparara, A., M. Fischetti and P. Toth (1995), A Heuristic Algorithm for
the Set Covering Problem, working paper.
[6] Ceria, S., P. Nobili and A. Sassano (1995), A Lagrangean-based Heuristic
for Large-scale Covering Problems, working paper.
[7] Cplex Optimization Inc. (1994), Using the CPLEX Callable Library, Cplex
Optimization Inc., Suite 279, 930 Tahoe Blvd., Bldg. 802, Incline Village,
NV 89451-9436, USA.
30 Chapter 1

[8] Desaulniers, G., J. Desrosiers, M.M. Solomon and F. Soumis (1994), Daily
Aircraft Routing and Scheduling, Research report G-94-21, GERAD, Mon-
treal, Canada.
[9] Desaulniers, G., J. Desrosiers, Y. Dumas, S. Marc, B. Rioux, M.M.
Solomon and F. Soumis (1995), Crew Pairing at Air France, Research
report G-93-39, GERAD, Montreal, Canada.
[10] Desrosiers, J., Y. Dumas, M.M. Solomon and F. Soumis (1995), "Time
Constrained Routing and Scheduling", in Handbooks in Operations Re-
search and Management Science, vol. 8: Network Routing, eds.: Ball, M.O.,
T.L. Magnanti, C.L Monma and G.L. Nemhauser, North-Holland, Ams-
terdam, The Netherlands.
[11] Elmroth T. and Housos E. (1996), "Automatic Subproblem Optimization
for Airline Crew Scheduling", Interfaces (to be published).
[12] Engel, F. (1995), Summary over test runs, Internal report, Carmen Sys-
tems AB, Gothenburg, Sweden.
[13] Garnkel, R.S. and G.L. Nemhauser (1972), Integer Programming, John
Wiley and Sons.
[14] Gershko, I. (1989), "Optimizing Flight Crew Schedules", Interfaces, vol.
19, no. 4, pp. 29-43.
[15] Graves, G.W., R.D. McBride and I. Gershko (1993), "Flight Crew
Scheduling", Management Science, vol. 39, no. 6, pp. 736-745.
[16] Homan, K.L. and M. Padberg (1993), "Solving Airline Crew Scheduling
Problems by Branch-and-Cut", Management Science, vol. 39, no. 6, pp.
657-682.
[17] Lavoie, S., M. Minoux and E. Odier (1988), "A new approach for crew
pairing problems by column generation with an application to air trans-
portation", European Journal of Operational Research, vol. 35, pp. 45-58.
[18] Marsten, R. (1994), Crew Scheduling with RALPH, Presentation given
at the workshop "Optimization in Production and Transportation", The
Hague, The Netherlands, November 9-11, 1994.
[19] Nemhauser, G.L and L.A. Wolsey (1988), Integer and Combinatorial Op-
timization, Wiley - Interscience.
[20] Pulleyblank, W.R. (1994), An Airline Crew Pairing Optimization Sys-
tem, Presentation given at the workshop "Optimization in Production and
Transportation", The Hague, The Netherlands, November 9-11, 1994.
Crew Pairing Optimization 31

[21] Ryan, D.M. and J.C. Falkner (1987), " A Bus Crew Scheduling System
Using a Set Partitioning Model", Asia Pacic Journal of Operational Re-
search, no. 4, pp. 39-56.
[22] Wedelin, D. (1995), "An algorithm for large scale 0-1 integer program-
ming with application to airline crew scheduling", Annals of Operations
Research, vol. 57, pp. 283-301.