S7-1500 und MQTT — geht das direkt?

Kurz: Eine S7-1500 bringt MQTT nicht als fertigen Klick im TIA Portal mit — du musst es über eine Bibliothek nachrüsten oder ein Gateway davorsetzen. Welcher der drei Wege für dich passt, hängt davon ab, ob du in die SPS eingreifen darfst und ob TLS gefordert ist.

Die S7-1500 spricht von Haus aus S7-Kommunikation, PROFINET, OPC UA (lizenzpflichtig je nach CPU) und offene TCP/UDP-Verbindungen. MQTT ist keine eingebaute Funktion. Du hast drei praktikable Wege: (1) den MQTT-Client im SPS-Programm mit der kostenlosen Siemens-Bibliothek LMQTT_Client nachbauen, (2) ein Gateway/Edge-Gerät davorsetzen, das die SPS ausliest und selbst als MQTT-Client publiziert, (3) den Umweg über OPC UA mit einem OPC-UA-zu-MQTT-Bridge-Dienst. Weg 1 ist am saubersten, wenn du das SPS-Projekt anfassen darfst; Weg 2, wenn die Anlage nicht angefasst werden soll.

Siemens stellt im Support-Portal (SIOS) die freie Bibliothek LMQTT_Client bereit. Sie setzt intern auf die offene Kommunikation (TCON/TSEND/TRCV) auf und bildet Connect, Publish und Subscribe als Funktionsbausteine ab. Vorgehen: Bibliothek herunterladen und ins Projekt einbinden, einen Instanz-DB anlegen, Broker-IP/Port (1883 unverschlüsselt, 8883 mit TLS), Client-ID, User und Passwort parametrieren, Topic und Payload als String/Array of Byte übergeben und den Baustein zyklisch aufrufen. Wichtig: Prüfe im SIOS-Eintrag die geforderte Mindest-Firmware deiner CPU und TIA-Version — ältere CPUs und ältere TIA-Stände unterstützen nicht alle Funktionen, TLS erst ab neueren Firmware-Ständen.

Das ist der Weg, den wir bei Anlagen fahren, die im Bestand laufen und nicht neu programmiert werden sollen. Ein kleines Edge-Gerät liest die SPS über S7-Kommunikation (z. B. Snap7 oder der s7-Node in Node-RED) oder über Modbus TCP aus und publiziert die Werte als JSON auf Topics wie anlage/bhkw/1/json. Zwei Fallstricke: In der CPU muss unter Schutz/Sicherheit der Zugriff über PUT/GET erlaubt sein, und die zu lesenden Datenbausteine brauchen deaktivierten optimierten Bausteinzugriff — sonst hast du keine feste Absolutadresse zum Lesen. Vorteil: Das Gateway puffert bei Netzausfall, die SPS bleibt unberührt.

Wenn deine CPU eine OPC-UA-Server-Lizenz hat, kannst du die Variablen dort veröffentlichen und einen Bridge-Dienst (z. B. Node-RED, Telegraf oder ein Edge-Gerät) auf MQTT umsetzen lassen. Das lohnt sich, wenn ohnehin schon OPC UA genutzt wird oder mehrere Konsumenten unterschiedliche Protokolle brauchen. Nachteil: eine Schicht mehr, zusätzliche Latenz und je nach CPU Lizenzkosten für OPC UA.

Baue Topics hierarchisch nach Standort/Anlage/Gerät/json statt flach — das macht Wildcard-Abos später möglich. Publiziere JSON statt Rohbytes, dann kann jede Datenbank direkt andocken. Publiziere nicht im schnellen OB1-Zyklus: Ein Sende-Takt von 1 bis 60 Sekunden oder ereignisgesteuert bei Wertänderung (Deadband) reicht für Energie- und Zustandsdaten und hält die CPU-Last klein. Setze eine Last-Will-Nachricht (LWT), damit der Broker meldet, wenn die Anlage still wird.

Port 1883 ist unverschlüsselt — nur innerhalb eines geschlossenen Anlagennetzes akzeptabel. Sobald Daten über Internet oder VPN-Grenzen gehen, nimm 8883 mit TLS und Benutzer/Passwort je Anlage, nicht einen gemeinsamen Account für alle Standorte. TLS direkt aus der S7-1500 heraus hängt an der Firmware-Version deiner CPU; kann sie es nicht, terminiert das Gateway die Verschlüsselung. Gib jedem Client eine eigene Client-ID — doppelte IDs werfen sich gegenseitig vom Broker.

→ Passend dazu: mqtt ports

→ Passend dazu: mqtt broker

→ Passend dazu: mqtt waagen

→ Passend dazu: mqtt browser

Kurz: Deine S7-1500 kann direkt als MQTT-Client publizieren und abonnieren, aber MQTT ist kein eingebautes Protokoll der CPU. Ab Werk beherrscht die Steuerung PROFINET, S7-Kommunikation, Open User Communication (TCP/ISO-on-TCP/UDP) und je nach CPU einen OPC-UA-Server — einen fertigen MQTT-Baustein findest du im TIA Portal nicht. Den Weg dorthin öffnet Siemens über die kostenlose Bibliothek LMQTT_Client aus dem Siemens Industry Online Support: Sie setzt auf die Open User Communication (TCON/TSEND/TRCV) auf und bildet das MQTT-Protokoll komplett im SPS-Anwenderprogramm nach. Voraussetzung sind also eine ausreichend aktuelle CPU-Firmware, TIA Portal, freie Verbindungsressourcen der CPU und ein erreichbarer Broker — üblicherweise Port 1883 unverschlüsselt, 8883 mit TLS. Für TLS legst du das CA-Zertifikat des Brokers über die globalen Sicherheitseinstellungen ins Zertifikatsverzeichnis der CPU; ohne das bleibt die Verbindung unverschlüsselt im Anlagennetz.

Konkret gehst du so vor: Broker, Client-ID, Zugangsdaten und Topic-Struktur festlegen (z. B. werk/linie1/bhkw/json) — dann die Bibliothek ins Projekt einbinden, einen Instanz-DB anlegen und Verbindungsparameter samt Keep-Alive parametrieren. Danach baust du die Nutzlast selbst: Die CPU liefert Bytes und Strings, JSON musst du im Programm zusammensetzen oder rohe Werte senden. Wichtig ist der Sendetakt — nicht in jedem OB1-Zyklus publizieren, sondern zeitgesteuert oder bei Wertänderung, sonst flutest du Broker und CPU-Verbindung. Zum Schluss gegenprüfen mit einem Fremd-Client (mosquitto_sub oder MQTT Explorer) am selben Topic. Willst oder darfst du das SPS-Programm nicht anfassen — bei laufender Anlage bedeutet jede Änderung Test und Abnahme —, ist der zweite Weg der übliche: ein kleines Gateway daneben (Industrie-PC, Edge-Gerät oder Raspberry Pi), das die Daten per S7-Kommunikation oder über den OPC-UA-Server der CPU liest und als MQTT weiterreicht. Funktional ergibt das dieselben Topics, nur ohne Eingriff in die Steuerung — dafür mit einem zusätzlichen Gerät, das gewartet werden muss.