IFM-Sensoren und MQTT im industriellen Energiemonitoring: Was wirklich funktioniert

TL;DR: IFM-Sensoren liefern Prozess- und Zustandsdaten (Druck, Temperatur, Schwingung), die per MQTT in zentrale Energiemonitoring-Plattformen fließen können. Der Mehrwert entsteht nicht durch die Sensor-Hardware allein, sondern durch saubere Datenpipelines, konsistente Zeitstempel und eine klare Trennung von Prozess- und Energiedaten. Dieser Artikel beschreibt Architektur, Anwendungsfälle und typische Fallstricke.

Was IFM-Sensoren messen – und was nicht

IFM Electronic ist ein Automatisierungstechnik-Anbieter, dessen Sensoren in Fertigungsanlagen, Biogasanlagen und der Gebäudetechnik eingesetzt werden. Das Portfolio umfasst Positions-, Druck-, Temperatur-, Füllstand- und Schwingungssensoren sowie IO-Link-fähige Geräte, die sich über standardisierte Schnittstellen in übergeordnete Systeme einbinden lassen.

Wichtig für die Einordnung: IFM-Sensoren sind primär Prozesssensoren, keine Energiemessgeräte im Sinne von MID-geeichten Zählern. Sie erfassen physikalische Zustandsgrößen einer Maschine oder Anlage – etwa die Lagertemperatur eines Motors oder die Vibration einer Pumpe. Energieverbrauchsdaten im abrechnungsrelevanten Sinne liefern sie nicht; dafür sind geeichte Energiezähler zuständig.

Diese Unterscheidung ist in der Praxis relevant, weil viele Ansätze scheitern, wenn Prozessdaten und Energiedaten ohne saubere Konzeption zusammengeführt werden.

MQTT als Transportprotokoll: Stärken und Grenzen

MQTT (Message Queuing Telemetry Transport) ist ein schlankes Publish-Subscribe-Protokoll, das ursprünglich für ressourcenschwache Geräte mit instabilen Verbindungen entwickelt wurde. IFM unterstützt MQTT bei neueren Geräten nativ oder über IO-Link-Master mit MQTT-Bridge.

Die Stärken von MQTT im Industriekontext:

• Geringer Overhead bei hoher Nachrichtenfrequenz – geeignet für Sensoren mit kurzen Messintervallen
• Asynchrone Übertragung – Broker puffert Nachrichten, falls der Empfänger kurzzeitig nicht erreichbar ist
• Einfaches Verbindungsmodell – Sensoren müssen keine dauerhafte TCP-Verbindung halten

Die Grenzen:

• MQTT garantiert keine Zeitstempel auf Sensorseite – der Broker-Empfangszeitstempel weicht bei Netzlatenzen vom tatsächlichen Messzeitpunkt ab
• MQTT ist kein Protokoll für sicherheitskritische Steuerungen; für bidirektionale Regelkreise sind OPC-UA oder Feldbussysteme besser geeignet
• QoS-Level 0 (Fire and Forget) führt unter Last zu Datenlücken, die in Zeitreihenauswertungen als Nullwerte oder Artefakte erscheinen können

Anwendungsfälle mit realem Nutzen

Aus der Praxis haben sich einige Anwendungsszenarien als besonders sinnvoll erwiesen:

Condition Monitoring an rotierenden Maschinen: Schwingungssensoren an Pumpen, Kompressoren und Rührwerken können Lagerabnutzung oder Unwuchten erkennen, bevor es zu Ausfällen kommt. Der Nutzen liegt in der Möglichkeit, Wartungsintervalle bedarfsgerecht statt kalenderbasiert zu planen.

Temperaturüberwachung in Biogasanlagen: Fermentertemperaturen müssen in engen Bändern gehalten werden. IFM-Temperaturfühler, die per MQTT an ein zentrales Monitoring angebunden sind, ermöglichen frühzeitige Alarmierung bei Abweichungen.

Korrelation von Prozess- und Energiedaten: Wenn Energiezählerwerte und Prozesssensordaten auf einer gemeinsamen Zeitachse vorliegen, lassen sich spezifische Energieverbräuche je Produktionsschritt ableiten – eine Grundlage für Effizienzanalysen nach ISO 50001.

Lastspitzenmanagement: Kombiniert mit Leistungsmessung kann der Anlaufstrom energieintensiver Antriebe überwacht und der Startzeitpunkt koordiniert werden, um Lastspitzen im Netzanschluss zu begrenzen.

Stolperfallen aus der Praxis

Zeitstempel-Probleme: Das häufigste technische Problem bei MQTT-basierten Setups ist die fehlende oder inkonsistente Zeitstempelung auf Geräteebene. Wenn der Zeitstempel erst beim Broker-Eingang gesetzt wird, entstehen bei vielen gleichzeitig aktiven Sensoren und variabler Netzlast systematische Verschiebungen in den Zeitreihen. Abhilfe: NTP-Synchronisation auf allen IO-Link-Mastern, Zeitstempel im MQTT-Payload statt im Broker.

Topic-Struktur ohne Konzept: MQTT-Topics wachsen schnell chaotisch, wenn kein klares Namensschema definiert wird. Spätere Reorganisationen sind aufwendig, weil bestehende Consumer angepasst werden müssen. Empfehlenswert ist eine hierarchische Struktur wie anlage/bereich/gerät/messgröße von Beginn an.

Datenmenge vs. Speicherkosten: IFM-Sensoren können mit hoher Frequenz senden. Ohne Downsampling oder Edge-Aggregation landen große Datenmengen in der Datenbank, von denen ein Großteil für Energiemonitoring-Zwecke überflüssig ist. Minutenmittelwerte reichen für Energieanalysen meist aus; Rohsignale sollten nur für Condition-Monitoring-Zwecke mit hoher Frequenz gespeichert werden.

Fehlende Metadaten: Ein Sensorwert ohne Kontext – ohne Einheit, ohne Gerätezuordnung, ohne Kalibrierungsdatum – ist in der Auswertung wertlos. Gerätebeschreibungen (etwa über IO-Link Device Description Files) sollten von Beginn an in das System importiert werden.

Netzwerksegmentierung: Industriesensoren sollten in einem eigenen VLAN betrieben werden, getrennt vom Office-Netz. Ungepatchte Firmware auf Feldgeräten ist ein bekanntes Angriffsszenario; die Segmentierung begrenzt den möglichen Schaden.

Fazit

IFM-Sensoren in Verbindung mit MQTT sind ein praxistauglicher Weg, um Prozessdaten in ein zentrales Energiemonitoring einzuspeisen. Der technische Aufwand für die Integration ist überschaubar – der konzeptionelle Aufwand wird jedoch regelmäßig unterschätzt. Zeitstempelkonsistenz, Topic-Struktur, Datensparsamkeit und Metadatenpflege entscheiden darüber, ob das System nach einem Jahr noch nutzbar ist oder im Datenchaos versinkt.

Der eigentliche Wert liegt nicht in der Hardware, sondern in der Verbindung von Prozesszustand und Energieverbrauch auf einer gemeinsamen Zeitachse – als Grundlage für fundierte Betriebsentscheidungen.

FAQ

q

a

q

a

q

a

q

a