Vehicle Level Constraints

Constraints that operate at the vehicle level allow one to control properties of the solution that apply to the individual vehicles. In cases where there is only one shift per vehicle these are equivalent to constraints at the route level as there is exactly one route per vehicle. However for multi-day, multi-vehicle problems one may wish to control properties of all the routes associated with a particular vehicle.

Vehicle Balance — vehicle_balance

Description

Very similar to the route_balance constraint, this constraint allows us to provide a min and max value for a metric that is summed across all the routes associated with the vehicles specified. If a list is provided for vehicle_ids then the constraint is only applied to the specified vehicles. Otherwise the constraint applies to all vehicles. When specifying the constraint, values for metric_id, min_metric_value, and max_metric_value must be given, and the metrics are summed across all orders in the routes for the specified vehicle(s).

Example

TODO: [MARE-1027] Complete vehicle balance example

Work Speed — work_speed

Description

There are some cases where the duration of an order depends on who is servicing it. For example, a particular technician may be able to complete a repair much faster than his/her colleagues. This variability can be expressed by using the work_speed parameter as a property of the shift. Since a vehicle can have multiple shifts, the work_speed parameter can be tied to the operator of the vehicle instead of the vehicle itself.

Example

In the example below, we illustrate a simple request where a manager explores the impact of "What if all my employees could work faster?" This can be achieved by trying different values of work_speed as shown below in the example vehicles array where a work_speed of 0.5 indicates that these workers are twice as fast as the default case.

 "vehicles": [
    {
      "vehicle_id": "Vehicle1",
      "shifts": [
        {
          "work_speed": 0.5,
          "shift_end": "2017-08-24T17:10:00-04:00",
          "start_location_id": "loc20",
          "shift_start": "2017-08-24T08:05:00-04:00",
          "shift_id": "v1shift",
          "end_location_id": "loc20",
          "break_start": [
            "2017-08-24T12:00:00-04:00"
          ],
          "break_end": [
            "2017-08-24T13:00:00-04:00"
          ]
        }
      ]
    },
    {
      "vehicle_id": "Vehicle2",
      "shifts": [
        {
          "work_speed": 0.5,
          "shift_end": "2017-08-24T15:10:00-04:00",
          "start_location_id": "loc99",
          "shift_start": "2017-08-24T10:05:00-04:00",
          "shift_id": "v2shift",
          "end_location_id": "loc99",
          "break_start": [
            "2017-08-24T12:00:00-04:00"
          ],
          "break_end": [
            "2017-08-24T13:00:00-04:00"
          ]
        }
      ]
    }
  ]

This experiment shows the manager that 5 more orders can be completed in this day if the workers are twice as fast since the 0.5 work_speed solution allows 22 order to be completed as opposed to 17 in the default case. The first image below shows the default work_speed 1 case and the second shows how additional orders are satisfied when workers are twice as fast.

imgA solution with work_speed = 1.0

imgA solution with work_speed = 0.5