Schlüsselwörter

1 Konzept des Demonstrators

Das zentrale Ziel des Forschungsvorhabens AKKORD ist die Entwicklung eines Referenzbaukastens für die industrielle Datenanalyse (siehe Kap. 1 und 2). Der Backend-Demonstrator soll ein greifbares und leicht verständliches Beispiel für die in diesem Vorhaben entwickelten Lösungskomponenten aus dem Bereich Datenbackend liefern. In Kap. 4 wurde der entwickelte Referenzbaukasten mit seinen Bausteinen vorgestellt. Konkret sollen die in den entsprechenden Beiträgen vorgestellten Bausteine des Referenzbaukastens demonstriert werden (siehe Kap. 5 und 6). In diesem Kontext dient eine Modellautorennbahn aus der Digital 132 Serie als Lieferant für Daten, auf die zunächst mit einem Datenzugriffsbaustein zugegriffen wird. Die einzelnen Modellautos wurden in diesem Kontext als Internet of Things (IoT)-Datenquellen interpretiert, die Daten in der Form von Zeitstempeln für Zwischen- und Rundenzeiten und simulierten Tankfüllständen liefern. Gerade in dieser Phase liegt ein besonderer Fokus auf der Gewährleistung einer durchgängigen Datenanalysequalität (West et al., 2021, S. 131 ff.). Die somit verfügbar gemachten Daten werden auf verschiedenen Wegen in einem Datenbackend abgespeichert. Anschließend werden die dort gespeicherten Daten für die Datenanalyse verfügbar gemacht. Der Aufbau des Demonstrators ist hierbei größtenteils mit dem in Kap. 18 beschriebenen Demonstrator für die Analysebausteine identisch, da zu Vergleichszwecken das gleiche Rennbahnmodell beschafft wurde. Eine detaillierte Beschreibung der verfolgten Anwendungsszenarien ist dort zu finden. In diesem Kapitel soll dementsprechend der Fokus auf dem technischen Aufbau, sowie den eingesetzten Protokollen und Technologien liegen. Der generelle Aufbau des Szenarios aus Backend-Sicht ist in Abb. 17.1 dargestellt.

Abb. 17.1
figure 1

Bausteine des Demonstrators

Full size image

Zu Testzwecken wurden an den Standorten der beteiligten Forschungspartner in Dortmund und Kaiserslautern jeweils eine Rennbahn in Betrieb genommen. Die Daten der Bahnen wurden über eine optional verfügbare Bluetooth-Schnittstelle ausgelesen und per Netzwerk an das Datenbackend gesendet. Dort können die Daten angereichert und mit weiteren Datenquellen verknüpft werden. Anschließend erfolgt die Weitergabe an die Analysebausteine. Diese konzeptionellen Schritte werden im Folgenden detaillierter beschrieben.

2 Auslesen und Übertragen der Daten

Die eingesetzte Produktreihe ermöglicht es, Daten über ein Bluetooth-Modul an mobile Endgeräte zu übertragen, um beispielsweise mit der offiziellen Smartphone-App des Herstellers die Rangliste des laufenden Rennens zu verfolgen. Die Daten stehen aber auch anderen Endgeräten zur Verfügung. So ermöglicht die Python-Bibliothek carreralib (github.com/tkem/carreralib) das Empfangen der Daten über standardkonforme Bluetooth-Hardware. Im Kontext des Backend-Demonstrators erfüllt ein RaspberryPi diese Rolle. Ein eigens entwickeltes Python-Skript liest die gesendeten Daten aus und bereitet sie für die Übertragung an das Datenbackend vor. Im Hinblick auf den Analysebaustein-Demonstrator wurde dieses Skript um die Eingabe von Fahrerdaten ergänzt. Diese Vorgehensweise ähnelt den typischen Ansätzen zum Retrofitting in industriellen Anwendungsfällen, in denen häufig auch gezielt Low-Cost-Sensorik verwendet wird (Wöstmann et al., 2019, S. 94 ff.).

Alle verfügbaren Daten werden in einem JSON-Datensatz gesammelt und unter Verwendung des MQTT-Protokolls versendet. Die Verwendung einer solchen Standard-Schnittstelle ermöglicht unterschiedliche Endpunkte für diese Übertragung: So wurde zu Testzwecken zunächst ein bereits vorhandener MQTT-Broker angebunden, an dem die empfangenen Daten in Echtzeit ausgelesen werden konnten. Nach Sicherstellung der grundlegenden Funktionalität wurden zwei weitere MQTT-Broker hinzugefügt, die jeweils in die Software-Produkte Contact Elements for IoT und InfluxDB integriert laufen. Um maximale Autonomie des Demonstrators, beispielsweise bei Messebesuchen sicherzustellen, wurde schließlich auch eine in Kap. 18 beschriebene Anbindung an MariaDB realisiert. Diese etappenhafte Entwicklung liegt einerseits in verschiedenen praktischen Entscheidungen aus der Entwicklungsphase des Projekts begründet, spiegelt gleichzeitig aber auch den modularen Ansatz des entwickelten Referenzbaukastens wieder, da hier einzelne Lösungselemente passend für den anvisierten Einsatzzweck ausgewählt und gegeneinander ausgetauscht werden können.

3 Verwaltung der Daten im Backend

Die hauptsächliche Verwaltung der Daten erfolgt in der Software Contact Elements for IoT. Dort ist entsprechend des in Kap. 5 beschriebenen Ansatzes eines zentralisierten Datenbackends eine hochgradige Verknüpfung der Daten der Rennbahn mit beispielsweise PLM-Stammdaten zu den einzelnen Fahrzeugtypen vorgesehen. Für jedes Auto an einer der beiden Rennbahnen wurde ein sogenanntes IoT-Asset angelegt. In einem solchen Asset können Daten über den Standort und die Betriebsbereitschaft des Assets hinterlegt werden. Zusätzlich existiert für jedes IoT-Asset die Möglichkeit, Zeitreihendaten in einer angebundenen Zeitreihendatenbank abzuspeichern, was im Kontext des Demonstrators für die Speicherung der per MQTT empfangenen Daten genutzt wurde. Die Anzeige einer solchen Zeitreihe in der Contact-Oberfläche ist in Abb. 17.2 dargestellt.

Abb. 17.2
figure 2

Darstellung einer Zeitreihe in Contact Elements for IoT

Full size image

Zusätzlich stehen die Vernetzungsmöglichkeiten der Contact Elements Plattform mit dem im Rahmen des Projekts ausdetaillierten Verknüpfungsmöglichkeiten zur Verfügung. Darüber hinaus können für verwaltete Assets interaktive Dashboards zusammengestellt werden, die über die aktuell empfangenen Daten informieren.

4 Weitergabe an die Analysemodule

Das bislang beschriebene Vorgehen zur Verwaltung orientiert sich am Ansatz für ein zentralisiertes Datenbackend (siehe Kap. 5). Um eine größere Bandbreite der entwickelten Lösungsbausteine darstellen zu können, wurde dieser für die Weitergabe der Daten an die Analysebausteine mit einem dezentralen Ansatz im Sinne von (siehe Kap. 5) verknüpft. Im Kontext dieses Ansatzes ist Contact Elements wiederum eine Datenquelle, welche über die an der Rheinland-Pfälzischen Technischen Universität entwickelte SP2IDER-Plattform angebunden ist.

Am Aufbau des Demonstrators lassen sich die in Abb. 17.3 dargestellten Schritte zum Aufbau der Datenanbindung nachverfolgen: Über einen entsprechenden Connector können die Daten als JSON oder CSV ausgelesen werden. Anschließend können sie im Data Model Canvas einem Datenbedarf gegenübergestellt werden. Die Definition des Datenbedarfs erfolgt hierbei durch eine JSON-Datei, die in der Gegenüberstellung um URLs für den Zugriff auf die ausgewählten Daten ergänzt wird. Diese Datei wird anschließend an die von RapidMiner entwickelte ISGAT-Schnittstelle übergeben, um die Weitergabe an die in RapidMiner AI Hub verwalteten Analysebausteine zu ermöglichen.

Abb. 17.3
figure 3

Anbindung von Datenquellen im Autorenn-Demonstrator

Full size image

5 Fazit

Der Datenbackend-Demonstrator zeigt die praktische Umsetzung, der im Rahmen von AKKORD entwickelten Ansätze zum Aufbau einer Backend-Lösung. Die sich daraus ergebende Lösung wird in einem folgenden Schritt mit den Baustein „Datenanalyse“ und „Datennutzung“ integriert, um ein durchgängiges Anwendungsbeispiel für den AKKORD-Referenzbaukasten aufzuzeigen. Im Hinblick auf das eingesetzte Datenbackend können prinzipiell alle in Kap. 5 vorgestellten Ansätze verfolgt werden möglich. Insbesondere der Data Warehouse-Ansatz wurde im Rahmen der industriellen Anwendungsfälle des Projekts erprobt. Alle entwickelten Ansätze lassen sich im Hinblick auf den produktiven Einsatz in Unternehmen auf die individuellen Bedürfnisse und Gegebenheiten eines interessierten Unternehmens anpassen. Die Möglichkeiten, Backend-Bausteine im Unternehmenskontext einzusetzen, werden am Ende von Kap. 5 kurz aufgezeigt.