Ein Tag im Leben eines Restaurantmodells

Dieser Artikel beschreibt die neuen Komponenten des Frameworks für die Simulation, die zuvor im Artikel „Ein einfaches Simulationssystem für unterwegs“ vorgestellt wurden . Mit der Erweiterung des Frameworks wurde es möglich, komplexere Systeme zu modellieren, um beispielsweise die Arbeit eines Restaurants zu simulieren.

Neue Komponenten

Es gibt mehrere neue Komponenten: Bifacility , Split , Aggregate , Count , Assign , Check . Betrachten wir sie genauer.

Bifacility ist im Wesentlichen dasselbe wie Facility , dient jedoch dazu, dass die Transaktion für eine Weile nicht nur eine einzelne Komponente, sondern eine Kette von Komponenten umfasst. Hierzu bildet der Bifacility- Konstruktor zwei Komponenten - IN und OUT. Nachdem eine Transaktion in die IN-Komponente eingegeben wurde , wird Bifacility als ausgelastet betrachtet und eine andere Transaktion kann sie nicht mehr ausführen . Wenn eine Transaktion die OUT-Komponente erreicht, wird Bifacility freigegeben und kann nun von einer anderen Transaktion übernommen werden. Nur die Transaktion, die es belegt hat, kann Bifacility freigeben . Die einfachste Analogie von Bifacility kann als technologische Installation betrachtet werden, die eine Reihe von Operationen an einem Teil ausführt. Bis das Teil die Installation verlässt, ist es unmöglich, ein anderes Teil an das Teil zu senden.

Teilen - eine Komponente, die eine Transaktion in Teile aufteilen soll - andere Transaktionen, die in Zukunft parallel verarbeitet werden. Wenn wir beispielsweise eine Transaktion als Auftrag betrachten, sind ihre Teile Positionen in dem Auftrag. Wenn keine Parameter vorhanden sind, teilt Split die resultierende Transaktion standardmäßig durch einen Betrag, der den nachfolgenden Komponenten entspricht. Es kann angegeben werden, wie viele Teile und mit welchem ​​Modifikator (um einen zufälligen Wert zu generieren) die Partition ausgeführt wird. Da es in der Praxis erforderlich sein kann, dass die Aufteilung in Teile nach einem bestimmten Gesetz erfolgt, ist es bei der Aufteilung möglich, Ihren Handler zum Aufteilen anzuschließen.

Zusammen mit Split ist Aggregate , wie der Name schon sagt, eine Reihe von Transaktionen zu einer zusammengefasst. Die Funktionalität ist recht einfach: Nachdem alle Teile einer zuvor unterbrochenen Transaktion empfangen wurden, wartet sie auf alle anderen Teile und sendet nach Erhalt eine weitere Transaktion.

Count - Komponente zum Zählen. Der Count- Konstruktor bildet zwei Komponenten - INC und DEC. Wenn eine Transaktion INC eingibt, erhöht sich der Zählzähler, wenn sie einen DEC eingibt, verringert er sich. Im Konstruktor von Count werden Werte festgelegt, um die der Zähler beim Eingeben von INC bzw. DEC zunimmt und abnimmt.

Zuweisen - zum Festlegen einiger Transaktionsparameter. Eine Transaktion hat eine Liste von Parametern, jeder Parameter hat einen Namen und einen Wert. Der Wert kann eine Zeichenfolge, eine Zahl oder eine Struktur sein. Wenn einem Parameter Null zugewiesen wird, wird er aus der Liste entfernt.

Prüfen - Eine Komponente, die die Erfüllung einer bestimmten Bedingung überprüft und eine Transaktion nur überspringt, wenn sie ausgeführt wird. Standardmäßig wird die Gleichheit des Transaktionsparameters mit dem angegebenen Wert überprüft. Im Check- Konstruktor können Sie den Block angeben, an den die Transaktion gesendet wird, wenn das Ergebnis der Prüfung falsch ist . Um die Flexibilität zu erhöhen, kann ein eigener Handler angeschlossen werden, um den Zustand des Überspringens von Transaktionen zu überprüfen.

Es ist anzumerken, dass bei der Entwicklung des Frameworks das Ziel nicht darin bestand, GPSS vollständig zu kopieren. Daher kann die Funktionalität bei gleichem Namen der Komponenten variieren.

Restaurant Modell

Die Entscheidung, ein Restaurantmodell zu bauen, kam nicht von Grund auf. Erstens besuchen sie ziemlich viele Leute, zweitens ist dies ein ziemlich kompliziertes Warteschlangensystem, drittens arbeitet meine Frau seit vielen Jahren im Restaurantgeschäft, und ich könnte sie konsultieren.

Also werden wir beginnen, das Modell des Restaurants zu beschreiben. Das Restaurant wird an 24 Tischen stehen. Restaurantbesucher werden "Gäste" genannt, Gäste kommen zufällig, diese werden Transaktionen generiert. Bei der Transaktion handelt es sich jedoch nicht um eine Person, sondern um eine Gruppe von Personen, die nur einen Tisch eingenommen haben. Wenn mehr als 6 Gäste in der Warteschlange stehen (6 Tische werden benötigt), um den Realismus zu erhöhen, warten neue Gäste und warten nicht.

Hostessen treffen Gäste am Eingang, in großen Restaurants gibt es oft zwei oder mehr, im Modell sind es zwei. Falls es freie Tische gibt, führen Hostessen sie zum Tisch, wenn es keine freien Tische gibt, warten die Gäste. In echten Restaurants gibt es eine Reservierung und VIP-Gäste, die der Einfachheit halber nicht im konstruierten Modell sind, aber solche Pläne müssen berücksichtigt werden.
Nachdem die Gäste an einem Tisch Platz genommen haben, werden sie von einem Kellner bedient, normalerweise einem Kellner für mehrere Tische. Im Modell gibt es einen für drei Tische. Wie in einem normalen Restaurant kann der Kellner nicht mehrere Tische gleichzeitig bedienen, sondern nur einen nach dem anderen. Während des Service erhält der Kellner eine Bestellung von den Gästen. Mit Bestellung sind mehrere Gerichte verschiedener Art und Getränke gemeint. Wie viele Gerichte und Getränke bestellt werden, ist nicht im Voraus bekannt, aber wir zählen mindestens eins und nicht mehr als fünf, einschließlich der Bestellung an einer Bar. Der Kellner, der die Bestellung erhalten hat, gibt sie an die Köche und Barkeeper weiter.

Traditionell gibt es unter Köchen Spezialisierungen: Vorspeisen und Salate, Fleisch, Kuchen und Desserts, Sushi. Es wird auch im simulierten Restaurant vier Köche geben, die verschiedene Gerichte zubereiten. Es wird zwei Barkeeper geben.

Es ist üblich, dass nicht alle Gerichte sofort, sondern sofort fertig sind. Dementsprechend essen die Gäste nicht alle auf einmal, sondern nach und nach. Und nur wenn sie alle Gerichte gegessen haben, können Sie die Bestellung bezahlen. Danach kann der Tisch geräumt werden.

Bestimmte Zeitparameter können im Code angezeigt werden .

Modellierung

In Abb. 1 zeigt das Strukturdiagramm des Modells. Bei der Modellierung wird fast der gesamte Satz von Komponenten des Frameworks einbezogen. Um die Anzahl der Gäste in der Warteschlange zu schätzen, wird die Check- Komponente verwendet. Mit einem speziellen Handler überprüft er die Anzahl der Gäste in der Warteschlange und sendet sie an den Ausgang, wenn die angegebene Anzahl überschritten wird. Überprüfen Sie auch , ob freie Tabellen angezeigt wurden.


Abb. 1. Das Strukturdiagramm des Restaurantmodells

Mit Bifacility können Sie den Tisch besetzen und freigeben . Mit Zuweisen gepaart mit Scheck können Sie festlegen, ob der Kellner die Bestellung vom Tisch in die Küche überträgt oder das fertige Geschirr bereits liefert.

Wie aus Abb. 1 Jeder der Köche hat eine Reihe von Bestellungen, in der Realität ist es natürlich möglich, mehrere Gerichte parallel zu kochen, aber im vorgestellten Modell wird dies weggelassen. Für Barkeeper ist die Bestellposition üblich.

Simulationsergebnisse

Die Simulationsergebnisse finden Sie hier . Der Bericht zeigt:

• zwei Tabellen wurden nicht verwendet (23 und 24), und im Allgemeinen wird ein Viertel der Tabellen praktisch nicht verwendet;
• Das Restaurant bediente 29 Besucher und keiner der Besucher verließ das Restaurant, ohne jemals das Restaurant betreten zu haben.
• Besucher mussten nicht in der Schlange stehen;
• Am Ende der Simulation erhielten 12 Besucher einen Teil ihrer Bestellung und erwarteten die restlichen Gerichte.
  
• Koch 1 und 4 haben eine sehr große Last (91,46%, 88,33%);
• Barmann 2 ist nicht mit Arbeit beladen (1,67%);
• Die Hälfte der Kellner ist nicht besonders beschäftigt.
• Hostess 2 ist fast nicht beschäftigt (9,38%).

Unterm Strich ist das Restaurant groß und hat viel zusätzliches Personal. Oder das Restaurant ist an einem Ort mit wenig Verkehr geöffnet (im vorgestellten Modell betreten die Besucher alle 10 ± 5 Minuten). Wenn Sie mit mehr Verkehr testen (5 ± 3), steigt die Anzahl der Mitarbeiter erheblich, aber einige Besucher gehen, ohne auf einen Tisch zu warten.

Fazit

Das vorgestellte Modell ermöglicht es Ihnen trotz einiger Vereinfachungen ziemlich erträglich, die Arbeit des Restaurants zu simulieren, und hat möglicherweise sogar praktischen Wert. Aber sowohl neue als auch alte Komponenten müssen sicherlich weiterentwickelt werden. Nicht alle Ausnahmen werden falsch oder falsch behandelt. Es ist notwendig, den Framework-Code mit Tests und der wichtigsten Dokumentation abzudecken. All dies ist geplant und wird so weit wie möglich realisiert.