In den letzten fünfzig Jahren hat sich die Simulation zu einem bevorzugten Werkzeug für die Analyse operativer Systeme entwickelt. Die Fortschritte in der Technologie haben neue Produkte und neue Umgebungen ohne Softwarestandards oder methodische Gemeinsamkeiten hervorgebracht. Jede neue Simulationssprache bzw. jedes neue Simulationsprodukt bietet eine eigene Reihe von Merkmalen und Fähigkeiten. Dennoch sind diese Simulationsprodukte das Ergebnis von Forschung, Entwicklung und Anwendung. In diesem Papier interpretieren wir die historische Entwicklung der Simulationsmodellierung. Nach unserer Auffassung ist die Simulationsmodellierung der Teil des Simulationsproblemlösungsprozesses, der sich auf die Entwicklung des Modells konzentriert. Es handelt sich um die Interpretation eines realen Produktions- (oder Dienstleistungs-) Problems in Form einer Simulationssprache, die in der Lage ist, eine Simulation dieses realen Prozesses durchzuführen. Während die "Interpretation" im Auge des Betrachters liegt (nämlich bei uns), gibt es einige historische Standpunkte und Methoden, die den Entwurf des Simulationsmodells beeinflussen.
In jahrzehntelanger Forschung wurden formale mathematische und statistische Modelle für Operationen entwickelt. Wenn ein Modell jedoch über seine Annahmen hinaus angewendet wird, stellt sich die Frage nach seiner Anwendbarkeit, und der Modellierer steht vor der Aufgabe, das Modell anzupassen oder ein neues Modell zu entwickeln. Die Anpassung oder Erstellung eines neuen analytischen Modells ist eine bedeutende Aufgabe, die die analytischen Fähigkeiten des Entwicklers herausfordert und unter Umständen erheblich mehr Zeit und Mühe erfordert, ohne dass greifbare Ergebnisse erzielt werden.
Der Wert eines Modells liegt in seiner Anwendung. Da einzelne Modelle ihre Grenzen haben und ihre Erweiterung entmutigend sein kann, bevorzugen einige Forscher und Praktiker eine flexiblere Modellierungsumgebung. Die Simulation gilt seit langem als ein Modellierungsinstrument, das eine sehr breite Entwicklungsumgebung bietet und keine mathematischen oder statistischen Kenntnisse für die Modellentwicklung und -nutzung erfordert. Um die Entwicklung von Simulationsmodellen zu erleichtern, wurde eine Vielzahl von Simulationssprachen entwickelt. Jede Simulationssprache bietet ihre eigenen Modellierungskonstrukte, mit denen ein Simulationsmodell erstellt, simuliert und analysiert werden kann. Während sich die Sprachen im Laufe der Zeit verändert haben, ist der Modellierungsansatz untrennbar mit der Perspektive der Simulationsausführung verbunden.
Der Zweck dieses Artikels ist es, eine personalisierte (und daher begrenzte) Geschichte der Simulationsmodellierung zu geben, wie sie weitgehend durch die Winter Simulation Conference populär geworden ist. Der Einsatz der Simulation in einem Problemlösungskontext erfordert mehrere Fähigkeiten:
Kiviat (1967) war einer der ersten, der den Modellierungsprozess und die erforderlichen Kenntnisse beschrieb. Ein Benutzer mit fundierten Kenntnissen in fast jeder Universalprogrammiersprache kann die meisten dieser Fertigkeiten erwerben. Der Aufwand für die Erstellung einer endgültigen Simulation ist jedoch enorm, da der Programmierer Software für alle erforderlichen Komponenten bereitstellen muss, einschließlich der Generierung von Zufallszahlen, der Generierung von Zufallsvariablen, der Statusaktualisierung und des Zeitfortschritts, der statistischen Erfassung und Anzeige, usw. All dies für ein einziges Modell zu bewerkstelligen, ist im Allgemeinen unerschwinglich, und es gibt Simulationssprachen und Simulationsbibliotheken, die die Erstellung von Simulationen erleichtern.
Es gibt zwar viele Simulationssprachen, aber die grundlegenden Simulationsansätze sind ähnlich. Eine Simulationssprache führt ein Modell des Systems aus, um das Verhalten des Systems im Laufe der Zeit dynamisch nachzubilden. Dies geschieht, indem der Wert von Zustandsvariablen über die simulierte Zeit verändert wird. Simulationssprachen lassen sich im Allgemeinen in zwei große Familien einteilen: diskrete und kontinuierliche. Diskrete Werkzeuge modellieren Systeme, bei denen sich der Zustand des Systems in diskreten Einheiten zu bestimmten Ereigniszeiten ändert. Kontinuierliche Werkzeuge modellieren Systeme, bei denen sich der Zustand des Systems kontinuierlich über Teile der Zeit ändert. Der Schwerpunkt liegt hier auf diskreten Systemen, obwohl auch kontinuierliche Systeme in Betracht kommen. Heutzutage sind die meisten Simulationssprachen multimodal und unterstützen mehrere Modellierungsparadigmen, die in der Regel diskrete und kontinuierliche Fähigkeiten mischen.
Eine diskrete Simulation besteht aus einem Satz von Zustandsvariablen und einem Mechanismus zur Änderung dieser Variablen zu bestimmten Zeitpunkten. Eine Weltanschauung zur Simulationsmodellierung bietet dem Praktiker einen Rahmen für die Definition eines Systems, um die Ziele so detailliert zu erreichen, dass das Verhalten des Systems simuliert werden kann. Im Gegensatz zu einfachen statischen Beschreibungswerkzeugen wie Flussdiagramm(https://en.wikipedia.org/wiki/Flowchart), Visio(https://en.wikipedia.org/wiki/Microsoft_Visio), IDEF(https://en.wikipedia.org/wiki/IDEF), UML(https://en.wikipedia.org/wiki/Unified_Modeling_Language)usw. muss eine Weltanschauung für die Simulationsmodellierung die dynamischen Zustandsübergänge, die im Laufe der Zeit auftreten, genau berücksichtigen. Die Weltanschauung bietet einen definitiven Satz von Regeln für das Fortschreiten der Zeit und die Änderung des diskreten Zustands (oder des kontinuierlichen Zustands) des Modells.
In der 60-jährigen Geschichte der Simulation haben sich vier verschiedene Weltsichten durchgesetzt: Ereignis, Aktivitäten, Prozess und Objekte (obwohl auch andere Terminologien und Taxonomien angeboten wurden - siehe Overstreet und Nance 1986). Diese wurden alle von den Pionieren der Simulation in den 1960er Jahren entwickelt (Gordon 1961; Markowitz et al. 1962; Tocher 1963; Dahl und Nygaard 1966). Obwohl diese Weltsichten in den letzten 50 Jahren erheblich verfeinert wurden, haben sich die Grundideen nicht geändert. Die Entwicklung von Modellierungswerkzeugen hat sich darauf konzentriert, ein Gleichgewicht zwischen Benutzerfreundlichkeit und Flexibilität zu erreichen. Die ereignisorientierte Weltanschauung bietet die größte Flexibilität, ist aber schwieriger zu handhaben. Die tätigkeitsbasierte Weltsicht bietet mehr Kontext für Aktivitäten, schränkt aber die Modellierung ein. Die Prozesssicht ist einfacher zu handhaben, jedoch um den Preis einer geringeren Modellierungsflexibilität. Die Objektsicht ist die einfachste und natürlichste von allen, hat aber auch den Preis einer höheren Modellierungskomplexität. Die Geschichte der Entwicklung von Simulationssprachen hat sich im Allgemeinen darauf konzentriert, die Prozess- und die Objektsicht flexibler zu machen und gleichzeitig ihren Vorteil der Benutzerfreundlichkeit zu bewahren. Gleichzeitig vermischen die meisten modernen Simulationssprachen ihre Ausführungsmethoden (mit Ereignisverarbeitung für zukünftige Ereignisse und Abtastung aktueller Ereignisse) und verwenden multimodale Darstellungen (z. B. Netzwerke, Prozesse, Dynamik), so dass sie sich nicht ohne weiteres in eine einfache Taxonomie einordnen lassen.
Ereignisse sind sequenzielle Zeitpunkte, an denen das System seinen Zustand ändert. Es liegt in der Verantwortung des Modellierers, dafür zu sorgen, dass die Ereignisse erkannt werden und dass die Zustandsänderungen stattfinden. Die Entscheidung über die Ereignisse ist eine Entscheidung des Modellierers und nicht immer offensichtlich. Diese Entscheidung wird zum Teil durch das Verhalten des Systems bestimmt, aber auch durch die Art der für die Simulation erforderlichen Leistungsmessungen. Die Entscheidung über die Ereignisse ist nur ein Teil der Herausforderung. Sobald ein Ereignis eintritt, muss der Übergang vom aktuellen Zustand zum Nachfolgezustand abgebildet werden. Außerdem muss es eine Möglichkeit geben, Ereignisse seriell zu pflegen und hinzuzufügen. Und es müssen geeignete Ausgaben gesammelt und angezeigt werden.
Zentral für die Modellierung mit Ereignissen ist die Rolle des Kalenders zukünftiger Ereignisse (dessen tatsächliche Datenstruktur sich entwickelt hat und variieren kann), der alle zukünftigen Ereignisse verwaltet. Eine diskrete Ereignissimulationssprache funktioniert oft so, dass (1) das nächste Ereignis aus dem Ereigniskalender entfernt und die Simulationszeit auf diese Ereigniszeit aktualisiert wird und (2) dann die mit diesem Ereignis verbundenen Zustandsaktualisierungsprozeduren ausgeführt werden.
Die Ereignislogik kann in jeder Allzweckprogrammiersprache wie Fortran, C++, C# usw. implementiert werden. Da jedoch eine Reihe von Simulationsfunktionen, wie z. B. die Erzeugung von Zufallsvariablen und die Planung von Ereignissen, den meisten Simulationen gemeinsam sind, erleichtert die Verwendung einer Bibliothek solcher Funktionen im Rahmen einer Programmiersprache die Entwicklung von Simulationsprogrammen erheblich. Beispiele hierfür sind die Verwendung von Fortran, ergänzt durch GASP (Pritsker und Kiviat 1969) und die Programmierung in C mit CSIM (Schwetman 1986). Andererseits stellte SIMSCRIPT II.5 (Russell 1983) seine eigene Programmiersprache zur Verfügung, um seine Simulationsbibliothek zu erweitern. Es fügte auch grundlegende Möglichkeiten zur Definition von Entitäten, zur Zuweisung von Attributen zu Entitäten und zur Zusammenfassung von Entitäten in Mengen hinzu.
In den ersten 20 Jahren der Simulation waren die Werkzeuge der Ereignisweltansicht weit verbreitet. Diese Werkzeuge wurden von vielen bevorzugt, weil sie sehr flexibel waren und zur effizienten Modellierung eines breiten Spektrums komplexer Systeme verwendet werden konnten. Man beachte, dass in dieser Zeit die Effizienz wichtiger war, da die Computer weniger Speicherplatz hatten und deutlich langsamer waren. Allerdings waren ereignisbasierte Modelle oft schwer zu verstehen und zu debuggen und erforderten Programmierkenntnisse, was ihre allgemeine Verwendung einschränkte.
Möglicherweise aufgrund ihrer Allgemeinheit gibt es keine allgemein akzeptierten Werkzeuge für die Modellierung mit Ereignissen. Normalerweise verwenden Modellierer Flussdiagramme und informelle Zeichnungen. Einige haben sich für Petri-Netze (Haas 2002) und Signalflussdiagramme ausgesprochen. Eine allgemeine Methode zur visuellen Modellierung diskreter Ereignisse sind Ereignisgraphen, die von Schruben eingeführt wurden (Schruben 1983). Obwohl der Ereignisgraph ein wertvolles Werkzeug für das Verständnis der diskreten Ereignissimulation ist, ist seine Verwendung als allgemeines Modellierungsinstrument recht begrenzt, und für seine allgemeine Verwendung sind eine Reihe von Erweiterungen und Ausschmückungen erforderlich.
Die Modellierung mit dem Schwerpunkt auf Ereignissen hat die Entwicklung von Simulationsmodellen im Allgemeinen in der nordamerikanischen Gemeinschaft dominiert, während ein etwas anderer Ansatz zur diskreten Modellierung, der so genannte Drei-Phasen-Ansatz, von K. D. Tocher in England initiiert wurde (siehe Hollocks 2008). Pidd (Pidd 2004) beschreibt eine verwandte Methode, das so genannte Activity Scanning. Aktivitäten (durch Ereignisse ausgelöste Vorgänge) bilden die Grundlage für Zustandsänderungen, wenn Ereignisse stattfinden. Die Drei-Phasen-Methode hat sich weiterentwickelt, besteht aber im Wesentlichen aus (1) dem Vorziehen der Zeit bis zum nächsten Ereignis (dem so genannten nächsten (zeitabhängigen) gebundenen Ereignis), (2) der Verarbeitung des einen oder der mehreren nächsten gebundenen Ereignisse und (3) der Verarbeitung aller anderen Aktionen, die vom Eintreten der gebundenen Ereignisse abhängig sind. So wie ein Kalender für zukünftige Ereignisse benötigt wird, so werden auch Listen von gebundenen und bedingten Ereignissen benötigt. Diese späteren bedingten (zustandsabhängigen) Ereignislisten werden erneut gescannt, bis keine Aktivität mehr gestartet werden kann.
Im Mittelpunkt des dreiphasigen Ansatzes steht die Verwendung eines konzeptionellen Modellierungswerkzeugs, das heute als "Aktivitätszyklusdiagramm" bezeichnet wird (ursprünglich als "Raddiagramm"). Um die Aktivitäten in einem System zu identifizieren, ist es sinnvoll, zunächst die Entitätstypen zu bestimmen, die die Aktivitäten ausführen. Das können zum Beispiel Aufträge und ein Bediener sein. Die Aufträge kommen an, warten auf die Maschine und gehen dann wieder. Der Bediener richtet die Maschine ein und bedient sie dann. Andernfalls ist der Bediener untätig, wenn es keine Aufträge zu bearbeiten gibt. Die Bearbeitung, das Einrichten und die Ankunft sind gebundene Aktivitäten, während das Warten und der Leerlauf abhängig von den gebundenen Aktionen sind. Hier wird das Aktivitätszyklusdiagramm verwendet, um die Elemente der dreiphasigen Simulation zu identifizieren.
Die Prozessmodellierung, vor allem in Form von GPSS (Gordon 1961), entstand parallel zur Entwicklung der Ereignis- und Aktivitätsmodellierung. GPSS, das bei IBM entwickelt wurde, war sowohl ein Modellierungswerkzeug als auch eine Simulationssprache. Es betrachtete die Welt als Entitäten (genannt Transaktionen), die sich durch ein Modell bewegten, das aus speziellen Blöcken bestand. Jeder Block hatte eine bestimmte Funktionalität. Zwischen dem Blockdiagramm und dem Simulationscode besteht fast eine Eins-zu-eins-Entsprechung. Das Simulationsmodell hat also sowohl eine visuelle als auch eine schriftliche Interpretation. Diese Entsprechung ist wichtig, weil der GPSS-Modellierer das visuelle Modell fast direkt in ein "Anweisungs"-Modell übersetzen kann und statt der Sprachsyntax eine visuelle Semantik zum primären Mittel der Modellierung wurde. Dieser Ansatz bedeutete, dass der Simulationsmodellierer kein Programmierer sein musste, und so führte GPSS dazu, dass sich eine große Zahl von Personen an der Simulation versuchte, die sonst nicht daran teilgenommen hätten. Das Interesse an GPSS wurde durch das klassische Buch Simulation Using GPSS (Schriber 1974) von Tomas J. Schriber von der University of Michigan im Jahr 1974 weiter angefacht. Dieses Buch war eines der ersten, in dem argumentiert wurde, dass die Modellierung von Simulationen auf strukturierte Weise erfolgen sollte.
Während GPSS weithin als einfach zu erlernen und zu verwenden anerkannt wurde, wurden viele Fragen zu seiner Ausführungseffizienz aufgeworfen. In GPSS wird die Simulation anhand von zwei Listen ausgeführt: einem Kalender für zukünftige Ereignisse und einem Kalender für aktuelle Ereignisse. Wenn Entitäten generiert werden, durchlaufen sie das Blockdiagramm so weit wie möglich. Wenn sie auf einen Block stoßen, der seine Abreise zu einem späteren Zeitpunkt planen kann, wird diese Entität in den Kalender für zukünftige Ereignisse aufgenommen. Wenn die Entität jedoch nicht weitergehen kann (z. B. weil keine Ressourcen verfügbar sind), wird sie in den aktuellen Terminkalender eingetragen. Der aktuelle Terminkalender wird so lange gescannt, bis es keine weiteren Aktionen mehr gibt (ähnlich wie beim Scannen von Aktivitäten), und dann wird das nächste Ereignis aus dem Terminkalender entfernt und die Zeit vorgerückt. Dieses Scannen des aktuellen Ereigniskalenders war zusammen mit einer Reihe anderer Probleme die Grundlage für eine stark verbesserte Version von GPSS im Jahr 1983 namens GPSS/H (Henriksen und Crain 1983), die die Ausführungszeit um einen Faktor von vier oder mehr verkürzen konnte, einschließlich der Tatsache, dass GPSS/H kompiliert wurde, während die IBM-Versionen interpretiert wurden.
Angeregt durch die weit verbreitete Akzeptanz der GPSS-Blockmodellierung wurde eine Reihe neuer (Ende der 1970er, Anfang der 1980er) Prozesssprachen entwickelt, die auf Netzwerken von Blöcken (Knoten) basieren. Dazu gehörten QGERT (Pritsker 1979) und SLAM (Pegden und Pritsker 1979). Anfang der 1980er Jahre kam dann der Personal Computer auf, und SIMAN (Pegden 1982) war eine der ersten Simulationssprachen, die auf dieser Plattform ausgeführt werden konnten. SIMAN verwendete ebenfalls stilisierte Blöcke, um ein Modell von Entitäten zu erstellen, die ein Netzwerk von einzelnen Verarbeitungsstellen durchliefen.
Prozessmodellierungssprachen verwendeten im Allgemeinen den Kalender für zukünftige Ereignisse und den Kalender für aktuelle Ereignisse. Um jedoch die Abfrage des Kalenders für aktuelle Ereignisse zu reduzieren, wurden Effizienzsteigerungen eingeführt, um eine reale Uhrzeit anstelle einer ganzzahligen Uhrzeit einzubeziehen und die Abfrage von Entitäten und aktuellen Ereignissen zu eliminieren, deren Status sich nicht ändert (z. B. wenn sie sich in einer Warteschlange hinter anderen befinden). Weitere Verbesserungen in den 1980er Jahren waren die verbesserte Generierung von Zufallszahlen und Zufallsvariationen, die Verringerung der Varianz, die effiziente Kalenderverwaltung und die effizientere Erhebung von Statistiken. Nur wenige Modellierer waren sich dessen bewusst, da die Simulationssprachen immer stärker mit den kommerziellen Unternehmen identifiziert wurden, die sie entwickelten und pflegten und ihre internen Abläufe als geistiges Eigentum betrachteten. Die Eins-zu-eins-Beziehung zwischen Simulationssprache und kommerzieller Organisation besteht auch heute noch.
Einer der wichtigsten Vorteile der Prozessorientierung besteht darin, dass das Prozessmodell grafisch in Form eines Flussdiagramms definiert wird (siehe (Fishman 1973). Der Benutzer muss also kein Programmierer sein, um ein Modell des Systems erstellen zu können. Vergleicht man das Prozessmodell mit dem Ereignisansatz, so ist die Modelllogik viel einfacher zu definieren und zu verstehen/erlernen und erfordert nur geringe Programmierkenntnisse. Dennoch haben Prozesssimulationssprachen inhärente Grenzen, da nicht für jede Situation ein entsprechender Block in der Sprache vorhanden ist. In einer Notaufnahme zum Beispiel kann der Patient als Entität betrachtet werden, die sich durch die Operationsblöcke bewegt, aber es gibt auch Ressourcen, die sich bewegen und die nicht gut durch Entitäten modelliert sind. Irgendwann stößt ein Prozessmodellierer in Bezug auf die Darstellung an seine Grenzen und muss entweder eine weniger akzeptable Darstellung in der aktuellen Sprache finden oder einen anderen Weg finden, um die benötigten Fähigkeiten hinzuzufügen (in der Regel durch Programmierung).
Ein weiterer konzeptioneller Fortschritt bei der Prozessmodellierung war die Einführung von hierarchischen Modellierungswerkzeugen, die die Idee von domänenspezifischen Prozessbibliotheken unterstützen. Das Grundkonzept besteht darin, dem Benutzer die Möglichkeit zu geben, seine eigenen Prozessschritte und -blöcke zu definieren, indem er bestehende Prozessschritte und -blöcke kombiniert. Das weit verbreitete Arena-Modellierungssystem(https://www.arenasimulation.com/) ist ein gutes Beispiel für diese Fähigkeit. Im Jahr 1992 fügten Cota und Sargent (Cota und Sargent 1992) die Modularisierung und Kapselung von Prozessen hinzu, was später zu hierarchischen Kontrollflussgraphen führte, die eine grafische Darstellung (und Berechnung) von Simulationsmodellen ermöglichten (Sargent 1997). SLX (Henriksen 1995) ist ein Beispiel für eine neuere prozessorientierte Sprache, die in einem objektorientierten Rahmen entwickelt wurde.
Eine andere Sichtweise der Prozessmodellierung besteht darin, dass ein Modell eine Menge von interagierenden Prozessen oder, allgemeiner, Objekten ist. Simula (Dahl und Nygaard 1966), das in den 1960er Jahren entwickelt wurde, stellte eine frühe Implementierung dar, die die Idee von Objekten als Elemente der Simulation förderte, und dass diese Objekte Aktionen enthalten können, die durch Logik beschrieben werden, die dieses Objekt steuern und die synchron oder asynchron mit anderen Objekten interagieren können (einige Ideen wurden aus der Sprache der künstlichen Intelligenz List 2 entwickelt - (siehe Nygaard und Dahl 1981). Obwohl sie in den frühen 1960er Jahren als Simulationssprache entwickelt wurde, war sie in Nordamerika kaum bekannt und in den USA nicht weit verbreitet. Ein Grund für die geringe Verbreitung war, dass es sich um eine auf Algol basierende Simulationsprogrammiersprache handelte, die nicht nur einige sehr einzigartige Simulationskonzepte bot, sondern auch eine (für die USA) einzigartige Software/Hardware erforderte. Im Nachhinein betrachtet war Simula ein wichtiger Beitrag zur Simulation, doch wurde es zunächst in der Programmiergemeinschaft mehr geschätzt. Mit dem Wachstum der objektorientierten Simulation wurde Simula als Vorläufer vieler aktueller Simulationssprachen wiederentdeckt.
Die objektorientierte Simulationsmodellierung lässt sich im Allgemeinen in zwei Lager einteilen. Die erste, für die Simula ein Beispiel ist, geht davon aus, dass die Simulationssprache objektorientierte Konzepte enthalten sollte, die es dem Modellierer ermöglichen, anspruchsvolle Simulationsprogramme zu entwickeln. Bei diesem Ansatz sind Konzepte wie abstrakte Datentypen, Vererbung, Polymorphismus, Komposition, parametrisierte Typen usw. von Bedeutung, da sie eine breite Palette von Objekten und Verhaltensweisen ermöglichen. Die Modelle sind kompakt, effizient und erweiterbar. Mit anderen Worten, sie sind eine bessere Umgebung für die Simulationsprogrammierung. Heutzutage werden Modelle typischerweise in C++ oder Java im Rahmen von Simulationspaketen erstellt.
Die von Simula eingeführten Ideen bilden die Grundlage für einige der jüngsten Fortschritte, die von den Entwicklern von Simulationssprachen gemacht wurden, um den objektorientierten Ansatz bei der Modellierung sowohl einfach zu handhaben als auch flexibel zu gestalten. Obwohl diese Ideen als Simulationsmodellierungskonzepte eingeführt wurden, haben sie das Design und die Implementierung von Programmierwerkzeugen im Allgemeinen völlig verändert. Die Ideen von Simula haben viele spätere Programmiersprachen direkt beeinflusst, darunter Smalltalk, LISP, C++, Java und C#. Die mit Simula eingeführten objektorientierten Ideen sind nicht nur die bedeutendste Entwicklung in der Simulationssoftware, sondern vielleicht der größte Fortschritt in der Informatik der letzten 50 Jahre.
Abgesehen von der Simulation als Programmierherausforderung sieht das andere Lager der objektorientierten Simulationsmodellierung die objektorientierte Simulation als aus einer Vielzahl von vordefinierten Objekten zusammengesetzt an, von denen jedes eine Reihe von Verhaltensweisen aufweist, die für die Steuerung und Verwendung der Objekte als relevant erachtet werden. Diese Modellierungsausrichtung vereinfacht den Prozess der Modellerstellung, indem sie ein Modellierungsparadigma bietet, das natürlicher und in vielen Fällen einfacher zu verwenden ist. Bei einem objektbasierten Modellierungsansatz erstellen wir unser Modell, indem wir Softwareobjekte in unser Modell einfügen, die die physischen Komponenten des Systems darstellen - z. B. einen Arzt, einen Maschinenführer, einen Gabelstapler, ein Förderband usw. Diese Objekte können angepasst werden, indem Eigenschaftswerte für dieses Objekt angegeben werden, wie z. B. Servicezeit, Fahrgeschwindigkeit usw. Wir modellieren z. B. eine Fabrik, indem wir die Arbeiter, Maschinen, Förderbänder, Roboter und andere Objekte, aus denen unsere Fabrik besteht, platzieren und durch Eigenschaften beschreiben. Bei der Prozessorientierung beschreibt der Modellierer die Aktionen, die im System stattfinden, wenn sich Entitäten durch Prozesse bewegen. Beachten Sie, dass Prozessschritte durch Verben beschrieben werden (ergreifen, verzögern, freigeben), während Objekte durch Substantive beschrieben werden (Maschine, Roboter, Arbeiter). In der Objektorientierung beschreibt der Modellierer einfach die physischen Komponenten im System und die Verhaltensweisen und Aktionen für diese Objekte, die bereits in die Objekte eingebaut sind. So verfügt ein Arbeiterobjekt über vordefinierte Verhaltensweisen, die es ihm ermöglichen, mit Maschinen und anderen Arbeitern im Modell zu interagieren.
Es ist schwierig, sich eine natürlichere Methode zur Erstellung eines Modells vorzustellen als die Verwendung einer Sammlung vorgefertigter Modellierungskomponenten, die die Komponenten des realen Systems nachahmen. Die Herausforderung bei diesem Ansatz besteht darin, dass wir, wenn wir irgendetwas in der realen Welt modellieren wollen, eine umfangreiche Bibliothek von Objekten benötigen, um die enorme Vielfalt der realen Objekte, denen man begegnen kann, erfassen zu können. Es reicht zum Beispiel nicht aus, ein einziges Objekt namens Roboter zu haben, da es in der realen Welt viele verschiedene Arten von Robotern gibt. Das Bestreben der Entwickler von Simulationssprachen, ein praktisches Simulationswerkzeug auf der Grundlage des Objektansatzes zu schaffen, veranschaulicht die Herausforderung, in ein und demselben Simulationsmodellierungswerkzeug sowohl Flexibilität als auch Benutzerfreundlichkeit zu erreichen. Obwohl die Flexibilität, die die Prozessorientierung bietet, sie immer noch zu einem weit verbreiteten Ansatz für die Simulationsmodellierung macht, wurde in den letzten 20 Jahren eine wachsende Zahl erfolgreicher Simulationsprodukte auf der Grundlage der Objektorientierung eingeführt. Genauso wie in den zweiten 20 Jahren ein Wechsel von der Ereignisorientierung zur Prozessorientierung stattfand, hat sich in den letzten 20 Jahren ein Wechsel von der Prozessorientierung zur Objektorientierung vollzogen. Die neueren objektorientierten Tools verfügen über eine Vielzahl von Objektbibliotheken, die auf bestimmte Anwendungsbereiche wie Fertigung, Lieferkette und Gesundheitswesen ausgerichtet sind. Einige dieser Tools ermöglichen es den Benutzern auch, ihre eigenen Objektbibliotheken für bestimmte Anwendungsbereiche zu erstellen und anzupassen. Der Grundgedanke der Möglichkeit, benutzerdefinierte Objekte als formales Konzept zu erstellen, wurde von OleJohan Dahl und Kristen Nygaard vom Norwegischen Rechenzentrum in Oslo in den 1960er Jahren in Simula und Simula 67 (Dahl et al. 1967) eingeführt. Simula führte den Begriff der Verhaltensklassen (z. B. Server, Worker, Roboter) und deren Instanzen (Objekte, z. B. Fred und Drill) als Teil eines expliziten Modellierungsparadigmas ein. Ein Modellierer kann eine Objektklasse wie z. B. Car erstellen und dann mehrere Instanzen dieser Klasse in sein Modell einfügen und das Verhalten jeder Instanz durch das Setzen von Eigenschaftswerten anpassen. Sie führten auch den Begriff der Unterklassenbildung von Objekten ein. Mit diesem leistungsfähigen Konzept kann ein Benutzer eine neue Objektklasse aus einer vorhandenen Objektklasse erstellen, indem er das Verhalten der Objektklasse erbt, überschreibt und erweitert. Zum Beispiel könnte eine neue Objektklasse namens Truck aus der Objektklasse Car erstellt werden, indem einige Verhaltensweisen neu definiert und einige neue Verhaltensweisen hinzugefügt werden. Die Möglichkeit, eine neue Objektklasse zu erstellen, indem man von einer vorhandenen Objektklasse ausgeht, die einige gewünschte Verhaltensweisen aufweist, vereinfacht die Entwicklung von Objektbibliotheken erheblich.
Ein Großteil der innovativen Arbeit bei der Entwicklung von Simulationssprachen findet in objektorientierten Simulationswerkzeugen statt. Diese Werkzeuge werden immer flexibler, behalten aber ihren Vorteil in Bezug auf die Benutzerfreundlichkeit bei und verdrängen daher die prozessorientierten Werkzeuge. Sie haben auch einen entscheidenden Vorteil in Bezug auf die Animation. Bei der Ereignis- und Prozessorientierung ist das Hinzufügen von Animationen ein zweistufiger Prozess, bei dem der Benutzer zunächst das logische Modell aufbaut, dann in einem separaten Schritt die Animation erstellt und anschließend diese beiden Komponenten miteinander verknüpft. In der Objektorientierung werden die vordefinierten Objekte nicht nur mit ihren zugehörigen Eigenschaften, Zuständen und Verhaltensweisen, sondern auch mit den zugehörigen 3D-Animationen geliefert. Dadurch kann der Benutzer sowohl die Modelllogik als auch die Animation in einem einzigen Schritt erstellen.
Systemdynamik ist ein Modellierungsansatz, der in den späten 1950er Jahren am MIT von Jay Forrester (Forrester 1961) entwickelt wurde. Es handelt sich um eine Form der kontinuierlichen Simulation, bei der sich die Variablen kontinuierlich mit der Zeit ändern können. Manchmal wird die Systemdynamik zur Annäherung an große diskrete Systeme verwendet (z. B. bei der Modellierung von Populationen). In ihrer allgemeinen Form hat die Systemdynamik eine Reihe von Zustandsvariablen, die dynamisch mit einer Reihe von Differentialgleichungen verbunden sind. Für die meisten Anwendungen bestehen die Modelle jedoch aus "Niveaus" und "Raten", wobei die Niveaus einfach Zustandsvariablen und die Raten Differentiale erster Ordnung sind (Sterman 2000). Indem wir uns auf diese einfache Form beschränken, kann ein breites Spektrum an dynamischen Systemproblemen modelliert werden. Die Systemdynamik wird häufig durch Kausalschleifendiagramme und durch Bestands- und Flussdiagramme beschrieben.
Ein Kausalschleifendiagramm ist ein visuelles Mittel, um die Struktur und das Verhalten des Systems darzustellen. Ein detaillierteres Modell ist jedoch die Darstellung der Bestände und Flüsse. Ein Vorrat kann als Tank dargestellt werden, der sich füllt und leert und die Höhe einer Zustandsvariablen misst, z. B. die Anzahl der Patienten in einer Notaufnahme oder die Anzahl der Personen, die einer Krankheit ausgesetzt waren. Ein Fluss wird als ein Ventil dargestellt, das die Änderungsrate eines Bestands steuert. In diesem Beispiel kann der Zustrom von Patienten in die Notaufnahme durch den Umfang der Versicherung gesteuert werden. Wenn die Zahl der Versicherten steigt, sinkt die Zahl der Besuche in der Notaufnahme. All dies kann jedoch durch die Kosten abgeschwächt werden, die die Zahl der Nichtversicherten erhöhen, was wiederum die Inanspruchnahme der Notaufnahme steigert.
Forrester veröffentlichte 1961 das erste und immer noch klassische Buch auf diesem Gebiet mit dem Titel Industrial Dynamics (Forrester 1961). Eines der bekanntesten Modelle der Systemdynamik ist ein Modell des Wachstums der Weltbevölkerung, das 1972 in dem Bestseller Grenzen des Wachstums (Meadows et al. 1972) veröffentlicht wurde. Dieses Modell prognostizierte das exponentielle Wachstum von Bevölkerung und Kapital bei endlichen Ressourcen, was unter einer Vielzahl von Szenarien zum wirtschaftlichen Zusammenbruch führen würde. Das ursprüngliche Modell hatte fünf Stufen, die die Weltbevölkerung, die Industrialisierung, die Umweltverschmutzung, die Nahrungsmittelproduktion und die Erschöpfung der Ressourcen maßen.
Obwohl jedes kontinuierliche Simulationswerkzeug zur Simulation von System Dynamics-Modellen verwendet werden kann, wurde eine Reihe von speziellen Modellierungswerkzeugen entwickelt. Zum Beispiel (siehehttps://en.wikipedia.org/wiki/Comparison_of_system_dynamics_software). Ursprünglich war die wichtigste Simulationssprache für die Systemdynamik Dynamo (heute nicht mehr in Gebrauch), aber heutzutage sind Sprachen wie Stella(https://www.iseesystems.com/store/products/stella-architect.aspx) und Vensim(http://vensim.com/) in der Systemdynamik-Gemeinschaft beliebt. Andere Simulationssprachen wie PowerSim(http://www.powersim.com/) und AnyLogic(http://anylogic.com/) haben Systemdynamik-Komponenten, bieten aber jetzt auch andere Kombinationen mit Ereignis- und Prozesselementen an. Auch wenn Systemdynamikmodelle als kontinuierliche Systeme ausgedrückt werden, geht es bei den meisten Anwendungen um die Modellierung großer diskreter Systeme mit vielen Einheiten. Eine Alternative zu System Dynamics für große diskrete Systeme ist die Modellierung von Agenten.
Die agentenbasierte Modellierung (ABM) erweitert die Idee von Objekten auf "Agenten", deren Eigenschaften stark mit menschlichem Verhalten assoziiert werden, obwohl es keine universelle Übereinstimmung über ihre Definition gibt. Diese Tendenz, Agenten wie Menschen zu behandeln, bedeutet, dass Agenten intelligente, autonome Eigenschaften haben müssen und die Fähigkeit, unabhängige Entscheidungen zu treffen. Obwohl Agenten unabhängig sein können, befinden sie sich in einer Umgebung mit anderen Agenten, und daher gibt es Regeln, die sowohl die individuelle Entscheidungsfindung als auch die Interaktion mit anderen Agenten regeln. Im Allgemeinen werden ABM auf gesellschaftliche Probleme angewandt, die soziales Verhalten wie Schwärmen, Schwärmen, Folgen usw. widerspiegeln. Einige Elemente der ABM umfassen auch die Systemdynamik.
Das Grundkonzept der agentenbasierten Modellierung (siehe North und Macal 2007) besteht darin, dass ein System modelliert wird, indem Agenten in das System platziert werden und das System sich aus der Interaktion dieser Agenten entwickelt. Jeder Agent ist eine autonome Einheit, die mit anderen Einheiten im System interagiert. Der Schwerpunkt liegt auf der Modellierung des Agentenverhaltens im Gegensatz zum Systemverhalten. Bei einer traditionellen Prozessorientierung folgen die Entitäten einer Abfolge von Prozessschritten, die aus der Top-Down-Perspektive des Systems definiert werden. Im Gegensatz dazu werden bei der agentenbasierten Modellierung die (oft einfachen) lokalen Verhaltensregeln jeder Entität aus einer Bottom-up-Perspektive definiert. Das Systemverhalten ergibt sich als kumulatives Ergebnis der Interaktion der Agenten untereinander. Anwendungsbeispiele sind Menschenmengen, die sich durch ein Gebiet bewegen, Kunden, die auf neue Produkteinführungen reagieren, oder Truppen im Kampf.
Der Zustandsübergangsrahmen für die Agenten kann unter Verwendung einer beliebigen Weltsicht modelliert werden. Die agentenbasierte Modellierung wird häufig mit einem objektorientierten Simulationswerkzeug implementiert. Es handelt sich also nicht um eine neue ereignisdiskrete Weltsicht, sondern um eine Gruppe von Anwendungen, die häufig mit der objektorientierten Weltsicht modelliert werden. Klassen werden verwendet, um die Zustände und Verhaltensweisen der Agenten zu definieren, und Instanzen (oft eine große Anzahl) werden im Modell platziert. Die Agenten (Objekte) interagieren und der Systemzustand entwickelt sich mit der Zeit. Einige der Anwendungsbereiche der agentenbasierten Modellierung stellen besondere Herausforderungen dar, insbesondere wenn eine große Anzahl von Agenten beteiligt ist (z. B. bei der Modellierung der Evakuierung von Fans aus einem Stadion).
Für einfache Anwendungen der agentenbasierten Modellierung ist der vollständige objektorientierte Rahmen mit Vererbung und Unterklassenbildung manchmal leistungsfähiger als nötig, und ein einfaches Zustandsdiagramm kann für die Definition des Klassenverhaltens für jeden Agenten ausreichend sein. Das Konzept des Zustandsdiagramms wurde von Shannon und Weaver (Shannon 1949) in ihrem 1949 erschienenen Buch The Mathematical Theory of Communication eingeführt. Ein Zustandsdiagramm definiert eine endliche Menge von Zuständen, die der Agent einnehmen kann, zusammen mit den Übergangsbedingungen, die einen Übergang zwischen einem Paar von Zuständen bewirken. Jedes Diagramm definiert typischerweise das Verhalten eines Objekts einer bestimmten Klasse und die Zustandsübergänge für die Objektinstanzen dieser Klasse. Obwohl es verschiedene Varianten von Zustandsdiagrammen gibt, definieren sie alle Zustände als Knoten und Bögen für den Übergang zwischen den Zuständen. Das Zustandsdiagramm von Agenten kann z. B. zeigen, wie eine infizierte Population verarbeitet wird und wie Zustandsänderungen im Laufe der Zeit auftreten.
Aufgrund der gestiegenen Kapazität von Computern zur Verwaltung einer großen Anzahl von Agenten können einige Modelle, die früher als diskrete Annäherungen mit Hilfe eines systemdynamischen Ansatzes erstellt wurden, jetzt besser mit einem agentenbasierten Modellierungsansatz erstellt werden. Dies ermöglicht eine größere Flexibilität in der Logik auf Kosten einer längeren Ausführungszeit. Eines der ersten agentenbasierten Modelle war das Game of Life, das von John Conway in den 1970er Jahren entwickelt wurde (Conway 1970). Das Game of Life ist ein zweidimensionales Modell mit zellulärem Wachstum, das sich mit einem festen Zeitschritt entwickelt, wobei jede Zelle zwei Zustände hat: lebendig und tot. Der Zustand einer Zelle hängt vom Zustand der Nachbarzellen des vorherigen Zeitschritts ab. Conways Spiel demonstriert das grundlegende Konzept der Entstehung von Komplexität aus einfachen Regeln.
Das Interesse an der agentenbasierten Modellierung nahm in den 1990er Jahren mit dem Erscheinen verschiedener agentenbasierter Werkzeuge, insbesondere Swarm(https://en.wikipedia.org/wiki/Swarm_(app)), NetLogo(https://ccl.northwestern.edu/netlogo/), Recursive Porous Agent Simulation Toolkit (Repast)(http://repast.sourceforge.net/repast_3/) und AnyLogic (http://anylogic.com/), weiter zu und diversifizierte sich.
Unsere eigenen Erfahrungen mit Simulationsmodellierung und Simulationssprachen reichen von den späten 1970er Jahren bis heute. Obwohl die Modellierungsansätze unterschiedlich sind und sich von den zuvor besprochenen Standpunkten aus erstrecken, basieren sie nach wie vor auf den Techniken von Ereignissen und Prozessen mit neueren Interessen an objektorientierten Methoden und Multiparadigmen, die wir im nächsten Abschnitt beschreiben. Wir stellen Beobachtungen für ihre historischen Erkenntnisse vor.
Die Entwicklung von SLAM geht auf eine Simulationsklasse zurück, die von C. Dennis Pegden im Frühjahr 1978 an der University of Alabama in Huntsville (UAH) gehalten wurde. Obwohl Pegden während seines Studiums an der Purdue University einen Simulationskurs bei A. Alan B. Pritsker absolviert hatte, lag sein Schwerpunkt auf mathematischer Optimierung, so dass das Unterrichten dieses Simulationskurses an der UAH für Pegden sowohl eine Herausforderung als auch eine Lernerfahrung war. Die Klasse bestand aus einem Dutzend Teilzeitstudenten, von denen viele in ihrer Vollzeitbeschäftigung bei der NASA und verschiedenen Raumfahrtunternehmen täglich mit Simulationen arbeiteten. Einige der Studenten waren bereits erfahrene Benutzer von GPSS, SIMSCRIPT und anderen Simulationstools. Angesichts dieses beeindruckenden Hintergrunds der Studenten beschloss Pegden, das Fachwissen der Studenten durch Teamteaching zu nutzen und sich auf einen Vergleich der Ereignis-, Prozess- und Objektansätze sowie auf effiziente Algorithmen zur Implementierung von Simulationswerkzeugen zu konzentrieren. In diesem Kurs lernte Pegden die Unterschiede zwischen dem Ereignis-, Prozess- und Objektansatz kennen und entwickelte die Idee, eine Ereignis- und Prozessmodellierungssprache in einem einzigen Rahmenwerk zusammenzuführen. Da die GASP IV-Software öffentlich zugänglich war, verwendete Pegden GASP IV als Ereignis- und Kontinuitätskomponente von SLAM und erweiterte dieses Framework um eine neue Prozessmodellierungsfunktion. Die SLAM-Sprache wurde parallel zu und als direktes Ergebnis des Unterrichts in dieser Klasse entwickelt.
Zum Zeitpunkt der Fertigstellung von SLAM vermarktete Pritsker and Associates das Simulationsprodukt GASP IV, das von Nicholas Hurst im Rahmen seiner Doktorarbeit unter der Leitung von Alan Pritsker entwickelt worden war. Da SLAM alle Funktionen von GASP IV und zusätzlich die Möglichkeit der Prozessmodellierung bot, stellte es eine deutliche Verbesserung gegenüber GASP IV dar. Im Sommer 1978 reiste Pegden zu Pritsker and Associated und präsentierte die Vorteile von SLAM und schlug Pritsker and Associates vor, SLAM anstelle von GASP IV zu vermarkten. Man einigte sich auf eine Marketing-Vereinbarung und vereinbarte, gemeinsam ein neues Lehrbuch über Simulation mit SLAM zu verfassen. Mit dem neuen Buch und der Unterstützung von Pritsker wurde SLAM schnell ein Markterfolg.
In den folgenden Jahren verlagerte Pegden sein Forschungsinteresse von der Optimierung auf die Simulation und begann, SLAM zur Modellierung komplexer Systeme einzusetzen. Er erkannte schnell, dass das Produkt zwar für viele Lehrbuchprobleme gut funktionierte, dass aber die Einschränkungen der Prozessmodellierungsfunktionen den Benutzer zwangen, für die meisten komplexen realen Anwendungen auf die Ereignisansicht zurückzugreifen. Das ursprüngliche Ziel, ein Simulationswerkzeug zu entwickeln, das leichter zu erlernen und für reale Anwendungen zu verwenden ist, wurde daher für viele komplexe Anwendungen - insbesondere in der Fertigungsumgebung - nicht erreicht. Es wurde klar, dass eine viel reichhaltigere und leistungsfähigere Prozesssprache erforderlich sein würde, um dieses Ziel zu erreichen, und dass spezielle Funktionen benötigt wurden, um einige Fertigungsanwendungen abzudecken. Daher beschloss Pegden, noch einmal ganz von vorne anzufangen und die Sprache SIMAN zu entwickeln.
Die Entwicklung der SIMAN-Sprache begann im Frühjahr 1981. Der Schwerpunkt des Entwurfs lag sowohl auf der Erweiterung der Vollständigkeit der Prozessmerkmale als auch auf der Verbesserung der Ausführungseffizienz. Im Sommer 1981 kam der erste IBM PC auf den Markt und wurde zur Zielplattform für die SIMAN-Entwicklung, was zusätzliche Anforderungen an die Speichereffizienz und Ausführungsgeschwindigkeit stellte. Im August 1981 nahm Pegden ein einjähriges Sabbatical bei Tektronix Inc. in Portland Oregon und konzentrierte sich ganz auf die Entwicklung der SIMAN-Sprache. Während dieser Zeit wurden mehrere Fertigungsprozesse mit Hilfe von Beta-Versionen der Sprache erfolgreich modelliert, was die Idee bestätigte, dass SIMAN eine erhebliche Verbesserung der Prozessmodellierungsfähigkeit bietet. Während dieses Sabbaticals wurde auch ein Lehrbuch über Simulation mit SIMAN geschrieben (Pegden 1982).
Im Sommer 1982 setzte sich Pegden mit Pritsker and Associates in Verbindung, um sich nach deren möglichem Interesse an der Vermarktung von SIMAN zu erkundigen. Diese waren jedoch stark in SLAM investiert und zeigten kein Interesse an dem neuen SIMAN-Produkt. Daher gründeten Dennis und Lisa Pegden im Dezember 1982 die System Modeling Corporation und brachten die SIMAN-Sprache auf den Markt - mit sofortigem Erfolg. Drei Schlüsselfaktoren waren für das anfängliche Marktwachstum ausschlaggebend: (1) die erheblich verbesserte Fähigkeit von SIMAN zur Prozessmodellierung, (2) die auf Fertigungsanwendungen ausgerichteten Funktionen und (3) die Fähigkeit von SIMAN, auf dem neuen IBM PC zu laufen. SIMAN enthielt spezielle Konstruktionen zur Modellierung komplexer Materialtransportanlagen wie FTS und Förderanlagen. SIMAN implementierte auch das von Zeigler (Zeigler 1984) propagierte Konzept des experimentellen Rahmens, der die Modelllogik von den Experimenten trennt.
Nach der Einführung von SIMAN entwickelte die Systems Modeling Corporation das PC-basierte Animationssystem Cinema (1985), um SIMAN-Modelle in Echtzeit zu animieren. Dieses System war realistischer als die bestehenden zeichenbasierten Animationssysteme und bot durch die parallele Ausführung zum SIMAN-Modell eine leistungsfähige interaktive Plattform zur Überprüfung/Validierung von Modellen. Dies war ein wichtiger Schritt, um die Möglichkeiten der Animation in der Simulation zu nutzen. Da Microsoft Windows noch nicht zur Verfügung stand, wurde Cinema mit einem speziell entwickelten Fenstersystem entwickelt. Da der Standard-PC nur eine Auflösung von 320 x 200 Pixeln hatte, benötigte die erste Version von Cinema eine spezielle High-End-Grafikkarte und einen Monitor eines Drittanbieters, um die erforderliche Auflösung für eine qualitativ hochwertige Animation zu erreichen. SIMAN und Cinema wurden dann zum Simulationssystem Arena (1991) kombiniert und auf Microsoft Windows portiert. Arena führte das Konzept der grafischen Prozesse für die Modellerstellung anstelle von Anweisungen ein und bot eine Dialogfeldschnittstelle für die Eingabe von Eigenschaften. Außerdem unterstützte es sowohl die Input- als auch die Output-Analyse. Arena erfreute sich in kommerziellen Anwendungen großer Beliebtheit und wurde zum vorherrschenden Simulationsprodukt, das von Universitäten für die Lehre von Simulationskonzepten verwendet wurde. Die Popularität an den Universitäten wurde durch die Modellierungsflexibilität von SIMAN, die Benutzerfreundlichkeit der grafischen Oberfläche und die beliebten Lehrbücher "Simulation with Arena" von W. David Kelton, Randall P. Sadowski, Deborah A. Sadowski und David T. Sturrock gefördert. Im Jahr 2000 wurde die System Modeling Corporation von Rockwell aufgekauft, die das Produkt Arena derzeit vermarktet und unterstützt.
Obwohl SIMAN einen Fortschritt in der Modellierungsflexibilität darstellte, gab es immer noch viele komplexe Anwendungen, die mit der Prozessansicht schwer zu modellieren waren. Ein Problem, das häufig auftrat, war, dass Ressourcen (wie auch Entitäten) in SIMAN keine benutzerdefinierten Entscheidungsmöglichkeiten hatten. Obwohl Entitäten Ressourcen in Anspruch nehmen konnten, hatten die Ressourcen kein Mitspracherecht im Prozess. In manchen Systemen (z. B. im Gesundheitswesen) ist es natürlicher, dass die Ressourcen ihre eigene Logik kontrollieren. Diese Herausforderung der Modellierung von Systemen, die eine komplexe Ressourcenlogik erfordern, wurde zum Schwerpunkt der Arbeit von Stephen Roberts.
Roberts wurde 1973 als Fakultätsmitglied an der Purdue University eingestellt und hatte eine gemeinsame Stelle mit dem Regenstrief Institute for Health Care inne, das innerhalb der großen allgemeinen und fachübergreifenden Kliniken der Indiana University School of Medicine in Indianapolis, Indiana, angesiedelt war. Bei der Analyse der Betriebsmerkmale dieser Kliniken über mehrere Jahre hinweg wurde deutlich, dass nur die Simulation eine Analyse der komplexen und stochastischen Komponenten in diesen Einrichtungen ermöglichte. In Purdue entwickelten Alan Pritsker und seine Studenten Netzwerk- (Prozess-) Simulationssprachen auf der Grundlage des diskreten Simulationsteils von GASP IV. Während diese Sprachen den Fluss von Entitäten durch Prozesse betonten, war es klar, dass im Gesundheitswesen der "Patienten- und damit verbundene Fluss" nur ein Teil der Umgebung war und der Patientenfluss durch vielbeschäftigte Gesundheitsdienstleister und -mitarbeiter, die Dienstleistungen in einer dynamischen Umgebung erbrachten, stark eingeschränkt war, im Gegensatz zu Maschinen und Geräten, die man in einer Fertigungseinrichtung sehen könnte. In der Tat wurde der Fluss fast immer durch sehr aktive menschliche Ressourcen eingeschränkt, die entschieden, was getan wurde, und das hing von mehreren Faktoren ab.
In den späten 1970er und frühen 1980er Jahren wurde daher am Regenstrief-Institut ein Simulationsprodukt namens INSIGHT (früher INS) entwickelt, das den Fluss von Entitäten (damals Transaktion genannt) einschloss, sich aber an den "Stellenbeschreibungen" orientierte, die von den verschiedenen verfügbaren "menschlichen" Ressourcen ausgeführt wurden. Bei der Modellierung wurde eine Aktivität als Servicepunkt für Entitäten und Ressourcen verwendet. Die Aktivität spezifizierte die Anzahl, Art und Kombination der benötigten Ressourcen und die damit verbundene Aktivitätszeit, aber logische Warteschlangen vor einer Aktivität hielten die Entitäten fest, bis der Dienst beginnen konnte. Die Ressourcen dienten also an den Aktivitäten, aber die Entitäten wurden in den Warteschlangen bedient. Die Entitäten bewegten sich nicht in eine Aktivität hinein, sondern warteten darauf, dass die Ressourcen sie hineinbrachten. Ressourcen wurden einzeln und optional nach Typ identifiziert. Jede Ressource war mit einem Primärknoten in einem Ressourcenentscheidungsbaum verbunden. Es konnten mehrere Ressourcenentscheidungsbäume definiert werden. Dieser Primärknoten konnte sich auf die Warteschlangen innerhalb des Modells und/oder auf andere Primärknoten beziehen. Diese Primärknoten drückten die Methode zur Bewertung der zugehörigen Warteschlangen und anderer Knoten anhand von Suchkriterien aus. Beispielsweise könnte der primäre Entscheidungsknoten einer Krankenschwester darin bestehen, zuerst die Warteschlange der Patienten in den Untersuchungsräumen zu bedienen, die eine Krankenschwester benötigen, dann die Warteschlange der Patienten zu bedienen, die darauf warten, in einem Untersuchungsraum untergebracht zu werden und ihre Vitalwerte zu erfassen, und dann einen weiteren primären Entscheidungsknoten auszuführen, der besagt, dass je nach Wartezeit der Personen bei der Anmeldung oder beim Ausgang geholfen werden soll. Dieser Entscheidungsprozess könnte Teil eines anderen Entscheidungsprozesses sein oder nur für eine Ressource gelten.
In jedem Fall war der Ressourcenentscheidungsprozess dynamisch und hing entscheidend vom Zustand des Systems ab. Das Funktionieren des Entscheidungsprozesses wurde durch den von der Simulationssprache verwendeten Statusaktualisierungsalgorithmus ermöglicht. Da Ereignisse am Ende einer Aktivität alle anderen Ereignisse dominierten, war ihre Aktualisierung ein zentraler Bestandteil der Modellierung und wurde als zweistufiger Prozess bezeichnet. Wenn eine Aktivität abgeschlossen war, wurden die Ressourcen in einen vorübergehenden Haltezustand versetzt, der Pufferspeicher genannt wurde. Zu diesem Zeitpunkt sollte Phase 1 die Entität so lange in das Netz schicken, bis ihr Fortschritt durch die Notwendigkeit, Ressourcen zu erwerben, eine Aktivität zu starten oder das Netz zu verlassen, gestoppt wurde. Nach Abschluss von Phase 1 wurde Phase 2 eingeleitet, in der jede Ressource im Pufferspeicher ihren Entscheidungsbaum verwendet, um zu bestimmen, was sie als Nächstes tun soll. Sie wurde entweder mit einer anderen Aktivität beschäftigt oder wurde inaktiv. Es gab Spezifikationen, die es Entitäten erlaubten, Ressourcen aus dem Pufferspeicher zu identifizieren und zu beanspruchen, und die es erlaubten, dass die Aktualisierung einer Ressource Entitäten dazu veranlasste, Aktivitäten zu starten. Es sollte beachtet werden, dass Entitäten aufgrund von Synchronisationsanforderungen, wie z. B. Sammeln oder entfernte Bewegungen, verzögert werden konnten. Weitere Prioritäten unter den Ressourcen für die Verwendung bei Aktivitäten könnten zu einer Vorverlegung oder Wiederaufnahme von Aktivitäten führen.
Die Entwicklung der Simulationssprache INSIGHT wurde in den 1980er Jahren fortgesetzt und in Tutorials am WSC beschrieben. Der kommerzielle Erfolg blieb aus und das Regenstrief Institute stellte die Entwicklung ein, als Roberts 1990 zur North Carolina State University wechselte. In den 1990er Jahren entwickelte Roberts, hauptsächlich zusammen mit Jeff Joines, eine objektorientierte C++-Simulationssprache, deren Prozesssimulationsfunktionen INSIGHT ähnelten. Aufgrund der Polymorphie von Objekten konnte diese Simulation in einem erweiterten Entscheidungsprozess sowohl "Teams" als auch Einzel- und Typressourcen einsetzen. Darüber hinaus zeigte die Entwicklung, wie eine Sprache wie INSIGHT mit echten objektorientierten Merkmalen erweitert und ausgebaut werden kann. Die Verwendung erforderte jedoch umfangreiche C++-Programmiererfahrungen, so dass die Akzeptanz sehr begrenzt war und die Entwicklung innerhalb eines Jahrzehnts nach der Entwicklung eingestellt wurde. Obwohl INSIGHT nie ein kommerzieller Erfolg wurde, zeigte es, wie wichtig es ist, die Modellierungsflexibilität über einfache Entitätsflüsse hinaus zu erweitern, um auch die Modellierung komplexer Ressourcenlogik zu unterstützen.
Nachdem er sich einige Jahre aus dem Simulationsgeschäft zurückgezogen hatte, wurde Pegden eingeladen, auf der Winter Simulation Conference 2005 den Titan-Vortrag zum Thema Future Directions of Simulation zu halten. Dieser Vortrag war der Anstoß, sich mit dem Stand der Simulation zu befassen und darüber nachzudenken, wie man die vorhandenen Werkzeuge verbessern könnte. Daraus entwickelte Pegden das Konzept, die grundlegenden objektorientierten Konzepte zu modifizieren, um kodierte Methoden durch Prozesse zu ersetzen, wobei das Grundkonzept von Klassen, Unterklassen, Vererbung, Polymorphismus, Overriding usw. beibehalten wird. Die Motivation für diese Idee bestand darin, die Vorteile des objektorientierten Ansatzes mit Hilfe von grafischen Prozessen zu nutzen und damit die Notwendigkeit komplexer Programmierkenntnisse zu vermeiden.
Pegden nutzte diese für den Titan-Vortrag entwickelten Konzepte, um die Simulationssoftware Simio zu entwickeln, die 2008 auf den Markt gebracht wurde. Mit Simio wurde es für die Benutzer viel einfacher, Objektbibliotheken zu erweitern und zu erstellen, ohne dass sie in einer objektorientierten Sprache wie C++ oder Java programmieren müssen. Simio hat auch die Idee einer intelligenten Ressource, wie sie von INSIGHT eingeführt wurde, weiter ausgebaut. In Simio sind Ressourcen (und Entitäten) ebenfalls Objekte, die auf Anfragen mit ihrer eigenen Prozesslogik reagieren können. Dies macht es viel einfacher, Situationen zu modellieren, in denen die Entität oder Ressource die Kontrolle über ihr eigenes Verhalten hat.
Ein weiterer wichtiger Fortschritt in Simio ist die Möglichkeit, das Verhalten von Objekten durch Add-In-Prozesse zu verändern, ohne die Objektdefinition zu verändern. Vor der Einführung dieses Konzepts in Simio bestand die primäre Methode zum Hinzufügen benutzerdefinierter Logik zu einer Objektinstanz darin, dem Objekt benutzerdefinierte Ereignisse hinzuzufügen. Add-in-Prozesse waren ein bedeutender Durchbruch, da sie sowohl einfacher zu benutzen als auch leistungsfähiger sind. Die zusätzliche Leistung ergibt sich aus der Prozesslogik, die Aktivitäten darstellen kann, die sich über einen längeren Zeitraum erstrecken, während ein kodiertes Ereignis auf einen bestimmten Zeitpunkt beschränkt ist.
Die Entwicklung von SLAM - SIMAN - Arena - Simio hat sich über einen Zeitraum von fast 40 Jahren vollzogen. In dieser Zeit hat sich das primäre Modellierungsparadigma von Ereignissen zu Prozessen und Objekten verschoben. Bei SLAM war der primäre Modellierungsansatz Ereignisse, wobei Prozesse verwendet wurden, wo es möglich war. Bei SIMAN war der primäre Modellierungsansatz ein Prozess, wobei Ereignisse verwendet wurden, wenn es nötig war. Mit Cinema/Arena wurde die Animation zu einem zentralen Bestandteil des Modellierungs- und Verifikations-/Validierungsprozesses. Bei Simio ist der primäre Modellierungsansatz objektbasiert, wobei bei Bedarf Prozesse zum Einsatz kommen. Diese Entwicklung hat die Simulation einfacher gemacht, ohne die Flexibilität der Modellierung zu beeinträchtigen.
Die frühesten Simulationsmodellierungsansätze waren Reflexionen eines einzigen Simulationsparadigmas, nämlich Ereignis, Aktivität, Prozess und Objekt. In den 1970er Jahren entstand eine "kombinierte" Paradigmenmodellierung, die es dem Benutzer ermöglichte, den Modellierungsansatz zu wählen, der am besten zum Problem passte, oder Modellierungsansätze zu kombinieren, wie es die Situation erforderte. GASP IV (Pritsker 1974) machte die Idee der Kombination von diskreten und kontinuierlichen Rahmenmodellen in ein und demselben Modell populär, obwohl es bereits frühere Bemühungen anderer gab (siehe z. B. Tocher und Splaine 1966). Dieser Rahmen ermöglichte sowohl die diskrete Ereignismodellierung als auch die kontinuierliche Modellierung innerhalb desselben Simulationsmodells. Es bot sowohl Zeit- als auch Zustandsereignisse, so dass die diskreten Ereignisse die kontinuierlichen Variablen und die Zeitereignisse die diskreten Variablen beeinflussen konnten. SLAM (Pegden und Pritsker 1979) entwickelte die Kombination weiter und schloss die Prozessmodellierung mit ein. Es war eines der ersten weit verbreiteten Werkzeuge, das die Idee der Mischung alternativer Modellierungsansätze (Prozesse und Ereignisse und kontinuierliche) in ein und demselben Modell förderte. Im Falle von SLAM wurde die Prozess-/Kontinuitätsmodellierung für die grundlegende Modellierung verwendet, und die Ereignisse wurden als "Hintertür" genutzt, um zusätzliche Flexibilität zu bieten.
Die Idee, die Simulation in Kombination mit anderen Analysewerkzeugen einzusetzen, wurde schon früh in der Geschichte der Simulation informell verwendet. 1983 boten Shanthikumar und Sargent (1983) eine vereinheitlichende Definition von hybriden Simulations-/Analysemodellen. Sie stellten vier Klassen von Hybridmodellen vor, die die Möglichkeiten der Interaktion zwischen Simulation und analytischen Modellen darstellen. Swinerd und McNaught (2012) verwendeten kürzlich eine Kombination aus einer agentenbasierten Simulation und einem analytischen Modell, um einen Fall von hybrider Simulation zu schaffen.
Die modernen objektorientierten Simulationswerkzeuge verwenden ebenfalls einen multiparadigmatischen Ansatz. Diese Werkzeuge kombinieren die einfache und schnelle Modellierung, die durch Objekte ermöglicht wird, mit der Flexibilität, die durch die Einbeziehung von benutzerdefinierten Ereignissen und/oder Prozessen entsteht. Ein Objekt, das einen Server darstellt, kann zum Beispiel ausgewählte Punkte in der Objektlogik haben, in die der Benutzer seine eigene Ereignislogik oder Prozesslogik einfügen kann. Die Ereignislogik wird in der Regel entweder mit einer Programmiersprache wie Java oder C++ oder mit einer speziellen Skriptsprache, die anstelle von Code verwendet werden kann, in die Objekte integriert. In beiden Fällen unterliegt die Ereignislogik jedoch einer wichtigen Einschränkung: Die simulierte Zeit kann innerhalb des Ereignisses nicht weiterlaufen. Dies schränkt die Art der Logik, die in eine Objektinstanz eingefügt werden kann, stark ein. Es ist zum Beispiel nicht möglich, innerhalb eines Ereignisses darauf zu warten, dass ein Arbeiter verfügbar wird, da dies ein Fortschreiten der Zeit erfordern würde. Simio(https://www.simio.com/index.php) führte einen viel leistungsfähigeren Ansatz ein, der es den Benutzern erlaubt, Objekte mit Prozessen zu kombinieren. Da Prozesse die Zeit überbrücken können, bieten sie dem Benutzer wesentlich mehr Möglichkeiten, das Verhalten seiner Objekte zu erweitern. So können Prozesse in ein Objekt eingebettet werden, um auf eine bestimmte Zeit oder eine bestimmte Bedingung zu warten (z. B. Fred ist verfügbar). Dieser Ansatz kombiniert die volle Leistungsfähigkeit und Flexibilität von Prozessen mit der Einfachheit und schnellen Modellierbarkeit von Objekten.
AnyLogic(http://anylogic.com/) hat agentenbasierte Modellierung, Systemdynamik und diskrete Ereignismodellierung in einem einzigen Tool kombiniert. Ein einziges AnyLogic-Modell kann alle drei Modellierungsansätze kombinieren, um das Systemverhalten darzustellen.
Neben dem Interesse an Multiparadigmen besteht auch ein Interesse an der Vereinheitlichung der Simulationsmodellierung innerhalb eines bestimmten Rahmens oder einer Simulationstheorie. Im Jahr 1981 beschrieb Nance (Nance 1981) die grundlegenden Rollen von Zeit und Zustand in diskreten Ereignissimulationen, was schließlich zu der Conical Methodology (Overstreet und Nance 1985) führte, die einen Rahmen für die Kapselung der grundlegenden Modellierungsstandpunkte von Ereignis, Aktivität und Prozess bietet.
Die bekannteste Simulationstheorie ist der 1984 erstmals von Zeigler vorgeschlagene Formalismus (Zeigler 1984), der heute als DEVS (Discrete Event System Specification) bekannt ist. Im Laufe der Jahre wurde diese Theorie weiterentwickelt und auf zahlreiche Fälle angewendet (siehe (Zeigler und Muzy 2017). DEVS ist eine formale Systemtheorie, die aus Eingaben, Zuständen und Ausgaben in Kombination mit Zeitverlaufsfunktionen besteht, um sowohl diskrete als auch kontinuierliche (potenziell hierarchische) Systemkomponenten zu modellieren. Die Abstraktion bietet einen Rahmen, der Modellierung und Simulationsausführung trennt, um beispielsweise die Reihenfolge und potenziell parallele Ausführung von Ereignissen hervorzuheben. Der DEVS-Formalismus hat weltweites Interesse geweckt, und seine Formulierung hat eine Reihe von Erweiterungen und Interpretationen erfahren.
Schruben und Yucesan (Schruben und Yücesan 1993) zeigen anhand eines graphentheoretischen Ansatzes, dass eine Ereignisgraphenansicht der diskreten Ereignissimulation zur Schaffung einer vollständigen und konsistenten Modellentwicklungs- (Problemlösungs-) Umgebung verwendet werden kann. Ein Ereignisgraphenmodell ist nicht nur visuell ansprechend, sondern bietet auch einen rigorosen Rahmen für die Modellerstellung (Savage et al. 2005).
In den ersten 30 Jahren der Simulation erfolgte die Ausgabe in Form von Textberichten. Obwohl die visuelle Animation der Simulationsausführung bereits 1970 ins Auge gefasst wurde (Reitman et al. 1970), wurde die Animation erst in den 1980er Jahren in die kommerzielle Simulation integriert. Über die Vorzüge der Animation wurde viel diskutiert. Viele hielten die Animation für einen Schnickschnack, der keinen wirklichen Einfluss auf den Erfolg eines Simulationsprojekts hatte. Heute wird die Animation jedoch als entscheidender Bestandteil erfolgreicher Simulationsprojekte angesehen, und sie spielt eine Schlüsselrolle bei der Ausweitung von Simulationsanwendungen im Unternehmen. Einer der wichtigsten Vorteile der Animation ist die Fähigkeit, das Modellverhalten allen Beteiligten am Modell zu vermitteln. Jeder, von der Werkstatt bis zur Chefetage, kann das in das Modell eingebaute Verhalten sehen. Die Animation verdeutlicht die Modellierungsannahmen und ist ein leistungsfähiges Werkzeug für die Überprüfung und Validierung des Modells.
Bevor es die Animation gab, mussten die Entscheidungsträger darauf vertrauen, dass das Modell das Verhalten des realen Systems mit dem entsprechenden Detaillierungsgrad genau wiedergibt. Die Logik des Modells konnte oft fehlerhaft sein, aber es gab keine einfache und visuelle Möglichkeit, Fehler in der Logik zu erkennen. Mit der Animation wird das Modell zum Leben erweckt, und das Verhalten wird deutlich sichtbar. Animationen in Kombination mit interaktiven Debuggern haben die Fähigkeit, logische Fehler in einem Modell zu finden und zu beheben, radikal verbessert. Animationen helfen Modellierern nicht nur, unbeabsichtigte Fehler in der Logik zu finden und zu beheben, sondern auch, die geplanten vereinfachenden Annahmen, die Teil jedes Modells sind, zu vermitteln. Die Animation ist eine wesentliche Komponente, um Vertrauen in die Modellergebnisse zu schaffen.
Eines der frühen Simulationsanimationssysteme war das in den späten 80er Jahren entwickelte Produkt See Why, das rudimentäre zeichenbasierte Animationen verwendete. Die Witness-Simulationssoftware(https://www.lanner.com/technology/witness-simulation-software.html) wurde aus See Why entwickelt. Das Animationssystem Cinema war ein vektorbasiertes 2D-Animationssystem, das im gleichen Zeitraum entwickelt wurde und ein Echtzeit-Animationssystem für SIMAN-Modelle war. Das Cinema-Animationssystem und das SIMAN-Modellierungssystem wurden dann in eine einzige Plattform integriert, um das weit verbreitete Produkt Arena zu schaffen. Ein weiteres frühes 2D-Animationssystem war Proof(http://www.wolverinesoftware.com/ProofProducts.htm), entwickelt von Jimes O. Henriksen von Wolverine Software im Jahr 1989.
In den 90er Jahren kamen die ersten 3D-Animationsmöglichkeiten auf. Zu den frühen Systemen gehörten AutoMod (mit Schwerpunkt auf Materialtransportsystemen) (http://www.appliedmaterials.com/global-services/automationsoftware/automod), Taylor ED (ein Vorläufer von FlexSim(https://www.flexsim.com/)) und Simple++ (ein Vorläufer von PlantSim (https://www.plm.automation.siemens.com/)). Die Animationsdebatte hat sich auch auf die Frage ausgeweitet, ob 3D-Animationen mit hoher Wiedergabetreue oder 2D-Animationen erforderlich sind. Einige argumentieren, dass die 2D-Animation ausreicht, um die meisten Vorteile der Animation zu nutzen, und dass der zusätzliche Aufwand für die 3D-Animation einen abnehmenden Nutzen bringt. Obwohl eine hochwertigere 3D-Animation das zugrunde liegende Modell oder die Ergebnisse im Vergleich zu einer 2D-Animation nicht verändert, kann der verbesserte Realismus dazu beitragen, die Modellergebnisse zu vermitteln. Mit den Verbesserungen in der 3D-Animation und der breiten Verfügbarkeit von 3D-Symbolen ist der Aufwand für die Erstellung der 3D-Animation nicht mehr so hoch. Daher bieten die meisten modernen Simulationswerkzeuge eine 3D-Animationsumgebung.
Die Kombination aus objektorientiertem Framework, einer immersiven 3D-Modellierungsumgebung und verbesserten 3D-Zeichenfunktionen hat sich als eine sehr leistungsfähige Kombination erwiesen, um 3D-Animation in den Mainstream der Simulationsmodellierung zu bringen. Die meisten modernen Simulationswerkzeuge bieten jetzt 3D als Standardfunktion.
Die nächste Welle der Simulationsanimation ist die Entwicklung von Virtual-Reality-Umgebungen (VR) für die Darstellung von Simulationsanimationen. Dies ermöglicht es dem Betrachter, in das Modell einzutauchen und durch das System in einer VR-Umgebung zu gehen, die das reale System nachahmt, und möglicherweise mit der Simulation zu interagieren, indem er Objekte bewegt, den Verkehr umleitet oder die Simulationsaktivitäten verändert. Mehrere Simulationssysteme (z. B. Simio, FlexSim, Emulate3D(https://www.demo3d.com/)) unterstützen bereits VR-Umgebungen zur Betrachtung von Animationen. Der nächste Schritt in der Entwicklung der VR-Darstellung ist es, dem Benutzer zu erlauben, in die Animation einzugreifen.
Die Geschichte der Simulation ist voll von zahlreichen Simulationssprachen und Simulationspaketen, die oft einzigartige Modellierungskomponenten für sich beanspruchen. Viele sind auf dem Markt der Popularität untergegangen, weil sie nicht in der Lage waren, ein Simulationspublikum zu erobern. Im Gegensatz zur kontinuierlichen Simulation, die auf der Lösung von Differentialgleichungen beruht, gibt es für diskrete Simulationen keine allgemein anerkannte Grundlagentheorie. Infolgedessen ist die Modellierung von Simulationen eher im Bereich der "Kunst" angesiedelt. In der Praxis erfordert die Kunst der Simulation eher ein umfassendes Wissen darüber, was mit dem verwendeten Werkzeug simuliert werden kann, als eine uneingeschränkte Konzentration auf das zu lösende Problem. Folglich sind erfolgreiche Simulationen in der Regel das Produkt eines kommerziellen Interesses, das durch eine Fülle von Dokumentationen und Lernwerkzeugen unterstützt wird, und zwar in einem Rahmen, der die Vorteile des Werkzeugs fördert.
Es ist allgemein anerkannt, dass die Umsetzung eines Problems in eine Simulation eine Verschmelzung der Leistungsziele des Systems, der verfügbaren Eingabedaten und der Modellierungsfähigkeiten des Modellierers darstellt. Es gibt eine Reihe von Möglichkeiten, mit den verfügbaren Eingabedaten und verschiedenen Leistungsmaßen umzugehen (siehe (Banks et al. 2010; Law 2015). Die Modellkonzeption stützt sich im Allgemeinen auf grafische Darstellungen (Blockdiagramme, Flussdiagramme, Aktivitätszyklusdiagramme usw.), die in der Regel mit spezifischen Simulationssprachen verbunden sind, und es gibt nur eine begrenzte systematische Diskussion über allgemeine Ansätze. Robinson (Robinson 2008a, b) stellt einen zweiteiligen konzeptionellen Modellierungsrahmen vor. Die Bedeutung und Anforderungen des konzeptionellen Modells umfassen: Validität, Glaubwürdigkeit, Nützlichkeit und Machbarkeit. Die eigentliche Modellierungstätigkeit besteht aus: dem Verständnis der Problemsituation, der Bestimmung der Modellierungs- und allgemeinen Projektziele, der Ermittlung des Modelloutputs, der Ermittlung der Modelleingaben und der Bestimmung des Modellinhalts. Zusammen bilden sie einen Rahmen für die Konzeptualisierung, ergeben aber noch kein Berechnungsmodell. Die Umsetzung des konzeptionellen Modells muss noch durch eine Simulationssprache oder ein Simulationspaket erfolgen, das dem Simulationsmodellierer zugänglich ist.
Die Rolle der Simulationssprache bei der Simulationsmodellierung ist nach wie vor untrennbar mit ihr verbunden. Bemühungen, die Modellierung durch grafische Techniken und natürliche Sprache transparenter und sichtbarer zu machen, bieten ein erhebliches Potenzial für die Simulationsmodellierung. Dennoch muss die Simulationstechnologie mit der Speicherung und Analyse großer Datenmengen verknüpft werden, um ihr größeres Potenzial im Zuge des Fortschritts der Rechentechnik auszuschöpfen.