Die meisten IoT-Projekte enden beim Dashboard. Sensoren schicken Temperatur, Vibration, Druck und Stromstärke in Diagramme, und das Team schaut zu. Dashboards machen ihre Arbeit gut: Sie zeigen, was passiert ist. Das Problem ist, dass kein Dashboard verrät, dass eine Pumpe nächsten Donnerstag ausfällt.
Analytics-Modelle schließen diese Lücke. Sie lernen das normale Verhalten jeder Anlage aus deren eigener Historie und bewerten dann jeden neuen Messwert gegen dieses Muster. Das Ergebnis ist kein weiteres Diagramm zum Deuten. Es ist eine Wahrscheinlichkeit, eine Prognose oder ein Countdown, auf den man reagieren kann: Ersatzteil bestellen, Team einplanen, Last vor der Spitze verschieben.
Dieser Artikel behandelt, was ein Analytics-Modell tatsächlich ist, warum ein trainiertes statistisches Modell einem KI-Modell für allgemeine Zwecke beim Bewerten von Telemetrie überlegen ist, welche Modellfamilie welche Frage beantwortet und was veröffentlichte Forschung zum Nutzen sagt. Die Einführung zu deskriptiver, prädiktiver und präskriptiver Analytik steht in was Predictive Analytics für IoT bedeutet.
Wie IoT-Analytik funktioniert, vom Sensor bis zur Entscheidung
Die Pipeline läuft in vier Schritten: Daten von Sensoren sammeln, ein Modell auf dieser Historie trainieren, Inferenzen auf neuen Messwerten ausführen und auf das Ergebnis reagieren.
Das Sammeln haben die meisten IoT-Teams schon. Geräte melden nach Zeitplan, die Plattform speichert die Messwerte als Zeitreihen, und ein paar Wochen Historie kommen zusammen. Diese Historie ist der Rohstoff für alles andere. Wie viel davon Sie brauchen, hängt vom Modell und von der Saisonalität ab, die Sie erfassen wollen, und das lohnt sich zu klären, bevor Sie irgendetwas trainieren.
Das Training passiert gelegentlich. Das Modell liest die Historie einmal und zieht die Struktur heraus: den Tagesgang, den Wochengang, den Trend, die Beziehung zwischen Variablen. Die Inferenz läuft dauerhaft und kostet fast nichts. Jeder neue Messwert wird in Millisekunden gegen das gelernte Muster bewertet. Zur Mechanik, wo das Training läuft und wo bewertet wird, siehe Machine Learning auf IoT-Daten ausführen.
Im letzten Schritt zeigt sich der Nutzen. Eine Prognose, die einen Grenzwert überschreitet, kann einen Arbeitsauftrag auslösen. Ein Anomaliewert kann eine Technikerin alarmieren. Eine Bedarfsprognose kann auf demselben Dashboard landen, das das Betriebsteam schon nutzt, direkt neben den Live-Werten.
Was ist ein Analytics-Modell im IoT?
Ein Analytics-Modell ist eine mathematische Beschreibung davon, wie sich eine Variable über die Zeit verhält, angepasst an Ihre eigenen Sensordaten. Einmal angepasst, beantwortet es Fragen, die die Rohdaten nicht beantworten: was dieser Sensor nächste Woche anzeigt, ob das Vibrationsmuster von heute ungewöhnlich ist, wie viele Tage bleiben, bis ein Tank seinen Grenzwert erreicht.
Das Modell verändert außerdem, was ein KPI sein kann. Verfügbarkeit im letzten Monat und Durchschnittstemperatur von gestern sind rückwärtsgerichtete Zahlen; sie beschreiben eine Vergangenheit, die niemand mehr ändern kann. Ein Modell erzeugt vorwärtsgerichtete KPIs: Ausfallwahrscheinlichkeit in diesem Monat, Tage bis zum Grenzwert, ein Zustandswert pro Anlage, prognostizierter Bedarf mit Konfidenzintervall. Das sind die KPIs, auf die jemand reagieren kann, weil das beschriebene Ereignis noch nicht eingetreten ist.
Konfidenzintervalle sind wichtiger, als sie aussehen. Eine Prognose von “82 kWh morgen, zwischen 76 und 88 bei 95% Konfidenz” erlaubt Planung mit bekanntem Risiko statt aus dem Bauch. Das ist der Unterschied zwischen einem Blick auf ein Diagramm und einer Entscheidung, die Sie verteidigen können.
Dashboards bleiben im Bild. Es geht nicht darum, sie zu ersetzen, sondern darum, zu ändern, was sie anzeigen: Modellausgaben kommen als neue Variablen an, sodass derselbe Bildschirm, der die letzten 24 Stunden zeigt, auch die nächsten 7 Tage zeigen kann.
| Dashboards | Analytics-Modelle mit guten KPIs | |
|---|---|---|
| Beantwortete Frage | “Was ist passiert?” | “Was passiert wahrscheinlich, und wie sicher sind wir?” |
| Zeithorizont | Vergangenheit bis Gegenwart | Gegenwart bis Zukunft |
| Ausgabe | Diagramme, die jemand deutet | Prognosen, Wahrscheinlichkeiten, Anomaliewerte |
| Wie Handeln beginnt | Jemand merkt es und reagiert dann | Alarme und Arbeitsaufträge laufen vor dem Ausfall an |
| Entscheidungshilfe | Kontext und Prüfpfad | Vorlaufzeit und quantifizierte Sicherheit |
Warum statistische Modelle statt KI für die Analyse von Sensordaten?
Weil das Bewerten von Sensordaten ein numerisches Problem ist und ein trainiertes Modell es für einen Bruchteil dessen löst, was KI für allgemeine Zwecke kostet. Große Sprachmodelle sind für Text und Schlussfolgern gebaut. Eines auf rohe Telemetrie zu richten heißt, GPU-Preise zu zahlen, bei jeder Frage, für Arithmetik, die ein angepasstes Modell auf einer CPU in Millisekunden erledigt.
Der strukturelle Unterschied liegt darin, wo gelesen wird. Ein statistisches Modell liest Ihre Historie genau einmal, beim Training. Danach berührt jede Inferenz nur die neuesten Datenpunkte. Ein KI-Assistent, den man fragt “ist dieser Kompressor gesund?”, hat kein angepasstes Modell, auf das er sich stützen kann, und müsste die relevanten Daten jedes Mal neu verarbeiten. Niemand will ein LLM, das Milliarden Datenpunkte erneut liest, weil jemand dieselbe Frage zweimal gestellt hat.
Determinismus ist die zweite Lücke. Ein angepasstes Modell liefert bei gleicher Eingabe die gleiche Antwort, mit einem Konfidenzintervall, das Sie prüfen und einer Betriebsleitung oder einer Aufsichtsbehörde erklären können. Die Ausgabe generativer KI kann zwischen Durchläufen schwanken, was schlecht zu einem Alarm passt, der jemanden um 3 Uhr morgens weckt.
| Trainierte Analytics-Modelle | KI für allgemeine Zwecke (LLMs) | |
|---|---|---|
| Gebaut für | Numerische Zeitreihen | Sprache und allgemeines Schlussfolgern |
| Hardware pro Inferenz | CPU | GPU-Cluster |
| Kosten pro Inferenz | Bruchteile eines Cents | Um Größenordnungen höher |
| Latenz | Millisekunden | Sekunden |
| Umgang mit Daten | Trainiert einmal auf der Historie, bewertet nur neue Punkte | Verarbeitet die Daten bei jeder Frage neu |
| Wiederholbarkeit | Deterministisch, gleiche Eingabe, gleiche Ausgabe | Ausgabe kann zwischen Durchläufen schwanken |
| Erklärbarkeit | Trend, Saisonalität und prüfbare Grenzwerte | Schwer zu prüfen |
| Skalierung auf eine Flotte | Tausende Geräte laufend bewertet bei stabilen Kosten | Kosten wachsen mit jedem verarbeiteten Token |
KI hat weiter ihren Platz. Assistenten helfen beim Bauen von Lösungen, beim Schreiben von Skripten und beim Erklären von Ergebnissen, und Sie können Ihren IoT-Daten Fragen in natürlicher Sprache stellen. Das laufende Bewerten großer Mengen Sensordaten ist Aufgabe von Modellen, so wie Sie auch keine Beraterin dafür anheuern würden, jede Stunde eine Tabelle zusammenzurechnen.
Welches Modell passt zu welchem Problem?
Beginnen Sie mit der Frage, die beantwortet werden muss, und wählen Sie erst dann die Familie.
Prognose beantwortet “wie verhält sich diese Variable als Nächstes?” Exponentielle Glättung (ETS) und Holt-Winters schreiben eine Reihe fort, indem sie die jüngste Historie und deren saisonale Zyklen gewichten. Sie sind die Arbeitspferde des Feldes, ausführlich behandelt in Forecasting: Principles and Practice von Hyndman und Athanasopoulos an der Monash University. Die MSTL-Zerlegung bewältigt Reihen mit mehreren saisonalen Mustern gleichzeitig, etwa Energieverbrauch mit Tages- und Wochengang. Wie ARIMA, Prophet und die neuronalen Varianten auf derselben Reihe abschneiden, steht in welches Prognosemodell zu Ihrer IoT-Zeitreihe passt.
Anomalieerkennung beantwortet “ist das normal?” K-Means-Clustering, fester Teil des Machine-Learning-Lehrplans in Stanford, gruppiert die Betriebszustände einer Anlage, sodass neue Messwerte, die in kein Cluster passen, auffallen. DBSCAN findet dichtebasierte Gruppen und hilft so, das eine Gerät zu erkennen, das sich anders verhält als seine Nachbarn. Isolation Forest trennt Ausreißer auch in großen Datenmengen schnell ab. Erkennung und Prognose lösen verschiedene Probleme, und zur falschen zu greifen ist ein häufiger Anfängerfehler.
Drifterkennung beantwortet “wird das langsam schlechter?” EWMA-Kontrollkarten, dokumentiert im e-Handbook of Statistical Methods des NIST/SEMATECH, gewichten die jüngsten Messwerte gegen eine Grundlinie und melden kleine, anhaltende Verschiebungen lange bevor sie einen festen Grenzwert reißen. Zusetzende Filter, verschleißende Lager und wegdriftende Kalibrierung sehen genau so aus.
Schätzung und Restzeit bis zum Grenzwert beantworten “was treibt dieses Ergebnis, und wie viel Zeit habe ich?” Multivariate Regression schätzt eine Zielgröße aus ihren Treibern, nützlich wenn das Interessante keinen eigenen Sensor hat. Eine Prognose mit einem Grenzwertscan zu verbinden macht aus “der Tank steht bei 63%” ein “der Tank erreicht seinen Grenzwert in etwa 9 Tagen”, und das ist ein Wartungsplan, kein Diagramm.
Zahlt sich vorausschauende Wartung wirklich aus?
Die veröffentlichten Zahlen sagen ja. Der Operations & Maintenance Best Practices Guide des US-Energieministeriums schätzt, dass ein funktionierendes Programm für vorausschauende Wartung 8% bis 12% gegenüber einem präventiven Programm einspart, und 30% bis 40% für Betriebe, die von reaktiver Wartung bis zum Ausfall kommen. Das Pacific Northwest National Laboratory vertritt dieselbe Linie: zustandsbasierte Planung schlägt sowohl den Kalender als auch den Defekt. Eine peer-reviewte Übersichtsarbeit zu vorausschauender Wartung in der Industrie 4.0 kommt über Dutzende Studien zum gleichen Schluss. Die Technik funktioniert, wenn die Datenpipeline dahinter funktioniert.
Die Zahlen von Deloitte zu Verfügbarkeit und Wartungskosten sind in vorausschauende Wartung vereinfachen aufgeschlüsselt und werden hier nicht wiederholt.
Eine ehrliche Einschränkung: Der Gewinn hängt am Handeln. Eine Prognose, die niemand in einen Arbeitsauftrag überführt, ist nur ein weiteres Diagramm. Der Handlungsschritt der Pipeline ist nicht optional.
Anfangen ohne Data-Science-Team
Alles oben Beschriebene lässt sich von Hand bauen, mit Open-Source-Bibliotheken, einem Ort, wo sie laufen, und jemandem, der die Pipeline pflegt. Das ist ein echtes Projekt: Datenextraktion, Zeitpläne fürs Nachtrainieren, Modellablage und die Verdrahtung der Ausgaben zurück in die Alarme.
TagoIO Analytics packt diese Pipeline in die Plattform, an die Ihre Geräte schon melden. Sie wählen eine Variable, ein Assistent trainiert das Modell auf den Daten, die Ihnen schon gehören, und die Prognosen kommen als gewöhnliche Variablen zurück. Sie landen auf Dashboards, lösen Actions aus und speisen Alarme, ohne eine Zeile ML-Code.
Die schweren Schritte, Training und Inferenz, laufen auf dem Dienst sight.tago.io, während Ihre Daten, Dashboards und Actions in Ihrem TagoIO-Konto bleiben. Die Pipeline vom Anfang dieses Artikels bildet sich direkt darauf ab.
Die Modellliste entspricht den Familien von oben: Seasonal Forecasting (MSTL-Zerlegung mit exponentieller ETS-Glättung), Demand Prediction (Prophet mit Treiberprognosen), Estimation from Drivers (multivariate OLS-Regression), Quick Health Check (Isolation Forest), Continuous Monitoring (K-Means-Clustering), Peer Comparison (DBSCAN-Dichteclustering), Slow Drift Detection (EWMA-Kontrollkarte auf einer saisonalen Grundlinie) und Time to Threshold (Holt-Winters- oder AutoETS-Prognose mit Grenzwertscan).
Wenn Ihre Sensoren schon Daten senden, beginnt der Trainingsschritt mit einer Historie, die Ihnen bereits gehört. Sehen Sie sich die Modelle auf tago.io/analytics an, oder buchen Sie eine Demo, um eines davon an Ihren eigenen Messwerten durchzugehen.
Quellen
- Hyndman, R.J. und Athanasopoulos, G. (Monash University), Forecasting: Principles and Practice, 3. Aufl.
- Taylor, S.J. und Letham, B., Forecasting at Scale (Prophet), PeerJ Preprints
- Liu, F.T., Ting, K.M. und Zhou, Z.-H., Isolation Forest, IEEE ICDM 2008
- Ng, A. (Stanford University), CS229 Lecture Notes: The k-means clustering algorithm
- NIST/SEMATECH, e-Handbook of Statistical Methods: EWMA Control Charts
- US-Energieministerium, Operations & Maintenance Best Practices Guide, Release 3.0
- Pacific Northwest National Laboratory, O&M Best Practices: Maintenance Approaches
- Predictive maintenance in Industry 4.0: a survey of planning models and machine learning techniques, peer-reviewte Übersichtsarbeit
