Using Hardware Scheduling Methods Peter Lieber ECEn 625 2 December 2009.

Using Hardware Scheduling Methods

Peter LieberECEn 625

2 December 2009

I like trains, trains are cool…They go fastThey follow a predetermined routeThey can haul an enormous amount of cargoThey sound coolI can play with them until I dieThey just look cool

Public TransitSchedules: The difference between success

and failureGood Schedule == economical and enjoyableBad Schedule == low use and waste of time

Infrastructure: Dictates much of the cost of a systemAnalogues to Binding and Area usage in

hardwareBetter infrastructure can encourage ridership

Public TransitGood Bad

FreightSchedules: The difference between success

and failureGood Schedule == economical and speedBad Schedule == low use and hard to manage

Infrastructure: Dictates much of the cost of a systemAnalogues to Binding and Area usage in

hardwareBetter infrastructure can get trucks off the road

Model TrainsSchedules: The difference between bored

kids and funGood Schedule == lots to seeBad Schedule == long waits and short thrills

Infrastructure: Cost? We don’t care, we like trainsAnalogues to Binding and Area usage in

hardwareBetter infrastructure can seem more realistic

Model TrainsGood Bad

GoalApply 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 linesThe common way railroad infrastructure is

modeled in the literatureVertices: Railroad stations or important

network pointsEdges: Tracks connecting these points

Traditional ApproachDevelop a modelDetermine objective(s) and constraintsMap model into mathematical formulationMap objectives and constraints into

equationsThrow it at an ILP solverSound simple?

Traditional Approach - ExampleTheir parameters:

Traditional Approach - ExampleTheir parameters:

Traditional Approach - ExampleTheir parameters:

Traditional Approach - ExampleTheir parameters:

Traditional Approach - ExampleTheir decision variables:

Traditional Approach - ExampleTheir decision variables:

Traditional Approach - ExampleTheir Objective Equations:

Fuel Consumption Cost

Traditional Approach - ExampleTheir Objective Equations:

Travel Time Cost

Traditional Approach - ExampleTheir Constraint Equations

Traditional Approach - ExampleTheir Constraint Equations

My ApproachUse hardware scheduling concepts to

schedule trainsAlgorithmic approach rather than ILPCan we use IMS?Start with a simple, greedy approachMove to better algorithms and heuristics

ModelLayout – track configurationRoute – path a train takes on the layout

a b

f

c

g

d e

2

Model

a b

f

c

g

d e

2

Route 1: A B C D E D C BRoute 2: A B F C G BRoute 3: E D C F B G C DRoute 4: B F C G B F C G

Naïve Greedy Algorithmforeach 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

a b

f

c

g

d e2

Greedy Algorithmt = 0while 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 Algorithmt = 0while 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

a b

f

c

g

d e

2 2 2

Restarting BT Greedy Algt = 0While 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

a b

f

c

g

d e

2 2 2

Improvement AttemptsSo far, the order of iterating through the

routes is not knownCan we order them in such a way to minimize

route duration?Can we order them to maximize movement?

Ordered BT Greedy Algorithmt = 0while 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 Algt = 0While 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++}

ChallengesFind the right heuristic for route order

Next step is to be less greedyBig 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 IMSNot only are we resource-constrained, the

DGs (routes) are bound already. The DG is ALL routes combined into one,

unconnected, graphEach station in the layout is a resource typeAfter 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