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

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

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

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

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

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 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

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

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 toolkit ILOG Scheduler Depth 1st search or LDS powerful propagation texture 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 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?

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