1. Vehicle Routing and Job Shop Scheduling:
What’s the difference?
J. Christopher Beck, Patrick Prosser, Evgeny Selensky

2. What this talk is about
VRP & JSSP are essentially the same (NPC)
There are specialised toolkits for VRP and for JSSP
e.g. Dispatcher & Scheduler
As VRP becomes less pure it looks more like JSSP
As JSSP becomes less pure it looks more like VRP
When should we treat a VRP as if it were a JSSP?
When should we treat a JSSP as if it were a VRP

3. VRP Objective minimise travel minimise vehicles used
Like a TSP but with many salesmen

4. VRP Can be richer time windows on visits capacity of vehicles
type of vehicle
type of visit
sequencing between visits
minimise time of last visit
Like a TSP but with many salesmen

5. VRP Specialised Tool Kit ILOG Dispatcher Local Search GLS & TS
Construction Techniques
Savings etc
Weak propagation
Typically
Like a TSP but with many salesmen

6. JSSP

7. We have
a set of resources
a set of jobs
a job is a sequence of operations/activities
sequence the activities on the resources

8. An example: 3 x 4
Op1.1
Op1.2
Op1.3
Op1.4
Op2.1
Op2.2
Op2.3
Op2.4
Op3.1
Op3.2
Op3.3
Op3.4
job1
job2
job3
We have 4 resources: green, yellow, red and blue
a job is a sequence of operations
each operation is executed on a resource
each resource can do one operation at a time
the duration of an operation is the length of its box

9. An example: 3 x 4
Op1.1
Op1.2
Op1.3
Op1.4
Op2.1
Op2.2
Op2.3
Op2.4
Op3.1
Op3.2
Op3.3
Op3.4
Op1.2
Op2.1
Op3.4
Op1.1
Op2.3
Op3.1
Op1.3
Op2.2
Op3.3
Op1.4
Op2.4
Op3.2
And so on

10. Why bother?
Minimise makespan
Maximise start
JIT, minimise inventory levels
minimise idle time on resources
maximise ROI
...

11. Variants of jsp
openness:
variety of resources can perform an operation
processing time dependant on resource used
set up costs, between jobs (transition cost)
consumable resources
such as gas, oil, etc
pre-emption
can stop and restart an operation
resource can perform multiple operations simultaneously
batch processing
secondary resources
people, tools, cranes, etc
etc

12. JSSP
Specialised toolkit
ILOG Scheduler
Depth 1st search or LDS
powerful propagation
texture based heuristics

13. JSSP <-> VRP
We can model a jssp as a vrp
resources are vehicles
activities are visits
set up costs between activities are travel between visits
sequence within a job is sequence between visits
but these visits are on different vehicles
minimise completion of latest visit
… and then solve with Dispatcher
NOTE: pure jssp is a weird vrp
We can model a vrp as a jssp
vehicles are resources
visits are activities
distances are set up costs
a job has a single activity/visit
minimise transition times (set ups)
… then solve with Scheduler
NOTE: pure vrp is weird jssp

14. JSSP <-> VRP
VRP
JSSP
Scheduler
Dispatcher ?
There is a spectrum of problems
As we vary characteristics of problems
do we move across the spectrum and
make better use other toolkits?

15. Features we can change for VRP & JSSP
alternative resources
VRP, specialised fleet
JSSP, openness
temporal constraints
VRP, add sequencing constraints between visits
JSSP, remove sequencing constraints between activities
duration to transition time
VRP, increase time at visit and decrease travel between visits
optimisation criterion
VRP, minimise makespan (normally minimise travel & vehicles used)
JSSP, minimise transition times (normally minimise tardiness)
temporal slack
how will this affect technology used?
resource capacity
the number of activities/visits a resource/vehicle can do/make in a solution
How do these 6 parameters affect solution technology?

16. The experiments
VRP -> JSSP
Generate a vrp
solve using Dispatcher, 10 minutes cpu, solution cost Y
solve using Scheduler, 10 minutes cpu, solution cost X
result is X/Y
25 vehicles, 100 visits
Mutate using one of 6 parameters
JSSP -> VRP
Generate a jssp
solve using Dispatcher, 10 minutes cpu, solution cost Y
solve using Scheduler, 10 minutes cpu, solution cost X
result is X/Y
10 by 10
Mutate using one of 6 parameters

17. Pure vrp & pure jssp
VRP
Dispatcher is far better at pure vrp than Scheduler
JSSP
Scheduler is far better at pure jssp than Dispatcher

18. Alternative resources
VRP
with high vehicle specialisation Dispatcher fails to find solutions
we suspect culprit is the savings heuristic
find first solution with Scheduler then improve with Dispatcher
JSSP
Scheduler dominates Dispatcher
Dispatcher has to start from a Scheduler solution
precedence constraints cripple Dispatcher
as alternative resources increase neighbourhood increases
more failures due to precedence constraints

19. Resource Capacity
VRP
Dispatcher dominates Scheduler
as we increase vehicle capacity Dispatcher improves (relatively)
a loosening of resource constraints weakens Scheduler’s propagation
¬JSSP
allow activities to be performed on any machine, i.e. not a JSSP!
vary number of activities a machine can perform (from 100 down to 13)
Scheduler dominates Dispatcher
as capacity increases Scheduler gets even better than Dispatcher
probably because neighbourhood increases
many rejected Dispatcher moves due to precedence constraints

20. Precedence Constraints
VRP
Dispatcher dominates Scheduler
… but we need to start from a Scheduler solution
Dispatcher degrades relatively as we add precedence constraints
JSSP
When no precedence constraints, we are in P and both find optimal solutions
As we add precedence constraints Dispatcher needs a Scheduler 1st solution
Dispatcher is then gradually dominated by Scheduler

21. Activity Duration v Transition Time
VRP
Dispatcher dominates Scheduler
varying duration and transition times has little effect
JSSP
Dispatcher dominates as we increase transition times
… but we need to start with Scheduler solution

22. Optimisation Criterion
VRP minimise makespan
Dispatcher and Scheduler compete
possibly due to propagation through cost function
JSSP minimise transition times
Dispatcher competes with Scheduler
… but we need to start with Scheduler solution

23. Slack
VRP
Dispatcher dominates Scheduler
As slack decreases Scheduler improves relative to Dispatcher
JSSP
Scheduler dominates
As slack decreases Scheduler finds best solution earlier
of course

24. Conclusions
Scheduling technology is robust
frequently comes to the rescue in VRP
VRP technology is crippled by precedence constraints
result of initial construction with Savings
Good option is frequently to
initial solution from Scheduler
improve with Dispatcher
Optimisation criteria has profound effect
we guess this is because of how it affect propagation
VRP still looks like a VRP when travel is compressed
good news for urban problems

25. Know your problem, and understand your technology