OEE-Dashboard für die Fertigung mit Databricks: Maschinendaten via MQTT in unter 4 Wochen

OEE-Dashboard für die Fertigung mit Databricks und MQTT: Maschinendaten in unter 4 Wochen live. Sekundengranularität, Delta Live Tables, Festpreis-Sprint.

7 Aug.. 2026 | Data Analytics

Inhaltsverzeichnis

Pexon Consulting | 10 Min. Lesezeit | 15.06.2026


TL;DR

OEE-Dashboard mit Databricks und MQTT macht Verfügbarkeit, Leistung und Qualität pro Maschine in unter 5 Sekunden sichtbar — statt Excel-Schichtberichte mit 6-12 Stunden Verzögerung. Pexon Consulting baut die Streaming-Pipeline in unter 4 Wochen als Festpreis zwischen 38 und 58k EUR mit Delta-Live-Tables-Architektur, Stillstands-Code-Drilldown und Übergabe an Schichtleitung.

Aspekt Excel-Schichtbericht Databricks + MQTT Live
Datenlatenz 6-12 Stunden < 5 Sekunden
Granularität pro Schicht / pro Werk pro Sekunde / pro Maschine
Pflegeaufwand hoch (manuell) gering (Stream-Pipeline)
Setup-Dauer 0 (existiert schon) < 4 Wochen
Investment versteckt im Stundenlohn 38-58k EUR Festpreis
OEE-Genauigkeit grob geschätzt exakt aus SPS-Werten

Warum OEE-Dashboards in der Realität so oft scheitern

Wir hören das in fast jedem Discovery-Workshop bei Maschinenbauern und Industrieausrüstern: „Wir haben vor 2 Jahren ein OEE-Tool eingeführt, aber die Schichtleiter pflegen die Werte nicht mehr.“ Das Pattern hat drei Ursachen.

Ursache 1: Manuelle Erfassung skaliert nicht. Wenn Schichtleiter Verfügbarkeits-, Leistungs- und Qualitätsdaten in Tablets oder Excel-Files eintragen müssen, ist die Datenqualität nach 6-8 Wochen unterwegs zur Beliebigkeit. Bei 12 Maschinen und 3-Schicht-Betrieb sind das 30-40 Erfassungs-Vorgänge pro Tag, die in der Hektik durchrutschen.

Ursache 2: Daten kommen zu spät. Wenn der Werksleiter morgens den Schichtbericht vom Vorabend bekommt, ist die Reaktion nur noch nachgelagert — die Schicht ist vorbei, die Engpässe lassen sich nicht mehr beheben. OEE-Daten entfalten Wirkung in der laufenden Schicht, nicht im Tages-Review.

Ursache 3: Aggregations-Ebene zu grob. Werk-OEE hilft dem Controlling, dem Schichtleiter nicht. Der braucht die Sicht auf einzelne Maschinen oder Zellen mit Stillstands-Gründen. Klassische Reporting-Tools liefern das oft nicht.

Die Databricks-MQTT-Pipeline löst alle drei Probleme strukturell — automatisierte Erfassung aus SPS-Daten, Sekundengranularität, Maschinen-Drilldown.


Die Architektur in der Übersicht

SPS / Maschinen-Controller ──► OPC UA / MQTT Gateway ──► Databricks Auto Loader
│
▼
Delta Live Tables
(Bronze → Silver → Gold)
│
▼
OEE-Berechnung
(Availability, Performance, Quality)
│
▼
Power BI / Grafana Live Dashboard

Wichtige Designentscheidungen.

Die Maschinen-Datenkommunikation läuft in modernen Werken meist über OPC UA — dem Standard der OPC Foundation, der in Siemens, Beckhoff, Rockwell und den meisten anderen SPS-Welten zuhause ist. Aus OPC UA in MQTT zu konvertieren ist gängige IIoT-Praxis, dafür gibt es bewährte Gateway-Lösungen (z.B. HiveMQ, Inductive Automation, Litmus Edge).

Databricks Auto Loader liest direkt aus dem Streaming-Layer — sei das ein Cloud-MQTT-Broker (Azure Event Hubs MQTT, AWS IoT Core) oder ein on-prem Broker, der die Events nach Azure Event Hubs spiegelt. Delta Live Tables bauen aus den Events die Bronze-Silver-Gold-Architektur ohne dass jemand Pipeline-Code von Hand schreiben muss.


Die OEE-Berechnung im Detail

OEE setzt sich klassisch aus drei Komponenten zusammen, jede zwischen 0 und 100%.

Verfügbarkeit (Availability). Geplante Produktionszeit minus ungeplante Stillstände, geteilt durch geplante Produktionszeit. Maschinen-Status kommt aus der SPS — typisch ein „running“-Bit plus Stillstands-Code wenn der Status auf „stopped“ springt.

Leistung (Performance). Tatsächliche Stückzahl in der Laufzeit geteilt durch theoretische Stückzahl bei Soll-Taktzeit. Stückzähler und Soll-Taktzeit liegen meist in der SPS, oft auch in der MES-Schicht.

Qualität (Quality). Gut-Teile geteilt durch Gesamt-Teile. Bei Inline-Prüfungen direkt aus der SPS, bei nachgelagerter QS oft aus dem ERP — je nach Setup.

# Beispiel: OEE-Berechnung in Databricks Delta Live Tables
import dlt
from pyspark.sql.functions import col, sum, when, lit

@dlt.table(name="bronze_machine_events", comment="Rohe MQTT-Events pro Maschine")
def bronze_machine_events():
    return (
        spark.readStream
        .format("cloudFiles")
        .option("cloudFiles.format", "json")
        .load("/Volumes/raw/mqtt/")
    )

@dlt.table(name="silver_machine_state", comment="Bereinigte Maschinen-Zustände pro Sekunde")
def silver_machine_state():
    return (
        dlt.read_stream("bronze_machine_events")
        .filter(col("event_type").isin("status", "production", "quality"))
        .withColumn("availability_flag",
            when(col("status") == "running", 1).otherwise(0)
        )
    )

@dlt.table(name="gold_oee_per_machine_hour", comment="OEE pro Maschine pro Stunde")
def gold_oee_per_machine_hour():
    return (
        dlt.read("silver_machine_state")
        .groupBy("machine_id", window("timestamp", "1 hour"))
        .agg(
            (sum("availability_flag") / 3600.0).alias("availability"),
            (sum("good_parts") / sum("theoretical_parts")).alias("performance"),
            (sum("good_parts") / sum("total_parts")).alias("quality")
        )
        .withColumn("oee", col("availability") * col("performance") * col("quality"))
    )

Die so berechneten Werte landen in der Gold-Schicht und stehen für Live-Dashboards bereit. Der Power-BI-Direct-Lake-Connector oder ein Grafana-Dashboard ziehen die Daten ohne Caching-Verzug.


Was in unter 4 Wochen ehrlich machbar ist

Das aggressive Zeitversprechen braucht klare Abgrenzung.

Was geht in 4 Wochen. OEE-Pipeline für 1 Werk mit 8-20 Maschinen die OPC UA oder MQTT bereits sprechen. Dashboard mit Live-OEE plus Stillstands-Analyse plus Top-Down-Drilldown von Werk auf Maschine. Übergabe an Werks-Engineering plus Schichtleitung mit Schulung.

Was Mehr-Aufwand braucht. Maschinen ohne OPC UA / MQTT-Anbindung. Hier kommen zusätzliche IIoT-Gateways ins Spiel (z.B. Siemens Mendix Edge, AWS IoT Greengrass), Engineering pro Maschine 1-3 Tage. Bei einem Werk mit gemischtem Maschinenpark (50% modern, 50% alt) typisch 2 Wochen Mehrarbeit gegenüber dem reinen 4-Wochen-Versprechen.

Was komplett anderer Sprint ist. OEE-Vorhersage mit Machine Learning (Predictive Maintenance). Multi-Werk-Konsolidierung. Anbindung an SAP-PP für automatische Reihenfolge-Optimierung. Das sind eigene Folge-Sprints typisch 4-8 Wochen pro Modul.

Wir machen die Realitäts-Bewertung in einem 60-Minuten-Vorgespräch — kein 4-Wochen-Versprechen ohne vorherige Datenlage-Klärung.


Sie wollen das OEE-Dashboard in 4 Wochen live haben, statt einen 6-Monats-IIoT-Sprint zu starten? Pexon liefert die Databricks-MQTT-Pipeline als Festpreis-Sprint mit dokumentierter Übergabe an euer Werks-Team — OEE-Dashboard-Sprint mit Pexon planen.

Warum Databricks und nicht Microsoft Fabric oder Snowflake

Pragmatische Abwägung — wir bauen alle drei Plattformen produktiv, aber für IIoT-OEE-Setups hat Databricks konkrete Vorteile.

Streaming-Reife. Databricks Structured Streaming ist seit 2018 produktiv getrieben durch das Spark-Backbone. Delta Live Tables vereinfachen das Streaming-Pipeline-Engineering ohne den Spark-Stack zu verlassen. Microsoft Fabric Eventstream ist seit 2024 verfügbar, hat aber noch Reife-Lücken bei sehr hohen Volumen (>50.000 Events/Sekunde). Mehr zur Fabric-Bewertung im Mittelstand-Vergleich.

Notebook-Engineering-Speed. Bei den schnellen IIoT-Setups arbeiten wir viel im Notebook-Modus — Hypothesen testen, Berechnungen anpassen, sofort visualisieren. Databricks Notebooks sind hier extrem produktiv.

Lakehouse-Pattern für IIoT. Hochfrequente Sensordaten brauchen eine Storage-Schicht, die effizient mit Zeitreihen umgeht. Delta Lake mit Z-Ordering auf Timestamp ist hier deutlich performanter als klassische Data-Warehouse-Schichten.

Wann Fabric trotzdem die bessere Wahl ist. Wenn ihr ohnehin im Microsoft-Stack lebt (M365, Azure AD, SharePoint) und das OEE-Setup mit anderen Analytics-Themen kombinieren wollt (z.B. mit dem CSRD-Reporting in Fabric), ist Fabric die einheitlichere Plattform. Wir machen beides — die Entscheidung kommt im Assessment.


Pexon-Sprint und Investment

4-Wochen-Festpreis-Sprint:

  • Woche 1 — Discovery und IIoT-Inventur. Welche Maschinen, welche SPS-Welten, welche MQTT-Lage, welche Stillstands-Codes existieren bereits. Architektur-Skizze.
  • Woche 2 — Pipeline-Aufbau. Auto-Loader-Konfiguration, Delta-Live-Tables-Definition, Bronze-Silver-Gold-Schichten produktiv.
  • Woche 3 — OEE-Berechnung und Dashboard. Verfügbarkeit, Leistung, Qualität berechnen. Power-BI- oder Grafana-Dashboard mit Drilldown.
  • Woche 4 — Schulung und Übergabe. Werks-Engineering und Schichtleitung-Schulung, Doku, Übergabe.

Investment-Festpreis: 38-58k EUR je nach Komplexität. Untere Spanne bei modernem Maschinenpark mit kompletter OPC-UA-Anbindung, obere Spanne bei gemischtem Maschinenpark mit teilweisen Edge-Gateway-Anpassungen.

Laufende Cloud-Kosten: Bei einem Mittelständler-Werk mit 20 Maschinen typisch 800-1.400 EUR pro Monat Databricks-Cluster-Kosten plus Storage. Bei Multi-Werk-Setups skaliert die Cluster-Kapazität, nicht linear sondern eher logarithmisch.


Häufig gestellte Fragen

Was wenn die SPS-Welt extrem heterogen ist?

Bei einem Industrie-Pilotkunden mit 6 verschiedenen SPS-Generationen (Siemens S5, S7, TIA, Rockwell, Beckhoff, Mitsubishi) haben wir das mit drei IIoT-Gateways gelöst, die jeweils 2-3 SPS-Welten kapseln. Engineering-Aufwand 1,5 Wochen mehr als Standard. Pro alter SPS-Generation rechnen wir typisch 2-4 Tage Mehraufwand.

Wie verhält sich das bei On-Prem-Anforderung?

Databricks läuft primär in der Cloud (AWS, Azure, GCP). Bei harten On-Prem-Anforderungen (KRITIS-Tier-1, Defence) empfehlen wir oft hybride Setups — Edge-Aggregation on-prem mit MQTT-Broker, anonymisierte Aggregate in die Cloud. Vollständig On-Prem für hochfrequente IIoT-Setups ist möglich aber deutlich teurer und länger.

Kann ich das selbst bauen ohne externe Begleitung?

Klar. Databricks hat gute Dokumentation, MQTT-Patterns sind etabliert. Der Engineering-Aufwand für ein eigenes Team mit Spark-Erfahrung liegt typisch bei 12-18 Wochen für die erste Version. Pexon liefert in 4 Wochen weil wir das Pattern aus produktiven Setups haben — Lerneffekt aus 6+ Projekten ist im Sprint enthalten.

Was passiert nach den 4 Wochen?

Übergabe an euer Werks-Engineering plus optionale Pexon-Begleitung für die ersten 2-3 Monate. Pro Monat typisch 2-4 Engineering-Tage für Anpassungen, neue Maschinen, neue Stillstands-Codes. Bei größeren Erweiterungen (Predictive Maintenance, Multi-Werk-Konsolidierung) eigene Folge-Sprints.

Wie sicher sind die Maschinendaten in der Cloud?

Klar adressierbar. Maschinendaten sind ohne Kontext keine sensiblen Daten — Stückzahlen, Stillstands-Codes, Taktzeiten sagen ohne Produkt-Kontext wenig aus. Bei sensiblen Kontexten (Defence, Pharma) verschlüsseln wir auf Edge-Ebene, anonymisieren Produkt-IDs. Vollständige Compliance-Architektur als optionaler Sprint-Zusatz.


Nächster Schritt

Wenn dein Werks-Leiter seit Quartalen ein Live-OEE-Dashboard fordert und das Excel-Pattern an Grenzen stößt: Wir machen einen 60-Minuten-Discovery-Call mit dir und idealerweise dem Werks-Engineering-Lead. Du beschreibst die Maschinen-Lage und SPS-Welten, wir skizzieren den 4-Wochen-Sprint mit Festpreis.


Verwandte Themen


Microsoft Fabric. Bilder Blogtemplate Whitepaper

Leitfaden Microsoft Fabric

  • Datenstrategien und Praxislösungen für den Mittelstand – effizient, skalierbar und zukunftssicher

Beratungsgespräch

Sichern Sie sich Ihre kostenfreie Erstberatung

Analyse Ihres individuellen Cloud- oder KI-Bedarfs
Erste Empfehlungen zu Umsetzungsstrategien
Transparente Einblicke in unsere Methoden, Technologien & Referenzen