Konzept Und Lösungen Für Automatisches Produktdatenmanagement

Konzept und Lösungen für automatische Produktdatenverwaltung

vorgelegt von: Dipl.- Ing. Carina Fresemann

an der Fakultät V – Verkehrs- und Maschinensysteme der Technischen Universität Berlin zur Erlangung des akademischen Grades Doktorin der Ingenieurwissenschaften - Dr.-Ing. –

genehmigte Dissertation

Promotionsausschuss:

Vorsitzender: Prof. Dr.-Ing. Michael Rethmeier

Gutachter: Prof. Dr.-Ing. Rainer Stark

Gutachter: Prof. Dr.-Ing. Detlef Gerhard

Tag der wissenschaftlichen Aussprache: 05.02.2021

Berlin 2021

Vorwort der Autorin

“Beginning a discussion on how to structure the bill of material is a good way to start a fight in a bar” (Garwood 2000). Ebensolche Diskussionen darüber, wie Produktdatenmanagement in einem Unternehmen zu implementieren und auszuführen ist, habe ich mehrere Jahre im professionellen Bereich durchlebt. Dabei wurden viele Gespräche jener Zeit mit Grundsatz- fragen beendet, mitunter wurden daraus Innovations- oder Lösungsideen erkoren. Auf Basis dieses Vorwissens entstand die Ahnung, dass sich einfachere Lösungen für Kern PDM Aufgaben entwickeln lassen. Die Suche nach solchen Lösungen legte den Grundstein für diese Promotion. Ich hoffe, die Arbeit inspiriert Leser, den eingeschlagenen Weg weiter- zugehen. Ohne die Unterstützung vieler Menschen auf diesem Weg, wäre das fertige Werk jedoch nicht entstanden. Unter der Supervision von Prof. Stark entstand diese Arbeit im Rahmen der Tätigkeit als Wissenschaftliche Mitarbeiterin am Fachgebiet Industrielle Informationstechnik der TU Berlin. Für die Bereitstellung von Möglichkeiten und konstruktive Kritik bedanke ich mich. Dankbar bin ich für den umfänglichen kritischen Diskurs mit Hartmut Sörgel und Martin Witte. Sie haben mein Verständnis für einige Sachverhalte immens verbessert. Weitere freundliche Unterstützung und fachliche Diskussionen mit Wolfgang Tauber und Udo Freise brachten Licht ins Dunkel: einerseits bezüglich der bestehenden Technologien aber auch der hinsichtlich der industriellen Erwartungshaltung. Ebenso bedanke ich mich bei Dietmar Jenke, Axel Sylvester, Corinna Beier und Uwe Kloss für die Bereitstellung von Daten und praktischen Beispielen. Diese bilden die Basis für die Versuche und geben der Arbeit somit die erforderliche praktische Relevanz. Weiterhin wäre diese Arbeit nicht ohne das Zutun von Vignesh Subban, Felix Lösch, Jan Mohrlock, Timos Ioannou und insbesondere Lars Bittcher möglich gewesen. Ich bedanke mich ausdrücklich für die gute und gewissenhafte Unterstützung aber auch für den inhaltlichen Diskurs, der einige Ansätze hinsichtlich der Praktikabilität und Relevanz verbesserte. Schlussendlich hat zudem der familiäre und geistliche Rückhalt, die Geduld und Ermutigung in schwierigen Phasen die Bewerkstelligung dieser Arbeit ermöglicht. Ich freue mich gegenwärtig auf viele frohe, gemeinsame Stunden mit meinem Mann und meinen Kindern.

Aus Gründen der Lesbarkeit wird in dieser Arbeit die maskuline Form Anwender oder Nutzer verwendet. Dennoch sind selbstverständlich alle Personen gemeint. Ebenso werden einzig im Englischen bestehende Begriffe, wie tokenization nicht übersetzt.

Inhaltsverzeichnis

Vorwort der Autorin ...... i

Inhaltsverzeichnis ...... ii Abbildungsverzeichnis ...... v Tabellenverzeichnis ...... vii Abkürzungsverzeichnis ...... ix Zusammenfassung ...... i Abstract ...... ii 1 Einführung ...... 1

1.1 Problemstellung und Motivation...... 1

1.2 Zielstellung und Abgrenzung der Arbeitsinhalte ...... 2

1.3 Charakter der Arbeit und Vorgehensweise ...... 6

2 Produktdatenverwaltung ...... 8

2.1 Produktdaten ...... 8

2.2 Dimensionen ...... 13

2.3 Methoden ...... 20

2.3.1 Gliederungen...... 21

2.3.2 Varianten ...... 25

2.4 Werkzeuge ...... 27

2.4.1 Funktionen ...... 28

2.4.2 Integration von Autoren Werkzeugen ...... 31

2.4.3 Stand der Forschung zu PDM Funktionen ...... 33

2.5 Zusammenhang von Methoden und Funktionen ...... 35

2.6 Automatisierungspotentiale ...... 39

3 Studie zur effizienten Produktdatenverwaltung ...... 41

3.1 Zielstellung und Durchführung ...... 41

3.2 Ergebnisse und Zwischenfazit ...... 42

4 Konzept für effiziente Produktdatenverwaltung ...... 46 4.1 Stufenmodell der Automatisierung ...... 46

4.2 Ableitung der Bedarfe und Potentiale in ein Konzept ...... 51

Inhaltsverzeichnis

4.2.1 Architektur des InADM ...... 55

4.2.2 Funktionen des InADM ...... 56

4.2.3 Auswirkungen auf die Methoden der Produktdatenverwaltung ...... 75

5 Exemplarische Umsetzung relevanter Bedarfe ...... 77

5.1 Design Artefakte automatisch zuweisen ...... 77

5.1.1 Funktionsweise von Semantischen Technologien ...... 79

5.1.2 Anwendung auf den Kontext der Gliederungen ...... 82

5.1.3 Anwendung auf den Kontext der steuernden Metainformation ...... 85

5.1.4 Versuchsaufbau und Daten für Gliederungen ...... 89

5.1.5 Versuchsergebnisse für Gliederungen ...... 90

5.1.6 Versuchsaufbau und Daten für Metadaten ...... 92

5.1.7 Versuchsergebnisse für Metadaten ...... 94

5.1.8 Beurteilung der Ergebnisse zur Verwendung im InADM ...... 96

5.2 Nutzerinteraktion durch einen Chat Bot ...... 99

5.2.1 Funktionsweise der natürlichen Sprachverarbeitung ...... 100

5.2.2 Anwendung auf das Variantenmanagement ...... 106

5.2.3 Versuchsaufbau und Daten ...... 108

5.2.4 Versuchsergebnisse ...... 111

5.2.5 Beurteilung der Ergebnisse zur Verwendung im InADM ...... 116

5.3 Plausibilisierung auf Basis geometrischer Daten ...... 118

5.3.1 Algorithmus auf Basis der geometrischen Merkmalserkennung ...... 118

5.3.2 Versuchsaufbau und Daten ...... 125

5.3.3 Versuchsergebnisse ...... 130

5.3.4 Beurteilung der Ergebnisse zur Verwendung im InADM ...... 139

5.4 Plausibilisierung auf Basis von Identifikationsdaten ...... 140

5.4.1 Funktionsweise des Nearest Neighbour Verfahrens ...... 141

5.4.2 Anwendung auf die Ermittlung von Varianten ...... 142

5.4.3 Versuchsaufbau und Daten ...... 144

5.4.4 Versuchsergebnisse ...... 145

5.4.5 Beurteilung der Ergebnisse zur Verwendung im InADM ...... 147

iii

Inhaltsverzeichnis

5.5 Zwischenfazit ...... 149

6 Evaluierung des Konzepts ...... 151

6.1 Aufbau der Expertenbefragung ...... 151

6.2 Ergebnisse der Befragung ...... 153

7 Weiterer Forschungs- und Handlungsbedarf ...... 159

7.1 Entwicklungspotentiale ...... 159

7.2 Verortung im Forschungsfeld ...... 161

8 Literaturverzeichnis ...... 164 Erklärung ...... 173 Anhang ...... I Fragebogen zur effizienten Produktdatenverwaltung ...... I

Informationen zu den befragten Personen ...... III

Versuchsdaten: Datenblätter ...... IV

Versuchsergebnisse: Zuweisung Produktdaten ...... IV

Versuchsdaten: Tripelec Funktionen ...... V

Fragebogen zur Evaluierung des Chat Bots ...... VII

Fragebogen zur Evaluierung des Konzepts ...... VIII

Abbildungsverzeichnis

Abbildung 1: Abhängigkeiten des Untersuchungsgegenstands, eigene Darstellung ...... 3 Abbildung 2: Untersuchungsgegenstand: Methoden und Funktionen der Datenverwaltung ... 5 Abbildung 3: Verortung des Fokus der Forschung im PEP ...... 6 Abbildung 4: Kapitelstruktur ...... 7 Abbildung 5: Übersicht unterschiedlicher Metadaten ...... 10 Abbildung 6: Zusammenhang von Version und Revision für mechanische Bauteile ...... 14 Abbildung 7: Aufprägen des Status auf Objekte und Produktumfänge ...... 15 Abbildung 8: Generischer Aufbau der Produktgliederung nach Glauche ...... 16 Abbildung 9: Schematische Darstellung zur Bildung von Sichten ...... 18 Abbildung 10: Technischer Prozesse in der Automatisierungstechnik nach Lauber ...... 47 Abbildung 11: Automatisierungslevel, eigene Darstellung ...... 49 Abbildung 12: InADM Konzept ...... 52 Abbildung 13: IT-Architektur Ebenen des InADM ...... 55 Abbildung 14: Zuweisung von Design Artefakten zu Produktgliederungen ...... 60 Abbildung 15: Übergabe von Design Artefakten und Zuweisung zu einer Gliederung...... 61 Abbildung 16: Visualisierung von Strukturen und Zusammenhängen ...... 62 Abbildung 17: Etablieren realtionaler Verbindungen ...... 63 Abbildung 18: Konzept zur Bildung und Verwaltung von Varianten...... 64 Abbildung 19: Verlinkung der Design Artefakte zu Varianten ...... 65 Abbildung 20: Anzeigen und Modifizieren von Produktvarianten ...... 67 Abbildung 21: Erstellen von Verwendungsnachweisen ...... 68 Abbildung 22: Verwendung von Hashfunktionen für die Versionskontrolle...... 70 Abbildung 23: Allokieren von Design Artefakten zu Funktionen ...... 77 Abbildung 24: Verlinkung eines Design Artefakts mit einem Referenzobjekt ...... 78 Abbildung 25: Programmablauf zur statistischen Zuordnung ...... 83 Abbildung 26: Sequenzdiagramm der Taxonomie Zuweisung ...... 86 Abbildung 27: Rückgabe des Codes für die Zuweisung zu einem Produktdatenblatt ...... 88 Abbildung 28: Foto eines ersten physischen Aufbaus des Tripelecs ...... 89 Abbildung 29: Taxonomie der Zolltarifnummern ...... 92 Abbildung 30: Übersicht der Chat Bot Architektur ...... 99 Abbildung 31: Parsing - Graph für einen englischen Satz nach Eisenstein ...... 101 Abbildung 32: Schematische Darstellung der Bag-of-Words Methode ...... 102 Abbildung 33: Übersichtsschaubild zur Erkennung und Korrektur von Tippfehlern ...... 105 Abbildung 34: Sequenzdiagramm des Chat Bots ...... 106 Abbildung 35: Aktivierung des Chat Bots aus der CAD Umgebung ...... 108 Abbildung 36: Screenshot der Interaktion zwischen Anwender und Chat Bot ...... 112

Abbildungsverzeichnis

Abbildung 37: Bildschirmausschnitt des Chat Bots ...... 112 Abbildung 38: Abbruch des Programms durch den Chat Bot ...... 113 Abbildung 39: Fehlerhafte Nutzereingabe und Korrekturvorschlag durch den Chat Bot ...... 113 Abbildung 40: Ergebnis der SUS Auswertung für den Chat Bot ...... 115 Abbildung 41: Ausschnitt des xml Schemas einer STEP Datei ...... 119 Abbildung 42: Dimensionen und Orientierung charakteristischer Merkmale ...... 120 Abbildung 43: Programmablauf der Varianten-Plausibilisierung ...... 122 Abbildung 44: Exemplarische Rückgabe der Zusammengehörigkeitsanalyse ...... 124 Abbildung 45: Explosionsdarstellung der Spindelauspresseinheit ...... 125 Abbildung 46: Explosionsdarstellung des Sternmotors ...... 127 Abbildung 47: Maschinenelemente ohne Bezug zueinander ...... 128 Abbildung 48: Verlängerung des Bolzens ...... 130 Abbildung 49: Auszug der Ergebnisse für die Verlängerungsstange ...... 131 Abbildung 50: Ergebnis Ausdruck des Sternmotors ...... 133 Abbildung 51: Funktionsweise der Nearest Neighbour Methode ...... 142 Abbildung 52: Sequenzdiagramm des erstellten SW-Codes ...... 143 Abbildung 53: IT-Architektur Schaubild zur Plausibilisierung mittels Identifikationsdaten .... 143 Abbildung 54: Screenshot der Rückgabe für den Versuch „ein fehlendes Bauteil“ ...... 146 Abbildung 55: Screenshot der Rückgabe für den Versuch "zwei fehlende Bauteile" ...... 146 Abbildung 56: Screenshot der Rückgabe für den Versuch "zwei zusätzliche Bauteile" ...... 147 Abbildung 57: Aufbau und Umfang der Evaluierung des InADM Konzepts ...... 151 Abbildung 58: Effizienz des Variantenmanagements ...... 153 Abbildung 59: Akzeptanz des Variantenmanagements ...... 153 Abbildung 60: Einfluss auf die Datenqualität ...... 154 Abbildung 61: Bewertung des Funktionsumfangs ...... 154 Abbildung 62: Effizienz der Metadatenverwaltung ...... 155 Abbildung 63: Akzeptanz der Metadatenverwaltung ...... 155 Abbildung 64: Methoden für Metadaten ...... 155 Abbildung 65: Funktionen für Metadaten ...... 155 Abbildung 66: Akzeptanz der Gliederung...... 156 Abbildung 67: Effizienz der Produktstrukturierung ...... 156 Abbildung 68: Methoden der Produktgliederung ...... 157 Abbildung 69: Funktionen der Produktgliederung ...... 157 Abbildung 70: Kombination der InADM Technologien ...... 160 Abbildung 71: Integration von Hardware, Software und Daten ...... 163

Tabellenverzeichnis

Tabelle 1: Übersicht typischer Attribute ...... 11 Tabelle 2: Automatisierungspotentiale von Metadaten...... 13 Tabelle 3: Ingenieursbedarfe an die Produktdatenverwaltung ...... 19 Tabelle 4: Gegenüberstellung von Merkmalen der Gliederung ...... 22 Tabelle 5: Methoden und Tätigkeiten der Produktgliederung ...... 23 Tabelle 6: Methoden und Tätigkeiten zur Variantenbildung ...... 26 Tabelle 7: Übergeordnete Bedarfe für PDM Werkzeuge und Methoden ...... 28 Tabelle 8: Methoden zum Übertrag von Modellen zwischen CAD und PDM Werkzeugen ....33 Tabelle 9: Zusammenhang von Funktionen und Methoden der Produktgliederung ...... 37 Tabelle 10: Wirkung von Funktionen auf die Bildung von Produktvarianten ...... 39 Tabelle 11: Potentiale für die Optimierung der Produktdatenverwaltung ...... 39 Tabelle 12: Verwaltungsaufwand der Dimensionen ...... 42 Tabelle 13: Paradigmen der Datenverwaltung im InADM ...... 54 Tabelle 14: Übersicht der zu speichernden Informationen nach Ort...... 56 Tabelle 15: Übersicht der Funktionen im InADM Konzept ...... 72 Tabelle 16: Aufgaben der Anwender im InADM Konzept ...... 74 Tabelle 17: Vergleich bisheriger und neuer Methoden ...... 75 Tabelle 18: Schema der Tabelle für CAD Daten ...... 84 Tabelle 19: Schema der Tabelle für Funktionen ...... 84 Tabelle 20: Schema der Zuweisungsmatrix für Zolltarifnummern und Produktdatenblätter ...87 Tabelle 21: CAD Bauteile für den Versuch der Zuweisung und Zuordnung zu Funktionen ...90 Tabelle 22: Ergebnisse der CAD Zuweisung auf Basis des Dateinamens ...... 90 Tabelle 23: Ergebnisse der Zuweisung ...... 91 Tabelle 24: Versuchsaufbau für die Zuweisung von Produktdatenblättern ...... 93 Tabelle 25: Zusammenstellung der Versuchsergebnisse ...... 94 Tabelle 26: Zusammenstellung der Versuchsergebnisse ...... 95 Tabelle 27: Zusammenstellung der Versuchsergebnisse ...... 96 Tabelle 28: Ergebnisse der Kosinus Ähnlichkeit nach Eisenstein ...... 103 Tabelle 29: Varianten des Tripelecs ...... 109 Tabelle 30: Übersicht der SUS Werte pro Proband ...... 116 Tabelle 31: Schema der „STEP item list“ ...... 122 Tabelle 32: Schema der “dedicated object list” ...... 123 Tabelle 33: Ausgewählte Dimensionen der Gewindeauspresseinheit ...... 126 Tabelle 34: Ausgewählte Dimensionen des Sternmotors ...... 127 Tabelle 35: Ausgewählte Dimensionen nicht zusammengehörender Maschinenelemente . 129 Tabelle 36: Ergebnisse für die Spindelauspresseinheit...... 132

vii

Tabellenverzeichnis

Tabelle 37: Ergebnisse für den Sternmotor ...... 133 Tabelle 38: Ergebnisse für unabhängige Bauteile ...... 135 Tabelle 39: Ergebnisse für Sternmotor und Verstellhebel ...... 137 Tabelle 40: Ergebnisse der Varianten der Spindelauspresseinheit ...... 138 Tabelle 41: Schematischer Aufbau der Versuchsdaten ...... 144 Tabelle 42: Zusammenstellung personenbezogener Daten zur präskriptiven Befragung ...... III Tabelle 43: Ergebnisse der Zuweisung für den Gabelstapler zu Zolltarifnummern ...... IV Tabelle 44: Ergebnisse der Zuweisung für die Kettensäge zur Zolltarifnummmer ...... IV

viii

Abkürzungsverzeichnis

BOM ...... Bill of Material BOW ...... Bag-of-Words, Bag of Words Methode CAD ...... Computer Aided Design CAE ...... Computer Aided Engineering CAX ...... Computer Aided "X" CF ...... characteristic feature CLIR ...... Crosslinguales Information Retrieval CLISP ...... Computational Linguistic & Psycholinguistic CM ...... Charakteristisches Merkmal CPO ...... Code of PLM Openness CPS ...... Cyber Physikalisches System DB ...... Datenbank eBOM ...... Engineering Bill-of-Material, Engineering Bill-of-Material ERP ...... Enterprise Ressource Planning ETL ...... Extract Transform Load, Extract Transform Load GAO ...... Generic Assembly Object IBD ...... Internal Block Diagram InADM...... Invisible and Automated Data Management mBOM ...... Manufacturing Bill-of-Material NEW ...... Non word errors NLP ...... Natural Language Processing NNM ...... Nearest-Neighbour Methode NWE ...... Non Word Error, non word error ODA ...... Open Design Alliance OOTB ...... Out Of The Box PEP ...... Produktentstehungsprozess, Produktentwicklungsprozess POS ...... Part-of-Speech Tagging PRC ...... Product Representation Compact Format PSS ...... Product Service System SHA ...... Secure Hash Algorithm SOA ...... Service Orientierte Architektur SQL ...... Structured Query Language SUS ...... System Usability Scale SVM ...... Support Vektor Machine TF-IDF ...... Term Frequency- Inverse Document Frequency vdH ...... van den Hamer WWW ...... World Wide Web

Zusammenfassung

Aktuelle Produktdatenmanagement Werkzeuge wurden im Kern gegen Ende der 80er Jahre mit der Maßgabe entwickelt, Ingenieure aus Konstruktionsabteilungen bei der Ablage von CAD Daten zu unterstützen. Durch sukzessive Erweiterungen der initialen Werkzeuge entstand eine umfangreiche, mitunter aufwändig zu bedienende Software. Die vorliegende Arbeit zielt darauf ab, den Arbeitsaufwand während der Datenablage bei Ingenieuren zu verringern. Dafür sollen die manuellen Tätigkeiten der Datenverwaltung durch Algorithmen ersetzt werden. Diese Arbeit beschreibt und erprobt ein Konzept für ein im Hintergrund agierendes, algorithmisch gestütztes Produktdatenmanagement Werkzeug.

Das Verständnis von Produktdatenverwaltung folgt den klassisch formulierten Dimensionen Variantenmanagement, Gliederung von Produkten, Bildung von Sichten sowie Verwaltung des Status und der Versionen. Als Ausgangsbasis für das Konzept formuliert diese Arbeit die Bedarfe von Ingenieuren sowie Limitationen und Verbesserungspotentiale an die softwaregestützte Produktdatenverwaltung. Eine Studie mit Anwendern ermittelt ergänzend die Relevanz der Bildung von Sichten sowie praktische Hemmnisse der effizienten Arbeitsweise.

Im weiteren Verlauf der Arbeit wird das Konzept des algorithmisch gestützten, im Hintergrund agierenden Produktdatenmanagement Werkzeugs beschrieben. Für die Interaktion mit Anwendern werden neue Schnittstellen definiert: erstens in den Autoren Werkzeugen für die Datenablage und zweitens in einer Suchumgebung.

Die Ausführung der operativen Verwaltungstätigkeiten innerhalb des automatischen Produktdatenmanagements wird durch fünf Experimente analysiert. Zunächst erfolgt die automatische Zuweisung von Produktdaten zu Varianten und Metadaten zu Gliederungen mithilfe einer textuellen Zuweisung. Die gewonnene Datenbasis wird plausibilisiert, indem sie periodisch ohne Nutzerinteraktion auf Konsistenz mit sich selbst geprüft wird. Diese Konsistenzprüfung erfolgt in zwei weiteren Teilexperimenten auf Basis statistischer Analyse sowie geometrischer Zusammengehörigkeit. Die neue Nutzerinteraktion wir mit einem Assistenten auf Basis natürlicher Sprachverarbeitung erprobt.

Der Einfluss des erarbeiteten Konzepts auf die Arbeitsaufwände von Ingenieuren bei der Dateneingabe wurde in einer Umfrage mit Experten evaluiert. Das Konzept und die damit verbundenen Arbeitsweisen wurden als verständlich und arbeitserleichternd bewertet, positiv wurde der Einfluss auf die Datenqualität bewertet.

Abstract

Towards the end of the 80s, product data management tools were initially developed regarding the aim to provide design and development engineers with support relative to the storage of CAD data. The gradual expansion of the initial tools resulted in an extensive software package that is sometimes difficult to use and is therefore rather considered as cumbersome. The present work aims at a reduction of effort for engineers during the establishment and data storage by providing automatisms that take over the tasks of data management. This thesis describes and samples a concept for an automatic and background processing product data management tool.

The understanding of product data management follows the classical dimensions variant management, product structuring, views, as well as status and versions. As a starting point this work formulates the needs of engineers, limitations and improvement potential for IT- supported product data management. In addition the relevance of views as well as the influence of data management tasks on the workload are determined by a user study.

In the further course of the work the concept of an algorithmic supported and background processing product data management tool is described. The influence on the new job split between user and software as well as methods for product data management is included in the conceptual description. Due to the future background processing tool new user interfaces are required for the data input executed in the authoring tool as well for the data consumption in a search and browse environment. The data input is implemented in an experiment with an natural language processing based assistant.

The execution of the automated data management tasks will be analyzed in five experiments. First of all product data is allocated to variants as well as to meta data to structures by means of text processing. The resulting data base will be checked periodically regarding its self- conformity without user interaction. Two different mechanisms are used: one of them compares the geometrical fit, the other one the statistical plausibility. A new user interface is proposed as chat bot based on natural language processing.

The five practical tests use industrial data or industry related examples and successfully prove technical feasibility. The influence of the developed concept on the effort is evaluated in an experts-survey. The concept and the associated working methods were assessed as under- standable and as work facilitating. The influence on the data quality was rated specifically positive which therefore results in a positive influence on the acceptance of the data- consuming users.

1 Einführung

Die vorliegende Arbeit entstand basierend auf zwei Kerngedanken zur Produktdatenverwaltung. Einerseits bestehen in der Praxis Hemmnisse für eine erfolgreiche und schlanke Nutzung bestehender Produktdatenmanagement (PDM) Werkzeuge, etwa durch umständliche Menüführung oder fehlende Möglichkeiten zur einfachen Datenintegration. Andererseits wurden neuere IT Methoden, wie das Maschinelle Lernen nicht systematisch mit der Produktdatenverwaltung in Beziehung gesetzt. Der Abschnitt 1.1 erläutert beide Aspekte näher. Der Abschnitt 1.2 dieses Kapitels erläutert den inhaltlichen Umfang der Promotionsarbeit. Die Vorgehensweise, der Zusammenhang der Kapitel sowie weitere Randbedingungen sind im Abschnitt 1.3 dargelegt.

1.1 Problemstellung und Motivation

Produktdatenmanagement (PDM) ist aktuell durch manuelle, vermeintlich einfache, administrative Tätigkeiten geprägt. Ein entwickelnder Ingenieur wertet diese Tätigkeiten häufig als zusätzliche und umständliche Aufgabe, die ihm gleichzeitig keinen direkten Gegenwert für seine eigentlichen Aufgaben bieten. Durch eine Verlagerung der Verwaltungstätigkeiten aus den Entwicklungsaufgaben hin zu Verwaltungsabteilungen resultiert ein „Stillepost-Effekt“ (Hellerstein 2008, S. 2). Die Verlagerung geht mit entsprechendem Aufwand sowie manuell verursachten Fehlern und der daraus resultierenden mangelnden Reputation der Werkzeuge einher. (Mesihovic und Malmqvist 2000) beschreiben, dass Ingenieure, die innerhalb eines Unternehmens das größte Fachwissen über ein Produkt besitzen dieses oft nicht selbstständig nutzen, etwa um Konfigurationen anzulegen. Die Autoren begründen dies mit fehlenden und wenig nutzer-freundlichen PDM Werkzeugen. Im Zuge der Beobachtung von Anwendern, die die Daten in PDM Werkzeuge einpflegen und nutzen, sehen beide Parteien Verbesserungsmöglichkeiten. Einerseits hinsichtlich des Aufwands zur Erstellung und Pflege der Daten, andererseits bei der mangelnden Präzision sowie der zeitlichen Verfügbarkeit auf der datenkonsumierenden Seite (Otto und Österle 2016, S. 19–25).

Ist der Aufwand der Bedienung eines PDM Werkzeugs hoch, so sinkt die Akzeptanz der Benutzung des Werkzeugs. Dadurch wiederum arbeiten Nutzer weniger sorgfältig und zeitnah, so dass auch die Qualität der Daten sinkt, was wiederum die Akzeptanz negativ beeinflusst. Es ist folglich anzustreben, dass der Aufwand der Datenverwaltung zu minimieren ist, indem Datenersteller die Werkzeuge direkt bedienen und der Aufwand für die Datenpflege minimiert wird.

1 Einführung

Die Effektivität der Produktdatenverwaltung wird insbesondere innerhalb der bestehenden Systemgrenzen als gegeben angenommen (Sendler 2009, S. 18), eine Effizienzsteigerung wird jedoch als erforderlich angesehen (Shilovitsky 2017b). Effizienz wird im Rahmen der vorliegenden Arbeit mit Aufwand bei der Datenverwaltung, im Sinne einer Wirtschaftlichkeitsbetrachtung, gleichgesetzt. Der Begriff der effizienten Produktdatenverwaltung beschreibt somit eine Entlastung des Ingenieurs durch eine intelligente Automatisierung der Produktdatenverwaltungsaufgaben. Ziel ist es, die Automatisierung der Verwaltungstätigkeiten möglichst autark durch das System zu realisieren. Dabei ist zudem die Fehleranfälligkeit der Automatisierung gegenüber der manuellen Tätigkeit ein Untersuchungsgegenstand, da manuelle Nachbesserungen eventuellen Zeitersparnissen gegenüberzustellen sind.

Für die Automatisierung von Ingenieursaufgaben schlägt (Lutters 2014, 623) vor, Computer für Routineaufgaben zu engagieren, um Menschen für die kreativen Arbeitsaufgaben freizustellen. Darüber hinaus führt er aus, dass Methoden und Werkzeuge stets im Kontext betrachtet werden sollten. Die vorliegende Arbeit zielt darauf ab, diese Annahmen auf den Kontext der konventionellen Produktdatenverwaltung zu übertragen. Neben der Forschung gibt es weitere Möglichkeiten und Ideen, die in dem gegebenen Zusammenhang Optionen offerieren. So beschreibt beispielsweise (Shilovitsky 2017a) einen Sprachroboter, der bei der Suche innerhalb von PDM Werkzeugen verwendet werden könnte.

1.2 Zielstellung und Abgrenzung der Arbeitsinhalte

Der Untersuchungsgegenstand der vorliegenden Forschungsarbeit ist der Aufwand der konventionellen Produktdatenverwaltung, wie sie bei (Gerhard 2016, S. 220) beschrieben ist. Dabei ist die anwendungsorientierte praktische Zielrichtung des Untersuchungsgegenstands offensichtlich die Reduktion des Aufwands. Im folgenden Abschnitt erfolgen eine Eingrenzung des Themas sowie eine Fokussierung der Zielstellung.

Entsprechend des durch (Blessing und Chakrabarti 2009, S. 40) vorgeschlagenen Referenzmodells sind zunächst einflussnehmende Parameter auf den Untersuchungsgegenstand und deren Wirkrichtung aufgetragen (siehe Abbildung 1). Die Pfeilrichtung indiziert die Wirkrichtung, plus und minus quantitative Tendenzen. Weiterhin erfolgt eine Zuordnung der Parameter zur Einflussebene, in der die Parameter eingeordnet sind, die den Untersuchungsgegenstand beeinflussen, allerdings im Rahmen der Arbeit nicht näher betrachtet werden sollen. Parameter, die für den weiteren Verlauf als relevant

1 Einführung angesehen werden, finden sich in der Gestaltungsebene. Die Auswirkungsebene sammelt die beeinflussten Parameter, die ebenfalls nicht näher betrachtet werden.

Zentral in der Graphik finden sich die Parameter Existenz von Funktionen sowie Art und Umfang der Methoden. Steigt die Anzahl der Methoden, so wird auch der Aufwand der Produktdatenverwaltung steigen. Folglich erfordern viele zu beachtende Regeln, die einander gegebenenfalls bedingen, ein ebenso umfängliches Wissen zur Umsetzung durch die Anwender. Gibt es eine bestimmte Funktion in einem Werkzeug nicht, wie etwa zur Bildung von Sichten, so wird dadurch zusätzlicher Aufwand verursacht, beispielsweise indem Nutzer zusätzliche Regeln oder Methoden zum Umgang mit dem Werkzeug definieren. Gibt es sehr viele Funktionen, ist die Vorgehensweise nicht mehr eindeutig. In der Folge suchen Anwender die korrekte Funktion und der erforderliche Aufwand steigt. Diese Wirkrichtung ist in der Abbildung 1 über den bidirektionalen Pfeil zwischen Methoden und Werkzeugen dargestellt. Umgekehrt können bestimmte Anpassungen des Werkzeugs zusätzliche Funktionen realisieren, die in der Regel eine einfachere Bedienung des Werkzeugs bedingen und somit weniger manuellen Aufwand bewirken. Die Wechselwirkung zwischen Methoden der Bedienung und Funktionen eines PDM Werkzeugs auf den Aufwand der Produktdatenverwaltung sind somit zentrale Fragestellungen dieser Arbeit.

Abbildung 1: Abhängigkeiten des Untersuchungsgegenstands, eigene Darstellung

Autoren Werkzeug, wie beispielsweise CAD, CAE oder CAM und Datenverwaltungswerkzeug können mehr oder weniger stark integriert sein. (Eigner und Stelzer 2013, S. 38–42) stellen die Integration als die Möglichkeit dar, die erzeugten Daten in dem Verwaltungswerkzeug entsprechend abzurufen, zu administrieren, zu analysieren und weiterzuleiten. Ist die

1 Einführung

Integration von Autoren Werkzeugen schwach, so bewirkt sie eine Steigerung des Aufwands, um die Daten für deren Verwaltung bereitzustellen. Auch diese Fragestellung soll näher hinsichtlich des Ziels untersucht werden, die Datenverwaltung, ausgehend von der Ingenieursaufgabe im Autoren Werkzeug, effizient zu gestalten.

Offensichtlich ist, je weniger ein Anwender ein (PDM) Werkzeug kennt, desto höher ist der Aufwand, den er für die Bearbeitung benötigt. In der Praxis werden Anwender geschult, um die Kenntnis zu erhöhen, dieses Verhalten wird in der vorliegenden Arbeit nicht thematisiert. Die Nutzerschnittstelle eines Werkzeugs und die Bedienbarkeit der Funktionen links oben in der Abbildung 1 wirken bei abnehmender Qualität dieser mit einem erhöhten manuellen Aufwand, da etwa für einen Anwender die Funktionen verschachtelt sind. Die Bedienbarkeit der Funktionen ist eng verknüpft mit der Gestaltung der Nutzeroberfläche. Insbesondere die Nutzeroberfläche ist nicht im Untersuchungsgegenstand dieser Arbeit verortet, die Wirkweise auf den Menschen und die Interaktion zwischen Mensch und Maschine sind in sich geschlossene weiterführende Fragestellungen. Weiterhin ist anzumerken, dass Hersteller von PDM Werkzeugen diese Fragestellung bereits im „Active Workspace“ der Firma Siemens PLM adressieren. Dennoch wird dieses Thema an Stellen gestreift, bei denen stark verschachtelte Funktionen, wie bei der Bildung von Konfigurationen, einen hohen manuellen Aufwand verursachen.

Die Performanz des Werkzeugs wirkt bei schwächerer Ausprägung auf den zeitlichen Aufwand bei der Produktdatenverwaltung. Insbesondere die Beschaffenheit von netztechnischer Übertragung sowie die ggf. vorhandenen Programmierfehler in einem PDM Werkzeug sind nicht Gegenstand des Gestaltungsumfangs dieser Arbeit.

Wird das zu verwaltende Produkt komplexer, werden ebenfalls die Regeln und Methoden zur Verwaltung umfänglicher. Ebenso können umfängliche normative Vorgaben, die für ein Land eine Region oder bestimmte Produkte gelten, umfassende Methoden bewirken. Produkte werden generell komplexer und die Art der Produktdaten wird diverser (Abramovici 2016). Die Diversifikation der Daten verursacht zudem eine Steigerung von Art und Umfang der Methoden für die Produktdatenverwaltung.

Zusammenfassend untersucht diese Arbeit, auf welche Weise die drei Parameter Funktionen, Integration von Autoren Werkzeugen, sowie Methoden die Produktdatenverwaltung und damit deren Effizienz und Effektivität beeinflussen. Die, für die Arbeit angenommene, Wirkrichtung ist in Abbildung 2 dargestellt. Das praktische Untersuchungsziel der vorliegenden Arbeit ergibt sich in der Art und Weise der Reduktion des Aufwands hinsichtlich der Produktdatenverwaltung auf Seiten des Datenerzeugers. Es wird ein Konzept erstellt, welches eine Automatisierung der Aufgaben der Produktdatenverwaltung herausarbeitet. Daraus

1 Einführung resultierende Änderungen der Methoden der Produktdatenverwaltung sowie Funktionen der PDM Werkzeuge und deren Wechselwirkung werden betrachtet und bedarfsgerecht adaptiert.

Abbildung 2: Untersuchungsgegenstand: Methoden und Funktionen der Datenverwaltung

Die Produktdatenverwaltung lässt sich in zwei Abschnitte unterteilen, erstens die Datenerzeugung und Bereitstellung, zweitens das Konsumieren der Daten. Die vorliegende Arbeit fokussiert sich auf die Verbesserung der datenerzeugenden und aktiv verwaltenden Arbeitsschritte. Somit treten nutzende Prozesse der Datenverwaltung, wie das Digital Mock- Up1 oder die Ersatzteilversorgung lediglich am Rand als Anwendungsfälle auf.

Darüber hinaus ist das Rollen- und Rechtemanagement kein Teil des Gestaltungsrahmens, obschon dieses beispielsweise bei der Bildung von Sichten durch den Zuschnitt auf die Nutzergruppe relevant ist. Es wird angenommen, dass die aktuelle Funktionsweise des Rollen- und Rechtemanagements zielführend ist und somit als Konstante betrachtet wird. Der Fokus der Arbeiten richtet sich auf solche Phasen im Produktentstehungsprozess (PEP), (Feldhusen und Grote 2013), in denen die Daten erzeugt und innerhalb des Unternehmens genutzt werden (siehe Abbildung 3).

Die anvisierten Versuche finden in einer abgeschlossenen Umgebung statt. Die übergreifende Vernetzung von Daten und damit erforderliche Cloudfähigkeit und Datensicherheit sind ein eigenständiges, in dieser Arbeit nicht betrachtetes Thema.

Die Fokussierung auf die Entwicklung bedingt zudem eine Konzentration auf konventionelle Entwicklungsdaten, insbesondere CAD Daten werden in der Arbeit berücksichtigt. Es wird zunächst erarbeitet, welche Informations- und Manipulationsbedarfe für die Produktdaten

1 Digital Mock-Up: DMU: Datenreduzierte visuelle Aufbereitung der geometrischen Produktdaten, etwa zur Durchführung von Design Reviews.

1 Einführung bestehen und durch welche Methoden und Funktionen sie bedient werden. Weiterhin wird betrachtet welche Potentiale zur Optimierung bestehen.

Abbildung 3: Verortung des Fokus der Forschung im PEP

1.3 Charakter der Arbeit und Vorgehensweise

Die vorliegende Arbeit ist grundlagenorientiert und experimentell orientiert. Durch eine Literaturrecherche werden in Kapitel zwei Bedarfe der Ingenieursarbeit im Rahmen der konventionellen Produktdatenverwaltung ermittelt und Potentiale für die Automatisierung von PDM Tätigkeiten herausgearbeitet. Eine Studie der industriellen Praxis verdichtet die theoretischen Überlegungen zusätzlich, indem praktische Limitationen sowie der Nutzen möglicher Potentiale validiert werden. Daraus entsteht im Kapitel vier ein Konzept für eine automatisierte, im Hintergrund verlaufende Datenverwaltung. Dieses Konzept findet eine punktuelle Umsetzung in Kapitel fünf, wobei die Experimente zunächst eine grundlegend mögliche Umsetzung aufzeigen und nicht den Anspruch auf ein durchgängiges System zur Produktdatenverwaltung erheben. Die Evaluation in Kapitel sechs ermittelt die Wirkung der Automatisierung, deren Einfluss auf die methodische Vorgehensweise und erforderliche Erweiterungen für einen potentiellen praktischen Einsatz.

Folgende forschungsleitende Fragen zeichnen den Verlauf der Arbeit:

1. Durch welche Dimensionen und Methoden ist die Produktdatenverwaltung gekennzeichnet? → Kapitel zwei 2. Wie beeinflussen Funktionen der PDM Werkzeuge und Methoden einander und welche Wirkungen haben sie auf den Aufwand der Datenverwaltung? → Kapitel zwei 3. Welche dringlichsten Bedarfe zur Reduktion des Aufwands der Produktdatenverwaltung werden in der industriellen Praxis wahrgenommen? → Kapitel drei 4. Welche konkreten Möglichkeiten für Automatisierung bestehen? → Kapitel vier

1 Einführung

5. Welche Informationen muss ein Ingenieur bewusst setzen? → Kapitel vier 6. Wie kann eine prototypische, technologische Lösung aussehen? → Kapitel fünf 7. Können mit dem Konzept Effizienzen gehoben werden, und wenn ja, welche? → Kapitel sechs und sieben

In der Abbildung 4 sind die Bezüge der Kapitel zueinander visualisiert. In Kapitel zwei sind die Grundlagen in Form von Definitionen, dem Stand der Technik und Forschung beschrieben sowie eine entsprechende Ableitung von Bedarfen, Aufgaben und Potentialen der Automatisierung. Eine Studie beantwortet in Kapitel drei die verbleibenden, offenen Fragen zu den tatsächlichen industriellen Bedarfen. Das vierte Kapitel stellt grundlegende Ideen zur Adaption von PDM Werkzeugen in einem Konzept vor. Eine punktuelle technische Umsetzung und Evaluation werden darauf aufbauend in den Kapiteln fünf und sechs inhaltlich ausgearbeitet. Die abschließende Bewertung in Kapitel sieben bezieht sich auf die herausgearbeiteten Bedarfe der Kapitel zwei und drei sowie die vorgeschlagenen Lösungen des Konzepts.

Abbildung 4: Kapitelstruktur

2 Produktdatenverwaltung

In diesem Kapitel werden Bedarfe und Potentiale der Produktdatenverwaltung mit Blick auf die Effizienz der Verwaltungsaufgabe herausgearbeitet. Initial werden die zu verwaltenden Produktdaten beschrieben und analysiert. Dazu wird im Abschnitt Dimensionen betrachtet, was Produktdatenverwaltung ausmacht, um darauf basierend, jeweils relevante Methoden zusammenzutragen. Der Abschnitt Werkzeuge der Produktdatenverwaltung stellt Funktionen innerhalb der PDM Werkzeuge, ausgehend von der historischen Entwicklung bis hin zum Stand der Forschung, zusammen.

(Stark 2018, S. 17–18) trug Rollen zusammen, die regelmäßig in PDM Werkzeugen arbeiten. Aus dieser Menge werden im Rahmen dieser Arbeit besonders solche betrachtet, die Produktdaten in das PDM Werkzeug bringen und dort die Verwaltung übernehmen. Die Rollen Produktentwickler oder Konstrukteur, Softwareentwickler, Validation Ingenieur, Dokumentenmanager sowie Administrator werden im Laufe der Arbeit referenziert.

2.1 Produktdaten

Dieser Abschnitt beschreibt sowohl die Produktdaten, die das Produkt repräsentieren als auch die darüber hinaus für die Datenverwaltung relevanten Metadaten. Zudem erarbeitet der Abschnitt Potentiale für die Automatisierung, die sich aus der Betrachtung der Daten ergeben.

Ein Produkt wird nach dem ISO Standard (ISO Standard 10303 -214) als ein Gegenstand oder eine Substanz, der oder die durch einen natürlichen oder einen künstlichen Prozess produziert werden kann definiert. In Verbindung mit diesem Produkt werden gemäß der Norm „Produktinformationen in Produktstrukturen“ verwaltet. Aktuellere Definitionen gehen darüber hinaus von Produktservicesystemen (PSS) aus, die den Service integriert konzipieren und in die Strukturen integrieren (Smirnov et al. 2017). Zudem werden Produkte als Cyberphysikalische Systeme (CPS), die sich mit ihrer Umwelt vernetzen, verstanden und entwickelt, sodass weitere Daten abzulegen sind (Abramovici und Aidi 2013, S. 145).

Neben CAD/CAX und CAE Dateien, die konventionell in PDM Werkzeugen verwaltet werden (Gerhard 2016, S. 220) entstehen im Laufe des PEP2 weitere Dokumente. Unter anderem Berechnungen, Anforderungen, Spezifikationen, Systemarchitekturen, Funktionsbeschreibungen, Softwarecode, Stücklisten oder elektronische und elektrische Schaltpläne, Wartungskonzepte und -pläne, Montageanweisungen etc. die in der Regel ein dokumentiertes Ergebnis eines Denk- oder Arbeitsprozesses repräsentieren. Diese, in

2 PEP: Produktentwicklungsprozess, generische, prozessuale Beschreibung anhand derer die Produktentwicklung umfänglich beschrieben wird, etwa mit der VDI 2221.

2 Produktdatenverwaltung

Modellen oder Dokumenten manifestierten, Ergebnisse werden im weiteren Verlauf dieser Arbeit als Design Artefakte3 bezeichnet.

PDM Werkzeuge speichern sowohl Nutzdaten in Form der Design Artefakte als auch Metadaten, die für die Verwaltung erforderlich sind oder für die spätere Verwendung informierend wirken. Eine Definition von Nutz- und Metadaten findet sich bei (Assfalg 2013, S. 160). Der Autor erklärt Metadaten als beschreibende Daten der eigentlichen Daten und zeigt auf, dass die Festlegung, welches Datum das eigentliche und welches das beschreibende ist, an der Perspektive der Betrachtung festgemacht wird. (Dengel 2012, S. 13–15) unterscheidet zudem zwischen extrinsischen und intrinsischen Metadaten. Extrinsische Metadaten sind nach der Definition von Dengel solche, die einem Nutzdatum in der Regel in einer Datenbank zugefügt sind. Für den weiteren Verlauf wird festgelegt, dass Metadaten alle Daten sind, die Design Artefakte beschreiben, komplementieren, klassifizieren, in Beziehung zueinander setzen, sowie deren Verwaltung ermöglichen. Im Rahmen der Produktdatenverwaltung gelten etwa Daten für die Konfiguration als extrinsische Metadaten. Intrinsische Metadaten sind solche, die sich in der Nutzdatei wiederfinden. Dies können beispielsweise bestimmte Kennzahlen und Werte eines Produkts sein. Dengel führt aus, dass diese oftmals in einer Attribut-Wert-Paarung in Datenbanken abgelegt werden. Da viele Attribute der Produkte aus den Autoren Werkzeugen grundsätzlich bekannt sind, ergibt sich das Potential der direkten Übertagung.

Metadaten können einen informierenden Charakter aufweisen. Das bedeutet, dass die Informationen abgelegt werden und wieder zur Anzeige gebracht werden können, um einen Anwender zu informieren (beispielsweise das Gewicht eines Bauteils als Attribut-Wert-Paar). Sie können hingegen ebenso einen steuernden Charakter haben. Dieser Terminus wird im Verlauf der Arbeit stets in dem Fall verwendet, wenn durch das Metadatum eine Wirkung auf weitere Daten vorliegt oder Vorgänge ausgelöst werden, wie das Sperren der weiteren Bearbeitung durch einen Status. Die Abbildung 5 zeigt im oberen Teil die steuernden Metadaten, die häufig zudem extrinsisch im PDM ergänzt werden. Die Verwendungsnachweise sind durch einen steuernden Charakter geprägt. In der Regel werden sie manuell gesetzt, im Zusammenhang mit Workflows mitunter automatisch. Sie werden in beiden Fällen auf Indikation eines Entwicklungs- oder Validierungsingenieurs erzeugt. Ein Potential für eine Unterstützung kann für die nicht automatisierten Fälle in einem Vorschlagswesen erfolgen.

Die Begriffe Relationen oder Verlinkungen werden synonym verwendet und bezeichnen im Rahmen dieser Arbeit die physikalische Verbindung von Datenbankobjekten. Relationen sind

3 Design: aus dem Englischen für Konstruieren, entwerfen, entwickeln; Artefakt: durch einen Menschen erstelltes Objekt, Gerät oder Ding (Duden).

2 Produktdatenverwaltung relevante Informationen für die Traversierung der Produktdaten und wirken damit über die hierarchischen Gliederungen indirekt steuernd. Gleichzeitig dienen sie der Veranschaulichung der „gehört-zu“ Information zwischen zwei Design Artefakten, die für Anwender der PDM Werkzeuge einen informierenden Charakter aufweist. Weiterhin werden Design Artefakte unter anderem entsprechend den Korrespondenzregeln der ISO 42010 (Emery und Hilliard 2009) transversal miteinander verlinkt. Auch in diesem Fall besteht häufig ein informierender Charakter für den Anwender. Relationen werden, mit Ausnahme von Kopiervorgängen und der automatischen Übergabe aus Autoren Werkzeugen, manuell erzeugt und verbleiben variabel über den gesamten Lebenszyklus des Design Artefakts. Das automatische Erzeugen der Relationen zwischen den Design Artefakten stellt ein Potential für eine Automatisierung dar. Darüber hinaus ist generell zu prüfen, ob die Traversierung von Produktstrukturen durch einen schlankeren Mechanismus ersetzt werden kann.

Abbildung 5: Übersicht unterschiedlicher Metadaten

Die verwaltungsrelevanten Attribute eines Design Artefakts im unteren Teil der Abbildung 5 werden bis auf wenige Ausnahmen von Nutzern manuell während der Entstehungsphase des Objekts angelegt und manipuliert. Eine Übersicht relevanter Attribute, die den Objekten zugeordnet sind, findet sich in Tabelle 1. Diese Übersicht wurde zusammengestellt auf Basis von eigenen Erfahrung und Beratungsprojekten in der Industrie und stellt eine vereinfachte Übersicht gegenüber der industriellen Praxis dar.

Die Attribute Ersteller und Datum (siehe Nr. 1 und 2 in Tabelle 1) werden bei der Anlage eines Objektes im PDM System automatisch angelegt und beziehen sich auf das PDM Objekt. Diese Angaben weisen einen informierenden Charakter auf, sodass ein Potential für den Wegfall dieser Information gegeben ist. Die Information zum Ersteller des zugehörigen Design

2 Produktdatenverwaltung

Artefakts wird nicht mit in das PDM Werkzeug übertragen, ein automatischer Übertrag erscheint hilfreich, um für etwaige inhaltliche Fragen einen Ansprechpartner zu haben.

Tabelle 1: Übersicht typischer Attribute

manuell/ Nr. Bezeichnung Kommentar steuernd automatisch 1 Ersteller automatisch nein

2 Datum automatisch nein oft sprechend, 3 Nummer manuell ggf. ja unternehmensindividuell 4 Bezeichnung manuell ggf. auch mehrsprachig nein 5 Verantwortlicher manuell nein Vorgänger- über die Nummer, über 6 Nachfolger manuell nein Verlinkung Beziehung 7 Projekt Bezug manuell ggf. ja Gewichts- und 8 manuell Übertrag aus anderen Quellen ggf. ja Materialangaben Ausweispflicht erfordert semantische 9 gegenüber Behörden manuell ja Beurteilung (Zoll, Zulassung)

Nummernsysteme (siehe Nr. 3 in Tabelle 1) sind in Unternehmen häufig mit vielen Bedeutungen belegt (Eigner und Stelzer 2013, S. 66) und werden aktuell manuell gepflegt. Die Nummern werden oftmals steuernd verwendet, beispielsweise um die Zugehörigkeit zu einem bestimmten System oder um einen damit verbundenen Installationsschritt anzuzeigen. Diese „gehört-zu“ Information, könnte allerdings ebenso mit anderen IT-Mitteln, wie beispielweise den Relationen, erbracht werden. Somit ergibt sich ein Potential, die manuell gepflegte Nummer durch eine automatisch erstellte zu ersetzen und weiter ergibt sich das Potential für eine Verschlankung der Informationsablage (Gerhard 2016, S. 224).

Die Bezeichnung (siehe Nr. 4 in Tabelle 1) wird in der Regel manuell gesetzt und weist ebenso unter der Voraussetzung, dass einige unternehmensspezifische Regeln für die Benennung beachtet werden, ein Potential für eine Automatisierung durch Übernahme aus den Autoren Werkzeugen auf.

Ein Verantwortlicher (siehe Nr. 5 in Tabelle 1) wird manuell benannt und wird bei Problemen mit dem Bauteil oder Objekt herangezogen. Es besteht in der Praxis ein Unterschied zwischen demjenigen, der ein Design Artefakt an das Werkzeug übergibt und demjenigen, der es erstellt hat. Aufgrund dieser Umgehungslösung hat sich die Notwendigkeit ergeben, zusätzlich beide Attribute (siehe Nr. 1 und 5 in Tabelle 1) zu verwalten. Dadurch, dass die Bedienung des PDM

2 Produktdatenverwaltung

Werkzeugs vereinfacht wird, ergibt sich das Potential, in die ursprüngliche Lösung zurückzukehren.

Vorgänger/Nachfolger Beziehungen (siehe Nr. 6 in Tabelle 1) werden an dieser Stelle stellvertretend, für derartige Attribute, die durch Verlinkungen (beispielsweise transversale Beziehung zwischen Objekten) dargestellt werden können, benannt. Ebenso kann der Projekt Bezug (siehe Nr. 7 in Tabelle 1) entfallen, denn der mitunter steuernde Charakter kann zudem über den Verwendungsnachweis, demnach die Konfigurationsangabe, gesteuert werden.

Für das Gewichtsmanagement (siehe Nr. 8 in Tabelle 1) gilt ebenso, dass die Informationen, über die Grenzen der konventionellen PDM Werkzeuge hinaus, nicht ausreichend verknüpft sind. Da die Vorgaben und errechneten sowie tatsächlich gewogenen Daten in weiteren Modellen oder Dokumenten gespeichert werden. An diesem Punkt besteht folglich ebenso Potential für eine automatische Zuweisung und Verknüpfung. Damit entfällt der Bedarf der manuellen Pflege.

Die Informationen zur Ausweispflicht gegenüber Behörden (siehe Nr. 9 in Tabelle 1), wie etwa der Zulassung oder des Zolls, steht diesbezüglich stellvertretend für solcherlei Attribute, die einen direkt steuernden Charakter aufweisen. Die manuelle Befüllung erfolgt erst nach der Fertigstellung der Nutzdaten sowie einer Interpretation von normativen Vorgaben durch Experten und resultiert in einer Klassifikation der Objekte. Eine Automatisierung dieser Information, insbesondere hinsichtlich der ggf. unterschiedlichen Beurteilung der Objekte im Kontext (siehe Tabelle 2), bleibt zu prüfen. Ein Potential ergibt sich in der automatischen Klassifikation, Ablage und Bereitstellung.

Mitunter doppeln sich in der Praxis Attribute im PDM Werkzeug mit den Angaben in Autoren Werkzeugen sowie weiteren Datenbanken im Unternehmen. Dies geschieht häufig aus dem Grund, dass ein Zugriff auf die Informationen gelingt, ohne dass ein Anwender in ein anderes Werkzeug wechseln muss. Dieses Vorgehen wird an dieser Stelle vernachlässigt, denn ein einfaches Kopieren oder Referenzieren bietet in der Praxis eine Unterstützung.

PDM Systeme bieten mehr oder weniger umfängliche und unterschiedliche Objekttypen an, die jeweils mitabgestimmten Attributen ausgestattet sind. Alle PDM Hersteller bieten zudem an, zusätzliche Attribute an Objekten in einer Administrationsumgebung zu ergänzen. Auf diese Weise entstehen in der Praxis mitunter umfängliche Attribut-Listen. Im Rahmen dieser Arbeit werden die betrachtet, die für die Produktentwicklung relevant sind.

Attribute bieten das Potential durch die Vernetzung zwischen Autorenwerkzeug und Verwaltungswerkzeug entweder automatisch befüllt zu werden oder komplett zu entfallen (siehe Tabelle 2). Insbesondere derartige Metadaten, die eine Kenntnis des Produkts und weitere Vorgaben und Regeln erfordern, sind ggf. lediglich mit erhöhtem Aufwand zu

2 Produktdatenverwaltung automatisieren. Die unterschiedlichen Möglichkeiten der Automatisierung reichen von einfachen Copy-Paste Vorgängen, wie für gleich bezeichnete Attributfelder, bis zu komplexen Suchvorgängen, für den Fall des kompletten Entfalls von Metadaten.

Tabelle 2: Automatisierungspotentiale von Metadaten

Nr. Potential Erläuterung

Nummern von Design Artefakten Benötigt gleichzeitig einen Ersatz für 1 automatisch vergeben verklausulierte Steuerungen oder Filterungen Benennung von Design Artefakten Ggf. sind zusätzlich unternehmensinterne 2 aus den Autoren Werkzeugen Regularien zu betrachten automatisch übernehmen Werkzeuge verfügen über eine Intelligenz, Befüllung der Attribute aus den 3 welche die Informationen aus den Design Nutzdaten Artefakten herausliest Automatische Klassifikation von Automatisierte Ablage inklusive der 4 Design Artefakten zur Steuerung der Verlinkung, so dass die Steuerung weiterhin weiteren Verwendung möglich ist Verwaltung der Design Artefakte ohne Verschlankung der 5 Attribute und durch Anwender manipulierbare Informationsablage Metadaten

2.2 Dimensionen

Unter Produktdatenverwaltung wird die Tätigkeit verstanden, Daten des Engineerings aufzunehmen, zentral abzulegen, miteinander in Beziehung zu setzen, zu analysieren, zu kennzeichnen und zur Verfügung zu stellen. Dieser Abschnitt trägt maßgebliche Ingenieursaufgaben und Bedarfe für die Produktdatenverwaltung zusammen.

(van den Hamer und Lepoeter 1996) beschreiben in ihrem Artikel fünf Dimensionen der Produktdatenverwaltung als erklärendes Modell. Dazu zählen sie die Versionierung als die Weiterentwicklung des Designs in Schritten, den Status als Angabe zur Qualität, Funktionalität, Sicherheit und Zuverlässigkeit eines Produkts, Hierarchie als den Aufbruch von Produkten in kleinere, überschaubare Teilmengen, Sichten als eine zeitlich manifestierte Beschreibung des Produkts entlang eines Prozesses und Varianten als die unterschiedlichen Ausprägungen eines Produkts. Im Folgenden werden die einzelnen Begriffe diskutiert und mit weiteren Quellen in Verbindung gebracht.

Versionierung wird durch die Autoren als transparente Verfolgung der Weiterentwicklung von Bauteilen beschrieben. Ein Bedarf von Ingenieuren ist, eigenständig vor- und rückspringen zu können zwischen den Design-Lösungen. Der sich daraus ergebende Bedarf ist, dass der Charakter der Modifikation bei der Erstellung dieser festgehalten werden muss. Van den Hamer beschreibt weiterhin, dass die Versionierung für alle Engineering Domains in der Form

2 Produktdatenverwaltung relevant ist. Im maschinenbaulichen Kontext ist es üblich, funktionsfähige Revisionen eines Design Artefakts zu veröffentlichen (siehe die dunkelgrauen Blöcke in Abbildung 6). Zusätzlich werden weitere unveröffentlichte Zwischenschritte als Versionen abgelegt 4 . Diese Arbeit verwendet den Begriff der Version oder der Versionierung für den dokumentierten, veröffentlichten Zwischenstand eines Design Artefakts.

Abbildung 6: Zusammenhang von Version und Revision für mechanische Bauteile

In PDM Werkzeugen hat sich über der Zeit ein Master- Version- Schema, entsprechend der Abbildung 6, zu einem quasi Standard etabliert.

Van den Hamer beschreibt die Aufprägung eines Status auf eine Design Information als eine formale Bestätigung einer Organisation, dass diese Design Information bestimmten Anforderungen gerecht wird. Die Abbildung 7 zeigt schematisch Design Informationen als einzelne Objekte oder zusammengehörende Gruppe, die jeweils zu einem Zeitpunkt gelten. Die Autoren van den Hamer et. al. führen weiter aus, dass die aufgeprägte Statusinformation benutzt wird, um die weitere Verwendung des Designs zu steuern. Der eigentliche Bedarf ist folglich, die Verwendungsmöglichkeiten des Designs aufzuprägen und Organisationsmitgliedern anzuzeigen (siehe „ready“ in Abbildung 7).

Van den Hamer legt nicht fest, ob das Aufprägen einen Status auf ein einzelnes Objekt oder mehrere Objekte gemeinschaftlich zutrifft. In der Praxis hat sich das markieren einzelner Objekte mit einem dedizierten Status etabliert. Der (MIL-HDBK 61, 8-1) führt die Verwaltungsaktivität „Configuration Status Accounting“, also das Ausleiten und Einfrieren von gewissen Produktumfängen, an. Zusätzlich führt das Dokument die Tätigkeit des „Configuration Validation and Verifikation“ an, bei der gewisse Produktumfänge gegen eine

4 Im Software-Kontext werden partielle Zwischenlösungen ohne Stufen unter dem Begriff der Version abgelegt.

2 Produktdatenverwaltung intendierte Nutzung geprüft werden. Der tatsächliche Bedarf ist folgend das Aufprägen der Verwendungsmöglichkeit sowohl auf einzelne Objekte als auch auf größere Produktumfänge anzuwenden und weiterhin der Bedarf diese Statusanzeige im Kontext anzuzeigen und zu analysieren.

Abbildung 7: Aufprägen des Status auf Objekte und Produktumfänge

Während van den Hamer die Bildung von Hierarchien als Produktdatenverwaltungstätigkeit beschreibt, geht aktuellere Literatur in der Regel von Strukturen aus. So beschreibt beispielsweise (Gerhard 2016, S. 228–229) den Zusammenhang für mechanische Produkte von Baugruppen, Unterbaugruppen und Teilen aus CAD Werkzeugen als Aufbau der Struktur im PDM Werkzeug. Diese Logik findet sich in dem Namen der gängigen Darstellungsform „gozintograph“ wieder (Gerhard 2016, S. 229). (Zagel 2006, S. 41–42) beschreibt Produktstrukturen als n-dimensionales Gebilde, welche zusätzlich unterschiedlich ausgeprägte Strukturen transversal, also nicht hierarchisch, miteinander verbinden. Zusätzlich wurde demnach der Bedarf der Ablage von Zusammenhängen in der Struktur verankert (Eigner und Stelzer 2013, S. 83).

(Glauche 2015, S. 76) beschreibt Produktstrukturen als dreigeteilt, (siehe Abbildung 8). Strukturen bestehen demnach aus einer Ebene der dokumentierten Arbeitsergebnisse (Design Artefakten), einer Konfigurationsebene, repräsentiert durch ein Metaobjekt in der PDM Welt, sowie einem zusätzlichen Gliederungsobjekt innerhalb des PDM Werkzeugs. Die Gliederungsebene übernimmt die Aufgabe den generischen (oder „logischen“) Aufbau eines Produkts wiederzugeben. Sie entspricht damit dem Bedarf, eine ordnende Struktur für Beteiligte der Produktentstehung vorzugeben, wie er ebenfalls in den Hierarchien bei beschrieben ist, siehe (van den Hamer und Lepoeter 1996).

2 Produktdatenverwaltung

Der Aufbau hierarchischer Produktgliederungen ist in (DIN EN 62023:2012-08) oder dem NIST Core Product Model (Elgh und Cederfeldt 2010) in Form von Datenmodellen und relevanten Informationszusammenhängen definiert.

Abbildung 8: Generischer Aufbau der Produktgliederung nach Glauche

In der Konfigurationsebene werden nach Glauche steuernde Informationen, wie die der Variantenbildung, der Versionierung oder der zeitlichen Gültigkeit abgelegt. Die Struktur nach Glauche ist aufgrund der vielfachen Verlinkung zwischen Design Artefakten und den Elementen der Gliederungsebene ein mehrdimensionales Gebilde. Erst durch eine nachgelagerte Traversierung der Produktstruktur entsteht folglich eine 2-dimensionale Stückliste, die exportiert und beispielsweise zum Kosten- oder Gewichtsmanagement verwendet wird. Die Gliederungsebene hat keine direkte Auswirkung auf nachgelagerte Arbeiten, sondern übernimmt die, im Abschnitt Dimensionen beschriebene, informierende Randbedingung während der frühen Phase der Produktentstehung.

Gliederungen eines Produkts können Systemarchitekturen beschreiben, kombinierbare Module oder auch prozessuale oder organisatorische Aspekte, wie die inhaltliche Verantwortlichkeit für gewisse Umfänge, anzeigen. Häufig werden diese unterschiedlichen Bedarfe in einer Produktstruktur kombiniert realisiert, sodass einzelnen Bedarfen nicht vollumfänglich Rechnung getragen wird.

Als weitere Dimension führen (van den Hamer und Lepoeter 1996) Varianten ein, die sie als Variation eines Produkts beschreiben. Nach DIN 199 sind Varianten „Gegenstände ähnlicher Form und/oder Funktion mit in der Regel hohem Anteil identischer Gruppen oder Teile“ (DIN199). Varianten sind am Produkt wahrnehmbar als äußere Varianz oder nicht wahrnehmbar als innere Varianz beschrieben (Thiebes und Plankert 2014, S. 167). Als Bedarf arbeiten van den Hamer et.al. heraus, dass Gemeinsamkeiten und Unterschiede zwischen

2 Produktdatenverwaltung den einzelnen Produktvarianten ausgewiesen werden sollen. Varianten stellen grundsätzlich einen zentralen Anwendungsgrund für PDM Systeme dar und werden als Filtermöglichkeit der Gesamtproduktmenge benötigt. Der MIL-Std (MIL-HDBK 61, 9-5) spricht nicht von Produktvarianten, sondern von Konfigurationen. Die Zusammenstellung oder Konfiguration eines Produktes beispielsweise durch den Kunden oder den Vertrieb sind weniger im Fokus. Der Standard Mil-Std führt aus, dass das „Konfiguration Status Accounting“ eine aktuelle Produktdefinition analysiert und etwaige erforderliche Verbesserungen einleitet. Dabei werden Konfigurationsinformationen sehr präzise aufgewiesen, da sie einen steuernden Charakter etwa in Richtung der Produktionsplanung und -steuerung haben.

Die Sichten entstehen bei van den Hamer entlang des Produktentwicklungsprozesses aufgrund der unterschiedlichen Informationsdarstellung des gleichen Produkts an unterschiedlichen Zeitpunkten. Die Autoren gehen davon aus, dass die Designinformation aus Zeitpunkt A in eine konkrete Darstellung des gleichen Designs zu einem Zeitpunkt B gewandelt wird. Die Autoren verbleiben darüber unklar, ob die gleichen oder andere Nutzer involviert sind. (Zagel 2006, S. 38) beschreibt Sichten in Zusammenhang mit den Produktlebenszyklusphasen Entwicklung, Produktion und Maintenance. Offen bleibt in seiner Betrachtung, ob tatsächlich unterschiedliche Artefakte miteinander in Beziehung gesetzt werden, so wie es (van den Hamer und Lepoeter 1996) beschreiben oder dieselben Dateien in einer variierten Ordnung und variiertem Detailgrad präsentiert werden. (Eigner und Stelzer 2013, S. 28) motivieren Sichten explizit mit den unterschiedlichen Anforderungen bestimmter Anwendergruppen und begründen somit, dass Produktstrukturen sowohl einen dedizierten Aufbau als auch ausgewählte Design Artefakte heranziehen. Ebenso argumentiert (Kehl 2019, S. 93) mit explizit hierarchischen Strukturen, die entsprechend der Nutzerbedarfe unterschiedlich angeordnet werden. (Emery und Hilliard 2009, S. 37) Sichten als Ausschnitt eines Ganzen, um bestimmte Informationen gezielter für ausgewählte Anwendergruppen darstellen zu können. Übereinstimmend beschreiben die obenstehenden Quellen, dass sich Sichten auf Design Artefakte und die darin enthaltenen Informationen beziehen und der Erfüllung der Ingenieursaufgabe dienlich sein sollen.

Im weiteren Verlauf wird angenommen, dass Sichten gebildet werden aufgrund von Anforderungen zum Informationsbedarf und zur -aufbereitung für bestimmte Nutzergruppen, der durch den zugrundeliegenden Entwicklungsprozess zeitlich bestimmt und in den Design Artefakten manifestiert ist. Die Abbildung 9 gibt eine Übersicht zum Verständnis von Sichten im Rahmen dieser Arbeit.

2 Produktdatenverwaltung

Abbildung 9: Schematische Darstellung zur Bildung von Sichten

Van den Hamer führt aus, dass transversale und hierarchische Beziehungen zwischen unterschiedlichen Artefakten existieren. Er geht jedoch nicht davon aus, dass die Verlinkung auch „physisch“ existieren und für die Bildung von Sichten verwendet werden kann. Aktuellere Konzepte, wie das PLM oder MBSE, gehen davon aus, dass diese transversalen Bezüge, beispielsweise Anforderung-Bauteil-Test oder Bauteil-Montageanweisung-Wartungs- handbuch, etabliert werden. Sichten sind dadurch gekennzeichnet, dass sie einen informierenden Charakter haben.

In den Bereich der Produktdatenverwaltung fällt zusätzlich zu den von van den Hamer benannten Dimensionen, der in dem (MIL-HDBK 61, 9-2) und in dem Standard SAE ANSI/EI649C (Standard SAE ANSI/EIA649C) erklärte Sachverhalt der Identifikation, der zunächst durch die Benennung und Benummerung der Objekte, die unter Datenverwaltung stehen, realisiert wird. Der dahinterliegende Bedarf ist allerdings das Identifizieren von Daten, Objekten oder Artefakten, die unter Konfigurationskontrolle stehen und die Festlegung, auf welche Daten, Objekte oder Artefakte das nicht zutrifft. Insbesondere die Benummerung der Objekte wird gemäß (Eigner und Stelzer 2013, S. 72) zusätzlich zur Klassifikation und Gliederung der Produktdaten verwendet und macht diese damit auf einfache Art filterbar.

Suchen wird im Zusammenhang dieser Arbeit, wie auch bei den zuvor zitierten Quellen, nicht als Verwaltungsdimension von Produktdaten eingeordnet. Bei der Suche werden Produktdaten nicht aktiv in eine Ordnung oder Beziehung zueinander gebracht, sondern lediglich die, zur Verfügung stehenden, Informationen verwendet. Da hingegen Teilmengen oder einzelne Objekte dem Anwender schnell angezeigt werden sollen und Produktverwaltung kein Selbstzweck ist, sondern für die Dokumentation und Versorgung des Engineerings selbst

2 Produktdatenverwaltung und nachfolgender Personengruppen relevant ist, gilt es, den Suchprozess in der Lösung zu beachten. Die diskutierten Bedarfe der Ingenieursarbeit an die Produktdatenverwaltung sowie die intrinsischen Bedarfe der Produktdatenverwaltung werden in Tabelle 3 zusammengefasst.

Tabelle 3: Ingenieursbedarfe an die Produktdatenverwaltung

steuernd/ Nr. Bedarf Referenz informativ

Dokumentation und Versorgung des Engineerings und 1 i vdH nachfolgender Prozessteilnehmer mit Produktdaten

Identifizieren von Daten, Objekten oder Artefakten, die (MIL-HDBK 2 s unter Konfigurationskontrolle stehen 61, 9-2)

3 Strukturierung des Produkts in Teilumfänge i vdH/ Hierarchien Gemeinschaftliches Nutzen von Teilumfängen als 4 Unterstützung während der Konstruktion & i vdH/ Entwicklung Hierarchien

Etablieren und Ausweisen von Zusammenhängen vdH/ 5 i einzelner Design Artefakte zueinander Hierarchien & Sichten Präzises Festhalten und Ausweisen von 6 s vdH/ Produktvarianten Varianten Anzeigen von Unterschieden zwischen den 7 i vdH/ Produktvarianten Varianten Verwendungsmöglichkeit von Design Artefakten (MIL-HDBK 8 s ausweisen 61, 9-5) vdH

Verwendungsmöglichkeit von (Teil) Produktumfängen (MIL-HDBK 9 s ausweisen 61, 9-5) vdH

(MIL-HDBK 10 Verwendungsmöglichkeit im Kontext analysieren s 61, 7-1)

Zusammenhang der Weiterentwicklung von Teilen 11 i vdH/Versionen festhalten und anzeigen Eigenständiges vor- und rückspringen zwischen 12 i vdH/Versionen unterschiedlichen Design Ständen

13 (Teil) Produktumfänge nutzerzentriert repräsentieren i vdH/Sichten

(Teil) Produktumfänge ausleiten und in Beziehung (MIL-HDBK 14 s zueinander setzen 61, 8-1)

14 Teile und Umfänge einfach anzeigen I

15 Design Artefakte in Beziehung zueinander setzen i vdH/Sichten

2 Produktdatenverwaltung

Eine wesentliche Feststellung von van den Hamer et. al. ist, dass die Dimensionen nicht unabhängig voneinander sind und es deshalb nicht offensichtlich ist, welche Dimension zur Datenverwaltung zu verwenden ist. Dies verdeutlicht sich am Beispiel der Traversierung einer Struktur. Eine Konfiguration muss aufgrund der Funktionsweise aktueller PDM Werkzeuge in der Hierarchie verankert werden; für die Bildung einer Variante ist technischer Sicht des Produktes keine Gliederung erforderlich. Ein anderes Beispiel ist die Bildung von Sichten, die über Zugriffskontrolle, hierarchische oder transversale Verknüpfungen oder auch den Status im PDM Werkzeug erzeugt werden kann.

2.3 Methoden

Der folgende Abschnitt stellt die Unterstützung der Methoden für die Produktdatenverwaltung zusammen, analysiert die damit verbundenen Aufgaben im Zusammenspiel zwischen Mensch und Werkzeug und bewertet abschließend die Methoden hinsichtlich Effektivität und Effizienz. Im Vordergrund stehen die, im Abschnitt 2.2 als relevant erarbeiteten, Dimensionen Gliederungen, Sichten und Varianten. Die Dimensionen Status und Versionierung finden aufgrund der verhältnismäßig einfachen Lösung mit Bezug zu lediglich einem Bauteil und dem, die Gesamtheit der PDM Werkzeuge umfassenden quasi standardisierten, Vorgehen an dieser Stelle keine weitere Beachtung.

(Lutters 2014, 612) definiert Methoden im Kontext der virtuellen Produktentstehung als Vorgehen, das angewandt wird, um ein bestimmtes Ergebnis zu erzielen. Dazu sind spezielles Wissen zur Arbeitsreihenfolge sowie Fertigkeiten zur Nutzung eines bestimmten Werkzeugs erforderlich. Methoden und deren Beschreibungen sind unabhängig von konkreten Personen. Erst die tatsächliche Ausführung der Methode ist abhängig von der Person.

An dieser Stelle erfolgt zusätzlich eine Abgrenzung zu dem Begriff Prozess, der als formale Beschreibung eines Arbeitsablaufs und der dazu erforderlichen sequenziellen oder parallelen Aktivitäten verstanden wird und festlegt, wer die Akteure sind. Relevante Prozesse der Produktdatenverwaltung sind, neben dem übergeordneten Produktentstehungsprozess, beispielsweise die darin verankerten Änderungs- oder Freigabeprozesse (SASIG/ Pro Step 2009; MIL-HDBK 61). Prozesse werden im Rahmen dieser Dissertation als nicht veränderliche Konstante betrachtet, da die konkrete, detaillierte Arbeit des Ingenieurs mit dem PDM Werkzeug zu gestalten ist.

Darüber hinaus geben Unternehmen eine Arbeitsweise vor und adaptieren das PDM Werkzeug in zwei Ausprägungsstufen. Einerseits durch Einstellungen, die in einer Administrations Umgebung des Werkzeugs möglich sind und weiterhin durch Adaption der

2 Produktdatenverwaltung

Softwareprogrammierung - folglich der Funktionsweise des Werkzeugs. Dieser Abschnitt geht zunächst von invarianten Werkzeugfunktionen aus.

2.3.1 Gliederungen

Die Erstellung von Gliederungen kann auf zwei grundsätzlichen Wegen erfolgen. Einerseits kann initial eine „leere“ Gliederung aus PDM Objekten erarbeitet werden, welche die Möglichkeit der ordnungsgebenden Eigenschaften, unterstützend für den weiteren Produktentwicklungszyklus, bereitstellt. Dieses Vorgehen unterstützt die einfache Beurteilung des Arbeitsfortschritts während der sukzessiven Befüllung mit Design Artefakten. Andererseits kann eine bestehende Struktur kopiert und modifiziert werden, was implizites Wissen zur Produktarchitektur, Aufteilung der Systeme oder Module kopiert sowie das Übernehmen von „Carry-Over5“ Teilen unterstützt. Dieses Vorgehen findet in der Regel dann Anwendung, wenn das neue Produkt wesentlich auf einem bestehenden aufbaut. (Glauche 2015, S. 44–59)

Relevante Forschung zum Thema Produktgliederung findet vornehmlich um die Jahre 2000 bis 2010 statt; häufig mit der Zielstellung, komplexer werdende Produkte effektiv zu verwalten. Die Tabelle 4 stellt die unterschiedlichen Merkmale zusammen und vergleicht diese.

(Blees 2011, S. 88–92) erarbeitet eine 8-schrittige Methode zur Gliederung des Produkts in Module. Es findet sich kein Verweis auf die Bildung einer hierarchischen Gliederung. Vielmehr wird das Produkt in Module gegliedert und die Module wiederum in Komponenten. Die Module sind dabei konfigurierbare Objekte. Die Module von Blees sind derart aufgebaut, dass sie in ihrem Umfang unabhängig voneinander sind. Dies beschreibt er in einer Formel, die die Schnittstellen in Beziehung zueinander setzt.

Ebenso beschreibt (Zagel 2006, S. 42) die Bildung von Modulen in seiner Methode mit dem Ziel, die Varianz der Produkte in der Produktstruktur abzubilden. Die Module von Zagel können in sich wiederum variabel gestaltet sein, es ergibt sich somit eine „Modulhierarchie“, welche insbesondere für sehr variantenreiche Produkte mit gleichermaßen hohen Stückzahlen konzeptioniert wurde. Zagel stellt zusätzlich ein Datenmodell vor, das er in die STEP Protokolle integriert und evaluiert seine Methode durch die Umsetzung in einem PDM Werkzeug.

(Glauche 2015, S. 193 ff) kombiniert in seiner Methode zur Produktstrukturierung die funktionale Gliederung mit Modulen der Instandhaltung und Wartung des Produkts. Dabei werden die Anforderungen der Modularisierung und der Instandhaltung in der Konfigurationsebene berücksichtigt (siehe Abbildung 8 oben). Bemerkenswert ist, dass die Umsetzung einer funktionalen Gliederung ohne eine Konfiguration auskommt. Glauche geht folglich davon aus, dass für ein Produkt mit variablen Modulen genau eine funktionale

5 Bereits in einem vorangegangenen Produkt konstruierte und verwendete Komponenten.

2 Produktdatenverwaltung

Gliederung ausreichend ist, um den Entwicklungsprozess zu unterstützen. Darüber hinaus empfiehlt Glauche eine möglichst große Entkopplung der unterschiedlichen Anforderungen an Produktstrukturierungen, so trennt er „gehört-zu“ Informationen der Wartung von denen der Produktion.

Tabelle 4: Gegenüberstellung von Merkmalen der Gliederung

Merkmal

ung

bild

PDM PDM

ierarchischer ierarchischer ervicerelevante

Autor ertigungsrelevante

Bildung von Bildung Ordnungskriterien h Aufbau der Entkopplung Bedarfe Zusammenhang mit Datenmodell Zusammenhang mit Varianten f Aspekte s Aspekte

Blees ja bedingt nein nein ja nein nein Glauche ja ja ja bedingt ja ja ja Zagel ja ja nein ja ja ja nein Brière-Coté ja bedingt ja ja ja bedingt nein Stone ja nein ja nein nein nein nein Weber nein nein ja bedingt nein nein nein Vielhaber nein nein ja ja ja bedingt bedingt

(Brière-Côté 2010) beschreibt, ähnlich wie Zagel, eine Methode, mit der eine Produktstruktur die Varianz eines Produktes im PDM Werkzeug abbildet. Module werden bei Brière-Coté mit sich wiederholenden Produktumfängen gleichgesetzt. Die Autoren vertreten die Meinung, möglichst viele unterschiedliche Anforderungen in einer generischen Produktstruktur zu vereinen.

(Stone et al. 2000, S. 7) stellen eine methodische Vorgehensweise vor, mit der Module heuristisch gebildet werden. Die Methode unterstützt den Entwickler darin, entsprechend dem Ansatz von van den Hamer, einen Überblick über das Produkt zu gewinnen. Dabei vernachlässigen die Autoren die Aspekte der Konfiguration, der Baubarkeit sowie den Zusammenhang zu den Werkzeugen.

(Weber et al. 2003, S. 453) stellen in ihrem Beitrag ein Konzept für Gliederungen vor, das die Merkmale eines Produktes, wie beispielsweise Form, Struktur und Material sowie dessen externes Verhalten, wie beispielsweise Gewicht, Baubarkeit oder Ästhetik als explizit getrennte PDM Objekte verwaltet. Die Trennung zwischen Produkt und Eigenschaft wird vorgeschlagen, um Design Analyse und Synthese expliziter darzustellen und zu unterstützen. Darüber hinaus wird durch die Autoren eine computergestützte Etablierung der Beziehungen zwischen den Datenbankobjekten mittels semantischer Netze oder agentenbasierter Systeme als

2 Produktdatenverwaltung

Möglichkeit angeboten, jedoch nicht umgesetzt. Weiterhin stellen die Autoren in Frage, ob die Merkmale hierarchisch in Beziehung stehen müssen. Ordnungsrelevante Gliederungsknoten führen sie in ihrer Methode nicht ein. Die Ideen von Weber werden bei (Vielhaber et al. 2004) aufgegriffen und um die Verwaltung der Verbauungsinformation erweitert. Dafür definieren die Autoren ein „Generic Assembly Object“ (GAO), das die Verbindungsart, wie das Schweißen und Kleben etc., zweier Bauteile sowie die geometrische Position und Bedingungen wie Toleranzen beinhaltet. Dieses entspricht in etwa dem heutigen PMI6. Weiterhin führen die Autoren aus, dass keine hierarchischen Gliederungen mehr erforderlich sind, wenn ein System gefunden wird, das die Beziehungsinformation explizit ablegt. Für eine praktische Umsetzung verwenden (Vielhaber et al. 2006, S. 657) ein bestehendes PDM Werkzeug, in dem das GAO als zusätzliches Objekt in der Produktstruktur verankert wird. Obwohl PMIs von PDM Werkzeugen unterstützt werden, werden Produktstrukturen weiterhin hierarchisch organisiert. Die Autoren empfehlen weiterhin, die Varianteninformation, entsprechend dem Orthogonal Variant Model (OVM), beschrieben bei (Pohl et al. 2005, S. 105), getrennt von der Produktgliederung zu verwalten. Dieser Aufbau der Klassen wird in PDM Werkzeugen wie Siemens Teamcenter und PTC, Windchill unterstützt.

Nachfolgend werden die Tätigkeiten der vorgestellten Methoden sowie der entsprechend umsetzende Part in Tabelle 5 zusammengestellt. Gemäß dem aktuellen Stand der Technik werden sowohl die eher konzeptionellen Aufgaben, jeweils unter 1. in Tabelle 5, als auch die eher operativen Aufgaben, wie das Erzeugen und Verlinken der Objekte vom Menschen durchgeführt. Damit ergeben sich in Richtung einer Automatisierung zwei mögliche, aufeinanderfolgende Stufen. Erstens könnten Objekte und Verlinkungen durch den Computer erzeugt werden. Zweitens könnten Konzepte und Ordnung gebende Schemen automatisiert erzeugt werden. Der erste Schritt kann für das Erzeugen von Objekten, basierend auf Ereignissen, angeregt werden und einem Datenmodell folgen (Kehl 2019, 200 ff). Darüber hinaus erfordert eine vertrauenswürdige Verlinkung eines Design Artefakts zu dem entsprechenden Ordnungskriterium weiterführende „gehört-zu“ Informationen.

Tabelle 5: Methoden und Tätigkeiten der Produktgliederung

ausführendes Nr. Methoden Tätigkeiten Referenz Organ 1. Objekte erzeugen 2. Objekte in Beziehung zueinander setzen 1 Leere Gliederung erstellen Mensch Autorin 3. Design Artefakte erzeugen und verlinken 2 Erstellen einer Gliederung 1. Auswahl von zukünftig Mensch Glauche

6 Product and Manufacturing Information: Informationen zur Herstellung, zu Form- und Lagetoleranzen Annotationen, Oberflächen- oder Materialangaben. Es existieren unterschiedliche Dateiformate, unter anderem in der ISO 10303 STEP.

2 Produktdatenverwaltung

ausführendes Nr. Methoden Tätigkeiten Referenz Organ durch Modifikation einer zu verwendenden bestehenden Bauteilen treffen 2. Kopieren einer Gliederung 3. ausgewählte Objekte von der Struktur lösen 4. andere ausgewählte Objekte der Gliederung hinzufügen 1. Konzept der Funktionale Gliederung erstellen 3 Gliederungsobjekte 2. Objekte erzeugen Mensch Glauche verwenden 3. Objekte in Beziehung zueinander setzen 1. Konzept der Gliederungsobjekte für eine Gliederung erstellen 4 modulare Gliederung des 2. Objekte erzeugen Mensch Blees Produkts verwenden 3. Objekte in Beziehung zueinander setzen 1. Konzept der miteinander Modulare Gliederung für kombinierbaren 5 ineinander verschachtelte Module Mensch Zagel Module erstellen 2. Objekte erzeugen 3. Objekte in Beziehung zueinander setzen 1. Verständnis von zu trennender Information Trennung unterschiedlicher bereitstellen 6 Informationsbedarfe durch 2. Erzeugung von Mensch Glauche korrespondierende Äste Objekten 3. Beziehung der Objekte zueinander erstellen 1. Konfigurationslogik Anknüpfpunkte für die erstellen Konfiguration an einem 2. Erzeugung von Zagel/ 7 bestimmten Objekt Mensch Objekten Glauche festlegen, dass sich in der 3. Beziehung der Objekte Stückliste wiederfindet zueinander erstellen 1. Konfigurationslogik erstellen Bildung einer relationalen 2. Erzeugung von Weber/ 6 Mensch Gliederung Objekten Vielhaber 3. Beziehung der Objekte zueinander erstellen

2 Produktdatenverwaltung

Der zweiten Stufe der Automatisierung folgend wird deutlich, dass für das Erstellen der benannten Produktgliederung weit mehr Informationen erforderlich sind, als aktuell in einem PDM Werkzeug zur Verfügung stehen. Diese Informationen sind beispielsweise:

• unternehmensstrategische Entscheidungen, bestimmte Module oder Komponenten gemeinsam zu vertreiben. Ein einfaches Beispiel hierzu sind Ersatzteile eines Fahrzeugs, in der Regel werden Pakete mit mehr als der defekten Komponente als Ersatzteile verkauft. Diese Umfänge werden mitunter in der Produktstruktur gekennzeichnet. • das technische Zusammenspiel von Modulen (siehe Vorgehensweise nach Blees). Die Teilsysteme müssen als solche in der Produktstruktur, mit möglichst wenigen zu pflegenden Abhängigkeiten, identifizierbar sein. • zu erwartende oder berücksichtigende Technologiesprünge in den Produkten oder der Fertigung der Produkte. Ein Beispiel für einen solchen Technologiesprung kann beispielsweise sein, dass Bauteile, die zuvor aus mehreren Montageschritten einzeln zusammengesetzt wurden, gegenwärtig in einem Fertigungsschritt hergestellt werden. Veranschaulichend wirkt der Vergleich einer Blisk – gefrästes Turbinenschaufelrad - gegenüber einer Welle mit etwa 15-20 gesteckten einzelnen Turbinenschaufelblättern.

Diese Fragestellungen bedürfen erstens unternehmensinterner Abstimmungen über mehrere Domänen und zweitens Informationen, die über die Grenzen eines PDM Werkzeugs deutlich hinausgehen. Die vorliegende Arbeit zielt darauf ab, die bestehende Verwaltung innerhalb der gegebenen Grenzen des Werkzeugs zu verschlanken. Es wird somit für das weitere Vorgehen dieser Arbeit festgelegt, dass die bekannte Logik der Modul- oder Systemgrenzen, im Gegensatz zu der Verlinkung der Design Artefakte zu den Modulen oder Systemen, nicht automatisiert wird.

2.3.2 Varianten

Bezugnehmend auf Varianten stellen (Vielhaber et al. 2006, S. 655) zunächst das Erfordernis korrekter und solider Konfigurationszuweisung auf. Die Methode der Konfigurationszuweisung kann entweder auf einer Ebene der Produktstruktur, entsprechend (Glauche 2015, S. 76) oder in Kombination mit weiteren Werkzeugen auf mehreren Ebenen erarbeitet werden. So bestimmt (Dreßler 2015, S. 60) einen Konfigurator, der für einen Kunden sichtbare Module auswählbar vorgibt. Die detaillierte Konfiguration auf Stücklistenebene wird in diesem konkreten Anwendungsfall mit dem ERP Werkzeug SAP verwaltet.

(Zagel 2006, S. 80) beschreibt die Bildung von Konfigurationen auf mehreren Ebenen der Produktstruktur im PDM Werkzeug. Er setzt, wie Dreßler, bei einem generellen Modulkatalog

2 Produktdatenverwaltung an. In diesen integrieren beide Autoren Bedingungen unter denen bestimmte Kombinationen erlaubt oder erforderlich sind. Ein Beispiel dazu ist ein PKW, der entweder mit einem Schiebedach oder einem Klappverdeck als Kabrio ausgestattet sein kann. Das Beispiel verdeutlicht, dass vertriebsrelevante oder technische Aspekte in den Bedingungen der Konfiguration implizit hinterlegt sind. Gemäß Zagel werden tiefer in der Produktstruktur bestimmte Knotenpunkte als Kontaktstellen für die Variantenlogik identifiziert. Bei Zagel können diese, anders als bei Glauche oder Blees, mehrfach gestuft verwendet werden.

Die Tabelle 6 stellt die benannten Quellen gegenüber, indem die Methoden und die tatsächlichen Aufgaben aufgelistet werden. Die Betrachtung zeigt, dass ein Mensch die wesentlichen Tätigkeiten ausführt, das PDM Werkzeug fungiert hingegen als Ablage.

Tabelle 6: Methoden und Tätigkeiten zur Variantenbildung

Nr. Methode Tätigkeiten Ausführendes Referenz Organ

a) Erstellen einer Variantenlogik b) Übertragen der Steuerung der Konfigurationslogik in ein Konfiguration mittels Werkzeug einer 1 c) Erstellen der Mensch Glauche Gliederungsebene Gliederungsobjekte (Modul, Baustein, d) Aufbringen der Teilfunktion…) Konfigurationsinformation auf die Gliederungsobjekte Siehe Nr. 1 mit dem Steuerung der Unterschied, dass anstelle 2 Konfiguration an den der Gliederungsobjekte, die Mensch Glauche Design Artefakten Design Artefakte verwendet werden Siehe Nr. 1 mit dem Aufprägen der Unterschied, dass anstelle Variantenzuweisung 3 der Gliederungsobjekte, die Mensch Glauche auf eine Objektversionen verwendet Bauteilversion werden Siehe Nr. 1 mit dem Aufprägung auf Unterschied, dass anstelle Dreßler/ 4 mehreren Ebenen (z. der Gliederungsobjekte, Mensch Zagel B. Modul und Teil) mehrere Objekte markiert werden Siehe Nr. 1 mit dem Kennzeichnung einer Unterschied, dass 5 Plattform plus variable Mensch Blees Verwendungshinweise etwas Anteile anders geartet sind

Für die Bildung von Varianten können zwei Stufen der Automatisierung in Betracht gezogen werden. Erstens die Verlinkung der Objekte an eine gegebene Konfigurationslogik. Am

2 Produktdatenverwaltung

Beispiel „Schiebedach oder Kabrio“ müssen demnach jeweils die konkreten Bauteile wie Motoren, Steuerung, Glasscheiben, Schrauben, Leisten etc. der Variante „Schiebedach“ oder der Variante „Kabrio“ zugeordnet werden. Zweitens die automatisierte Erstellung der Logik – sollen folglich „Schiebedach“ und „Kabrio“ überhaupt eine Variante sein sowie zusätzlich die Verlinkung der Bauteile.

Die Aufstellung der Konfigurationslogik bedarf unternehmensstrategischer Informationen und darüber hinaus der Abstimmung mehrerer Personen und Domänen, wie etwa Marketing und Produktion. Die erforderliche Kommunikation im Unternehmen sollte im direkten Diskurs erfolgen. Somit liegt für Konfigurationen das Ziel in der Umsetzung einer Verlinkung der Design Artefakte mit der strategischen Konfigurationsinformation.

2.4 Werkzeuge

Dieser Abschnitt erläutert die Funktionsweisen des IT-Systems PDM, das die Produktdatenverwaltung unterstützt. Dabei stehen grundlegende Funktionen für die in den Abschnitten 2.1 bis 2.3 beschrieben Dimensionen und Methoden der Datenverwaltung im Fokus. Der Abschnitt zeigt somit weitere Aspekte zur aktuell geltenden Arbeitsteilung zwischen Werkzeug und Anwender auf.

Grundlegend betrachtet (Lutters 2014, 626) Werkzeuge der virtuellen Produktentwicklung. Er beschreibt, dass Werkzeuge dann erfolgreich sind, wenn sie einfach zu erreichen und robust sind sowie keine größere Aufmerksamkeit bei der Umsetzung der Aufgabe erfordern. (Eigner und Stelzer 2013, S. 31–35) erläutern, dass PDM Werkzeuge Design Artefakte beinhalten und diese allen Nutzern entlang des Lebenszyklus zur Verfügung stellen. Damit unterstützen PDM Werkzeuge die Kommunikation über Unternehmensgrenzen hinaus (Gerhard 2016, S. 216). Gerhard versteht neben den besprochenen Dimensionen die Steuerung von Arbeitsvorgängen als Kernaufgabe von PDM Werkzeugen. Als wesentliches Differenzierungsmerkmal gegenüber einer einfachen Ablage in Ordnerstrukturen stellt Gerhard heraus, dass Dateien lediglich einmal abgelegt und dann mehrfach referenziert werden. Darüber hinaus definiert der Autor die Wichtigkeit von Produktstrukturen als Ordnungskriterium. Die Produktgliederung wird in der VDI (2219:2016) als tragendes Objekt der Produktdatenverwaltung in PDM Werkzeugen beschrieben. Die grundlegenden Anforderungen und Bedarfe an PDM Werkzeuge sind in Tabelle 7 zusammengefasst und dienen als Grundlage sowohl für die Konzeptionierung vom automatisierten PDM als auch zu dessen Evaluierung.

2 Produktdatenverwaltung

Tabelle 7: Übergeordnete Bedarfe für PDM Werkzeuge und Methoden

Nr. Bedarf

1 Werkzeuge sind einfach zu bedienen. 2 Es existiert eine klar verständliche Methode für das Werkzeug. Ein Werkzeug ist gleichermaßen umfassend, robust und einfach um praktisch 3 verwendet zu werden. 4 Ein PDM Werkzeug verwaltet alle Design Artefakte entlang des Lebenszyklus. 5 Dateien werden initial einfach abgelegt und danach referenziert. Ein PDM Werkzeug unterstützt den Zugriff auf die Design Artefakte entlang des 6 Lebenszyklus für alle Stakeholder.

2.4.1 Funktionen

Dieser Abschnitt beschreibt die initialen Kernfunktionalitäten von PDM Werkzeugen, die Ingenieure zur Bewältigung ihrer Aufgaben verwenden. Geringfügige Unterschiede zwischen den Werkzeugen einzelner Hersteller verbleiben mit dem Ziel unbeachtet, die Ganzheit der Aufwände der Produktdatenverwaltung zu betrachten.

Ausgangspunkt des Datenmanagements in einem PDM-System sind die Design Artefakte, wie Einzelteile oder Baugruppen etc., aus denen ein Produkt besteht. Jedem Design Artefakt wird ein Datenbankobjekt zugeordnet (Gerhard 2016, S. 220). Diese Datenbank- oder Containerobjekte sind untereinander manuell verknüpfbar und bilden somit die Produktstruktur. Zu jedem Objekt können zusätzliche Informationen, sogenannte Metadaten, in Form von Attributen oder verlinkten Informationen verwaltet werden. Die Design Artefakte werden als Nutzdaten bezeichnet.

Klassische PDM Werkzeuge bieten, neben dem Persistieren, dem damit verbundenen Schutz und der Verfügbarkeit der Daten die folgenden Möglichkeiten der operativen Datenverwaltung:

1. Objekte erzeugen, sowie Nummern und Namen zu den Datenbankobjekten zuweisen. 2. Datenbankobjekte mit Dateien (Design Artefakten) aus Autoren Werkzeugen verknüpfen. Dabei werden mitunter die vergebenen Namen und Nummern der Datenbankobjekte auf die Nutzdaten und deren Datenbankobjekte im Autorenwerkzeug übertragen. 3. Den Datenbankobjekten und damit zudem den Nutzdaten Status zuweisen und manipulieren. Je nach PDM Werkzeug und dessen Konfiguration erfolgt dies integriert oder unabhängig von Workflows. Sollen gesamte (Teil-) Produkte mit einem Status versehen werden, bedarf es des Ausleitens und eines nachfolgenden Reimports beispielsweise einer Stückliste. 4. Sperren für die Bearbeitung durch andere Anwender durch einen Check-Out Vorgang, sodass simultan einzig ein Anwender ein Design Artefakt inhaltlich manipulieren kann. Ein

2 Produktdatenverwaltung

Check-In Vorgang gibt das veränderte Design Artefakt und das zugehörige Datenbankobjekt wieder für die Bearbeitung frei. 5. Versionen erzeugen, verwalten und ändern. Dabei werden auf Basis einer manuellen Anweisung durch einen Anwender neue hierarchisch unterhalb angeordnete Datenbankobjekte angelegt und entsprechend benannt. Die Nutzdaten werden, je nach PDM Werkzeug, durch Bestätigung des Anwenders mit überführt und bei Bedarf durch das Verknüpfen der veränderten oder neuen Datei sowie dem Trennen der Verbindung zu der bestehenden Datei ersetzt. 6. Hierarchische Gliederungen erzeugen und editieren, durch das Verbinden der Objekte mit „gehört-zu“ Verbindungen. Das Editieren erfolgt durch Trennen und neu Verbinden. 7. Transversale Verknüpfungen (“steht in Verbindung zu”) erzeugen und editieren. Das Editieren erfolgt durch Trennen und neu Verbinden. 8. Konfigurations-Logiken7 aufzubauen. Dies ist ein Prozess in mehreren Schritten: 1. Festlegen von „Baureihen“ oder „Auswahlkriterien“, die später als Filterparameter fungieren. 2. Zuweisen dieser Filterparameter zu dedizierten Objekten, etwa auf Stammnummernebene oder auf Versionsebene, je nach betrieblicher Vereinbarung. Mitunter erfolgt die Zuweisung auf mehrere Objekte gleichzeitig. Teilweise mit und teilweise ohne ausschließende Bedingungen. 9. Einzelnen Objekten oder deren Versionen zeitliche Gültigkeiten zuweisen.

Die Ausführung der oben benannten Funktionen erfolgt jeweils manuell und bringt damit den entsprechenden Aufwand sowie eine Fehleranfälligkeit mit sich (Hellerstein 2008, S. 13).

Zum Zeitpunkt der Erstellung dieser Arbeit gibt es keine ausgewiesene Funktion in PDM Systemen, die Sichten erzeugt. Eine Ausnahme stellt die Bildung von Sichten an einem Objekt dar (Boma R. Koko, Hugh Stewart 1993). Diese ermöglicht es, letzte Arbeitsstände ein- oder auszublenden.

Die Funktionen des Suchens stellt eine Kernfunktionalität des PDM Systems dar, welche durch den Zugriff auf Datenbanken zunächst einfach ermöglicht wird. Die Suche funktioniert konventionell stichwortbasiert und erfordert aus diesem Grunde eine sehr gründliche und durchgängige Datenverwaltung (Eigner et al. 2017, S. 159). Es gibt wissenschaftliche Arbeiten, die vorschlagen, konventionelle PDM Systeme zusätzlich mit Indizierungssystemen zu ergänzen (Weber 2011, S. 213). Zudem gibt es technische Lösungsansätze, wie etwa von Contact Software oder Siemens PLM, welche bereits eine indexbasierte Suche in geschlossenen textbasierten Dateien wie PDF oder Excel innerhalb des PDM realisiert haben. Entsprechend (Hawking, S. 16) indexiert ein Enterprise Search zusätzlich verteilte und diverse

7 Die Abläufe der Konfiguration unterscheiden sich je nach PDM Hersteller.

2 Produktdatenverwaltung textbasierte Datenquellen. Arbeiten der Autorin mit Studierendengruppen konnten ein Enterprise Search auf Basis von Apache „Solr“8, entsprechend den Konzepten von (Smiley und Pugh 2009), aufbauen. Das Enterprise Search unterstützt zudem, ähnliche und verwandte Worte zu suchen, ignoriert Groß- und Kleinschreibung, unterstützt die Benennung von mehreren Suchworten und filtert eigenständig nicht relevante Füllworte aus der Nutzereingabe heraus. Zusätzlich ist das Enterprise Search dadurch charakterisiert, dass es mehrere Datenbanken als Quelle verwenden kann.

Weitere Forschung adressiert das indizierte Suchen als PDM Funktionalität ebenso für „ähnliche“ geometrische 3D Modelle. (Neumann und Abuosba 2016, S. 170–174) stellen einen 3D Index Mechanismus vor, der am Beispiel von 3D PDF Dateien (ISO 14739-1:2014) Formdeskriptoren ermittelt und diese für eine Ähnlichkeitssuche verwendet. Diese werden in einer Abstandsmessung miteinander verglichen. Ebenso zeigen die Arbeiten von (Adolphy 2015, S. 156) eine Methode auf, mit der STL Dateien auf eine geometrische Ähnlichkeit hin analysiert werden. Der verwendete Mechanismus ist eine Nachbarschaftsanalyse. Auch (Aßfalg 2005, S. 215) optimiert die geometrische Ähnlichkeitssuche. Er verwendet Voxel9 Geometrien, mit denen die Ähnlichkeit von jeweils zwei Geometrien durch eine Eigenwertanalyse ermittelt wird. In ähnlicher Weise arbeitet auch (Dekhtiar 2018, S. 240) daran, ähnliche Geometrien zu ermitteln. Er erzeugt zum Trainieren eines neuronalen Netzes Bilder einer CAD Datei von allen Seiten und nutzt das trainierte Netz, um die Bauteile zu klassifizieren. Aktuelle PDM Werkzeuge, wie Teamcenter 12, beinhalten bereits geometrische Ähnlichkeitssuchen, die Anwender zum Auffinden von Geometrien verwenden können. Dabei wird vorausgesetzt, dass ein Anwender dem PDM Werkzeug eine Geometrie zeigt und es auffordert eine ähnliche zu finden.

Operativ eingesetzte PDM Werkzeuge sind in der Regel adaptiert (Vielhaber et al. 2006, S. 656). Veränderungen der Funktionen von PDM Werkzeugen können in einer Administrationsebene realisiert werden. Hierbei handelt es sich um Einstellungen, die auch bei Updates und Veränderungen der umgebenden IT unbeeinträchtigt bleiben. Typische Einstellungen können die Rollen und Rechte oder Workflows betreffen.

Über die wachsende Art und Anzahl von verwalteten Dokumenten und Prozessteilnehmern wurden PDM Systeme um die Möglichkeiten des Projekt-, Workflow- und des Anforderungsmanagements erweitert. Dies wurde durch eine Ergänzung von zusätzlichen Funktionsblöcken oder Modulen um das Kern PDM herum realisiert. Die umfassende Verknüpfung mit allen relevanten Fragestellungen, wie des Änderungswesens, entlang des

8 Verfügbar als Java Bibliothek unter: https://lucene.apache.org/solr. 9 Voxel: englische Wortkombination aus volume (vox) + element(el), kleine Würfel oder ähnliche bilden einen Volumenkörper

2 Produktdatenverwaltung gesamten Produktlebenszyklus geht deutlich über die Grenzen des Unternehmens hinaus (Han und Do 2006, S. 827), wodurch der Begriff des Produktlebenszyklusmanagements (PLM) entstand. Durch die Ergänzung weiterer, zugekaufter Funktionen ergab sich ein umfänglich zu bedienendes Werkzeug, von dem häufig lediglich Teilumfänge von einzelnen Nutzern verwendet werden. Der Kern der Anwendung wurde in der Regel technologisch nicht adaptiert.

Die automatisierte Plausibilisierung von Produktdaten mit dem Ziel der Erhöhung der Qualität in größeren Datenbanken in Unternehmen wurde von (Hellerstein 2008, S. 18) untersucht. Der Autor schlägt vor, dass eine automatische, statistische Prüfung nach der Dateneingabe erfolgen soll. Gleichzeitig geht er davon aus, dass eine Korrektur, ohne die Intervention eines Domänenexperten, nur in wenigen Fällen gelingen kann. Die vorliegende Arbeit bringt einen Vorschlag für eine derartige automatische Analyse und die dazugehörende Methode für den PDM Kontext.

Abschließend ist zu resümieren, dass insbesondere die Verwaltung von Konfigurationen über ineinander verschachtelte Bedienelemente realisiert ist und damit die augenscheinlich aufwändigste Funktion. Darüber hinaus können Sichten nicht mit einer einfachen, anerkannten Funktion gebildet werden. Die Verwaltung von Versionen funktioniert derzeit in allen Werkzeugen nahezu identisch.

2.4.2 Integration von Autoren Werkzeugen

Dieser Abschnitt zeigt die Integration von CAD zu PDM Werkzeugen. Die Erkenntnisse am Ende des Kapitels lassen sich ebenso auf andere Autoren Werkzeuge übertragen, insbesondere für die Fälle, in denen Hersteller des Autoren- und Verwaltungswerkzeugs nicht identisch sind. Das Kapitel trägt neben der technologisch geprägten Diskussion über Integration auch methodische Aspekte zusammen und schließt mit einer Zusammenfassung der ingenieursmäßigen Bedarfe ab.

Wesentlich, hinsichtlich der Integration zwischen den Werkzeugen, ist die Frage nach dem Hersteller, bzw. der Kooperation der Hersteller. Einige PDM Hersteller verkaufen gleichzeitig auch CAX Werkzeuge. Mitunter gibt es CAD Hersteller, die keine PDM Funktionen anbieten, beispielsweise das Werkzeug Rhinoceros der Firma Robert McNeel & Associates. Andere Unternehmen bieten ein einfaches Produkt Data Management an, wie etwa die Firma Autodesk mit dem Produkt Vault. Dieses einfache PDM stellt Kernfunktionalitäten des PDM bereit. Andersherum bieten PDM Hersteller nicht immer CAD Werkzeuge an, wie etwa die Firma Contact mit CIM Database. Im Falle einer Kooperation zwischen den Herstellern kann ein PDM Werkzeug auch integriert mit der CAD Umgebung wirken, wie etwa für das Werkzeug Inventor von der Firma Autodesk und das PDM Werkzeug Teamcenter von der Firma Siemens DI.

2 Produktdatenverwaltung

Die pragmatische Betrachtung ergibt, dass eine intuitive Bedienung des PDM Werkzeugs sowie eine möglichst große Offenheit 10 zur Integration von unterschiedlichen Design Artefakten gegeben sein muss, damit das PDM beispielsweise im Verbund mehrerer Unternehmen nutzbar ist.

Hersteller, die CAD und PDM aus einer Hand anbieten, sind bestrebt, ihre komplette Werkzeugpalette zu offerieren und sorgen intrinsisch für eine gute Integration. In der Regel wird für derartige Werkzeuge, die für die Zusammenarbeit ausgelegt sind, ein Plug-In angeboten, mit dem aus der PDM Umgebung in die CAD Umgebung gewechselt werden kann und vice versa. Einige Hersteller bieten die Möglichkeit, Modelle anderer Hersteller in ausgewählten Formaten in das PDM Werkzeug hochzuladen, diese können somit teilweise gelesen und visualisiert werden. Aus den CAD Werkzeugen werden, je nach Werkzeugkombination, sowohl einzelne Design Artefakte als auch Zusammenbauten über eine Import-Funktion in das PDM Werkzeug übertragen. Darüber hinaus wird die Positionsinformation der 3D Geometrie im Kontext des Produkts auf dem Link zwischen dem Design Artefakt und dem darüber liegenden Objekt in der Struktur abgelegt, um die jeweilige Instanz anzuzeigen. Diese Positionsinformation ist nicht permanent an der Oberfläche des PDM Werkzeugs sichtbar und ist somit auch nicht explizit für die Variantenverwaltung ansprechbar.

Können die Daten nicht direkt übergeben werden, wie es bei unterschiedlichen Herstellern der Fall sein kann, erfolgt eine Konvertierung in einen neutralen Standard, beispielsweise STEP 242 oder JT2Go, und ein Import in das PDM Werkzeug. Das PDM Werkzeug wird somit vielmehr als Archiv denn als eine aktive Verwaltungsumgebung entlang des Entwicklungsprozesses verwendet, da etwa das direkte Öffnen des Modells aus dem PDM Werkzeug heraus nicht verfügbar ist.

Der Speicherort eines geometrischen Modells kann in CAD Werkzeugen durch den Anwender bestimmt werden, dabei legt er zudem das Dateiformat fest. Alternativ besteht die Möglichkeit, diesen in der Administrationsebene auf einen bestimmten Zielort, wie beispielsweise einen Server eines PDM Werkzeugs festzulegen. Integrierte Cloud Systeme wie Fusion von der Firma Autodesk oder 3D Experience von der Firma Dassault speichern an einem vorgegebenen Ort auf der Cloud. Der Export und Import von Dateien wird dabei häufig aufwändiger für Anwender, da Funktionen stärker verschachtelt, im Vergleich zu konventionellen Werkzeugen, bereitstehen.

10 Vgl. “Code of PDM openness”. Datenformate werden, wie in der Einleitung beschrieben, nicht näher betrachtet. Es sei darauf hingewiesen, dass aktuelle PDM Werkzeuge lediglich in Ausnahmefällen dem Code of PDM Openness entsprechen.

2 Produktdatenverwaltung

Der Aufwand für die Datenverwaltung verbleibt in Cloud-Plattformen vergleichbar zu aktuellen Werkzeugen. Anstelle der zwei Werkzeuge mit den entsprechenden Funktionen erfüllen gegenwärtig zwei Apps mit identischen Funktionen die Aufgaben der Erstellung von Design Artefakten sowie der Datenverwaltung. Die Integration ist ebenso wie bei Werkzeugen, die von einem Hersteller erzeugt wurden gegeben, allerdings nicht auf verbesserte Art und Weise.

Die Methoden zum Übertrag geometrischer Modelle auf PDM Werkzeuge werden sowohl durch die jeweiligen Werkzeuge selbst, als auch durch die Unternehmen geprägt. Die Tabelle 8 fasst diese zusammen.

Tabelle 8: Methoden zum Übertrag von Modellen zwischen CAD und PDM Werkzeugen

Nr. Methode Beschreibung Quelle Erstellung der geometrischen Modelle und 7 PDM folgt CAD Zusammenbauten, ohne dass die Autorin Gliederung dazu vorliegt PDM Objekt gibt Namen, Nummer und 8 CAD folg PDM Systemzugehörigkeit für Design Artefakte Autorin und/oder Zusammenbauten vor Modell über einen Vektor durch eine zusätzlich gespeicherte „Geo Siemens 9 zum Produkt Pos“, die eigenständig befüllt wird PLM positionieren situationsabhängig entsprechend der Modelle einzeln 10 Anzahl fertig gestellter Design Artefakte und Autorin übertragen der unternehmensindividuellen Methode

Abschließend ist festzustellen, dass die Integration zwischen CAD und PDM Werkzeug, je nach verwendeter Werkzeugkombination, unterschiedlich gut unterstützt wird. Für einen Ingenieur ist es hilfreich, dass möglichst viele Informationen, wie die Position im Produkt, zusätzliche Informationen zur Verwendung, Informationen zu Beziehungen zu anderen Objekten etc. möglichst automatisch mit an die PDM Umgebung übergeben werden.

2.4.3 Stand der Forschung zu PDM Funktionen

Neben den konventionell in Produktstrukturen organisierten Daten werden zudem unstrukturierte Daten im Rahmen der Produktdatenverwaltung erforscht. Diese ermöglichen es, vorhandene produktbezogene Informationen zu bündeln und der Datenverwaltungsumgebung und den Anwendern zur Verfügung zu stellen. (Kassner et al. 2015) benennen Texte, Emails, Bilder oder Videos, Patente, Spezifikationen, Marktanalysen, Fehlerberichte, die nicht in einer Datenbank abgelegt sind, aber auch unternehmensinterne Blogs und Wikis als Beispiele für unstrukturierte Daten. Dabei finden sie heraus, dass insbesondere in der Phase der Produktentwicklung verhältnismäßig viele unstrukturierte Daten vorliegen. Dem entgegen stellen die Autoren unter anderem PDM, BOM und ERP als strukturierte Daten vor. Kassner analysiert strukturierte und unstrukturierte Daten mit

2 Produktdatenverwaltung statistischen Verfahren des Data Minings. Sie setzt dabei Fehler aus dem Feld mit Fehlern während des Testens und den Entwicklungsdaten in Bezug zueinander. Damit wird die nachträgliche Analyse der zusammengeführten Datenbestände unterstützt und zukünftige Produktgenerationen können auf dieser Grundlage neu entworfen werden. Ähnlich verfahren auch (Zeeshan und Gerhard 2008, S. 4) mit einer entsprechend erweiterten IT-Architektur zur Datenlagerung und Analyse. Die Autoren schlagen ein Konzept vor, in dem die Informationsbereitstellung während der Suche über Agenten und semantische Zusammenhänge in Form von Ontologien verbessert wird.

(Wickel 2017, 128 ff) beschreibt die Möglichkeit, Änderungsmanagement auf Basis von Assoziationsanalysen so zu unterstützen, dass Abhängigkeiten innerhalb von Produktstrukturen automatisch aufgezeigt werden können. Durch eine Prüfung auf hochvernetzte, statistisch häufig veränderte Komponenten sowie einen dadurch entstehenden gewichteten Graphen werden Abhängigkeiten einer aktuellen Änderung vorausgesagt. So entsteht ein Unterstützungswerkzeug, das während der Erstellung der Änderung mögliche, ebenfalls betroffene Komponenten anzeigt.

Die Arbeiten von Wickel, Zeeshan und Kassner zeigen die Potentiale der Datenanalytik und semantischen Vernetzung von Produktdaten auf, mit denen Werkzeuge zur Entscheidungsunterstützung in Entwicklungsprozessen entstehen. Dazu benötigen die Autoren eine erweiterte Datenbasis gegenüber der konventionellen PDM Welt sowie einen manuellen Aufbau der Datenanalytik. Diese Arbeit zielt darauf ab, die Potentiale der semantischen Vernetzung und Datenanalytik zunächst an den Produktdaten zu erproben um die Aufwände der konventionellen Produktgliederung und Verwaltung von Varianten zu verbessern.

(Kehl 2019, S. 227) untersucht in seiner anwendungsnahen Arbeit eine ereignisgesteuerte SOA11 mit dem Ziel, die domänenübergreifende Datenversorgung zu verbessern. In seiner Arbeit ergänzt Kehl eine Middleware, die unterschiedliche Systeme miteinander in Verbindung bringt. In der Umsetzung der Arbeit bildet die technologische Umsetzung der Middleware, hinsichtlich des inneren Aufbaus, des hinterlegten Datenmodells und der Performanz, den Kern der Forschung. Die Einflüsse auf Methoden und Prozesse in den Autoren- und Datenverwaltungswerkzeugen verbleiben bei Kehl sekundär. In Übereinstimmung mit der Auffassung von Kehl wird in dieser Arbeit die ergänzende vereinfachte Informationsunterstützung in den bestehenden Autoren Werkzeugen angestrebt.

(Tiedeken et al. 2013, S. 144) benennt als Problem der Produktdatenverwaltung die fehlenden Beziehungen zwischen Design Artefakten, die oftmals auch in verteilten Datenquellen lagern.

11 Service Oriented Architecture: Services (auch Funktionen und Aufgaben) aus unterschiedlichen Autoren - Systemen werden auf einer Plattform zentral angesteuert und folgend Informationen geteilt.

2 Produktdatenverwaltung

Er schlägt Ontologien als Lösungselement für die Vernetzung vor. (Bunzel 2013, S. 41) erklärt in ihrem Artikel die Nutzung von Ontologien zur Entscheidungsunterstützung im Kontext der Produktentwicklung. Zwei Ontologien bilden in dem Vorschlag der Autorin Anforderungen und Funktionen auf der einen Seite und mögliche technologische Lösungsbausteine auf der anderen Seite ab. Die semantische Beziehungsfindung zwischen beiden Seiten zeichnet den Syntheseprozess des Ingenieurs nach, indem das entwickelte Softwarewerkzeug Begriffe in beiden Ontologien erkennt und verbindet. So werden dem Anwender technologisch untermauerte Lösungselemente für gesuchte Funktionen als Entscheidungsunterstützung angeboten. (Gogineni 2019, S. 95–97) verwendet Ontologien, um Beziehungen zwischen bereits bestehenden, nicht verbundenen, relationalen Datenbanken innerhalb der Produktion zu etablieren und auf diese Weise Suchvorgänge zu verbessern. Die Veränderlichkeit der Daten wird dabei nicht betrachtet. (Woll 2018, S. 59–65) erarbeitet ein Konzept, mit dem Produktdaten innerhalb des PDM Werkzeugs mit solchen aus anderen Werkzeugen in Verbindung gebracht werden können. Er verwendet Ontologien, um das Datenmodell einer Graph Datenbank zu beschreiben. In dieser Graph Datenbank werden Relationen zwischen Daten innerhalb und außerhalb des PDM Werkzeugs in Verbindung gebracht. Ontologien stellen somit ebenso im Bereich der Produktdaten eine Möglichkeit dar, Wissen generisch abzubilden und über den Begriff einem gewissen Kontext zuzuordnen. Diese Möglichkeit soll im späteren Konzept für die Produktdaten verwendet werden, um Klassifikationen herzustellen.

Abschließend ist zu erkennen, dass ausgehend von einem einfachen datenbankbasierten Werkzeug mit einem Fokus auf die mechanische Konstruktionswelt ein umfängliches PLM Gesamtkonzept gewachsen ist. Der Kern der initial geschaffenen Werkzeuge wurde jedoch technologisch nicht adaptiert. Das Gesamtkonzept kollidiert mit der, in der Realität nicht umgesetzten, Informationsdurchgängigkeit über die Kette der Werkzeuge hinweg sowie mit der umfangreichen Funktionsmenge der Werkzeuge. Die jüngere Forschung adressiert verteilte Datenquellen als Problematik und findet Möglichkeiten, die Daten miteinander in Beziehung zu setzen und dem Anwender somit weiterführende Informationen bereitzustellen. Diese zusätzlichen Möglichkeiten werden häufig für Fragestellungen von Datenkonsumenten außerhalb der PDM Kernfunktionalitäten angewandt. Es erscheint somit erforderlich, die Möglichkeiten für die Daten generierenden Anwendungen sowie die Kernfunktionalitäten zu untersuchen.

2.5 Zusammenhang von Methoden und Funktionen

Die obenstehenden Abschnitte beschreiben Methoden der Datenverwaltung unter dem Gesichtspunkt der Ausprägung des Produkts und der Ingenieursaufgabe, sowie den

2 Produktdatenverwaltung funktionalen Aufbau des PDM Werkzeugs. In den wissenschaftlichen Arbeiten zu Methoden werden die Werkzeuge der Produktdatenverwaltung als nicht veränderliche Eingangsgröße betrachtet, vergleiche (Glauche 2015, S. 131; Blees 2011, S. 11–12; Weber et al. 2003, S. 448). Andersherum verbleibt in wissenschaftlichen Konzepten zur Veränderung der Werkzeuge der Einfluss auf die Arbeitsweise unbeachtet (Dekhtiar 2018, S. 230). (Lutters 2014, 607) beschreibt demgegenüber den Zusammenhang von Werkzeug und Methode als grundsätzlich erforderlich. Der folgende Abschnitt konkretisiert die Betrachtungen für die relevanten Dimensionen dieser Arbeit Produktgliederungen und Varianten. Für diese Dimensionen werden die jeweiligen Werkzeugfunktionen mit den Methoden gegenübergestellt.

Die Wechselwirkung von Werkzeug und Methode wird durch das Werkzeug, die Tätigkeiten im Rahmen der Methode, die Fertigkeiten des Anwenders sowie das umgebende System beschrieben (Lutters 2014, 611). Diese Arbeit betrachtet die Wechselwirkung zwischen Methode und Werkzeug während das Werkzeug modifiziert wird, die individuellen Fähigkeiten des Anwenders verbleiben eine Konstante. Allein der Zugang zu dem Werkzeug oder der Methode befähigt den Ingenieur nicht zur Umsetzung seiner Aufgabe.

Im Kontext von Produktgliederungen sind die Methoden, die in Abschnitt 2.3 zusammengestellt wurden, gegenüber den, in Abschnitt 2.4.1 erläuterten, Funktionen in Tabelle 9 aufgetragen. Dabei ist der Zusammenhang als unabhängig (0), hinderlich (-1) oder förderlich in zwei Ausprägungsstufen manuell (1) und automatisiert (2) aufgetragen. Die Werte in der Tabelle entstehen durch die Beobachtung der Durchführung der Aufgaben in Teamcenter und Enovia durch die Autorin. In Enovia wurden bei Aufgaben, Nr. 1 und 2 durchgeführt am Beispiel einer bestehenden Produktstruktur. Die Design Artefakte lagen für die Tests fertiggestellt vor und verblieben unverändert. Die Aufgaben 3 – 6 wurden in Teamcenter durchgeführt, ebenfalls am Beispiel einer bestehenden Produktstruktur. Die jeweiligen Funktionen, Module oder Baukastenelemente bestehen als Objektbenennung bereits vor dem Test und werden im Rahmen des Tests in der Struktur erzeugt und entsprechend mit den Design Elementen und in der Struktur verlinkt. Für den Test 6 wurde eine Anforderungsstruktur in Teamcenter angelegt und diese mit den Design Elementen der Funktionalen Gliederung aus Zeile 3 verknüpft.

2 Produktdatenverwaltung

Tabelle 9: Zusammenhang von Funktionen und Methoden der Produktgliederung

Nr. 1 2 3 4 5

Funktion Methode

Nr.

in/out

–

Objekte erzeugen Verlinkungen erzeugen Metadaten eintragen aufprägen Status Check kopieren einer vollständigen 1 Gliederung inkl. Design Artefakten 2,1 2, 1 0 0 0 und modifizieren dieser Gliederung ohne Design Artefakte 2 1 1 0 0 0 erstellen und nachträglich befüllen Funktionnale Gliederung des 3 1 1 0 0 0 Produktes bereitstellen Modulare Gliederung des 4 1 1 0 0 0 Produktes bereitstellen

5 Baukastenlogik bereitstellen 1 1 0 0 0

6 Bildung einer relationalen Struktur 1 1 0 0 0

Augenscheinlich aus der Tabelle abzulesen ist, dass es keine Behinderung bei der Umsetzung der Methoden der Produktgliederung gibt. Weiterhin sind die Funktionen für den Status, Check- in/out und die Metadaten unabhängig von der Erstellung und Manipulation der Produktgliederung. Die Spalten 1 und 2 zeigen, dass aktuell Objekte und Verlinkungen in der Regel manuell erzeugt werden. Die Objekte und Verlinkungen unterstützen die konzeptionelle Produktgliederung. Die eigentliche Logik der Produktgliederung, das bedeutet, warum ein Objekt zu erzeugen ist, ist unabhängig von der Werkzeugfunktion. Beispielsweise werden die zu bildenden Knoten bei (Blees 2011, S. 106–108) berechnet, die der Produktdatenverwaltung nicht zur Verfügung stehen. Die aktuell manuell durchgeführten Tätigkeiten des Erzeugens von Objekten und der Etablierung von Verlinkungen sind manuell einfach durchzuführen; eine Automatisierung wäre technologisch einfach zu ersetzen. Eine Automatisierung mit der Bewertung „2“ findet aktuell lediglich für die Kopiervorgänge kompletter Produktstrukturen statt, siehe Zeile 1. Bei den anderen Vorgängen ist eine Begründung für die Erstellung von Objekt und Verlinkung erforderlich. Die dafür erforderlichen Informationen liegen im PDM Werkzeug nicht vor.

Der Zusammenhang zwischen Werkzeugfunktionen und Methoden zur Bildung von Varianten, wie sie in Abschnitt 2.3.2 Varianten zusammengestellt sind, gegenüber den in Abschnitt 2.4.1

2 Produktdatenverwaltung

Funktionen erläuterten Funktionen ist Tabelle 10 zu entnehmen. Dabei ist der Zusammenhang als hinderlich (-1), förderlich in zwei Ausprägungsstufen: manuell (1), automatisiert (2) oder unabhängig (0) eingeteilt. Die Werte in der Tabelle entstehen durch die Beobachtung der Durchführung der Aufgaben und eine Bewertung durch die Autorin. Als Werkzeug wird Teamcenter verwendet, es werden in die bestehende Funktionale Gliederung aus den Betrachtungen zur Produktgliederung ob Varianteninformationen hinzugefügt. Dazu werden zunächst zuvor bestehende Varianten erzeugt, in der Tabelle zusammengefasst in der Funktion 3 „Metadaten eintragen“. Die so erzeugte Varianteninformation wird auf die unterschiedlichen Elemente der Struktur aufgebracht, entsprechend der Methoden in den Zeilen 1-5.

Hinderlich für die Verwaltung von Varianten wird die Nutzung von mehreren Werkzeugen bewertet, da diesbezüglich neben den Verwaltungstätigkeiten ein Abgleich zwischen zwei Werkzeugen stattfinden muss. Für die Verwaltung der Varianten ist neben den Datenbankobjekten und deren Verlinkung zusätzlich das Aufprägen der Variantenlogik erforderlich, was durch die Funktion 3 „Metadaten eintragen“ erfolgt. Die Objekte und Artefakte müssen zunächst verlinkt sein, damit etwa ein kompletter Ast der Produktstruktur mit einer Variante in Verbindung gebracht wird und das spätere Traversieren der Struktur erfolgen kann. Die Verwendung eines Status wurde im Rahmen der Tests nicht betrachtet, etwaige Einschränkungen bei der Modifikation der Verlinkung wurden folglich nicht betrachtet.

Die Information warum ein Objekt mit einer bestimmten Varianteninformation in Zusammenhang steht, liegt aktuell außerhalb der Informationen, die regulär im PDM Werkzeug verwaltet werden. Der technische Vorgang des Aufprägens der Metadaten, des Erzeugens und Verknüpfens der Objekte ist einfach.

Zusammenfassend ist zu sagen, dass die Umsetzung einer Methode im PDM Werkzeug einem Datenmanipulationsvorgang entspricht, bei dem Datenbankobjekte und Funktionen angesprochen werden. Die genaue Umsetzung ist mitunter innerbetrieblich geregelt, und auch die die Werkzeuge geprägt. Die Umsetzung oder Ausführung des Manipulationsvorgangs ist technisch einfach, erfolgt heute jedoch manuell. Das liegt darin begründet, dass die Informationen zur Ausführung der Methode in der Regel nicht im PDM Werkzeug vorliegen, etwa warum ein Objekt zu einer Struktur ergänzt werden soll.

2 Produktdatenverwaltung

Tabelle 10: Wirkung von Funktionen auf die Bildung von Produktvarianten

Nr. 1 2 3 4 5

Funktion

Nr. Methode in/out

–

ck ck

Objekte erzeugen Verlinkungen erzeugen Metadaten eintragen Status aufprägen C 1 auf ein Teilobjekt 1 0 1 0 0 2 auf ein Nutzdatum 1 0 0 0 0 3 auf Äste 1 1 1 0 0 auf einer bestimmten 4 1 1 1 0 0 Ebene 5 auf mehreren Ebenen 1 1 1 0 0 in mehreren 6 -1 0 1 0 0 Werkzeugen

2.6 Automatisierungspotentiale

Dieser Abschnitt subsummiert die bisher zusammengetragenen Möglichkeiten der Optimierung von PDM Werkzeugen. In den obenstehenden Abschnitten 2.2 bis 2.4 werden sowohl technologische als auch methodische Optionen vorgeschlagen. Diese werden in der Tabelle 11 zusammengestellt und sind in Fortführung von Tabelle 2 in Abschnitt 2.1 nummeriert, um sie später im Konzept entsprechend zu referenzieren.

Ein Fokus der Forschung liegt auf der Etablierung von Zusammenhängen zwischen Produktdaten. Dazu werden einerseits die Bezüge zwischen den Daten - unterstützt durch Automatismen - etabliert, aber auch die zu betrachtenden Datenquellen erweitert. Auf diese Weise werden bestehende Produktstrukturen erweitert. Darüber hinaus beschäftigt sich die Forschung bisher nicht damit, die konventionellen Aufgaben der Produktdatenverwaltung zu automatisieren.

Tabelle 11: Potentiale für die Optimierung der Produktdatenverwaltung

Nr. Potential Referenz

6 Verwaltung der Zusammenbauposition als explizites Datenobjekt Vielhaber 2004 7 Verwaltung von Produktdaten ohne Hierarchien Weber 2003 Nutzung von Data Mining zur Ermittlung, Gewichtung und 8 Wickel 2017 Häufung von Beziehungen zwischen Dateien Etablierung der Beziehungen zwischen Design Artefakten mittels Weber 2003/ 9 semantischer Netzen oder agentenbasierter Systeme Kehl 2019

2 Produktdatenverwaltung

Etablierung von Beziehungen zwischen Design Artefakten mittels Bunzel 2013/ 10 Ontologien Tiedeken 2013 Etablierung von Beziehungen zwischen Design Artefakten mittels 11 Kehl 2019 Klasseninformationen 12 CAD Systeme dienen als Geometrie- und Eigenschaftslieferant Weber 2003 Explizite Ausweisung von Produkteigenschaften als eigene 13 Weber 2003 Struktur Ablage von unterschiedlichen Bedarfen in unterschiedliche Vielhaber 2006 14 Strukturen Kehl 2019 15 Ausschließliche Etablierung von „gehört-zu“ Verbindungen Vielhaber 2004 Verbindung und Nutzung von unstrukturierten und strukturierten 16 Kassner 2014 Daten als Informationsquelle Herstellung von Datendurchgängigkeit durch Nutzung von 17 Kehl 2019 ereignisbasierter SOA Neumann/ 18 Automatische Suche geometrisch ähnlicher Bauteile Dekhtiar 2018 Identifizierung zusammengehörender Teile aufgrund ihrer 19 Adolphy 2015 Geometrie Automatische, nachträgliche Prüfung von Daten zur Hellerstein 20 Fehleridentifikation (2008) Swierstra und 21 Automatische Verfolgung von Versionen Löh (2004)

Mitte der 2000er Jahre wurde die aktive Forschung an PDM abgebrochen. Somit finden wissenschaftliche Konzepte ohne technologische Erprobung, wie die von Vielhaber oder Weber, keinen Einzug in die Verwendung von PDM Werkzeugen.

Augenscheinlich werden Data Mining und Maschinelles Lernen als gewinnbringende Möglichkeiten für die zukünftige Datenverarbeitung vorgeschlagen, vergleiche Potentiale 8-10 und 16 in Tabelle 11. PDM Hersteller setzen sich im Rahmen der Weiterentwicklung der Werkzeuge damit auseinander, beispielsweise Fa. CONTACT oder Fa. Siemens DI. Limitierend wirkt jedoch die unternehmens-individuelle, manuelle Abstimmung gängiger Algorithmen auf vorliegende Daten (Bunzel 2013, S. 46) (Dekhtiar 2018, S. 240). Über den aktuellen Stand der Forschung hinaus sind demnach für die Produktdatenverwaltung generisch anwendbare Regeln zu suchen oder die Algorithmen so zu erweitern, dass ein semantisches Verständnis der Zusammenhänge ohne menschliche Interaktion erfolgen kann.

3 Studie zur effizienten Produktdatenverwaltung

Aus der theoretischen Betrachtung der Dimensionen und Methoden sowie den aktuellen Funktionen von PDM Werkzeugen wurden in Kapitel zwei Gliederungen und Varianten als relevante Dimensionen herausgearbeitet. Varianten verbleiben in der Studie weitestgehend unbeachtet, denn es wurde bereits in Kapitel zwei deutlich, dass diese aufgrund des steuernden Charakters, der methodischen Vielfalt und aufwändigen Funktion in den PDM Werkzeugen für das automatisierte Konzept zu berücksichtigen sind. Der Untersuchungsgegenstand dieser Studie liegt somit in dem Aufwand zur Verwaltung und der praktischen Verwendung von Gliederungen. Weiterhin werden Sichten thematisiert, da diese bislang in der Forschung keine umfängliche Behandlung erfuhren. Gleichzeitig existieren innerhalb der PDM Werkzeuge gegenwärtig keine Funktionen. Es stellt sich folglich die Frage, ob und in welcher Form Sichten tatsächlich gebraucht werden.

Die Studie untersucht somit die beiden Dimensionen Sichten und Gliederungen. Methodisch basiert sie auf einer qualitativen Inhaltsanalyse nach (Mayring 2010), für die ein Fragebogen erstellt und eine Befragung durchgeführt wird. Diese Methode gibt die Möglichkeit, halboffene Fragen zu stellen, durch die zudem Vorschläge, Kommentare oder Konkretisierungen zu den Inhalten erfasst werden können. Der erste Abschnitt 3.1 detailliert den inhaltlichen Fokus sowie die Durchführung der Befragung. Der folgende Abschnitt 3.2 diskutiert die Ergebnisse und erläutert deren Verwendung im weiteren Verlauf der Arbeit.

3.1 Zielstellung und Durchführung

Im wissenschaftlichen Kontext wird der Aufwand für PDM Verwaltungstätigkeiten kaum thematisiert. Insbesondere die subjektive Wahrnehmung verbleibt offen, denn diese ist insbesondere, neben den Funktionen des Werkzeuges und unternehmensspezifischen Methoden, durch die Bedingungen im Unternehmen sowie die Charakteristika des Produktes geprägt. Die Studie untersucht zunächst, welche der Dimensionen Aufwand verursacht, und welche Funktionen als unpraktisch empfunden werden.

Die Dimension der Sichten wird sowohl durch Funktionen im PDM Werkzeug als auch durch theoretische Methoden vergleichsweise selten betrachtet. Deshalb soll diesbezüglich eine Relevanz bestimmt werden. Da es keine einheitliche Definition gibt, wird den Probanden zu der Befragung nach den Sichten initial die Definition von Sichten, wie in Abschnitt 2.2 hergeleitet, erläutert. Einige Untersuchungen zur Dimension der Gliederungen schlagen vor, ohne Hierarchien zu arbeiten. Hierzu wird untersucht, wie stark Ingenieure sich an den Gliederungen innerhalb der PDM Werkzeuge orientieren. Zusätzlich wird, entsprechend des

3 Studie zur effizienten Produktdatenverwaltung

Untersuchungsgegenstandes, erhoben, wie die Integration von PDM und CAD Werkzeugen empfunden wird und wodurch im Allgemeinen viel Aufwand erzeugt wird. Weiterhin wird die Effizienz der PDM Funktionen untersucht und Verbesserungspotentiale werden ermittelt.

Es wurde ein Fragebogen erstellt, dieser findet sich im Anhang auf Seite I.

Teilnehmer der Studie waren 15 Personen, die in Unternehmen der Branchen Medizintechnik, Automotiv, Luftfahrt und Schiffbau in Betrieben mit mehr als 5000 Mitarbeitern angestellt sind. Die Teilnehmer haben zwischen drei und zehn Jahren Berufserfahrung im PDM Umfeld und arbeiten aktiv mit den Werkzeugen. Die Berufsbilder erstrecken sich von internen Methoden- und Prozessteams, sowohl aus Anwendersicht als auch der IT Sicht, bis hin zu Ingenieuren aus Entwicklungsabteilungen. Eine Übersicht zu den befragten Personen ist in anonymer Form im Anhang auf Seite III, Tabelle 42 beschrieben.

3.2 Ergebnisse und Zwischenfazit

Dieser Abschnitt stellt die Ergebnisse der Befragung dar, und setzt diese in den Kontext der Zielstellung, PDM Werkzeuge zu automatisieren.

Die Befragung fand im Rahmen von Interviews statt, so dass zusätzlich Randbemerkungen notiert und Nachfragen gestellt wurden. Nicht jeder Teilnehmer der Studie beantwortete aufgrund seines Arbeitskontextes alle Fragen. Gleichzeitig sind entsprechend der qualitativen Inhaltsanalyse mehrere Antworten oder Begründungen zulässig. Somit entspricht die Aufsummierung der einzelnen Werte nicht stets der Summe der Teilnehmerzahl.

Die Tabelle 12 zeigt die Ergebnisse zum Zusammenhang zwischen dem Aufwand für die einzelnen Verwaltungsdimensionen und deren praktischer Anwendung in heutigen PDM Werkzeugen. Der Wert nicht zutreffend konnte durch die Befragten gewählt werden, wenn die entsprechende Dimension im Unternehmen nicht verwendet wird.

Tabelle 12: Verwaltungsaufwand der Dimensionen

geringer mäßiger hoher nicht Nr. Aufwand Aufwand Aufwand zutreffend 1 Gliederung 3 5 2 2 2 Status 4 4 3 - 3 Versionen 8 3 - - 4 Sichten - 3 2 7 5 Varianten 2 4 3 3

3 Studie zur effizienten Produktdatenverwaltung

Die Verwaltung der Gliederung wurde als mäßig aufwändig eingeschätzt. Das methodische Konzeptionieren der Gliederung sei aufwändig, die Nutzung dagegen einfach erklärte ein Teilnehmer. Die Antwort wurde als „einfach zu bedienen“ gewertet und entsprechend in der Tabelle wiedergegeben. Ein Teilnehmer gab an, dass das Unternehmen der Automobilbranche für das er arbeitet, keine Gliederungen in PDM Systemen verwaltet, sondern ausschließlich die Baugruppenzugehörigkeit in CAD Werkzeugen. Ein anderer Teilnehmer gab an, dass der Aufwand der Produktgliederung schwer zu beurteilen sei, da die Aufgabe im Konzern auf fünf unterschiedliche Rollen verteilt ist und gleichzeitig Teilautomatismen bestehen.

Das Versionieren in Zeile 3 der Tabelle 12 wird offensichtlich als sehr einfache Tätigkeit betrachtet. Begründet ist dies in der zumeist vorliegenden Verlinkung an die integrierten Workflowmanagementsysteme sowie das quasi-standardisierte Vorgehen der Versionierung in zwei Stufen (Bauteil.A.1) in Kombination mit dem Form-Fit-Funktion Kriterium. Ein Teilnehmer bemerkte, dass die OOTB Versionierung adaptiert wurde, da man diese in der originalen Form als zu umständlich empfunden habe.

Sichten verbleiben in vielen Unternehmen ungenutzt, was Zeile 4 der Tabelle wiedergibt. Sie haben nach Auskunft der Studienteilnehmer die größte Bedeutung beim Übertrag der Daten an die Produktion. 20 % der Unternehmen gaben an, Sichten in ERP Systemen zu erzeugen und bereitzustellen. Deshalb finden sie sich nicht in PDM Werkzeugen wieder. Dies ist auf die Ordnungsbedarfe der Logistik und Produktion, folglich den Unterschied zwischen mBOM, eBOM und Service-BOM zurückzuführen.

Sichten werden nicht in allen Unternehmen explizit verwendet. Partiell wird die Möglichkeit der Strukturbildung verwendet, ebenso können Zugriffsrechte verwendet werden um Sichten zu erzeugen. Mitunter definieren Unternehmen eigene Filtermechanismen für bestimmte Anwendungen. Somit hat sich kein einfaches und einheitliches Vorgehen entwickelt.

Der Aufwand zur Verwaltung von Varianten wurde als hoch eingestuft, was in Zeile 5 beobachtet werden kann. Es besteht der Wunsch nach Vereinfachung der Nutzeroberfläche, was von zwei Teilnehmern geäußert wurde, die mit Siemens Teamcenter arbeiten.

Ergänzend dazu können für die Dimension der Gliederungen folgende weiterführende Beobachtungen festgehalten werden. Die Ordnungskriterien wurden von 54 % der Teilnehmer der Umfrage als relevant eingeschätzt. Die Inhalte und Begründungen dafür, warum

3 Studie zur effizienten Produktdatenverwaltung

Gliederungen einer bestimmten Form folgen, findet sich unternehmens- und produktbedingt in unterschiedlichen Formen, beispielsweise:

• Arbeitsorganisation zwischen Abteilungen innerhalb des Engineerings aber auch firmenweit, • die inhaltliche Erfüllung von Meilensteinen wird an bestimmten Knoten und deren zugehörigen Design Artefakten festgemacht, • Auftragsbücher, die gegenüber dem Kunden relevant sind, • Pflichtenhefte aus dem Produktmanagement, dem Einkauf, oder der Projektleitung, • den Bedarfen der Produktion und Stücklisten in ERP Systemen.

Die Verwendung der Gliederung findet demnach mittlerweile, entgegen der Beschreibung von (van den Hamer und Lepoeter 1996), jenseits des Engineerings statt. Die Vorgaben zur Gliederungen der Produkte entstammen nicht dem Engineering.

Eine gute Vorbereitung der Gliederung ist nach Einschätzung von 62 % der Unternehmen relevant für die einfache Zuordnung der Daten zu dieser übergeordneten Gliederung um eine gute Datenqualität zu erreichen. 70 % der Teilnehmer erklären gleichzeitig, dass es in ihrem Unternehmen keine einfache Erklärung oder kein durchgängiges Verständnis von Produktstrukturen gebe.

80 % der Teilnehmer bestätigten, dass die Produktgliederungen über der Zeit stabil bleiben, und ebenso sehen die meisten Teilnehmer in etwaigen Änderungen keine großen Schwierigkeiten.

Wenn Unternehmen Sichten verwenden, so werden sie diese in der Regel durch die Anwender selbst zusammengestellt. Die hoch eingeschätzten Aufwände hinsichtlich der Erstellung von Sichten, die in Tabelle 12 deutlich werden, wurden damit begründet, dass sowohl eine methodische Konsolidierung der darzustellenden Inhalte als auch eine technische Umsetzung erforderlich sei. Wesentliche Unklarheiten bestünden darin, welche Informationsinhalte wann und wie an wen zur Verfügung gestellt werden. Die Pluralität der Dateitypen und die diversen Rollen wurden als kritische Elemente benannt.

Die Integration zwischen CAD und PDM Werkzeugen wird von allen Teilnehmern der Studie als nicht arbeitseinschränkend beurteilt. Dagegen wird mehrfach explizit die Datenübergabe in Richtung der ERP Systeme, beziehungsweise der Produktionsstücklistenverwaltung, als arbeitsintensiv beschrieben.

Als generell irrelevante oder ineffiziente Tätigkeiten wurden die folgenden benannt:

1. Die Datenübertragung derselben Information zwischen unterschiedlichen Systemen, die teilweise manuell erfolgt. Als wesentlich und arbeitsaufwändig wurde die

3 Studie zur effizienten Produktdatenverwaltung

Informationsweitergabe zwischen Konstruktions- oder Entwicklungsingenieur und Stücklistenverwalter in diesem Zusammenhang von fünf Teilnehmern der Umfrage benannt. Ebenso wurde die manuelle Befüllung von Attributen mit Metadaten von drei Teilnehmern benannt. 2. Das Suchen von gleichen oder ähnlichen Teilen wurde von 30 % der Teilnehmer benannt. Die Suche nach Informationen innerhalb der PDM Werkzeuge wurde ebenso von etwa 30 % der Teilnehmer als nicht nutzerfreundlich benannt. 3. Zudem erscheint 20 % der PDM Nutzer das Generieren von speziellen Listen für Logistik, Fertigung oder andere Domänen als ineffizient.

Die Teilnehmer sehen die Integration zwischen CAD und PDM Werkzeug als arbeitsunterstützend und effektiv an.

Zwischenfazit

Die Dimensionen Versionierung und Status wurden als wenig aufwändig und von den Unternehmen beherrscht bestätigt. Das entspricht somit den Vorarbeiten, die in Kapitel zwei getätigt wurden. Die Dimensionen finden deshalb in der weiteren Forschung keine Berücksichtigung.

Varianten wurden als Dimension mit hohem Verwaltungsaufwand bestätigt. Die Anwendbarkeit von Oberflächen zur Verwaltung von Varianten wurde als störend benannt. Dieser Punkt soll im Konzept und in der Umsetzung berücksichtigt werden.

Die Nutzung von Produktgliederungen wird mehrheitlich als erforderlich betrachtet. Jedoch liegt die Gliederungs-Information mehrfach vor, unter anderem in Dokumenten, die wesentlich über die Grenzen des Engineerings hinausgehen. Somit soll in dem zu erstellenden Automatisierungskonzept die Gliederung als bestehendes Dokument zur Verfügung gestellt werden und durch Ingenieure referenziert werden. Entwicklungs- oder Konstruktionsingenieure verwenden Gliederungen in der Regel informativ, sind allerdings für gewöhnlich mit der Dokumentation beauftragt. Diese Dokumentation soll durch die vorgegebene Gliederung und eine automatisierte Zuweisung der Design Artefakte vereinfacht werden.

Sichten werden dann effizient von den Unternehmen genutzt, wenn diese durch die Anwender selbst konfiguriert werden. So wird zudem in dem zu erstellenden Automatisierungskonzept für zukünftige PDM von einer manuellen Einstellung durch den jeweiligen Datenkonsumenten ausgegangen. Weitere Forschung könnte erarbeiten, ob ein branchenübergreifender Standard für Sichten (etwa für einen Transfer zwischen der eBOM und mBOM) existiert. Findet man diesen Standard, so wäre auch eine Automatisierung der Schnittstelle denkbar.

4 Konzept für effiziente Produktdatenverwaltung

Dieses Kapitel synthetisiert die Forschungslücke aus den vorstehenden Kapiteln und entwickelt, zusammen mit den theoretischen und praktischen Grundlagen, das Zielbild für eine zukünftige effektive Produktdatenverwaltung. Entsprechend der in Kapitel zwei festgestellten Abhängigkeit von Methoden und Funktionen auf den Aufwand der Produktdatenverwaltung sollen Automatisierung und Algorithmen in ein PDM Werkzeug integriert werden. Die erforderliche Nutzerinteraktion wird im Konzept erarbeitet. Gemeinsam dienen die Zielstellung der Arbeit und das Konzept als Ausgangspunkt für die praktische Umsetzung und deren Validierung, was in Abbildung 4 Kapitelstruktur auf Seite 7 visualisiert wird.

Die übergeordnete Zielstellung dieser Arbeit verfolgt den Ansatz, die Effizienz der Produktdatenverwaltung zu verbessern. Daraus ergeben sich zwei Möglichkeiten zur Veränderung an den Werkzeugen. Einerseits können bestehende Funktionen diskutiert und verbessert werden. Dieser Weg wird durch die PDM Werkzeughersteller intrinsisch motiviert verfolgt, wobei bestehende Funktionen in der Regel erweitert und aufwändiger werden. Andererseits können Funktionsweisen grundlegend neu gedacht werden, in einer Form, die etablierte Methoden und Grundprinzipien des Engineerings weiterhin unterstützt. Diese Möglichkeit soll hier, auf Basis der bereits erarbeiteten Bedarfe entsprechend der Tabelle 2 auf Seite 13, Tabelle 3 auf Seite 19, Tabelle 7 auf Seite 28 sowie Tabelle 11 auf Seite 39 verfolgt werden.

4.1 Stufenmodell der Automatisierung

Dieser Abschnitt stellt ein Stufenmodell der Automatisierung sowie eine Verortung von darin bestehenden Algorithmen vor. Dieses Stufenmodell dient im späteren Verlauf zur Bewertung und Einschätzung der Reichweite der Automatisierung von PDM Werkzeugen.

Die Automatisierungstechnik definiert technische Prozesse, wie es in Abbildung 10 durch (Lauber 1976, S. 15) dargestellt wurde. Ein technischer Prozess des PDM ist beispielsweise das Erzeugen einer Stückliste, bei der gewisse Filterparameter zu Beginn gesetzt werden und als Ergebnis eine Liste in einem gewissen Format exportiert wird. Für die nachfolgende Konzeption der Automatisierung werden demnach bestehende in neue technische Prozesse - folglich PDM Funktionalitäten mit adaptiertem Zuschnitt - überführt.

Eine Fragestellung der Automatisierung der Produktdatenverwaltung besteht in dem geringen Grad standardisierter Aufgaben. Einzig normative Vorgaben, beispielsweise bezüglich des Nachweises funktionaler Sicherheit, Dokumentation von Inhaltsstoffen oder Bestandteilen oder dem Nachweis bestimmter Herstellungsverfahren oder Qualitäts- und Lieferzustände,

4 Konzept für effiziente Produktdatenverwaltung prägen einige Vorgaben zur Verwaltung, Lagerung und Verantwortlichkeit der Produktdaten. Diese normativen Vorgaben lassen den Unternehmen jedoch bewusst Möglichkeiten zur Gestaltung ihrer Vorgehensweise, die sich branchenübergreifend heterogen ausprägen. Die zu bildenden technischen Prozesse müssen hinreichend generisch oder flexibel sein, um die Individualität abzubilden. Weiter müssen sie gleichermaßen umfassend genug sein, um entsprechende manuelle Tätigkeiten zu ersetzen.

Abbildung 10: Technischer Prozesse in der Automatisierungstechnik nach Lauber

Der Umfang der neuen Funktionen und Aufgaben wird entlang der Bedarfe von Ingenieuren im Abschnitt 4.2.2 festgelegt. Darüber hinaus ist eine industriell taugliche Robustheit und Verlässlichkeit im Rahmen der Automatisierung zu etablieren. Diese wird konzeptionell diskutiert und in der exemplarischen Umsetzung in Kapitel fünf im Rahmen der Umsetzbarkeit in den Demonstratoren berücksichtigt.

Die Automatisierung wird durch den Begriff von autonomen technischen Systemen in einer gesteigerten Form ergänzt. Maurer et al. definieren für das autonome Fahren, dass eine „Selbstbestimmung im Rahmen eines übergeordneten (Sitten)-Gesetzes“ (Maurer et al. 2015) ermöglicht wird. Diese inkludiert zudem eigenständige Entscheidungen von Problemklassen mit mehreren Lösungsmöglichkeiten und sieht damit eine gewisse systemeigene Intelligenz oder auch mehrere Lösungswege vor. Mayer und Pantförder weisen hinsichtlich autonomer Systeme darauf hin, dass im Unterschied zur regelbasierten Automatisierung „der Mensch im Falle von unbekannten Störungen unter Umständen nicht mehr geeignet auf einen Fehlerfall reagieren“ (Mayer und Pantförder 2014) kann. Bei der Übertragung auf die technischen Prozesse der Datenverwaltung stellt sich somit die Frage, für welche Zielstellungen eine vollständige Nachvollziehbarkeit oder Abschätzung der Konsequenzen der Datenverwaltung erforderlich ist. Dies wird im Abschnitt 4.2.2 für die einzelnen Bedarfe der Produkt- datenverwaltung diskutiert und festgelegt.

4 Konzept für effiziente Produktdatenverwaltung

Die Künstliche Intelligenz hat sich nach Rich zum Ziel gesetzt „Computer Dinge tun zu lassen, bei denen aktuell Menschen besser sind“ (Rich 1983). Dazu werden Algorithmen und Methoden erstellt, die den Computer befähigen, eigenständig Aufgaben zu lösen, die nicht eindeutig schließbar sind und eine Interpretation des Kontexts oder eine Adaption im Laufe der Zeit erfordern. Insbesondere die Lernenden Systeme der Künstlichen Intelligenz nehmen eine breite Spanne zwischen der Reproduktion von vorgegebenen Mustern bis hin zum eigenständigen, induktiven Erkennen und Anwenden der neu verstandenen Zusammenhänge ein (Herrmann 1997, S. 16). Die Lösungen der Künstlichen Intelligenz können folglich für Problemklassen mit Entscheidungsfindung verwendet werden und somit technische Prozesse in Richtung der Autonomie verschieben. Die Abbildung 11 stellt die oben diskutierten Automatisierungsstufen in Beziehung zueinander. Dabei sind drei Dimensionen relevant für die Beurteilung: • erstens die Intelligenz des verwendeten Algorithmus mit einer Skala von I1- I3, • zweitens die Komplexität der Aufgabenstellung mit einer Skala von K1- K2 und • drittens die zu erzielende Eigenständigkeit des Systems mit einer Skala von G1-G3. Diese drei Dimensionen werden für die Beurteilung jeweils für eine konkrete technische Umsetzung eines technischen Prozesses betrachtet. Es ergibt sich ein Punkt im Raum mit entsprechenden Koordinaten. Von einem autonomen System wird innerhalb der Grenzen G3, K2, I2-3 gesprochen, was der blaue Punkt 7 in der Abbildung 11 veranschaulicht. Das autonome System ist demnach in der Lage, Lösungen für eine Problemstellung mit mehreren Lösungsmöglichkeiten zu finden, ohne dass ein Mensch eingreift. Die grauen Punkte 1 und 2 in der Abbildung entsprechen der regelbasierten Automatisierung, die mit einer weniger komplexen Aufgabenstellung K1 einhergeht. Die bunten Punkte 3 bis 7 repräsentieren technische Lösungen des maschinellen Lernens, die für unterschiedlich komplexe Fragestellungen verwendet werden können. Die Größe der Punkte zeigt die Flexibilität der möglichen methodischen Lösungen und deren Mächtigkeit an. Regelbasierte Prozesse werden in einer konkreten Weise programmiert und erbringen eine sehr konkrete Lösung zu dem Problem, insbesondere adaptive Verfahren können Lösungen für initial unbekannte Fragestellungen eigenständig erlernen. Die Punkte sind somit als nicht ausschließliche technische Lösungsmöglichkeit für technische Prozesse zu verstehen, Lösungskonzepte können alternativ verwendet werden, wie etwa zwischen den Punkten 4 bis 6. Ein Beispiel für einen regelbasierten Prozess in Nr.1 ist die automatische Befüllung von Metadaten aus Autoren Werkzeugen, indem ein Attribut aus einem Autoren Werkzeug in ein PDM Werkzeug übertragen wird. Der vollständig regelbasierte Prozess kennzeichnet sich dadurch aus, dass alle Teilschritte des Prozesses durch den Computer erledigt werden, was mit Hilfe von Nr. 2 in der Abbildung 11 ersichtlich wird. Ein Beispiel bieten Workflowprozesse,

4 Konzept für effiziente Produktdatenverwaltung die mehrere Lösungswege zu einem Ziel vereinen. Die Workflowprozesse sind derart transparent gestaltet, dass sie dem Anwender die Gelegenheit geben, im eigenen Tempo Informationen nachzuvollziehen und zu manipulieren. Somit ist eine Nachvollziehbarkeit und Intervention, anders als in einem autonomen System, durch den Anwender gegeben.

Abbildung 11: Automatisierungslevel, eigene Darstellung

Der Punkt 3, der auswendig gelerntes Wissen repräsentiert, ist mit Anspruch auf Vollständigkeit gemäß (Herrmann 1997, S. 17) aufgezählt. Es wird davon ausgegangen, dass gespeicherte Information mit auswendig gelerntem Wissen gleichzusetzen ist. Da 100 % der Information vor der Abfrage vorliegen müssen und keine Interpretation möglich ist, ist von

4 Konzept für effiziente Produktdatenverwaltung einem erhöhten manuellen Aufwand gegenüber dem regelbasierten auszugehen. Die Punkte 4-6 zeichnen sich dadurch aus, dass aufgezeigte Muster in Beziehung zu bestehenden Mustern gesetzt werden und diese ggf. erweitert werden. So könnte mit unterschiedlichen Verfahren die Klasse aller Teile für eine bestimmte Fahrzeugvariante erweitert werden. Die Definition der Punkte 4-6 kann mit (Ertel 2016, S. 10–15) ergänzt werden, der die Adaptionsgeschwindigkeit der Lernprozesse als weiteres Kriterium anlegt. Entsprechend den konkret zugrundeliegenden Verfahren und Anwendungsfällen verändert sich der manuelle Aufwand. (Ertel 2016, S. 16) klassifiziert maschinelle Lernverfahren zusätzlich in Richtung der Lösungsfindung, wobei einige lediglich bei präzisen Eingaben eine Lösung hervorbringen können, andere hingegen Lösungen unsicher schließen können – demnach schlagen sie Ergebnisse mit gewissen Prozentsätzen an Korrektheit als Lösung vor. Aufgrund seiner Bezeichnung und der Metadaten der Vorgängerversion oder auch bestimmter geometrischer, charakteristischer Merkmale (CM), könnte das System beispielsweise vorschlagen, dass das Material eines Bauteils zu 80 % aus einem bestimmten Gusseisen besteht. Die Person, die eine bestimmte Funktion etabliert und trainiert hat, kann die Reaktion direkt interpretieren. Dritte erlernen die Handlungsweise erst nach längerer Verwendung. (Herrmann 1997, S. 21) gibt zu bedenken, dass die systemisch gegebene Unterstützung von dem Anwender verstanden werden muss.

Der intelligente Prozess Nr. 7 repräsentiert die höchste Stufe des maschinellen Lernens, da Muster und Zusammenhänge ohne Lehrer erfasst werden. Damit ist er sehr wirksam hinsichtlich der Autonomie, da er einen erweiterten Kontext selbstständig interpretiert. Dennoch ist zu beachten, dass auch dieses System Grenzen hat. Liegen beispielsweise Beschlüsse zur Erweiterung des Produktportfolios mündlich oder in Form von E-Mails vor, hat das System gegebenenfalls keinen Zugriff darauf und kann keine Bewertungen schließen.

Die Verwendung der vorgestellten Verfahren entscheidet über den tatsächlichen Grad der Automatisierung. Tatsächlich können sowohl regelbasierte Algorithmen als auch intelligente Algorithmen als Vorschlagssystem oder die errechnete Lösung als eigenständige Handlungsgrundlage verwendet werden.

(Herrmann 1997, S. 6–10) definiert einen Lebenszyklus für die Verwendung von Wissen. Er weist darauf hin, dass Wissen heuristisch und fehlerbehaftet, unvollständig sowie im Verlauf der Zeit veränderbar sein kann. Im Kontext der Produktdatenverwaltung kann sich ein Variantenkatalog erweitern, beispielsweise, weil Kundenwünsche oder gesetzliche Rand- bedingungen zusätzlich beachtet werden müssen.

Für die Umsetzung im Automatisierungskonzept werden die Ingenieursbedarfe und technischen Prozesse der Datenverwaltung im nachfolgenden Abschnitt im Spannungsdreieck

4 Konzept für effiziente Produktdatenverwaltung zwischen Entlastung, Nachvollziehbarkeit sowie technischer Realisierbarkeit der Lösung interpretiert.

4.2 Ableitung der Bedarfe und Potentiale in ein Konzept

Der vorliegende Abschnitt stellt ein Konzept für automatisiertes PDM auf Basis der Bedarfe und Potentiale, gemäß ihrer Erarbeitung in den vorstehenden Kapiteln zwei und drei, vor. Dabei werden der Grad der Automatisierung und die Intelligenz des Werkzeugs entsprechend des Abschnitts 4.1 sowie das Zusammenwirken zwischen Mensch und Werkzeug und den jeweiligen Aufgaben betrachtet. Leitplanken setzen dabei die Forderungen nach Robustheit und Einfachheit in der Bedienung und Anwendung.

Wesentliche Aufgaben der Datenverwaltung bestehen in der Ablage und dem Persistieren der Design Artefakte sowie deren Verlinkung zu anderen Design Artefakten, wie in Abschnitt 2.3 aufgezeigt wurde. Diese Aufgaben werden zukünftig maßgeblich durch das automatisierte PDM übernommen, was aus der Abbildung 12 hervorgeht. Dabei werden „gehört-zu“ Verbindungen, beispielsweise die Strukturierung, Modularisierung, Systemzugehörigkeit oder Konfigurationsumfänge, entsprechend der tatsächlich vorhandenen Bedarfe unabhängig voneinander verwaltet. Dies ist als blaue Linien innerhalb der ovalen Kreise in der Abbildung 12 illustriert. Es gibt folgend nicht den einen hierarchischen Zusammenhang, in dem die unterschiedlichen Bedarfe gemeinsam abgebildet werden, was in den Ausarbeitungen in Abschnitt 2.3.1 zu erkennen ist. Damit das System die Aufgaben der Verlinkung und Speicherung sinnhaft erledigen kann, übernimmt das automatische PDM bekannte Zusammenhänge aus den Autoren Werkzeugen. Weiterhin übergibt der Ingenieur zusätzlich zu den Design Artefakten ihm bekannte Angaben, beispielsweise hinsichtlich der Verwendung im Kontext.

Das Konzept sieht vor, dass Ingenieure nicht in der Datenverwaltungsumgebung arbeiten, sondern durch die Such- und Anzeigeumgebung bzw. die Autoren Systeme auf das System zugreifen, was die Abbildung 12 verdeutlicht. Das InADM agiert somit ähnlich einer Middleware ohne eigene Nutzeroberfläche. Die neue Umgebung für Produktdatenverwaltung ist durch Automatismen und das Arbeiten im Hintergrund charakterisiert und wird im weiteren Verlauf als „InADM“- „Invisible and Automated Data Management“ bezeichnet. Die Datenmanipulation erfolgt immer über das Autorenwerkzeug, in der Regel im Verlauf der Erstellung der Design Artefakte. Aus der Such- und Anzeigeumgebung - Search & Browse, in der Abbildung 12 - werden Nutzer bei der Suche unterstützt. Aktive Aufgaben der Produktdatenverwaltung werden aus dieser Umgebung nicht unterstützt. Heutige Anwender in PDM Werkzeugen werden oft mit einem großen Funktionsumfang konfrontiert, wobei sie die Produktdaten lediglich konsultieren möchten. Die Search & Browse Umgebung bietet diesbezüglich eine

4 Konzept für effiziente Produktdatenverwaltung

Umgebung an. Die Umgebung wird auch als Enterprise Search bezeichnet, da ein Zugriff auf weitere Datenquellen, wie etwa bei (Kassner et al. 2015), leicht denkbar ist. Weitere anhängende Prozesse, wie beispielsweise die Freigabe von Design Artefakten, werden ebenso in der Search& Browse oder Autoren Werkzeuge zugänglich gemacht.

Abbildung 12: InADM Konzept

Entsprechend der Abbildung 12 übergibt der Anwender die Design Artefakte. Es erfolgt ein vorbehaltlicher Speicherprozess ohne aktive Mitwirkung des Nutzers. (Swierstra und Löh 2014, S. 44) folgend, ist dabei unerheblich, ob die Dateien an genau einem zentralen Ort abgelegt oder lediglich entsprechend referenziert werden. Somit verbleibt der konkrete physische Speicherort (Cloud, Server oder verteiltes System) im Rahmen des Konzepts unspezifisch.

Die Abbildung 12 zeigt im unteren Teil eine Prüfliste. Diese Prüfliste nimmt Rückmeldungen einer internen Plausibilisierung auf, welche periodisch Unstimmigkeiten im Datenbestand eruiert. Auf dieser Basis werden mögliche Korrekturen durch das Werkzeug vorgeschlagen und einem Anwender zur Verfügung gestellt (siehe Anfrage zur Modifikation).

Die Referenzliste im oberen Teil der Abbildung 12 speichert Informationen, beispielsweise zum Aufbau von Modulen, Varianten oder Funktionen des Produkts. Diese dienen als Referenz für die Strukturierung der Produktdaten. Die Referenzliste wird bewusst nicht automatisiert erstellt, sondern entsteht im Zuge des Diskurses im Unternehmen. Am Beispiel von Funktionen oder Baukästen, die in der Referenzliste abgelegt werden, wird ersichtlich,

4 Konzept für effiziente Produktdatenverwaltung dass eine solide Abstimmung, beispielsweise zum Umfang, die spätere Befüllung unterstützt. In das InADM werden Referenzlisten als fertige Dateien in Form einer Liste oder eines Modells übergeben.

Metadaten werden gegenwärtig aufwendig verwaltet, wie in den Abschnitten 2.1 sowie 3.2 herausgearbeitet wurde. Das Konzept verzichtet auf Metadaten und Attribute an Items, die durch Anwender manipulierbar sind. Somit werden neben den Design Artefakten und den „gehört-zu“ Verbindungen zusätzliche Informationen mit steuerndem Charakter abgelegt, die sich nicht in den Autoren Werkzeugen befinden.

Um zu verhindern, dass Design Artefakte mehrfach abgelegt werden, prüft das InADM bei jeder Datenübergabe, ob das jeweilige Design Artefakt bereits in der Datenbank existiert (Funktion 1). Dazu wird der Dateiinhalt verglichen, etwa nach einem Schema wie es Dekhtiar oder Neumann12 vorschlagen. Der Grad der Automatisierung in einer später zu realisierenden Anwendung ist als intelligentes Vorschlagswesen einzustufen (G2, K1, I2, entsprechend Abbildung 11). Der Prozess startet und operiert ohne Einfluss des Anwenders, die Entscheidung des Werkzeugs kann nicht manuell aufgehoben werden. Der Anwender bekommt bei negativer Einschätzung einen Hinweis auf ein zu verwendendes alternatives Design Artefakt.

Tabelle 13 stellt Paradigmen zusammen, die die Datenverwaltung mit dem InADM prägen. Entscheidungen zur konkreten Umsetzung in Funktionen nehmen im späteren Verlauf Bezug dazu.

Das Paradigma 1 für die Datenverwaltung mit dem InADM besagt, dass die Speicherung eines Design Artefakts in der Verantwortung desjenigen liegt, der das Design Artefakt erstellt. Die operative Umsetzung erfolgt somit durch den Ersteller des Design Artefakts unterstützt durch das InADM. Die Design Artefakte und ihre Metadaten werden zum Zeitpunkt ihrer Entstehung abgelegt.

Ein weiteres Paradigma 2 ist das der starken, steuernden Information. Dahinter verbirgt sich, dass steuernde Informationen gegenüber rein informierenden priorisiert werden. Steuernde Informationen müssen stets korrekt sein, um keine zusätzlichen Kosten in nachfolgenden industriellen Prozessen zu verursachen. Dies wird beispielsweise für Variantenangaben deutlich, die verwendet werden, um Produktionsstücklisten auszuleiten und damit Bestellung und Lagerung von Bauteilen oder Materialien auslösen. Daraus folgt, dass diese steuernden Informationen innerhalb des InADM plausibilisiert und bei Bedarf an die Prüfliste gemeldet

12 Siehe auch: Abschnitt 2.4.3, Potential 20, geometrischer Ähnlichkeitsvergleich.

4 Konzept für effiziente Produktdatenverwaltung werden. Veränderungen der Verlinkungen finden, entsprechend der methodischen Vorgabe, durch die Verantwortung beim Ersteller der Daten ebenso in seinem Autoren Werkzeug statt.

Tabelle 13: Paradigmen der Datenverwaltung im InADM

Nr. Paradigma 1 Die Datenerzeuger sind für die Ablage der Daten verantwortlich.

2 Die automatisierte Datenverwaltung priorisiert steuernde Informationen als Basis der Produktdatenverwaltung. Konzeptionelle und steuernde Informationen werden durch Unternehmen 3 bereitgestellt. 4 Operative Verwaltungsaufgaben werden durch das InADM übernommen. Design Artefakte werden ausschließlich mit „gehört-zu“ Verbindungen zu 5 anderen Informationen verknüpft.

Das Paradigma 3 besagt, dass konzeptuelle und steuernde Vorgaben dem System zur Verfügung gestellt werden. Diese steuernden Informationen werden beispielsweise durch einen verantwortlichen Product Manager, Systems Architect oder Chief Engineer zur Verfügung gestellt. Für die steuernden und konzeptionellen Daten und Informationen sind aus konzeptionierender Sicht für das InADM keine bestimmten Formate, sondern die Informa- tionen selbst erforderlich. Im Sinne eines modellbasierten Ansatzes sind Modelle, die wünschenswerte Darbietungsform. Die abgelegten Modelle unterliegen einer Versionskontrolle und benötigen dafür eine methodische Unterstützung.

Das Paradigma 4 „Operative Verwaltungsaufgaben werden durch das InADM übernommen.“ zielt darauf ab, die manuellen Tätigkeiten der Produktdatenverwaltung durch erlernte und definierte Regeln durch das Werkzeug umzusetzen. Damit soll eine Entlastung des Nutzers erzeugt werden. Es werden alle technischen Prozesse auf eine möglichst weitreichende Automatisierung hin überprüft und Funktionen entsprechend neu zugeschnitten.

Das Paradigma 5 zur ausschließlichen Verwendung von „gehört-zu“ Verlinkungen geht auf die Arbeiten von Vielhaber zurück (siehe Tabelle 11, Potential 17, Tabelle 2, Potential 5). Er sieht Produktdaten als relational miteinander in Beziehung stehende Design Artefakte oder Informationsobjekte ohne eigentliche Hierarchie. Die „gehört-zu“ Verbindung sagt im InADM folglich aus, dass ein Design Artefakt mit einem anderen in Verbindung steht. Die Informationen über die Art und Weise der Erzeugung der Verbindung und über die Art der Verbindung der Design Artefakte oder Informationsobjekte werden auf dem Link abgelegt. Da die Verbindungen, entsprechend dem Paradigma 1, in der Regel automatisch gesetzt werden, erledigt das InADM diese Aufgabe.

4 Konzept für effiziente Produktdatenverwaltung 4.2.1 Architektur des InADM

Der innere Aufbau des InADM ist, analog zu aktuellen PDM Werkzeugen, in vier Ebenen gegliedert (Huang et al. 2004, S. 849), was in der Abbildung 13 ersichtlich wird. Gegenüber bestehenden PDM Werkzeugen verfügt das InADM nicht über eine eigene Nutzerschnittstelle, sondern verwendet einerseits die Autoren Werkzeuge zur Datenbereitstellung und andererseits die Such- und Anzeigeumgebung zur Konsultation und Repräsentation. Für die Autoren Werkzeuge werden dazu Plug-Ins zur Verfügung gestellt, aus welchen sich Produktdatenverwaltungsaufgaben initiieren lassen. Die Verwaltungstätigkeiten werden gegenüber der aktuellen Vorgehensweise entsprechend dem Paradigma 4 vermehrt in die Datenmanipulationsebene verschoben.

Abbildung 13: IT-Architektur Ebenen des InADM

Wie bisher erfüllt die Vernetzungsebene die Funktion der Kommunikation innerhalb oder außerhalb eines Unternehmens. Die bereitgestellten Funktionen in der Ebene der Geschäftsprozesse ändern sich inhaltlich etwa durch die erweiterten Automatismen. Weiterhin finden wie bisher an dieser Stelle Einstellungen durch Administratoren statt. Die Ebene kommuniziert sowohl mit den darüber liegenden Anwenderanfragen als auch mit den darunterliegenden Datenspeichern. Die Ebene der Speicherung erfüllt zudem weiterhin die Funktion der permanenten und sicheren Ablage der Daten. Die Trennung in Nutz- und Metadaten entspricht dem InADM Konzept. Jedoch erwies sich die Ablage der Metadaten in relationalen Datenbanken als unflexibel. Dies wurde durch die festgeschriebenen Relationen sowie den mitunter fest codierten tabellarischen Aufbau innerhalb relationaler Datenbanken bedingt. Eine Manipulation, beispielsweise der Attribute oder eine einfache Generierung von Sichten durch den Nutzer, war lediglich eingeschränkt möglich so wie eine zügige Adaption ohne Eingriffe eines Administrators. Am Beispiel der aktuellen Vorgehensweise zur Extraktion von Stücklisten und nachträglichen manuellen Bearbeitung durch Kopieren, Ein- und Ausblenden, Verändern der Reihenfolge und Vergleichen mit bestehenden Dateien

4 Konzept für effiziente Produktdatenverwaltung verdeutlicht sich die Inflexibilität zur Generierung von Sichten. Das neue IT Konzept sieht daher die Datenablage in Graphdatenbanken vor. Diese sind insbesondere für die Ablage der Metadaten in der Speicher-Ebene zielführend, da hier die Verlinkungen zwischen den Design Artefakten, den Referenzdaten und Ordnung gebenden Strukturen und sich wandelnden Verwendungen abgelegt sind. In Graphdatenbanken lassen sich die Relationen flexibel manipulieren, auch wenn bereits Daten abgelegt sind. (Sauer et al. 2019, S. 405) zeigen, dass sich Graphdatenbanken für die Verwaltung von konventionellen Produktdaten eignen und stellt darüber hinaus das Potential für die Integration weiterer Daten dar. Er weist zudem auf die erhöhte Semantik der Datenbanken hin, die sich aus der verbesserten Kombinatorik weiterer Datenquellen ergibt.

Ein Überblick über die Speicherorte der relevanten Informationen schließt sich in der Tabelle 14 an. Der Speicherort befindet sich in der Speicher - Ebene des Architekturmodells. Diese ist in Nutz- und Metadaten separiert. Die Metadaten teilen sich wiederum in die benannten Referenzobjekte und Daten, die Prüfliste, die übertragenen Metadaten aus den Autoren Werkzeugen sowie die Verlinkungen, die im InADM erzeugt werden auf.

Tabelle 14: Übersicht der zu speichernden Informationen nach Ort

Information Speicherort Auslöser Übergabe durch den Design Artefakt Nutzdaten Anwender Übergabe durch den Steuernde Informationen Referenzobjekte und Daten Anwender Statusangaben Metadaten Workflow Zusammenhang Alt-Neu; automatisch bei der Erstellung des neuen Versionen Verlinkungen Design Artefakts bei Übergabe durch den Anwender Automatisch bei der Verlinkungen Metadaten Erstellung, sowie Nutzereingabe Automatisch bei der Nutzeranfragen Browse und Search Nutzeranfrage Zwischenergebnisse aus Prüfliste Automatisch internen Plausibilisierungen

4.2.2 Funktionen des InADM

Im Folgenden wird das Konzept um die Bedarfe und Möglichkeiten entsprechend der Vorarbeiten der Kapitel zwei und drei ergänzt. Insbesondere derartige Bedarfe, die einen steuernden Charakter aufweisen (siehe Fazit in Kapitel zwei), müssen bei einer späteren Implementierung berücksichtigt werden. Relevant erscheinen aus den obenstehenden

4 Konzept für effiziente Produktdatenverwaltung

Kapiteln die Verwaltung von Varianten, ein Ersatz für die Steuerung durch Metadaten, sowie die Strukturierung der Produktinformationen. Herausgearbeitete Funktionen des Werkzeugs sind im Fließtext mit einer Klammer referenziert (z.B. Funktion 0815). Der nachfolgende Abschnitt 4.2.3 reflektiert die neue Aufgabenteilung zwischen Anwender und Software.

Der grundlegende Bedarf (Nr. 1) der Dokumentation und Versorgung des Engineerings und nachfolgend aktiver Domänen wird als trivial durch die Existenz des Werkzeugs und der angegliederten Browse and Search Umgebung verstanden und verbleibt ohne weitere Aktivitäten bestehen.

Bedarf 2: Identifizieren von Design Artefakten, die unter Konfigurationskontrolle stehen In einer methodischen Vorgabe wird entsprechend Paradigma 3 durch ein Unternehmen festgelegt, welche Design Artefakte unter Konfigurationskontrolle gehören. Dazu gehören zukünftig auch bisher unstrukturiert vorliegende Daten, wie beispielsweise Spezifikationen, E- Mails mit relevanten Abstimmungen oder Testergebnisse, entsprechend dem Vorschlag von Kassner (vgl. Tabelle 11, Potential 16). Für die Gesamtheit der relevanten Design Artefakte, die mit Zusatzinformationen abgelegt werden müssen, wird eine Schnittstelle zum Autoren- werkzeug etabliert.

Die Nummerierung und Benennung der Artefakte erfolgt automatisch (Funktion 2), was die Potentiale 2 und 3 in Tabelle 2 wiedergeben. Anwender müssen mit den Daten interagieren, diese folglich explizit suchen und ansprechen können. Deshalb wird die Benennung aus den Autoren Werkzeugen übernommen, wobei ein Anwender bei der Übergabe Einfluss auf diese Benennung nehmen kann. Technologisch ist die Funktion 2 eine Speicher- und Kopierfunktion, und wird aufgrund der technologischen Einfachheit nicht umgesetzt.

Bei der Vergabe der Nummer sind zwei Fälle zu unterscheiden, erstens die initiale Erzeugung eines Design Artefakts und zweitens die Änderung desselben. Bei der initialen Erzeugung legt das InADM eine freie Nummer fest.

Als Konsequenz der automatisch erstellten, für Menschen nicht einfach interpretierbaren Nummer muss die Suchfunktion einem Enterprise-Search (Funktion 3) entsprechen, was in Abbildung 12 verdeutlicht wird. Das Enterprise Search interpretiert neben der Bezeichnung zusätzlich den Dateiinhalt sowie darüber hinaus die Verlinkungen zwischen den Objekten. Aktuell werden die, in den Autoren Werkzeugen bereits gebildeten oder indirekt über die Benennung bereits vorhandenen, Relationen nicht weiter genutzt. Jedoch soll zukünftig der bestehende Zusammenhang, beispielsweise zwischen CAD zu CAX, mit an das InADM übertragen werden. Dies soll nicht durch die Benennung eines Design Artefakts geschehen, sondern durch die Interpretation der Produktdaten selbst. Hierzu ist der Aspekt der Zugänglichkeit der Daten, wie er durch (Hertwig und Lentes 2019) - entsprechend dem Code

4 Konzept für effiziente Produktdatenverwaltung of PLM Openness (CPO) (Pro Step AG 2014) – gefordert wird, grundlegende Voraussetzung. Auf diese Weise wird eine verbesserte Vernetzung der Produktdaten realisiert.

Eine Steigerung der semantischen Interpretation der Daten wird zusätzlich durch eine Enterprise Search unterstützt, indem diese auf weitere Datenquellen des Unternehmens zugreifen kann, entsprechend der Vorschläge von (Stiefel 2011, S. 42), (Sauer et al. 2019, S. 402) oder (Kehl 2019, S. 355). Von einer Umsetzung wird abgesehen, da es bereits erste Umsetzungen in der Industrie gibt, was in Abschnitt 2.4.1 Thematisierung erfährt.

Bedarf 3: Strukturieren des Produkts in Teilumfänge Teilumfänge, die für ein Produkt gelten sollen, müssen zunächst definiert werden. Die ordnungsgebenden Teilumfänge können etwa ein Modulkatalog, eine Systembeschreibung oder die Ersatzteilversorgung sein, und mit Methoden wie von (Baumberger 2007, S. 100), (Blees 2011, S. 106–108) oder (Glauche 2015, S. 193) beschrieben, gebildet werden. Dabei können im InADM Konzept, je nach Bedarf, mehrere Ordnungskriterien gleichzeitig zur Anwendung gebracht werden. Diese sind unabhängig voneinander, wie es in der Abbildung 14 zu erkennen ist und verfügen über die funktionale Gliederung oben und den Baukasten unten. Damit wird die Trennung unterschiedlicher Bedürfnisse explizit ansprechbar, was in den Potentialen 14 und 15 herausgearbeitet wurde. Beide ordnungsgebenden Strukturen referenzieren auf einen Datenpool aus unterschiedlichen Design Artefakten. Die Abbildung 14 stellt die unterschiedlichen Design Artefakte, also Dokumente, Berechnungen, Simulations- oder Konstruktionsdaten folglichstilisiert als heterogene Menge von Kreisen, Dreiecken oder Rechtecken dar.

Die funktionale Gliederung und die Baukastenlogik, wie sie in Abbildung 14 dargestellt sind, können als Dokument (.PDF etc.) oder Modell (beispielsweise als UML) abgelegt werden. Durch den Nutzer erfolgt eine Kennzeichnung als Referenzobjekt und somit eine entsprechende Ablage. Für beide Arten der Ablage ist bei der technischen Implementierung zu beachten, dass die einzelnen Baukastenelemente oder Funktionen individuell ansprechbar sind.

Die Festlegung der Ordnungskriterien ist wesentlich an interdisziplinäres methodisches Vorgehen sowie Marktwissen gekoppelt, welches sich in der Regel nicht im Verfügungsraum des Produktdatenverwaltungswerkzeugs befindet. Gleichzeitig ist die eigentliche Modellierung oder „schriftliche Fixierung“ der Module oder Systeme in der frühen Phase durch einen vergleichsweise geringen manuellen Aufwand gekennzeichnet. Ein, im interdisziplinären Diskurs erarbeitetes, Ordnungskriterium besteht mit einem gewissen Gewicht. Somit verbleibt die Definition der Module oder Teilsysteme eine menschliche Aktivität. Die Verlinkung von Artefakten zu den Modulen oder Teilsystemen (Funktion 4) soll automatisiert werden. Hierbei gilt weiterhin das bereits beschriebene Paradigma: das Werkzeug erbringt bei der Speicherung

4 Konzept für effiziente Produktdatenverwaltung einen Vorschlag, der durch den Nutzer validiert wird. Das muss insbesondere für alle Fälle gelten, in denen der Teileumfang einen steuernden Charakter aufweist. Der Grad der Automatisierung entspricht einem Vorschlagssystem (G2, K1-2, I2), bei dem ein Anwender einen Vorschlag durch das InADM erhält und diesen bestätigt.

Für die Automatisierung sollen automatische Nummern vergeben werden und die Benennung aus dem Autorenwerkzeug übernommen werden. Information Retrieval, Ontologie und Sprachinterpretation unterstützen die Zuweisung entsprechend der Potentiale 1 und 12. Das Vorschlagsystem verfügt somit durch das semantische Beziehungswissen über eine gewisse Intelligenz. Eine automatisierte Zuweisung wird in Abschnitt 5.1.2 umgesetzt.

Die Übernahme der Design Artefakte erfolgt im InADM Konzept in Form einzelner Modelldateien aus den Autoren Werkzeugen, sodass diese zunächst ungeordnet im InADM persistiert werden (Funktion 5). Damit wird das Potential 9, Verwaltung von Daten ohne Hierarchien, zur Anwendung gebracht. In der Abbildung 14 repräsentieren die gelben Rechtecke, die orangenen Dreiecke und die grauen Kreise exemplarisch unterschiedliche Design Artefakte. Diese weisen keine Beziehung zueinander oder zu Datenbankobjekten auf. Zusammenhänge zwischen Design Artefakten, die bereits in den Autoren Werkzeugen bekannt sind, werden übernommen. In der Abbildung 14 illustrieren die drei verlinkten, grauen Kreisflächen solche übernommenen Zusammenhänge. In der Praxis relevante Beziehungen bestehen beispielsweise aus CAD Assemblies oder aus Simulationen, die auf geometrischen Modellen basieren.

Die Abbildung 14 zeigt weiterhin, dass eine Zuweisung der einzelnen Design Artefakte zu Funktionen besteht und somit eine „gehört-zu“ Information etabliert und verstetigt wird. Die relevant, gespeicherte „gehört-zu“ Information ist durch den Nutzer einsehbar und inkludiert die Grundlage zur Etablierung der Verbindungen. Das Potential 14 unterschiedliche Bedarfe in unterschiedlichen Strukturen ablegen wird zur Anwendung gebracht, indem unterschiedliche Ordnung gebende Strukturen getrennt werden. Die Abbildung 14 zeigt hierzu exemplarisch eine funktionale Gliederung und einen Baukasten, zu denen die Design Artefakte zugewiesen werden.

Um Zuordnungen von Design Artefakten zu Ordnung gebenden Strukturen zu erzeugen, kann ein Unternehmen ein Datenmodell hinterlegen, welches zwischen den Design Artefakten fungieren soll. Dieses kann etwa bestehende Lücken in der aktuellen Datenlage suchen und selbstständig Ergänzungen der Verlinkung vorschlagen13. Als Beispiel hierfür ist denkbar, dass jeder Software eine Hardware zugewiesen sein muss oder dass jeder FEM-Simulation eine

13 Siehe auch die Methode von Conweaver, die nach diesem Prinzip arbeitet.

4 Konzept für effiziente Produktdatenverwaltung

Geometrie zugeordnet ist14. Die Zuordnung soll für Anwender nachvollziehbar bleiben, deshalb wird eine Begründung für die Erstellung der Verlinkung auf ebendieser abgelegt. Die Verlinkung erhält darüber hinaus einen Zeitstempel, sodass zu einem Zeitpunkt geltende „gehört-zu“ Umfänge aktuell oder nachträglich ausgewiesen werden können (siehe Funktion 7).

Abbildung 14: Zuweisung von Design Artefakten zu Produktgliederungen

Die Übergabe der Design Artefakte an das InADM ist in Abbildung 15 dargestellt. Bei dem Informationsaustausch zwischen Autorenwerkzeug und InADM, werden neben dem Design Artefakt zusätzliche Informationen, beispielsweise zur Verwendung mit dem Ordnungs- kriterium, angegeben. In einem nächsten Schritt werden die, in den Nutz- und Metadaten inhärent vorliegenden, Informationen ausgelesen. Sie werden mit den Ordnungskriterien aus dem Bereich der Referenzobjekte und Daten mittels semantischer Technologien in Verbindung gebracht und die zuvor beschriebene „gehört-zu“ Verlinkung wird etabliert.

Die funktionale Gliederung, die als Referenzobjekt abgelegt ist, ist einer Versionierung unterstellt. Die Versionierung wird für eine eventbasierte Plausibilisierung der Verlinkungen verwendet (Funktion 6).

Die Abbildung 15 zeigt im unteren Bildabschnitt zusätzlich ein Modul zur Plausibilisierung der Gliederung. Dafür ist vorgesehen, dass die abgelegten Daten durch das InADM, ohne menschliche Intervention, auf die eigene Konsistenz geprüft werden. Werden bei dieser Prüfung Unregelmäßigkeiten festgestellt, erfolgt eine Übermittlung an die Prüfliste, die folgend

14 Das entsprechende Datenmodell ohne automatische Befüllung ist in heutigen PDM Werkzeugen bereits hinterlegt.

4 Konzept für effiziente Produktdatenverwaltung weiter an den Nutzer geht. Dieser kann aus dem Autoren Werkzeug heraus die bestehende „gehört- zu“ Verbindung bestätigen oder adaptieren.

Abbildung 15: Übergabe von Design Artefakten und Zuweisung zu einer Gliederung

Bedarf 4: Verwenden von Teilumfängen als Unterstützung während der Konstruktion und Entwicklung

Für eine Nutzung der Teilumfänge ist eine Visualisierung (Funktion 8) der referenzierten Design Artefakte in der Browse und Search Umgebung verfügbar (siehe Abbildung 16).

Durch die Angabe von Filterparametern stellt der Anwender eine Datenbankanfrage an das InADM. Dieses durchsucht, entsprechend der Anfrage, die Referenzobjekte und zudem die Nutz- und Metadaten. Entsprechend der Anfrage des Anwenders werden die Daten in einer, der Anfragesituation entsprechenden, Struktur dargestellt. Werden folglich Fertigungsmodule angefragt, kann die Visualisierung in einem gozinto-Graph dargestellt sein, für Funktionen oder Systembeschreibung eignet sich etwa ein SysML Blockdiagramm (IBD15).

Der Grad der Automatisierung für die Funktion 8 ist gering, denn es handelt sich um eine Nutzeranfrage sowie reguläre Anzeigefunktionen. Etwaige Aufbereitungen der Struktur erfolgen regelbasiert, beispielweise über die Rolle, mit der ein Nutzer die Anfrage stellt oder darüber, welche Filterparameter er setzt. Diese Arbeit fokussiert sich auf die Dateneingabe in

15 Internal Block Diagram: stellt unterschiedliche Teilsysteme dar.

4 Konzept für effiziente Produktdatenverwaltung das PDM sowie die Manipulation innerhalb dessen. Somit erfolgen keine Untersuchungen zur expliziten und klaren Darstellung unterschiedlicher Sichten.

Abbildung 16: Visualisierung von Strukturen und Zusammenhängen in der Browse und Search Umgebung

Bedarf 5: Etablieren und Ausweisen von Zusammenhängen einzelner Design Artefakte zueinander Transversale Verlinkungen können für, regelmäßig miteinander in Beziehung stehende, Design Artefakte in einem Datenmodell im InADM als Referenzobjekt hinterlegt werden. Ein Beispiel hierzu ist der Zusammenhang zwischen dem physikalischen Design Artefakt und dem virtuellen und realen Testergebnis, die jeweils in einem bestimmten Format vorliegen (siehe Abbildung 17). Das zugehörige Datenmodell wird in diesem Beispiel ergänzt. Dies erfolgt beispielsweise indem zu jeder CAD Datei, welche durch einen grauen Kreis in der Abbildung dargestellt wird, entweder ein virtueller oder in realer Test, welche als gelbe und graue Rechtecke in der Abbildung erscheinen, zugeordnet werden. Eine Voraussetzung, für die Möglichkeit der Verlinkung der Dateien, ist die Ablage im InADM Werkzeug. Für das gegebene Beispiel kann angenommen, dass Testdaten beispielsweise als Bericht in PDF Form abgelegt werden und dann mittels NLP16 Verfahren in maschinenlesbare Inhalte umgewandelt werden.

Die Erzeugung der „gehört-zu“ Verlinkung kann in Anlehnung an das Vorgehen der Software Linked Data, Firma Conweaver erfolgen. Die Leerstellen im Datenmodell werden auf Basis der Dateiformate sowie einem Wissensgraphen17 mit Design Artefakten ergänzt (Funktion 9). Die Wissensgraphen werden dem Werkzeug zu Beginn durch einen Administrator auf Basis von

16 Detaillierte Erklärungen zur Funktionsweise des NLP finden sich in den Abschnitten 5.1 – 5.3. 17 Conweaver referenziert auf Wissensgraphen als semantisches Netz, dieses stellt ein Netz von Begriffen dar. Anders als Ontologien muss es nicht hierarchisch sein.

4 Konzept für effiziente Produktdatenverwaltung

Expertenbefragungen im Unternehmen zur Verfügung gestellt. Der Wissensgraph liegt in der Umgebung der Referenzdaten und Objekte. Die konkrete Zuweisung erfolgt über die Verfolgung der Verbindungen zu den Begriffen, die mit einer Wahrscheinlichkeit bestätigt werden.

Abbildung 17: Etablieren realtionaler Verbindungen

Das Linked Data Werkzeug ist für das Auffinden von Daten und Repräsentieren von Wissen konzipiert. Es basiert auf Verfahren der künstlichen Intelligenz, somit sind nicht permanent zu 100 % korrekte Lösungen zu erwarten. Der Mechanismus wird im InADM als Vorschlagssystem integriert. Der Anwender kann bei der Speicherung des Design Artefakts weitere Hinweise zur Verlinkung übergeben. Ebenso erhält er einen Vorschlag zur transversalen Vernetzung durch das Werkzeug zurück. Die Intelligenz des Mechanismus ist in einem mittleren gehobenen Bereich, was in I2 in der Abbildung 11 in Erscheinung tritt. Die Komplexität der Nutzeranfrage bewegt sich in einem mittleren Level K1-2, abhängig davon, welche konkreten Design Artefakte miteinander in Beziehung gebracht werden sollen. Weiterer Forschungsbedarf besteht zum Zeitpunkt der Entstehung dieser Arbeit in der automatischen Konzeption und Erweiterung des oben beschriebenen Datenmodells und der Wissensgraphen, beispielsweise durch das Einbeziehen von Nutzeranfragen. Die Potentiale 10 und 11, Nutzung von semantischen Netzen18 und Data Mining zur Ermittlung und Ge- wichtung von Relationen werden hier verwendet.

Bedarf 6: Präzises Festhalten und Ausweisen von Produktvarianten In Abschnitt 2.2 wurde der Grundsatz herausgearbeitet, dass Produktvarianten unabhängig von Hierarchien oder anderen Ordnungskriterien erstellt werden können. Es entsteht demnach

18 Wissensgraphen.

4 Konzept für effiziente Produktdatenverwaltung eine weitere, unabhängige „gehört-zu“ Verbindung durch das Verlinken eines Design Artefakts zu einer Variante. Ein Variantenkatalog ist in „Referenzobjekte und Daten“ durch ein Unternehmen abgelegt.

Das Erfassen und Bearbeiten von Produktvarianten beginnt bei der Datenübergabe aus dem Autoren Werkzeug (siehe Abbildung 18). Das InADM verfügt über zwei Funktionen, die gemeinschaftlich Produktvarianten verwalten. Das erste, in der Abbildung obenstehende „Interpretation der Nutzereingabe“ gleicht die natürlich-sprachlichen Eingaben mit dem Variantenkatalog ab (Funktion 10). Bei erfolgreicher Zuweisung eines Design Artefakts zu einer bestimmten Variante wird eine Verbindung initiiert und eine Bestätigung an den Anwender rückgemeldet. Erfolgt keine Verlinkung, so wird dieses ebenfalls an den Nutzer zurückgemeldet. Eine prototypische technische Umsetzung erfolgt in Abschnitt 5.2.

Abbildung 18: Konzept zur Bildung und Verwaltung von Varianten

Der Grad der Automatisierung entspricht einem Umsetzungssystem, welches auf intelligente Mechanismen eines Chat-Bots zurückgreift. Es werden verhältnismäßig einfache Nutzeranfragen an das Werkzeug herangetragen, denn die Auswahl der Variante selbst liegt beim Anwender. Der Nutzen der Unterstützung ergibt sich für den Anwender dadurch, dass er ab sofort natürlich-sprachlich mit der PDM Software interagiert.

Die Variantensteuerung erfolgt im InADM Konzept durch eine direkte Zuordnung des jeweilig anzusprechenden Design Artefakt zur Variante (siehe Abbildung 19). Die Zuordnung der Design Artefakte, die als farbige Rechtecke, Dreiecke und Kreise in der Abbildung 19 schematisch dargestellt sind, erfolgt automatisch auf Basis der Informationen zur Verwendung durch den Anwender bei der Übergabe aus dem Autorenwerkzeug. Die etwaige mehrfache Verwendung erfolgt über entsprechende „gehört-zu“ Verlinkungen zur im Kontext relevanten

4 Konzept für effiziente Produktdatenverwaltung

Variante, vergleiche in Abbildung 19 die Zeiger von den Varianten V4 und V1 auf den gleichen grauen Kreis.

Die Verlinkung der einzelnen Varianten, entsprechend V0 - V5 in Abbildung 19, speichert relevante Informationen des Variantenmanagements, wie etwa Zwangsbedingungen oder den Ausschluss der gemeinsamen Verwendung. Somit können später die Konfigurationen gesteuert werden. Die Anlage dieses Referenzobjekts erfolgt durch den Anwender (siehe Paradigma 1).

Abbildung 19: Verlinkung der Design Artefakte zu Varianten

Das Modul Plausibilisierung der Konfiguration prüft, nach der initialen Verlinkung zu einer Variante, ob die, gemeinschaftlich der Variante zugeordneten, Design Artefakte inhaltlich zueinander passen (Funktion 11). Diese Funktion wird in Abschnitt 5.2.3 implementiert. Entsprechend der Automatisierungslevel aus Abbildung 11 wird die Funktion wird als vollständig automatisiert (G3) eingeschätzt, da sie turnusgemäß ausgelöst wird und im Rahmen des vom Menschen gegebenen Normativs der Variantenreferenzen und Prüflisten eigenständig agiert. Die tatsächliche Umsetzung erfolgt durch den Vergleich relevanter Geometrien und ist damit wenig intelligent (I1), die Fragestellung entspricht einer Klassifikationsaufgabe mit wenig Interpretationsspielraum (K1).

Das Modul Plausibilisierung von Konfigurationen (siehe Abbildung 18) besteht aus zwei Teilen. Der erste Teil analysiert Konfigurationen gesamter Produkte, indem er Metadaten aktueller und bestehender Varianten miteinander vergleicht (Funktion 12). Die entsprechende Umsetzung mittels statistisch arbeitender, lernender Algorithmen findet sich in Abschnitt 5.4. Ermittelte Auffälligkeiten werden in der „Prüfliste“ abgelegt und dem Ersteller der Daten übermittelt (Funktion 13). Der Automatisierungsgrad ist hoch, denn das System arbeitet zunächst ohne Nutzerinteraktion. Da lernende Algorithmen verwendet werden, verfügt es über

4 Konzept für effiziente Produktdatenverwaltung eine gewisse, mittelhohe Intelligenz. Die Komplexität der Fragestellung entspricht einer Klassifikationsaufgabe, es gibt in der Regel eine geltende binäre Antwort.

Der zweite Teil der Plausibilisierung von Konfigurationen (siehe Abbildung 18) analysiert den inhärenten Dateiinhalt auf Plausibilität. Ermittelte Auffälligkeiten werden in der „Prüfliste“ abgelegt und dem Ersteller der Daten übermittelt. Eine technologische Umsetzung findet sich in 5.3 für geometrische Daten. Der Automatisierungsgrad ist hoch, denn das System arbeitet zunächst ohne Nutzerinteraktion. Der Algorithmus arbeitet auf Basis objektorientierter Programmierung und ist somit nicht intelligent. Die Komplexität der Fragestellung entspricht einer Klassifikationsaufgabe, es gibt in der Regel eine geltende binäre Antwort.

In der Beschreibung der Abhängigkeiten der Dimensionen wird gefordert, dass innerhalb einer Variante der Zusammenhang von alternativen Teilen anzugeben ist. Eine Verlinkung wird wiederum als unabhängige „gehört-zu“ Verbindung etabliert. Die Verlinkung soll beim Anlegen einer Version eines Bauteils mit erfragt werden. Für die Browse und Search Umgebung ergibt sich die Anforderung, dass mehrere Parameter und Filter, entsprechend aktueller Filtermöglichkeiten, zu oder abgeschaltet werden können.

Für das Ergebnis der Konfigurationen muss einerseits eine Nachvollziehbarkeit und andererseits eine entsprechende industrietaugliche Präzision gewährleistet bleiben. Die technischen Umsetzungen in den Abschnitten 5.2- 5.4 dienen als Grundlage, um erste Aussagen bezüglich Präzision und Geschwindigkeit des Systems zu treffen.

Bedarf 7: Anzeigen von Unterschieden zwischen Produktvarianten Die Anzeige von Strukturen erfolgt, ausgelöst durch einen Nutzer, aus dem Browse und Search Werkzeug heraus. Die Visualisierung von Strukturen und die Unterschiede zwischen den Produktvarianten können den Bedarf der Korrektur auslösen. Markierungen oder Anfragen von Anwendern der Browse und Search Umgebung werden an die Prüfliste übergeben. Die leitet die Anfrage über das Workflow Management System zurück an den oder die Ersteller der fraglichen Design Artefakte. Etwaige Korrekturen erfolgen aus den Autoren Werkzeugen. In der Praxis sind Funktionen zum Vergleich von Varianten in PDM Werkzeugen etabliert, beispielsweise in CIM Database (vgl. Abschnitt 2.4). Ebenso sind aktuelle Workflow Management Systeme dazu in der Lage, die Rückmeldungen entsprechend zu verwalten. Die bestehenden Funktionen sind objektorientiert erzeugte Automaten, welche Deltas zwischen Varianten aufgrund der Anfrage von Menschen anzeigen.

4 Konzept für effiziente Produktdatenverwaltung

Abbildung 20: Anzeigen und Modifizieren von Produktvarianten

Bedarfe 8 und 9: Verwendungsmöglichkeiten von Design Artefakten und Teilprodukt- umfängen ausweisen Die steuernde Information des Status ist an den inhaltlich-technischen Fortschritt eines einzelnen Design Attributs (Funktion 15), sowie auch eines gewissen Produktumfangs (Funktion 16) zu einem Zeitpunkt gebunden. Für einzelne Objekte kann der, bei van den Hamer benannte, Konsens einer Organisation mittels eines verlinkten Workflows ermittelt werden. Damit ist für die einfache Umsetzung der Statusangabe bereits automatisierte Unterstützung vorhanden. Ein Workflow wird ausgelöst im Moment der Bestätigung zum Persistieren der Design Artefakte. Die Ablage der Status Information erfolgt als verlinktes Objekt durch eine „gehört-zu“ Beziehung zum Design Artefakt.

Eine Optimierung des Aufprägens von Statusangaben für Teilproduktumfänge oder gesamte Produkte ist erforderlich, anders als in konventionellen PDM Anwendungen. Das Aufprägen von Statusangaben für Teilproduktumfänge erfolgt basierend auf Workflow Mechanismen. Der Auslöser ist eine Suche, die aus dem Browse and Search Werkzeug initiiert wird und beispielsweise ein Produkt einer gewissen Variante zu einem bestimmten Zeitpunkt filtert. Der gefundene Umfang einer Summe an Design Artefakten kann folgend mit einem Status versehen und dieser über das Workflow-Management-System kommuniziert und abgelegt werden.

Die vorliegende Arbeit zielt auf die Prüfung und Inkludierung neuer Funktionen ab, somit verbleibt dieser Bedarf ohne eine technologische Implementierung. Die Einstufung des Automatisierungsgrades ist wiederum ein einfacher Automat, da die Bewertung durch den

4 Konzept für effiziente Produktdatenverwaltung

Nutzer erfolgt und das Werkzeug keine intelligente Unterstützung im Sinne der Künstlichen Intelligenz bietet.

Ein weiterer Aspekt ist das automatische Verknüpfen des Design Artefakts zu Verwendungsnachweisen. Entgegen dem bisherigen Vorgehen sollen für die weitere Verwendung die steuernden Informationen nicht mehr als Attribut an das Objekt des Design Artefakts geschrieben werden, sondern als Verlinkung zu der jeweiligen Verwendung abgelegt sein (Potential 5). Dafür werden die relevanten Verwendungsnachweise dem InADM als Referenzobjekt zur Verfügung gestellt. Die Abbildung 21 zeigt den Verwendungsnachweis in blau, die automatisch erstellte Verknüpfung in orange sowie die Verwendung von weiteren Informationen, wie Metadaten, in grau.

Abbildung 21: Erstellen von Verwendungsnachweisen

Bei der Speicherung des Design Artefakts aus dem Autoren Werkzeug heraus werden durch den Ersteller des Design Artefakts weitere Hinweise zu dessen Verwendung mitgegeben. Diese Hinweise zur Verwendung können beispielsweise die Vorgänger - Nachfolger Beziehung betreffen oder Angaben zum Bezug auf eine Spezifikation, Anforderung oder einem Test enthalten. Die, aus dem Autoren Werkzeug bekannten, Metadaten werden kopiert und in die Metadaten des InADMs übernommen. Diese setzen sich zusammen aus den auch im Autorenwerkzeug als Metadaten verwalteten Daten wie Benennung, automatisch erzeugter Nummer und Ersteller, sowie in den Autoren Werkzeugen innerhalb der Nutzdaten gelagerte Informationen wie beispielsweise das Gewicht. In einem weiteren Schritt werden relevante Ordnungskriterien aus der Umgebung der Referenzdaten und –Objekten, zusammen mit den Hinweisen des Anwenders sowie den bekannten Metadaten, semantisch miteinander

4 Konzept für effiziente Produktdatenverwaltung kombiniert. Die Verwendungsnachweise können beispielsweise Ordnungskriterien zur Produktvarianz oder zu Baukästen enthalten. Durch die semantische Zuordnung entsteht ein Vorschlag für die weitere Verwendung, der an den Anwender zurückgegeben wird.

Eine entsprechende Umsetzung der (Funktion 4) findet sich in Abschnitt 5.1 Design Artefakte automatisch . Eine Veränderung gegenüber aktuellen PDM Werkzeugen ergibt sich dadurch, dass Metadaten ab sofort einzig automatisch gespeichert werden und nicht mehr für den Anwender zugänglich sind. Daten und Hinweise zur weiteren Verwendung werden in der Regel direkt bei der Speicherung, unterstützt durch eine semantische Automatisierung, abgelegt. Der Mechanismus ist als Vorschlagssystem konzipiert, das den Anwender mit einer gewissen Intelligenz unterstützt. Bei den Anfragen zur Verlinkung kann eine gewisse Komplexität entstehen, beispielsweise durch mehrere Möglichkeiten der Zuweisung oder ein noch nicht in Gänze ausgereiftes Design.

Bedarf 10: Verwendungsmöglichkeit im Kontext analysieren Für die Tätigkeiten der Überprüfung des Entwicklungsfortschritts, des Status, der Zuweisung zu Varianten sowie der Verwendung von einzelnen Design Artefakten, Teilprodukten oder gesamten Produkten, wird die Search und Browse-Umgebung verwendet. Analog zu den Ausführungen im Bedarf 7 in Abbildung 20 stellt ein Anwender Fragen an das InADM und erhält eine entsprechende Visualisierung zurück.

Die Tätigkeiten der Prüfung und Validierung von Teilprodukten oder vollständigen Produkten weist einen wesentlich steuernden Charakter auf, insbesondere mit Bezug auf die In-Verkehr- Bringung von Produkten. Deshalb werden ermittelte Auffälligkeiten in der Prüfliste abgelegt und wiederum an den Ersteller des Design Artefakts herangetragen. Das Verfahren entspricht wiederum den Ausführungen in Bedarf 7.

Die von (Weber et al. 2003, S. 453) geforderte Trennung nach Merkmal, Beziehung und Eigenschaft, ermöglicht es, die Eigenschaftsbestätigung, das bedeutet, die Validierung und Verifikation, auf Basis der Beziehungen zwischen einzelnen Design Artefakten durchzuführen. Die Etablierung der Verbindungen erfolgt gemäß dem Bedarf 5 in Abbildung 17.

Der Grad der Automatisierung und die Unterstützung des Anwenders in diesem Bereich ist hoch. Die eigentliche Fragestellung ist komplex, denn es gibt mehrere Einflussfaktoren, wie Varianten, Status und Eigenschaftszuweisung, die sich überlagern. Für die Beantwortung der Nutzeranfragen sind mehrere Funktionen des InADM zur Bildung von Verlinkungen erforderlich, die Mechanismen des Maschinellen Lernens und der semantischen Informationsvernetzung beinhalten. Die Browse und Search Umgebung wird durch einen

4 Konzept für effiziente Produktdatenverwaltung

Anwender getriggert, folgend arbeitet das InADM autark, bis es auf eine nicht plausible Information stößt.

Bedarf 11: Zusammenhang der Weiterentwicklung von Teilen festhalten und anzeigen Bei der Übergabe von Design Artefakten aus den Autoren Werkzeugen soll zunächst sichergestellt werden, dass diese tatsächlich neu sind. Deshalb prüfen Mechanismen, wie die von (Dekhtiar 2018, S. 240) oder (Neumann und Abuosba 2016, S. 170–174), ob es geometrisch ähnliche Bauteile in der Datenbank gibt (Potential 20).

Bei der Weiterentwicklung eines Bauteils wird der Bezug zum Vorgänger automatisch mitgeschrieben (Funktion 14). Die technologische Umsetzung, basierend auf Hashfunktionen, stellt (Falbe 2020, S. 12–15) in seiner Arbeit analog zur Funktionsweise des SW-Version Managements beispielsweise in GitLab 19 vor. Dazu verwendet Falbe den öffentlich verfügbaren SHA20-1 Generator zur Erzeugung von Hashes. Dieser geht inhaltlich zurück auf den NIST (Standard FIPS Pub 180-1, S. 7–15) zur Verschlüsselung von Nachrichten. Eine beliebige Datei wird unabhängig davon, ob sie durch den Hash-Generator lesbar ist, oder nicht, in einen sogenannten „bite array“, also eine Zeichenkette des Inhalts, übersetzt. Für eine Textdatei im TXT Format ist dies einfach einsehbar, für eine CAD Datei entsteht ein nicht menschenlesbarer TXT String. Auf den „bite array“ wird der eigentliche Hash erzeugt. Dieser ist für SHA-1 eine 20 Byte Zeichenkette, die die Nummer eines Design Artefakts ersetzt. Die Zeichenkette ist für identische Datei Inhalte ebenfalls identisch, wodurch die Eindeutigkeit des Design Artefakts nachgewiesen werden kann.

Die Abbildung 22 zeigt den Zusammenhang der Design Artefakte zu den gebildeten Hash- Codes in Verwendung mit dem bekannten Versionskonzept mechanischer Daten.

Abbildung 22: Verwendung von Hashfunktionen für die Versionskontrolle

19 Verfügbar unter: https://gitlab.com; Software Version Control Werkzeug. 20 SHA: Secure Hash Algorithm.

4 Konzept für effiziente Produktdatenverwaltung

Die Hash-Codes werden bei einer beliebigen Änderung eines Design Artefakts erzeugt und diesem zugeordnet. Gleichzeitig wird in den Arbeiten von Falbe der Zusammenhang zum Vorgänger behalten. In der Abbildung wird deutlich, dass die neue Revision 0815.B.1 eine Weiterentwicklung der 0815.A.3 ist.

Die Einbindung in das InADM erfolgt, indem der Ingenieur zum Zeitpunkt der Speicherung Auskunft über den Charakter der Änderung und die intendierte Nutzung des neuen Design Artefakts gibt. Dies erfolgt, entsprechend dem Form-Fit-Funktion Kriterium, der öffentlichen Sichtbarkeit oder möglichen Alternativen. Eine menschliche Intervention erscheint an dieser Stelle erforderlich, da die Nutzdaten noch im Erstellungsprozess sind und diese somit kaum Interpretationsmöglichkeiten für Algorithmen bieten. Zudem werden einige Regeln, wie das Form-Fit-Funktion Kriterium, entsprechend der innerbetrieblichen Maßgabe interpretiert, was durch Algorithmen schwerlich zu erfassen ist. Gleichzeitig bestehen Implikationen zur Beschaffung und Lagerung von Teilen, die durch das InADM nicht interpretiert werden können. Folglich arbeitet das InADM mit Freigabeprozessen, die durch einen Ingenieur aus der Browse and Search Umgebung oder dem Autoren Werkzeug angeregt werden. Eine entsprechende Eingabe durch den Ingenieur erfolgt während der Speicherung über die Schnittstelle im CAD Werkzeug.

Der Grad der Automatisierung ist niedrig, denn die Komplexität der Fragestellung wird beim Nutzer belassen. Obschon die Hashfunktion, gegenüber aktuellen Datenbankfunktionen, technisch fortgeschritten ist, folgt sie kalkulierbaren Ergebnissen.

Bedarf 12: eigenständiges Vor- und Rückspringen zwischen unterschiedlichen Design Ständen Dieser Bedarf mit informativem Charakter wird durch die zuvor erläuterte Einbindung der Hashfunktion (Funktion 14) abgedeckt. Das InADM stellt den Zusammenhang sowohl den Plug-Ins der Autoren Werkzeuge als auch der Browse & Search Umgebung zur Verfügung.

Bedarf 13: (Teil) Produktumfänge nutzerzentriert repräsentieren Sichten, die für den Nutzer relevante Information, wie Daten und Dokumente, in dem, für ihn erforderlichen Detailgrad und Ordnung, repräsentieren, haben einen informativen Charakter. Entsprechend der Ergebnisse der Studie zur effizienten Produktdatenverwaltung (siehe Abschnitt 3.2) ermöglicht die Search & Browse Umgebung die eigenständige Konfiguration von Sichten.

Die Browse und Search Umgebung bietet den Anwendern die Möglichkeit, alle Filterparameter des InADM anzusprechen. Diese können, ähnlich zu bereits bestehenden Abfragemöglichkeiten in Teamcenter, durch natürlich-sprachliche Anfragen formuliert werden. Ergänzend dazu können bestimmte Ordnungen, wie etwa zur Montagereihenfolge, innerhalb

4 Konzept für effiziente Produktdatenverwaltung einer graphischen Repräsentation durch den Nutzer erzeugt werden. Weiterhin haben Anwender die Möglichkeit, ihre Anfragen und Einstellungen zu speichern. Auf diese Weise ist es den Anwendern möglich, regelmäßige Anfragen einfach zu reproduzieren.

Die Tabelle 15 stellt die Funktionen sowie das ausführende Organ und die Verantwortlichkeit entsprechend den Ausführungen in diesem Abschnitt zusammen. In Ergänzung dazu erfolgt eine Beschreibung der Veränderung der Werkzeugfunktionen und Tätigkeiten der Anwender.

Tabelle 15: Übersicht der Funktionen im InADM Konzept

ausführendes Nr. Funktion verantwortlich Delta Organ Inhaltliche Prüfung des Bestands der Design 1 Werkzeug Werkzeug neue Funktion Artefakte in der Datenbank Benummerung und Wechsel vom Anwender zum 2 Benennung der Design Werkzeug Werkzeug Werkzeug Artefakte Werkzeug/ Werkzeug/ 3 Enterprise Search vergleichbare Arbeitsteilung Anwender Anwender Verlinkung von Design neu ist der Vorschlag zur Artfakten zu 4 Werkzeug Anwender Verlinkung durch das ordnungsgebenden Werkzeug Strukturen unstrukturierte Ablage 5 Werkzeug Werkzeug Wechsel vom Anwender zum der Design Artefakte Werkzeug eventbasierte Prüfung 6 Werkzeug Werkzeug neue Funktion der Verlinkung Etablierung von partieller Wechsel vom 7 „gehört- zu“ Werkzeug Anwender Anwender zum Werkzeug Verbindungen Visualisierung im Werkzeug/ Werkzeug/ vergleichbare Arbeitsteilung, 8 Browser Anwender Anwender anderer Werkzeugteil automatisches 9 Komplettieren von Werkzeug Werkzeug neue Funktion Datenmodellen Interpretation 10 natürlich-sprachlicher Werkzeug Werkzeug neue Funktion Anwendungen Interpretation 11 dateiinhärenter Werkzeug Werkzeug neue Funktion Informationen Plausibilisierung von 12 Werkzeug Werkzeug neue Funktion Varianten partieller Wechsel vom 13 Fehlerkorrektur Werkzeug Anwender Anwender zum Werkzeug

4 Konzept für effiziente Produktdatenverwaltung

ausführendes Nr. Funktion verantwortlich Delta Organ Automatische 14 Werkzeug Werkzeug neue Funktion Versionsverwaltung Status am Design analog zur konventionellen Werkzeug Anwender 15 Artefakt anzeigen Vorgehensweise neue Funktion, methodisch Status an vergleichbar mit 16 Teilproduktumfängen Werkzeug Anwender konventioneller anzeigen Vorgehensweise neue Funktion, Möglichkeit Begründung an der für manuellen Eingaben 17 Verlinkung Werkzeug Werkzeug partiell in Werkzeugen automatisch vermerkt gegeben 18 Check / In Out Werkzeug Anwender analog

Die Funktion 3 Enterprise Search ist in einigen PDM Werkzeugen partiell am Markt verfügbar. Die Trennung zwischen Anwender und Werkzeug beruht darauf, dass die Anwender in der Regel die Eingaben vornehmen und somit auch die Inhalte kontrollieren.

Die Funktion 7 Etablieren von “gehört-zu“ Verbindungen wird in konventionellen PDM Werkzeugen ausschließlich durch den Anwender umgesetzt, im InADM Konzept übernimmt das Werkzeug den operativen Arbeitsanteil in der Datenbank auf Anweisung des Anwenders.

Da das InADM ohne Nutzeroberfläche im Sinne konventioneller PDM Werkzeuge aufgebaut ist, wird die Visualisierung von strukturellen Zusammenhängen oder Dateiinhalten in die Browse & Search Umgebung verschoben. Analog zu der Darstellung von Design Artefakten in aktuellen PDM Werkzeugen erfolgt zukünftig die Visulisierung in der Browse & Search Umgebung.

Im Rahmen der Funktion 13 Fehlerkorrektur meldet das InaDM aufgrund der datenbankinternen Analyse nicht plausible Design Artefakte. Die zusätzlichen Informationen zur Fehlerbehebung erbringt ein Nutzer. Das InaDM prüft unter anderem die Zuweisung zu Varianten automatisiert. Dabei kann festgestellt werden, dass ein bestimmtes Design Artefakt nicht zu einer Variante zu gehören scheint, etwa aufgrund seiner Geometrie oder Benennung. Am Beispiel eines Windkraftrades kann dies beispielweise die Zugehörigkeit eines Turbinenblattes zu einer bestimmten Leistungsklasse sein, die bisher immer anders gewählt wurde. Ein Nutzer kann dann entscheiden, ob dies eine beabsichtigte Zuweisung entgegen des bisherigen Musters ist, oder ein Fehler unterlaufen ist.

Die Funktion 18 Check In/Check Out verbleibt wie bisher. Die Initiierung und Statusanzeige, beispielsweise in Bearbeitung steht in dem Plug-In des Autorenwerkzeugs und der Browse & Search Umgebung zur Verfügung.

4 Konzept für effiziente Produktdatenverwaltung

Neben den oben erarbeiteten Funktionen sind einige Tätigkeiten der Anwender sowie Werkzeugfunktionen aus Tabelle 5, Seite 23 und Tabelle 6, Seite 26 bekannt, die bisher noch nicht betrachtet wurden. Diese werden in Tabelle 16 gegenüber der konventionellen Werkzeugfunktion und Tätigkeit des Anwenders dargestellt und im Anschluss diskutiert.

Tabelle 16: Aufgaben der Anwender im InADM Konzept

ausführendes Nr. Tätigkeit verantwortlich Delta Organ Transfer vom Erstellen von 1 Werkzeug Werkzeug Anwender zum Datenbankobjekten Werkzeug Erstellen und Transfer vom 2 Modifizieren von Werkzeug Werkzeug Anwender zum Attributen der Objekte Werkzeug Modifizieren der 3 Identifikation des - - entfällt Designs Korrigieren der Werkzeug führt die Werkzeug/ 4 Verlinkung zwischen Anwender operative Umsetzung Anwender Design Artefakten aus Auslösen von Änderungen an 5 Anwender Anwender analog bestehenden Design Artefakten Konzeptionieren und Bereitstellen einer funktionalen 6 Anwender Anwender analog Gliederung, Baukastenlogik, Variantenlogik Trainieren der Anwender/ 7 Anwender neue Aufgabe Algorithmen Werkzeug

Die Aufgabe 6 Konzeptionieren Ordnung gebender Strukturen ist in ihrer Explizitheit gegenüber der bisherigen Vorgehensweise neu. Sie ist bei den Aufgaben eines Produktmanagers oder System-Architekten oder einer vergleichbaren Rolle mit Überblick und Verantwortung für gesamte Baureihen zu verorten. Die Abstimmung erfolgt im Diskurs zwischen Abteilungen. Das InADM verfügt gegenüber bisherigen PDM Werkzeugen zusätzlich über lernende Algorithmen, die trainiert werden müssen. Es entsteht die neue Tätigkeit 7, die keiner aktuellen Rolle zugeordnet werden kann. Erforderliche Kenntnisse über die relevanten Umfänge des Produktes aber auch Kenntnisse der Funktionsweise der Algorithmen sind hierfür erforderlich. Folglich wird eine neue Rolle eingeführt und als Product Data Engineer bezeichnet.

4 Konzept für effiziente Produktdatenverwaltung 4.2.3 Auswirkungen auf die Methoden der Produktdatenverwaltung

Dieser Abschnitt beschreibt Veränderungen der methodischen Vorgehensweisen zur Bildung von Gliederungen und Varianten. Die Tabelle 17 stellt die Methoden einander gegenüber, wobei die Nummer in der ersten Spalte anzeigt, ob es sich um eine Methode zur Gliederung G 1 - n oder zur Variantenbildung V 1 – n handelt.

Die Gliederungen werden nicht mehr hierarchisch im InADM erzeugt, folglich entfallen die Methoden G1 und G2 zur Erstellung der Datenbankobjektstrukturen. Die Erstellung von Ordnung gebenden Strukturen findet außerhalb des InADM, auf Basis bereits etablierter Vorgehensweisen, statt, ein Beispiel hierfür liefert (Blees 2011, S. 106–108). Für wenig komplexe Produkte mag es ausreichend sein, ohne übergeordnete Strukturen zu arbeiten. Ebenso ist es, bedingt durch die automatische Zuweisung und integrierte Plausibilisierung, unerheblich, wann die Ordnung gebende Struktur dem InADM übergeben wird.

Tabelle 17: Vergleich bisheriger und neuer Methoden

Nr. bisherige Methode InADM Methode G 1 Gliederung vollständig übernehmen (inkl. Nutzdaten) Entfällt, denn es werden lediglich Ordnung G 2 Gliederungsobjekte ohne Nutzdaten gebende Strukturen bereitgestellt. neu erzeugen G 3 Funktionale Gliederung erzeugen Manuelle Vorgehensweise wie bisher, aber in dafür vorgesehenem Autoren System. G 4 Modulare Gliederung erzeugen Wirkt strukturierend und unterstützend im Konstruktionsprozess, wenn zuvor bekannt. G 5 Baukasten erzeugen Reduktion zu einer Funktion, die eine V 1 Variante an Datenbankobjekt Verlinkung ausschließlich auf der Ebene verknüpfen des Design Artefakts zulässt. Konzept muss extern erstellt werden. V 2 Variante an Teilproduktumfänge verknüpfen V 3 Varianz auf bestimmter Ebene Entfällt, da es keine Hierarchien mehr gibt. pflegen V 4 Varianz auf mehreren Ebenen pflegen V 5 Variante an Design Artefakt Analog zu V - 1 verknüpfen V 6 Varianz in mehreren Werkzeugen Weder im InADM noch in konventionellem verwalten PDM so vorgesehen.

In der konventionellen Welt wurden Produktdatenstrukturen entweder durch Ingenieure oder durch Produktdatenpfleger angelegt. Im Rahmen des InADM Konzepts erfolgt diese Tätigkeit in der Abstimmung zwischen Ingenieuren, Funktionsarchitekten, Produktmanagern und

4 Konzept für effiziente Produktdatenverwaltung

Produktionsverantwortlichen je nach Ordnungskriterium. Die Erstellung der Struktur erfolgt durch eine der benannten Rollen zunächst außerhalb des InADM, und wird dann übergeben.

Varianten werden zukünftig auf Anweisung des erstellenden Ingenieurs, entsprechend der Methode V5, direkt mit dem relevanten Design Artefakt verlinkt. Die Bildung der Variantenlogik erfolgt außerhalb des InADM, beispielsweise gemäß der Methode von (Zagel 2006, S. 165) unter anderem in Abstimmung zwischen Ingenieuren und Produkt Managern. Analog zu der Erstellung Ordnung gebender Gliederungen wird zudem das Schema der Varianz durch eine der beteiligten Rollen an das InADM übergeben. Die übergebenen Varianten enthalten Angaben zu Zwangsbedingungen oder optionalen Verwendungen, analog zur Funktionsweise des Werkzeugs 3DExperience, Fa. Dassault. Dadurch, dass die Verlinkung des Design Artefakts mit den referenzgebenden Objekten durch das Werkzeug erstellt wird, entfallen wesentliche Tätigkeiten der heutigen Rolle des Produktdatenpflegers, die Verantwortlichkeit des Ingenieurs wird hingegen gestärkt.

Die Überprüfung von Gliederungen und Varianten ist gegenwärtig nicht als explizite Tätigkeit innerhalb der Methoden adressiert, allerdings ist sie Gegenstand der operativen Arbeit in Unternehmen. Im InADM ist eine manuelle Interaktion zunächst bei möglicherweise erforderlichen Korrekturen vorgesehen. Durch die Zuweisung zur Prüfliste und Übermittlung an den Ersteller der Dateien, werden einzig derartige Design Artefakte oder Daten erneut angesehen, die nicht plausibel erscheinen. Somit findet eine Verschiebung der Arbeiten vom Datenpfleger zum Ingenieur statt.

Zusammenfassend wird festgestellt, dass methodisch konzeptionelle und planerische Tätigkeiten in ihrer aktuellen Form erhalten bleiben und durch die gleichen Rollen erfüllt werden wie bisher. Die manuellen Tätigkeiten des Produktstrukturpflegers werden häufig durch Funktionen des InADM ersetzt, die die Verlinkung zwischen Design Artefakten und Ordnung gebenden Objekten erzeugen sowie die Daten innerhalb des InADM plausibilisieren. Die technologischen Voraussetzungen für diese Veränderung der gängigen Praxis findet sich in Kapitel fünf.

5 Exemplarische Umsetzung relevanter Bedarfe 5 Exemplarische Umsetzung relevanter Bedarfe

Dieses Kapitel beschreibt punktuelle Umsetzungen des Konzepts. Diese wesentlichen technologischen Säulen werden individuell implementiert, jedoch nicht zu einem gesamten, neuen Datenverwaltungssystem integriert. Die jeweils relevanten IT-Methoden und Vorgehensweisen werden im Zusammenhang des jeweiligen Abschnitts beschrieben und erheben den Anspruch, eine mögliche Lösung aufzuzeigen. Die Anforderung an die intendierte Anwendung sowie deren spätere Nutzung werden erläutert. Für jede Anwendung werden konkrete Produktdatenbeispiele aus dem direkten industriellen oder vergleichbaren Kontext herangezogen.

5.1 Design Artefakte automatisch zuweisen

Dieser Abschnitt stellt Automatismen für die Klassifizierung und Zuweisung von Design Artefakten zu Ordnung gebenden Strukturen oder anderen Design Artefakten dar. Es werden zwei Anwendungsszenarien betrachtet. Dies ist erstens die datenerzeugende Seite während der Erstellung von Design Artefakten und der darauffolgenden Zuweisung zu einer Gliederung und zweitens wird die datenkonsumierende Seite betrachtet, die ein „fertiges“ Design Artefakt für seine weitere Nutzung entsprechend markiert. Der erste Anwendungsfall Zuweisung zu Gliederungen ist in Abbildung 23 schematisch skizziert.

Abbildung 23: Allokieren von Design Artefakten zu Funktionen

Die orangenen Linien zwischen den Metadaten der Design Artefakte und der Funktionshierarchie deuten den anvisierten Versuch an. In diesem ersten Versuch sollen

5 Exemplarische Umsetzung relevanter Bedarfe zunächst die Benennung, weitere vorliegende beschreibende Daten sowie der eigentliche Dateiinhalt den Funktionen zugewiesen werden. Die Verantwortung für die korrekte Allokation liegt, entsprechend dem Konzept, bei dem Ingenieur, der die Design Artefakte erstellt. Die Umsetzung der „gehört-zu“ Verbindung im InADM erfolgt somit als Vorschlag, der durch den Ersteller des Design Artefakts bei dessen Speicherung oder Modifikation bestätigt wird.

Die Interpretation und Kontrolle der „gehört-zu“ Verbindung erfolgt zyklisch, beispielsweise quartalsweise, um veränderliche Randbedingungen zu berücksichtigen. Ergebnisse der Kontrolle werden der Prüfliste zugeführt und dem Anwender übergeben. Eine direkte Korrektur der „gehört-zu“ Verbindung wird lediglich in einer Administrationsebene vorgesehen.

Entsprechend dem InADM Konzept sind Attribute an PDM Objekten auf ein Minimum reduziert und nicht länger für Nutzer zugänglich. Somit erfolgt die Verwaltung von steuernden Informationen basierend auf der inhaltlichen Ausprägung der Design Artefakte sowie vorliegenden Metainformationen. Am konkreten Beispiel eines CAD Modells kann man sich vorstellen, dass das Gewicht aus der CAD Datei übernommen oder darauf referenziert wird, und beispielsweise mit einem Vorgabe- oder Sollwert aus einer Spezifikation verlinkt wird. Abbildung 24 zeigt den zu erzeugenden Link orangefarben zwischen den Metadaten des Design Artefakts sowie den Referenzdaten. Am zuvor benannten Beispiel des Gewichts würde also eine Referenz zwischen dem aus der CAD Datei übernommenen Wert für das Gewicht und der Spezifikation erfolgen. Erfolgt die Anfrage aus der Search und Browse Umgebung ist zusätzlich eine Verlinkung zu einem Referenzobjekt außerhalb der PDM Umgebung denkbar. Folglich ist in Abbildung 24 die Datenbank der Referenzobjekte außerhalb des InaDM dargestellt. Der Nutzer stellt eine Anfrage zur Verlinkung und erhält vom InaDM einen entsprechenden Vorschlag dazu, diesen bestätigt er oder lehnt ihn ab.

Abbildung 24: Verlinkung eines Design Artefakts mit einem Referenzobjekt zur Verwendung im Kontext

5 Exemplarische Umsetzung relevanter Bedarfe

In diesem Abschnitt liegt der Fokus auf der technischen Umsetzung der eigentlichen Verlinkung. Dazu stellt der Abschnitt 5.1.1 technologische Grundlagen zusammen.

Als Anwendungsbeispiel für die datenkonsumierende Seite dient die Exportkontrolle. Durch die Exportkontrolle werden bestimmte Produkte oder Teilprodukte Zollvorschriften zugewiesen. Personen, die sich mit dem Warenimport und -Export und den entsprechenden Vorschriften befassen, profitieren von dem Vorschlagswesen.

Als Anwendungsbeispiel für die datengenerierende Seite dient die Zuweisung von CAD Dateien zu einer Funktionsstruktur. Profiteure der automatischen Zuweisung sind Datenpfleger oder Ingenieure, die diese Zuweisung gegenwärtig manuell vornehmen.

Die beiden Anwendungsbeispiele werden durch eine Implementierung in den Abschnitten 5.1.2 und 5.1.3 realisiert. Dabei wird eine Anwenderschnittstelle grundlegend etabliert, sodass die technologische Funktionalität in Tests nachgewiesen werden kann.

Das Kapitel wird komplettiert durch die Vorstellung der Versuchsdaten für beide Anwendungsfälle sowie die Versuchsdurchführungen. Die Ergebnisse sowie eine Beurteilung der technologischen Lösung zur Verwendung im InADM runden den Abschnitt ab.

5.1.1 Funktionsweise von Semantischen Technologien

Dieser Abschnitt beschreibt bereits bestehende Algorithmen und Verfahren, die für das Zusammenführen von Design Artefakten und Ordnung gebenden Strukturen verwendet werden.

Die Zielstellung Semantischer Technologien ist es, textuellen Informationen die im Kontext relevante Bedeutung zuzuordnen, entsprechend den Ausführungen von (Dengel 2012, S. 12). Dazu werden in der Regel Metadaten verwendet.

Die Extraktion von Informationen aus Texten (englisch: Information Retrieval) stellt einen Teilbereich Semantischer Technologien dar. Die grundlegende Aufgabe der Informationsextraktion ist es, ein Template mit entsprechenden Informationen zu befüllen.

Um die Extraktion zu ermöglichen, werden Techniken der Natürlichen Sprachverarbeitung21 verwendet, die zunächst eine syntaktische und dann eine semantische Analyse durchführen. Die Grundlage für die Analyse wird durch den Zugriff auf einzelne Worte ermöglicht, beispielsweise das Portieren von Texten in XML oder HTML-basierte Formate. In einem weiteren Schritt werden die Daten folgend für die Analyse bereitgestellt, entsprechend dem

21 Engl.: Natural Language Processing (NLP), vgl. Abschnitt 5.3.

5 Exemplarische Umsetzung relevanter Bedarfe

ETL22 Prozess, wie er unter anderem durch (Bunzel 2013, S. 41) oder (Woll 2018, S. 42–46) beschrieben und verwendet wird.

Teil der syntaktischen Analyse ist es, einzelne Worte, Sätze und Phrasen in der jeweiligen Sprache zu erkennen und der Grammatik zuzuordnen. Die semantische Analyse interpretiert die Verwendung oder Bedeutung im Kontext.

(Carstensen 2010, S. 35) unterscheidet zwischen dem oben beschriebenen „klassischen“ Information Retrieval, das auf klaren Regeln basiert und direkte Muster, Strings oder Wortkombinationen verwendet, um die Zuordnung zu einer Klasse zu erzeugen. Moderne Methoden des NLP verwendet das Maschinelle Lernen mit Parsing oder POS Tagging (siehe Abschnitt 5.2.1) für die Funktionsweise. Der Vorteil dieser Methoden besteht laut (Carstensen 2010, S. 220) darin, eine größere Abdeckung der Ergebnisse dadurch zu erzielen, dass beispielsweise bestimmte Wortkombinationen nicht erforderlich sind.

Für diesen Abschnitt werden die statistischen Verfahren TF-IDF Maß und die Levenshtein- Distanz aus dem Bereich der Informationsextraktion verwendet.

TF-IDF

Für die Suche innerhalb großer Datenmengen werden häufig Indizes gebildet, die das schnelle Suchen und Zuweisen ermöglichen. Ein Anwendungsbeispiel dazu ist ein Nutzer, der zu einem Begriff ein passendes und relevantes Dokument erhalten soll, demnach beispielsweise ein Fachbuch zum Thema Computerlinguistik aus dem gesamten Universitätsbestand. Neben der schnellen Suche, ist zudem das Erfassen von relevanten Begrifflichkeiten erforderlich, an dieser Stelle setzt das TI-IDF an. (Carstensen 2010, S. 350) erläutert die Bildung von Indizes, indem alle Dokumente (d) vollständig erfasst werden und jedem Dokument relevante Begriffe aus dem Dokument zugeordnet werden. In der Regel geschieht das über das Erfassen aller Begriffe und einer Reduktion um Stoppworte. Zunächst wird die Häufigkeit (f - frequency) des

Begriffs (t - term) in einem Dokument (c - corpus) erfasst. Die Termfrequenz (tfc) beschreibt folglich die Häufigkeit, mit der ein bestimmter Begriff im einem bestimmten Korpus (c) vertreten ist. Der Korpus besteht dabei aus mehreren Dokumenten, wie etwa einer Bibliothek mit vielen � Büchern. Die inverse (i- invers) Dokumentenfrequenz �� = �� beschreibt, dass ein Term �� umso charakteristischer für ein Dokument ist, je häufiger er in diesem vorkommt. Diese statistische Größe wird als TF-IDF Maß bezeichnet und in Indizes zu den Begriffen, für jedes Dokument, abgelegt. Wendet man das TF-IDF Maß auf die vorliegende Arbeit (c) sowie dieses Kapitel (d) zum gegenwärtigen Zeitpunkt an, so ergibt sich für den Begriff Automat ein Wert

49784 49784 von log ( 140 ) = 2,55 und für den Begriff Nutzeroberfläche ein Wert von log ( 9 ) = 3,74. Es

22 ETL (engl.): Extract Transform Load.

5 Exemplarische Umsetzung relevanter Bedarfe wird somit klar, dass zu Automat mehr Inhalte in der Arbeit zu finden sind als zu Nutzeroberfläche.

Damit insgesamt relevante Werte gebildet werden können, werden Stoppworte aus den Korpora entfernt. Das sind Worte, die sehr häufig in Texten auftauchen und damit diesen nicht mehr charakterisieren. Typische Beispiele aus Fließtexten sind Artikel oder Konjunktionen. Maschinenbauliche Texte verwenden häufig Zahlen oder Formeln sowie einzelne Wort-Zahl Kombinationen, etwa 20V. Stoppworte werden für diesen Kontext definiert als solche, die sehr häufig in einem Dokument oder Korpus vorkommen und somit nicht mehr charakteristisch wirken.

Ein Teil der Computerlinguistik beschäftigt sich damit, Nichtworte auf das durch den Anwender intendierte Wort zurückzuführen. Ein Verfahren ist die Levenshtein-Distanz, wie sie (Carstensen 2010, S. 225) beschreibt. Dabei werden einzelne Buchstaben im Wort:

• getauscht (Hnad - Hand) • durch weitere ergänzt (a, in Hnd) • durch weitere ersetzt (Wand- Hand) oder • gekürzt (Haand → Hand).

Es wird ein möglicher Vorschlag mit den wenigsten erforderlichen Änderungen von einem Nichtwort zu einem realem Wort an den Nutzer zurückgegeben. Die Levenshtein-Distanz ist rein syntaktisch, die Verwendung des Wortes im Kontext wird nicht berücksichtigt. Der Algorithmus würde an dieser Stelle demnach zwei gleichberechtigte Änderungen von Hand → Hund oder von Hand→ Wand vorschlagen, ohne zu prüfen, ob das initiale Hand ggf. das Passendste ist.

Umgang mit Komposita

Der deutschen Sprache ist es eigen, Komposita, also Wortzusammensetzungen, zu bilden. Diese liegen in der Fachsprache des Ingenieurwesens ebenfalls vor, wie am Beispiel des Wechselstrommotors klar wird. Um die Bedeutung der Worte zu erfassen, kann es hilfreich sein, sie in ihre Einzelbestandteile zu reduzieren und diese ebenfalls den Korpora zum semantischen Abgleich zur Verfügung zu stellen. Ein solcher Mechanismus wird in der Enchant Library (Lachowitz 1998) im Bereich Hunspell zur Verfügung gestellt.

Um Inhalte der Design Artefakte zu verwenden, ist es erforderlich, diese in textuell interpretierbare Bausteine, entsprechend dem ETL Vorgehen, zu überführen. Hierfür wird das PRC 23 oder 3D PDF Format verwendet. Der Standard wurde initial erstellt um 3D Repräsentationen lesbar zu machen, ohne ein CAD Werkzeug oder einen entsprechenden

23 Abkürzung für: Product Representation Compact Format.

5 Exemplarische Umsetzung relevanter Bedarfe

Viewer zur Verfügung zu haben. Eine Einbindung in PDF Dokumente sowie das Betrachten der Dateien von allen Seiten ist durch dieses Format unterstützt. Das PRC wird in der ISO 14739-1 definiert, und beinhaltet, neben der visuellen Repräsentation der Geometrie in einem B-REP, die Produktstruktur für Baugruppen sowie Fertigungsinformationen in PMIs. Die Informationen werden jeweils in einzelnen Tabellen abgelegt. Das Erzeugen von 3D PDFs kann durch übliche CAD Werkzeuge erfolgen. Das inhaltliche Auslesen ist durch das Werkzeug SDK der Open Design Alliance (ODA) möglich. Dieses Java-basierte Werkzeug ermöglicht es, unterschiedliche CAD Datei-Formate in der oben benannten Tabellenform als Textdatei auszugeben.

5.1.2 Anwendung auf den Kontext der Gliederungen

Die Zielstellung der hier zu implementierenden Anwendung ist es, einzelne Design Artefakte Funktionen zuzuordnen. Die Abbildung 23: Allokieren von Design Artefakten zu Funktionen auf Seite 77 stellt die Assoziation zwischen den hierarchisch aufgebauten Funktionen sowie den Design Artefakten als orange Linien dar. Die zu erstellenden Beziehungen liegen in einem 1 : n Verhältnis (Funktion : Design Artefakt) vor.

Durch das Auslösen des Speichervorgangs wird die Anwendung im InADM Konzept gestartet. Für die exemplarische Umsetzung erfolgt durch die Aufforderung eines Nutzers, die Zuweisung für ein bestimmtes Design Artefakt auszulösen.

Die Grundstruktur für den Versuchsaufbau folgt dem Modeltracer von (Sünnetcioglu et al. 2016, S. 368–370). In einer relationalen Datenbank werden Tabellen für:

• die Metadaten der CAD Daten, • die „gehört-zu“ Relationen, • die Funktionen sowie • die Relationen der Funktionen erstellt.

In einem vorbereitenden Schritt werden die Tabellen mit den Versuchsdaten zu den Funktionen befüllt. Die Design Artefakte liegen als lose Dateien vor. Sie werden durch eine Bezeichnung und eine Nummer identifiziert, davon wird lediglich die Bezeichnung für diese Anwendung in die Tabelle der Metadaten übertragen. Zusätzlich liegen die ergänzenden Daten aus den PRC Dateien als Text vor. Dieser wird ebenso in der Tabelle der Metadaten abgelegt. Die Tabelle der „gehört-zu“ Relationen wird durch den Algorithmus mit einer gewissen Wahrscheinlichkeit befüllt. Die Tabelle der Funktionen stellt ebenso eine Spalte für die Benennung bereit sowie eine inhaltliche Erläuterung. Die Tabelle der Relationen der Funktionen ermöglicht beliebige Abhängigkeiten zwischen den Funktionen.

5 Exemplarische Umsetzung relevanter Bedarfe

Die Schritte 1, Auslesen der DB24 und 2, Erstellung des Index in Abbildung 25 verlaufen automatisch im Hintergrund. Der Index ist mit einem TF-IFD Maß versehen, das auf Basis aller Einträge der Datenbank beruht und zusätzlich für das zuzuweisende CAD Dokument gilt. Der Programmablauf für den Nutzer entspricht den Schritten 3-6 in Abbildung 25.

Abbildung 25: Programmablauf zur statistischen Zuordnung von Design Artefakten zu Ordnungskriterien

Der in Abbildung 25 beschriebene Vorgang wird in der Verwendung innerhalb des InADM durch das Speichern eines Design Artefakts angestoßen. Im Schritt 4, Errechnung eines Zuordnungsvorschlags wird ein Design Artefakt zu einem Ordnung gebenden Kriterium allokiert. Die Rückgabe verwendet die Nutzeroberfläche des Modeltracers, der Nutzer erhält jedoch die drei optimal passenden Vorschläge für eine Zuordnung des Design Artefakts zu den Funktionen.

Um einzelne Dateien mit einer bestehenden Funktion vergleichen zu können, wurde der CAD Import Button erstellt. Mit diesem kann eine beliebige Menge einzelner CAD Dateien in den Formaten STEP, PRT, JT oder DWG eingelesen werden. Über den Import Button wird die Benennung der Datei in die Tabelle der CAD Daten übertragen. In Tabelle 18 ist in der Spalte Identifikationsnummer, die durch die Datenbank erstellte, fortlaufende, interne Identifikation, notiert. Die Spalte Bezeichnung wird durch die Import Funktion befüllt und ist ebenso wie die

24 DB: Abkürzung für Datenbank.

5 Exemplarische Umsetzung relevanter Bedarfe

Identifikation ein Pflichtfeld. Sollen weitere Metadaten zu den CAD Daten für die Zuweisung verwendet werden, erfolgt ein manueller Eintrag in die Datenbank.

Tabelle 18: Schema der Tabelle für CAD Daten

Identifikationsnummer Bezeichnung Kommentar Setzen durch die DB Benennung der CAD Datei optional, String der PRC Datei

Die Funktionen werden für den Versuch manuell in einer Tabelle, entsprechend dem Aufbau von Tabelle 19, erstellt. Im Versuch wird automatisch eine fortlaufende Identifikationsnummer erzeugt. Die Bezeichnung entspricht der Benennung der Funktion und ist ein Pflichtfeld. Der Kommentar kann beispielsweise Hinweise des Nutzers enthalten. Der zu bildende Index berücksichtigt die Tabellenfelder Bezeichnung und Kommentar.

Tabelle 19: Schema der Tabelle für Funktionen

Identifikations- Bezeichnung Kommentar nummer Benennung der Funktion durch den optional, durch den Setzen durch die DB Nutzer Anwender gesetzte Hinweise

Für die Analyse statistischer Zusammenhängen werden die Einträge der Tabellen der Metadaten und Funktionen miteinander verglichen. Dazu wird das Java basierte Open Source Projekt Lucène 25 (Cutting 2011) verwendet. Lucène beinhaltet Bausteine für die Rechtschreibprüfung, das Tokenization, die Indizierung von Texten und neben vielen Weiteren auch Module für die Ähnlichkeitssuche (Białecki 2012, S. 18). Die Bildung des Index erfolgt für die Liste der Funktionen. Alle Worte werden tokenisiert, das bedeutet in diesem Kontext, dass Leerzeichen und Satzzeichen neue Worte markieren. Weiterhin findet im Rahmen des Tokenization eine Reduktion auf den Singular statt. Zusätzlich findet eine Trennung der Komposita statt. Die Bildung des TF-IDF Maßes für den Index findet auf Basis der deutschsprachigen Lucene Bibliothek statt.

Zunächst werden Strings zwischen der CAD Datei und dem Index der Funktionen gesucht. Ist diese direkte Suche erfolglos, wird eine zusätzliche Ähnlichkeitssuche verwendet. Für dieses Beispiel wird die Fuzzy Search aus dem Lucène Paket verwendet, diese benutzt die beschriebene Levensthein-Distanz um ähnliche Worte zu finden. Es handelt sich folglich um eine regelbasierte, statistische Zuweisung.

25 Diese bietet mittlerweile Optionen, um zusätzlich Pyhton Bibliotheken über APIs anzuschließen und so erweiterte Funktionalitäten zu verwenden.

5 Exemplarische Umsetzung relevanter Bedarfe

Durch das Erproben des Programms fällt auf, dass die Suchrichtung entscheidend ist. Sucht ein Anwender danach, ob ein Design Artefakt zu einem Ordnungskriterium passt, erhält er ein anderes Ergebnis als in der umgekehrten Suchrichtung. Tatsächlich kann ein Design Artefakt entweder zu einer Funktion passen oder nicht. Deshalb wurde der Programmablauf dementsprechend modifiziert, dass der errechnete Wert bidirektional erstellt und anschließend aufsummiert wird.

Der Software Code wurde mit Eclipse in Java geschrieben, als Datenbanksystem wird MariaDB verwendet. Der vollständige Code findet sich auf Deposit-Once (Fresemann und Göksel 2020).

5.1.3 Anwendung auf den Kontext der steuernden Metainformation

Dieser Abschnitt erläutert die Verwendung von Taxonomien für das übergeordnete Ziel des Datenmanagements ohne manipulierbare Metadaten. Ziel der Anwendung ist eine Beurteilung, welchen Exportvorschriften ein Bauteil, Halbzeug, Teilprodukt oder Produkt unterliegt. Dazu wird ein industrielles Erzeugnis (Halbzeug, Teilprodukt oder Produkt) einer bestimmten Exportkontrollnummer aktuell manuell zugeordnet. Zu der Exportkontrollnummer sind entsprechende Verfahrensanweisungen öffentlich26 hinterlegt (Ausfuhr erlaubt, für Land A mit x % Zollgebühren versehen etc.). Anwender des späteren Systems sind Experten der Zollwirtschaft, Nutznießer sind Ingenieure die operativ entlastet werden durch die automatische Zuordnung der Bauteile.

Um die automatische Zuweisung eines Produktdatenblattes zu einer Zolltarifnummer zu erwirken wird ein Python Code mit der Freeware Idle 3.8 erstellt. Der grundsätzliche Ablauf des Codes findet sich in Abbildung 26, der vollständige Code auf DepositOnce (Fresemann und Bittcher 2020c). Zunächst werden im Schritt prepare die Daten der Taxonomie der Zollnummern vorbereitet. Dazu werden aus der Taxonomie die Nummer, der Name und die Hierarchiestufe ausgelesen.

Es wird zunächst ein deutschsprachiger Korpus von der enchant Bibliothek von (Lachowitz 1998) geladen. Dieser wird tokenisiert, um den Singular der Worte, sowie eine Kleinschreibung aller Begriffe zu erwirken. Dieser Vergleichskorpus wird für die spätere Erzeugung der TF-IDF Maße herangezogen. Zusätzlich wird die Taxonomie der Zolltarifnummern geladen (siehe Abbildung 25, „get taxonomy“).

Weiterhin wird ein Index auf Basis der Zolltarifnummern-Taxonomie gebildet. Zunächst werden alle Begriffe reduziert und kommen lediglich einmal im Index vor, die Häufigkeit wird ebenso

26 Vgl. unter anderem: https://www.zolltarifnummern.de/2019/85462000; Zugriff am 06.09.201. Ausfuhr von keramischen Isolatoren in alle Länder der Welt erlaubt mit Ausnahme von Nordkorea.

5 Exemplarische Umsetzung relevanter Bedarfe notiert. Die Begriffe werden über ein Lemmatizing aus Spacy.io auf einen Wortstamm zurückgeführt, klein geschrieben und in den Singular überführt. Es werden weiterhin Stoppworte über NLTK27 für die deutsche Sprache sowie alle Begriffe, die häufiger als 20-mal vorkommen. eliminiert. Diese haben aufgrund ihrer Häufigkeit keine Aussagekraft bezüglich der Zuweisung zu einer Klasse. Zusätzlich werden über die enchant Funktion „split“ mögliche Komposita aufgetrennt.

In einem weiteren Schritt werden die Einheiten aus den jeweiligen Zolltarifnummern ausgelesen und in dem Index vermerkt. Dies findet über einen Vergleich zu einer, für den Versuch manuell erstellten, Liste gängiger Einheiten im maschinenbaulichen Kontext statt. Damit ist der Programmabschnitt get taxonomy abgeschlossen.

Abbildung 26: Sequenzdiagramm der Taxonomie Zuweisung

Im nächsten Schritt aktiviert der Nutzer das Programm, indem er ein Produktdatenblatt an den Algorithmus übergibt. Der Schritt entspricht in der Abbildung 26 dem send datasheet. In der Umsetzung wird davon ausgegangen, dass jeweils lediglich ein Design Artefakt zur selben Zeit allokiert wird. Die Anwendung ist als Vorschlagssystem konzipiert, in dem der Anwender folgend die tatsächliche Verlinkung des Produktdatenblattes bestätigt. Die Intention hinter diesem Vorgehen ist, „Sammelquotierungen“ ohne bewusst prüfende Intervention des Anwenders zu unterbinden.

Für die Interpretation und Zuweisung der Produktdatenblätter werden diese durch eine CODECS28 Interpretation als Text Datei abgelegt. Diese CODECS Analyse ist für die deutsche

27 Verfügbar unter: https://www.nltk.org/. 28 https://docs.python.org/3/library/codecs.html: Pyhton interne Library, die Text verschlüsselt und entschlüsselt. Es kann in UTF-8, folglich Standardzeichen, übersetzt werden. Damit können Textbausteine aus Datenblättern ohne Bilder ausgelesen werden.

5 Exemplarische Umsetzung relevanter Bedarfe

Sprache erstellt. Sie kann Bilder aussondern sowie Umlaute korrekt abbilden. CODECS erkennt einzelne Worte durch Komma oder Leerzeichen.

Der Baustein „allocation“ (siehe Abbildung 26) bringt die Klassen der Zolltarifvorschriften mit den Begriffen des Produktdatenblattes in Verbindung. Dazu wird mittels NumPy29, kurz für numerisches Python, eine Matrix aufgespannt, deren Schema in der Tabelle 20 exemplarisch dargestellt ist. NumPy integriert numerische Verfahren, die in C# erstellt wurden um „for“ Schleifen zu umgehen und allgemein Programmcodes zu schnelleren Rückgaben zu führen.

Tabelle 20: Schema der Zuweisungsmatrix für Zolltarifnummern und Produktdatenblätter

Begriff 1 Begriff n Klasse 1 0 2 0 3 1

Klasse n

In der Tabelle 20 ist ein exemplarischer Vektor dargestellt. In der Matrix wird zunächst die „term frequency“, folglich das Vorkommen einzelner Begriffe des Datenblattes in jeder Klasse der Zolltarifnummern gezählt. Für das gegebene Beispiel kommt demnach Begriff 1 keinmal vor, der Begriff n einmalig usw. Somit stehen nun die relevanten Begriffe der Zolltarifnummern und zudem die des zuzuweisenden Produktdatenblattes zur Verfügung.

Das Programm steht in zwei unterschiedlichen Varianten zur Verfügung, mit und ohne TF-IDF Maß. Verwendet man es ohne das TF-IDF, werden die Begriffe unmittelbar mit den Begriffen der Klassen in Verbindung gebracht. Alternativ werden einzig die, über TF-IDF als charakteristisch ermittelten, Begriffe für das Ermitteln der Relation verwendet. Dieses optionale Vorgehen wird für die folgenden Versuche verwendet, um die Relevanz des TF-IDF zu bewerten.

Das Zuweisen der Produktdatenblätter zu den Zolltarifnummern erfolgt im Programmabschnitt „allocation“ von unten nach oben in der Taxonomie. Der Aufbau der Daten ist in Abschnitt 5.1.6 detailliert erläutert. Kann ein Produktdatenblatt bereits zu einer der unteren Klassen zugeordnet werden, bricht der Algorithmus ab, andernfalls iteriert er so lange nach oben bis er eine Zuweisung gefunden hat, oder das Ende der Liste erreicht ist. Sowohl erfolgreiche als auch erfolglose Ergebnisse werden an den Anwender zurückgegeben. Ergänzend zu den KI Methoden wurden zudem regelbasierte Methoden implementiert. Diese verwenden die

29 https://www.python-kurs.eu Erweiterung für Python, mit der bestimmte mathematische Funktionen besonders schnell umgesetzt werden können.

5 Exemplarische Umsetzung relevanter Bedarfe

Benennung der Produktdatenblätter sowie die Einheiten in ihrer Benennung und Größe, um eine Zuweisung zu erzeugen.

Die Begriffe werden nicht als direkte Strings gesucht, sondern es wird über die Cosinus Similarity ein möglichst ähnlicher Begriff gesucht. Dadurch ist es möglich, nicht einzig Strings miteinander in Beziehung zu setzen, sondern auch ähnliche Worte. Die Cosinus Similarity findet ebenfalls im Abschnitt 5.2.1 Anwendung und ebenso wird ihre Funktionsweise dort erläutert.

Die Rückgabe der Anwendung ist in der Abbildung 27 exemplarisch gezeigt.

Abbildung 27: Rückgabe des Codes für die Zuweisung zu einem Produktdatenblatt

Der Anwender erhält unter Punkt 1 die Möglichkeit, einen neuen Index der Taxonomie zu erzeugen. Für diesen Zusammenhang wurde „n“ = nein gewählt. Bei Punkt 2 wird der Fortschritt des Programms dargestellt und in der roten Box wird angezeigt, dass für das verwendete Beispiel 2774 unterschiedlich Begriffe in den Indizes und Listen miteinander in Beziehung gesetzt werden. Bei Punkt 3 und Punkt 4 ist die Rückgabe des Programms einmal mit und einmal ohne die Einheiten zu betrachten. Die Rückgabe zeigt, dass ohne Verwendung der Einheiten eine Zuweisung zu der Zollposition Bagger durch den Code vorgeschlagen wird. Durch die Verwendung der Einheiten wird hingegen ein Gleichstrommotor mit einer bestimmten Leistungsklasse vorgeschlagen. An dieser Stelle wird somit bereits deutlich, dass einzig textuelle Untersuchungen nicht konsequent das gewünschte Ergebnis erbringen.

5 Exemplarische Umsetzung relevanter Bedarfe 5.1.4 Versuchsaufbau und Daten für Gliederungen

Die Produktdaten des Tripelec dienen als Anwendungsbeispiel für diesen Versuch. Eine Ausführung zu dem Versuchsträger Tripelec findet sich in Abschnitt 5.2.3. Die Abbildung 28 zeigt ein Bild des physikalischen Aufbaus.

Abbildung 28: Foto eines ersten physischen Aufbaus des Tripelecs

Eine funktionale Gliederung des Produkts wird aus bestehenden Daten des Tripelecs übernommen und findet sich in leicht modifizierter Form als Tabelle im Anhang auf Seite VIV. Die in der Kommentarzeile vorliegenden Einträge stammen in der verwendeten Form ebenso aus dem Entwicklungsprojekt. An einigen Stellen wurde eine Übersetzung vom Englischen ins Deutsche vorgenommen, da die Analyse der Wort-Strings auf der deutschen Sprache beruht. Es fanden keine inhaltlichen Modifikationen der Einträge der Funktionen statt, um das Verhalten des implementierten Algorithmus zu testen. Die Funktionen Insassen transportieren und mechanisches Fahren unterstützen wurden ergänzt, denn die initiale Funktionsbeschreibung bezieht sich wesentlich auf elektrische Komponenten sowie die Steuerung des Fahrzeugs. Die vorliegenden CAD Bauteile sind hingegen offensichtlich für den Rahmen und die primären Fahrfunktionen erstellt worden. Somit hätte ein Versuch ohne Modifikation keine Ergebnisse zurückliefern können.

Die CAD Daten der Tabelle 21 entstammen ebenso dem Versuchsträger Tripelec. Die Benennung unter der Spalte CAD Bauteil entstammt in der Form exakt den originalen Versuchsdaten. Die Bemerkungen entstammen in der vorliegenden Form exakt einer Stückliste, folglich inhärenten Informationen. Die Zuordnung zur Funktion wurde durch die Autorin vorgenommen, diese dient der Kontrolle der Ergebnisse. Der Test wird dann positiv beurteilt, wenn mindestens vier von fünf Bauteilen korrekt zugeordnet werden können.

5 Exemplarische Umsetzung relevanter Bedarfe

Tabelle 21: CAD Bauteile für den Versuch der Zuweisung und Zuordnung zu Funktionen

CAD Bauteil Bemerkung Funktion Kugellager 61902-2RS-MAE Mädler Insassen transportieren DMG Motor ja Energie erzeugen Bowdenzugbracket 1.4301 Fahrzeug anhalten Rohr6 Insassen transportieren Kettenblatt LK64, 22Z Kaufteil, Bike24 mechanisches Fahren unterstützen

5.1.5 Versuchsergebnisse für Gliederungen

Dieser Abschnitt beschreibt die Ergebnisse, die der Algorithmus aus Abschnitt 5.1.2 zu dem Testablauf aus Abschnitt 5.1.4 erzeugt.

Zunächst wird der Algorithmus verwendet, um die Zuweisung der CAD Dateien jeweils einzeln lediglich auf Basis des Namens zu den Funktionen zu erproben. Die Ergebnisse dazu sind in Tabelle 22 zusammengestellt. Für alle Werte vom Kugellager bis zum Kettenblatt werden unklare bis negative Zuweisungen mit Werten kleiner 50% errechnet, siehe Spalte Wahrscheinlichkeiten.

Tabelle 22: Ergebnisse der CAD Zuweisung auf Basis des Dateinamens

CAD Bauteil erwartete vorgeschlagene Funktion Wahr- Funktion scheinlichkeit Lasten mit Anhänger 0,25 transportieren Kugellager 61902- Insassen System kontrollieren 0,25 2RS-MAE transportieren mechanisch in elektrische 0,4 Energie umwandeln linken Motor steuern 0,5 rechten Motor steuern 0,5 DMG Motor Energie erzeugen elektrische in mechanische 0,4 Energie umwandeln Bowdenzugbracket Fahrzeug anhalten keine Zuweisung größer 0,25 möglich Insassen transportieren 0,5 verbleibende Wegstrecke 0,15 Insassen Rohr6 errechnen transportieren mechanisch in elektrische 0,16 Energie umwandeln mechanisches Kettenblatt LK64, 22Z Fahren keine Zuweisung größer 0,25 möglich unterstützen

5 Exemplarische Umsetzung relevanter Bedarfe

Im weiteren Verlauf werden die bestehenden JT CAD Daten des Tripelecs mittels Laden in Autodesk und Exportieren als PRC konvertiert. Von dort werden sie in das SLK Werkzeug der Firma ODA eingelesen und folgend werden Strings des Dateiinhalts ausgelesen. Entweder durch Konvertierungsverluste oder dadurch, dass sie nie erzeugt wurden, weist kein vorliegenden Datensätze PMI Informationen auf. Lediglich der Motor und das Kugellager sind durch weitere Einzelteile als Baugruppe aufgebaut. Die Benennungen und Hierarchien liegen für diese beiden Datensätze somit zusätzlich vor. Die BREP Dateien werden nicht weiter durch das SLK Werkzeug in ihre Einzelteile aufgeteilt.

Durch das Ergänzen der Strings aus den PRC Dateien ergeben sich die, in Tabelle 23 zusammengestellten, Änderungen für die ermittelten Wahrscheinlichkeiten. Tatsächlich verbessern sich die Ergebnisse in der Form, dass sich die errechneten Wahrscheinlichkeiten zugunsten der tatsächlichen Zugehörigkeit verschieben. Ebenso wird an dieser Stelle zudem die für das Kugellager vorgesehene Funktion als möglicher Kandidat durch den Algorithmus vorgeschlagen, obschon der Vorschlag mit dem geringen Wert von 0,15 nicht besonders ausgeprägt ist. Ebenso werden die Aspekte der Motorsteuerung weniger stark mit 0,4 im Vergleich zu 0,6 gewichtet.

Tabelle 23: Ergebnisse der Zuweisung unter Verwendung der Datei inhärenten Informationen

vorgeschlagene Wahr- CAD Bauteil erwartete Funktion Funktion scheinlichkeit linken Motor steuern 0,4 rechten Motor 0,4 DMG Motor Energie erzeugen steuern elektrische in mechanische 0,6 Energie umwandeln

Lasten mit Anhänger 0,5 transportieren Kugellager 61902- Insassen System kontrollieren 0,25 2RS-MAE transportieren Insassen 0,15 transportieren

Obwohl zusätzliche Informationen vorhanden sind konnten die zuvor nicht allokierbaren Dateien weiterhin nicht zugewiesen werden. Es wird folglich deutlich, dass weitere Informationen aus dem Kontext der Verwendung erforderlich sind, um die Zuweisung adäquat zu bewerkstelligen.

5 Exemplarische Umsetzung relevanter Bedarfe 5.1.6 Versuchsaufbau und Daten für Metadaten

Dieser Abschnitt stellt die Versuchsdaten und den Aufbau des Versuchs für die Zuweisung bereits beschriebener Design Artefakte zu weiteren Ordnung gebenden Strukturen vor.

Der betrachtete Anwendungsfall für steuernde Metadaten stammt aus der Exportkontrolle von Geräten und Anlagen zur Energieerzeugung. Produzierte Waren, also Geräte, Anlagen oder Produkte, werden auf landesspezifische Ein- und Ausfuhrbedingungen geprüft. Die operative Umsetzung erfolgt in Realität durch die bauteilindividuelle Bewertung von Domänenexperten des Engineerings und der Exportkontrolle.

Im Versuch werden Produktdatenblätter herangezogen, die fertige Produkte oder Erzeugnisse repräsentieren. In den Datenblättern finden sich unstrukturierte Angaben in Form von Fließtexten und Bildern wieder. Die für den Versuch verwendeten Datenblätter liegen im Anhang auf Seite III vor.

Abbildung 29: Taxonomie der Zolltarifnummern

Die Zolltarifnummern30 folgen einer hierarchisch gegliederten Anordnung, wie in Abbildung 29 dargestellt. Die Beziehungen sind „hat“ Beziehungen mit einer 1:n Relation, folglich hat eine Unterposition n Nummern. Die Klassen haben jeweils eine Identifikationsnummer, die nach unten vererbt wird, sowie einen textuellen Eintrag. Im rechten Teil der Abbildung sind die Zolltarifnummern exemplarisch befüllt. In dem Beispiel sind keine Unterpositionen vorhanden. Unter dem Abschnitt XVI sind alle Arten von Maschinen aggregiert.

30 Vollständige Liste online verfügbar unter: https://www.zolltarifnummern.de/2020.

5 Exemplarische Umsetzung relevanter Bedarfe

Im Rahmen der technischen Validierung werden der Anwendung aus Abschnitt 5.1.3 fünf unterschiedliche Produktdatenblätter durch den Anwender zur Zuordnung übergeben. Die Datenblätter wurden von einem Unternehmen gestellt, somit sind auch die zu erwartenden Ergebnisse der Anwendung bekannt. Die Produktdatenblätter und ihre Zuordnung sind in der untenstehenden Tabelle 24 wiedergegeben.

Tabelle 24: Versuchsaufbau für die Zuweisung von Produktdatenblättern

Produktdatenblatt Benennung Zolltarifnummer 84501111 Waschvollautomaten zum Waschvollautomat Waschen von Wäsche, Datenblatt Frontlader, mit einem GWN 48440 W Fassungsvermögen an Trockenwäsche von <= 6 kg oder weniger 84272011 Elektro-Gabelstapler Datenblatt_edia-em Gabelstapler, Stapelkraftkarren, geländegängig 85014080 Einphasen- Einphasen Wechselstrommotor FBS 56 Einphasen- Wechselstrommotor B 2 Wechselstrommotoren mit einer Leistung von > 750 W 901890 Beatmungsgerät Produktdatenblatt andere Instrumente, Vivo 55 Vivo 55 Apparate und Geräte 84672210 Elektro-Kettensäge uc3551ak Handkettensägen mit UC3551AK eingebautem Elektromotor

Die verwendeten Produktdatenblätter sowie die erwartete Zuordnung sind in der Tabelle 24 zusammengestellt. Die Spalte Produktdatenblatt gibt die Bezeichnung des technischen Produkts wieder. In der Spalte Benennung ist der Titel des Produktdatenblatts abgelegt, so wie er durch das jeweilige Unternehmen vorgenommen wurde.

Die Bezeichnung eines Produkts findet sich häufig, aber nicht durchgängig in den Produktdatenblättern wieder. Mitunter werden ähnliche oder synonyme Bezeichnungen verwendet, etwa Vollwaschautomat und Frontlader in der Kategorie der Waschmaschinen. Ebenso ist aus der Bezeichnung nicht stetig genau ersichtlich, worum es sich handelt. Dass beispielsweise die Elektrokettensäge eine Handkettensäge ist, wird durch die Betrachtung des zugehörigen Bildes im Datenblatt deutlich. Ebenso finden sich Einheiten nicht konsequent in der gleichen Größenordnung in den Produktdatenblättern und Zolltarifnummern, demnach

5 Exemplarische Umsetzung relevanter Bedarfe werden für die Leistung des Wechselstrommotors in dem Produktdatenblatt [kW] angegeben, in der Zolltarifnummernliste hingegen [W].

5.1.7 Versuchsergebnisse für Metadaten

Durch die Anwendung des Algorithmus, wie er in Abschnitt 5.1.3 Beschreibung findet, konnte eine Zuordnung entsprechend der Tabelle 25 - 26 erzielt werden. Die beiden anderen Tabellen sind im Anhang auf Seite IV zu finden. Die Spalte der erwarteten Zolltarifnummer entspricht den Vorgaben aus dem Versuchsaufbau und wird an dieser Stelle lediglich wiederholt. Die Rückgabe des Algorithmus findet sich in der Spalte der vorgeschlagenen Zolltarifnummer. Die Spalte % gibt den gefundenen Wahrscheinlichkeitswert der Zuordnung wieder.

Die in der Tabelle 25 rückgegebenen Positionen der Zolltarifnummern weisen eine Streuung über mehrere Bereiche auf. Insbesondere sind die Werte, die ohne TF-IDF Maß errechnet wurden offensichtlich nicht korrekt.

Tabelle 25: Zusammenstellung der Versuchsergebnisse der Zuweisung von Zolltarifnummern für den Vollwaschautomaten

Produkt- erwartete Zolltarif- vorgeschlagene Zolltarifnummer % datenblatt Nummer 8450 Maschinen zum Waschen von Wäsche, auch mit 0,6 Trockenvorrichtung; Teile davon 84501111 845011 Waschvollautomaten zum Waschen von Waschvollautomaten zum Waschen von Wäsche, mit einem 0,8 Waschvollautomat Wäsche, Frontlader, mit einem Fassungsvermögen an GWN 48440 W Fassungsvermögen Trockenwäsche von <= 10 kg ... an Trockenwäsche 8517 oder Teilen von automatischen von <= 6 kg oder Datenverarbeitungsmaschinen 0,2 weniger verwendeten Art 8456 0,1 Werkzeugmaschinen

Der Algorithmus gibt diese Werte zurück da er für die Positionen 8517 und 8456 Zuordnungen für die Einheiten finden kann, ebenso stimmen die Antriebsarten überein sowie der Begriff Maschine. Der Algorithmus konnte die unterste Hierarchiestufe der Zolltarifnummern nicht korrekt zuordnen. Da dennoch die beste errechnete Wahrscheinlichkeit mit dem tatsächlichen Wert übereinstimmt wird das Ergebnis positiv bewertet.

In der Tabelle 26 sind die Ergebnisse für den Wechselstrommotor zusammengestellt. An dieser Stelle sind insgesamt, verglichen zur Waschmaschine, höhere Wahrscheinlichkeiten

5 Exemplarische Umsetzung relevanter Bedarfe durch den Algorithmus zurückgegeben. Weiterhin sind die Zuordnungen ebenso dem korrekten Level der Positionsnummer zugewiesen worden, die exakte Nummer konnte durch den Algorithmus gefunden werden. Für diesen Fall ergab sich eine exakte String Übereinstimmung zwischen Produktdatenblatt sowie Zolltarifnummern und demnach musste nicht auf ähnliche Begriffe zurückgegriffen werden. Die Verwendung des TF-IDF Maßes bringt in diesem Fall keine Verbesserung oder Verschlechterung.

Tabelle 26: Zusammenstellung der Versuchsergebnisse der Zuweisung von Zolltarifnummern für den Wechselstrommotor

Produkt- erwartete Zolltarif- vorgeschlagene Zolltarifnummer % datenblatt nummer 85014080 Einphasen-Wechselstrommotoren 0,8 mit einer Leistung von > 750 W 850140 Einphasen-Wechselstrommotoren 0,8 85014080 mit einer Leistung von > 37,5 W Einphasen- Einphasen- 85014020 Wechselstrom- Wechselstrommotoren Einphasen-Wechselstrommotoren motor FBS 56 B 2 mit einer Leistung von 0,8 mit einer Leistung von > 37,5 W bis > 750 W <= 750 W ... 85011093 Wechselstrommotoren mit einer 0,7 Leistung von <= 37,5 W (ausg. Synchronmotoren bis 18 W) ...

Die Tabelle 27 zeigt die Ergebnisse für das Beatmungsgerät.

Ähnlich zu der Waschmaschine haben auch an diesem Punkt einige Begriffe den Algorithmus irritiert. Das Wort Geräuschpegel in Kombination mit der Einheit dB(A) erzeugte die Zuweisung zu der Position 90304000, in der Geräte zur Erfassung des Geräuschpegels gelistet werden. Die Ähnlichkeitssuche konnte in Zusammenwirkung mit dem TF-IDF Maß durchweg eine Zuordnung zum Bereich der medizintechnischen Produkte erzeugen. Obschon die korrekte Zolltarifnummer nicht gefunden werden konnte stimmt die Tendenz der Wahrscheinlichkeiten mit den realen Gegebenheiten überein.

5 Exemplarische Umsetzung relevanter Bedarfe

Tabelle 27: Zusammenstellung der Versuchsergebnisse der Zuweisung von Zolltarifnummern für das Beatmungs- gerät

Produkt- erwartete vorgeschlagene Zolltarifnummer % datenblatt Zolltarif- nummer 9018 medizinische, chirurgische, zahnärztliche oder tierärztliche Instrumente, Apparate und Geräte, einschließlich Szintigrafen und 0,7 andere elektromedizinische Apparate und Geräte, sowie Apparate und Geräte zum Prüfen der Sehschärfe 90181910 901890 Elektrodiagnose-Überwachungsapparate und Beatmungs- andere Elektrodiagnose-Überwachungsgeräte, zur 0,7 gerät Instrumente, gleichzeitigen Überwachung von zwei oder Vivo 55 Apparate und mehr physiologischen Parametern Geräte 9018 medizinische, chirurgische, zahnärztliche oder tierärztliche Instrumente, Apparate und Geräte, einschließlich Szintigrafen und 0,6 andere elektromedizinische Apparate und Geräte, sowie Apparate und Geräte zum Prüfen der Sehschärfe 90304000 - Instrumente, Apparate, Geräte 0,4

5.1.8 Beurteilung der Ergebnisse zur Verwendung im InADM

Der Vergleich der beiden Algorithmen, des Java basierten, mit klassischer regelbasierter Indexierung einerseits, und des NLP basierten für die Zuweisung von Produktdatenblättern zu den Zolltarifnummern andererseits, verdeutlicht, dass beide fehlerbehaftet sind. Der erste erlangt in Summe eine Genauigkeit der Zuweisung von 70 %, der NLP basierte Algorithmus erzielt 75 % korrekte Zuweisung. Diese Zahlen gelten für den Fall, dass jeweils der Dateiinhalt mitbetrachtet wird. Zunächst fällt auf, dass reine Texte mit deutlich höherer Präzision klassifiziert und analysiert werden können, etwa mit 95 % in Abhängigkeit von dem Anwendungsfall (Carstensen 2010, S. 625). Fallbeispiele, die ohne Fachsprache auskommen sind präziser, da die Datenbasis größer ist. Fachsprachliche Fallbeispiele fallen eher schlechter aus. Die an dieser Stelle erzielten Ergebnisse erfordern demnach noch deutliche Nacharbeiten, bis eine industrielle Tauglichkeit erzielt werden kann. Wiederum ist eine gewisse Anzahl an Fehlern durch den Algorithmus akzeptabel, da ein Anwender die Verwendung quittiert. Der Zuordnungsvorschlag wird in der Search & Browse Umgebung bzw. dem Plug-In des Autoren Werkzeugs bestätigt. Mit dieser Bestätigung löst der Anwender folgend weitere anhängige Vorgänge – in diesem Kontext beispielsweise Verzollung und Verpackung - aus.

5 Exemplarische Umsetzung relevanter Bedarfe

Hinsichtlich der Versuche mit den Zolltarifnummern wird klar, dass die zugrundliegenden erlernten NLTK Bibliotheken für die deutsche Sprache nicht ausreichend Begriffe, Synonyme und Abstraktionsmechanismen für die maschinenbauliche Fachsprache beinhalten. Die gleichzeitige Verwendung von direkten Regeln, wie Suchen und Zuweisen von Strings, erweist sich in der Kombination als sehr hilfreich.

Zur Verbesserung der Zuweisungsergebnisse müssten Wissensgrafen, Browning Cluster oder Ontologien herangezogen werden. Diese bieten die Möglichkeit, ähnliche Begriffe im Sinne von synonymer oder verwandter Bedeutung ebenfalls in Erwägung zu ziehen. Weiterhin bieten sie die Möglichkeit, generell die Verwendung von beispielsweise Maschinenelementen für gewisse Funktionen abzubilden. Ein bestimmtes Kugellager oder Gelenk, ermöglicht beispielsweise eine freie Bewegung in einer bestimmten Richtung. Diese Art von Zuweisungen ermöglicht es, über die dateiinhärenten Informationen generisch geltende Informationen heranzuziehen. Damit wird das Vorgehen der Maschine dem ähnlicher was ein Mensch bei der Zuweisung leistet: das Interpretieren der eigentlichen Datei sowie die Verwendung des generellen Hintergrundwissens, das ein Mensch durch das Studium oder die Tätigkeit in einem Unternehmen erlangt hat.

Für den speziellen Bereich der Zolltarifnummern wirken Formulierungen wie: „alle Motoren, außer elektrische“ irritierend auf die Algorithmen, da die sprachlich intendierten Mengen nicht korrekt abgebildet wurde. Diese Art der „sprachlichen Mengenbildung“ existiert und müsste für eine industrielle Anwendung ergänzt werden, um beispielsweise die Klasse aller Maschinen XY ohne die Subklasse Z korrekt zu benennen.

Zum gegenwärtigen Zeitpunkt scheint zu gelten, dass Korpora der maschinenbaulichen Fachsprache noch nicht umfänglich frei verfügbar existieren. (Baroni und Bernadini 2004) zeigen einen Mechanismus auf, um domänenspezifische Texte auf Basis von Fachvokabular aus dem WWW zu generieren. NLP Verfahren wurden initial geschrieben, um vollständige Fließtexte zu analysieren. Jedoch sind Texte oder Dokumente des Ingenieurswesens zudem wesentlich durch Einheiten und Abkürzungen geprägt. Der Umgang mit Formeln und Zeichen wird im NLP nicht umfänglich verwendet. Die an dieser Stelle verwendeten Bibliotheken sind für die deutsche Sprache erstellt worden. Für einen industriellen Einsatz ist eine Mehrsprachigkeit erforderlich, die hinsichtlich einer Weiterentwicklung berücksichtigt werden muss.

In Summe zeigen die Versuche zur semantischen Vernetzung auf, dass eine automatische Zuweisung gegenwärtig einzig durch eine Kombination aus regelbasierten Verfahren und NLP und ML basierten Verfahren bestehen kann.

5 Exemplarische Umsetzung relevanter Bedarfe

Der Rechenaufwand kommt durch die Verwendung von Indizes sowie die verpflichtende Bildung der Korpora vor dem eigentlichen Abgleich zustande. Durch dieses Vorgehen können Rückgabezeiten von etwa 3-4 Sekunden für das Beispiel der Zolltarifnummern sowie 0,5 -1 Sekunde für das Beispiel der Gliederungen gemessen werden. Da auch in der geplanten Anwendung im InADM jeweils einzelne Design Artefakte mit bestehenden Strukturen verlinkt werden sollen, werden leicht verbesserte, aber dennoch ähnliche Rückgabezeiten erwartet. Der Unterschied zwischen den beiden Methoden wird in der Verwendung der Programmiersprache vermutet. Bei der Erstellung der Algorithmen liegt allerdings die Antwortzeit oder eine Optimierung in diese Richtung nicht im Fokus der Entwicklung, sodass sich an dieser Stelle Potentiale abzeichnen.

Die Überführung semantischer Technologien auf die Interpretation von Design Artefakten stellt ein interdisziplinäres Forschungsfeld für die Informatik und die Ingenieurswissenschaften dar. Einen Einstieg bietet Software Code, der sich leicht interpretieren lässt und zu dem es bereits Verfahren gibt. Eine Prüfung zum Übertrag dieser Methoden auf den Kontext der mechanischen Design Artefakte (ECAD, MCAD, Simulationsdaten) stellt weiteren Forschungsbedarf dar.

Die Rückgabe der Zusammengehörigkeitsinformation erfolgte im Rahmen der Versuche lediglich in der Testumgebung. Eine reale Umsetzung im Sinne des InADM Konzepts erfordert eine tatsächliche Verlinkung des gefundenen Klassenwerts in eine „gehört-zu“ Beziehung in einer Datenbank. Darüber hinaus ist für die Weiterführung der Arbeiten zudem eine Implementierung der Nutzeroberfläche erforderlich. Beide Maßnahmen münden im nächsten Schritt zu einer Überprüfung der Nutzbarkeit, die am Beispiel mehrerer Produkte oder Branchen erfolgen sollte.

Für den Nachweis der Steuerung von Produktdaten hinsichtlich nachfolgender Prozesse wurde zunächst ausschließlich ein konkreter Anwendungsfall – in diesem Kontext der Exportkontrolle - appliziert. Es wäre zu überprüfen, ob in der Praxis tatsächlich eher stetige Rahmenbedingungen vorliegen, wie es der Fall für die Exportkontrolle ist. Sollte sich herausstellen, dass sich die Ordnungskriterien häufig ändern, ist ein Datenverwaltungskonzept zu etablieren und eine Verwaltung innerhalb des InaDM zu bedenken. Darüber hinaus ist eine Untersuchung erforderlich, in wie fern ein fortgeschrittener Suchvorgang (Enterprise Search) als Basis für ein Vorschlagssystem zu verwenden wäre. Eine weitere Fragestellung zu diesem Themenkomplex ist bei einer Gegenüberstellung, auf welche Art ein Anwender seine Verantwortung für die Verstetigung der Metainformation besser darstellen kann.

5 Exemplarische Umsetzung relevanter Bedarfe 5.2 Nutzerinteraktion durch einen Chat Bot

Die Zuweisung und Steuerung der Varianz eines Produkts soll, mit dem InADM, automatisiert erfolgen. Die tatsächliche Verwendungsmöglichkeit entsteht bei der Erstellung des Design Artefakts und wird, entsprechend dem Konzept, durch den Autor des Design Artefakts bei seiner Übergabe zur Speicherung angegeben (Paradigma 1, Tabelle 13).

Weiterhin sieht das Konzept vor, dass ein Ingenieur die Verwendungsinformation beim Speichervorgang aus dem Autorenwerkezug heraus übergibt. Die technische Umsetzung erfolgt als schriftliche natürlich-sprachliche Eingabe in einen Chat Bot. (Rozga 2018, S. 6) definiert Chat Bots als Programme, die natürlich sprachliche Eingaben eines Anwenders aufnehmen und Text oder interaktive Medien, wie Videos, zurückgeben. Die Kommunikation kann entweder über einen Messenger Dienst oder über ein Sprachgerät erfolgen. Der Chat Bot des InADM ist als Plug- In in ein CAD Werkzeug eingebettet, um von dort die Nutzer Interaktion zu realisieren (vgl. Abbildung 30). Neben der Kommunikation verfügt der Chat Bot über Funktionalitäten zum Ablegen von Daten auf der Seite des InADM. Damit werden die PDM Funktionalitäten in einer, für den Anwender nicht sichtbaren, Form unterstützt. Auf der Seite des InADM wird die Spracheingabe mittels des Moduls Interpretation der Eingabe analysiert und in Befehle zur Datenablage und Rückmeldungen an den Anwender umgesetzt.

Abbildung 30: Übersicht der Chat Bot Architektur

Wenn die Intention des Anwenders festgestellt werden kann, erfolgt über den Chat Bot die Anweisung zur Speicherung der entsprechenden Daten. Wenn der Befehl nicht erfolgreich interpretiert werden kann, erfolgt eine Kommunikation mit dem Anwender.

Im folgenden Abschnitt 5.2.1 werden die technologischen Grundlagen für die Interpretation und mögliche Korrektur der Sprache betrachtet. Im Abschnitt 5.2.2 folgt die Umsetzung in Chat Bot für das Variantenmanagement. Das Kapitel wird komplettiert mit der Versuchs-

5 Exemplarische Umsetzung relevanter Bedarfe durchführung in Form einer Probandenstudie, die die Anwendbarkeit überprüft. Abschließend werden die Versuchsergebnisse dargestellt und interpretiert.

5.2.1 Funktionsweise der natürlichen Sprachverarbeitung

Natürliche Sprachverarbeitung oder Natural Language Processing (NLP) ist ein Teilgebiet der Informatik, welches die Regeln der Linguistik in Computerprogrammen anwendet (Eisenstein 2019, S. 4). Methoden des Maschinellen Lernens werden herangezogen, um die Regeln einer Sprache auf Basis von Texten zu erlernen und auf natürliche Sprache anzuwenden. Diesem Prinzip folgt ebenso der Chat Bot für die Initialisierung von Varianten. Dieser Abschnitt betrachtet zwei Teilaspekte der Natürlichen Sprachverarbeitung, die innerhalb des Moduls zur Interpretation der Sprache verwendet werden. Dies ist einerseits die Analyse und das Ableiten eines Textverständnisses, andererseits die Korrektur von Spracheingaben. Alle Arbeiten werden für die deutsche Sprache durchgeführt.

Tokenization

Text, der analysiert werden soll, muss zunächst in interpretierbare, und für Computer identifizierbare Einheiten separiert werden. Dieser Vorgang wird Tokenization genannt (Eisenstein 2019, S. 74). Häufig, aber nicht grundsätzlich, umfasst ein Token ein Wort. Ein Beispiel für ein Token aus mehreren Worten ist „Spaghetti Carbonara“, beide Worte gehören zusammen. Es wird ein bestehender Algorithmus aus der phython-eigenen „re“ Bibliothek verwendet, dieser ist nicht speziell für die deutsche Sprache adaptiert.

Textnormalisierung

Die Textnormalisierung führt Modifikationen durch, die eine notwendige Vorbereitung für die Analyse der Worte darstellt. Dazu zählen beispielweise das vollständige Kleinschreiben aller Begriffe oder die Rückführung von Zahlen in ein bestimmtes Schema (Schreibweise 1.000 → 1000). Eine Subklasse der Textnormalisierung ist die Reduktion eines Tokens oder Wortes auf sein Lemma 31 . Dieses sogenannte „lemmatizing“ wird in diesem Kontext verwendet, um identifizierte Verben in den Infinitiv zu konjugieren. Es wird ein bestehender Algorithmus aus der „pattern“ Bibliothek (Emmery 2018) des CLISP der Universität Antwerpen für die deutsche Sprache verwendet.

Semantisches Verständnis der Spracheingabe

Die Bedeutung eines Textes kann auf unterschiedliche Weise durch ein Computerprogramm nachempfunden werden. Eine Möglichkeit ist, Worte eines Satzes seiner grammatikalischen

31 Lemma: Begriff der Linguistik, auch Nennform. Ein Lemma bezeichnet die Grundform eines Wortes, folglich diejenige Wortform, unter der man einen Begriff in einem Nachschlagewerk findet.

100

5 Exemplarische Umsetzung relevanter Bedarfe

Struktur, folglich der Syntax, zuzuweisen und derart die Verwendung im Kontext zu ermitteln. (Eisenstein 2019, S. 167) empfiehlt dieses Vorgehen insbesondere für Fälle, wenn limitierte Textquellen vorliegen, wie es für das NLP im deutschsprachigen Maschinenbau aktuell der Fall ist. Das Part-of-Speech-Tagging (POS) weist Tokens, also zuvor identifizierten Worten, eine Wortart (Verb, Nomen, etc.) zu. (Cutting 1992, S. 136) schlägt ein regelbasiertes POS Verfahren vor, das manuell programmiert wird und in ähnlicher Form in dieser Arbeit Anwendung findet. Weitere Methoden, wie etwa statistische oder solche, basierend auf selbstlernenden neuronalen Netzwerken, bieten Alternativen (Adhvaryu und Balani 2015).

Die ohne Kontext annotierten tags weisen bislang keinen Zusammenhang zueinander auf (Eisenstein 2019, S. 170). Durch das Parsing werden syntaktische Abhängigkeiten zwischen den tags zugewiesen (Ioannou 2020, S. 25). Das Parsing verwendet einen Graphen, der die Syntax abbildet und diesem Worte zuweist (Kempen 1998, S. 214). Ein Beispiel nach (Eisenstein 2019)(Eisenstein 2019)(Eisenstein 2019)(Eisenstein 2019, S. 297) ist in Abbildung 31 für einen englischen Satz dargestellt. Die Rückgabe des Taggings besteht für dieses Beispiel aus dem Satz „S“, aufgeteilt in drei „tags“: Adverbial Phrase, Noun Phrase, Verb Phrase.

Am Beispiel des Verbs wird die syntaktische Beziehung zwischen Prädikat und Objekt für die englische Grammatik deutlich.

Abbildung 31: Parsing - Graph für einen englischen Satz nach Eisenstein

In dieser Arbeit wird die bestehende Parsing-Funktion „pattern“ (Emmery 2018) des CLISP der Universität Antwerpen benutzt. Diese inkludiert ein POS Tagging für die deutsche Sprache.

Um die Parsing Zuordnung zu unterstützen wird dem Chat Bot zusätzlich eine Bibliothek von häufig auftretenden Verben zur Verfügung gestellt, die in dem Kontext der Verknüpfung von Design Artefakten zu Varianten relevant sind. Diese sind beispielsweise zuweisen, verknüpfen, verlinken etc. Weiterhin werden die Worte „zu“, „bei“, „an“, „in“ und „mit“ aus dem

101

5 Exemplarische Umsetzung relevanter Bedarfe

Eingabetext des Anwenders gefiltert und für die Zuweisung verwendet, indem diese dem Objekt „tag“ zugeordnet werden.

Das Verb wird in der Anwendung des Chat Bot für die Variantenzuweisung verwendet, um die auszuführende Aktion „Speichern und Verlinken“ zu einer bestimmten Variante auszulösen. Das Subjekt wird verwendet, um das entsprechende Design Artefakt zu verlinken. Das Objekt wird verwendet, um die korrekte Variante, der das Design Artefakt zugeordnet werden soll, anzusprechen.

Bag-of-Words Methode

Gemäß (Euzenat und Shvaiko 2007, S. 93) wandelt die Bag-of-Words Methode textuelle Bausteine in Vektoren und damit in mathematisch verwertbare Einheiten um. Dazu werden Tokens, hier also relevante Worte festgelegt. Für jedes Token wird eine Achse im Raum angelegt. Es entsteht somit ein n-dimensionaler Raum, in den Richtungen Halter, Verlängerungsstange1, Verlängerungsstange2 und Feder (siehe Abbildung 32). Eine Abbildung der Variantenvektoren BOW 1 und BOW 2 erfolgt, indem für jeden gefundenen Treffer eines Tokens ein Schritt auf der entsprechenden Achse gezählt wird.

Abbildung 32: Schematische Darstellung der Bag-of-Words Methode am Beispiel der Gewindespindelauspress- einheit

Die in Abbildung 32 dargestellten Vektoren BOW1 (0,1,1,1) und BOW2 (1,0,1,1) repräsentieren gegenwärtig jeweils eine Variante der Gewindespindelauspresseinheit und sind numerisch auswertbar.

102

5 Exemplarische Umsetzung relevanter Bedarfe

Mit der Bag-of-Words Methode werden im später applizierten Anwendungsfall die Nummerierungen von Bauteilen und die Gesamtheit einer Variante somit informationstechnisch für die Analyse hinsichtlich der Ähnlichkeit der Vektoren vorbereitet.

Ähnlichkeit von Worten

Mit Hilfe der Kosinus Ähnlichkeit (Han et al. 2011) werden zwei Worte i und j auf ihren Bezug zueinander untersucht. Dazu werden zunächst mithilfe der Bag-of-Words Methode zwei

Wörter i und j in Vektoren �� und �� abgebildet. Mittels der Formel (1) wird der Cosinus Wert zwischen den beiden Wortvektoren �� und �� ermittelt, dessen Rückgabewert liegt zwischen 0 und 1.

�� ∗ �� cos(� , � ) = (1) � � 2 2 ||��|| ∗ ||��|| Die Rückgabewerte signalisieren im vorliegenden Kontext die Bedeutungsähnlichkeiten der Worte. (Eisenstein 2019, S. 322) stellt Arbeiten mehrerer Forschergruppen zusammen und benennt die, in Tabelle 28 wiedergegebenen, Werte. Aus der Tabelle wird anhand der höheren oder niedrigeren Ähnlichkeitswerte der Worte ersichtlich, ob diese inhaltlich miteinander in Verbindung stehen oder nicht.

Tabelle 28: Ergebnisse der Kosinus Ähnlichkeit nach Eisenstein

Wort 1 Wort 2 Ähnlichkeit money cash 0,915 love sex 0,677 stock jaguar 0,092 lad brother 0,446

Im Kontext des Chat Bots wird die Kosinus Ähnlichkeit verwendet, um den Zusammenhang zwischen der Benennung der Variante und dem Namen des Design Artefakts zu plausibilisieren. Es wird die „similarity“ Funktion der „spacy32“ Bibliothek verwendet. Diese beruht auf der Cosinus Ähnlichkeit. Die Bibliothek geht zurück auf das Softwareunternehmen Explosion AI33 (Honnibal).

Bildung eines Korpus

Als Grundbasis, beispielsweise für die Korrektur der Worte, werden ein Wörterbuch, sowie ein Textkorpus benötigt. Als Wörterbuch wird das online gemeinfrei verfügbare Wörterbuch der

32 https://spacy.io. 33 https://explosion.ai.

103

5 Exemplarische Umsetzung relevanter Bedarfe deutschen Sprache von (Schreiber 2010) verwendet. Es dient dem Auffinden von Nichtworten durch einen Abgleich.

Um einen Referenzkorpus für das Variantenmanagement mit den in diesem Kontext relevanten Worten des Versuchsbeispiels aufzubereiten und mit geeignet großen Datenumfängen auszustatten, wurden mehrere Texte kombiniert und präpariert. Die Basis bildet der deutsche Korpus aus dem Projekt Wortschatz (ASV - Automatische Sprachverarbeitung Leipzig 1998). Dieser besteht aus Internetdokumenten wie Wikipedia und ist zudem partiell aus limitiert zugänglichen Dateien zusammengestellt. Er ist als creative commons Lizenz u.a. für wissenschaftliche Zwecke verfügbar. Darüber hinaus wird der Wortschatz mit dem Standardwerk Dubbel (Beitz und Küttner 1987) ergänzt, um den maschinenbaulichen Kontext besser widerzuspiegeln. Zusätzlich sind die Variantenlisten sowie Stücklisten des Tripelec (siehe Abschnitt 5.2.3) inkludiert, um die zu einem späteren Zeitpunkt tatsächlich verwendeten Worte aufzufinden. Nachfolgend erfolgt eine Bereinigung des Korpus, wie sie beispielsweise bei (Kukich 1992, S. 380) vorgeschlagen wird- zunächst hinsichtlich der Zahlen, Formeln sowie nicht arabischen Schriftzeichen. Weiterhin werden nicht existierende Wörter, auch Nichwort-Fehler (engl. auch als non-word-errors (NWE)), mittels des Wörterbuchs identifiziert und gekennzeichnet. Zusätzlich werden Stoppwörter, wie und oder da, eliminiert, entsprechend dem Vorgehen von (Schäfer 2013, S. 7). Der Referenzkorpus umfasst ein Volumen von insgesamt 3GB bereinigtem Text und ist auf Deposit Once (Fresemann und Ioannou 2020) hinterlegt.

Bildung eines Index

Aus dem Referenzkorpus wird für eine später folgende statistische Analyse eine Liste im TF- IDF Format erstellt. Dazu wird jedem Token, also jedem Wort des Referenzkorpus, ein entsprechender Wert zugewiesen. Die Berechnung erfolgt über das TF-IDF Maß (siehe Abschnitt 5.1.1) für die zugrunde liegende Berechnung. Es entsteht folglich eine Liste mit zwei Spalten, einerseits mit dem Wort und andererseits mit dem TF-IDF Maß. Das Maß gibt die Relevanz des Wortes für einen bestimmten Text wieder. Für dieses Beispiel hat das Token Kindersitz ein hohes TF-IDF Maß, da es eine einschlägige Variante des Anwendungsbeispiels ist. Die resultierende Tabelle dient zur Autokomplettierung und -korrektur von Wörter.

Autokorrektur der Spracheingabe

Die Eingaben eines Anwenders in den Chat Bot sollen von diesem korrekt verstanden werden. Dazu ist die Maschine auf eine korrekte Nutzereingabe angewiesen. Da Menschen fehlerhaft agieren, benötigt ein Chat Bot stets ein Korrekturmodul der Eingaben.

Das Vorgehen zur Korrektur von Nichtworten (NWE) ist in Abbildung 33 zusammengestellt, es basiert auf den Ausführungen von (Kukich 1992, S. 380) und (Carstensen 2010, S. 350).

104

5 Exemplarische Umsetzung relevanter Bedarfe

Im ersten Schritt Überprüfen der Schreibweise (Tippfehler) werden alle nach der Stoppwort Eliminierung verbleibenden Wörter der Nutzereingabe gegenüber dem Wörterbuch auf ihre Existenz geprüft. Wurden alle Wörter gefunden, endet die Funktion. Wurde ein Wort nicht gefunden, werden mögliche Ersatzworte gebildet. Das geschieht über eine Levenshtein- Distanz (Carstensen 2010), Details der Funktionsweise finden sich in Abschnitt 5.1.1.

Auf diese Weise entstehen neue Ersatzwörter, die wiederum nur zugelassen werden, wenn sie im Wörterbuch existieren. Weiterhin wird die Liste der gefundenen Kandidaten so reduziert, dass jedes Kandidatenwort jeweils lediglich einmal vorliegt.

Im Schritt Wahrscheinlichkeit der Ersatzwörter bestimmen wird die Wahrscheinlichkeit des Kandidatenwortes als Ersatz für das Nichtwort ermittelt. Grundlegend bietet das Bayes- Theorem die Möglichkeit, die Wahrscheinlichkeit des Auftretens eines bestimmten Phänomens oder Zustandes unter Randbedingungen zu ermitteln (Ertel 2016, S. 78). (Ertel 2016)Für diesen Kontext kann demnach das Auftreten eines bestimmten Wortes in einem bestimmten Text ermittelt werden. Voraussetzung dafür ist, dass die zu prüfenden Phänomene oder Zustände unabhängig voneinander sind.

Abbildung 33: Übersichtsschaubild zur Erkennung und Korrektur von Tippfehlern

(Eisenstein 2019, S. 23) verwendet das Theorem für Wortvektoren und deren Kontext, indem er die Wahrscheinlichkeiten bildet und den maximalen Wert zurückgibt (2).

� � = �� ∏ �(�, �; �) (2) �=1 In der Formel nach Eisenstein wird ein Produkt gebildet aus der Wahrscheinlichkeit p, mit der die Kandidatenwörter (A und B) im Referenzkorpus (�) vorliegen. Durch die zuvor errechnete Levenshtein-Distanz werden die n Wörtern in den Referenzkorpus aufgenommen, die eine Modifikation innerhalb des Wortes aufweisen. Diese Argumentation zur Verwendung von Wörtern mit einer Levenshtein-Distanz von 1 geht auf (Damerau 1964, S. 176) zurück.

105

5 Exemplarische Umsetzung relevanter Bedarfe

Praktisch kann man sich diesen Zusammenhang für das Kandidatenwort A = Speichere, und den NWE B1 = Spiechere, oder den NWE B2= Spoechere überlegen. Die Wahrscheinlichkeit P(B1|A) mit der das Wort speichere anstelle des Wortes spiechere gemeint war, ist höher als die für spoechere.

Die Auswahl eines Kandidaten erfolgt über den maximalen Wert des am Wahrscheinlichsten auftretenden Wortes. Dieses wird dem Anwender als Vorschlag zurückgegeben und die Funktion der Sprachkorrektur endet.

5.2.2 Anwendung auf das Variantenmanagement

Dieser Abschnitt beschreibt den technischen Aufbau eines Chat Bots, der die Anwender bei der Verlinkung von Design Artefakten mit Varianten unterstützt. Der Aufbau des Zusammenspiels zwischen CAD und PDM Umgebung erfolgt entsprechend der Abbildung 30, unter Verwendung der technologischen Grundlagen aus Abschnitt 5.2.1.

Die Implementierung des Chat Bots erfolgt in C# sowie der Python Umgebung Idle 3.7. Das Modul chat bot in Abbildung 34 ist in C# erstellt und realisiert das Plug-In zu Fusion 360, die Module language, correction und logic realisieren die eigentliche Sprachverarbeitung auf Basis der zuvor benannten, bestehenden Bibliotheken. Der Softwarecode findet sich als digitaler Anhang zu dieser Arbeit in (Fresemann und Ioannou 2020). Die Abbildung 34 stellt die Funktionsweise des gesamten Chat Bots als Sequenzdiagramm dar.

Abbildung 34: Sequenzdiagramm des Chat Bots

Zunächst werden die einzelnen Wörter der Nutzereingabe vom Chat Bot an das language Modul gegeben und auf ihre Existenz geprüft. Um eine bessere Akzeptanz zu erlangen werden

106

5 Exemplarische Umsetzung relevanter Bedarfe fehlende Lehrtasten oder fälschlicherweise zusammengeschriebene Wörter automatisch korrigiert. Werden weitere Nichtworte identifiziert, wird durch das correction Modul ein Vorschlag für ein alternatives Wort ermittelt. Dieses wird über den Chat Bot zurück an den Nutzer gegeben. Dafür werden unterschiedliche Sätze verwendet „bitte korrigiere deine Angabe“ oder „die Datei kann so nicht verlinkt werden“.

Zusätzlich zu der Nutzereingabe zu der Variante mit der ein Design Artefakt verlinkt werden soll, erarbeiten das language und das correction Modul einen Vorschlag zur Verlinkung der Datei auf Basis der Dateibenennung. Diese erfolgt über eine semantische Ähnlichkeitsanalyse der Cosinus similarity. Es wird folglich ein Vorschlag auf inhärent vorliegenden Informationen erarbeitet.

Das language Modul führt weiterhin eine Analyse der Spracheingabe in zwei Abschnitten durch:

• Überführen einer Wortkombination in ein linguistisches Muster (parsing) • Zuweisen der Bausteine zu bestimmten Funktionen der Verlinkung sowie zu bestimmten Antwortklassen des Chat Bots und Weiterleiten an das Modul logic

Beim Parsing wird das Subjekt, Prädikat und Objekt identifiziert. Für eine beispielhafte Nutzereingabe „Verbinde das Kugellager mit der Variante Hinterachse“ wird demnach festgestellt, dass das Wort Kugellager das Subjekt ist, und Variante Hinterachse das Objekt. Damit kann im nächsten Schritt festgelegt werden, dass das Kugellager das Design Artefakt ist, das verlinkt werden soll und die Hinterachse die Variante, der es zugeordnet werden soll.

Um eine intuitive Eingabe der natürlichen Sprachverarbeitung zu erzielen, sollte beim Anwender das Gefühl entstehen, dass der Chat Bot intelligent interagiert. Die Kommunikation erfolgt idealerweise in der Form, dass der Anwender nicht mehr identifizieren kann, ob es sich um einen Menschen oder eine Maschine handelt, die antwortet. Dieser sich beim Anwender einstellende Effekt wird auch als Eliza-Effekt bezeichnet (Höltgen 2019, S. 11). Höltgen führt einige Optionen aus, die diesen Effekt begünstigen. Für die Anwendung des Chat Bots werden Antworten des Systems so konzipiert, dass nicht permanent exakt dieselbe Antwort auf eine Fragestellung gegeben wird, sondern zufällig aus einer Antwortklasse gewählt wird.

Für das CAD Werkzeug Autodesk Fusion 360 2019 wurde über eine API eine Schnittstelle geschaffen, durch die der Chat Bot gestartet wird (siehe Abbildung 35). Die entsprechende API ist in C# erstellt, die zugehörige Datei mit dem Quellcode befindet sich im digitalen Anhang (Fresemann und Ioannou 2020) dieser Arbeit.

Eine Rückgabe der Verlinkung erfolgt durch eine schriftliche Bestätigung des Chat Bots.

107

5 Exemplarische Umsetzung relevanter Bedarfe

Die Ablage der CAD Datei erfolgt für den Versuch in einem Explorer Ordner, getrennt von der Verlinkungsinformation, entsprechend dem konventionellen Verhalten von PDM Datenbanken.

Für den Versuch werden die Varianten dem Chat Bot als Liste in einer Textdatei zur Verfügung gestellt. Die Verlinkung wird durch einen linksseitigen Schrägstrich signalisiert, beispielsweise nach dem Schema „Tripelec\Anhänger“.

Die Verlinkungsinformation wird in demselben Textfile abgelegt, in der auch die Varianten dargestellt sind. Dieses Verhalten ist für den Versuch hinreichend. Für eine industrielle Anwendung ist an dieser Stelle eine Datenbank vorzusehen, die Relationen verwalten kann.

Aktivierung des Chat Bots über die Kommandozeile

Abbildung 35: Aktivierung des Chat Bots aus der CAD Umgebung

5.2.3 Versuchsaufbau und Daten

Dieser Abschnitt stellt zunächst den Versuchsaufbau und die Versuchsdaten dar. Nachfolgend wird der Chat Bot, wie er in Abschnitt 5.2.2 erstellt wurde, auf seine technische Funktionsfähigkeit und seine Anwendbarkeit durch Nutzer überprüft.

Die Versuchsdaten für diesen Versuch werden dem Tripelec, einem bestehenden Versuchsträger des Fachgebiets Industrielle Informationstechnik, entnommen. Dieser wurde initial für andere Versuche erstellt, verfügt allerdings über einen industriell relevanten Umfang an Daten, Komplexität sowie entsprechende Varianten. Die Abbildung 28 zeigt einen ersten Prototypen des Tripelecs.

Der Versuchsträger Tripelec besteht aus etwa 100 mechanischen Bauteilen. Das Tripelec besteht aus einem konstruierten Chassis mit Lenkung sowie aus zugekauften und dem

108

5 Exemplarische Umsetzung relevanter Bedarfe

Datensatz zugefügten Daten für Räder, Schaltung, Sitz, Federgabel, Antrieb (Elektromotor und Batterie), Beleuchtung und einer Bremse mit Bremskraftrückgewinnung. Das Tripelec beinhaltet variable Komponenten im Sinne des Variantenmanagements. Die Komponenten, die in diesem Kontext verwendet werden, sind in Tabelle 29 zusammengestellt.

Die real bestehenden Varianten werden um einige fiktive Kaufoptionen erweitert, um die Beispiele anschaulicher zu gestalten. Diese Varianten werden dem Algorithmus in der Datei Varianten.txt (Fresemann und Ioannou 2020) im digitalen Anhang zur Verfügung gestellt.

Tabelle 29: Varianten des Tripelecs

Nummer Variante Bemerkung 1 Kindersitz 2 Lastengepäckträger 3 Anhänger fiktive Komponente 4 Rekuperation 5 starker Elektromotor 6 kleiner Elektromotor fiktive Komponente 7 Solarmodul 8 Unterboden-Spritzschutz fiktive Komponente 9 Navigationssystem 10 10-Gang Schaltung 11 20-Gang Schaltung fiktive Komponente

Um die technische Funktionsfähigkeit zu validieren, wird ein Testprogramm absolviert. Der Chat Bot wird mit folgenden Situationen beaufschlagt:

Test 1: Der Nutzer fordert das System auf, eine neu erstellte CAD Datei der Variante Rekuperation zuzuordnen.

Test 2: Der Nutzer fordert das System auf, eine modifizierte CAD Datei einer Variante zuzuordnen.

Test 3: Menschen zeigen mitunter erratisches Verhalten, in diesem Test wird die Reaktion des Chat Bots auf solches Verhalten überprüft. Der Anwender gibt dem Chat Bot demnach im Kontext nicht-sinnhafte Anweisungen, etwa: „Sing ein Lied“.

Test 4: Die Eingaben des Nutzers sind orthografisch inkorrekt, beispielsweise anstelle von „verlinken“ wird „vreliknen“ eingegeben.

Test 5: Die Wortwahl wird so variiert, dass der Chat Bot übermäßige oder unzureichende Informationen erhält. Beispielsweise kann ein Anwender anstelle von „XY gehört zu

109

5 Exemplarische Umsetzung relevanter Bedarfe

AB“ „XY gehört zur Variante AB“ angeben oder Wörter wie „bitte“ in seine Aufforderung integrieren. Ein Beispiel für zu wenige Eingaben könnte sein, dass ein Anwender lediglich den Namen der Variante eingibt, nicht aber das zu verlinkende Design Artefakt benennt.

Test 6: Die Menge der Varianten wird in der Datei Varianten.txt erweitert. Es wird überprüft, ob CAD Dateien sowohl den bestehenden als auch den neuen Varianten zugeordnet werden können.

Alle Tests werden mehrfach durchgeführt, jeweils mit kleinen Variationen. Die Tests werden in den folgenden Fällen positiv bewertet:

Zu Test 1: die neu erstellte Datei korrekt zugeordnet werden konnte.

Zu Test 2: die modifizierte Datei sowohl der initialen Variante, als auch einer beliebigen neuen Variante zugeordnet werden konnte.

Zu Test 3: der Chat Bot die Aufgabe eigenständig ablehnt, oder eine Aufforderung zur Nachbesserung an den Nutzer ausgegeben wird.

Zu Test 4: eine Autokorrektur durch den Chat Bot erfolgt oder der Chat Bot den Anwender auffordert, seine Anweisung zu modifizieren.

Zu Test 5: der Chat Bot seine Aufgabe erledigen kann oder den Nutzer auffordert, die Angaben zu konkretisieren. Die Aufgabe soll entsprechend der Intention des Anwenders umgesetzt werden.

Zu Test 6: Wenn jeweils eine CAD Datei mit einer bestehenden und einer neuen Variante verlinkt werden kann.

Darüber hinaus ist es im Sinne eines erfolgreich nutzbaren Softwarewerkzeugs erforderlich, dass keine ungeplanten System Abbrüche erfolgen. Derartige Vorkommnisse werden während der Versuchsdurchführung notiert.

Die Funktionsfähigkeit der in Absatz 5.2.2 erstellten Anwendung wird darüber hinaus hinsichtlich ihrer Nutzbarkeit getestet. Anders als die anderen Teilimplementierungen ist der Chat Bot für die direkte Interaktion mit Anwendern konzipiert, deshalb ist dieser Schritt zusätzlich erforderlich.

Für die Durchführung des Versuchs wird ein Rechner zur Verfügung gestellt, auf dem Autodesk Fusion 360 und der Chat Bot funktionsfertig installiert sind. Die Aufgabe der Anwender während der Untersuchung besteht zunächst darin, eine einfache Geometrie zu erstellen, um den Konstruktionsvorgang anzudeuten. Exemplarisch werden den Probanden Quader, Zylinder, Kugel und Kegel vorgeschlagen. Für die Konstruktionsaufgabe wird die

110

5 Exemplarische Umsetzung relevanter Bedarfe

Software Fusion360 verwendet. Die CAD Dateien sind in ihrer Entstehungsreihenfolge den gegebenen Varianten Solarmodul, Lastengepäckträger (2x) und 10-Gang Schaltung mit Hilfe des Chat Bots zuzuordnen. Als Hilfestellung wird den Probanden die Liste der Varianten zur Verfügung gestellt. Die Aufgabe wird mündlich an die Probanden herangetragen und zusätzlich wird der Ablauf eines Datenverwaltungsablaufs durch den Versuchsleiter demonstriert. Der Versuchsleiter vergewissert sich, dass die Probanden Aufgabe und Ablauf verstanden haben. Während des Tests dürfen die Probanden Fragen stellen. Es wird für jeden Probanden notiert, ob Fragen gestellt wurden bzw. ob die Aufgaben erledigt werden konnten. Die Probanden werden jedoch nicht explizit darauf aufmerksam gemacht.

Die Beurteilung, ob das System aus Nutzersicht anwendbar ist, erfolgt anhand des System Usability Scale (SUS; dt. System-Nutzbarkeit-Skala) Fragebogen der auf (Brook 1996) zurückgeht. Dieser ermittelt die subjektive Wahrnehmung der Nutzbarkeit eines Software Werkzeugs und wird in der deutschen Übersetzung von (Ziegler 2014, S. 4) verwendet. Gegenüber der Übersetzung von Ziegler wird das Wort System gegen das Wort Chat Bot ersetzt, um Anwenderinnen mit einer einheitlichen Bezeichnung des Untersuchungsgegenstands zu konfrontieren. Darüber hinaus wurde ein Feld für freie Kommentare zur Verfügung gestellt, um individuelle Meinungen zu erfassen. Der Fragebogen fokussiert sich neben der direkten Funktionalität auf Fragestellungen zur Erlernbarkeit und Übersicht der Anordnung von Funktionen. Aus diesem Grund verwendet (Saenz 2017) den SUS für die Beurteilung von Chat Bots. Der Fragebogen ist im Anhang auf Seite VII zu finden. Die Studie ist, entsprechend der Dokumentation von (Bangor 2008, S. 580), mit acht Probanden durchzuführen, um ein signifikantes Ergebnis zu erzielen.

5.2.4 Versuchsergebnisse

Zunächst beschreibt dieser Abschnitt die technische Validierung des Chat Bots entlang des Versuchsplans aus dem vorherigen Abschnitt. Im weiteren Verlauf werden die Ergebnisse der Nutzbarkeitsuntersuchung vorgestellt.

Funktionstests

Zu Test 1: Für den Versuch der erfolgreichen Speicherung wird in der CAD Anwendung ein Objekt erstellt und diese Datei zur Speicherung an eine Variante übergeben. Die Abbildung 36 zeigt den eingegebenen Befehl des Ingenieurs im unteren Teil der Abbildung bei 1 sowie zudem die Rückmeldung des Chat Bots im oberen Bildausschnitt bei 2.

Weiterhin wurde im Rahmen des Tests 1 nachvollzogen, ob die programmierte Anwendung die Datei am angegeben Ort in korrektem Zusammenhang mit der Variante abgelegt hat. Dies wird nach der positiven Rückmeldung des Chat Bots in der relevanten Textdatei manuell

111

5 Exemplarische Umsetzung relevanter Bedarfe geprüft. Die Speicherung erfolgte in allen durch den Chat Bot positiv quittierten Fällen korrekt. Der Test 1 wird somit positiv bewertet.

Abbildung 36: Screenshot der Interaktion zwischen Anwender und Chat Bot in der CAD Umgebung

Zu Test 2: Für den Test 2 wurde die Datei Kupplung erstellt und zunächst mit der Variante Anhänger verlinkt, um den Ausgangszustand vorzusehen. Die Datei Kupplung wird in Autodesk geschlossen und nach dem Öffnen modifiziert. Für diesen Test wurde die Länge des Quaders vergrößert. Die modifizierte Datei wird der Variante Tripelec zugeordnet. Die Abbildung 37 zeigt die erfolgreiche Rückmeldung des Chat Bots nach dem zweiten Speichervorgang. Der Test 2 wird positiv bewertet.

Abbildung 37: Bildschirmausschnitt des Chat Bots zur Verlinkung einer Datei bei zwei Varianten

112

5 Exemplarische Umsetzung relevanter Bedarfe

Zu Test 3: Im Test zu nicht sachgemäßen Anfragen des Anwenders lehnt der Chat Bot die Ausführung erwartungsgemäß ab (siehe Abbildung 38). Ebenso wird dieser Test positiv bewertet, denn der Chat Bot korrespondiert sinnhaft mit dem Anwender.

Abbildung 38: Abbruch des Programms durch den Chat Bot

Zu Test 4: Die Autokorrektur des Chat Bots erkennt einfache Tippfehler insbesondere solche mit lediglich einem fehlerhaften Buchstaben. Ebenso werden kleinere orthographische Fehler, wie Groß- und Kleinschreibung im Sinne der Intention des Anwenders interpretiert. Für diese, durch den Anwender eingetragenen Fehler, bringt der Chat Bot einen Korrekturvorschlag. Die Abbildung 39 zeigt links die fehlerhafte Eingabe und rechts die Antwort des Chat Bots. Test 4 wird somit positiv bewertet.

Abbildung 39: Fehlerhafte Nutzereingabe und Korrekturvorschlag durch den Chat Bot

Zu Test 5: Während der Versuchsdurchführung konnte beobachtet werden, dass der Chat Bot einen grammatikalisch korrekten Satzbau und vollständige Sätze besser interpretieren kann als umgangssprachlich oder verkürzt formulierte Aufforderungen. Ein Beispiel dazu ist das Einfügen von Buchstaben oder Artikeln in „Verlinke die Zeichnung.xy mit Variante.Z“. Sind die fett gedruckten Anteile integriert, werden das Verb und das Subjekt des Beispielsatzes korrekt erkannt. Dieses Verhalten erklärt sich durch die verwendeten Trainingsdaten und Datensätze.

113

5 Exemplarische Umsetzung relevanter Bedarfe

Fragen werden weniger gut interpretiert als Aufforderungen. Wenn ein Nutzer folglich formuliert: „verlinke Kugel.DWG mit Anhänger!“, versteht der Chat Bot die Aufforderung ohne Nachfragen. Formuliert der Anwender sein Ansinnen allerdings als Frage: „Könntest du Kugel.DWG bitte mit Anhänger verlinken?“, reagiert der Chat Bot mit Nachfragen und Korrekturvorschlägen.

Der Chat Bot benötigt Verben für die korrekte Umsetzung seiner Aufgaben, verkürzte Anweisungen wie beispielsweise „Kupplung zu Kindersitz“ werden mit Nachfragen durch den Chat Bot beantwortet. In drei von vier Versuchen kann der Dialog nicht im Sinne des Anwenders abgeschlossen werden.

Der Test 5 wird positiv bewertet, da stets ein Ergebnis erzielt werden kann. Für ein industriell einsetzbares Werkzeug, das Nutzer zufriedenstellt, ist es erforderlich, Fragen und umgangssprachliche Anweisungen besser interpretieren zu können.

Zu Test 6: Auch die Verlinkung mit neu erstellten Varianten konnte durchgeführt werden, ohne dass Einschränkungen in der Funktionsfähigkeit des Chat Bots festgestellt wurden. Existiert eine bestimmte Variante nicht, während der Chat Bot aufgefordert wird eine Verlinkung zu etablieren, so erfolgt eine entsprechende Fehlermeldung. Dieses Verhalten entspricht der Intention des InADM. Der Test 6 wird positiv bewertet.

Zusammenfassend werden die sechs Versuche und somit die technische Umsetzung des Chat Bots erfolgreich bewertet. Bislang nicht umgesetzt ist das Ändern der Zuordnung eines Design Artefakts zu einer Variante und sollte somit im weiteren Forschungs- und Handlungsbedarf berücksichtigt werden.

Nutzerstudie

Die Studie wurde mit acht Teilnehmern entsprechend dem SUS durchgeführt. Die Probanden erhalten zunächst durch die Versuchsleiterin eine Erklärung der Funktionsweise des Chat Bots, sowie eine einmalige Demonstration der Nutzung. Dabei wird die erfolgreiche Verlinkung eines Design Artefakts mit einer Variante durchgeführt. Weiterhin erhalten alle Probanden eine Erläuterung des Tripelecs und der im Versuch verwendeten Varianten. Die Versuchsleiterin versichert sich, dass die Probanden ihre Aufgabe korrekt verstanden haben und dass die Teilnehmer die Aufgabe eigenständig durchführen können. Die Versuchsleiterin hält sich weiterhin im Raum auf, sodass Probanden nach Bedarf Fragen stellen können.

Die acht Teilnehmer der Studie verfügen über eine abgeschlossene Ingenieursausbildung oder befinden sich noch darin. Keiner der Probanden besitzt signifikante Vorerfahrung in der Benutzung von PDM Werkzeugen oder in den konkreten Tätigkeiten der Verwaltung von Varianten. Die Probanden sind im Alter von 23 bis 42, der Durchschnitt ist 31 Jahre alt. Die Studie wurde mit einer weiblichen Teilnehmerin durchgeführt, die restlichen waren männlich.

114

5 Exemplarische Umsetzung relevanter Bedarfe

Der Fragebogen besteht aus zehn Aussagen (siehe Fragebogen zur Evaluierung des Chat Bots, Seite VII). Die Antwortmöglichkeiten sind in Form einer Fünf-Punkte Liekert Skala gegliedert und reichen von Stimme gar nicht zu (1 Punkt) bis Stimme voll zu (5 Punkte). Die Fragen sind alternierend positiv und negativ angeordnet.

Die Auswertung des Fragebogens wird nach der vorgegebenen Berechnung von (Brook 1996) und (Bangor 2008, S. 580) durchgeführt.

5 Für ungerade Fragen gilt: u = ∑�=1(2n − 1) – 1) 5 Für gerade Fragen gilt: g = ∑�=1(5 – (2n)) Der Gesamt – Systemnutzbarkeitswert ist: S = (� + �) ∗ 2,5

Das n in der Formel stellt dabei den Wert dar, mit dem ein Proband die jeweilige Frage beantwortet hat. Das Ergebnis S (scale) liegt bei einem Wert zwischen 0 und 100, wobei 0 das schlechteste mögliche Ergebnis ist und 100 das beste Ergebnis. (Bangor 2008, S. 580) schlägt eine visuelle Darstellung des errechneten Wertes, entsprechend Abbildung 40, vor.

Die Punktzahl wird in Relation zu Akzeptanzgrenzen, Schulnoten von 1-5 (1 ist die beste 5 die schlechteste) und einer Bewertung durch Adjektive gesetzt. Die eingefügte rote Linie stellt das durchschnittliche Ergebnis S = 72.8 des implementierten Chat Bots dar. Die Gesamtbewertung der Teilnehmer liegt damit im guten Bereich, wobei Verbesserungspotentiale adressiert werden.

Abbildung 40: Ergebnis der SUS Auswertung für den Chat Bot

Die individuellen Ergebnisse pro Proband sind in der Tabelle 30 zusammengestellt. Die Streuung der Ergebnisse liegt zwischen den Werten 60 und 85. Den schwächsten Wert erzielte der Chat Bot für die Nachfrage, wie sicher sich ein Nutzer bei der Bedienung fühlt. Auf Nachfrage gaben die Teilnehmer an, dass sie sich nicht sicher seien, ob der Chat Bot die Speicherung tatsächlich ausführe.

Offensichtlich fehlt den Benutzern die visuelle Rückmeldung der verlinkten Daten in einer Struktur oder Datenbank. Es bleibt an dieser Stelle offen, ob Anwender sich an dieses

115

5 Exemplarische Umsetzung relevanter Bedarfe

Verhalten gewöhnen und dem Chat Bot vertrauen können oder ob sie einen konkreten visuellen Nachweis der physikalischen Verlinkung benötigen. Dieses Vertrauen kann etwa in der Form auftreten, wie auch Google dahingehend vertraut wird, alle relevanten Informationen gefunden zu haben, ohne nachzuprüfen, in welchen Datenbanken gesucht wurde und welche Quellen beispielsweise nicht referenziert sind oder zu weit hinten in der Liste auftauchen.

Tabelle 30: Übersicht der SUS Werte pro Proband

Proband Ergebnis Proband 1 60 Proband 2 70 Proband 3 60 Proband 4 72,5 Proband 5 75 Proband 6 82,5 Proband 7 77,5 Proband 8 85 Durchschnittswert: 72,8

Die Anwender haben bei der Durchführung der Studie keine Fehler der Zuweisung erzeugt. Das wurde im Nachgang jedes Versuchs durch die Versuchsleiterin überprüft. Ebenso hat der Chat Bot die Anwender entweder verstanden, oder den Versuch eigenständig abgebrochen.

Ein Kommentar eines Probanden enthielt die Information, dass zu wenig Vorkenntnisse vorhanden seien – gleichzeitig wurden während des Versuchs von dieser Person jedoch keine Fragen gestellt. Als Verbesserungswunsch gaben drei Teilnehmer an, stets die aktive Datei als zu verlinkendes oder zu speicherndes Objekt durch den Chat Bot vorauszusetzen analog zum Verhalten von Speicherfunktionen in gängigen Windows Werkzeugen. Ein Teilnehmer machte den Vorschlag, direkt während des Tippens der Variante eine Autokomplettierung auf Basis der Liste der Varianten zu erhalten.

5.2.5 Beurteilung der Ergebnisse zur Verwendung im InADM

Der Chat Bot konnte, entsprechend der Tests 1 – 5 in Abschnitt 5.2.4, technisch erfolgreich umgesetzt werden. Änderungen an der Liste der Varianten werden berücksichtigt, sodass neu anzulegende Design Artefakte entsprechend zugeordnet werden. Das Löschen einer bestehenden Variante hat keinen Einfluss auf die Funktionsfähigkeit des Algorithmus. Es ist demnach für das Verhalten der Referenzobjekte zu berücksichtigen, dass Änderungen an der Variantenliste gegebenenfalls Fehler auslösen. Die, in diesem Fall, nicht assoziierten Design Artefakte müssen der Prüfliste zugeordnet werden.

116

5 Exemplarische Umsetzung relevanter Bedarfe

Ebenso konnte eine gute Nutzbarkeit des Chat Bots für das Variantenmanagement durch eine Probandenstudie im Abschnitt 5.2.4 nachgewiesen werden. Die Tabelle 7: Übergeordnete Bedarfe für PDM Werkzeuge und Methoden listet die Bedarfe Einfachheit der Bedienung und Robustheit eines Werkzeugs als generelle Anforderungen auf. Beide Fragestellungen konnten mit dem Chat Bot gezeigt werden.

Die Modifikation eines Design Artefakts kann erfolgreich durchgeführt werden, ohne dass sich die Änderung auf die Variantenzuordnung auswirkt. Für kleinere Änderungen, beispielsweise zu Beginn des Entwicklungsprozesses oder vor einer Freigabe, kann ein Ingenieur eine Datei weiterentwickeln und speichern, ohne Einschränkungen durch das InADM zu erhalten. Der Chat Bot in der vorliegenden Form referenziert ausschließlich den Dateinamen. Für eine industrielle Anwendung sollte darüber hinaus die Nummerierung als identifizierendes Objekt mitverwendet werden.

Weiterhin wurde der Chat Bot an den Speichervorgang geknüpft. Für eine tatsächliche Anwendung kann es in einigen Fällen erforderlich sein, einen Speichervorgang ohne Variantenzuordnung zu tätigen, beispielsweise aus dem Grund, dass ein Produkt keine Varianten hat oder diese zu dem Zeitpunkt der Erstellung des Design Artefakts noch nicht definiert sind. Dafür müsste der Chat Bot entsprechend programmiert werden.

Die Durchführung der Programmierung erfolgte für die deutsche Sprache, für eine industrielle Umsetzung ist eine Adaption, wie beispielsweise für die englische Sprache, erforderlich. Diese kann unter anderem mit dem Crosslingualen Information-Retrieval (CLIR) realisiert werden (Carstensen 2010, S. 442). Dabei verwenden Nutzer eine ihnen bekannte Sprache, das System übersetzt die Anfrage und durchsucht anderssprachige Wissensdatenbanken. Bibliotheken, die für die deutsche Sprache erstellt wurden, beziehen sich auf den allgemeinen Sprachgebrauch. Viele Anwendungen sind im industriell kommerziellen Sektor in der Kundeninteraktion, wie etwa bei Banken etabliert (Carstensen 2010, S. 550). Der maschinenbauliche Bereich ist bislang unterrepräsentiert, sodass bestimmte Worte oder Zusammenhänge nicht klar erkannt werden. Diese Lücke zu schließen, erfordert eine substantielle Untersuchung zur Verwendung der Fachsprache, aber auch zur Kommunikation von Einheiten.

Es wurden lediglich einfache Anweisungen im Chat-Bot umgesetzt. Es fehlen Methoden zu umständlicheren Beschreibungen wie, „Verlinke diese Datei mit demselben Ort, wie die gestrige“. Ebenso kann mit der aktuellen Umsetzung einzig ein Design Artefakt gleichzeitig verlinkt werden. Anfragen wie „Alle geöffneten Dateien gehören zu Variante A“, können somit nicht durch den Chat Bot umgesetzt werden. Ebenso reagiert das System auf sprachlich unvollständige Angaben wie „zu Variante C“ ohne Benennung, welche Datei mit der Variante verlinkt werden soll, mit sehr vielen Rückfragen, die in der Regel zu Abbrüchen des Vorgangs

117

5 Exemplarische Umsetzung relevanter Bedarfe führen. In diesem Sinne ist eine technologische Verbesserung erforderlich, um ein industrietaugliches Niveau zu erzielen.

Das State-of-the Art für die Entwicklung von Chat Bots wurde in dieser Arbeit bei weitem nicht ausgeschöpft. Semantisches Verständnis und „Denkprozesse 34 “ sowie weiterführende Anwendungen des Maschinellen Lernens wurden nicht verwendet. Diese Möglichkeiten können helfen, das zuvor adressierte industrietaugliche Level zu erreichen.

5.3 Plausibilisierung auf Basis geometrischer Daten

Das Ziel der algorithmischen Plausibilisierung ist es, die Korrektheit einer Variante, bestehend aus mehreren Design Artefakten, zu prüfen. Die Plausibilisierung von Varianten erfolgt auf Grundlage von geometrischen Eigenschaften, wie sie in CAD Modellen oder deren Derivaten vorliegen. Der Anwender wird vom InADM involviert, sobald ein Design Artefakt als unpassend für andere Design Artefakte der Variante identifiziert wurde. Die Kommunikation erfolgt vom Algorithmus über die Prüfliste periodisch an den Anwender. Der Abschnitt 5.3.1 führt die erforderlichen technologischen Grundlagen ein. Weiterhin beschreibt er den Aufbau des erstellten Algorithmus zur Plausibilisierung von Design Artefakten innerhalb einer Variante. Im weiteren Verlauf beschreibt das Kapitel im Abschnitt 5.3.2 den Versuch und seine Ergebnisse im Abschnitt 5.3.3.

5.3.1 Algorithmus auf Basis der geometrischen Merkmalserkennung

Die technologische Basis für das Überprüfen der Zusammengehörigkeit von Bauteilen bildet die Erkennung charakteristischer Merkmale in geometrischen Daten. (Shah et al. 2000, S. 43) definieren charakteristische Merkmale als generische Flächen, wie Kreise, Rechtecke etc. Die identifizierten charakteristischen Merkmale werden von einem Algorithmus mit denen anderer CAD Modelle verglichen. Als Programmiersprache wurde Python verwendet, der vollständige Software Code findet sich im digitalen Anhang der Arbeit (Fresemann und Bittcher 2020b).

Um die CAD Modelle einfach analysieren zu können, werden diese im Format des STEP Protokolls AP242 verwendet. In diesem sind die geometrischen Merkmale durch den Aufbau als xml Struktur zugänglich abgelegt (siehe Abbildung 41).

34 In der englischsprachigen Fachliteratur als „reasoning“ bezeichnet. Der Begriff bezeichnet die Fähigkeit des Programms, ein Wort im Kontext korrekt zu bewerten und angemessen zu reagieren. Das ist beispielsweise für Synonyme oder zusammengesetzte Worte aus Nomen von Interesse.

118

5 Exemplarische Umsetzung relevanter Bedarfe

Abbildung 41: Ausschnitt des xml Schemas einer STEP Datei

Aus der Abbildung wird deutlich, dass anhand der Nummern „#XY“ Punkte, Ecken, Längen und Orientierungen maschinell erfassbar und damit auswertbar sind. Exemplarisch zeigt beispielsweise Zeile 90 den Aufbau eines Kreises, dessen Mittelpunkt unter #89 platziert ist und dessen Radius 6,3mm beträgt.

(Pratt 2001) erläutert, dass das STEP Protokoll Flächen (F für Face), Kanten (E für Edge) und Punkte (V für Vertex) kennzeichnet. Diese werden folgend zu einem Volumenkörper zusammengesetzt. Von den gegebenen Flächen des Protokolls werden für die vorliegende Arbeit • Kugeloberflächen, • zylindrische Flächen, • Kegeloberflächen, • abgerundete Kanten sowie • Rechtecke als charakteristische Merkmale verwendet. Eine STEP Advanced Face kennt neben dem Flächeninhalt und den zugehörigen Kanten zudem ihre Orientierung im Zusammenhang mit dem gesamten Volumenkörper. Regelmäßige Muster, wie zirkular angeordnete Bohrungen, die in CAD Werkzeugen als Feature angelegt sind, sind im STEP Standard grundsätzlich erfasst. Jedoch werden sie nicht bei jedem Export aus allen CAD Werkzeugen korrekt in die STEP Dateien geschrieben. Deshalb wird im Algorithmus dieser Arbeit eine Umschreibung über Abstände und Anzahlen geschaffen, die Muster repräsentieren. Dem Algorithmus werden einzelne STEP Dateien, die einer Variante zugeordnet sind, in einem Explorer Folder zur Verfügung gestellt. Von dort werden sie nach dem Start des Algorithmus durch den Anwender geladen. Da der Algorithmus in der späteren Verwendung im InADM nicht an der Oberfläche mit dem Anwender interagieren soll, wird der Algorithmus für die Tests

119

5 Exemplarische Umsetzung relevanter Bedarfe aus der Programmierumgebung (Python Idle, Version, 3.7.3) ohne zusätzliche Anwenderoberfläche aktiviert.

Für die Identifikation der Zusammengehörigkeit von jeweils zwei Bauteilen sind die Dimension und die Orientierung entscheidend. Ein Beispiel dazu sind beispielsweise die Radien von zwei Kugeln, die im Durchmesser und deren entgegengesetzter Orientierung als Außen- und Innenwölbung am jeweiligen Bauteil überprüft werden (siehe Abbildung 42). Die Dimensionen werden in der Abbildung durch die Radien R1 und R2 sowie die Orientierung O1 (konvex) und O2 (konkav) dargestellt.

Die Orientierung im Bild empfindet die Identifikation der Orientierung innerhalb der „advanced Face“ im STEP Format nach. Ist nun R1 = R2 ist davon auszugehen, dass beide schematisch angedeuteten Bauteile der Abbildung 42 aufeinander passen.

Abbildung 42: Dimensionen und Orientierung charakteristischer Merkmale

Die Informationen der Dimension und Orientierung allein reichen jedoch nicht aus, um eine geometrische Zusammengehörigkeit zu überprüfen. Es gibt Geometrien, die mutwillig nicht zu 100 % korrekt modelliertet sind, wie beispielsweise Gewinde, die als einfache Zylinder erstellt werden. Weiterhin gibt es konstruktive Erfordernisse, wie ein absichtlich eingefügtes Spiel bei Unterlegscheiben oder auch mehrere Bauteile die mit Schraube und Mutter zusammengeklemmt werden. Dadurch ist eine 1:1 Relation zwischen Bauteilen nicht eindeutig erklärbar. Zusätzlich werden demnach weitere Merkmale verwendet, die Indizien für eine Passfähigkeit der Modelle liefern. So werden die Längen für Zylinder zusätzlich erfasst und verglichen sowie alle Kantenlängen, der Flächeninhalt und die dazugehörige Tiefe und Orientierung für Rechtecke. Es existieren im Algorithmus somit für jedes charakteristische

120

5 Exemplarische Umsetzung relevanter Bedarfe

Merkmal mehrere Parameter. Durch Gewichtungsvariablen werden sie mehr oder weniger stark hinsichtlich der Einschätzung der Zusammengehörigkeit berücksichtigt.

Die Gewichtungsvariablen, „may & must values“ in Abbildung 43 wurden durch einige Überlegungen und Vorversuche wie folgt festgelegt: • Für Kugeln muss die Orientierung korrekt sein („must value“) und der Durchmesser muss nahezu genau mit einer maximalen Abweichung von 5 % des Wertes stimmen („may value“). Der Wert 5 %, also 5 mm bei einem Durchmesser von 100 mm, hat sich durch Vorversuche als zielführend erwiesen. Die Werte für die Variablen Orientierung = 1 und Durchmesser =1 drücken für die Kugel aus, dass beide gleichgewichtet werden. • Für Kegel müssen die Orientierung und der Winkel stimmen, die Länge versteht sich als „may value“. Damit ergeben sich die Gewichtungswerte Länge L = 1, Orientierung O = 2 und Winkel W = 2. • Bei Rechtecken wird die Orientierung vernachlässigt, da lediglich Außenflächen im Algorithmus berücksichtigt werden. Aus diesen sind hingegen Funktionsflächen im Sinne der Variantenzugehörigkeit nicht ableitbar, beispielsweise, wenn ein kleineres Gegenstück aufgeklebt oder geschweißt wird oder eine Fläche keinen funktionalen Zusammenhang zu anderen Bauteilen aufweist. Die Kantenlängen und der Flächeninhalt werden gemeinsam als Muss-Wert gesetzt. Es ergeben sich die Gewichtungswerte Kantenlänge K = 1 und Flächeninhalt F = 1, denn beide gemeinsam ergeben die Überprüfbarkeit mit gleichgeformten Gegenstücken. • Bei Zylindern muss die Orientierung korrekt und der Durchmesser nahezu mit einer maximalen Abweichung von 5 % des Wertes stimmen, die Länge ist ein Kann-Kriterium. Es ergeben sich die Gewichtungswerte Orientierung O= 2, Durchmesser D= 2 und Länge L=1 analog zu den Einstellungen des Kegels.

Diese Werte sind im Quellcode festgelegt und werden im Schritt der Wahrscheinlichkeitsberechnung „calculate fit“ (siehe Abbildung 43) am Ende des Programms verwendet.

Der Ablauf des Algorithmus ist in Abbildung 43 vereinfacht dargestellt. Der initiale Schritt des Zurücksetzens der Werte in Listen und Variablen auf einen Ausgangswert sowie das Laden der STEP Dateien und Klassen aus parallelen Programmabschnitten werden in der Abbildung vernachlässigt. Ebenso wird der Schritt „set may & must values“ durch einmaliges Einstellen, wie zuvor beschrieben, festgelegt. Der Algorithmus startet gemäß Abbildung 43 mit dem Auslesen der „characteristic feature“ (CF) aus den STEP Dateien.

121

5 Exemplarische Umsetzung relevanter Bedarfe

Abbildung 43: Programmablauf der Varianten-Plausibilisierung

Diese charakteristischen Merkmale (CM) und ihre Dimensionen werden in der „STEP item list“ abgelegt. Die „STEP item list“ wird durch den Algorithmus für jedes Bauteil entsprechend der Tabelle 31 angelegt.

Tabelle 31: Schema der „STEP item list“

Nr. CM 1…n Dimension 1 Winkel#1, Kegel #22 20° Seitenlänge#1, 2 59 mm Kegel#22

In einem nachgelagerten Schritt werden Geometrien entfernt, die für die Merkmalserkennung irrelevant sind. Alle Zylinder und Kegel mit einer Länge L= 0 mm werden aus der „STEP item list“ entfernt. Diese Informationen befinden sich beispielsweise in den STEP Dateien, da sie in der CAD Umgebung als Hilfsgeometrien angelegt oder durch Exportfehler erzeugt wurden.

Darüber hinaus werden im Programmabschnitt „extract characteristic feature“ einfache geometrische Muster gesucht. Einfache geometrische Muster bezeichnen an dieser Stelle beispielsweise regelmäßig angeordnete Lochbohrungen in einem Flansch. Für die Analyse wird pro Bauteil nach identischen, mehrfach auftauchenden Abständen zwischen charakteristischen Merkmalen in einem Bauteil gesucht. Diese regelmäßigen Abstände werden in einer zusätzlichen Liste, „pattern list“, pro Bauteil abgelegt.

Der Programmabschnitt „compare each 2 files“, vergleiche Abbildung 43, verwendet die „STEP item list“ sowie die „pattern list“, falls diese vorhanden ist. In diesem Arbeitsschritt wird bei jeweils zwei der zur Verfügung stehenden STEP Dateien geprüft, ob gleiche oder ähnliche charakteristische Merkmale existieren. Mögliche Übereinstimmungen werden in einer „dedicated object list“ pro Bauteilpaarung abgelegt. Dabei werden die charakteristischen Merkmal (CM 1…n) mit Bezug zum Bauteil (BT) übertragen, wie es in Tabelle 32 schematisch

122

5 Exemplarische Umsetzung relevanter Bedarfe dargestellt ist. Die Zeile 1 der Tabelle 32 zeigt exemplarisch, dass der Winkel#1 an Kegel #22 in Bauteil 1 gleich dem Winkel#4 an Kegel#3 in Bauteil2 ist.

Das Programm endet, wenn bis zu diesem Zeitpunkt keine möglichen Übereinstimmungen gefunden werden (siehe Abbildung 43). In diesem Fall erfolgt eine Rückgabe an den Anwender mit der Information „Bauteil X und Bauteil Y gehören mit einer Wahrscheinlichkeit von 0 zusammen“, jeweils für alle geladenen STEP Dateien.

Tabelle 32: Schema der “dedicated object list”

Nr. CM 1…n @ BT1 CM 1…m @ BT2 1 Winkel#1, Kegel #22 Winkel#4, Kegel #3 2 Seitenlänge#1, Kegel#22 Winkel#4, Kegel #3

Wenn mögliche Übereinstimmungen gefunden wurden, erfolgt der Schritt „calculate fit“. Mit diesem wird die Wahrscheinlichkeit der Zusammengehörigkeit aller innerhalb der Variante möglicher Bauteilkombinationen ermittelt. Die Wahrscheinlichkeit P (i, j), mit der die Bauteile i und j zusammengehören wird mit Formel (3) bestimmt:

#� → � #� → � #� (3) �(�, �) = #� + � � Darin ist k die Summe der übereinstimmenden charakteristischen Merkmale für die Bauteile i und j; #i die Anzahl der charakteristischen Merkmale in Bauteil i; #j die Anzahl der charakteristischen Merkmale in Bauteil j. Der Ausdruck #i→j beschreibt die Anzahl, der in Bauteil i gefundenen Merkmale, die mit Bauteil j übereinstimmen. Der Ausdruck #j→i beschreibt die Anzahl, der in Bauteil j gefundenen Merkmale, die ebenfalls mit Bauteil i übereinstimmen.

Die Rückgabewerte werden in einem für Menschen lesbaren Format ausgegeben, um die Ergebnisse im Rahmen der Versuche interpretieren zu können (siehe

Abbildung 44). Der Anwender erhält weiterhin eine Wahrscheinlichkeit der Zusammengehörigkeit von jeweils zwei Dateien in der Ausgabe zurück. Unten in der Abbildung wird eine Zusammengehörigkeit von ~ 0,52 erkennbar. Diese bezieht sich auf die beiden Dateien „Feder_lang“ und „Halter_lang“, die am oberen Bildausschnitt angezeigt werden. Zudem werden Zwischenwerte abgebildet, diese ermöglichen das Bewerten der Funktionalitäten des Algorithmus. In diesem Kontext beispielsweise für die Auswahl konkreter Zylinder und Geometrien sowie das Auslesen konkreter geometrischer Werte (siehe die Spalten Radius und Tiefe in der

123

5 Exemplarische Umsetzung relevanter Bedarfe

Abbildung 44.)

Abbildung 44: Exemplarische Rückgabe der Zusammengehörigkeitsanalyse

124

5 Exemplarische Umsetzung relevanter Bedarfe 5.3.2 Versuchsaufbau und Daten

Um die Funktionsfähigkeit des Algorithmus, wie in Abschnitt 5.3.1 beschrieben, zu prüfen, werden drei Aspekte untersucht:

Test 1: Werden zusammengehörende Teile korrekt als solche bestätigt?

Test 2: Werden Teile ohne Bezug zueinander als solche identifiziert?

Test 3: Können Varianten eines Produktes oder eines Teils identifizieren werden?

Es entstehen drei Teilversuche, entsprechend der Fragestellungen 1-3, die Versuchsaufbauten, Daten und Ergebnisse finden sich jeweils in Bezug zum Test in den beiden Abschnitten 5.3.2 und 5.3.3.

Zu Test 1) Dem Algorithmus aus Abschnitt 5.3.1 werden zwei beliebige Baugruppen mit bis zu zehn Bauteilen pro Baugruppe zur Verfügung gestellt. Der Test wird positiv bewertet, wenn alle tatsächlich in Beziehung stehenden Bauteile korrekt identifiziert werden.

Die erste Baugruppe ist eine Spindelauspresseinheit, bestehend aus fünf metallischen Teilen. Die Verlängerungsstangen sind so konzipiert, dass sie über eine Zylinder-Bolzen-Verbindung ineinandergesteckt werden können und mit einem gefederten Schnappsystem arretiert werden (siehe Abbildung 45).

Senkschrauben M4

Halter

Feder

Verlängerungsstange Verlängerungsstange 1 2

Abbildung 45: Explosionsdarstellung der Spindelauspresseinheit

Die Verlängerungsstangen 1 und 2 in der Abbildung sind tatsächlich zwei baugleiche Teile. Die Einheit dient dazu, eine Welle aus einem Zylinder zu schieben. Diese Verwendung und Funktionalität sind aus den CAD Daten selbst nicht zu erfassen. Die Daten wurden von einem

125

5 Exemplarische Umsetzung relevanter Bedarfe

Unternehmen zur Verfügung gestellt, sie wurden initial in Solid Edge erstellt und durch das Unternehmen als STEP exportiert. Beide Dateiformate liegen vor.

In der Tabelle 33 sind relevante geometrische Dimensionen der Baugruppe zusammengestellt. Die Spalte Dinnen bezeichnet den Innendurchmesser, die Spalte Daußen bezeichnet den Außendurchmesser. Am Beispiel der Winkel wird klar, dass die Bauteile Senkschraube und Halter geometrisch passfähig sind. Diese sollen in dem Versuch als passfähig identifiziert werden. Die Verlängerungsstange mit einem Innendurchmesser Dinnen = 9,5 mm und einem Außendurchmesser Daußen = 10 mm passt folgend zusammen. Der Algorithmus bewertet die Passfähigkeit eines Teils zu sich selbst nur dann, wenn die Datei doppelt in dem entsprechenden Explorerordner vorliegt. Für den Versuch wird die Datei Verlängerungsstange zweifach zugefügt, um das Verhalten des Algorithmus zu beobachten. Die Schrauben haben ein Gewinde der Größe M4. Das Gewinde ist als Zylinder mit dem Außendurchmesser Daußen = 4 mm modelliert. Halter und Feder haben jeweils eine Lochbohrung Dinnen = 4,5 mm sowie ein regelmäßig auftretendes Muster, dass sich in beiden Bauteilen wiederholt. Die Abweichung der Durchmesser von Halter und Schraube übersteigt den 5 % Grenzwert im „Mustvalue“ der Gewichtungsvariablen und wird somit vermindert berücksichtigt.

Tabelle 33: Ausgewählte Dimensionen der Gewindeauspresseinheit

Geometrie Dinnen [mm] Daußen [mm] Länge [mm] Winkel [°]

67 (Bohrung) Verlängerungsstange 9,5 10, 00 67 (am Bolzen) Senkschraube 4 13 (Schaft) 30 (Kopf) Feder 4,5 1 (Schaft) Halter 4,5 2,5 (Schaft) 30 (Senkung)

Die zweite Baugruppe ist ein Sternmotor, bestehend aus vier identischen Kolben, die in einem zylindrischen Gehäuse geführt werden. Die Dateien wurden von der Seite GrabCAD 35 geladen. Der Abtrieb erfolgt über vier Pleuel sowie eine gelagerte Welle (siehe Abbildung 46). In der Abbildung ist das „Lager 1“, mit dem die Welle gelagert ist, auf der Rückseite der Baugruppe verdeckt.

35 https://grabcad.com.

126

5 Exemplarische Umsetzung relevanter Bedarfe

Zylinder

Kolben

Lager 1

Welle

Pleuel

Lager 2

Abbildung 46: Explosionsdarstellung des Sternmotors

Die Tabelle 34 fasst relevante Dimensionen des Sternmotors zusammen. Exemplarisch ist Lager 2 von insgesamt vier baugleichen Lagern in der Tabelle aufgeführt. Die Angaben ohne Funktion in der Spalte Daußen (Außendurchmesser) beschreiben, dass diese Dimensionen keinen funktionalen Zusammenhang zu einer anderen Datei der betrachteten Baugruppe aufweisen. Der Algorithmus sollte diese demnach als irrelevant identifizieren. Jedoch finden sich für den Kolben Dinnen = 8 mm und die Welle Daußen = 8 mm, diese offenbar theoretisch zueinanderpassen.

Tabelle 34: Ausgewählte Dimensionen des Sternmotors

Geometrie Dinnen [mm] Daußen [mm] Länge Winkel [°] [mm] 11 (Zylinder) 8 (ohne 6 (Lagersitz - 2) Kolben 25 Funktion) 5 (Pleuelsitz) 4 (ohne Funktion) Zylinder 11 (Kolben) Lager 2 6 15 (Abrollfläche) 8 (ohne Funktion) Welle 6 (ohne Funktion) 5 (ohne Funktion) Pleuel 5 (Kolben) 6 (ohne Funktion)

127

5 Exemplarische Umsetzung relevanter Bedarfe

Zu Test 2) Der Algorithmus aus Abschnitt 5.3.1 untersucht acht mechanische Maschinenteile, die in Realität keinen funktionalen Bezug zueinander aufweisen. Der Test wird positiv bewertet, wenn die Teile als nicht zusammengehörend identifiziert werden. Die hierfür verwendeten Teile finden sich in einer isometrischen Ansicht in

Abbildung 47.

Abbildung 47: Maschinenelemente ohne Bezug zueinander

Die Bauteile sind hinsichtlich ihrer Proportionen in der Abbildung nicht maßstabsgetreu abgebildet. Teile, wie die Distanzhülse, sind sehr viel kleiner als die Schraube oder der Zylinderkopf. Eine Übersicht zu den relevanten Dimensionen gibt Tabelle 35. Die Bauteile wurden aus dem Internet von der Seite GrabCAD geladen. Dinnen bezeichnet den Innendurchmesser und Daußen den Außendurchmesser. Die Länge, die bei der Feder vermerkt ist, entspricht der abgewickelten Drahtlänge. Der Querschnitt der Feder ist oval, somit zeigt die Tabelle 35 keine Durchmesser. Die Werte zwischen Pleuel und Distanzhülse haben lediglich 1 mm Unterschied zueinander an Innen- und Außendurchmesser, was einem Wert von ~12 % entspricht. Dieser ähnliche charakteristische Wert sollte durch den Algorithmus nicht vermindert berücksichtigt werden. Die Bremsscheibe ist durch viele unterschiedliche Radien an den Ausschnitten aufgebaut und die Klinkenplatte weist an der Verzahnung sowohl nach innen als auch nach außen orientierte Krümmungen auf. Alle Radien werden durch den Algorithmus in Beziehung zueinander gesetzt. Die Tabelle zeigt weiterhin, dass die Funktionsflächen, wie etwa Gewinde der Teile, nicht in Relation zueinanderstehen. Somit

128

5 Exemplarische Umsetzung relevanter Bedarfe sollte der Algorithmus diese auch als nicht zusammengehörend bewerten. Der Test wird positiv bewertet, wenn alle Teile korrekt als nicht zusammengehörend identifiziert werden.

Tabelle 35: Ausgewählte Dimensionen nicht zusammengehörender Maschinenelemente

Länge Höhe Geometrie Dinnen [mm] Daußen [mm] [mm] [mm] 14 (kleine Bohrungen) Klinkenplatte 153 (am Umfang) 2,6 40 (große Bohrungen) Zylinderkopf 323 (Pleuelbefestigung) 1613

Schraube 20 (Gewinde außen) 40 (Schaft) 15.5 (Gewinde innen) 58 (gesamt) Pleuel 5 8 27

11 (roter Bereich) Verstellhebel 7 (im Rohr) 250 10 (roter Bereich)

Distanzhülse 9 15 7 36 (Lagerfläche zur Achse) Bremsscheibe 5,5 (zwischen Außen- und 80 (am Umfang) 1,2 Innenteil) Feder 555

Im Zuge einer weiteren Untersuchung zu Test 2 wird ein einzelnes Modell vorsätzlich falsch innerhalb einer außerdem funktional stimmenden Baugruppe platziert. Dieses falsch zugeordnete Modell soll vom Algorithmus identifiziert werden. Dazu wird zu der oben beschriebenen Baugruppe des Sternmotors (siehe Abbildung 46) der Verstellhebel aus der

Menge der nicht zusammengehörenden Teile (siehe auch

Abbildung 47) hinzugefügt. Diese Untersuchung wird dann positiv bewertet, wenn der Verstellhebel mit keinem anderen Bauteil in Verbindung gebracht werden kann.

Zu Test 3) Für die Überprüfung wird zunächst eine Variante der bereits bekannten Spindelauspresseinheit (siehe Abbildung 45) neu erstellt. Es wird dazu Autodesk Fusion360 verwendet und es findet wiederum ein Export nach STEP statt. Es wird die Länge von Zylinder und Bolzen verlängert. Die beiden Varianten der Baugruppe sind in sich funktionsfähig, die Länge des Bolzens und der Feder wurden adaptiert. Die Halter passen variantenübergreifend

129

5 Exemplarische Umsetzung relevanter Bedarfe zu beiden Verlängerungsstangen. Relevante Dimensionen zur Verlängerung des Bolzens um 10 mm sind in der Abbildung 48 visualisiert.

Abbildung 48: Verlängerung des Bolzens

Der Test ist wiederum so angelegt, dass dem Algorithmus aus Abschnitt 5.3.1 die Teile Feder und Verlängerungsstange jeweils in der langen und kurzen Version als unabhängige STEP Dateien zur Verfügung gestellt werden. Zusätzlich liegen der Halter und die Schrauben vor. Der Test wird in dem Fall positiv bewertet, wenn die beiden nicht kompatiblen Verlängerungsstangen und Federn entsprechend identifiziert werden und ebenso dann, wenn die weiterhin kombinierbaren Halter und Schrauben mit beiden Verlängerungsstangen und Federn zueinander passen.

5.3.3 Versuchsergebnisse

Im Folgenden sind die Ergebnisse der drei Teilversuche zu den Daten und Versuchsplänen aus Abschnitt 5.3.2 dargestellt.

Zu Test 1) Die Ergebnisse, die der Algorithmus mit den Versuchsdaten der Verlängerungsstange erzeugt, sind als Ausschnitt in der Abbildung 49 dargestellt.

Der Ausschnitt des Ergebnisses zeigt, dass jeweils zwei Bauteile miteinander in Beziehung gesetzt werden, was in dem roten Kasten zu beobachten ist. Weiter unten im Bild sind die ausgelesenen Werte der charakteristischen Merkmale, jeweils für eine Bauteilpaarung, aufgelistet. Diese werden dazu verwendet, um die Ergebnisse der Berechnung nachzuvollziehen, indem die entsprechenden Merkmale der jeweiligen Bauteile betrachtet

130

5 Exemplarische Umsetzung relevanter Bedarfe werden. In der Abbildung sind das beispielweise ein Außendurchmesser Daußen = 5 mm und ein Innendurchmesser von Dinnen = 4,75 mm.

Abbildung 49: Auszug der Ergebnisse für die Verlängerungsstange

Eine Übersicht der vollständigen Ergebnisse ist in Tabelle 36 aufgeführt. Als Orientierung zur Eigeneinschätzung dient dem Leser die Visualisierung der Bauteile in Abbildung 45.

Durch die Betrachtung der Tabelle 36 wird deutlich, dass wesentliche Bauteile, entsprechend den reellen Gegebenheiten in der Baugruppe, miteinander in Verbindung gebracht werden können. Diese Einschätzung entsteht durch den Wahrscheinlichkeitswert > 60 % für alle STEP Datei Kombinationen. Die Paare Halter-Feder und Feder-Schraube mit einer errechneten Wahrscheinlichkeit von 0,6 befinden sich im Grenzbereich der Bewertung. Dieser verhältnismäßig geringe Wert resultiert daraus, dass jeweils lediglich der Durchmesser, aber nicht die Länge der charakteristischen Bohrungen und auch keine weiteren relevanten Merkmale gefunden werden können. Der hohe errechnete Wert von 0,86 für das Paar Verlängerungsstange-Feder beruht auf den korrespondierenden Merkmalen der Radien an der Doppelbohrung für die Schraube sowie auf dem Radius an der Kante zum Positionieren der Feder in der dafür vorgesehenen Aussparung.

131

5 Exemplarische Umsetzung relevanter Bedarfe

Tabelle 36: Ergebnisse für die Spindelauspresseinheit

errechnete tatsächliche Nr. Bauteil 1 Bauteil 2 Wahrscheinlichkeit Zusammengehörigkeit Verlängerungs- 1 Halter 0,8 ja stange 2 Halter Feder 0,6 ja 3 Halter Schraube 0,73 ja Verlängerungs- 4 Feder 0,86 ja stange 5 Feder Schraube 0,6 ja Verlängerungs- Verlängerungs- 6 0,72 ja stange stange Verlängerungs- 7 Schraube 0,33 ja stange

Der niedrigste Wert von 0,33 für die Kombination Verlängerungsstange-Feder widerspricht dem tatsächlichen funktionalen Zusammenhang. Der funktionale Zusammenhang von Feder und Nut wird durch den Algorithmus nicht erkannt und bewertet. Der Zusammenhang der Breite der Aussparung in der Verlängerungsstange und der Feder wird erkannt, ebenso die doppelte Bohrung, die in beiden Bauteilen vorliegt. Weiterhin werden keine Bezüge zwischen den Bauteilen festgestellt, jedoch sehr viele charakteristische Merkmale. Dadurch wird der prozentuale Wert entsprechend der Formel (2) zu gering.

Insgesamt kann der Teilversuch positiv bewertet werden, denn es wurden fachlich korrekte Werte der Zusammengehörigkeit errechnet. Ebenso stimmten die Tendenzen mit der Realität überein. Für das Beispiel Halter-Feder weniger deutlich mit 0,6 oder klar mit 0,73 für das Paar Halter-Schraube. Der einzelne fehlerhafte Wert deutet an, dass eine alleinige Korrektur der Variantenzuordnung auf Basis des Algorithmus nicht zulässig ist.

Die Ergebnisse, die der Algorithmus mit den Versuchsdaten des Sternmotors erzeugt, sind als Ausschnitt in Abbildung 50 dargestellt. Abbildung 50 verdeutlicht, exemplarisch für die Paarung Kolben-Lager, dass insbesondere Zylinder mit unterschiedlicher Orientierung als

132

5 Exemplarische Umsetzung relevanter Bedarfe charakteristische Merkmale zwischen beiden Bauteilen gefunden wurden, was im roten Kasten in der Abbildung zu sehen ist.

Abbildung 50: Ergebnis Ausdruck des Sternmotors

Eine Übersicht der vollständigen Ergebnisse ist in Tabelle 37 aufgeführt. Zur Orientierung der dargestellten Werte dient Abbildung 46 auf Seite 127. Anders, als für die Baugruppe der Verlängerungsstange, sind bei dem Sternmotor nicht alle Bauteile funktional miteinander gekoppelt. In der Spalte tatsächliche Zusammengehörigkeit sind demnach die Bauteilpaarungen mit ja angezeigt, die in Realität funktional miteinander verbunden sind. Mit nein sind solche gekennzeichnet, die zwar zu der Baugruppe gehören, aber keinen direkten Bezug zueinander haben.

Tabelle 37: Ergebnisse für den Sternmotor

errechnete tatsächliche Nr. Bauteil 1 Bauteil 2 Wahrscheinlichkeit Zusammengehörigkeit 1 Kolben Lager 1 0,43 nein 2 Kolben Lager 2 0,51 ja 3 Kolben Welle 0,7 nein 4 Kolben Zylinder 0,38 ja 5 Kolben Pleuel 0,8 ja 6 Lager 1 Lager 2 0,33 nein 7 Lager 1 Welle 0,88 ja 8 Lager 1 Zylinder 0,33 nein 9 Lager 2 Welle 0,7 nein 10 Lager 2 Zylinder 0,33 nein 11 Welle Zylinder 0,37 nein 12 Pleuel Welle 0,58 nein 13 Pleuel Lager 2 0,33 nein 14 Pleuel Lager 1 0,37 nein 15 Pleuel Zylinder 0,38 nein

133

5 Exemplarische Umsetzung relevanter Bedarfe

Eine real zusammengehörende Bauteilpaarung, die nicht korrekt aufgefunden wurde, ist in Tabelle 37 in Zeile 4 Kolben-Zylinder zu finden. Der relativ kleine Wert von 0,38 lässt sich ebenfalls mit der umfangreichen Innengeometrie des Kolbens und zusätzlich mit den variablen Funktionsflächen des Zylinders erklären.

Nicht zusammengehörende Bauteile, die korrekt als solche identifiziert wurden, sind in Tabelle 37 in den Zeilen 1, 6, 8, 10, 11, 13, 14 und 15 aufgeführt. Der verhältnismäßig hohe Wert für die Bauteilpaarung Welle–Pleuel in Zeile 12 wird dadurch erzeugt, dass der Innendurchmesser Dinnen = 5 mm des Pleuelsitzes ebenso gut auf den Kolben passt, wie auf die Welle. Es wird somit deutlich, dass die alleinige Fokussierung auf Dimensionen ohne Berücksichtigung der Funktionalität weitere Aspekte- etwa dem Einbauort- nicht zielführend ist.

Fazit zu Test 1):

Die Daten für die Versuche entstammen unterschiedlichen Quellen, wie dem Internet, der eigenen Hand oder der Bereitstellung eines Unternehmens. Der Algorithmus reagiert auf alle der Daten gleich.

Zusammengehörige sowie unabhängige Bauteile wurden, abgesehen von zwei Ausnahmen, korrekt identifiziert. Das entspricht einer Genauigkeit von 90 %, damit ist der Algorithmus für die Bereitstellung möglicherweise nicht korrekt allokierter Design Artefakte geeignet. Vielschichtige Bauteil Geometrien, wie der Kolben sie aufweist aber auch Varianten mit vielen Bauteilen, ergeben eine Vielzahl an theoretischen Paarungen. Diese Kombinationsmöglichkeiten werden korrekt durch den Algorithmus identifiziert, jedoch sind diese inhaltlich nicht zwangsweise sinnvoll, wie am Beispiel des Pleuels klar wird. Es fehlt dem Algorithmus folglich eine Möglichkeit der Bewertung des Funktionszusammenhangs.

Zu Test 2) Die Ergebnisse, die der Algorithmus für die unabhängigen Bauteile errechnet hat, sind in der Tabelle 38 zusammengestellt. Orientierung zur eigenen Bewertung der Ergebnisse bietet die Visualisierung der Bauteile in

Abbildung 47. Die Spalte errechnete Wahrscheinlichkeit stellt das numerische Ergebnis des Algorithmus dar, die Spalte tatsächliche Zusammengehörigkeit zeigt die Verwendung der Bauteile in der Realität. Diese ist naturgemäß, entsprechend der vorliegenden STEP Dateien, stets negativ. Errechnete Werte < 0,4 werden als nicht zusammengehörend klassifiziert, Werte > 0,6 als zusammengehörend, solche dazwischen als indifferent.

134

5 Exemplarische Umsetzung relevanter Bedarfe

Tabelle 38: Ergebnisse für unabhängige Bauteile

errechnete tatsächliche Nr. Bauteil 1 Bauteil 2 Wahrscheinlichkeit Zusammengehörigkeit 1 Klinkenplatte Distanzhülse 0,34 nein 2 Klinkenplatte Feder 0 nein 3 Klinkenplatte Pleuel 0,56 nein 4 Klinkenplatte Schraube 0,52 nein 5 Klinkenplatte Verstellhebel 0,67 nein 6 Klinkenplatte Bremsscheibe 0,46 nein 7 Klinken Platte Zylinderkopf 0 nein 8 Distanzhülse Feder 0 nein 9 Distanzhülse Pleuel 0,33 nein 10 Distanzhülse Verstellhebel 0,56 nein 11 Distanzhülse Bremsscheibe 0,38 nein 12 Distanzhülse Schraube 0,33 nein 13 Distanzhülse Zylinderkopf 0,32 nein 14 Feder Pleuel 0 nein 15 Feder Schraube 0 nein 16 Feder Verstellhebel 0 nein 17 Feder Zylinderkopf 0 nein 18 Feder Bremsscheibe 0 nein 19 Pleuel Schraube 0,33 nein 20 Pleuel Zylinderkopf 0 nein 21 Pleuel Bremsscheibe 0,38 nein 22 Pleuel Verstellhebel 0 nein 23 Bremsscheibe Zylinderkopf 0,41 nein 24 Bremsscheibe Schraube 0,25 nein 25 Bremsscheibe Verstellhebel 0,33 nein 26 Schraube Verstellhebel 0,36 nein 27 Schraube Zylinderkopf 0 nein 28 Verstellhebel Zylinderkopf 0,25 nein

Die zuvor verwendeten Schwellwerte von < 0,4 für nicht zusammengehörend und > 0,6 für zusammengehörend werden auch in diesem Kontext angelegt. Insgesamt wurden 22 von 28 Kombinationen korrekt bewertet, das entspricht 79 %. Eine Kombination wurde falsch

135

5 Exemplarische Umsetzung relevanter Bedarfe eingeschätzt (siehe Zeile 5), die restlichen Kombinationen (18 %) konnten durch den Algorithmus nicht eindeutig identifiziert werden.

Eindeutig negativ bewertet wurden die Bauteilpaarungen in den Zeilen 2, 7, 8, 14-18, 20, 22 und 27 mit einer Wahrscheinlichkeit von 0 % Zusammengehörigkeit. Offensichtlich konnte das Ellipsoid der Feder mit keinem anderen Bauteil in Verbindung gebracht werden.

Die Bauteilpaarung Pleuel-Distanzhülse wird von dem Algorithmus mit einer Wahrscheinlichkeit von 0,33 als wenig eindeutig negativ bewertet. Die Distanzhülse ist ein geometrisch einfaches Bauteil, der Pleuel weist ebenso mehrere, nicht funktionale charakteristische Merkmale auf. Der Algorithmus bringt den Durchmesser Daußen = 15 mm der Distanzhülse mit den Radien Dinnen = 14,5 mm an der Verbindungstelle zwischen Schaft und Lagersitz des Pleuels in Zusammenhang. Dadurch entsteht die negative Bewertung. Auf diese Weise resultieren zudem die Werte der Zeilen 1, 9, 11-13, 19, 21, 24-26 und 28 durch jeweils einige grundsätzlich passfähige, der insgesamt verfügbaren, charakteristischen Merkmale.

In den STEP Dateien der Schraube finden sich Hilfsgeometrien sowie eine modellierte Beschriftung auf dem Schraubenkopf. Diese bedingen, dass die Schraube in Zusammenhang mit anderen Bauteilen gebracht wird, obschon das nicht der Realität entspricht. Dennoch sind die, in Zusammenhang gebrachten, charakteristischen Merkmale (~10) in der Summe deutlich kleiner, als die insgesamt vorliegenden (~40). Somit liegen die Werte im Bereich zwischen 0,3 und 0,4.

Die indifferent errechnete Zusammengehörigkeit der Zeilen 3-6 für die Bauteilpaarungen der Klinkenplatte wird durch die Radien der Verzahnung erzeugt. Diese bieten rechnerisch mehrere Möglichkeiten, andere Bauteile zu kombinieren. Dadurch, dass die Verzahnung mehrfach auftritt, werden entsprechend viele der gefundenen Merkmale als positiv bewertet. Ebenso erklärt sich der errechnete Wert von 0,56 in Zeile 10 für die Bauteilpaarung Distanzhülse-Verstellhebel. Die Hülse passt physisch in das Rohr des Verstellhebels. Der Wert liegt nicht höher, da aus der Menge der gesamten charakteristischen Merkmale beider Bauteile lediglich dieses eine als zusammengehörig identifiziert wurde.

Die zweite Untersuchung in Test 2 kombiniert den Verstellhebel aus der Menge der nicht zusammengehörenden Bauteile (siehe

Abbildung 47) mit dem Sternmotor (siehe Abbildung 46). Die Ergebnisse sind in Tabelle 39, auf die Ergebnisse zum Verstellhebel reduziert, zusammengestellt, da die Ergebnisse für die Zusammengehörigkeit des Sternmotors als Beschreibung in Test 1, Tabelle 37 bereits vorliegen.

Die Bauteilpaarungen der Zeilen 1-3 weisen den erwarteten Zugehörigkeitswert von 0 auf. Die Bauteilpaarung Verstellhebel-Lager 1 aus Zeile 5 der Tabelle 39 weisen beide eine

136

5 Exemplarische Umsetzung relevanter Bedarfe zylindrische Fläche mit D = 3 mm auf. Dasselbe gilt für die Bauteilpaarung Verstellhebel-Lager 2 in Zeile 6 und die Bauteilpaarung Verstellhebel-Welle. Aus diesem Grund sind alle drei Werte nicht 0 und dennoch deutlich kleiner als der Referenzwert von 0,4. Folglich sind sie als klar nicht zusammengehörend eingestuft.

Tabelle 39: Ergebnisse für Sternmotor und Verstellhebel

errechnete tatsächliche Nr. Bauteil 1 Bauteil 2 Wahrscheinlichkeit Zusammengehörigkeit 1 Verstellhebel Pleuel 0 nein 2 Verstellhebel Kolben 0 nein 3 Verstellhebel Zylinder 0 nein 5 Verstellhebel Lager 1 0,12 nein 6 Verstellhebel Lager 2 0,12 nein 7 Verstellhebel Welle 0,17 nein

Fazit zu Test 2): Der Test wird positiv bewertet, denn es wurden in beiden Teiluntersuchungen keine Kombinationsmöglichkeiten errechnet. Hilfsgeometrien oder nicht korrekt exportierte Teile können zu nicht der Realität entsprechenden Interpretationen durch den Algorithmus führen. Weiterhin bestätigt sich, dass aufwändige Geometrien Spielräume für Fehlinterpretationen bieten. Diese weisen immens vielfältige charakteristische Merkmale auf, die zudem konsequent in Zusammenhang mit charakteristischen Merkmalen anderer Bauteile gebracht werden können. Der Algorithmus in der vorliegenden Form kann keine Ellipsoide erkennen, somit konnte die Feder keinem anderen Bauteil zugeordnet werden. Eine Berücksichtigung dieses charakteristischen Merkmals würde die Präzision der Ergebnisse erhöhen.

Zu Test 3) Die Testergebnisse der fünf Bauteile Feder, Halter, Schraube, Verlängerung_kurz und Verlängerung_lang sind in Tabelle 40 zusammengefasst. Visuell wird die Zusammengehörigkeit der Bauteile in Abbildung 45 und Abbildung 48 dargestellt. Die in der Realität bestehende Zusammengehörigkeit ist in der Spalte tatsächliche Zusammengehörigkeit in Tabelle 40 zusammengefasst. Die Federn sind in der Länge auf die Nut zum Einrasten angepasst.

Die zuvor verwendeten Schwellwerte von < 0,4 für nicht zusammengehörend und > 0,6 für zusammengehörend werden ebenfalls in diesem Test angelegt. Der Einfluss der Variante wird im Vergleich der Zeilen 5, 9 und 10 deutlich. Die lange und kurze Verlängerungsstange passen entsprechend dem Algorithmus mit einem Wert von 0,66 zusammen, in der Realität jedoch nicht. Die lange und kurze Verlängerungsstange lässt sich in der Realität jeweils mit sich selbst kombinieren, mit einem Wert von 0,72 und 0,76. Der Längenunterschied der Zylinder-

137

5 Exemplarische Umsetzung relevanter Bedarfe

Bolzenverbindung wird entsprechend der May und Must Values gewichtet, somit ergibt sich die geringe Differenz der Werte.

Tabelle 40: Ergebnisse der Varianten der Spindelauspresseinheit

errechnete Tatsächliche Nr. Bauteil 1 Bauteil 2 Wahrscheinlichkeit Zusammengehörigkeit Verlängerungs- 1 Halter 0,54 ja stange_kurz Verlängerungs- 3 Feder_kurz 0,68 ja stange_kurz Verlängerungs- 4 Schraube 0,33 ja stange_kurz Verlängerungs- Verlängerungs- 5 0,76 ja stange_kurz stange_kurz Verlängerungs- 6 Halter 0,56 ja stange_lang Verlängerungs- 7 Feder_lang 0,66 ja stange_lang Verlängerungs- 8 Schraube 0,33 ja stange_lang Verlängerungs- Verlängerungs- 9 0,66 nein stange_lang stange_kurz Verlängerungs- Verlängerungs- 10 0,72 ja stange_lang stange_lang Verlängerungs- 11 Feder_kurz 0,57 nein stange_lang Verlängerungs- 12 Feder_lang 0,56 nein stange_kurz

Der Vergleich der Werte in den Zeilen 11 und 12 mit den Zeilen 3 und 7 zeigt den errechneten Unterschied für die passenden bzw. nicht passenden Bauteilpaarungen der Feder mit der Verlängerungsstange, jeweils in der kurzen und langen Version. Die errechnete Tendenz stimmt mit der Realität überein. Die nicht kombinierbaren Lösungen in Zeile 11 und 12 erzielen Werte von 0,56 und 0,57, die kombinierbaren Lösungen werden korrekt als solche, mit Werten von 0,68, erkannt. Die Ursache für diese Unterschiede liegt in der Länge der Nut der Verlängerungsstange, die für die passende Kombination ähnlich lang ist und damit als positives charakteristisches Merkmal identifiziert wird. Die indifferente Bewertung [0,4 < 0,56 (Zeile 11) < 0,6] der in Realität nicht funktional kombinierbaren Bauteile macht es dem Algorithmus unmöglich, diese als fehlerhaft der Variante zugeordnet zu identifizieren. Somit ist der Algorithmus nicht dazu in der Lage, eine Variante der Spindelauspresseinheit von einer anderen zu unterscheiden.

Wie in Test 1 werden die Schrauben durch den Algorithmus als nicht zusammengehörend bewertet. Dies ist nachvollziehbar, da sich die geometrischen Dimensionen für diesen Abschnitt nicht verändert haben.

138

5 Exemplarische Umsetzung relevanter Bedarfe

Fazit zu Test 3):

Der Algorithmus ist nicht dazu in der Lage, zwischen Varianten mit kleinen, sich in einzelnen charakteristischen Merkmalen äußernden Variationen der Bauteile zu unterscheiden. Dies wird verursacht, da der Algorithmus keine Möglichkeit besitzt, die relevante Funktion und die übergeordnete Verwendung zu identifizieren. Dafür wäre eine Assoziation der charakteristischen Merkmale im Kontext der Verwendung erforderlich.

5.3.4 Beurteilung der Ergebnisse zur Verwendung im InADM

Ein wesentliches Ergebnis der drei Tests ist, dass voneinander unabhängige Bauteile als solche identifiziert werden können (siehe Teilversuch 2, Abschnitt 5.3.3). Varianten eines Bauteils können allerdings mit der vorgestellten Methode nicht identifiziert werden, wie am Beispiel der gebildeten Variante der Verlängerungsstange der Spindelauspresseinheit deutlich wurde. Die Verwendung des Algorithmus erfolgt im InADM als Plausibilisierung der bereits gebildeten Varianten, mit dem Ziel, alle nicht zusammengehörenden Bauteile zu identifizieren. Das sind folglich solche, die mit keinem anderen Bauteil aus der untersuchten Menge positiv (< 0,4) in Verbindung gebracht werden können. Die Genauigkeit des Algorithmus für diese Aufgabe entspricht 87 %.

Eine Weiterentwicklung des Algorithmus für die Plausibilisierung von Varianten ist für die Identifikation von Funktionsflächen erforderlich. Funktionsflächen können etwa als Gewinde oder Klebe- und Schweißflächen in PMIs berücksichtigt werden, ebenso könnten Montageanweisungen Hinweise zur Zusammengehörigkeit geben. Diese könnten mit einer Gewichtung gegenüber anderen charakteristischen Merkmalen versehen werden, beziehungsweise auf das jeweilige Gegenüber hinweisen. Jedoch ist es oftmals einzig möglich, den funktionalen Zusammenhang aus der Verwendung im Kontext abzuleiten und nicht aus den Dateien selbst. Am Beispiel der Verlängerungsstange wird deutlich, dass mit den vorhandenen Daten keine Aussage darüber möglich ist, ob eine lange oder kurze Version zweckmäßig oder funktional ist. Eine Weiterentwicklung ist denkbar, indem ein Vergleich mit zuvor gebildeten Varianten der Zuordnung zu Modulen berücksichtigt wird.

(Dekhtiar 2018, S. 240) der sich ebenso mit der Interpretation von CAD Datei-Inhalten auseinandergesetzt, hält Austauschformate, wie das in diesem Kontext verwendete STEP Format, für nicht zielführend, da diese nicht zu jedem Zeitpunkt im Prozess verfügbar sind. Deshalb stellt er in Aussicht, direkt in den nativen Dateiformaten zu arbeiten. Zudem wäre es für die Ergebnisse dieser Arbeit zielführend, direkt die nativen Dateiformate zu interpretieren.

In Ergänzung zu dem entwickelten Algorithmus für geometrische Plausibilisierung von Varianten wird das InADM Konzept mit der bestehenden Clash and Clearance Analyse ausgestattet. Diese kann ebenso dysfunktionale Varianten identifizieren, indem für

139

5 Exemplarische Umsetzung relevanter Bedarfe

Baugruppen Überschneidungen der Geometrien angezeigt werden. Gegenüber der vorgestellten Methode ist das Clash and Clearance auf die korrekte Positionierung der Geometrien angewiesen. Weiterhin können flexible Bauteile, wie Kissen oder bewegte Bauteile, durch die Clash and Clearance Analyse in Abhängigkeit ihrer Position als scheinbare Fehler zurückgegeben werden. Deshalb erscheint für das InADM Konzept eine Kombination der Methoden als zielführend.

Bei der Implementierung wurde die Zeit für die Ausführung des Algorithmus bislang außer Acht gelassen. Die Rückgabe der Werte erfolgt in der vorliegenden Version des Algorithmus innerhalb von etwa 20-30 Sekunden für 10 Bauteile, die zeitgleich auf Kompatibilität untersucht werden. Die Geschwindigkeit der Kalkulation sollte für industrielle Anwendungen optimiert werden, beispielsweise indem bereits bewertete Teile nicht erneut geprüft werden oder frühere Abbruchkriterien integriert werden, wenn die charakteristischen Merkmale nicht aussagekräftig sind.

5.4 Plausibilisierung auf Basis von Identifikationsdaten

Eine Plausibilisierung von vorliegenden Produktvarianten erfolgt auf Basis der Identifikation, folglich der Benennung und Nummerierung von Design Artefakten. Die Benennung und Nummerierung der Design Artefakte wird mit der Bag-of-Words Methode in statistisch interpretierbare Vektoren überführt. Die Nearest-Neighbour Methode überprüft die statistische Korrektheit der Vektoren im Vergleich zu bereits bestehenden Varianten. Auf diese Weise werden für eine bestimmte Produktvariante atypische Design Artefakte identifiziert. Die statistisch auffälligen Werte werden der Prüfliste zugeführt und an denjenigen zurückgegeben, der die Verbindung initial erzeugt hat. Die Plausibilisierung auf Basis der Identifikationsdaten erfolgt, entsprechend dem InADM Konzept, ohne Involvierung des Anwenders, solange bis Manipulationen an der Variantenzuordnung erforderlich erscheinen.

Durch die im InADM vorgesehene automatisch vergebene Nummer wird zukünftig die kombinierte Verwendung von Bezeichnung, Nummer und Version erforderlich sein. Die Bezeichnung für sich ist im Sinne einer eindeutigen Identifikation nicht aussagekräftig.

Um eine automatische Plausibilisierung im Kontext des InADM zu realisieren, ist es erforderlich, dass:

• die Plausibilisierung periodisch auslöst • eine Rückmeldung an die Prüfliste ohne menschliche Interaktion verläuft • ein Zugriff auf die bestehenden Varianten – also historische Daten - für die Interpretation zur Verfügung steht

140

5 Exemplarische Umsetzung relevanter Bedarfe

Für die Umsetzung im experimentellen Umfeld wird eine Interaktion mit einem rudimentären Nutzerinterface direkt auf der Datenbasis implementiert. Eine Einbindung in die anderen Funktionen des InADM, wie die Prüfliste, ist für den Funktionsnachweis nicht erforderlich.

5.4.1 Funktionsweise des Nearest Neighbour Verfahrens

Um festzustellen, ob ein Vektor zu einer Variante gehört, können grundsätzlich Approximations- oder Klassifikationsverfahren verwendet werden (Ertel 2016, S. 206). Approximationsverfahren werden in der Regel angewendet, wenn die Eingangsdaten unendlich sind. Somit kommt ein Klassifikationsverfahren zum Einsatz. Der Ausgabewert ist ebenso endlich durch die Bewertung der Zugehörigkeit. Die einzelnen Vektoren, die als Input aus der Bag-of-Words Methode zur Verfügung stehen, sind mitunter abhängig voneinander – einzelne Tokens, also Bauteile, kommen in mehreren Bag-of-Words, also Varianten, vor. Somit scheiden probabilistische Verfahren, wie das Bayes Verfahren, als Methode aus, da sie eine Unabhängigkeit der Daten voraussetzen. Die Vektoren befinden sich in einem n- dimensionalen Raum. Für die Anwendung der präzise funktionierenden Support Vektor Machines (SVM) wäre zur Klassifizierung ein 2-dimensionaler Raum erforderlich. Die Vektoren könnten über einen weiteren Rechenschritt in diesen Raum projiziert werden. Die von (Ertel 2016, S. 206) als Möglichkeit der Klassifizierung beschriebene Nearest Neighbour Methode (NNM) benötigt diesen zusätzlichen Rechenschritt nicht. Weiterhin kann sie, ebenso wie die SVM, ohne lineare Separierung von Klassen erfolgreich agieren.

Das Nearest-Neighbour Verfahren wird ohne Trainingsdatensätze auf eine bestehende Datenmenge vollumfänglich angewandt. Der Abstand aller Datenpunkte oder Vektoren zueinander wird bestimmt, dadurch ergibt sich für jeden Datenpunkt ein gewisser Raum, in Abbildung 51 ist er als Waben um die grauen Punkte herum dargestellt.

Um eine Klassifikation vorzunehmen, erhält die Methode durch den Anwender Vorgaben zur Klassifikation jedes Randvektors, welcher durch die rote Trennlinie in Abbildung 51 symbolisiert ist. Die NNM errechnet den Abstand zwischen einem zu prüfenden Datensatz „s“ im Vergleich zu allen bestehenden Vektoren oder Datenpunkten und findet den nächsten Nachbarn „k“. Der neue Vektor „s“ wird entsprechend der zuvor festgelegten Klassendefinition M+ und M- der Klasse M- zugeordnet.

141

5 Exemplarische Umsetzung relevanter Bedarfe

Abbildung 51: Funktionsweise der Nearest Neighbour Methode

Die Berechnung des vektoriellen Abstands zwischen den Vektoren „s“ und den bestehenden erfolgt über einen euklidischen Abstand, entsprechend der Formel (4). Die in der Formel enthaltenen Werte x, y entsprechen im Anwendungsbeispiel den Variantenvektoren. Der Abstand D wird zunächst auf alle Vektoren angewendet; D wird im Beispiel minimal für k, die Rückgabe erfolgt dann als Klassenzugehörigkeit M- für das Beispiel des Vektors „s“.

� (4) D (x, y) = | x − y | = √∑(xi − �i)² �=1

5.4.2 Anwendung auf die Ermittlung von Varianten

Um einen bestehenden Datensatz zu analysieren, wurde ein Programm erstellt, welches die BOW und NNM Methode ausführt. Dieses wurde mit der Sprache C# erstellt und ist im digitalen Anhang (Fresemann und Bittcher 2020a) in vollständiger Form zu finden. Der Datensatz, der für das Experiment verwendet wird, lagert in einer Access Datenbank. Das Programm verfügt über eine Schnittstelle zu der Access Datenbank sowie über eine Visualisierung der Rückgabewerte. Der Programmablauf ist in Abbildung 52 dargestellt.

Der Anwender initiiert den Programmstart, die BOW Methode erzeugt Variantenvektoren aus den Nummern der Bauteile. Um die korrekte Funktionsweise für den Anwender während der Versuche nachvollziehbar zu gestalten, werden die Vektoren geordnet und können bei Bedarf durch die Funktion „order“ visualisiert werden.

142

5 Exemplarische Umsetzung relevanter Bedarfe

Der Funktionsblock „classification“ wird wiederum durch den Nutzer aktiviert und ein ausgewählter Vektor der Datenmenge wird über die dahinterliegende NNM klassifiziert und entsprechend zurückgegeben.

Abbildung 52: Sequenzdiagramm des erstellten SW-Codes zur Plausibilisierung von Varianten

Die Versuchsdaten liegen in einer Access Datenbank vor, aus dieser werden relevante Daten über SQL 36 angefragt (siehe Abbildung 53). Für die Versuchsdurchführung findet die Anwenderkommunikation über eine Windows Forms Applikation „user interface WF“ statt. Der Algorithmus ist derart aufgebaut, dass er die Versuchsdaten sowie die Visual Studio Anwendung, C# NNM, in demselben Explorer Ordner erwartet.

Abbildung 53: IT-Architektur Schaubild zur Plausibilisierung mittels Identifikationsdaten

36 Structured Query Language, Sprache zur Abfrage in relationalen Datenbanken.

143

5 Exemplarische Umsetzung relevanter Bedarfe

5.4.3 Versuchsaufbau und Daten

Ziel dieses Versuchs ist es, die Funktionsfähigkeit der statistischen Plausibilisierung von Produktvarianten, wie sie in Abschnitt 5.4.2 vorgestellt wurde, zu erproben. Um die Funktionsfähigkeit des Algorithmus zu prüfen werden dem Datensatz manuell Fehler zugefügt, die dieser im Laufe des Versuchs vollständig identifizieren soll.

Als Versuchsdaten steht eine Liste mit etwa 1000 „As-Built“ Fahrzeugen, inklusive der Angabe einer laufenden Fahrzeugnummer, einem Identifikationscode für die Variante sowie den versionierten Bauteilen und deren Bezeichnung zur Verfügung. Die in Tabelle 41 vereinfacht dargestellten Werte liegen in der benannten Access Datenbank vor, die ein direkter Extrakt einer Datenbank eines Automobilherstellers ist.

Die Anzahl der Design Artefakte zu einer Variante schwanken zwischen etwa 70 und einem Eintrag pro Variante, wobei die kurzen Variantenvektoren deutlich häufiger auftreten. Die Bag- of-Words erstellt zunächst Vektoren, die jeweils alle Design Artefakte einer Variante, pro

Fahrzeug auflisten. Am Beispiel der Tabelle 41 heißt der Vektor V1 (0815, ABCDE) = (A150 1234). Die Verwendung der Fahrzeugidentifikationsnummer wird verwendet, um während des Versuchs Orientierung im Gesamtdatensatz zu erhalten.

Tabelle 41: Schematischer Aufbau der Versuchsdaten

BT Fahrzeugidentifikation Variante Bauteilnummer BT Version Bezeichnung 0814 BCDEF A149 1234 AAB Pedal 0815 ABCDE A150 1234 AAA Schiebedach

Für den Versuch werden aus den Versuchsdaten zwei Varianten mit einer Länge von jeweils mindestens 15 Einträgen - also Bauteilen - zufällig ausgewählt. Eine weitere Prämisse für die Auswahl der Varianten ist, dass sie jeweils in mindestens 15 Fahrzeugen Verwendung finden. Es wird das folgende Versuchsprogramm durchlaufen:

Voruntersuchung: Die Originaldaten werden unverändert für beide Varianten mit den NNM klassifiziert. Die Anwendung auf die Originaldaten erfolgt, um festzustellen, ob ein auffälliger Wert in den zufällig ausgewählten Variantenvektoren vorliegt.

Test 1: Dem ersten Vektor (Variante 1, Fahrzeug 2) wird ein Design Artefakt entnommen.

Test 2: Dem zweiten Vektor (Variante 1, Fahrzeug 5) werden zwei Design Artefakte entnommen.

144

5 Exemplarische Umsetzung relevanter Bedarfe

Test 3: Dem dritten Vektor (Variante 2, Fahrzeug 4) werden zwei Design Artefakte hinzugefügt.

Der Versuch wird dann positiv bewertet, wenn alle manuell hinzugefügten Fehler identifiziert werden.

5.4.4 Versuchsergebnisse

Dieser Abschnitt berichtet über die Ergebnisse des oben dargelegten Versuchsablaufs.

Die Voruntersuchung zeigt, dass sich die zwei ausgewählten Varianten deutlich voneinander unterscheiden. Der erste Variantenvektor besteht aus 18 Design Artefakten, wird in 14 Fahrzeugen verwendet und verfügt im Originaldatensatz über keine Abweichungen zwischen den Fahrzeugen. Der zweite Vektor besteht aus 59 Design Artefakten und wird in 98 Fahrzeugen verwendet. Gleichzeitig weist er bereits im Originaldatensatz neun unterschiedliche Ausprägungen auf. Diese neun Ausprägungen manifestieren sich in jeweils ein bis zwei Design Artefakten. Die Daten werden als korrekt positioniert innerhalb der Varianten angenommen. Identische Vektoren haben einen Rückgabewert von „0“, entsprechend der NNM. Je weiter der Wert abweicht, desto größer ist folglich der Abstand zum korrekt definierten Variantenvektor.

Für Test 1 wurde dem ersten Variantenvektor ein Datensatz, der ein Bauteil repräsentiert, entnommen. Dieser wurde durch die Verwendung des Algorithmus identifiziert. Folgend zeigt der Screenshot der Rückgabe des Algorithmus in Abbildung 54 im unteren Bereich 2 Variantenvektoren. Die rote Markierung in der Abbildung 54 zeigt die Position und das fehlende Bauteil an Position 1 (oberste Zeile der Rückgabewerte des Algorithmus) an. Die Abbildung 54 zeigt weiterhin eine Spalte mit der Wahrscheinlichkeit (engl.: probability). Die künstlich erzeugte Variante wird mit einer Wahrscheinlichkeit von 7 % ermittelt. Für eine industrielle automatische Anwendung im Hintergrund muss ein Unternehmen folglich einen Grenzwert definieren der den Einbezug eines Nutzers anzeigt. Basierend auf den hier verwendeten Datensätzen wäre es empfehlenswert alle Variantenvektoren kleiner 20% zu kontrollieren und schrittweise die Präzision des Algorithmus und die Korrektheit der Daten aufeinander abzustimmen.

145

5 Exemplarische Umsetzung relevanter Bedarfe

Position Benennung Design Artefakt Variante 1 Variante 2

Abbildung 54: Screenshot der Rückgabe für den Versuch „ein fehlendes Bauteil“

Im Test 2 wurde dem ersten Variantenvektor zwei Bauteile entnommen, nun am Beispiel eines anderen Fahrzeugs. Die fehlenden Bauteile wurden wiederum korrekt identifiziert (siehe Abbildung 55, Variante 2 mit den Unterschieden an den Positionen 13 und 17. Der Abstandswert beträgt für diese beiden Vektoren D(SFI1,SFI2) = √2 = 1,4 aufgrund der zwei voneinander abweichenden Einträge.

Position Benennung Design Artefakt Variante 1 Variante 2

Abbildung 55: Screenshot der Rückgabe für den Versuch "zwei fehlende Bauteile"

Die Ergänzung von zwei zusätzlichen Bauteilen in Test 3 konnte für den zweiten Variantenvektor erfolgreich identifiziert werden. Der rote Kreis in Abbildung 56 zeigt die manuell ergänzten Datensätze an den Positionen 59 und 60.

146

5 Exemplarische Umsetzung relevanter Bedarfe

Position Benennung Design Artefakt Variante 1 Variante 2 Variante 3

Abbildung 56: Screenshot der Rückgabe für den Versuch "zwei zusätzliche Bauteile"

Die Vektoren weisen einen Abstand von 1,73, entsprechend der NNM, auf. Dieser Wert fällt bei der Betrachtung der anderen Vektoren nicht stark ins Gewicht, denn die Differenzen zwischen den Werten des industriellen Originaldatensatzes liegen ebenfalls zwischen 1 und 2. Es wurde zusätzlich die prozentuale Auftretenswahrscheinlichkeit errechnet. Durch diese fällt der manuell modifizierte Vektor stärker auf, da er lediglich einmal vorkommt und damit einzig mit 1 % Wahrscheinlichkeit auftritt. Somit sind für eine erfolgreiche Bewertung des Algorithmus neben der Abweichung zu anderen Variantenvektoren durch die NNM auch die Auftretenswahrscheinlichkeit zu betrachten.

5.4.5 Beurteilung der Ergebnisse zur Verwendung im InADM

Es konnte mit Hilfe der Teilversuche 1-3 nachgewiesen werden, dass Abweichungen von Varianten zueinander durch die NN Methode identifiziert werden. Diese identifizierten Abweichungen erlauben somit eine Plausibilisierung der zum jeweiligen Zeitpunkt vorliegenden Konfiguration mit Blick auf zuvor bestehende Konfigurationen.

Eine statistische Relevanz kann durch die NNM erzielt werden, sobald bestehende Produkte in größeren Stückzahlen vorliegen, denn der Vergleich zu älteren Varianten kann augenscheinlich nur dann erfolgen, wenn diese in einer entsprechenden Stückzahl existieren. Durch Stichproben in den bestehenden Datensätzen ist zu vermuten, dass Varianten, die weniger als 10 Mal vorkommen sowie aus lediglich ein bis zwei Einträgen bestehen, nicht sinnhaft algorithmisch geprüft werden können.

Die Versuchsdaten bestehen aus Daten, die physische Teile beschreiben, jedoch kann die Anwendung ohne weitere Adaption alle Design Artefakte, beispielsweise Software oder

147

5 Exemplarische Umsetzung relevanter Bedarfe

Berechnungen, berücksichtigen. Denn diese sind ebenfalls mit einer Identifikation (Name und Nummer) versehen.

Das oben beschriebene Verfahren wird auf der sprechenden Nummer des Design Artefakts angewendet, da sie in dem exemplarischen industriellen Datensatz vorhanden und einfach zugänglich ist. Ebenso könnte die Bezeichnung eines Design Artefakts als Eingabewert, oder auch eine nicht sprechende Nummer, wie sie für die vollständige Umsetzung des Konzepts avisiert ist, herangezogen werden.

Um die Anwendung automatisiert zu applizieren bedarf es einer sauberen Datenlage, gegebenenfalls einer Korrektur gemäß des Brownfield Ansatzes sowie einer regelmäßigen Kontrolle der zugrundeliegenden Annahmen, wie beispielsweise der pro Variante zugeordneten Design Artefakte. Zeitbedingte Veränderungen der Varianten sollten für eine Klassifikation in gut oder schlecht Werte durch einen geeignet qualifizierten Mitarbeiter gesetzt werden. Weiterhin ist für eine industrielle Anwendung eine Anbindung an ein Datenbanksystem vorzusehen.

Die an dieser Stelle applizierte Anwendung in der MS Visio Umgebung entspricht keiner praxistauglichen Umsetzung. Die Anwendung ist im Gesamtkonzept des InADM derart verankert, dass sie im Hintergrund agiert. Somit muss in einer unternehmensindividuellen Anpassung der Zyklus des internen Ausleitens von Produktvarianten sowie eine Festlegung zur Prüfung aller oder ausgewählter Variantenklassen definiert werden. Weiterhin wurden die Versionen der Design Artefakte vernachlässigt. Dieses Vorgehen sollte jedoch für Unternehmen eigenständig adaptierbar sein. Ein Grenzwert ist beispielsweise dann festzulegen, wenn eine Korrektur bei einer bestimmten prozentualen Auffälligkeit und einer besonders hohen Distanz zwischen zwei Varianten einzuleiten ist. Auf Basis der durchgeführten Versuche erscheinen Abweichungen von P < 5 % und gleichzeitig D > 1,2 % als relevanter Grenzwert für eine falsche Zuordnung der Variante. Die beschriebenen Adaptionen sind in einer Administrationsebene durchzuführen.

Die NNM benötigt kein Training somit entspricht das ausgewählte Verfahren dem Anspruch im Hintergrund zu agieren.

Ein weiterer Schritt in Richtung eines autark handelnden Werkzeugs wäre, die Einstellungen in der Administrationsebene zu verschieben, beispielsweise indem Regressionen die Entwicklung der Varianten im Laufe der Zeit beurteilen. Darüber hinaus wäre es möglich, dass ein selbstlernender Algorithmus die Klassen der Varianten eigenständig ermittelt, beispielsweise indem ihm vorgegeben wird, nach Klassen zu suchen, die bereits in den Referenzobjekten (siehe Abbildung 12) definiert sind. Wird diesem Vorschlag Folge geleistet, gilt es zudem, zu erproben, ob die industriell erforderliche Präzision eingehalten werden kann.

148

5 Exemplarische Umsetzung relevanter Bedarfe 5.5 Zwischenfazit

Dieser Abschnitt summiert die Beobachtungen der technologischen Umsetzung der Funktionen auf und zieht erste Rückschlüsse. Vier der fünf Algorithmen reagieren bei den verwendeten Datensätzen inklusive aller Ausnahmen zufriedenstellend im Sinne der Produktdatenverwaltung. Dies ist nachvollziehbar, da die Methoden in der Mehrheit auf lernenden Algorithmen oder Statistiken beruhen und diese oftmals mit Wahrscheinlichkeiten von 95 % agieren. Weiterhin sind Produktdaten nicht homogen und Unterschiede werden stetig zu Fehlinterpretationen führen, so, wie es auch im Bereich des DMU zu „falsch“ identifizierten Überschneidungen kommt. Auf Basis dieser Überlegung ist eine Verwendung der Ergebnisse der Algorithmen als Entscheidungsgrundlage im Gesamtkonzept zu verankern.

Die technologisch untersuchten Aspekte der Produktdatenverwaltung zur Erzeugung von Relationen für Gliederung oder als Ersatz für Metadaten konnte in Abschnitt 5.1 gezeigt werden. Ebenso konnte die technologische Hypothese für die Variantenverwaltung in den Abschnitten 5.2 - 5.4 nachgewiesen werden.

Insbesondere hinsichtlich der Klassifizierung in den Abschnitten 5.1 und 5.2 wurde deutlich, dass aktuelle Programme, die auf NLP basieren aber auch konventionelle, die ausschließlich regelbasiert arbeiten, jeweils alleine keine geeignete Qualität der Zuweisung erzielen können. Die Kombination aus Nutzereingabe, regelbasiertem und statistischem Vorgehen kann eine korrekte Zuweisung erzeugen. Dabei wurden, ausgehend von unterschiedlichen Fragestellungen, jeweils dieselben Verfahren gefunden, die die Zuweisung unterstützen. Diese sind die Bildung von Indizes und die Gewichtung einzelner Begriffe innerhalb dieser Indizes. Aufgrund ihres Ursprungs in der Untersuchung von Sprache werden für die Verwendung dateiinhärenter Informationen diese ebenfalls in, für Maschinen lesbare, sprachliche Bausteine umgewandelt. Um die Ergebnisse und die Präzision der Algorithmen zu verbessern, sind zwei Optionen denkbar. Erstens die Verbesserung der sprachlichen Basis, indem eine Anpassung der Korpora hinsichtlich des ingenieur-fachsprachlichen Gebrauchs vorgenommen wird. Zweitens die derartige Modifizierung der Algorithmen, dass beispielsweise charakteristische Merkmale oder funktionale Flächen mit Hilfe eines abgewandelten „functional TF-IDF“ als Bibliotheken zur Verfügung stehen.

Über die unterschiedlichen Anwendungsabschnitte hinweg wurden lernende Algorithmen verwendet, die mitunter einen Lehrer benötigen. Beispielsweise um relevante Worte und Vokabular zu trainieren, die auf die Bedarfe des Maschinenbaus, der Produktdatenverwaltung und des betrachteten Produkts abgestimmt sind. Andere Trainingsprozesse beziehen sich beispielsweise auf das Erfassen historischer Daten und auf die Auswahl eines

149

5 Exemplarische Umsetzung relevanter Bedarfe

Vertrauenslevels der rückgemeldeten Wahrscheinlichkeit. Diese Aufwände sind im Verlauf der Arbeit manuell durchgeführt worden und werden nach aktueller Maßgabe auch zukünftig manuell getätigt. Dazu ist eine neue Rolle in Unternehmen zu etablieren, denn das Training von Algorithmen oder deren Abstimmung auf geänderte Randbedingungen erfordert Kenntnisse über die Funktionsweise der Algorithmen. Diese neue Rolle wird als Product Data Scientist bezeichnet.

Die Analyse von dateiinhärenter Information ist wesentlich aufwändiger, als die der Metainformationen zu den Dateien selbst. Erstens ist ein Zugang zu dem Dateiaufbau erforderlich, was beispielsweise hinsichtlich proprietärer CAD Formate nicht durchgängig gewährleistet ist. Zweitens ist ein Verständnis für den inneren Aufbau der Dateien erforderlich, um die enthaltenen Informationen zielgerichtet zu analysieren. Drittens sind die inhärenten Informationen mengenmäßig wesentlich größer und vielschichtiger, sodass Fehlinterpretation sehr viel einfacher geschehen.

Die Plausibilisierung der Produktdaten auf Basis der Metadaten, aber auch auf Basis der geometrischen Daten, ist technologisch in der aufgezeigten Form in konventionelle PDM Werkzeuge integrierbar. Damit kann eine Verbesserung der Datenqualität und damit ein gesteigertes Vertrauen in PDM Werkzeuge erzielt werden, wenn die konsequente Bearbeitung der Ergebnisse der Prüfliste beachtet wird.

Die Analyse der ermittelten Auffälligkeiten innerhalb der Produktdaten erfolgte im Rahmen der Versuche als direkte Rückgabe der Algorithmen. Besonders für die dateiinhärenten Informationen ist eine Rückübersetzung für Anwender, im Zuge einer Industrialisierung, erforderlich. Als Beispiel dient die Analyse geometrisch zusammengehörender Bauteile. Anwender könnten einen Hinweis erhalten, in dem identifizierte charakteristische Merkmale farblich in beiden betroffenen Geometrien markiert sind. Es ist nicht davon auszugehen, dass jeder Anwender die Kenntnisse eines Product Data Scientists erlangt.

Der Einfluss auf die methodische Vorgehensweise des InADM als Vorschlagssystem gilt insbesondere für die Verlinkung von Design Artefakten zu Ordnung gebenden Strukturen oder anderen Design Artefakten. Dabei ist es unerheblich, ob der Impuls aus der Search & Browse Umgebung oder den Autoren Werkzeugen erfolgt. Sowohl ein einfacher mit Lehrer lernender Algorithmus als auch ein aufwändiger, selbstlernender Algorithmus liefert eine Wahrscheinlichkeit zurück, mit der ein Design Artefakt mit einem anderen oder einem Ordnung gebenden Kriterium zu verlinken ist. Dabei ist es methodisch erforderlich, dass ein verantwortlicher Ingenieur, insbesondere bei steuernden Informationen, die Relation bestätigt. Dies kann am Beispiel der Exportkontrolle inhaltlich nachvollzogen werden.

150

6 Evaluierung des Konzepts

Dieses Kapitel untersucht, ob das InaDM Konzept und die Lösungsbausteine eine Ausgangsbasis schaffen, um Produktdaten effizienter zu verwalten. Dazu wird eine Expertenbefragung durchgeführt, die die neuen, gegenüber den konventionellen Tätigkeiten der Ingenieure sowie die methodisch verankerte Arbeitsteilung zwischen Ingenieur und Werkzeug mit Blick auf die Effizienz und Akzeptanz von PDM Werkzeugen beurteilt.

6.1 Aufbau der Expertenbefragung

Das Konzept, wie in Kapitel vier vorgestellt, wurde in Kapitel fünf durch relevante Bausteine in Forschungsdemonstratoren umgesetzt und erprobt. Das Gesamtkonzept wurde nicht als vollständige Lösung implementiert, die Bewertung gegenüber der initialen Forschungsfrage zur Reduktion des Aufwands erfolgt somit als quantitative Untersuchung. Die Abbildung 57 verdeutlicht die Abhängigkeiten zwischen den Untersuchungsgegenständen und den PDM Verwaltungsdimensionen, sowie den Zielrichtungen, die in der vorliegenden Arbeit untersucht wurden. Die Untersuchungsgegenstände und die Zielrichtung beziehen sich auf die Herleitung der Zielstellung der Arbeit in Abschnitt 1.2 (siehe Abbildung 2).

Abbildung 57: Aufbau und Umfang der Evaluierung des InADM Konzepts

Die Integration zwischen Autorenwerkzeug und Verwaltungsumgebung soll demnach möglichst hoch sein. Funktionen sollen auf die Bedarfe der Verwaltungsdimensionen zugeschnitten sein, insbesondere aber sollen sie nicht fehlen, um keinen zusätzlichen Aufwand zu verursachen. Folglich ist die Zielrichtung als steigend in der Abbildung 57 dargestellt. Das Kapitel eins geht davon aus, dass umfängliche Methoden und Vorschriften zur Bedienung eines Werkzeugs zu manuellen Fehlern und Aufwand führen, somit ist die

151

6 Evaluierung des Konzepts

Zielrichtung in der Abbildung 57 als sinkend dargestellt. Die Verwaltungsdimensionen A-C entstammen den Herleitungen des Kapitels zwei. Jede Verwaltungsdimension (siehe Abbildung 57, A-C) wird im Rahmen der Evaluierung individuell zu den drei Aspekten des Untersuchungsgegenstands sowie der Wirkrichtung 1-3 untersucht. Um eine relevante Einschätzung von Experten zu erhalten, ist es zunächst erforderlich, das erarbeitete Konzept sowie die partiellen Lösungen vorzustellen. Dies wurde mündlich, mit Hilfe der Abbildung 12 für das Konzept, insbesondere bezüglich der Funktionalität von Varianten mit Hilfe der Abbildung 18, hinsichtlich Bildung und Pflege von Gliederungen anhand der Abbildung 14 und Abbildung 15, vorgetragen. Die Funktionsweise für die Bildung von Relationen zur Vermeidung von Metadaten wurde anhand der Abbildung 5 und Abbildung 21 erläutert. In einem weiteren Schritt wurde die Funktionsweise der jeweiligen Demonstratoren vorgestellt. Die jeweils relevante Arbeitsweise wurde zusätzlich anhand der Abbildung 59 verdeutlicht. Es wird herausgearbeitet, welcher Teil der Anwendung im Hintergrund und welcher im Vordergrund verläuft. Um das Verständnis der Probanden abzusichern, bevor die eigentliche Befragung beginnt, wird ihnen die Möglichkeit eingeräumt, die vorgestellten Inhalte durch Fragen zu vertiefen. Dies bietet beispielsweise für IT-affine Teilnehmer die Möglichkeit, die hinterlegten Algorithmen zu verstehen oder die Arbeitsweise näher zu betrachten. Darüber hinaus wurden in den etwa 30-minütigen Gesprächen, die der eigentlichen Studie vorangestellt wurden, unternehmensinterne Fallbeispiele mit den Teilnehmern der Studie durchdacht. Die eigentliche Befragung erfolgt auf Basis der qualitativen Inhaltsanalyse von (Mayring 2010) für offene Fragestellungen, die diskutiert werden sollen und zusätzlich mit geschlossenen Fragebögen zur Bewertung der vorgestellten Lösung. Der entsprechende Interviewleitfaden findet sich im Anhang auf Seite VIII. Für ein evidentes, statistisch valides Ergebnis sind N=12 Teilnehmer erforderlich. Diese wurden aus großen Unternehmen der Branchen Automobilbau, Energieerzeugung sowie der Luftfahrt ausgewählt. PDM Werkzeuge werden häufig in großen Unternehmen eingesetzt, deshalb bringen Experten aus diesen Unternehmen ein gutes Einschätzungsvermögen und entsprechendes Hintergrundwissen mit. Das Aufgabengebiet der Teilnehmer erstreckt sich über Fachbereiche des Engineerings, der mechanischen Entwicklung, der Methodenentwicklung und der Produktdatenverwaltung. Alle Teilnehmer haben mindestens fünf Jahre Berufserfahrung im PDM Kontext. Die Befragung erfolgt in einem geführten Interview. Die eigentliche Bewertung erfolgt papierbasiert durch die Studienteilnehmer auf den bereitgestellten Bewertungsbögen. Der inhaltliche Aufbau folgt den, in Abbildung 57 dargestellten, Dimensionen Varianten, Metadaten und Produktgliederung sowie Fragestellungen zum allgemeinen Konzept. Die Befragung adressiert pro Verwaltungsdimension die erwartete Effizienz, die Funktionalität und

152

6 Evaluierung des Konzepts das methodische Vorgehen. Darüber hinaus werden die Parameter der Auswirkungsebene Akzeptanz und Datenqualität in den Interviews, entsprechend der zuvor beschriebenen Wirkrichtungen, mitbetrachtet. Darüber hinaus werden freie Kommentare erfasst und die Teilnehmer werden darum gebeten, etwaige Bedenken, beispielsweise zur Lücke der industriellen Praxis, zu äußern.

6.2 Ergebnisse der Befragung

Dieser Abschnitt stellt die Ergebnisse der Interviews und Befragungen, entsprechend dem in Abschnitt 6.1 vorgestellten Vorgehen, zusammen. Dieser Abschnitt schließt mit einer Bewertung der inhaltlichen Ergebnisse zum Forschungsgegenstand.

Variantenmanagement

Ein Großteil der 12 befragten Experten erwartet eine positive Auswirkung auf die Effizienz der Verwaltung von Varianten (siehe Abbildung 58). Die unzufrieden stellenden Rückmeldungen wurden durch die Probanden damit begründet, dass der kontinuierliche Aufwand für das Training von Algorithmen oder Adaptionen an diesen, aufgrund der dargestellten Inhalte, nicht klar absehbar für Unternehmen ist. Diese Fragestellung lässt sich zum Zeitpunkt der Erstellung dieser Arbeit nicht beurteilen, da eine Untersuchung zur mittelfristigen Nutzung des vollständigen InADM, einschließlich der Erprobung von größeren Produktänderungen während der Produktentwicklung, nicht untersucht wurde. Die Probanden beurteilten den Einfluss auf die Akzeptanz des vorgestellten Variantenmanagements als sehr gut oder gut (siehe Abbildung 59). Dies begründeten fünf Teilnehmer damit, dass Ingenieure in ihrer regulären Umgebung arbeiten können.

Abbildung 58: Effizienz des Variantenmanagements Abbildung 59: Akzeptanz des Variantenmanagements

60 % der Teilnehmer der Studie weisen gleichzeitig darauf hin, dass eine hohe Qualität des Chat Bots zu realisieren ist, damit die Akzeptanz nicht ins Gegenteil umschlägt. Zehn Teilnehmer der Befragung rechtfertigen über die Automatisierung der Kontroll- und

153

6 Evaluierung des Konzepts

Plausibilisierungsaufgaben und die damit zu erwartende Verbesserung der Datenqualität ihre Einschätzung zur Akzeptanz.

Der Großteil der Befragten (89 %) erwartet eine sehr gute bis gute Verbesserung der Datenqualität (siehe Abbildung 60). Dies wird auf die automatische Prüfung und Korrektur (Plausibilisierung) der Daten zurückgeführt, die unabhängig vom Anwender durchgeführt wird.

Der vorgestellte Funktionsumfang wurde von etwa der Hälfte der befragten Teilnehmer positiv bewertet, von der anderen Hälfte als durchschnittlich. Es wurde bemängelt, dass das Konzept nicht schlüssig auf die Verwendung von Material und Positionen, folglich auf Instanzen, eingehe. Als zusätzlichen Hinweis gaben einige Teilnehmer an, im Funktionsumfang die Verwaltung von Baugruppen zu vermissen. Es konnte im Gespräch analysiert werden, dass das in Einklang mit dem Konzept steht.

Abbildung 60: Einfluss auf die Datenqualität Abbildung 61: Bewertung des Funktionsumfangs

Metadaten

Die Effizienz der Verwaltung von Metadaten wurde durch die Teilnehmer der Evaluierung als grundsätzlich gegeben erachtet (siehe Abbildung 62). Dabei geben einige Teilnehmer zu bedenken, dass die Bewertung, ohne die entsprechende Nutzeroberfläche der Browse und Search Umgebung, schwerfällt. Es wird positiv bewertet, dass eine Unterstützung der

154

6 Evaluierung des Konzepts

Anwender anvisiert ist, weshalb die Mehrheit der Probanden eine gute bis sehr gute Akzeptanz beim Anwender erwartet (siehe Abbildung 63).

Abbildung 62: Effizienz der Metadatenverwaltung Abbildung 63: Akzeptanz der Metadatenverwaltung

Die Probanden gehen darüber hinaus davon aus, dass die Erstellung von Referenzen, anstelle von Metadaten, in der industriellen Praxis umsetzbar ist. Die methodische Vorgehensweise erscheint den Probanden zu 75 % sinnvoll (siehe Abbildung 64). Die zu verwendenden Funktionen erscheinen den Experten in größerer Mehrheit ebenso nachvollziehbar (siehe Abbildung 65). Im Bereich der Funktionen wurde bemängelt, dass der Aufwand für das Erstellen von Ontologien und die Modifikation der hinterlegten Algorithmen nicht eindeutig erfassbar ist.

Abbildung 64: Methoden für Metadaten Abbildung 65: Funktionen für Metadaten

Insgesamt wird zudem für den Bereich der Metadaten eine Verbesserung der Datenqualität erwartet, dies wird von 45 % der Teilnehmer mit einem „sehr gut“ bewertet. Als Begründung wird benannt, dass durch die aktuelle manuelle Bedienung sehr viele Fehler in PDM Werkzeuge eingetragen werden. Einige Teilnehmer konstatieren, dass selbst ohne vollständige Prüfung der Vorschläge durch einen Anwender eine Verbesserung erzielt werden kann.

155

6 Evaluierung des Konzepts

Gliederungen

Die Akzeptanz der dargestellten Lösung für Produktgliederungen wird durch die Experten teilweise als „gut“ und als „sehr gut“, teilweise als „befriedigend“ oder als „ausreichend“ bewertet (siehe Abbildung 66). Bei den kritischen Kommentaren zu dieser Lösung wird weniger die Verwendbarkeit des Werkzeugs an sich bemängelt, sondern vielmehr der Gedanke daran, ohne hierarchische Strukturierungen zu arbeiten. Die Mehrheit der Befragten bestätigt jedoch, dass die aktuelle Vorgehensweise zur Strukturierung mit einer großen hierarchischen Struktur sehr aufwändig ist. Im Bereich der Produktstrukturierung wird der vorgestellten Lösung zugetraut, eine Verbesserung der Effizienz der Bearbeitung zu erreichen (siehe Abbildung 67). Dies wird mit der zugrundeliegenden automatischen Plausibilisierung begründet, die sich einige Experten explizit auch für diesen Teil der Produktdaten wünschen.

Abbildung 66: Akzeptanz der Gliederung Abbildung 67: Effizienz der Produktstrukturierung

Die Studienteilnehmer bestätigen das methodische Vorgehen, mehrere Strukturen anstelle einer großen zu etablieren und lediglich „gehört-zu“ Verbindungen zu verwenden (siehe Abbildung 68). Mit Blick auf die Methoden wird durch einen Probanden ergänzt, dass die Gliederungen insbesondere für Personen im Unternehmen relevant sind, die sich einen Überblick über das gesamte Produkt verschaffen müssen. Deshalb ist insbesondere die datenkonsumierende Seite in der Search & Browse Umgebung methodisch stärker zu hinterlegen.

Der vorgestellte Funktionsumfang zur Erstellung von Gliederungen wird positiv bewertet (siehe Abbildung 69). Ein Teilnehmer wünscht sich, analog zum Variantenmanagement, einen Chat Bot, mit dem ein Nutzer bei der Speicherung der Daten zusätzlich seine Hintergrund-

156

6 Evaluierung des Konzepts informationen zur Verwendung im Kontext eingeben kann. Dieser sollte den Verlinkungs- vorschlag inkludieren.

Abbildung 68: Methoden der Produktgliederung Abbildung 69: Funktionen der Produktgliederung

Ebenso wie im Bereich der Metadaten wird für Produktgliederungen eine Verbesserung der Datenqualität durch etwa 80 % der Befragten erwartet, wiederholt mit der Begründung, dass die Automatisierung und Plausibilisierung eine wesentliche Unterstützung dazu bietet.

Konzept

Die zu erwartende Korrektur, die durch die Prüflisten des InADM ausgelöst wird, erfordert Disziplin im Unternehmen. Es wird von zwei Befragten aus dem Automobilumfeld angenommen, dass die Ingenieure die Aufgabe der Korrektur nicht wahrnehmen. Sie sehen die Aufgabe in der Produktdatenverwaltung verortet. Jedoch werten sie auch für diesen Bereich die vorgeschlagenen Vorkehrungen als Unterstützung und Beitrag zur Effizienz, denn aktuell werden die Datensätze manuell, beispielsweise auf Basis von Excel Suchvorgängen durchgeführt.

Es ist im Rahmen der bisherigen Umsetzung nicht vollständig nachvollziehbar, ob durch die zusätzlichen verwaltungstechnischen Aufgaben, wie das Trainieren lernender Algorithmen oder der Etablierung von Ontologien, der Aufwand für ein Unternehmen insgesamt reduziert werden kann. Der Aufwand beim anwendenden Ingenieur wird allerdings als vermindert anzunehmen bestätigt. Damit wird auch die Akzeptanz von PDM Werkzeugen als verbessert eingeschätzt.

Es wird von 70 % der Befragten erwartet, dass sich die Aufwände für Datenersteller reduzieren. Einige Teilnehmer aus dem Umfeld der Automobilindustrie können sich vorstellen, auf die Rolle des Datenmanagers zu verzichten. Jedoch scheint es eine neue Rolle zu geben, einen Product Data Scientist, der Algorithmen in einer Low Code Umgebung manipuliert und

157

6 Evaluierung des Konzepts wartet. Dieser soll als Anwender in der Ebene des Administrators das Verhalten des Werkzeugs einstellen und bei Bedarf modifizieren.

Als genereller Hinweis zu der Befragung wurde zurückgegeben, dass es ein rollenabhängiges Optimum zwischen zu wenigen und zu vielen Funktionen gebe. Dies ist einsehbar für die Nutzung der Search & Browse Umgebung. Ein Ingenieur, der ein bestimmtes Design Artefakt für eine festgelegte Variante weiterentwickeln und mit anderen Varianten vergleichen will, setzt und manipuliert mehrere Filter. Wohingegen jemand, der eine Reparatur für ein bestimmtes Design Artefakt koordinieren soll, neben der Varianz auch einen Umfang der Gliederung filtert, beispielsweise um zu eruieren, ob ein Bauteil separat ausgetauscht werden kann. Für eine industrielle Anwendung ist somit, entsprechend der Betrachtung von Sichten, eine einfache Adaptionsmöglichkeit der Filtereinstellungen in der Search & Browse Umgebung durch den Anwender erforderlich.

Fazit:

Insgesamt bestätigen die befragten Experten das vorgestellte InADM Konzept. Im Rahmen der Studie wurde deutlich, dass mit den technologischen Ideen die Datenqualität in PDM Werkzeugen gesteigert werden kann. Die Experten können sich vorstellen, diese Option, losgelöst vom InADM Konzept, ebenso für konventionelle PDM Werkzeuge zu verwenden. Über die in Abbildung 1 auf Seite 3 dargestellte Wirkkette konnte gezeigt werden, dass in Folge zudem die Akzeptanz von PDM Werkzeugen steigt.

Weiterhin bestätigen die Teilnehmer, dass das InADM Konzept die vorgestellten Methoden und Technologien zunächst schlüssig miteinander zu verwenden sind. Einige Fragestellungen, wie beispielsweise bezüglich des Umgangs mit Instanzen von CAD Modellen oder bezüglich des Umgangs mit Software-Quellcode als Design Artefakt werden durch das Konzept nicht schlüssig beantwortet und sind durch die Experten als Lücken im Konzept identifiziert worden.

Über die unterschiedlichen technologischen Entwicklungen hinaus beurteilten die Befragten, dass sich eine Erleichterung in Bezug auf den Arbeitsaufwand für Ingenieure und Daten generierende Anwender ergibt. Damit konnte zusätzlich die praktische Zielstellung des Untersuchungsgegenstands, der Steigerung der Effizienz durch mehr Automatisierung, gezeigt werden. Insbesondere im Bereich der automatischen und semantischen Verlinkung, die mit einer Plausibilisierung kombiniert ist, erwarten die Studienteilnehmer eine Verminderung des Aufwands.

158

7 Weiterer Forschungs- und Handlungsbedarf

Die vorstehenden Abschnitte haben gezeigt, dass das Konzept und seine Umsetzung einen grundsätzlich industriell tauglichen Beitrag zur Akzeptanz und Effizienz von PDM Werkzeugen leisten können. Während der Konzeption und praktischen Umsetzung wurden Aspekte deutlich, die das InADM in Richtung der praktischen Anwendung weiterentwickeln. Der Abschnitt 7.1 fasst diese Entwicklungspotentiale zusammen. Der Abschnitt 7.2 überträgt die erzielten Ergebnisse in den Forschungskontext des erweiterten Produktdatenmanagements.

7.1 Entwicklungspotentiale

Dieser Abschnitt betrachtet die technologischen und methodischen Entwicklungspotentiale des InADM Konzepts auf Basis der Testergebnisse und Befragungserkenntnisse.

Die vorliegende Arbeit fokussiert sich auf die Erstellung von Daten und die Datenbereitstellung aus der Sicht von Ingenieuren sowie auf die operativen Tätigkeiten der Produktdatenverwaltung. Um das Konzept als Ganzes validieren zu können, ist es erforderlich, die Search & Browse Umgebung einschließlich des skizzierten Enterprise Search zu implementieren. Technologisch ist bei einer solchen Umsetzung darauf zu achten, dass mehr als eine Datenbank durchsuchbar gemacht wird, wie beispielsweise in den Ausführungen von (Zeeshan und Gerhard 2008, S. 2–3) oder (Bunzel 2013, S. 44) aufgezeigt. Methodisch ist das Zusammenspiel von datenkonsumierenden und datenerstellenden Tätigkeiten neu zu bewerten. Beispielsweise für den Fall, dass sich ein Ingenieur über bestehende Daten informieren möchte, bevor er mit den Konstruktionsaufgaben beginnt. Welcher Umgebung unterstützt ihn dabei bestmöglich?

Das InADM Konzept wurde durch fünf technologische Untersuchungen grundlegend untermauert. Die vollständige Umsetzung aller Funktionen, die im Abschnitt 4.2.2 herausgearbeitet wurden, führt die Forschungsarbeiten logisch fort. Durch eine solche Umsetzung sind die, in dieser Arbeit getroffenen, Festlegungen der zukünftigen Aufgabenteilung nachzuweisen. Die neu eingeführte Rolle des Product Data Scientists bringt bisher unbekannte Aufgaben mit sich. Eine Reduktion des Aufwands wird bei den Aufgaben des datenerstellenden Ingenieurs und dem Datenmanager erwartet. Die gesamt- technologische Umsetzung des Konzepts bietet die Möglichkeit, die sich vollständig ergebende Aufwandsabschätzung im Vergleich zum konventionellen Vorgehen zu erproben. Dabei ist bei der Durchführung an einem industriell skalierten Anwendungsfall darauf zu

159

7 Weiterer Forschungs- und Handlungsbedarf achten, welche Voreinstellungen und Trainingsvorgänge, relativ zum Effizienzgewinn des datenerstellenden Anwenders und des Dokumenten Managers, zu leisten sind.

Die deskriptive Umfrage in Abschnitt 6 zeigt, dass eine Kombination aus automatischer Zuweisung und Verwendung der dateiinhärenten Informationen sowie der durch den Datenersteller mitgegebenen in Summe für alle Datenverwaltungsvorgänge verwendet werden soll. Die Zusammenführung der aufgezeigten technologischen Möglichkeiten für die Datenerstellung ist in Abbildung 70 dargestellt. Um eine solche Kombination der Technologien praktisch umzusetzen, ist es zunächst erforderlich, den Chat Bot derart zu trainieren, dass er neben dem Variantenmanagement ebenso die anderen Vorgänge der Produktdatenverwaltung versteht und diese sprachlich voneinander unterscheiden kann. Weiterhin erfolgt, parallel zur Analyse des vom Anwender eingegebenen Textes, die automatische Zuweisung sowohl zu Ordnung gebenden Gliederungselementen als auch zu Varianten. Die Abbildung 70 zeigt dieses Vorgehen mit den orangenen Pfeilen „Vorschlag ermitteln“ und „Vorschlag übermitteln“. Die Bestätigung durch den Anwender wird durch das InaDM Konzept aufgrund der Verantwortung des Datenerstellers für die spätere Verwendung der Daten vorgesehen und folgend auch durch die Industrieexperten bestätigt.

Abbildung 70: Kombination der InADM Technologien

Unregelmäßigkeiten, die durch die Algorithmen ermittelt und der Prüfliste zugeführt werden, werden entsprechen dem InADM Konzept durch einen Anwender geprüft und ggf. modifiziert. Ein Rückschluss auf die Funktionsweise des Algorithmus und die Korrektheit der Plausibilisierung erfolgt somit im aktuellen Konzept nicht. Es wäre allerdings durchaus denkbar, die Definition von Klassen automatisch zu beurteilen und zu manipulieren.

160

7 Weiterer Forschungs- und Handlungsbedarf

Die Vorgehensweise zur Bildung von Sichten wurde als einfach eingestuft, wenn die Anwender sie selbst konfigurieren (siehe Abschnitt 3.2). Damit wurde die Forschungstätigkeit im Rahmen dieser Arbeit unterbrochen. Es bleibt jedoch offen, ob alternativ ein standardisiertes Vorgehen zu Bildung von Sichten denkbar wäre. Auf diese Weise könnte eine permanent ähnliche Schnittstelle direkt an den Nutzer herangetragen werden.

Weitere Forschungsarbeit am InADM Konzept liegt in einem vergleichenden Experiment zur Ergebnisqualität der Datenverwaltung, wenn Daten manuell mit einem konventionellen PDM Werkzeug oder automatisch mit dem InADM verwaltet werden.

Bei der Betrachtung der Methoden untersucht das InADM Konzept zunächst die Arbeitsteilung zwischen Anwender und Maschine und zeigt eine Verschiebung der Tätigkeiten zugunsten der Entlastung des Menschen auf. Aufwändigere Methoden, wie beispielsweise zur Bildung von Modulen oder zur Vermeidung von Variantenkomplexität wurden in konventionellen und gegenwärtig ebenso im InADM Konzept außerhalb der Verwendung von PDM Werkzeugen durchgeführt. Die Bedienkomplexität wird durch das InADM Konzept reduziert, insbesondere im Bereich des Variantenmanagements.

Die Manipulation und Konfigurationslogik sowie die Gesamtheit der Ordnung gebenden Strukturen wurden im Konzept methodisch, unter Versionskontrolle, festgelegt. Der sich ergebende Verwaltungsaufwand, insbesondere bei Änderungen, wurde in die Betrachtungen bislang nicht vollumfänglich fakturiert.

Einflüsse unterschiedlicher Produktarten oder Einflüsse der Branchen wurden für das InADM Konzept nicht näher betrachtet. Methodische Vorgehensweisen, wie für Build-to-order, Configure-to-order und Engineer-to-order Konfigurationen, sind am Konzept zu spiegeln. Build-to-order Konfigurationen gehen davon aus, dass einmalig ein Konfigurationskonzept festgelegt wird und dieses folgend im Verlauf der Bestellung verwendet wird. Dieses Vorgehen ist aus der Sicht von PDM Werkzeugen einfach, da Änderungen während der Datenerstellung und der Nutzung nicht vorgesehen sind. Eine Implementierung und Erhebung ist erforderlich, um den Gesamtnutzen des InADM abschließend zu bewerten.

7.2 Verortung im Forschungsfeld

Gegenüber dem aktuellen Stand der Forschung und praktischen Umsetzung wurde eine Möglichkeit aufgezeigt, PDM Werkzeuge mit einem Automatismus zum Plausibilisieren der Metadaten zu versehen und bestehende Mechanismen zum Plausibilisieren von geometrischen Daten zu erweitern. Dies beantwortet Anforderungen der Praxis (siehe (Tiedeken et al. 2013, S. 144)) für den Bereich der E/E Datenverwaltung im Bereich der Automobilindustrie.

161

7 Weiterer Forschungs- und Handlungsbedarf

Die vorliegende Arbeit leistet einen Beitrag zur Anwendung des automatischen Zuweisens von konventionellen Produktdaten und zeigt damit eine Lösung auf, um Datenverwaltungsvorgänge zu automatisieren. Manuelle, administrative Tätigkeiten der Zuweisung zu Gliederungselementen oder Varianten entfallen damit im InADM Konzept. Es ist keine Nutzeroberfläche für die Datenverwaltung erforderlich. Die Rolle eines Datenverwalters oder Dokumentenverwalters, wie sie von (Stark 2018, S. 17–18) beschrieben wird, ist somit nicht länger erforderlich. Die Überlegungen zum InADM sowie die Industriebefragung zur Verwendung des Konzepts in Abschnitt 6.2 zeigen, dass zukünftig ein neues Kompetenzprofil des Product Data Scientists erforderlich ist.

Grundlage dieser Arbeit bildet das historische Verständnis von PDM Werkzeugen, die vorwiegend zur Verwaltung mechanischer Produktdaten verwendet werden. Weiterer Forschungsbedarf ergibt sich aus der Integration konventioneller Vorgehensweisen der Software und der Elektrotechnik und Elektronik. Eine grundlegende Untersuchung, analog zu Kapitel zwei, sollte etwaige Unterschiede und Gemeinsamkeiten in den Bedarfen der Datenverwaltung von Ingenieuren der unterschiedlichen Domänen präzisieren. Bestehende Arbeiten zur Integration von ALM und PLM Werkzeugen wie beispielsweise von (Deuter et al. 2019) tragen bereits Anforderungen und Lösungsideen zusammen. Die Arbeiten zeigen, dass es gewisse Synchronisationspunkte im PEP zum Mapping von Software Baselines mit den zugehörigen Hardware Versionen gibt.

Der sich abzeichnende Bedarf der Verwaltung von Sensordaten ist eine junge Disziplin, deren Datenverwaltung selbst aktuell noch Gegenstand der Forschung ist. Es bleibt näher zu betrachten, in welcher Form die Verwaltung der Sensordaten kongruent mit denen des Produkts zu organisieren ist. Einige Aspekte der Datenverwaltung werden schnell verständlich, die klare Identifikation von Daten oder Datensets ist hingegen erforderlich. Weiterhin erscheint eine Versionierung oder ein Status nicht gewinnbringend oder realisierbar für einzelne Daten zu sein. Es kann jedoch sehr sinnvoll sein, eine wiederauffindbare Zuordnung der einzelnen oder aggregierten Daten zu Varianten oder Produkten, im Rahmen der Datenverwaltung, bereitzustellen. Analog zu dem vorgeschlagenen Konzept von Deuter für die Zuordnung von Software zu Hardware, sollte zukünftig zudem eine Zuordnung von Sensordaten zu zugehörigen Produkten, Produktvarianten oder auch bestimmten Design Artefakten ermöglicht werden. Die Abbildung 71 zeigt die unterschiedlichen Entstehungsgeschwindigkeiten von Hardware Daten, Software Code sowie Daten von Sensoren und Aktoren in den drei übereinander angeordneten Datenflüssen. Die Integrationspunkte stellen an dieser Stelle Zeitpunkte dar, an denen die unterschiedlichen Daten miteinander in Verbindung gebracht werden.

162

7 Weiterer Forschungs- und Handlungsbedarf

Abbildung 71: Integration von Hardware, Software und Daten

Entsprechend dem InADM Konzept soll die Verlinkung von Daten zukünftig automatisch erfolgen. Dies kann ebenso in dem in Abbildung 71 skizzierten erweiterten Kontext automatisch erfolgen. Metadaten stehen in allen drei Dimensionen der Daten zur Verfügung. Die vorgestellten Mechanismen der Klassifizierung und Zuweisung aus Abschnitt 5.1 gelten für schnell und langsam erzeugte Daten gleichermaßen.

Die experimentelle Umsetzung des Chat Bots in Abschnitt 5.2.1 beruht auf der Verwendung der natürlichen Sprachverarbeitung, die wiederum Mechanismen des Maschinellen Lernens bemüht. Es konnte durch die Implementierung gezeigt werden, dass sich die bestehenden Algorithmen grundsätzlich für eine Anwendung im Ingenieurskontext eignen. Jedoch bleiben in der Anwendung Fehler zurück, die darauf zurückzuführen sind, dass das NLP nicht für Ingenieursanwendungen erstellt wurde. Eine weitere Entwicklung des Stands der Forschung besteht demnach in der Bildung eines Wortschatzes für die Ingenieurswissenschaften und die Produktdatenverwaltung.

163

Literaturverzeichnis

8 Literaturverzeichnis

Abramovici, Michael (2016): Semantic data management for the development and continuous reconfiguration of smart products and systems. Unter Mitarbeit von Jens Christian Göbel und Hoang Bao Dang. In: CIRP Annals 2016, Bd. 65, S. 185–188.

Abramovici, Michael; Aidi, Youssef (2013): Next Generation Product Lifecycle Management (PLM). In: Madjid Fathi (Hg.): Integration of Practice-Oriented Knowledge Technology: Trends and Prospectives. Berlin, Heidelberg: Springer Berlin Heidelberg, S. 143–156. Online verfügbar unter https://doi.org/10.1007/978-3-642-34471-8_12.

Adhvaryu, Nidhi; Balani, Prem (2015): Survey: Part-of-speech tagging in nlp. In: International Journal of Research in Advent Technology (E-ISSN: 2321-9637) 1980.

Adolphy, Sebastian (2015): Method for Automated Structuring of Product Data and its Applications. Unter Mitarbeit von Hendrik Grosser, Lucas Kirsch und Rainer Stark. In: Procedia CIRP 2015, Bd. 38, S. 153–158.

Aßfalg, Johannes (2005): Accurate and efficient similarity search on 3d objects using point sampling, redundancy, and proportionality. Unter Mitarbeit von Hans-Peter Kriegel, Peer Kroeger und Marco Poetke. In: C. Bauzer Medeiros (Hg.): International Symposium on Spatial and Temporal Databases. Heidelberg, Berlin: Springer, S. 200–217.

Assfalg, Rolf (2013): B 2 Metadaten. In: Rainer Kuhlen, Wolfgang Semar und Dietmar Strauch (Hg.): Grundlagen der praktischen Information und Dokumentation. Berlin, Boston: de Gruyter Saur, S. 159–171.

ASV - Automatische Sprachverarbeitung Leipzig (1998): corpora. Unter Mitarbeit von Projekt Wortschatz. Hg. v. Universität Leipzig, Institut für Informatik, Abteilung Automatische Sprachverarbeitung. Online verfügbar unter https://corpora.uni- leipzig.de/de?corpusId=deu_newscrawl-public_2018, zuletzt aktualisiert am 2020, zuletzt geprüft am 29.05.2020.

Bangor, Aaron (2008): An Empirical Evaluation of the System Usability Scale. In: International Journal of Human-Computer Interaction 24 (6), S. 574–594.

Baroni, Marco; Bernadini, Sylvia (2004): BootCaT: Bootstrapping Corpora and Terms from the Web. In: International conference on Language Resources and Evaluation (LREC), S. 1313–1317.

Baumberger, Georg Christoph (2007): Methoden zur kundenspezifischen Produktdefinition bei individualisierten Produkten. Dissertation. Technische Universität München, München. Online verfügbar unter http://mediatum.ub.tum.de/doc/627396/document.pdf.

164

Literaturverzeichnis

Beitz, Wolfgang; Küttner, Karl-Heinz (Hg.) (1987): Dubbel. Taschenbuch für den Maschinenbau. 16., korrigierte und ergänzte Auflage. Berlin, Heidelberg, s.l.: Springer Berlin Heidelberg. Online verfügbar unter http://dx.doi.org/10.1007/978-3-662-06778-9.

Białecki, Andrej (2012): Apache Lucene 4. Unter Mitarbeit von Robert Muir und Grant Ingersoll. In: Andrew Torman (Hg.): Proceedings of the SIGIR 20102 Workshop on Open Source Information Retrieval. Unter Mitarbeit von Charles Clark, Iadh Ounis, Shane Culpepper, Marc-Allen Cartright und Shlomo Geva. SIGIR 2012 workshop on open source information retrieval. Portland, Oregon, S. 17–24.

Blees, Christoph (2011): Eine Methode zur Entwicklung modularer Produktfamilien. Dissertation. Technische Universität Hamburg-Harburg, Hamburg.

Blessing, Lucienne T.M.; Chakrabarti, Amaresh (2009): DRM, a Design Research Methodology. London: Springer London.

Boma R. Koko, Hugh Stewart (1993): Product structure management. Veröffentlichungsnr: US5434791A.

Brière-Côté, Antoine (2010): Adaptive generic product structure modelling for design reuse in engineer-to-order products. In: Computers in Industry 61 (1), S. 53–65.

Brook, James (1996): SUS: a ´quick and dirty´ usability scale. In: P. W. Jordan, B. Thomas, B. A. Weerdemester und McClelland I.L. (Hg.): Usability Evaluation in Industry. London: Taylor and Francis, S. 189–194.

Bunzel, Stefanie (2013): Ontology- and Function-Based Technology Model for Decision Making in New Product Development. Unter Mitarbeit von Joachim Warschat, Dieter Spath und Antonino Ardilio. In: Dilek Cetindamar, Tugrul Daim, Berna Beyhan und Nuri Basoglu (Hg.): Strategic Planning Decisions in the High Tech Industry. London: Springer London, S. 35–51.

Carstensen, Kai-Uwe (2010): Computerlinguistik und Sprachtechnologie. Eine Einführung. Unter Mitarbeit von Christian Ebert, Cornelia Ebert, Susanne Jekat, Ralf Klabunde und Hagen Langer. 3. überarbeitet und erweiterte Auflage. Heidelberg: Spektrum Akademischer Verlag (Spektrum Lehrbuch).

Standard SAE ANSI/EIA649C, 2019: Configuration Management Standard.

Cutting, Douglas (2011): Apache Lucene. Hg. v. The Apache Software Foundation. The Apache Software Foundation. Online verfügbar unter https://lucene.apache.org/, zuletzt geprüft am 05.06.2020.

165

Literaturverzeichnis

Cutting, Douglass (1992): A Practical Part-of-Speech Tagger. Unter Mitarbeit von Julian Kupiec, Jan Pedersen und Penelope Sibun. In: Third Conference on Applied Natural Language Processing, S. 133–140.

Damerau, Fred J. (1964): A technique for computer detection and correction of spelling errors. In: Communications of the ACM 7 (3), S. 171–176.

Dekhtiar, Jonathan (2018): Deep learning for big data applications in CAD and PLM– Research review, opportunities and case study. In: Computers in Industry 100, S. 227–243.

Dengel, Andreas (Hg.) (2012): Semantische Technologien. Grundlagen - Konzepte - Anwendungen. Heidelberg: Spektrum Akademischer Verlag.

Deuter, Andreas; Otte, Andreas; Ebert, Marcel; Possel-Dölken, Frank (2019): Developing the Requirements of a PLM/ALM Integration: An Industrial Case Study. In: Product Lifecycle Management (Volume 4): The Case Studies: Springer, S. 125–143.

ISO 14739-1:2014, 2014: Document Management.

Dreßler, Martin (2015): Entwicklung von Mock-ups der Benutzerschnittstelle eine Produktkonfigurators mit integrierter Baubarkeitsprüfung. Masterarbeit. Technische Universität Berlin, Berlin. Institut für Werkzeugmaschinen und Fabrikbetrieb.

Eigner, Martin; Koch, Walter; Muggeo, Christian (Hg.) (2017): Modellbasierter Entwicklungsprozess cybertronischer Systeme. Berlin, Heidelberg: Springer Berlin Heidelberg.

Eigner, Martin; Stelzer, Ralph (2013): Product Lifecycle Management. Ein Leitfaden für Product Development und Life Cycle Management. 2. neu bearbeitete Auflage. Dordrecht: Springer (VDI).

Eisenstein, Jacob (2019): Introduction to natural language processing. London: The MIT Press.

Elgh, Fredrik; Cederfeldt, Mikael (2010): Documentation and Management of Product Knowledge in a System for Automated Variant Design: A Case Study. In: Jerzy Pokojski, Shuichi Fukuda und Józef Salwiński (Hg.): New World Situation: New Directions in Concurrent Engineering. London: Springer London, S. 237–245.

Emery, David; Hilliard, Rich (2009): Every architecture description needs a framework: Expressing architecture frameworks using ISO/IEC 42010. In: 2009 Joint Working IEEE/IFIP Conference, S. 31–40.

Emmery, Chris (2018): pattern. Unter Mitarbeit von Enrique Manjavaica, Giovanni Cassini und Guy De Pauw. Hg. v. Computational Linguistics Research Group. University of

166

Literaturverzeichnis

Antwerpen. Antwerpen. Online verfügbar unter https://www.clips.uantwerpen.be; https://github.com/clips/pattern/wiki.

Ertel, Wolfgang (2016): Grundkurs Künstliche Intelligenz. Wiesbaden: Springer.

Euzenat, Jérôme; Shvaiko, Pavel (2007): Ontology matching. Berlin, Heidelberg: Springer- Verlag Berlin Heidelberg.

Falbe, Max (2020): Verwendung von Hashfunktionen für die Versionskontrolle für CAD Werkzeuge. Technische Hochschule Berlin, Berlin. Fachgebiet Industrielle Informationstechnik.

Feldhusen, Jörg; Grote, Karl-Heinrich (2013): Der Produktentstehungsprozess (PEP). In: Jörg Feldhusen und Karl-Heinrich Grote (Hg.): Pahl/Beitz Konstruktionslehre, Bd. 75. Berlin, Heidelberg: Springer Berlin Heidelberg, S. 11–24.

Fresemann, Carina; Bittcher, Lars (2020a): Statistical check of meta data. Online verfügbar unter http://dx.doi.org/10.14279/depositonce-10371.

Fresemann, Carina; Bittcher, Lars (2020b): SW-Code for plausible GeometricData. Online verfügbar unter http://dx.doi.org/10.14279/depositonce-10369.

Fresemann, Carina; Bittcher, Lars (2020c): SW-Code_I for semantic data linking.

Fresemann, Carina; Göksel, Christian (2020): SW-Code_II for semantic data linking. Online verfügbar unter https://depositonce.tu-berlin.de/handle/11303/11519.

Fresemann, Carina; Ioannou, Spyridon-Timos (2020): Chat Bot for variant management. Online verfügbar unter http://dx.doi.org/10.14279/depositonce-10370.

Garwood, Dave (2000): Bills of Material: Structured for Excellence. 5. Aufl.: Dogwood.

Gerhard, Detlef (2016): Daten-und Informationsmanagement PDM/PLM. In: Udo Lindemann (Hg.): Handbuch Produktentwicklung. München: Hanser, S. 215–245.

Glauche, Marc (2015): Methode zur Entwicklung handlungsbefähigender Produktstrukturen. Dissertation. Technische Universität Clausthal, Clausthal.

Gogineni, Sonika (2019): Semantic Assistance System for Providing Smart Services and Reasoning in Aero-Engine Manufacturing. Unter Mitarbeit von Konrad Exner, Rainer Stark, Jonas Nickel, Marjan Oeler und Heiko Witte. In: Emmanouel Garoufallou, Francesca Fallucchi und Ernesto William de Luca (Hg.): Metadata and Semantic Research. 13th International Conference, MTSR 2019, Rome, Italy, October 28–31, 2019, Revised Selected Papers, S. 90–102.

Han, Jiawei; Pei, Jian; Kamber, Micheline (2011): DATA MINING: Concepts and Techniques: Elsevier (The Morgan Kaufmann Series in Data Management Systems).

167

Literaturverzeichnis

Han, Kwan Hee; Do, Namchul (2006): An object-oriented conceptual model of a collaborative product development management (CPDM) system. In: The International Journal of Advanced Manufacturing Technology 28 (7-8), S. 827–838.

Hawking, David: Challenges in Enterprise Search. In: Australasian Database Conference 2004, Bd. 4, S. 15–24.

Hellerstein, Joseph M. (2008): Quantitative data cleaning for large databases. In: United Nations Economic Commission for Europe (UNECE). Online verfügbar unter http://db.cs.berkeley.edu/jmh.

Herrmann, Jürgen (1997): Maschinelles Lernen und Wissensbasierte Systeme. Systematische Einführung mit praxisorientierten Fallstudien. Berlin, Heidelberg: Springer.

Hertwig, Michael; Lentes, Joachim (2019): Certification of Openness–Corner Stone of an Agile PLM Strategy. In: Procedia Manufacturing 39, S. 1383–1391.

Höltgen, Stefan (2019): Von der Sprachphilosophie zu ELIZA. In: Klaus Mainzer (Hg.): Philosophisches Handbuch Künstliche Intelligenz. Wiesbaden: Springer Fachmedien Wiesbaden, S. 1–22.

Honnibal, Matthew: spaCy. Unter Mitarbeit von Ines Montani, Justin DuJardin, Sofie van Langedhem, Sebastien Ramirez, Adriane Boyd, Walter Henry et al. Hg. v. Explosion AI. Berlin, Boston. Online verfügbar unter spacy.io.

Huang, M. Y.; Lin, Y. J.; Xu, Hu (2004): A framework for web-based product data management using J2EE. In: The International Journal of Advanced Manufacturing Technology 24 (11-12), S. 847–852.

ISO Standard 10303 -214, 2010: Industrial Automation Systems and Integration.

2219:2016, 2016-09: Informationsverarbeitung in der Produktentwicklung - Einführung und Betrieb von PDM-Systemen.

Ioannou, Spyridon-Timos (2020): Verwendung maschineller Textverarbeitung für das Variantenmanagement. Bachelorarbeit. Technische Universität Berlin, Berlin.

Kassner, Laura; Gröger, Christoph; Mitschang, Bernhard; Westkämper, Engelbert (2015): Product Life Cycle Analytics – Next Generation Data Analytics on Structured and Unstructured Data. In: Roberto Teti (Hg.): CIRP Conference on Intelligent Computation in Manufacturing Engineering, Bd. 33, S. 35–40.

Kehl, Stefan (2019): Marken- und domänenübergreifendes Management industrieller Produktdaten. Wiesbaden: Springer Fachmedien Wiesbaden.

168

Literaturverzeichnis

Kempen, Gerard (1998): Sentence Parsing. In: Angela D. Friederici (Hg.): Language Comprehension: A Biological Perspective, Bd. 18. Berlin, Heidelberg: Springer Berlin Heidelberg, S. 213–228.

Kukich, Karen (1992): Techniques for automatically correcting words in text. In: Muntz, Richard, M. (Hg.): Computing Surveys, Bd. 24. New York, New York, USA, S. 377–439.

Lachowitz, Dominik (1998): Enchant. Unter Mitarbeit von Reuben Thomas. Hg. v. AbiSource community.

Lauber, Rudolf (Hg.) (1976): Prozeßautomatisierung I: Aufbau und Programmierung von Prozeßrechensystemen. Berlin, Heidelberg: Springer Berlin Heidelberg.

Lutters, Eric (2014): Tools and techniques for product design. Unter Mitarbeit von Fred van Houten, Alain Bernard, Emmanuel Mermoz und Corne Schutte. In: CIRP Annals - Manufacturing Technology, 63 (2), 607-630.

Maurer, Markus; Gerdes, J. Christian; Lenz, Barbara; Winner, Hermann (2015): Autonomes Fahren. Berlin, Heidelberg: Springer Berlin Heidelberg.

Mayer, Felix; Pantförder, Dorothea (2014): Unterstützung des Menschen in Cyber-Physical- Production-Systems. In: Thomas Bauernhansl, Michael ten Hompel und Birgit Vogel-Heuser (Hg.): Industrie 4.0 in Produktion, Automatisierung und Logistik: Anwendung · Technologien · Migration. Wiesbaden: Springer Fachmedien Wiesbaden, S. 481–491.

Mayring, Philipp (2010): Qualitative Inhaltsanalyse. In: Günter Mey und Katja Mruck (Hg.): Handbuch qualitative Forschung in der Psychologie: Springer, S. 601–613.

Mesihovic, Samir; Malmqvist, Johan (2000): Product data management (PDM) system support for the engineering configuration process. In: 14th European Conference on Artificial Intelligence ECAI 2000. Configuration Workshop, S. 20–25.

MIL-HDBK 61, 07.04.2020: Military Handbook: Configuration Management Guidance.

Neumann, Frank; Abuosba, Mohammad (2016): Nutzung von 3D-PDF für die Ähnlichkeitssuche in Produktdaten-Management-Systemen. In: BWV Berliner Wissenschaftsverlag, S. 166–174.

Otto, Boris; Österle, Hubert (2016): Corporate Data Quality. Berlin, Heidelberg: Springer Berlin Heidelberg.

Pohl, Klaus; Böckle, Günter; van Der Linden, Frank J (2005): Software product line engineering: foundations, principles and techniques: Springer Science & Business Media.

169

Literaturverzeichnis

Pratt, Michael J. (2001): Introduction to ISO 10303—the STEP Standard for Product Data Exchange. In: Journal of Computing and Information Science in Engineering 1 (1), S. 102– 103.

Pro Step AG (2014): CPO Statement of OPN PDM. Hg. v. Pro Step AG. Online verfügbar unter https://www.prostep.com/en/products-and-solutions/code-of-plm-openness/, zuletzt geprüft am 12.06.2020.

Rich, Elaine (1983): Artificial Intelligence and the humanities. In: Computers and the Humanities 1985 (Vol. 19, No. 2), S. 117–122.

Rozga, Szymon (2018): Introduction to Chat Bots. In: Szymon Rozga (Hg.): Practical Bot Development. Berkeley, CA: Apress, S. 1–28.

Saenz, Julia (2017): The usability analysis of chatbot technologies for internal personnel communications. Unter Mitarbeit von Walkers Burgess, Elizabeth Gustities, Andres Mena und Farzan Sasangohar. In: Proceedings of the 2017th Industrial and Systems Engineering Conference, Bd. 2017, S. 1357–1362.

SASIG/ Pro Step (Hg.) (2009): Engineering Change Management Reference Process. covering VDA 4965 V3.0. SASIG- Strategic Automotive product data Standards Industry Group. Online verfügbar unter https://www.prostep.org/fileadmin/downloads/Whitepaper_ECM_Reference_Process_V2.0.3. pdf, zuletzt geprüft am 14.06.2019.

Sauer, Christopher; Schleich, Benjamin; Wartzack, Sandro (2019): Einsatz von Graphdatenbanken für das Produktdatenmanagement im Kontext von Industrie 4.0. In: Stelzer, Ralph H., Krzywinski, Jens (Hg.): Entwerfen Entwickeln Erleben in Produktentwicklung und Design.

Schäfer, Thorsten (2013): Semantische Suche in Wissensportalen: Konzeption und Evaluation der Erweiterung eines Suchframeworks um semantische Technologien. Hochschule Bonn-Rhein-Sieg.

Schreiber, Jan (2010): German Dictionary. A German word list for GNU Aspell. Hg. v. Source Forge. Online verfügbar unter https://sourceforge.net/projects/germandict/, zuletzt aktualisiert am 11.06.2020, zuletzt geprüft am 06/2020.

Standard FIPS Pub 180-1, 17.04.1995: Secure Hash Standard. Online verfügbar unter nvlpubs.nist.gov, zuletzt geprüft am 15.07.2020.

Sendler, Ulrich (2009): Das PLM-Kompendium: Referenzbuch des Produkt-Lebenszyklus- Managements. Berlin, Heidelberg: Springer (Xpert.press).

170

Literaturverzeichnis

Shah, Jami J.; Anderson, David; Kim, Yong Se; Joshi, Sanjay (2000): A Discourse on Geometric Feature Recognition From CAD Models. In: Journal of Computing and Information Science in Engineering 1 (1), S. 41–51.

Shilovitsky, Oleg (2017a): How PLM chatbots will change product documentation and customer service. Hg. v. beyondplm. Online verfügbar unter http://beyondplm.com/2017/12/14/plm-chatbots-will-change-product-documentation- customer-service.

Shilovitsky, Oleg (2017b): PLM and machine learning – how to find the right data. Hg. v. beyondplm. Online verfügbar unter http://beyondplm.com/2017/09/06/plm-machine-learning- find-right-data/, zuletzt aktualisiert am 06.09.2017, zuletzt geprüft am 06/2020.

Smiley, David; Pugh, Eric (2009): Solr 1.4 enterprise search server: Packt Publishing Ltd.

Smirnov, Alexander; Shilov, Nikolay; Oroszi, Andreas; Sinko, Mario; Krebs, Thorsten (2017): Changing Information Management in Product-Service System PLM: Customer-Oriented Strategy. In: José Ríos, Alain Bernard, Abdelaziz Bouras und Sebti Foufou (Hg.): Product Lifecycle Management and the Industry of the Future, Bd. 517. Cham: Springer International Publishing (IFIP Advances in Information and Communication Technology), S. 701–709.

Stark, John (2018): Product Lifecycle Management (Volume 3): The Executive Summary. Cham: Springer International Publishing.

Stiefel, Patrick (2011): Eine dezentrale Informations- und Kollaborationsarchitektur für die unternehmensübergreifende Produktentwicklung. Zugl.: Clausthal, Techn. Univ., Diss., 2010. 1. Aufl. Wiesbaden: Vieweg+Teubner Verlag / Springer Fachmedien Wiesbaden GmbH Wiesbaden. Online verfügbar unter http://dx.doi.org/10.1007/978-3-8348-8180-9.

Stone, Robert B.; Wood, Kristin L.; Crawford, Richard H. (2000): A heuristic method for identifying modules for product architectures. In: Design Studies 21 (1), S. 5–31.

DIN EN 62023:2012-08, 2012: Strukturierung technischer Information und Dokumentation.

Sünnetcioglu, Atakan; Brandenburg, Elisabeth; Rothenburg, Uwe; Stark, Rainer (2016): ModelTracer: User-friendly Traceability for the Development of Mechatronic Products. In: Procedia Technology 26, S. 365–373.

Swierstra, Wouter; Löh, Andres (2014): The Semantics of Version Control. In: Andrew Black, Shriram Krishnamurthi, Bernd Bruegge und Joseph N. Ruskiewicz (Hg.): Proceedings of the 2014 ACM International Symposium on New Ideas, New Paradigms, and Reflections on Programming & Software - Onward! '14. the 2014 ACM International Symposium. Portland, Oregon, USA, 20.10.2014 - 24.10.2014. New York, New York, USA: ACM Press, S. 43–54.

171

Literaturverzeichnis

Thiebes, Florian; Plankert, Nicole (2014): Umgang mit Komplexität in der Produktentwicklung–Komplexitätsbeherrschung durch Variantenmanagement. In: Komplexitätsmanagement in Unternehmen: Springer, S. 165–185.

Tiedeken, Julian; Herbst, Joachim; Reichert, Manfred (2013): Managing complex data for electrical/electronic components: challenges and requirements. In: Datenbanksysteme für Business, Technologie und Web (BTW) 2013-Workshopband, S. 141–150. van den Hamer, P.; Lepoeter, K. (1996): Managing design data: the five dimensions of CAD frameworks, configuration management, and product data management. In: Proceedings of IEEE 1996, 84 (1), S. 42–56.

Vielhaber, Michael; Burr, Holger; Deubel, Till; Weber, Christian; Haasis, Siegmar (2004): Assembly-oriented design in automotive engineering. In: Proceedings of Design 2004, DS 32, S. 539–546.

Vielhaber, Michael; Burr, Holger; Eigner, Martin (2006): Product Structuring for Cross-x PDM. In: Proceedings of DESIGN 2006, DS 36, S. 655–664.

Weber, Christian; Werner, Horst; Deubel, Till (2003): A different view on Product Data Management/Product Life-Cycle Management and its future potentials. In: Journal of Engineering Design 14 (4), S. 447–464.

Weber, Nadine (2011): Facettenbasierte Indexierung multipler Artefakte. Ein Framework für vage Anfragen in der Produktentwicklung. Dissertation, Bamberg.

Wickel, Martina Carolina (2017): Änderungen besser managen. Eine datenbasierte Methodik zur Analyse technischer Änderungen. Dissertation. Technische Universität München, München.

Woll, Robert (2018): Optimized Data Integration for Tracelinking in Product Development Through the Application of Semantic Web Technologies. Dissertation, Berlin.

Zagel, Mathias (2006): Übergreifendes Konzept zur Strukturierung variantenreicher Produkte und Vorgehensweise zur iterativen Produktstruktur-Optimierung. Dissertation, Kaiserslautern.

Zeeshan, Ahmed; Gerhard, Detlef (2008): Design Implementation of Semantic Oriented Agent and Knowledge based approach for Intelligent Human Machine Data Manipulation. In: Proceedings of 4th Virtual International Conference on Innovative Production Machines and Systems.

Ziegler, Jens (2014): Usability Engineering 4. Messmethoden der Mensch-Maschine- Systemtechnik. Technische Universität Dresden, 2014.

172

Erklärung

Hiermit erkläre ich, dass ich die vorliegende Arbeit in allen Teilen selbstständig und nur unter Zuhilfenahme der angegebenen Quellen verfasst habe.

Berlin, den 06.11.2020

Carina Fresemann

173

Anhang

Fragebogen zur effizienten Produktdatenverwaltung

Effiziente Produktdatenverwaltung – Umfrage zu industriellen Bedarfen

Im Rahmen meiner Promotion erarbeite ich ein Konzept, mit dem PDM Systeme automatisiert werden und mit dessen Hilfe sich Ingenieure besser auf ihre Kernaufgaben fokussieren können. Dazu sollen Tätigkeiten der Produktdatenverwaltung, die aktuell aufwändig sind, herausgefunden werden. Die vorliegende Umfrage nimmt dazu den Sachstand im industriellen Kontext auf. Dabei stehen Methoden und Arbeitsweisen sowie klassische PDM Werkzeuge und deren Funktionen im Fokus der Betrachtung. Angaben zur Organisation und Organisationformen verbleiben unbeachtet.

Die Inhalte der Umfrage werden vertraulich behandelt, Angaben zu Person und Unternehmen dienen ausschließlich der Bewertung im Kontext und werden nicht veröffentlicht.

Bitte beantworten Sie die Fragen spontan.

Bitte geben Sie an, wie groß das Unternehmen ist in dem Sie arbeiten und in welcher Branche es beheimatet ist.

Bitte benennen Sie, welche PDM und CAD Werkzeuge Sie verwenden und wieviel Zeit Sie damit aktiv verbringen.

1. Welche Verwaltungstätigkeit der unten genannten nimmt die meiste Zeit in Anspruch? Welche verwenden Sie nicht? • Bildung von Strukturen und Verknüpfungen • Setzen von Statusi • Versionieren von Dokumenten und Dateien • Erzeugen von Sichten • Erzeugen von Konfigurationen und Varianten

Bitte begründen Sie Ihre Angaben kurz.

Anhang

2. Aus welcher Quelle bezieht ein Ingenieur Informationen darüber, für welches Modul, welches System oder welche Funktion innerhalb des gesamten Produktes sein Bauteil verwendet wird?

3. Erachten Sie die Ordnungskriterien (z.B. Teil-Module, Nummernkreise, Äste oder Abschnitte der Struktur) des Produkts als relevant für die Arbeit eines Ingenieurs?

4. Bleiben die Ordnungskriterien der Strukturen dauerhaft stabil (wie beispielsweise ein Modulsplit, wie er zu Beginn einer Produktentwicklung festgelegt wird)? 4.1 Wenn nein, entsteht dadurch eine Schwierigkeit?

5. Bleibt die Anzahl und Art der Varianten und der Konfigurationsregeln aus Produktsicht dauerhaft stabil? 5.1 Wenn nein, entsteht dadurch eine Schwierigkeit?

6. Werden in Ihrem Unternehmen Sichten auf die Produktdaten erzeugt? [Hinweis: Mit Sicht wird im Kontext dieser Arbeit eine bestimmte Anordnung ausgewählter Daten für eine konkrete Nutzergruppe verstanden.] 6.1 Wenn keine Sichten bereitgestellt werden, wäre das hilfreich oder umständlich? 6.2 Für wen?

7. Welche Funktionen im PDM Werkzeug sind am umständlichsten zu bedienen?

8. Nutzen Sie „Ersatzmethoden“, weil ihr PDM Werkzeug die direkt gewünschte Funktion nicht bietet?

9. Welche Funktionen würden Sie sich zusätzlich wünschen?

10. Wie groß ist der Aufwand des Suchens von Informationen im Vergleich zu den oben genannten Verwaltungstätigkeiten?

11. Wie groß ist der Aufwand für Korrekturen fehlerhafter Daten im Vergleich zu den oben genannten Tätigkeiten?

12. Welche Tätigkeiten könnten wegfallen, ohne dass das Ergebnis wesentlich anders wäre? (beispielsweise die Weitergabe der Informationen von Konstrukteuren an Datenverwalter oder die Korrektur von Fehlern)

13. Gibt es bei Ihnen im Unternehmen Doppelarbeiten, die durch Methoden und PDM Funktionen oder deren Zusammenspiel verursacht werden? Wenn ja beschreiben Sie diese bitte stichpunktartig.

14. Wie gut funktioniert die Integration zwischen CAD und PDM Werkzeug? Bitte notieren Sie kurz mit welchen Systemen Sie arbeiten.

Anhang Informationen zu den befragten Personen

Tabelle 42: Zusammenstellung personenbezogener Daten zur präskriptiven Befragung

Mitarbeiter- Unternehmen Branche Alter Geschlecht Abteilung anzahl Siemens 55.000 Energieerzeugung 55 männlich Methodenentwicklung Energy Siemens 55.000 Energieerzeugung 38 männlich Entwicklung Energy Boeing 150.000 Luftfahrt 45 weiblich IT AVL 5.000 Automobilbau 44 weiblich Entwicklung AVL 5.000 Automobilbau 35 männlich Entwicklung Forschung & Airbus 130.000 Luftfahrt 35 männlich Entwicklung Airbus 130.000 Luftfahrt 53 männlich Methodenentwicklung Airbus 45.000 Luftfahrt 37 männlich Entwicklung Helicopters Airbus 45.000 Luftfahrt 31 männlich IT Helicopters AUDI 90.000 Automobilbau 46 männlich Methodenentwicklung AUDI 90.000 Automobilbau 38 weiblich Entwicklung VW PKW 100.000 Automobilbau 48 männlich Methodenentwicklung VW PKW 100.000 Automobilbau 33 männlich IT GE - Energy 65.000 Energieerzeugung 46 männlich Entwicklung GE - Energy 65.000 Energieerzeugung 39 männlich Methodenentwicklung

III

Anhang Versuchsdaten: Datenblätter

Auf Anfrage bei der Autorin erhältlich.

Versuchsergebnisse: Zuweisung Produktdaten

Tabelle 43: Ergebnisse der Zuweisung für den Gabelstapler zu Zolltarifnummern

Produkt- erwartete Zolltarif- vorgeschlagene Zolltarifnummer % datenblatt nummer 847989 Maschinen, Apparate und 0,2 mechanische Geräte, a.n.g. 842720 andere selbstfahrende Karren zum Heben auf eine Höhe 0,6 84272011 von 1 m oder mehr Elektro- Gabelstapler, 84272011 Gabelstapler Stapelkraftkarren, geländegängige Gabelstapler und 0,7 geländegängig Stapelkraftkarren 84312000 Teile von Gabelstaplern und anderen mit Hebevorrichtung 0,5 ausgerüsteten Karren zum Fördern und für das Hantieren, a.n.g.

Tabelle 44: Ergebnisse der Zuweisung für die Kettensäge zur Zolltarifnummmer

Produkt- erwartete Zolltarif- vorgeschlagene Zolltarifnummer % datenblatt nummer 84678100 Kettensägen, handgeführt, mit eingebautem 0,7 nichtelektrischen Motor betrieben 84672290 Handsägen mit eingebautem Elektromotor (ausg. 0,8 Kreis- und Kettensägen) Elektro- 84672210 - Kettensäge Handkettensägen, 8467 Werkzeuge, pneumatisch, eingebautem, UC3551AK hydraulisch oder von eingebautem Elektromotor elektrischem oder nichtelektrischem 0,5 Motor betrieben, von Hand zu führen; Teile davon 84678100 - Kettensägen, handgeführt, mit eingebautem 0,9 nichtelektrischen Motor betrieben

Anhang Versuchsdaten: Tripelec Funktionen

Funktion Benennung Kommentar Die Aufgabe der Energieerzeugung kann bei F1 Energie erzeugen diesem System in drei Bereiche geteilt werden. durch eine Bremskraftrückgewinnung der F2 Energie zurückgewinnen Motoren erzeugte Energie durch ein optionales Solarmodul erzeugte F3 Solarenergie gewinnen Energie F4 Tretenergie gewinnen durch den Fahrer erzeugte Energie Die Aufgabe der Energieerzeugung kann bei F5 Energie umwandeln diesem System in drei Bereiche geteilt werden. mechanische Energie in F6 durch Einsatz eines Generators elektrische Energie umwandeln elektrische Energie in F7 mechanische Energie durch Verwendung eines Motors umwandeln Die gesamte, in welcher Art auch immer, erzeugte Energie muss vom System gespeichert und somit transportfähig gemacht F8 Energie speichern werden. Hiermit sind sowohl stationäres Laden, als auch z.B. Laden im Stand oder das Speichern der Rekuperationsenergie gemeint. Diese Energie muss dann letztlich sinnvoll auf das Gesamtsystem verteilt werden. So sind z.B. Energiesenken die Beleuchtung und der F9 Energie bereitstellen Antrieb von Bedeutung. Auch die Interaktionsgeräte müssen mit Energie versorgt werden. Diese Funktion übernimmt letztendlich die Kontrolle über das gesamte System Tripelec. Daten und Informationsfluss F10 So müssen sowohl die Motoren, als auch z.B. steuern der Energiespeicher und die Beleuchtung des Tripelec kontrolliert und gesteuert werden. In dieser Funktion sind alle Kontroll- und System kontrollieren und Regelungsvorgänge des Tripelec vereint. Dies F11 steuern ist letztlich die wichtigste Funktion im gesamten System, da es Der erforderliche Fahrmodus kann manuell durch den Fahrer oder automatisch geschaltet werden. Er wird dabei durch unzählige äußere F12 Fahrmodus einstellen Umstände beeinflusst. Durch diese Funktion werden Steuersignale in Abhängigkeit der Eingabe erzeugt.

Anhang

Funktion Benennung Kommentar Da der Fahrer mit einer maximalen Geschwindigkeit von 25 km/h mit elektrischer Unterstützung fahren F13 Geschwindigkeit kontrollieren darf, wird die Geschwindigkeit angezeigt. Die Information wird weitergeleitet. Um die Geschwindigkeit zu kontrollieren, muss diese als erstes aus der Tretleistung des Fahrers F14 Tretgeschwindigkeit errechnen berechnet werden. Hier ist noch nicht festgelegt, ob diese über die Kraft oder über die Frequenz des Pedelierens berechnet wird. Da es nicht ausreicht, beide Motoren mit der gleichen Leistung anzusteuern, muss hier eine F15 rechten Motor kontrollieren Unterscheidung der beiden Motoren eingerichtet werden. Da es nicht ausreicht, beide Motoren mit der gleichen Leistung anzusteuern, muss hier eine F16 linken Motor kontrollieren Unterscheidung der beiden Motoren eingerichtet werden. F17 Fahrzeug anhalten Bremsen müssen eingefügt werden F18 Richtung steuern Lenkung mit dem System in Verbindung bringen. Die Steuerung des Energiespeichers. Zu ihr gehören F19 Energiespeicher kontrollieren sowohl ein aktives Balancing als auch bestimmte Berechnungs- und Schutzfunktionen Zu den Aufgaben der Oberfunktion gehört auch die F20 verbleibende Wegstrecke Ressourcenverwaltung und somit das Berechnen errechnen von verbleibender Energie, verbrauchter Energie und verbleibendem Weg Errechnen der verbrauchten F21 Energie F22 Energiestatus anzeigen Schnittstelle zu "System kontrollieren". Das Tripelec soll immer noch ein vom Nutzer gesteuertes Fahrzeug sein. Insofern müssen Nutzereingaben angenommen und verwaltet F23 Nutzereingaben verwalten werden. Dies geschieht in der "Receive" und in der "Control" Funktion. Nachfolgend sind alle Eingabemöglichkeiten, welche für das zu entwickelnde Konzept notwendig sind, aufgezeigt. Fahrmodus Einstellung F24 Fahrmodus wählen erhalten Insassen gegen Wettereinfluss F28 durch Frontscheibe schützen F29 Insassen bei Unfällen schützen durch optionale Gurtanlage F30 kleine Kinder transportieren durch optionalen Kindersitz Tripelec benötigt Beleuchtung, ausreichend F33 Straßensicherheit gewähren Reflektoren und Fahnen um auch von Bussen und LKW im toten Winkel wahrgenommen zu werden. F34 Lasten mit Anhänger Stellt eine Anhängerkupplung und eine Option für transportieren einen Anhänger bereit. Lasten auf Gepäckträger F35 durch festinstallierte Plattform transportieren

Anhang Fragebogen zur Evaluierung des Chat Bots

Umfrage zur Nutzerfreundlichkeit

Bitte beantworten Sie die Fragen spontan.

stimme Stimme stimme gar stimme Aussage weniger neutral vollkom nicht zu zu men zu zu

Ich kann mir gut vorstellen den Chat Bot regelmäßig zu nutzen.

Ich empfinde den Chat Bot als unnötig komplex.

Ich empfinde den Chat Bot als einfach zu nutzen.

Ich denke, dass ich technischen Support brauchen würde, um das System zu nutzen.

Ich finde, dass die verschiedenen Funktionen des Chat Bots gut integriert sind.

Ich finde, dass es im System zu viele Inkonsistenzen gibt.

Ich kann mir vorstellen, dass die meisten Leute den Chat Bot schnell zu beherrschen lernen.

Ich empfinde die Bedienung als sehr umständlich.

Ich habe mich bei der Nutzung des Chat Bots sehr sicher gefühlt.

Ich musste viele Dinge lernen, bevor ich mit dem Chat Bot arbeiten konnte.

Kommentare/Hinweise:

VII

Anhang Fragebogen zur Evaluierung des Konzepts

Evaluierung zur Produktdatenverwaltung

Im Rahmen meiner Promotion entwickle ich ein Konzept zur Produktdatenverwaltung, das konventionelle Werkzeuge effizienter gestalten soll. Dazu werden Ihnen zunächst das Konzept sowie einige Funktionen vorgestellt.

Die Inhalte der Umfrage werden vertraulich behandelt, Angaben zur Person dienen ausschließlich der Verortung im Kontext (Methodenentwicklung, IT-Bereich, Entwicklung, Größe des Unternehmens, Art des Produkts, …) und werden nicht veröffentlicht. Angaben zum Unternehmen werden nicht erfasst und ebenfalls nicht veröffentlicht.

Bitte beantworten Sie die Fragen spontan.

Die Skalen beurteilen, entsprechend eines Schulnotensystems von 1 (sehr gut) bis 5 (mangelhaft). Diese sind auszufüllen.

Freitext Felder fordern zu einem freien Kommentar auf; diese können offengelassen werden.

Allgemein ------1 2 3 4 5

1. Wie einfach schätzen Sie die Bedienung des vorgestellten PDM-Konzepts insgesamt ein?

2. Wie effizient schätzen Sie das Arbeiten mit dem vorgestellten PDM-Konzepts insgesamt ein?

3. Wie vertrauenswürdig schätzen sie die Produktdatenverwaltung mit dem vorgestellten Konzept ein?

4. Wie beurteilen Sie die erforderliche Korrektur von Daten, nachdem das Werkzeug Fehler gefunden hat? Freitext 5. Welcher Aspekt des Konzepts erscheint Ihnen am wichtigsten/fragwürdigsten? Freitext

VIII

Anhang

Varianten ------

1 2 3 4 5

6. Wie effizient schätzen Sie die Variantenverwaltung mit der vorgestellten Vorgehensweise ein?

7. Kann die Akzeptanz des Variantenmanagements durch den Transfer der Bedienung in das Autorenwerkzeug und die Browse & Search Umgebung verbessert werden?

8. Wie schätzen Sie den Einfluss des vorgestellten Variantenmanagements auf die Datenqualität ein?

9. Sind aus Ihrer Sicht alle relevanten Funktionen zur Verwaltung von Varianten gegeben?

10. Sind aus Ihrer Sicht zu viele Funktionen zur Verwaltung von Varianten gegeben?

11. Ist das methodische Vorgehen zur Verwaltung von Varianten verständlich?

12. Ist das methodische Vorgehen zur Verwaltung von Varianten einfach?

13. Haben Sie Bedenken? Welche? Freitext 14. Welche Lücke bezüglich einer industriellen Umsetzung sehen Sie? Freitext

Anhang

Metadaten ------1 2 3 4 5

15. Wie effizient schätzen Sie die Verwaltung von Metadaten mit der vorgestellten Vorgehensweise ein?

16. Wie bewerten Sie die Akzeptanz von Metadaten durch den Transfer der Bedienung in das Autorenwerkzeug und die Browse & Search Umgebung?

17. Wie schätzen Sie den Einfluss der vorgestellten Produktgliederungsmethode auf die Datenqualität ein?

18. Sind aus Ihrer Sicht alle relevanten Funktionen zur Verwaltung von Metadaten gegeben?

19. Sind aus Ihrer Sicht zu viele Funktionen zur Verwaltung von Metadaten gegeben?

20. Ist das methodische Vorgehen zur Verwaltung von Metadaten verständlich?

21. Ist das methodische Vorgehen zur Verwaltung von Metadaten einfach?

22. Haben Sie Bedenken? Welche? Freitext

23. Welche Lücke zu einer industriellen Umsetzung sehen Sie? Freitext

Anhang

Produktgliederungen ------1 2 3 4 5

24. Wie effizient schätzen Sie die Verwaltung von Produktgliederungen mit der vorgestellten Vorgehensweise ein?

25. Kann die Akzeptanz von Produktgliederungen durch den Transfer der Bedienung in das Autorenwerkzeug und die Browse & Search Umgebung verbessert werden?

26. Wie schätzen Sie den Einfluss der vorgestellten Produktgliederungsmethode auf die Datenqualität ein?

27. Sind aus Ihrer Sicht alle relevanten Funktionen zur Verwaltung von Produktgliederungen gegeben?

28. Sind aus Ihrer Sicht zu viele Funktionen zur Verwaltung von Produktgliederungen gegeben?

29. Ist das methodische Vorgehen zur Verwaltung von Gliederungen verständlich?

30. Ist das methodische Vorgehen zur Verwaltung von Gliederungen einfach?

31. Welche Bedenken haben Sie? Freitext

32. Welche Lücke zu einer industriellen Umsetzung sehen Sie? Freitext