Distinction between planning scenarios (xTour 1)
Posted: 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.
Let's start with the pure optimization classes - as they are the most interesting ones:
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.
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.
- 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
- StandardParams: Inputplan optional, creates new tours
Use this subclass if you want to perform an optimization where the goal is to reduce a planning goal such asStandard tour planning attributes. The use case described by this class
executes the standard tour optimization without unusual goals or constraints.- as few unscheduled orders as possible
- use as few ressources as possible
- short tours
- Tour end as early as possible
- Tour start as late as possible
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
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.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. - AmmendingParams: Inputplan required, creates no new tours
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.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.
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
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.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.
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.
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.Truck scheduling attributes. The use case described by this class executes a cost based vehicle scheduling based on an existing input tour.
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
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.Attributes for overnight tour planning.
Single tour only. Usefull if the standard parameters for toursMustFitIntoSingleInterval do not match your level of flexibility.
- CalculationParams: Inputplan required, does not create new tours
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.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. - UnscheduledOrderAnalysisParams: Inputplan required, does not create new tours
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...). Check this post to get more details about unscheduled orders.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.
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
Identifies those tours out of a set of tours that can handle an order that is unscheduled so far.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.
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
Used if the workload of a single tour is not high enough and the driver has some "space" for other orders.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.
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
If a tour is already prepared but the resource can be negotiated among several trucks or drivers.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. - findToursForVehicle: Inputplan required
Used if a vehicle is unused and should get a proper workload.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.