Skip to main content

Dynamic Service Time

In logistics, the time it takes to service an order at a drop-off location (like a warehouse or distribution center) is often not a fixed number. It can vary based on the size, weight, or type of goods being delivered. Dynamic Service Time is a feature that allows the optimization engine to calculate the service time for an order based on these variable factors, rather than using a single static value.

This creates a more realistic and accurate operational plan, as the time allocated for each stop reflects the actual work required.

Implementation of the fixed service time is explained in compound zones document.

Purpose​

The primary purpose of dynamic service time is to move beyond simple, fixed-time estimates (e.g., "all deliveries take 5 minutes") and create a more nuanced model. By calculating service time based on the order's specific demand, you can:

  • Improve Planning Accuracy: Routes and schedules become more reliable because they account for the actual time needed at each stop.
  • Optimize Vehicle Utilization: The optimizer can make better decisions about how many orders a vehicle can realistically handle in a day.
  • Model Complex Operations: It allows for modeling scenarios where different product types or quantities have different handling requirements at a warehouse or depot.

How It Works: The Calculation​

Dynamic service time is calculated by combining a fixed base time with variable components derived from the order's demand. The formula is:

Total Service Time = Fixed Time + (Demand Type 1 * Coefficient 1) + (Demand Type 2 * Coefficient 2) + ...

For example, you can define that the service time is a combination of a fixed time for paperwork plus a variable time based on the total volume (cbcm) and weight of the delivery.

Implementation in API​

This feature is implemented through the Integration API by configuring the calculation_params on an Operations Location or an Operations Location Group.

info

This feature is only available through the stateful Integration API and is not supported in the Stateless API, as it relies on pre-configured OperationsLocation data.

You define the service time rules within the calculation_params object. The key parameters are:

  • service_time.fixed: A base service time (in seconds) that applies to every order at that location.
  • coefficients: An object that maps a product_kind to the coefficients for different demand types.

Example​

Let's say you configure an OperationsLocation with the following calculation_params:

"calculation_params": {
  "service_time": { "fixed": 300 },
  "coefficients": {
    "AMBIENT": {
      "cbcm": 0.000018,
      "weight": 0.01
    }
  }
}

Now, a booking is created that uses this Operations Location for its drop-off. The booking has the following properties:

  • product_kind: "AMBIENT"
  • demand: { "cbcm": 500000, "weight": 100 }

When this booking is processed, the optimizer will calculate the service time for its drop-off node as follows:

Total Service Time = fixed + (cbcm * coefficient) + (weight * coefficient) Total Service Time = 300 + (500000 * 0.000018) + (100 * 0.01) Total Service Time = 300 + 9 + 1 = 310 seconds

The solver will then use this calculated 310-second service time for the drop-off node in its route planning, leading to a more accurate and feasible schedule.