Simulationsmodelle mit Bflow und DesmoJ

TH Wildau IM11, WS 2012/13 Simulationsmodelle mit Bflow und DesmoJ Belegarbeit für das Modul Simulation II Christian Schmidt, Jan Druschke 11.01.2013

Inhaltsverzeichnis 1 Einleitung... 1 2 Verwendete Frameworks, Programme und Bilddateien... 3 3 Modellierung und Generierung des ersten Simulationsmodells... 4 3.1 Die model.epc... 4 3.2 Die Schiff-Prozesse... 7 3.2.1 EPK der Schiff-Prozesse... 7 3.2.2 Codeerweiterungen der Information-Klasse Containerlieferung... 9 3.3 Die LKW-Prozesse... 10 3.4 Die Trigger-Prozesse <Gezeiten> und <Sonntagsfahrverbot>... 11 3.4.1 EPK des Gezeiten-Prozesses... 11 3.4.2 EPK des Sonntagsfahrverbot-Prozesses... 12 3.4.3 Codeerweiterungen für den Trigger <Sonntagsfahrverbot>... 13 3.5 Das Process Interface <Stocks>... 13 3.5.1 EPK des Process Interface <Stocks>... 13 3.5.2 Codeerweiterungen der Information-Klasse Stocks... 16 3.5.3 Codeerweiterungen in der Model-Klasse... 16 3.5.4 Codeerweiterungen in den Stocks... 18 3.6 Statistische Elemente... 21 4 Erweiterungen im zweiten Simulationsmodell... 22 4.1 Erweiterungen in model.epc... 22 4.2 Erweiterung um einen Zug-Prozess... 23 4.3 Erweiterung der LKW-Prozesse... 24 4.4 Erweiterung der Schiff-Prozesse... 25 4.5 Erweiterung um eine Werkstatt... 25 4.6 Erweiterung im Process Interface <Stocks>... 27 5 Fazit... 29 I

1 Einleitung Die zwei Simulationsmodelle in dieser Belegarbeit veranschaulichen vereinfacht die Vorgänge in einem Hafen-Containerterminal. Beide Beispiele sind relativ komplex, wobei das zweite Beispiel auf dem ersten aufbaut. Das Modellieren, also das Anlegen der epc-dateien, wird mit der BFlow-Toolbox (+ Validator Add-on) durchgeführt. Um eine lauffähige Simulation auf Basis des JAVA Frameworks DESMO-J zu erhalten, werden danach die.epc-dateien mit dem Generator Add-on in Java- Klassen umgewandelt. Zum Schluss sind (bei Bedarf) noch einige Codeerweiterungen notwendig. In diesem Tutorial werden alle.epc-dateien einzeln beschrieben und parallel deren spätere Ansicht in der Animationsumgebung (dem Viewer) dargestellt. An den entsprechenden Stellen werden zusätzlich die Codeerweiterungen erklärt. 1

Bei den Attributen zu den.epc-dateien wurden aus Platzgründen nur die wichtigsten ausgewählt und aufgelistet. Die vollständige Liste ist bei Bedarf bitte den originalen.epc- Dateien (Anhang) zu entnehmen. Bei der Entwicklung eines Simulationsmodells in Anlehnung an die hier vorliegende Arbeit, wird empfohlen (anders geht es auch nicht) zuerst alle.epc-dateien zu erstellen, zu validieren und im Anschluss zu generieren. Ganz am Ende werden die Codeerweiterungen dann implementiert. Es soll das wesentliche Verständnis dafür entwickelt werden, wie aus den EPKs (eine model.ecp + mehrere process.epc s) die Java-Klassen entstehen und wo die entsprechenden Stellen zu finden sind, an denen Codeimplementierungen durchgeführt werden müssen. Erklärung der Simulationsmodelle Es werden zwei lauffähige Simulationsmodelle erstellt, um die Abläufe in einem Containerterminal zu simulieren. Folgender Sachverhalt soll dabei berücksichtigt werden: Erstes Simulationsmodell: Schiffe legen in entsprechenden Abständen (EXPO, 24 h) im Hafen des Terminals an. Sie haben jeweils eine Lieferung an Containern geladen (zwischen 20 und 100), die im Terminal in drei unterschiedlichen Stocks gelagert werden sollen. In welchen der drei Stocks die Container abgeladen werden, bestimmt die jeweilige Lieferung des Schiffes. In gewissen Abständen (UNIFORM, 5 bis 60 min) erreichen LKW das Terminal und holen jeweils einen Container aus einem Stock ab. Dabei wird vom LKW immer der momentan vollste Stock angefahren. Das Ausladen der Container von den Schiffen übernehmen zwei Schiffskräne, das Einladen der LKW zwei LKW-Kräne. An Sonntagen sollen keine LKW im Terminal eintreffen bzw. abfahren (Sonntagsfahrverbot!). Schiffe können täglich das Terminal erreichen und verlassen. An-und Abfahren können sie aber nur bei Flut. Sie müssen jeweils warten, falls in der entsprechenden Zeit Ebbe herrscht. Die Gezeiten sollen einfach im 6- Stunden-Takt simuliert werden. 2

Erweiterung im zweiten Simulationsmodell: Im zweiten Beispiel wird das Simulationsmodell um eine Werkstatt erweitert, in der LKW und Schiffe repariert werden können. Dabei sind für Schiffe und LKW jeweils kleine oder große Reparaturen zu unterscheiden (20% zu 80%). Zwei neue Mechaniker-Ressourcen für LKW und Schiffe führen die Reparaturen durch (in Wirklichkeit natürlich mehr). Zudem wird ein Güterzug an das Terminal angebunden. Dieser Zug erreicht das Terminal in gewissen Abständen (zweimal in der Woche), um den vollsten der drei Stocks komplett zu leeren. Des Weiteren müssen nun nicht mehr alle LKW sonntags warten, sondern nur noch 90%. Die restlichen 10% sind Sondertransporte und dürfen immer aus dem Terminal abfahren. 2 Verwendete Frameworks, Programme und Bilddateien In den vorliegenden Beispielen wurden folgende Versionen der Programme und Frameworks verwendet: Programm/ Framework Bflow Validator und Generator DESMOJ SimTools Version des JARs bflow-1.2.4-win32.zip EpcSimGeneratorShell_20121109.jar desmoj-2.3.5beta-complete-bin.jar EpcSimTools_20130107.jar Folgende Bilddateien wurden für die Simulation verwendet und müssen im Ordner Icons (\[Workspace]\[Projectname]\model_data\[Projectname]\Icons) liegen. 3

3 Modellierung und Generierung des ersten Simulationsmodells Beide Simulationsmodelle dieser Belegarbeit beinhalteten verschiedene Komponenten aus der Bflow-Toolbox, wie Trigger-, Process Interface, File- und Document-Objekte. Die einzelnen Informations-Objekte erleichtern später die Codeerweiterungen und müssen zuerst in der Modell-Datei (model.epc) definiert werden. Die untere Grafik zeigt den Projektordner mit allen.epc-dateien des ersten Beispiels. 3.1 Die model.epc Die Modell-Datei (CT_Model.epc) beschreibt alle Rahmenbedingungen eines Simulationsmodells. In der folgenden Tabelle sind die im ersten Modell verwendeten Komponenten mit den wichtigsten Attributen dargestellt und beschrieben. Die Werte für die Verteilung der Ankunfts-, Warte-, und Bedienzeiten wurden frei erfunden und sollen nur beispielhaft dienen. Document Die Containerlieferung wird als Document-Objekt modelliert. Ein Document-(Information)-Objekt ist immer an einen anderen Prozess, hier an jeden Schiff-Prozess, gebunden. Jedes Mal wenn ein neues Schiff erzeugt wird, wird auch eine neue Containerlieferung erzeugt. Nach der Generierung wird daraus eine Java-Klasse. Sie enthält später die Informationen einer Containerlieferung, wie Anzahl und Ziel der Container, die ein Schiff in den Hafen transportiert. Das Attribut InformationType ist auf den Wert Information zu setzten! File Ein File-(Information)-Objekt dient als Speicherort der gelieferten Container im Terminal. Im Unterschied zu Document- Objekten sind diese nicht an bestimmte Prozesse gebunden. Ein File existiert einmal pro Simulationsmodell und wird später in der Java-Modell-Datei angelegt. Das Attribut InformationType ist ebenfalls auf den Wert Information zu setzten! 4

Trigger Trigger haben einen bestimmten Zustand während der Simulation. Sie können gesetzt oder nicht-gesetzt sein (Set/ Unset). Trigger dienen dazu, in bestimmten Warteschlangen (Funktionen) die mit dem Trigger verbunden sind, das Signal zum Halt oder zum Los zu geben. Solange der Trigger nicht gesetzt ist (Unset), müssen die Prozesse in der Warteschlange (Funktion) warten. Sobald er gesetzt wird (Set), passieren die Prozesse jene Stelle. Zu Beginn der Simulation ist ein Trigger immer standartmäßig deaktiviert. Für das Simulationsmodell benötigen wir zwei Trigger. Einen für die Gezeiten, damit die Schiffe bei Ebbe warten und einen für das Sonntagsfahrverbot damit die LKW sonntags warten. Bei den Attributen sind die entsprechenden Bilddateien anzugeben und der InformationType ist auf Trigger zu setzten. Hier z.b. der <Ebbe-Flut>-Trigger: Master Entities/ SimProzesse Die Master Entities (aktive SimProzesse) in diesem Simulationsmodell sind Schiffe und LKW. Sie machen aktiv etwas, nämlich Container bringen und abholen. Für sie wird jeweils ein eigenes Process Interface mit den entsprechenden EPKs angelegt. Die wichtigsten Attribute in der Modell-Datei sind für die Schiffe: Und für die LKW: Schiffe treffen exponentialverteilt mit 24 Stunden und LKW normalverteilt alle 5 bis 60 Minuten (außer sonntags) im Terminal ein. 5

Prozesse für die Trigger Damit die zwei Trigger ihren Zustand (set oder unset) während der Simulation ändern, ist für jeden Trigger ein separates Process Interface notwendig. Zu beachten ist, dass bei den zwei PersonTypes (<Gezeiten> und <Sonntagsfahrverbot>) das Attribut Quantity hinzugefügt und auf 1 gesetzt werden muss! Damit der Prozess <Sonntagsfahrverbot> auch am ersten Sonntag um 0:00 Uhr startet, sind noch folgende Attribute nötig: Slave Entities/ Resourcen Die bedienenden Prozesse, also die Ressourcen oder auch Slave Entities genannt, (in Bflow Participants) sind zwei Kran-Typen, Schiffskräne und der LKW-Kräne. Diese arbeiten, die ganze Woche über 24 Stunden am Tag. Und es gibt jeweils zwei Stück davon: Da ein kompletter Monat ab dem 01.01.2013 um 00:00 Uhr simuliert werden soll, sind die folgenden Modell-Attribute unbedingt noch anzugeben: 6

In der nachfolgenden Abbildung ist die gesamte model.epc mit allen verwendeten Elementen dargestellt. Gut zu erkennen ist die Verbindung der Containerlieferung mit dem Schiffprozess. 3.2 Die Schiff-Prozesse 3.2.1 EPK der Schiff-Prozesse Die EPK beschreibt den Ablauf eines Schiff-Prozesses im Simulationssystem. Besondere Aufmerksamkeit sei hier auf die zwei Funktionen <Warten bei Ebbe>, vor und hinter dem Process Interface, gerichtet. Gut zu erkennen ist der Trigger <Ebbe-Flut>, der mit diesen Funktionen verbunden ist. Er beeinflusst ob ein Schiff warten muss (bei Ebbe) oder nicht (bei Flut), bevor es in die Stocks fahren bzw. aus dem Terminal abfahren kann. Das Abladen der Container im Terminal wird in dem separaten Process Interface <Stocks> modelliert. Nachfolgend ist die EPK des Schiff-Prozesses mit den entscheidenden Eintragungen für die Attribute abgebildet. 7

In den unteren zwei Abbildungen ist die Viewer-Ansicht der LKW-EPK nach der Generierung zu sehen. Im ersten Bild ist gerade Flut (Symbol: Wellen). Das heißt, kein Schiff muss warten. Im zweiten Bild ist die Ebbe dargestellt (Symbol: Sonne). Zum jetzigen Zeitpunkt können die Schiffe weder hinein ins Terminal, noch hinaus aus dem Terminal. Zu jedem Schiff-Prozess gehört eine eigene Containerlieferung, in der die Anzahl und das Ziel der Container definiert sind. Das wird mit dem Anbinden des Document-Objektes <Containerlieferung> in der model.epc realisiert. Nach dem Generieren wird daraus die Java- Klasse Information_Containerlieferung.java. Diese muss dann um die genannten Angaben (Anzahl, Ziel) erweitert werden, was im Folgenden beschrieben wird. 8

3.2.2 Codeerweiterungen der Information-Klasse Containerlieferung Beim Generieren des Modells wird aus dem Document-Objekt <Containerlieferung> die Java-Klasse Containerlieferung.java erzeugt. Jeder Schiff-Prozess (Master_Schiff.java) bekommt eine eigene Instanz dieser Containerlieferung (im Konstruktor) zugewiesen. Anzahl und Ziel (Stock 1, 2 oder 3) der Container werden jeweils in einer einfachen int- Variable gespeichert. Diese werden erst deklariert und im Konstruktor zugewiesen. Um dabei eine Normalverteilung bei der Anzahl der Container zu ermöglichen, ist der Import der DESMO-J-Klasse DiscreteDistUniform notwendig. //@@_begin of import individual code import desmoj.core.dist.discretedistuniform; //@@_end of import individual code Variablen deklarieren: //@@_begin of declaration individual code public int ziel; public int anzcont; //@@_end of declaration individual code Zufallswerte im Konstruktor erzeugen (für Ziel 0-2 sowie für Anzahl 20-100) und den Variablen zuweisen: //@@_begin of constructor individual code ziel = new DiscreteDistUniform(model, "Ziel", 0, 2, false, false).sample().intvalue(); anzcont = new DiscreteDistUniform(model, "Anzahl ", 20, 100, false, false).sample().intvalue(); //@@_end of constructor individual code Bemerkung: Die drei Stocks werden später als Array (mit drei Elementen) angelegt. Daher wird an dieser Stelle die Wahrscheinlichkeit des Ziels von 0 bis 2 normalverteilt. 9

3.3 Die LKW-Prozesse EPK der LKW-Prozesse Ein LKW kommt imterminal an und fährt direkt in die Stocks um einen Container aufzuladen. Nachdem er aus dem Stock fährt, muss er im Falle eines Sonntags warten. Zur Gegenüberstellung ist nachfolgend wieder abgebildet, wie das Ganze später nach der Generierung im Viewer aussieht. Im ersten Fall ist Sonntag und die LKW müssen in der Warteschlange ausharren (Symbol: Durchfahrt verboten). Im zweiten Fall ist ein beliebiger anderer Wochentag dargestellt. Die LKW dürfen passieren und das Terminal verlassen (Symbol: grüne Ampel). Codeerweiterungen sind bei den generierten LKW-Klassen nicht notwendig. 10

3.4 Die Trigger-Prozesse <Gezeiten> und <Sonntagsfahrverbot> 3.4.1 EPK des Gezeiten-Prozesses In der EPK für die Gezeiten wird der Trigger jeweils im Wechsel von 6 Stunden auf Ebbe und Flut, also das Attribut Trigger auf Set oder Unset, gesetzt (siehe untere Grafik). Die Funktion <Prüfen> hat keine Bedeutung für die Simulation, sondern wurde nur wegen den EPK-Konventionen eingefügt. Nach der Generierung wird der Trigger-Prozess wie folgt im Viewer dargestellt (links Flut, rechts Ebbe). 11

3.4.2 EPK des Sonntagsfahrverbot-Prozesses Gestartet wird dieser Trigger-Prozess nur ein mal. Und zwar startet er am ersten Sonntag um 0:00 Uhr (und eine Nanosekunde), wie oben in der model.epc angegeben. Zuerst wird der Trigger in der Methode <Trigger deaktivieren> deaktiviert (Unset), damit die LKW warten. Das setzt natürlich voraus, dass er bereits zu Anfang der Simulation aktiviert (Set) sein muss. Darum kümmern wir uns aber erst später bei den Codeerweiterungen. Die Methoden <Trigger deaktivieren> und <Trigger aktivieren> dauern jeweils nur eine Nanosekunde (quasi nichts). Dazwischen wird 24 Stunden, bzw. 6 Tage, gewartet. Nachfolgend sind beide Zustände des Triggers im Viewer dargestellt. Auf der linken Seite ist kein Sonntag (also: Freie Fahrt!) und auf der rechten Seite ist Sonntag (also: Warten!). 12

3.4.3 Codeerweiterungen für den Trigger <Sonntagsfahrverbot> Jede Trigger-Klasse (z.b. Trigger_Sonntagsfahrverbot.java) verfügt, neben dem Konstruktor, unter anderem über die Methoden settrigger() und unsettrigger() zum Aktivieren bzw. Deaktivieren des Triggers. Ein Trigger wird in der Modell-Klasse in der Methode initanimation() durch Aufrufen des Konstruktors des Triggers erzeugt. Ebenfalls wird in der initanimation()-methode der Trigger durch Aufruf von unsettrigger() deaktiviert. Um den Trigger zu Beginn auf true zu setzten, muss die Methode settrigger() in der Modell-Klasse (CT_Model.java) aufgerufen werden. Hierfür gibt es zwei Möglichkeiten. Entweder wird im Individualcode-Abschnitt der Methode doinitialschedules() oder in der Methode initanimation() der Aufruf initialisiert. Der folgende Codeabschnitt zeigt die Anpassung in doinitialschedules(). //@@_begin of doschedule individual code trigger_id_113_application_sonntagsfahrverbot.settrigger(); //@@_end of doschedule individual code 3.5 Das Process Interface <Stocks> 3.5.1 EPK des Process Interface <Stocks> Im ersten Beispiel können nur LKW und Schiffe in die Stocks fahren, um dort ihre Tätigkeiten (Container aus- bzw. einladen) zu verrichten. Unterstützt werden sie dabei von den vorher festgelegten Ressourcen/ Participants. Zuerst werden die wichtigsten Attribute aufgeführt und nachfolgend die EPK erläutert. Die Stellen der Attribute sind in der EPK mit roten Buchstaben markiert. a) Erstes XOR (Entscheidung welches Fahrzeug eingetroffen ist) 13

b) Zweites XOR (Entscheidung des LKW welcher Stock am vollsten ist) c) Drittes XOR (Entscheidung des Schiffes welches Ziel die Container haben) d) File <Stocks> an XOR e) Document <Containerlieferung> an XOR: f) File <Stocks> an den Funktionen Ausladen und Einladen (hier nur beispielhaft Stock I) g) Funktionen für das Ausladen der Schiffe in die jeweiligen Stocks h) Funktionen für das Einladen der LKW aus den jeweiligen Stocks 14

Die EPK der Stocks (siehe folgende Grafik) sieht auf den ersten Blick etwas verwirrend aus, ist sie aber gar nicht. In der oberen Hälfte ist das Ausladen der Schiffe und in der unteren das Einladen der LKW, jeweils mit den entsprechenden Ressourcen/Participants (Schiffskran, LKWkran), dargestellt. In der Mitte befinden sich die drei Stocks, repräsentiert durch das File-Objekt, das jeweils mit den Funktionen (Ausladen beim Schiff und Einladen beim LKW) verbunden ist. Die Trennung der drei Stocks erfolgt erst später bei den Codeerweiterungen. Auch die Unterscheidung, welches Fahrzeug gerade in die Stocks gefahren ist, sowie die Vorgänge des Ausladens und Einladens müssen als Java-Code implementiert werden. In der Simulation sieht dann später das Process Interface folgendermaßen aus: Anmerkung: Die drei Zähler (Counter) in der Mitte, sowie die farblich hinterlegten Vierecke (Backgroundelemente), wurden nachträglich als Codeerweiterung hinzugefügt. (siehe 3.5.3 Codeerweiterungen in Model-Klasse) 15

3.5.2 Codeerweiterungen der Information-Klasse Stocks Die Information-Klasse (Information_Stocks.java) dient als Speicherort der Container. Diese Java-Klasse wird aus dem File-Objekt <Stocks> beim Generieren erzeugt. Es werden zwei int- Arrays angelegt. Damit die Stocks bei Simulationsbeginn nicht komplett leer sind, gibt es ein Array dem Initialisieren der Stockkapazität mit drei festen (final) Werten (50, 80, 100). Das zweite Array nimmt später im Simulationsablauf die Containerkapazitäten auf. //@@_begin of declaration individual code public final int[] INIT_KAP_STOCK = {50,80,100}; public int[] actualkapstock = {0,0,0}; //@@_end of declaration individual code Im Konstruktor der Information_Stocks.java werden die Initialwerte der drei Stocks den anfänglichen Kapazitäten zugewiesen. //@@_begin of constructor individual code for (int i=0; i<actualkapstock.length; i++) { actualkapstock[i] = INIT_KAP_STOCK[i]; } //@@_end of constructor individual code 3.5.3 Codeerweiterungen in der Model-Klasse Anmerkung: In der Model-Klasse (CT_Model.java) wird beim Generieren automatisch der Speicher für die Container angelegt. Das ist unser ursprüngliches File-Objekt <Stocks>, repräsentiert durch die Klasse Information_Stocks.java mit entsprechender Zugriffsmethode: public Information_Stocks getinformation_id_66_file_stocks() { return information_id_66_file_stocks; } Über die Model-Klasse ist dieser Speicher dann von überall im System erreichbar und ansprechbar. 16

Es müssen noch die Counter und Backgroundelemente, wie vorher angesprochen, angelegt werden. Folgende Importe sind dazu notwendig: //@@_begin of import individual code import desmoj.extensions.visualization2d.animation.form; import desmoj.extensions.visualization2d.animation.core.statistic.countanimation; import desmoj.extensions.visualization2d.animation.backgroundelementanimation; import desmoj.extensions.visualization2d.engine.model.backgroundelement; import java.awt.color; //@@_end of import individual code Anlegen der Animationskomponenten Counter und Backgroundelemente im Deklarationsteil: //@@_begin of declaration individual code //--- Animations-Komponenten //Counter zum Darstellen der aktuellen Containeranzahl in den Stocks public CountAnimation[] containerinstock = null; public BackgroundElementAnimation[] bckgrndstock = null; //@@_end of declaration individual code Im Animationsteil (Methode initanimation) werden die Counter und Backgroundelemente initiiert, damit sie im Viewer an der richtigen Position stehen. Auf die Beschreibung wird an dieser Stelle verzichtet. //@@_begin of initanimation individual code //Drei Counter anlegen um Kapazitäten der Stocks darzustellen containerinstock = new CountAnimation[3]; //Drei Backgroundelemente anlegen bckgrndstock = new BackgroundElementAnimation[3]; for (int i = 0; i < 3; i++){ containerinstock[i] = new CountAnimation( this, "Stock"+(i+1), this.reportison(), this.traceison()); containerinstock[i].createanimation(new Position("/Tutoriale/ContainerTerminal_NEU/Stocks.epc", i*285+(150),460), new Form(), this.animationison()); bckgrndstock[i] = new BackgroundElementAnimation(this, "Stock"+(i), null, "Stock "+(i+1), BackgroundElement.TEXT_POSITION_MiddleLeft, BackgroundElement.TEXT_Size_Big, BackgroundElement.TEXT_Style_Bold, new Position("/Tutoriale/ContainerTerminal_NEU/Stocks.epc",i*285+(50),380), new Position("/Tutoriale/ContainerTerminal_NEU/Stocks.epc",i*285+(250),550), 9, new Color(25,25,112), new Color(220,220,220), this.animationison()); } //@@_end of initanimation individual code 17

3.5.4 Codeerweiterungen in den Stocks Wichtige Anmerkung: Um in dem generierten Java-Code die entsprechenden Stellen (Methoden) zu finden, an denen die Erweiterungen hinzugefügt werden müssen, sollte man sich an den IDs der jeweiligen EPK-Elemente orientieren. Oder man verfasst eigene Kommentare. Diese treten später im generierten Code an entsprechender Stelle auch wieder auf. Man findet die jeweiligen Einträge für IDs und Kommentare in den Attributen. Beispiel: Die oberste XOR-Verknüpfung, dort wo die Containerlieferung verbunden ist und die Entscheidung über das Anfahren der drei Stocks getroffen wird, habe folgende ID: Und in der Containerlieferung ist beispielsweise folgende Beschreibung hinterlegt: Dann wird daraus die folgende Methode generiert: (...) } Bei Funktionen wird nach dem Generieren hinter die ID noch der vergebene Funktionsname angehängt. Als Übergabewert bekommen die Methoden immer mindestens den EpcProcess übergeben, der bei Bedarf auf die entsprechende Master-Entity-Klasse gecastet werden muss (z.b. Master_Schiff). In den folgenden Codebeispielen sind die Werte der IDs zu ignorieren, da sie dynamisch vom Validator vergeben werden und somit später abweichen können. In der folgenden Grafik sind alle Stellen rot umkreist, an denen Codeerweiterungen nötig sind. Das sieht auf den ersten Blick sehr viel aus, aber die 9 Markierungen sind eigentlich prinzipiell nur 5. Für das Ein- und Ausladen vollziehen sich die Anpassungen jeweils drei Mal analog, entsprechend angepasst an drei Stocks. Die Java-Codeerweiterungen sind in der Datei Epc_Stocks.java durch zu führen. 18

1) XOR- Entscheidung Prüfen welches Fahrzeug im Stock angekommen ist Je nachdem von welcher Instanz der übergebene EpcProzess ist (Master_LKW oder Master_Schiff), wird dem Event true oder false zugewiesen. //@@_begin of individual code for this method decision_id_24_event_lkw_trifft_ein = proc instanceof Master_LKW? true : false; decision_id_23_event_schiff_trifft_ein = proc instanceof Master_Schiff? true : false; //@@_end of individual code for this method 2) XOR Entscheidung des Schiffes Nachschauen welches Ziel die geladenen Container haben Zuerst wird der übergebene EpcProzess auf Master_Schiff gecastet um an die Containerlieferung heranzukommen. Dort wird nach dem Ziel der Container geschaut und dem entsprechenden Event true oder false zugewiesen. //@@_begin of individual code for this method //Schiff aus EpcProcess holen Master_Schiff schiff = (Master_Schiff)proc; //Fall 1: Ziel der Container im Schiff ist Stock 1 decision_id_34_event_ziel_schiff_stock1 = schiff.getinformation_id_72_document_containerlieferung().ziel == 0? true : false; //Fall 2: Ziel der Container im Schiff ist Stock 2 decision_id_33_event_ziel_schiff_stock2 = schiff.getinformation_id_72_document_containerlieferung().ziel == 1? true : false; //Fall 3: Ziel der Container im Schiff ist Stock 3 decision_id_35_event_ziel_schiff_stock3 = schiff.getinformation_id_72_document_containerlieferung().ziel == 2? true : false; //@@_end of individual code for this method 19

3) XOR-Entscheidung des LKW Den vollsten Stock suchen Es wird die aktuelle Kapazität der drei Stocks verglichen und dem Event mit dem vollsten Stock true zugewiesen. //@@_begin of individual code for this method int size1 = model.getinformation_id_66_file_stocks().actualkapstock[0]; int size2 = model.getinformation_id_66_file_stocks().actualkapstock[1]; int size3 = model.getinformation_id_66_file_stocks().actualkapstock[2]; //Fall: Alle Stocks leer if (size1<=0&&size2<=0&&size3<=0) { System.out.println("LKW: Stock ist leer!!!!"); } //Fall: Stock 1 am vollsten else if ((size1 >= size2) && (size1 >= size3)) { decision_id_30_event_ziel_lkw_stock1 = true; } //Fall: Stock 2 am vollsten else if ((size2 >= size1) && (size2 >= size3)) { decision_id_31_event_ziel_lkw_stock2 = true; } //Fall: Stock 3 am vollsten else { decision_id_32_event_ziel_lkw_stock3 = true; } //@@_end of individual code for this method 4) Funktionen Ausladen in jeweiligen Stock (hier beispielhaft für Stock 1) Die Container werden aus dem Schiff in den entsprechenden Stock ausgeladen Es wird zuerst der übergebene EpcProzess auf Master_Schiff gecastet um in die Containerlieferung zu schauen. Die Anzahl der Container wird dann auf die aktuelle Stockkapazität dazu addiert. Hier auf actualkapstock[0] für den Stock 1. Auch der Counter wird angepasst. //@@_begin of individual code for this method Master_Schiff schiff = (Master_Schiff)proc; int contsfromship = schiff.getinformation_id_72_document_containerlieferung().anzcont; model.getinformation_id_66_file_stocks().actualkapstock[0] += contsfromship; model.containerinstock[0].update(contsfromship); //@@_end of individual code for this method 5) Funktionen Einladen aus jeweiligen Stock (hier beispielhaft für Stock1) Der LKW holt einen Container aus dem entsprechenden Stock Die Kapazität des entsprechenden Stocks wird um 1 verringert und der Counter um 1 herunter gezählt. //@@_begin of individual code for this method model.getinformation_id_66_file_stocks().actualkapstock[0] --; model.containerinstock[0].update(-1); //@@_end of individual code for this method 20

3.6 Statistische Elemente Es gibt bereits eine Auswahl an implementierten grafischen Elementen zur statistischen Auswertung (Zeitreihen und Histogramme). Soll beispielsweise die Auslastung der LKW- Kräne in einer Grafik dargestellt werden, müssen folgende Attribute in der model.epc beim PersonType für den LKW-Kran angegeben werden: Histogram TimeSeries_ScatterPlot TimeSeries_LineChart TimeSeries_StepChart An den drei verschiedenen Arten der Zeitreihen (TimeSeries) ist deutlich zu erkennen, dass alle 7 Tage (an den Sonntagen) ein Fahrverbot für LKW herrscht und damit auch die Auslastung der LKW-Kräne zurück geht (oder eben 0 ist). 21

4 Erweiterungen im zweiten Simulationsmodell Nachfolgend sind alle.epc Dateien des zweiten Beispiels dargestellt. Es sind im Vergleich zur Vorversion die zwei Dateien Güterzug.epc und Werkstatt.epc hinzugekommen. 4.1 Erweiterungen in model.epc In der unteren Abbildung ist die model.epc des zweiten Beispiels abgebildet. Auf der rechten Seite sind die neuen Elemente zu erkennen. Ein Zug-Prozess, zwei Mechaniker und ein neuer Kran sind hinzugekommen. 22

Der Güterzug erreicht am Montag und Donnerstag das Terminal um Container aufzuladen. Folgende Attribute sind für den Zug zu beachten: Die neuen Ressourcen/Participants arbeiten 24 Stunden, 7 Tage die Woche. Da LKW häufiger ankommen und repariert werden müssen, gibt es zwei LKW-Mechaniker einen lediglich einen Schiffsmechaniker. 4.2 Erweiterung um einen Zug-Prozess Der Güterzug kann nun ebenfalls in die Stocks fahren und Container aufladen. In den folgenden zwei Abbildungen sind die EPK des Zug-Prozesses sowie die spätere Ansicht im Animation-Viewer dargestellt. 23

4.3 Erweiterung der LKW-Prozesse Der LKW-Prozess wird nun um die mögliche Nutzung einer Werkstatt (in 10% der Fälle) erweitert. Außerdem dürfen einige LKW auch sonntags abfahren (ebenfalls 10% der Fälle). Mögliche Reparaturen werden getätigt, bevor der LKW in den Stock fährt. Nachfolgend sind die modifizierte EPK der LKW-Prozesse und die Viewer-Ansicht abgebildet: 24

4.4 Erweiterung der Schiff-Prozesse Auch ein Schiff kann nun mögliche Reparaturen in der Werkstatt durchführen lassen (in 20% der Fälle), nachdem es die Container abgeladen hat. Auf die Abbildung der Attribute wird an dieser Stelle verzichtet (siehe LKW-Prozess). 4.5 Erweiterung um eine Werkstatt Um Reparaturen durchführen zu lassen können LKW und Schiffe in die Werkstatt fahren. Für beide Prozesse können große Schäden zu 20% und ein kleine Schäden zu 80% auftreten. 25

26

Als Codeerweiterung in der Epc_Werkstatt.java muss analog zu den Stocks das eintreffende Fahrzeug (LKW oder Schiff) geprüft werden. 4.6 Erweiterung im Process Interface <Stocks> Wie in der EPK des Zug-Prozesses modelliert, können diese nun ebenfalls in die Stocks fahren und Container abholen. Dieser Fall muss auch in dem EPK der Stocks angepasst werden, wie im unteren Bereich der Grafik zu sehen. Die Methode <Einladen aller Container eines Stocks> ist hinzugekommen und muss bei den Codeerweiterungen ebenfalls angepasst werden. 27

Codeerweiterungen in der Zug-Methode <Einladen aller Container eines Stocks> In der Methode werden zuerst die Kapazitäten der Stocks verglichen. Der vollste Stock wird daraufhin geleert und auch der Counter wieder angepasst (zurückgesetzt). Anmerkung: Es kann der Fall auftreten, dass ein Zug gerade alle Container eines Stocks geleert hat aber gleichzeitig noch LKW im selben Stock auf die Bedienung warten oder gerade selbst einen Container aufladen. Es würde dann zu negativen Beständen oder Fehlern kommen. Deshalb wird in der ProcessStation, bzw. WaitingQueue des entsprechenden Stocks, nachgeschaut ob dort LKW vorhanden sind. Sollten LKW warten oder gerade selbst bedient werden, so lässt der Zug einfach die entsprechende Anzahl Container (waitinglkw) im Stock. //@@_begin of individual code for this method int size1 = model.getinformation_id_144_file_stocks().actualkapstock[0]; int size2 = model.getinformation_id_144_file_stocks().actualkapstock[1]; int size3 = model.getinformation_id_144_file_stocks().actualkapstock[2]; int waitinglkw = 0; if (size1<=0&&size2<=0&&size3<=0) {System.out.println("ZUG"+((Master_Zug)proc).getIdentNumber()+": Alle Stocks leer!!!!");} else if ((size1 >= size2) && (size1 >= size3)){ //Wartende LKW in Stock1 waitinglkw = Logic_Stocks.wtq_id_184_Function_Einladen_aus_Stock1.length() +Logic_Stocks.processStation_id_184_Function_Einladen_aus_Stock1.length(); model.getinformation_id_144_file_stocks().actualkapstock[0] = waitinglkw; model.containerinstock[0].reset(); model.containerinstock[0].update(waitinglkw); else if ((size2 >= size1) && (size2 >= size3)){ //Wartende LKW in Stock2 waitinglkw = Logic_Stocks.wtq_id_186_Function_Einladen_aus_Stock2.length() +Logic_Stocks.processStation_id_186_Function_Einladen_aus_Stock2.length(); model.getinformation_id_144_file_stocks().actualkapstock[1] = waitinglkw; model.containerinstock[1].reset(); model.containerinstock[1].update(waitinglkw); else { //Wartende LKW in Stock3 waitinglkw = Logic_Stocks.wtq_id_188_Function_Einladen_aus_Stock3.length() +Logic_Stocks.processStation_id_188_Function_Einladen_aus_Stock3.length(); model.getinformation_id_144_file_stocks().actualkapstock[2] = waitinglkw; model.containerinstock[2].reset(); model.containerinstock[2].update(waitinglkw); //@@_end of individual code for this method 28

5 Fazit Es wurden zwei komplexe Simulationsmodelle entwickelt um die Geschäftsprozesse in einem Hafen-Containerterminal abzubilden. Jedes der Beispiele besteht aus den epc-dateien, die mit Hilfe der BFlow-Toolbox (+ Validator & Generator) erstellt wurden und aus den generierten Java-Klassen. Es wurden alle in den EPK verwendeten Bflow-Komponenten, wie Trigger und Information-Objekte, beschrieben und entsprechende Codeanpassungen kenntlich gemacht. Die Modelle könnten durchaus noch weiter ausgebaut werden. Zum Beispiel wären weitere Stocks oder neue Prozesse und Bedingungen denkbar. Eine Obergrenze für Container in den Stocks könnte ebenfalls eingefügt werden. Es muss in diesem Beleg aber auch angemerkt werden, dass die Ereignisgesteuerten Prozessketten (EPK) an manchen Stellen nicht optimal für geeignet sind, Simulationsmodelle dieser komplexen Form zu modellieren. So wurden in dieser Ausarbeitung auch beispielsweise beim Vergeben der Namen für Funktionen und Ereignisse die EPK- Konventionen nicht immer korrekt eingehalten, da dies oft unsinnig erschien. An einer Stelle wurde eine überflüssige Dummy-Funktion eingefügt, um den Konventionen gerecht zu werden. Des Weiteren wurde in der EPK für die Stocks das File-Information-Objekt <Stocks> mehrfach an Funktionen geknüpft. Laut Vorschriften für EPKs ist das nicht zulässig. Es macht allerdings für die Simulation keinen Unterschied, da durch die Verknüpfung lediglich ein Verweis in der entsprechenden Funktion auf das Information-Objekt generiert wird. Der Fokus liegt im vorliegenden Beitrag im Wesentlichen auf der Simulation von Geschäftsprozessen als weniger auf der Modellierung, die aber selbstverständlich eine wesentliche Voraussetzung dafür ist! 29