IVR WindowWindow
Overview
A window defines a feasible interval on a dimension, with a start and an end. Windows are created in attributes which are in turn linked to a dimension and task or location. This allows us to specify what the feasible windows are on a particular dimension for an activity. Windows are added to the attributes of either a task, location or vehicle shift.
Applicable models
- IVR7
ivr7-kt461v8eoaif
- IVR8
ivr8-yni1c9k2swof
Window
The Window
defines a constraint which restricts the feasible values that may occur on a dimension.
Schema definition
message Window {
required float start = 1;
required float end = 2;
optional float slackCostCoef = 3 [default = 0];
optional float tardyCostCoef = 4 [default = 0];
optional float slackMax = 5 [default = -1];
optional float tardyMax = 6 [default = -1];
}
Fields
- start
- The starting value of the window.
- end
- The end value of the window.
- slackCostCoef
- The coefficient describing the cost per unit of slack.
- tardyCostCoef
- The coefficient describing the cost per unit of tardiness.
- slackMax
- The maximum slack quantity that may be incurred for this window. If specified, it will override the inherited value from the dimension. The slack is used to allow for activities to have a feasible arrival. In the context of time windows (i.e. windows on the time dimension), this corresponds to allowing for an early arrival at a location, where the amount of slack required (for feasibility) is the waiting time incurred for the window to permit the activity. The value -1 is reserved for the default to indicate that the window should not override the inherited value from the dimension.
- tardyMax
- The maximum tardy quantity that may be incurred for this window. If specified, it will override the inherited value from the dimension. In the context of time windows, a positive tardy value allows for soft time windows, where the tardyCoef corresponds to the cost of a unit of lateness on a particular window. It is typical to have a higher cost for lateness than the normal dimensional cost. In the context of capacity dimensions, a non-zero tardyMax indicates that a certain amount of overloading is permitted on the dimension (at a cost specified by the tardyCoef). The value -1 is reserved for the default to indicate that the window should not override the inherited value from the dimension.
Examples
A window used in an attribute on the time dimension (measured in minutes) restricting the arrival time to between 06:00 and 18:00.
start: 360
end: 1080
A window used in an attribute on the time dimension (measured in minutes) restricting the delivery time at a customer to between 14:00 and 15:00 where a vehicle may arrive no earlier than 13:30 (30 minutes of slack) and no later than 17:00 (120 minutes of tardiness). A tardy arrival by the vehicle will come at a cost of 2 units per minute of tardiness.
start: 840
end: 900
slackCostCoef: 0.1
tardyCostCoef: 2
slackMax: 30
tardyMax: 120
Another example is a window used in an attribute on the weight dimension (measured in kilograms) restricting the weight currently loaded on a vehicle when arriving at a particular customer to be less than two tonnes. This is often due to special features of the location where vehicles that are heavily laden may damage equipment at the location. It may also be related to the road-conditions entering the site.
start: 0
end: 2000
Notes
- Windows may be used in multiple contexts. Not only dimensional contexts, but also in the context of arrival or departure.
- Windows are very powerful modelling tools, but can also create problems where finding a feasible way to navigate all the specified windows may not be possible. It can help to have slack and tardiness in your window settings to help identify infeasible schedules (if the infeasibility info is inadequate)
- Multiple windows are permitted in many of the attributes. In cases where windows overlap, the union of the windows is used where the slack and tardy specifications of the first window (ordered by start) are used for the representative window. If this is not the behaviour you were hoping for, please create disjoint (i.e. non-overlapping) windows.
- Each node-visit in the vehicle router will target exactly one window per node in the solution (if windows are specified). This will always be the closest window (by dimensional quantity) for the designated task, location or shift. The optimiser will not introduce more slack/tardiness than the minimum amount required to be feasible with the designated window. This is the preferred behaviour for most routing situations. Having additional slack introduced to “skip” a window to make use of a cheaper
slackCostCoef
on an alternate window on the same node typically points to the incorrect configuration of the window parameters. Likewise, having lateness used to execute on an earlier window when no slack is available on a successive window is also undesireable.