1 / 24

The Canadian Pacific Railway Locomotive Resource Planning Model

A & L ASSOCIATES. The Canadian Pacific Railway Locomotive Resource Planning Model. Presentation to INFORMS Seattle October 26, 1998. Overview of Presentation. Project background Model design Methodology and implementation Status Conclusions. The Canadian Pacific Service Design Vision.

aricin
Download Presentation

The Canadian Pacific Railway Locomotive Resource Planning Model

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. A & L ASSOCIATES The Canadian Pacific Railway Locomotive Resource Planning Model Presentation to INFORMS Seattle October 26, 1998

  2. Overview of Presentation • Project background • Model design • Methodology and implementation • Status • Conclusions

  3. The Canadian PacificService Design Vision “Canadian Pacific Railway will have and use a structured methodology and state of the art tools for designing, validating, executing, and refining a committed operating plan providing for consistently reliable, competitive service at a low cost.”

  4. MultiRail Implementation at Canadian Pacific • Objective: “The MultiRail Project will provide CPR with a service design package to improve [the] operating plan as represented currently in MTP, CYards, and SMS.” • Major tasks: • Development of service group blocking and train design • Creation of unified operating design structure • Validation of model and resource planning, including crews and locomotives • Plan publication

  5. CPR Requirements from the Locomotive Resource Planning Model • Locomotives required, by type of locomotive and class of service • Inventory of locomotives by type, location, and time • Deadheading requirements • Calibration and manual adjustment capabilities • Summary statistics

  6. Possible Approaches to Locomotive Resource Planning (1) Aggregate planning • Requirements developed from HP-miles and HP-hours required during modeling cycle (2) Network scheduling • Requirements developed from definition of locomotive cycles required to power all trains (3) Combined approach • Requirements developed from locomotive inventories at key terminals and balancing power in network by deadheading

  7. Input Requirements for the A & L Locomotive Resource Planning Model • Train schedules and expected tonnages • Physical network characteristics • Rules governing assignment of locomotives to trains • Locomotive processing requirements and capabilities • Rules governing balancing of locomotive supply and demand

  8. Overview of the A & L Model MultiRail Inputs from CP Segment and schedule information HP/ton requirements Locomotive fleet characteristics Standard locomotive consists Power pool locations Operational parameters A & L Associates Model (written in MS Access) User Adjustments by CPR  Number and type of required locomotives  Running inventories of locomotives at terminals and on the road  Summary statistics

  9. Model Capabilities • Size of problem: • 1,000 + trains over seven-day cycle • 2,400 + terminals • 1,000 + unit locomotive fleet comprised of 16 categories • Time required: • Less than 10 minutes on Pentium class PC • Terminal hierarchy would be defined for each new network

  10. Model Capabilities (Continued) • Scenario Options • Define ideal consists for trains • Define “cycled” power • Default Scenario Options • Locomotive categories and fleet assignments • Default consist assignments • Terminal network data • Locomotive management inputs • Substitution priorities

  11. Outputs of A & L Model • Fleet requirements: locomotive units of different classes required to operate plan • Terminal activity: inventories throughout modeling cycle • Fleet performance statistics: utilization, horsepower-hours, gross-ton miles, and productivity

  12. Modeling Assumptions Regarding Pooling of Locomotives • Units that come off inbound trains are serviced and then become part of a power pool. • Outbound trains take units from the power pool as needed without regard to inbound trains. • In cases of shortages of units, additional power must be sent to the terminal or certain trains must be under-powered, delayed, or cancelled. • In cases of surpluses of units, fleet managers must decide whether units should be sent to terminals where they can be used more effectively.

  13. Modeling Methodology (1) • Default consists based on train category and terminal location are assigned for each train route segment where a locomotive consist is indicated in MultiRail. • The number of units assigned is adjusted to reflect the minimum power requirements and manual overrides entered by the model user. • Locomotive lineups are created for each terminal.

  14. Modeling Methodology (2) • Deadheading requirements are determined by aggregating weekly supply and demand of locomotives at terminals to identify surpluses and deficits. • Locomotive demand is balanced over the CP network in a pre-arranged set of steps in which smaller and more peripheral terminals reconcile surpluses and deficits with their “source” terminals.

  15. Calculating Network Locomotive Demand • Classification of terminals into four levels: • Hump Yards • Regional Yards • IMS and Local Yards • Other Terminals (e.g., customers) • Categorization contained in MultiRail data on terminals • Higher order yards are successively balanced with lower order yards associated with them based on proximity

  16. Calculating Network Locomotive DemandSimplified Diagram of Stage 1—Balancing Demand from Customer Yards into Local Yards South Edmonton Golden Sutherland Coquitlam Alyth Yard Winnipeg Quebec Moose Jaw Lethbridge Thunder Bay St. Luc Ottawa Stinson Yd Toronto Yard Lambton St. Paul Yd Kenwood Yd Milwaukee Selkirk Bensenville Clearing Yard Blue Island

  17. Calculating Network Locomotive DemandSimplified Diagram of Stage 2—Consolidation of Demand into CPR’s Hump and Regional Yards South Edmonton Sutherland Coquitlam Alyth Yard Winnipeg Moose Jaw Lethbridge Thunder Bay 67 St. Luc Toronto Yard Lambton St. Paul Yd Milwaukee Selkirk Bensenville Clearing Yard Blue Island

  18. Calculating Network Locomotive DemandSimplified Diagram of Stage 3—Consolidation of Demand into the Six CP Hump Yards Alyth Yard Winnipeg Toronto Yard St. Paul Yd Bensenville Clearing Yard

  19. Calculating Network Locomotive DemandSimplified Diagram of Final Stage—Balancing Demand Among Calgary, Winnipeg, and St. Paul Hump Yards Alyth Yard Winnipeg St. Paul Yd

  20. Taking into account the required light moves, terminal and road inventories are created for the modeling period. Initial inventories are adjusted to avoid excess deficits, taking into account servicing and maintenance requirements. The number of units required under an operating plan, as well as other summary statistics, can be obtained by summing over the terminal and road inventories. Modeling Methodology (3)

  21. Locomotive Inventory Graphic

  22. Model Architecture Queries and Visual Basic Code Queries and Visual Basic Code MultiRail Input Tables Intermediate Tables Output Tables & Reports MMTRN Terminal locomotive transactions Terminal locomotive transactions Terminal locomotive inventories MMTRNSCH Consist assignments Required fleet size and summary statistics Terminal locomotive surpluses & deficits MMNDESUM MMTRNRTV

  23. Current Status • Model has been completed and tested with inputs from CP Rail • Basic functionality has been demonstrated • MultiRail functions as effective source of inputs • Calibration and validation requires comparison to actual performance

  24. Conclusions • Use of knowledge of the network and of the problem made it possible to simplify the analysis into a one-pass process • Several parameters facilitate calibration, but calibration still requires actual performance data that may not be readily available • Speed and capabilities of personal computers with standard software now permit effective handling of “real world” problems

More Related