Modelowanie logiki biznesowej za pomocą atrybutów przejścia

W tym przewodniku znajdziesz możliwe zastosowania atrybutów przejścia. Dowiesz się z niego, jak modelować rzeczywiste scenariusze na 2 przykładach: uwzględniania czasu parkowania pojazdu w zoptymalizowanych trasach oraz zapewniania, że każda trasa kończy się wizytą w określonym miejscu.

Zanim zaczniesz

Atrybutów przejścia używasz do dodawania kosztów i opóźnień związanych z konkretnym modelem do określonych przejść na zoptymalizowanych trasach. Te koszty i opóźnienia są dodawane do czasów przejścia i kosztów obliczonych na podstawie danych mapy na podstawie parametrów używanego pojazdu.

Przejście to odcinek trasy, który łączy jedną lokalizację z następną.

Lokalizacja to dowolny z tych punktów na trasie pojazdu:

• Punkt początkowy trasy.
• Przystanek, na którym następuje odbiór lub dostawa.
• punkt końcowy trasy,

Wszystkie atrybuty przejścia dla modelu określasz, dodając je do listy ShipmentModel.transition_attributes. Każdy element listy definiuje jeden zestaw atrybutów przejścia i jest dopasowywany do przejść na trasach za pomocą tagów w lokalizacji początkowej i końcowej przejścia. Więcej informacji o atrybutach przejścia znajdziesz w dokumentacji referencyjnej TransitionAttributes.

Ważne: dzięki atrybutom przejścia możesz wdrożyć wiele ograniczeń biznesowych dotyczących sekwencji lokalizacji. Możesz na przykład sprawić, że niektóre trasy będą mniej atrakcyjne dla optymalizatora, zabronić bezpośrednich przejść z lokalizacji A do lokalizacji B lub zadbać o to, aby po wizycie w lokalizacji A zawsze następowała wizyta w lokalizacji B.

Modelowanie scenariuszy z życia codziennego

W tej sekcji znajdziesz 2 krótkie przykłady wdrażania rzeczywistych ograniczeń biznesowych za pomocą atrybutów przejścia.

Rezerwowanie czasu parkowania

W takiej sytuacji kierowca musi zaparkować pojazd, zanim będzie mógł odwiedzić lokalizację A. Lokalizacja B znajduje się w pobliżu, a kierowca może skorzystać z tego samego miejsca parkingowego podczas obu wizyt. Jeśli kierowca odwiedzi punkt B bezpośrednio po punkcie A, zaoszczędzi czas, ponieważ nie będzie musiał opuszczać miejsca parkingowego i ponownie parkować pojazdu. W interfejsie Route Optimization API możesz używać atrybutów przejścia, aby dodać dodatkowy czas na parkowanie pojazdu tylko wtedy, gdy kierowca przemieszcza się z jednego miejsca parkingowego na inne.

Jeśli czas parkowania jest modelowany oddzielnie od czasu trwania wizyt, trasy, na których wizyty korzystające z tego samego parkingu są zgrupowane, zajmują mniej czasu. Dzięki temu model jest dokładniejszy, a optymalizator preferuje trasy, na których wizyty są zgrupowane.

Aby to zrobić w żądaniu interfejsu Route Optimization API, wykonaj te czynności:

1. Używaj VisitRequest.duration tylko przez czas potrzebny na wizytę. Na przykład przekazać przesyłkę i zebrać podpis klienta.

2. W przypadku każdego odrębnego miejsca parkingowego użytego w modelu użyj nowego tagu, który nie jest używany do niczego innego w modelu, np. PARKING_123.

3. Dodaj ten tag do tych elementów:

   1. VisitRequest.tagswe wszystkich żądaniach wizyt, które korzystają z tego miejsca parkingowego.

   2. Vehicle.start_tags jeśli pojazd rozpoczyna trasę w tym miejscu parkingowym.

   3. Vehicle.end_tags jeśli pojazd rozpoczyna lub kończy trasę na tym parkingu.

4. Dla każdego nowego tagu parkowania dodaj wpis do ShipmentModel.transition_attributes który dodaje opóźnienie parkowania w przypadku przyjazdu z innego miejsca parkingowego, wykonując te czynności:

   1. Ustaw TransitionAttributes.excluded_src_tag i TransitionAttributes.dst_tag na PARKING_123.

   2. Ustaw wartość TransitionAttributes.delay na czas potrzebny na zaparkowanie pojazdu.

   Jeśli na przykład tag lokalizacji to PARKING_123, a zaparkowanie pojazdu zajmuje 150 sekund, dodaj do ShipmentModel.transition_attributes ten wpis:

   {
     "excluded_src_tag": "PARKING_123",
     "dst_tag": "PARKING_123",
     "delay": "150s"
   }
   

Obowiązkowe sprzątanie na końcu trasy

W tym scenariuszu pojazd musi zostać wyczyszczony na końcu trasy, z uwzględnieniem tych dodatkowych ograniczeń:

• Czyszczenie odbywa się w specjalistycznym punkcie czyszczenia, a następnie pojazd wraca do zajezdni. Zoptymalizowana trasa korzysta z najlepszego punktu czyszczenia na podstawie jego lokalizacji oraz lokalizacji odbioru i dostawy wykonanych przez pojazd.
• Po zakończeniu sprzątania pojazd nie może odbierać ani dostarczać żadnych dodatkowych przesyłek.
• Czas dojazdu i czyszczenia pojazdu wlicza się do godzin pracy kierowcy i musi mieścić się w maksymalnym czasie trwania trasy.

Ten wymóg modelujesz, zezwalając tylko na trasy, które są puste lub których ostatnim punktem jest myjnia. W interfejsie Route Optimization API możesz to zrobić, zabraniając przejść do końcowego punktu trasy z dowolnego miejsca z wyjątkiem punktu początkowego trasy lub punktu czyszczenia:

1. Wybierz 2 nowe tagi, które nie są używane w modelu, np. CLEANED i ROUTE_END. Pierwszy z nich dotyczy miejsc, w których pojazd jest lub staje się czysty, a drugi – końca trasy.
2. W przypadku każdego pojazdu dodaj nową przesyłkę tylko z dostawą, która reprezentuje wizytę w myjni, z tymi atrybutami:
   1. Każda lokalizacja pralni powinna być reprezentowana jako prośba o wizytę związaną z dostawą w ramach tej przesyłki.
   2. Dodaj CLEANED do VisitRequest.tags każdej prośby o wizytę w przypadku przesyłki z zakładu czyszczącego. Sygnalizuje to, że pojazd opuszczający tę lokalizację jest czysty. Inne żądania wizyt w modelu nie powinny używać tego tagu, aby pojazd był uznawany za „nieczysty” po opuszczeniu tych miejsc.
   3. Zezwól optymalizatorowi na pominięcie tej dostawy, gdy pojazd nie jest używany w inny sposób, ustawiając jego wartość penalty_cost na małą liczbę.

3. W przypadku każdego pojazdu dodaj CLEANED do Vehicle.start_tags. Służy do oznaczania pojazdu jako czystego przed rozpoczęciem odbioru lub dostawy, przy założeniu, że został on wyczyszczony pod koniec poprzedniego dnia roboczego, i umożliwia mu przejazd z początkowego punktu trasy bezpośrednio do punktu końcowego. Nawet jeśli takie trasy nie są w praktyce realizowane, dopuszczenie tego scenariusza pomaga optymalizatorowi skuteczniej wyszukiwać zoptymalizowane trasy.

4. W przypadku każdego pojazdu dodaj ROUTE_END do Vehicle.end_tags.

5. Dodaj nowy wpis do ShipmentModel.transition_attributes, który zabrania pojazdom docierania do punktu końcowego trasy, jeśli nie są czyste. Wpis powinien mieć te właściwości:

   1. Ustaw TransitionAttributes.excluded_src_tag na CLEANED.

   2. Ustaw TransitionAttributes.dst_tag na ROUTE_END.

   3. Ustaw TransitionAttributes.delay na dużą wartość. Jeśli ustawisz opóźnienie dłuższe niż maksymalny czas trwania trasy, uniemożliwisz optymalizatorowi użycie tego przejścia na trasie.

   Jeśli na przykład skala czasowa modelu to 1 dzień roboczy, możesz użyć opóźnienia wynoszącego 24 godziny (86 400 sekund), aby uniemożliwić przejście do końca trasy z dowolnego miejsca z wyjątkiem punktu czyszczenia i początku trasy:

   {
     "excluded_src_tag": "CLEANED",
     "dst_tag": "ROUTE_END",
     "delay": "86400s"
   }
   

Ostrzeżenie: jeśli zabronisz zbyt wielu przejść, możesz całkowicie zablokować dostęp do niektórych odbiorów lub dostaw, a optymalizator może znaleźć tylko rozwiązania, w których wiele lub wszystkie przesyłki są pomijane.

Jak wybrać między opóźnieniami a kosztami

Wybór między opóźnieniami a kosztami zależy od charakteru wdrożonej logiki biznesowej i ograniczeń. Ustawienie TransitionAttributes.delay jest najlepsze do wdrażania sztywnych ograniczeń lub wyrażania kompromisu w zakresie czasu spędzonego na zadaniu. TransitionAttributes.cost lepiej sprawdza się w przypadku wdrażania preferencji miękkich lub kompromisów wyrażonych jako dodatkowy koszt. Możesz dowolnie łączyć opóźnienia i koszty, jeśli chodzi o czas i koszty.

W przykładzie dotyczącym czyszczenia pojazdu użyto bardzo długiego opóźnienia, ponieważ wyczyszczenie pojazdu na końcu trasy jest wymagane, a długie opóźnienie uniemożliwia optymalizatorowi zignorowanie tego wymagania. Jeśli ustawisz tylko koszt, optymalizator może pominąć czyszczenie, jeśli znajdzie sposób na zrekompensowanie kosztów w inny sposób, np. dostarczając więcej przesyłek w czasie „zaoszczędzonym” dzięki nieczyszczeniu pojazdu.

W przykładzie dotyczącym parkowania użyto krótkiego opóźnienia, które odpowiada dodatkowemu czasowi potrzebnemu na zaparkowanie pojazdu. Możesz też użyć atrybutu costs w połączeniu z atrybutem delays, jeśli kierowca zatrzymuje się na płatnym parkingu.

Jak dodać atrybut przejścia, który pasuje do wszystkich żądań wizyt

W przykładach powyżej użyto atrybutów przejścia, które pasują do lokalizacji z danym tagiem lub do lokalizacji, które nie mają tego tagu. Ale co, jeśli chcesz dodać atrybuty przejścia, które mają zastosowanie do wszystkich przejść?

Nie możesz po prostu pominąć tagów, ponieważ każda wiadomość TransitionAttributes musi zawierać jeden z tagów TransitionAttributes.src_tag i TransitionAttributes.excluded_src_tag oraz jeden z tagów TransitionAttributes.dst_tag i TransitionAttributes.excluded_dst_tag.

Możesz jednak dopasować wszystkie tagi, ustawiając TransitionAttributes.excluded_src_tag lub TransitionAttributes.excluded_dst_tag na tag, który nie jest nigdzie używany w modelu. Spowoduje to dopasowanie wszystkich lokalizacji, które nie mają tego tagu, ale ponieważ celowo wybrano tag, który nie jest używany w żadnej lokalizacji, te atrybuty przejścia będą pasować do wszystkich lokalizacji.

Więcej informacji

• Parametry modelu kosztów