Eigene Simulation von Produktionsprozessen

In Unternehmen schlummern schon heute unzählige Daten, unabhängig davon, ob eine Big-Data Strategie vorliegt. In nahezu jedem Produktionsunternehmen werden über ERP-Systeme Daten zu Artikeln, Arbeitsplätzen und Arbeitsplänen verwaltet, um die Produktion zu steuern.

Oft werden diese Daten nur genau für diesen Zweck genutzt. Das ist schade. Gerade für eine heute notwendige, stetige Optimierung von Prozessen bieten diese Informationen den idealen Ausgangszustand.

Um Ideen für Optimierungen zu erhalten, sind verschiedenen Wege möglich. Ein Weg ist ein Spezialisten-Workshop mit Personen aus unterschiedlichen Abteilungen durchzuführen. Das ist zur Ideenentwicklung eine gute Maßnahme. Kommt durch den Workshop eine Reihe von Ideen zusammen, entsteht ein Dilemma. Welche Idee verspricht die höchste Zielerreichung?

Eine Nutzwertanalyse bringt nicht viel, wenn die Idee selbst nicht auf Ihre Erfolgswahrscheinlichkeit untersucht wird. Eine Verifizierung erfolgt aber meist überhaupt nicht oder direkt im Live-Betrieb in der Produktion. Das ist aufwändig, teuer und stört den aktiven Produktionsfluss.

Heute gibt es viele Möglichkeiten, Produktionsflüsse virtuell umzugestalten und neue Ideen und Abläufe zu überprüfen.

Trotzdem gibt es Simulationssysteme meist nur in größeren Unternehmen und im Automotivbereich. Das liegt nicht nur an den Kosten eines Simulationssystem. Die Kosten für kommerzielle Produkte liegen über 10.000 EUR. Auch das notwendige Expertenwissen ist ein Hemmnis, um zu investieren. Nutzt man das Wissen nicht regelmäßig, geht es schnell verloren.

Gibt es eine Simulation ohne Expertenwissen?

Viele der grundsätzlichen Fragen von Optimierungen in der Produktion sind ähnlich. Wie verändert die Produktionsreihenfolge die Durchlaufzeit der Produkte? Welches ist die richtige Losgröße eines Produktionsauftrags? Wo und zu welchem Zeitpunkt entstehen Engpass-Arbeitsplätze? Wie groß muss der Pufferplatz bei einer Push-Fertigung vor dem Arbeitsplatz sein? Welche Auswirkung hat der Wechsel auf eine Pull-Strategie?

Wie können solche Fragestellungen faktenbasiert für verschiedene Produktionssituationen beantwortet werden? Und zwar ohne, dass man ein Simulationsexperte für eine spezielle Software ist. Oder man in eine teure Software investiert, die nur selten genutzt wird.

Ist es möglich, ein einfaches Simulationssystem selber zu programmieren, um Antworten auf genau diese Fragestellungen zu liefern? Dieser Frage gehe ich in diesem Blogartikel und dem daraus entwickelten Projekt Simple Production Simulation nach.

Konzeption eines eigenen (einfachen) Simulationssystems

Eine Simulation startet immer mit einer konkreten Fragestellung, also bei einem realen Problem! Deswegen ist das auch eine der Todsünden der Simulation (nach Liebl). Eine Simulation wird nie direkt eine Lösung für das Problem ausgeben. Aber sie kann und sollte mögliche faktenbasierende Optimierungsansätze aufzeigen, die dann wieder simuliert werden können.

Deswegen steht am Beginn die Konzeptionsphase für die Auslegung des Simulationssystems.

Anders als bei einem professionellen System, das höchst flexibel auf viele verschiedene Simulationsumgebungen angewendet werden kann, ist das zugleich die wichtigste Frage bei einem selbst-programmierten System. Denn der grundsätzliche Ablauf ist nicht flexibel, sondern „hardcoded“.

Grundsätzlicher Aufbau des Simulationssystems mit Quelle, Puffer, Prozess und Senke

Mein System bildet eine spezifische Produktionsumgebung ab, in der Produkte hergestellt werden. Material fließt von einer Quelle über Puffer in Prozesse zu einer Senke.

Diskret oder kontinuierlich

Die meisten Simulationen basieren auf diskreten, ereignisgesteuerten Simulationsumgebungen. Die Simulationssoftware berechnet dabei nur die Zeitpunkte, bei denen wirklich etwas passiert. Die anderen Phasen überspringt die Software in der Zeitlinie einfach und spart dadurch Simulationszeit ein.

Das ist programmiertechnisch über eine zeitliche Ereigniskette realisierbar, aber gleichzeitig eine komplizierte Variante. Deswegen basiert meine einfache Simulation auf einer kontinuierlichen Simulation – in der Simulation gibt es keine Zeitsprünge. Die kleinste Einheit ist eine Sekunde und jede Sekunde wird in der Simulation durchlaufen.

Elemente der Simulation

In professionellen Systemen werden die einzelnen Elemente, wie Quelle, Puffer, Arbeitsplätze und Senke modelliert und entsprechend der Produktionsflüsse miteinander verbunden.

Der Startpunkt der Simulation ist eine Quelle. Sie ist in meinem Fall das Produktionsprogramm und definiert Produktionsreihenfolge und Mengen der zu produzierenden Artikel.

Die Herstellung der zu produzierenden Artikel erfolgt über einzelne Prozesse. Prozesse werden in einem Arbeitsplatz ausgeführt. Jeder Arbeitsplatz hat einen Eingangs- und Ausgangspuffer, der Produktionsaufträge in einer Warteschlange lagern kann.

In professionellen Simulationsumgebungen werden diese Materialflüsse über Verbindungen manuell durch den Planer modelliert. In meiner Simulation sind die Verbindungen durch die Produktionsaufträge bereits bekannt und Arbeitsplätze werden automatisch miteinander verbunden.

Am Ende der Simulation befindet sich eine Senke, welche die produzierten Artikel aufnimmt und Auswertungen ermöglicht.

Im Inneren des Prozesses

Die Schritte innerhalb eines Produktionsauftrags, die Arbeitsfolgen, werden über Arbeitspläne definiert.

Anmerkung: In einem ERP System ist meist nicht ein Arbeitsplan verknüpft, sondern eher eine Kopie davon als Produktionsplan. Zur einfacheren Begrifflichkeit verwende ich hier aber den Begriff Arbeitsplan.

Produktionsumgebung mit Verbindung zwischen Produktionsauftrag, Artikel, Arbeitsplatz, Arbeitsplan und Arbeitsfolgen

Der Arbeitsplan steuert, in welcher Reihenfolge die Arbeitsplätze durchlaufen werden müssen, um ein Produkt herzustellen. In ihm werden Zeiten für das Rüsten des Arbeitsplatzes für den jeweiligen Produktionsauftrag und die Bearbeitungsdauern definiert.

Beispiel für einen Arbeitsplan mit Arbeitsfolgen

Mit der Simulation soll das Verhalten dieses System „berechnet“ werden. Die Darstellung dieser Aufgabenstellung erfolgt über ein mathematisches Modell. In diesem Fall ist das mathematische Modell die berechenbare Auftragszeit. Sie besteht aus der Rüstzeit und der Einsatzzeit multipliziert mit der Auftragsmenge.

Aufbau der gesamten Auftragszeit mit Wartezeit, Rüstzeit und Einsatzzeit

Die Wartezeit bis zur und nach der Bearbeitung kann nicht direkt ermittelt werden. Sie entsteht durch die Länge der Warteschlange vor und nach dem Arbeitsplatz. Sie wird während der Simulation für alle Elemente berechnet und kann am Ende der Simulation ausgewertet werden.

Was die Simulation nicht kann

Im Rahmen der Simulation versucht man u.a., Ausschnitte der Wirklichkeit so genau wie möglich und so knapp wie nötig in einem Modell zu erfassen und dieses dann auf seine Eigenschaften hin zu untersuchen.
J. Biethahn, A. Lackner, M. Range: Optimierung und Simulation nach P. Mertens

Diesen Ansatz verfolge ich ebenfalls. Je größer des Simulationsmodell ist, desto größer wird der Aufwand und die Komplexität der Programmierung steigt überproportional. Um die Softwareumgebung nicht zu groß werden zu lassen, bleibt in dieser Variante die Zeit für Transporte unberücksichtigt.

Nach der Bearbeitung an einem Arbeitsplatz steht ein fertiggestellter Produktionsauftrag sofort dem nächsten Arbeitsplatz zur Verfügung.

Sei es direkt für die folgende Bearbeitung oder im Anfügen an die Warteliste.

Schrittkette der Simulation

Mit den jetzt bekannten Simulationselemente lässt sich eine Schrittkette für die Simulationsumgebung gestalten.

Einlesen der Daten
Startbedingungen herstellen
Produktionsprogramm abarbeiten
Auswertungen darstellen

Irgendwo her müssen die Daten für die Elemente kommen. Deswegen ist der erste Schritt das Einlesen der Daten. Eine Simulation kann nur starten, wenn festgelegt wurde, wie das erfolgen soll. Deshalb werden im zweiten Schritt die Startbedingungen festgelegt.

Im Hauptteil der Simulation bearbeitet das Simulationssystem die virtuellen Produktionsaufträge. Ist das ganze Produktionsprogramm abgearbeitet oder erfolgt ein Abbruch durch den Benutzer, muss es eine Möglichkeit geben, Auswertungen abzurufen und damit die Fragestellungen der Simulation zu beantworten.

Wie sehen die vier Schritte im Detail aus? Das ist das Thema der nächsten Kapitel.

Einlesen der Daten

Die Datengrundlage kommt aus der Unternehmenssoftware, dem ERP-System. Datenspeicher ist i. d. R. ein relationales Datenbanksystem, dass eine Vielzahl von Tabellen vorhält. Ein einfacher Datenaustausch gelingt dann, wenn auch die selbst-programmierte Simulationsumgebung mit einer Datenbank arbeitet.

Notwendige Tabellen sind Informationen über Artikel, Arbeitsplätze, Arbeitspläne und dem Produktionsplan.

Diese Daten liest das Simulationssystem einmalig beim Programmstart in dessen Objektstruktur ein. Aus Performance-Gründen ist es nicht zielführend, während der Simulation, Daten aus der Datenbank zu lesen.

Je nach Simulationsumfang sollten deshalb auch nicht alle verfügbaren ERP-Daten gespeichert werden, sondern nur diejenigen, welche für die Simulation betrachtet werden sollen.

Startbedingungen herstellen

In welchem Anfangsszenario soll die Simulation beginnen? Diese Frage lässt mit zwei Antworten klären. Einmal ist es möglich, dass die Simulation „leer“ beginnen soll. Gerade für die Untersuchung von Anlaufverhalten einer Linie kann das eine wichtige Fragestellung sein, um z. B. zu klären, wie lange es dauert bis nach dem Start Produktionsaufträge an nachgelagerten Arbeitsplätzen ankommen.

Auf der anderen Seite tritt ein Anlaufverhalten eher selten auf. Es gibt aber Fragestellungen, die sich auf ganz bestimmte Auftragskonstellationen beziehen.

Was passiert beispielsweise an Arbeitsplätzen bei einer Auftragsreihenfolge: große Losgröße – kleine Losgröße – große Losgröße?

Diese Konstellationen können sich zwar auch nach einem Anlaufverhalten einstellen, dafür wird aber Simulationszeit benötigt. Besser wäre es, wenn direkt mit einem festgelegten Szenario begonnen werden könnte.

Die Simulationsumgebung soll mit beiden Situationen klarkommen. In dieser ersten Version, im proof of concept kann nur mit einer leeren Simulation begonnen werden.

Produktionsprogramm abarbeiten

Sind alle Daten eingelesen und die Startbedingungen hergestellt, beginnt die eigentliche Simulation. Hier passiert das gleiche, wie in der Wirklichkeit.

Jeder Arbeitsplatz kann einen Eingangs- und/oder Ausgangspuffer haben. Ist der Eingangspuffer befüllt oder liegt direkt ein Produktionsauftrag für den Arbeitsplatz vor, kann mit der Bearbeitung begonnen werden.

Mögliche Auftragsflussvarianten über Puffer oder direkt zum Arbeitsplatz

Bearbeitet werden kann immer nur ein Auftrag. Ist ein Produktionsauftrag fertiggestellt, wird er zum nächsten Arbeitsplatz über einen ggf. vorhandenen Ausgangspuffer weitergereicht und der nächste Produktionsauftrag aus der Warteschlange geholt. Gibt es keinen Auftrag wartet der Arbeitsplatz einfach.

Es gibt also einiges zu steuern. Die Aufgabe übernimmt die Simulationssteuerung. Sie wird in einer Schleife wiederholt, bis das Produktionsprogramm durchlaufen ist oder die Simulation durch den Benutzer abgebrochen wird.

In der Wiederholungsschleife wird die Simulationszeit schrittweise erhöht. Sie prüft in jedem Schritt die Produktionsbedingungen für jeden Arbeitsplatz.

Jeder Produktionsauftrag wird von Arbeitsplatz zu Arbeitsplatz weitergereicht, bis alle enthaltenen Arbeitsfolgen fertiggestellt worden sind.

Produktionsauftrag "fließt" von Arbeitsplatz zu Arbeitsplatz — Produktionsauftrag „fließt“ von Arbeitsplatz zu Arbeitsplatz

Ein Arbeitsplatz kann mehrere Zustände haben.

Warten – falls sich kein Produktionsauftrag in der Warteschlange befindet
Rüsten – Im Arbeitsplan ist eine Rüstzeit vorhanden
Bearbeiten – Im Arbeitsplatz ist eine Einsatzzeit vorhanden

In der Realität können weitere Zustände vorliegen, die hier aus Gründen eines kürzeren Quellcodes erst einmal entfallen: Arbeitsplätze sind blockiert z. B. durch volle Puffer oder Arbeitsplätze haben eine Störung.

Die Warteschlangen der Eingangs- und Ausgangspuffer arbeiten im Zusammenhang mit dem Arbeitsplatz als typisches Ein-Stationen-Wartemodell (Single-Server-Model). Als Strategie wird FIFO (first-in-first-out) verwendet: Abhängig von der Eingangsreihenfolge werden die Aufträge auch wieder entnommen.

Je nachdem, wie das Simulationsszenario aussieht, kann es hier zu unerwünschten Konstellationen durch den Startzustand kommen. Das steuert die Quelle. Hat ein Arbeitsplatz keinen Auftrag im Puffer und ist ein passender in der Quelle vorhanden, wird dieser weitergegeben. Wird ein Start-Arbeitsplatz auch in Zwischenschritten verwendet, werden nach der FIFO-Regel erst alle Produktionsaufträge des Produktionsprogramms abgearbeitet.

Auswertungen darstellen

Ist die Simulation abgeschlossen, muss es eine Darstellung der durchlaufenen Produktionszustände geben.

Gesamtdauer der Simulation
Durchlaufzeit jedes Produktionsauftrags
Auslastungsgrade jedes Arbeitsplatzes (Warten-Rüsten-Bearbeiten)
Länge der Warteschlange jedes Arbeitsplatzes
Maximale Wartedauer auf nächsten Auftrag

Damit ist schon sehr gut umschrieben, was mein einfaches, selbst-programmiertes Simulationssystem alles leisten soll und wie das Konzept einer Umsetzung aussehen kann.

Kann man nun ein eigenes Simulationssystem entwickeln?

Ich denke die Frage, ob man selber ein einfaches Simulationssystem programmieren kann, lässt sich mit JA beantworten.

Programmiert habe ich in Lazarus und Freepascal (Object Pascal). Lazarus kompiliert in schnellen, nativen und gut lesbaren Code. Es ist auch für die meisten Betriebssysteme verfügbar. Die Datengrundlage bildet eine Datenbank. Aus Gründen der einfachen Bedienung nutze ich Microsoft Access. Die Anbindung an Lazarus erfolgt über ODBC. Lazarus bietet datenbanktechnisch viele Möglichkeiten an, so dass sicher auch Ihre Datenbankvorlieben erfüllt werden können.

Ein erster Blick auf die Software ist auch schon möglich. Unter Downloads können Sie die Runtime Version für Windows downloaden und ausprobieren.

MainForm der BETA-Version von SimProdSim

Sie werden sehen, der Produktionsplan wird aus der Datenbank geladen, Arbeitsplätze werden gerüstet und arbeiten Aufträge ab. Aufträge werden in der Reihenfolge der Arbeitspläne zwischen den Arbeitsplätzen weitergeleitet.

Ob das aber ausreicht, um so die angesprochenen produktionstechnischen Fragestellungen zu beantworten, muss ich jetzt weiter verifizieren.

Lerntechnisch kann ich bereits ein Resümee ziehen: Dem Verständnis für Prozessabläufe hilft es ungemein, sich diese von der Coding-Seite aus zu betrachten.

Das funktioniert am besten darüber, welche Zusammenhänge im Objektmodell integriert sind und wie die einzelnen Komponenten zusammenarbeiten. Das alles wäre etwas zu viel für diesen Blogartikel, deswegen gibt es noch einen weiteren. In diesem geht es neben der Programmierung auch um erste Ergebnisse und die Verifizierung des Modells.

Schauen Sie einfach wieder in meinem Blog vorbei oder tragen Ihre Mailadresse hier ein. Sie werden dann automatisch informiert, wenn ich weitere Artikel veröffentliche.