Całość zaimplementowanego systemu można podzielić na: moduł źródła danych, moduł kontrolera oraz moduł serwisu optymalizacyjnego. Wysokopoziomowy diagram aktywno-ści całego systemu jest przedstawiony na Rysunku 8.1.
Źródłem danych, w zaimplementowanym podejściu, są pliki, których postać pierwotnie została zdefiniowana w [90]1. Zadaniem kontrolera jest uruchamianie serwisów optyma-lizacyjnych oraz wybór i propagacja najlepszego rozwiązania. Pseudokod kontrolera jest przedstawiony w Algorytmie 8.3. Zadaniem serwisu optymalizacyjnego jest znalezienie es-tymacji optymalnego zbioru tras R dla zadanego stanu problemu DVRP. Serwis optymali-zacyjny stanowi zatem właściwą implementację metody ContDVRP. Diagram aktywności pojedynczego serwisu optymalizacyjnego jest przedstawiony na Rysunku 8.2. Pseudokod pierwszej i drugiej fazy optymalizacji algorytmu ContDVRP przedstawiony jest odpo-wiednio w Algorytmach 8.4 i 8.5. Algorytm ContDVRP, stanowiący jeden z głównych wyników rozprawy, jest szczegółowo opisany w podrozdziale 8.2.2.
8.2.1 Kontroler
Algorytm 8.3 Psuedokod kontrolera serwisów optymalizacyjnych.
{Vt := zbiór pojazdów dostępnych w czasie t}
{Ct := zbiór zamówień oczekujących w czasie t}
1: while time ≤ end do
2: for all optimizer ∈ optimizers do
3: OptimizeRequestsAssignment(Vt, Ct) {(szczegóły przedstawione w Algoryt-mie 8.4)}
4: OptimizeV ehiclesRoutes(Vt, Ct) {(szczegóły przedstawione w Algorytmie 8.5)}
5: end for
6: bestSolution = ChooseBestSolution(optimizers)
7: end while
W każdym przedziale czasowym ContDVRP przetwarza zbiór zamówień oczekujących Ct. W każdym przedziale czasowym, aż do końca dnia (linia 1 w Algorytmie 8.3) mo-duł kontrolera uruchamia niezależne procesy optymalizacyjne (ozn. optimizers) (linia 2 Algorytmu 8.3). Procesy te są synchronizowane na koniec każdego przedziału czasowego, kiedy wybierane jest najlepsze znalezione rozwiązanie (ozn. bestSolution) (linia 6 Algo-rytmu 8.3).
1Opis tych plików oraz zbiory instancji testowych wykorzystywane w rozprawie są dostępne na stronie:
http://www.mini.pw.edu.pl/∼mandziuk/dynamic/?page id=67
Optymalizacja przeprowadzana przez jedną instancję w pojedynczym kroku czasowym Moduł statystyczny
Kontroler Algorytmy heurystyczne Algorytmy
metaheurystyczne
Rysunek 8.2: Diagram aktywności prezentujący kolejność przetwarzania przez poszcze-gólne moduły w zaimplementowanym procesie optymalizacji. Moduły oznaczone białym kolorem są wykonywane niezależnie od konfiguracji metody optymalizacyjnej. Bazowa wersja algorytmu ContDVRP składa się z modułów białych i zielonych. Niebieskim kolo-rem oznaczone są moduły związane z wykorzystaniem danych problemu. Żółtym kolokolo-rem moduły związane z ciągłą optymalizacją kolejności zamówień.
72
8.2.2 Serwis optymalizacyjny realizujący algorytm ContDVRP
Diagram aktywności serwisu optymalizacyjnego, przedstawiony na Rysunku 8.2, obejmuje pełną możliwą ścieżkę przetwarzania zadanego stanu problemu VRP. Na tym diagramie aktywności oznaczone niebieskim kolorem wiążą się z wykorzystaniem danych problemu w metodach hiperheurystycznej i predykcyjnej. Aktywności oznaczone zielonym kolorem tworzą główny silnik optymalizacyjny ContDVRP, oparty o metaheurystyczne algorytmy optymalizacji globalnej oraz zmodyfikowany algorytm Kruskala rozwiązujący CCP. Ak-tywności oznaczone żółtym kolorem stanowią drugą (opcjonalną) fazę optymalizacji, w której trasa każdego z pojazdów poddana jest dodatkowej optymalizacji algorytmem me-taheurystycznym.
Algorytm 8.4 Pseudokod pierwszej fazy optymalizacji (przypisań zamówień do pojaz-dów).
1: radius ⇐ 2 max
l1,l2=k+1,...,k+mρ(l1, l2)
{rozwiązanie heuristicSolution jest konstruowane aby zwiększyć różnorodność puli rozwiązań oraz utrzymać wyższą jakość rozwiązania}
2: if USE TREE HEURISTIC then
3: heuristicSolution ⇐ CapacitatedM inimalSpanningF orest(Ct) {szczegóły w Al-gorytmie 4.2}
4: else
5: heuristicSolution ⇐ CreateRandomGreedySolution(Ct)
6: end if
7: if t = 0 then
8: bestSolution ⇐ heuristicSolution
9: else
10: bestSolution ⇐ Adapt(bestSolution, heuristicSolution, DISCRETIZE BEST)
11: end if
{część rozwiązań początkowych jest opartych na heuristicSolution, co zapewnia ogra-niczenie dolne na jakość rozwiązania}
{część rozwiązań początkowych opartych jest na bestSolution, co pozwala wykorzy-stać wiedzę o problemie z poprzedniego kroku czasowego}
{pozostałe rozwiązania początkowe są generowane w promieniu radius od bestSolution}
12: optimizer ⇐ InitializeOptimizer(heuristicSolution, bestSolution, radius)
13: for i = 1, 2, . . . , maxAssignmentIterations do
14: P erf ormOptimizationStep(optimizer)
15: end for
{znalezione rozwiązanie (ozn. optimizerBestSolution) jest traktowane jako podział zamówień pomiędzy pojazdy, wraz początkowymi trasami}
16: optimizerBestSolution = GetBestSolution(optimizer)
Każdy proces optymalizacyjny wywołuje najpierw procedurę OptimizeRequestsAssign–
ment(Vt, Ct) (przedstawioną w Algorytmie 8.4), która zwraca podział zamówień pomię-dzy pojazdy, wraz z trasami przetworzonymi algorytmem 2–OPT. Następnie wywoływana jest procedura OptimizeV ehiclesRoutes(Vt, Ct) (przedstawiona w Algorytmie 8.5),
któ-rej zadaniem jest poprawienie trasy dla każdego z pojazdów i zapewnienie dopuszczalność zwracanego rozwiązania.
W optymalizacji podziału zamówień populacja początkowa w algorytmie optymalizacji ciągłej, składa się z: rozwiązania opartego na dyskretnym rozwiązaniu heuristicSolution, ciągłym rozwiązanu bestSolution zaadaptowanym z poprzedniego przedziału czasowego (linia 10 Algorytmu 8.4) oraz losowych rozwiązań wygenerowanych w promieniu radius od bestSolution (linia 11 Algorytmu 8.4). Dyskretne rozwiązanie heuristicSolution jest transformowane do przybliżonego rozwiązania w przestrzeni ciągłej poprzez proces od-zyskiwania aproksymacji, opisany w podrozdziale 6.2.1. Proces transformacji polega na uśrednianiu lokalizacji zamówień przypisanych do jednego pojazdu, a następnie lekkim zaburzaniu tej lokalizacji. Dzięki temu każde z k skupień zamówień przypadających na pojazd ma nieco inną wartość. Najlepsze rozwiązanie z poprzedniego przedziału czasowego jest adaptowane do aktualnego stanu problemu na podstawie liczby pojazdów wykorzy-stanej w heuristicSolution. Jeżeli liczba pojazdów w heuristicSolution jest większa od liczby pojazdów w bestSolution, to bestSolution jest rozszerzone o losowo położone cen-troidy klastrów. Parametr DISCRETIZE BEST decyduje o tym, czy cencen-troidy klastrów są zachowywane (gdy FAŁSZ), czy też odzyskiwane poprzez uśrednianie lokalizacji zamówień oczekujących (gdy PRAWDA).
Algorytm 8.5 Pseudokod drugiej fazy optymalizacji (kolejności obsługi zamówień) i procedury naprawczej rozwiązań.
1: for all vehicle ∈ optimizerBestSolution do
2: vehicle.route ⇐ EnhanceW ith2OP T (vehicle.route)
3: vehicleOptimizer ⇐ InitializeV ehicleOptimizer(vehicle.route)
4: for i = 1, 2, . . . , maxRouteIteration do
5: P erf ormOptimizationStep(vehicleOptimizer)
6: end for
7: vehicle.route ⇐ GetBestRoute(vehicleOptimizer)
8: vehicle.route ⇐ EnhanceW ith2OP T (vehicle.route)
9: end for
{rozmieszczenie w sposób zachłanny zamówień łamiących ograniczenie powrotu do zajezdni (warunek (3.3))}
10: optimizerBestSolution = RepairBestSolution(optimizerBestSolution)
{zachowanie rozwiązania z kroku t − 1, jeżeli w kroku t nie znaleziono lepszego, a stan problemu się nie zmieniał}
11: if Ct⊆ Ct−1 AND optimizerBestSolution > bestSolution then
12: optimizerBestSolution ⇐ bestSolution
13: end if
Po zainicjalizowaniu populacji początkowej, serwis optymalizacyjny iteracyjnie po-szukuje coraz lepszych rozwiązań za pomocą algorytmu stanowiącego parametr metody ContDVRP2. Następnie najlepsze rozwiązanie optimizerBestSolution jest zwracane jako
2W rozprawie rozważane są algorytmy PSO i DE.
74
wynik tej fazy optymalizacji (linia 16 Algorytmu 8.4). W drugiej fazie optymalizacji trasy każdego pojazdów są poprawiane niezależnie od siebie (linie 1-9 Algorytmu 8.5). Z uwagi na fakt, że w ramach optymalizacji przypisania zamówień do pojazdów trasy były już optymalizowane algorytmem 2–OPT, dalsza optymalizacja w tym kroku jest opcjonalna.
Obowiązkową procedurą jest natomiast weryfikacja spełnialności reguły powrotu do za-jezdni na czas (warunek (3.3)). Ostatnie zamówienia z danego pojazdu, które bezpośred-nio powodują złamanie tej reguły, są usuwane i w sposób zachłanny przypisywanego do innego (w szczególności nowego) pojazdu, tak aby ograniczenia problemu zostały zacho-wane (linia 10 Algorytmu 8.5). Jeżeli w wyniku procedury optymalizacyjnej znalezione rozwiązanie uległoby pogorszeniu w stosunku do poprzedniego rozwiązania, a stan pro-blemu nie uległ zmianie, przywracane jest poprzednie najlepsze rozwiązanie (linie 11-12 Algorytmu 8.5).
Po przeprowadzeniu procesu optymalizacyjnego, sterowanie powraca do kontrolera, który zatwierdza do realizacji zamówienia, zgodnie z zasadami przedstawionymi w pod-rozdziale 3.5.