Ein Dashboard zur Produktionslinienüberwachung verwandelt rohe Maschinensignale in einen einzigen Bildschirm, der Schichtleitern zeigt, ob die Linie läuft, wie viele Gutteile gefertigt wurden und wo Zeit verloren geht. In diesem Tutorial veröffentlichen Sie Stationsdaten per MQTT, speichern sie mit Telegraf und InfluxDB und bauen das Dashboard in Grafana – mit einer schlankeren Node-RED-Alternative für kleine Linien. Alles läuft gegen einen echten Broker, sodass Sie direkt am Laptop mitmachen können.
Was ein gutes Produktionslinien-Dashboard zeigt
Bevor Sie etwas verdrahten, legen Sie fest, welche Fragen der Bildschirm beantworten muss. Die meisten Linien-Dashboards scheitern, weil sie jeden Tag anzeigen, den die SPS bereitstellt, statt der Handvoll Fragen, die während einer Schicht tatsächlich gestellt werden.
| Frage in der Halle | Benötigtes Signal | Typisches Widget |
|---|---|---|
| Läuft jede Station gerade? | state (RUNNING, IDLE, DOWN, SETUP) |
Farbcodierte Statuskacheln |
| Liegen wir im Schichtplan? | Gutteile, Planmenge | Große Zahl plus Fortschrittsbalken |
| Woher kommt der Ausschuss? | Ausschuss pro Station | Balkendiagramm nach Station |
| Welche Station ist der Engpass? | Ist-Takt vs. Ideal-Takt | Tabelle sortiert nach Taktlücke |
| Wie gesund ist die Linie insgesamt? | Verfügbarkeit, Leistung, Qualität | OEE-Anzeige mit drei Teilbalken |
| Was hat uns in der letzten Stunde gestoppt? | Zustandswechsel mit Zeitstempel | Zustandszeitleiste |
Beschränken Sie die erste Version auf diese sechs. Schichtleiter fordern mehr, sobald sie den Zahlen vertrauen – und Vertrauen entsteht, wenn die Stückzahlen mit dem übereinstimmen, was sie in der Halle sehen.
Architektur: Von der Station auf den Bildschirm
Der Datenpfad ist kurz, und jede Komponente ist austauschbar:
- Jede Station (SPS-Gateway, Edge-PC oder Mikrocontroller) veröffentlicht bei jedem Zustandswechsel und mindestens alle paar Sekunden eine kleine JSON-Statusnachricht an einen MQTT-Broker.
- Telegraf abonniert die Topics der Linie und schreibt jede Nachricht als Zeitreihe in InfluxDB.
- Grafana fragt InfluxDB ab und rendert die Panels.
- Optional abonniert ein Node-RED-Flow dieselben Topics und steuert ein schlankes Dashboard auf einem Fernseher neben der Linie.
Der Broker ist die Drehscheibe, die Stationen und Verbraucher entkoppelt. Wenn Ihnen diese Rolle neu ist, erklärt dieser Beitrag darüber, was ein MQTT-Broker macht, die Grundlagen. Da jeder Verbraucher unabhängig abonniert, können Sie später einen Historian, ein Andon-Board oder einen OEE-Rechner hinzufügen, ohne die Stationen anzufassen.
Schritt 1: Die Topic-Struktur entwerfen
Ein vorhersehbarer Topic-Baum spart später Stunden. Verwenden Sie eine Hierarchie im ISA-95-Stil, damit das Dashboard mit Wildcards nach Linie und Station filtern kann:
connectmq/demo/<your-id>/line1/<station>/status
Zum Beispiel connectmq/demo/a7f3k9/line1/filler/status. Der Payload ist ein einzelnes JSON-Objekt:
{
"state": "RUNNING",
"good": 1842,
"reject": 17,
"rate": 58.5,
"ideal_rate": 60,
"ts": 1792137600
}
Die Zähler sind für die Schicht kumulativ, was die Daten robust macht: Geht eine Nachricht verloren, trägt die nächste trotzdem die korrekte Summe. Takte werden in Teilen pro Minute angegeben. Ergänzen Sie vor der Linie eine Unternehmens- und Standortebene, wenn Sie auf mehr als ein Werk ausrollen.
Genau diese ISA-95-Ebenen (Enterprise → Site → Area → Line → Cell) bilden die Topic-Struktur eines Unified Namespace (UNS) auf dem MQTT-Broker, etwa acme/werk-stuttgart/abfuellung/linie-1/fueller/status. So wird das Linien-Dashboard zum ersten Baustein eines werksweiten UNS, den MES, ERP und weitere Anwendungen später mitnutzen. Wie das mit Sparkplug B zusammenspielt, zeigt der Beitrag zu Sparkplug B und Unified Namespace.
Schritt 2: Die Stationen simulieren
Um das Dashboard zu bauen, bevor die echte Linie angeschlossen ist, starten Sie diesen Python-Simulator. Er nutzt paho-mqtt 2.x und den kostenlosen öffentlichen MQTT-Broker unter broker.connectmq.com. Ersetzen Sie a7f3k9 durch Ihre eigene zufällige ID, denn der öffentliche Bereich ist für alle lesbar.
import json
import random
import time
import paho.mqtt.client as mqtt
PREFIX = "connectmq/demo/a7f3k9/line1"
STATIONS = {"filler": 60, "capper": 62, "labeler": 65, "packer": 58}
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="line1-sim-a7f3k9")
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_start()
counters = {name: {"good": 0, "reject": 0, "state": "RUNNING"} for name in STATIONS}
try:
while True:
for name, ideal in STATIONS.items():
c = counters[name]
# Gelegentlich den Zustand wechseln, damit das Dashboard interessant bleibt
roll = random.random()
if c["state"] == "RUNNING" and roll < 0.03:
c["state"] = random.choice(["DOWN", "IDLE"])
elif c["state"] != "RUNNING" and roll < 0.25:
c["state"] = "RUNNING"
rate = 0.0
if c["state"] == "RUNNING":
rate = round(ideal * random.uniform(0.85, 1.0), 1)
made = int(rate / 12) # etwa 5 Sekunden Produktion
rejects = 1 if random.random() < 0.04 else 0
c["good"] += made - rejects
c["reject"] += rejects
payload = {
"state": c["state"],
"good": c["good"],
"reject": c["reject"],
"rate": rate,
"ideal_rate": ideal,
"ts": int(time.time()),
}
client.publish(f"{PREFIX}/{name}/status", json.dumps(payload), qos=1, retain=True)
time.sleep(5)
except KeyboardInterrupt:
client.loop_stop()
client.disconnect()
Vier Stationen, die alle fünf Sekunden senden, bleiben deutlich unter dem Limit des öffentlichen Brokers von 10 Nachrichten pro Sekunde und Client. Durch das Retain-Flag erhält ein Dashboard, das sich mitten in der Schicht verbindet, sofort den letzten bekannten Zustand jeder Station. Prüfen Sie den Datenstrom im Terminal:
mosquitto_sub -h broker.connectmq.com -p 1883 -i viewer-a7f3k9 -t "connectmq/demo/a7f3k9/line1/+/status" -v
Schritt 3: Daten mit Telegraf und InfluxDB speichern
Der MQTT-Consumer von Telegraf macht aus jeder Nachricht einen InfluxDB-Punkt, und das Topic-Parsing extrahiert Linie und Station als Tags. Speichern Sie dies als telegraf.conf:
[agent]
interval = "5s"
flush_interval = "5s"
[[inputs.mqtt_consumer]]
servers = ["tcp://broker.connectmq.com:1883"]
topics = ["connectmq/demo/a7f3k9/line1/+/status"]
client_id = "telegraf-a7f3k9"
qos = 1
data_format = "json"
json_string_fields = ["state"]
json_time_key = "ts"
json_time_format = "unix"
[[inputs.mqtt_consumer.topic_parsing]]
topic = "connectmq/demo/+/+/+/status"
measurement = "_/_/_/_/_/measurement"
tags = "_/_/_/line/station/_"
[[outputs.influxdb_v2]]
urls = ["http://localhost:8086"]
token = "YOUR_INFLUX_TOKEN"
organization = "plant"
bucket = "line"
Jeder Punkt landet im Measurement status mit den Tags line=line1 und station=filler sowie den Feldern state, good, reject, rate und ideal_rate. Für den Produktivbetrieb stellen Sie den Server auf ssl://broker.connectmq.com:8883 um und ergänzen username = "YOUR_USERNAME", password = "YOUR_PASSWORD" sowie Ihre zugewiesene client_id. Weitere Optionen finden Sie im Leitfaden zum Telegraf-MQTT-Consumer.
Schritt 4: Das Dashboard zur Produktionslinienüberwachung in Grafana bauen
Fügen Sie InfluxDB in Grafana als Datenquelle hinzu (Abfragesprache Flux) und erstellen Sie diese Panels.
Statuskacheln der Stationen. Verwenden Sie ein Stat-Panel mit Value Mappings: RUNNING grün, IDLE gelb, DOWN rot, SETUP blau.
from(bucket: "line")
|> range(start: -5m)
|> filter(fn: (r) => r._measurement == "status" and r._field == "state")
|> last()
|> group(columns: ["station"])
Gutteile in dieser Schicht. Da die Zähler kumulativ sind, ist der letzte Wert die Summe:
from(bucket: "line")
|> range(start: today())
|> filter(fn: (r) => r._measurement == "status" and r._field == "good" and r.station == "packer")
|> last()
Verwenden Sie die letzte Station der Linie (hier den Packer) als Linienausbringung; wer an jeder Station zählt, zählt doppelt.
Takt vs. Ideal. Ein Time-series-Panel mit rate und ideal_rate pro Station zeigt den Engpass auf einen Blick: die Station, deren Ist-Takt im Betrieb am weitesten unter ihrem Idealwert liegt.
Zustandszeitleiste. Das State-timeline-Panel von Grafana, gespeist aus dem Feld state, zeigt pro Station einen nach Zustand eingefärbten Balken über die gesamte Schicht – der schnellste Weg, um zu sehen, wann und wo die Linie stand.
OEE-Anzeige. Für eine erste Version berechnen Sie die OEE in einem separaten Subscriber, veröffentlichen das Ergebnis auf line1/oee und stellen dieses Topic grafisch dar. Die Rechnung wird in OEE berechnen erklärt, und das Tutorial zur OEE-Überwachung in Echtzeit enthält einen fertigen Subscriber. Wenn die Berechnung einmal außerhalb von Grafana erfolgt, zeigt jeder Bildschirm dieselbe Zahl.
Node-RED-Alternative für eine einzelne Linie
Wenn Sie nur einen Fernseher neben einer Linie brauchen und keine Zeitreihendatenbank möchten, ist Node-RED schneller. Konfigurieren Sie einen mqtt-broker-Config-Node mit dem Server broker.connectmq.com und Port 1883 (im Produktivbetrieb 8883 mit TLS und Ihren Zugangsdaten) und fügen Sie hinzu:
- Einen
mqtt in-Node, derconnectmq/demo/a7f3k9/line1/+/statusabonniert, mit Ausgabe als geparstes JSON-Objekt. - Einen
function-Node, der den Stationsnamen ausmsg.topic.split("/")[4]extrahiert und an das richtige Widget weiterleitet. - Dashboard-2.0-Widgets:
ui-textfür den Zustand,ui-gaugefür den Takt und einui-chartfür die Gutteile.
Der Kompromiss ist die Historie: Node-RED zeigt die Gegenwart gut, ist aber kein Historian. Viele Werke betreiben beides – Node-RED auf der Linienanzeige und Grafana für die Schichtauswertung. Der Artikel zum Node-RED-OEE-Dashboard vertieft diesen Ansatz.
Typische Stolperfallen und ihre Lösung
- Zähler springen mitten in der Schicht auf null. Ein Neustart von SPS oder Gateway löscht den Zähler. Speichern Sie die Schicht-Basislinie am Edge, oder lassen Sie das Dashboard
difference()mitnonNegative: trueverwenden, damit Resets keine negative Produktion erzeugen. - Kacheln zeigen veraltetes RUNNING. Geht eine Station offline, meldet ihre Retained Message weiterhin RUNNING. Zeigen Sie das Feld
tsin der Kachel an und färben Sie sie grau, wenn es älter als 30 Sekunden ist, oder nutzen Sie eine MQTT-Last-Will-Nachricht, die OFFLINE veröffentlicht. - Doppelte Client-IDs. Zwei Telegraf-Instanzen mit derselben Client ID werfen sich gegenseitig ständig hinaus. Jeder Client braucht eine eindeutige ID.
- Zu viele Panels. Muss man auf dem Hallenbildschirm scrollen, ist er überladen. Verlagern Sie Details in ein Drill-down-Dashboard.
Von der Demo in den Produktivbetrieb
Der öffentliche MQTT-Broker eignet sich perfekt für den Aufbau, aber seine Topics sind für jeden sichtbar. Für eine echte Linie wechseln Sie auf einen privaten Broker: Ein verwalteter MQTT-Broker nimmt Ihnen das Patchen und Skalieren eines Servers ab, und mit einem Cloud-MQTT-Broker sehen Schichtleiter an anderen Standorten und die Zentrale dasselbe Dashboard. Mit ConnectMQ legen Sie den Broker im Portal an, erhalten Benutzername, Passwort und Client ID und ändern im Simulator, in Telegraf und in Node-RED nur die Verbindungseinstellungen. Der Live-Topic-Explorer im Portal hilft zu bestätigen, dass jede Station sendet, bevor Sie ein leeres Grafana-Panel debuggen.
Der kostenlose Tarif Serverless (Free) unterstützt bis zu 25 Verbindungen – genug für eine Pilotlinie mit Gateway, Telegraf und ein paar Dashboards. Größere Werke wechseln typischerweise auf Serverless (Paid) oder einen Dedicated-Cluster, sobald weitere Linien hinzukommen. Zur übergeordneten Strategie siehe den Leitfaden für Smart Manufacturing.
Jetzt mit ConnectMQ starten
Erstellen Sie unter app.connectmq.com einen kostenlosen Broker im Serverless-Tarif ohne Kreditkarte, richten Sie Ihre Stationen und Telegraf darauf aus und betreiben Sie noch heute ein Produktionslinien-Dashboard auf privater Infrastruktur.
Häufig gestellte Fragen
Sollte ich Grafana oder Node-RED für ein Produktionslinien-Dashboard verwenden?
Nutzen Sie Grafana, wenn Sie Historie, Schichtvergleiche und viele Benutzer brauchen; nutzen Sie Node-RED für eine schnelle Live-Anzeige an einer Linie. Viele Teams betreiben beides auf denselben MQTT-Topics.
Wie oft sollten Stationen ihren Status veröffentlichen?
Veröffentlichen Sie sofort bei jedem Zustandswechsel und senden Sie alle 5 bis 10 Sekunden einen Heartbeat. So bleiben die Kacheln aktuell, ohne den Broker zu fluten.
Kann ich SPSen direkt anbinden?
Die meisten SPSen brauchen ein Edge-Gateway (Node-RED, einen Protokollumsetzer oder den eigenen MQTT-Client der SPS), das Tags liest und JSON an den Broker veröffentlicht. Sobald die Daten auf MQTT liegen, ist es dem Dashboard egal, woher sie stammen.
Ist der öffentliche Broker sicher für echte Produktionsdaten?
Nein. Der öffentliche Bereich von broker.connectmq.com ist für jeden lesbar. Nutzen Sie ihn daher nur für Tests und verlagern Sie Produktionsdaten auf einen privaten ConnectMQ-Broker mit Zugangsdaten und TLS.
