Priorytetowe traktowanie wizyt w pobliżu dzięki atrybutom przejścia

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;
• dodatkowe dostawy są dalej na tej samej drodze;
• dostawy nie mają określonych czasów dostawy;
• 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łkowitej długości 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. Ustaw TransitionAttributes.excluded_src_tag i TransitionAttributes.excluded_dst_tag na ten tag.
• Skonfiguruj TransitionAttributes.distance_limit z odległością progową i kosztami:
  • Ustaw DistanceLimit.soft_max_meters wybrany próg.
  • Ustaw DistanceLimit.cost_per_kilometer_below_soft_max koszt na kilometr poniżej progu.
  • Ustaw DistanceLimit.cost_per_kilometer_above_soft_max koszt na kilometr powyżej progu.

{
  "model": {
    "transitionAttributes": [
      {
        "excluded_dst_tag": "UNUSED_TAG",
        "excluded_src_tag": "UNUSED_TAG",
        "distanceLimit": {
          "softMaxMeters": 100,
          "costPerKilometerBelowSoftMax": 50,
          "costPerKilometerAboveSoftMax": 1,
        }
      }
    ]
  }
}

Aby dopasować wszystkie możliwe przejścia, tagu #unused_tag# nie mogą używać żadne przesyłki ani pojazdy. 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 całkowity 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ą. 2 z nich są dostarczane podczas pierwszego przejazdu, a pozostała podczas drugiego. Istnieje 5 przejść:

Całkowity koszt oblicza się jako sumę 2 kosztów na kilometr:

• koszt na kilometr poniżej progu (50) pomnożony przez całkowitą odległość poniżej progu (450 m = 0,45 km);
• koszt na kilometr powyżej progu (1) pomnożony przez całkowitą odległość powyżej progu (3710 m = 3,71 km).

Całkowity 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ę wcale. Ponownie mamy 5 przejść, ale ich długość i skład są inne:

Przy tych samych obliczeniach co w rozwiązaniu 1 całkowity 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:

W każdej wersji niższy z całkowitych kosztów 2 rozwiązań jest wyróżniony pogrubieniem. Widać, że gdy używasz wysokiego kosztu powyżej progu, całkowity koszt trasy jest teraz wyższy w przypadku trasy, na której wizyty są pogrupowane, co jest odwrotne do tego, co chcesz osiągnąć.