Blocking Optimizer

1
Blocking Optimizer

• 23 October 2008

Rail Planning Working MultiRail Users
Conference
2
Block optimization as plan of an overall planning
process
Simu-lation

• Flow of traffic items through network
• Check transport times of traffic items, train
  lengths, line and node utilizations

Train optimiz.
Optimization

• Block to train assignments according to
  commercial and operational requirements
• Check node and line utilization by minute

Block optimization

• Find optimal routings with help of algorithms
  (Definition of routing and shunting for every
  traffic item / block)
• Check daily node and line utilization

Traffic

• Generation of basic data
• Setup restrictions and degrees of freedom

Core data
Network
3
Block Optimizer - Objective
Illustrative example
Variant 1
Variant 2
Variant 3
Variant 4
Example
Calculation of variants
Results

• 10 wagons from yard A to yard D
• 9 wagons from yard C to yard D
• Shunting in C or A equivalent to 30km, in B
  equivalent to 50km (interrupted arrows shunting
  operations)

• V1 (10 wagons A-D) ((85km 50km) 10 wagons)
  (9 wagons C-D) ((43km 50km 50 km) 9
  wagons)) 2637 km
• V2 1687 km
• V3 2777 km
• V4 2524 km

• V2 is with 1687 km the most best
• The most expensive variant V3 is 65 more
  expensive than V2 (Average is 43 more expensive)
• High optimization potential

4
Block Optimizer - Objective
Optimization parameters
Aim of optimization
Objective function

• Wagon-km (Costs for using the infrastructure and
  traction costs)
• Number of handlings (Shunting costs)

• Minimize production costs
• Keep restrictions given by infrastructure
• Keep operational limits

• Cost total km Cost total handlings minimal
• Costs per km and per handling are put into
  relation 1 handling (shunting) x km

5
Block Optimizer Constraints

• To achieve an reasonable and workable plan,
  additional hard and soft constraints need to be
  considered
• Yards are only able to handle a certain number of
  wagons per day Set a maximum number of daily
  wagon handlings per yard
• Operating yards should at least handle a certain
  number of wagons per day, in order to satisfy
  their existence (respect fix costs of yard)
  Set a minimum number of daily wagon handlings per
  yard
• Yards are only able to build a certain number of
  blocks per day, some of them are reserved for
  local services Set maximum numbers of local
  and road blocks per yard
• Blocks should contain a certain number of daily
  wagons, in order to be efficient (respect fix
  costs of building a block in a yard and to
  transport it). In smaller yards and with a small
  overall block distance the total fix costs for
  building and transporting the block are lower, so
  that smaller block sizes are more acceptable
  Set minimum number of wagons per block, depending
  on yard categories and overall block
  distances

6
Block Optimizer Constraints

• In some cases there might be contracts or other
  necessities that force to build a certain block
  Set specific must have blocks
• Some theoretical blocks between two yards are
  impossible for technical (only yard exit going to
  wrong direction etc.) or organizational
  (certain locomotive types not available etc.)
  reasons Set specific must not have blocks
• Constraints can be realized as hard or soft
  constraints
• Hard constraints must always be fulfilled in the
  final blocking plan. If there is no blocking plan
  possible that keeps all hard constraints, no
  solution will be delivered.
• Soft constraints should be kept whenever
  possible, but can be broken if they become very
  expensive. A predefined penalty is added to the
  objective function for every broken soft
  constraint. This penalty represents the maximum
  acceptable expenses in operations in order to
  keep the constraint (for example necessary detour
  for traffic because of a too small block)
• Soft constraints should be preferred whenever
  possible.

7
Block Optimizer - Multiple traffic categories

• The block optimizer is able to deal with multiple
  traffic categories
• Ability to specify sub-networks for, say, postal
  or automotive traffic
• Blocks can be reserved for certain traffic
  categories
• Yard can be restricted by traffic categories
• Ability to weight the traffic category within the
  block category for a restricted use of blocks in
  other sub-networks by traffic in certain
  circumstances
• Two modes of multiple traffic category
  optimizations have been used
• Separate optimization runs for different
  sub-networks Relatively quick optimization runs
  if there is only very limited use of blocks by
  traffic from other sub-networks and number of
  allowed blocks for each sub-network in a yard is
  fix
• Integrated optimization run for all sub-networks
  in parallelPreferred if different sub-networks
  are widely used by traffic from other
  sub-networks and there no fixed assignments of
  allowed number of blocks for each sub-network in
  the yards (optimizer tries to find best
  assignments)
• More work is being done to deal with multiple
  competing traffic categories in a yard (How many
  blocks are allowed for each traffic category?
  Create separated blocks vs. create integrated
  blocks? Etc.)

8
Block Optimizer - Roll up traffic

• As a complete specification of all constraints
  for local traffic in a sufficient level of detail
  is very difficult or even impossible, one may
  decide to roll up the traffic to serving yards
• Serving yards can be defined by their type or
  individually
• Two possible traffic roll up strategies
• Sequencer logic find first and last Serving
  yard or higher nodes based on existing traffic
  sequences
• Nearest neighbor logic find nearest Serving
  yard or higher nodes to the real origin and
  destination node of the traffic
• Overrides are possible
• Existing blocks between serving yards can be
  flagged as local, so that the block destination
  is considered as the first Serving yard on the
  traffic flow
• Currently the block optimizer just cares about
  the part of a traffic flow between its first and
  last Serving yard and ignores the local
  operations at the begin and the end of the
  traffic flow

9
Block Optimizer - Roll up traffic

• If absolute named / CT Layer rules are used or if
  a Serving yard contains secondary locations
  there might occur some problems with current
  traffic roll up
• absolute rules of non-optimized local blocks
  might negatively influence traffic flows in the
  optimized blocking plan
• secondary locations of a serving yards might in
  fact be local sidings which should not be part of
  the optimization
• Therefore a kind of pre-optimization of local
  traffic is thought about
• find suitable serving yard(s) for each local node
  based on destinations (origins) of the traffic
  starting (ending) there
• create new local blocks for first and last mile
  of traffic flows
• roll up traffic based on these new pre-optimized
  local blocks
• This way the local traffic is also part of the
  optimization process

10
Block Optimizer - Technology

• Heuristic based
• Cold start or warm start possible. Cold
  start is based on a set of defined rules for
  building a hierarchical blocking plan warm start
  is based on current plan
• Insertion and deletion strategies
• By-pass block possibilities
• 2-opt (if I delete block A ? B, can I add in
  other block(s) to make routing A ? C ? B
  possible?) examinations
• Ongoing experimentation with other strategies
• Various block deletion strategies
• Some important design questions
• What next optimization step is best? (Set up
  order of steps)
• How to make sure that whole process makes
  progress on optimality, but does not get stuck
  in a local optimum?
• In what extent shall constraints temporarily be
  broken during the optimization run?

11
Block Optimizer - Technology

• Example Insertion of large by-pass blocks and
  closure of a yard

12
Block Optimizer - Technology

• Example Remove a long distance block with low
  utilization and insert a shorter alternative block

A
2 wagons
C
12 wagons
B
13
MREE ComponentsIntegrated block optimizer model
Placing the block optimizer within MREE gives
planners the ability to quickly see estimates of
handlings, circuity, block sizes when
re-optimizing. All of MREE outputs are
available. Simplifies running the model when
MREE data is coupled the block optimization
parameters.
Traffic Manager
Network Manager
Block Manager
Train Manager
Report Manager
Block Optimizer
Algorithmic andrule-basedblock sequencing
Locomotive Module
Trip planSimulation
14
Benefits of using a Block Optimizer Integrated
into MREE

• MREE, as a planning tool, is perfect for housing
  the block optimizer model
• The primary data of traffic and network are
  already contained in MREE
• MREE has been extended to contain other data
  needed for the block optimizer
• In general, the block optimizer model needs care
  to setup the parameters correctly and to properly
  calibrate the model.
• Putting the model in MREE allows planners to run
  it within projects, thereby allowing easier
  comparisons between projects with, say, different
  assumptions on yard penalties.
• Placing the block optimizer within MREE leads to
  the much more use of the model by breaking down
  barriers of the degree of complication to run it.
• Results of the block optimization can easily be
  used in further planning process steps (train
  planning) without major data export / conversion
  / import issues.

15
Block Optimizer - User interface

• The MREE block optimizer user interface provides
  many possibilities to adjust the models
  parameters

16
Block Optimizer - User interface
Traffic Supercompression
Define super traffic categories in order to
compress the MREE traffic file for speed purposes
17
Block Optimizer - User interface
Traffic Roll-up
Define serving yards and specific traffic roll-up
parameters
18
Block Optimizer - User interface
Mandatory and forbidden blocks
Define Must have and Must not have blocks
19
Block Optimizer - User interface
Building blocks
Define rules to set up an initial hierarchical
blocking plan (cold start)
20
Block Optimizer - User interface
Sequencing traffic
Define rules (multipliers) which traffic category
is allowed to use which block types
21
Block Optimizer - User interface
Hard and soft constraints
Define constraints on block and yard capacities
as well as amount of penalties for violating
these constraints
22
Block Optimizer - User interface
Algorithmic options
Set specific algorithmic options on mode of
optimizer run
23
Block Optimizer - User interface
Import/export setup
Select dataset to import or export a block
optimizer setup for later use
24
Block Optimizer - User interface
Select output project
Select a project to write the block optimizer
results into
25
Block Optimizer - First project experiences

• A block optimizer prototype was initially used in
  two consulting projects for Swiss Federal
  Railways (Schweizerische Bundesbahnen - SBB)
• Generation of an operational concept for 2008
  (improvement of existing blocking plan)
• Hub strategy study for 2020 (completely new
  blocking plans for different sets of hubs)
• Besides use at SBB, its been used for a study at
  Canadian Pacific, and created the initial
  blocking plan for the ongoing Transnet zero-based
  project

26
Block Optimizer - First project experiences
Illustrative example SBB Cargo
Gross-Ton-Kilometers
Number of handlings
- 12,6
- 3,3
27
Block Optimizer - First project experiences
Illustrative example SBB Cargo
Intermediate Handlings BO Output vs. Base Case
Number of wagons
Number wagons Base Case
Number wagons BO Output
Number of intermediate handlings of single
traffic flow
28
Block Optimizer - First project experiences
Illustrative example SBB Cargo
Traffic increase vs. Base Case
Traffic decrease vs. Base Case
29
Block Optimizer - First project experiences

• Example Hub strategy result

Scenario Close Yard G
Scenario Close Yard A
Wagons per day
Wagons per day
Increase of wagons
Decrease of wagons
30
(No Transcript)
31
Locomotive Models in MultiRail
MultiModal Systems Practice

• 13 September 2008

Rail Planning Working MultiRail Users
Conference
32
Common characteristics of Locomotive Models

• Locomotives assigned to a train areallowed to be
  on the train

• Train is assigned sufficient power

LOCOMOTIVE MODEL
Other business rules
Number of locomotivesused within a fleetis
limited by an overallnumber of locomotives
Minimal time is maintain between a
locomotiveterminating on one train and starting
on another train

• A cycle plan is possible that is, there is
  aplan on how every locomotive thatgoes into a
  yard will leave the yard

33
Locomotive Models used in the Industry
Real-time assignment of locomotives for trains
departing soon
Common rules
Strategic Estimatingcurrent and
futurelocomotive fleets
TacticalTarget assignmentof locos to
trainsand basic cycle plan
Locomotive models

• Real-time models must have the current status of
  all locomotives, active trains and trains
  preparing to depart, as well as the best guess
  schedule for trains that will depart over the
  next few days
• Strategic and Tactical models ignore starting
  conditions and develop a cyclic plan for a train
  schedule that repeats itself each week

34
MREE ComponentsIntegrated locomotive model
Placing the locomotive model within MREE gives
planners the ability to quickly see estimates of
fleet size and to judge if a plan is using too
many locomotives. It could also help point out
where deficiencies in the schedule usually poor
timings of train arrival/departure times can
cause excess use of locomotives.
Traffic Manager
Network Manager
Block Manager
Train Manager
Report Manager
Locomotive Module
Algorithmic andrule-basedblock sequencing
Other tools within MREE
Trip planSimulation
35
Benefits of using a Locomotive Model Integrated
into MREE

• MREE, as a planning tool, is perfect for housing
  strategic / tactical locomotive models
• The primary data of train-schedules and
  train-size (weight) are already contained in MREE
• MREE has been extended to contain other data
  needed for locomotive models
• In general, locomotive models need care to setup
  the parameters correctly and to properly
  calibrate the model.
• Once parameters are correctly estimated and
  calibration is complete, a major impediment to
  using the model is to transfer train schedules to
  it. In most railways, the schedules are only the
  published schedules stored in their mainframe
• Putting the model in MREE allows planners to run
  it on projects that are in any phase of
  development, therefore making locomotive fleet
  sizing estimates almost as easy as estimating
  train size for a project.
• Placing the model within MREE leads to the most
  complete use of the model.

36
MultiRail implementations of Locomotive
ModelsCanadian Pacific and Transnet
implementations

• Canadian Pacific Railway
• For Canadian Pacific we built a locomotive model
  with MultiRail Freight Edition. The following
  slides show many of its features. There is
  discussion with the client to move this model to
  MREE.

• Transnet Freight Rail (South Africa)
• A preliminary locomotive model is completed, and
  in the process of moving this to MREE. The model
  for TFR works differently than CPR due to
  differences in business rules. A summary of
  those business rules follows the slides on the
  CPR model.

37
CPR Locomotive Model - Inputs

• Data inputs are grouped
• Schedule
• Recommended locomotive consist
• Forced consist connections
• Parameters
• Schedule
• Usually the manifest, intermodal, auto trains as
  represented in MultiRail
• A representative unit train plan
• Recommended locomotive consist
• CPRS has in their T-Plan a recommended (minimum)
  consist for each train
• E.g., According to CPs T-Plan, train 102 takes 1
  AC44, 2 SD90s from Vancouver to Alyth (Calgary)
  drops one AC44 off and continues on with the
  other two SD90s
• The consist is allowed to change (but not desired
  to change) at Moose Jaw and Winnipeg

38
CPR Train 102 Example of Suggested Consist
39
CPR Forced Connections

• Users can force connections of consist

40
CPR Parameters Treating different locomotive
types

• Group all equipment together
• Simplistic, but might be configured to examine
  horsepower balance
• Combine locomotives into groups
• Allow locomotives to substitute for one another
  if necessary
• SD90 could be substituted for an AC44 in a pinch
• Separate locomotives by model type
• Fleet AC44s, then SD90s, etc.

41
CPR Parameters limits on the number of
locomotives deadheading on trains

• The model decides how to balance power by
• Deadheading power on existing trains
• Switching power between close-by yards in a
  terminal
• Proposing light engine moves
• Some trains are forbidden to deadhead power
• Deadheading power bumps revenue producing cars
  when train size is limited by siding length
• We provide limits on the number of deadheads
• Global limit
• Train-by-train limit

42
CPR Parameters - Penalties for mid-route consist
changes

• At CPRS, the train profile has explicit places
  where the consist is allowed to be changed
• Even if the power profile doesnt call for a
  change, it allows deadheaded locomotives to
  switch on and off
• This flexibility allows a significant reduction
  in the locomotive needs
• BUT, theres a significant operational costs
• The locomotive model has explicit parameters the
  penalize consist changes
• One penalty when train profile already calls for
  a consist change
• Another penalty, usually set to be significantly
  higher, when train profile says to stay the
  course!

43
CPR Parameters Terminal definitions

• A Terminal is a set of close-by yards
• Sometimes, trains tend to terminate more at one
  yard within a terminal, and originate more at
  another yard

• Locomotives are often switched around these
  close-by yards to re-balance power.
• At CPRS, they consider the redistribution of
  power as a free move, costing only the time it
  takes to make the move

44
CPR Parameters Mandatory time spent in yards

• At termination of train, locomotives need to be
  decoupled, possibly inspected, fueled, sanded,
  etc. This is called service time
• Locomotives cannot be immediately coupled to a
  new train, called switch time
• Minimum time spent in a yard may vary by yard

45
CPR Parameters Light Engine Moves

• Speed used to estimate LEM transit time
• Cost per crew
• Cost per locomotive mile
• Cost per locomotive
• Distance of crew district
• Longest (distance) LEM allowed
• Distance for free LEM (no crew cost)

• Drivers of light engine moves
• Need to rebalance to reduce locomotive needs
• Costs of performing a light-engine move
• Mostly crew cost
• Transit time

46
CPR Model Outputs

• Summary statistics
• Terminal view
• Shows locomotive activity within a terminal
• Train view
• Shows assignment, by day-of-week, of locomotives
  on trains
• Locomotive view
• Shows locomotive cycles
• Schedule view
• Shows how to reduce number of locomotives by
  moving train origination times

47
CPR Model Outputs Train View

• Shows power assignments by train
• By day-of-week
• By locomotive type
• Where power came from
• Where power is going to
• Shows locomotive utilization statistics by train
  category
• Shows locomotive utilization statistics by train
• Can filter by train category

48
CPR Model outputs Terminal View

• Shows activity in a terminal (set of close-by
  yards)
• Trains in-and-out of yards
• Inventory over the week of locomotives
• Shows infeasibilities
• Where did system have to reposition locomotives
  that couldnt be handled by light-engine moves or
  intra-terminal moves
• Where did system have to put on more locomotives
  than allowed
• What yards are terminate-only or originate-only?

49
CPR Model Outputs Terminal View Connections

• Rework connections so that they are FIFO or LIFO
• FIFO most evenly distributes the terminal dwell
  time
• LIFO shows where there is the longest possible
  dwell, and therefore indicates where potential
  schedule changes might reduce dwell, or where a
  road locomotive may be available for local
  service and possibly eliminate the need for a
  local locomotive

50
CPR Model Outputs Suggested Schedule Changes

• Example Train 120 originates at 0100. If that
  train could originate 9 hours earlier, at 1600,
  then a locomotive could saved!
• In general, a heuristic is applied to every train
  to see if savings can accrue by moving the
  schedule back or forwards by 12 hours, in
  one-hour increments

51
CPR Model Outputs Locomotive Cycles

• Shows every locomotive cycle, and its utilization
  statistics
• Warning paying too much attention to locomotive
  cycles is dangerous to ones job, especially in
  service design
• Cycles can change when using FIFO, LIFO
• Cycle optimization is not really performed in
  model
• Cycles are broken in the field, especially at
  large yards

52
Transnet Freight Rail rulesTraction regions

• Traction regions define which locomotive types
  are able to operate from technical point of view
  in a certain region
• Four traction regions in the system
• 3 kV
• 25 kV
• 50 kV
• Diesel
• A single train may need to change locomotives 2
  or 3 times as it transverses different traction
  regions.

53
TFR 3kV region
54
TFR 25kV regions
55
TFR 50kV region
56
TFR Diesel region
57
TFR Locomotive terminals

• Locomotive terminals define a neighborhood of
  yards, where single locomotives or locomotives
  consists are completely interchangeable at
  reasonable costs
• The general rule for setting up terminals was
  to combine all the yards with locomotive actions
  within 25 kilometers. These yards should also
  deal with similar locomotive types.
• In some cases yards with larger distances have to
  be combined, to make sure that there are inbound
  as well as outbound trains for that terminal.
  Otherwise you cannot get locomotives into or out
  of the terminal.
• Germiston example on left side

58
TFR Restrictions on locomotive types

• The following locomotive types are defined in the
  model and can be used in following traction
  regions to pull trains
• Any locomotive type can be deadheaded on any
  train.

59
TFR Preferred Locomotive Assignments

• TFR has preferred assignments based on traction
  regions and train types
• An example is that general merchandise types of
  trains have a preferred locomotive consist that
  could be overridden by the model
• Hub-to-hub trains Hub-to-feeder trains
• 3kV 2 x 18E6E 2 x 18E6E
• 25kV 2 x 7E11E 2 x 7E11E
• 50kV 2 x D34D37 2 x D34D37
• Diesel 2 x D34D37 2 x D33D35
• TFR maintains a table of preferred consists for
  many of their unit trains.

60
TFR Creating a balanced locomotive plan

• Based on the preferred locomotive assignments,
  the model is generating a feasible solution
• Main task is to balance the locomotive input and
  output for each yard / terminal and every defined
  locomotive type
• In addition to pulling trains in preferred
  consists, following locomotive movements are
  possible
• intra-terminal movements between yards of the
  same terminal according to an intra-terminal
  movement schedule for that terminal
• deadhead movements adding additional locomotives
  to an existing train without powering the train
  (there shall be no more deadhead locomotives than
  driving locomotives)
• light engine movements of a set of locomotives
  between yards of different terminals
• A locomotive cycle plan can be generated to show
  the locomotive demands
• Besides reducing the total number of needed
  locomotives for a given plan, the cycle plan
  tries to reduce busting of existing consists
  where possible
• Switching and service times respected by the
  cycle plan can be defined for a locomotive type /
  yard combination

61
TFR Improving the plan with locomotive
substitutions

• A consist substitution list is set up for every
  possible preferred consist.
• For example 210E can be substituted by 318E6E,
  3D34D37 or 4D33D35
• With respect to the number of total available
  locomotives per locomotive type, the locomotive
  model tries to reduce the number of necessary
  locomotives and shunting operations by
  substituting the preferred consist with another
  consist where appropriate
• First test runs for TFR show a potential of 10
  less locomotives demand for the same train
  operations by using the substitution strategy
  

62
(No Transcript)
63
Capacitated Trip Planner

• 23 October 2008

Rail Planning Workshop MultiRail Users
Conference
64
Trip Planner

• The trip planner in EE is conceptually simple
  when the block sequence is pre-computed
• Given a release time and day (TIME), and given a
  block sequence
• Set LOCATION and BLOCK to be origin of the wagon
  and the first block in the block sequence
• Find the first train that pickups BLOCK at
  LOCATION on or after TIME
• Set LOCATION to be setout of the train
• Set TIME to be the setout time of the train
• If LOCATION is the destination of the block, and
  thats the last block, done!
• If LOCATION is the destination of the block, and
  its not the last block, then set BLOCK the
  next block
• Go to step 2
• In reality, the EE Trip Planner has many
  complexities
• Trains may terminate a block in locations other
  than the block destination, forcing a resequence
• The last train may not terminate at the
  destination of the traffic
• Various, and in some cases exceedingly
  complicated, rules for cutoff times (including
  negative time cutoffs!)
• The first mile and the last mile of the trip plan
  is often governed by complex, local rules that
  vary from railway to railway

65
Trip Planner

• The choice for which train to take is set by a
  simple rule Take the first train out that has
  the block on it.
• Each traffic record/release time can be
  trip-planned independent of each other
• But other trip planning rules could exist
• Find train path that gets to destination
  earliest. Taking the first train doesnt
  guarantee shortest trip plan
• Introduce a probability of making a connection
• Assume limited train capacity, roll over cars to
  next train based on first-in, first-out
• Assume limited train capacity, roll over wagons
  based on customer priority.
• The introduction of capacity changes the game
  no longer can a trip plan be run for an
  individual wagon movement without consideration
  of other wagons.
• Capacitation is the focus here.

66
Use of Capacitation

• Analyze restrictions on block and train size
• Which provides the ability to analyze putting
  priorities on the blocks
• Primary use is to provide more realistic
  statistics
• Rollover indicators show pressure points in the
  system
• Capacities on blocks allow to do planning to
  handle day-of-week traffic variations
• An by extension, block capacities provide the
  ability to manage traffic variations due to
  non-day-of-week demand variability and
  variability due to operational oops such as
  late trains.

67
Capacitated Trip Planner

• The key to developing a capacitated trip planner
  is to introduce a time-sequence of events.
• The events are
• Release time of wagons
• Pickup of train-blocks
• Setout of train-blocks
• The concept is to list all the events, sorted by
  time, then process events in time sequence.
• Have all yards contain no wagons
• Go to first event
• If event is
• A release time, add wagon to origin yard.
• A train setout, add wagons from the train block
  to the setout yard
• If setout yard is destination and setout train
  block is the last block in sequence, then flag
  the wagon as having a completed trip plan
• A train pickup, select wagons that are in the
  pickup yard to go onto train block
• Go to next event and go back to step 3.

68
Capacitated Simulation Must Examine All Events in
Time Order
Train 101, Block CCC
Train 102, Block DDD
Release at A
dwell
Rel_at_A
PU_at_A
SO_at_C
PU_at_C
SO_at_D
Non-capacitated trip plannerviews eachtrip
separately
Train 202, Block JJJ
dwell
Train 201, Block GGG
Release at A
PU_at_H
SO_at_G
PU_at_G
SO_at_J
Capacitatedtrip plannerviews eachevent in
time order
Time
SO_at_G
PU_at_C
SO_at_J
SO_at_D
Rel_at_A
PU_at_A
SO_at_C
PU_at_G
Rel_at_H
PU_at_H
69
Selecting Wagons

• The main business logic is in the ability to
  select wagons.
• Business logic varies by customer.
• Key concepts of current logic
• Train blocks can be capacitated.
• Wagons could be rejected for that train, yet the
  train capacity might not be reached!
• Train blocks can share capacitation

70
Trip-Planner takes Sequence of yard-blocks on the
Traffic

• Traffic is sequenced to yard-blocks by Sequencer

71
Trip-Planner finds Trains for yard-blocks in the
Sequence
72
Trip-Planner uses Timing of the train Train
Expanded Route, Terminal Standards, and Cutoff
Times to assign the trains to traffic
73
Starting one-by-one Trip-Planner

• Trip-Planner button on the Main screen invokes
  the bulk trip-planning

74
Run options for one-by-one Trip-Planner

• Make sure Capacitated Trip Planner is
  un-checked and click Run

75
Trip-Planner produces the Trip-Plan for each
Traffic release

• It takes 4 days and 20 hours for the trip

76
Capacitated Trip-Planner vs. One-by-one
Trip-Planner

• Capacitated mode. All the traffic is released
  and is assigned to trains in accordance to its
  priority (booking time) but within the capacity
  limits of the train. Closer to reality.
• Additional input for Capacitated Trip-Planner
• Maximum capacity of the train at train-station
• Maximum capacity of the train-block and its
  priority on the train
• Capacitated Trip-Planner produces a similar
  output with the following differences
• Different train assignment to the traffic.
• It might take longer until the traffic is picked
  up by the overloaded trains
• Changing capacity limit on one train can affect
  the volume load of this and other trains
• Potentially more failed trips when capacity
  restrictions will prevent the pick-up of the
  traffic by the trains

77
Capacitated Trip-Planner meets the capacity
limits on train-block and train-route
78
Starting Capacitated Trip-Planner

• Trip-Planner button on the Main screen invokes
  the bulk trip-planning either in one-by-one or in
  capacitated mode

79
Run options for Capacitated Trip-Planner

• Check Capacitated Trip Planner and select Warm
  Up and Stop after periods in weeks

80
Capacitated Trip-Planner produces the Trip-Plan
for each Traffic release

• It takes longer (19 days vs. 4 days before) for
  the traffic to get to its destination due to
  capacity limits of trains at Hallsberg
• A different train picks up the traffic at
  Hallsberg and thereafter

81
Potential Trip Planner Extensions

• The current selection of cars is based on both
  the block (and its priority and capacitation
  limits) and a first-in, first-out discipline.
• A future extension would be to allow cars to be
  selected based on some type of priority other
  than time of arrival.
• The current train schedules are strictly adhered
  to no late trains permitted. Likewise, release
  times and size of release (number of wagons
  released) are strictly held.
• Simulation of early/late trains, randomization of
  release times and possible number of wagons.
  Harder to simulate are effects of other
  operational problems such as annulments, extras,
  maintenance of way.

82
(No Transcript)
83
Wagon Optimizer

• 23 October 2008

Rail Planning Workshop MultiRail Users
Conference
84
Intermodal Planning

• Intermodal planning, especially in non North
  American locations, is the planning of container
  movements
• No TOFC (Trailers on Flat Cars)
• But container is a loose term, and includes
  many types of objects that fit the intermodal
  qualification but cannot be double stacked or put
  into a well (even without double stacking)
• Intermodal planning should beginwith
  origin/destination traffic bycontainer
• Not by wagon

85
Hey, how this picture get here?
86
Wagon Optimizer

• Given container traffic and a proposed train
  schedule, how many wagons, and of what type,
  should be placed on a train? Wagon types are
• Flat cars,
• Wells (and various sizes),
• Skels which are articulated sets of flat cars

87
The need for wagon optimization
Situation
Objectives

• Efficiently utilize available resources to serve
  the growing demand for movement of containerized
  freight
• When equipment supply is limited, difficult
  decisions need to be made on which shipments to
  load onto a train, and which shipments to defer
  to a later train
• Operations are becoming more complex as different
  sizes and types of equipment are used
• Geographical restrictions on double-stacking

• Develop a tool that assigns intermodal wagons to
  trains, such that the number of wagons necessary
  to meet the demand is minimized
• Ensure that all system constraints are met
• Operational
• Network
• Fleet
• Customer Requirements
• Link the wagon optimizer to MultiRail
• Utilize the data in MultiRail as system inputs
• Output the optimizer results back into MultiRail
  for comprehensive evaluation
• Provide a tool that can be used for
• Weekly planning
• What if scenarios, including
• Demand changes
• New services
• Changes to fleet size or type

88
Quick and dirty wagon optimizer prototype

• We built a quick and dirty prototype that
  produces solutions and has many of the major
  concepts of a real wagon optimizer
• Allocates wagons to trains to meet TEU demand
• Understands the geographical restrictions on
  double stacking
• Limits train length
• Finds the minimal platform solution

89
Basic wagon optimizer model design
Constraints
Outputs
Objective function

• A container cannot be assigned to an incompatible
  wagon (e.g., an ugly to a well)
• Restrictions on length and weight of the train
• All container demand must be met (though not
  always on the first available train)
• Wagon flows must be balanced by yard (wagons are
  not created or destroyed at a yard)
• A wagon cannot depart a yard before it arrives
  and is processed
• Double-stacking allowed on part of network

Minimize the number of intermodal platforms
needed to meet the forecasted container
demand -or- Maximize the number of TEUs carried
given a limiting set of wagons

• Wagon trip plans (number of wagons by type and
  location assigned to each train)
• Report format
• MultiRail format for further analysis
• Yard workloads and statistics
• Wagon arrival/departure by location and time
• Containers handled by location
• Stock-outs (lack of wagons)
• Wagon utilization statistics reports
• Number of wagons needed to meet demand
• Wagon slot utilization
• Wagon deadhead Kms
• Container movement statistics reports
• Total containers handled
• Container delays due to equipment unavailability

90
Pacific National Intermodal Flows
91
Need to match use of wagons to container demand
92
Station Activity
93
Role of Capacitation in the Wagon Optimizer and
Trip Plan Simulator

• Demands for container shipments have peaks over
  the course of a day.
• More containers may arrive in the morning than in
  the evening
• From a pure customer delivery viewpoint, without
  regard for wagons, the trains would be sized to
  handle all of the demand. Maybe long trains in
  the morning, short trains in the evening.
• The problem is that is not an efficient use of
  wagons an expensive asset so instead some
  load leveling needs to take place.
• Both the wagon optimizer and the MREE simulation
  capability should understand capacitation
• The wagon optimizer may have a cruder model of
  capacitation, but it should understand the
  tradeoffs between the number of wagons needed,
  the penalty for rolling traffic, and having a
  fixed fleet size.
• The wagon optimizer will not know any more
  detailed rules, such as prioritizing which
  shipments if at all possible are delivered
  asap and not rolled to the next opportunity. But
  the simulation program should understand more of
  these rules.
• The wagon optimizer results may be for a subset
  of the different types of intermodal wagons. It
  is to be determined if this is sufficient for the
  planning model
• The wagon optimizer will probably not model as
  many different container types (and possible
  wagon types) as possible with the simulation
  program. Although we are not endorsing
  developing a separate optimization of how to load
  containers onto the various wagons.

94
(No Transcript)