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.
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
│
▼
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.
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 als Alternative zu Databricks im Mittelstand
→CSRD-Reporting auf Microsoft Fabric mit SAP- und Lieferanten-Daten
→AI Readiness Assessment als Vorab-Klärung für Daten-Plattform-Entscheidungen



