Die Herausforderung
von Thomas J. Schriber (Universität von Michigan), Daniel T. Brunner (Dan Brunner Associates) und Jeffrey S. Smith (Auburn University)
Vorgestellt auf der Winter Simulation Conference 2017
Dieses Papier bietet Simulationspraktikern und -nutzern eine Einführung in die Funktionsweise ereignisdiskreter Simulationssoftware. Die Themen umfassen ereignisdiskrete Systeme, Entitäten, Ressourcen, Steuerelemente und Operationen, Simulationsläufe, Entitätszustände, Entitätslisten und deren Verwaltung. Die Implementierungen dieser generischen Ideen in AutoMod, SLX, ExtendSim und Simio werden beschrieben. Der Beitrag schließt mit mehreren Beispielen, die zeigen, warum es für Modellierer wichtig ist, zu wissen, wie ihre Simulationssoftware funktioniert, einschließlich der Diskussion von AutoMod, SLX, ExtendSim, Simio, Arena, ProModel und GPSS/H.
1 Einleitung
Beim Unterrichten von ereignisdiskreter Simulationssoftware wird häufig ein "Black Box"-Ansatz verfolgt. Die äußeren Merkmale der Software werden untersucht, aber das Fundament, auf dem die Software basiert, wird nur kurz gestreift oder ganz ignoriert (aus Zeitmangel). Die bei der Implementierung der Grundlage getroffenen Entscheidungen und die Auswirkungen dieser Entscheidungen auf die schrittweise Ausführung des Modells werden möglicherweise überhaupt nicht untersucht. Der Modellierer ist dann möglicherweise nicht in der Lage, die Dinge zu Ende zu denken, wenn es darum geht, gute Ansätze für die Modellierung komplexer Situationen zu entwickeln, interaktive Werkzeuge zu verwenden, um Fehlerbedingungen zu verstehen, die während der Modellentwicklung auftreten, und interaktive Werkzeuge zu verwenden, um zu überprüfen, ob die komplexe Systemlogik korrekt modelliert wurde. Ziel ist es daher, die logischen Grundlagen der ereignisdiskreten Simulation zu beschreiben und dieses Material anhand verschiedener Implementierungen von Software für die ereignisdiskrete Simulation zu veranschaulichen.
In den Abschnitten 2, 3 und 4 erläutern wir das Wesen der ereignisdiskreten Simulation, grundlegende Simulationskonstrukte wie Entitäten, Ressourcen, Steuerelemente und Operationen sowie die Modellausführung. In Abschnitt 5 werden vier spezifische Implementierungen von Regeln zur Verwaltung von Entitäten erörtert. Schließlich werden in Abschnitt 6 verschiedene Aspekte des "Warum es wichtig ist" untersucht. In diesem Dokument werden Begriffe, die wir definieren, bei der ersten Verwendung fett gedruckt. Werkzeugspezifische Begriffe werden in Großbuchstaben oder gegebenenfalls in GANZEN GROSSBUCHSTABEN geschrieben.
Dieses Papier ist eine überarbeitete Version eines ähnlichen Papiers, das ursprünglich in den Proceedings der Winter Simulation Conference 1996 erschien (Schriber und Brunner 1996). Eine Version des Papiers von 1996 wurde seit 1996 jedes Jahr auf der Konferenz vorgestellt, mit gelegentlichen Aktualisierungen, wie z.B. der Änderung der im Detail behandelten Sprachen. Das Papier von 1996 behandelte zum Beispiel die Regeln für die Verwaltung von Entitätslisten und "warum das wichtig ist" für SIMAN (Arena), ProModel und GPSS/H. (Eine wesentlich erweiterte Version des Papiers von 1996 mit Abbildungen, Flussdiagrammen und zusätzlichen Erklärungen findet sich in Schriber und Brunner (1998)).
Die Lösung
2 Diskrete Ereignissimulation in der Transaktionsfluss-Weltanschauung
Die "Transaktionsfluss-Weltanschauung" bildet häufig die Grundlage für die ereignisdiskrete Simulation. In dieser Weltsicht wird ein System als bestehend aus diskreten Verkehrseinheiten visualisiert, die sich von Punkt zu Punkt im System bewegen (fließen) und dabei miteinander um die Nutzung knapper (kapazitätsbeschränkter) Ressourcen konkurrieren. Die Verkehrseinheiten werden manchmal als "Transaktionen" bezeichnet, was zu dem Ausdruck "Transaktionsfluss" führt. Auf zahlreiche Systeme trifft die obige Beschreibung zu. Dazu gehören Systeme in den Bereichen Fertigung, Materialtransport, Dienstleistungen, Gesundheitswesen, Kommunikation und Informationsverarbeitung sowie andere allgemeine Warteschlangensysteme.
Grundsätzlich handelt es sich bei einer ereignisdiskreten Simulation um eine Simulation, bei der sich der Zustand eines Modells nur zu einer diskreten, aber möglicherweise zufälligen Reihe von simulierten Zeitpunkten, den so genannten Ereigniszeiten, ändert. Häufig müssen zwei oder mehr Verkehrseinheiten zu ein und demselben Zeitpunkt manipuliert werden. Eine solche "gleichzeitige" Bewegung des Verkehrs wird erreicht, indem die Verkehrseinheiten zu diesem Zeitpunkt nacheinander manipuliert werden. Dies führt zu logischer Komplexität, da es Fragen über die spezifische Echtzeit-Reihenfolge aufwirft, in der zwei oder mehr Verkehrseinheiten zu einem bestimmten simulierten Zeitpunkt verarbeitet werden sollen.
Die Herausforderungen, denen sich ein Modellierer gegenübersieht, verschärfen sich für den Designer einer Modellierungssprache. Der Designer muss die logischen Anforderungen der ereignisdiskreten Simulation in einer verallgemeinerten Weise berücksichtigen. Es bestehen Wahlmöglichkeiten und Kompromisse. Obwohl sich ereignisdiskrete Simulationssprachen im Großen und Ganzen ähneln, können sie sich in subtilen, aber wichtigen Details unterscheiden. In diesem Beitrag wollen wir diesen Begriff näher erläutern und konkrete Beispiele anführen. Zuvor werden jedoch in den folgenden Abschnitten weitere allgemeine Simulationskonzepte vorgestellt.
3 Entitäten, Ressourcen, Steuerelemente und Operationen
Der Begriff Entität wird hier verwendet, um eine Verkehrseinheit (eine "Transaktion") innerhalb eines Modells zu bezeichnen. Entitäten initiieren und reagieren auf Ereignisse. Ein Ereignis ist ein momentanes Ereignis, das den Zustand eines Modells (oder Systems) verändert. In einem Modell eines Bestellsystems kann beispielsweise das Eintreffen einer Bestellung (ein Ereignis) simuliert werden, indem eine Entität in das Modell gebracht wird. Es gibt zwei mögliche Arten von Entitäten, die hier als externe Entitäten und interne Entitäten bezeichnet werden. Externe Entitäten sind solche, deren Erzeugung und Bewegung vom Modellierer explizit veranlasst wird (Beispiel: Eintreffen eines Auftrags an einer Auftragsabwicklungsstelle). Im Gegensatz dazu werden interne Entitäten implizit von der Simulationssoftware erzeugt und manipuliert. Interne Entitäten werden beispielsweise in einigen Sprachen verwendet, um simulierte Maschinenausfälle auszulösen und Maschinenpläne zu implementieren, während externe Entitäten verwendet werden können, um den Einsatz von Maschinen zur Bearbeitung von Teilen zu simulieren.
Der Begriff Ressource bezeichnet ein Systemelement, das eine Leistung erbringt (z. B. eine Bohrmaschine, ein fahrerloses Transportfahrzeug, ein Arbeiter oder Platz in einem Eingabepuffer). Entitäten nutzen in der Regel Ressourcen (z. B. beansprucht eine in Bearbeitung befindliche Entität einen Platz in einem Eingangspuffer und nimmt dann ein fahrerloses Transportsystem in Anspruch, um die Entität zum Eingangspuffer zu bewegen). Die Kapazität von Ressourcen ist in der Regel begrenzt, so dass Entitäten um ihre Nutzung konkurrieren und manchmal warten müssen, um sie zu nutzen, was zu Verzögerungen führt (Warteschlangenbildung). Der Begriff Steuerelement bezeichnet ein Konstrukt, das andere Arten von Verzögerungen oder logische Alternativen basierend auf dem Zustand eines Systems unterstützt. Steuerelemente können die Form von Schaltern, Zählern, Benutzerdatenwerten und Systemdatenwerten haben, die in das Modellierungswerkzeug eingebaut sind. Komplexe Bedingungen können mit arithmetischen und/oder booleschen Ausdrücken ausgewertet werden, die den Zustand der relevanten Steuerelemente untersuchen.
Eine Operation ist ein Schritt (oder eine Reihe von Schritten), der von oder an einer Entität ausgeführt wird, während sie sich durch ein System bewegt. Zu den Operationen, die auf ein Schiff in einem Hafen anwendbar sind, könnten folgende gehören: Ankunft im Hafen; Anfordern eines Liegeplatzes; Einnehmen eines Liegeplatzes; Anfordern eines Schleppers; Einnehmen eines Schleppers; Einfahren in den Liegeplatz; Freigeben des Schleppers; Beladen mit Ladung; Anfordern eines Schleppers; Ausfahren aus dem Liegeplatz; Freigeben des Liegeplatzes; Einfahren ins offene Wasser; Freigeben des Schleppers; Auslaufen.
4 Überblick über die Ausführung des Modells
Ein Simulationsprojekt beinhaltet die Durchführung von Experimenten. Experimente werden durch die Verwendung von Alternativen in der Logik und/oder den Eingabedaten eines Modells unterschieden. Zum Beispiel können im Modell eines Produktionssystems alternative Regeln für die Reihenfolge der Teile und/oder die Anzahl der verschiedenen Maschinentypen (Ressourcen) ausprobiert werden. In ähnlicher Weise könnte die Anzahl der Be- und Entladeplätze in einem Hafen variiert werden, um die Auswirkungen auf die Systemleistung zu bewerten. Jedes Experiment besteht aus einer oder mehreren Replikationen (Versuchen). Eine Replikation ist eine Simulation, die die Modelllogik und die Daten des Experiments verwendet, aber einen eigenen Satz von Zufallszahlen verwendet und so eindeutige statistische Ergebnisse erzeugt, die als Teil eines Satzes solcher Replikationen (die alle unabhängig sind) analysiert werden können. Eine Replikation besteht darin, das Modell zu initialisieren, es laufen zu lassen, bis eine Bedingung für das Ende des Laufs erfüllt ist, und die Ergebnisse zu melden. Diese "Ausführungsphase" wird als Lauf bezeichnet.
Während eines Laufs verfolgt die Simulationsuhr (ein intern verwalteter, gespeicherter Datenwert) den Ablauf der simulierten Zeit. Die Uhr läuft während des Laufs (automatisch) in diskreten Schritten (in der Regel von ungleicher Größe) weiter. Nachdem alle möglichen Aktionen zu einem bestimmten simulierten Zeitpunkt durchgeführt worden sind, wird die Uhr auf den Zeitpunkt des nächstmöglichen Ereignisses vorgestellt. Dann werden die entsprechenden Handlungen zu diesem neuen simulierten Zeitpunkt ausgeführt usw. Die Ausführung eines Laufs hat also im Wesentlichen die Form einer zweistufigen Schleife: "Diese beiden Phasen werden so lange wiederholt, bis eine Bedingung für das Ende des Laufs eintritt (in der Regel eine vom Modellierer festgelegte simulierte Zeit, Anzahl der verarbeiteten Entitäten oder eine andere Bedingung). Diese beiden Phasen werden hier als Entity-Movement-Phase (EMP) bzw. als Clock-Update-Phase (CUP) bezeichnet.
4.1 Entitätszustände
Während der Ausführung der Simulation wandern die Entitäten von Zustand zu Zustand, während sie sich durch das Modell bewegen. Die fünf typischerweise verwendeten Zustände sind:
Aktiv - Der Zustand der sich gerade bewegenden Entität ist der aktive Zustand. Mit "sich gerade bewegende Entität" meinen wir die Entität, die gerade die Entscheidungslogik im Modell ausführt. Zu jedem Zeitpunkt der Wanduhrzeit bewegt sich nur eine Entität. Diese Entität bewegt sich, bis sie auf eine Verzögerung der einen oder anderen Art stößt. Dann wechselt sie in einen anderen Zustand.
Bereit - Während einer Entitätsbewegungsphase kann mehr als eine Entität bereit sein, sich zu bewegen, und dennoch kann sich nur eine Entität nach der anderen bewegen (im aktiven Zustand sein). Der Zustand "bereit" ist der Zustand der Einheiten, die darauf warten, während der aktuellen Bewegungsphase in den aktiven Zustand überzugehen.
Zeitverzögert - Der zeitverzögerte Zustand ist der Zustand von Einheiten, die darauf warten, dass ein bekannter zukünftiger simulierter Zeitpunkt erreicht wird, damit sie dann (wieder) in den Bereitschaftszustand übergehen können. Eine "Teil"-Einheit befindet sich z. B. in einem zeitverzögerten Zustand, während sie auf den zukünftigen simulierten Zeitpunkt wartet, zu dem ein an ihr durchgeführter Vorgang beendet wird.
Bedingungsverzögert - Der bedingungsverzögerte Zustand ist der Zustand von Entitäten, der verzögert wird, bis eine bestimmte Bedingung eintritt, z. B. könnte eine "Teil"-Entität im bedingungsverzögerten Zustand warten, bis sie an der Reihe ist, eine Maschine zu benutzen. Zustandsverzögerte Entitäten werden automatisch aus dem zustandsverzögerten Zustand in den Bereitschaftszustand überführt, wenn die angegebenen Bedingungen dies zulassen.
Ruhend - Manchmal ist es wünschenswert oder notwendig, Entitäten in einen Zustand zu versetzen, aus dem keine automatische Flucht durch Änderungen der Modellbedingungen ausgelöst wird. Wir nennen diesen Zustand den ruhenden Zustand. Entitäten im ruhenden Zustand sind auf die vom Modellierer bereitgestellte Logik angewiesen, um sie vom ruhenden Zustand in den bereiten Zustand zu überführen. Job-Ticket-Entitäten können beispielsweise in einen ruhenden Zustand versetzt werden, bis eine Operator-Entität entscheidet, welches Job-Ticket als nächstes gezogen werden soll, und die Job-Ticket-Entität daraufhin in den bereiten Zustand überführt wird. In diesem Fall sind die spezifischen Bedingungen, die bei der Auswahl des Jobtickets gelten, möglicherweise erst dann bekannt, wenn der Zeitpunkt gekommen ist, an dem die Betreiberinstanz ein Jobticket auswählen muss.
4.2 Strukturen der Entitätsverwaltung
In unserem generischen Modell verwalten wir die Entitäten, indem wir eine aktive Entität und eine Reihe von Entitätslisten bestimmen. Die aktive Entität (die Entität im aktiven Zustand) bewegt sich ununterbrochen, bis sie auf einen (versuchten) Schritt trifft, der sie dazu veranlasst, in einen anderen Entitätszustand zu wechseln (sie in eine andere Liste zu übertragen) oder sie aus dem Modell zu entfernen. Eine Ready-State-Entität wird dann die nächste Active-State-Entität. Schließlich gibt es zum aktuellen Zeitpunkt keine Ready-State-Entitäten mehr. Das EMP endet dann und ein CUP beginnt. Die folgenden Listen werden verwendet, um die Entitäten zu organisieren. (Die Dynamik der Bewegung von Entitäten zwischen diesen Listen wird in einer PowerPoint-Foliensequenz während der Wintersimulationskonferenz veranschaulicht, die in Verbindung mit diesem Tutorium gehalten wird).
Liste der aktuellen Ereignisse - Entitäten, die sich im Bereitschaftszustand befinden, werden in einer einzigen Liste geführt, die wir als Liste der aktuellen Ereignisse (CEL) bezeichnen. In die CEL wandern Entitäten aus der Liste zukünftiger Ereignisse, aus Verzögerungslisten und aus benutzerverwalteten Listen (jeweils unten beschrieben). Darüber hinaus beginnen Entitäten, die aus der Entität "Active-State" geklont werden, ihre Existenz normalerweise in der CEL. CEL-Entitäten werden im Allgemeinen in der FIFO-Reihenfolge (first-in, first-out) geordnet. Einige Softwaretools bieten ein eingebautes Entitätsattribut Priorität, mit dem Entitäten auf der CEL nach Priorität geordnet werden können (wobei Gleichstände durch FIFO aufgelöst werden).
Liste zukünftiger Ereignisse - Entitäten im zeitverzögerten Zustand gehören zu einer einzigen Liste, in die sie zu Beginn ihrer zeitbasierten Verzögerung eingefügt werden. Diese Liste, die hier als Liste zukünftiger Ereignisse (FEL) bezeichnet wird, ist in der Regel nach zunehmender Bewegungszeit der Entitäten geordnet. Die Bewegungszeit ist der simulierte Zeitpunkt, zu dem eine Entität versuchen soll, sich erneut zu bewegen (z. B. das Ende der Behandlungszeit für einen Patienten in einer Klinik oder das Ende der Bearbeitungszeit für ein Teil in einem Fertigungssystem). Zum Zeitpunkt des Einsetzens der Entität in den FEL wird die Bewegungszeit der Entität berechnet, indem der Wert der Simulationsuhr zu der bekannten (abgetasteten) Dauer der zeitlichen Verzögerung addiert wird. Nach Beendigung eines EMP setzt der CUP den Wert der Uhr auf die Bewegungszeit der höchstrangigen (kleinsten) Entität des FEL. Diese Einheit wird dann von der FEL an die CEL übertragen, wobei sie aus dem zeitverzögerten Zustand in den Bereitschaftszustand übergeht und die Voraussetzungen für den Beginn des nächsten EMP schafft. Die vorstehende Aussage setzt voraus, dass es keine anderen Einheiten auf der FEL gibt, deren Bewegungszeit mit dem aktualisierten Wert der Uhr übereinstimmt. Im Falle von Zeitverschiebungen übertragen einige Werkzeuge alle zeitlich gebundenen Entitäten von der FEL zur CEL während eines einzigen CUP, während andere Werkzeuge den Ansatz "nur eine Entitätsübertragung pro CUP" wählen. Sprachen, die interne Entitäten bereitstellen, verwenden normalerweise die FEL, um die Zeitanforderungen dieser Entitäten zu unterstützen. (Die FEL umfasst dann interne und externe Entitäten).
Verzögerungslisten - Listen (es können viele sein) von Entitäten im Zustand "verzögert" werden als Verzögerungslisten bezeichnet. Diese Entitäten warten (z. B. darauf, dass sie an der Reihe sind, eine Maschine zu benutzen), bis ihre Verzögerung aufgelöst ist, so dass sie automatisch in den Bereitschaftszustand der CEL überführt werden können. Verzögerungslisten, die im Allgemeinen automatisch von der Simulationssoftware erstellt werden, werden mit einer von zwei Arten des Wartens verwaltet. Wenn eine Verzögerung leicht mit Modellereignissen in Verbindung gebracht werden kann, die die Verzögerung auflösen könnten, dann kann die Verzögerungsliste mit Hilfe von Wartezeiten verwaltet werden. Nehmen wir zum Beispiel an, der Status einer Maschine ändert sich von "besetzt" zu "frei". Daraufhin kann die Software automatisch die nächste wartende Entität aus der entsprechenden Verzögerungsliste entfernen und sie in den Bereitschaftszustand auf der CEL setzen. Verbundenes Warten ist der gängige Ansatz, um bedingte Verzögerungen zu verwalten. Wenn die Verzögerungsbedingung zu komplex ist, um sie einfach mit Ereignissen zu verknüpfen, die sie auflösen könnten, kann abgefragtes Warten verwendet werden. Beim abgefragten Warten prüft die Software routinemäßig, ob Einheiten von einer oder mehreren Verzögerungslisten in den Bereitschaftszustand überführt werden können. Zu den komplexen Verzögerungsbedingungen, für die "polled waiting" nützlich sein kann, gehören boolesche Kombinationen von Zustandsänderungen, z. B. ein Liegeplatz ist leer und ein Schlepper ist untätig.
Benutzerverwaltete Listen Listen -(es können viele sein) von Entitäten im ruhenden Zustand werden als benutzerverwaltete Listen bezeichnet. Der Modellierer muss Maßnahmen ergreifen, um solche Listen zu erstellen, und muss in der Regel die Logik bereitstellen, die erforderlich ist, um Entitäten in und aus den Listen zu übertragen. Abgesehen von sehr einfachen Ein-Zeilen-, Ein-Server-Service-Punkten in einem System hat die zugrundeliegende Software keine Möglichkeit zu wissen, warum Entitäten überhaupt in benutzerverwaltete Listen aufgenommen wurden, und hat daher keine Grundlage für das automatische Entfernen von Entitäten aus solchen Listen.
5 Implementierung in vier Werkzeugen
Die Werkzeuge, die hier zur Erläuterung der Implementierungsdetails ausgewählt wurden, sind AutoMod (Phillips 1997), SLX (Henriksen 2000; Schulze 2008), ExtendSim (Imagine That Incorporated 2015; Krahl 2012) und Simio (Kelton et al., 2014). In einer früheren Version dieses Papiers (Schriber und Brunner 1996) wurden SIMAN (Arena) (Kelton et al., 2014), ProModel (ProModel Corporation 2015) und GPSS/H (Henriksen und Crain 2000) ähnlich ausführlich behandelt. Wir halten diese Tools für repräsentativ, aber natürlich nicht für erschöpfend (siehe Swain 2015 für einen zweijährlichen Überblick über die vielen verfügbaren Tools).
5.1 AutoMod
Die Liste der aktuellen Ereignisse wird in AutoMod als Current Event List (CEL) bezeichnet (siehe Tabelle 1). Geklonte Ladungen, Ladungen, die die FEL aufgrund einer Taktaktualisierung verlassen, und Ladungen, die aus Auftragslisten bestellt werden, werden sofort in die CEL eingefügt. Die Einfüge-Regel lautet, zuerst nach Priorität zu ordnen (Priorität ist ein eingebautes Attribut eines jeden Loads) und dann FIFO innerhalb der Priorität. Wenn die CEL leer wird, wird die Condition Delay List (siehe unten) geprüft, und die Loads können von dort in die CEL übertragen werden. Dies wird so lange fortgesetzt, bis die CEL leer ist und keine Ladungen mehr übertragen werden können.
Die AutoMod Future Event List (FEL) ist wie die Future Event List in anderen Tools. Die Ladungen treffen in der FEL zeitverzögert ein, indem eine WAIT FOR-Anweisung ausgeführt wird. AutoMod erlaubt die Angabe von Zeiteinheiten (Tag, Std, Min, Sek) in einer WAIT FOR-Anweisung. Der AutoMod CUP entfernt mehrere Ladungen aus der FEL, wenn sie für den frühesten Verschiebungszeitpunkt gebunden sind, und fügt sie nacheinander an der entsprechenden Stelle der CEL ein. Es gibt auch interne Entitäten in AutoMod, so genannte logische Ladungen, die z. B. auf die FEL warten, um geplante Schichtpausen auszulösen.
Verzögerungslisten (Delay Lists, DL's) sind Listen von Loads, die darauf warten, Kapazität zu beanspruchen, die von einem der fünf Finite-Capacity-Elemente (Ressource, Warteschlange, Block, Zähler oder Process Traffic Limit; siehe Tabelle 1) bereitgestellt wird. Jedem endlichen Kapazitätselement innerhalb des Modells ist ein DL zugeordnet. Das Warten, das sich in diesen fünf Fällen ergibt, ist ein verbundenes Warten. Immer wenn Kapazität frei wird, wird eine Last aus dem Kopf der DL des Elements versuchsweise auf die CEL gesetzt (aber ein Platzhalter wird auf der DL belassen). Wenn diese Last während der EMP angetroffen wird, versucht sie, die angeforderte Kapazität zu beanspruchen. Gelingt dies nicht (z. B. weil zwei Einheiten angefordert werden, aber nur eine frei ist), wird die Last wieder an ihrem ursprünglichen Platz in der DL platziert (dies ist ein Standardverhalten, das der Modellierer außer Kraft setzen kann. Siehe Abschnitt 6.2 für eine allgemeinere Diskussion). Unmittelbar nach dieser Auswertung wird, falls noch freie Kapazität vorhanden ist, die nächste Last (falls vorhanden) auf dem betreffenden DL auf die CEL gelegt. Dann wird die Verarbeitung der aktiven Last fortgesetzt, gefolgt von der Auswertung dieser nächsten vorläufig platzierten Last. Und so weiter, vorläufig, für jede nächste Last (falls vorhanden) während des EMP.
Für das bedingte Warten, abgesehen von den fünf oben beschriebenen Fällen, verfügt AutoMod über eine WAIT UNTIL-Anweisung, die zu einem abgefragten Warten führt. WAIT UNTIL-Bedingungen können mit Booleschen Operatoren geklammert werden. Wenn ein Load eine WAIT UNTIL-Anweisung ausführt und die Bedingung falsch ist, wird der Load auf eine einzige globale AutoMod-Liste gesetzt, die so genannte Condition Delay List (CDL). Nachdem die CEL geleert wurde, aber bevor die Simulationsuhr aktualisiert wird, werden alle Loads auf der CDL in die CEL verschoben (eigentlich "wird" die CDL zur CEL), wenn es eine Zustandsänderung für mindestens ein Element desselben allgemeinen Typs (z. B. Warteschlange) gegeben hat, auf das ein beliebiger Load auf der CDL wartet (dieser Mechanismus ist in erster Linie "gepollt", wobei der Polling-Prozess durch eine Zustandsänderung mindestens eines Elements desselben allgemeinen Typs ausgelöst wird).
Wenn die CEL nun nicht mehr leer ist, wird die EMP fortgesetzt. Wenn die Bedingung, auf die ein CEL Load wartet, noch nicht erfüllt ist, verschiebt AutoMod diesen Load vom CEL zurück in die CDL. In manchen Fällen kann die CDL während einer EMP mehrfach geleert werden, bis schließlich die CEL geleert wurde, ohne dass eine Zustandsänderung in Bezug auf eine Last auf der CDL ausgelöst wurde. Dann kommt es zu einem CUP. Aufgrund des Potenzials für wiederholte Listenmigrationen mit WAIT UNTIL empfiehlt der AutoMod-Anbieter die Verwendung von Auftragslisten oder anderen expliziten Kontrollmechanismen zur Verwaltung komplexer Wartezeiten.
AutoMod implementiert den Ruhezustand mit Order Lists, die vom Benutzer verwaltete Listen von Loads sind. Nachdem eine Ladung sich selbst auf eine Bestellliste gesetzt hat (durch Ausführen einer WAIT TO BE ORDERED-Aktion), kann sie nur durch eine andere Ladung (oder ein anderes aktives Modellelement wie ein Fahrzeug) entfernt werden, die eine ORDER-Aktion ausführt. Eine ORDER-Aktion kann eine Menge von Ladungen oder eine Bedingung angeben, die für eine bestimmte Ladung erfüllt sein muss, wenn diese Ladung bestellt werden soll, oder beides. Erfolgreich bestellte Ladungen werden sofort auf der CEL platziert (eine nach der anderen, je nachdem, wie sie aus der Bestellliste ausgewählt wurden, und in der CEL nach Priorität geordnet, wobei Prioritätsbindungen FIFO aufgelöst werden). Auftragslisten können Leistungsverbesserungen gegenüber CDL-Warteschlangen erzielen, da Auftragslisten nur auf ausdrückliche Anforderung hin gescannt werden. AutoMod-Bestelllisten bieten mehrere interessante Möglichkeiten, darunter: die Möglichkeit, dass eine bestellende Last eine Rückbestellung aufgibt, wenn die ORDER-Menge nicht befriedigt wird; die Möglichkeit, dass eine Last auf einer Bestellliste angewiesen wird, mit der nächsten Aktion fortzufahren, anstatt mit einem Prozess (diese Funktion ist nützlich für Control Handshaking); und die Möglichkeit, für jede Last auf der Bestellliste eine Funktion aufzurufen (durch Verwendung der ORDER...SATISFYING-Aktion).
AutoMod verfügt über mehrere Materialhandhabungskonstrukte, die in die Lastbewegung integriert sind. Für Fahrzeugsysteme gibt es drei weitere Arten von Listen (nicht in Tabelle 1 enthalten). Ladungen auf Lastbereitschaftslisten (LRL) (eine Liste pro Fahrzeugsystem) warten darauf, von einem Fahrzeug abgeholt zu werden. Von einem Fahrzeug beanspruchte (aber noch nicht abgeholte) Ladungen befinden sich in der Vehicle Claim List (VCL) des Fahrzeugs. Beanspruchte Ladungen, die bereits abgeholt wurden, befinden sich in der Vehicle Onboard List (VOL) des Fahrzeugs. Das Fahrzeug wird dann zur aktiven "Ladung" und bewegt sich zwischen den AutoMod-Listen (FEL, CEL und möglicherweise DL) und nicht den Ladungen selbst.
5.2 SLX
SLX ist eine hierarchische Sprache, in der sich die eingebauten Primitive auf einer niedrigeren Ebene befinden als in den meisten anderen Simulationssprachen, was die Definition des Verhaltens vieler Systemelemente durch den Benutzer (oder Entwickler) erleichtert. Diese Entwurfsphilosophie ermöglicht es dem SLX-Benutzer (oder -Entwickler), Modellierungswerkzeuge auf höherer Ebene zu erstellen, deren Konstrukte ein genau definiertes, veränderbares Verhalten aufweisen. Äquivalente für die generischen Begriffe für Benutzer von SLX auf niedriger Ebene sind in Tabelle 2 aufgeführt. SLX verwendet zum Beispiel Kontrollvariablen, die als Kontrollelemente fungieren. Der Modifikator "control" kann an eine Variable beliebigen Datentyps (Integer, Real, String, etc.) angehängt werden. Eine Steuervariable kann global oder eine lokale Variable sein, die in der Klassendefinition eines Objekts deklariert ist. (Eine in einer Klasse deklarierte Variable ist in anderen Tools ein Attribut).
SLX hat zwei Arten von Objekten: Aktive und Passive. Die beiden unterscheiden sich durch das Vorhandensein von Aktionen - ausführbaren Anweisungen - in der Klassendefinition eines aktiven Objekts (auch ohne Aktionen sind passive Objekte als benutzerdefinierte komplexe Datenstrukturen nützlich). Tabelle 3 zeigt, wie SLX-basierte Werkzeuge auf höherer Ebene die definitorischen Fähigkeiten von SLX nutzen können.
Die Liste der aktuellen Ereignisse wird in SLX "Current Events Chain" (CEC) genannt. Die Mitglieder der CEC erhalten den interessanten Namen Puck. Was ist ein Puck? SLX trennt das Konzept eines aktiven Objekts (mit seinen zugehörigen lokalen Daten) von einem Puck, der die "bewegliche Entität" ist, die die Aktionen ausführt, ihre eigenen Entitätsplanungsdaten trägt und von Liste zu Liste wandert. Der Effekt dieser Trennung ist, dass ein einzelnes Objekt mehr als einen Puck "besitzen" kann. Alle Pucks, die einem einzelnen Objekt gehören, teilen sich die lokalen Daten (Attribute) des Objekts. Eine Anwendung dieser "lokalen Parallelität" (im Vergleich zur "globalen Parallelität", die von "Clone"- oder "Split"-Aktionen in anderen Sprachen geboten wird) ist zum Beispiel die Verwendung eines zweiten Pucks, um eine Sperrzeit zu simulieren, während der ursprüngliche Puck auf eine Bedingung wartet. (Tritt die Bedingung ein, bevor die Überbrückungszeit verstrichen ist, kommt es nicht zu einer Überbrückung; andernfalls kommt es doch zu einer Überbrückung).
Die Aktivierung eines neuen Objekts erzeugt einen Puck und setzt diesen in Aktion. In vielen Fällen werden keine zusätzlichen Pucks für dieses Objekt erstellt, und die Kombination aus einem aktiven Objekt und seinem Puck bildet das Äquivalent einer Entität (passive Objekte haben keine Aktionen und besitzen daher keine Pucks). Neu aktivierte Pucks, Pucks, die den FEC aufgrund einer Zeitaktualisierung verlassen, und reaktivierte Pucks (siehe unten) werden auf dem CEC platziert, geordnet nach der Priorität (FIFO). Das CEC ist leer, wenn ein EMP endet.
Die SLX Future Events Chain (FEC) ist wie die Listen zukünftiger Ereignisse in anderen Tools. Pucks kommen in der FEC im zeitverzögerten Zustand an, indem eine ADVANCE-Anweisung ausgeführt wird. Der SLX CUP entfernt mehrere Pucks aus der FEC, wenn sie für den frühesten Zugzeitpunkt gebunden sind, und fügt sie nacheinander an der entsprechenden Stelle der CEC ein. Da die SLX-Kernel-Funktionalität keine Stillstandszeiten oder gar eine sich wiederholende Puck-Erzeugung (geplante Ankünfte) vorsieht, laufen alle Aktivitäten auf dem SLX-FEC so ab, wie vom Entwickler des SLX-Modells festgelegt. Allgemeiner ausgedrückt: Wenn ein Benutzer ein Modell (oder einen Model Builder) verwendet, das von einem Entwickler definierte Primitive auf höherer Ebene enthält, ist es wahrscheinlich, dass alle möglichen Dinge hinter den Kulissen ablaufen, die dem Blick des Benutzers auf höherer Ebene verborgen bleiben. Delay Lists (DL's) in SLX sind Listen von Pucks, die (über WAIT UNTIL) auf Zustandsänderungen in einer beliebigen Kombination von Kontrollvariablen und dem Simulationstaktwert warten. Ein Puck, der auf eine zusammengesetzte Bedingung wartet, die zwei oder mehr Kontrollvariablen beinhaltet, wird in mehr als einer DL aufgeführt. Alle von den Entwicklern definierten übergeordneten Konstrukte können diesen Mechanismus nutzen. Jede Kontrollvariable (die eine lokale Variable sein kann, in diesem Fall gibt es eine für jedes Objekt in der Klasse) hat eine eigene DL, die mit ihr verbunden ist.
Eine DL wird in der Reihenfolge des Einfügens geordnet. Alle Pucks auf einer DL werden entfernt, wenn die zugehörige Kontrollvariable ihren Wert ändert, und einer nach dem anderen in das CEC eingefügt. Entfernte Pucks, die auf zusammengesetzte Bedingungen warten, werden auch versuchsweise aus jeder der anderen Verzögerungslisten entfernt, zu denen sie gehören. Wenn diese Pucks während der EMP auf dem CEC angetroffen werden, werden diejenigen, die ihre WAIT UNTIL nicht bestehen, in die Verzögerungsliste(n) für die Kontrollvariablen zurückgegeben, die noch zur Falschheit der Bedingung beitragen. Bei Bedingungen, die eine Taktreferenz enthalten, wird der Puck gegebenenfalls in den FEC eingefügt, wobei er vorzeitig aus dem FEC entfernt werden kann, wenn die Bedingung aufgrund von Änderungen anderer Kontrollvariablen wahr wird. Dieser auf Kontrollvariablen basierende Wartemechanismus auf niedriger Ebene ist der Standardansatz von SLX für die Modellierung aller Arten von einfachen oder zusammengesetzten bedingungsverzögerten Zuständen.
SLX behandelt den ruhenden Zustand auf eine einzigartige Weise. Anstatt den Puck aus dem aktiven Zustand in eine vom Benutzer verwaltete Liste zu verschieben und ihn in einer einzigen Operation zu suspendieren, unterteilt SLX diese Operation in zwei Teile. Zunächst tritt der Puck normalerweise einem Set bei. Der Beitritt zu einem Set führt jedoch nicht automatisch zur Suspendierung des Pucks. Ein Puck kann einer beliebigen Anzahl von Gruppen angehören. Die Mitgliedschaft in einem Set ermöglicht lediglich jedem anderen Puck den Zugriff auf die Mitgliedspucks. Um in den Ruhezustand zu gelangen, führt ein Puck eine WAIT-Anweisung aus. Er wird dann auf unbestimmte Zeit außerhalb einer bestimmten Liste ausgesetzt, bis ein anderer Puck den wartenden Puck identifiziert und eine REACTIVATE-Anweisung für ihn ausführt. Häufig durchsucht dieser andere Puck eine Menge, um den Puck für REACTIVATE zu finden, aber eine Menge ist in unserer Terminologie nicht genau dasselbe wie eine benutzerverwaltete Liste. Ein Puck im Ruhezustand kann Mitglied keines Sets sein (solange ein Zeiger auf ihn irgendwo gespeichert wurde) oder eines oder mehrerer Sets. Ein SLX-Entwickler kann auf einfache Weise ein benutzerverwaltetes Listenkonstrukt definieren, das Sets, WAIT und REACTIVATE als Bausteine verwendet und das die Konstrukte anderer Sprachen nachahmt oder seine eigenen einzigartigen Eigenschaften bietet.
5.3 ExtendSim
ExtendSim (ursprünglich Extend genannt) verwendet eine nachrichtenbasierte Architektur für die ereignisdiskrete Simulation. Verschiedene Arten von Nachrichten werden verwendet, um Ereignisse zu planen, Elemente (Entitäten) durch ein Modell zu bewegen, die in ein Modell eingebaute Logik durchzusetzen und Berechnungen zu erzwingen. Die Absender und Empfänger von Nachrichten sind Blöcke (Operationen), einschließlich des Executive Blocks (Master Controller). In ExtendSim ist es die Blockausführung, die geplant wird (wenn ein Block ausgeführt wird, kann dies zum Beispiel das Senden von Nachrichten zwischen den Blöcken auslösen, mit dem Effekt, dass ein Element entlang seines Block-basierten Pfades in einem Modell bewegt wird). Tabelle 4 fasst die ExtendSim-Äquivalente für die Begriffe zusammen, die in der früheren generischen Diskussion eingeführt wurden.
Ein Block ist das grundlegende Modellierungskonstrukt in ExtendSim. Jeder Block hat ein Symbol, Konnektoren zur Nachrichtenübermittlung, Dialogfähigkeit und verhaltensdefinierenden Code. Residenz-Blöcke können Objekte halten, während die simulierte Zeit vergeht, während Passing-Blöcke dies nicht können (Objekte durchlaufen Passing-Blöcke in null simulierter Zeit). Modelle können durch Auswahl vorprogrammierter Blöcke aus den Blockbibliotheken von ExtendSim erstellt werden. Der Modellierer kann auch den Quellcode der Bibliotheksblöcke verändern (alle Blöcke in der Basisversion von ExtendSim sind Open Source). Schließlich kann der Modellierer benutzerdefinierte Blöcke von Grund auf neu erstellen (benutzerprogrammierte Blöcke), indem er die von ExtendSim bereitgestellten Entwicklungswerkzeuge verwendet.
ExtendSim verwendet ein Time Array, um zukünftige Blockausführungen zu planen. Für ein gegebenes Modell enthält das Time Array ein oder mehrere Elemente für jeden Block. Ein Zeit-Array-Element zeichnet die zukünftige Zeit auf, für die die Ausführung dieses Blocks geplant wurde. Die Möglichkeit, dass ein Block mehr als ein Zeit-Array-Element haben kann, ist eine Erweiterung in Version 7 der Sprache (Version 8 ist die aktuelle Version). Diese Funktion kann nützlich sein, wenn ein Block mehrere, ungleiche Ereignisse hat, wie zum Beispiel bei der Modellierung von Förderanlagen.
Blöcke, die derzeit nicht für eine zukünftige Ausführung vorgesehen sind, werden vorübergehend "verdunkelt", indem beliebig große Zeitwerte für sie im Zeit-Array aufgezeichnet werden. Residenzblöcke, die mehrere Elemente enthalten können, verwalten die entsprechenden Ereigniszeiten intern, wobei nur die früheste der Ereigniszeiten des Blocks im Zeit-Array gespeichert wird. Dies ist eine zweistufige Ereignisliste, da Blöcke optimierte verknüpfte Listen enthalten können, die als ihre eigenen zukünftigen Ereignislisten dienen. Die Ausführung von Blöcken kann dazu führen, dass zukünftige Blockausführungen geplant werden. Wenn z. B. Nachrichten übermittelt werden, die dazu führen, dass ein Objekt in einen Residenzblock mit einer Kapazität von einer Einheit eintritt, der dazu dient, das Objekt so lange zu halten, bis eine bestimmte simulierte Zeitspanne verstrichen ist, dann wird der Wert des Eintrags in der Zeitleiste für diesen Block entsprechend gesetzt.
Die Anzahl der Blöcke in einem bestimmten Modell ist konstant, was bedeutet, dass das Zeit-Array eine feste und relativ kleine Größe hat. Aufgrund seiner geringen Größe wird das Zeitfeld durchsucht, um den unmittelbar bevorstehenden Ereigniszeitpunkt zu finden; es wird nicht in sortierter Reihenfolge gehalten. Dies macht es für einen Block einfach, seine Ereigniszeit zu ändern, da keine Suche in der Ereignisliste erforderlich ist. Das Array Nächste Zeiten wird verwendet, um die Ausführung von Blöcken zu verwalten, deren Ausführung über das Zeit-Array geplant wurde. Das Array Nächste Zeiten wird unmittelbar vor einer Blockausführungsphase (ExtendSims Äquivalent zu einem EMP) wie folgt gefüllt. Bei jeder CUP wird das Zeit-Array durchsucht, um die früheste zukünftige Zeit zu finden, für die eine Blockausführung geplant ist. Die Bezeichner für den entsprechenden Block (oder die Blöcke, im Falle von Zeitüberschneidungen) werden dann in das Array Nächste Zeiten eingetragen. Dann beginnt die Blockausführungsphase (BEP), in der die Exekutive den am besten qualifizierten Block im Array Nächste Zeiten benachrichtigt, um seine Ausführung zu starten.
Das Array Aktuelle Ereignisse wird verwendet, um die Wiederaufnahme der Ausführung von Blöcken zu verwalten, deren Ausführung im Verlauf einer Blockausführungsphase vorübergehend unterbrochen wurde. Nehmen wir zum Beispiel an, ein Block sendet eine Nachricht und der empfangende Block antwortet (gibt die Kontrolle zurück) sofort an den sendenden Block (obwohl der empfangende Block zum fraglichen simulierten Zeitpunkt noch eine weitere Verarbeitung durchführen muss). In diesem Fall wird die Kennung des empfangenden Blocks zum Array Aktuelle Ereignisse hinzugefügt. Wenn die Ausführung des sendenden Blocks beendet ist, sendet die Exekutive eine Nachricht an den am höchsten qualifizierten Block im Current Events Array, um seine Ausführung fortzusetzen. Schließlich wird das Current Events Array leer. Dann wendet sich der Ausführende erneut dem Array Nächste Zeiten zu und sendet eine Nachricht an den am besten qualifizierten Block, um mit der Ausführung zu beginnen.
Während einer Blockausführungsphase können Blöcke ihre Ausführung zum aktuellen simulierten Zeitpunkt (d. h. während des laufenden BEP) planen. Auch hier kommt das Current Events Array ins Spiel, um die Ausführung von Blöcken in solchen Fällen zu steuern. Wenn z. B. ein Block mit Kapazitätsbeschränkungen durch die Ausführung eines anderen Blocks nicht mehr voll ist, trägt der nicht volle Block seine Kennung in das Array Aktuelle Ereignisse ein. Die Exekutive wird später (aber zur gleichen simulierten Zeit) eine Nachricht an den Block senden, damit dieser mit der Ausführung beginnt. Der Block wird dann versuchen, Elemente in sich hineinzuziehen (falls vorhanden), die darauf gewartet haben, in den Block zu gelangen (in ExtendSim können Elemente sowohl durch ein Modell gezogen als auch geschoben werden). Wenn das Array "Aktuelle Ereignisse" und das Array "Nächste Zeiten" beide leer sind, ist die Blockausführungsphase von ExtendSim zu Ende. Dann finden die nächsten CUP und BEP statt, die sich wiederholen, bis eine Bedingung für das Ende der Simulation erfüllt ist. Verzögerungslisten bestehen aus Elementen, die in Residenzblöcken verzögert werden und darauf warten, dass sie in ihre(n) nächsten Block(s) gezogen oder geschoben werden. Wenn die Modellbedingungen es zulassen, wird das Ziehen und Schieben durch Nachrichtenübermittlung erreicht. ExtendSim bietet eine zusammenhängende Warteverwaltung dieser Elemente auf der Grundlage von benutzerdefinierten First-in, First-out (FIFO), Last-in, First-out (LIFO), Prioritäts-, Attribut-, Reneging-, Matching- und gleichungsbasierten Alternativen. Das Warten auf die Auflösung von zusammengesetzten Bedingungen wird in ExtendSim normalerweise durch eine geeignete Kombination von Blöcken und die Ausnutzung der nachrichtenbasierten Architektur von ExtendSim erreicht. Wir betrachten dies als eine Form des zusammenhängenden Wartens, weil es eine Änderung in einem zugrundeliegenden Wert ist, die eine Neubewertung der Bedingung auslöst, die das Warten in erster Linie verursacht hat.
Aufgrund der Messaging-Architektur von ExtendSim ist das abgefragte Warten im Allgemeinen nicht notwendig. Eine Nachricht wird gesendet, wenn sich ein Wert ändert und alle Bedingungen werden in diesem Moment ausgewertet. Das Warten auf ein taktbasiertes Ereignis kann durch die Verwendung eines Blocks erreicht werden, der Ereignisse plant, z.B. Shift; Lookup Table; Equation. Diese Blöcke senden zu geplanten Zeiten eine Nachricht. Abgefragtes Warten ist jedoch mit dem Gate-Block und der Option "Bedarf bei jedem Ereignis prüfen" möglich.
Der Modellierer kann mit benutzerprogrammierten Blöcken arbeiten, um Listen zu erstellen und zu verwalten, die er selbst entworfen hat. Der Code für benutzerdefinierte Blöcke kann geschrieben werden, um die Ziele des Modellierers in dieser Hinsicht zu erreichen, so wie der Code für die vorprogrammierten Blöcke von ExtendSim geschrieben wurde, um das Verhalten dieser Blöcke zu spezifizieren. ExtendSim stellt Funktionen zur Verfügung, die von Blöcken verwendet werden können, um Listen (Arrays) mit anderen Blöcken zu teilen, was die kundenspezifische Listenverwaltung in Modellen weiter unterstützt.
5.4 Simio
Simio ist eine objektorientierte Sprache, in der alle Modellkonstrukte Simio-Objekte sind, die von demselben Basisobjekt abgeleitet sind. Die meisten Simio-Benutzer werden hauptsächlich Objekte aus der Simio-Standardbibliothek für die Konstruktion von Modellen verwenden. Entitäten, Ressourcen, Server, Workstations, Quellen, Senken, Knoten und Konnektoren sind häufig verwendete Objekte aus der Standardbibliothek. Simio basiert auf Prozessen, die sich aus einzelnen Prozessschritten zusammensetzen, die von Token ausgeführt werden. Das Verhalten von Objekten der Standardbibliothek wird (durch den Objektdesigner) mit Hilfe von Prozessen implementiert. Während die meisten Modelle mit diesen High-Level-Objekten erstellt werden, haben Benutzer (und Entwickler) vollständigen Zugriff auf Simio-Prozesse und können komplette Modelle sowie wiederverwendbare Objekte mit Simio-Prozessen entwickeln. Darüber hinaus können Anwender das Verhalten bestehender Objekte mit Hilfe von Add-on-Prozessen und/oder durch Subklassifizierung bestehender Objekte erweitern. Simio-Modelle selbst sind eigentlich Objekte, die in andere Modelle eingebettet werden können. Die Objektstruktur von Simio erleichtert die Entwicklung kundenspezifischer Objektbibliotheken, die den Modellierungsprozess in verschiedenen Anwendungsdomänen vereinfachen können.
Die Äquivalente für die allgemeinen Begriffe für Simio-Benutzer sind in Tabelle 5 aufgeführt. Beachten Sie, dass jedes Simio-Objekt als Ressource fungieren kann, indem Sie die Eigenschaft "Resource Object" auf True setzen. Das Resource-Objekt aus der Standardbibliothek ist analog zu einer Ressource im Kontext dieses Papiers. Die Beziehung zwischen Simio-Entity-Objekten und Token ist vom Konzept her ähnlich wie die Beziehung zwischen dem aktiven Objekt und Pucks in SLX. Wenn Objekte interagieren (z. B. ein Entity-Objekt, das sich durch ein Server-Objekt bewegt, um sich in eine Warteschlange einzureihen und auf eine Ressource mit begrenzter Kapazität zuzugreifen), führen ein oder mehrere mit diesen Objekten verbundene Token die Prozesse (Schrittfolgen) aus, die das Verhalten der Objekte bestimmen. Die Möglichkeit, mehrere Token zu haben, die verschiedene Prozesse im Namen desselben Objekts ausführen, bietet Flexibilität bei der Modellierung.
Objekteigenschaften und Zustände dienen als Simio-Steuerelemente. Eigenschaften und Zustände sind beides Attribute von Objekten. Eigenschaften werden zu Beginn eines Laufs festgelegt und ändern sich während des Laufs nicht, während Zustände jederzeit während eines Modelllaufs festgelegt und geändert werden können. Eigenschaften werden in der Regel bei der Modellkonstruktion und beim Experimentieren verwendet, während Zustände in der Regel während eines Modelllaufs verwendet werden, um den Ablauf zu steuern und/oder Statistiken zu verfolgen und zu melden. Ereignisse sind in Simio etwas abstrakter als in einigen anderen Paketen. In Simio sind Ereignisse durch eine Ausführungszeit (die Simulationszeit, zu der das Ereignis eintritt), einen Verweis auf einen Prozeduraufruf (der ausgeführt wird, wenn das Ereignis eintritt) und einen Verweis auf ein Objekt (das der Prozedur bei Bedarf zusätzliche Daten liefert) gekennzeichnet. Das referenzierte Objekt eines Ereignisses kann ein für den Benutzer sichtbares Entity oder ein zugehöriges Token sein, muss es aber nicht. Bei Ereignissen, die mit einer Entitätsbewegung verbunden sind, verweist das Ereignisobjekt auf ein Token, das mit der Entität verbunden ist, und die Ereignisprozedur führt einen Prozessschritt aus (ein so genanntes "Token arrived to a step"-Ereignis). Die meisten Ereignisse, die während eines Modelllaufs auftreten, sind von diesem Typ. Beispiele für andere, interne Ereignisse sind End-of-Run-Ereignisse, Zustände, die einen Schwellenwert überschreiten, Entity-Kollisionsereignisse, etc. Simio unterstützt auch benutzerdefinierte Ereignisse, die abgefeuert, abgewartet und zum Auslösen von Prozessen verwendet werden können.
Während der Modellausführung werden, sobald der CUP auftritt und Simio in die EMP eintritt, alle für die aktuelle Simulationszeit geplanten Ereignisse aus dem Future Event Heap (FEH) entfernt und in der Current Event List (CEL) abgelegt. Die Heap-Datenstruktur wird für zukünftige Ereignisse verwendet, da sie sehr recheneffizient ist. Simio führt alle Ereignisse in der CEL (sequentiell) aus, bevor die Simulationszeit auf den nächsten Ereigniszeitpunkt fortgesetzt wird. Die Ereignisse auf der CEL werden nach Ereignistyp (normal, früh und spät) priorisiert. Ereignisprozeduren können weitere Ereignisse erzeugen (zukünftige Ereignisse sowie für die aktuelle Simulationszeit geplante Ereignisse), den Systemzustand aktualisieren, die Aufzeichnung von Statistiken auslösen und den Modelllauf beenden. Zuweisungswarteschlangen sind Listen von Entitäten, die auf Ressourcen warten. Wenn eine Ressource verfügbar wird, durchläuft Simio einen Standard-Neuzuweisungsprozess, bei dem die "erste" Entität in der Zuweisungswarteschlange (bestimmt durch die Warteschlangen-Rangfolge-Regel) an die Spitze der CEL gesetzt wird und die Entität, die die Ressource freigegeben hat, schrittweise abgearbeitet wird, bis sie eine Verzögerung erreicht (entweder eine Zeitverzögerung, eine Bedingungsverzögerung oder eine vom Benutzer festgelegte Speicherung). Bei diesem Prozess wird die letzte freigebende Entität abgearbeitet, bis sie eine Verzögerung erreicht, und die letzte Entität, der eine Ressourcenkapazität zugewiesen wurde, beginnt als erste mit der Abarbeitung (zur gleichen Simulationszeit). Simio implementiert den ruhenden Zustand mit Hilfe von Storage- oder Station-Elementen. Ein Storage-Element implementiert eine logische Warteschlange, in der Objekte vom Benutzer zur späteren Entnahme "platziert" werden können. Storage-Elemente haben keinen physischen Standort und ein bestimmtes Objekt kann sich gleichzeitig in mehreren Storages befinden. Ein Stationselement hingegen definiert einen physischen Ort mit begrenzter Kapazität, an dem Entity-Objekte zur späteren Entnahme und Verarbeitung gespeichert werden können.
6 Warum das wichtig ist
In den Abschnitten 6.1-6.5 beschreiben wir Situationen, die einige praktische Unterschiede in der Implementierung von Arena (das die SIMAN-Sprache und den SIMAN-Prozessor verwendet), ProModel, GPSS/H, AutoMod, SLX, ExtendSim und Simio aufzeigen. Keiner der genannten alternativen Ansätze ist per se "richtig" oder "falsch". Der Modellierer muss sich lediglich der Alternative bewusst sein, die in der verwendeten Simulationssoftware zum Tragen kommt, und mit ihr arbeiten, um das gewünschte Ergebnis zu erzielen. Andernfalls ist es möglich, eine Situation falsch zu modellieren und sich dessen vielleicht nicht bewusst zu werden. In Abschnitt 6.6 wird erläutert, inwieweit Kenntnisse über Software-Interna erforderlich sind, um Modellprüfungswerkzeuge effektiv zu nutzen. Schließlich weisen wir in Abschnitt 6.7 darauf hin, dass die Kenntnis von Interna zum Verständnis der Leistungsüberwachung beiträgt.
6.1 Der Versuch, eine Ressource sofort zurückzuerobern
Angenommen, ein Job in einem flexiblen Job-Shop gibt eine Maschine frei (auf die andere Jobs warten) und beschließt dann, diese Maschine als nächsten Schritt wieder zu übernehmen. Wird der Auftrag die Maschine sofort wieder übernehmen, oder wird ein wartender Auftrag (auch wenn er weniger oder gleich qualifiziert ist) die Maschine stattdessen übernehmen? Von Interesse ist hier die Reihenfolge der Ereignisse nach der Freigabe einer Ressource. Es gibt mindestens drei Alternativen: (1) Mit dem Ereignis der Ressourcenfreigabe ist die sofortige Wahl des nächsten Nutzers der Ressource verbunden, ohne dass die freigebende Entität ihren nächsten Schritt bereits vollzogen hat; (2) die Wahl des nächsten Ressourcennutzers wird aufgeschoben, bis die freigebende Entität potenziell zu einem Konkurrenten geworden ist; und (3) ohne auf andere Konkurrenten zu achten, erobert die freigebende Entität die ungenutzte Ressource sofort zurück. Arena, ExtendSim und Simio (das Standardverhalten) implementieren (1). ProModel implementiert (2). GPSS/H und AutoMod implementieren standardmäßig (3). In SLX, das eine Kontrollvariable als Ressourcenzustand verwendet, ist das Ergebnis ebenfalls (3). (In einigen Werkzeugen können Modellierer Ressourcenkonstrukte auf höherer Ebene implementieren oder zusätzliche Anweisungen verwenden, so dass sich die Modelle entsprechend den diesbezüglichen Entscheidungen des Modellierers verhalten).
6.2 Der Erste in der Reihe ist immer noch verzögert
Angenommen, zwei bedingt verzögerte Entitäten warten in einer Verzögerungsliste, weil keine Einheiten einer bestimmten Ressource frei sind. Angenommen, die erste Entität benötigt zwei Einheiten der Ressource, während die zweite Entität nur eine Einheit benötigt. Nehmen wir nun an, dass eine Einheit der Ressource frei wird. Der Bedarf der ersten Listenentität kann noch nicht befriedigt werden, der Bedarf der zweiten Entität hingegen schon. Was geschieht dann? Es gibt mindestens drei mögliche Alternativen: (1) Keine der beiden Entitäten beansprucht die ungenutzte Ressourceneinheit; (2) die erste Entität beansprucht die eine ungenutzte Ressourceneinheit und wartet auf eine zweite Einheit; und (3) die zweite Entität beansprucht die ungenutzte Ressourceneinheit und wechselt in den Bereitschaftszustand. Wie in Abschnitt 6.1 kommt jede dieser Alternativen in den hier betrachteten Tools zum Tragen. Arena (SEIZE) und ProModel (GET oder USE) implementieren standardmäßig (1) bzw. (2). AutoMod (GET oder USE), GPSS/H (ENTER oder TEST) und SLX (WAIT UNTIL auf eine Kontrollvariable) implementieren standardmäßig (3). ExtendSim implementiert ebenfalls standardmäßig (3). Aber ExtendSim gibt dem Modellierer die Möglichkeit, (1) für die vom Modellierer angegebenen Ressourcen lokal zu implementieren. Der Modellierer tut dies, indem er für jede dieser Ressourcen die Option "Only allocate resource pool to the highest ranked Item" ankreuzt. In Simio kann der Modellierer die Option (1) oder (2) auswählen, indem er die Eigenschaft "Anzahl der Objekte" und die Option "Wiederholte Ressourcenbelegung" mit dem Schritt "Belegung" verwendet.
6.3 Vorübergehende Abgabe der Kontrolle
Angenommen, die aktive Entität möchte die Kontrolle an eine oder mehrere Ready-State-Entitäten abgeben, muss dann aber wieder die aktive Entität werden, bevor die Simulationsuhr weitergelaufen ist. Dieses Szenario kann zum Beispiel eintreten, wenn die aktive Entität einen Schalter geöffnet hat, der es einer Reihe anderer Entitäten erlaubt, sich an einem Punkt im Modell vorbeizubewegen, und dann den Schalter wieder schließen muss, nachdem die Vorwärtsbewegung der anderen Entitäten abgeschlossen ist. Nehmen wir als Beispiel einen Fall, in dem eine Gruppe von Eiskremkartons mit identischen Geschmacksrichtungen von einem Sammelpunkt zu einem Förderband transportiert werden soll, das zu einem Verpackungsvorgang mit einer Sorte pro Karton führt.
In Arena kann der Effekt ungefähr mit einem DELAY erreicht werden, das die aktive Entität für eine beliebig kurze, aber von Null verschiedene simulierte Zeit in einen zeitverzögerten Zustand versetzt. In ProModel kann "WAIT 0" verwendet werden, um die aktive Entität zurück auf den FEC zu setzen. Die Entität wird zu einem späteren Zeitpunkt (Wanduhrzeit, aber zur gleichen simulierten Zeit) vom CUP wieder in den aktiven Zustand versetzt. In GPSS/H kann der aktive Xact (Transaktion) einen YIELD-Block ausführen, um sofort aus dem aktiven Zustand in den Bereitschaftszustand zu wechseln (in seiner Prioritätsklasse an letzter Stelle) und einen Neustart des CEC-Scans zu erzwingen. Höherrangige CEC-Xacts erhalten dann die Chance, aktiv zu werden, bevor der nachgebende Xact zur gleichen simulierten Zeit wieder aktiv wird. SLX (YIELD), AutoMod (Wait For 0) und Simio (Delay step with Math.Epsilon) bieten alle Lösungen an, bei denen der aktive Puck (SLX), Load (AutoMod) oder Token (Simio) an das Ende seiner Prioritätsklasse auf dem CEC verschoben wird, wo er darauf wartet, wieder aktiv zu werden, bevor die Uhr weitergestellt wird. In ExtendSim ist "nachgeben und dann eventuell wieder aufnehmen" Teil der Architektur. Eine Nachricht wird über den entsprechenden Block-Konnektor gesendet, wenn sich ein Element in einen Block hinein oder aus einem Block heraus bewegt. Diese Nachricht wird an andere angeschlossene Blöcke weitergegeben, wodurch sich möglicherweise der Systemstatus ändert oder Elemente von einem Block in einen anderen verschoben werden. Wenn der Block, von dem die Nachricht stammt, die Antwort erhält, setzt er die Verarbeitung des ursprünglichen Elements fort.
6.4 Bedingungen, die die Uhr betreffen
Jede Sprache bietet eine Zeitverzögerungsfunktion für FEL-Wartezeiten. Dies funktioniert gut, wenn eine Entität warten muss, bis ein bekannter Zeitwert erreicht ist. Was aber, wenn eine Entität auf eine zusammengesetzte Bedingung warten muss, die die Uhr einbezieht, wie z. B. "warte, bis ein bestimmter Eingabepuffer leer ist oder es genau 17:00 Uhr ist"? Ein typischer Ansatz hierfür ist das Klonen einer Dummy-Entität ("Schatten"), die das zeitbasierte Warten übernimmt. Die Verwaltung solcher Dummy-Entitäten kann umständlich sein, insbesondere bei sehr komplexen Regeln. ProModel verwendet keine abgefragte Wartezeit, so dass eine Dummy-Entität der beste verfügbare Ansatz wäre. (Andernfalls würde die Bedingung erst geprüft, wenn die andere Komponente der zusammengesetzten Bedingung eine Wertänderung aufweist). ExtendSim verwendet ebenfalls kein "polled waiting", so dass eine ähnliche Situation für ExtendSim gilt und jeder Block, der Ereignisse planen kann, verwendet werden kann. Bei Simio können Entitätsobjekte mehrere zugehörige Token haben, die jeweils auf eine andere Komponente der zusammengesetzten Bedingung warten. Dies ist vom Konzept her ähnlich wie die Verwendung einer Dummy-Entität, erfordert aber keine zusätzliche Entität.
Wenn eine einzelne Entität versucht, auf eine zusammengesetzte Bedingung zu warten, die die Uhr betrifft, kann ein interessantes Problem entstehen, wenn ein abgefragter Wartemechanismus vorhanden ist. Dies liegt daran, dass die nächste Abfragezeit möglicherweise nicht mit der Zieluhrzeit übereinstimmt. Arena und AutoMod erkennen den Wahrheitsgehalt zusammengesetzter Bedingungen über ihre Endof-EMP-Abfragemechanismen. Auch GPSS/H erkennt die Wahrheit über seine Version des gepollten Wartens (refusalmode TEST). Da es jedoch keine Möglichkeit gibt, auf der FEL bis genau 17:00 Uhr zu warten (d. h. der oben für ProModel, ExtendSim und Simio empfohlene Ansatz), besteht bei allen drei Werkzeugen die Möglichkeit, dass der erste EMP, der die Bedingung für wahr hält, eintritt, wenn die Uhr einen Wert größer als 17:00 Uhr hat. Dies kann problematisch sein, wenn die Genauigkeit von 5:00 PM wichtig ist.
SLX erkennt die Uhr als ein zugehöriges Wait-until-Ziel. Ein WAIT UNTIL, das einen zukünftigen Zeitwert in einer Weise verwendet, die zur Falschheit der Bedingung beiträgt, führt dazu, dass der Puck auf dem FEL eingeplant wird, um einen EMP zu der genauen Zeit zu erzwingen, auf die verwiesen wird. Dadurch wird das Problem der "Mehr-als-die-wünschte-Zeit" gelöst. Beachten Sie, dass dieser Puck auch auf einer oder mehreren Verzögerungslisten warten kann.
6.5 Mixed-Mode-Warten
Angenommen, viele Entitäten warten darauf, eine bestimmte Ressource zu erfassen, während eine vom Benutzer erstellte Controller-Entität darauf wartet, dass die zusammengesetzte Bedingung "der Schichtstatus ist 'Freischicht' und die Anzahl der Wartenden ist kleiner als sechs und die Ressource ist derzeit nicht in Gebrauch" eine Aktion auslöst (z. B. das Abschalten der Ressource in Sprachen, die benutzerdefinierte Entitäten zum Abschalten von Ressourcen zulassen, oder die Anzeige einer Statusmeldung). Wie können wir garantieren, dass die Controller-Entität in der Lage sein wird, sich vor die wartenden Entitäten zu einem angemessenen simulierten Zeitpunkt zu schieben (bevor die ungenutzte Ressource wieder in Besitz genommen wird)?
Eine Möglichkeit, dies zu handhaben, wären Entitätsprioritäten in Sprachen, die diese Funktion anbieten. Wie unten beschrieben, könnte dies jedoch nicht funktionieren, selbst wenn der Controller eine relativ hohe Priorität hat. Das Hauptproblem ist die Methode, die für die Implementierung des Wartens verwendet wird. Wenn es für die Entitäten, die auf die Ressource warten, "related" und für die Controller-Entität, die auf die Compound-Bedingung wartet, "polled" ist (das ist es, was wir mit dem Begriff "mixed-mode waiting" meinen), können die Dinge kompliziert werden. Jedes Mal, wenn die Ressource frei wird, wird eine neue Entität aus einer Verzögerungsliste sofort in Arena und über den CEL in AutoMod ausgewählt, wobei in beiden Fällen die End-of-EMP-Prüfung für abgefragte Wartebedingungen vorausgeht (und dadurch die Entity-Priorität des Controllers ignoriert wird). Es gibt Möglichkeiten, dies zu umgehen, z. B. durch die Verwendung einer anderen Art von Operation, um eine abgefragte Wartezeit für Entitäten zu erzwingen, die die Ressource nutzen möchten.
In GPSS/H wartet die Steuerung bei Verwendung einer hochprioren Steuerung Xact an einem TEST-Block im Verweigerungsmodus an der Vorderseite des CEC. Die Fazilität RELEASE löst einen Scan-Neustart aus und der Controller erledigt seine Arbeit. In ProModel gibt es keine abgefragte Wartezeit, aber es kann eine zusammenhängende Wartezeit für zusammengesetzte Bedingungen mit Variablen geben. Für jedes Element der booleschen Bedingung müssten Variablen definiert und manipuliert werden, und um gleichen Wettbewerb zu gewährleisten, müssten die Entitäten, die auf die Ressource warten, möglicherweise auch WAIT UNTIL anstelle von GET oder USE verwenden. Eine weitere Möglichkeit mit ProModel wäre, dass die Entität, die die Ressource freigibt, sofort eine Zustandsüberprüfung durchführt (und so zu einem Ersatz für den Controller wird). Dies ist aufgrund der von ProModel verwendeten Methode der verzögerten Auswahl möglich (siehe Abschnitt 6.2).
In der damit verbundenen Wartezeit von SLX wird ein Puck, der auf eine zusammengesetzte Bedingung wartet, in die Verzögerungslisten derjenigen (und nur derjenigen) Kontrollvariablen eingetragen, die zur Falschheit der Bedingung beitragen. Die SLX-Architektur (in der nur globale oder lokale Kontrollvariablen und die Uhr in jeder Art von bedingtem Warten auf unterster Ebene referenziert werden können) stellt sicher, dass es bereits Variablen gibt, die den zu überwachenden Zustandsänderungen zugrunde liegen. Der Modellierer definiert sie als Kontrollvariablen.
Wie bei ProModel und SLX würde ExtendSim das bedingte Warten verwenden, um eine Änderung der Verbundbedingung zu erkennen und sofort darauf zu reagieren. Da die Zustandsänderung der Ressource sofort als Nachricht gesendet wird, bevor die Ressource neu zugewiesen wird, kann diese Nachricht verwendet werden, um die Reihenfolge und Logik der Elementauswahl zu steuern. Eine Ressource wird nur dann zugewiesen, wenn sowohl nachgelagerter Platz für ein Item als auch die Verfügbarkeit der Ressource gegeben ist, so dass die Blockierung des Ausgangspfads einer Warteschlange die Zuweisung der Ressource verhindert.
In Simio können Resource-Objekte ihre eigene Logik mit Hilfe von Add-on-Prozessen implementieren, so dass es nicht notwendig ist, "Controller-Entitäten" zur Implementierung des Kontrollmechanismus zu verwenden. In diesem Fall können die Add-on-Prozesse "Off-Shift" und "Released" verwendet werden, um die komplexe Bedingung zu prüfen, die den Schichtstatus, die Größe der Warteschlange und den Status der Ressource beinhaltet. Bitte beachten Sie, dass dies einer zusammenhängenden Wartezeit entspricht, da die Bedingung nur geprüft wird, wenn die Ressource aus der Schicht geht und/oder wenn eine Kapazitätseinheit freigegeben wird.
6.6 Interaktive Modellüberprüfung
Wir möchten nun kurz erläutern, warum ein detailliertes Verständnis der Funktionsweise von Simulationssoftware die interaktive Überprüfung des Verhaltens von Simulationsmodellen unterstützt. Im Allgemeinen können Simulationsmodelle interaktiv oder im Batch-Modus ausgeführt werden. Interaktive Läufe sind nützlich, um die Modelllogik während der Modellerstellung zu überprüfen (zu verifizieren) und bei der Fehlersuche in einem Modell, wenn Ausführungsfehler auftreten. Der Batch-Modus wird dann zur Durchführung von Produktionsläufen verwendet.
Bei interaktiven Läufen wird eine Simulation während der Ausführung unter die Lupe genommen. Der Modellierer kann der aktiven Entität Schritt für Schritt folgen und die Listen der aktuellen und zukünftigen Ereignisse, der Verzögerungen und der vom Benutzer verwalteten Listen sowie andere Aspekte des Modells anzeigen. Diese Aktivitäten geben dem Modellierer, der die zugrunde liegenden Konzepte kennt, wertvolle Einblicke in das Modellverhalten. Ohne diese Kenntnisse kann der Modellierer die interaktiven Werkzeuge der Software nicht in vollem Umfang nutzen oder, was noch schlimmer ist, die Werkzeuge gar nicht verwenden.
6.7 Leistungsaspekte
Simulationsexperimente können erhebliche Mengen an Computerzeit in Anspruch nehmen. Bei sonst gleichen Voraussetzungen (einschließlich der Fähigkeiten des Modellbauers) hängt der Zeitbedarf vom Design und der Implementierung der Software ab, die zur Erstellung der Modelle verwendet wird. Die Leistung ist ein so wichtiges Thema, dass einige Simulationssoftware (z. B. ExtendSim, SLX und Simio) Leistungsprofile bereitstellt, die z. B. Histogramme erstellen können, die zeigen, wo die CPU-Zeit während der Modellausführung verbraucht wird.
Danksagungen
Viele Informationen in diesem Papier wurden von Mitarbeitern der Hersteller zur Verfügung gestellt. Die Autoren bedanken sich für die Unterstützung durch Deb Sadowski, Vivek Bapat, Charles Harrell (ProModel), Kenneth Farnsworth und Tyler Phillips (AutoMod), Robert C. Crain und James O. Henriksen (GPSS/H und SLX), David Krahl (ExtendSim) sowie David T. Sturrock und C. Dennis Pegden (beide ursprünglich bei Arena/SIMAN und jetzt bei Simio).