How to understand and use Violations and UnscheduledOrders

This forum deals with any kind of trip optimization whether it is automatic planning or manual dispatching, refering to transport orders or service planning.

How to understand and use Violations and UnscheduledOrders

Postby Bernd Welter » Wed Feb 13, 2019 10:52 am

Hi there,

every once in a while users of an optimization tool face some of the following conditions:

After an automated planning call one or more orders remain unscheduled or the result tour is supposed to be "not optimal" ("I guess I have a better sequence in mind"). Now the dispatcher wants to know the cause for such a result.

To support the search for the cause we offer two elegant mechanisms I'd like to draw your attention to:
#1: perform a so-called "UnscheduledOrderAnalysis". This will tell you about orders which remain unscheduled after a creative phase (such as construction or improvement)
#2: cross check whether "the better sequence" is really valid, i.e. whether it takes care of 100% of the given restrictions. If not: "it is not a better sequence" which means "the dispatchers assumption was wrong".

Now let's check #1 first:

Be aware that potential causes can be separated into the following categories:
  • The order itself is the cause! No resource would be able to deal with the order because of insufficient skills, not matching opening times (or not both at the same time). This is UNSCHEDULED_DUE_TO_VEHICLES (The stop was not planned due to the vehicles. For example there was no suitable vehicle or there are already other stops in the tour.)
  • Though there would be resources matching all required skills, opening times and capacity restrictions there is some other (global) restriction that prevents us from scheduling the order, e.g. there are too many orders at all so a tour would exceed an operating interval or maximum tour length. This is a UNSCHEDULED_DUE_TO_PLAN.
  • Well: sometimes an order could be scheduled but we just didn't find the solution. Maybe the algorithm requires more time for an improvement phase or the heuristics just fail due to suboptimal processing sequence. This kind of a cause is called FEASIBLE: The stop is not scheduled in the input plan but it could be scheduled without a violation. The reason why this stop is not scheduled is most likely the fact that the construction step refuses to schedule stops that do not match some general conditions such as the maximum earliness. The improvement stop will schedule the stop then, so please switch on the improvement stop.
To trigger the UnscheduledOrderAnalysis in xTour you can either
  • use the UnscheduledOrderAnalysisParams class in combination with an input plan and a set of order IDs
  • or use the StandardParams (or any subclass) property maximumNumberOfUnscheduledOrdersToBeAnalyzed which will then determine and analyze some of the unscheduled orders.

Depending on the number of unscheduled orders to be analyzed the performance of a call may decrease.

#2 "better sequence": To evaluate whether the dispatchers assumption is right just provide the input plan based on the better sequence in combination with CalculationParams. Then check whether the output plan is violated (assumption was wrong) or not. In the later case our heuristics may just have failed.

Best regards,
Bernd
Bernd Welter
Senior Technical Consultant Developer Components
PTV GROUP - Germany

Bernd at Youtube
User avatar
Bernd Welter
Site Admin
 
Posts: 1412
Joined: Mon Apr 14, 2014 10:28 am

Return to PTV xTourServer

cron