Breaks

The optimization engine offers a wide variety of methods to express breaks in a route – these are periods during a shift which the vehicle/driver is not servicing any orders. The breaks are properties of the shift so that in problems where a vehicle has multiple shifts, different breaks can exist for the same vehicle across the different shifts. There are three types of breaks supported

BREAK — A period of time during which the vehicle is not moving and no orders are serviced. This type of break is useful to express events such as a lunch break at a known time. For the standard break, the start and end time are explicitly expressed, and the break is always honored. A shift can have multiple breaks but the breaks cannot overlap (since two overlapping breaks really just represent a single longer break).
SOFT BREAK — A period of time during which no orders are serviced, but the vehicle may or may not be moving. This type of break is useful to express events such as a pre-scheduled phone call that might take place while the vehicle is moving. For the soft break, the start and end time are explicitly expressed, and the soft break is always honored. A shift can have multiple soft breaks but the soft breaks cannot overlap (since two overlapping soft breaks really just represent a single longer soft break). A shift can have a mixture of breaks and soft breaks, but they cannot overlap.
FLOATING BREAK — The floating break has a fixed duration but can start at any time during a provided window. The vehicle is not allowed to be moving during a floating break. The floating break can be used to handle compliance requirements where a driver must receive a certain amount of rest during any continuous work period of a certain length. As with the other breaks, any route for the shift will always honor the floating break. Floating breaks can be used in conjunction with the other break types.

In the following three examples, we have a single vehicle with 6 total orders in the Washington, DC/Baltimore area. In each case, we have a different kind of 45-minute break that impacts the efficiency of the shift.

Hard Break

In this first example, we have a hard break from 12:30 to 1:15. As the vehicle cannot be traveling during this period, it turns out that it is not possible to visit all 6 orders in this case and the Baltimore order is not visited. The route ends at 3:22, and there are more than 2 hours of time remaining in the shift. However, that does not provide sufficient time to complete a round trip to Baltimore to service the final order.

Expand to view request sample

With a hard break of 45 minutes starting at 12:30, it is not possible to visit all 6 orders.

Soft Break

In a soft break, recall that the vehicle is allowed to be moving during the break. This additional level of flexibility allows us to now visit all 6 orders as the soft break is taken after servicing the Baltimore order and returning to DC. The route concludes with about 40 minutes to spare before the end of the shift.

Expand to view request sample

The soft break is taken on the way back down to DC after the Baltimore order (stop 3 in the route).

Floating Break

The floating break allows us an additional degree of flexibility as we are now allowed to take the 45-minute break at any time during the day. Even though the break is similar to a hard break in that the vehicle cannot be moving, the freedom to scheduled this break any time during the shift allows sufficient freedom that we are now able to visit all 6 orders. The floating break occurs immediately after the final order at the Vietnam Memorial, and we complete the route with less than 2 minutes to spare in the shift.

Expand to view request sample

The floating break allows us to visit all 6 orders even though the vehicle does not move during the break. Note that we traverse the orders in a slightly different sequence than with the soft break. With the optimization engine’s ability to incorporate predicted traffic into the route optimization, the floating break can be a powerful way to add some additional flexibility into the route.

Delivery Only Problem with Replenishment and Balanced Routes

In this example, we have a fictitious company that delivers various sizes of pallets to customer locations. The fleet is not large enough to carry all the pallets for the day in a single load, so the vehicles can return to various locations throughout the day to replenish their supply of pallets. The three types of pallets to be delivered are described in the items array below

The vehicles are constrained in terms of how much of each item they can carry as well as by volume and weight. Each vehicle’s capacity is expressed separately as part of the vehicle object, and an example vehicle object now looks like this. Note that we are specifying the "type": "truck" so that the paths over the street network between stops are compliant with the dimensions of the truck.

As in other delivery problems, we express the amount to be delivered to each order with delivery_item_quantities . In problems involving deliveries, the vehicle may become empty during the shift and be therefore unable to service any more orders. By specifying certain orders to have the ability to replenish the supply, we can extend the shift since the vehicle can refill an amount so that more orders can be serviced. An example of such a replenishment order is below. Note that the amount that can be replenished must be set – typically this should be a very large value if essentially limitless replenishment can occur at this stop. If the replenishment stop has a limited supply of items, then that can be specified as well, and the total amount of supply added to the vehicles at this stop will not exceed the amount specified. Additionally, a duration is specified for the replenishment, and a maximum number of visits (enforced by the visit_range constraint)

A full request involving deliveries, replenishment events, and a num_stops constraint to balance the routes is given below.

Expand to view request sample

All replenishments occur at the central depot (boxed in red). In the purple route, the vehicle visits stop 1 and stop 2, replenishes in stop 3, then services stops 4, 5, and 6 in the western portion and returns to replenish in stop 7. The route concludes by servicing stops 8 and 9 south of the depot before returning home. The output JSON contains the full details of the stops and specifies when the replenishments occur.

In the routes returned in the API response, any stop where items are delivered will have details of what is delivered, and how much of each item is in the vehicle at that time. An example is below:

For every replenishment stop, an items_replenished array is included to describe the activity at the stop.

As with unloading problems, other features of the pickup/delivery aspects of the route are also included in the route object, such as max_volume_in_vehicle , max_num_items_in_vehicle , and max_weight_in_vehicle . Since vehicle capacity constraints are never violated, the optimization engine ensures that no vehicle will ever be carrying more than its capacity at any point during the route (in terms of weight/volume/number of items). The replenishment stops are strategically inserted by the algorithm in order to satisfy as many orders as possible while still respecting the vehicle capacities.

Welcome to Knowledge Base!

KB at your finger tips

CRM-Salesforce

Salesforce Developers

Weekday Traffic

Salesforce Developers

Routing Optimization

Basics

Constraints

Salesforce Developers

Breaks

Hard Break

Soft Break

Floating Break

Salesforce Developers

Delivery Only Problem with Replenishment and Balanced Routes

Salesforce Developers

Forced Routes

Salesforce Developers

Multiple Vehicles, Multiple Shifts

Thank you for subscribing to AiDOOS! Stay connected for updates!