Konzept und Implementierung eines Frameworks zur Verwaltung von Digital Twins

Universität Ulm | 89069 Ulm | Germany Fakultät für Ingenieurwissenschaften, Informatik und Psychologie Institut für Datenbanken und Informationssysteme Konzept und Implementierung eines Frameworks zur Verwaltung von Digital Twins Bachelorarbeit an der Universität Ulm Vorgelegt von: Sven Bihlmaier sv[email protected] Gutachter: Prof. Dr. Manfred Reichert Betreuer: Klaus Kammerer 2017 Fassung 3. August 2018 c 2017 Sven Bihlmaier This work is licensed under the Creative Commons. Attribution-NonCommercial-ShareAlike 3.0 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/de/ or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA. Satz: PDF-L A TEX2ε Kurzfassung Die fortschreitende Digitalisierung und damit verbundene Themen wie Industrie 4.0 werden für Unternehmen immer wichtiger. So sollen zukünftig beispielsweise digitale Abbilder, sogenannte Digital Twins, von Produkten helfen, deren Lebenszyklus zu analysieren. Die hierfür erforderlichen Daten müssen erhoben und gespeichert werden. Diese können auch für andere Aufgaben bereitgestellt werden. Die Daten liegen aber meist in unterschiedlichen Formaten und an verschiedenen Endpunkten bereit. Deren Erhebung und Integration in bestehende Informationssysteme ist aufgrund der meist großen Datenmengen zudem aufwendig und meist nur mit großem Aufwand verwaltbar. Im Rahmen dieser Bachelorarbeit wird ein graphbasiertes Konzept zur Verwaltung von Digital Twins am Beispiel von Pharmaverpackungsmaschinen vorgestellt. Zusätzlich wird die Machbarkeit mit einer prototypischem Implementierung aufgezeigt. iii Danksagung Zunächst gilt mein Dank Herrn Prof. Dr. Manfred Reichert für die Bereitstellung des Themas der Bachelorarbeit und den Ressourcen, dieses zu bearbeiten. Einen besonderen Dank widme ich meinem Betreuer Klaus Kammerer, der mich während der gesamten Zeit fachlich und persönlich unterstützt und motiviert hat. Außerdem möchte ich meiner Familie danken, die mich tatkräftig moralisch unterstützt hat. Weiter danke ich meinen Freunden, insbesondere Adrian und Fabian, die mich sowohl fachlich unterstützt als auch motiviert haben. Mein Dank gilt zudem Sarah, die mich während der Arbeitsphase immer wieder auf den Boden zurückgeholt hat. v Glossar API Application Programming Interface. Eine API ist eine Schnittstelle, mit deren Hilfe Systeme miteinander kommunizieren können. CRUD Das Akronym steht für Create, Read, Update, Delete. Dies sind die üblichen Methoden, um Daten in persistenten Speichern zu verwalten. Framework Ein Framework ist eine Rahmenstruktur für ein Softwareprojekt. Es bietet wichtige Funktionalitäten für die gewünschten Einsatzgebiete. HTTP Hypertext Transfer Protocol. HTTP ist ein Protokoll zur Übertragung von Daten zwischen Systemen. JSON Die JavaScript Object Notation ist ein Datentransport-Format. REST Representational State Transfer bezeichnet die Möglichkeit, Methoden über eine Web-Schnittstelle aufzurufen. URL Ein Uniform Resource Locator ist ein einheitlicher Ressourcenzeiger in einem Computernetzwerk. Meist auch umgangssprachlich als "Internetadresse" genutzt, können mit URLs Ressourcen eindeutig identifiziert werden. XML Mit der Extensible Markup Language können hierarchisch strukturierte Daten abgebildet werden. XML ist ein standardisiertes Format und kann dazu genutzt werden, Daten zwischen Systemen zu transportieren. vii Inhaltsverzeichnis Glossar vii 1 Einleitung 1 1.1 Problemstellung ................................ 1 1.2 Zielsetzung ................................... 2 1.3 StrukturderArbeit ............................... 3 2 Anforderungen und Analyse 5 2.1 UseCases ................................... 5 2.1.1 Use Case 1: Produktionsmaschinen . . . . . . . . . . . . . . . . . 5 2.1.2 UseCase2:PKW ........................... 7 2.1.3 Use Case 3: Softwareabhängigkeiten . . . . . . . . . . . . . . . . 10 2.2 Anforderungen ................................. 11 3 Grundlagen 15 3.1 DigitalerZwilling ................................ 15 3.2 Datenbankmanagementsysteme . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.1 Neo4j Graph Database . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.2 Elasticsearch.............................. 18 3.3 WebServices.................................. 20 3.3.1 Austauschformate . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.3.2 Schematisierung............................ 22 3.3.3 URL................................... 23 3.3.4 Representational State Transfer (REST) . . . . . . . . . . . . . . . 24 3.4 SpringFramework ............................... 24 3.4.1 SpringBoot............................... 26 3.4.2 SpringData............................... 27 4 Lösungskonzept 29 4.1 Anforderungsauswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 ix 2 Anforderungen und Analyse werden Daten aus verschiedenen Quellen in ein System geleitet und dort in ihrem jeweiligen Format abgespeichert. Um diese Daten dann vergleichen zu können, müssen die Datensätze zuerst analysiert werden, um die gewünschten Daten in einem nativen Format extrahieren zu können (siehe Abbildung 2.1). MaschinenBediensystem SensorMesswerte CAD-Server Zeichnungen (CAD) Handbücher VerfahrensAnweisungen Bilder Datenbank Maschinenaufbau Nutzer Alarme Manuelles Abrufen der Daten Abbildung 2.1: Anwendungsfalldiagramm Produktionsmaschinen Die verschiedenen Daten werden außerdem meist unstrukturiert in einer Datenbank gespeichert, sodass bei einer Suche meist die gesamte Datenmenge durchsucht werden muss, um einen bestimmten Datensatz zu finden. 6 2.1 Use Cases Soll dann auf die Daten zugegriffen oder sollen die Daten verändert werden, muss für jedes Datenformat eine andere Bearbeitungsmethode gewählt werden. Meist können verschiedene Datenformate nur auf bestimmten Maschinen manipuliert werden. Es gibt demnach keine einheitliche Schnittstelle, die von den Mitarbeitern genutzt werden kann. Bei einem Ausfall einer solchen Maschine muss ein externer Techniker hinzugezogen werden, der durch die Auftragsplanung, das Kennenlernen der Maschine, die Lokalisierung des Problems und schließlich die Problemlösung einen langen Stillstand der Maschine verursacht, in dem diese nicht arbeiten kann. Zudem wird der Wartungsprozess meist nur unzureichend dokumentiert [ 4 ]. Diese Dokumentationen werden dann wiederum in einer Datenbank hinterlegt und dort nur im Fehlerfall noch einmal eingesehen. Wichtige Statistiken, die aus diesen Dokumentationen erhoben werden können und sich positiv auf die Wartungsintensität von Systemen auswirken, können daher nicht effektiv ausgeführt werden. Wenn ein Techniker Einsicht in die verschiedenen Daten einer Maschine bekommen sollte, muss gewährleistet sein, dass er nur freigegebene Daten einsehen darf. Beispielsweise sind für einen Techniker Daten über den physikalischen Aufbau einer Maschine relevant. Andere Daten wiederum können für die Wartung irrelevant sein und sollten daher nicht von einem Techniker eingesehen werden. 2.1.2 Use Case 2: PKW Ähnlich wie bei Maschinen im vorhergehenden Anwendungsfall bestehen auch PKW aus vielen Einzelteilen, Komponenten und Sensoren, die wiederum unterschiedliche Eigenschaften aufweisen und Messdaten generieren können. Die Daten über den physikalischen oder logischen Aufbau eines PKW können innerhalb der Produktion von Nutzen sein, da PKW oft in vielen verschiedenen Konfigurationen und mit speziellen Extraausstattungen produziert werden und die digitale Abbildung hierbei mit einer einheitlichen Repräsentation hilfreich sein kann. Besitzer eines PKW müssen diesen oftmals wartungsbedingt in eine Werkstatt bringen und ihn auf Fahrtauglichkeit oder Schäden und Fehler untersuchen lassen. Je nach Zustand des PKW ist diese Überprüfung mehr oder weniger aufwendig und nimmt entsprechend mehr oder weniger Zeit und somit Kosten in Anspruch. Oftmals fehlt eine 7 2 Anforderungen und Analyse genaue Beschreibung des Fahrzeugzustands vor der eigentlichen Untersuchung. Hierdurch kann es zu unerwünschten Fehleinschätzungen bezüglich des Wartungsaufwands kommen. Anhand im PKW gemessener Sensordaten können außerdem beispielsweise auch Informationen über das Fahrverhalten gewonnen werden. Diese Informationen sind momentan zum Beispiel für Versicherungen interessant. So bieten manche Versicherungen an, dem Versicherten in einer Werkstatt ein kleines Gerät in den PKW einbauen zu lassen, mit dem bestimmte Werte wie Seitenbeschleunigung (die beispielsweise auf harte Lenkmanöver hinweisen) oder Beschleunigung (die hartes Bremsen aufzeigen kann) gemessen werden, um im Nachhinein die Versicherungstarife an das Fahrverhalten des Fahrers anzupassen: je sicherer ein Fahrer fährt, desto günstiger kann sein Versicherungstarif eingestuft werden [ 5 ]. Die hierbei gesammelten Daten sind momentan nicht einsehbar und stehen ausschließlich der Versicherung zur Verfügung. Diese Daten werden nicht voll ausgenutzt, da sie viele Informationen enthalten, die auch in anderen Teilsystemen Relevanz haben. So können beispielsweise die vom Gerät gemessenen Sensordaten in das Fahrzeugsystem eingegeben werden, um so die Nachrüstung von Fahrerassistenzsystemen in alten PKW zu ermöglichen. Allgemein ist das Sammeln und übersichtliche Darstellen dieser Fahrzeugdaten ein wichtiger Aspekt. Über diese Informationen können viele Aussagen bezüglich der Wartung von PKW gesammelt und getroffen werden. Anhand der ADAC Pannenstatistik wird ersichtlich, dass die Wartung von PKW eine große Rolle spielt und viel Aufwand mit sich bringt [ 6 ]. PKW-Hersteller sollten demnach mehr in eine höhere Wartbarkeit investieren. Es ist momentan zwar möglich, aber dennoch sehr schwierig, Probleme am eigenen PKW als fachfremde Person zu beheben. Dies flächendeckend zu realisieren wäre für viele PKW-Besitzer eine markante Ersparnis. Nicht nur PKW, sondern auch LKW können von der Technik profitieren. Über das interne Sammeln der Messdaten können hierbei wichtige Informationen wie Ruhezeiten oder Mautgebühren zentral gespeichert und an die jeweilige Spedition weitergegeben werden. Natürlich betrifft auch LKW der Vorteil der verbesserten Wartbarkeit. 8 2.1 Use Cases Daten, die bei den verschiedenen Messungen anfallen oder die bei der Produktion eines PKW bereits hinterlegt werden, können zentral in einer digitalen Repräsentation eines PKW gespeichert werden, sodass alle Daten über diesen Digital Twin auf einmal abgerufen werden können. Insgesamt kann mit dem Digital Twin der Pfad in Richtung Wartungsverbesserung, Telematik und Fahrsicherheit weiter geebnet und ausgebaut werden. Abbildung 2.2 stellt einen Auszug aus einer Übersicht über die verschiedenen Daten dar, die von einem Nutzer manuell abgefragt werden können. Nutzer Manuelle Abfrage der einzelnen Daten Beschleunigung Kurbelwellenposition Temperatur Kraft, Drehmoment Durchfluss Abgaszusammensetzung Druck Raddrehzahl Drehzahl, Geschwindigkeit Bremsbelagverschleiß Position Sensoren Abbildung 2.2: Auszug der Datenstruktur eines PKW 9 2 Anforderungen und Analyse 2.1.3 Use Case 3: Softwareabhängigkeiten Bei der Softwareentwicklung können Teile anderer Software wiederverwendet werden, sofern die zugrundeliegende Architektur dies zulässt. Softwareentwickler profitieren somit von bereitgestellten Frameworks zur Erstellung komplexer Softwaresysteme. Diese vielen verschiedenen Frameworks können auch Abhängigkeiten untereinander aufweisen. Um eine korrekte Auflösung dieser Abhängigkeiten gewährleisten zu können, muss sichergestellt werden, dass die einzelnen Versionen der Frameworks dies erlauben. Um die Verwaltung solcher Frameworks und ihrer Versionsanforderungen zu automatisieren und zu vereinfachen, werden viele unterschiedliche Dependency Management Systeme angeboten (beispielsweise NuGet für .NET [ 7 ] oder Maven beziehungsweise Gradle für Java [ 8 , 9 ]. Solche Systeme überwachen, sofern möglich, alle vorhandenen sogenannten ”Dependencies” (Abhängigkeiten zu anderer Software) und sorgen dafür, dass diese auf dem benötigten und möglichst neuesten Stand sind. Diese Systeme schlagen dem Nutzer vor, welche Versionen benötigt werden und laden diese (sofern dies erlaubt ist) automatisch in das Softwareprojekt. Durch die meist gegenseitige Abhängigkeit vieler verschiedener Dependencies kann dieses Netz aus Abhängigkeiten als Graph dargestellt werden, dem sogenannten Dependency Graph. Auch für die beiden bereits genannten Einsatzzwecke (Maschine und PKW) und deren Software werden immer auch Frameworks genutzt, die entweder vom Hersteller selbst oder von Zulieferern entwickelt werden. Abbildung 2.3 zeigt ein Beispiel für einen solchen Dependency Graph für eine GraphAlgorithmik-Software. Diese benötigt Frameworks, um beispielsweise einzelne Knoten eines Graphen verwalten zu können oder komplexe mathematische Berechnungen durchführen zu können. Sowohl Klassen zur Erstellung eines Graphen als auch die mathematisch-logischen Pakete werden durch solche Frameworks bereitgestellt. Ein Dependency Graph kann mit Dependency Management Software erstellt werden. So können wichtige Kernkomponenten, mehrfach genutzte Pakete oder Abhängigkeiten sofort erkannt werden. 10 2.2 Anforderungen Programm Graphengine Mathematikengine Nodepaket Algorithmikpaket Numerikpaket Logikpaket Abbildung 2.3: Beispielhafter Dependency Graph 2.2 Anforderungen Die aufgezeigten Use Cases behandeln verschiedene Problemstellungen und Themengebiete. Das zu erstellende Konzept soll Digital Twins der vorgestellten Use Cases ermöglichen. Zusätzlich wird ein Managementsystem für die einzelnen Digital Twins benötigt, um diese zentral speichern und verwalten zu können. Die einzelnen Anforderungen bezüglich der Funktion der Software werden in Tabelle 2.1 aufgelistet. Des Weiteren ergeben sich nicht-funktionale Anforderungen, die in Tabelle 2.2 beschrieben werden. 11 2 Anforderungen und Analyse Tabelle 2.1: Funktionale Anforderungen F1 Heterogene Datenmodelle Daten sollen in verschiedenen Formaten eintreffen können und so verarbeitet werden, dass sie nachher ein einheitliches Format besitzen. F2 Unterschiedliche Datenquellen Daten sollen aus verschiedenen Quellen eintreffen können und weiterverarbeitet werden. F3 Beziehung zwischen Datensätzen Daten über die physikalische Struktur eines Objekts sollen mit Messwerten der Sensoren dieses Objekts verbunden werden können, um so weitere Aussagen treffen zu können. F4 Gruppierung von Daten Messdaten sollen direkt an die entsprechenden Module, in denen sie aufgenommen wurden, gekoppelt werden können. F5 Dynamische Akquisition von Daten Die Software soll selbstständig während der Laufzeit Daten sammeln, verarbeiten und abspeichern können. F6 Effiziente Suchfunktionen Die Software soll so aufgebaut sein, dass Daten strukturiert abgespeichert werden, sodass Suchen auf den Daten möglichst schnell sind. F7 Standardisierte Schnittstellen Mit der Software soll möglichst agil kommuniziert werden können. Über eine Schnittstelle soll auf die gesamte Software zugegriffen werden können. F8 Authentifizierung Der Zugriff auf Daten soll beschränkt werden können, sodass für den Zugriff eine bestimmte Authentifizierungsstufe nötig ist. 12 2.2 Anforderungen Tabelle 2.2: Nicht-funktionale Anforderungen NF1 Data Awareness Unternehmen sollen sich der Daten bewusst sein, die sie sammeln und der Möglichkeiten, die sie mittels dem Sammeln der Daten haben. Dafür sollen unter anderem Modelle der Daten bereitgestellt werden. NF2 Generischer Aufbau Das Konzept zur Erstellung von Digital Twins soll so generisch wie möglich werden, um möglichst viele Use Cases abdecken zu können. NF3 Geschwindigkeit Alle Suchen und das Laden der Daten sollen so schnell wie möglich (möglichst unter einer Minute) ablaufen. NF4 Wiederverwendbarkeit Die Software soll so erstellt werden, dass große Teile der Software wiederverwendet werden können (Stichwort Schnittstellen). NF5 Wartbarkeit Die Software soll einfach verständlich und gut dokumentiert sein, sodass sie einfach zu warten ist. NF6 Skalierbarkeit Die Software soll hoch skalierbar sein. Das heißt es sollen Tools genutzt werden, die eine möglichst hohe Skalierbarkeit gewährleisten können. 13 3 Grundlagen 3.1 Digitaler Zwilling Ein Digitaler Zwilling ist ein Modell, das eine physikalische Maschine hinsichtlich ihrer Funktion und ihrer Daten digital abzubilden versucht [ 10 ]. So können ganze Maschinen mitsamt ihrer Funktionalität und ihren physikalischen Gegebenheiten digitalisiert werden. Zur Unterstützung dessen werden der Maschine eigene Sensoroder Metadaten (z.B. Standort, Anschaffungsjahr, letzte Wartung) angehängt. Der Mehrwert für das Unternehmen, das den digitalen Zwilling einsetzt, und den Anwender des Systems liegt hier in der permanenten Verfügbarkeit. So besitzt die Firma durch den digitalen Zwilling einer Maschine an einem gegebenenfalls fernen Standort über diese Maschine trotz der Distanz alle nötigen Informationen. Beispielsweise kann so präventiv eine Wartung angesetzt werden, wenn Messdaten von Sensoren von den bisher gemessenen Werten stark abweichen. Dies kann das Unternehmen nutzen, um die Wartung der eigenen Maschinen zu überwachen und zu optimieren. Zudem kann im Nachhinein über den standardisierten Aufbau der digitalen Zwillinge einfacher Datenaustausch mit externen Unternehmen gewährleistet werden. Hierbei können unter anderem den Mechanikern vor Ort direkt Daten zugänglich gemacht werden, sodass diese mit dem Aufbau einer Maschine bereit vertraut sind, bevor sie die Maschine in der Firma gesehen haben. Ein solcher Digitaler Zwilling mit einigen Komponenten und Messwerten zeigt Abbildung 3.1. 15 3 Grundlagen 3.3.2 Schematisierung JSONSchema JSONSchema ist eine Beschreibungssprache für Schemata von JSON-Dokumenten [ 16 ]. Mit JSONSchema kann beispielsweise festgelegt werden, dass in einem Feld für eine Jahreszahl kein Buchstabe vorkommen darf. JSONSchema kann verwendet werden, wenn Objekte aus Datensätzen generiert werden und sorgt dafür, dass diese den vorgegebenen Regeln entsprechen. OpenAPI Interface Specification Um REST-Methoden und deren Aufruf-URLs zu dokumentieren, bietet sich die OpenAPI Interface Specification an [ 17 ]. Diese bietet, unter Verwendung entsprechender Frameworks, eine Sammlung aller über eine REST-Schnittstelle aufrufbaren Methoden an (siehe Abbildung 3.5). Abbildung 3.5: OpenAPI Beispiel Hierbei bietet die OpenAPI Interface Specification verschiedene Möglichkeiten und Tools an, um eigene APIs zu verwalten. Es können von Grund auf neue APIs erschaffen 22 3.3 Web Services oder bereits bestehende editiert werden. Zudem bietet Swagger die Möglichkeit, APIs zu schreiben und dann aus diesen APIs direkt Code zu generieren. Swagger bietet auch eine interaktive Dokumentation zu den APIs an, die dem Endnutzer zur Verfügung gestellt werden kann, sodass dieser sich einfacher in dem Programm zurechtfindet. Des Weiteren bietet Swagger eine Testumgebung für APIs an, mit denen eigene RESTMethoden aufgerufen und getestet werden können. Swagger kann zudem eine Einsicht in die Methoden gewähren und zeigt beispielsweise das erforderte JSON Format an, in dem Daten an einen bestimmten Endpunkt gesendet werden müssen. Aus diesem Schema des Aufrufs kann das Datenmodell hergeleitet, da diese Informationen meist auch den Aufbau bestimmter Datenklassen beinhalten. Weiterhin bietet Swagger auch die Option, Rückgabewerte an die eigenen Bedürfnisse anzupassen. So können HTTP Fehlercodes auf die eigenen Methoden und Fehlerfälle zugeschnitten genutzt werden, um dem Nutzer ein Gefühl dafür zu geben, wo der Fehler beim Aufruf lag. 3.3.3 URL Eine URL identifiziert und lokalisiert eine Ressource. Ein bekanntes Beispiel hierfür ist das adressieren von Seiten im Internet. Über die URL ist somit ein Pfad angegeben, wo die angezeigte Ressource (Website) liegt. Natürlich lassen sich mit URLs weit mehr als nur Internetadressen identifizieren. Durch Strukturierung bestimmter Teilkomponenten können beispielsweise genaue Identifikatioren zugewiesen werden. Für ein Auto gäbe es dann beispielsweise eine URL für den Motor: Auto://Motorinnenraum/Motor und eine URL für das rechte, hintere Rad: Auto://Räder/hinten/rechts. So können verschiedene Teile eines großen Ganzen genau lokalisiert und strukturiert werden. Beispielsweise kann sich ein Nutzer über die URL Auto://Räder alle Räder des Autos ansehen, da alle Räder diesem Pfad untergeordnet sind. 23 3 Grundlagen 3.3.4 Representational State Transfer (REST) REST bezeichnet ein Programmierparadigma für verteilte Systeme [ 18 ]. REST soll hierbei einen Architekturstil schaffen, der die Anforderungen des modernen Web besser darstellt. REST kann genutzt werden, um über das Internet Daten und Objekte zwischen weit entfernten Rechnern zu transferieren. Zum Beispiel kann über das HTTP-Protokoll mittels REST auf Funktionen auf anderen Rechnern zugegriffen werden. Diesen sogenannten REST-Calls kann dann noch ein Payload angehängt werden, der dann automatisch an das Zielsystem übertragen wird. So können beispielsweise mit JSON erstellte Datensätze zwischen Rechnern über das Internet ausgetauscht werden. Zudem bietet REST eine weitere Abstraktionsebene zwischen Client und Server (siehe Abbildung 3.6), sodass bei Codeänderungen eine Seite der Schnittstelle beibehalten werden kann, was einen angenehm wartungsfreundlichen Vorteil bietet. Da REST auf HTTP basiert, kann auf jeden Aufruf, beziehungsweise jede Anfrage eine Antwort vom anderen Rechner folgen, um den Ablauf der Aktion zu kommentieren. Beispiele für solche Antworten oder “Statuscodes” sind 200-OK oder 404-NOT FOUND, wenn die gesuchte Ressource, zum Beispiel ein Datum in einer Datenbank, nicht gefunden wurde. Vorgehensweise ohne REST ClientCode ServerCode Call Method Send Response Vorgehensweise mit REST ClientCode ServerCode REST Controller Call Endpoint Call Method Send Response Send Response Abbildung 3.6: Ablauf eines REST-Aufrufs 3.4 Spring Framework Das Spring Framework ist ein quelloffenes Dependency-Injection-Framework für Java, das die Modularisierung von Softwarekomponenten unterstützt [ 19 ]. Das Spring Fra24 3.4 Spring Framework mework bietet Hilfestellung bei dem gesamten Lifecycle einer Applikation. Spring Boot ermöglicht es, eine Applikation so schnell wie möglich und ohne großartige Konfiguration vorab lauffähig zu machen. Spring bietet hierbei einfache Möglichkeiten, beispielsweise mit wenig Aufwand einen REST-Service zu erstellen. Des weiteren bietet Spring einfache Werkzeuge, um eine SQLoder eine NoSQL-Datenbank mit der eigenen Applikation zu verknüpfen. Spring enthält auch Hilfsmittel, um Applikationen direkt in einer Cloud mittels microservice-style zu entwickeln. Zudem bietet Spring Werkzeuge an, die eigene Applikation mit Mobilgeräten oder einfachen Sensoren zu verbinden, sodass diese kommunizieren können. Dependency-Injection ist das Schlüsselwort, um die Parameter und Abhängigkeiten eines Objekt während der Laufzeit zu bestimmen. Dieses Framework bietet also die Möglichkeit, Objekten, die bei der Erstellung ein anderes Objekt benötigen, ein zentral hinterlegtes Objekt als Abhängigkeit zu übergeben, sodass das Objekt erstellt werden kann. So wird die Verantwortlichkeit für das Verwalten des Aufbaus der Abhängigkeiten zwischen den verschiedenen Java-Objekten an eine zentrale Komponente übergeben. Das Spring Framework bietet eine Vielzahl von Methodiken und Techniken, um verschiedene Java-Einsatzgebiete abzudecken [ 20 ]. Zudem bietet das Spring Framework einige Erweiterungen an, die für noch speziellere Fälle einfach zu dem bestehenden Framework hinzufügen werden können. Die verschiedenen Erweiterungen für das Spring Framework sind in Abbildung 3.7 dargestellt. Im Folgenden wird kurz aufgezeigt, wofür die einzelnen Erweiterungen genutzt werden können. Spring AMQP bietet Hilfsmittel, um AMQP-basierte Messaging-Lösungen zu entwerfen. Spring Batch bietet Möglichkeiten, robuste Batch-Programme zu entwickeln. Spring BeanDoc ist eine Erweiterung, die Spring Bean-Factories dokumentiert und Graphen auf den Daten der Beans erstellt. Spring Boot bietet einfache Werkzeuge um alleinstehende Applikationen zu programmieren, die so schnell wie möglich ausgeführt werden können. Spring Extensions bietet die Möglichkeit, eigene Spring-Erweiterungen einzubinden. Spring IDE ist ein Plugin für die Eclipse IDE, das bereits vorgefertigte Plugins für Eclipse enthält. Der Sinn hinter Spring Data ist es, ein einheitliches, Spring-basiertes Programmmodell zu entwickeln, mit dem der Zugriff auf Daten in einer Datenbank er25 3 Grundlagen leichtert wird. Spring LDAP bietet Hilfsmittel, mit Spring Applikationen zu entwickeln, die das Lightweight Directory Access Protocol nutzen. Spring Integration erweitert das Spring-Framework um eine Möglichkeit, Applikationen zu entwickeln, die Enterprise Integration Patterns nutzen. Spring OSGi bietet Werkzeuge, Spring Applikationen zu entwickeln, die das OSGi-Framework nutzen. Spring Social bietet eine Vereinfachung für den Zugriff auf verschiedene Social Networks. Spring Web Services hilft bei der Erstellung von Contract-First-Webservices. Spring Roo hilft bei der raschen Generierung von Spring-basierten Enterpriseanwendungen. Spring MVC bietet Möglichkeiten zur Erstellung von Webanwendungen. Spring Security (ehemals Spring Acegi) bietet Werkzeuge zur Absicherung von Java-Anwendungen und Webseiten. ColdSpring ColdFusion ist die Portierung des Spring-Frameworks auf die ColdFusion-Plattform. Spring for Android ist eine Erweiterung, die das Erstellen von nativen Android-Applikationen erleichtern soll. Spring Web Flow bietet Hilfe bei der Implementierung von Abläufen auf einer Webseite. Spring Rich-Client hilft bei der Erstellung von Rich Clients auf Basis des Spring-Frameworks. Spring BlazeDS ist die Open-Source-Lösung zur Erstellung von Spring-unterstützten RIA-Anwendungen mit Adobe Flex. Letztendlich bietet Spring .NET eine Portierung des Spring-Frameworks auf die .NET Plattform. Die beiden implementierten Erweiterungen werden im Folgenden genauer erläutert. 3.4.1 Spring Boot Spring Boot ist eine Erweiterung des Spring Frameworks, das den Anwender in der Programmierung selbstständig laufender Programme unterstützen soll. Solche Programme werden initial einmal angestoßen, laufen dann selbstständig weiter und warten beispielsweise auf Befehle oder Daten für die Verarbeitung. Mit solchen Programmen können auch REST-Schnittstellen betrieben werden, welche dauerhaft darauf warten, dass über die Schnittstelle Befehle eintreffen, die dann bearbeitet werden können. 26 3.4 Spring Framework Spring Framework Spring IDE Spring Integration Spring BeanDoc Spring Data Spring AMQP Spring OSGi Spring Extensions Spring LDAP Spring BlazeDS Spring MVC Spring Roo Spring Rich Client Spring Social Spring Web Flow Spring Security Spring Web Services ColdSpring ColdFusion Spring for Android Spring Batch Spring Boot Spring .NET Abbildung 3.7: Übersicht der Spring Framework Extensions 3.4.2 Spring Data Spring Data ist eine Erweiterung des Spring Frameworks, das die Anbindung an eine Vielzahl verschiedener Datenbanken über Java-Code ermöglicht. Mit Spring Data können Datenbanken direkt gesteuert werden und ihnen Befehle für Speichervorgänge oder die Suche auf Daten übermittelt werden. Aufgrund der einfachen Anbindung von Java-Code an die Datenbanken können alle wichtigen Vorgänge direkt im Java-Code gesteuert oder auch Datenbankoperationen in REST-Schnittstellen aufgelistet werden, sodass direkt über einen Befehl im Browser Änderungen in der Datenbank vollzogen werden. 27 4 Lösungskonzept Dieses Kapitel stellt ein Konzept zur Erstellung von Digital Twins unter Berücksichtigung der zuvor erhobenen Anforderungen vor. Diese Anforderungen werden zunächst ausgewertet, um einen genauen Überblick über das zu erstellende System zu erhalten. 4.1 Anforderungsauswertung Aus den bisher erfassten Anforderungen können bestimmte Funktionen abgeleitet werden, die das Projekt zur Erfüllung der Anforderungen enthalten muss. F1 Das System benötigt mehrere Parser, die die eingespeisten Daten zunächst in ein einheitliches Format überführen (hier z.B. JSON). F2 Es muss eine Möglichkeit geben, das System über Schnittstellen ansprechen zu können, sodass mehrere verschiedene Quellen Daten an das selbe System senden können. F3 Um die Daten des Digitalen Schattens, also Messwerte und Metadaten, verbinden zu können, wird eine Datenbank benötigt, die diese Beziehungen darstellen kann (hier z.B. Neo4j). F4 Um die Messdaten direkt an Module anheften zu können, wird eine generische Darstellung benötigt, die Daten frei verbinden kann. Dies kann direkt in der Datenbank geschehen. 29 4 Lösungskonzept F5 Um Daten selbstständig sammeln zu können, wird eine Schnittstelle benötigt, die im Programmcode angesprochen werden und empfangene Daten automatisch weiterverarbeiten kann. F6 Eine Datenbank muss gewisse Voraussetzungen erfüllen, um Daten strukturiert abspeichern zu können. Zudem wäre es von Vorteil, wenn die Datenbank selbst bereits Suchfunktionen auf den enthaltenen Daten anbietet (trifft beides auf Neo4j zu). F7 Eine Schnittstelle, mit der möglichst dynamisch gearbeitet werden kann, ist REST, daher wäre dies perfekt geeignet, um auch von mehreren Personen und Systemen gleichzeitig angesprochen zu werden. F8 Eine bereits integrierte Authentifizierungstechnologie ist in Neo4j enthalten. 4.2 Architektur In diesem Kapitel wird zunächst ein typischer Ablauf im System beschrieben. Daraufhin folgt eine Beschreibung der einzelnen Systemkomponenten. 4.2.1 Systemablauf Eine Maschine produziert während ihrer Laufzeit meist dauerhaft Sensordaten (z.B. Messwerte). Diese Sensordaten werden über einen Webservice an den Server gesendet. Der Server empfängt dann die Sensordaten und konvertiert diese in ein einheitlich benutzbares Format (z.B. JSON). Die Sensordaten werden dann nach der Konvertierung über den Datenbankconnector an die angeschlossene Datenbank gesendet. Diese Speichert die Sensordaten so ab, dass sie schnell und effektiv durchsucht werden und mit anderen, bereits bestehenden Datensätzen in Verbindung gebracht werden können. Ein Nutzer des Systems kann dann über einen Webservice die verknüpften Datensätze in einer Datenbank einsehen und Analysen und Suchen auf den Datensätzen ausführen. Nutzer können zudem auch manuell Daten über einen Webservice in die Datenbank einfügen. So können bestimmte Metadaten an z.B. Messwerte angefügt werden. 30 4.2 Architektur 4.2.2 Datenbankaufbau Im Folgenden werden die einzelnen Komponenten der Datenbankverbindung dargestellt. Datenschnittstelle Über die Datenschnittstelle kann der Code auf dem Server angesprochen werden (siehe Abbildung 4.1). Möchte ein Nutzer eine gewisse Funktion auf einem Server ausführen, muss dieser zunächst den Befehl an den Server übermitteln. Diesem Befehl müssen gegebenenfalls noch einige Nutzdaten mitgesendet werden, die der Server dann verarbeiten kann. Um dem Server einen Befehl zu übermitteln, muss der Nutzer mit diesem über eine Datenschnittstelle kommunizieren. Der Nutzer setzt zunächst einen Request (Anfrage) über die Datenschnittstelle ab. Dieser Request wird auf dem Server angenommen und weiterverarbeitet. Der Server setzt nun eine Anfrage ab, die vom Database-Connector empfangen wird. Dieser führt die geforderte Aktion auf der Datenbank aus und empfängt die Daten von der Datenbank. Diese Daten werden dann vom Server aufgenommen und über die REST-Schnittstelle an den Nutzer zurückgegeben. Neo4j-Datenmodell Mit Hilfe der graphenbasierten Datenbank Neo4j lassen sich Daten in einem graphbasierten Format abspeichern. Dabei wird das Datum als Knoten gehalten und kann mit jedem anderen Datum verbunden werden. So können beliebig komplexe Graphen aufgebaut werden, die nicht nur die Daten selbst, sondern auch ihre Beziehungen zueinander darstellen. Daten werden im System in einem Container gehalten. Dieser kann alle Daten darstellen, egal ob Messwert, Modul oder Sensor. Container werden anhand ihrer URL oder URI gekennzeichnet. Zudem können Container mit einem Label versehen werden, um darstellen zu können, worum es sich bei dem Datencontainer handelt (z.B. Messwert). Container sind untereinander mittels Relationships verbunden. Diese Relationships stellen dar, welche Container inwiefern zu einander in Relation stehen. 31 5 Realisierung Dieses Kapitel führt die Realisierung der vorher angegebenen Anforderungen auf und wie diese implementiert wurden. 5.1 Spring Class Management Das Spring-Framework bietet die Möglichkeit, bestimmte Java-Klassen mit verschiedenen Annotations zu markieren, um ihren Zweck in dem System festzulegen. Zum Beispiel bietet Spring Boot das Werkzeug, einen Entry-Point für das Programm zu bestimmen (siehe Listing 5.1). 1 @SpringBootApplication Listing 5.1: Entry Point Annotation Der Builder weiß somit genau, wo die Start-Klasse ist, bei der initial Code ausgeführt werden muss. Diese Klasse stößt dann mit ihren Methoden sämtliche anderen Prozesse im System an. Dabei kann auch festgelegt werden, welche Methoden zum initialen Build gehören, und welche erst nach dem Build ausgeführt werden sollen (siehe Listing 5.2). 1 @PostConstruct 2public void generateDeviceTree () throws IOException , URISyntaxException ) { Listing 5.2: Bestimmung ob Code vor oder nach dem Build ausgeführt werden soll Des Weiteren kann Spring Objekte aus einem zentralen Speicher nutzen, bevor sie im Code initiiert werden. Somit können Objekte mittels folgendem Code (siehe Listing 5.3) direkt genutzt werden und müssen nicht vorher über einen Konstruktor initiiert werden, für den vielleicht noch nicht alle Daten bereitliegen. 39 5 Realisierung 1 @AutoWired 2 ContainerRepository containerRepository ; Listing 5.3: Spring Annotation für REST Schnittstelle 5.2 REST-Schnittstelle Die REST-Schnittstelle wurde mit Hilfe von Spring und einigen OpenAPI-Annotations realisiert. Spring bietet hierbei mehrere Möglichkeiten zur Strukturierung einer solchen REST-Schnittstelle. Zunächst kann die Klasse, die die REST-Schnittstelle beinhaltet, mit einer simplen Annotation für den Spring-Controller markiert werden (siehe Listing 5.4). 1 @RestController 2public class CapeController { Listing 5.4: Spring Annotation für REST Schnittstelle Die einzelnen Methoden in dem Controller werden dann mit einer Annotation versehen, um einige Parameter festzulegen. So können sowohl der anzusteuernde Endpunkt als auch der Methodentyp im HTTP-Format festgelegt werden. Zusätzlich können den Methoden auch Daten in der URL oder als Payload mitgeschickt werden (siehe Kapitel 5.5). 1 @RequestMapping ( value = " / container / { id } " , method = RequestMethod .GET) 2public ResponseEntity <Container > getSpecificContainer ( @PathVariable ( " id " ) Long id ) { . . . } 3 4 @RequestMapping ( value = " / container " ,method = RequestMethod .POST) 5public ResponseEntity <Container > storeContainerPost (@RequestBody Container container ) { . . . } Listing 5.5: REST-Methoden-Annotation Die übertragenen Daten können dann entweder aus dem Pfad extrahiert werden (siehe Listing 5.6). 1 @PathVariable ( " id " ) Long id Listing 5.6: Spring Annotation für REST Schnittstelle oder im Format einer Java-Klasse direkt aus dem Body des HTTP-Calls (siehe Listing 5.7) 1 @RequestBody Container container Listing 5.7: Spring Annotation für REST Schnittstelle 40 5.3 Neo4j-Datenbank 5.3 Neo4j-Datenbank Danach wird die Datenbank einfach über eine Konsole initialisiert und kann dann über eine Weboberfläche, die standardmäßig über die URL localhost:7474 erreicht werden kann, genutzt werden. Auf dieser Weboberfläche können dann entweder die Daten selbst oder die Änderungen an den Daten eingesehen werden. Visualisiert werden können die Daten hierbei bereits als dynamischen Graph mit allen Knoten und Kanten. Diese Knoten können außerdem nach Belieben farblich markiert werden, um eine einfachere Übersicht zu erreichen. In der Weboberfläche können zudem auch Queries ausgeführt werden, um beispielsweise den Status der Datenbank abzufragen oder Daten hinzuzufügen oder zu manipulieren. 5.4 Datenbankschnittstelle mit Spring Spring bietet zusätzlich zu den bereits oben genannten Annotations weitere Markierungen, um beispielsweise die Datenklassen des Systems zu markieren. So können unter Anderem mit (siehe Listing 5.8) 1 @EnableNeo4jRepositories Listing 5.8: Repositories initiieren die vorliegenden Repositories geladen werden, um der Neo4j-Datenbank bereits die Struktur den eintreffenden Daten übergeben zu können. Außerdem können sich die Datenklassen, die hierfür in einem separaten Package liegen sollten, mit der Annotation (siehe Listing 5.9). 1 @EntityScan ( " cape . neo4j . model" ) Listing 5.9: Scan nach Datenklassen selbstständig scannen lassen, sodass Neo4j und Spring bereits die datenbeinhaltenden Klassen von den rein funktionalen Klassen unterscheiden können. Die bereits erwähnten Repositories sind vorgefertigte Interfaces und bieten die Methoden, 41 5 Realisierung die genutzt werden, um mit der Datenbank zu kommunizieren. Sie werden mit der folgenden Annotation versehen (siehe Listing 5.10), sodass über den REST-Client der Status eines Repositories abgefragt werden kann. In diesem Beispiel wird markiert, dass es sich um das Repository handelt, das die Datenklasse ”Container” verwaltet. 1 @RepositoryRestResource ( path = " containers " ) Listing 5.10: Repository Annotation Ein gesamtes Repository ist in Abbildung 5.11 dargestellt. 1 @RepositoryRestResource ( path = " containers " ) 2public interface ContainerRepository extends PagingAndSortingRepository <Container , Long> { 3 Container findByName ( St ri ng name ) ; 4 5 Container findOne ( Long id ) ; 6 7 L ist <Container > f i n d A l l ( ) ; 8 9 Container f ind ByU ri ( URI u r i ) ; 10 11 @Query( "CALL algo . betweenness . stream ( ’ { containerType } ’ , ’ { edgeType } ’ ,{ d i re cti on : ’ { di rec tio n } ’ } ) \ n" + 12 "YIELD nodeId as id1 , c e n t r a l i t y \ n" + 13 "MATCH ( n : Container ) \ n " + 14 "WHERE ID ( n) = id1 \ n" + 15 "RETURN n , c e n t r a l i t y order by c e n t r a l i t y desc l i m i t 20; " ) 16 I terable <Map<String , Integer >> calculateBetweenness ( String containerType , String edgeType , String di rec tio n ) ; 17 18 @Query( "MATCH ( n : Container ) WHERE NOT ( n)<−[:HAS_COMPONENT]−() RETURN n" ) 19 List <Container > findRootNodes ( ) ; 20 } Listing 5.11: Repository Hierbei ist zu sehen, dass das Repository von einem sogenannten ”PagingAndSortingRepository” abstammt. Dieses bietet Neo4j die Möglichkeit, Daten seitenweise sortiert zurückzugeben (siehe Listing 5.12). 1public interface ContainerRepository extends PagingAndSortingRepository <Container , Long>{ Listing 5.12: PagingAndSortingRepository Des Weiteren sind hier die von Spring Data vorgegebenen Standardmethoden zu sehen, wie ”findByName” oder ”findOne”. Diese Methoden werden von Spring erkannt und ohne weiteren Aufwand für den Programmierer passend auf die Daten verlinkt (siehe Listing 5.13). 42 5.5 API-Übersicht mit OpenAPI 1 Container findByName ( Str in g name ) ; 2 Container findOne ( Long id ) ; Listing 5.13: Standardmethoden von Spring Data Sollten diese Methoden nicht genügen oder sollten bestimmte Algorithmen ausgeführt werden müssen, bietet das Framework die Werkzeuge, eigene Methoden aus Queries zu bauen. So finden sich in dem Repository Methoden mit der Annotation ”@Query” wieder, welche die in Neo4j auszuführende Query enthalten (siehe Listing 5.14). 1 @Query( "MATCH ( n : Container ) WHERE NOT ( n)<−[:HAS_COMPONENT]−() RETURN n" ) 2 List <Container > findRootNodes ( ) ; Listing 5.14: Query Annotation So muss vom Programmierer nur der Rückgabetyp und der Name der Methode festgelegt werden, um das gewünschte Ergebnis zu erzielen. Aus solchen Queries heraus können auch in Neo4j gespeicherte Algorithmen ausgeführt werden, wie in diesem Beispiel der ”betweenness”-Algorithmus. Diesem werden im Methodenaufruf auch direkt Parameter übergeben, die dann automatisch in die Query eingesetzt werden (siehe Listing 5.15). 1 @Query( "CALL algo . betweenness . stream ( ’ { containerType } ’ , ’ { edgeType } ’ ,{ d ire cti on : ’ { di rec tio n } ’ } ) \ n" + 2 "YIELD nodeId as id1 , c e n t r a l i t y \ n" + 3 "MATCH ( n : Container ) \ n " + 4 "WHERE ID ( n) = id1 \ n" + 5 "RETURN n , c e n t r a l i t y order by c e n t r a l i t y desc l i m i t 20; " ) 6 I terable <Map<String , Integer >> calculateBetweenness ( String containerType , String edgeType , String di rec tio n ) ; Listing 5.15: Query Annotation für Algorithmen 5.5 API-Übersicht mit OpenAPI OpenAPI bietet die Möglichkeit, die bereits annotierten REST-Methoden mit einigen Parametern zu beschreiben um daraus eine API-Dokumentation generieren zu lassen (siehe Listing 5.16). 1 @ApiOperation ( value = " showAllContainers " , notes = " Prints out a l l containers in the database " , 2 response = String . class , responseContainer = " L is t " , tags = " container " ) Listing 5.16: OpenAPI Annotation 43 5 Realisierung Hierbei lassen sich einige Werte wie der dargestellte Methodenname (value), ein eigener Kommentar (notes), den Rückgabetyp direkt als Java-Class (response), bestimmte Modifikationen des Rückgabetyps, z.B. eine Liste oder ein Array (responseContainer) und Tags festlegen, aus denen dann eine vollständig dokumentierte API generiert werden kann. Um zu beeinflussen, wie die API nachher dargestellt wird, lässt sich dies mit Hilfe einer Config-Klasse verändern (siehe Listing 5.17). 1 @Configuration 2 @EnableSwagger2 3public class SwaggerConfig { 4 5 @Bean 6public Docket api ( ) { 7return new Docket ( DocumentationType .SWAGGER_2) 8 . sel ec t ( ) 9 . apis ( RequestHandlerSelectors . any ( ) ) 10 . paths ( PathSelectors . any ( ) ) 11 . build ( ) ; 12 } 13 14 private Ap iIn fo a piIn fo ( ) { 15 return new ApiInfo( 16 " CaPe_Neo4j_Rest_API " , 17 " This is the API of the CaPe_Neo4j−project" , 18 " 0.1 " , 19 "These are some custom TermsOfService " , 20 new Contact ( " John Doe" , "www. example .com" , "myeaddress@company .com" ) , 21 " License of API " , " API license URL" , Collections . emptyList ( ) ) ; 22 } 23 } Listing 5.17: OpenAPI Config Hierbei kann der Documentation-Type verändert werden oder Informationen über die API, das System und den Herausgeber hinzugefügt werden. 5.6 Zusammenfassung Der in Kapitel 4 konzipierte Lösungsansatz konnte mit Hilfe des Spring-Frameworks prototypisch umgesetzt werden. Spring Data bietet eine große Hilfestellung bei der Kommunikation eines Systems mit einer Datenbank. Zusätzlich ist das Spring-Framework im Bezug auf die Programmierung von REST-Schnittstellen sehr nützlich. Hier bietet die 44 5.6 Zusammenfassung OpenAPI zudem viele Möglichkeiten, die genutzten REST-Methoden zu dokumentieren und im Programmcode zu strukturieren. 45 6 Evaluierung In diesem Kapitel folgt die Gegenüberstellung der Problemstellung und der Use Cases mit dem fertigen Prototypen. Inwiefern das Projekt die geforderten Funktionalitäten umsetzt, wird anhand einer Tabelle aufgeführt. Tabellen 6.1 und 6.2 führen alle Anforderungen auf, die das erarbeitete Systemkonzept umsetzen soll (siehe Kapitel 2). Diese funktionalen Anforderungen wurden in dem System wie in Tabelle 6.3 umgesetzt, die nicht-funktionalen Anforderungen wie in Tabelle 6.4. 47 7 Verwandte Konzepte Softwares, die die Bedienung einer Maschine ermöglichen, miteinander verbinden können. Das Unternehmen Cumulocity sorgt mit seiner Implementierung dafür, dass die Daten geschützt werden und für Analysen aufbereitet werden können. Cumulocity bietet bereits integrierte Real-Time-Streaming Analysen, die ein effektives Werkzeug für z.B. Predictive Maintenance darstellen können. 7.2 Watson IoT Die Firma IBM hat mit Hilfe ihres KI-Tools Watson eine eigene Implemetierung für eine IoT-Lösung entwickelt [ 23 ]. Die IoT-Lösung von IBM enthält unter anderem Teile wie die Erstellung eines Digitalen Zwillings oder den Einbau einer Blockchain für zusätzliche Sicherheit. Durch diese Blockchain können beispielsweise Möglichkeiten realisiert werden, wie Geschäftspartner auf IoT-Daten einer nutzenden Firma zugreifen können, ohne eine zentrale Verwaltungsoder Managementstelle zu benötigen. Durch das Einbinden von IBM Watson bietet diese IoT-Lösung auch KI-getriebene Ansätze wie die kognitiv unterstützte Defektsuche bei produzierten Teilen. So kann diese Lösung über das Vergleichen von optischen Sensorwerten mit zuvor eingespeisten Mustern Defekte in Produkten erkennen, die einem Menschen nur schwer auffallen würden. 7.3 AWS IoT Amazon bietet auf Basis der Amazon Web Services (AWS) eigene IoT-Lösungen an [ 24 ]. Diese können entweder als Infrastructure as a Service (IaaS-), Platform as a Service (PaaS-) oder als Software as a Service (SaaS-) Lösungen bezogen werden (siehe Abbildung 7.1). Das Produkt AWS IoT Core von Amazon kann die Kommunikation von verschiedenen Geräten ermöglichen, selbst wenn diese unterschiedliche Protokolle zur Datenübertragung 54 7.3 AWS IoT nutzen. Dabei kann AWS IoT Messages von verschiedenen Inputs entgegennehmen, diese auswerten und an verschiedene Outputs weiterleiten. Dort können dann andere Dienste von AWS wie zum Beispiel AWS Lambda die Nachrichten entgegennehmen und anhand dieser bestimmte Funktionen ausführen. So kann mit AWS IoT schnell und einfach eine simple Lüftersteuerung mit eingehenden Temperaturdaten realisiert werden [24]. Zusätzlich bietet Amazon mit AWS Greengrass die Möglichkeit, Geräte auch ohne Verbindung zum Internet über ein lokales Netzwerk kommunizieren zu lassen, um so schnell und unabhängig auf lokale Events reagieren zu können. Außerdem können eventuell gespeicherte Daten mit Amazon S3 mit einer hohen Beständigkeit gespeichert und sicher und direkt abgefragt werden. Amazon S3 bietet unter anderem die Möglichkeit, komplexe Big-Data-Analysen auf den Daten ausführen zu können, ohne die Daten in ein separates Analysesystem verschieben zu müssen. Die Daten in Amazon S3 können mittels Amazon Athena on-demand mit SQL abgefragt werden. Amazon S3 Select bietet zusätzlich die Möglichkeit, nur Teildatensätze aus der Datenbank abzurufen, um so die Leistung der meisten Anwendungen, die häufig auf Daten in S3 zugreifen, um bis zu 400% zu steigern. Für weitere Informationen zu AWS oder für Hilfe bei der Implementierung eigener AWS kann das Werk “Programming Amazon Web Services” von James Murty hinzugezogen werden [25]. 55 7 Verwandte Konzepte Anwendung Sicherheit Datenbanken Betriebssysteme Virtualisierung Server Datenhaltung Netzwerk Datencenter Anwendung Sicherheit Datenbanken Betriebssysteme Virtualisierung Server Datenhaltung Netzwerk Datencenter Anwendung Sicherheit Datenbanken Betriebssysteme Virtualisierung Server Datenhaltung Netzwerk Datencenter Infrastructure as a Service (IaaS) Platform as a Service (PaaS) Software as a Service (SaaS) Anwendung Anwendung Vom Kunden verwaltet Vom Provider verwaltet z.B. AWS IoT 1-Click z.B. AWS IoT Analytics z.B. Amazon FreeRTOS Abbildung 7.1: Übersicht der AWS-Produkte 56 8 Zusammenfassung und Ausblick 8.1 Zusammenfassung Die Problemstellung umfasste das Problem, dass physische Objekte digitalisiert werden sollten. Dieser digitale Zwilling soll dann mit Messdaten und Metadaten des Objekts angereichert werden, um eine möglichst funktionale und eine möglichst realitätsnahe Abbildung des Objektes zu realisieren. Das erarbeitete Konzept beinhaltet die Möglichkeit, mittels einer Java-Anwendung und einer Datenbank einen digitalen Zwilling zu erzeugen und zugehörige Messund Metadaten zu speichern. Dazu ist eine einfache Kommunikation mit dem System über eine Webservice-Schnittstelle möglich. So können sowohl Maschinen ihre Messdaten selbstständig über die Webservice-Schnittstelle an das System übermitteln, als auch Nutzer mit dem System kommunizieren, um administrative Aufgaben auszuführen oder Daten manuell hinzufügen oder löschen zu können. Der erstellte Prototyp setzt die Anforderungen des Konzeptes und der Problemstellung um. Der Prototyp nutzt ein Spring-Framework, um eine effektive Ausführbarkeit und eine einfache Anbindung an die Datenbank zu realisieren. Als Datenbank wurde die graphorientierte Neo4j-Datenbank verwendet, um die Daten in der Datenbank in Relation setzen zu können und so beispielsweise Messdaten mit ihren jeweils zugehörigen Sensoren verbinden zu können. Mit dem Prototyp kann zusätzlich über eine RESTSchnittstelle kommuniziert werden, um Daten hinzuzufügen, zu ändern, zu löschen oder Algorithmen (z.B. zur Zentralität der einzelnen Knoten im Graphen) auf den Datensätzen ausführen zu können. 57 8 Zusammenfassung und Ausblick 8.2 Ausblick Das System setzt die bisherigen Anforderungen gut um. Jedoch werden in der Zukunft weitere Funktionen von dem System gefordert. Demnach ist das System noch nicht zu 100% ausgebaut. Des Weiteren gibt es noch manche Punkte, die eventueller Nachbesserung bedürfen. So können sicherlich noch einige Performanceverbesserungen am Code vorgenommen werden. Zusätzlich wäre es von Vorteil, wenn zunächst eine performantere Lösung für die Parser gefunden werden könnte, da diese momentan einen Flaschenhals (engl.: Bottleneck) darstellen: Das initiale Laden der Daten läuft nicht so schnell ab, wie initial gewünscht war. Des Weiteren sollten die Parser auf mehr verschiedene Systeme und Formate ausgeweitet werden, um so viele Formate wie möglich verarbeiten zu können. Eine andere Erweiterung stellt die Möglichkeit dar, die zugrundeliegenden Graphen für Analysezwecke gewichten zu können. So können Graphen für verschiedene Analysezwecke nach unterschiedlichen Vorgaben gewichtet werden, um ein präziseres Ergebnis zu erzielen. 58 Literaturverzeichnis [1] Jeschke, S., Brecher, C., Song, H., Rawat, D.: Industrial Internet of Things: Cybermanufacturing Systems. Springer Series in Wireless Technology. Springer International Publishing (2016) [2] Hehenberger, P., Bradley, D.: Mechatronic Futures: Challenges and Solutions for Mechatronic Systems and their Designers. Springer International Publishing (2016) [3] Farhangi, H.: The Path of the Smart Grid. IEEE Power and Energy Magazine 8 (2010) 18–28 [4] Reichert, M., Weber, B.: Enabling Flexibility in Process-Aware Information Systems: Challenges, Methods, Technologies. Springer (2012) [5] Maier, S.C., Todte, H.: Telematik–eine Revolution in der Kfz-Versicherung. Zeitschrift für Versicherungswesen 23 (2013) 776–782 [6] ADAC: ADAC Pannenstatistik 2017. https://www.adac.de/infotestrat/ unfall-schaeden-und-panne/pannenstatistik/ (2017) Zugriffsdatum: 07.03.2018. [7] Daki´ c, D., Arh, D.: Nuget2 Essentials. Packt Publishing (2013) [8] Media, S.: Maven: The Definitive Guide. O’Reilly (2009) [9] McCullough, M., Berglund, T.: Building and Testing with Gradle. O’Reilly (2011) [10] Siemens: Der Digitale Zwilling. https://www. siemens.com/customer-magazine/de/home/industrie/ digitalisierung-im-maschinenbau/der-digitale-zwilling.html (2017) Zugriffsdatum: 27.02.2018. [11] Lal, M.: Neo4j Graph Data Modeling. Packt Publishing (2015) [12] Chhajed, S.: Learning ELK Stack. Packt Publishing (2015) [13] Haas, B.: W3C Web-Services. Website (2004) 59 Literaturverzeichnis [14] Bray, T., Paoli, J., Sperberg-McQueen, C.M., Maler, E., Yergeau, F.: Extensible Markup Language (XML). World Wide Web Journal 2(1997) 27–66 [15] Severance, C.: Discovering JavaScript Object Notation. Computer 45 (2012) 6–8 [16] Pezoa, F., Reutter, J.L., Suarez, F., Ugarte, M., Vrgoˇ c, D.: Foundations of JSON Schema. In: Proceedings of the 25th International Conference on World Wide Web. WWW ’16, International World Wide Web Conferences Steering Committee (2016) 263–273 [17] Mulligan, C.: Open API Standardisation for the NGN Platform. In: 2008 First ITU-T Kaleidoscope Academic Conference - Innovations in NGN: Future Network and Services. (2008) 25–32 [18] Balachandar, B.: RESTful Java Web Services: A pragmatic guide to designing and building RESTful APIs using Java. Packt Publishing (2017) [19] Johnson, R., Hoeller, J., Donald, K., Sampaleanu, C., Harrop, R., Risberg, T., Arendsen, A., Davison, D., Kopylenko, D., Pollack, M., et al.: The Spring Framework– Reference Documentation. Interface 21 (2004) 27 [20] Johnson, R., Höller, J., Arendsen, A., Risberg, T., Sampaleanu, C.: Professional Java Development with the Spring Framework. Wiley (2007) [21] Masak, D.: Moderne Enterprise Architekturen. Xpert.press. Springer (2006) [22] SoftwareAG: Cumulocity Homepage. https://www.cumulocity.com (2017) Zugriffsdatum: 08.04.2018. [23] IBM: IBM Watson IoT Cognitive Processes. https://www.ibm. com/internet-of-things/industries/iot-manufacturing/ cognitive-process (2018) Zugriffsdatum: 18.05.2018. [24] Amazon: AWS IoT. https://aws.amazon.com/de/iot/ (2018) Zugriffsdatum: 18.05.2018. [25] Murty, J.: Programming Amazon Web Services: S3, EC2, SQS, FPS, and SimpleDB. O’Reilly Series. O’Reilly (2008) 60 Abbildungsverzeichnis 2.1 Anwendungsfalldiagramm Produktionsmaschinen . . . . . . . . . . . . . . 6 2.2 Auszug der Datenstruktur eines PKW . . . . . . . . . . . . . . . . . . . . 9 2.3 Beispielhafter Dependency Graph . . . . . . . . . . . . . . . . . . . . . . 11 3.1 Beispielhafter Digitaler Schatten einer Maschine . . . . . . . . . . . . . . 16 3.2 Aufbau Datenbankmanagementsystem . . . . . . . . . . . . . . . . . . . 17 3.3 Beispielgraph.................................. 19 3.4 Beispiel der Kibana Oberfläche . . . . . . . . . . . . . . . . . . . . . . . . 20 3.5 OpenAPIBeispiel................................ 22 3.6 Ablauf eines REST-Aufrufs . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.7 Übersicht der Spring Framework Extensions . . . . . . . . . . . . . . . . . 27 4.1 REST-Sequenzdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.2 Datenmodell .................................. 33 4.3 Datenbankconnector.............................. 34 4.4 Systemarchitektur ............................... 34 4.5 Komponentendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.6 Vollständiges Klassendiagramm des Systems . . . . . . . . . . . . . . . . 36 4.7 Lösungskonzept Use Case 1 . . . . . . . . . . . . . . . . . . . . . . . . . 37 7.1 Übersicht der AWS-Produkte . . . . . . . . . . . . . . . . . . . . . . . . . 56 61 Tabellenverzeichnis 2.1 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2 Nicht-funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . 13 3.1 Relationaler Beispieldatensatz . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1 Funktionale Anforderungen an das System . . . . . . . . . . . . . . . . . 48 6.2 Nicht-funktionale Anforderungen an das System . . . . . . . . . . . . . . 49 6.3 Umsetzung der funktionalen Anforderungen . . . . . . . . . . . . . . . . . 50 6.4 Umsetzung der nicht-funktionalen Anforderungen . . . . . . . . . . . . . . 51 63