Meaning of an input plan... (xTour 1)
Posted: Mon Nov 25, 2019 10:56 am
Here's a generic article about the meaning of an input plan.
xTour 1: You know the signature of the planBasicTours method :In xTour2.planTours it looks like this:
So the Plan class is used twice in such a call:
- as an optional input parameter
- as part of the result object
The meaning of the result object is quite simple: it tells you
OutputPlan:
So why should you use a Plan object in the context of an input plan?
Use a plan object if you created it through a previous function call and you want to add some more orders to the plan. Here are the most important plan properties that control the constraints:
Here's some example taken from a field service scenario:
Imagine you created a first plan with the following structure - 100% valid:
Also good to know:
A vehicle which is part of a request belongs to exactly one of these categories:
Get back to me if needed!
Bernd
xTour 1: You know the signature of the planBasicTours method :
Code: Select all
Plan planBasicTours(
TransportOrder[] transportOrders,
Depot[] depots,
Fleet fleet,
PlanningParams planningParams,
Plan inputPlan)
Code: Select all
Location[] locations,
Order[] orders,
Fleet fleet,
InputPlan inputPlan,
PlanToursOptions planTourOptions,
DistanceMode distanceMode,
Boolean storeRequest
- as an optional input parameter
- as part of the result object
The meaning of the result object is quite simple: it tells you
- which order is handeled by which vehicle
- what is the sequence of the stops, the arrival / departure times
- which orders are not scheduled (and why)
- some KPIs such as total distances, total driving times
InputPlan:The tour planning by means of chains, tours and tour points. It is used both for the import of the existing tours and for the export of the planned tours. The tour optimization only plans valid tours. A tour is valid if there are no violations of the considered constraints. An invalid tour is not considered at all. All attributes are relevant for the input plan except for result. An input plan must always contain at least one tour point.
Chains: The tour chains of the vehicles performing at least one tour (required). There is one element in the list for every used vehicle.
PlanResult: The overview of the planned tours in all tour chains. This attribute is not relevant for the import of the existing tours, but it appears in the export case to provide additional information.
If you do not provide an input plan at all this means all previous optimization info is "lost" and the next call will handle everything from scratch.A previously planned tour plan which is used to start the planning from (optional). Not all of the parameters will be used, see the description of the related elements. An input plan must always contain at least one tour point.
OutputPlan:
So while some of the properties of such a plan object are used by the engine to treat them as INPUT controlling the optimization constraints others are created by the engine to enrich the OUTPUT of such a plan.The results of the tour optimization including the planned tours and some additional information.
So why should you use a Plan object in the context of an input plan?
Use a plan object if you created it through a previous function call and you want to add some more orders to the plan. Here are the most important plan properties that control the constraints:
| Parameter | Meaning |
|---|---|
| Tour.tourPointFixation | The fixation of tour points during the tour optimization. |
| TourPoint.tourFixed | If true, the tour point is fixed. Otherwise the tour point can be changed to another tour during the tour optimization. This is only relevant in case of no fixation of the tour, otherwise the value true is set for all tour points of the tour. |
| TourPoint.remainPlanned | If true, the tour point must remain planned. Otherwise the tour point can be set unscheduled during the tour optimization. |
Imagine you created a first plan with the following structure - 100% valid:
- Vehicle 1 - Mr. Superman:
- Depot
- Customer SMITH from 09:00-10:00
- Customer WESSON from 10:30 - 12:00
- Depot
- Vehicle 2 - Mr. Batman:
- Depot
- Customer Tick
- Customer Trick
- Customer Track
- Depot
- Customer SMITH was told that he get's visited by Mr. Superman between 09:00 and 10:00. In a next call you want to make sure that this task is assigned to Mr. Superman: use the existing plan, set tourFixed=TRUE and remainPlanned=true
- Customer WESSON was told that he get's visited from 10:30 to 12:00 but without the name of the visitor: use the existing plan, set tourFixed=FALSE and remainPlanned=TRUE. This will ensure that the task is scheduled at all, at the proper time but if the overall optimization can be improved the task can be switched to Mr. Batman.
- - Mr Batman has prepared himswlf to visit his customers Trick, Trick and Track and he doesn't want them to be moved to Mr. Superman. You could either set "tourFixed=TRUE" for each order or you simply parametrize his Batman tour to "tourPointFixation=NO_TOUR_POINT_OUT"
Also good to know:
A vehicle which is part of a request belongs to exactly one of these categories:
- Scenario 1 : It is not referenced by the input plan (especially if there's no input plan at all
) : orders may be assigned to the vehicle, if there's an output chain it is not violated. - Scanario2 : It is referenced by the input plan
- 2a. the input chain of the vehicle is violated : no orders may be assigned to or removed from the vehicle - the output chain is equal to the input chain, returned with the violations. PS: a chain is violated if at least one tour of the chain is violated. As a consequence the valid tours of an invalid chain remain untouched.
- 2b. the input chain of the vehicle is not violated : orders may be assigned to or removed from it - if there's an output chain it is not violated.
Get back to me if needed!
Bernd