Distinction between planning scenarios

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

Distinction between planning scenarios

Postby Bernd Welter » Thu Jan 26, 2017 3:23 pm

Hi there,

during a lot of workshops I've been asked for the meaning of the various planning scenarios covered by xTour1.
Quite often I describe tour optimization as "determine best attachment and sequence of orders (transport or tasks) to resources (trucks, cars) vehicles without violating constraints optimizing a goal" (ok, the sentence could be 5 times as long as it is including break- and rest rules and other influences ;-) )... the question is: what is the goal?

Some easy to understand approach is to separate the various classes.

PlanningParams.PNG
blue: the base class that contains parameters required for all the scenarios
green: those scenarios create tours, change sequences and really optimize things
yellow: small optimization - doesn't change sequences but performs reassignments of tours as a whole
red: no optimization at all, just evaluation


Let's start with the pure optimization classes - as they are the most interesting ones:

  • StandardParams: Inputplan optional, creates new tours
    Standard tour planning attributes. The use case described by this class
    executes the standard tour optimization without unusual goals or constraints.

    Use this subclass if you want to perform an optimization where the goal is to reduce a planning goal such as
    • use as few ressources as possible
    • short tours
    • as few unscheduled orders as possible
    This scenario is able to work both from scratch and with a given input plan. It is the base class for any optimization scenario. The other roptimization classes are more or less special cases of StandardPlanning. Input chains that are invalid (=at least one single tour of the chain contains a VIOLATION) will remain unchanged in the output.
    PS: This is also the approach that covers a single vehicle's SEQUENCING task: one truck, start and destination are defined, a set of additional orders has to be placed between start and destination. Special subcases: if there's more workload that vehicle availability you might have to work with priorities.
  • BalancingParams: Inputplan optional, creates new tours
    The use case described by this class executes the tour optimization and considers at the same time to balance the tours with regard to a balancing goal (for example all planned tours have nearly the same tour period). This use case is subject to additional restrictions. Firstly every vehicle performs a tour and so there are no unscheduled vehicles. Secondly every tour chain consists of not more than one tour. Thirdly the tours of one depot are balanced among each other, but there is no balancing between depots. Finally the tour optimization in this use case is focused on depot-related transportation. Therefore it is recommended to use mainly TransportDepot and to add only a smaller part of TransportAB to the planning. The use of the parameter tourReductionStep of StandardParams is forbidden and will throw an exception.

    Use this subclass if you want to spread the workload over the vehicles in a balanced, fair way: each driver should take care of same tour length or quantity (while quantity could mean almost anything such as mass, volume, revenue, service period…). Usually this contradicts to the basic goals of planning (use few...). Creates not more than 1 tour per vehicle.
  • AmmendingParams: Inputplan required, creates no new tours
    Amending tour planning attributes. The use case described by this class executes the tour optimization by amending existing tours with the given orders. Therefore an input plan with at least one tour should be provided.

    Use this subclass if you have at least one given input chain and you do not want to create new tours but simply add unscheduled orders to existing tours without moving scheduled orders to other tours. This is meaningful e.g. if you already prepared the loading process of the next days transports and you want to add new incoming orders to the given vehicles without a completely new tour planning.
    Faster but alsoless flexible than standard planning from scratch. Useful if your level of manipulation is rather low.
  • AreaParams: Inputplan not required, creates new tours
    Extends the class PlanningParams with area tour planning attributes. The use case described by this class executes the tour optimization and considers at the same time all area attributes of transport orders, vehicles and tours.

    Less flexible planning scenario used for pre-combined trips: Major requirement of this scenario is to ensure that all orders with the same AREA ID are scheduled on the same tour (usually considering the AreaNumberPosition). But it is also possible possible to allow several tours into the same area (which causes the server to ignore the AreaNumberPosition). Orders without an AreaId can be assigned to any vehicle/tour. Useful if you have fixed tours (incl. sequences) but the vehicle is not determined so far.
    Another important constraint: orders with different AreaIDs are not allowed on the same tour. In other words: each tour is based on a specific AreaID and only accepts orders with that ID or with an empty AreaID. If a single tour is not able to handle the complete Area (due to capacities or max number of stops within a tour) there might be several tours dealing with that Area depending on allowMultipleToursPerArea flag. If that flag is disabled but one tour isn't sufficient some orders remain unscheduled.
  • VehicleSchedulingParams: Inputplan required, doesn't create new tours but could concatenate existing tours to larger chain.
    Truck scheduling attributes. The use case described by this class executes a cost based vehicle scheduling based on an existing input tour.

    Use this subclass if the structure of your chains is already fixed: tour stop sequences should remain in he given sorting order. The optimization potential of this subclass is the consideration of the vehicles Cost vectors: While any other optimization function simply applies the cost vector after the planning steps themselves the VehicleScheduling does no longer optimize tours but determine which vehicles produce lowest costs when assigned to the given tours.
    It is also possible that this approach concatenates given tours to a bigger chain. Considers the CostValues of the vehicles and performs the optimization based on these values (not the case wthin the other optimization classes)
  • OvernightParams: Inputplan not required, creates new tours
    Attributes for overnight tour planning.

    Use this subclass if your orders are already assigned to a specific vehicle and if you want to perform a single weeks calendar optimization of the drivers (Sales, Field Service, Nursing…). This subclass considers hotel costs and checks whether staying overnight outside the home address is cheaper than driving back home. It is an option to enfore the return on specific weekdays and you can also limit the number of overnight stays.
    Single tour only. Usefull if the standard parameters for toursMustFitIntoSingleInterval do not match your level of flexibility.

Then we have some evaluation classes which do not optimize things but just extend existing chains by some important info:

  • CalculationParams: Inputplan required, does not create new tours
    The use case described by this class calculates the tour attributes of the imported tours without changing the existing tours at all (for example to get an idea of the time profile or to check if a tour is violated or not). There is no optimization step executed.

    This class does not manipulate anything but requires a given input plan which is simply evaluated but not optimized. Use this class if you just want to determine the time scheme of your vehicles and orders and to find out whether your tours are valid or create VIOLATIONS of the given constraints. Unscheduled orders remain unscheduled. No new tours will be generated.
  • UnscheduledOrderAnalysisParams: Inputplan required, does not create new tours
    Additional attributes for analyzing unscheduled orders. The attribute unscheduledOrderIdsToBeAnalyzed must contain a subset of the input plan's unscheduledOrderIds. These orders will be analyzed and the result is returned in PlanResult as an array of UnscheduledOrderAnalysisResult.

    Same as with Calculation but in addition to that this class triggers the deeper analysis of unscheduled orders and tells you why orders can't be scheduled. Use this class if you need to support your dispatcher in the "why does this order remain unscheduled?" story. Possible reasons could be "no vehicle has sufficient equipment", "no vehicle has sufficient operating intervals" but also causes that are not 100% related to the order (e.g. "too many orders to be fullfilled in the given time"). Once you know the cause for unscheduled orders you are enabled to decide about countermeasures (add another vehicle, shift timeframes...)

And finally there are 4 proposal methods that enable you to find proper matches out of several potential alternatives.
What they have in common is that they usually deal with a limited scope of manipulations but they gain speed in the calculation performance.
This is why they are dedicated for callcenter usecases where an agent needs several options within a few seconds.


  • findToursForUnscheduledOrder: Inputplan required
    Finds the best matching tours for an unscheduled transport order. The method generates a number of scenarios to support order insertion decisions on client side. All necessary objects (transport orders including the unscheduled one, depots, vehicles, tours) are imported in this method. As a result of the method a list of possible insertion proposals ordered by costs is exported.

    Identifies those tours out of a set of tours that can handle an order that is unscheduled so far.
    The agent can offer the cheapest alternative as first approach and escalate through the variants.
    The target for the orders client is always achieved - the goal is to have the least cost impact for the agent.
    Compared to planBasicTours: returns several tours as candidates while planBasicTours already decided where to add the order.
  • findUnscheduledOrdersForTour: Inputplan required
    Finds the best matching unscheduled transport orders for a specific tour. The method generates a number of scenarios to support order insertion decisions on client side. All necessary objects (transport orders, depots, vehicles, tours including the specific one) are imported in this method. As a result of the method a list of possible insertion proposals ordered by costs is exported.

    Used if the workload of a single tour is not high enough and the driver has some "space" for other orders.
    Almost equal to planBasicTours with just one tour and several unscheduled orders. Benefit of planBasicTours is that it might add several of the uscheduled ones at a time (better quality).
  • findVehiclesForTour: Inputplan required
    Finds the best matching vehicles for a specific tour. The method generates a number of scenarios to support vehicle assignment decisions on client side. All necessary objects (transport orders, depots, vehicles, tours including the specific one) are imported in this method. As a result of the method a list of possible assignment proposals ordered by costs is exported.

    If a tour is already prepared but the resource can be negotiated among several trucks or drivers.
  • findToursForVehicle: Inputplan required
    Finds the best matching tours for a specific vehicle. The method generates a number of scenarios to support vehicle assignment decisions on client side. All necessary objects (transport orders, depots, vehicles including the specific one, tours) are imported in this method. As a result of the method a list of possible assignment proposals ordered by costs is exported.

    Used if a vehicle is unused and should get a proper workload.
Last edited by Bernd Welter on Mon Feb 19, 2018 9:27 am, edited 6 times in total.
Reason: Some more comments about area planning
Bernd Welter
Manager Technical Consulting & Requirement Engineering
Senior Technical Consultant Developer Components
PTV GROUP - Germany

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

Return to PTV xTourServer

cron