Wie Maschinendaten in Microsoft Fabric gelangen - Von OPC UA zur Echtzeitanalyse

Maschinenalarme, Sensorwerte, Produktionszähler und Störungsereignisse in die Cloud zu bringen, ist heute einfacher denn je. OPC UA stellt das Maschinensignal bereit, eine Edge-Schicht erfasst es, MQTT kann es lokal verteilen, und Microsoft Fabric kann den resultierenden Datenstrom aufnehmen und analysieren. Der schwierige Teil beginnt jedoch, nachdem die Daten angekommen sind: Wie macht man aus Rohtelemetrie genug Produktionskontext, um eine tatsächliche Entscheidung zu unterstützen?

Diese Episode verfolgt ein einzelnes Maschinensignal vom Shopfloor durch den industriellen Datenstack von Microsoft. Sie beginnt bei OPC UA, führt über die Edge und MQTT, überquert sicher nach Azure und Microsoft Fabric und betrachtet dann, wie Eventstream, Eventhouse, KQL, Lakehouse, Power BI, MES, ERP, Wartungsdaten und Produktionskontext zusammenpassen. Ziel ist nicht einfach, eine weitere Telemetrie-Pipeline zu zeigen. Es geht darum zu erklären, was passieren muss, bevor Maschinendaten für Produktion, Instandhaltung, Qualität und Planung nützlich werden.

VOM MASCHINENSTILLSTAND ZUR PRODUKTIONSFOLGE
Ein Maschinenstillstand wirkt auf Steuerungsebene simpel. Der Status wechselt von Laufen zu Störung, ein Fehlercode erscheint, der Teilezähler bleibt stehen und möglicherweise ändern sich andere Werte zur gleichen Zeit. Diese Information ist nützlich, doch die Produktion stellt meist eine andere Frage: Welcher Arbeitsauftrag ist betroffen, wie viel Menge bleibt offen, kann eine andere Maschine übernehmen, und gefährdet diese Verzögerung eine Lieferung?

Die Maschine kennt ihren eigenen Zustand, versteht aber nicht automatisch die geschäftliche Konsequenz. MES kennt womöglich Arbeitsgang und Arbeitsauftrag. ERP kennt eventuell Liefertermin und Bedarf. Die Instandhaltung versteht die Gerätehistorie. Die Qualität entscheidet, ob Ausbringung noch verwendbar ist. Deshalb ist eine schnelle Telemetrie-Pipeline nur der Anfang der Architektur.

OPC UA — WO DAS SIGNAL IN DEN DATENPFAD EINTRITT
OPC UA bietet eine standardisierte industrielle Schnittstelle, um Informationen von Anlagen abzurufen, ohne dass jede Cloud-Anwendung proprietäre Steuerungsprotokolle verstehen muss. Ein Server kann Variablen, Maschinenzustände, Alarme, Ereignisse, Methoden, Zeitstempel, Qualitätsinformationen und teils strukturierte Gerätemodelle bereitstellen.

Diese Struktur ist wichtig, weil ein nützliches industrielles Ereignis mehr als einen numerischen Wert transportieren sollte. Quellzeitstempel, Serverzeitstempel, Qualitätsstatus, Einheiten, Quellidentität und die ursprünglichen OPC-UA-Knoteninformationen können später entscheidend werden, wenn jemand fragt, woher eine Zahl stammt oder warum eine Produktionsberechnung falsch aussieht.

Die Episode betont außerdem, dass ein Tag-Name kein Datenmodell ist. Ein Feld mit der Bezeichnung „Temperatur“ oder „Maschinenstatus“ benötigt weiterhin Kontext wie Anlage, technische Einheit, zulässigen Bereich, Zustandsdefinition und die Produktionssituation, in der das Signal beobachtet wurde.

DIE OT-GRENZE KONTROLLIERT HALTEN
Maschinenanbindung darf das Produktionsnetz nicht zu einer Erweiterung der Unternehmens- oder Cloud-Umgebung machen. Industrienetze benötigen kontrollierte Grenzen, typischerweise mit Segmentierung und einer industriellen DMZ, damit freigegebene Edge-Systeme mit Anlagen kommunizieren können, ohne Unternehmensanwendungen direkten Zugriff auf Steuerungen zu geben.

Das empfohlene Muster ist grundsätzlich ausgehend orientiert. Die Edge-Schicht verbindet sich mit freigegebenen OPC-UA-Endpunkten und sendet anschließend ausgewählte Informationen über kontrollierte Ziele, Ports, Protokolle und Identitäten in Richtung Cloud-Dienste. Analyseplattformen sollten Daten empfangen, ohne breite Rechte zum Durchsuchen oder Verändern von Produktionssystemen zu erben.

Zertifikate, Firewall-Regeln, Vertrauensbeziehungen, Ablaufbehandlung und Verantwortlichkeiten müssen ebenfalls als betriebliche Prozesse und nicht als einmalige Konfigurationsarbeit behandelt werden.

DIE EDGE SOLL DATEN VERBESSERN — NICHT GESCHÄFTLICHE BEDEUTUNG ERFINDEN
Die Edge-Schicht liegt zwischen der Maschinenumgebung und der übrigen Datenplattform. Ihre erste Aufgabe ist die Verbindung, sie kann die Informationen aber auch vor dem Verlassen des Werks filtern, normalisieren, puffern, anreichern und weiterleiten.

Sinnvolle Aufgaben der Edge sind:
• Auswahl nur der Signale, die für definierte Anwendungsfälle benötigt werden
• Filterung unnötiger hochfrequenter Daten
• Anwendung vereinbarter Einheitenumrechnungen
• Erhalt von Quellzeitstempeln und Qualitätsindikatoren
• Ergänzung stabiler Standort-, Linien- und Anlagenkennungen
• Pufferung bei Cloud-Ausfällen
• Umgang mit Wiederholungs- und Backpressure-Verhalten
• Bereitstellung des Zustands von Konnektoren und Warteschlangen
• Ausführung ausgewählter lokaler Berechnungen oder KI-Inferenz, wenn Latenz oder unterbrechungsfreier Betrieb es erfordern

Die wichtige Grenze: Die Edge sollte nur Fakten hinzufügen, die sie sicher kennt. Sie sollte nicht raten, welcher Produktionsauftrag aktiv ist, auf Basis veralteter Informationen, und auch nicht stillschweigend geschäftlichen Kontext erzeugen, der zu MES, ERP, Planung oder Qualitätssystemen gehört.

AZURE IOT EDGE VS. AZURE IOT OPERATIONS
Die Episode vergleicht zwei Microsoft-Ansätze für den Betrieb industrieller Edge-Workloads.
Azure IoT Edge eignet sich gut, wenn die Anforderung auf ein Gateway oder einzelne Geräte fokussiert ist. Containerisierte Module können Daten erfassen, lokale Logik anwenden, Informationen puffern und über Azure IoT Hub nach oben senden. Das kann eine praktische Wahl für eine definierte Zelle oder einen kleineren Workload sein, bei dem die Organisation einen schlankeren Betriebsaufwand anstrebt.

Azure IoT Operations ist eher als standortbezogene industrielle Datenumgebung positioniert. Sie läuft auf einer Azure-Arc-fähigen Kubernetes-Umgebung und umfasst Funktionen rund um OPC-UA-Anbindung, MQTT, Datenflüsse sowie Verwaltung von Assets und Geräten. Das ergibt eher Sinn, wenn ein Standort mehrere Linien, Maschinen verschiedener Hersteller, lokale Verbraucher hat und ein einheitliches, gesteuertes Edge-Muster über Werke hinweg wiederholen möchte.

Die Entscheidung sollte nicht davon abhängen, welche Plattform die längste Funktionsliste hat. Sie sollte sich danach richten, welches Betriebsmodell die Organisation tatsächlich unterstützen kann. Azure IoT Operations bietet breitere standortbezogene Fähigkeiten, bringt aber auch Verantwortung für Kubernetes, Arc, Cluster-Betrieb, Monitoring, Speicher, Patching und Wiederherstellung mit sich.

MQTT ALS RÜCKGRAT DER FABRIK-EREIGNISSE
Wenn mehrere Verbraucher dieselben Maschinenereignisse benötigen, kann MQTT die Architektur deutlich vereinfachen. Der Maschinenkonnektor veröffentlicht einmal an einen Broker, und Instandhaltungsanwendungen, lokale Historians, Cloud-Datenflüsse oder andere freigegebene Verbraucher abonnieren unabhängig voneinander.

Das beseitigt viele Punkt-zu-Punkt-Abhängigkeiten. Eine neue Anwendung kann ein freigegebenes Topic abonnieren, ohne eine weitere direkte Verbindung zur SPS oder zum OPC-UA-Server zu schaffen.

Das Design der Topics bleibt trotzdem wichtig. Eine Hierarchie kann Standort, Bereich, Linie, Zelle und Anlage abbilden, das Topic sollte aber nicht das gesamte Datenmodell werden. Wichtige Fakten wie Ereignisidentität, Quellzeitstempel, Anlagen-ID, Qualität, Vertragsversion und Ereignistyp sollten im Nachrichten-Payload erhalten bleiben, damit das Ereignis auch dann verständlich bleibt, wenn es gespeichert, wiedergegeben oder anderswo weitergeleitet wird.

DER UNIFIED NAMESPACE IST EIN VERTRAG — NICHT NUR EIN TOPIC-BAUM
Das Muster des Unified Namespace kann einen gemeinsamen betrieblichen Vertrag über industrielle Systeme hinweg schaffen. Der Nutzen liegt nicht einfach darin, eine riesige MQTT-Hierarchie zu haben. Der Wert entsteht dadurch, dass vereinbart wird, wie Anlagen identifiziert werden, wie Ereignisse aufgebaut sind, wer die Daten besitzt, wie sich Schemata ändern und welche Systeme für welche Fakten maßgeblich sind.

Ein guter Unified Namespace kann eine stabile Möglichkeit bieten, Anlagen zu identifizieren und gesteuerte betriebliche Ereignisse zu veröffentlichen, während Quellsysteme die Verantwortung für ihre eigenen Datensätze behalten.

Dieser Vertrag sollte unter anderem festlegen:
• Anlagenidentität
• Ereignistypen
• Nachrichtenstruktur
• Regeln für Zeitstempel
• Qualitätsinformationen
• Verantwortlichkeit
• Sicherheit
• Versionierung
• Änderungsmanagement

MQTT kann den Vertrag transportieren, aber MQTT erzeugt den Vertrag nicht.

VON DER OPC-UA-BENACHRICHTIGUNG ZUM MQTT-EREIGNIS
Die Umwandlung einer OPC-UA-Benachrichtigung in ein MQTT-Ereignis ist mehr als eine Protokollübersetzung. Der Konnektor nee