1
Inventory Allocation an
d Transportation
Scheduling for
Logistics of
Network

Centric
Military Operations
1
F
rancisco
Barahona, P
awan
Chowdhary, M
arkus
Ettl,
P
u Huang,
Tracy Kimbrel,
L
aszlo
Ladanyi,
Young Lee,
B
aruch
Schieber,
Karthik Sourirajan,
M
axim
Svi
r
i
denko
and
G
rzegorz
Swirszcz
IBM
Thomas J. Watson
Research
Center
Yorktown Heights, NY 10598, USA
In t
his paper
we describe
a prototype inventory placement and transportation scheduling sol
u
tion
developed
in
support of
the emerging military doctrine
of
Network

Centric
Operations
. The
objective of the N
etwork

Centric
concept is to collect, disseminate, and react to real

time info
r
mation to improve the U.S. Army's performance as a fight
ing force. One problem that arises i
n
the logistics domain
is the m
aintenance of combat vehicles.
We seek to determine the improv
e
ment, if any, made possible by exploiting accurate
information on the status of avail
able repair
parts inventory,
the current locations of mobile sup
ply points, and
the demand for parts. We d
e
scribe logistics algorithms for maximizing operational availability of combat vehicles by produ
c
ing flexible, optimized inventory and delivery plans that decrease replenishment times and pr
i
o
r
itize parts allocations and repairs. Our algorithms are designe
d to leverage real

time info
r
mation available from modern communications and inventory tracking technology by
emplo
y
ing
state

of

the

art mathematical optimization models.
Our simulations indicate that
Network

Centric Logistics
can significantly improve co
mbat vehicle availability relative to current pra
c
tice.
1. Introduction
M
ilitary logistics
systems face a dynamic
and uncertain environment. The United States and
its
allies are confronted by
increasing number
s
of opportunistic adversaries and insurge
n
cies that
use unconventional
fighting tactics to nullify
an
overwhelming force advantage. The response
needs to be agile, adaptive and flexible in both military operations and logistics.
The current l
o
gistics system works
well
in
an
environment of relative
ly predictable demand, such as peacetime
1
U.S. Department of Defense Distribution Statement: Approved for Public Release, Distribution Unlimited
2
garrison operations or traditional
,
high
ly planned force

on

force o
perations. However, conve
n
tional logistics systems
often
break
down in
tod
ay’s military operations
invol
v
ing
rapid force

structure change, extremely
mobile forces, and
great
ly var
ying
demand
s.
To achieve
greater
flexibility
,
modern
logistics model
s require
new analytical tools and ex
e
cution model
s
with
greater adaptability and agility
.
In 2005,
the Defense A
d
vanced Research
Projects Agency (
DARPA
)
sp
onsored a Network

Centric Logistics (NCL) experiment to demo
n
strate
the effectiveness of dynamic configuration algorithms for tactical
ground logi
s
tics control.
The
objectives were to in
crease the
flexibility
of tactical supply cha
ins
and
to
i
m
prove
delive
ry
speed
by
tre
at
ing
tactical logistics as a dynamic configuration problem
and
by
co
ntrol
ling
phys
i
cal inventory and distribution with proven techniques from adaptive inventory management
sy
s
tems
.
In this paper, we demonstrate
how a dynamic multi

point sup
ply approach can in
crease
o
p
e
r
ational a
va
ilability
(defined later)
in a
volatile combat environment compared to
a
hierarchical
logistics
structure.
W
e d
e
scribe
the
logistics algorithms designed to achieve
our
goal
, which are
based on state

of

the

art mathe
mat
i
cal optimization models.
To
evaluate the concept, we have
conducted a series of experiments in which the
logistics
models are driven by
a
high

speed logi
s
tics simulation test
bed
(
which is beyond the scope of this paper)
.
It takes an operations plan
(O
PLAN) and generates detailed battlefield scenario data. The demonstration is driven by a fict
i
tious scenario lasting 30 days.
T
he
o
ptimization models
produce a plan for the
storage and d
e
livery of re
pair parts
for maintenance support
in a
single combat
br
i
gade
.
The
remainder of the
paper is
organized as follows.
Section 2 describes logistics challenges
encountered in today’s military operations and introduces Network

C
entric
L
ogistics co
n
cepts.
Section
3 describes the
inventory allocation problem
and the m
athematical algorithms
we use to
solve
it.
Section
4 introduces the transportation scheduling problem
,
and
the next four se
c
tions
de
scribe our
solution
.
Section 9
contains numerical results and
Section
10
co
n
cludes the paper
.
2.
The
Logistics Challenge
Our
problem setting
is based on a
projected
Army
logistics
sc
enario
. We focus
on the distrib
u
tion of
parts
inventor
ies
needed to
repair
combat vehicles
in
a
combat
brigade.
For the purpose of
this study, only critical
repair
parts, i.e., parts necessary to re
store vehicles to operational status,
are
considered.
The brigade consists of
several
combat
battalions
that are
supplied by a central
3
l
o
gistics depot
called the
Brigade Support Battal
ion or BSB
as shown in Figure 1.
A battalion is
composed of a group of
s
maller
operational
units
, most of which are called companies; we will
si
m
ply refer to all of these as companies
. These units need logistics support to meet their demand
for
spare
parts
.
This support is pr
o
vided by combined delivery and repair

team trucks;
however,
some parts are crew

replaceable and do not require the delivering truck to stay while its mecha
n
ics carry out the r
e
pair.
Figure
1
.
Testing environment based on a U.S. Army logistics scenario.
Lines denote examples
of
possible movements of parts between units.
The brigade is network

enabled and has continuous visibility of all its repair parts inventory,
both at the BSB level and at the company level down to the individual combat vehicles. Each
company can be considere
d to have a local stocking point (in actuality representing on

board
spares storage on the combat vehicles themselves). It is possible to transfer materiel between
companies and across battalions. The locations of the BSB and the oper
a
tional units change o
ver
time. NCL responds to supply needs by fulfilling demand as requested
continually,
allowing any
truck to serve any battalion. Widely distributed parts require intelligence to identify where a
needed supply part should come from and who should supply it.
This is called cross

leveling and
it might entail getting parts from different, rapidly changing locations. In this system
repair
parts
can be supplied from multiple sources including the BSB, pre

loaded stores on delivery and r
e
pair

team trucks, and even
from
other
combat vehicles pr
o
vided they carry on

board spares.
4
Although network enabled logistics structures and operating procedures do not currently e
x
ist, they are under development as part of the Army’s future combat system.
T
oday’s traditional
briga
de combat teams use hierarchical distribution techniques
in which
repair parts are located in
the BSB, parts requests are consolidated
by the subordinate units, and a single daily replenis
h
ment operation, called
a
logistics package, delivers parts to the s
ubordinate units. Each battalion
is se
r
viced only by trucks dedicated to it.
Figure
2
lists the main features contrasting
the concepts
of operation
for the
traditional
hierarchical logi
s
tics structure
(
b
aseline
)
and NCL
.
B
aseline
NCL
L
ocations of suppl
ies
C
entralized at BSB
P
artially distributed
—
some part
types are carried on

board
S
upply network
T
op

down hierarchy
F
lexible: any truck can serve any
battalion
M
ethod of distribution
D
aily batches using only
per

battalion
dedicated trucks
F
lexible

size b
atches using any
truck in brigade
D
ecision cycle
24 hours
A
s
frequent
as 1 hour
D
ecis ion crit eria
F
irs t

c
ome
firs t

s
erved
M
at hemat ical opt imizat ion us ed t o
maximi ze vehicle availabilit y
Figure
2
.
Logist ics operations for
the
ba
seline case
and NCL.
2.1
Measures of Performance
The
efficacy of the NCL
approach was
evaluated using
standard military utility testing and eva
l
uation methodologies
. For this
project,
DARPA
was interested in
in
creased o
perational
a
vai
l
a
bility
of combat v
ehicles
and reduced customer wait t
ime.
•
O
perational a
vailability
(
A
0
)
is a
measure of the time that a system’s capabilities are
available for operational use. It takes into a
c
count failure and repair information. This
dependent variable is measured at the
vehicle level and
summed over vehicles
.
Si
m
ple, unweighted
A
0
equals
the
time
a vehicle is working
divided by total time.
The
precise definition we use will be described later.
It includes time

varying relative
priorities of combat units corresponding to
their operations (for instance, a unit e
n
gaged in battle would be considered to have high priority).
5
•
C
ustomer wait t
ime
(
CWT
) is a
measure o
f time from request to delivery; in our case,
the
re
quest time is defined to be the
time
at which
a part breaks. CW
T is composed of
the time for administrative processing,
possibly time waiting for a part to arrive from
outside the brigade,
the time waiting for transportation
to begin, and
the
travel time or
total elapsed time spent getting
the part
from the supplier’s
loca
tion to the consumer
’s
location.
2.
3
Solu
tion Overview
Our solution consists of two ma
in
components,
an
i
nventory
allocation
module
and
a
t
ransport
a
tion
schedul
er as illustrated in Figure 3
.
The
i
nventory
allocation
module
takes as input
the
avai
l
a
ble
repair parts
in
ventory,
fore
cast
ed
b
reakages, and the future positions of the
operational
units
. It produces
an allocation
plan
for
each repair part and operational unit
in the brigade
over a
future planning horizon
of
up to
72 hours.
It
accounts for
s
torage capacit
y constraints
as well as
rel
a
tive priori
ties of the combat units
.
Figure
3
.
Functional design of the NCL logistics optimization
prototype
.
6
Th
e
t
ransportation
scheduling module
uses as input the current
locations
of
the (immob
i
lized)
broken
vehicles
, the
projected future movements of
other entities,
and the
allocation
plan
gene
r
ated by
the i
nventory
allocation module
. It produces a plan for delivering parts and ca
rrying out
repairs. This schedule
spec
i
fies
the spar
e parts to carry on each vehicle and the locations at
which to load and unload the parts. The primary objective is to deliver the spare parts needed to
repair
currently
broken
vehicles
. The secondary objective is to replenish the parts inventory at
the log
istics points to approach the levels specified by the
i
nventory
allocation module
. This a
l
lows repairs to begin immediately upon breakage (if the part is available in the same
unit
) or
very soon therea
f
ter (if the part is available in the same battalion) i
n the case of crew

replaceable
parts that are carried on

board.
The framework
allow
s
real

time adjustment of schedules and resource allocation
.
The
an
a
ly
t
ical modules
continually update the solutions in response to changing conditions. At
each time
incre
me
nt (which we will call an
iteration
) of a scenario simulation (we will call an individual
run with
its own se
t
tings of input parameters an
experiment
)
, the optimizer
s
receive
the current
state from the simulator and com
pute
an optimized delivery plan cover
ing the next 72 hours. The
simulator commits and executes the initial portion of the
plan
. As the simulated scenario evolves
and o
p
erational plans change,
vehicles
break down, new
repair
parts become available
,
etc.
,
t
he
simulator communicates these change
s to the optimizer
s
which pro
duce
a new
delivery plan
o
p
timi
zed for the new state
.
3
.
Inventory
Allocation
The goal of the
i
nventory
allocation
module
is to determine
pre

positioned levels of
supplies to
best
respond to future breakages
.
W
e develop
a
prac
tical heuristic
allocation model
that
uses
up

to

date information on available inventory, supply points, and demand
forecast
.
The model
re
c
ognizes
cross

leveling oppor
tunities,
accounts for movements of
operational
units within the br
i
gade
,
and deals with
short

term
sup
ply shortfalls
such as delayed deliver
ies
or
supply
shor
t
ages
that could lead to longer

term degradation of capability.
The inventory allocation is performed in
two
stage
s; the first stage
strive
s
to
achieve high
operational availability
,
and
the second stage
attempts to
further reduce customer wait times through strategic placements of inventory
.
The
allocation procedure is based on a
ssigning a
preference score computed from weighted fulfil
l
ment ratios and transportation lead times
to each co
mpany
to identify stocking points that can
7
efficiently
cross

fill demand at neighboring companies. Allocating inventory based on the pre
f
erence score minimizes customer wait time, which in turn maximizes fleet availability.
Although
the proposed inventory
allocation sol
u
tion is a practical heuristic that is not in general optimal,
we will show in section 9 that a key performance utility commonly used by the US Army, oper
a
tional availability, can be improved by roughly 10 percent when
it is
applied under a r
ealistic
military force sc
e
nario.
T
he academic literature presents a large body of research on inventory

service tradeoff mo
d
els. However,
none of
the traditional approaches deal
with dynamic supply chains or multiple
sour
c
ing in the context of optimizatio
n. We therefore propose a heuristic algorithm that leverages
ea
r
lier work on service

level optimization in commercial supply chains, implosion techniques for
manufacturing, and inventory allocation in service

after

sales networks (
Ettl et al.
[1]
;
Deshpand
e et al. [2]
;
Graves and Willems
[3]
;
Muckstadt
[4]
;
Cheng et al.
[5]
; Dietrich
et al.
[6]
).
In contrast to conventional inventory systems and methods, the proposed algorithm can deal
with mobile entities that may change loc
a
tions during a planning horizon
. Furthermore, it does
not rely upon static sourcing relationships to allocate inventory but instead manages the alloc
a
tion of inventory to each entity dynamically by exploiting opportun
ities for multiple sourcing,
cross

leveling
, and selecting su
ppliers o
n the
fly
.
A
recent paper
by
Caggiano et al. [7]
deals with
a related
inventory allocation
problem in
a two

echelon reparable service parts system.
T
he sy
s
tem in question consists of a central repair facility, a central warehouse, and a number of field
sto
cking locations that service customers. The authors describe a
repair and inventory
allocation
model that dete
r
mines how many parts to ship from the central warehouse to the field stocking
locations to minimize the total expected inventory holding and back
order costs over a planning
horizon.
A
l
though their approach could be employed to address the inventory allocation problem
in a trad
i
tional brigade with hierarchical distribution operations, it does not capture the dynamic
sourcing relationships found in a
n NCL environment with
cross

leveling
of materiel between
combat
units.
Before presenting our modeling and solution approach for making inventory allocation dec
i
sions in a network

enabled brigade, we summarize several key modeling assumptions: (a) the
a
ter

level logistics are not modeled except
“
Class IX
”
repair parts during operations; this excludes
other categories of materiel such as armament, fuels, ammunitions, and communications subsy
s
tems; (b) at most one part failure can occur on any given
combat ve
hicle, so
each repair i
n
volves
8
a single part type to return a broken vehicle to an operational condition; (c) installation times are
deterministic and depend on the type of repair part delivered to a combat vehicle; and (d) gathe
r
ing of installed parts fro
m broken vehicles to repair other broken vehicles, i.e., cann
i
balization, is
not currently considered.
We
now
define the
notation
re
quired
to describe our
model.
Here and elsewhere,
t
always r
e
fers to the time
t
units from the current (simulated) time; i
.e., each time we run our algorithms,
we “r
e
set the clock” so the current time is 0.
Logistics network
P
:
Set
of
repair part
type
s
indexed by
p
B
:
Set
of battalions
indexed by
b
C
:
Set
of companies
indexed by
c
:
Relative import
ance of company
c
at
time
t
.
:
Relative importance o
f battalion
b
at
time
t
.
:
E
xpected transit time between
companies
i
and
j
for transport initiated in time period
t
.
:
S
torage cap
acity of part
p
at company
c
.
:
Overall
storage capacity
of part
p
at battalion
b
where
;
d
e
notes
the set of all co
m
panies
c
assigned to battalion
b
.
Note that the maximum storage capa
city of a battalion
,
,
is
at most
the sum of the on

board spare capacities of
all of
its co
m
bat vehicles.
Further restrictions (stocking limits) may
also apply.
Demand and Supply
:
E
xpected
demand
for
part
p
at company
c
at time
t
(
D
pc0
= demand backlog at time 0).
:
Quantity
of
part
p
expected to arrive from outside
the
brigade
at time
t
.
:
I
n

transit inventory of part
p
at time
0
(repair parts stored on truc
ks)
.
:
O
n

hand inventory of part
p
at company
c
at time
0
(current on

hand inventory).
9
:
Quantity
of part
p
available in the brigade
at time
t
(available supply for allocation)
The demand for repair parts is
assumed to be deterministic. However,
the
demand
intensity
varies based on
information about
the mission type and location provided in the OPLAN, thus
capturing
different
stresses which impact the
vehicle damage and
repair parts
requirements (e.g.,
low de
mand intensity during humanitarian assistance missions; high inte
n
sity during combat
operations).
Decision Variables
:
N
umber of
parts
of type
p
allocated to company
c
at time
t
.
:
N
umber of
parts
of type
p
allocated to battalion
b
at time
t
.
:
Optimized cumulative receipts
of
part
type
p
at company
c
at time
t
.
:
Optimized cumulative receipts
of
part
type
p
at battalion
b
at time
t
.
T
he relative importance is
a non

negative weight representing a unit’s priority relative to
other units.
A l
arger weight mean
s
higher priority.
The transit times are co
m
puted by a shortest

path algorithm that takes into account the
state of the road network and the current
movement
plan
.
Expected demands are computed from scenario data including breakage rates as a function
of activity (e.g., idle or engaged in combat). Initial quantities and parts arriving from outside the
brigade are given as scenario data, as well as brigade stru
cture, storage capacities, etc.
The proposed algorithm pr
oceeds in
three
steps as d
e
scribed next
.
Step 1: Allocate
repair parts based on relative priorities
In this step, we
try to
maximize the fraction of breakages that can be served immediately
from pr
e

positioned rep
air parts inventory
, taking into account the priorities of the various mil
i
tary units.
We allocate parts hierarchically, first to battalions and then to companies, using a pr
o
rati
ng
scheme.
The first goal when allocating spare parts to a b
attalion is to cover the breakages forecasted
for all its companies. We do this in a way that takes into account the relative priority of each
company: the fraction of spare parts allocated to a battalion is the priority

weighted sum of the
breakage foreca
sts of its companies
divided by
the priority

weighted sum of the breakage for
e
10
casts across all companies in all battalions.
However, t
he number of parts allocated will not e
x
ceed the storage
limit
at the battalion.
The following for
mula e
x
presses this rule.
(1)
where
is the expected amount of
available
(unallocated)
supply of a part type
p
in the brigade
at time
t
.
A
pt
includes all the available supply
in the bri
gade of part
p
in time period
t
and not just the inventory at the BSB
, and is comput
ed as
the difference between cumulative number of parts that entered the brigade until time
t
and the
c
u
mulative expected breakages until time (
t

1).
Having thus allocated
parts to a battalion
b
, we
further allocate them to each company
c
in the ba
ttalion
using a similar prora
t
i
ng
scheme.
(2)
Denote
the weighted
fulfillment ratio
for
an operational unit
c.
In order
to i
m
prove
operational
availability
(as defined in Section 2.1)
, we try to stock as much as possible at
the demand point to satisfy demand immediately. This can be achieved by having a higher fu
l
fillment ratio.
The allocation scheme
(
1
) and
(
2
)
strives to
balance the fulfillment ratios of all
battalions and companies while satisfying the
stocking limits
and
. Notice that the all
o
cation in this step may entail fractional quantities of inventory being assigned to
a company or
battalion
.
F
i
nally, s
et
.
Step 2:
Iteratively improve allocation to further reduce CWT
If the storage capacity
limit
at some companies or ba
t
talions is
smaller than the
desired all
o
cation
target
based on their weighted
share as given in (1) and (2) in Step 1,
the algorithm above
yields
leftover
supply at the end
of Step 1. The
remaining
supply
is
now
allocated
among
co
m
panies
or
battalions
that have not exceeded their capacity limit
so as to
mini
mize
the expected
time to
respond to breakages
that ar
e not
fixed immediately
.
T
he algorithm gives preference to
11
oper
a
tional
unit
s that are
centrall
y l
ocated
in order to maximize the benefit
from
cross

leveling.
This helps to minimize the CWT as defined in Section 2.1 and thus yie
ld a better solution.
For
each
time period
t
, t
he algo
rithm computes a preference score
M
f
or each company
c
in
the bri
gade
, r
ank
s
all companies by their preference score
s
,
and
a
llocate
s
one part
from the r
e
maining unallocated available supply
to
the
comp
any
with the highest score
.
This step is r
e
pea
t
ed
until all remaining stock
is
allocated, or all companies
reach
their capacity limit
s
. In th
e se
c
ond
case all
re
maining
parts
are all
o
cated to the
BSB.
There are several scor
ing
metrics
(
M
)
that
we can use
in the first step. The simplest one is
based on the expected transit time
between any two companies
c
and
j
in the brigade
.
We
define
as
the
ex
pected transit time
to other co
m
panies
:
(
3)
A low
indicates
that
a company
is
centrally
located
and
can
there
fore
quickly r
e
spond to
requests from
other
companies in the
brigades. The simple
preference score
considers tra
n
s
it time
s
,
but it does not consider the inventory
state
. Thus we enhance it by defining a
nother
prefe
r
ence score
that simultaneously considers transit times and inventory
state
:
(4)
combines
the expec
ted transit time and the
difference in weighted fulfillment ra
tios,
helping to balance the fulfillment ratios across the brigade.
We use
to allocate the remai
n
ing available sup
ply using the
algorithm
below
.
T
he company with a
smalle
st
score
is given
the highest priority for allocation
.
N
ot
ice
that
the algorithm can assign
fractional values
in Step
A
1, and thus
t
he remaining
(expected)
supply need not be
an
i
n
teger.
Algorithm
A: Allo
cate remaining supply
Step
A
1:
Find
.
Step
A
2:
Set
X
pc
*
t
:=
X
pc
*
t
+ min{
1,
A
pt
}
and
A
pt
=
A
pt
–
min{1,
A
pt
}
Step
A
3:
If
A
pt
= 0,
stop. Otherwise
,
update
based on the allocation in Step A2 and
go
to Step
A
1.
12
Given that the values of expected demand are usually fractional and the amount of expected su
p
ply available is small, allocating one unit at a time incrementally can b
e justified. N
ote that
accounts for the preference for the operat
ional units.
Step
3
:
Determine allocation
p
lan
Using the allocations
obtained in Steps 1 and 2,
we generate a
parts
allocation
plan for the
BSB and
all operational units in the brigade
.
The plan is expressed in the form of c
u
mulative
net
receipts targets
(cumulative net flow into a company)
for each repair part
p
and o
p
erational
unit
c
and time period
t
. We have
(5)
The
allocation
plan is always feasible
in the sense that
the total
number
of par
ts delivered to
an operational unit
is always equal to the
number
of parts that
are
taken
from other units
(
inclu
d
ing the BSB
)
. For example, if company
c
is sche
d
uled to receive 10 parts at time
t
, then there are
other
companies that in sum provide these 1
0 parts. Th
e
se are represented as negative receipts in
the receipts plan.
Again, it is possible that the values of
are fractional.
To make
an
i
n
teger, we set
and
. We then
u
se
Algorithm A
to
a
l
locate
A
pt
to the companies and recalculate
using (5).
Note that at most one of the
values can be fractional after we apply
Algorithm B
in any p
e
riod
t
for every part
p
,
and th
is is
unavoidable
since the expected demand can be fractional.
The operational decision of where to source the supply is provided
by the
t
ransportation
scheduler
which is d
e
scribed next.
4. Tr
ansportation
Scheduler
We now describe our solution for generat
ing an optimized plan for the
truck
s that load and d
e
li
v
er spare parts. The primary goal is to dete
rmine a schedule for the
truck
s
to load parts at the su
p
ply locations (BSB and companies) and deliver them to the
combat veh
i
cle
s that need repair. The
truck
s’ schedules are also given load and unload operations for parts that are not needed immed
i
13
ately so that the inventory level at each location approaches the target spec
i
fied by the
i
nventory
allocation module
.
4
.1
Inputs
One of the inputs
to the
t
ransporta
tion
scheduler
is the output of the inventory optimization
phase: namely, a list of parts
that
need to be delivered to each location and the
times
at which to
deliver them
to achieve optimized pre

placement of inve
n
tories.
Other inputs describe the number
of available
truck
s and their operational constraints, such as
their ranges of operation
(i.e., how far they can travel before returning to the BSB for refueling,
etc.)
and their capacities for storing parts. Our model for delivery can incorporate a variet
y of
other operational con
straints, such as
load and delivery time windows, preferred or prohi
b
ited
assignments of
truck
s to routes, and constraints on the total length and composition of a route
(such as limits on the number and type of deliveries in each
route).
However,
of these
only the
truck capaci
ty and delivery time window constraints were applied
in this prot
o
type effort.
4
.2
Outputs
For each available
truck
we will either produce a route or label it as idle. A route will be d
e
scribed by the followi
ng.
The locations to visit (BSB, company or broken
combat vehicle
) in sequential time
order. A route may include companies and broken
vehicle
s that belong
to
different
battalion
s
(in contrast to the traditional hiera
r
chical assignment of
truck
s). A route
starts at the current location of the
truck
. It ends at the BSB, a company
,
or a broken
vehicle
. The
length of a tour will not exceed the
planning h
o
rizon of
72
hours.
The sequence of operations to perform at each location (load part, unload part, or r
e
pa
ir broken
vehicle
).
4
.3
Objective Function
We now formally describe the objective function used by the optimizer
as specified by
DARPA
.
It contains two terms. The first measures the availability of
combat vehicle
s over the planning
h
o
rizon. The
second
ter
m penalizes the schedule if the inventories at the various locations do not
meet or exceed the levels re
c
ommended by the inventory allocator.
14
A good schedule prioritizes the repairs to maximize the number of operational
combat veh
i
cle
s across battalions an
d time, taking into account the relative weight
s
of
each battalion
b
at
each time period
t
, and striving
to balance the availabilities across
battalions. To achieve this
goal
,
we include in the objective function a term
that measures the operational availabi
l
ity of
vehicle
s at battalion
b
and time
t
as a result of the repairs
,
where
denotes the number of
vehicle
s in battalion
b
that have been fixed before or during period
t
.
We wish
to m
aximize
the
sum of these availabilities weighted over all battalions and time periods
, i.e.,
(6)
This is the
first term in our objective function
. (It will be
divided
by a normalizing factor d
e
scribed later)
.
Three ranges of operational availability are defined for the
combat vehicle
s: up to 80%, from
80% to 90%, and from 90% to 100%. Each one has a distinct prio
rity
; for instance,
if we ignore
weighting
of battalions
due to different activities such as
“
in combat
”
versus
“
idle
,”
a balanced
s
o
lution
with
two battalions
each at 80%
availability
is
considered
by our customer
, DARPA,
to
be
better
than one
battalion
a
t 70% and one at 90%
.
(The weights specified in the OPLAN for
different battalions will be included in the overall objective function as defined below.)
The
term
s
in the objective
function capture
these three
levels of priority as f
ollows.
Let
V
b
be
the total number of
combat vehicle
s in battalion
b
, and let
N
b
be the number of operational
veh
i
cle
s at time period 0.
Thus, the fraction of operational
vehicle
s at period
t
in the battalion
(igno
r
ing future br
eakages)
is given by
.
The first priority in repairing is to get this fra
c
tion up to 80%. The secondary priority is to get thi
s fraction up
to 90%, and the tertiary priority
is to be fully operational, i.e.
, to bring
the fraction
up
to
100%. In the objective function we give
these levels of priorities weights that reflect their relative importance: 4, 2 and 1, respectively.
With these weights each term
is a piecewise linear co
n
cave function
. We write this
as
where
.
Note that the first 80% of operational vehicles are
counted 4 times in this expression, the next 10% twice, and the last 10% once
,
as desired.
B
e
cause
is
always
between
0 and 1,
t
h
e term
yields a value between 0 and 3.5
as can be seen by substituting x=0 and x=1, respe
c
tively
.
15
Recall that
denotes
the optimized cumulative re
ceipts
for part
p
at company
c
as gene
r
a
t
ed by the
i
nventory
all
ocator
,
and that the initial inventory is
.
D
enote by
the actual c
u
mulative receipts by time
t
for part
p
at company
c
. It is d
e
fined as the number of parts of type
p
unloaded from trucks up to and including tim
e
t
at company
c
, minus the number loaded there
and taken elsewhere.
To penalize deviations from the target receipts value
, w
e
apply
the
fo
l
lowing
penalty term
to the objective function
:
(7)
me
asures the relative deviation of the actual receipts plan from the target receipts
plan
establis
hed
by the
i
nventory
allocator
.
Rewriting
a
s
,
we can interpr
et
it as
the fraction of inventory missing at time
t
compared to the ideal value.
Note that
and
may be negative. However,
and
, and thus
the above pe
n
alty is
less t
han
1 for all
p
,
c
, and
t
.
Taking the maxi
mum
with 0
ensur
es that there is no benefit
(neg
a
tive penalty)
from exceeding the inventory requir
e
ments.
T
he composite function
we seek to maximize,
including the weighted measure of availability
and the terms co
rrespon
d
ing to pre

placement
,
is
(
8
)
where
the n
ormaliz
ing
factors
and
PCT
convert
each of
the two sum
s in (8)
to
numbers
be
tween 0 and 1
.
is a weight
between 0 and 1
that de
notes
the relative importance of
meeting the inventory
pre

placement
targets
.
In this prototype
effort we used a value of 0.05
which
could be
further
tuned
in a larger scale development effort
.
(We note that this particular
combination, including per

batta
lion weights for availability but per

company weights for inve
n
tory placement, is not arbitrary; it was specified by our customer
DARPA.)
16
4
.4
Outline
of
Solution Approach
We have
developed and experimented with
three app
roaches for producing optimized
sch
e
d
ules.
The firs
t approach uses
integer p
rogramming
(IP
, defined below
)
, and is described in
Section
5
.
The second approach uses local s
earch and is described in Section
6
.
The third approach uses a
somewhat
sophisticated greedy heuristic, and is describ
ed
in Section
7
.
In the
integer programming
approach we first produce routes for the trucks to deliver parts to
combat vehicle
s that need
repair. Then we add load and unload operations
to
these routes to d
e
liver
th
e spare parts specified by the i
nventory
allocator
. The
local
search
and greedy
a
p
proach
es
work
to satisfy both goals concurrently.
In Section 8 we describe how the three alg
o
rithms are
combined
.
5.
Integer Programming Algorithm
Our first algorithm optimizes the first term of the objective direc
tly using
integer
linear
pr
o
gramming
techniques
. That is, it first seeks only to fix broken
combat vehicle
s, and ignores i
n
ventory placement. It then heuris
tically adds load and unload
operations
to the schedule thus
generated,
attempting to satisfy the re
commended inventory placement produced by the Inve
n
t
o
ry Opt
i
mizer.
To meet the primary objective (repairing
vehicles), we
solve an
integer programming mat
h
ematical m
odel. We describe the model in detail in Section
5.1
. This model requires
column g
e
n
eration
, a sophisticated technique to generate possible routes for each
truck
. We d
e
scribe this
technique in Section
5.2
. Section
5.3
describes
fix and r
esolve
, a specialized tec
h
nique we use to
solve the integer p
rogram and determine optimized routes for the
tru
ck
s. Finally, Section
5.4
d
e
scribes
how we
use
these routes to transport the rest of the inventory to the companies. Fi
g
ure
4
is a pictorial view of these components.
17
Figure
4
:
The compone
nts of the integer programming a
lgorithm.
5
.1 Integer Programmi
ng Mathematical Model
An
integer programming
mat
hematical problem is similar to a
linear programming
problem, with
the additional restriction that some of the variables must take only integer values. A
linear pr
o
gramming
problem is a mathematica
l problem
in which
we seek to assign values to numerical
variables, so that they satisfy a collection of linear equalities and inequalities (the co
n
straints)
and also maximize a linear function (the objective function). Linear and
integer programming
models have bee
n in wide use since WWII both in military and industrial Operations Research,
to solve a v
a
riety of problems in vehicle and personnel scheduling, facility location, portfolio
selection, di
s
tribution network planning and other practical ap
plications.
5.1.1
Variables
For each route
j
that a
truck
can be assigned to, we define a variable
x
j
.
This is a binary var
i
able.
A value of 1 indicates that
the route
j
is
to be
used in the schedule
(a
truck travels the route);
0
means that the route is not
used.
Thus we define
x
j
{0
,
1}
for all routes
j
(9)
18
The number of possible routes may be very large; if we were to include them all, we would
end up with an unmanageable model with far too many variables
x
j
.
We
defer until section 5.2 a
detailed discussion of our heuristic column generation
techniques t
o generate just the routes and
variables we need
.
We define the variable
as the number of
vehicle
s in battalion
b
that will be
fixed before
or
during period
t
. This must
be a non

negative number, i.e.
for each battalion
b
and each period
t
(
10
)
This variable must also take only integer values. However, we do not need to explicitly d
e
clare this, and we reap a
computational benefit as a consequence: by virtue of constraint
(
14) in
the next section, if each
x
j
is an integer, each
will be an
int
e
ger as well.
5.1.2 Constraints
Each broken
combat vehicle
should be visited at
most once during each schedule.
This e
n
sures
that the objective value does not “take credit” for fixing any vehicle more than once.
To express
this, let
S
(
i
) be the set of routes that i
n
clude a stop at a broken
vehicle
i
. Then
fo
r each broken combat vehicle
i
(11)
Each available
truck
will either be assigned to exactly one route or will sit idle.
To express
this, let
T
(
v
) be the set of routes that
truck
v
can be assigned to. Then
for each repair
truck
v
(12)
Two (or more)
truck
s can be candidates for the same route or for a portion of the same route.
To keep track of such possible assignments, we label each combination pair of candidate route
and
truck
; the pair is then unique.
The q
uantity of a part
type
transported away from a location on
truck
s visiting the location
should not exceed the quantity
that has arrived
at the location.
To model this, let
P
(
p
,
t
,
l
) be the
set of routes on which the assigned
truck
s transport away part
p
fro
m location
l
up to and inclu
d
ing time period
t
. Let
be the quantity of part
p
that the
truck
on route
j
transports away from
19
location
l
. Let
be the quantity of part
p
that has arrived
at location
l
up to and
including p
e
r
i
od
t
. Then the constraint reads
for each part
p,
each period
t
, and each location
l
(13)
The number of
combat vehicle
s serviced by the
truck
s on the routes equals the number of
combat vehicle
s repaired.
Le
t
U
(
b
,
t
) be the set of routes for
truck
s that visit a broken
vehicle
in
battalion
b
before or during period
t
. Let
be the number of
vehicle
s in battalion
b
that the
truck
on route
j
services up to and including period
t
. This is a
no
n

negative integer constant.
Thus
for each battalion
b
and each period
t
.
(14)
To capture the function
in the objective function
we introduce three vari
ables
y
1
,
y
2
and
y
3
:
y
1
measures the e
x
tent to which 80% of the
vehicle
s are operational;
y
2
measures the next
10%, and
y
3
measures the final 10%. Their sum must be the actual operating fraction, and we
include a con
straint to capture that.
Thus each term
f
b
,
t
(
r
b
,
t
)
in the objective function is
(15)
and the additional variables and const
r
aints needed to represent it are defined by
(16)
5
.2
Column Generation for
Truck
Routes
In
integer programming
models for scheduling vehicles there are usually too many routes to
co
n
sider explicitly. However, an
y feasible
schedule contains relatively few routes, i.e., at most
one per av
ailable vehicle. We use
a family of he
u
ris
tics
to produce good candidate routes, i.e.,
20
routes that drive the optimization forward and have the potential of being part of an optimal
schedule.
This can be seen as a
heuristic column generation procedure
.
Reca
ll that e
ach possible route corresponds to a variable in the mathematical model
;
thus it
defines a column of the matrix
that describes the model
.
The ability to generate good columns
quickly is the make

or

break test of
a column

genera
tion

based integer pr
ogramming
approach.
We have several
methods in our tool set for generating good routes. They are described b
e
low.
S
ee
Barnhardt et al. [8]
and
Desrosieres et al. [9] for a description of column generation
techniques. For background on
vehicle

routing prob
lems and solu
tion approaches, see
Bramel
and Simchi

Levi [10], Desrosieres et al. [11], Solomon and Desrosieres [12], Psaraftis [13], and
Gendreau and Potvin [14]. More recently, Gendreau et al. [15] considered a problem similar to
ours including dynamic
scheduling of both pickups and delive
r
ies, but their objective function
was different from ours.
5.2.1 Closest Neighbor Algorithm
For a given
truck
we pick at random a
vehicle
among the
k
broken ones that are clo
s
est to the
current location of the
truck an
d that require some part that is currently carried by the truck.
We
add this
vehicle
as the next s
top to the route of the truck
. Then, from this
vehicle
’s l
o
cation we
look for another broken
vehicle
to visit next
among the
k
closest ones
, and so on
. We re
peat
u
n
til
no more broken
vehicle
s can be fixed with the spare parts that the
truck
carries. The next stop on
the route is then the BSB, where the
truck
goes to load new spare parts. Then we look again for a
broken
vehicle
among the
k
closest ones as befor
e. We add
stops to the route in this fash
ion
u
n
til
the
truck
on the route has visited all broken
vehicle
s or the rou
te lasts longer than the
pla
n
ning
horizon.
The truck capacity is taken into account when choosing each stop, so a broken v
e
hicle
requiring a
part that does not fit into the truck is ignored. Our experiments ind
i
cate that one
should give the values 3 or 4 to the parameter
k
.
In this heuristic the trucks are treated seque
n
tia
l
ly.
5.2.2 Clarke

Wright Algorithm
T
he Clarke

Wright algorithm
is a
wel
l

established procedure in v
ehicle
r
outing
(Clarke and
Wright [16
])
. We star
t with elementary routes and then
combine
them
to create longer ones that
are time

efficient.
21
Step 1.
We create elementary routes, in which a
truck
starts at the BSB (denoted
),
visits a broken
combat vehicle
i
and returns back to the BSB. So, for each broken
v
e
hicle
i
we create the route {
}. The total number of routes equals the number of
broken
vehicle
s, which typically exceeds the nu
mber of
truck
s available. Thus we
need to combine these routes to produce one route per
truck
.
Step 2.
We combine routes recursively, as follows: We examine together a route that
includes broken
combat vehicle
i
as a last stop before returning to the BSB,
{
}, and a route that includes broken
vehicle
j
as a first stop after the BSB,
{
}. Let
c
i
and
c
j
be the time length of each route, respectively. Now we co
n
sider the combined route {
}, where the
truck
takes on the second route
right after completing the first and skips the intermediate visit to the BSB.
Of course,
we must reject combinations which are infeasible, for instance because the truck ca
n
not obtain all n
ecessary parts at the BSB.
Let
be the length in time of this co
m
bined route. The time
savings
of the combined route versus the two single ones
is
. For every pair
i
and
j
of routes, we calculate the time
saving
s
of their
possible combination, and we combine the two routes with the largest
savings,
brea
k
ing ties
random
ly. We repeat this
until the number of routes is equal to the number of
truck
s.
5.2.3 Cluster

and

Route Algorithm
Another procedure to generate ro
utes is to first create a cluster of broken
combat vehicle
s for
each truck and then create a route that includes all
vehicles in the cluster
.
The clustering algorithm is as follows:
First mark as “available” all broken vehicles.
Then move each truck to a
closest availa
ble vehicle and mark it
as unavai
l
able.
Continue as above until all broken vehicles have been assigned. Then we have a clu
s
ter for each truck.
When defining the clusters, all trucks are treated in parallel, each o
f them mak
ing one move
at a
time, in contrast to
the Closest Neighbor procedure
in which
the trucks are treated seque
n
22
tially. Once the
clusters have been defined
,
the routing of the truck is done in each cluster
as
in
5.2.1.
After
we schedule visits to all
vehicle
s in a cluster
usin
g parts available on the truck
, we add
additional stops to the route, such as the BSB or a co
m
pany where the
truck
can pick up spare
parts
, and then further repairs may be added to the route
.
For the cases in our test set, we observed that the
generating
700 to 1000
possible routes with
th
e three methods provided good results, where the input specified
a 72

hour horizon, 36 types of
parts, 7 repair trucks, 8 battal
ions, 19 companies and around 150
broken
combat veh
i
cles. From
these
routes
,
7 were chosen by
the solution method we describe in the next se
c
tion.
5.3
Solving the Integer Program with the Fix

and

Resolve
M
ethod
To solve the integer p
rogram
,
we
first
solve its
linear relaxation
, i.e.
,
we allow the binary i
n
teger
variables to take fractional values
and we solve the resulting
linear p
rogram
using the si
m
plex
method
(see, e.g., Dantzig [17
])
and
the ope
n

source solver CLP (COIN

OR [18
])
.
Then we e
x
amine the values of the relaxed binary variables
x
j
in the solution. Some of them will have
value
0 or 1, which means the solution e
x
cludes (respectively, includes) them. Others will have values
in between: for example, the sol
u
tion may feature two routes for a
truck
, each with value 0.5.
This indicates that the solution does not select
one route
over the other. This
inconclusive situ
a
tion
does not help us in selecting a route.
On the other hand, a route with value close to 1 su
g
gests tha
t this route can be part of a good
solution. We have designed our iterative solution pr
o
cedure around this, as
fo
l
lows:
We set the variables taking a fractional value close to 1 to the value 1,
thus ‘fixing’
them.
If any variables are at least 0.999999, they are chosen. Otherwise, we choose
the variable closest to 1
and fix only that variable before the next ite
ration.
However,
if fixing a variable to the value 1 makes the linear program infeasible, then it is fixed
to 0.
We reduce the size of the problem by removing all the
truck
s, inventory, and fixed
combat vehicles associated with the
routes
that are thus f
ixed
.
We solve the linear relaxation again, to optimize the smaller the problem.
We
repeat,
fix
ing
new va
riables close to 1
, until there are no more variables taking a
fractional value.
23
We call this procedure
fix and r
esolve
. It is designed to produce a
good s
olution quickly. (As
we fix more variables the linear programs get smaller, and we expect to solve them faster.)
5
.4
Delivering All Spare Parts
The solution of the integer p
rogram assigns each
truck
to a repair route for broken
combat veh
i
cle
s, and
assigns load
operations for
the spare parts required. We can make additional use of this
route to deliver to the
companies the
parts specified by the Inventory Optimizer. The alg
o
rithm is
as follows:
We mark all companies that have parts to be delivered t
o them as ‘unfulfilled’.
We produce a random ordering of the
truck
s that are non

idle, i.e.
, that
have routes
assigned to them.
For each
truck
as we go down the ordering
1.
For each part we compute the total quantity to be delivered to the companies
on the
route of the
truck
.
2.
We exami
ne whether the BSB
has
some or all of
these parts.
We also check
whether some other company has excess quant
i
ties available for cross

leveling.
3.
If
(some of) the parts are available
, we load the part
s
on the
truck
,
up to its c
a
pacity limit.
4.
As the
truck
travels its route and delivers parts to the companies, we note
whether the parts delivered meet the total demand of each company or not. In
the first case, we mark the company as ‘fulfilled’.
At the end of this algorithm some
companies may be unfulfilled, i.e.
,
their demand will have
been filled only partially, or not at all. For these companies we reserve one
truck
to run a sp
e
cial
route: it starts from the BSB, tours the unfulfilled companies delivering parts
,
and returns to
the
BSB.
We schedule this
truck
using a closest

neighbor heuristic, as follows:
We
greedily
create a route for the
truck
, where the
truck
starts at the BSB, then visits
the unfulfilled company closest to the BSB, then the unf
ulfilled company closest to
th
at
company, and so on. The last stop is the BSB.
For each company on the route we calculate the quantity of parts needed to reach ‘fu
l
filled’ status. We create a load plan for the
truck
, in which the
truck
loads the parts
24
needed at the BSB. If the BSB can
not supply the full quantity needed,
then, if poss
i
ble,
we add load operations at companies that have excess inventory of the part nee
d
ed and are visited earlier by the
truck
on the route. In all cases we take care not to e
x
ceed the c
a
pacity of the
truck
.
6.
Local Search Algorithm
I
n contrast to our
integer programming
algorithm,
our
local
search
algorithm addresses both
terms of the objective function simultaneously.
The general idea for
a
local
search
algorithm is
to start with a feasible schedule and im
prove it in small (
local
) steps until no further improv
e
me
nt can be found (Aarts and
Lenstra
[19
]
; Ibaraki et al.
[20
]
)
.
At each step we try to improve
the scheduling of trucks for
combat vehicle
repair, as well as the overall distribution of spare
parts.
This is done by exploring the
neighborhood
of the current solution, and r
e
placing it with
another, better solution in the neighborhood. Solutions in the neighborhood are evaluated accor
d
ing to the objective function
(
8
)
. The process stops when a
local opti
mum
is reached
,
i.e., a
schedule that cannot be improved by local i
m
provement steps
.
To define precisely a
local
search
algorithm we need to specify how to find a feasible sche
d
ule
that can be used as a starting point
and how to
define the search neighborh
ood
, i.e., the ca
n
didates for an improvement step.
In choosing the neighborhood we balance two oppo
s
ing objectives:
Since we need to improve the current schedule, the neighborhood must be large and
varied enough to contain a good i
m
provement.
We must be
able to explore
t
he neighborhood
quickly.
Techniques exist for exploring
very large neighborhoods
(Ahuja et al [21
]);
we manage the search by keeping the
size of the neighbo
r
hood relatively small.
There are also several options in choosing an improve
ment
in a neighborhood: for example,
we can
take the best solution in the neighborhood, or we can take the first solution
that
is be
t
ter
tha
n the current. The second option decreases the running time of an iteration, but may also d
e
crease the magnitude of the
improvement.
25
6.
1
Details of the Local Search
Algorithm
6
.2.1 Initialization
The starting point
can
be any of the following three options:
The schedule generated by the
integer programming
algorithm
described above
.
A schedule produced by a
ny other algor
ithm, for instance
,
a
simple greedy algorithm.
No schedule at all.
In the first option we are motivated by the fact that the
integer programming
method does not
generate all possible routes, just a small, manageable subset of good routes. It is possible,
at least
in theory, that better routes exist, and we
can
use the local search method to improve upon the
routes produced by
integer programming
. Sometimes an improvement that is relatively small in
terms of the objective function, but obvious to the human
eye, may be missed by the IP sol
u
tion’s global view
, and a local search can find
and correct
this
; this may increase user confidence
in the IP solution
.
Section
7
below
describes another algorithm that could be used as a starting
point.
In this prototypin
g effort we implemented only the third option, i.e., simply start with the
empty solution and take local improvement steps from there.
As we will see, one of our local
improvement steps inserts a new action into a route; inserting into an “empty route” is
simply a
special case.
However, we use
specialized techniques
, which we omit for lack of space,
to grea
t
ly speed up the
initial iterations until we have
a “reaso
n
able” schedule to use as a starting point.
6
.2.2 Improvement Steps
The set of feasible improv
ement steps
we e
x
plore
(i.e., the changes that define the neighborhood)
are
:
1.
Insert a previously unscheduled
delivery/
repair or inventory replenishment order into
one of the existing routes.
2.
Perform a simple delete

and

reinsert swap, as follows:
Pick a r
oute
and an unload
or r
epair operation and delete it
.
Delete the corresponding load operation in this route.
Insert the deliver/repair
operation into a different position
in
the same route, or i
n
sert it in some other route.
For the repair/unload operati
on inserted in the last step, examine
the route up to
that operation
to find a location and time to insert
a
corresponding load oper
a
tion.
26
Add the load operation to the route.
3.
In case the algorithm cannot accommodate unscheduled orders and insert them in
to a
cu
r
rent schedule, delete one of the scheduled orders and insert one of the unscheduled
ones. Although this action may seem not to make progress, it may improve overall
availability, as it may repair a broken
combat vehicle
sooner or repair a higher

pr
iority br
o
ken
vehicle
.
Our approach closely rese
mbles that of Dror and Levy [22
], which solved a similar pro
b
lem but
with deliveries only rather than load/unload pairs.
7
.
Stabilized
Greedy Algorithm
Our third transportation scheduling algorithm can be t
hought of as a sophisticated improv
e
ment
on a natural greedy strategy.
The algorithm has three
phases
–
oscillation avoidance
(hence the
name)
, allocation of
truck
s to battalions, and routing of individual
truck
s.
Due to
lack of space
we omit detailed discu
ssion of this algorithm.
8.
Combining the
A
lgorithms
The algorithms described in the previous sections are combined
into a single
i
nventory and
t
ransportation
o
ptimiz
er
as follows: On
each
incremental
receipt of new data (typically three

hour gran
u
larity is
used,
but experiments were carried out with values as
small
as one hour and
as
large as
24 hours), we run
the
i
nventory
allocator
and then
all three
transportation
algorithms
in parallel. Each produces
its own schedule. We evaluate the quality of these sc
he
d
ules using the
combined objective function
(8)
over the full
72

hour planning horizon. We choose the best
of
the three
schedule
s
according to the
objective function, and return the first
i
n
crement
of it to the
simulator. The first
increment
is executed,
and the process repeats. The
previous schedule is di
s
carded and a new schedule is d
e
rived using the
up
dated snapshot of the situation.
Thus we
re

optimize
at fine granularity, and continually incorporate the latest available
data
into our solution.
Below
we refer to each such run of the optimizers as an “iteration.”
The 72

hour h
o
rizon is used to find the best
plan, assuming nothing changes, at each time increment. If
new data
becomes available at the next time increment, a better solution for
th
e new sit
uation
may be po
s
sible.
27
There are several benefits derived from using multiple
transportation
algorithms. The
first is
high solution quality: We are able to choose the best of three
available solutions. Different alg
o
rithms may have better success in
diffe
rent situations. Because we optimize at fine granularity,
we get the best of all algorithms' performance rather than having to
stick with a single alg
o
rithm's solution.
Another benefit is robustness. The likelihood of all three algorithms
failing or
produ
c
ing low quality solutions is small. Thus
we are
likely
to have a
high quality
solution
at
every time p
e
riod.
9
.
Numerical Results
The goal of
our numerical experimentation wa
s to determine whether
NCL capabilities will r
e
sult in a significant increase in
operational availability of the total force
w
hen compared with c
a
pabi
l
ity provided by a
traditional
logistics
distribution system, particularly under conditions of
high
uncer
tainty
and frequent change
.
We also made measurements of the computational r
e
sour
ces required by NCL, and
compare
d
the performance of the three different transpo
r
tation
scheduling algorithms.
9.1 Simulation
Scenario
The
scenario used in this
numerical study
, provided by our customer,
was designed to evaluate
and compare the traditional
and NCL approaches to logistics distribution over a 30

day simul
a
tion.
The
simulated
brigade
organization encompassed the headquarters and headquarters co
m
pany
, brigade combat team, three infantry battalions, a reconnaissance surveillance and target
acqui
sition squadron, and anti

armor and engineer companies,
together comprising
302 combat
vehicles. The brigade combat
team was assumed to be network

enabled based on
the Army’s
emerging future combat system capabilities
. More specifically, repair parts can b
e distributed to
subordinate units carried on combat vehicles and
on combat repair team vehicles,
combat veh
i
cles are equipped with a sensor suite that provides continuous and total visibility of brigade r
e
pair parts i
nventory and parts requirements,
and a
centraliz
ed decision support system
all
o
cates
inventory and optimizes delivery schedules for repair parts down to the individual combat veh
i
cles.
The brigade’s operations plan
was based on a hypothetical five

phased military operation. For
computer simul
ation purposes, the area of operations terrain was converted to a map with nodes
28
representing key terrain features, cities, bridges, junctions, and arcs representing roads connec
t
ing the nodes.
Repair parts delivery times from the external theater support
base to the BSB were
calculated based on actual distances between the two locations and allowable ground transport
a
tion speeds.
Various perturbations were introduced into the simulation to conduct a series of
stresses which impact the repair parts delivery
process in four areas: demand, inventory, co
m
munications, and road network changes under three different levels of i
n
tensity.
9.
2
Measures of Performance (
A
0
and
CWT
)
T
he benefit
of
NCL
with respect to
the b
aseline system
was assessed in terms of increas
e
d oper
a
tional availability
,
,
and reduced
customer wait time,
CWT
,
as described in section 2.
1
. We
executed over
7
0
0 experiments
to
gain
insight and understanding of
how NCL, e
n
abled by
state
of the art
optimization
algorithm
s
, differ
s from and improves upon the traditional logistics sy
s
tem
.
Each experiment
used a
30

day
battlefield
scenario along with various combinations of
“
stres
s
ors
”
such as increased breakage rates, inventory losses,
communications breakdowns,
and
road closures.
F
or lack of space, we omit detailed discussion of the scenarios.
We
found that
NCL
capabilities result in a significant increase in
operational availability and reduction in cu
s
tomer wait time
compared to a
traditional logistics distribution system
.
Figure
5
shows the br
i
gade

wide operational availability that resulted from the baseline and NCL logistics system
s
in
an unstressed sc
e
nario
.
Figure
5
.
NCL versus
baseline
brigade level
availability
in an uns
tre
ss
ed
scenario
.
29
Because
the
B
SB is not deployed
until day 4
,
a
backlog
of parts require
ments is created
and it
takes
several
days to be overcome
in
both
the
NCL and the
baseline
cases
.
then
levels out in
both cases, but at a much higher level under NCL.
The second dip in the base
line
does not
occur in the NCL case because of the on

board spare capability of the latter.
In the unstressed
scenario, the average NCL
for the
b
rigade was 0.95
vs.
0.86
for the baseli
ne system.
The
a
verage
CWT
for the
b
rigade overall was 7 hours (NCL) vs. 52 hours (bas
e
line).
In the fully stressed case
NCL was
again
superior
as illustrated in Figure
6
.
was
0.93
u
n
der NCL vs. 0.83
under the baseline system
.
Mos
t dramatic was the performance during the
highest stress period from day 24 to day 2
8
, when combat units were cut off from the BSB
.
A
l
t
hough the baseline system recovered to its steady

state a day sooner than the NCL system and
achieved a better
value on day 28, the
downward spike is much deeper for the baseline.
The
overall brigade baseline
dropped to
0.57
on day 27 compared to the NCL
of
0.78
. C
WT
for the fully

stressed
b
r
i
gade averag
ed 8 hours (NCL) vs. 106 hours (baseline).
Figure
6
.
NCL versus
baseline brigade level availability in a
stressed scenario.
9.
3
P
erformance
Comparisons of
Transportation Sche
d
uling
A
lgorithms
To compare the solution quality performance of the three
t
ranspor
ta
tion
scheduling
algorithms,
we collected statistics on a set of 75
,
300 iterations
(about 2/5 of the total number of iterations in
all e
x
periments)
.
Normalizing the objective function to a scale of 0 to 100, the average winning
30
score was 89.6. The
average gap between the best and worst of the three scores was 0.16, and the
maximum gap was 14.4.
Figure
7
shows for each algorithm the number of iter
a
tions on which
that algorithm’s sol
u
tion was best among the three
(“
W
ins”)
. It also shows the number of
times
an algorithm’s score was greater than 0.48, or three times the average gap, be
t
ter than the oth
ers
(“
B
ig wins”)
.
The most frequent outcome was that the three algorithms achieved the same score
,
within a 0.01 margin
.
I
nteger programming
is the most f
requent winner, but no algorithm dom
i
nate
d
any other alg
o
rithm.
IP
LS
SG
IP and LS
IP and SG
LS and SG
3

way tie
Wins
23476
5418
11085
3641
3970
1345
26374
Big wins
2635
1597
899
123
19
11
Figure
7
.
Win tallies among the three transportation sch
eduling alg
o
rithms.
9.
4
Running
T
ime
P
erformance
In production

level testing, the running time of the
i
nventory
allocation module
was always less
than 1 second.
In Figure
8
we show the average and maximum running times of the three
t
ran
s
portation
schedul
ing
algorithms. These are taken over all iterations of all experiments. Each ru
n
ning time data point refers to one invocation of the optimizer, where there are 240 invocations
for a run of 720 hours at three

hour granularity, for instance. We show the over
all minimum,
max
i
mum, and mean for each algorithm, and also the same statistics with the highest and lowest
5% of values removed. Our method for measuring running times of the
local
search
algorithm
di
ff
ered slightly and we have only upper bounds on its ru
nning times. As can be seen from the
table, the comput
a
tional requirements of the algorithms are quite modest.
Algorithm
min
max
m
ean
IP
1.39
68.2
3.18
IP no outliers
1.62
6.01
2.97
LS
<1.0
<84.3
<1.60
LS no outliers
<1.0
<2.10
<1.06
SG
0.53
1.84
0.8
7
SG no outliers
0.63
1.00
0.87
Figure
8
.
Running times of the three transportation scheduling alg
o
rithms in seconds.
31
10
. Summary and Conclusions
T
he
methods and
results
presented in this paper
indicate that
mathematical optimization mo
d
els
have the pot
ential to significantly improve
military
logistics operations, and in particular to i
n
crease
operational availability
of combat vehicles. The simulations considered here were li
m
ited
to a small class of supplies. The very modest computational requirements
suggest that pro
b
lems
of much l
arger scale can be solved by the proposed
optimization techniques. We believe that fu
r
ther investigation is warranted to e
x
pand the scope of the problem considered to yield greater
insight and more accurate results r
e
garding
the amount and types of improvement (i.e., relative
to different performance measures) that can be achieved.
Acknowledgements
We wish to thank our many colleagues contributing to this project: Marshall Brinn, Aaron He
l
singer, John Phelan, Ray Tomlinson and
Todd Wright of BBN Technologies,
Joseph Cross and
Mark Greaves
of DARPA,
John Kirzl and Dave Signori of Evidence Based Research, Inc.,
Steve
Buc
k
ley,
I
gor Frolow, Spy
ros Kontogiorgis,
Yahong Gu
and
John McCann
of IBM
,
Tony Rozga
of LMI
Government Co
n
sulti
ng
,
Leo Pigaty of L
os Alamos Technical Associates, Inc., and Mike
Dyson of Schafer Co
r
poration.
References
1.
Ettl, M., G.E.
Feigin, G.Y.
Lin and D.D.
Yao. 2000. A Supply Network Model with Base

Stock Control and Service Requirements,
Operations Research
48
, 3, 216
–
232.
2. Deshpande, V., Cohen, M.A., and Donohue, K. 2003.
An Empirical Study of Service Diffe
r
e
n
tiation for Weapon System Se
r
vice Parts
,
Operations Research
51
, 4, 518
–
530.
3. Graves, S.C. and S.P.
Willems. 2003. Supply Chain Design: Safety Stoc
k Placement and Su
p
ply Chain Configuration, In
Supply Chain Management: Design, Coordination and Oper
a
tion
, Handbooks in Operations Research and Management Science Volume 11, 95
–
132.
A.G
De Kok and S.C.
Graves (eds.)
4.
Muckstadt, J.A
.
Analysis and Algorit
hms for Service Parts Supply Chains
. 2004.
Springer S
e
ries in Operations Research and Financial Enginee
r
ing,
Springer.
32
5. Cheng, F., M.
Ettl, G.
Lin, and D.
Yao. 2002. Inventory

service optimization in configure

to

order systems,
Manufacturing Services and
Operations Management
4
, 2, 114
–
132.
6. Dietrich, B. et al. 2004. Applications of Implosion in Manufacturing, In
Supply Chain Ma
n
agement On Demand
, pp. 97
–
115, C.
An and H.
Fromm (eds.) Springer.
7. Caggiano, K.E., J.A. Muckstadt, and J.A. Rappold 2006. I
ntegrated Real

Time Capacity and
Inventory Allocation for Reparable Service Parts in a Two

Echelon Supply System,
Man
u
facturing Services and Operations Management
8
, 3, 292

319.
8
. Barnhart, C., E.
L.
Johnson, G.L. Nemhauser, M.
Savelsbergh and P.
Vance. 1
998. Branch

and

Price: Column generation for solving huge integer programs,
Operations Research
46
,
316
–
329.
9
. Desrosiers, J., F. Soumis, and M. Desrochers. 1984. Routing with time windows by column
generation,
Networks
14
, 545
–
565.
10
. Bramel, J. and D.
Simchi

Levi. 1997. On the effectiveness of set covering formulations for
the v
e
hicle routing problem with time windows,
Operations Research
45
, 2, 295
–
301.
1
1
. Desrosiers, J., Y. Dumas, M.M. Solomon and F. Soumis. 1995. Time constrained routing
and sched
uling, In
Network Routing,
35
–
139, M. O. Ball, T. L. Magnanti, C. L. Monma, and
G. L. Nemhauser (eds.) NorthHolland.
1
2
. Solomon, M.
M.
and J.
Desrosiers. 1998. Time window constrained routing and scheduling
problems,
Transport
a
tion Science
22
, 1
–
13.
13.
Psaraftis
, H
.
1995. Dynamic vehicle routing: s
tatus and prospects.
Annals of Operations R
e
search
, 61:143

164
.
14. M Gendreau, J Y Potvin. 1998, Dynamic vehicle routing and dispatching, In:
Fleet Ma
n
agement Logistics
,
115

226, Crainic, T.G., L
a
porte, G.
(Eds.), Kluwer.
15.
Gendreau, M., F. Guertin, J.Y. Potvin, R.
Séguin
.
2006. Neighborhood search heuristics for
a dynamic vehicle dispatching problem
with pick

ups and deliveries.
Transportation R
e
search Part C
14
, 157

174.
1
6
. Clarke, G. and J.
V.
Wrigh
t. 1964. Scheduling of vehicles from a central depot to a nu
m
ber
of delivery points,
Operations R
e
search
12
, 568
–
581.
1
7
. Dantzig, G., 1998. Linear Programming and Extensions,
Princeton Unive
r
sity Press.
1
8
. COIN

OR,
Computational Infrastructure for Opera
tions Research
,
http://www.coin

or.org/Clp
.
33
1
9
.
Aarts, E. and J. K. Lenstra. 2003.
Local search in combinatorial optimization
. Princeton
University Press.
20
. Ibaraki, T., K.
Nonobe and M.
Yagiura (eds.) 2005. M
etaheuristics: Progress as Real Pro
b
lem Solvers,
Operations R
e
search/Computer Science Interfaces Series
Vol.
32.
21
. Ahuja, R., O. Ergun, J. Orlin, and A. Punnen.
2002. A survey of very large

scale neighbo
r
hood search techniques,
Discrete Applied Mathemat
ics
123
, 75

102.
22
. Dror, M. and L. Levy. 1986. A v
ehicle
routing improvement algorithm comparison of
`greedy' and a matching
implementation for inventory routing",
Computers & Operations
Research
13
, 1,
33

45.
Francisco Barahona
IBM Research Divisi
on, Thomas J. Watson Research Center, P.O. Box
218, Yorktown Heights, New York 10598
(
barahon@us.ibm.com
). Dr. Barahona r
e
ceived a Ph.
D. degree in Operations Research from the University of Grenoble, France. His
research i
n
terests
include Combinatorial Optimization, Integer Programming and Mathematical Progra
m
ming. He
has been a professor at the Unive
r
sity of Chile, University of Waterloo, Canada and a visiting
professor at the University of Bonn. He has received
one IBM Outstanding Technical Achiev
e
ment Award and he holds two patents. He has been an Associate editor of SIAM Journal on O
p
timization, Operations Research and Management Sciences.
Pawan Chowdary
IBM T.J.
Watson Research Division, P.O. Box 218, Yor
ktown Heights, NY
10598
(
chowdhar
@us.ibm.com).
Pawan has been associated with various divisions of IBM du
r
ing his career span of 10 years, architecting, designing and implementing complex, high pe
r
fo
r
mance and scalable distributed object

oriented applicat
ions. In 2004, he joined IBM Research as
an A
d
visory Software Engineer in the Analytic Models & Architecture Department and has been
wor
k
ing on the Sense

and

Respond and Business Performance Management (BPM) related
technologies. Lately he is actively inv
olved in the research of Model Driven Software Develo
p
ment tec
h
niques. He has received projected related awards and writes extensively in the area of
BPM and Model Driven Techniques.
He
received his Bachelors degree in Electronics Enginee
r
ing from Nagpur U
niversity, India in 1996.
34
Mark
us Ettl
IBM T.J.
Watson Research Division, P.O. Box 218, Yorktown Heights, NY 10598
(msettl@us.ibm.com).
Dr.
Ettl is a Research Staff Member at IBM’s T.J. Watson Research Ce
n
ter. He received his doctoral degree in Computer
Science in 1995 from Friedrich

Alexander Un
i
versity in Erlangen, Germany. Since joining IBM in 1995, he focused on a
d
vanced research in
supply chain management
,
holding several patents in this field. Dr. Ettl's current research inte
r
ests lie in decision s
upport for produ
c
tion systems and logistics networks, and sense

and

respond
business management for adaptive organizations. He has received the I
N
FORMS Franz Edelman
Award in 1999. His other awards and commend
a
tions include two IBM Outstanding Technical
Ac
hievement Awards and several IBM R
e
search Division Awards.
Pu Huang
IBM T.J.
Watson Research Division, P.O. Box 218, Yorktown Heights, NY 10598
(puhuang
@us.ibm.com).
Dr.
Huang is a research staff member at the IBM T. J. Watson R
e
search Center in Yorkt
own Heights, NY. His current interests
are
in supply chain management,
stochastic optimization, machine learn
ing and data mining. His
work includes
sense

and

respond
systems that help businesses quickly detect emerging risks and react with corrective actio
ns.
These systems typically integrate intelligent data mining techniques and sophisticate dec
i
sion
support algorithms to provide their func
tions. Recently he has worked
on extending the same
idea to support business decision making in large

scale, distribu
ted environments. Dr. Huang r
e
ceived
his
M.S. degree from the School of Computer Science and
his
Ph.D. from the Tepper
School of Bus
i
ness
at Carnegie Mellon University.
Tracy Kimbrel
IBM Research Division, Thomas J. Watson Research Center, P.O. Box
218,
Yorktown Heights, New York 10598 (
kimbrel@us.ibm.com
).
Dr. Kimbrel received B.S.,
M.S., and Ph.D. degrees in Computer Science from the University of Washington
and
joined the
IBM Research Division in 1997.
His
research
on the
design of algorithms for optimization pro
b
lems
includes theoretical, experimental, and applied
efforts
in areas such as operating system
schedu
l
ing, resource allocation
in multi

server systems
, and vehicle routing
.
He has received an
IBM R
e
search Division Award and two Research Division Technical Group Awards, and holds
two patents with several more pending.
35
Laszlo
Ladanyi
IBM T.J.
Watson Research Division, P.O. Box 218, Yorktown Heights,
NY
10598 (ladanyi@us.ibm.com).
Dr. Ladanyi receive
d an M.S. in Mathematics from Eotvos L
o
rand
University in Budapest, Hungary and a Ph.D. in Operations Research from
Cornell Unive
r
sity in Ithaca, NY, USA. He joined the IBM Research Division
in 1996. His main research areas
are integer programming and par
allel
programming, focusing on the computational a
s
pects of
these topics.
Young M. Lee
IBM Research Division, Thomas J. Watson Research Center, P.O. Box 218,
Yorktown Heights, New York 10598 (
ymlee@us.ibm.com
)
.
Dr. Lee received B.S., M.S., and
Ph.D. degrees in chemical engineering from Columbia University. He joined the IBM R
e
search
Division in 2002, and has been working in the areas of supply chain simulation and opt
i
mization.
Prior to joining IBM, he had wor
ked for BASF for 14 years, where he had founded and managed
the Mathematical Modeling Group, and led development of numerous optimization and simul
a
tion models for various logistics and manufa
c
turing processes.
Baruch Schieber
IBM Research Division, Tho
mas J. Watson Research Center, P.O. Box 218,
Yorktown Heights, New York 10598 (
sbar@us.ibm.com
).
Dr.
Schieber is the manager of the O
p
timization Center in the Mathematical Sciences Department. In this capacity Baruch
leads a
group of Computer Scientists, Mathematicians and Operation
s
Researchers in activities combi
n
ing world

class basic research with the des
ign and implementation of state

of

the

art software in
areas such as supply chain management, personnel and vehi
cle scheduling, production planning,
print technology and intrinsic function acceleration. Baruch received his PhD in Computer Sc
i
ence from Tel Aviv University in 1987 and joined IBM as a post doctoral fellow. His main inte
r
ests are approximation algorithm
s, scheduling, and routing. Baruch has published more than 50
papers in scientific journals and is a regular presenter in leading Theoretical Computer Science
conferences.
Karthik Sourirajan
IBM Research Division, Thomas J. Watson Research Center, P.O.
Box
218, Yorktown Heights, New York 10598 (
ksourira@us.ibm.com
).
Dr. Sourirajan is a R
e
search
Staff Member in the Mathematical Sciences deprtament at IBM's TJ Watson Research Center,
Dr. Sourirajan received a B.E
.(Hons.) in Mechanical Engineering at Birla Institute of Techno
l
o
36
gy and Science, Pilani, India in 2000 followed by M.S. (2002) and Ph.D. (2006) degrees in I
n
dustrial Engineering from Purdue University, West Lafayette, Indiana. His research interests i
n
clud
e the application of operations research techniques to solving real world problems generally
related to supply chains such as forecasting, inventory management, integrated faci
l
ity location
and logistics.
Maxim Sviridenko
IBM Research Division, Thomas J.
Watson Research Ce
n
ter, P.O. Box 218,
Yorktown Heights, New York 10598 (
sviri@us.ibm.com
).
Dr. Sviridenko r
e
ceived B.S., M.S., and
Ph.D. d
e
grees in Applied Math and Computer Science from the Novosibirsk State Un
iversity. He
joined the IBM Research Division in 2000. He has r
e
ceived an IBM Research Division Award,
4 patent awards and Research Division Tec
h
nical Group Award for various works on design of
algorithms for optimization pro
b
lems.
Grzegorz M. Swirszcz
I
BM Research, T.J. Watson Research Center, P.O. Box 218,
Yorktown
Heights, NY 10598 (
swirszcz@us.ibm.com
).
Dr. Swirszcz joined IBM in 2003 after receiving
M.S. and PhD degrees from the University of Warsaw and
spending 3 years as a Marie Curie
Post

Doc Fellow at the Centre de Recerca Matematica in Barcelona. He works on math
e
matical
methods in modelling, optimization, qualitative theory of differential equations and a
p
plications
of mathematics in signal analysis
and business processes. Dr. Swirszcz is currently work
ing on
fault detection algorithms in electric networks. He also continues his fundamental re
search in
various areas of pure and applied mathematics. His interests are creative and innovative applic
a
tio
ns of advanced mathematics and problem solving.
Σχόλια 0
Συνδεθείτε για να κοινοποιήσετε σχόλιο