Wie im ersten Teil der Artikelreihe beschrieben, ermöglicht es die Umsetzung des Cold-Data-Pfades, Erkenntnisse aus Langzeitdaten-Analysen zu ziehen. Damit werden frühzeitige Steuerungsmaßnahmen möglich, die eine Minderung der Produktivität, -qualität oder gar einen Produktionsausfall verhindern können. In diesem Teil der Serie steht die Frage im Vordergrund, wie sich eingehende Live-Daten für ad-hoc Analysen, Alarme oder Visualisierungen nutzen lassen. Dazu bauen Anwenderunternehmen ein Stream Processing auf der AWS-Cloud auf, mit dem Echtzeit-Einblicke in die Produktion gewonnen und diese anschließend gewinnbringend genutzt werden können.
Vereinfachter Anwendungsfall
Als Szenario dient ein stark vereinfachter Anwendungsfall aus der Instandhaltung:
Im Beispiel geht es um ein Asset, das nur in einem bestimmten Temperatur- und Luftfeuchtigkeitskorridor Teile in der gewünschten Qualität produzieren kann. Erweiterte Analyseverfahren können diesen Korridor offenlegen. Nun möchten die Produzenten frühzeitig eine Warnung an einen Instandhalter schicken, dass sich die Maschine außerhalb dieses Korridors bewegt, oder diesen bald verlassen wird. Zu diesem Zweck setzen sie eine Streaming-Architektur auf. Eine Streaming Architektur besteht immer aus drei Bestandteilen: dem Event Producer, dem Event Router und dem Event Consumer. Dabei veröffentlicht der Producer die Nachricht an den Router, wobei dieser die Daten filtern oder anreichern kann und liefert diese Daten wiederum an die Consumer aus. Dadurch können Producer und Consumer voneinander unabhängig skaliert werden. Um das Szenario umzusetzen – also Warnungen an die Instandhaltung zu schicken – sobald Luftfeuchtigkeit und Temperatur drohen ihren Korridor zu verlassen, lässt sich eine Architektur mit folgenden Komponenten aufbauen.
AWS-Software im Einsatz
In der Architektur fließen die Daten aus IoT Core direkt über eine IoT Rule in die Streaming-Anwendung Kinesis Data Streams, die von AWS verwaltet wird. Dabei wird kein zusätzlicher Code benötigt, da die Integration der AWS Services verlässlich ist. Innerhalb der Regel müssen Anwender lediglich einen Kinesis Data Stream angeben, auf den die Daten veröffentlicht werden sollen. Die tatsächliche Verarbeitung der Daten erfolgt in Kinesis Data Analytics (kurz KDA), wobei KDA hierbei das Hosting der vom Anwender als Docker Container bereitgestellten Apache-Flink-Applikation übernimmt. Apache Flink ist ein Framework zum Stream Processing, welches die asynchrone Filterung und die Anreicherung von Daten unterstützt. KDA übernimmt dabei die Skalierung und Überwachung der Applikation.
KI-gestütztes Monitoring
Von hier lässt sich eine asynchrone Anfrage an eine Lambda-Funktion anstoßen, die als Proxy für die Sagemaker Inference API dient, welche in diesem Fall mit einem Micro-Batch angefragt wird. Also wird für ein kleines Datenset angefragt, ob die aktuellen Daten darauf hindeuten, dass die Werte bereits außerhalb des Korridors liegen, oder zu verlassen drohen. Diese API wird genutzt, um die Live-Daten gegen das zuvor trainierte Modell zu validieren. In diesem Korridor von Luftfeuchtigkeit und Temperatur ist die Problemstellung nahezu trivial und könnte auch durch einfache Wenn-Dann-Verkettungen gelöst werden. Doch das Vorgehen ist auf weit komplexere Daten mit vielen Einflussvariablen übertragbar.