Angebotsplanung in dynamischen Produktionsnetzwerken

Ausgabe 3-2021, S. 147

1 Einleitung

Die auftragsgesteuerte Produktion (AGP), ein Anwendungsszenario von Industrie 4.0 [1], in dessen Zentrum der Produktionsauftrag steht, beschreibt die unternehmensübergreifende, automatisierte Vernetzung von Produktionsressourcen, um für einen spezifischen Auftrag dynamisch die erforderlichen Fähigkeiten und Kapazitäten bereitzustellen.

Am Beispiel von Zeichnungs- oder Sonderteilen zeigt sich, dass ein kurzfristiger Ausfall von Produktions- beziehungsweise Lieferkapazitäten hohe manuelle Aufwände nicht nur für das Auffinden, sondern auch für die Integration neuer Lieferanten in bestehende Bestell- und Logistikprozesse verursacht. Hier setzt die Plattform an, die im Rahmen des Forschungs­projekts „Broker für dynamische Produktionsnetzwerke“ (DPNB) mit dem Ziel, Produktionsnetzwerke in ihrer Reaktionsfähigkeit und -schnelligkeit zu unterstützen, entwickelt wird. Sie soll zwischen Nach­fragern und Anbietern von Produktions-, Montage- und Transportkapazitäten vermitteln und deren Integration beschleunigen (vgl. Bild 1). Weitere Projektziele sind die Entwicklung eines Montage-Assistenten und eines Geschäftsmodells für die Plattform (siehe dazu [2]).

Die Aktivitäten der Plattform werden in drei Anwendungs­fällen dargestellt (vgl. Bild 2).

Der Anwendungsfall UC0 thematisiert das Onboarding neuer Nachfrager und Anbieter. Der Fokus von UC0 ist die Modellierung der produktionstechnischen Fähigkeiten von Anbietern, welche für die Bildung auftragsspezifischer Produktionsnetzwerke essenziell sind. Anwendungsfall UC1 beschäftigt sich mit der Anfragebearbeitung vom Eingang einer Produktionsanfrage bis zur Vorlage eines Angebots beim Kunden. Erteilt der Kunde der Plattform schließlich den Auftrag, so erfolgt die Auftragsausführung und -überwachung (UC2).

Der Inhalt dieses Beitrags besteht in der detaillierten Aus­einandersetzung mit UC1. Der Fachaufsatz gliedert sich in eine Darstellung der microservice-basierten Systemarchitektur der Plattform (Kapitel 2) sowie der einzelnen Services, welche im Rahmen des UC1 entwickelt werden (Kapitel 3). Es folgt in Kapitel 4 ein Einblick in besondere Herausforderungen bei der Entwicklung und Implementierung. Kapitel 5 gibt einen kurzen Ausblick auf Weiterentwicklungsmöglichkeiten.

2 Systemarchitektur und Technologien

Im Rahmen des Projekts wird ein minimal funktionsfähiger Prototyp (Minimal Viable Product, MVP) implementiert. Dieser Prototyp ist auf die wesentlichen Funktionalitäten fokussiert, um die theoretischen Konzepte in der Implementierung zu validieren und das Gesamtziel des Projekts darzustellen. Das Gesamtsystem basiert auf einer Microservice-Architektur (vgl. Bild 3) mit einer zentralen Broker-Instanz im Backend. Die Pfeile in dem Bild stellen Datenflüsse zwischen den Komponenten dar.

Im Backend sind einzelne Funktionalitäten, wie zum Beispiel die auftragsspezifische Planung eines Produktionsnetzwerks, in abgeschlossene Programme (Services) ausgelagert. Über vorab definierte Rest-Schnittstellen kommunizieren die Services mit dem Broker. Der Broker koordiniert die Ein- und Ausgaben der Services, speichert Daten und stellt das Benutzerinterface für die Kunden bereit. Im Prototyp dient eine Website als Frontend, das mittels GraphQL mit dem Broker kommuniziert und dem Benutzer die Registrierung auf der Plattform, das Anfragen von An­geboten, deren Bestellung und die Auftragsüberwachung erlaubt.

Durch die Nutzung von Schnittstellen können die einzelnen Komponenten in unterschiedlichen Programmiersprachen umgesetzt werden. Im Projekt wird der Broker in NodeJS mit dem Framework NestJS umgesetzt. Die Website nutzt Angular als Framework und die Services werden in Java mit Spring Boot umgesetzt. Jede Komponente wird in einem Docker-Container ausgeliefert, sodass diese in einer entsprechenden Container-Umgebung, zum Beispiel Microsoft Azure, zusammenarbeiten können.

3 Im Detail: Use Case 1

Der UC1 bildet den Prozess von der Produktionsanfrage für ein Produkt bis zur Bereitstellung eines Angebots ab. Im Folgenden werden die Services genauer beschrieben, die in diesem Anwendungsfall zusammenspielen. Zur Veranschaulichung dient als Beispielprodukt ein Winkelverbinder (vgl. Bild 4).

Zwar handelt es sich hierbei grundsätzlich um ein standardisiertes Massenprodukt, es wird hier aber angenommen, dass der Kunde ein spezifisches Sondermaß wünscht, welches nicht auf Lager produziert wird.

Der grundlegende Ablauf von UC1 ist in Bild 5 skizziert.

Er beginnt links mit der Produktionsanfrage durch den Kunden. Dazu gibt der Kunde im Frontend die Beschreibung des gewünschten Bauteils in Form eines CAD-Modells und einer technischen Zeichnung sowie Details seiner Anfrage an. Die Details umfassen unter anderem den gewünschten Liefertermin, Preisvorstellung und Lieferort. Zusätzliche Angaben, ob es sich etwa um eine zeitkritische oder preissensible Anfrage handelt, kann der Broker verwenden, um dem Kunden alternative Angebote vorzuschlagen. Anschließend wird die Anfrage an die Services Requirements Engineering, Network Builder und Pricing zur Angebotsplanung übergeben. Das Ergebnis wird aufbereitet und dem Kunden im Frontend präsentiert, um so eine Kaufentscheidung zu ermöglichen. Hiermit endet der durch UC1 beschriebene Prozess. Die nachgelagerte Auftragsausführung und -überwachung definiert UC2, welcher nicht mehr Gegenstand dieses Beitrags ist.

3.1 Requirements Engineering

Ziel dieses Services ist die Anfrage des Kunden hinsichtlich der implizit geforderten Produktionsfähigkeiten zu analysieren und daraus mögliche Prozessketten für das gewünschte Bauteil abzuleiten. Bei einer Prozesskette handelt es sich um eine mögliche Fertigungsvariante für das angefragte Bauteil, bestehend aus einer Abfolge von Bearbeitungen. Vereinfachend wird im MVP von linearen Prozessketten ausgegangen. Bild 6 zeigt diesen Ablauf, beginnend mit der Produktionsanfrage, sowie eine zwei- und eine dreistufige Prozesskette:

Schneiden → Bohren → Biegen

Laserschneiden → Biegen

Jede Bearbeitung wird soweit heruntergebrochen, dass sie durch eine Maschine oder Arbeitsstation ausgeführt werden kann. Zu jeder Bearbeitung werden die Anforderungen an den Maschinentyp bestimmt. Diese können beispielsweise die verarbeitbare Materialgeometrie umfassen. Auf Grundlage dieser Fähigkeits­anforderungen wird aus den im Broker verfügbaren Maschinen­typen für jede Bearbeitung geprüft, welche Typen diese Anforderungen erfüllen und somit für ein Angebot in Betracht gezogen werden können. Die Prozessketten mit den zugeordneten Maschinentypen werden für die Anfrage an den Broker über­geben und können im nächsten Service genutzt werden.

3.2 Network Builder (NB)

Den Ablauf dieses Services skizziert Bild 7.

Aufgabe des NB ist die Planung des auftragsspezifischen Produktionsnetzwerks. Das Planungsergebnis ist eine (konkrete) Lieferkette, die einen Produktions- und Transportplan beinhaltet. Das bedeutet, eine Lieferkette beschreibt den konkreten zeitlichen Ablauf, wie und zu welchen Kosten die spezifische Produktionsanfrage realisiert werden kann. Der Service arbeitet in zwei Stufen: Routen- und Lieferkettenbildung.

Eine Route ist eine Abfolge konkreter (Maschinen-/Transport-)Ressourcen der registrierten Anbieter. Der NB erwartet als Eingabe die Produktionsanfrage und die zuvor ermittelten Prozessketten und erzeugt im Rahmen der Routenbildung eine Menge an realisierbaren Routen für die gegebene Anfrage.

Die Routenbildung beginnt damit, auf Basis der Prozessketten alle Maschinenressourcen mit entsprechenden Fähigkeiten und verfügbaren Kapazitäten im relevanten Planungshorizont abzu­fragen. Dadurch ergibt sich für jede Bearbeitung eine Menge an verfügbaren, räumlich verteilten Ressourcen. Hierbei werden die zum Anfragezeitpunkt im Broker verfügbaren Kapazitäten verschiedener (Produktions-/Transport-)Anbieter berücksichtigt. Wie in Bild 7 unten links zu sehen, hat in dem Beispiel das Laserschneiden eine, jede andere Bearbeitung zwei verfügbare Maschinen. Zusätzlich dargestellt ist der Lieferort des Kunden.

Zur Aufgabe der Routenbildung gehört auch, benötigte Transporte zwischen Bearbeitungen, die auf Ressourcen an verschiedenen Standorten stattfinden, in die Route zu integrieren. In Bild 7 ist unten mittig zu sehen, dass ein Transport vom Laserschneiden zum Biegen notwendig ist. Alle anderen Maschinen sind vereinfacht am selben Standort angenommen – es könnten zum Beispiel Maschinen eines Werkstattfertigers sein. In diesem Netzwerk gibt es zehn potenzielle Routen. Dies zeigt auch, dass die Größe des Netzwerks und damit die Menge an potentiellen Routen schon für relativ kleine Szenarien schnell groß ist.

Allerdings sind im Allgemeinen nicht alle potentiellen Routen auch zulässig. Eine zulässige Route zeichnen vor allem zwei Dinge aus: Sie berücksichtigt die Bearbeitungsreihenfolge der Prozesskette und ist im Hinblick auf die zeitliche wie mengenmäßige Verfügbarkeit der Ressourcen realisierbar. Daher werden in der Routenbildung unzulässige Routen bereits herausgefiltert (vgl. Bild 7, unten rechts). Im Beispiel ist angenommen, dass jeweils eine Maschine für Bohren und Biegen in keiner zulässigen Route vorkommt. Die Gesamtzahl an Routen reduziert sich damit im Beispiel auf drei. Für weitere Details zur Routenbildung wird auf Abschnitt IV verwiesen.

Sobald die zulässigen Routen bekannt sind, startet der NB die zweite Planungsstufe. Aufgabe der Lieferkettenbildung besteht darin, nach einem definierten Bewertungskriterium zu entscheiden, welche Route für das Angebot ausgewählt und welches Lieferdatum dem Kunden angeboten werden soll. Die Kriterien für Lieferketten ergeben sich aus der Anfrage. Sollte der Kunde zum Beispiel eine schnellstmögliche Lieferung wünschen, wird nach einer Lieferkette mit frühestmöglichen Lieferdatum gesucht. Ist der Lieferzeitpunkt hingegen weniger kritisch, dafür aber der Angebotspreis, so wird nach einer möglichst kosteneffizienten Lieferkette gesucht. Weitere Details zur Lieferkettenbildung finden sich in Abschnitt IV. Mit der Entscheidung über die Lieferkette(n) ist die Bearbeitung im NB beendet.

3.3 Pricing

Das Pricing (vgl. Bild 8) schlägt auf die errechneten Gesamtkosten für die Lieferketten eine Gewinnmarge auf, welche die Plattform für den Gesamtservice erhält. Dieser Angebotspreis wird zurück an den Broker übermittelt.

Nun liegen im Broker alle für die finale Angebotsdarstellung nötigen Informationen vor. Damit ist der Prozess in UC1 abgeschlossen.

4 Besondere Herausforderungen

Dieser Abschnitt berichtet von einigen Herausforderungen, die bei der Entwicklung und Umsetzung der vorgestellten Konzepte auftreten.

Die Problematik der Reduzierung der Routen wird mittels Graphentheorie angegangen, bei dem das Netzwerk, siehe Bild 7, als gerichteter Graph dargestellt wird. Die Knoten stellen die einzelnen Maschinen mit Kapazitäten dar und die Kanten mögliche Routenentscheidungen. Bereits beim Hinzufügen der Kanten wird für jede Kante geprüft, ob es dadurch eine gültige Route bis zu diesem Knoten gibt. Dabei gilt, dass alle Schritte von links nach rechts linear nacheinander ausgeführt werden müssen. Dementsprechend müssen die Zeiträume der einzelnen Schritte auch nacheinander sein und dürfen sich nicht überschneiden. Eine zusätzliche Bedingung stellt der Wunschpreis des Kunden dar, der nicht überschritten werden darf. Knoten ohne eingehenden Kanten werden anschließend als nicht nutzbar identifiziert und entfernt. Durch die Traversierung des Graphen können abschließend alle möglichen Routen aus dem Graph abgeleitet werden.

Im Rahmen der Lieferkettenbildung entsteht zunächst ein Entscheidungsproblem für eine einzelne Anfrage nach einem Produkt. Es fragt danach, welche Route aus einer gegebenen Menge zulässiger Routen auszuwählen und wie diese zeitlich einzuplanen ist, sodass die Kapazitätsrestriktionen der Ressourcen und Lieferterminrestriktionen des Kunden eingehalten werden. Diese Entscheidungen sind so zu treffen, dass das Zielkriterium der Anfrage möglichst gut erfüllt ist. Naheliegend ist, auch Anfragen nach mehreren (unabhängigen) Produkten beziehungsweise gleichzeitig mehrere Ein-Produkt-Anfragen zu betrachten. So könnte ein nachfragendes Unternehmen beispielsweise mehrere Produktionsanfragen zu einer bündeln.

Im Projekt werden die genannten Entscheidungsprobleme als mathematische Optimierungsprobleme modelliert und mittels Methoden des Operations Research gelöst. Dabei kommt auch Standardsoftware zur Lösung von linearen gemischt-ganzzahligen Optimierungsproblemen zum Einsatz, wie zum Beispiel „IBM Ilog CPlex“ (vgl. [4]).

5 Ausblick

Beim Requirements Engineering stellt die automatische Erkennung von möglichen Prozessketten, allein auf Basis der Konstruktion, in Form einer technischen oder 3D-Zeichnung (CAD), eine Hauptschwierigkeit dar. Eine Möglichkeit ist die Erkennung von Bearbeitungen in technischen Zeichnungen mittels neuronalen Netzen.

Vor dem Hintergrund, dass die Plattform einem kontinuierlichen Zulauf an Produktionsanfragen unterliegt, stellt sich die Frage, wie der Network Builder (NB) mit dieser Nachfrageun­sicherheit umgehen sollte. Ein möglicher Ansatzpunkt wird darin gesehen, vorausschauend die Produktionsanfragen innerhalb eines definierten Zeitraums, dem Lookahead, zu sammeln und gemeinsam einzuplanen, um so die vorhandenen Ressourcen besser auszunutzen.

Eine über den UC1 hinausgehende Weiterentwicklung des NB könnte im Rahmen einer dedizierten Transportnetzwerkoptimierung versuchen, die durch die bestellten Produktionsaufträge festgelegten Transportflüsse effizient zu bündeln.

Das Forschungs- und Entwicklungsprojekt DPNB wird mit Mitteln des Bundesministeriums für Bildung und Forschung (BMBF) im Programm „Innovationen für die Produktion, Dienstleistung und Arbeit von morgen“ (Förderkennzeichen 02P17D060 bis 02P17D066) gefördert und vom Projektträger Karlsruhe (PTKA) betreut. Die Verantwortung für den Inhalt dieser Veröffentlichung liegt bei den Autoren.

Literatur

1. Plattform Industrie 4.0: Fortschreibung der Anwendungsszenarien der Plattform Industrie 4.0. Ergebnispapier. Stand: 2016. Internet: https://www.plattform-i40.de/PI40/Redaktion/DE/Downloads/Publikation/fortschreibung-anwendungsszenarien. Zugriff am 09.12.2020
2. Wiesner, S.; Behrens, L.; Baalsrud Hauge, J.: Business Model Development for a Dynamic Production Network Platform. In: Lalic, B.; Majstorovic, V.; Marjanovic, U. et al. (Hrsg.): Advances in Production Management Systems. Towards Smart and Digital Manufacturing. Cham: Springer International Publishing 2020, S. 749–757
3. FZI Forschungszentrum Informatik: DPNB Broker für dynamische Produktionsnetzwerke. Internet: https://www.dpnb.de/dpnb/motivation/. Zugriff am 09.12.2020
4. IBM: IBM ILOG CPLEX Optimization Studio. Internet: https://www.ibm.com/products/ilog-cplex-optimization-studio. Zugriff am 09.12.2020