Energiemonitoring in der Fabrik gibt jeder Linie, jeder Schicht und jedem Produkt einen messbaren Energie-Fußabdruck statt einer einzigen monatlichen Stromrechnung. In diesem Leitfaden planen Sie die Zähleranordnung, entwerfen eine MQTT-Topic-Struktur, die von einem Gebäude bis zu mehreren Standorten skaliert, speichern Zählerstände korrekt und bauen Berichte, die kWh pro Linie, pro Schicht und pro Teil zeigen.
Warum die Stromrechnung nicht ausreicht
Die monatliche Rechnung sagt Ihnen, was das Werk verbraucht hat, aber nicht warum. Sie kann die Lackiererei nicht von der Montagelinie trennen, eine produktive Schicht nicht von einem Wochenende im Leerlauf und eine gut eingestellte Maschine nicht von einer, deren Hydraulikpumpe auf Volllast läuft, während sie auf Teile wartet. Ohne diese Aufschlüsselung bleibt Energie ein Gemeinkostenblock, für den sich niemand verantwortlich fühlt.
Ein Energiemonitoring-System in der Fabrik verändert das Gespräch. Sieht ein Linienverantwortlicher, dass seine Linie am Samstag ohne Produktion ähnlich viel Energie verbraucht hat wie in einer normalen Schicht, beantwortet sich die Frage „Was lief da?“ von selbst. Steht die Energie pro Teil neben der OEE, wird Energie zu einer Produktionskennzahl statt zu einem Problem der Haustechnik.
Die Bausteine eines Energiemonitoring-Systems in der Fabrik
| Ebene | Typische Komponenten | Rolle |
|---|---|---|
| Messung | Hauptzähler des Versorgers, Unterzähler pro Abgang, Linie und großer Maschine; Zähler für Gas, Wasser und Druckluft | Liefern rohe Zählerstände und Momentanwerte |
| Edge | Modbus-Gateway, SPS, Industrie-PC oder Raspberry Pi mit Node-RED oder Python | Zähler abfragen, Zeitstempel ergänzen, per MQTT veröffentlichen |
| Transport | MQTT-Broker | Publisher und Consumer entkoppeln, Live-Daten zustellen |
| Speicherung | Zeitreihendatenbank wie InfluxDB oder TimescaleDB, über Telegraf oder einen eigenen Subscriber | Historie für Berichte vorhalten |
| Kontext | Produktionsplan, Maschinenzustände, Stückzahlen | Aus kWh Energie pro Schicht und pro Teil machen |
| Darstellung | Grafana, Node-RED-Dashboard, BI-Werkzeug | Trends, Vergleiche und Alarme anzeigen |
Der MQTT-Broker ist das Scharnier der Architektur. Zähler veröffentlichen einmal; Historian, Live-Dashboard, ein Alarmskript und eine künftige MES-Anbindung abonnieren unabhängig voneinander. Wenn Sie entscheiden müssen, wo dieser Broker laufen soll, hält ihn ein vollständig verwalteter MQTT-Broker verfügbar, ohne dem Instandhaltungsteam einen weiteren Server aufzubürden.
Schritt 1: Festlegen, wo gemessen wird
Gehen Sie vom einpoligen Stromlaufplan und der Liste der wesentlichen Energieverbraucher aus. Eine verbreitete, kostengünstige Reihenfolge:
- Einspeisung: der Hauptzähler, idealerweise alle paar Sekunden ausgelesen, statt sich auf die 15-Minuten-Werte des Versorgers zu verlassen.
- Hauptverteilungsabgänge: ein Zähler pro Gebäude, Halle oder größerem Bereich.
- Produktionslinien: ein Zähler pro Linienverteiler.
- Große Einzelverbraucher: Kompressoren, Kältemaschinen, Öfen, Spritzgießmaschinen, große Pressen.
- Weitere Medien: Erdgas, Dampf, Wasser und Druckluftdurchfluss.
Jeder Schritt erhöht die Auflösung. Sie brauchen nicht alles am ersten Tag; Sie brauchen genug, um die erste geschäftliche Frage zu beantworten. Die detaillierte Verdrahtung und die Modbus-Abfrage für Schritt drei und vier behandelt das Tutorial zu Strom-Submetering.
Schritt 2: Die Topic-Struktur entwerfen
Eine Topic-Hierarchie auf Basis von ISA-95 (Unternehmen, Standort, Bereich, Linie, Zelle) hält Daten auffindbar und entspricht der Art, wie Menschen über das Werk denken. Genau diese Struktur bildet den Unified Namespace (UNS): Die ISA-95-Ebenen werden zu Topic-Ebenen auf dem MQTT-Broker, sodass Energiedaten direkt neben Maschinenzuständen und Stückzahlen derselben Linie liegen. ConnectMQ erkennt Topics im Stil von ISA-95 und Unified Namespace und zeigt Geräte im Portal nach diesen Ebenen an.
connectmq/<site>/<area>/<line>/<asset>/energy
connectmq/plant1/assembly/line1/main-board/energy
connectmq/plant1/assembly/line2/main-board/energy
connectmq/plant1/molding/imm-04/drive/energy
connectmq/plant1/utilities/compressors/comp1/energy
Ein Zähler-Payload sollte sowohl kumulierte Zählerstände als auch Momentanwerte enthalten:
{
"ts": 1760600000,
"kwh_total": 183452.7,
"kw": 42.6,
"kvar": 11.2,
"pf": 0.97,
"v_l1": 231.4,
"i_l1": 61.8
}
Veröffentlichen Sie kwh_total als das zählereigene kumulierte Register, niemals als Wert, den das Gateway aus Leistungswerten aufsummiert. Zählerstände überstehen Gateway-Neustarts und verpasste Nachrichten: Gehen drei Nachrichten verloren, enthält der nächste Zählerstand trotzdem die dazwischen verbrauchte Energie.
Schritt 3: Die Daten speichern
Der MQTT-Consumer von Telegraf ist ein schneller Weg, die Daten in InfluxDB zu bringen, wobei Tags aus den Topic-Ebenen extrahiert werden. Er verbindet sich als normaler MQTT-Client mit dem Broker:
[[inputs.mqtt_consumer]]
servers = ["ssl://broker.connectmq.com:8883"]
topics = ["connectmq/plant1/+/+/+/energy"]
client_id = "YOUR_CLIENT_ID"
username = "YOUR_USERNAME"
password = "YOUR_PASSWORD"
qos = 1
persistent_session = true
data_format = "json_v2"
[[inputs.mqtt_consumer.topic_parsing]]
topic = "connectmq/+/+/+/+/energy"
tags = "_/site/area/line/asset/_"
[[inputs.mqtt_consumer.json_v2]]
measurement_name = "energy"
timestamp_path = "ts"
timestamp_format = "unix"
[[inputs.mqtt_consumer.json_v2.field]]
path = "kwh_total"
type = "float"
[[inputs.mqtt_consumer.json_v2.field]]
path = "kw"
type = "float"
[[inputs.mqtt_consumer.json_v2.field]]
path = "pf"
type = "float"
[[outputs.influxdb_v2]]
urls = ["http://localhost:8086"]
token = "${INFLUX_TOKEN}"
organization = "plant"
bucket = "energy"
Eine persistente Session mit QoS 1 bedeutet, dass der Broker Nachrichten, die während eines Telegraf-Neustarts veröffentlicht werden, für ihn zwischenspeichert (innerhalb der Session-Ablaufzeit).
Schritt 4: Energie pro Linie und pro Schicht
Da Sie Zählerstände speichern, ist die Energie für einen beliebigen Zeitraum einfach der Zählerstand am Ende minus der Zählerstand am Anfang. In der Flux-Sprache von InfluxDB sieht kWh pro Linie für eine Schicht so aus:
from(bucket: "energy")
|> range(start: 2026-10-15T06:00:00Z, stop: 2026-10-15T14:00:00Z)
|> filter(fn: (r) => r._measurement == "energy" and r._field == "kwh_total")
|> spread()
|> group(columns: ["line"])
|> sum()
spread() liefert Maximum minus Minimum pro Zähler, was bei einem monoton steigenden Zähler dem Verbrauch entspricht; Gruppierung und Summe addieren die Zähler jeder Linie. Achten Sie auf Zählertausch oder Zählerüberläufe, die einen Sprung nach unten erzeugen; markieren Sie diese in den Daten, statt sie stillschweigend zu korrigieren.
Schichtgrenzen gehören in die Konfiguration, nicht fest in Abfragen. Eine kleine Tabelle mit Schichtbeginn und -ende pro Standort oder Schichtereignisse, die das MES auf einem Topic .../shift veröffentlicht, lassen dasselbe Dashboard in jedem Werk funktionieren.
Schritt 5: Energie pro Teil
Energie pro Teil (oder pro Tonne, pro Charge, pro Quadratmeter) ist die Kennzahl, die Energie mit der Produktion verbindet. Sie benötigen die Stückzahl für dieselbe Linie und denselben Zeitraum, die Ihre Stückzahlerfassung neben den Energiedaten veröffentlichen kann:
energy_per_part = kWh(line, shift) / good_parts(line, shift)
Verwenden Sie Gutteile, nicht die Gesamtstückzahl, damit sich Ausschuss ebenfalls als Energiekosten zeigt. Vergleichen Sie den Wert über Schichten und Produkte hinweg, aber denken Sie daran, dass er nie null ist: Die Grundlast einer Linie im Leerlauf verteilt sich in einer langsamen Schicht auf weniger Teile. Wer Grundlast und variable Last trennt, zum Beispiel mit einer einfachen Regression von kWh gegen Stückzahl, erhält ein faireres Bild und die Basis für die energetischen Ausgangsbasen, die ISO 50001 fordert – erklärt im Beitrag zum Erfassen von Energiedaten nach ISO 50001.
Dashboards, die tatsächlich genutzt werden
Eine sinnvolle Auswahl an Ansichten für verschiedene Zielgruppen:
| Zielgruppe | Ansicht | Aktualisierung |
|---|---|---|
| Linienverantwortliche | Live-kW der eigenen Linie, kWh dieser Schicht vs. Ziel, Leerlaufverbrauch seit dem letzten Teil | Sekunden bis Minuten |
| Werksleitung | kWh pro Linie und Tag, Trend der Energie pro Teil, Top-10-Verbraucher | Täglich |
| Energiemanagement | Grundlast nachts und am Wochenende, Spitzenlast, Leistungsfaktor, Vergleich mit der Ausgangsbasis | Täglich und monatlich |
| Instandhaltung | Auffälliger Verbrauch pro Maschine, spezifische Leistung der Kompressoren, Leckageschätzung | Live und wöchentlich |
Die Grundlast nachts und am Wochenende ist oft der schnellste Hebel. Stellen Sie den Verbrauch von Freitagabend bis Montagmorgen pro Bereich dar: Alles, was flach und hoch verläuft, verdient einen Rundgang. Druckluft ist ein häufiger Verursacher, und die Überwachung von Druckluftleckagen beziffert sie.
Alarme
Live-Alarme funktionieren am besten für Zustände, auf die jemand sofort reagieren kann: eine Linie, die lange nach Schichtende noch Leistung zieht, eine Last, die sich einer vertraglich vereinbarten Spitze nähert, ein Leistungsfaktor, der unter die Strafschwelle fällt. Im ConnectMQ-Portal definieren Sie Schwellwert-Alarmregeln auf numerischen Feldern wie kw oder pf, und Überschreitungen erscheinen im Alarmprotokoll. Die Weiterleitung dieser Ereignisse per E-Mail oder Chat übernimmt ein externer Subscriber wie Node-RED.
Häufige Fehler
- Leistung aufsummieren statt Energiezählerstände lesen. Verlorene Messwerte werden zu verlorenen kWh.
- Nicht synchronisierte Uhren. Gateways ohne NTP verschieben Daten zwischen Schichten. Vergeben Sie Zeitstempel am Edge mit synchronisierter Zeit.
- Fehler im Wandlerverhältnis. Ein falsches Stromwandlerverhältnis in der Zählerkonfiguration vervielfacht jeden Messwert. Prüfen Sie jeden Zähler einmal mit einer Stromzange.
- Zu viele Dashboards, kein Verantwortlicher. Weisen Sie die Energiekennzahl jeder Linie ihrem Verantwortlichen zu.
- Daten in einem Werkzeug gefangen. Veröffentlichen Sie alles zuerst an den Broker; Werkzeuge kommen und gehen, die Topic-Struktur bleibt.
Die übergeordnete Roadmap der vernetzten Produktion, einschließlich der Rolle der Energie neben OEE, Qualität und Instandhaltung, beschreibt der Leitfaden zu Smart Manufacturing.
Betreiben Sie Ihr Energiemonitoring mit ConnectMQ
ConnectMQ ist ein Cloud-MQTT-Broker mit TLS auf Port 8883, MQTT 5, einer ISA-95-fähigen Geräteansicht, einem Live-Topic-Explorer und Schwellwertalarmen. Testen Sie Ihren ersten Zähler auf dem Öffentlichen MQTT-Broker, erstellen Sie dann einen kostenlosen Serverless-Broker ohne Kreditkarte und skalieren Sie auf kostenpflichtige oder dedizierte Tarife, wenn weitere Zähler hinzukommen.
Häufig gestellte Fragen
Wie viele Zähler braucht Energiemonitoring in der Fabrik?
Beginnen Sie mit der Einspeisung, einem Zähler pro Produktionslinie und Zählern an den größten Einzelverbrauchern. Das reicht meist, um die ersten Einsparungen zu finden, und weitere Zähler lassen sich später ergänzen, ohne die Architektur zu ändern.
Wie oft sollten Energiezähler veröffentlichen?
Typisch sind 5 bis 60 Sekunden. Schnelleres Veröffentlichen hilft Live-Dashboards und Lastalarmen, während Berichte auf dem kumulierten Zählerstand beruhen und vom Intervall nicht beeinflusst werden.
Kann ich vorhandene Modbus-Zähler verwenden?
Ja. Ein Gateway fragt die Zähler über Modbus RTU oder TCP ab und veröffentlicht die Werte als JSON per MQTT. Die meisten modernen Multifunktionszähler stellen Energiezählerstände und Momentanwerte in dokumentierten Registern bereit.
Speichert ConnectMQ historische Energiedaten?
Nein. ConnectMQ stellt Live-Nachrichten und Retained-Werte zu. Die Langzeithistorie speichert ein Subscriber wie Telegraf, der in eine Zeitreihendatenbank schreibt.
