Kapitel 2: Verarbeitung der Daten

Aufnahme über den IoT Core

Wie bereits in Kapitel 1 erwähnt, erhalten wir alle eingehenden Maschinen-Daten im JSON-Format über das MQTT-Protokoll. Damit diese reibungslos in die Cloud-Architektur aufgenommen werden können, fungiert zu Beginn der IoT Core als sogenannter Broker, der in unserem Fall alle Nachrichten eines bestimmten Topics aufnimmt. Das Topic wird vor dem Senden einer Nachricht angegeben und dient dabei als eine Art Zielordner eines Dateisystems. Abhängig nach bspw. der Anzahl der Maschinen oder Sensoren kann somit in verschiedene Pfade unterteilt werden. Über vorab definierte Regeln ist der IoT Core anschließend in der Lage, alle ankommenden Nachrichten an die entsprechenden Services weiterzuleiten.

Der IoT Core bietet an dieser Stelle den Vorteil, dass er die ankommenden JSON-Daten als solche erkennt und ohne weitere Anpassungen im selben Format weitergibt. Gleichzeitig ist für uns die unkomplizierte Anbindung an weitere AWS-Dienste von großer Bedeutung. Somit sind wir in der Lage, Sensordaten, die nicht weiterverarbeitet werden müssen, direkt an den Elasticsearch Service zur finalen Visualisierung weiterzugeben. Zusätzlich landen diese ebenfalls direkt in einem S3-Bucket zur persistenten Speicherung. Diese unbearbeiteten Daten spiegeln vor allem den aktuellen Zustand der Maschine wider. Des Weiteren gehen gleichzeitig Sensordaten, die vorab für Berechnungen benötigt werden, an eine Lambda-Function.

Da die Verbindung zwischen Industrie-Maschine und IoT Core außerhalb unserer Cloud-Infrastruktur erfolgt, muss eine sichere Kommunikation gewährleistet werden. In unserem Showcase nutzen wir daher eine MQTT-Verbindung über TLS 1.2 mit X.509 basierter Zertifikat-Authentifizierung. Eine Verbindung erfolgt daher nur, wenn ein gültiges Zertifikat mit dazu passendem Schlüssel vorliegt. Gleichzeitig arbeiten wir mit einer ID-zugewiesenen Topic-Richtlinie, die bei jeder Verbindung zusätzlich definiert sein muss.

Anpassungen über eine Lambda-Function

Eine Lambda-Function ermöglicht die Ausführung von Programmcode, ohne selbst dafür Server zur Verfügung stellen zu müssen. Der Code muss hierbei nur ein einziges Mal in einer, von AWS unterstützten, Programmiersprache geschrieben werden. Anschließend wird dieser durch den Eingang jeder einzelnen Nachricht getriggert und somit dynamisch ausgeführt. Die Nachrichten, die dabei eingehen, sind genau dieselben, die der IoT Core weitergeleitet hat.

Das Augenmerk unserer Visualisierungen liegt auf der Darstellung einiger Durchschnittswerte, die dem Betrachter eine bestmögliche Tendenz geben sollen, zu welchem Zeitpunkt die maximale Laufleistung einer Maschinenkomponente voraussichtlich erreicht ist. Damit sich dieser Orientierungspunkt bilden kann, sammeln wir kontinuierlich alle maximal erreichten Laufleistungen jeder einzelnen Maschinenkomponente und verrechnen diese auf die Anzahl ihrer jeweiligen Wechsel. Auf lange Sicht betrachtet, erhalten wir hiermit eine ziemlich genaue Einschätzung für einen vorhersehbaren und optimalen Komponentenwechsel. Es kann also ein reibungsloser Wartungsaufwand prognostiziert werden, der sich als zeit- und ressourcensparend darstellt.

Unsere Lambda-Function zur Durchschnittsberechnung geht dabei nach einem bestimmten Schema vor:

  • Ein aktueller Datensatz als Vergleichsrechnung ist für genau einen weiteren Durchlauf gespeichert.
  • Es wird überprüft, ob der neu eintreffende Datensatz eine geringere Laufleistung (bspw. 0) als der Letzte, vorher abgespeicherte, aufweist.
    • Falls: Nein -> Die Laufleistung ist wie erwartet gestiegen. Die Maschine befindet sich im Normalbetrieb.
    • Falls: Ja -> Es liegt ein Wechsel an der Maschinenkomponente vor. Die festgestellte maximale Laufleistung aus dem letzten Datensatz wird abgespeichert und zu neuen Berechnungen herangezogen.
  • Der gespeicherte Datensatz zur Vergleichsrechnung wird mit neuen Werten überschrieben.
  • Die als Array gebündelten Maschinendaten der Laufleistung werden entsprechend aufgeteilt, um sie verarbeitungskonform nach Elasticsearch Service übertragen zu können.
  • Zu den jeweils aktuellen Laufleistungen werden Durchschnittswerte, sowie Restlaufleistungen angefügt und sowohl an Elasticsearch Service, als auch an einen S3-Bucket übergeben.

Da sich Variablen über eine Lambda-Ausführung hinaus nicht wieder aufrufen lassen, gehen wir für das Abspeichern des Datensatzes der Vergleichsrechnung einen kleinen Umweg über einen S3-Bucket. Aus diesem wird bei jeder Ausführung zu Beginn eine Datei gelesen und zum Ende wieder mit aktuellen Werten überschrieben. Die Datei enthält neben der momentanen Laufleistung jeder Maschinenkomponente ebenfalls die aktuellen Durchschnitts-, sowie Restlaufleistungswerte. Die Lese- und Schreibzugriffe auf die S3-Datei halten sich dabei in Grenzen, sodass sie sich auf die Ausführungszeit der Lambda-Function nicht negativ auswirken.

Am Ende jeder Funktion erhält Elasticsearch Service für jede Maschinenkomponente einen einzelnen Datensatz, der dabei alle nötigen Informationen beinhaltet. Wie schon aus dem IoT Core, handelt es sich hierbei ebenfalls um Daten im JSON-Format, die schlussendlich durch Kibana problemlos aufgenommen und dargestellt werden können.

In Kapitel 3 folgt ein genauerer Überblick der erarbeiteten Visualisierungen.

Alle Beiträge von Lukas Babinsky

Schreibe einen Kommentar