Supply Chain Scheduling mit Teams von Agenten

Diplomarbeit 

Supply Chain Scheduling mit Teams 

von Agenten 

Klaas Hambörger 

16. April 2002 – 14. Oktober 2002 

Erstgutachter: Prof. Dr. Hans-Jürgen Appelrath 

Zweitgutachter und Betreuer: Priv.-Doz. Dr. Jürgen Sauer

Inhaltsverzeichnis 

Inhaltsverzeichnis iii 

1 Einleitung 1 

1.1 Motivation und Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . 1 

1.2 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 

2 Grundlagen 5 

2.1 Ablaufplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 

2.1.1 Grundbegriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 

2.1.2 Modellierung eines Ablaufplanungsproblems . . . . . . . . . . . 9 

2.1.3 Multi Site Scheduling . . . . . . . . . . . . . . . . . . . . . . . 14 

2.1.4 Benutzerinteraktion . . . . . . . . . . . . . . . . . . . . . . . . . 17 

2.2 Supply Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 

2.2.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 

2.2.2 Supply Chain Management . . . . . . . . . . . . . . . . . . . . . 19 

2.3 Agentensysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

2.3.1 Agenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

2.3.2 Multiagenten-Systeme . . . . . . . . . . . . . . . . . . . . . . . 29 

2.3.3 Kooperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 

2.3.4 AMPA-Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 

3 Problemstellung 37 

3.1 Anforderungen an das Szenario . . . . . . . . . . . . . . . . . . . . . . . 37 

3.2 Szenario: Produktion und Auslieferung von Euro-Münzen . . . . . . . . 38 

3.2.1 Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 

3.2.2 Geldmengensteuerung . . . . . . . . . . . . . . . . . . . . . . . 38 

3.2.3 Euro als Produkt . . . . . . . . . . . . . . . . . . . . . . . . . . 40 

3.2.4 Rondenproduktion . . . . . . . . . . . . . . . . . . . . . . . . . 41 

3.2.5 Münzprägung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 

iii


3.2.6 Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 

3.2.7 Lagerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 

3.3 Anmerkungen und Anpassungen . . . . . . . . . . . . . . . . . . . . . . 45 

4 Entwurf 47 

4.1 Teams von Agenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 

4.2 Vorgehensmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 

4.2.1 Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 

4.2.2 Phasen des Vorgehensmodells . . . . . . . . . . . . . . . . . . . 50 

4.3 Umsetzung für das Beispiel Euro-Münzen . . . . . . . . . . . . . . . . . 58 

4.3.1 Analyse des Realwelt-Szenarios . . . . . . . . . . . . . . . . . . 58 

4.3.2 Mapping der relevanten Stellen auf Agenten . . . . . . . . . . . . 59 

4.3.3 Hinzufügen der Beziehungen und Teams . . . . . . . . . . . . . 63 

4.3.4 Präzisierung der Agenten . . . . . . . . . . . . . . . . . . . . . . 65 

4.3.5 Entwurf / Auswahl der Agentenplattform . . . . . . . . . . . . . 69 

4.3.6 Ausgestaltung der Anforderungen . . . . . . . . . . . . . . . . . 77 

4.3.7 Integration des Systems . . . . . . . . . . . . . . . . . . . . . . 95 

4.3.8 Test und Verifikation . . . . . . . . . . . . . . . . . . . . . . . . 96 

5 Implementierung 97 

5.1 Stamm- und Testdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 

5.1.1 Stammdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 

5.1.2 Testdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 

5.2 Klassenstruktur des Multiagenten-Systems . . . . . . . . . . . . . . . . . 106 

5.2.1 Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 

5.2.2 Änderungen an den Frozen Spots . . . . . . . . . . . . . . . . . 106 

5.2.3 Änderungen an den Hot Spots . . . . . . . . . . . . . . . . . . . 108 

5.3 Dateien und Startumgebung . . . . . . . . . . . . . . . . . . . . . . . . 109 

5.3.1 Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 

5.3.2 Sourcecode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 

5.3.3 Startumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 

5.4 Beispielablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 

6 Zusammenfassung und Ausblick 115 

6.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 

6.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 

Abbildungsverzeichnis 120 

iv


Tabellenverzeichnis 122 

Literaturverzeichnis 126 

Danksagung 127 

v


vi

1 Einleitung 

1.1 Motivation und Aufgabenstellung 

Betriebliche Produktionsprozesse sind häufig nicht mehr auf einen isolierten Standort be- 

schränkt. Vielmehr findet ein umfangreicher Austausch von Rohstoffen, Teil- und Fertig- 

produkten zwischen verschiedenen Herstellungs- und Lagerorten statt. Im Gegensatz zum 

Einzelbetrieb müssen Schedules für mehrere kooperierende Unternehmen erstellt und für 

globale Ziele optimiert werden. Supply Chain Szenarien erweitern das Problemspektrum 

der Ablaufplanung daher durch neue, spezifische Probleme: 

• Der Informationsfluss muss unternehmensübergreifend stattfinden und ist daher 

schwieriger und oft fehlerbehaftet, z.B. durch unterschiedliche (interne) Darstel- 

lung von Objekten. 

• Optimierung aus Sicht eines Einzelbetriebes kollidiert mit den für einen erfolgrei- 

chen Betrieb der Gesamtkette erforderlichen Parametern. 

• Reaktive Planung als Antwort auf aktuelle Veränderungen und Probleme findet 

nicht statt. 

• Unterschiedliche Prozessarten (Produktion, Transport, Lagerung) müssen in einen 

Gesamtablauf integriert werden. 

Ziel dieser Diplomarbeit ist es, einen Lösungsansatz für ein hinreichend komplexes Sup- 

ply Chain Szenario zu entwerfen, mit dem es möglich ist, die charakteristischen Aufgaben 

des Themenfeldes zu verdeutlichen. 

Zentrales Element sind dabei „Teams Of Agents“, verschiedene Gruppen von Agenten, 

die beteiligte Einheiten der Supply Chain modellieren und in Abhängigkeit von ihrer Posi- 

tion im System Teilpläne des Gesamtplans erstellen. Um den unterschiedlichen Prozessen 

gerecht werden zu können, müssen für einzelne Teams verschiedene Planungsverfahren 

bereitgestellt werden, welche z.B. auf Produktions-, Transport- oder Lagerraumplanung 

1

1 Einleitung 

optimiert sind. Ebenfalls von Bedeutung ist die Konzeption einer effizienten Kommuni- 

kationsstruktur, die im Gegensatz zu bestehenden Systemen in der Lage ist, auch auf dy- 

namische Veränderungen selbsttätig zu reagieren, ohne dabei einen „lähmenden“ Nach- 

richtenüberfluss zu erzeugen. 

Damit ein geeignetes Beispielszenario zur Verfügung steht, wird zunächst untersucht, 

welche Abläufe erforderlich sind, um Münzen der neuen Euro-Währung zu fertigen und 

sicher zu den Kunden (Landeszentralbanken, Geschäftsbanken) zu transportieren. 

In der Arbeitsgruppe Planungssysteme bereits vorliegende Ergebnisse – etwa ein Fra- 

mework für Planungsagenten – sollen mit in den Lösungsansatz integriert werden, um 

redundanten Entwicklungsaufwand zu vermeiden und die Eignung für das betrachtete 

Problemfeld zu überprüfen. 

Zur Veranschaulichung der erarbeiteten Lösungsstrategie erfolgt abschließend eine proto- 

typische Implementierung des Systems, wobei auf zukünftige Erweiterbarkeit, z.B. durch 

eine graphische Benutzungsschnittstelle, Wert zu legen ist. Als Zielsprache wird Java � 

verwendet, da Java � durch die Verfügbarkeit leistungsfähiger Entwicklungswerkzeuge, 

Plattformunabhängigkeit und das Vorhandensein benötigter Technologien (Netzwerkkom- 

munikation, Datenbankzugriff, Multithreading) gekennzeichnet ist. 

1.2 Aufbau der Arbeit 

Diese Diplomarbeit ist in sechs Kapitel untergliedert. 

Das Grundlagenkapitel vermittelt zunächst wichtige theoretische Kenntnisse für das Ver- 

ständnis der betrachteten Domäne. Dazu gehören Informationen über Ablaufplanung all- 

gemein, sowie über die Verfeinerungen des Multi Site Scheduling und der Supply Chains. 

Agenten als angestrebtes Realisierungsparadigma werden ebenfalls thematisiert. 

Es folgt ein konkretes Beispiel einer realistischen Supply Chain, konkret die Prägung der 

Euro-Münzen, welches die Grundlage für die Veranschaulichung der involvierten Kom- 

plexität und die Entwicklung der weiteren Vorgehensweise ist. 

Die Kapitel Entwurf und Implementierung beschäftigen sich zunächst mit der Erarbeitung 

eines Vorgehensmodells zur Umsetzung des aus der Realwelt stammenden Szenarios auf 

ein Multiagentensystem, welches im weiteren Verlauf dann ausgestaltet wird. Dabei wer- 

2

1.2 Aufbau der Arbeit 

den die Anforderungen an Algorithmen, Datenstrukturen und Kommunikationsstrukturen 

mit Inhalten gefüllt. Ausgewählte und wichtige Aspekte der prototypischen Implementie- 

rung werden erläutert. 

Eine Zusammenstellung und abschließende Einordnung der erzielten Ergebnisse erfolgen 

schließlich im Kapitel Zusammenfassung und Ausblick. 

3

1 Einleitung 

4

2 Grundlagen 

In diesem Abschnitt werden die Grundlagen eingeführt, die für das Verständnis der im 

späteren Verlauf der Arbeit entwickelten Konzepte benötigt werden. 

Dazu erfolgt eine Einführung in die Thematik der Ablaufplanung, wobei einige wichti- 

ge Vertiefungen, wie etwa verteilte Ablaufplanung (Multi Site Scheduling) und Supply 

Chain Management, berücksichtigt werden. Da eine Realisierung mittels Agenten vorge- 

sehen ist, wird auch dieses Konzept vorgestellt. 

2.1 Ablaufplanung 

Die Ablaufplanung umfasst einen Teilbereich der Aufgaben, die im Rahmen der Pro- 

duktionsplanung und -steuerung (PPS) zu bewältigen sind. PPS beschäftigt sich mit der 

Koordination aller dispositiven Vorgänge eines produzierenden Unternehmens, von der 

Auftragsannahme bis zur Produktlieferung. Dabei unterliegen die Planungsvorgänge ge- 

wissen Rahmenbedingungen (Constraints), die temporaler, kapazitiver oder technischer 

Art sein können. Außerdem gilt es, unterschiedliche betriebswirtschaftliche Zielvorstel- 

lungen zu erfüllen. 

Die hier gegebene Einführung und die vorgestellte Modellierung der Ablaufplanung ba- 

sieren auf Arbeiten von Sauer ([Sau93], [Sau01d]). 

2.1.1 Grundbegriffe 

Ablaufplanung bezeichnet den Vorgang, eine Menge von Aufträgen auf eine Menge zur 

Verfügung stehender Ressourcen (z.B. Maschinen, Personal, Rohmaterialien) kapazitäts- 

gerecht zuzuordnen, wobei vorgegebene Bedingungen (Constraints) zu erfüllen sind. Da- 

bei integriert die Ablaufplanung verschiedene Teilbereiche der PPS. Es handelt sich dabei 

um Aufgaben aus der Primärbedarfsplanung, Materialwirtschaft, Kapazitätsterminierung, 

5

2 Grundlagen 

Kapazitätsabgleich und Produktionssteuerung. Abbildung 2.1 zeigt das Zusammenwirken 

der verschiedenen Stufen der Planung im betriebswirtschaftlichen Kontext. Ergebnis der 

Ablaufplanung ist der Ablaufplan. 

Ebenen der Ablaufplanung Ergebnis 

Abbildung 2.1: Ebenen der Ablaufplanung 

Aufgabe der Primärbedarfsplanung ist es, in Abstimmung mit Auftragssteuerung und 

Kalkulation festzulegen, welche Produkte mittel- und langfristig hergestellt werden sol- 

len. Grundlage dafür bilden Heuristiken, die sich Erfahrungswerten, früheren Absatzzah- 

len und Marktprognosen bedienen. Bereits vorhandene Aufträge und aktuell vorhandene 

Lagerbestände fließen mit in die Betrachtung ein. Resultat dieser Planung ist ein Grob- 

plan, der erste, wenn auch noch relativ ungenaue Endtermine für die Produktion enthält. 

Im nächsten Planungsschritt, der Materialwirtschaft, wird dieser Grobplan konkretisiert. 

Dazu werden aus dem Primärbedarf entsprechende Sekundärbedarfe, Rohstoffe und Zwi- 

schenprodukte mit ihrer termingerechten Bereitstellung abgeleitet. Die dazu benötigten 

Informationen werden Stücklisten entnommen. Es entsteht ein verfeinerter Grobplan, der 

bereits konkrete End- und späteste Starttermine enthält, bei deren Berechnung aber noch 

keine kapazitiven Beschränkungen berücksichtigt werden. 

6


Die Lokale Planung umfasst die Bereiche Kapazitätsterminierung, Kapazitätsabgleich 

und die Produktionssteuerung. In diesem Schritt der Planung erfolgt die Erstellung von 

Feinplänen. Ein Feinplan berücksichtigt auch zur Verfügung stehende Ressourcen, de- 

ren Kapazitäten und bereits verplante Aktivitäten. Die Lokale Planung wird durch die 

Betriebsdatenerfassung (BDE) unterstützt, deren Informationen Kontrolle über den Pro- 

duktionsverlauf und gegebenenfalls Plankorrekturen ermöglichen. 

Nach Sauer ([Sau93]) sind für die Domäne der Ablaufplanung folgende Komponenten 

wesentlich: 

• Aufträge: Vorgaben für die Herstellung eines bestimmten Produkts. Sie enthalten 

Informationen über Menge, Start und Ende der Produktion. 

• Produkte: Ergebnisse des Produktionsprozesses, herzustellende Erzeugnisse. 

• Varianten: Als Varianten bezeichnet man alternative Herstellungsvorschriften für 

ein Produkt. 

• Operationen: Operationen sind die einzelnen Herstellungschritte im Produktions- 

prozess. Jede Variante eines Prozesses besteht aus einer Menge unterschiedlicher 

Operationen, die in einer bestimmten Reihenfolge ausgeführt werden müssen. 

• Maschinen: Ressourcen, auf denen die Operationen während der Produktion durch- 

geführt werden. Üblich ist eine redundante Auslegung, d.h., für eine Operation ste- 

hen alternativ verwendbare Maschinen zur Verfügung. 

• Zeiten: Zeiten sind neben Maschinen der eigentliche Planungsfaktor. Operationen 

werden auf Maschinen zu bestimmten Zeiten – typischerweise in Intervallen – ein- 

geplant. Für die rechnergestützte Planung finden meist keine Realzeitangaben, son- 

dern diskrete Zeitschritte Verwendung. 

Auch diese Arbeit stützt sich auf diskrete Zeitschritte. Ausgangspunkt der Darstel- 

lung ist ein frei zu wählendes, festes Datum in der Vergangenheit. Die Kardinalität 

der Schritte ist konstant, kann jedoch frei eingestellt werden, um ein geeignetes 

Mass für die Planung zu wählen. 

• Ereignisse: Ereignisse sind ein weiteres Merkmal der Ablaufplanung. Hierunter 

werden alle Einflüsse zusammengefasst, die eine Änderung des Plans erforderlich 

machen. Ereignisse können wiederum Folgeereignisse auslösen. 

Bereits angesprochen wurde ein weiterer elementarer Bestandteil der Ablaufplanung, die 

Rahmenbedingungen (Constraints). Diese werden unterschieden in Hard Constraints (Re- 

striktionen), welche unbedingt zu erfüllen sind, und Soft Constraints (Präferenzen), deren 

7

2 Grundlagen 

Erfüllung wünschenswert ist. Bei Interesse findet sich bei Henseler ([Hen98]) eine for- 

malere Beschreibung, die über das hier Eingeführte hinausgeht. 

Hard Constraints bestehen u.a. aus den Produktionsvorschriften. Diese beschreiben die 

zur Herstellung eines Produktes notwendigen Operationen und legen deren Ausführungs- 

reihenfolge, sowie die zu verwendenden Ressourcen fest. Für den Fall, dass in der Produk- 

tionsvorschrift unterschiedliche Varianten vorgesehen sind, muss eine davon ausgewählt 

werden. 

Soft Constraints finden für die Operationalisierung von betriebswirtschaftlichen Planungs- 

zielen Verwendung. Mögliche Ziele sind z.B. gute Maschinenauslastung, Minimierung 

von Lagerkosten, Einhaltung von vorgegebenen Fertigungsterminen oder Minimierung 

von Rüstkosten bei Universalmaschinen durch eine möglichst homogene Einplanung un- 

terschiedlicher Produkte. In der Realität ergibt sich das Problem, dass Ziele gegensätzlich 

sein können und damit nicht gleichzeitig erfüllbar sind. 

Werden im Verlauf der Planerstellung Constraints verletzt, wird dies als Konflikt bezeich- 

net. Bei Planerstellung oder -änderung, egal, ob durch das Ablaufplanungssystem oder 

einen Benutzereingriff, sind Konflikte zu vermeiden. Für Hard Contraints ist dies zwin- 

gend erforderlich. 

Ein Ablaufplan, der sämtliche Hard Constraints erfüllt, heisst gültig. Aufgrund des „Di- 

lemmas der Ablaufplanung“, das eine gleichzeitige Erfüllung sämtlicher Soft Constraints 

ausschließt, ist das Ziel der Ablaufplanung ein Plan, der sämtliche Hard Constraints erfüllt 

und ein Optimum bei der Erfüllung der Soft Constraints erreicht. Um dieses zu gewähr- 

leisten, wird eine Bewertungsfunktion eingesetzt, deren Ergebnis Aufschluss über den 

besten unter verschiedenen Plänen gibt. 

Im Allgemeinen ist die Suche nach der optimalen Lösung jedoch NP-vollständig und da- 

mit nur mit exponentiell steigendem Berechnungsaufwand möglich. Für die Praxis ist dies 

nicht geeignet, weshalb heuristische Näherungsverfahren eingesetzt werden, die ein zu- 

frieden stellendes Ergebnis liefern. 

Ablaufpläne können entweder komplett neu erstellt oder modifiziert werden, falls dies als 

Reaktion auf Veränderungen im betrieblichen Ablauf erforderlich sein sollte. Planende 

Instanzen können das System oder der Benutzer sein. Diese Möglichkeiten werden wie 

folgt klassifiziert: 

8


• Prädiktive Planung (predictive scheduling): Ein Plan für eine zukünftige Planungs- 

periode wird erstellt, der den Ablauf der Produktion im Voraus festlegt. Grundlage 

bilden Erfahrungs- und Schätzwerte (Soll-Daten). 

• Reaktive Planung (reactive scheduling): Ein bestehender Plan wird an veränderte 

Bedingungen der Umgebung angepasst. Gründe für die Anpassung sind typischer- 

weise Ereignisse, wie etwa der Ausfall einer Maschine oder die Änderung eines 

Auftrags. Um zur Lösung der resultierenden Konflikte nicht den kompletten Plan 

neu berechnen zu müssen, erfolgt eine Umplanung, die folgendes zu berücksichigen 

hat: 

– Die Antwortzeit des Systems sollte kurz sein und schnell einen konfliktfreien 

Plan liefern. 

– Die Gesamtqualität des bestehenden Plans bezügl. der operationalisierten Zie- 

le sollte erhalten bleiben. 

– Die Veränderungen sollten möglichst lokal durchgeführt werden, ohne kon- 

fliktfreie Abschnitte des Plans zu berühren. 

Bei bestehender Anbindung einer BDE, welche die in der Produktion aufgetretenen 

Ereignisse an das Planungssystem zurückmeldet, kann ein Regelkreis zwischen Pla- 

nung und Durchführung etabliert werden ([Hen98]). 

• Interaktive Planung (interactive scheduling): Der Benutzer des Ablaufplanungssys- 

tems führt eine manuelle Veränderung am Ablaufplan durch. Ermöglicht wird dies 

typischerweise durch eine graphische Benutzungsschnittstelle. Die Motivation für 

einen solchen Eingriff liegt entweder in einer reaktiven Veränderung oder dient der 

Realisierung einer Präferenz, die das automatische System so nicht leistet. Wichtig 

ist, dass manuell durchgeführte Veränderungen durch eine automatische Konsis- 

tenzprüfung auf eventuelle Konflikte getestet werden. 

2.1.2 Modellierung eines Ablaufplanungsproblems 

Für den weiteren Verlauf der Arbeit ist die Definition einiger Begriffe unumgänglich. 

Diese beruhen auf Sauer ([Sau01d]), allerdings wird hier weitestgehend auf strenge For- 

malismen verzichtet und das Wichtigste informell dargestellt. 

9

2 Grundlagen 

Definition 2.1: Ablaufplanungsproblem 

Ein Ablaufplanungsproblem wird durch ein 7-Tupel (R, P, A, HC, SC, E, Z) 

beschrieben. 

Dabei bezeichnet 

R eine Menge von Ressourcen, 

P eine Menge von Produkten, 

A eine Menge von Produktionsaufträgen, 

HC eine Menge von Hard Constraints, 

SC eine Menge von Soft Constraints, 

E eine Menge von Ereignissen und 

Z eine Bewertungsfunktion. 

10 

• R={r1, ..., rm}, R ist endlich und nicht leer. Jede Ressource ri steht zu jedem Zeit- 

punkt nur mit einer beschränkten Kapazität zur Verfügung. 

• P={p1, ..., pn}, P ist endlich und nicht leer. Jedes Produkt pj enthält eine Pro- 

duktionsvorschrift, die Informationen über Varianten mit ihren notwendigen Ferti- 

gungsoperationen, deren Vorrangrelation, sowie über verwendbare Ressourcen mit 

Produktions- und Rüstzeiten enthält. Zur Beschreibung von pj ergibt sich daher ein 

6-Tupel der Form (pname, v, o, r, d, rz). Dabei ist 

pname die Produktbezeichnung, 

v die Variantennummer, 

o die Operationsnummer, 

r eine alternativ einsetzbare Ressource, 

d die Dauer der Operation und 

rz die Rüstzeit der Ressource, auf der die Operation ausführbar ist. 

Zur Festlegung der Bearbeitungsreihenfolge der Operationen existiert eine Vorrang- 

relation. 

• A ist endlich und nicht leer. Jeder Produktionsauftrag a ∈ A kann durch ein 6-Tupel 

beschrieben werden: a = (aname, p, s, e, m, pri). Dabei ist 

aname der Auftragsname, 

p das zu fertigende Produkt, 

s der früheste mögliche Startzeitpunkt für die Produktion, 

e der späteste mögliche Endzeitpunkt für die Produktion, 

m die zu produzierende Menge und 

pri die Priorität des Auftrags.


• HC ist endlich und nicht leer. Zu den wichtigsten Hard Constraints zählen: 

hc1: Alle Aufträge müssen eingeplant werden. 

hc2: Zu jedem Auftrag ist genau eine Variante des Produkts einzuplanen. 

hc3: Alle Operationen der gewählten Variante müssen eingeplant werden. 

hc4: Die Vorrangrelation zwischen einzelnen Operationen einer gewählten Va- 

riante muss eingehalten werden. 

hc5: Jede Operation kann nur auf einer dafür bestimmten Ressource eingeplant 

werden. 

hc6: Auf jeder Ressource kann zu einem bestimmten Zeitpunkt nur eine Ope- 

ration ausgeführt werden. 

hc7: Für die Berechnung der Produktionsdauer ist die gewünschte Menge zu 

berücksichtigen. 

hc8: Das Ende einer Operation ergibt sich aus Startzeitpunkt plus Dauer der 

Operation. 

hc9: Die Startzeit einer Operation darf nicht vor der Startzeit des zugehörigen 

Auftrags liegen. 

hc10: Nicht verfügbare Zeitschritte bleiben bei der Planung unberücksichtigt. 

hc11: Einplanungen in der Vergangenheit dürfen nicht verändert werden. 

Gemäß Sauer ([Sau01d]) stellen die hier aufgezählten Hard Constraints nur eine 

Auswahl dar, im jeweiligen Anwendungsfall können weitere hinzukommen. 

• SC ist endlich und (im realen Anwendungsfall) nicht leer. Zu den wichtigsten Soft 

Constraints zählen: 

sc1: Vorgegebene Start- und Endtermine sind einzuhalten. 

sc2: Ressourcen sollten möglichst gut ausgelastet werden. 

sc3: Durchlaufzeiten sind zu minimieren, um Kapitalbindung durch hohe La- 

gerhaltung zu vermeiden. 

sc4: Rüstkosten sind zu minimieren. 

sc5: Engpassressourcen sind zu entlasten. 

sc6: Personal- und Lagerbeschränkungen sollten eingehalten werden. 

sc7: Die Planung ist hinsichtlich der Zielfunktion zu optimieren. 

11

2 Grundlagen 

12 

Auch für die vorgestellten Soft Constraints gilt, dass sich im konkreten Anwen- 

dungsfall sicherlich weitere finden lassen. 

• E ist endlich und nicht leer. Jedes Ereignis e ∈ E stellt eine Änderung in der Pla- 

nungsumgebung dar, die in der Regel zu einem Konflikt führt. Bei einem Ereignis e 

handelt es sich entweder um einen konkreten Vorfall aus der Realwelt oder um ein 

Folgeereignis, das aus einer Bearbeitung eines externen Ereignisses resultiert. 

Mögliche Ereignisse sind u.a.: 

e1: Neuer Auftrag, 

e2: Stornierung eines Auftrags, 

e3: Änderung des Starttermins eines Auftrags, 

e4: Änderung des Endtermins eines Auftrags, 

e5: Änderung der Auftragsmenge, 

e6: Änderung der Auftragspriorität, 

e7: Ändern des Produktes oder der Produktvariante für einen Auftrag, 

e8: Splitten eines Auftrags, 

e9: Störung/Reparatur einer Maschine, 

e10: Wartungsperiode einfügen, 

e11: Maschinenintensität ändern, 

e12: Schichtzahl ändern, 

e13: Ressource ändern, 

e14: Rückmeldung von Maschinendaten/Fertigungsdaten, 

e15: Auswärtige Fertigung. 

Für konkrete Anwendungen müssen u.U. weitere Ereignisse definiert werden. 

• Z bezeichnet die Menge der Bewertungsfunktionen (Zielfunktionen). Eine Ziel- 

funktion zf ∈ Z ordnet einem zulässigen Plan eine reelle Zahl als Bewertung für die 

Güte des Plans zu. Da nicht alle für einen Plan wünschenswerten Kriterien mittels 

einer Funktion modellierbar sind, beschränken sich Zielfunktionen häufig auf die 

Erfassung von Durchlauf- oder Fertigstellungszeiten. 

Jaudszim ([Jau98]) nennt Beispiele für Bewertungsfunktionen: 

zf1: Summe der Verspätungen (lateness), 

zf2: Mittlere Verspätung (mean lateness),

zf3: Summe der Terminüberschreitungen/Verzüge (tardiness), 

zf4: Anzahl der Aufträge mit Verzug (tardy orders), 

zf5: Mittlerer Verzug (mean tardiness), 


zf6: Summe der gewichteten Terminüberschreitungen (weighted tardiness), 

zf7: Summe der quadrierten Verzüge. 

Verspätungen pro Auftrag können negativ sein, der Verzug eines Auftrags ist mini- 

mal null. 

Als Ergebnis der Ablaufplanung wurde bereits der Ablaufplan genannt. 

Definition 2.2: Ablaufplan 

Ein Plan (Ablaufplan) ist eine Menge von Belegungen. PL sei die endliche, nicht leere 

Menge der Pläne. 

Zu der Belegung eines Plans gehören die verplante Operation eines Auftrags, die damit 

belegte Ressource, sowie Start- und Endzeitpunkt der Operation. 

Ein Plan kann unterschiedliche, für seine Qualität maßgebende Eigenschaften aufweisen, 

die im Folgenden definiert werden. 

Definition 2.3: Zulässiger oder gültiger Plan 

Ein Plan pl ∈ PL heißt genau dann zulässig oder gültig, wenn er alle Hard Constraints 

aus HC erfüllt. Die Menge der zulässigen Pläne heißt ZPL. 

Definition 2.4: Konsistenter, inkonsistenter Plan 

Ein Plan pl ∈ PL heißt genau dann konsistent, wenn er zulässig oder gültig ist und 

zusätzlich alle Soft Constraints aus SC erfüllt. 

Die Menge der konsistenten Pläne heißt KPL. 

Ein Plan pl ∈ PL heißt genau dann inkonsistent, wenn er nicht alle Constraints aus 

(HC ∪ SC) erfüllt. 

Definition 2.5: Optimaler Plan 

Ein konsistenter Plan pl ∈ KPL heißt optimal, wenn er optimal bezüglich der gewählten 

Bewertungsfunktion ist. 

13

2 Grundlagen 

2.1.3 Multi Site Scheduling 

2.1.3.1 Überblick 

In der Literatur und auch im vorangegangenen Abschnitt werden Probleme der Ablauf- 

planung häufig primär aus Sicht einer einzelnen, isolierten Produktionsstätte betrachtet. 

Dabei bleibt eine Vielzahl von Fragestellungen unberücksichtigt, die sich dann ergeben, 

wenn unterschiedliche Betriebe von einer zentralen Stelle aus koordiniert werden sollen 

und Abstimmungs- und Lieferprozesse zwischen verschiedenen Orten der Leistungser- 

stellung erforderlich werden. 

Ziel des Multi Site Scheduling ist es daher, die Betrachtung von Ablaufplanungsproble- 

men auf eine Darstellung von verteilten Produktionsstandorten zu erweitern. Die Notwen- 

digkeit dafür ergibt sich aus der zunehmenden Bedeutung von derartigen Szenarien, wie 

es die aktuelle Diskussion über Begriffe wie etwa „Dezentralisierung“, „Supply Chain 

Management“ oder „Virtuelle Unternehmen“ zeigt. 

Sauer ([Sau01d]) nennt dazu Eigenschaften, die eine verteilte Ablaufplanung charakteri- 

sieren: 

• Zwischen Produktionsprozessen an verschiedenen Standorten bestehen komplexe 

Beziehungen. 

• Auf höheren Ebenen der Planung werden generalisierte Daten verwendet. 

• Um globale Vorgaben und Ziele erreichen zu können, ist eine Koordination der 

dezentralen Planung erforderlich. 

• Die aktuelle Situation der Produktionsstätten ist höheren Planungsebenen nicht be- 

kannt. 

• Auf den verschiedenen Ebenen der Planung existieren unterschiedliche Planungs- 

ziele. 

Zur Integration der neuen Anforderungen wird das bestehende Modell der Ablaufplanung 

um eine globale Ebene erweitert (Abbildung 2.2). Auf dieser Ebene wird ein für alle un- 

tergeordneten lokalen Ablaufplanungssysteme geltender Grobplan erstellt, welcher auf 

kumulierten Daten basiert. Nach Sauer ([Sau01d] hat die globale Ebene folgende Aufga- 

ben: 

14 

• Erstellung von Vorgaben für nachgelagerte Planungseinheiten. Der hier erzeugte 

Plan genügt den globalen Zielen (Termine, Kosten), beschränkt sich aus Komplexi- 

tätsgründen aber auf grobe Zeitvorgaben für die lokalen Systeme.

Globale 

Ebene 

Lokale 

Ebene 

Globale Ablaufplanung 


Kunden, Auftraggeber 

Lokale Ablaufplanung Lokale Ablaufplanung Lokale Ablaufplanung 

BDE 

BDE 

Aufträge, Ereignisse 

Pläne, Ereignisse Pläne, Ereignisse 

Pläne, Ereignisse 

Pläne, Ereignisse Pläne, Ereignisse Pläne, Ereignisse 

Abbildung 2.2: Ebenen der verteilten Ablaufplanung 

BDE 

• Aufgabenverteilung: Eingehende Aufträge werden in Teilaufträge für Zwischenpro- 

dukte zerlegt und an lokale Betriebe verteilt. 

• Koordination der Planungsaktivitäten. Für den Fall, dass in den Produktionsbetrie- 

ben Ereignisse auftreten, die zu Konflikten im aktuellen Plan führen, obliegt es der 

globalen Ebene, eine reaktive Planung zu veranlassen, um die Plankonsistenz wie- 

derherzustellen. 

2.1.3.2 Modellierung 

Aufgrund der erweiterten Architektur bei der verteilten Ablaufplanung ergeben sich Än- 

derungen für die Modellierung. Das bekannte 7-Tupel (R, P, A, HC, SC, E, Z) bleibt 

zwar erhalten, die Bedeutung einzelner Elemente wird allerdings erweitert. 

15

2 Grundlagen 

Jaudszim ([Jau98]) und Sauer ([Sau02]) nennen wichtige Änderungen, die in Tabelle 2.1 

zusammengefasst sind. 

Element global lokal 

Ressource r ∈ R Maschinengruppe Maschine 

Produkt p ∈ P Endprodukt Zwischenprodukt 

Variante eines Produkts Variante eines Endprodukts Variante eines Zwischenprodukts 

Eine Variante bezeichnet eine Menge 

von Zwischenprodukten mit jeweils 

zugehörigen, alternativ verwendbaren 

Maschinengruppen. 

Auftrag a ∈ A externer Auftrag, bezieht sich auf 

ein Endprodukt 

Eine Variante bezeichnet eine Menge 

von Operationen mit jeweils zugehörigen, 

alternativ verwendbaren 

Maschinen. 

interner Auftrag, bezieht sich auf 

ein Zwischenprodukt 

Hard Constraint globales Hard Constraint lokales Hard Constraint 

hc ∈ HC 

Soft Constraint globales Soft Constraint lokales Soft Constraint 

sc ∈ SC 

Planziel zf ∈ Z globales Planziel, z.B.: Termineinhaltung 

bei externen Aufträgen 

lokales Planziel, z.B.: Optimierung 

der Maschinenauslastung 

Ereignis e ∈ E Ereignis auf globaler Ebene Ereignis auf lokaler Ebene 

Plan pl ∈ PL globaler Plan lokaler Plan 

Belegungen enthalten Zuordnungen 

von Zwischenprodukten auf Maschinengruppen. 

Belegungen enthalten Zuordnungen 

von Operationen auf Maschinen. 

Tabelle 2.1: Verteilte Ablaufplanung, Unterschiede der globalen 

und lokalen Ebene 

2.1.3.3 Durchführung der Planung 

Analog zur herkömmlichen Ablaufplanung sind auch bei der verteilten Ablaufplanung 

prädiktive und reaktive Ablaufplanung gleichermaßen von Bedeutung. Der wesentliche 

Unterschied liegt darin, dass aufgrund der hierarchischen Abhängigkeiten zwischen der 

Planung der globalen Ebene und den angeschlossenen Planungssystemen der lokalen Be- 

triebe ständig Ereignisse unterschiedlichster Art auftreten. 

Nicht nur, dass die prädiktive Planung auf lokaler Ebene den Vorgaben der globalen Ebe- 

ne nachkommen und diese in verfeinerte Pläne umsetzen muss, auch die reaktive Planung 

auf beiden Ebenen ist ständig gefordert. Auf lokaler Ebene können Betriebsstörungen 

Umplanungen zur Wiederherstellung der Plankonsistenz bedingen. Global werden mög- 

licherweise Aufträge hinzugefügt, geändert oder storniert und Auswirkungen lokaler Er- 

16


eignisse auf den globalen Plan umgesetzt, wodurch sich evtl. neue Vorgaben für andere 

Betriebe ergeben, da Aufträge für Zwischenprodukte von einem auf einen anderen Stand- 

ort verlagert werden. 

Die prädiktive Planung der globalen Ebene ist daher gut beraten, möglichst robuste Pläne 

zu erstellen, in denen Kapazitätsengpässe frühzeitig vermieden werden. Auf diese Weise 

besteht überhaupt erst die Möglichkeit, den Raum für Umplanungen aufgrund zahlreicher 

Ereignisse zu erhalten. 

2.1.4 Benutzerinteraktion 

In den vorangegangen Abschnitten wurden hauptsächlich die informationstechnischen 

Gesichtspunkte von Ablaufplanungsproblemen und der sie realisierenden Systeme the- 

matisiert. In der Praxis hat sich allerdings gezeigt, dass der „Faktor Mensch“ erheblichen 

Einfluss auf die erfolgreiche Etablierung entsprechender Systeme in Unternehmen hat. 

Hambörger und Würdemann ([HW01]) nennen einige Gesichtspunkte, die den Einsatz 

selbst eines leistungsfähigen und auf die spezifischen Gegebenheiten eines Betriebes zu- 

geschnittenen Ablaufplanungssystems gefährden können: 

• Vom System erstellte Pläne – inbesondere bei reaktiver Planung aufgrund von In- 

konsistenz infolge von Ereignissen – sind ohne weitere Unterstützung für den Be- 

nutzer nur schwer nachvollziehbar. Viele Systeme liefern keine Antwort auf die 

Fragen: 

– „Warum ist eine Änderung erfolgt?“ 

– „Was ist geändert worden?“ 

– „Wie ist die Änderung erfolgt?“ 

• Umfangreiche Ablaufpläne sind nur schwer in einer überschaubaren Form darstell- 

bar. Eine leicht verständliche Form der Darstellung ist jedoch inbesondere für in- 

teraktive Planung Voraussetzung, wobei z.B. eine explizite Abgrenzung zwischen 

manuell und vom System angeordneten Aufträgen sinnvoll ist. 

• Inhärent vorhandenes Spezialwissen des mit dem Ablaufplanungssystem arbeiten- 

den Experten (z.B. „Fertigung großer Scheiben nicht am Montag, da erhöhte Bruch- 

gefahr durch reduzierte Leistungsfähigkeit der Mitarbeiter nach einem Wochenen- 

de“) ist nicht nur schwer modellierbar, sondern auch schlecht visualisierbar. 

17

2 Grundlagen 

Konsequenz dieser Anforderungen ist, dass auf die Konzeption der Benutzungsschnitt- 

stelle eines Ablaufplanungssystems besonderes Augenmerk zu richten ist, was mit hohem 

Entwicklungsaufwand verbunden ist. Eine Vernachlässigung der genannten Anforderun- 

gen resultiert schnell in mangelnder Akzeptanz durch den Benutzer, wodurch die Investi- 

tionsbereitschaft der verantwortlichen Entscheidungsträger und damit die Marktchancen 

eines kommerziell zu vertreibenden Ablaufplanungssystems ebenfalls gefährdet werden. 

Ein bisher verfolgter Ansatz, Änderungen nachvollziehbar zu gestalten, besteht in vom 

System erzeugten Veränderungsprotokollen. Komfortablere Lösungen, auf Ebene einer 

graphischen Benutzungsschnittstelle realisiert, sind Gegenstand aktueller Forschung. 

2.2 Supply Chains 

2.2.1 Einführung 

Supply Chains gewinnen unter dem Eindruck von globalisierten Wirtschaftsprozessen 

mehr und mehr an Bedeutung. Für viele Unternehmen ist es nicht mehr profitabel, alle 

Produktionsschritte innerhalb der Wertschöpfungskette in eigenen Betrieben auszufüh- 

ren. Zur Kostenminimierung wird die Produktion von Zwischenprodukten daher an kos- 

tengünstigere Standorte verlagert oder an andere Unternehmen vergeben (Outsourcing). 

Abbildung 2.3 1 zeigt eine einfache Supply Chain am Beispiel der Textilindustrie. 

raw 

materials 

1 Entnommen aus [Sch01] 

18 

textile 

production 

material flows 

textile 

finishing 

information flows 

apparel 

industry 

Abbildung 2.3: Einfache Supply Chain in der Textilindustrie 

retailer

Es entsteht eine Logistikkette mit folgenden Stufen: 


• Raw Materials: Aufbereitung bzw. Bereitstellung von Rohmaterialen, wie etwa 

Baumwolle oder Schafwolle. 

• Textile Production: Produktion von Bekleidungsstoffen. 

• Textile Finishing: Veredelung der Stoffe, etwa durch Färben oder Imprägnieren. 

• Apparel Industry: Herstellung von Kleidungsstücken, z.B. Pullover, Hosen, Hem- 

den, etc. 

• Retailer: Wiederverkäufer der Endprodukte, u.a. Mode- und Warenhäuser. 

Der Materialfluss durchläuft die Supply Chain nur in einer Richtung, umfangreicher Aus- 

tausch von Informationen zur Koordination der Aktivitäten ist in beide Richtungen erfor- 

derlich. 

2.2.2 Supply Chain Management 

Das Supply Chain Management (SCM) beschäftigt sich mit der Etablierung und dem Be- 

trieb von Supply Chains. Schönsleben ([Sch98]) liefert zunächst folgende Begriffsbestim- 

mung: 

Definition 2.6: Supply Chain Management (SCM) 

Supply Chain Management ist die Koordination einer strategischen, längerfristigen 

Zusammenarbeit von Unternehmen im gesamten Logistiknetzwerk zur Entwicklung 

und Herstellung von Produkten. 

Das Supply Chain Management verfolgt dabei eine Reihe von Zielen, die allerdings nicht 

frei von Konflikten sind (nach Sauer, Schönsleben [Sch98]): 

• Schnellere Auftragsabwicklung, 

• geringere Lagerhaltungskosten, 

• geringere Transferkosten, 

• hohe Auslastung der Ressourcen, 

• höhere Produktqualität, 

• verbesserte Termintreue, 

19

2 Grundlagen 

• höhere Kundenzufriedenheit, 

• schnellere Reaktion auf Marktveränderungen, 

• verbesserter ROI 2 . 

Aus Sicht der Informatik gehört Supply Chain Management in die Domäne der verteilten 

Ablaufplanung. Die dort vorhandenen Beziehungen zwischen der leitenden globalen Ebe- 

ne und den untergeordneten lokalen Produktionsbetrieben werden allerdings um weitere 

Entitäten und komplexe Beziehungen ergänzt. 

Dazu gehört inbesondere die explizite Berücksichtung von Transporten zwischen Produk- 

tionsstandorten und der Lagerung von End- oder Zwischenprodukten. Für die Ablaufpla- 

nung bedeutet das viele neue Herausforderungen, da Transporte u.U. deutlich unzuverläs- 

siger zu kalkulieren sind als Maschinen. Ein Totalverlust oder eine kurzfristig auftretende 

Verzögerung sollten nicht dazu führen, dass der Gesamtablauf zusammenbricht. 

Sauer ([Sau02]) nennt noch weitere Aspekte, die den reibungslosen Ablauf einer Supply 

Chain gefährden: 

• Da unterschiedliche Unternehmen am Wertschöpfungsprozess beteiligt sind, exis- 

tiert kein Gesamtplan für die Produktion bestimmter Endprodukte, sondern eine 

Anzahl von zunächst unabhängigen Einzelplänen. 

• Die beteiligten Unternehmen verfolgen eigene, individuelle Ziele, die möglicher- 

weise kollidieren. 

• Es ist nicht nur ein effizienter Materialfluss zu etablieren, sondern insbesondere eine 

reibungslose Koordination der involvierten Abteilungen der beteiligten Unterneh- 

men zu erreichen. Dazu ist ein umfangreicher Informationsaustausch notwendig. 

• Die Zusammenarbeit im Rahmen der Supply Chain erfordert ein gewisses Maß an 

Vertrauen aller Beteiligten, da sonst Korrektheit, Vollständigkeit und Aktualität der 

ausgetauschten Informationen in Frage gestellt sind. 

Durch Beteiligung einzelner Unternehmen an verschiedenen Supply Chains und komple- 

xen Abhängigkeiten einzelner Zwischenprodukte ergibt sich gegenüber der „einfachen“ 

Baumstruktur des Multi Site Scheduling schnell eine netzwerkartige Struktur des Gesamt- 

systems. 

2 ROI = Return on Investment 

20


Bevor beschrieben wird, wie Planungsprozesse im Rahmen des SCM zu (re-)organisieren 

sind, sollen zunächst einige Anforderungen genannt werden, die es zu erfüllen gilt, um 

wirklich eine Win-Win-Situation für die beteiligten Unternehmen erreichen zu können 

(vergl. Zäpfel [Zae01]): 

• Eine Kooperation der Unternehmen ist Voraussetzung, ohne die Bereitschaft dazu 

ist eine Supply Chain nicht denkbar. 

• Hinsichtlich der Steuerungsaspekte muss Einigkeit über ein Kooperationsmodell 

erzielt werden (hierarchisch, heterarchisch). Dazu müssen evtl. Kompetenzen zwi- 

schen den Unternehmen neu aufgeteilt werden. 

• Eine unternehmensübergreifende Planung ist aufzubauen, um Aktivitäten koordi- 

nieren zu können. 

• Die Orientierung am Gesamtoptimum für alle Teilnehmer sollte die Grundlage der 

Planungsaktivitäten sein. 

• Die Informationstechnologie als Basis für Ablaufplanungssysteme ermöglicht über- 

haupt erst einen schnellen Daten- und Planaustausch über große Entfernungen. 

• Die Bereitschaft zum umfangreichen Austausch von Informationen muss gegeben 

sein, nur dann kann eine für den langfristigen Erfolg wichtige Vertrauensbasis ent- 

stehen. 

Die Darstellung der für das SCM wichtigen Planungsaufgaben erfolgt anhand der Supply 

Chain Planning Matrix, Abbildung 2.4 3 und orientiert sich an [MRW00]. 

Grundlage für die Gestaltung einer Supply Chain ist die Strategische Netzwerkplanung 

(SNP), deren Ergebnis die gewünschte Konfiguration eines Netzwerkes aus Zulieferern, 

Produktionsstandorten, Distributionszentren und Endkunden darstellt. SNP beinhaltet u.a. 

folgende Aufgaben: 

• Auf-/Abbau von Lager- und Produktionskapazitäten, 

• Planung und Auswahl neuer Standorte, 

• Auswahl der Beschaffungs- und Distributionskanäle, 

• Entscheidungen über die Fertigungstiefe, 

3 Angelehnt an [MRW00] 

21

2 Grundlagen 

langfristig 

kurzfristig 

Beschaffung Produktion Distribution Absatz 

Strategische Netzwerkplanung 

Hauptproduktionsprogrammplanung 

Materialbedarfsplanung 

Produktionsgrobplanung 

Feinplanung 

Distributionsplanung 

Transportplanung 

Abbildung 2.4: Die Supply Chain Planning Matrix 

Absatzplanung 

Available 

to 

Promise 

• strategische Auswahl und Bewertung der wichtigsten Kunden und Zulieferer, 

• Gestaltung von Partnerschaften. 

Aufgabe der Absatzplanung ist es, die zukünftigen Absatzmengen der Supply Chain zu 

prognostizieren. Dazu werden statistische Verfahren, Lebenszykluskonzepte und What- 

if-Analysen verwendet. Über Aggregation und Disaggregation werden daraus Zahlen für 

Endprodukte und Endproduktgruppen abgeleitet. Bestandteil der Absatzplanung ist das 

Available to Promise (ATP). Diese Funktion ermöglicht es, aus dem das SCM unterstüt- 

zenden bzw. realisierenden Softwaresystem, direkt eine Verfügbarkeitsanfrage zu stellen 

oder sogar Planaufträge zu erzeugen, indem aufgrund vorhandener Daten eine Abfrage 

entlang der vollständigen Supply Chain erfolgt. 

Ausgehend von den ermittelten Absatzzahlen und vorliegenden Kundenaufträgen werden 

mittels der Hauptproduktionsprogrammplanung Geld- und Informationsflüsse synchroni- 

22


siert. Dazu ist eine kostenoptimale Nutzung aller Ressourcen der an der Supply Chain 

beteiligten Unternehmen anzustreben. Aufgrund des hohen Datenvolumens ist eine Kon- 

zentration auf Endprodukte und kritische Komponenten, wie etwa Engpassressourcen, 

sinnvoll. 

Hauptaufgabe der Hauptproduktionsprogrammplanung ist der kostenoptimale Abgleich 

von Produktionsmengen und zur Verfügung stehender Kapazität über die gesamte Sup- 

ply Chain hinweg. Die Planung auf dieser Ebene wird in der Regel für ein Jahr vorge- 

nommen, wobei eine Orientierung an durchschnittlich zu erwartenden Durchlaufzeiten 

erfolgen muss. Ergebnisse sind u.a.: 

• Personaleinsatz, Überstunden, Zusatzschichten, 

• Produktionsmengen pro Zeitintervall für einzelne Werke, 

• Transportmengen und -kapazitäten in den Intervallen, 

• Maßnahmen zur Kapazitätsanpassung, 

• Lagerbestände am Intervallende, 

• Beschaffungsmengen an den Grenzen / Schnittstellen der Supply Chain. 

Diese Ergebnisse stellen Grundlage und Vorgaben für die weiteren, lokalen Planungsebe- 

nen dar. 

Bei der Produktionsgrob- und -feinplanung handelt es sich um die bereits eingeführten 

Planungsaufgaben auf lokaler und evtl. globaler Ebene. Aufgrund der Eigenverantwort- 

lichkeit im Rahmen der Vorgaben durch die Hauptproduktionsprogrammplanung behalten 

die einzelnen Unternehmen die Möglichkeit, Pläne zu erstellen, die auf die spezifischen 

Besonderheiten der eigenen Produktionsstandorte zugeschnitten und optimiert sind. 

Eine effiziente Distributions- und Transportplanung kann erheblich dazu beitragen, die 

Gesamtkosten eines Endproduktes zu senken. In einigen Branchen, z.B. der Konsumgü- 

terindustrie, können die Distributionskosten sogar den größten Kostenfaktor darstellen. 

Der Distributionsplanung obliegt es dabei, längerfristige Vorgaben für Transporte und Be- 

stände innerhalb des Distributionsnetzwerkes zu liefern. Zur Berechnung werden vorhan- 

dene Kundenbedarfe, gegebene Produktionsmengen und hoffentlich auch die tatsächlich 

23

2 Grundlagen 

verfügbaren Kapazitäten herangezogen. Der Planungshorizont ist dabei in der Regel kür- 

zer als bei der Hauptproduktionsprogrammplanung. 

Die Transportplanung erstellt aus den periodengenauen (meistens tagesgenauen) Distri- 

butionsplänen konkrete Tourenpläne und Ladepläne für einzelne Transportmittel. Diese 

Aufgaben sind vor allem dann relevant, wenn auf einem LKW viele Sendungen mit unter- 

schiedlichen Produkten transportiert werden. Das Ergebnis der Tourenplanung ist die Zu- 

ordnung von Kundenaufträgen zu den verfügbaren Fahrzeugen und der genaue zeitliche 

Ablauf der einzelnen Touren. Die Ladeplanung verfolgt das Ziel, unter Berücksichtigung 

der Be- und Entladevorgänge eine möglichst gute Nutzung des vorhandenen Stauraumes 

zu erreichen. 

Schließlich bleibt noch die Materialbedarfsplanung, die Bestellaufträge für Materialien 

(Rohstoffe, Vorprodukte, Betriebsmittel, ...) an Lieferanten generiert. Eine weitere ge- 

wünschte Funktionalität besteht in der Beauskunftung von Materialverfügbarkeiten, etwa 

zur Freigabe eines Auftrags. Dazu können evtl. auch Bestandsinformationen der Liefe- 

ranten mit herangezogen werden. 

Zu berücksichtigen sind dabei die je nach Branche unterschiedlich ausfallenden Größen 

für Bestellmengen und Häufigkeiten, wobei allerdings ein Zielkonflikt zwischen Lager- 

und Lieferkostenminimierung besteht. Um Unsicherheiten in der Materialzulieferung zu 

kompensieren, kann die Beachtung eines Sicherheitsbestands sinnvoll sein. 

Die für das SCM wichtigen Planungstätigkeiten lassen sich grob in folgende Kategorien 

einordnen: 

• Planung einer Supply Chain: Strategische Netzwerkplanung. 

• Konfiguration einer Supply Chain: Hauptproduktionsprogrammplanung, Absatz- 

planung. 

• Steuerung einer Supply Chain: Absatzplanung und Available to Promise, Produk- 

tionsgrob- und feinplanung, Distributions- und transportplanung, Materialbedarfs- 

planung. 

Nach Corsten und Gössinger ([CG01]) ist eine klare Trennung zwischen diesen Ebenen 

allerdings nicht möglich. 

24

2.3 Agentensysteme 

2.3.1 Agenten 

2.3.1.1 Einführung 


Computersysteme sind nicht ohne weiteres in der Lage, an sie gestellte Aufgaben zu er- 

füllen. Jeder auszuführende Arbeitsschritt muss explizit geplant und von Entwicklern in 

Form eines Programms realisiert werden. Bleibt eine Situation, die eine Reaktion des Sys- 

tems erfordert, unberücksichtigt, erfolgt im besten anzunehmenden Fall „nur“ ein Absturz 

der Software. Werden Computer in kritischen Bereichen eingesetzt, können Menschenle- 

ben unmittelbar bedroht sein. 

Immer mehr Anwendungen erfordern daher Systeme, die selbsttätig kritische Entschei- 

dungen im Rahmen der Entwicklungsziele treffen können. Solche Systeme werden als 

Agenten bezeichnet. Agenten, die in sich verändernden, unbestimmten und offenen Um- 

gebungen eingesetzt werden, und trotzdem auch im Fall unerwarteter Daten ein robustes 

Verhalten zeigen, werden als Intelligente Agenten bezeichnet. 

Ausgehend von diesen Anforderungen stellt Wooldridge ([Woo99]) eine Definition vor, 

wobei er allerdings betont, dass darüber kein allgemeiner Konsens in der Fachwelt be- 

steht. 

Definition 2.7: Agent 

Ein Agent ist ein Computersystem, das in eine Umgebung eingebettet und in der Lage 

ist, innerhalb dieser Umgebung Aktionen autonom auszuführen, um die gewünschten 

Zielvorgaben zu erreichen. 

Eine besondere Bedeutung hat dabei die Autonomie, d.h. die Fähigkeit des Agenten, oh- 

ne den Eingriff durch Benutzer oder andere Systeme Aktionen auszuführen. Neben dieser 

Eigenschaft zeichnet sich ein intelligenter Agent durch eine Befähigung zu flexiblem Han- 

deln aus, die wie folgt charakterisiert wird: 

• Reaktivität: Intelligente Agenten nehmen ihre Umgebung war und reagieren in an- 

gemessener Zeit auf sich ergebende Veränderungen, um den Zielvorgaben gerecht 

zu werden. 

• Proaktivität: Intelligente Agenten entwickeln ein zielgerichtetes Verhalten, indem 

sie selbst im Rahmen der Zielvorgaben die Initiative übernehmen. Ein für Ablauf- 

25

2 Grundlagen 

planungsaufgaben eingesetzter Agent könnte z.B. selbsttätig an der Planverbesse- 

rung arbeiten, wenn er gerade keine anderen Tätigkeiten auszuführen hat. 

• Soziale Fähigkeiten: Intelligente Agenten können mit anderen Agenten – mögli- 

cherweise auch mit Benutzern – interagieren, um die gewünschten Zielvorgaben zu 

erreichen. 

Für den praktischen Einsatz von Agenten sind weitere Anforderungen sinnvoll. Wool- 

dridge und Jennings ([WJ95]) nennen einige: 

• Vernunft: Die Agenten weisen ein rationales Verhalten auf und verstoßen nicht wis- 

sentlich gegen die gesetzten Ziele. 

• Ehrlichkeit: Ein ehrlicher Agent gibt grundsätzlich nur korrekte Informationen wei- 

ter und versucht nicht, sich durch Desinformation einen Vorteil zu verschaffen. 

• Mobilität: Die Fähigkeit eines Agenten, sich innerhalb eines elektronischen Netz- 

werks zu bewegen. 

• Wohlwollen: Wohlwollende Agenten haben widerspruchsfreie Ziele und versuchen, 

ihr Handeln auf die gegebenen Ziele abzustimmen. 

2.3.1.2 Architekturen 

Zur Realisierung eines Agenten ist die Erarbeitung von möglichen Architekturen notwen- 

dig. Dazu werden zunächst bisher abstrakt beschriebene Begriffe etwas formaler einge- 

führt (Wooldridge, [Woo99]). Hier sollen Agenten betrachtet werden, die über interne 

Zustände – ähnlich einem Automaten – verfügen. Der Agent interagiert mit seiner Um- 

gebung, indem er externe Beobachtungen (see) auf interne Wahrnehmungen (perception) 

abbildet, und darauf in Form einer geeigneten Handlung (action) reagiert. Ein proaktiver 

Agent kann darüber hinaus ohne äußeren Einfluss aktiv werden. 

Abbildung 2.5 4 zeigt den schematischen Aufbau, Definition 2.8 erläutert das Zusammen- 

wirken der Komponenten. 

Da ein Agent sowohl reaktive, als auch proaktive Verhaltensweisen zeigen soll, muss er 

über verschiedene Teilsysteme verfügen, um diesen unterschiedlichen Anforderungen ge- 

recht zu werden. Zur Modellierung bietet sich eine aus Schichten bestehende Architektur 

an. 

4 Angelehnt an [Woo99] 

26

Abbildung 2.5: Schematische Darstellung eines Agenten 

Definition 2.8: Arbeitsweise eines Agenten 

A: Menge der möglichen Aktionen des Agenten, 

I: Menge der internen Zustände eines Agenten, 

S: Menge der beobachtbaren Zustände der Umgebung, 

P: Menge der Wahrnehmungen des Agenten. 

see : S → P 

action : I → A 

next : I × (P ∪ ε) → I 


Wooldridge ([Woo99]) beschreibt für Schichtenarchitekturen zwei grundsätzliche Arten 

des Datenflusses (Abbildung 2.6 5 ): 

• Horizontale Anordnung: In einer horizontalen Architektur (Abbildung 2.6(a)) sind 

alle Schichten direkt mit Wahrnehmungs- und Aktionseinheit verbunden. Jede ein- 

zelne Schicht arbeitet quasi als eigenständiger Agent. 

• Vertikale Anordnung: In einer vertikalen Architektur (Abbildung 2.6(b) und 2.6(c)) 

sind Wahrnehmungs- und Aktionseinheit nur mit maximal einer Schicht verbunden. 

5 Entnommen aus [Bro01] 

27

2 Grundlagen 

a) 

Wahrnehmung 

Schicht n 

... 

Schicht 2 

Schicht 1 

Aktionen 

b) c) 

Aktionen 

Schicht n 

... 

Schicht 2 

Schicht 1 

Wahrnehmung 

Abbildung 2.6: Architekturen für Agenten 

Wahrnehmung 

Schicht n 

... 

Schicht 2 

Schicht 1 

Aktionen 

Der große Vorteil von Architekturen mit horizontaler Anordnung besteht in der konzep- 

tionellen Einfachheit: Für die Realisierung eines Agenten mit n unterschiedlichen Verhal- 

tensweisen reicht es, n verschiedene Schichten zu implementieren. Es besteht allerdings 

die Gefahr, dass eine Art „Wettstreit“ der einzelnen Schichten entsteht, da jede unab- 

hängig Aktionen auslösen kann. Das Gesamtverhalten des Agenten ist dann nicht mehr 

kohärent. 

Um ein kohärentes Verhalten des Agenten zu gewährleisten, wird üblichweise eine spezi- 

elle Schlichtungsfunktion integriert, die entscheidet, welche Schicht zum aktuellen Zeit- 

punkt die Kontrolle ausüben darf. Das Design einer solchen Funktion gestaltet sich jedoch 

sehr aufwändig, da sehr viele Interaktionen zwischen den Schichten denkbar sind. Außer- 

dem kann sich eine solche zentrale Überwachungsinstanz schnell als Flaschenhals für das 

Gesamtsystem erweisen. 

Vertikale Architekturen werden in One-Pass-Architekturen (Abbildung 2.6(b)) und Two- 

Pass-Architekturen (Abbildung 2.6(c)) unterschieden. 

Bei einer One-Pass-Architektur durchläuft der Kontrollfluss sequentiell jede Schicht, be- 

vor in der letzten Schicht eine Aktion ausgelöst wird. Eine Two-Pass-Architektur leitet die 

Informationen der Wahrnehmungseinheit zunächst durch alle Schichten bis nach oben, 

bevor dann der Kontrollfluss in umgekehrter Richtung abläuft. 

28


Die Two-Pass-Architektur weist Ähnlichkeiten mit der Arbeitsweise großer Organisatio- 

nen auf, auch dort werden wichtige Informationen bis in die höchste Instanz geleitet, 

bevor dort eine nach unten laufende Handlungskette angestoßen wird. 

2.3.2 Multiagenten-Systeme 

Henseler definiert ein Multiagenten-System als „[...] eine endliche Menge nebenläufiger 

Agenten, die über Nachrichten oder gemeinsame Variablen miteinander kommunizieren 

können.“ ([Hen98]). Das Multiagenten-System soll dabei von Synergieeffekten profitie- 

ren und über weitere Fähigkeiten, wie z.B. Selbstorganisation oder Reaktionsfähigkeit auf 

unvorhergesehene Ereignisse, verfügen. Nach außen stellt sich ein solches System als ein 

einziges System dar. 

Ein sinnvoller Einsatz von Multiagenten-Systemen ist nur dann möglich, wenn die ein- 

zelnen Agenten koordiniert und kooperierend zusammenarbeiten. Um diese Eigenschaf- 

ten zu gewährleisten, sind unterschiedliche Organisationsformen denkbar. Laut Henseler 

([Hen98]) sind folgende für Planungssysteme interessant: 

• Zentralistische und hierarchische Organisation: Die Agenten sind in einer vorge- 

gebenen Master-Slave-Beziehung angeordnet. Diese Struktur wird verwendet, um 

Ressourcen zu verwalten oder Arbeit auf verschiedene Agenten zu verteilen. Im 

Konfliktfall existiert eine klare Weisungsbefugnis. 

• Marktorientierte Organisationsformen: Alle Agenten sind gleichberechtigt an der 

Kommunikation beteiligt und kämpfen auf einem von Angebot und Nachfrage ge- 

regelten Markt um Ressourcen. 

• Kooperierende Experten: Jeder Agent ist auf ein bestimmtes Gebiet spezialisiert. 

Im Bedarfsfall kann er den Expertenrat eines anderen Agenten einholen. 

• Teams: Agenten schließen sich (dynamisch) zu Teams zusammen, um gemeinsam 

ein Problem zu lösen. 

Zwingende Voraussetzung für Kooperation ist die Möglichkeit der Kommunikation. Zwei 

unterschiedliche Verfahren werden bei Multiagenten-Systemen eingesetzt: 

• Shared Memory: Hier läuft die Kommunikation über gemeinsame, allen Agenten 

zugängliche Datenstrukturen ab. Nachrichten sind ungerichtet, d.h., sie haben kei- 

nen bestimmten Empfänger und können von allen eingesehen werden. 

29

2 Grundlagen 

• Message Passing: Zwischen den Agenten werden vordefinierte, gerichtete und pa- 

rametrisierte Nachrichten ausgetauscht. Empfänger der Nachricht sind ein einzel- 

ner Agent, eine Gruppe von Agenten (Multicast), oder alle Agenten des Systems 

(Broadcast). 

2.3.2.1 Hierarchisches Modellieren 

Zur Abbildung (Mapping) einer Unternehmensstruktur aus der Realwelt auf ein zu ent- 

werfendes Multiagenten-System wird häufig die Technik Hierarchisches Modellieren ver- 

wendet. Nach Henseler ([Hen98] werden die Agenten dabei in einer vorgegebenen und 

unveränderlichen Hierarchie angeordnet. 

Bei der Bildung der einzelnen Hierarchieebenen erfolgt eine Orientierung an Kompetenz- 

bereichen oder Abstraktionsebenen, für die Abbildung von Unternehmen sind die vorhan- 

denen Strukturen und Hierarchien eine geeignete Grundlage. 

Ein in der Hierarchie höher gestellter Agent besitzt einen größeren Überblick und arbei- 

tet auf kumulierten Daten, die er aus den von untergeordneten Agenten erhaltenen Daten 

ermittelt. In der Hierarchie tiefer stehende Agenten verfügen über höheres Detailwissen, 

welches sie zur Erstellung von Feinplänen für die Fertigung benötigen. Für die Weiterga- 

be an übergeordnete Agenten wird das Wissen in geeigneter Form aufbereitet. 

2.3.3 Kooperation 

Für die Kommunikation innerhalb eines Multiagenten-Systems wird einfaches Delegie- 

ren oder eine Variante des Contract Net Protokolls verwendet. Beide Verfahren werden in 

den folgenden Abschnitten beschrieben. 

2.3.3.1 Einfaches Delegieren 

Ein übergeordneter Agent erteilt einem Agent einen Auftrag (Abbildung 2.7(1)). Diesem 

ist es nicht erlaubt, Aufträge abzulehnen. Die Rückgabe eines Auftrags ist nur für den Fall 

einer Störung zulässig (Abbildung 2.7(2)). Eine Konfliktbereinigung innerhalb der Hier- 

archieebene, z.B. durch Kommunikation mit Agenten, die mögliche Alternativmaschinen 

repräsentieren, ist hier nicht vorgesehen. 

30

Agent 1 

2.3.3.2 Contract Net Protokoll 

1 

2 

Agent 2 

Abbildung 2.7: Einfaches Delegieren bei Agenten 


Huhns und Stephens ([HS99] nennen das Contract Net Protokoll als besonders geeignet 

für den Einsatz bei kooperierenden Agenten. Es handelt sich dabei um einen Versteige- 

rungsmechanismus, der eingesetzt wird, um Aufgaben auf mehrere Agenten zu verteilen. 

Bei einem Ablaufplanungssystem handelt es sich dabei um neu zu verplanende Aufträge. 

Bieter 1 

Versteigerer 

1 2 1 2 3 1 

Bieter 2 

Bieter 3 

Abbildung 2.8: Versteigerung im Contract Net 

Bei einer Versteigerung im Contract Net nimmt der Agent, der eine Aufgabe zu vergeben 

hat, die Rolle des Versteigerers (Manager) ein, die beteiligten untergeordneten Agenten 

übernehmen die Aufgabe der Bieter (Contractor). Die Rollenverteilung kann variieren, 

d.h. ein Agent, der bei einer Verhandlung noch Manager ist, nimmt an der nächsten mög- 

licherweise als Contractor teil. 

Abbildung 2.8 zeigt den Ablauf, der immer aus drei Phasen besteht: 

1. Ausschreibung: Der Versteigerer schreibt eine neue Aufgabe an alle Bieter aus. 

2. Bieten: Alle Agenten, die temporal und materiell in der Lage sind, die Aufgabe zu 

übernehmen, geben innerhalb einer festgelegten Zeitspanne ein Gebot ab. Außer- 

31

2 Grundlagen 

dem übermittelt jeder bietende Agent eine heuristische Wertung, die ausdrückt, wie 

gut er die Aufgabe ausführen kann. 

3. Zuschlag: Der Versteigerer erteilt dem nach seiner Meinung am geeignetsten er- 

scheinenden Agenten den Zuschlag. 

Zur Reduktion des Kommunikationsaufwands kann der Manager nur die Agenten in die 

Versteigerung einbeziehen, von denen ihm bekannt ist, dass sie die Aufgabe ausführen 

könnten. Ein evtl. unzureichender Informationsstand des Managers kann bei diesem Ver- 

fahren allerdings zur Nichtberücksichtigung geeigneter Agenten führen. 

Andere Verfahren ermöglichen es den Bietern, an mehreren Versteigerungen gleichzeitig 

teilzunehmen. Dabei kann sich die Situation des Agenten zwischen Abgabe eines Gebots 

und des möglicherweise erfolgenden Zuschlags ändern, was es sinnvoll erscheinen lässt, 

einen Mechanismus zur Rücknahme eines Gebots einzuführen. 

Davis und Smith ([DS83]) beschreiben drei Arten von Anomalien, die beim Contract Net 

entstehen können: 

32 

• Temporal Ignorance: Bei einer Versteigerung zum aktuellen Zeitpunkt bleiben zu- 

künftige Entwicklungen unberücksichtigt. Es könnte z.B. vorteilhaft für den Ver- 

steigerer sein, einem suboptimalen Angebot den Zuschlag zu erteilen, um dadurch 

Verbesserungen für spätere Verhandlungen zu erreichen. 

Ein Ansatz zur Lösung dieses Problems besteht darin, die Auftragszusage an einen 

Agenten differenzierter auszuführen, indem unterschiedliche Ebenen der Zusage 

eingeführt werden (Levels of Commitment) und es erlaubt wird, Gebote und Zusa- 

gen nachträglich zu verändern (Counterpropose) ([SL95]). 

• Spatial Ignorance: Agenten nehmen nur an Versteigerungen teil, von denen sie auch 

erfahren haben. Der Manager sollte daher alle für den Auftrag geeigneten Agenten 

kennen und diese in die Ausschreibung einbeziehen. 

Bei Systemen mit strikter Hierarchie sind dem versteigernden Agenten alle poten- 

ziellen Bieter bekannt. In anderen Fällen kann die Einrichtung eines Verzeichnisses 

helfen, in dem alle Agenten ihre Fähigkeiten eintragen. 

• Loading ignorance: Ein Agent hat keine Kenntnisse über die Belastung anderer 

Agenten, die evtl. Maschinen gleichen Typs repräsentieren. Dadurch können sich 

stark unterschiedliche Auslastungen ergeben.


Neimann et. al. ([NH+94]) schlagen als Lösung die Einführung von Texturen (textu- 

res) vor, die für jede Auftragssituation eine Bewertung der vorhandenen und nach- 

gefragten Ressourcen erlauben. 

2.3.3.3 Nachrichtenübermittlung 

Um miteinander Informationen und Wissen austauschen zu können, verwenden Agenten 

Agentenkommunikationssprachen (ACL: Agent Communication Languages), nach La- 

brou et al. ([LFP99]). 

Die Möglichkeiten dieser Sprachen sind sehr vielfältig. Im Gegensatz zu anderen Kom- 

munikationsverfahren der verteilten Programmierung (RMI 6 oder CORBA 7 ) werden an- 

stelle von einfachen Methodenaufrufen komplexe Nachrichten mit Vorschlägen, Regeln 

oder Aktionen versendet. Die Basis bilden übliche Netzwerkprotokolle, z.B. SMTP 8 , 

TCP/IP 9 oder HTTP 10 . 

KQML (Knowledge Query and Manipulation Language) ist eine der bekanntesten ACLs. 

Sie basiert auf der Sprechakt-Theorie und ist eine hohe, nachrichtenorientierte Kommu- 

nikationssprache, sowie ein Protokoll zum Austausch von Informationen. 

Für KQML sind diverse Transportmedien (TCP/IP, etc.) geeignet, außerdem ist der In- 

halt der Nachrichten variabel (z.B. strukturierter Text, SQL, Prolog). Die Struktur einer 

KQML-Nachricht ist gemäß Huhns und Stephens ([HS99]) wie folgt aufgebaut: 

Definition 2.9: Aufbau einer KQML-Nachricht 

(KQML-performative 

) 

6 RMI = Remote Method Invocation 

7 CORBA = Common Object Request Broker Architecture 

8 SMTP = Simple Message Transfer Protocol 

9 TCP/IP = Transfer Control Protocol / Internet Protocol 

10 HTTP = Hypertext Transfer Protocol 

:sender 

:receiver 

:identification 

:language 

:ontology 

:content 

33

2 Grundlagen 

KQML-Nachrichten lassen sich in drei Ebenen unterteilen: 

• Inhalt (content): Der eigentliche Inhalt der Nachricht. Dieser wird von KQML le- 

diglich transportiert und nicht beachtet. Er umfasst die Felder language, ontology 

und content. Verwendung finden dabei einfache Informationen, komplexe Sprachen 

oder strukturierter Text. 

• Kommunikation (communication): Informationen für den Nachrichtenversand, ins- 

besondere Sender (sender), Empfänger (receiver) und eine Identifikation (identifi- 

cation). 

• Nachrichtentyp (message): Der auf der Sprechakt-Theorie basierende Performativ 

(performative) der Nachricht typisiert diese in verschiedene Kategorien. Huhns und 

Stephens ([HS99]) nennen folgende: 

– Einfache Anfragen (basic query): evaluate, ask-one, ask-all, ..., 

– komplexe Anfragen (multiresponse query): stream-in, stream-all, ..., 

– Antworten (response): reply, sorry, ..., 

– Information (generic informational): tell, achieve, cancel, untell, unachieve, 

..., 

– Leistungsdefinition (capability-definition): advertise, subscribe, broadcast, ... 

Die Menge der Nachrichtentypen ist nicht minimal oder abgeschlossen. Eine reale 

Anwendung orientiert sich daher an ihrem konkreten Bedarf. 

Eine Kommunikation bei KQML funktioniert nach dem Client-Server-Prinzip und kann 

sowohl synchron, als auch asynchron ablaufen. 

Für die in dieser Arbeit betrachteten Multiagenten-Systeme und KQML-Nachrichten be- 

steht der Content immer aus strukturiertem Text. Pro Inhaltszeile ist genau eine Informa- 

tion enthalten, welche durch ein Schlüsselwort gekennzeichnet ist. Sämtliche Informatio- 

nen (Aufträge, Produktionsdaten, Ereignisse, etc.) werden auf diese Weise zwischen den 

Agenten ausgetauscht. 

Bröske ([Bro01]) beschreibt den beispielhaften Ablauf einer Versteigerung mit Contract 

Net und KQML. 

34

nces etc. are 

only agreed 

in different 

in electronic 

rovide other 

nment or its 

licting goals, 

als. They do 

goals. 

w to achieve 

ing problem 

al agent. 

ENTS 

e posts and 

of business 

tion and the 

ncerned with 

zational units 

sion of work 

f its entailed 

f hierarchies. 

to instruct, 

perordinated 

ncerning the 

typical basic 

rests on the 

sts in a tree 

the principle 

roblems and 

m, a post can 

rarchy. This, 

sk of unclear 

es the multitwo 

respects: 

cheduling is 

chical, intrak-like, 

inter- 


2.3.4 AMPA-Projekt 

Bei dem OFFIS-Projekt AMPA (Agent Based Multi Site Planning and Scheduling Application 

Framework) ([FST99]) wird die Absicht verfolgt, Probleme der verteilten Ablaufplanung 

mit einem Multiagenten-System zu lösen. 

Abbildung 2.911 Complex organization structures, however, are not exclusively 

organised hierarchically. This applies especially to legally and 

economically independent enterprises, for relationships between 

them do neither define powers of decision nor authorities to 

instruct; they only represent the aspect of coordination between 

their directional systems. In addition to the hierarchical, static 

dimension of the intra-company directional system in AMPA the 

network-like, dynamic dimension of the coordinating, logistical 

relationships on all levels of hierarchy is considered by a special 

type of relationship. Within AMPA organizations are accordingly 

represented by an overlay of hierarchical and network-like 

zeigt das Organisationsmodell des Systems. Zu erkennen ist, dass das 

structures, thus achieving both vertical and horizontal integration. 

Modell des Multi Site Scheduling zu einer netzwerkartigen, unterschiedliche Tiefen der 

The resulting organization model is illustrated by Figure 2, where 

Hierarchie zulassenden Struktur erweitert wurde. Die Beziehungsverhältnisse zwischen 

the enterprise under consideration is represented by dark nodes. 

den Agenten werden dabei in disziplinarische (Aufträge) und funktionale (Lieferung von 

These nodes also represent the problem area of multi-site 

Zwischenprodukten) unterschieden. 

scheduling. External organizational units are depicted using pale 

nodes. 

Company 

Site 

Shop 

Resource Group 

Resource 

Supply Chain 

Supplier Consumer 

Figure 2. Organization Model 

On a more formal level the approach pursued within AMPA 

can be regarded as a combination of the single-line system and 

the multiple-line system. This combination aims at clear 

responsibilities on the one hand and improved ways of 

coordination by shorter communication paths on the other. In 

order to achieve these goals while avoiding the disadvantages 

pointed out before two different types of relationships are 

considered. Both are directed and define a potential usage of a 

11 Entnommen aus [FST99] 

Abbildung 2.9: Architektur des AMPA-Systems 

Global Schedule, 

Long-Term 

Scheduling Hierarchy 

Local Schedule, 

Short-Term 

35

2 Grundlagen 

AMPA verfolgt das Ziel, universelle Agenten zu entwickeln, die durch ihre modulare Ar- 

chitektur für alle Arten der Planung (Produktion, Transporte, Lagerung) und auf allen 

Ebenen beteiligter Unternehmen eingesetzt werden können. 

Dieser Anspruch ist mit einem hoch komplexen Aufbau eines einzelnen Agenten verbun- 

den (Abbildung 2.10 12 ). Durch Austausch einzelner Module kann eine Adaption an die 

gewünschten Funktionalitäten erreicht werden. 

Aktivität 

Auftrag 

Produkt 

Ressource 

temporale 

Constraint 

Java Virtual Machine 

Aktueller Plan 

Persistenz 

ODBC- 

Treiber 

Gantt- 

Chart 

Präsentation 

DBMS 

(z.B. 

mSQL) 

Aktivitäten 

Produkte 

Ressourcen 

temporale 

Constraints 

Filesystem 

Aufträge 

Exemplarische 

Komponenten 

Auftragsfenster 

ERP- 

Wrapper 

R/3 

. . . 

. . . 

. . . 

. . . 

Fähigkeiten 

Java 

RMI 

Agentenfenster 

prädiktives Planen 

reaktives 

Planen 

Strategien 

Kommunikation 

Java 

IDL 

Exemplarische 

Komponenten 

. . . 

Prädikt. 

Algoritmus 

Reaktiver 

Algoritmus 

. . . 

Lagerhaltung 

. . . 

Auftragsvergabe 

IIOP / JRMP 

Abbildung 2.10: Architekturskizze eines AMPA-Agenten 

Exemplarische 

Ko mponenten 

weitere 

Planungsagenten 

Eine Anbindung an bestehende ERP-Systeme 13 erfolgt dabei durch unterschiedliche Wrap- 

per, deren Aufgabe darin besteht, vorhandene Planungsinformationen in geeigneter Form 

für den Planungsagenten aufzubereiten. 

12 Entnommen aus [FST99] 

13 ERP = Enterprise Ressource Planning 

36

3 Problemstellung 

Die Problemstellung dieser Diplomarbeit besteht darin, einen Lösungsansatz zu erarbei- 

ten, der Teams von Agenten verwendet, um Planungsaufgaben des Supply Chain Sche- 

duling zu lösen. Dieses Kapitel beschäftigt sich mit der Beschreibung eines geeigneten 

Szenarios, für das im weiteren Verlauf der Arbeit ein Ablaufplanungssystem entwickelt 

wird. Auch wenn das gewünschte Beispiel – der Logistik-Ablauf bei der Produktion von 

Euro-Münzen – bereits feststeht, ist es trotzdem erforderlich, zunächst ein paar Rahmen- 

bedingungen zu setzen. Anschließend wird in mehreren Schritten das Szenario vorgestellt 

und auf die Existenz der vorauszusetzenden Eigenschaften überprüft. 

3.1 Anforderungen an das Szenario 

Die Anforderungen, die an das betrachtete Szenario zu stellen sind, ergeben sich unmit- 

telbar aus den in den Grundlagen (Abschnitt 2.2) erarbeiteten Eigenschaften einer Supply 

Chain. 

Nachfolgend eine Liste der wichtigsten Gesichtspunkte: 

• Die Produktion findet an verschiedenen Standorten statt, 

• Produkte eines Standorts sind Vorprodukte für einen anderen, 

• es sind Transporte zwischen unterschiedlichen Betrieben erforderlich, 

• Produkte müssen gelagert werden, 

• eine unternehmensübergreifende Koordination ist notwendig, 

• nur eine koordinierte Ausführung aller Teilschritte ermöglicht das Erreichen von 

gemeinsamen Zielen (Kostensenkung, Auslastung, etc.). 

37


3.2 Szenario: Produktion und Auslieferung von 

Euro-Münzen 

3.2.1 Übersicht 

In dieser Diplomarbeit werden die komplexen Aufgaben, die für das Scheduling einer 

Supply Chain erforderlich sind, am Beispiel der Prägung von Euro-Münzen veranschau- 

licht. Dieses Beispiel wurde gewählt, um einerseits nicht erneut „klassische“ Szenarien 

aus der Produktion, wie etwa den Automobilbau, zu bemühen und andererseits evtl. neue 

Aspekte, die diesem Problemfeld vorbehalten sind, entdecken zu können. 

Um die Abläufe darzustellen, müssen die Organisationseinheiten identifiziert werden, die 

an der Supply Chain als Auftraggeber oder -nehmer beteiligt sind, und in Zusammenhang 

gebracht werden. Da es sich bei der Produktion von Münzen um eine Tätigkeit handelt, 

die staatlich reglementiert ist, werden die dafür verantwortlichen Institutionen und Geset- 

ze ebenfalls mit einbezogen. 

3.2.2 Geldmengensteuerung 

Für das Funktionieren einer modernen Volkswirtschaft ist eine stabile Währung unab- 

dingbar. In Deutschland galt die Deutsche Mark jahrelang als Grundlage für Wohlstand 

und wirtschaftliches Wachstum. Dieses hohe Ansehen verdankt die unlängst endgültig ab- 

gelöste Währung der konsequenten Geldmarktpolitik seitens der Deutschen Bundesbank, 

die im Zweifelsfall auch gegen politische Widerstände agiert hat. 

Zu den wichtigsten Instrumenten der kraft Gesetz unabhängig von der Regierung zu be- 

treibenden Geldmarktpolitik gehören u.a. die Steuerung der Leitzinssätze in Abhängigkeit 

von Konjunktur und Inflation, sowie die Regulierung der in Umlauf befindlichen Bargeld- 

menge. 

Mit Beginn der Europäischen Währungsunion und der schrittweisen Einführung des Euro 

musste eine neue, staatenübergreifende Regulierungsinstitution geschaffen werden, die in 

der Lage ist, europaweit die Währungsstabilität zu gewährleisten, um die neue Währung 

nicht durch einen Vertrauensverlust zu gefährden. Zu diesem Zweck wurde die Europäi- 

sche Zentralbank (EZB) mit Sitz in Frankfurt gegründet. 

Die EZB bildet zusammen mit den Nationalen Zentralbanken (NZB) der Länder, u.a. der 

Deutschen Bundesbank, das neue Europäische System der Zentralbanken (ESZB). Die 

38

3.2 Szenario: Produktion und Auslieferung von Euro-Münzen 

bisher national ausgeführten Regulierungen obliegen nun der EZB, die sich für die lokale 

Umsetzung der europaweit gültigen Entscheidungen der Zentralbanken der Mitgliedsstaa- 

ten bedient. 

Die Kompetenz über die in einzelnen Mitgliedsstaaten des Euro-Verbundes in Umlauf 

befindlichen Bargeldbestände befindet sich jetzt ebenfalls bei der EZB. Damit lokale Un- 

terschiede der Mitgliedsstaaten besser berücksichtigt werden, erfolgt dabei zunächst eine 

Evaluierung der voraussichtlich benötigten Bargeldmengen durch die nationalen Zentral- 

banken, die ihre Erkenntnisse gegenüber der EZB fundiert begründen und von dieser vor 

der Umsetzung genehmigen lassen müssen. 

NZB 

Landeszentralbank 

(LZB) 

Zweiganstalt 

Europäische 

Zentralbank (EZB) 

Deutsche 

Bundesbank 

(NZB) 


(LZB) 

NZB 


(LZB) 

Zweiganstalt Zweiganstalt 

Hauptstelle Haupstelle Zweigstelle Zweigstelle 

Zweigstelle Betriebsstelle 

Abbildung 3.1: Das Europäische System der Zentralbanken 

Bei der nationalen Umsetzung der Bargeldmengenregulierung wird die Deutsche Bun- 

desbank durch ihre Landesorgane, die Landeszentralbanken (LZBs) sowie deren Zweigan- 

stalten, unterstützt. Durch diese werden die operativen Aufgaben, etwa Ausgabe und Pfle- 

ge des Bargeldes, wahrgenommen. Geschäftsbanken versorgen sich hier mit „frischem“ 

Bargeld und liefern vereinnahmte Bestände an Scheinen und Münzen zur Echtheits- und 

Zustandsüberprüfung an diese zurück. Entsprechende Wertstellungen erfolgen auf den 

Konten, welche die Geschäftsbanken bei den LZBs unterhalten. 

39


3.2.3 Euro als Produkt 

Für die weitere Beschreibung des Szenarios interessiert hier der Anteil des Bargeldes, der 

aus Münzen besteht. In den Mitgliedsstaaten der Europäischen Währungsunion handelt es 

sich dabei um Euro- und Euro-Cent-Münzen. Die Nennwerte der Münzen (2, 1 Euro; 50, 

20, 10, 5, 2, 1 Euro-Cent) und die Abbildungen des jeweiligen Wertes auf der Vorderseite 

sind dabei in allen Ländern einheitlich. Die Gestaltung der Rückseiten ist den einzelnen 

Staaten selbst überlassen. 

In Deutschland finden sich insgesamt drei unterschiedliche Abbildungen auf der Rück- 

seite, von denen der Bundesadler und das Eichenlaub an vorherige Mark- und Pfennig- 

Münzen erinnern. Andere Staaten haben sich z.T. für eine komplett einheitliche oder auch 

komplett unterschiedliche Ausgestaltung entschieden. Bei einigen nationalen Ausgaben 

(Vatikan, Monaco, San Marino), ist aufgrund der geringen Stückzahlen bereits jetzt eine 

den Nennbetrag überschreitende Wertsteigerung eingetreten. Durch die Reglementierun- 

gen der Gestaltungsfreiheit werden sowohl ein hoher Wiedererkennungswert, als auch die 

gewünschte nationale Differenzierung erreicht. Eine vollständige Fotoserie aller Münz- 

rückseiten findet sich unter [BB02]. 

Um ein europaweit zuverlässiges Funktionieren von münzbetriebenen Automaten zu ge- 

währleisten, wurden die dafür erforderlichen Parameter, wie etwa Masse, Gewichte, Metallbeschaffenheit 

und Ausformung des Randes, einheitlich festgeschrieben. Tabelle 3.1 1 

bietet einen Überblick. 

Da Euro- und Cent-Münzen in dieser Diplomarbeit nicht als Zahlungsmittel, sondern als 

zu fertigendes Produkt betrachtet werden, liefert Tabelle 3.1 gleichzeitig eine Übersicht 

der einzelnen Produkte mit ihrer individuellen Beschaffenheit. Es ist offensichtlich, dass 

viele unterschiedliche Abläufe zu betrachten sind. 

So bestehen die Euro-Münzen aus einem Kern und einem äußeren Ring, die erst bei der 

Prägung miteinander verbunden und zunächst separat gefertigt werden. Auch bei den 

verwendeten Metallen und der Randgestaltung bestehen erhebliche Unterschiede. Die- 

se Unterschiede werden zunächst bei der Produktion von Ronden (siehe Abschnitt 3.2.4) 

gewürdigt. 

1 Quelle: Deutsche Bundesbank 

40


Nennwert 1 Cent 2 Cent 5 Cent 10 Cent 20 Cent 50 Cent 1 Euro 2 Euro 

Durchmesser in mm 16,25 18,75 21,25 19,75 22,25 24,25 23,25 25,75 

Dicke in mm 1,67 1,67 1,67 1,93 2,14 2,38 2,33 2,20 

Gewicht in g 2,30 3,06 3,92 4,10 5,74 7,80 7,50 8,50 

Form Rund Rund Rund Rund Rund Rund Rund Rund 

Farbe Rot Rot Rot Gelb Gelb Gelb weiß/gelb gelb/weiß 

Zusammensetzung (1a)* (1a)* (1a)* (1b)* (1b)* (1b)* (1c)* (1d)* 

Rändlung Glatt (2a)* Glatt (2b)* (2c)* (2b)* (2d)* (2e)* 

(1a) Stahl mit Kupferauflage 

(1b) Nordisches Gold (Kupfer-Aluminium-Zink-Zinn-Legierung) 

(1c) Ring: Nickel-Messing, Mittelteil: Kupfer-Nickel, Nickel, Kupfer-Nickel (dreischichtig) 

(1d) Ring: Kupfer-Nickel, Mittelteil: Nickel-Messing, Nickel, Nickel-Messing (dreischichtig) 

(2a) glatt mit umlaufender Rille 

(2b) grob geriffelt (Wellenstruktur) 

(2c) glatt mit Einbuchtungen 

(2d) gebrochen geriffelt 

(2e) Schriftprägung fein geriffelt 

3.2.4 Rondenproduktion 

Tabelle 3.1: Technische Merkmale der Euro-Münzen 

Als Ronden oder Rohlinge werden flache Metallscheiben bezeichnet, die als Vorprodukt 

in die Prägeanstalten geliefert oder dort selbst hergestellt werden. In dem hier betrachteten 

Szenario erfolgt eine separate Fertigung bei Rondenherstellern. Die Produktion der Ron- 

den erfordert beträchtlichen technischen Aufwand und besteht aus folgenden Schritten: 

1. Angeliefertes Münzmetall wird in Stangen gegossen. Die Beschaffung ist Aufgabe 

des Rondenherstellers. 

2. Die Stangen werden zu Metallbändern ausgewalzt. 

3. Aus den Metallbändern werden die Rohlinge ausgestanzt. 

4. Die Rohlinge werden randriert, d.h., der Rand wird verdickt, wobei gleichzeitig 

eine Glättung erreicht und die gewünschte Ausformung aufgebracht wird. 

5. Es erfolgt ein Glühen der Rohlinge, was die Prägung im späteren Produktionsablauf 

erleichtert. 

6. Die 1, 2 und 5 Euro-Cent-Stahlrohlinge werden durch Elektrolyse mit einer Kup- 

ferschicht überzogen. 

7. Die Rohlinge werden poliert, gewaschen und getrocknet. 

8. Abschließend werden die Rohlinge auf ihre Qualität überprüft und gezählt. 

9. Einwandfreie Stücke werden gelagert oder zu den Prägeanstalten geliefert. 

41


Für die insgesamt acht vorhandenen Euro- und Euro-Cent-Münzen sind individuelle Roh- 

linge zu erstellen. Bei Euro-Münzen müssen Kern und Ring separat gefertigt werden, 

außerdem ist zu berücksichtigen, dass der Kern aus insgesamt drei Schichten besteht, 

die miteinander verbunden werden müssen. Euro-Cent-Münzen sind etwas weniger an- 

spruchsvoll konzeptioniert, allerdings erfordert die Verkupferung der Stahl-Ronden einen 

getrennten Produktionsschritt. 

Den nach diesem Verfahren hergestellten Rohlingen fehlt nur noch die Prägung von Vor- 

der- und Rückseite. Die erforderlichen Maße und Gewichte werden aber bereits eingehal- 

ten. Für münzbetriebene Automaten sind Rohlinge daher uneingeschränkt verwendbar. 

Durch diese Eigenschaft und den aufwändigen Wertschöpfungsprozess stellt dieses Zwi- 

schenprodukt bereits einen erheblichen Wert dar. 

3.2.5 Münzprägung 

Die Prägeanstalten oder Münzen haben die Aufgabe, den Rohlingen ihr endgültiges „Ge- 

sicht“ zu verleihen. Obwohl für die Zukunft eine zumindest europäische Öffnung dieses 

Tätigkeitsbereiches geplant ist, arbeiten die fünf Deutschen Münzen in Berlin, München, 

Stuttgart, Karlsruhe und Hamburg bislang unter rein staatlicher (deutscher) Aufsicht. 

Neben den Euro- und Cent-Münzen werden auch andere Produkte, wie etwa Sonder- 

oder Gedenkmünzen, geprägt. Die Auftragsvergabe an die einzelnen Münzen erfolgt da- 

bei durch das Bundesministerium der Finanzen, was in §6 des Deutschen Münzgesetzes 

(MünzG) [Bun99] festgelegt wird. Das MünzG schreibt ebenfalls vor, dass das erforder- 

liche Münzmetall den Prägeanstalten durch das Bundesministerium der Finanzen bereit- 

zustellen ist. In dem hier beschriebenen Szenario erfolgt die Bereitstellung in Form der 

angelieferten Münzrohlinge, deren Produktion durch den Bund bzw. durch das Bundes- 

ministerium der Finanzen beauftragt wird. 

Bevor die Deutschen Münzen ihrem eigentlichen Produktionsauftrag nachkommen kön- 

nen, müssen zunächst die dafür erforderlichen Prägestempel erstellt werden. Die Herstel- 

lung umfasst wiederum aufwändige und teils von Hand auszuführende Arbeitsschritte, 

wie etwa Werkzeugbau und Gravurarbeiten. Für dieses Szenario wird das Vorhandensein 

der erforderlichen Prägemaschinen und -stempel vorausgesetzt, eine weitere Betrachtung 

der Vorstufen soll hier nicht erfolgen. Nähere Informationen zu diesem Themengebiet 

sind unter [Swi02] zu finden. 

42


Die Verarbeitung der angelieferten Rohlinge in der Münze umfasst folgende Schritte: 

1. Prägung der Rohlinge mit passendem Stempel-Paar für beide Seiten, 

2. manuelle Qualitätskontrolle und ggf. Aussonderung schlecht ausgeprägter Stücke, 

3. Verpackung der Münzen; zunächst in Rollen, anschließend in Säcke oder Kisten, 

4. Lagerung oder Transport zu den Landeszentralbanken. 

3.2.6 Transport 

Aus den bisher beschriebenen Schritten zur Fertigung von Euro-Münzen ergibt sich be- 

reits, dass unterschiedliche Stationen an möglicherweise verschiedenen Standorten durch- 

laufen werden müssen. Die Integration aller Schritte zu einem Gesamtablauf erfordert 

Transporte von Rohstoffen sowie Zwischen- und Endprodukten, und es ergibt sich die 

gewünschte Supply Chain. 

Metall 1 

Metall 2 

Rohmetall 

Ronden 1 

Ronden 2 

Rondenproduktion 

Normaler Transport 

Sicherheitstransport 

BUND 

HH 

M 

B 

Münzprägung 

S 

KA 

Gemeinsamer Pool von 

Unternehmen 

Abbildung 3.2: Transporte bei der Produktion der Euro-Münzen 

LZB 1 

LZB 2 

Lagerung 

Abbildung 3.2 zeigt das Zusammenwirken der beteiligten Stufen. Transportiert werden 

zunächst die von den Ronden-Herstellern benötigten Metalle, im späteren Verlauf dann 

die Münzrohlinge und schließlich die fertigen Münzen. Rohmetalllieferanten, Rondenher- 

steller und Landeszentralbanken sind exemplarisch dargestellt, die fünf Deutschen Mün- 

zen in Stuttgart (S), Hamburg (HH), Berlin (B), Karlsruhe (KA) und München (M) sind 

komplett abgebildet. 

43


Aus der Abbildung werden einige zu beachtende Besonderheiten ersichtlich. Während 

die Transporte des Rohmetalls ohne besondere Vorkehrungen erfolgen können und von 

den Metalllieferanten initiiert werden, besteht bei Transporten von Münzrohlingen und 

fertigen Münzen erhöhter Sicherheitsbedarf. Vom Bund werden daher geeignete Sicher- 

heitstransportunternehmen beauftragt. Die Instanz „Bund“ ist hier stellvertretend für die 

Deutsche Bundesbank bzw. das Bundesministerium der Finanzen zu verstehen. Beiden 

obliegen unterschiedliche Aufgaben im Rahmen der Münzfertigung, ein sinnvoller Ab- 

lauf kann aber nur durch Koordination beider Stellen erreicht werden. 

Ermittelt aus den Aufträgen die 

benötigten Transporte in Rohform: 

n Transportaufträge (Produkt, Anzahl, 

früheste Abfahrt, späteste Ankunft, 

Quelle, Ziel) 

Umgruppierung in konkrete Mengen 

an Gewicht und Ausmaß 

Transportunternehmen 

Abbildung 3.3: Beauftragung von Transporten durch den Bund 

Der Bund selbst beschränkt sich bei der Planung der Transporte auf eine Sammlung der 

sich aus den Aufträgen ergebenden Notwendigkeiten. Abbildung 3.3 zeigt, dass erst die 

Transportunternehmen selbst, bzw. deren Kopf in Form eines fokalen Unternehmens, eine 

Optimierung und konkrete Verplanung auf einzelne Transporteure vornehmen. 

3.2.7 Lagerung 

Die vorliegende Supply Chain erfordert an unterschiedlichen Stellen eine Berücksichti- 

gung von Lagerkapazitäten. In Abbildung 3.2 werden nur die „Endlagerung“ der Münzen 

44

3.3 Anmerkungen und Anpassungen 

bei den Landeszentralbanken und die Rohmetalllieferanten als ebenfalls lagernde Instan- 

zen dargestellt. 

Weitere Lagerkapazitäten sind bei Rondenherstellern und den Münzen zu finden. Durch 

Ein- und Ausgangslager soll hier eine Entkopplung von Transporten und damit eine rei- 

bungslose Produktion erreicht werden. Im weiteren Verlauf dieser Arbeit wird allerdings 

zunächst eine reine Just-In-Time-Produktion betrachtet, weshalb Ein- und Ausgangslager 

keine weitere Berücksichtigung finden. 

3.3 Anmerkungen und Anpassungen 

Das in diesem Kapitel beschriebene Szenario versucht, ein Modell für die bei der Produk- 

tion von Euro-Münzen involvierten Wirtschaftsprozesse zu bilden. Dazu wurden authen- 

tische Quellen, wie etwa die Deutsche Bundesbank, gesetzliche Vorschriften, Medienbe- 

richte und Informationen von Produzenten im In- und Ausland herangezogen. 

Für einige Aspekte war eine detaillierte Informationsbeschaffung mit vertretbarem Auf- 

wand allerdings nicht möglich, weshalb einige Erkenntnisse aus vorliegenden Fakten de- 

duziert werden mussten. Dies gilt insbesondere für den Bereich Transport, über den auf- 

grund der Sicherheitsrelevanz dieses Themas wenig Konkretes zu erfahren war. 

45


46

4 Entwurf 

Nachdem im vorigen Kapitel das ausgewählte Beispiel-Szenario beschrieben wurde, folgt 

jetzt die Aufgabe, ein System zur Lösung der dort beteiligten Ablaufplanungsprobleme 

zu entwickeln. Dazu wird zunächst ein Vorgehensmodell erarbeitet, das eine schrittweise 

Abbildung des Szenarios auf ein Multiagenten-System ermöglicht. 

Anhand des Modells erfolgt dann ein Mapping der vorhandenen Planungseinheiten auf 

Agenten. Im Weiteren können die spezifischen Eigenschaften, die diese Agenten aufwei- 

sen müssen, identifiziert werden. Zu klären sind insbesondere die Anforderungen an die 

jeweils benötigten Planungsalgorithmen und das Kommunikationsverhalten. Beide wei- 

sen aufgrund der unterschiedlichen Positionierung im Gesamtsystem beträchtliche Unter- 

schiede auf. 

4.1 Teams von Agenten 

Diese Diplomarbeit verfolgt das Ziel, Probleme des Supply Chain Scheduling mit einem 

Multiagenten-System zu realisieren, dessen Agenten in Teams organisiert sind. 

Ein Aspekt der auf Sauer ([Sau02]) basierenden Idee ist es, ein Kooperationsmodell 

für die Agenten zu finden, das geeignet ist, den bei früheren Realisierungen enstande- 

nen Kommunikations-Overhead zu minimieren. Eine Organisation der Agenten in Teams 

scheint dazu verwendbar, da sich so Kontrollflussschleifen (Control Loops) auf verschie- 

denen Ebenen der Supply Chain herausbilden können. 

In jeder dieser Schleifen ist nur eine begrenzte Ablaufplanungsaufgabe zu lösen, wozu nur 

begrenztes Planungswissen erforderlich ist. Außerdem führt der eingeschränkte Betrach- 

tungshorizont dazu, dass weniger Ereignisse auftreten, die eine Kommunikation zwischen 

den Agenten erfordern. 

Ein Control Loop könnte z.B. die obere Ebene der Supply Chain abdecken, in der sich 

der fokale Kopf und die obersten Repräsentanten der beteiligten Unternehmen befinden. 

47

4 Entwurf 

Weitere Schleifen umfassen Objekte der mittleren Ebene. Auf unterer Ebene sind z.B. nur 

noch Maschinenagenten und der für deren direkte Koordination zuständige Agent enthal- 

ten. 

Es gibt allerdings noch weitere Gesichtspunkte, die für den Einsatz von Teams von Agen- 

ten bei Ablaufplanungsproblemen sprechen: 

48 

• Parallelen zur Realwelt: Bei auf Multiagenten-Systemen abzubildenden Betriebss- 

trukturen ist häufig eine hierarchische, in Gruppen und Abteilungen gegliederte Or- 

ganisation zu finden. Für unternehmensübergreifende Kooperationen ist ebenfalls 

eine Koordination zwischen den Disponenten der Beteiligten erforderlich, auch die- 

se Zusammenarbeit kann als Team verstanden werden. 

• Strukturierung für die Konfiguration: Um komplexe Projekte auf Multiagenten- 

Basis in späteren Phasen schnell an unterschiedliche Umgebungen anpassen und da- 

mit kommerziell einfacher nutzen zu können, sind ein komponentenbasierter Auf- 

bau und Unterstützung durch ein grafikbasiertes Konfigurationssystem wünschens- 

wert. Teams bieten sich hier als Strukturierungsmöglichkeit an, um dem Benutzer 

die Umsetzung unterschiedlicher Ebenen auf das System zu erleichtern. 

• Abgrenzung von Bereichen: Agenten auf einer mittleren Stufe sind typischerwei- 

se in mehrere Teams eingebunden. Einerseits sind sie „Befehlsempfänger“ eines 

übergeordneten Agenten, andererseits leiten sie selbst ein untergeordnetes Team. 

Diesen Agenten kommt daher die Aufgabe zu, zwischen beiden Ebenen zu ver- 

mitteln. Dazu verfügen sie über das erforderliche Planungswissen und setzen von 

oben erhaltene Grobpläne in Feinpläne um, deren Aufträge sie unter den in der Hie- 

rarchie tiefer stehenden Agenten verteilen. Hier liegen Risiken und Chancen dicht 

beieinander. Die konkrete Realisierung und Abgrenzung der Bereiche entscheiden 

unmittelbar über die erreichbare Reduktion der Komplexität. 

• Unterschiedliche Kommunikationsmodelle: Durch die bereits hervorgehobene Un- 

terteilung, die in einem Multiagenten-System durch Teambildung erreicht werden 

kann, ergeben sich neue Möglichkeiten für die Kooperation der Agenten. Heterar- 

chische Verhandlungen z.B., bei denen ein Team selbsttätig nach Vorgaben eines in 

der Hierarchie höher stehenden Agenten die Aufgabenverteilung übernimmt, ohne 

diesen dabei in die Verhandlung einbeziehen zu müssen, sind ohne Aufteilung in 

Bereiche nicht vorstellbar.

4.2 Vorgehensmodell 



Das hier vorgestellte Vorgehensmodell zur Abbildung eines Supply Chain Szenarios der 

Realwelt auf ein Multiagenten-System besteht aus ingesamt acht Phasen (Abbildung 4.1). 

Abbildung 4.1: Phasen des Vorgehensmodells 

Die Phase Analyse des Realwelt-Szenarios beschäftigt sich mit der gründlichen Betrach- 

tung der Wirtschaftsprozesse, für die eine Planungsunterstützung realisiert werden soll. 

49

4 Entwurf 

Den dabei identifizierten Stellen der Realwelt werden in den beiden folgenden Phasen 

Agenten zugeordnet, die in Teams strukturiert und mit Beziehungen versehen werden. 

Anschließend ist eine Präzisierung der Agenten möglich. Diese liefert Erkenntnisse über 

die für einzelne Agenten zu realisierenden Eigenschaften. Betrachtet werden u.a. Pla- 

nungsaufgaben, Verantwortungsbereich und Kooperationsverhalten. 

Der Entwurf bzw. die Auswahl der Agentenplattform, die für eine Realisierung geeig- 

net erscheint, ist Voraussetzung, um in der nächsten Phase die ermittelten Anforderungen 

ausgestalten und z.B. Datenschema, Algorithmen und Kommunikationsverfahren entwi- 

ckeln zu können. Abschließend erfolgt die eigentliche Implementierung des Systems und 

die Durchführung von Tests. 

Einige Tätigkeiten weisen Ähnlichkeiten mit einem von Appelrath et al. im Rahmen des 

Projekts AMPA beschriebenen Ansatzes ([AFST00]) auf. An anderen Stellen weicht das 

hier eingeführte Modell jedoch davon ab oder liefert eine detailliertere Darstellung. 

Die für die einzelnen Phasen des Abbildungsprozesses relevanten Handlungen werden im 

Folgenden näher beschrieben. 

4.2.2 Phasen des Vorgehensmodells 

4.2.2.1 Analyse des Realwelt-Szenarios 

Zu Beginn ist eine gründliche Analyse des Szenarios erforderlich, für das ein Ablauf- 

planungssystem realisiert werden soll. Hierbei werden die Informationen gesammelt, die 

später für die Ausgestaltung des Softwaresystems von Bedeutung sind. 

Ergebnis der Untersuchung sollten detaillierte Erkenntnisse über folgende Aspekte sein: 

50 

• Produkte und Ziele: Damit eine geeignete Supply Chain etabliert werden kann, ist 

zu betrachten, was Ergebnis dieser Supply Chain sein soll. Dazu gehören die zu 

fertigenden Produkte bzw. anzubietenden Dienstleistungen und angstrebte Optimie- 

rungen in Form von Zielen. Näheres findet sich in Abschnitt 2.2.2. 

• Prozesse: Für den Ablauf der Supply Chain sind unterschiedliche Prozesse rele- 

vant, u.a. Produktions-, Liefer- und Bereitstellungsprozesse, für deren Koordination 

Planungs- und Steuerungsprozesse benötigt werden. 

• Beteiligte Unternehmen und Stellen: Realisiert wird die Supply Chain durch eine 

Kooperation von Unternehmen, die einzelne Prozesse untereinander aufteilen. Es ist


zu klären, welches Unternehmen, bzw. welche Stelle eines Unternehmens einzelne 

Teilaufgaben zu übernehmen hat und wo Redundanzen durch Zusammenführen von 

Prozessen abgebaut werden können, z.B. durch eine gemeinsame Instanz für die 

Beschaffung von Rohmaterial. 

• Beziehungen: Durch die Zuordnung bestimmter Prozesse zu Unternehmen erge- 

ben sich disziplinarische Unterstellungsverhältnisse (z.B. Handlungsanweisungen 

an untergeordnete Unternehmen oder Abteilungen) und funktionale Beziehungen 

(z.B. Lieferung von Teilprodukten). 

Zur Verbesserung der Koordinationsfähigkeit ist die Vermeidung von Multi-Hie- 

rarchien sinnvoll, d.h., jede Stelle der Supply Chain sollte nur einer anderen In- 

stanz disziplinarisch unterstellt sein. Aus dieser Anforderung ergibt sich, dass eine 

baumartige Anordnung der Unterstellungsverhältnisse entsteht. 

• Technische Voraussetzungen: Um für eine Supply Chain geeignete Unterstützung 

durch ein Softwaresystem leisten zu können, ist zu beachten, welche Teile der 

IT-Infrastruktur möglicherweise schon vorhanden sind, etwa in Form bestehender 

ERP-Systeme. Denkbar ist auch, dass in einzelnen beteiligten Unternehmen erst die 

benötigten Strukturen geschaffen werden müssen. 

Für die Aufbereitung der gesammelten Fakten sind Grafiken, Tabellen und beschreiben- 

de Texte sinnvoll. Etablierte Referenzmodelle, wie das SCOR-Modell des Supply Chain 

Council (beschrieben in [SK01]), helfen bei der Strukturierung und der Vereinheitlichung 

der Terminologie. 

4.2.2.2 Mapping der relevanten Stellen auf Agenten 

Nachdem ein klares Bild der Supply Chain und der (Management-)Prozesse vorhanden 

ist, erfolgt ein Mapping der relevanten Stellen auf Agenten. 

Dazu wird den Stellen der Realwelt, für die eine Planung vorgenommen werden soll, ein 

Planungsagent zugeordnet. Abbildung 4.2 zeigt, wie Agenten in bereits vorhandene Dia- 

gramme der Supply Chain integriert werden. 

Vorhandene Systeme zur Ablaufplanung, die durch Einführung der neuen Multiagenten- 

Plattform nicht abgelöst werden sollen, sind durch einen Agenten zu kapseln, der als 

Wrapper arbeitet und so eine Schnittstelle darstellt. 

51

4 Entwurf 

Beschaffung 

Leitung PA 1 

Produktion 

Auslieferung 

PA 1.1 PA 1.2 PA 1.3 

Abbildung 4.2: Zuordnung von Agenten zu Stellen 

Disziplinarisches 

Unterstellungsverhältnis 

Zuordnung eines Agenten 

zu einer Stelle 

Wichtig ist, dass die Agenten bereits zum jetzigen Zeitpunkt konsistente Bezeichnungen 

erhalten (Abbildung 4.3). Dazu erfolgt eine Numerierung, die bei dem einzelnen Agenten 

auf oberster Hierarchieebene mit „1“ beginnt. Untergeordnete Agenten erben den Namen 

ihres Vaters und erweitern diesen um eine Zahl, abhängig von ihrer horizontalen Anord- 

nung. Als Trennzeichen zwischen den Zahlen wird ein Punkt verwendet. 

1.1 1.2 

1 

1.1.1 1.1.2 1.1.3 1.2.1 1.2.2 1.3.1 

Abbildung 4.3: Benennung der Agenten 

Für eine übersichtlichere Darstellung komplexer Szenarien ist es sinnvoll, Virtuelle Orga- 

nisationseinheiten einzuführen, die eine Gruppe gleichartiger Einheiten, etwa verschie- 

dene Münzprägen, repräsentieren. Bei der späteren Verfeinerung des Modells kann dann 

entschieden werden, ob diese als konkrete Agenten zu realisieren sind oder die Kommuni- 

kation direkt vom übergeordneten Agenten zu den untergeordneten durchgereicht werden 

kann. 

52 

1.3


Die Einführung der virtuellen und neuen Agenten ist darüber hinaus ein geeignetes Werk- 

zeug für die Verbesserung der innerhalb oder zwischen den involvierten Unternehmen 

ablaufenden Geschäftsprozesse (Business Process Optimization). 

Durch die hier vorgestellte Benennung der Agenten ergeben sich systemweit eindeutige 

Namen, die gleichzeitig Rückschlüsse über die Hierarchie erlauben. In dieser Arbeit wird 

den Agentennamen noch das Kürzel „PA“ für „Planungsagent“ vorangestellt. 

4.2.2.3 Hinzufügen der Beziehungen und Teams 

In der ersten Phase des Vorgehensmodells wurden bereits Erkenntnisse über disziplina- 

rische Unterstellungsverhältnisse und funktionale Beziehungen zwischen den Stellen der 

Unternehmen gesammelt. Von besonderem Interesse sind die disziplinarischen Beziehun- 

gen, da diese auch für Kommunikation und Verhandlungen zwischen den Agenten benö- 

tigt werden. 

Funktionale Beziehungen, wie etwa die Lieferung von Gütern von einer Stelle zu einer 

anderen, werden zunächst nur implizit durch Planungswissen der Agenten modelliert. Da 

laut Appelrath et al. ([AFST00]) funktionale Beziehungen nicht mit einem Anspruch auf 

Auskunft oder direkte Abstimmung verbunden sind, soll diese Betrachtung zunächst aus- 

reichen. 

Die Agenten sind bereits Stellen der Unternehmen zugeordnet worden, zwischen denen 

disziplinarische Unterstellungsverhältnisse bestehen. Soweit möglich, können diese für 

die Agenten übernommen werden, falls nicht z.B. mehrfache Abhängigkeiten eine Auflö- 

sung erforderlich machen. Diese kann erreicht werden, indem weitere Agenten hinzuge- 

fügt oder einzelne Agenten in eine andere Hierarchiestufe verlagert werden. 

In bestimmten Fällen, z.B., wenn ein Agent Aufträge von mehreren höhergestellten Agen- 

ten bekommen kann, ist dieser Konflikt auch auf Ebene des Planungsalgorithmus lösbar. 

Dazu könnte der Agent seine Kapazitäten entweder strikt nach Auftragseingang vergeben 

oder in Form von auf einmal zu verteilenden Kontingenten verwalten. 

Für die Bildung der Teams von Agenten können einige der Aspekte verwendet werden, 

die bereits in Abschnitt 4.1 genannt wurden, bzw. aus diesen abgeleitet werden: 

• Gemeinsame Planungsaufgabe: Agenten, die an einer gemeinsamen Planungsauf- 

gabe arbeiten, z.B. an der Planung für eine Montageabteilung, können sinnvoll zu 

einem Team zusammengefasst werden. 

53

4 Entwurf 

• Control Loops / Hierarchische Position: Um den Kommunikationsaufwand gering 

zu halten und das Ablaufplanungsproblem auf einen definiert begrenzten Raum zu 

reduzieren, erfolgt eine Gruppierung geeigneter Agenten. Typischerweise befinden 

sich Agenten eines Control Loops an benachbarten Positionen innerhalb des Ge- 

samtsystems. 

• Parallelen: Bei der Gruppierung helfen kann eine Betrachtung der Realwelt, die 

Informationen über organisatorisch zusammenwirkende Stellen und damit Agenten 

liefert. 

• Gemeinsame Kommunikationsform: Neben einer benachbarten Position kann auch 

die Verwendung der gleichen Kommunikationsform bzw. eine Kommunikation un- 

tereinander geeignet sein, um Agenten eines Teams zu identifizieren. 

• Schnittstellen: Durch die Gruppierung werden automatisch Schnittstellen zwischen 

unterschiedlichen Bereichen gebildet, zwischen denen z.B. ein leitender Agent von 

oben erhaltene Grobpläne in Feinpläne für die Tagesproduktion umsetzt. Bei „Aus- 

tausch eines Bereichs“, möglicherweise bedingt durch den Einsatz eines separaten 

ERP-Systems, ist lediglich eine Anpassung des Schnittstellen-Agenten erforderlich. 

Aufgrund der genannten Gesichtspunkte ist es offensichtlich, dass an Teamgrenzen ein- 

gesetzte Agenten über deutlich komplexeres Planungswissen und komplexere Planungs- 

algorithmen verfügen müssen, als ein untergeordneter Maschinenagent. 

Für die Anwendung der Klassifizierungsmerkmale empfiehlt es sich, diese zu gewichten 

und im Zweifelsfall gegeneinander abzuwägen. Eine hohe Bedeutung sollte der Bear- 

beitung einer gemeinsamen Planungsaufgabe und der Bildung von Control Loops bei- 

gemessen werden. Die Verwendung gleicher Kommunikationsmittel ist nicht unbedingt 

Voraussetzung für Agenten innerhalb eines Teams, wie im weiteren Verlauf der Arbeit 

noch deutlich werden wird. 

4.2.2.4 Präzisierung der Agenten 

Die vorangegangenen Phasen haben gezeigt, wie individuell die Anforderungen an Agen- 

ten für verschiedene Positionen des Systems gestellt sind. Diese müssen jetzt präzisiert 

und in geeigneter Form aufbereitet werden. 

Für die Darstellung der Informationen wird ein Template verwendet, das für jeden Agen- 

ten mit seinen individuellen Daten zu füllen ist: 

54


• Name des Agenten: Der Name des Agenten, der bereits festgelegt wurde. Bei der 

Benennung der Agenten ist auf Eindeutigkeit zu achten. Ein geeignetes Verfahren 

wird in Abschnitt 4.2.2.2 vorgestellt. 

• Repräsentierte Stelle der Realwelt: Das Objekt der Realwelt, für die der Agent die 

Planungsaufgaben übernommen hat. Es kann sich dabei um ein fokales Unterneh- 

men handeln, das den Kopf der Supply Chain verkörpert, aber auch um eine Gruppe 

von Maschinen, die zu einer Abteilung zusammengefasst sind, oder um eine einzel- 

ne Maschine. 

• Verantwortungsbereich: Beschreibt den Wirkungsbereich des Agenten. Der fokale 

Kopf der Supply Chain ist z.B. für die gesamte Vorgabeplanung und eine Weiterlei- 

tung von Teilaufträgen verantwortlich. 

• Teamzugehörigkeit: Beschreibt, welchen Teams der Agent angehört. An Schnitt- 

stellen eingesetzte Agenten können Mitglied mehrerer Teams sein. Die benötigten 

Erkenntnisse wurden bereits in der Phase Hinzufügen der Beziehungen und Teams 

(Abschnitt 4.2.2.3) gesammelt. 

• Planungsaufgaben: Der Agent kann unterschiedliche Planungsaufgaben haben, ins- 

besondere dann, wenn er als leitender Agent oder im Schnittstellenbereich ein- 

gesetzt ist. Die Aufgabe kann z.B. darin bestehen, Produkte in Zwischenproduk- 

te aufzuteilen und Teilaufträge mit konkreten Zeitvorgaben weiterzuleiten. Für die 

beschriebenen Planungsaufgaben werden im späteren Verlauf der Entwicklung ge- 

eignete Algorithmen realisiert. 

• Planungswissen: Hier wird festgelegt, welcher Anteil der Datenbasis für den Agen- 

ten relevant ist und über welche Spezialinformationen, möglicherweise in den Al- 

gorithmus integriert, er verfügen muss. 

• Planungsstrategie: Für einige Planungsaufgaben bietet sich die Festlegung einer 

Strategie an. Diese könnte z.B. darin bestehen, Aufträge zum frühest möglichen 

Zeitpunkt einzuplanen, um Spielraum für nachfolgend vorgesehene Transporte zu 

gewinnen. In vielen Fällen ist eine „einfache“ Strategie nicht zu formulieren, da 

sich aus den Planungsaufgaben möglicherweise ergibt, dass eine differenzierte Be- 

trachtung notwendig ist. Inbesondere der Toplevel-Agent muss die Zeitfenster, die 

er seinen untergeordneten Agenten in Form von Aufträgen übermittelt, von deren 

Position innerhalb der Supply Chain abhängig machen. 

• Kooperation: Jeder Agent kommuniziert nur mit einigen Agenten des Gesamtsys- 

tems. Diese werden hier genannt, außerdem erfolgt eine Zuordnung der jeweils 

55

4 Entwurf 

verwendeten Kommunikationsmethode, also direkte Kommunikation, für die einfa- 

ches Delegieren (Abschnitt 2.3.3.1) verwendet wird, oder Contract Net Versteige- 

rung (Abschnitt 2.3.3.2). 

4.2.2.5 Entwurf / Auswahl der Agentenplattform 

Die bisher nur in Beziehungen und Aufbau bekannten Agenten benötigen für eine Imple- 

mentierung eine Laufzeitumgebung, in die sie möglichst ohne großen Adaptionsaufwand 

integriert werden können. Dazu erscheint der Entwurf bzw. die Verwendung einer bereits 

vorhandenen Agentenplattform sinnvoll. Um eine bestmögliche Abstimmung auf die er- 

forderlichen Leistungsmerkmale zu erhalten, bietet sich ein komplett eigenes Design an. 

Allerdings kann durch Veränderung bestehender Systeme evtl. eine deutliche Reduktion 

des Implementierungsaufwands erreicht werden. 

Beide Ansätze müssen eine Plattform entwickeln, die folgende Eigenschaften hat: 

56 

• Einheitliche Datenbankanbindung: Dem Programmierer muss ermöglicht werden, 

ohne großen Aufwand auf die benötigten Daten zuzugreifen. Typischerweise wer- 

den diese zur Laufzeit des Systems in dynamischen Objekten im Speicher bereitge- 

halten und über Operationen mit dem Datenbank-System abgeglichen. 

• Unterstützung von mehreren, unterschiedlichen Agenten zur Laufzeit: Für eine ver- 

teilte Ablaufplanung wird eine Vielzahl von Agenten benötigt. Die Plattform muss 

daher so ausgelegt sein, dass sie dieser Anforderung ohne Einbruch in der Leistung 

gerecht wird und das System skalierbar ist. 

• Bereitstellung der geforderten Kommunikationsmittel: Es muss ein Konzept für den 

Austausch von Nachrichten angeboten werden, das im besten Fall erweiterbar ist. 

Außerdem wird eine Realisierung des Contract Net Protokolls benötigt. 

• Konfiguration der Agenten: Wünschenswert sind Konfigurationsmöglichkeiten, um 

nicht für jeden Agent die erforderliche Funktionalität manuell implementieren zu 

müssen. Ein Ansatz könnte darin bestehen, dem Agenten über Stammdaten vorzu- 

geben, welche der vorhandenen Algorithmen für ihn bestimmt sind. 

• Ausreichende Flexibilität: Diese ist für die Umsetzung stark unterschiedlich arbei- 

tender Agenten erforderlich. In Abhängigkeit von dem umzusetzenden Szenario der 

Realwelt werden unterschiedliche Datenschemata, diverse Algorithmen und wech- 

selnde Teamstrukturen mit verschiedenen Ansprüchen an die Kommunikationsmit- 

tel benötigt.


Die weitere Entwurfsmethodik sollte den aktuellen Regeln der Softwaretechnik folgen 

und wird hier nicht näher beschrieben. Bei Nutzung einer vorhandenen Agentenplatt- 

form ist diese auf das Vorhandensein der gewünschten Anforderungen zu prüfen. Ggfs. 

ist festzustellen, ob notwendige Erweiterungen technisch durchführbar und wirtschaftlich 

sinnvoll sind. Eine derart offene Architektur, wie sie hier benötigt wird, ist prädestiniert 

für den Einsatz eines Frameworks (siehe Abschnitt 4.3.5). 

4.2.2.6 Ausgestaltung der Anforderungen 

Bevor die Agenten in die Laufzeitumgebung eingefügt werden, müssen die während der 

Klassifikation ermittelten Eigenschaften in einer für die Plattform geeigneten Weise auf- 

bereitet werden. Zu diesen Tätigkeiten gehören z.B.: 

• Datenschema: Es ist ein Datenschema zu erstellen, das umfassend genug ist, um die 

in der Realwelt vorgefundenen Produktions-, Transport- und Lagerprozesse darauf 

abbilden zu können. Dabei ist darauf zu achten, die Entitäten so zu wählen, dass 

das Schema auf unterschiedlichen Ebenen innerhalb der Hierarchie gleichermaßen 

einsetzbar ist. 

• Nachrichten und Kommunikation: Die verwendete Agentenplattform stellt evtl. nicht 

alle benötigten Nachrichten und Kommunikationsmittel zur Verfügung. Diese müs- 

sen dann ergänzt werden. 

• Algorithmen: Für die bei der Präzisierung der Agenten identifizierten Planungsauf- 

gaben sind geeignete Algorithmen zu erstellen. Es handelt sich dabei sowohl um 

prädiktive, als auch um reaktive Algorithmen, da jeder Agent unterschiedliche Pla- 

nungssituationen zu bearbeiten hat. Manchmal ist nur ein einzelner Auftrag in einen 

bestehenden Plan zu integrieren, in anderen Fällen ist ein komplett neuer Plan für 

alle vorliegenden Aufträge zu erstellen. 

• Stammdaten: Das fertige System soll Ablaufplanungsprobleme für reale Wirtschafts- 

prozesse lösen und muss daher mit Informationen über Produkte, Ressourcen usw. 

versorgt werden. Diese bilden die Stammdaten des Systems und sind sowohl von 

dem zugrunde liegenden Datenschema, als auch von der Ausgestaltung der Al- 

gorithmen abhängig. Bei vielen Planungssituationen kann im Vorfeld entschieden 

werden, ob Besonderheiten durch einen Algorithmus umgesetzt, oder ob die Daten 

entsprechend aufbereitet werden. Ein Beispiel dafür ist die Aufteilung eines Pro- 

dukts in Zwischenprodukte. 

• Agentenkonfiguration: Im Rahmen der Möglichkeiten der Agentenplattform ist eine 

Konfiguration der Agenten zu erstellen. Dabei wird zumindest eine Festlegung der 

57

4 Entwurf 

hierarchischen Position für jeden Agenten erfolgen. Weitere Vorgaben, etwa der zu 

verwendende Algorithmus, werden ebenfalls ausgewählt. 

• Startumgebung: Der Start des Ablaufplanungssystems sollte alle benötigten Agen- 

ten aufrufen und mit den initial notwendigen Parametern versorgen. In Abhängig- 

keit von der Agentenplattform ist eine Startumgebung bereitzustellen, die dieses 

leisten kann. 

4.2.2.7 Integration des Systems 

Das Ergebnis der Integration des Systems ist ein ablauffähiges, evtl. aus mehreren Kom- 

ponenten bestehendes Ablaufplanungssystem, das mittels der gemäß den Anforderungen 

konfigurierten Agenten die Planungsaufgaben der Supply Chain bewältigt. Hierfür wer- 

den die bisherigen Ergebnisse zusammengefügt bzw. in Form von Sourcecode realisiert. 

4.2.2.8 Test und Verifikation 

Eine relative sichere Eigenschaft komplexer Systeme ist ihre Sensibilität für Fehler, die 

zu Abstürzen oder schwerwiegenden Fehlberechnungen führen können. Das System ist 

daher mit geeigneten Testdaten für das definierte Szenario auf Übereinstimmung mit den 

Anforderungen zu überprüfen. Diese Daten werden im Rahmen der Entwicklung erstellt. 

Weitere Test- und Verifikationsverfahren sollten wieder den Regeln der Softwaretechnik 

folgen und sind nicht Teil des Vorgehensmodells. 

4.3 Umsetzung für das Beispiel Euro-Münzen 

Gestützt auf das Vorgehensmodell werden im Folgenden die vorgestellten Arbeitsschritte 

für das Beispiel der Euro-Münzen umgesetzt. 

4.3.1 Analyse des Realwelt-Szenarios 

Die Analyse des Realwelt-Szenarios ist Thema von Kapitel 3 und damit bereits abge- 

schlossen. Ein Ablaufplanungssystem für den Einsatz im konkreten Unternehmensumfeld 

benötigt natürlich weitaus umfangreichere und genauere Informationen. Für dieses Bei- 

spiel sollte der gewählte Betrachtungshorizont allerdings ausreichen. Bei tatsächlicher 

Unternehmensbeteiligung ist aber auch mit einer deutlichen Erleichterung der Informati- 

onsgewinnung zu rechnen. 

58


4.3.2 Mapping der relevanten Stellen auf Agenten 

Zur Abbildung der in der für die Euro-Produktion bestehenden Supply Chain enthaltenen 

Organisationseinheiten auf Agenten wird zunächst die in Abbildung 3.2 implizit enthal- 

tene Auftragshierarchie weiter verfeinert. 

BUND 

PA 1 

Ronden S-Transport 

Münzen LZB 

PA 1.1 PA 1.2 PA 1.3 PA 1.4 

Abbildung 4.4: Globale Sicht der Supply Chain 

Abbildung 4.4 zeigt, dass für die globale Steuerung der Supply Chain der Bund zuständig 

ist. Aus den Mengenplanungen für die benötigten Münzen generiert er Aufträge für Ron- 

denproduzenten, Münzen, Landeszentralbanken und Sicherheitstransporte. Den Ronden- 

produzenten obliegt es, sich die benötigten Rohmetallmengen zu beschaffen. Die dafür 

notwendigen Transporte werden von den Metalllieferanten beauftragt. 

Wie im Vorgehensmodell beschrieben, werden für alle dem Bund untergeordneten Entitä- 

ten zunächst Virtuelle Organisationseinheiten eingeführt, wodurch sich der Toplevel der 

Supply Chain zunächst sehr übersichtlich darstellen lässt. 

Da Abbildung 4.4 die Auftragsvergabe und nicht den Materialfluss zeigt, sind die Si- 

cherheitstransportunternehmen nur an einer Position dargestellt. Wie bereits beschrieben, 

handelt es sich um einen Pool von Unternehmen, die wiederum durch einen fokalen Kopf 

gegenüber dem Bund repräsentiert werden. 

Abbildung 4.5 zeigt die nächste Verfeinerungsstufe der Supply Chain. Bis auf die Si- 

cherheitstransporte werden alle Organisationseinheiten hier in einer aufgefalteten Struk- 

tur dargestellt. 

59

4 Entwurf 

BUND 

Ronden PA S-Transport PA Münzen PA LZB 

PA 1.1 1.2 1.3 1.4 

Ronden 1 

PA 1.1.1 

Ronden 2 PA 1.1.2 

PA 1 

Münze HH 

Münze M 

Münze B 

Münze S 

Münze KA 

PA 1.3.1 

PA 1.3.2 

PA 1.3.3 

PA 1.3.4 

PA 1.3.5 

Abbildung 4.5: Globale Sicht der Supply Chain mit aufgefalteten 

Virtuellen Organisationseinheiten 

Analog zu Abbildung 3.2 sind auch in dieser Abbildung für die Bereiche Metall (Rohstof- 

fe), Rondenproduktion und Landeszentralbanken (Lagerung, „Endkunde“) jeweils zwei 

Einheiten abgebildet, was die Übersicht vereinfacht und zur Illustration der Anforderun- 

gen ausreicht. 

Abbildung 4.6 zeigt die interne Struktur eines Rondenherstellers. Die für Beschaffung 

verantwortliche Abteilung kommuniziert mit den Metalllieferanten und sorgt für termin- 

gerechte Anlieferung des Rohmaterials. Für die eigentliche Produktion sind sieben wei- 

tere Abteilungen vorgesehen. 

Eine Betrachtung von Ein- und Ausgangslagern unterbleibt. Es ist anzumerken, dass auf- 

grund des Fertigungsablaufs auch die Rondenproduktion bereits als Supply Chain ange- 

sehen werden kann. Für das hier zu entwerfende System werden die vom Bund erhaltenen 

Produktionsaufträge in Teilaufträge zerlegt und direkt an die Abteilungen weitergeleitet. 

Jede Abteilung wird durch einen Agenten verkörpert, der aus den vom übergeordne- 

ten Agenten erhaltenen Aufträgen Arbeitspläne für angeschlossene Maschinenagenten 

erstellt, bzw. über einen Wrapper bestehende Planungssysteme mit Plandaten versorgt. 

Ausgehend von globalen Vorgaben über Rondenmengen und deren Bereitstellungszeit- 

punkte realisieren die Agenten die konkrete Erfüllung der einzelnen Schritte. Der oder 

die weiteren Rondenhersteller im System sind analog aufgebaut. 

60 

LZB 1 

LZB 2 

PA 1.4.1 

PA 1.4.2

Beschaffung 

Giessen 

Walzen 

Ronden 1 PA 1.1.1 

Stanzen 


Randrieren 

Glühen 

Polieren 

PA 1.1.1.1 PA 1.1.1.3 PA 1.1.1.5 PA 1.1.1.7 

Metall 1 Metall 2 

PA 1.1.1.1.1 

Prüfung 

PA 1.1.1.2 PA 1.1.1.4 PA 1.1.1.6 PA 1.1.1.8 

PA 1.1.1.1.2 

Ronden PA 1.1 

Abbildung 4.6: Produktion der Ronden 

Verglichen mit den Rondenherstellern ist die interne Struktur einer Münze deutlich we- 

niger komplex. Es wird deutlich, dass mit der Rondenproduktion bereits ein wesentlicher 

Anteil für das Gesamtprodukt erbracht worden ist. Abbildung 4.7 zeigt die Abteilungen 

einer Münze. Hier findet keine Kommunikation mit vorgelagerten Stufen statt, da durch 

die globale Steuerung eine Anlieferung der benötigten Vorprodukte erreicht wird. 

Das Planungsproblem reduziert sich daher auf eine korrekte Vergabe der Aufträge an 

die Abteilungen Prägen, Prüfen und Verpacken. Diese Abteilungen werden jeweils durch 

einen Agenten repräsentiert. 

Für die Realisierung der Sicherheitstransporte ist ein Pool von Unternehmen vorgesehen, 

der gegenüber dem Bund durch ein fokales Unternehmen vertreten wird. In Abbildung 

4.8 ist die weitere Untergliederung des Transportwesens dargestellt. 

Im Gegensatz zu den produzierenden Einheiten für Ronden und Münzen hat der Agent, 

der die Rolle des fokalen Unternehmens im System übernimmt, die Aufgabe, vom Bund 

61

4 Entwurf 

S-Trans 1 

1.3.1 

1.3.1.1 1.3.1.2 1.3.1.3 

Abbildung 4.7: Prägung der Münzen 

S-Transport PA 1.2 

S-Trans 2 

S-Trans 3 

PA 1.2.1 PA 1.2.2 PA 1.2.3 

Abbildung 4.8: Verteilung der Sicherheitstransporte 

1.3 

S-Trans 4 

PA 1.2.4 

erhaltene Transportaufträge geeignet umzugruppieren, um sie dann an die weiteren Agen- 

ten im Team zu verteilen. Da die an zwei verschiedenen Stellen der Supply Chain benö- 

tigten Sicherheitstransporte durch ein Team von Agenten gesteuert werden, ergeben sich 

Potenziale für eine Optimierung, bevor eine Versteigerung an angeschlossene Unterneh- 

men erfolgt. 

62


4.3.3 Hinzufügen der Beziehungen und Teams 

Alle disziplinarischen Beziehungen, die für das hier zu realisierende System benötigt wer- 

den, können direkt aus den bereits vorhandenen Diagrammen übernommen werden. Eine 

Ergänzung bzw. Entfernung einzelner Kanten des Beziehungssystems scheint zum jetzi- 

gen Zeitpunkt nicht notwendig. 

Da vorgesehen ist, den Bund über die an Rondenhersteller, Münzprägen und Landeszen- 

tralbanken zu vergebenden Produktions- und Lageraufträge selbst entscheiden zu lassen, 

können die virtuellen Knoten Ronden, Münzen und LZB aus dem System entfernt werden. 

Die benötigten Contract Net Versteigerungen werden vom Bund durchgeführt und direkt 

mit den konkreten Agenten der Produzenten bzw. Landeszentralbanken ausgehandelt. 

Anhand des Vorgehensmodells soll jetzt eine Gruppierung der Agenten in Teams erfol- 

gen. Dazu werden zunächst die Kriterien Gemeinsame Planungsaufgabe, Control Loops 

und Parallelen zur Realwelt herangezogen und in der genannten Reihenfolge gewichtet. 

Sollten diese nicht ausreichen, werden evtl. weitere gewählt. 

Ein Blick auf die bisher erstellten Grafiken und an die einzelnen Organisationseinheiten 

gestellten Anforderungen ergibt mittels der Gruppierungsaspekte eine geeignete Eintei- 

lung der Agenten in Teams: 

• Toplevel: Das oberste Team des Systems besteht aus dem Bund und den leitenden 

Agenten von Rondenherstellern, Sicherheitstransporten, Münzen und Landeszen- 

tralbanken. Der Bund ermittelt aus den benötigten Münzmengen Aufträge für die 

ihm unterstehenden Abteilungen und versteigert diese (Ronden und Münzen) bzw. 

übergibt komplette Auftragspakete (Sicherheitstransporte). Die Verteilung der fer- 

tigen Münzen auf LZBs erfolgt nach einem festgelegten Aufteilungsschlüssel, um 

den Bedarfen der einzelnen Bundesländer gerecht zu werden. 

• Ronden: Jeder Rondenhersteller bildet ein Team von Agenten. Der leitende Agent 

generiert aus den vom Bund erhaltenen Aufträgen Teilaufträge zur Steuerung der 

einzelnen Abteilungsagenten. Eine genauere Betrachtung der Metalllieferanten soll 

zunächst nicht erfolgen. Daher werden die diese verkörpernden Agenten mit in die 

Ronden-Teams aufgenommen und als disjunkt betrachtet. Für eine spätere Erwei- 

terung ist eine Aufteilung denkbar. 

• Münzen: Die Teams der Münzhersteller ähneln denen der Rondenproduktion und 

sind deutlich weniger komplex aufgebaut. 

63

4 Entwurf 

• Sicherheitstransporte: Das Team der Sicherheitstransporte besteht aus dem fokalen 

Unternehmen zur Repräsentation des Teams gegenüber dem Bund, sowie aus den 

beteiligten Sicherheitsunternehmen. Wie bereits beschrieben, ist es Aufgabe des 

fokalen Unternehmens, die vom Bund erhaltenen Auftragspakete umzugruppieren 

und an die Unternehmen zu versteigern. 

• Landeszentralbanken: Die einzelnen Landeszentralbanken stellen jeweils ein eige- 

nes Team dar, das lediglich aus einem einzelnen Agenten besteht. Für spätere Ent- 

wicklungen ist auch hier eine Ergänzung denkbar, z.B. durch eine weitere Auftei- 

lung der LZB-Teams in Zweiganstalten. So wäre eine automatisierte, verfeinerte 

Disposition der Münzmengen realisierbar. 

Teamname Beteiligte Organisationseinheiten Zugehörige Agenten 

Toplevel Bund, Leitende Stellen von Rondenherstellern, 

Münzen, Sicherheitstransporten, 

LZBs 

Ronden 1 Ronden 1, Beschaffung, Walzen, Giessen, 

Stanzen, Randrieren, Glühen, Polieren, 

Prüfung, Metall 1, Metall 2 

Ronden 2 Ronden 2, Beschaffung, Walzen, Giessen, 

Stanzen, Randrieren, Glühen, Polieren, 

Prüfung, Metall 3, Metall 4 

PA1, PA1.1, PA1.2, PA1.3, PA1.4 

PA1.1.1, PA1.1.1.1, PA1.1.1.2, PA1.1.1.3, 

PA1.1.1.4, PA1.1.1.5, PA1.1.1.6, PA1.1.1.7, 

PA1.1.1.8, PA1.1.1.1.1, PA1.1.1.1.2 

PA1.1.2, PA1.1.2.1, PA1.1.2.2, PA1.1.2.3, 

PA1.1.2.4, PA1.1.2.5, PA1.1.2.6, PA1.1.2.7, 

PA1.1.2.8, PA1.1.2.1.1, PA1.1.2.1.2 

Münze HH Münze HH, Prägung, Prüfung, Verpacken PA1.3.1, PA1.3.1.1, PA1.3.1.2, PA1.3.1.3 

Münze M Münze M, Prägung, Prüfung, Verpacken PA1.3.2, PA1.3.2.1, PA1.3.2.2, PA1.3.2.3 

Münze B Münze B, Prägung, Prüfung, Verpacken PA1.3.3, PA1.3.3.1, PA1.3.3.2, PA1.3.3.3 

Münze S Münze S, Prägung, Prüfung, Verpacken PA1.3.4, PA1.3.4.1, PA1.3.4.2, PA1.3.4.3 

Münze KA Münze KA, Prägung, Prüfung, Verpacken PA1.3.5, PA1.3.5.1, PA1.3.5.2, PA1.3.5.3 

S-Transport S-Transport, S-Trans 1, S-Trans 2, S-Trans 

3, S-Trans 4 

LZB 1 LZB 1 PA1.4.1 

LZB 2 LZB 2 PA1.4.2 

Tabelle 4.1: Zugehörigkeit der Agenten zu Teams 

PA1.2, PA1.2.1, PA1.2.2, PA1.2.3, PA1.2.4 

Die vorgestellte Einteilung der Agenten in Teams entspricht den genannten Kriterien. Die 

gewünschten Schnittstellen zwischen verschiedenen Bereichen sind durch die notwendi- 

gen Umgruppierungen von Aufträgen ebenfalls gegeben. Das Toplevel-Team zeigt, dass 

es u.U. sinnvoll ist, das Kriterium der gemeinsamen Kommunikationsform zu verletzen, 

wenn andere Aspekte höher zu gewichten sind. Tabelle 4.1 liefert einen Überblick über 

die genaue Zugehörigkeit der Agenten zu den Teams. 

64


Obwohl bei Rondenherstellern und Landeszentralbanken nur eine eingeschränkte Anzahl 

von Entitäten verwendet wird, ist eine spätere Erweiterung leicht möglich, da die entspre- 

chenden Agenten identisch aufzubauen sind und sich lediglich bezüglich ihrer Benennung 

und der Stammdaten (Verfügbarkeiten, etc.) unterscheiden. 

4.3.4 Präzisierung der Agenten 

In der Übersicht wurde gezeigt, welche Entitäten der Supply Chain auf Agenten abgebil- 

det werden und wie sich einzelne Teams von Agenten im System zusammensetzen. Für 

die weitere Entwicklung müssen jetzt die Aufgaben und Unterschiede der Agenten be- 

trachtet werden. Dazu wird das im Vorgehensmodell eingeführte Template für die Agen- 

teneigenschaften mit konkreten Inhalten gefüllt. Sofern Agenten identische Eigenschaften 

aufweisen, werden diese gemeinsam beschrieben. 

Agent PA1: 

• Repräsentierte Stelle der Realwelt: Repräsentiert den Bund und damit den fokalen 

Kopf der gesamten Supply Chain. 

• Verantwortungsbereich: Globaler Ablauf der Produktion, vergibt Aufträge für Zwi- 

schenprodukte und Transporte. 

• Teamzugehörigkeit: Toplevel. 

• Planungsaufgaben: Aufteilung der Produkte in Produktions- und Transportschritte. 

• Planungswissen: Informationen über Produkte und deren Aufteilung in Schritte, 

grobes Wissen über Kapazitäten der in der Hierarchie tiefer stehenden Organisati- 

onseinheiten. 

• Planungsstrategie: Differenziert, d.h., die zu vergebenden Aufträge werden je nach 

Position der Empfänger innerhalb der Supply Chain vorgeplant. 

• Kooperation: Manager in verschiedenen Contract Net Verhandlungen (Rondenher- 

steller, Münzen, Agenten PA1.1.1, PA1.1.2, PA1.3.1, PA1.3.2, PA1.3.3, PA1.3.4, PA1.3.5); 

direkte Kommunikation mit dem fokalen Agenten der Sicherheitstransporte (Agent 

PA1.2) und dem der LZBs (Agenten PA1.4.1, PA1.4.2). 

Agenten PA1.1, PA1.3, PA1.4: 

• Wie bereits beschrieben, werden diese Virtuellen Agenten bei der Realisierung des 

Systems nicht berücksichtigt und die Kommunikation direkt an die tiefer stehenden 

Agenten weitergereicht. 

65

4 Entwurf 

Agenten PA1.1.1, PA1.1.2: 

• Repräsentierte Stelle der Realwelt: Rondenhersteller. 

• Verantwortungsbereich: Lokale Planung der Rondenproduktion am jeweiligen Stand- 

ort. 

• Teamzugehörigkeit: Toplevel und Ronden 1 bzw. Ronden 2. 

• Planungsaufgaben: Aufteilung der Produkte (Ronden) in Zwischenprodukte. 

• Planungswissen: Informationen über Produkte und deren Aufteilung in Produkti- 

onsschritte. 

• Planungsstrategie: Frühestmögliche Startzeit. 

• Kooperation: Contractor in Contract Net Verhandlung mit dem Bund (Agent PA1); 

direkte Kommunikation mit den eigenen Abteilungsagenten (Agenten PA1.1.1.x bzw 

PA1.1.2.x, x ∈ {1,...,8}). 

Agent PA2.1: 

• Repräsentierte Stelle der Realwelt: Fokaler Kopf der Sicherheitstransportunterneh- 

men. 

• Verantwortungsbereich: Lokale Planung der Sicherheitstransporte. 

• Teamzugehörigkeit: Toplevel und S-Transport. 

• Planungsaufgaben: Umgruppierung der Transporte in technisch sinnvolle Größen, 

Weiterverteilung. 

• Planungswissen: Informationen über Transportgrößen und Kapazitäten. 

• Planungsstrategie: Frühestmögliche Anlieferung. 

• Kooperation: Direkte Kommunikation mit dem Bund (Agent PA1); Manager in 

Contract Net Verhandlungen mit den Sicherheitstransportunternehmen (Agenten 

PA1.2.1, PA1.2.2, PA1.2.3, PA1.2.4). 

Agenten PA1.3.1, PA1.3.2, PA1.3.3, PA1.3.4, PA1.3.5: 

66 

• Repräsentierte Stelle der Realwelt: Münzen in HH, M, B, S, KA. 

• Verantwortungsbereich: Lokale Planung der Münzprägung am jeweiligen Standort.


• Teamzugehörigkeit: Toplevel und je nach Standort Münze HH, Münze M, Münze 

B, Münze S oder Münze KA. 

• Planungsaufgaben: Aufteilung der Produkte (Münzen) in Zwischenprodukte. 

• Planungswissen: Informationen über Produkte und deren Aufteilung. 

• Planungsstrategie: Spätestmögliche Fertigstellung. 

• Kooperation: Contractor in Contract Net Verhandlung mit dem Bund (Agent PA1); 

direkte Kommunikation mit den Agenten der einzelnen Abteilungen am eigenen 

Standort (Agenten PA1.3.1.x, PA1.3.2.x, PA1.3.3.x, PA1.3.4.x bzw. PA1.3.5.x, x ∈ {1,...,3}). 

Agenten PA1.4.1, PA1.4.2: 

• Repräsentierte Stelle der Realwelt: Landeszentralbanken. 

• Verantwortungsbereich: Lokale Lagerraumplanung / Verwaltung. 

• Teamzugehörigkeit: Toplevel und LZB 1 bzw. LZB 2. 

• Planungsaufgaben: Einlagerung von Münzen, Kapazitätsauskunft. 

• Planungswissen: Informationen über Kapazitätsbedarf und Verfügbarkeit. 

• Planungsstrategie: Maximale Auslastung. 

• Kooperation: Contractor in Contract Net Verhandlung mit dem Bund (Agent PA1). 

Agenten PA1.1.1.1, PA1.1.2.1: 

• Repräsentierte Stelle der Realwelt: Beschaffungsabteilung der Rondenhersteller. 

• Verantwortungsbereich: Lokale Beschaffungsplanung des jeweiligen Standortes. 

• Teamzugehörigkeit: Ronden 1 bzw. Ronden 2. 

• Planungsaufgaben: Verteilung der benötigten Metallmengen auf Lieferanten. 

• Planungswissen: Informationen über Kapazitäten der Lieferanten. 

• Planungsstrategie: Frühestmögliche Beschaffung. 

• Kooperation: Manager in Contract Net Verhandlungen mit den Rohmetalllieferan- 

ten (Agenten PA1.1.1.1.1, PA1.1.1.1.2 bzw. PA1.1.2.1.1, PA1.1.2.1.2). 

67

4 Entwurf 

Agenten PA1.1.1.x, PA1.1.2.x, x ∈ {2,...,8}: 

• Repräsentierte Stelle der Realwelt: Einzelne Produktionsabteilungen der jeweiligen 

Standorte der Rondenhersteller. 

• Verantwortungsbereich: Lokale Planung der jeweiligen Abteilung. 

• Teamzugehörigkeit: Ronden 1 bzw. Ronden 2. 

• Planungsaufgaben: Lokale Ablaufplanung der betrachteten Abteilung. 

• Planungswissen: Informationen über die gefertigten Produkte, Kapazitäten. 

• Planungsstrategie: Frühestmögliche Startzeit. 

• Kooperation: Direkte Kommunikation mit dem leitenden Agenten des jeweiligen 

Rondenherstellers (Agent PA1.1.1 bzw. PA1.1.2). 

Agenten PA1.3.1.x, PA1.3.2.x, PA1.3.3.x, PA1.3.4.x, PA1.3.5.x, x ∈ {1,2,3}: 

• Repräsentierte Stelle der Realwelt: Einzelne Produktionsabteilungen der jeweiligen 

Standorte der Münzen. 

• Verantwortungsbereich: Lokale Planung der jeweiligen Abteilung. 

• Teamzugehörigkeit: Abhängig vom Standort Münze HH, Münze M, Münze B, Mün- 

ze S oder Münze KA. 

• Planungsaufgaben: Lokale Ablaufplanung der betrachteten Abteilung. 

• Planungswissen: Informationen über die gefertigten Produkte, Kapazitäten. 

• Planungsstrategie: Spätestmögliche Startzeit. 

• Kooperation: Direkte Kommunikation mit dem leitenden Agenten der Münze (Agent 

PA1.3.1, PA1.3.2, PA1.3.3, PA1.3.4 oder PA1.3.5). 

Agenten PA1.2.1, PA1.2.2, PA1.2.3, PA1.2.4: 

68 

• Repräsentierte Stelle der Realwelt: Verschiedene Sicherheitstransportunternehmen. 

• Verantwortungsbereich: Lokale Planung von Sicherheitstransporten im jeweiligen 

Unternehmen. 

• Teamzugehörigkeit: S-Transport. 

• Planungsaufgaben: Verteilung / Bündelung der Transporte auf Fahrzeuge.


• Planungswissen: Informationen über Kapazitäten und Transporteinheiten. 

• Planungsstrategie: Frühestmögliche Anlieferung. 

• Kooperation: Contractor in Contract Net Verhandlung mit dem Fokalen Unterneh- 

men der Sicherheitstransporte (Agent PA1.2). 

Agenten PA1.1.1.1.1, PA1.1.1.1.2, PA1.1.2.1.1, PA1.1.2.1.2: 

• Repräsentierte Stelle der Realwelt: Rohmetalllieferanten. 

• Verantwortungsbereich: Verwaltung verfügbarer Ressourcenmengen an Metall. 

• Teamzugehörigkeit: Ronden 1 bzw. Ronden 2, näheres in Abschnitt 4.3.3. 

• Planungsaufgaben: Bereitstellung von Metall, Kapazitätsauskunft. 

• Planungswissen: Informationen über Mengenverfügbarkeit. 

• Planungsstrategie: Maximale Auslastung. 

• Kooperation: Contractor in Contract Net Verhandlung mit der Beschaffungsabtei- 

lung des jeweiligen Rondenherstellers (Agent PA1.1.1.1 bzw. PA1.1.2.1). 

4.3.5 Entwurf / Auswahl der Agentenplattform 

4.3.5.1 Übersicht 

Für die softwaretechnische Umsetzung dieser Arbeit soll kein komplett eigenständiger 

Entwurf eines Multiagenten-Systems erfolgen, sondern eine bereits bestehende Agen- 

tenplattform Verwendung finden. Es handelt sich dabei um ein von Bröske im Rahmen 

einer Diplomarbeit konzeptioniertes Framework 1 für Planungsagenten ([Bro01]). Dieses 

Framework soll im Folgenden vorgestellt und auf das Vorhandensein der gewünschten 

Anforderungen überprüft werden. Notwendige Anpassungsarbeiten werden ebenfalls be- 

schrieben. 

Abbildung 4.9 2 zeigt den schematischen Aufbau eines Planungsagenten, der mit dem Fra- 

mework realisiert werden kann. Die in Form von Frozen Spots 3 realisierten Komponenten 

1 Gemäß [JF88] ist ein Framework eine Menge von Klassen, die ein abstraktes Design für Lösungen zu 

einer Familie bekannter Probleme bieten, und so Wiederverwertung auf höherer Ebene als einfache 

Klassenbibliotheken erlauben. 

2 Angelehnt an [Bro01] 

3 Frozen Spots stellen die den Anwendungen einer Domäne gemeinsamen Funktionen dar und werden 

durch das Framework implementiert. 

69

4 Entwurf 

- externe Nachrichten 

- interne Anfragen 

Datenbank- 

Schnittstelle 

Contract 

Net 

Kommunikations- 

Schnittstelle 

Datenbank Kommunikation 

- Plan 

- Stammdaten 

Planungskomponente(n) 

Planung 

Contract Net 

Planverbesserung 

Abbildung 4.9: Schematischer Aufbau eines Planungsagenten 

des Frameworks von Bröske 

sind in der Darstellung grau unterlegt, die Schnittstellen für die Hot Spots 4 sind durch Ver- 

bindungspunkte hervorgehoben. Hier ist die Anbindung von eigenen, auf den spezifischen 

Anwendungsfall abgestimmten Algorithmen vorgesehen. 

Die einzelnen Komponenten des Agenten sind in einer Schichtenarchitektur angeordnet, 

welche in Abbildung 4.10 5 dargestellt ist. Zentrale Elemente, wie der Agenten-Kern, Un- 

terstützung für das Contract Net Protokoll, Datenbank und Kommunikation sind erkenn- 

bar und sollen jetzt näher beschrieben werden. 

4.3.5.2 Erläuterung der Komponenten 

Agenten-Kern (Frozen Spot) 

Dem Agenten-Kern obliegen die zentralen Aufgaben des Agenten. Insbesondere erfolgt 

hier die Ereignisverarbeitung, d.h., eingehende Nachrichten werden an die zuständigen 

4 Hot Spots repräsentieren die variablen Teile einer Domäne, die durch den Anwendungsprogrammierer 

angepasst werden. 

5 Angelehnt an [Bro01] 

70


Datenbank- 

Schnittstelle 

Datenbank 



Planung 

Contract Net 

Contract Net 

Kommunikations- 

Schnittstelle 

Netzwerk 

Abbildung 4.10: Schichtenarchitektur eines Planungsagenten 

des Frameworks von Bröske 

Komponenten weitergeleitet. Die Nachrichten selbst bestehen aus KQML-Statements mit 

strukturiertem Text als Inhalt. Vorgesehen ist die Bearbeitung der in Abschnitt 2.1.2 ge- 

nannten Ereignisse, erweitert um Funktionen für die Contract Net Versteigerung. Sofern 

keine aktuellen Ereignisse zu behandeln sind, übergibt der Agenten-Kern die Kontrolle 

an die Komponente Planverbesserung. 

Neben dieser Tätigkeit ist der Agenten-Kern Vermittler und Dienstleister der Komponen- 

ten und führt z.B. Datenbankabfragen aus. Weitere Aufgaben bestehen in der Speicherung 

von Informationen über den Status, den eindeutigen Namen des Agenten und die Bezie- 

hungen zu anderen Agenten des Systems. Technisch ist der Agenten-Kern als Automat 

realisiert. 

Planung (Hot Spot) 

Durch individuelle Ausgestaltung dieser Komponente kann das Framework an unter- 

schiedliche Planungssituationen angepasst werden. Dabei können auch mehrere Kom- 

ponenten dieser Art existieren, die mittels separater Hooks beschrieben werden. So be- 

steht die Möglichkeit, für neue Konstellationen neue Ereignisse und neue Algorithmen 

zu entwickeln und diese in separaten, leichter wartbaren Blöcken unterzubringen. Um ei- 

71

4 Entwurf 

ne Reduzierung der Laufzeit zu erreichen, werden zunächst nur Hard Constraints bei der 

Planung berücksichtigt. 

Fehlerbehandlung (Frozen Spot) 

Sollte es dazu kommen, dass ein Agent die Anforderung eines anderen Agenten hinsicht- 

lich der vorhandenen Planungs-Komponenten nicht erfüllen kann, liefert diese Kompo- 

nente eine Fehlermeldung zurück. Um eine standardisierte Bearbeitung zu gewährleisten, 

ist diese Funktion als Frozen Spot implementiert. 

Planverbesserung (Hot Spot) 

In den Zeitabschnitten, in denen der Agent keine Ereignisse verarbeiten oder anderen Ak- 

tivitäten nachkommen muss, wird die Kontrolle an diese Komponente übergeben. Ihr Ziel 

ist es, den bestehenden Plan des Agenten anhand einer Bewertungsfunktion zu optimieren. 

Dabei sind die üblichen Restriktionen zu beachten, d.h., Änderungen am Plan sollten nur 

dann durchgeführt werden, wenn der dazu notwendige Aufwand durch das Ergebnis auch 

gerechtfertigt wird. Zu vermeiden ist, dass auch Pläne von Agenten, die in der Hierarchie 

höher gestellt sind, beeinflusst werden. Änderungen an Teilen des Plans, die unmittelbar 

vor der Ausführung stehen, sollten unterbleiben, um Unruhe in der Produktion zu vermei- 

den. 

Contract Net (Frozen Spot) 

Das Contract Net als wesentliches Element der Verhandlungen zwischen den Agenten 

ist als Frozen Spot realisiert und arbeitet nach den in Abschnitt 2.3.3.2 beschriebenen 

Modalitäten. Um einzelnen Agenten in Abhängigkeit von ihrer Planungssituation unter- 

schiedliche Verhaltensweisen zu ermöglichen, sind die Hot Spot Komponenten Manager 

und Contractor vorgesehen. 

Manager (Hot Spot) 

In dieser Komponente sind die Phasen Ausschreiben und Zuschlag erteilen des Contract 

Net Protokolls definiert. Durch diese Auslagerung ergibt sich die Möglichkeit, das Verhal- 

ten des Agenten bei der Versteigerung zu beeinflussen. Z.B. kann ein zu versteigernder 

Auftrag, für den keine Gebote abgegeben wurden, in kleinere Teilaufträge zerlegt und 

erneut ausgeschrieben werden. 

Contractor (Hot Spot) 

Analog zu der Komponente Manager wird hier die Phase Bieten des Contract Net Pro- 

tokolls definiert. Die Art und Weise, in der ein Agent handeln soll, kann hier adaptiert 

72


werden. Typischerweise wird ein Agent bei einer neuen Versteigerung seine eigenen Fä- 

higkeiten prüfen und, wenn er dazu in der Lage ist, auch ein Gebot abgeben. 

Kommunikation (Frozen Spot) 

Die für die Kommunikation der Agenten benötigten Queues für eingehende und aus- 

gehende Nachrichten werden von dieser Komponente bereitgestellt. Nachrichten in der 

Eingangs-Queue werden an die Ereignisverarbeitung des Agenten-Kerns weitergeleitet, 

wobei eine Priorisierung zur bevorzugten Weiterleitung vorgesehen ist. 

Nachrichtenübertragung (Hot Spot) 

Diese Komponente kapselt die technische Realisierung der Kommunikation und ist dafür 

verantwortlich, die Übertragung der Nachrichten zwischen den unterschiedlichen Queues 

mittels eines geeigneten Mediums zu ermöglichen. 

Datenbankschnittstelle (Frozen Spot) 

Die Datenbankschnittstelle sorgt für die Umsetzung der Anfragen des Agenten-Kerns in 

für eine relationale Datenbank verständliche SQL-Ausdrücke. Das Design der Datenbank, 

bzw. das Datenschema, ist hier ebenfalls festgeschrieben. 

Anbindung an das DBMS (Hot Spot) 

Analog zur Komponente Nachrichtenübertragung erfolgt auch hier eine Kapselung der 

technischen Realisierung für die Anbindung der Datenbankschnittstelle an eine konkrete 

Datenbank. Besonderheiten in den Schnittstellen unterschiedlicher relationaler Datenban- 

ken kann so begegnet werden. 

4.3.5.3 Ablauf der Verarbeitung 

Der Agenten-Kern ist als Endlicher Automat realisiert, dessen Zustände in Abbildung 

4.11 6 dargestellt sind. In Zustand 1 prüft der Agenten-Kern, ob neue Nachrichten in der 

Eingangs-Queue vorhanden sind. Ist dies der Fall, wechselt er in Zustand 2 und übergibt 

die Kontrolle an die zuständige Einheit, die er anhand der Nachrichtenkennung identi- 

fiziert. Bei Datenbankanfragen oder zu versendenden Nachrichten erhält der Kern den 

Kontrollfluss zurück (Zustand 4). 

Sind keine Nachrichten vorhanden, wird dies vom Agenten über ein Flag in der Kom- 

munikationsschnittstelle vermerkt und der Kontrollfluss an die Komponente Planverbes- 

serung übergeben (Zustand 3). Diese kann ebenfalls Dienstleistungen des Kerns in An- 

spruch nehmen (Zustand 4) oder beim Eintreffen neuer Nachrichten unterbrochen werden. 

6 Entnommen aus [Bro01] 

73

Kapitel 3: Konzept 4 Entwurf eines Frameworks für Planungsagenten 55 

Datenbankschnittstelle 

Kommunikationschnittstelle 

-Eingangs-Queue 

-Ausgangs-Queue 

1 

Agenten 

Initialisierung 

Interrupt 

4 

2 

3 

Interrupt 

Agenten-Kern 

Legende 

ABBILDUNG 18: AGENTEN-KERN: ENDLICHER AUTOMAT 

Abbildung 4.11: Agenten-Kern: Endlicher Automat 



Zustand 1: Agenten-Kern fragt Nachricht ab 

Zustand 2: Neue Nachricht vorhanden: 

Planungskomponente aktiv 

Zustand 3: Keine neue Nachricht: 

Planverbesserung aktiv 

Zustand 4: "Dienstleistungszustand" 

Ein Agent prüft zunächst, ob eine neue Nachricht in der Eingangs-Queue der 

Kommunikationsschnittstelle 

Bei Zustand 4 handelt 

vorhanden 

es sich um 

ist 

den 

(Zustand 

Dienstleistungszustand 

1). Ist dies der 

des 

Fall, 

Agenten. 

übergibt 

Hier wer- 

der Agentenden 

ggfs. Datenbankanfragen bearbeitet oder Nachrichten an die Kommunikationskom- 

Kern diese Nachricht an die entsprechende Einheit, die er anhand der Kennung identifiziert 

ponente zum Versand übergeben. Eine detailliertere Beschreibung der involvierten Ge- 

(Zustand 

schäftsprozesse 

2). Die planende 

findet 

Einheit 

sich bei 

hat 

Bröske 

jetzt 

([Bro01]). 

auch die Kontrolle über den Kontrollfluss, allerdings 

geht diese bei Datenbankanfragen oder neu zu versendenden Nachrichten wieder auf den Kern 

über, damit Der dieser Agenten-Kern die entsprechenden ist in drei Bereiche Leistungen unterteilt: erbringen kann (Zustand 4). 

Falls keine Nachricht im Eingangs-Queue vorhanden ist, setzt der Agenten-Kern ein spezielles 

• Agenten-Kern Control: Initialisiert den Agenten und steuert anschließend den Kon- 

Flag in der trollfluss Kommunikations-Komponente in der beschriebenen Weise. und ruft anschließend die Planverbesserungs- 

Komponente auf (Zustand 3). Der Kontrollfluss geht nun ebenfalls auf diese Einheit über. Diese 

• Agenten-Kern Dienstleistung: Dient als Mittler zwischen den Planungskomponen- 

kann ebenso wie die anderen Planungskomponenten Leistungen des Agenten-Kerns in Anspruch 

ten und der Datenbank bzw. der Kommunikation. Durch diese Kapselung wird ein 

nehmen (Zustand direkter 4). Allerdings Zugriff durch kann die Planungskomponenten der Agenten-Kern die verhindert Arbeit dieser und derKomponente Kontrollfluss jederzeit 

unterbrechen, wenn eindeutig eine gehalten. neue Nachricht im Eingangs-Queue eingetroffen ist. 

Im „Dienstleistungs-“ Zustand 4 sorgt der Agenten-Kern für das Versenden neuer Nachrichten, 

durch Weiterleiten der Nachricht an die Kommunikations-Komponente. Oder er befriedigt die 

74 

Anfragen der Planungs-Komponenten bzgl. Informationen zu Plänen, Produkten, Maschinen, 

Kapazitäten oder Aufträgen. Hierzu übergibt er die notwendigen Informationen an die 

Datenbankschnittstelle. Diese sorgt für die Umsetzung der Anfragen an die konkrete Datenbank,


• Agenten-Kern Information: Speichert die für den Agenten primär relevanten Infor- 

mationen in einer statischen Klasse, z.B. den Namen des Agenten und Referenzen 

auf Kommunikations-Objekte und Datenbank. 

Eine Beschreibung der genauen Nachrichtenformate und Datenbankobjekte soll zu einem 

späteren Zeitpunkt erfolgen, da hier umfangreiche Änderungen und Erweiterungen erfor- 

derlich sind. 

4.3.5.4 Notwendige Änderungen 

Das von Bröske vorgestellte Konzept eines Frameworks für Planungsagenten wurde zwar 

mit dem Ziel entwickelt, Agenten für verteilte Ablaufplanung zu realisieren, allerdings 

gehen die Anforderungen des Supply Chain Scheduling über diese hinaus. Außerdem 

ist durch den beschränkten Zeitrahmen sicherlich eine Fokussierung auf ausgewählte 

Schwerpunkte erfolgt. 

Es ergibt sich daher Änderungs- und Erweiterungsbedarf. In diesem Abschnitt sollen zu- 

nächst die Aspekte genannt und dann in Abschnitt 4.3.6 beschrieben werden: 

• Datenschema: Das dem Framework zugrunde liegende Datenschema ist auf die An- 

forderungen der „klassischen“ verteilten Ablaufplanung zugeschnitten und beinhal- 

tet die dabei involvierten Entitäten, wie etwa Aufträge, Maschinen und Produkte 

mit ihrer Aufteilung in Zwischenprodukte. Für das Scheduling einer Supply Chain 

ist eine weitere Differenzierung notwendig. Produkte z.B. sollten nicht nur aus 

Produktionsschritten bestehen, sondern sich in Produktions-, Transport- und La- 

gerschritte aufteilen lassen. Dafür sind zusätzliche Entitäten erforderlich, etwa zur 

Abbildung von Transporteinheiten oder Lagern. 

• Nachrichten / Kommunikation: Die Agenten des Frameworks verwenden grund- 

sätzlich das Contract Net, um Aufträge an in der Hierarchie tiefer stehende Organi- 

sationseinheiten zu vergeben. Die benötigte Kommunikationsstruktur wird implizit 

aus der Produktionsstruktur ermittelt. Um für Teams von Agenten unterschiedliche 

Kommunikationsformen realisieren zu können, ist jedoch eine explizite Festlegung 

notwendig. 

Aus den notwendigen Änderungen am Datenschema ergibt sich ein erweiterter Um- 

fang der ausgetauschten Nachrichten. Für Transport- und Lagerschritte werden ent- 

sprechende Nachrichten benötigt, um anderen Agenten Statusänderungen, z.B. den 

Totalverlust eines Transports, mitteilen zu können. 

75

4 Entwurf 

• Konfigurierbarkeit: Das Framework ist dafür ausgelegt, einen individuellen Agen- 

ten zu erstellen. Werden mehrere Agenten benötigt, ist für jeden Agenten eine ge- 

sonderte Programmierung erforderlich. Im bisherigen Verlauf des Entwurfs hat sich 

gezeigt, dass für die Umsetzung der vollständigen Supply Chain über 40 Agenten 

benötigt werden, die z.T. stark unterschiedliche Eigenschaften aufweisen. Es er- 

scheint daher sinnvoll, das Framework um Möglichkeiten zur Konfigurierbarkeit zu 

erweitern. 

• Startumgebung: Jeder Agent des Frameworks arbeitet in einer eigenen, unabhän- 

gigen Laufzeitumgebung und muss separat gestartet werden. Für eine große Zahl 

von Agenten ist das wenig praktikabel, weshalb eine Startumgebung zur Verfügung 

gestellt werden sollte, die alle Agenten des Systems durch einen einzigen Aufruf 

initialisiert. 

In einer ersten Umsetzung könnte dies durch ein Skript auf Betriebssystem-Ebene 

geschehen. Eine optimale Lösung wäre es, die Agenten in einer gemeinsamen Lauf- 

zeitumgebung zu starten. Das könnte von einer übergeordneten Klasse realisiert 

werden, die für jeden Agenten die erforderlichen Parameter aus den in der Daten- 

bank enthaltenen Stammdaten einliest und anschließend einen individuellen Thread 

startet. 

Vorteil dieser Lösung wäre, dass der Ressourcenbedarf erheblich reduziert werden 

könnte, da ein Agent ca. 11 MB Arbeitsspeicher benötigt. Die Fähigkeit zur Vertei- 

lung der Agenten auf unterschiedliche Systeme sollte dabei erhalten bleiben. 

• Implementierung: Für das Framework liegt eine prototypische Implementierung 

vor. Daraus ergibt sich, dass nicht alles, was im Konzept vorgesehen ist, bereits 

umgesetzt ist. Einige Aspekte können vernachlässigt werden, z.B., dass die Kom- 

munikation nicht über RMI ausgeführt wird, sondern über die Datenbank erfolgt. 

An anderen Stellen ist jedoch eine Vervollständigung notwendig. 

Die genannten Gesichtspunkte zeigen, dass sich die erforderlichen Anpassungsarbeiten 

nicht auf die Hot Spots des Frameworks beschränken. Insbesondere die Änderungen des 

Datenschemas resultieren in der Notwendigkeit, auch die Frozen Spots des Frameworks 

entsprechend anzupassen. Davon sind nahezu alle Klassen des Systems betroffen. Weitere 

Erläuterungen sind in Abschnitt 5.2 zu finden. 

76

4.3.6 Ausgestaltung der Anforderungen 


Für die Ausgestaltung der Anforderungen müssen die in Abschnitt 4.2.2.6 genannten 

Punkte konkretisiert werden. Es handelt sich dabei um: 

• Datenschema, 

• Kommunikation und Nachrichten, 

• Algorithmen, 

• Stammdaten und Agentenkonfiguration, 

• Startumgebung. 

Die beiden zuletzt aufgeführten Punkte werden erst in Abschnitt 5.1.1 und Abschnitt 5.3.3 

betrachtet. 

4.3.6.1 Datenschema 

Grundlage des Gesamtsystems ist ein Datenschema, das über alle notwendigen Entitäten 

verfügt, um das Scheduling einer Supply Chain darauf abbilden zu können. Außerdem 

müssen Objekte für die Konfigurationsinformationen, z.B. über die Eigenschaften der 

Agenten, vorgesehen werden. Bei der Konzeption des Datenschemas wurde versucht, im 

Framework bereits vorhandene Bestandteile möglichst zu übernehmen, um den Ände- 

rungsaufwand zu minimieren. Priorisiert wurde allerdings der Anspruch, ein möglichst 

universelles Schema zu erstellen und aktuelle Entwicklungen der Arbeitsgruppe Pla- 

nungssysteme zu berücksichtigen. 

Abbildung 4.12 zeigt zunächst eine Übersicht aller Entitäten in einem ER-Diagramm 7 . 

Dabei werden die optionalen Datenfelder, deren Verwendung für das erweiterte Frame- 

work zunächst nicht vorgesehen ist, weggelassen. 

Die gezeigten Objekte sind in verschiedenen Gruppen zusammengefasst. Die Gruppe 

Agent wird ausschließlich für die Agentenkonfiguration benötigt. Die anderen Gruppen 

enthalten die Stammdaten des Systems, die später für die Planung verwendet werden. 

Diese werden von allen Agenten genutzt. Für die Anzeige eines Gantt-Charts ohne wei- 

tere Details wäre ein Zugriff auf die Gruppen Auftrag / Plan und Ressource ausreichend. 

7 ER = Entity Relationship 

77

4 Entwurf 

78 

Plan 

PK Plan 

PK Auftrag 

Ressource 

Status 

Startzeitpunkt 

Endzeitpunkt 

Belegung 

Startort 

Zielort 

Maschine 

PK Maschine 

Produkt 

PK Produkt 

Ressource 

PK Ressource 

Beschreibung 

Losgroesse 

Maschinentyp 

Intensitaet 

Naechster_Schritt 

PK Produkt 

PK Schritt 

PK Naechster_Schritt 

Ressourcentyp 

defekt_bis 

Standort 

Route 

PK Startort 

PK Zielort 

Dauer 

PK 

Schritt 

Produkt 

PK Schritt 

PK Schritttyp 

PK Ressource 

Transporter 

PK Transporter 

Transportertyp 

Zuladung 

Auftrag 

PK Auftrag 

PK Produkt 

Benoetigte_Kapazitaet 

Rohstoff 

Anzahl_Rohstoff 

Transportschritt 

PK Produkt 

PK Schritt 

Anzahl_TE 

Ressourcen_Verfuegbarkeit 

PK Ressource 

PK Beginn 

PK Ende 

Verfuegbarkeit 

Lager 

PK Lager 

Vater 

Auftragnehmer 

Menge 

Startzeitpunkt 

Endzeitpunkt 

bisher_produziert 

Startort 

Zielort 

Lagertyp 

Agent 

PK Agent 

Vater 

Team 

Algo 

Ressource 

Agent zu Kinder 

PK Vater 

PK Kind 

Auftrag / Plan 

Produkt 

Kommunikation 

Ressource Agent 

Abbildung 4.12: Datenschema des Multiagenten-Systems


Die Darstellung erfolgt aus der Sicht von Datenbanktabellen. Das Laufzeitsystem lädt 

benötigte Informationen zum Teil in dynamisch erzeugte Objekte, deren Aufbau sich ge- 

ringfügig unterscheiden kann. Auf signifikante Unterschiede wird hingewiesen. 

Jedes Datenobjekt wird mit einer Tabelle beschrieben. Neben den Daten selbst gibt diese 

auch Aufschluss über den jeweils zu verwendenden Datentyp, liefert eine kurze Beschrei- 

bung für jede Zeile und enthält Informationen darüber, welche Zeilen als optional zu 

betrachten sind. Bei Primärschlüsseln ist der Bezeichner kursiv dargestellt. 

Agent 

Agent CHAR 30 Name des Agenten 

Vater CHAR 30 Referenz auf den Vater-Agenten Opt. 

Team CHAR 30 Teamleiter von Opt. 

Algo CHAR 30 Planungsalgorithmus Opt. 

Ressource CHAR 30 Ressource, für die der Agent plant Opt. 

Tabelle 4.2: Daten eines Agenten 

Agent_zu_Kinder 

Vater CHAR 30 Name des Vater-Agenten 

Kind CHAR 30 Name des Kind-Agenten 

Kommunikation CHAR 30 Verwendete Kommunikationsform, 

entweder „ContractNet“ oder „Direkt“ 

Tabelle 4.3: Daten der Agent_zu_Kinder-Relation 

Die beiden Datensätze Agent und Agent_zu_Kinder (Tabellen 4.2, 4.3) enthalten alle In- 

formationen über die Agenten des Systems und ihre hierarchische Position. Durch die 

Möglichkeit, jedem Agenten einen Algorithmus mitzuteilen, den er zu verwenden hat, 

und die explizite Nennung der Kommunikationsform wird eine Konfigurierbarkeit des 

Systems erreicht. 

Durch Nutzung der beiden Parameter können unterschiedliche Planungssituationen auf 

mehrere Arten gelöst werden. Denkbar ist z.B., einen spezialisierten Algorithmus ein- 

zusetzen, dem Kommunikationspartner und -form bekannt sind, so dass auf den Eintrag 

Kommunikation verzichtet werden kann. Eine andere Variante wäre, einen universellen 

Algorithmus an mehreren Stellen des Planungssystems einsetzbar zu machen, indem die- 

ser die Information über seine Kommunikationspartner aus der Datenbank lädt. 

Opt. 

79

4 Entwurf 

Das Datenschema des Frameworks sah die Möglichkeit vor, einem Agenten mehrere Ma- 

schinen zuzuordnen, indem der Name des Agenten bei der Entität Maschine gespeichert 

wurde. Im Interesse der Normalisierung der Darstellung und im Hinblick auf die vor- 

gestellte Vorgehensweise für die Zuordnung von Agenten zu Organisationseinheiten soll 

dieser Ansatz allerdings nicht weiter verfolgt werden. 

Während der Laufzeit des Systems werden für die Vater-Kind-Beziehungen Listen er- 

zeugt, die leichter zu handhaben sind. 

Der Plan (Tabelle 4.4) speichert alle geplanten Aktivitäten. Start- und Endzeitpunkt müs- 

sen sich dabei innerhalb der Grenzen der für den zugehörigen Auftrag vorgesehenen frü- 

hesten Start- und spätesten Endzeit bewegen. Die Belegung drückt aus, wieviel der Ka- 

pazität der eingeplanten Ressource durch die Aktivität belegt wird. Ggfs. können, sofern 

die Ressource nicht exklusiv ist, weitere Aufträge auf dieser eingeplant werden. 

Plan 

Plan CHAR 30 Name des Plans 

Auftrag CHAR 30 Referenz auf den Auftrag 

Ressource CHAR 30 Referenz auf verwendete Ressource Opt. 

Status CHAR 10 Statusbeschreibung Opt. 

Startzeitpunkt NUMBER Beginn des Planschritts Opt. 

Endzeitpunkt NUMBER Ende des Planschritts Opt. 

Belegung NUMBER Prozentuale Belegung Opt. 

Produkt CHAR 30 Referenz auf Produkt Opt. 

Schritt CHAR 30 Referenz auf Schritt Opt. 

Startort CHAR 30 Startort bei Transporten Opt. 

Zielort CHAR 30 Zielort bei Transporten Opt. 

Tabelle 4.4: Daten eines Planschritts 

Das Statusfeld beschreibt analog zu Bröske und einer Idee von Freese ([Fre98]), in wel- 

chem seiner möglichen Zustände sich ein Auftrag gerade befindet: 

80 

• Reserviert: Der Bieter hat im Rahmen einer Contract Net Versteigerung die Res- 

sourcen reserviert. Bei tatsächlicher Auftragserteilung wechselt der Status in Ein- 

zuplanen, ansonsten wird der Auftrag wieder gelöscht. Reservierte Ressourcen wer- 

den bei Planänderungen genauso behandelt wie einzuplanende oder eingeplante 

Ressourcen. Dadurch wird gewährleistet, dass der Agent nach Abschluss einer Ver- 

steigerung auch zur Ausführung des Auftrags in der Lage ist.


• Einzuplanen: Der Auftrag wurde nur in den Plan eingetragen, allerdings sind noch 

keine Folgeaufträge an untergeordnete Agenten vergeben worden. 

• Eingeplant: Der Auftrag und alle Folgeaufträge sind eingeplant, d.h., alle Contract 

Net Versteigerungen für die Teilaufträge sind erfolgreich abgeschlossen. 

• Laufend: Die Produktion des Auftrags hat bereits begonnen, Änderungen sind daher 

nur schwerlich möglich. 

• Fest eingeplant: Aufträge mit diesem Status wurden manuell vom Benutzer einge- 

plant und sollten vom System nicht ohne Rückfrage verändert werden. 

• Abgeschlossen: Nach Produktion aller zugehörigen Teilaufträge wird ein Auftrag 

als abgeschlossen markiert. 

Ein Plan wird im Laufzeit-System durch zwei Klassen repräsentiert. Das Objekt Plan hat 

dabei die Aufgabe, die Planschritt-Objekte zu verwalten. Eine beliebige Anzahl dieser 

Planschritt-Objekte speichert die Informationen zu den einzelnen Planabschnitten. 

Beim Auftrag (Tabelle 4.5) wird das Feld Auftragnehmer für den Agenten verwendet, der 

den Auftrag erhalten hat. Ein frühestmöglicher Auftragsbeginn, der auf null gesetzt ist, 

symbolisiert, dass die Planung hier keinen Restriktionen unterliegt. Viele der optionalen 

Felder bleiben zunächst unberücksichtigt, sind aus Gründen der Erweiterbarkeit aber be- 

reits vorgesehen. 

Die Entitäten Produkt, Schritt, Transportschritt und Naechster_Schritt (Tabellen 4.6, 4.7, 

4.8, 4.9) bilden die Produktionsvorschrift für die einzelnen Produkte. In der Tabelle Pro- 

dukt selbst findet sich lediglich eine Beschreibung und eine optional zu nennende optimale 

Losgröße. 

Entgegen dem ursprünglichen Framework wurde hier eine Differenzierung der Schritte 

in Produktions-, Transport- und Lagerschritte vorgenommen. Die Tabelle Schritt liefert 

Detailsinformationen, die bei Transportschritten noch um die aus der Tabelle Transport- 

schritt zu ergänzen sind. Analog zum Framework muss der erste Schritt einer Produkti- 

onsvorschrift immer mit der Zahl „1“ beginnen, die weitere Reihenfolge kann dann belie- 

big gewählt werden und wird durch die Verkettung mittels der Tabelle Naechster_Schritt 

eindeutig festgelegt. Im System wird die Produktionsvorschrift durch ein Produkt-Objekt, 

sowie eine verkettete Liste von Schritt-Objekten repräsentiert. 

81

4 Entwurf 

Auftrag 

Auftrag CHAR 30 Names des Auftrags 

Produkt CHAR 30 zugehöriges Produkt 

Vater CHAR 30 übergeordneter Auftrag Opt. 

Auftragspool CHAR 10 zugehörige Auftragsmenge Opt. 

Prioritaet NUMBER Priorität des Auftrags Opt. 

Auftraggeber CHAR 30 Name des Auftraggebers Opt. 

Auftragnehmer CHAR 30 Name des Auftragnehmers Opt. 

Menge NUMBER Menge des Auftrags 

Startort CHAR 30 Starort bei Transportaufträgen Opt. 

Zielort CHAR 30 Zielort bei Transportaufträgen Opt. 

Startzeitpunkt NUMBER Frühestmöglicher Beginn 

Endzeitpunkt NUMBER Spätestmögliches Produktions- 

ende / Lieferung 

Vorgeplante_Ressource CHAR 30 Referenz auf eine vorgeplante 

Ressource 

Verspaetung NUMBER Gesamt-Verspätung des Auf- 

trags 

Opt. 

Opt. 

Verzug NUMBER Gesamt-Verzug des Auftrags Opt. 

bisher_gefertigt NUMBER Bisher produzierte / gelieferte / 

Tabelle 4.5: Daten eines Auftrags 

Produkt 

Produkt CHAR 30 Name des Produktes 

gelagerte Menge des Auftrags 

Opt. 

Beschreibung CHAR 30 Bescheibung Opt. 

Losgroesse NUMBER Menge pro Durchlauf Opt. 

Tabelle 4.6: Daten eines Produkts 

Ressource und Ressourcen_Verfuegbarkeit (Tabellen 4.10, 4.11) definieren ganz allge- 

mein die für Produktion, Transporte und Lagerung benötigten Ressourcen, sowie deren 

Verfügbarkeiten. Eine Differenzierung im Datenschema kann somit wie gewünscht er- 

reicht werden. 

Die Tabellen Maschine, Transporter und Lager (Tabelle 4.12, 4.13, 4.14) beschreiben die 

individuellen Eigenschaften der jeweiligen Ressourcen. 

82


Schritt 

Produkt CHAR 30 Name des Produkts, zu dem der 

Schritt gehört 

Schritt CHAR 30 Name des Schritts 

Schritttyp CHAR 30 Typ-Beschreibung, entweder 

Transportschritt, Lagerschritt 

oder Produktionsschritt 

Ressource CHAR 30 Referenz auf die Ressource, 

wird benötigt, um mehrere Res- 

sourcen als Alternativen aus- 

wählen zu können 

Relativer_Beginn NUMBER Relativer Startzeitpunkt Opt. 

Dauer NUMBER Länge des Schrittes Opt. 

Benoetigte_Kapazitaet NUMBER prozentuale Angabe über die be- 

nötigte Auslastung der Ressour- 

ce (100% �= exklusiv) 

Opt. 

Rohstoff CHAR 30 Benötigter Rohstoff Opt. 

Anzahl_Rohstoff NUMBER Anzahl Rohstoff Opt. 

Tabelle 4.7: Daten eines Schrittes 

Transportschritt 

Produkt CHAR 30 Name des Produkts, zu dem der Schritt 

gehört 

Schritt CHAR 30 Name des zugehörigen Schrittes 

Anzahl_TE NUMBER Anzahl der zu transportierenden 

Transporteinheiten (TE) 

Tabelle 4.8: Daten eines Transportschrittes 

Naechster_Schritt 

Produkt CHAR 30 Name des Produkts, zu dem der Schritt 

gehört 

Schritt CHAR 30 Name des zugehörigen Schrittes 

Naechster_Schritt CHAR 30 Name des nächsten Schrittes 

Tabelle 4.9: Daten für die Nachfolgerbeziehung zwischen den 

Schritten 

Opt. 

83

4 Entwurf 

Ressource 

Ressource CHAR 30 Name der Ressource 

Ressourcentyp CHAR 30 Typ-Beschreibung der Ressource, ein- 

deutige Namenszuweisung zu Maschi- 

ne, Transporter oder Lager 

Kapazitaet NUMBER Ressourcenkapazität 

defekt_bis NUMBER Defektinformation Opt. 

Standort CHAR 30 Standort der Ressource Opt. 

Tabelle 4.10: Daten einer Ressource 

Ressourcen_Verfuegbarkeit 

Ressource CHAR 30 Referenz auf die Ressource 

Beginn NUMBER Startzeitpunkt 

Ende NUMBER Endzeitpunkt 

Verfuegbarkeit NUMBER Anteil in Prozent, zu wieviel die Res- 

source ausgelastet werden kann 

Tabelle 4.11: Daten der Ressourcenverfügbarkeit 

Maschine 

Maschine CHAR 30 Name der Maschine, muss mit dem 

Ressourcennamen übereinstimmen 

Opt. 

Maschinentyp CHAR 30 Typ der Maschine Opt. 

Intensitaet NUMBER Auslastung der Maschine Opt. 

Tabelle 4.12: Daten einer Maschine 

Eine Maschine kann dabei nicht nur eine einzelne, konkret vorhandene Maschine abbil- 

den, sondern für eine Maschinengruppe stehen. Die benötigte Größe der maximalen Ka- 

pazität wird nicht direkt als Feld abgelegt, da diese laufzeitabhängig ist. Sie kann jedoch 

wie folgt berechnet werden: 

MaxKapazitaet = Intensitaet ∗ Lau f zeit 

Die Transporteinheiten (TE) eines Transporters korrespondieren mit denen, die bereits 

bei den Transportschritten genannt wurden. Für eine erste Näherung sollte diese Dar- 

stellung ausreichen, für eine universelle Transportplanung wird allerdings eine weitere 

Differenzierung benötigt. 

84


Transporter 

Transporter CHAR 30 Name des Transporters, muss 

mit dem Ressourcennamen über- 

einstimmen 

Transportertyp CHAR 30 Typ-Beschreibung Opt. 

Zuladung NUMBER Maximale Ladekapazität in 

Transporteinheiten (TE) 

Kosten_pro_km NUMBER Kosten pro km (Kraftstoff, Steu- 

ern, Wartung) 

Opt. 

Opt. 

Startort CHAR 30 Referenz auf den Startort Opt. 

Laufzeit_Beginn NUMBER Laufzeitbeginn des Transporters Opt. 

Laufzeit_Ende NUMBER Laufzeitende des Transporters Opt. 

Tabelle 4.13: Daten eines Transporters 

Lager 

Lager CHAR 30 Name des Lagers, muss mit dem Res- 

sourcennamen übereinstimmen 

Lagertyp CHAR 30 Lagertyp Opt. 

Tabelle 4.14: Daten eines Lagers 

Es könnte beispielsweise in Maße, Gewichte und Stoffklassen unterschieden werden und 

eine Zuordnung verschiedenartiger Container sowohl zu Fahrzeugen bzw. Transportern 

als auch zu Produkten erfolgen. In diesem Schema ist für einen Transportschritt vorab zu 

berechnen, wieviele Transporteinheiten er benötigt. 

Route 

Route CHAR 30 Name der Route 

Startort CHAR 30 Refenrenz auf den Startort 

Zielort CHAR 30 Referenz auf den Zielort 

Entfernung NUMBER Länge der Route in km Opt. 

Dauer NUMBER Fahrtdauer Opt. 

Tabelle 4.15: Daten einer Route 

Die Route (Tabelle 4.15) ist ein weiteres Konstrukt für die Planung der Transporte. Je 

nach Zweckmäßigkeit kann entweder eine Streckenlänge oder eine Zeitdauer angegeben 

werden. 

85

4 Entwurf 

4.3.6.2 Kommunikation und Nachrichten 

Die für Teams von Agenten relevante Unterscheidung in eine Auftragsvergabe durch das 

Contract Net Protokoll und eine direkte Kommunikation ist durch die explizite Berück- 

sichtigung im Datenschema bereits erleichtert worden. Planungsalgorithmen haben die 

Möglichkeit, beide Verfahren einzusetzen und so die Planungssituationen der Realwelt 

besser abzubilden. 

Eine Erweiterung der im Framework bereits vorgesehenen Nachrichtentypen ist ebenfalls 

von Bedeutung. Bei Nachrichten handelt es sich zunächst um einfache Datenobjekte, de- 

ren Aufbau sich an KQML (siehe Abschnitt 2.3.3.3) orientiert. Tabelle 4.16 beschreibt 

die vorgesehenen Nachrichten. Die Ontologie wird in der erweiterten Version des Frame- 

works dazu verwendet, den Typ zu identifizieren. 

86 

Tabelle 4.16: Ontologie und Inhalt der KQML-Nachrichten 

Nachrichtentyp & Ontologie KQML Inhaltsfeld (content) 

Neuer Auftrag Auftrag: [String] 

(NeuerAuftrag) Produkt: [String] 

Anzahl: [Integer] 

Start: [Integer] 

Ende: [Integer] 

Stornierung eines Auftrags Auftrag: [String] 

(Stornierung) 

Terminänderung für einen Auftrag Auftrag: [String] 

(Terminaenderung) Produkt: [String] 



Änderung der Auftragsmenge Auftrag: [String] 

(Mengenaenderung) Produkt: [String] 


Fortsetzung auf der nächsten Seite



Fortsetzung von vorheriger Seite 


Neue Contract Net Versteigerung Versteigerung: [Integer] 

(NeueContractNetVersteigerung) Auftrag: [String] 

Produkt: [String] 




Contract Net initiieren Auftrag: [String] 

(ContractNetInit) Versteigerung: [Integer] 

Anzahl_Auftraege: 

[Integer] 

Auftrag ausschreiben Versteigerung: [Integer] 

(AuftragAusschreiben) Auftrag: [String] 

Produkt: [String] 




Gebot abgeben Versteigerung: [Integer] 

(GebotAbgeben) Auftrag: [String] 

Gebot: [Integer] 

Gebot ablehnen Versteigerung: [Integer] 

(GebotAblehnen) Auftrag: [String] 

Störung einer Maschine Maschine: [String] 

(MaschineStoerung) von: [String] 

bis: [String] 

Reparatur einer Maschine Maschine: [String] 

(MaschineReparatur) 

Wartungsperiode einfügen Start: [Integer] 

(NeueWartung) Ende: [Integer] 

Maschinenintensität ändern Maschine: [String] 

(NeueIntensitaet) Intensitaet: [Integer] 

Fortsetzung auf der nächsten Seite 

87

4 Entwurf 

88 




Schichtzahl ändern, d.h. Änderung Maschine: [String] 

der Laufzeit Laufzeit: [Integer] 

(NeueLaufzeit) 

Rückmeldung von Maschinen- Maschine: [String] 

bzw. Fertigungsdaten Zeitraum_Start: [Integer] 

(MaschineRueckmeldung) Zeitraum_Ende: [Integer] 

produziert: [Integer] 

Kapazitätsanfrage Start: [Integer] 

(Kapazitaetsanfrage) Ende: [Integer] 

Rückmeldung von Plandaten Für jeden Planeintrag wird ein String 

mit den nachfolgend genannten Infor- 

mationen zurückgeliefert. Die einzel- 

nen Einträge sind durch Tabs (Java Ho- 

rizontal Tab: \t) getrennt. 

(Rueckmeldung) Auftrag: [String] 

Maschine: [String] 

Status: [String] 



Belegung: [Integer] 

Störung Auftrag: [String]} 

(Stoerung) Maschine: [String] 

Agent herunterfahren 

(AgentShutDown) 

Agent: Prädiktiv neu planen Zeitraum_Start: [Integer] 

(AgentPredSched) Zeitraum_Ende: [Integer] 

Totalverlust eines Transports Transporter: [String] 

(TransportVerlust) Auftrag: [String] 

Verzögerung eines Transports Transporter: [String] 

(TransportVerzoegerung) Auftrag: [String] 

bis: [Integer] 

Fortsetzung auf der nächsten Seite





Verfügbarkeitsanfrage im Lager Produkt: [String] 

(LagerVerfuegbarkeit) Anzahl: [Integer] 

Lager: [String] 

Zeitraum_Start: [Integer] 

Zeitraum_Ende: [Integer] 

Platzanfrage im Lager Lager: [String] 

(LagerPlatzanfrage) Produkt: [String] 




Verfügbarkeitsrückmeldung vom Lager Produkt: [String] 

(LagerMeldVerfuegbarkeit) Anzahl: [Integer] 

Lager: [String] 



Platzmeldung vom Lager Lager: [String] 

(LagerMeldPlatz) Produkt: [String] 

4.3.6.3 Algorithmen 




Ein zentrales Element für die Arbeit der Agenten sind Algorithmen, deren Aufgabe es 

ist, die Ablaufplanungsprobleme zu bearbeiten. Aus der Klassifizierung der Agenten ist 

ersichtlich, dass sich diese Probleme höchst unterschiedlich gestalten und daher individu- 

elle Planungsalgorithmen an den einzelnen Stellen des Systems benötigt werden. 

Darüber hinaus wird jeder der Agenten mit unterschiedlichen Planungssituationen kon- 

frontiert. Im „einfachsten“ Fall ist nur ein prädiktiver Plan für eine Menge von Aufträgen 

zu erstellen. Andere Situationen erfordern dagegen Algorithmen, die in der Lage sind, 

einzelne neue Aufträge in bestehende Pläne zu integrieren. Um an einer Contract Net 

Versteigerung teilnehmen zu können, benötigt der Agent einen Algorithmus, der prüft, ob 

eine Teilnahme sinnvoll möglich ist, und daraufhin ein geeignetes Angebot erstellt. 

89

4 Entwurf 

Eine Integration der Algorithmen in das Framework erfolgt durch die Erstellung von 

Planungskomponenten für spezifische Situationen. Beim Auftreten von Ereignissen, z.B. 

durch das Eintreffen der Nachricht Störung einer Maschine, wird vom Agenten-Kern die 

zuständige Komponente aktiviert und der dafür vorgesehene Algorithmus gestartet. Das 

Framework wird dahingehend erweitert, dass in den Daten der Agentenkonfiguration ein 

Feld Algo vorgesehen wird, welches eine Differenzierung ermöglicht, die nicht mehr nur 

von empfangenen Nachrichten abhängt. 

Für die Realisierung der Algorithmen werden heuristische Verfahren benötigt, da die 

Komplexität naiver Lösungsansätze zu hoch (NP-vollständig) ist. In Abhängigkeit von 

der Strategie, die der Agent zu verfolgen hat, sind unterschiedliche Heuristiken verwend- 

bar. Sauer ([Sau01d]) beschreibt diverse. Teile der Kommunikations- und Teamstruktur 

sind ebenfalls in den Algorithmen enthalten, da eine Auflösung allein durch ein geeigne- 

tes Datenschema nicht immer möglich bzw. sinnvoll ist. Insbesondere der Algorithmus 

für den Toplevel-Agenten muss „wissen“, dass er Transportaufträge gebündelt an einen 

untergeordneten Agenten zu übergeben hat. Einige der benötigten Algorithmen werden 

exemplarisch in Form von Pseudo-Code vorgestellt. 

Agent PA1, der den Bund repräsentiert und den fokalen Kopf der Supply Chain bildet, 

hat die umfangreichsten Aufgaben zu übernehmen. Daher soll zuerst ein Algorithmus be- 

schrieben werden, der diesem Agenten die Einplanung vorhandener Aufträge ermöglicht 

(Abbildung 4.13). Ergebnis ist ein prädiktiver Grobplan für in der Hierarchie tiefer ste- 

hende Agenten. 

Der Algorithmus bearbeitet alle aktuell noch nicht eingeplanten Aufträge. Dazu ermit- 

telt er zunächst für jeden Auftrag das zu fertigende Produkt mit seinen Produktions-, 

Transport- und Lagerschritten. 

Die Produktionsschritte enthalten Angaben über Zwischenprodukte, für die in der Daten- 

bank vermerkt ist, welche Maschinengruppen (Rondenhersteller, Prägeanstalten) zu deren 

Fertigung in der Lage sind. Für jeden Produktionsschritt kann so die benötigte Menge an 

Zwischenprodukten berechnet und unter den zuständigen Agenten versteigert werden. 

Durch die Konfliktbearbeitung wird erreicht, dass Auftragsmengen, die aufgrund ihrer 

Größe keinen Abnehmer bei der Versteigerung gefunden haben, in kleineren Tranchen 

erneut angeboten werden. 

90

while A u f t r a e g e zu p l a n e n do 

Waehle A u f t r a g ; 


E r m i t t l e h e r z u s t e l l e n d e _ M u e n z e f u e r A u f t r a g ; 

E r m i t t l e P r o d u k t i o n s S c h r i t t e 

f u e r h e r z u s t e l l e n d e _ M u e n z e ; 

E r m i t t l e T r a n s p o r t S c h r i t t e 


E r m i t t l e L a g e r S c h r i t t e 


while P r o d u k t i o n s S c h r i t t e zu p l a n e n do 

Waehle P r o d u k t i o n s S c h r i t t ; 

Berechne e r f o r d e r l i c h e _ M e n g e ; 

E r m i t t l e g e e i g n e t e R e s s o u r c e n und 

d a f u e r v e r a n t w o r t l i c h e Agenten ; 

Fuehre V e r s t e i g e r u n g durch 

o der l o e s e K o n f l i k t ; 

end while ; 

Berechne T r a n s p o r t A u f t r a e g e 

aus T a n s p o r t S c h r i t t e n und 

Auftragsmenge ; 

Sende T r a n s p o r t A u f t r a e g e an 

v e r a n t w o r t l i c h e n Agenten ; 

B e a r b e i t e e v t l . K o n f l i k t ; 

Berechne zu l a g e r n d e Gesamtmenge 

an Muenzen aus L a g e r S c h r i t t e n und 

Auftragsmenge ; 

Erzeuge nach f e s t e m V e r t e i l s c h l u e s s e l 

L a g e r A u f t r a e g e aus L a g e r S c h r i t t e n ; 

Sende L a g e r A u f t r a e g e an v e r a n t w o r t l i c h e 

Agenten ; 

B e a r b e i t e e v t l . K o n f l i k t ; 

end while ; 

Abbildung 4.13: Pseudocode für den prädiktiven Toplevel- 

Algorithmus 

91

4 Entwurf 

Eine alternative Variante des Algorithmus könnte vorsehen, die Aufträge für die Prägean- 

stalten nicht zu versteigern, sondern nach einem festen Schlüssel zu verteilen. Hierdurch 

könnten in der Realwelt möglicherweise vorhandene und evtl. historisch begründete Ka- 

pazitätszuweisungen umgesetzt werden. 

Für alle in der jeweiligen Produktbeschreibung enthaltenen Transportschritte ist in der 

Datenbank nur eine geeignete Ressource eingetragen: Der fokale Kopf der Sicherheits- 

transportunternehmen, Agent PA1.2. Daher werden die aus Transportschritten und Auf- 

tragsmenge ermittelten Transportaufträge komplett an diesen Agenten weitergeleitet. 

Dabei wird über geeignete Stammdaten gewährleistet, dass die Kapazitäten für Sicher- 

heitstransporte mindestens genauso groß sind wie die Produktionskapazitäten. Eine Kon- 

fliktbearbeitung bei Auftragsablehnung durch den fokalen Kopf der Sicherheitstransport- 

unternehmen wird daher nur bei Störungen auf Seiten der einzelnen Transportunterneh- 

men erforderlich. 

Analog zu den Transporten werden die Lageraufträge berechnet. Da eine bedarfsorientier- 

te Verteilung der fertigen Münzen auf einzelne Bundesländer gewünscht ist, erfolgt keine 

Versteigerung unter den verantwortlichen Agenten, sondern eine Zuteilung nach einem 

festen Verteilschlüssel. Eine Konfliktbehandlung fängt evtl. auftretende Lagerplatzpro- 

bleme ab, z.B., wenn Kapazitäten durch Brand o.ä. nicht verfügbar oder länger belegt 

sind, als dies ursprünglich vorgesehen war. Alternativ ist vorgesehen, den Auftrag mit ei- 

nem Zielort zu versehen. 

Der Algorithmus zeigt, dass der Toplevel-Agent zwar unterschiedliche Aufgaben bearbei- 

ten muss, aufgrund der hierarchischen Organisation in Teams aber deutlich entlastet wird. 

Die Planung der Transporte wird komplett an ein anderes Team delegiert, die Produkti- 

onsplanung erfolgt lediglich in grober Form und wird erst durch die für die Feinplanung 

verantwortlichen Teams genauer aufgelöst. 

Abbildung 4.14 beschreibt einen prädiktiven Algorithmus, der für die Teams bei der Pro- 

duktion von Ronden oder der Prägung von Münzen eingesetzt werden kann. Dazu werden 

die in den erhaltenen Aufträgen genannten Produkte in Zwischenprodukte zerlegt und an- 

schließend unter jenen Agenten versteigert, welche einzelne Produktionsabteilungen und 

damit Maschinengruppen repräsentieren. Im Konfliktfall erfolgt wieder eine Zerlegung in 

kleinere Auftragsmengen, um Gebote bei der Versteigerung zu erhalten. 

92



E r m i t t l e h e r z u s t e l l e n d e s _ P r o d u k t f u e r A u f t r a g ; 

E r m i t t l e P r o d u k t i o n s S c h r i t t e 

f u e r h e r z u s t e l l e n d e s _ P r o d u k t ; 

while P r o d u k t i o n s S c h r i t t e zu p l a n e n do 

Waehle P r o d u k t i o n s S c h r i t t ; 

Berechne e r f o r d e r l i c h e _ M e n g e ; 

E r m i t t l e g e e i g n e t e R e s s o u r c e n und 

d a f u e r v e r a n t w o r t l i c h e Agenten ; 

Fuehre V e r s t e i g e r u n g durch 

o der l o e s e K o n f l i k t ; 

end while ; 

end while ; 

Abbildung 4.14: Pseudocode für die prädiktive Planung der 

Teams bei Rondenproduktion und Münzprägung 

In dem hier betrachteten Szenario sind für die einzelnen Stationen der Ronden- und Münz- 

produktion keine alternativen Maschinengruppen vorgesehen, die Kommunikation könnte 

sich daher auf eine direkte Auftragszuteilung beschränken und ohne Versteigerung – mit 

nur einem potenziellen Bieter – auskommen. Im Interesse der universellen Einsetzbarkeit 

des Algorithmus für leitende Agenten, deren Aufgabe es ist, Produkte in Zwischenpro- 

dukte zu zerlegen und an Agenten für Maschinengruppen zu verteilen, erfolgte allerdings 

die variablere Form der Konzeptionierung. 

Ein weiterer, interessanter Algorithmus wird für die Umsetzung der Transportplanung 

benötigt (Abbildung 4.15). Er bearbeitet für Agent PA1.2 die vom Bund erhaltenen Trans- 

portaufträge und nimmt dabei einige Optimierungen vor, um die anderen Mitglieder des 

Teams mit möglichst gut aufgeteilten Transportaufträgen zu versorgen. 

Zunächst wird für jeden erhaltenen Transportauftrag anhand der Auftrags- und Produkt- 

daten ermittelt, welche Menge es auf welcher Route zu transportieren gilt, und wie die 

zeitlichen Vorgaben dafür aussehen. Die Ergebnisse werden in eine Gesamtliste eingetra- 

gen, die alle noch nicht an einzelne Transportunternehmen versteigerten Aufträge enthält. 

93

4 Entwurf 

T r a n s p o r t e : = {} ; 


Waehle A u f t r a g ; 

E r m i t t l e z u _ t r a n s p o r t i e r e n d e s _ P r o d u k t f u e r A u f t r a g ; 

E r m i t t l e T r a n s p o r t S c h r i t t 

f u e r z u _ t r a n s p o r t i e r e n d e s _ P r o d u k t 

und a k t u e l l e n A u f t r a g ; 

T r a n s p o r t e : = T r a n s p o r t e ∪ T r a n s p o r t S c h r i t t ; 

end while ; 

S o r t i e r e T r a n s p o r t e nach Route ; 

S o r t i e r e T r a n s p o r t e nach Z e i t i n t e r v a l l ; 

G r u p p i e r e T r a n s p o r t e nach TE−Zahlen um ; 

Erzeuge T r a n s p o r t A u f t r a e g e 

aus T a n s p o r t e ; 

V e r s t e i g e r e T r a n s p o r t A u f t r a e g e an 

v e r a n t w o r t l i c h e Agenten oder 

l o e s e K o n f l i k t ; 

Abbildung 4.15: Pseudocode für die Optimierung und prädiktive 

Planung der Sicherheitstransporte 

Anschließend wird diese Liste nach Routen und Zeitintervallen sortiert, wobei nach Be- 

darf eine Anpassung der Intervallgrenzen erfolgen kann, sofern dabei keine Verletzung 

der Vorgaben erfolgt. Die so bearbeitete Liste ermöglicht es, mittels der Kapazitätsinfor- 

mationen der im Team arbeitenden Sicherheitstransportunternehmen eine Umgruppierung 

bzw. Zusammenfassung von Einzeltransporten vorzunehmen. 

Dafür wird eine bestimmte Kapazität an Transporteinheiten (TE) pro Fahrzeug und Route 

vorausgesetzt und versucht, einzelne Transporter möglichst voll auszulasten und so eine 

Beschränkung der erforderlichen Fahrten zu erreichen. Weiteres Optimierungspotenzial 

besteht in einer intelligenten Berücksichtigung der erforderlichen Rückfahrten der Fahr- 

zeuge. Auch eine Sammlung der vom Bund hoffentlich frühzeitig erhaltenen Aufträge zur 

Bildung eines größeren Pools erscheint sinnvoll. 

94


Neben den vorgestellten Beispielen werden für die Realisierung des Systems noch weitere 

Algorithmen benötigt. Dazu gehören auch reaktive Algorithmen, etwa für die Anpassung 

des Plans nach dem Ausfall einer Maschine. Eine interaktive Planung erfordert Algorith- 

men für eine Überprüfung der vom Benutzer durchgeführten Änderungen auf Konsistenz. 

4.3.6.4 Umsetzung der Agenten 

Das Ziel bei der Ausgestaltung der Anforderungen ist es, alle wichtigen Konzepte und 

Methoden bereitzustellen, die benötigt werden, um den ermittelten Anforderungen des 

Szenarios gerecht werden zu können. Um zu gewährleisten, dass dieses auch geschehen 

ist, soll abschließend am Beispiel des den Bund repräsentierenden Agenten (PA 1) gezeigt 

werden, wie dieser umgesetzt werden kann. 

Die Einordnung des Agenten in die Gesamthierarchie des Systems und die Abbildung der 

dafür notwendigen Beziehungen zu anderen Agenten kann mit dem vorgestellten Daten- 

schema erreicht werden. Dort können auch die Verantwortung für einzelne Ressourcen 

und gewünschte Kommunikationsformen festgelegt werden. 

Die unterschiedlichen Kommunikationsformen sind mit dem Contract Net Protokoll und 

der Nachrichtenverarbeitung des Frameworks realisierbar, der erweiterte Umfang der un- 

terstützten Nachrichten berücksichtigt die neuen Anforderungen im Bereich Transport 

und Lager. 

Für die Realisierung von Planungsaufgaben und -strategie wurde ein geeigneter Algorith- 

mus entwickelt, der sein erforderliches Planungswissen zum Teil inhärent selbst bereit- 

stellt und für Produkt-, Ressourcen- und Auftragsdaten auf die entsprechenden Entitäten 

des Datenschemas zugrückgreifen kann. 

Andere Agenten können analog umgesetzt werden. 

4.3.7 Integration des Systems 

Nachdem die konzeptionellen Entscheidungen getroffen worden sind und die zu verwen- 

dende Agentenplattform mit den notwendigen Änderungen beschrieben worden ist, kann 

jetzt die Integration des Systems erfolgen. Dazu werden folgende Arbeiten durchgeführt: 

• Datenbank: Die Skripte zum Erzeugen der benötigten Datentabellen werden gene- 

riert und die Datenbank erzeugt. 

95

4 Entwurf 

• Anpassung des Frameworks: Das Framework wird an die neuen Anforderungen 

angepasst, z.B. wird die Datenbank für das neue Datenschema adaptiert. 

• Restliche Implementierung: Die Planungsalgorithmen werden umgesetzt und in das 

Framework integriert. Die Startumgebung wird erstellt. 

Besonderheiten und Details der Integration werden in Kapitel 5 beschrieben. 

4.3.8 Test und Verifikation 

Damit gewährleistet ist, dass sich das erstellte Planungssystem erwartungskonform ver- 

hält, werden im Rahmen der Implementierung geeignete Testdaten erstellt (Abschnitt 

5.1). Eine über dieses „naive“ Verfahren hinausgehende Verifikation soll zunächst nicht 

erfolgen. 

96

5 Implementierung 

Ziel dieser Diplomarbeit ist es, Konzepte für Ablaufplanung mit Teams von Agenten 

zu entwickeln, und dabei die notwendigen Tätigkeiten bis hin zu einer prototypischen 

Umsetzung zu beschreiben. Dieses Kapitel beschäftigt sich mit der Implementierung 

des Multiagenten-Systems, die sich auf das Framework für Planungsagenten von Brös- 

ke gründet ([Bro01]), das in Abschnitt 4.3.5 vorgestellt wurde. 

Dort wurde deutlich, dass umfangreiche Änderungen und Erweiterungen vorzunehmen 

sind, um das Framework für den erweiterten Aufgabenbereich einsetzen zu können. Im 

direkten Vergleich zu einem komplett eigenständigen Design erscheint dieser Aufwand 

allerdings gerechtfertigt. 

Die abgeschlossene Entwurfsphase hat bereits umfangreiche und detaillierte Beschrei- 

bungen dafür geliefert, wie das zu implementierende System umzusetzen ist. Die Erläu- 

terungen in diesem Kapitel beschränken sich daher auf exemplarische Ausschnitte und 

Besonderheiten, z.B. die Startumgebung für die unterschiedlichen Agenten. 

5.1 Stamm- und Testdaten 

5.1.1 Stammdaten 

Grundlage für ein konkretes Ablaufplanungssystem bilden die Stammdaten, die inner- 

halb des entwickelten Datenschemas die Realwelt mit ihren Produkten, Ressourcen und 

Constraints modellieren. Das Datenschema selbst wurde in Abschnitt 4.3.6.1 eingeführt. 

Mittels einiger Tabellen soll gezeigt werden, wie Entitäten des Szenarios in der realisier- 

ten SQL-Datenbank einzuordnen sind. Als Relationales Datenbankmanagementsystem 

(RDBMS) wird für diese Arbeit MySQL verwendet, das für alle relevanten Betriebssys- 

tem-Plattformen verfügbar ist. 

Abbildung 5.1 zeigt die Produktionsvorschrift für die Herstellung einer Euro-Münze, die 

als Grundlage für die Beschreibung nachfolgender Tabellen dienen soll. Erkennbar ist, 

97


dass eine Euro-Münze zunächst aus zwei Produktions-, zwei Transport- und einem La- 

gerschritt besteht. Der erste Produktionsschritt sieht dabei die Bereitstellung eines Zwi- 

schenprodukts, einer Euro-Ronde, vor. 

Münze 1 Euro 

Ronde 1 Euro Transport 1 Euro Prägung 1 Euro Transport 1 Euro Lagerung 1 Euro 

Produktionsschritt Transportschritt Produktionsschritt Transportschritt Lagerschritt 

Ronde fertigen Ronden -> Münze Münze ausprägen Münze -> LZB Münze einlagern 

Beschaffung 

Ronde 1 Euro 

Produktionsschritt 

Material für Ronde 

1 Euro beschaffen 

Nickel-Messing Kupfer-Nickel Nickel 

Produktionsschritt Produktionsschritt Produktionsschritt 

Material für 1 Euro 

bereitstellen 

Giessen 

Ronde 1 Euro 


Metall für Ronde 

1 Euro giessen 


bereitstellen 

Walzen 

Ronde 1 Euro 


Metall für Ronde 

1 Euro walzen 


bereitstellen 

Abbildung 5.1: Produktionsvorschrift Euro-Münze 

Prüfen 

Ronde 1 Euro 


Ronde für 1 Euro 

prüfen 

Für dieses Zwischenprodukt wurde aus Gründen der Übersichtlichkeit in der Darstellung 

eine Vereinfachung vorgenommen. Im Gegensatz zu dem eigentlichen Szenario bleibt zu- 

nächst unberücksichtigt, dass die Ronden für Ein-Euro-Münzen und Zwei-Euro-Münzen 

aus zwei Teilen bestehen, Krone und Kern, die erst bei der Ausprägung zu einem Stück 

verbunden werden. Eine entsprechende Erweiterung des Systems ist allerdings leicht 

möglich, es ist nur ein weiteres Zwischenprodukt hinzuzufügen. 

Die Produktion der Ronde besteht in der vorliegenden Darstellung nur aus Produktions- 

schritten, von denen der erste die Beschaffung der notwendigen Vor- bzw. Zwischenpro- 

98


dukte vorsieht. In diesem Fall sind drei unterschiedliche Metalllegierungen erforderlich. 

Die anschließenden Produktionsstufen der Rondenherstellung sind nur exemplarisch ab- 

gebildet. Gleiches gilt für die Darstellung des zweiten Produktionsschritts für die Herstel- 

lung der Euro-Münze, der Ausprägung. Diese entspricht von der Struktur her der Ron- 

denproduktion. 

Produkt Beschreibung 

1 Euro Münze 1 Euro (500 Stück) 

2 Euro Münze 2 Euro (500 Stück) 

50 Cent Münze 50 Cent (500 Stück) 






1 Euro Ronde Ronde 1 Euro (500 Stück) 

2 Euro Ronde Ronde 2 Euro (500 Stück) 

50 Cent Ronde Ronde 50 Cent (500 Stück) 






Stahl Stahl, 0,01 g 

Nordisches Gold Kupfer-Aluminium-Zink-Zinn-Legierung, 0,01 g 

Nickel-Messing Nickel-Messing-Legierung, 0,01 g 

Kupfer-Nickel Kupfer-Nickel-Legierung, 0,01 g 

Nickel Nickel, 0,01 g 

Tabelle 5.1: Daten der Tabelle Produkt 

Tabelle 5.1 enthält eine Liste der dem System bekannten Produkte, die für die Ronden 

benötigten Metalle sind dort ebenfalls aufgeführt. Münzen und Ronden sind nicht als ein- 

zelne Exemplare abrufbar, sondern in Paketen zu jeweils 500 Stück. 

Obwohl eine Modellierung möglich ist, indem die benötigten Metallmengen für jede ein- 

zelne Münze in normierter Form aufgeführt werden, sollte ein für die Realwelt tauglicher 

99


Algorithmus eine Beschaffung in größeren Dimensionen veranlassen, wozu ein ausrei- 

chender Planungshorizont erforderlich ist. 

Produkt Schritt Schritttyp Ressource Benoetigte_ Rohstoff Anzahl_ 

Kapazitaet Rohstoff 

1 Euro 1 Produktion Ronden 1 100 Ronde 1 Euro 1 

1 Euro 1 Produktion Ronden 2 100 Ronde 1 Euro 1 

1 Euro 2 Transport S-Transport 100 Ronde 1 Euro 1 

1 Euro 3 Produktion Muenze HH 100 Praegung 1 Euro 1 

1 Euro 3 Produktion Muenze M 100 Praegung 1 Euro 1 

1 Euro 3 Produktion Muenze B 100 Praegung 1 Euro 1 

1 Euro 3 Produktion Muenze S 100 Praegung 1 Euro 1 

1 Euro 3 Produktion Muenze KA 100 Praegung 1 Euro 1 

1 Euro 4 Transport S-Transport 100 1 Euro 1 

1 Euro 5 Lager LZB 1 100 1 Euro 1 

1 Euro 5 Lager LZB 2 100 1 Euro 1 

Ronde 1 Euro 1 Produktion Beschaffung 100 Metall 1 Euro 1 

Ronde 1 Euro 2 Produktion Giessen 100 Metall 1 Euro 1 

Ronde 1 Euro 3 Produktion Walzen 100 Metall 1 Euro 1 

Ronde 1 Euro 4 Produktion Stanzen 100 Metall 1 Euro 1 

Ronde 1 Euro 5 Produktion Randrieren 100 Metall 1 Euro 1 

Ronde 1 Euro 6 Produktion Gluehen 100 Metall 1 Euro 1 

Ronde 1 Euro 7 Produktion Polieren 100 Metall 1 Euro 1 

Ronde 1 Euro 8 Produktion Pruefung 100 Metall 1 Euro 1 

Praegung 1 Euro 1 Produktion Praegung 100 Ronde 1 Euro 1 

Praegung 1 Euro 2 Produktion Pruefung 100 Ronde 1 Euro 1 

Praegung 1 Euro 3 Produktion Verpacken 100 Ronde 1 Euro 1 

Tabelle 5.2: Daten der Tabelle Schritt 

Für die Abbildung der Produktionsvorschrift werden Informationen über Schritte benö- 

tigt, die in Tabelle 5.2 dargestellt sind. Es ist ersichtlich, dass alle Schritte die jeweils 

benötigte Ressource exklusiv belegen, die benötigte Kapazität beträgt 100 %. Für einige 

Schritte, z.B. die Prägung, sind unterschiedliche Ressourcen vorgesehen, die Beschrei- 

bung erstreckt sich dann über mehrere Zeilen. 

Die Transportschritte benötigen zusätzliche Informationen über die zu transportierende 

Menge, enthalten in Tabelle 5.3. Start- und Zielort für einen Transport werden aus den 

Produktionsschritten ermittelt, die unmittelbar vor und nach dem Transportschritt erfol- 

gen. Die Reihenfolge der Schritte wird durch Tabelle 5.4 beschrieben. Aufgrund der ge- 

wählten Form der Darstellung sind auch nebenläufige Aktionen realisierbar. Da für jedes 

100


Produkt Schritt Anzahl_TE 

1 Euro 2 4 

Ronde 1 Euro 4 4 

2 Euro 2 5 


Tabelle 5.3: Daten der Tabelle Transportschritt 

Produkt eigenständige Bezeichnungen für die Schritte verwendet werden können, bieten 

sich „sprechende“ Bezeichner an, die z.B. bereits Rückschlüsse auf die Reihenfolge zu- 

lassen. 

Produkt Schritt Naechster_Schritt 

1 Euro 1 2 

1 Euro 2 3 

1 Euro 3 4 

1 Euro 4 5 








Praegung 1 Euro 1 2 

Praegung 1 Euro 2 3 

Tabelle 5.4: Daten der Tabelle Naechster_Schritt 

Jeder Schritt benötigt eine Ressource, auf der er ausgeführt werden kann. Tabelle 5.5 

zeigt eine Auswahl der Ressourcen, die dem System bekannt sind. Die Abteilungen der 

Rondenhersteller und Münzprägen sind nur exemplarisch für Ronden 1 und Münze HH 

aufgeführt. Bestandteil der Ressourcenbeschreibung ist ein Standort, der im Verlauf der 

algorithmischen Planung für die Bestimmung der Transportroute benötigt wird. 

Der Ressourcentyp gibt Auskunft über die Art der Ressource und stellt gleichzeitig eine 

Verknüpfung zu der für jeden Eintrag benötigten Tabelle mit Zusatzinformationen her. 

101


Ressource Ressourcentyp defekt_bis Standort 

Ronden 1 Maschinengruppe 0 Frankfurt 

Ronden 2 Maschinengruppe 0 Frankfurt 

Muenze HH Maschinengruppe 0 Hamburg 

Muenze M Maschinengruppe 0 Muenchen 

Muenze B Maschinengruppe 0 Berlin 

Muenze S Maschinengruppe 0 Stuttgart 

Muenze KA Maschinengruppe 0 Karlsruhe 

S-Transport Transportgruppe 0 bundesweit 

LZB 1 Lager 0 Hamburg 

LZB 2 Lager 0 Muenchen 

Beschaffung F1 Maschinengruppe 0 Frankfurt 

Giessen F1 Maschinengruppe 0 Frankfurt 

Walzen F1 Maschinengruppe 0 Frankfurt 

Stanzen F1 Maschinengruppe 0 Frankfurt 

Randrieren F1 Maschinengruppe 0 Frankfurt 

Gluehen F1 Maschinengruppe 0 Frankfurt 

Polieren F1 Maschinengruppe 0 Frankfurt 

Pruefung F1 Maschinengruppe 0 Frankfurt 

Praegung HH Maschinengruppe 0 Hamburg 

Pruefen HH Maschinengruppe 0 Hamburg 

Verpacken HH Maschinengruppe 0 Hamburg 

S-Trans 1 Transportgruppe 0 bundesweit 




Folgende Einträge sind vorgesehen: 

102 

Tabelle 5.5: Daten der Tabelle Ressource 

• Maschine: Es handelt sich um eine Maschine, weitere Informationen finden sich in 

der Tabelle Maschine. 

• Maschinengruppe: Die Ressource stellt eine Gruppe von Maschinen dar, weitere 

Daten sind in der Tabelle Maschine abgelegt. 

• Transporter: Die Ressource stellt einen Transporter dar, dessen weitere Eigenschaf- 

ten in der Tabelle Transporter beschrieben werden.


• Transportgruppe: Analog zu Maschinengruppen können auch verschiedene Trans- 

porter zu einer Gruppe zusammengefasst werden. Nähere Angaben sind in der Ta- 

belle Transporter enthalten. 

• Lager: Die Eigenschaften des Lagers werden durch den korrespondierenden Eintrag 

in der Tabelle Lager präzisiert. 

• Lagergruppe: Auch für Lager ist eine Gruppierung vorgesehen, weiteres findet sich 

in Tabelle Lager. 

Maschine Maschinentyp Intensitaet 

Ronden 1 Maschinengruppe 240 

Ronden 2 Maschinengruppe 240 

Muenze HH Maschinengruppe 120 

Muenze M Maschinengruppe 60 

Muenze B Maschinengruppe 60 

Muenze S Maschinengruppe 120 

Muenze KA Maschinengruppe 120 

Beschaffung F1 Maschinengruppe 120 

Giessen F1 Maschinengruppe 120 

Walzen F1 Maschinengruppe 120 

Stanzen F1 Maschinengruppe 120 

Randrieren F1 Maschinengruppe 120 

Gluehen F1 Maschinengruppe 120 

Polieren F1 Maschinengruppe 120 

Pruefung F1 Maschinengruppe 120 

Praegung HH Maschinengruppe 120 

Pruefen HH Maschinengruppe 120 

Verpacken HH Maschinengruppe 120 

Tabelle 5.6: Daten der Tabelle Maschine 

Die Tabellen 5.6 und 5.7 konkretisieren die Eigenschaften der Ressourcen Maschine und 

Transporter. Für Lager sind zunächst keine weiteren Informationen vorgesehen, die ent- 

sprechende Tabelle entfällt daher. Der Maschinen- bzw. Transportertyp erlaubt eine Klas- 

sifizierung der jeweiligen Ressourcen. Handelt es sich nicht um ein Gruppe, so kann dort 

z.B. Praegemaschine oder LKW 5t vermerkt sein. 

103


Transporter Transportertyp Zuladung 

S-Transport Transportgruppe 100000 

S-Trans 1 Transportgruppe 40000 




Tabelle 5.7: Daten der Tabelle Transporter 

Die Intensität beschreibt, wie viele der auf der Maschine ausführbaren Produktionsschritte 

innerhalb einer Stunde ablaufen können. Die Zuladung enthält eine Angabe darüber, wel- 

che Anzahl Transporteinheiten (TE) der Transporter gleichzeitig laden kann. In diesem 

Beispiel wird davon ausgegangen, dass ein einzelner Transporter 10000 TE mit jeweils 

500 g Gewicht laden kann. Die Transportgruppe S-Trans 1 hat demnach 4 Fahrzeuge 

gleichzeitig im Einsatz. 

Startort Zielort Dauer 

Frankfurt Hamburg 7 

Frankfurt Muenchen 6 

Hamburg Muenchen 12 

Stuttgart Muenchen 4 

Berlin Muenchen 9 

Tabelle 5.8: Daten der Tabelle Route 

Der für die Transportplanung zuständige Algorithmus benötigt, nachdem die konkreten 

Routen aus der Vergabe von Produktionsaufträgen an unterschiedliche Standorte ermittelt 

worden sind, Informationen über zu kalkulierende Fahrtzeiten. Diese sind in Tabelle 5.8 

abgelegt. 

Zu den Stammdaten des Systems gehören Informationen über die beteiligten Agenten. 

Eine Auswahl zeigt Tabelle 5.9. Aufgrund von zum Teil ähnlichen Planungsaufgaben 

können Agenten, die eigentlich für verschiedene Ressourcen zuständig sind, identische 

Algorithmen verwenden, so z.B. die Toplevel-Agenten der einzelnen Münzprägen. 

Im Gegensatz zu den Produktionsstufen benötigen die für die Abteilung Beschaffung der 

Rondenhersteller verantwortlichen Agenten einen speziellen Algorithmus, der in der Lage 

104


Agent Vater Team Algo Ressource 

PA 1 Toplevel toplevel 

PA 1.2 PA 1 S-Transport 1 transporttop S-Transport 

PA 1.1.1 PA 1 Ronden 1 rondentop Ronden 1 

PA 1.1.2 PA 1 Ronden 2 rondentop Ronden 2 

PA 1.3.1 PA 1 Muenze HH muenzetop Muenze HH 

PA 1.3.2 PA 1 Muenze M muenzetop Muenze M 

PA 1.3.3 PA 1 Muenze B muenzetop Muenze B 

PA 1.3.4 PA 1 Muenze S muenzetop Muenze S 

PA 1.3.5 PA 1 Muenze KA muenzetop Muenze KA 

PA 1.4.1 PA 1 LZB 1 lzbtop LZB 1 

PA 1.4.2 PA 1 LZB 2 lzbtop LZB 2 

PA 1.1.1.1 PA 1.1.1 rondenbeschaffung Beschaffung F1 

PA 1.1.1.2 PA 1.1.1 rondendurchlauf Giessen F1 

Tabelle 5.9: Daten der Tabelle Agent 

Vater Kind Kommunikation 

PA 1 PA 1.1.1 Contract Net 


PA 1 PA 1.2 direkt 






PA 1 PA 1.4.1 direkt 

PA 1 PA 1.4.2 direkt 

PA 1.1.1 PA 1.1.1.1 direkt 

PA 1.1.1 PA 1.1.1.2 direkt 

PA 1.2 PA 1.2.1 Contract Net 

PA 1.3.1 PA 1.3.1.1 direkt 

PA 1.3.1 PA 1.3.1.2 direkt 

PA 1.1.1.1 PA 1.1.1.1.1 Contract Net 

Tabelle 5.10: Daten der Tabelle Agent_zu_Kinder 

105


ist, für jede Ronde die benötigten Mengen unterschiedlicher Metalle zu kalkulieren. Die 

anderen Stationen (Giessen, Walzen, etc.) können mit dem gleichen Algorithmus arbeiten. 

Tabelle 5.10 legt das Kommunikationsverhalten der Agenten fest. Für alle Paare von 

Agenten, die in einer hierarchischen Beziehung zueinander stehen, ist hier vermerkt, ob 

sie Aufträge via Contract Net oder direkter Kommunikation, die einfaches Delegieren 

verwendet, erteilen sollen. 

5.1.2 Testdaten 

Geeignete Daten für einen Test des Systems bestehen aus Aufträgen. Diese können dem 

obersten Agenten PA1 entweder über eine Nachricht zugestellt oder direkt in die Daten- 

bank geschrieben werden. Die Prädiktive Planung für in der Tabelle Auftrag enhaltene 

Aufträge kann anschließend mit der Nachricht AgentPredSched ausgelöst werden. Tabel- 

le 5.11 zeigt mögliche Aufträge. 

Auftrag Produkt Auftragnehmer Menge Startzeitpunkt Endzeitpunkt 

1 1 Euro PA 1 1200 0 60 

2 50 Cent PA 1 2400 0 60 

3 2 Euro PA 1 2400 0 60 

4 1 Euro PA 1 960 0 60 

Tabelle 5.11: Daten der Tabelle Auftrag 

5.2 Klassenstruktur des Multiagenten-Systems 


Abbildung 5.2 zeigt das Klassendiagramm des Multiagenten-Systems. Datenobjekte sind 

in der Grafik nicht dargestellt, Operationen werden exemplarisch gezeigt. Die Auftei- 

lung in Frozen Spots und Hot Spots ist erhalten geblieben, Frozen Spots sind analog zu 

Abbildung 4.9 dunkel hervorgehoben. Von den benötigten Planungskomponenten ist die 

Komponente Neuer Auftrag enthalten. 

5.2.2 Änderungen an den Frozen Spots 

Das dem Framework ursprünglich zugrunde liegende Datenschema wurde radikal verän- 

dert. Daher war es erforderlich, auch die Frozen Spots an die neuen Erfordernisse anzu- 

passen. 

106

PNeuerAuftrag 

NeueNachricht() 

weitereOperationen() 

1 

1 

AgentenKern 

Datenbank : Datenbank 

Kommunikation : Kommunikation 

Status : short 

Planverbesserung : Planverbesserung 

NeueNachrichtEingetroffen() 

NachrichtWeiterleiten() 

KernStarten() 

AgentenSchleife() 

ContractNetInit() 

ContractNetVersteigerung() 

1 

1 

1 

1 

Datenbank 

Datenbank : Datenbankschnittstelle 

PlanOperationen() 

AuftragOperationen() 

RouteOperationen() 

ProduktOperationen() 

RessourceOperationen() 

AgentOperationen() 

1 

1 

Datenbankschnittstelle 

con : Connection 

stmt : Statement 

rs : ResultSet 

Connect() 

Update() 

Query() 

Close() 

1 

Planungskomponente 


1 


weitereOperationen() 

5.2 Klassenstruktur des Multiagenten-Systems 

weitere Planungskomponenten 

AgentenInformation 

AgentenKernDienstleistung 

AgentenID : string 



Kommunikation : Kommunikation 

Kommunikation : string 

Algo : string 

1 1 Team : string 

PlanOperationen() 

AuftragOperationen() 

1 1 

RouteOperationen() 

ProduktOperationen() 

RessourceOperationen() 

1 

1 

AgentOperationen() 

NachrichtVerschicken() 

1 

1 

1 

Kommunikation 

EingangsQueue : NachrichtenQueue 

AusgangsQueue : NachrichtenQueue 

FlagPlanverbesserung : boolean 

Kommunikationsschnittstelle : Kommunikationsschnittstelle 


NeueNachrichtVorhanden() 

NeueNachrichtAbholen() 

NachrichtSenden() 

NachrichtSendenVorhanden() 

NachrichtSendenAbholen() 

FlagPlanverbesserungSetzen() 

1 

1 

Kommunikationsschnittstelle 

kom : Kommunikation 

NachrichtVerschicken() 

NachrichtAbrufen() 

1 

1 

1 

1 

1 

1 

1 


PlanverbesserungAktivieren() 

PlanverbesserungUnterbrechen() 

NachrichtenQueue 

AddNachricht() 

NaechsteNachricht() 

1 2 

IstLeer() 

Abbildung 5.2: Vereinfachtes Klassendiagramm des Multiagenten-Systems 

Nachricht 

Performative : string 

Sender : string 

Receiver : string 

Language : string 

Ontology : string 

Content : string 

Grundlage der weiteren Veränderungen ist eine Überarbeitung der Klasse Datenbank. 

Analog zu der Ausgangsversion werden die Inhalte der Datenbank zur Laufzeit in dy- 

namischen Objekten bereitgestellt. Damit ein Abgleich mit den Tabellen erfolgen kann, 

werden Operationen zum Anzeigen und zum Speichern bzw. Ändern angeboten. 

Die eigentliche Kontrollfluss-Steuerung mittels der Agentenschleife in der Klasse Agen- 

tenKern bleibt im Wesentlichen unverändert (Abschnitt 4.3.5.3). Da für die Aktivierung 

der Planungskomponenten zusätzliche Parameter erforderlich sind und neue Komponen- 

1 

1 

0..* 

107


ten hinzugefügt wurden, ist die situationsabhängige Weiterleitung der Nachrichten ent- 

sprechend modifiziert worden. 

Die Klasse AgentenKernDienstleistung hat u.a. die Aufgabe, den Planungskomponenten 

einen Zugriff auf die Datenobjekte zu ermöglichen. Dazu stellt sie eigene Operationen 

zur Verfügung, die auf die Datenbank zurückgreifen und eine Kapselung bewirken. Durch 

diese Maßnahme wird erreicht, dass der Kontrollfluss immer dem Agenten-Kern vorbe- 

halten bleibt. Die bereitgestellten Operationen wurden entsprechend denen der Datenbank 

verändert. 

In der Klasse AgentenInformation sind jetzt ein paar zusätzliche Informationen enthalten, 

die der erweiterten Agentenbeschreibung im Datenschema Rechnung tragen. 

Die Kommunikation wurde um die benötigten zusätzlichen Nachrichten erweitert. Im Zu- 

sammenspiel mit den Planungskomponenten ist es nun möglich, den Aufruf einer Kom- 

ponente nicht nur durch den Nachrichteninhalt zu steuern, sondern zusätzlich auch von 

dem in den Stammdaten für den Agenten eingetragenen Algorithmus abhängig zu ma- 

chen. 

5.2.3 Änderungen an den Hot Spots 

Mit einer Änderung der Hot Spots des Frameworks kann eine Adaption für ein bestimm- 

tes Ablaufplanungsszenario erreicht werden. Die benötigten Algorithmen werden dabei 

in unterschiedlichen Planungskomponenten untergebracht und in Abhängigkeit von auf- 

tretenden Ereignissen angesteuert. 

Für das vorliegende Szenario war eine Modifikation der Planungskomponenten erforder- 

lich. Neben der Erstellung eigenständiger Algorithmen musste auch hier eine Anpassung 

an die tiefgreifenden Veränderungen des Datenschemas erfolgen. Künftige Erweiterungen 

können sich auf eine Neugestaltung der Hot Spots beschränken, sofern das vorhandene 

Datenschema und die unterstützten Nachrichtentypen ausreichend erscheinen. 

Wie in der originalen Version des Frameworks vorgesehen, wird ein auf SQL basierendes 

RDBMS für die Datenhaltung und als Kommunikationsmedium verwendet. Eine Ände- 

rung der Schnittstellen ist daher nicht erfolgt. 

108

5.3 Dateien und Startumgebung 

5.3 Dateien und Startumgebung 

Die prototypische Implementierung des Multiagenten-Systems greift auf eine Vielzahl 

von Dateien zurück. Neben den Dateien, die den Sourcecode bzw. die vom Compiler 

erzeugte Ausgabe enthalten, gibt es noch einige Skript-Dateien für die Einrichtung und 

Pflege der Datenbank. 

Der Start des kompletten Systems mit allen erforderlichen Agenten wird ebenfalls durch 

ein Skript unterstützt. Dieses ist abhängig vom verwendeten Betriebssystem und wird 

hier in einer für Microsoft Windows � in den Versionen NT/2000/XP geeigneten Variante 

vorgestellt. 

5.3.1 Datenbank 

Die SQL-Skript-Dateien für die Erzeugung und Wartung der Datenbank müssen zur Aus- 

führung dem Befehlsinterpreter des zugrunde liegenden RDBMS (MySQL) übergeben 

werden. Der Aufruf lautet: mysql < {SKRIPTDATEI}. 

Folgende Skripte stehen bereit: 

• \maplan\sql\DBCreate.sql: Erzeugt alle für das Planungssystem benötig- 

ten Tabellen in der vorhandenen, aber vollständig leeren Datenbank maplan. 

• \maplan\sql\DBDrop.sql: Entfernt alle Tabellen samt Inhalt aus der Daten- 

bank maplan. 

• \maplan\sql\DBInit.sql: Löscht alle Bewegungsdaten (Aufträge, Pläne, La- 

gerdaten) aus der Datenbank maplan. 

• \maplan\sql\DBLoad.sql: Dient dazu, den Inhalt der nachfolgenden Daten- 

Dateien in die Tabellen der Datenbank maplan zu laden: 

– \maplan\sql\DataPlan.sql, 

– \maplan\sql\DataAuftrag.sql, 

– \maplan\sql\DataProdukt.sql, 

– \maplan\sql\DataSchritt.sql, 

– \maplan\sql\DataNaechster_Schritt.sql, 

– \maplan\sql\DataTransportSchritt.sql, 

– \maplan\sql\DataRoute.sql, 

109


– \maplan\sql\DataRessource.sql, 

– \maplan\sql\DataRessourcen_Verfuegbarkeit.sql, 

– \maplan\sql\DataAgent.sql, 

– \maplan\sql\DataAgent_zu_Kinder.sql, 

– \maplan\sql\DataMaschine.sql, 

– \maplan\sql\DataTransport.sql, 

– \maplan\sql\DataLager.sql. 

• \maplan\sql\DBTest.sql: Initialisiert die Tabellen der Datenbank maplan 

mit den für den Beispielablauf benötigten Daten. 

5.3.2 Sourcecode 

Für die Java � -Source-Dateien wird der Package-Name maplan verwendet, die Dateien 

sind in dem Verzeichnis \maplan\java\maplan abgelegt. Jede Klasse steht in einer 

eigenen Datei, was auch für die Planungskomponenten gilt. Da mit dem erweiterten Fra- 

mework unterschiedliche Agenten realisiert werden sollen, sind in einigen Dateien für 

Planungskomponenten mehrere Varianten eines Algorithmus vorhanden, von denen zur 

Laufzeit die für den aktuellen Agent gültige gewählt wird. 

5.3.3 Startumgebung 

Alle Agenten des Planungssystem werden durch ein Start-Skript nacheinander in separa- 

ten Prozessen des Betriebssystems gestartet und präsentieren sich mit einzelnen Fenstern 

auf dem Bildschirm. 

Die Skript-Datei hat den Namen \maplan\java\maplan\maplan.cmd und enthält 

Befehlszeilen gemäß folgendem Aufbau: 

start "Agent {AGENTNAME}" /i java maplan.Planungsagent "{AGENTNAME}" 

Folgende Befehlszeile in der Datei bewirkt z.B., dass Agent PA1.3.1 gestartet wird: 

start "Agent PA 1.3.1" /i java maplan.Planungsagent "PA 1.3.1" 

Jeder Agent, der gestartet wird, bekommt außer seinem Namen keine zusätzlichen Para- 

meter. Die weiteren Informationen, etwa über ihm untergeordnete Agenten oder den zu 

verwendenden Planungsalgorithmus, bezieht der Agent aus der Datenbank. 

110

5.4 Beispielablauf 


Die für das Planungssystem verwendeten Algorithmen beinhalten einige Besonderheiten, 

die an zwei beispielhaften Abläufen des Systems illustriert werden sollen. Die dazu benö- 

tigten Stamm- und Testdaten sind in Abschnitt 5.1 erläutert. Abbildung 5.3 zeigt in einem 

Gantt-Diagramm, wie ein möglicher Ablaufplan aussehen kann, wenn er von der prädik- 

tiven Komponente des Algorithmus toplevel erstellt wird. 

Ronden 1 

Ronden 2 

S-Transport 

S-Transport 

Münze HH 

Münze M 

Münze B 

Münze S 

Münze KA 

LZB 1 (HH) 

1200 

2400 

Auftrag 1 

10 20 30 40 50 60 

2400 

F-HH 

960 

F-S 

1200 

F-KA 

F-HH 

2400 

HH-M 

S-HH 

10 20 30 40 50 60 

Auftrag 2 

HH-HH 

960 

2400 

LZB 1 (M) 1200 

Auftrag 3 

Abbildung 5.3: Prädiktive Planung des Algorithmus toplevel 

(Agent PA1, BUND) 

960 

KA-M 

2400 

Auftrag 4 

In der Grafik sind die vier Aufträge dargestellt, deren einzelne Schritte auf die unter- 

schiedlichen Ressourcen verplant worden sind. Für jede Ressourcenbelegung sind zwei 

Balken dargestellt. Der untere zeigt die minimale Zeit, wie sie aufgrund der Angaben aus 

den Stammdaten zu erwarten wäre, der obere enthält einen durch den Algorithmus hin- 

zugefügten Sicherheitszuschlag. Dieser beträgt bei Produktionsschritten 20 % und wird 

2400 

111


auf volle Zeitschritte auf- oder abgerundet. Für jeden Zeitschritt wird die Dauer von einer 

Stunde angenommen. 

Bei Transportschritten wird der Sicherheitszuschlag in Abhängigkeit von der in der Tabel- 

le Route eingetragenen Fahrtzeit erhoben. Bei Zeiten von bis zu fünf Stunden wird eine, 

bei sechs bis zehn Stunden werden zwei Stunden Aufschlag addiert. Dauert die Fahrt län- 

ger als zehn Stunden, wird für alle weiteren, angefangenen Intervalle mit einer Länge von 

fünf Stunden eine zusätzliche Stunde addiert. 

Latenzzeiten, die bei der Fertigung von Ronden und Münzen eigentlich zu berücksich- 

tigen wären, können vernachlässigt werden, da ohnehin ein Sicherheitszuschlag erhoben 

wird und sich die Latenzzeiten außerdem im Bereich weniger Minuten (n - 1 Produkti- 

onsstufen) bewegen. Für innerstädtische Fahrten wird eine Fahrtdauer von einer Stunde 

angenommen, die durch den Sicherheitszuschlag automatisch auf zwei Stunden erhöht 

wird. Unter dem Eindruck zunehmender Verkehrsdichte in den Ballungsräumen erscheint 

diese Größe angemessen. 

Die Produktionsschritte enthalten eine Angabe über die zu produzierenden Mengen, die, 

wie in den Stammdaten definiert, aus Paketen zu je 500 Stück bestehen. Bei Transport- 

schritten ist eine Angabe über die zu fahrende Route vermerkt. Lagerschritte werden 

durch gestrichelt gezeichnete Quadrate angedeutet. Da die Ressource S-Transport über 

große Kapazitäten verfügt, wurden zwei Zeilen für die Darstellung vorgesehen. 

Der für die Versteigerung zuständige Algorithmus erteilt grundsätzlich dem besten Gebot 

den Zuschlag. So ist zu erklären, dass die Münze Hamburg zwei der Fertigungsaufträge 

erhält, während die Münzen in München und Berlin bei der dargestellten Auftragssituati- 

on unberücksichtigt bleiben. Es wird allerdings darauf geachtet, dass Produktionssaufträ- 

ge innerhalb von drei Stunden nach Anlieferung beginnen können. So ist gewährleistet, 

dass keine Zwischenlagerung großer Produktmengen erforderlich ist. 

Falls mehrere Agenten, die an einer Versteigerung teilnehmen, gleichwertige Gebote ab- 

geben, wird der Zuschlag nach dem Zufallsprinzip erteilt. Hierdurch soll ein gewisses 

Maß an Fairness gewährleistet bleiben. Es ist allerdings anzumerken, dass die Münzen in 

München und Berlin bei der vorgestellten Konfiguration benachteiligt werden. Gemäß ih- 

ren Stammdaten verfügen sie nur über die halbe Produktionskapazität im Vergleich zu den 

anderen drei Münzen. Für jeden Produktionsauftrag benötigen sie daher die doppelte Zeit. 

112


Die Verteilung der produzierten Münzen auf die Landeszentralbanken ist in diesem Bei- 

spiel nicht durch Aufteilung von Mengen erfolgt. In den Aufträgen für Agent PA1 ist der 

Zielort entsprechend gesetzt, wodurch der Planungsalgorithmus gezwungen wird, die ge- 

wünschte Einlagerung zu veranlassen. 

S-Transport 

S-Transport 

S-Trans 1 

S-Trans 2 

S-Trans 3 

S-Trans 4 

Auftrag 1 

10 20 30 40 

F-HH 

(4800 TE) 

F-S 

(9600 TE) 

F-HH 

(4800 TE) 

F-S 

(9600 TE) 

HH-M 

(4800 TE) 

HH-HH 

(3840 TE) 

HH-M 

(4800 TE) 

HH-HH 

(3840 TE) 

S-HH 

(9600 TE) 

10 20 30 40 50 

Auftrag 2 

F-KA 

(12000 TE) 

F-HH 

(3840 TE) 

F-KA 

(12000 TE) 

F-HH 

(3840 TE) 

Auftrag 3 Auftrag 4 

S-HH 

(9600 TE) 

Abbildung 5.4: Prädiktive Planung des Algorithmus transporttop 

(Agent PA1.2, S-Transport) 

50 

KA-M 

(12000 TE) 

KA-M 

(12000 TE) 

Agent PA1.2 erhält alle auszuführenden Transportaufträge und hat die Aufgabe, diese an 

die Transportunternehmen zu verteilen. In Abbildung 5.4 ist das Ergebnis des prädiktiven 

transporttop Algorithmus dargestellt. Die Balken enthalten Angaben über die Fahrtroute 

und die zu transportierende Menge von Transporteinheiten (TE). 

In seinem eigenen Plan berücksichtigt der Agent die übermittelteten Sicherheitszuschlä- 

ge. Für die Vorgaben an die untergeordneten Agenten wird dieser allerdings entfernt. Bei 

der Versteigerung ist aufgrund der großzügig zur Verfügung stehenden Transportkapa- 

zitäten damit zu rechnen, dass die Agenten sehr oft gleichwertige Gebote abgeben. Im 

Gegensatz zu dem Algorithmus des Toplevel-Agenten erfolgt bei der Transportplanung 

keine zufällige Vergabe. Stattdessen wird versucht, jedem Unternehmen nach und nach 

einen Auftrag zu erteilen, um eine gleichmäßige Auslastung zu erreichen (Round Robin 

Prinzip). So bleiben auch für den Fall einer höheren Auslastung Räume, in denen notwen- 

dige Rück- bzw. Leerfahrten stattfinden können. 

Betriebswirtschaftlich gesehen wäre eine Transportplanung sinnvoller, die versucht, auf 

möglichst wenig Transportunternehmen angewiesen zu sein. Durch diese Strategie könnte 

eine Reduktion der notwendigen Geschäftsbeziehungen und gleichzeitig eine Belebung 

des Wettbewerbs erreicht werden. 

113


114

6 Zusammenfassung und Ausblick 

6.1 Zusammenfassung 

In dieser Diplomarbeit wird ein Ansatz beschrieben, der Teams von Agenten verwen- 

det, um Ablaufplanungsprobleme über mehrere Ebenen hinweg, z.B. beim Supply Chain 

Scheduling, zu lösen. Dieser Ansatz besteht aus einem Vorgehensmodell, das detailliert 

beschreibt, wie ein Supply Chain Szenario der Realwelt auf ein Team-basiertes Multi- 

agenten-System abgebildet werden kann. Eine exemplarische Umsetzung für ein Beispiel- 

Szenario liefert wichtige Erkenntnisse über die konkrete Ausgestaltung von Algorithmen, 

sowie Daten- und Kommunikationsstrukturen. 

Das Modell besteht aus mehreren Phasen und beginnt mit einer gründlichen Analyse des 

zu betrachtenden Szenarios. Anschließend wird gezeigt, wie einzelnen Organisationsein- 

heiten Agenten zugeordnet werden und diese mit einer hinsichtlich Planungskomplexität 

und Kommunikationseffizienz sinnvollen Team- bzw. Beziehungsstruktur versehen wer- 

den können. Es folgt eine Betrachtung der Tätigkeiten, die für eine Präzisierung der Agen- 

ten notwendig sind. Dabei wird ein allgemeines Template für die Agenten vorgestellt, das 

vorgibt, welche Eigenschaften erforderlich und mit Inhalten zu füllen sind. Gegenstand 

weiterer Betrachtungen sind die Auswahl bzw. Konzeption einer geeigneten Agenten- 

Plattform und Strategien, wie konkrete Anforderungen bezüglich Datenstrukturen und 

Algorithmen in diese integriert werden. 

Auf Basis des Vorgehensmodells erfolgt die Entwicklung eines Ablaufplanungssystems 

für ein konkretes Beispielszenario. Fundament des Systems ist ein umfassendes Daten- 

schema, das spezifische Besonderheiten des Supply Chain Scheduling und der Teams von 

Agenten berücksichtigt. Insbesondere die gegenüber der „klassischen“ verteilten Ablauf- 

planung explizit zu berücksichtigenden Transporte benötigen neue Entitäten, um Prozesse 

der Realwelt mit dem System realisieren zu können. 

Die einzelnen Agenten des Planungssystems haben sehr unterschiedliche Aufgaben zu 

erfüllen und benötigen diverse Algorithmen. Einige der interessantesten davon sind in 

115


Pseudo-Code dargestellt und mit einer näheren Beschreibung versehen. Es handelt sich 

dabei u.a. um den Planungsalgorithmus für den Toplevel-Agenten und den Algorithmus 

für die Optimierung der Transporte. 

Im Bereich Kommunikation werden verschiedene Möglichkeiten der Auftragsvergabe 

vorgestellt. Die dazu erforderlichen Nachrichten werden definiert, wobei die Berücksich- 

tigung von Transporten und Lagern auch hier die Erweiterung üblicher Konzepte bedeu- 

tet. 

Hinsichtlich der benötigten Agenten-Plattform erfolgt die Evaluierung eines vorhandenen 

Frameworks für die Realisierung einzelner Planungsagenten. Diese ergibt zwar umfas- 

senden Änderungsbedarf, im Vergleich zu einem komplett neuen Design erscheint dieser 

allerdings gerechtfertigt. Notwendige Änderungen, z.B. das neu gestaltete Datenschema 

und ein erweitertes Nachrichtenkonzept, werden integriert und das Framework mit Me- 

chanismen zur Konfiguration ausgestattet. Mit einer standardisierten Startumgebung ist 

es nun möglich, mehrere Agenten gleichzeitig auf einfache Weise ablaufen zu lassen. 

Als Beispielszenario dient dieser Diplomarbeit die bei der Prägung von Euro-Münzen be- 

stehende Supply Chain. Die dabei beteiligten Organisationseinheiten werden vorgestellt 

und die für die Ablaufplanung relevanten Vorgänge beschrieben. 

6.2 Ausblick 

Der in dieser Diplomarbeit behandelte Bereich der Ablaufplanungsprobleme benötigt eine 

Vielzahl von Lösungen für unterschiedliche Ebenen der Betrachtung. Das hier vorgestell- 

te Modell für die Umsetzung eines Szenarios der Realwelt auf ein auf Teams von Agenten 

basierendes Multiagenten-System und die erfolgte Realisierung bieten einige Möglichkei- 

ten für Erweiterungen: 

116 

• Das in dieser Arbeit eingeführte Datenschema könnte um weitere Entitäten ergänzt 

werden. Insbesondere im Bereich Transportplanung wäre eine präzisere Abbildung 

sinnvoll, die z.B. nicht nur einheitlich große Transporteinheiten berücksichtigt, son- 

dern variable Container einführt. Diese könnten dann sowohl den Produkten, als 

auch den Transportern zugeordnet werden, um die Mengenbeziehungen herzustel- 

len.

6.2 Ausblick 

Eine Beachtung von Gewichten und Stoffeigenschaften für Transporte sollte eben- 

falls ermöglicht und auch die Lagerraum-Planung in dieses erweiterte Schema ein- 

bezogen werden. Für die Abbildung von Produkten ist eine bessere Unterstützung 

von unterschiedlichen Fertigungsarten, z.B. der Fließfertigung, wünschenswert. 

• Eine genauere Abbildung der Transportproblematik mit komplexeren Datenmen- 

gen erfordert neue Algorithmen, die dann z.B. in der Lage wären, Fahrzeuge unter- 

schiedlicher Größe mit verschiedensten Produkten optimal zu beladen. 

• Im Bereich Konfigurierbarkeit wurde zwar ein Grundstein gelegt, allerdings ist 

auch eine automatische Konfigurationsumgebung für die menügesteuerte Einrich- 

tung des Multiagenten-Systems denkbar. Grundlage dafür ist die Erarbeitung eines 

abstrakten Modells für die Beschreibung der Konfigurationsdaten und der erforder- 

lichen Schnittstellen der Agenten zu Algorithmen und Daten. 

• Eine Anbindung einer grafischen Benutzungsschnittstelle ist zwar durch die Ver- 

wendung einer SQL-Datenbank und eines Nachrichtenkonzepts ohne weiteres mög- 

lich, bisher aber nicht realisiert. 

• Die prototypische Implementierung lässt Raum für Verbesserungen im Bereich 

Speicherplatzbedarf und Variabilität. 

• Für den Einsatz eines Multiagenten-Systems in der Realwelt und über Unterneh- 

mensgrenzen hinweg ist eine Erweiterung des Nachrichtenmodells notwendig, die 

neben einer Verschlüsselung der Daten auch die Authentizität und die Berechtigun- 

gen der Kommunikationspartner berücksichtigt. 

• Die Benutzerinteraktion bekommt durch die erweiterte Komplexität des Supply 

Chain Scheduling ebenfalls eine neue Dimension. Neben den bereits in Abschnitt 

2.1.4 genannten Problemen und den erweiterten Datenmengen und Planungsop- 

tionen, insbesondere durch den Transport, müssen evtl. unterschiedliche Views für 

verschiedene Benutzer erzeugt werden. So wäre es möglich, kooperierenden Unter- 

nehmen zwar Daten der eigenen Produktion zu übermitteln, gleichzeitig aber eine 

Zugriffsbeschränkung und, falls notwendig, auch eine Informationsausblendung zu 

erreichen. 

117


118

Abbildungsverzeichnis 

2.1 Ebenen der Ablaufplanung . . . . . . . . . . . . . . . . . . . . . . . . . 6 

2.2 Ebenen der verteilten Ablaufplanung . . . . . . . . . . . . . . . . . . . . 15 

2.3 Einfache Supply Chain in der Textilindustrie . . . . . . . . . . . . . . . . 18 

2.4 Die Supply Chain Planning Matrix . . . . . . . . . . . . . . . . . . . . . 22 

2.5 Schematische Darstellung eines Agenten . . . . . . . . . . . . . . . . . . 27 

2.6 Architekturen für Agenten . . . . . . . . . . . . . . . . . . . . . . . . . 28 

2.7 Einfaches Delegieren bei Agenten . . . . . . . . . . . . . . . . . . . . . 31 

2.8 Versteigerung im Contract Net . . . . . . . . . . . . . . . . . . . . . . . 31 

2.9 Architektur des AMPA-Systems . . . . . . . . . . . . . . . . . . . . . . 35 

2.10 Architekturskizze eines AMPA-Agenten . . . . . . . . . . . . . . . . . . 36 

3.1 Das Europäische System der Zentralbanken . . . . . . . . . . . . . . . . 39 

3.2 Transporte bei der Produktion der Euro-Münzen . . . . . . . . . . . . . . 43 

3.3 Beauftragung von Transporten durch den Bund . . . . . . . . . . . . . . 44 

4.1 Phasen des Vorgehensmodells . . . . . . . . . . . . . . . . . . . . . . . 49 

4.2 Zuordnung von Agenten zu Stellen . . . . . . . . . . . . . . . . . . . . . 52 

4.3 Benennung der Agenten . . . . . . . . . . . . . . . . . . . . . . . . . . 52 

4.4 Globale Sicht der Supply Chain . . . . . . . . . . . . . . . . . . . . . . 59 

4.5 Globale Sicht der Supply Chain mit aufgefalteten Virtuellen Organisati- 

onseinheiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 

4.6 Produktion der Ronden . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 

4.7 Prägung der Münzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 

4.8 Verteilung der Sicherheitstransporte . . . . . . . . . . . . . . . . . . . . 62 

4.9 Schematischer Aufbau eines Planungsagenten des Frameworks von Bröske 70 

4.10 Schichtenarchitektur eines Planungsagenten des Frameworks von Bröske 71 

4.11 Agenten-Kern: Endlicher Automat . . . . . . . . . . . . . . . . . . . . . 74 

4.12 Datenschema des Multiagenten-Systems . . . . . . . . . . . . . . . . . . 78 

4.13 Pseudocode für den prädiktiven Toplevel-Algorithmus . . . . . . . . . . 91 

119

Abbildungsverzeichnis 

120 

4.14 Pseudocode für die prädiktive Planung der Teams bei Rondenproduktion 

und Münzprägung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 

4.15 Pseudocode für die Optimierung und prädiktive Planung der Sicherheits- 

transporte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 

5.1 Produktionsvorschrift Euro-Münze . . . . . . . . . . . . . . . . . . . . . 98 

5.2 Vereinfachtes Klassendiagramm des Multiagenten-Systems . . . . . . . . 107 

5.3 Prädiktive Planung des Algorithmus toplevel (Agent PA1, BUND) . . . . 111 

5.4 Prädiktive Planung des Algorithmus transporttop (Agent PA1.2, S-Transport)113

Tabellenverzeichnis 

2.1 Verteilte Ablaufplanung, Unterschiede der globalen und lokalen Ebene . . 16 

3.1 Technische Merkmale der Euro-Münzen . . . . . . . . . . . . . . . . . . 41 

4.1 Zugehörigkeit der Agenten zu Teams . . . . . . . . . . . . . . . . . . . . 64 

4.2 Daten eines Agenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 

4.3 Daten der Agent_zu_Kinder-Relation . . . . . . . . . . . . . . . . . . . 79 

4.4 Daten eines Planschritts . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 

4.5 Daten eines Auftrags . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 

4.6 Daten eines Produkts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 

4.7 Daten eines Schrittes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 

4.8 Daten eines Transportschrittes . . . . . . . . . . . . . . . . . . . . . . . 83 

4.9 Daten für die Nachfolgerbeziehung zwischen den Schritten . . . . . . . . 83 

4.10 Daten einer Ressource . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 

4.11 Daten der Ressourcenverfügbarkeit . . . . . . . . . . . . . . . . . . . . . 84 

4.12 Daten einer Maschine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 

4.13 Daten eines Transporters . . . . . . . . . . . . . . . . . . . . . . . . . . 85 

4.14 Daten eines Lagers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 

4.15 Daten einer Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 

4.16 Ontologie und Inhalt der KQML-Nachrichten . . . . . . . . . . . . . . . 86 

5.1 Daten der Tabelle Produkt . . . . . . . . . . . . . . . . . . . . . . . . . 99 

5.2 Daten der Tabelle Schritt . . . . . . . . . . . . . . . . . . . . . . . . . . 100 

5.3 Daten der Tabelle Transportschritt . . . . . . . . . . . . . . . . . . . . . 101 

5.4 Daten der Tabelle Naechster_Schritt . . . . . . . . . . . . . . . . . . . . 101 

5.5 Daten der Tabelle Ressource . . . . . . . . . . . . . . . . . . . . . . . . 102 

5.6 Daten der Tabelle Maschine . . . . . . . . . . . . . . . . . . . . . . . . 103 

5.7 Daten der Tabelle Transporter . . . . . . . . . . . . . . . . . . . . . . . 104 

5.8 Daten der Tabelle Route . . . . . . . . . . . . . . . . . . . . . . . . . . 104 

121

Tabellenverzeichnis 

122 

5.9 Daten der Tabelle Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 105 

5.10 Daten der Tabelle Agent_zu_Kinder . . . . . . . . . . . . . . . . . . . . 105 

5.11 Daten der Tabelle Auftrag . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Literaturverzeichnis 

[AFST00] Appelrath, H.-J., Freese, T., Sauer, J., Teschke, T.: Strukturelle Abbildung 

von Produktionsnetzwerken auf Multiagentensysteme, erschienen in: KI, 

Künstliche Intelligenz, Heft 3/00, S. 64, arenDTaP Verlag Bremen, ISSN 

0933-1875, 2001. 50, 53 

[BB02] Webseite der Deutschen Bundesbank, http://www.bundesbank.de/ 

bargeld/euro_muenzen.php, Juli 2002. 40 

[Bro01] Bröske, S.: Ein Framework für Planungsagenten, Diplomarbeit, Fachbe- 

reich Informatik, Universität Oldenburg, 2001. 27, 34, 69, 70, 73, 74, 

97 

[Bun99] Deutsches Münzgesetz, vom 16. Dezember 1999 (BGBl. I S. 2402) 42 

[CG01] Corsten, H., Gössinger, R.: Advanced Planning Systems – Anspruch und 

Wirklichkeit, erschienen in PPS Mangament, Heft 2/01, S. 32, GITO- 

Verlag, Berlin, 2001. 24 

[Fre98] Freese, T.: Ein generisches Ablaufplanungssystem auf Basis von Cons- 

traints. Diplomarbeit, Fachbereich Informatik, Universität Oldenburg, Ol- 

denburg, 1998 80 

[FST99] Freese, T., Sauer, J., Teschke, T.: AMPA Zwischenbericht. Zwischenbe- 

richt, OFFIS, Oldenburg, 1999. 35, 36 

[DS83] Davis, R, Smith, R.G.: Negotiation as a Metaphor for Distributed Problem 

Solving. Artificial Intelligence, Vol. 20, 1983. 32 

[Hen98] Henseler, H.: Aktive Ablaufplanung mit Multi- Agenten. DISKI Band 180, 

Infix Verlag, Sankt Augustin, 1998. 8, 9, 29, 30 

[HR00] Horn, E., Reinke, T.: Musterarchitekturen und Entwicklungsmethoden 

für Multiagentensysteme. In Künstliche Intelligenz, Heft 4/00, S. 48-54, 

arenDTaP Verlag, Bremen, 2000. 

123


[HS99] Huhns, M., Stephens, L.: Multiagent Systems and Societies of Agents, er- 

schienen in [Wei99], 1999. 31, 33, 34 

[HW01] Hambörger, K., Würdemann, T.: Produktionsplanungssysteme – Konzep- 

te und Methoden. Seminarvortrag, Fachbereich BWL, Universität Olden- 

burg, Oldenburg, 2001. 17 

[Jau98] Jaudszim, I.: Mobilitätsaspekte bei Ablaufplanungssystemen, Diplomar- 

beit, Fachbereich Informatik, Universität Oldenburg, Oldenburg, 1998. 

12, 16 

[JF88] Johnson, R., Foote, B.: Designing Reusable Classes, erschienen in Journal 

of Object-Oriented Programming 1, no. 2 (1988): S. 22-35, 1988. 69 

[KS99] Kirn, S., Petsch, M. (Hrsg.): Workshop: „Intelligente Softwareagenten 

und betriebswirtschaftliche Anwendungsszenarien“. Arbeitsbericht, Tech- 

nische Universität Ilmenau, Ilmenau, 1999. 

[LFP99] Labrou, Y., Finin, T., Peng, Y.: Agent Communication Languages: The 

Current Landscape. In IEEE Intelligent Systems, March/April 1999, 

1999. 33 

[MRW00] Meyr, H., Rohde, J., Wagner, M.: Die Supply Chain Planning Matrix, er- 

schienen in: PPS Management, Heft 5/00, GITO Verlag, Berlin, 2000. 21 

[NH+94] Neimann, D., Hildum, D., Lesser, V., Sandholm, T.: Exploiting Meta- 

Level Information in a Distributed Scheduling System. Technical Report, 

University of Massachusetts at Armherst, Computer Science Department, 

Armherst, 1994. 33 

[Pru00] Prusch, T.: Eine Benutzungsoberfläche für integrierte interaktive Ablauf- 

planungssysteme im PPS-Bereich, Diplomarbeit, Fachbereich Informatik, 

Universität Oldenburg, 2000. 

[Sau93] Sauer, J.: Wissensbasiertes Lösen von Ablaufplanungsproblemen durch ex- 

plizite Heuristiken. DISKI Band 37, infix Verlag, Sankt Augustin, 1993. 

5, 7 

[Sau01a] Sauer, J: AI in planning, scheduling, configuration and design, Procee- 

124 

dings of the KI-2001 Workshop W1 ; zugleich 15. Workshop ,Planen, 

Scheduling, Konfigurieren und Entwerfen’, PuK 2001, Wien 18. 9. 2001, 

Wien, 2001


[Sau01b] Sauer, J: Modelling and solving multi-site scheduling problems, to appear 

in: Jorna, R.: Planning and Intelligence, Wiley, 2001 

[Sau01c] Sauer, J: Koordinierte Ablaufplanung auf mehreren Ebenen, in: KI, Künst- 

liche Intelligenz, Heft 2/01, S. 18-24, arenDTaP Verlag Bremen, ISSN 

0933-1875, 2001. 

[Sau01d] Sauer, J.: Multi-Site Scheduling. Arbeitstitel, Habilitationsvorhaben, Fach- 

bereich Informatik, Universität Oldenburg, Oldenburg, 2001. 5, 9, 11, 14, 

90 

[Sau02] Sauer, J., Appelrath, H.-J.: Scheduling the Supply Chain by Teams Of 

Agents. Projektvorhaben, Universtität Oldenburg, Oldenburg, 2002. 16, 

20, 47 

[Sch95] Schierenbeck, H.: Grundzüge der Betriebswirtschaftslehre. R. Olden- 

bourg Verlag, München, 1995. 

[Sch98] Schönsleben, P.: Integrales Logistikmanagement: Planung und Steuerung 

von umfassenden Geschäftsprozessen. Springer Verlag, Berlin, Heidel- 

berg, 1998. 19 

[Sch01] Schneidewind, U.: Folien zur Vorlesung Produktionsmanagement I. Fach- 

bereich BWL, Universität Oldenburg, Oldenburg, 2001. 18 

[SK01] Stadtler, H., Kilger, C. (Editors): Supply Chain Management and Advan- 

ced Planning. Springer Verlag, Berlin, Heidelberg 2001. 51 

[SL95] Sandholm, T., Lesser, V.: Issues in Automated Negotiation and Electro- 

nic Commerce: Extending the Contract Net Framework. Technical Report, 

University of Massachusetts at Armherst, Computer Science Department, 

Armherst, 1995. 32 

[Swi02] Webseite der Swissmint AG, http://www.swissmint.ch/d/ 

numismatik/fliessbild.shtml, Juli 2002. 42 

[Wei99] Weiss, G. (Hrsg.): Multiagent Systems. Massachusetts Institute of Techno- 

logy, Massachusetts (USA), 1999. 124, 126 

[WJ95] Wooldridge, M., Jennings, N. R.: Intelligent Agents: Theory and Practice. 

Knowledge Engineering Review, 10 (2), 1995. 26 

125


[Woo99] Wooldridge, M: Intelligent Agents, erschienen in [Wei99], 1999. 25, 26, 

27 

[Zae01] Zäpfel, G.: Bausteine und Architekturen von Supply Chain Management- 

126 

Systemen, erschienen in: PPS Management, Heft 6/01, S. 9, GITO-Verlag, 

Berlin, 2001. 21

Danksagung 

An dieser Stelle möchte ich mich bei allen bedanken, die mich bei der Verfassung dieser 

Diplomarbeit unterstützt haben. 

Insbesondere danke ich meinen Eltern und meinem Bruder, die mich während des gesam- 

ten Studiums über begleitet haben. Ohne die mir entgegen gebrachte Toleranz sowie die 

moralischen und finanziellen Hilfen wäre diese Arbeit nicht entstanden. 

Priv.-Doz. Dr. Jürgen Sauer danke ich für seine sympathische und kompetente Betreuung. 

Durch seine Anregungen und viele konstruktive Diskussionen hat er erheblich zum Ge- 

lingen dieser Arbeit beigetragen. 

Ralf BeXXX Beckers, Frank Bodmann, Bernd Kuper, Martin Sparenberg und Thorsten 

Würdemann danke ich für das Korrekturlesen und zahlreiche kritische und produktive 

Vorschläge. Franks umfassende Java � -Kenntnisse haben mir bei die Implementierung 

betreffenden Fragen die Recherche erheblich erleichtert. BeXXX hat ein gutes Werk ge- 

tan, indem er mich davon überzeugt hat, diese Arbeit mit LATEX zu erstellen. 

Meiner Verlobten Sita Unbehaun danke ich dafür, dass sie während der Diplomarbeit mich 

und meine häufige Abwesenheit geduldvoll ertragen hat. Ihre moralische Unterstützung 

war eine große Hilfe. 

Allen meinen Freunden (Buero & Co) danke ich für die nette Abwechslung und Ablen- 

kung während des gesamten Studiums. 

127

Danksagung 

128

Erklärung 

Ich versichere, dass ich diese Diplomarbeit selbstständig verfasst und keine anderen als 

die angegebenen Hilfsmittel verwendet habe. 

Oldenburg, 11. Oktober 2002

Supply Chain Scheduling mit Teams von Agenten

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?