Peter Lorenz English smaller fonts Simulation und Animation

4.1. Transaktionen und Einrichtungen

4.1.1. Joe's Barbershop
Im Kapitel 3 ist GPSS/H als eine einfache Programmiersprache mit besonders gut entwickelten Möglichkeiten zur Zufallszahlenerzeugung behandelt worden. Nun beginnt seine Nutzung als echtes Simulationssystem.
Joe's Barbershop ist ein praktisches Beispiel für einen Single Server oder ein einkanaliges Bedienungssystem. Es wird dazu benutzt, um die Grundideen der diskreten ereignisorientierten Simulation zu erklären.
Dieses Einführungsbeispiel wurde erstmals in dem legendären, weltweit verbreiteten Lehrbuch von Thomas J. Schriber Simulation Using GPSS, Wiley & Sons 1974 vorgestellt und danach von vielen anderen Lehrbuchautoren übernommen.
4.1.2. Klassen von Modellelementen
Simulationssysteme besitzen in der Regel vordefinierte Klassen von Modellelementen und erlauben oft auch dem Nutzer, eigene Modellelementklassen zu definieren. Modelle werden dann aus Instanzen der Klassen gebildet. Hier wird ein Überblick über GPSS/H-Modellelementklassen oder Objektklassen gegeben und mit der genaueren Betrachtung von zwei Klassen begonnen: Transaktionen und Einrichtungen.
4.1.3. Transaktionen
(Transactionsoder Xacts) sind dynamische, aktive und universell nutzbare Modellelemente.
Transaktionen werden durch GENERATE -Blöcke erzeugt.
4.1.4. Einrichtungen
oder Facilities benutzt man, um einkanalige Bedienungssysteme oder Single Server nachzubilden. Joe und Jim ist ein Beispiel für ein Modell mit zwei getrennt und voneinander völlig unabhängig arbeitenden Bedienungssystemen.
4.1.5. Single-Server-Animation
ist ein Programmbeispiel, in dem Simulation und Animation zusammengeführt werden. Wie muß ein Simulationsmodell erweitert werden, um ein Animationstracefile oder ATF-Kommandos zu schreiben? Die Antwort auf diese Frage wird hier für das Single-Server-Modell gegeben. Ein Schnappschuß einer Animation wird als Bild vorgestellt.

4.1.1. Joe's Barbershop Top Line

Systembeschreibung
Modell
Kurze Erklärung
Standardausgabe
Resultate

Chicago Florida
Joe's Barbershop am Al-Capone-Show-Theater in Chicago Joe's Barbershop in Florida
mit frdl. Genehmigung von Alf Ritter mit frdl. Genehmigung von Tobias Isenberg

Im folgenden soll eine Version des oft gebrauchten Einführungsbeispiels in die Simulation von Bedienungssystemen beschrieben und anschließend als GPSS/H-Modell vorgestellt werden.

SystembeschreibungTop Line

Joe arbeitet in seinem Salon allein. Kunden kommen alle 18+-6 Minuten. (Damit ist eine im Intervall von 12 bis 24 gleichverteilte Pausen- oder Zwischenankunftszeit gemeint.)
Ankommende Kunden brauchen 1/2 Minute, um ihren Mantel aufzuhängen. Wenn Joe frei ist, beginnt nun die Bedienung. Sonst warten die Kunden in einer Warteschlange. Wer zuerst angekommen ist, wird zuerst bedient (FIFO: First In - First Out oder FCFS: First Come - First Served. Joe braucht zur Bedienung eines Kunden 15+-3 Minuten. Die Kunden verlassen Joe's Salon, sobald die Bedienung beendet ist.
Wie lange dauert es, 100 Kunden zu bedienen?

ModellTop Line

Hier wird das Quelltextfile JOEBARB.GPS wiedergegeben. Alle GPSS/H-Quelltextfiles sollten mit der Namenserweiterung .GPS gekennzeichnet werden. Mit dem folgenden Text können Experimente ausgeführt werden: Man kann Werte von Konstanten ändern, neue Anweisungen einführen oder den enthaltenen Text komplett gegen einen anderen Text austauschen.


SLX-Modell von Joe's Barbershop

Kurze Erklärung des GPSS/H Programms Top Line

SIMULATE
ist eine Steueranweisung, die veranlaßt, dass das folgende Modell nicht nur compiliert, sondern auch ausgeführt wird. Ohne diese Anweisung wird nur übersetzt und das übersetzte Programm wird nicht ausgeführt.
GENERATE
ist eine Blockanweisung oder ein Block. Dieser Block erzeugt Transaktionen. Transaktionen sind aktive, dynamische Modellelemente oder Entities. Das interne Steuersystem von GPSS/H bewegt die Transaktionen von Block zu Block. Die Operanden 18,6 beschreiben die Zwischenankunfts- oder Pausenzeit zwischen zwei zu erzeugenden oder eintreffenden Transaktionen. Diese Zeiten sind gleichverteilt im Intervall (12, 24).
ADVANCE
ist ein Block, der die Bewegung einer ihn betretenden Transaktion um eine Zeit verzögert, die durch seine Operanden bestimmt ist. Der Operand 0.5 bestimmt oder spezifiziert eine Zeitverzögerung um 0.5 Einheiten der simulierten Zeit. Die Operanden 15,3 spezifizieren eine Gleichverteilung der Verzögerungs- oder Wartezeit im Intervall (12, 18).
SEIZE
ist ein Block, der die in seinem Operanden spezifizierte Einrichtung oder Facility (JOE) belegt, wenn diese frei ist. Wenn die Einrichtung gerade benutzt, d.h. durch eine andere Transaktion belegt ist, kann die eintreffende Transaktion den SEIZE -Block nicht betreten, sondern muß warten. Sie hat zu warten, bis die Bedingung Einrichtung frei oder Facility Not Used (FNU )eintritt.
RELEASE
ist ein Block, der die Einrichtung freimacht, sobald er von einer Transaktion betreten wird. Zur selben Zeit wird allen wartenden Transaktionen der Versuch erlaubt, die Einrichtung zu betreten.
TERMINATE
ist ein Block, der die ihn betretende Transaktion vernichtet oder aus dem Modell entfernt. Ihr weiteres Schicksal kann nun nicht mehr verfolgt werden. Der Startzähler oder Termination Counter wird um den Wert des Operanden diesesTERMINATE Blocks verringert.
START
ist eine Steueranweisung, die den Simulationslauf startet und beendet. Ihr Operand ist der Anfangswert des Startzählers. Jedesmal, wenn eine Transaktion einen TERMINATE -Block betritt, wird der Wert des Startzählers um den Wert des Operanden von TERMINATE verringert. Die Simulation bricht ab, wenn der Startzähler kleiner oder gleich Null wird. Im vorliegenden Beispiel endet die Simulation, nachdem der 100. Kunde fertig bedient ist und Joe's Salon verläßt.
END
ist eine Steueranweisung, die das Ende des Quelltextfiles und damit des GPSS/H Modells anzeigt.

Joe's Barbershop: StandardausgabeTop Line

Jede Compilierung erzeugt in der Regel (nach Default-Compilerdirektive) eine Standardausgabe. Die Standardausgabe ist eine Ergebnisliste, die als Datei oder File verfügbar ist. Dieses File trägt den Namen des Quelltextfiles mit der Namenserweiterung .LIS. Zum Quelltext JOEBARB.GPS gehört also das Ergebnisfile JOEBARB.LIS.
Die Standardausgabe beginnt mit einem Compilerprotokoll. Das Compilerprotokoll hat in seinen ersten Spalten drei Zähler: Zeilen, Anweisungen (Statements) und Blöcke werden gesondert gezählt. Wenn der Quelltext Syntaxfehler enthält, erscheinen Fehlermeldungen. Wenn der Quelltext syntaxfehlerfrei ist, wird eine Resultatausgabe angefügt. Sie enthält
Clock Values,
die Werte zweier Simulationsuhren, derabsoluten und der relativen Zeit am Ende des Simulationslaufes,
Block Statistics,
die Blockstatistik mit der aktuellen Anzahl der in jedem Block am Ende des Simulationslaufes vorhandenen und der kumulativen Anzahl der während des Simulationslaufes eingetretenen Transaktionen,
Statistiken für jede Klasse
von statischen, permanenten Modellelementen, im vorliegenden Beispiel sind das nur die Einrichtungen oder Facilities sowie
Random Number Stream Report
mit speziellen Informationen über die Zufallszahlenerzeugung und
Status of Common Storage,
den Bericht über die Inanspruchnahme des gemeinsamen Speicherbereiches, der vorwiegend von Transaktionen benutzt wird.
Elapsed Time
informiert über den Rechenzeitverbrauch für die Simulation. Diese Angaben sind für größere Modelle von besonderem Interesse, wenn durch eine Vielzahl von Simulationsläufen statistische Sicherheit gewonnen werden soll. Anzumerken ist hier, das GPSS/H einer der schnellsten Simulatoren im Bereich der diskreten Simulation ist.
Listen von Transaktions-Ketten
können sehr lang werden und erscheinen nur dann,
wenn der Simulationslauf wegen eines Laufzeitfehlers vorzeitig abbricht oder
wenn die Ausgabe durch einen Operanden der START-Anweisung ausdrücklich angefordert ist.

Resultatdatei des EinführungsmodellsTop Line

Im folgenden wird die vom Simulationssystem GPSS/H erzeugte Resultatdatei vollständig wiedergegeben. Man erhält die gleiche Datei beim Start des obenstehenden Programms.

Die wichtigsten Resultate dieses Simulationsexperiments lauten:
Es hat 1780.6667 Minuten gedauert, bis die Bedienung des 100. Kunden abgeschlossen war.
Die mittlere Bedienungsdauer betrug 15.149 Minuten.

Wenn man diese Resultate kritisch bewertet, ist folgendes festzustellen:

  1. Die Resultate sind zufallsabhängig. Mit einer anderen Serie von Zufallszahlen ergeben sich andere Resultate.
  2. Es gibt keine Aussagen über mittlere und maximale Länge einer Warteschlange von Kunden.
  3. Es gibt keine Aussagen über die Aufenthaltsdauer der Kunden in Joe's Laden.

Diese Probleme werden in folgenden Abschnitten zu beachten sein.

  1. Aussagen über die Zufallsabhängigkeit der Resultatdaten gewinnt man durch Serien von Zufallsexperimenten.
  2. Aussagen über Eigenschaften einer Warteschlange gewinnt man durch die Einführung von Warteschlangen in das Modell.

4.1.2. Modellelementklassen Top Line

Das oben vorgestellte Modell eines Frisiersalons nutzt zwei Typen oder Klassen von Modellelementen: Transaktionen (engl. Transactions oder Xacts) und Einrichtungen (engl. Facilities).

Alle im GPSS/H auftretenden Objekte oder Modellelemente sind Repräsentanten (Inkarnationen) vordefinierter Klassen. Die wichtigsten Modellelementklassen sind Transaktionen, Einrichtungen, Warteschlangen, Speicher, Logikschalter, Tabellen, Nutzerketten, Gruppen, Skalare, Matrizen.

Die Objekte jeder Klasse sind identifizierbar durch
1. eine bei 1 beginnende, fortlaufende Zählnummer und
2. einen Namen, falls der Nutzer einen vergeben hat.
So gibt es Einrichtungen mit den Nummern 1, 2, 3, . . . und Warteschlangen mit den Nummern 1, 2, 3, . . . Die Einrichtung 1 kann z. B. den Namen JOE haben. Lediglich die Transaktionen haben nur eine Nummer, aber keinen Namen.
GPSS/H erlaubt nur Großbuchstaben für Operationssymbole, Operanden und vom Nutzer vergebene Namen. Ein Name beginnt mit einem Buchstaben und besteht aus höchstens 8 Buchstaben oder Ziffern.
Jede Klasse hat einen Satz von Standardattributen. Das sind klassenspezifische Größen, die durch einen festliegenden Bezeichner identifiziert werden. QM(SCHL) bezeichnet z. B. den im Verlauf der Simulation beobachteten Maximalwert der Länge einer Warteschlange mit dem vom Nutzer gewählten Namen SCHL . Man muß diese vordefinierten Bezeichner von Standardattributen bei der Auswahl eigener Namen vermeiden. Entsprechend ihrer Wertetypen hat man zu unterscheiden zwischen
Numerischen Standardattributen (Standard Numerical Attributes, SNA)
z.B. bezeichnet XID1 die Identifikationsnummer einer Transaktion oder FR(JOE) die mittlere Auslastung der Einrichtung JOE in Promille.
Logischen Standardattributen (Standard Logical Attributes, SLA)
z.B. FNU(JOE): Facility JOE is Not Used, JOE ist gerade frei.
Zeichenketten-Standardattributen (Standard Character Attributes, SCA)
z.B. SYM(FAC,1) : der symbolische Name der Einrichtung 1 (z.B. JOE).
Einige Standardattribute kann man nur lesen, während man andere auch schreiben kann.

Als Beispiele kann man sich die Standardattribute von Einrichtungen und Warteschlangen anschauen.

Ausgewählte Modellelementklassen Top Line

Transaktionen
(Transactions oder Xacts) sind bewegliche, temporäre und universell verwendbare Modellelemente.
Einrichtungen
(Facilities) bilden eine Klasse stationärer, permanenter, spezieller Objekte. Eine Einrichtung kann gleichzeitig nicht mehr als eine Transaktion aufnehmen.
Warteschlangen
(Queues) dienen der Sammlung statistischer Daten über Warte- oder Verzögerungszeiten von Transaktionen.
Speicher
(Storages) kann man benutzen, um eine multiple Bedienungsstation nachzubilden, die gleichzeitig mehrere Einheiten aufnehmen kann.
Logische Schalter
(Logic Switches) sind Signalelemente, die nur zwei Zustände annehmen können.
Tabellen
(Tables) nutzt man zur Erfassung statistischer Daten in Häufigkeitstafeln oder Histogrammen. Sie dienen der Berechnung von Mittelwerten und Standardabweichungen.
Nutzerketten
(User Chains) dienen der nutzereigenen Steuerung des Ablaufs der Simulation.
Gruppen
(Groups) sind Mengen von Werten oder von Transaktionen. Man kann sie zum Austausch von Nachrichten zwischen Transaktionen benutzen.
Simulationsuhren
Absolutzeit (Absolute Clock) AC1 und Relativzeit (Relative Clock) C1 werden von der Internen Steuerung des Simulationssystems verwaltet. Sie spielen bei der Steuerung der Reihenfolge der Ausführung von Algorithmen, bei der Steuerung des Laufes der Transaktionen durch die Blöcke, eine zentrale Rolle.

4.1.3. Transaktionen Top Line

Allgemeine Eigenschaften
Blöcke und Transaktionen
Ketten von Transaktionen
Bewegung von Transaktionen
Ausgewählte Numerische Standardattribute
Standardausgabe von Transaktionen
GENERATE-Block
TERMINATE-Block
ADVANCE-Block
Kontrollfragen über Transaktionen

Allgemeine EigenschaftenTop of the Paragraph

Transaktionen bilden die wichtigste Klasse von Modellelementen. Sie kommen in jedem GPSS-Modell vor. Wenn keine Transaktion mehr vorhanden ist oder sich bewegen kann, bricht die Abarbeitung des Modells, der Simulationslauf, mit einer Fehlermeldung ab.
Transaktionen sind aktive, bewegliche, temporäre und universelle Modellelemente. Sie sind
aktiv,
weil sie Aktionen auslösen können, die von anderen, passiven Modellelementen auszuführen sind,
beweglich oder dynamisch,
weil sie gewöhnlich keinen festen Platz in der simulierten Welt besitzen, sondern sich zwischen derartigen Plätzen bewegen,
temporär,
weil sie gewöhnlich nicht während des ganzen Simulationslaufes existieren, sondern während dieses Laufs erzeugt und später wieder vernichtet werden,
universell oder generell,
weil man sie mit beliebigen Eigenschaften oder Attributen ausstatten kann und weil man ihren Lebenszyklus frei bestimmen kann, indem man Folgen von Blöcken aufschreibt, die sie zu durchlaufen haben.
Transaktionen können Fahrzeuge, Kunden, Aufträge, Gabelstapler, Container oder Schiffe darstellen oder repräsentieren. Transaktionen bewegen sich von Block zu Block; während ihrer gesamten Lebenszeit sind sie nie ohne momentane Bindung an einen Block.
Transaktionen unterscheiden sich von allen anderen Klassen von Modellelementen. Die Elemente anderer Klassen (Einrichtungen, Speicher, Warteschlangen, ... ) werden oft Ressourcen genannt. Ressourcen sind

Transaktionen und Blöcke Top Line

Die oben genannte Beweglichkeit von Transaktionen bezieht sich auf Blöcke, die in jedem Modell vorkommen und sichtbar sind. Man kann sich zunächst vorstellen, dass jede Transaktion immer an irgendeinem Block steht und nach ihrer Erzeugung oder nach ihrer Reaktivierung versucht, möglichst viele darauffolgende Blöcke zu durchlaufen.

Zwei Blöcke, GENERATE und SPLIT , können Transaktionen erzeugen und die Zeitpunkte ihrer Einführung in das Modell festlegen.
Zwei andere Blöcke, TERMINATE und ASSEMBLE, können Transaktionen vernichten.
Einige Blöcke (z. B. SEIZE, GATE, TEST, ENTER) können Transaktionen zeitweilig den Zutritt verweigern und damit ihren Lauf durch das Modell verzögern.

Der ADVANCE- Block verzögert den Lauf einer Transaktion um eine in seinen Operanden festgelegte Zeitdauer.

TransaktionskettenTop Line

Transaktionen gehören während ihrer gesamten Lebensdauer verschiedenen Ketten an.
  1. Die Zukünftige Ereigniskette (Future Events Chain, FEC) ist eine Liste von Transaktionen, für die ein zukünftiger Zeitpunkt zur Fortsetzung ihrer Aktionen geplant ist.
  2. Die Aktuelle Ereigniskette (Current Events Chain, CEC) ist die Liste aller Transaktionen,
    • deren Aktivierung für den aktuellen Zeitpunkt der simulierten Zeit geplant ist oder
    • die zu einem früheren Zeitpunkt am Betreten eines Blockes gehindert worden sind.
  3. Die Unterbrechungskette (Interrupt Chain) enthält alle Transaktionen, deren Aufenthalt in einer Einrichtung durch eine andere Transaktion unterbrochen worden ist.
  4. Benutzerketten (User Chains) enthalten Transaktionen, deren Aktivität der Benutzer des Simulationssystems selbst steuern möchte.
  5. Matchketten enthalten alle Transaktionen eines Verbandes, die auf andere Transaktionen desselben Verbandes warten. Das geschieht in Verbindung mit den Blöcken MATCH, ASSEMBLE, GATHER.

Bewegung von TransaktionenTop of the Paragraph

Das interne Steuerungssystem von GPSS/H verwaltet die Transaktionen und steuert deren Aktionen. Anhand der Zukünftigen Ereigniskette FEC bestimmt es den nächsten Ereigniszeitpunkt und setzt die für diesen Zeitpunkt geplanten Transaktionen von der FEC in die CEC um.
Dann verarbeitet es die Transaktionen der CEC in der Reihenfolge, in der sie dort gespeichert sind. Jede Transaktion der CEC wird von ihrem aktuellen Ausgangsblock soweit von Block zu Block bewegt, bis ihre Bewegung unterbrochen wird. Für eine Unterbrechung gibt es folgende Ursachen:
  1. ein ADVANCE -Block überführt die Transaktion in die FEC,
  2. ein SEIZE-, ENTER-, GATE-, TEST-, GATHER-, oder MATCH- Block veranlaßt das Warten auf eine Bedingung,
  3. ein LINK -Block überführt die Transaktion in eine Benutzerkette oder
  4. ein TERMINATE- oder ein ASSEMBLE -Block zerstört die Transaktion.
Nachdem die aktuelle Transaktion bei einem Block angelangt ist, der eine Weiterbewegung zum aktuellen Zeitpunkt verhindert, wendet sich die interne Steuerung der nächsten Transaktion der CEC zu. Wenn keine Transaktion der CEC bewegt werden kann, wendet sich die interne Steuerung der FEC zu, sucht dort den nächsten Ereigniszeitpunkt und stellt die Simulationsuhren auf den neuen, aktuellen Ereigniszeitpunkt ein.

Ausgewählte Numerische StandardattributeTop of the Paragraph

Transaktionen haben mehrere Attribute. Im folgenden werden einige der stets vorhandenen Attribute einer Transaktion beschrieben. Darüber hinaus kann der Nutzer sie mit einer von ihm gewünschten Anzahl von Parametern verschiedenen Typs ausstatten. Näheres darüber erfährt man im Abschnitt 4.5. Attribute von Transaktionen, der auch eine vollständige Übersicht über die Attribute von Transaktionen enthält.

XID1Identifikationsnummer der Xact
PRPriorität
M1Laufzeit seit der Erzeugung oder seit dem Eintritt in einen MARK-Block (Transit time)

Standardausgabe von TransaktionenTop of the Paragraph

Die nach jedem Simulationslauf im LIS-File automatisch erzeugte Standardausgabe enthält gewöhnlich keine Informationen über Transaktionen. Für die am Ende des Laufes im Modell verbliebenen Transaktionen erhält man nur dann eine Übersicht, wenn der Simulationslauf wegen eines Laufzeitfehlers abbricht oder die START -Anweisung als vierten Operand eine 1 enthält. Das folgende Beispiel erzeugt drei Transaktionen und bricht ab, wenn noch zwei im System vorhanden sind.


GENERATE Top of the Paragraph
ist einer der beiden Blöcke (oder Blockanweisungen), die Transaktionen erzeugen.
Noch zum Zeitpunkt Null der simulierten Zeit, unmittelbar nach dem Start der Blockverarbeitung, welche durch eine START -Anweisung ausgelöst wird, erzeugt jeder vorhandene GENERATE-Block seine erste Transaktion. Ihr erster Aktionszeitpunkt wird auch als Erzeugungs-, Eintritts- oder Ankunftszeitpunkt bezeichnet. Er ist durch die Operanden A und B des GENERATE -Blockes festgelegt, falls nicht im Operanden C ein anderer Wert spezifiziert wird. Da er in der Regel nicht Null ist, sondern in der Zukunft liegt, wird die Transaktion in die zukünftige Ereigniskette (FEC) eingefügt. Dort sind die Transaktionen nach ihren Erzeugungs- oder Aktionsbeginnzeitpunkten geordnet. Dort wartet nun jede Transaktion darauf, dass die Simulationsuhr diesen Zeitpunkt erreicht. Zu diesem Zeitpunkt wird der GENERATE -Block erneut aktiv und erzeugt seine nächste Transaktion, die ebenso in die FEC eingereiht wird. Dieser Aktionszyklus des GENERATE -Blockes endet, wenn die in seinem Operanden D eventuell angegebene Maximalzahl der zu erzeugenden Transaktionen erreicht ist.
Die Aktivität des GENERATE-Blockes kann dadurch unterbrochen werden, dass die erzeugte Transaktion den auf GENERATE folgenden Block nicht betreten kann.
Ein Beispiel dafür findet man im Abschnitt 5.2.
In der folgenden Tabelle werden die Operanden des GENERATE-Blockes mit A, B, C, . . . bezeichnet. Der erste Operand ist also durch A, der zweite durch B bezeichnet.

OperandDefaultErklärung
A-I- beliebige SNA/SLA außer Transaktion-Attributen
A0 Mittelwert der Zeit zwischen der Erzeugung zweier Transaktionen (Zwischenerzeugungszeit)
B0 Maximale Abweichung von diesem Mittelwert; muß kleineren Wert haben, als der A-Operand, um negative Zeiten zu vermeiden. Wenn A und B angegeben sind, wird die Zwischenerzeugungszeit als eine im Intervall von A-B bis A+B stetig gleichverteilte Zufallszahl bestimmt.
C- Falls angegeben, der Erzeugungszeitpunkt der ersten Transaktion
Dinf. Maximalzahl der zu erzeugenden Transaktionen. Ein GATE-Block nach GENERATE kann benutzt werden, um die Erzeugung von Transaktionen zu unterbrechen oder zu beenden.
E0 Priorität der erzeugten Transaktionen
F-I12PH Anzahl der Vollwort-, Halbwort-, Byte- und Gleitkommaparameter für die zu erzeugenden Transaktionen.
13PH,3PF bedeutet: Jede Transaktion hat 13 Halbwort- und drei Vollwortparameter.
Beispiele

GENERATE 10,3,,5
erzeugt 5 Xacts mit der Zwischenerzeugungszeit 10+-3, einer Gleichverteilung im Intervall von 7 bis 13.

GENERATE RVEXPO(1,3.4)
erzeugt Transaktionen mit exponentiell verteilten Zwischenankunftszeiten mit dem Erwartungswert 3.4.

GENERATE ,,,1,20
erzeugt eine Transaktion mit der Prioritätsstufe 20.

GENERATE 20,,50,,2PF,3PB
erzeugt Xacts genau zu den Ankunftszeitpunkten 50, 70, 90, ... mit zwei Vollwort- und drei Byteparametern.
TERMINATE Top of the Paragraph
ist ein Block, der die ihn betretende Transaktion zerstört oder vernichtet. Der von ihr belegte Speicherplatz wird freigegeben und steht wieder zur Verfügung. Ihre Identifikationsnummer XID1 wird nicht neu vergeben. Sie ist eine laufende Zählnummer für erzeugte Transaktionen.
Der einzige Operand von TERMINATE bestimmt den Wert, um den der Startzähler oder Termination Counter (TG1) verringert wird. Der Startzähler hat einen in der START-Anweisung angegebenen Anfangswert. Er dient der Steuerung der Simulationsdauer: Ein Simulationslauf bricht ab, wenn der Startzählerwert Null oder negativ wird.
Wenn der Operand des TERMINATE -Blockes weggelassen wird, erfolgt keine Verringerung des Startzählerwertes.
ADVANCE Top of the Paragraph
ist ein Block, der die ihn betretende Transaktion eine gewisse Zeit festhält. Diese Zeit ist durch die Operanden A und B des ADVANCE -Blockes bestimmt. Die interne Steuerung von GPSS/H überführt jede Transaktion, die einen ADVANCE -Block betritt, in die zukünftige Ereigniskette (FEC). Dort wird sie entsprechend ihrem neuen, aus den ADVANCE -Operanden abgeleiteten Aktivierungszeitpunkt eingeordnet.
Beispiele

ADVANCE 1.5
Wartezeit genau 1.5 Zeiteinheiten

ADVANCE 40,10
Zufällige, im Intervall (30,50) gleichverteilte Wartezeit

ADVANCE RVEXPO(1,13.2)
Zufällige exponentialverteilte Wartezeit mit Erwartungswert 13.2

KontrollfragenTop of the Paragraph

  1. Nennen Sie Beispiele realer Objekte, die durch Transaktionen abbildbar sind!
  2. Beschreiben Sie die Unterschiede zwischen Transaktionen und allen anderen Klassen von Modellelementen!
  3. Beschreiben Sie das Zusammenwirken von Transaktionen und Blöcken!
  4. Wie steuert man die Dauer eines Simulationslaufes?
  5. Wie organisiert die interne Steuerung von GPSS die Bewegung der Transaktionen?
  6. Welche Blöcke können Transaktionen erzeugen?
  7. Welche Blöcke können die Aufnahme einer Transaktion verweigern1 2 3 4 5?
  8. Welche Blöcke können eine Transaktion vernichten1 2?
  9. Welchen Ketten können Transaktionen angehören?
  10. Welche Transaktionen enthält die Zukünftige Ereigniskette (FEC)?
  11. Welche Transaktionen enthält die Aktuelle Ereigniskette (CEC)?
  12. Welche Blöcke veranlassen die Überführung einer Transaktion in die Zukünftige Ereigniskette 1 2?
  13. Nennen Sie drei Beispiele für Attribute von Transaktionen!
  14. Beschreiben Sie das Zusammenwirken von GENERATE -Block und Zukünftiger Ereigniskette!
  15. Zu welchen Zeitpunkten wird ein GENERATE -Block durch das interne Kontrollsystem aktiviert ?
  16. Welche Spezifikation des Erzeugungsprozesses wird durch GENERATE -Operanden bewirkt?
  17. Geben Sie einen GENERATE -Block an, der genau zu den Zeitpunkten 30, 70, 110, 150,... Xacts erzeugt!
  18. Geben Sie einen GENERATE -Block an, der genau 4 Transaktionen zum selben Zeitpunkt 120 erzeugt, die mit fünf Gleitkommaparametern ausgestattet sind!

4.1.4. EinrichtungenTop Line

Funktion
Blöcke und Einrichtungen
Standardattribute
Kontrollfragen über Einrichtungen
Joe und Jim: Modell mit zwei Einrichtungen

Funktion

Einrichtungen (Facilities) ist der Name einer Klasse passiver, unbeweglicher, permanenter und nur einem speziellen Zweck dienender Objekte oder Modellelemente. Einrichtungen werden benutzt, um einkanalige Bedienungssysteme zu modellieren oder um Transaktionen zu vereinzeln, d.h. einen gewissen zeitlichen Abstand zwischen ihnen herzustellen.
Beispiele für die Anwendung von Einrichtungen sind Arbeitsplätze zur Bearbeitung von Aufträgen, Schalter mit Einzelabfertigung und Fahrspuren an einer Kreuzung, wo Fahrzeuge einen zeitlichen Abstand halten müssen.
Eine Einrichtung kann genau eine Transaktion aufnehmen und ist danach solange belegt (used) oder besetzt (seized, busy), bis diese Transaktion die Einrichtung verläßt. Danach ist sie frei (free) oder unbenutzt (not used), , bis sie von der nächsten Transaktion belegt wird. Die nächste Belegung kann sich unmittelbar an die vorangegangene anschließen.

Eine Transaktion, die sich gerade in einer Einrichtung befindet, kann durch eine andere Transaktion höherer Priorität zeitweilig oder ganz verdrängt werden. Diesen Vorgang bezeichnet man als Unterbrechung, Verdrängung oder vorrangige Belegung (Preempting).

Einrichtungen und Blöcke Top of the Paragraph

SEIZE
beschreibt und veranlaßt den Eintritt einer Transaktion in eine Einrichtung. Er verweigert einer Transaktion den Zutritt, wenn die Einrichtung bereits durch eine andere Transaktion belegt oder vorrangig belegt ist.

OperandInhalt
ANr. oder Name der Einrichtung
RELEASE
beschreibt und veranlaßt die Freigabe einer Einrichtung in dem Moment, wo er von der bisher belegenden Transaktion verlassen wird. Nun können Transaktionen, die auf die Freigabe warten, ihren Eintritt erneut versuchen. Dieser gelingt nur der ersten Transaktion in einer sogenannten Verzögerungskette wartender Transaktionen. Transaktionen dieser Kette sind nach Prioritäten und nach Eintrittszeitpunkten sortiert.
OperandInhalt
ANr. oder Name der Einrichtung
PREEMPT
beschreibt und veranlaßt die Unterbrechung oder Vorrangbelegung einer Einrichtung mit zeitweiliger oder ständiger Verdrängung einer eventuell gerade vorhandenen Transaktion .
RETURN
beschreibt und veranlaßt die Freigabe einer vorrangig belegten Einrichtung. Das kann mit der Rückkehr der verdrängten Transaktion verbunden sein.

Numerische und Logische Standardattribute von EinrichtungenTop of the Paragraph

Standardattribute von Einrichtungen haben Namen, die in der Regel mit F (Facility) beginnen.
Fj Wahr, wenn die Einrichtung j gerade normal oder vorrangig belegt ist
FCj Anzahl der Transaktionen, die im bisherigen Verlauf der Simulation die Einrichtung j belegt oder vorrangig belegt haben (Count)
FIj Wahr, wenn die Einrichtung j gerade unterbrochen, d.h. vorrangig belegt ist (Interrupted)
FNIj Wahr, wenn die Einrichtung j gerade nicht unterbrochen ist
FNUj Wahr, wenn die Einrichtung j gerade nicht belegt ist (Not Used)
FRj Nutzungsgrad der Einrichtung j in Promille
FTj Mittlere Verweilzeit der Transaktionen in der Einrichtung j (Time)
FUj Wahr, wenn die Einrichtung j gerade (normal oder vorrangig) belegt ist (Used)


j bedeutet Nummer oder Name der Einrichtung. Die Nummer kann sowohl als Konstante angegeben werden, als auch ein arithmetischer Ausdruck sein.

KontrollfragenTop of the Paragraph

  1. Vergleichen Sie allgemeine Merkmale der Klasse Einrichtungen mit Merkmalen der Klasse Transaktionen!
  2. Welche realen Objekte modelliert man mit Hilfe von Einrichtungen? Geben Sie auch Beispiele an!
  3. Wie kann man Einrichtungen identifizieren?
  4. Beschreiben Sie das Zusammenwirken von Einrichtungen und Transaktionen!
  5. Welche Blöcke sind mit Einrichtungen verbunden?
  6. Beschreiben Sie die Funktionen der Blöcke SEIZE und RELEASE!
  7. Was versteht man unter Vorrangbelegung einer Einrichtung (Siehe auch 5.4.)?
  8. Geben Sie drei Beispiele für Standardattribute von Einrichtungen an!

Joe und Jim: GPSS/H-ModellTop of the Paragraph

JOE und JIM bedienen verschiedene, getrennte Ströme von Kunden. Die Interne Steuerung von GPSS/H plant diese zeitlich parallel laufenden, konkurrenten Prozesse auf der Grundlage der Zukünftigen und der Aktuellen Ereignislisten.
Es ist empfehlenswert, dieses Beispiel nicht nur auf dem Server zu starten, sondern auch lokal. Hier kann man den Debug-Modus nutzen und den Ablauf der Simulation Schritt für Schritt verfolgen!



Joe&Jim als SLX-Modell

4.1.5. Single-Server-AnimationTop Line

Grundidee und Aufgabenstellung
Layout im Draw-Modus
Layout im Path-Modus
Modell mit Anweisungen zur Erzeugung des Animationstracefiles
Erläuterungen zum Programm
Animationslauf
Schnappschuß zur Animation
Ausschnitt aus dem Animationstracefile
Navigation

Grundidee und AufgabenstellungTop of the Paragraph

Am Beispiel des einfachen oder einkanaligen Bedienungssystems soll nun gezeigt werden, wie man eine Animation zur anschaulichen Darstellung der simulierten Prozesse erzeugen kann.

Das erfolgt nach folgender Grundidee:

Das folgende Bild zeigt das vorbereitete Layoutfile, in dem auch eine Klasse Customer definiert worden ist. Hier wird das Layout im Draw-Modus gezeigt.

Single-Server as Proof-Snapshot
Layout für ein Single-Server-Modell

Wie man sieht, ist im Layout eine Quelle für die beweglichen Animationsobjekte, die Kunden, eingezeichnet.

Von der Quelle, dem Entstehungsort für die Customer-Objekte, führt ein Linienzug zum Symbol der Bedienungseinrichtung. Ein zweiter Linienzug führt von der Bedienungseinrichtung zu dem Ort, an dem die Objektsymbole wieder verschwinden sollen. Diese beiden Linienzüge sind die Träger von Wegen (Paths), die als Bewegungsbahnen für die Objektsymbole benutzt werden sollen.

Die Quelle und die Einrichtung sind übrigens hier keine Animationsobjekte, sondern lediglich Komponenten der Zeichnung, die man oft auch als Bildhintergrund bezeichnet.

Das folgende Bild zeigt Proof Animation im Path-Modus. Man sieht, dass die beiden Wege P1 und P2 eingetragen sind, auf die im Simulationsprogramm Bezug genommen wird.

Neuer Schnappschuß
Single-Server-Layout im Path-Modus

Damit ist das Layout mit allem ausgestattet, worauf im folgenden GPSS/H-Text Bezug genommen wird.

Single-Server-Modell mit Anweisungen zur Erzeugung eines AnimationstracefilesTop of the Paragraph


SLX mit Animations-Statements

Erläuterungen zum ProgrammTop of the Paragraph

Wenn man das Einführungsbeispiel (Joe's Barbershop) mit dem oben angeführten, neuen Programmtext vergleicht, stellt man einige Änderungen fest. Insbesondere ist sichtbar, dass zwei neue Blöcke BPUTPIC hinzugekommen sind.

BPUTPIC
ist eine Blockanweisung, deren Operanden vollständig mit den Operanden der PUTPIC-Steueranweisung übereinstimmen. Auch die Funktionen beider stimmen weitgehend überein: Eine Ausgabe auf den Bildschirm oder in ein beliebiges File wird veranlaßt. Der Unterschied liegt im Charakter der Anweisungen: Während PUTPIC eine Steueranweisung ist, die vor dem Start der Blockbearbeitung ausgeführt wird, ist BPUTPIC ein Block. Er wird immer dann ausgeführt, wenn ihn eine Transaktion betritt.

Zur Erläuterung der animationsbedingten Erweiterungen des Einführungsbeispiels ist folgendes zu erklären:

  1. Nach dem GENERATE-Block zur Erzeugung der Transaktionen des GPSS/Modells muß sich die gleichzeitige Erzeugung von Proof-Animation-Objekten der Klasse Customer anschließen. Das geschieht, indem jede Transaktion sofort nach dem Verlassen des GENERATE-Blockes den BPUTPIC-Block betritt, der eine Ausgabe von ATF-Kommandos in das ATF-File bewirkt. Ausgegeben werden Nun wird die Bewegung der Transaktion fortgesetzt: ADVANCE 2 läßt sie genau so lange warten, wie die Bewegung des Animationsobjektes auf dem Weg P1 dauert. Die Zeitdauer der Bewegung ist gegenüber dem Originalmodell nur deshalb erhöht worden, dass die Bewegung der Objekte visuell besser erfaßbar wird. Nach dem RELEASE-Block, der die Freigabe von JOE bewirkt, muß die nächste Objektbewegung angestoßen werden. Der zweite BPUTPIC-Block schreibt in das ATF
  2. Während das ursprüngliche Simulationsmodell die Transaktionen unmittelbar nach dem Bedienungsende vernichtet, ist für die Animation eine echte Modellerweiterung nötig: Jede Transaktion muß nun zwei Zeiteinheiten länger leben, um das Ende der Bewegung ihres Animationsobjektes abzuwarten und dieses danach zu vernichten, bevor sie sich selbst zerstört. Die Vernichtung des Animationsobjektes wird durch den dritten BPUTPIC-Block vorgenommen. Er schreibt

Damit sind alle animationsbedingten Änderungen oder Erweiterungen des Simulationsmodells ausgeführt. Der Simulationslauf kann gestartet werden. Er erzeugt neben der üblichen Resultatausgabe auch das File SINGLPRF.ATF.

AnimationslaufTop of the Paragraph

Wenn man Proof Animation lokal verfügbar hat, kann man die beiden Files SINGLPRF.LAY und joe.ATF laden und die Animation starten.

Die folgende Momentaufnahme soll einen Eindruck vom Ablauf der Animation vermitteln.

Proof-SnapshotW
Schnappschuß zur Animation des Single-Server

Proof-Layout- und ATF-Files kann man mit Steffen Masiks Proof2SVG in SVG-Files umwandeln und im Web-Browser betrachten

Play SVG

Single-Server-Animation: TracefileausschnittTop of the Paragraph



 Time 15.2435
 Create Customer 1
 Place 1 on P1
 Set 1 Travel 2
 Time 33.2358
 Create Customer 2
 Place 2 on P1
 Set 2 Travel 2
 Time 42.0390
 Place 1 on P2
 Set 1 Travel 2
 Time 44.0390
 Destroy 1
 Time 47.6849
 Create Customer 3
 Place 3 on P1
 Set 3 Travel 2
 Time 54.4523
 Place 2 on P2
 Set 2 Travel 2
 Time 56.4523
 Destroy 2
...............
 Destroy 100
 End

Wie man sieht, ist das Trace-File unkommentiert lesbar. Das Simulationssystem, das mit Hilfe seiner Liste zukünftiger Ereignisse (FEC) und seiner internen Steuerung alle Ereignisse in eine zeitlich aufsteigende Reihenfolge bringt, sichert auch, dass die Time-Kommandos in zeitlich aufsteigender Folge erscheinen, denn sonst würde die Animation wegen Laufzeitfehlern abgebrochen.


SAHome previous next up Englishsmaller fonts Top Line
Last Modified Fri 05-27-11 19:36 GMT Valid CSS!

Comments please to:pelosim@yahoo.com