Balanced loading

How it works
1. Specifics

The main priority of route planning is often to get a relatively uniform distribution of orders across vehicles or couriers.

To achieve this, RouteQ has an option for balanced loading: balanced_groups.

How it works

Balanced loading can be based on one or more parameters at the same time:

custom_value: Based on the sum of the orders' custom unit values.
hour: Based on the route time.
km: Based on mileage kilometers.
served_order: Based on the number of orders handled.
stop: Based on the number of stops.
unit: Based on the number of units.
weight_kg: Based on the total weight of orders (in kg).

The balanced group is a property of the vehicle's shift: the ID of the balanced group is set in the vehicles.shifts.balanced_group_id field. The balanced loading option works independently in each group.

The balancing parameters are set in the options.balanced_groups field. The parameters include:

Group ID (also used in the vehicles.shifts.balanced_group_id field).
Amount of penalties for route imbalance relative to each other. Note that these parameters have default values.

The solution building process only includes the balancing specified during planning.

Tip.

For large penalty values, use sequence post-optimization.

Specifics

We recommend that you balance vehicles that originally have similar conditions. This may apply to various task parameters: duration and window of vehicle shift, order density per specific group of vehicles, load capacity, tags, etc. For cars with different conditions, we recommend that you create different balancing groups. For example:

Vehicles might have different shift durations: for some vehicles, it is 8 hours, for other vehicles, it is 6 hours. You may need to balance such vehicles separately, because their route times will differ, and they will be able to complete different numbers of orders.
Couriers work morning and evening shifts (of the same duration) and are routed within the same request. Let's assume that the number of orders in the morning and evening shifts is unevenly distributed. Then you either need to separately balance between the morning and evening couriers, or only balance them by route time, because the average number of orders (and, accordingly, stops on the route), would most likely be different for the morning and evening shifts.
The same vehicles are used, but there are many orders in the city and a few orders in the surrounding area in different directions. You can only balance such a task by route time. This is because the vehicles that drive a long distance will, most likely, complete fewer orders.
Vehicles of different load capacity are used. They usually complete a different number of orders. That's why you need to either set different balanced groups for different load capacities, or balance the vehicles by route time only (the second option is preferable).

Note.

When you use balanced groups, it usually results in less optimal routes in terms of general solution metrics (by “Total mileage”/“Total route time”), and sometimes also by the number of vehicles involved. If you increase the penalties for unbalanced distribution, you get a more uniform solution achieved at the expense of optimal routes.

The balanced loading option helps you to balance routes inside a specific planning. If your task is to balance the load on your resources over an extended period of time (for example, a month), you need to implement it outside RouteQ in a separate process. In this process, couriers are assigned to routes based on the accumulated value you balance the solution against. For example, let couriers accumulate a total number of working hours. After the routes are planned for a given day, the courier who has the minimum accumulated value (of the total working hours) is assigned the longest route, and vice versa. Therefore, this balancing will be achieved not for a specific day, but over a period of time. However, on a given day, the routes might still be optimal, even if they are unevenly distributed.

Example 1

The task includes 52 orders and 3 couriers. Solve the task without balancing.

Planning result:


Courier	Number of stops in the route	Mileage, km	Route time
Courier 1	19	50	10:49
Courier 2	17	47.4	09:50
Courier 3	16	35.8	09:04
Total	52	133.1	29:43

API request (JSON) ⋅ API response ⋅ View on map

Example 2

The same task as in example 1, but with the following additions:

Enable the balanced group option.
Create one balanced group.
Use the default penalties for unbalanced routes.

Planning result:


Courier	Number of stops in the route	Mileage, km	Route time
Courier 1	17	54.1	09:56
Courier 2	17	41.9	09:48
Courier 3	18	48.7	10:05
Total	52	144.7	29:49

Routes are now more balanced relative to the indicator “Number of stops on the route”/“Route time”, but the overall metrics of the solution (“Total mileage”/“Total route time”) have degraded compared to example 1.

API request (JSON) ⋅ API response ⋅ View on map

Example 3

The same task as in example 1, but with the following additions:

Enable the balanced group option.
Balance the routes by the route time only.
Increase the penalties for unbalanced routes relative to default.

Planning result:


Courier	Number of stops in the route	Mileage, km	Route time
Courier 1	17	47.5	10:09
Courier 2	18	50	10:09
Courier 3	17	52.5	10:09
Total	52	150	30:27

Now the couriers work the same hours, but the overall solution metrics have degraded even more. This is because the algorithm with increased penalties for unbalanced routes tries to find a solution that would be more balanced than optimal.

API request (JSON) ⋅ API response ⋅ View on map

Contact support