Was ist eine Breathe-Aktivität?
Der Name Breathe wird von den FlexSim-Entwicklern genutzt um eine Delay-Aktivität mit einer eingestellten Verzögerungszeit von Null Sekunden zu beschreiben.
Wofür wird sie genutzt?
Sie wird genutzt um die Reihenfolge von Ereignissen zu beeinflussen, die zum selben Zeitpunkt in der Simulation eintreten bzw. ausgewertet werden.
Wenn ein Token ein solches Nullzeit-Delay erreicht, werden zunächst alle anderen ausstehenden Ereignisse ausgewertet, bevor das Token zur nächsten Aktvität weiter gelassen wird.
Wann ist dies wichtig?
Es ist empfehlenswert nach Aktivitäten, die auf andere Teile des Modells reagieren ein Breathe einzusetzen. Dies sind vor allem Event-Triggered Sources, Wait for Event- und Pull from List-Aktivitäten. In jedem dieser Fälle könnte das Ereignis, welches das Token erzeugt oder im Process Flow weiter schickt, noch andere Ereignisse/Aktivitäten im Modell auslösen. Wenn weitere Aktivitäten im Process Flow davon abhängen, dass diese Ereignisse komplett durchgeführt wurden (z.B. Zuweisung von Labels in Triggern), so sollte auf jeden Fall ein Breathe genutzt werden, um ein verfrühtes Ausführen der weiteren Aktivitäten zu verhindern.
Ähnliches gilt, wenn zwei oder mehr Process Flow-Aktivitäten durch das gleiche Ereignis ausgelöst werden. Breathes können verwendet werden, um die Reihenfolge, in der die nachfolgenden Blöcke ausgeführt werden, zu steuern. (Ansonsten wäre dies vom Rang der entsprechenden Nodes im Tree abhängig.)
Beispiele
Auf Trigger reagieren - Labelwerte aktualisieren
Eine Source erzeugt Items und sendet diese zu einer Queue. Im On Entry-Trigger wird eine globale Variable namens Count um den Wert Eins erhöht. Außerdem wird eine Nachricht an ein verbundenes Objekt gesendet. Dieses reagiert wiederum in einem Trigger auf diese Nachricht und erhöht ein Label, das ebenfalls Count heißt, um Eins.
Wenn wir jetzt eine Event-Triggered Source nutzen, um beim Eintreffen eines Items in der Queue ein Token zu erzeugen und die beiden Werte in Labels des Tokens schreiben, sehen wir folgendes:
Der Wert der globalen Variable ist 1, wohingegen der Labelwert auf dem verbundenen Objekt noch bei 0 steht. Die Assign Labels-Aktivität wurde vor dem Message-Trigger auf dem BasicFR-Objekt ausgeführt.
Platzieren wir ein Breathe vor der Assign Labels-Aktivität, wurden bereits beiden Werte erhöht, wenn sie auf das Token kopiert werden.
Auf Trigger reagieren - Objekte löschen
Objekte oder Items zu löschen während noch Ereignisse ausstehen, die mit ihnen zu tun haben, führt meist zu Fehlermeldungen. Daher besitzt die Destroy Object-Aktivität eine integrierte Breathe Funktion, in der Form der Asynchronous Option.
In diesem Beispiel reagiert eine Event Triggered Source auf das On Process Finish-Event eines Processors. Sie ist mit einer Destroy Object-Aktivität verbunden, die das gerade fertig bearbeitete Item löschen soll. Wenn wir die Asynchronous Pption deaktivieren und das Modell laufen lassen, gibt FlexSim einen Fehler aus, sobald ein Item den Processor durchlaufen hat.
Die interne Logik des Processors, die an Ende des Prozesses ausgeführt wird, greift ebenfalls auf das Item zu. Wird es zu früh gelöscht ist die Referenz auf das Item im internen Trigger ungültig, was in der Fehlermeldung resultiert.
Neben der Möglichkeit die Asnychronous Option wieder zu aktivieren, kann auch ein Breathe vor der Destroy Object-Aktivität platziert werden, um dies zu umgehen.
Gleichzeitiges Hinzufügen und Entfernen eines Listenwertes
Das dritte Beispiel behandelt die folgende Situation: Tokens warten in einer Wait for Event-Aktivität vor einer Pull from List-Aktivität, bis die Anzahl an Einträgen auf der Liste eine bestimmte Anzahl überschreitet. (zum Beispiel als eine Art Überlaufschutz).
Wenn dieser Wert erreicht wird, ziehen sich die Tokens sofort Werte von der Liste. Wenn einer dieser Werte derjenige ist, der gerade erst auf die Liste geschrieben wurde (und so zum "Überlauf" geführt hat), so wird er zwar von der Liste entfernt. Das Token, welches ihn in einer Push to List-Aktivität zur Liste hinzugefügt hat, bleibt jedoch dort stecken.
Die interne Logik der Push to List-Aktivität war (anscheinend) noch nicht fertig ausgeführt und das Token hat noch nicht darauf gewartet, dass der entsprechende Wert wieder von der Liste genommen wird, um dann zur nächsten Aktivität zu wandern.
Lassen wir das Modell über einen längeren Zeitraum laufen, so sammeln sich immer mehr Tokens in der Aktivität, obwohl die Liste eigentlich leer ist.
AGV Process Flow
Für weitere Beispiele können Sie auch einen Blick auf die AGV Process Flows in FlexSim werfen. Diese nutzen Breathe-Aktivitäten recht oft. Zumeist nach Travel- oder Unload-Aktivitäten, um sicherzustellen, dass die alle Logiken im 3D-Modell oder On Arrival-Events der Kontrollpunkte durchlaufen können, bevor weitere Prozess ausgelöst werden.
Fazit
Obwohl Fälle, in denen ein Breathe unabdinglich ist, nur relativ selten vorkommen, sind sie doch manchmal die Lösung für zunächst obskur anmutende Probleme in einem Modell.
Eine Fehlersuche kann dabei oft lange dauern, insbesondere wenn es sich um ein großes, komplexes Modell handelt. Es ist daher empfehlenswert von vornherein Breathe-Aktvitäten zu platzieren, um etwaigen Problemen vorzubeugen.
Das komplette Modell steht unter folgendem Link zum Download zur Verfügung. Breathe_Example.fsm
Sollten Sie weitere Fragen haben, können Sie uns gerne unter info@pro-sim.de kontaktieren.
Autor: F. Möhlmann