Simulation diskreter Systeme

Beispiel einer Lieferkette:

vereinfachte Version des Argesim-Benchmarks C14 [9]
drei Firmen stellen je drei von vier verschiedenen Produkten her
Distributoren beziehen Produkte von je zwei Fabriken
Großhändler bestellen Produkte bei den Distributoren
Fragestellung z. B.
- Nach welcher Strategie soll ein Distributor Produkte nachbestellen?
- Wie groß sollten die Lager der Fabriken bzw. Zwischenhändler sein?
- Wie lange dauert der Vorgang von der Bestellung eines Großhändlers bis zur Auslieferung des Produkts?
Überblick über veröffentlichte Lösungen des Benchmarks

Modellierung der Großhändler:

Bestellungen erfolgen nach einer Startzeit von tW Stunden
Zeit zwischen Bestellungen gleichverteilt im Intervall [tMin, tMax] Sekunden, ganzzahlig
Produkttyp gleichverteilt 1 .. nProd
Distributor gleichverteilt 1 .. nDist
Versionen für nDist = 3 bzw nDist = 4
Eingang der Produkte wird nicht weiter modelliert

Implementierung des Großhändler-Modells:

Komponente Wholesaler mit 3 Ausgängen zu den Distributoren
Parameter
- Initial waitting time [h]: tW
- Minimum interarrival time [s]: tMin
- Maximum interarrival time [s]: tMax
- Number of product types: nProd
Entität Order
- Attribute Product, Distributor
- Attribute NItems, Factory, Port für spätere Erweiterungen

Intergeneration time action

coder.extrinsic('randi');
persistent init;
if isempty(init)
  init = true;
end

% time between orders in hours
res = 1.0;     % define type
if init
  dt = tW;
  init = false;
else
  res = randi(tMax - tMin + 1);
  dt = (res + tMin - 1)/3600;
end

Generate action

coder.extrinsic('randi');
entity.Product = randi(nProd);
entity.Distributor = randi(3);

Ergebnis von testWholesalers

Modellierung einer Fabrik:

Fabrik produziert rund um die Uhr
- jeweils nur einige Produkte gemäß Vektor-Parameter prodTypes (z.B. [1,2,4])
- Produktionszeit exponentiell mit tMean
Fabrik beliefert jeweils zwei Distributoren
am Eingang kommen Bestellungen mit Produkt-Typ, Distributor und Anzahl
- genügend Produkte vorhanden → Artikel an Distributor liefern
- sonst 24 h später erneut probieren

Entwicklung einer Grundversion:

Beschränkungen
- drei feste Produkttypen 1/2/3
- zwei feste Distributoren 1/2
- Anzahl = 1 fest
- keine Prüfung auf Bestand
Implementierung
Produktion
- jeweils ein Produkt in exponentiell verteilten Zeitabständen
- Produkt-Typ 1/2/3 gleichverteilt
Produkte, nach Typ sortiert, in Speicherbausteinen (Entity Store) gesammelt
- Queue statt Store wäre hier genauso gut
Bestellungen werden einmal kopiert
Bestellung eines Typs wird in anonyme Entität (Message) verwandelt
- dazu Entity Generator mit Generation method = Event-based
- Message schaltet Release Gate frei
- Release Gate lässt genau eine Entität (Produkt) durch
aus Kopie der Bestellung wird Distributor abgelesen (in Server)
- als Message an Output Switch geschickt
- steuert Ausgangs-Port der Factory
Vorsicht Nullserver (Server mit tS = 0)
- werden eingesetzt wegen Entry/Exit Action
- können problematisch sein (vgl. [10])
- speichern bei blockiertem Ausgang eine (ggf. mehrere) Entities
- unkritisch, wenn Ausgang nie blockiert ist

Test der Grundversion:

Modell testFactory1
Trick
- Server mit kurzer Verzögerung zwischen zwei Displays
- → verschiedene Attribute der Entities nebeneinander angezeigt
Ergebnis bei tMean = 2000
- ok: Lagereingang führt zur Vergrößerung des Bestands
- ok: Bestelleingang führt zur Bestandsverringerung und Auslieferung
- Bestand reicht hier immer!
Ergebnis bei tMean = 4000
- mehrere Bestellungen ohne Bestand
- bei t = 6.2 Bestellung von Produkt-Typ 1
- Release Gate bleibt offen
- bei t = 6.7 passender Wareneingang → wird sofort ausgeliefert

1. Erweiterung:

vor Auslieferung Prüfung auf Bestand
- ggf. tD Stunden später wieder versuchen
Simulink-Funktion checkStock(prodId)
- prüft, ob stock(prodId) < 1
- schickt entsprechende Message zum Kontrolleingang des Output Switches
Implementierung
- Bestand reicht nicht → Bestellung kommt in Warteschleife
Hinweis
- Bestandsausgänge mit Multiplexer zusammenfassen → Modell deutlich übersichtlicher
- aber: geht nicht, Fehlermeldung in SimEvents

Test der Erweiterung:

Bestellungen zeitlich begrenzt
Wartezeit tD = 12
Ergebnis
- Bestellung bei t = 1.4 wird ausgeführt um t = 13.4
- Bestellung bei t = 12.3 wird ausgeführt um t = 24.3

2. Erweiterung:

beliebige Produkttypen und Distributoren als Parameter, z. B.
- prodTypes = [1,2,4]
- dists = [3,2]
zunächst aufräumen durch Subsysteme
Trick: intern immer Produkt-Typen 1/2/3
Produkt-Typ der Bestellung sofort auf 1/2/3 umsetzen
- dazu Entry action in Nullserver ChangeIds
- ```
idx = find(prodTypes == entity.Product);
entity.Product = idx(1);  % idx could be a vector
```
Lagerhaltung bleibt i. W. unverändert
- Produkt-Typ I bei Erzeugung 1/2/3 (zur einfachen Speicher-Zuordnung)
- bei Eintritt in Speicher auf prodTypes(I) umgesetzt
Wahl des Ausgangs zum Distributor in Nullserver chooseOutput
- wie bei Produkt-Typ durch Umkehrung von dists
Ergebnis ok

Endversion Factory:

Bestellungen haben Anzahl eines Produkts als Attribut NItems
Order Generator
- würfelt Werte für NItems von 1 bis maxItems (Masken-Parameter)
Eingangsprüfung
- keine Teillieferungen!
- prüfeBestand ruft checkStock(entity.Product, entity.NItems) auf
- Simulink-Funktion vergleicht stock und entity.NItems
Kopierer schickt NItems Kopien zur Lagerhaltung
Anzeige der wiederholten Produkte mit DisplayIdM
- hat am Eingang Queue/Server mit kleiner Verzögerung
zusätzlicher Ausgang nWaiting für Statistik-Zwecke
Ergebnis ok

Modell eines Distributors:

Grundfunktion
- bekommt Bestellungen von den Großhändlern
- liefert ggf. Produkte an die Großhändler
- bestellt Produkte bei jeweils 2 Firmen
- eigene Lagerhaltung für alle insgesamt 4 Produkte
Anschlüsse
- Eingang für Bestellung von Großhändlern
- Ausgang für Produkte zu den Großhändlern
- 2 Eingänge für Produkte von Fabriken
- 2 Ausgänge für Bestellungen an die Fabriken
- Ausgang des Lagerbestands
Parameter
- Distributor-Id: distId
- Liste, welche Produkte bei welcher Fabrik bestellt werden: factory (z. B. [1,2,1,2])
- Parameter tI, nInit, nDaily für die Strategie (s.u.)
Strategie für Fabrikbestellungen je nach Lagerstand und Auftragslage
einfache Strategie (DistributorA)
- Lagerfüllphase: nach Startzeit tI je nInit Produkte jeder Sorte bestellen
- alle 24 h später je nDaily Stücke von jedem Produkt bestellen
- Bestellung eines Großhändlers konnte nicht ausgeführt werden
- ⇒ wird bei nächster Fabrikbestellung hinzugefügt

Implementierung DistributorA:

Grundstruktur
Eingangsprüfung
- wie bei Factory, aber ohne Warteschleife
- stornierte Bestellung wird zu Fabrikbestellung
Lagerhaltung
- wie bei Factory, aber alle 4 Produkte, keine Index-Spielereien
Bestellungen
Initial Order
- erzeugt zur Zeit tI Bestellungen für je nInit Produkte jeden Typs
- setzt Attribut Factory gemäß Parameter factory(entity.Product)
- ruft createMessage(port) auf → Weiterleitung zur richtigen Fabrik
Daily Order analog, aber täglich ab tI + 24
Additional Orders
- warten bis Mitternacht
- dt = 24 - rem(getTime(), 24);
- Entry action setzt Factory
- Exit action wählt Ausgang über createMessage(port)

Test der Verteilung von Bestellungen zur Fabrik:

testDistributor1A
Erwartung (bei factory = [1,2,1,2])
- oben nur Fabrik 1 und Produkte 1/3
- unten nur Fabrik 2 und Produkte 2/4
Ergebnis fehlerhaft
Vermutung
- Problem in Bestellungen
- Timing der createMessage-Aufrufe von zwei Blöcken aus durcheinander
Sequence Viewer in Bestellungen zum Debuggen
- zeigt Nachrichten zwischen Blöcken
- Anklicken einer Event-Linie zeigt Entity und ihre Attribute
Analyse
- zwei einlaufende Additional Orders (t = 7, t = 14)
- 1. Initial Order mit createMessage(1) und auslaufender Entity
- 2. Initial Order startet mit createMessage(2)
- Additional Orders drängelt sich dazwischen, am Ende createMessage(1)
- Entity der 2. Initial Order kommt endlich, jetzt auf falschem Ausgang (1)
Auflösen von Gleichzeitigkeit über mehrere Blöcke in TBM generell ein Problem

Lösung durch anderes Routing-Schema:

Idee: verwende Attribut statt Control-Port zum Routing
- Entity Order hat weiteres Attribut Port
- wird von Entry action des Servers gesetzt
- Auswahl des Ports im Switch über Port-Attribut statt über Simulink-Funktion
Ergebnis: klappt!
zusätzlicher Ausgang nCancelled für Statistik-Zwecke
- Zahl der stornierten Bestellungen
- soll direkt bei Eingang (und Abweisung) steigen
- Problem: Server zeigt nur Gesamtzahl der ausgehenden Entities, nicht der eingehenden
- Trick: Nullserver davor

Verifikation von DistributorA:

Überprüfung des Gesamtverhaltens mit testDistributor2
Ergebnis

manuell Entitäten-Tabelle erstellen

dazu zunächst Inputs (PIn, OIn) aus Osci-Daten ablesen
dann zeitlich vorgegebene OOuts eintragen
danach alle weiteren Größen per Hand ermitteln
Lagerwerte immer nach dem Input/Output

 t PIn OIn   Lager    POut  OOut(P)  OOut(F) Bemerkung
----------------------------------------------------------------
 7      2   0/0/0/0                          delayed bis 24, E1
10  2       0/1/0/0
12  4       0/1/0/1
14      3   0/1/0/1                          delayed bis 24, E2
20  1       1/1/0/1
21      1   0/1/0/1    1
24  3       0/1/1/1
                           1/2/3/4  1/2/1/2
                             2/3      2/1        E1/E2
28      4   0/1/1/0    4
30  2       0/2/1/0
35      3   0/2/0/0    3
36  3       0/2/1/0
40  2       0/3/1/0
42      4   0/3/1/0                          delayed bis 48, E3
48  3       0/3/2/0
                           1/2/3/4  1/2/1/2
                             4        2         E3
49      1   0/3/2/0                          delayed bis 72, E4
50  1       1/3/2/0
56      2   1/2/2/0    2
60  4       1/2/2/1
    1       2/2/2/1
63      2   2/1/2/1    2
70  2       2/2/2/1
        1   1/2/2/1    1
72  3       1/2/3/1
                           1/2/3/4  1/2/1/2
                              1        1         E4

Vergleich mit Osci → ok

Gesamtmodell supplychain1:

Aufbau gemäß obigem Plan
- zusätzlich Lieferzeiten Fabrik → Distributor berücksichtigen
Parameter nach [9]
- Fabrikproduktion reduziert von tMean = 600 s auf tMean = 1500 s
- Originalwert viel zu hoch
- SimEvents stoppt sonst wegen zu vieler gleichzeitiger Events pro Block!
Ergebnisse
Analyse
- Fabriken haben Überproduktion
- Distributoren bestellen zu wenig nach
- viele stornierte Bestellungen

Verbesserungen der Parameter:

Abschätzung der Nachfrage
- mittlere Zeit zwischen Bestellungen: 2100 s = 7/12 h
- bei gleichmäßiger Verteilung auf Fabriken: tMean = 7/4 h = 6300 s
- bei 4 Produkten und 3 Distributoren: alle 7 h ein Produkt bei einem Distributor
- bei täglicher Nachbestellung: nDaily = 24/7 = 3 oder 4?
- zum Testen: setze nDaily = 2/3/4 für D1/D2/D3
Ergebnisse
- Produktion von Produkten 4/3 in Fabriken F2/F3 nicht ausreichend
- → Distributoren bekommen nicht genug geliefert
- → Zahl der stornierten Bestellungen hoch

Erweiterungsideen:

andere Distributorstrategien
- jeweils soviel, wie von den Großhändlern in den letzten 24 h bestellt wurde
- Auswahl einer Fabrik nach bisherigen Verfügbarkeiten/Lieferzeiten
viele Produkt-Typen, gemeinsamer Speicher für alle Typen
Berechnung von Kosten für Lagerhaltung und Transport
Großhändler-Modell verfeinern
Teillieferungen ermöglichen

Aufgaben:

Logistische Versorgungsketten