Kapitel 3: Simulationssoftware Flashcards
Arten von Simulationssoftware
• Sprachebene
- Allgemeine Programmiersprachen
• Modellebene
- Parametrisierte Modelle
• Werkzeuge
- Simulationssysteme
Potenziale von Animation in der Simulation
- Unterstützung der Modellvalidierung (leichte Fehlererkennung durch visuelle Darstellung)
- Verbesserte Vermittlung der Funktionen und Logik des Simulationsmodells für die Modellanwender
- Anschauliche Präsentation von Simulationszuständen (Visualisierung von Engpsässen)
- Bessere Kommunikationsmöglichkeiten mit Modellanwendern und Entscheidungsträgern
Grenzen von Animation in der Simulation
- Leichte Fehlinterpretationsmöglichkeiten (“Schnellschüsse von Entscheidungsträgern”)
- Vernachlässigung der Zufallsaspekte von Simulationsmodellen
- Oberflächlichere Betrachtung der Modellstruktur (kann nur so genau sein wie die Daten)
Auswahlkriterien für Simulationssoftware
• Fachliche Angemessenheit (Simulationsspezifisch) → welche Simulationsfeatures und Funktionalitäten?
→ Modellierungskonzept (Modellogik diskret/kontinuierlich; Unterstützte Modellierungsstile; Abbildungsgenauigkeit; Anschaulichkeit)
→ Anwendungsdomäne (Fertigung, Materialfluss, Logistik, Warehousing, Hafenbetrieb)
- Technische Anforderungen (Performance, Integrationsfähigkeit mit anderen IT-Systemen, Betriebssystem, Hardwareanforderungen, Dokumentation, Wartung, Support, Updates, Kosten)
- Anbietermerkmale und Kosten (Marktstellung, Zukunftsfähigkeit)
Technische Anforderungen an Simulationssoftware
- Hardware-/Softwareanforderungen (Rechnerplattform, Betriebssystem, Prozessor, Arbeitsspeicher, Bildschirmauflösung; Performance)
- Integration/Schnittstellen (Integration in bestehende IT-Landschaft; Schnittstellen z.B. CAD, ASCII, SQL-Datenbanken,Tabellenkalkulation (z.B. Microsoft Excel))
- Benutzungsschnittstelle (Grafische Unterstützung, GUI)
Erkenntnisgewinnung durch Simulation (Traditionell)
- Computermodell und konzeptuelles Modell getrennt
- Einmal implementiertes Computermodell rückwärts verifiziert um zu überprüfen, ob Computermodell ausreichend mit konzeptuellem übereinstimmt
Erkenntnisgewinnung durch Simulation (IYOPRO)
- Einweg-Beziehung (Computermodell als Erweiterung des konzeptionellen)
- Durch Anreichern hinterlegt
Ressourcen in IYOPRO
- Müssen vor erstmaliger Verwendung definiert werden
- Organisationsdiagramme beschreiben verfügbare Ressourcen und die von ihren angebotenen Rollen
- Im Kollaborationsdiagrammen erfolgt die Festlegung des eventuellen Ressourcen-Bedarfs von Aktivitäten oder ganzen Lanes über die Definition von „Participants“(=benötige „Rollen“)
- Unterscheidung folgender Zustände einer Ressource bzgl. ihrer Verfügbarkeit für eine Rolle:
- „Idle“: Die Ressource ist für Anforderungen verfügbar
- „In use“: Die Ressource wird von einem Prozess, der sie für die benötigte Rolle angefordert hat, produktiv verwendet
- „Other role“: Die Ressource wird von einem Prozess, der sie für eine andere Rolle angefordert hat, verwendet (nur möglich, wenn die Ressource mehrere Rollen einnehmen kann)
- „Waiting“: Die Ressource wurde von einem Prozess angefordert, wird aber noch nicht verwendet, weil der Prozess noch auf andere angeforderte Ressourcen wartet.
- „Post-processing“/„setup“: Vor-bzw. Nachbereitung einer Nutzung
Verhinderung von Deadlocks in IYOPRO
Zuordnung der Ressourcen zu Prozessen kann über Prioritäten kontrolliert werden
IYOPRO Limitationen
- Fehlende Ereignis-basierte Modellierung (Warten ist möglich, aber kein Verschieben oder Löschen)
- Fehlender Zugriff auf und ggf. Anpassung der Simulationsinfrastruktur (Erweiterung der Reports,Austausch der Zufallszahlengeneratoren,Definition eigener stochastischer Verteilungstypen)
- Fehlende Flexibilität einer allgemeinen Programmiersprache (Definition eigener Modellierungskonstrukte,etwa algorithmische Beschreibung komplexeren Ressourcen-Verhaltens wie explizite Manipulation der internen Warteschlangen)
Black-Box-Framework
- Fertige Komponenten, aus denen der Anwender auswählt und neu zusammenstellt
- DESMO-J: Scheduler, Warteschlangen, Datenkollektoren
White-Box-Framework
- Abstrakte Klassen, die durch abzuleitende Klassen oder zu implementierende Interfaces zu ergänzen sind (Hot Spots)
- Detailliertere Kenntnis der Architektur des Frameworks nötig
- DESMO-J: Entitäten, Events, Modell
Framework
- Gibt Architektur einer Anwendung vor
- Sammlung von Softwarekomponenten, die zur Erledigung einer gemeinsamen Aufgabe zusammenarbeiten
→ Jedes Simulationsmodell ist eine spezielle Anpassung des Frameworks
Trennung von Modell und Experiment (DESMO-J)
Hat sachliche Gründe: fachliche Domänenwelt im Modell braucht keine Kenntnis mit den Einstellungen eines spezifischen Experiments
Methoden, die in Ereignisliste enthalten sein sollten
- passivate oder hold geben nach vollständiger Abarbeitung des Lebenszyklusses die Programmkontrolle an den Scheduler zwecks Aktivierung des nächsten Prozesses zurück
- Sicherstellung der vollständigen, ununterbrechbaren (atomaren) Abarbeitung der Methode eventRoutine() einer Ereignisklasse
