Master Document Template

1 downloads 0 Views 2MB Size Report
TDD schedules channel missions to haul on-hand cargo. These missions .... example using current manual planning methods in 0. A TS-IAOP ..... time at any node is greater than the previous node start time plus the service time and the ...... 5545. OTBH. ORBD. 0. 1. 0. 232. 235. 1. 5546. OKBK. ORBD. 9. 0. 17. 232. 233. 3.
Copyright by Kiel Martin 2012

THE DISSERTATION COMMITTEE FOR KIEL MARTIN CERTIFIES THAT THIS IS THE APPROVED VERSION OF THE FOLLOWING DISSERTATION:

AN ADVANCED TABU SEARCH APPROACH TO THE INTRATHEATER AIRLIFT OPERATIONS PROBLEM WITH SPLIT LOADING

Committee: J.W. Barnes, Supervisor Michael Ciarleglio, Co-supervisor Erhan Kutanoglu David Morton Jeffery Weir

AN ADVANCED TABU SEARCH APPROACH TO THE INTRATHEATER AIRLIFT OPERATIONS PROBLEM WITH SPLIT LOADING

BY KIEL MARTIN, B.S., M.S. OPERATIONS RESEARCH

DISSERTATION Presented to the Faculty of the Graduate School of The University of Texas at Austin in Partial Fulfillment of the Requirements for the Degree of

DOCTOR OF PHILOSOPHY

THE UNIVERSITY OF TEXAS AT AUSTIN AUGUST 2012

Dedication To my family.

Acknowledgements The last in the line of many grateful former advisees, I would like to thank Dr. J. Wesley Barnes for his energy, dedication, patience, and guidance. To Dr. Michael Ciarleglio, I owe a deep gratitude for volunteering to serve as my co-advisor, tirelessly answering my simple questions as I learned to extend his powerful metaheuristic framework and providing invaluable expertise. I hope only to someday be a peer in terms of software development instead of a pupil. Without either one of them this work would have stagnated long before completion. To Dr. Erhan Kutanoglu, Dr. Dave Morton, and Dr. Jeffery Weir, thank you for the taking the time to serve on my committee. To Jerome Goodin, I appreciate your efforts as a practitioner to reach out and connect to the academic community. I hope our continued collaboration brings together research and practice to improve USAF mobility operations in the future. To my friends and colleagues at UT Austin I say thanks for a rewarding, enjoyable learning experience. Apart from the stresses of research, I will have many found memories of Austin and the ORIE program. Finally, I must thank my wife. Only she knows the trials and tribulations I struggled through to complete this work. I am blessed to be loved by an amazing woman.

v

AN ADVANCED TABU SEARCH APPROACH TO THE INTRATHEATER AIRLIFT OPERATIONS PROBLEM WITH SPLIT LOADING Kiel Martin, Ph.D. The University of Texas at Austin, 2012

Supervisors: J. Wesley Barnes, Michael Ciarleglio This dissertation details an algorithm to solve the Intratheater Airlift Operations Problem (IAOP) using advanced tabu search. A solution to the IAOP determines the routes and assignment of customer requests to a fleet of aircraft over a given time horizon. This problem and other variants comprise an ongoing challenge for United States Air Force (USAF) planners who manage detailed logistics throughout many theaters of operations. Attributes of the IAOP include cargo time windows, multiple cargo types, multiple vehicle cargo bay configurations, vehicle capacity, route duration limits, and port capacities. The IAOP multi-criteria objective embraces several components with the primary goal of satisfying as much of the demand as possible while minimizing cost. The algorithm is extended to allow split load deliveries of customer requests, allowing a shipment to be split into two or more sub-loads which are delivered separately to the customer. The split load relaxation, while significantly increasing the complexity of the problem, allows for possible improvement in the solution. The necessary changes to the model and algorithm are detailed, providing a foundation to extend any local search algorithm solving a vehicle routing problem to allow split loading. Results allowing split loading are presented and compared with results without split loading. The algorithm is also extended to include a rolling time horizon. Starting from a solution found at a previous time step, the algorithm is limited on how the solution can be modified. This reflects the reality of operations in which near-term plans are locked as they approach and enter execution while longer-term plans are continually updated as new information arrives.

The views expressed in this article are those of the author and do not reflect the official policy or position of the United States Air Force, Department of Defense, or the U.S. Government vi

Table of Contents CHAPTER 1 INTRODUCTION

1

1.1 Motivation ..........................................................................................................1 1.2 Research Contribution .......................................................................................2 1.3 Summary ............................................................................................................5 CHAPTER 2 BACKGROUND 1.1

6

Current Practice to Solve the IAOP ................................................................6 2.1.1 Objective ................................................................................................8 2.1.2 Inputs......................................................................................................9 2.1.3 Planning Function ................................................................................10 2.1.4 Execution Function ..............................................................................12

2.2 Problem Description ........................................................................................13 2.2.2 Traditional MIP Formulation ...............................................................15 2.2.3 Unimplemented constraints .................................................................19 2.3 Literature Review.............................................................................................20 CHAPTER 3 SOLVING THE INTRATHEATER AIRLIFT OPERATIONS PROBLEM

23

3.1 Modeling the IAOP ..........................................................................................24 3.1.1 Definitions............................................................................................24 3.1.2 The Decision Variable Configuration ..................................................26 3.1.3 Hashing ................................................................................................29 3.1.4 A Small IAOP Example .......................................................................29 3.2 Designing the TS-IAOP ...................................................................................32 3.2.1 Objective Function Measures ..............................................................32 3.2.2 A Constrained Multi-Criteria Objective ..............................................34 3.2.3 TS-IAOP Neighborhoods.....................................................................36 3.2.4 Composite Neighborhoods...................................................................40

vii

3.3 TS-IOAP Memory Structure ............................................................................40 3.4 TS-IAOP Neighborhood Selection Strategies .................................................41 3.5 TS-IAOP Results .............................................................................................43 3.5.1 Data ......................................................................................................43 3.5.2 Assumptions .........................................................................................45 3.5.3 Experimental Results ...........................................................................45 3.5.4 Search Trajectory Output .....................................................................51 3.5.5 Additional Airlift Metrics ....................................................................54 3.6 Extensions ........................................................................................................55 3.7 Conclusions ......................................................................................................56 CHAPTER 4 THE IAOP WITH SPLIT LOADS

57

4.1 Modeling Split Loads .......................................................................................59 4.1.1 Split Shipment Decision Variable ........................................................59 4.1.2 A Small Split Load Example ...............................................................61 4.2 Designing the TS-IAOP-SL .............................................................................63 4.2.1 IAOP-SL Objective Function Measures ..............................................64 4.2.2 IAOP-SL Neighborhoods.....................................................................65 4.2.3 Composite Neighborhoods...................................................................68 4.2.4 IAOP-SL Dynamic Neighborhood Selection Strategy ........................68

viii

4.3 TS-IAOP-SL Results .......................................................................................69 4.4 Lower Bounds ..................................................................................................71 4.5 Extensions ........................................................................................................72 4.6 Conclusions ......................................................................................................73 CHAPTER 5 THE IAOP-SL WITH A ROLLING HORIZON

75

5.1 Modeling a Rolling Horizon ............................................................................75 5.2 Designing the Dynamic TS-IAOP-SL .............................................................77 5.3 Results ..............................................................................................................79 5.4 Extensions ........................................................................................................80 5.5 Conclusions ......................................................................................................80 CHAPTER 6 CONCLUSIONS

83

6.1 Major Contributions .........................................................................................83 6.2 Further Enhancements .....................................................................................85 6.3 Future Extensions.............................................................................................86 6.4 Summary ..........................................................................................................88 Glossary .................................................................................................................90 Appendix A

Example Using Current Planning Methods ................................92

Appendix B

Cargo Configurations ..................................................................99

Appendix C

Data ...........................................................................................101

References ............................................................................................................121 Vita ....................................................................................................................124

ix

List of Tables Table 1: Port Data ..................................................................................................30 Table 2: Aircraft Data ............................................................................................30 Table 3: C-17 Data .................................................................................................30 Table 4: Shipment Demand Data ...........................................................................30 Table 5: Summary of measures..............................................................................33 Table 6: Feasibility constraints as penalty measures .............................................34 Table 7: Hierarchical description of weights used in multi-criteria objective .......35 Table 8: Description of Scenarios ..........................................................................45 Table 9: Results for Scenarios 1-5 .........................................................................49 Table 10: Results for Scenarios 6-8 .......................................................................50 Table 11: Metrics relevant to Air Mobility Command for Scenarios 6-8..............55 Table 12: Shipment demand for Split load example 1 ...........................................61 Table 13: Split Load Results ..................................................................................74 Table 14: Dynamic Scenario results ......................................................................82 Table 15: Sorted list of shipments by ALD, RDD, and priority ............................93 Table 16: Transit time between locations and the turn time at each location ........93 Table 17: Mission 1 construction summary ...........................................................95 Table 18: Mission 1 information............................................................................96 Table 19: Mission 2 construction summary ...........................................................97 Table 20: Mission 2 information............................................................................97

x

List of Figures Figure 1: Representation of the Planned Missions ..................................................8 Figure 2: Decision Variable Configuration............................................................26 Figure 3: Vehicle Decision Variable......................................................................27 Figure 4: Routes and Stops within the Vehicle Decision Variable ........................28 Figure 5: Unassigned Shipment Element Decision Variable .................................29 Figure 6: Aircraft 1 schedule .................................................................................31 Figure 7: Aircraft 2 Schedule .................................................................................32 Figure 8: Basic Dynamic Neighborhood Selection Strategy .................................42 Figure 9: Standard Dynamic Neighborhood Selection Strategy ............................42 Figure 10: Aggressive Dynamic Neighborhood Selection Strategy ......................43 Figure 11: Scenario 1 search trajectories for Basic, Standard, and Aggressive DNS strategies ...........................................................................................53 Figure 12: Best Solution for Scenario 1 during search for each DNS strategy .....54 Figure 14: Split Shipment Decision Variable ........................................................60 Figure 15: Summary of solution not allowing split loads ......................................62 Figure 16: Summary of solution allowing split loads ............................................63 Figure 17: Split Load Dynamic Neighborhood Selection Strategy .......................69 Figure 17: Scenario 5 best solution during search .................................................71 Figure 18: Scenario 1 comparison of best solutions ..............................................72 Figure 19: Fleet plan over 72 hour horizon ...........................................................76 Figure 20: Fleet plan after time step to next day ...................................................77 Figure 21: Updated fleet plan constrained by previous plan .................................78 Figure 22: Updated fleet plan constrained by routes currently in progress ...........79 Figure 23: Graphic representing APOE -> APOD for each shipment ...................92 Figure 24: Algorithm for planners to schedule shipments .....................................94 Figure 25: Route 1 and Route 2 labeled in sequential order of route segments. ...98 Figure 26: C-17 cargo configurations ....................................................................99

xi

CHAPTER 1 INTRODUCTION This dissertation continues a long line of fruitful research into tabu search pursued by J. Wesley Barnes over the last three decades. His work has significantly advanced the state of the art of metaheuristics over several combinatorial problem domains, including extensions to vehicle routing problem with numerous military applications.

1.1 Motivation Since the origins of operations research, military logistics has been a driver for improved models and methods. Recently, several large instances of military logistics problems have been solved using tabu search (TS) highlighting different aspects of the logistics chain including refueling operations, deployment of forces, and theater distribution (Barnes, Wiley et al. 2004; Crino, Moore et al. 2004; Lambert, Barnes et al. 2007; Burks, Moore et al. 2010). In this research, we introduce the Intratheater Airlift Operations Problem (IAOP) in which a fleet of aircraft is tasked with fulfilling customer requests to pick up and deliver cargo within a theater of operations. This problem is based directly on necessary airlift planning to support operations in the middle east and is an extension of a one-to-one pickup and delivery problem (PDP) (Cordeau, Laporte et al. 2008) in which each customer request has a specific origin and destination. Variants of the PDP are found in many transportation problems such as scheduling and routing for ship or airlift problems. The PDP is an extension of the wellstudied vehicle routing problem (Dantzig and Ramser 1959). Over the last half century,

1

significant progress has been made on many difficult extensions applied to the VRP. The constraints are summarized as follows: 

multiple vehicles;



multiple trips;



capacitated vehicles;



route duration limits;



time windows for each customer request;



precedence constraints;



port capacities; and



customer request priority levels. We implement a multi-criteria objective with the primary goal of maximizing

effectiveness and a secondary goal of maximizing efficiency, measured by several metrics to be described later. While most research focuses on problems in which all demand must be satisfied, we relax this constraint, similar to the defined orienteering problem (Archetti, Feillet et al. 2009), or generalized PDP (Ropke and Pisinger 2005). We also allow split load deliveries of customer requests, allowing a shipment to be split into two or more sub-loads which are delivered separately to the customer (Dror and Trudeau 1989). Lastly, we consider a rolling time horizon with dynamic arrival of demand data in which the problem must be resolved starting from an existing solution, implementing new information.

1.2 Research Contribution Recent advances have allowed classical math programming methods to solve ever larger instances of difficult problems, even the PDPTW. However, at this time, given the 2

several additional complicating constraints and size of the IAOP, a metaheuristic approach is the only practical option. The first contribution of this research is modeling and solving the IAOP using advanced TS. The object-oriented design of the solution representation and the defined neighborhoods allow the search to work from a micro to a macro level, permitting a range of alternatives from the addition of a single unit of a shipment pickup to the deletion an entire vehicle route. Solutions explicitly allow for unmet demand and model down to smallest unit of cargo, while aggregating cargo by customer during the search to minimize computational complexity. Often, direct search neighborhoods rely solely on insert and swap moves. The IAOP requires a more general framework as exemplified in recent advances in local search as described by Ropke and Pisinger (2005) and Ciarleglio (2008), where add and delete moves are the core building blocks of direct search neighborhoods and not all solution elements (i.e., customer requests) are required to be in the solution (i.e., included in scheduled routes) at each iteration of the search. Following any add or delete move, a solution element may be placed on an ‘unassigned’ list and may or may not be added back into the solution at the next iteration. Such different neighborhood strategies allow the number of solution elements considered to differ at each iteration of the search. Data for the instances of the IAOP are based on historic data from United States Air Force airlift operations in the Middle East. Several instances are developed and numerical results are reported comparing several different dynamic neighborhood search (DNS) strategies, along with a heuristic based on current operational practice.

3

The second contribution of this research is extending the IAOP model and solving the IAOP with split loading (IAOP-SL).

Numerical results from the IAOP-SL are

compared to the IAOP, demonstrating the improvement gained by allowing split loads. Permitting split loads significantly increases the complexity of the problem, while allowing for the possibility for improved solutions.

The solution representation is

augmented to include the current partition of each customer request and neighborhoods that split and merge customer requests are implemented. The solution representation is implicitly designed to efficiently handle split loads when compared to traditional representations using disjoint numerical permutations since the smallest element of the solution representation is the pickup or delivery of a single unit of cargo from a customer request. By keeping track of the partition of each customer request, the algorithm only considers the current set of split loads at each iteration. The final contribution of this research is the extension of the IAOP to consider rolling time horizons, solving the problem starting from an existing solution from a previous time step.

At each time step, the search incorporates newly available

information and considers the existing solution from the previous time step. A cost is associated with any change to the existing solution. Therefore, such costs must be weighed against benefits from covering additional customer requests. This work builds on the MASTS software framework written in Java (Ciarleglio 2007; Ciarleglio 2008) which provides an advanced TS engine that includes solution hashing to detect cycles, adaptive tabu tenure (TT), reactive diversification strategies, dynamic neighborhood selection (DNS) strategies, parallel processing, rule based 4

objectives, traversal of infeasible regions, and a user interface that allows interaction during the search. The software also provides the structure necessary to create all basic elements of the search such as the solution representation, adjacent solutions for implemented neighborhoods, and the presentation of results.

1.3 Summary Chapter 2 describes relevant background information for the IAOP, including current operational practice, a more detailed problem description, an exact classical integer programming formulation, and a literature review. Chapter 3 describes the model and algorithm implemented to solve the IAOP along with numerical results. Chapter 4 extends the IAOP to allow split loading and provides a numerical comparison with the results in Chapters 3. Chapter 5 extends the IAOP to consider a rolling time horizon, providing a proof-of-concept for a more usable planning tool. Chapter 6 provides a summary of this research along with possible improvements and extensions to this work.

You will not find it difficult to prove that battles, campaigns, and even wars have been won or lost primarily because of logistics. - General Dwight D. Eisenhower

5

CHAPTER 2 BACKGROUND This chapter describes relevant background for the Intratheater Airlift Operations Problem (IAOP). The following sections include the process for planning and executing missions by Air Mobility Command (AMC) aircraft to support intratheater airlift operations, a detailed problem description of the IAOP, an integer programming formulation of the IAOP, and a literature review which includes important related published research. Intratheater operations are limited as an operational area under a single geographic command, such as Central Command (CENTCOM) (AFDD:2-6 2006).

1.1 Current Practice to Solve the IAOP The Theater Direct Delivery (TDD) cell within the Air Mobility Command (AMC) supports airlift requests in theaters of operation by moving intratheater cargo requests, mostly pallets (PAL) and passengers (PAX).

This relationship evolves as

conditions in theater change. TDD also has access to other assets: additional military (organic) aircraft scheduled by other AMC directorates may become available after completing their given missions. The planning process for TDD begins in a theater distribution center. The first step is to determine the PAX/PAL requests for airlift in theater using AMC assets, i.e., large bodied aircraft such as the C-17 or C-5. Customers input mission essential requests for transportation into the Intratheater Airlift Request System (ITARS). Separate from ITARS, ports also in-process other random cargo for transport to given destinations. If

6

port on-hand cargo levels become excessive or the nature of the cargo requires large body aircraft, TDD can schedule missions to fulfill those requirements. To assign cargo on TDD aircraft, the information that identifies the requests to be moved on AMC assets is compiled according to several attributes: 

Priority level from 1 to 10;



Estimated number of pallets (PAL);



Estimated tonnage;



Number of passengers (PAX);



Aerial port of embarkation (APOE);



Aerial port of debarkation (APOD);



Available Load Day (ALD); and



Required Delivery Day (RDD). This list of requests is updated daily and the updates can include new entries or

changes to existing requests, such as a change in the size or delivery time window. After the TDD receives this list from the theater distribution center, the actual mission planning begins. TDD relies on a graphical representation of all current and future planned missions as a tool to see mission details in an organized format. This helps TDD to organize currently scheduled missions and make decisions to add or adjust missions when necessary.

7

Figure 1: Representation of the Planned Missions As shown in Figure 1, the schedule is broken down by day, detailing missions as blocks of time, and also indicates when certain aircraft are unavailable. Each mission also contains information describing the route, cargo, start times, and any other necessary details. The TDD cell is comprised of planning and execution functions. Both planning and execution desks are manned 24 hours a day. 2.1.1 Objective The TDD objective is to support intra-theater airlift. From the perspective of troops in theater, it is critical to have effective airlift. This means getting the right cargo to the right place at the right time. For TDD, planners are also concerned completing the mission efficiently in terms of utilization rates and number of aircraft used.

8

2.1.2 Inputs The current TDD mission scheduling process consists of planning and execution, with input from several external sources. External inputs include: 

Scheduled channel missions to deliver on-hand cargo;



On-hard cargo levels;



List of priority shipments to be scheduled;



Theater data/Constraints; and



Higher priority conflicts. On-hand cargo levels are constantly monitored and can be accessed through an

online database system. TDD schedules channel missions to haul on-hand cargo. These missions are created based on on-hand cargo levels and historic TDD mission data. TDD schedules these missions from 1-4 weeks in advance, as opposed to 1-7 days for ITARS missions carrying specific priority cargo. TDD and the theater distribution center also coordinate to create a list of shipments. This list contains priority shipments to be scheduled by TDD. Several theater specific constraints limit TDD planning. Each port within the theater has unique characteristics: operating hours, maximum-on-ground (MOG), and aircraft suitability. A port’s operating hours define when aircraft are allowed to land or takeoff. The MOG level at each port describes the port’s maximal capacity to park and service aircraft. Each port might have unique circumstances to consider that could alter its suitability for different aircraft. For example, a port may have a gravel runway that requires re-grading following a given number of landings by wide body cargo aircraft before operations can resume. 9

Higher priority external conflicts can require the use of TDD aircraft on a temporary basis.

For example, a conflict can be an aero-medical evacuation or a

distinguished visitor. 2.1.3 Planning Function Actual scheduling starts with the mission planners. These personnel are in charge of adding new missions to the schedule and adjusting the schedule due to unforeseen changes, such as execution delays, aircraft availability, or higher priority requests. The bulk of the planning typically occurs between two weeks and 72 hours before execution. Similar to domestic airlines’ operations, delays in execution ripple through the schedule causing later missions assigned to the delayed aircraft to be pushed back. In some instances, this simply changes the start time of the next mission; but sometimes later missions must be cancelled due to current delays. Aircraft can become unavailable due to maintenance, aircrew needs, diplomatic clearance restrictions, weather, MOG restrictions, cargo handling maintenance, or unpredicted cargo fluctuations. Aircraft can be temporarily assigned to other higher priority missions such as Aerial Evacuation (AE) of wounded personnel. For example, an aircraft might be reassigned to take injured American troops from a port in Iraq to Germany. In this case, that aircraft would be unavailable for several days. The arrival of higher priority requests might also force a mission planner to reschedule currently scheduled missions in order to accommodate the new cargo.

10

Mission planners use several traditional rules to try to improve the scheduling process. 

Only schedule given percentage of aircraft;



Leave slack (“holes”) in the schedule prior to 48 hours before execution; and



Plan extra slack time (“gaps”) between missions. Based on the historic utilization rates of C-17 aircraft, planners try to schedule a

similar percentage of their aircraft. The extra aircraft are only used when necessary, but often must be used due to unexpected changes. Also, planners try to leave gaps in the schedule until the day before execution. This allows planners the ability to add a mission on the day before execution in a required time slot without adjusting any other missions. Planners adapt to accommodate situations where the schedule gets overloaded with more than the expected number of aircraft unavailable, or if the aircraft scheduled are full and additional high priority requests appear in the system. Planning a new mission to cover existing requests is accomplished with a greedy algorithm in which the most important requests are considered first. Referencing the graphical schedule representation, planners sort the list of requests by priority and then by time window. A mission is tentatively planned that fills an open time in the schedule, comprised of required cargo from the top of the sorted list, along with any other cargo that can fit on the aircraft or be carried by scheduling additional legs. The planner conducts several checks on mission feasibility. First, individual airfield limitations are considered, i.e., unique operating hours, suitability, MOG over the projected usage period and any other special considerations. The planned mission time

11

is calculated by estimating the required flight times using historic data and estimating port “turn times” based on necessary operations at each stop and the port location. The planner must assure that mission time will not violate Crew Duty Day (CDD) restrictions which are 18 hours for a standard crew and 24 hours for an augmented crew with additional personnel. Airfield landing permissions must be obtained before the mission starts. Finally, any required diplomatic clearances from involved sovereign entities must be secured by sending requests to a specific cell which manages this issue. Obtaining clearances can require anywhere from a few days to weeks depending on cargo characteristics and the entity involved. After completion of the above process, the schedule is updated with the added mission information.

Missions are added until all current requests are covered or

available aircraft are exhausted. 2.1.4 Execution Function Unlike other AMC mission directorates, both the planning and execution functions reside within TDD. Each TDD mission is monitored at the execution desk from 24 hours before takeoff to mission termination. The execution desk coordinates with theater personnel and the TDD planner to minimize disruptions to the schedule due to unforeseen changes while delivering as much of the required cargo as possible. For example, if a high priority cargo aircraft becomes unavailable, other lower priority cargo aircraft can be reassigned.

12

Changes closer to mission start time require more effort for obtaining modified diplomatic clearances and airfield landing permissions. Air crews must be notified of changes within 16 hours and flight managers responsible for monitoring individual aircraft must be notified if changes occur within 6 hours of takeoff. Some changed missions cannot be rescheduled in the current time frame and must be placed back in the scheduling queue. The small size of TDD has historically allowed significant flexibility in adjusting due to the inherent uncertainty in the mission scheduling process.

2.2 Problem Description The IAOP consists of a set of locations, a fleet of vehicles, and a dynamically changing list of customer requests to be fulfilled by scheduling routes. In the following section we describe and define a simplified problem in which all data is known at the beginning of the problem and we do not consider a rolling time horizon, but rather a single, fixed planning horizon.

For further reference, we describe solving a small

example using current manual planning methods in 0. A TS-IAOP approach to the IAOP has been successfully implemented to solve the static version of the IAOP, which contains a fleet of aircraft, multi-commodity pickup/delivery requirements, port capacity constraints, and considers several constraints on aircraft load capacity. The IAOP is a variant of the NP-hard, multi-trip, multi-vehicle, pickup and delivery problem with time windows (PDPTW) over a set time horizon. There are several associated assumptions, some of which are relaxed in the TS-IAOP. The IAOP constraints and assumptions are:

13

SHIPMENT & AIRCRAFT CONSTRAINTS 

Shipment time windows [ALD, RDD];



Pickup and delivery (precedence constraints);



Aircraft capacity (weight and volume);



Aircraft route duration limit (time);



Multiple cargo types (pallets and passengers);



Prioritized cargo; and

PORT CONSTRAINTS 

Port aircraft capacity constraints (MOG).

ASSUMPTIONS 

All problem data is known with certainty at the beginning of the problem.



Each vehicle has a release time before available (currently busy).



No vehicle delays or breakdowns are considered.



All customer requests are defined in minimal units (integer).



Shipment time windows are wide compared to vehicle travel times and route duration limits.



The availability of required vehicle crews is not a limiting constraint.



The total required capacity of customer requests is larger than available vehicle capacity over the time horizon.



The locations of customer requests strongly overlap; all requests are associated with two or more aerial ports.



The aircraft fleet is homogeneous.



Split loads are allowed.

14

2.2.2 Traditional MIP Formulation We formulate the IAOP as an extension of the general PDPTW described in (Ropke and Pisinger 2005). This model serves as a precise mathematical description of the IAOP. This model will not be directly used for a classical mathematical programming solution approach to the IAOP because the great complexity and dimensionality of practical instances of the NP-hard IAOP precludes any successful implementation of such classical approaches. The classical formulation will, however, form the foundation for a complete and consistent formulation of the TS-IAOP. The IAOP is based on the well-known pickup and delivery problem with n requests and m vehicles. The problem can be defined over a graph with P  1,.., n pickup nodes and D  n  1,..,2n delivery nodes. A request is defined by nodes i and j which are members of P and D respectively. The following notation describes the PDPTW formulation: INDICES

i

shipments

k

vehicles

r

routes

SETS

P

set i  P of pickup nodes, i  1,.., n

D

set i  D of demand nodes, i  n  1,..,2n

K

set k  K vehicles. K  m

Ki

subset Ki  K vehicles that can serve request i

15

Pk

subset Pk  P pickups that can be serviced by vehicle k

Dk

subset Dk  D deliveries that can be serviced by vehicle k

N

set of nodes N  P  D

Nk

set of nodes N k  Pk  Dk

Type set u  Type   pal , pax of commodity types

Dim set v  Dim  wt, volof capacity dimensions R

set r  R routes. R  q , (max number of routes for a vehicle with a given time horizon)

GRAPH G  (V , A)

 kr

 kr  2n  k  r , start node of vehicle k on route r, k  K , r  R

 kr

 kr  2n  m  q  k  r , end node of vehicle k on route r, k  K , r  R

V

 } set of nodes V  N  { 1,.. mq }  { 1,.. mq

A

set of arcs A  V V

VEHICLE SUBGRAPH Gk  (Vk , Ak )

Vk

} set of nodes Vk  N k  { k 1,.., kq }  { k1,.., kq

Ak

set of arcs Ak  Vk Vk

DATA

d ij

distance (i, j )  A , d ij  0 , satisfies triangle inequality

tij

travel time (i, j )  A , tij  0 , satisfies triangle inequality

si

service time for request i , i V

 ai , bi  time window for request i , i V

16

liuv

load of type u and dimension v for request i , li  0 i  P, u  Type, v  Dim ,

liuv  liuvn i  D Ckuv

capacity of type u and dimension v for vehicle k, k  K , u  Type, v  Dim

wi

priority for request i , wi  0 , i  P

RDk

route duration limit for each vehicle k , k  K

DECISION VARIABLES

xijk

1 if vehicle k travels on the edge between node i and node j, 0 otherwise

i, j V , k  K Sik

time vehicle k starts service at node i , i V , k  K

Luvik

upper bound on goods of type u and dimension v on vehicle k after servicing node i , i V , k  K , u  Type, v  Dim

zi

1 if request i is not serviced, 0 otherwise, i V

17

FORMULATION

min  



x

 zi  1

x ,S , z

kK ( i , j )A





dij xijk    S k  a k    wi zi kK

(2.1)

iP

i  P

(2.2)

  x j , n  i ,k  0

k  K , i  Pk

(2.3)



x k , j ,k  1

k  K

(2.4)



xi , k ,k  1

k  K

(2.5)

k  K , j  N k

(2.6)

Sik  si  tij  S jk  M (1  xijk )

k  K ,  i, j   Ak

(2.7)

ai  Sik  bi

k  K , i Vk

(2.8)

Sik  Sni ,k

k  K , i  Pk

(2.9)

uv uv xijk  1  Luv ik  l j  L jk

k  K , u  Type, v  Dim

uv Luv ik  Ck

k  K , i Vk , u  Type, v  Dim (2.11)

Luvkr k  Luvkr k  0

k  K , r  R, u  Type, v  Dim

(2.12)

Si kr  Si kr  RDk

i Vk , k  K , r  R

(2.13)

xijk 0,1

k  K ,  i, j   Ak

(2.14)

zi 0,1

i  P

(2.15)

Sik  0

k  K , i Vk

(2.16)

Lik  0

k  K , i Vk

(2.17)

ijk

kKi jN k

x

ijk

jVk

jVk

jPk  k 

jDk  k 

x

iVk

ijk

  x jik  0 iVk

(2.10)

The objective minimizes a weighted sum of the total distance, the total time, and the number of undelivered requests. This is a generalized objective, but achieves the

18

overall goal of maximizing effectiveness and efficiency; in later sections we will introduce several specific measures within a multi-criteria objective. Constraint (2.2) ensures that either a request is scheduled or it is a member of the unassigned requests. Constraint (2.3) ensures that the delivery location is visited if the pickup location is visited. Both visits must happen on the same vehicle. Constraints (2.4) and (2.5) ensures that each vehicle leaves its starting location and returns to its ending location. Constraint (2.6) enforces flow balance for each node visited. Constraint (2.7) ensures the node start time at any node is greater than the previous node start time plus the service time and the travel time. Constraint (2.8) enforces time windows. Constraint (2.9) ensures that each pickup happens before the corresponding delivery. Constraints (2.10), (2.11), and (2.12) ensure the load variable is correctly set. A vehicle must start and end empty and loads must be less than vehicle capacity. This formulation extends the general PDPTW in several ways. Capacity is a two dimensional constraint in terms of weight and volume. Also, each request is comprised of two commodity types, pallets and passengers. Each request has a priority level, which is manifest as a multiplier in the objective function. Each vehicle can be scheduled for multiple routes up to a given time horizon. Each route has an associated duration. 2.2.3 Unimplemented constraints Several of the constraints present in the IAOP are not explicitly considered in the above formulation. They are considered in the TS-IAOP. Adding these constraints to the traditional IP formulation would bring additional complexity to the model.

19



Port capacity



Vehicle configurations



Split Loads However, the addition of these constraints completes the practical formulation of

the IAOP. Each port location also has constraints regarding capacity. Vehicles have set configurations that can fit different numbers of pallets and passengers.

Customer

requests can be split between routes or vehicles. One approach would be to model shipments as individual shipment elements and provide incentive in the objective to keep shipment elements together. However, this would significantly increase the dimensions and complexity of the problem. Also, when considering the IAOP over a rolling time horizon, we must also consider the previous solution when building the current solution to account for the cost to change the plan.

2.3 Literature Review This section discusses recent literature related to vehicle routing problems with time windows (VRPTWs), pickup and delivery problems with time windows (PDPTWs), airlift operations, and TS. Cordeau, Laporte, and Mercier (2001) present a TS heuristic to solve general vehicle routing problems with time windows (GVRPTW).

These problems include

generalizations to multi-depot or multi-period VRPTWs. As in several other papers by Cordeau, the cost function is the weighted sum of violations for each constraint: time windows, load, and duration. The weights are adjusted throughout the search to balance exploration of both feasible and infeasible regions. Solution attributes defined by a given 20

customer on a given vehicle are used to control several aspects of the TS. The frequency of incorporated attributes provides input to an intelligently constructed penalty function which is added to the objective function. The authors present an update to their work (Cordeau, Laporte et al. 2004), discussing improved ways to deal with route duration constraints. The change allows route departures to be delayed if time feasibility is not affected, significantly improving the quality of computational results. Nanry and Barnes (2000) solve the multiple pickup and delivery problem with time windows (m-PDPTW) using reactive TS (RTS). This research was heavily based on the research documented in Carlton and Barnes (1996) and Carlton (1996). The heuristic constructs an initial feasible solution by inserting pickup and delivery pairs. The TS uses three neighborhoods: single paired insertion, swapping pairs between routes, and within route insertion.

Modifying Solomon’s vehicle routing problem (VRP) benchmark

problem set, they create a new benchmark problem set for the PDPTW. Cordeau, Laporte, et al. (2008) highlight advances in both modeling and algorithms for the one-to-one PDP. Most research relates to the m-PDP or m-PDPTW, with exact algorithms focusing on variants of branch-and-cut or branch-cut-and-price, while heuristics include TS, simulated annealing, and large neighborhood search (LNS). The work presented in the following chapters is comparable to recent advanced TS and contains elements similar to LNS. Crino, Moore et al. (2004) solved the theater distribution vehicle routing and scheduling problem (TDVRSP), extending Colletti’s (1999; Colletti and Barnes 2000) work in group theoretic TS (GTTS). One of the versions of Crino’s defined TDVRSP, 21

the Air Force theater distribution problem, is similar to the IAOP, with multiple trips and multiple services per customer. Lambert, Barnes et al. (2007) applied a TS approach to solve the strategic airlift problem (SAP), delivering passengers and palletized cargo from a set of locations in the United States to a foreign theater of operations with given time windows. The algorithm alternated between two phases - a mission assignment phase and a mission improvement phase - dynamically selecting the move neighborhoods. One main difference between the SAP and IAO is the number of shipments that can be assigned to a given mission. In the SAP, only a limited number of shipments could be combined on any given mission, usually only one or two, given the long flight legs required. Both the TDVRSP and the SAP assume a static problem in terms of customer demand.

Logistics ... as vital to military success as daily food is to daily work. - Capt. Alfred Thayer Mahan, Armaments and Arbitration, 1912

22

CHAPTER 3 SOLVING THE INTRATHEATER AIRLIFT OPERATIONS PROBLEM The research documented in this paper uses many of the ideas and concepts described in Moore, Barnes et al. and Burks, Moore et al. (2009; 2010) for using tabu search (TS) to solve difficult real-world combinatorial optimization problems. A solution to the intra theater airlift operations problem (IAOP) determines the routes and assignment of customer requests to a fleet of aircraft over a given time horizon. This problem and other variants comprise an ongoing challenge for United States Air Force (USAF) planners who manage detailed logistics throughout many theaters of operations. The IAOP multi-criteria objective embraces several components with the primary goal of satisfying as much of the demand as possible while minimizing cost. We first classify this problem with respect to related academic problems. The IAOP is an extension of two NP-Hard problems: the one-to-one pickup and delivery problem with time windows (PDPTW) (Nanry and Barnes 2000; Cordeau, Laporte et al. 2008) and the capacitated team orienteering problem (CTOP) (Archetti, Feillet et al. 2009). The PDPTW enforces the constraint that each customer request must be first picked up at its origin and then later dropped off at its destination within a given time window during a given route. The CTOP relaxes the requirement, found in most related problems, of fulfilling all customer requests in favor of maximizing profit while minimizing the travel cost. It also defines the problem over a fleet of vehicles which are capacitated in some regard, such as weight, volume, or route duration. The IAOP also

23

includes several additional constraints such as the maximum number of vehicles at each port, multiple commodity types, and multiple cargo bay configurations. In the following sections we will discuss the details of the problem, describe our TS approach, and present computational results.

3.1 Modeling the IAOP An IAOP solution is defined by a decision variable (DV) configuration which consists of a data structure representing the plan for the fleet, with related results, in an object-oriented hierarchy.

This modeling convention follows the framework described

and implemented by Ciarleglio (2007) and Barnes, Ciarleglio et al. (2010). Next, we provide several definitions that provide a foundation for the IAOP solution representation. 3.1.1 Definitions A shipment element is an individual pallet or a passenger and is the smallest separable unit which is part of a shipment.

Each shipment element shares the

characteristics of its “parent” shipment. A shipment is a customer request to pick up cargo, pallets (PAL) and/or passengers (PAX), at an origin and deliver the cargo to a destination. Other shipment attributes include the number of pallets and passengers, total weight, priority level, and a shipment time window defined by an available load date (ALD) and a required delivery date (RDD). A shipment can be broken down into shipment elements, and the term “shipment” may be used generically to refer to a partial shipment or a full shipment 24

(defined below).

Specific references to the type of shipment will be used when

appropriate. Each shipment’s priority applies to all of the elements in the shipment. In this model, the priority can be 1, 2, or 3, where 3 is the highest priority. Shipments may be larger than available vehicles. In this model, shipments are broken into feasible loads upon initialization. A full shipment contains the entire set of shipment elements from a customer request. A partial shipment contains a subset of a full shipment’s elements, up to and including a full shipment. A port is a location where aircraft can land and take off. All shipments originate and end at a port. A vehicle, or aircraft, has a realized cruising speed, volume and weight capacities, and a route duration limit. A vehicle is based at a home port where it begins and ends each route. Each vehicle has multiple cargo configurations that correspond to different capacities of passenger and pallet cargo. Cargo configurations are detailed in Appendix B. A route consists of a single trip by a vehicle to pick up and deliver cargo. A route may visit multiple ports, but must start and end at the vehicle’s home port and may not exceed the vehicle’s route duration limit.

Following each route, the vehicle has a

required down time for service to prepare for the next route. .

25

3.1.2 The Decision Variable Configuration The decision variable (DV) configuration provides the basis for the solution representation. Earlier research has framed the solution representation as a permutation of solution elements representing vehicles and customer requests, sometimes all in a single sequential array. The solution representation for this research uses an objectoriented data structure which resembles the actual organizational hierarchy of the routes and shipments. This data structure allows for simplified associated computer code, easier neighborhood definitions, and a greater degree of flexibility when adding new features and strategies. For our model, a DV is associated with both each vehicle and with one additional DV as the unassigned shipment element bank. For further clarification and detail, our nested hierarchical DVs are presented in Figure 2 through Figure 5.

Figure 2: Decision Variable Configuration VEHICLE DVS Each vehicle DV contains an associated vehicle and a vehicle plan, which consists of a unique time-ordered set of vehicle routes. Each route is composed of a time-ordered set of stops.

A stop is defined by a port with stipulated unload and load actions

26

corresponding to the pickup and delivery of shipments. Load and unload actions can range in size from a single shipment element to a full shipment. For a shipment to be feasibly assigned, it must be loaded at one stop and subsequently unloaded at another stop later in same route. Any shipment elements which are not assigned reside in the unassigned shipment element bank.

Figure 3: Vehicle Decision Variable

27

Figure 4: Routes and Stops within the Vehicle Decision Variable The vehicle DV is built as a hierarchical structure consisting of a vehicle plan, a route, a stop, load/unload actions, and shipments. The structure of the vehicle DV allows for many simple extensions and is essential to our neighborhood definitions. Any level of the vehicle plan can be added, deleted, or adjusted by a defined neighborhood. The hierarchical DV structure provides a simple framework to implement a complete spectrum of diversifying and intensifying solution neighborhoods. UNASSIGNED ELEMENTS BANK DV The unassigned elements DV contains an array, with each array element corresponding to a shipment element from the set of full shipments. When an element is assigned to a route on a given vehicle plan, the unassigned elements array is updated to reflect that the element is now assigned. Similarly, an element is marked unassigned when removed from the schedule. This provides a quick determination of whether a shipment element is assigned.

28

Figure 5: Unassigned Shipment Element Decision Variable 3.1.3 Hashing One important feature of this TS is the ability to quickly identify repeat solutions. The DV configuration uses the 128 bit MD5 algorithm to create “unique” hash for each solution.

Two solutions will receive different hashes unless they are completely

identical, i.e., in our application, the solution hash value is unique to any solution. 3.1.4 A Small IAOP Example For ease of explanation, we provide a small example which describes the necessary input data and provides a graphical representation of the solution. From the solution representation, we may calculate all necessary times to execute each vehicle plan and translate that information into a usable product for USAF planners. The network of ports, aircraft data, and shipment demands are detailed in Table 1 through Table 4. The port data includes the International Civil Aviation Organization (ICAO) code, the name, the location (given as latitude and longitude coordinates), the minimal aircraft-port “turn around” time, and the maximum on ground (MOG) aircraft capacity. The aircraft data includes the aircraft’s home port, release (availability) time, feasible load configurations, speed, and maximum weight. For the demand data, any full 29

shipments (FS) larger than an aircraft’s capacity have already been broken into feasible partial shipments (PS). TABLE 1: PORT DATA ICAO

Name

Lat

Long

Turn Time

MOG

OTBH OAIX OKAS ORBD

Al Udeid AB Bagram Ali Al Salem AB Balad

25.1173

51.3150

195

2

34.9461

69.2650

75

1

29.3467

47.5208

135

1

33.9402

44.3616

75

1

TABLE 2: AIRCRAFT DATA Name

Type

Aircraft 1 Aircraft 2

C-17 C-17

Home Port OTBH OTBH

Release Time (min) 0 600

TABLE 3: C-17 DATA Load Configuration 1 2 3 Speed (mph) Weight (lbs)

PAL

PAX

18 11 0

0 54 102

515 170900

TABLE 4: SHIPMENT DEMAND DATA Name

ID

Origin

PS-1a PS-1b FS-2 PS-3a PS-3b FS-4 FS-5 FS-6

1 1 2 3 3 4 5 6

OKAS OKAS OTBH OAIX OAIX OKAS OTBH OTBH

Destination PAL OAIX OAIX OKAS OKAS OKAS ORBD OKAS ORBD

1 0 3 4 0 0 2 8

30

PAX

Tons

ALD

RDD

Priority

54 13 11 54 19 21 4 0

1.2 0.0 4.3 6.0 0.0 0.0 7.7 37.1

213 213 213 213 213 213 213 215

214 214 214 215 215 218 220 216

3 3 3 2 2 1 1 2

The vehicle plan for each aircraft includes the sequence of stops, shipment pickup and delivery, and load information. As shown in Figure 6, aircraft 1 has two routes in which it services five shipments. Notice, shipments do not have to be delivered at the next stop after being picked up. Rather, intermediate stops to service other shipments are allowed. As shown in Figure 7, aircraft 2 is not available at the beginning of the scenario. In the solution presented, Shipment 6 is not delivered.

Figure 6: Aircraft 1 schedule

31

Figure 7: Aircraft 2 Schedule

3.2 Designing the TS-IAOP In this section we introduce the multi-criteria objective function and the constraints that were considered in the design and implementation of the TS-IAOP. We then outline the neighborhoods, TS strategies, and neighborhood selection strategies that were employed. 3.2.1 Objective Function Measures From solution results, we calculate various measures, shown in Table 5. We are primarily interested in effectiveness with regard to satisfying the customer and then efficiency with respect to the usage of the fleet of aircraft. We also include split load measures relevant if any of the original full shipments are larger than the vehicles and must be split into pieces to be delivered. The feasibility measures, shown in Table 6, correspond to constraint violations. Shipment pickup and delivery precedence, as well as the shipment available load date are considered hard constraints and are enforced throughout the search. 32

TABLE 5: SUMMARY OF MEASURES Effectiveness Undelivered shipments The number of undelivered shipments. To count a shipment delivered, all elements of a given shipment must be delivered. Undelivered elements The number of undelivered shipment elements. Priority weighted The number of undelivered shipments weighted by their priority. undelivered shipments Priority weighted The number of undelivered shipment elements weighted by their undelivered elements priority. Late shipments The number of late shipments. The shipment's arrival time is determined by its last element's arrival. If a shipment is undelivered, but its due date is after the scenario horizon, the shipment is not considered late. Late elements The number of late shipment elements. If an element is undelivered, but its due date is after the scenario horizon, the element is not considered late. Priority weighted late The number of late shipments weighted by their priority. shipments Priority weighted late The number of late shipment elements weighted by their priority. elements Total cumulative The total cumulative time of all shipment element lateness. Each element lateness element's lateness calculated as amount of time between due date and arrival. Efficiency Total time The amount of time vehicles are busy, including turn times at ports. Total travel time The amount of time vehicles are busy traveling between ports. Total cumulative The total cumulative time to deliver all shipment elements. Each element delivery time element's delivery time is measured as difference between the scenario start and the delivery time. If an element is undelivered, its delivery time is measured as the entire scenario duration. Split Loads Additional split loads The number of additional split loads beyond what is necessary to create feasible loads. This measure is zero unless split loading is allowed during the search. Total shipment Shipment lag is defined as the time between a shipment’s first delivery lag element arrival and each additional element’s arrival for that shipment. The lag for any undelivered element is measured as the time between the first element arrival and the scenario end time. If none of a shipment's elements are delivered, the lag is the product of the number of elements and the scenario duration.

33

TABLE 6: FEASIBILITY CONSTRAINTS AS PENALTY MEASURES Feasibility Port levels Route duration Vehicle weight Vehicle volume Scenario time horizon

The number of vehicles that are at each port at any given time. The total amount of time any route duration exceeds the maximum allowed route duration. The total amount of weight that exceeds the maximum vehicle weight over all route segments. The total amount of volume that exceeds the maximum vehicle volume over all route segments. The total amount of time in which vehicles are busy past the scenario time horizon.

3.2.2 A Constrained Multi-Criteria Objective We use a basic rule based objective to order the solution set (Barnes, Ciarleglio et al. 2010). A constrained multi-criteria objective combines elements of an objective score with a rule based objective. The score is computed as a weighted aggregate of selected measures from the tables above. The main rule is that feasible solutions are always ranked above infeasible solutions. When comparing feasible solutions, the solution with the lower score is preferred.

The search may also consider infeasible solutions, and will

prefer the solution that is “closer to feasibility” based on the constraints listed above. The multi-criteria objective minimizes effectiveness, efficiency, and split load measures. Each measure is scaled between 0-1 and has a defined weight. Table 7 illustrates the relative importance of each category, along with the individual measure importance within each category.

Note, a weight of zero means the measure is

effectively not used in the computation, but is reported as a relevant metric in the output.

34

TABLE 7: HIERARCHICAL DESCRIPTION OF WEIGHTS USED IN MULTI-CRITERIA OBJECTIVE Effectiveness (96%) priority priority priority priority weighted weighted weighted weighted undelivered undelivered late late shipments elements shipments elements 0% 90% 0% 0% 0.000 0.864 0.000 0.000

total time late elements 10% 0.096

Efficiency (3%) total total total time vehicle vehicle deliver travel time elements time 50% 40% 10% 0.015 0.012 0.003

Split Loads (1%) additional splits

total delivered shipment lag

10% 0.001

90% 0.009

We constructed the multi-criteria objective in a manner similar to the analytical hierarchy process (Saaty 1994; Moffett, Dyer et al. 2006). The bottom line of the above table gives the numerical coefficients used in the objective. These coefficients were derived by hierarchically sorting the measures based on importance according to our knowledge of the specific problem domain. The undelivered elements measure drives solutions to deliver as much as possible by minimizing the number of priority weighted undelivered elements. The efficiency measures encourage the search to minimize the total time vehicles are used, the total vehicle travel time, and to deliver all shipment elements as early as possible. While vehicle utilization is not explicitly included, by maximizing delivered elements and minimizing vehicle travel time, the vehicle utilization is implicitly maximized. The additional splits measure is always zero in the results documented in this paper since we do not allow the search to further split shipments after initialization. The effects of allowing further dynamic shipment splits after initialization are presented in 0. Finally, the delivered shipment lag encourages the search to deliver partial shipments from the same parent shipment as close as possible with one another.

35

3.2.3 TS-IAOP Neighborhoods A simple set of neighborhoods, adjusting one or more elements of the solution, served as building blocks to form larger composite neighborhoods for our search. These neighborhoods are: 

Add a shipment to a new route;



Add a shipment to an existing route by creating new stop(s);



Add a shipment to an existing route by using existing stops;



Delete a shipment; and



Delete a stop. Each neighborhood operates on an incumbent solution and generates a set of

moves that will be used to create the neighboring solutions.

The most basic

neighborhoods will only create moves for one vehicle at a time, and the neighborhood size depends on the incumbent solution. When executed, each move must update both the relevant Vehicle DV and the Unassigned Elements DV to reflect adding or deleting shipments from the schedule. Note, in the next section, 0.0.0, we describe how these neighborhoods are combined as larger composite neighborhoods that operate over the entire fleet in the TS-IAOP. ADD SHIPMENT NEIGHBORHOODS All neighborhoods adding a shipment to a vehicle’s schedule consider each partial shipment that is currently unassigned to generate the set of neighboring solutions. Any neighborhood adding a shipment is allowed to violate feasibility constraints, except for the ALD. Each neighborhood focuses on a single vehicle (and there is essentially one

36

such neighborhood for each vehicle). The moves created by these neighborhoods respect the requirement that the vehicle starts and ends at the depot. When adding a shipment to a route, the shipment is added to the load list of the stop matching its origin and the unload list of the stop matching its destination. The AddShipmentNewRoute neighborhood consists of solutions with a new route to cover one of the unassigned shipments. For each unassigned partial shipment, a new route is created containing that shipment. Each neighboring solution corresponds to inserting the new route at each possible position among the existing routes on the vehicle. If the vehicle has no assigned routes, only a single neighboring solution is created. The neighborhood creates each neighboring solution by first building a new empty route, and then adds the starting and ending stops at the depot. Any other stops that are necessary to fulfill the pickup at the shipment’s origin and the delivery at the shipment’s destination are added, i.e., one stop (either the delivery port or the pickup port) or two stops (the pickup and delivery ports) may be added. The AddShipmentNewStops neighborhood consists of solutions with new stops added to cover one of the unassigned shipments. Each neighboring solution corresponds to inserting an unassigned partial shipment on an existing route in one of three ways: (1) if a route contains a stop matching the shipment origin, but not a following stop matching the shipment destination, neighboring solutions inserting the matching destination stop are generated, (2) if a route contains a stop matching the shipment destination, but not a previous stop matching the shipment origin, neighboring solutions inserting the matching origin stop are generated and (3) all neighboring solutions inserting both stops at all 37

possible positions in the route, excluding irrelevant positions.

Irrelevant positions

include any situation in which a shipment stays on a vehicle while unnecessarily passing through the pickup or delivery port, the shipment pickup and deliver precedence is violated, or the added stops require a shipment pickup before the shipment ALD. Each neighboring solution is created by adding the necessary stops, either one or two, at the given stop indices. Note, for a given route, only logical insert locations are considered, but may correspond to different pickup/delivery pairs. For example, suppose that a route contains two stops matching the shipment origin, but no stops matching the destination. In this case, the neighboring solutions would include: (a) solutions with the destination stop insertion at any position after the first origin stop and before the second origin stop, (b) solutions with the destination stop insertion after the second origin stop, and (c) solutions in which both origin and destination stops are inserted. The first set of solutions (a) corresponds to the shipment pickup at the first existing origin stop and the second set of solutions (b) corresponds to the shipment pickup at the second existing origin stop. Since the neighborhood assumes the vehicle begins and ends at the depot, stop inserts are not allowed at the head or tail of any route. Neighbors only include those solutions feasible with respect to shipment availability, i.e., the early time window. However, vehicle capacity constraints (volume and weight) are not strictly enforced. The AddShipmentExistingStops neighborhood consists of solutions with an unassigned shipment added to existing route stops. For each unassigned partial shipment, all existing route stops matching the shipment origin/destination are considered. Each 38

neighboring solution corresponds to adding an unassigned partial shipment to existing stops matching the shipment’s origin/destination. DELETE NEIGHBORHOODS The DeleteShipment neighborhood consists of solutions in which an assigned shipment is deleted from the schedule of a given vehicle.

To generate the set of

neighboring solutions, the neighborhood iterates over the currently assigned shipments on each existing route of the vehicle. Each neighboring solution corresponds to deleting a single shipment on one of the vehicle’s routes.

Any stops are requiring no loading or

unloading cargo after deleting the given shipment are also deleted. If the route does not contain any additional shipments after deleting the given shipment, it is also deleted. Therefore, any scheduled route must have at least one assigned shipment. The DeleteRouteStop neighborhood consists of solutions in which a stop is deleted from a route of a given vehicle. To generate the set of neighboring solutions, the neighborhood iterates over each stop of each route for the vehicle. Each neighboring solution corresponds to deleting a stop and any associated shipments from the vehicle. Any shipments that are either picked up or delivered on the deleted stop are also deleted from the route. Following the stop deletion, if any other stops are empty, they are also deleted. Likewise, if the route does not contain any additional shipments after deleting the given stop, it is also deleted.

39

3.2.4 Composite Neighborhoods We create composite neighborhoods by combining specific sets of neighborhoods and using them as building blocks to implement our neighborhood selection strategies. The composite neighborhoods employed are: 

(A)

: All three add shipment neighborhoods over all vehicles;



(D)

:The delete shipment neighborhood over all vehicles;



(A/D) : Both (A) and (D); and



(R)

: The delete route stop neighborhood over all vehicles.

3.3 TS-IOAP Memory Structure To implement the TS-IAOP memory structure, we restrict neighboring solutions based on route and shipment. Since routes can be created and deleted during the search, we assign each one a unique ID to keep track of it in the tabu restrictions. Each shipment also has a unique ID. The search uses both the shipment and route IDs to determine if a given neighbor is tabu. The basic rule governing the tabu restriction is that once a shipment is either added (deleted) from a route, it cannot be deleted (re-assigned) to that route for a number of iterations specified by the tabu tenure. We implement adaptive tabu tenure (TT) with limits set as a function of the problem data (Dell'Amico and Trubian 1993). The TT is set between 20-90% of the minimum number of shipments estimated to be delivered by the given fleet in the given time frame. The initial TT is set as the midpoint of this interval. If a route is deleted from the solution, any shipment with a tabu restriction related to the route is no longer relevant.

Therefore, we implemented an additional tabu

40

restriction to directly consider the transient nature of routes as solution elements. Whenever a route is deleted, a tabu restriction prevents re-assigning the last shipment from that route to the same vehicle. This memory structure significantly decreases the chances of visiting a repeat solution following the deletion of a route.

3.4 TS-IAOP Neighborhood Selection Strategies Three dynamic neighborhood selection (DNS) strategies, Basic, Standard, and Aggressive were implemented and used. As shown in Figure 8 through Figure 10, each strategy cycles through different neighborhoods. The Basic DNS considers all possible add and delete moves at each iteration. Therefore, the search remains feasible under most circumstances since, at any iteration, a scheduled shipment may be deleted to preserve feasibility. The only way for the Basic DNS to pick an infeasible incumbent is to have an entire set of infeasible solutions in a given neighborhood. Each pattern within the Standard and Aggressive DNS executes for a given number of iterations as a function of n, where n is the number of shipments to be serviced. The Standard DNS contains repeats a basic pattern of allowing all possible add and delete moves for a given number of iterations, performing short, specific diversification actions, and finally recovering deleting stops if necessary and then by adding or deleting shipments until the schedule is full. By allowing the DeleteRouteStop (R) and the AddDeleteShipment (A/D) neighborhoods to repeat until a disimproving move is selected, the search is able to find a feasible solution if infeasible.

The

Aggressive DNS builds on the Standard DNS by including an escape sequence to

41

diversify the search if a new best solution has not been found in a specified number of iterations based on the problem size. The diversification sequence consists of repeating the DeleteRouteStop neighborhood such that approximately 5% of the stops are removed from the solution. Legend A Add shipment D Delete shipment A/D Add or delete shipment R Delete route stop

Figure 8: Basic Dynamic Neighborhood Selection Strategy

Figure 9: Standard Dynamic Neighborhood Selection Strategy

42

Figure 10: Aggressive Dynamic Neighborhood Selection Strategy

3.5 TS-IAOP Results In this section we briefly describe the datasets constructed to evaluate our algorithm and then compare results from the three different search strategies. 3.5.1 Data The data sets used to evaluate the algorithm are based on historical data provided by the USAF Air Mobility Command (AMC) over a six month time period. The data includes 9790 unique customer requests with locations throughout the Middle East, as well as ports in the US, Europe, and Africa. Five ports with undocumented locations (with only 22 total associated deliveries) were removed. Since the focus of this research is on intratheater airlift, 206 deliveries to or from locations outside of the C-17 range

43

from the home port in Qatar were removed. These actions left 9562 deliveries between 46 ports in a 6 month dataset. The original data is based on what was flown, not on the actual customer requests. This required some reconstruction of the data, including the priority level and time window for each shipment. Since actual shipment priority levels are unknown, each shipment was randomly assigned a priority level from 1 to 3 with 1 being the least important. Time windows were constructed to match their priority level, with generally shorter time windows for higher priority shipments. The shipment time windows were assigned as follows: 

1 day for priority 3 shipments;



1-2 days for priority 2 shipments; and



3-7 days for priority 1 shipments. For our experiments, we built eight scenarios, shown in Table 8. Each scenario

spans 72 hours, matching the horizon utilized by USAF planners in current planning and scheduling efforts. Each scenario consists of a given customer demand of shipments broken down into the total number of pallets, passengers, and total tonnage. The first five scenarios have three available C-17s and maximum on ground (MOG) port capacity of 1 for all ports. The last three scenarios are similar in size to historical data with higher demand, 10 available C-17s, and MOG of 3.

44

TABLE 8: DESCRIPTION OF SCENARIOS Label Scenario 1 Scenario 2 Scenario 3 Scenario 4 Scenario 5 Scenario 6 Scenario 7 Scenario 8

Vehicles 3 3 3 3 3 10 10 10

MOG 1 1 1 1 1 3 3 3

Shipments 52 62 53 43 45 121 178 160

Pallets 218 258 223 109 125 494 664 456

Passengers 1400 1654 1145 1064 942 2641 3927 6242

Tons 495.234 576.65 485.813 208.544 256.865 1113.956 1407.432 951.707

3.5.2 Assumptions We made several simplifying assumptions. We assume all problem data is known with certainty at the beginning of the problem with no vehicle delays or breakdowns. We assume we have an adequate number of available crews and do not attempt to solve the crew scheduling problem. However, the crew duty day restricts the route duration to 16 hours.

The tonnage of a shipment is distributed evenly over the set of pallets with an

assumed weight of 250 lbs. for each passenger. We assume all flight segments are short enough that mid-air refueling is not required and that fuel does not further limit the payload of the aircraft. This assumption is valid since we are not considering longer strategic flight segments (e.g., Kuwait to Germany). 3.5.3 Experimental Results While TS-IAOP can start from any given solution, all runs were initialized from an empty solution in which none of the shipments are scheduled for pickup and delivery. A separate single pass greedy heuristic was also implemented to provide a baseline. The greedy heuristic uses the composite add neighborhood (A), as defined previously, and

45

continues adding shipments to the schedule one by one until no improving solutions can be found. For comparison to current practice, vehicle schedules are currently solved manually with a single planner continuously working until the schedule for the next 72 hours is constructed. Since it is difficult to manage the several complicated constraints of the problem, planners are only able to consider a limited number of possibilities when adding any given shipment to the schedule. To compare different search strategies, we ran Scenarios 1-5 for 50,000 iterations, evaluating between 2-7 million solutions. Scenarios 6-8 were run for 20,000 iterations, evaluating between 85-400 million solutions. For the first five scenarios we were able to find an initial solution in seconds using the aforementioned greedy heuristic, while finding a greedy solution for the larger scenarios took 5-10 minutes. Each run was performed on a machine with dual 6-core 2.61 GHz processors (12 execution threads) and 16 GB of memory. The java virtual machine version was 1.6.0_21 with 2 GB of memory allocated. A summary of the results for Scenarios 1-5 is presented in Table 9. The objective value and related measures for the initial empty solution and the best solutions found by each DNS are shown along with relevant run statistics.

Note the first four measures

relating to shipments and shipment elements are weighted by priority, similar to the objective described in Section 3.2. Also note the objective score for any initial solution is less than one since all none of the aircraft are used and some of the undelivered shipments are not considered late. For a solution to have a score of 1 would require all 46

aircraft to be flown nonstop with no cargo for the entire planning period and all shipments to be due before the beginning of the scenario. Comparing the initial solutions, Scenario 1 seems to be the most capacitated since it has the highest number of undelivered elements. Scenario 5 was the only one in which we found a solution that delivered all shipments. All other scenarios could not deliver all requested shipments. As expected, each DNS strategy was able to find significant improvements over the greedy heuristic. In four scenarios, the Standard DNS found the best known solution, while the Aggressive DNS strategy achieved the best solution for a single scenario. This can be attributed to the balance between mining a given area of the solution space and diversifying to find other possibly productive regions of the solution space. Given longer runs, the Aggressive DNS strategy should outperform the Standard and Basic DNS strategies since it has increased flexibility to diversify away from unproductive regions of the solution space. A summary of the results for Scenarios 6-8 is shown in Table 10. The greedy heuristic was unable to find solutions that fully utilized all available aircraft due to conflicting constraints for Scenario 6 and 8, which accounts for the lower travel time. The Standard DNS strategy again found the best solution in two of the three scenarios, with the Aggressive DNS strategy finding a slightly better solution in Scenario 6. For most of the solutions found, the search was not only able to increase the number of shipment elements delivered, but also decrease overall lateness.

47

Run times varied from 8 to 56 minutes for Scenarios 1-5 and 1.5 to 13 hours for Scenarios 6-8. The total number of evaluations performed over the duration of the search varied with the neighborhood size at each iteration. Scenarios with more shipments left unassigned had larger neighborhoods due to the increased number of possibilities to insert a shipment. Such scenarios required longer run times. The Basic DNS strategy generally took longer than the other two search modes which used smaller neighborhoods during some iterations.

48

TABLE 9: RESULTS FOR SCENARIOS 1-5 Multi-criteria Objective metrics

Initial Soln

0.89182

Greedy

0.16730

42

591

13

384

1.98E+05

13398

6259

4.83E+06

Basic

0.12084

28%

29

405

18

256

6.81E+04

13351

5743

4.57E+06

0:56:27

1.07E+08

5

412

Standard

0.11181

33%

25

367

16

184

4.57E+04

13234

6012

4.74E+06

0:42:11

8.03E+07

244

1431

32%

0:45:30

8.63E+07

248

1309

Scenario 5

Scenario 4

Scenario 3

Scenario 2

Scenario 1

DNS

Objective Improv

Aggressive

0.11353

Initial Soln

0.89036

Greedy

0.10086

Basic

0.08378

17%

Standard

0.07181

29% 25%

Aggressive

0.07614

Initial Soln

0.89408

Greedy

0.08609

Basic

0.07333

15%

Standard

0.07099

Priority Weighted Undelivered Elements 3637

Run Information

Priority Weighted Undelivered Shipments 104

Priority Priority Total Time Weighted Weighted Late Total Travel Late Elements Late Shipment Time * Time * * Shipments Elements 50 1195 1.15E+06 0 0

Total Time Deliver Elements *

Time (hh:mm:ss)

Total Evals **

Repeat Incumbents

Infeasible Incumbents

6.99E+06

39

374

17

271

6.81E+04

13347

5820

4.66E+06

119

3439

51

1544

1.24E+06

0

0

8.26E+06

45

308

16

48

2.93E+04

12964

6107

3.86E+06

30

241

20

183

6.43E+04

13517

5957

3.75E+06

1:03:39

1.05E+08

17

48

23

196

10

202

3.73E+04

13249

5759

3.70E+06

0:43:40

7.27E+07

358

1270

0:44:23

7.33E+07

410

1269

28

211

20

130

6.76E+04

13188

5817

3.86E+06

102

3071

50

1685

1.11E+06

0

0

5.91E+06

38

222

10

63

1.77E+04

13315

5883

3.81E+06

26

178

9

548

3.14E+04

13389

5497

3.90E+06

0:38:22

8.26E+07

5

522

18%

22

169

9

356

3.55E+04

13241

5843

3.73E+06

0:31:03

6.62E+07

287

1084

20%

15

160

15

71

3.78E+04

13450

5934

3.72E+06

0:32:05

6.97E+07

385

899

83

2221

35

790

6.67E+05

0

0

5.07E+06

Aggressive

0.06907

Initial Soln

0.88863

Greedy

0.04325

8

56

2

18

2.25E+02

12779

5112

2.59E+06

Basic

0.03306

24%

6

28

3

24

1.21E+04

13105

5495

2.73E+06

0:16:25

3.81E+07

64

157

Standard

0.03177

27%

6

24

10

117

9.01E+03

13488

5763

2.76E+06

0:12:17

2.85E+07

759

1428

24%

0:12:29

2.91E+07

349

1469

Aggressive

0.03306

Initial Soln

0.90062

Greedy

0.03096

Basic

0.02476

20%

Standard

0.02223

28%

Aggressive

0.02530

18%

8

27

12

150

1.24E+04

13397

5729

2.72E+06

87

2282

41

1487

1.18E+06

0

0

4.61E+06

9

20

13

173

7.64E+04

13387

5486

2.04E+06

6

6

15

71

4.48E+04

13392

5484

2.00E+06

0:11:34

2.85E+07

15

61

0

0

2

126

1.66E+04

13220

5645

2.35E+06

0:07:55

1.89E+07

1104

1315

2

5

12

167

7.06E+04

13251

5612

2.24E+06

0:08:36

2.10E+07

900

1252

50K iterations; * times measured in minutes; **total evaluations vary based on size of neighborhood at each iteration

49

TABLE 10: RESULTS FOR SCENARIOS 6-8 Mul ti-cri teri a Objective metri cs DNS

Scenario 6

Initial Soln 0.89487

Scenario 7

239

6160

116

3013

2.66E+06

0

0

Time

Evals ***

Repeat Infeasible Incumbents Incumbents

1.35E+07

Greedy

0.08101

29

430

18

162

7.08E+04

38529 14528

7.70E+06

Basic

0.07646

6%

22

382

18

162

7.08E+04

43483 16964

7.57E+06

2:01:34 1.14E+08

8

0

Standard

0.07410

9%

21

366

19

179

7.95E+04

42688 16849

7.64E+06

1:33:17 8.53E+07

23

1206

Aggressive 0.07405

9%

21

366

25

188

8.21E+04

42289 17272

7.55E+06

1:33:50 8.71E+07

18

1660

341

8883

170

3773

3.47E+06

83

1276

47

624

2.57E+05

44638 19225

1.24E+07

Initial Soln 0.89278

0

0

1.98E+07

Greedy

0.14899

Basic

0.14525

3%

77

1237

41

602

2.29E+05

44638 20095

1.23E+07

8:18:28 2.90E+08

6

0

Standard

0.13942

6%

51

1182

42

527

1.85E+05

44777 19886

1.23E+07

5:17:00 1.83E+08

29

1330

Aggressive 0.14100

5%

64

1199

45

548

1.94E+05

43485 19148

1.23E+07

5:36:31 1.94E+08

34

1448

343

14849

186

7268

5.33E+06

165

6061

85

2804

1.25E+06

26713 11917

2.14E+07

Initial Soln 0.89370

Scenario 8

Run Informa tion

Late Late Total Time Total Travel Total Time Undelivered Undelivered Objective Improv Shipments Shipment Late Time Time Deliver Shipments * Elements * * Elements * Elements ** ** ** Elements **

0

0

2.89E+07

Greedy

0.37531

Basic

0.33186

12%

117

5205

79

2738

1.20E+06

44114 17813

2.04E+07

18:11:36 3.93E+08

6

0

Standard

0.32477

13%

101

5099

79

2689

1.12E+06

42536 17810

2.00E+07

12:59:34 2.94E+08

9

2497

Aggressive 0.32911

12%

110

5178

74

2681

1.13E+06

41668 17178

2.00E+07

13:01:14 2.98E+08

16

2270

20,000 iterations; * weighted by priority; ** times measured in minutes; ***total evaluations based on size of neighborhood at each iteration

50

3.5.4 Search Trajectory Output Along with the results of the best solution for each scenario and search mode, we also recorded information relating to search trajectory, including the incumbent objective score, feasibility, and whether the incumbent was a new best solution or repeat solution. For Scenarios 1-5, the Basic DNS strategy visited infeasible solutions less than 1% of the time, while the Standard and Aggressive DNS strategies visited infeasible solutions between 5-10% of the time. For Scenarios 6-8, the Basic DNS strategy never visited infeasible solutions, while the Standard and Aggressive DNS strategies visited infeasible solutions between 2-5% of the time. Interestingly, the Aggressive DNS strategy often dominated the Standard DNS strategy early in the search, finding better solutions after a diversification trigger, but seemed to eventually get overtaken by the Standard DNS strategy. This highlights the tradeoff between intensification and diversification in any local search. As expected, the ability to traverse infeasible regions often allowed the search to find better solutions. As a representative example, the search trajectories for Scenario 1 are shown in Figure 11 and Figure 12.

51

52

Figure 11: Scenario 1 search trajectories for Basic, Standard, and Aggressive DNS strategies NOTE: Solution evaluations are a function of the number of iterations and the number of solutions in each neighborhood. We report solution evaluations since computational difficulty is more directly related to solution evaluations versus number of iterations.

53

Figure 12: Best Solution for Scenario 1 during search for each DNS strategy 3.5.5 Additional Airlift Metrics In the results presented, we have shown improvement in the number of shipment elements delivered.

We describe several metrics more specific to airlift to further

quantity the benefit. As shown in Table 11, an increased number of shipment elements delivered roughly translates into an improved cargo velocity, measured in ton miles per hour (TM/hr). This metric is calculated by summing the ton miles of demand delivered and dividing by the length of the scenario. Given each scenario is limited to a fixed time horizon of 36 hours, most solutions fill up the allotted time with similar results for available ton miles, a measure of the network capacity, but more effective solutions tend to increase the amount delivered. Extending these results over time could translate into 54

either a significant gain in network capacity, or the ability to satisfy the same demand using less aircraft, tasking some assets to other urgent needs. For example, given a similar fleet of 10 C-17 aircraft operating for a month, with a demand of 9,000,000 TM, improving the cargo velocity by 600 TM/hr translates to an additional 432,000 TM delivered in the same time frame. TABLE 11: METRICS RELEVANT TO AIR MOBILITY COMMAND FOR SCENARIOS 6-8 Available Ton Miles

DNS

Scenario 6

Initial Soln

Scenario 7

Total cost for flight hours *

$/RTM

Cargo Velocity TM/hr

Improv

8.11E+05

Greedy

7.46E+06

5.30E+05

$ 3,147,733.33

5.94

7356

Basic

8.78E+06

5.74E+05

$ 3,675,533.33

6.40

7972

8%

Standard

8.68E+06

5.82E+05

$ 3,650,616.67

6.27

8081

10%

Aggressive

8.97E+06

5.82E+05

$ 3,742,266.67

6.43

8081

10%

Initial Soln

9.38E+05

Greedy

1.02E+07

7.53E+05

$ 4,165,416.67

5.54

10452

Basic

1.06E+07

7.64E+05

$ 4,353,916.67

5.70

10613

2%

Standard

1.03E+07

7.86E+05

$ 4,308,633.33

5.48

10919

4%

Aggressive

9.96E+06

7.15E+05

$ 4,148,733.33

5.80

9933

-5%

Initial Soln

Scenario 8

Delivered Required Ton Miles

9.35E+05

Greedy

6.14E+06

5.38E+05

$ 2,582,016.67

4.80

7471

Basic

9.16E+06

7.15E+05

$ 3,859,483.33

5.40

9927

33%

Standard

9.18E+06

7.36E+05

$ 3,858,833.33

5.25

10216

37%

Aggressive

8.81E+06

7.40E+05

$ 3,721,900.00

5.03

10281

38%

Initial Solution shows total undelivered ton mile demand; * assume $13K / flt hr

3.6 Extensions Several immediate extensions for the IAOP exist to explore in further research. In this chapter, we have not allowed shipments to be split into smaller pieces during the search. Allowing split loads could further increase the solution quality while adding to the computational complexity.

This is a reasonable extension that could also be 55

implemented in practice for the IAOP. Another extension would be to consider solution persistence in the objective. In practice, solutions must build upon previously built schedules over a rolling time horizon. A new solution must consider the amount of change from the solution at the previous time step and cannot arbitrarily change the entire solution. These extensions are explored in the following chapters.

3.7 Conclusions This chapter presented a tabu search algorithm to solve an extension of the pickup and delivery problem that includes several difficult constraints and a comprehensive multi-criteria objective. The problem data and constraints relate directly to an airlift scheduling problem tackled daily by military planners. Several search strategies were explored and the results of each were compared, showing significant improvement in the quality of the solutions obtained.

Forget logistics, you lose. - Lt. Gen. Fredrick Franks, USA, 7th Corps Commander, Desert Storm

56

CHAPTER 4 THE IAOP WITH SPLIT LOADS An extension of the classical vehicle routing problem (VRP) is to allow split load deliveries of customer requests, allowing a shipment to be split into two or more subloads which are delivered separately to the customer. The split load relaxation, while significantly increasing the complexity of the problem, allows for possible improvement in the solution. As detailed in the previous chapter, split loading is appropriate in the airlift context since each shipment is composed of a finite set of indivisible elements and shipments are located at a finite set of ports. This chapter discusses the implementation of split loading within the IAOP, describing necessary changes to both the model and algorithm.

Results for the IAOP with Split Loads (IAOP-SL) are presented and

compared to the IAOP results. Dror and Trudeau (1989) formalized the split delivery (i.e., load) VRP (SDVRP), which relaxes the traditional VRP to allow customers to be serviced by one or more vehicles and introduced a heuristic to solve the problem. Archetti and Speranza (2008; 2012) provide a survey of the SDVRP, including a brief history of recent research, a discussion on the problem complexity and properties, a classical mathematical programming formulation, and a comparison of recent heuristic and exact approaches. The metaheuristic methods include TS (Archetti, Speranza et al. 2006; Aleman and Hill 2010), genetic algorithms (Boudia, Prins et al. 2007), and several hybrid approaches that combine heuristics with integer programming (Chen, Golden et al. 2007; Archetti, Speranza et al. 2008; Jin, Liu et al. 2008). 57

Ho and Haugland (2004) describe a TS

approach for the SDVRP with time windows, allowing split loads based on available capacity, while none of the aforementioned research include time windows. Extending the work on split loads further, Nowak (2005; 2008), defined the oneto-one pickup and delivery problem with split loads (PDPSL), proving that as with the VRP, the routing cost can be improved by at most one half if split loads are considered, and developed a heuristic to solve the PDPSL. The problem assumes all of the standard constraints for the PDP, but does not include time windows. The heuristic constructs the initial solution with no split loads, selects loads to split, and then uses local search techniques to further improve the solution. Several authors have recently addressed the PDPSL with time windows in applied problems. Fagerholt, Korsv et al (2009; 2010) present a heuristic to solve ship routing and scheduling on a benchmark set of problems. This problem is an instance of the multi-vehicle PDPTW.

An interesting aspect of the proposed algorithm is that it

combines random multi-start (GRASP), TS, SA, and steepest descent. Unfortunately, with the combination of several methods, it is difficult to discern how much each method contributed to finding good solutions. Laporte, Korsvik et al (2011) portray a large neighborhood search heuristic solving the ship routing and scheduling problem allowing split loads on the same benchmark set. Their approach achieved an average of 10% improvement over solutions without split loads.

The algorithm consists of a large

neighborhood search that destroys and repairs the solution at each iteration, accepting the new solution if it results in improvement.

58

4.1 Modeling Split Loads In the Chapter 3, the IAOP solution was defined by the decision variable (DV) configuration which was comprised of a vehicle DV containing the required information for each vehicle schedule and an unassigned elements DV. Implementing split loading requires an additional decision variable which maintains the partition of each shipment. 4.1.1 Split Shipment Decision Variable The split shipment partition DV contains a list of lists, as shown in Figure 13. The outer dimension corresponds to the set of full shipments. For each full shipment, the inner list corresponds to the current splits on that shipment, corresponding to an exhaustive partition of each shipment. If all full shipments are feasible with respect to vehicle capacity, this DV initializes with one ‘partial’ shipment, equal to the full shipment. Full shipments too large for a vehicle are split into the fewest number of feasible partial shipments necessary to deliver the full shipment during problem initialization.

59

Figure 13: Split Shipment Decision Variable After initialization, the IAOP does not allow dynamic load splitting. However, the IAOP-SL implements such additional split loading. This requires that any time a shipment’s current split structure is changed, the shipment partition information must be updated. Just like the IAOP, the IAOP-SL always references customer requests as partial shipments instead of referencing each individual shipment element.

Each partial

shipment then contains the details of its associated shipment elements. The IAOP-SL theoretically allows a shipment to be split into at most m partial shipments, where m is the number of shipment elements of the given shipment. In practice, the number of splits per shipment is much closer to 1, with a limited number of additional splits created when advantageous.

60

4.1.2 A Small Split Load Example For clarity, we provide a small example and a summary of associated solutions to demonstrate instances when split loading is advantageous. As shown in Table 12, the customer demand includes three shipments from OKAS to ORBD. Each shipment’s size is such that if split loading is not allowed, only one shipment may be placed on a C-17 aircraft. TABLE 12: SHIPMENT DEMAND FOR SPLIT LOAD EXAMPLE 1 ID 0 1 2

APOE OKAS OKAS OKAS

APOD ORBD ORBD ORBD

PAL 8 7 6

PAX 5 10 20

Tons 30 25 10

ALD 1 1 1

RDD 2 2 3

Priority 3 3 2

If one aircraft is available, then to deliver all shipments, three trips from OKAS to ORBD must be made. A summary of that solution is shown below in Figure 14. Since the third trip between OKAS and ORBD goes over the route duration limit, the aircraft must return to its home port and then start a new mission to deliver the last shipment.

61

Time: Action 0: starts Mission 1 from OTBH 0: departs from OTBH 74: arrives at Airbase OKAS 74: loading FullShipment 2 209: departs from Airbase OKAS 282: arrives at Airbase ORBD 282: unloading FullShipment 2 357: departs from Airbase ORBD 430: arrives at Airbase OKAS 430: loading FullShipment 1 565: departs from Airbase OKAS 638: arrives at Airbase ORBD 638: unloading FullShipment 1 713: departs from Airbase ORBD 829: arrives at Airbase OTBH 829: finishes Mission 1 at OTBH

1024: 1024: 1098: 1098: 1233: 1306: 1306: 1381: 1497: 1497:

starts Mission 2 from OTBH departs from OTBH arrives at Airbase OKAS loading FullShipment 0 departs from OKAS arrives at ORBD unloading FullShipment 0 departs from ORBD arrives at Airbase OTBH finishes Mission 2at OTBH

Figure 14: Summary of solution not allowing split loads In contrast, as illustrated in Figure 15, split loading allows one of the three shipments to be split into two pieces such that only two trips from OKAS to ORBD are required to deliver the shipments.

62

Time: Action 0: starts mission Airbase OTBH 0: departs from OTBH 74: arrives at Airbase OKAS 74: loading FullShipment 2 74: loading PartialShipment 0 [NPallets=5, NPassengers=5] 209: departs from Airbase OKAS 282: arrives at Airbase ORBD 282: unloading FullShipment 2 282: unloading PartialShipment 0 [NPallets=5, NPassengers=5] 357: departs from Airbase ORBD 430: arrives at Airbase OKAS 430: loading FullShipment 1 430: loading PartialShipment 0 [NPallets=3, NPassengers=0] 565: departs from Airbase OKAS 638: arrives at Airbase ORBD 638: unloading FullShipment 1 638: unloading PartialShipment 0 [NPallets=3, NPassengers=0] 713: departs from Airbase ORBD 829: arrives at Airbase OTBH 829: finishes mission at OTBH

Figure 15: Summary of solution allowing split loads The improvement due to allowing split loading in this example is simple and would likely be found by a human planner. However, any routing algorithm that prohibits split loading would not obtain the improved solution.

4.2 Designing the TS-IAOP-SL Extending the IAOP to allow split loads requires additional objective function measures, new neighborhoods, and an associated dynamic neighborhood selection (DNS) methodology. The tabu memory structure is unchanged from the TS-IAOP since tabu restrictions are based on the route and shipment. If a shipment is split into multiple pieces, any tabu restrictions created are relevant to the entire partition of partial shipments for any given shipment.

63

4.2.1 IAOP-SL Objective Function Measures As in the IAOP, the number of additional loads, which includes split loads, and total shipment lag are the two measures relevant to the IAOP-SL. These measures describe the increased complexity of the problem and possible impact to the planner and/or customer. The number of additional split loads measures any additional splits beyond those necessary to create feasible partial shipments during problem initialization. While splitting a shipment may allow for improvement in other objective measures, increasing the number of split shipments forces a planner to consider more entities while ensuring that all shipment elements arrive at their destination. Likewise, customers may not prefer that their shipment be split into several pieces because of the perception of an increased risk that the entire shipment will not arrive safely. Including the number of additional split shipments causes the search to balance the gain achieved by splitting a shipment with the increased complexity. Shipment lag measures the time between a given shipment’s first element arrival and each additional element’s arrival. For the IOAP, this measure is relevant to any shipments that must be partitioned to feasibly fit on a vehicle. For the IOAP-SL, this measure is relevant to all of the aforementioned shipments and any split shipments. Minimizing shipment lag in the objective causes the search to prefer solutions in which all the partial shipments for a given full shipment are delivered as closely together as possible. Compared to all other measures in the multicriteria objective function, these tertiary measures have a much lower weight than the primary effectiveness measures.

64

4.2.2 IAOP-SL Neighborhoods In addition to the set of neighborhoods described in the IAOP, additional neighborhoods are implemented to allow split loading.

As mentioned, the Split

Shipments DV keeps track of the current partition of partial shipments for each full shipment. The neighborhoods described for the IAOP do not change the cardinality of the initial partition. However, for the IAOP-SL, certain additional neighborhoods can increase or decrease the partition cardinality by either splitting a current partial shipment into two pieces or merging two partial shipments into a single partial shipment. These neighborhoods are: 

(S) Split a shipment into two new parts and add one or both new partial shipments to existing route stops



(M) Delete two scheduled partial shipments from the same parent shipment and merge the shipments into a single partial shipment In the following sections, these neighborhoods are detailed.

All neighborhoods

are explained with respect to generating neighboring solutions and are applied over the entire fleet of vehicles. The neighborhood size is dependent on the incumbent solution. Each neighborhood must update the relevant Vehicle DV(s), the Unassigned Elements DV, and the Split Shipment DV to reflect adding or deleting shipments from the schedule. Rules concerning how and when a shipment can be split or merged must be instantiated. When the IAOP-SL considers splitting a shipment it considers splitting a single partial shipment into two pieces. Any valid partition is acceptable for each piece, down to the indivisible shipment element, but splits must be feasible with respect to the 65

current incumbent solution. While, in theory, a shipment could be split or merged in several ways, we have limited when this action can occur in the search. Only an unassigned partial shipment can be split for inclusion into the schedule. A pair of partial shipments can be merged in one of two ways.

First, any pair of assigned partial

shipments from the same parent shipment can be merged when deleting the pair from the schedule. Second, a partial shipment can be merged with another related partial shipment if one is feasibly assigned to a portion of a route already containing a matching partial shipment. The AddSplitShipmentExistingStops neighborhood consists of solutions with an unassigned partial shipment split into two partial shipments and one or both new partial shipments added to existing route stops. For each unassigned partial shipment, existing stops matching the shipment origin/destination are considered to generate neighboring solutions. If an existing pair of stops is found, the search checks if there is available vehicle capacity for the shipment. When the capacity is insufficient, the search tries two methods to split the shipment under current consideration into two pieces. The first method tries to fit pallets, then passengers and the second method tries to fit passengers, then pallets. The first piece (partial shipment) of either method is as large as possible with respect to vehicle capacity feasibility over along the path between the origin and destination segments. For each splitting method, the neighborhood builds a neighboring solution by adding just the first piece. Then, the neighborhood tries to find another set of existing stops on any vehicle’s routes with available capacity to fit the second piece. If a feasible set of stops is found, the neighborhood builds a neighboring solution by adding 66

both the first and second pieces of the split. In summary, each neighboring solution corresponds to splitting an unassigned partial shipment into two pieces and adding one or both newly created smaller partial shipments to the existing segments of a route on any vehicle. Note, this neighborhood limits the actual number of possible insertion locations for a newly split shipment by only allowing insertion on existing stops. The data required to create each unique neighboring solution for this neighborhood includes the original shipment, all the necessary information for adding the first partial shipment, and all the necessary information for adding the second partial shipment. The information for each partial shipment includes the vehicle, the route index, the pickup stop index, and the delivery stop index. Each neighboring solution is created by splitting an unassigned partial shipment into two pieces. Each new partial shipment is added to the load list of the given pickup segment and the unload list of the given delivery segment. The two shipments can be added not only to different routes, but also to different vehicles. The Split Shipment DV is updated to reflect the additional partition of the given partial shipment into two partial shipments. The Delete&MergeShipments neighborhood deletes two scheduled partial shipments from the same parent shipment and merges them into a single partial shipment. To generate the set of neighboring solutions, the neighborhood iterates over all assigned pairs of partial shipments with the same “parent” full shipment. The data required to create each unique neighboring solution for this neighborhood includes all the necessary information for deleting both the first partial shipment, and the second partial shipment. The information for each partial shipment 67

includes the vehicle, the route index, the pickup stop index, and the delivery stop index. Each neighboring solution corresponds to deleting both partial shipments from their respective load and unload lists. The Split Shipment DV is updated to reflect the merge of the two partial shipments into a single shipment. 4.2.3 Composite Neighborhoods We create composite neighborhoods by combining specific sets of neighborhoods and using them as building blocks to implement our neighborhood selection strategies. The composite neighborhoods employed are: 

(A)

: all three add shipment neighborhoods over all vehicles



(D)

: the delete shipment neighborhood over all vehicles



(A,D)

: both (A) and (D)



(R)

: delete route stop



(A,S,D,M)

: both (A) and (D) along with split (S) and merge (M) nbhds

4.2.4 IAOP-SL Dynamic Neighborhood Selection Strategy A new dynamic neighborhood selection (DNS) strategy is implemented to allow split loads. As shown in Figure 16, the strategy is an extension of the Aggressive DNS described previously for the IAOP. Each pattern within the Split Load DNS executes for a given number of iterations as a function of n, the number of shipments to be serviced. Similar to the Aggressive DNS, the Split Load DNS strategy repeats a basic pattern of allowing all possible add and delete moves for a given number of iterations, performing a short diversification action, deleting a portion of the solution, and finally recovering by

68

adding shipments until the schedule is full. During a portion of the Split Load DNS, shipments are allowed to be split or merged when recovering by adding shipments.

Figure 16: Split Load Dynamic Neighborhood Selection Strategy

4.3 TS-IAOP-SL Results The computation results using the Split Loading DNS strategy are promising. As shown in Table 13, the average improvement over the previously best found solution is over 6%, with a range of -1% to 21%. This improvement comes while including an additional penalty in the objective function related to the number of split loads in the solution. In only one scenario did the Split Loading DNS fail to find an improving solution and in that case, the difference in the best solutions was so small that it can be logically attributed to the penalty due to the number of split loads.

69

One concern when constructing the search was that the number of split loads would continue to increase during the search. However, this was controlled by merging shipments back together and by the objective function measures penalizing both the number of splits and the shipment lag created when splitting a shipment. The number of split loads found in the best solutions tended to be low. In all cases, the best solution did not include the maximum number of split loads found during the search. Not only did including split loading tend to improve the solution quality, but in many instances, it also improved the computational time necessary to find good solutions, dominating the other search strategies after some initial period. Figure 17 shows the best solution found for Scenario 5 in which the Split Load DNS strategy quickly found good solutions even though it did not significantly improve beyond the eventual best solution from the Standard DNS strategy. This shows an example where the increased flexibility due to allowing split loading may allow the search to more quickly find excellent solutions amply sufficient for practical use. In Figure 17, the iterations required to find highly competitive solutions using splits (when compared to the best solution found using splits at 50000 iterations) was about half the iterations required by the standard IOAP approach to find practically competitive solutions.

70

Figure 17: Scenario 5 best solution during search

4.4 Lower Bounds As shown in Figure 18, we ran both the Aggressive and Split Load DNS strategies for 1M iterations to find a proxy for the lower bound of Scenario 1. For comparison, we show the best solutions found by the greedy heuristic and all strategies over 50K iterations. The search is still actively finding new best solutions even after more than 700K iterations for both DNS strategies. However, there is a significant gap between the best solutions found after 50k compared to the best solutions after 1M iterations.

71

Figure 18: Scenario 1 comparison of best solutions

4.5 Extensions This work focuses on a split load neighborhood that operates over existing stops on existing routes in the solution and does not include neighboring solutions that add one or more stops while adding a split load. The possibility exists that further improvements could be found by including a general split load neighborhood which includes all possible ways to split a load among existing routes. Further testing could also be done to quantify how often splitting should be allowed in a given iteration. The strategy implemented in this research only allows the search to split a load periodically, giving the search time to explore after the partition of shipments is changed. 72

4.6 Conclusions This chapter presents an improved version of the IAOP-TS algorithm that allows split loads. An additional decision variable is introduced that keeps track of the current partitioning of shipments at each iteration during the search. Appropriate measures are included in the objective to encourage the search to use the least number of splits necessary while pursuing improving solutions and minimizing the perceived impact to the customer. Results are compared to previous work showing improvement in solution quality with negligible impact on computational time. Furthermore, in several cases, allowing split loading allowed the search to find better solutions much more quickly.

The essence of flexibility is in the mind of the commander; the substance of flexibility is in logistics. - Rear Admiral Henry Eccles, U.S. Navy

73

TABLE 13: SPLIT LOAD RESULTS Multi-criteria Objective metrics DNS

Objective

Scenario 1

Initial Soln

0.89182

104

3637

50

1195

1.15E+06

0

0

6.99E+06

0

6.99E+06

Standard

0.11181

25

367

16

184

4.57E+04

13234

6012

4.74E+06

0:42:11

8.03E+07

244

1431

0

1.08E+06

Split Loads

0.10342

30

332

20

352

4.96E+04

13476

5883

4.76E+06

0:44:01

8.45E+07

294

1267

4

1.07E+06

Scenario 2

Initial Soln

0.89036

119

3439

51

1544

1.24E+06

0

0

8.26E+06

0

8.26E+06

Standard

0.07181

23

196

10

202

3.73E+04

13249

5759

3.70E+06

0:43:40

7.27E+07

358

1270

0

4.21E+05

Split Loads

0.06885

33

182

14

55

3.79E+04

13244

5668

3.82E+06

0:50:07

8.32E+07

201

1502

7

9.59E+05

Scenario 3

Initial Soln

0.89408

102

3071

50

1685

1.11E+06

0

0

5.91E+06

0

5.91E+06

Aggressive

0.06907

15

160

15

71

3.78E+04

13450

5934

3.72E+06

0:32:05

6.97E+07

385

899

0

6.97E+05

Split Loads

0.06360

21

142

8

127

3.32E+04

13247

6002

3.73E+06

0:33:32

7.21E+07

351

1323

3

4.32E+05

Scenario 4

Initial Soln

0.88863

83

2221

35

790

6.67E+05

0

0

5.07E+06

0

5.07E+06

Standard

0.03177

6

24

10

117

9.01E+03

13488

5763

2.76E+06

0:12:17

2.85E+07

759

1428

0

1.64E+05

Split Loads

0.02506

3

8

6

30

1.17E+04

13463

5330

2.64E+06

0:11:38

2.65E+07

522

1440

1

1.25E+05

Scenario 5

Initial Soln

0.90062

87

2282

41

1487

1.18E+06

0

0

4.61E+06

0

4.61E+06

Standard

0.02223

0

0

2

126

1.66E+04

13220

5645

2.35E+06

0:07:55

1.89E+07

1104

1315

0

6.45E+04

Split Loads

0.02182

0

0

7

53

1.32E+04

13103

5458

2.11E+06

0:06:51

1.62E+07

1239

1576

1

6.24E+04

Scenario 6

Initial Soln

0.89487

239

6160

116

3013

2.66E+06

0

0

1.35E+07

0

1.35E+07

Aggressive

0.07405

21

366

25

188

8.21E+04

42289

17272

7.55E+06

1:33:50

8.71E+07

18

1660

0

1.47E+06

Split Loads

0.06869

21

330

20

155

6.34E+04

42150

16832

7.56E+06

1:43:59

9.66E+07

35

1455

5

1.46E+06

Scenario 7

Undelivered Shipments *

Split Load Metrics

Initial Soln

0.89278

341

8883

170

3773

3.47E+06

0

0

1.98E+07

0

1.98E+07

Standard

0.13942

51

1182

42

527

1.85E+05

44777

19886

1.23E+07

12:33:14

4.38E+08

45

3219

0

2.59E+06

Split Loads

0.14046

65

1193

41

594

2.06E+05

44674

19454

1.24E+07

15:03:41

5.18E+08

41

4993

20

2.52E+06

Scenario 8

Improv

Run Information

Late Total Time Total Time Total Total Undelivered Late Total Travel Time Infeasible Additional Shipment Late Elements Deliver Evaluations Repeats Shipment Elements * Shipments * Time ** Time ** (hh:mm:ss) Incumbents Split Loads Elements * ** Elements ** *** Lag **

Initial Soln

0.89370

343

14849

186

7268

5.33E+06

0

0

2.89E+07

0

2.89E+07

Standard

0.32477

101

5099

79

2689

1.12E+06

42536

17810

2.00E+07

32:09:37

7.13E+08

24

6636

0

8.24E+06

Split Loads

0.31312

116

4938

68

2432

9.99E+05

38560

16561

1.99E+07

38:02:37

8.25E+08

28

6437

22

7.80E+06

8%

4%

8%

21%

2%

7%

-1%

4%

50K iterations; * weighted by priority; ** times measured in minutes; ***total evaluations based on size of neighborhood at each iteration

74

CHAPTER 5 THE IAOP-SL WITH A ROLLING HORIZON Another extension of the VRP is to change the problem definition from a static, single problem to a dynamic problem with a rolling horizon. By considering the actual passage to time, the continual changes to system over time must be taken into account. This extension is usually referred to as a dynamic or online problem in which some aspects of the problem are incrementally revealed over time. Many applications of the VRP require solving a problem not from a blank initial solution, but rather starting at a previously solved solution from the prior time step that represents the ‘live’ state of the system. The arrival of new information in any form is the driver behind resolving the problem. Similar to OODA (observe-orient-decide-act) loop (Boyd 1976; Boyd 1995), this process continually re-orients to the new information as planners decide and act. In the context of military airlift, new information arrives as either updated shipment demand, updated plans affecting available resources, or unforeseen events.

In this

chapter, we only consider updated shipment demands over time as we resolve the problem over a rolling horizon. We discuss and implement strategies that take into account a rolling horizon. Examples show how a new solution is found constrained by aspects of the solution found at the previous time step.

5.1 Modeling a Rolling Horizon In the previous chapters we have solved the static IAOP, including split loads. As introduced in Chapter 2, Figure 19 illustrates a solution as a fleet plan over a 72 hour

75

horizon. Note, for simplicity the details of each route are not shown, but would include all relevant times, stops, pickups, and deliveries.

Figure 19: Fleet plan over 72 hour horizon As airlift operations are ongoing, Figure 20 shows the same fleet plan 24 hours later, with the red mark indicating the current time, before newly arrived shipments have been scheduled. In current practice, the ad hoc planning process is usually continually updated as opposed to utilizing discrete time steps. For the purposes of this chapter’s initial illustrative “proof of concept,” a 24 hour increment is adopted. Assuming new shipment information arrives, planners must route and schedule the fleet to best satisfy the undelivered demand, both existing and newly available shipments, for the next available day.

76

Figure 20: Fleet plan after time step to next day Several options exist on how to update the existing plan before considering how to service the newly arrived shipments. The simplest and most conservative option is to consider any planned route fixed and only add new routes to the schedule. However, a natural improvement to this approach, Option 1, would be to allow planners to also add shipments to planned routes if there exists a path from a shipment’s origin to destination with sufficient capacity.

This action would improve vehicle utilization without

significantly altering the existing schedule. A more flexible option, Option 2, would be to consider changing any part of a planned route on the schedule. However, in practice, this would, almost certainly, introduce insurmountable difficulties since each route requires unique planning by the assigned flight crew and coordination with respect to other factors.

5.2 Designing the Dynamic TS-IAOP-SL In this work, we have implemented two DNS strategies that closely mirror planning Options 1 and 2. Building upon the Split Load DNS, we constrain the included neighborhoods with respect to either the starting solution or a given time. As shown in 77

Figure 21, associated with Option 1, the Constrained Previous Solution DNS does not allow any solution elements, either shipments or stops, to be deleted from previously scheduled routes. As mentioned above, shipments can only be added to previously planned routes not yet in execution using the AddShipmentExistingStops neighborhood, described in Section 3.2.3. Since only the last day before the end of the planning horizon is considered using this strategy, the overall problem size is decreased.

Figure 21: Updated fleet plan constrained by previous plan As shown in Figure 22, associated with Option 2, the Constrained Time DNS does not allow any solution elements to be deleted from routes starting before a given time, indicated by the red vertical line. This is set as the current time with respect to the planners’ perspective. Any planned route beyond the given time can be modified in any way, including deletion, and new routes can be added.

78

Figure 22: Updated fleet plan constrained by routes currently in progress

5.3 Results To build the scenarios for the dynamic IAOP, we combined data from the static scenarios introduced in Chapter 3. Three scenarios, each with an additional day of shipment demand, were constructed based on Scenarios 1, 3, and 5. For example, the start time of the (dynamic) Scenario 1 is 24 hours forward from the beginning of Scenario 1 with shipment data from Scenario 1 and the first day of shipment data from Scenario 2. The starting solution for each scenario was set as the best solution found by the Split Load DNS. Results from the updated dynamic scenarios, employing a maximum of 20K iterations, are presented in Table 14. There is an inherent tradeoff between the two constrained DNS strategies. On one hand locking routes from the previous solution provides a smaller problem, but also further constrains the solution space. The opposite is true for the DNS strategy which constrains only routes currently in execution. We expected the DNS strategy constrained by time to outperform the DNS strategy constrained by the previous solution. This was true in all three scenarios tested. This is 79

illustrated in two of the scenarios in the limited searches presented in Table 14. While not shown in the table, a similar predicted result held for Scenario 1 when the search performed 50k iterations and achieved an improvement of 43%.

5.4 Extensions Other search strategies could find a balance between the two options shown in this chapter by allowing changes to previously scheduled routes with some cost. One way to implement this idea would be to introduce additional time horizons with different associated costs.

For example, routes in the next 24 hours could be available for

adjustment with some added cost if changed.

Another idea would be to develop cost

measures for adjusting previously scheduled routes with respect to solution persistence. For example, adding a stop to deliver an additional shipment on an existing route might cause re-planning by flight crews and disruptions to crew rest, but might still be preferred.

5.5 Conclusions This chapter introduced a dynamic version of the IAOP with a rolling time horizon.

Two constrained DNS strategies were implemented and demonstrated on

extended versions of scenarios introduced in Chapter 3. This work provides an initial proof of concept that brings the TS-IAOP-SL one step closer to an implementable planning tool by considering planning efforts at a previous time step.

80

Amateurs talk about tactics, but professionals study logistics. - Gen. Robert H. Barrow, USMC (Commandant of the Marine Corps) noted in 1980

81

TABLE 14: DYNAMIC SCENARIO RESULTS Mul ti-cri teri a Objective metri cs

Scenario 6

Scenario 3

Scenario 1

DNS

Objective Improv

Priority Priority Priority Weighted Weighted Weighted Undelivered Undelivered Late Shipments Elements Shipments

Priority Weighted Late Shipment Elements

Run Informa tion

Total Time Total Time Total Travel Time Late Deliver Time * Time * (hh:mm:ss) Elements * Elements *

Evals **

Spl i t Loa d Metri cs

Repeat Additiona Total Infeasible Incum l Split Shipment Incumbents bents Loads Lag **

Initial Soln

0.37501

61

2264

32

572

2.01E+05

13476 5883

1.20E+07

4

8.27E+06

Greedy

0.16255

41

882

35

809

1.95E+05

17455 7672

1.17E+07

4

3.73E+06

Constrained 1 ^

0.09669

41%

45

468

27

325

1.27E+05

17831 7638

1.11E+07

0:42:20

4.73E+07

1098

360

7

1.76E+06

Constrained 2 ^^ 0.10736

34%

43

537

25

305

1.40E+05

17811 7971

1.13E+07

0:57:42

6.43E+07

23

374

5

1.07E+06

Initial Soln

0.22583

46

911

14

167

8.08E+04

13247 6002

6.26E+06

3

2.96E+06

Greedy

0.05324

19

133

14

167

7.71E+04

17347 7642

5.97E+06

3

6.16E+05

Constrained 1 ^

0.05206

2%

20

127

14

167

8.08E+04

17530 7765

5.97E+06

0:13:06

2.09E+07

1337

499

2

6.75E+05

Constrained 2 ^^ 0.04898

8%

0:22:28

3.26E+07

154

1206

14

103

29

883

2.90E+05

17473 7993

6.54E+06

5

7.18E+05

Initial Soln

0.06384

21

330

30

271

1.61E+05

42150 16832

7.90E+06

5

1.80E+06

Greedy

0.01914

2

5

34

271

1.06E+05

47061 19418

7.72E+06

5

5.74E+05

Constrained 1 ^

0.01981

-4%

2

5

44

343

1.42E+05

48604 19527

7.92E+06

0:18:27

1.59E+07

356

1221

4

6.32E+05

Constrained 2 ^^ 0.01867

2%

1

2

36

290

1.13E+05

46911 19136

7.79E+06

0:23:32

1.97E+07

13

680

5

5.92E+05

20K iterations; * times measured in minutes; **total evaluations vary based on neighborhood size; ^ constrained wrt previous solution; ^^ constrained wrt time;

82

CHAPTER 6 CONCLUSIONS This dissertation introduced the IAOP, a difficult problem tackled daily by USAF planners. In addition to the constraints of the traditional one-to-one PDPTW, the IAOP includes several difficult constraints including multiple vehicles, multiple routes, different cargo types, cargo bay configurations, and port capacities. As opposed to most studied versions of the VRP, not all demand must be satisfied and shipments are may be larger than vehicle capacity.

6.1 Major Contributions This work built upon Ciarleglio’s metaheuristic framework (2007) to implement several modeling and algorithmic contributions to the IAOP. These contributions are: 

the development of an practical model and effective TS algorithm to solve the IAOP;



the development of several competing DNS strategies within the TS-IAOP;



the implementation of split loads within the TS-IAOP-SL, including a novel change to the solution representation to limit the additional complexity; and



the proof of concept for an extension of the TS-IAOP-SL over a rolling horizon. The TS-IAOP implements an object-oriented solution representation to model the

IAOP. The model provides the ability to easily adjust elements at any level of the hierarchical solution along with the ability to keep any number of shipments unassigned. A multi-criteria objective considers several relevant solution measures. The objective measures’ weighting can easily be adjusted to accommodate different decision maker preferences between effectiveness and efficiency. 83

The TS-IAOP provides a set of

neighborhoods that add or delete solution elements to the fleet plan.

These

neighborhoods are used as the foundation of larger composite neighborhoods implemented within several dynamic neighborhood selection (DNS) strategies. The DNS strategies are designed to execute intelligent combinations of the composite neighborhoods. These strategies construct and destroy aspects of the solution during the search, intensifying and diversifying when appropriate.

The IAOP-TS produces a

portfolio of excellent solutions within a reasonable time frame far superior to those found by current planning methods. The TS-IAOP-SL incorporates split loading. To our knowledge, this is the first academic model related to military airlift relaxing the assumption of no split loading. The implementation of split loads within the solution representation is handled by a new, unique decision variable that provides the framework to handle all the necessary complications due to allowing split loading, while limiting the additional complexity. The solution representation keeps track of each shipment’s current partition and has the ability to change any shipment partition when necessary during the search. Additional objective measures penalize split loads to balancing the additional complexity with solution improvement.

Several neighborhoods are implemented to split and merge

shipments. The Split Load DNS periodically incorporates these neighborhoods to alter the current shipments’ partition if advantageous. While only considering a subset of all possible split loads, the algorithm provides an average improvement of 6% and maximum of 21% improvement over the best known solutions without split loading. In addition, these solutions are also often found earlier in the search. Further, the computational 84

effort of the TS-IAOP-SL is not significantly higher than the TS-IAOP, with comparable run times. The TS-IAOP-SL is further extended, in an initial proof of concept, over a rolling time horizon. This extension is the first step toward a planning tool for a rolling time horizon.

The algorithm explicitly considers the previously scheduled solution and

constrains the search accordingly.

6.2 Further Enhancements This work built a foundational set of easily extendable neighborhoods and intelligently implemented several dynamic neighborhood selection strategies. However, several improvements could be made to further enhance the algorithm. Efforts should be made to improve computational efficiency. Calculating the results after performing each move takes significant computation.

While we

implemented methods to reduce this computation, more improvements exist.

For

example, significant improvement was obtained by reducing the calculation to only the relevant adjusted vehicle plan and updating the previous set of results instead of recalculating the entire set of results following a move. However, with some effort, further improvement could be found by reducing this calculation to only the relevant adjusted routes or even stops. Another possible avenue to improve computational time would be to reduce the size of implemented neighborhoods. This is reminiscent of earlier “candidate list strategies” that were employed in the earlier development of TS methodologies. For example, some measure of the current solution quality could be used 85

to sort solution elements, such as vehicles, routes, or shipments. Only a subset of these elements would be used to generate a given neighborhood.

Implementing smaller

neighborhoods must balance the tradeoff between missing ‘good’ solutions and improving reducing necessary computation. Both additional neighborhoods and strategies should be developed and explored. In this work we only allow split loads to be feasibly added over existing route stops. Additional split loads neighborhoods could be implemented allowing split loads to be added on any new or existing route stop. Currently, all neighborhoods perform some form or adding or deleting solution elements from the vehicle plans. Efforts to develop neighborhoods that rearrange solution elements might be fruitful.

A neighborhood

rearranging shipments within a given route could yield improvements. However, this approach might provide more benefit to general VRPs versus more constrained PDPTWs such as the IAOP. Additional preset combinations of neighborhoods could be developed within new DNS strategies. These could be generic or based on some aspect of the current solution. For example, macro constructive and destructive sequences could be implemented to delete poor quality routes and construct a new route filled with as many shipments as possible. New or existing measures could be used to define route quality.

6.3 Future Extensions Three main lines of research can be extended from this work. First, the TS-IAOP provides a proof-of-concept for USAF planners. However, more work in necessary to continue improving the model and algorithm such that it can be implemented into the 86

decision process with the USAF. This requires coordination with planners, analysts, and programmers to ensure all relevant real-world issues are taken into account and that the model correctly interfaces with existing systems. Such improvements would be problem specific, including, but not limited to, adding other aircraft types, cargo types, and cargo bay configurations. Other aspects of airlift planning such as fuel loads, aircrews, and shipment mode selection could also be considered if deemed appropriate at this level of planning.

Combining this model with other existing research could provide better

solutions for strategic airlift from CONUS to forward theaters (Lambert, Barnes et al. 2007), load placement within aircraft (Roesener, Barnes et al. 2010), and general theater logistic network construction (Crino, Moore et al. 2004; Burks, Moore et al. 2010). Providing a graphical visualization of IAOP solutions would help planners to more quickly interpret results and compare competing solutions. In the work performed in this research, the only human-readable solution visualization is a full text summary of all scheduled routes for each aircraft and a table of all solution measures. Incorporating ideas from the ‘map of the market’ (Wattenberg 1999), color differentiated visualizations could represent several aspects of a solution. For example, a color differentiated partition of all shipments could provide a quick visual summary of each shipment’s size, whether or not each shipment is delivered, and how late each shipment arrives at its destination. Route utilization could also be represented with respect to different capacity dimensions. A second thread of research would be to continue to explore the dynamic version of the problem and relax some data certainty assumptions. Simulating longer time periods, such as an entire month, and resolving the problem daily would provide a chance 87

to look at the value of information. Incorporating uncertainty during execution with respect to vehicle down time and vehicle travel times would force the algorithm to deal with disruption management. Additional objective measures would have to be explored to improve solution robustness under uncertainty while balancing solution quality. The third thread of research would be to extend this work back to generic academic problems and/or other relevant problem domains. Well known benchmark sets exist for several variants of the VRP, the PDPSL and the PDPTW being most relevant to this research.

Modifying this advanced TS algorithm to work on these existing

benchmarks would validate the quality of this algorithm and provide an opportunity to find improvements. Other difficult variants of the VRP are the topic of open research, such as routing and scheduling fleets of unmanned aerial vehicles to conduct ISR (intelligence, reconnaissance, and surveillance), strike missions, and BDA (battle damage assessment). Many similar constraints exist with such things as payload considerations, precedence relationships between activities, online re-planning, and coordination time windows.

Extending this research to these domains can only serve to improve upon

current findings.

6.4 Summary Continually improving air mobility planning extends a proud tradition within the USAF to push the envelope in terms of airlift capability. This work continues in that tradition, expanding upon advanced tabu search techniques to model the IAOP, quickly find excellent solutions, implement split loading, and consider a rolling time horizon. 88

The last 75 years include many impressive mobility operations (Callander 1998): “The Hump” of WWII, the Berlin Airlift, the Korean War, Operation Desert Shield, Operation Iraqi Freedom, and Operation Enduring Freedom in Afghanistan, to name only a few. Along with advances in weaponry, continued research in air mobility operations is crucial to maintain several of the USAF core competencies, including Rapid Global Mobility, Agile Combat Support, and Information Superiority (USAF 2012). Automated heuristics must eventually replace time intensive, inefficient manual efforts to be combat the complexities of mobility planning.

My logisticians are a humorless lot...they know if my campaign fails, they are the first ones I will slay. - Alexander

89

Glossary

AE

Aerial Evacuation

ALD

Available Load Date

AMC

Air Mobility Command

APOD

Aerial Port of Debarkation

APOE

Aerial Port of Embarkation

CDD

Crew Duty Day

CENTCOM

Central Command

CONUS

Continental United States

CTOP

Capacitated Team Orienteering Problem

DNS

Dynamic Neighborhood Selection

DV

Decision Variable

FS

Full Shipment

GRASP

Greedy Randomized Adaptive Search Procedure

GTTS

Group Theoretic Tabu Search

IAOP

Intratheater Airlift Operations Problem

ICAO

International Civil Aviation Organization

ITARS

Intratheater Airlift Request System

LNS

Large Neighborhood Search

MOG

Maximum on Ground 90

PAX

Passengers

PAL

Pallets

PDP

Pickup and Delivery Problem

PDPTW

Pickup and Delivery Problem with Time Windows

PDPSL

Pickup and Delivery Problem with Split Loading

PS

Partial Shipment

RDD

Required Delivery Date

RTS

Reactive Tabu Search

SAP

Strategic Airlift Problem

SDVRP

Split Delivery Vehicle Routing Problem

SL

Split Loads

TDD

Theater Direct Delivery

TDVRSP

Theater Distribution and Vehicle Routing and Scheduling Problem

TM

Ton Mile

TS

Tabu Search

TT

Tabu Tenure

USAF

United States Air Force

VRP

Vehicle Routing Problem

VRPTW

Vehicle Routing Problem with Time Windows

91

Appendix A

Example Using Current Planning Methods

In the following example there are two available aircraft, each with a capacity of 18 pallets and a route duration limit of 18 hours. The maximum weight constraint for each aircraft is not considered. Thus, the weight of each shipment is not considered when determining the loading feasibility in an aircraft. The scenario includes five locations, one of which is the aircraft depot. All routes begin and end at the depot and there are no additional constraints at any location such operating hours or MOG. The list of customer requests consists of 22 shipments and is known at the beginning of the scenario. Figure 23 shows a graphic representation of the scenario locations with directional arcs between locations representing the APOD, APOE pair for each shipment. The shipments, shown in Table 15, are sorted according to by ALD, RDD, and finally priority.

Figure 23: Graphic representing APOE -> APOD for each shipment

92

TABLE 15: SORTED LIST OF SHIPMENTS BY ALD, RDD, AND PRIORITY Shipment 11 1 5 2 6 10 13 7 9 3 4 8 12 21 16 18 19 20 23 14 15 17 22

APOE Depot A Depot D B E B B E C Depot E A Depot Depot E D C B Depot E Depot B

APOD E E E B D Depot Depot C B Depot B A B C E C B B Depot E C C E

Pallets 5 18 8 18 8 7 10 7 14 1 10 13 3 2 2 18 7 1 10 4 18 2 5

ALD 1 1 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2

RDD 2 2 2 3 3 3 5 5 5 21 21 21 21 3 4 4 6 6 6 21 21 21 21

Priority 1 2 2 1 1 2 1 2 2 3 3 3 3 2 1 2 1 1 1 3 3 3 3

TABLE 16: TRANSIT TIME BETWEEN LOCATIONS AND THE TURN TIME AT EACH LOCATION

Depot A Depot 126 A 126 B 135 33 C 132 25 D 142 38 E 72 87

B 135 33 32 36 85

C 132 25 32 42 84

D 142 38 36 42 87

E 72 87 85 84 87

Turn Time 195 75 75 75 75 135

Table 16 shows the transit time between locations and the necessary turn time at each location. All times are defined in minutes. The turn time includes the necessary 93

time to prepare an aircraft for the next route segment. The turn time at the Depot is the time necessary to prepare an aircraft for another mission with a new crew. The planning algorithm to construct missions that pickup and deliver the requested shipments is shown in Figure 24. All nodes in the algorithm are referenced as either a decision or a process with a corresponding number. We define S as the first shipment on our sorted list of shipments and treat this list as a ‘pop-off’ list in which the shipment S is removed from the list after it is scheduled on a mission and the new shipment at the top of the list becomes S. To demonstrate the algorithm, we describe the construction of missions for this example.

Figure 24: Algorithm for planners to schedule shipments The algorithm begins with the given scenario data and shipment list as inputs. Since there are two available aircraft and 22 shipments to deliver, the algorithm moves to 94

from D1 to P1 and sorts the list by ALD, RDD, and priority. An empty mission 1 is created at P2. Adding the route segment Depot:E with shipment 11 and the required return to the Depot does not break the limit of 18 hours (P3 to D2). Thus, route segment Depot:E with shipment 11 is added to mission 1 (P4). Since there are still existing shipments (D3), the algorithm returns to P3 and considers adding route segments necessary to deliver S. This loop continues by adding route segment E:A and A:E with shipment 1, then shipment 5, followed by route segments E:D and D:B with shipment 2. The algorithm considers adding route segment B:D with shipment 6, but this exceeds the maximum route duration (D2). At this point, the routing of mission 1 is complete, as shown in Figure 25. Now at P5, the sorted list of remaining shipments is scanned and any shipments that can fit onto the route of mission 1, without adding any additional route segments, are added to the mission. This adds shipment 13 and shipment 8. A shipment does not necessarily need to go directly to its destination and can stay on an aircraft for multiple route segments if necessary. Mission 1 is now complete. Table 18 contains a summary of the actions taken in the planning algorithm and Table 18 summarizes the information contained in mission 1. TABLE 17: MISSION 1 CONSTRUCTION SUMMARY Action 1 2 3 4 5 6 7 8

Segment(s) Shipment Notes: Depot:E 11 E:A, A:E 1 5 No segments necessary E:D, D:B 2 B:D 6 Too long; not added B:Depot 13 8 95

TABLE 18: MISSION 1 INFORMATION Transit Segment APOE APOD Shipment Pallets Time 1 Depot E 11 1 72 1 Depot E 5 1 2 E A 8 1 87 3 A E 1 1 87 4 E D 87 5 D B 2 1 36 6 B Depot 13 1 135

Turn Time 135

Total Time 999

75 135 75 75

The algorithm continues by creating an empty mission for the second aircraft. Adding the route segment Depot:B and B:D with shipment 6 and the required return to the Depot does not break the limit of 18 hours (P3 to D2). Thus, route segments Depot:B and B:D with shipment 6 are added to mission 2 at P4. Since there are still existing shipments (D3), the algorithm returns to P3 and considers adding route segments necessary to deliver S. This loop continues by adding route segment D:E and D:Depot with shipment 10, then route segments B:C and C:B with shipment 7. Note: the route segments B:C and C:B are inserted before the existing route segment B:D since this is the most efficient placement of the additional route segments. The algorithm considers adding route segment E:B and B:E with shipment 9, but this exceeds the maximum route duration (D2). ). At this point, the routing of mission 2 is complete, as shown in Figure 25. Now at P5, the sorted list of remaining shipments is scanned and any shipments that can fit onto the route of mission 2, without adding any additional route segments, are added to the mission. This adds shipment 3 and shipment 4. Mission 2 is now complete.

96

Table 19 contains a summary of the actions taken in the planning algorithm and Table 20 summarizes the information contained in mission 2. The algorithm would continue by scheduling the next mission on second aircraft since its mission ends first. Additional missions would be scheduled until either no shipments or no available aircraft remained. TABLE 19: MISSION 2 CONSTRUCTION SUMMARY Action Segment(s) Depot:B, 1 B:D D:E, 2 E:Depot 3 B:C, C:B 4 E:B,B:E 5 6

Shipment Notes: 6 10 7 9 3 4

Insert before 2nd segment Too long; not inserted

TABLE 20: MISSION 2 INFORMATION Segment 1 2 3 4 5 6

APOE Depot B C B D E

APOD B C B D E Depot

Shipment 4 7 3 6

Pallets 10 7 1 8

10

7

97

Transit Time 135 32 32 36 87 72

Turn Time 75 75 75 75 135

Total Time 829

Route 1

Route 2

Figure 25: Route 1 and Route 2 labeled in sequential order of route segments.

98

Appendix B

Cargo Configurations

The C-17 has several different cargo configurations depending on its mission. For purposes of this research, we use three different cargo configurations: 18 pallets, 11 pallets/54 passengers, and 102 passengers, shown in Figure 26.

Regardless of the

configuration, the maximum allowable load weight is 170,900 pounds.

When only

carrying standardized pallets, known officially as 463L Master Pallets, the C-17 can fit two rows of 9 pallets for a total of 18 pallets. Two options are available when carrying passengers.

Seats lining the sides of the cargo compartment can be folded down

providing up to 54 seats. However, this limits capacity to 11 pallets. Additionally, a centerline of seating can be installed that provides space for up to 102 total passengers with no additional space for pallets.

Figure 26: C-17 cargo configurations 99

It is important to note that the cargo configuration of the aircraft can swiftly be adjusted upon landing at a port before loading new cargo. The centerline seating is carried aboard the aircraft at all times. We assume that the time to change the cargo configuration of the aircraft is negligible and thus allow the configuration to be changed at any stop on an aircraft’s route.

100

Appendix C

Data

Airbases ISAO OTBH ETAD ETAR FJDG FSIA HAGO HDAM HECA HKJK HKMO LTAG LTAU OAHR OAIX OAKB OAKN OAMS OATN OBBI OERY OJAM OJAQ OKAS OKBK OLBA OMAM OMFJ OOMA OOTH OP12 OPKC OPPI OPRN ORAA ORAT ORBD ORBI ORBM ORER ORKK ORMM ORQW ORSH ORSU ORTL ORUB UAFM UTAA

Latitude 25.1173 49.9727 49.4369 -7.3133 -4.6743 5.9351 11.5473 30.1219 -1.3171 -4.0268 37.0021 38.7704 34.2100 34.9461 34.5659 31.5058 36.7069 32.6042 26.2708 24.7098 31.9727 29.6116 29.3467 29.2266 33.8209 24.2482 25.1097 20.6754 17.6660 27.8466 24.9065 25.2905 33.6167 33.7813 33.3381 33.9402 33.2625 36.3058 36.2376 35.4695 30.5491 35.7672 34.6727 35.5609 30.9358 32.4818 43.0613 37.9868

Longitude 51.3150 6.6925 7.6003 72.4111 55.5218 43.5786 43.1595 31.4056 36.9308 39.5989 35.4259 35.4954 62.2283 69.2650 69.2123 65.8478 67.2097 65.8658 50.6336 46.7252 35.9916 35.0181 47.5208 47.9689 35.4884 54.5477 56.3306 58.8905 54.0246 65.1597 67.1608 63.3451 73.0992 42.4412 43.5971 44.3616 44.2346 43.1474 43.9632 44.3489 47.6621 43.1251 43.5429 45.3147 46.0901 45.7580 74.4776 58.3610

Turn Time (min) 195 135 135 135 135 135 135 135 135 135 135 135 75 75 75 75 75 75 135 135 135 135 135 135 135 135 135 135 135 135 135 135 135 75 75 75 75 75 75 75 75 75 75 75 75 75 135 135

101

Aircraft Name C-17

Speed (mph) 515

Max Load (lbs.) 170900

Parameters Maximum Route Duration (min) Passenger Weight (lbs.) Maximum Number of Splits (per shipment)

960 250 5

102

Scenario 1 ID 4597 4600 4603 4606 4609 4612 4615 4618 4621 4624 4627 4630 4633 4636 4639 4642 4645 4648 4651 4654 4657 4660 4663 4666 4669 4672 4675 4678 4681 4684 4687 4690 4693 4696 4699 4702 4705 4708 4711 4714 4717 4720 4723 4726 4729 4732 4735 4738 4741 4744 4747

APOE OKAS OTBH OKAS OTBH ORBI ORBD ORBD OKBK OTBH OKBK OTBH OKAS OTBH ORAT ORBD ORBD OKAS OKAS OAIX OTBH OKBK UAFM OOTH OKBK ORBD ORBD OTBH OAKN LTAG ORBD ORKK OAKN OKAS OTBH ORAA OKAS OKBK OTBH UAFM OKAS OKBK ORAA OAIX OAIX ORBD ORBD ORMM OKAS ORAT ORKK OKAS

APOD OAIX OKAS ORBI OOTH ORBD ORQW OKAS ORAT ORBD OAKB ORBI ORBD OKBK ORAA OTBH OKAS OAIX OTBH UAFM OOTH OAKB OAIX OTBH ORBD OKAS OKBK ORAT OAIX ORBD ORBI ORBD UAFM OAIX ORTL OTBH OTBH ORBI OKAS OAIX ORBD OAKB OKBK OKAS OAKN ORAT OKAS ORBI OAIX OKAS OTBH ORAT

PAL 1 3 1 12 0 4 4 5 3 18 0 0 6 15 18 0 0 0 2 1 18 1 17 4 2 6 0 8 2 1 1 1 5 0 0 1 6 0 0 1 18 5 5 6 7 0 0 9 0 1 0

PAX 67 11 113 0 10 1 12 0 0 0 5 21 0 0 3 1 87 29 12 0 0 10 0 0 30 0 2 54 0 25 2 5 61 2 2 131 0 2 7 51 0 0 63 2 5 144 180 70 132 0 48

103

Tons 1 4 1 22 0 7 6 10 13 56 0 0 10 28 35 0 0 0 4 0 45 1 31 7 3 11 0 38 8 3 2 3 20 0 0 1 10 0 0 1 56 8 10 10 13 0 0 16 0 0 0

ALD 213 213 213 213 213 213 213 213 213 213 213 213 213 213 213 213 213 213 214 214 214 214 214 214 214 214 214 214 214 214 214 214 214 215 215 215 215 215 215 215 215 215 215 215 215 215 215 215 215 215 215

RDD 214 214 214 219 214 214 214 216 215 217 218 218 214 218 215 214 214 214 215 215 216 219 215 215 215 215 221 216 215 216 218 221 216 219 217 221 222 216 216 216 217 216 216 216 221 217 216 216 216 216 218

Priority 3 3 2 1 3 2 3 1 2 1 1 1 2 1 2 3 3 3 3 3 2 1 3 2 3 3 1 2 2 2 1 1 2 1 2 1 1 2 2 2 2 3 2 3 1 2 3 3 3 2 1

Scenario 2 UID 4750 4753 4756 4759 4762 4765 4768 4771 4774 4777 4780 4783 4786 4789 4792 4795 4798 4801 4804 4807 4810 4813 4816 4819 4822 4825 4828 4831 4834 4837 4840 4843 4846 4849 4852 4855 4858 4861 4864 4867 4870 4873 4876 4879

APOE ORAT OKBK ORBM ORBI ORBD ORBM ORBI ORBD OKBK ORBM ORBI ORBM ORBI LTAG OTBH ORBM ORAT ORBM OAIX ORQW OKBK OKBK OTBH OKAS ORBI ORBI ORBI OTBH ORAT ORBD OAKN ORBD ORBD ORBI ORBD OTBH ORBI ORBD ORBI OKAS ORBD ORKK OKBK OKBK

APOD OKAS ORBD ORBI ORBM OKBK ORBI OTBH OKAS ORBD ORBI ORKK ORBI ORKK ORBD ORBM ORBI OKAS ORBI UAFM ORBD ORBD ORBD OAIX OTBH ORBD OKBK OKAS ORBD OKBK ORAT OAIX ORBI ORSH OTBH ORBI ORBI OKAS ORKK ORBD OTBH ORBI OKAS ORBD ORBI

PAL 0 4 0 0 7 0 0 1 8 0 0 0 0 6 1 0 0 0 1 17 8 8 18 7 2 1 0 6 8 3 0 12 4 5 2 11 0 3 6 0 11 0 15 4

PAX 123 0 88 2 0 140 33 1 0 102 144 102 67 0 1 133 102 135 3 5 0 0 0 4 3 0 2 0 0 0 22 0 0 1 14 0 2 0 0 54 1 8 0 0

104

Tons 0 7 0 0 13 0 0 2 14 0 0 0 0 28 1 0 0 0 0 31 14 14 38 13 3 5 0 11 14 11 0 21 16 24 2 19 0 13 26 0 19 0 28 8

ALD 216 216 216 216 216 216 216 216 216 216 216 216 216 216 216 216 216 216 216 217 217 217 217 217 217 217 217 217 217 217 217 217 217 217 217 217 217 217 217 217 217 217 218 218

RDD 221 221 218 218 217 218 219 222 222 217 222 219 222 217 220 217 219 220 217 220 218 218 219 223 218 218 218 218 220 218 219 224 220 218 218 222 221 218 219 218 218 219 224 219

Priority 1 1 2 2 3 2 1 1 1 3 1 1 1 2 1 3 1 1 3 1 2 2 2 1 3 3 3 3 1 2 2 1 1 3 2 1 1 2 2 3 3 2 1 3

4882 4885 4888 4891 4894 4897 4900 4903 4906 4909 4912 4915 4918 4921 4924 4927 4930

OTBH OTBH UAFM OTBH OKBK OAIX OTBH OAKN ORBD OAIX ORBD OAKB OKAS ORBI OAIX ORBD ORBI

OAIX OKAS OAIX OAKN ORBD OTBH OAKN OAIX OKBK OKAS ORTL OAKN ORBI OKAS OTBH ORBI OTBH

4 3 1 5 7 1 10 13 6 3 6 9 0 0 0 11 0

6 7 73 20 0 7 4 22 0 65 3 0 49 98 1 6 1

105

15 5 4 9 13 1 18 24 11 4 11 16 0 0 0 51 0

218 218 218 218 218 218 218 218 218 218 218 218 218 218 218 218 218

219 221 219 219 219 224 219 220 219 219 219 220 225 220 219 219 223

3 1 3 3 3 1 3 2 3 2 2 2 1 2 3 3 1

Scenario 3 UID 4932 4935 4938 4941 4944 4947 4950 4953 4956 4959 4962 4965 4968 4971 4974 4977 4980 4983 4986 4989 4992 4995 4998 5001 5004 5007 5010 5013 5016 5019 5022 5025 5028 5031 5034 5037 5040 5043 5046 5049 5052 5055 5058 5061

APOE OKAS OKBK OTBH OATN ORBI OKBK ORBD ORBD ORBI OTBH ORBD ORAT OAIX ORAA ORBM OKBK OMAM ORBD OTBH OTBH OOTH ORBM OKBK OTBH ORBD ORBD OTBH ORBD OKAS ORAA ORBI ORAA UAFM ORBD OKBK OTBH ORBD ORAA OBBI OKBK OKBK ORAT OTBH OAIX

APOD OAIX ORBI OAKN OAIX ORBD ORBD OKAS OKBK OMFJ ORBD ORAT ORAA OTBH OTBH OKAS ORBD OOTH OKBK ORBM ORBI OTBH OKAS ORBD ORBD OKAS OKBK ORAT ORBM ORBD OKBK OKAS OTBH UTAA OTBH ORBD ORBI OKBK ORBD HDAM ORAT ORBD OKBK ORBM OKAS

PAL 14 7 0 9 2 7 4 6 18 4 7 7 0 4 0 7 2 9 1 0 6 6 6 3 1 7 0 13 3 3 0 0 8 1 5 0 8 5 16 7 5 6 0 0

PAX 54 0 15 13 0 0 10 0 0 9 6 7 3 3 96 0 0 0 0 41 0 2 0 11 104 0 14 0 142 0 102 43 0 0 0 1 0 3 0 0 0 0 2 90

106

Tons 26 12 0 16 2 12 6 11 65 20 13 13 0 8 0 12 3 17 0 0 29 10 11 15 1 12 0 24 5 5 0 0 14 23 8 0 14 8 29 12 8 11 0 0

ALD 219 219 219 219 219 219 219 219 219 219 219 219 219 219 220 220 220 220 220 220 220 220 220 220 220 220 220 220 220 220 220 220 220 221 221 221 221 221 221 221 221 221 221 221

RDD 220 226 220 224 221 224 220 220 220 225 220 220 225 223 221 222 221 224 221 221 225 222 222 221 221 221 226 221 221 227 225 221 221 222 224 227 223 222 226 222 222 225 226 222

Priority 3 1 3 1 2 1 3 2 3 1 3 2 1 1 3 2 2 1 3 3 1 2 2 3 3 3 1 2 2 1 1 3 2 3 1 1 2 2 1 2 3 1 1 3

5064 5067 5070 5073 5076 5079 5082 5085

HDAM OAKN OKAS OAIX OAIX ORBD ORBI ORBI

OTBH OTBH ORBI OKAS OTBH OKAS ORMM OTBH

1 2 0 1 1 0 0 1

3 7 50 90 31 13 180 0

107

0 6 0 0 4 0 0 1

221 221 221 221 221 221 221 221

222 222 227 224 223 226 222 222

2 2 1 1 2 1 3 3

Scenario 4 UID 5087 5090 5093 5096 5099 5102 5105 5108 5111 5114 5117 5120 5123 5126 5129 5132 5135 5138 5141 5144 5149 5152 5155 5158 5161 5164 5167 5170 5173 5176 5179 5182 5185 5188 5191 5194 5197 5200 5203 5206 5209 5212

APOE OTBH OKAS OTBH ORBI OKAS UAFM ORBD ORAT ORBD LTAG OTBH ORSH OKAS ORAA OTBH OKBK ORTL OMAM ORBI ORBD OKAS ORBD ORBI HDAM OKAS OAIX OKBK OTBH ORBI OKAS OKBK ORBD OTBH ORBD OTBH ORBD OKAS ORBD ORAT OAIX OKAS OKAS

APOD OKAS ORBI OKAS OKAS ORQW OAIX ORAT ORAA OTBH ORBD ORBD ORBD OTBH ORBD OKAS ORBI ORBI OTBH ORBD OKAS ORBD ORBI OKAS OTBH OTBH UAFM ORBI OAIX OKBK ORBD ORAT OKAS ORBD OKBK OAIX ORBI ORAT OKAS OKAS OTBH OTBH OAIX

PAL 0 3 3 0 1 7 2 6 2 18 1 6 0 3 3 2 0 1 0 3 3 2 0 1 2 0 8 0 6 0 9 1 6 6 0 1 1 0 1 1 0 0

PAX 79 76 0 23 18 11 3 0 13 0 3 2 127 6 53 0 1 0 9 8 5 0 127 1 40 15 0 10 0 3 0 144 1 0 22 3 17 8 101 26 35 74

108

Tons 0 6 5 0 0 13 6 11 9 40 1 10 0 4 5 9 0 4 0 5 5 2 0 0 5 0 14 0 10 0 16 2 11 10 0 5 0 0 0 0 0 0

ALD 222 222 222 222 222 222 222 222 222 222 222 222 222 222 223 223 223 223 223 223 223 223 223 223 223 223 224 224 224 224 224 224 224 224 224 224 224 224 224 224 224 224

RDD 226 225 223 224 225 223 227 226 223 228 228 223 223 223 228 224 225 224 224 224 229 230 225 228 224 224 225 226 225 230 225 231 229 225 231 230 225 225 225 226 225 230

Priority 1 1 3 2 1 2 1 1 3 1 1 3 3 2 1 3 2 3 2 3 1 1 2 1 3 3 2 2 3 1 3 1 1 3 1 1 3 3 3 2 3 1

Scenario 5 UID 5214 5217 5220 5223 5226 5229 5232 5235 5238 5241 5244 5247 5250 5256 5259 5262 5265 5268 5271 5274 5277 5280 5283 5286 5289 5292 5295 5298 5304 5307 5310 5313 5316 5319 5322 5325 5328 5331 5334 5337 5340 5343 5346

APOE ORAA OKBK OTBH ORMM LTAG OTBH OKAS OKBK ORBI ORBD OKAS OKAS ORBI OAIX OKBK OKAS UAFM ORBI OKBK OTBH ORAT ORAT OTBH OKAS OTBH OTBH ORAT OTBH OKAS OKBK OKBK ORBD OTBH ORBI ORBI OKBK ORQW ORBD OTBH ORBD ORBD OTBH OKAS

APOD OTBH ORAT OKAS ORSU ORBD ORBI ORSH ORBD ORBD OKBK ORBM ORBD OTBH UAFM ORBD ORBI OAIX ORBD ORAT ORBD OKBK ORAA OKAS ORAA OAIX OKAS OKAS OKBK OTBH ORBD ORBD OKBK ORBI OTBH OKAS ORBI ORBI OKBK ORAA ORQW ORBI OBBI OTBH

PAL 0 8 0 0 3 0 0 4 0 7 0 6 0 6 4 0 0 0 9 2 8 9 2 7 8 2 0 1 3 5 5 15 0 0 0 4 0 4 0 0 2 1 0

PAX 46 0 33 180 0 3 82 0 6 0 9 32 44 3 0 63 142 1 0 54 0 0 0 3 0 0 102 0 0 0 0 0 1 9 1 0 65 0 35 7 7 0 14

109

Tons 0 15 0 0 13 0 0 6 0 12 0 11 0 11 8 0 0 0 15 7 14 16 9 13 14 6 0 1 11 23 9 27 0 0 0 8 0 6 0 0 2 0 0

ALD 225 225 225 225 225 225 225 225 225 225 225 225 225 226 226 226 226 226 226 226 226 226 226 226 226 226 226 226 227 227 227 227 227 227 227 227 227 227 227 227 227 227 227

RDD 230 226 231 226 227 230 227 230 226 226 226 232 226 233 229 227 227 227 232 230 228 227 227 233 227 227 230 227 228 229 228 228 228 231 230 229 228 231 228 233 231 228 228

Priority 1 3 1 3 2 1 2 1 2 2 2 1 2 1 1 2 3 3 1 1 2 3 3 1 3 3 1 3 3 2 3 3 3 1 1 2 3 1 3 1 1 3 3

Scenario 6 UID 5354 5355 5356 5357 5358 5359 5360 5361 5362 5363 5364 5365 5366 5367 5368 5369 5370 5371 5372 5373 5374 5375 5376 5377 5378 5379 5380 5381 5382 5383 5384 5385 5386 5387 5388 5389 5390 5391 5392 5393 5394 5395 5396 5397

APOE OAIX OKAS OTBH OAIX OKBK OKAS OKBK UAFM OKAS ORBI ORBD OKAS OTBH ORBI ORBD OTBH ORKK ORBD OTBH OAKN LTAG UAFM OAIX OKAS ORBM ORBD LTAG OTBH OKAS ORBD ORBI OAIX ORBD OTBH ORBD OAIX ORBD ORBD ORKK ORBI OTBH OKAS ORAT OKAS

APOD UAFM ORKK OKAS OTBH ORBI ORBI ORBD OAIX ORBD ORBD ORBI ORKK ORBD OKAS OKAS OAKN OTBH ORBM OAIX OAIX ORBD OKAS OKAS ORBD OKAS ORBI ORBD ORBD ORBI ORBI ORBD OTBH ORKK ORAT ORAT OTBH ORBI ORBI ORBD OKAS OKAS OTBH ORAA OAIX

PAL 2 12 3 7 5 0 5 0 0 0 9 15 3 0 3 5 1 12 1 3 2 0 3 2 4 0 7 3 0 1 1 15 1 0 4 1 18 3 2 1 0 7 2 7

PAX 85 2 30 51 0 62 0 92 82 1 0 1 2 1 60 0 0 13 0 0 0 2 107 40 0 1 0 1 104 7 0 0 15 37 0 6 0 0 5 52 7 46 0 69

110

Tons 3 22 5 13 9 0 9 0 0 0 15 28 12 0 5 21 5 22 0 10 4 0 5 9 17 0 34 10 0 1 0 27 3 0 6 2 48 12 6 1 0 12 10 13

ALD 228 228 228 228 228 228 228 228 228 228 228 228 228 228 228 228 228 228 228 228 228 228 228 228 228 228 228 228 228 228 228 228 228 228 228 228 228 228 228 228 228 228 228 228

RDD 235 229 229 232 232 234 229 229 229 231 229 235 229 230 232 230 231 233 229 231 229 235 229 229 235 230 229 229 229 231 235 229 229 229 235 229 229 229 230 230 229 229 234 232

Priority 1 3 3 1 1 1 3 3 3 1 3 1 2 2 1 2 1 1 2 1 3 1 3 2 1 2 3 3 2 1 1 3 3 2 1 3 3 3 2 2 3 2 1 1

5398 5399 5404 5405 5406 5407 5408 5409 5410 5411 5412 5413 5414 5415 5416 5417 5418 5419 5420 5421 5422 5423 5424 5425 5426 5427 5428 5429 5430 5431 5432 5433 5434 5435 5436 5437 5438 5439 5440 5441 5446 5447 5448 5449 5450

OKAS ORBI ORKK OTBH OKBK OKBK OKBK ORBD OTBH ORBD ORSH UAFM OTBH OKAS OKAS OTBH OKAS OTBH OTBH ORBI OAIX OTBH ORBD OKAS OAIX ORBI ORBD ORKK OAIX OAKN OTBH OKAS OTBH ORBI OKAS ORBD OKAS ORBD OKAS ORBI OTBH OAIX OKAS OKBK OTBH

ORKK OTBH OKBK OKAS ORBD ORBD ORAA ORSH OKAS OKBK OKBK OAIX OAIX OAIX ORBI OKAS ORKK ORBD ORBD ORBD OAKN ORAT ORAT OTBH OTBH OKAS OKAS ORBI OKAS UAFM OAIX OAIX OKAS OTBH ORBD ORAA ORBI ORBI OAIX OKAS OKAS UAFM UAFM ORBI OAIX

14 0 1 1 4 4 18 4 3 9 8 0 0 10 0 14 1 2 0 0 5 0 1 1 0 0 1 5 4 5 0 18 3 5 1 1 0 5 4 0 0 2 3 7 0

0 3 3 33 0 0 0 0 11 0 0 8 7 0 123 5 99 10 14 1 25 2 10 0 9 2 131 23 90 2 7 0 0 50 119 2 14 0 83 142 30 29 0 0 3

111

26 0 1 1 6 6 33 8 4 18 15 0 0 47 0 26 1 9 0 0 23 0 0 0 0 0 1 22 7 23 0 37 11 24 0 2 0 8 7 0 0 5 5 13 0

228 228 229 229 229 229 229 229 229 229 229 229 229 229 229 229 229 229 229 229 229 229 229 229 229 229 229 229 229 229 229 229 229 229 229 229 229 229 229 229 230 230 230 230 230

233 229 234 236 230 230 231 232 230 236 230 230 230 230 230 232 234 232 232 231 230 231 230 230 231 231 233 230 231 230 233 231 235 230 230 234 230 235 234 231 231 232 233 237 235

1 3 1 1 3 3 2 1 2 1 3 3 3 3 3 1 1 1 1 2 3 2 3 2 2 2 1 2 2 3 1 2 1 2 2 1 3 1 1 2 3 2 1 1 1

5451 5452 5453 5454 5455 5456 5457 5458 5459 5460 5461 5462 5463 5464 5465 5466 5467 5468 5469 5470 5471 5472 5473 5474 5475 5476 5477 5478 5479 5480 5481

OKAS OKBK OTBH OKAS ORAT ORSH ORBD UAFM OKAS OKBK ORQW OKAS OAIX ORBD ORBI OKBK OTBH ORBD OTBH ORBI ORBD OAIX OTBH OTBH OAKN ORAT OKAS LTAG ORBD ORBD OAIX

OAIX ORBD OKAS ORSH ORAA ORQW OKBK OAIX ORBD ORBD ORSH ORBI OTBH ORSH ORBD ORBI ORBI OKBK OAKN OKAS OKAS OKAS ORAT OAIX OAIX ORAA ORBD ORBD ORBI ORBM OTBH

15 4 1 18 13 1 9 2 6 4 9 2 0 11 1 5 1 9 2 0 3 1 1 2 7 7 1 12 2 4 7

0 0 59 0 0 0 0 7 0 0 4 145 3 0 18 0 30 0 6 1 9 70 2 34 0 0 144 0 10 5 23

112

28 6 1 35 23 1 16 9 10 7 16 3 0 20 4 9 1 17 8 0 4 0 0 3 34 13 1 21 6 16 12

230 230 230 230 230 230 230 230 230 230 230 230 230 230 230 230 230 230 230 230 230 230 230 230 230 230 230 230 230 230 230

231 231 235 231 231 232 232 231 231 231 234 231 231 232 232 231 231 231 231 231 231 231 234 232 233 237 234 233 235 237 231

3 3 1 2 3 2 2 3 2 3 1 3 3 2 2 3 3 2 3 3 3 3 1 2 1 1 1 1 1 1 3

Scenario 7 UID 5486 5487 5488 5489 5490 5491 5492 5493 5494 5495 5496 5497 5498 5499 5500 5501 5502 5503 5504 5505 5506 5507 5508 5509 5510 5511 5512 5513 5514 5515 5516 5517 5518 5519 5520 5521 5522 5523 5524 5525 5526 5527 5528 5529

APOE OAIX OKBK OTBH ORAA ORBD OKAS OKBK OTBH OKBK ORBD OKAS OKBK OKAS ORAA UAFM ORKK OKAS ORBI ORBD OKBK OTBH OTBH ORBD OKAS UAFM ORBD OTBH ORBD OTBH LTAG ORBD OAIX ORAT ORKK ORBD OAIX OKAS OAKN ORSH ORBD ORAA OTBH OAKN HDAM

APOD UAFM ORBD OKBK OTBH OTBH OTBH ORBD OKAS ORAA OKBK ORKK ORBI ORBI OKBK OAIX OKAS ORBD ORBD OTBH ORBD ORBD OAKN OKAS ORKK OAIX OTBH ORAT ORAT HDAM ORBD OKBK OKAS ORAA OTBH ORSH OAKN ORBD OTBH ORBD ORBI OTBH ORBD UAFM OTBH

PAL 1 11 1 1 0 1 7 5 5 6 0 12 0 2 0 1 0 0 0 5 9 1 2 0 5 6 3 9 1 5 7 2 13 1 2 1 5 0 10 1 2 7 1 1

PAX 14 0 0 0 1 71 0 6 0 0 96 0 5 0 98 31 109 9 3 0 36 8 141 100 21 0 0 19 7 0 0 85 0 0 19 29 133 2 8 17 10 1 4 4

113

Tons 2 21 0 1 0 3 12 8 8 10 0 22 0 3 0 1 0 0 0 8 17 1 3 0 25 11 6 16 0 24 12 4 23 1 2 1 9 0 18 1 6 33 0 5

ALD 231 231 231 231 231 231 231 231 231 231 231 231 231 231 231 231 231 231 231 231 231 231 231 231 231 231 231 231 231 231 231 231 231 231 231 231 231 231 231 231 231 231 231 231

RDD 232 233 235 232 232 232 232 235 233 235 237 233 234 237 232 233 232 238 232 232 232 232 237 232 232 232 232 232 232 237 232 233 232 235 232 232 232 235 233 233 233 235 233 233

Priority 3 2 1 2 3 2 3 1 2 1 1 2 1 1 3 2 3 1 3 3 3 3 1 3 3 3 3 2 2 1 3 2 3 1 3 3 2 1 2 2 2 1 2 2

5530 5531 5532 5533 5534 5535 5536 5537 5538 5539 5540 5541 5542 5543 5544 5545 5546 5547 5548 5549 5550 5551 5552 5553 5554 5555 5556 5557 5558 5559 5560 5561 5562 5563 5564 5565 5566 5567 5568 5569 5570 5571 5572 5573 5574

ORBD ORBI ORBD OKAS HDAM OTBH ORKK OTBH ORBI OKAS OAIX ORBD LTAG OMAM OBBI OTBH OKBK OTBH OKBK OKAS OKAS OTBH OTBH OKAS ORBD ORBI UAFM OTBH OOTH OTBH ORBD LTAG OKBK OTBH OKAS ORBI OKBK UAFM OTBH OKAS ORAT ORBI ORBD ORBD ORBD

OKAS OKAS ORKK OAIX OBBI OBBI ORBD OMAM OTBH OTBH UAFM OKAS OKAS OTBH OTBH ORBD ORBD OKAS ORBI ORUB OTBH OOTH ORBI ORBI OKBK OKBK OAIX OKAS OTBH OAIX OAIX ORBD ORAT ORBD ORBD ORBD ORBD OAIX ORBD ORBD OKBK OKAS OKAS ORTL ORBI

0 0 11 6 1 1 8 4 0 0 2 7 1 10 4 0 9 2 6 0 3 7 1 1 9 9 3 5 12 0 0 13 9 1 0 2 5 9 0 9 6 1 2 4 4

49 10 31 25 4 0 1 2 1 19 27 9 0 8 0 1 0 36 0 100 6 0 0 129 0 0 40 0 0 5 1 0 0 0 3 3 0 0 33 1 0 2 113 16 0

114

0 0 19 11 1 1 15 23 0 0 3 12 0 18 15 0 17 2 10 0 14 12 0 1 23 19 11 8 21 0 0 24 20 0 0 2 9 43 0 16 10 0 3 7 7

231 231 231 231 231 231 231 231 231 231 231 231 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232

233 235 232 232 236 232 232 237 233 232 232 232 234 235 235 235 233 234 233 236 234 239 235 234 233 233 236 234 236 236 233 236 233 233 233 236 236 233 233 233 233 233 234 235 238

2 1 2 2 1 2 2 1 2 3 2 2 2 1 1 1 3 2 3 1 2 1 1 2 2 2 1 2 1 1 3 1 3 2 3 1 1 3 3 3 3 3 2 1 1

5575 5576 5577 5578 5579 5580 5581 5582 5583 5584 5585 5586 5587 5588 5589 5590 5591 5592 5593 5594 5595 5596 5597 5598 5599 5600 5601 5602 5603 5604 5605 5606 5607 5608 5609 5610 5611 5612 5613 5614 5615 5616 5617 5618 5619

ORBD OTBH OKBK OKAS OAIX OAIX OTBH ORBM OKAS ORAT OTBH ORTL OKAS ORBD OAIX OTBH ORAA ORBD OAIX ORBI ORBD ORBM ORBD OTBH OAIX OAKN ORBI ORAA OKAS ORBD OMAM OKAS OTBH UAFM OKBK ORBI OTBH OAIX OKBK OKBK OKAS ORBD UAFM OKAS ORBI

ORBM OAIX OAIX ORBM OKAS OTBH ORAT ORBD ORBD ORAA OAIX ORBD ORBI ORBI OAKN ORBD OKBK OKBK OTBH OKAS ORBI OTBH OTBH OMAM UAFM UAFM ORBD OTBH OAIX ORBI OTBH OTBH OKAS OAIX ORBD OTBH OKAS UAFM ORAT ORBI ORUB OKBK OAIX ORBI OKBK

5 0 13 1 1 1 1 16 1 4 5 13 0 2 1 7 11 8 1 0 18 0 4 1 1 0 3 0 11 4 6 2 2 2 8 2 0 1 5 5 0 23 0 1 1

4 59 0 1 80 16 0 8 75 0 0 1 2 17 14 2 0 0 13 118 0 27 26 10 0 4 0 42 69 0 2 12 3 51 0 23 18 79 0 0 150 6 72 144 0

115

25 0 26 1 3 0 0 30 1 17 21 23 0 3 1 13 21 36 0 0 41 0 8 0 1 0 4 0 20 16 11 2 7 9 38 6 0 2 8 9 0 43 0 0 0

232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 232 233 233 233 233 233 233 233 233 233 233 233 233

233 233 233 236 234 236 234 236 233 233 234 237 239 233 233 233 234 238 235 239 235 234 233 234 238 233 235 235 234 233 239 233 233 234 235 235 240 235 237 238 234 240 237 236 234

3 2 3 1 2 1 2 1 3 3 2 1 1 2 3 3 2 1 1 1 1 2 2 2 1 2 1 1 2 3 1 2 3 3 2 2 1 2 1 1 3 1 1 1 3

5620 5621 5622 5623 5624 5625 5626 5627 5628 5629 5630 5631 5632 5633 5634 5635 5636 5637 5638 5639 5640 5641 5642 5643 5644 5645 5646 5647 5648 5649 5650 5651 5652 5653 5654 5655 5656 5657 5658 5659 5660 5661 5662

ORBI OTBH ORAT OTBH OTBH ORBI ORBD OKAS OOTH OKBK OAIX OTBH OKBK OKAS OTBH ORBD ORBD ORSH ORBI OTBH OKAS ORAT OTBH OTBH OKBK OTBH OAKN LTAG ORAA ORBD OKAS OKAS ORKK OTBH OKAS OAIX OTBH ORBD OAKN OAIX ORKK OAIX OKAS

ORBD OKAS OKBK OKBK OKAS OKAS OKAS ORUB OTBH ORSH OKAS ORBD ORBD ORBI ORAT ORAT ORBI OKBK OKAS OAKN OAKB ORAA OKAS OAIX OAIX OAIX OAIX ORBD OTBH ORKK OTBH OAIX ORBD ORKK ORKK OTBH OKAS LTAG OTBH OTBH OTBH UAFM ORBD

0 1 7 1 1 0 0 0 14 5 0 1 6 1 1 4 7 4 1 5 7 8 1 1 14 6 1 6 1 5 3 4 5 1 1 2 0 1 6 0 1 1 0

2 1 0 0 0 13 63 142 0 0 54 2 0 141 41 9 0 0 65 12 0 2 0 12 0 22 3 0 2 3 0 99 4 0 143 1 2 0 14 19 1 42 103

116

0 0 12 2 2 0 0 0 26 8 0 4 11 1 1 7 12 6 0 9 13 14 2 0 27 10 0 26 0 21 5 7 8 0 1 4 0 0 10 0 0 2 0

233 233 233 233 233 233 233 233 233 233 233 233 233 233 233 233 233 233 233 233 233 233 233 233 233 233 233 233 233 233 233 233 233 233 233 233 233 233 233 233 233 233 233

234 234 239 237 236 236 236 236 237 234 240 234 234 235 234 234 239 240 234 240 234 238 240 234 235 234 239 235 234 235 234 234 235 234 234 239 234 235 235 240 235 237 235

3 3 1 1 1 1 1 1 1 3 1 3 2 2 3 3 1 1 3 1 3 1 1 2 2 2 1 2 3 2 3 3 2 3 2 1 3 2 2 1 2 1 2

Scenario 8 UID 5663 5664 5665 5666 5667 5668 5669 5670 5671 5672 5673 5674 5675 5676 5677 5678 5679 5680 5681 5682 5683 5684 5685 5686 5687 5688 5689 5690 5691 5692 5693 5694 5695 5696 5697 5698 5699 5700 5701 5702 5703 5704 5705 5706

APOE ORBD OKBK OTBH OKBK OKBK OTBH OKAS OTBH UAFM OKAS OBBI OKAS ORBD OKAS ORBI OBBI OKBK OTBH ORBI OKBK OTBH OTBH ORBD ORBI ORBD OBBI LTAG ORSH ORBD OAIX OKAS LTAG ORBD OKAS ORSH ORBD ORBI ORQW UAFM UAFM OKAS ORSH ORBD OTBH

APOD OKAS ORBD OBBI ORBI ORBI OKAS ORBD OBBI OAIX ORBI ORBI OTBH OTBH ORBD ORBD ORAA ORBI ORBD OKAS ORBD OKAS ORSH ORSH OKAS OKAS OTBH ORBD ORBD OKBK OKAS ORBI ORQW ORQW ORSH OKAS OKAS OTBH ORBD OAIX OAIX ORBD OKAS ORBI OKAS

PAL 1 23 2 7 6 0 1 1 13 1 6 1 1 0 0 1 7 3 0 6 2 0 9 0 1 1 2 1 9 0 0 1 3 0 0 3 5 7 7 2 0 2 1 1

PAX 13 0 0 0 0 6 102 0 12 110 0 0 62 15 19 0 0 16 39 0 0 2 30 83 14 0 0 19 0 76 101 0 21 144 23 10 13 19 5 0 144 79 11 0

117

Tons 2 43 6 12 11 0 0 0 23 2 29 2 0 0 0 0 13 15 0 10 3 0 17 0 2 2 8 1 18 0 0 4 4 0 0 4 22 13 34 3 0 3 0 1

ALD 234 234 234 234 234 234 234 234 234 234 234 234 234 234 234 234 234 234 234 234 234 234 234 234 234 234 234 234 234 234 234 234 234 234 234 234 234 234 234 234 234 234 234 234

RDD 235 235 235 235 235 235 236 235 240 239 240 235 235 235 235 241 235 235 240 235 241 235 235 235 236 235 235 235 235 239 236 235 235 235 238 237 237 236 237 236 238 235 235 235

Priority 2 3 3 3 3 3 2 3 1 1 1 3 3 2 3 1 3 2 1 3 1 3 3 3 2 3 3 3 2 1 2 2 3 3 1 1 1 2 1 2 1 3 2 3

5707 5708 5709 5710 5711 5712 5713 5714 5715 5716 5717 5718 5719 5720 5721 5722 5723 5724 5725 5726 5727 5728 5729 5730 5731 5732 5733 5734 5735 5736 5737 5738 5739 5740 5741 5742 5743 5744 5745 5746 5747 5748 5749 5750 5751

OTBH OKAS OKAS ORBD ORBI ORAA OKAS OAIX ORAT OTBH OKAS OKAS OKBK OKBK ORAA OTBH OTBH OKAS OKAS OKAS OTBH ORAT ORAT ORBI UAFM ORSH ORAT OKAS OKAS ORBD ORBD OKAS ORBD OKAS OKAS OKBK OKBK OTBH ORSH ORBI OAIX ORBD OKAS OKAS OKAS

ORAA OTBH OAIX OKAS OKAS OKAS ORAT UAFM OKAS OKAS ORAA OTBH ORAT ORAT OKAS OKAS ORBI ORBI ORSH ORAT OKAS ORBD ORBD ORBD OAIX OKAS OTBH OTBH ORSH OKBK OKBK ORSH OKAS ORSH ORBD ORBI ORBD OAKN OKAS OKBK OKAS OKBK ORSH ORSH ORBD

3 4 11 0 0 0 0 5 1 1 0 3 9 4 0 1 0 1 0 0 0 7 8 5 6 4 1 2 1 9 7 0 1 2 2 3 5 1 0 1 2 4 0 0 3

41 22 64 88 40 100 123 20 43 60 83 35 0 0 49 0 1 142 136 115 1 0 0 12 1 10 0 0 142 0 0 144 140 143 0 0 0 25 1 0 81 0 134 137 144

118

2 6 21 0 0 0 0 9 0 2 0 4 23 7 0 0 0 2 0 0 0 12 13 9 11 7 0 6 1 17 13 0 2 4 3 5 8 1 0 1 9 7 0 0 4

234 234 234 234 234 234 234 234 235 235 235 235 235 235 235 235 235 235 235 235 235 235 235 235 235 235 235 235 235 235 235 235 235 235 235 235 235 235 235 235 235 235 235 235 235

235 237 235 236 235 236 235 235 239 237 237 236 236 237 236 237 236 237 237 236 236 242 236 237 240 237 236 236 236 236 238 236 239 237 236 236 236 236 236 240 236 237 242 236 236

3 1 2 2 3 2 3 3 1 2 2 3 3 2 3 2 2 2 2 3 3 1 3 2 1 2 3 3 2 2 1 2 1 2 2 3 3 3 3 1 3 2 1 3 3

5752 5753 5754 5755 5756 5757 5758 5759 5760 5761 5762 5763 5764 5765 5766 5767 5768 5769 5770 5771 5772 5773 5774 5775 5776 5777 5778 5779 5780 5781 5782 5783 5784 5785 5786 5787 5788 5789 5790 5791 5792 5793 5794 5795 5796

OTBH OAKN LTAG ORBD LTAG ORBD ORSH OTBH ORKK LTAG ORBD ORBI OKAS OAKN OAIX OKAS ORBD OKAS OKAS ORSH OAIX ORSH OKAS OTBH OKBK OKAS OTBH OKBK ORSH OTBH ORBD OTBH OKAS OTBH OKAS ORBI OKAS UAFM OKAS OKBK OKBK OAIX ORBI ORBD OTBH

OAIX OAIX ORBD ORBI ORKK ORKK OKAS OKAS ORBD ORBD OKAS OKAS OAIX OTBH OTBH ORSH OTBH ORSH OTBH OKAS UAFM OKAS ORSH OKAS ORBD ORSH OKAS ORBI OTBH OKAS OKBK ORBI ORBI OAIX ORKK ORBD ORBD OAIX ORSH ORBI ORBD OAKN OKAS OKAS ORSH

4 2 3 1 2 0 0 1 5 11 0 0 0 0 4 0 8 0 3 0 2 0 0 3 4 0 3 7 0 1 9 0 0 17 0 1 0 0 0 4 4 12 0 1 1

21 0 0 9 0 6 2 3 6 0 4 11 96 5 21 144 5 144 61 3 3 139 144 19 0 119 0 0 2 0 0 35 57 2 115 10 24 104 144 0 0 1 4 58 1

119

15 3 5 4 8 0 0 3 9 20 0 0 0 0 8 0 14 0 5 0 6 0 0 4 7 0 4 13 0 1 20 0 0 32 0 4 0 0 0 8 7 22 0 2 0

235 235 235 235 235 235 235 235 235 235 235 235 235 235 235 235 235 235 235 235 235 236 236 236 236 236 236 236 236 236 236 236 236 236 236 236 236 236 236 236 236 236 236 236 236

236 236 242 239 240 236 237 241 240 236 236 236 236 238 240 236 238 236 236 236 236 237 238 237 237 237 238 237 242 237 237 241 237 237 238 238 237 237 237 237 239 240 237 240 237

2 2 1 1 1 2 2 1 1 2 3 2 2 1 1 3 1 3 2 3 2 2 2 3 2 3 2 3 1 3 2 1 3 3 2 2 2 2 3 2 1 1 3 1 2

5797 5798 5799 5800 5801 5802 5803 5804 5805 5806 5807 5808 5809 5810 5811 5812 5813 5814 5815 5816 5817 5818 5819 5820 5821

OKAS ORSH UAFM ORBD OKAS ORSH OKAS OKAS ORBD OAIX OKAS OAKN OKAS ORSH ORBD ORKK OTBH LTAG ORBD ORBD ORBI OTBH OKAS OKAS ORBM

ORSH OKAS OAKN OKBK OTBH OKAS ORKK ORSH ORAT OKAS ORBD OTBH ORSH OKAS ORBI OTBH ORBD ORBD ORBI ORBI OKAS OAIX OAIX OTBH OTBH

0 0 2 7 0 0 0 0 1 3 2 13 0 0 1 1 2 5 12 10 0 10 2 0 18

86 83 44 0 2 112 118 136 4 90 54 2 143 51 12 37 44 0 0 0 131 0 81 24 1

120

0 0 8 12 0 0 0 0 0 4 3 23 0 0 2 2 9 23 23 17 0 46 2 0 42

236 236 236 236 236 236 236 236 236 236 236 236 236 236 236 236 236 236 236 236 236 236 236 236 237

237 237 240 237 237 237 237 237 238 237 237 237 237 243 237 237 242 237 237 239 243 237 242 237 242

3 2 1 3 3 3 3 3 2 3 2 3 3 1 3 3 1 2 3 1 1 2 1 3 1

References AFDD:2-6 (2006). "Air Mobility Operations, Air Force Doctrine Document 2-6." Aleman, R. E. and R. R. Hill (2010). "A tabu search with vocabulary building approach for the vehicle routing problem with split demands." International Journal of Metaheuristics 1(1): 55-80. Archetti, C., D. Feillet, et al. (2009). "The capacitated team orienteering and profitable tour problems." Journal of the Operational Research Society 60(6): 831-842. Archetti, C. and M. G. Speranza (2008). The Split Delivery Vehicle Routing Problem: A Survey The Vehicle Routing Problem: Latest Advances and New Challenges. B. Golden, S. Raghavan and E. Wasil, Springer US. 43: 103-122. Archetti, C. and M. G. Speranza (2012). "Vehicle routing problems with split deliveries." International Transactions in Operational Research 19(1-2): 3-22. Archetti, C., M. G. Speranza, et al. (2006). "A Tabu Search Algorithm for the Split Delivery Vehicle Routing Problem." Transportation Science 40(1): 64-73. Archetti, C., M. G. Speranza, et al. (2008). "An optimization-based heuristic for the split delivery vehicle routing problem." Transportation Science 42(1): 22-31. Barnes, J. W., M. Ciarleglio, et al. (2010). "ConsNet-A tabu search approach to the spatially coherent conservation area network design problem." Journal of Heuristics 16(4): 537-557. Barnes, J. W., V. D. Wiley, et al. (2004). "Solving the aerial fleet refueling problem using group theoretic tabu search." Mathematical and Computer Modelling 39(6-8): 617-640. Boudia, M., C. Prins, et al. (2007). An effective memetic algorithm with population management for the split delivery vehicle routing problem. Proceedings of the 4th international conference on Hybrid metaheuristics. Dortmund, Germany, Springer-Verlag: 16-30. Boyd, J. (1976). Creation and Destruction, U.S. Army Command and Staff College. Boyd, J. (1995). The Essence of Winning and Losing. Burks, R. E., J. T. Moore, et al. (2010). "Solving the Theater Distribution Problem with Tabu Search." Military Operations Research 15(4): 5-26. Callander, B. (1998) "The Evolution of Air Mobility." Airforce Magazine 81. Carlton, W. B. and J. W. Barnes (1996). "A note on hashing functions and tabu search algorithms." European Journal of Operational Research 95(1): 237-239. Carlton, W. B. and J. W. Barnes (1996). "Solving the traveling-salesman problem with time windows using tabu search." Iie Transactions 28(8): 617-629. Chen, S., B. Golden, et al. (2007). "The split delivery vehicle routing problem: Applications, algorithms, test problems, and computational results." Networks 49(4): 318-329. Ciarleglio, M. (2007). Modular Abstract Self-Learning Tabu Search (MASTS) Metaheuristic Search Theory and Practice. 121

Ciarleglio, M. (2008). "A tabu search approach to the spatially coherent conservation area network design problem." Journal of Heuristics. Colletti, B. W. and J. W. Barnes (2000). "Linearity in the traveling salesman problem." Applied Mathematics Letters 13(3): 27-32. Colletti, B. W., J. W. Barnes, et al. (1999). "A note on characterizing the k-OPT neighborhood via group theory." Journal of Heuristics 5(1): 47-51. Cordeau, J.-F., G. Laporte, et al. (2008). Recent Models and Algorithms for One-to-One Pickup and Delivery Problems The Vehicle Routing Problem: Latest Advances and New Challenges. B. Golden, S. Raghavan and E. Wasil, Springer US. 43: 327-357. Cordeau, J., G. Laporte, et al. (2001). "A unified tabu searrch heurisitic for vehicle routing problems with time windows." Journal of Operational Research Society 52: 928-936. Cordeau, J., G. Laporte, et al. (2004). "Improved tabu search algorithm for the handling of route duration constraints in vehicle routing problems with time windows." Journal of the Operational Research Society 55: 542-546. Crino, J. R., J. T. Moore, et al. (2004). "Solving the theater distribution vehicle routing and scheduling problem using group theoretic tabu search." Mathematical and Computer Modelling 39(6-8): 599-616. Dantzig, G. B. and J. H. Ramser (1959). "The Truck Dispatching Problem." Management Science 6(1): 80-91. Dell'Amico, M. and M. Trubian (1993). "Applying tabu search to the job-shop scheduling problem." Annals of Operations Research 41(3): 231-252. Dror, M. and P. Trudeau (1989). "Savings by Split Delivery Routing." Transportation Science 23(2): 141-145. Fagerholt, K. and J. E. Korsvik (2010). "A tabu search heuristic for ship routing and scheduling with flexible cargo quantities." Journal of Heuristics 16(2): 117-137. Fagerholt, K., J. E. Korsvik, et al. (2009). "Ship Routing and Scheduling with Persistence and Distance Objectives." Innovations in Distribution Logistics 619: 89-107. Ho, S. C. and D. Haugland (2004). "A tabu search heuristic for the vehicle routing problem with time windows and split deliveries." Computers & Operations Research 31(12): 1947-1964. Jin, M., K. Liu, et al. (2008). "A column generation approach for the split delivery vehicle routing problem." Operations Research Letters 36(2): 265-270. Lambert, G. R., J. W. Barnes, et al. (2007). "A tabu search approach to the strategic airlift problem." Military Operations Research 12(3): 59-79. Laporte, G., J. E. Korsvik, et al. (2011). "A large neighbourhood search heuristic for ship routing and scheduling with split loads." Computers & Operations Research 38(2): 474-483. Moffett, A., J. S. Dyer, et al. (2006). "Integrating biodiversity representation with multiple criteria in North-Central Namibia using non-dominated alternatives and a modified analytic hierarchy process." Biological Conservation 129(2): 181-191. 122

Moore, J. T., J. W. Barnes, et al. (2009). Modeling the End-to-End Military Transportation Problem. Handbook of Military Industrial Engineering, CRC Press: 6-1-6-74. Nanry, W. P. and J. W. Barnes (2000). "Solving the pickup and delivery problem with time windows using reactive tabu search." Transportation Research Part BMethodological 34(2): 107-121. Nowak, M., O. Ergun, et al. (2008). "Pickup and delivery with split loads." Transportation Science 42(1): 32-43. Nowak, M. A. (2005). "The pickup and delivery problem with split loads." from http://etd.gatech.edu/theses/available/etd-07182005-134320/. Roesener, A. G., J. W. Barnes, et al. (2010). "An Advanced Tabu Search Approach to the Static Airlift Loading Problem." Military Operations Research 15(1): 5-29. Ropke, S. and D. Pisinger (2005). "An Adaptive Large Neighborhood Search Heuristic for the PDPTW." Saaty, T. L. (1994). "How to Make a Decision: The Analytic Hierarchy Process." Interfaces 24(6): 19-43. USAF. (2012). "Air Force Mission." Retrieved July, 2012, from http://www.af.mil/main/welcome.asp. Wattenberg, M. (1999). Visualizing the stock market. CHI '99 extended abstracts on Human factors in computing systems. Pittsburgh, Pennsylvania, ACM: 188-189.

123

Vita Kiel M. Martin was born in Ft Oglethorpe, GA. After attending Cumberland County High School, Crossville, TN, in 2001, he entered the United States Air Force Academy, Colorado Springs, CO.

He received a Bachelor’s of Science in both

Operations Research and Mathematics in 2005 and was commissioned as a Second Lieutenant in the United States Air Force. He was awarded the Draper Fellowship and attended Massachusetts Institute of Technology, Cambridge, MA, graduating with a master’s degree (SM) in Operations Research in 2007. Following an assignment to Nellis AFB, NV performing operational testing, Kiel began his doctoral studies at the University of Texas at Austin in the fall of 2009. His subsequent assignment is to Headquarters USAF/A9 at the Pentagon.

Email: [email protected] This dissertation was typed by the author.

124