Maschinendaten-Lakehouse in Microsoft Fabric: vom OPC-UA-Sensor-Flood zum brauchbaren Signal

Pexon Consulting | 11 Min. Lesezeit | 15.06.2026

TL;DR

Maschinendaten-Lakehouse in Microsoft Fabric macht aus 50 Millionen OPC-UA-Events pro Tag analytisch brauchbare Signale durch Edge-Filterung und Signal-Engineering-Disziplin — von 50-200 GB Rohdaten auf 2-8 GB pro Tag bei voller analytischer Tauglichkeit. Pexon Consulting baut die Lakehouse-Plattform in 6-8 Wochen als Festpreis zwischen 55 und 95k EUR mit OEE plus Energie-Dashboard als sofortigen Output.

Das „Volume and Meaning“-Problem

Wir hören das bei fast jedem CIO-Erstgespräch in der Fertigung: „Wir haben in den letzten 3 Jahren 4 Millionen EUR in IIoT-Sensorik investiert. Die Daten sammeln wir auch. Aber wir nutzen sie kaum — und das, was wir nutzen, kommt nie schnell genug.“

Das ist kein Engineering-Fehler. Das ist ein strukturelles Pattern, das wir bei 7+ Industrie-Mittelständlern in identischer Form gesehen haben. Der Ablauf ist immer ähnlich.

Phase 1: IIoT-Initiative startet (Jahr 1). Eine Beraterfirma legt ein „Industrie 4.0“-Konzept vor, die Geschäftsleitung gibt 500k-2 Mio EUR frei, Sensorik wird verbaut, OPC-UA-Server wird produktiv. Daten beginnen zu fließen.

Phase 2: Datenmüll-Akkumulation (Jahr 2). Die OPC-UA-Daten landen in einem InfluxDB-Cluster, einer SQL-Datenbank oder einem Cloud-Storage. Volumen steigt linear, jeder Tag wird mitgesammelt. Datenbank-Kosten oder Cloud-Storage-Kosten steigen, aber niemand hat einen klaren Use-Case dafür.

Phase 3: Frustration (Jahr 3). Erste Versuche, mit den Daten zu arbeiten, scheitern. Daten sind unstrukturiert, viele Tags haben keine Dokumentation, die Bedeutung einzelner Signale ist beim Ingenieur, der inzwischen Rentner ist. Geschäftsleitung fragt nach ROI der IIoT-Initiative.

Phase 4: Re-Engineering wird teurer als initialer Aufbau. Das ist die Phase, in der die meisten Mittelständler bei uns landen. Die Frage ist nicht mehr „noch mehr Sensoren“, sondern „wie kommen wir aus dem Datenmüll raus“.

Die Antwort ist Signal-Engineering-Disziplin, eingebaut in die Pipeline-Architektur.

Signal-Engineering als Architektur-Prinzip

Drei Disziplinen, die wir bei jedem Sprint von Tag 1 an durchziehen.

Disziplin 1: Sensor-Inventur mit Use-Case-Zuordnung. Pro Sensor, pro Tag (im OPC-UA-Sinne): Welcher Use-Case nutzt dieses Signal? Wenn die Antwort „noch keiner“ ist, kommt das Tag nicht in den Bronze-Layer. Stattdessen wird die Frage gestellt: Soll der Use-Case in den nächsten 12 Monaten aufgesetzt werden? Wenn ja — Bronze-Layer mit dokumentiertem Use-Case-Owner. Wenn nein — Tag bleibt on-prem im OPC-UA-Server, kein Cloud-Ingest.

Disziplin 2: Edge-Filterung vor Cloud-Send. Ein OPC-UA-Server liefert ein Tag im 10ms-Takt. Für die meisten Analytik-Use-Cases reicht 1-Sekunden-Granularität. Edge-Gateway aggregiert die 100 Subwerte zu 1 Sekundewert. Bei 800 Tags pro Maschine bei 10ms-Update-Rate kommen wir damit von 80.000 Events/Sekunde auf 800 Events/Sekunde — Faktor 100 Reduktion ohne Informations-Verlust für Analytik-Use-Cases.

Disziplin 3: Bedeutung dokumentieren. Pro Tag im Bronze-Layer ist die Engineering-Bedeutung dokumentiert. Welche physikalische Größe, welche Einheit, welcher normale Wertebereich, welche Anomalien gelten als kritisch. Diese Metadata-Schicht ist Audit-Artefakt und Analytik-Voraussetzung gleichzeitig.

In Pexon-Sprints sind das nicht „nice to have“ Postulate, sondern Tagespflicht der ersten zwei Sprint-Wochen.

Die Lakehouse-Architektur in der Übersicht

Wichtige Architektur-Entscheidung: Edge-Filterung. Bei einem Industrie-Pilotkunden haben wir die Edge-Filterungs-Logik in Node-RED implementiert. Pro Tag eine konfigurierbare Filter-Regel — Sample-Rate, Wertebereich, Delta-Threshold (nur bei signifikanten Änderungen senden). Bei 22 Maschinen sind wir von 47 GB pro Tag Rohdaten auf 2,1 GB pro Tag in die Cloud gekommen — bei voller analytischer Tauglichkeit.

Lakehouse statt Time-Series-DB. Wir bauen das bewusst in OneLake mit Delta-Lake-Format statt in InfluxDB. Drei Gründe.

• Schema-Evolution. Bei Sensor-Erweiterungen muss die DB sich anpassen — Delta-Lake macht das schmerzlos.
• Mehrfach-Nutzung. Die gleiche Datenbasis trägt OEE-Dashboard (siehe Databricks-MQTT-Pattern), Energiemonitoring (siehe Lastgang-Pattern), Predictive Maintenance.
• Power-BI-Direct-Lake. Fabric ermöglicht ohne Caching-Overhead Live-Dashboards auf der Lakehouse-Schicht.

Mehr zur Plattform-Wahl zwischen Fabric und Databricks für IIoT.

Die typischen Use-Cases pro Sprint

Was wir nach dem Sprint produktiv haben — und was eigene Folge-Sprints brauchen.

Use-Case 1: OEE-Live-Dashboard (im Sprint enthalten). Verfügbarkeit, Leistung, Qualität pro Maschine in Sekundengranularität. Stillstands-Codes mit Drilldown. Schichtleiter-tauglich, ohne Excel.

Use-Case 2: Energie-pro-Stück-Tracking (im Sprint enthalten). kWh pro produziertes Teil pro Maschine. Anomalie-Detection bei Sprüngen über 20% gegenüber Baseline.

Use-Case 3: Predictive Maintenance (eigener Folge-Sprint). Basierend auf der Lakehouse-Schicht lassen sich ML-Modelle für Stillstands-Vorhersagen aufsetzen. Investment zusätzlich 6-12 Wochen je nach Maschinen-Typ und verfügbarer Trainings-Daten-Historie.

Use-Case 4: Werkzeug-Verschleiß-Vorhersage (eigener Folge-Sprint). Bei spanenden Maschinen lassen sich aus Antriebs-Strömen Verschleiß-Indikatoren ableiten. Aufwendiger, aber bei Hochpreis-Werkzeugen wirtschaftlich interessant.

Use-Case 5: Computer-Vision-Anbindung (eigener Folge-Sprint). Kamera-basierte Qualitäts-Kontrolle, kombiniert mit Maschinen-Daten. Wird wirtschaftlich bei vielen Prüfungen pro Tag — siehe Sovereign-Computer-Vision-Pattern.

Der Punkt: Der Lakehouse-Sprint öffnet die Tür für viele Use-Cases. Jeder Folge-Use-Case wird deutlich schneller, weil die Datenbasis bereits steht.

Die typischen Engineering-Fallen

Drei Fallen, die wir in Sprints häufig sehen.

Falle 1: Alte SPS sprechen kein OPC UA. Bei Maschinen vor 2015 ist oft nur klassisches Siemens-S7 oder Modbus verfügbar. Wir bauen Edge-Gateways mit Node-RED oder Inductive Automation Ignition, die SPS-Protokolle in OPC UA übersetzen. Engineering-Aufwand pro Maschine 1-3 Tage.

Falle 2: Maschinen-Lieferanten haben proprietäre Cloud-Anbindungen. Manche Maschinenbauer (Trumpf, DMG MORI, Mazak) drücken eigene Cloud-Plattformen rein — und die Sensorik geht an deren Server, nicht an euer Werks-Netz. Vertrags-Klauseln-Klärung mit dem Maschinenbauer ist Pflicht-Aufgabe vor dem Sprint.

Falle 3: Sensor-Dokumentation fehlt komplett. Bei einem Pilotkunden hatten wir 720 Tags pro Maschine, davon waren 80 Tags überhaupt dokumentiert. Die Engineering-Aufgabe wird dann Detektivarbeit — Werkstattmeister, Maschinen-Inbetriebnehmer und externe Maschinenbauer-Spezialisten zusammenbringen. Wir rechnen typisch 1-2 Wochen Mehraufwand für solche Setups.

Pexon-Sprint und Investment

6-8-Wochen-Festpreis-Sprint:

• Wochen 1-2 — Sensor-Inventur und Use-Case-Mapping. Pro Maschine OPC-UA-Browse, Tag-Bedeutung mit Werkstatt-Verantwortlichen klären, Use-Case-Zuordnung. Output: Sensor-Inventur-Tabelle mit Bedeutungs- und Use-Case-Zuordnung.
• Wochen 3-4 — Edge-Filterung und Ingest. Edge-Gateways konfigurieren, Eventstream-Setup, Bronze-Layer mit dokumentierten Tags.
• Wochen 5-6 — Silver/Gold und Use-Cases. Maschinen-Status-Schicht, OEE-Berechnung, Energie-Tracking, Power-BI-Dashboards.
• Wochen 7-8 — Übergabe und Dokumentation. Werks-Engineering- und Schichtleitungs-Schulung, Übergabe-Doku, Roadmap für Folge-Use-Cases.

Investment-Festpreis: 55-95k EUR je nach Komplexität. Untere Spanne bei modernen Werken mit guter OPC-UA-Anbindung und 8-15 Maschinen. Obere Spanne bei gemischten Werken mit teilweisem SPS-Modernisierungs-Bedarf und 20-30 Maschinen.

Laufende Cloud-Kosten: Fabric-Capacity F2-F4 reicht für mittelständische Werke, 800-1.800 EUR pro Monat. Bei sehr großen Setups mit ML-Workloads eher F8.

Häufig gestellte Fragen

Wir haben schon eine InfluxDB für Maschinendaten — sollen wir die ersetzen?

Nicht zwingend. InfluxDB ist gut für Live-Monitoring und kurzfristige Time-Series-Queries. Lakehouse ist gut für analytische Use-Cases und Multi-Use-Case-Konsolidierung. Wir bauen oft hybride Setups: InfluxDB bleibt für Real-Time, Lakehouse für analytische Schicht. Pro Setup-Variante entscheiden wir in der Discovery.

Was bei harten On-Prem-Anforderungen?

Fabric ist primär Cloud. Bei strengen On-Prem-Anforderungen (Defence, KRITIS-Tier-1) empfehlen wir on-prem Databricks (über Azure Arc) oder reine on-prem Setups mit PostgreSQL plus TimescaleDB. Wir bauen alle drei Varianten, die Wirtschaftlichkeit kippt typisch zugunsten Cloud bei < 50 Maschinen.

Wie verhält sich der Sprint zu OEE-spezifischen Setups?

Der Maschinendaten-Lakehouse-Sprint enthält OEE als Use-Case. Wenn ihr nur OEE wollt und nichts anderes, ist der reine OEE-Databricks-Sprint schneller und günstiger. Wenn ihr aber 2-3 Use-Cases ansteht (OEE, Energie, Predictive Maintenance), ist die Lakehouse-Variante wirtschaftlich.

Was wenn die Maschinenbauer kein OPC UA anbieten?

Häufig bei älteren Maschinen-Generationen. Edge-Gateway-Pattern mit SPS-spezifischen Konnektoren löst das. Engineering-Aufwand pro Maschinen-Typ 2-5 Tage. Bei sehr exotischen Steuerungen (z.B. ältere Mitsubishi oder Beckhoff TwinCAT 2) eher 5-8 Tage.

Wie reagieren die Maschinen-Operator auf Live-Daten in der Schicht?

Erfahrung aus produktiven Setups: Akzeptanz ist gut, wenn die Werte nicht als Kontroll-Instrument sondern als Hilfe positioniert werden. Wir empfehlen, die ersten 4-6 Wochen das Dashboard nur in der Schichtleitung zu nutzen, nicht direkt am Maschinen-Display. Bei Werks-internen Vereinbarungen kann das später erweitert werden.

Nächster Schritt

Wenn euer Werk in den letzten 3-5 Jahren in IIoT-Sensorik investiert hat und die Daten nicht zur analytischen Wirkung kommen: Wir machen einen 60-Minuten-Discovery-Call mit dir und idealerweise dem Werks-Engineering-Lead. Du beschreibst die Sensor-Lage und die OPC-UA-Anbindung, wir skizzieren den 6-8-Wochen-Sprint mit Festpreis.

Verwandte Themen