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

Z tego przewodnika dowiesz się, jak korzystać z atrybutów przejścia. Nauczysz się, jak modelować rzeczywiste scenariusze na 2 przykładach: uwzględniania czasu parkowania pojazdu w zoptymalizowanych trasach oraz zapewnienia, że każda trasa kończy się wizytą w określonej lokalizacji.

Zanim zaczniesz

Atrybuty przejścia służą do dodawania do zoptymalizowanych tras kosztów i opóźnień specyficznych dla modelu w przypadku niektórych przejść. Koszty i opóźnienia są dodawane do czasu trwania 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 drugą.

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 definiujesz, dodając je do listy ShipmentModel.transition_attributes. Każdy element listy definiuje 1 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 dla TransitionAttributes.

Modelowanie rzeczywistych scenariuszy

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

Rezerwowanie czasu na parkowanie

W tym scenariuszu 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 w przypadku obu wizyt. Jeśli kierowca odwiedzi lokalizację B bezpośrednio po lokalizacji 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 drugie.

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

Aby to zrobić w żądaniu do interfejsu Route Optimization API:

  1. Używaj VisitRequest.duration tylko w przypadku czasu potrzebnego na wizytę. Na przykład na przekazanie paczki i zebranie podpisu od klienta.

  2. W przypadku każdego odrębnego miejsca parkingowego używanego 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.tags we wszystkich żądaniach wizyty, 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 kończy trasę w tym miejscu parkingowym.

  4. W przypadku każdego nowego tagu parkowania dodaj wpis do ShipmentModel.transition_attributes który dodaje opóźnienie na parkowanie, gdy przyjeżdżasz z innego miejsca parkingowego, wykonując te czynności:

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

    2. Ustaw TransitionAttributes.delay na czas potrzebny na parkowanie pojazdu.

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

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

Obowiązkowe czyszczenie 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 specjalistycznej myjni przed powrotem do zajezdni. Zoptymalizowana trasa korzysta z najlepszej myjni na podstawie jej lokalizacji oraz lokalizacji odbioru i dostawy wykonanych przez pojazd.
  • Po czyszczeniu pojazd nie może wykonywać żadnych dodatkowych odbiorów ani dostaw.
  • Czas dojazdu i czyszczenia pojazdu wlicza się do godzin pracy kierowcy i musi mieścić się w maksymalnym czasie trwania trasy.

To wymaganie modelujesz, zezwalając tylko na trasy, które są puste lub których ostatnia wizyta jest w myjni. W interfejsie Route Optimization API możesz to zrobić, zabraniając przejść do końcowego punktu pośredniego trasy z dowolnej lokalizacji z wyjątkiem myjni lub punktu początkowego trasy:

  1. Wybierz dwa nowe tagi, które nie są używane nigdzie w modelu, np. CLEANED i ROUTE_END. Pierwszy tag jest przeznaczony dla lokalizacji, w których pojazd jest lub staje się czysty, a drugi – dla 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 myjni powinna być reprezentowana jako żądanie wizyty dostawy w ramach tej przesyłki.
    2. Dodaj CLEANED do VisitRequest.tags każdego żądania wizyty w ramach przesyłki do myjni. Sygnalizuje to, że pojazd opuszczający tę lokalizację jest czysty. Inne żądania wizyty w modelu nie powinny używać tego tagu, aby pojazd był uznawany za „nieczysty” podczas opuszczania tych lokalizacji.
    3. Zezwól optymalizatorowi na pominięcie tej przesyłki, gdy pojazd nie jest używany, ustawiając jej penalty_cost na małą liczbę.

  3. W przypadku każdego pojazdu dodaj CLEANED do Vehicle.start_tags. Służy to do oznaczania pojazdu jako czystego przed wykonaniem odbioru lub dostawy, przy założeniu, że został on wyczyszczony na koniec poprzedniego dnia roboczego, i umożliwia mu przejście z początkowego punktu pośredniego bezpośrednio do punktu końcowego. Nawet jeśli takie trasy nie występują w praktyce, zezwolenie na ten scenariusz 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 końcowego punktu pośredniego, gdy nie są czyste, z tymi właściwościami:

    1. Ustaw TransitionAttributes.excluded_src_tag na CLEANED.

    2. Ustaw TransitionAttributes.dst_tag na ROUTE_END.

    3. Ustaw TransitionAttributes.delay na dużą wartość. Gdy ustawisz opóźnienie dłuższe niż maksymalny czas trwania trasy, skutecznie zabronisz optymalizatorowi używania tego przejścia na trasie.

    Jeśli na przykład skala czasu modelu to 1 dzień roboczy, możesz użyć opóźnienia wynoszącego 24 godziny (86 400 sekund), aby zabronić przejścia na koniec trasy z dowolnego miejsca z wyjątkiem myjni i początku trasy:

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

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 najlepiej sprawdza się w przypadku wdrażania twardych ograniczeń lub wyrażania kompromisu w zakresie czasu spędzonego. TransitionAttributes.cost lepiej pasuje do wdrażania miękkich preferencji lub kompromisów wyrażonych jako dodatkowy koszt. Możesz dowolnie łączyć opóźnienia i koszty, gdy chodzi o czas spędzony i koszty.

W przykładzie czyszczenia pojazdu używamy bardzo długiego opóźnienia, ponieważ czyszczenie pojazdu na końcu trasy jest twardym wymaganiem, 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 kosztu w innym miejscu, np. dostarczając więcej przesyłek w czasie "zaoszczędzonym" przez nieczyszczenie pojazdu.

W przykładzie parkowania używamy krótkiego opóźnienia, które odpowiada dodatkowemu czasowi potrzebnemu na parkowanie pojazdu. Możesz też używać kosztów w połączeniu z opóźnieniami, jeśli kierowca zatrzymuje się na płatnym parkingu.

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

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

Nie możesz po prostu pominąć tagów, ponieważ każdy TransitionAttributes komunikat musi zawierać jeden z TransitionAttributes.src_tag i TransitionAttributes.excluded_src_tag oraz jeden z 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 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 przez żadną lokalizację, te atrybuty przejścia będą pasować do wszystkich lokalizacji.

Więcej informacji