[A] (3) Ereignisdiskrete Simulation

• “Prozessorientierte” Sicht

• Deshalb bestens geeignet für klassische „Prozesse“ bzw. Abfolgen von Operationen

• Geeignet für klassische „Prozesse“ bzw. Abfolgen von Operationen / Prozessen

  • Materialflüsse in klassischen produktions- oder logistiknahen Systemen

  • Prouktions- und Logisitksysteme

• Wenn das simulierte System als Prozessabfolge ausschließlich in EINEM Agenten (Main) modelliert werden kann

• Zustandsänderungen werden über Ereignisse verursacht

• Das heißt

  • Zustandsänderungen werden nicht über die Zeit getriggert

  • Zustandänderungen der Zustandsgröße nur nach Ereignissen

• Simulation

  • statisch

  • dynamisch

    • Kontinuierlich

    • diskret

      • zeitgesteuert

      • ereignisgesteuert

• zeitkontinuierliche Systeme

  • kontinuierliche Betrachtung der Zeit

  • Zeitmenge => Alle positive reelle Zahlen einschließlich der Null

• Zustandskontinuierliche Systeme

  • Belegungszustände eines Behälters für Schüttgut lassen sich bspw. über den Füllgrad des Behälters definieren

• zeitdiskrete Systeme

  • diskrete Betrachtung der Zeit

  • Zeitmenge => Zeitmenge T durch eine abzählbare Menge von Zeitpunkten t1, t2, t3, … definiert

• Zustandsdiskretee Systeme

  • Belegungszustände eines Behälters für Schüttgut lassen sich bspw. über mit Zustand z1 = leer und Zustand z2 = voll definieren

• 4 Fälle, bestehend aus

  • Kontinuierlichen Zustands- und Zeitmengen

  • Diskreten Zustands- und Zeitmengen

• Vorliegen einer Abfolge von Ereignissen mit Zeitstempeln

  • Alle Ereignise müssen im Simulationsablauf terminiert werden

  • Werden in einer liste aller künftigen Ereignisse festgehalten

• Basiert auf der diskreten Zeit

• Chronologisches Abarbeiten der Ereignisse im Laufe der Simulation anhand einer Ereignisliste => Reihenfolge ist also von größter Bedeutung

• Im Rahmen der Ablaufsteuerung wird das jeweils erste Ereignis der Liste ausgeführt und die Zeit entsprechend angepasst

  • Der aktuelle Zeitpunkt t, also die aktuelle Simulationszeit, wird jeweils auf den Zeitpunkt des nächsten zu betrachtenden Ereignisses gesetz

• Modellzeit wird nur vorgestellt, wenn ein Agent eine Operation beginnt oder abschließt => Ereignis

  • Jede Veränderung des Modells ist mit diesen Ereignissen verbunden

  • kontinuierliche Änderungen werden durch sofortige Ereignisse angenähert

• Ereignisse können auch neue Ereignisse (Folgeereignisse) erzeugen

  • Werden der Ereignisliste hinzugefügt (zur sofortigen Ausführung oder zu einem späteren Zeitpunkt)

    
    

• Chronologisches Abarbeiten der Ereignisse im Laufe der Simulation anhand einer Ereignisliste

  • Das Ereignis der Liste wird ausgeführt

  • Ereignis wird anschließend aus der Ereignisliste gestrichen

  • Der aktuelle Zeitpunkt t, also die aktuelle Simulationszeit, wird jeweils auf den Zeitpunkt des nächsten zu betrachtenden Ereignisses gesetz

• Modellzeit wird nur vorgestellt, wenn ein Agent eine Operation beginnt oder abschließt => Ereignis

  
  

  
  

Bsp: . Bei Beginn der Prüfung eines PCs an der Station „P2“ kann beispielsweise innerhalb einer Ereignisroutine der Zeitpunkt für das Ende der Prüfung stochastisch bestimmt werden, womit sich ein neues Ereignis (Ende der Prüfung) ergibt, das in die Ereignisliste einzutragen ist

• Folgeereignisse

• werden der Ereignisliste hinzugefügt (zur sofortigen Ausführung oder zu einem späteren Zeitpunkt)

• kontinuierliche Änderungen werden durch sofortige Ereignisse angenähert.

• Viele Ereignisse können nicht initial terminiert werden, da der Zeitstempel von zukünftigen Ereignissen

  • nicht immer eindeutig definiert werden kann

  • abhängig von Ereignissen bzw. Zuständen ist

• Folge

  • In vielen Fällen wird ein Folgeereignis nicht über einen Zeitpunkt, sondern über das Eintreten einer oder mehrerer Bedingungen bestimmt

  • Deshalb zusätzliche Überprüfung, ob die an das Ereignis geknüpfte Bedingungen erfüllt sind

• Berücksichtigung bzw. ständige Überprüfung des Zustands aber sehr rechenintensiv,

  • Daher sollte die Überprüfung ereignisdiskret erfolgen

  • Prüdung zu bestimmten Zeitpunkten oder ausgelöst durch ein anderes Ereignis

• Abarbeiten der Ereignisse erst wenn die Bedingungen erfüllt sind, nach bekanntem Schema

  • Zum Zeitpunkt wird die gesmate Liste der bedingten Ereignisse geprüft ob bedingungen erfült sind oder Prüfung von Bedingungen in den Ereignisroutinen

So kann beispielsweise mit der Bearbeitung eines PCs an einer Montagestation nicht immer direkt mit Eintritt des PCs auf der Station begonnen werden. Dies darf nur erfolgen, wenn alle erforderlichen Komponenten verfügbar sind. Der Zeitpunkt, zu dem alle fehlenden Komponenten durch Stapler angeliefert worden sind, ist aber zum Zeitpunkt der Ankunft des PCs unter Umständen noch gar nicht bekannt. Daher ist es nicht möglich, in der zuvor beschriebenen Weise ein Folgeereignis mit fixem Eintrittszeitpunkt zu definieren und in den Ereigniskalender einzutragen. Der PC würde an der Station letztendlich „hängen“ bleiben, wenn nicht anderweitig sichergestellt wird, dass mit der Montage nach dem Eintreffen der erforderlichen Teile begonnen wird

• Es kann mehrere Ereignisse mit dem gleichen Zeitstempel geben

• Echte Gleichzeitigkeit ist aber nicht möglich => Serialisierung

• Parallele Ereignisse müssen in der Umgebung serialisiert werden

Serialisierung paralleler Ereignisse kann zu Problemen führen

• Am besten: Modell ist nicht sensitiv ggü . Veränderungen der Reihenfolge paralleler Events

• Oder: muss kontrolliert - oder zumindest verstanden - werden

• Es sollte daher immer klar definiert werden, welches Ereignis vor anderen stattfinden muss

• Ereignisse können insbesondere durch Zustandsänderungen während der Simulation getriggert werden

• Die wichtigsten Elemente sind:

  • Events => Eintreten eines Ereignisses

  • Prozessmodellierungsblöcke => Ein Agent erreicht oder verlässt einen Prozessmodellierungsblock

  • Zustandsgraphen (State Charts) => Veränderung eines Zustands der mit einem bedingten Ereignis verknüpft ist

• AnyLogic bietet in den Actions die Möglichkeit, mittels Java-Code individuell Einfluss auf die Ereignisse zum Zeitpunkt zu nehmen

  • Code wird ausgeführt, wenn der beschriebene Zustand erreicht wird bzw. das beschriebene Ereignis eintritt

• Events

• Prozessmodellierungsblöcke

• Zustandsgraphen (StateCharts)

• Die Folgen des Ereigniseintritts werden meist per Java Code definiert

• AnyLogic bietet in den Actions die Möglichkeit, mittels Java-Code individuell Einfluss auf die Ereignisse zum Zeitpunkt zu nehmen

• Code wird ausgeführt, wenn der beschriebene Zustand erreicht wird bzw. das beschriebene Ereignis eintritt

• Events

• DynamicEvents

• Ein solches Event kann zeitgenau erstellt werden

• Spezifikationsmöglichkeiten

  • Events können abhängig von Zuständen, Zeit oder Ankunftsrate erstellt werden

  • Sie Können einmalig, zyklisch oder deterministsich auftreten

• Im Action-Abschnitt wird definiert welche Aktion (durch Code) das Event auslöst

• Events können abhängig von Zuständen, Zeit oder Ankunftsrate erstellt werden

• Sie Können einmalig, zyklisch oder deterministsich auftreten

• I.d.R. in Kombination mit bedingten Ereignissen

• Bspw. angelehnt an klassischen bedientheoretischen Prozess:

  • Bedientheorie => generischer Prozess aus Ankunft, Warten, Bedienen, Abgang

  • Bedienen ohne explizite Berücksichtigung von Ressourcen

    • Parallelisierung durch Angabe von Delay-Kapazität

  • Bedienen mit Ressourcen

    • Parallelisierung durch Anzahl verfügbarer Ressourcen

• Parallelisierung durch Angabe von Delay-Kapazität

• Parallelisierung durch Anzahl verfügbarer Ressourcen

• AnyLogic bietet die Möglichkeit den Bedienprozess über Ressourcen genauer darzustellen.

  • Eine Ressource nimmt im bedientheoretischen Sinn die Rolle eines Bedieners ein

  • Ressourcen stellen jeweils eigene Agenteninstanzen dar und können eigenen Agententypen zugeordnet werden

• Eine Ressource nimmt im bedientheoretischen Sinn die Rolle eines Bedieners ein

• Ressourcen stellen jeweils eigene Agenteninstanzen dar und können eigenen Agententypen zugeordnet werden

• Definition der Ressourcenkapazität

• Können einen bestimmten Prozess zugeordnet werden => n:n Zuordnungen zwischen Prozessen und Ressource möglich

• Verhaltens der Ressourcen kann festgelegt werden

  • Zwischen den Aufgaben (Auf den Weg zu einem Prozessblock und zurück)

  • zu bestimmten Zeitpunkten während der Bedienung der Aufgabe

• Zuordnung von Schichtplänen

• Auswertung der Auslastung der Ressourcen

• Definition und Zuordnung der Ressourcen über

  • Resource Pool

  • zugeordnete Seize-, Release- bzw. Service-Blöcke

• Ressourcen sollten immer dann eingeführt werden, wenn diese ein beschränkendes Element darstellen, die zur Durchführung eines oder mehrerer Prozesse benötigt werden.