Ten przykład pokazuje, jak za pomocą atrybutów przejścia określać priorytety tras, na których te same pojazdy wykonują w jednym przedziale czasowym odbiory i dostawy w pobliżu. Więcej informacji o atrybutach przejścia znajdziesz w artykule Modelowanie logiki biznesowej za pomocą atrybutów przejścia.
W tym przykładzie:
- Dostawy przesyłek A, B i C znajdują się blisko siebie na tej samej drodze.
- Kolejne dostawy są dalej.
- Dostawy nie mają określonych godzin.
- Niezależnie od harmonogramu wizyt pojazd musi przejechać tę drogę 2 razy: rano w drodze z bazy i wieczorem w drodze powrotnej.
- Całkowita odległość i czas podróży na trasie są zawsze takie same, niezależnie od tego, kiedy zostaną wykonane dostawy A, B i C.

W tej sytuacji i w przypadku żądania, które używa tylko kosztu na godzinę i kosztu na kilometr, zoptymalizowana trasa może obejmować dostawy A i B rano, a dostawę C wieczorem. Koszt rozwiązania będzie taki sam jak w przypadku, gdy wszystkie 3 dostawy zostaną wykonane w tym samym czasie.
Koszt na kilometr z progiem
Aby pogrupować wizyty w pobliżu, musisz najpierw wybrać odległość progową. Jest to maksymalna odległość między 2 wizytami, które uważasz za bliskie. W tym przykładzie używamy progu 100 metrów, który odpowiada mniej więcej jednemu blokowi w obszarze miejskim. Możesz zwiększyć lub zmniejszyć próg, aby dopasować go do potrzeb firmy i preferencji kierowców.
Aby pogrupować wizyty w pobliżu w odległości do 100 metrów od siebie, ustaw wysoki koszt na pierwsze 100 metrów każdego przejścia i niższy koszt na każdy dodatkowy metr przejścia. Ponieważ pierwsze 100 metrów jest najdroższe, optymalizator uzyskuje największe oszczędności, korzystając z przejść krótszych niż próg 100 metrów, nawet jeśli oznacza to wydłużenie całej trasy.
Aby skonfigurować koszty, dodaj nowy wpis do
ShipmentModel.transition_attributes
z tymi właściwościami:
- Aby dopasować wszystkie możliwe przejścia, wybierz tag, który nie jest używany w modelu, np.
UNUSED_TAG. UstawTransitionAttributes.excluded_src_tagiTransitionAttributes.excluded_dst_tagna ten tag. - Skonfiguruj
TransitionAttributes.distance_limitz odległością progową i kosztami:- Ustaw
DistanceLimit.soft_max_metersna wybrany próg. - Ustaw
DistanceLimit.cost_per_kilometer_below_soft_maxna koszt na kilometr poniżej progu. - Ustaw
DistanceLimit.cost_per_kilometer_above_soft_maxna koszt na kilometr powyżej progu.
- Ustaw
{
"model": {
"transitionAttributes": [
{
"excluded_dst_tag": "UNUSED_TAG",
"excluded_src_tag": "UNUSED_TAG",
"distanceLimit": {
"softMaxMeters": 100,
"costPerKilometerBelowSoftMax": 50,
"costPerKilometerAboveSoftMax": 1,
}
}
]
}
}
Tagu #unused_tag# nie mogą używać żadne przesyłki ani pojazdy, aby dopasować wszystkie możliwe przejścia. Więcej informacji znajdziesz w artykule Jak dopasować wszystkie żądania wizyt.
Jak działa wysoki koszt poniżej progu
W tej sekcji pokazujemy, jak koszt poniżej i powyżej progu wpływa na łączny koszt różnych rozwiązań w przykładowym scenariuszu.
Rozwiązanie 1: wykonaj dostawy A i B w drodze do celu, a dostawę C w drodze powrotnej
W tym rozwiązaniu przesyłki są podzielone na 2 przejazdy tą drogą. Dwie z nich są dostarczane podczas pierwszego przejazdu, a pozostała – podczas drugiego. Jest 5 przejść:
| Przejście | Odległość | Poniżej progu | Powyżej progu | ||
|---|---|---|---|---|---|
| Odległość | Koszt | Odległość | Koszt | ||
| baza → A | 1000 m | 100 m | 5 | 900 m | 0,9 |
| A→B | 50 m | 50 m | 2,5 | 0 m | 0 |
| B → inne | 1030 m | 100 m | 5 | 930 m | 0,93 |
| inne → C | 1000 m | 100 m | 5 | 900 m | 0,9 |
| C → baza | 1080 m | 100 m | 5 | 980 m | 0,98 |
| Łącznie | 450 m | 22,5 | 3710 m | 3,71 | |
Łączny koszt jest obliczany jako suma 2 kosztów na kilometr:
- koszt na kilometr poniżej progu (50) pomnożony przez łączną odległość poniżej progu (450 m = 0,45 km),
- koszt na kilometr powyżej progu (1) pomnożony przez łączną odległość powyżej progu (3710 m = 3,71 km).
Łączny koszt wynosi zatem 0,45 * 50 + 3,71 * 1 = 22,5 + 3,71 = 26,21.
Rozwiązanie 2: wykonaj dostawy A, B i C w drodze do celu, a w drodze powrotnej nie zatrzymuj się
W tym rozwiązaniu, w przeciwieństwie do rozwiązania 1, wszystkie 3 przesyłki są dostarczane „w grupie” podczas jednego przejazdu. Podczas drugiego przejazdu pojazd nie zatrzymuje się w ogóle. Ponownie mamy 5 przejść, ale ich długość i skład są inne:
| Przejście | Odległość | Poniżej progu | Powyżej progu | ||
|---|---|---|---|---|---|
| Odległość | Koszt | Odległość | Koszt | ||
| baza → A | 1000 m | 100 m | 5 | 900 m | 0,9 |
| A→B | 50 m | 50 m | 2,5 | 0 m | 0 |
| B→C | 30 m | 30 m | 1,5 | 0 m | 0 |
| C → inne | 1000 m | 100 m | 5 | 900 m | 0,9 |
| inne → baza | 2080 m | 100 m | 5 | 1980 m | 1,98 |
| Łącznie | 380 m | 19 | 3780 m | 3,78 | |
Przy użyciu tych samych obliczeń co w rozwiązaniu 1 łączny koszt wynosi 0,38 * 50 + 3,78 * 1 = 19 + 3,78 = 22,78. Wykonanie wszystkich wizyt w jednym przedziale czasowym jest tańsze niż wykonanie ich w 2 grupach. Możesz wzmocnić ten efekt, zwiększając wartość
increasing
DistanceLimit.cost_per_kilometer_below_soft_max.
Dlaczego niski koszt na kilometr poniżej progu nie działa
Ponieważ chcesz preferować krótkie przejścia nad długimi, możesz ustawić wysoki koszt na kilometr w przypadku długich przejść i niski koszt na kilometr w przypadku krótkich przejść. Ma to jednak odwrotny skutek: ponieważ pierwsze 100 metrów przejścia jest najtańsze, optymalizator wykorzystuje te „tanie” metry w największym stopniu, preferując przejścia o długości zbliżonej do 100 metrów lub większej.
Ten efekt widać w 2 przykładowych rozwiązaniach. Jeśli zamienisz koszt na kilometr poniżej i powyżej progu, koszty trasy ulegną zmianie:
| Wysoki koszt powyżej progu | Wysoki koszt poniżej progu | |||
|---|---|---|---|---|
| Rozwiązanie 1 | Rozwiązanie 2 | Rozwiązanie 1 | Rozwiązanie 2 | |
| Kilometry poniżej progu | 0,45 | 0,38 | 0,45 | 0,38 |
| Koszt na kilometr poniżej progu | 1,00 | 1,00 | 50,00 | 50,00 |
| Kilometry powyżej progu | 3,71 | 3,78 | 3,71 | 3,78 |
| Koszt na kilometr powyżej progu | 50,00 | 50,00 | 1,00 | 1,00 |
| Łączny koszt | 185,95 | 189,38 | 26,21 | 22,78 |
W każdej wersji niższy z łącznych kosztów 2 rozwiązań jest wyróżniony pogrubieniem. Widać, że gdy używasz wysokiego kosztu powyżej progu, łączny koszt trasy jest teraz wyższy w przypadku trasy, na której wizyty są pogrupowane, co jest odwrotne do tego, co chcesz osiągnąć.