240 likes | 341 Views
Simulationsanwendungen sind sehr beliebt und modern.
E N D
SWiInf WIP – Simulation Sommersemester 2005 Zusammenfassung Simulation Allgemeine Einführung und Anwendungsgebiete „Dabei ist zu bemerken, dass nichts größere Schwierigkeiten in der Ausführung bietet und von zweifelhafterem Erfolg ist, als ein neues System zu errichten.“ Machiavelli Anwendungsgebiete • Produktion und Logistik • Öffentliche Institutionen / Organisationen o Gesundheitswesen o Militär o öffentlicher Dienst • Dienstleistungssektor o Transportwesen o Luftverkehr o Computersysteme o Kommunikationssystem Produktion und Logistik • Aufzeigen von Rationalisierungspotentialen Wichtig ist ein flexibel einsetzbares Simulationswerkzeug. •Computer Integrated Manufacturing (CIM) CIM steht für computerintergrierte Produktion. Es ist ein Sammelbegriff für verschiedene andere Tätigkeiten, die in einem Unternehmen durch den Computer unterstützt werden. Die Bestandteile von CIM sind: CAD (rechnergestützter Entwurf) CAP (rechnergestützte Arbeitsplanung) CAQ (rechnergestützte Qualitätssicherung) CAM (rechnergestützte Fertigung) PPS Produktionsplanung und -steuerung) BDE (Betriebsdatenerfassung) Michael Heß Alle Angaben ohne Gewähr 1 / 24
SWiInf WIP – Simulation Sommersemester 2005 Im Jahre 1973 stellte Joseph Harrington das Konzept des Computer Integrated Manufacturing vor. Damit wollte er die Bedeutung von Informationen in der Produktion, sowie die Synergiepotentiale bei der Verknüpfung der Insellösungen hervorheben. Er sprach von pieces of puzzles, damit meinte er die Insellösungen, wie CAD, NC (= Numeric Controll ? Numerische Steuerung), CAM, usw. welche in einem Betrieb alleine, ohne jede EDV-Anbindung untereinander, angewandt wurden. Simulation von Verkehrssystemen • Individualverkehr (PKW / LKW) • ÖPNV • Güterverkehr / Güterumschlag (Schiene, Straße, Luft, Wasser) • Fernbahnen (Fernverkehr der Deutschen Bahn) Fazit Grundsätzlich kann Simulation in allen Bereichen angewandt werden, deren Abläufe formalisiert werden können. Dies trifft insbesondere auf alle Lebenszyklusphasen technischer Produkte zu (Herstellung, Planung, Entwicklung, Organisation, Michael Heß Alle Angaben ohne Gewähr 2 / 24
SWiInf WIP – Simulation Sommersemester 2005 Realisierung, Betrieb, Wartung). Außerdem lassen sich mittels Simulationen Struktur- und Funktionsanalysen durchführen. Diese dienen der Steuerung und Regelung, Optimierung und Entscheidung und der Prognose und Diagnose. Handsimulation Eine Handsimulation eines Programms ist die gedankliche Ausführung des Programms mit Bleistift und Papier. Vorteile der Handsimulation sind deren Genauigkeit und somit das Auffinden von Fehlern im Simulationsalgorithmus. Nachteilig sind der große zeitliche Aufwand und die immer schwierigere Durchführung, je komplexer die Simulation wird. ARENA-Guide Create Module Das Create Module ist der Startpunkt einer jeden Simulation. Von hier aus fließen die Entitäten durch das Modell. Eigenschaften, wie Zeitintervalle, können dem Create Module übergeben werden. Eine Simulation kann beliebig viele Create Modules enthalten. Process Module Ein Process Module stellt einen Vorgang dar, der in der Regel Ressourcen (Personal - resource, Zeit - delay, …) bindet. Ein Entity tritt zu einem Zeitpunkt in das Process Module ein und Bearbeitungszeit Bearbeitungszeit nach der Dreiecksverteilung ermittelt, d.h. man gibt die Bearbeitungszeit an und das Programm ermittelt bei jedem Entity-Eintritt mittels der Dreiecksverteilung die aktuelle Verweilzeit des Entities im System. Benötigt ein Entity mehrere Ressourcen, dann beginnt die Bearbeitung erst, wenn alle Ressourcen verfügbar sind. Dreiecksverteilung (Triangular Distribution) verlässt wieder. es der nach Regel Ablauf wird der die In minimale, maximale und häufigste Decide Module Das Decide Module funktioniert wie eine If-Anweisung. Entweder die an das Entity gestellte Bedingung ist erfüllt oder nicht. Dementsprechend folgt eine Weiterleitung über den Pfad „True“ (Bedingung erfüllt) oder über den Pfad „False“ (Bedingung nicht Michael Heß Alle Angaben ohne Gewähr 3 / 24
SWiInf WIP – Simulation Sommersemester 2005 erfüllt). Die Bedingung wird entweder in den Eigenschaften des Decide Module angegeben, oder die Entscheidung wird nach Wahrscheinlichkeitsvorgaben getroffen, sodass bspw. 80% der Entitäten die Bedingung erfüllen und dementsprechend 20% die Bedingung nicht erfüllen. Hierbei liegen dann aber keine Werte vor, sondern die Simulation Wahrscheinlichkeitsverteilung. Soll bei einem Decide Module ein Entity beide Ausgangspfade durchlaufen, so ist die Erzeugung eines Duplikates mittels des Seperate Modules nötig, damit ein paralleler Durchlauf erfolgen kann. Dispose Module Bei einem Dispose Module terminiert die Simulation. Eine Simulation kann beliebig viele Dispose Modules enthalten, bspw. nach einem Decide Module. Alle Modules zählen die durchlaufenden Entities hoch und zeigen die Zahl während und nach der Simulation an. entscheidet lediglich anhand der Michael Heß Alle Angaben ohne Gewähr 4 / 24
SWiInf WIP – Simulation Sommersemester 2005 Begriffe und Modellierung Definitionen VDI-Richtlinie 3633 Simulation ist die Nachbildung eines dynamischen Prozesses in einem Modell, um zu Erkenntnissen zu gelangen, die auf die Wirklichkeit übertragbar sind. Shannon Simulation is the process of designing a model of a real system and conducting experiments with this model for the purpose either of understanding the behavior of the system or of evaluation various strategies (within the limits imposed by a criterion or set of criteria) for the operation of the system. Banks Simulation is the imitation of the operation of a real-world process or system over time. It is an indispensable problemsolving methodology for the solution of many real- world problems. Simulation is used to describe and analyze the behaviour of a system. Both existing and conceptual systems can be modeled with simulation. Naylor ... simulation as a numerical technique for conducting experiments with certain types of mathematical system on a digital computer over extended periods of time. Michael Heß Alle Angaben ohne Gewähr 5 / 24
SWiInf WIP – Simulation Sommersemester 2005 Kreuzer A system is defined as a collection of objects, their relationships and a behaviour relevant to a set of purposes, characterizing some relevant part of reality. Simulation bedeutet experimentieren an einem Modell Begriffe System System Abgegrenzte Anordnung von Komponenten, die zu einem gemeinsamen Zweck interagieren. Systemzustand Menge der Systemausprägungen zu einem bestimmten Zeitpunkt. Systemzweck Einzelne Komponenten können in anderem Zusammenhang differenzierte Bedeutungen haben. Grundlegende Systembegriffe Modell Modell Ein Modell ist eine vereinfachte Nachbildung eines geplanten oder existierenden Systems. Es dient der Abstraktion und Idealisierung, wodurch die Untersuchung komplexer Systeme durch Komplexitätsreduktion ermöglicht / vereinfacht wird. Modelle können nach vielfältigen Kriterien klassifiziert werden, u.a.: • Untersuchungsmethode • Abbildungsmedium • Art der Zustandsübergänge • Intendierter Verwendungszweck Michael Heß Alle Angaben ohne Gewähr 6 / 24
SWiInf WIP – Simulation Sommersemester 2005 Sichtweisen der Simulation Statische Simulation – Dynamische Simulation Eigenschaften der statischen Simulation Darstellung eines Systems zu genau einem Zeitpunkt, genau dann, wenn das System im Gleichgewicht ist (das Modell ist unabhängig von der Zeit). Eigenschaften der dynamischen Simulation Darstellung eines Systems zu mehreren Zeitpunkten (über ein Zeitintervall), Veränderungen im System resultieren aus den Systemaktivitäten im Zeitablauf. Deterministische Simulation – Stochastische Simulation Eigenschaften der deterministischen Simulation Sämtliche Systemvariablen und –werte sind eindeutig bestimmt, es existiert zu jedem Systeminput ein bestimmter Output. Eigenschaften der stochastischen Simulation Nicht alle Systemvariablen und –werte sind deterministisch festgelegt, d.h. zu einem System gibt es (zufallsbedingt) verschiedene Outputs. Endogene Simulation – Exogene Simulation Eigenschaften der endogenen Simulation Sämtliche Systemvariablen und –werte tauchen nur innerhalb des Systems auf. Eigenschaften der exogenen Simulation Es existieren auch Variablen und Aktivitäten außerhalb des Systems (d.h. in der Systemumgebung), die das Verhalten des Systems beeinflussen. Diskrete Simulation – Kontinuierliche Simulation Eigenschaften der diskreten Simulation Sämtliche Zustandsänderungen des Systems werden durch einzelne Ereignisse oder eintretende Aktivitäten ausgelöst – die Zustände des Systems bilden eine diskrete Menge. Die Ereignisse können zu Zeitpunkten einer diskreten oder kontinuierlichen Zeitvariablen stattfinden. Eigenschaften der kontinuierlichen Simulation In diesen Systemen sind Zustandsvariablen stetig. Zur Darstellung der dynamischen Abhängigkeit zwischen den Systemvariablen werden Differentialgleichungen (auch höherer Ordnung) verwendet. Michael Heß Alle Angaben ohne Gewähr 7 / 24
SWiInf WIP – Simulation Sommersemester 2005 Modellierung Unter Modellierung versteht man die Umsetzung des erdachten oder real existierenden Systems in ein experimentierfähiges System. Ziel ist die Komplexitätsreduktion durch Abstraktion und Idealisierung von der Realität. Modellbildung lässt sich in mehrere Schritte zerlegen: • Prinzipielles Problemverständnis • Konzeptuelles Modell • Umsetzung in ein Softwaremodell • Implementierung Besonders wichtig ist die Validität des Modells, d.h. die wirklichkeitsgetreue Abbildung der Realität. Die relevanten Kriterien müssen vollständig und richtig im Modell enthalten sein. Stufen der Modellvalidierung Zunächst wird das konzeptuelle Modell validiert, anschließend findet die Modellverifikation statt, d.h. dass ein gegebenes System die ihm zugedachten Eigenschaften erfüllt. Abschließend erfolgt die operationale Modellvalidierung, bestehend aus: • Plausibilitätstests • Sensitivitätsanalyse • Kalibrierung • Outputvergleich • Prognostische und dynamische Gültigkeitsprüfung (ex post) Michael Heß Alle Angaben ohne Gewähr 8 / 24
SWiInf WIP – Simulation Sommersemester 2005 Framework zur Modellierung und Simulation nach Zeigler Real System: Behaviour Das Real System ist der Teil der Realität, der auch der Untersuchungsgegenstand ist. Dabei kann es sich um ein natürliches oder künstliches System handeln, welches derzeitig existiert oder für die Zukunft geplant ist. Das Real System ist die Quelle beobachtbarer Daten. Model: Instructions for generating Data Das Modell beinhaltet die Vorschriften, wie die Daten generiert werden, die das Verhalten des untersuchten Modells darstellen. Hierbei kann es sich um Differentialgleichungen oder andere Formalismen handeln. Experimental frame: Validity Der experimentelle Rahmen (Experimentierrahmen) legt die Einschränkungen fest, unter denen das Real System beobachtet wird oder Experimente durchgeführt werden ? Umweltbedingungen. Jedes Modell ist nur genau dann gültig, wenn die angenommenen Bedingungen, also der experimentelle Rahmen, unter denen das Modell aufgestellt wurde, gültig (validiert) sind. Base model: Hypothetical complete explanation Das Gesamtmodell ist eine Abbildung, die alle Input-Output-Abhängigkeiten des Real Systems umfasst. Dieses Gesamtmodell wird in der Praxis nie vollständig bekannt sein, da es aus einer riesigen Anzahl von Komponenten und Wechselwirkungen bestehen, was eine extrem große Komplexität bedeuten würde. Lumped model: Simplification Wenn der experimentelle Rahmen für eine bestimmte Aufgabenstellung festgelegt ist, gelingt es dem Modellierer meist, ein relativ simples Model zu konstruieren, das Michael Heß Alle Angaben ohne Gewähr 9 / 24
SWiInf WIP – Simulation Sommersemester 2005 für den gewählten experimentellen Rahmen gültig ist. Dabei werden Komponenten weggelassen, sowie Wechselwirkungen vereinfacht. ? Abstraktion / Reduktion des Modells auf die wesentlichen Eigenschaften Computer: Complexity Der Computer ist das Werkzeug, mit dem die Input-Output-Paare des Lumped Models generiert werden. Gelegentlich ist es auch möglich das Modell analytisch zu lösen – mit Bleistift und Papier. Meistens ist es aber notwendig dies Schritt für Schritt vorzunehmen, von einem simulierten Zeitpunkt zum nächsten. Diskrete Simulation Grundlage der diskreten Simulation ist der E-A-S Ansatz von Harry Markowitz. Dieser beschreibt den Zustand eines Systems anhand von: • Entities • Attributes (den Entities zugeordnet) • Sets (Mengen, Warteschlangen) Elemente zeitdiskreter Simulationsmodelle Konzeptuelle Sichtweisen (Weltbilder, Modellierungsstile) • Ereignisorientiert • Aktivitätsorientiert • Prozessorientiert • Transaktionsorientiert Beziehungen zwischen Zustand und Zeit Zusammenhänge zwischen (statischer) Struktur und (dynamischem) Verhalten. Attributarten: • Indikative Attribute ? beschreiben Eigenschaften von Objekten • Relationale Attribute ? setzen Objekte zueinander in Beziehung Indexattribute: • Zeit / Zeitbasis ? spezielles Attribut zur Abbildung dynamischen Verhaltens • Raum ? spezielles Attribut zur Abbildung der räumlichen Dynamik Herstellung der Beziehung zwischen Zustand und Zeit durch •Ereignis (event) o exogen ? der Ereignispunkt ist von der Systemumgebung vorgegeben, d.h. es besteht keine interne Abhängigkeit o endogen ? das Ereignis ist die Folge einer Zustandsveränderung, der Ereigniszeitpunkt ist determiniert oder wird stochastisch ermittelt Michael Heß Alle Angaben ohne Gewähr 10 / 24
SWiInf WIP – Simulation Sommersemester 2005 •Aktivität (activity) Eine Aktivität Zustandsveränderung des Systems wird dem Endzeitpunkt des Zeitintervalls zugeordnet. •Prozess (process) Ein Prozess besteht aus einer Folge von Aktivitäten, die auf ein bestimmtes Objekt bezogen sind und innerhalb einer Zeitspanne ablaufen. Zusammenhang von Ereignis, Aktivität und Prozess besteht aus einer Menge von Operationen und die Konzepte der zeitdiskreten Simulation Ereignisorientierte Sicht (event scheduling) Hier findet die Beschreibung von Ereignissen in Form von Ereignisroutinen statt. Dies erlaubt eine klare Trennung von Struktur und Verhalten des Simulationssystems. Man unterscheidet statische und dynamische Komponenten. Ereignisroutinen bestimmen das Verhalten des Modells durch Änderungen der Attributwerte von Objekten, Generierung oder Löschung temporärer Objekte und Hinzufügung neuer, geplanter Ereignisse oder deren Streichung aus der Objektliste. Aktivitätsorientierte Sicht Vorgänge im System werden durch Aktivitäten dargestellt. Jede Aktivität verfügt über einen Anfangs- und einen Endzeitpunkt, der durch Bedingungen beschrieben wird. Aufgabe des Modellierers ist es daher einerseits die Aktivitäten zu identifizieren, die von den Entities im System verursacht werden, andererseits die Bestimmung der Bedingungen zur Kennzeichnung von Anfang und Ende der Aktivitäten. Jede Veränderung der Simulationszeit führt dazu, dass alle Bedingungen überprüft werden, um ggf. Zustandsveränderungen hervorzurufen. Jede erfüllte Bedingung bewirkt Anfang oder Ende einer Aktivität. Problematisch ist hier der hohe Rechenaufwand. Prozessorientierte Sicht In der prozessorientierten Sicht werden die auf ein Objekt bezogenen Aktivitäten zu einem Prozess zusammengefasst. wirklichkeitsgetreue Abbildung der aktiven Systemkomponente. Ein Prozess kann während seiner aktiven Phase: • Objektattribute modifizieren • neue Prozesse generieren Dadurch ergibt passiven sich eine Phasen relativ einer und Michael Heß Alle Angaben ohne Gewähr 11 / 24
SWiInf WIP – Simulation Sommersemester 2005 • die Aktivierung anderer Prozesse zu bestimmten Zeitpunkten planen oder geplante Aktivierungen verschieben oder löschen • sich selbst deaktivieren, wobei die Kontrolle an einen anderen Prozess übergeht • Prozesse beenden Die Ablaufkontrolle sorgt für die Einhaltung der Reihenfolge und der Zeitabstände. Transaktionsorientierte Sicht (transaction flow) Hierbei handelt es sich um Blockdiagrammtechnik zur Beschreibung des Systemverhaltens. Wesentliche Elemente sind Transaktionen, die auf ihrem Weg durch die einzelnen Blöcke verändert werden, und Blöcke mit fest vorgeschriebenen Eigenschaften, die permanent vorhanden sind. Diese Blöcke bilden die statischen Systemkomponenten. Hierunter fallen beispielsweise: • Bedienstationen (facilities) • Speicher (storages) • Leitstellen (logic switches) Die Steuerungen der Transaktionen erfolgt gemäß ihrer Abhängigkeiten. Komponenten ereignisorientierter Simulationssysteme • Zustandsvariablen • Simulationsuhr • Ereignisliste • Statistische Zähler • Initialisierungsroutine • Ereignisroutine • Ergebnisroutine (Reportgenerator) • Steuerprogramm • Aktionen innerhalb der Ereignisroutine o Aktualisierung des Systemzustandes o Sammeln von Informationen o Aktualisierung der statistischen Zähler o Erzeugen neuer Ereignisse ? Festsetzung ihres Ereigniszeitpunktes und Eintragen in die Ereignisliste ? evtl. Löschen von Ereignisses aus der Ereignisliste Prinzipielles Ablaufschema einer ereignisorientierten Simulation Michael Heß Alle Angaben ohne Gewähr 12 / 24
SWiInf WIP – Simulation Sommersemester 2005 Typische Modellklassen Warteschlangensysteme (queuing systems) Zielkriterien sind: • minimale Anzahl von Bedienstationen • minimale Wartezeiten • maximale Auslastung der Bedienstationen ACHTUNG: Diese Ziele sind häufig konfliktär! Einführung in Warteschlagenmodelle Warteschlangenmodelle sind spezielle stochastische Systeme, die als Modellklasse zur Analyse von Leistungsaspekten von Systemen geeignet sind. Typischerweise werden Warteschlangen als Ein-Station-Wartemodell betrachtet. Dieses besteht aus einer Warteraum (Warteschlange, Queue) und Bedieneinheit (Prozessor, Server). (Single-Server-Model) Michael Heß Alle Angaben ohne Gewähr 13 / 24
SWiInf WIP – Simulation Sommersemester 2005 Klassifikation von einfachen Wartesystemen Klassifikation nach der Kendall-Notation: A/B/c/K/m/Z •A: Verteilung der Zwischenankunftszeiten •B: Verteilung der Bedienzeiten •c: Anzahl der Bedieneinheiten •K: Kapazität des Warteraums (inklusive der in Bedienung befindlichen Kunden) •m: Auftragsanzahl in der Quelle •Z: Warteschlangenstrategie (Bedienstrategie) Oft ausreichende Kurzform: A/B/c ? Annahme, dass der Warteraum unbegrenzt ist (K = ∞) und als Warteschlangenstrategie das FIFO-Prinzip angewandt wird (Z = FIFO). Die weitere Betrachtung allgemeiner Warteschlangenmodelle, sowie von Little’s Law entfällt an dieser Stelle. Phasen einer Simulationsstudie Phase 0: Problemstellung, Problemanalyse, Kostenanalyse Lässt sich das Problem mit Simulation lösen? Wichtig zur Beantwortung dieser Frage sind die folgenden Aspekte: Das Simulationskosten und den daraus resultierenden Erkenntnissen. Lässt sich das Problem mittels mathematisch-analytischen Modellen lösen? Kann die Komplexität des Problems adäquat von der Simulation wiedergegeben werden? Die Qualität der Input-Daten ist ausschlaggebend für die Qualität der Output-Daten, d.h. erfüllt die zugrunde liegende Datenbasis die an sie gestellten Anforderungen. Außerdem ist der Wiederverwendungsgrad der Simulation zu beachten. Ob man die Simulation intern oder extern durchführen lässt, hängt vor allem vom im Unternehmen vorhandenen Know-How und den technischen und personellen Kosten-Nutzen-Verhältnis zwischen Michael Heß Alle Angaben ohne Gewähr 14 / 24
SWiInf WIP – Simulation Sommersemester 2005 Kapazitäten ab. Auch der Kostenaspekt sollte hier berücksichtigt werden. Außerdem sollte geprüft werden, ob eine bereits bestehende Simulationsumgebung weitergeführt werden kann. Hier sind entsprechende Abwandlungen des alten Systems einzukalkulieren. Phase 1: Problemformulierung Sowohl der Kunde als auch der Simulationsexperte beschreiben das Problem aus der eigenen Sicht. Anschließend wird dann ein gemeinsames Problemverständnis erarbeitet. Unter Umständen ist eine Neuformulierung des Problems bei fortschreitender Simulationsstudie notwendig. Phase 2: Ziele setzen, Gesamtplan erstellen Hier werden das Gesamtziel und die Teilziele der Studie sowie ihre Interdependenzen erarbeitet. Des Kostenaufwand und die für einzelne Phasen benötigte Zeit kalkuliert. Außerdem werden die erwarteten Resultate nach den einzelnen Phasen festgelegt. Phase 3: Modellbildung Man erstellt ein konzeptuelles Modell, arbeitet die Besonderheiten des Problems heraus und trifft Annahmen. Die Modellierung erfolgt Top-Down, hierbei wird der Kunde mit einbezogen um die Qualität zu verbessern und Vertrauen zu generieren. Phase 4: Datensammlung Zeitgleich mit der Modellbildung findet die Datensammlung statt. Dazu müssen die benötigten Daten identifiziert und auf Korrektheit und Vollständigkeit überprüft werden. Im Idealfall liegen diese Daten bereits vor und müssen nicht erst noch erhoben werden. Wichtig sind frühzeitige Datensammlung und das Vorliegen der Daten in der richtigen Verteilungsfunktion. Generierung von „guten“ Input-Daten in 4 Schritten: 1. Daten aus dem Realsystem sammeln 2. Wahrscheinlichkeitsverteilung zur identifizieren 3. Parameter für Verteilung festlegen 4. Gewählte Verteilung mittels Anpassungstest beurteilen Phase 5: Modellcodierung Man überführt (programmiert) das konzeptuelle Modell auf den Computer. Hierbei muss man sich zwischen einer Simulationssprache und einem Simulationstool entscheiden. Die Simulationssprache ist in der Regel mächtiger, das Simulationstool dafür aber leichter und schneller zu verwenden, was sich in einer kürzeren Entwicklungszeit niederschlägt. Phase 6: Modell verifizieren Das System „richtig“ modellieren: 1. Überprüfung der „Programmierung“ durch andere Person 2. Nachvollziehen der auftretenden Ereignisse an Ablaufdiagramm 3. Modelloutputs nachvollziehbar und vernünftig? 4. Input-Parameter nach jedem Lauf vom System ausgeben 5. Gute Dokumentation von Variablen und entwickelten Modulen 6. Grobe Systemüberprüfung durch Animation Weiteren werden Personalaufwand, Repräsentation des Input-Prozesses Michael Heß Alle Angaben ohne Gewähr 15 / 24
SWiInf WIP – Simulation Sommersemester 2005 7. Debugging Phase 7: Modell validieren • Prüfung und Sicherstellung von hinreichender Übereinstimmung von Modell und Realität • Vermutlich schwerste und wichtigste Phase der Simulationsstudie • Toleranzbereich abstimmen: „So grob wie möglich und so genau wie nötig“ • Iterativer Prozess in verschiedenen Phasen der Modellbildung • Überprüfung der Input-Daten • Vergleich der Output-Daten mit Realsystemdaten oder • Plausibilitätsprüfung der Output-Daten durch Systemexperten • Eignung von Startzustand und Laufwiederholungen überprüfen • Interpretation der „reduzierten“ Modellwelt Phase 8: Entwurf des Experimentierrahmens Hier werden zentrale Modellparameter, wie Simulationslaufzeit, Aufwärmphase, Anzahl der Laufwiederholungen und Startzustand, festgelegt. Weiter wird festgelegt, ob die Modellparameter im Verlauf der Simulation geplant oder auf Grundlager aus der Simulation gewonnener Erkenntnisse variiert werden. Phase 9: Produktionsläufe und Analyse Durchführung der Simulation zur konkreten Leistungsmessung. Die Analyse der Output-Daten kann mit Hilfe von Tools erfolgen. Phase 10: Weitere Simulationsläufe ? In weiteren Simulationsläufen kann man die Auswirkungen von unterschiedlichen Systemen / Modellen miteinander vergleichen, bevor diese real existieren. Hierin liegt die Stärke der Simulationen. Werden weitere Simulationsläufe durchgeführt, dann werden die Phasen 8 und 9 erneut durchlaufen. Ermöglicht wird dies durch Variation des Experimentierrahmens. Zu beachten ist, dass statistische Methoden richtig angewandt werden müssen und die Anzahl der Simulationsläufe ausreichend hoch sein muss, damit statistische Ausreißer nicht das Ergebnis verfälschen! Phase 11: Programmdokumentation und Ergebnisbericht In dieser Phase werden das Programm und der Fortschritt der Simulation dokumentiert. Außerdem erfolgt eine möglichst prägnante Beschreibung der Ergebnisse der Studie. Dies dient der Nachvollziehbarkeit des Simulationsmodells durch Außenstehende zu einem späteren Zeitpunkt (ex post Betrachtung). Dies ermöglicht dem Kunden eine spätere Betrachtung / Bewertung der einzelnen Modellvarianten. Abschließend wird eine Empfehlung des Simulationsspezialisten angefügt. Phase 12: Ergebnisumsetzung Die Ergebnisumsetzung ist das eigentliche Ziel der Simulationsstudie. Der Erfolg der Studie ist abhängig von allen vorhergehenden Phasen, insbesondere aber von der Integration des Kunden und der Validierung (Phase 7). Der Einsatz des Simulationsexperten erscheint sinnvoll bei der Umsetzung der Erkenntnisse und im Rahmen der Wartung, sowie zur Klärung von evtl. auftretenden Fragen / Problemen. Michael Heß Alle Angaben ohne Gewähr 16 / 24
SWiInf WIP – Simulation Sommersemester 2005 Die 7 Todsünden der Simulation (1) Falsche Definition des Studienziels Modellierung und Simulation sollten nie zum Selbstzweck oder als reine Daseinsberechtigung betrieben werden. Ausgangspunkt sollte immer ein reales Problem sein. Simulation darf hierbei nicht als Optimierung verstanden werden. Simulation optimiert keine Problemstellungen, Optimierungsansätze auf. (2) Ungenügende Partizipation des Auftraggebers Eine enge Zusammenarbeit von Auftraggeber Grundvoraussetzung für eine gute Studie. Verdeckte, vorgefertigte Ziele der Auftraggeber können die Simulationsstudie sabotieren, teilweise sogar zum Scheitern führen, da sie ihre eigenen Ziele durch die Studie bestätigt haben wollen. (3) Unausgewogene Mischung von Kernkompetenzen Große Komplexität realer Systeme erfordert umfassendes Know-how in den Bereichen des Fachpersonals, der Programmierung und EDV und der statistischen Auswertung der Ergebnisse. Defizite im Management des Simulationsprojektes können auch bei sonst ausgezeichneten Kenntnissen große Schwierigkeiten bei der Durchführung bereiten. (4) Ungeeigneter Modellierungsgrad „Small models, small troubles“ Je größer das Projekt, desto größer der Aufwand und die Probleme. Probleme wachsen mit der Komplexität des Projektes überproportional an. Daher gilt der Grundsatz: „Nicht so gut wie möglich, sondern nur so gut wie nötig“ zu modellieren und dementsprechend den Detaillierungsgrad wählen. (5) Wahl des falschen Modellierungswerkzeuges Die Welt der Modellierungswerkzeuge ist aufgrund der großen Anzahl verfügbarer Produkte nur schwer überschaubar. Bei der Wahl eines Produktes sollte auf die angemessene Ausstattung des Produktes und auf die Kosten-Nutzen-Relation hinsichtlich Einsatzhäufigkeit und Schulungskosten geachtet werden. (6) Unzureichende Validierung Neben direkten Versäumnissen bei der Datenerfassung zum realen System und Modellierung können die folgenden Fehler auftreten: •Fehler 1. Art: Simulationsresultate werden als ungültig oder falsch abgelehnt, obwohl sie in Wahrheit durchaus richtig sind. Mögliche Ursachen hierfür sind schlechte Ergebnisaufbereitung und / oder -präsentation •Fehler 2. Art: Simulationsresultate werden akzeptiert obwohl sie eigentlich ungenügend fundiert oder auch falsch sind. Mögliche Ursachen sind häufig fehlerhafte Modelle oder Wunschdenken bei der Auswertung •Fehler 3. Art: Die Problemlösung durch die Simulation ist irrelevant, es wurden Antworten auf gar nicht interessierende Fragen gegeben (7) Klägliche Präsentation Letztendlich kann auch eine noch so gute Simulationsstudie an der abschließenden Ergebnispräsentation scheitern. Zu berücksichtigen sind vor allem die zum Teil völlig unterschiedlichen Begriffswelten von Management und Praktikern. Auch bei der sie zeigt nur mögliche und Auftragnehmer ist Modellierung und Simulation, der Michael Heß Alle Angaben ohne Gewähr 17 / 24
SWiInf WIP – Simulation Sommersemester 2005 Auswahl Ergebnisdokumentation sehr genau betrachtet werden. Simulationssprachen Programmiersprachen vs. Simulationssprachen In den 50er/60er Jahren fand der erste Einsatz von Computern zur Lösung von Simulationsproblemen statt. Seitdem werden Computer, Simulationssysteme und Simulationssprachen stetig weiterentwickelt. Die Verwendung von Computern zur Simulation hat folgende Vorteile: • Schnellere Berechnung der Ergebnisse • Modellentwicklung von großen und komplexen Simulationssystemen • Bessere Darstellungsmöglichkeiten der Simulation durch Animation • Statistische Auswertung der Simulationsergebnisse Simulationssprachen verfügen über viele Vorteile gegenüber konventionellen Programmiersprachen: • Bessere und einfachere Entwicklung Bereitstellung von entsprechenden Tools und Funktionen • Bessere Auswertung von Simulationsergebnissen durch entsprechende Tools. • Steuerung des Simulationslaufes durch das System selbst Es existieren verschiedene Ausprägungen von Simulationssprachen: • Ergänzungen von Programmiersprachen um entsprechende Funktionen und Klassen zur Simulation, z.B. SIMULA (Klasse SIMSET / DEMOS) oder GPSS- Fortran • Reine Simulationssprachen, teilweise Programmiersprachen, z.B. SIMAN, SLAM, GPSS • Komplexe Simulationssysteme mit Animation, z.B. SIMAN / CINEMA, AUTOMOD II oder verschiedene Robotersimulatoren Einteilung von Simulationssprachen Die Simulationssprachen lassen sich traditionell folgendermaßen einteilen: • Kontinuierliche Simulationssprachen • Diskrete Simulationssprachen o Ereignisorientierte Sprachen o Aktivitätsorientierte Sprachen (Activity-Scanning Sprachen) o Prozessorientierte Sprachen o Transaktionsorientierte Sprachen (Transaction-Flow Sprachen) Die meisten aktuellen Simulationssprachen und -systeme erlauben sowohl diskrete als auch kontinuierliche Sichten zu verbinden. Ereignisorientierte Sprachen Veränderungen im System werden durch Ereignisse ausgelöst, der Simulationslauf ist eine Folge von Ereignissen. Aufgabe des Modell-Entwicklers sind die Bestimmung der Ereignisse und die Entwicklung der mit den Ereignissen verbundenen Logik. Die Simulation ist die Ausführung dieser Logik in zeitlicher Reihenfolge. des Simulationswerkzeuges sollte die Komponente zur von Simulationsmodellen durch mit Schnittstellen zu anderen Michael Heß Alle Angaben ohne Gewähr 18 / 24
SWiInf WIP – Simulation Sommersemester 2005 Vertreter des ereignisorientierten Ansatzes: • SIMSCRIPT • GASP (General Activity Simulation Program) • SIMCOM (Simulation Compiler) • SIMPAS (auf PASCAL basierend) Activity-Scanning Sprachen (Aktivitätsorientierte Sprachen) Vorgänge im System werden durch Aktivitäten dargestellt. Jede Aktivität verfügt über einen Anfangs- und einen Endzeitpunkt, der durch Bedingungen beschrieben wird. Aufgabe des Modellierers ist es daher einerseits die Aktivitäten zu identifizieren, die von den Entities im System verursacht werden, andererseits die Bestimmung der Bedingungen zur Kennzeichnung von Anfang und Ende der Aktivitäten. Jede Veränderung der Simulationszeit führt dazu, dass alle Bedingungen überprüft werden, um ggf. Zustandsveränderungen hervorzurufen. Jede erfüllte Bedingung bewirkt Anfang oder Ende einer Aktivität. Problematisch ist hier der hohe Rechenaufwand. Vertreter des Activity-Scanning-Ansatzes: • HOCUS • CSL (Control and Simulation Language • ESP (Elliot Simulator Package) • GSP (General Simulation Program) • FORSIM-IV • MILITRAN Prozessorientierte Sprachen Prozessorientierte Sprachen versuchen aktivitätsorientierten Ansatz zu verbinden. Die Abbildung des Systemverhaltens erfolgt durch Prozesse, d.h. durch wiederkehrende Folgen von Ereignissen. In den Prozessen werden alle, aus der Sicht des Entwicklers zusammengehörenden, Ereignisse zu einem Modul zusammengefasst. Vertreter des prozessorientierten Ansatzes: • SIMSCRIPT II.5 • SIMULA (Simulation Language) • SIMPL/1 (Simulation Language based on PL/1) • SOL (Simulation Oriented Language) • INS (Integrated Network Simulator) • ASPOL (ASimulation Prozess-Oriented Language) Transaction-Flow Sprachen (Transaktionsorientierte Sprachen) Hierbei handelt es sich um eine spezielle Form des prozessorientierten Ansatzes. Kern des Ansatzes sind dynamische Transactions, d.h. dynamische Entities, die ein Lebenszyklusszenario repräsentieren: • sie werden erzeugt (stochastisch oder deterministisch) • sie fließen durch das System • sie werden aufgehalten oder umgeleitet • sie fordern Ressourcen an und geben diese frei • sie werden am Ende ihres Lebenszyklus gelöscht den ereignisorientierten mit dem Michael Heß Alle Angaben ohne Gewähr 19 / 24
SWiInf WIP – Simulation Sommersemester 2005 Jede Transaction ist eine Prozess-Instanz, die statische Struktur des Systems wird durch passive Objekte wie Ressourcen oder Speicher beschrieben. Transactions durchlaufen Blöcke. Vertreter des Transaction-Flow-Ansatzes: • GPSS (General Purpose Simulation System) • SIMAN (Simulation Analysis Program) • SLAM (Simulation Language for Alternative Modeling) • GEMS (Generalized Manunfacturing Simulator) • BOSS (Burroughs Operational System Simualtor) Zukünftige Entwicklungen • High Fidelity Simulation • Datenaustauschformate • Komponenten- / Objektbibliotheken • Eingebettet Simulation • Optimierung • Internet • Verteilte Simulation Meilensteine der Simulationstechnik Fortschritte im letzten Jahrzehnt Für die Mehrheit der Simulationssysteme wurden PC-Versionen entwickelt, wodurch grafische Benutzeroberflächen zur Modellierung und Modellnutzung bereitgestellt werden. Außerdem existieren Interfaces zu vorhandenen Datenbanken, PPS- und BDE-Systemen. Auch lassen sich die Ergebnispräsentationen in 2D- und 3D-Grafik erstellen. Zusätzlich haben sich neue Anwendungslösungen und Anwendungsmöglichkeiten entwickelt, beispielsweise Reengineering, Modellierung von Geschäftsprozessen und der Einsatz im Dienstleistungsbereich. Hinzugekommen ist auch die Möglichkeit, Michael Heß Alle Angaben ohne Gewähr 20 / 24
SWiInf WIP – Simulation Sommersemester 2005 Zeugenaussagen im Rahmen von Unfallsituationen und Leistungen von Mitarbeitern beim Einsatz komplexer technischer Systeme zu überprüfen. Mängel und Defizite Simulationsanwendungen sind oft rechner- und betriebssystemabhängig, was sich auch in mangelnder Wiederverwendbarkeit der Simulationsanwendung niederschlägt (? Einzwecklösungen). Hinzu kommt die Problematik der Echtzeitdatenaustausch in heterogenen Simulationssystemen. Diese ist nur in den wenigsten Fällen vorhanden. Kritisch zu betrachten ist auch die „Do-it-yourself-Welle“, die aufgrund der einfachen Verwendung von Simulationstools aufgetreten ist. Außerdem besteht die Gefahr der naiv oder vorsätzlich missbräuchlichen Verwendung, was die Simulationstechnik in Verruf gebracht hat. Des Weiteren dient sie häufig als sog. High-Tech- Rechtfertigungsinstrument für Fehlentscheidungen. Parallele und verteilte Simulation Wie in allen Bereichen führt auch in der Simulation die Globalisierung zu neuen Anforderungen. So entstehen in der Produktion komplexere Produktionsnetzwerke, aufgrund verschiedener Modellvarianten bedarf es einer flexibleren Anpassung des Simulationsmodells und einer Änderung der Simulationsziele. Anpassungsbedarf besteht auch vermehrt durch kürzere Produktlebenszyklen, unterschiedliche Produktausprägungen (Kundenorientierung) und neue Technologien. Simulationsläufe komplexer Systeme benötigen viel Rechenzeit und sind hinsichtlich Anzahl und Umfang der Läufe begrenzt. Als Lösungsmöglichkeiten kommt in Betracht: • Verteilte Simulation • Wiederverwendbarkeit von Simulationsmodellen • Interoperabilität zwischen Simulationsmodellen • Synchronisation ? High Level Architecture for Modelling and Simulation (HLA) High Level Architecture (HLA) HLA ist eine Architektur für verteilte Simulation, die Interoperabilität und Wiederverwendung von verschiedenen Programmarten unterstützt. Es muss sich dabei nicht zwingend um Simulationen handeln. Motivation Monolithische (untrennbare Einheit) Simulationen können nicht den gesamten Anforderungen aller Nutzer entsprechen. Eine vollständige Antizipation aller Simulationsnutzungen und aller Kombinationen mit anderen Systemen ist nicht möglich! Prinzipien der HLA • Interoperabilität ? Datenaustausch und Interpretation • Wiederverwendbarkeit ? Definition und Dokumentation von Schnittstellen und Objekten Michael Heß Alle Angaben ohne Gewähr 21 / 24
SWiInf WIP – Simulation Sommersemester 2005 • Föderationen von Simulationen ? Unterschiedliche Simulationen (Federates) formen eine Föderation (Federation) • Trennung von Basisdiensten und Simulationsfunktionalität ? RTI (Runtime Infrastructure) ? Objektsichtweise auf Entitäten Terminologie • Federation ? Menge von zusammenarbeitenden Simulationen • Federate ? Mitglied einer HLA-Federation o als Plattform: Ein Simulator o als Aggregat: Eine Simulation • Federation Execution ? Durchführung einer verteilten Simulation • Object ? Entität in der Domäne o besitzt Attribute o ist von mehr als einem Federate von Interesse Schlüsselkomponenten • HLA Regeln (Rules) ? Definieren die Kooperation der Simulationen anhand • von Regeln für Federates und Federations • HLA Object Model Template (OMT) ? Definiert die Objektsicht auf die Simulationen • HLA Interface Specification ? Definiert das API (Application Programming Interface) • für alle teilnehmenden Simulationen ? Gesamte Kommunikation zwischen den Simulationen findet nur über diese Schnittstelle zur RTI statt Object Model Template (OMT) OMT ist eine Struktur zur Beschreibung der verwendeten Objekte und ihren Interaktionen. Es legt fest, wie die Funktionalität eines Objektes nach außen hin dokumentiert wird. Derzeit besteht es aus den fünf folgenden Komponenten: • Object Class Structure Table • Interaction Class Structure Table • Attribut Table • Parameter Table • FOM/SOM Lexicon HLA Interface Specification Die HLA Interface Specification ist die Definition der Schnittstellendienste zwischen der Runtime Infrastructure (RTI) und den Simulationen. Es existieren sechs Managementbereiche: • Federation Management • Declaration Management • Object Management • Ownership Management • Time Management • Data Distribution Management Michael Heß Alle Angaben ohne Gewähr 22 / 24
SWiInf WIP – Simulation Sommersemester 2005 Funktionale Übersicht über die HLAs Systemintegration Simulation Data Exchange Schnittstelle (SDX) o Verringerung des Modellierungsaufwandes o Unterstützung der Einbindung vorhandener (Anlagen)Modelle ? Vermeidung Modellierung/Einsparungsmöglichkeiten ? Insbesondere Fertigungssystemen Automatisierung (Fließbänder, Führerlosenfahrzeuge etc.) Extensible Markup Language (XML) o restriktive Trennung zwischen Inhalt, Präsentation und Struktur eines Dokuments o Unterstützt die Kompatibilität Verwendungszusammenhängen ? z. B. Datenbanken o ermöglicht: ? Intelligenter kontextueller Recherche ? Mehrfachverwendung von Informationen ? Automatisierte Verarbeitung von Dokumenten XML-Technologien von Redundanzen in der mit hohem Anteil an von Daten in beliebigen Michael Heß Alle Angaben ohne Gewähr 23 / 24
SWiInf WIP – Simulation Sommersemester 2005 Fazit Paradigmen für die Entwicklung von Simulationssoftware 1. Modelle sind so zu entwickeln, dass sie nicht nur für eine konkrete Aufgabenstellung, sondern für viele Benutzer und Aufgaben verwendbar sind. 2. Modelle und ihre Basissoftware sollten so beschaffen sein, dass sie auf das Zusammenwirken mit anderen Modellen oder Komponenten der Realität vorbereitet sind. 3. Simulationssoftware sollte die Möglichkeit vorsehen, alle Arbeitsschritte einer Simulationsanwendung im Rahmen eines Web-Browsers zu unterstützen. Es sollte Schnittstellen zum Anschluss von 2D- und 3D-Visualisierungssoftware im Web vorsehen. Die Statistik-Inhalte der Veranstaltung sind in dieser Zusammenfassung nicht aufgeführt, da dieses bezüglich des Umfanges nicht mehr der Charakteristik einer Zusammenfassung gerecht werden würde. Hier sei auf den entsprechenden Foliensatz und die CDs zur Veranstaltung verwiesen. Michael Heß Alle Angaben ohne Gewähr 24 / 24