Die Verfügbarkeit relevanter Daten in den betreffenden Produktlebenszyklusphasen bildet eine notwendige Voraussetzung für die Durchführung industrieller Datenanalysen. Die individuelle Analysezielsetzung und die spezifischen Anforderungen des jeweiligen Anwendungsszenarios bestimmen essenzielle Randbedingungen für die technische Auslegung einer Datenanalyse-Umgebung. Ausgehend von den verschiedenen im Forschungsprojekt AKKORD analysierten Anwendungsfällen wurde ein modulares Vorgehensmodell entwickelt, das verschiedene Lösungsbausteine umfasst, um unterschiedliche Szenarien angemessen abbilden zu können. Dabei wird die Auswahl erforderlicher Lösungskomponenten und die Realisierung einer informationstechnischen Lösung durch einen an dem Cross-Industry Standard Process for Data Mining angelehnten Prozess unterstützt. Die abgedeckten Anwendungsszenarien schließen hierbei die dezentrale Vernetzung verschiedener Datenquellen ein, um die vorhandenen Datenquellen zu nutzen. Daneben wird der Aufbau eines zentralen Datenbackends für die integrierte Verwaltung aller relevanten Analysedaten ermöglicht. Um zusätzliche Flexibilität bei der Vorverarbeitung der Daten zu erreichen, wird als dritte Lösungskomponente ein Data-Warehouse-Ansatz eingesetzt. Für die in diesem Kapitel vorgestellten Datenbackend-Ansätze und Konzeptmodule wird weiterhin eine Entscheidungshilfe zur Auswahl der für einen spezifischen Anwendungsfall bestmöglichen Konfiguration vorgestellt. Abschließend werden Möglichkeiten für den Einsatz von Standardlösungen für den Aufbau des Datenbackends sowie für die Weitergabe der Daten an Analysemodule diskutiert und abgegrenzt.
5.1 Anforderungen an das Datenbackend
In der Softwareentwicklung bezeichnet ein (Daten-)Backend die Teile der Gesamtlösung, die sich mit der Speicherung und Verwaltung von Daten befassen. Das Backend, welches sich weiter vom Benutzer entfernt befindet als das Frontend, stellt Eingabemasken und andere Benutzeroberflächen und Interaktionsmöglichkeiten bereit. Grundlegende Ansätze zum Aufbau eines Backends, wie zum Beispiel Synchronisation oder Integration bestehender Datenquellen im Kontext der Produktentwicklung werden von Bergsjö et al. (2006, S. 1065 ff.) verglichen.
Die Entwicklung eines Datenbackends für die industrielle Datenanalyse setzt ein tiefgehendes Verständnis des adressierten Anwendungsszenarios voraus. Um im Kontext des integrierten Referenzbaukastens auf verschiedene grundsätzliche Ausprägungen eines möglichen Datenbackends eingehen zu können, wurden im Rahmen des Forschungs-Projekts AKKORD (siehe Kap. 1) zunächst allgemeine funktionale und nicht-funktionale Anforderungen, an die im Projekt zu entwickelnde Backend-Lösung formuliert. Diese aufgenommenen Anforderungen lassen sich anhand einiger repräsentativer Beispiele illustrieren: Durch funktionale Anforderungen wurde der prinzipielle Funktionsumfang des Backends eingegrenzt. Das Datenbackend muss erforderliche Schnittstellen bereitstellen, um verschiedene Quellsysteme anzubinden. Das Backend soll darüber hinaus in der Lage sein, diese Daten so aufzubereiten, dass sie für eine Analyse verwendet werden können. Neben der Kernfunktionalität wurden auch weitere Aspekte, wie zum Beispiel ein flexibler Einsatz der entwickelten Lösung sowohl in der Cloud als auch auf eigener Hardware vorgesehen. Nichtfunktionale Anforderungen, beispielsweise zur verarbeiteten Datenmenge, wurden ebenfalls berücksichtigt. Um das im Projekt gewonnene Wissen sichern zu können, wurde durch weitere definierte Anforderungen die Erstellung diesbezüglicher Leitfäden berücksichtigt. Insgesamt bezogen sich 29 der aufgenommenen Anforderungen auf das Datenbackend. Alle Anforderungen wurden mit passenden Prüfkriterien verknüpft, die die Basis für die Validierung am Projektende liefern sollten.
Anzeige
5.2 Allgemeines Vorgehen zum Aufbau des Datenbackends
Basierend auf den Anforderungen wurde ein Vorgehensmodell für die Entwicklung des Datenbackends definiert. Der prinzipielle Aufbau orientiert sich an den Phasen des Cross- Industry Standard Process for Data Mining (CRISP-DM) nach (Chapman et al., 2000), der ein allgemeines Vorgehen für Data Mining-Projekte definiert und bereits in Kap. 3 vorgestellt wurde (West et al., 2021, S. 133). In der ersten Phase, die das Geschäftsverständnis umfasst, wird fachlich definiert, was mit den geplanten Analysen erreicht werden soll. Ein solches Verständnis ergab sich im Projektkontext aus der Bearbeitung der ersten Arbeitspakete, die sich mit der Anforderungsaufnahme und Konzeption des Referenzbaukastens befassten. Das hier beschriebene Vorgehen setzt daher ein fachliches Verständnis als gegeben voraus, welches jedoch bei der späteren Beschreibung der fachlichen Ebene noch nachgeschärft werden kann.
Der Aufbau des Backends, von der Konzeption bis hin zur technischen Umsetzung, wird in diesem Kontext als Teil der Datenverständnis-Phase aufgefasst, da es hier um die Verfügbarmachung der Daten für die Datenvorverarbeitungs-Phase geht. In der Prozesskette der Industriellen Datenanalyse behandelt das im weiteren vorgestellte Datenbackend also den Schritt des Datenzugriffs (siehe Kap. 4). Da die Vorverarbeitung der Daten im Projektkontext teilweise in den in Kap. 6 beschriebenen Analysebausteinen erfolgt, endet der Aufbau des Datenbackends zwischen der Datenverständnis- und Datenvorverarbeitungs-Phase. In der exemplarischen Umsetzung im Projektkontext werden unterschiedliche Abgrenzungen zwischen Backend-Aufbau und Datenvorverarbeitung aufgezeigt. Dies ist schematisch in der nun folgenden Abb. 5.1 dargestellt.
Abb. 5.1
Vorgehen beim Aufbau des Datenbackends
×
Innerhalb der Datenverständnis-Phase ergeben sich die folgenden vier Teilschritte: Zunächst wird auf der fachlichen Ebene das Geschäftsverständnis auf die im Unternehmen verfügbaren Datenquellen abgebildet. Zu diesem Zweck wird der sich aus dem Geschäftsverständnis ergebende Datenbedarf in Form von benötigten Datenobjekten aufgebaut. Dieser wird dann den tatsächlich in den IT-Systemen des Unternehmens vorhandenen Datenobjekten gegenübergestellt. Hierbei besteht die Möglichkeit, in der Vernetzungsebene Querbeziehungen zwischen den einzelnen angebundenen Datenquellen zu ergänzen und diese in der Anreicherungsebene mit weiteren Informationen, wie beispielsweise externen Links oder Metainformationen, anzureichern.
Abschließend können die zusammengeführten Daten entsprechend dem Datenbedarf an die für die Datenvorverarbeitung bzw. Analyse zuständigen Bausteine weitergegeben werden.
Anzeige
5.3 Lösungsbausteine
Das im vorherigen Abschnitt abstrakt beschriebene Vorgehen lässt grundsätzlich noch ein breites Spektrum an technischen Umsetzungen zu. Im Kontext des Forschungsprojekts wurden einige Lösungsbausteine entwickelt, die auf verschiedenen Umsetzungsstrategien basieren, die von einer zentralisierten Datenintegration über Datenduplizierung bis hin zu einer metadatenbasierten dezentralen Datenhaltung reichen. Die entwickelten Lösungsbausteine in Datenzugriffsbausteine, Backendbausteine sowie Schnittstellenbausteine untergliedern. Die Wahl einer passenden Umsetzung hängt vom Anwendungsszenario ab, jede Lösung bringt eigene Vor- und Nachteile mit sich (Bergsjö et al., 2006, S. 1065 ff.).
Die Datenzugriffsbausteine ermöglichen das Anbinden von Datenquellen. Dies kann sehr pragmatisch erfolgen. Beispielsweise wurde im Kontext des Autorenn-Demonstrators (siehe Kap. 17) ein Baustein entwickelt, der die Übertragung von Daten der Bahn (Rundenzeiten und simulierte Tankfüllstände) und weiteren Metainformationen (Fahrername, Fahrzeug, Alter) ermöglicht. Dieser Zugriffsbaustein liegt in der Form eines einfachen Python-Skripts vor, dass auf einem RaspberryPi ausgeführt wird, der über Bluetooth auf die Rennbahndaten zugreift. Ein etwas komplexeres Beispiel für Datenzugriffsbausteine sind die in Abschn. 5.3.2 beschriebenen SP2IDER-Konnektoren.
Die Schnittstellenbausteine ermöglichen das Übertragen von Daten zwischen den Datenzugriffsbausteinen und dem Backend, aber auch die Weitergabe von Daten aus dem Backend an die Analysebausteine. Exemplarisch wird nachfolgend der für das Projekt zentrale Lösungsbaustein „Data Model Canvas“ vorgestellt.
5.3.1 Dezentrale Datenvernetzung mit SP2IDER
Der dezentrale Ansatz zur Datenvernetzung basiert auf der Idee, die im Unternehmen verfügbaren Daten in ihren ursprünglichen Quellsystemen gespeichert zu lassen, und über ein gemeinsames Metadatennetz darauf zu verlinken. Zum Aufbau des Netzes und zum Abruf der Daten wird jedes Quellsystem über einen minimalistischen Konnektor mit einem zentralen Repository verbunden.
Das zentrale Repository verwaltet im Gegensatz zu monolithischen Datenintegrationsansätzen bewusst keine vollständige Kopie der angebundenen Daten. Stattdessen wird nur die Information „Datensatz A existiert in Quellsystem B“ und „Datensatz A steht in Beziehung zu Datensatz C“ verwaltet. Aus der Vielzahl so beschriebener Beziehungen entsteht ein Graph, der mit zusätzlichen Informationen angereichert werden kann, um beispielsweise systemübergreifende Querbeziehungen zwischen Datensätzen zu modellieren. Wird ein kompletter Datensatz benötigt, kann dieser im ursprünglichen System abgefragt werden.
Die technologische Basis für die dezentrale Datenintegration im Forschungsprojekt AKKORD bildet das am Lehrstuhl für Virtuelle Produktentwicklung der RPTU entwickelte SP2IDER-System. Die Architektur der SP2IDER-Plattform ist in Abb. 5.2 dargestellt. Das System wurde bereits in verschiedenen Publikationen beschrieben (Eiden et al., 2021, S. 690 ff.).
Abb. 5.2
Architektur der SP2IDER-Plattform
×
Um Daten aus verschiedenen Quellsystemen in der SP2IDER-Plattform verfügbar zu machen, werden bestehende IT-Systeme über eine einheitliche Schnittstelle mit der Plattform verbunden. Auch diese Konnektoren wurden im Kontext des Projekts in Python implementiert, können aber mithilfe beliebigen Programmiersprachen umgesetzt werden, da für die Kommunikation mit der Plattform ausschließlich sprachunabhängige REST-Schnittstellen zum Einsatz kommen. Um den Benutzer durch die in Abschn. 5.2 beschriebenen Phasen zu leiten, stellt die SP2IDER-Plattform mit dem Data Model Canvas eine intuitive Benutzeroberfläche zur Verfügung (siehe Abb. 5.3). Auf der fachlichen Ebene unterstützt der Data Model Canvas die Benutzer methodisch und informationstechnisch beim Aufbau einer fachlichen Datengrundlage zur Datenanalyse. Datenmodelle aus verschiedenen Quellen können analysiert und in ein gemeinsames Modell für die weitere Analyse integriert werden. Der Aufbau dieses fachlich orientierten Datenmodells soll hierbei vorrangig durch Domänen-Experten erfolgen.
Abb. 5.3
Benutzeroberfläche des Data Model Canvas
×
Die prototypische Implementierung des Data Model Canvas wird als Web-App bereitgestellt und liefert die beschriebenen Möglichkeiten, Datenmodelle in verschiedenen Formaten sowie bereits bestehende Vorüberlegungen zu importieren. Die Daten werden in einem Graph mit Datentypen als Knoten, die durch als Kanten dargestellte Relation miteinander in Beziehung stehen, dargestellt.
Nach dem Import des ersten Datenmodells wird dieses auf die relevanten Datentypen reduziert. Der Aufbau des gemeinsamen Datenmodells folgt anschließend einem iterativen Prozess: Jedes weitere importierte Datenmodell wird ebenfalls auf die relevanten Datenobjekte reduziert. Querbeziehungen zwischen den Datenmodellen werden durch das Einfügen neuer Kanten abgebildet. Datentypen, die denselben Sachverhalt in unterschiedlichen Systemen abbilden, können zu einem gemeinsamen Knoten zusammengeführt werden.
Die zusammengeführten Informationen liefern ein initiales fachliches Verständnis über die vorhandenen Daten, und bilden somit die fachliche Ebene des Datenzugriffsprozesses ab. Gleichzeitig liefert das entwickelte Modell aber auch eine technische Abbildung der Verfügbarkeit dieser Daten in den angebundenen Quellsystemen. Der Data Model Canvas ermöglicht somit die Verfeinerung des entwickelten Datenmodells hin zur technischen Ebene. Sind die benötigten Daten sowie ihre Beziehungen und ihr Speicherort bekannt, kann die eigentliche Vernetzung stattfinden. In diesem Schritt werden die im DMC entwickelten Modelle auf die reale Infrastruktur übertragen, damit die Daten in gebündelter Form für die Analyse zur Verfügung stehen. Dafür kommen verschiedene Lösungen infrage, wobei der DMC durch seinen Aufbau eine große Flexibilität in der technischen Umsetzung erlaubt. Eine Einschränkung auf konkret zu verwendende Softwaresysteme oder eine feste Struktur des endgültigen Datenmodells wird vermieden. Im Projektkontext ergibt sich die konkret gewählte Umsetzung aus den Anforderungen der betroffenen Use Cases.
In den Anwendungsfällen des Projekts kam der Data Model Canvas für die Gegenüberstellung eines Datenbedarfes gegen die in den mit SP2IDER verbundenen Quellsystemen verfügbaren Daten zum Einsatz. Der Datenbedarf wird in diesem Fall in Form einer JSON-Datei bereitgestellt. Benötigte Datenobjekte können mit verfügbaren Datenobjekten verbunden werden. Das daraus resultierende Datenmapping wird wiederum als JSON-Datei bereitgestellt, die u. a. URLs zum Abruf der ausgewählten Daten beinhaltet. Diese Datei wird anschließend an die in Rapidminer Studio implementierten Analysebausteine weitergegeben.
5.3.2 Aufbau eines zentralen Datenmodells mit der Contact Elements-Plattform
In diesem Ansatz werden alle Daten in einer zentralen Plattform gespeichert. Das Datenmodell kann hierbei unterschiedlichste Datenquellen umfassen und detaillierte Verknüpfungen abbilden. Die eingesetzte Datenbank kann bereits Werkzeuge zur weiteren Vernetzung, Bearbeitung oder Auswertung der Daten mitliefern. Im Kontext von Produktdaten oder Daten aus dem „Internet of Things“ (IoT) ist es sinnvoll, eine angemessene Plattform zu wählen, wie beispielsweise eine PLM-Softwarelösung für die Verwaltung von Produktlebenszyklusdaten.
Im Forschungsprojekt wurde ein zentrales Datenmodell in der Elements-Plattform des Herstellers Contact Software erstellt. Die Architektur der Lösung ist in Abb. 5.4 dargestellt. Im Zentrum stand hierbei der Aufbau eines durchgängigen Datenmodells, um eine möglichst breite Informationsbasis für Datenanalysen bereitstellen zu können.
Abb. 5.4
Architektur und Module des konsolidierten Datenbackends
×
Zur Anbindung von Datenquellen und zur Weitergabe der Daten an die Analysebausteine wird auch hier auf den im vorherigen Ansatz beschriebenen Data Model Canvas zurückgegriffen. Ein Einsatz der bestehenden Möglichkeiten zum Datenimport oder -export in der Contact Elements Plattform ist ebenfalls möglich.
Der Einsatz einer konsolidierten Backend-Lösung bietet vielfältige Möglichkeiten, Daten direkt miteinander zu verknüpfen und über den kompletten Produktlebenszyklus hinweg an einer Stelle zu verwalten. Konkret können beispielsweise Daten eines über die Zugriffsbausteine angebundenen IoT-Assets mit PLM-Stammdaten vernetzt werden. Das konsolidierte Backend liefert auch Möglichkeiten, erste Vorverarbeitungsschritte oder grundlegende Analysen direkt auszuführen und wichtige Performance-Indikatoren in Dashboards zusammenzufassen. Die für verschiedene Aufgabenbereiche relevanten Daten sind in Abb. 5.5 dargestellt.
Abb. 5.5
Datenmodell des konsolidierten Datenbackends
×
Verschiedene Datenobjekte aus Modulen repräsentieren Daten aus heterogenen Quellen des Produktlebenszyklus in der Contact Elements Plattform: Das Modul Produktdatenmanagement besteht aus Objekten wie dem Produkt selbst, das auf generischer Ebene verschiedene Teile enthält. Das generische Produkt muss Spezifikationen erfüllen, die Teil von Anforderungen sind, die in Testläufen gemäß Akzeptanzkriterien getestet werden und Testergebnisse erzeugen. Jedes getestete Teil wird durch die Zuweisung einer Serie instanziiert, auf die in einem Testauftrag als Teil des Testausführungsmanagementmoduls Bezug genommen wird. Arbeits- und Prüfpläne bestehen aus einer oder mehreren Sequenzen (bzw. Prüfprozessen) und einer oder mehreren Operationen (bzw. Prüfschritten) und sind Teil des Moduls Arbeitsplanung bzw. Prüfplanung. Ein Arbeitsplatz stellt das Organisations- und Ressourcenmanagementmodul dar, das Teil einer Organisation oder eines Werkes ist, dem Personen, z. B. arbeitendes Personal, zugeordnet sind. Echtzeitdaten werden durch Objekte wie Assets repräsentiert, die den digitalen Zwilling einer Produktinstanz beschreiben. Der Produktionsauftrag schließlich beschreibt die Reihenfolge, in der Vorgänge ausgeführt werden. Als Teil verschiedener Module kommunizieren diese Objekte mit den Modulen zur Datenanalyse und der Datenmodellanalyse und -vorlage.
Wie oben beschrieben, bietet die CONTACT Elements Plattform ein umfangreiches Datenmodell, das es erlaubt, heterogene Daten aus verschiedenen Legacy-Quellen in eine State-of-the-Art-Plattform einzubringen, zu verknüpfen und diese Daten semantisch anzureichern. Diese Ansätze können mit den Bausteinen der anderen Ansätze kombiniert werden, um eine ganzheitliche Backendlösung zu realisieren. Das detaillierte Konzept wurde im Rahmen einer Veröffentlichung im Rahmen der DESIGN2022 Konferenz vorgestellt (Eiden et al., 2022, S. 693 ff.). Hier ist auch beschrieben, wie ein zentrales Backend mit dem SP2IDER-System aus der in Abschn. 5.3.1 beschriebenen dezentralen Lösung kombiniert werden kann, um gezielt Daten für eine Analyse zusammenzuführen und an die im Projekt entwickelten Analysebausteine weitergegeben werden.
5.3.3 Data Warehouse-Ansatz mit Power-BI
Ein Data Warehouse ist eine für Analysezwecke optimierte zentrale Datenbank, die Daten aus mehreren, in der Regel heterogenen Quellen zusammenführt (Devlin & Cote, 1996). Die Architektur eines Data Warehouse und von Microsoft Power BI umfasst in der Regel die Verwendung eines ETL-Tools (Extrahieren, Transformieren, Laden), um Daten z. B. aus SaaS-Anwendungen, aber auch aus strukturierten Dateien (Excel) oder unstrukturierten Formaten, sowie Datenbanken zu extrahieren und in diese über ein Staging/Publishing Mechanismus in das Data Warehouse zu laden. Dabei sind insbesondere das Vorschieben von Business-Transformationslogik aus Power BI in die Datenbank und das Speichern von Dimensionsdaten im Data Warehouse für Berichts- und Analysezwecke zu beachten. Je nach Situation kann entweder ein Data Warehouse oder Power BI Dataflow die beste Option für eine bestimmte Lösung sein. Im Kontext AKKORD lag der Fokus auf der Implementierung des Data Warehouse. PowerBI wurde im Rahmen der Plausibilisierung und Validierung der Daten im Wesentlichen für die Visualisierung und das Reporting verwendet. Zu den verwendeten Verfahren für die Kopplung eines Data Warehouse mit Power BI gehörten neben der Verwendung eines Data Warehouse, das alle Daten an einem einzigen Ort für Analysen konsolidiert, auch die Erstellung eines dimensionalen Modells mithilfe von Datenflüssen, sowie die Möglichkeit zur Berichtserstellung und die Implementierung von Self-Service-BI.
Im Rahmen von AKKORD zeigt das Abb. 5.6 die gewählte Architektur, die im Rahmen des Referenzbaukastens als Lösungsschablone dienen sollte. Ausgehend von verschiedenartigen Quellsystemen wird mittels verschiedener Mechanismen und Methoden, wie das Mapping von Modellinformationen (Klassen, Attribute, Relationen), Datenschemas und Datenstrukturen und deren Konsolidierung die Daten in ein Data Warehouse, bestehend aus Staging und Publishing System, hinterlegt und aufbereitet. Diese stehen im Anschluss zur Analyse mittels z. B. Visualisierung, Machine-Learning-Algorithmen oder anderen Verfahren u. a. für PowerBI oder anderen 3rd Party Solutions den Domänenexperten im Unternehmen zur Verfügung.
Abb. 5.6
Architektur des Data Warehouses im Referenzbaukasten von AKKORD
×
Für die Instanziierung der Architektur aus Abb. 5.6 wurde ein agiler Ansatz anstelle eines Big-Bang-Ansatzes gewählt. Es wurden sukzessive verschiedene Quellsysteme, je nach Verfügbarkeit, agil aufbereitet und in das Data Warehouse extrahiert. Ein großer Vorteil dieser Methode liegt darin, dass auf diese Weise sich die Erstellung abtrünniger „unabhängiger“ Data Marts vermeiden lässt und das Geschäftsmodell und die Architektur nur bei Bedarf und sobald die Data Marts einen echten Mehrwert liefern, berücksichtigt werden. Außerdem ist es wichtig, in der Testphase Sortiertests sowie Hierarchisierungstest durchzuführen und später optimierte Abläufe einzuführen. Dazu wurden entsprechende Läufe und Tests über eine speziell geschaffene Infrastruktur entwickelt und durchgeführt. Schließlich sind die Einhaltung von Best Practices der Branche, wie z. B. das Verständnis, warum man ein Data Warehouse braucht, und die Analyse der Quellsysteme, wichtige Konzepte, die bei der Implementierung berücksichtigt wurden.
In Abb. 5.7 wird die Instanziierung der Architektur dargestellt. Dabei wird auf der linken Seite den Quellsystemen die zugehörige Instanz, sowie die Import- und Mappingmethode gezeigt. In der PDTec eigenen ice.NET Plattform wird die Staging Datenbank gehostet. Ice.NET stellt mittels speziell im Projektkontext entwickelten Tools automatisierte Transformationsalgorithmen zur Verfügung, die im Wesentlichen eine Normalisierung der DB vornehmen, wobei der Fokus insbesondere auf Robustheit und Performance, z. B. bei verschachtelten Hierarchien, lagen. Im ice.NET Data Warehouse liegen letztendlich die normalisierten Daten bereit, um in verschiedenen 3rd Party Tools Anwendung zu finden. Beispielhaft wurde hierzu PowerBI, SQL View und SQL Queries herangezogen.
Abb. 5.7
Instanziierung des Data Warehouse für AKKORD
×
5.4 Diskussion und Entscheidungshilfe zur Auswahl der entwickelten Lösungsbausteine
Die Stärke des Data-Warehouse-Ansatzes liegt in der flexiblen Vorverarbeitung in der Staging-Datenbank, da hier eine uneingeschränkte Transformation der Daten vorgenommen werden kann. Wie bereits beschrieben können die anderen beiden Ansätze (d. h. dezentrale Datenvernetzung oder zentrales Datenmodell) eingebunden werden, indem die Daten durch ein geeignetes Austauschformat in die Staging-Datenbank übertragen werden. Der Ansatz ist also insbesondere geeignet, wenn ein exploratives Herangehen an die Daten und eine umfangreiche Datenvorverarbeitung bereits im Backend erwünscht sind. Zur Befüllung des Data Warehouses kann bei Bedarf auf Datenzugriffsbausteine zugegriffen werden, die im Kontext der anderen Ansätze entwickelt wurden.
Der Aufbau eines zentralen Datenmodells ist sinnvoll, wenn im angedachten Einsatzszenario eine hohe Integrationstiefe und ein direkter Zugriff auf Daten aus dem Live-Betrieb erforderlich sind. Sofern eine vollständige Backend-Lösung ohne zuvor bestehende Datenbanken aufgebaut werden soll, liefert ein zentrales Backend direkt einen Ort, an dem Daten persistent gespeichert werden können. Für Datenanbindung und -weitergabe kann hier ebenfalls auf Bausteine aus dem dezentralen Ansatz zurückgegriffen werden, wie in Abschn. 5.3.1 aufgezeigt wird. Falls bereits andere datenverwaltende IT-Systeme im Einsatz sind, gilt es hier aber den „Single Source of Truth“-Grundsatz zu beachten, d. h. keine Datenbestände parallel weiter zu pflegen. Stattdessen wäre hier eine (potenziell aufwendige) Datenmigration angeraten.
Der dezentrale Ansatz kommt ohne die Einführung einer großen neuen Datenbank aus. Über offene Standards kann mit relativ geringem Aufwand auf neue Quellsysteme zugegriffen werden, weshalb der Ansatz im Kontext des Forschungsprojekts auch oft als „Datenlieferant“ für die beiden anderen Ansätze zum Einsatz kam. Dieser Daten-Minimalismus wird aber damit erkauft, dass zunächst keine Datenbank für neue Daten ohne persistentes Quellsystem (z. B. ein neu angebundenes IoT-Asset) zur Verfügung steht.
5.5 Zusammenfassung
Insgesamt ergibt sich im Kontext des im Projekt realisierten Referenzbaukastens eine flexible, modulare Lösung, die auf spezifische Datenanalyse-Anforderungen des jeweiligen Unternehmens anpassbar ist. So stehen neben dem vorgestellten Prozess und IT-Tool zur Analyse vorhandener Datenmodelle Lösungen für die Sammlung und Verwaltung der relevanten Daten: Dieser kann durch den Aufbau einer Staging-Datenbank für Analysen in einem kontrollierten Umfeld erfolgen. Gleichermaßen stehen aber auch Konzepte für den dezentralen Zugriff auf Daten mittels Verwaltung eines gemeinsamen Metadatenmodells sowie skalierbare Konzepte für den Aufbau eines Datenbackends im Unternehmen bis hin zu einer vollständigen Lösung zur Datenverwaltung basierend auf dem PLM-System Contact Elements zur Verfügung. Je nach gewähltem Lösungsansatz stehen die gesammelten Daten und/oder Analyseergebnisse zur weiteren Freigabe zur Verfügung. Die Anforderungen an das Rollen- und Rechte-Management variieren hierbei stark mit den anvisierten Anwendungsfällen. Besonders im Hinblick auf Kollaboration über Unternehmensgrenzen hinweg besteht ein großer Bedarf daran, den Zugriff auf freigegebene Daten des eigenen Unternehmens feingranular kontrollieren zu können. Im Projekt kommt das ausgereifte Rollenkonzept der Contact Plattform zum Einsatz, für Daten aus den Quellsystemen wird auf die sorgfältige Vergabe von Rechten in den jeweiligen Zielplattformen gesetzt, um den beteiligten Unternehmen maximale Sicherheit und Transparenz zu garantieren.
Im Rahmen der Use Cases im Projekt wurde ein breites Feld an unterschiedlichen Szenarien aufgezeigt, weshalb eine „One-Size-Fits-All“-Lösung für das Datenbackend nicht realistisch erscheint. Stattdessen wird im Rahmen des modularen Referenzbaukastens des AKKORD-Projekts die hier vorgestellte Bandbreite an Lösungsbausteinen bereitgestellt, um auf die individuellen Anforderungen von Unternehmen eingehen zu können.
Denkbare Erweiterungen der im Projekt entwickelten Lösung wären beispielsweise Konzepte zu entwickeln, wie die Datenfreigaben anonymisiert und gefiltert werden können. Zudem könnten zeitgebundene Freigaben zwischen Unternehmen betrachtet werden, was beispielsweise ein „Abo-Modell“ für Nutzungsdaten ermöglicht.
Die im Leistungsbereich entwickelten Lösungen werden im Rahmen der Projektergebnisse zur Verfügung gestellt. Zudem wird derzeit die Veröffentlichung der im akademischen Umfeld entstandenen Lösungskomponenten geprüft.
Open Access Dieses Kapitel wird unter der Creative Commons Namensnennung 4.0 International Lizenz (http://creativecommons.org/licenses/by/4.0/deed.de) veröffentlicht, welche die Nutzung, Vervielfältigung, Bearbeitung, Verbreitung und Wiedergabe in jeglichem Medium und Format erlaubt, sofern Sie den/die ursprünglichen Autor(en) und die Quelle ordnungsgemäß nennen, einen Link zur Creative Commons Lizenz beifügen und angeben, ob Änderungen vorgenommen wurden.
Die in diesem Kapitel enthaltenen Bilder und sonstiges Drittmaterial unterliegen ebenfalls der genannten Creative Commons Lizenz, sofern sich aus der Abbildungslegende nichts anderes ergibt. Sofern das betreffende Material nicht unter der genannten Creative Commons Lizenz steht und die betreffende Handlung nicht nach gesetzlichen Vorschriften erlaubt ist, ist für die oben aufgeführten Weiterverwendungen des Materials die Einwilligung des jeweiligen Rechteinhabers einzuholen.
