Einleitung
Diese Tutorial soll, anhand eines Beispielmodells, eine Einführung in die Möglichkeiten bieten, die Resourcen und Listen zusammen mit Process Flow bieten. Es werden Grundkenntnisse über das Arbeiten mit FlexSim, insbesondere in den Bereichen 3D-Objekte, Label und Process Flow vorausgesetzt.
Bei dem Beispielmodell, welches wir in diesem Tutorial bauen werden, handelt es sich um einen simplen Fabrikationsprozess. In einer Source werden Items acht unterschiedlicher Typen erzeugt. Diese müssen auf einer von sechs Maschinen bearbeitet werden. Welche Maschine (Processor) welche Typen bearbeiten kann, wird in einer Tabelle festgelegt. Dabei stehen die Zeilen für die verschiedenen Typen und die Spalten für die Maschinen.
Schritt 1 Aufbauen des 3D-Modells
- Ziehen Sie zunächst eine Source und eine Queue in das Modell und verbinden Sie dieser mit einer A-Verbindung. Erstellen Sie in der Source einen On Creation Trigger.
- Stellen Sie diesen auf Set Label and Color. Erweitern Sie die Bandbreite an möglichen Werten auf 1 bis 8.
- Fügen Sie als nächstes sechs Processors zum Modell hinzu. Ziehen Sie außerdem eine weitere Queue und eine Sink in das Modell. Ziehen Sie Verbindungen von allen Processors zur zweiten Queue und von dieser zur Sink.
- Fügen Sie alle sechs Processors zu einer Gruppe hinzu. (Wir haben diese "Processors" genannt, ein anderer Name ist aber selbstverständlich auch möglich)
- Erstellen Sie als nächstes eine globale Tabelle und benennen Sie sie zu "ValidTypes" um. Diese Tabelle wird festlegen, welcher Processor einen Itemtyp bearbeiten kann. Die Spalten repräsentieren die Processors, die Zeilen die Itemtypen. Jede Zelle gibt an, ob der jeweilige Processer den Typ bearbeiten kann (1) oder nicht (0).
Ihr Modell sollte nun in etwa wie auf dem folgenden Bild aussehen. (Die genauen Positionen der Objekte sind natürlich Ihnen überlassen).
Einführung in Listen und Resourcen
Bevor wir uns mit dem Process Flow beschäftigen, der die Verteilung der Items übernehmen wird, wollen wir zunächst eine kleine Übersicht über Listen und Resources und die Unterschiede zwischen den beiden bieten.
Listen
Eine Liste ist genau das, was ihr Name vermuten lässt: Sie ermöglicht es Reihe von Werten (Objekte, Items, Token, etc.) in einem Listenformat zu speichern. Diese Daten können dann für Entscheidungsprozesse, wie zum Beispiel das Verteilen von Aufgaben im Modell, verwendet bzw. ausgewertet werden.
Eine wichtige Eigenschaft von Listen sind Fields. Jedem Wert auf der List können darüber verschiedene andere Werte zugeordnet werden. Diese können zum Beispiel weitergehende Informationen über den Listenwert enthalten und über SQL-Abfragen zum Filtern und Ordnen der Liste verwendet werden, wenn ein Wert von der Liste gezogen werden soll.
Listen können lokal, also nur in einem limitieren Bereich, wie einem einzelnen Process Flow definiert sein. Oder aber global, sodass von allen Bereichen des Modells aus darauf zugegriffen werden kann.
Sie sind ein mächtiges Werkzeug um Informationen zwischen verschiedenen Teilen des Modells zu übertragen, Aufgaben zu verteilen oder Prozesse zu steuern, an denen mehrere Objekte beteiligt sind.
Resources
Die Process Flow-Aktivität Resource erfüllt eine ähnliche Funktion. In ihrer Standardkonfiguration (Reference -> Numeric) funktioniert sie in etwa wie eine "Liste light". Sie stellt eine limitierte Menge an "Dingen" da, die von einem Token reserviert (acquired) werden können. Jeder Wert der Ressource kann dabei zu jeder Zeit nur von einem Token gleichzeitig genutzt werden.
Dies geschieht mit Hilfe der Acquire Aktivität. Sobald eine Ressource nicht mehr benötigt wird, kann sie über die Release Aktivität wieder freigegeben werden.
Numerische Ressourcen eignen sich daher als schnelle und einfache Möglichkeit einen begrenzten Vorrat an Komponenten für einen Prozess zu implementieren. Ein Beispiel sind zum Beispiel Werkzeuge, die von mehreren Arbeitsplätzen genutzt werden. Man spart sich so die Arbeit, diese Komponenten als tatsächliche Objekte zum Modell hinzufügen zu müssen. Auch eine komplett "virtuelle" Simulation ist so möglich.
Schritt 2 Erstellen des Process Flows
Nun fügen wir den Process Flow hinzu, der Entscheiden wird, auf welchem Processor die Items bearbeitet werden.
Wir bauen die Logik aus Sicher der Items: Jedes Token wird ein einzelnes Item darstellen und versuchen einen, für den Itemtyp passenden, Processor zu reservieren. Diese werden als Teile einer Resource dargestellt..
- Fügen Sie einen neuen General Process Flow zum Modell hinzu.
- Ziehen Sie eine Event-Triggered Source in das Process Flow-Fenster. In ihrem Eigenschaftenfenster, wählen Sie die Pipette neben dem Object Feld aus.
Klicken Sie dann im 3D-Fenster auf die Queue, die mit der Source verbunden ist und wählen Sie OnEntry als Triggerevent aus.
Immer wenn jetzt ein Item in die Queue eintritt wird ein Token erzeugt. Um von diesem aus das Item referenzieren zu können, wollen wir es einem Label auf dem Token zuweisen.
- Fügen Sie den gewünschten Labelnamen neben Entering Item im Label Assignment/Match Value Bereich ein und wählen Sie die Option assign im Feld rechts davon aus. Wir haben den kreativen Namen "item" gewählt.
- Fügen Sie eine Delay-Aktivität direkt hinter der event-triggered Source hinzu und stellen Sie eine Dauer von Null Sekunden ein.
- Ziehen Sie als nächstes eine Resource in das Process Flow-Fenster. Wählen Sie als Reference, die Gruppe aus, zu der Sie die Processors hinzugefügt haben.
- Klicken Sie auf die nun verfügbar gewordene Advanced-Schaltfläche am unteren Rand des Eigenschaftenfensters. Dies öffnet die Listeneigenschaften der Ressource, in denen, unter Anderem, weitere Fields hinzugefügt werden können.
- Erstellen Sie ein neues Expression-Feld für die Liste, indem Sie im entsprechenden Tab auf das grüne Plus-Symbol klicken. Dieser Feldtyp erlaubt es einen Flexscriptbefehl einzutippen, welcher ausgewertet wird, sobald ein Wert auf die Liste gesetzt wird oder versucht wird einen Wert von ihr herunterzunehmen. Der Rückgabewert des Befehls wird dann als eigentlicher Wert des Feldes genutzt.
- Nennen Sie das hinzugefügte Feld Valid. Es wird angeben, ob der jeweilige Processor (das Listenobjekt) das entsprechende Item bearbeiten kann oder nicht. Tippen Sie das Folgende in das Expression-Feld ein und setzen Sie bei der nebenstehenden Option Dynamic ein Häkchen.
- Fügen Sie nun noch ein zweites Expression-Feld namens "Number" zur Liste hinzu. Dieses soll den Rang des Processors angeben; wir verwenden also den gleichen Ausdruck wie zuvor für die Tabellenspalte. Man könnte alternativ auch auf jedem Processor ein Label erstellen, welches die Nummer angibt. Dies könnte dann durch Hinzufügen eines Label-Feldes zur Liste in SQL-Abfragen genutzt werden.
- Fügen Sie als nächstes eine Acquire-Aktivität nach der "Breathe"-Aktivität hinzu. Wählen Sie mithilfe der Pipette die zuvor angelegte Ressource für das Feld Resource Reference aus. Unter Assign To Label können Sie den angeben, wie das Label heißen soll, welches den reservierten Processor referenziert. Wir belassen hier die Standardeinstellung "token.resource".
- Tippen Sie den folgenden Ausdruck in das Query/Object/Array-Feld ein.
- Fügen Sie eine Move Object-Aktivität hinzu und konfigurieren Sie diese so, dass das Item auf den, von der Liste gezogenen, Processor bewegt wird.
- Fügen Sie außerdem eine Wait for Event-Aktivität hinzu. Diese hält das Token so lange fest, bis das zugehörige Item vom Processor vollständig bearbeitet wurde. (Nutzen Sie die Pipette um das OnProcessFinish-Event von einem beliebigen Processor im Modell auszuwählen.)
- Nachdem der Arbeitsschritt abgeschlossen ist, wollen wir den Processor wieder für weitere Items freigeben. Dafür fügen wir eine Release-Aktivität hinzu. Da wir den voreingestellen Labelnamen "resource" in der Acquire-Aktvität nicht geändert haben, sind hier keine Anpassungen nötig.
- Verbinden Sie den Process Flow zum Schluss mit einer Sink-Aktvität, um das Token des fertiggestellten Items zu löschen.
Wenn Sie das Modell nun laufen lassen, wird für jedes Item ein Token, mit einem Verweis auf das Item im entsprechenden Label, erzeugt.
Table("ValidTypes")[puller.item.Type][Group("Processors").indexOf(value)]
Wenn ein Token versucht einen Processor von der Liste zu ziehen, wird das Valid-Feld für jeden Processor auf der Liste ausgewertet. Es gibt dabei den jeweiligen Wert in der "ValidTypes" Tabelle für die jeweilige Kombination von Itemtyp und Processor zurück. Damit dies funktioniert, muss die Dynamic Option aktiviert sein. Andernfalls wird der puller Wert, nicht als Parameter an die Funktion übergeben.
WHERE Valid = 1 ORDER BY Number ASC
Die match-Funktion zu nutzen ist in diesem Fall zwar nicht unbedingt nötig, schadet aber auch nicht. Lieber sollte man sie einmal öfter hinzufügen, als sie womöglich zu vergessen, wenn sie tatsächlich gebraucht wird.
Der fertige Process Flow sollte in etwa wie folgt aussehen.
Fazit
Wenn Sie nun das Modell starten, sehen Sie dass Items nur von dazu passenden Maschinen bearbeitet werden. Sollte kein passender Processor frei sein, warten sie stattdessen in der vorgelagerten Queue.
Experimentieren Sie, wenn Sie möchten, mit den Werten in der "ValidTypes" Tabelle, um die Funktionalität des Modells zu testen.
Jetzt, da Sie die Grundzüge des Umgangs mit Listen, ihren Feldern und den zugehörigen Abfragen gelernt haben, möchten wir Sie dazu ermutigen, sich vielleicht selbst weitere Modelle zu überlegen, um die Nutzung weiter zu üben.
Zum Beispiel könnten Sie den Process Flow in diesem Modell aus Sicht der Maschinen anstelle der Items bauen. Dass also die Maschinen sich passende Teile suchen und nicht umgekehrt.
Statt einer Ressource müssten Sie eine Liste verwenden, die zunächst leer ist und deren Inhalt sich über die Laufzeit des Modells hinweg stets ändert. Die Queue könnte die eintreffenden Items zum Beispiel auf eine globale Liste setzen (entweder in der Send to Port Option oder dem On Entry Trigger). Diese kann dann von Process Flow Liste referenziert werden, von der die Tokens (eines pro Processor) sich mittels einer Pull from List-Aktivität passende Items ziehen.
Falls Sie dabei an einer Stelle nicht weiterkommen, können Sie diesen Fall in dem ebenfalls verfügbaren B-Modell betrachten.
Sollten Sie weitere Fragen haben, können Sie uns gerne unter info@pro-sim.de kontaktieren.
Autor: F. Möhlmann