Produktionsprozess des

Ziele des Teilprojektes

In diesem Teilprojekt geht es darum, Prozesse bis ins letzte Detail zu analysieren, zu definieren und den Datenbedarf abzuleiten. Es geht im Einzelnen um die folgenden Prozessschritte:

• Bereitstellen der Engineering-Daten
• Abgleichen der Produktionsmittel
• Steuerung der Produktionsabläufe
• Erfassung von Produktionsdaten

Ein Beispiel: Welche Prozesse führen dazu, dass eine Leitung mit dem Kontakt verbunden werden kann? Dafür werden die Schritte schneiden, abisolieren, crimpen, stecken gebraucht. Oder: Um den Prozessschritt Ultraschallschweißen durchzuführen, müssen beispielsweise die Anzahl der Leitungen und die Schweißspezifika bekannt sein. Jeder Bearbeitungsschritt muss sozusagen mitgeschrieben werden. Das sind Eingangs- als auch Ausgangsparameter. Im Mittelpunkt stehen Fragen, wie: Welche Vorgänge sind wie durchgeführt worden, wurden sie erfolgreich durchgeführt, ist das Ergebnis in Ordnung? Ist die Qualität zu jedem einzelnen Produktionsschritt wirklich gesichert und nachvollziehbar dokumentiert? Planziel ist, für die einzelnen Stationen auf der Produktionsseite die notwendigen Daten zu ermitteln und diese interoperabel bzw. automatisiert zur Verfügung zu stellen.

Aktuelle Arbeitsschwerpunkte und Ergebnisse

Hauptaufgabe ist die Analyse des Ist-Zustandes. Sowie die Anforderungen an einen unternehmensübergreifenden und digitalisierten Produktionsprozess des Leitungssatzes zu formulieren. Diese Anforderungen sollen anschließend in den Produktionsprozess einfließen und so dafür sorgen, den Prozess selbst zu optimieren und Teilmodelle für die Verwaltungsschale zu entwickeln. Wenn am Ende alle Produkt- und Prozessdaten erhoben sind, können nun auch die Produktions- und Produkt-Verwaltungsschalen erstmals zusammengeführt werden. Im Idealfall kann mit Hilfe von Metadaten eine Art „Data Dictionary“ erarbeitet werden, das über den gesamten Leitungssatz-Lebensweg verwendet werden kann. Das zahlt ein auf die Rückverfolgbarkeit und die Resilienz innerhalb der Lieferkette.

Weitere Schwerpunkte sind:

• Integration der CAD-Daten aus dem Prozess und der Materialliste (Bill of Material, kurz BOM)
• Prozessbeschreibung (Bill of Process, kurz BOP)
• An- und Einbindung der entsprechenden IT-Systeme auf Basis eines PPR-Datenmodells (Produkt – Prozess – Ressource)

Das Teilprojekt 3 enthält fünf Arbeitspakete:

AP3.1 Untersuchung von Anforderungen

AP3.2 Konzeption eines Referenzmodells

AP3.3 Erforschung von Teilmodellen für Rückmeldedaten

AP3.4 Proof of Concept

AP3.5 Validierung der Prinzipien

Stand der Arbeiten

AP3.1 Untersuchung von Anforderungen

Bei der Definition der Anforderungen ergaben sich mehr als 90 Anforderungen, die in einer Liste zusammengestellt wurden. Ziel war es, in Erfahrung zu bringen, wo aktuell die „größten Schmerzen“ sind und wie diese Probleme durch die Implementierung eines standardisierten digitalen Zwillings lösbar werden. Letzen Endes geht es für den Bereich Produktionsprozesse darum, die notwendigen Informationen für die Ausführung der Produktionsprozesse bereitzustellen, damit Maschinen die Prozesse interoperabel und automatisiert starten können.

Außerdem wurde bezogen auf die Sammlung der Anforderungen eine Unterscheidung vorgenommen: Ob die Anforderungen einem Prozess zugeordnet werden müssen, der im Moment noch manuell stattfindet. Oder ob es sich dabei um einen bereits automatisierten Prozess handelt. Weil nicht alle 90 Anforderungen integriert werden können, muss man außerdem entscheiden, welche absolut unverzichtbar sind und welche einfach nur ein möglicher aber nicht zwingend notwendiger Zusatz wären.

Im Rahmen des AP 3.1 wurde eine Vorlage für die Anforderungserhebung entwickelt, TP-übergreifend von allen Konsortialpartnern angewendet, partnerübergreifend konsolidiert und bereinigt. Hieraus ist eine Liste mit konkreten Anforderungen an den Digitalen Zwilling eines Leitungssatzes und dessen Umsetzung durch Nutzung von Verwaltungsschalen entstanden.

AP3.2 Konzeption eines Referenzmodells

Im Kern geht es darum, das Zusammenspiel zwischen Verwaltungsschalen, Prozessschritten in der Produktion und den heterogenen IT-Landschaften zu definieren. Da gibt es mehrere Möglichkeiten: Zum einen kann die Verwaltungsschale durch das Asset repräsentiert werden. Das wäre dann ein einzelner Gegenstand, wie zum Beispiel eine Leitung oder aber eine Verbundkomponente. Die Verwaltungsschale kann jedoch auch aus einer gesamten Fabrik mit den zur Verfügung stehenden Maschinen und deren Fähigkeiten bestehen, welche ebenfalls wiederum eine Verwaltungsschale besitzen. Das wäre, wollte man das bildlich übersetzen, eine Art Zwiebelprinzip. Dass nämlich kleinere Verwaltungsschalen übereinandergeschichtet werden, die dann zusammen die Daten der Fabrik enthalten.

Außerdem wird der Frage nachgegangen, an welcher Stelle die Verwaltungsschale in den jeweiligen IT-Landschaften der Unternehmen „aufgehängt“ ist und wie eine Verwaltungsschale in den Lebenszyklus eines Assets implementiert werden kann. Die Datenflüsse bei den Akteuren, etwa bei den Herstellern der Komponenten und beim OEM, geben Aufschluss darüber, welche Daten bereitgestellt werden müssen und wie diese mit den Datenlandschaften (MES, PLM, ERP) der Akteure verknüpfbar sind. Gerade in der heterogenen IT-Systemlandschaft der Akteure können noch viele andere Systeme mithineinspielen. Die Erkenntnis ist: Die IT-Landschaft kann nicht, wie ursprünglich geplant, als Blackbox betrachtet werden. Klar ist: Wegen der Unterschiedlichkeiten in den IT-Systemlandschaften wird ein Anknüpfungspunkt gebraucht. Die Idee ist, einen „Data Virtualization Layer“ dazwischenzusetzen, der die Aufgabe hat, die Daten aus der Verwaltungsschale abzugreifen und bereitzustellen. Sowie die unternehmensbezogenen Daten aus PLM, MES, ERP auszulesen und verfügbar zu machen. Auch gilt es zu klären, welche Anforderungen sich an die Verwaltungsschale selbst daraus ableiten lassen.

Für einen unternehmensübergreifenden Datenaustausch sind Konzepte für den unternehmensinternen Datenzugriff sowie zur Datenaggregation und -konvertierung entscheidend, um alle relevanten Daten bereitstellen zu können. Hierzu wurde eine erste High-Level-Architektur erstellt, um alle Elemente für die Datengenerierung und -haltung in einem Modell zusammenzufassen. Die entwickelte Architektur setzt voraus, dass die unterschiedlichen Verwaltungsschalen der Wertschöpfungspartner über einen Datenraum verfügbar gemacht werden. Dies entspricht einer Cloudumgebung für jedes Mitglied in einer Wertschöpfungskette, in der sowohl die Typ- als auch Instanz-Verwaltungsschale gespeichert sind und über API (Application Programming Interfaces) angesprochen werden können. Für den unternehmensübergreifenden Datenaustausch wird angenommen, dass dieser über den in Catena-X entwickelten EDC (Eclipse Dataspace Connector) erfolgen wird.

Aufbauend auf der High-Level-Architektur wurden drei Use Cases definiert, um die Datenflüsse im Kontext einer konkreten Anwendung darzustellen. Diese Use Cases sollen Anwendungsfälle im Umfeld, „Predictive Maintenance, „Pay-per-Use für Anlagenbetreiber“ und eine „Overall Equipment Effectivness-Berechnung“ adressieren.

AP3.3 Erforschung von Teilmodellen für Rückmeldedaten

Das AP3.3 ist zum Teil noch in Bearbeitung. Um die Produktionsprozesse zu betrachten, wurden die Abläufe an den Maschinen bis zu den einzelnen Vorgängen heruntergebrochen, wie zum Beispiel dem Schneiden einer Leitung. Generell wichtig beim Kabelschneiden ist die Soll- und die Ist-Länge des Kabels, welche Inputdaten in diesem Fall notwendig sind, welche Outputdaten erzeugt werden. Daraus wurde eine Liste, die immer weiter verfeinert wurde, ein sogenanntes Klassendiagramm, das inzwischen fertig ist. Erste Ergebnisse zeigen, dass eine sehr hohe Anzahl an Input- und Outputparametern gebraucht werden. Auch spielt beim Fertigungsprozess etwa die Ressource, also die Maschine, auf der gefertigt wurde, eine entscheidende Rolle. Außerdem müssen zusätzliche Informationen über die Komponenten aus der Peripherie einfließen. Beim Crimpen zum Beispiel Informationen über den Stecker. Das macht deutlich, dass an der Stelle auch ein Zugriff auf die Produktverwaltungsschale möglich sein muss.

Schlussendlich ist ein Informationsmodell angedacht, in dem Maschinensprache steckt. Denn: Semantische Elemente sind zentral, wenn in Zukunft Maschinen miteinander reden sollen. Genau diese semantischen Elemente lassen sich in einem Informationsmodell hinterlegen, sodass klar wird, was genau mit einer „Ist-Länge“ gemeint ist und vieles mehr.

Nächste Schritte und erwartbare Ergebnisse

Es folgt die Bearbeitung der Arbeitspakete 3.4 / 3.5.

AP3.4 Proof of Concept: Ist die erste Umsetzung eines digitalen Zwillings.

AP3.5 Validierung der Prinzipien: Hier soll geprüft werden, ob die Annahmen richtig waren, wie sich die Ergebnisse interpretieren lassen. Das alles ist mit viel Dokumentation verbunden.