Vehicle Routing and Job Shop Scheduling:What’s the difference?

J. Christopher Beck, Patrick Prosser, Evgeny Selensky

• 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

What this talk is about

VRP

Like a TSP but with many salesmen

Objective minimise travel minimise vehicles used

VRP

Like a TSP but with many salesmen

Can be richer• time windows on visits• capacity of vehicles• type of vehicle• type of visit• sequencing between visits• minimise time of last visit

VRP

Like a TSP but with many salesmen

Specialised Tool KitILOG Dispatcher

Local Search GLS & TSConstruction Techniques Savings etcWeak propagation Typically

JSSP

We have

• a set of resources• a set of jobs

• a job is a sequence of operations/activities

• sequence the activities on the resources

An example: 3 x 4

• 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

Op1.1 Op1.2 Op1.3 Op1.4Op1.1

Op2.1 Op2.2 Op2.3 Op2.4

Op3.1 Op3.2 Op3.3 Op3.4

job1

job2

job3

Op1.1 Op1.2 Op1.3 Op1.4Op1.1

Op2.1 Op2.2 Op2.3 Op2.4

Op3.1 Op3.2 Op3.3 Op3.4

An example: 3 x 4

Op1.1Op2.3Op3.1

Op1.4Op2.4Op3.2

Op1.2Op2.1Op3.4

Op1.3Op2.2Op3.3

And so on

Why bother?

• Minimise makespan• Maximise start

• JIT, minimise inventory levels• minimise idle time on resources

• maximise ROI• ...

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

JSSP

Specialised toolkitILOG Scheduler

Depth 1st search or LDSpowerful propagationtexture based heuristics

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

JSSP <-> VRP

VRP JSSP

There is a spectrum of problemsAs we vary characteristics of problemsdo we move across the spectrum and make better use other toolkits?

Dispatcher Scheduler?

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?

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

Pure vrp & pure jssp

VRP• Dispatcher is far better at pure vrp than Scheduler

JSSP• Scheduler is far better at pure jssp than Dispatcher

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

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

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

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

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

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

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

Know your problem, and understand your technology