Sample usecase: Multi Depot Planning

[Bernd Welter]

Cheers,

as you might have seenthe xTour2 API offers a specific planning case which is base on the order types
com.ptvgroup.xserver.xtour.OrderWithAlternativeDeliveryDepots and com.ptvgroup.xserver.xtour.OrderWithAlternativePickupDepots. Just want to show you the potential of these approaches based on a client I wrote for a potential project. The locations (depots and orders) are ficticious.

The most important feature in this example is that the engine decides about the assignment of vehicles (depots) to the orders.

Here's the setup:

A set of depots and vehicles located somewhere in the "overall region" where you are dealing with. In this example there's just one vehicle per depot but the engine can also handle several vehicles per depot. At the beginning of the planning horizon the vehicles position is defined. The end position of a vehicle can also be defined (roundtrip or even a specific alternative depot) but you can also expect the engine to determine the best position for you (last customer location)

Within that region there's a bunch of locations where you'd like to pickup or deliver a certain amount of goods. As usual these activities have to be fulfilled under cerrtain constraints: time windows, required skills, quantities...

The story takes place on a single day planning horizon. I also deal with quantities and some constraints such as maximum driving time but there are no explizit time windows given. Skills/equipment aren't used in this example but they are available through the API.

And here are some results - depending on some settings that are parametrized through the test client:
Long story short: from scratch each order can be handeled by each vehicle and from each depot.

Usually the number of tours is supposed to be minimized, even if this leads to additional distance contributions. By comparing the KPIs with the other results you can recognize the impact of that scenario. Here we produce a total distance of 1100 km which are based on 5 different tours (which means we utilize only 50% of the trucks). Keeping the number of tours as small as possible is a quite usual case.

With this setting the target function is now to minimize the KPIs such as distance and travel period. By utilizing 8 instead of 5 vehicles the overall distance is reduced from 1100km to just 925 km.

In both of the samples above the tours ended at the last customer (determined by the engine). The user story is also based on "at the end of the day a vehicle should join the nearest depot whih is not necessarily it's start depot". I simply determined the "closest final destination" based on airline. Attention: this is business logic and not part of the optimum!

Now the next screenshots deal with closed tours (rountrips):

Here I enforce the drivers to return back to the depot. As this is an additional constraint the KPIs grow again: 8 tours required (1100 kilometers)

And finally I tell the engine to produce as few as possible closed tours. Worst result: 1275 kilometers within 6 tours.

Here's another sample - I reduced the vehicle's capa which then requires to drive with all the available reccources which are not even sufficient.

The next two scenarios compare the pre-assignment of each orders closest depot which reduces the optimization potential and increases the overall distance.

biggest potential: each depot is able to server each order

Here I applied some business logic: each order has been pre-assigned the nearest depot within it's proximity, not taking care of other orders near by. This reduces the overall flexibility and returns 1075 kilometers (additional 40).

Best regards,
Bernd

PS: the distance calculation was based on airline - of course we can also handle this via routing / distance matrix.

[Bernd Welter]

Update : here's also a sample where the number of vehicles per depot varies:

"Size of truck" indicates capacity at a specific depot
"Size of order" indicates order capacity

Most orders are handeled by the large depot in the center