1 / 21

Travel Time Optimization for Public Utility Job Scheduling

Travel Time Optimization for Public Utility Job Scheduling. Jacob Feldman, IntelEngine, CTO (732) 287-1531 feldman@ilog.com Nicholas P. Sekas , LILCO (516) 391-6729 nsekas@lilco.com. LILCO Resource Management System. More than 1 million customers More than 5000 employees

ailish
Download Presentation

Travel Time Optimization for Public Utility Job Scheduling

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. Travel Time Optimization for Public Utility Job Scheduling Jacob Feldman, IntelEngine, CTO (732) 287-1531feldman@ilog.com Nicholas P. Sekas, LILCO (516) 391-6729 nsekas@lilco.com

  2. LILCO Resource Management System • More than 1 million customers • More than 5000 employees • Service territory 1,230 square miles. • Hundreds jobs per day • Job requires a mix of people skills, vehicles and equipment

  3. Family of Scheduling Engines • Construction/Designer scheduling engines • Library Public Utility Scheduling Engines (PULSE) CRMS L I B R A R Y CSE DSE New Engine

  4. Application, Interface, Engine(Pattern “Engine”)

  5. Interface - Abstract Classes • Each interface class specifies only virtual accessors & modifiers (no data members). Sample: class Designer { public: virtual Skill* getSkill() const = 0; virtual void assignJob(Job* job) = 0; virtual int getSelectionCost() = 0; ….. };

  6. Application: Concrete SubClasses of the Interface Classes class lilcoDesigner : public Designer { public: Skill* getSkill() const { return _skill; } void assignJob(Job* job); private: lilcoSkill* _skill; ….. };

  7. Engine: Concrete ILOG-aware Classes class ilogDesigner { public: IlcBool does(ilogJob* job); // may fail …. private: Designer* _designer; IlcUnaryResource _resource; …. };

  8. Pattern “Weighted Selection” • Job selection cost • Weight of Job priority • Weight of LFD • Resource selection cost • Weight of travel • Weight of skill matching, etc. • Configuration files and run-time parameters

  9. Switching Scheduling Strategies • Parameterized strategies • Assign Resources to Jobs • Select the next most important job • Choose the cheapest resource for this job • Assign Jobs to Resources • For the latest scheduled crew of resources find the most important job this crew can do next • Use the pattern “Strategy”

  10. Resources Inside Job Clusters • Prefer a designer with max number of “nearby” jobs (hours) Tom Job-A 5 min cluster Bob

  11. Resources Outside Job Clusters • “Outside time” is a tiebreaker for designers with the same “inside time” Tom Job-A 5 min cluster Bob

  12. Idle Resources • Idle resources are sitting in headquarters • “Idle time” is an another tiebreaker Tom Job-A 5 min cluster Bob HQ Jim (idle)

  13. Unavailability Tolerance • Actual job duration is far different from the original estimate • First, the Engine tries to allocate 100% available resources • If fails, it tries again tolerating partial unavailability but no more the a certain percent of the job duration

  14. Resource Levelization and Travel • Question: utilize All resources at 60% or utilize only 60% of all resources at 100%? • Initially, it serves as a good tiebreaker for resources with the same travel cost • Later, when resources are more utilized, may lead to too many new clusters • Tweaking weight of levelization vs. weight of travel

  15. Skill Matching and Travel • Skills are hierarchical: Skill-C can be replaced by Skill-B Skill-B can be replaced by Skill-A A has a qualification distance 2 from C • Replacement C by A will increase the designer selection cost by 2 * WEIGHT_OF_SKILL_MATCHING • Tweaking weight of skill matching vs. weight of travel

  16. Minimize Travel Vs. Start ASAP • If the “closest” designer is busy during week-1 and ASAP-strategy is set, the Engine will assign another designer. • If the TRAVEL-strategy is set, the Engine will assign the “closest” designer but will schedule start date to week-2

  17. Incremental Clustering Job 5 min 10 min

  18. Strategy “Assign Jobs to Resources” • Daily job clustering • Assign a crew to a job with small duration • What else this crew can do nearby today • Resource pattern hierarchy • Use over-staffed crews for nearby jobs • Use this strategy for jobs far away from HQ • Solving travelling salesperson problem

  19. User Involvement • Scheduling parameters defined via GUI • What-if analysis • change weights and re-run the Engine • set frozen assignments and re-run the Engine • Self-explanatory Engines • Engine Logs • Help from ILOG?

  20. Dynamic Weighting • Provocative conclusion: each data set requires a customized scheduling strategy?! • Computing scheduling metrics up front • Dynamic selection of scheduling weights • Dynamic selections of scheduling strategies

  21. Conclusion • Consider not one but a Family of multi-objective intelligent engines • Keep users involved during the entire system life-cycle. • Use common ILOG design patterns

More Related