• Keine Ergebnisse gefunden

Kapitel 8 Das Benchmark Bench01 115

8.8 Vergleich mit anderen Verfahren

Zuerst werden einige Ergebnisse von Verfahren vorgestellt, die von der SAP-AG für die Lösung des Benchmarks getestet wurden. Dazu wird auf Kapitel 15.3 in [8.2] verwiesen. Bei den Ergebnis-sen handelt es sich um die jeweils besten gefundenen bei spezieller Parameteranpassung an die In-stanz 0. Als Rechenzeitlimit waren 10 Minuten auf einem Rechner mit 200 MHz vorgegeben. Es sind Ergebnisse zu einem Simulated Annealing Ansatz (TFP_SA), einem auf einer Bibliothek für Constraint Propagation aufgesetztem Branch&Bound Verfahren (CP), einem Branch&Bound Ver-fahren von Schwindt (B&B) und einem Ansatz basierend auf einem genetischen Algorithmus GA gegeben. Meist waren diese Verfahren noch Prototypen, speziell auf den Benchmark angepasst.

Jedoch steckten in den Grundlagen der Verfahren oft jahrelange Entwicklungsarbeiten. So war

TFP_SA bereits im Einsatz bei Kunden, ebenso die Bibliothek für Constraint Propagation von CP.

B&B wurde bereits in [8.3] vorgestellt, jedoch noch um einige Funktionalitäten für das Benchmark erweitert. Details bzgl. der einzelnen Verfahren sind dem Autor leider nicht bekannt.

Der größte Unterschied zwischen TFP_SA zu dem in dieser Arbeit vorgestellten Verfahren (SA_N2) scheint in der Modellierung zu liegen. Während der in dieser Arbeit vorgestellte Ansatz die einzelnen Aktivitäten seriell nacheinander bestmöglich plant, nutzt TFP_SA einen parallelen Aufbau des Plans auf einer direkten Repräsentation, soll bedeuten, dass evtl. mehrere Aktivitäten gleichzeitig zu vorher festgelegten Zeitpunkten geplant werden und anschließend der Plan korrigiert wird, damit einige Nebenbedingungen eingehalten werden. Meist sind die Nebenbedingungen bei TFP_SA weich beachtet worden.

CP basiert auf einer Bibliothek für Constraint Propagation. Darauf aufgesetzt wurde ein Verfahren für Scheduling Probleme, das zuerst eine gültige Initiallösung erstellt und dann mittels einer Fens-tertechnik die Lösung schrittweise verbessert. Grundlage dafür ist ein Branch&Bound-Verfahren, das eine Suche mit Vorausschau verwendet.

Unter GA versteht man ein auf einem genetischen Algorithmus basierendes Verfahren. In [8.2]

wurden verschiedene Initialisierungen und Nachbarschaften getestet. Die in Tabelle 8.14 angege-benen Ergebnisse sind die besten aus einer Menge von Lösungen, die mithilfe eines Parametertu-nings auf Instanz 0 erreicht wurden. GA schafft die Planung von 1000 Aktivitäten pro Sekunde.

Zum Aufbau eines gesamten Plans benötigt der Algorithmus somit 150/1000 Sekunden, oder anders ausgedrückt: der Algorithmus vermag in 15 Sekunden 100 Lösungen zu erzeugen (Rechner mit 200 MHz).

M S M S M S M S M S

2767 760 2361 780 2804 1412 2254 1410 2261 1451

2729 680 2368 650 2714 1270 2288 920 2409 631

2609 660 2510 530 2674 850 2346 640 2442 572

2725 500 2338 -- 2385 540

2758 430 2798 390

GA (av)

TFP_SA CP B&B GA

Tabelle 8.14: Die besten Ergebnisse der Verfahren TFP_SA, CP, B&B und GA. Zusätzlich sind für GA noch durch-schnittliche Ergebnisse angegeben GA(av). Es wird dabei ein Rechenzeitlimit von 10 Minuten auf ei-nem Pentium mit 200 MHz eingehalten.

Bei den Ergebnissen aus Tabelle 8.14 ist jedoch noch zu beachten, dass

• beim 3. Ergebnis von TFP_SA mit erhöhter Lagerkapazität gerechnet wurde,

• beim 2. Ergebnis von B&B zusätzlich noch ein Nachoptimierungsschritt speziell für Rüstzei-ten zum Einsatz kam und beim letzRüstzei-ten Ergebnis die UmrüstzeiRüstzei-ten ignoriert wurden,

• beim GA zuerst nur die besten Ergebnisse mit angepasster Parametereinstellung und zusätz-lich noch durchschnittzusätz-liche Werte angegeben sind GA(av).

In Tabelle 8.15 werden die Ergebnisse aus [8.4] gezeigt. Diese sind die besten bei einer Rechenzeit von 4-5 Stunden auf einer UltraSparc mit 296 MHz mit den Verfahren Threshold Accepting (Vogl_TA) und Simulated Annealing (Vogl_SA). Allerdings sind diese Ergebnisse möglicherweise

nicht korrekt. In der Arbeit wurde ein Gantt einer Lösung gezeigt, in dem nur 27 Aktivitäten vor-handen waren, die die Produkte Ax produzieren. Eigentlich müssten es jedoch 50 sein, da bei jedem der 25 Aufträge jeweils 2 benötigt werden. Leider fehlen auch Ergebnisse zu veränderten Prioritäten bzgl. Durchlaufzeit und Rüstzeiten.

Diese Verfahren (Vogl_SA und Vogl_TA) erzeugt 1000 Moves pro Sekunde (UltraSparc mit 296 MHz). Im Unterschied zu SA_N2 wird bei Vogl_SA auf weiche Nebenbedingungen viel Wert ge-legt. Viele der Nebenbedingungen sind deshalb weich modelliert und mit hohen Strafkosten belegt, wodurch nach Aussagen des Autors [8.4] ‚eine typische Simulation 30 Minuten dauert und man nach dieser Zeit eine erste Lösung vorliegen hat’.

M S M S

2109 650 2106 670

Vogl_SA Vogl_TA

Tabelle 8.15: Die besten Ergebnisse der Verfahren Vogl_SA und Vogl_TA nach 350 Temperaturschritten mit je 50000 Moves. Dies entspricht 4-5 Stunden Rechenzeit auf einer UltraSparc mit 296 MHz.

In [2.7] wurden vom Autor bereits verschiedene Verfahren zur Lösung dieser Problemstellung vor-gestellt. Neben einem Simulated Annealing Ansatz (SA_N1) finden sich dort auch ein Ansatz basie-rend auf Threshold Accepting (TA_N1) und Ergebnisse zu einem Temperature Bouncing (Boun-ce_N1). Der Unterschied zu dem in dieser Arbeit vorgestellten SA_N2 Ansatz liegt in der Modellie-rung. Es werden hier die meisten Nebenbedingungen hart modelliert, so z.B. die Lagerkapazitäten, was den Vorteil hat, dass sehr früh Lösungen gefunden werden, die alle Nebenbedingungen einhal-ten. Neben der Betrachtung als harte Nebenbedingung könnte man in der Modellierung natürlich auch auf eine weiche wechseln, was jedoch zu keinen nennenswerten Unterschieden in der Qualität der Ergebnisse nach Erreichen des Rechenzeitlimits führt. Die größte Veränderung der Modellie-rung liegt in der Nachbarschaft. Während in [2.7] nur eine Nachbarschaft auf den Primärressourcen eingeführt wurde und die Reihenfolge auf den Multiressourcen bei Überschneidung von mehreren Primärressourcen, die diese benötigen, durch ein deterministisches Verfahren bestimmt wurde, er-laubt die Nachbarschaft in dieser Arbeit nun eine Veränderung der Reihenfolge bei der Planung der Multiressourcen. Ebenso werden die Veränderungen nun gleichmäßiger auf alle Ressourcen und Aktivitäten verteilt, da nicht zuerst wie in [2.7] eine Primärressource und erst dann ein Nachbar-schaftsoperator gewählt wird, was zu einer unterdurchschnittlichen Veränderung pro Aktivität auf einer stark ausgelasteten Primärressource führt, sondern zuerst die Operatoren und die zu verän-dernden Aktivitäten ausgewählt werden. Spezielle Operatoren, die nur Veränderungen auf einer ausgewählten Ressource vornehmen, wurden zwar erstellt, in dieser Problemstellung jedoch nicht angewendet, da die Auswertung der Nachbarschaft (siehe Kapitel 8.4.1) offenlegt, dass hier mit der einfachsten Nachbarschaft die besten Ergebnisse zu erzielen sind. Kein großer Unterschied ergab sich in der Geschwindigkeit beim Erstellen einer Lösung. In [2.7] benötigten 10000 Lösungen 16 Sekunden auf einem Pentium mit 200 MHz, hier ist eine Rechenzeit von 5,6 Sekunden für 10000 Lösungen auf einem Pentium mit 650 MHz zu erwarten. In Tabelle 8.16 und 8.17 sind die besten Ergebnisse aus [2.7] für verschiedene Rechenzeiten gegeben.

M S M S M S

2522 660 2514 550 2283 540

2845 540 2643 440 2540 420

2302 1900 2254 1950 2139 1280

SA_N1 TA_N1 Bounce_N1

Tabelle 8.16: Die besten Ergebnisse der Verfahren SA_N1, TA_N1 und Bounce_N1 bei einer Rechenzeitgrenze von 524 Sekunden auf einem Pentium mit 200MHz.

M S M S M S

2357 370 2284 430 2273 380

2074 1000 2465 410 2061 1130

2171 1270

SA_N1 TA_N1 Bounce_N1

Tabelle 8.17: Die besten Ergebnisse der Verfahren SA_N1, TA_N1 und Bounce_N1, erreicht innerhalb der Rechen-zeitgrenze von 22 Stunden (SA_N1), 7 Stunden (TA_N1) und 16 Stunden (Bounce_N1) auf einem Pen-tium mit 200MHz.

Es werden nun die aus der Literatur entnommenen Ergebnisse mit denen aus Kapitel 8.4.2 Abbil-dung 8.7 verglichen. Dazu werden die Pareto-Fronten für 2 Rechenzeiten (1000 und 10000 Sweeps) genommen (Tabelle 8.18). Eine Simulation mit je 1000 Sweeps pro Temperaturschritt benötigt 168 Sekunden auf Pentium mit 650MHZ.

M S M S

2464 390 2220 370

2335 410 2130 470

2317 430 2113 1020

2219 550 2101 1100

2177 690 2089 1550

2159 960 2159 980 2155 1110 2131 1130

SA_N2(1000) SA_N2(10000)

Tabelle 8.18: Die besten Ergebnisse von SA_N2 mit einer Rechenzeitschranke von 1000 und 10000 Sweeps (ent-spricht 168 und 1680 Sekunden auf Pentium mit 650MHz).

In Abbildung 8.10 sind die besten Ergebnisse der verschiedenen Verfahren für kurze Rechenzeiten (<10 Minuten auf Pentium mit 200 MHz) zu sehen. B&B schneidet von den vorgestellten Verfah-ren am schlechtesten ab. SA_N2 am besten. Im Vergleich zu TFP_SA schneiden die beiden ande-ren Simulated Annealing Ansätze SA_N2 und SA_N1 vor allem bei Betrachtung der Durchlaufzeit (M) sehr viel besser ab. Es ist deshalb davon auszugehen, dass der parallele Planaufbau mit an-schließendem Reparaturschritt für diese Problemstellung nicht zu empfehlen ist. Betrachtet man sich die verschiedenen statistischen Versionen aus [2.7], erkennt man, dass die hier gewählte Nach-barschaft in den meisten Fällen deutlich bessere Ergebnisse liefert. Selbst der bisher beste Ansatz des Temperature Bouncing schneidet schlechter ab als SA_N2. Der in [8.2] vorgestellte Ansatz mit einem GA ist zwar besser als die schlechteren Simulated Annealing Versionen, liefert jedoch deut-lich schlechtere Ergebnisse als Bounce_N1 und SA_N2.

0 400 800 1200 1600 2000

2000 2200 2400 2600 2800 3000

M

S

SA_N2 SA_N1 TA_N1 Bounce_N1 TFP_SA CP B&B GA

Abbildung 8.10: Die besten Ergebnisse der verschiedenen Verfahren bei kurzen Rechenzeiten (<=10 Minuten auf einem Pentium mit 200 MHz).

0 400 800 1200 1600

2000 2100 2200 2300 2400 2500

M

S

SA_N2 SA_N1 TA_N1 Bounce_N1 Vogl_SA Vogl_TA

Abbildung 8.11: Die besten Ergebnisse der verschiedenen Verfahren bei langen Rechenzeiten (>10 Minuten auf einem Pentium mit 200 MHz).

Bei den besten Ergebnissen zu den längeren Rechenzeiten (Abbildung 8.11) zeigt sich ein ähnli-ches Bild. SA_N2 liefert bis auf die Optimierung der Durchlaufzeit die besten Ergebnisse. Jedoch ist anzumerken, dass SA_N2 sehr viel weniger Rechenzeit (Minuten) zur Verfügung hatte als SA_N1 und Bounce_N1 (mehrere Stunden). Bei Vogel_SA und Vogl_TA ist noch zu beachten, dass weniger Aktivitäten als benötigt geplant wurden und die Rechenzeiten im Bereich von Stunden lagen.

In [8.5] sind Ergebnisse eines genetischen Algorithmus (OmeGA) zu einer vereinfachten Problem-stellung gegeben. Dort werden keine Lagerbeschränkungen vorgegeben. In den Lösungen im An-hang des Buches sind einige der besten Ergebnisse des dort vorgestellten Verfahrens zu sehen. Es fällt jedoch auf, dass die Rüstzeiten in Stufe B und D nicht den vorgegebenen entsprechen. Nach Rücksprache mit dem Autor konnte festgestellt werden, dass statt den vorgegebenen Rüstmatrizen die Rüstmatrix der Stufe A verwendet wurde. Im Folgenden wurde deshalb eine Simulation mit angepassten Daten ([8.5]) vorgenommen. In Tabelle 8.19 sind einige der besten Ergebnisse aus

jeweils 10 Simulationen mit SA_N2 mit einer Rechenzeit von 1000 Sweeps pro Temperaturschritt zu sehen.

M S M S

2225 360 2298 90

2199 250

2105 720

OmeGA SA_N2(1000)

Tabelle 8.19: Es werden die jeweils besten Ergebnisse des OmeGA und SA_N2 für eine veränderte Problemstellung gezeigt. Die Rechenzeit war bei SA_N2 auf 1000 Sweeps pro Temperaturschritt beschränkt.

In [8.6] wurde mit einem parallelen Ansatz basierend auf dem GA aus [8.2] die Problemstellung bearbeitet. Es wurden dabei Instanzen verwendet, die dem 50fachen der ursprünglichen Aufgaben-stellung entsprechen. Leider können keine Vergleiche zu den dort erstellten Lösungen gegeben werden, da sich der Autor nur mit Aufgabenstellungen mit zusätzlichen Funktionalitäten befasst hat. Es wurde ein Schichtkalender eingeführt, der an die Lösung die Bedingung stellt, dass be-stimmte Aktivitäten nur innerhalb einer Schicht bearbeitet werden dürfen. Neben dieser von dem in dieser Arbeit vorgestellten Verfahren nicht erfüllbaren Funktionalität werden in [8.6] noch Pausen eingeführt, die Kapazitäten der Pools zeitabhängig verändert und ein Kalender für zeitabhängige Produktivität eingeführt. Die zeitabhängige Produktivität führt zu Produktionsdauern, die nun nicht mehr nur von dem Produktionsvorgang und der verwendeten Maschine, sondern auch noch vom Startzeitpunkt des Produktionsvorgangs abhängig sind.