Unsung Heroes of MultiRail

1. Unsung Heroes of MultiRail 16-October-2012 Marc Meketon

2. Allocation of Resources by Type of O.R. Based SystemIllustrative of typical systems built by railways Tasks: • Modeling • Calibration • Database • Integration • User Interface • Data validation • Reporting • Other analyses • Testing • Documentation • Installation • Other (non-OR) • Project Mgmt • Business Analysis • System admin SEMI-REAL-TIME PLANNING

3. Sally – our O.R. Protagonist • Sally is a somewhat newly minted O.R. PhD. She has one-year of experience with the her employer, a large railway. • Through Sally’s viewpoint, we will see the project mature and the heroic efforts of the unsung Don’t be shocked at the lack of design – • Sally’s viewpoint is myopic • It is more fun to tell the story this way

4. Life of an O.R. SystemExpand Train Route as seen through the eyes of Sally • Sally, our OR PhD is asked to create algorithm for finding a train route given “key” nodes and the network • Sally researches algorithms and formulas (Dijkstra’s, A*, etc.) • Calculating arrival/departure times shouldbe trivial • She begins implementation… • …But first needs database help from Dannato design structures to read the train route and store the expanded route • Sally polishes her algorithm (network reduction theory, to remove or not to remove from PQ, etc.) • Sally finishes her work! • Sally codes away… • …She thinks she understands data structures (including priority queues), but a random conversation with her computer science trained colleague, Claire, teaches her new tricks • Fibonacci heaps, “bucket” lists, etc.

5. Sadly, Sally learns that the task has just begunComplex Business Rules • Asked to calibrate her results against established train schedules… • …Her train arrival/departure times are different! Apparently, D ≠ RT! • Her dwell times aredifferent! • Time zones! • She consults with service designer Stevie • Certain yards want arrival/departure times roundedto nearest 5 minutes • Dwell time rules aren’t merely additive; crew lead time isparallel to fueling, but additiveto PU/SO times • Some yards use different time zones for entering versus leaving a yard, depending on train direction. • Needed help from the mainframe Cobol programmer (Carol) who seems to be the only one that really understands time zone rules. • Sally finishes calibration! • Her client (Stevie) sometimes wants to enter initial departure time and run times and have her system calculate arrival/departure times. • [Sally is then told by the Project Manager, Pamela, that she should be going through the IT Business Analyst, Irene]

6. Sally is fooled againShe learns that an algorithm is not a system • No user interface, no ability for user to enter data or override route or time calculations • Despite her fancy algorithms, expanding all the trains is still slower than expected • Needs to interface to more systems • DiscoversCalibration ≠ Tested • Ingrid, the User Interface expert, is brought in to create a “Train designer” that uses calls Sally’s algorithm. • Marie joins Ingrid, with Marie showing the trains routes on a map. • Claire, her computer science colleague, works extensively with Sally to create a multi-core version of the algorithm • Practically a complete rewrite of the algorithm (it had too many static variables) • Claire fixed Sally’s lack of software standards (variable names, etc.) • Code becomes “maintainable” • Danna implements database constraints to ensure better referential integrity • Ingrid, still working away on the user interface • Valerie assists by developing various validations of the manually entered data. • Theresa builds interfaces between the mainframe Train Scheduling System and this new product

7. Sally & Team Keeps up the PaceShe learns that an algorithm is not a system • Sally’s algorithm/code would be useful for another application, this time browser based • But needed to add acceleration “physics” • Wilma, a web-service specialist, re-architects Sally’s code to be used as web-service and/or a client service • Wilma continues by ensuring the code is scalable to hundreds of users – Claire’s re-write was a truly necessary. • Ingrid& Marie are bringing to completion the user interface • Roberta is helping out by creating a number of reports that use Sally’s algorithmic results (train-miles, train-hours, crew-starts) • Ingrid starts working on an editable String-Line graphics to display the expanded trains • Sally discovers complexities in adding acceleration/deceleration • Wilmacompletes the re-architecture of Sally’s expanded train route algorithm into a web-service • Roberta completes the reports • Valeria completes the validations • Theresa completes the integration with the TSS • Danna fine tunes some database aspects • Ingrid finishes the string-line user interface • Sally is impressed with how her colleagues really put together this system. Finally it’s done! • … or not!

8. Closing to the FinaleSally’s little algorithm grew up! • Hard core testing begins, with Terry leading the test group. • Sally’s algorithm bombed when called from the string-line program under multi-user demands • Claire needed to rethink some of her multi-core tricks that collided with the multi-user aspect of the code • Danna needed to implement some record locking rules • Pamela (project manager) demands to know when the project will be finished. • Wendy wrote extensive user documentation • Ingrid wrote system installation documentation, guidelines for the help desk • Theresa formally documented the interfaces to the mainframe TSS system. • The team celebrates completion and installation of the system. • The fantasy begins: The users are wildly happy – no bugs, all the features they wanted were included

9. Sally Gives INFORMS Presentation • She gives a nice, 22 minute presentation that describes her algorithm • Modified Dijkstra’s • Fancy priority queue implementation • Network reduction strategies • Her results of various experiments on different aspects of the algorithm • How fast it is • How many users call upon it • But the real heroes and their contribution: Danna, Claire, Ingrid, Marie, Roberta, Valerie, Wendy, Wilma, Theresa, Stevie, Pamela, Irene, Terry are never acknowledged! • After all, this is an RAS INFORMS presentation. Isn’t the focus on O.R.??

10. My Unsung Heroes Jini, David, MingDean, Bonnie, David, Kevin, Francis, Stephanie, Toma, Ping, (me), Soma, Alex, Wendy, Sebastian,

11. Second Example: Locomotive Planning Model • A Locomotive/Equipment Planning Model has been installed at several clients • The next few slides try to make one point: the modeling was easy and quick compared to all the other aspects of the system.

12. MultiRail Locomotive Planning System Characteristics of Locomotive PlanA well-formed plan considers many constraints and objectives Locomotives legally assigned to a train Train is assignedsufficient power LOCOMOTIVEMODEL Repositioning Plan Fleet size limits Other: • Efficiency of units • Switching rules • Repositioning costs The plan cycles locomotives from one train to the next

13. MultiRail Locomotive Planning System Model LogicModel uses a sophisticated multi-commodity network flow formulation The solution must satisfy: • Balance (locos in=locos out) • Legality of assignments • Minimum connection time The solution minimizes • Locomotive Transit andtonnage costs • Efficiency of locomotives • Costs for repositioning The solution should satisfy: • Preferred locomotive assignments • Fleet size • No consist busting withtime limits The solution considers all constraints and costs are simultaneously, throughout the entire network

14. MultiRail Locomotive Planning System Software infrastructure to create the planning system is complexThe model is dwarfed by the supporting system Inputs and Input Management Outputs and Output Management • Data Editors • Locomotive sets (business rules) • Fleet size, assignment preferences, minimum connection times, etc. • Projects and operating plan • Validations, data checks • Multi-user considerations • Solution analysis • Key operating statistics • Train assignments and day-of-week details • Outputs saved for projects and locomotive sets • Comparisons between sets • Key statistics archived for future comparisons Model

15. MultiRail Locomotive Planning System Goals of a Locomotive Planning SystemBuilding a good planning system is as important as building a good model Meaningful analysis • Knowing the difference between showing the locomotive assignments, and showing how to understand the locomotive assignments What if’s & comparison • Ability to store multiple sets of locomotive plan parameters, run the model for these sets of compare at least the key statistics side-by-side • Ability to run Projects • The ability to store a base operating plan, and variations of the plan as projects Data editingDocument-ation • Making the product easy to use, easy to understand Validations • The ability for the system to make sophisticated checks of the model input and give warnings, errors and indications of problems Archiving • The ability to store key statistics for later comparisons (e.g. year-over-year)

16. MultiRail Locomotive Planning System The Locomotive Planning System uses Projects and Locomotive Sets Project name Locomotive setname

17. Many Adjustable Business Rules are contained in a Locomotive Set Locomotive switch times Fleet size limitations User preferences for locomotive assignments

18. MultiRail Locomotive Planning System Locomotive Sets Contains Adjustable Business RulesFull management of locomotive set; can be assigned to multiple projects Locomotive setmanagement Single loco set assigned to multiple projects

19. MultiRail Locomotive Planning System Analyze Solutions – Locomotive imbalancesCalculating prior to running model

20. MultiRail Locomotive Planning System Analyze Solution – Locomotive assignments by Train Top grid summarizes assignment and productivity for each train Bottom grid details assignments and connections

21. MultiRail Locomotive Planning System Analyze Solution - Connections

22. MultiRail Locomotive Planning System Analyze Solutions – Fleet Utilization Statistics

23. MultiRail Locomotive Planning System Analyze Solutions – Specialized Reports on Train miles, locos/run, etc.

24. MultiRail Locomotive Planning System Analyze Solution – Schedule Improvement Recommendations

25. MultiRail Locomotive Planning System Ability to compare results from two locomotive setsUsually, but not always, within the same project

26. Allocation of Resources by Type of O.R. Based SystemIllustrative of typical systems built by railways Tasks: • Modeling • Calibration • Database • Integration • User Interface • Data validation • Reporting • Other analyses • Testing • Documentation • Installation • Other (non-OR) SEMI-REAL-TIME PLANNING