Zusammenfassung der Konzepte der diskreten Ereignissimulation (DES)

Einführung in DES und datengestützte Entscheidungen

• Diskrete Ereignissimulationen (DES) sind ein hochentwickeltes Instrument zur Entscheidungsfindung und Systemanalyse, das die Dynamik komplexer Systeme durch die Modellierung von Ereignissen zu diskreten Zeitpunkten abbildet.

• Entscheidungen sollen datengestützt (Data Driven Decisions) getroffen werden, basierend auf den durch die Simulation gewonnenen Einsichten und quantitativen Metriken, um die Zuverlässigkeit und Objektivität der Entscheidungsfindung zu erhöhen.

Rückblick: Modellübersetzung mit simpy

• Der Simulations-Workflow umfasst mehrere Phasen, die einen strukturierten Ansatz zur Problemlösung sicherstellen:

  1. Problemformulierung: Klare Definition der Forschungsfrage und des Systemumfangs.

  2. Modellkonzeptualisierung: Identifizierung relevanter Systemkomponenten, deren Interaktionen und der zu messenden Leistungskennzahlen.

  3. Datenerfassung: Beschaffung und Aufbereitung realer oder geschätzter Daten zur Parametrisierung des Modells.

  4. Modellübersetzung (Programmierung): Implementierung des konzeptuellen Modells in einer Simulationssoftware oder -sprache.

  5. Verifikation & Validierung (gegebenenfalls Iteration zur Anpassung): Überprüfung der korrekten Implementierung und der Übereinstimmung des Modells mit der Realität.

  6. Experimentaldesign: Planung der Simulationsläufe zur Untersuchung spezifischer Szenarien oder Parameter.

  7. Simulationsläufe & -analyse: Durchführung der Simulationen und statistische Auswertung der Ergebnisse.

  8. Daten- & Entscheidungsimplementierung: Anwendung der Simulationsergebnisse zur Verbesserung des realen Systems oder zur Unterstützung strategischer Entscheidungen.

• Modellübersetzung beinhaltet das Schreiben des Codes für das Simulationsprogramm, oft unter Verwendung spezialisierter Bibliotheken wie simpy in Python, die die Event-Scheduling-Logik und das Management von Entitäten, Ressourcen und Ereignissen vereinfachen.

Problemformulierung

• Definition: Festlegung des Umfangs und der Ziele der Simulationsstudie. Dies beinhaltet die präzise Formulierung der spezifischen Fragen, die durch die Simulation beantwortet werden sollen, sowie die klare Abgrenzung des zu untersuchenden Systems.

• Identifizierung der Grenzen des zu untersuchenden Systems: Welche Teile der Realität gehören zum System und welche nicht? Dies ist entscheidend, um den Modellfokus zu schärfen und unnötige Komplexität zu vermeiden.

• Ausschließen dessen, was exogen zum System ist: Elemente, die von außen auf das System wirken und deren Verhalten im Modell nicht erklärt, sondern als gegebene Randbedingungen betrachtet wird (z.B. Wetterbedingungen für einen Tankstellenbetrieb, wenn diese nicht direkt modelliert werden).

Beispiel: Friseursalon

• Geschäftsfragen: Die Simulation kann hier helfen, betriebswirtschaftliche Entscheidungen zu treffen und die Servicequalität zu optimieren:

  • Wie viele Sitzplätze werden für die Warteschlange benötigt, um Wartezeiten zu minimieren und Kundenabwanderung zu vermeiden?

  • Wie lange müssen Kunden durchschnittlich warten, bis sie bedient werden? Dies ist eine wichtige Metrik für die Kundenzufriedenheit.

  • Benötigt der Salon einen zusätzlichen Friseur, um die Auslastung zu optimieren und Wartezeiten zu reduzieren?

  • Was sind die Auswirkungen unterschiedlicher Buchungssysteme oder Servicezeiten auf den Gesamtablauf?

  • … (Beispiel einer DES in Excel: Ein einfaches Modell kann einen Bedienplatz simulieren, indem Ankunftszeiten, Servicezeiten und resultierende Wartezeiten manuell oder mit Formeln berechnet werden).

Beispiel: Betrieb einer Tankstelle

• Geschäftsfragen: Hier kann die Simulation zur Optimierung der Ressourcen und des Betriebs beitragen:

  • Wie viele Zapfsäulen werden benötigt, um Stoßzeiten effizient zu bewältigen und lange Warteschlangen zu vermeiden?

  • Wie lange müssen Autos im Durchschnitt warten, bis eine Zapfsäule frei wird? Dies beeinflusst die Kundenerfahrung und den Durchsatz.

  • Wie groß muss das Kraftstofflager sein, um Engpässe zu vermeiden und gleichzeitig Überbestände zu minimieren?

  • Welche Auswirkungen haben unterschiedliche Tankwagenlieferintervalle auf die Lagerhaltung und die Verfügbarkeit von Kraftstoff?

  • …

Modellkonzeptualisierung

• Definition: Identifizierung der Leistungsmerkmale (Performance Characteristics), d.h. der Effektivitätsmaße des Systems. Dies sind die Schlüsselkennzahlen, die zur Bewertung der Systemleistung und zur Beantwortung der Problemfragen herangezogen werden. Sie müssen quantifizierbar und relevant sein.

• Identifizierung der Eingabevariablen (Input Variables), die für die Ziele der Untersuchung relevant sind. Diese Variablen sind die Stellschrauben des Modells, deren Werte variiert werden können, um verschiedene Szenarien zu testen (z.B. Anzahl der Friseure, Ankunftsraten, Servicezeiten).

Beispiel: Friseursalon

• Leistungskennzahlen (Performance Metrics):

  • Warteschlangenlänge: Durchschnittliche oder maximale Anzahl der wartenden Kunden (Indikator für Kundenzufriedenheit und benötigten Platz).

  • Wartezeit / Bearbeitungszeit: Wartezeit bis zum Beginn des Services, sowie die gesamte Zeit im System (maßgeblich für Kundenerfahrung).

  • Auslastung des Friseurs: Prozentsatz der Zeit, in der ein Friseur beschäftigt ist (Indikator für Ressourceneffizienz).

  • Gewinn (z.B. abhängig von der Anzahl der Friseure und der Kapazität, Kunden zu bedienen).

• Eingabevariablen (Input Variables):

  • Kundenankünfte: Typischerweise modelliert durch eine Wahrscheinlichkeitsverteilung (z.B. Exponentialverteilung für die Zwischenankunftszeiten).

  • Angeforderte Haarschnitt-Typen: Können unterschiedliche Servicezeiten implizieren.

  • Haarschnittdauer: Dauer der Serviceleistung, oft modelliert durch eine bestimmte Wahrscheinlichkeitsverteilung (z.B. Normal- oder Dreiecksverteilung).

  • Anzahl der Friseure: Eine der Hauptstellschrauben für die Kapazitätsplanung.

  • Usw.

Beispiel: Tankstelle

• Leistungskennzahlen:

  • Wartezeit: Zeit, die ein Fahrzeug auf eine freie Zapfsäule oder auf die Betankung wartet.

  • Return on Investment (Investitionskosten vs. Umsatz): Wirtschaftliche Bewertung verschiedener Kapazitätskonfigurationen.

  • Servicezeit: Die Dauer des Betankungsvorgangs.

  • Auslastung der Zapfsäulen: Prozentsatz der Zeit, die Zapfsäulen in Betrieb sind.

  • Durchsatz: Anzahl der pro Zeiteinheit bedienten Fahrzeuge.

  • Usw.

• Eingabevariablen:

  • Autoankünfte: Häufig modelliert als Poisson-Prozess für die Ankunftsrate (oder Exponentialverteilung für Zwischenankunftszeiten).

  • Angeforderte Kraftstoffmenge: Beeinflusst die Dauer des Tankvorgangs.

  • Kraftstoffarten: Können unterschiedliche Nachfrage- und Lageranforderungen haben.

  • Lieferzeit des Tankwagens: Beeinflusst die Verfügbarkeit von Kraftstoff im Lager.

  • Kapazität des Kraftstofflagers: Direkte Auswirkung auf die Notwendigkeit von Lieferungen.

  • Usw.

Modellübersetzung

• Modellübersetzung:

  • Entwerfen des Simulationsmodells, z.B. mittels Flussdiagramm: Ein visuelles Flussdiagramm hilft, die Logik des Systems, den Fluss der Entitäten und die Interaktionen zwischen Komponenten klar darzustellen, bevor der eigentliche Code geschrieben wird.

  • Testen der Gültigkeit (Validität), wo immer möglich (z.B. face validity, Experten-Walk-Throughs): Dies umfasst die Überprüfung, ob das Modell das beabsichtigte System korrekt darstellt. Face Validity bedeutet, dass Experten und Stakeholder das Modell als plausible Repräsentation des realen Systems anerkennen. Weitere Validierungsmethoden umfassen den Vergleich mit historischen Daten oder die Sensitivitätsanalyse der Modellparameter.

• Simulationsmodell:

  • Auswahl einer geeigneten Computersprache oder Simulationssoftware, die die Anforderungen des Modells und die Präferenzen des Modellierers erfüllt (z.B. Python mit simpy, Arena, AnyLogic, ExtendSim).

  • Schreiben des Codes für das Simulationsprogramm und Verifizieren (Debuggen) des Programms: Verifikation stellt sicher, dass das Simulationsprogramm korrekt implementiert ist und keine Fehler im Code enthält. Dies ist ein iterativer Prozess des Testens und Debuggens.

DES Konzepte: Modell

• Was ist ein Modell? Ein Modell ist eine vereinfachte, abstrakte Repräsentation eines realen Systems oder Prozesses, die darauf abzielt, dessen Verhalten für spezifische Untersuchungszwecke nachzubilden und zu verstehen.

• Wie erstellt man ein Modell? Man berücksichtigt nur jene Aspekte des Systems, die das zu untersuchende Problem beeinflussen. Dies erfordert eine sorgfältige Abstraktion und die Entscheidung, welche Details wesentlich sind und welche vernachlässigt werden können, um das Modell handhabbar zu halten.

• Herausforderungen:

  • Modelle sind nicht einzigartig: Für ein gegebenes System und Problem können verschiedene Modelle mit unterschiedlichen Abstraktionsebenen und Annahmen erstellt werden, die alle ihre Berechtigung haben.

  • Die Granularität der Details ist entscheidend: Zu wenige Details können das Modell irrelevant machen; zu viele Details können es unnötig komplex, langsam und schwer verifizierbar machen.

• Tendenz: Die Tendenz ist fast immer, zu viel statt zu wenig Details zu simulieren. Daher sollte man das Modell immer um die zu beantwortenden Fragen herum konzipieren, anstatt das reale System exakt nachzubilden (Shannon, 1975). Dies unterstreicht die Notwendigkeit, sich auf die Relevanz für die Problemstellung zu konzentrieren.

Arten von Modellen (konkret zu abstrakt)

• Physische Modelle: Dies sind materielle Nachbildungen eines realen Systems, die dessen physikalische Eigenschaften nachahmen, oft in verkleinertem oder vergrößertem Maßstab (z.B. ein maßstabsgetreu gebautes Flugzeugcockpit für Pilotentraining oder Architekturmodelle).

• Skalierte Modelle: Ähneln dem System, aber in einer anderen Größe oder auf einer anderen Skala (z.B. ein stark hochskaliertes Atommodell zur Veranschaulichung der Struktur oder ein maßstabsgetreues Schiffsmodell zur Erprobung in einem Strömungskanal).

• Analoge Modelle: Eine Eigenschaft des realen Objekts wird durch eine substituierte Eigenschaft repräsentiert, die sich ähnlich verhält, basierend auf einer Analogie (z.B. ein Graph, bei dem die Distanz zwischen Knoten die Zeit, Temperatur, Umsatz oder andere verwandte Metriken repräsentiert).

• Schematische Modelle: Bildliche Darstellung eines Systems, oft in Form von Diagrammen oder Plänen, die die Beziehungen und Struktur des Systems visualisieren (z.B. Bauplan, Schaltplan, Organigramm).

• Spiele oder Mensch-Maschine-Modelle: Interaktive Modelle, bei denen menschliche Entscheidungen oder Strategien in das Simulationsgeschehen einfließen, oft zu Trainings- oder Entscheidungsfindungszwecken (z.B. Management-Spiele, Kriegsspiele, Planungs- oder Wettbewerbssimulationen).

• Simulationsmodelle: Sind abstrakter und haben im Allgemeinen keine direkte menschliche Interaktion während des Laufs. Sie verwenden Algorithmen und Schritt-für-Schritt-Berechnungen, oft implementiert als Computerprogramm, um das dynamische Verhalten eines Systems über die Zeit abzubilden. Sie sind darauf ausgelegt, das Systemverhalten zu prognostizieren und zu analysieren.

• Mathematische Modelle: Verwenden mathematische Symbole, Gleichungen und logische Ausdrücke, um Entitäten und Beziehungen zu repräsentieren. Sie sind die generalisiertesten Modelle, mit dem Potenzial, präzise Analysen zu ermöglichen, bergen aber das Risiko der Übervereinfachung, wenn die Realität nicht ausreichend durch die Formeln abgebildet wird.

• Heuristische Modelle: Eine Sammlung von Deskriptoren, Regeln, Algorithmen oder Entscheidungsregeln, meist computerbasiert, die nicht streng durch physische, diagrammatische oder mathematische Grenzen eingeschränkt sind. Sie nutzen oft Faustregeln oder erfahrungsbasierte Ansätze, um komplexe Probleme zu lösen, bei denen optimale Lösungen schwer zu finden sind.

System vs. Modell

• Wie studiert man ein System?

  • Experiment mit dem tatsächlichen System: Liefert die genauesten Ergebnisse, ist aber oft teuer, zeitaufwendig, riskant oder unmöglich durchzuführen (z.B. Testen eines neuen Produktionslayouts).

  • Experiment mit einem Modell des Systems: Bietet eine kostengünstige, risikoarme und flexible Alternative, um verschiedene Szenarien zu testen und Einblicke in das Systemverhalten zu gewinnen, ohne das reale System zu beeinflussen.

• Modellkategorien:

  • Mathematisches Modell

  • Analytisches Modell: Mathematisch lösbar, liefert exakte Ergebnisse, aber oft nur für stark vereinfachte Systeme.

  • Simulation: Numerische, computergestützte Nachbildung, flexibler für komplexe Systeme, liefert Schätzungen statt exakter Lösungen.

  • Physisches Modell

DES Konzepte: Systemzustand

• Eine Sammlung von Variablen, die alle Informationen enthalten, die notwendig sind, um das System zu einem beliebigen Zeitpunkt vollständig zu beschreiben. Dazu gehören beispielsweise die Anzahl der Kunden in jeder Warteschlange, der Status jeder Ressource (beschäftigt, untätig, ausgefallen), der Inhalt von Puffern und andere relevante Zustandsgrößen (z.B. $x$, $y$, $z$, …).

DES Konzepte: Entität (Entity)

• Ein dynamisches Objekt im System, das im Modell explizit dargestellt werden muss, weil es das Systemverhalten aktiv beeinflusst oder von ihm beeinflusst wird. Beispiele sind Personen, Maschinen, Knoten in einem Netzwerk, Pakete, Server, oder Kunden. Entitäten sind oft diejenigen Elemente, die durch das System "fließen".

DES Konzepte: Attribute

• Die charakteristischen Eigenschaften einer gegebenen Entität, die deren Zustand oder Verhalten im System beschreiben. Attribute unterscheiden Entitäten voneinander oder definieren ihre speziellen Merkmale (z.B. die Länge eines Pakets, die Kapazität einer Maschine, die Priorität eines Kunden, die Ankunftszeit eines Produkts).

DES Konzepte: Ereignisse, Ereignisnotizen und Ereignislisten

• Ereignis (Event): Ein spontanes Eintreten zu einem spezifischen Zeitpunkt, das den Zustand eines Systems signifikant ändert. Ereignisse erfolgen instantan und sind die treibende Kraft einer DES (z.B. Ankunft eines Kunden, Ende eines Services, Maschinenausfall, Start einer Aktivität).

• Ereignisnotiz (Event Notice): Ein strukturierter Datensatz, der alle notwendigen Informationen über ein zukünftiges Ereignis enthält. Typischerweise besteht er aus dem Ereignistyp (z.B. "Ankunft", "Serviceende"), der Zeit, zu der es eintreten soll, und allen zugehörigen Daten oder Attributen, die zur Ausführung des Ereignisses erforderlich sind (z.B. die Identität der betroffenen Entität).

• Ereignisliste (Event List): Eine zentrale Datenstruktur in einer DES, die alle Ereignisnotizen für zukünftige Ereignisse enthält, geordnet nach ihrem Zeitpunkt des Eintretens. Sie wird auch als Future Event List (FEL) oder Future Event Set (FES) bezeichnet.

  • Immer chronologisch nach der Ereigniszeit geordnet: Das früheste zukünftige Ereignis steht immer an erster Stelle. Dies ermöglicht es der Simulationsuhr, diskontinuierlich von einem Ereignis zum nächsten zu springen (variable Zeitfortschritt).

DES Konzepte: Uhr (Clock)

• Eine spezielle Variable, die die verstrichene simulierte Zeit repräsentiert. In einer ereignisgesteuerten Simulation springt die Uhr von einem Ereigniszeitpunkt zum nächsten, im Gegensatz zu einer festen Zeitinkrementierung.

DES Konzepte: System-Snapshot

• Eine diskrete Ereignissimulation schreitet fort, indem sie eine Abfolge von System-Snapshots über die Zeit generiert. Jeder Snapshot repräsentiert den vollständigen Zustand des Systems zu einem bestimmten Zeitpunkt $t$. Er beinhaltet:

  • Systemzustand ($(x, y, z, …)$): Aktuelle Werte aller Variablen, die den Zustand des Systems definieren (z.B. Anzahl der Kunden in der Warteschlange, Status der Server).

  • Status aller Entitäten: Die Position, der aktuelle Aktivitätsstatus und die Attribute jeder einzelnen Entität im System (z.B. welcher Kunde wird gerade bedient, welche Eigenschaften hat er).

  • Status aller Sets: Informationen über Warteschlangen, Gruppen oder andere logische Sammlungen von Entitäten, die verwendet werden, um benötigte Informationen zur Berechnung von Leistungskennzahlen zu sammeln.

  • Future Event List (FEL): Eine Momentaufnahme der geplanten zukünftigen Ereignisse zum Zeitpunkt $t$ (z.B. $(3, t<em>1)$ – Ereignis vom Typ $3$ soll zu Zeitpunkt $t</em>1$ eintreten).

  • Statistiken: Die akkumulierten Leistungskennzahlen und Zähler bis zum aktuellen Zeitpunkt (z.B. maximale Warteschlangenlänge, durchschnittliche Auslastung).

• Der Snapshot wird zu einem bestimmten Zeitpunkt $t$ aufgenommen, unmittelbar nachdem ein Ereignis verarbeitet wurde und bevor die Uhr zum nächsten Ereignis fortschreitet.

Ereignis-Scheduling/Zeitfortschrittsalgorithmus

Dieser Algorithmus beschreibt den Kernmechanismus einer diskreten Ereignissimulation:

• Schritt 1: Entfernen der Ereignisnotiz für das unmittelbar bevorstehende Ereignis aus der FEL (z.B. Ereignis $(3, t_1)$). Die FEL ist immer so geordnet, dass das nächste Ereignis an erster Stelle steht.

• Schritt 2: Fortschreiten der Uhr auf die Zeit des unmittelbar bevorstehenden Ereignisses (Setze Uhr = $t_1$). Die Simulationszeit springt also direkt zum nächsten relevanten Zeitpunkt.

• Schritt 3: Ausführen des unmittelbar bevorstehenden Ereignisses:

  • Aktualisierung des Systemzustands (z.B. # Kunden im System wird erhöht oder verringert, Serverstatus ändert sich).

  • Änderung der Entitätsattribute (z.B. ein Kunde erhält einen neuen Status oder eine neue Eigenschaft).

  • Anpassung der Set-Zugehörigkeit nach Bedarf (z.B. eine Entität verlässt eine Warteschlange und tritt in den Service ein).

• Schritt 4: Generieren zukünftiger Ereignisse und Platzieren ihrer Ereignisnotizen in der FEL (z.B. Ereignis $(4, t^*)$). Das aktuelle Ereignis kann neue Ereignisse auslösen (z.B. eine Kundenankunft plant die nächste Kundenankunft, der Beginn eines Services plant dessen Ende).

• Schritt 5: Aktualisieren von Statistiken und Zählern, basierend auf den Änderungen, die durch das Ereignis verursacht wurden.

Future Event List (FEL)

• Alle Ereignisnotizen sind chronologisch in der FEL geordnet, von der Gegenwart bis in die Zukunft.

• Zum aktuellen Zeitpunkt $t$ enthält die FEL alle geplanten Ereignisse, deren Eintrittszeiten in der Zukunft liegen: t < t1 < t2 < t3 < ext{…} < tn

• Das Ereignis $t_1$ ist das unmittelbar bevorstehende Ereignis, d.h. das nächste Ereignis, das eintreten wird und die Simulationsuhr weiterbewegen wird.

• Planung eines Ereignisses: Zu Beginn einer Aktivität wird deren Dauer berechnet (oft probabilistisch) und ein End-of-Activity-Ereignis mit der entsprechenden Endzeit in die Future Event List eingefügt. So wird der Abschluss einer Aktivität im Voraus terminiert.

• Der Inhalt der FEL ändert sich dynamisch während des Simulationslaufs: Ereignisse werden entfernt (wenn sie ausgeführt werden) und neue Ereignisse werden hinzugefügt (wenn sie geplant werden).

• Ein effizientes Management der FEL hat einen großen Einfluss auf die Performance eines Simulationslaufs. Die Wahl geeigneter Datenstrukturen und Algorithmen (z.B. sortierte Listen, binäre Heaps oder Skip-Listen) ist hier entscheidend, da das Einfügen und Extrahieren von Ereignissen häufig erfolgen muss (oft in $O( ext{log } n)$ Zeit, wobei $n$ die Anzahl der Ereignisse in der Liste ist).

Ereignisgenerierung: Ankunft eines Kunden

• Angenommen, zum Zeitpunkt $t = 0$ wird die erste Ankunft generiert und geplant (z.B. für $t=5$).

• Was passiert als Nächstes?

  • Eine zweite Ankunft muss generiert werden, sobald die erste Ankunft verarbeitet wird, oder manchmal präemptiv.

  • Generieren einer Zwischenankunftszeit $a^*$: Diese wird oft aus einer empirischen Verteilung oder einer bekannten Wahrscheinlichkeitsverteilung (z.B. einer Exponentialverteilung für zufällige Ankünfte) gezogen.

  • Berechnen von $t^* = ext{clock} + a^*$: Die tatsächliche Ankunftszeit des neuen Kunden ergibt sich aus der aktuellen Simulationszeit plus der gezogenen Zwischenankunftszeit.

  • Platzieren der Ereignisnotiz für die neue Ankunft bei $t^*$ in der FEL: Das neue Ankunftsereignis wird somit für die Zukunft geplant.

Ereignisgenerierung: Laufzeiten und Ausfallzeiten

• In Systemen mit Ressourcen, die ausfallen oder gewartet werden müssen, erfolgt eine alternierende Generierung von Lauf- und Ausfallzeiten.

• Zur Zeit $0$ wird die erste Laufzeit generiert und ein End-of-Runtime (eor)-Ereignis geplant.

• Immer wenn ein End-of-Runtime (eor)-Ereignis eintritt, wird eine Ausfallzeit (Downtime) generiert und ein End-of-Downtime (eod)-Ereignis geplant. Während der Ausfallzeit ist die Ressource nicht verfügbar.

• Am End-of-Downtime-Ereignis wird eine neue Laufzeit generiert und ein End-of-Runtime-Ereignis geplant, wodurch die Ressource wieder in Betrieb genommen wird.

• Laufzeiten und Ausfallzeiten sind Aktivitäten, die eine bestimmte Dauer haben und den Status der Ressource über einen Zeitraum hinweg definieren.

• End-of-Runtime und End-of-Downtime sind primäre Ereignisse, die den Zustand des Systems schlagartig ändern und die Planung des jeweils nächsten Zustands einleiten.

Simulation stoppen

• Es gibt verschiedene Methoden, um eine Simulationslauf zu beenden:

  • Methode 1 (Fixed-Time Termination): Zum Zeitpunkt $0$ wird ein Stopp-Simulationsereignis für eine bestimmte zukünftige Zeit $T<em>E$ eingeplant. Die Simulation läuft dann deterministisch über das Intervall $[0, T</em>E]$. Diese Methode ist nützlich, wenn man das System über einen festen Zeitraum betrachten möchte.

  • Methode 2 (Event-Based Termination): $T<em>E$ ist nicht im Voraus bekannt, sondern die Lauflänge $T</em>E$ wird durch das Eintreten eines spezifischen Systemzustandes oder Ereignisses bestimmt.

  • Beispiel 1: $T_E$ = Wenn FEL leer ist. Die Simulation endet, wenn keine zukünftigen Ereignisse mehr geplant sind, was oft bei Endlos-Systemen oder bei Simulationen mit begrenzten Entitäten der Fall ist.

  • Beispiel 2: $T_E$ = Wenn der $k$-te Kunde das System verlässt. Diese Methode wird häufig verwendet, um eine ausreichende Anzahl von Beobachtungen zu sammeln, um statistische Konvergenz zu gewährleisten, unabhängig von der verstrichenen Simulationszeit.

Weltansichten (World Views) diskreter Simulationen

• Eine Weltansicht ist eine konzeptionelle Orientierung oder ein Paradigma für den Modellentwickler, das die Art und Weise beeinflusst, wie ein System in einem Simulationsmodell abgebildet wird. Sie definiert die grundlegenden Bausteine und die Logik, die zur Beschreibung des Systemverhaltens verwendet werden.

• Simulationspakete unterstützen typischerweise bestimmte Weltansichten, die die Modellierung erleichtern.

• Hier werden nur Weltansichten für diskrete Simulationen betrachtet, da sie sich auf spezifische Ereignis- und Zeitfortschrittslogiken konzentrieren:

  • Ereignis-Scheduling (Event-scheduling)

  • Prozess-Interaktion (Process-interaction)

  • Aktivitäts-Scanning (Activity-scanning)

Weltansicht: Ereignis-Scheduling (z.B. Excel DES)

• Der Fokus liegt auf Ereignissen. Der Modellierer definiert alle möglichen Ereignistypen und schreibt für jeden Ereignistyp eine Routine, die beschreibt, welche Zustandsänderungen eintreten und welche neuen Ereignisse geplant werden, wenn dieses Ereignis ausgelöst wird.

• Definition, was eine Änderung des Systemzustands verursacht: Jede relevante Änderung ist direkt an ein Ereignis geknüpft.

• Für jedes Ereignis wird eine Routine zur Ausführung geschrieben: Eine Funktion oder ein Codeblock, der die Auswirkungen des Ereignisses auf den Systemzustand umsetzt.

• Variable Zeitfortschritt: Die Simulationsuhr springt direkt von einem Ereigniszeitpunkt zum nächsten relevanten Ereigniszeitpunkt, ohne die dazwischen liegende (ereignislose) Zeit zu diskretisieren.

Weltansicht: Prozess-Interaktion (z.B. simpy)

• Der Modellierer denkt in Prozessen. Ein Prozess repräsentiert den gesamten Lebenszyklus einer Entität (z.B. eines Kunden oder Produkts) beim Durchlaufen des Systems. Dieser Lebenszyklus besteht aus einer Sequenz von Ereignissen, Aktivitäten und Wartezeiten.

• Das Simulationsmodell wird in Bezug auf die Entitäten oder Objekte und deren Lebenszyklus definiert, während sie durch das System fließen, Ressourcen anfordern, bearbeiteten werden und gegebenenfalls in Warteschlangen auf Ressourcen warten müssen.

• Einige Aktivitäten könnten die Nutzung einer oder mehrerer Ressourcen erfordern, deren Kapazitäten begrenzt sind, was zu Wartezeiten führen kann.

• Prozesse interagieren miteinander: Beispielsweise muss ein Prozess (eine Entität) in einer Warteschlange warten, weil die benötigte Ressource durch einen anderen Prozess belegt ist.

• Ein Prozess ist eine zeitlich geordnete Liste von Ereignissen, Aktivitäten und Verzögerungen, einschließlich der Anforderung von Ressourcen, die den gesamten Lebenszyklus einer Entität beim Durchlaufen eines Systems definieren.

• Variable Zeitfortschritt: Auch hier springt die Simulationsuhr von einem Ereignis zum nächsten.

• Simulationspakete (z.B. simpy) handhaben die Interaktion automatisch: Die Komplexität des Ereignis-Schedulings, des Ressourcenmanagements und der Synchronisation zwischen Prozessen wird von der Simulationsumgebung abstrahiert, was die Modellierung oft intuitiver macht.

Weltansicht: Aktivitäts-Scanning

• Der Modellierer konzentriert sich auf Aktivitäten eines Modells und jene Bedingungen, die den Beginn oder das Ende einer Aktivität erlauben (z.B. "Der Server ist untätig UND ein Kunde ist anwesend" ist die Bedingung für den Beginn eines Services).

• Bei jedem Uhrzeitfortschritt (der hier typischerweise fest ist) werden die Bedingungen für jede mögliche Aktivität im System überprüft. Wenn die Bedingungen wahr sind, beginnt die entsprechende Aktivität oder schreitet fort.

• Fester Zeitfortschritt (Fixed Time Advance): Die Simulationsuhr wird in festen, kleinen Schritten vorangetrieben (z.B. um $1$ Zeiteinheit). Bei jedem Schritt wird der Systemzustand "gescannt".

• Nachteil: Das wiederholte Scannen aller Aktivitäten bei jedem kleinen Zeitschritt, um herauszufinden, ob eine Aktivität beginnen oder enden kann, ist sehr ineffizient und führt zu langsamen Laufzeiten, insbesondere bei Systemen mit vielen Aktivitäten oder weiten Zeitspannen zwischen relevanten Ereignissen. Daher wird diese Weltansicht seltener für komplexe DES verwendet.