• Keine Ergebnisse gefunden

5 Deadlock-Handling

5.3 Deadlock-Resolution

5.3.3 Die Prozedur reassignOrder

Wenngleich die meisten Deadlocks durch eine der beiden in den vorhergehenden Ab-schnitten beschriebenen Prozeduren aufgelöst werden können, gibt es Situationen, in denen keine der beiden Methoden anwendbar ist. So kann es z.B. in der in Abbildung 5-12(a) dargestellten Situation vorkommen, dass die nächste Operation einer

Container-brücke nicht sofort ausgeführt werden kann, selbst wenn sie an die erste Stelle des AGV-Plans vorgezogen würde. Dafür kann es zwei Gründe geben. Zum einen kann diese nächste Operation eine Aufladeoperation sein, aber die Ladefläche des Fahrzeugs ist vollständig durch andere Container blockiert. Andererseits kann die nächste Opera-tion eine AbladeoperaOpera-tion sein, aber der entsprechende Container befindet sich noch nicht auf der Ladefläche des Fahrzeugs. In beiden Fällen ist ein einfaches Vorziehen der betreffenden Operationen im Plan des AGVs nicht ausreichend, um den Deadlock auf-zulösen.

In solchen Fällen muss ein so genanntes Springer-Fahrzeug bereitgestellt werden. Die Idee von Springer-Fahrzeugen ist angelehnt an die Vorgehensweise bei flexiblen Ferti-gungslinien, z.B. in der Automobilindustrie. In diesem Umfeld gibt es spezielle Arbeiter – die „Springer“ – die immer dort aushelfen, wo gerade ein Engpass auftritt. Ähnlich dieser Arbeiter werden Springer-Fahrzeuge im vorliegenden Fall nicht für den laufen-den Betrieb eingesetzt. Sie werlaufen-den nur aktiviert, wenn sie zur Auflösung eines Dead-locks benötigt werden.

Generell ist ein einziges Springer-AGV ausreichend, um alle Deadlocks eines Systems auflösen zu können. Wie weiter unten in diesem Abschnitt genauer erklärt wird, kommt während jedem Aufruf der Prozedur reassignOrder nur ein solches Fahrzeug zum Ein-satz. Weiterhin wird gezeigt, dass ein Deadlock, der ein Springer-AGV umfasst, allein durch Anwendung der Prozedur modifyScSequence aufgelöst wird (ohne erneut reassignOrder benutzen zu müssen).

Natürlich hat die Anzahl der eingesetzten Springer-AGVs Einfluss auf die Geschwin-digkeit, mit der ein Deadlock aufgelöst werden kann. Die Verwendung mehrerer solcher Fahrzeuge verringert die Arbeitslast jedes einzelnen Springer-AGVs. Daher kann für Systeme, die extrem anfällig für Deadlocks sind und in denen die Auflösung des Dead-locks sehr zeitkritisch ist, der Einsatz mehrerer Springer-AGVs sinnvoll sein. Die ge-naue Anzahl der einzusetzenden Fahrzeuge wird am besten in Simulationsstudien er-mittelt, wobei zusätzlich die Anschaffungskosten der Fahrzeuge eine Rolle spielen. Für sämtliche in dieser Arbeit untersuchten Szenarien jedoch war die Verwendung eines einzigen Springer-Fahrzeugs völlig ausreichend, da die Anzahl der auftretenden Dead-locks sehr gering war (siehe Abschnitt 6.3.1.4).

Prinzipiell wäre es auch möglich, auf den expliziten Einsatz von Springer-Fahrzeugen zu verzichten und stattdessen Fahrzeuge, die momentan ungenutzt sind, in einen Sprin-ger-Modus zu versetzen. In fast jedem Terminal oder Flexiblen Fertigungssystem gibt es zeitweise ungenutzte Kapazitäten. Allerdings ist dieser Ansatz nicht ganz unkritisch, da die Springer-Fahrzeuge eine wesentliche Komponente des hier beschriebenen Ansat-zes zur Deadlock-Resolution sind. Man müsste in einem solchen Fall garantieren, dass

zu jeder Zeit mindestens ein Fahrzeug in den Springer-Modus versetzt werden kann.

Dieses Fahrzeug dürfte insbesondere nicht gerade selbst in einen Deadlock verwickelt sein. Da Deadlocks vornehmlich in Hochlastsituationen auftreten, ist eine solche Ga-rantie vermutlich schwer zu geben.

Die Eingriffe, die bei der Durchführung der Prozedur reassignOrder notwendig werden, sind schwerwiegender als jene, die für die anderen beiden Prozeduren erforderlich sind.

Als Beispiel betrachte man die Situation in Abbildung 5-13(a).

(a) Situation vor reassignOrder(V2) (b) Situation vor reassignOrder(V2) Q2

V1 V1

V2 V2

QC-Plan p2 d5

p2 d5

AGV-Plan d5 p4

QC-Plan p4 d1

AGV-Plan d1 p2 d1 d2

p4

Q1

S1 S1

SC-Plan d2

AGV-Plan p3 d3 5

1

d2

VX VX

Q2

V1 V1

V2 V2

QC-Plan p2

d5 d5

AGV-Plan d5 p4

QC-Plan p4 d1

AGV-Plan d1 d1

p4

Q1

S1 S1

SC-Plan d2

VX VX

AGV-Plan p3 d3 p2 d2 5

1

d2 p2

Abbildung 5-13: Die Prozedur reassignOrder

Angenommen, die Kante (Q2,V1) soll hier eingefügt werden. In dieser Situation kann die Prozedur advanceOrder nicht angewendet werden, da Containerbrücke Q1 auf das Fahrzeug V2 wartet, um die Aufladeoperation p2 auszuführen. Die Ladefläche von V2 ist allerdings noch von dem 40ft-Container 1 blockiert, der zuerst abgeladen werden muss. Operation p2 kann also nicht ohne weiteres im Plan von V2 vorgezogen werden.

Aus denselben Gründen kann Operation p4 nicht an die erste Stelle des Plans von V1 gezogen werden. Der Zykel, der durch Einfügen der Kante (Q2,V1) in die Kette V1-Q1-V2-Q2 entsteht, muss mit anderen Mitteln aufgelöst werden. Dazu werden – im Rah-men der Prozedur reassignOrder – die Auflade- und Abladeoperation p2 und d2 des ersten Containers im Plan von Q1 einem Springer-Fahrzeug (statt bisher dem Fahrzeug V2) zugeordnet. In Abbildung 5-13 wird dieses Springer-Fahrzeug mit Vx bezeichnet.

Um zu verhindern, dass Springer-Fahrzeuge selbst in einem Deadlock gefangen sind, werden diese Fahrzeuge nur im SLC-Modus betrieben, d.h. diese Fahrzeuge arbeiten die Transportaufträge nacheinander ab, ohne Auf- und Abladeoperationen verschiedener Aufträge zu verschachteln. Wird ein Auftrag einem Springer-Fahrzeug zugewiesen, so wird er am Ende dessen bisherigen Plans angehängt. Die Zuordnung von Aufträgen zu

Springer-Fahrzeugen ist prinzipiell eine feste Zuordnung, d.h. einmal getroffene Zuord-nungen werden nicht wieder aufgelöst.

Im Ergebnis der Prozedur reassignOrder warten im gegebenen Beispiel die Kräne Q1 und S1 nicht mehr auf V2, und das Einfügen der Kante (Q2,V1) erzeugt nun keinen Zykel im Resource-Allocation-Graphen. In Abbildung 5-13(b) ist die Situation nach Anwendung der Prozedur reassignOrder dargestellt.

Wie man sieht, werden im Rahmen der Prozedur reassignOrder die zusätzlichen Kanten (Q1,Vx) und (S1,Vx) eingefügt, um die neu entstandenen Wartebeziehungen zwischen Q1 bzw. S1 und Vx abzubilden. Es muss also sichergestellt werden, dass das Einfügen dieser Kanten zu keinem neuen Zykel im Graphen führt. Wie dies geschieht, soll in Abbildung 5-14 beispielhaft deutlich gemacht werden.

Sei die Kante 9 (in Abbildung 5-13(b) mit (Q2,V1) bezeichnet) jene Kante, die ursprünglich in den Graphen eingefügt werden sollte. Das Einfügen von Kante 9 würde einen Kreis schließen. Durch Anwendung der Prozedur reassignOrder wurden die Kanten 1 und 2 aus dem Graphen entfernt. Da der nächste Auftrag von Q1 von V2 an Vx gegeben wurde, wartet nun weder Q1 noch S1 auf V2. Allerdings warten diese Kräne nun möglicherweise auf Vx, in welchem Falle die Kanten 5 und 8 eingefügt wer-den müssten. Dies wiederum kann zu neuen Zykeln führen, in wer-denen das Springer-Fahr-zeug Vx nun selbst enthalten ist. Diese Zykel dürfen natürlich nicht bestehen bleiben.

V2

Q1

Q2

S1 V1

Vx

S3 S2

1 2

99 4

3

5

8

6 7 modifyScSequence(S2)

modifyScSequence(S3)

reassignOrder(V2ÆVx) 9

Abbildung 5-14: Korrektheit der Prozedur reassignOrder

Wirft man einen näheren Blick auf die neu entstandenen Zykel, so stellt man fest, dass Vx, so es denn zu einem Zykel gehört, natürlich auf irgendeinen Kran wartet. Dieser Kran kann jedoch keine Containerbrücke sein, da alle Operationen von Container-brücken, die einem Springer-Fahrzeug zugeordnet werden, an erster Stelle des Plans der entsprechenden Containerbrücke stehen (dies folgt aus der Arbeitsweise der Prozedur reassignOrder, die nur für Containerbrücken angewendet wird). Wartet Vx aber nicht auf eine Containerbrücke, muss das Fahrzeug auf einen Lagerkran warten. Das bedeu-tet, dass mindestens ein Lagerkran im entsprechenden Zykel enthalten sein muss.

Also kann die Prozedur modifyScSequence auf einen Lagerkran in jedem Zykel (z.B.

den Engpass-Kran) angewendet werden. In Abbildung 5-14 seien die ausgewählten Lagerkräne S2 und S3. Die Anwendung der Prozedur modifyScSequence führt dazu, dass die Kanten 3 und 4 bzw. 6 und 7 gelöscht werden können. Im Ergebnis können nun die Kanten 5 und 8 (wie durch reassignOrder vorgesehen) in den Graphen eingefügt werden, ohne dass er zyklisch wird. Durch die Anwendung von modifyScSequence wur-den keine weiteren Kanten eingefügt. Folglich kann der ursprüngliche Deadlock in ma-ximal zwei Schritten aufgelöst werden.