Techniken für die Simulation zeitdiskreter Systeme

deposit_hagen

Publikationsserver der

Mathematik und

Informatik

Informatik-Berichte 78 – 03/1988

Dietmar Nentwig

Techniken für die Simulation

zeitdiskreter Systeme

Dietmar Nentwig

Fernuniversität Hagen, 1987 Lehrgebiet Technische Informatik

TECHNIKEN FUR DIE SIMULATION

ZEITDISKRETER

SrsTEME

Abstract:

In dieser Arbeit werden grundlegende Techniken, Prinzipien und Denkweisen vorgestellt, die bei der Simulation zeitdiskreter Systeme relevant sind. Es wird dabei getrennt zwischen einer Simulatorspezi-

fikation, für die verschiedene konzeptionelle Ansät- ze sowie Hilfsmittel zur Verfügung stehen, und einer Simulatorrealisierung. Als Aspekte der Realisierung werden Implementierungsmöglichkeiten, Methoden des Designs von Simulationsexperimenten einschließlich ihrer Lastcharakterisierung, Techniken der Modellka- 1 ibierung und -va 1 idierung sowie verschiedene Ver- fahren zur Auswertung und Analyse von Simulationser-

I n h a 1 t s v e r z e i c h n i s

1. Einleitung

2. Begriffserklärungen 2.1. Der Systembegriff 2.2. Der Prozeßbegriff 2.3. Der Modellbegriff

3. Spezifikation eines Simulators 3.1. Der Simulationsbegriff 3.2. Probleme der Modellierung

3.2.1. Die Systemanalyse 3.2.2. Die Modellsynthese 3.3. Auswahl der Modellstruktur

3,3,1, Monte-Carlo-Methoden 3,3.2. Period Modelling

3.3.3, Ereignisorientierter Ansatz 3,3.4. Aktivitätsorientierter Ansatz 3.3.5, Prozeßorientierter Ansatz 3.3.6. Netzwerk-Ansatz

4. Realisierung eines Simulators

4.1. Unterstützung durch spezielle Simulationssprachen 4.2. Design der Experimente

4.2.1. Konzeptionelle Methoden 4.2.2. Definition der Last

4.3. Modellierung von Zufallsvariablen 4.3.1. Hypothesenbildung

4.3.2. Parameterschätzungen 4,3.3. Anpassungstests

4.4. Gleichverteilte Zufallszahlen

4.4.1. Möglichkeiten der Generierung 4.4.2. Testmethoden

4.5. Zufallszahlengenerierung bestimmter Verteilungen 4.5.1. Allgemeine Ansätze

4.5~2. Zufallszahlen stetiger Verteilungen 4.5.3. Zufallszahlen diskreter Verteilungen 4.6. Modellanalyse: Outputauswertung

4.6.1. Probleme und Begriffe 4.6.2. Konfidenzintervalle

4.6.3. Terminierende Simulation 4.6.4. Stationäre Simulation

4.7. Modellverifikation: Kalibrierung und Validierung 4.7.1. Probleme und Begriffe

4.7.2. Drei-Phasen-Ansatz 4.7.3. Vergleichstests

4.7.4. Methoden zur Reduzierung der Varianz 5. Kritische Sichtung

6. Literatur

B e z e i c h n u n g e n und Symbo1e

t X,Y,Z y

fy(t) F y ( t )

y

~=(y1,Y2,•••,Yn)

Prob µ

E[Y]

Var[Y) Cov[X,Y]

n

reelle Zahl

Zufallsvariablen

Realisierung (Wert) der Zufallsvariablen y

Dichtefunktion der Zufallsvariablen Y Verteilungsfunktion der Zufallsvariablen

y

Umkehrfunktion von Fy(t)

vektorwertige Zufallsvariable

n-dimensionale Stichprobe, bestehend aus n voneinander unabhängigen Beobachtungen einer Zufallsvariablen Y

Wahrscheinlichkeit Erwartungswert Varianz

Erwartungswert der Zufallsvariablen Y Varianz der Zufallsvariablen Y

Kovarianz der Zufallsvariablen X,Y Stichprobenerwartungswert

Stichprobenvarianz Verteilungsparameter

Schätzer des Verteilungsparameters 8J

X ² ( l _,..) • ( k -l )

Z1-"'

t ( 1 - 0 < ) • ( n - 1 )

L(a)

U(a)

Ergebnis des Chi-Quadrat-Tests

reelle Zahlt, für die gilt: Der Wert der Chi-Quadrat-Verteilung mit (k-1) Frei- heitsgraden an der Stelle t i:st gleich

( 1-a)

Vergleichswerte bei Kolmogorov-Smirnov- Tests

Wert der N(0,1)-Verteilung, links von dem 100•(1-a)-Prozent der Fläche unter der N(0,1)-Verteilung liegt

Wert der t-Verteilung mit hei tsgraden, von dem links zent der Fläche unter der funktion liegt

(n-1) Frei- 100 ( 1-a )-Pro-

Verteilungs-

gleichverteilte Pseudozufallszahlen Output eines Simulationsexperimentes linke Grenze eines Konfidenzintervalls mit der Signifikanzzahl a

rechte Grenze eines Konfidenzintervalls mit der Signifikanzzahl a

zeitdiskreter stochastischer Prozeß

i • E:i.n.1 e:i. t: u.ng

Das Konzept der Simulation hat sich in der heutigen Zeit zu einem äußerst leistungsfähigen Analyse- und Prognoseinstrument entwickelt, ohne das viele Probleme nicht bzw. nur mit hohem Auf- wand gelöst werden könnten. Dementsprechend vielseitig sind auch die Einsatzbereiche. Beispielsweise wird auf Simulationsmodelle zurückgegriffen bei

• technischen und biologischen Systemen,

• Modellen der Verkehrstheorie, Soziologie, Wirtschafts- wissenschaften,

• der Leistungsbewertung von Rechensystemen,

• dem Vergleich von betriebswirtschaftlichen Planungs- strategien,

• der Modellierung logischer Schaltwerke,

• der Vorausberechnung der Zuverlässigkeit neuer Maschi- nen oder Anlagen.

Rein historisch gesehen wurden Simulationskonzepte entwic- kelt, um Kernwaffen zu testen: Zum einen waren die Probleme einer Kettenreaktion von Atomkernen analytisch nicht lösbar, und zum an- deren waren rein experimentelle Versuche zu gefährlich, so daß ein neues Verfahren entwickelt wurde, die sogenannte Monte-Carlo-Me-

thode (vgl. 3.3.1.).

Nach /TURING 37/ gibt es eine theoretische Grundlage für die Existenz von Simulationsalgorithmen: Er konstruierte eine soge- nannte Universalturingmaschine, mit deren Hilfe man andere Turing- maschinen simulieren kann. Dies geschieht dadurch, daß die Univer- salturingmaschine mit der Kodierung einer anderen Turingmaschine als Anfangszustand des Eingabe/Ausgabe-Bandes belegt wird.

Explizite Beispiele für spezielle Simulationsanwendungen und -modelle werden an dieser Stelle nicht erwähnt, sie sind hinrei- chend in der Literatur (/FRANK,LORENZ 79/, /KRÜGER 75/, /NAY- LOR_et_al 66/) sowie in den Tagungsbänden verschiedener Kongresse zu finden: GI-NTG-Fachtagung Messung, Modellierung und Bewertung von Rechensystemen, European Simulation Congress, Symposium Simu- lationstechnik, ACM/IEEE/SCS Annual Simulation Symposium, SCS Pro- ceedings of the ( ••• ) Summer/Winter Computer Simulation Confe- rence, etc •• Krüger beispielsweise unterscheidet folgende Anwen- dungsgebiete:

• Modelle zur Lösung von Management-Aufgaben,

• Warteschlangenmodelle,

• Modelle zur Ablaufplanung,

• Modelle zur Instandhaltung und Wartung,

• Lagerhaltungsmodelle,

• Investitions- und Finanzierungsmodelle,

• Marketing-Modelle,

• ökonomische Modelle,

• Verhaltensmodelle,

• Modelle von Computer-Systemen,

• Verkehrsmodelle,

• Modelle von Städten und Regionen,

• Planspiele,

• Sonstige Modelle.

Nach /BAUKNECHT_et al 76/ setzt eine Simulationsuntersuchung gleichwertige Kenntnisse auf dem Gebiet der Modellbildung, der statistischen Grundlagen und der Modellimplementation auf einem Computer voraus. Auf diese drei Komponenten wird im folgenden nä- her eingegangen, doch zunächst werden in Kapitel 2. einige zentra- le Begriffe erläutert und eingeführt. Danach werden die für einen Modelldesigner wesent 1 ichen Gesichtspunkte dargeste 11 t: Formul ie-

rung eines Simulations- bzw. Modellentwurfs, Implementierung und Realisierung des Systems, Auswahl der Simulationsexperimente, Ka- librierung und Validierung des Modells sowie Möglichkeiten der Re- sul tatinterpretation. Zuletzt sei noch bemerkt, daß nachfolgend nur diskrete und nicht kontinuierliche bzw. hybride (/GORDON 69/) Systeme behandelt werden. Für Informationen hierüber sei auf /JENTSCH 69/ und /KORN,WAIT 83/ verwiesen. Tauchen in diesem Text die Begriffe Folge, Reihe oder Menge auf, so sind diese nicht in einem streng mathematischen Sinne zu interpretieren.

2 . B e g r i f f s e r k 1 a r u n g e n

Aufgrund der Tatsache, daß - insbesondere auf dem Gebiet der Simulation - in der Literatur oft die gleichen Begriffe mit unter- schiedlichen Bedeutungen belegt und interpretiert werden, ist es wichtig, diese zu erklären. Darüberhinaus benötigt man nach /THIEL 67/ Begriffe als Basis des Verstehens:

Wo zu handeln ist, können Beispiele leicht mit Rezepten verwechselt werden. Begriffe hingegen dienen als Anlei- tung des Zurechtfindens.

Im folgenden werden nun die Begriffe System, Prozeß und Mo- dell näher erläutert und abgegrenzt.

2.1. Der Systembegriff

Der Begriff System wird win verschiedenen Bereichen benutzt, z.B. Computersystem, Betriebssystem, Transportsystem, Wirtschafts- system, Planetensystem, Periodensystem der Elemente, etc •• Eine Gemeinsamkeit zwischen allen diesen Systemen versuchen folgende Definitionen herauszustellen:

Definition 2.1: System

1. Ein System wird festgelegt durch seine

• Ziele, d.h. Zwecke und Aufgaben,

• Elemente nach Anzahl und Eigenschaften und

• Relationen zwischen den Elementen und zur Systemumgebung (/KRÜGER 75/).

2. A system is a collection of related entities, characterized by attributes that may themselves be related (/FISHMAN 73/).

3. Ein System ist eine geordnete (strukturierte) Ganzheit, die durch

• eine gegebene Menge von Elementen mit definierten Eigenschaften sowie durch

• Beziehungen zwischen den Elementen und ihrer Umgebung

festgelegt ist. Formal beschrieben: S

=

[E,R], wo- bei E

=

{e~} die Menge der Elemente und R

=

{e~ x

x ej} die Menge der Relationen der Elemente

onen bestimmt die Struktur des Systems ( /FRANK, LORENZ 79/).

Diesen Systembegriff kann man natürlich weiter differenzie- ren. So wird in /FRANK,LORENZ 79/ zwischen natürlichen und künst- lichen Systemen unterschieden, letztere wiederum unterteilen sie in statisch bzw. dynamisch:

natüJ;,lich

~ A

statisch dynamisch

/\

~

diskret stetig

h ~ A - h

~ etermrnf...stisc

stationär nichtstationär

Abbildung 2.1: Systemklassen

Der Unterschied zwischen natürlichen und künstlichen Systemen ist dabei intuitiv klar. Dynamische Systeme sind durch aktive Ele- mente und sich im Zeitverlauf ändernde Relationen gekennzeichnet, statische Systeme dagegen haben als Charakteristikum eine konstan- te innere Ordnung, das heißt ihre Elemente sowie Relationen ändern sich nicht im Zeitablauf (z.B. Zahlensysteme). Bei den dynamischen Systemen können noch weitere Unterscheidungskriterien aufgeführt werden, nämlich

• diskret - stetig,

• deterministisch - stochastisch,

• stationär - nichtstationär.

Dabei ist das wesentliche Kriterium bei der ersten Unter- scheidung der Zeitablauf: Bei diskreten Systemen wird dieser durch konstante bzw. variable Zeitintervalle realisiert (z.B. Ferti- gungsabläufe, Warteschlangenmodelle), bei kontinuierlichen Syste- men dagegen impliziert ein stetiger Zeitablauf auch stetige Rela- tionen (z.B. kontinuierlicher Strom von Wasser, Gas, Elektrizität, etc.).

Betrachtungsgegenstand · dieser Arbeit sind zei tdis- krete Systeme. Werden sowohl die Zustandsübergänge als auch die Ergebnisse bzw. Ereignisse durch die Eingabedaten eindeutig fest-

gelegt, so spricht man von deterministischen Systemen. Experimente sind dabei - der gleiche Input vorausgesetzt - beliebig oft mit gleichem Resultat wiederholbar. Dieses Systembild ist jedoch nicht sehr realistisch, denn oft wirken zufällige Einflüsse auf ein Sys- tem ein. Dann spricht man von stochastischen Systemen (z.B. Warte- schlangensysteme mit zufälligen Ankunfts- und Bedienraten). Insta- / tionäre Systeme zeichnen sich durch ein übergangsverhal ten / ihrer Elemente bzw.Relationen aus, diese sind also zeitabhängig. Im Ge- gensatz zu stationären Systemen erreichen sie nie einen einge- schwungenen oder Gleichgewichtszustand, in dem sich nichts mehr ändert. Ein weiterer Unterscheidungspunkt ist nach /KRÜGER 75/

• offen - geschlossen,

wobei sich ein offenes System durch sogenannte externe Relationen, d. h. Beziehungen zur Systemumgebung, auszeichnet, die bei einem geschlossenen System fehlen, so daß dort nur Beziehungen zwischen S ys temkomponent en bestehen. Charakte ris t_i_1?~.h- fü_r ß_ynaII1!~c.h_e"_.~_y_~:te- me sind Zustandsvariable und Zustandsraum.

Definition 2.2: Zustandsvariable

Die Variable t charakterisiere den Zeitverlauf.

Zus tandsvariab 1 e zi ( i=l, 2, ••• , n) beschreiben in quantifizierbarer Form die dynamischen Merkmale eines Systems: z1 (t), ••• , Zn(t) stellen Werte zu einem gegebenen Zeitpunkt dar.

Definition 2.3: Zustand

Ein Zustand wird durch ein Zahlen-n-tupel be- schrieben, das einen Punkt im n-dimensionalen Zu- standsraum bestimmt (n ist hier die Anzahl der Zu- standsvariablen). Er ist also zu einem Zeitpunkt t die vorliegende Realisierung der Zustandsvariab- len.

Das Verhalten eines Systems ist somit definiert durch die Menge der möglichen Zustandsfolgen, die im Zeitverlauf erzeugt werden. Der Hauptaspekt der Simulation dynamischer Systeme ist demnach die Beobachtung von Zuständen im Zustandsraum, Diese In- terpretation führt zum Prozeßbegriff,

2.2. Der Prozeßbegriff

Nach /FRANK, LORENZ 79 / ist ein Prozeß eine zeit 1 iche Fa lge von Zustandsübergängen in einem System, /FISHMAN 73/ interpretiert diesen Begriff ähnlich: Ein Prozeß ist eine Menge logisch zusam- menhängender Zustandsübergänge, Analog zum Systembegriff wird auch

zwischen diskreten und stetigen, stationären und nichtstationären sowie deterministischen und stochastischen Prozessen unterschie- den, Üblicherweise kann ein Prozeß vier mögliche Zustände anneh- men:

• AKTIV: Dem Prozeß ist eine Aktivität zugeordnet, die auch ausgeführt wird.

• BLOCKIERT: Dem Prozeß ist zwar eine Aktivität zugeord- net, die jedoch nicht ausgeführt wird.

• PASSIV: Dem Prozeß ist keine Aktivität zugeordnet, zu einem späteren Zeitpunkt jedoch kann er in die Zustände AKTIV bzw. BLOCKIERT wechseln.

• TERMINIERT: Der Prozeß kann keine Aktivität ausführen, Terminierte Prozesse können nie wieder aktiviert wer- den.

2.3. Der Modellbegriff

Eine Möglichkeit, den Simulationsbegriff zu umreißen und ein- zuschränken, besteht in der Differenzierung des Modellbegriffes.

Definition 2.4: Modell

Das Modell eines Originals O ist ein Objekt M, das als Abbild wesentlicher Eigenschaften und Bezie- hungen von O durch ein Subjekt S eingesetzt und genutzt wird, um eine bestimmte Aufgabe lösen zu können, deren Durchführung mittels direkter Opera- tionen am Original nicht möglich, zu aufwendig o- der zu langwierig ist (/FRANK, LORENZ 79/).

Klassif~

z1erung nach Model~

charakter

mögliche { Untersuchung~

Methode

BerspieJc 1

' ^l

MODELLE

/ ~

7\ 7\

künstliche natürliche bildlich-verbale mathematische

Modelle Modelle Modelle Modelle

\/ J

nalog-Simulat1on 01skurnon

^-,,6.

Verfahren Simulation Stromungsmodell auf volks\l. lrt· Lag'.!ropt1- Wa.rteschlan- dl!m Analog.rl!chner 5ChJfrliche m1enmg_mJ1 ic bei der

Erk.larung,- D1ffe.r:,ent1al• Kunden- moddk rcchnun(!. bed1enung

Abbildung 2.2: Modelle (aus /KRÜGER 75/)

Grob kann man zunächst einmal zwischen physischen (materiel- len) und formalen (abstrakten) Modellen unterscheiden, von denen die mathematischen Modelle wiederum eine Teilmenge darstellen.

Definition 2.5: Mathematisches Modell

Das mathematische Modell eines realen Systems oder Prozesses ist eine Gesamtheit formaler Beziehun- gen, die den Zusammenhang der Zustandsvariablen mit anderen Systemparametern, gewissen Anfangsbe- dingungen, und Eingangsgrößen des Systems oder Prozesses beschreibt (/FRANK,LORENZ 79/).

Ein mathematisches Mode 11 heißt analytisch, falls zusammen- hänge zwischen Zustandsvariablen, Parametern, Anfangsbedingungen, etc. durch analytische (funktionale) Ausdrücke beschrieben werden z.B. algebraische Terme, Integral-, Differentialgleichungen, etc.). Es heißt algorithmisches Modell, falls der Prozeßverlauf durch elementare Operationen und Bedingungen algorithmisiert wer- den kann (/FRANK, LORENZ 79 /). Solche Modelle sind die Grundlage für die sogenannte Digitale Simulation.

Definition 2.6: Simulationsmodell (

Ein Simulationsmodell eines realen Systems ist ein mathematisches Mode 11 desse 1 ben Systems, in dem das Systemverhalten durch geeignete Algorithmen beschrieben wird. (Der Begriff Algorithmus wird

hier von analytischen Ausdrücken streng getrennt.) l

Im folgenden werden nur noch Simulationsmodelle betrachtet.

3 .

S p e z i f i k a t i o n e i n e s

S i m u i a t o r s

Das Wort Simulation gründet sich auf dem lateinischen Verb simulare, das die Bedeutung ähnlich machen impliziert. Dadurch wird die zeitliche Komponente sichtbar, deren Manipulation und Verwalten ein Hauptprobl_em innerhalb des Gebietes der Simulation ist.

3.1. Der Simulationsbegriff

Die meisten in der Literatur vorhandenen Definitionen bieten nichts überraschendes. So wird z.B. in /JENTSCH 69/ und /RISAK 71/

recht oberflächlich der Simulationsbegriff eingeführt:

Definition 3.1: Simulation

1. Mittel zur Untersuchung physikalischen Systems im 69/).

des Verhaltens eines Zeitbereich (/JENTSCH

2. Nachbildung eines Systems durch ein ihm hin- sichtlich seiner wesentlichen Eigenschaften äqui- valentes anderes System (/RISAK 71/).

Die schon oben kurz erwähnte digitale Simulation kann folgen- dermaßen definiert werden:

Definition 3.2: Digitale Simulation

Digitale Simulation ist die Nachahmung von Verhal- tensweisen eines dynamischen Systems auf der Grundlage eines algorithmischen Modells zum Zweck der Analyse und Bewertung eines möglichen oder existierenden realen Systems auf Rechenanlagen (/FRANK,LORENZ 79/).

Digitale Simulation steht also für Berechnungsexperimente mit mathematischen Modellen dynamischer Systeme. Das zugrundeliegende mathematische Konzept kann aus der Bedienungs-, Automaten-, Gra- phentheorie stammen bzw. auf Differentialgleichungen basieren.

Demzufolge unterscheidet man auch zwischen bedienungstheoreti- schen, automatentheoretischen und gleichungsorientierten Simulati- onsmodellen bzw. -systemen.

Im folgenden wird statt von digitaler Simulation nur noch kurz von Simulation gesprochen. Dabei taucht oft der Begriff Er- eignis auf:

Definition 3.3: Ereignis

Ein Ereignis ist eine zu einem bestimmten Zeit- punkt erfolgende Zustandsveränderung eines Systems bzw. Prozesses. Es führt zu Wertveränderungen et-

ner oder mehrerer zusammenhängender Zustandsvari- ablen des Systems und beansprucht selbst keine Zeitdauer (/FRANK,LORENZ 79/).

In /FRANK,LORENZ 79/ werden noch einige weitere Begriffe ein- geführt: Sie interpretieren Experimentierparameter als jene im Mo- dell erfaßten Grössen und Beziehungen, die während der Simulation in gewissen Grenzen durch den Experimentator verändert werden kön- nen. Ein Simulationsversuch ist für sie die Durchführung aller Be- rechnungen, die mit einem vorgegebenen Satz von Werten der Experi- mentierparameter verbunden sind.

Im folgenden werden noch einmal kurz die wesentlichen Unter- schiede zwischen analytischen und simulativen Verfahren aufge- führt.

• ein analytisches Verfahren liefert in den meisten Fäl- len mehr Informationen in allgemeiner Form, d,h. für verschiedene Fragestellungen,

• Simulation ergibt meist nur Information für eine kon- krete Fragestellung,

• der Arbeitsaufwand bei der Simulation ist oft höher,

• Simulation erfordert lediglich die Ausführung relativ einfacher Operationen,

• Simulationsergebnisse sind relativ ungenau und nur un- ter hohem Aufwand zu verbessern,

• oft stehen für die Untersuchung komplexer Systeme keine analytischen Verfahren zur Verfügung.

3.2. Probleme der Modellierung

Grundsätzlich können die Probleme der Modellierung in einen analytischen sowie einen generativen Bereich unterteilt werden,

3.2.1. Die Systemanalyse

Die schon oben aufgestellte Forderung nach einer formalen Be- schreibungsmethode des Verhaltens eines realen Systems in einem Modell impliziert gewisse Gedankengänge beim Modelldesigner:

• Die Systemstruktur muß präzise und korrekt wiedergege- ben werden, Vereinfachungen und Abstraktionen dürfen lediglich dann vorgenommen werden, falls sie auf das Untersuchungsziel keinen Einfluß besitzen.

• Das Systemverhalten muß genauestens analysiert werden bezüglich

• der Ziele des natürlichen Systems,

• der Elemente des natürlichen Systems sowie

• der Relationen zwischen dessen einzelnen Elementen.

• Die Zuordnung _einer für das System geeigneten Beschrei- bungsmethode, z.B. Prozeßkonzept, Beschreibung durch mathematische Formulierungen, Warteschlangensysteme, etc., mit deren Hilfe das Systemverhalten möglichst re- alistisch erfaßt wird, muß vorgenommen werden.

• Die wesentlichen und für das Untersuchungsziel relevan- ten Systemzustände müssen abstrahiert, mit Attributen versehen und geeignet dargestellt werden.

• Die Relationen zwischen den einzelnen Systemzuständen müssen modelliert werden.

• Das Hauptproblem, nämlich die Modellierung der Zeit, muß in geeigneter Weise gelöst werden.

Diese verschiedenen Punkte definieren eine gewisse Mode 11- struktur, die das reale System - in Hinblick auf die zu untersu- chende Fragestellung - abstrahiert.

Oft werden gewisse Forderungen bezüglich benutzbarer Funktio- nen an Modelle geste 11 t, die man wie folgt zusammenfassen kann (/BAUKNECHT et_al 76/):

• Parallele Prozesse müssen Wechselwirkungen zwischen

im gleichen Zeitintervall gegenseitig beeinflussen, dellierbar.

darstellbar sein, d.h. die Elementen, die nebeneinander ablaufen und sich eventuell sind in geeigneter Weise mo-

• Standardisierte Funktionen - beispielsweise Zufallszah- lengeneratoren, Verteilungsfunktionen, etc. sollten benutzbar sein.

• Beziehungen zwischen Elementen sollten dargestellt wer- den können: Durch sie sind Relationen innerhalb des Systems modellierbar.

• Die Ergebnisse der Simulationsläufe, d.h. die Ereignis- se während eines und Aussagen (bezüglich der jeweiligen Systemziele) nach einem Simulationsexperiment, müssen dem Modelldesigner bzw. dem Benutzer zur Verfügung ge- stellt werden, also greifbar sein.

3.2.2. Die Modellsynthese

Die entscheidensten Gesichtspunkte und Kriterien bei der Mo- dellierung eines Systems sind die Güte und Genauigkeit, mit der das Modell das reale System wiedergibt. Ist ein Modell erst einmal konzipiert und im Einsatz und liefert es die ersten zweifelhaften Meßergebnisse, so kann man es dann kaum noch ohne großen Aufwand verbessern. Demzufolge sollte man schon in der Phase der Systema- nalyse sehr sorgfältig vorgehen, um Fehler bzw. Ungenauigkeiten zu vermeiden. Im Idealfall wird solange ein iterativer Optimierungs- prozeß im Modell vorgenommen, bis keine nennenswerte Abweichung mehr zwischen Simulationsmeßergebnissen und vorhandenen 'realen' Werten auftritt. Diesen Vorgang bezeichnet man auch als Kalibrie- rung und Validierung (vgl. Kapitel 4.7.). Hierdurch wird versucht, die Ursache für Abweichungen des Modellverhaltens zu erklären und zu beseitigen: Diese können durch fehlerhafte Meßergebnisse oder durch Fehler im Modelldesign bedingt sein.

Das Abwägen zwischen den Kosten für den Bau eines Simulators und der Menge der Fragen, die durch gewisse Experimente beantwor- tet werden sollen, ist ein kritischer Gesichtspunkt für den Mo- delldesigner: Denn oft ist vor Beginn der Simulationsexperimente nicht absehbar, welche wichtigen und strittigen Probleme noch auf- tauchen werden. Für die Güte eines Modells kann man eine Vielzahl von Kriteri.en...-a.n-t--lih-re-n---(-/FISHMAN 73/):

---·

_• Detaillierungsgrad,

• Auflösung,

• Robustheit,

• Flexibilität,

• Wahl der Implementierungssprache,

• Modellstruktur,

• Variable,

• Experimente.

Der Detaillierungsgrad eines Simulators gibt an, wie genau das Modell das reale System wiedergibt. Trivialerweise ist ein möglichst hoher Detaillierungsgrad für Simulationsergebnisse mit hohem Aussagegehalt erstrebenswert: Die Resultate sind leichter verifizierbar und die flexibleren Anwendungsmöglichkeiten lassen differenziertere Experimente zu. Demgegenüber sind auch die Nach- teile klar: Der Aufwand und die Kosten beim Design, bei der Imple- mentierung, bei der Test- und Dokumentationsphase sowie der War- tung steigen zusammen mit dem Detaillierungsgrad. Der Modelldesig- ner muß also einen geeigneten Kompromiß finden, welcher beispiels- weise oft darin besteht, daß die Abbildungsgenauigkeit des realen Systems nicht im gesamten Modell gleich hoch ist. Darüberhinaus gibt es zwei wesentliche Faktoren, die den Detaillierungsgrad be- einflussen:

• Der Detaillierungsgrad des Simulators muß dem des Last- modells entsprechen (vgl. Kapitel 4.2.). Träten dort große Unterschiede auf, so könnte zum einen das Simula- tionsmode 11 nicht die Genauigkeit und den Umfang des

differenzierteres Simulationsmodell durch eine ungenaue Last nicht hinreichend initialisiert und somit ausge- lastet.

• Informationen bezüglich der Struktur und Semantik des realen Systems implizieren ebenfalls die Höhe des De- taillierungsgrades des Simulators.

Eine Möglichkeit, Aen Detaillierungsgrad eines Systems zu charakterisieren, wird in der Literatur oft durch das Verhältnis D = S/R angegeben, wobei S die vom Simulator benötigte Zeitspanne ist, um das Zeitintervall R des realen Systems zu simuljeren. Ei- nige typische Werte, die bei der Simulation von Rechensystemen auftreten, sind im folgenden Beispiel angegeben:

Beispiel 3.1:

S/R

10³ 10² - 10¹ 10° 10-¹ 10-² - 10-³

Detaillierungsgrad auf Gatterebene

auf Register/Instruktionsebene auf Interruptebene

sehr wenig Details

Abbildung 3.1: Detaillierungsgrad bei Model- len von Rechensystemen

Bei einem hohen Detaillierungsgrad, also einer Rechnersimulation auf Gatterebene, wäre die Lauf- zeit der Simulationsexperimente im Vergleich zum untersuchten Zeitintervall des Realsystems um den Faktor 1000 vergrößert. Dies ist für manche prak- tische Anwendungen völlig unbrauchbar·, läßt sich jedoch in manchen Bereichen (z.B. VLSI-Design) nicht vermeiden.

Um die Genauigkeit eines Simulators zu charakterisieren, gibt es noch eine Vielzahl von anderen Maßen: Bei der Auflösung (reso- lution) unterscheidet man zwischen einer zeitlichen (kleinstes Zeitintervall zwischen zwei vom Simulator erfaßten Ereignissen im realen System) sowie einer räumlichen (kleinste vom Simulator ak- zeptierte Informationseinheit). Weitere sinnvolle Maße für die Auflösung sind beispielsweise die Anzahl der Simulatorzustände oder die Anzahl der verschiedenen vom Simulator akzeptierbaren Er- eignisse.

Die Robustheit (robustness) eines Simulators ist meist direkt proportional zu seinem Detaillierungsgrad. Man interpretiert sie als die Fähigkeit des Simulationssystems, das reale System mit Eingabedaten, durch die der Simulator nicht verifiziert wurde, noch genau darzustellen, also gewissermaßen als Kennzahl für die Allgemeingültigkeit des Simulators.

Weil die Ziele und endgültigen Fragestellungen einer Simula- tionsuntersuchung in der ersten Phase der Modellentwicklung oft noch nicht feststehen, ist die Forderung nach einer gewissen Fle- xibilität des Simulators unabdingbar, die natürlich einen Mehrauf- wand bei der Entwicklungszeit und den Kosten sowie eine längere Laufzeit der Simulationsexperimente impliziert. Auch hier muß der Modelldesigner einen geeigneten Kompromiß finden, der gewährleis- tet, daß nachträgliche Änderungen leicht an das Modell angepaßt werden können.

Eine triviale Möglichkeit bietet sich hierfür in der Defini- tion von Eingangs- und Ausgangsvariablen an: Man kann also über Parameter Einfluß auf die Arbeitsweise des Simulators nehmen. Da- rüberhinaus so 11 te man auch schon beim Modelldesign das Konzept und den Umfang der später durchzuführenden Simulationsexperimente berücksichtigen. Die Wahl der Implementierungssprache ist - ebenso wie die Entscheidung für eine Modellstruktur - oft eng mit der zur Verfügung stehenden Hard- und Software verknüpft.

3.3. Auswahl der Modellstruktur

Um das Verhalten eines realen Systems durch ein Modell be- schreiben zu können, benötigt man eine formale Darstellungsmetho- de, mit deren Hilfe man seine wesentlichen Eigenschaften charakte- risieren kann. Im einzelnen sind mindestens

• eine Möglichkeit zur Darstellung der Systemzustände,

• eine Menge von Zustandsübergangsregeln zwischen den einzelnen Systemzuständen für die entsprechenden Syste- mereignisse sowie

• eine Möglichkeit, eine Zuordnung zwischen der Modell- zeit und dem Auftritt bestimmter Ereignisse zu schaffen vorausgesetzt. Die größte Schwierigkeit liegt dabei in der Model- lierung der Zeit. Diese tritt nicht auf bei den Monte-Carlo Met.h.D..=

den, die weder den a . r f a T ~ _ d e n __ simulativen _verfahren zu- _3uo rdnen sind u~d l>_E! i viE!_!_E!_!l __ A.:n\Y.!rnd:ung.en ___ ~_;ü!el_!_ fü::_1:1-_nd !_1:1:~:~-~~~ha._r-ak t er

besitzen. Bei der Methode des Period Modelling wird ein festifr-Mö- aeTI=zeittakt vorgegeben, der leicht zu realisieren ist. Kompli- zierter wird dies bei den warteschlangenorientierten Methoden.

Hier gibt es drei verschiedene Ansätze, Ankunft und Bedienung in Systemen zu modellieren, und zwar mit Hilfe von Ereignissen (Event Scheduling Approach), von Aktivitäten (Activity Scanning Approach) sowie der Interpretation von Ereignisfolgen als Prozeß (Process Interaction Approach). Der letzte hier vorgestellte Ansatz benutzt Netzwerke mit Knoten und Kanten als formales Hilfsmittel zur Dar- stellung von Systemen und systemimmanenten Abläufen. Hierbei wird oft die Modellierung der Zeit außer Acht gelassen.

3.3.1. Monte-Carlo-Methoden

Unter dem Begriff Monte-Carlo-Methoden werden eine Anzahl verschiedener Verfahren zusammengefaßt. Nach /KRÜGER 75/ sind dies nicht immer simulative Ansätze, sondern es wird lediglich eine Al- ternative für analytische Lösungsverfahren benutzt: So brauchen die zu untersuchenden Systeme beispielsweise keine dynamische Struktur besitzen. Zeitfaktoren werden meistens nicht berücksich- tigt.

In /FRANK,LORENZ 79/ wird versucht, die Monte-Carlo-Simulati- on zu definieren, die noch allgemeiner in /HAMMERSLEY, HANDSCOMB 64/ gehalten ist:

Definition 3.4: Monte-Carlo-Simulation

1. Eine Monte-Carlo-Simulation ist die rechneri- sche Ermittlung der Modellergebnisse in stochasti- schen Systemen mit Hilfe von Zufallszahlen und ma- thematisch-statistischen Methoden (/FRANK,LORENZ 7 9 /).

2. Monte-Carlo-Methoden sind alle Techniken, die für die Lösung von Problemen innerhalb eines Mo- dells Zufallszahlen oder Pseudozufallszahlen be- nutzen (/HAMMERSLEY, HANDSCOMB 64/).

/KLEIJNEN 74/ unterscheidet als Anwendungsgebiete von Monte- Carlo-Methoden

• Lösung deterministischer Probleme,

• Distribution-Sampling: Bestimmen von Verteilungen bzw.

Verteilungsparametern,

• Simula tian.

Da in den meisten Simulationsexperimenten Zufallszahlen benutzt werden, sind sie trivialerweise als Monte-Carlo-Simulation inter- pretierbar. In der Literatur werden heute meistens nur noch die ersten beiden obenstehenden Anwendungen als Monte-Carlo-Methoden - manchmal auch als Monte-Carlo-Simulationen - bezeichnet.

Ein einfaches Beispiel für eine Anwendung der Monte-Carlo-Si- mulation, durch die Aussagen bezüglich des Zuverlässigkeitsverhal- tens komplexer, fehle rto le rante r Systeme gewonnen werden können, ist aus /DAL CIN 79/ entnommen:

Beispiel 3. 2:

Gegeben sei ein Zuverlässigkeitsschal tnetz mit m Komponenten. Pi sei die Funktionswahrscheinlich- keit der i-ten Systemkomponente. Der Algorithmus besteht dann aus folgenden Schritten:

1. Eine Zahl n wird durch einen Pseudozufalls- zahlengenerator bestimmt, der gleichverteil-

2.

3 •

4.

te natürliche Zahlen im Bereich [O, ••• , 99]

erzeugt, Es gilt dann Prob{n/100 s Pi} = Pi•

Für alle m Komponenten des Systems wird die Indikatorvariable

xi

der i-ten Komponente auf 1, falls n/100 ^$ Pi gilt, ansonsten auf 0 gesetzt.

Es wird festgestellt, ob intakt (z=l) oder defekt Schritte 1. bis 3. werden wiederholt.

das Gesamtsystem (z=O) ist. Die hinreichend oft Die Verfügbarkeit des Gesamtsystems wird be- rechnet durch den Quotienten Z/N, wobei N die Anzahl der Versuche und

z

die Anzahl der Versuche mit z=l darstellt.

Monte-Carlo-Methoden werden oft auch als Sampling-Technik be- zeichnet, Sie sind immer dann anwendbar, wenn zufällige Komponen- ten in ein System einfließen (z.B. Verteilen von Konsumenten auf Bediener). Eine hohe Genauigkeit der Ergebnisse einer Monte-Carlo- Simulation bedingt eine große Stichprobe, die aus Gründen des Auf- wandes oft nicht zu rechtfertigen ist, so daß man Methoden zur Steigerung der Effizienz entwickelte, die sogenannten Variance- and Sample-Size-Reducing-Techniques (vgl, Kapitel 4.7.). Sehr wichtig bei der Monte-Carlo-Simulation ist das Problem der Gene- rierung von Zufallszahlen und -verteilungen (vgl. Kapitel 4.3.- 4 . 5 . ) • Für de t a i 11 i e r t e r e I n f o rm a t i o n e n sei an diese r

s

t e 11 e auf /HAMMERSLEY,HANDSCOMB 64/ verwiesen.

3.3.2. Period Modelling

Will man bei einer Systemsimulation jeden Wechsel der Zu- standsvariablen modellieren, so kann dies zu einem hohen Aufwand führen, der sogar die Qualität der erhaltenen Ergebnisse gefähr- det. Dies ist zum Beispie 1 bei Systemen der Fall, in denen zwar viele Zustandswechse 1 in kurzen Zeitintervallen auftreten, diese jedoch lediglich eine geringe Auswirkung auf das globale System- verhalten besitzen,

Abhilfe schafft das Konzept des sogenannten Period Modelling.

Dieses wird benutzt, falls man in erster Linie Aussagen und Infor- mationen allgemeingültiger Art erhalten will und weniger Wert auf Ergebnisse über spezifische und einzelne Systemelemente legt. Da- bei wird der Zeitverlauf in konstanten Schritten einer vorgegebe- nen Intervall-Länge dt (Sampling-Intervall) modelliert. Die Zu- standswechsel innerhalb des Systems werden zu den Zeitpunkten dt, 2dt, 3dt, . . . modelliert, und zwar in der Form, daß zu einem die- ser Zeitpunkte alle innerhalb des letzten Intervalls aufgetretenen Systemveränderungen berücksichtigt werden.

Das Konzept des Period Modelling findet überall dort Einsatz, wo ein hoher Verwaltungsaufwand - bedingt durch viele auftretende Ereignisse - die Simulationsdauer zu sehr erhöhen würde. Simulier-

gen über die Verfügbarkeit der vorhandenen Harddisks zu erhalten, führte es sicherlich zu weit, jeden einzelnen Plattenzugriff als

'wichtiges' Ereignis zu interpretieren.

3.3.3. Ereignisorientierter Ansatz

Bei dem Event Scheduling Approach müssen alle Schritte be- schrieben werden, die bei einem Auftreten eines individuellen Er- eignisses stattfinden. Ein Zustandsübergang findet dabei lediglich zum Zeitpunkt des Auftretens eines Ereignisses statt, zwischen zwei Ereignissen geschieht nichts, das System verbleibt in seinem aktuellen Zustand. Der Zeitverlauf innerhalb des Systems wird als Sprung vom letzten zum zeitlich nächsten Ereignis interpretiert.

Es wird eine sogenannte Ereignisliste gebildet, welche die Ereig- nisfolge modelliert, in der alle auftretenden Ereignisse nach ih- rer Auftrittszeit geordnet zusammen mit einer Anzahl gewisser At- tribute enthalten sind:

Ereigniszeit to Ereigniszeit t ....

Ereignistyp eo ^..__

> -->

Ereignistyp em

Auswirkungen Auswirkungen

Abbildung 3.2: Ereignisliste

Zu Beginn der Simulation wird nun diese Ereignisliste gene- riert und mit bestimmten Ereignissen initialisiert. Neu hinzukom- mende Ereignisse werden ihrer Ereigniszeit entsprechend in die Liste eingeordnet. Ihre Abarbeitung wird durch ein sogenanntes Si- mulations-Kontrollprogramm solange mit folgenden Schritten durch- geführt, bis die Ereignisliste leer ist:

• Das Simulations-Kontrollprogramm wählt das Listenele- ment mit der kleinsten Ereigniszeit als nächstes auf- tretendes Ereignis aus.

• Der Wert der aktuellen Modellzeit taict wird auf den Wert der nächsten Ereigniszeit vorgestellt.

• Entsprechend dem abzuarbeitenden Ereignistyp laufen Un- terprogramme ab, die die jeweiligen Änderungen inner- halb des Modells realisieren. Danach übernimmt wieder das Simulations-Kontrollprogramm die Steuerung des Si- mulationsablaufes.

Die Problematik der Modellierung der Zeit wird an einem Bei- spiel verdeutlicht:

Beispiel 3.3:

Simuliert wird ein Rechensystem, das die Ankunft und Bedienung von ins System eintretenden Jobs be- schreibt und synchronisiert. Nun wird der Fall be- trachtet, daß ein Job ins System eintritt, der zwei abzuarbeitende Aufgaben besitzt. Ankunft und Bedienung werden folgendermaßen dargestellt:

Ereignis 1 Erelgnla 2 Ankunft de, Beginn der

Joba Bedienung

von~gabel

Ereignis 3 Beginn der Bedienung

\IOl"IAufgabe II

Ereignis

•

Ende derBe- clenung von Aalgabe 1

Abbildung 3.3: Modellierung der Zeit

Erelgnla 5 Ende der Be- dienung von Aalgabe II

Für detailliertere und umfangreichere Beispiele sei an dieser Stelle auf /FISHMAN 73/ verwiesen.

Trotzdem diese ereignisorientierte Methode zur Darstellung von Simulationsabläufen sehr übersichtlich ist, ergibt sich jedoch ein großer Nachteil: Treten viele Ereignisse auf, so wird das Ver- walten der Ereignisliste sehr aufwendig, so daß auf andere Verfah- ren zurückgegriffen werden muß. Eines davon wird im nächsten Ab- schnitt vorgestellt.

3.3.4. Aktivitätsorientierter Ansatz

Bei der aktivitätsorientierten Methode - in der Literatur oft auch als Activity Scanning Approach bezeichnet - werden keine Er- eignisse, sondern im System ablaufende Aktivitäten betrachtet. Ei- ne Aktivität wird hierbei als eine Anzahl von Elementaroperatio- nen, die den Systemzustand ändern, interpretiert. Trivialerweise besteht eine Aktivität mindestens aus zwei Ereignissen, nämlich ihrem Beginn und ihrem Ende. Der Zeitverlauf wird analog zur er- eignisorientierten Methode in Sprüngen von Ereignis zu Ereignis modelliert. Man benutzt jedoch keine Ordnungsinstanz, wie sie die Ereignisliste darstellt, sondern eine Vielzahl individueller Uh- ren. Diesen sind bestimmte, Aktivitäten auslösende Zustandsvariab- len zugeordnet. Die Uhren zeigen - relativ zur Systemzeit - die Eintrittszeiten von zukünftigen Ereignissen an, also z.B. den Be- ginn einer Aktivität nach Verstreichen von zehn weiteren Einheiten der Systemzeit.

Die Abarbeitung des Simulationslaufes wird wieder durch ein Simulations-Kontrollprogramm realisiert, das solange mit folgenden Schritten abläuft, bis keine Aktivitäten mehr abzuarbeiten sind:

• Das Simulations-Kontrollprogramm prüft alle Uhrzeiten und wählt die Aktivität mit der kleinsten Uhrzeit ti•

• Der Zeitsprung wird realisiert, indem alle Uhren um den Betrag ti redu2iert werden.

• Entsprechend dem abzuarbeitenden Ereignistyp laufen Un- terprogramme ab, die die jeweiligen Änderungen inner- halb des Modells realisieren. Danach übernimmt wieder das Simulations-Kontrollprogramm die Steuerung des Si- mulationsablaufes.

Die Problematik der Modellierung der Zeit wird an dem Bei- spiel des vorhergehenden Abschnittes verdeutlicht:

Beispiel 3.4:

Simuliert wird ein Rechensystem, das die Ankunft und Bedienung von ins System eintretenden Jobs be- schreibt und synchronisiert. Nun wird der Fall be- trachtet, daß ein Job ins System eintritt, der zwei abzuarbeitende Aufgaben besitzt. Ankunft und Bedienung werden im Vergleich der ereignis- und aktivitätsorientierten Methode folgendermaßen dar- gestellt:

Erelgnl• 1 Erelgnlt 2 Ardwnft dea Beginn der

Job• Bedienung

von.Aufgabe 1

Erelgnl• 3 Beginn der Bedienung IJCl'I.Aufgabe II

Erelgntt'4 Ende der Be- dienung von Allgabel

Abbildung 3.4: Modellierung der Zeit

•

Eretgnl• 6 Ende der Be- dienung von Allgabe II

Für detailliertere und umfangreichere Beispiele sei auf /FISHMAN 73/ verwiesen.

Der große Vorteil dieses Modellierungsansatzes gegenüber der Event-Scheduling-Methode, der vor allem in Systemen mit vielen Er- eignissen bzw. Aktivitäten in Erscheinung t r i t t , besteht darin, daß keine Ereignisliste generiert und verwaltet zu werden braucht:

Denn das Einsortieren von (zukünftigen) Ereignissen in eine Ereig- nisliste wird durch logische Abfragen der jeweiligen Uhren umgan-

gen. Bei Systemen mit wenig Aktivitäten sollte jedoch aufgrund des geringen Umfangs der Ereignisliste das Event-Scheduling-Konzept verwendet werden.

Obwohl der Activity Scanning Aproach - im Vergleich zur er- eignisorientierten Methode ein höheres und vielschichtigeres Konzept darstellt, ist er aus zwei Gründen kaum praxisrelevant:

Zum einen wird dieses Konzept nur von wenigen Programmiersprachen unterstützt, und zum anderen gibt es für die Modellierung von Sys- temen ein höheres Konzept, das im nächsten Abschnitt näher vorge- stellt wird.

3.3.S. Prozeßorientierter Ansatz

Bei dem sogenannten Process Interaction Approach steht nicht die Bedienung einzelner Aufgaben eines Jobs im Vordergrund, son- dern es wird dessen gesamter Verlauf durch das System betrachtet.

Ein Prozeß wird hier als Folge von - nach der Zeit geordneten - Ereignissen interpretiert, also als die Menge der logisch zusam- menhängenden Zustandsübergänge der einzelnen Zustandsvariablen be- trachtet, wodurch sich besonders gut die Problematik von parallel ablauf enden, sich überlappender bzw. sich gegenseitig beeinf lus- sende r Prozesse darstellen läßt:-) Ist dieses Modellierungskonzept in einer Programmiersprache implementiert, so gibt es im wesentli- chen drei Statements, um Konflikte zwischen Prozessen zu beseiti- gen:

• Delay-Statement: Verzögerung des Prozeßablaufs um eine Zeitspanne bzw. bis zu einem bestimmten Zeitpunkt rela- tiv zur Simulationszeit.

• Wait-Statement: Suspendierung des Prozeßablaufs bis der Prozeß von außen reaktiviert wird.

• Wait-Until-Statement: Suspendierung des Prozeßablaufs bis ein bestimmtes prozeßexternes Ereignis eintritt.

Die Abarbeitung des Simulationslaufes wird wieder durch ein Simu- lations-Kontrollprogramm realisiert, das mit der Abarbeitung aller im System enthaltenen Prozesse terminiert. Tritt ein Wai t- oder Delay-Statement in einem Prozeßablauf auf, wird ein sogenannter Interaktionspunkt im Simulationsprogra-mm definiert, und die Kon- trolle geht an das Simulations-Kontrollprogramm über. Dieses er- zeugt dann ein Record-Element, welches mit folgenden Attributen in eine Liste eingetragen wird:

• Identifikation des Jobs,

• Zeitpunkt des Wiedereintritts bezüglich der Simulati- onszeit,

• Reaktivierungspunkt, d.h. der Stelle im Simulationspro- gramm, an welcher die Kontrolle zurückkehrt,

Das Simulations-Kontrollprogramm bestimmt dann ein Listenelement, dessen Wiedereintrittszeitpunkt der aktuellen Simulationszeit am nächsten ist. Danach wird die Simulationszeit auf diesen Zeitpunkt gesetzt und die Kontrolle geht wieder an das Simulationsprogramm des Benutzers an dem entsprechenden Reaktivierungspunkt über . .

Die Handhabung eines Wait-Until-Statements läuft etwas anders ab. Die Kontrolle geht zwar wieder vom Simulations- zum Simulati- ons-Kontra 11 programm über, das ebenfalls ein Recorde lement gene- riert, in dem die

• Identifikation des Jobs sowie

• der Reaktivierungspunkt

enthalten sind. Dieses Element wird in die Liste der wartenden Prozesse eingetragen. Erst nachdem keine unkonditionalen Ereignis- se mehr für die aktuelle Simulationszeit anstehen, wird mit der Abarbeitung dieser Liste begonnen. Das Simulations-Kontrollpro- gramm wählt ein Listenelement aus, welches dem momentanen System- zustand genügt, danach wird es bearbeitet. Dieser Vorgang wieder- holt sich solange, bis kein weiteres Listenelement mehr unter den aktuellen Bedingungen ausgeführt werden kann. Danach geht die Kon- trolle wieder an das Simulationsprogramm an dem entsprechenden Re- aktivierungspunkt über.

Die Problematik der Modellierung der Zeit wird wiederum an dem Beispiel des vorhergehenden Abschnittes verdeutlicht:

Beispiel 3.5:

Simuliert wird ein Rechensystem, das die Ankunft und Bedienung von ins System eintretenden Jobs be- schreibt und synchronisiert. Nun wird der Fall be- trachtet, daß ein Job ins System eintritt, der zwei abzuarbeitende Aufgaben besitzt. Ankunft und Bedienung werden im Vergleich der ereignis-, akti- vitäts- sowie prozeßorientierten Methode folgen- dermaßen dargestellt:

, , , , , , , , , , , ., , , , , , , , , , , , , , , , , , , , , ,

'

' '

'

'

'

' ' ' ' ' ' ~ '

' ' '

'

'

' '

'

' ' ' ' '

' '

' ' '

, , , , , , , ,

.,

, , , , , , , , , ,

.,

, , , , , , , , ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ., , , , , , , , , ., , , , , , ., , , , , , , , , , , , , , , , , ,

' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' '

, ., , , , , , ., , , , , , , , , ., , , , , ✓ , , , , , , , , , ✓ ,

' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ^. . . ^{. .} , , , , , , , , , , , , , , , ,-~·.·

' ' ' ' ' ' ' ' ' ' ' ' ' ' ' , , , , , , , , , , , , , , , ,

' ' ' ' ' ' ' ' ' ' ' ' ' ' '

',',',',',,,,.,.,..,...,c,.-,-_....,...,....r'-'.1--r--r-.,...,...,..--r--r-,r-,_

, , ,

,

, ., ., ' ' ' ' ' ' ,,,.,,.,,,,

...

Erelgnla 1 Ankunft des Jobs

Erelgnl• 2 Beginn der Bedienung vonAufgabe 1

Erelgnla 3 Beginn der Bedienung von Aufgabe II

Erelgnla -l Ende der Be- dienung von Al.fgabe 1

Abbildung 3.5: Modellierung der Zeit

Ereignis 5 Ende der Be - dlenung von Altgabe II

Für detailliertere und umfangreichere sei an dieser Stelle auf die Literatur 73/) verwiesen.

Beispiele (/FISHMAN

Ein großer Vorteil des Process-Interaction-Ansatzes liegt in seiner Strukturiertheit, die einem Anwender. einen guten überblick ü'ber den Kontrollfluß der Simulationstätigkeit ermöglicht. Darü- berhinaus ist dieses Konzept besonders gut für die Mode 11 ie rung dynamischer Systeme geeignet. Es ist allerdings nicht trivial zu verstehen und anzuwenden.

3.3.6. Netzwerk-Ansatz

Ein weiterer Ausgangspunkt für die Modellierung von Simulato- ren ist der sogenannte Netzwerk-Ansatz. Im Gegensatz zu den bisher vorgestellten Konzepten stehen bei diesem Ansatz graphische Ge- sichtspunkte im Vordergrund, die ein Modell übersichtlicher und faßbarer gestalten sollen. Eine Modellierung der Zeit ist dabei meist nicht vorgesehen, so daß man eine entsprechende Erweiterung des jeweilig benutzten Konzeptes selber entwickeln bzw. eine Me- thodik verwenden muß , die die gewünschten Möglichkeiten bereit- stellt (z.B. Timed-Petri-Netze). Da es kaum Programmiersprachej

11

J

gibt, die den Netzwerk-Ansatz unterstützen, sind diese Konzepte h, ¹

für die Praxis heute noch wenig relevant.

Oft wird auf gerichtete Graphen mit Knoten und Kanten zurück--~

gegriffen. Die Knoten stellen dabei Elemente des zu simulierenden Systems, die Kanten gewisse Aktivitäten innerhalb des Systems dar.

Ein Simulationslauf besteht nun im 'Finden' eines Weges innerhalb des Netzwerkes, ausgehend von einem oder mehreren Anfangsknoten bis hin zu einer Menge von End- oder Terminalknoten._J

Bei der originaren, formalen Beschreibung des Modells wird nicht auf mathematische Hilfsmittel oder die Elemente einer Pro- grammiersprache zurückgegriffen, sondern man benutzt eine graphi- sche Darstellungsform. Man unterscheidet dabei oft statische von dynamischen ('flüchtigen') Einheiten, wobei die statischen Elemen- te durch Relationen untereinander in Beziehung stehen und von den dynamischen Einheiten 'besucht' werden.~odelle solcher Art werden in der Literatur oft Traffic Networks genannt) Am bekanntesten sind dabei sicherlich die Petri-Netze bzw. die Netze aus Instanzen und Kanälen ( /REISIG 85/) mit ihren Erweiterungen. (Es existieren einige Gründe, die für ihre Verwendung beim Systementwurf spre- / chen':)

• ^{Man kann} auf Softwaresysteme zurückgreifen, mit deren Hilfe Petrinetze graphisch generiert, manipuliert, ve- rifiziert sowie getestet werden können.

• Die Struktur der Netze aus Instanzen und Kanälen ist an das Softwareentwicklungskonzept des ¹stepwise refine- ment' angelehnt.

• Sowohl Syntax (Graphentheorie) wie auch Semantik (Mo- de 11 des end 1 ichen Automaten) sind praz1se definiert, so daß keine Möglichkeit der unterschiedlichen Inter- pretation bestimmter Sachverhalte besteht.

Petrinetze finden in den unterschiedlichsten Gebieten Verwen- dung, beispielsweise bei der Modellierung von Hardware oder von Kommunikationsprotokollen, bei der Darstellung von parallelen Pro- zessen und verteilten Datenbanken, vor allem aber beim sogenannten Requirements Engineering, d.h. während der ersten Entwicklungspha- sen beim Systementwurf. Für weitere Informationen sei an dieser Stelle auf die umfangreiche zu diesem Thema existierende Literatur verwiesen, z.B. /REISIG 85/.

Untenstehendes Beispiel ist aus /REISIG 85/ entnommen. Es wird ein System mit drei konkurrierenden speicherlesenden und ei- nem speicherschreibenden Prozeß dargestellt. Die Kreise bezeichnen dabei sogenannte Stellen, die Quadrate Transitionen. Der Wert an den Pfeilen (Pfeilgewicht) gibt die Anzahl der Marken an, die beim Schalten der entsprechenden Transition weitergeleitet werden.

Beispiel 3.6:

Abbildung 3.6: Netz aus Stellen und Transitionen

4 . R e a 1 i s i e r u n g e i n e s S i m u i a t o r s

Hat man sich hinsichtlich der grundlegenden Charakteristika und Eigenschaften eines Modells genügend Klarheit verschafft, so kann man die Modellsynthese abschließen: Das Modell kann mit Hilfe von Programmiersprachen in eine auf einem Rechner ablaufbare Form übertragen, d.h. implementiert werden (Kapitel 4.1.). Weiterhin wird es durch einen iterativen Optimierungsprozeß solange geän- dert, bis es den gesetzten Anforderungen entspricht (Kapitel 4,7.). Dafür muß eine geeignete Auswahl von verschiedenen Simula- tionsexperimenten definiert, also die Last bzw. der Modellinput festgelegt werden (Kapitel 4,2.-4.5,), Hierfür, bei der Validie- rung und Calibration des Modells, sowie bei der abschließenden Auswertung der Ergebnisse (Kapitel 4.6.) benötigt der Modelldesig- ner eine Vielzahl von Hilfsmitteln aus dem Bereich der Statistik.

/KRÜGER 75/ teilt den Ablauf eines Simulationsprojektes in fünf Phasen ein, deren Zusammenhang in Abbildung 4.1 wiedergegeben wird:

lienmg

Einsatz

.indere Pro- der

~lemlOsung Simulation Jl Schaffung der Voraussetzung tilr die Simula- Daten Modellfor- -.ammdn muHetw11

1 + +

^III

t

,chlecht

t

schlecht ^V

l

Abbildung 4.1: Simulationsablauf

In der ersten Phase steht die Spezifikation des Untersu- chungszieles im Vordergrund. Die Frage, ob der Aufwand für die Ge-

scheidung zugunsten eines Modells, so müssen gewisse Voraussetzun- gen geschaffen werden: Informatik- bzw. simulationsspezifische Kenntnisse, Fertigkeiten und Fähigkeiten (beispielsweise aus dem j ewei 1 igen Anwendungsgebiet, Operations Research, Wahrscheinlich- keitstheorie, Programmierkenntnisse, etc.), Bereitstellung einer geeigneten Hardware sowie die Beschaffung der für die Simulations- experimente benötigten Daten. Die Datensammlung stellt neben der Madellfarmulierung den wesentlichen Gesichtspunkt der dritten Pha- se dar. Diese beiden Tätigkeiten beeinflussen sich gegenseitig, d.h. sie stehen in einer Wechselwirkung zueinander. In Phase vier findet die sogenannte Validierung des Modells statt, d.h. ein Test auf die Wiedergabegenauigkeit des realen Systems durch das gene- rierte (künstliche) Modell. Die letzte Phase besteht aus dem De- sign, der Durchführung und der Analyse von Simulationsläufen mit dem validierten Modell. Sind die Phasen eins bis vier vorher kor- rekt abgearbeitet worden, so erhält man in dieser Phase Ergebnisse bezüglich der betrachteten Problematik.

Ähnlich werden in /FRANK,LORENZ 79/ die Bereiche Prozeßanaly- se, Modellierung, Programmierung sowie Validierung während eines Simulationsprojektes unterschieden:

fl'rOb/em -und Zietf'ormulienm

Ht!Olsystem (-proreß) ( existent oder geplont:

i~ ~i

~~ p

1 ~, _I

~§ _'l: ~~ !:i

~ empirisclles inho/tliche Proreßbe -

'E

Ootenmoterlol scllreibun (Objekr.;ysfem.

<t

~ _~

~i

~

]

'I:,

f~

^~

r-

^~

t - - - ----

^{-l:?~ ~}

i- - - -~

~

::7

ll :f1 ~ .91

t

¹

¹¹

~ " ' 11::....

^{g -.:}

^~

I

¹

formolisiertes ili

t 1

1

1

·l:? Ootenmoterio/

<: _l

fk

~ 1

~

-~

_~

1 ^{~ ~}

~I t ^...

^,:::

... 1~ i

^t-

..

^~

-~

^{], ~ 1}

-~

^~

1

~

Modell (entwvrf'J. _1,:

Experimentpton ~

t

1 J

1 ' ^{"' F}

¼

^~ 11

l ' -

.1

1: ....

~ 1: ~

1 "€ ^{~ t 1:}

~ ~ 1

~

1 ~

1

L _{- - -} - - - ^_J

Abbildung 4.2: Simulationsaktivitäten

Im Einzelnen sind die verschiedenen Aktivitäten folgendermas- sen interpretierbar: Die Prozeßanalyse kann als Struktur- und Funktionsanalyse mit dem Ziel einer 'verbalen Definition des Ob-

jektsystems (inhaltliche System- und Prozeßbeschreibung)', d.h.

Auflistung der Elemente einschließlich ihrer Eigenschaften, Rela- tionen, Parameter und Zustandsänderungen des Gesamtsystems, inter- pretiert werden, Es findet eine isolierende sowie eine generali- sierende Abstraktion statt: Zum einen werden die zur Problemlösung bedeutungslosen oder redundanten Items eliminiert, zum anderen wird die verbale Systembeschreibung formalisiert, wodurch der Mo- delldesigner eine Basis für das weitere Vorgehen erhält. In der Phase der Modellierung wird diese Basis zur Konstruktion eines die Systemziele verwirklichenden Algorithmus benutzt. Parallel dazu ist eine Planung der Simulationsläufe einschließlich einer Defini- tion der dafür benötigten Daten erforderlich. Wichtige Aspekte bei der Programmierung sind die Auswahl der Programmiersprache bzw.

geeigneter Softwaretools sowie das Verwenden von Software-Enginee- ring-Techniken, die eine gute Einsicht in die Syntax und Semantik des Programms ermöglichen. Ein auf syntaktischer und logischer Ebene verifiziertes Simulationsprogramm wird in der Phase der Va- lidierung auf seine Gültigkeit, d,h. Abbildtreue und Genauigkeit, überprüft. Dies geschieht beispielsweise durch den Vergleich von Simulationsergebnissen mit realen Daten (vgl, Kapitel 4,7.).

Der nun in dieser Arbeit vorgestellte Ansatz ist in Abbildung 4.3 mit Hilfe eines sogenannten Struktogramms dargestellt.

Simulatorspezifikation;

Systemanalyse;

Modellsynthese;

Simulatorrealisierung;

Modellimplementierung;

Experimentdesign;

1

Lastcharakterisierung;

REPEAT

Modellanalyse;

Kalibrierung;

UNTIL Modell hinreichend valide;

Outputauswertung;

Nachdem der Problembereich der Simulatorspezifikation in Ka- pitel 3. diskutiert wurde, werden jetzt die Realisierungsaspekte näher erläutert.

4.1. Unterstützung durch spezielle Simulationssprachen Simulationssprachen wurden entwickelt, um dem Benutzer leicht überschaubare, einfache, formale Prozeduren für die Beschreibung real er Systeme, d. h. für die Formulierung von Modellen, anzubie- ten. Wesent liehe Komponenten sind dabei Hi 1 f smi t te 1 für die Dar- ste 11 ung von Elementen sowie Funktionen zwischen diesen Elementen.

Die Vorteile von Simulationssprachen gegenüber herkömmlichen Programmiersprachen sind dabei offensichtlich:

• geringerer Programmieraufwand,

• Reduzierung der Kosten bei nachträglichen Änderungen, Erweiterungen, etc.,

• Die Anzahl der Fehlermöglichkeiten wird von vornherein eingeschränkt.

Dieselbe Unterscheidung, die man zwischen diskreten und kon- tinuierlichen Simulationen trifft, kann man auch bei den Simulati- onssprachen anwenden: Zum einen wird ein stetiger Zeitablauf ange- nommen, zum anderen wird er in einzelnen Schritten über konstante bzw. variable Zeitintervalle simuliert. Diese Sichtweisen stellen jedoch kein grundsätzliches Problem dar, da sie rein subjektiv auf nahezu alle Modelle angewandt werden können. Beiden Typen von Pro- grammiersprachen ist jedoch folgendes gemeinsam: Sie besitzen Kom- ponenten zur Modellformulierung und Steueranweisungen für den Si- mulationsablauf.

Eine Darstellung einiger bekannter kontinuierlicher Simulati- onssprachen ist in Abbildung 4.4 (aus /KREUTZER 86/) enthalten, die meisten Implementierungen basieren auf FORTRAN. Kombinierte Sprachklassen , d.h. Programmiersprachen, die beiden Unterschei- dungskriterien genügen, sind in Abbildung 4.4 unterstrichen:

Cla.u ,... _ _ _ _ PDONE

DSl)'J(J

./ t

^GASP_!Y

, - CSSL \

DYNAMO / \CSMP/J60 , FOrJIM

l>YNA~II . /Sil~I \ SLAiG • • ' - r - - r - - - - '

/ ~ ^{. "} ACSL CSMPIII ,

l)YNAMI > III DARF.-P PROSE

C'SSL IV Sl_il .!. PDEL

PDELAN.,,

Abbildung 4.4: Kontinuierliche Simulationssprachen

Nach /KREUTZER 86/ besitzen diskrete am ältesten und be- kanntesten sind GASP, SIMSCRIPT, GPSS und SIMULA, die auf den Pro- grammiersprachen FORTRAN IV bzw. ALGOL 60 basieren eine größere Praxisrelevanz als kontinuierliche Simulationssprachen, einen überblick gibt er in Abbildung 4.5:

1 1 1 1 1 1 1 1 1 1 1 1 1

1 ' /

•--ADASIM

\ ' ' ^\ _\

\

\

\,

lman~ rc:t.:i:nt ' \

propo.wl$J \ GPSS V/

SAMOA \ Nordc:n

/ / /

,/~/ /,/

, /

,-,~~,__.,_---• PA~SIM

PASCAL

~

' ... __________________ /J/ --- _ _..,. SIMP.~\

---~

Abbildung 4.5: Diskrete Simulationssprachen

---

,1MINI: ---

PA>l'Al. PI.US