Lösungsmuster · Referenzarchitektur
Zustandsüberwachung und Predictive Maintenance auf Databricks.
Das Muster verbindet Sensordaten mit Anlagenstamm, Betriebszustand und Wartungsereignissen. Modelle liefern nachvollziehbare Hinweise für die Instandhaltung, steuern aber keine Maschine und ersetzen keine sicherheitsgerichtete Logik.
Ausgangslage
Sensoralarme zeigen Werte, aber selten den Wartungskontext.
Zeitreihen liegen in Historian, Steuerung oder IoT-Plattform, während Störungen und Arbeitsaufträge im Instandhaltungssystem stehen. Ohne gemeinsame Zeitbasis und Anlagenkennung bleiben Muster schwer bewertbar.
Geschäftlicher Nutzen
Zustandshinweise werden mit Wartungsentscheidungen und Rückmeldung verbunden.
Instandhaltung kann Trends, Betriebszustand und Ereignishistorie gemeinsam prüfen. Warnungen erhalten einen dokumentierten Ursprung und ihre fachliche Bewertung fließt zurück in Daten- und Modellqualität.
Messbar werden
- Sensorverfügbarkeit, Zeitlücken und Qualität der Anlagenzuordnung
- Vorwarnzeit, fachlich bestätigte Hinweise und Fehlalarme je Betriebszustand
- Modellabweichung, Datenänderungen und Rückmeldung aus Arbeitsaufträgen
Referenzarchitektur
Bausteine und ihre Aufgabe
Streaming und Historie landen im Delta Lake. Databricks erzeugt reproduzierbare Merkmale, MLflow versioniert Modelle und die Instandhaltung behält die Entscheidung.
- 01
Signale sicher aufnehmen
Azure IoT Hub oder Azure Event Hubs übernimmt freigegebene Telemetrie über einen abgesicherten OT-Übergang. Geräteidentität und Zeitstempel werden geprüft.
- 02
Zeitreihen unverändert sichern
Azure Data Lake Storage Gen2 und Delta Lake halten Rohsignale, Qualitätskennzeichen und Eingangskontext als Bronze-Schicht fest.
- 03
Kontext und Merkmale bilden
Azure Databricks synchronisiert Zeitachsen, verbindet Anlagenstamm und Betriebszustand und erzeugt versionierte Merkmale in Silver und Gold.
- 04
Modelle nachvollziehbar entwickeln
MLflow erfasst Datensatz, Parameter, Metriken, Artefakte und Freigabestatus. Ein einfaches Regelmodell bleibt eine mögliche Vergleichsbasis.
- 05
Hinweise bereitstellen
Batch- oder Stream-Bewertung erzeugt priorisierbare Zustandsindikatoren für Power BI oder das Instandhaltungssystem, nicht für direkte Maschinensteuerung.
- 06
Rückmeldung und Drift überwachen
Bestätigte Befunde, Fehlalarme und Arbeitsaufträge fließen kontrolliert zurück. Azure Monitor und Databricks überwachen Pipeline, Daten und Modellverhalten.
Technologie
Konkrete Dienste für die Umsetzung
Die Auswahl wird an bestehende Verträge, Regionen, Sicherheitsvorgaben und den tatsächlichen Umfang angepasst.
- Azure IoT Hub
- Azure Event Hubs
- Azure Data Lake Storage Gen2
- Azure Databricks
- Delta Lake
- MLflow
- Unity Catalog
- Azure Monitor
- Power BI
Erster Projektschnitt
Ein Pilot braucht eine klare Innen- und Außengrenze
Der erste Einsatz prüft Daten, Integration und Arbeitsprozess in einem begrenzten Ausschnitt. Er ist kein vorweggenommener Gesamtrollout.
Bewusst enthalten
Eine klar abgegrenzte Maschinenfamilie und ein fachlich verstandenes Zustandsbild, verfügbare Sensorhistorie, Anlagenstamm, Wartungsereignisse sowie ein Hinweis-Dashboard mit dokumentierter Rückmeldung.
Bewusst nicht enthalten
Kein werksweiter Rollout, keine autonome Abschaltung oder Regelung, keine Änderung an Sicherheits-SPS, keine Garantie für Ausfallvorhersagen und kein Modell für unbekannte Fehlerbilder ohne belastbare Daten.
Voraussetzungen und Grenzen
Technik ersetzt keine Datenverantwortung
Vor der Umsetzung müssen Datenzugang, Zuständigkeiten, Lizenzen und Betrieb geklärt sein. Offene Punkte werden als Projektrisiko behandelt.
- 01Sensorqualität, Zeitsynchronisation, Betriebszustände und stabile Anlagenkennungen bestimmen, ob ein Modell sinnvoll bewertet werden kann.
- 02OT-Zugang, Netzwerksegmentierung, Datenpufferung und Verantwortungsgrenzen müssen mit Betrieb und Informationssicherheit abgestimmt sein.
- 03Für seltene Fehler fehlen oft belastbare Labels. Fachliche Regeln oder reine Zustandsüberwachung können dann geeigneter sein als überwachte Vorhersage.
- 04Instandhaltung, Produktion, Automatisierung, OT-Sicherheit, Data Engineering und Modellverantwortung müssen gemeinsam über Warnung und Reaktion entscheiden.
Deutschland und EU
Compliance wird aus dem konkreten Zweck abgeleitet
Maschinendaten können über Schicht, Arbeitsplatz oder Bedienereingriff einen Personenbezug erhalten. Dann gelten DSGVO, Zweckbindung und klare Lösch- und Zugriffsregeln. Das System darf nicht still zu einer Leistungs- oder Verhaltenskontrolle werden, eine frühe Beteiligung des Betriebsrats nach BetrVG ist bei entsprechender Eignung erforderlich. Für den EU AI Act sind Verwendungszweck und möglicher Bezug zu Arbeitsplatz, Sicherheit oder kritischen Produkten zu bewerten. Datenhaltung und Modellbetrieb sollten in geeigneten EU-Regionen geplant und vertraglich geprüft werden.
Kostenfreie Einordnung
Welcher Anlagenzustand ist fachlich verstanden, aber datenmäßig noch nicht verbunden?
Im Erstgespräch werden Signale, Ereignisse, OT-Grenzen, Reaktion und ein prüfbarer Pilotumfang eingeordnet.
Das erste Beratungsgespräch und die gemeinsame Use-Case-Einordnung sind kostenfrei und unverbindlich.
Passende Use Cases
Zustandsüberwachung für eine kritische Anlage
Sensorwerte, Störungen und Wartungsaufträge liegen getrennt. Seltene oder schlecht markierte Fehlerfälle erschweren eine belastbare Zustandssicht.
Reklamations- und Qualitätsursachenanalyse
Reklamationen, Fehlercodes, Chargen und Prozesswerte liegen in getrennten Systemen. Wiederkehrende Muster werden dadurch spät erkannt.
Ersatzteil- und Bestandsoptimierung
Kritische Teile fehlen, andere liegen jahrelang im Lager. Verbrauch, Anlagenkritikalität, Lieferzeit und Gleichteile werden selten gemeinsam bewertet.