Home

- Simplex3

1. Kunde Bank B ae D c V B gt G Einzahlung G gt V Schuldzinsen G gt B Auszahlung V gt G Guthabenzinsen Da das Girokonto sowohl dem Kunden wie der Bank zugeordnet ist k nnen beide beliebig dar ber verf gen So kann der Kunde nach Belieben seinen Kreditrahmen berziehen ohne da die Bank sich davor sch tzen kann Die Bank kann sich nicht einmal davor sch tzen da ein Fremder ihr Verm gen angreift Nicht nur zur Herstellung der Eindeutigkeit auch zum Schutz von Best nden gegen unkon trollierbare fremde Zugriffe ist es sinnvoll einer Komponente bei Bedarf mehr Autonomie zu verleihen 168 4 Transporte zwischen Best nden 4 6 Transportbezogene Modularisierung mit Teilautonomie Die bestandsbezogene Beschreibung von Transporten orientierte sich an der klassischen Sy stemtheorie und an deren Modellbeschreibung durch Definitionsgleichungen Dadurch war stets die vollst ndige Autonomie einer Komponente sichergestellt Die transportbezogene Beschreibung hingegen erfordert f r den Austausch von Elementen zwischen Komponenten einen freien Zugriff auf die Best nde Die Autonomie f r Best nde ist also nicht gegeben Wir sahen Beispiele wo dies von Vorteil war aber auch solche wo sich dies als nachteilig herausstellte Daher erscheint es angebracht danach zu fragen wieso sich so unterschiedliche Anforderun gen an die Autonomie ergeben Autonomie besagt d
2. R R Exit Q Queue Reservoir d Ftit R Reservoir Exit Q s Exit Q Exit S Server i Exit A o Queue Server Unsch n bleibt lediglich da die Pfeile welche die Komponenten verbinden nach wie vor entgegen der Transportrichtung weisen Aber auch dieses Problem wird im n chsten Kapitel behoben 3 7 4 Methodologische Gesichtspunkte Anf nglich wurde der Aufenthaltsort einer mobilen Komponente durch eine ihrer Zustands variablen bestimmt Eine Warteschlange wurde als Menge mobiler Komponenten aufgefa t bei denen diese Zustandsvariable den gleichen Wert besitzt Mengenvariablen die durch Zuordnung einer derartigen geordneten Eigenschaftsmenge definiert wurden und Warte schlangen repr sentierten waren daher abh ngige Variablen Mit der Einf hrung der Location wurde der mobilen Komponente die Zustandsvariable ent zogen die den Aufenthaltsort bestimmt Diese Information ber den Modellzustand wird nun durch die Inhalte der Locations festgelegt Im Sinne der Informatik verk rpern Locations Variablen die Listen von Modellobjekten mobilen Komponenten verk rpern und nicht wie bisher f r singul re Werte stehen Die traditionelle systemtheoretische Beschreibungsform die den Modellzustand allein durch At tribute beschreibt wird damit verlassen und durch einen neuen Variablentyp die geordnete Menge Location erg nzt Die Richtung der Zuordnung wurde umgekehrt Bisher war jeder mobil
3. Beschreibung des Transports in K1 EMPTY Server LET Queue Job 1 gt Server END Ebenso wie bei der bestandsbezogenen Beschreibung treten beim Transport von individuellen Elementen Probleme mit der Eindeutigkeit auf Es ist m glich da beide Komponenten gleichzeitig ver ndernd auf dasselbe Element im Bestand B_2 zugreifen Dies kann nicht nur zur Ausf hrung eines Transportes sondern auch zum Setzen eines Attributes geschehen Damit im praktischen Betrieb kein Zugriffskonflikt auftreten kann w re eine genaue Abstimmung zwischen den Komponenten notwendig Die Ursache f r einen m glichen Konflikt liegt darin da ein Bestand gleichberechtigt beiden Komponenten zugeschlagen wird und diese daher ber die gleichen Zugriffsrechte verf gen Keine der beiden Komponenten kann ber die quivalenzierten Best nde autonom verf gen 4 5 Modularisierung 165 Wie der nachste Abschnitt zeigt kann durch eine teilweise Wiederherstellung der Autonomie das Eindeutigkeitsproblem gel st werden F r die bestandsbezogene Beschreibung hingegen konnte eine derartige L sung nicht gefunden werden F r Transporte mit gleichartigen Elementen liegt bereits ohne weitere Erg nzungen eine ideale Beschreibungsform vor In diesen F llen stellt die Eindeutigkeit kein Problem dar Insbesondere f llt auf da es keine unsymmetrischen L sungen mehr gibt und daher jede m gliche Art der Modellierung f r die Anwendung des Klassenkonzepts gut g
4. Teilmengen von Warteschlangen zu bilden die Anzahl von Elementen einer Warteschlange festzustellen auf einzelne Elemente aus einer Warteschlange ber ihre Position selektiv zuzugreifen Eine alternative Sicht der Warteschlange ist es nur das Einreihen nach angegebenen Ord nungskriterien vorzunehmen und die dadurch geschaffene Ordnung aufrecht zu erhalten ndert sich ein Attibut eines Elements aus dieser Warteschlange so f hrt das nicht zu ei ner nderung der bestehenden Ordnung F r diese Art von Warteschlange w re es denkbar die Einreihung nach einem an die Warteschlange gebundenen Kriterium vorzunehmen oder beim Einreihen individuell die Position zu bestimmen an die das Element gebracht werden soll Beide M glichkeiten k nnen auch nebeneinander zur Anwendung kommen Eine besondere Beachtung verdient die Selektion von Elementen aus einer Warteschlange Die Kriterien k nnen sehr vielf ltig sein und dennoch sollte sich die Selektion verst ndlich in der Modellbeschreibungssprache formulieren lassen Folgende Beispiele sind typisch f r die Selektion aus Warteschlangen bzw Warter umen Zugriff auf den ltesten Auftrag in der Warteschlange FIFO Zugriff auf den j ngsten Auftrag in der Warteschlange LIFO Zugriff auf den ltesten Auftrag der eine bestimmte Eigenschaft erf llt z B im Arbeitsspeicher noch Platz findet Zugriff auf die f nf ltesten Teile in der Warteschlange z B Sammelstat
5. Die zun chst teilweise impliziten Modellgleichungen uU Rii u R i Ug Uy U2 0 u sin t lassen sich in das scheinbar explizite Gleichungssystem i w R ifu uz R i usli Ul Ug Ug tl uq u sin t umformen Der dazugeh rige Abh ngigkeitsgraph hat das folgende Aussehen 1 0 0 Die vorgenommene Umformung ist zwar quivalent aber nicht zyklenfrei Der Abh ngigkeitsgraph erm glicht uns demnach die berpr fung einer korrekten Semantik Es gilt daher Eine explizite Modellbeschreibung ist dann semantisch korrekt wenn f r jeden Modellzu stand X t Y t Z t t die folgenden Bedingungen erf llt sind 1 F r jede Modellgr e mu mindestens eine Definitionsgleichung angegeben sein 2 Der durch die Definitionsgleichungen gegebene Abh ngigkeitsgraph mu zyklenfrei sein 3 F r jede Modellgr e darf h chstens eine Definitionsgleichung angegeben sein 36 2 Sprachentwurf im Sinne der klassischen Systemtheorie Die erste und zweite Bedingung sichern die Vollst ndigkeit der Modellbeschreibung die dritte Bedingung stellt die Eindeutigkeit sicher und verhindert damit da weitere eventuell widerspr chliche Aussagen hinzukommen Die erste und dritte Bedingung l uft nat rlich darauf hinaus da f r jede Modellgr e genau eine Definitionsgleichung anzugeben ist Beispiele a Y Y Yo Yi Y di 2Y In beiden F llen enth lt
6. T TGenera T TBetween END END END Hiermit w re nun die Voraussetzung geschaffen um die Beschreibung der drei Bewegungen auf drei Komponenten zu verteilen Leider hat diese Umformung den Preis da keine Ein deutigkeit mehr gew hrleistet ist Der menschliche Betrachter ist zwar schon in der Lage zu erkennen da die drei Indexmengen in den IF Zweigen disjunkt sind weil das Attribut Ort drei verschiedene Auspr gungen annimmt ein Compiler jedoch kann diese Aufgabe im allgemeinen nicht bernehmen Um berhaupt eine Modularisierung durchf hren zu k nnen verzichten wir vorl ufig auf die Uberpr fung der Eindeutigkeit zur Compile Zeit und beschr nken uns auf eine Fehlererken nung zur Laufzeit in einer konkreten fehlerhaften Situation Der erste Versuch einer modularen Modellzerlegung nimmt folgende Gestalt an Da einer Komponente nicht bekannt ist wohin es ein Element schicken soll wenn der Ort in einer fremden Komponente liegt sind Sensorvariablen einzuf hren um diese Informationen zu beschaffen F r jede Komponente wird eine Sensorvariable Exit und eine Zustandsvariable Entrance vereinbart Da nicht vorgesehen ist da Sensorvariablen mit Werten z B Server verbunden sind m ssen auch noch Zustandsvariable eingef hrt werden deren Aufgabe nur darin liegt das Ziel an welches das mobile Element zu verschicken ist mitzuteilen 110 3 Spracherweiterungen zur Formulierung von Warteschlangenmodellen EF
7. 0 STATE VARIABLES TGenera REAL 0 Queue SET OF Job INC TEntry O Job Server SET OF Job O Job Reservoir SET OF Job 100 Job RANDOM VARIABLE TBetween REAL EXPO Mean 10 DYNAMIC BEHAVIOUR Bewegung von Queue nach Server FOREACH J IN Queue Job 1i LET IF EMPTY Server LET J gt Server J TEntry T END END Bewegung von Server nach Reservoir FOREACH J IN Server Job 1 LET IF T gt J TEntry TService LET J gt Reservoir J TEntry T END END 124 3 Spracherweiterungen zur Formulierung von Warteschlangenmodellen Bewegung von Reservoir nach Queue FOREACH J IN Reservoir Job 1 LET IF T gt TGenera LET J gt Queue J TEntry T TGenera T TBetween END END Da sichergestellt ist da eine mobile Komponente nur in einer einzigen Location enthalten ist darf die Beschreibung des Modellverhaltens auf mehrere FOREACH Konstrukte verteilt werden ohne da dadurch die Eindeutigkeit verletzt werden k nnte 3 7 3 Modularisierung mit Locations Eine modulare Zerlegung dieses Modells ist nun fast ohne Abstriche an die gestellten Anfor derungen m glich MOBILE COMPONENT Job DECLARATIONS STATE VARIABLE TEntry REAL 0 END OF Job zo SS eS Se a ee Se Se ee eS Komponente Q Sao Io LS SS E SS Se SS eS Se eos 3 Se SS Se eS SS Se Se STATE VARIABLE Queue SET OF Job INC TEntry 0 Job SENSOR VARIABLE Exit SET OF Job Bewegung von Queue nach
8. Best nde sind disjunkte geordnete Mengen und deshalb kann ber sie auf die mobilen Ele mente eines Modells eindeutig zugegriffen werden Wir k nnen vier verschiedene Zugriffs rechte auf Best nde unterscheiden Leserecht Schreibrecht Bringerecht Holerecht F r Best nde mit gleichartigen Elementen entf llt die M glichkeit zu schreiben Eine Komponente kann private Best nde oder zug ngliche Best nde vereinbaren ber pri vate Best nde besitzt sie volle Autonomie d h sie besitzt alle Rechte w hrend andere Kom ponenten berhaupt keine Rechte mit Ausnahme des Leserechts besitzen Exklusivrechte Zug ngliche Best nde dienen dem Austausch von Elementen zwischen Komponenten Meh rere Komponenten teilen sich einen Bestand und verf gen ber gewisse Rechte die einen Transport m glich machen 5 2 Deklaration in Basiskomponenten und mobilen Komponenten 195 Eine Komponente kann ihre Autonomie iiber einen Bestand teilweise abtreten indem sie auf eigene Rechte verzichtet und oder anderen Komponenten ebenfalls Rechte einr umt Je nachdem wieviel eine Komponente von ihrer Autonomie abtritt k nnen Best nde mit unterschiedlichen Attributen deklariert werden Wir unterscheiden Best nde mit folgenden Rechten private Best nde PRIVATE L WA S WK B WK H WK Durchgangsbest nde TRANSIT L WA S WA B WA H WA Ausgangsbest nde EXIT L WA S VA B WA_ H VA Eingangsbest nde ENTRY L WA S WK B
9. Dieses Kapitel stellt weitere Betrachtungen zur Transportoperation an Es soll herausgefun den werden ob eine einheitliche Beschreibung von Transporten m glich und sinnvoll ist Dabei d rfen d rfen die Anforderungen wie e Eindeutigkeit der Beschreibung e Erhaltung der mobilen Elemente e nicht negative Best nde e Autonomie der Komponenten bei modularer Zerlegung e Verst ndlichkeit und Kompaktheit der Beschreibung nicht aus den Augen verloren werden 4 1 Motivation Das folgende Beispiel wiederum ein M D 1 Modell soll zeigen wie man mit den klassi schen Mitteln siehe Kapitel 2 ein Warteschlangenmodell beschreiben kann wenn man nicht zwischen einzelnen individuellen Elementen unterscheiden mu 130 4 Transporte zwischen Best nden In diesem Fall l t sich eine Warteschlange durch einen einfachen Z hler repr sentieren der anzeigt wieviele Elemente in der Warteschlange enthalten sind Es sei NR Anzahl Elemente im Reservoir NQ Anzahl Elemente in der Queue NS Anzahl Elemente im Server Die Modelldynamik l t sich hiermit folgenderma en formulieren Bewegung von Queue nach Server ac s22snossa 2222 2 2sase IF NQ gt O AND NS 0 LET ng NQ 1 NS NS 1 TEntry T END ELSIF NS gt O AND T gt TEntry TService LET NS NS 1 NR NR 1 END Bewegung von Reservoir nach Queue a a a a a a a ie ELSIF T gt TGenera LET NR NR
10. IDXSET selected_location condition expression criteria_list ordering_criterion ordering_criterion ordering_criterion INC expression DEC expression TRUE expression FALSE expression Im Gegensatz zur Deklaration von Best nden darf ein Ordnungskriterium hier ein Ausdruck sein der beliebige Variablen des Modells miteinander verkn pft a 5 4 H here Komponenten 205 Da Best nde bereits mit einer Ordnung versehen wurden erh lt man aus einem durch eine Bedingung reduzierten Bestand wiederum eine geordnete Menge Eine Neuordnung durch Angabe eines Kriteriums ist aber dennoch m glich 5 3 10 Verkn pfen von Best nden mit unterscheidbaren Elemen ten F r die Bildung von Eigenschaftsmengen sind Verkn pfungen Bestand x Bestand Menge von Best nden mit unterscheidbaren Elementen interessant die wiederum Mengen von un terscheidbaren Elementen erzeugen Als Verkn pfungsoperationen k men die g ngigen Mengenoperationen wie Vereinigung Dif ferenz Durchschnitt und symmetrische Differenz in Frage Da Best nde jedoch stets disjunkt sind ist nur die Vereinigung von Best nden eine sinnvolle Verkn pfung location_expression selected_location selected_location Die Vereinigung wird durch den Additionsoperator symbolisiert Nur Best nde mit Ele menten der gleichen Klasse k nnen vereinigt werden Auf die Einf hrung einer derartigen Verkn pfung ka
11. 2 6 7 Schnittstellen zur Umgebung 20 ee es Er ah er ee OEE SS 6 8 Simultanbetrieb mit anderen Prozessen 0000084 7 Anwendungen 7 1 Die Modellbank PetriNet dara ra ra af op hee rn na 7 2 Das F nf Philosophen Problem 1 22 222 2 2 Sr EL EEE IE 7 3 Das Modell Bodenfeuchte race Ha Ka a nr Aal 7 4 Die Modellbank QueneNet 3 28 ee en 7 5 Die Modellkomponente Transportband 2 2 2 2 nn 7 6 Das Modell Linienbus 8 Zusammenfassung Literaturverzeichnis xi 221 223 223 225 225 229 232 235 242 244 249 257 xii Kapitel 1 Einleitung Die vorliegende Arbeit stellt konzeptionelle berlegungen f r eine deklarative Sprache zur Beschreibung von dynamischen Modellen Modellbeschreibungssprache vor Der Schwer punkt liegt dabei auf der Formulierung von Warteschlangen und Transportmodellen Es wird jedoch Wert darauf gelegt da die Verwandtschaft zu entsprechenden kontinuierlichen Modellen deutlich wird um ein f r diskrete und kontinuierliche Modelle einheitliches Kon zept zu schaffen Die Abhandlung ist von zwei Seiten motiviert Da ist zum einen das Verlangen der Ferti gungstechnik mit einem auf den Planer zugeschnittenen Simulationssystem neuartige Pro duktionssysteme detailgenau modellieren simulieren und analysieren zu k nnen Und zum anderen ist da das Bed rfnis des Informatikers das Thema Simulationssprachen das et was in Vergessenheit geriet mit neueren sprachl
12. Boss 85 BraFo 87 Cell 83 ChaMi 88 Crae 85 Dorn 91 Apsel Th Eschenbacher P Wittmann J ffentliche Modellbanken des Simulationssystems SIMPLEX II erschienen im Selbstverlag Institut fiir Mathematische Maschinen und Datenverarbeitung der Universitat Erlangen Niirnberg Erlangen 1992 B hme Gert Einstieg in die Mathematische Logik Carl Hanser Verlag Miinchen 1981 Siemens AG Hrsg Benutzerhandbuch BORIS Version 1 5 Bossel Hartmut Dynamik des Waldsterbens Springer Verlag Fachberichte Simulation Bd 4 Berlin 1985 Bratley P Fox B Schrage L A Guide to Simulation Springer Verlag New York 1987 Cellier Francois Simulation Software Today and Tomorrow in Simulation in Engineering Sciences IMACS Symposium International Nantes 1983 Chandy K M Misra J Parallel Program Design Addison Wesley Reading Massachusetts 1988 Craemer Diether Mathematisches Modellieren dynamischer Vorg nge Eine Einf hrung in die Programmiersprache DYNAMO Teubner Verlag Stuttgart 1985 D rnh fer Klaus Die Benutzerumgebung von SIMPLEX II Eine offene graphische Bedienoberfl che zur Erstellung und Auswertung von Simulationsmodellen Arbeitsberichte des Instituts f r Mathematische Maschinen und Datenverarbeitung der Universit t Erlangen Niirnberg Dissertation Band 24 Nummer 8 Erlangen 1991 258 Esch 90 Esch 91 EsWi 90 Forr 72a Forr 72b For
13. Jede Komponente enth lt die f r sie relevanten Variablen Jede Komponente besitzt durch die Sensorvariablen Sr_ab und Sr_zu die M glich keit ihren Bestand zu vergr ern oder zu verkleinern Ob eine Ver nderung des Be stands zu erfolgen hat bestimmt die Membran als dazwischenliegende Komponente Durch das Herstellen der passenden Verbindungen wirkt eine veranla te nderung der Best nde f r die eine Komponente positiv und f r die andere Komponente negativ aus Dieses Beispiel sollte deutlich machen da die angef hrten Anforderungen zu schwache Kri terien sind um von vornherein die eine oder andere L sung ausscheiden zu lassen Die Anforderungen der Praxis sind oft h her zu bewerten Es zeigt da f r eine komponenten weise Zerlegung dem Anwender alle M glichkeiten offenstehen sollten Damit mu man sich allerdings im klaren sein da sich die Korrektheit des Modells bei einer bestandsbezogenen Transportbeschreibung nicht durch semantische Pr fungen nicht sicherstellen l t 162 4 Transporte zwischen Best nden 4 5 2 Modularisierung mit transportbezogener Beschreibung In diesem Fall sollen nicht die Best nde mit ihren Definitionsgleichungen auf verschiedene Komponenten verteilt werden sondern die Transportgleichungen Welche Konsequenzen dies nach sich zieht wird im folgenden er rtert Wir betrachten hierzu drei Best nde B_1 B_2 B_3 mit bidirektionalen Transporten zwischen B_1 und B_2 sowie B_2 und B_3 B_
14. Modellbildung mit GPSS FORTRAN Version3 Springer Verlag Fachberichte Simulation Bd 3 Berlin 1984 Schmidt Bernd Systemanalyse und Modellaufbau Grundlagen der Simulationstechnik Springer Verlag Fachberichte Simulation Bd 1 Berlin 1985 Schmidt Bernd Simulation von Produktionssystemen in Simulation in der Fertigungstechnik Springer Verlag Fachberichte Simulation Bd 10 Berlin 1988 Schnupp Peter Hrsg Moderne Programmiersprachen Oldenbourg Verlag Miinchen 1991 Schriber Thomas J An Introduction to Simulation Using GPSS H John Wiley amp Sons New York 1991 Sch rmann Hans Werner Theoriebildung und Modellbildung Akademische Verlagsgesellschaft Wiesbaden 1977 Siegert Hans Jiirgen Simulation zeitdiskreter Systeme Oldenbourg Verlag Miinchen 1991 Stroustrub Bjarne The C Programming Language Addison Wesley Reading MA 1987 Literaturverzeichnis 261 SYSMOD 86 System Designers Hrsg um 91 Ulb 92 Unbe 80 Wun 86 ZeiElz 79 SYSMOD User Manual Release 1 0 April 1986 SYSMOD Language Definition Release 1 0 Juni 1986 erschienen im Selbstverlag System Designers Scientific Ferneberga House Alexandra Road Farnborough Hampshire United Kingdom Ulbrich Alwin Modellierung und Simulation einer Werkstattfertigung Studienarbeit am IMMD4 der Universit t Erlangen 1991 Ulbrich Alwin Definition und Implementierung der Schnittstelle zwischen Simulationspro
15. Server Das Schl sselwort IN soll uns auch als zweistelliger Operator dienen Die Operation identifier IN indexset liefert einen logischen Wert TRUE wenn die Konstante in der Indexmenge enthalten ist FALSE sonst Beispiel IF j IN i IN1 N X i 0 LET END 3 5 2 Problematik beim Transport zwischen Warter umen Mit den besprochenen Spracherweiterungen sind wir mittlerweile in der Lage das eingangs im Unterabschnitt Motivation dargestellte Beispiel zu verstehen Die Elemente des Warteschlangensystems legen wir als Feld an Ort Pos Farbe Laenge Ort Pos Farbe Laenge Wir modellieren das Verhalten jedes einzelnen Elements Hierzu indizieren wir das Element und erweitern die Aussage mit Hilfe des eingef hrten FOREACH Konstrukts fiir alle Ele mente 102 3 Spracherweiterungen zur Formulierung von Warteschlangenmodellen ARRAY 1 N Job FOREACH i IN 1 N LET IF Job i Ort Q AND EMPTY j IN 1 N Job j Ort S LET IF Job i Pos 1 LET Job i Ort S ELSE LET Job i Pos Job i Pos 1 END END END Aufgrund des Attributes Ort werden alle mobilen Elemente an einem Aufenthaltsort zu einer Menge zusammengefa t Das Attribut Pos soll eine Ordnung innerhalb dieser Menge herstellen Beim Hinzuf gen eines Elements zu einer Menge ist daher seine neue Position innerhalb dieser Menge zu bestimmen Wird es vor der bisher letzten Position eingereiht m ssen d
16. definiert werden m ssen Differenzengleichungen kommen nur dann in Betracht wenn im gesamten Modell mit dem stets gleichen Zeitinkrement gearbeitet werden kann und keine besonderen Anforderungen an die Genauigkeit gestellt werden In der Regel nimmt man die Modellzeit als reellwertig an Man geht deshalb noch einen Schritt weiter und l t als Zeitmenge reelle Zahlen und ein infitesimal kleines Zeitinkre ment dt 0 zu So erh lt man eine Modellbeschreibung mit Differentialgleichungen und Ereignissen Ein diskreter Zustands bergang wird durch die Ereignisfunktion zi t dt fi W t bzw beschrieben 38 2 Sprachentwurf im Sinne der klassischen Systemtheorie Da dt ein infinitesimal kleines Zeitinkrement darstellt l t sich ein realer Zeitfortschritt nur erzielen wenn f eine diskrete Funktion mit folgender Eigenschaft ist fi W t zit falls W t g A Nur wenn eine Ausl sebedingung erf llt ist d h der aktuelle Modellzustand der Ausl se menge A angeh rt besitzt die Ereignisfunktion f einen Wert der von seinem Vorg nger verschieden ist Die diskrete ZUF nimmt daher stets die Form ee fi W t falls W t A z t sonst an Da fiir die Formulierung eines Ereignisses nur der Fall interessant ist bei dem sich die Zustandsvariable ndert lassen wir auch die Kurzschreibweise amp WA falls W t A Zu Auf diese Weise lassen sich diskrete Funktionsverlaufe l ckenlos ber der reellen Zeitac
17. delldarstellung 2 5 1 Der Grundalgorithmus Der folgende Grundalgorithmus simuliert ein formales Modell das in einer expliziten Mo delldarstellung abgefa t und in einer Komponente d h nicht modular aufgebaut ist 1 Anfangszeit und Anfangszustand setzen 2 Alle nicht angeschlossenen Sensorvariablen x_i t_k berechnen Fuer alle i aus 1 NX x_i t_k e_i t_k 3 Alle abhaengigen Variablen y_i t_k berechnen Fuer alle i von 1 bis NY y_i t_k g_i X t k VID y_i 1 t_k Z t_k t_k 4 Alle neuen Zustandsvariablen z_i t_k 1 berechnen Fuer alle i aus 1 NZ z_i t_k 1 f_i X t_k Y t_k Z t_k t_k 5 Variablen des aktuellen Zustands aufzeichnen Monitor 6 Zeitfortschaltung t_k gt t_k 1 k lt k 1 7 Fahre fort mit Schritt 2 Dieser Algorithmus setzt voraus da die statischen Beziehungen sortiert sind d h stets nur auf bereits berechnete abh ngige Variablen zur ckgegriffen wird Die dynamischen Be ziehungen und die Belegungen der Sensorvariablen k nnen in jeder beliebigen Reihenfolge berechnet werden Die eigentlichen Modellgleichungen befinden sich in den Abschnitten 2 4 Nach Bestimmung der abh ngigen Variablen ist der Zustand zum Zeitpunkt t vollst ndig ermittelt An die ser Stelle aber auch noch bevor die Zeit weitergesetzt wird k nnen die interessierenden Variablen aufgezeichnet werden Monitor 2 5 Algorithmus fiir die Simulation einer expliziten Modelldars
18. 1 NQ NQ 1 TGenera T TBetween END Die Bewegungen werden hierbei durch Ver ndern der Best nde nachgebildet Es obliegt dem Anwender daf r zu sorgen da die Anzahl von Elementen die einem Bestand entnommen wird einem oder mehreren Best nden wieder zugef hrt wird Mit anderen Worten Der An wender ist daf r verantwortlich da die Anzahl der Elemente im Modell zu jedem Zeitpunkt erhalten bleibt 4 1 Motivation 131 Ebenso ist er daf r verantwortlich da aus einem Bestand keine Elemente entnommen wer den wenn keine darin enthalten sind Best nde d rfen falls nicht anders vereinbart nicht negativ werden Gegen beide Fehlerquellen kann die Sprache bei verteilter Beschreibung des Transports keinen Schutz gew hrleisten Die Eindeutigkeit hingegen ist sichergestellt denn durch die Verwendung des IF ELSIF Konstrukts k nnen f r die Zustandsvariablen NR NQ und NS keine Mehrdeutigkeiten entste hen Dadurch wird die Problemetik des klassischen Erzeuger Verbraucher Modells vermieden bei dem m glicherweise zum gleichen Zeitpunkt die Anzahl der der Elemente in der Warte schlange erh ht bzw erniedrigt werden Das IF ELSIF Konstrukt sorgt f r den gegenseitigen Ausschlu des Zugriffs F r die beiden Ereignisse IF T gt TGenera und IF NQ gt O AND NS O LET LET NQ NQ 1 NQ NQ 1 END END o ware dies nicht sichergestellt Es ist deshalb nicht ohne weiteres m glich zwei Ereig
19. 5 3 2 Die Formulierung von Ausdr cken Es werden hier nur Ausdr cke betrachtet die einen Wert liefern und nicht etwa eine Menge Bedingte Ausdr cke d h Ausdr cke nach F llen unterschieden treten in Wertzuweisungen und in Transportanweisungen mit gleichartigen Elementen auf 5 3 Beschreibung der Modelldynamik in Basiskomponenten 199 conditional_expression expression expression WHEN expression ELSE expression WHEN expression ELSE expression END Einfache Ausdr cke finden als Bedingung in IF Konstrukten und WHEN Konstrukten so wie bei der Bildung von Eigenschaftsmengen Verwendung Auch als Ordnungskriterium fiir Eigenschaftsmengen und zur Berechnung von Indices sind sie in Gebrauch Ein Ausdruck wird gebildet indem Operanden durch zweistellige Operatoren miteinander verkn pft werden expression operand op operand Zu den Operanden z hlen Modellvariablen Attribute und Best nde mit gleichartigen Elementen Zahlenwerte und Dimensionierungskonstanten logische Werte TRUE und FALSE Werte aus Aufz hlungsmengen Zeit T Funktionsaufrufe und einstellige Operatoren geklammerte Ausdr cke Die zweistelligen Operationen lassen sich in numerische Rechenoperationen logi che Rechenoperationen AND OR und Vergleichsoperationen lt lt lt gt gt gt unterteilen Die numerischen Rechenoperationen und die Vergleichsoperatio
20. Der Graph besitzt 5 Ebenen Die Reihenfolge nach der Sortierung lautet yo y Ys Ys Ya 2 22 3 Vom Gesichtspunkt der Effizienz ist der Algorithmus aber noch keineswegs optimal Es wer den n mlich zu jedem neuen Zeitpunkt s mtliche Modellvariablen neu bestimmt 2 5 3 Verbesserung der Effizienz Speziell in diskreten Modellen ver ndern nur wenige Zustandsvariablen zu einem Zeitpunkt ihren Wert Es ist dann nicht erforderlich den gesamten Graphen zu durchlaufen Vielmehr ist es ausreichend nur diejenigen Variablen neu zu berechnen welche von einer Zustandsva riablen abh ngen die sich ver ndert hat Beispiele Nach einer Ver nderung von 23 ist lediglich 23 neu zu bestimmen Nach einer Ver nderung von z sind y Y3 Ya Ys sowie 2 und 22 neu zu bestimmen Nach einer Zeitfortschaltung ist 2 neu zu bestimmen 54 2 Sprachentwurf im Sinne der klassischen Systemtheorie Um zu erreichen da nur bestimmte Variablen w hrend eines Durchlaufs neu berechnet werden setzt man dynamische Marken Hierzu lassen sich zwei Vorgehensweisen angeben 1 Markierung der Auswirkungen einer nderung Vorw rts Verfolgung Nach der Ver nde rung einer Variablen werden diejenigen Variablen markiert auf welche diese Anderung Einflu hat Nur Variablen mit einer Markierung werden neu berechnet 2 Markierung der ver nderten Variablen R ckw rts Verfolgung Nach der Ver nderung einer Variablen erh lt diese eine Marke Der We
21. Flag und x_ p2 j Flag und und y_ qi j Flag und y_ q2 j Flag und und z_ r1 j Flag und z_ r2 j Flag und und t Flag y_ i j g_ i j x_ p1 j x 2 j a y q1 j y q42 j See 3 Zo Ey VE a yt D3 Falls Wertaenderung Abhaengigkeitsliste verfolgen und Bitfeldeintraege vornehmen y_ i j Flag TRUE Sensorvariablen bernehmen zu diesem Zweck die nderungsmarke derjenigen Variable auf die sie verweisen Die Vorbesetzung und das R cksetzen der Marken erfolgt wie bereits besprochen Die Ausf hrungen haben gezeigt da sich auch bei einer Modularisierung des Modells der Aufwand zur Berechnung sehr stark herabsetzen l t und ungef hr einer Realisierung in einer einzigen Komponente gleichkommt Eine effiziente Bearbeitung einer expliziten Mo delldarstellung ist demnach auch bei modularer Modellzerlegung sichergestellt 2 8 Zusammenfassung 81 2 8 Zusammenfassung In diesem Kapitel wurde gezeigt da die systemtheoretische Modelldarstellung als Grund lage f r eine Spezifikationssprache zur Beschreibung dynamischer Modelle dienen kann Da die Zielrichtung im Bereich diskreter Modelle liegt beschr nkten wir uns auf die explizite Darstellungsform Als besondere Vorteile ergaben sich e Die Modellbeschreibungssprache ist deklarativ und entbindet den Anwender von der Kontrolle des Programmflusses d h die Reihenfolge in der die Aussagen stehen hat keinen Einflu auf die Modellsemantik e Die Spr
22. Job i TEntry T END END END Die vorgestellten sprachlichen Mittel zur Selektion mobiler Elemente aus Warter umen sind allgemein und elementar Da an den Ausdruck der die Ordnung herstellt keine Bedingungen gekn pft sind selbst Funktionen d rfen enthalten sein l t sich jede beliebige Ordnung beschreiben Eine Einschr nkung ergibt sich nur aus der Tatsache da das Beschneiden von Mengen nur mit konstanten Indices vorgenommen werden darf Die praktischen Erfahrungen haben jedoch noch keinen dar ber hinaus gehenden Bedarf erkennen lassen 3 5 6 Probleme der Modularisierung Eine der wichtigsten Anforderungen an eine deklarative Modellbeschreibungssprache war die Modularisierbarkeit von Modellen Die klassische Systemtheorie lieferte hierf r einen beson ders eleganten Ansatz Wir wollen nun pr fen inwieweit die bislang eingef hrten sprachlichen Mittel f r eine komponentenweise Zerlegung von Warteschlangenmodellen ausreichend sind Zu diesem Zweck modellieren wir das einfachste aller Warteschlangenmodelle ein M D 1 System Das Modell bestehe aus drei Aufenthaltsorten einer Warteschlange Queue einer Bedienein heit Server und einem Vorrat von Elementen Reservoir Auf ein dynamisches Erzeugen und Vernichten von Elementen wird vorl ufig bewu t ver zichtet 3 5 Einf hrung von Indexmengen 107 Reservoir Queue Server Anfangs halten sich alle mobilen Elemente im Reservoir auf Mit einer exp
23. SENSOR EXIT SENSOR 1 x ENTRY 1 x GENTRY 1 x DENTRY 1 x GDENTRY GEXIT SENSOR 1 x ENTRY 1 x DENTRY 1 x GENTRY mi 1 x GEXIT m2 x GDEXIT 1 x GDENTRY mi 1 x GEXIT m2 x GDEXIT 1 x TRANSIT DEXIT SENSOR 1 x ENTRY 1 x GENTRY ni x DENTRY n2 x GDENTRY GDEXIT SENSOR 1 x ENTRY 1 x GENTRY mi x GEXIT m2 1 x GDEXIT ni x DENTRY n2 x GDENTRY n2 x GDENTRY m2 1 x GDEXIT k x TRANSIT TRANSIT SENSOR n1 x DENTRY n2 x GDENTRY n2 x GDENTRY m2 x GDEXIT k 1 x TRANSIT Da man sowohl auf der Ausgangsseite wie auf der Eingangsseite bestimmen kann ob Sam meln oder Verzweigen erlaubt sein soll ergibt sich eine relativ gro e Zahl von m glichen Kombinationen Eine so hohe Anzahl ist fiir den praktischen Einsatz aber nicht mehr iiber schaubar 174 4 Transporte zwischen Best nden 4 6 2 Eingrenzung der Typenzahl f r Eingangs und Ausgangsbest nde Willman dem Anwender lediglich die M glichkeit bieten eine eindeutige Modellbeschreibung zu erzwingen etwa weil keine Absprache zwischen parallel liegenden Eing ngen vorgesehen ist dann gen gt eine Unterscheidung der Eingangsbest nde in GENTRY und GDENTRY F r die Ausgangsbest nde ist der Typ GDEXIT ausreichend da ein Bringen stets ohne Verlust der Eindeutigkeit erfolgen kann Wir wollen in Zukunft auf die gro e L sung ganz verzichten und riskieren daher keine Mi verst ndnisse wenn wir die Schl sselw rter im Namen
24. auch eine h here Komponente eine eine Schnitt stelle mit ENTRY DENTRY TRANSIT oder EXIT LOCATIONS anlegen kann Aus der Sicht einer bergeordneten Komponente darf es dabei keinen Unterschied machen ob eine derartige Location einer Basiskomponente oder einer h heren Komponente angeh rt In Anlehnung an Eigenschaftsvariablen verbinden wir die Deklaration gleich mit der den entsprechenden Verbindungen zu den darunterliegenden Komponenten EXIT LOCATIONS Eine EXIT Location f r eine h here Komponente kann durch Verbindung mit einer oder mehreren EXIT Locations aus Subkomponenten vereinbart werden A EXIT LOCATION EXIT X EEE XH B EXIT X C Da die neu vereinbarte EXIT Location nach au en hin auf das Recht zu Holen verzichtet d rfen A X und B X mit keiner Location eines anderen Typs ENTRY DENTRY oder TRANSIT verbunden sein ENTRY LOCATIONS Eine ENRTY Location f r eine h here Komponente kann durch Verbindung mit einer ein zigen ENRTY Location aus einer Subkomponente vereinbart werden ENTRY LOCATION A XH gt A X XH p X ENTRY 4 6 Transportbezogene Modularisierung mit Teilautonomie 179 Alternativ kann eine ENTRY Location auch durch Verbindung mit einer oder mehreren DENTRY Locations aus Subkomponenten vereinbart werden ENTRY Locations ben das Recht zu holen nach au en hin exklusiv aus Innerhalb der Komponente d rfen aber mehrere Eingangs Locations vom Typ D
25. da das angesprochene Element auch tats chlich in der Menge enthalten ist selected_variable indexed_identifier identifier index indexed_identifier Beispiel Queue1 Job 1 Laenge Attribut Laenge des ersten Elements in der Warteschlange Queuel 3 6 3 Beschreibung von Transporten Die Einf hrung von Mengenvariablen verschafft uns eine verk rzte und bersichtlichere Mo dellbeschreibung Beispiel ARRAY 1 N Job Queuel J IN Job J Ort Q1 DEC J Laenge INC J TEntry FOREACH J IN Job LET IF CARD Queuel gt 5 LET IF J IN Queuei Job 1 LET J Ort 02 J TEntry T END END END 3 6 Einf hrung von Mengenvariablen als abh ngige Variablen 115 Wie man sieht wurde auch der Allquantor so erweitert da als gebundene Variable nicht nur Indices sondern auch Feldelemente in Frage kommen Es f llt auf da der Aufenthaltsort eines mobilen Elements einerseits als Menge Queue1 andererseits als Wert einer Aufz hlungsmenge Q1 gef hrt wird Um dies zu vermeiden ordnen wir der Variable Ort eines mobilen Elements in Zukunft nicht mehr den Wert einer Aufz hlungsmenge sondern den Namen einer Mengenvariablen zu 3 6 4 Namen von Mengen Bezeichner stehen in der Regel f r den Inhalt Wert oder Menge einer Variablen Wir wollen nun auch Bezeichner zulassen die f r den Namen einer Variablen stehen Der Name einer Variablen wird mit Hilfe des Operators NAME angesproch
26. da es bei Modellen ohne unterscheidbare Elemente nur deshalb nicht blich ist einen Unterschied zwischen Attributen und Best nden zu machen weil die einzelnen Ele mente nicht individuell verfolgt werden m ssen und ein Transport daher in zwei Operationen Erzeugen und Vernichten zerlegt werden kann 251 Die Verwendung der Transportoperation hat neben einer gr eren Anschaulichkeit jedoch den weiteren Vorteil da die Einhaltung des Erhaltungssatzes garantiert wird Der Erhal tungssatz gilt naturgem f r alle Bestandsgr en Es wurde ausf hrlich diskutiert in welcher Weise Modelle mit Bestandsgr en modularisiert werden k nnen Da die Transportoperation jeweils zwei Best nde ver ndert mu man sich entscheiden in welcher Komponente die Transportoperation unterzubringen ist Einer der beiden Best nde ist daher auf zwei Komponenten zu verteilen Da ein Bestand im Gegensatz zu einem Attribut nicht mehr nur einer Komponente zugerech net werden kann besitzt eine Komponente keine volle Autonomie bez glich dieser verteilten Best nde Die Forderung nach modularer Modellzerlegung und die Forderung nach einem eindeutig geregelten Zugriff auf die Elemente und deren Attribute lassen sich aber nur gleichzeitig erf llen wenn die Komponenten nicht zuviel von ihrer Autonomie abgeben Da die Bed rf nisse von Anwendung zu Anwendung unterschiedlich liegen wurde eine Kompromi l sung vorgeschlagen die es dem Anwender erm glich
27. gt Zustand C t 1 Zustand D t 1 6 5 Zufallsvariablen 219 Jede zuf llig zu ermittelnde Zeitdauer bzw Auspr gung ist eine Zufallsvariable Diese wer den durch Verteilungs bzw Verteilungsdichtefunktionen beschrieben welche aus empirisch bestimmten H ufigkeiten abgeleitet werden Beispiele Zufallvariable Verteilungsdichte Dauer eines Bedienvorgangs F arbeitet gt fertig a Zeitdauer Dauer bis zur n chsten Ankunft 4 wartet gt Ankunft Se 0 gt Zeitdauer Niederschlagsmenge bei Regen O 10 mm p 0 2 10 20 mm p 0 4 20 30 mm p 0 3 30 mm p 0 1 Wahrscheinlichkeit Zufallsvariable k nnen wie in den Beispielen statistisch unabh ngig sein aber auch mit vorangegangenen Werten korreliert und oder mit anderen Zustandsvariablen korreliert sein Je nachdem werden ein oder mehrdimensionale Verteilungsfunktionen ben tigt Ein neuer Wert einer Zufallsvariable wird mit Hilfe einer Zufallszahlenfolge bestimmt die auf die gegebenen Verteilungsfunktionen angewendet werden Beispiele Es seien x x und z2 Zufallsvariable r r und rz seien Zufallszahlenfolgen aus 0 1 F sei eine eindimensionale F eine zweidimensionale Verteilungsfunktion 3 Eine Zufallsvariable statistisch unabh ngig x k Fi r k 3 Eine Zufallsvariable Korrelation zum vorangegangenen Wert x k Fy r k 2 k 1 3 Zwei Zufallsvariablen Korrelation untereinander keine
28. i j t 72 2 Sprachentwurf im Sinne der klassischen Systemtheorie 3 Alle abhaengigen Variablen y_i berechnen Fuer alle i aus 1 NY_j Falls Ebene m y_ i j Level y j g G j X_j Y j 2 4 Alle neuen Zustandsvariablen z_i berechnen Fuer alle i aus 1 NZ_j Falls Ebene m NE z_ i j f_ i j _j Y_j Z_j t Ende des Komponentenaufrufs 5 Variablen des aktuellen Zustands aufzeichnen Motor Os 6a Neuen Zeitpunkt t bestimmen und Zeit fortschalten Sr Da tS tS 6b Alle Zustandsvariablen umspeichern Fuer alle i aus 1 NZ z_i zii Ende Schleife ueber alle Zeitpunkte Die abh ngigen Variablen werden nun zu einem Zeitpunkt nur noch ein einziges Mal be stimmt Dieser Algorithmus bleibt f r alle weiteren Verbesserungen der gleiche Es ist nur die Frage wie man durch geschicktes Setzen der Marken und durch eine Verminderung der Anzahl der Ebenen die Zahl der auszuf hrenden Anweisungen weiter reduzieren kann 2 7 Algorithmus f r die Simulation einer modularen Modellbeschreibung 73 Die Reduktion der Anzahl der Ebenen l t sich erreichen wenn man die Gleichungen in nerhalb einer Komponente sortiert und in Gruppen zusamenf t Auf diese Ma nahme die auch mit statischen Marken durchgef hrt wird soll nun n her eingegangen werden Reduktion der Anzahl der Ebenen Sortierte Gleichungen in einer Komponente k nnen zu einer Gruppe zusammengefa t und hintereinander weg ausgef hrt werden
29. in der ihr Wert zu berechnen ist Bevor die Beziehung ausgewertet wird wird auf die richtige Ebene gepr ft Zur Berechnung der abh ngigen Variablen sind nunmehr f r jeden Zeitpunkt NY statische Beziehungen zu berechnen NE 1 NK Unterprogramme aufzurufen NE 1 NK NY Abfragen der Marken auszuf hren 2 Aussondern derjenigen Komponenten die keine Variablen enthalten welche in der aktuellen Ebene zu berechnen sind Es wird ein zweidimensionales Feld B mit logischen Werten der Dimension NK NE angelegt Ein Feldelement B j m enth lt eine Marke wenn die Komponente j Be stimmungsgleichungen enth lt welche in der Ebene m auszuf hren sind Die Anzahl der aufzurufenden Unterprogramme verringert sich hierdurch erfahrungs gem etwa um den Faktor 2 bis 3 Der Grund warum diese Bedingungen nicht in den Code aufgenommen werden k nnen sondern als Daten in Form statischer Marken abzulegen sind liegt im Klassenkonzept Eine Variable die in der einen Auspr gung einer Klasse in Ebene i berechnen ist ist in einer anderen Auspr gung m glicherweise in Ebene j zu bestimmen Der Grundalgorithmus ist hierzu durch die eingef hrten Marken zu erg nzen 1 Anfangszeit und Anfangszustand setzen Fuer alle j aus 1 Nk Falls B j m TRUE Aufruf der Komponente j 2 Alle nicht verbundenen Sensorvariablen x_i berechnen Fuer alle nicht verbundenen x_ i j mit i aus 1 NX_j Falls Ebene m 1 x_ i j e_
30. j IN 1 100 Job j Laenge lt LMax DEC Job j Laenge 1 Die resultierende Menge enth lt nur den Index des Jobs mit dem gr tem Attribut Laenge der gerade noch kleiner oder gleich LMax ist sofern es berhaupt einen solchen Job gibt 3 5 Einf hrung von Indexmengen 105 3 5 5 Verbesserte Formulierung des Transports zwischen Warter umen Wir greifen die eingangs angef hrten Beispiele nochmals auf und zeigen wie sich durch die Bildung von geordneten Mengen und das Ausgrenzen von Teilmengen eine griffigere und kompaktere Beschreibung ergibt Beispiel Das erste Beispiel beschreibt den Transport des ltesten Elements aus einer Warte schlange in eine Bedieneinheit sobald diese frei ist ARRAY 1 N Job FOREACH i IN 1 N LET IF i IN j IN 1 N Job i Ort Q INC Job i TEntry 1 AND EMPTY j IN Job j Job j Ort S LET Job i Ort7 9 Job i TEntry T END END Das Attribut Pos wurde durch das Attribut TEntry ersetzt das den Eintrittszeitpunkt festh lt und beim Betreten eines Warteraums gesetzt wird Die Position wird nun indirekt ber den Eintrittszeitpunkt bestimmt Das eingangs erw hnte Problem da die Position nicht als Zustandsvariable im eigentlichen Sinne angesehen werden kann hat sich dadurch erledigt Es f llt allerdings auf da die Ordnung nicht geregelt ist wenn zwei oder mehrere Elemente den gleichen Eintrittszeitpunkt besitzen In einem solchen Fall
31. nkungen nicht mehr alle Anwen dungsf lle abdeckt bieten SLAM und SIMAN beide beruhen auf dem Simulationspaket GASP daneben eine ereignis orientierte Form der Modellbeschreibung an Die gleiche Er weiterung wurde in GPSS FORTRAN durchgef hrt Diese Vorgehensweise f hrt aber beim kombinierten Einsatz beider Konzepte zu methodologischen Ungereimtheiten Diese Sprachen sowie ihre Weiterentwicklungen umfassen nicht nur eine Beschreibung des Simulationsmodells sondern auch Befehle zur Durchf hrung der Experimente und zur Aus gabe der Ergebnisse Neue Experimente machen zumindest eine teilweise Neu bersetzung erforderlich Erst zu Beginn der achtziger Jahre wurde massiert auf diesen Mi stand hingewiesen und die Forderung nach einer Trennung von Modell und Experiment erhoben Andere Schwierigkeiten ergaben sich wegen des geringen Sprachumfangs und insbesondere wegen der begrenzten M glichkeiten Ein Ausgabe zu betreiben Aus diesem Grund ge 12 1 Einleitung statten manche Simulationssprachen Eingriffe in das darunterliegende Programmpaket eine Vorgehensweise die sicherlich nicht zur Ubersichtlichkeit beitr gt Neuere Entwicklungen auf dem Gebiet der Simulationssprachen die auch einen modularen Modellaufbau gestatten sollten erfolgten jedoch nur sehr schleppend und erlangten keine Produktreife COSMOS Kett83 Kett88 SYSMOD SYSMOD 86 Die ganze Aufmerk samkeit galt in den vergangenen zehn Jahren den datengesteuerten Simulatore
32. riablen mit Ausgangsvariablen verbunden ist das gesamte Modell abgeschlossen Beispiel Das System S1 enthalte die Gleichungen en 2 Y te glz und das System S2 die Gleichung y te g x Wir stellen nun die folgenden Verbindungen her S2 c Sly Sl x S24 S1 S2 n 2 Xx z z a ee Dadurch erhalten wir ein abgeschlossenes Modell Durch das Gleichsetzen der Eingangsvariablen mit Ausgangsvariablen sind aus den Glei chungen des Gesamtmodells die Eingangsvariablen eliminiert Beispiel Die Gleichungen f r das Gesamtmodell lauten Slizttea t f S1 z S2y Slyk g S1 z S2y th g S1 y Es f llt auf da nun sowohl in der Zustands berf hrungsfunktion als auch in einer Ausga befunktion Ausgangsvariablen auftreten Ob das Modell korrekt ist ist nach einem Zusam mensetzen aus Teilsystemen nicht mehr ohne weiteres sichergestellt 32 2 Sprachentwurf im Sinne der klassischen Systemtheorie Beispiel Wenn man den Eingang des Systems S2 mit dem Ausgang des gleichen Systems verbindet d h 2 72 52 y dann erh lt man keine korrekte Modellsemantik mehr S2 y th gt ge S2 y Eine Modellbeschreibung wird praktikabler wenn man die strenge systemtheoretische Dar stellung etwas ab ndert Da sie die Korrektheit des Modells ohnehin nicht sicherstellen kann sei es deshalb erlaubt einige Modifikationen vorzunehmen 2 1 6 Modifizierte Zustandsdarstellung Fiir praktische Anwen
33. weitere Angaben gilt das FIFO Prinzip Best nde mit Ausnahme von Quellen und Senken k nnen aber auch mit einem anderen Einordnungskriterium bzw einer Liste von Kriterien versehen werden Neben FIFO und LIFO die nur am Ende der Liste stehen d rfen kann nach aufsteigenden oder abfallenden Attributen der mobilen Komponenten in die Warteschlange einsortiert werden Stehen nach Anwendung des ersten Kriterium noch mehrere Positionen f r eine Einordnung zur Wahl wird durch Anwendung des n chsten Kriteriums zwischen diesen entschieden Wenn gar kein oder wenn keine weiteren Kriterien angegeben sind wird nach FIFO entschieden Mehrere in einer h heren Komponente zusammengeschlossene Best nde m ssen die gleichen Einordnungskriterien besitzen ordering_criteria criterion criterion criterion FIFO LIFO INC identifier DEC identifier TRUE identifer FALSE identifier 5 3 Beschreibung der Modelldynamik in Basiskomponenten 197 Zustandsvariablen und nicht angeschlossene Sensorvariablen welche Attribute ausdriicken sind mit einem Anfangswert zu versehen F r alle anderen Attribute sowie f r Best nde ist die Vorbesetzung optional Fehlt die Anfangsbelegung wird f r Best nde ein leerer Bestand angenommen Die Vorbesetzung von Quellen und Senken ist nicht m glich initial_value number unit identifier TRUE FALSE gt identifier Zufallsvariablen sind mit einer Verteilung zu versehen Sie s
34. Ah Versickern in tieferen Schichten Verzicht auf Initialisierung Wasseraufnahme durch Wurzeln Verdunstung durch Baum Transpiration 7 4 Die Modellbank QueueNet 235 HIGH LEVEL COMPONENT Bodenfeuchte SUBCOMPONENTS Wasser Baum STRUCTURE TRANSPORT CONNECTION Wasser FHumus gt Baum FHumus END OF Bodenfeuchte Wasser Baum FLaub e FHumus R D e FBHori FHumus FBaum 7 4 Die Modellbank QueueNet Die Modellbank QueueNet stellt Komponenten zum Aufbau von einfachen Warteschlan genmodellen zur Verf gung wie sie in der Warteschlangentheorie behandelt werden Als Attribute f hren die mobilen Elemente eine Priorit t mit und den Zeitpunkt zu dem ihre Bearbeitung endet Der Wert der Priorit t kann 0 niedrige Priorit t oder 1 hohe Priorit t betragen Die Modellbank enth lt die folgenden Komponenten e Job Auftrag der das Modell durchlauft e Source Quelle die mobile Elemente mit einer exponentiell verteilten Zwischenan kunftszeit erzeugt Parameter TBetween Mean mittlere Zwischenankunftszeit HighPrio Wahrscheinlichkeit f r hohe Priorit t Ausgang Exit TBetween Mean HighPrio Exit e Senke Senke die mobile Elemente vernichtet Entrance gt 236 7 Anwendungen e Facility Warteschlange mit einer oder mehreren Bedieneinheiten und exponential verteilter Bedienzeit Parameter TService Mean mittlere Bedienzeit NUnits Anzahl von Bedieneinheite
35. Aus bung der letzten drei Rechte f hrt Ver nderungen an einem Bestand herbei Eine Komponente hat verschiedene M glichkeiten mit diesen Rechten umzugehen Interes sant sind vor allem die folgenden F lle Sie kann e ein Recht selbst wahrnehmen W oder e selbst auf ein Recht verzichten V und sie kann ein Recht e allen anderen verweigern K keiner e nur einer einzigen fremden Komponente zugestehen 1 oder e allen fremden Komponenten zugestehen A alle Daraus resultieren sechs M glichkeiten jedes einzelne der vier Rechte zu vergeben insgesamt demnach 24 Typen von Best nden Die interessantesten davon werden im folgenden disku tiert Durch Kombination der angegebenen Buchstaben ergibt sich eine Kurzschreibweise f r jede der M glichkeiten Private Best nde und Durchgangsbest nde Private Best nde und Durchgangsbest nde verk rpern zwei Extrempositionen Private Be st nde sind f r fremde Komponenten v llig unzug nglich Auf private Best nde k nnen andere Komponenten keinen Einflu nehmen Sie werden mit dem Zusatz PRIVATE ver sehen In Anlehnung an Eigenschaftsvariablen erhalten andere Komponenten lediglich ein Leserecht auf private Best nde In Kurzschreibweise L WA SBH Wk Durchgangsbest nde sind f r alle Komponenten frei zug nglich und d rfen von allen Kompo nenten gleichberechtigt mitgenutzt werden Jede Komponente besitzt alle Rechte Insbeson dere k nnen Transporte in die Komponente und
36. Ausdr cken stellen Funktionen und Operatoren Bedingungen an die Wertemengen der Operanden Bei Wertzuweisungen darf einer Variablen darf nur ein Ausdruck zugeordnet werden der die gleiche Wertemenge besitzt wie die Variable Anstelle der geforderten Wertemenge ist auch eine Teilmenge zul ssig wie z B eine INTEGER Zahle anstelle einer REAL Zahl Zeitverlauf Im Dynamikteil darf einer Konstanten kein Wert zugewiesen werden Das Verhalten einer diskreten Zustandsvariable darf nur durch eine Ereignisfunktion beschrieben werden Das Verhalten einer kontinuierlichen Zustandsvariable darf auch durch eine Differentialgleichung beschrieben werden Einer diskreten abh ngigen Variablen oder Sensorvariablen darf nur ein Ausdruck mit zeitdiskretem Verlauf zugeordnet werden physikalische Ma einheit Zwei Modellgr en d rfen nur dann summiert werden wenn ihre Ma einheiten iden tisch sind Zwei Modellgr en d rfen nur dann verglichen werden wenn ihre Ma ein heiten kommensurabel d h ineinander berf hrbar sind Bei der Verwendung von Standardfunktionen lassen sich hnliche Bedingungen abpr fen Ein Ausdruck darf einer Modellgr e nur zugeordnet werden wenn ihre Einheiten kommensurabel sind Auf die Angabe einer Syntax f r das Festlegen der Eigenschaften wird vorl ufig verzichtet da dies f r das Verst ndnis der Beispiele nicht erforderlich ist und im Kapitel 5 nachgeholt wird Die Notation ist weitestgehend selbsterkl re
37. Beschreibung von Warteschlangen und Transportsystemen taugt Zun chst wurde versucht durch die Einf hrung von Elementen Verbunde von Modellva riablen von Feldern indizierbaren Attributen und Elementen und von Allquantoren das Problem zu erledigen Es zeigte sich da hierdurch jedoch keine Modularisierung der Modelle m glich ist Es wurden Erg nzungen notwendig die das bisherige Konzept um grundlegend neue Inhalte erweiterten Neben den Modellvariablen als Repr sentanten f r Attribute wurden Variablen als Repr sen tanten f r geordnete Mengen eingef hrt wobei jedes Mengenelement selbst wiederum einen Verbund von Variablen repr sentiert Es erwies sich als besonders vorteilhaft diese Mengen als disjunkt anzusehen Dadurch erhielten sie die Bedeutung eines Aufenthaltsorts f r Ele mente und wurden daher auch als Bestandsgr en oder Locations bezeichnet Um das dynamische Verhalten der Best nde zu beschreiben wurde f r diesen neuen Va riablentyp eine Transportoperation eingef hrt Diese diente nicht nur zum Transportieren sondern auch zum Erzeugen und Vernichten von Mengenelementen Es war das Ziel eine Notation zu finden die Transporte von unterscheidbaren und von nicht unterscheidbaren Elementen in gleicher Weise beschreiben Zu diesem Zweck wurden auch Bestandsgr en f r Mengen eingef hrt deren Elemente sich nicht unterscheiden lassen und die lediglich durch eine Anzahl repr sentiert werden Es zeigte sich
38. DENTRY LOCATIONS deklariert Das besagt da mehrere Transitionen mit derselben Stelle verbunden sein d rfen Dadurch ist es m glich da zwei oder mehrere Transitionen gleichzeitig je eine Marke von der Stelle abziehen Darin steckt nat rlich eine Konfliktm glichkeit weil u U mehr Marken von einer Stelle weggenommen werden sollen als sich auf ihr befinden BASIC COMPONENT Place DECLARATION TRANSIT LOCATION State INT 0 END OF Place BASIC COMPONENT Transition DECLARATION STATE VARIABLES CONSTANT NI INT 1 NO INT 1 DENTRY LOCATION ARRAY 1 3 Input INT 1 EXIT LOCATION ARRAY 1 3 Output INT SOURCE LOCATION Source INT SINK LOCATION Sink INT 7 1 Die Modellbank PetriNet 227 DYNAMIC BEHAVIOUR IF ALL i IN 1 3 Input i gt 0 LET FOREACH i IN 1 3 i lt NI LET Input i gt Sink 1 END FOREACH i IN 1 3 i lt NO LET Source gt Output i 1 END END END OF Transition Aus diesen beiden Grundbausteinen lassen sich nun ganze Netze wie etwa das folgende aufbauen 3 4 228 HIGH LEVEL COMPONENT System SUBCOMPONENTS ARRAY 1 5 Place ARRAY 1 4 Transition STRUCTURE TRANSPORT CONNECTIONS Place 1 State gt Transition 1 Place 2 State gt Transition 1 Transition 1 Output 1 gt Place Place 3 State gt Transition 2 Transition 2 Output 1 gt Place Transition 2 Output 2 gt Plac
39. Ebenso die M glichkeit Zusammenh nge kompakt zum Ausdruck zu bringen F r die Verst ndlich keit eines modular aufgebauten Modells ist vor allen Dingen wichtig da der Transportvor gang und die Transportrichtung zwischen zwei Komponenten ersichtlich ist 4 5 1 Modularisierung mit bestandsbezogener Beschreibung Die Modularisierung bei bestandsbezogener Beschreibung wird ebenso vorgenommen wie die Modularisierung mit Eigenschaftsgr en Jeder Bestand und dessen Definitionsgleichung wird einer beliebigen Komponente zugeordnet Wie wir bereits wissen erm glicht diese Vorgehensweise einen hierarchischen Modellauf bau Auch k nnen die Komponenten als autonom angesehen werden da der Zeitverlauf einer internen Variablen nur durch eine Definitionsgleichung festgelegt ist und diese sich in der gleichen Komponente befindet In diesem Abschnitt soll untersucht werden inwieweit auch die anderen Anforderungen an eine Modellbeschreibungssprache bei bestandsbezogener Transportbeschreibung erf llt werden In diesem Abschnitt wird die modulare Modellzerlegung wie sie im Abschnitt 4 1 f r Trans portvorg nge angedeutet wurde verallgemeinert Hierzu sind neben den Best nden bezeich net mit B abh ngige Mengen Variablen notwendig um die Transportmenge bezeichnet mit T ausdr cken und an andere Komponenten weitergeben zu k nnen Weiterhin sind Sensorvariablen f r Mengen erforderlich um Einblick in Best nde bezeichnet mit SB und
40. Exit Server _ FOREACH J IN Queue Job i LET IF EMPTY Exit LET J gt Exit J TEntry T END END 3 7 Einf hrung von Mengenvariablen als Zustandsvariablen 125 SSS SS SS SS eS a oe a a ee eee Se a eS See eS Komponente S SSeS eee ee ee ee eS eS SS Se Se a a ee eS Se eS eS SS CONSTANT TService REAL 8 STATE VARIABLE Server SET OF Job 0 Job SENSOR VARIABLE Exit SET OF Job Bewegung von Server nach Exit Reservoir SEI 220022 ee eS Se eS SS SS ee eS FOREACH J IN Server Job 1 LET IF T gt J TEntry TService LET J gt Exit J TEntry T END END aaa eae eee ee SS SS Se eS a Sa a ee a 3a eae Se eee eS Komponente R SS Sa ee ee ee Se ee Ue eS eS ee ee ee STATE VARIABLE TGenera REAL 0 Reservoir SET OF Job 100 Job SENSOR VARIABLE Exit SET OF Job RANDOM VARIABLE TBetween REAL EXPO Mean 10 Bewegung von Reservoir nach Exit Queue fe a ca a a ag Bun a a a a FOREACH J IN Reservoir Job 1 LET IF T gt TGenera LET J gt Exit J TEntry T TGenera T TBetween END END Soccer ea a ea SS a SS ee Se Hoehere Komponente H 2 a a a ee ae Se ee eee eee eee SUBCOMPONENTS Q S R EFFECT CONNECTIONS Q Queue gt R Exit S Server gt Q Exit R Reservoir gt S Exit 126 3 Spracherweiterungen zur Formulierung von Warteschlangenmodellen
41. FOREACH P IN Eingang B StatNo LET P gt B Plaetze END Naechster Halt B TStation T FahrZeit B StatNo B StatNo MOD B StatNo NStat 1 END OF Linienbus 248 7 Anwendungen HIGH LEVEL COMPONENT System Nur zu Testzwecken SUBCOMPONENTS Linienbus ARRAY 1 NStat Quelle Senke STRUCTURE TRANSPORT CONNECTIONS Quelle i Ausgang gt Linienbus Eingang i Linienbus Ausgang i gt Senke END OF System Linienbus Senke Quelle 1 Eingang 1 Ausgang gt ee Ausgang 1 Quelle 2 Eingang 2 Ausgang gt _ Ausgang 2 Eingang Quelle NStat lt lt 249 Kapitel 8 Zusammenfassung In der vorliegenden Arbeit wurde ein Konzept fiir eine formale Sprache vorgestellt und diskutiert das der Beschreibung und Simulation von dynamischen Modellen dient Dabei lag der Schwerpunkt auf Warteschlangen und Transportmodellen Die Problemstellung Auftrags orientierte Systeme wie Rechnernetze Betriebsorganisationen und Betriebssysteme sowie Transport und Verkehrssysteme zeichnen sich dadurch aus da ihre Leistungsf hig keit in erheblichem Ma von den eingesetzten Steuerungen bestimmt werden Will man die Leistungsf higkeit eines solchen Systems anhand von Leistungsgr en bestimmen und zu diesem Zweck das System simulieren dann mu das Simulationsprogramm die wesentlichen Teile der Steuerungs
42. Form eines Petri Netzes abzulegen Da bereits einzelne Teilnetze eine enorme Gr e annehmen geht schnell die bersicht verloren Will man die Information nicht nur auf dem Bildschirm sondern auch auf Papier haben dann sind riesige Pl ne auszugeben Viele Auswahlstrategien lassen sich allein mit Petri Netzen nur sehr umst ndlich 1 5 Neue Anforderungen an die Simulationstechnik 23 beschreiben Bereits beim Suchen in einer Liste nach bestimmten Kriterien entstehen nahezu un berwindliche Schwierigkeiten Ein Fertigungstechniker ist sicherlich nicht in der Lage Steuerungen mit Hilfe von Petri Netzen zu beschreiben Wenn aber schon ein Informatiker hinzugezogen werden mu dann ist nicht einzusehen warum dann nicht eine kompaktere Beschreibung gew hlt werden sollte Durch die vielen Erweiterungen die eingef hrt wurden um ein Petri Netz Modell f r ferti gungstechnische Anwendungen einsatzf hig zu machen ist eine ganz neue Modellwelt ent standen die mit der urspr nglichen Intention der Petri Netze letztlich nicht mehr viel gemein hat SIMPLEX II das vierte Projekt wurde am Institut f r Mathematische Maschinen und Da tenverarbeitung der Universit t Erlangen durchgef hrt Bei diesem Projekt ging man von vornherein davon aus da die gesteckten Ziele nicht in einem Schritt zu verwirklichen sind So einfach es ist datengesteuerte Simulatoren mit einer komfortablen Oberfl che auszustat ten so m hsam ist es aber auch dies
43. Gleichungsseite auftaucht Beispiel ARRAY 0 4 X REAL IF T gt TNext LET Z X k k k 1 MOD 5 TNext T 10 END Alle 10 Zeiteinheiten wird einer von 5 Eing ngen X 0 X 4 abgetastet und der Abtastwert in der Variablen Z festgehalten Wie man relativ schnell erkennt gibt es keine M glichkeit bereits durch den Compiler festzustellen ob die Variable k stets im Bereich zwischen 0 und 4 liegt Dies w re nur durch eine symbolische Analyse zu leisten Da bislang auch keine syntaktische Notation gefunden wurde die eine Pr fung unterst tzt ist eine Kontrolle des Indexbereichs zur Compilezeit im allgemeinen nicht m glich Handelt es sich bei dem Index allerdings um die gebundene Variable eines FOREACH Konstrukts wie das in der Praxis meist der Fall ist so ist selbstverst ndlich bekannt in nerhalb welcher Grenzen die Werte dieser Variablen liegen Es spricht dann nat rlich nichts dagegen bei speziellen aber h ufig vorkommenden Indexausdr cken wie i 1 oder 2 i 1 welche die gebundene Variable durch einfache Operationen mit Konstanten verkn pfen be reits vom Compiler eine Feldgrenzenpr fung durchf hren zu lassen Beispiel FOREACH i IN 2 9 LET Z i Yli 1 Yli 1 END Erleichtert wird eine Feldgrenzen berwachung bei einer Beschr nkung auf monotone Ope rationen wie oder da in diesen F llen nur f r den kleinsten und den gr ten Index der gebundenen Variable ein Test durchgef
44. Hierin zeigt sich auch das Dilemma einer Spezifikationssprache 1 Der Anwender ist bei der Formulierung seines Modells auf die angebotenen sprachlichen Mittel angewiesen Beispiele e Wenn die Sprache keine Zufallsvariablen anbietet kann der Anwender keine stochastischen Modelle formulieren e Wenn die Sprache keine Differentialgleichungen zul t k nnen keine kon tinuierlichen Modelle formuliert werden e Wenn die Sprache nur arithmetische Ausdr cke zur Formulierung von Zusammenh ngen zwischen Modellvariablen kennt k nnen Funktionen nicht tabellarisch oder algorithmisch dargestellt werden 2 Der Anwender kann Funktionen die ber die reine Modellbeschreibung hinausgehen nicht in das erzeugte Simulationsprogramm aufnehmen Beispiele e Laufende Ein Ausgabe von Daten w hrend eines Simulationslaufs von auf Datei Datenbank oder Bildschirm e Kommunikation mit anderen Prozessen w hrend des Simulationslaufs e Synchronisation mit der Systemuhr Echtzeit bzw zeitproportionaler Betrieb Eine prozedurale Sprache kennt diese Probleme nicht Jede Art von Funktionalit t die den Umfang der Sprache bersteigt kann in Form einer Unterprogrammsammlung zur Verf gung gestellt werden In einem erheblichen Umfang kann der Anwender sich Unterprogramme mit 214 6 Spracherweiterungen fiir den praktischen Einsatz den Mittel einer Programmiersprache selbst erstellen Lediglich Funktionen die auf die Hard ware oder das Betriebssystem
45. Korrelation zum voran gegangenen Wert z k Fi r k x2 k Fy rz k z k Zufallsvariable sind demnach unter Angabe einer Verteilungsfunktion einer Zufallszahlen folge und der korrelierten Variablen zu deklarieren In SIMPLEX MDL wurden bislang nur statistisch unabh ngige Zufallsvariablen realisiert Beispiel 220 6 Spracherweiterungen f r den praktischen Einsatz RANDOM VARIABLE TWork REAL GAUSS Mean 10 Sigma 3 Eine bestimmte Zufallszahlenfolge wird vom Compiler zugeteilt Eigentlich k nnte man die Zufallszahlen auch einer einzigen idealen Zufallszahlenfolge entnehmen Dies h tte aber den Nachteil da die einzelnen Prozesse nach nderungen am Modell auch der Parame ter wegen Verschiebungen im zeitlichen Ablauf nicht mehr das gleiche zuf llige Verhalten aufweisen w rden Dadurch ist die Vergleichbarkeit von Simulationsergebnisse nicht mehr gegeben Die Integration von Zufallsvariablen in die Dynamikbeschreibung einer zustandsorientierten Sprache bereitet bislang noch methodologische Schwierigkeiten Im Gegensatz zu den Modellvariablen besitzen Zufallsvariablen nur vor bergehend einen Wert In anderen Zeitabschnitten sind sie undefiniert Der Wert einer Zufallsvariable die eine Zeitdauer ausdr ckt ist nur interessant solange ein bestimmter Zustand vorliegt Wird dieser Zustand verlassen ist der Wert der Zufallsvariable ohne Bedeutung Zufallsvariablen die einer Auspr gung entsprechen werde
46. Liefert der Ausdruck f r mehrere Elemente den gleichen Ordnungswert dann ist ihre Rei henfolge innerhalb der Menge nicht festgelegt Durch Hinzuf gen eines weiteren Ordnungs kriteriums kann bei Gleichheit des Ordnungswertes ber die Reihenfolge entschieden werden 104 3 Spracherweiterungen zur Formulierung von Warteschlangenmodellen Beispiel i IN 1 100 Job i Ort 701 DEC Job i Priority INC Job i TEntry Die Menge von Jobs auf der Warteschlange Q1 wird nach fallenden Priorit ten ge ordnet Besitzen zwei oder mehrere Jobs die gleiche Priorit t werden diese nach dem zunehmendem Eintrittszeitpunkt TEntry geordnet Erfolgte bislang eine Teilmengenbildung ausschlie lich durch Angabe von Eigenschaften so ist bei geordneten Mengen eine Teilmengenbildung auch m glich indem man Bereiche ausgrenzt 3 5 4 Beschneiden von Mengen Das Beschneiden von Mengen d h das Ausgrenzen von Teilmengen aus einer geordneten Menge erfolgt durch Angabe desjenigen Indexbereiches der erhalten bleiben soll cutted_set ordered_property_set cardinal_set cardinal_set index_range constant_integer Sind keine der angegebenen Indices in der Menge enthalten bleibt die resultierende Menge leer Beispiele j IN 1 10 INC x j 1 5 Die geordnete Indexmenge wird bis auf die Positionen 1 5 abgeschnitten und enth lt die Indices der 5 kleinsten Werte der Variablen x
47. NOT EMPTY Band LET IF X gt Band Teil 1 XEnde Sobald das Teil am Ende angekommen LET ist wird es auf den Uebergabeplatz Band Teil 1 gt Ausgang gelegt END END END OF Transportband 244 7 Anwendungen 7 6 Das Modell Linienbus Mobile Komponenten sind nur Datentr ger und besitzen keine eigene Dynamik Da es sich anbietet Transportmittel als mobile Komponenten zu repr sentieren wird oft vermutet da diese daher kein eigenst ndiges Verhalten zeigen d rfen Das folgende Beispiel ein Linienbus Verkehr ist kein auftragsgebundenes Transportsystem d h ein Bus f hrt auch dann wenn gar kein Fahrauftrag vorliegt Beim auftragsgebundenen Betrieb teilt der Fahrgast seinen Transportwunsch einer Vermittlungsstelle mit Diese w hlt ein Fahrzeug aus und teilt ihm den Transportauftrag mit Das Abfahren der Strecke jedoch wird in hnlicher Weise modelliert wie beim Linienbus Daher l t das Beispiel das Prinzip erkennen nach dem sich auch alle anderen Tranportsy steme wie Taxibetriebe Aufz ge fahrerlose Transportsysteme FTS Elektroh ngebahnen etc modellieren lassen Im allgemeinen geht man so vor da man alle mobilen Komponen ten Transportmittel in einer Basiskomponente zusammenfa t und darin das Abfahren der Strecken beschreibt Dieses Modell zeigt weiterhin wie auf die Location einer mobilen Komponente andere mobile Elemente aufgeladen und auch wieder entladen werden k nnen Beschreibung des Modells
48. Standardschnittstellen abzudecken Eine Ausnahme bilden lediglich solche Ein Ausgaben die vom Simulationsmodell selbst initiiert werden e Durch semantische Pr fungen mu sichergestellt werden k nnen da die Formulierun gen die ein Modell beschreiben vollst ndig und widerspruchsfrei sind Im Sinne der Informatik handelt es sich also um eine Spezifikation des Simulationspro gramms Eine Modellbeschreibungssprache ist daher eine Spezifikationssprache f r Simula tionsmodelle Wir unterscheiden deshalb fortan zwischen der Modellimplementation Simu lationsprogramm und der Modellbeschreibung Modellspezifikation Modellvorstellung Modellspezifizierung Modell Formale programmierung Modellbeschreibung automatische Modellgenerierung Simulationsprogramm Abb 1 4 1 Modellerstellung durch Spezifizierung Damit eine Modellbeschreibungssprache auch im praktischen Einsatz erfolgreich sein kann mu sie drei weitere Anforderungen erf llen e Die Sprache mu universell genug sein um eine breite Anwendungspalette abzudecken Der Anwender m chte die Gewi heit haben da sein Problem tats chlich mit Hilfe der Sprache behandelt werden kann und er nicht irgendwann auf un berwindliche Schwie rigkeiten st t Und er m chte die Sprache nicht nur f r einen Modelltyp einsetzen sondern auch f r andere Anwendungen Nur dann lohnt sich f r ihn der Aufwand die Sprache zu erlernen e Modelle m
49. System die Werte dieser Gr en aus seiner Umgebung bezieht Ausgangsgr en sind Gr en die von der Umgebung eines Systems beobachtet werden k nnen Sie h ngen von den aktuellen Werten der Eingangs und Zustandsgr en ab und k nnen daher auch als abh ngige Gr en bezeichnet werden Da ihr Wert ohne jeden Zeitver zug den Eingangs und Zustandsgr en folgt k nnte man sie auch Spontangr en nennen Jede Ausgangsgr e y wird durch eine Ausgabefunktion g beschrieben Ein System ohne Zustandsgr en zeigt auf gleiche Eingangsbelegung stets die gleiche Re aktion am Ausgang Erh lt man nicht immer die gleichen Werte am Ausgang macht man hierf r den aktuellen Zustand des Systems verantwortlich Der aktuelle Zustand wiederum stellt sich als Folge eines Anfangszustands und des bisherigen Verlaufs der Eingangsvariablen ein F r die nderung eines Zustands ist eine mehr oder weniger gro e Zeitspanne erforder lich Der Folgezustand zum Zeitpunkt t t wird f r jede Zustandsgr e z mit Hilfe einer lokalen Zustands berf hrungsfunktion f berechnet ee SYSTEM Eingangsgr en mit Ausgangsgr en Zustandsgr en Die Systemtheorie Pich 75 definiert die Zustandsdarstellung eines System S formal als ein 11 Tupel A B X Y Qo Q Z F G T to mit der Eingangszeitfunktion X t der Ausgangszeitfunktion Y t der Zustandszeitfunk tion Z t und den dazugeh rigen Wertemengen A B
50. Transportmengen bezeichnet mit ST fremder Komponenten nehmen zu k nnen EFFECT CONNECTION K1 B_1 gt K2 5B_1 K1 T_12 gt K2 ST_12 K1 K2 Bi HI SB1 T 12 J ST_12 156 4 Transporte zwischen Best nden Die Typen von Variablen sind daher die gleichen wie bei den Eigenschaftsvariablen Anstatt mit einer Wertemenge INT REAL operieren sie jedoch auch mit einer Menge von mobilen Elementen SET OF mobile component Wir wollen nun die bestehenden M glichkeiten diskutieren um mit der bestandsbezogenen Beschreibung Transportmodelle zu zerlegen und deren Vor und Nachteile aufzeigen Hierzu betrachten wir zwei Best nde zwischen denen bidirektionale Transporte stattfinden Tij 133 B_1 B_1 T_12 B_2 B_2 T_12 T_21 T2415 Bei dem Versuch die Best nde B_1 und B_2 und deren Zustands berf hrungsfunktionen in zwei verschiendene Komponenten zu legen f llt es sofort als st rend auf da die Trans portmengen T_12 und T_21 in beiden Komponenten ben tigt werden Die Transportmengen m ssen daher entweder e in einer Komponente Quellkomponente oder Zielkomponente ermittelt und an die andere Komponente weitergegeben werden e in beiden Komponenten ermittelt werden e in einer gesonderten Komponente bestimmt werden Dem Anwender stehen hiermit vier M glichkeiten zur Auswahl den Transport zwischen zwei Komponenten zu beschreiben
51. Variablen festgelegt die beobachtet werden sollen Die Parameter besagen zu welchen Zeitpunkten bzw bei welchen Ereignissen die Variablen be obachtet und bei einer Komprimierung zu welchen Zeitpunkten sie aufgezeichnet werden sollen Die Komprimierung eines Zeitverlaufs kann dadurch erfolgen da die Variablenwerte nur in bestimmten Zeitabst nden aufgezeichnet werden Minimum Maximum und Mittelwert der Verlaufsfunktion am Ende von periodischen Beobachtungsintervallen aufgezeichnet wird die zeitlich gewichtete Verteilung der Verlaufsfunktion am Ende des Simulationslaufs aufgezeichnet wird Die Steuerparameter dienen der Auswahl und der Parametrierung der verwendeten Algo rithmen Hierzu z hlen beispielsweise Zufallgeneratoren und deren Startwerte Damit der Anwender z gig und bersichtlich seine Experimente durchf hren kann sind diese Eingabe Schnittstellen komfortabel zu gestalten Insbesondere mu es m glich sein die Modellvariablen symbolisch zu benennen Wie die Arbeiten Lang 89 und Ulb 92 zeigen ben tigt man hierzu jedoch nur die Symbolinformation auf Datei Eine Codegenerierung zur Einrichtung dieser Schnittstellen ist nicht erforderlich Die Ausgaben eines Simulationsprogramms umfassen den nach Ablauf des Simulationslaufs erreichten Endezustand mit s mtlichen Modell variablen die Aufzeichnungen der Beobachter ggf ein Ablaufprotokoll und eine Ablaufstatistik Ablaufprotokoll und
52. Zerlegung eines Modells in mo dulare Bestandteile sprich Komponenten gestattet gelten die folgenden Anforderugen 1 Ein modularisiertes Modell mu exakt das gleiche Verhalten zeigen wie ein Modell das nicht zerlegt ist 2 Die Pr fbarkeit der Modellsemantik auf Korrektheit Eindeutigkeit etc mu ebenso gew hrleistet sein 3 Es darf zu keinen nennenswerten Einbu en an Laufzeiteffizienz kommen 4 Dem Anwender d rfen keine Restriktionen auferlegt werden nach welchen Gesichts punkten er die Modularisierung vorzunehmen hat 5 Eine Hierarchiebildung mu m glich sein 6 Die Formulierung einer Komponente mu unabh ngig von der Umgebung sein in der sie sp ter zum Einsatz kommt 7 Jede Modellkomponente sollte auch wie ein selbst ndiges Modell betrieben werden k nnen um ein Modell nach und nach aufbauen und testen zu k nnen 8 Die Komponenten sollten autonom sein d h jede Komponente ver ndert nur ihre eigenen Variablen beeinflu t aber nicht direkt die Variablen fremder Komponenten F r eine explizite Modelldarstellung bietet sich ein sehr einfaches Konzept an das die ge nannten Anforderungen erf llt 2 6 2 Modellzerlegung und Kommunikation zwischen Komponenten Die Attribute Konstanten und Variablen des Modells und deren Definitionsgleichungen werden auf einzelne Komponenten verteilt Diejenigen Variablen welche in den Modell gleichungen ben tigt werden aber nicht in der Komponente enthalten sind
53. auch an eine andere Station delegieren Zu diesem Zweck erzeugt sie einen Unterauftrag w hlt eine m gli che Station aus und schickt ihr den Unterauftrag zur weiteren Bearbeitung Wenn nicht in der Zwischenzeit ein anderer Bearbeitungsschritt erledigt werden kann ist der Auftrag solan ge blockiert Sobald der erledigte Unterauftrag zur ckgeliefert wird kann der urspr ngliche Auftrag wieder deblockiert werden Auf den Fortschritt der Bearbeitung eines Auftrag hat es demnach die gleiche Wirkung ob Betriebsmittel angefordert werden oder ein Unterauftrag erzeugt wird Neben dieser Auftragsabwicklung ist auch die Betriebsmittelnutzung zu modellieren Ein Betriebsmittel steht nicht die gesamte Zeit f r die Bearbeitung eines Auftrags zur Verf gung weil es m glicherweise auf oder abger stet wird oder eine St rung hat Auch die Betriebsmittelzuteilung ist von Bedeutung da eine Zuteilung m glicherweise an Bedingungen gekn pft ist Die Zuteilung eines Fahrzeugs ist beispielsweise nur dann m glich wenn es eine bestimmte Gr e besitzt Die Modellierung der Auftragsabwicklung und die Modellierung der Betriebsmittelnutzung liefern uns gerade die Leistungsgr en eines Systems Diese unterscheiden wir in prim re Leistungsgr en welche f r den Auftraggeber interessant sind und in sekund re Leistungs gr en an denen der Betreiber der Anlage Interesse hat Die prim ren Leistungsgr en wie Wartezeiten Bedienzeiten und Blockierzeit
54. auf die f r die Fragestellung wesentlichen Teile zu reduzieren Nur eine strenge top down Vorgehens weise kann hier zum Erfolg f hren Ausgehend von den interessierenden Gr en sind nach und nach alle wesentlichen Einfl sse zu erfassen 2 Der Anwender mu lernen sein Modell zustandsorientiert zu betrachten Gerade dis krete Modelle werden von Leuten mit Programmierkenntnissen zu gerne als eine Fol ge von Aktionen mit Zwischenzust nden gesehen Nicht Ablaufdiagramme sondern Darstellungen wie Zustands bergangsdiagramme Abh ngigkeitsgraphen oder System Dynamics Diagramme k nnen eine gute Hilfestellungen geben Der erste Punkt betrifft ganz allgemein die Systemanalyse und steht unabh ngig vom ver wendeten Simulationswerkzeug Dennoch tritt er haupts chlich bei einem universellen Werk zeug zutage Die herk mmlichen Simulationssprachen mit ihren Funktionsbl cken und noch viel mehr die Baustein Simulatoren dr ngen dem Anwender eine bestimmte Sichtweise der Realit t auf weil er sein Modell aus diesen Komponenten aufbauen mu Dies erweist sich aber in vielen F llen von gro em Nachteil ja es lenkt den Anwender so gar von den entscheidenden Zusammenh ngen ab So hat es sich herausgestellt da man ber die Leistungsf higkeit eines flexiblen Fertigungssystems keine vern nftigen Ausk nfte erh lt wenn man es in Werkst cke Paletten Maschinen Wechsler u s w d h in s mtli che Hardware Komponenten zerlegt Entscheidend i
55. bekannt sind H lt man sich die dort 1 5 Neue Anforderungen an die Simulationstechnik 17 vertretene Modellwelt vor Augen die aus Auftr gen sowie aktiven und passiven Betriebs mitteln besteht bekommt man eine konkretere Vorstellung von der erforderlichen Funktio nalit t Aktive Betriebsmittel Stationen nehmen Auftr ge entgegen und f hren diese evtl unter Verwendung weiterer Betriebsmittel aus Ein an einer Station ankommender Auftrag war tet zun chst bis er bedient werden kann Die Station bearbeitet dann diesen Auftrag gem dessen Arbeitsplan Schritt f r Schritt mit daf r vorgesehenen Zeitverz gerungen Der Ar beitsplan ist ein zyklenfreier gerichteter Graph dessen Knoten die Bearbeitungsschritte und dessen Kanten die Abh ngigkeiten von vorangegangenen Bearbeitungsschritten darstel len F r Graphen dieser Art findet man viele Bezeichnungen beispielsweise Vorranggraph Abh ngigkeitsgraph oder Reihenfolgegraph Schritt 1 Schritt 2 1 Schritt 2 2 Schritt 3 1 Schritt 4 Abb 1 5 1 Arbeitsplan als Vorranggraph Nachdem mit der Bearbeitung begonnen wurde kann der Auftrag bzw der Bearbeitungs schritt entweder vollst ndig zu Ende gef hrt werden unterbrochen werden weil ein wichtigerer Auftrag zu bearbeiten ist Verdr ngung unterbrochen werden weil eine vorgegebene Zeitscheibe abgelaufen ist blockiert werden weil auf die Zutei
56. bereits einen ersten Hinweis da die Beschreibung von Warteschlangen ber ein Positions Attribut nicht der geeignete Weg ist Bevor wir einzelne Sprachkonstrukte einf hren wollen wir kl ren welche Anforderungen damit abgedeckt werden sollen 3 2 Anforderungen Bereits in der Einleitung wurden die Anforderungen an die Funktionalit t einer Modellbe schreibungssprache er rtert Diese Anforderungen wurden einer ganz konkreten Anwendung entlehnt Da wir eine universell einsetzbare Sprache anstreben soll an dieser Stelle fest gestellt werden welche Anforderungen sich aus theoretischen berlegungen ergeben wenn man versucht mit folgender gedanklicher Modellvorstellung zu operieren Warteschlangen und Transportmodelle bestehen aus einer gr eren Anzahl von beweglichen Einheiten die sich durch einen Verbund von Attributen auszeichnen Aufgrund bestimmter Eigenschaften k nnen solche beweglichen Einheiten zu Mengen zusammengefa t werden Eine Mengenbildung erfolgt in der Regel um Einheiten die sich am gleichen physikalischen oder logischen Aufenthaltsort befinden zusammenzufassen Eine solche Menge kann man sich geordnet Warteschlange oder ungeordnet Warteraum vorstellen F r die Dynamik eines Modells ist es nun wichtig festzustellen wieviele bewegliche Einheiten mit bestimmten Eigenschaften sich an einem Aufenthaltsort befinden Ebenso ist es wichtig da bewegliche Einheiten mit bestimmten Eigenschaften aus einem Warterau
57. der Abh ngigkeitsgraph einen Zyklus Im ersten Fall sind die Gleichungen nicht unabh ngig da die erste Gleichung die zweite impliziert Im zweiten Fall sind die beiden Gleichungen widerspr chlich Der hier eingef hrte Abh ngigkeitsgraph wird sich als allgemein n tzliches Hilfsmittel f r die Analyse zustandsorientierter Modelle erweisen Neben der Pr fung auf korrekte Mo dellsemantik bringt er bei der Systemanalyse Klarheit ber die Wirkungen der einzelnen Modellgr en Beim Entwurf eines Algorithmus zur Abarbeitung der Modellbeschreibung wird er uns dienlich sein um Effizienz zu erreichen Und im Kapitel ber Modularisierung werden wir den Abh ngigkeitsgraphen schlie lich auf zusammengesetzte Modelle erweitern 2 3 Spezielle Zustands berf hrungsfunktionen Die Zustands berf hrungsfunktion Z F beschreibt in welchen Zustand zum Folgezeit punkt das Modell aus dem aktuellen Zustand bergeht Je nachdem welche Zeitmenge man f r die Modellzeit zugrunde legt ergeben sich verschie dene spezielle Formen f r die ZUF Da f r das Verst ndnis der Beispielmodelle die Kenntnis der m glichen ZUF erforderlich ist werden diese im folgenden nochmals in aller K rze vor gestellt F r die Kernaussagen dieser Arbeit ist jedoch die gew hlte Zeitmenge und Z F ohne Belang Alle Betrachtungen zur Semantik zur Effizienz oder zur Modularisierung unseres Program miermodells gelten f r jede Art von ZUF Unabh ngig davon mit welc
58. dies da eine mobile Komponente auf der Location einer fremder Komponente plaziert wird Dieser direkte Eingriff in den Zustand einer fremden Komponente bedeutet einen Verlust an Autonomie mit dem wir uns im n chsten Kapitel auseinandersetzen werden Transporte zwischen Locations erm glichen eine Beschreibung von Warteschlangenmodellen die auf abh ngige Mengenvariablen ganz verzichtet Auch die Bildung von Eigenschaftsmen gen ist nur noch in Ausnahmef llen n tig da es meist gen gt Teilmengen aus Locations auszugrenzen Der Sprachumfang kann damit verh ltnism ig klein gehalten werden Locations garantieren auch eine hohe Effizienz bei der Simulation der Modelle Das Ent nehmen bzw Einreihen einer mobilen Komponente sind Operationen die nur bei einem Transport ausgef hrt werden m ssen Dazu brauchen nur einzelne Elemente aus und ein gekettet werden Abh ngige Mengenvariablen oder Eigenschaftsmengen hingegen m ten jedesmal vollst ndig neu bestimmt bzw geordnet werden wenn sich f r ein mobiles Ele ment der Grundmenge der Wert eines Attributs ndert Die im letzten Kapitel diskutierten Ma nahmen zur Effizienzverbesserung k nnen in vollem Umfang genutzt werden 3 8 Zusammenfassung Zur Behandlung von Warteschlangensystemen wurde die bisherige Sprachsyntax durch eine Reihe von neuen Datentypen und Konstrukten erg nzt Elemente bzw mobile Komponenten dienen dazu die Auftr ge oder Teile zu modellieren die sich in Wa
59. dieser Vorgehensweise war klar da der fertigungstechnische Planer Erweite rungen an seinem Simulationssystem wegen des hohen Einarbeitungsaufwands in der Regel nicht selbst vornehmen kann Im Unterschied zu den datengesteuerten Baustein Simulatoren sind aber keine Eingriffe in die Simulationssoftware notwendig und daher k nnen Erweiterun gen auch von anderen qualifizierten Personen durchgef hrt werden Dienstleistungserbrin ger wie OR Abteilungen im eigenen Betrieb Unternehmensberatungen oder Ingenieurb ros w ren in der Lage diese Aufgabe bernehmen Auf diese Weise k nnte sich jeder Anwender die f r ihn relevanten Bausteine erstellen und in einer Modellbank ablegen lassen Die Forderung nach modularer Modellerstellung soll es demnach auch m glich machen Mo delle graphisch darzustellen bzw am Bildschirm einzugeben F r die Verwendbarkeit ei ner Modellbeschreibungssprache als Grundlage f r Baustein Simulatoren ist dieser Gesichts punkt von ausschlaggebender Bedeutung Die Modularisierung von Modellen wird daher ein zentrales Thema dieser Arbeit sein 24 25 Kapitel 2 Sprachentwurf im Sinne der klassischen Systemtheorie In diesem Kapitel sollen die Grundlagen der systemtheoretischen Modellbeschreibung erl utert werden Es handelt sich hierbei um eine spezielle Form der zustands orientierten Betrach tungsweise wie sie in den Ingenieurwissenschaften blich ist Wir wollen darstellen da diese Betrachtungsweise als Basi
60. e Modelluntersuchungen beginnt man meist mit kleinen Modellen und ist daher geneigt diese auf die Schnelle zu Programmieren Wird daraus allm hlich eine ernsthafte An wendung dann nehmen die Programme sehr schnell einen nicht erwarteten Umfang an Das liegt nicht nur daran da das Modell umfangreicher wird sondern vor allem auch daran da immer mehr Komfort f r das Experimentieren erforderlich wird will man nicht das Programm f r jedes Experiment neu bersetzen Die Erstellung von Benutzerschnittstellen die so gestaltet sind da der Anwender selbst mit dem Modell experimentieren kann erfordern einen nochmals deutlich h heren Zeitaufwand e Der Test eines Simulationsprogramms ist sehr aufwendig da sehr viele Situationen ausgetestet werden m ssen Dazu ist das Simulationsprogramm jedesmal gezielt in einen gew nschten Zustand zu bringen und die zu erwartenden Ergebnisse von Hand zu berechnen Ohne die M glichkeiten beliebige Anfangsbelegungen vorzunehmen und ausf hrliche Protokolle ausgeben zu lassen ist ein Test gar nicht praktikabel Zusammenfassend l t sich feststellen da a zwischen der Gedankenwelt des Anwenders und des Programmierers eine tiefe Kluft besteht b sich die Erstellung eines Simulationsprogramms als sehr anspruchsvoll und aufwendig erweisen kann Der Programmierer versteht zu wenig von der Anwendung und der Anwender versteht nicht das Simulationsprogramm Auf jeden Fall mu man davon ausgehen da d
61. eine Ablaufsteuerung und eine Verwaltung f r Zeitereignisse bereitgestellt Weiterhin werden diverse numerische Verfahren vor allem zur L sung von Differentialglei chungen oder zur Erzeugung von Zufallszahlen und evtl auch Verfahren zur Auswertung und Darstellung der Ergebnisse angeboten 1 3 Erstellung von Simulationsprogrammen 9 Ereignisse va implementiertes Programmrahmen Modell fiir Anwender x Differentialgleichungen System Unterprogramme Abb 1 3 1 Prinzipieller Aufbau eines Simulationspakets Die Programmierung diskreter Modelle wird ggf durch die Vorgabe einer Modellwelt un terst tzt f r die ebenfalls bereits eine Implementierung in Form von Unterprogrammen vorliegt So bietet das Simulationspaket GPSS FORTRAN Schm 84a b die Modellwelt der Simulationssprache GPSS Schr 91 bestehend aus Transactionen und diversen Stationsty pen wie Facility Pool oder Storage Weitere Vertreter f r Simulationspakete sind GASP IV Prit 74 und BORIS BORIS 85 Die vorgegebene Systematik entbindet den Programmierer davon eine eigene Programm struktur entwerfen und h ufig wiederkehrende Programmteile selbst entwickeln zu m ssen Simulationspakete bem hen sich darum durch einen geschickten Aufbau die Implementie rung des Modells von der Ablaufsteuerung und den brigen Systemprogrammen zu trennen Dadurch wird eine Modellimplementierung leichter nac
62. eine Modellbeschreibung gelangen Die Ursache liegt darin da Modellgleichungen vielfach aus allgemeinen Beziehungen ei ner Theorie abgeleitet werden Solche allgemeinen Beziehungen sind Bilanzgleichungen oder Gleichgewichtsbeziehungen Bilanzgleichungen besagen da eine Gr e innerhalb eines abgeschlossenen Gebietes kon stant bleibt Beispiel Die Summe aller Energien Massen Stoffmengen Impulse und Drehimpulse bleibt erhalten 2 1 Systemtheoretische Modellbeschreibung 29 Gleichgewichtsbeziehungen besagen da sich gleichartige Gr en die an einem gemeinsamen Punkt wirken zu Null summieren Beispiel Die Summe aller Kr fte Drehmomente Str me etc in einem gemeinsamen Punkt ist stets null Werden nun Zusammenh nge zwischen beteiligten Gr en durch nichtlineare Funktionen be schrieben dann erh lt man Gleichungen die nicht explizit nach allen Modellgr en aufl sbar sind Beispiel Reihenschaltung zweier Widerst nde ui U2 R Ry IC f Einer der Widerst nde zeigt lineares Verhalten der andere wird durch ein Polynom 3 Grades beschrieben F r die unbekannten Gr en U U1 U2 und I gelten die folgenden Beziehungen Bauelementegleichungen U Uo const U Beet Uz Ry I RoI Rz TP Maschengleichung Gleichgewichtsbeziehung U U Up Dieses Gleichungssystem ist nicht explizit nach J aufl sbar Im Falle diskreter M
63. es sich nicht etwa um Parameter die ein spezielles Modell charakterisieren sondern etwa um Auftragsdaten oder Arbeitspl ne Diese Informationen ben tigt der Anwender auch noch f r andere Zwecke und ist daher an einer zentralen Datenhaltung interessiert Diese Daten sind nicht selten in Datenbanken oder in einem benutzereigenen Format abgelegt Ebenso besteht die Notwendigkeit einer Datenausgabe die ber die M glichkeiten der ange botenen Beobachter hinausgeht wenn Ausgaben aufgrund besonderer Bedingungen und in speziellen Formaten erfolgen sollen Die W nsche der Anwender in Bezug auf Ein Ausgabe sind sehr vielf ltig und schwer genau er zu spezifizieren Offensichtilch kann man diesen W nschen nur nachkommen wenn man die M glichkeit anbietet Funktionen der Basissprache C aus dem Simulationsprogramm heraus aufzurufen F r diese L sung spricht auch eine weitere Anforderung Komplexere Steuerstrategien liegen h ufig bereits als Programme in einer h heren Programmiersprache vor Durch die bert ragung in eine andere Sprache w rden sich nur Fehler einschleichen und man w rde der M glichkeit beraubt per Simulation das Originalprogramm zu testen Aus diesen Gr nden und nat rlich wegen des Zeitaufwands ist es erw nscht das Originalprogramm unver ndert mit einzubeziehen Da es ohnehin als notwendig erachtet wurde Funktionen und Prozeduren anzubieten kann dem auch sehr leicht Rechnung getragen werden Es ist n mlich l
64. garantiert werden soll pr gen neben der Forderung nach modularer Modellzerlegung ganz entscheidend die Ausgestaltung der Sprache F r die Beherrschung umfangreicher Modelle f r die Wiederverwendbarkeit von Teil Mo dellen sowie f r eine Zusammenarbeit mehrerer Personen am gleichen Projekt ist die Mo dularisierbarkeit wesentlich und unverzichtbar Es zeigt sich jedoch da diese Forderung im Konflikt mit anderen Gesichtspunkten Eindeutigkeit und Autonomie steht und daher sehr sorgf ltig eine Kompromi l sung ausgearbeitet werden mu Die syntaktische Notation der entworfenen Sprache wird vollst ndig dargestellt Die theore tischen Ausf hrungen werden f r den Leser dadurch griffiger und die Beispiele sind in ihrer Ganzheit zu verstehen zu verstehen Es wird sich auch herausstellen da eine geeignete Syn tax einzelne Anforderungen an die Sprache unterst tzen kann Theoretische Betrachtungen neigen dazu m glichst allgemeine Formulierungen zuzulassen Abgesehen davon da komplexe Formulierungen wegen ihrer Un bersichtlichkeit selten ge nutzt werden wird die Implementierung sehr umfangreich und ineffizient in der Ausf hrung Daher werden geeignete Einschr nkungen diskutiert welche die Anwendungsbreite der Spra che nicht mindern aber viel zur Einfachheit und Effizienz beitragen Auf dem Gebiet der Simulation gibt es bislang kaum Betrachtungen ber das Thema Mo dellspezifikation auf die man Bezug nehmen oder auf die ma
65. getakteten Anlagen ein z giges Durchschleu sen stets gew hrleistet Es kann auch zu Verklemmungen kommen wenn beispielsweise zwei Teile auf der jeweils anderen Maschine weiterzubearbeiten sind und kein Ablageplatz mehr frei ist Um einen derart komplizierten Fertigungsablauf bew ltigen zu k nnen wird mittlerweile in der Produktion eine gr ere Anzahl an Rechnern eingesetzt welche die diversen Dispositions und Steuerungsaufgaben bernehmen Je h her die Flexibilit t der Anlage ist desto gr er ist die Bedeutung der Leit und Steuerungssysteme Die von ihnen eingesetzten Strategien m ssen m glicherweise detailgetreu nachgebildet werden wenn man spezielle Effekte unter suchen m chte Simulationsstudien sind ein geeignetes Mittel die Planung solch komplexer und schwer durchschaubarer Anlagen zu erleichtern und Fehlinvestitionen zu vermeiden Wegen der ho hen Vielfalt an Einrichtungen zum Fertigen Montieren Transportieren und Lagern und der besonderen Bedeutung der Steuerungsalgorithmen die in jeder Anlage individuell sind ist jedoch eine so breite Funktionalit t erforderlich wie es eigentlich nur von einem universell einsetzbaren Werkzeug erwartet werden kann Spezielle Simulatoren f r die Fertigungstech nik k nnen stets nur f r sehr spezielle Fragestellungen zum Einsatz kommen Die Gegebenheiten auftrags orientierter Fertigungsanlagen entsprechen ziemlich genau de nen wie sie von Betriebssystemen f r Rechenanlagen her
66. heren Komponenten wird durch Verbindungen von Sensorvariablen und internen Variablen eine Modellstruktur aufgebaut Die Modellstruktur mit Komponenten und Verbindungen l t sich sehr sch n graphisch veranschaulichen Beispiel A B z ff gt x x By Innerhalb eines Komponenten K stchens stehen die komponentenspezifischen Bezeichner am Rahmen des K stchens der Name der Komponente Die Pfeile weisen von einer inter nen Variablen auf eine oder mehrere Sensorvariablen und sind als Wirkpfeile zu verstehen Sie symbolisieren da von einer Komponente eine Wirkung auf eine andere Komponente ausgeht Durch eine Verbindung zwischen zwei Komponenten wird einer Komponente Information aus einer anderen Komponente zug nglich gemacht Es handelt sich demnach um einen lesenden Zugriff Schreibende Zugriffe sind in diesem Konzept nicht vorgesehen Die Ver nderung einer Varia blen kann nur von der betreffenden Komponente selbst vorgenommen werden Wir bezeich nen Komponenten deshalb auch als utonom Die G ltigkeit der Variablen beschr nkt sich nicht auf die Basiskomponente in der sie de klariert werden Sie sind auch in der dar berliegenden h heren Komponente bekannt Da den Sensorvariablen innerhalb einer Komponente bereits eine Zeitfunktion oder auch nur ein konstanter Wert zugeordnet werden kann ist es m glich eine Komponente auch dann als vollst ndiges Modell zu b
67. hrt werden mu 3 4 Einf hrung von Feldern 93 Indexpr fung auf der linken Gleichungsseite Erscheint der variable Index auf der linken Gleichungsseite d h bei der zu definierenden Variablen ergibt sich eine hnliche Situation Beispiel Z k TRUE WHEN k gt 0 AND Z k FALSE END Die Variable k habe f r gew hnlich den Wert null Sobald k einen positiven Wert annimmt wird Z k auf TRUE gesetzt und nicht mehr zur ckgenommen auch wenn k wieder null wird oder einen anderen Wert annimmt In dem Feld Z wird demnach festgehalten welche Werte die Variable k im Lauf ihrer Geschichte angenommen hat Eine Verletzung der Feldgrenzen l t sich nur sicher vermeiden wenn man gew hrleisten kann da die Variable k aus der Indexmenge des Feldes z entnommen ist Auch dies ist wiederum nur m glich wenn es sich um die gebundene Variable eines FOREACH Konstrukts handelt Pr fung auf Vollst ndigkeit Abh ngige Variablen m ssen vollst ndig d h f r jeden einzelnen Index definiert sein F r eine berpr fung zur Compilezeit ist es deshalb erforderlich da die Indices berechenbar sind Definiert man ein Feld von abh ngigen Variablen dann darf der Indexausdruck folglich keine anderen Variablen als die gebundene Variable eines Allquantors enthalten Die Pra xis zeigt gl cklicherweise da kein Bedarf daf r besteht andere Variablen im Index zu verwenden Beispiel ARRAY 1 N X REAL ARRAY 1 N Y REAL Y k 9 FOR
68. mathematische Beziehungen 2 1 3 Implizite M delldarstellimgen 2 2 ee et 22223 214 ws 2 1 4 Die explizite Modelldarstellung der Systemtheorie 2 1 5 Zusammenf gen von Systemen 2 2 2 2m n nennen 2 1 6 Modifizierte Zustandsdarstellung 2 222222 2 2 Semantische Korrektheit 22 Sy er Yang En ke ee ee OE ee 2 3 Spezielle Zustands berf hrungsfunktionen 2 2 2 222 nn 2 4 Grundkonstruktionen des Sprachkonzepts 2 2 2 nn nn nenn 2 4 1 Definitionsgleichungen esate ek ee Bud ak ul ea 2 4 2 Deklaration der Modellvariablen 2 2 4 3 Anfangsbelegung der Modellvariablen 2 4 4 Aufbau einer Basiskomponente 2 2 2m a 2 5 Algorithmus f r die Simulation einer expliziten Modelldarstellung 2 5 1 Der Grundalgorithmus Sry east Bass ote eh 2 5 2 Sortieren der statischen Beziehungen vu viii 2 5 3 Verbesserung der Effizienz ame a Harn aa Be Barrel 2 0 Modularisierunt org Aa a eena Breed ee Bg te se Gk eee A 2 6 1 Anforderungen Aue sce Ye ceils ig cat rac Hebe ee cp ea Ht ode uate Se rare Bees Bets 2 6 2 Modellzerlegung und Kommunikation zwischen Komponenten pe 2a ar ee al hehe eg an EM 2 05 Klassenbildung e wu 2 unse nase nase en nen Rh 2 6 4 Pr fung der semantischen Korrektheit 2 6 5 Hierarchische Modularisierung 2 2 2 22m 2 6 6 Sprachliche Konstrukte f r h here Kompone
69. ndern Wir k rzen diese Be zeichnungen bis auf das D f r distributed entry und unterscheiden nur noch Ausgangsbestand EXIT statt GDEXIT Eingangsbestand ENTRY statt GENTRY verteilter Eingangsbestand DENTRY statt GDENTRY Damit ergeben sich die folgenden einfacheren Regeln f r eine m gliche quivalenzierung PRIVATE SENSOR EXIT SENSOR 1 x ENTRY m 1 x EXIT n2 x DENTRY m 1 x EXIT k x TRANSIT TRANSIT SENSOR n x DENTRY m x EXIT k 1 x TRANSIT Ein oder mehrere Ausgangsbest nde k nnen demnach entweder mit einem einzigen Ein gangsbestand oder aber mit mehreren Durchgangsbest nden und verteilten Eingangsbest nden verbunden werden m x EXIT gt ENTRY mx EXIT gt k x TRANSIT gt nx DENTRY Aquivalenzierungen zwischen Ausgangs sowie zwischen Eingangsbest nden werden durch den Operator dargestellt da zwischen diesen Gruppen kein Transport m glich ist quivalenzierungen zwischen Durchgangsbest nden zeigt der Operator lt gt an F r alle brigen Aquivalenzierungen steht der Operator gt der in Transportrichtung zu zeigen hat 4 6 Transportbezogene Modularisierung mit Teilautonomie 175 Beispiel Zwei Ausgangsbest nde sind mit einem Eingangsbestand verbunden TRANSPORT CONNECTION K1 B K2 B gt K3 B K1 EXIT B K3 ENTRY B K2 EXIT B Da nur die Komponente K3 Elemente aus B entnimmt ist die Ein
70. nge zwischen Modellvariablen lassen sich nicht immer in geschlossenen Aus driicken ggf auch mit Fallunterscheidungen oder tabellarisch darstellen Insbesondere bei der Formulierung von Strategien wo eine Auswahl aus mehreren Alternativen zu treffen ist sind auch Schleifenkonstuktionen notwendig Beispiel Dieser Algorithmus sucht nach der Strategie SCAN aus einer Warteschlange Queue bei gegebener Position ActPos den in der aktuellen Richtung n chst gelegenen Auftrag PosDirec TRUE FALSE Der gr tm gliche Abstand bei N Positionen ist N 1 FUNCTION Scan SET OF Job Queue INT ActPos LOGICAL PosDirec gt INT DECLARE MinDist INT N INT IMin INT BEGIN N 80 IMin 0 MinDist N FOR i FROM 1 TO CARD Queue REPEAT IF PosDirec DO IF Queue Job i Pos gt ActPos DO Dist Queue Job i Pos ActPos END ELSE DO Dist ActPos Queue Job i Pos N ActPos END END ELSE IF Queue Job i Pos lt ActPos DO Dist ActPos Queue Job i Pos END ELSE DO Dist Queue Job i Pos ActPos ActPos 1 END END IF Dist lt MinDist DO MinDist Dist IMin i END END_LOOP 218 6 Spracherweiterungen ftir den praktischen Einsatz RETURN IMin END_FUNC Das Beispiel zeigt folgendes e Die beschriebene Strategie l t sich mit den bisherigen sprachlichen Mitteln nicht mehr beschreiben e Prozedurale Formulierungen ben tigen den gesamten Sprachumfang wie e
71. parts of models in a formal language in order to generate executable code from it In this book based on a new state oriented viewpoint the possibilites of formulating queuing systems and system components by means of a formal language are revisited and thoroughly discussed This was initiated by the fact that none of the former simulation languages enabled the modular decomposition of discrete models but from a different viewpoint system theory demonstrates for continuous models how modularization can be practiced in an ideal way A target was set up to transfer the advatages of the system theoretic concept to discrete models especially those involving queuing models But that way turned out to be difficult an lengthy Above all it became apparent that the original means of system theory enable a description of queuing systems in principle but not a modular model decomposition as hoped For this reason at first the theoretic and methodologic foundation to describe and simulate queuing systems had to be created as a useful supplement to the system theoretic paradigm Furthermore it turned out that the state oriented viewpoint of system theory and the tra ditionally procedural simulation languages have no similarities In the course of time the character of the desired language appeared more and more to be declarative This requires quite a different way of thinking from that used with procedural languages My dissertation Esch 90 deal
72. transit_location lt gt transit_location 210 5 Systematische Darstellung der Modellbeschreibungssprache exit_fusion exit_location exit_location exit_location o dentry_fusion dentry_location dentry_location dentry_location transit_fusion transit_location transit_location lt gt transit_location exit_location indexed_component indexed_location entry_location indexed_component indexed_location dentry_location indexed_component indexed_location transit_location indexed_component indexed_location indexed_identifier indexed_identifier indexed_component indexed_location Die Verwendung indizierter Komponenten Variablen und Best nde macht auch bei der For mulierung von Verbindungen in h heren Komponenten die Verwendung eines expliziten oder impliziten Allquantors m glich Dadurch wird die Strukturbeschreibung gro er Komponen ten mit regelm igem Aufbau stark vereinfacht 5 4 4 Initialisierung der Subkomponenten Die Anwendung des Klassenkonzepts gestattet den mehrfachen Einsatz der gleichen Modell komponente Die Vorbesetzung die bei der Definition einer Komponentenklasse angegeben ist gilt demnach f r alle Auspr gungen einer Klasse Eine individuelle Vorbesetzung kann in der h heren Komponente vorgenommen werden Die in den Subkomponenten durchgef hrte Vorbesetzung der Attribute kann
73. und Q der Zeitmenge T to ti deren Elemente in aufsteigender Ordnung vorliegen dem Anfangszustand Qo zum Zeitpunkt to d h Z to Qo der lokalen berf hrungsfunktion F wobei gilt Ziter FIX te Z t te der Ausgabefunktion G wobei gilt Y tk G X ltr Z t te Dieses Schema entspricht sehr gut der Anlage von Experimenten das System als unbekannter Wirklichkeitsausschnitt die Ausgangsvariablen als die f r die Fragestellung interessierenden 2 1 Systemtheoretische Modellbeschreibung 31 Gr en und die Eingangsvariablen als diejenigen Variablen von denen man einen Einflu auf die Ausgangsgr en erwartet Stellt man sicher da jede Zustandsgr e und jede Ausgangsgr e durch genau eine Be stimmungsgleichung definiert wird dann sind die Beziehungen zwangsl ufig vollst ndig und widerspruchsfrei Die Unabh ngigkeit wird dadurch erreicht da die Bestimmungsgr en Z tk 1 und Y t auf der rechten Gleichungsseite nicht vorkommen d rfen Eine korrekte Modellsemantik l t sich leider nicht mehr so einfach sicherstellen wenn wir Systeme zu einem gr eren Modell zusammenf gen 2 1 5 Zusammenf gen von Systemen Die zun chst unbestimmten Eingangsvariablen erm glichen es gr ere Modelle aus Teilsy stemen zusammenzusetzen Den Zeitverlauf einer Eingangsvariablen erh lt man indem man diese mit einer Ausgangsvariablen eines anderen Systems gleichsetzt Sind alle Eingangsva
74. verwenden mu Ein weiterer Nachteil liegt darin da Steuerungs Strategien nicht oder nur bei spezi eller Systemkenntnis in das Modell eingebracht werden k nnen 1 3 Erstellung von Simulationsprogrammen 11 Datengesteuerte Simulatoren Simulationssprache Modellbeschreibungssprache Simulationspaket Implementierungssprache Abb 1 3 2 Werkzeuge zur Erstellung von Simulationsprogrammen Simulationssprachen Schon mit Beginn der sechziger Jahre entstanden die ersten Simulationssprachen GPSS Schr 91 SIMSCRIPT Russ 83 SLAM PriPed 79 und SIMAN Ped86 auf dem Gebiet der diskreten Simulation Vergleich in Prit 82 und CSSL CSMP und ACSL auf Gebiet der kontinuierlichen Simulation Alle Sprachen zur Formulierung diskreter Modelle erm glichen eine proze orientierte Be schreibung Man beschreibt gewisserma en die Lebensgeschichte eines Auftrags Werkst cks Fahrzeugs etc der in Warteschlangen Puffer Abstellpl tze etc ruht und von Betriebsmit teln Maschinen Streckenabschnitten zeitverz gert bearbeitet wird transactions orientierte Simulation Mit Ausnahme von SIMSCRIPT lassen sich die Betriebsmittel nicht individuell modellieren sondern nur aus vorgefertigten Beschreibungsbl cken zusammensetzen Durch diese Verein fachung wird allerdings eine komfortable Handhabung der Modelle auch erst m glich Da der proze orientierte Ansatz durch diese Einschr
75. welche Aktionen des Modells dar stellen als auch die Anweisungen welche die Reihenfolge dieser Aktionen festlegen analysiert 1 3 Erstellung von Simulationsprogrammen 7 e Gr ere Simulationsprogramme werden sehr schnell un bersichtlich wenn man sich nicht strikt an einen geeigneten Programmierstil h lt und sind daher keine Aufgabe f r einen unerfahrenen Anwender Der Grund liegt darin da ein Modell viele paral lel ablaufende Aktivit ten beinhaltet die in einer geeigneten Reihenfolge sequentiell abgearbeitet werden m ssen Hierdurch wird vor allem eine modulare Zerlegung des Programms zum Problem e Wegen der schlechten Lesbarkeit f llt es schwer ein ohne Werkzeuge erstelltes Simu lationsprogramm zu ndern zu erweitern oder durch einen anderen Programmierer fortf hren zu lassen Die Weitergabe an einen Fachkollegen bringt diesem meist wenig Nutzen e Die Analyse einer Reihe von bestehenden Simulationsprogrammen ergab da diese h ufig methodische Fehler enthalten und die Aktionen nicht in einer geeigneten Rei henfolge ausgef hrt werden Insbesondere ist f r die Modellvariablen meist nicht klar festgelegt ob der neu errechnete Wert zum aktuellen Zeitpunkt oder f r den folgenden Zeitpunkt G ltigkeit besitzt Die Reaktion des Programms auf gleichzeitig eintretende Ereignisse ist damit nicht klar bestimmt und so erzeugen Simulationsprogramme mit derartigen Fehlern immer wieder berraschende nicht gewollte Ergebnisse
76. wenn einzelne Entwicklungen schneller oder langsamer verlaufen als angenommen es werden immer dieselben Folgen eintreten Um diese Strukturen z B positive oder negative R ckkopplungen anschaulich darzustel len entstand eine graphische Darstellungsmethode die unter dem Namen System Dynamics Forr 72a Forr 72b Forr 73 bekannt wurde Dar ber hinaus wurde auch die Simulations sprache DYNAMO Crae 85 entwickelt die eine unmittelbare Umsetzung einer System Dy namics Darstellung in eine Programmiersprache erlaubt und die auch heute noch Verwen dung findet Wegen der vagen Daten verzichtet DYNAMO bzw System Dynamics auf Differentialglei chungen und begn gt sich mit Differenzengleichungen zur Beschreibung des dynamischen Modellverhaltens Auch Ereignisse sind nicht vorgesehen weil auch hierzu pr zise Angaben notwendig sind Die Modelle dienten schlie lich in erster Linie dazu m gliche Entwicklungen aufzuzeigen und sollten keine exakten Vorhersagen liefern Gerade wegen dieser Beschr nkungen hat System Dynamics au erhalb der Wirtschafts und Sozialwissenschaften aber nie Beachtung gefunden oder gar Bedeutung erlangt Dies ist scha de da es nur wenige Methoden gibt etwa Blockdiagramme der Regelungstechnik Bondgra phen welche es erlauben aus der graphischen Modelldarstellung den vollst ndigen Satz von Modellgleichungen abzuleiten Um tats chlich ber ein Modell diskutieren zu k nnen ist dies aber eine Notwendigkeit Die me
77. wenn zu ihrer Bestimmung nicht ber Sensorvaria blen auf Variablen fremder Komponenten zugegriffen werden mu Variablen einer Gruppe werden in der gleichen Ebene ausgef hrt Dadurch vermindert sich in der Regel die Zahl der Komponentenaufrufe Beispiel Gruppe 0 1 1 1 1 n Bm mn e Bm mn 1 1 1 1 Gruppe 0 Sind die Gleichungen sortiert k nnen sie zu einer einzigen Gruppe zusammengefa t werden d h alle Berechnungen k nnen in einer Ebene ausgef hrt werden Man kommt mit zwei Komponentenaufrufen aus Werden Werte von Variablen anderer Komponenten ben tigt dann m ssen erst diese Werte ermittelt werden bevor mit der Berechnung begonnen bzw fortgefahren werden kann Um die korrekte Reihenfolge einzuhalten sind die importierten Variablen einer anderen Gruppe zuzuordnen und vorher zu berechnen Beispiel Einwirkung einer anderen Komponente Gruppe 0 2 2 2 a mO GD Bd Gn Ga Gia 1 1 1 Gruppe 0 Die optimale Bearbeitung besteht darin da die abh ngigen Variablen der Kompo nente K2 in der Gruppe 1 die der Komponente K1 in der Gruppe 2 ausgef hrt werden Auch hier kommt man mit zwei Komponentenaufrufen aus 74 2 Sprachentwurf im Sinne der klassischen Systemtheorie Bestehen R ckwirkungen oder Wechselwirkungen dann k nnen die internen Variablen einer Komponente nicht mehr gemeinsam in einer G
78. wird bei kontinuierlichen Transporten in der Regel nicht vorgenommen Die Transportrate r j steht demnach sowohl f r den Transport von 7 nach 7 als auch f r den Transport von 7 nach 2 Dies bedeutet da die Transportraten sowohl positive wie negative Werte annehmen k nnen a bestandsbezogene Beschreibung F r jeden Bestand 5 wird eine Gleichung angegeben welche alle in den Bestand hin einflie enden Str me ber cksichtigt Diese k nnen auch negatives Vorzeichen besitzen RATE B_j B_j SUM_k r_ij zufliessende bzw abfliessende Stroeme b transportbezogene Beschreibung F r jeden Transportweg zwischen zwei Best nden wird eine Gleichung folgender Form angegeben RATE B_i gt B_j Bi gt B_j r_ij W t 4 3 Beschreibung von Transporten zwischen Best nden 143 4 3 3 Diskrete Transporte Die Transportfunktion Tj ist in diesem Fall eine diskrete Funktion und liefert eine positive ganze Zahl die nur dann von Null verschieden ist wenn ein Transport von Bestand B nach Bestand B stattfindet Der Wert der Funktion zeigt an wieviele Einheiten zum aktuellen Zeitpunkt den Bestand wechseln To ok ee falls Transportbedingung erf llt Bu 0 sonst Da der Hin und R cktransport zwischen zwei Best nden nur selten zeitlich zusammenf llt ist f r jede Transportrichtung eine eigene Transportfunktion anzugeben a bestandsbezogene Beschreibung Bij B_j SUM_i T_ij SUM_i T_ji zuf
79. zu erstellen oder zumindest bestehende Modelle zu modifizieren 250 8 Zusammenfassung Aus dieser formalen Modellbeschreibung sollte es dann m glich sein mittels eines Compilers ein effizient ausf hrbares Simulationsprogramm zu generieren das mit den n tigen Schnitt stellen versehen ist um in einer Experimentierumgebung ablauff hig zu sein Da die Modellierung auftrags orientierter Systeme hohe Anforderungen an die Funktionalit t stellt sollte eine universell einsetzbare Sprache d h eine Sprache mit einem elementaren Ab straktionsniveau geschaffen werden Dadurch sollte gleichzeitig ein breites Anwendungsfeld erschlossen und eine detailgetreue Modellierung sichergestellt werden Die Sprache sollte auch als Basis f r Baustein Simulatoren dienen k nnen und einen gra phischen Modellaufbau erm glichen Die wichtigste Voraussetzung hierf r war es Modelle modular und hierarchisch aufbauen zu k nnen Der L sungsweg Von der in der Systemtheorie blichen Modelldarstellung war bekannt da sie die genannten Anforderungen erf llt und sich auch sehr gut f r die Umsetzung in eine Computersprache eignet Zudem ist es m glich die kontinuierliche und die diskrete Modellierungswelt in einem einheitlichen Konzept unterzubringen Dies zeigte sich bereits als Ergebnis meiner Disserta tion Esch 90 In dieser Abhandlung wurde nun untersucht ob dieses Paradigma d h die explizite zu standsorientierte Modelldarstellung auch fiir die
80. 1 gt B2 T_12 B2 gt B3 T_23 B2 gt Bi T_21 B3 gt B2 T_32 Eine komponentenweise Zerlegung nach Transportgleichungen bedingt da der Bestand B_2 in beiden Komponenten auftritt Dabei handelt es sich jedoch nicht nur um einen lesenden Zugriff d h um die reine Beschaffung von Information aus einer fremden Komponente Vielmehr k nnen beide Komponenten auf den Bestand B_2 gleichberechtigt zugreifen Die beiden Komponenten teilen sich gewisserma en den Bestand B_2 Bil B_3 F r eine Modularisierung bedeutet das da B_2 in beiden Komponenten zu deklarieren ist und in der h heren Komponente eine quivalenzierung vorgenommen werden mu Diese Gleichsetzung mit der M glichkeit eines Transports bezeichnen wir als Transportverbindung Der Operator lt gt deutet an da ein Transport in beiden Richtungen stattfinden kann TRANSPORT CONNECTION K1 B_2 lt gt K2 B_2 K1 K2 Bi B2 D B2 B1 4 5 Modularisierung 163 Zu einem Widerspruch kommt es wenn die Initialisierung des Bestandes B_2 nicht in beiden Komponenten identisch ist In diesem Fall ist es erforderlich da die quivalenzierung in der h heren Komponente mit einer Vorbesetzung versehen wird welche die Vorbesetzungen der darunter liegenden Komponenten berschreibt K1 B_2 lt gt K2 B_2 lt initial_value gt Auch eine Hierarchisierung der Modelle ist m glich und wird sp ter noch au
81. 1 Bestimmung der Transportmenge in der Quellkomponente Bringen von Elementen T12 ff ST_12 ST 21 k BT 21 T12 IN B1 T21 IN B2 Bit B1 T12 B 9 B2 ST12 ST_21 T21 Die Menge der zu transportierenden Elemente wird an die andere Komponente tiber mittelt Gegen ber den sp ter angef hrten M glichkeiten ergeben sich in diesem Fall nur Vor teile e Eindeutigkeit l t sich gew hrleisten e Kompaktheit Die Transportmenge wird nur einmal bestimmt 4 5 Modularisierung 157 e Verst ndlichkeit Die Verbindungen geben Aufschlu ber einen Transportpfad Die Richtung der Verbindung stimmt mit der Transportrichtung berein 2 Bestimmung der Transportmenge in der Zielkomponente Holen von Elementen B1 ff SB_1 SB_2 f B2 T21 E ST21 ST_12 k E T12 T21 IN SB2 T 12 IN SB1 Bir B1 ST 12 B2 B2 T12 T21 ST 21 Neben der Menge der zu transportierenden Elemente sind an die andere Komponente auch die beteiligten Best nde zu bermitteln In diesem Fall ergeben sich nur Nachteile o Eindeutigkeit l t sich f r den Transport individueller Elemente nicht gew hrleisten Ein Ele ment kann von der eigenen ebenso wie von einer fremden Komponente bewegt werden o Kompaktheit Es sind zus tzliche Sensorvariablen und Verbindungen erforderlich o V
82. 1 und y_2 2 4 Grundkonstruktionen des Sprachkonzepts 45 F r das WHEN Konstrukt ist eine korrekte Semantik sehr leicht zu gew hrleisten Die Ein deutigkeit ist durch die sukzessive Fallunterscheidung erreicht worden und Vollst ndigkeit ist immer dann gegeben wenn auf den ELSE Zweig nicht verzichtet wurde Es wurde bereits erw hnt da man auf die Angabe des ELSE Zweiges in Fallunterscheidun gen verzichten kann wenn ein Differentialquotient oder eine Ereignisfunktion definiert wird F r diese F lle l t sich eine sinnvolle Vorbesetzung angeben die darauf hinausl uft da sich der Wert der Variablen nicht ver ndert Eine solche Vorbesetzung ist aber nur f r Zustandsvariable nicht aber f r abh ngige Variable m glich Bei der Definition von abh ngigen Variablen darf daher der ELSE Zweig nicht weggelassen werden Der Nachweis der korrekten Semantik beim IF Konstrukt erfordert sehr viel mehr Aufwand Die Vollst ndigkeit verlangt da eine Variable in allen Zweigen eines IF Konstrukts mit einer Definitionsgleichung vertreten sein mu Anstelle einer Definitionsgleichung kann in einem IF Zweig wiederum ein IF Konstrukt stehen das seinerseits diese Variable in allen Zweigen zu enthalten hat Die Eindeutigkeit verlangt da eine Variable die durch ein IF Konstrukt bereits vollst ndig definiert ist nicht an anderer Stelle nochmals definiert wird Beispiel IF x gt c LET vol 1 IF z gt 0 LET y_2 x X END ELSE LE
83. 149 4 4 Diskussion der Eindeutigkeit am Problem der Ver teilung Die Beschreibung der Transportvorg nge in einem Modell ist dann eindeutig wenn nicht der Fall eintreten kann da ein Element an zwei verschiedene Orte transportiert werden soll Probleme mit der Eindeutigkeit k nnen daher immer dann auftreten wenn Elemente aus einem Bestand auf zwei oder mehrere Best nde verteilt werden Zum Studium der m glichen Konfliktf lle und zum Vergleich der verschiedenen Gegebenhei ten wollen wir wiederum zwischen kontinuierlichen diskreten mengenweisen und element weisen Transporten unterscheiden ee Oral 4 4 1 Kontinuierlicher Transport 1 Bestimmen der Transportraten 7 12 4 53 r_13 of iN 2 Beschreibung des Zustands nderung a bestandsbezogen Bett pS se Ss rS B_2 r_12 B_3 r_13 b transportbezogen B_1 gt B_2 r_12 BI gt B_3 r_13 In beiden F llen sind die Differentialquotienten eindeutig definiert Wenn wie in den meisten Fallen zur Berechnung der Transportraten keine Fallunter scheidungen n tig sind brauchen diese nicht gesondert berechnet werden sondern k nnen bei der Angabe des Differentialquotienten bestimmt werden 150 4 Transporte zwischen Best nden 4 4 2 Diskreter Transport 1 Bestimmen der Transportfunktionen IF cond_12 LET T_12 n_12 END ELSE LET T_12 0 END IF cond_13 LET T_13 n_13 END ELSE LET T_13 0 END 2 Beschreibung des Z
84. 3 J IN B_1 J Typ B AND cond_13 EMPTY B_3 Job 1 10 1 Bestimmen der Transportfunktion T_12 4 J IN B_1 cond_12 Job 1 n_12 T_13 4 J IN B_1 cond_13 Job 1 n_13 2 Beschreibung des Zustands bergangs a bestandsbezogen BLIS t Bet Sao T213 B_2 B_2 T_12 B_3 B_3 T_13 durch Angabe der Differenzen DELTA B_1 T_12 T_13 DELTA B_2 T_12 DELTA B_3 T_13 komponentenweise CHANGE B_1 T_12 CHANGE B_2 T_12 CHANGE B_1 T_13 CHANGE B_3 T_13 b transportbezogen T_12 gt B_2 T_13 gt B_3 elementweise FOREACH Job IN B_1l LET IF Job IN T_12 LET Job gt B_2 END IF Job IN T_13 LET Job gt B_3 END END Die Beschreibung entspricht der beim diskreten Transport mit dem Unterschied da die Best nde Mengen statt Anzahlen ausdr cken da Mengenvariablen anstelle von Wertvaria blen beteiligt sind Statt Summe und Differenz stehen hier die Operationen Mengenvereini gung und Mengendifferenz 152 4 Transporte zwischen Best nden Aber es taucht hier ein Problem auf das beim diskreten Transport nicht besteht Die Bestim mung der Transportmengen auf die obige Art gew hrleistet nicht da die Transportmengen Tig und Tig disjunkt sind Es ist n mlich nicht ohne weiteres erkenntlich ob sich die Be dingungen cond_12 und cond_13 gegenseitig ausschlie en Dies ist aber eine notwendige Voraussetzung daf r da f r jedes Element aus B eindeutig bestimmt is
85. 3 2 Kontinuierliche Transporte a2 Ha nal a a el 142 4 3 3 Diskrete Transporte oa 2a we an ee a ea an 143 4 3 4 Mengenweise und elementweise Transporte 144 4 3 5 Gemeinsamkeiten bei der Beschreibung von Transporten 145 4 3 6 Bestandsbezogene Beschreibung des Transports ohne explizite Bestimmung der Transportmenge 146 4 4 Diskussion der Eindeutigkeit am Problem der Verteilung 149 4 4 1 Kontmui rlicher Transport 23er eed ao dak ee 2 149 4 4 2 Diskreter Transport 2 Sy ale ea RE ale eben aoe ee 150 4 4 3 Mengenweiser Transport 22 4 2 2 60 Gos 2 ans See Bil 150 4 4 4 Das DEVIDE Koanstrukt 2 00 2 44 32 2832 Ben da Bern 152 4 4 5 Elementweiser Transport 2 2 on nn 153 4 3 Modularis ernne s 22 6 wer en a a a Dt Bee er 155 4 5 1 Modularisierung mit bestandsbezogener Beschreibung 155 4 5 2 Modularisierung mit transportbezogener Beschreibung 4 6 Transportbezogene Modularisierung mit Telautonome 5 35 SE EEE a Bac ee amp ep aA 4 6 1 Typisierung der Best nde nach Zugriffsrechten 2 2 2 2 2 4 6 2 Eingrenzung der Typenzahl f r Eingangs und Ausgangsbest nde na 2 Sr De RR RR 4 6 3 Hierarchiebildung mit Best nden 4 7 Quellen und Senken u 22 St 2 2 Keen re ea a 4 8 Beziehungen zu System Dynamics 2 2 2 Can nn 4 9 Z s mmenfassung eK a A ee et oad Systematische Darstellung der Modellbeschreibu
86. 7 Algorithmus fiir die Simulation einer modularen Modellbeschreibung Die Betrachtungen in diesem Abschnitt gehen davon aus da man ein modular beschrie benes Modell komponentenweise bersetzen m chte Wegen des Klassenkonzepts bedeutet dies da der bersetzte Code f r jede Komponentenklasse nur einmal vorhanden ist w hrend die Datenbereiche f r jede Auspr gung einer Klasse angelegt werden Neben der Speicher platzersparnis liegen die Vorteile vor allem darin da nach der nderung einer einzelnen Komponente nicht das gesamte Modell neu bersetzt werden mu Verzichtet man auf die getrennte bersetzbarkeit lassen sich alle Bestimmungsgleichungen in ein gemeinsames Programm packen Es kann dann der bereits besprochene Algorithmus eingesetzt werden wenn zuvor alle Gleichungen des Modells in eine geeignete Reihenfolge gebracht werden 2 7 1 Der Grundalgorithmus f r modulare Modelle Um die getrennte bersetzbarkeit der Modellkomponenten zu gew hrleisten mu mit einem etwas erweiterten Algorithmus gearbeitet werden Das liegt daran da die Gleichungen auf mehrere Unterprogramme verteilt sind und ein Sortieren der Gleichungen nur noch innerhalb einzelner Modellkomponenten m glich ist Beispiel y g la j g2 x 2 fila y2 g2 z2 1 vu F Lo a z F ee z E m J 0 In welcher Reihenfolge man auch immer die beiden Komponenten aufruft eine
87. 9 Die Ziffern geben an zu welchem Teil des Grundalgorithmus der jeweilige Ausschnitt geh rt Bei der R ckw rts Verfolgung werden die Marken aller Variablen abgefagt welche auf die zu berechnende Variable Einflu haben Beispiel R ckw rts Verfolgung Der Algorithmus mit Marken zur R ckw rts Verfolgung sieht f r obiges Beispiel aus schnittsweise etwa so aus 1 Vorbesetzung t Flag TRUE y_i Flag TRUE fuer alle i aus 1 NY z_i Flag TRUE fuer alle i aus 1 NZ z_i Flag FALSE fuer alle i aus 1 NZ 3 Falls z_2 Flag dann ende Falls z_1 Flag oder y_2 Flag dann ende y_2 Value g 2 z_2 Bei Wertaenderung dann y_2 Flag TRUE ende y_1 Value g_1 z_1 y_2 Bei Wertaenderung dann y_1 Flag TRUE ende 56 2 Sprachentwurf im Sinne der klassischen Systemtheorie 4 Falls t Flag oder y_1 Flag oder y_4 Flag dann z_1 Value f_1 y_1 y_4 t Bei Wertaenderung dann z_1l Flag TRUE ende ende Falls y_5 Flag dann z_2 Value f_2 y_5 Bei Wertaenderung dann z_2 Flag TRUE ende ende Falls z_2 Flag oder z_3 Flag dann z_3 Value f_3 z_2 z_3 Bei Wertaenderung dann z_3 Flag TRUE ende ende 6a t t t Falls realer Zeitfortschritt dann t Flag TRUE sonst t Flag FALSE 6b Fuer alle i aus 1 NY y_i Flag FALSE Fuer alle i aus 1 NZ z_i Flag FALSE Fuer alle i aus 1 NZ Falls z_i Flag dann z_i z_i
88. AL 0 NR INT 0 DEPENDENT VARIABLE N_RQ INT SENSOR VARIABLE N_SR INT RANDOM VARIABLE TBetween REAL EXPO Mean 10 Transporte von Reservoir nach Queue a a ca cc a a a es a ee ee IF T gt TGenera LET N_RQ 1 TGenera T TBetween END ELSE LET N_RQ 0 END Aenderung in der Belegung des Reservoirs NR N_R N_SR N_RQ 4 1 Motivation 135 SSS SS SS Oe Se E oe ee eee ee ee eee Se ee Hoehere Komponente H aerate ae a ae Se Se ese SS SS ae SS ee aS a SS a a ee EEE 22a Hannes SUBCOMPONENTS Q S R EFFECT CONNECTIONS Q N QS gt S N_QS S NS gt Q NS S N_SR gt R N_SR R N_RQ gt Q N_RQ R Q N_In R N_RQ R N_In S NSR E NSR N_In Q S S N_In Q N_QS NOS ff gt N_In N_In NSR NS F Ns Q NS S NS Verglichen mit dem entsprechenden Modell das individuelle Elemente enthalt und mit Trans portoperationen beschrieben wurde ist die Formulierung dieses Modells wesentlich umfang reicher und weniger leicht verst ndlich Es wurde auch bereits erw hnt da bei einer verteilten Beschreibung des Transports we der die Frhaltung der Elemente sichergestellt ist noch das Auftreten negativer Best nde ausgeschlossen werden kann Wegen dieser Nachteile wollen wir pr fen ob die Einf hrung der Transportoperation auch f r Modelle Vorteile bringt die keine individuellen
89. AarlLerJumen ea dey et ee aed ha E dev a 4 a Mw KAO 3 5 6 Probleme der Modularisierung ze icae ose s ara 3 6 Einf hrung von Mengenvariablen als abh ngige Variablen 112 3 6 1 Variablen f r Indexmengen lt i ou 4 6 see ss see 112 3 6 2 Variablen f r Mengen aus Feldelementen 113 3 6 3 Beschreibung von Transporten 2 22 2 2m 114 3 6 4 Namen von Mengen a Sur SE Da u Bd ee ig 115 3 6 5 Modellierung eines M D 1 Systems 2 2 2220 115 3 6 6 Modularisierung mit Mengenvariablen 117 3 7 Einf hrung von Mengenvariablen als Zustandsvariablen zum sen SoS Pt IS Soe Se eh a NG 119 3 7 1 Locations und mobile Komponenten 120 3 7 2 Modellierung eines M D 1 Systems 0 123 3 7 3 Modularisiering mit Locations 2 2 na Sa at 8 amp eos ri 124 3 7 4 Methodologische Gesichtspunkte 2 22 222mm nennen 126 3 8 Zusammenfassung aooaa a 127 Transporte zwischen Best nden 129 AN Motiv tioi e ee p be he Se re Be ae Le ee 129 ASA POSE len m s r test Bl mul Nes AAE Gi ak ee Hl at oy atte Fe at dele N anae ale a Gla 136 4 2 1 Die Eigenheiten von Best nden 00 2 008 136 4 2 2 Bestandsgr en und Eigenschaftsgr en im Vergleich 137 4 2 3 Bedeutung der Bestandsgr en 2 2 2 138 4 3 Beschreibung von Transporten zwischen Best nden 140 4 3 1 Allgemeine Betrachtungen 2 2 22m nn n 140 4
90. Ablaufstatistik geben Aufschlu ber die ausgef hrten Aktionen des Simulationsprogramms und deren Anzahl und sind eine Hilfe beim Test des Simulationsmo dells Endezustand und Aufzeichnungen der Beobachter sind in einem offengelegten Datenformat abzuspeichern Auf diese Weise kann die Nachbereitung sowohl durch das Simulationssystem als auch durch fremde benutzereigene Auswerte und Darstellungsprogramme evtl nach einer Konvertierung des Datenformats vorgenommen werden 1 2 Aufgaben eines Simulationsprogramms 5 Um bei einem Trainingssimulator das Verhalten eines Modells im laufenden Betrieb studie ren zu k nnen ist neben den bereits genannten Schnittstellen eine Kommunikation mit externen Programmen z B ber TCP IP vorzusehen Diese Kommunikation dient einer seits der fortlaufenden Ausgabe von Beobachtungen andererseits der fortlaufenden Eingabe von Geschehnissen aus der Umgebung z B das Dr cken eines Gaspedals welche auf die Dynamik des Modells Einflu nehmen F r die Ein und Ausgabe mu das Modell geeignete Variablen bereitstellen Auch f r diese Schnittstelle ist keine individuelle Codegenerierung sondern nur Symbolinformation auf Datei erforderlich Ein Echtzeitbetrieb oder ein echtzeitproportionaler Betrieb als Trainingssimulator l t sich herzustellen indem der Simulator immer wieder aufs neue von au en angesto en wird und stets nur bis zu einem vorgegebenen Zeitpunkt weiterl uft Auch f r eine derart
91. Auf diese Art lassen sich sowohl Detailuntersuchungen als auch globale Betrachtungen durchfiihren 1 5 3 Diskussion der L sungsans tze Aus dem bisher gesagten wird klar da jede Art von Programmiersprache auch eine objek torientierte und auch ein Simulationspaket nicht geeignet ist diese Anspr che zu erf llen Programmiersprachliche Konzepte wie Zeiger sind f r einen Nicht Informatiker nicht be herrschbar Dazu fehlt ihm das Grundwissen und vor allem auch die n tige bung Seitdem die genannten Anforderungen im Rahmen der berlegungen zu CIM Konzepten aufgestellt und propagiert wurden gab es vier gr ere Projekte mit denen man versuchte zu einsatzf higen L sungen zu kommen DOSIMIS III entwickelt am Fraunhofer Institut in Dortmund und WHITNESS eine ame rikanische Entwicklung sind zwei datengesteuerte Baustein Simulatoren mit integrierten Steuerungsstrategien f r die Transportbausteine Sie verf gen ber eine beeindruckende gra phische Bedienoberfl che die graphischen Modellaufbau Experimentieren Animation und Ergebnispr sentation im gleichen Layout erm glicht Die Vorgabe eines Sortiments an Bausteinen l t keine speziellen Maschinentypen zu Es sind aber gerade die Spezialmaschinen an deren Verhalten man besonders interessiert ist da sie sehr teuer sind meist eine zentrale Rolle im Fertigungsablauf spielen und mit ihnen keine Betriebserfahrung vorliegt In erster Linie liegen ihre Schw chen aber darin
92. Bestandstypen EXIT ENTRY und DENTRY f r praktische Anwendungen ausreichend ist und in der Regel nur wenig Bedarf f r eine detailliertere Vergabe der Rechte besteht Jede der beteiligten Komponenten kann die Transportrichtung festlegen und damit eine berpr fung der Verbindung veranlassen ob denn eine weitere Komponente beteiligt ist die einen Transport in umgekehrter Richtung vornimmt Dar ber hinaus kann eine Komponente die Elemente hereinholt verf gen da keine weitere Komponente Hole oder Schreibrecht auf diese Elemente erh lt Auf diese Weise l t sich ein eindeutiger Zugriff sichern W hrend eine Komponente mit der Vereinbarung eines Bestands vom Typ TRANSIT auf ihre Autonomie vollst ndig verzichtet tritt sie mit der der Deklaration eines Eingangs oder Ausgangsbestandes nur soviel Autonomie wie n tig an fremde Komponenten ab 4 6 Transportbezogene Modularisierung mit Teilautonomie 177 Wir meinen damit eine annehmbare L sung gefunden zu haben die den unterschiedlichen F llen der Modellierungspraxis gerecht wird Der Sprachumfang wird dadurch nur geringf gig erweitert die Sicherheit beim Modellieren und das Verst ndnis des Modells jedoch sehr gef rdert Zahlenm ige Eingangs und Ausgangsbest nde Wenn Best nde nicht durch individuelle Elemente sondern durch einen Zahlenwert ausge dr ckt werden ist die eben vorgenommene Unterscheidung in verschiedene Bestandstypen ebenfalls interessant Zwar spielt der ei
93. CAL unterscheidet Aus einer derartigen Modellbeschreibung l t sich Code generieren der eine fast optimale Laufzeiteffizienz besitzt Es gibt also keinen Grund ein Modell nur deshalb in einer proze duralen Sprache abzufassen weil es sich schneller ausf hren lie e Modelle sind modularisierbar und k nnen hierarchisch in Komponenten zerlegt werden Die Modularisierbarkeit erm glicht zudem eine Modellbeschreibung auf zwei verschiedenen Ab straktionsniveaus Sieht man von den mobilen Komponenten ab dann wird auf der untersten Hierarchie Ebene die Modelldynamik beschrieben und auf den dar berliegenden Ebenen die Modellstruktur Liegen wie in vielen F llen alle ben tigten Basiskomponenten bereits vor so ist es aus reichend lediglich die Modellstruktur anzugeben Die Formulierung eines Modells ist dann besonders einfach und vor allem auch graphisch darstellbar Wegen des Klassenkonzepts bestehen auch besonders umfangreiche Modelle in der Regel nur aus wenigen verschiedenen Modellkomponenten Sind diese sorgf ltig getestet dann k nnen hierarchisch zusammengesetzte Modelle im Grunde kein fehlerhaftes Verhalten zeigen es sei denn die Verbindungen wurden nicht richtig vereinbart Man erh lt daher auch f r gro e Modelle ein hohes Ma an Zuverl ssigkeit Das Konzept der modularen Zerlegung erm glicht auch den Aufbau von Modellbanken Dar unter sind Sammlungen von Modellkomponenten zu verstehen die in einem bestimmten An wen
94. Das Modell Linienbus beschreibt Busse die auf einem Ringkurs fahren und an den Haltestel len Fahrg ste ein und aussteigen lassen An jeder Haltestelle befindet sich eine Quelle welche Fahrg ste mit ihrem Fahrziel erzeugt Aussteigende Fahrg ste werden nach ihrer Ankunft in einer Senke vernichtet H H Der bersichtlichkeit halber ist die Dynamik sehr einfach gehalten Der Leser hat aber sicherlich keine Schwierigkeiten sich vorzustellen da ebenso variable Fahrzeiten Fahrtun terbrechungen Einstiegs und Ausstiegszeiten etc ber cksichtigt werden k nnten Es w re auch auf sehr einfache Art m glich weitere Busse in den Fahrkurs einzuschleusen oder Busse dem Betrieb zu entziehen MOBILE COMPONENT Passagier 7 6 Das Modell Linienbus 245 DECLARATION STATE VARIABLE DISCRETE Ort INT Ziel INT Il N e END OF Passagier MOBILE COMPONENT Bus MOBILE SUBCOMPONENTS OF CLASS Passagier DECLARATION STATE VARIABLE TStation REAL StatNo INT Il oO gt Ankunft an der naechsten Station aktuelle bzw Ziel Station Il fo PRIVATE LOCATION Plaetze SET OF Passagier 0 Passagier END OF Bus BASIC COMPONENT Quelle MOBILE SUBCOMPONENTS OF CLASS Passagier DEFINITIONS TABULAR DISTRIBUTION RanZiel INT gt REAL BY LINEAR INTERPOLATION ON a 2 Sig Aula 10 gt 0 15 0 25 0 30 1 00 DECLARATI
95. Des halb ist daf r zu sorgen da die Variablen jeder einzelnen Auspr gung vorbelegt werden k nnen Beispiel Al z A2 z 2 I r 2 6 4 Pr fung der semantischen Korrektheit Ein Modell das in Komponenten zerlegt ist mu nat rlich den gleichen Anforderungen an die Semantik gerecht werden wie ein nicht zerlegtes Modell Insbesondere bedeutet dies da die Zyklenfreiheit des Abh ngigkeitsgraphen nicht verletzt sein darf 62 Beispiel 2 Sprachentwurf im Sinne der klassischen Systemtheorie Komponente A Komponente B Be e ee es y_1 g_1 z y g x z Woe g_2 y_1 Die Verbindungen werden beschrieben durch A y gt Bux B y_2 gt A X Wahrend die beiden Komponenten fiir sich genommen semantisch korrekt sind ergibt sich durch die vorgenommenen Verbindungen ein Zyklus A y g B y_2 z B y_1 gi Ay B y_2 g_2 B y_1 Um einen solchen Zyklus auf h herer Ebene zu erkennen m ssen nicht die Abh ngigkeiten von s mtlichen Modellvariablen bekannt sein Vielmehr gen gt es zu wissen von welchen Sensorvariablen die Ausgangsvariablen abh ngen Beispiel F r die beiden Komponenten A und B gen gt die folgende verk rzte Information Komponente A Komponente B y g x y_ 1 g_1 z y_2 g_2 z Bei den Verbindungen A y gt B x B y_2 gt A X ergibt sich A y g y_2 B y_2 g_2 A y 4 2 Wie man sofort sieht l t sich a
96. EACH i IN 2 N LET Y i 2 x X i END Da man nicht davon ausgehen kann da die Variable k stets den Wert 1 annimmt mu man eine unvollst ndige und wahrscheinlich auch nicht eindeutige Definition annehmen Pr fung auf Eindeutigkeit Die Eindeutigkeit hingegen l t sich durch eine weniger weit gehende Forderung sichern Enth lt der Indexausdruck einer zu definierenden Variablen eine andere als eine gebundene Variable verbietet man lediglich da f r irgendein Feldelement dieser Variablen eine weitere gleichzeitig g ltige Definitionsgleichung in der Modellbeschreibung erscheint Unterstellt man n mlich da der variable Index jeden m glichen Wert annehmen kann dann kommt es wenigstens bei einem Wert zum Konflikt 94 3 Spracherweiterungen zur Formulierung von Warteschlangenmodellen Beispiel ARRAY 0 4 Z REAL IF T gt TNext LET z 0 0 WHEN k 0 AND x lt 0 END Z k x k k 1 MOD 5 TNext T 10 END Alle 10 Zeiteinheiten wird die Variable x abgetastet und die letzten 5 Werte in den Feldelementen der Zustandsvariable Z zyklisch abgespeichert Dabei soll die Zustandsvariable Z 0 den Wert null annehmen wenn x kleiner als 0 ist F r k 0 und x lt 0 ist aus der angegebenen Modellbeschreibung jedoch nicht eindeutig ersichtlich welchen Wert Z 0 annehmen soll Eine L sung durch die oben genannte Einschr nkung ist tragbar da sich solche Probleme durch eine alternative syntaktische Formulieru
97. ENTRY von diesem Be stand holen Durch eine geeignete Kommunikation kann innerhalb der h heren Komponente ein eindeutiger Zugriff hergestellt werden A ENTRY LOCATION D XH gt A X B X X DENTRY XH B X DENTRY Da die neu vereinbarte ENTRY Location nach au en hin auf das Recht zu Bringen verzichtet darf innerhalb der h heren Komponente keine Verbindung zu Locations anderen Typs EXIT oder TRANSIT hergestellt werden DENTRY LOCATIONS Eine DENTRY Location f r eine h here Komponente kann durch Verbindung mit einer oder mehreren DENTRY Locations aus Subkomponenten vereinbart werden A DENTRY LOCATION D XH gt A X B X X DENTRY XH B X DENTRY Da die neu vereinbarte DENTRY Location nach au en hin auf das Recht zu Bringen verzich tet darf innerhalb der h heren Komponente keine Verbindung zu Locations anderen Typs EXIT oder TRANSIT hergestellt werden 180 4 Transporte zwischen Best nden TRANSIT LOCATIONS Eine TRANSIT Location kann in einer h heren Komponente durch Verbindung mit e einer oder mehreren TRANSIT Locations oder e einer Kombination aus EXIT und DENTRY Locations vereinbart werden Zusammen mit einer TRANSIT Location k nnen auch einzelne EXIT oder DENTRY Locations mit einbezogen werden Anders ausgedr ckt Eine TRANSIT Location kann durch Verbindung mit einer einzelnen TRANSIT Location aus einer Subkomponente oder durch Verbin
98. Elemente enthalten 136 4 Transporte zwischen Best nden 4 2 Best nde 4 2 1 Die Eigenheiten von Best nden Die Einf hrung von Locations war mit der Forderung verbunden da jedem Element genau eine Menge zuzuordnen sei F r die Mengen m ssen hierzu zwei Voraussetzungen erf llt sein e Die Mengen m ssen disjunkt sein e Die Vereinigung aller Mengen mu die Gesamtheit aller Elemente umfassen Mengen die diese Voraussetzungen erf llen bezeichnen wir als Best nde Die Vereinigung aller Best nde bildet den Gesamtbestand des Modells G B UB U B3 B Bs By Abb 4 2 1 Zerlegung eines Gesamtbestandes in 3 Teilbest nde Ein Transport bewegt Elemente von einem Bestand zu einem anderen ordnet diesen Elemen ten also einen anderen Bestand zu Der Transport ist eine Operation die den Gesamtbestand an Elementen im Modell nicht ver ndert In einem abgeschlossenen Modell d h in einem Modell das weder Quellen noch Senken besitzt in dem also Elemente weder erzeugt noch vernichtet werden bleibt die gesamte Anzahl an Elementen in jedem Zeitpunkt Zustand konstant In einem abgeschlossenen Modell gilt daher f r die Elemente aller Best nde der Erhaltungssatz Die Zerlegung des Gesamtbestandes in disjunkte Teilmengen d h in einzelne Best nde kann dabei nach Gesichtpunkten vorgenommen werden die der Modellbildung dienlich sind In der Regel fa t ein Bestand elementare Einheiten nach r umlichen oder logischen Ge
99. FECT CONNECTIONS Q Entrance gt R Exit S Entrance gt Q Exit R Entrance gt S Exit R R Exit Q Entrance Entrance S Exit R Entrance Exit Q S Exit Q Exit S Entrance 5 Exit p go u Entrance Entrance Das Bild zeigt eine Modellzerlegung in die drei Komponenten Q S und R mit den erforderli chen Verbindungen Die Modellbeschreibung f r jede dieser drei Komponenten erlangt damit folgendes Aussehen STATE VARIABLE Entrance Queues Queue SENSOR VARIABLE Exit Queues Bewegung von Queue nach Exit Server Sa See Se oe ee a ee ae ee eS FOREACH i IN 1 N LET IF i IN j IN 1 N Job j Ort Queue INC Job j TEntry 1 LET IF EMPTY j IN 1 N Job j Ort Exit LET Job i Ort Exit Job i TEntry T END END END 3 5 Einf hrung von Indexmengen 111 STATE VARIABLE Entrance Queues Server SENSOR VARIABLE Exit Queues Bewegung von Server nach Exit Reservoir Sa SS a a a a a alnacgenn FOREACH i IN 1 N LET IF i IN j IN1 N Job j Ort Server LET IF T gt Jobli TEntry TService LET Job i Ort Exit Jobli TEntry T END END END za EZ Ein anal Zossen Sn nase nn Komponente R Basar u zn az an Ss zycn sn a ca ca oe i Se ee STATE VARIABLE Entrance Queues Reservoir SENSOR VARIABLE Exit Queues Bewegung von Reservoir nach Exit
100. Konzeption einer deklarativen und zustandsorientierten Sprache zur formalen Beschreibung und Simulation von Warteschlangen und Transport Modellen Peter Eschenbacher Juni 1993 Habilitationsschrift erschienen bei SCS Society for Computer Simulation Int Frontiers in Simulation Band 1 ISBN 1 56555 047 1 Vorwort Die vorliegende Arbeit entstand als Habilitationsschrift am Lehrstuhl fiir Betriebssysteme IMMD 4 der Universitat Erlangen Niirnberg Sie behandelt die theoretischen berlegungen die der Modellbeschreibungssprache SIMPLEX MDL zugrunde liegen Diese Sprache ist Bestandteil des Simulationssystems SIM PLEX II dessen Entwicklung im Rahmen des Forschungsvorhabens PAP Projekt fiir fle xibel automatisierte Produktionssysteme in den Jahren 1985 1992 von der Firma Siemens gefordert wurde Ziel dieses Projekts war es eine Arbeitsumgebung zu schaffen mit deren Hilfe die Simulati on von geplanten Produktionssystemen wesentlich erleichtert werden sollte Nach M glich keit sollte der fertigungstechnische Planer Simulationsstudien ohne fremde Hilfe durchf hren k nnen Die zu Projektbeginn verf gbare Software machte eine mehr oder weniger aufwendige Pro grammierung der Modelle erforderlich wof r spezielles Personal eingesetzt werden mu te Um diesem Mi stand abzuhelfen entstanden seit dieser Zeit viele Simulationprogramme die es erlauben Modelle aus vorgefertigten Grundbausteinen mit Hilfe einer graphischen B
101. OBILE COMPONENT Job DECLARATIONS STATE VARIABLES Ort NAME SET OF Job NAME Reservoir TEntry REAL 0 END OF Job 118 3 Spracherweiterungen zur Formulierung von Warteschlangenmodellen DIMENSION CONSTANT N 100 ARRAY 1 N Job DEPENDENT VARIABLE Queue SET OF Job SENSOR VARIABLE Exit SET OF Job Queue J IN Job J Ort NAME Queue INC J TEntry Bewegung von Queue nach Exit Server FOREACH J IN Job LET IF J IN Queue Job 1 LET IF EMPTY Exit LET J Ort NAME Exit J TEntry T END END END DEPENDENT VARIABLE Server SET OF Job SENSOR VARIABLE Exit SET OF Job Server J IN Job J Ort NAME Server INC J TEntry Bewegung von Server nach Exit Reservoir FOREACH J IN Job LET IF J IN Server Job 1 LET IF T gt J TEntry TService LET J Ort J TEntry END NAME Exit T END END 3 7 Einf hrung von Mengenvariablen als Zustandsvariablen 119 SSS SS SS SS SS SS oe ee SS a ee eee eS a See ee eS Komponente R aS eee ee eee ee ee SS eS SS eS ee Sa Se SS a DEPENDENT VARIABLE Reservoir SET OF Job SENSOR VARIABLE Exit SET OF Job Reservoir J IN Job J Ort NAME Reservoir INC J TEntry Bewegung von Reservoir nach Exit Queue a Sat a Se ae N a SS eS ee ee FOREACH J IN Job LET IF J IN Reservoir Job 1 LET IF T gt TGenera LET J Ort NAME Exit J TEntry T TGenera T TBetween END END END Gegen ber de
102. ONS STATE VARIABLES DISCRETE TAnkunft REAL 0 RANDOM VARIABLES TZwischen REAL EXPO Mean 1 RanZiel INT DistZiel EXIT LOCATION Ausgang SET OF Passagier SOURCE LOCATION PassQuelle SET OF Passagier 246 DYNAMIC BEHAVIOUR IF T gt TAnkunft LET TAnkunft T TZwischen FOREACH P IN PassQuelle Passagier 1 LET P Ziel RanZiel P gt Ausgang END END OF Quelle BASIC COMPONENT Senke MOBILE SUBCOMPONENTS OF CLASS Passagier DECLARATIONS ENTRY LOCATION Eingang SET OF Passagier SINK LOCATION PassSenke SET OF Passagier DYNAMIC BEHAVIOUR Eingang Passagier i gt PassSenke END OF Senke BASIC COMPONENT Linienbus MOBILE SUBCOMPONENTS OF CLASS Passagier Bus DEFINITIONS DIMENSION NStat 10 TABULAR FUNCTION Fahrzeit INT gt REAL ON 1 2 3 y TO gt 142 18 2 255 ur gy 145 7 Anwendungen 7 6 Das Modell Linienbus 247 DECLARATIONS PRIVATE LOCATION Strecke SET OF Bus 10 Bus ENTRY LOCATION ARRAY 1 NStat Eingang SET OF Passagier EXIT LOCATION ARRAY 1 NStat Ausgang SET OF Passagier INITIAL CONDITIONS Strecke Bus 1 StatNo 1 Aufenthaltssort zu Beginn Strecke Bus 2 StatNo 3 DYNAMIC BEHAVIOUR FOREACH B IN Strecke LET END TE LET END T gt B TStation Aussteigen der Fahrgaeste FOREACH P IN B Plaetze P Ziel B StatNo LET P gt Ausgang B StatNo P Ort B StatNo END Einsteigen der Fahrgaeste
103. Quellen noch Senken sind anderen Komponenten zug nglich Quellen und Senken d rfen berall dort verwendet werden wo sonst auch Best nde stehen d rfen Da eine Quelle potentiell unendlich viele Elemente enth lt darf jedoch nie auf die Quelle als Ganzes zugegriffen werden Eine Quelle ist stets auf die n tigen Elemente zu beschneiden Beispiele 1 SOURCE LOCATION Wasserhahn REAL 1 PRIVATE LOCATION Becher REAL 1 SINK LOCATION Ausguss REAL 1 Wasserhahn gt Becher 0 1 1 s kontinuierlicher Fluss in einen Becher Becher gt Ausguss 0 5 1 s Ausschuetten des Bechers 182 4 Transporte zwischen Best nden 2 SOURCE LOCATION Lieferant INT PRIVATE LOCATION Lager INT SINK LOCATION Kunde INT Lieferant gt Lager Liefermenge diskreter Zugang in ein Lager bei Lieferung Liefermenge gt 0 Lager gt Kunde bei Abholung Abholmenge gt 0 3 SOURCE LOCATION Auftragsquelle SET OF Job PRIVATE LOCATION Queue SET OF Job Server SET OF Job SINK LOCATION Auftragssenke SET OF Job IF T gt TGenera LET Auftragsquelle Job 1 gt Queue Entnahme von Auftraegen aus TGenera T TAbst einem Quellvorrat END IF CARD Server lt NUnits LET FOREACH J IN Queue LET J gt Server J TReady T TWork END END FOREACH J IN Server T gt J TReady LET Server Job 1 gt Auftragssenke Ausschleusen eines Auftrags END auf eine Senke Quelle u
104. Queue SS Sr Sa na nit ill 2asL sie FOREACH i IN 1 N LET IF i IN j IN 1 N Job j Ort Reservoir 1 LET IF T gt TGenera LET Job i Ort Exit Jobli TEntry T TGenera T TBeteen END END END Betrachten wir das Beispiel genauer dann stellen wir eine ganze Reihe von Unzul nglichkei ten fest 1 Die Wertemenge der Variablen Ort d h alle m glichen Aufenthaltsorte eines Elements mu bereits bei der Deklaration der mobilen Komponente Job vollst ndig bekannt sein 2 Jede Komponente hat ber den Index prinzipiell Zugang zu allen mobilen Elementen einer Klasse Eine komponentenweise Zerlegung ergibt jedoch nur dann einen Sinn wenn eine Komponente auf einen Teil ihrer Zugriffsm glichkeiten verzichtet Hierf r gibt es aber bislang keine Vorkehrungen 112 3 Spracherweiterungen zur Formulierung von Warteschlangenmodellen 3 Das Klassenkonzept kann nicht eingesetzt werden da alle Instanzen einer Klasse die selben Aufenthaltsorte verwenden w rden 4 Die berpr fbarkeit der Eindeutigkeit durch den Compiler mu te aufgegeben werden 5 Die Zustandsvariable Entrance mutet k nstlich an da sie nur der Weitergabe eines einzelnen Wertes dient 6 Die Pfeile welche die Komponenten miteinander verbinden verlaufen entgegen der Transportrichtung und dienen damit nicht dem Verst ndnis des Modells auf h herer Ebene Wie wir feststellen m ssen handelt es sich hier nicht mehr um eine Modulari
105. T IF Job i Ort Q AND EMPTY j IN 1 N Job j Ort S LET IF Job i Pos 1 LET Job i Ort S ELSE LET Job i Pos Job i Pos 1 END END END Bereits dieses einfache Modell macht eine Reihe von Erweiterungen notwendig Zu einem Auftrag geh ren die Attribute Ort und Pos Um diese Verbindung deutlich zu machen sind Verbunde von Attributen erforderlich Damit die Modellbeschreibung nicht f r jeden einzelnen Auftrag erstellt werden mu werden Felder von Modellelementen und eine Art Allquantor FOREACH eingef hrt 3 2 Anforderungen 85 Es mu weiterhin festgestellt werden ob sich ein Auftrag in der Bedieneinheit befindet es also einen Auftrag gibt dessen Attribut Ort den Wert S besitzt Hierf r ist eine Mengenbildung oder zumindest eine Funktion zum Feststellen der Kardinalit t einer Menge erforderlich Das Beispiel zeigt auch bereits Probleme die typisch f r die weiteren Ausf hrungen dieses Kapitels sind Die Vorbesetzungen der Zustandsvariablen gelten f r alle Auspr gungen der Klasse Job Hieraus resultiert da zun chst alle mobilen Elemente den gleichen Ort und die gleiche Position besitzen Zumindest aber die Position mu individuell vorbesetzt werden Von einer Zustandsvariable wie dem Attribut Pos erwartet man normalerweise da sie zu jedem Zeitpunkt jeden beliebigen Wert aus ihrer Wertemenge annehmen kann Dies ist of fensichtlich nicht der Fall und wir haben an dieser Stelle
106. T y_2 x END END ELSIF x lt c LET y i 1 IF z gt 0 LET y_2 x x END ELSE LET y_2 x END END ELSE LET y_1 0 y2 0 END Die abh ngigen Variablen y_1 und y_2 sind sowohl eindeutig wie vollst ndig definiert Mit den in diesem Abschnitt vorgestellten sprachlichen Mitteln l t sich bereits das dyna mische Verhalten eines diskreten oder kontinuierlichen Modells beschreiben Auf die Syntax f r Ausdr cke expression wurde an dieser Stelle nicht n her eingegangen weil sich der Leser an anderen h heren Programmiersprachen orientieren kann N heres findet sich zudem in Kapitel 5 Auch sei auf Esch 90 bzw Esch 91 verwiesen Es f llt auf da sich die vorgestellte Syntax nicht von der vieler anderer h herer Program miersprachen unterscheidet Dies mag auf den ersten Blick irritierend sein Wie es sich aber zeigte ist der Anwender sehr schnell in der Lage sich auf die ver nderte Bedeutung der Konstrukte einzustellen und zu erkennen da sie nicht der Ablaufsteuerung sondern zur Fallunterscheidung bei der Definition von Variablen dienen Durch die berpr fung der Vollst ndigkeit und Eindeutigkeit durch den Compiler wird ihm die Semantik der Sprache sehr schnell bewu t gemacht Neben der Definition der Variablen ist selbstverst ndlich auch eine Typvereinbarung und Initialisierung erforderlich Dies behandelt der n chste Abschnitt 46 2 Sprachentwurf im Sinne der klassischen Systemtheorie 2 4 2 Dek
107. TBetween END END 3 6 Einf hrung von Mengenvariablen als abh ngige Variablen 117 Das Beispiel deckt allerdings noch einige Schwierigkeiten auf So stellt sich das Problem wie eine Vorbesetzung des Ortes vorgenommen werden kann da idealerweise bei der Deklaration der mobilen Elemente noch gar keine Aufenthaltsorte bekannt sind Diese sollten erst innerhalb der statischen Komponenten vereinbart werden Ein anderes Problem ist da die Zustandsvariable Ort nur dann aussagekr ftig ist wenn eine mobile Komponente stets genau einer der drei Mengen angeh rt d h nicht gleichzeitig in einer anderen Menge als der zugewiesenen enthalten ist Die Mengen die einen Aufenthaltsort repr sentiern m ssen dazu disjunkt sein Die korrekte Festlegung der Mengen ist jedoch vollst ndig dem Anwender berlassen 3 6 6 Modularisierung mit Mengenvariablen Durch die Einf hrung von Mengenvariablen ist es m glich geworden Informationen ber Mengen an andere Komponenten weiterzugeben EFFECT CONNECTIONS Q Queue gt R Exit S Server gt Q Exit R Reservoir gt S Exit R R Exit Q Queue Reservoir S Exit R Reservoir Exit Q S Exit Q Exit S Server a Exit le Queue Server Das Bild zeigt eine Modellzerlegung in die drei Komponenten Q S und R Die Modellbe schreibung fiir jede dieser drei Komponenten erlangt damit folgendes Aussehen M
108. Transportgleichung ein a Bestandsbezogene Beschreibung eine Gleichung pro Bestand B_i B_i T_ij T_ji B_j B_j T_ij T_ji b Transportbezogene Beschreibung eine Gleichung pro Transportweg B_i gt B_j B_j gt B_i T_ij T_ji Finden mehrere Transporte von und zu einem Bestand statt dann sind die Modellbeziehun gen entsprechend zu erg nzen a Bestandsbezogene Beschreibung eine Gleichung pro Bestand B_j BI SUM_i T_ij SUM_i T_ji i IN Et zufliessende abfliessende Transportmengen 142 4 Transporte zwischen Best nden b Transportbezogene Beschreibung eine Gleichung pro Transportweg B_1 gt B_j T_1j Boy gt B_1 IE B_2 gt B_j T_2j BET gt B_2 T_j2 B_i gt B_j T_ij B_j gt B_i T_ji zufliessende abfliessende Transportmengen Die quivalenz zwischen bestands und transportbezogener Beschreibung ist uns bereits von Transporten mit individuellen Elementen bekannt Mit den folgenden Ausf hrungen pr zisieren wir die transportbezogene Beschreibung auch f r diskrete und kontinuierliche Transporte 4 3 2 Kontinuierliche Transporte Die Transportfunktion gibt in diesem Fall diejenige Transportmenge an die pro Zeiteinheit zwischen Bestand B und Bestand B flie t Differentialquotient Wir bezeichnen diese Gr e auch als Transportrate r B Einheit der Transportrate rj 2 el Eine Unterscheidung der Transportrichtung
109. Unterteilung des Zu standsraumes bersichtlicher zu beschreiben ist Gleichzeitig bringt es den Effekt mit sich da die zu definierende Gr e stets eindeutig definiert ist Mehrdeutigkeiten schlie t die Syntax von vornherein aus Diese Art von Pragmatik stie in Diskussionen immer wieder auf Skepsis Daher seien an dieser Stelle die wichtigsten Einw nde und Gegenargumente zusammengestellt Die sonst in einer deklarativen Sprache vorzufindende Reihenfolgeunabh ngigkeit der Aus sageformen ist in diesem Fall scheinbar verletzt weil die einzelnen Zweige der Fallunterschei dung nicht vertauschbar sind Die Sprache weist an dieser Stelle vermeintlich gar prozedurale Z ge auf Man mu sich jedoch dar ber im klaren sein da nur die Definitionsgleichung als Ganzes d h mit allen Zweigen eine vollst ndige Aussageform darstellt Die Definitionsgleichungen selbst lassen sich auch weiterhin in beliebiger Reihenfolge anordnen F r den Ausdruck auf der rechten Gleichungsseite gelten ohnehin eigene Gesetze So wird ein arithmetischer Ausdruck nach Priorit tsregeln z B Punkt vor Strich interpretiert Auch hier ist eine bestimmte Abarbeitungsreihenfolge ausschlaggebend Ein anderer Einwand ist da die Bedingungen so ungl cklich formuliert sein k nnen da ein Zweig gar keine Ber cksichtigung findet Beispiel fiV falls z lt 5 u sonst fV falls z lt 3 sonst fV Der zweite Fall wird vom ersten vollst ndig mit eingeschloss
110. VA H WK verteilbare Eingangsbestande DENTRY L WA S WA B VA H WA Quellen SOURCE L WK S WK B VK H WK Senken SINK L WK S VK B WK H VK Sensorbest nde SENSOR L WA S VA B VA H VA Durchgangsbestande sind f r alle frei zug nglich Ausgangsbest nde verzichten auf das Recht zu holen und r umen anderen das Recht zu bringen ein Dadurch k nnen mehrere Ausgangs best nde zusammengeschlossen werden Eingangsbest nde verzichten auf das Recht zu bringen Verteilbare Eingangsbest nde r um en auch anderen das Recht zu holen ein und k nnen daher zusammengeschlossen werden und auch mit Durchgangsbest nden verbunden werden Einfache Eingangsbest nde nehmen das Recht zu holen exklusiv wahr und d rfen daher nur mit einer oder mehreren Ausgangs best nden verbunden werden Quellen halten f r den Benutzer stets eine unendliche Menge von Elementen vor w hrend Senken ankommende Elemente sofort aus dem Modell entfernen Sensorbest nde d rfen le send auf fremde Best nde und deren mobile Elemente zugreifen location_declaration_part PRIVATE LOCATION S loc_course_specific_declaration ENTRY LOCATION S loc_course_specific_declaration DENTRY LOCATION S loc_course_specific_declaration EXIT LOCATION S loc_course_specific_declaration TRANSIT LOCATION S loc_course_specific_declaration SENSOR LOCATION S loc_course_specific_declaration SOURCE LOCATION S loc_course_specific_declaration SINK LOCATION S loc_co
111. Variablenwertes Spezifikator gt handelt Durch den Spezifikator lassen sich algebraische Gleichungen Ereignisse und Differentialglei chungen voneinander unterscheiden Der besseren Lesbarkeit halber mag es aber angebracht erscheinen Ereignisse und Differentialgleichungen d h die Zustands bergangsfunktionen durch Schl sselworte besonders hervorzuheben Beispiel DIFFERENTIAL EQUATIONS freier Fall x V Ve eure END EVENT Reflexion am Boden v k v WHEN x lt O AND v lt O END END Definitionsgleichung mit Fallunterscheidung Die Forderung nach Vollst ndigkeit und Widerspruchsfreiheit mu auch bei Fallunterschei dungen gew hrleistet sein Eine Fallunterscheidung hat bekanntlich folgendes Aussehen fi W falls WeB fo W falls W B y f W falls W B Paati falls we ue fr W sonst Die Fallunterscheidung ist semantisch nur dann korrekt wenn sich a die Mengen B Bo u s w nicht berschneiden d h wenn MOB KN Bae Nur dann ist die Eindeutigkeit gew hrleistet b die Mengen B B2 u s w den gesamten Zustandsraum abdecken d h wenn B UB U UB _1 SZ AKT Nur dann ist die Vollst ndigkeit gew hrleistet Ist die erste Bedingung verletzt ist in bestimmten Gebieten des Zustandsraums f r die Variable u mehr als ein Wert definiert Wenn die zweite Bedingung verletzt ist gibt es Gebiete des Zustandsraums in denen f r u gar kein Wert definiert ist 42 2 Sprachentwurf im Sin
112. Vorkehrungen zu treffen damit neue Elemente erzeugt und bestehende Ele mente vernichtet werden k nnen Bei der bestandsbezogenen Beschreibung die einen Trans port ohnehin in eine Operation zum Erzeugen und eine zum Vernichten zerlegt ist hierf r lediglich ein Zugang zu neuen Elementen zu schaffen NEW Job 1 5 Beispiel Erzeugen B_1 B_1 B_2 B_2 B_2 Job 1 Vernichten Bei Verwendung der transportbezogenen Beschreibung wird die Einf hrung von Quellen und Senken erforderlich Eine Quelle ist ein Bestand auf dem sich potentiell unendlich viele Elemente befinden Eine Komponente darf ihr beliebige Elemente entnehmen aber keine hinzuf gen Die Rechte eines Quellbestandes lauten daher L WK S WK B VK H WK Lesen und Schreiben ist gestattet Das Schreiben erm glicht eine von der Vorbesetzung abweichende Anfangsbelegung der mobilen Komponenten Auch als konstant vereinbarte Zustandsvariablen d rfen an dieser Stelle gesetzt werden Eine Senke ist ein Bestand dem in unbegrenzter Menge Elemente hinzugef gt aber nicht mehr entnommen werden d rfen Die Rechte einer Senke lauten daher L VK S VK B WK H VK Auch das Lesen und Schreiben ist untersagt Damit sind Elemente die auf eine Senke ge bracht wurden quasi nicht mehr existent Eine Quelle wird als SOURCE LOCATION eine Senke als SINK LOCATION deklariert Vorbesetzungen mit einer bestimmten Menge von mobilen Komponenten sind nicht m glich Weder
113. a nur eine Komponente selbst Ver nderungen an ihren Zustandsvaria blen und abh ngigen Variablen vornehmen kann Einfl sse von au en werden einer Kompo nente nur ber ihre Sensorvariablen mitgeteilt Ob und wie sie darauf reagiert ist Sache der Komponente keinesfalls aber ihrer Umgebung Dieses Prinzip war eines der Gr nde f r den Erfolg der Systemtheorie zur Beschreibung von Systemen der Nachrichten und Regelungstechnik In den Naturwissenschaften dagegen hat die Systemtheorie bislang kaum Fu fassen k nnen und wahrscheinlich ist daf r ebenfalls das starre Prinzip der Autonomie verantwortlich Daf r gibt es folgende Gr nde In der Technik aber auch in betriebswirtschaftlichen Organisationsformen ist man bestrebt Komponenten so auszulegen da sie in ihrem Verhalten von der Umwelt weitgehend un abh ngig sind Technische Komponenten sollen nur auf wenige durch Schnittstellenbeschrei bungen genau festgelegte Eingaben reagieren R ckwirkungen auf die Eing nge sollten nach M glichkeit vermieden werden Durch Komposition von Komponenten kann ein Ingenieur dann gr ere technische Systeme aufbauen Wegen der angestrebten R ckwirkungsfreiheit l t sich das Verhalten des Gesamtsystems sehr einfach aus dem Verhalten der einzelnen Bausteine ermitteln In den Naturwissenschaften hingegen findet man zun chst einmal gar keine Komponenten vor Erst der Forscher grenzt durch sein Bestreben nach Systematik Dinge gegeneinander ab Dies
114. ache l t weitgehende berpr fungen der Aussagen auf semantische Korrekt heit zu Auf diese Weise kann dem Anwender ein hohes Ma an Sicherheit gew hrleistet werden e Die Sprache erlaubt eine effiziente Umsetzung in eine prozedurale Sprache zur algo rithmischen Abarbeitung einer Modellbeschreibung e Die Sprache stellt ein einfaches Konzept f r eine hierarchische Modularisierung ei nes Modells zur Verf gung Dabei m ssen weder Einbu en bei der berpr fung der Modellsemantik noch bei der effizienten Bearbeitung hingenommen werden Die Mo dellstruktur l t sich sehr gut graphisch repr sentieren Der Sprachaufbau umfa t e Basiskomponenten zur Beschreibung der Modelldynamik und h here Komponenten zur Beschreibung der Modellstruktur e Basiskomponenten beinhalten einen Deklarationsteil zum Vereinbaren der Modellva riablen mit ihren Eigenschaften und einen Dynamikteil zum Definieren der Modell variablen Die Definition legt den Wert einer Variablen in Abh ngigkeit der anderen Modellvariablen zu jedem Zeitpunkt fest e H here Komponenten beinhalten die Deklaration der Subkomponenten Deklaration einer Schnittstelle mit Sensorvariablen und internen Variablen aus Subkomponenten Verbindungen zwischen Subkomponenten und die Initialisierung der Variablen aus Sub komponenten e Modellvariablen wurden unterschieden in Zustandsvariablen abh ngige Variablen und Sensorvariablen e F r die Zustands berf hrungsfunktion und
115. and l t sich vermeiden wenn man innerhalb eines FOREACH Konstrukts nur eine Definitionsgleichung pro Variable zul t Noch ein facher wird eine Pr fung auf semantische Korrektheit wenn als Index nur die gebundene Variable alleine auftreten darf In beiden F llen ist daher eine alternative Syntax zu verwenden Beispiel FOREACH i IN 1 10 LET IF MOD i 2 0 LET x i 1 Belegung bei geradem Index END ELSE LET x i 1 Belegung bei ungeradem Index END END Im zweiten Beispiel dehnt sich die Modellbeschreibung etwas in die L nge was aber keine Folge der getroffenen Einschr nkungen ist sondern sich daraus ergibt da die kleinsten und gr ten Indices gesondert ber cksichtigt werden m ssen 3 4 Einf hrung von Feldern 97 Beispiel IF X 1 gt X 2 LET x 1 X 2 MOS ae 8 END ELSIF X 2 gt X 3 LET x 2 X 3 END FOREACH i IN 3 N 1 LET IF XLi lt XLi 1 LET IF Xli 1 gt X i 2 LET X i X i 1 END END ELSIF X i gt X i 1 LET X i X i 1 END END IF X N 1 gt X N AND X N 1 gt X N 2 LET X N X N 1 END Das Vertauschen der Werte mit dem linken Nachbarn hat Vorrang wird aber nur durchgef hrt wenn nicht der linke Nachbarn m glicherweise selbst mit seinem linken Nachbarn tauscht Die nun gefundene Beschreibung zum Sortieren des Zustandsvektors X ist semantisch korrekt und bei genauerem Hinsehen stellt man fest da sie auch als Algorithm
116. ann ist eine Sensorvariable einzuf hren und auf n chst h herer Ebene eine Verbindung herzustellen Beispiel Gesamtmodell verteilt auf zwei Komponenten m i _ a p _ be X 7 7 bi 7 an AUX SENSOR EXIT ENTRY Wegen der vielen Verwandtschaften zu dem in dieser Arbeit diskutierten Sprachkonzept erweist sich System Dynamics daher als interessanter Ansatzpunkt um Zusammenh nge und Fl sse im Modell graphisch zu repr sentieren Um den Anspruch auf Vollst ndigkeit der Darstellung aufrecht erhalten zu k nnen wird es wohl noch erforderlich sein auch Zu standsvariable mit einzuarbeiten welche Eigenschaften repr sentieren Insbesondere ist diese Darstellungsart dazu geeignet Zusammenh nge im Modell sowohl f r Basiskomponenten als auch f r h here Komponenten und hierarchische Modelle durchg ngig zu repr sentieren 188 4 Transporte zwischen Best nden 4 9 Zusammenfassung Neben den bereits aus Kapitel 2 bekannten Eigenschaftsgr en wurden die Bestandsgr en als g nzlich neuer Variablentyp eingef hrt Best nde repr sentieren Mengen von Elementen Alle Best nde eines Modells sind disjunkt d h jedes Element ist eindeutig einem Bestand zugeordnet Transporte zwischen Best nden lassen sich bestandsbezogen oder transportbezogen beschrei ben Die verschiedenen Beschreibungsformen f r ko
117. ar Das DEVIDE Konstrukt impliziert eine Priorit tenregelung wie wir sie in hnlicher Form vom IF Konstrukt kennen Ein Element das in beiden Eigenschaftsmengen enthalten ist wird bevorzugt der ersten Transportmenge zugeschlagen Will man die Eindeutigkeit beim Transport herstellen ohne die Sprache um das DEVIDE Konstrukt zu erg nzen darf in Transportoperationen nur die Verwendung einzelner Elemente zugelassen sein d h eine Angabe ganzer Mengen darf nicht erm glicht werden 4 4 5 Elementweiser Transport F hrt man den Transport elementweise durch l t die Syntax ebenfalls keinen Eindeutigkeits Konflikt zu Ein IF THEN ELSE Konstrukt sorgt innerhalb des Allquantors f r die Eindeu tigkeit beim Verteilen der Elemente FOREACH TJob IN B_1 LET IF TJob IN T_12 LET TJob gt B_2 END ELSIF TJob IN T_23 LET TJob gt B_3 END END Die Mengen T2 und 733 entsprechen nun allerdings u U nicht mehr den tats chlichen Trans portmengen Deshalb kann es ratsam sein auf eine gesonderte Bestimmung der Transport mengen zu verzichten FOREACH TJob IN B_1 LET IF TJob IN Job IN B_1 condition_12 Job 1 n_12 LET TJob gt B_2 END ELSIF TJob IN 4 Job IN B_1 condition_13 Job 1 n_13 LET TJob gt B_3 END END 154 4 Transporte zwischen Best nden Setzt man anstelle der Transportoperation TJob gt B_i die beiden Aussagen CHANGE B_1 TJob CHANGE B_i TJob ein l t sich die Eindeutigkeit
118. auch f r die bestandsbezogene Beschreibung herstellen F r den h ufigen Fall da immer nur ein Element transportiert werden soll l t sich die Ver teilung aus einem Bestand wesentlich k rzer und ohne Bestimmung einer Eigenschaftsmenge durchf hren Beispiel FOREACH TJob IN B_1 Job 1 LET IF cond_12 LET TJob gt B_2 END ELSIF cond_13 LET TJob gt B_3 END END Die bisherigen Sprachkonstrukte reichen demnach durchaus aus um das Problem des ein deutigen Zugriffs bei Verteilung zu l sen 4 5 Modularisierung 155 4 5 Modularisierung Die hierarchische Modularisierbarkeit von Modellen wurde als eines der wichtigsten Ziele ganannt In diesem Abschnitt soll nun untersucht werden welche prinzipiellen M glichkeiten bestehen um Modelle bestandsbezogen oder transportbezogen zu zerlegen Auch bei modular zerlegten Modellen durch eine geschickte Sprachsyntax eine berpr fung der semantischen Korrektheit durch den Compiler erfolgen k nnen Zu den bisher genannten Anforderungen kommt nun noch die Autonomie einer Komponente die in einem eigenen Abschnitt diskutiert wird Anforderungen die im nicht zerlegten Modell verletzt werden lassen sich nat rlich im zerleg ten Modell erst recht nicht erf llen Hierzu z hlt insbesondere die Erhaltung der Elemente die von der bestandsbezogenen Beschreibung nicht sichergestellt werden kann Die Gew hrleistung der Eindeutigkeit wird auch weiterhin Ziel der Bem hungen sein
119. aus der Komponente d h in beiden Rich tungen durchgef hrt werden Durchgangsbest nde werden daher mit dem Zusatz TRANSIT versehen In Kurzschreibweise LSBH WA 170 4 Transporte zwischen Best nden Wenn ein Bestand in zwei oder mehreren Komponenten als Durchgangsbestand deklariert ist k nnen seine Elemente demnach von allen Komponenten gelesen geschrieben und entfernt werden und es k nnen Elemente hinzugef gt oder entfernt werden Komponente A Komponente B bringen holen holen bringen Beispiel Girokonto Es wird zus tzlich der Bestand S Schalter eingef hrt und als TRANSIT gekenn zeichnet Die Bank verwaltet das Girokonto ganz allein Nur auf einen ausdr cklichen Auszahlungswunsch gibt die Bank dem Kunden Geld von seinem Konto indem sie es auf den Schalter legt W nscht er mehr als auf dem Konto ist verweigert sie die Auszahlung TRANSPORT CONNECTION Kunde S lt gt Bank S Kunde Bank B s gt s8 G V SAW falls SAW lt G G gt S lt 0 sonst Lediglich der Bestand S ist ungesch tzt und evtl auch f r einen Dritten zug nglich Alle brigen Best nde sind nicht zug nglich Mit dem Gewinn an vollst ndiger Autonomie ber private Best nde ist auch verbunden da sich der eindeutige Zugriff auf die Elemente sicherstellen l t Dagegen l t sich ein eindeu tiger Zugriff beim Einsatz von Durchgangsbest nden selbstverst ndlich nich
120. beliebige Strategien f r die Selektion und die Entnahme mobiler Komponenten aus Warteschlangen anzugeben Bei der Wahl ob Locations mit einem Ordnungs oder einem Einordnungskriterium ausge stattet werden sollen entscheiden wir uns f r das leichter realisierbare Einordnungskriterium Zustandsvariablen verharren im Zustand der Ruhe wenn nicht ausdr ckliche Operationen eine Zustands nderung herbeif hren Das allgemeinere Ordnungskriterium w rde solche Zu stands berg nge implizieren Da weder mit der einen noch mit der anderen L sung alle Anforderungen erf llt werden k nnen mu die Sprache ohnehin mit weiteren Konstrukten ausgestattet werden Diese Anforderungen lassen sich entweder durch die Einf hrung geordneter Eigenschaftsmen gen Kapitel 3 5 oder durch Funktionen erf llen f r die Locations als Parameter zul ssig sind und die einen Index zur ckliefern Dieses Thema wird an sp terer Stelle Kapitel 6 nochmals kurz angeschnitten 3 7 Einf hrung von Mengenvariablen als Zustandsvariablen 123 3 7 2 Modellierung eines M D 1 Systems Das folgende Beispiel wiederum das M D 1 System zeigt da die Einf hrung des Trans portoperators daf r sorgt da der Operator NAME f r den Benutzer verborgen bleibt und sich eine besonders gut lesbare und kompakte Modellbeschreibung ergibt MOBILE COMPONENT Job DECLARATION STATE VARIABLE TEntry REAL 0 END OF Job BASIC COMPONENT MD1 DECLARATIONS CONSTANT TService REAL
121. bildet werden ordered_property_set identifier IN basis_set a condition E71 criteria_list basis_set index_range identifier Beispiel ARRAY 1 N Job J IN Job J Ort Q1 J TEntry Auch fiir Mengen aus Feldelementen lassen sich Mengenvariablen einfiihren Die Deklaration enthalt als Wertemenge den Namen des Feldes Beispiel DEPENDENT VARIABLE Queuei SET OF Job Queue2 SET OF Job Zuordnungen an diese Mengenvariablen erfolgen in gewohnter Weise Beispiel Queuel J IN Job J Ort Q1 INC J Laenge 114 3 Spracherweiterungen zur Formulierung von Warteschlangenmodellen Mengen aus Feldelementen k nnen beschnitten werden indem man einen Indexbereich in Verbindung mit dem Namen des Feldes angibt Diese Art der Teilmengenbildung kann so wohl auf geordnete Eigenschaftsmengen als auch auf geordnete Mengenvariablen angewendet werden cutted_set set identifier cardinal_set set u ordered_property_set indexed_identifier Beispiel J IN Job Job Ort Q1 INC Job TEntry Job 1 5 Die ersten f nf Elemente aus linksstehender Menge werden ausgegrenzt Beispiel Queue1 Job 1 5 Beschneiden einer Mengenvariablen Queue1 Job 1 Teilmenge aus einem einzelnen oder gar keinem Element Der Zugriff auf ein Attribut eines mobilen Elements erfolgt in hnlicher Weise Der Index des mobilen Elements steht jedoch in eckigen Klammern Damit wird vorausgesetzt
122. ch Ein schr nkung eines einzigen Indexbereichs gebildet werden Geschachtelte Konstruktionen bei denen eine Eigenschaftsmenge Teilmenge einer anderen Eigenschaftsmenge ist werden nicht erm glicht F r die Modellbildung erweist sich die vorgeschlagene Mengendefinition als aus reichend index_set cardinal_set property_set cardinal_set index_range constant_integer property_set identifier IN index_range condition condition expression Fiir die Bildung einer Eigenschaftsmenge wird ein Bezeichner fiir einen Index angegeben der implizit deklariert wird und nur innerhalb der Mengenklammern G ltigkeit besitzt Beispiele 10 20 cardinal_set 1 5 i IN 452303 property_set i IN 1 10 X i 0 i IN 1 N Job bi Ore 7017 Wir wollen auch einige einstellige Operatoren einfiihren die eine Indexmenge als Argument besitzen CARD index_set liefert als ganze Zahl die Kardinalit t also die Anzahl der Mengenelemente EMPTY index_set liefert einen logischen Wert TRUE wenn die Menge leer ist FALSE sonst 3 5 Einf hrung von Indexmengen 101 ALL index_set liefert f r Eigenschaftsmengen einen logischen Wert TRUE wenn die Menge die gesamte Grundmenge umfa t FALSE sonst ANY index_set liefert f r Eigenschaftsmengen einen logischen Wert TRUE wenn die Menge wenigstens ein Element enth lt FALSE sonst Beispiel CARD i IN 1 N Jobli Ort
123. ch mit gew hnlichen Differen tialgleichungen beschreiben lassen ist sie als universell anzusehen Modelle k nnen einen beliebigen Detaillierungsgrad erreichen F r die allermeisten Anwendungen kann sie daher tats chlich alternativ zu einer h heren Programmiersprache eingesetzt werden Auch wenn spezialisierte Werkzeuge leichter zu erlernen und zu handhaben sind bietet sie gegen ber diesen den entscheidenden Vorteil da nicht f r jede Anwendung ein anderes Werkzeug verwendet werden mu und da Modelle verschiedener Anwendungsbereiche mit einander verkn pft werden k nnen 292 8 Zusammenfassung Abgesehen vom IF und WHEN Konstrukt ist die Sprache nicht redundant d h sie besitzt keine berz hligen Konstruktionen Die Semantik der Sprache ist mit der zustandsorientierten Betrachtungsweise an ein verh lt nism ig einfaches Paradigma gebunden das in den Ingenieurwissenschaften ohnehin weite Verbreitung genie t und daher den meisten Anwendern bereits vertraut ist Die Korrektheit einer Modellbeschreibung l t sich weitestgehend bereits vom Compiler pr fen so da zur Laufzeit nur noch sehr wenige Fehlerm glichkeiten bestehen Durch die berpr fung auf Eindeutigkeit und Vollst ndigkeit und damit auch auf Widerspruchsfrei heit wird dem Anwender der deklarative Sprachcharakter sehr gut vor Augen gef hrt Das ist vor allem deshalb erforderlich weil sich die Notation nicht besonders von der prozeduraler Sprachen wie PAS
124. chen Fachgebieten einzusetzen Simulationstechniker k nnten in Ingenieurb ros Unternehmensberatungen oder in Planungsabteilungen gr erer Firmen zu finden sein Da der Anwender die Modellbeschreibung zumindest lesen kann ist er auch in der Lage die Arbeit des Simulationstechnikers nachzuvollziehen und zu berpr fen An dieser erforderlichen Zusatzqualifikation leidet bislang die Akzeptanz der Sprache Da der Anwender meint zum Erlernen der Sprache keine Zeit zu haben und ein Simulations techniker nicht so leicht zu finden ist wie ein PASCAL Programmierer bleibt er zun chst einmal bei den Werkzeugen die er kennt und bereits im Einsatz hat Dabei sind die Vorteile gegen ber herk mmlichen Werkzeugen hnlich wie der bergang von einer Assemblersprache zu einer h heren Programmiersprache Vergleicht man SIMPLFX MDL mit dem ebenfalls universell einsetzbaren Simulationspaket GPSS FORTRAN einer FORTRAN Implementation der Simulationssprache GPSS dann l t sich feststellen da man zur Beschreibung eines kleinen Modells 10 Zustands berg nge etwa ein F nftel der Zeit und zum Test des Modells etwa ein Zehntel der Zeit ben tigt Mit wachsender Modell gr e nimmt der Unterschied rapide zu Diese Fakten allein sind f r den Anwender jedoch nicht berzeugend und deshalb gilt es genauer zu untersuchen was zu tun ist um die Akzeptanz zu verbessern Vorschl ge hierzu gibt es gen gend F r jedes Anwendungsgebiet wird ein realistisch
125. chnen Falls Ebene m lt NE Fuer alle i aus 1 NY_j y i j g G j 08 5 75 27 t 2 7 Algorithmus f r die Simulation einer modularen Modellbeschreibung 69 4 Alle neuen Zustandsvariablen z_i berechnen Falls Ebene m NE Fuer alle i aus 1 NZ_j z_ i j f_ i j X_j Y_j Z_j Ende Schleife ueber alle Komponenten 5 Variablen des aktuellen Zustands aufzeichnen Monitor 6a Neuen Zeitpunkt t bestimmen und Zeit fortschalten ware en t amp tt 6b Alle Zustandsvariablen umspeichern Fuer alle i aus 1 NZ z_i Z i Ende Schleife ueber alle Zeitpunkte Es werden nur die Werte solcher Sensorvariablen berechnet die nicht mit internen Variablen anderer Komponenten verbunden sind Da die nicht angeschlossenen Sensorvariablen nur von der Zeit abh ngig sind ist ihre Berechnung nur in der ersten Ebene erforderlich Die abh ngigen Variablen werden NE 1 mal immer wieder aufs neue bestimmt Das Sortieren der Gleichungen ist bei dieser Vorgehensweise daher nicht erforderlich Die Zustandsvariablen f r den Folgezeitpunkt werden abschlie end berechnet wenn die Wer te der brigen Variablen mit Sicherheit schon bestimmt sind Der gezeigte Algorithmus gliedert sich in gleichbleibende Abschnitte und einen Abschnitt der f r einzelne Komponenten steht Die gleichbleibenden Abschnitte Ablaufsteuerung sind im Laufzeitsystem untergebracht die komponentenspezifischen Abschnitte werden vom Com piler aus
126. crit est completement expliqu e Les explications th oriques deviennent plus claires aux lecteurs et les exemples peuvent tre totalement compris Il devient apparent qu une syntaxe propre peut supporter certaines des exigences du langage Les tudes th oriques ont tendance a admettre des formulations g n ralement imaginables En d pit du fait que les formules complexes sont peu utilis es l impl mentation devient volumineuse et l efficacite diminue pendant l execution Pour cette raison des limitations utiles sont discut es qui ne diminuent pas les applications mais qui conduisent a plus de simplicit et d fficacit Jusqu a present dans la simulation il ny a que peu de consid rations propos des sp cifications des modeles qui peuvent tre approuv es Afin de mieux suivre le cours des id es on a donn des explications sur le materiel d une maniere inductive et non d ductive ce qui n est pas toujours commun dans des th ses scientifiques Pour une meilleure com pr hension et comme base pour des tudes plus avanc es a propos de ce projet ce livre me semble plus opportun Je crois que les consid rations present es dans ce livre seront int ressantes au dela des aspects classiques des problemes de simulation Dans beaucoup de cas elles traitent des problemes qui se manifestent d une maniere identique quand d autres aspects de la r alit doivent tre d crits Le concept d un langage m me pourra
127. da individuelle Steuerungsstrategien wenn berhaupt nur mit genauen Kenntnissen des Systems realisierbar sind F r auftrags orientierte z B flexible Fertigungsanlagen ist dieser Punkt jedoch entscheidend Wie im Abschnitt 1 5 1 dargelegt wurde erh lt man die interessierenden Leistungsgr en aus der Verfolgung der Auftr ge d h aus der Kommunikation der Leit und Steuerrechner und nicht aus dem Layout des Maschinenparks F r diese Betrachtungsweise sind die g ngigen Baustein Simulatoren nicht ausgelegt da sie vor allem Maschinen Transporteinrichtungen und L ger als Bausteine zur Verf gung stellen SIMPRO ist ein datengesteuerter Simulator der auf der Darstellung von Petri Netzen be ruht die zu diesem Zweck um neue Elemente erg nzt wurden Um Steueralgorithmen nicht durch ein unanschauliches Programm beschreiben zu m ssen w hlte man Petri Netze als Beschreibungsmittel Petri Netze haben zudem den Vorteil da sie hierarchisch in Kompo nenten zerlegbar sind Eine Anlage kann demnach Zug um Zug am Bildschirm zusammen gestellt werden Der Ablauf in Petri Netzen ist auch animierbar so da sowohl der Flu der bewegten Teile als auch Zustands berg nge in der Steuerung am Bildschirm beobachtet wer den k nnen Auch hier kann das Layout der Modellerstellung unmittelbar f r die Animation herangezogen werden Diesen unzweifelhaften Vorteilen stehen leider auch betr chtliche Nachteile gegen ber Das gesamte Modell ist in
128. declaration DEPENDENT VARIABLE S var_course_specific_declaration SENSOR VARIABLE S var_course_specific_declaration RANDOM VARIABLE S var_course_specific_declaration var_course_specific_declaration CONSTANT variable_declaration_list DISCRETE variable_declaration_list CONTINUOUS variable_declaration_list Die weitere Syntax ist f r Attribute und Best nde identisch und findet sich auf der bern chsten Seite Eine Basiskomponente besitzt die volle Autonomie ber ihre Eigenschaftsvariablen d h sie allein besitzt das Recht Ver nderungen an den internen Variablen Zustandsvariablen und abh ngige Variablen vorzunehmen Andere Komponenten d rfen lediglich lesend auf die internen Variablen zugreifen Dies ist durch eine entsprechende Vergabe des Lese und Schreibrechts f r jeden Variablentyp geregelt STATE L WA S WK DEPENDENT L WA S WK SENSOR L WA S VA RANDOM L WK S VK Best nde gelten ebenfalls als Zustandsvariable Weil sie sich jedoch in ihrem Wesen so sehr von den Attributen unterscheiden erhalten sie einen eigenen Platz im Deklarationsteil ein ger umt Best nde unterscheiden sich von den Attributen dadurch da ihr dynamisches Verhalten durch eine Transportanweisung und nicht durch eine Wertzuweisung beschrieben wird Sie repr sentieren Mengen anstelle von Eigenschaften Mehrere Komponenten k nnen sich einen Bestand teilen w hrend ein Attribut stets genau einer Komponente zugeordnet ist
129. delle der Warteschlangentheorie untersuchen Das folgende Beispiel zeigt eine stark vereinfachte Rechenanlage als offenes Warteschlangenmodell Distrib Processor Facility Source R Exit 1 d Sink oh gt D Exit 2d gt D Exit 3C Disk Facility D C 7 4 Die Modellbank QueueNet 241 HIGH LEVEL COMPONENT Computer SUBCOMPONENTS Source Processor OF CLASS Facility Disk OF CLASS Facility Distrib Sink STRUCTURE TRANSPORT CONNECTIONS Source Exit Disk Exit Distrib Exit1 gt Processor Entrance Processor Exit gt Distrib Entrance Distrib Exit2 gt Disk Entrance Distrib Exit3 gt Sink Entrance END OF Computer Will man die Quelle und Senke nach au en verlagern und die h here Komponente mit ent sprechenden Schnittstellen ausstatten erh lt man folgende Modellkomponente HIGH LEVEL COMPONENT Computer SUBCOMPONENTS Processor OF CLASS Facility Disk OF CLASS Facility Distrib DECLARATIONS TRANSIT VARIABLE Entrance lt gt Disk Exit Distrib Exiti gt Processor Entrance EXIT VARIABLE Exit lt Distrib Exit3 STRUCTURE TRANSPORT CONNECTIONS Processor Exit gt Distrib Entrance Distrib Exit2 gt Disk Entrance END OF Computer Da auf die Eingangsbestand des Prozessors auch mobile Elemente gebracht werden darf die Location Entrance der h heren Komponente le
130. dem Beschneiden eines Bestandes Auch die Angabe einer gebundenen Variablen ist m glich welche alle Werte des angegebenen Indexbereichs annimmt Diese Variable besitzt ihre G ltigkeit nur innerhalb dieser einen Anweisung Fehlt die Angabe des Indexbereiches dann nimmt die gebundene Variable alle m glichen Werte an F r Elemente von Best nden bedeutet das da die gebundene Variable die Indices aller Elemente annimmt die sich zur Zeit auf diesem Bestand befinden Die Indexmenge kann durch eine Bedingung welche die gebundene Variable zu enthalten hat eingeschr nkt werden 5 3 8 Beschneiden von geordneten Mengen Das FOREACH Konstrukt erlaubt es bestimmte Operationen mit ausgew hlten Mengen elemente durchzuf hren Es ist m glich mit einer gesamten Menge zu operieren oder Men genelemente aus einer geordneten Menge durch Beschneiden auszugrenzen Durch das Beschneiden wird eine geordnete Menge auf die Elemente mit denjenigen Positio nen reduziert die mit dem Indexbereich bzw dem Index angegebenen sind cutted_set set identifier cardinal_set set selected_location ordered_property_set constant_integer constant_integer constant_integer cardinal_set 204 5 Systematische Darstellung der Modellbeschreibungssprache Es k nnen sowohl Indexmengen wie auch Mengen von mobilen Elementen beschnitten wer den Im letzterem Fall ist der Klassenname der mobilen Komponenten anzu
131. den Subkomponenten sind ber gemeinsame Best nde m glich die durch Transportverbindungen hergestellt werden Zur Einbettung in eine andere h here Komponente kann eine Schnittstelle geschaffen werden Variablen der Subkomponen ten werden zu diesem Zweck zu eigenen Variablen gemacht Auf diese Weise l t sich eine hierarchische Modellstruktur beschreiben Auf der untersten Ebene dieser Hierarchie stehen diejenigen Komponenten die selbst keine weiteren Kompo nenten enthalten Das k nnen Basiskomponenten oder mobile Komponenten sein Keine Komponente darf in sich selbst oder in einer ihrer Subkomponenten enthalten sein Die Hierarchie mu zyklenfrei sein Ein vollst ndiges Modell mu mindestens eine Basiskom ponente enthalten Auf den Ebenen der h heren Komponenten und der Basiskomponenten ist die Modellstruktur statisch auf den Ebenen der mobilen Komponenten ist sie dynamisch Aus der Sicht der 192 5 Systematische Darstellung der Modellbeschreibungssprache Informatik bieten mobile Komponenten die gleichen M glichkeiten wie mehrfach verkettete Listen Sie stellen daher einen relativ m chtigen und flexiblen Datentyp dar 5 2 Deklaration in Basiskomponenten und mobilen Kom ponenten Basiskomponenten und mobile Komponenten besitzen den gleichen Aufbau mit dem Unter schied da mobile Komponenten keine Beschreibung der Modelldynamik beinhalten basic_component BASIC COMPONENT identifier mobile_subclass_declaration de
132. der beiden Komponenten mu zweimal betreten werden um 2 aus z bestimmen zu k nnen Die einfachste Art diesem Problem zu begegnen ist die Gleichungen in allen Komponenten sooft auszuwerten wie der Abh ngigkeitsgraph Ebenen besitzt Am Ende des ersten Durch laufs sind mit Sicherheit die Variablen der Ebene 1 korrekt berechnet am Ende des zweiten Durchlaufs die der Ebene 2 u s w Wir modifizieren daher unseren Grundalgorithmus dahingehend 68 2 Sprachentwurf im Sinne der klassischen Systemtheorie Daten t aktueller Zeitpunkt t i n chster Zeitpunkt t 1 NK Anzahl der Komponenten NZ NK Anzahl der Zustandsvariablen pro Komponente NY NK Anzahl der abhangigen Variablen pro Komponente NX NK Anzahl der Eingangsvariablen pro Komponente NE Anzahl der Ebenen des Abh ngigkeitsgraphen Fuer jede Komponente 7 Z NZ NZ_j Zustandsvariablen Wert zum Zeitpunkt tx z NZ j NZ_j Zustandsvariablen Wert zum Zeitpunkt tk 1 Y NX_j NX_j Ausgangsvariablen Wert zum Zeitpunkt t X NX_j NX_j Eingangsvariablen Wert zum Zeitpunkt t Algorithmus 1 Anfangszeit und Anfangszustand setzen Schleife ueber alle Ebenen Fuer alle m von 1 NE Schleife ueber alle Komponenten Fuer alle j aus 1 NK Aufruf der Komponente j 2 Alle nicht verbundenen Sensorvariablen x_i berechnen Falls Ebene m 1 Fuer alle nicht verbundenen x_ i j mit i aus 1 NX_j x_ i j e_ i j t 3 Alle abhaengigen Variablen y_i bere
133. der Modellbeschreibung Spezifikation erzeugt F r Komponenten der gleichen Klasse liegt nur eine Codierung vor Abbildung 2 7 1 zeigt die Struktur eines in Komponen ten zerlegten Simulationsprogramms Der Aufwand zur Berechnung der abh ngigen Variablen ist jedoch betr chtlich Insgesamt werden hierzu pro Zeitpunkt NE 1 NY statische Beziehungen berechnet und NE 1 NK Unterprogrammaufrufe ausgef hrt Dieser hohe Mehraufwand gegen ber der Bearbeitung in einem einzigen Programmst ck ist nat rlich nicht mehr akzeptabel Wir wollen daher verschiedene M glichkeiten ausloten hier Verbesserungen herbeizuf hren 70 2 Sprachentwurf im Sinne der klassischen Systemtheorie Gesamtmodell in Modellbeschreibungssprache SPEZIFIKATION Ubersetzung Modellkomponenten in der Basissprache IMPLEMENTATION Ablaufsteuerung Laufzeitsystem Too n Simulationsprogramm in Basissprache Abb 2 7 1 Erzeugung eines modularen Simulationsprogramms Die einfachste L sung beruht auf einem vorzeitigen Abbruch der Iteration ber alle Ebenen In der Regel kann man davon ausgehen da die statischen Beziehungen teilweise bereits sortiert sind und sich daher die korrekten Werte der abh ngigen Variablen bereits bei we niger Durchl ufen einstellen Sobald man feststellt da ein Durchlauf keine nderungen von abh ngigen Variablen mehr bewirkt hat kann man die It
134. der Zielkomponente K1 K2 Queue TQS Server nd E gt E Queue Queue Queue SenTQS Server Server TQS Bestimmung der Transportmenge in K2 IF EMPTY Server LET TQS ELSE LET TQS SenQueue Job 1 END ik END 160 4 Transporte zwischen Best nden 3 Bestimmung der Transportmenge in beiden Komponenten Ki K2 Queue Queue Server Seas Se Je Server Queue Queue TQS Server Server TQS Bestimmung der Transportmenge in K4 IF EMPTY SenServer LET TQS ELSE LET TQS Queue Job 1 END 135 END Bestimmung der Transportmenge in K2 IF EMPTY Server LET TQS ELSE LET TQS SenQueue Job 1 END ur END Das Beispiel macht aber auch deutlich da die in den allgemeinen berlegungen genannten Vor und Nachteile gar nicht so gravierend ins Gewicht fallen m ssen Eine Einschr nkung des Anwenders auf die erste Variante erscheint daher nicht geboten und w re ohnedies nur schwer realisierbar F r bestimmte Anwendungsf lle insbesondere beim nicht individuellen Transport gestatten gerade die Varianten 3 und 4 wegen ihrer Symmetrie durchaus eine vorteilhafte Modellzerle gung Da das Klassenkonzept eingesetzt werden kann werden die anderen Nachteile wieder wettgemacht Beispiel Diffusion durch eine Membran Jede Komponente repr sentiert ein Beh ltnis Dazwischen liegt eine teildurchl ssi ge Membran der Fl che A Die Diffusions
135. dere Komponenten weitergegeben werden k nnen wurde ein Teil dieser Probleme berwunden Unbefriedigend war aber nach wie vor die Initialisierung des Aufenthaltsortes von mobilen Elementen sowie der ungeregelte Zugang zu mobilen Komponenten die gar nicht in der be trachteten Modellkomponente enthalten sind Diesen Problemen begegneten wir durch die Einf hrung von Locations d h Mengen von mobilen Komponenten die als Zustandsvaria blen zu verstehen sind Hierdurch wurden auch die letzten Schwierigkeiten beseitigt Ganz bewu t wurden die Erweiterungen der Sprache Zug um Zug durchgef hrt damit der Leser die L sungsvorschl ge gegeneinander abw gen kann Am Ende des letzten Abschnitts zeigte sich da die Einf hrung von Locations einen gro en Teil von bereits eingef hrten Sprachkonstrukten wieder berfl ssig macht So erweist sich die Vereinbarung von abh ngi gen Mengenvariablen als berfl ssig und auch die Bildung von Eigenschaftsmengen wird kaum noch ben tigt Lediglich die Ausgrenzung von Teilmengen ist f r die Modellbildung unbedingt erforderlich Diese Beschr nkungen erm glichen auch eine effiziente Simulation von Warteschlangenmodellen Als unbefriedigend wird allerdings empfunden da dieses Konzept zun chst nur auf die Bed rfnisse der Modellierung von Warteschlangen und Transportmodellen zugeschnitten ist Die quivalenz zwischen der Transportoperation und den beiden Teiloperationen Hinzuf gen und Wegnehmen liefert
136. des Rechners zuriickgreifen miissen als Systemprogramme bereits zur Verfiigung stehen Bei einer Spezifikationssprache wie der diskutierten Modellbeschreibungssprache mu man sich nun berlegen in welcher Form man die gew nschten Erweiterungen zur Verf gung stellt W nsche nach einer erweiterten Funktionalit t lassen sich in drei Kategorien unterscheiden 1 Erweiterungen die in den Compiler eingehen m ssen Aufz hlungsmengen physikalische Ma einheiten Funktions und Prozeduraufrufe zur Beschreibung komplexerer Zusammenh nge zwischen Modellvariablen z B Formulieren von Strategien 2 Erweiterungen die sich durch Unterprogramme abdecken lassen aber sehr h ufig ge nutzt werden und Teil der Modellbeschreibung sind Zufallsvariablen Tabellenfunktionen 3 Erweiterungen die nicht Teil der Modellbeschreibung sind und sich durch Unterpro gramme abdecken lassen Laufende Ein Ausgabe von Daten w hrend eines Simulationslaufs von auf Datei Datenbank oder Bildschirm Kommunikation mit anderen Prozessen w hrend des Simulationslaufs Synchronisation mit der Systemuhr Echtzeit bzw zeitproportionaler Betrieb Die W nsche aus der ersten Gruppe m ssen selbstverst ndlich in die Sprache eingehen da sie vom Compiler zu ber cksichtigen sind Bei W nschen aus der zweiten Gruppe kann indi viduell abgewogen werden ob und in welcher Weise sie Eingang in die Sprache finden sollen Bei den W nsc
137. deutigkeit sichergestellt und kein Zugriffskonflikt m glich Das beinhaltet jedoch nicht da die Komponente K3 vollst ndige Autonomie ber den Be stand B besitzt Die Komponente K3 kann schlie lich nicht bestimmen welche Elemente dem Bestand B zugef hrt werden Beispiel Ein Ausgangsbestand ist mit zwei Eingangsbest nden verbunden TRANSPORT CONNECTION K1 B gt K2 B K3 B K2 KI ENTRY B EXIT B K3 ENTRY B Damit die beiden Komnponenten K2 und K3 nicht gelegentlich zur selben Zeit schreibend oder holend auf dasselbe Element des Bestandes B zugreifen ist eine Absprache zwischen den beiden Komponenten erforderlich die ber eine zus tzliche Kommunikation erfolgen mu 176 4 Transporte zwischen Best nden Beispiel Je zwei EXIT TRANSIT und DENTRY Best nde sind miteinander verbunden TRANSPORT CONNECTION K1 B K2 B gt K3 B lt gt K4 B gt K5 B K6 B K1 K3 K5 EXIT B TRANSIT B DENTRY B A AO K2 K4 K6 7 7 EXIT B TRANSIT B D DENTRY B Innerhalb der Komponente in der ein Bestand mit den genannten Attributen deklariert wird sind die folgenden Operationen zul ssig Antransport Abtransport Attribute setzen Attribute lesen PRIVATE X X X X EXIT X X ENTRY X X X DENTRY X X X TRANSIT X X X X Die Erfahrung zeigt da die zuletzt vorgenommene Unterscheidung in die
138. die Zeitmenge wurden verschiedene M glich keiten aufgezeigt Wir werden hier stets die reellen Zahlen als Modellzeit heranziehen Auf die Besonderheiten bei der Implementierung die sogenannte Implementierungszeit wurde hingewiesen Im folgenden wird die Sprache weiter ausgebaut um auch Warteschlangen und Transport modelle beschreiben zu k nnen Dabei wird versucht die genannten Vorteile dieser Sprache zu erhalten 82 83 Kapitel 3 Spracherweiterungen zur Formulierung von Warteschlangenmodellen In diesem Kapitel wird er rtert wie Warteschlangenmodelle zustandsorientiert beschrieben werden k nnen Hierzu ist der bisherige Ansatz um eine ganze Reihe sprachlicher Mittel zu erweitern Dabei wird zun chst von naheliegenden Erg nzungen ausgegangen wie sie das erste einf hrende Beispiel zeigt Diese Spracherweiterungen werden diskutiert und es wird versucht deren Probleme durch weitere Erg nzungen des Sprachkonzepts zu berwinden Auf diese Weise ergibt sich nach und nach ein betr chtlicher Sprachumfang Gl cklicherweise wird schlie lich eine L sung gefunden die einen gro en Teil der bereits eingef hrten Sprachkonstrukte wieder berfl ssig macht Dieser Umweg wird bewu t beschritten weil die gefundene L sung nicht auf der Hand liegt und das systemtheoretische Konzept um neue Inhalte erweitert Dies wird besser verst nd lich wenn der Bezug zum urspr nglichen Konzept hergestellt wird Durch die allm hliche Erwe
139. diesem Verfahren braucht man den Abh ngigkeitsgraph nicht durch entsprechende Da tenbereiche zu repr sentieren F r jede Variable wird lediglich durch Setzen der Marke Flag vermerkt ob sie ver ndert wurde Anhand dieser Flags wird gepr ft ob eine Komponente zu durchlaufen ist bzw ob eine Bestimmungsgleichung auszuwerten ist Eine Komponente wird nur durchlaufen wenn sich interne Variablen oder Sensorvariablen der Komponente ver ndert haben die auf Variablen der aktuellen Gruppe Einflu nehmen Eine Bestimmungsgleichung in einer Komponente wird nur dann ausgef hrt wenn sie der aktuell auszuf hrenden Gruppe angeh rt und Variablen von denen diese Gleichung abh ngt ihren Wert ver ndert haben Die Pr fung ob eine Komponente zu durchlaufen ist ist sehr aufwendig 2 7 Algorithmus fiir die Simulation einer modularen Modellbeschreibung 79 Beispiel K1 211 u a 0 5 Ne 2 K2 212 rz 32 0 1 2232 Die Komponente K2 ist zu durchlaufen wenn die Gruppennummer gleich 1 ist und sich 212 oder 295 ver ndert hat die Gruppennummer gleich 2 ist und sich y 2 oder 212 ver ndert hat Dieselben Abfragen die innerhalb der Komponente n tig sind werden vor dem Betreten der Komponente nochmals erforderlich Daraus ist ersichtlich da es mit diesem Verfahren nicht m glich ist auf effiziente Art und Weise das Durchlaufen einer Komponente zu unterbinden Kombinie
140. dung mit einer Transport verbindung deklariert werden Da die TRANSIT Location nach au en hin sowohl ein Bringerecht wie ein Holerecht gew hrt mu sie innerhalb der h heren Komponente mit Best nden verbunden sein die ebenfalls diese Rechte gew hren A eZ Ds DENTRY XH B TRANSIT LOCATION D XH lt gt A X gt B X gt C X X TRANSIT C D X EXIT Die Notation zerlegt sich in zwei Teile Der rechte geklammerte Teil zeigt eine Transport verbindung d h Verbindungen wie sie auch ohne die eingef hrte TRANSIT LOCATION bestehen w rden Der linke Teil stellt die Verbindung zur neuen Location her 4 7 Quellen und Senken Wir hatten bisher nur geschlossene Modelle betrachtet d h Modelle die eine bestimmte Anzahl von Elementen in einem geschlossenen Kreislauf enthielten Sieht man im Modell ein Reservoir f r eben nicht ben tigte Elemente vor und dimensioniert es gen gend gro kann man auf das Erzeugen und Vernichten von Elementen verzichten 4 7 Quellen und Senken 181 Die Einf hrung eines Reservoirs mutet in manchen F llen jedoch k nstlich an wenn das Reservoir im modellierten System keine Entsprechung besitzt Vor allem in einem modular aufgebauten Modell m ten u U ber mehrere Komponenten hinweg R cktransporte durch gef hrt werden Auch sollten mobile Elemente wieder ihre Vorbesetzung erhalten wenn sie dem Reservoir entnommen werden Es sind daher
141. dungen ist das vorgestellte Schema in drei Punkten etwas zu ein schr nkend 1 Ausgangsvariablen d rfen weder zur Berechnung des neuen Zustands noch zur Bestim mung weiterer Ausgangsvariablen herangezogen werden 2 Zusammengesetzte Modelle lassen sich nur durch die Verbindung von Ausgangsvaria blen mit Eingangsvariablen erzeugen Die Werte von Zustandsvariablen k nnen nur ber eine zus tzliche Ausgangsvariable als Zwischengr e nach au en gegeben werden 3 Um die Eingangsvariablen zu belegen ist stets ein weiteres System erforderlich Ein Sy stem das Eingangsvariablen besitzt kann nicht einmal zu Testzwecken f r sich alleine betrieben werden Die Tatsache da Ausgangsvariablen weder in der Zustands berf hrungsfunktion noch in der Ausgabefunktion verwendet werden d rfen stellt zwar aus mathematischer Sicht keine Einschr nkung dar weil f r eine Ausgangsgr e jederzeit ihre Definitionsgleichung eingesetzt werden kann aus praktischer Sicht ist diese Einschr nkung jedoch erheblich Beispiel Die Gleichungen z tk 1 Y t yo yilt 2 443 Yo t z y13 Ys tk Y Yo m ten lauten z tk41 Yr t Yo yi t 2 443 yltk 2 2 2 3 ete z x 3 z 2z x 3 Die Ausgabefunktionen k nnen sehr komplex werden und wiederholen dabei Terme die f r andere Ausgangsvariablen bereits berechnet wurden 2 1 Systemtheoretische Modellbeschreibung 33 Im folgenden arbeiten wir nur noch mit der modifi
142. dungsgebiet immer wieder ben tigt werden Beim R ckgriff auf solche Modellbanken ist die Modellerstellung ebenso einfach wie bei den datengesteuerten Baustein Simulatoren Beschr nkt man sich auf eine spezielle Modellbank ist es kein Problem eine komforta ble graphische Bedienoberfl che hierzu anzubieten Will man hingegen dem Benutzer die M glichkeit geben selbst neue Modellkomponenten in die Bank aufzunehmen und ein gra phisches Symbol hierf r zu erzeugen steht man vor einer weit schwierigeren Aufgabe Die Behandlung dieser Thematik ist Gegenstand gegenw rtiger Forschung Die Erfahrungen mit der Realisierung Das vorgestellte Sprachkonzept wurde in geringf gig anderer Form mit der Modellbeschrei bungssprache SIMPLEX MDL Esch 91 realisiert Diese Sprache ist Bestandteil des Simula tionssystems SIMPLEX I Lang 89 Esch 90 Dorn 91 das seit 1989 institutsintern und seit 1991 auch bei externen Anwendern im Einsatz ist Dadurch liegen bereits viele Erfahrungen im Umgang mit der Sprache vor 253 Beim Einsatz in Hauptseminaren hat sich gezeigt da Studenten der Informatik ohne wei teres Vorwissen in der Lage sind innerhalb von ein bis zwei Wochen gr ere Modelle 10 Seiten Code in SIMPLEX MDL zu formulieren Es zeigte sich allerdings auch da der Anwender erst lernen mu die neue Sprache effizient zu nutzen Hier sind vor allem zwei Punkte zu nennen 1 Der Anwender mu lernen ein gegebenes System z B einen Aufzug
143. e Komponenten sind nun keineswegs autonom Wenn ein Schl ger auf einen Ball trifft ndert er seine Geschwindigkeit Der Ball kann sich nicht dagegen wehren Die Natur fragt nicht ob f r diesen Einflu von au en eine Schnittstelle vorgesehen war In dem einen Fall handelt es sich also um vom Menschen zu seinem eigenen Nutzen ge schaffene Systeme die er frei gestalten kann und durch Prinzipien der Modularisierung und Hierarchisierung versucht berschaubar und verst ndlich zu halten Im anderen Fall handelt es sich um Systeme die der Mensch vorfindet und zu verstehen und zu erkl ren versucht Auf ihre Wirkungsweise hat der Mensch keinen Einflu Diese berlegungen veranlassen uns der Autonomie eine besondere Beachtung zu schenken um die Modellbeschreibungssprache sowohl f r den technischen wie f r den naturwissen schaftlichen Einsatz attraktiv zu halten 4 6 Transportbezogene Modularisierung mit Teilautonomie 169 4 6 1 Typisierung der Best nde nach Zugriffsrechten Die Zugriffsrechte auf einen Bestand entscheiden dartiber inwieweit eine Komponente auto nom ber einen Bestand verf gen kann F r Best nde haben wir 4 verschiedene Zugriffsrechte zu unterscheiden Leserecht L Recht die Information auf einem Bestand zu lesen Schreibrecht S Recht die Attribute auf einem Bestand zu ver ndern Bringerecht B Recht Elemente einem Bestand zuzuf hren Holerecht H Recht Elemente von einem Bestand entfernen Die
144. e Place 4 State gt Transition 3 Place 5 State gt Transition 4 Transition 3 Output 1 gt Place Transition 4 Output 1 gt Place INITIAL CONDITIONS Place 2 State 1 Place 4 State 1 Transition 1 NI 2 Transition 2 NO 2 END OF System Input 1 Input 2 3 State Input 1 4 State 5 State Input 1 Input 1 1 State 2 State 7 Anwendungen 7 2 Das F nf Philosophen Problem 229 7 2 Das F nf Philosophen Problem Als Standardbeispiel zur Demonstration von Verklemmungen hat sich das f nf Philosphen Problem bew hrt Es wird angenommen da dieses Problem dem Leser bekannt ist Die Gabeln sind dabei Elemente deren Anzahl stets konstant bleibt Eine Gabel kann sich auf dem Tisch in der linken Hand des rechts sitzenden Philosphen oder in rechten Hand des links sitzenden Philosphen befinden Dieses Modell macht folgendes deutlich Der Platz auf dem Tisch an dem sich die Gabel befindet ist als TRANSIT LOCATION zu deklarieren da die Gabel sowohl von diesem Platz weggenommen als auch hingebracht wird Da auch jeder Philosoph die Gabeln in beiden Richtungen bewegt greift auch er ber eine TRANSIT LOCATION zu Den Platz an dem eine Gabel liegt teilen sich somit drei Komponenten Alle drei verf gen ber die gleichen Rechte auf die Gabeln zuzugreifen Aus der erforderlichen Deklaration wird dem Anwender bewu t da es f r die
145. e oder gar widerspr chliche Syntax entsteht das generierte Simulationsprogramm nicht ineffizient wird Bei der Festlegung des Sprachumfangs waren folgende berlegungen ma gebend Kern jeder Modellbeschreibung sind Definitionsgleichungen und Transportanweisungen Sowohl Definitionsgleichungen wie auch Transportanweisungen bei denen es nur auf die Anzahl von Elementen ankommt ben tigen einen Wert der sich aus dem aktuellen Modell zustand bestimmen l t Ein solcher Wert l t sich in geschlossener Form in tabellarischer Form oder durch einen Algorithmus Funktion bzw Prozedur errechnen 190 5 Systematische Darstellung der Modellbeschreibungssprache Fiir Transportanweisungen mit unterscheidbaren Elementen werden ein oder mehrere mobile Elemente ben tigt die aus einem oder mehreren Best nden auszuw hlen sind Zur Auswahl einer Menge von mobilen Komponenten kommt das Beschneiden einer geordneten Location das Beschneiden einer geordneten Eigenschaftsmenge Bestimmung des Ordnungswerts durch eine Funktion ein Algorithmus Funktion in Betracht Das Beschneiden der Mengen ist optional Aus diesen berlegungen geht hervor da die universelle Einsetzbarkeit nur hergestellt wer den kann wenn auch eine algorithmische prozedurale Bestimmung von Werten und von mobilen Elementen bzw deren Indices m glich ist siehe Kapitel 6 Da man also auf die Integration von Funktionen und Prozedur
146. e eine gute Lesbarkeit sicherstellt Beispiel Modellierung eines bin ren Zufallsprozesses STATE VARIABLES X LOGICAL FALSE TChange REAL 0 RANDOM VARIABLE TDtrue REAL GAUSS Mean 10 Sigma 3 TDfalse REAL EXPO Mean 50 IF T gt TChange LET IF X FALSE LET X TRUE TChange T TDtrue END ELSE LET X FALSE TChange T TDfalse END END In der Praxis hat sich diese L sung auch durchaus bew hrt 6 6 Tabellarische Funktionen und Verteilungen Zusammenh nge in Modellen die auf empirisch ermittelten Daten also nicht auf einer be reits vorhandenen Theorie beruhen lassen sich zun chst vielfach nur durch tabellarische Funktionen beschreiben Zwischen den bekannten St tzwerten ist ggf noch in geeigneter Weise zu interpolieren Diese Tabellenfunktionen k nnen recht umfangreiche Datenbest nde ausmachen Es erscheint daher nicht zweckm ig diese Tabellen mit in die Modellbeschreibung aufzunehmen zumal sie meist bereits auf externen Dateien vorliegen Andererseits ist die Beschreibung eines Zusammenhangs zwischen Modellvariablen Bestand teil eines Modells und sollte daher nicht im verborgenen bleiben Das sieht man auch daran da man ein Modell nicht an einen anderen Anwender weitergeben kann ohne ihm die Funk tionstabellen mitzugeben Aus diesem Grund wurden tabellarische Funktionen und Verteilungsfunktionen mitsamt ih rer St tzstellen und St tzwerte in den Modellte
147. e machen kann die das Geschehen noch berblicken k nnen Bei gro en St ckzahlen lohnt sich die Anschaffung von weitgehend bedienerlosen Fertigungs automaten Transporteinrichtungen und L ger Ihr Einsatz mu im Voraus wohl durchdacht sein um Fehlinvestitionen zu vermeiden Da auf Anfrage produziert wird interessiert nicht mehr nur der erreichbare Durchsatz Pro duktionsrate sondern vor allem auch die Durchlaufzeiten der Teile da man den Kunden nicht lange auf seine Bestellung warten lassen will Daneben ist die notwendige Anzahl an Pufferpl tzen zu ermitteln um einen reibungslosen Betrieb und damit eine hohe Auslastung der Maschinen zu gew hrleisten Auch die erfor derliche Leistung der Transporteinrichtungen ist interessant damit der Betriebsablauf nicht verz gert wird Solange jede Produktionseinrichtung nur einen einzigen Bearbeitungsgang bernimmt k nnen diese durch starre Transporteinrichtungen aneinandergereiht werden bernimmt jedoch ei ne Maschine mehrere Bearbeitungsg nge oder ist die Maschinenfolge nicht f r alle Varianten dieselbe m ssen die Maschinen flexibel miteinander verkettet werden In diesem Fall kann es passieren da ein Teil vor bergehend nicht weiterverarbeitet werden kann weil die dazu n tige Maschine noch belegt ist Umgekehrt kann es vorkommen da eine Maschine warten mu weil mit dem Zuarbeiten eines Teils nicht rechtzeitig begonnen wurde Im Gegensatz dazu ist bei starr verketteten und
148. e oder mehrere Eigenschaften des Systems auf Eine objektivierte Beobachtung d h eine Beobachtung die f r alle Betrachter gleich ist bezeichnen wir als Messung Eine Messung wird durch Vergleich mit einem Normal durch gef hrt und w hlt aus einer definierten Menge m glicher Werte Attributauspr gungen einen bestimmten Wert aus 26 2 Sprachentwurf im Sinne der klassischen Systemtheorie Eine Beobachtung v TV l t sich demnach mathematisch als eine Funktion der Zeit ansehen Die Werte welche die Beobachtung v annehmen kann geh ren einer Eigenschaftsmenge V an Die Werte welche die Systemzeit t annehmen kann sind einer Zeitmenge 7 entnommen Wir gehen nun von der Annahme aus da es m glich ist zum gleichen Zeitpunkt an ver schiedenen Stellen des Systems Beobachtungen auszuf hren Um zeitliche Ver nderungen festzuhalten soll es uns gen gen Beobachtungen in endlichen Zeitabst nden also nicht et wa kontinuierlich anzustellen Aus dem Abtasttheorem geht hervor da uns bei gen gend klein gew hlten Zeitabst nden keine Information verloren geht Ohnehin besitzt jeder reale Beobachter Me ger t nur ein begrenztes zeitliches Aufl sungs verm gen Es ist daher absolut korrekt die Zeitmenge der Systemzeit nicht der Modellzeit stets als diskret und unendlich abz hlbar anzusehen T to ti to ura y tk Weiterhin gehen wir davon aus da es m glich ist alle Beobachtungen gerade zu diesen Zeitpunkten auszu
149. eady REAL END OF Job BASIC COMPONENT Source MOBILE SUBCOMPONENTS OF CLASS Job DECLARATIONS STATE VARIABLE CONSTANT HighPrio REAL DISCRETE TNext REAL RANDOM VARIABLES Random REAL TBetween REAL EXIT LOCATION SOURCE LOCATION DYNAMIC BEHAVIOUR IF T gt LET TNext TNext T TBetween FOREACH J LET J Priorty 1 O END J gt Exit END END END OF Source Exit SET OF Job JobSource SET OF Job IN JobSource Job 1 WHEN Random lt HighPrio UNIFORM LowLimit EXPO Mean 10 237 Prioritaet Fertigstellungszeitpunkt Wahrscheinlichkeit hoher Prioritaet Zeitpunkt der naechsten Generierung 0 UpLimit 1 O Job ELSE 238 BASIC COMPONENT Sink MOBILE SUBCOMPONENTS OF CLASS Job DECLARATION ENTRY LOCATION Entrance SET OF Job SINK LOCATION JobSink SET OF Job DYNAMIC BEHAVIOUR FOREACH J IN Entrance LET J gt JobSink END END OF SinkJob BASIC COMPONENT Facility MOBILE SUBCOMPONENTS OF CLASS Job DECLARATIONS STATE VARIABLE CONSTANT NUnits INT RANDOM VARIABLE TService REAL PRIVATE LOCATION Server SET OF Job ENTRY LOCATION Queue SET OF Job EXIT LOCATION Exit SET OF Job DYNAMIC BEHAVIOUR Einlasten in eine der Bedieneinheiten IF CARD Server lt NUnits LET FOREACH J IN Queue Job 1 LET J gt Server J TReady T TService END END 1 EXPO Mean 7 Anwendungen Anzahl der Bedieneinheit
150. eben sind die funktionalen Abh ngigkeiten y mlz Y2 a filly Ya t y2 g 22 2 fa ys ys 9l2 Y2 23 Plz 23 ys galyi Ys Ys gs y3 Der dazugeh rige Abhangigkeitsgraph hat folgendes Aussehen t t J 0 0 JE 223 w gt gt v5 2o 23 23 2 5 Algorithmus f r die Simulation einer expliziten Modelldarstellung 53 Wir formen diesen Graphen nun so um da seine Pfeile nur noch nach vorne orientiert sind und sprechen dann von einem vorw rtsorientierten Graphen Diese Umformung ist nat rlich nur m glich wenn der Graph zyklenfrei d h die Modellbeschreibung semantisch korrekt ist Beispiel Vorw rtsorientierter Graph t u N 21 gt J O O O FE Ebene 0 1 2 3 4 5 Die Modellvariablen sind in diesem Graphen ebenenweise angeordnet Alle Variablen einer Ebene beruhen auf den Variablen der davorliegenden Ebenen Die Zustandsvariablen werden der Ubersichtlichkeit halber alle in die letzten Ebene gelegt Jeder Knoten und damit jede Modellvariable erh lt die Nummer der Ebene im vorw rtsorientierten Graphen zugeordnet Anhand dieser Nummer lassen sich die Variablen nun sortieren Variablen in der gleichen Ebene k nnen in jeder beliebigen Reihenfolge also auch parallel berechnet werden Beispiel
151. edienoberflche zusammenzusetzen Dadurch ergibt sich aber ein neues Problem Vielfach reichen die vorhandenen Grundbausteine nicht aus und es m ssen neue Bausteine program miert und in das Grafiksystem eingepa t werden Der Aufwand f r eine Simulationsstudie wird daher im Einzelfall sogar noch h her als zuvor Trotz gewisser Vereinfachungen in Bezug auf die Bedienung bleibt weiterhin die Notwendig keit Modelle oder Teile von Modellen leichter und nach M glichkeit auch f r den Anwender formal sprachlich beschreibbar zu machen um daraus ablauff higen Code zu erzeugen In die ser Arbeit werden daher die M glichkeiten um Warteschlangen Modelle und Modellkompo nenten mit den Mitteln einer Sprache zu formulieren aus einer neuen zustands orientierten Sichtweise nochmals grundlegend durchdacht Den Ansto dazu gab die Tatsache da keine der damals bestehenden Simulationssprachen eine Modularisierung diskreter Modelle zulie andererseits aber die Systemtheorie f r kontinuierliche Modelle aufzeigt wie Modellzerlegung in idealer Weise m glich ist Es entwickelte sich die Zielvorstellung die Vorteile des systemtheoretischen Konzepts auf diskrete Modelle und insbesondere Warteschlangenmodelle zu bertragen Der Weg dorthin erwies sich jedoch als m hsam und langwierig Vor allen Dingen stellte sich heraus da die urspr nglichen Mittel der Systemtheorie zwar prinzipiell die Beschreibung von Warteschlangenmodellen erm glichen aber nic
152. ediglich erforderlich offen zulegen welchen Code der Compiler generiert wenn er eine Funktion oder Prozedur aufruft und wie dieses Unterprogamm die Parameter entgegennimmt Der Anwender hat sich nur an diese Konventionen zu halten damit anstelle einer MDL Funktion eine C Funktion durch laufen wird In der Modellbeschreibung steht dann anstelle einer MDL Funktion die Deklaration einer C Funktion damit der Compiler Anzahl und Typen der Parameter des Funktionsaufrufs pr fen kann Beispiel C_FUNCTION Strategie INT ARRAY n REAL gt INT So einfach dieses Konzept klingen mag die Schnittstellenbeschreibung erreicht doch einen betr chtlichen Umfang Insbesondere der Umgang mit Feldern n tigt dem Anwender einigen Einarbeitungsaufwand ab 6 8 Simultanbetrieb mit anderen Prozessen Beim Einsatz eines Simulationsprogramms als Trainingssimulator wird mit einem offenen Modell gearbeitet d h das Modell bzw das Simulationsprogramm reagiert fortw hrend auf 224 6 Spracherweiterungen fiir den praktischen Einsatz Eingaben aus der Umgebung Diese Eingaben geben die Werte von Sensorvariablen vor die nicht an andere Modellkomponenten angeschlossen sind Zu diesem Zweck ben tigt das Simu lationsprogramm eine Schnittstelle die es anderen Prozessen erm glicht diese Informationen zuzusenden Die eingehenden Informationen haben etwa folgenden Inhalt Kennung Setzen einer Sensorvariablen Name der Sensorvariablen bzw deren Adresse i
153. eeignet ist Beispiel Diffusion Wir betrachten drei Beh ltnisse mit Best nden B_1 B_2 und B_3 die durch zwei Membranen getrennt sind Bi B2 B3 Wir zerlegen das Gesamtmodell in zwei identische Komponenten Jede Komponente beschreibt einen Diffusionsvorgang TRANSPORT CONNECTION K1 B2 lt gt K2 B2 Ki K2 D 412 D A23 B1 B2 C D B2 3 vi v2 V2 V3 B_1 gt B_2 D A12 B 2 gt B23 D AL23 1 02 C_2 C_3 C_1 B_1 V_1 C_2 B_2 V_2 2 5 B2 V2 C3 B3 V8 Das Volumen V_2 ist in beiden Komponenten zu halten da es eine Eigenschaft des Bestandes B_2 ist 166 4 Transporte zwischen Best nden Eine andere Modellzerlegung die sich mehr an den physikalischen Gegebenheiten orien tiert zeigt das folgende Beispiel Um jeden Bestand wird eine Komponente gelegt und der Transport durch die Trennschicht in einer gesonderten Komponente modelliert Die Modell zerlegung entspricht daher der aus dem letzten Beispiel des vorangegangenen Abschnitts Au erdem zeigt dieses Beispiel da es m glich ist ein bestehendes Modell durch Einf gen einer weiteren Komponente um einen Transportvorgang zu erweitern ohne da in die anderen Komponenten eingegriffen werden mu Dies ist nat rlich nur m glich weil die Komponenten auf die Autonomie ber ihre Best nde verzichten Beispiel Diffusion Wir betrachten zwei Beh ltnisse mit Best nden B_1 und B_2 die zun chs
154. ei dungen durch tabellarisch beschriebene Funktionen ggf mit Interpolation durch algorithmisch beschriebene Funktionen In der Mathematik sowie in allen h heren Programmiersprachen FORTRAN PASCAL C etc ist es blich Funktionen als Bestandteile von Ausdr cken zuzulassen Wir beschr nken daher die weiteren Ausf hrungen auf Ausdr cke mit und ohne Fallunterscheidung Von den Funktionen verlangen wir eine derartige Realisierung da sie keinerlei Seiteneffekte auf die Argumente oder auf andere Modellvariablen aus ben k nnen Wir setzen weiterhin voraus da der Ausdruck bzw die Funktion f r alle m glichen Zust nde einen g ltigen Wert liefert d h keine Divisionen durch Null oder Verletzungen von De finitionsbereichen auftreten Diese Fehlerm glichkeiten lassen sich leider erst w hrend des Modellaufs aber nicht bereits vom bersetzer pr fen Definitionsgleichung ohne Fallunterscheidung Hier gibt es keinen Grund von der in der Mathematik blichen syntaktischen Notation ab zuweichen assignment identifier tr_spec expression tr spec soe non non 2 4 Grundkonstruktionen des Sprachkonzepts 41 Der bergangsspezifikator tr_spec der hinter dem zu definierenden Bezeichner steht bestimmt ob es sich um den Variablenwert zum aktuellen Zeitpunkt kein Spezifikator um den Variablenwert zum nachfolgenden Zeitpunkt Spezifikator oder um die zeitliche Ableitung des
155. eichem Namen ver einbarte Aufz hlungsmenge im gesamten Modell identisch definiert ist Dies tr gt zur ber sichtlichkeit bei und ist f r den Fall wichtig da eine Sensorvariable ber eine Verbindung an eine Variable in einer anderen Komponente angeschlossen ist 6 3 Physikalische Ma einheiten Modellvariablen sind in vielen Anwendungen mit Einheiten behaftet Eine Kontrolle der Ein heiten bei Verkn pfungen von Modellvariablen erleichtert den Modellaufbau ungemein und ist von gro em dokumentarischen Wert Deshalb wird in SIMPLEX MDL standardm ig das SI Einheitensystem mit den genormten Einheiten und Vorfaktoren zur Verf gung gestellt Dar ber hinaus wird dem Anwender die M glichkeit gegeben eigene Einheiten oder gar ein eigenes Einheitensystem zu definieren Bei der Deklaration einer Variablen wird die Einheit zusammen mit der Wertemenge ange geben 216 6 Spracherweiterungen ftir den praktischen Einsatz Beispiel STATE VARIABLE CONTINUOUS X REAL m 10 m Zur Unterscheidung von anderen Bezeichnern werden Einheiten in eckige Klammern gesetzt Wird mit Einheiten gearbeitet ist f r die Standardvariable T ebenfalls eine Einheit anzuge ben Beispiel TIMEUNIT min Mit diesen Informationen lassen sich nun bei der weiteren semantischen Analyse eine Vielzahl von Pr fungen durchf hren Bei Operationen in Ausdr cken wird bei Summationen und Vergleichen auf Identit t der Einheiten und gepr ft und bei einer Pr
156. eigt erst ein gen gend langer Simulationslauf Das Laufzeitsystem ist in der Lage Situationen zu erkennen in denen keine weiteren Aktivit ten mehr m glich sind Der Anwender kann einen solchen Zustand dann ausgiebig analysieren Die berpr fung einer Modellspezifikation auf korrekte Semantik besagt lediglich da es m glich ist nach der Spezifikation ein reales System zu bauen ohne da Informationen fehlen oder sich widersprechen Deadlocks sind aber ebenso wie Lifelocks Ph nomene die sowohl im Modell wie auch im realen System in gleicher Weise beobachtbar sind Wenn hingegen der Zugriff nicht eindeutig geregelt ist liegt eine etwas andere Situation vor Ein reales System das aus Komponenten aufgebaut ist die keine Vereinbarung ber einen Zugriffskonflikt getroffen haben werden ein Verhalten zeigen das nicht im voraus geregelt war Ein Simulationsprogramm das aus einer unvollst ndigen Modellbeschreibung hervorgeht wei nat rlich nicht wie sich das reale System in einer solchen Situation verh lt Der Mo dellablauf kann daher nur mit einer Fehlermeldung beendet werden Zur Vermeidung dieser Problematik k nnte man das System im Sinne der objektorientierten Programmierung modellieren Die Pl tze w ren Komponenten Objekte die auf Anfrage selbst entscheiden ob sie dem rechten oder linken Philosophen die Gabel aush ndigen Das Objekt Platz entscheidet sich in jedem Fall eindeutig Im Gegensatz zur objektorientierten P
157. einer Komponente zusammen Hierdurch entsteht eine Blockstruktur Die Identifikation der Variablen erfolgt durch einen Pfad in dem der Reihe nach alle bergeordneten Komponenten enthalten sind 64 2 Sprachentwurf im Sinne der klassischen Systemtheorie Beispiel Variablennamen H1 A z Variable z aus Komponente A eingebettet in Komponente H1 Verbindungen H1 A z gt H2 B x H2 B y gt H1 A x H1 H2 A B Z gt x x lt yY Die Beschreibung der Kommunikation ber einen mehrstufigen Pfad macht einen tiefen Ein blick in die beteiligten Komponenten erforderlich Es erscheint daher sinnvoll eine Daten kapselung vorzunehmen und nur bestimmte Variablen einer h heren Komponente f r die n chst h here Schicht sichtbar zu machen Zu diesem Zweck ist es erforderlich Sensorvariablen und interne Variablen f r h here Kom ponenten einzuf hren Sensorvariablen h herer Komponenten nehmen Information von au en ntgegen und leiten sie an noch nicht angeschlossene Sensorvariablen von untergeordneten Komponenten weiter Interne Variablen h herer Komponenten stehen f r eine interne Variable einer untergeord neten Komponente und machen deren Information u enverf gbar Beispiel Eine h here Komponente H enth lt die Komponenten A1 A2 und B mit Sen sorvariablen x und internen Variablen z bzw y SUBCOMPONENTS A1 OF CLASS A A2 OF CLASS A B Sensorvariablen der h her
158. el Job Ort Q2 WHEN X gt O ELSE Q3 END 3 4 Einf hrung von Feldern In einem Warteschlangensystem bewegen sich meist sehr viele Elemente Um nicht f r jedes einzelne Element eine Beschreibung abgeben zu m ssen f hren wir indizierbare Elemente d h Felder ein Sp ter werden sich zwar Felder f r die Beschreibung von Warteschlangenmodellen als nicht unbedingt erforderlich herausstellen die damit verbundenen sprachlichen Konstrukte ins besondere der Allquantor lassen sich anhand von Feldern jedoch besser einf hren Dar ber hinaus sollte wegen einer Vielzahl anderer Anwendungen auf Felder ohnehin nicht verzichtet werden Jede Modellvariable bzw jedes mobile Element sowie jede Modellkomponente kann als Feld Reihung mit einer oder mehreren Dimensionen ausgebildet sein Ein einzelnes Feldelement wird durch die Angabe von Indizes je einer pro Dimension identifiziert Die Indices umfassen einen zusammenh ngenden Bereich ganzer Zahlen der bei der Dekla ration angegeben wird 3 4 1 Deklaration Jeder Bezeichner f r eine Variable oder eine Komponente auch ein Element kann als Feld vereinbart werden dimensioned_identifier ARRAY dimension_list identifier dimension_list index_range index_range index_range constant_integer constant_integer constant_integer AS operand 3 4 Einf hrung von Feldern 89 Einem Bezeichner der als Feld deklariert werden soll w
159. emnach durch die An gabe von zwei Funktionen beschrieben Der Ableitungsfunktion f und der Ereignisfunktion f F r das Verst ndnis der Beispiele in dieser Arbeit sollten diese Anmerkungen ber spezielle ZUF ausreichend sein 40 2 Sprachentwurf im Sinne der klassischen Systemtheorie 2 4 Grundkonstruktionen des Sprachkonzepts 2 4 1 Definitionsgleichungen Eine explizite Modellbeschreibung ist ein Satz von Definitionsgleichungen d h von allge meing ltigen Aussageformen f r den Vollst ndigkeit und Eindeutigkeit zu gew hrleistet ist Die Vollst ndigkeit k nnen wir dadurch sicherstellen indem wir f r jede deklarierte Modell gr e mindestens eine Definitionsgleichung verlangen Dar berhinaus fordern wir da der Abh ngigkeitsgraph zyklenfrei ist Die Eindeutigkeit ergibt sich daraus da nicht mehr als eine Definitionsgleichung angegeben werden darf Unser Ziel ist es einen Sprachentwurf anzugeben der es m glich macht diese Forderungen durch einen Rechner zu berpr fen damit ein semantisch korrektes Modell sichergestellt ist In diesem Abschnitt soll gezeigt werden da eine geeignete Syntax eine solche ber pr fung erleichtern kann Eine Definitionsgleichung bestimmt aus dem aktuellen Modellzustand den Wert einer Modell variablen Diese funktionale Abh ngigkeit kann auf verschiedene Art und Weise dargestellt werden durch explizite geschlossene algebraische Ausdr cke mit oder ohne Falluntersch
160. en 8 INC TReady 0 Job DEC Priority 7 4 Die Modellbank QueueNet Weiterleiten nach Fertigstellung i a a aa ae a a ee ee ann FOREACH J IN Server Job 1 LET IF T gt J TReady LET J gt Exit END END END OF Facility BASIC COMPONENT Advance MOBILE SUBCOMPONENTS OF CLASS Job DECLARATIONS STATE VARIABLE CONSTANT TDelay REAL 8 PRIVATE LOCATION Wait SET OF Job 0 Job ENTRY LOCATION Entrance SET OF Job EXIT LOCATION Exit SET OF Job DYNAMIC BEHAVIOUR Ankommender Auftrag ja Ss SS EEE EAS FOREACH J IN Entrance Job 1 LET J gt Wait J TReady T TDelay END Weiterleiten nach Ablauf der Verzoegerungszeit FOREACH J IN Wait Job 1 LET IF T gt J TReady LET J gt Exit END END END OF Advance 239 240 7 Anwendungen BASIC COMPONENT Distrib MOBILE SUBCOMPONENTS OF CLASS Job DECLARATIONS STATE VARIABLES CONSTANT pl REAL p2 REAL 0 5 0 5 RANDOM VARIABLES Random REAL UNIFORM LowLimit 0 UpLimit 1 ENTRY LOCATION Entrance SET OF Job EXIT LOCATION Exiti SET OF Job Exit2 SET OF Job Exit3 SET OF Job DYNAMIC BEHAVIOUR FOREACH J IN Entrance Job i LET IF Random lt pi LET J gt Exiti END ELSIF Random lt p1 p2 LET J gt Exit2 END ELSE LET J gt Exit3 END END END OF Distrib Modell einer einfachen Rechenanlage Durch Zusammenschalten der gezeigten Komponenten lassen sich im Grunde alle Mo
161. en Beispiel Ort NAME SET OF Job Deklaration J Ort NAME Queue2 Wertzuordnung Bei der Deklaration der Variablen Ort wird dazu als Wertemenge NAME SET OF identifier angegeben Als inverse Operation lie e sich der Operator VAL einf hren der den Namen einer Variablen in den Wert umformt und f r den gilt VAL NAME identifier identifier Diese Operation wird jedoch im weiteren keine Verwendung finden 3 6 5 Modellierung eines M D 1 Systems Anhand der Beschreibung eines MD 1 Systems wollen wir sehen wie sich die Verbesserungen auswirken MOBILE COMPONENT Job DECLARATIONS STATE VARIABLES Ort NAME SET OF Job NAME Reservoir TEntry REAL 0 END OF Job 116 3 Spracherweiterungen zur Formulierung von Warteschlangenmodellen ARRAY 1 N Job Queue J IN Job J Ort NAME Queue INC J TEntry Server J IN Job J Ort NAME Server INC J TEntry Reservoir J IN Job J Ort NAME Reservoir INC J TEntry FOREACH J IN Job LET END Bewegung von Queue nach Server LET IF EMPTY Server LET J Ort NAME Server J TEntry T END END Bewegung von Server nach Reservoir ELSIF J IN Server Job 1 LET IF T gt J TEntry TService LET J Ort NAME Reservoir J TEntry T END END Bewegung von Reservoir nach Queue ELSIF J IN Reservoir Job 1 LET IF T gt TGenera LET J Ort NAME Queue J TEntry T TGenera T
162. en Vorteile e symmetrische Beschreibung vorteilhaft f r Anwendung des Klassenkonzepts Nachteile o Eindeutigkeit l t sich f r den Transport individueller Elemente nicht gew hrleisten o hoher Komunikationsaufwand Alle Information zur Berechnung der Transportmengen m ssen der Zwischenkom ponente zur Verf gung gestellt werden o Verst ndlichkeit Die Verbindungen zwischen den Komponenten lassen nicht auf die Transportrich tung schlie en Wie wir feststellen ist nur bei Variante 1 f r den Transport individueller Elemente die Eindeutigkeit gesichert und der Transportvorgang auf der h heren Ebene zufriedenstellend zu erkennen 4 5 Modularisierung 159 Ein Beispiel soll dies weiter verdeutlichen Au erdem ist zu ersehen da neben der Uberga be der Transportmenge in der Regel noch weitere Kommunikation erforderlich ist um die Transportmenge berhaupt bestimmten zu k nnen Beispiel Transport von Warteschlange Queue nach Bedieneinheit Server Die Best nde befinden sich in verschiedenen Komponenten TQS Transportmenge Queue Server SenTQS Sensorvariable f r Transportmenge 1 Bestimmung der Transportmenge in der Quellkomponente Ki K2 Queue TQS Server ee a ae Server Queue Queue TQS Server Server SenTQS Bestimmung der Transportmenge in K1 IF EMPTY SenServer LET TQS ELSE LET TQS Queue Job 1 END END 2 Bestimmung der Transportmenge in
163. en die am realen Systems vorgenommen wurden oder durch die Spezifikation eines erdachten fiktiven technischen Systems Die Ergebnisse von Simulationsexperimenten liegen zun chst als Zeitreihen ggf auch stati stisch komprimiert auf Dateien vor und m ssen will man sie interpretieren oder mit anderen Ergebnissen vergleichen aufbereitet und visualisiert werden Diesen Aufgaben entsprechend gliedert sich die Simulationstechnik in die beiden Kernberei che e Erstellen des Modells d h des Simulationsprogramms e Experimentieren mit dem Modell und die beiden angrenzenden Bereiche e Modellbildung Systemanalyse und e Aufbereitung und Visualisierung der Ergebnisse welche auch Bestandteil anderer Disziplinen sind Im Verlauf der letzten 30 Jahre hat die Simulation auf Digitalrechnern die Simulation mit anderen physikalischen Systemen weitgehend verdr ngt da der Digtalrechner alle Bereiche wirksam unterst tzt und mittlerweile f r viele Anwendungen auch die erforderliche Rechen geschwindigkeit besitzt Von 1985 1991 wurde am Institut f r Mathematische Maschinen und Datenverarbeitung Lehrstuhl f r Betriebssysteme das Simulationssystem SIMPLEX II Lang 89 Esch 90 D rn 91 entwickelt das eine weitgehende Unterst tzung in allen Bereichen bietet und al le dazu erforderlichen Funktionen unter einer gemeinsamen Bedienoberfl che vereint Diese Abhandlung st tzt sich zum gro en Teil auf Erkenntnisse und Erfahrungen die be
164. en Komponente x_1 x_2 Al x xl A2 x xl B x xX_2 Interne Variablen der h heren Komponente u_11 u_12 u_2 u_li A1l z u_ll2 A2 z u_2 B y 2 6 Modularisierung 65 Da auch hier Variablen einander zugeordnet werden und ein Informationsflu dargestellt wird verwenden wir auch in diesem Fall den Verbindungsoperator gt Um weiterhin die Eindeutigkeit sicherzustellen darf auf Sensorvariable einer Subkomponente nur ein Verbin dungsoperator weisen Die in h heren Komponenten eingef hrten Sensorvariablen und internen Variablen berneh men alle Eigenschaften der mit ihnen verbundenen Variablen Eine explizite Deklaration ist daher nicht erforderlich Beim erstmaligen Auftreten des Bezeichners kann eine Deklaration implizit vorgenommen werden Beispiel SENSOR VARIABLES x_1 gt Al x x_1 gt A2 x x_2 gt B x INTERNAL VARIABLES u ti lt Al z u_l2 lt A2 z u_2 lt B y Auch f r hierarchisch strukturierte Modelle gibt es eine eindeutige graphische Darstellung Beispiel Al A r zE g T A2 A jr z E m B B T2 a vt Oy 66 2 6 6 Sprachliche Konstrukte f r h here Komponenten Entsprechend den obigen Ausf hrungen besteht eine h here Komponente aus 1 Deklaration der Subkomponenten 2 Deklaration der Schnittstellenvariablen a Sensor Variablen b inter
165. en Komponente ein deutig ein Aufenthaltsort zugeordnet Jetzt wird ber eine Location und eine Position ein deutig auf eine mobile Komponente zugegriffen Zugunsten einer modularen Zerlegbarkeit von Modellen ist ein direkter Zugriff auf mobile Komponenten nicht mehr m glich location Job i Job j Queue1 Job 1 N eee een ee Job 1 2 3 m 2 3 Queue2 Job 1 a alae 5 2 Eine Location kann als eine Zustandsvariable aufgefa t werden die den Aufenthaltsort von mobilen Komponenten bestimmt indem sie eine Teilmenge aller mobilen Komponenten ge ordnet zusammenfa t 3 8 Zusammenfassung 127 Man kann die nun entstandene Situation auch als Wechsel des Bezugssystems interpretieren W hrend bisher das Modellgeschehen aus der Sichtweise der mobilen Elemente beschrieben wurde wird es nun aus der Sicht eines bergeordneten systemweiten Betrachters dargestellt Eine Transportoperation d h ein Wechsel des Aufenthaltsortes entspricht einer Zusam menfassung zweier Operationen auf Locations einem Wegnehmen und einem Hinzuf gen von mobilen Komponenten Es gilt die folgende quivalenz f r einen Transport Q2 U Q1 Job 1 Q1 Q2 Job 1 Q27 Q1 Job l1 gt Q2 gt Q1 Diese quivalenz l t nochmals deutlich erkennen da es sich bei Locations in der Tat um Zustandsvariablen handelt Findet der Transport ber Komponentengrenzen hinweg statt so bedeutet
166. en erh lt man aus der Auftragsabwicklung die sekund ren Leistungsgr en wie Auslastung Durchsatz und Lagerbest nde kann man der Betriebsmittelnutzung entnehmen Aus diesen Betrachtungen l t sich auf die notwendige Funktionalit t einer Modellbeschrei bungssprache schlie en Erforderliche Datentypen f r Zust nde Variablen mit unterschiedlichen Wertemengen f r Auftr ge Verbunde sowie Felder oder Listen von Verbunden f r Warteschlangen Listen von Verbunden Erforderliche Funktionen Zustandswechsel deterministisch zustandsbedingt und zeitbedingt stochastisch Bestimmung von Folgezustand und Zustandsdauer Entnehmen von Auftr gen aus Warteschlangen nach beliebigen Strategien Einreihen von Auftr gen in Warteschlangen nach beliebigen Kriterien Erzeugung und Vernichtung von Unter Auftr gen Senden und Empfangen von Unter Auftr gen 20 1 Einleitung Cis Conte gt Zeitanteil Abb 1 5 3 Prim re Leistungsgr en aus Zust nden der Auftr ge arten gt outr nen I bearbeiten X bristen X Zeitanteil Abb 1 5 4 Sekund re Leistungsgr en aus Zust nden der Betriebsmittel 1 5 Neue Anforderungen an die Simulationstechnik 21 Delegieren von Auftr gen an Stationen nach beliebigen Auswahlstrategien Von genau den gleichen Betrachtungen ist brigens die Simulationssprache GPSS motiviert Allerdings ist es dort nur m glich die Au
167. en in eine allgemeine Modellbeschreibungssprache ohnehin nicht verzichten kann ist es aber andererseits m glich den deklarativen Sprachteil unter Hinweis auf algorithmische Funktionen und Prozeduren in engen Grenzen zu halten So w re es m glich auf tabellarische Funktionen oder die Bildung von Eigenschaftsmengen zu verzichten Ob dies ratsam ist m ssen weitere Erw gungen kl ren Mit der folgenden Darstellung soll dem Leser ein geschlossenes sprachliches Konzept vor Augen gef hrt werden Die Sprachsyntax wird in einer solchen Weise angegeben da sie m glichst viel von der Sprachsemantik vermittelt Sie ist daher etwas ausschweifend und in dieser Form nicht f r einen Parser zu gebrauchen Sie l t sich allerdings jederzeit in eine LR 1 Grammatik umformen 5 1 Grundlegende Konzepte der Sprache In einem formalen Modell wird durch eine mathematische Notation beschrieben welche Zu sammenh nge zwischen Beobachtungen an der Realit t vorherrschen Diese Zusammenh nge gelten f r alle Beobachtungszeitpunkte Eine Beobachtung bezieht sich stets auf ein bestimmtes Gebiet im Anschauungsraum Idealisiert kann ein Raumgebiet auch ein Punkt eine Linie oder eine Fl che sein Inner halb eines Raumgebiet k nnen wir Eigenschaften oder Best nde Inhalte beobachten Jede Beobachtung wird durch den Zeitverlauf einer Variablen dargestellt Demnach unter scheiden wir e Eigenschaftsvariablen Attribute Qualit ten oder e Bestandsvar
168. en und kann daher nie zur Anwendung kommen Ist eine Bedingung gar allgemeing ltig d h f r alle Zust nde erf llt dann bleiben alle wei teren Zweige unber cksichtigt Die Modellbeschreibung ist in diesen F llen zwar vollst ndig und eindeutig dennoch ist klar da hier wohl ein gedanklicher Fehler bei der Formulierung der Bedingungen vorliegt der nicht erkannt wird Dem sind zwei Dinge zu entgegnen Erstens kann man prinzipiell nicht erwarten da sich gedankliche Fehler durch eine Fehlermeldung zur Laufzeit oder bersetzungszeit u ern In aller Regel so auch hier wird das Modell ein fehlerhaftes Verhalten zeigen Zweitens ist die Formulierung der Bedingungen bei der ersten Variante ungleich komplizierter und l t daher sehr viel h ufiger Fehler erwarten In der Praxis hat sich gezeigt da die sukzessive Fallunterscheidung vom Anwender bes ser gehandhabt werden kann Er wird durch die Syntax von Anfang an dazu angehalten dar ber nachzudenken in welcher Weise der gesamte Zustandsraum zu unterteilen ist Er mu nicht selbst f r den gegenseitigen Ausschlu der Bedingungen sorgen und er kann eine Fallunterscheidung ohne gro e M he durch weitere F lle erg nzen 44 2 Sprachentwurf im Sinne der klassischen Systemtheorie Wir stellen nun die Syntax fiir eine Fallunterscheidung in zwei verschiedenen Varianten vor die Wertzuweisung mit bedingtem Ausdruck WHEN Konstrukt und die bedingte Aussa geform IF Konstruk
169. enten in einem abgegrenzten Raum darstellt ergeben sich eine Reihe von abgeleiteten Eigenschafts gr en mit ihren Ma einheiten Dichte Konzentration Menge von Einheiten pro Rauminhalt Menge De Volumen Strom Menge von Einheiten durch eine Grenzfl che pro Zeit Menge Strom T Zeit T Stromdichte Menge von Einheiten durch eine Grenzfl che pro Zeit und Fl che Menge Stromdichte Zeit Fl che Wegen der zentralen Bedeutung der Bestandsgr en in den empirischen Wissenschafen sei hier die Vermutung ausgesprochen da alle Eigenschaftsgr en aus Bestandsgr en ableitbar sind Daraus w rde resultieren da Eigenschaftsgr en stets zu den abh ngigen Variablen z hlen w hrend Bestandsgr en allein den Zustand bestimmen Mit wenigen Ausnahmen wurde diese Vermutung durch Modelle der unterschiedlichsten Fachrichtungen best tigt In den wenigen F llen in denen dies nicht zutrifft erscheinen gar keine Bestandsgr en im Modell Es liegt daher der Verdacht nahe da diejenigen Ei genschaftsgr en welche als Zustandsvariablen fungieren lediglich Bestandsgr en substi tuieren Die Vermutung wird dadurch erh rtet da in den Wirtschafts und Sozialwissenschaften seit zwei Jahrzehnten eine Methode zur graphischen Darstellung von Modellen praktiziert wird die nur Best nde als Zustandsgr en kennt System Dynamics Auf diese Darstellungsform wird daher an sp terer Stelle noch a
170. er Anwender sein Modell nicht selbst programmieren kann Diese Problematik wurde schon sehr fr hzeitig erkannt und man versuchte durch verschie dene Hilfsmittel Verbesserungen zu erreichen Diese wollen wir unterscheiden in a simulations unterst tzende Programmiersprachen 8 1 Einleitung b Programmpakete fiir die Simulation c datengesteuerte Simulatoren d Simulationssprachen Simulations unterst tzende Programmiersprachen Die simulations unterst tzenden Programmiersprachen zeichnen sich durch Spracherwei terungen aus welche Simulationsanwendungen unterst tzen sollen Hierzu z hlen SIMU LA Rohl 73 sowie alle objektorientierten Sprachen wie SMALLTALK Kaehl 86 C Strou 87 oder Object C Schnu 91 Die Unterst tzung beschr nkt sich jedoch im wesentlichen auf die Bildung von abstrakten Datentypen sogenannte Objekt Klassen von denen mehrfache Auspr gungen Objekte an gelegt werden k nnen Jedes Objekt besteht aus einem individuellen Satz von Variablen und einem Satz von Funktionen Methoden die nur auf den Datenbest nden des Objekts operieren und allen Objekten einer Klasse gemein sind Ein Objekt kann ber Botschaften Methoden eines anderen Objekts ansto en Nicht vorgesehen ist im allgemeinen jedoch die Nebenl ufigkeit von Objekten Eine Ausnah me davon bildet lediglich SIMULA das damit proze orientierte Modellimplementierungen erlaubt Das von den objekt orientierten Sprachen angebotene Vererbun
171. eration beenden und mit der Bestimmung des neuen Zustands fortfahren Andererseits zeigt die Erfahrung da man gerade bei gr eren Modellen durchaus mit min destens 5 Zyklen rechnen mu da die Modellkomponenten oft in einer ungl cklichen Rei henfolge aufgerufen werden Wir sind daher mehr an gezielten Ma nahmen interessiert die auch von der Einflu nahme des Benutzers unabh ngig sind F r Effizienzverbesserungen werden wir wiederum Marken einsetzen Es ist die Aufgabe der Marken zu steuern welche Teile des Programms tats chlich auszuf hren sind Hierbei unterscheiden wir Ma nahmen die mit statischen Marken arbeiten von solchen die dynami sche Marken einsetzen Statische Marken legen den Programmflu einmal fest und werden ber den ganzen Programmlauf hinweg beibehalten Dynamische Marken optimieren den Programmflu w hrend des Ablaufs 2 7 2 Effizienzverbesserung durch statische Marken Alle Effizienzverbesserungen beruhen im wesentlichen darauf eine Komponente nur dann aufzurufen und eine Variable nur dann neu zu berechnen wenn es n tig ist Mit Hilfe statischer Marken l t sich dies durch die beiden folgenden Ma nahmen erreichen 1 Aussondern derjenigen Bestimmungsgleichungen die in der aktuellen Ebene nicht zu berechnen sind 2 7 Algorithmus f r die Simulation einer modularen Modellbeschreibung 71 Hierzu erh lt jede Variable neben ihrem Wert als weiteren Eintrag die Nummer der Ebene y_i Level zugeordnet
172. ere Forderung ergibt sich aus der Tatsache da eine Gr e zu einem Zeitpunkt stets nur einen einzigen Wert annehmen kann 3 Jede Modellgr e mu eindeutig bestimmt sein Beispiel F r die Gr e X sei die Gleichung X 2 T gegeben Diese Gleichung liefert zwei L sungen n mlich Xi ENGE Xa S Dealer Der Wert der Gr e X ist durch die angegebene Gleichung nicht eindeutig bestimmt Um in solchen F llen die Eindeutigkeit sicherzustellen sind Zusatzbedingungen erfor derlich welche alle nicht g ltigen L sungen ausschlie en Einen Satz von Beziehungen ggf mit Zusatzbedingungen bezeichnen wir als eine formale Modellbeschreibung oder auch als mathematisches Modell Eine Modellbeschreibung enth lt die gesamte Information die man ben tigt um aus einem gegebenen Anfangszustand die Systemdaten zu reproduzieren Aussagenlogisch betrachtet werden dabei die Ausageformen zu konkreten Aussagen Lassen sich die Gleichungen nach den Modellgr en explizit aufl sen sprechen wir von einer expliziten Modelldarstellung andernfalls von einer impliziten Modelldarstellung 2 1 3 Implizite Modelldarstellungen Wir haben festgestellt da jede Systemgr e einen Funktionsverlauf ber der Zeit repr sen tiert und damit zu jedem Zeitpunkt einen eindeutigen Wert annimmt Naturgem ist zu einem Zeitpunkt auch nur eine Beobachtung m glich Wie ist es dann berhaupt denkbar da Gleichungen mit mehreren L sungen in
173. erst ndlichkeit Die Verbindungen zur Weitergabe der Transportmengen weisen entgegen der Transportrichtung 3 Bestimmung der Transportmenge in beiden Komponenten B1 F sB_1 SB_2 f B2 T12 IN B1 T12 IN SB1 T21 IN SB2 T21 IN B2 B_1 Bi T12 T21 BO B2 T12 T21 Vorteile e Eindeutigkeit l t sich gew hrleisten e Symmetrie Eine gleichartige Beschreibung in beiden Komponenten ist vorteilhaft f r Anwen dung des Klassenkonzepts Nachteile 158 4 Transporte zwischen Best nden o Kompaktheit und Fehleranf lligkeit Transportmenge wird zweifach bestimmt und mu identisch sein o Verst ndlichkeit Die Verbindungen zwischen den Komponenten lassen nicht auf einen Transport schlie en In der Regel erh hter Kommunikationsaufwand da in beiden Komponenten die Information zur Berechnung der Transportmengen vorliegen mu 4 Bestimmung der Transportmenge in einer gesonderten Komponente SB_1 T12 T21 SB_2 E Eai B_1 B_2 ST_12 gt ST_12 ST_21 r gt ST_21 B 1 B_1 ST_12 B27 B2 ST 12 ST_21 ST_21 Alle zur Bestimmung der Transportmengen ben tigten Informationen werden der ge sonderten Komponente zur Verf gung gestellt Die ermittelten Transportmengen wer den dann wiederum an die Komponenten weitergegeb
174. es Beispiel ben tigt das als Vorbild weitere Modelle dienen kann die Sprache und die Modellierungstechniken m ssen im Selbststudium erlernbar sein der Umgang mit dem System mu den Eindruck vermitteln als w te man ohne nachzulesen wie es zu bedienen ist u s w Trotz oder gerade wegen der vielen Bem hungen gewinnt man im Lauf der Zeit leider den Eindruck da die Qualit t nicht der ausschlaggebende Gesichtspunkt f r die Akzeptanz eines Erzeugnisses ist Es ist schade wenn deshalb so viele Entwicklungen an Hochschulen und auch anderswo im Sande verlaufen 259 F r zuk nftige Entwicklungen erscheint vor allem eine Verbreiterung des Anwendungsfeldes interessant Die vorgestellte Spezifikationssprache wurde zwar zum Zweck der Simulation ent worfen aber auch im Bereich der Proze automatisierung und der Steuerungstechnik k nnte sie evtl in modifizierter Form Verwendung finden In diesen Gebieten werden zur Durchf hrung von Simulationsstudien Modelle erstellt die bereits gro e Teile des zu realisierenden Systems beinhalten Es erscheint daher berfl ssig die Teile nochmals in einer Implementierungssprache zu codieren Daher gilt es zu pr fen ob es nicht m glich ist in diesen Anwendungsgebieten auf eine Programmierung in einer Imple mentierungssprache vollst ndig zu verzichten und nur noch mit einer Spezifikationssprache zu arbeiten 256 257 Literaturverzeichnis ApEsWi 92 Boh 81 BORIS 85
175. es Konzept um neue Bausteine zu erweitern wenn die angebotenen Komponenten f r den Anwendungsfall nicht ausreichen Nur der Entwickler des Simulators selbst ist hierzu in der Lage Jeder neue Baustein bedeutet aber eine Erweiterung des originalen Simulators Um nicht eine Flut von Spezialbausteinen f hren oder f r jeden Anwender eine eigene Version unterhalten zu m ssen wird der Entwickler aber nur bereit sein solche Bausteine neu aufzunehmen die von allgemeinem Interesse sind Der Anwender wird daher in der Regel mit der angebotenen Modellwelt vorlieb nehmen m ssen Daher entstand die Idee das gesteckte Ziel zweistufig zu erreichen In der ersten Stufe sollte ein Werkzeug zur Verf gung gestellt werden mit dessen Hilfe Bausteine ohne Kenntnis eines darunterliegenden Simulationspakets definiert werden k nnen In der zweiten Stufe sollte eine graphische Bedienoberfl che entstehen die nicht nur mit vorgefertigten Bausteinen operieren kann sondern die es gleichwohl erlaubt neue Bilder Icons f r neue Komponenten zu gestalten und diese wiederum f r den Modellaufbau heranzuziehen Dar ber hinaus sollte es m glich sein Icons f r eine Animation vorzubereiten Auf diese Weise sollte die gleiche komfortable Bedienung erreicht werden wie man sie von den datengesteuerten Simulatoren kannte allerdings mit einer viel h heren Flexibilit t da der Anwender nicht nur mit einem vordefinierten Satz von Komponenten auskommen mu te Aber auch bei
176. eschreibung wird die Transportmenge in zwei getrennten Glei chungen ben tigt Deshalb bietet es sich an die Transportmenge an gesonderter Stelle zu bestimmen und in einer eigenen abh ngigen Variablen festzuhalten Aber auch aus anderen Gr nden l t es sich nicht umgehen eine Zwischenvariable zu ver wenden Der folgende Abschnitt kl rt die Ursachen hierf r und bietet eine L sung an die eine explizite Bestimmung der Transportmenge vermeidet 146 4 Transporte zwischen Best nden 4 3 6 Bestandsbezogene Beschreibung des Transports ohne explizite Bestimmung der Transportmenge Das Hauptproblem besteht darin da eine Summenbildung ber abschnittsweise definierte Funktionen in geschlossener Form nicht m glich ist Insbesondere bei diskreten und element weisen Transporten ist die Transportmenge immer durch Fallunterscheidungen vereinbart Bei kontinuierlichen Transporten ist dies in vielen F llen hingegen nicht der Fall Eine Zu sammenfassung der Gleichungen ist dann problemlos m glich Wir betrachten hierzu das folgende Beispiel n_12 n_23 9 05 cond_12 cond_23 T_12 n_12 WHEN cond_12 ELSE 0 END T_23 n_23 WHEN cond_13 ELSE 0 END B_2 B_2 T_12 T_23 Eine Substitition der Variablen T_12 und T_23 in der letzten Zeile durch einen Aus druck ist nicht m glich weil die Sprachsyntax keine entsprechenden Konstruktionen vorsieht Eine Erweiterung der Syntax f r algebraische Ausdr cke allein aus diesem Grund er
177. etreiben wenn einzelne Sensorvariable nicht angeschlossen ist Dies ist zu Testzwecken w nschenswert aber auch um ein Modell nach und nach Bottom up aufzubauen 2 6 Modularisierung 61 2 6 3 Klassenbildung Ein Modell l t sich u U so zerlegen da gleichartige Komponenten auftreten Sie besitzen zwar ein identisches dynamisches Verhalten aber ihre Variablen unterscheiden sich in ihren aktuellen Werten In diesem Fall gen gt nat rlich die Beschreibung dieser Komponenten nur ein einziges Mal niederzulegen Um solche gleichartigen Komponenten zu unterscheiden kann man sie entweder mit verschiedenen Indizes oder verschiedenen Namen versehen Die Beschreibung einer Komponente vereinbart demnach eine Klasse von Komponenten von der mehrere Auspr gungen instances incarnations in einem Modell enthalten sein k nnnen Beispiel Komponentenklasse A Z ae f x re y g R z Modell mit Auspr gungen A1 und A2 der Klasse A SUBCOMPONENTS A1 OF CLASS A A2 OF CLASS A EFFECT CONNECTIONS Al y gt A2 x A2 y gt Al x Al A A2 A vi z z By Am Rahmen eines K stchens steht nun in der graphischen Darstellung hinter dem Aus pr gungsnamen in Klammern der Klassenname der Komponente Eine Belegung des Anfangszustands ist bereits innerhalb der Komponenten vorgesehen Diese Vorbesetzung hat jedoch f r alle Auspr gungen einer Komponentenklasse G ltigkeit
178. f hren Die Zusammenfassung aller Beobachtungen am realen System zu einem Zeitpunkt bezeichnen wir als den Systemzustand V tk v tk va t Spa vilt sl Alle ber die Zeit hinweg am System gewonnenen Me daten lassen sich nun in einer Tabelle anordnen die folgende Gestalt hat Zeit Beobachtungen t v V2 V3 U4 to ty t2 t3 tk Als zustands orientierte Beschreibung bezeichnen wir schlie lich einen Satz von Gleichun gen der die Beziehungen zwischen den Me werten in dieser Tabelle herstellt Im Sinne der Aussagenlogik handelt es sich bei den Gleichungen um allgemeing ltige Aussageformen 2 1 Systemtheoretische Modellbeschreibung 27 2 1 2 Aufstellen der mathematische Beziehungen Mathematische Beziehungen lassen sich unterscheiden in statische Beziehungen G V tz dynamische Beziehungen F V t V tk 1 unabh ngige Beziehungen E v tx Son Statische Beziehungen verkn pfen Daten eines Zeitpunkts Zustands miteinander Dyna mische Beziehungen verkn pfen Daten zweier aufeinanderfolgender Zeitpunkte miteinander Wenn Totzeiten eine Rolle spielen werden auch weiter zur ckliegende Zust nde mit ein bezogen Unabh ngige Beziehungen geben einzelne Gr en als reine Zeitfunktion d h un abh ngig vom jeweiligen Modellzustand an Ein Satz von mathematischen Beziehungen weist jedoch nur dann eine einwandfreie Se mantik auf wenn sich aus den angegebenen Beziehun
179. fa t die gebundene Variable alle m gli chen Indices dieser Dimension Die gebundene Variable wird implizit deklariert und besitzt nur innerhalb der Definitionsgleichung G ltigkeit Bei der Definition von abh ngigen Variablen darf keine den Indexbereich einschr nkende Bedingung verwendet werden Beispiel xX i ve 2 x Y i Beispiel X 1 y i X i IN 2 10 2 Y i Beispiel Z i High WHEN X i gt 10 ELSE Low WHEN X i lt 10 END Beispiel Z i i lt O Z i WHEN X i lt Y i AND Z i lt 0 END Der implizite Allquantor l t dem Anwender etwas weniger Freiheiten erm glicht aber eine grifige und kompakte Formulierung sowie einen sicheren Gebrauch ohne da man etwas ber semantische Einschr nkungen wissen m te 100 3 Spracherweiterungen zur Formulierung von Warteschlangenmodellen 3 5 Einf hrung von Indexmengen Im ersten Ansatz formulieren wir Warteschlangenmodelle indem wir durch Mengenbildung feststellen welche mobilen Elemente sich auf demselben Aufenthaltsort befinden und welche Elemente bzw wieviele bestimmte Eigenschaften besitzen 3 5 1 Bildung von nicht geordneten Indexmengen Indexmengen werden f r gew hnlich durch Aufz hlung einzelner Indices bzw Indexbereiche oder durch die Angabe von Eigenschaften beschrieben F r unsere Zwecke kann die Bildung von Mengen sehr einfach gehalten werden Mit R cksicht auf die Lesbarkeit d rfen Eigenschaftsmengen daher lediglich dur
180. finition_part declaration_part dynamic_behaviour END OF identifier mobile_component MOBILE COMPONENT identifier mobile_subclass_declaration definition_part declaration_part END OF identifier rm Von allen Bestandteilen einer Basiskomponente oder mobilen Komponente ist nur der De klarationsteil nicht optional Im ersten Abschnitt werden mobile Komponenten genauer Klassen von mobilen Komponenten deklariert die in der Komponente ben tigt werden mobile_subclass_declaration MOBILE SUBCOMPONENT S OF CLASS identifier identifier In einem Definitionsteil kann sich der Benutzer eigene Beschreibungsmittel wie Dimensionierungskonstanten Wertemengen durch Aufz hlung Ma einheiten tabellarische Funktionen und Verteilungen algorithmische Funktionen und Prozeduren Schnittstellen zu Funktionen und Prozeduren in der Basissprache C vereinbaren definition_part DEFINITION S DIMENSION identifier unsigned_number VALUE SET identifier enum_value_list 5 2 Deklaration in Basiskomponenten und mobilen Komponenten 193 UNIT identifier unit_description TABULAR FUNCTION tabular_function_definition TABULAR DISTRIBUTION tabular_function_definition FUNCTION algorithmic_function_definition PROCEDURE algorithmic_procedure_definition C_FUNCTION c_function_declaration C_PROCEDURE c_procedure_declara
181. folgenden Typen von Ausgangsbest nden Ausgangs Bestand zur bertragung EXIT Rechte L WA S V1 B WK H V1 Ausgangs Bestand zum Sammeln Gathering GEXIT Rechte L WA S V1 B WA H V1 Ausgangs Bestand zum Verteilen Distributing DEXIT Rechte L WA S VA B WK H VA Ausgangs Bestand zum Sammeln und Verteilen GDEXIT Rechte L WA S VA B WA H VA Die Eingangsbest nde unterteilen wir in die folgenden Typen Eingangs Bestand zur bertragung ENTRY Rechte L WA S WK B V1 H WK Eingangs Bestand zum Sammeln Gathering GENTRY Rechte L WA S WK B VA H WK Eingangs Bestand zum Verteilen Distributing DENTRY Rechte L WA S WA B V1 H WA Eingangs Bestand zum Sammeln und Verteilen GDENTRY Rechte L WA S WA B VA H WA 4 6 Transportbezogene Modularisierung mit Teilautonomie 173 Erzielen eindeutigen Verhaltens Das Modellverhalten bei schreibenden oder holenden Zugriffen auf einen Bestand wird im mer dann eindeutig beschrieben wenn nur eine einzige Komponente den schreibenden oder holenden Zugriff ausf hrt Folgende Typen von Best nden garantieren daher eine eindeutige Beschreibung PRIVATE EXIT GEXIT ENTRY GENTRY quivalenzierung von Best nden verschiedenen Typs Aufgrund der zugeteilten Rechte kann bei quivalenzierung in einer h hreren Komponente gepr ft werden ob das Zusammenlegen der Best nde erlaubt ist oder nicht Folgende Verbindungen sind erlaubt PRIVATE
182. ftragsabwicklung zu modellieren Die Betriebs mittelzuteilung und Betriebsmittelnutzung kann nicht individuell beschrieben werden Die Machtigkeit der Sprache ist deshalb in keinster Weise ausreichend um die notwendige Funk tionalit t in allgemeiner Weise herstellen zu k nnen 1 5 2 Anforderungen an die Ergonomie Zu Beginn der achtiger Jahre entstand das CIM Konzept computer integrated manufactu ring das den Zeitraum von der Idee eines Produkts bis zu dessen Fertigung auf automati sierten Produktionseinrichtungen deutlich verk rzen sollte Zu diesem Zweck sollten die Entwickler eines neuen Produkts die Planer der Fertigungsanla gen sowie die Betreiber der Fertigungsst tten auf eine gemeinsame Datenbasis zur ckgreifen k nnen Dort gespeicherte Daten sollten auch die Grundlage f r eine Simulation der geplanten Pro duktionsanlagen sein Der Anwender sollte f r die Simulation nur noch ein Minimum an Daten erg nzen m ssen um seine Ergebnisse als Animation oder Pr sentation auf dem Bildschirm zu sehen Neben der Modellerstellung aus einer gemeinsamen Datenbasis wurden noch betr chtliche andere Anforderungen genannt Entsprechend dem physikalischen Aufbau einer Fertigungs anlage sollte das Gesamtmodell aus seinen Systemkomponenten zusammengesetzt werden k nnen Bei dieser Vorgehensweise sollte selbstverst ndlich die Denkwelt des Planers nicht verlassen werden Er sollte seine Komponenten als bekannte graphische Symbole wiede
183. g nge werden durch Angabe der St ckzahl beschrieben die zum folgenden Zeitpunkt in den Zielbestand berwechselt b Kontinuierliche Transporte werden durch die im aktuellen Zeitpunkt g ltige Trans portrate beschrieben Hierzu wird der Transportpfad mit einem Apostroph versehen quantity_transport selected_location gt selected_location tr_spec conditional_expression tr_spec j Das H kchen als bergangs Spezifikator findet keine Verwendung 5 3 5 Das IF Konstrukt Wertzuweisungen und Transportanweisungen k nnen durch ein IF Konstrukt nach F llen unterschieden werden conditional_statement IF expression LET statement_sequence ELSIF expression LET statement_sequence ELSE LET statement_sequence END Bei der Anwendung dieses Konstrukts ist darauf zu achten da e abh ngige Variablen vollst ndig definiert werden d h in allen Zweigen einschlie lich des ELSE Zweiges mit einer Definitionsgleichung vertreten sind e alle Attribute und Best nde eindeutig definiert werden d h au erhalb des IF Konstrukts nicht mehr auftreten d rfen Bei der Verwendung indizierter Variablen gilt dies f r jeden einzelnen Index 5 3 6 Das FOREACH Konstrukt Das FOREACH Konstrukt verallgemeinert Aussageformen fiir eine Menge von Indices Hier zu stellt das FOREACH Konstrukt einen Bezeichner gebundene Variable zur Verfiigung der fiir jeden einzelnen Index bzw fiir jedes einzel
184. geben Auf diese Weise wird eine quivalenz zum Zugriff von mobilen Elementen hergestellt die sich auf Best nden befinden Als geordnete Menge kann ein Bestand location oder eine Eigenschaftsmenge ordered_property_set herangezogen werden Eine Bildung von Ausdr cken d h eine Verkn pfung von Mengen durch Operatoren ist an dieser Stelle nicht sinnvoll weil dadurch die Mengen wieder ihre Ordnung verl ren und somit nicht mehr beschnitten werden k nnten Ohne Einschr nkung der Allgemeinheit l t sich die Verkn pfung von Mengen hingegen bei der Bildung von Eigenschaftsmengen einbringen 5 3 9 Die Bildung von Eigenschaftsmengen Eigenschaftsmengen werden aus einer Grundmenge heraus gebildet Die Grundmenge einer Indexmenge wird durch Angabe eines Indexbereiches die Grundmenge einer Menge aus mo bilen Elementen wird durch Angabe eines Bestandes oder einer Verkn pfung von Best nden angegeben Aus dieser Grundmenge kann durch die Angabe einer Bedingung eine reduzierte Menge gebil det werden die durch Angabe eines oder mehrerer Ordnungskriterien noch in eine andere Ordnung gebracht werden kann Ohne eine Neuordnung gilt die Ordnung der Grundmenge bei Indexmengen eine aufsteigende Reihenfolge ordered_property_set identifier IN basis_set gt condition criteria_list basis_set actual_index_range location_expression actual_index_range constant_integer constant_integer
185. gehen wir davon aus da die Auswahl des einen oder anderen Elements weder auf das Modellverhalten noch auf die Simulationsergebnisse Einflu hat W re dies der Fall so k nnte man durch hinzuziehen weiterer Attribute die Ordnung klarstellen Wurden bereits alle Attribute eines Elements zum Festlegen der Ordnung herangezogen dann k nnen nur gleiche Elemente mit gleichen Attributen um denselben Platz konkurrieren Nach einem Transport wird demnach keine Position am neuen Aufenthaltsort bestimmt d h es erfolgt kein Einreihen in eine Warteschlange Erst bei einem selektiven Zugriff wird eine Ordnung hergestellt Ein Aufenthaltsort ist daher als Warteraum und nicht als Warteschlange anzusehen An einem weiteren Beispiel wird ersichtlich da die Entnahme aus einem Warteraum durch das Herstellen einer Ordnung auch in schwierigeren F llen beschreibbar ist 106 3 Spracherweiterungen zur Formulierung von Warteschlangenmodellen Beispiel Falls in Q1 fiinf Elemente enthalten sind werden die zwei langsten Attribut Laenge die kleiner sind als eine maximale Lange LMax entnommen und nach Q2 gebracht Falls zwei Elemente gleich lang sind wird dasjenige ausgewahlt das Q1 zuerst betreten hat ARRAY 1 N Job FOREACH i IN 1 N LET IF CARD j IN 1 N Job j Ort Q1 gt 5 LET IF i IN j IN1 N Job j Ort Q1 AND Job j Laenge lt LMax DEC Job j Laenge INC Job j TEntry 1 2 LET Jobli Ort Q2
186. gen eine eindeutige Aussage ber den Zeitverlauf jeder Gr e treffen l t Hierzu m ssen f r ein Gleichungssystem mit M Beziehungen und N Gr en die folgenden Forderungen erf llt sein 1 Die Beziehungen m ssen widerspruchsfrei sein Beispiel Es seien die drei Gleichungen z 2y z OV x 2y z 0 z sin wt mit den Gr en x y und z angegeben Aus den ersten beiden Gleichungen folgt die Aussage x 0 der die letzte Gleichung offensichtlich widerspricht 2 Der Satz von Beziehungen mu vollst ndig sein Wenn das Modell N Modellgr en enth lt m ssen mindestens M gt N Beziehungen angegeben sein wobei N Beziehun gen voneinander unabh ngig sein m ssen d h von den M angegebenen Beziehungen d rfen nicht mehr als die berz hligen M N Beziehungen aus den brigen Beziehun gen abgeleitet werden k nnen Beispiel Es seien die drei Gleichungen 4y z 0 Lt2y z Q ytz 0 mit den Gr en x y und z angegeben Die beiden ersten Beziehungen implizieren die dritte d h das Gleichungs system ist noch nicht vollst ndig man sagt auch es ist unterbestimmt In aller Regel ist M N d h man gibt nicht mehr Gleichungen an als Gr en vorhan den sind In diesem Fall m ssen alle Beziehungen voneinander unabh ngig sein d h es darf dann keine einzige Gleichung aus den brigen abgeleitet werden k nnen 28 2 Sprachentwurf im Sinne der klassischen Systemtheorie Eine weit
187. gies in SIMULATION Volume 32 No 3 March 1979 pp 69 82 Page B B lckow R Heydermann A Kadler R Liebert H Simulation und moderne Programmiersprachen Springer Verlag Fachberichte Simulation Bd 8 Berlin 1988 Pedgen C Dennis Introduction to SIMAN Systems Modelling Corporation Calder Square PN 1986 Pichler Franz Mathematische Systemtheorie Dynamische Konstruktionen Walther de Gruyter Berlin 1975 Pritsker A Alan B The GASP IV Simulation Language John Wiley New York 1974 Pritsker A Alan B Pedgen C D Introduction to Simulation and SLAM John Wiley New York 1979 260 Prit 82 Richt 93 Rohl 73 Russ 83 Schm 84a Schm 84b Schm 85 Schm 88 Schnu 91 Schr 91 Sch r 77 Sieg 91 Strou 87 Literaturverzeichnis Pritsker amp Associates Hrsg A Comparison of three general purpose Simulation Languages SLAM SIMSCRIPT and GPSS erschienen im Selbstverlag P O Box 2413 West Lafayette Indiana 47906 Oktober 1982 Richter Oliver Statistische Disposition in flexiblen Fertigungssystemen Diplomarbeit am IMMD 4 der Universitat Erlangen 1993 Rohlfing Helmut SIMULA Bibliographisches Institut Mannheim 1973 Russel Edward C Building Simulation Models with SIMSCRIPT 11 5 CACTI Los Angeles 1983 Schmidt Bernd Der Simulator GPSS FORTRAN Version 3 Springer Verlag Fachberichte Simulation Bd 2 Berlin 1984 Schmidt Bernd
188. gramm und Experimentierumgebung in SIMPLEX II Diplomarbeit am IMMD4 der Universitat Erlangen 1992 Unbehauen Rolf Systemtheorie Eine Darstellung f r Ingenieure Oldenbourg Verlag Miinchen 1980 Wunsch Gerhard Handbuch der Systemtheorie Oldenbourg Verlag Miinchen 1986 Ziegler B Elzas M Klir Oren T Hrsg Methodology in Systems Modelling and Simulation North Holland Amsterdam 1979
189. gskonzept erscheint uns f r Simulationsanwendungen weniger nutzbringend Bei keiner der von unserer Arbeitsgrup pe zahlreich durchgef hrten Anwendungen h tte dieses Konzept nennenswerte Vorteile ge bracht Letztendlich liefern objekt orientierte Sprachen nur ein Konzept f r die Modularisierung von Programmen Richtig eingesetzt werden Simulationsprogramme dadurch tats chlich et was lesbarer Den gleichen Effekt erreicht man aber auch durch eine disziplinierte Program mierung mit anderen Sprachen Beim strukturellen Aufbau eines Simulationsprogramms der Implementierung der Ablaufsteuerung sowie der gesamten Ein Ausgabe erf hrt der Programmierer jedoch nach wie vor keine direkte Unterst tzung Eine Ann herung an die Modellwelt des Anwenders leisten diese Sprachen berhaupt nicht Der komponentenwei se Aufbau kontinuierlicher Modelle ist zudem g nzlich unm glich da man hierf r andere Kommunikationsmechanismen ben tigt Simulationspakete Simulationspakete sind Programmpakete f r Simulationsanwendungen Sie sind in einer h heren Programmiersprache geschrieben und unterst tzen den Anwender beim Aufbau und der Strukturierung von Simulationsprogrammen Dazu stellen sie dem Programmierer einen Programmrahmen zur Verf gung in den er nur noch die Anweisungen eintragen mu welche die Dynamik seines Modells repr sentieren Alle brigen Dienste werden von einer Sammlung von Unterprogrammen bernommen Ins besondere wird
190. gt sensor_variable sensor_variable internal_variable indexed_component indexed_variable sensor_variable indexed_component indexed_variable indexed_component indexed_identifier indexed_variable indexed_identifier Transportverbindungen sind Zusammenschl sse von Best nden die dem Austausch von gleichartigen oder unterscheidbaren Elementen zwischen Komponenten dienen Ein Ausgangsbestand oder ein Zusammenschlu von Ausgangsbest nden darf mit einer einzigen ENTRY Location oder mit einer oder mehreren DENTRY bzw TRANSIT Locations verbunden sein Ein verteilbarer Eingangsbestand DENTRY oder ein Zusammenschlu von solchen darf mit einer oder mehreren EXIT bzw TRANSIT Locations verbunden sein Mehrere zusammengeschlossene Transit Locations definieren ebenfalls eine Transportverbin dung Im Grunde sind alle Verbindungen m glich Es ist nur darauf zu achten da Zusammenschl sse von EXIT oder DENTRY Locations nicht f r sich alleine stehen transport_connection_part TRANSPORT CONNECTION S transport_connection transport_connection exit_fusion gt entry_location exit_fusion gt dentry_fusion exit_fusion gt transit_fusion exit_fusion gt transit_fusion gt dentry_fusion transit_fusion gt dentry_fusion transit_location lt gt
191. h oder nur u erst umst ndlich und aufwendig zu formulieren Deshalb werden wir f r die Selektion von Elementen einen ganz anderen Weg beschreiten Wir schaffen uns sprachliche Mittel mit deren Hilfe wir eine Menge ordnen und den Zugriff auf Elemente geordneter Mengen formulieren k nnen Dadurch wird das Positionsattribut berfl ssig und auch das Einreihen in eine Warteschlange ist nicht mehr erforderlich 3 5 3 Einf hrung geordneter Mengen Die Ordnung einer Menge bzw Indexmenge wird hergestellt indem nach monoton aufstei genden oder abfallenden Werten einer Funktion geordnet wird ordered_property_set identifier IN index_range condition DMs criteria_list 722 criteria_list ordering_criterion ordering criterion ordering_criterion INC expression DEC expression TRUE expression FALSE expression Ein Ordnungskriterium enthalt einen numerischen oder logischen Ausdruck Ist der Ausdruck numerisch dann soll sein Wert mit jedem Element in der Warteschlange entweder zunehmen INC oder abnehmen DEC Ist der Ausdruck logisch dann werden die Elemente mit denjenigen Indices vorangestellt bei denen der Ausdruck den angegebenen logischen Wert annimmt Der Ausdruck des Ordnungskriteriums mu selbstverstendlich den variierten Index beinhal ten Sollen durch das Kriterium Elemente eines Warteraums geordnet werden dann wird der Ausdruck in der Regel ein Attribut dieser Elemente enthalten
192. h die relativen Aussagen CHANGE B_1 CHANGE B_2 T_12 CHANGE B_2 T_23 CHANGE B_3 T_12 T_12 Je zwei dieser Aussagen beschreiben einen Transport Dadurch wird eine starke hnlichkeit zur transportbezogenen Beschreibung hergestellt Allgemein betrachtet wird die Wertzuweiung B_j Bj T1j T2j Tnj T ji T2 Tjn dabei ersetzt durch die Aussagen CHANGE B_j T_1j CHANGE B_j T_ji CHANGE B_j T_2j CHANGE B_j T_j2 CHANGE B_j T_nj CHANGE B_j T_jn zufliessende Elemente abfliessende Elemente 148 4 Transporte zwischen Best nden Die Summenbildung wird implizit ber alle CHANGE Anweisungen ausgef hrt die den glei chen Bestand betreffen B_j B_j SUM CHANGE B_j Bei Einf hrung dieses Konstrukts kann auf die explizite Berechnung der Transportmenge verzichtet werden und die Modellbechreibung gewinnt sogar etwas an Ubersicht Beispiel CHANGE B_1 n_12 WHEN cond_12 END CHANGE B_2 n_12 WHEN cond_12 END CHANGE B_2 n_23 WHEN cond_23 END CHANGE B_3 n_23 WHEN cond_23 END Zum Vergleich sei abschlie end auch die quivalente transportbezogene Beschreibung ange geben Beispiel B_1 gt B_2 n_12 WHEN cond_12 END B_2 gt B_3 n_23 WHEN cond_13 END Inwieweit durch die unterschiedlichen Beschreibungsformen die Eindeutigkeit sichergestellt ist wird im n chsten Abschnitt behandelt 4 4 Diskussion der Eindeutigkeit am Problem der Verteilung
193. he 5 3 1 Zugriff auf Modellvariablen Modellvariablen gliedern sich in Attribute und Best nde Zugriffe auf Attribute selected_attribute und Zugriffe auf Best nde selected_location werden aber in gleicher Weise formuliert Variablen selected_variables welche auf einer mobilen Kom ponente plaziert sind sind durch einen zweistufigen Selektionspfad ber Bestand und mobiles Element zu erreichen selected_attribute selected_variable selected_location selected_variable selected_variable variable_path identifier variable_path variable_path variable element variable element identifier index variable identifier index_list index_list index index index index_expression Da jede Aussage in einen Allquantor eingebettet sein kann kann der Zugriffspfad auf Va riablen mobiler Komponenten sowohl mit einer Location als auch mit einem Bezeichner fiir eine gebundene Variablen beginnen die fiir eine mobile Komponente steht Zugriffe auf einzelne mobile Elemente erfolgen ber den gleichen Zugriffspfad der dann aber mit einem Element endet selected_element selected_variable element identifier Ein ungel stes Problem ist die Indexpr fung zur Compile Zeit Da dem bersetzer nicht bekannt ist ob und wieviele Elemente in der Warteschlange enthalten sind werden Zugriffe auf nicht existierende mobile Elemente erst w hrend des Programmlaufs festgestellt
194. he First European Simulation Congress 1983 Springer Berlin 1983 pp 251 260 Kettenis D L The COSMOS Simulation Environment in Huntsinger R C SCS International Hrsg Simulation Environments Proceedings of the ESM Nice 1988 Literaturverzeichnis 259 K Ma 72 Lang 89 MarLed 87 May 89 ren 84 OrZi 79 Page 88 Ped 86 Pich 75 Prit 74 PriPed 79 K cher D Matt G Oertel C Schneewei H Einf hrung in die Simulationstechnik Hrsg Deutsche Gesellschaft f r Operations Research DGOR Beuth Vertrieb Berlin 1972 Langer Klaus J rgen Entwurf und Implementierung eines Simulationssystems mit integrierter Modellbank und Experimentdatenverwaltung Arbeitsberichte des Instituts f r Mathematische Maschinen und Datenverarbeitung der Universit t Erlangen N rnberg Dissertation Band 22 Nummer 17 Erlangen 1989 Marcotty M Ledgard H The World of Programming Languages Springer Verlag Berlin 1987 Mayer Klaus Peter Modellierung der Schadstoffeinwirkung auf das Okosystem Wald Studienarbeit am IMMD4 der Universit t Erlangen 1989 ren Tuncer I GEST A Modelling and Simulation Languages Based on System Theoretic Concepts in ren T I Hrsg Simulation and Model Based Methodologies An Integrative View NATO ASI Series vol F10 pp 281 334 Springer Verlag Berlin 1984 ren T Ziegler B Concepts for Advanced Simulation Methodolo
195. hen aus der dritten Gruppe f llt auf da sie h ufig von Systemprogrammen Gebrauch machen Hierzu ist es erforderlich eine Schnittstelle zur Basissprache zu schaffen Die folgenden Abschnitte deuten an wie diesen W nschen der Anwender Rechnung getra gen werden kann Es soll damit das Sprachkonzept abgerundet werden so da keine Ein schr nkungen an den praktischen Einsatz gemacht werden m ssen Von besonderer Bedeutung hierf r ist die Ausgestaltung einer Unterprogramm Schnittstelle Diese erm glicht es dem Anwender sowohl Funktionen und Prozeduren zu schreiben die vom Compiler der Modellbeschreibungssprache bearbeitet werden als auch Unterprogram me in der Implementierungssprache C einzubinden Im ersten Fall braucht der Anwender die Sprachumgebung nicht verlassen und bekommt vom Compiler eine umfangreiche Schnittstel lenpr fung geboten Im zweiten Fall hat der Anwender die M glichkeit Systemprogramme aufzurufen oder sich Schnittstellen zu anderen Programmen und Datenbest nden einzurich ten Gleichzeitig verhindert die Unterprogramm Schnittstelle da die Modellbeschreibungsspra che durch immer neue Konstruktionen erweitert werden mu Bei Anforderungen die ber die Funktionalit t der Sprache hinausgehen kann sich der Anwender selber weiterhelfen 6 2 Aufz hlungsmengen 215 Die folgenden Beschreibungen sollen nur einen berblick vermitteln und so viel Verst ndnis schaffen wie es f r die im Anschlu folgenden Anwend
196. her Zeitmenge wir arbeiten wollen wir den Folgezustand z tk 1 abk rzend auch mit 2 und den Folgezeitpunkt t abk rzend mit t bezeichnen Den aktuellen Modellzustand der auch die Belegungen der Sensorvariablen und der abh ngi gen Variablen sowie die aktuelle Zeit enth lt k rzen wir mit W t ab und bezeichnen ihn als erweiterten Modellzustand 2 3 Spezielle Zustandstiberftihrungsfunktionen 37 Legt man f r die Zeitmenge die Menge der nichtnegativen ganzen Zahlen zugrunde d h T No dann erh lt man die Darstellung der Automatentheorie zt 1 f W t Automatentheoretische Modelle k nnen keine Aussage dar ber machen zu welchem realen Zeitpunkt Systemzeit ein bestimmter Zustand angenommen wird Lediglich die Reihenfolge der Zustands nderungen d h der funktionelle Ablauf kann anhand eines solchen Modells studiert werden Eine spezielle Darstellungsform f r endliche Automaten sind die Petri Netze Eine einfache Beschreibungsform f r diskrete Modelle bei der auch ein Bezug zur Systemzeit hergestellt wird ergibt sich wenn man f r die Zeitmenge das Vielfache einer Zeiteinheit At E R mit At gt 0 w hlt zi t At f WE Nehmen dabei die ZUF die spezielle Form z t At z t At r w an dann erh lt man eine Modellbeschreibung mit Differenzengleichungen Eine geeignete Notation z B DELTA At z r W t kann daf r Sorge tragen da nicht die gesamte ZUF sondern nur die nderungsraten r
197. hose named above Erlangen February 1995 P Eschenbacher Pr face Ce livre a t soumis afin d obtenir le certificat d ing nieur pour une chaire de systemes op rationnels IMMD4 de l Universit de Erlangen a Nurembourg Ce livre traite des consid rations relatives au langage de mod lisation SIMPLEX MDL Ce langage fait partie du systeme de simulation SIMPLEX II dont le d veloppement a t soutenu dans le cadre du projet de recherche PAP projet relatif aux systemes de productions flexibles automatis s durant les ann es 1985 1992 chez Siemens Le but de ce projet tait de construire un environnement de travail qui facilite la simulation de syst mes de production en phase de conception Si possible un concepteur non sp cialiste devrait etre en mesure de faire la simulation sans aucune aide ext rieure Le logiciel pr sent au d but du projet exigeait d importants efforts de programmation des modeles ce qui n cessitait du personnel sp cialis A Vheure actuelle cette situation s est am lior e grace l utilisation d interfaces graphiques facilitant le d veloppement des mod les et l utilisation de parties pr d finies Cependant quand un nouveau probleme se pr sente les parties existantes ne sont pas suffisantes De nouveaux mod les devraient tre programm s et int gr s dans le systeme graphique Dans certains cas les d penses pour l etude de la simulation se montrent encore plus lev e
198. hse beschreiben Eine weitere Voraussetzung hierf r ist da nach endlich vielen Zwischenzust nden kein wei teres Ereignis mehr stattfindet d h die vereinigte Ausl semenge von allen Zustandsvariablen A A wieder verlassen wird Erst dann wird wieder ein realer Zeitfortschritt m glich Nach einem realen Zeitfortschritt bleiben die Werte s mtlicher diskreter Zustandsvariablen konstant bis eine Zeitbedingung daf r sorgt da wieder ein neues Ereignis stattfindet d h eine Zustandsvariable ihren Wert sprunghaft ndert Beispiel Anfangsbelegung z 0 0 t_0 0 DT 1 Ereignis z t falls t gt z DT Der Zeitverlauf von z w chst alle DT Zeiteinheiten um DT Durch die Ausf hrung des Ereignis wird die Ausl sebedingung unwahr Erst wenn die Zeit den Wert z DT erreicht wird wieder ein Ereignis ausgef hrt 2 3 Spezielle Zustandstiberftihrungsfunktionen 39 Um diskrete Zeitverl ufe ber einer reellen Modellzeit auch implementierungstechnisch kor rekt zu behandeln empfiehlt es sich eine zweidimensionale Implementierungszeit einzuf hren Wie bereits in Esch 90 ausf hrlich beschrieben setzt sich ein Zeitpunkt aus zwei Kompo nenten der realen Zeit T und dem Moment M fr her Takt zusammen Der Bezug zur Modellzeit wird durch die Beziehung t T M d mit T n R und MEN hergestellt Dabei ist T das Vielfache eines vorgegebenen Aufl sungsverm gens R Gleitkommazahl und M ist ein Z hler der angibt wiev
199. ht wie erhofft eine modulare Modellzerle gung gestatten Aus diesem Grunde mu te die theoretische und methodologische Grundlage f r die Beschreibung und Simulation von Warteschlangenmodellen erst durch eine sinnvolle Erg nzung des systemtheoretischen Paradigmas geschaffen werden Auch zeigte sich da die zustandsorientierte Sichtweise der Systemtheorie mit den Modellie rungsans tzen der herk mmlichen und prozedural orientierten Simulationssprachen keinerlei Gemeinsamkeit oder hnlichkeit aufwies Im Laufe der Zeit wurde immer deutlicher da die angestrebte Sprache deklarativen Charakter besitzt und damit eine ganz andere Denkweise voraussetzt als man es von prozeduralen Sprachen gewohnt ist ii In meiner Dissertation Esch 90 wurde zun chst untersucht wie sich die Beschreibung von kontinuierlichen und von diskreten Vorg ngen miteinander in Einklang bringen l t In dieser Arbeit werden nun diejenigen Erweiterungen des Sprachkonzepts beschrieben die eine For mulierung von Warteschlangen und Transportmodellen m glich machen Eine Kenntnis der Dissertation ist dazu nicht vonn ten da alle f r das Verst ndnis erforderliche Grundlagen auch in dieser Abhandlung enthalten sind Im Mittelpunkt der Ausf hrungen stehen die Eigenarten der deklarativen Beschreibungs form Die deklarative Beschreibung verlangt nach Vollst ndigkeit und Widerspruchsfreiheit Diese beiden Kriterien deren Einhaltung nach M glichkeit bereits vom Compiler
200. hvollziehbar F r die Programmierung des Modells und auch f r das Verst ndnis des Modellablaufs ist die Kenntnis der Ablaufsteue rung allerdings notwendig Simulationspakete bilden auch die Grundlage f r datengesteuerte Simulatoren und Simulationssprachen Datengesteuerte Baustein Simulatoren Beschr nkt man sich auf ein sehr enges Anwendungsgebiet kann man in vielen F llen Simula tionsprogramme so gestalten da die Konfiguration des Modells in Form von tabellarischen Daten beschrieben werden kann Ohne da eine erneute bersetzung erforderlich w re kann ein Modell erstellt und ver ndert werden Diese Vorgehensweise setzt voraus da das Mo dell aus genau spezifizierten Modellbausteinen aufgebaut werden kann die miteinander ber vordefinierte Kan le kommunizieren 10 1 Einleitung Als Beispiele fiir derartige Modellwelten lassen sich anfiihren Warteschlangennetze bestehend aus Quellen Senken Bedieneinheiten mit Warteschlan gen und Verzweigungen Petrinetze bestehend aus Stellen und Transitionen Neuronale Netze Elektrische Schaltkreise bestehend aus Quellen Widerst nden Kapazit ten Indukti vit ten etc Zus tzlich k nnen f r jeden Modellbaustein eine Vielzahl von Parametern angegeben werden Auch unterschiedliche Strategien sind ber Parameter anw hlbar Im Sinne der Graphentheorie lassen sich die Bausteinen als Knoten und die Kommuni kationskan le als Kanten ansehen Hieraus wird unmit
201. i der Ent wicklung und Anwendung des Simulationssystems SIMPLEX II gesammelt werden konnten Wir beschr nken uns in den Ausf hrungen hier allerdings auf den Bereich der Modellerstel lung Ziel ist es einerseits Modellvorstellungen formal beschreiben zu k nnen andererseits aus dieser formalen Beschreibung durch einen Compiler ein Simulationsprogramm generieren konstruieren zu lassen 1 2 Aufgaben eines Simulationsprogramms 3 reales fiktives System Modellbildung Systemanalyse Modellvorstellung Modellerstellung Aufbau Konstruktion Simulationsprogramm Experimentieren Simulationsergebnisse Aufbereiten Visualisieren Ergebnisdarstellung Abb 1 1 1 Aufgabenfelder der Simulationstechnik 1 2 Aufgaben eines Simulationsprogramms Jedes Simulationsprogramm besteht aus dem Code der das Modell simuliert und dem Code der die Programmschnittstellen herstellt Ein Simulationsprogramm kann zu unterschiedlichen Zwecken eingesetzt werden Die Schnitt stellen zur Umgebung welche die Einsatzm glichkeiten eines Programms bestimmen sind jedoch in ihrer Funktionalit t stets gleich Man setzt Simulationsprogramme e zur Durchf hrung von Simulationsstudien oder e zu bungs und Trainingszwecken ein Bei der Durchf hrung von Simulationsstudien will man Erkenntnisse ber das modellierte System gewinnen Hierzu f hrt man eine Vielzahl einzelner Simulation
202. iablen Mengen Quantit ten Einer Eigenschaftsvariablen ist zu jedem Zeitpunkt genau ein Wert aus einer der Wertemenge zugeordnet Dabei kann es sich um numerische Wertemengen INT REAL handeln die evtl durch eine physikalische Ma einheit erg nzt werden aber auch logische Werte oder Werte aus benutzerdefinierten Aufz hlungsmengen kommen in Betracht Einer Bestandsvariablen ist bei gleichartigen Elementen eine Anzahl und bei unterscheidba ren mobilen Elementen eine Menge zugeordnet Bestandsvariablen repr sentieren Inhalte nicht berlappender Raumgebiete Daher sind ihre Mengen disjunkt d h jedes mobile Ele ment ist genau einem Bestand zugeordnet Mobile Elemente werden wegen zahlreicher Verwandtschaften den Komponenten zugerechnet 5 1 Grundlegende Konzepte der Sprache 191 Eine Komponente fa t Modellvariablen und Beziehungen zwischen Modellvariablen so zu sammen da sie ein vollst ndiges Modell bilden Komponenten unterscheiden wir in die Typen e Mobile Komponenten e Basiskomponenten und e H here Komponenten model_component mobile_component basic_component high_level_component Jede vereinbarte Komponente bildet eine Klasse und kann unter einem eigenen Namen bzw eigenem Index mehrfach in einem Modell zum Einsatz kommen Die Auspr gungen einer Klasse besitzen zwar prinzipiell das gleiche dynamische Verhalten die aktuelle Belegung der Modellvariablen ist jedoch in der Regel verschieden Eine m
203. ichen Konzepten zu bereichern Da sich die Anforderungen der Fertigungstechnik mit den herk mmlichen Simulationssprachen ohnehin nicht abdecken lie en bot sich die Gelegenheit bei der Konzeption einer neuen Sprache beide Zielsetzungen gemeinsam zu verfolgen und damit eine Synthese praktischer Notwendigkeiten mit theoretischen berlegungen zu versuchen In dieser Einleitung wird zun chst die Thematik dieser Abhandlung aus dem brigen Be reich der Simulationstechnik ausgegrenzt Daraufhin wird gezeigt welche Aufgaben ein Si mulationsprogramm im allgemeinen zu erf llen hat und mit welchen Arten von Werkzeugen Simulationsprogramme erstellt werden k nnen In Abgrenzung von den traditionellen Simu lationssprachen werden die grundlegenden Gesichtspunkte einer Modellbeschreibungssprache herausgestellt und damit der hier eingeschlagene Weg umrissen Schlie lich wird am Beispiel der Fertigungstechnik erl utert welche Anforderungen an die Simulationstechnik und insbesondere an Werkzeuge zur Modellerstellung heute gestellt wer den Unterschiedliche Ans tze diese Anforderungen zu erf llen werden diskutiert Im zweiten Kapitel wird die systemtheoretische Modelldarstellung als neues Programmier modell grundgelegt und die elementaren Sprachkonstrukte einer Modellbeschreibungssprache eingef hrt Das dritte Kapitel er rtert die Probleme dieses Paradigmas bei der Modellierung von Warteschlangen und Transportmodellen und versucht diese durch Erg n
204. ider nur als Durchgangsbestand und nicht als Eingangsbestand deklariert werden 242 7 Anwendungen 7 5 Die Modellkomponente Transportband Die Modellkomponente Transportband ist Teil der Modellbank Fertig ApEsWi 92 in der Komponenten zur Modellierung von Fertigungslinien zusammengestellt sind Die Werkstiicke sind mobile Elemente welche die Anlage durchlaufen Neben der gezeigten Komponente enthalt diese Bank Komponenten fiir Quellen und Senken Bearbeitungssta tionen Priifstationen Bander als Pufferstrecken oder Sammelstrecken sowie Verteiler und Zusammenf hrungen Min_Abst a nn Die Werkst cke Teile werden prinzipiell von der nachfolgenden Komponente geholt Es gilt die Vereinbarung da ein Teil immer dann geholt werden darf wenn es auf einem bergabeplatz liegt Durch das Holen der Teile im Gegensatz zum Bringen gelangen nie mehr Werkst cke in eine Komponente als darin Platz finden Die Komponente Transportband ist ein Beispiel daf r da Vorg nge in Warteschlangenmo dellen kombiniert diskret kontinuierlich beschrieben werden k nnen In F llen wie diesem f hrt dies zu einer deutlich einfacheren Modellbeschreibung Beschreibung der Modellkomponente Transportband Das Band bleibt stehen wenn das vorderste Teil das Ende des Bandes erreicht hat und nicht vom Band genommen wird Der Abstand der Teile auf dem Band bleibt daher erhalten Da die Teile eine gewisse Gr e besitzen halten sie auf dem Band eine
205. ie dahinterliegenden Elemente um eine Position nach hinten verschoben werden Im Beispiel ist dies nicht erforderlich da nur ein Element im Server Platz findet Bei der Entnahme eines Elements aus einer Menge r cken diejenigen Elemente die hinter dem entnommenen Element eingereiht waren um eine Position nach vorne Dieses Verfahren f r jedes Element eine Position festzulegen ist nicht nur umst ndlich Wie die folgenden Beispiele deutlich werden lassen ist das Hinzuf gen und Entnehmen von Elementen in etwas schwierigeren aber immer noch typischen F llen nicht formulierbar Beispiel f r eine Entnahme aus einer Warteschlange Bei Eintritt eines bestimmten Ereignisses sollen die zwei l ngsten Elemente Attribut Laenge die kleiner oder gleich einer gegebenen maximalen L nge LMax sind aus der Warteschlange entnommen und an einen anderen Ort gebracht werden Falls zwei Elemente gleich lang sind soll dasjenige ausgew hlt werden das die Warteschlange zuerst betreten hat 3 5 Einf hrung von Indexmengen 103 Beispiel fiir das Einreihen in eine Warteschlange Q Ankommende Elemente sind in der Warteschlange ihrer L nge nach zu ordnen die langsten Elemente vorne die kiirzesten hinten Sind zwei Elemente gleich lang wird das neu ankommende hinten angestellt Der Versuch Problemstellungen dieser Art zu modellieren zeigt Das Festlegen des Positi onsattributs ist mit den bisherigen Mitteln entweder berhaupt nicht m glic
206. ie bei der Beschreibung konti nuierlicher Modelle seit langem blich ist Dies geschieht in der Erwartung auf diese Weise eine Sprache definieren zu k nnen die elementar genug ist um alle Arten von dynamischen Vorg ngen beschreiben zu k nnen Auf diese Weise wird zwischen Modellvorstellung und prozeduralem Simulationsprogramm eine weitere Sprachschicht eingezogen die das dynamische Modell vollst ndig formal be schreibt Die nicht formale und mehr oder weniger mathematisierte Modellvorstellung wird da durch konkretisiert und formalisiert Aus dieser Modellbeschreibung l t sich schlie lich das Simulationsprogramm durch einen Compiler automatisch generieren Um dem Begriff Modellbeschreibungssprache gerecht zu werden m ssen vor allem vier Ziel setzungen erreicht werden e Die formale Beschreibung eines Modells mu der gedanklichen Vorstellung bzw ei ner bereits vorliegenden mathematischen Beschreibung m glichst nahe kommen Die Notation mu gut lesbar sein Dazu mu sie ausf hrlich darf aber nicht ausschweifend sein 1 4 Ansatz f r ein neues Sprachkonzept 13 e Die Reihenfolge von Abl ufen mu man der Modellbeschreibung selbst entnehmen k nnen Kenntnisse ber die Arbeitsweise der Ablaufsteuerung d rfen nicht vonn ten sein e Die Modellbeschreibung darf keine Information enthalten die f r die Ein Ausgabe und die Bedienung des Simulationsprogramms dienlich ist Diese Aufgaben sind durch datengesteuerte
207. iele infinitesimal kleine Zeitinkremente verstrichen sind d h wieviele Ereignisse zur realen Zeit T bereits ausgef hrt wurden Da die Zeit als Zahlenpaar T M gef hrt wird kann dem neuen Zustand nach einem Ereignis eine eindeutige Zeitangabe zugeordnet werden Wir haben damit drei Zeitbegriffe kennengelernt die Systemzeit welche durch das Aufl sungsverm gen der Uhren festgelegt ist die Modellzeit welche die modellhafte Zeitvorstellung des Anwenders wiedergibt die Implementierungszeit welche eine Ann herung an die Modellzeit wiedergibt Bei Verwendung einer reellen Modellzeit lassen sich auch kontinuierliche Zustands berg nge formulieren welche durch die spezielle ZUF z t dt z t fi W t dt beschrieben werden Die besondere Notation f r diesen Fall beschr nkt sich auf die Angabe der Ableitung also auf die Differentialgleichung Differentialgleichungen erm glichen die Beschreibung stetiger Funktionsverl ufe und sind nur auf reelle Modellvariablen anwendbar Um auch stetige Funktionsverl ufe mit Sprungstellen beschreiben zu k nnen ist die Einf hrung einer kombinierten ZUF erforderlich Wie bereits in Esch 90 beschrieben l t sich eine kombinierte ZUF so definieren da reelle Modellvariablen sowohl durch Ereignisse als auch durch Differentialgleichngen beschrieben werden k nnen z_i f_i W t f_i W t Der Verlauf von reellen Zustandsgr en mit reeller Zeitmenge wird d
208. ige Triggerung ist eine geeignete Schnittstelle vorzusehen Experiment Beobachter Anfangszustand Steuerparameter Definitionen Vorbereitung Triggerung N we Durchfiihrung Einfl sse Wirkungen Simulations f der gt m Umgebung programini Umgebung Endezustand Ablaufstatistik Aufzeichnungen Ablaufprotokoll der Beobachter Nachbereitung Abb 1 2 1 Schnittstellen eines Simulationsprogramms Wichtig ist es festzuhalten da alle Simulationsprogramme mit den gleichen Schnittstellen auskommen und diese Schnittstellen in gleicher Weise codiert sein k nnen da sie Symbolin formationen nur auf Datei ben tigen Dadurch braucht der Verwendungszweck eines Modells nicht bereits bei seiner Erstellung festgelegt werden und eine automatische Codegenerierung braucht keinen Code f r die Schnittstellen liefern Lediglich der Code der das Modell simuliert ist individuell zu erzeugen Auch dieser Code l t sich wiederum in einen gleichbleibenden und einen individuellen Code trennen Der indi viduelle Code repr sentiert das spezifische Modellverhalten der gleichbleibene Code steuert die Ausf hrungsreihenfolge des modellspezifischen Codes siehe hierzu Kapitel 2 L t sich der Code in dieser Weise trennen dann zerf llt ein Simulationsprogramm in drei Teile e Repr sentation des spezifischen Modellverhaltens e Steuerung der Ausf hrungsreihenfolge Ablaufsteuerung e komfortable Ein Ausgabeschnittstellen 6 1 E
209. immten Warteschlange Da f r den Benutzer der Aufenthaltsort als Attribut einer mobilen Komponente nicht mehr sichtbar ist enthalten die Mengenvaria blen Locations die Information ber den Modellzustand Daher stellen sich die getroffenen Ma nahmen f r den Benutzer folgenderma en dar e Wir f hren Zustandsvariablen mit Wertemenge SET OF mobile_element ein und erm glichen bei deren Deklaration die Angabe von Ordnungskriterien bzw Einord nungskriterien Diese Mengenvariablen stehen f r m gliche Aufenthaltsorte einer mo bilen Komponente werden daher als Locations bezeichnet und k nnen vom Benutzer deklariert werden Beispiel STATE VARIABLE Queuel SET OF Job DEC Priority INC TEntry 3 Job Locations k nnen mit einer bestimmten Anzahl von mobilen Komponenten vorbelegt werden Aus den Vorbelegungen aller Aufenthaltsorte ergibt sich die gesamte Menge an mobilen Elementen im Modell 122 3 Spracherweiterungen zur Formulierung von Warteschlangenmodellen e Zugriffe auf mobile Komponenten sind ber ihren Aufenthaltsort m glich Der Aufent haltsort setzt sich aus der Location und der Position auf der Location zusammen Beispiele Queue Job 1 erster Job auf Queue Queue Job 1 5 Menge mit den ersten f nf Jobs auf Queue soweit vorhanden e Ein Wechsel des Aufenthaltsortes wird durch einen speziellen Transportoperator gt vorgenommen Beispiel Queue1 Job 1 gt Queue2 Die mobile Komponente Job 1 a
210. ind hier nur der Vollst ndigkeit halber mit aufgef hrt und werden in Kapitel 6 kurz abgehandelt Auf die Einf hrung von abh ngigen Mengenvariablen die abh ngigen Eigenschaftsvariablen entsprechen wurde bewu t verzichtet An dieser Stelle gibt es viele methodologische Pro bleme und ein praktischer Nutzen ist nicht erkennbar Vor allem gibt es kein Unterscheidungsmerkmal zwischen einer abh ngigen Eigenschafts variablen und einer abh ngigen Mengenvariablen wenn es sich um gleichartige Elemente handelt die nur durch eine Anzahl ausgedr ckt werden 5 3 Beschreibung der Modelldynamik in Basiskompo nenten Die Modelldynamik wird durch eine Folge von Aussageformen beschrieben Der zeitliche Ver lauf von Attributen wird durch Wertzuweisungen der Verlauf von Best nden durch Trans portanweisungen festgelegt Beide Arten von Aussagen k nnen auch als bedingte Aussage oder als verallgemeinerte Aus sage formuliert werden Hierzu sind sie in ein IF bzw in ein FOREACH Statement einzu betten dynamic_behaviour DYNAMIC BEHAVIOUR statement_sequence statement_sequence statement statement statement assignment transport conditional_statement foreach_statement Da der Zugriff auf Modellvariablen und die Bildung von Ausdr cken Teile aller Aussagefor men und daher f r das Verst ndnis unentbehrlich sind seien zwei entsprechene Abschnitte vorangestellt 198 5 Systematische Darstellung der Modellbeschreibungssprac
211. ines Programms findet die Vereinbarung eines Bezeichners und die Festlegung der Eigen schaften Da zur Definition des dynamischen Verhaltens einer Variablen auf andere Modellvariablen zur ckgegriffen werden mu und bei der Angabe der Eigenschaften von Variablen auch durch den Benutzer definierte Eigenschaften angegeben werden k nnen bietet es sich an die Beschreibung der Variablen auf drei Teile zu verteilen 1 Einf hrung von Eigenschaften durch den Benutzer 2 Bezeichner und Eigenschaften der Modellvariablen 3 Dynamisches Verhalten der Modellvariablen 2 4 Grundkonstruktionen des Sprachkonzepts 47 Da die Sprache einem bestimmten Zweck dient der Modellbeschreibung lassen sich fiir die Modellvariablen neben der Wertemenge eine Anzahl weiterer Eigenschaften angeben Diese Eigenschaften erm glichen eine eingehende Pr fung der Dynamikbeschreibung auf semantische Korrektheit a Verwendung Der Verlauf einer Zustandsvariablen darf nur durch eine Zustands berf hrungsfunk tion definiert sein bei reeller Modellzeit demnach durch ein Ereignis oder eine Diffe rentialgleichung Der Verlauf einer abh ngigen Variablen mu durch eine algebraische Gleichung definiert werden Der Verlauf von Sensorvariablen darf f r den Fall da sie nicht mit einer anderen Variablen verbunden ist durch eine algebraische Gleichung definiert werden die aber als einzige Variable lediglich die Zeit enthalten darf Wertemenge Bei der Bildung von
212. ingen wahr und r umt es ggf auch weiteren Best nden ein Um keine Zugriffskonflikte zu provozieren verzichtet er auf das Recht zu Schreiben r umt aber fremden Komponenten das Schreibrecht in gleicher Anzahl wie das Holerecht ein Ein Eingangsbestand ist ein Bestand der auf das Recht zu Bringen verzichtet und es daf r einem oder mehreren anderen Best nden zugesteht Gleichzeitig nimmt er das Recht zu Holen wahr und r umt es ggf auch weiteren Best nden ein Er verzichtet nicht auf das Schreibrecht und r umt auch anderen Komponenten das Schreibrecht in gleicher Anzahl wie das Holerecht ein Mit einer derartigen Verteilung der Rechte kann man sich einen Bestand auch in einen Ausgangs und einen Eingangsbestand zerlegt vorstellen SER aa SH ENTRY 172 4 Transporte zwischen Best nden Speziellere F lle von Transporten liegen vor wenn der Bestand nur zum Sammeln oder nur zum Verteilen bestimmt ist Von bertragung sprechen wir wenn nur ein einziger Absender und nur ein einziger Adressat zul ssig ist Sammeln mehrere eine Komponen Komponenten Be e te die bringen ae die holt Verteilen eine mehrere Komponente a Komponenten die bringt TSS die holen bertragen eine eine Komponente gt Komponente die bringt die holt Je nach Verwendungszweck erscheint es sinnvoll durch gezieltes Einr umen von Rechten nur die eine oder andere Konfiguration zu erlauben Wir unterscheiden daher die
213. inleitung Von diesen drei Teilen sollte sich der Anwender nach M glichkeit nur mit der Repr senta tion des Modells besch ftigen m ssen Die beiden anderen Aufgaben sollten ihm durch den Einsatz geeigneter Software Werkzeuge vollst ndig abgenommen werden In einem prozeduralen Simulationsprogramm l t sich jedoch das Modellverhalten nicht oh ne Kenntnis der Ablaufsteuerung und ohne Kenntnis der Datenstrukturen repr sentieren Es wird daher das Ziel sein eine formale Beschreibung f r das Modellverhalten zu finden die keine Kenntnis der Ablaufsteuerung ben tigt Hingegen ist die Repr sentation des Mo dellverhaltens von den Schnittstellen eines Simulationsprogramms unabh ngig und deshalb werden wir uns mit der Realisierung der Schnittstellen nicht weiter auseinandersetzen 1 3 Erstellung von Simulationsprogrammen In Page 88 werden die Programmiersprachen Modula 2 C und Ada sehr ausf hrlich auf ihre Eignung f r diskrete Simulationsprogramme untersucht Hierbei werden zwei prinzipiell verschiedene Implementierungskonzepte unterschieden ereignis orientierte Simulation proze orientierte Simulation W hrend ereignis orientierte Simulationsprogramme nur einen einzigen Programmflu ent halten und ber einen programmeigenen Scheduler zu den einzelnen Aktivit ten verzweigt wird beschreiben proze orientierte Simulationsprogramme parallele Abl ufe die sich ge genseitig aktivieren oder nach einer bestimmten Ruhezeit se
214. ion zum Verpacken Zugriff auf denjenigen Auftrag der als erster fertig wird z B Mehrfachbedienstation Zugriff auf bis zu drei Auftr ge mit h chster Priorit t die am l ngsten gewartet haben z B Zusammenstellung einer Fahrtroute Wir wollen nun Zug um Zug die f r die Formulierung von Warteschlangen und Transport modellen geforderte Funktionalit t herstellen und dazu neue Sprachkonstrukte einf hren 3 3 Einf hrung von Elementen mobilen Komponenten 87 3 3 Einf hrung von Elementen mobilen Komponenten In Warteschlangenmodellen bewegen sich Einheiten im folgenden Elemente genannt die sich durch eine Zusammenfassung von Attributen auszeichnen Um die Zusammengeh rig keit dieser Attribute deutlich werden zu lassen f hren wir das Element als Datenstruktur Verbund von Attributen ein Im Vorgriff auf die sp tere Verwendung bezeichnen wir Elemente auch als mobile Elemente oder mobile Komponenten mobile_component MOBILE COMPONENT identifier definition_part declaration_part END OF identifier Das Element ist wie eine Basiskomponente zu formulieren mit dem Unterschied da es keine eigene Dynamik besitzt Beispiel Die Elemente eines Warteschlangenmodells haben die Attribute Ort Pos Farbe und Laenge Das Attribut Ort bezeichnet die Warteschlange in der sich das Element gerade befindet das Attribut Pos die Stellung innerhalb der Warte schlange MOBILE COMPONENT Job DEFINITIONS VALUE SET Q
215. ionnel et non pas sur les simulations Au cours du temps le caract re du langage d sir apparaissait de plus en plus d claratif et ceci n cessitait une toute autre maniere de penser comme l utilisation de langages proc duraux Ma th se Esch 90 traite de ce probl me comment am liorer la description des processus continus et discrets I i les suppl ments de ce langage sont d crits ce qui rend la formulation des syst mes de transport et d attente possible La pr connaisance de la th se n est pas n cessaire parce que tout ce qui est n cessaire sera trait dans ce livre Au travers des explications le lecteur trouvera les particularit s de description des syst mes d une maniere d clarative La description d clarative pr tend tre compl te et sans contra diction Ces deux crit res qui devraient tre observ s et control s par un compilateur avec vi une d composition modulaire du modele Ceci determine considerablement la construction du modele Afin de maitriser les modeles complexes de r utiliser certaines parties des modeles et de travailler en quipe il est important de voir comment la d composition des modeles est effectu e sans perdre les modeles originaux N anmoins j indiquerai que cette pr tention se met en conflit avec d autres aspects l aspect definitif et autonome et pour cette raison une solution de compromis doit tre trouv e La notation synth tique du langage de
216. ird das Schl sselwort ARRAY und eine Dimensionierungsliste vorangestellt F r jede Dimension wird in geschweiften Klammern der Indexbereich Indexmenge angegeben Die Feldgrenzen sind durch konstante ganze Zahlen festzulegen Die Verwendung von Di mensionierungskonstanten ist ebenso erlaubt wie Operanden z B geklammerte Ausdr cke siehe Esch 90 die sich aus konstanten ganzen Zahlenwerte zusammensetzen und sich bereits zur Compile Zeit berechnen lassen Beispiele ARRAY 1 100 X ARRAY 1 10 1 5 Y ARRAY 5 5 X ARRAY 0 9 0 4 Y ARRAY 1 XDIM X ARRAY 1 XDIM 1 1 2 XDIM Y ARRAY XDIM 5 XDIM 5 XM 3 4 2 Verwendung von indizierten Variablen in Definitionsgleichungen Durch die Angabe eines konkreten Index l t sich jedes einzelne Feldelement auch von mobilen Komponenten ansprechen indexed_attribute indexed_identifier indexed_identifier indexed_identifier indexed_identifier identifier index_list index_list index index index index_expression index_expression expression Hinter dem Feldnamen steht die Indexliste fiir jede Dimension ein Indexausdruck in eckigen Klammern Beispiele X 2 Y 2 5 x 2 k 1 Y k 1 k Der Indexausdruck mu einen ganzzahligen Wert liefern der im Indexbereich der jeweiligen Dimension liegt 90 3 Spracherweiterungen zur Formulierung von Warteschlangenmodellen Die Werte von Feldelementen werden wie gehab
217. isse Menge an Wasser gesammelt hat Das Wasser auf dem Laub verdunstet nach und nach wieder Interzeption Das Wasser das auf den Boden f llt dringt relativ rasch in die oberste Bodenschicht AH Horizont ein Das Wasser in dieser humosen Bodenschicht wird zum Teil von den Wurzeln der B ume aufgenommen zum Teil verdunstet es wieder Evaporation und zum Teil ver sickert es in die n chst tiefere Bodenschicht B Horizont Das Wasser im B Horizont ist f r die Wurzeln nicht mehr erreichbar Allerdings findet ein kapillarer Aufstieg in den AH Horizont statt wenn der Boden dort trockener ist als im B Horizont Wasser das noch tiefer versickert wird im Modell nicht mehr ber cksichtigt Das Wasser das von den Wurzeln der B ume aufgenommen wird verdunstet nach und nach ber die Bl tter Transpiration Das Modell zeigt da durch die transportbezogene Beschreibung mit Bestandsgr en a eine dem Modell quivalente graphische Darstellung System Dynamics m glich ist und b eine formale Modellbeschreibung entsteht die einer informellen nat rlich sprachlichen Beschreibung unmittelbar entspricht Dar ber hinaus zeigt es da auch eine System Dynamics Darstellung auf einfache Art und Weise in Module zerlegt werden kann F r ein Zusammenwirken der beiden Komponen ten Wasser und Baum ist lediglich der Bestand FHumus als TRANSIT LOCATION bzw DENTRY LOCATION zu deklarieren 7 3 Das Modell Bodenfeuchte 233 CU Niede
218. isten anderen graphischen Modelldarstellungen geben nur Teilaspekte eines Modells wieder Wegen der methodologischen hnlichkeiten zu dem hier diskutierten Sprachkonzept soll an dieser Stelle eine kurze Einf hrung in System Dynamics gegeben werden Einf hrende Darstellung System Dynamics f hrt die folgenden Symbole ein Level Bestand Inhaltsgr e Ver nderungsrate von Best nden Rate Stromst rke Menge im Zeitschritt At 184 4 Transporte zwischen Best nden Constant O Konstante Auxiliary C mathematische Hilfsgr e Quelle Senke Material Str me zwischen Best nden 5 oder zwischen Quelle und Bestand oder zwischen Bestand und Senke Abh ngigkeiten Wirkungen Einfl sse amp von Bestand auf Hilfsgr e oder Anderungsrate von Hilfsgr e auf Anderungsrate Die Zustandsgr en werden stets als Best nde angesehen Die Best nde wirken auf Hilfs gr en ein Aus Hilfsgr en und Best nden k nnen weitere Hilfsgr en abgeleitet werden Schlie lich nehmen die Best nde und Hilfsgr en Einflu auf die nderungsraten der Best nde Die Wirkungen der Variablen aufeinander werden durch gestrichelte Pfeile dargestellt Die Ver nderung eines Bestandes hat einen Strom zur Folge der in einem anderen Bestand oder einer Senke m ndet und in einem anderen Bestand oder einer Quelle seinen Ursprung hat Die Str me werden als durchgezogene Linien dargestellt Ein kleines Beispiel sol
219. it aussi donner une impulsion au d veloppement de langages dans d autres disciplines informatiques Ce serait surtout valable dans les techniques de contrle et les processus d automatisation Ce livre ne serait certainement pas paru sous cette forme sans la contribution de deux de mes coll gues Jochen Wittmann et Thomas Apsel Aussi je les en remercie infiniment Je remercie aussi le Professeur B Schmidt qui a d bute ce travail et le professeur F Hofmann qui m a prodigu de pr cieux conseils et les professeurs H Wedekind et W Ameling qui ont effectu l valuation de ce livre en coop ration avec les susmentionn s Erlangen F vrier 1995 P Eschenbacher Inhaltsverzeichnis 1 Einleitung 1 1 Aufgabenfelder der Simulationstechnik 1 2 Aufgaben eines Simulationsprogramms 2 2 2 2 2 e 1 3 Erstellung von Simulationsprogrammen 2 2 2 En nn nn 1 4 Ansatz f r ein neues Sprachkonzept 2 2 2 n 2 nn nennen 1 5 Neue Anforderungen an die Simulationstechnik am Beispiel der Fertigungs technik rs a ae ee ee De be eck a a 1 5 1 Anforderungen an die Funktionalit t 1 5 2 Anforderungen an die Ergonomie 4 1 5 3 Diskussion der L sungsans tze 22 CE nn nn Sprachentwurf im Sinne der klassischen Systemtheorie 2 1 Systemtheoretische Modellbeschreibung 24 2 1 1 Die zustands orientierte Sichtweise 2 2 2222 nano 2 1 2 Aufstellen der
220. it jedem Zeitpunkt s mtliche Zustandsvariablen Hier wird die Einf hrung von Mar ken nat rlich gar keine Wirkung zeigen Nur bei geschalteten kontinuierlichen Vorg ngen l t sich eine Verbesserung der Effizienz erwarten In einem diskreten Modell allerdings ndern sich zu einem Zeitpunkt stets nur sehr wenige Zustandsvariablen Dementsprechend m ssen auch nur wenige Gr en weiterverfolgt werden Das vorgestellte Verfahren erweist sich hier um so wirkungsvoller je gr er das gesamte Modell ist Der Algorithmus erscheint so effizient da vermutet werden kann da sich auch durch Parallelisierung keine nennenswerte Verk rzung der Rechenzeiten erreichen l t Die bisher allesamt erfolglosen Versuche diskrete Modelle auf Parallelrechnern zu simulieren geben dieser Vermutung recht Im Kapitel ber Modularisierung wird untersucht ob und inwieweit sich diese effiziente Abarbeitung bei einer komponentenweisen Zerlegung des Modells aufrechterhalten l t Dort werden auch die beiden vorgestellten Verfahren zur Markierung nochmals diskutiert werden 58 2 Sprachentwurf im Sinne der klassischen Systemtheorie 2 6 Modularisierung 2 6 1 Anforderungen Die Modularisierung soll ganz allgemein gesehen ein Programm in abgegrenzte Einheiten berschaubarer Gr e zerlegen um es e besser handhabbar zu machen e gleichartiges Verhalten nicht mehrfach zu beschreiben Fiir ein Modularisierungskonzept d h ein Konzept das die
221. iterung der Sprache erkennt der Leser auch gleichzeitig die Intention mit der die neuen Konstrukte und Datentypen eingef hrt werden Das im vorangegangenen Kapitel dargestellte Grundkonzept und die berlegungen f r seine algorithmische Umsetzung gelten auch f r die vorzunehmenden Spracherweiterungen Besonderer Wert wird auch weiterhin darauf gelegt da die semantische Korrektheit vom Compiler berpr ft werden kann Dieser Gesichtpunkt ist deshalb so wichtig weil er die beim Sprachentwurf bestehenden Freiheiten sinnvoll einschr nkt Als wichtigste Anforderung berhaupt wird allerdings die Modularisierbarkeit von Warte schlangen und Transportmodellen angesehen 84 3 Spracherweiterungen zur Formulierung von Warteschlangenmodellen 3 1 Motivation Wir betrachten den folgenden typischen Ausschnitt aus einem Warteschlangensystem IN E Auftr ge vom Typ Job in einer Warteschlange Q warten auf ihre Bearbeitung in der Be dieneinheit S Sobald die Bedieneinheit frei ist darf der erste Auftrag aus der Warteschlange in die Bedieneinheit wechseln Die in der Warteschlange verbliebenen Auftr ge r cken dann um eine Position nach vorne In einem ersten Ansatz k nnte eine formale Beschreibung etwa folgenderma en aussehen MOBILE COMPONENT Job DEFINITIONS VALUE SET Queues Q1 92 037 DECLARATIONS STATE VARIABLES DISCRETE Ort Queues QL Pos INT 1 END OF Job ARRAY 1 N Job FOREACH i IN 1 N LE
222. itted for the certificate of habilitation at the chair for operating systems IMMD 4 at the university of Erlangen Nuremberg It deals with the theoretical considerations which underlie the model description language SIMPLEX MDL This language ist part of the simulation system SIMPLEX II the develop ment of which was sponsered by the Siemens company from 1985 1992 in connection with the research project PAP project for flexibly automated production systems It was the aim of this project to build a working environment which makes simulation of planned production systems much easier If possible the planner of the production system should be able to perform simulation studies without assistance The software available at the beginning of the project required great efforts to program these models and specially skilled personnel were needed Since that time many simulation programs have been developed to improve this situation which enable a model composition with pre defined components to be constructed with the aid of a graphical user interface However this has given rise to a new problem Often the existing components are not suf ficient and new modules must be programmed and integrated into the graphic system In certain cases the costs for a simulation study are even higher than before In spite of many simplifications concerning usage the necessity has remained to make it easier if possible for the user to describe models and
223. konstante ist D Der Diffusionsstrom Be stand Zeit ist dem Konzentrationsgef lle proportional Die Konzentration errechnet sich aus Bestand pro Volumen K1 K2 B D cH SC D B V A sc k E c A V Modellgleichungen in beiden Komponenten C B V Konzentration B D A SC C Aenderung des Bestandes Diskussion Die Kompaktheit der Beschreibung wird in erster Linie dadurch erzielt da keine Flu richtung unterschieden wird Transporte in Gegenrichtung werden einfach durch 4 5 Modularisierung 161 negative Zahlenwerte ausgedr ckt eine Verfahrensweise wie sie bei Mengen aus indi viduellen Elementen selbstverst ndlich nicht m glich ist Trotz der eleganten symmetrischen Beschreibung wird jedoch der Transport zwischen den Komponenten nicht deutlich Als nachteilig f llt auch auf da die Trennschicht mit Fl che A und Diffusionskoeffizi ent D im System nur einmal vorhanden ist im Modell die Parameter jedoch in beiden Komponenten deklariert werden Abhilfe in diesen Punkten schafft eine L sung nach Variante 4 Hier bildet die Trenn schicht eine eigene Komponente DA r_12 D A SC_1 SC2 SC_1 r_12 SC_2 B C C B Sr_ab Sr zu V Sr_zu Sr_ab V Modellgleichungen in beiden Komponenten C B V Konzentration B Sr_ab Sr_zu Aenderung des Bestandes
224. l den Einsatz der Methode verdeutlichen Beispiel Modell Lagerhaltung Die Abb 4 8 1 zeigt den Warenflu in einem einfachen Lagerhaltungsmodell Waren werden bei einem Unternehmen bestellt Bestellrate und aus dem Be stellbestand treffen mit einer gewissen zeitlichen Verz gerung gelieferte Waren im Lager ein Lieferrate Durch Eink ufe der Kunden gehen schlie lich Waren aus dem Lager ab Abgangsrate Obwohl Zug nge und Abg nge wohl allgemein als diskret angesehen werden werden sie hier durch stetige Str me beschrieben Es kommt eben weniger darauf an einzelne Waren zu erfassen als vielmehr den gesamten Waren und den daraus resultierenden Kapitalstrom zu betrachten 4 8 Beziehungen zu System Dynamics 185 Unternehmen Quelle Bestellrate p Zustands berf hrungsfunktionen fai x k r j f A t o gt f Dy N Bestell z t At a t Bestellrate l Pre bestand x Lieferrate j ae i i j j l t l er Lieferrate E l P 1 F i 7 i Dy Lager y t At y t Lieferrate 5 x bestand y Abgangsrate N Abgangsrate A Fi F K Kundenmarkt Senke Abb 4 8 1 Modell Lagerhaltung in System Dynamics Darstellung 186 4 Transporte zwischen Best nden Verwandtschaft zum diskutierten Sprachkonzept Wie gerade im gezeigten Beispiel deutlich wird stellt die durch ein Ventil symbolisierte Anderungsrate einen Spezialfall un
225. laration der Modellvariablen Das hier vorgestellte Sprachkonzept rechnet sich zu den deklarativen Sprachen Im Gegensatz zu prozeduralen Sprachen wird kein Programmablauf beschrieben sondern vielmehr das Verhalten von Variablen in Abh ngigkeit der anderen Variablen Die Formulierung eines Modells Programms konzentriert sich demnach ganz auf die Be schreibung der einzelnen Modellvariablen in ihren Eigenschaften und ihrem Verhalten Deshalb sprechen wir auch von einer Modellbeschreibungssprache und grenzen uns damit von den herk mmlichen Simulationssprachen ab Die Beschreibung einer einzelnen Modellvariablen umfa t e Bezeichner eindeutiger Name e Verwendung Zustandsvariable Sensorvariable abh ngige Variable e Wertemenge ganzzahlig reell logisch Aufz hlungsmenge e Zeitverlauf konstant zeitdiskret zeitkontinuierlich e ggf physikalische Ma einheit e Initialialwert fiir Zustandsvariablen und Sensorvariablen e dynamisches Verhalten der Variablen Das dynamische Verhalten der Variablen wird durch Definitionsgleichungen beschrieben und wurde bereits im vorangegangenen Abschnitt behandelt Die Belegung der Modellvariablen im Anfangszeitpunkt ist f r Zustandsvariable und ggf auch f r Sensorvariable durch einen Initialwert vorzugeben Die Anfangswerte der brigen Variablen k nnen aus diesen Vorgaben berechnet werden Die brigen Teile der Beschreibung umfassen das was man herk mmlich im Deklarationsteil e
226. lbst wieder aktiv werden Bei gleicher Modellvorstellung f hren die beiden Konzepte zu v llig verschieden Program men Ereignisorientierte Simulation l t sich mit jeder Programmiersprache hinreichend gut rea lisieren proze orientierte Simulation jedoch nur wenn die Sprache Nebenl ufigkeiten un terst tzt und die erforderlichen Synchronisationsmechanismen z B signal wait zur Ver f gung stellt Von den drei angef hrten Programmiersprachen kommt hierf r nur ADA in Betracht Die Erstellung eines prozeduralen Simulationsprogramms unmittelbar aus einer nicht for mal dokumentierten Modellvorstellung ist zwar m glich und wird leider auch heute noch in vielen F llen praktiziert das Resultat ist jedoch meist nicht zufriedenstellend Hierf r gibt es eine Vielzahl von Gr nden e Eine nicht formal dokumentierte Modellvorstellung ist in der Regel nicht pr zise ab gefa t und meist unvollst ndig H ufig liegt sie teilweise nicht einmal in schriftlicher Form vor Dadurch sind dem Programmierer viele Freiheiten gegeben nach eigenem Gutd nken die bestehenden L cken auszuf llen Da der Programmierer in der Re gel wenig von der Anwendung versteht enthalten Simulationsprogramme oft falsche Annahmen und Vermutungen e Das Simulationsprogramm mit dem schlie lich die Ergebnisse gewonnen werden ist als Dokument f r das Modell schlecht geeignet da man auf das Modellverhalten nur schlie en kann wenn man sowohl die Anweisungen
227. leifenkonstukt einer prozeduralen Programmier sprache erinnert und selbstverst ndlich auch durch ein solches implementiert wird so ergeben sich durch die semantischen Anforderungen einer Spezifikationssprache doch eine Reihe von Einschr nkungen Wir betrachten die Anforderungen an die Definition indizierter Variablen zun chst allgemein und sp ter im Zusammenhang mit dem Allquantor 3 4 4 Semantisch korrekter Gebrauch von indizierten Variablen in Definitionsgleichungen Die berschreitung des Indexbereiches ist f r gew hnlich ein Problem das erst zur Laufzeit erkannt werden kann F r die berpr fung der Eindeutigkeit und Vollst ndigkeit ist jedoch die Kenntnis der einzelnen Indices erforderlich Deshalb wollen wir dar ber nachdenken unter welchen Einschr nkungen eine Indexkontrolle durch den bersetzer m glich wird und ob diese Einschr nkungen die Verwendung von Feldern nicht zu sehr einengen Solange nur konstante Indices bzw Indexausdr cke zul ssig sind hat man die gleichen Verh ltnisse wie bei einzelnen Variablen 92 3 Spracherweiterungen zur Formulierung von Warteschlangenmodellen yli z 1 y 2 zD Beispiel x 1 x 2 Allerdings ergibt die Verwendung von Feldern hierbei keine Vorteile Interessant wird erst der Fall da ein Indexausdruck eine Variable enth lt Indexpr fung auf der rechten Gleichungsseite Wir wollen dabei zun chst den Fall betrachten da ein variabler Index auf der rechten
228. lem dar Der Algorithmus f r die Simulation ist nun noch durch die Abfrage der Variablenflags zu erg nzen Vor der Berechnung einer Bestimmungsgleichung wird zus tzlich zur Ebe ne Gruppe auch gepr ft ob berhaupt ein Einflu auf die zu setzende Variable vorliegt F r die abh ngigen Variablen sieht dies beispielsweise so aus 3 Alle abhaengigen Variablen y_i berechnen Fuer alle i aus 1 NY_j Falls Ebene m y_ i j Level Falls y_ i j Flag TRUE y G j g G j Qj Ch eee y G 1 j Z_j t Falls Wertaenderung Setzen der Marken siehe oben Bei der dynamischen Markierung sind also f r jeden Zeitpunkt c NY Ausgangsbeziehungen zu berechnen c x NG b NK Unterprogramme aufzurufen c NG b NY Abfragen auszuf hren wenn man davon ausgeht da die Anzahl der Gruppen NG betr gt pro Ebene b NK Kom ponenten aufzurufen sind und pro Zeitpunkt nur c NY statische Beziehungen berechnet werden m ssen Da sich die Auswirkungen auf wenige Komponenten beschr nken geht die Anzahl der Unterprogrammaufrufe und der Abfragen entsprechend zur ck Bei einer Realisierung in einer Komponente m ten pro Zeitpunkt NY Abfragen ausgef hrt werden F r gr ere Modellen bei denen c deutlich kleiner als 1 wird ergibt sich bei mo dularer Zerlegung sogar ein geringerer Aufwand Dies r hrt daher weil pro Zeitpunkt nur wenige kleine Komponenten anstelle einer sehr gro en zu durchlaufen sind R ckw rts Verfolgung Bei
229. len Zustand hervor Zustandsvariablen zi tk41 fi X tr Y tr Z tk tk Bei den algebraischen Gleichungen ist dies etwas anders da sich damit u U keine expliziten Beziehungen mehr ergeben Beispiele a y z y b Y 5 Z T Y2 Y2 TF Yi Wie wir aber gesehen haben kann dieser Effekt auch bei einer ungl cklichen Verschaltung einzelner Systeme auftreten Aus diesem Grund m ssen wir uns ohnehin berlegen auf wel che Weise die semantische Korrektheit bzw der explizite Charakter der Modellbeschreibung bewahrt werden kann Bei einem korrekt beschriebenen Modell mu es ganz offensichtlich m glich sein die abh ngi gen Variablen in eine solche Reihenfolge zu bringen da sich die zu definierende abh ngige Variable nur aus Eingangs und Zustandsgr en und bereits vorher definierten abh ngigen Variablen errechnet abh ngige Variablen y t gi X tk i te yalka gt Yi lka Z tk tk SQ Wie man diese Eigenschaft an den Modellgleichungen erkennen kann zeigt der folgende Abschnitt 34 2 Sprachentwurf im Sinne der klassischen Systemtheorie 2 2 Semantische Korrektheit Existiert so wie dies bei der expliziten Modelldarstellung der Fall ist f r jede Modellgr e eine Bestimmungsgleichung dann lassen sich die Beziehungen zwischen den Gr en durch einen Abhangigkeitsgraphen zum Ausdruck bringen Wir betrachten hier zun chst den Fall da das Modell nicht in mehrere S
230. liessende abfliessende Stueckzahlen oder in Anlehnung an eine Differenzengleichung DELTA B_j SUM_i T_ij SUM_i T ij b transportbezogene Beschreibung B_i gt BJ T_ij 144 4 Transporte zwischen Best nden 4 3 4 Mengenweise und elementweise Transporte In diesem Fall zeigt die Transportfunktion T an welche Teilmenge von Elementen aus dem Bestand B zum aktuellen Zeitpunkt zum Bestand B berwechselt Findet gerade kein Transport statt umfa t sie die leere Menge a sonst Sr falls Transportbedingung erf llt Tij 0 card T bestandsbezogene Beschreibung SUM Vereinigung Bj B_j SUM_i T_ij SUM_i T_ji Mengendifferenz zufliessende abfliessende Elemente oder in Anlehnung an eine Differenzengleichung DELTA B_j SUM_i T_ij SUM_i T_ij transportbezogene Beschreibung Bi gt B_j Tij Da T aus B entnommen sein mu ist f r den Fall des mengenweisen Transports die k rzere Schreibweise T_ij gt B_j vorteilhaft Bei Verwendung des Allquantors wurde als weitere M glichkeit bereits vorgestellt Transporte elementweise zu formulieren FOREACH Element IN T_ij LET Element gt B_j END Die Vorteile dieser Schreibweise werden an sp terer Stelle behandelt 4 3 Beschreibung von Transporten zwischen Best nden 145 Bei der Formulierung eines mengen bzw elementweisen Transports k nnen nur Elemente aus einem Bestand entnommen werden die a
231. lung eines Betriebsmittels gewartet werden mu oder blockiert werden weil auf die Bearbeitung eines Unterauftrags gewartet werden mu Wartende und blockierte Auftr ge werden in Warteschlangen zur ckgestellt 18 erledigte Auftr ge Betriebsmittel zuteilung Deblockierung ankommende Auftr ge 1 Einleitung Auftr ge warten auf Bedienung Auftrag wird bedient Betriebsmittel Unterauftrag ist erledigt anforderung Auftr ge sind blockiert Unterauftrag wird vergeben Station f r Unterauftrag Abb 1 5 2 Funktionsweise einer Station zur Bearbeitung von Auftr gen 1 5 Neue Anforderungen an die Simulationstechnik 19 Sind f r einen Arbeitsschritt Betriebsmittel erforderlich so werden diese angefordert Wenn alle ben tigten Betriebsmittel zugeteilt sind kann die Station den Auftrag bearbeiten So lange die Station noch auf Betriebsmittel warten mu ist der Auftrag blockiert Ob damit auch die Station blockiert ist oder in der Zwischenzeit ein anderer unabh ngiger Bearbei tungsschritt ausgef hrt wird h ngt von der individuellen Anwendung ab Ein Betriebsmittel bzw dessen Verwaltung nimmt Anforderungen der Stationen entgegen Sobald es verf gbar ist wird es einer Station zugeteilt Wenn es die Station nicht mehr ben tigt gibt sie es wieder frei Eine Station mu einen Bearbeitungsschritt nicht selbst ausf hren sie kann ihn
232. m Einsatz kommt gibt es hiermit offenbar keine Probleme In anderen Gebieten empfanden wir es jedoch als durchaus sinnvoll einen Zustand auch durch eine Eigenschaft d h durch einen Wert aus einer Wertemenge ausdr cken zu k nnen Diese Frage m ssen wir leider offenlassen da sie noch nicht endg ltig ausdiskutiert ist Ein anderer Punkt die Modularisierung l t sich jedoch nach den Beitr gen der letzten Abschnitte bereits zufriedenstellend abhandeln Modularisierung von System Dynamics Darstellungen DYNAMO bzw System Dynamics beinhaltet kein Konzept f r eine Modularisierung eines Modells Modelle sind daher immer nur als Ganzes darstellbar Dieses Manko fiel bislang nicht allzu sehr ins Gewicht da auch die anderen Simulationssprachen keine Modellzerlegung erm glichten Wie wir in den vorangegengenen Abschnitten gelernt haben mu die Modularisierung einer transportbezogenen Beschreibung durch Aufteilung eines Bestandes auf zwei oder mehrere Best nde vorgenommen werden Um dies auch graphisch zum Ausdruck zu bringen ist ein Bestand der mit einem anderen geteilt werden soll an den inneren Rand einer Komponente zu zeichnen und als ENTRY DENTRY EXIT oder TRANSIT zu kennzeichnen Auf einer bergeordneten Ebene k nnen dann diese Best nde durch Flu pfeile miteinander verbunden werden Auch ein hierarchischer Modellaufbau ist denkbar 4 8 Beziehungen zu System Dynamics 187 Durchtrennt die Komponentengrenze ein Wirkpfeil d
233. m Gebrauch des Allquantors da e fiir jeden Feldnamen nur eine einzige Definitionsgleichung angegeben ist e jeder Index der zu definierenden Variablen nur aus einer gebundenen Variablen besteht e alle gebundenen Variablen als Indices der zu definierenden Variablen verwendet werden Die Gew hrleistung der Vollst ndigkeit erfordert dar ber hinaus da e das FOREACH Konstrukt keine Bedingung enth lt Eine berpr fung der Feldgrenzen ist unter diesen Bedingungen stets m glich 3 4 Einf hrung von Feldern 99 3 4 6 Impliziter Allquantor Um die Vollst ndigkeit und Eindeutigkeit zu sichern haben wir zahlreiche Einschr nkungen getroffen Als besonders vorteilhaft stellte sich heraus den Indexausdruck der zu definieren den Variablen auf die gebundene Variable zu beschr nken Es bietet sich daher alternativ eine kompaktere Notation f r den Allquantor an die sich lediglich auf eine einzige Definitionsgleichung bezieht Dazu erlaubt man da Indices der zu definierenden Variablen eine Indexmenge anstelle eines einzelnen Wertes enthalten d rfen index index_expression implicit_indexset implicit_indexset index_range identifier IN index_range gt condition Diese Indexmenge in geschweiften Klammern umfa t einen Indexbereich der durch eine Bedingung eingeschr nkt werden kann und kann mit einer gebundenen Variablen versehen werden Wird kein Indexbereich angegeben dann um
234. m Simulationsprogramm Neuer Wert der Sensorvariablen Diese Vorgehensweise erfordert jedoch gleichzeitig eine Synchronisation mit der Echtzeit damit der Simulator nicht seiner Umgebung in der Zeit vorauseilt Ebenso ist das Abfragen von Variablenwerten von Interesse Kennung Abfragen eines Variablenwertes Name der Variablen bzw deren Adresse Die Ausgabe erfolgt dann ber einen zweiten Kanal Kennung Mitteilung eines Variablenwertes Name der Variablen bzw deren Adresse Wert der Variablen Schnittstellen wie die eben beschriebenen machen den Simulator zu einem eigenst ndigen Modul in einem Verbund von Prozessen Betriebsbegleitende Simulation wird dadurch ebenso erm glicht wie das Testen von Steuerungs Software an einer simulierten Anlage 225 Kapitel 7 Anwendungen Die folgenden Anwendungsbeispiele sollen die Tragfahigkeit des vorgestellten Sprachkonzepts unter Beweis stellen und dem Leser einen Eindruck davon vermitteln welche M glichkeiten sich hiermit er ffnen Es geht dabei mehr darum den Einsatz der sprachlichen Mittel zu demonstrieren als f r jedes Anwendungsgebiet ein typisches Beispiel abzugeben Das w rde den Rahmen der Arbeit sprengen Der interessierte Leser sei hierzu auf ApEsWi 92 verwiesen 7 1 Die Modellbank PetriNet Die Modellbank PetriNet stellt die Komponenten zum Aufbau von allgemeinen Petrinetzen zur Verf gung Die Marken sind durch Z hler repr sentiert Dieses Bei
235. m ersten Ansatz konnten durch die Einf hrung der abh ngigen Mengenvaria blen zwei wesentliche M ngel beseitigt werden Vor allem ist der Gebrauch des Klassenkonzepts weiterhin gew hrleistet Bei einer Ver vielf ltigung der Komponenten vervielf ltigen sich auch die Mengenvariablen bzw Warte schlangen Jede Mengenvariable erh lt ihren individuellen Namen der sich aus Komponenten und Variablennamen zusammensetzt Beispiel SUBCOMPONENTS Q1 OF CLASS Q Q2 OF CLASS Q Die Mengenvariablen in den Komponenten Q1 und Q2 besitzen die Namen Q1 Queue und Q2 Queue Zum Verbindungsaufbau sind nun auch keine Dummy Variablen mehr erforderlich da die Mengenvariablen selbst an die anderen Komponenten weitergegeben werden k nnen Nach wie vor besteht aber das Problem in welcher Weise der Aufenthaltort der mobilen Komponenten initialisiert werden soll Bei ihrer Deklaration sind die Namen der Mengenva riablen noch nicht bekannt Auch die brigen Unzul nglichkeiten konnten noch nicht beseitigt werden 3 7 Einf hrung von Mengenvariablen als Zustandsvariablen Im dritten Ansatz sehen wir vor da jede mobile Komponente standardm ig stets einen bestimmten Aufenthaltsort besitzt und damit immer einer Menge zugeordnet ist Der Auf 120 3 Spracherweiterungen zur Formulierung von Warteschlangenmodellen enthaltsort wird dadurch zu einer besonderen Menge die als Zustandsvariable angesehen werden kann 3 7 1 Locations und mobile Komponente
236. m selektiert und ver ndert werden k nnen Um mit der Vorstellung eines Warteraums arbeiten zu k nnen mu es m glich sein Eigenschaftsmengen von beweglichen Einheiten zu bilden die Anzahl von Elementen dieser Menge Kardinalit t festzustellen auf einzelne Elemente dieser Mengen selektiv zuzugreifen In der Regel enth lt eine bewegliche Einheit ein Attribut das f r den Aufenthaltsort steht und das zur Mengenbildung herangezogen werden kann Die Selektion eines Elements aus einer ungeordneten Menge kann nur durch die Angabe von Selektionkriterien erfolgen die quasi auf ein Ordnen der Menge hinauslaufen z B h chste Priorit t 86 3 Spracherweiterungen zur Formulierung von Warteschlangenmodellen Die Attribute selektierter Einheiten k nnen dann entweder gelesen oder beschrieben werden Durch ein Ver ndern des Aufenthaltsorts ist auch ein Transport einer selektierten Einheit m glich Wir werden zun chst Modelle mit Warter umen aufbauen und erst sp ter Warteschlangen einf hren Eine Warteschlange ist eine Menge bei der die Elemente stets nach vorgegebenen Kriterien geordnet sind Diese st ndig bestehende Ordnung erleichtert die Selektion von Elementen aus einer Menge Um mit der Vorstellung einer Warteschlange arbeiten zu k nnen mu es m glich sein die Zugeh rigkeit einer beweglichen Einheit zu einer Warteschlange eindeutig festzule gen Ordnungskriterien f r eine Warteschlange zu vereinbaren
237. mit einem neuen Wert berschrieben werden Die Best nde k nnen mit einer ver nderten Anzahl mobiler Komponenten vorbesetzt werden Die Vorbesetzung von Best nden ist immer dann notwendig wenn durch eine Zusammen legung von Best nden widerspr chliche Initialisierungen gelten In diesem Fall ist die Vor besetzung f r alle zusammengelegten Best nde durchzuf hren Aber auch private Best nde k nnen initialisiert werden initialization INITIAL CONDITION S variable_initialization location_initialization variable_initialization variable expression location_initialization fusion number identifier fusion location location location gt transport_connection 5 4 H here Komponenten variable indexed_component indexed_variable location indexed_component indexed_location indexed_component indexed_identifier indexed_location indexed_identifier Beispiel INITIAL CONDITIONS A X 15 A Queue 5 Job A Queue B Queue A Server gt C Queue 1 Job 5 Job 211 212 213 Kapitel 6 Spracherweiterungen fiir den praktischen Einsatz 6 1 Anforderungen Das bisher besprochene Sprachkonzept bildet die Grundlage f r die zustandsorientierte Be schreibung von Modellen F r einen praktischen Einsatz sind diese Konstrukte trotz des bisher erreichten Sprachumfangs jedoch noch nicht ausreichend
238. n Beispiel Komponente A Komponente B rA 6 a y g x y g z Z Die Zuordnungen an die Sensorvariablen werden beschrieben durch A x B y B x A Z Eine Komponente ist demnach ein Teil Modell mit eigenen Variablen und eigenen Defini tionsgleichungen f r diese Variablen Bei der Zuordnung eines Wertes an eine Sensorvariable beschr nken wir uns auf die Zuord nung einer internen Variablen Ein Ausdruck der sich aus internen Variablen zusammensetzt oder ein einzelner Wert d rfen nicht zugeordnet werden Wir sprechen daher im folgenden nicht mehr von Zuordnung sondern von Verbindung und verwenden einen Pfeil gt als Verbindungsoperator 60 2 Sprachentwurf im Sinne der klassischen Systemtheorie Beispiel EFFECT CONNECTIONS A z gt B x B y gt A X Die internen Variablen auf der linken Seite werden mit den Sensorvariablen auf der rechten Seite verbunden Diese Ma nahme f rdert die bersichtlichkeit und erm glicht eine graphische Darstellung der Modellbeschreibung Sie ist keine Einschr nkung der Modellierbarkeit Schlie lich ist es immer m glich f r Verkn pfungen zwischen mehreren internen Variablen eine weitere Komponente zwischenzuschalten Modellbeschreibung spielt sich demnach auf zwei Ebenen ab Auf der unteren Ebene in den sogenannten Basiskomponenten wird durch Verkn pfung zwischen Variablen das dy namische Verhalten definiert Auf der bergeordneten Ebene in den sogenannten h
239. n Eingang Entrance Ausgang Exit TService Mean NUnits Entrance gt Exit e Advance Zeitverz gerung eines oder mehrerer Auftr ge um eine feste Zeit Parameter TDelay Verz gerungszeit Eingang Entrance Ausgang Exit TDelay Entrance Exit e Distrib Verteilung von Auftr gen nach Wahrscheinlichkeiten auf drei verschiedene Ausg nge Parameter pl Wahrscheinlichkeit f r Exit1 p2 Wahrscheinlichkeit f r Exit2 Eingang Entrance Ausg nge Exit1 Exit2 Exit3 Exiti Exit2 Exit3 Entrance gt Py P2 Nach Ablauf der Bearbeitungszeit schickt die Bedienstation den Auftrag weiter Deshalb sind alle Komponenten so ausgelegt da sie jederzeit einen Auftrag entgegennehmen k nnen Ins besondere ist es erforderlich da vor einer Bedieneinheit stets eine Warteschlange angeordnet ist Alle Transporte sind gerichtet Eing nge d rfen nicht parallel zueinander liegen f r Ausg nge ist dies erlaubt Das bedeutet da Transporte zwischen Komponenten zum Sammeln von Auftr gen dienen d rfen aber es darf keine Verteilung auf mehrere Eing nge stattfinden Aus diesem Grund mu zum Verteilen eine eigene Komponente existieren Mit den Komponenten dieser Modellbank ist der Sprachumfang der Simulationsssprache GPSS bereits nahezu abgedeckt 7 4 Die Modellbank QueueNet MOBILE COMPONENT Job DECLARATIONS STATE VARIABLES CONSTANT Priority INT DISCRETE TR
240. n Um einen Bezug zu den bisherigen Ausf hrungen herzustellen berlegen wir uns zun chst wie abh ngige Mengenvariablen zu modifizieren w ren wenn wir den Aufenthaltsort als standardm iges Attribut einer mobilen Komponente einf hren o Jede mobile Komponente wird standardm ig mit einer Zustandsvariablen LOC mit Wertemenge NAME SET OF mobile_component versehen die dem Anwender verbor gen bleibt und auch nicht durch Wertzuordnung vorbelegt werden kann Dieser Zu standsvariablen wird der momentane Aufenthaltsort der mobilen Komponente zuge wiesen Beispiel STATE VARIABLE LOC NAME SET OF Job o Wir f hren abh ngige Mengenvariablen mit Wertemenge SET OF mobile_element ein und erm glichen bei deren Deklaration die Angabe von Kriterien nach denen die mobi len Elemente anzuordnen sind Diese Mengenvariablen stehen f r m gliche Aufenthalts orte einer mobilen Komponente werden daher als Locations bezeichnet und k nnen vom Benutzer deklariert werden Beispiel DEPENDENT VARIABLE Queueil SET OF Job DEC Priority INC TEntry Die Definition einer Location erfolgt implizit aufgrund der bei der Deklaration gemach ten Angaben Beispiel Quevel J IN Job J LOC NAME Queuel o Mobile Komponenten werden nicht mehr durch die Vereinbarung eines globalen Feldes angelegt Stattdessen kann jede Location mit einer bestimmten Anzahl von mobilen Elementen vorbelegt werden Beispiel Queuel 5 Job Dadurch wird dere
241. n stetigkeitsstellen Knick und Sprungstellen vorsieht oder die Angabe der Ableitung optional ermeoglicht falls diese bekannt ist Beispiel TABULAR FUNCTION Concut REAL gt REAL CONTINUOUS BY CUBIC BESSEL INTERPOLATION ON 1 0 0 5 0 0 0 0 1 0 gt 1 0 0 25 0 0 1 0 2 0 3 0 Die Tabellenfunktion besitzt im Punkt 0 0 eine Sprungstelle Rechts davon verl uft eine Gerade links eine Parabel Die Angabe der Ableitung im Punkt 0 0 ist bei kubischer Interpolation durch zwei Punkte erforderlich Wie die Beispiele zeigen k nnen Tabellenfunktionen mit betr chtlichem Komfort ausgestat tet werden Auch dieser Gesichtspunkt macht die Aufnahme der Funktionstabellen in die Sprache sinnvoll weil dadurch eine umfangreiche Analyse von Syntax und Semantik der Datens tze erfolgen kann Um die Auswertung zur Laufzeit insbesondere die Interpolation kontinuierlicher Funktionen braucht sich der Anwender dann ebenfalls keine Gedanken zu machen 6 7 Schnittstellen zur Umgebung 223 6 7 Schnittstellen zur Umgebung Die bisher beschriebene Funktionalit t des Sprachkonzepts l t bez glich der Formulierung von Modellen keine W nsche mehr offen Leider ist aber auch noch zu ber cksichtigen da der Anwender den Simulator in eine bereits vorhandene Umgebung auf seinem Rechner einbetten m chte So m chte er beispielsweise vor oder w hrend eines Simulationslaufs Daten einlesen die dem Betrieb des Modells dienen Dabei handelt
242. n Mindestabstand ein Parameter Laenge L nge des Transportbands m V F rdergeschwindigkeit m s MinAbst Mindestabstand zwischen zwei Teilen m Eingangsbestand Eingang Ausgangsbestand Ausgang Transportband Laenge Eingang DV d Ausgang MinAbst MOBILE COMPONENT Teil DECLARATIONS STATE VARIABLE DISCRETE XEnde REAL 0 Ort an dem das Teil das Ende des Bandes erreicht hat END OF Teil 7 5 Die Modellkomponente Transportband 243 BASIC COMPONENT Transportband MOBILE SUBCOMPONENTS OF CLASS Teil DECLARATIONS STATE VARIABLES CONSTANT V REAL 5 Geschwindigkeit des Bandes Laenge REAL 5 Laenge des Bandes MinAbst REAL 0 5 Abstand der Teile auf dem Band DISCRETE XLast REAL 0 5 Ort an dem das letzte Teil eintraf Vorbesetzung MinAbst CONTINUOUS X REAL 0 Ort DEPENDENT VARIABLE DISCRETE Fahren LOGICAL Anzeige ob Band faehrt ENTRY LOCATION Eingang SET OF Teil 0 Teil PRIVATE LOCATION Band SET OF Teil 0 Teil EXIT LOCATION Ausgang SET OF Teil 0 Teil DYNAMIC BEHAVIOUR Fahren EMPTY Ausgang Band faehrt wenn nicht am Ende ein Teil zum Abholen liegt IF Fahren LET X V END ELSE LET X 0 END IF NOT EMPTY Eingang AND X XLast gt MinAbst Vom Eingang darf ein LET Teil geholt werden Eingang Teil 1 gt Band wenn der Abstand gross Eingang Teil 1 XEnde X Laenge genug ist XLast X END IF
243. n Standardattribut LOC entsprechend besetzt Aus den Vorbelegun gen aller Aufenthaltsorte ergibt sich die gesamte Menge an mobilen Elementen im Modell 3 7 Einf hrung von Mengenvariablen als Zustandsvariablen 121 o Zugriffe auf mobile Komponenten sind nun nicht mehr global m glich sondern nur noch ber ihren Aufenthaltsort Beispiele Job 5 ist nicht mehr m glich Queue Job 1 erster Job auf Queue Queue Job 1 5 Menge mit den ersten f nf Jobs auf Queue soweit vorhanden o Die Zuordnung des Aufenthaltsortes wird durch einen speziellen Operator vorgenom men Diesen Operator gt bezeichnen wir als Transportoperator weil er den Wechsel des Aufenthaltsortes und damit einen Transport zum Ausdruck bringt Beispiel Queue1 Job 1 gt Queue2 entspricht Queue1 Job 1 LOC NAME Queue2 Die mobile Komponente Job 1 auf Queuei befindet sich im folgenden Zustand auf Location Queue2 Der Transportoperator verbirgt das Standardattribut LOC eines mobilen Elements Er erm glicht lediglich einen schreibenden Zugriff auf die Variable LOC Da Zugriffe auf mobile Komponenten nur noch ber deren Aufenthaltsort m glich sind wird ein le sender Zugriff auf das Attribut LOC berfl ssig Beispiel Liefert LOCATION den Aufenthaltort einer mobilen Komponente dann gilt LOCATION Queue1 Job 1 ergibt Queuel Jedes mobile Element erh lt durch diese Ma nahmen umkehrbar eindeutig eine bestimmte Position innerhalb einer best
244. n Zeitmenge ergibt sich der n chste Zeit punkt einfach als n chster Wert aus dieser Menge z B t t At L t man eine kontinuierliche Zeitmenge mit reellen Zahlen zu und verwendet man als Im plementierungszeit eine zweidimensionale Zeitmenge die sich aus Zeitpunkt und Moment zusammensetzt dann h ngt der Zeitfortschritt vom aktuellen Zustand ab Solange der ak tuelle Zustand ein weiteres Ereignis ausl st wird mit einem infinitesimal kleinen Zeitinkre ment d h mit dem n chsten Moment fortgefahren Ansonsten wird die Zeit entsprechend dem Aufl sungsverm gen um einen endlichen Zeitschritt weitergesetzt Eine effiziente Imple mentierung die nicht f r jeden Zeitpunkt einen Schleifendurchlauf ben tigt wurde bereits in Esch 90 angegeben Dort wurde auch beschrieben wie der Algorithmus zu erweitern ist wenn neben Ereignis sen Differentialgleichungen als Zustands bergangsfunktionen zul ssig sind Da dies auf die folgenden berlegungen keinen Einflu hat nehmen wir stets auf den angegebenen Grun dalgorithmus Bezug der sich f r alle Arten von diskreten Zustands berg ngen eignet 2 5 2 Sortieren der statischen Beziehungen Anhand des eingef hrten Abh ngigkeitsgraphen kann man sowohl eine geeignete Reihenfolge f r die Berechnung der abh ngigen Variablen als auch eine insgesamt effizientere Abarbeitung des Algorithmus ableiten Wir betrachten das folgende Beispiel mit den angegebenen Abh ngigkeiten Beispiel Geg
245. n fertigungstechnischen Anlagen streben von jeher eine L sung an welche die vor gegebene Produktionsrate bei m glichst geringen Kosten Investitions und Betriebskosten erreicht Bei einer gro en St ckzahl von Teilen geringer Variantenvielfalt und einem gro en Fer tigteilelager kann ein sehr kontinuierlicher Fertigungsproze erreicht werden St rungen im Fertigungsablauf lassen sich durch gen gend gro e Puffer zufriedenstellend berbr cken Die Produktionsrate als einzige interessierende Gr e l t sich sehr leicht aus den Verf gbarkei ten der Maschinen ermitteln Durch die immer individueller werdenden Kundenw nsche und die daraus resultierende Va riantenvielfalt hat sich die Situation in den letzten Jahren zunehmend ver ndert Es ist nicht mehr m glich jedes gew nschte Produkt auf Lager zu halten da das Lager zu gro und zu 16 1 Einleitung teuer die Kapitalbindung betrachtlich und das Risiko bereits produzierte Ware gar nicht mehr absetzen zu k nnen zu hoch w re An die Stelle einer Produktion auf Vorrat tritt daher zunehmend eine Produktion auf Anfra ge Diese bei kleinen St ckzahlen schon immer praktizierte Produktionsform findet demnach verst rkt Eingang im Bereich der Serien und Massenfertigung Bei kleinen St ckzahlen kann man es sich leisten auf eine detaillierte Planung des Ferti gungsprozesses zu verzichten weil der Automatisierungsgrad gering ist und man sich die Intelligenz der Werker zunutz
246. n mehreren anderen Knoten ab dann wird die jeweils gr te Gruppennummer bernommen F r Sensorvariablen tragen wir die um 1 erh hte Gruppennummer der angeschlossenen Variablen ein Bei jedem Wechsel des Signalpfads auf eine andere Komponente wird demnach die Grup pennummer um 1 erh ht Die Gruppennummer jeder Variable zeigt nun an ber wie viele Sensorvariablen der Pfad im Abh ngigkeitsgraphen maximal f hrt d h wie h ufig zwischen Komponenten zu wechseln ist 76 2 Sprachentwurf im Sinne der klassischen Systemtheorie Beispiel Y t gu 211 Ya 912 X12 Yor c ga Lu Yu Yoq 922 Y 2 y 931 211 Ya Ya 932 X22 Y22 0 1 2 x 2 a Gl Ge ma m N K2 5 j o Eine weitere Optimierung w re m glich w rde man y der Gruppe 2 zuordnen Absch tzung des Rechenaufwands Durch Kombination der drei Ma nahmen sind nunmehr f r jeden Zeitpunkt zur Bestimmung der abh ngigen Variablen NY statische Beziehungen zu berechnen NG b NK Unterprogramme aufzurufen NG b NY Abfragen auszuf hren wenn man davon ausgeht da die Anzahl der Gruppen NG betr gt und pro Gruppe b NK Komponenten aufzurufen sind Geht man typischen Erfahrungen gem von einer Gruppenanzahl von 3 aus und davon da mit jeder Gruppe durchschnittlich zwei von drei Komponenten b 2 3 aufzurufen sind ergeben sich 2 x NK Unterprogrammaufrufe und 2 x NY Abfragen Macht man vom Se
247. n mit ihren beeindruckenden graphischen Oberfl chen Die Abbildung 1 3 2 zeigt in welcher Weise Werkzeuge zur Frstellung von Simulationspro grammen aufeinander aufbauen Die Ausf hrungen machen deutlich da keiner der bisherigen Ans tze eine allgemein zufrie denstellende L sung gebracht hat Wie wir sp ter sehen werden k nnen vor allem neuere Anforderungen damit nicht bearbeitet werden 1 4 Ansatz f r ein neues Sprachkonzept Es wurde bereits herausgestellt da alle Bestrebungen darauf hinauslaufen die Kluft zwi schen einer mehr oder weniger vagen Modellvorstellung des Anwenders und dem mehr oder weniger kryptischen Simulationsprogramm eines Programmierers zu berbr cken Die Entwickler der Simulationssprachen bem hten sich anstelle der h heren Programmier sprachen eine prozedurale Sprache anzubieten welche durch geeignete Sprachkonstrukte die Formulierung von proze orientierten Simulationsprogrammen vereinfacht Wie bereits oben ausgef hrt erscheint der Erfolg fraglich weil nicht alle Modellvorstellungen auf die angebotene einfache Weise beschreibbar sind Um weitere Eingriffsm glichkeiten ausnutzen zu k nnen sind jedoch wiederum betr chtliche Systemkenntnisse vonn ten Der in dieser Arbeit anvisierte Sprachentwurf geht nicht von einer proze orientierten son dern von einer ereignis orientierten Beschreibung dynamischer Modelle aus Wir schlie en uns damit einer zustands orientierten Betrachtung an wie s
248. n sogar immer nur f r einen Augenblick ben tigt Unstrittig ist da eine Zufallsvariable zu einem Zeitpunkt nur einen Wert annehmen kann Hingegen ist offen wodurch eine Zufallsvariable veranla t werden soll ihren Wert zu ndern Drei Alternativen stehen zur Auswahl 1 Eine Anweisung in einem Ereignis z B DRAW TWork veranla t das Ziehen einer neuen Zufallszahl die dann im n chsten Zeitpunkt bzw Moment zur Verf gung steht Nachteil Der neue Wert der Zufallsvariablen wird meist bereits schon zum aktuellen Zeitpunkt ben tigt 2 Ein Funktionsaufruf z B NXTRAN TWork erlaubt bereits den Zugriff auf den n chsten Wert der Zufallszahlenfolge und veranla t da TWork vom n chsten Zeitpunkt bzw Moment an den neuen Wert besitzt Nachteil Zu einem Zeitpunkt besteht Zugriffsm glichkeit auf den alten wie den neuen Wert der Zufallsvariablen 3 Zufallsvariable d rfen nur in Ereignisfunktionen verwendet werden Jeder Zugriff auf die Zufallsvariable in einer Wertzuordnung an eine Zustandsvariable z B TReady T TWork liefert einen fiir den aktuellen Zeitpunkt neuen Wert zuriick Nachteil Kein informativer Zugriff m glich da sich dadurch der Variablenwert ver ndert 6 6 Tabellarische Funktionen und Verteilungen 221 Keine der drei Alternativen kann vollst ndig zufriedenstellen In SIMPLEX MDL wurde zun chst einmal die Alternative drei realisiert Das folgende Beispiel zeigt da diese Alter nativ
249. n verweisen k nnte Um die Gedankeng nge nachvollziehbar zu machen wurde die Materie streckenweise f r wissen schaftliche Abhandlungen un blich induktiv statt deduktiv dargelegt Als Grundlage fiir weitere Arbeiten an diesem Thema erschien mir diese Vorgehensweise die geeignetere Ich denke da die berlegungen die in dieser Arbeit angestellt werden auch ber die Bew ltigung von Simulationsaufgaben hinaus von Interesse sind Vielfach handelt es sich um Probleme die sicherlich in hnlicher Form bei der Beschreibung anderer Sachverhalte auftreten Auch das Sprachkonzept selbst soll Anregungen f r einen Sprachentwurf in ande ren Disziplinen der Informatik liefern Vor allem auf den Bereich der Steuerungstechnik und Proze automatisierung scheint das Konzept bertragbar Die Arbeit w re in dieser Form sicherlich nicht zustande gekommen ohne die Mitwirkung meiner beiden Kollegen Herrn Jochen Wittmann und Herrn Thomas Apsel Ihnen geb hrt ein herzliches Dankesch n f r die vielen Beitr ge die sie in zahlreichen Diskussionen beige steuert haben Ebenso geht mein Dank an Herrn Prof B Schmidt der diese Arbeit angeregt und betreut hat an Herrn Prof F Hofmann der mir stets mit Tips und Ratschlgen zur Seite stand und Herrn Prof H Wedekind sowie Herrn Prof W Ameling die zusammen mit den beiden erstgenannten die Arbeit begutachteten Erlangen im Februar 1995 P Eschenbacher iii Preface This book has been subm
250. nd Senke sind eigenst ndige Typen von Best nden und lassen sich nicht einfach als Spezialf lle von ENTRY und EXIT Locations auffassen Mit Quellen und Senken ist n mlich eine eigene Dynamik verbunden d h eine Dynamik die nicht vom Benutzer definiert ist Die Implementierung sorgt daf r da mobile Komponenten die an einer Senke ankommen vernichtet werden um nicht unn tig Speicherplatz zu belegen Eine mobile Komponente wird implizit erzeugt wenn auf ein Element einer Quelle zugegriffen wird das noch nicht vorhanden ist Abholmenge diskreter Abgang aus einem Lager 4 8 Beziehungen zu System Dynamics 183 4 8 Beziehungen zu System Dynamics Die in diesem Kapitel vorgenommene Unterteilung der Modellvariablen in Eigenschafts gr en und Bestandsgr en wurde in einem anderen Zusammenhang bereits Ende der sech ziger Jahre von J W Forrester angeregt Forrester besch ftigte sich mit Modellen deren Ergebnisse hohe firmen politische Prisanz hatten Entwicklung von Industriekomplexen Stadtentwicklung Weltmodelle Da diese Modelle auf relativ vagen Daten beruhten und auch nicht klar war ob alle we sentlichen Einflu gr en Ber cksichtigung fanden hatte Forrester die Notwendigkeit auf m glichst anschauliche Art und Weise die Zusammenh nge in seinen Modellen offenzulegen Er wollte zeigen da das prinzipielle Verhalten dieser Modelle eher von deren Struktur als von einer exakten Parametrierung beeinflu t wird Auch
251. nd keine ELSIF Zweige mehr erforderlich um die Eindeutigkeit herzu stellen Die Variablen lassen sich nun auf einzelne Komponenten verteilten und damit eine Modularisierung durchf hren 4 1 Motivation 133 SSS SS SS eS Se Seo ae CS SS Se a eo ee ee eee ee ee eee ee ee Komponente Q SSeS eee ee ee See ee Se Se SS Se 2 Sc 2 2 LI SD eS Se ee ee eS eS SS CONSTANT TService REAL 8 STATE VARIABLE NQ INT 0 DEPENDENT VARIABLE N_QS INT SENSOR VARIABLE N_S CINT N_RS INT Transporte von Queue nach Server SSS eee ee ee Sa a a Sa Se Se aa IF NQ gt 0O AND NS O LET N_QS 1 END ELSE LET N_QS 0 END Aenderung in der Belegung der Queue a a a a i a NO a SEE HESS EEEEREE REKEN EN SER ER SER SE INEER aia NQ N_Q N_RQ N_QS Sooo Se a a also Do I 2 ou Komponente S za s s te kh a ea ee ee ee isn CONSTANT TService REAL 8 STATE VARIABLE TEntry REAL 0 NS INT 0 DEPENDENT VARIABLE N_SR INT SENSOR VARIABLE N_QS INT Transporte von Server nach Reservoir SS SS Se ee ae SS ee ee IF NS gt 0O AND T gt TEntry TService LET N_SR 1 END ELSE LET N_SR 0 END 134 4 Transporte zwischen Best nden Aenderung in der Belegung des Servers lol 2 22 2a sooo IF N_QS gt 0 LET TEntry T END else ee eS Se ee eee Jo sooo Zoos SS Se Se eo Komponente R eit Ee Se ee Se eS See See SSS ee ss on Delete STATE VARIABLE TGenera RE
252. nd und daher m gen an dieser Stelle einige Beispiele gen gen 48 2 Sprachentwurf im Sinne der klassischen Systemtheorie Beispiel DEFINITION VALUE SET Color red green blue DECLARATIONS STATE VARIABLE CONSTANT a INT at DISCRETE Z1 Color red CONTINUOUS Z2 REAL 10 DEPENDENT VARIABLE CONSTANT F Color DISCRETE Y1 LOGICAL CONTINUOUS Y2 REAL SENSOR VARIABLE CONSTANT m INT E DISCRETE x REAL m 10 nm CONTINUOUS v REAL m s 0 m s Die M glichkeit Ma einheiten definieren zu k nnen ist zwar f r eine sichere Modellerstel lung von gro er Bedeutung f r die Zielsetzung dieser Arbeit sind Ma einheiten jedoch ohne Belang Sie werden in Kapitel 6 in aller K rze abgehandelt 2 4 3 Anfangsbelegung der Modellvariablen Die Anfangsbelegung der Modellvariablen ist mit der Initialisierung der Zustandsvariablen vollst ndig bestimmt Damit eine Vorbesetzung in jedem Fall sichergestellt ist sind Zu standsvariablen bei ihrer Deklaration in der Modellbeschreibung mit einem Anfangswert zu initialisieren In h heren Komponenten siehe Kapitel 2 6 kann diese Vorbesetzung ber schrieben werden Letztendlich g ltig ist aber der Initialwert den der Experimentator ber die Programmschnittstelle siehe Kapitel 1 2 vorgibt wenn dieser mit einer ver nderten Vorbesetzung arbeiten m chte Die Werte von nicht angeschlossenen Sensorvariablen im Anfangszeitpunkt ermitteln sich aus eine
253. ndeutige Zugriff auf einen Eingangsbestand in diesem Fall keine Rolle daf r ist es aber von Bedeutung da aus einem Eingangsbestand nicht mehr Elemente entnommen werden als darin enthalten sind siehe Kapitel Anwendungen Petrinetze und Philosophen problem Dies kann der Benutzer leichter sicherstellen wenn nur eine Komponente aus einem Bestand entnimmt Auch in diesem Fall m ten sich die Komponenten sonst gegen seitig abstimmen Wenn dies nicht vorgesehen ist kann durch die Deklaration eines Bestands mit dem Typ ENTRY ausgeschlossen werden da eine eine zweite Komponente den Bestand vermindert Nicht angeschlossene Eingangs und Ausgangsbest nde Eine andere Problemstellung ergibt sich aus der Frage wie verfahren werden soll wenn ein Eingangs oder Ausgangsbestand nicht mit einem Bestand in einer anderen Komponente verbunden ist Sinnvollerweise wird in einem solchen Fall so verfahren als w rde eine an geschlossene Komponente keine Aktivit t zeigen Das bedeutet ein Eingangsbestand erh lt seine Vorbesetzung die auch entnommen werden kann und ein Ausgangsbestand sammelt all die Elemente die ihm zugef hrt werden ohne sie zu vernichten 178 4 Transporte zwischen Best nden 4 6 3 Hierarchiebildung mit Best nden Hierarchiebildung mit Eigenschaftsvariablen haben wir bereits behandelt Selbstverst ndlich sollen auch Best nde kein Hindernis darstellen Hierarchiebildung zu betreiben Wir m ssen es daher m glich machen da
254. ne Variablen 3 Verbindungen zwischen Komponenten 4 Initialisierung der Modellvariablen in Subkomponenten 2 Sprachentwurf im Sinne der klassischen Systemtheorie Die Syntax der Modellbeschreibungssprache kann sich unmittelbar daran anlehnen und ist im folgenden nochmals zusammengefa t high_level_component subcomponent_declaration subcomponent sensor_variables i internal_variables effect_connections initialization HIGH LEVEL COMPONENT subcomponent_declaration sensor_variables internal_variables effect_connections initialization END OF identifier FI f A pa G a SUBCOMPONENT S identifier subcomponent subcomponent identifier SENSOR VARIABLE S identifier gt 7 gt identifier identifier identifier INTERNAL VARIABLE S identifier lt identifier identifier lt identifier EFFECT CONNECTION S identifier identifier identifier identifier identifier identifier identifier identifier INITIAL CONDITION S identifier identifier identifier identifier OF CLASS identifier identifier identifier identifier identifier value value Die Bedeutung der Bezeichner ergibt sich aus den Erl uterungen der vorangegangenen Ab schnitte 2 7 Algorithmus f r die Simulation einer modularen Modellbeschreibung 67 2
255. ne der klassischen Systemtheorie Durch Erzeugung eines geeigneten Codes lassen sich beide F lle problemlos zur Laufzeit erkennen Eine Fehlererkennung zur bersetzungszeit ist jedoch nicht mehr mit vertretbarem Aufwand zu leisten und es ist nicht klar ob es im allgemeinen Fall berhaupt l sbar ist Dazu m te es m glich sein die einzelnen Bedingungen symbolisch zu verarbeiten Dieses Problem l t sich dadurch umgehen indem man erlaubt da die Zustandsraumzerle gung sukzessive erfolgt d h ausgegrenzte Gebiete bei den weiteren Bedingungen nicht mehr ber cksichtigt werden Die Schreibweise lautet dann fi V falls W e Ci sonst fV falls W C u sonst f3 V falls W C SONSt ek falls aaa sonst AV mit der Bedeutung fiV falls We Ci fo V falls W EC und nicht W EC ie f3 V falls W EC3 und nicht W EC UC ER falls Be und nicht sr fa V sonst Die Mengen Ci C2 u s w d rfen bei dieser Schreibweise die bereits ausgegrenzten Gebiete mit umfassen Ci BiU Bii U U Bi Die Fallunterscheidung in einem zweidimensionalen Zustandsraum kann man sich beispiels weise so vorstellen 22 B B B3 By 21 V falls 21 lt a dh W B sonst fo V falls 2z gt b d h W BU B sonst fs V falls 21 lt c d h WEBUBUB sonst I d h We B U Bs U B U B 2 4 Grundkonstruktionen des Sprachkonzepts 43 Diese Art der Formulierung hat auf jeden Fall den Vorteil da eine
256. ne mobile Element einer angegebenen Menge steht 202 5 Systematische Darstellung der Modellbeschreibungssprache Diese Menge kann angegeben sein durch einen Indexbereich der durch konstante ganze Zahlen festgelegt wird oder die aktuell belegten Indices einer Location umfa t durch eine beschnittene Menge von Indices oder mobilen Elementen die auch eine Eigenschaftsmenge sein darf L t man die Angabe einer Eigenschaftsmenge zu k nnen mobile Elemente aus Locations selektiert werden Die Aussageformen die im Rumpf des Konstrukts stehen sind indiziert und gelten f r alle diese Indices foreach_statement FOREACH identifier IN range_or_set LET statement_sequence END range_or_set actual_index_range cutted_set actual_index_range constant_integer constant_integer IDXSET selected_location Jede gebundene Variable mu daf r verwendet werden um die im FOREACH Konstrukt eingeschlossenen Aussagen zu quantisieren d h sie mu die zu definierenden Variablen einer Wertzuweisung bzw die Elemente oder den Quellbestand einer Transportanweisung n her bestimmen F r den Fall geschachtelter FOREACH Konstrukte kann dies kann auch dadurch geschehen da eine gebundene Variable die Menge cutted_set eines eingeschlossenen FOREACH Konstrukts n her bestimmt Beispiel FOREACH i IN 1 N LET FOREACH J IN Queue il LET J gt Server END END Im Grunde wire es ausreichend n
257. nen lassen sich auf Attribute und Best nde mit gleichartigen Elementen in gleicher Weise anwenden Daneben liefert auch die zweistellige Operation identifier IN cutted_set Element aus Menge an der eine Menge mit unterscheidbaren Elementen beteiligt ist als Ergebnis einen logischen Wert F r den Vorrang bei der Verkn pfung der Operanden gelten die in der Mathematik blichen Reglen z B Punkt vor Strich Neben dem einstelligen Operator NOT haben vor allem auch die folgenden Operationen zur Abfrage von Mengeneigenschaften Bedeutung CARD set Kardinalit t EMPTY set Menge leer ALL ordered_property_set Menge vollst ndig ANY set Menge nicht leer 200 5 Systematische Darstellung der Modellbeschreibungssprache 5 3 3 Die Wertzuweisung Die Wertzuweisung ordnet einem Attribut oder der Ableitung eines Attributs in Form einer Definitionsgleichung einen Wert zu Dabei sind drei F lle zu unterscheiden 1 Einer abh ngigen Variablen wird der f r den aktuellen Zeitpunkt g ltige Wert durch eine Definitionsgleichung zugeordnet 2 F r eine Zustandsvariable wird beschrieben wie sie sich zum folgenden Zeitpunkt gegen ber dem aktuellen Zeitpunkt ver ndert a Ein diskreter Zustands bergang legt den Wert des Attribut f r den folgenden Zeitpunkt fest Der Name des Attributs wird hierzu mit einem H kchen ver sehen b Ein kontinuierlicher Zustands bergang wird durch die im aktuellen Zeitpunkt g ltige Steigung des F
258. ng aus der Welt schaffen lassen Dies hat den Vorteil da der m gliche Konflikt durch die Fallunterscheidung deutlich zu Tage tritt Beispiel IF T gt TNext LET Zz k 0 WHEN k 0 AND x lt 0 ELSE X END k k 1 MOD 5 TNext T 10 END Gem obiger Forderung enth lt die Modellbeschreibung nur eine einzige Definitionsglei chung f r das Feld z Es ist zwar nicht m glich die Einhaltung der Feldgrenzen zu gew hr leisten die Eindeutigkeit ist jedoch sichergestellt Zusammenfassung Besitzt eine zu definierende Variable einen Indexausdruck der eine Variable enth lt die keine gebundene Variable ist dann ist e keine berpr fung der Feldgrenzen durch den Compiler m glich e keine Vollst ndigkeit gew hrleistet e Eindeutigkeit nur gegeben wenn nicht gleichzeitig eine zweite Definitionsgleichung f r irgendein Feldelement dieser Variablen vorhanden ist Eine berpr fung der Feldgrenzen durch den Compiler ist nur m glich wenn e ein Indexausdruck au er einer gebundenen Variablen keine weiteren Variablen enth lt 3 4 Einf hrung von Feldern 95 Vereinfacht wird die Kontrolle der Feldgrenzen wenn ein Indexausdruck e nur eine einzige gebundene Variable enth lt e nur solche Operatoren enth lt die eine monotone Funktion erzeugen Die hier behandelten Einschr nkungen sind allgemeiner Natur Wir wollen nun untersuchen welche Konsequenzen dies f r die Verwendung von Definitionsgleichungen innerhalb eine
259. ngen das Erstellen von Simulationsprogrammen ganz erheblich zu vereinfachen Da bewu t auf schwierige Sprachkonstrukte wie Zeiger die eine hohe Fehleranf lligkeit beinhalten ver zichtet wurde ist es auch dem Nicht Informatiker m glich Modelle in der Sprache zu for mulieren Andererseits ist es sicher auch gelungen dem Anwender eine Modellbeschreibung als Do kumentation zu berlassen die dieser auch versteht und in der er seine Modellvorstellung wiederfindet Damit ist ein Anwender erstmals in der Lage mit anderen Fachkollegen ber ein Modell zu diskutieren ohne da irgendwelche Angaben fehlen oder unklar bleiben Die Modellbeschreibung ist stets vollst ndig und eindeutig und enth lt nicht mehr und nicht weniger Information als erforderlich Es bleibt die Frage wer denn die Modelle formuliert Ohne eine gewisse Ausbildung ist dies sicherlich nicht m glich Idealerweise w rde ein mathematisch vorgebildeter Anwender eine Zusatzausbildung erhalten und seine Modelle selbst formulieren Dies wird er aber nur tun wenn er selber Systemanalyse und Modellerstellung betreibt Solche Anwender sind in der Regel nur im Hochschulbereich zu finden Der andere Typ von Anwender der nur gelegentlich Simulationen durchf hrt ben tigt einen Partner der nach seinen Angaben das Modell formuliert Als Partner k nnte man sich einen Simulationstechniker vorstellen der Sprache und Methoden beherrscht und in der Lage ist sie in unterschiedli
260. ngssprache 5 1 Grundlegende Konzepte der Sprache 0 0000 pee 5 2 Deklaration in Basiskomponenten und mobilen Komponenten 5 3 Beschreibung der Modelldynamik in Basiskomponenten 5 3 1 Zugriff auf Modellvariablen 2 2 2 0 amp au a 2er RE 5 3 2 Die Formulierung von Ausdriicken 2 5 3 3 Die Wertzuweisung 22 e g dens area ae be 5 3 4 Transporte zwischen Best nden 2 2 a a a 5 3 0 Das IF Konstr kt oa e eui eaae gl e ED 5 3 6 Das FOREACH K Konstrukt ooa 2 8a me mar neh 5 3 7 Der implizite Allquantor 2 0 ooa au era 5 3 8 Beschneiden von geordneten Mengen oaoa a 5 3 9 Die Bildung von Eigenschaftsmengen ooa a 5 3 10 Verkn pfen von Best nden mit unterscheidbaren Elementen 5 4 H here Komponenten zu ge sr ee er tere 5 4 1 Vereinbarung der Subkomponenten 0 5 4 2 Einrichten einer Schnittstelle 2 2 2 22 5 4 3 Verbindungen zwischen Komponenten 2 22 2222 5 4 4 Initialisierung der Subkomponenten Spracherweiterungen f r den praktischen Einsatz 6 1 Anforderungen oh a RZ a ee a aE ale ce Be ak ce oe a 6 2 Aufz hlungsmengen ena hese erg ot gs ara tea PRY goede caused eh 6 3 Physikalische Ma einheiten 4 4 2440 6 bad eh we heran 6 4 Funktions und Prozeduraufrufe 0 2 2 2 00048 6 52 Zutallsyar ablense wa ce ads za be ee A a ee ee 6 6 Tabellarische Funktionen und Verteilungen
261. nisse die beide auf den gleichen Bestand zugreifen auf zwei verschiedene Komponenten zu verteilen Es gibt jedoch eine Methode mit der sich eine Modellzerlegung unter Beibehaltung der Eindeutigkeit erreichen l t Hierzu ist die Einf hrung von abh ngigen Variablen erforder lich die anzeigen wieviele Elemente gerade transportiert werden Diese Methode ist sehr anschaulich und l t sich bei Transporten zwischen Komponenten stets anwenden Sie hat jedoch den Nachteil da sie das Modell wesentlich umfangreicher macht Es sei N_QS Anzahl Elemente die sich von der Queue zum Server bewegen N_SR Anzahl Elemente die sich vom Server zum Reservoir bewegen N_RQ Anzahl Elemente die sich vom Reservoir zur Queue bewegen 132 4 Transporte zwischen Best nden Ohne eine Modularisierung vorzunehmen l t sich die Modelldynamik hiermit folgenderma Ben beschreiben Bewegung von Queue nach Server seco oo 2ooooooo oo moooooooooo IF NQ gt O AND NS 0 LET N_QS 1 TEntry T END ELSE LET N_QS 0 END Bewegung von Server nach Reservoir a EA IF NS gt 0O AND T gt TEntry TService LET N_SR 1 END ELSE LET N_SR 0 END a a a a a a oe ee a nenn IF T gt TGenera LET N_RQ 1 TGenera T TBetween END ELSE LET N_RQ 0 END Alle Bewegungen durchfuehren SSS eee a ea ae ee ee S NQ N_Q N RQ N_QS NS N_S N_QS N_SR NR N_R N_SR N_RQ Wie man sieht si
262. nn allerdings auch verzichtet werden da sich ihr Gebrauch in der Praxis als unbedeutend erweist Auch die im vorangegangenen Abschnitt besprochene Bildung von Eigenschaftsmengen ist nicht unbedingt erforderlich da die gleiche Funktionalit t mit Funktionsaufrufen erreicht werden kann Die Beschreibung durch Mengenbildung ist jedoch eleganter und der deklarative Teil der Sprache mu nicht verlassen werden 5 4 H here Komponenten Eine h here Komponente setzt sich aus untergeordneten Komponenten Subkomponenten zusammen Verbindungen zwischen Subkomponenten bestimmen die Struktur einer h heren Komponente und damit auch deren Verhalten Durch Vereinbarung eigener Variablen die aus Variablen von Subkomponenten abgeleitet werden kann eine Schnittstelle geschaffen werden die es erm glicht die Komponente selbst wiederum als Subkomponente einzusetzen Die in den Subkomponenten durchgef hrte Vorbesetzung kann in der h heren Komponente durch eine erneute Initialisierung berschrieben werden high_level_component HIGH LEVEL COMPONENT identifier subcomponent_declaration interface_declaration component_structure initialization END OF identifier 206 5 Systematische Darstellung der Modellbeschreibungssprache 5 4 1 Vereinbarung der Subkomponenten Eine h here Komponente setzt sich aus untergeordneten Komponenten Subkomponenten zusammen Die Subkomponenten sind Auspr gungen Instanzen Inkarnationen bereits de finier
263. nten 2 7 Algorithmus f r die Simulation einer modularen Modellbeschreibung 2 7 1 Der Grundalgorithmus f r modulare Modelle 2 2 2 2 2 7 2 Effizienzverbesserung durch statische Marken 2 7 3 Effizienzverbesserung durch dynamische Marken 2 85 Zusammenfassung y a 2 i eee Er aoe 4 ee DER Sa Sep ee Spracherweiterungen zur Formulierung von Warteschlangenmodellen ol Mo tiyation 5 are une Be ee ae ae ee ee 8 2 Anforderungen 4 Ss aa Sy en are ee ee 3 3 Einf hrung von Elementen mobilen Komponenten 2 2 2 ae a oe a ee ae 3 4 Einf hrung von Feldern 4 es sae 8 GIS na er Sie ORES Geel Meklarationnz 272 22 2 eat eae a ar ee 3 4 2 Verwendung von indizierten Variablen in Definitionsgleichungen 2 2a ws un aed Ie Krk ea geh 3 4 3 Formulierung von Definitionsgleichungen mit Algusnt ren na ai pda ee eae ae 2S 3 4 4 Semantisch korrekter Gebrauch von indizierten Variablen in Definiti onsgleichungen 1 u Sibi a a REN ER Re 3 4 5 Semantisch korrekter Gebrauch von Allquantoren 3 4 6 Impliziter Allquantor ana rer 3 5 Einf hrung von Indexmengen aaau aaa Re ee de we Kl aS we les 3 5 1 Bildung von nicht geordneten Indexmengen 3 5 2 Problematik beim Transport zwischen Warterdumen 3 5 3 Einf hrung geordneter Mengen 2 2 nn 3 5 4 Beschneiden von Mengen 200 0052 eee 3 5 5 Verbesserte Formulierung des Transports zwischen W
264. ntinuierlichen diskreten sowie mengen weisen Transport wurden diskutiert Ein eigenes Problem beim Transport ist der eindeutige Zugriff auf die Elemente bei Vertei lung Um diesen herzustellen wurden die f r die bestandsbezogene bzw transportbezogene Beschreibung erforderlichen Ma nahmen diskutiert Wie die Ausf hrungen in Kapitel 3 gezeigt haben erm glichen Best nde eine besonders geeignete Art der Modularisierung Auch hier wurde wieder die bestandsbezogene und die transportbezogene Beschreibung miteinander verglichen War es bisher nicht m glich der einen oder der anderen Beschreibungsform den Vorzug zu geben so erweist sich die transportbezogene Beschreibung bei Modularisierung der bestands bezogenen deutlich berlegen Aus diesem Grund wird die transportbezogene Beschreibung weiter verfeinert Durch eine gezielte Einschr nkung der Autonomie einer Komponente konnte erreicht werden da e die Best nde einer Komponente gegen Zugriffe von au en weitgehend gesch tzt sind und e auf h herer Ebene anhand der Verbindungen erkannt werden kann in welche Richtung ein Transport erfolgen kann Ein hierarchischer Modellaufbau erwies sich ebenfalls als m glich Um auch offene Modelle formulieren zu k nnen war es schlie lich notwendig Quellen und Senken als eigene Bestandstypen einzuf hren Zum Schlu wurde gezeigt da Modelldarstellungen mit System Dynamics der hier ein gef hrten Modellwelt sehr nahestehen und dahe
265. obile Komponente wird als Menge Verbund von Variablen vereinbart Sie darf dem nach auch Bestandsvariablen enthalten auf denen wiederum andere mobile Elemente plaziert sind Mobile Komponenten repr sentieren lediglich einen Zustand Sie enthalten keine Be schreibung ber dynamische Ver nderungen Eine Basiskomponente wird ebenfalls als Menge Verbund von Variablen vereinbart Da neben enth lt sie auch die Beschreibung f r das dynamische Verhalten ihrer eigenen Varia blen und f r das dynamische Verhalten von mobilen Komponenten auf Bestandsvariablen ber Sensorvariablen kann sich die Basiskomponente Werte von Variablen fremder Kompo nenten beschaffen und darauf reagieren Anders betrachtet k nnen fremde Komponenten ber Sensorvariablen auf das dynamische Verhalten einer Basiskomponente einwirken ber zug ngliche Best nde kann sich die Basiskomponente mobile Komponenten aus fremden Komponenten holen bzw dorthin bringen Zug ngliche Best nde k nnen mit Best nden fremder Komponenten zusammengelegt wer den Dadurch ist es m glich mobile Komponenten in eine fremde Komponente zu bringen bzw aus einer fremden Komponente zu holen Eine h here Komponente wird als Menge von Basiskomponenten und oder anderen h her en Komponenten vereinbart Einfl sse welche die Subkomponenten gegenseitig aufeinander aus ben d h das Lesen von internen Variablen durch Sensorvariablen werden durch Wirk pfeile festgelegt Transporte zwischen
266. odelle spielen Bilanzgleichungen und Gleichgewichtsbeziehungen aber keine Rolle Hier ist es in der Regel immer m glich eine explizite Modelldarstellung anzu geben Da wir uns hier in erster Linie mit der Beschreibung diskreter Modelle befassen wollen gehen wir im folgenden von der Voraussetzung aus da sich die Modellbeziehungen explizit darstellen lassen Diese Einschr nkung f hrt uns zum Konzept der systemtheoretischen Modellbeschreibung und erleichtert es uns ganz wesentlich die gestellten Anforderungen an die Modellbeschrei bungssprache zu erf llen 30 2 Sprachentwurf im Sinne der klassischen Systemtheorie 2 1 4 Die explizite Modelldarstellung der Systemtheorie Wenn wir in der Lage sind jede einzelne Modellgr e explizit auszudr cken ergibt sich f r jede Modellgr e eine Definitionsgleichung Je nachdem welche Art von Beziehung eine Gr e zum Ausdruck bringt unterscheidet man die Modellgr en v in Eingangsgr en z t Zustandsgr en ziltky1 fi X te Z t tk Ausgangsgr en y th gi X tk Z tk tk Der Operator dr ckt aus da die Variable auf der linken Seite durch den Ausdruck auf den rechten Seite zu jedem Zeitpunkt definiert wird Die Namensgebung beruht auf folgender Vorstellung Eingangsgr en sind Gr en auf die das System selbst keinen Einflu hat Man kann sie auch als unabh ngige Umgebungsgr en oder als Sensorgr en bezeichnen weil das
267. oduktbildung eine neue Einheit als Produkt gebildet Beispiel KEN Y muss ebenfalls die Einheit m besitzen X WV Besitzt V die Einheit m s dann resultiert aus der Division die Einheit s F r den Fall da zwei Einheiten zwar nicht identisch aber ineinander berf hrbar kom mensurabel sind mu die M glichkeit bestehen die Einheit eines Ausdrucks Teilausdrucks oder einer Variable in eine andere Einheit umzuwandeln Beispiel X V min Der Ausdruck mit der Einheit s wird in die Einheit min umgewandelt d h implizit durch 60 dividiert Bei Wertzuordnungen mu ebenfalls die Identit t der Einheiten hergestellt werden Dies kann explizit durch den Benutzer oder implizit durch den Compiler erfolgen da bekannt ist welche Einheit ben tigt wird Beispiel TWeg X V min Besitzt TWeg die Einheit min ist eine Anpassung der Einheit notwendig TWeg X V Implizite Anpassung Identit t der Einheiten ist ebenfalls erforderlich wenn Variablen aus verschiedenen Kompo nenten miteinander verbunden werden Beispiel A X gt B X Die Variable X aus Komponente B muss dieselben Einheiten besitzen wie Variable Y aus Komponente A Wenn Modelle aus Komponenten zusammengesetzt werden die von verschiedenen Benutzer erstellt wurden wirkt sich diese verbesserte Schnittstellenpr fung besonders positiv aus 6 4 Funktions und Prozeduraufrufe 217 6 4 Funktions und Prozeduraufrufe Zusammenh
268. onentiell verteil ten Zwischenankunftszeit TBetween betreten mobile Elemente die Warteschlange Queue Ist die Bedieneinheit Server frei wechselt das erste Element der Queue dorthin Es halt sich dann w hrend der konstanten Bedienzeit TService in der Bedieneinheit auf Danach verl t es den Server und wechselt in das Reservoir ber Die Elemente geh ren der Klasse Job an deren Datenstruktur vereinbart ist durch MOBILE COMPONENT Job DEFINITION VALUE SET Queues Reservoir Queue Server DECLARATIONS STATE VARIABLES Ort Queues Reservoir TEntry REAL 0 END OF Job Es existiere ein Vorrat von N 100 Elementen DIMENSION CONSTANT N 100 ARRAY 1 N Job Die Dynamik des Modells l t sich nun folgenderma en beschreiben FOREACH i IN 1 N LET Bewegung von Queue nach Server a ee a IF i IN j IN1 N Job j Ort Queue INC Job j TEntry 1 LET IF EMPTY j IN1 N Job j Ort Server LET Job i Ort Server Job i TEntry T END END 108 3 Spracherweiterungen zur Formulierung von Warteschlangenmodellen Bewegung von Server nach Reservoir SSS Se Se ee Se ee ee eee en ELSIF i IN j IN1 N Job j Ort Server LET IF T gt Jobli TEntry TService LET Job i Ort Reservoir Job i TEntry T END END Bewegung von Reservoir nach Queue See a Se ee ee ee ee eS eS ELSIF i IN j IN1 N Job j Ort Reservoi
269. orstellung davon machen kann in welcher Weise man in Zukunft Simulationstechnik zum Einsatz bringen m chte und welche Leistungsf higkeit gefordert wird sollen die gestellten Anforderungen im Rahmen dieser Einleitung abschlie end kurz umrissen werden Die Anforderungen der Anwender lassen sich in Anforderungen an die Funktionalit t und an die Ergonomie unterscheiden Diese beiden Anforderungskreise sind naturgem widerspr chlich Je benutzerfreundlicher ein Programm ist desto schwieriger ist es diesem auch einen universellen Funktionsum fang mitzugeben Andererseits ist es ebenso schwierig universelle Funktionalit t auch dem unge bten Anwender zur Verf gung zu stellen Die neuen Anforderungen an die Simulationstechnik Schm 88 resultieren aus der Notwen digkeit neuartige Produktionsanlagen modellieren zu m ssen und aus dem Wunsch durch eine komfortablere Software Umgebung auch dem fertigungstechnischen Planer die Simula tion zur Verf gung zu stellen Die Zielsetzung f r einen Einsatz der Simulation hingegen ist nach wie vor dieselbe Es soll untersucht werden auf welche Weise die geforderte Leistungsf higkeit einer Anlage bei geringsten Kosten erreicht werden kann Zu diesem Zweck werden alternative Konstruktionen untersucht die Dimensionierung der einzelnen Anlagenteile aufeinander abgestimmt und nach geeigneten Betriebsabl ufen und Strategien gesucht 1 5 1 Anforderungen an die Funktionalit t Planer vo
270. phischer Art an einer allgemeinen Akzeptanz mangelt es jedoch bislang Darstellungen aus theoretischen Abhandlungen beschr nken sich auf Modelle die sich ana lytisch behandeln lassen und sind daher nicht allgemein genug Darstellungen aus Simula tionssprachen GPSS SLAM SIMAN sind den Sprachkonzepten entsprechend proze orientiert und aus diesem Grund nicht brauchbar Diese Abhandlung will einen Weg aufzeigen den angef hrten Anforderungen gerecht zu werden Sie stellt den Versuch dar das im Bereich der kontinuierlichen Modelle so erfolgrei che Konzept der zustandsorientierten Modellbeschreibung auch auf die Welt der diskreten Warteschlangen und Transportmodelle zu bertragen Dieses Bem hen beide Welten zu vereinheitlichen ist aus verschiedenen Gr nden reizvoll In vielen Anwendungsgebieten entstehen auf unterschiedlichen Abstraktionsstufen diskrete bzw kontinuierliche Modelle Mikroskopische Modelle sind oft diskreter Natur wenn die Wechselwirkungen einzelner Individuen betrachtet werden Abstrahiert man von diesem in dividuellen Verhalten erh lt man meist kontinuierliche makroskopische Modelle z B kine tische Gastheorie Umgekehrt kann auch das mikroskopische Verhalten kontinuierlicher und das makroskopische Verhalten diskreter Natur sein z B Digitalrechner Eine einheitliche Beschreibungsform erleichert sicherlich das Umdenken zwischen diesen Mo dellformen Aber auch eine Kombination diskreter und kontin
271. ponente auch durch Gleichsetzung mit einem Zusammenschlu mehrerer verteilter Fingangsbest nde DENTRY vereinbart werden Einen verteilbaren Eingangsbestand DENTRY f r eine h here Komponente erh lt man durch Gleichsetzung mit einem verteilten oder nicht verteilten Eingangsbestand einer Sub komponente oder durch Gleichsetzung mit einem Zusammenschlu mehrerer verteilter Ein gangsbest nde DENTRY dentry_location_declaration identifier gt dentry_location identifier gt dentry_fusion Einen Ausgangsbestand f r eine h here Komponente erh lt man durch Gleichsetzung mit einem Ausgangsbestand einer Subkomponente oder durch Gleichsetzung mit einem Zusam menschlu mehrerer Ausgangsbest nde 208 5 Systematische Darstellung der Modellbeschreibungssprache exit_location_declaration identifier lt exit_location identifier lt exit_fusion exit_fusion exit_location exit_location exit_location Einen Durchgangsbestand f r eine h here Komponente erh lt man durch Gleichsetzung mit einem Durchgangsbestand einer Subkomponente oder durch Gleichsetzung mit einer Trans portverbindung zwischen Subkomponenten transit_location_declaration PS identifier lt gt transit_fusion identifier lt gt transport_connection transit_fusion transit_location transit_location lt gt transi
272. r 1 LET IF T gt TGenera LET Job i Ort Queue Jobli TEntry T TGenera T TBetween END END END Die vorliegende Modellbeschreibung gen gt unseren Anforderungen an die semantische Kor rektheit Insbesondere ist durch die Verwendung des IF ELSIF Konstrukts die Eindeutigkeit der Wertzuordnungen gew hrleistet Eine sinnvolle Modularisierung w re sicherlich die Beschreibungen f r die drei Transpor te in separaten Komponenten unterzubringen Zu diesem Zweck mu allerdings die obige geschachtelte Sprachkonstruktion zerlegt werden Damit erlangt die Modellbeschreibung folgendes Aussehen Bewegung von Queue nach Server Sons oe Se a Se a FOREACH i IN 1 N LET IF i IN j IN1 N Job j Ort Queue INC Job j TEntry 1 LET IF EMPTY j IN1 N Joblj Ort Server LET Job i Ort Server Jobli TEntry T END END END 3 5 Einf hrung von Indexmengen 109 Bewegung von Server nach Reservoir i a a a a a a a te Re EEE a a ER ERERTER FOREACH i IN 1 N LET IF i IN j IN1 N Job j Ort Server LET IF T gt Jobli TEntry TService LET Job i Ort Reservoir Jobli TEntry T END END END Bewegung von Reservoir nach Queue a a a a a a a a a a a a a a a nn a a u FOREACH i IN 1 N LET IF i IN j IN 1 N Job j Ort Reservoir 1 LET IF T gt TGenera LET Job i Ort Queue Jobli TEntry
273. r 73 INGER 85 Kaehl 86 KerRit 83 Kett 83 Kett 88 Literaturverzeichnis Eschenbacher Peter Entwurf und Implementierung einer formalen Sprache zur Beschreibung dynamischer Modelle Arbeitsberichte des Instituts f r Mathematische Maschinen und Datenverarbeitung der Universit t Erlangen N rnberg Dissertation Band 23 Nummer 1 Erlangen 1990 Eschenbacher Peter Die Modellbeschreibungssprache SIMPLEX MDL in Referenzhandbuch des Simulationssystems SIMPLEX II erschienen im Selbstverlag c SIEMENS AG Institut f r Mathematische Maschinen und Datenverarbeitung der Universit t Erlangen N rnberg Erlangen 1991 Eschenbacher P Wittmann J Methodische Vorgehensweise bei der Durchf hrung von Simulationsstudien Skript Teil B zur Vorlesung Simulation Iim WS 89 90 Forrester Jay W Grundziige einer Systemtheorie Gabler Verlag Wiesbaden 1972 Forrester Jay W Der teuflische Regelkreis Deutsche Verlagsanstalt Stuttgart 1972 Forrester Jay W World Dynamics Wright Allen Press Cambridge MA 1973 INGERSOLL Engineers Hrsg Flexible Fertigungssysteme Der FFS Report der INGERSOLL ENGINEERS Springer Verlag Berlin 1985 Kaehler T Patterson D A Taste of Smalltalk Norton New York 1986 Kernighan B Ritchie D Programmieren in C Carl Hanser Verlag Miinchen 1983 Kettenis D L The COSMOS Modelling and Simulation Language in Ameling W Hrsg Proceedings of t
274. r Feldgrenzen und ist beispielsweise dann erf llt wenn nur die Operatoren und zugelassen werden Unter der Voraussetzung da nicht eine Variable durch zwei oder mehrere Definitionsglei chungen beschrieben wird ist die Eindeutigkeit hergestellt Bereits im letzten Abschnitt wurde festgestellt da pro Bezeichner nur eine einzige Definiti onsgleichung angegeben werden darf wenn der Index eine Variable enth lt Es k nnte sonst zu berschneidungen der Indices und damit zu einer Verletzung der Eindeutigkeit kommen 96 3 Spracherweiterungen zur Formulierung von Warteschlangenmodellen Auch mit gebundenen Variablen innerhalb eines FOREACH Konstrukts k nnen Schwierig keiten dieser Art entstehen Beispiel FOREACH i IN 1 5 LET X 2 i f Belegung bei geradem Index X 2 i 1 1 Belegung bei ungeradem Index END In diesem Beispiel kommt es noch zu keinem Widerspruch w hrend es im folgenden Beispiel zu einer berschneidung von Indices kommen kann Beispiel FOREACH i IN 1 9 Das Feld X soll durch eine Folge LET von Ereignissen aufsteigend IF X i gt X i 1 sortiert werden LET X i X i 1 X i 1 X i END END Beim Sortieren der Teilfolge X 1 3 X 2 2 X 3 1 wird der Variablen X 2 sowohl der Wert 3 f r i 1 als auch der Wert 1 f r i 2 zugeordnet Diese m glichen berschneidungen lassen sich nur feststellen wenn der Compiler eine Liste aller auftretenden Indices anlegt Dieser Aufw
275. r Gabeln LET State TActEnd Thinking T TThink I m RightHand gt RightSide LeftHand gt LeftSide 1 END END OF Philosopher BASIC COMPONENT Table DECLARATION TRANSIT LOCATION ARRAY 1 5 Place INT 1 END OF Table 232 7 Anwendungen HIGH LEVEL COMPONENT System SUBCOMPONENTS ARRAY 1 5 Philosopher Table STRUCTURE TRANSPORT CONNECTIONS Philosopher 1 RightSide lt gt Table Place 2 lt gt Philosopher 2 LeftSide Philosopher 2 RightSide lt gt Table Place 3 lt gt Philosopher 3 LeftSide Philosopher 3 RightSide lt gt Table Place 4 lt gt Philosopher 4 LeftSide Philosopher 4 RightSide lt gt Table Place 5 lt gt Philosopher 5 LeftSide Philosopher 5 RightSide lt gt Table Place 1 lt gt Philosopher 1 LeftSide INITIAL CONDITIONS Philospher 1 TActEnd Philospher 2 TActEnd Philospher 3 TActEnd Philospher 4 TActEnd Philospher 5 TActEnd Unterschiedliches Ende der Anfangsaktivitaet we we we oP WN Hr we END OF System 7 3 Das Modell Bodenfeuchte Das Modell Bodenfeuchte ist ein Beispiel fiir die Modellierung mit Bestandsgr en bei kon tinuierlichen Vorg ngen Es beschreibt den Wasserhaushalt in einem Wald Boss 85 May89 Regen der auf einen Wald f llt landet zun chst auf dem Laub der B ume und f llt erst dann zur Erde wenn sich auf dem Laub bereits eine gew
276. r Variablen zu vermerken auf welche anderen Komponenten bzw Variablen sie Einflu aus bt Dazu legt man f r jede Variable eine Auswirkungsliste an Sie enth lt f r jeden Pfad im Abh ngigkeitsgraphen der von der betreffenden Variable ausgeht ein Listenelement In je dem Listenelement befindet sich je ein Zeiger auf einen Eintrag im Bitfeld B und auf die Marke Flag der Variable Der Eintrag Level gibt die Gruppenzugeh rigkeit einer Variablen an Variable EffList u Zeiger auf Zeiger auf Zeiger auf ae oe EffList Bitfeldeintrag Variablenflag BACH eres Element Y NULL Bitfeld m Variable Zeiger auf Wert Level Flag EffList 2 Nach der Wert nderung einer Variablen werden f r jedes Element der Auswirkungsliste die Marken gesetzt Erstes Listenelement EffEntry lt Variable gt EffList Besetzung des Bitfeldes EffEntry gt Zeiger_BitFeld TRUE Besetzung des Variablenflags EffEntry gt Zeiger_VarFlag TRUE N chstes Listenelement EffEntry EffEntry gt Zeiger_EffList 78 2 Sprachentwurf im Sinne der klassischen Systemtheorie Es f llt auf da das Setzen der Marken nahezu keine Rechenzeit in Anspruch nimmt Da gegen erfordert die Auswirkungsliste und die Vorbesetzung der Auswirkungsliste einigen Speicherplatz Dies stellt jedoch bei den heutzutage sehr geringen Kosten im allgemeinen kein Prob
277. r anzugebenden Zeitfunktion Da nicht angeschlossene Sensorvariablen in den meisten F llen mit einem konstanten Wert belegt werden bietet es sich an f r Sensorvariablen ebenso wie f r Zustandsvariablen eine Initialisierung bei ihrer Deklaration zu verlangen Die Angabe der Zeitfunktion kann dann optional erfolgen Die Anfangswerte der angeschlossenen Sensorvariablen sind durch die Verbindung mit einer Zustandsvariablen oder abh ngigen Variablen festgelegt Die Werte der abh ngigen Variablen im Anfangszeitpunkt lassen sich durch die zugeh rigen Definitionsgleichungen vollst ndig aus den Initialwerten der Zustandsvariablen der Sensor variablen sowie anderer abh ngiger Variablen berechnen 2 4 Grundkonstruktionen des Sprachkonzepts 49 2 4 4 Aufbau einer Basiskomponente Entsprechend der vorgestellten Aufteilung wird ein Modell bzw im Vorgriff auf sp ter eine Modellkomponente strukturiert basic_component BASIC COMPONENT identifier DEFINITION S value_set_definitions unit_definitions function_definitions DECLARATION S variable_declaration_part DYNAMIC BEHAVIOUR statement_sequence END OF identifier Der Abschnitt mit Definitionen ist optional und dient der Vereinbarung von Aufz hlungsmen gen benutzereigenen Ma einheiten sowie von tabellarischen und algorithmischen Funktionen siehe Kapitel 6 50 2 Sprachentwurf im Sinne der klassischen Systemtheorie 2 5 Algorithmus f r die Simulation einer expliziten Mo
278. r ein guter Ausgangspunkt f r weitere Be trachtungen sind um eine formal sprachliche Modellbeschreibung vollst ndig auch graphisch beschreiben zu k nnen Wegen methodologischer Unsicherheiten wurde dieses an sich sehr wichtige Thema jedoch nur andeutungsweise behandelt 189 Kapitel 5 Systematische Darstellung der Modellbeschreibungssprache In den beiden letzten Kapiteln wurden eine Reihe von m glichen Spracherweiterungen be sprochen um Warteschlangen und Transportmodelle mit Hilfe des zustandsorientierten An satzes beschreiben zu k nnen Dabei sollten die verschiedenen Gesichtspunkte deutlich werden die f r einen Sprachent wurf bedeutsam sind Es wurden unterschiedliche Konzepte und Konstrukte diskutiert und miteinander verglichen Als Ergebnis dieser Betrachtungen wird nun in diesem Kapitel eine vollst ndige Modellbeschreibungssprache vorgeschlagen Wegen des gro en Umfangs und um die wesentlichen Aspekte nicht in Details verschwinden zu lassen wird die Syntax und Semantik nicht in allen Einzelheiten beschrieben Die Teile der Sprachsyntax die keinen Bezug zu den bisherigen Ausf hrungen haben werden nur angedeutet Eine kurze Abhandlung ber diese Teile der Sprache findet sich in Kapitel 6 Die Semantik wird angegeben soweit sie sich nicht von selbst erkl rt Das Sprachkonzept ist so gestaltet da der Sprachumfang bersichtlich bleibt die universelle Einsetzbarkeit gew hrleistet ist keine kompliziert
279. r in gew hn lichen Programmiersprachen zur Verf gung gestellt wird Deklaration lokaler Variablen Wertzuweisungen Fallunterscheidungen Schleifen e Besonderes angenehm f r den Anwender ist es da er Locations als Eingabeparame ter bergeben kann und die ihm bereits vertrauten dieselben Zugriffm glichkeiten auf mobile Elemente und deren Attribute hat Auch wenn dieser Aufwand sehr hoch erscheint er erm glicht es auf der anderen Seite den Sprachumfang im deklarativen Teil in Grenzen zu halten Anderfalls m te die deklarative Sprache f r Spezialf lle wie f r das gezeigte Beispiel jedesmal entsprechend erweitert werden Selten ben tigte Sprachkonstrukte werden so vermieden und die Universalit t der Sprache gew hrleistet Die Schnittstelle wurde so gehalten da ein Unterprogrammaufruf frei ist von jeglichen Seiteneffekten Dies l t sich insbesondere deshalb erreichen weil die Sprache keine globalen Variablen kennt Alle ben tigten Parameter sind in der Parameterliste zu bergeben 6 5 Zufallsvariablen Der bergang einer Zustandsvariablen auf einen neuen Wert Zustands bergang kann mit Sicherheit deterministisch stattfinden oder aber mit einer gewissen Wahrscheinlichkeit sto chastisch erfolgen Dabei kann a die Zeitdauer in der ein Zustand verweilt und oder b die folgende Auspr gung Wert der Zustandsvariable zufallsabh ngig sein Zeitdauer Auspr gung Zustand B t Zustand A t
280. rfinden um mit diesen intuitiv Modelle aufzubauen und zu experimentieren Arbeitspl ne Entscheidungsta bellen und was sonst alles n tig ist sollte in gewohnter Form eingegeben werden k nnen Hinter diesen konkreten W nschen nach Anschaulichkeit stehen letztendlich die verst ndli chen Forderungen nach kurzer Einarbeitungszeit z giger und sicherer Bedienung schnellem Reaktivieren des abgelegten Wissens rechtzeitiger und verst ndlicher Information ber fehlerhafte Bedienung Da abzusehen war da die Modelle wom glich sehr umfangreich werden k nnen war von Anfang an auch auf eine effiziente Ausf hrung der Simulationsl ufe zu achten Auf Seiten der Betriebsleitung entstand die Wunschvorstellung eine gesamte Fabrik zu si mulieren um sich mehr Transparenz ber die Abl ufe in ihrer Firma verschaffen zu k nnen Anders als in der Vergangenheit wirken sich St rungen im geplanten Ablauf bei modernen Konzepten wie just in time viel schneller und intensiver auf die nachfolgenden Abteilungen aus Auch wenn das Ziel der Fabriksimulation etwas utopisch erscheint so hat es doch insofern seine Berechtigung da es m glich sein sollte die Teilmodelle eines Betriebs miteinander zu verbinden 22 1 Einleitung Hierzu sollten alle Modelle in einer gemeinsamen Umgebung laufen und auf der gleichen Basis beruhen Teilmodelle sollten auf verschiedenen Abstraktionsstufen modellierbar und gegeneinander austauschbar sein
281. rogrammierung ist es aber nicht unser Anliegen ein Sprachkonzept zu entwerfen das nur softwaretechnisch sichere L sungen zul t Die Modell beschreibungssprache will vielmehr vorgefundene Gegebenheiten nachbilden und die damit verbundenen Probleme deutlich werden lassen BASIC COMPONENT Philosopher DEFINITIONS VALUE SET PhilStates Thinking GetLeft GetRight Eating DECLARATIONS STATE VARIABLES State PhilStates Thinking aktueller Zustand TActEnd REAL 0 Ende einer Aktivitaet RANDOM VARIABLES TGetFork REAL UNIFORM LowLimit 0 1 UpLimit 1 TEat REAL EXPO Mean 100 TThink REAL EXPO Mean 500 PRIVATE LOCATION LeftHand INT 0 RightHand INT 0 TRANSIT LOCATION LeftSide INT 0 RightSide INT 0 7 2 Das Fiinf Philosophen Problem 231 DYNAMIC BEHAVIOUR IF State Thinking AND T gt TActEnd Aufnehmen der linken Gabel LET IF CARD LeftSide gt 0 LET State GetLeft TActEnd T TGetFork LeftSide gt LeftHand 1 END END ELSIF State GetLeft AND T gt TActEnd Aufnehmen der rechten Gabel LET IF CARD RightSide gt 0 LET State GetRight TActEnd T TGetFork RightSide gt RightHand 1 END END ELSIF State GetRight AND T gt TActEnd Essen LET State Eating TActEnd T TEat END ELSIF State Eating AND T gt TActEnd Ablegen de
282. rschlag Regen Feuchtigkeit auf Laub FLaub Verdunstung Abtropfen und Versickern Ab im Ah Horizont Verdunstung Feuchtigkeit in der FHumus FHumus Humusschicht FBaum Versickern in Aufnahme B Horizont durch Wurzeln orizon SBH bzw kapillarer Aufstieg Feuchtigkeit in der unteren FBHori Transpiration Tr Bodenschicht Versickern im Boden j fe F E N QS Abb 7 3 1 Modell Bodenfeuchte in System Dynamics Darstellung 234 BASIC COMPONENT Wasser DECLARATIONS PRIVATE LOCATIONS FLaub REAL FBHori REAL TRANSIT LOCATION FHumus REAL SOURCE LOCATION Wolken REAL 7 Anwendungen SINK LOCATION Atmosphaere REAL Grundwasser REAL DYNAMIC BEHAVIOUR Wolken gt FLaub HEP ee i FLaub gt Atmosphaere 2 FLaub gt FHumus TS ek 8 FHumus gt Atmosphaere aay i FHumus gt FBHori wee FBHori gt Grundwasser ieee 3 END OF Wasser BASIC COMPONENT Baum DECLARATION PRIVATE LOCATION FBaum REAL DENTRY LOCATION FHumus REAL SINK LOCATION Atmosphaere REAL DYNAMIC BEHAVIOUR FHumus gt FBaum sae 3 FBaum gt Atmosphaere Be 5 END OF Baum Niederschlagsmenge pro Zeit Verdunstung auf Blaettern Interzeption Abtropfen und Versickern in Humusschicht Bodenverdunstung Versickern in B Horizont bzw kapillarer Aufstieg in
283. rt einer Variablen wird nur dann neu bestimmt wenn eine der Variablen von der diese abh ngt markiert ist Auf eine geeignete Vorbesetzung der Marken sowie auf das R cksetzen an passender Stelle ist zu achten Die Sortierung der statischen Beziehungen ist nach wie vor erforderlich Beispiel Vorw rts Verfolgung Der Algorithmus mit Marken zur schnittsweise etwa so aus Vorw rts Verfolgung sieht f r obiges Beispiel aus 1 Vorbesetzung z_i Flag FALSE fuer alle i aus 1 NZ y_i Flag TRUE fuer alle i aus 1 NY z _i Flag TRUE fuer alle i aus 1 NZ 3 Falls y_2 Flag dann y_2 Value g_2 z_2 y_2 Flag FALSE Bei Wertaenderung dann y_l Flag TRUE y_3 Flag TRUE ende ende Falls y_1 Flag dann y_1 Value g 1 z_1 y_2 y_1 Flag FALSE Bei Wertaenderung dann y_4 Flag TRUE z_1l Flag TRUE ende ende 4 Falls z_1 Flag dann z_1 Value f_1 y_1 y_4 t z_1 Flag FALSE Bei Wertaenderung dann z_1 Flag TRUE ende ende 2 5 Algorithmus f r die Simulation einer expliziten Modelldarstellung 6a t t e Falls realer Zeitfortschritt dann z_1 Flag TRUE 6b Falls z_1 Flag dann ende Falls z_2 Flag dann ende Falls z_3 Flag dann ende ende z_1 z_1 z_1 Flag FALSE y_1 Flag TRUE y_3 Flag TRUE 2 2 2 27 z_2 Flag FALSE y_2 Flag TRUE z_3 Flag TRUE N wo Il N w gt z_3 Flag FALSE z_3 Flag TRUE 5
284. rte Vorw rts und R ckw rts Verfolgung Von Interesse ist aber eine Kombination der beiden Verfahren Durch Vorw rts Verfolgung wird markiert auf welche Komponenten die Ver nderung einer Variablen Einflu hat Durch R ckw rts Verfolgung wird innerhalb einer Komponente festgestellt ob eine Bestimmungs gleichung auszuf hren ist Gegen ber der reinen Vorw rts Verfolgung verk rzen sich die Abh ngigkeitslisten ganz ent scheidend Variable EffList eier Zeiger auf Zeiger auf nn _ EffList Bitfeldeintrag Ds 7 Element T NULL 4 Bitfeld m gt 80 2 Sprachentwurf im Sinne der klassischen Systemtheorie Bisher mu te f r jede Auswirkung auf eine andere Variable d h f r jeden Pfad im Abh ngig keitsgraphen ein Listenelement angelegt werden Nun mu nur noch f r eine Auswirkung auf eine andere Komponente Gruppe ein Listenelement angelegt werden Viele Variablen besit zen dadurch berhaupt keine Abh ngigkeitsliste mehr F r Auswirkungen auf die aktuelle Komponente Gruppe ist kein Eintrag mehr erforderlich Mehrere Auswirkungen auf die gleiche Komponente Gruppe k nnen in einem gemeinsamen Listenelement zusammengefa t werden Die Berechnung der abh ngigen Variablen gestaltet sich demnach wie folgt 3 Alle abhaengigen Variablen y_i berechnen Fuer alle i aus 1 NY_j Falls Ebene m y_ i j Level Falls x_ p1 j
285. rteschlangen und Bedienstationen aufhalten Da in einem Modell eine ganze Vielzahl solcher Elemente enthalten sind und jedes dieser Ele mente das gleiche dynamische Verhalten zeigt f hrten wir Felder ein um viele Auspr gungen eines Elements zu erzeugen Definitionsgleichungen welche die Belegung der Attribute bestimmen sollen nunmehr auch f r eine gr ere Anzahl von Feldindices gelten k nnen Wir betteten dazu Definitionsglei chungen in das FOREACH Konstrukt ein welches eine Art Allquantor darstellt Es stellte sich heraus da die Gew hrleistung der Eindeutigkeit und Vollst ndigkeit im Zusammenhang mit Feldern neue Betrachtungen erfordert Werden als Index Modellvariablen 128 3 Spracherweiterungen zur Formulierung von Warteschlangenmodellen oder Ausdr cke verwendet dann ist die semantische Korrektheit eines Modells gef hrdet Durch geeignete Einschr nkungen lassen sich diese Probleme l sen Mit diesen naheliegenden sprachlichen Erweiterungen wurde nun versucht Teile von War teschlangenmodellen zu formulieren Es stellte sich heraus da f r die Entnahme von Ele menten aus Warteschlangen die Bildung von geordneten Mengen erforderlich ist wenn man den dazu erforderlichen Aufwand in Grenzen halten will W hrend es nun zufriedenstellend m glich war Warteschlangenmodelle zu formulieren er wies sich die Modularisierung solcher Modelle als unzul nglich Durch die Einf hrung von Mengenvariablen deren Namen auch an an
286. ruppe berechnet werden In diesem Fall mu das Unterprogramm der Komponente mehrfach betreten werden Beispiel R ckwirkung Gruppe 0 2 2 n a K2 212 p Ge Ti 3 Gruppe 0 Hier besteht die optimale Bearbeitung darin zun chst die abh ngige Variable yj in Gruppe 1 zu berechnen daraufhin alle abh ngigen Variablen der Komponente 1 in Gruppe 2 und schlie lich yoo und y3 in Gruppe 3 Die Variable yoo h tte auch in Gruppe 1 berechnet werden k nnen Es sind drei Komponentenaufrufe n tig Beispiel Wechselwirkung Gruppe 0 1 2 2 Bl m mw a N JD RORO OLE 1 2 2 Gruppe 0 Hier besteht die optimale Bearbeitung darin zun chst die abh ngigen Variablen y und y 2 in Gruppe 1 zu berechnen und daraufhin alle brigen abh ngigen Variablen in Gruppe 2 In diesem Fall braucht man vier Komponentenaufrufe Wie man sieht kann man durch eine geeignete Gruppierung die Anzahl der ben tigten Komponentenaufrufe erheblich reduzieren 2 7 Algorithmus f r die Simulation einer modularen Modellbeschreibung 75 Die Abwicklung zur Laufzeit erfolgt mit Hilfe des bereits angegebenen Algorithmus Nur tritt an die Stelle der Schleife ber alle Ebenen eine Schleife ber alle Gruppen Bei der Vergabe der Gruppennummer sind zwei Gesichtspunkte zu beachten 1 Angeschlossene Sensorvariablen erhal
287. s FOREACH Konstrukts nach sich zieht 3 4 5 Semantisch korrekter Gebrauch von Allquantoren Zun chst l t sich feststellen da es keinen Sinn ergibt im FOREACH Statement Modell variablen zu definieren ohne die gebundenen Variablen im Index zu verwenden Beispiel FOREACH i IN 1 10 LET A 10 Ausfuehrung ineffizient B Yli Belegung von B widerspruechlich XLi Y i korrekte Verwendung END Eine solche Formulierung ist nicht nur in der Ausf hrung ineffizient sie wird auch wider spr chlich wenn der zugewiesene Ausdruck den iterierten Index enth lt Es ist daher zu fordern da Variablen die definiert werden alle gebundenen Variablen in ihren Indices ver wenden Das folgende Beispiel zeigt da diese Forderung jedoch noch nicht ganz ausreichend ist Beispiel FOREACH i IN 1 10 j IN 1 5 LET U i j Z i j Indices treten mehrfach auf X i j MOD 2 zZ i j Indices treten mehrfach auf Y i j Z i j korrekte Verwendung END Es zeigt sich da offensichtich in einer Reihe von F llen Indices mehrfach auftreten k nnen Um die Eindeutigkeit zu sichern ist deshalb durch geeignete Einschr nkungen Sorge zu tragen da jedes Feldelement nur ein einziges Mal definiert wird Wir verlangen daher da jeder Index nur eine einzige gebundene Variable enthalten darf und der Indexausdruck eine monotone Funktion sein mu Wie bereits erw hnt erleichert die letzte Forderung auch die berwachung de
288. s and inefficient during execution Therefore useful limitations are discussed which do not deminish the field of application but lead to much simplicity and efficiency So far in the field of simulation there are few discussions concerning the topic of model specification which can be referenced To be able to better follow the chain of reasoning the material was explained in an inductive rather than deductive way which is not very common in scientific dissertations For a better understanding and as a basis for further studies of the topic this procedure seems to be the more appropriate I believe that the considerations presented in this book are of interest beyond accomplishing the solution of simulation problems In many cases they deal with problems which certainly occur in a similar way when other aspects of reality have to be described The concept of the language itsself could also give impulse to language design in other disciplines within computer science This concept seems to be transferable especially in the fields of control technique und process automation This book certainly did not appear in this form without the contributions of my two colleagues Jochen Wittmann and Thomas Apsel A cordial thankyou to both of them Just as much I thank Prof B Schmidt who initiated this work Prof F Hofmann who contributed many tips and advices as well as Prof H Wedekind and Prof W Ameling who evaluated this book together with t
289. s qu auparavant En d pit des simplifications d utilisation il est n cessaire si possible pour l utilisateur de d crire des parties de modeles dans un langage formel afin de g n rer du code utilisable En se basant sur une nouvelle approche les possibilit s de description des systemes d attente et des parties de systemes a l aide d un langage formel seront discut es Ceci a t justifie dans ce livre par le fait qu aucun des langages de simulation existants permettaient la d composition modulaire des modeles discrets mais aussi par le fait que la theorie des systemes montrait que pour les mod les continus la mod lisation pouvait tre pratiqu e plus simplement L objectif envisag tait de transf rer les avantages d une id e th orique sur des mod les discrets surtout les mod les d attente Mais cette voie se montra longue et difficile Surtout il tait vident qu en principe les moyens originaux des syst mes th oriques mettent en mesure la description des syst mes d attente mais ne permettent pas une approche modulaire de d composition comme il avait t esp r Pour cette raison il tait n cessaire de s int resser d abord la fondation th orique et m thodologique pour d crire et simuler les syst mes d attente en utilisant l apport d un paradigme th orique des syst mes En plus il devenait apparent que le point de vue tait orient sur les langages de simulation tradit
290. s f r eine deklarative Sprache zur Beschreibung von Modellen die nen kann und die Wesensz ge und Vorteile einer solchen Sprache herausarbeiten Um ein tieferes Verst ndnis zu erzielen wird auch eine konkrete Sprachsyntax vorgestellt damit sich der Leser anhand von Beispielen mit der Materie auseinandersetzen kann Die ser Sprachentwurf wird dann in den folgenden Kapiteln weiterentwickelt um dem Ziel Warteschlangen und Transportmodelle zu formulieren n herzukommen 2 1 Systemtheoretische Modellbeschreibung 2 1 1 Die zustands orientierte Sichtweise Von einem Simulationsprogramm erwartet man da es innerhalb einer gewissen Genauig keit Beobachtungen erm glicht die denen am realen System entsprechen Jede Modellbildung st tzt sich daher direkt oder indirekt bei Anwendung einer Theorie auf Beobachtungsdaten die an einem realen System durch Experimente gewonnen wurden Ein Modell mathematisch formal zu beschreiben spezifizieren hei t Zusammenh nge Ge setzm igkeiten zwischen diesen Daten herauszufinden die stets d h zu jedem beliebigen Zeitpunkt G ltigkeit besitzen Bei gleichen Anfangsbedingungen kann dann ein Simulati onsprogramm unter Anwendung dieser Gesetzm igkeiten diese Daten reproduzieren W hrend wir ein Experiment durchf hren beobachten wir unser zu untersuchendes System an vorher ausgesuchten wohl berlesten Stellen Uber eine gewisse Zeit hinweg zeichnen wir an jedem Beobachtungsort ein
291. s with the problem how the description of continuous and discrete processes can be unified Here in this book those supplements of the language con cept are described which make a formulation of queuing and transport systems possible Knowledge of the dissertation is not required for everything that is needed will be found in this book as well iv In the center of the explanations there are the peculiarities of describing in a declarative way The declarative description claims to be complete and free of contradiction These two criteria which should be observed and controlled by the compiler together with the demand for modular model decomposition determine the language design considerably To master large models to re use parts of models and to work at the same project in a team model decomposition is important and cannot be relinquished However it must be pointed out that this claim conflicts with other aspects definiteness and autonomy and therefore a compromise solution carefully must be worked out The syntactic notation of the designed language is completely explained The theoretic ex planations become clearer to the reader and the examples can be wholly understood It turns out that a proper syntax can support some of the requirements given to the language Theoretic studies tend to admit general formulations as far as imaginable Despite of the fact that complex formulations are seldom used the implementation becomes voluminou
292. schaftsgr e wie wir sie bisher kennengelernt haben ist dadurch bestimmt da ihr aus einer vorgegebenen Wertemenge ein spezieller Wert eindeutig zugeordnet wird Jeder Wert aus der Wertemenge hingegen kann einer mehreren oder auch gar keiner Eigenschafts gr e also einer Menge von Eigenschaftsgr en zugeordnet sein Eine Bestandsgr e ist dadurch bestimmt da ihr aus einer Gesamtmenge eine Teilmen ge von einzelnen Elementen zugeordnet wird Umgekehrt l t sich jedes einzelne Element eindeutig einer Bestandsgr e zuordnen W hrend eine Eigenschaftsgr e lediglich einen einzigen Wert annimmt kann eine Bestands gr e mehrere Elemente aufnehmen Eine Eigenschaftsgr e wird daher von einer Wertva riablen eine Bestandsgr e von einer Mengenvariablen repr sentiert Die Definition einer Eigenschaftsgr e ist eine injektive die Definition einer Bestandsgr e hingegen eine surjek tive Abbildung Auch die Begriffe Qualit t f r Eigenschaftsgr e und Quantit t f r Bestandsgr e machen die Unterschiede deutlich 138 4 Transporte zwischen Best nden Elemente mit Wertevorrat Eigenschaftsvariablen Bestandsvariablen A gt a Zu 3 59 m E TE A I a 2 y Tr b ee B I Cc 2 q a do ee e 2 df la Es _ Ba g JA oy 2 I h 2 I i 2 B J 2 ge a a a T3 k S Es _ 7 SEEN Die Eigenschaftsvariablen x y sind zu Elementen FE zusammenfa t Eigen
293. schaftsvariable z a Injektion Bestandsvariable Ba E gt E3 Surjektion F r den Fall da eine Bestandsgr e lediglich die Anzahl von Elementen eines Bestandes repr sentiert demnach eine ganze oder reelle Zahl ist scheint kein Unterschied zwischen einer Bestandsgr e und einer Eigenschaftsgr e zu bestehen Schlie lich wird durch die Gr e die Eigenschaft einer Menge d h deren Kardinalit t erfa t Dies ist aber ein Trugschlu F r Bestandsgr en gilt der Erhaltungssatz nicht jedoch f r Eigenschaftsgr en Wird in einem abgeschlossenen Modell ein Bestand ver ndert dann m ssen die anderen Best nde in der Summe ebenfalls diese Anderung erfahren Beispiel Entfernt man Masse von einer Stelle des Modells dann mu dieselbe Masse an anderen Stellen im Modell wieder auftauchen Diesem Verhalten unterliegen Eigenschaftsgr en nicht 4 2 3 Bedeutung der Bestandsgr en Es l t sich die interessante Beobachtung machen da sich die meisten empirischen Wissen schaften anhand der verwendeten Bestandsgr en abgrenzen lassen Bestandsgr en spielen daher meist eine zentrale Rolle im Modell Wirtschaftswissenschaften Produktionsfaktoren Kapital Arbeitskr fte Boden Physik allgemein Energie Elektrotechnik Ladungen Hydraulik Fl ssigkeitsvolumina Chemie Stoffmengen Soziologie Menschen 4 2 Best nde 139 Allein aus der Modellvorstellung da ein Bestand eine Menge von Einheiten Elem
294. scheint jedoch nicht geboten Auch eine Fallunterscheidung f r die Bestandsgleichung f hrt zu keiner praktikablen L sung weil alle F lle bei denen ein gleichzeitiger Transport stattfinden kann einzeln ber cksichtigt werden m ssen Beispiel B_2 B_2 n_12 n_23 WHEN cond_12 AND cond_13 ELSE B_2 n_12 WHEN cond_12 ELSE B_2 n_23 WHEN cond_13 END Falls zum Bestand B nicht zwei sondern drei Transportwege f hren w rden w ren insgesamt bereits sieben F lle zu unterscheiden 4 3 Beschreibung von Transporten zwischen Best nden 147 Eine Sequentialierung in dem Sinne da zuerst der eine und dann der andere Transport ausgef hrt wird ist aber auch nicht m glich weil sonst die Best nde nicht mehr zeitgleich ver ndert werden Beispiel B_2 B_2 n_12 WHEN cond_12 ELSE B_2 n_23 WHEN cond_13 END B_3 B_3 n_23 WHEN cond_13 END Wenn beide Transportbedingungen gleichzeitig erf llt sind wird zun chst der Bestand By um n z erh ht und der Bestand B3 um n z erh ht Erst im folgenden Zeitpunkt wird auch der Bestand Ba um n z vermindert vorausgesetzt die Bedingung cond_13 ist dann noch erf llt Eine vern ftige L sung w rde sich ergeben wenn man erlaubt da die Bestandsgleichung in ihre Komponenten zerlegt werden darf Im Falle eines Transports von B nach B gt und von B nach B3 w rden die Wertzuweisungen B_17 B_1 T_12 B_2 B_2 T_12 T_23 B_3 B_3 T_23 ersetzt durc
295. sen Platz einen Zugriffskonflikt gibt und sich je zwei Philosophen darauf verst ndigen m ssen wer die Gabel erh lt wenn beide sie gleichzeitig wollen Da dieser Fall im nachfolgenden Modell nicht ber cksichtigt ist zeigt allerdings auch da es bei modularem Modellaufbau m glich ist semantisch unvollst ndige Modelle zu formulieren ohne da dies vom Compiler verhindert werden k nnte L ge w hrend des Simulationslaufs tats chlich ein gleichzeitiger Zugriff vor dann w rde der Z hler auf dem Platz des Tisches eine 1 annehmen Es ist Sache des Laufzeitsystems in einem solchen Fall den Simulationslauf mit einer Fehlermeldung zu beenden Je grober das zeitliche Aufl sungsverm gen eingestellt ist desto h ufiger kann eine solche Situation eintreten In erster Linie wird das Modell jedoch als Beispiel f r ein anderes Problem herangezogen Wenn sich alle Philosophen etwa zur gleichen Zeit dem Essen zuwenden und ihre linke Gabel aufnehmen kann keiner von ihnen mehr die rechte Gabel nehmen und zu essen beginnen Das System hat sich verklemmt da keine weitere Zustands nderung mehr m glich ist Damit 230 7 Anwendungen dieser Fall eintreten kann ist es notwendig da jeder Philosoph eine gewisse Zeit braucht um seine linke Gabel aufzunehmen und erst danach beginnt seine rechte Gabel aufzunehmen Die M glichkeit eines solchen Verhaltens ist der Modellspezifikation leider nicht zu entneh men Das Eintreten einer Verklemmung z
296. serer Transportfunktion dar W hrend wir die Transportfunktion f r kontinuierliche zeitdiskrete und elementweise Trans porte eingef hrt haben erm glicht der mit Differenzengleichungen beschriebene Transport lediglich zeitlich getaktete berg nge Wie wir meinen ist diese Darstellungsart aber keineswegs an Differenzengleichungen gebun den da man statt der Anderungsrate auch jede andere Transportfunktion einsetzen kann Die Hilfsgr en entsprechen den abh ngigen Gr en Die gestrichelten Pfeile die auf die Hilfsgr en und Anderungsraten weisen sind Wirkpfeile und daher entspricht dieser Teil der graphischen Darstellung unserem Abh ngigkeitsgraphen Hinzu kommen die durchgezogenen Pfeile welche Str me zwischen Best nden repr sentieren und stets von einer Anderungsrate in ihrer St rke gesteuert werden Auf diese Art werden sowohl Transportvorg nge als auch Wirkungen sehr anschaulich in das gleiche Bild eingebunden Aus diesem Grund ist System Dynamics evtl mit gewissen Erweiterungen als graphisches Darstellungsmittel f r die hier besprochene Modellbeschrei bungssprache von hohem Interesse Es f llt allerdings auf da System Dynamics keine Zustandsgr en kennt die Eigenschaften verk rpern Dies ist nat rlich nur statthaft wenn sich die Eigenschaftsgr en stets aus den Bestandsgr en ableiten lassen In den wirtschafts und sozialwissenschaftlichen Gebieten in denen System Dynamics in er ster Linie zu
297. sf hrlich be handelt Zu diesem Zweck sind Best nde lediglich unter einem eigenen Namen an die n chst h here Komponente weiterzugeben B lt gt K1 B_1 Gegeniiber der Modularisierung mit bestandsbezogenen Gleichungen weist diese Art der Modellzerlegung eine ganze Reihe von Vorteilen auf e Erhaltung Bei der transportbezogenen Beschreibung k nnen keine Elemente verloren gehen oder unbeabsichtigt hinzukommen e Kompaktheit Die Beschreibung des Transports und die Bestimmung der Transportmenge k nnen in einer einzigen Beziehung zusammengefa t werden Der Kommunikationsaufwand ist deutlich geringer e Verst ndlichkeit Transporte zwischen Komponenten sind deutlich hervorgehoben e Unabh ngigkeit Ein Teilaspekt kann vollst ndig modelliert und getestet werden ohne da die Um gebung bekannt sein mu da Transporte nur innerhalb der eigenen Komponente be schrieben werden 164 4 Transporte zwischen Best nden Die Vorteile zeigt auch das folgende Beispiel Beispiel Transport von Warteschlange Queue nach Bedieneinheit Server Die quivalenzierten Best nde tragen in beiden Komponenten denselben Namen 1 quivalenzierung der Warteschlange K1 K2 Queue Queue Server Queue alo N C Beschreibung des Transports in K2 EMPTY Server LET Queue Job 1 gt Server END 2 quivalenzierung der Bedieneinheit K1 K2 Queue Server Server Server gt
298. sichtspunkten zusammen Best nde kann man sich nicht nur aus einzelnen individuellen Elementen zusammengesetzt vorstellen vielmehr k nnen sie auch durch eine positive ganze oder reelle Zahl beschrieben werden In seiner allgemeinen Form geh ren einem Bestand eine Menge von Individuen an die sich in ihren individuellen Eigenschaften unterscheiden 4 2 Best nde 137 Beispiele Auftr ge in Warteschlangen Werkst cke in Maschinen Puffern Transporteinrichtungen Ist f r die Modellbildung eine Unterscheidung der Individuen eines Bestandes nicht erforder lich ben tigt man lediglich Variable welche die Anzahl der Elemente eines Bestandes durch eine nichtnegative ganze Zahl ausdr ckt Beispiele Schrauben in Magazinen Kapital auf Bankkonten Bei einer sehr gro en Anzahl gleichartiger Individuen dr ckt man den Bestand h ufig auch durch eine nichtnegative reelle Zahl aus indem man in einer Ma einheit eine festgelegte Zahl von Individuen zusammenfa t Beispiele Stoffmengen bei chemischen Reaktionen in mol Volumina in der Hydraulik in m Ladungsmengen in der Elektrotechnik in C Eine Variable die mit einer Ma einheit verbunden ist bezeichnet man in der Physik als Gr e Variablen die einen Bestand repr sentieren bezeichen wir daher auch als Bestands gr en Andere Variablen die f r ein Attribut stehen nennen wir Eigenschaftsgr en 4 2 2 Bestandsgr en und Eigenschaftsgr en im Vergleich Eine Eigen
299. sierung im urspr nglichen Sinne Durch eine weitere Erg nzung des Sprachumfangs wollen wir versuchen diese Nachteile zu beseitigen Am aussichtsreichsten erscheint die Einf hrung von Mengenvariablen die bereits geordnete Warter ume d h Warteschlangen repr sentieren Die Inhalte dieser Mengenva riablen k nnten dann auch anderen Komponenten zug nglich gemacht werden Au erdem versprechen wir uns davon auch eine kompaktere Beschreibung des Modells und die M glich keit die zu einer Warteschlange geh rigen Elemente gemeinsam beobachten und ausgeben zu k nnen 3 6 Einf hrung von Mengenvariablen als abh ngige Va riablen Im zweiten Ansatz formulieren wir Warteschlangenmodelle indem wir Mengen von mobilen Elementen bilden und diese Mengen abh ngigen Variablen zuordnen 3 6 1 Variablen f r Indexmengen Die bisherigen Operationen dienten lediglich der Bildung von Mengen Wir wollen nun pr fen ob es sich als vorteilhaft erweist Mengen auch als abh ngige Variablen zuzulassen Bei der Deklaration wird anstelle der Wertemenge das Schl sselwort INDEXSET angegeben Beispiel DEPENDENT VARIABLE Queuei INDEXSET Queue2 INDEXSET Die Belegung erfolgt durch Zuordnung einer Indexmenge Variablen denen eine Menge zugeordnet wird bezeichen wir als Mengenvariablen und un terscheiden sie dadurch von den Eigenschaftsvariablen denen ein einzelner Wert zugeordnet wird Beispiele Queuei 1 10 Queue1 i IN 1 10 X i g
300. sl ufe mit immer wie der neuen Anfangszust nden und Parametrierungen aus wertet anschlie end die Ergebnisse aus und l t sie graphisch darstellen In den meisten F llen liegt der Zweck von Simulati onsstudien im Auffinden optimaler Parameter Strategien und Modellstrukturen Beim Einsatz eines Simulators zu bungs und Trainingszwecken will man den Bediener im Umgang mit dem modellierten System schulen W hrend des Simulationslaufs wird das Verhalten des Modells fortw hrend ausgegeben und der Bediener reagiert auf diese Ausgaben mit st ndig neuen Eingaben an das Modell Zu diesem Einsatzfeld z hlen u a Planspiele oder Fahrzeugsimulatoren 4 1 Einleitung Wahrend man im ersten Fall mit einem abgeschlossenen Modell experimentiert ist im zwei ten Fall das Modell fiir laufende Eingaben offen Fiir Simulationsstudien ist das Simulationsprogramm mit Eingabe Schnittstellen zu verse hen die eine Belegung des Anfangszustands einschlie lich der Parameter ein Definieren der Beobachter sowie ein Setzen der Steuerparameter erlauben Beobachter erm glichen es den Verlauf von Variablen in Abh ngigkeit von der Zeit Zeitrei he oder in Abh ngigkeit vom Eintreten bestimmter Ereignisse Ereignisreihe aufzuzeichnen Die Aufzeichnung kann bei diskreten Variablen vollst ndig oder komprimiert erfolgen Dementsprechend wird ein Beobachter durch die Art der Aufzeichnung durch einige Pa rameter und durch eine Liste von
301. software enthalten Da die klassischen Simulationsssprachen hierzu nicht ber die n tige Funktionalit t verf gen und datengesteuerte Baustein Simulatoren nicht mit individuellen Steuerungskomponenten versehen werden k nnen konnten derartige Systeme nur in einer h heren Programmiersprache evtl unter Zuhilfenahme eines Simulationspa kets modelliert werden Wegen der Komplexit t der Programme kamen hierf r eigentlich nur Informatiker in Frage Simulationsprogramme dieser Art ben tigen jedoch einen betr chtlichen Zeitaufwand f r die Erstellung und sind dennoch sehr schwer lesbar und nderungsunfreundlich Da einer seits der Informatiker meist nur wenig von der Anwendung versteht und der Anwender das Simulationsprogramm nicht nachvollziehen kann l t sich nie sicherstellen ob das Simula tionsprogramm genau den Modellvorstellungen des Anwenders entspricht Die Zielsetzung Auftrags orientierte Systeme bzw Warteschlangen und Transportsysteme sollten daher durch eine Sprache mit einem einfacheren Paradigma beschreibbar sein Durch ein einfaches und schnell erlernbares Sprachkonzept und gut lesbare und verst ndliche Formulierungen soll dem Anwender die M glichkeit gegeben werden die Beschreibungen der Modelle zu verstehen Die Formulierung des Modells sollte nicht l nger einen Informatiker erforderlich machen Ein geschulter Anwender oder ein Ingenieur sollte nach einer gewissen Einarbeitungszeit selbst in der Lage sein Modelle
302. spiel zeigt da mit wenig Aufwand eine ganze Modellklasse erschlossen werden kann Die eigentliche Modellierung findet auf der Ebene der h heren Komponenten durch Verschaltung statt Es ist leicht vorstellbar da durch eine zus tzliche graphische Bedieno berfl che das Arbeiten mit dem System wesentlich attraktiver gemacht werden kann Komponentenklassen e Place Eine Stelle Place ist eine Bestandsvariable die mit einer keiner oder mehreren Marken belegt sein kann Diese Bestandsvariable kann mit ei nem oder mehreren Eing ngen und einem oder mehreren Ausg ngen von Transitionen verbunden werden Die Belegungen der Stellen repr sentie ren den Zustand des Petri Netzes Durchgangsbestand State N State gt l State 226 7 Anwendungen e Transition Eine Transition feuert wenn alle Eing nge durch mindestens eine Marke belegt sind In diesem Fall wird jeder Stelle auf der Eingangsseite je eine Marke entnommen und jeder Stelle auf der Ausgangsseite je eine Marke zugef hrt Parameter NI Anzahl belegter Eing nge NO Anzahl belegter Ausg nge vert Eingangsbest nde Input 1 3 Ausgangsbest nde Output 1 3 bu d Input 1 3 D q Output 1 3 D q Dieses Modell macht folgendes deutlich Eine Stelle ist als TRANSIT LOCATION zu dekla rieren da diesem Platz sowohl Marken hinzugef gt wie auch weggenommen werden Die Eing nge der Transitionen sind als
303. ssen hierarchisch modularisierbar sein Dies erm glicht einerseits Modelle aus vorgefertigten Bausteinen zusammenzusetzen und andererseits Modelle in ber schaubare Komponenten zu zerlegen Jede Komponente mu ein eigenst ndiges Mo dell repr sentieren um f r sich getestet werden zu k nnen Dies sichert eine hohe Zuverl ssigkeit der zusammengesetzten Modelle 14 1 Einleitung e Die Ausf hrung eines automatisch generierten Simulationsprogramms mu effizient er folgen Ein eventueller Verlust an Rechengeschwindigkeit gegen ber einem von Hand erstellten Simulationsprogramm mu tolerierbar sein Weitere f r die Praxis wichtige Erfordernisse die aber nicht den Sprachentwurf beeinflussen sind in Kapitel 6 zusammengestellt Im Bereich kontinuierlicher Modelle kann sich eine formale Modellbeschreibung eng an die blichen Darstellungsmethoden in Form von Differentialgleichungen und algebraischen Glei chungen anlehnen Die Systemtheorie Pich 75 Unbe 80 Wun 86 hat aufgezeigt wie sich solche Modelle auch modular zerlegt repr sentieren lassen In ren 84 wird mit GEST ein erster Sprachentwurf dokumentiert der diese berlegungen aufgreift Mit SIMPLEX MDL Esch 90 entstand schlie lich die erste vollst ndig implementierte Sprache zur Formulierung und Simulation diskret kontinuierlicher Modelle Im Bereich der Warteschlangen und Transportmodelle fehlen derartige Vorbilder Zwar gibt es eine Reihe von Ans tzen auch gra
304. st in erster Linie die Abwicklung der Auftr ge d h die Software Komponenten des Systems Beim zweiten Punkt geht es darum da der Anwender eine geeignete Modellierungstechnik verwendet hnlich wie ein Programmierer erst die Strukturierte Programmierung erler nen und ein ben mu um effizient zu programmieren mu auch der Modellierer bestimmte Techniken nutzen Es ist noch eine Aufgabe weiterer Forschung graphische Darstellungs methoden f r die zustandsorientierte Modellbeschreibung in dem Sinne zu vervollkommnen wie Struktogramme eine Hilfestellung f r sauberes Programmieren abgeben Aus diesen Gr nden ist es wichtig da Systemanalyse und Modellierungstechniken gleich wertige Ausbildungsziele neben dem reinen Erlernen der Sprache Syntax und Semantik sind damit der Anwender erfolgreich davon Gebrauch machen kann und die Modelle gut les bar und bersichtlich werden Ebenso wie man in einer prozeduralen Sprache unverst ndlich programmieren kann ist es leider auch in einer Spezifikationssprache m glich unverst ndlich zu formulieren Durch zahlreiche Anwendungen wurde daher versucht einen geeigneten Modellierungsstil zu finden Die Brosch re Offentliche Modellbanken des Simulationssystems SIMPLEX II ApEsWi 92 stellt viele beispielhafte Anwendungen vor und liefert den MDL Quelltext dazu 254 8 Zusammenfassung Resumee Mit der Modellbeschreibungssprache als universellem Werkzeug ist es sicherlich gelu
305. t assignment identifier tr_spec conditional_expression tr_spec Pa Wan conditional_expression expression expression WHEN expression ELSE expression WHEN expression ELSE expression END conditional_statement IF expression LET statement_sequence ELSIF expression LET statement_sequence ELSE LET statement_sequence END statement assignment conditional_statement statement_sequence statement statement Wie man erkennt werden Aussageformen entweder durch einen Strichpunkt einfache Wert zuordnung oder durch das Schliisselwort END bedingte Aussageformen abgeschlossen Die Ausdr cke hinter den Schl sselw rtern WHEN und IF m ssen selbstverst ndlich einen logischen Wert liefern Von diesen beiden Konstrukten ist im Grunde nur eines erforderlich Dennoch haben je nach Anwendung beide Konstrukte ihre Berechtigung Das WHEN Konstrukt hat seinen Vorteil darin da es sehr kompakt ist und deutlich macht welche Gr e durch die Aussageform definiert wird Das IF Konstrukt hat den Vorteil da es mehrere Definitionsgleichungen aufnehmen kann wenn gleiche F lle zu unterscheiden sind Ein weiterer Vorteil ist da es tiefere Schachte lungen des Zustandsraumes erlaubt Beispiel IF x gt c LET 1 1 yi2 3S X END ELSIF x lt c LET y_i 1 V2 x3 END ELSE LET y_1 0 y_2 0 END Dieses IF Konstrukt definiert die beiden abh ngigen Variablen y_
306. t durch Definitionsgleichungen festgelegt Hierzu ist die Syntax der Wertzuweisung entsprechend abzu ndern assignment indexed_attribute tr_spec conditional_expression Um die Eindeutigkeit und Vollst ndigkeit sicherzustellen sind folgende Bedingungen zu erf llen e Jedes einzelne Feldelement mu eindeutig definiert sein d h f r jeden Index darf nicht mehr als Modellgleichung g ltig sein e Damit keine berfl ssigen Variablen deklariert sind sollte jedes einzelne Feldelement zumindest in Teilen des Zustandsraums durch eine Modellgleichung definiert sein e Abh ngige Variable m ssen vollst ndig d h f r jeden Index in allen Teilen des Zu standsraums durch eine g ltige Modellgleichung definiert sein Um diese Bedingungen wie bisher vom Compiler berpr fen zu k nnen ist es erforderlich die Indices der definierten Variablen zu kennen Inwieweit dies m glich ist wird an sp terer Stelle er rtert Zun chst jedoch wollen wir den Allquantor einf hren um indizierte Variablen wirkungsvoll einsetzen zu k nnen 3 4 3 Formulierung von Definitionsgleichungen mit Allquantoren Um formulieren zu k nnen da Definitionsgleichungen nicht nur f r einen einzigen Varia blenindex sondern f r eine ganze Menge von Indices gelten f hren wir Allquantoren ein Da die Aussageformen die mit einem Allquantor zusammengefa t werden stets wahr sind liefert der hier eingef hrte Allquantor keinen logischen Wert z
307. t O Queue1 i IN 1 10 Jobli Ort Q1 Eine Mengenvariable kann auch f r eine geordnete Menge stehen 3 6 Einf hrung von Mengenvariablen als abh ngige Variablen 113 Beispiel Quevel i IN 1 10 Job i Ort Q1 INC Job i Laenge Eine Mengenvariable mu nicht unbedingt fiir einen Aufenthaltsort stehen Die Bedingung ist schlie lich beliebig und auch Elemente mehrerer Aufenthaltsorte k nnen durch eine Men genvariablen zusammengefa t sein Beispiel Quevel2 i IN 1 10 Joblil Ort Q1 OR Job i Ort Q2 Aber auch fragw rdige Mengenbildungen sind m glich So ist es denkbar da eine Mengen variable Indices von mobilen Elemente verschiedenen Typs beinhaltet Beispiel QType12 i IN 1 10 Jobt i Ort Q1 OR Job2 i Ort Q2 Eine solche Mengenbildung ist in der Regel jedoch nicht sinnvoll da jeder Index nur einmal in die Indexmenge aufgenommen wird Die Elemente die zur Bildung der Menge beigetragen haben lassen sich ber die Mengenvariable nicht mehr ansprechen Bildet man nicht eine Indexmenge sondern eine Menge mobiler Elemente wird dieses Pro blem vermieden 3 6 2 Variablen f r Mengen aus Feldelementen Wir wollen nun geordnete Mengen bilden die sich aus Elementen eines Feldes zusammen setzen Der Name des deklarierten Feldes dient gleichzeitig als Name der Grundmenge Aus dieser Grundmenge kann durch Angabe von Eigenschaften eine Teilmenge ge
308. t bei der Deklaration verteilter Best nde selbst Schwerpunkte zu setzen und die Autonomie der Komponenten je nach Bedarf einzu schr nken Die Ergebnisse Durch Einbeziehung aller erforderlichen Gesichtspunkte entstand nach und nach ein voll st ndiges Sprachkonzept Die mit diesem Konzept erzielten Ergebnisse lassen sich wie folgt zusammenfassen Die konzipierte Modellbeschreibungssprache stellt eine Spezifikationssprache dar Sie ist de klarativ und beschreibt die Modelldynamik als eine Menge von Aussageformen Im Gegensatz zu einer prozeduralen Sprache formuliert sie lediglich was zu tun ist um ein Modell abzuar beiten aber nicht wie die Ausf hrung erfolgen soll Der Anwender mu sich demnach nicht um den Programmflu k mmern was insbesondere bei parallelen Abl ufen eine wesentliche Erleichterung darstellt Ein charakteristisches Merkmal f r den deklarativen Charakter ist es da die Aussageformen in keiner besonderen Reihenfolge angeordnet werden m ssen So konnte eine klare Unterscheidung zwischen Modellbeschreibung und Modellimplementa tion hergestellt werden W hrend die Modellbeschreibung die physikalische Realisierung des Modells v llig offen l t ist die Modellimplementation in Form eines Simulationsprogramms immer an eine bestimmte Art von Rechenanlage gebunden Die vorgestellte Sprache besitzt ein sehr niedriges Abstraktionsniveau F r alle Arten von diskreten Modellen sowie f r kontinuierliche Modelle die si
309. t ob es nach B oder B3 transportiert wird Bei den folgenden Transportfunktionen w re dies beispielsweise erf llt ist aber im allgemei nen Fall vom Compiler nicht nachzuweisen T_12 T_13 s A AND cond_12 Job 1 n_12 B AND cond_23 Job 1 n_13 e e ar lt ll H a us an lt ke I Dieses Problem l t sich a durch ein Sprachkonstrukt dessen Syntax die Disjunktheit der Transportmengen ga rantiert oder b durch einen elementweisen Transport mobiler Elemente l sen 4 4 4 Das DEVIDE Konstrukt Angeregt wird ein Sprachkonstrukt das hnlich dem IF THEN ELSE sukzessive einen an gegebenen Bestand unterteilt Dieses Konstrukt hier als DEVIDE Konstrukt bezeichnet k nnte etwa folgenderma en aus sehen DEVIDE B_1 INTO T_12 Job cond_12 Job 1 n_12 REMAINING SET INTO T_13 Job cond_13 Job 1 n_13 END Aus B wird zun chst die Teilmenge Tiz gebildet und aus der verbliebenen Menge B Ti wird die Teilmenge 7 ausgegrenzt Elemente aus den Eigenschaftsmengen werden auf diese Art eindeutig der Teilmenge Tio oder T g zugeordnet Tis B 4 4 Diskussion der Eindeutigkeit am Problem der Verteilung 153 Die Eindeutigkeit beim Tranportvorgang ist hergestellt wenn Transportmengen welche Teil mengen des gleichen Bestandes sind unter Zuhilfenahme des DEVIDE Kontrukts ermittelt worden sind Das ist wiederum vom Compiler abpr fb
310. t gew hrleisten 4 6 Transportbezogene Modularisierung mit Teilautonomie 171 Sensorbestinde Ein wichtiges Anliegen ist es sich ber Best nde in anderen Komponenten zu informieren ohne diese selbst zu ver ndern Zu diesem Zweck mu ein Bestand mit dem Recht zu lesen ausgestattet sein und gleichzeitig auf alle anderen Rechte verzichten In Anlehnung an Sen sorvariablen bezeichnen wir diese Best nde als SENSOR Best nde Sensorbest nde k nnen die Informationen eines privaten Bestandes und auch aller anderen Typen von Best nden lesen Der zu lesende Bestand kann auch durch quivalenzierung aus mehreren Best nden hervorgehen In Kurzschreibweise L WA SHB VA Eingangs und Ausgangsbest nde Vielfach ist ein Modell so gestaltet da Transporte zwischen Komponenten nur in einer Richtung m glich sind Im allgemeinsten Fall liegt ein richtungsgebundener Transport dann vor wenn eine oder mehrere Komponenten einen Bestand beschicken und eine oder mehrere Komponenten einen Bestand entleeren Komponenten en ee Komponenten die bringen Br un die holen Um zwischen Komponenten die bringen und Komponenten die holen unterscheiden zu k nnen gestalten wir die Rechte derart da ein Bestand nur als Ausgangs bzw Eingangs Bestand fungieren kann Ein Ausgangsbestand ist ein Bestand der auf das Recht zu Holen verzichtet und es daf r einem oder mehreren anderen Best nden zugesteht Gleichzeitig nimmt er das Recht zu Br
311. t vonein ander unabh ngig sind Nun soll das Modell durch einen Diffusionsvorgang zwischen diesen beiden Beh ltnissen erweitert werden EFFECT CONNECTIONS K_1 C_1 gt K_12 SC_1 K_2 C_2 gt K_12 SC_2 TRANSPORT CONNECTIONS K_1 B_1 lt gt K_12 B_1 K_2 B_2 lt gt K_12 B_2 Ki RAD K2 Bi le Bi B2 be B2 ci sca s2 41 c2 B_1 gt B_2 D A C_1 C_2 Ein lesender Zugriff auf die Konzentrationen in den Beh ltnissen ist ebenfalls ohne Eingriff in die Komponenten K_1 und K_2 m glich In den beiden letzten Beispielen hat der Verzicht auf Autonomie die Modellbildung erleichert und zu einer bersichtlichen Modellzerlegung gef hrt Ein weiteres Beispiel soll zeigen da der Verzicht auf Autonomie auch unerw nschte Folgen nach sich ziehen kann 4 5 Modularisierung 167 Es soll ein Girokonto mit den dazugeh rigen Geldtransfers modelliert werden das eine Bank ihrem Kunden zur Verf gung stellt Beispiel Girokonto Der Kunde kann Einzahlungen und Abbuchungen vornehmen die Bank kann Gutha benzinsen und Schuldzinsen verbuchen Din Bargeld Girokonto Bankverm gen B gt G Einzahlung G gt V Schuldzinsen G gt B Auszahlung V gt G Guthabenzinsen Die Zerlegung soll nach Bank und Kunde vorgenommen werden Das Girokonto teilen sich die beiden Komponenten TRANSPORT CONNECTION Kunde G lt gt Bank G
312. t_location Eine Transportverbindung beinhaltet mindestens den Zusammenschlu zweier Durchgangs best nde oder eine Verbindung zwischen einem Ausgangs und einem verteilbaren Ein gangsbestand entry_location indexed_component indexed_location dentry_location indexed_component indexed_location exit_location indexed_component indexed_location transit_location indexed_component indexed_location indexed_component indexed_identifier indexed_location indexed_identifier Beispiele hierzu finden sich im Kapitel 4 6 5 4 3 Verbindungen zwischen Komponenten Der strukturelle Aufbau einer h heren Komponente wird durch Verbindungen zwischen Kom ponenten dargestellt Verbindungen zwischen Komponenten k nnen sowohl Wirkungen von Attributen auf andere Komponenten zum Ausdruck bringen als auch Zusammenschl sse von Best nden repr sentieren die dem Transport von Elementen dienen component_structure STRUCTURE effect_connection_part transport_connection_part Wirkungen gehen von internen Variablen Zustandsvariablen oder abh ngigen Variablen ei ner Komponente aus und nehmen ber Sensorvariablen auf die Dynamik einer oder mehrerer anderer Komponenten Einflu 5 4 H here Komponenten 209 effect_connection_part EFFECT CONNECTION S effect_connection effect_connection internal_variable gt sensor_variable internal_variable
313. telbar einsichtig da sich derartige Modellwelten stets auch graphisch repr sentieren lassen In Verbindung mit komfortablen graphischen Bedienoberfl chen kann jeder Anwender bei Kenntnis der Modellwelt z gig Mo delle aufbauen und in ihrer Struktur ver ndern Das graphisch aufgebaute Modell Layout l t sich gleichzeitig f r die Animation heranziehen Seitdem nahezu jeder Anwender einen graphischen Rechner Arbeitsplatz besitzt sind eine Vielzahl derartiger Simulatoren entstanden Diese enthalten neben elementaren Bausteinen wie sie in den Beispielen oben angef hrt wurden auch komplexere Komponenten um den Bed rfnissen der Anwender Rechnung zu tragen Auf dem Gebiet der Fertigungstechnik sind die derzeit wichtigsten Vertreter DOSIMIS III WITNESS und SIMPLE Bei kontinuier lichen Anwendungen steht XANALOG f r den Stand der Technik Wegen ihrer komfortablen Bedienung haben datengesteuerte Simulatoren Ma st be gesetzt Alle Simulatoren werden mittlerweile an ihnen gemessen weil der Anwender selbst damit umgehen kann Ob er auch alle seine Probleme damit l sen kann bleibt meist dahingestellt Durch die Beschr nkung auf bestimmte Modellbausteine lassen sich n mlich viele Eigenarten eines Systems nicht oder nur sehr trickreich nachbilden Auf ein bestimmtes eng umrissenes Anwendungsgebiet ist man ohnehin verwiesen Daher bedeutet ein Wechsel des Anwendungs gebietes f r den Benutzer da er einen anderen datengesteuerten Simulator
314. tellung 51 Gegen ber dieser eher mathematischen Darstellung des Algorithmus ist es bei einer Imple mentierung in einer prozeduralen Sprache nat rlich nicht erforderlich da f r jede Variable der gesamte Zeitverlauf mitgef hrt wird Es ist lediglich notwendig da der Zustand in zwei getrennten Zustandsvektoren gespeichert wird n mlich einen f r den aktuellen Zustand zum Zeitpunkt t sowie einen f r den Folgezustand zum Zeitpunkt t 1 Daten t aktueller Zeitpunkt t i naechster Zeitpunkt tp41 Z NZ NZ Zustandsvariablen Wert zum Zeitpunkt t z NZ NZ Zustandsvariablen Wert zum Zeitpunkt t 1 Y NY NY abhaengige Variablen Wert zum Zeitpunkt tx x NX NX Sensorvariablen Wert zum Zeitpunkt t Algorithmus 1 Anfangszeit und Anfangszustand setzen 2 Alle nicht angeschlossenen Sensorvariablen x_i berechnen Fuer alle i aus 1 NX x_i e_i t 3 Alle abhaengigen Variablen y_i berechnen Fuer alle i von 1 bis NY y_i gi X y_1 y_i 1 Z t 4 Alle neuen Zustandsvariablen z_i fuer den Zeitpunkt t berechnen Fuer alle i aus 1 NZ z_i f i Y Z t 5 Variablen des aktuellen Zustands aufzeichnen Monitor 6a Neuen Zeitpunkt t bestimmen und Zeit weiterschalten 6b Alle Zustandsvariablen umspeichern Fuer alle i aus 1 NZ gt Aa NY ARE 7 Fahre fort mit Schritt 2 52 2 Sprachentwurf im Sinne der klassischen Systemtheorie Bei Verwendung einer eindimensionalen diskrete
315. ten immer eine um eins h here Gruppennummer als die Variable mit der sie verbunden ist Gruppe x Gruppe v 1 wenn v 2 Zustandsvariablen abh ngige Variablen und nicht angeschlossene Sensorvariablen ber nehmen die gr te Gruppennummer von denjenigen Variablen von denen sie abh ngen In manchen F llen ist auch eine noch gr ere Gruppennummer sinnvoll Gruppe z gt Max Gruppe v Gruppe v Der Weg im Abh ngigkeitsgraph der zu einer Variable ber die meisten Sensorvariablen f hrt liefert die insgesamt gr te Gruppennummer Algorithmus f r die Gruppierung von algebraischen Gleichungen Diese Vorgaben lassen aber noch Freiheiten f r die Zuordnung der Gruppennummer an die Variablen und es stellt sich daher die Frage mit welchem Algorithmus eine optimale L sung erzielt wird Optimal bedeutet in diesem Zusammenhang da die Anzahl der Komponen tenaufrufe f r jeden Zeitpunkt minimal gehalten wird Dadurch spart man nicht nur den Unterprogammaufruf ein sondern vor allem das aufwendige berpr fen der Bedingungen f r jede Variable Wir wollen uns an dieser Stelle mit der Beschreibung einer nicht ganz optimalen Vorgehens weise begn gen die aber bereits ausreichende Ergebnisse liefert Knoten die nur von Zustandsvariablen oder der Zeit abh ngen erhalten die Gruppennummer 1 eingetragen Wir verfolgen nun jeden Pfad des Graphen und tragen die Nummer des vorangegangenen Knotens ein H ngt ein Knoten vo
316. ter Komponentenklassen Klassenkonzept Auspr gungen der gleichen Klasse k nnen durch eigene Namen und oder bei Feldern von Subkomponenten durch Indices unter schieden werden subcomponent_declaration SUBCOMPONENT S subcomponent subcomponent subcomponent ARRAY dimension_list identifier OF CLASS identifier Felder von Komponenten werden genauso angelegt wie Felder von Variablen 5 4 2 Einrichten einer Schnittstelle Um eine h here Komponente wiederum als Subkomponente einsetzen und damit Modelle hierarchisch aufbauen zu k nnen ist es m glich eine Schnittstelle einzurichten Zu die sem Zweck werden in der h heren Komponente eigene Variablen Attribute und Locati ons vereinbart denen Variablen aus Subkomponenten entsprechen Beliebige Variablen und Best nde aus Subkomponenten mit Ausnahme der privaten Best nde k nnen in einer h heren Komponente mit eigenen Namen belegt werden interface_declaration DECLARATION S declaration_of_sensor_variables declaration_of_internal_variables declaration_of_entry_locations declaration_of_dentry_locations declaration_of_exit_locations declaration_of_transit_locations VIE Ue aae Fe SENSOR VARIABLE S sensor_variable_declaration declaration_of_sensor_variables INTERNAL VARIABLE S internal_variable_declaration declaration_of_internal_variables declaration_of_entry_locations ENTRY LOCATION S entry_loca
317. tion Die M glichkeiten die hier geboten werden sind sehr umfangreich Sie sind aber notwendig um den n tigen Komfort und die universelle Einsetzbarkeit zu erzielen Mehr dar ber findet sich in Kapitel 6 Im Deklarationsteil werden die Modellvariablen d h die Attribute und Best nde der Mo dellkomponente vereinbart declaration_part DECLARATION S initial_time_and_unit attribute_declaration_part location_declaration_part Die Zeit wird zwar durch die Standardvariable T repr sentiert und besitzt die Wertemenge REAL die physikalische Ma einheit soweit ben tigt sowie der Anfangszeitpunkt zu dem auch die angegebene Anfangsbelegung geh rt sind jedoch noch offen initial_time_and_unit INITIAL TIME number unit Die Deklaration der Attribute wurde bereits in Abschnitt 2 4 2 behandelt und soll deshalb hier nur noch in aller K rze angef hrt werden Attribute erhalten einen eindeutigen Bezeichner und werden durch die Angabe von Eigen schaften n her klassifiziert e Verwendung Zustandsvariablen abh ngige Variablen Sensorvariablen und Zufallsvariablen e Form der Zeitverlaufs konstant diskret sprunghaft oder kontinuierlich stetig e Wertemenge ganzzahlig reell logisch Aufz hlungsmenge Menge von mobilen Elementen e physikalische Ma einheit 194 5 Systematische Darstellung der Modellbeschreibungssprache attribute_declaration_part STATE VARIABLE S var_course_specific_
318. tion_declaration DENTRY LOCATION S dentry_location_declaration declaration_of_dentry_locations declaration_of_exit_locations EXIT LOCATION S exit_location_declaration 5 4 H here Komponenten 207 declaration_of_transit_locations TRANSIT LOCATION S transit_location_declaration Der Wert einer Sensorvariablen kann an eine oder auch mehrere Sensorvariablen aus Sub komponenten weitergereicht werden sensor_variable_declaration identifier gt sensor_variable identifier gt sensor_variable sensor_variable Der Wert einer internen Variablen kann von einer Zustandsvariablen oder abh ngigen Va riablen einer Subkomponente bernommen werden internal_variable_declaration identifier lt internal_variable sensor_variable indexed_component indexed_variable internal_variable indexed_component indexed_variable indexed_identifier indexed_identifier indexed_component indexed_variable Einen Eingangsbestand f r eine h here Komponente erh lt man durch Gleichsetzung mit einem nicht verteilbaren Eingangsbestand einer Subkomponente entry_location_declaration identifier gt entry_location identifier gt dentry_fusion dentry_fusion dentry_location C dentry_location dentry_location Alternativ kann ein Eingangsbestand einer h heren Kom
319. tzen statischer Marken Gebrauch mu man f r die Siumulation eines modular aufgebauten Modells gegen ber einer Realisierung in einer einzigen Komponente trotzdem noch mit einem bis zu doppelt so hohem Aufwand rechnen 2 7 3 Effizienzverbesserung durch dynamische Marken Beim Einsatz dynamischer Marken wird w hrend des Programmablaufs gepr ft ob eine Komponente aufzurufen bzw innerhalb einer Komponente eine Variable zu berechnen ist Es lassen in diesem Fall drei Verfahren unterscheiden 1 Markierung der Auswirkungen einer nderung Vorw rts Verfolgung Komponentenaufruf falls Komponente und Ebene Gruppe markiert Berechnung falls Variable markiert 2 7 Algorithmus fiir die Simulation einer modularen Modellbeschreibung 77 2 Markierung der ver nderten Variablen R ckw rts Verfolgung Komponentenaufruf falls Abh ngigkeit einer internen Variablen markiert Berechnung falls Abh ngigkeit einer Variablen markiert 3 Markierung der Auswirkungen auf Komponente Gruppe und Markierung der ver nder ten Variablen gemischte L sung Komponentenaufruf falls Komponente und Ebene Gruppe markiert Berechnung falls Abh ngigkeit einer Variablen markiert Vorw rts Verfolgung Eine Marke im Bitfeld B f r Ebene und Komponente bzw die Marke einer Variablen werden dann gesetzt wenn wenn nach einer Wert nderung ein Einflu auf die betreffende Kom ponente bzw Variable vorliegt F r diesen Zweck ist zu jede
320. uch darin enthalten sind Wird der Transport durch St ckzahlen beschrieben ist es durchaus m glich da aus einem Bestand mehr Elemente entnommen werden sollen als dieser enth lt Der Bestand w rde dann eine negative Zahl annehmen Solche Modellierungsfehler lassen sich aber leider erst zur Laufzeit feststellen 4 3 5 Gemeinsamkeiten bei der Beschreibung von Transporten Wie man sieht ben tigen wir je nachdem ob die Transporte individuelle Elemente umfas sen diskret oder kontinuierlich sind etwas unterschiedliche Schreibweisen Der strukturelle Aufbau einer Transportbeschreibung ist jedoch stets derselbe 1 a Bestimmen des Transportzeitpunkts au er beim kontinuierlichen Transport b Bestimmen der Transportmenge bzw der Transportrate 2 a Wegnehmen der Transportmenge von Bestand B b Hinzuf gen der Transportmenge zu Bestand B Die transportbezogene Beschreibung fa t die beiden Schritte 2a und 2b in einer Beziehung zusammen Die Transportmenge wird daher nur in einer Beziehung ben tigt Daraus ergeben sich folgende Vorteile e Die Schritte 1 und 2 lassen sich in einer einzigen Zeile zusammenfassen F r die Trans portmenge T wird keine eigene Variable ben tigt e Es ist garantiert da Elemente die einem Bestand entnommen werden auch einem anderen hinzugef gt werden Die Erhaltung der Elemente ist damit sichergestellt e Die Schreibweise ist kompakt und gut verst ndlich Bei der bestandsbezogenen B
321. uch hieran der Zyklus erkennen 2 6 Modularisierung 63 Eine weitere Forderung ist da eine Sensorvariable nur mit einer einzigen internen Variablen verbunden sein darf Dies entspricht der Forderung nach Eindeutigkeit bei der Zuordnung wie sie bereits aus den Basiskomponenten bekannt ist Hingegen ist es nicht erforderlich da jede Sensorvariable verbunden ist Bleibt die Schnitt stelle offen dann tritt hierf r die in der Basiskomponente festgelegte Zeitfunktion oder der feste Wert ein Auf die Vollst ndigkeit bei der Belegung von Sensorvariablen kann daher verzichtet werden Dennoch erscheint es ratsam wenigstens eine Warnung auszugeben wenn eine Sensorvariable nicht verbunden ist da hier eine h ufige Fehlerquelle liegt In der graphischen Darstellung bedeutet dies da von einer internen Variablen mehrere Verbindungspfeile ausgehen d rfen auf eine Sensorvariable jedoch nur ein einziger Verbin dungspfeil gerichtet sein darf Beispiel A1 A A2 A vi z T ml E T2 B Z x Die Zustandsvariable z der Komponente B ist sowohl mit x_2 der Komponente A1 wie auch mit x_2 der Komponente A2 verbunden Die Sensorvariable x der Komponente B bleibt unbelegt 2 6 5 Hierarchische Modularisierung Auch eine Hierarchisierung der Modellzerlegung ist m glich Zu diesem Zweck fa t man mehrere Komponenten selbst wiederum zu
322. ueues Q1 Q2 Q3 VALUE SET Color red green blue DECLARATIONS STATE VARIABLES CONSTANT Farbe Color red Laenge REAL 5 DISCRETE Ort Queues Q1 Pos INT 1 END OF Job Die f r die Verwendung in Basiskomponenten eingef hrten Konstanten sind Gr en die w hrend des gesamten Simulationslaufs auf einem konstanten Wert bleiben In den meisten Anwendungsf llen reicht die Lebensdauer mobiler Komponenten nicht ber den gesamten Simulationslauf sondern nur f r den Weg den sie von einer Quelle d h ihrer Erzeugung bis zu einer Senke d h ihrer Vernichtung durchlaufen Es ist daher daf r zu sorgen da Konstanten von mobilen Komponenten bei ihrer Erzeugung gesetzt werden k nnen Darauf wird allerdings erst im Kapitel 4 eingegangen Der Zugriff auf ein Attribut eines Elements erfolgt zweistufig ber Elementnamen und At tributnamen getrennt durch einen Punkt 88 3 Spracherweiterungen zur Formulierung von Warteschlangenmodellen attribute identifier identifier identifier Eine Schachtelung von Elementen Element auf Element ist zun chst nicht erforderlich und wird sp ter in einem anderen Zusammenhang eingef hrt Die Syntax von Definitionsgleichungen ist schlie lich noch dahingehend abzu ndern da auch Attributen von Elementen Werte zugewiesen werden k nnen assignment attribute id_specificator conditional_expression Beispi
323. uf Queuei befindet sich im folgenden Zustand auf Location Queue2 Ihre Einordnung und damit die Bestimmung der Position erfolgt entsprechend des Einordnungskriteriums Da mobile Komponenten nur noch ber ihren Aufenthaltsort angesprochen werden k nnen sollte der Zugriff m glichst einfach gehalten sein Deshalb ist es sinnvoll den Aufenthaltsort von vornherein mit einer Ordnung zu versehen d h als Warteschlange und nicht als War teraum auszubilden Beim Zugriff auf einzelne Elemente mu dann nicht erst eine Ordnung hergestellt werden Zu diesem Zweck wird der Location bereits bei ihrer Deklartion ein Ordnungskriterium bzw ein Einordnungskriterium mitgegeben Ein Ordnungskriterium ordnet die Mengenelemente gem ihrer aktuellen Attribute Ein Einordnungskriterium legt die Position bei der Ankunft eines Teiles fest und ver ndert diese nur wenn das Element nachr cken kann ndern sich Attribute von mobilen Komponenten so ndern sich dadurch nicht ihre Positionen innerhalb der Warteschlange Es darf nicht bersehen werden da die Angabe des Ordnungs bzw Einordnungskriteriums bei der Deklaration einer Location betr chtliche Einschr nkungen mit sich bringt Bislang konnten die Ausdr cke beliebig sein um die Ordnung einer Menge festzulegen und insbe sondere auch Funktionen beinhalten Ordnungs bzw Einordnungskriterien von Locations hingegen d rfen lediglich Variablen der mobilen Komponente enthalten Es ist daher nicht moglich
324. uierlicher Modelle wird dadurch denkbar Schlie lich sind aber auch die methodologischen Gesichtspunkte interessant Welche Gemein samkeiten zeichnet das Denken in kontinuierlichen und diskreten Modellen aus und wo liegen die Unterschiede K nnen neuartige Beschreibungsformen f r diskrete Modelle die traditio nellen Beschreibungsformen f r kontinuierliche Modelle befruchten Wie sehr hneln sich Syntax und Semantik zur Beschreibung kontinuierlicher bzw diskreter Vorg nge Die angestrebte Spezifikationssprache soll eine manuelle Programmierung des Simulations modells vollst ndig ersetzen Die Kluft zwischen Modellvorstellung und Modellbeschreibung mu deutlich kleiner sein als zwischen Modellvorstellung und Simulationsprogramm Sie soll klein genug sein damit auch ein in formalen Sprachen wenig erfahrener Anwender damit umgehen kann 1 5 Neue Anforderungen an die Simulationstechnik 15 1 5 Neue Anforderungen an die Simulationstechnik am Beispiel der Fertigungstechnik Die Anregungen fiir neue Werkzeuge zum Erstellen von Simulationsprogrammen kamen in den letzten Jahren haupts chlich aus der Fertigungstechnik die neuartigen Anforderungen INGER 85 gegen bersteht und sich hierf r L sungen durch Simulationsstudien erhofft Die Anforderungen der Fertigungstechnik sind besonders anspruchsvoll und schlie en die Bed rfnisse der meisten anderen Anwendungsgebiete der diskreten Simulation mit ein Damit sich der Leser eine V
325. ungen n tig ist Eine detaillierte Beschreibung findet sich im Referenzhandbuch der Modellbeschreibungssprache SIMPLEX MDL Esch 91 6 2 Aufz hlungsmengen Neben den standardm ig angebotenen Wertemengen INTEGER REAL und LOGICAL sind insbesondere benutzerdefinierte Aufz hlungsmengen einer besseren Lesbarkeit des Mo dells dienlich Neben ungeordneten Aufz hlungen sind auch geordnete Aufz hlungen denk bar Beispiel DEFINITIONS VALUE SET Status wartet arbeitet gestoert VALUE SET Groesse klein lt mittel lt gross Zur Unterscheidung von benutzerdefinierten Variablen und Komponentennamen werden Auspr gungen einer Aufz hlungsmenge in einfache Hochkommas eingeschlossen Werte von Aufz hlungsmengen d rfen in mehreren Mengen enthalten sein Dadurch darf es jedoch keine Widerspr che in der Ordnungsrelation geben Die Deklaration von Variablen erfolgt unter Angabe der Aufz hlungsmenge Beispiel STATE VARIABLE DISCRETE Zustand Status wartet An Operationen ist bei ungeordneten Mengen die Pr fung auf Gleichheit oder Un gleichheit lt gt m glich bei geordneten Mengen sind auch die brigen Relationen erlaubt Der Name des Aufz hlungstyps mitsamt den Auspr gungen wird in die dar berliegenden Komponenten vererbt Dadurch wird eine Initialisierung ohne erneute Definition m glich und es l t sich sicherstellen da eine in mehreren Komponenten mit gl
326. unktionsverlaufs beschrieben Der Name des Attributs wird hierzu mit einem Apostroph gt versehen Die Wertzuweisung kann sich sowohl auf Attribute der Basiskomponente als auch auf Attri bute mobiler Komponenten beziehen Diese sind ber ihren Aufenthaltsort zu erreichen assignment selected_attribute tr_spec conditional_expression tr_spec us non 5 3 4 Transporte zwischen Best nden Schreibende Zugriffe auf Best nde k nnen nur ber Transportoperationen erfolgen Es wird syntaktisch unterschieden ob der Transport mit unterscheidbaren oder mit gleichartigen Elementen durchgef hrt wird transport element_transport quantity_transport 1 Transporte mit unterscheidbaren Elementen Transporte mit unterscheidbaren Elementen k nnen nur mit einzelnen Elementen ele mentweise durchgef hrt werden element_transport selected_element gt selected_location Die Transportanweisung kann sich sowohl auf Best nde der Basiskomponente als auch auf Best nde mobiler Komponenten beziehen Diese sind ber ihren Aufenthaltsort zu erreichen 5 3 Beschreibung der Modelldynamik in Basiskomponenten 201 2 Transporte mit gleichartigen Elementen Bei Transporten mit gleichartigen Elementen wird neben dem Transportpfad Bestand gt Bestand die zu transportierende Menge angegeben Dabei ist zwischen diskreten und kontinuierlichen Transportvorg ngen zu unterscheiden b Diskrete Transportvor
327. uns jedoch eine Br cke zu kontinuierlichen und diskreten Modellen die keine unterscheidbaren mobilen Elemente beinhalten Anhand der Transportoperation wollen wir im folgenden Kapitel Gemeinsamkeiten und Un terschiede dieser bislang stets v llig getrennt behandelten Modellwelten herausarbeiten Ein weiterer wichtiger Punkt wird die weitgehende Wiederherstellung der Autonomie sein die durch den Einsatz der Transportoperation in modular zerlegten Modellen verletzt wird Damit verbunden ist auch die Tatsache da die Eindeutigkeit in zerlegten Modellen unter gewissen Bedingungen nicht gew hrleistet ist 129 Kapitel 4 Transporte zwischen Best nden Im vorangegangenen Kapitel haben wir durch geeignete sprachliche Erweiterungen des sy stemtheoretischen Konzepts eine Beschreibung von Warteschlangenmodellen m glich ge macht Der eleganteste Weg der auch am besten die sematische Korrektheit eines Modells sicherstellen konnte ergab sich durch die Einf hrung von Aufenthaltsorten Locations die man als Zustandsvariable interpretieren kann und die eine Menge von mobilen Komponenten repr sentieren Es wurde bereits erw hnt da sich die eingef hrte Transportoperation ebenso als eine Kom bination zweier Zustandsgleichungen auffassen l t einem Hinzuf gen und einem Wegneh men Diese Art der Beschreibung ist typisch f r die Formulierung von Transporten in kon tinuierlichen Modellen oder diskreten Modellen ohne individuelle Elemente
328. ur ck Er unterscheidet sich insofern vom Allquantor wie er in der Logik Verwendung findet und kann daher auch nicht als Bestandteil von logischen Ausdr cken gebraucht werden Um dies deutlich zu machen verwenden wir anstelle des Schl sselwortes FORALL das Schl sselwort FOREACH foreach_statement FOREACH iterator iterator LET statement_sequence END iterator identifier IN index_range condition Mit dem FOREACH Konstrukt wird eine gebundene Variable vereinbart deren Wert ber ei nem angegebenen Indexbereich variiert Durch Angabe einer Bedingung kann die Indexmenge eingeschr nkt werden Die gebundene Variable besitzt G ltigkeit innerhalb einer eventuell angegebenen Bedingung sowie im Rumpf der Anweisung zwischen LET und END 3 4 Einf hrung von Feldern 91 Beispiele FOREACH i IN 2 XDIM 1 LET DIFFERENTIAL EQUATION X i 2 x X i X i 1 X i 1 END END Die Ableitung der Feldelemente X i ermittelt sich aus den Werten des Feldelements und dessen Nachbarn FOREACH i IN 1 M j IN 1 N LET Y i j A i j B i j END Die Werte der Feldelemente Y i j ergibt sich zu jedem Zeitpunkt aus der Summe der Feldelemente Ali j und B i j FOREACH i IN 1 10 LET Z i TRUE WHEN X i gt 0 AND Z i FALSE END END Sobald f r irgendein i die Variable X i positiv wird wird Z i auf TRUE gesetzt und nicht mehr zur ckgenommen Wenngleich der Allquantor sehr an das Sch
329. ur Indices als gebundene Variable zuzulassen Die Formu lierung eines Modells wird jedoch wesentlich tibersichtlicher wenn die gebundene Variable auch mobile Komponenten repr sentieren kann 5 3 7 Der implizite Allquantor H ufig ist die Selektion von Variablen oder mobilen Elementen allein durch die Angabe von evtl eingeschr nkten Indexbereichen m glich In diesen F llen erm glicht der implizite Allquantor eine besonders kompakte und bersichtliche Beschreibung Methodologisch gese hen w re er nicht erforderlich da bereits das FORALL Konstrukt alle seine M glichkeiten mit einschlie t 5 3 Beschreibung der Modelldynamik in Basiskomponenten 203 Der implizite Allquantor ist sowohl auf Wertzuweisungen als auch auf Transportanweisungen anwendbar Er besagt daf eine solche Aussage nicht nur fiir einen einzigen Index sondern fiir eine ganze Menge von Indices Giiltigkeit besitzt index index_expression implicit_indexset implicit_indexset index_range identifier IN index_range condition Bei zu definierenden Variablen in Wertzuweisungen Quellbest nden in Transportanweisungen Elementen aus Quellbest nden in Transportanweisungen mit unterscheidbaren Ele menten darf anstelle eines Indexausdrucks in eckigen Klammern eine Indexmenge in geschweiften Klammern stehen Die Angabe einer Indexmenge hinter einem Element entspricht dabei syntaktisch und se mantisch
330. urse_specific_declaration Der Zeitverlauf eines Bestands kann diskret sprunghaft oder kontinuierlich stetig sein In der Regel wird der Zeitverlauf diskret sein ein konstanter Verlauf macht bei Best nden keinen Sinn loc_course_specific_declaration DISCRETE variable_declaration_list CONTINUOUS variable_declaration_list Die weitere Deklartion ist f r Attribute und Best nde identisch 196 5 Systematische Darstellung der Modellbeschreibungssprache variable_declaration_list variable_declaration variable_declaration variable_declaration ARRAY dimension_list identifier value_set initial_value ARRAY dimension_list identifier value_set distribution Durch die Angabe von Dimensionen kann jede Variable als mehrdimensionales Feld ver einbart werden Als Feldgrenzen sind konstante Zahlenwerte oder geklammerte Ausdriicke erlaubt die sich bereits zur bersetzungszeit berechnen lassen dimension_list index_range index_range index_range constant_integer constant_integer constant_integer operand Die anzugebende Wertemenge kann um eine physikalische Ma einheit erg nzt werden value_set INT unit REAL unit LOGICAL identifer SET OF identifier ordering_criteria Best nde die individuelle Elemente enthalten sind als Warteschlange organisiert Ohne
331. us f r einen Parallel rechner dienen kann Dies ist nicht weiter verwunderlich wenn man bedenkt da Ereignisse gleichzeitig ausf hrbare Zuweisungen sind Weiterhin stellt man fest da man sich beim Abfassen der Beschreibung quasi auf den Standpunkt einer beliebigen Variablen stellt und deren Ver nderung beschreibt Diese Vor gehensweise ist typisch f r die Beschreibung des Verhaltens von Modellvariablen 98 3 Spracherweiterungen zur Formulierung von Warteschlangenmodellen Die getroffenen Einschr nkungen m gen sehr restrikiv erscheinen stellen aber keine prinzi piellen Beschr nkungen dar was die Formulierbarkeit von Modellen anbelangt Insbesondere erleichtern sie auch die Pr fung auf Vollst ndigkeit da bekannt ist f r welche Feldindices eine Variable definiert ist Wenn abh ngige Variablen zu definieren sind ist als weitere Einschr nkung lediglich zu fordern da keine Bedingung den Indexbereich eines FOREACH Konstrukts einschr nken darf Beispiel FOREACH i IN 1 10 Z i gt 0 LET Mit 213 END Die abh ngigen Variablen X i sind nur definiert falls Z i gt 0 ist Eine korrekte Formulierung k nnte folgenderma en aussehen Beispiel FOREACH i IN 1 10 LET IF Z i gt 0 LET X i Z i END ELSE LET X i 0O END END Die abh ngigen Variablen X i sind im gesamten Zustandsraum definiert da der ELSE Teil nicht fehlt Zusammenfassung Das Sicherstellen der Eindeutigkeit erfordert bei
332. usf hrlich eingegangen 140 4 Transporte zwischen Best nden 4 3 Beschreibung von Transporten zwischen Best nden Es wurde bereits festgestellt da sich Transporte durch eine einzige Transportoperation oder durch zwei verteilte Wertzuweisungen Wegnehmen und Hinzuf gen beschrieben werden k nnen In diesem Abschnitt wird diese Thematik sowohl in allgemeiner Form als auch f r die Spezialf lle kontinuierlicher diskreter und elementweiser Transport abgehandelt 4 3 1 Allgemeine Betrachtungen Gegeben seien Mengen von Best nden B Ba zwischen denen Elemente ausgetauscht werden ar e Na Mittels einer Transportfunktion T j beschreiben wir die Transportmenge welche zum aktu ellen Zeitpunkt zwischen Bestand B und Bestand B ausgetauscht wird Je nachdem welchen Standpunkt man einnimmt kann der Transport als Zustands nderung auf zwei unterschiedliche Weisen formal sprachlich beschrieben werden F r einen Transport zwischen zwei einzelnen Best nden ergibt sich a Bestandsbezogene Beschreibung eine Gleichung pro Bestand B_i T_ij B_j Bj T_ij b Transportbezogene Beschreibung eine Gleichung pro Transportweg B_i gt B_j T_ij 4 3 Beschreibung von Transporten zwischen Best nden 141 Findet auch ein Transport in der Gegenrichtung statt geht die zus tzliche Transportmenge Tj in die bestandsbezogene Beschreibung als weiterer Term und in die transportbezogene Beschreibung als weitere
333. ustands bergangs a bestandsbezogen B 17 BI T 12 181 B_2 B_2 T_12 Boo B_3 T_13 durch Angabe der Differenzen DELTA B_1 T_12 T_13 DELTA B_2 T_12 DELTA B_3 T_13 komponentenweise CHANGE B_1 T_12 CHANGE B_2 T_12 CHANGE B_1 T_13 CHANGE B_3 T_13 b transportbezogen B_1 gt B_2 T_12 B_1 gt B_3 T_13 Die Eindeutigkeit ist auch hier soweit sichergestellt Mehrdeutige Formulierung wie sie etwa das folgende Beispiel zeigt k nnen wie bereits besprochen vom Compiler erkannt und angemahnt werden Beispiel IF cond_12 LET B_1 Bud n_12 B_2 B_2 n_12 END IF cond_23 LET B_2 B_2 n_23 B_3 B_3 n_23 END Der Bestand B_2 ist mehrdeutig bestimmt wenn die Transportbedingungen cond_12 und cond_23 gleichzeitig erf llt sind 4 4 3 Mengenweiser Transport Wir betrachten den Fall da beim Eintritt einer Bedingung eine Teilmenge aus dem Bestand B nach B und beim Eintritt einer anderen Bedingung eine andere Teilmenge aus B nach B gebracht werden soll 4 4 Diskussion der Eindeutigkeit am Problem der Verteilung 151 Beispielsweise sollen bei leerem Bestand B bis zu f nf Auftr ge des Typs A Bedingung cond_12 nach B und bei leerem Bestand B3 bis zu zehn Auftr ge des Typs B Bedingung cond_13 nach B3 gebracht werden Job Typ A T_12 JINB_1 J Typ A AND cond_12 EMPTY B_2 Job 1i 5 Job Typ B T_1
334. werden durch Sensorvariablen ersetzt 2 6 Modularisierung 59 Beispiel Ein Modell mit z f y_1 y_2 zZ vol g z y 2 g y_1 z soll in zwei Komponenten zerlegt werden Eine Komponente soll die Variablen z und y_2 enthalten die andere y_1 Komponente A Komponente B z s On A y_1 g x_B yo g xA z Die Sensorvariablen x_A und x_B wurden hierzu neu eingef hrt Durch diese Art der Modularierung werden Modelle geschaffen bei denen der Verlauf der Eingangsfunktionen nicht n her bestimmt ist Ein Gesamtmodell entsteht wenn die beiden Komponenten im Verbund betrieben werden Hierzu liefern die abh ngigen Variablen und Zustandsvariablen der einen Komponente den Zeitverlauf f r die Sensorvariablen der anderen Komponente Die Modellbeschreibung ist daher zu erg nzen und den Sensorvariablen jeweils eine inter ne Variable einer anderen Komponente zuzuordnen Unter internen Variablen verstehen wir Zustandsvariablen und abh ngige Variablen da diese der Komponente selbst zugerechnet werden Aus der Sicht einer Komponente ist hingegen eine Sensorvariable eine externe Va riable Beispiel xA yil xB Z Da jede Komponente eine abgeschlossene Einheit darstellen soll ist es natiirlich wiinschens wert da sich die Bezeichner nicht von denen anderer Komponenten unterscheiden m ssen Damit im Gesamtmodell Variablen mit gleichen Namen unterscheidbar bleiben wird der Komponentennamen hinzugezoge
335. xt aufgenommen Es ist zu unterscheiden ob Tabellenfunktionen ein zwei oder mehrdimensional sind und ob sie einen kontinuierlichen oder diskreten Verlauf beschreiben Kontinuierliche Verl ufe sind zwischen den St tzstellen zu interpolieren Dabei hat es sich als ausreichend erwiesen vier verschiedene Arten der Interpolation anzubieten 222 6 Spracherweiterungen fiir den praktischen Einsatz stufenf rmige lineare kubische Bessel kubische Spline Interpolation Mit zunehmender Reihenfolge wird im Kurvenverlauf eine weitere Ableitung stetig Die Verwendung von Tabellenfunktionen mit mehr als zwei Eingabeparametern ist sehr un gew hnlich Damit das Datenmaterial nicht zu umfangreich wird zieht man es in der Regel vor in einem solchen Fall mit approximierenden Funktionen zu arbeiten auch wenn diese oft nicht sonderlich genau sind Aus diesem Grund erscheinen Tabellenfunktionen mit mehr als zwei Dimensionen verzichtbar Beispiele TABULAR FUNCTION Parabel REAL gt REAL CONTINUOUS BY CUBIC BESSEL INTERPOLATION ON 1 5 1 0 0 5 0 0 0 5 1 0 1 5 gt 2 25 1 0 0 25 0 0 0 25 1 0 2 25 TABULAR FUNCTION Not LOGICAL gt LOGICAL ON FALSE TRUE gt TRUE FALSE TABULAR FUNCTION And LOGICAL LOGICAL gt LOGICAL ON FALSE TRUE FALSE gt FALSE FALSE TRUE gt FALSE TRUE Kontinuierliche Tabellenfunktionen lassen sich noch dahingehend verbessern da man U
336. ysteme Kompo nenten zerlegt ist Die Knoten des Graphen repr sentieren die nicht verbundenen Sensorvariablen 2 t die abh ngigen Variablen y t und die Zustandsvariablen z t bzw zi tk 1 die Kanten stellen die funktionalen Abh ngigkeiten dar Der Graph ist gerichtet und beginnt mit den Gr en die den Zustand zum Zeitpunkt t kenn zeichnen d h mit den Zustandsvariablen z t und der Zeit t dargestellt in rechteckigen K stchen Er endet mit den Zustandsvariablen z t zum n chsten Zeitpunkt Dazwischen liegen die nicht angeschlossenen Sensorvariablen x t und die abh ngigen Variablen y t markiert durch Kreise Beispiel Die funktionalen Abh ngigkeiten der Modellgr en ze er te yi tk gi X1 21 Y2 tx go z1 22 y3 tk 93 1 alte file y3 Zo tegi Falz2 ye lassen sich durch den folgenden Graphen darstellen tk gt x1 ty tk 1 0 Gs Ga fre z t Te Yaltk gt 22 ter 7 Wenn nun in einer algebraischen Funktion abh ngige Gr en auftauchen die noch nicht definiert wurden dann bedeutet das da der Graph einen R ckw rtsverweis enth lt Mit anderen Worten der Graph ist dann nicht mehr zyklenfrei 2 2 Semantische Korrektheit Beispiel Reihenschaltung zweier Widerst nde u R 39 U2 ie Ry
337. z_i Flag TRUE z_i Flag FALSE ende F r eine manuelle Programmierung ist diese L sung wohl eher geeignet da sie einen einfachen schematischen Aufbau besitzt Von besonderer Bedeutung f r das bersetzen der Modellbeschreibung in einen ausf hrba ren Code hat sich das Aufstellen des Abh ngigkeitsgraphen erwiesen Basierend auf dem Abh ngigkeitsgraphen wird die Zyklenfreiheit der Modellbeschreibung berpr ft die alge braischen Gleichungen geordnet und durch das Einbringen dynamischer Marken optimaler Code erzeugt Es empfiehlt sich auch die zeitabh ngigen Sensorvariablen mit in den Abh ngigkeitsgraph aufzunehmen und genauso wie die abh ngigen Gr en zu behandeln Der Ubersichtlichkeit 2 5 Algorithmus f r die Simulation einer expliziten Modelldarstellung 57 halber wurde im Beispiel jedoch auf diese Gr en verzichtet Die Ausf hrungen haben gezeigt da es m glich ist das vorgestellte Programmiermodell effizient zu bearbeiten Der dazu erforderliche Code l t sich ohne Schwierigkeit von einem Compiler erzeugen Die Anzahl der zur Laufzeit ausgef hrten Operationen ist minimal und kann durch manuelle Programmierung nicht weiter reduziert werden Allerdings h ngt der Effekt den die eben geschilderten Verbesserungen bringen sehr stark davon ab wie viele Zustandsvariablen zu einem Zeitpunkt ihren Wert ver ndern In einem kontinuierlichen Modell oder einem zeitlich getakteten Modell ndern sich in der Regel m
338. zierten Modelldarstellung Sie ist gekenn zeichnet durch Beziehungen der Form Sensorvariablen Tilt i tk Zustandsvariablen elimi Si l X te Y t Z t tk abh ngige Variablen y t gi X t Y t Z t tk Eingangsgr en hei en fortan nur noch Sensorvariablen Ihnen wird eine Zeitfunktion Sen sorfunktion zugeordnet wenn die Gr e nicht angeschlossen ist Ausgangsgr en erhalten eine etwas andere Bedeutung da sie nun auch als Zwischengr en fungieren k nnen und nicht mehr die einzigen Gr en sind die nach au en gegeben werden k nnen Aus diesem Grund wollen wir in Zukunft von abh ngigen Variablen sprechen Abh ngige Variablen d rfen sowohl zur Berechnung von Zustandsvariablen als auch von anderen abh ngigen Variablen verwendet werden Ihre Definitionsgleichungen bezeichen wir als statische Beziehungen oder algebraische Gleichungen die Funktion zu ihrer Berechnung entsprechend als algebraische Funktion Zustandsvariablen werden durch Zustands berf hrungsfunktionen definiert und die Defini tionsgleichungen zu ihrer Berechnung als dynamische Beziehungen bezeichnet Weiterhin wollen wir zulassen da auch Zustandsvariablen mit Sensorvariablen verbunden werden d rfen Aus der Verwendung von abh ngigen Variablen in Zustands berf hrungsfunktionen ergeben sich berhaupt keine Probleme denn der zu berechnende neue Zustand zum Zeitpunkt tk 1 geht aus dem bereits bekannten aktuel
339. zungen der Sprache und des Paradigmas zu beheben Im vierten Kapitel wird diskutiert auf welche Wei se Transportvorg nge insbesondere bei modularer Modellzerlegung beschrieben werden k nnen Das f nfte Kapitel fa t den Sprachentwurf zusammen und stellt ihn systematisch dar Das sechste Kapitel spricht Spracherweiterungen an die erforderlich sind um die Spra che f r praktische Anwendungen einsetzen zu k nnen Schlie lich werden im siebten Kapitel 2 1 Einleitung anhand von vollst ndigen Beispielen die Einsatzm glichkeiten der Sprache aufgezeigt In der Zusammenfassung wird zuletzt ein Resumee gezogen und geschildert inwieweit die gesetzten Ziele erreicht werden konnten 1 1 Aufgabenfelder der Simulationstechnik Simulieren hei t Experimentieren mit Modellen An die Stelle eines realen oder fiktiven Systems originales System tritt ein Simulationsmodell Mit diesem werden Experimente durchgef hrt und man hofft auf Ergebnisse die denen des originalen Systems entsprechen Simulation auf Digitalrechnern bedeutet da mit Hilfe eines auf einem Rechner ablaufen den Simulationsprogramms Experimente durchgef hrt und Ergebnisse gewonnen werden Das Simulationsprogramm basiert auf einer gedanklichen Modellvorstellung vom origina len System die in mathematisierter Form in graphischer Form oder auch in rein informeller verbaler Form vorliegen kann Die Modellvorstellung erh lt man durch Analyse von Beobachtungen Messung

- Simplex3

Contents

Download Pdf Manuals

Related Search

Related Contents