SWiInf WIP – Simulation                                                                           ...
This presentation is the property of its rightful owner.
Sponsored Links
1 / 24

Zusammenfassung Simulation PowerPoint PPT Presentation


Simulationsanwendungen sind sehr beliebt und modern.

Download Presentation

Zusammenfassung Simulation

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Zusammenfassung simulation 7425101

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


Zusammenfassung simulation 7425101

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


Zusammenfassung simulation 7425101

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


Zusammenfassung simulation 7425101

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


Zusammenfassung simulation 7425101

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


Zusammenfassung simulation 7425101

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


Zusammenfassung simulation 7425101

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


Zusammenfassung simulation 7425101

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


Zusammenfassung simulation 7425101

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


Zusammenfassung simulation 7425101

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


Zusammenfassung simulation 7425101

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


Zusammenfassung simulation 7425101

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


Zusammenfassung simulation 7425101

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


Zusammenfassung simulation 7425101

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


Zusammenfassung simulation 7425101

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


Zusammenfassung simulation 7425101

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


Zusammenfassung simulation 7425101

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


Zusammenfassung simulation 7425101

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


Zusammenfassung simulation 7425101

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


Zusammenfassung simulation 7425101

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


Zusammenfassung simulation 7425101

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


Zusammenfassung simulation 7425101

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


Zusammenfassung simulation 7425101

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


Zusammenfassung simulation 7425101

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


  • Login