260 likes | 436 Views
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
E N D
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
We have • a set of resources • a set of jobs • a job is a sequence of operations/activities • sequence the activities on the resources
job1 Op1.1 Op1.1 Op1.2 Op1.3 Op1.4 job2 Op2.1 Op2.2 Op2.3 Op2.4 job3 Op3.1 Op3.3 Op3.4 Op3.2 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.1 Op1.2 Op1.3 Op1.4 Op2.1 Op2.2 Op2.3 Op2.4 Op3.1 Op3.3 Op3.4 Op3.2 An example: 3 x 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?
25 vehicles, 100 visits • 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 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 The experiments
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