WAGO über MQTT an ein SCADA-System anbinden

Du willst Prozessdaten einer WAGO-Steuerung (PFC100/PFC200) in dein SCADA holen? Der saubere Weg ist: Die WAGO publiziert per MQTT auf einen Broker, dein SCADA abonniert dieselben Topics. So funktioniert es Schritt für Schritt.

WAGO-PLC (Publisher) → MQTT-Broker (z. B. Mosquitto) → SCADA (Subscriber). Die WAGO schreibt Messwerte als kleine JSON- oder Wert-Nachrichten auf ein Topic wie anlage/wago1/leistung, der Broker verteilt sie, und jedes SCADA/Dashboard, das dieses Topic abonniert, bekommt die Werte in Echtzeit. Kein direktes Polling der PLC nötig – der Broker entkoppelt Sender und Empfänger.

1) In WAGO WBM (Web-Based Management) den Zugriff bzw. die CODESYS-Laufzeit/Docker vorbereiten. 2) MQTT-Client auf der PLC konfigurieren: in CODESYS mit der MQTT-Bibliothek publizieren, oder auf der Linux-Ebene der PFC200 per Node-RED/Skript. 3) Broker-Adresse, Port (1883 offen, 8883 mit TLS), User/Passwort und Topic-Präfix eintragen. 4) Variablen auf Topics mappen. 5) Im SCADA denselben Broker als Datenquelle anlegen und die Topics abonnieren.

WAGO PFC100/PFC200 laufen auf einem echten Linux. Dadurch hast du drei Wege: (a) CODESYS mit MQTT-Client-Bibliothek direkt aus dem SPS-Programm publizieren, (b) Node-RED als Docker-Container auf der PLC, das interne oder Modbus-Werte liest und per MQTT-Node sendet, (c) ein eigenes Python-/Shell-Skript mit einer MQTT-Bibliothek. Welcher Weg passt, hängt davon ab, ob du im SPS-Programm bleiben willst oder die Linux-Ebene nutzt.

Halte Topics hierarchisch und sprechend: standort/gerät/messgröße, z. B. hof1/wago-bhkw/wirkleistung_kw. Als Payload eignet sich schlankes JSON – das kann jedes SCADA und jede Datenbank weiterverarbeiten. Konsistente Namen sparen später viel Arbeit beim Mapping. Nutze retain für langsame Zustandswerte und QoS 1, wenn keine Nachricht verloren gehen darf.

Achte auf Zeitstempel: Sende die PLC-Zeit im Payload mit und klär, ob lokal oder UTC – naive Lokalzeit als UTC zu interpretieren ist ein klassischer Fehler. Ports/Firewall: 1883 unverschlüsselt, für Fernzugriff besser 8883 mit TLS und eigenem MQTT-User pro Anlage. Und teste die Kette erst mit einem MQTT-Tool (z. B. mosquitto_sub), bevor du das SCADA anhängst – so siehst du sofort, ob die WAGO überhaupt publiziert.

Nein. Weil MQTT herstellerneutral ist, kannst du statt eines klassischen SCADA auch eine Kette Broker → Datenbank → Dashboard bauen: eine Bridge schreibt die MQTT-Nachrichten in eine Zeitreihen-Datenbank (z. B. InfluxDB oder ClickHouse), ein Dashboard (z. B. Grafana) visualisiert. Für reines Monitoring, Trends und Alarme reicht das oft und ist flexibler. Volle Prozess-Bedienung mit Stellbefehlen spricht dagegen weiter für ein echtes SCADA.

Kurz gesagt: Ja, das geht — die WAGO-Controller der PFC-Reihe (PFC100/PFC200) bringen einen MQTT-Client schon mit, und du machst ihn über drei Bausteine sicher: verschlüsselte Transportschicht, echte Authentifizierung und ein sauber getrenntes Netz. MQTT selbst ist nur ein leichtgewichtiges Publish/Subscribe-Protokoll und im Auslieferungszustand unverschlüsselt (Port 1883) — sicher wird es erst durch die Konfiguration, nicht durch das Protokoll an sich. Genau deshalb reicht es in einer Steuerungsumgebung nicht, den Client einfach zu aktivieren.

Konkret gehst du so vor: (1) Aktiviere den MQTT-Client des WAGO-Controllers über das Web-Based-Management (WBM) bzw. in deiner CODESYS-/e!RUNTIME-Applikation. (2) Schalte TLS ein und nutze Port 8883 statt 1883 — hinterlege im WBM das CA-Zertifikat deines Brokers, damit der Controller die Broker-Identität prüft, und optional ein Client-Zertifikat für gegenseitige (mutual) TLS-Authentifizierung. (3) Vergib Benutzername und Passwort für den Broker-Login und arbeite pro Gerät mit einem eigenen Konto statt einem Sammel-Login. (4) Beschränke die Topic-Rechte nach dem Least-Privilege-Prinzip: Jeder Controller darf nur auf die Topics publishen/subscriben, die er wirklich braucht — Stell- und Steuerbefehle strikt von reinen Mess-Topics trennen. (5) Setze den WAGO-I/O-Knoten in ein eigenes, per Firewall abgeschottetes OT-Netzsegment und lass die MQTT-Verbindung nur zum definierten Broker zu; kein direkter Weg aus dem Internet auf den Controller. So bleibt die Kommunikation vertraulich, die Gegenstelle verifiziert und ein kompromittiertes Gerät kann nicht das ganze System steuern.

Ja, das geht — aber nicht mit den Werkseinstellungen. MQTT ist ein schlankes Publish/Subscribe-Protokoll: Deine WAGO-Steuerung (z. B. PFC100/PFC200) ist ein Client, der Messwerte an einen Broker sendet; das SCADA-System ist ein zweiter Client, der dieselben Topics abonniert. Direkt verbunden sind beide nie. Genau darin liegt der erste Sicherheitsgewinn: Der Controller baut die Verbindung nach außen auf, du musst also keinen eingehenden Port in der Anlagen-Firewall öffnen — anders als bei einem Modbus-TCP- oder OPC-UA-Server, der auf Verbindungen wartet. Der zweite Punkt: MQTT selbst bringt keine Verschlüsselung mit. Klartext läuft auf Port 1883, TLS-gesichert auf Port 8883. Wer 1883 im Anlagennetz stehen lässt, überträgt Benutzername und Passwort im Klartext — das ist der häufigste Fehler beim Einstieg. Auf WAGO-Seite hast du zwei Wege: die im Web-Based Management integrierte Cloud-/MQTT-Konfiguration (Umfang je nach Firmware-Stand deines Geräts) oder eine MQTT-Client-Bibliothek in CODESYS bzw. e!COCKPIT, wenn du Topics und Payload selbst aus dem SPS-Programm heraus bauen willst. Sicherheitstechnisch verhalten sich beide gleich — entscheidend ist, was du konfigurierst, nicht welchen Weg du wählst.

Konkret in dieser Reihenfolge: (1) Zuerst die Richtung festlegen. Reines Monitoring bedeutet, die Steuerung publiziert nur — dann abonniert sie kein Command-Topic, und ein kompromittierter Broker kann keine Sollwerte schreiben. Steuerbefehle aus dem SCADA heraus nimmst du nur auf, wenn du sie wirklich brauchst, und plausibilisierst sie in der SPS gegen Grenzwerte, statt sie ungeprüft auf Ausgänge zu legen. (2) TLS aktivieren: Port 8883, CA-Zertifikat des Brokers auf den Controller laden und die Server-Zertifikatsprüfung wirklich einschalten — ohne Prüfung ist die Verschlüsselung zwar aktiv, die Gegenstelle aber ungeprüft. Wo der Broker es unterstützt, ist beidseitige Authentifizierung per Client-Zertifikat sauberer als Passwörter. (3) Jedes Gerät bekommt eine eigene Client-ID und eigene Zugangsdaten. Ein geteilter Account über alle Anlagen hinweg heißt: ein Leak, und alles muss getauscht werden. Gleiche IDs werfen sich zudem gegenseitig aus der Verbindung. (4) Auf dem Broker Topic-ACLs setzen — Schreibrecht nur auf den eigenen Anlagen-Pfad, Leserecht für das SCADA. (5) Last Will and Testament konfigurieren, damit das SCADA einen Verbindungsabriss erkennt und nicht stillstehende Werte als gültig anzeigt; Messdaten mit QoS 1 senden. (6) Broker nicht ins Steuerungsnetz stellen, sondern in eine DMZ oder erreichbar über VPN — die Netztrennung nach IEC 62443 bleibt auch mit MQTT die Grundlage. (7) Zeitsynchronisation per NTP sicherstellen, sonst schlägt die Zertifikatsprüfung bei abgelaufener Uhrzeit fehl und du suchst den Fehler an der falschen Stelle.