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ędnianie czasu parkowania pojazdu w zoptymalizowanych trasach oraz zapewnienie, ż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 segment trasy, który łączy jedną lokalizację z następną.

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

  • Punkt początkowy trasy.
  • Miejsce, w którym następuje odbiór lub dostawa.
  • Końcowy punkt trasy.

Wszystkie atrybuty przejścia dla modelu definiujesz, dodając je do listyShipmentModel.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.

Modelowanie scenariuszy z życia codziennego

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

Rezerwowanie czasu parkowania

W tej 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 staje się dokładniejszy, a optymalizator preferuje trasy, na których wizyty są zgrupowane.

Aby to zrobić w żądaniu do 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 zakładzie, zanim pojazd wróci do zajezdni. Zoptymalizowana trasa korzysta z najlepszego punktu czyszczenia na podstawie jego lokalizacji oraz lokalizacji odbioru i dostawy wykonanych przez pojazd.
  • Po zakończeniu czyszczenia 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.

Wymaganie to 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 punktu końcowego trasy z dowolnego miejsca z wyjątkiem punktu początkowego trasy 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 z nich dotyczy lokalizacji, 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, że pojazd opuszczający tę lokalizację jest czysty. Inne prośby o 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. Do każdego pojazdu dodaj CLEANED do Vehicle.start_tags. Służy do oznaczania pojazdu jako czystego przed wykonaniem odbiorów lub dostaw, przy założeniu, że został on wyczyszczony pod koniec poprzedniego dnia roboczego, i umożliwia mu przejazd z początkowego punktu na trasie bezpośrednio do punktu końcowego. Nawet jeśli takie trasy nie są w praktyce możliwe, dopuszczenie tego scenariusza pomaga optymalizatorowi skuteczniej wyszukiwać zoptymalizowane trasy.

  4. Do 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 na trasie, 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"
}

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 sztywnych ograniczeń lub wyrażania kompromisu w postaci czasu spędzonego na wykonaniu zadania. 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żdy komunikat musi zawierać jeden z tagów TransitionAttributes, TransitionAttributes.src_tag lub TransitionAttributes.excluded_src_tag oraz jeden z tagów TransitionAttributes.dst_tag lub 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