INHALTSVERZEICHNIS

INHALTSVERZEICHNIS   

1  EINLEITUNG.  1

2  VERTEILTE SIMULATION  3

2.1  Anwendungsmöglichkeiten der Simulation  3

2.2  Parallelisierung und Verteilung  4

2.2.1  Verteilung  4

2.2.2  Parallelisierung  5

2.2.3  Multitasking und Multithreading.  5

2.3  Vorgehensweise.  6

2.4  Festlegung wichtiger Begriffe  7

2.4.1  Die Begriffe Simulationszeit und Rechenzeit.  7

2.4.2  Die Begriffe Zustand und Ereignis.  8

2.5  Zeitdiskrete Simulationen.  9

2.5.1  Zeitgesteuerte Datenausgabe.  10

2.5.2  Zustandsgesteuerte Datenausgabe.  10

2.6  Zeitkontinuierliche Simulationen.  10

2.6.1  Berücksichtigung von Unstetigkeitsstellen.  11

2.6.2  Datenausgabe.  12

2.7  Unterschiedliche Simulationsverfahren.  12

2.7.1  Die Begriffe Kausalität, Kausalordnung und Konservativ.  12

2.7.2  Zeitdiskrete konservative Simulationen  12

2.7.3  Kontinuierliche konservative Simulationen.  13

2.7.4  Optimistische Simulationsverfahren.  13

2.8  Vergleich der Verfahren anhand eines Beispiels.  15

2.8.1  Aufgabenstellung.  16

2.8.2  Aufteilung in Komponenten.  16

2.8.3  Zustandsänderungen.  16

1.1.4  Konservatives Verfahren.  19

1.1.5  Optimistisches Verfahren.  21

1.1.6  Vergleich der Rechenzeiten.  23

3  DAS UNTERSUCHTE MODELL.  27

3.1  Das gewählte Beispiel.  27

3.2  Kriterien  27

3.2.1  Entkoppelbarkeit  28

3.2.2  Berücksichtigung von Ereignissen.  30

3.2.3  Integrationsverfahren nach Euler.  30

-i-

INHALTSVERZEICHNIS

3.2.4  Konservatives und optimistisches Verfahren  30

3.3  Wählbare Größen  31

3.4  Vereinfachende Annahmen  32

4  SIMULATIONSKONZEPT  33

4.1  Umwandlung der Bewegungsgleichungen.  33

4.2  Allgemeines Simulationskonzept  33

4.2.1  System.  34

4.2.2  Integrator.  34

4.2.3  Zusammenwirken von Integrator und System.  35

4.2.4  Berücksichtigung von Unstetigkeitsstellen.  36

4.3  Umsetzung für die gewählte Simulationsaufgabe  36

4.3.1  Simulationskonzept für das konservative Verfahren.  36

4.3.2  Simulationskonzept für das optimistische Verfahren.  38

4.3.3  Stoßerkennung.  39

5  EINFÜHRUNG IN CORBA  41

5.1  Die Object Mangment Group OMG.  41

5.2  Das OMA-Referenzmodell  41

5.3  Middleware CORBA.  42

5.4  Der Sortwarebus ORB  43

5.5  Die Schnittstellensprache IDL.  43

5.6  Server-Aufruf  44

5.7  Implementierung eines einfachen Beispiels  44

5.7.1  Aufgabenstellung.  44

5.7.2  Schnittstellendefinition.  44

5.7.3  Von IDL nach C  45

5.7.4  Der Server.  45

5.7.5  Der Client.  47

6  UMSETZUNG ALS CORBA-ANWENDUNG  49

6.1  Komponenten der CORBA-Anwendung  49

6.1.1  Schnittstelle Integrator.  50

6.1.2  Schnittstelle System.  50

6.1.3  Schnittstelle Animation  51

6.2  Zusammenwirken von Monitor, Integrator und System  51

-ii-

INHALTSVERZEICHNIS

7  SIMULATIONSVERSUCH.  54

7.1  Aufgabenstellung.  54

7.2  Die verwendete Soft- und Hardware  55

7.3  Versuchsdurchführung.  56

7.3.1  Vergleich der Rechenzeiten und Anzahl der Aufrufe von Calc  56

7.3.2  Vergleich der Prozessorauslastung.  61

8  ZUSAMMENFASSUNG UND AUSBLICK.  64

A  SCHNITTSTELLENDEFINITIONEN.  66

B  DIE METHODEN DER KOMPONENTEN.  68

C  VORGEHENSWEISE BEI DER SIMULATION  73

-iii-

1 Einleitung

Die Simulation ist heute ein taugliches Mittel, um reale Vorgänge nachzubilden und zu analysieren. Der Grad der Übereinstimmung zwischen Simulation und Realität hängt dabei von den berücksichtigten Parametern und der verlangten Rechengenauigkeit ab. Leider steigt mit der gewünschten Übereinstimmung aber auch der Rechenaufwand und die Rechenzeit. Um letztere zu verringern, wurden Parallelisierungsansätze entworfen, bei welchen die Rechenlast auf mehrere Prozessoren verteilt wird. Eine Möglichkeit ist es, das Modell in mehrere Teilmodelle zu zerlegen. Diese können dann unterschiedlichen Prozessoren zugeordnet werden. Die Teilmodelle werden durch einzelne Komponenten repräsentiert, die über ein geeignetes M edium miteinander kommunizieren. Ein weiterer Aspekt, der sich durch das Bilden dieser Komponenten ergeben kann, ist ein Steigern der Übersichtlichkeit und Wartbarkeit. Aus der notwendigen eindeutigen Festsetzung der Aufgaben jeder einzelnen Komponente ergeben sich überschaubare Einzelprogramme und klar definierte Schnittstellen zur Kommunikation untereinander.

Ziel dieser Arbeit soll es sein, eine v erteilte Simulation zu erstellen, deren Vorteile gegenüber einer monolithischen Simulation aufgezeigt werden. Es wurde dafür bewußt ein einfaches Beispiel gewählt, um das Augenmerk auf die verwendeten Verteilungsstrategien und nicht auf die Erklärung des Modells als mechanisches System zu lenken.

In dieser Arbeit werden zwei unterschiedliche Parallelisierungskonzepte vorgestellt. Ein w esentlicher Unterschied zwischen den beiden liegt darin, ob die Kausalordnung verletzt werden darf oder nicht. Das erste Konzepte verletzt die Kausalordnung nicht und entspricht der Definition eines konservativen Verfahrens. Das zweite Konzept entspricht der Definition eines optimistischen Verfahrens. Dafür muß die Möglichkeit einer kurzzeitigen Verletzung der Kausalordnung berücksichtigt werden, was einen gewissen Mehraufwand bedeutet. Zu beiden Konzepten ist ein Monitor implementiert worden. Die erzielten Ergebnisse in Bezug auf R echenzeit, Prozessorauslastung und verbundenen Aufwand wurden anschließend miteinander verglichen. Das gesamte Modell wurde als CORBA-Anwendung implementiert, wobei C++ als Programmiersprache genutzt wurde.

CORBA (Common Object Request Broker) ist eine sogenannte Middleware, welche zwischen Anwendung und Betriebssystem geschaltet wird. Sie ermöglicht es, einzelne Komponenten auch über Hardware- und Betriebssystemgrenzen hinaus zu nutzen und koordiniert dabei die dafür notwendige Kommunikation. Dabei hat sich der Programmierer nicht mehr um Netzwerkprotokolle oder Hardwarebesonderheiten zu kümmern. Es macht auch keinen Unterschied, ob sich die einzelnen Komponenten auf einem Rechner oder im gleichen LAN (Local Area Network) befinden oder über das Internet kommunizieren.

-1-

Das für die Simulation verwendete Modell entspricht mehreren, in Reihe hintereinander a n-geordneten Pendeln. Jedes Pendel besteht dabei aus einem Faden und einer an dessen Ende fixierten Kugel. Die Pendel können solange frei schwingen, bis sie aneinander stoßen. Im Falle eines Stoßes muß dieser nach den Gesetzen des Stoßes berechnet werden.

Der Umsetzung der Aufgabenstellung liegt ein komponentenbasiertes Simulationskonzept zugrunde, wie es in [ADA 98] beschrieben wird. Das zu erstellende Modell wurde so gebildet, daß für jedes Pendel eine eigene System- und Integratorkomponente zur Berechnung der beschreibenden Differentialgleichung und den Vorgängen beim Stoß besteht. Des weiteren existieren eine Animationskomponente zur graphischen Darstellung und eine zentrale Monitorkomponente, welche die einzelnen Komponenten koordiniert. Die Komponenten können b eliebig auf verschiedene Rechner im Netzwerk verteilt werden. Die Integratorkomponente, die Systemkomponente und die Animationskomponente wurden so ausgelegt, daß sie für beide Verfahren verwendet werden können. Die Monitorkomponente des konservativen Verfahrens unterscheidet sich von der des optimistischen Verfahrens.

Diese Arbeit wurde in Zusammenarbeit der Technischen Universität Graz, Institut für Mechanik, Univ. Prof. Kecskeméthy, und der Gerhard Mercator Universität, Fachgebiet Mechatronik, Univ. Prof. Hiller, in Duisburg erstellt.

-2-

2 Verteilte Simulation

In diesem Abschnitt soll eine Überblick über die Klassifizierung von Simulationen gegeben werden. Weiters wird auf die Besonderheiten, die sich aus der Verteilung und Parallelisierung einer Simulation ergeben, eingegangen. Einzelne Simulationsverfahren, wie das konservative und das optimistische Verfahren werden miteinander bezüglich ihrer Vor- und Nachteile verglichen.

2.1 Anwendungsmöglichkeiten der Simulation

Simulation ist eine wirksame Analysetechnik, welche auf vielen Gebieten der Technik, Wirtschaft und Wissenschaften eingesetzt wird. Sie erlaubt es, Abläufe eines realen Systems an-hand eines vereinfachten Modells zu untersuchen. Gründe für das Ersetzen eines realen Experiments durch eine Simulation sind unter anderem:

• Die Kosten des Experiments übersteigen die der Simulation meist bei weitem. Man

denke dabei nur an aufwendige Crashexperimente, wo pro Experiment ein Kraftfahrzeug investiert werden muß.

• Der Druck des Marktes erfordert immer kürzere Entwicklungszeiten. Simulation

kann ein Weg sein, die Anzahl der notwendigen Prototypen zu reduzieren, um so das Produkt schneller am Markt zu positionieren.

• Das Testen mehrerer Varianten zur Reduzierung von Kosten kann bei Produkten,

welche nur einmal erstellt werden, nicht angewendet werden. Zum Beispiel macht es wenig Sinn, ein Gebäude zweimal zu bauen, um herauszufinden, welches das günstigere gewesen wäre.

Die Leistungsfähigkeit moderner Rechner ermöglicht es, immer komplexere Modelle mit immer höherer Genauigkeit zu simulieren. Trotzdem ergeben sich auch mit leistungsstarken Prozessoren bei Simulationen, wo eine Vielzahl von Differentialgleichungen und algebraischen Gleichungen gelöst werden müssen, oft unerwünscht hohe Rechenzeiten. Der Begriff der Echtzeitsimulation, bei welcher die Rechenzeit mit der tatsächlich simulierten Zeitspanne übereinstimmt, sei in diesem Zusammenhang genannt. Echtzeitsimulationen sind zum Beispiel dort notwendig, wo eine real existierende Komponente, wie ein Regler oder eine Überwachungseinheit, mit einer am Rechner simulierten Umgebung auf dessen Funktionsfähigkeit geprüft werden soll. In diesem Fall spricht man auch von einer Hardware-in-the-Loop- Simulation.Kürzere Rechenzeiten werden aber auch vom Benutzern anderer Anwendungen verlangt, die mit der Simulationsumgebung rationell arbeiten wollen.

-3-

Möglichkeiten zur Reduzierung von Rechenzeit gibt es sowohl auf programmtechnischer als auch auf hardware-Ebene. Das Entwickeln schnellerer Algorithmen oder das Verwenden besserer, meist hardwarebezogenerer Compiler, gehören zum Bereich der programmtechnischen Möglichkeiten. Leistungsfähigere Prozessoren, schnellere Speicher und bessere Bussysteme reduzieren die Rechenzeit ebenfalls und zählen zu den Möglichkeiten auf hardware-Ebene.

Um Rechenzeit zu reduzieren, wäre ein weiterer Ansatz, die Leistungsfähigkeit mehrerer Pro-zessoren für die Bewältigung einer Simulationsaufgabe zu nutzen. Eine Möglichkeit dazu ist es, rechenintensive Hilfsfunktionen, wie zum Beispiel das Generieren gut verteilter Zufallszahlen, oder die Berechnung von Fließkommaoperationen auf eigene Prozessoren auszulagern. Das Konzept wurde zum Beispiel bei den Prozessoren INTEL 8086 bis INTEL 80386 verwirklicht. Bei diesen Prozessoren ist es möglich, ihnen einen Hilfsprozessor für Fließkommaoperationen zur Seite zu stellen. In den folgenden Prozessoren dieser Serie, von 80486 aufwärts, wurden die Funktionen des Hilfsprozessors bereits im Hauptprozessor integriert. Das im nächsten Abschnitt vorgestellte Verfahren der Parallelisierung geht einen bedeutenden Schritt weiter. Da es auch in dieser Arbeit angewendet wird, soll darauf etwas genauer eingegangen werden.

2.2 Parallelisierung und Verteilung

2.2.1 Verteilung

Grundgedanke der Verteilung ist es, die Funktionalität in Komponenten zu kapseln. Das Aufteilen in klar definierte Einheiten steigert dabei die Übersichtlichkeit. Jeder Komponente wird eine bestimmte, klar definierte Aufgabe übertragen. Die Komponente empfängt Daten als Eingangsgrößen, verarbeitet sie und stellt anschließend von ihr berechnete Daten anderen Komponenten zu Verfügung.

Bei dem in dieser Arbeit verwendeten Verfahren, wo CORBA als Middleware eingesetzt wird, können Komponenten genutzt werden, ohne daß sich der Anwender über deren internen Aufbau G edanken machen muß. Ist ihm bekannt welche Eingangsgrößen die Komponente verlangt und welche Ausgangsgrößen sie daraus errechnet, so kann er sie nutzen. Bei einer CORBA-Anwendung kann die Komponente bereits in kompilierter Form vorliegen. Nur der Code der Schnittstelle, eine Datei welche die Ein- und Ausgangsgrößen festlegt, muß dem Anwender bekannt sein. Dabei wird klar, daß auch Komponenten, welche in unterschiedlichen Programmiersprachen programmiert wurden, zusammenwirken können.

-4-

2.2.2 Parallelisierung

Eine Parallelisierung liegt vor, wenn die Prozesse gleichzeitig abgearbeitet werden. Geht man von einem System mit den Komponenten K i (i=1...k) aus und laufen in jeder Komponente die zugehörigen logischen Prozesse LP i,j (j=1...p), so müssen zwei Arten der Parallelisierung unterschieden werden. Die Parallelisierung kann intern in der Komponente erfolgen, wie es auch bei jeder monolithischen, nicht verteilten Anwendung möglich ist. Dabei rechnen die Prozesse einer Komponente gleichzeitig. LP i,1 bis LP i,p laufen i n diesem Fall zumindest teilweise gleichzeitig ab. Der Vorgang wird entweder als Multithreading oder Multitasking, je nach Grad der Unabhängigkeit der einzelnen Prozesse bezeichnet. Im folgenden Abschnitt wird auf beide Konzepte eingegangen.

Kennzeichnend für eine Parallelisierung, wie sie bei verteilten Systemen üblich ist, ist jedoch die Tatsache, daß auch Prozesse unterschiedlicher Komponenten gleichzeitig ausgeführt werden. Verteilter Systeme sind dadurch gekennzeichnet, daß sich die Parallelisierung über Prozesse unterschiedlicher Komponenten, im allgemeinsten Fall, von LP 1,1 bis LP k,p , erstreckt.

In dieser Arbeit erfolgte die Parallelisierung dadurch, daß in einer Komponente, dem Monitor, das Verfahren des Multithreadings angewandt wird. Den restlichen Komponenten ist jeweils nur ein Prozeß zugeordnet. Bei der Simulation rechnen auch Prozesse unterschiedlicher Komponenten gleichzeitig, wie es für eine Parallelisierung bei verteilten Systemen kennzeichnend ist.

Die Koordination des Ablaufes dieser P rozesse kann auf verschiedene Weise realisiert werden. Zwei Möglichkeiten dazu, das konservative Verfahren und das optimistische Verfahren, werden in dieser Arbeit vorgestellt.

2.2.3 Multitasking und Multithreading

Beide Konzepte, das Multitasking und das Multithreading, bieten die Möglichkeit der Parallelisierung mehrerer Programme auf einem Rechner. Da beide Konzepte in dieser Arbeit verwendet wurden, soll auf sie kurz eingegangen werden.

Als Task bezeichnet man ein ausführbares Programm, welches vom Anwender oder von einem anderen Programm gestartet wird. Multitasking-fähige Betriebssysteme bieten nun die Möglichkeit, mehrere solche Tasks parallel auszuführen. Windows 95 und Windows NT geht dabei folgendermaßen vor: Jedem Task wird eine gewisse Anzahl von Zeittakten zugeteilt. Daraus ergibt sich eine Zeitscheibe, welche die Zuteilung der Prozessorzeit regelt. Nach A blauf der zugeteilten Prozessorzeit wird der laufende Prozeß vom Betriebssystem gestoppt, alle notwendigen Informationen werden abgelegt, und der n ächste anstehende Prozeß wird in den

-5-

Speicher geladen. Das Verfahren des Multitaskings kommt zum Beispiel immer dann zur Anwendung, wenn mehrere Komponenten auf einem Rechner gestartet werden. Im Simulationsversuch von Abschnitt 7 wird jeweils eine Systemkomponente und eine Integratorkomponente auf einem Rechner gestartet. Das Zeitscheibenverfahren teilt nun den Prozessen der beiden Komponenten ihren Anteil an der Prozessorzeit zu.

Multithreading erlaubt es, einen Prozeß in Threads aufzuteilen. Beim herkömmlichen Programmablauf ohne der Verwendung von Threads wird nach Aufruf eines Unterprogrammes solange gewartet, bis das Unterprogramm abgearbeitet worden ist. Erst anschließend wird der Programmablauf mit dem nächsten Befehl des aufrufenden Programmes fortgesetzt. Durch die Verwendung von Threads ist es möglich, mehrere Unterprogramme parallel zu starten. Jedem Thread kann dabei eine unterschiedliche Priorität zugeteilt werden. Dadurch ist es im Programm zum Beispiel möglich, Tätigkeiten von geringerer Wichtigkeit auf Zeiten zu verlegen, in denen der Anwender keine Eingaben macht. Die Eingabe des Anwenders kann ohne Behinderung erfolgen.

Ein wesentlicher Unterschied von Multitasking und Multithreading liegt geringeren Grad der Unabhängigkeit, welchen die Threads gegenüber den Prozessen haben. Während zum Beispiel jedem Prozeß sein eigener Adressenraum zugeteilt wird, benutzen alle Threads eines Prozesses den gleichen Adressenraum. Für eine detailliertere Darstellung der Vorgänge sei auf [TAN 95] und [ BUR 93] verwiesen. [ BAC 98] geht auf die Realisierung Multitaskingfähiger und Multithreading-fähiger Programme mit Windows 95 und Windows NT näher ein.

2.3 Vorgehensweise

Die folgende Aufzählung soll die notwendigen Schritte für die Realisierung einer verteilten Anwendung aufzeigen.

1) Festlegen der einzelnen Komponenten

Die Komponenten sollten so gewählt werden, daß sie einerseits nicht zu komplex sind und andererseits die Kommunikation zwischen den Komponenten nicht zu aufwendig wird. Üblicherweise ist es so, daß je einfacher die Komponenten gewählt werden, um so geringer ist die Rechenzeit für einen einzelnen Rechenschritt. Andererseits steigt jedoch die Menge der auszutauschenden Daten zwischen den Einheiten und somit auch die Zeit, d ie für Kommunikation benötigt wird. Die Anzahl der zur Verfügung stehenden Prozessoren kann auch eine Basis für eine sinnvolle Unterteilung bilden. Bei voneinander stark abhängigen Komponenten kann es aber durchaus sinnvoll sein, sie einem gemeinsamen Prozessor zuzuordnen. Bei vielen Modellen, wie auch bei dem später behandelten mechanischen System, bieten die mechanischen

-6-

Einheiten eine gute Grundlage für die am Rechner modellierten Komponenten.

2) Definition der Schnittstellen

Die Prozesse der Komponenten müssen in der Lage sein, über ein geeignetes Kommunikationsmedium Daten untereinander auszutauschen. In Abschnitt 5 wird ein solches Kommunikationsmedium, in diesem Fall CORBA, vorgestellt. Welche Daten das sind, und wie sie ausgetauscht werden, wird über die Schnittstellendefinition festgelegt. Dazu wird ein in einer Schnittstellendefinitionssprache verfaßter Code benötigt, welcher als Schnittstelle bezeichnet wird. Dieser Code wird für alle Komponenten, welche miteinander kommunizieren wollen, in die der Komponenten entsprechenden Programmiersprache mittels eines Schnittstellencompilers umgesetzt. Der Schnittstellencompiler erstellt dabei nicht ein lauffähiges Programm, sondern Quellcode in der Programmiersprache der gewünschten Komponente. Den Vorgang bezeichnet man als Schnittstellenmapping. Dieser Code kann von der entsprechenden Komponente eingebunden werden.

3) Implementierung der einzelnen Komponenten

Nach dem Einbinden des vom Schnittstellencompilers in der gewünschten Programmiersprache erstellten Codes ist es möglich, das gesamte Programm in dieser Sprache fertigzustellen. Der Programmierer muß sich dafür nicht mit dem vom Schnittstellencompiler erstellten Code befassen. Es genügt, wenn er die Schnittstellendefinition kennt und weiß, welche Methoden sich daraus für die Implementierung ergeben.

2.4 Festlegung wichtiger Begriffe

2.4.1 Die Begriffe Simulationszeit und Rechenzeit

Die Simulationszeit t gibt an, welcher Zeitpunkt der Simulation gerade betrachtet wird. Sollen zum Beispiel die Wetterveränderungen eines Tages simuliert werden, dann könnte der Simulationszeitpunkt des Sonnenaufganges mit t Sonnenaufgang =7h festgelegt werden. Davon zu unterscheiden ist die Rechenzeit T. Sie gibt an, wie lange der Computer benötigt, um zu einem bestimmten Simulationszeitpunkt zu gelangen. Die Rechenzeit hängt also von der Geschwindigkeit des verwendeten Computersystems ab. Braucht das System für die gesamte Simulation drei Sekunden, so gilt, daß T gesamt =3s ist. Die Rechenzeit bis zum Sonnenaufgang könnte bei T Sonnenaufgang =1s liegen.

Es soll vereinbart werden, daß es sich bei Zeiten, welche mit kleinem t bezeichnet werden,

-7-

immer um die Angabe einer Simulationszeit handelt. Bei Zeiten, welche mit großem T b ezeichnet werden, handelt es sich um Rechenzeiten.

2.4.2 Die Begriffe Zustand und Ereignis

Unter dem Zustand eines Systems versteht man die Gesamtheit aller zum Simulations- ) (t Z

zeitpunkt t gehörenden Werte, welche das simulierte System so beschreiben, daß die Simulation von diesem Simulationszeitpunkt ohne Kenntnis vorheriger Werte fortgesetzt werden

kann. Im Falle eines mechanischen Systems kann keiten angegeben werden. Die Schreibweise

Rechenschritt betrachtet werden soll. Bei einfacher Vorwärtsintegration, wie sie in dieser A rbeit verwendet wurde, soll

⋅ + = Z m ( 2.1 ) ) ( 0 h m t Z

gelten. Dabei steht h für die Schrittweite und 0 t für den Startzeitpunkt.

Die zu Z gehörenden Werte können nun den einzelnen Komponenten zugeordnet werden. ) (t

Es soll für die folgenden Betrachtungen festgelegt werden, daß eine Matrix mit den ) (t Z Werten t z , ) ( ist, wobei i den Bezug zur Komponente K i herstellt und j ein laufender Index

i j

für die einzelnen Werte der Komponente darstellt. Er soll die Werte von 1 bis w der Maximalanzahl der Zustandswerte, die eine Komponente besitzt, annehmen können. Für Komponenten, die weniger als w Zustandswerte beinhalten, sollen die restlichen Werte auf 0 g esetzt werden. Komponenten welche keine Zustandswerte besitzen werden nicht in die Matrix aufgenommen. Das Zusammenfassen der Zustandswerte in Matrix-Form erscheint sinnvoll, wenn sich die Komponenten einer Anwendung ähnlich sind. Ist dies nicht der Fall so wird der Zustand über einen Spaltenvektor, welcher die Zustandswerte aller Komponenten aufnimmt, festgelegt.

Für die weiteren Betrachtungen sollen die Spaltenvektorn

zugeordneten Werte aufnehmen. Mit dieser Vereinbarung soll )

angeschrieben werden.

Bei den Ereignissen muß zwischen Zustandsereignissen und Zeitereignissen unterschieden

-8-

werden. Ein Ereignis, das vom Zustand des Systems abhängt, wird Zustandsereignis genannt. Zur Bestimmung eines Zustandsereignisses können dabei alle bekannten Zustandswerte h erangezogen werden. Hängt ein Ereignis nicht vom Zustand des Systems ab, sondern von einer vorgegebenen Simulationszeit, so nennt man dieses Ereignis Zeitereignis. Da der Zeitpunkt im voraus bekannt ist, läßt sich ein Zeitereignis wesentlich effizienter behandeln als ein Z u-standsereignis. Durch das Auswerten eines Ereignisses können unterschiedliche Aktionen gesetzt werden. Das Ausgeben von Daten und das Ändern von Zustandswerten soll im folgenden behandelt werden.

Ereignisse e i,j,n werden so indiziert, daß der Index i für die Komponente, die es erzeugt und j für die Komponente, für die das Ereignis bestimmt ist, stehen. Der Index n gibt als fortlaufender Index an, um das wievielte Ereignis der Komponente K i es sich handelt. Der mit dem Ereignis verbundene Simulationszeitpunkt soll als Zeitstempel t * i,j,n festgelegt werden. Die E reignisse e i,j,n einer Komponente K i können also über den Index n nach ihren Zeitstempeln ge-ordnet werden.

2.5 Zeitdiskrete Simulationen

Kennzeichnend für zeitdiskrete Systeme ist, daß sich der neue Zustand als Funktion des vorherigen über die Gleichung

⁺ = 1 m ( 2.3 ) ) ( Z f Z

bestimmen läßt. Das Voranschreiten der Zeit erfolgt sprunghaft. Der gesamte Simulationsablauf beschränkt sich auf das Generieren, das Übermitteln und das Auswerten von Ereignissen. Dafür wird für jede Komponente K i eine Ereignisliste EL i angelegt. Die Aufgaben der logischen Prozesse LP i,j , welche der Komponente K i zugeordnet sind, können in drei Bereiche aufgeteilt werden. Die Verwendung von x anstelle von j bei der Indizierung der Ereignisse, soll darauf hindeuten, daß jede beliebige Komponente, auch die Komponente K i, selbst, im System damit gemeint sein kann. Schließlich ist es ja auch denkbar, daß ein Komponente Ereignisse für sich selbst generiert.

• Entgegennehmen aller Ereignisse e x,i,n , und Eintragung in die EL i

• Auswertung der e x,i,n und Generierung der e i,x,n für sich selbst und die übrigen Kom-

ponenten. Nach der Auswertung werden die e x,i,n aus der EL i gestrichen.

Die LP i,j werten ein Ereignis e x,i,n mit dem Zeitstempel t * x,i,n aus. Dadurch wird der Zustandsvektor der Komponente K i berechnet. Der Vorgang entspricht der ) * ( i t z

, n i x

-9-

oben abgeführten Gleichung. Auf Grund des geänderten Zustandsvektors müssen die LP i,j in der Lage sein, zu erkennen, welche neuen Zustandsereignisse e i,x,n zu generieren sind.

• Übermittlung der e i,x,n , für die gilt (x←i) an die übrigen Komponenten und Eintra-

gung der e i,i,n in die eigene EL i

Um die Ergebnisse einer Simulation dem Anwender sichtbar zu machen, muß der Zustand der einzelnen Komponenten ausgegeben werden. Um dies zu tun, gibt es zwei verschieden Konzepte, welche als zeitgesteuerte und als zustandsgesteuerte Datenausgabe bezeichnet werden.

2.5.1 Zeitgesteuerte Datenausgabe

∆ ein Z eit-Bei der zeitgesteuerten Datenausgabe wird in festgesetzten zeitlichen Abständen t

ereignis ez j,n mit dem Zeitstempel tz *

^{* *} }. Da schon zu Beginn der Simulation alle diese Zeitereignisse feststehen, können sie t i,j,n

auch schon zu Beginn in die entsprechende EL i eingetragen werden. Die Ereignisse werden also nicht von einer anderen Komponente generiert, weshalb auch kein Index für die generierende Komponente vorgesehen ist. Der Anwender bekommt durch dieses Verfahren die Folge

∆ ⋅ + ∆ + von Zuständen ),... 2 ( ), ( ), ( t z t z t z ausgegeben.

0 i

2.5.2 Zustandsgesteuerte Datenausgabe

Bei der zustandsgesteuerten Datenausgabe werden bei der Auswertung bestimmter, vom A nwender festgesetzter Zustandsereignisse die Zustandswerte ausgegeben. Es gibt also keine gesonderten Zeitereignisse für die Ausgabe des Zustandes der Komponente. Die LP i,j der Komponente K i legen über einen geeigneten Selektionsprozeß fest, nach welchen Ereignissen eine Ausgabe erfolgen soll. Der Vorteil solch eines Verfahren ist es, daß keine Daten für Totzeiten, daß sind Zeiten wo kein einziges Ereignis stattfindet, ausgegeben werden.

Natürlich ist auch eine Kombination beider Verfahren möglich. In dieser Arbeit wird eine zeitgesteuerte Datenausgabe verwendet.

2.6 Zeitkontinuierliche Simulationen

Zeitkontinuierliche Simulationen sind dadurch gekennzeichnet, daß sie versuchen, eine stetige

( ) Z = t f t ) ( Änderung des Zustandes durch ein geeignetes Verfahren zu simulieren. Dazu ist

ein Integrationsverfahren notwendig. Das einfachste Integrationsverfahren ist das die einfache

-10-

Vorwärtsintegration, welche auch Euler-Integration genannt wird. Bei diesem Verfahren kann die stetige Veränderung des Zustandes durch

pro Schritt angenähert werden. Der Wert h entspricht dabei der gewählten Schrittweite.

Alle Systeme, welche durch ein System von gewöhnlichen Differentialgleichungen ¹ und a lgebraischen Gleichungen vollständig beschrieben werden können, wie zum Beispiel mechanische Systeme ohne Blockiervorgänge, ohne Stoßvorgänge und ohne einseitigen Bindungen können als kontinuierliche Simulation simuliert werden.

Es gibt unterschiedlich aufwendige Integrationsverfahren um kontinuierliche Simulationen durchzuführen, gemeinsam ist ihnen jedoch, daß sie alle das stetige Voranschreiten der Zeit durch endlich kleine Zeitschritte annähern.

2.6.1 Berücksichtigung von Unstetigkeitsstellen

Z = Bei zeitkontinuierlichen Systemen ist nicht stetig. Es muß ein Weg gefunden wer- ) ( ) ( t f t

den die Unstetigkeitsstellen zu berücksichtigen. Eine Möglichkeit ist es, dies mittels Ereignissen zu tun. Die Auswertung dieser Ereignisses kann bei solch einem Modell Zustandswerte sprunghaft ändern. Denkbar wären auch Ereignisse, die es ermöglichen den Zustandsvektor ) (t z i in seiner Dimension zu ändern. Die Anzahl der unabhängigen Zustandswerte kann sich z.B. ändern, wenn es in einem System einseitige Bindungen gibt. Da für diese Arbeit nur das Problem der Unstetigkeitsstellen von Bedeutung ist, soll nur darauf eingegangen werden.

= ^{] , [} z b a Dafür sollen die Funktionen ) ( ) ( t f t z i in stetige Abschnitte ) ( t aufgeteilt werden,

, j , i j

wobei a den Simulationszeitpunkt für den Startpunkt und b den Simulationszeitpunkt für den

− ^{] [} z u Endpunkt des stetigen Bereichs angibt. Für Unstetigkeitsstellen soll die Indizierung ) ( t

, i j

für den Grenzwert vor Erreichen der Unstetigkeitsstelle (linksseitiger Grenzwert) zum Simu-

lationszeitpunkt u und legt werden. Der Verlauf von

für stetige Bereiche und

¹ Als Differentialgleichungen sollen hier solche gemeint sein, welche Ableitungen nach der Zeit beinhalten.

-11-

für die Unstetigkeitsstellen, zusammengesetzt werden.

Bei einem kontinuierlichen System mit Ereignissen müssen die LP i,j der Komponenten also sowohl die Aufgabe der Integration in den stetigen Bereichen als auch die Aufgabe des Generieren und Auswerten von Ereignissen bei Unstetigkeitsstellen erfüllen.

2.6.2 Datenausgabe

Die Datenausgabe wird bei kontinuierlichen Systemen üblicherweise in festgesetzten Zeitschritten, ausgelöst durch Zeitereignisse, wie sie schon bei den diskreten Simulationen erläutert wurden, erfolgen.

2.7 Unterschiedliche Simulationsverfahren

Um die beiden im folgenden vorgestellten Simulationsverfahren unterscheiden zu können, ist es notwendig, zuerst die Begriffe Kausalordnung, konservativ und Garantie zu erörtern. Die Begriffe sollen zuerst anhand diskreter Systeme erörtert werden.

2.7.1 Die Begriffe Kausalität, Kausalordnung und Konservativ

Unter Kausalität versteht man, daß das Auswerten der Ereignisse in der Folge entsprechender Zustandsänderungen erfolgt. Diese Zustandsänderungen bewirkt wiederum neue Ereignisse, welche mit einem Zeitstempel versehen, in eine neue Reihenfolge eingegliedert werden. Diese Reihenfolge bezeichnet man als Kausalordnung. Ein Verfahren, welches diese Kausalordnung nie verletzt, wird als konservativ bezeichnet.

2.7.2 Zeitdiskrete konservative Simulationen

Bei Systemen wo eine Abhängigkeit zwischen den Komponenten besteht, gibt es die Möglichkeit, über die Vergabe von Garantien einen konservativen Verlauf für die Simulation s icherzustellen. Dafür soll der Begriff der Garantie genauer erörtert werden.

Jedes System ist dadurch gekennzeichnet, daß man Abhängigkeiten zwischen den Komponenten festlegen kann. Eine Abhängigkeit a i,j entsteht dann, wenn es während der Gesamtzeit der Simulation nicht auszuschließen ist, daß die Komponente K i für die Komponente K j ein E reignis erzeugt. Es soll dabei a i,j =1 gelten, wenn eine Abhängigkeit besteht, und a i,j =0 wenn

-12-