Peter Lorenz English smaller fonts Simulation und Animation

5.2. Interne Steuerung von GPSS/H

Bisher ist schon mehrfach die Interne Steuerung von GPSS/H als zentrales Instrument zur Steuerung der Bewegung der Transaktionen und der Festlegung der Reihenfolge der Ausführung von Operationen erwähnt worden. An dieser Stelle erfolgt ihre nochmalige systematische Erklärung.
Erklärt werden auch die von ihr genutzten Datenstrukturen. Das sind neben den Simulationsuhren verschiedene Ketten von Transaktionen, die hier nochmals behandelt werden.
Bekanntlich muß man zwischen den unsichtbaren Modellelementen und den sichtbaren Blöcken und Anweisungen unterscheiden. Intern sind im Operativspeicher des Computers die Modellelemente als Datenstrukturen und die Blöcke als Algorithmen oder Methoden der Modellelementklassen angelegt. Während die permanenten Modellelemente während eines Simulationslaufes ihren festen Platz im Operativspeicher besitzen, sind für temporäre (nur zeitweilig vorhandene) Elemente, die Transaktionen, nur eine bestimmte Anzahl von Plätzen vorgesehen. Sie belegen diese Plätze während ihrer Lebenszeit. Das ist die Zeit, in der sie im Modell vorhanden sind. Nach dem Lebensende einer Transaktion (TERMINATE) wird ihr Platz frei und kann von einer später geborenen (GENERATE) Transaktion eingenommen werden. Die Verwaltung dieser Transaktionen ist eine algorithmisch anspruchsvolle Aufgabe. Sie wird mit Hilfe von Ketten oder Listen gelöst. Jede dieser Ketten hat ein erstes Element, das man oft als Kopfelement bezeichnet. Jedes Element trägt einen Verweis auf die Nummer seines Nachfolgers. Das letzte Element kann man daran erkennen, dass es auf nichts verweist.

TransaktionskettenklassenTop Line

Klasse von Transaktionsketten Anzahl Inhalt
Aktuelle Ereigniskette (AEK) 1 Transaktionen, die auf eine Bedingung warten
Zukünftige Ereigniskette (ZEK) 1 Transktionen, die auf einen bekannten künftigen Zeitpunkt warten
Benutzerkette (UC) 0...n Transaktionen, die auf Befreiung durch eine andere Transaktion warten
Unterbrechungskette (IC) 0...n Transaktionen, die auf das Ende ihrer Unterbrechung warten
Montagekette (MC) 0...n Transaktionen, die auf andere Vertreter ihres Verbandes warten

Tabelle: Fünf Klassen von Transaktionsketten


In GPSS/H werden Ketten von Transaktionen für deren Verwaltung während der Simulation genutzt. Der Inhalt dieser Ketten wechselt während eines Simulationslaufes ständig. Die Änderungen der Kettenzugehörigkeit und der Attribute der Transaktionen in den Ketten spiegeln den Lauf der Transaktionen von Block zu Block wider. Jede Blockoperation hat Einfluß auf den Inhalt wenigstens einer dieser Listen.

In diesem Kapitel werden zunächst die beiden ersten Arten von Transaktionsketten näher betrachtet.

Die Aktuelle und die Zukünftige Ereigniskette werden vom GPSS angelegt und existieren jeweils nur einmal. Die übrigen Ketten entstehen in Abhängigkeit von den Blöcken, die der Benutzer in seinem Programm verwendet. Sie brauchen gar nicht vorhanden zu sein, sie können aber auch mehrfach vorkommen. Eine Übersicht über alle Transaktionsketten erhält der Nutzer im automatisch erzeugten Schlußbericht eines Simulationslaufs dann, wenn er als vierten Operanden seiner START-Anweisung den Wert 1 angibt.
Jede Transaktion gehört zu jedem Zeitpunkt ihrer Existenz genau einer dieser Ketten an. Keine Transaktion kann also gleichzeitig mehr als einer Kette angehören.

Eine derartige Klassifikation, die alle Transaktionen umfaßt und deren Klassendurchschnitte leer sind, nennt man vollständig und disjunkt.

Im folgenden soll beschrieben werden, wie Transaktionen im Laufe ihrer Existenz zwischen CEC und FEC hin- und herwechseln. Auf die anderen Klassen von Transaktionsketten wird später einzugehen sein.

Aktuelle Ereigniskette CECTop Line

Die CEC enthält alle Transaktionen, die zum gegebenen Zeitpunkt aktiv sind und bewegt werden könnten. Allerdings können sie dadurch blockiert sein, dass sie auf eine Bedingung warten.

Beispiele solcher Bedingungen sind

Jedesmal, wenn die Simulationsuhr von einem Ereigniszeitpunkt zum nächsten vorrückt, versucht die interne Steuerung von GPSS/H, alle Transaktionen der CEC zu bewegen. Sie beginnt am Kopf der CEC und bewegt die erste Transaktion solange von Block zu Block, bis die nächste Blockierung auftritt. In der CEC sind Transaktionen nach ihren Prioritäten geordnet. Die Priorität einer Transaktion ist ein ganzzahliger Wert, der bei der Erzeugung einer Transaktion festgelegt und während ihres Lebens verändert werden kann. Transaktionen gleicher Priorität werden nach der FIFO-Regel (First In First Out) in die CEC eingeordnet. Diese Regel heißt auch FCFS (First Come, First Served).
Jede Transaktion ist zu jedem Zeitpunkt sowohl einer Kette als auch einem Block zugeordnet.

Zukünftige Ereigniskette FECTop Line

Die zukünftige Ereigniskette enthält alle Transaktionen, die auf einen zukünftigen Zeitpunkt der Simulationsuhr warten. In die FEC gelangt jede Transaktion bei ihrer Erzeugung durch GENERATE und nach dem Betreten eines ADVANCE-Blockes. Die Transaktionen, die auch durch Xacts abkürzend bezeichnet werden, werden in die FEC nach steigenden Ereigniszeitpunkten (Move-Time) eingeordnet. Xacts mit gleicher Move-Time werden nicht nach Priorität, sondern chronologisch, d.h. in der Reihenfolge ihrer Eintragung, in die FEC aufgenommen.

Transaktion-BewegungTop Line

Hier soll zunächst ein grober Einblick in die interne Steuerung erfolgen. Dieser wird später zu verfeinern sein.

Zwei Phasen der Xact-Bewegung
Bild: Zwei Phasen der Xact-Bewegung

Der Simulationslauf beginnt mit der Abarbeitung einer START -Steueranweisung. Danach werden Der Zyklus Xact-Bewegung besteht aus den beiden Phasen Der Zyklus wird abgebrochen, wenn der Startzähler (Termination Counter ) kleiner oder gleich Null ist. Seine Dekrementierung erfolgt beim Eintritt einer Xact in einen TERMINATE -Block um den Wert seines Operanden A.

GENERATE-InitialisierungTop Line

GENERATE Initializing
Bild: GENERATE-Initialisierung

Vor Beginn eines Simulationslaufes findet die GENERATE-Initialisierung statt. In der Reihenfolge ihrer Anordnung im Modell erzeugt jeder GENERATE-Block eine Xact und veranlaßt den Eintrag in die FEC. Wenn es Xacts gibt, deren Bewegungszeit gleich Null ist, so kommen sie sofort in die CEC.

Stellen der SystemuhrTop Line

Clock Updating
Bild: Stellen der Systemuhr

Stellen der Systemuhr oder Clock-Update-Phase heißt der Abschnitt der internen Steuerung, der die zukünftige Ereigniskette FEC verarbeitet.

Wenn die Clock-Update-Phase die Steuerung übernimmt, wird die Simulationsuhr auf den Wert der Blockabgangszeit der ersten Xact der FEC erhöht. Ein Rückwärtsgang der Simulationsuhr ist ausgeschlossen. Dieser erste Xact wird aus der FEC entfernt und in die CEC überführt. Weitere Xacts mit der gleichen Blockabgangszeit werden ebenfalls in die CEC überführt und dort entsprechend ihrer Priorität eingeordnet. Bei gleicher Priorität wird nach dem FIFO-Prinzip geordnet.

Scan-PhaseTop Line

In der Scan-Phase bewegt die interne Steuerung jede Xact der CEC solange, bis sie aufgehalten oder vernichtet wird. Sie beginnt damit am Kopf der CEC, der Liste der aktuellen Ereignisse oder der bewegbaren Xacts. Wenn trap scan aktiv ist, wird die Steuerung beim Eintritt in die Scan-Phase dem Nutzer übergeben, der jetzt Kommandos eingeben kann. Sonst wird jede der in der CEC enthaltenen Xacts solange bewegt, bis sie
Scan Phase
Bild: Die Scan-Phase im Überblick

GENERATE mit NullintervallTop Line

Nachdem die Arbeit der internen Steuerung erklärt wurde, kann man den Lebenszyklus einer Transaktion im gleichnamigen Bild verfolgen. Die Xacts wechseln nach ihrer Erzeugung zwischen FEC und CEC, bis sie schließlich vernichtet werden.

Xact Lifecycle
Bild: Transaktion-Lebenszyklus

Am Bild erkennt man die Sonderstellung von Xacts, die mit der Pausenzeit oder Zwischenerzeugungszeit Null entstehen. Dieser Sonderfall ist für viele Modellierungsaufgaben von Interesse, so dass er hier genauer betrachtet werden soll. Dazu wird die folgende Fallunterscheidung eingeführt:

Im Fall A1 erzeugt der GENERATE-Block in einer einzigen Scan-Phase solange Xacts, bis deren Maximalzahl überschritten wird.


Das ist ein elementares Beispiel dieser Situation. Als Modell eines Realprozesses, in dem solange Forderungen auftreten, bis totale Überfüllung auftritt, besitzt es keine praktische Bedeutung. Denn man weiß auch ohne Modellierung, was passieren wird. Als Demonstrationsbeispiel für den TEST-Mode von GPSS bietet es Einblick in die Verwaltung der zukünftigen Ereigniskette (FEC).

Im Fall A2 stellt der GENERATE-Block in der ersten Scan-Phase die durch den Operanden D definierte Anzahl von Xacts bereit.


Dieser Fall ist von praktischem Interesse bei der Modellierung von Systemen, in denen von Beginn an eine bestimmte Anzahl von aktiven Objekten, z. B. Werker, Gabelstapler oder Straßenverkehrsampeln verfügbar sind. Obiges Beispiel weist darauf hin, dass keine Veranlassung besteht, die Vernichtung dieser Objekte vorzusehen. Auch für dieses Beispiel ist es lehrreich, im Test-Mode die Entwicklung von FEC und CEC schrittweise zu verfolgen.

Im Fall B1 ist der GENERATE -Block darauf eingestellt, eine unbegrenzte Anzahl von Xacts zu erzeugen.

Zum Zeitpunkt 0 erzeugt er die Xact mit der Nummer 1, die sofort in die CEC überführt wird und SEIZE betritt. GENERATE wird durch den Abgang von Xact1 aktiviert, die nächste Xact zu erzeugen. Aber sie muß in der CEC und im GENERATE -Block warten, bis die Einrichtung PLATZ1 frei wird. Erst dann verläßt sie GENERATE und regt die Erzeugung der nächsten Xact an. So regulieren SEIZE und die Einrichtung PLATZ1 die Aktivität des GENERATE -Blockes.


Dieser Fall ist von praktischem Interesse bei der Modellierung von Systemen, in denen Objekte (z.B. Bearbeitungsaufträge, Kunden, Fahrzeuge, Liftkabinen) ständig warten, um hereingelassen zu werden.

Der Fall B2, wo nur eine beschränkte Anzahl von Objekten von Beginn an auf Einlaß wartet, bringt keine wesentlich neue Situation und soll hier nicht weiter verfolgt werden.

Nachdem nun die Grundprinzipien der internen Steuerung in GPSS-Systemen und die Verwaltung der beiden immer benutzten Ereignisketten FEC und CEC behandelt wurden, sind die Grundlagen für die in den folgenden Abschnitten zu behandelnden speziellen Mechanismen zur Koordinierung parallel laufender Prozesse gelegt.

KontrollfragenTop Line

  1. Welche Transaktionsketten gibt es im GPSS/H?
  2. Wann geraten Transaktionen in die Zukünftige Ereigniskette (FEC)?
  3. Wann werden Transaktionen aus der FEC in die CEC bewegt?
  4. Wann erhalten die Simulationsuhren einen neuen Wert?
  5. Kann eine Transaktion gleichzeitig der CEC und einer Nutzerkette angehören?
  6. Welche Transaktionsketten gibt es nur einmal und welche können in beliebiger Anzahl auftreten?
  7. Nennen Sie drei Bedingungen, die zur Blockierung einer Transaktion in der CEC führen können!
  8. Wie sind die Transaktionen in der CEC geordnet?
  9. Nennen Sie zwei Phasen, die bei der Steuerung der Xact-Bewegung zyklisch durchlaufen werden!
  10. Wann findet die GENERATE -Initialisierung statt und worin besteht sie?
  11. Wie werden Xacts mit der Zwischenerzeugungszeit Null behandelt?
SAHome previous next up Englishsmaller fonts Top Line
Last Modified Thu 07-05-12 10:02 GMT Valid CSS!

Comments please to:pelosim@yahoo.com