420 likes | 768 Views
Train Scheduling. Using Hardware Scheduling Methods. Peter Lieber ECEn 625 2 December 2009. I like trains, trains are cool…. They go fast They follow a predetermined route They can haul an enormous amount of cargo They sound cool I can play with them until I die They just look cool.
E N D
Train Scheduling Using Hardware Scheduling Methods Peter Lieber ECEn 625 2 December 2009
I like trains, trains are cool… • They go fast • They follow a predetermined route • They can haul an enormous amount of cargo • They sound cool • I can play with them until I die • They just look cool
Public Transit • Schedules: The difference between success and failure • Good Schedule == economical and enjoyable • Bad Schedule == low use and waste of time • Infrastructure: Dictates much of the cost of a system • Analogues to Binding and Area usage in hardware • Better infrastructure can encourage ridership
Public Transit Good Bad
Freight • Schedules: The difference between success and failure • Good Schedule == economical and speed • Bad Schedule == low use and hard to manage • Infrastructure: Dictates much of the cost of a system • Analogues to Binding and Area usage in hardware • Better infrastructure can get trucks off the road
Model Trains • Schedules: The difference between bored kids and fun • Good Schedule == lots to see • Bad Schedule == long waits and short thrills • Infrastructure: Cost? We don’t care, we like trains • Analogues to Binding and Area usage in hardware • Better infrastructure can seem more realistic
Model Trains Good Bad
Goal • Apply what we have learned about hardware scheduling and binding to the train scheduling problem • Use what I learn to enable good scheduling of model trains with the goal of : • As much movement as possible!
Model • Not the trains, the circles and lines • The common way railroad infrastructure is modeled in the literature • Vertices: Railroad stations or important network points • Edges: Tracks connecting these points
Traditional Approach • Develop a model • Determine objective(s) and constraints • Map model into mathematical formulation • Map objectives and constraints into equations • Throw it at an ILP solver • Sound simple?
Traditional Approach - Example • Their parameters:
Traditional Approach - Example • Their parameters:
Traditional Approach - Example • Their parameters:
Traditional Approach - Example • Their parameters:
Traditional Approach - Example • Their decision variables:
Traditional Approach - Example • Their decision variables:
Traditional Approach - Example • Their Objective Equations: • Fuel Consumption Cost
Traditional Approach - Example • Their Objective Equations: • Travel Time Cost
Traditional Approach - Example • Their Constraint Equations
Traditional Approach - Example • Their Constraint Equations
My Approach • Use hardware scheduling concepts to schedule trains • Algorithmic approach rather than ILP • Can we use IMS? • Start with a simple, greedy approach • Move to better algorithms and heuristics
Model • Layout – track configuration • Route – path a train takes on the layout 2 f a b c d e g
Model Route 1: A B C D E D C B Route 2: A B F C G B Route 3: E D C F B G C D Route 4: B F C G B F C G 2 f a b c d e g
Naïve Greedy Algorithm foreach route { t = 0 while route is not done { if step s of route at time t is not occupied schedule the route's next step at time t t++ else wait at time t (stall) t++ } }
Naïve Greedy – Results 2 f a b c d e g
Greedy Algorithm t = 0 while any route's schedule is not done { foreach route that is not done { if the route's next segment is no occupied schedule the route's next step at time t else schedule the route's current step again (stall) } t++ } Problem: we can get into deadlock
Backtracking Greedy Algorithm t = 0 while any route’s schedule is not done { … if all routes stalled { unschedule stalled steps force the first route to schedule next step foreach other route { if the route's next segment is no occupied schedule the route's next step at time t else if the route's current segment is overfull increase capacity of the next segment schedule the route's next step at time t else schedule the route's current step again (stall) } } … }
Backtracking Greedy Algorithm 2 f 2 2 a b c d e g
Restarting BT Greedy Alg t = 0 While any route's schedule is not done { foreach route that is not done { … } if all routes stalled { … foreach other route { if the route's next segment is no occupied schedule the route's next step at time t else if the route's current segment is overfull increase capacity of the next segment restart scheduling with new capacities else schedule the route's current step again (stall) } } t++ }
Restarting BT Greedy Alg 2 f 2 2 a b c d e g
Improvement Attempts • So far, the order of iterating through the routes is not known • Can we order them in such a way to minimize route duration? • Can we order them to maximize movement?
Ordered BT Greedy Algorithm t = 0 while any route's schedule is not done { foreach route that is not done ordered by number of steps left { if the route's next segment is no occupied schedule the route's next step at time t else schedule the route's current step again (stall) } if all routes stalled { … } t++ }
Restarting Ord BT Greedy Alg t = 0 While any route's schedule is not done { foreach route that is not done orderd by number of steps left { … } if all routes stalled { … foreach other route { if the route's next segment is no occupied schedule the route's next step at time t else if the route's current segment is overfull increase capacity of the next segment restart scheduling with new capacities else schedule the route's current step again (stall) } } t++ }
Challenges • Find the right heuristic for route order • Next step is to be less greedy • Big difference from what we are used to: • while an operation of a DG cannot be executed, we usually dont think of it as taking any resources. Under this model, however, the train actually is still using the previous resource. • A TRAIN CANNOT BE NOWHERE!!!
Mapping to IMS • Not only are we resource-constrained, the DGs (routes) are bound already. • The DG is ALL routes combined into one, unconnected, graph • Each station in the layout is a resource type • After running IMS, the required number of each resource is the minimum capacity for that station
Mapping to IMS a b c d e d c b a b f c g b e d c f b g c d b f c g b f c g