Sie sind auf Seite 1von 7

Entwicklung des Modells

Bevor wir mit der Entwicklung des Modells beginnen, mchten wir klren, mit welchen Systemen wir bei der Realisierung unseres Modells arbeiten werden bzw. welche Systeme im konkreten Fallbeispiel vorliegen. Dazu werden wir die einzelnen Klassifizierungsmglichkeiten von Systemen und Modellen betrachten und dabei analysieren, welche in unserem Konkreten Seehafenmodell auftreten.

Kontinuierliches oder diskretes System?


Im Modell des Seehafen gibt es sowohl kontinuierliche als auch diskrete Gren. Kontinuierliche Gren sind hauptschlich die Ankunfts-, Bearbeitungs- und Verweilzeiten der Schiffe. Diskrete Gren stellen zum Beispiel die Anzahl ankommender Schiffe, die Anzahl der wartenden Schiffe in der Warteschlange oder die Anzahl der bedienten Schiffe im Server dar. Auch das ordinal messbare Merkmal "Schiffstyp" stellte eine diskrete Gre dar. Neben den Gren sind auch die Prozesse fr die Entscheidung kontinuierlich oder diskret von Bedeutung. Im Modell werden Ereignisse eintreten, die eine sprunghafte Zustandsnderung bewirken und keine Zeit beanspruchen. Es sind somit nichtstetige Prozesse. Da es in unserem Modell sowohl diskrete als auch kontinuierliche Gren gibt und nichtstetige Prozesse vorliegen, handelt es sich um diskrete Simulation. Diese Art der Simulation kann durch die Simulationssoftware Enterprise Dynamics realisiert werden.

Deterministische oder stochastische Simulation?


Die deterministische Simulation ist dadurch gekennzeichnet, dass das Simulationsergebnis durch die Eingangsgren und Startwerte determiniert, also bestimmt ist. Dies hat zur Folge, dass bei mehreren Lufen mit den gleichen Gren und Werten immer wieder das gleiche Ergebnis erzielt wird. Da in unserem Modell viele Zufallsgren verwendet werden die zum Beispiel einer Exponentialverteilung oder Gleichverteilung unterliegen, handelt es sich bei der Realisierung des Seehafens um eine stochastische Simulation. Spter beim Betrachten verschiedener Durchlufe wird deutlich, dass keine Lauf dem anderen gleicht. Bereits die Ankunft der Schiffe kann von Lauf zu Lauf unterschiedlich sein, da die Art und Anzahl der Schiffe der Bernoulli-Verteilung unterliegt.

Statisches oder dynamisches System?


Diese Frage ist in unserem Fall des Seehafens eindeutig zu beantworten. Der Zustand der einzelnen Atome wird sich im zeitverlauf entsprechend ndern. Warteschlangen fllen sich, Server wechseln ihren Zustand zwischen "ausgelastet (busy)" und "frei (idle)". Dies sind deutliche Merkmale von dynamischen Systemen.

Terminierendes oder nichtterminierendes System?


Die Einteilung in ein terminierendes oder nichtterminierendes System bezieht sich auf die Dauer der Prozesse. Haben die Prozesse des Systems einen natrlichen Endpunkt, so spricht man von einem terminierenden System. Dies kann auch der Fall sein, wenn diese terminierenden Prozesse stndig wiederholt werden. Ist dies nicht der Fall, liegt ein nichtterminierendes System vor. Auch hier kann es Unterbrechungen geben, wichtig ist jedoch, dass diese nicht zu einem unabhngigen Neustart in der nchsten Periode fhren. Betrachtet man den Ablauf eines Seehafen wird man feststellen, dass das System nahezu Unterbrechungsfrei luft. Unterbrechungen sollten nicht natrlicher Art sein,

sondern lediglich durch Ausflle bedingt sein. Fllt zum Beispiel ein Liegepltz wegen eines Schadens an einer Containerbrcke aus, fhrt dies nicht zu einem Neustart des Gesamten Systems. Somit kann man beim Modell des Seehafens von einem nichtterminierenden System sprechen.

Stationres oder nichtstationres System?


Stationre Systeme sind dadurch charakterisiert, dass nach einer bestimmten Einschwingphase ein sogenannter "steady state", also ein stationrer Zustand, erreicht wird. Fr die betrachteten Gren bedeutet dies, dass diese in der stabilen Phase keinen Trend mehr aufweisen drfen. Die Streuung der Parameter nimmt in whrend der Einschwingphase kontinuierlich zu und erreicht im stationren Fall ein stabiles Maximum. Wird kein stationrer Zustand erreicht, handelt es sich um ein nichtstationres System. Im Fallbeispiel des Seehafens pendeln sich zum Beispiel die Werte der Auslastung der Liegepltze nach einiger Zeit bei einem stabilen Maximum ein.

Echtzeit oder Nicht-Echtzeit-Simulation?


Da in unserem konkreten Fallbeispiel der Betrieb eines Seehafen betrachtet werden soll und relativ lange Zeitintervalle vorliegen und betrachtet werden sollen, wird hier eine Nicht-Echtzeit-Simulation vorgenommen.

Zeitfortschritt in der Simulation


Eine weiterer wichtiger Aspekt der Simulation des Seehafens ist der zeitfortschritt in der Simulation. Man unterscheidet in zeitorientierte, prozessorientierte und ereignisorientierte Simulation. Da Enterprise Dynamics zur ereignisorientierten diskreten Simulation herangezogen wird, lsst sich diese Frage fr unser Beispiel relativ leicht beantworten. Im Modell werden spter bestimmte Ereignisse eintreten. Dies kann zum Beispiel die Ankunft eines Schiffes, die Ankunft am Server oder das Verlassen des Servers sein. Die Ereignisse fhren bei den assoziierten Objekten zu Reaktionen. Fr das Aufrufen eines Objektes verstreicht anders als bei der zeitorientierten Simulation keine Zeit. Die Simulationsuhr wird immer mur um die Zeiten, die fr ein Ereignis vorgesehen sind erhht und luft nicht kontinuierlich weiter. Bei Erreichen einer vorgegebenen Simulationszeit oder beim Eintreten eines bestimmten Ereignisses wird die Simulation beendet. So wird zum Beispiel bei Ankunft eines Schiffes am Server die Simulationsuhr, die zu Beginn der Simulation den Wert 0 hat und durch eintretende Ereignisse um die jeweiligen Zeiten erhht wurde lediglich um die auf dem Produktlabel angegebene Bearbeitungszeit erhht. Grafisch ist di es fr den Benutzer jedoch nicht erkennbar. Vorteile dieser Simulation ist, dass die zeitliche Auflsung, die gerade beim Seehafenmodell sehr hoch sein kann, die Rechenzeit nicht beeinflusst.

Als nchstes soll geprft werden, ob das Modell anhand der mittleren Ankunfts- und Bearbeitungszeiten sowie der entsprechenden Kapazitten in der Lage ist, die ankommenden Schiffe zu bedienen. Es gibt verschiedene Mglichkeiten die Ankunft der Schiffe, das Warten vor dem Hafenbecken sowie den Hafenbetrieb zu simulieren. In unserer Simulation gehen wir davon aus, dass Schiffe in nur einer Queue eine Warteschlange bilden. Im Hinblick auf das Liegeplatzkonzept ist dies allerdings kritischer, da Schiffe strikt nach ihrer Ankunftsreihenfolge bearbeitet werden mssten. Spter im Modell knnte die Bearbeitungsreihenfolge durch Anpassen der Queue-Discipline so verndert werden, dass Schiffstypen bevorzugt werden. Die Liegepltze werden je nach Ankunft der Schiffe vergeben, so dass hier ein dynamisches Konzept gewhlt wird, in dem freie Kapazitten

besser ausgelastet werden. In dem zu simulierenden Zeitraum (500 Tage), kommen im Mittel 460 Schiffe an. Die folgende Tabelle stellt die mittleren Bearbeitungszeiten der Schiffe dar: Schiffstyp Anzahl pro 260 Stunden Entladezeit in Std. (exp. verteilt) 15 30 45 Beladezeit in Gesamtzeit in Std. Std. pro Schiff (gleichverteilt) 24 6 36 10 56 12 39 6 66 10 101 12 Gesamtzeit in Std.fr alle Schiffe 195 30 198 30 202 24

A B C

5 3 2

Tabelle 1 Ankunfts- und Bearbeitungszeiten der Schiffe

Zur gleichzeitigen Bearbeitung von Schiffe der unterschiedlichen Typen sind verschiedene Kombinationen mglich. Diese sind in Tabelle 2 aufgefhrt: Schiffstyp A B C 1 10 A 0B 0C 2 2A 2B 1C 3 6A 0B 1C 4 2A 0B 2C 5 2A 4B 0C

Tabelle 2 Mgliche Kombinationen zur gleichzeitigen Bearbeitung der Schiffstypen

Betrachtet man 260 Stunden ergibt sich fr die Belegung der Liegepltze mit Mglichkeit 2 folgender Durchsatz an abgefertigten Schiffen: 2 A : ca. 45 Stunden 11 A : 260 Stunden 2 B : ca. 76 Stunden 7 B : 260 Stunden 1 C : ca. 113 Stunden 2 C : 260 Stunden Mit diesem Belegungskonzept sollte der Hafen die ankommenden Schiffe abfertigen knnen. Die genaue Berechnung der Auslastung der Liegepltze erweist sich jedoch als sehr schwierig. Zum einen gibt es ausschlielich Nichtlinearitten, sodass nur mit Erwartungswerten zu rechnen ist. Weiterhin ist schlecht vorherzusagen, in welchem Ausma die Warteschlange die Schiffe auf die Server D2 und D3 aufteilen wird, weil dies von der Bernoulli-verteilten Ankunft der Schiffe abhngig ist.

Implementierung
An dieser Stelle mchten wir u. a. etwas nher auf die Realisierung des Seehafenbetriebs, mit Schwerpunkt auf dem Liegeplatzkonzept eingehen. Wichtigstes Element der Implementierung ist die Erstellung eines funktionsfhigen Liegeplatzkonzepts, welches den Restriktionen bezglich Kapazitten, die unter Punkt 1 genannt wurden, unterliegt. Hierzu sind einige Erluterungen ntig, die zur besseren bersicht zu jedem einzelnen Atom aufgefhrt werden. Von hoher Bedeutung ist die Kenntnis ber Verwendung von Labels, ber das Channelverhalten von Atomen sowie das Referenzieren auf andere Atome. Zunchst sollen die Atome etwas nher beschrieben werden, die zur Realisierung der einzelnen Bereiche des Hafens verwendet wurden. Hierzu werden auch die verwendeten 4D-Script Befehle herangezogen und erlutert.

Die Source (Ankunft der Schiffe)


Aus der Source kommen, wie aus der Aufgabenstellung hervorgeht, drei verschiedene Schiffstypen (A, B und C), die anstelle der Buchstaben die Zahlenwerte Typ A = 1,Typ B = 2 und Typ C = 4 zugewiesen bekommen. Dies wird mit Hilfe von Labels realisiert, die im Verhltnis 5:3:2 vergeben werden. Die Vorteilhaftigkeit von der Verwendung von Zahlenwerten anstelle der Buchstaben wird sptestens bei den Liegepltzen deutlich, da diese dort zur Berechnung verwendet werden. Das Verhltnis 5:3:2 wurde ber die Bernoulli-Verteilung realisiert. Zur grafischen Verdeutlichung werden die Schiffe grn (Typ A), gelb (Typ B) und rot (Typ C) eingefrbt und erhalten je nach Typ eine feste Gre, wobei wir festgelegt haben, dass Typ C den grten Schiffstyp darstellt. Neben Farbe und Gre erhalten die Schiffe in der Queue auch jeweils ein Label Cycletime, welches die Liegezeit im Hafen abbildet. Diese setzt sich aus der exponentialverteilten Entladezeit sowie der gleichverteilten Beladezeit zusammen. Der Quelltext, der in dem Feld "Trigger on Creation" in der Source eingegeben wurde ist in Abb. 1 dargestellt. Das Feld "Trigger on Creation" wurde gewhlt, da es logischer erscheint alle Daten bereits bei Ankunft des Schiffes zu vergeben. Genauso gut htten die u.g. Angaben aber auch im Feld "Trigger on Exit" oder sogar erst bei Eintritt in die Queue platziert werden knnen.
Abbildung 1 "Trigger on Creation" Befehle in der Source

Die Queue (Wartebereich vor dem Hafen)


Aufgabe der Queue ist es zum einen den Puffer zu schaffen, wenn die Liegepltze fr den jeweiligen Schiffstyp belegt sind und ein Schiff nicht in den Hafenbereich einfahren kann. Sie stellt den Wartebereich im offenen Meer dar. Zum anderen entscheidet die Queue ber den Liegeplatz, den ein Schiff zugewiesen bekommt. Als "Queue Discipline" haben wir zunchst das FIFO (First In First Out) - Verfahren gewhlt. Fr sptere Untersuchungen am Modell knnte man dies auch ohne Probleme so umstellen, dass zum Beispiel A-Schiffe an den anderen Schiffen vorbeifahren knnen, da fr A-Schiffe die meiste Kapazitt verfgbar ist. Die "Send To" Anweisung der Queue ist das erste Kernstck zur Realisierung der Liegeplatzvergabe. Zunchst prft die Queue, ob das Schiff an erster Position ein Typ A Schiff ist und schickt dieses vorrangig und sofern frei in den ersten Liegeplatz. Ist dieser belegt, wird der Reihe nach geprft, ob evtl. ein anderer Liegeplatz verfgbar ist und das Schiff anschlieend dorthin geschickt. Sollte das erste Schiff in der Queue ein B- oder C- Schiff sein, prft die Queue zunchst den Inhalt von Liegeplatz D2, sollte dieser komplett belegt sein, wird Liegeplatz D3 geprft und das Schiff bei freier Kapazitt in diesen geleitet, ist dies nicht der Fall gelangt das Schiff in Liegeplatz D2. Sind beide Liegepltze belegt, verweilt das Schiff im Wartebereich vor dem Hafen. Hierzu bekommt die Queue von den einzelnen Liegepltzen deren Inhalt ber das Label InhaltD.. mitgeteilt. Wie bereits beschrieben wir hier ein erster wichtiger Schritt zur Belegung der Liegepltze ausgefhrt. Die Queue addiert das Label des ersten Schiffes, auf das mit dem 4D-Script Befehl first(c)referenziert wird Ist diese Summe kleiner als der (Rest-)Kapazitt des jeweiligen Liegeplatzes, kann das Schiff in diesen geschickt werden. Ansonsten verweilt das Schiff bis zum frei werden eines Liegeplatzes in der Queue. Die 4D-Script Ansicht der Queue ist in Abbildung 2 dargestellt.

Abbildung 2 Die "Send-To"" Anweisung der Queue

Ein weiterer wichtiger Aspekt ist das Zurcksetzen der Labels InhaltD2 und InhaltD3 beim Neustart der Simulation, da dies nicht automatisch geschieht. Hierfr steht in Enterprise Dynamics der Atom Editor zur Verfgung, in dem smtliche Attribute, Parameter, etc. eines Atoms eingestellt werden knnen. Unter der Registerkarte Events gibt es eine Eingabemglichkeit fr Befehle, die bei Neustart (Reset) des Modells ausgefhrt werden sollen. Abbildung 3 zeigt, dass an genannter Stelle die beiden Labels, welche whrend der Simulation auf die Queue geschrieben werden zurckgesetzt werden.

Abbildung 3 Editiermglichkeiten der Queue

Die Multiserver (Liegepltze D1, D2 und D3)


Aufgabe der Multiserver ist es die eingehenden Schiffe zu be- und entladen. Um stndig die jeweilige Kapazittsauslastung zu kennen, erhalten die Server bei Eintritt des ersten Schiffes ein Label names Inhalt, welches den Wert zugewiesen bekommt, den ein Schiff als Label Typ aufweist. Hier wird auch deutlich, warum bei den Schiffstypen mit Zahlenwerten 1,2 und 4 gearbeitet wurde. Das Label Inhalt wird nmlich beim Einfahren eines Schiffes um den Wert des Labels Typ erhht, und bei Ausfahrt eines Schiffes um dessen Wertigkeit (die dem Typ entspricht) vermindert. Der Multiserver erkennt also bei jedem Ereignis seine beanspruchte Kapazitt. Diese gibt er an die Queue weiter in der er auf diese das Label InhaltD.. schreibt. Die Referenz auf die Queue wurde mit dem Befehl In(1,c) realisiert. Dies bedeutet, dass das Label auf das Atom geschrieben wird, was mit dem ersten Inputchannel des Atoms verknpft ist. Zustzlich wurde mit den Befehlen Openinput(c) und Closeinput(c) gearbeitet. Dies bewirkt, dass der Multiserver sobald eine gewisse Kapazitt erreicht ist (grer als 3), seinen Eingangschannel schliet und sobald die Kapazitt unter den Wert 3 fllt diesen wieder ffnet. Somit ist sichergestellt, dass keine weiteren Schiffe in den Multiserver gelangen knnen. Die einzelnen Verhalten des Servers bei Einfahrt eines Schiffes ("Trigger on Entry") und Ausfahrt des Schiffes ("Trigger on Exit") sind in den Abbildungen 4 und 5 dargestellt. Die Bearbeitungszeit, welche die Multiserver fr das bearbeiten der Schiffe bentigen wurde bereits am Anfang als Label auf den Schiffen aufgebracht. Somit muss der Multiserver dieses Label lediglich auslesen. Dies wurde mit dem Befehl Label([Cycletime],i) realisiert. Weiterhin mssen die Labels auf den Multiservern (analog zu den Labeln auf der Queue) im Atom-Editor bei Neustart des Systems auf den Wert 0 (dies bedeutet brigens, dass das Label gelscht und nichtmehr angezeigt wird) gesetzt.

Auf eine erneute Darstellung wird an dieser Stelle verzichtet, da sich gegenber der Queue lediglich der Name der Labels ndert.

Abbildung 4 "Trigger on Entry" - Verhalten des Multiservers

Abbildung 5 "Trigger on Exit" - Verhalten des Multiservers

Die Ausfhrungen zum Liegeplatz D3 entsprechen den oben genannten Ausfhrungen zu Liegeplatz D2. Es unterscheiden sich lediglich die Namen der Labels. Auf eine ausfhrliche Darstellung wird somit verzichtet.

Die Sink (Ausfahrt des Hafens)


Dieses Atom hat lediglich die Funktion die abgefertigten Schiffe aufzunehmen und anzuzeigen, wie viele Produkte (in diesem Fall Schiffe) das System durchlaufen haben. Sie gehrt genauso wie die Source und die Queue zu den Basisatomen eines jeden Modells in Enterprise Dynamics. Auf die Aufgabe bertragen stellt sie die Ausfahrt des Hafens dar. Hier wurden keine weiteren Eintragungen oder Befehle aufgefhrt.