© oliver wyman group surface transportation unsung heroes of multirail 16-october-2012 marc meketon

© Oliver Wyman Group SURFACE TRANSPORTATION

Unsung Heroes of MultiRail

16-October-2012

Marc Meketon

2© Oliver Wyman Group 2

Tasks:– Modeling– Calibration– Database– Integration– User Interface– Data validation– Reporting– Other analyses– Testing– Documentation– Installation– Other (non-OR)

– Project Mgmt– Business

Analysis– System admin

Analysis of results2Testing7Documentation3Installation1PL-Crew Planning (psg)100Modeling30Calibration15Database3Sector name 21,687Data validation3Reporting1Analysis of results1Testing16Documentation2Installation1SRT-Crew Planning100Modeling29Calibration59Database1Integration1User interface4Sector name 21,6870% 20% 40% 60% 80% 100% 20% 40% 60% 80% 100%ModelingCalibrationDatabaseIntegrationUser interfaceData valida-tionReportingAnalys is of result sTestingDocumentationInstallationLocomotiveModelingCalibrationDatabaseIntegrationUser interfaceData validationReportingAnalysi s of resultsTestingDocumentationInstallationOp Plan DesignModelingCalibrationDatabaseIntegrationUser interfaceData validationReportingAnaly sis of resultsTestingDocumentationInstallationCrew Planning (psg)ModelingCalibrationDatabaseIntegrationUser interfaceData validationReportingAnalysis of resultsTestingDocumentationInstallationCrew PlanningModelingCalibrationDatabaseIntegrationUser interfaceData validationReportingAnalysis of resultsTestingDocumentationInstallationLocomotiveModelingCalibrationDatabaseIntegrationUser interfaceData valida-tionReportingAnalysis o f resultsTestingDocumentationInstallationEmpty car dist.0% 20% 40% 60% 80% 100%

Allocation of Resources by Type of O.R. Based SystemIllustrative of typical systems built by railways

PLANNING SEMI-REAL-TIME


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


• 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

• 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.

• She begins implementation…

• …But first needs database help from Danna to design structures to read the train route and store the expanded route

Life of an O.R. SystemExpand Train Route as seen through the eyes of Sally


• 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!

• 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]

• 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

Sadly, Sally learns that the task has just begunComplex Business Rules


• 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

• 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

• 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”

• 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.

Sally is fooled againShe learns that an algorithm is not a system

Basel SBB

Maschen Rbf

Basel Bad Rbf

Padborg


• 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.

• 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!

• Wilma completes 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

• 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

Sally & Team Keeps up the PaceShe learns that an algorithm is not a system


• 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

• 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

• 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.

• Danna needed to implement some record locking rules

• Pamela (project manager) demands to know when the project will be finished.

Closing to the FinaleSally’s little algorithm grew up!


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.??


My Unsung Heroes

Jini, David, MingDean, Bonnie, David, Kevin, Francis, Stephanie, Toma, Ping, (me), Soma, Alex, Wendy, Sebastian,


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.

Other:• Efficiency of units • Switching rules• Repositioning costs

The plan cycles locomotivesfrom one train to the next

Locomotives legally assigned to a train

Train is assignedsufficient power

Repositioning Plan Fleet size limitsLOCOMOTIVEMODEL

MultiRail Locomotive Planning

SystemCharacteristics of Locomotive PlanA well-formed plan considers many constraints and objectives

The solution must satisfy:• Balance (locos in=locos out)• Legality of assignments• Minimum connection time

The solution should satisfy:• Preferred locomotive assignments• Fleet size• No consist busting with

time limits

The solution minimizes• Locomotive Transit and

tonnage costs• Efficiency of locomotives• Costs for repositioning

The solution considers all constraints and costs are

simultaneously, throughout the entire network


SystemModel LogicModel uses a sophisticated multi-commodity network flow formulation


Inputs and Input 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

Outputs and Output Management

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


SystemSoftware infrastructure to create the planning system is complexThe model is dwarfed by the supporting system


Meaningful analysis

Knowing the difference between showing the locomotive assignments, and showing how to understand the locomotive assignments

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

The ability to store a base operating plan, and variations of the plan as projects

The ability to store key statistics for later comparisons (e.g. year-over-year)

What if’s & comparison

Projects

Validations

Archiving

The ability for the system to make sophisticated checks of the model input and give warnings, errors and indications of problems


System

Making the product easy to use, easy to understandData editingDocument-ation

Goals of a Locomotive Planning SystemBuilding a good planning system is as important as building a good model


Project nameProject name

Locomotive setname

Locomotive setname


SystemThe Locomotive Planning System uses Projects and Locomotive Sets


Many Adjustable Business Rules are contained in a Locomotive Set

Locomotive switch timesLocomotive switch times

Fleet size limitationsFleet size limitations

User preferences for locomotive assignments

User preferences for locomotive assignments


Locomotive setmanagement

Locomotive setmanagement

Single loco set assigned to

multiple projects

Single loco set assigned to

multiple projects


SystemLocomotive Sets Contains Adjustable Business RulesFull management of locomotive set; can be assigned to multiple projects



SystemAnalyze Solutions – Locomotive imbalancesCalculating prior to running model



System

Top grid summarizes assignment and

productivity for each train

Top grid summarizes assignment and

productivity for each train

Bottom grid details

assignments and connections

Bottom grid details

assignments and connections

Analyze Solution – Locomotive assignments by Train


Analyze Solution - ConnectionsMultiRail

Locomotive Planning System


Analyze Solutions – Fleet Utilization StatisticsMultiRail



Analyze Solutions – Specialized Reports on Train miles, locos/run, etc.MultiRail



Analyze Solution – Schedule Improvement RecommendationsMultiRail




SystemAbility to compare results from two locomotive setsUsually, but not always, within the same project


Tasks:– Modeling– Calibration– Database– Integration– User Interface– Data validation– Reporting– Other analyses– Testing– Documentation– Installation– Other (non-OR)

Analysis of results2Testing7Documentation3Installation1PL-Crew Planning (psg)100Modeling30Calibration15Database3Sector name 21,687Data validation3Reporting1Analysis of results1Testing16Documentation2Installation1SRT-Crew Planning100Modeling29Calibration59Database1Integration1User interface4Sector name 21,6870% 20% 40% 60% 80% 100% 20% 40% 60% 80% 100%ModelingCalibrationDatabaseIntegrationUser interfaceData valida-tionReportingAnalys is of result sTestingDocumentationInstallationLocomotiveModelingCalibrationDatabaseIntegrationUser interfaceData validationReportingAnalysi s of resultsTestingDocumentationInstallationOp Plan DesignModelingCalibrationDatabaseIntegrationUser interfaceData validationReportingAnaly sis of resultsTestingDocumentationInstallationCrew Planning (psg)ModelingCalibrationDatabaseIntegrationUser interfaceData validationReportingAnalysis of resultsTestingDocumentationInstallationCrew PlanningModelingCalibrationDatabaseIntegrationUser interfaceData validationReportingAnalysis of resultsTestingDocumentationInstallationLocomotiveModelingCalibrationDatabaseIntegrationUser interfaceData valida-tionReportingAnalysis o f resultsTestingDocumentationInstallationEmpty car dist.0% 20% 40% 60% 80% 100%

Allocation of Resources by Type of O.R. Based SystemIllustrative of typical systems built by railways

PLANNING SEMI-REAL-TIME

QUALIFICATIONS, ASSUMPTIONS AND LIMITING

CONDITIONS

This report is for the exclusive use of the Oliver Wyman Group client named herein. This report is not intended for general circulation or publication, nor is it to be reproduced, quoted or distributed for any purpose without the prior written permission of Oliver Wyman Group. There are no third party beneficiaries with respect to this report, and Oliver Wyman Group does not accept any liability to any third party. Information furnished by others, upon which all or portions of this report are based, is believed to be reliable but has not been independently verified, unless otherwise expressly indicated. Public information and industry and statistical data are from sources we deem to be reliable; however, we make no representation as to the accuracy or completeness of such information. The findings contained in this report may contain predictions based on current data and historical trends. Any such predictions are subject to inherent risks and uncertainties. Oliver Wyman Group accepts no responsibility for actual results or future events.The opinions expressed in this report are valid only for the purpose stated herein and as of the date of this report. No obligation is assumed to revise this report to reflect changes, events or conditions, which occur subsequent to the date hereof.

All decisions in connection with the implementation or use of advice or recommendations contained in this report are the sole responsibility of the client. This report does not represent investment advice nor does it provide an opinion regarding the fairness of any transaction to any and all parties.

© oliver wyman group surface transportation unsung heroes of multirail 16-october-2012 marc meketon

Documents

time calculationsdespite

eyes of sally

train direction

different time zones

time zone rules

systemexpand train route

sally finishes calibration

initial departure time