Using Hardware Scheduling Methods Peter Lieber ECEn 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 ab f c g de 2

Model ab f c g de 2 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

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 ab f c g de 2

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 ab f c g de 2 22

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 ab f c g de 2 22

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 abcdedcb abfcgb edcfbgcd bfcgbfcg