Inventory Allocation and Transportation Scheduling for Logistics of Network-Centric Military Operations

kneewastefulAI and Robotics

Oct 29, 2013 (3 years and 9 months ago)

90 views




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.) North-Holland.

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.