Eine Methode zum Einsatz von bestärkenden Lernverfahren für die Produktionsablaufplanung

Zusammenfassung

Wie in der Schlussbetrachtung zum Stand der Wissenschaft und Technik beschrieben, existiert bisher noch keine systematische Vorgehensweise, wie bestärkende Lernverfahren für die Produktionsablaufplanung einsetzbar gemacht werden können. Basierend auf der theoretischen Fundierung in den Kapiteln 2 und 3 soll im Folgenden eine Methode herausgearbeitet werden, die das Vorgehen zum Einsatz von bestärkenden Lernverfahren für die Produktionsablaufplanung formalisiert. In Abschnitt 5.1 soll zunächst der aktuelle Prozess der Produktionsablaufplanung als Ausgangspunkt reflektiert werden, an welchen die zu entwickelnde Methode anknüpfen möchte.

Wie in der Schlussbetrachtung zum Stand der Wissenschaft und Technik beschrieben, existiert bisher noch keine systematische Vorgehensweise, wie RL-Verfahren für die Produktionsablaufplanung einsetzbar gemacht werden können. Basierend auf der theoretischen Fundierung in den Kapiteln 2 und 3 soll im Folgenden eine Methode herausgearbeitet werden, die das Vorgehen zum Einsatz von RL-Verfahren für die Produktionsablaufplanung formalisiert. In Abschnitt 5.1 soll zunächst der aktuelle Prozess der Produktionsablaufplanung als Ausgangspunkt reflektiert werden, an welchen die zu entwickelnde Methode anknüpfen möchte. Hierauf basierend soll eine Anforderungsdefinition für die zu entwickelnde Methode abgeleitet werden. Die eigentliche Methode fußt im Wesentlichen auf zwei Bestandteilen. In Abschnitt 5.2 wird zunächst diskutiert, dass es einen Wandel von einer Produktionsablaufplanung zu einer agentenbasierten Produktionsablaufsteuerung bedarf. Daran anschließend präzisiert Abschnitt 5.2 den Prozess und das Funktionsprinzip der agentenbasierten Produktionsablaufsteuerung. Der zweite Bestandteil der Methode ist ein Vorgehensmodell zur Projektierung und Entwicklung von agentenbasierten Produktionsablaufsteuerungen. Diesem Vorgehensmodell widmet sich Abschnitt 5.3.

5.1 Ausgangssituation, Problemstellung und Anforderungsdefinition

Als Ausgangspunkt wird zunächst der aktuelle Prozess der Produktionsablaufplanung gemäß einem etablierten PPS-Modell betrachtet. Zu diesem Zweck wurde bereits in Abbildung 2.2 (Abschnitt 2.2) der Prozess der Eigenfertigungsplanung und -steuerung des Aachener PPS-Modells skizziert. Eine zentrale Schlussfolgerung war, dass die Ressourcenbelegungsplanung (respektive die sequenzielle Feinterminierung und Ressourcenfeinplanung) sowie die daran anschließende Reihenfolgeplanung die Produktionsablaufplanung im engeren Sinne repräsentieren, derweilen die vorgelagerte Losgrößenplanung der Produktionsablaufplanung im weiteren Sinne zugerechnet wird.

Im Folgenden soll der momentane Prozess der Produktionsablaufplanung gemäß dem Aachener PPS-Modell im Detail betrachtet werden. Zu diesem Zweck präzisiert Abbildung 5.1 die blaugefärbten Aktivitäten der Produktionsablaufplanung aus Abbildung 2.2 als UML-Aktivitätsdiagramm. Eine Erklärung der Notation für UML-Aktivitätsdiagramme ist als Anhang G dem elektronischen Zusatzmaterial beigefügt. Der Prozessablauf basiert im Wesentlichen auf den Ausführungen von Schuh et al. (2012a, S. 53 ff.) zur Losgrößenrechnung, Feinterminierung, Ressourcenfeinplanung und Reihenfolgeplanung. Ausgehend von einem vorbestimmten Eigenfertigungsprogramm wird zunächst überprüft, ob die einzulastenden Produktionsaufträge zu Produktionslosen konsolidiert werden können. Wie bereits in Abschnitt 2.2 beschrieben, wird mithilfe der Bildung von Losen ein kostenoptimaler Kompromiss zwischen niedrigen Umlaufbeständen und einer geringen Anzahl von Rüstvorgängen angestrebt, bei welchen es sich um gegensätzliche Zielstellungen handelt. Die Losgrößen werden häufig auf Basis von Erfahrungswissen einmalig und intuitiv festgelegt oder mithilfe mathematischer Formeln für bestimmte Produktionszeiträume berechnet. Darauffolgend werden im Zuge der Ressourcenbelegungsplanung die Start- und Endzeiten der einzelnen Produktionsaufträge bzw. der kumulierten Produktionslose durch Vorwärts-, Rückwärts- oder Mittelpunktterminierung bestimmt. Falls die resultierenden Start- und Endzeiten unzulässig sind (bspw. aufgrund verletzter Fertigstellungsfristen), kann durch eine Aufteilung bzw. Zusammenführung von Produktionslosen eine Durchlaufzeitverkürzung angestrebt werden. Falls im Voraus bereits festgestellt wurde, dass eine Losbildung nicht zielführend ist, können neue Start- und Endzeiten mit einem alternativen Terminierungsverfahren bestimmt werden. Im nächsten Schritt werden die Kapazitätsbedarfe für die erforderlichen Produktionsressourcen ermittelt. Die Kapazitätsbedarfe werden nicht nur auf einzelne Produktionsressourcen, sondern ebenfalls auf verschiedene Produktionsperioden aufgeschlüsselt, die aus den zuvor ermittelten Start- und Endzeiten resultieren. Durch eine Gegenüberstellung des Kapazitätsbedarfs mit dem verfügbaren Kapazitätsangebot wird analysiert, ob in bestimmten Produktionsperioden Kapazitätsüberlasten auftreten. Etwaige Kapazitätsüberlasten können mithilfe von Sonderschichten oder durch Verschiebung von Produktionsaufträgen in Perioden, in denen die verfügbaren Kapazitäten nicht voll ausgeschöpft sind, aufgelöst werden. Aufgrund der Ressourcenbelegungsplanung entstehen Warteschlangen aus einzelnen Aufträgen oder Auftragslosen vor den jeweiligen Produktionsressourcen. Im Zuge der Auftragsreihenfolgeplanung wird die Bearbeitungsreihenfolge der Aufträge bzw. Auftragslose auf jeder Produktionsressource festgelegt. Für die Reihenfolgebildung werden häufig Prioritätsregeln oder Kumulationskriterien (z. B. Auftragsauswahl gemäß der gerüsteten Produktfamilie zur Minimierung von Rüstzeiten) zu Rate gezogen. Darüber hinaus kann ebenfalls auf eine explizite Auftragsreihenfolgeplanung verzichtet werden. Stattdessen entscheiden die Fachkräfte im Fertigungsbereich erfahrungsbasiert über die Bearbeitung des nächsten Auftrags(loses), sobald eine Kapazitätseinheit auf der erforderlichen Ressource verfügbar wird.

Abbildung 5.1

Detaillierter Prozess der Produktionsablaufplanung gemäß dem Aachener PPS-Modells

Das Vorgehen für die Produktionsablaufplanung gemäß dem Aachener PPS-Modell zeichnet sich insbesondere durch einen klaren stringenten Ablauf sowie durch die Verwendung von einfach verständlichen und aufwandsarm zu realisierenden Methoden aus. Hierdurch ist es leicht zugänglich für Produktionsplaner*innen und begünstigt ebenfalls eine softwaretechnische Realisierung. Ungeachtet dessen lassen sich am geschilderten Vorgehen einige Charakteristiken beobachten, die insbesondere in hochdynamischen und volatilen Produktionsumgebungen nachteilig wirken:

• Die Produktionsablaufplanung des Aachener PPS-Modells geht von einem fix determinierten Eigenfertigungsprogramm aus. Hierbei handelt sich um eine Liste von Aufträgen, die in einer definierten Planungsperiode produziert werden sollen. Die Losgrößenrechnung, Ressourcenbelegungs- und Reihenfolgeplanung unterliegen somit der Annahme eines statischen Auftragshorizonts. Die Produktionsablaufplanung des Aachener PPS-Modells ist somit nur in geringem Maße für einen dynamischen stochastischen Auftragshorizont geeignet, bei welchen in zufälligen Zeitabständen Produktionsaufträge in das System gelangen, die aufgrund von eng gesetzten Lieferterminen in der aktuellen Planungsperiode produziert werden müssen.

• Die mangelnde Eignung des Vorgehens für hochdynamische und volatile Produktionsumgebungen lässt sich ferner anhand der Art und Weise begründen, wie Produktionsablaufpläne erstellt werden. Die Losgrößenrechnung, Ressourcenbelegungs- und Reihenfolgeplanung finden nicht integriert, sondern stufenweise nacheinander statt. Dieses Vorgehen birgt insbesondere einen Nachteil. Angenommen in einer vorgelagerten Planungsstufe wird eine anforderungsgerechte Lösung generiert, so ist nicht sichergestellt, dass hieran anschließend ein zulässiges Planungsergebnis in einer der darauffolgenden Stufen ermittelt werden kann. Im besten Fall kann mithilfe von einfachen Heuristiken und Entscheidungsregeln ein zulässiger Alternativplan generiert werden, der jedoch gewöhnlich eine geringere Lösungsqualität aufweist. Im schlechtesten Fall muss der Planungsprozess vollständig von Neuem, ausgehend von der Losgrößenrechnung, begonnen werden. Dieses Szenario wird in Abbildung 5.1 nicht dargestellt, findet jedoch im Prozessmodell der Eigenfertigungsplanung und -steuerung des Aachener PPS-Modells (Abbildung 2.2 in Abschnitt 2.2) Berücksichtigung. Ein ähnliches Problem tritt zu Tage, wenn in der laufenden Periode ein zusätzlicher Auftrag im Produktionsablaufplan berücksichtigt werden muss. Sofern durch Heuristiken und Entscheidungsregeln kein zulässiger Alternativplan ermittelt werden kann, muss ebenfalls eine grundlegende Neuplanung in Erwägung gezogen werden.

• Das geschilderte Problem wird durch den Umstand verschärft, dass das Aachener PPS-Modell für die Losgrößenrechnung, Ressourcenbelegungs- und Reihenfolgeplanung vornehmlich einfache heuristische Verfahren empfiehlt, die Lösungen nach einer fest definierten Vorschrift konstruieren. Diese Verfahren haben den Nachteil, dass sie den Lösungsraum eines Problems nicht systematisch durchsuchen können und für eine gegebene Eingabe lediglich eine Lösung generieren. Vor diesem Hintergrund bieten sie lediglich einen geringen Handlungsspielraum, wenn eine vorgeschlagene Lösung nicht den Planungsanforderungen entspricht.

Die zu entwickelnde Methode zum Einsatz von RL-Verfahren für die Produktionsablaufplanung soll eine Ergänzung zum etablierten Aachener PPS-Modell darstellen. Zu diesem Zweck soll die Methode Lösungen für die geschilderten Defizite anbieten. Konkret soll sie die Produktionsablaufplanung unter Berücksichtigung eines dynamischen stochastischen Auftragshorizonts sowie enger Zeitfenster für die Entscheidungsfindung begünstigen. Vor diesem Hintergrund werden die folgenden Anforderungen (A) an die zu entwickelnde Methode postuliert:

• A1: Die Methode soll die Verwendung von RL-trainierten Agenten für die Produktionsablaufplanung beschreiben.

• A2: Die Methode soll die Konzeption und Implementierung von RL-Verfahren für die Produktionsablaufplanung beschreiben.

• A3: Die Methode soll die Verwendung von RL-trainierten Agenten in einer Weise anleiten, dass eine echtzeitfähige, datenbasierte und adaptive Produktionsablaufplanung ermöglicht wird. Die Erfüllung dieser Anforderung dient dem Zweck einer Produktionsablaufplanung unter Berücksichtigung eines dynamischen stochastischen Auftragshorizonts sowie enger Zeitfenster für die Entscheidungsfindung.

• A4: Beim Einsatz von RL für die Produktionsablaufplanung soll weiterhin der Mensch die letzte Entscheidungsinstanz darstellen. Vor diesem Hintergrund soll die zu entwickelnde Methode erlauben, dass eine RL-basierte Entscheidung durch den Menschen verworfen werden kann. Ferner soll die Methode ein Konzept präsentieren, wie RL-trainierte Agenten zusätzlich von der Expertise menschlicher Planer*innen lernen können.

• A5: Die Methode soll so konzipiert sein, dass sie theoretisch für jedes Problem der Produktionsablaufplanung angewandt werden kann.

• A6: Im Gegensatz zur Produktionsablaufplanung des Aachener PPS-Modells soll die zu entwickelnde Methode die Losbildung, Ressourcenbelegungs- und Reihenfolgeplanung nicht stufenweise, sondern integriert betrachten. Im Fall einer unzulässigen Lösung soll auf diese Weise die Berechnung von alternativen Lösungskandidaten vereinfacht werden.

• A7: Für die Berechnung alternativer Lösungskandidaten ist es notwendig, dass RL-basierte Planungsverfahren, die gemäß der zu entwickelnden Methode konzipiert und implementiert werden, den Lösungsraum eines Problems durchsuchen können.

• A8: Die Methode soll gewährleisten, dass der Einsatz von RL-trainierten Agenten zu einem gewissen Grad auf unterschiedlich große Probleminstanzen skalierbar ist. Konkret soll ein RL-trainierter Agent für eine flexible Anzahl von Aufträgen einsetzbar sein. Hingegen wird auf die Anforderung verzichtet, dass ein RL-trainierter Agent ebenfalls für eine beliebige Anzahl von Produktionsressourcen eingesetzt werden kann. Es wird angenommen, dass über einen mittel- bis langfristigen Planungshorizont die meisten Produktionssysteme über eine konstante Anzahl von Betriebsmitteln verfügen, sodass bei einer Veränderung des Systems ausreichend Zeit bleibt, um einen strukturell angepassten Agenten zu trainieren.

5.2 Von der Produktionsablaufplanung zur agentenbasierten Produktionsablaufsteuerung – Prozessmodell und Funktionsprinzip

Zunächst sei festzustellen, dass die Anforderungen A1, A2 und A3 hohe Synergien zueinander aufweisen. Durch die Konzeption und Implementierung von RL-Verfahren (A1) für das Training und den Einsatz von Agenten (A2) kann eine echtzeitfähige, datenbasierte und adaptive Produktionsablaufplanung realisiert werden (A3). Die agentenbasierte Produktionsablaufplanung ist echtzeitfähig, da der Agent durch ein ML-Modell repräsentiert wird. Im Kern approximiert das ML-Modell eine mathematische Funktion, wodurch ungeachtet der Anzahl von Funktionsvariablen und -parametern eine Ausgabe gewöhnlich innerhalb von einer Sekunde berechnet wird. Diese Aussage wird in Kapitel 6 anhand von einigen Beispielen untermauert. Die agentenbasierte Produktionsablaufplanung ist zudem datenbasiert, weil Entscheidungen stets in Abhängigkeit vom aktuellen Umgebungszustand getroffen werden. Ferner ist die agentenbasierte Produktionsablaufplanung adaptiv, weil Entscheidungen individuell auf den aktuellen Umgebungszustand zugeschnitten sind. Die Eigenschaft der Anpassungsfähigkeit wird insbesondere dadurch untermauert, dass der Agent sich kontinuierlich anhand von beobachteten Zuständen und erhaltenen Belohnungen optimieren kann.

In Anbetracht der dargestellten Eigenschaften erscheint der Begriff der Produktionsablaufplanung nicht mehr geeignet. Vielmehr wird durch den Einsatz RL-trainierter Agenten die Planung von Produktionsabläufen als Steuerungsproblem behandelt. Durch die Anwendung von RL-Verfahren vollzieht die Produktionsablaufplanung einen Wandel zur agentenbasierten Produktionsablaufsteuerung. Die Änderung dieser Betrachtungsweise ist der erste Ansatzpunkt, um eines der Hauptprobleme der konventionellen Produktionsablaufplanung zu lösen. Wie im vorhergehenden Abschnitt geschildert geht diese von einem statischen Auftragshorizont aus. Die Aufträge innerhalb des Horizonts werden als Auftragsliste im Planungsprozess simultan berücksichtigt. Eine Einlastung zusätzlicher Produktionsaufträge, die während des Planungsprozesses nicht miteinbezogen wurden, führt gewöhnlich zu einer Verminderung der Lösungsgüte des ursprünglichen Produktionsablaufplans. Der Verzicht auf eine in sich abgeschlossene Vorplanung auf Basis von Auftragslisten, zu Gunsten einer agentenbasierten Steuerung, die lediglich einzelne Aufträge betrachtet, dient als Grundpfeiler, um eine hochqualitative Produktionsablaufplanung für einen dynamischen stochastischen Auftragshorizont zu realisieren.

Im Folgenden soll zunächst diskutiert werden, wie sich der Prozess der agentenbasierten Produktionsablaufsteuerung im Vergleich zur konventionellen Produktionsablaufplanung gemäß Aachener PPS-Modell gestaltet. Zu diesem Zweck präsentiert Abbildung 5.2 ein entsprechendes Prozessmodell als UML-Aktivitätsdiagramm. Im Gegensatz zur konventionellen Produktionsablaufplanung ist der Ausgangspunkt der agentenbasierten Produktionsablaufsteuerung kein statisches Eigenfertigungsprogramm, sondern eine dynamische Liste mit freigegebenen Aufträgen, die zwischen null und unendlich vielen Aufträgen enthält (Startknoten in Abbildung 5.2). Der in Abbildung 5.2 dargestellte Prozess ist so gestaltet, dass dieser die Anforderungen A5 (Allgemeingültigkeit für die Produktionsablaufplanung) und A6 (Integration von Losbildung, Ressourcenbelegungs- und Reihenfolgeplanung) bestmöglich berücksichtigt.

Abbildung 5.2

Prozess der agentenbasierten Produktionsablaufsteuerung

Um Anforderung A5 Rechnung zu tragen, werden im Folgenden zwei Modelle für die Beschreibung von Produktionsbereichen formuliert, die ebenfalls im Prozess der agentenbasierten Produktionsablaufsteuerung unterschieden werden. Beide Modelle werden in Abbildung 5.3 veranschaulicht. Die erste Produktionsbereichsvariante (Abbildung 5.3 (a) bzw. die rechte Alternative im ersten Entscheidungsknoten in Abbildung 5.2) zeichnet sich dadurch aus, dass jede Produktionsressource durch eine eigene Warteschlange gespeist wird. Sie ist am universellsten einsetzbar, um verschiedene Produktionssysteme (z. B. Fließfertigung, Werkstattfertigung) als Produktionsablaufplanungsproblem zu modellieren (z. B. Flow-Shop und Job-Shop). Für Fließfertigungssysteme und ähnliche Produktionsstrukturen werden die Produktionsressourcen, deren Anzahl flexibel variiert werden kann, als gleichartig betrachtet. Ferner wird das Exklusiv-Oder-Gatter (XOR) vernachlässigt. Somit können beliebig stufige Fertigungssysteme durch Verkettung von Produktionsbereichen der Variante (a) modelliert werden. Hingegen werden für Werkstattfertigungen und verwandte Systeme die Produktionsressourcen als unterschiedlich betrachtet und das Exklusiv-Oder-Gatter berücksichtigt. Durch das Exklusiv-Oder-Gatter wird gewährleistet, dass ein Auftrag jede Produktionsressource beliebig oft besuchen kann. Auf diese Weise sind Fertigungspläne jeglicher Komplexität abbildbar. Hinsichtlich Anforderung A6 erlaubt Variante (a) zumindest eine integrierte Reihenfolgeplanung und Losbildung. Die Integration von Reihenfolgeplanung und Losbildung wird in Abschnitt 5.2.2 detailliert erläutert. Zusätzlich erfordert Variante (a) eine

Abbildung 5.3

Die agentenbasierten Produktionsablaufplanung unterscheidet zwei Modelle zur Abbildung von Produktionsbereichen, und zwar Produktionsbereiche mit (a) lokalen Warteschlangen für jede Produktionsressource und (b) zentraler Warteschlange für alle Produktionsressourcen

separate Ressourcenbelegungsplanung. Immer dann, wenn ein neuer Auftrag in den Produktionsbereich eintritt, entscheidet ein Agent über dessen Allokation zu einer Produktionsressource. Vor diesem Hintergrund erfordert eine rein agentenbasierte Produktionsablaufsteuerung in Variante (a) mindestens zwei Agenten, wobei ein Agent die Allokation und ein weiterer Agent die Sequenzierung von Aufträgen verantwortet. Ferner ist es möglich, jedoch methodisch nicht zwingend erforderlich, dass für jede Produktionsressource ein eigener Agent angelernt wird, der für die Reihenfolgebildung der jeweils vorgelagerten Warteschlange verantwortlich ist.

In der zweiten Produktionsbereichsvariante (Abbildung 5.3 (b) bzw. die untere Alternative im ersten Entscheidungsknoten in Abbildung 5.2) werden alle Produktionsressourcen durch eine zentrale Warteschlange gespeist. Variante (b) eignet sich, um Parallel-Maschinen-Umgebungen und einzelne Stufen von Fließfertigungssystemen zu modellieren, in welchen alle stationären Ressourcen durch eine gemeinsame Warteschlange bedient werden. Ferner eignet sich die Variante für die Modellierung einzelner Fertigungszentren mit mehreren Bearbeitungskapazitäten. Variante (b) erlaubt eine ganzheitliche Produktionsablaufsteuerung mit lediglich einem Agenten. Konkret kann auf eine explizite Ressourcenbelegungsplanung verzichtet werden, sodass lediglich ein Agent notwendig ist, der die Reihenfolge- und Losbildung steuert. Zu jedem Zeitpunkt, wenn eine Bearbeitungskapazität verfügbar ist, entscheidet der Agent, welcher Auftrag als nächstes auf der Produktionsressource bearbeitet wird. Hieraus resultiert eine implizite ereignisgesteuerte Ressourcenbelegungsplanung.

Die Modelle der Produktionsbereiche (a) und (b) können flexibel miteinander kombiniert und verkettet werden, um Fabriksysteme jeglicher Art abzubilden. In Abhängigkeit von der Art des Produktionsbereichs, der jeweiligen Anzahl enthaltener Produktionsressourcen, der Eigenschaften der Produktionsressourcen und der geltenden lokalen Optimierungskriterien ist für jeden Produktionsbereich das Training und die Integration eigener Agenten notwendig. Der Prozess der Produktionsablaufsteuerung endet, sobald der Unterprozess der agentenbasierten Reihenfolgeplanung und Losbildung für alle Produktionsressourcen abgeschlossen ist. Im Folgenden sollen die Unterprozesse »Agentenbasierte Ressourcenbelegungsplanung« und »Agentenbasierte Reihenfolgeplanung und Losbildung« näher beleuchtet werden.

5.2.1 Agentenbasierte Ressourcenbelegungsplanung

Im Rahmen der agentenbasierten Ressourcenbelegungsplanung werden freigegebene Aufträge Produktionsressourcen zugewiesen. Abbildung 5.4 präsentiert das Prozessmodell der agentenbasierten Ressourcenbelegungsplanung als UML-Aktivitätsdiagramm.

Der Prozess wird nur dann aufgerufen, sofern der Agent die Produktionsabläufe für einen Bereich steuert, in dem jede Produktionsressource durch eine eigene lokale Warteschlange bedient wird. In diesem Fall wird der Prozess immer dann initiiert, sobald ein neuer Auftrag freigegeben wird und dann für jeden nichtallozierten Auftrag in der freigegebenen Auftragsliste wiederholt. Die Wiederholung des Prozessablaufs für nichtallozierte Aufträge ist insbesondere dann relevant, wenn sich das Produktionssystem zu Beginn in einem nichteingeschwungenen Zustand befindet, sodass eine initiale Belegung erforderlich ist. Im ersten Schritt beobachtet der Agent den nächsten nichtallozierten Auftrag und schlägt darauffolgend eine Entscheidung vor, welcher Produktionsressource der Auftrag zugewiesen werden soll. Die Art und Weise, wie der Agent eine Ressourcenbelegungsentscheidung ermittelt, wird im Rahmen von Abschnitt 5.3.2.1 detailliert beschrieben.

Im nächsten Schritt erfolgt eine Evaluation, ob die vorgeschlagene Agentenentscheidung den Anforderungen der Produktion entspricht. Die Evaluation wird im besten Fall auf Basis menschlicher Expertise durchgeführt. In Anbetracht dessen, dass die agentenbasierte Produktionsablaufsteuerung echtzeitfähig sein soll (Anforderung A3), muss der Evaluationsprozess durch den Menschen so einfach und effizient wie möglich gestaltet sein. Für die Implementierung einer agentenbasierten Produktionsablaufsteuerung in einem realen System empfiehlt sich eine lediglich implizite Evaluation durch den Menschen. Ein mögliches Realisierungskonzept umfasst die Installation eines Sensorsystems, das erfasst, ob der Mensch den aktuell betrachteten Auftrag derjenigen Produktionsressource zuweist, die ebenfalls durch den Agenten vorgeschlagen wurde, oder ob stattdessen eine alternative Ressource ausgewählt wird. Das skizzierte Konzept funktioniert sowohl in Situationen, in denen der Agent qualitativ schlechte Entscheidungen trifft, als auch in Situationen, in welchen der Agent gänzlich unzulässige Entscheidungen fällt. Es dient insbesondere der Erfüllung von Anforderung A4 (Mensch als letzte Planungsinstanz).

Hingegen ist in hochautomatisierten Produktionssystemen, in welchen Ablaufentscheidungen in sekündlichen Intervallen getroffen werden, eine Evaluation durch den Menschen nicht zweckmäßig. Stattdessen kann eine automatisierte Evaluation von Agentenentscheidungen mithilfe von Simulation realisiert werden. Zu diesem Zweck bietet es sich an, das reale Produktionssystem mit einem digitalen Zwilling zu verknüpfen. Ausgehend von der aktuellen Liste freigegebener Aufträge sowie der aktuellen Belegung von Warteschlangen und Produktionsressourcen kann die Lösungsgüte des Agenten anhand von Leistungskennzahlen prognostiziert werden. Die Leistungskennzahlen werden ab dem gegenwärtigen Zeitpunkt über eine bestimmte Produktionsperiode berechnet. Als Leistungskennzahlen eignen sich u. a. die in Abschnitt 2.3.1.3 gelisteten Zielfunktionen. Sofern anhand der Leistungskennzahlen die Agentenentscheidung als unzulässig bewertet wird, kann mithilfe heuristischer Verfahren der Auftrag einer alternativen Produktionsressource in Echtzeit zugeordnet werden.

Abbildung 5.4

Prozess der agentenbasierten Ressourcenbelegungsplanung

Durch die Auswahl einer alternativen Produktionsressource entsteht ein Delta zwischen der durch den Agenten empfohlenen und der tatsächlichen Ressourcenbelegungsentscheidung. Dieses Delta wird als Lernsignal verwendet, um mittels überwachten Lernens die Entscheidungspolitik des Agenten zu optimieren. Auf diese Weise wird gewährleistet, dass der zweite Teil von Anforderung A4 (Agent kann von menschlicher Expertise oder aus heuristischen Entscheidungen lernen) durch die Methode berücksichtigt wird. Der beobachtete Auftrag wird nun in die Warteschlange derjenigen Produktionsressource transferiert, die entweder durch den Agenten oder – im Fall einer unzulässigen Agentenentscheidung – manuell bzw. heuristisch zugewiesen wurde.

Ungeachtet der (Un-)Zulässigkeit der getroffenen Agentenentscheidung wird die tatsächliche Allokation des Auftrags zu einer Produktionsressource durch eine Belohnungsfunktion bewertet. Die Belohnungsfunktion dient der Generierung von Lernsignalen für die Durchführung von RL-Trainingsschritten. Falls der Auftrag einer anderen als der durch den Agenten empfohlenen Produktionsressource zugewiesen wurde, dient die Belohnungsfunktion zusätzlich als Metrik, um die Lösungsgüte der durch den Menschen oder durch die Heuristik getroffene Entscheidungsalternative zu bewerten. Der negative Einfluss fehlerhafter Alternativentscheidungen auf das Agententraining kann auf diese Weise reduziert werden. Das Prozessmodell nimmt an, dass für die Berechnung von Belohnungen entweder Statistiken zur Ressourcenbelastung (z. B. verbleibende Arbeitslast in den Warteschlangen vor den Produktionsressourcen, Gleichmäßigkeit der Verteilung der Arbeitslast, Anzahl wartender Aufträge, u. v. m.) oder fertigstellungszeitbasierte Kennzahlen allozierter Aufträge (z. B. Durchlaufzeit oder Verspätung des Auftrags) zugrunde gelegt werden. Im ersten Fall kann die Belohnung unmittelbar nach der Ressourcenbelegungsentscheidung berechnet und der Agent RL-basiert aktualisiert werden. Im zweiten Fall muss der Agent für unbestimmte Zeit warten, bis der Auftrag im Prozess der agentenbasierten Reihenfolgeplanung und Losbildung ausgewählt und auf der entsprechenden Produktionsressource bearbeitet wurde. Erst dann kann der wahre Fertigstellungszeitpunkt zurückgemeldet und die entsprechende Belohnung berechnet werden. In der Zwischenzeit werden verbleibende freigegebene Aufträge auf die Produktionsressourcen verteilt. Sowohl die Berechnung von Belohnungen als auch die RL-basierte Aktualisierung des Agenten finden somit zeitverzögert und asynchron zur eigentlichen Ressourcenbelegungsplanung statt.

Der Prozess terminiert, sobald alle Aufträge alloziert wurden. Sofern Belohnungen auf Fertigstellungszeitpunkten basieren, gilt die Ermittlung aller Fertigstellungszeitpunkte als zusätzliches Terminationskriterium.

5.2.2 Agentenbasierte Reihenfolgeplanung und Losbildung

Die agentenbasierte Reihenfolgeplanung und Losbildung entscheidet, in welcher Reihenfolge Aufträge in einer Warteschlange auf einer Produktionsressource bearbeitet werden. Sofern die Nebenbedingung existiert, dass Produktionsressourcen für unterschiedliche Auftragsfamilien gerüstet werden müssen, folgt aus der expliziten Auswahl von Aufträgen eine implizite Steuerung der Losbildung. Immer dann, wenn ein Auftrag zur Bearbeitung ausgewählt wird, dessen Familie nicht der aktuellen Rüstung der Produktionsressource entspricht, muss die Ressource umgerüstet werden. Dieses Ereignis führt gleichzeitig dazu, dass das alte Produktionslos abgeschlossen und ein neues Produktionslos gebildet wird. Wird hingegen ein Auftrag gewählt, dessen Familie mit der aktuellen Ressourcenrüstung übereinstimmt, so wird das aktuelle Produktionslos fortgeführt und um einen weiteren Auftrag ergänzt. Abbildung 5.5 illustriert den Prozess der agentenbasierten Reihenfolgeplanung und Losbildung als UML-Aktivitätsdiagramm. Der Prozess wird für jede stationäre Ressource des betrachteten Produktionsbereichs instanziiert. Eine Prozessinstanz wird solange ausgeführt, solange sich Aufträge in der zugehörigen Warteschlange befinden. Die Warteschlange der Produktionsressource bildet zugleich den Startknoten im Prozess. Der Agent entscheidet zunächst, welcher Auftrag als nächstes auf der Produktionsressource bearbeitet wird. Um zu gewährleisten, dass der angelernte Agent für die Sequenzierung einer beliebigen Anzahl von Aufträgen eingesetzt werden kann (Anforderung A8), werden im Rahmen dieser Arbeit drei unterschiedliche Ansätze zur Auswahl von Aufträgen präsentiert. Zum einen kann die Auswahl direkt erfolgen, indem die Aufträge in der vorgelagerten Warteschlange durch den Agenten immer dann priorisiert werden, sobald eine Produktionsressource verfügbar wird. Darauffolgend wird der Auftrag mit der maximalen Priorität gewählt. In der zweiten Variante werden Aufträge ebenfalls priorisiert, jedoch nur einmalig und zu dem Zeitpunkt, zu welchem sie in den jeweiligen Produktionsbereich eintreten. Der Auftrag wird anschließend gemäß seiner Priorität an der entsprechenden Stelle in der Sequenz eingefügt. In beiden Varianten wird die Sequenzierung von Aufträgen durch einen Agenten mit kontinuierlichem Aktionsraum als Regressionsproblem gelöst. Darüber hinaus kann die Auswahl ebenfalls indirekt erfolgen, indem das eigentliche Steuerungsproblem auf die Auswahl einer reihenfolgebildenden Prioritätsregel reduziert wird. Die agentenbasierte Sequenzierung von Aufträgen wird somit als Klassifikationsproblem mit diskretem Aktionsraum modelliert. Abschnitt 5.3.2.2 widmet sich der detaillierten Erklärung und Umsetzung der drei genannten Ansätze.

Abbildung 5.5

Prozess der agentenbasierten Reihenfolgeplanung und Losbildung

Analog zur agentenbasierten Ressourcenbelegungsplanung erfolgt im nächsten Schritt eine Evaluation, ob die vorgeschlagene Agentenentscheidung den Anforderungen der Produktion entspricht. Eine implizite Evaluation durch den Menschen kann realisiert werden, indem sensorisch erfasst wird, ob der durch den Agenten vorgeschlagene Auftrag oder ein alternativer Auftrag ausgewählt wurde. Sofern ein alternativer Auftrag ausgewählt wurde, kann der Unterschied zwischen der agentenbasierten und der manuellen bzw. heuristischen Entscheidungsalternative quantifiziert und als Lernsignal rückwärts durch das Agentenmodell propagiert werden. Die Art und Weise der Quantifizierung hängt davon ab, ob die Auftragsauswahl durch Berechnung von Prioritäten oder durch Bestimmung von Prioritätsregeln gesteuert wird. Im ersten Fall entspricht das Lernsignal der Differenz zwischen der maximal möglichen Priorität und der Priorität des alternativ gewählten Auftrags. Wenn die agentenbasierte Reihenfolgebildung mithilfe von Prioritätsregeln gesteuert wird, muss zunächst ermittelt werden, welche Prioritätsregel am besten den alternativ gewählten Auftrag widerspiegelt. Für die Berechnung des Lernsignals wird darauffolgend ein alternativer Ausgabevektor konstruiert, der auf alle auswählbaren Prioritätsregeln abbildet. Jedes Element des alternativen Ausgabevektors besitzt einen Wert gleich null, ausgenommen des Elements, welches die Prioritätsregel des alternativ gewählten Auftrags widerspiegelt und demzufolge einen Wert von eins besitzt. Um auf die Prioritätsregel des alternativen Auftrags zu schließen, können diverse Auftragseigenschaften herangezogen werden, z. B. dessen Fertigstellungsfrist, Produktfamilie oder Bearbeitungszeiten. Von der Betrachtung ausgenommen ist diejenige Eigenschaft, die von der durch den Agenten ausgewählten Prioritätsregel herangezogen wurde. Hierdurch wird gewährleistet, dass eine andere Prioritätsregel identifiziert wird als diejenige, die durch den Agenten ausgewählt wurde. Ferner wird die am stärksten ausgeprägte Eigenschaft für die Bestimmung einer alternativen Prioritätsregel herangezogen. Der Grad der Ausprägung einer Auftragseigenschaft kann bspw. durch einen Vergleich mit den anderen Aufträgen in der Warteschlange beurteilt werden.

Zum besseren Verständnis wird der Ansatz am folgenden Beispiel erläutert. Das betrachtete System ist ein Ein-Maschinen-Problem zum Zeitpunkt $t = 0$, in welchem die Bearbeitungsreihenfolge durch die agentenbasierte Auswahl von Prioritätsregeln gesteuert wird. Der Agent kann zwischen den Regeln [SPT, LPT, EDD, LST] entscheiden (siehe Abschnitt 2.3.3.2 zu deren Bedeutung und Funktionsweise), wobei die Elemente des Ausgabevektors den vier Prioritätsregeln in derselben Reihenfolge zugeordnet sind. In $t = 0$ gibt der Agent den Vektor $\left[ {0{,}2~,~0{,}3~,~0{,}4~,~0{,}1} \right]$ aus. Da das Vektorelement mit dem Wert $0,4$ das Maximum darstellt, entscheidet sich der Agent für die Anwendung der EDD-Prioritätsregel. Hieraus folgt, dass die Bearbeitung des Auftrags mit der geringsten Fertigstellungsfrist empfohlen wird. Dieser Auftrag wird folgend als $j = 1$ bezeichnet. Der Auftrag $j = 1$ besitzt eine Fertigstellungsfrist von $d_{1} = 20$ und eine Bearbeitungszeit von $o_{1} = 3$. Entgegen der Agentenentscheidung wird jedoch Auftrag $j = 2$ als nächstes für die Bearbeitung ausgewählt, der eine Fertigstellungsfrist von $d_{2} = 21$ und eine Bearbeitungszeit von $o_{2} = 17$ besitzt. Für die Identifikation einer alternativen Prioritätsregel scheidet alleinig die Fertigstellungsfrist $d$ als Eigenschaft aus, da der ursprüngliche Auftrag auf Basis der EDD-Prioritätsregel gewählt wurde. Die zu vergleichenden Eigenschaften sind die Bearbeitungszeiten $o_{1}$ und $o_{2}$, die von den Prioritätsregeln SPT und LPT für die Sequenzierung von Aufträgen als Vergleichskriterium herangezogen werden, sowie die Schlupfzeiten $(d_{1} - o_{1}$) und $\left( {d_{2} - o_{2} } \right)$, die von der LST-Prioritätsregel für die Reihenfolgebildung zugrunde gelegt werden. Es ist auszuschließen, dass sich für den alternativ ausgewählten Auftrag $j = 2$ aufgrund der SPT-Prioritätsregel entschieden wurde, da $j = 2$ eine geringere Bearbeitungszeit als der alternativ ausgewählte Auftrag $j = 1$ besitzt. Als alternative Prioritätsregeln verbleiben somit nur noch LPT und LST. Im nächsten Schritt werden die Bearbeitungszeit und die Schlupfzeit des alternativ gewählten Auftrags mit allen Aufträgen in der vorgelagerten Warteschlange verglichen. Hierbei stellt sich heraus, dass der alternativ ausgewählte Auftrag die drittlängste Bearbeitungszeit und die zweitkürzeste Schlupfzeit unter allen wartenden Aufträgen besitzt. Da somit die Schlupfzeit des alternativ ausgewählten Auftrags stärker ausgeprägt ist als dessen Bearbeitungszeit, wird die Prioritätsregel LST verwendet, um den Unterschied zwischen der agentenbasierten und der manuell bzw. heuristisch ausgewählten Entscheidungsalternative zu quantifizieren. Der alternative Ausgabevektor lautet somit $\left[ {0,0,0,1} \right]$. Das Lernsignal, welches rückwärts durch das Agentenmodell propagiert wird, resultiert aus der Differenz zwischen dem Ausgabevektor des Agenten $\left[ {0{,}2~,~0{,}3~,~0{,}4~,~0{,}1} \right]$ und dem alternativen Ausgabevektor $\left[ {0,0,0,1} \right]$.

Das Konzept zum Einsatz von überwachtem Lernen für die Berücksichtigung von menschlicher Expertise im Agententraining verhält sich darüber hinaus analog zur agentenbasierten Ressourcenbelegungsplanung. Der agentenbasierte bzw. manuell oder heuristisch ausgewählte Auftrag wird nun auf die Produktionsressource umgelagert. Vor dem Start der Bearbeitung des Auftrags wird überprüft, ob die Produktionsressource für die Bearbeitung die richtige Rüstung besitzt. Zu diesem Zweck wird die Familie des Auftrags mit dem Rüsttypen der Produktionsressource verglichen. Falls Produktfamilie und Rüstung voneinander abweichen, wird die Produktionsressource umgerüstet. Damit einhergehend gilt das aktuelle Produktionslos als abgeschlossen, während der soeben gewählte Auftrag den Start eines neuen Produktionsloses markiert.

Nach der Bearbeitung des Auftrags wird eine Belohnung für den Agenten berechnet. Diese basiert stets auf dem Fertigstellungszeitpunkt des Auftrags. Die Ermittlung und Rückmeldung der Belohnung erfolgt unabhängig davon, ob der Auftrag durch den Agenten oder manuell bzw. heuristisch ausgewählt wurde. Analog zur agentenbasierten Ressourcenbelegungsplanung sollen auf diese Weise sowohl agentenbasierte als auch menschliche Entscheidungen belohnt und bestraft werden können. Darüber hinaus wird der Fertigstellungszeitpunkt des zuletzt gewählten Auftrags an den Prozess »Agentenbasierte Ressourcenbelegungsplanung« zurückgemeldet, sofern dieser zuvor initiiert wurde und dessen Belohnungssystem auf Fertigstellungszeitpunkten von Aufträgen basiert.

In den letzten beiden Prozessschritten wird der Agent für die Reihenfolgeplanung und Losbildung auf Basis der berechneten Belohnung aktualisiert und die Bearbeitungskapazität der betrachteten Produktionsressource freigegeben. Der Prozess terminiert, sobald sich keine weiteren Aufträge in der vorgelagerten Warteschlange befinden. Andernfalls durchläuft der Prozess eine weitere Iteration, sodass der Agent den nächsten Auftrag zur Bearbeitung auf der betrachteten Produktionsressource vorschlägt.

5.3 Projektierung und Entwicklung von agentenbasierten Produktionsablaufsteuerungen

Nachdem im vorhergehenden Abschnitt der Prozess und das Funktionsprinzip der agentenbasierten Produktionsablaufsteuerung hergeleitet wurde, soll im Folgenden ein Vorgehensmodell beschrieben werden, welches die Projektierung und Entwicklung von agentenbasierten Produktionsablaufsteuerungen anleitet. Wie Abbildung 5.6 zeigt, beinhaltet das Vorgehensmodell sieben Schritte. Ausgangspunkt ist ein beliebiges Problem der Produktionsablaufplanung. Das Vorgehensmodell mündet in der Realisierung einer agentenbasierten Produktionsablaufsteuerung. Im weiteren Verlauf sollen die einzelnen Schritten des Vorgehensmodells im Detail dargelegt werden.

Abbildung 5.6

Vorgehensmodell zur Projektierung und Entwicklung von agentenbasierten Produktionsablaufsteuerungen

5.3.1 Entwurf von Agentenumgebungen

Für den Entwurf von Agentenumgebungen ist eine Methode zu wählen, welche die Modellierung von Problemen der Produktionsablaufplanung als MEP erlaubt (siehe Abschnitt 3.3.1). Um eine datengetriebene agentenbasierte Produktionsablaufplanung zu realisieren, muss die Methode ferner beliebig viele und komplexe Informationen in einem Modell berücksichtigen können. Vor diesem Hintergrund eignen sich Modellierungsmethoden, die Produktionsprozesse gemäß ihres Ablaufs, ihrer Struktur, ihrer Informationen und ihrer Dynamik detailgetreu abbilden. Die DES-Methode, deren Grundlagen bereits in Abschnitt 2.3.2.2 dargelegt wurden, erfüllt die genannten Anforderungen und wird in dieser Arbeit für den Entwurf von Agentenumgebungen empfohlen.

Das Ziel dieses Abschnitts ist eine umfassende und generische Darstellung, wie Probleme der Produktionsablaufplanung mithilfe der DES-Methode als Agentenumgebung modelliert werden können. Wie bereits in den theoretischen Grundlagen diskutiert wurde, existieren sowohl grafische als auch sprachliche Beschreibungsformen für DES-Modelle. Für die Erklärung der Modellierung von Agentenumgebungen werden im Folgenden sprachliche Beschreibungsformen zugrunde gelegt, da diese eine algorithmische Darstellung über wiederum grafische Programmablaufpläne begünstigen. Darüber hinaus entsprechen sprachliche Beschreibungsformen einer rein Python-basierten Implementierung von DES-Modellen. Die Implementierung von DES-Modellen in Python ist vorteilhaft, weil die beiden weitverbreitetsten Bibliotheken für Deep Learning »TensorFlow« (Abadi et al. 2016) und »PyTorch« (Brockman et al. 2016) ebenfalls auf Python als Modellierungssprache setzen. Eine rein Python-basierte Implementierung vereinfacht sowohl die Integration von ML- und DES-Modellen als auch den Datenaustausch zwischen den Modellen. Ferner und im Unterschied zu kommerziellen DES-Softwarepaketen sind die beiden bekanntesten Python-Bibliotheken zur Implementierung von DES-Modellen »SimPy« (Matloff 2008) und »Salabim« (van der Ham 2018) kostenfrei verfügbar, quelloffen und somit niedrigschwellig zugänglich.

Konkret sind die folgenden Programmablaufpläne an die Methodik zur Beschreibung von Prozessabläufen in der Modellierungssprache »SIMULA« (Dahl und Nygaard 1966) angelehnt, an der sich ebenfalls der Modellierungsprozess von Salabim orientiert. In SIMULA wird das Verhalten eines jeden Flussobjekts, Quellobjekts (für die Erzeugung von Flussobjekten) und Ressourcenobjekts (für die Bearbeitung von Flussobjekten) durch eine jeweils eigene Prozesslogik beschrieben. Hierdurch wird eine dezentrale agentenbasierte Modellierung begünstigt. Ferner unterstützt SIMULA das zeitbasierte und ereignisbasierte Pausieren von Prozessen. Beim zeitbasierten Pausieren wird eine Ablauflogik für eine definierte Zeitspanne unterbrochen. Hingegen wird beim ereignisbasierten Pausieren eine Ablauflogik für eine unbestimmte Zeitspanne unterbrochen. Der Prozess wird erst dann fortgesetzt, wenn ein bestimmtes Ereignis eintritt, welches durch eine andere Prozesslogik ausgelöst wird. Abbildung 5.7 präsentiert ein umfassendes, generisches Prozessmodell für die Implementierung von Problemen der Produktionsablaufplanung als Agentenumgebung. Das Modell setzt sich aus der Prozesslogik zur Erzeugung von Aufträgen, der Prozesslogik von Aufträgen und der Prozesslogik von Produktionsressourcen zusammen. In den folgenden Abschnitten werden die drei Unterprozesse im Detail beschrieben.

Abbildung 5.7

Aufbau, Struktur und Komponenten des Prozessmodells für die Implementierung von Problemen der Produktionsablaufplanung als Agentenumgebung

5.3.1.1 Modellierung der Erzeugung von Aufträgen

Zunächst wird betrachtet, wie die Erzeugung von Aufträgen als Programmablaufplan formuliert werden kann. In Abhängigkeit von der Charakteristik des betrachteten Produktionssystems existieren zwei verschiedene Varianten zur Modellierung von Auftragserzeugungsprozessen. Beide Varianten werden in Abbildung 5.8 dargestellt. Die Ablauflogik in Abbildung 5.8 (a) geht von einer im Voraus bekannten Liste mit freigegebenen Aufträgen aus. Da die agentenbasierte Produktionsablaufsteuerung (Abbildung 5.2 in Abschnitt 5.2) ebenfalls von einer Liste mit freigegebenen Aufträgen ausgeht, repräsentiert Variante (a) den Standardablauf zur Modellierung von Auftragserzeugungsprozessen. Vor diesem Hintergrund ist Variante (a) ebenfalls stellvertretend in der Gesamtübersicht des Prozessmodells in Abbildung 5.7 dargestellt. Es wird angenommen, dass jedem Auftrag in der Liste freigegebener Aufträge eine Menge von Attributen zugeordnet ist, die zum einen für den Simulationsablauf, zum anderen für die Zustandsbildung für agentenbasierte Produktionsablaufentscheidungen von Bedeutung sind. Typische Auftragsattribute werden in Abschnitt 5.3.1.2 gelistet. Über eine for-Schleife werden alle Aufträge der freigegebenen Liste mit den entsprechenden Attributen initialisiert. Darauffolgend wird die Prozesslogik für null Zeiteinheiten pausiert. Das Pausieren hat keine Bedeutung für die Simulation des Produktionsablaufs, sondern ist als technischer Kniff zu verstehen, der einen korrekten Ablauf des DES-Modells erlaubt. Durch das Pausieren wird ein zusätzliches Ereignis im Ereignisverwalter gesetzt, wodurch zunächst einige Schritte in der Prozesslogik des erstellten Auftrags abgearbeitet werden, bevor die Quelle den nächsten Auftrag produzieren kann. Hierdurch wird gewährleistet, dass der Auftrag die Quelle verlässt und sich in der Warteschlange einer Produktionsressource einreiht, bevor der nächste Auftrag erstellt wird und die Quelle temporär blockiert. Die Auftragserzeugung in Abbildung 5.8 (a) eignet sich insbesondere, um eine initiale Ressourcen- und Warteschlangenbelegung für ein leeres Produktionssystem zu erzeugen.

Abbildung 5.8

Prozess der Erzeugung von Aufträgen als Programmablaufplan unter der Annahme (a) eines (temporär) finiten Auftragshorizonts bzw. (b) eines dynamischen stochastischen Auftragshorizonts

Abbildung 5.8 (b) zeigt ein alternatives Prozessmodell zur Erzeugung von Aufträgen. Der Prozess eignet für die Modellierung eines dynamischen stochastischen Auftragshorizonts, bei welchem weder die genauen Aufträge, noch ihre genauen Ankunftszeitpunkte bekannt sind. Es wird jedoch angenommen, dass alle Aufträge die gleiche Art und Anzahl von Attributen besitzen und nur die Werte der jeweiligen Attribute unterschiedlich sind. Ferner wird angenommen, dass für die zufälligen Werte von Attributen und Zwischenankunftszeiten Wahrscheinlichkeitsverteilungen bekannt sind. Auf Basis dieser Wahrscheinlichkeitsverteilungen generiert das Prozessmodell in Abbildung 5.8 (b) Aufträge in zufälligen Abständen mit zufällig initialisierten Attributen. Die Generierung von Aufträgen wird über eine while-Schleife gesteuert, die nach jedem Auftrag ein bestimmtes Terminationskriterium prüft, bspw. das Überschreiten einer maximalen Anzahl von generierten Aufträgen, eines bestimmten Zeitpunkts, einer bestimmten Systemlast u. v. m. Sobald das Terminationskriterium erfüllt ist, werden keine weiteren Aufträge generiert.

Ungeachtet dessen, welches Prozessmodell für die Erzeugung von Aufträgen Verwendung findet, wird durch die Initialisierung eines Auftrags eine Instanz der Auftragsprozesslogik erstellt und ausgeführt (Schnittstelle »A«). Der Aufbau und Ablauf der Auftragsprozesslogik soll im Folgenden behandelt werden.

5.3.1.2 Modellierung von Aufträgen

Jeder Auftrag, der durch ein Quellobjekt generiert wird, durchläuft eine eigene Instanz einer vordefinierten Prozesslogik. Abbildung 5.9 demonstriert die Prozesslogik für den Fluss von Aufträgen. Der Prozesslogik beschreibt alle Möglichkeiten, wie sich ein Auftrag durch das System bewegen kann, um vollständig bearbeitet zu werden. Der genaue Weg eines Auftrags durch das System, respektive welche Operationen des Auftrags durch welche Produktionsressourcen bearbeitet werden, ist von den jeweiligen Ressourcenbelegungsentscheidungen abhängig. Vor diesem Hintergrund wird an das zu formulierende Auftragsprozessmodell der Anspruch gestellt, dass dieses ausreichend generisch ist, um für eine Vielzahl von Produktionssystemen gültig zu sein. Die Prozesslogik in Abbildung 5.9 erfüllt diese Anforderung, indem eine notwendige Annahme getroffen wird. Diese fordert, dass das betrachtete Produktionssystem in einzelne Produktionsbereiche gemäß Abbildung 5.3 (siehe Abschnitt 5.2) untergliedert werden kann. Darüber hinaus werden zwei vereinfachende Annahmen getroffen, mit der Zielstellung den Untersuchungsbereich der vorliegenden Arbeit zu verfeinern und die Komplexität des Prozessmodells in Abbildung 5.9 zu reduzieren. Die erste vereinfachende Annahme lautet, dass jeder Auftrag alle Produktionsbereiche in einer festen Reihenfolge durchläuft. Die zweite vereinfachende Annahme besagt, dass alle Operationen eines Auftrags in fester Reihenfolge bearbeitet werden. Die Prozesslogik in Abbildung 5.9 eignet sich somit zur Modellierung von allen Problemen der Produktionsablaufplanung, die in Abschnitt 2.3.1.1 gelistet sind. Eine Ausnahme bilden Open-Shop-Probleme, in welchen die Operationen eines Auftrags in beliebiger Reihenfolge durchlaufen werden können. Aus konzeptioneller Sicht kann die vorgestellte Prozesslogik jedoch auf einfache Weise erweitert werden, um ebenfalls Open-Shop-Probleme als Agentenumgebung zu implementieren. Die notwendigen Erweiterungen werden am Ende dieses Abschnitts kurz skizziert. Zunächst soll jedoch auf das Prozessmodell in Abbildung 5.9 genauer eingegangen werden.

Abbildung 5.9

Prozess des Auftragsflusses durch Produktionssysteme als Programmablaufplan

Nachdem ein Auftrag mit vordefinierten oder zufälligen Attributwerten initialisiert wurde (Startknoten), gelangt dieser in den nächsten Produktionsbereich. Tabelle 5.1 listet die wichtigsten Attribute von Aufträgen, die für die Modellierung, Simulation und Optimierung von Problemen der Produktionsablaufplanung relevant sind. Ferner sind die gelisteten Attribute maßgeblich für die Beschreibung von Umgebungszuständen, die ein Agent für die Berechnung von Aktionen analysiert. Die Verarbeitung von Umgebungszuständen zu Produktionsablaufentscheidungen ist Gegenstand von Abschnitt 5.3.2. Sofern der Produktionsbereich eine zentrale Warteschlange besitzt (unterer Ausgang der ersten Verzweigung), reiht sich der Auftrag an deren hinterem Ende ein. Zum Eintrittszeitpunkt des Auftrags kann die Situation auftreten, dass nicht alle Produktionsressourcen belegt sind. Diejenigen Produktionsressourcen, welche keine Aufträge bearbeiten, pausieren ihre Prozesslogik auf unbestimmte Zeit und werden nur durch die Ankunft von neuen Aufträgen reaktiviert. Aktive und inaktive Produktionsressourcen werden in unterschiedlichen Listen gespeichert. Falls Produktionsressourcen bei Warteschlangeneintritt inaktiv sind (linker Ausgang der mittleren linken Verzweigung), sendet die Prozesslogik des Auftrags ein Signal an die erstgelistete inaktive Produktionsressource. Hierdurch wird die Prozesslogik der Produktionsressource fortgeführt und der eingetroffene Auftrag aus der Warteschlange bearbeitet (Schnittstelle »B«). Sofern jedoch die Ressourcen des Produktionsbereichs durch lokale Warteschlangen gespeist werden (rechter Ausgang der ersten Verzweigung), entscheidet zunächst ein sogenannter Allokationsagent, zu welcher Produktionsressource der Auftrag zugewiesen werden soll. Die Art und Weise der Entscheidungsfindung von Allokationsagenten wird in Abschnitt 5.3.2.1 erläutert. Die Berücksichtigung von Agentenentscheidungen im Simulationsmodell wird in Abschnitt 5.3.3.1 für gradientenabhängige bzw. in Abschnitt 5.3.3.2 für gradientenfreie RL-Verfahren gesondert behandelt. Der Auftrag reiht sich daraufhin am hinteren Ende der Warteschlange der zugewiesenen Produktionsressource ein. Wenn die Produktionsressource zum Eintrittszeitpunkt keinen Auftrag bearbeitet und sich keine weiteren Aufträge in der Warteschlange befinden, kann geschlussfolgert werden, dass die Produktionsressource ihre Prozesslogik gegenwärtig pausiert (rechter Ausgang der mittleren rechten Verzweigung). In diesem Fall sendet der Auftrag ein Signal zur Fortführung der Prozesslogik, wodurch dieser von der Produktionsressource zur Bearbeitung aufgenommen wird (Schnittstelle »B«).

Tabelle 5.1 Geläufige Attribute für die Modellierung von Aufträgen

Ungeachtet der Art des Produktionsbereichs pausiert der Auftrag seine Prozesslogik auf unbestimmte Zeit, nachdem dieser eine Warteschlange betritt und u. U. die Prozesslogik einer Produktionsressource reaktiviert. Die Prozesslogik des Auftrags wird wiederum durch eine Produktionsressource reaktiviert, sobald diese die aktuelle Operation am Auftrag bearbeitet hat (Schnittstelle »C«). Wenn weitere Operationen im aktuellen Produktionsbereich bearbeitet werden müssen (rechter Ausgang der vorletzten Verzweigung), wird erneut der Allokationsagent für eine Ressourcenbelegungsentscheidung konsultiert. Sofern im aktuellen Produktionsbereich alle möglichen Operationen durchgeführt wurden (unterer Ausgang der vorletzten Verzweigung), wird geprüft, ob der Auftrag noch weitere Operationen durchlaufen muss. Falls dem so ist (linker Ausgang der letzten Verzweigung), wird der Auftrag in den nächsten Produktionsbereich transferiert. Falls alle Operationen komplettiert wurden (unterer Ausgang der letzten Verzweigung), verlässt der Auftrag die Umgebung und wird in der fortlaufenden Simulation nicht mehr berücksichtigt.

Wie bereits erwähnt kann die geschilderte Logik um einige wenige Elemente erweitert werden, sodass ebenfalls die Modellierung von Open-Shop-Problemen möglich ist. Unter der Annahme, dass eine rein agentenbasierte Produktionsablaufsteuerung realisiert werden soll, sind darüber hinaus zwei weitere Arten von Agenten erforderlich. Der erste zusätzliche Agent entscheidet zunächst, welche Operation des betrachteten Auftrags als nächstes bearbeitet werden soll. Der zweite zusätzliche Agent entscheidet danach, in welchem Produktionsbereich die gewählte Operation bearbeitet werden soll. Im Folgenden würde die Prozesslogik gemäß Abbildung 5.9 durchlaufen werden. Sofern nach der Fertigstellung der gewählten Operation noch weitere Operationen offen sind, erfolgt die Auswahl der nächsten zu bearbeitenden Operation. Bei der daran anschließenden Auswahl des nächsten Produktionsbereichs besteht die Möglichkeit den aktuellen Produktionsbereich beizubehalten.

5.3.1.3 Modellierung von Produktionsressourcen

Ein weiterer entscheidender Aspekt hinsichtlich des Entwurfs von Agentenumgebungen ist die Modellierung von Produktionsressourcen. Abbildung 5.10 präsentiert eine generische Programmlogik für den Prozessablauf von Produktionsressourcen. Im Folgenden soll das Prozessmodell im Detail erläutert werden. Zudem wird anhand von Beispielen aufgezeigt, wie das Prozessmodell erweitert werden kann, um spezifische Restriktionen von unterschiedlichen Problemen der Produktionsablaufplanung zu berücksichtigen.

Die Produktionsressourcen und ihre Prozessmodelle werden im Zuge der Umgebungsinitialisierung instanziiert. Im Rahmen der Instanziierung werden ebenfalls die Attribute der Produktionsressourcen initialisiert. Tabelle 5.2 enthält einige der geläufigsten Attribute für die Modellierung von Produktionsressourcen. Analog zu Tabelle 5.1 dienen viele der gelisteten Attribute ebenfalls der Beschreibung von Umgebungszuständen, welche ein Agent für die Ausgabe von Aktionen vorwärtspropagiert. Einhergehend mit ihrer Instanziierung wird die Prozesslogik einer Produktionsressource automatisch gestartet. Zunächst wird abgefragt, ob die vorgelagerte Warteschlange der Produktionsressource leer ist. Zu Beginn einer Episode ist dies stets zutreffend (unterer Ausgang der ersten Verzweigung), da die Prozesslogik von jeder Produktionsressource ausgeführt wird, bevor der erste Auftrag durch eine Quelle produziert wird. Demzufolge wird die Prozesslogik pausiert, bis sich ein Auftrag in die vorgelagerte Warteschlange einordnet (Schnittstelle »B«). In fortschreitenden Zyklen der Prozesslogik befinden sich gewöhnlich mehrere Aufträge in der vorgelagerten Warteschlange, wodurch das Pausieren übersprungen und mit dem nachfolgenden Schritt fortgefahren wird (linker Ausgang der ersten Verzweigung).

Im Folgenden wird ein sogenannter Sequenzierungsagent für die Auswahl des nächsten zu bearbeitenden Auftrags konsultiert. Die Auswahl des Auftrags erfolgt entweder direkt durch die Priorisierung von Aufträgen oder indirekt durch die Auswahl einer Prioritätsregel. Beide Formulierungsvarianten werden in Abschnitt 5.3.2.2 detailliert beschrieben. Analog zur Allokation von Aufträgen wird für gradientenabhängige bzw. -freie RL-Verfahren die Berücksichtigung von agentenbasierten Sequenzierungsentscheidungen im Simulationsmodell in Abschnitt 5.3.3.1 bzw. 5.3.3.2 gesondert behandelt. Die darauffolgende Verzweigung dient als Beispiel für die Modellierung von problemspezifischen Nebenbedingungen. Es wird geprüft, ob die Familie des ausgewählten Auftrags mit der aktuellen Rüstung der Produktionsressource übereinstimmt. Ist dies nicht der Fall (linker Ausgang der zweiten Verzweigung), muss die Prozesslogik gemäß einer bestimmten Rüstzeit pausiert werden. Die Rüstzeit kann entweder konstant oder reihenfolgeabhängig sein. Im zweiten Fall wird die Rüstzeit aus einer Tabelle ausgelesen, die alle Rüstzeiten zwischen gerüsteten (Zeilen) und zu rüstenden Familien (Spalten) enthält. Auf ähnliche Art und Weise können weitere Restriktionen der Produktionsablaufplanung modelliert werden.

Abbildung 5.10

Prozess von Produktionsressourcen als Programmablaufplan

Tabelle 5.2 Geläufige Attribute für die Modellierung von Produktionsressourcen

Die Modellierung von zusätzlichen mobilen Ressourcen (z. B. Rüst-Kits, Servicekräfte u. v. m.) wäre in der Prozesslogik von Produktionsressourcen noch einfacher zu berücksichtigen. Für jede angeforderte mobile Ressource muss lediglich die Prozesslogik der Produktionsressource für unbestimmte Zeit pausiert werden. Im Gegensatz zur Modellierung von Rüstprozessen ist eine zusätzlich vorgelagerte Verzweigung nicht notwendig. Allerdings erfordert jede mobile Ressourcenart die Definition einer eigenen Prozesslogik, die ihr Verhalten beschreibt. Die Modellierung von mobilen Ressourcen wird in dieser Arbeit nicht explizit betrachtet, folgt aber sehr ähnlichen Prinzipien wie die Prozessmodelle von Aufträgen und Produktionsressourcen. Im Folgenden soll lediglich ein grobes verallgemeinerndes Prozessmodell für mobile Ressourcen umrissen werden, um das Prinzip zu verdeutlichen: Anfragen an mobile Ressourcen werden in einer separaten Warteschlange gepuffert. Die Anfragen werden nach einer bestimmten Sequenzierungslogik (z. B. Prioritätsregeln) oder agentenbasiert (gemäß den Entscheidungen eines zusätzlichen Sequenzierungsagenten) abgearbeitet. Für die Bearbeitung der Anfragen können zusätzliche Zeiten anfallen, z. B. für den Transport der mobilen Ressourcen und für weitere Hilfsoperationen. Sobald eine mobile Ressource ihren Bestimmungsort erreicht hat, sendet sie ein Signal an die Produktionsressource, sodass diese ihre Prozesslogik fortsetzt. Währenddessen wird die Prozesslogik der mobilen Ressource pausiert, bis die bediente Produktionsressource zurückmeldet, dass alle Operationen, für welche die mobile Ressource angefordert wurde, abgeschlossen sind und diese nicht mehr benötigt wird. Die Rückmeldung reaktiviert die Prozesslogik der mobilen Ressource. Sofern weitere Anfragen offen sind, werden diese abgearbeitet. Andernfalls wird die Prozesslogik der mobilen Ressource ein weiteres Mal auf unbestimmte Zeit pausiert, bis sich neue Anfragen in die entsprechende Warteschlange einreihen. Nach diesem kurzen Exkurs zur Modellierung von zusätzlichen Planungsrestriktionen sowie des Verhaltens von mobilen Ressourcen, soll nun mit der Beschreibung der Prozesslogik in Abbildung 5.10 fortgefahren werden.

Die Bearbeitung von Auftragsoperationen wird durch zeitbasiertes Pausieren der Prozesslogik realisiert. Die Unterbrechungsdauer ist abhängig von der Bearbeitungszeit der aktuellen Operation und u. U. von weiteren Größen (z. B. Leistung der Produktionsressource, siehe Tabelle 5.2). Nach Fertigstellung der Operation wird die Prozesslogik des ausgewählten Auftrags fortgesetzt (Schnittstelle »C«), wodurch dieser die Produktionsressource freigibt. Bevor die Prozesslogik der Produktionsressource in den nächsten Zyklus übergeht, wird überprüft, ob ein Terminationskriterium eingetreten ist, das den Prozess vollständig beendet. Als Terminationskriterium kann bspw. geprüft werden, ob der zuletzt bearbeitete Auftrag der letzte Auftrag im System war und keine weiteren Aufträge von der Quelle produziert werden. Ferner kann der Abbruch der Prozesslogik von der Überschreitung einer bestimmten Zeitschranke abhängig gemacht werden.

5.3.2 Definition von maschinellen Lernaufgaben und Gestaltung von Agenten

Die Prozessmodelle für Aufträge (Abbildung 5.9) und Produktionsressourcen (Abbildung 5.10) in Abschnitt 5.3.1 beinhalten lediglich symbolische Darstellungen für agentenbasierte Allokations- bzw. Sequenzierungsentscheidungen. Die Zielstellung des folgenden Abschnitts ist zunächst eine präzise Darstellung, wie Allokations- und Sequenzierungsentscheidungen als maschinelle Lernaufgaben (ML-Aufgaben) zu formulieren und die entsprechenden Agenten zu gestalten sind. Zu diesem Zweck widmet sich Abschnitt 5.3.2.1 der Formulierung von Allokationsproblemen für die Ressourcenbelegungsplanung als ML-Aufgabe. Im Anschluss werden in Abschnitt 5.3.2.2 drei Varianten zur Formulierung von Sequenzierungsproblemen, zum Zweck der Reihenfolgeplanung und indirekten Losbildung, als ML-Aufgaben diskutiert.

Die in den Teilabschnitten 5.3.2.1 und 5.3.2.2 vorgestellten Konzepte verwenden teils gleiche, teils verschiedenartige Informationen von Aufträgen und Produktionsressourcen, um Zustände zum Zweck der Aktionsermittlung durch Vorwärtspropagierung zu bilden. Ohne Anspruch auf Vollständigkeit listet Tabelle 5.3 relevante Informationen von Aufträgen und Produktionsressourcen auf, die für die Bildung von Zuständen in den verschiedenen Formulierungsvarianten verwendet werden. Bei den gelisteten Zustandsdaten handelt es sich zu großen Teilen um Untermengen der Attribute von Aufträgen und Produktionsressourcen aus Tabelle 5.1 bzw. Tabelle 5.2. Als Zustandsdaten nicht berücksichtigt werden solche Attribute, die entweder keinen Bezug zu Allokations- und Sequenzierungsproblemen haben (z. B. die Freigabezeit, welche die Ankunft eines Auftrags im betrachteten System bestimmt) oder für die alternative Attribute mit einer höheren Informationsdichte existieren (z. B. kann die Liste bereits fertiggestellter bzw. noch auszuführender Operationen eines Auftrags über den zeitabhängigen Fertigstellungsgrad aggregiert berücksichtigt werden). Ferner enthält Tabelle 5.3 einige zusätzliche Zustandsdaten, die zur Laufzeit der Umgebung und auf Basis weiterer Attribute berechnet werden (z. B. die Ausfallwahrscheinlichkeit einer Produktionsressource basierend auf dem Attribut »Verfügbarkeit« oder diverse Warteschlangenstatistiken). Bei den Zustandsdaten handelt es sich entweder um normierte oder standardisierte Gleitkommazahlen oder um binär kodierte Werte. Die Standardisierung bzw. Normierung dient insbesondere dem Zweck, dass verschieden ausgeprägte Zustandsdaten auf einen Wertebereich skaliert und somit vergleichbar gemacht werden. Im Fall einer binären Kodierung (bspw. für Auftrags- oder Rüstfamilien) wird das 1-aus-n-Kodierungsverfahren verwendet, wobei $n$ der Anzahl von Auftrags- bzw. Rüstfamilien entspricht. Das 1-aus-n-Kodierungsverfahren bildet einen diskreten Wertebereich über einen binären Vektor ab. Die Länge des Vektors entspricht der Anzahl von Werten. Das Vektorelement, das den zu kodierenden Wert repräsentiert, nimmt den Wert eins an. Die restlichen Vektorelemente besitzen den Wert null.

Tabelle 5.3 Relevante Informationen von Aufträgen und Produktionsressourcen zur Beschreibung von Zuständen für verschiedene Formulierungen von Allokations- und Sequenzierungsproblemen als maschinelle Lernaufgaben

5.3.2.1 Formulierung von Allokationsproblemen für die Ressourcenbelegungsplanung als maschinelle Lernaufgabe

Für die Allokation von Aufträgen zu Produktionsressourcen wird jede Aktion des Agenten mit einer Ressource des betrachteten Produktionsbereichs assoziiert. Sofern der Agent durch ein KNN repräsentiert wird, entspricht die Anzahl der Ausgabeneuronen der Anzahl von Produktionsressourcen des betrachteten Produktionsbereichs. Aus allgemeiner ML-Perspektive resultiert hieraus ein Klassifikationsproblem und aus spezifischer RL-Perspektive ein Entscheidungsproblem mit diskreten Aktionsraum. Abbildung 5.11 veranschaulicht den Einsatz von Agenten für die Allokation von Aufträgen anhand eines Beispiels.

Abbildung 5.11

Formulierung von Allokationsproblemen als maschinelle Lernaufgabe. (In Anlehnung an Lang et al. 2021a)

Jedes Mal, wenn ein Auftrag einer Produktionsressource zuzuordnen ist, werden verschiedene Informationen aus der Umgebung als Zustand zusammengefasst. Der Zustand wird vorwärts durch das Agentenmodell propagiert, um die Auswahlwahrscheinlichkeiten für alle Produktionsressourcen des Bereichs zu ermitteln. Im Beispiel von Abbildung 5.11 weist das zweite Ausgabeneuron die größte Anregung mit einem Wert von 0,58 auf. Auftrag $A$ würde somit der zweiten Produktionsressource zugewiesen werden, sofern der Entscheidungspolitik des Agenten Folge geleistet wird.

Für die Zustandsbildung sind sowohl Informationen des Auftrags als auch Attribute der Produktionsressourcen und ihrer vorgelagerten Warteschlangen relevant. In Abbildung 5.11 wird die Netzeingabe des Agenten stark aggregiert dargestellt. Jedes Eingabeneuron ist lediglich repräsentativ für eine beliebige Anzahl von Attributen des Auftrags bzw. der jeweiligen Produktionsressource und ihrer Warteschlange. Einige relevante Informationen für die Bildung von Zuständen können Tabelle 5.3 entnommen werden. Die momentanen Rüstungen der Produktionsressourcen werden nicht als Zustandsinformationen für Allokationsentscheidungen berücksichtigt, weil diese erst zu dem Zeitpunkt relevant sind, zu welchem der Auftrag für die Bearbeitung auf der Produktionsressource ausgewählt wird. Ferner ist es möglich, dass sich die Rüstung einer Produktionsressource nach dem Zeitpunkt der Allokation noch mehrfach ändert, bevor der allozierte Auftrag bearbeitet wird, weil zuvor andere Aufträge mit unterschiedlichen Familien durch den nachgelagerten Sequenzierungsagenten zur Bearbeitung ausgewählt werden.

Aus der in Abbildung 5.11 illustrierten Formulierung von Allokationsproblemen folgt, dass immer dann ein neuer Agent mit angepasster Ausgabeschicht von Grund auf neu angelernt werden muss, sobald sich die Anzahl der Produktionsressourcen verändert. Eine bessere Skalierbarkeit könnte dadurch realisiert werden, indem die Ausgabeneuronen des Agenten nicht mit den Produktionsressourcen, sondern mit Allokationsregeln assoziiert werden. Eine Formulierung für eine ähnliche Lernaufgabe, welche die Sequenzierung von Aufträgen mithilfe von Prioritätsregeln adressiert, wird in Abschnitt 5.3.2.2 diskutiert. Im Rahmen dieser Arbeit wird jedoch argumentiert, dass eine derartige Skalierbarkeit für die Ressourcenbelegungsplanung nicht notwendig ist, da sich die Dimensionierung von Produktionssystemen der taktischen bis strategischen Planungsebene zuordnet. Somit ist die Annahme legitim, dass die Anzahl von Produktionsressourcen über eine Monate bis Jahre andauernde Planungsperiode konstant bleibt, wodurch das Risiko und der Aufwand für ein erneutes Training vernachlässigbar ist.

5.3.2.2 Formulierung von Sequenzierungsproblemen für die Reihenfolgeplanung und Losbildung als maschinelle Lernaufgabe

Im Gegensatz zu Allokationsproblemen existieren mindestens drei skalierbare (Anforderung A8) Varianten für die Formulierung von Sequenzierungsproblemen als ML-Aufgabe. Alle drei Varianten können für eine flexible Anzahl von Aufträgen eingesetzt werden, weisen jedoch unterschiedliche Vor- und Nachteile auf. Sowohl in der ersten als auch in der zweiten Variante werden Sequenzierungsprobleme aus allgemeiner ML-Sicht als Regressionsproblem bzw. aus spezifischer RL-Sicht als Entscheidungsproblem mit kontinuierlichem Aktionsraum betrachtet. Das bedeutet, dass der Agent lediglich ein Ausgabeneuron besitzt, sofern es sich bei dem Agenten um ein KNN handelt. Die Ausgabe des Agenten wird als Priorität des jeweiligen Auftrags interpretiert.

In der ersten Variante ermittelt der Agent jedes Mal, wenn die betrachtete Produktionsressource verfügbar wird, eine neue Priorität für jeden Auftrag in der vorgelagerten Warteschlange. Sofern die Entscheidungspolitik des Agenten Anwendung findet, wird derjenige Auftrag gewählt, der die maximale Priorität aufweist. Abbildung 5.12 illustriert das Konzept anhand eines Beispiels. Für die Berechnung von Aktionen kann der Agent entweder über die Warteschlange iterieren und die enthaltenen Aufträge einzeln und nacheinander priorisieren oder alternativ (und wie ebenfalls in Abbildung 5.12 dargestellt) eine vektorisierte Priorisierung vornehmen. Eine vektorisierte Priorisierung führt zu derselben Ausgabe wie eine iterative Priorisierung, ist jedoch laufzeiteffizienter, da weniger Berechnungsschritte notwendig sind. Bei der vektorisierten Priorisierung wird zunächst ein Los von Zuständen gebildet. Die Losgröße entspricht der Anzahl von Aufträgen in der betrachteten Warteschlange. Jeder Zustand setzt sich aus den individuellen Zustandsdaten des jeweiligen Auftrags zusammen sowie aus den Zustandsdaten der betrachteten Produktionsressource, wobei Letztere zum Entscheidungszeitpunkt für alle Aufträge identisch sind. Zu diesem Zweck wird der Zustandsvektor der Produktionsressource entsprechend der Anzahl von Aufträgen in der Warteschlange kopiert und an die jeweiligen Zustandsvektoren der Aufträge angehängt. Wird das Zustandslos vorwärts durch den Agenten propagiert, ist dessen Ausgabe wiederum ein Los von Aktionen, die als Prioritäten der Aufträge interpretiert werden. Durch Ermittlung des Indizes mit der maximalen Priorität kann nun auf den nächsten zu bearbeitenden Auftrag in der betrachteten Warteschlange geschlossen werden.

Abbildung 5.12

Erste Variante zur Formulierung von Sequenzierungsproblemen als maschinelle Lernaufgabe – Auswahl des nächsten zu produzierenden Auftrags mittels Priorisierung. (In Anlehnung an Lang et al. 2021a)

Wie bereits eingangs erwähnt, werden in der zweiten Variante ebenfalls Aufträge mithilfe eines Agenten priorisiert. Im Unterschied zur ersten Variante findet die Priorisierung nur einmalig und nicht jedes Mal statt, wenn die betrachtete Produktionsressource verfügbar und ein neuer Auftrag gewählt wird. Konkret wird ein Auftrag immer genau einmal nach dessen Allokation zu einer Produktionsressource priorisiert. Der Auftrag wird an der Stelle in der Sequenz eingefügt, an der die Priorität des vorherigen Auftrags größer oder gleich und die des nachfolgenden Auftrags niedriger als die eigene Priorität ist. Auf diese Weise konstruiert der Agent iterativ eine Sequenz von Aufträgen, die nach dem FIFO-Prinzip abgearbeitet wird. Die Sequenz kann lediglich durch neu eingehende Aufträge verändert werden, die aufgrund ihrer Priorisierung zwischen bestimmten Aufträgen in der bestehenden Sequenz eingefügt werden. Abbildung 5.13 veranschaulicht die Formulierungsvariante anhand eines Beispiels. Für Auftrag $A$ wird eine Priorität von 0,97 ermittelt. Der Auftrag wird somit zwischen Auftrag $A_{1}$ (vorher zu produzierender Auftrag) und $A_{2}$ (nachfolgend zu produzierender Auftrag) eingefügt.

Abbildung 5.13

Zweite Variante zur Formulierung von Sequenzierungsproblemen als maschinelle Lernaufgabe – iterative Konstruktion einer Auftragssequenz durch Priorisierung

Bei der zweiten Variante sind i. d. R. lediglich die Attribute des zu priorisierenden Auftrags für die Zustandsbildung relevant. Aufgrund der iterativen Konstruktion der Sequenz werden fortlaufend neue Aufträge vor und hinter den bereits priorisierten Aufträgen eingefügt, wodurch sich deren Positionen und Bearbeitungsstartzeiten ebenfalls fortlaufend verändern. Demzufolge sind die Attribute von Produktionsressourcen für die Priorisierung von Aufträgen von geringer Bedeutung, da diese sich vom Priorisierungszeitpunkt bis zum Bearbeitungsstartzeitpunkt eines Auftrags noch mehrmals verändern können. Gegebenenfalls kann zumindest die aktuelle Rüstung der Produktionsressource als Zustandsattribut berücksichtigt werden. Für Aufträge, welchen der Agent eine hohe Priorität zuweisen möchte, kann die aktuelle Rüstung der Produktionsressource das entscheidende Kriterium sein, ob der Agent den betrachteten Auftrag auf die erste oder auf eine nachgelagerte Position setzt.

Die dritte Variante zur Formulierung von Sequenzierungsproblemen als ML-Aufgabe unterscheidet sich wesentlich von den ersten beiden vorgestellten Varianten. Die Sequenzierung von Aufträgen erfolgt indirekt, indem der Agent immer dann, wenn eine Produktionsressource verfügbar wird, die nächste anzuwendende Prioritätsregel aus einer fixen Menge von Prioritätsregeln auswählt. Analog zur agentenbasierten Allokation von Aufträgen wird somit die Reihenfolge- und Losbildung als Klassifikationsproblem bzw. als Entscheidungsproblem mit diskreten Aktionsraum behandelt. Abbildung 5.14 veranschaulicht das Prinzip anhand eines Beispiels. Jedes Ausgabeneuron ist einer bestimmten Prioritätsregel zugeordnet. Die Anzahl der Ausgabeneuronen entspricht der Anzahl der auswählbaren Prioritätsregeln. Im Beispiel erfährt das erste Ausgabeneuron mit einem Wert von 0,42 die stärkste Anregung, sodass die erste Prioritätsregel Anwendung findet, sofern der Entscheidungspolitik des Agenten gefolgt wird. Als auswählbare Prioritätsregeln kommen grundsätzlich alle reihenfolgebildenden Prioritätsregeln in Frage, so z. B. die in Abschnitt 2.3.3.2 gelisteten Beispiele. Beim Zusammenstellen der Menge auswählbarer Prioritätsregeln ist das verfolgte Optimierungskriterium zu berücksichtigen. Sofern bspw. die Gesamtdauer des Ablaufplans zu minimieren ist, sollte die Auswahlmenge aus Prioritätsregeln bestehen, welche die Produktionsressourcen bestmöglich auslasten und Nichtproduktivzeiten vermeiden, z. B. SPT und LPT.

Abbildung 5.14

Dritte Variante zur Formulierung von Sequenzierungsproblemen als maschinelle Lernaufgabe – indirekte Auswahl des nächsten zu produzierenden Auftrags mittels agentenbasierter Bestimmung von Prioritätsregeln

Falls die zu optimierende Zielfunktion auf Verspätungskriterien basiert, z. B. auf der Anzahl verspäteter Aufträge oder der Gesamtverspätung über alle Aufträge, sollte die Auswahlmenge aus Prioritätsregeln bestehen, durch welche die Verspätung von Aufträgen reduziert wird, z. B. EDD und LST. Um zu gewährleisten, dass der Ansatz für eine beliebige Anzahl von Aufträgen angewandt werden kann, werden für die Definition von Zuständen Aufträge nicht separat betrachtet. Im Gegensatz zu den ersten beiden Varianten wird ferner kein Zustandslos, sondern lediglich ein einzelner Zustand vorwärts durch den Agenten propagiert, um auf die Auswahl einer Prioritätsregel zu schließen. Um dennoch die Attribute von Aufträgen zu berücksichtigen, empfiehlt es sich, einige Statistiken zu verschiedenen Attributen über alle Aufträge der betrachteten Warteschlange zu bilden. Beispiele für relevante Statistiken sind in Tabelle 5.3 gelistet. Ferner kommen für die Definition von Zuständen Attribute der betrachteten Produktionsressource in Frage, bspw. deren aktuelle Rüstung, Ausfallwahrscheinlichkeit oder Bearbeitungsgeschwindigkeit.

Die ersten beiden Varianten zur Formulierung von Sequenzierungsproblemen besitzen den Vorteil, dass alle in der Warteschlange befindlichen Aufträge, aufgrund ihrer lückenlosen Priorisierung, im Entscheidungsprozess gleichermaßen berücksichtigt werden. Hingegen können in der dritten Variante nur diejenigen Aufträge zur Bearbeitung auf der Produktionsressource ausgewählt werden, die zum Entscheidungszeitpunkt das Auswahlkriterium von mindestens einer möglichen Prioritätsregel am meisten erfüllen.

Die erste Variante hat gegenüber der zweiten Variante den Vorteil, dass die Prioritäten immer augenblicklich zum Entscheidungszeitpunkt und somit gemäß den aktuellen Zustandsinformationen berechnet werden. Ein Nachteil der ersten Formulierungsvariante ist, dass sie zu einem gewissen Grad mit den Eigenschaften eines MEP (siehe Abschnitt 3.3.1) bricht. In einem klassischen MEP wird in einem Zustand $S_{t}$ eine Aktion $A_{t}$ gewählt, aus welcher der Folgezustand $S_{t + 1}$ resultiert. In der ersten Formulierungsvariante wird jedoch zu einem Zeitpunkt $t$ ein Los von Zuständen $S_{t, 1 \ldots n}$ für $n$ Aufträge gebildet, für die $n$ Aktionen $A_{t,1, \ldots ,n}$ berechnet werden. Es wird jedoch nur eine Aktion gewählt, in deren Abhängigkeit die Umgebung in der Zeit voranschreitet. Ungeachtet dessen ist es möglich RL-Algorithmen gemäß der ersten Formulierungsvariante anzuwenden. Gradientenfreie RL-Algorithmen können ohne weitere Komplikationen angewandt werden, da sie die Parameter eines Agenten stochastisch und nicht mit dem TD-Lernverfahren anpassen. Ebenfalls sind gradientenabhängige RL-Algorithmen für die erste Formulierungsvariante anwendbar, müssen jedoch zu diesem Zweck angepasst werden. Transitionen müssen nicht nur einzelne Zustände, sondern vollständige Zustandslose enthalten. Das TD-Lernverfahren muss ebenfalls vektorisiert für Zustands- und Aktionslose implementiert werden. Eine weitere Herausforderung ist die Modellierung der Belohnungsfunktion. Jede Aktion des Agenten, respektive jede vergebene Priorität, muss durch die Belohnungsfunktion bewertet werden, ungeachtet dessen, ob der Auftrag zum Zeitpunkt der Priorisierung zur Bearbeitung ausgewählt wurde oder nicht (hierzu später mehr in Abschnitt 5.3.5.1). Zusammengefasst erfordert die erste Variante zur Formulierung von Sequenzierungsproblemen einen hohen konzeptionellen und implementierungstechnischen Aufwand, sofern sie in Verbindung mit einem gradientenabhängigen RL-Verfahren Anwendung findet.

Die zweite Formulierungsvariante ist von dem geschilderten Problem nicht betroffen, obgleich sie ebenfalls einen Agenten mit kontinuierlichen Aktionsraum zur Priorisierung von Aufträgen verwendet. Der Grund ist, dass Aufträge nur einmal priorisiert werden. Die Belohnung für die Priorisierung wird nicht unmittelbar nach der Priorisierung ermittelt, sondern erst dann, wenn der Auftrag auf der Produktionsressource bearbeitet wurde. Die Berechnung der Aktion und die Vergabe der Belohnung sind somit zeitlich entkoppelt, was mit einem zusätzlichen Implementierungsaufwand für die Verwaltung von Daten im Erfahrungsspeicher einhergeht. Ein Nachteil der zweiten Variante ist, dass lediglich Zustandsdaten von Aufträgen, jedoch keine Zustandsdaten der Produktionsressourcen, auf sinnvolle Weise für die Berechnung von Aktionen berücksichtigt werden können. Wie bereits erläutert, sind die Zustandsdaten von Produktionsressourcen in der zweiten Formulierungsvariante gegenstandslos, da die Priorisierung von Aufträgen und deren Bearbeitung auf der jeweiligen Produktionsressource ebenfalls zeitlich entkoppelt sind.

Die dritte Formulierungsvariante, die auf der Auswahl von Prioritätsregeln basiert, besitzt keinen der geschilderten Nachteile der ersten beiden Varianten. Zum einen erfüllt die dritte Variante alle Eigenschaften eines MEP, zum anderen fließen sowohl Zustandsdaten von Aufträgen als auch von Produktionsressourcen in die Berechnung von Aktionen mit ein. Der offensichtliche Nachteil ist, dass der durchsuchbare Lösungsraum durch die auswählbaren Prioritätsregeln eingeschränkt wird, weil nur diejenigen Aufträge zur Bearbeitung in Frage kommen, die zu einem Zeitpunkt $t$ das Auswahlkriterium von mindestens einer Prioritätsregel am meisten erfüllen.

Es sei angemerkt, dass ferner eine vierte potenzielle Variante existiert, in der die Sequenzierung von Aufträgen ebenfalls als Klassifikationsproblem bzw. Entscheidungsproblem mit diskreten Aktionsraum formuliert wird. Gemäß dieser Formulierung bilden die Aktionen des Agenten direkt auf die Aufträge in der betrachteten Warteschlange ab. Obgleich Abschnitt 4.1.3 aufzeigt, dass diese Variante in der wissenschaftlichen Literatur mehrfach Beachtung findet, wird sie im vorliegenden Vorgehensmodell nicht berücksichtigt. Der Grund ist, dass diese Variante nicht in der Lage ist, auf eine flexible Anzahl von Aufträgen zu skalieren (Anforderung A8). Ein Agent, der auf eine bestimmte Anzahl von Aufträgen angelernt wurde, kann lediglich auf Auftragsvolumen angewandt werden, die kleiner oder gleich der Anzahl der während des Trainings beobachteten Aufträge sind. Ein höheres Auftragsvolumen in der Warteschlange würde das Training eines neuen Agenten mit angepasster Ausgabeschicht erfordern.

5.3.3 Integration und Inbetriebnahme von Agenten und Agentenumgebungen

In den vorhergehenden Abschnitten 5.3.1 und 5.3.2 wurde erläutert, wie Agentenumgebungen gestaltet bzw. wie Allokations- und Sequenzierungsprobleme modelliert werden müssen, sodass sie durch einen Agenten stufenweise entscheidbar sind. Der Zweck des vorliegenden Abschnitts ist, die technische Integration von Agenten und Simulationsumgebungen darzulegen. Die technische Integration dient zum einen als Grundlage für die Implementierung von RL-Trainingszyklen, zum anderen für den Einsatz von trainierten Agenten für PPS-Entscheidungen im Realbetrieb. Hierbei gestaltet sich die technische Integration von Agenten und Umgebungen für gradientenabhängige und gradientenfreie RL-Verfahren unterschiedlich. In Abschnitt 5.3.3.1 wird zunächst ein Integrationskonzept für gradientenabhängige RL-Verfahren beschrieben, gefolgt von einem Integrationskonzept für gradientenfreie RL-Verfahren in Abschnitt 5.3.3.2. Die Inbetriebnahme von Agenten und Agentenumgebungen wird nicht explizit erläutert, weil bei einer erfolgreichen Integration von Agenten und Umgebung die Inbetriebnahme lediglich die Ausführung des entsprechenden Programms erfordert. Die technische Realisierung der Inbetriebnahme kann somit als trivial betrachtet werden, sofern Agent und Umgebung fehlerfrei implementiert und miteinander integriert wurden. Ungeachtet dessen ist die Inbetriebnahme ein wichtiger Schritt im Vorgehensmodell zur Projektierung und Entwicklung von agentenbasierten Produktionsablaufsteuerungen (Abbildung 5.6 in Abschnitt 5.3), da mit dieser die technische Umsetzung der Integration validiert werden kann. Somit findet die Inbetriebnahme im Titel des vorliegenden Abschnitts Erwähnung, um konsistent mit den Prozessschritten des Vorgehensmodells zu bleiben.

5.3.3.1 Integrationskonzept für gradientenabhängiges bestärkendes Lernen

Für die Integration von Agenten, die durch gradientenabhängige RL-Verfahren trainiert werden, muss die Simulationsumgebung gemäß eines MEP modelliert sein (siehe Abschnitt 3.3.1). Insbesondere bedeutet dies, dass der Ablauf der Simulationsumgebung schrittweise – von Zustand zu Folgezustand – sowie in Abhängigkeit von gewählten Aktionen gesteuert werden muss. Hierfür ist es notwendig das in Abschnitt 5.3.1 eingeführte Prozessmodell für den Entwurf von Agentenumgebungen um wenige Aspekte zu erweitern.

Vor diesem Hintergrund wird für die Anwendung von gradientenabhängigen RL-Verfahren empfohlen, eigens entwickelte DES-Modelle mit der OpenAI-Gym-Schnittstelle auszustatten. Die OpenAI-Gym-Schnittstelle (Brockman et al. 2016) ist ein softwaretechnisches Objektmodell und zugleich eine Modellierungskonvention, mit der Zielstellung die Entwicklung von RL-Agentenumgebungen zu vereinheitlichen. Die Schnittstelle enthält alle benötigten Funktionen, um Agenten mithilfe von gradientenabhängigen RL-Verfahren zu trainieren. Aufbauend auf Abbildung 3.5 in Abschnitt 3.3.1 veranschaulicht Abbildung 5.15 das Zusammenspiel zwischen OpenAI-Gym-Umgebung und Agent für gradientenabhängige RL-Verfahren. Ferner zeigt Abbildung 5.15 die beiden wichtigsten Methoden, mit welchen jede OpenAI-Gym-Umgebung ausgestattet ist. Konkret handelt es sich um die Reset- und Step-Methode. Beide Methoden sollen im Folgenden kurz erläutert werden.

Abbildung 5.15

Wichtige Eigenschaften von OpenAI-Gym-Umgebungen und deren Integration in gradientenabhängige bestärkende Lernprozesse

Abbildung 5.16 zeigt den Aufbau und Ablauf der Reset-Methode als Programmablaufplan. Die Reset-Methode ist für die Initialisierung und das Zurücksetzen der Agentenumgebung verantwortlich. Die Agentenumgebung gilt dann als initialisiert, sobald sie das erste Ereignis erreicht, zu welchem eine Produktionsablaufentscheidung erforderlich ist. Je nachdem, welches Modell zur Abbildung des betrachteten Produktionsbereichs Anwendung findet (siehe Abbildung 5.3 in Abschnitt 5.2), handelt es sich hierbei um eine Allokations- oder Sequenzierungsentscheidung.

Aus konzeptioneller Sicht stellen sich sowohl für die Reset-Methode als auch für die Step-Methode zwei Fragen:

• 1. Wie können diejenigen Ereignisse identifiziert werden, zu welchen Produktionsablaufentscheidungen getätigt werden müssen?

• 2. Wie kann gewährleistet werden, dass die Simulationsumgebung genau zu diesen Ereignissen ihren Ablauf unterbricht?

Gewissermaßen alle DES-Entwicklungs- und Ablaufumgebungen bieten bereits eine interne Step-Funktion, die nicht mit der Step-Methode der OpenAI-Gym-Schnittstelle zu verwechseln ist. Die interne Step-Funktion ermöglicht es, ein DES-Modell schrittweise von Ereignis zu Ereignis zu durchlaufen. Hierbei hält das DES-Modell zu jedem Ereignis, bis die Step-Funktion erneut aufgerufen wird. Die Step-Funktion von DES-Modellen dient als Grundlage, um eine spezifizierte Reset- und Step-Methode im Sinne der OpenAI-Gym-Konvention zu entwickeln. In Abbildung 5.16 wird nach der Initialisierung des DES-Modells eine globale Merker-Variable mit der Bezeichnung »AUFRUFENDES_OBJEKT« initialisiert, ohne dass dieser ein Wert zugewiesen wird (None). Zum einen soll über den Merker AUFRUFENDES_OBJEKT festgestellt werden, ob eine Produktionsablaufentscheidung gefordert ist. In diesem Fall ist dem Merker ein Wert zugewiesen ($\ne None$). Zum anderen kann anhand der Art des Werts festgestellt werden, ob im DES-Modell eine Allokations- oder Sequenzierungsentscheidung getroffen werden muss. Gehört das aufrufende Objekt der Klasse »Auftrag« an, so ist eine Allokationsentscheidung gefordert. Eine Sequenzierungsentscheidung ist notwendig, sofern der Merker AUFRUFENDES_OBJEKT ein Objekt der Klasse »Produktionsressource« referenziert. Das DES-Modell wird mithilfe der internen Step-Funktion und einer while-Schleife solange durchschritten, bis der Merker AUFRUFENDES_OBJEKT erstmals auf ein Objekt referenziert. Je nach zugewiesenem Objekt wird danach der initiale Zustand für den Allokations- oder Sequenzierungsagenten gebildet und als Ergebnis zurückgegeben.

Abbildung 5.16

Algorithmischer Ablauf der Reset-Methode als Programmablaufplan

Der Einfachheit halber wird in Abbildung 5.16 der zurückgegebene initiale Zustand als $S_{t = 0}$ verallgemeinert. Genau genommen muss bei der initialen Zustandsbildung hinsichtlich des initialen Zustands des Allokationsagenten $S_{{t = 0, \theta_{Allok} }}$ und des Sequenzierungsagenten $S_{{t = 0, \theta_{Seq} }}$ unterschieden werden. Diese Unterscheidung gilt ferner für alle weiteren Zustände $S_{t = 1, \ldots T}$, die jedoch gleichermaßen in allen folgenden Programmablaufplänen vernachlässigt wird. Sofern die Sequenzierung von Aufträgen durch Priorisierung und anschließender Auswahl des maximal priorisierten Auftrags gesteuert wird, handelt es sich bei einem Zustand $S_{t}$ um ein Los von Zuständen ($S_{t, 1, \ldots ,n}$ bzw. $S_{{t, 1, \ldots ,n, \theta_{Seq} }}$). Diese Unterscheidung in der Notation wird in den folgenden Programmablaufplänen ebenfalls vernachlässigt. Für die Bildung von Zuständen werden diverse Attribute von Aufträgen und Produktionsressourcen aus der DES-Agentenumgebung ausgelesen. Einige relevante Zustandsdaten wurden bereits in Tabelle 5.3 (Abschnitt 5.3.2) vorgestellt. Analog der Zustände werden in den folgenden Programmablaufplänen Aktionen und Belohnungen als $A_{t}$ bzw. $R_{t + 1}$ verallgemeinert. Konkreter Weise müssen diese ebenfalls für die Allokation ($A_{{t, \theta_{Allok} }}$ bzw. $A_{{t, \theta_{Seq} }}$) und Sequenzierung ($R_{{t + 1, \theta_{Allok} }}$ bzw. $R_{{t + 1, \theta_{Seq} }}$) spezifiziert werden. Ebenfalls existieren Aktions- und Belohnungslose ($A_{t, 1, \ldots ,n}$ bzw. $A_{{t, 1, \ldots ,n, \theta_{Seq} }}$ und $R_{t + 1, 1, \ldots ,n}$ bzw. $R_{{t, 1, \ldots ,n, \theta_{Seq} }}$), sofern die Sequenzierung mittels Auftragsauswahl durch Priorisierung erfolgt. Auch dieser Sachverhalt wird in den folgenden Programmablaufplänen vernachlässigt.

Bisher wurde noch nicht erklärt, wie das aufrufende Objekt innerhalb der Simulationslogik der entsprechenden Merker-Variable zugewiesen wird. Zu diesem Zweck sei nochmal Abbildung 5.9 (Prozesslogik des Auftragsflusses) und Abbildung 5.10 (Prozesslogik von Produktionsressourcen) in Abschnitt 5.3.1.2 bzw. 5.3.1.3 in Erinnerung gerufen. Beide Prozesse enthalten jeweils eine Aktivität, welche auf dasselbe Unterprogramm verweisen. Abbildung 5.17 dient als Erweiterung der Prozessmodelle aus Abbildung 5.9 und Abbildung 5.10, indem sie den Ablauf der Unterprogramme präzisiert.

Abbildung 5.17

Präzisierung der Prozessmodelle von Aufträgen und Produktionsressourcen an der Schnittstelle zum Allokations- bzw. Sequenzierungsagenten für gradientenabhängige bestärkende Lernverfahren

Genau genommen wird immer dann, wenn in der Prozesslogikinstanz eines Auftrags oder einer Produktionsressource eine Allokations- bzw. eine Sequenzierungsentscheidung getroffen werden muss, dem globalen Merker AUFRUFENDES_OBJEKT der jeweilige Auftrag bzw. die jeweilige Produktionsressource zugewiesen, die mit der entsprechenden Prozesslogikinstanz assoziiert wird. Darauffolgend wird die Prozesslogik für null Zeiteinheiten pausiert. Analog der ersten Prozessvariante für die Auftragserzeugung (Abbildung 5.8 (a) in Abschnitt 5.3.1.1) hat das Pausieren keine Bedeutung für die Simulation des Produktionsablaufs, sondern dient lediglich der Terminierung eines zusätzlichen Ereignisses im Ereignisverwalter. Das Ereignis gewährleistet, dass die interne Step-Funktion des DES-Modells genau bei dem Ereignis hält, zu welchem eine Produktionsablaufentscheidung erforderlich ist.

Der initiale Zustand wird nun an den jeweiligen Agenten übergeben, um eine Aktion zu bestimmen. Abbildung 5.18 präsentiert einen generischen Programmablaufplan, der die agentenbasierte Berechnung von Aktionen in Abhängigkeit von eingehenden Zuständen beschreibt. Der Programmablaufplan unterscheidet, ob der Agent eine Aktionsnutzenfunktion $q_{\pi } \left( {s,a;\theta } \right)$, eine stochastische Entscheidungspolitik $\pi (a|s;\theta )$ oder eine deterministische Entscheidungspolitik $\pi \left( {s;\theta } \right)$ approximiert. Je nachdem finden unterschiedliche Techniken zur Exploration des Lösungsraums Anwendung. Die Approximation der Aktionsnutzenfunktion ist insbesondere für den DQN-Algorithmus charakteristisch, der ausschließlich für diskrete Aktionsräume Anwendung findet. Die Exploration des Lösungsraum wird dadurch realisiert, dass in einigen Zuständen eine zufällige Aktion anstelle der Aktion des maximal angeregten Ausgabeneurons gewählt wird. Die Explorationsstrategie wird über einen zusätzlichen Hyperparameter $\varepsilon$ gesteuert, der ungefähr gleich, jedoch kleiner als eins ist. In jedem Zustand wird eine Zufallszahl $rnd$ ausgewürfelt. Sofern diese kleiner als $\varepsilon$ ist, wird eine zufällige Aktion ausgewählt. Andernfalls wird die Aktion mit der maximalen neuronalen Anregung gewählt. Darauffolgend wird $\varepsilon$ diskontiert.

Abbildung 5.18

Aktionsermittlung durch Vorwärtspropagierung als Programmablaufplan

Der beschriebene Ablauf hat zur Folge, dass zu Beginn des Trainings vermehrt zufällige Aktionen gewählt werden und mit fortschreitender Zeit zunehmend der Entscheidungspolitik des Agenten gefolgt wird. Die Intention hinter diesem Vorgehen ist, dass der zufällig parametrisierte Agent zu Beginn des Trainings noch keine Entscheidungspolitik gelernt hat und durch eine verstärkte Exploration zunächst den Lösungsraum analysieren kann. Mit fortschreitender Trainingszeit ist es wiederum sinnvoll, dass die Exploration abnimmt, sodass der Agent zu einer bestimmten Entscheidungspolitik konvergiert.

Hingegen ist die Approximation einer stochastischen Entscheidungspolitik bspw. für die Algorithmen A2C, A3C und PPO charakteristisch. Für die Exploration des Lösungsraums sind keine zusätzlichen Techniken notwendig. Wie einleitend in Abschnitt 3.3.4 beschrieben, werden die eigentlichen Aktionen als Zufallsstichproben von den resultierenden Wahrscheinlichkeitsverteilungen entnommen. Zu Beginn des Trainings ist es üblich, dass die ermittelten Parameter der gesuchten Wahrscheinlichkeitsverteilung noch starken Schwankungen unterliegen, sodass die resultierenden Aktionen einen breiten Lösungsraum abdecken. Mit fortschreitendem Training nehmen diese Schwankung und damit einhergehend die Streubreite der Aktionen ab.

Der Agent approximiert immer dann eine deterministische Entscheidungspolitik, wenn es sich bei dem verwendeten DRL-Verfahren bspw. um den DDPG- oder TD3-Algorithmus handelt. Beide Verfahren werden ausschließlich für kontinuierliche Aktionsräume angewandt, d. h. dass der vollständige Aktionsraum über den Aktivierungsbereich eines Ausgabeneurons abgebildet wird. Für die Exploration des Lösungsraums wird jeweils ein zufälliger Wert auf alle Aktionen addiert, der im Folgenden auch »Rauschen« oder »Rausch-Term« genannt wird. Der Rausch-Term wird stichprobenartig von einer um den Wert null zentrierten Normalverteilung gezogen. Die Standardabweichung $\sigma_{rauschen}$ ist ein benutzerdefinierter Hyperparameter, der ungefähr gleich, jedoch kleiner als eins ist und nach jeder Aktion diskontiert wird. Die Diskontierung hat zur Folge, dass zu Beginn des Trainings die Aktionen stark verrauscht sind und eine Exploration des Lösungsraums begünstigt wird. Mit zunehmender Trainingszeit nimmt das Rauschen ab, bis dieses irgendwann vernachlässigbar ist und ausschließlich der Entscheidungspolitik des Agenten gefolgt wird. Hierdurch wird die Konvergenz der Lernkurve gewährleistet.

Wie in Abbildung 5.18 dargestellt, ist der Rückgabewert des Agenten eine Aktion. Die Aktion dient insbesondere als Eingangsparameter der Step-Methode der OpenAI-Gym-Schnittstelle. Abbildung 5.19 veranschaulicht die Step-Methode als Programmablaufplan. Eine Besonderheit der im Rahmen dieser Arbeit konzipierten Step-Methode ist, dass sie nicht ausschließlich für das Training eines einzelnen Agenten ausgelegt ist, sondern ebenfalls das parallele Training von bis zu zwei Agenten (konkret einen Allokations- und einen Sequenzierungsagenten) unterstützt. Auf diese Weise eignet sich die Step-Methode zur Anwendung für beide in Abbildung 5.3 (Abschnitt 5.2) eingeführten Produktionsbereichsmodelle.

Im Folgenden soll der Ablauf der Step-Methode kurz skizziert werden. Zu Beginn wird überprüft, ob der globale Merker AUFRUFENDES_OBJEKT einen Auftrag oder eine Produktionsressource referenziert. Zu diesem Zeitpunkt ist dem globalen Merker in jedem Fall ein Wert ungleich None zugewiesen, entweder aufgrund der zuvor ausgeführten Reset-Methode oder aufgrund der vorherigen Iteration der Step-Methode. Je nachdem wird die Belohnungsfunktion des Allokations- oder Sequenzierungsagenten aufgerufen. Für Allokationsentscheidungen erhält der Agent stets eine skalare Belohnung. Für Sequenzierungsentscheidungen erhält der Agent ebenfalls eine skalare Belohnung, sofern die Sequenzierung indirekt durch die agentenbasierte Auswahl von Prioritätsregeln gesteuert wird. Erfolgt die Sequenzierung hingegen durch die Priorisierung von Aufträgen, wird ein Belohnungsvektor zurückgegeben, der auf die Aufträge in der vorgelagerten Warteschlange abbildet. Die Gestaltung von Belohnungsfunktionen wird gesondert in Abschnitt 5.3.5 behandelt.

Sofern es sich beim aufrufenden Objekt um einen Auftrag handelt, wird dieser darauffolgend zu einer Produktionsressource entsprechend der übergebenen Aktion alloziert. Andernfalls handelt es sich bei dem aufrufenden Objekt um eine Produktionsressource. In diesem Fall wird der Auftrag mit der höchsten Priorität ausgewählt und auf die aufrufende Produktionsressource transferiert. Falls die Sequenzierung durch die agentenbasierte Auswahl von Prioritätsregeln gesteuert wird, ist die Priorität als dasjenige Attribut zu verstehen, das von der ausgewählten Prioritätsregel für die Sortierung von Aufträgen zu Rate gezogen wird.

Der Wert der globalen Merker-Variable AUFRUFENDES_OBJEKT wird nun zurückgesetzt ($: = None$). Analog zu der oben beschriebenen Reset-Methode wird im Folgenden die interne Step-Funktion der DES-Agentenumgebung wiederholt aufgerufen, bis die Umgebung beim nächsten Ereignis hält, in dem eine Produktionsablaufentscheidung gefordert wird. Abhängig von der Art des aufrufenden Objektes wird entweder der Folgezustand des Allokations- oder Sequenzierungsagenten gebildet. Darüber hinaus wird der lokale Merker $ENDE_{t + 1}$ auf $FALSCH$ gesetzt, was impliziert, dass die Simulation der Agentenumgebung noch nicht beendet ist. Bei der Ausführung der Step-Methode kann jedoch ebenfalls die gegenteilige Situation auftreten, nämlich dass die Agentenumgebung in einem finalen Zustand terminiert, in dem weder eine Allokations- noch eine Sequenzierungsentscheidung erforderlich ist. In diesem Fall werden die finalen Zustände $S_{t = T}$ von allen involvierten Agenten gebildet und der lokale Merker $ENDE_{t + 1}$ auf $WAHR$ gesetzt. Der finale Zustand eines Allokations- bzw. Sequenzierungsagenten ($S_{{t = T, \theta_{Allok} }}$ bzw. $S_{{t = T, \theta_{Seq} }}$) ist ein Tensor (d. h. ein mehrdimensionaler Vektor) mit derselben Dimensionalität aller zuvor beobachteten Allokations- bzw. Sequenzierungszustände, wobei jedes Element einen Wert von null besitzt.

Abbildung 5.19

Algorithmischer Ablauf der Step-Methode als Programmablaufplan

Abbildung 5.20

Vollständiges Prozessmodell der OpenAI-Gym-Schnittstelle

Zusammengefasst gibt die Step-Methode die Belohnung(en) $R_{t + 1}$, den Folgezustand $S_{t + 1}$ und den lokalen Merker $ENDE_{t + 1}$ zurück. In Abhängigkeit von $ENDE_{t + 1}$ wird entschieden, ob die DES-Agentenumgebung zurückgesetzt und (u. U.) ein weiteres Mal initialisiert wird ($ENDE_{t + 1} = WAHR)$ oder ob eine weitere Iteration der Step-Methode durchgeführt wird ($ENDE_{t + 1} = FALSCH$). Im zweiten Fall wird zuvor der Folgezustand $S_{t + 1}$ vorwärts durch den Agenten propagiert, um eine entsprechende Aktion $A_{t + 1}$ als Übergabeparameter für den erneuten Aufruf der Step-Methode zu ermitteln. Die Belohnung(en) $R_{t + 1}$ finden außerhalb der OpenAI-Gym-Umgebung für das Agententraining mithilfe eines ausgewählten RL-Verfahrens Verwendung. Abbildung 5.20 fasst das beschriebene Prozessmodell der OpenAI-Gym-Schnittstelle zusammen.

5.3.3.2 Integrationskonzept für gradientenfreies bestärkendes Lernen

Im Vergleich zu ihren gradientenabhängigen Verwandten ist für gradientenfreie RL-Verfahren die Einbindung von Agentenentscheidungen in DES-modellierte Umgebungen einfach zu realisieren. Der Grund ist, dass die Anwendung gradientenfreier RL-Verfahren keine Agentenumgebung mit den Eigenschaften eines MEP (siehe Abschnitt 3.3.1) erfordert. Konkret entfällt die Notwendigkeit, jede Aktion des Agenten mit einer Belohnung zu quittieren, weil der Lernprozess nicht schrittweise und einem Gradienten folgend, sondern stochastisch abläuft. Die Belohnung dient somit lediglich der Bewertung einer Lösung, jedoch nicht als Lernsignal, auf dessen Basis die Änderungsrichtung und -größenordnung der Agentenparameter gesteuert werden. Aus diesem Grund muss lediglich eine Belohnung am Ende jeder Episode ausgeschüttet werden. Zusammengefasst kann auf die aufwändige Implementierung der im vorhergehenden Abschnitt vorgestellten OpenAI-Gym-Schnittstelle verzichtet werden. Stattdessen erfolgt für gradientenfreie RL-Verfahren die Integration von Agenten und Agentenumgebungen nach einem grundlegend anderen, einfacheren Prinzip als bei gradientenabhängigen RL-Verfahren. Bei gradientenabhängigen RL-Verfahren werden die Agenten und die Agentenumgebung als dezentrale Software-Komponenten verstanden, welche insbesondere über die Step-Methode der OpenAI-Gym-Schnittstelle verknüpft sind. Hingegen werden bei gradientenfreien RL-Verfahren die Agenten durch geeignete Übergabeparameter in das DES-Modell als Objektattribute eingebettet und somit unmittelbar in die Simulationsablauflogik integriert.

Bereits im vorhergehenden Abschnitt wurde die Prozesslogik des Auftragsflusses (Abbildung 5.9 in Abschnitt 5.3.1.2) und die Prozesslogik von Produktionsressourcen (Abbildung 5.10 in Abschnitt 5.3.1.3) für gradientenabhängige RL-Verfahren präzisiert (Abbildung 5.17 in Abschnitt 5.3.3.1). Nach demselben Schema konkretisiert Abbildung 5.21 für gradientenfreie RL-Verfahren das entsprechende Unterprogramm für die gleichen beiden Aktivitäten.

Da der Agent direkt in das Simulationsmodell eingebettet wird, erfolgt die Bildung von Allokations- und Sequenzierungszuständen ebenfalls innerhalb der Ablauflogik des Simulationsmodells. Der generierte Zustand wird nun vorwärts durch den jeweiligen Agenten propagiert und darauffolgend in eine Produktionsablaufentscheidung übersetzt. Abbildung 5.22 konkretisiert beide Aktivitäten als Programmablaufplan. Analog zu Abschnitt 5.3.3.1 werden die unterschiedlichen Zustände und Aktionen von Allokations- und Sequenzierungsagenten zu Gunsten der Übersichtlichkeit als $S_{t}$ bzw. $A_{t}$ zusammengefasst. Ferner handelt es sich bei $S_{t}$ und $A_{t}$ um Zustands- bzw. Aktionslose, sofern der Sequenzierungsagent Aufträge auf Basis einer vorausgehenden Priorisierung auswählt. Im Unterschied zu ihren gradientenabhängigen Verwandten müssen für gradientenfreie RL-Verfahren keine zusätzlichen Explorationsstrategien für die Berechnung von Aktionen implementiert werden. Die Explorationsstrategien der gradientenabhängigen RL-Verfahren dienen insbesondere der Vermeidung von lokalen Optima. Dadurch dass der Gradient immer dem am nächsten gelegenen lokalen Extrempunkt folgt, kann bei einer zu geringen Schrittweite die Entscheidungspolitik in einem lokalen Optimum gefangen sein. Aufgrund der Tatsache, dass gradientenfreie RL-Verfahren die Parameter von Agenten zufällig verändern, sind diese von dem geschilderten Problem nicht betroffen. Obgleich die Bildung von Zuständen, die Berechnung von Aktionen sowie deren Umsetzung zu Produktionsablaufentscheidungen innerhalb der Simulationslogik stattfinden, ist es empfehlenswert die entsprechenden Ablaufroutinen als separate Funktionen oder Klassen zu implementieren. Dies fördert die Wiederverwendbarkeit und Wartbarkeit der DES-Agentenumgebung. Durch die Definition von zusätzlichen Übergabeparametern innerhalb der DES-Agentenumgebungsklasse können einfach und aufwandsarm unterschiedliche Agentenmodelle sowie Arten von Zustandsräumen experimentell untersucht werden.

Abbildung 5.21

Präzisierung der Prozessmodelle von Aufträgen und Produktionsressourcen an der Schnittstelle zum Allokations- bzw. Sequenzierungsagenten für gradientenfreie bestärkende Lernverfahren

5.3.4 Auswahl und Implementierung von bestärkenden Lernverfahren

Bisher adressierte das Vorgehensmodell in den Abschnitten 5.3.1 bis 5.3.3 die Konzeption und Implementierung von DES-basierten Umgebungen, welche Probleme der Produktionsablaufplanung abbilden, sowie von Agenten für unterschiedliche Arten von Produktionsablaufentscheidungen. Zu diesem Zeitpunkt können die Funktionalität und Integration von Agenten und deren Umgebung bereits validiert werden, indem die Agenten mit zufälligen Parametern initialisiert und darauffolgend für Produktionsablaufentscheidungen in der Umgebung eingesetzt werden. Der vorliegende Abschnitt beschäftigt sich nun mit der Auswahl und Implementierung von RL-Verfahren, um die Parameter eines Agenten in Richtung einer optimalen Entscheidungspolitik schrittweise anzupassen.

Abbildung 5.22

Programmablaufplan der Aktionsermittlung durch Vorwärtspropagierung und Übersetzung von Aktionen zu Produktionsablaufentscheidungen für gradientenfreies bestärkendes Lernen

Hinsichtlich der Auswahl von geeigneten RL-Verfahren sei zunächst festzustellen, dass keine wissenschaftlichen Arbeiten bekannt sind, welche die Dominanz eines bestimmten RL-Verfahrens gegenüber allen existierenden RL-Verfahren attestieren. Wie im Vorgehensmodell zur Umsetzung von agentenbasierten Produktionsablaufsteuerungen in Abbildung 5.6 (Abschnitt 5.3) dargestellt, ist die Auswahl eines geeigneten RL-Verfahrens vielmehr als experimentierbare Größe zu verstehen, die für die Optimierung des Agententrainings untersucht werden kann.

Abhängig von der betrachteten Teilproblemstellung der Produktionsablaufplanung (Allokation oder Sequenzierung) und deren Formulierung als ML-Aufgabe können jedoch einige RL-Verfahren im Voraus von der Untersuchung ausgeschlossen werden. Abbildung 5.23 präsentiert zu diesem Zweck ein Klassifikationsschema für den Einsatz von RL-Verfahren für die Produktionsablaufplanung. Dem Schema liegt die Überlegung zugrunde, dass einige RL-Verfahren lediglich für diskrete Aktionsräume ausgelegt sind, während andere RL-Verfahren allen voran für den Einsatz für Probleme mit kontinuierlichen Aktionsräumen gestaltet wurden. Hieraus kann geschlussfolgert werden, dass insbesondere für Allokationsprobleme die Algorithmen DDPG, TD3 und SAC von Untersuchungen ausgeschlossen werden können. Sofern ein Sequenzierungsproblem gemäß Abbildung 5.12 oder Abbildung 5.13 (Abschnitt 5.3.3.2) formuliert wird, kann hingegen auf die Untersuchung von all denjenigen Verfahren verzichtet werden, die vornehmlich für diskrete Aktionsräume ausgelegt sind (Q-Learning, DQN, SARSA, REINFORCE). Stochastische EPA-Verfahren (A2C, A3C, TRPO, PPO) können grundsätzlich für beide Teilproblemstellungen angewandt werden, da für diskrete Aktionsräume die Entscheidungspolitik als multinominale Verteilung bzw. für kontinuierliche Aktionsräume als Normalverteilung repräsentiert wird. Ferner sind ebenfalls gradientenfreie RL-Verfahren im Allgemeinen sowohl für Allokations- als auch für Sequenzierungsprobleme anwendbar.

Abbildung 5.23

Klassifikation von bestärkenden Lernverfahren hinsichtlich ihrer Einsatzmöglichkeiten für die Produktionsablaufplanung

Eine Diskussion von Implementierungsstrategien für alle gelisteten RL-Verfahren geht über den Rahmen dieser Arbeit hinaus. Zudem würde eine solche Darstellung keinen neuen wissenschaftlichen Beitrag leisten, da jedes der gelisteten RL-Verfahren bereits in wissenschaftlichen Publikationen, Onlinebeiträgen sowie in Form von öffentlich zugänglichen Software-Projekte beschrieben wurde. Aus Implementierungssicht soll stattdessen der Fokus auf den Entwurf und die Umsetzung von Trainingsprozeduren gelegt werden. Je nachdem ob das verwendete RL-Verfahren eigens implementiert oder vorgefertigt aus einer etablierten Programmbibliothek verwendet wird, unterscheiden sich die resultierenden Trainingsprozeduren wesentlich hinsichtlich ihrer Komplexität und ihres Umfangs voneinander.

Zunächst soll eine Trainingsprozedur für den Fall skizziert werden, dass ein gradientenabhängiges RL-Verfahren für eine Agentenumgebung angewandt wird, welche die Eigenschaften eines MDP (siehe Abschnitt 3.3.1) erfüllt und den Konventionen von OpenAI-Gym entspricht. Beispielsweise erfüllen die Formulierungsvarianten für die Allokation von Aufträgen (siehe Abbildung 5.11 in Abschnitt 5.3.2.1) bzw. für die Auswahl von Prioritätsregeln (siehe Abbildung 5.14 in Abschnitt 5.3.2.2) gleichermaßen die Eigenschaften eines MDP. Folglich bietet es sich an, einen vorgefertigten RL-Algorithmus aus einer etablierten Programmbibliothek wie »OpenAI Baselines« (Dhariwal et al. 2017), »Ray RLlib« (Liang et al. 2017) oder »Stable Baselines« (Hill et al. 2018) für das Training zu verwenden. Die Trainingsprozedur ist dementsprechend einfach zu implementieren.

Abbildung 5.24 spezifiziert zwei Trainingsprozeduren am Beispiel der Bibliotheken Stable Baselines (a) und Ray RLlib (b). Beide Trainingsprozeduren überzeugen durch ihre Einfachheit, da alle komplexeren Routinen, die für das Training erforderlich sind, innerhalb der jeweiligen Bibliothek implementiert sind. Aus konzeptioneller Sicht unterscheiden sich beide Trainingsprozeduren nur marginal. In Stable Baselines wird zunächst die Agentenumgebung initialisiert. Das resultierende Objekt wird als Parameter an das RL-Verfahren übergeben. Das Training wird über einen Methodenaufruf des gewählten RL-Verfahrens gestartet und dann in Abhängigkeit von der spezifizierten Anzahl von Episoden oder Zeitschritten (bei nicht terminierenden Umgebungen) durchgeführt. In Ray RLlib wird kein instanziiertes Objekt der Umgebungsklasse, sondern die Umgebungsklasse selbst als Parameter an das RL-Verfahren übergeben. Im Unterschied zu Stable Baselines ist es somit nicht möglich die DES-Umgebung und die OpenAI-Schnittstelle als separate Klassen zu implementieren. Dies würde erfordern, dass ein in Ray RLlib implementiertes RL-Verfahren die Agentenumgebung nicht als Klasse, sondern in Form eines instanziierten Objekts berücksichtigen kann. Nur auf diese Weise kann zunächst eine DES-Umgebung erstellt und darauffolgend mit der OpenAI-Schnittstelle umhüllt werden. Jegliche Parameter der Umgebung müssen ferner in einem separaten Konfigurationsobjekt definiert werden. Ein weiterer Unterschied zu Stable Baselines ist, dass in Ray RLlib die Anzahl der Episoden bzw. Zeitschritte nicht mittels eines Übergabeparameters der Trainingsmethode zur Verfügung gestellt wird. Gewöhnlich wird stattdessen das Training über ein Schleifenkonstrukt außerhalb der Trainingsmethode gesteuert.

Abbildung 5.24

Trainingsprozedur für gradientenabhängige bestärkende Lernverfahren unter Verwendung der Bibliotheken (a) Stable Baselines und (b) Ray RLlib

Für Sequenzierungsstrategien, in welchen Aktionen als Auftragsprioritäten betrachtet werden, erfordert die Anwendung von vorgefertigten RL-Algorithmen diverse Anpassungen innerhalb der Programmbibliotheken. Der Grund ist, dass die jeweiligen Formulierungsvarianten gewisse Eigenschaften eines MDP und damit einhergehend bestimmte Modellierungskonventionen von OpenAI-Gym nicht erfüllen. Konkret erfordert die erste Formulierungsvariante (siehe Abbildung 5.12 in Abschnitt 5.3.2.2) die Berechnung von mehreren Aktionen und Belohnungen, bevor die Umgebung in Abhängigkeit eines gewählten Auftrags voranschreiten kann. Bei der zweiten Formulierungsvariante (siehe Abbildung 5.13 in Abschnitt 5.3.2.2) können die Belohnungen erst verspätet vergeben werden, da die Priorisierung und die Auswahl von Aufträgen zeitlich entkoppelt sind. Aufgrund ihrer Komplexität sind Anpassungen in den Programmbibliotheken sehr aufwändig. Demgegenüber kann der Aufwand geringer sein, wenn das jeweilige RL-Verfahren zzgl. der Trainingsprozedur eigens implementiert werden. Abbildung 5.25 präsentiert eine beispielhafte Trainingsprozedur für genau diesen Zweck.

Die skizzierte Trainingsprozedur fußt auf der Annahme, dass die Agentenumgebung mit der OpenAI-Gym-Schnittstelle ausgestattet ist und die Umgebung in einem finalen Zustand $S_{T}$ terminiert. Über eine for-Schleife durchläuft die Prozedur eine benutzerdefinierte Anzahl von Episoden in der Agentenumgebung. Zu diesem Zweck werden die in Abschnitt 5.3.3.1 eingeführte Reset- (Abbildung 5.16) und Step-Methode (Abbildung 5.19) der OpenAI-Gym-Schnittstelle sowie die Methode zur Aktionsermittlung durch Vorwärtspropagierung (Abbildung 5.18) verwendet. Die Reset-Methode wird lediglich zu Beginn einer Episode aufgerufen. Das Durchschreiten der Umgebung mithilfe der Step- und Aktionsermittlungsmethode wird über eine while-Schleife gesteuert, die terminiert, sobald in einem Umgebungszustand $ENDE_{t + 1}$ als $WAHR$ beobachtet wird. Immer dann, wenn eine Aktion bestimmt wurde, in deren Abhängigkeit die Umgebung vorangeschritten ist, wird eine Belohnung $R_{t + 1}$, ein Folgezustand $S_{t + 1}$ sowie der Merker $ENDE_{t + 1}$ ausgegeben. Die drei Informationen dienen zunächst der Vervollständigung der aktuellen Transition $\left( {S_{t} , A_{t} , R_{t + 1} , S_{t + 1} , ENDE_{t + 1} } \right)$. In Abhängigkeit davon, ob der untersuchte RL-Algorithmus auf das N-Step-Bootstrapping- (siehe Abschnitt 3.3.5) oder das gewöhnliche TD-Lernverfahren zur Generierung von Lernsignalen zurückgreift, wird die Transition entweder dem Erfahrungsspeicher oder einer bestehenden bzw. einer neuen Trajektorie hinzugefügt.

Das N-Step-Bootstrapping-Verfahren wird insbesondere von stochastischen EPA-Verfahren verwendet, bei welchen es sich i. d. R. um On-Policy-Methoden handelt. On-Policy-Methoden trainieren mit Beobachtungen, die mit den aktuellen Agentenparametern $\theta$ gesammelt wurden. In einem Trainingsschritt werden die Ziel-Zustandsnutzenwerte durch Rückwärtsrechnung ermittelt, indem, ausgehend von der Zustandsnutzenprognose des Critic-Modells, die Belohnungen von dem am weitesten in der Zukunft liegenden bis zu dem am weitesten in der Vergangenheit liegenden Zustand kumuliert werden. Das genaue Prinzip wurde bereits in Abschnitt 3.3.5 dargelegt.

RL-Algorithmen, die das TD-Lernverfahren verwenden, sind bspw. der DQN-, der DDPG- und der TD3-Algorithmus. Jedes der drei Verfahren besitzt einen sogenannten Erfahrungsspeicher. Während eines Trainingsschritts wird eine benutzerdefinierte Anzahl zufälliger Transitionen aus dem Erfahrungsspeicher zu einem Los gebildet. Die Transitionen sind zeitlich nicht zusammenhängend und stammen größtenteils aus Beobachtungen, die mit vergangenen Agentenparametern $\theta^{ - }$ verarbeitet wurden. Aus diesem Grund werden jene Verfahren auch als Off-Policy-Methoden klassifiziert.

Nachdem die vollständige Transition entweder dem Erfahrungsspeicher oder der Trajektorie hinzugefügt wurde, prüft die Prozedur in Abbildung 5.25, ob in der aktuellen Iteration ein Trainingsschritt durchzuführen ist. Das Prüfkriterium ist abhängig vom verwendeten RL-Verfahren. Trajektorien bildende Verfahren führen gewöhnlich wiederholend und stets nach einer konstanten Anzahl von observierten Zuständen einen Trainingsschritt aus. RL-Verfahren, die über einen Erfahrungsspeicher verfügen, führen gewöhnlich nach jedem observierten Zustand einen Trainingsschritt aus, sofern der Erfahrungsspeicher über eine ausreichende Anzahl von Transitionen verfügt. Manche RL-Verfahren, z. B. der TD3-Algorithmus, kombinieren die beiden zuvor beschriebenen Prüfkriterien.

Abschließend prüft die Trainingsprozedur, ob $ENDE_{t + 1}$ den Wert $WAHR$ besitzt. Ist dies der Fall, so ist die Agentenumgebung terminiert, wodurch entweder eine neue Episode begonnen oder das Training beendet wird. Sofern $ENDE_{t + 1}$ den Wert $FALSCH$ besitzt, wird der Folgezustand $S_{t + 1}$ fortan als aktueller Zustand $S_{t}$ betrachtet, für die Eröffnung einer neuen Transition verwendet und schließlich dem Agenten zur Aktionsermittlung mittels Vorwärtspropagierung übergeben.

Abbildung 5.25

Beispielhafte Trainingsprozedur für selbstimplementierte gradientenabhängige bestärkende Lernverfahren

Abbildung 5.25 kann gewissermaßen als standardmäßige Trainingsprozedur betrachtet werden. Sie eignet sich sowohl für die Allokation von Aufträgen als auch für die Auswahl von Prioritätsregeln, deren Formulierung als ML-Aufgaben gleichermaßen die Eigenschaften eines MDP und die Modellierungskonventionen von OpenAI-Gym erfüllen. Ferner eignet sich die Prozedur für das Training von Agenten, welche Auftragsreihenfolgen durch Priorisierung aller wartenden Aufträge und anschließender Auswahl des nächsten zu produzierenden Auftrags bilden (siehe Abbildung 5.12 in Abschnitt 5.3.2.2). In diesem Fall ändert sich lediglich das Datenformat der Belohnungen und Aktionen, die durch die Step-Methode zurückgegeben und innerhalb von Transitionen gespeichert werden. Anstelle von Skalaren werden beide Größen nun als Vektoren ausgedrückt, deren Größe der Anzahl wartender Aufträge in der betrachteten Warteschlange entsprechen. Um zu gewährleisten, dass das N-Step-Bootstrapping- bzw. das TD-Lernverfahren funktionieren, ist es notwendig, dass die Aktions- und Belohnungsvektoren während des Trainings von einheitlicher Länge sind. Ein Grund hierfür ist u. a., dass bei der Rückwärtsrechnung zur Ermittlung der Ziel-Nutzenwerte Belohnungen von unterschiedlichen Zeitschritten kumuliert werden. Aus mathematischer Sicht handelt es sich hierbei nur dann um eine zulässige Operation, wenn die zu addierenden Vektoren gleich groß sind. Zu diesem Zweck muss während des Trainings eine maximale Anzahl von Aufträgen in der betrachteten Warteschlange angenommen werden. Wie in Abbildung 5.25 dargestellt, werden hierfür in den Zeitschritten, in welchen die gegenwärtige Anzahl kleiner als die maximale Anzahl von Aufträgen ist, die Aktions- und Belohnungsvektoren mit einer entsprechenden Menge von Nullwerten aufgefüllt, bevor sie dem Erfahrungsspeicher hinzugefügt werden. Es sei angemerkt, dass die Annahme einer maximalen Auftragsanzahl nur für das Training, jedoch nicht für den anschließenden Einsatz notwendig ist.

Hingegen kann die Trainingsprozedur in Abbildung 5.25 nicht für die zweite Formulierungsvariante von Sequenzierungsproblemen eingesetzt werden, in welcher mittels Priorisierung eine Auftragssequenz iterativ konstruiert wird. Hierzu müsste die Trainingsprozedur so angepasst werden, dass Transitionen zunächst ohne eine Belohnung dem Erfahrungsspeicher oder der Trajektorie hinzugefügt werden. Eine Belohnung kann erst ermittelt werden, sobald der jeweilige Auftrag bearbeitet wurde. Im Grenzfall, unter der Annahme eines temporär finiten Auftragshorizonts, würde der erste Auftrag auf einer Produktionsressource erst dann bearbeitet werden, wenn jeder Auftrag der initialen Auftragsliste einer Position in der Sequenz zugeordnet wurde. Um zu gewährleisten, dass die richtige Belohnung der richtigen Transition zugeordnet wird, kann bspw. eine zusätzliche Transitions-ID eingeführt werden. Diese verknüpft die jeweilige Transition mit dem jeweiligen Auftrag, der im entsprechenden Zeitschritt für die Zustandsbildung analysiert wurde. Über die Transitions-ID kann nach der Bearbeitung eines Auftrags die resultierende Belohnung der entsprechenden Transition zugeordnet werden. Ferner muss gewährleistet sein, dass unvollständige Transitionen nicht für das Training berücksichtigt werden. Für RL-Verfahren, welche einen Erfahrungsspeicher verwenden, kann bspw. eine zusätzliche Liste gepflegt werden, die unvollständige Transitionen temporär puffert. Bei RL-Verfahren, die auf N-Step-Bootstrapping zur Erzeugung von Lernsignalen zurückgreifen, kann bspw. gewartet werden, bis die Umgebung in einem finalen Zustand terminiert, sodass alle Aufträge einer Episode für die Bildung einer Trajektorie verwendet werden.

Aufgrund ihrer Vielfalt und Individualität ist es nicht zweckmäßig eine generische Trainingsprozedur für gradientenfreie RL-Verfahren herzuleiten. Analog zu den theoretischen Grundlagen in Abschnitt 3.4 soll eine Trainingsprozedur für den NEAT-Algorithmus als Stellvertreter der gradientenfreien RL-Verfahren skizziert werden. Abbildung 5.26 veranschaulicht eine mögliche Trainingsprozedur von NEAT, unter der Annahme, dass eine vorimplementierte Version des Algorithmus aus der Programmbibliothek NEAT-Python verwendet wird. Ergänzend sei an dieser Stelle ein weiteres Mal auf Abschnitt 3.4.2 verwiesen, in welchem das NEAT-Verfahren ausführlich beschrieben wird.

Abbildung 5.26

Trainingsprozedur für den NEAT-Algorithmus der Programmbibliothek NEAT-Python, stellvertretend für gradientenfreie bestärkende Lernverfahren

Der Programmablauf ist ähnlich simpel strukturiert wie die Trainingsprozeduren von gradientenabhängigen RL-Verfahren unter Verwendung einer etablierten Programmbibliothek (siehe Abbildung 5.24). Analog zu diesen sind komplexere Routinen, die für das Training erforderlich sind, innerhalb der jeweiligen Bibliotheken implementiert und werden in Abbildung 5.26 in Form von Unterprogrammbausteinen zusammengefasst. NEAT erfordert für die Initialisierung einige Hyperparameter, die innerhalb einer Konfigurationsdatei definiert und gespeichert werden. Die Hyperparameter sind insbesondere für die Steuerung des Trainingsprozesses verantwortlich und werden in Abschnitt 5.3.6 näher beleuchtet. Nachdem die Konfiguration eingelesen wurde, wird eine Population von Genomen erstellt. Die Größe der Population geht aus der benutzerdefinierten Konfiguration hervor. Im nächsten Schritt wird eine spezifische Anzahl von Evaluationskernels instanziiert. Ein Evaluationskernel ist für die Berechnung der Lösungsgüte von Genomen verantwortlich. Konkret wird auf einem Evaluationskernel eine Instanz der DES-Agentenumgebung ausgeführt. Nachdem eine Episode endet, werden verschiedene Kennzahlen aus der Umgebung ausgelesen und in einer Fitnessfunktion verarbeitet, welche die Lösungsgüte des analysierten Genoms ausgibt. Die Fitnessfunktion ist ebenfalls benutzerdefiniert und gilt als das Pendant zur Belohnungsfunktion gradientenabhängiger Verfahren. Fitnessfunktionen für verschiedene Anwendungsfälle werden in Abschnitt 5.3.5 spezifiziert. Die Anzahl von Evaluationskernels ist grundsätzlich frei wählbar, wird jedoch durch die Anzahl verfügbarer Prozessorkerne begrenzt. Sinnhafter Weise kann jeder logische Prozessorkern einen Evaluationskernel ausführen. Im letzten Schritt in Abbildung 5.26 wird der NEAT-Algorithmus gestartet. Hierbei wird gewöhnlich eine Anzahl von Generationen definiert, nach der die Ausführung des Algorithmus spätestens terminiert. Ferner können weitere Terminierungskriterien in der Konfigurationsdatei definiert werden, z. B. die Überschreitung (bzw. Unterschreitung) einer benutzerdefinierten oberen (bzw. unteren) Schranke bezogen auf den Rückgabewert der Fitnessfunktion bei Maximierungsproblemen (bzw. Minimierungsproblemen). Im Gegensatz zu ihren gradientenabhängigen Verwandten erscheint es nicht sinnvoll ein gradientenfreies RL-Verfahren von Grund auf eigenständig zu implementieren. Die Intention ein gradientenabhängiges RL-Verfahren selbst zu implementieren ist, dass einige der in Abschnitt 5.3.2 dargestellten Varianten zur Formulierung von ML-Aufgaben nicht die Eigenschaften eines MDP erfüllen. Die vorimplementierten RL-Algorithmen aus den etablierten Programmbibliotheken funktionieren für diese Formulierungsvarianten nicht, weil sie unter der Annahme implementiert wurden, dass die Agentenumgebung den Konventionen von OpenAI-Gym und den Eigenschaften eines MDP folgt. Aufgrund der Tatsache, dass gradientenfreie RL-Verfahren insbesondere stochastische Suchtechniken für die Anpassung der Agentenparameter verwenden, sind sie nicht darauf angewiesen, dass die Agentenumgebung den Eigenschaften eines MEP folgt. Aus dieser Beobachtung kann ebenfalls abgeleitet werden, dass alle in Abschnitt 5.3.2 dargestellten Varianten zur Formulierung von ML-Aufgaben für alle gradientenfreien RL-Verfahren problemlos implementiert werden können.

5.3.5 Gestaltung von Belohnungsfunktionen

Das Training mithilfe von RL-Verfahren wird stets über eine Belohnungsfunktion gesteuert. In gradientenabhängigen RL-Verfahren dient die Belohnungsfunktion der Generierung von Lernsignalen. Das Lernsignal wird rückwärts durch das Agentenmodell propagiert, um die Gradienten aller trainierbaren Parameter zu berechnen. Die Parameter des Agenten werden sodann mittels Gradientenabstieg (bei ANB-Verfahren – siehe Abschnitt 3.3.3) oder Gradientenaufstieg (bei EPA-Verfahren – siehe Abschnitt 3.3.4) aktualisiert.

In gradientenfreien RL-Verfahren wird die Belohnungsfunktion auch als Fitnessfunktion bezeichnet. Sie dient der Bewertung einer vollständigen Lösung, die nach Ablauf einer Episode und in Abhängigkeit der Sequenz von Agentenentscheidungen resultiert. In gradientenfreien RL-Verfahren übt die Belohnungsfunktion nur einen geringen Einfluss auf die Steuerung des Agententrainings aus. Sie beeinflusst u. a., wann das jeweilige RL-Verfahren terminiert (z. B. sobald ein bestimmter Fitnessschwellenwert über- oder unterschritten wurde), welche Lösungskandidaten (respektive Agentenparameterkombination) temporär beibehalten werden (die Top $n$ Lösungen) und welche Lösungskandidaten weiteren Veränderungen unterzogen werden (alle weiteren Lösungen). Hingegen hat die Belohnungsfunktion keinen Einfluss auf die Veränderungsrichtung und -ausprägung der trainierbaren Agentenparameter, da beide Aspekte zufallsgesteuert sind.

Entgegen der Reihenfolge in den vorausgegangenen Abschnitten soll die Gestaltung von Belohnungsfunktionen zunächst für gradientenfreie RL-Verfahren dargelegt werden, weil diese konzeptionell einfacher sind als die Belohnungsfunktionen ihrer gradientenabhängigen Verwandten. Die geringere Komplexität rührt daher, dass lediglich am Ende einer Episode (und nicht nach jeder Aktion, wie bei gradientenabhängigen RL-Verfahren) eine Belohnung vergeben werden muss. Die Belohnung dient lediglich der Bewertung der Gesamtlösung. Aus diesem Grund kann die Zielfunktion des Optimierungsproblems ebenfalls als Belohnungsfunktion für gradientenfreie RL-Verfahren verwendet werden. Die geläufigsten Zielfunktionen zur Optimierung von Ablaufplänen wurden bereits in Abschnitt 2.3.1.3 gelistet. Ferner ist es möglich eine multikriterielle Zielfunktion, die mehrere Optimierungskriterien berücksichtigt, gemäß Formel (6) aus Abschnitt 2.3.2.1 als Belohnungsfunktion zu definieren. In diesem Zusammenhang kann es für das Training ebenfalls förderlich sein, zusätzliche Kennzahlen in die Belohnungsfunktion mitaufzunehmen, die über eine vollständige Episode ermittelt werden, bei welchen es sich jedoch um keine direkten Optimierungskriterien handelt. Ein Beispiel für eine solche Kennzahl ist die Anzahl der Rüstvorgänge auf einer Produktionsressource, deren Verringerung häufig mit einer Erhöhung des Produktivzeitanteils einhergeht. Eine Erhöhung des Produktivzeitanteils kann bspw. wiederum zur Minimierung der Gesamtdauer eines Produktionsablaufplans oder zur Verringerung der Verspätung einzelner Aufträge beitragen.

Für gradientenabhängige RL-Verfahren ist es notwendig, dass eine Belohnung für jede berechnete Aktion ausgegeben wird. Demzufolge ist es nicht möglich die zu optimierende Zielfunktion als Belohnungsfunktion zu verwenden, weil diese lediglich im finalen Zustand $S_{T}$ eine Belohnung ausgeben könnte. Stattdessen muss die Belohnungsfunktion so gestaltet sein, dass in jedem Zustand bzw. für jede Aktion die vergebene Belohnung auf die zu optimierende Zielfunktion schließt. Konkret müssen die Belohnungsfunktion und die zu optimierende Zielfunktion insofern miteinander korrelieren, dass steigende Belohnungen bzw. sinkende Bestrafungen mit einer Verbesserung der Zielfunktion einhergehen, während steigende Bestrafungen bzw. sinkende Belohnungen zu einer Verschlechterung der Zielfunktion führen. In Abhängigkeit davon, ob der Agent die Allokation oder Sequenzierung von Aufträgen verantwortet, eignen sich für die Bildung der Belohnungsfunktion unterschiedliche Arten von Kennzahlen.

Um die Prinzipien der Gestaltung von Belohnungsfunktionen für gradientenabhängige RL-Verfahren zu beleuchten, kommt es dem intuitiven Verständnis zugute, einen beliebigen Produktionsprozess von dessen Senke bis zu dessen Quelle zu betrachten. Zur Veranschaulichung sei das Modell eines Produktionsbereichs mit lokalen Warteschlangen für jede Produktionsressource angenommen (Abbildung 5.3 in Abschnitt 5.2). Dieses Modell ist für die Diskussion von verschiedenen Belohnungsstrategien besonders geeignet, da die Steuerung der Produktion sowohl Allokations- als auch Sequenzierungsentscheidungen erfordert. Wird der entsprechende Produktionsprozess entgegengesetzt der Richtung des Materialflusses analysiert, so liegt der Fokus der Betrachtung zunächst auf Belohnungsfunktionen für Sequenzierungsentscheidungen.

5.3.5.1 Zeitbasierte Belohnungsfunktionen

Für die Bewertung von Sequenzierungsentscheidungen eignen sich grundsätzlich zeitbasierte Kennzahlen. Der primäre Grund ist, dass es sich bei den in Abschnitt 2.3.1.3 aufgeführten Zielfunktionen um zeitbasierte Optimierungskriterien handelt. Durch die Verwendung von zeitbasierten Kennzahlen ist grundsätzlich der Entwurf einer Belohnungsfunktion möglich, die mit der Zielfunktion korreliert.

Optimierungskriterien, welche die Minimierung von Durchlaufzeiten zum Ziel haben, z. B. die kumulierte Durchlaufzeit $F$ oder die Gesamtdauer eines Ablaufplans $C_{max}$, können u. a. auf Basis der verstrichenen Simulationszeit $t_{sim}$ bewertet werden. Dieser Ansatz wurde in der Literatur u. a. von Minguillon und Lanza (2019) untersucht. In diesem Fall wird jede Sequenzierungsentscheidung mit der verstrichenen Simulationszeit bestraft, indem sie mit dem Faktor $\left( { - 1} \right)$ multipliziert wird. Zusammengefasst ergibt sich die folgende Belohnungsfunktion, sofern die Belohnungsvergabe erst dann erfolgt, wenn der Auftrag die Produktionsressource verlässt.

$${\mathcal{R}}_{C} \left( j \right) = \left( { - 1} \right)*C_{j,o} = \left( { - 1} \right)*t_{sim}$$

(5.1)

Formel (5.1) entspricht somit der Fertigstellungszeit von Operation $o$ des selektierten Auftrags $j$. Die Intention ist, dass der Agent die Ermittlung ebensolcher Entscheidungen erlernt, durch die jegliche Zeitverbräuche möglichst vermieden und die erhaltenen Bestrafungen minimiert werden. Somit ist zum Zeitpunkt $T$ die theoretisch beste Belohnung bzw. geringste Bestrafung das negative Äquivalent der minimalen Gesamtdauer eines Ablaufplans. Auf dieser Basis lassen sich diverse weitere Belohnungsfunktionen herleiten, welche die Durchlaufzeit von einzelnen Aufträgen oder des gesamten Ablaufplans verringern. Wie Formel (5.2) zeigt, kann bspw. ebenfalls die Durchlaufzeit $F_{j,o}$ der zuletzt bearbeitete Operation $o$ des selektierten Auftrags $j$ als Belohnungsfunktion herangezogen werden, um auf diese Weise die kumulierte Durchlaufzeit $F$ als Optimierungskriterium zu adressieren.

$${\mathcal{R}}_{F} \left( j \right) = \left( { - 1} \right)*F_{j,o} = \left( { - 1} \right)*(t_{sim} - r_{j,o} )$$

(5.2)

Die Freigabezeit $r_{j,o}$ in Formel (5.2) entspricht dem Eintrittszeitpunkt von Auftrag $j$ im Produktionsbereich, der für die Bearbeitung der aktuellen Operation $o$ zuständig ist. Zeitgleich entspricht $r_{j,o}$ dem Eintrittszeitpunkt von Auftrag $j$ in der entsprechenden Warteschlange der allozierten Produktionsressource, da im vorliegenden Beispiel die Allokation von Aufträgen ohne Zeitverzug nach deren Ankunft im Produktionsbereich vonstattengeht. Formel (5.2) berechnet nur dann die Durchlaufzeit der Auftragsoperation, wenn $t_{sim}$ nach abgeschlossener Bearbeitung von Operation $o$ gemessen wird. Erfolgt hingegen die Erhebung von $t_{sim}$ vor Bearbeitungsbeginn von Operation $o$, berechnet Formel (5.2) nicht die Durchlaufzeit, sondern die Wartezeit des entsprechenden Auftrags in der Warteschlange. In beiden Fällen eignet sich Formel (5.2), um auf durchlaufzeitorientierte Optimierungskriterien zu schließen.

Falls der Agent Entscheidungen entsprechend der ersten Variante zur Formulierung von Sequenzierungsproblemen als ML-Aufgabe trifft (Auswahl des nächsten zu produzierenden Auftrags mittels Priorisierung, siehe Abbildung 5.12 in Abschnitt 5.3.2.2), wird ein Aktionsvektor mit Auftragsprioritäten berechnet, dessen Größe der Anzahl von Aufträgen in der betrachteten Warteschlange entspricht. Obgleich lediglich ein Auftrag gemäß dem Maximum des Aktionsvektors zur Bearbeitung ausgewählt wird, können ebenfalls die verbleibenden Aufträge mit einer entsprechend gestalteten Belohnungsfunktion bewertet werden. Dies hat den Vorteil, dass eine höhere Anzahl von Trainingsdaten zu ein und demselben Entscheidungszeitpunkt generiert werden kann. Als Beispiel soll die Belohnungsfunktion aus Formel (5.1) für eine beliebige Anzahl von Aufträgen in einer Warteschlange generalisiert werden. Die Aufträge einer Warteschlange können zu einer angenommenen endgültigen Sequenz gemäß der absteigenden Reihenfolge ihrer zugeordneten Prioritäten (Aktionen) sortiert werden. Die Belohnungsfunktion in Formel (5.3) zeigt, dass nun für jeden Auftrag an beliebiger Position $k$ in der angenommenen Sequenz ein Erwartungswert für die Fertigstellungszeit der jeweiligen Operation berechnet werden kann.

$$\begin{aligned} &{\mathcal{R}}_{{\mathbb{E}}[C]} \left( {i,k} \right) = \left( { - 1} \right)*{\mathbb{E}}_{\pi } [C_{{k,o}} \left( i \right)|A_{t} = a] = \left( { - 1} \right)*\\&{\mathbb{E}}_{\pi} \left[ {\left. {t_{{sim}} + {\tilde{p}}_{i} + \sum\limits_{{q = 1}}^{k} {p_{{q,o}} } } \right|A_{t} = a} \right] \hfill \\ \end{aligned} $$

(5.3)

In Kontrast zu Formel (5.1) liegt Formel (5.3) die Annahme zugrunde, dass die Belohnungsvergabe nicht erst dann erfolgt, wenn der Auftrag die Produktionsressource verlassen will, sondern genau zu dem Zeitpunkt, bevor der Auftrag auf die Produktionsressource gelangt. Das bedeutet, dass die Verweilzeit auf der Produktionsressource nicht in der Simulationszeit $t_{sim}$ enthalten ist und dementsprechend prognostiziert werden muss. Zu diesem Zweck sei für Formel (5.3) und folgende Formeln die Prozesszeiten $p_{j,o}$ und $\tilde{p}_{i}$ eingeführt. Die Prozesszeit $p_{j,o}$ (bzw. $p_{q,o}$ in Formel (5.3)) subsumiert alle Zeitanteile eines Auftrags $j$, welche für die Bearbeitung einer Operation $o$ anfallen. In jedem Fall beinhaltet $p_{j,o}$ stets die Operationszeit $o_{j}$. Je nach Problemart können zusätzliche Zeitanteile anfallen, bspw. Rüst- und Transferzeiten. Sofern verschiedene Zeitanteile stochastisch sind, gehen ebenjene als Erwartungswerte der jeweils zugrundeliegenden Wahrscheinlichkeitsverteilung in $p_{j,o}$ ein. Die Prozesszeit $\tilde{p}_{i}$ beschreibt die Restlaufzeit für die Bearbeitung der aktuellen Operation auf Produktionsressource $i$, zu welcher der Auftrag zugeordnet wurde. In der praktischen Umsetzung wird der Belohnungsfunktion in Formel (5.3) der Index der Produktionsressource, zu welcher der Auftrag zugeordnet wurde, als Parameter übergeben. Für die Berechnung der erwarteten Fertigstellungszeit der aktuellen Operation des $k$-ten Auftrags in der betrachteten Warteschlange werden die Restlaufzeit der Produktionsressource, die erwarteten Prozesszeiten der vorgelagerten Aufträge $\left( {1, \ldots ,\,k - 1} \right)$ sowie des betrachteten $k$-ten Auftrags kumuliert und mit der Simulationszeit $t_{sim}$ addiert. Ungeachtet dessen, ob die Bearbeitung von Aufträgen stochastischen Zeitanteilen unterliegt, handelt es sich bei den in Formel (5.3) kalkulierten Fertigstellungszeiten stets um Erwartungswerte, da die Annahme getroffen wird, dass alle Aufträge gemäß der aus dem Aktionsvektor $A_{t}$ resultierenden Reihenfolge bearbeitet werden. Tatsächlich wird jedoch nur ein Auftrag zur Bearbeitung ausgewählt. Die Reihenfolge der verbleibenden Aufträge zu den Folgezeitpunkten $t + 1, \,t + 2,\, \ldots , \,T$ kann aufgrund variierender Aktionsvektoren weiterhin Permutationen unterliegen. Eine Ausnahme kann der Erwartungswert der Fertigstellungszeit des zum Zeitpunkt $t$ ausgewählten Auftrags bilden. Der vorkalkulierte Erwartungswert entspricht für diesen Auftrag dann und nur dann der tatsächlichen Fertigstellungszeit, wenn alle Prozessparameter der Produktionsressource deterministisch sind.

Für zeitbasierte Optimierungskriterien, welche die Unpünktlichkeit von Aufträgen messen – konkret die Gesamtverspätung über alle Aufträge $T$, die Anzahl verspäteter Aufträge $U$ und die maximale Verspätung $L_{max}$ –, müssen die Belohnungsfunktionen aus den Formeln (5.1) und (5.3) konzeptionell erweitert werden. Zunächst sei festzustellen, dass die drei Optimierungskriterien $T$, $U$ und $L_{max}$ sich aus der Unpünktlichkeit einzelner Aufträge $L_{j}$ ergeben. Für einzelne Sequenzierungsentscheidungen eignet sich die Unpünktlichkeit $L_{j,o}$ einer Operation $o$ von Auftrag $j$ als maßgebliche Kennzahl zur Bildung von Belohnungsfunktionen, um die Verspätung von Aufträgen als Bewertungskriterium zu berücksichtigen. Der Berechnung der Unpünktlichkeit einer einzelnen Operation liegt zunächst die Überlegung zugrunde, dass die Fertigstellungsfrist eines Auftrags $d_{j}$ gewöhnlich so dimensioniert ist, dass alle Operationen fristgerecht bearbeitet werden können. Vor diesem Hintergrund kann $d_{j}$ zunächst auf einzelne Operationen heruntergebrochen werden. Formel (5.4) zeigt die im Rahmen dieser Arbeit präferierte Berechnungsvorschrift zur Ermittlung der Unpünktlichkeit $L_{j,o}$ einer beliebigen Operation $o$ von einem beliebigen Auftrag $j$.

$$ L_{j,o} = \left( {t_{sim} - d_{j} } \right){*}\left( {\frac{{p_{j,o} }}{{\mathop \sum \nolimits_{u = 1}^{{\left| {O_{j} } \right|}} p_{j,u} }}} \right) $$

(5.4)

Formel (5.4) basiert auf der Annahme, dass die Unpünktlichkeit der Operation erst dann berechnet wird, sobald der ausgewählte Auftrag die Produktionsressource verlassen will (d. h. $C_{j,o} = t_{sim}$). Die Unpünktlichkeit des Auftrags $\left( {t_{sim} - d_{j} } \right)$ wird mithilfe eines Faktors anteilsmäßig auf die aktuelle Operation heruntergebrochen. Der Faktor setzt die Prozesszeit der aktuellen Operation ins Verhältnis zur Summe aller (erwarteten) Prozesszeiten der am Auftrag auszuführenden Operationen.

Sofern Entscheidungen entsprechend der ersten Variante zur Formulierung von Sequenzierungsproblemen als ML-Aufgabe getroffen werden, ist es analog zu Formel (5.3) möglich eine Berechnungsvorschrift für die Unpünktlichkeit eines beliebigen Auftrags an einer beliebigen Sequenzposition $k$ zu formulieren.

$$\begin{gathered} {\mathbb{E}}_{\pi } {[}L_{k,o} \left( i \right){|} A_{t} = a] = \hfill \\ {\mathbb{E}}_{\pi } \left[ {\left. {\left( {\left( {t_{sim} + \tilde{p}_{i} + \mathop \sum \limits_{q = 1}^{k - 1} p_{q,o} } \right) - d_{k} } \right)* \left( {\frac{{p_{k,o} }}{{\mathop \sum \nolimits_{u = 1}^{{\left| {O_{j} } \right|}} p_{k,u} }}} \right) + p_{k,o} } \right|A_{t} = a} \right]\hfill \\ \end{gathered} $$

(5.5)

Im Unterschied zu Formel (5.4), jedoch analog zu Formel (5.3), unterliegt Formel (5.5) der Annahme, dass die Belohnungsvergabe vor Berücksichtigung der eigentlichen Verweilzeit des Auftrags auf der Produktionsressource erfolgt. Vor diesem Hintergrund müssen zunächst die Restlaufzeit der betrachteten Produktionsressource $i$ sowie die (erwarteten) Prozesszeiten aller Aufträge, die gemäß der aus dem Aktionsvektor resultierenden Sequenz vor Auftrag $k$ zu bearbeiten sind, auf die aktuelle Simulationszeit addiert werden $\left( {t_{sim} + \tilde{p}_{i} + \mathop{\sum}\nolimits_{q = 1}^{k - 1} p_{q,o} } \right)$. Das Zwischenergebnis ist die erwartete Startzeit von Operation $o$ von Auftrag $k$. Von dieser wird die Fertigstellungsfrist $d_{k}$ subtrahiert und mit dem gleichen Faktor aus Formel (5.4) gewichtet. Das Zwischenergebnis ist die Unpünktlichkeit von Operation $o$ von Auftrag $k$, ohne die Prozesszeit der Operation selbst zu berücksichtigen. Erst jetzt wird die (erwartete) Prozesszeit $p_{k,o}$ aufaddiert, um die prognostizierte Unpünktlichkeit zu erhalten, welche ebenfalls die Prozesszeit der betrachteten Operation miteinbezieht.

Die Formeln (5.4) und (5.5) eignen sich zwar als Ausgangsbasis für den Entwurf von verspätungsbewertenden Belohnungsfunktionen, können jedoch nicht als eigenständige Belohnungsfunktionen dienen. Würden die Ergebnisse der Formeln (5.4) bzw. (5.5) unmittelbar als Belohnung verwendet werden, würden verspätete Aufträge positiv belohnt und verfrühte Aufträge negativ bestraft werden. Ferner ist es ebenfalls nicht ausreichend die Ergebnisse der Formeln (5.4) und (5.5) mit dem Faktor $\left( { - 1} \right)$ zu multiplizieren. Auf diese Weise würden Verspätungen zwar bestraft werden, jedoch würden umso bessere Belohnungen resultieren, je früher ein Auftrag fertiggestellt wird. Eine solche Belohnungsvergabe ist aus zwei Gründen nicht sinnvoll. Aus produktionstheoretischer Sicht erzeugen zu früh fertiggestellte Aufträge zusätzliche Lagerkosten. Die Lagerkosten steigen in Korrelation mit der Zeitspanne, die ein Auftrag zu früh vor seiner Auslieferungsfrist fertiggestellt wird. Aus RL-theoretischer Sicht kann eine Belohnung von zu früh fertiggestellten Aufträgen dazu führen, dass Aufträge, die eine weit in der Zukunft liegende Fertigstellungsfrist besitzen, bevorzugt produziert werden, um die kumulative Belohnung zu maximieren. Dafür nimmt der Agent womöglich in Kauf, dass Aufträge mit einer Fertigstellungsfrist in naher Zukunft verspätet fertiggestellt werden. Idealerweise sollten alle Aufträge möglichst nah an, jedoch stets vor Eintritt ihrer Fertigstellungsfrist produziert werden.

Im Rahmen dieser Arbeit werden drei Strategien aufgezeigt, um auf Basis der Unpünktlichkeit von Aufträgen verspätungsbasierte Belohnungsfunktionen zu modellieren. Der ersten Strategie liegt die Idee zugrunde, dass Verspätungen bestraft werden, während verfrüht fertigstellte Operationen mit einer konstanten Belohnung $R_{E} \ge 0$ bewertet werden. Die resultierende Belohnungsfunktion bestraft somit lediglich das Ausmaß der Verspätungen von Aufträgen, vermeidet jedoch, dass Aufträge umso mehr belohnt werden, je früher sie eine Operation vollenden.

$${\mathcal{R}}_{T} \left( j \right) = {\mathcal{R}}_{{{\mathbb{E}}\left[ T \right]}} \left( j \right) = \left\{ \begin{array}{ll} R_{E} , & \quad wenn~L_{j,o} \le 0\\ \\ \left( { - 1} \right)*L_{j,o} ,&\quad sonst \hfill \\ \end{array} \right.$$

(5.6)

Hierbei repräsentiert $L_{j,o}$ die wahre oder geschätzte Unpünktlichkeit der $o$-ten Operation von Auftrag $j$. Je nachdem berechnet Formel (5.6) entweder ${\mathcal{R}}_{T}$ (wahre Unpünktlichkeit) oder ${\mathcal{R}}_{{{\mathbb{E}}\left[ T \right]}}$ (geschätzte Unpünktlichkeit). Die Idee der zweiten Strategie ist, dass sowohl verfrüht als auch verspätet vollendete Operationen bestraft werden. Jedoch werden verspätete Operationen durch einen Faktor $w_{T} > 1$ stärker bestraft als zu früh beendete Operationen.

$${\mathcal{R}}_{L} \left( j \right) = {\mathcal{R}}_{{{\mathbb{E}}\left[ L \right]}} \left( j \right) = \left\{ \begin{array}{ll} L_{j,o} , & wenn L_{j,o} \le 0 \\ \\ \left( { - w_{T} } \right)*L_{j,o} , & sonst \hfill \\ \end{array} \right.$$

(5.7)

Analog zu Formel (5.6) berechnet Formel (5.7) ${\mathcal{R}}_{L}$ oder ${\mathcal{R}}_{{{\mathbb{E}}\left[ L \right]}}$ in Abhängigkeit davon, ob es sich bei $L_{j,o}$ um die wahre oder geschätzte Unpünktlichkeit handelt. Die dritte Strategie normiert mittels Skalierung die erhaltenen Belohnungen in Wertebereiche, sodass sowohl verfrüht als auch verspätet beendete Operationen bestraft werden, wobei Verspätungen stets stärker bestraft werden als verfrühte Aufträge. Lediglich pünktliche Aufträge erhalten eine Belohnung von null. Aus dieser Überlegung resultiert die folgende Belohnungsfunktion in Abhängigkeit vom betrachteten Auftrag $j$.

$${\mathcal{R}}_{Ls} \left( j \right) = {\mathcal{R}}_{{{\mathbb{E}}\left[ {Ls} \right]}} \left( j \right) = \left\{ \begin{array}{ll} \frac{{L_{j,o} - \hat{E}_{min} }}{{\hat{E}_{max} - \hat{E}_{min} }}*\left( {R_{{\hat{E}min}} - R_{{\hat{E}max}} } \right) + R_{{\hat{E}max}} , & wenn~L_{j,o} \le 0 \hfill \\ \hfill \\ \frac{{L_{j,o} - \hat{T}_{min} }}{{\hat{T}_{max} - \hat{T}_{min} }}*\left( {R_{{\hat{T}min}} - R_{{\hat{T}max}} } \right) + R_{{\hat{T}max}} ,& ~sonst~~~~~~~~~~~~~~ \hfill \\ \end{array} \right.$$

(5.8)

wobei gilt…

$$\begin{aligned} & \left( {\hat{E}_{min} = 0} \right) \wedge \left( {\hat{E}_{max} > 0} \right) \wedge \left( {\hat{T}_{min} \approx 0 \wedge \hat{T}_{min} > 0} \right) \wedge \left( {\hat{T}_{max} > \hat{T}_{min} } \right) \wedge \\ & \left( {R_{{\hat{E}min}} > R_{{\hat{E}max}} > R_{{\hat{T}min}} > R_{{\hat{E}max}} } \right) \\ \end{aligned}$$

(5.9)

Auch im Fall von Formel (5.8) wird entweder ${\mathcal{R}}_{Ls} \left( j \right)$ oder ${\mathcal{R}}_{{{\mathbb{E}}\left[ {Ls} \right]}}$ in Abhängigkeit davon ermittelt, ob $L_{j,o}$ exakt berechnet oder lediglich prognostiziert wurde. Die Schranken $\hat{E}_{min}$ bzw. $\hat{E}_{max}$ sowie $\hat{T}_{min}$ bzw. $\hat{T}_{max}$ beschreiben die geschätzte minimale bzw. maximale Verfrühung eines Auftrags sowie die geschätzte minimale und maximale Verspätung eines Auftrags. Da der erste Fall in Formel (5.8) nicht nur für Auftragsoperationen gilt, die zu früh fertiggestellt wurden, sondern ebenfalls für solche, die exakt zur Fertigstellungsfrist vollendet werden ($L_{j,o} = 0$), wird im Rahmen dieser Arbeit die untere Schranke $\hat{E}_{min}$ stets gleich null gesetzt. Für die benutzerdefinierbare untere Schranke $\hat{T}_{min}$ wird angenommen, dass es sich um einen Wert nahezu gleich, jedoch größer als null handelt.

Die oberen Schranken $\hat{E}_{max}$ und $\hat{T}_{max}$ können über eine geeignete Berechnungsvorschrift geschätzt werden, welches auf das jeweilige Produktionsablaufplanungsproblem zugeschnitten ist. Beispielhaft sei ein Flexible-Job-Shop-Problem angenommen, bei dem alle Aufträge auf allen Produktionsressourcen bearbeitet werden können. Jede Operation eines jeden Auftrags kann auf jeder Produktionsressource bearbeitet werden, wobei die Operationszeiten zwischen den Produktionsressourcen variieren. Ferner sei angenommen, dass reihenfolgeabhängige Rüstzeiten zwischen den Aufträgen existieren. Für das skizzierte Problem kann $\hat{E}_{max}$ bspw. über die folgende Formel geschätzt werden.

$$\hat{E}_{max} = \mathop {\max }\limits_{j} \left( {d_{j} - \mathop \sum \limits_{o = 1}^{{\left| {O_{j} } \right|}} \mathop {{\text{min}}}\limits_{i} o_{i,j} } \right)$$

(5.10)

Formel (5.10) liegt die Überlegung zugrunde, dass alle Operationen desjenigen Auftrags, bei dem die Differenz zwischen seiner Fertigstellungsfrist und der Summe all seiner Operationszeiten maximal ist, ohne zusätzliche Wartezeiten und ohne vorhergehende Aufträge (d. h. $s_{j,k} = 0$) bearbeitet werden. Um die Differenz zwischen der Fertigstellungsfrist und der Summe der Bearbeitungszeiten eines Auftrags zu maximieren, wird in Formel (5.8) stets für jede Operation diejenige Produktionsressource gewählt, bei welcher die Operationszeit minimal ist.

Demgegenüber kann $\hat{T}_{max}$ unter der Annahme geschätzt werden, dass der Agent im ungünstigsten Fall alle Operationen von allen Aufträgen stets ein und derselben Produktionsressource (ggf. pro Bearbeitungsstufe) zuweist. Infolgedessen kann $\hat{T}_{max}$ bspw. gemäß der folgenden Formel berechnet werden.

$$\hat{T}_{max} = \mathop \sum \limits_{j = 1}^{\left| J \right|} \mathop {\max }\limits_{k} s_{j,k} + \mathop {\max }\limits_{i} \left( {\mathop \sum \limits_{j = 1}^{\left| J \right|} \mathop \sum \limits_{o = 1}^{{\left| {O_{j} } \right|}} \overline{o}_{i,j} } \right) - \mathop {\min }\limits_{j} d_{j}$$

(5.11)

Die Idee von Formel (5.11) ist, dass alle Operationen desjenigen Auftrags, der die engste Fertigstellungsfrist aufweist, als letztes auf derjenigen Produktionsressource bearbeitet werden, zu welcher der Agent exklusiv Auftragsoperationen alloziert. Formel (5.11) impliziert zwei Annahmen, nämlich (i) dass der Agent alle Aufträge auf diejenige Produktionsressource alloziert, bei welcher die Summe aller Operationszeiten über alle Aufträge maximal ist und (ii) dass für jeden Auftrag stets die maximale Rüstzeit veranschlagt wird, d. h. dass jeder Auftrag $j$ immer nach demjenigen Auftrag $k$ bearbeitet wird, bei welchem die Rüstzeit von Auftrag $j$ maximiert wird. Es sei angemerkt, dass Annahme (ii) lediglich einer vereinfachten Berechnung von $\hat{T}_{max}$ dient. In den meisten Fällen würde Annahme (ii) zu nicht realisierbaren Lösungen für das Produktionsablaufplanungsproblem führen, weil nicht ausgeschlossen wird, dass ein Auftrag $k$ mehrere nachfolgende Aufträge $j$ besitzt, obgleich jedem Auftrag $k$ nur genau ein Auftrag $j$ nachfolgen kann. Um eine noch präzisere Schätzung für $\hat{T}_{max}$ abzugeben, müsste korrekterweise diejenige Fertigungssequenz ermittelt werden, bei der die Summe aller Rüstzeiten maximiert wird. Hierbei handelt es sich jedoch um ein eigenständiges Optimierungsproblem, dessen exakte Lösung zur Ermittlung einer oberen Schranke zu aufwändig ist. Zudem beeinträchtigt die geschilderte Annahme nicht die Verwendung von Formel (5.11) als obere Schranke, sondern garantiert, im Gegenteil, dass die ermittelte obere Schranke $\hat{T}_{max}$ tatsächlich größer als die wahre maximal mögliche Verspätung ist. Aufgrund der Tatsache, dass in Formel (5.11) stets die maximalen Rüstzeiten kumuliert werden, ungeachtet der Gültigkeit der resultierenden Reihenfolge, kann das gültige Maximum lediglich eine gleich große oder kleinere kumulierte Rüstzeit aufweisen.

Die dargestellten Berechnungsvorschriften sollen an dieser Stelle ausreichen, um die Grundprinzipien der Gestaltung von Belohnungsfunktionen für Sequenzierungsentscheidungen darzustellen. Wie bereits erwähnt, bilden die Formeln (5.1–5.6) die Möglichkeit zur Herleitung vieler weiterer problemspezifischer Belohnungsfunktionen. Dies wurde beispielhaft an Formel (5.1) anhand der Abwandlung in Formel (5.2) demonstriert.

5.3.5.2 Belastungsorientierte Belohnungsfunktionen

Wird der Produktionsprozess weiter entgegengesetzt des Materialflusses verfolgt, so liegt der Fokus der Betrachtung nun auf der Allokation von Aufträgen zu Produktionsressourcen. In die Überlegungen zur Gestaltung von Belohnungsfunktionen für Allokationsentscheidungen muss miteinbezogen werden, dass ein Auftrag, nach dessen Allokation, zunächst in einer Warteschlange gepuffert wird und erst durch eine Sequenzierungsentscheidung zur Bearbeitung auf die entsprechende Produktionsressource gelangt. Im Umkehrschluss bedeutet dies, dass sich zeitbasierte Produktionskennzahlen nur bedingt zur Bewertung von Allokationsentscheidungen eignen, weil die Fertigstellungszeiten von Aufträgen maßgeblich durch Entscheidungen des nachgelagerten Sequenzierungsagenten beeinflusst werden. Somit erlaubt das Belohnungssignal keinen eindeutigen Rückschluss auf die Entscheidungsgüte des Allokationsagenten. Zeitbasierte Produktionskennzahlen eignen sich lediglich dann für Allokationsentscheidungen, wenn die nachgelagerte Sequenzierung von Aufträgen einer deterministischen und statischen Steuerungslogik folgt, z. B. einer Prioritätsregel. In diesem Ausnahmefall kann die Güte der Allokationsentscheidung auf Basis des Fertigstellungszeitpunkts bewertet werden, da sich zwischen den Zeitschritten lediglich die Entscheidungspolitik für die Allokation wandelt. Hingegen bleibt die Entscheidungspolitik für die Sequenzierung unverändert und vorberechenbar. Abseits des geschilderten Ausnahmefalls gilt es somit andere Arten von Produktionskennzahlen zu identifizieren, mit welchen zum einem Allokationsentscheidungen eindeutig bewertet werden können und welche zum anderen mit der zu optimierenden Zielfunktion korrelieren.

Produktionskennzahlen, die intuitiv für die Bewertung von Allokationsentscheidungen prädestiniert scheinen, sind ebensolche, die sich aufgrund und unmittelbar nach der Allokation eines Auftrags verändern. Hierzu zählt insbesondere die Arbeitslast auf einer Produktionsressource. Eine Belohnungsfunktion, die auf Basis der Arbeitslast $W_{i}^{\left( l \right)}$ von Ressource $i$ in Produktionsbereich $l$ Allokationsentscheidungen bewertet, kann wie folgt definiert werden.

$${\mathcal{R}}_{W} \left( {i, l} \right) = \left( { - 1} \right)*W_{i}^{\left( l \right)} = \left( { - 1} \right)*\left( {\tilde{p}_{i}^{\left( l \right)} + \mathop \sum \limits_{q = 1}^{{\left| {Q_{i} } \right|}} p_{i,j,o}^{\left( l \right)} } \right)$$

(5.12)

Hierbei beschreibt $\tilde{p}_{i}^{\left( l \right)}$ die verbleibende Laufzeit derjenigen Operation, die zum Erhebungszeitpunkt auf Ressource $i$ in Produktionsstufe $l$ bearbeitet wird. Analog zu Formel (5.1) ist es für die Belohnungsvergabe notwendig, dass die Arbeitslast $W_{i}^{\left( l \right)}$ mit dem Faktor $\left( { - 1} \right)$ multipliziert wird. Die Intention ist, dass jegliche Arbeitslast auf einer Produktionsressource bestraft wird. Aufgrund der Tatsache, dass ein Auftrag in jedem Fall einer Produktionsressource zugeordnet werden muss, minimiert der Agent die erhaltene Bestrafung, indem er die Aufträge möglichst gleichmäßig entsprechend ihrer Arbeitslast auf die Produktionsressourcen verteilt. Eine gleichmäßige Verteilung der Arbeitslast resultiert wiederum in einem höheren Ausnutzungsgrad aller Ressourcen derselben Produktionsstufe. Auf diese Weise werden zudem die Pufferzeiten von Aufträgen in den Warteschlangen vor den Produktionsressourcen verringert. Eine weitere Kennzahl für die Bewertung der Gleichmäßigkeit der Belegung von Produktionsressourcen ist die Standardabweichung der Arbeitslast $W_{\sigma }$, die über alle Ressourcen desselben Produktionsbereichs ermittelt wird. Eine auf der Standardabweichung der Arbeitslast $W_{\sigma }$ basierende Belohnungsfunktion kann in Abhängigkeit vom betrachteten Produktionsbereich $l$ folgendermaßen definiert werden.

$$ {\mathcal{R}}_{W\sigma } \left( l \right) = \left( { - 1} \right)*\sqrt {\frac{1}{{\left| {M^{\left( l \right)} } \right| - 1}}*\mathop \sum \limits_{i = 1}^{{\left| {M^{\left( l \right)} } \right|}} \left( {W_{i}^{\left( l \right)} - \frac{{\mathop \sum \nolimits_{h = 1}^{{\left| {M^{\left( l \right)} } \right|}} W_{h}^{\left( l \right)} }}{{\left| {M^{\left( l \right)} } \right|}}} \right)^{2} } $$

(5.13)

Die Standardabweichung der Arbeitslast einer Produktionsstufe ist ebenfalls als Bestrafungsfunktion zu verstehen. Sie wird daher mit dem Faktor $\left( { - 1} \right)$ multipliziert, um Agentenentscheidungen zu bewerten. Ein Anstieg der Standardabweichung bedeutet eine zunehmend ungleichmäßige Belegung der Produktionsressourcen und wird dementsprechend bestraft. Die beste Belohnung, die ein Allokationsagent gemäß Formel (5.13) erhalten kann, ist eine Standardabweichung von null. In diesem Fall sind alle Produktionsressourcen absolut gleichmäßig belastet.

5.3.6 Training von Agenten

Sofern alle Schritte des Vorgehensmodells aus Abbildung 5.6 (Abschnitt 5.3) bis hierhin durchlaufen wurden, sind nun alle Komponenten der agentenbasierten Produktionsablaufsteuerung implementiert, um das Agententraining zu starten. Das Training von Agenten ist kein geradliniger Prozess. Das Konvergenzverhalten des Agenten während des Trainings, respektive die Konvergenzrichtung und die Konvergenzgeschwindigkeit, hängen von einer Vielzahl von Einflussgrößen ab. Hierbei impliziert bereits das Vorgehensmodell aus Abbildung 5.6 eine empfohlene Reihenfolge für das experimentelle Ausloten der verschiedenen Einflussgrößen. Demnach sollen zunächst (i) die Belohnungsfunktion, danach (ii) die Hyperparameter des gewählten RL-Verfahrens und schließlich (iii) das RL-Verfahren selbst experimentell variiert werden, um den Trainingsprozess zu optimieren. Dem vorgeschlagenen Vorgehen liegt die Überlegung zugrunde, dass die Belohnungsfunktion den größten Einfluss auf das Konvergenzverhalten des Agenten während des Trainings besitzt, weil diese stets problem- und benutzerspezifisch implementiert wird. Hingegen sind die meisten RL-Verfahren (und deren Hyperparameter) generisch und problemunabhängig konzipiert. Die Priorisierung von Hyperparameter-Experimenten gegenüber der Variation des RL-Verfahrens gilt insbesondere dann, wenn das RL-Verfahren eigenständig implementiert wird, sodass jedes zu testende Verfahren mit einem erheblichen Zeitaufwand für dessen Implementierung einhergeht. Besteht hingegen die Möglichkeit vorgefertigte RL-Verfahren aus einer Programmbibliothek zu verwenden, können alternativ zunächst verschiedene RL-Verfahren mit standardmäßigen Parameterkonfigurationen ausgelotet werden.

In den vorherigen Abschnitten wurde bereits die Auswahl von RL-Verfahren sowie die Gestaltung von Belohnungsfunktionen diskutiert. Vor diesem Hintergrund konzentriert sich der folgende Abschnitt auf die Anpassung von Hyperparametern von RL-Verfahren, um das Konvergenzverhalten des Agenten während des Trainings zu verbessern. Es existiert eine Vielzahl von Methoden für die Untersuchung und Optimierung von Hyperparametern. Eine ausführliche Übersicht und Diskussion findet sich bspw. in (Yu und Zhu 2020). Anhand der folgenden vier beispielhaften Verfahren sollen verschiedene Prinzipien und Herangehensweisen für die Untersuchung und Optimierung von Hyperparametern veranschaulicht werden:

• Rastersuche: Es handelt sich um ein automatisiertes Verfahren für die strukturierte Erprobung verschiedener Wertekombinationen von Hyperparametern. Voraussetzung ist, dass die möglichen Werte eines jeden Hyperparameters über eine diskrete Menge abgebildet werden können. Kontinuierliche, nicht beschränkte Hyperparameter müssen zunächst auf eine endliche diskrete Untermenge von Werten eingegrenzt werden. Angenommen dass $n$ Hyperparameter in Wertebereiche mit jeweils $m$ Werten diskretisiert werden, so ergibt sich ein $\left( {n \times m} \right)$-Raster von Parameterwerten und $m^{n}$ möglichen Parameterkombinationen, die vollständig enumeriert werden.

• Zufallssuche: Es werden zufällige Kombinationen von Hyperparametern durchprobiert. Im Unterschied zur Rastersuche müssen kontinuierliche Hyperparameter nicht diskretisiert werden. Die Zufallssuche kann im einfachsten Fall über eine Menge von Wahrscheinlichkeitsverteilungen realisiert werden, aus welchen Stichproben für jeden Hyperparameter gezogen werden. Ferner können ebenfalls metaheuristische Verfahren für die Steuerung der Zufallssuche von Hyperparameterkombinationen eingesetzt werden.

• Bayes’sche Optimierung (BO): Als eines der gradientenfreien, modellsuchenden RL-Verfahren wurde das Funktionsprinzip der BO bereits in Abschnitt 3.4.1 kurz erläutert. Eine detaillierte Beschreibung der BO ist als Anhang E dem elektronischen Zusatzmaterial beigefügt. Das BO-Verfahren generiert Parameterkombinationen entweder strukturiert, bspw. über eine Rastersuche, oder zufällig, bspw. via Monte-Carlo-Simulation. Haupteigenschaft der BO ist, dass die Evaluation von Parameterkombinationen nicht arbiträr erfolgt, sondern eine Akquisitionsfunktion über den nächsten zu evaluierenden Lösungskandidaten entscheidet. Die Arbeitsweise der Akquisitionsfunktion wird in Anhang E am Beispiel der »Erwarteten Verbesserung« $EI$ dargestellt.

• Sensitivitätsanalyse: Das Verfahren dient der Evaluation einzelner Hyperparameter hinsichtlich ihres Einflusses auf den Trainingsprozess. Zu diesem Zweck wird pro Experiment lediglich der Wert eines Hyperparameters variiert und dessen Auswirkung auf den Trainingsprozess beobachtet. Im Kontrast zur Raster- und Zufallssuche handelt es sich bei der Sensitivitätsanalyse um kein Verfahren für die Optimierung von Hyperparametern. Vielmehr dient die Sensitivitätsanalyse der Entwicklung einer Intuition dafür, welche Hyperparameter im Rahmen einer manuellen Experimentplanung priorisiert untersuchen werden sollten.

Im Folgenden sollen die wichtigsten Hyperparameter von gradientenabhängigen und gradientenfreien RL-Verfahren dargestellt und ihr Einfluss auf den Trainingsprozess diskutiert werden. Zunächst sollen die Hyperparameter von gradientenabhängigen RL-Verfahren betrachtet werden. Tabelle 5.4 stellt die wichtigsten Hyperparameter für gradientenfreie RL-Verfahren vor und diskutiert deren Bedeutung für den Lernprozess. Darüber hinaus existieren eine Vielzahl weiterer RL-verfahrensspezifischer Hyperparameter, deren präzise Erläuterung jedoch über den Rahmen dieser Arbeit hinausgeht. Stellvertretend seien im Folgenden zwei Beispiele angeführt: (i) Für alle gradientenabhängigen RL-Verfahren, deren Lernprozess nicht auf N-Step-Bootstrapping basiert, muss die Größe des Erfahrungsspeichers definiert werden. Diese bestimmt die Gesamtmenge an Transitionen, aus welcher ein Agent ein zufälliges Trainingslos generieren kann. (ii) Die meisten EPA-Verfahren verwenden stochastische Techniken, um die Exploration des Lösungsraums zu forcieren. Im A2C- und A3C-Algorithmus (stochastische EPA-Verfahren) wird zu diesem Zweck die Entropie der Entscheidungspolitik im Performanzgradienten mitberücksichtigt (Mnih et al. 2016). Über einen benutzerdefinierten Koeffizienten kann die entropie-basierte Exploration feinjustiert werden. Hingegen addieren der DDPG- und TD3-Algorithmus (deterministische EPA-Verfahren) einen zufälligen Term auf berechnete Aktionen, um die Ergebnisse zu verrauschen. Vor diesem Hintergrund kann u. a. die Standardabweichung des Rauschens als weiterer Hyperparameter berücksichtigt werden.

Hinsichtlich der Auswahl von Neuronenmodellen für die versteckte KNN-Architektur sei auf Anhang A im elektronischen Zusatzmaterial verwiesen, in welchem nicht nur die Grundlagen zu KNN, sondern ebenfalls die in Tabelle 5.4 angeführten Neuronenmodelle »Perzeptron«, »LSTM« und »GRU« im Detail erklärt werden. Zusammengefasst wird das Perzeptron für die Modellierung von rein vorwärts gerichteten KNN-Strukturen verwendet. Das Perzeptron kann als Standard für die Modellierung von KNN-basierten RL-Agenten betrachtet werden. Es eignet sich ebenfalls für die meisten Anwendungsfälle in der Produktionsablaufplanung. Eine Ausnahme bildet bspw. die erste Formulierungsvariante von Sequenzierungsproblemen als ML-Aufgabe (Abbildung 5.12 in Abschnitt 5.3.2.2), bei der die Auswahl des nächsten zu produzierenden Auftrags mittels Priorisierung erfolgt. Bei $n$ Aufträgen in einer Warteschlange muss der Agent zunächst $n$ Aktionen (Prioritäten) berechnen, bevor ein konkreter Auftrag ausgewählt werden kann. Intuitiv erscheint es sinnvoll, dass der Agent bei der Priorisierung eines spezifischen Auftrags in dessen Entscheidung miteinbezieht, welche Charakteristiken die umliegenden Aufträge im Puffer besitzen und wie der Agent diese priorisiert hat. Derartige sequenzielle Zusammenhänge können mit rein vorwärtsgerichteten KNNs nicht analysiert werden. Sogenannte rekurrente neuronale Netze (RNN) sind hierzu imstande, indem sie Informationen aus vorhergehenden Entscheidungen speichern können. Die Neuronenmodelle »LSTM« und »GRU« wurden speziell für die Modellierung von RNN-Strukturen entwickelt, die durch gradientenabhängige Lernverfahren trainiert werden.

Die Auswahl des Optimierungsverfahrens und dessen Parametrisierung repräsentieren ebenfalls benutzerdefinierbare Freiheitsgrade für die Verbesserung des Konvergenzverhaltens. Die meisten RL-Bibliotheken verwenden standardmäßig den Adam-Algorithmus (Kingma und Ba 2015) für das Training von Agenten. Der Grund ist zum einen, dass in Adam viele der methodischen Verbesserungen implementiert sind, die in den vergangenen Jahre für das ursprüngliche stochastische Gradientenabstiegsverfahren eingeführt wurden. Zum anderen überzeugt der Algorithmus durch ein relativ robustes Konvergenzverhalten, weitgehend ungeachtet der gewählten Hyperparameter (Goodfellow et al. 2016). Abgesehen von der Lernrate $\alpha$ ist vor diesem Hintergrund die experimentelle Untersuchung der Parametrisierung des Optimierungsverfahrens als niedrig zu priorisieren, sofern der Adam-Algorithmus für das Agententraining verwendet wird. Nichtsdestotrotz soll am Beispiel des Adam-Algorithmus kurz dargestellt werden, welche zusätzlichen Parameter benutzerdefinierbar sind, um das Agententraining zu beeinflussen. Wie viele stochastische Gradientenabstiegsverfahren verwendet auch Adam die sogenannte Momentum-Technik, um die Lernrate während des Trainingsprozesses adaptiv zu justieren. Das Momentum merkt sich die Gradienten aus vergangenen Trainingsschritten mittels Kumulation. Die Lernrate wird durch das Momentum erster Ordnung (kumuliertes Momentum) und zweiter Ordnung (kumuliertes Momentum zum Quadrat) korrigiert. Über die Koeffizienten $\beta_{1}$ (Standardwert $= 0,9$) bzw. $\beta_{2}$ (Standardwert $= 0,999$) kann der Einfluss des Momentums erster Ordnung bzw. zweiter Ordnung auf die Lernrate angepasst werden. Beim Adam-Algorithmus werden die Parameter des Agenten über den Quotienten aus dem Momentum erster Ordnung und der Wurzel des Momentums zweiter Ordnung aktualisiert. Die Wurzel des Momentums zweiter Ordnung steht im Nenner des Quotienten und kann mitunter Werte annehmen, die dem Wert null entsprechen. Der benutzerdefinierbare Term $\epsilon$ (Standardwert $= 10^{ - 8}$) wird zu diesem Zweck dem Nenner hinzuaddiert, um die numerische Stabilität des Adam-Algorithmus zu gewährleisten. Ferner erlauben einige Implementierungen des Adam-Algorithmus, z. B. die PyTorch-Implementierung, eine zusätzliche Regularisierung der Gradienten, wodurch das Risiko einer Überanpassung der Agentenparameter an die Trainingsdaten reduziert wird. Mithilfe des Koeffizienten $\lambda$ (Standartwert $= 0$ – keine Regularisierung) kann die Ausprägung der Regularisierung benutzerspezifisch angepasst werden.

Tabelle 5.4 Wichtige Hyperparameter für gradientenabhängige bestärkende Lernverfahren

Entsprechend ihrer Vielfalt und Individualität sind ebenfalls die Hyperparameter für jedes gradientenfreie RL-Verfahren spezifisch. Vor diesem Hintergrund ist eine verfahrensübergreifende Darstellung der Hyperparameter nicht zweckmäßig. Analog zu den theoretischen Grundlagen in Abschnitt 3.4 werden stattdessen die Hyperparameter des NEAT-Algorithmus diskutiert, der im Rahmen dieser Arbeit als Stellvertreter der gradientenfreien RL-Verfahren untersucht wird. NEAT ist für die stellvertretende Diskussion der Hyperparameter von gradientenfreien RL-Verfahren prädestiniert, da der Algorithmus eine große Bandbreite verschiedenartiger Stellgrößen aufweist, welche sowohl die stochastische Suche nach einem geeigneten Agentenmodell als auch die stochastische Suche nach geeigneten Modellparametern adressieren. Tabelle 5.5 enthält eine Auflistung aller Hyperparameter von NEAT gemäß der Implementierung NEAT-Python. Ferner beinhaltet die Tabelle beispielhafte Werte für jeden Hyperparameter. Die Beispiele repräsentieren keine Empfehlungen, sondern dienen lediglich dem Zweck, ein Gespür zu vermitteln, in welchen ungefähren Wertebereichen sich die verschiedenen Hyperparameter ansiedeln. Im Folgenden soll die Bedeutung der einzelnen Hyperparameter für das Agententraining dargelegt werden.

Tabelle  5.5 – Sektion »Allgemeine Parameter«

Die Hyperparameter in dieser Sektion steuern insbesondere die Laufzeit von NEAT sowie die Exploration des Lösungsraums. Die Anzahl der Generationen entspricht der Anzahl der Iterationen, die NEAT durchläuft, bevor das Verfahren terminiert. Hierbei wird in jeder Iteration eine Anzahl von Lösungskandidaten entsprechend des Parameters »Populationsgröße« erzeugt und evaluiert. Eine hohe Anzahl von Generationen und eine hohe Populationsgröße gehen mit einer umfangreicheren Exploration des Lösungsraums einher, erhöhen jedoch ebenfalls die Laufzeit des Algorithmus. Das Fitnesskriterium bestimmt die Art und Weise, wie die Fitness der gesamten Population, basierend auf der Fitness einzelner Genome, berechnet wird. Wahlweise kann hierfür die minimale, maximale oder mittlere Fitness über alle Genome ermittelt werden. Der Fitnessschwellenwert ist ein optionales Terminationskriterium. Sofern die Fitness der Population den Fitnessschwellenwert überschreitet, endet der Algorithmus. Hieraus folgt, dass für die Bildung der Fitnessfunktion die Zielfunktion mit dem Faktor $- 1$ multipliziert werden muss, sofern das zugrundeliegende Optimierungsproblem zu minimieren ist. Der Grund ist, dass NEAT-Python stets bestrebt ist die Fitness der Population zu maximieren. Ferner existiert ein weiteres optionales Terminationskriterium. Gemäß diesem endet der Algorithmus vorzeitig, sofern die Population aufgrund von stagnierenden Fitnesswerten ausstirbt und der entsprechende Merker auf FALSCH gesetzt wurde. Besitzt der Merker hingegen den Wert WAHR, wird im Fall des Aussterbens eine neue Population erstellt und evolviert, sofern die maximale Anzahl von Generationen noch nicht erreicht wurde.

Tabelle 5.5 Hyperparameter des NEAT-Algorithmus der Programmbibliothek NEAT-Python (vgl. McIntyre et al. 2017b) stellvertretend für gradientenfreie bestärkende Lernverfahren

Tabelle  5.5 – Sektion »Genom-Parameter«

Die Hyperparameter in dieser Sektion definieren zum einen die Größe des untersuchbaren Lösungsraums, zum anderen die Schrittweite, mit welcher der Lösungsraum abgetastet wird. Die Größe des Lösungsraums resultiert aus den Wertebereichen und -mengen der verschiedenen Genattribute eines Genoms, aus welchen wiederum die Struktur und Parameter des jeweiligen KNN resultieren. Synaptische Gewichte sowie neuronale Bias-Terme und Reaktivitätswerte¹ werden über kontinuierliche Wertebereiche abgebildet und durch benutzerdefinierte Minima und Maxima begrenzt. Die möglichen Aktivierungs- und Netzeingabefunktionen werden wiederum als diskrete Wertemengen durch die Benutzer*innen definiert. Die Spannbreiten der Wertebereiche und die Kardinalitäten der Wertemengen bestimmen maßgeblich die Größe des Lösungsraums. Einen weiteren Einfluss auf die Größe des Lösungsraum besitzt der Merker für rekurrente synaptische Verbindungen. Sofern der Merker auf WAHR gesetzt wird, pflegen Neuronen nicht ausschließlich vorwärtsgerichtete Verbindungen zu nachgelagerten Neuronen, sondern ebenfalls rückwärtsgerichtete (rekurrente) Verbindungen zu sich selbst und / oder zu vorgelagerten Neuronen. Im Allgemeinen birgt die Vergrößerung des Lösungsraums das Potenzial, bessere Lösungen zu ermitteln. Gleichermaßen kann sich das Konvergenzverhalten verschlechtern, da aus der Vergrößerung des Lösungsraums ebenfalls eine höhere Anzahl qualitativ minderwertiger Lösungen resultieren kann. Die Schrittweite zur Abtastung des Lösungsraums wird implizit durch die Mutationswahrscheinlichkeiten und -standardabweichungen der neuronalen und synaptischen Attribute sowie durch die Wahrscheinlichkeiten für das Erstellen bzw. Eliminieren von Neuronen und Synapsen bestimmt. Im Fall der Mutation eines synaptischen Gewichts, eines neuronalen Bias-Terms oder eines neuronalen Reaktivitätswerts wird mithilfe der jeweiligen Mutationsstandardabweichung eine positive oder negative Zufallszahl aus einer um den Wert null zentrierten Normalverteilung gezogen und auf das jeweilige Attribut addiert. Im Fall der Mutation einer Aktivierungs- oder Netzeingabefunktion wird aus der entsprechenden Menge eine neue Aktivierungs- bzw. Netzeingabefunktion per Zufallsstichprobe gezogen. Sofern ein neues Neuron oder eine neue Synapse erstellt wird, werden die jeweiligen initialen Hyperparameter angewandt, um das neue Gen zu parametrisieren. In NEAT können Synapsen zudem aktiv oder inaktiv sein. Zweiteres bewirkt, dass der Wert, der über die inaktive Synapse gesendet und gewichtet wird, nicht von der Netzeingabefunktion des am Ausgang angeschlossenen Neurons berücksichtigt wird. Je größer die Mutationswahrscheinlichkeiten und -standardabweichungen, desto mehr neigt NEAT dazu den Lösungsraum großflächig zu untersuchen. Zu viele gleichzeitige oder zu starke Mutationen steigern demgegenüber das Risiko, dass der Algorithmus einer lokal optimalen Region zu schnell entweicht, ohne deren Lösungsgüte ausreichend ausgelotet zu haben. Geringe Mutationswahrscheinlichkeiten und -standardabweichungen begünstigen, dass eine lokal optimale Region intensiver ausgelotet werden kann, da sich das Genom allmählich und partieller verändert. Demgegenüber kann es länger dauern, bis NEAT zu einer guten Lösung konvergiert. Das Konvergenzverhalten des Algorithmus kann des Weiteren durch den Merker für einzelne strukturelle Mutationen sowie durch den Merker zur Absicherung struktureller Mutationen feinjustiert werden. Sofern der erstgenannte Merker auf WAHR gesetzt wird, führt NEAT pro Generation maximal eine strukturelle Mutation an jedem Genom durch. KNN-Strukturen mutieren somit langsamer und kontrollierter, wodurch das Ausloten von lokalen optimalen Regionen begünstigt wird. Falls der zweitgenannte Merker auf WAHR gesetzt wird, werden zwei Techniken aktiviert, um strukturelle Mutationen zu forcieren. Erstens wird ein neues synaptisches Gen anstelle des neuronalen Gens hinzugefügt, sofern NEAT ein weiteres neuronales Gen zu einem Genom hinzufügen will, das noch keine synaptischen Gene besitzt. Zweitens wird die bereits existierende Synapse aktiv geschaltet, wenn NEAT eine synaptische Verbindung herstellen möchte, die bereits existiert. Abschließend bietet die Sektion einige Hyperparameter, um die Generierung von Startlösungen zu steuern. Hierunter zählen die initialen Mittelwerte und Standardabweichungen für die Parametrisierung von synaptischen Gewichten sowie von neuronalen Bias-Termen und Reaktivitätswerten. Wahlweise kann für jede Startlösung eine fixe Anzahl versteckter Neuronen definiert werden. Zudem können Benutzer*innen festlegen, ob und wie die Neuronen eines jeden Genoms der Anfangspopulation synaptisch verbunden sind (z. B. nicht verbunden, voll verbunden oder zufällig verbunden).

Tabelle  5.5 – Sektion »Spezies-Parameter«

Die Hyperparameter in dieser Sektion beeinflussen ebenfalls die Exploration des Lösungsraums sowie die Ausbeutung lokaler Optima. Wie bereits in Abschnitt 3.4.2 beschrieben, unterteilt NEAT die Gesamtpopulation in Spezies, um Genomen die Möglichkeit einzuräumen, die Parameter von topologischen Innovationen über einige Generationen zu optimieren. Hierbei ist es möglich, dass eine komplette Spezies vollständig ausstirbt, sofern der Fitnesswert der jeweiligen Spezies über eine benutzerdefinierte Anzahl von Generationen stagniert. Das ebenfalls durch Benutzer*innen definierbare Fitnesskriterium für Spezies funktioniert analog zum Fitnesskriterium der Population. Je höher die Anzahl der Generationen ist, über welche die Fitness einer Spezies stagnieren darf, desto tiefer kann NEAT bestimmte Lösungsregionen untersuchen. Demgegenüber reduziert sich die Fähigkeit des Algorithmus, den Lösungsraum zeiteffizient in der Breite zu untersuchen. Benutzer*innen können des Weiteren jeweils eine fixe Anzahl von elitären Spezies und von elitären Genomen festlegen. Angenommen es werden $n$ elitäre Spezies und $m$ elitäre Genome je Spezies definiert, so sind die $n$ besten Spezies vom Aussterben durch Stagnation ausgenommen, während die $m$ besten Genome einer Spezies von jeglichen Mutationen ausgeschlossen werden. Auf diese Weise wird zum einen verhindert, dass während der Laufzeit die komplette Population ausstirbt. Zum anderen wird abgesichert, dass die bisher besten gefundenen Lösungen bewahrt bleiben. Eine hohe Anzahl elitärer Spezies und Genome mindert die Fähigkeit des Algorithmus, den Lösungsraum großflächig zu durchkämmen. Der Anteil reproduktionsfähiger Genome regelt, wie viel Prozent der besten Genome je Spezies für die Erzeugung der nächsten Generation gekreuzt werden können. Ferner muss definiert werden, wie viele Genome mindestens einer Spezies angehören, nachdem die Population evolviert wurde. Der Hauptindikator für die Zugehörigkeit eines Genoms zu einer Spezies stellt der Kompatibilitätsschwellenwert dar. Ein Genom gehört nur dann zu einer Spezies, wenn die genetische Distanz zwischen dem Genom und dem Speziesvertreter den Kompatibilitätsschwellenwert nicht überschreitet. Über die Kompatibilitätskoeffizienten kann der Einfluss der neuronalen und synaptischen Distanz auf die genetische Gesamtdistanz feinjustiert werden. Die entsprechenden Berechnungsvorschriften wurden bereits in Abschnitt 3.4.2 dargelegt (Formeln (3.21–23)).

5.4 Zusammenfassung der Methode

In diesem Kapitel wurde das Hauptartefakt der vorliegenden Arbeit beschrieben – eine Methode zum Einsatz von bestärkenden Lernverfahren für die Produktionsablaufplanung. Basierend auf einer Analyse der aktuell etablierten Produktionsablaufplanung gemäß des Aachener PPS-Modells wurden in Abschnitt 5.1 zunächst acht Anforderungen an die zu entwickelnde Methode formuliert. Die erste wesentliche Anforderung (A1), dass die Methode zur Verwendung von RL-trainierten Agenten für die Produktionsablaufplanung anleiten soll, wurde in Abschnitt 5.2 adressiert. Der zweiten wesentlichen Anforderung (A2), dass die Methode die Konzeption und Implementierung von RL-Verfahren für die Produktionsablaufplanung beschreiben soll, wurde in Abschnitt 5.3 Rechnung getragen.

Um Anforderung A1 zu berücksichtigen, wurden in Abschnitt 5.2 die Grundzüge der agentenbasierten Produktionsablaufsteuerung hergeleitet. Die in diesem Kontext vorgestellten Prozessmodelle für die Ressourcenbelegungsplanung (Abbildung 5.4 in Abschnitt 5.2.1) sowie für die Reihenfolgeplanung und Losbildung (Abbildung 5.5 in Abschnitt 5.2.2) erlauben eine echtzeitfähige, datenbasierte und adaptive Produktionsablaufplanung (Anforderung A3). Die Begründung, inwiefern die agentenbasierte Produktionsablaufsteuerung diese drei Eigenschaften erfüllt, wurde einleitend in Abschnitt 5.2 skizziert. Des Weiteren berücksichtigen beide Prozessmodelle, dass der Mensch die letzte Entscheidungsinstanz darstellt und dass ein RL-trainierter Agent seine Entscheidungspolitik auf Basis menschlicher Expertise anpassen kann (Anforderung A4). Konkret erlauben beide Prozessmodelle, dass Agentenentscheidungen durch den Menschen evaluiert und verworfen und dass Alternativentscheidungen als Lernsignal an den Agenten zurückgespielt werden können. Ferner wurden zu Beginn von Abschnitt 5.2 zwei Modelle für die Beschreibung von Produktionsbereichen vorgestellt (Abbildung 5.3), durch deren Verknüpfung beliebige Probleme der Produktionsablaufplanung abgebildet werden können (Anforderung A5). Sowohl die Prozessmodelle als auch die Modelle zur Abbildung von Produktionsbereichen sind so gestaltet, dass agentenbasierte PPS-Entscheidungen in jedem Fall die Reihenfolge- und Losgrößenplanung integrieren. Das zweite Produktionsbereichsmodell erlaubt darüber hinaus eine integrierte Betrachtung der Ressourcenbelegungs-, Reihenfolge- und Losgrößenplanung (Anforderung A6).

Hinsichtlich der Erfüllung von Anforderung A2 wurde innerhalb von Abschnitt 5.3 ein siebenphasiges Vorgehensmodell zur Projektierung und Entwicklung von agentenbasierten Produktionsablaufsteuerungen entwickelt. Die Phasen des Vorgehensmodells umfassen (i) die Implementierung von Agentenumgebungen als DES-Modelle, (ii) die Definition von ML-Aufgaben und die resultierende Gestaltung von Agenten, (iii) die Integration und Inbetriebnahme von Agenten und Agentenumgebungen, (iv) die Auswahl und Implementierung von RL-Verfahren, (v) die Gestaltung von Belohnungsfunktionen sowie (vi) das Training von Agenten. Im Rahmen des Vorgehensmodells wird Anforderung A7 (Durchsuchung des Lösungsraums für alternative Lösungskandidaten) für gradientenabhängige RL-Verfahren dadurch erfüllt, dass der Programmablaufplan für die Aktionsermittlung durch Vorwärtspropagierung (Abbildung 5.18 in Abschnitt 5.3.3.1) verschiedene zufallsbasierte Explorationsstrategien berücksichtigt. Die Exploration des Lösungsraums wird des Weiteren dadurch begünstigt, dass die in Abschnitt 5.2 vorgestellten Prozessmodelle für die Ressourcenbelegungsplanung sowie für die Reihenfolgeplanung und Losbildung eine manuelle oder heuristische Bestimmung von alternativen Produktionsablaufentscheidungen erlauben, wenn ein Agent keine anforderungsgerechte Entscheidung getroffen hat. Hinsichtlich der gradientenfreien RL-Verfahren ist die Erfüllung von Anforderung A7 trivial, da diese grundsätzlich den Lösungsraum unabhängig von Gradienten und i. d. R. zufallsbasiert durchsuchen. Zu guter Letzt wird ebenfalls Anforderung A8 (Skalierbarkeit von RL-trainierten Agenten auf unterschiedlich großen Probleminstanzen) durch das Vorgehensmodell adressiert. So erlauben alle in Abschnitt 5.3.2 vorgestellten Varianten zur Formulierung von Teilproblemen der Produktionsablaufplanung als ML-Aufgaben, dass Agentenentscheidungen für jede Systemlast berechnet werden können, ungeachtet der Anzahl von Aufträgen, die während des Trainings analysiert wurden.

Zusammenfassend erfüllt die Methode somit alle der in Abschnitt 5.1 postulierten Anforderungen, um Entscheidungsunterstützungssysteme für die Produktionsablaufplanung zu entwickeln, welche ebenfalls die Entscheidungsfindung unter Berücksichtigung eines dynamischen stochastischen Auftragshorizonts sowie enger Zeitfenster begünstigen.

5.1 Elektronisches Zusatzmaterial

Zusatzmaterial 1 (PDF 1907 kb)