Vehicle slack
In the context of a Vehicle Routing Problem (VRP), slack (also commonly called waiting time) is the unproductive idle time that a vehicle and driver must spend at a stop.
This waiting time is created when a vehicle arrives at a location before the location's service time window opens.
Where Slack Occurs: A Concrete Example
Imagine a vehicle has a delivery for "Customer B," whose time window is 9:00 AM – 11:00 AM.
- Vehicle Arrives: 8:40 AM
- Earliest Service Time: 9:00 AM (the start of the time window)
- Service Begins: 9:00 AM
- Resulting Slack: The 20 minutes between 8:40 AM (arrival) and 9:00 AM (service start) is slack. The driver must wait.
Purpose: Why Slack is a Key Metric
Slack is a critical component of the total solution cost. An idle vehicle and driver represent a real-world cost to the business (driver wages, vehicle non-utilization).
The optimizer's goal is not just to minimize travel time but to minimize total cost. By assigning a cost to slack, you tell the optimizer to value the driver's time and find a solution that is not just route-efficient but also operationally efficient.
How the Optimizer Treats Slack: The Cost Trade-Off
The optimizer does not see slack as "free" time. You configure the system with an artificial cost for waiting (e.g., a cost of 10 units per minute of slack). This cost is factored into the total solution cost.
Total Solution Cost = Travel Cost + Vehicle Cost + Penalty Costs + Slack Cost
The optimizer will now make intelligent trade-offs. It will only allow slack if that option is cheaper than any other alternative.
Example Trade-Off:
The optimizer is evaluating two possible routes to service Stop A and Stop B:
-
Option 1: Incur Slack
- Route: Stop A -> Stop B
- Travel Time: 30 minutes
- Wait Time: 25 minutes of slack at Stop B.
- Total Cost:
Cost(30m Travel)+Cost(25m Slack)
-
Option 2: Avoid Slack
- Route: Stop A -> (long, indirect route) -> Stop B
- Travel Time: 60 minutes (The driver "kills time" on the road to arrive at Stop B exactly on time).
- Wait Time: 0 minutes of slack.
- Total Cost:
Cost(60m Travel)
Result: The optimizer will choose Option 1 if the Cost(25m Slack) is less than the cost of the extra 30m Travel in Option 2. It correctly identifies that it's cheaper to wait at the stop than to waste fuel and time on a longer route.
Key Principle: Configuring Wait Cost
The wait cost (cost per minute/hour of slack) is a powerful tuning parameter:
- Setting a HIGH Wait Cost: Tells the optimizer, "Driver/vehicle time is extremely valuable. Avoid waiting at all costs. I would rather the vehicle take a longer route or even use a different vehicle to prevent slack."
- Setting a LOW (or ZERO) Wait Cost: Tells the optimizer, "Waiting is free. I don't care how long drivers are idle, as long as you minimize travel distance and the number of vehicles used."
Balancing this cost is key to producing routes that are both efficient on paper and practical in the real world.
Imposing a strict maximum slack limit will reduce the number of accepted solutions, which can result in solver being unable to find an initial solution that satisfies the constraints and an increase in rejected bookings.
Optimizing slack as a tradeoff with other costs
In the Stateless API, you can configure the optimizer to treat slack time as a cost. This is achieved through a new local search implementation that allows for slack minimization while also supporting driver breaks. This encourages the creation of routes that are not only short in distance but also operationally efficient by minimizing idle time for drivers, leading to better working hours and more feasible plans.
To enable slack optimization, you need to configure the following parameters in your request payload:
- Enable Logistics Mode: Set
model_parameters.path_constraints_modeto"logistics". This mode enables the slack costing feature. - Activate Slack Optimization per Vehicle: For each vehicle where you want to minimize slack, set
logistics_optimize_slacktotrue. - Set Slack Cost (Optional): You can tune the "cost" of slack using
model_parameters.slack_cost_factor. This is a coefficient for slack time in the objective function. A higher value will make the optimizer work harder to reduce slack, potentially at the expense of longer travel distances. The default value is10, and a typical range is0.1to1000.
The trip_cost parameter is not compatible with the logistics path constraint mode and will not work when it is enabled.
Example Configuration
This configuration works only with selected SWAT solvers and is not available by default.
Here is a JSON snippet showing how to set up these parameters in a node_scheduler request. In this example, the vehicle with agent ID dc1e... will have its slack time minimized.
{
"engine_settings": {
"model_parameters": {
"path_constraints_mode": "logistics",
"slack_cost_factor": 10
},
"calculation_parameters": {
"scheduling_mode": "prebook_cvrptw"
}
// ... other settings
},
"vehicles": [
{
"agent_id": "dc1e0000-2024-0731-aaaa-5206f1c21d09",
"logistics_optimize_slack": true
// ... other vehicle properties
}
]
// ... other request properties
}
Playground
You can try out the Vehicle Slack concept using the playground below. You can try out the Vehicle Slack concept using the playground below. In this example, the vehicle performs a series of pickups and drop-offs. The drop-off time windows are spaced out such that the vehicle is forced to wait (incur slack) between some of the stops, demonstrating how time window constraints can lead to unavoidable idle time.
