☎ +49 5223 4921030 ✉ hr@stromfee.ai
HomeBlog

MQTT und Siemens SPS: Datenkommunikation in industriellen Biogasanlagen

Stromfee Redaktion · 19. Juni 2026
ThemenseiteEnergiemonitoring →

TL;DR: MQTT verbindet Siemens-SPS-Steuerungen über einen zentralen Broker mit Monitoring-Systemen. Das Protokoll ist ressourcenschonend und eignet sich für Biogasanlagen, Motoren und andere industrielle Prozesse – wenn Broker-Sicherheit und Topic-Struktur von Anfang an sauber geplant sind.

▶ Energiemonitoring und Datenkommunikation in Biogasanlagen – so funktioniert die Anbindung von SPS-Systemen in der Praxis. Aus der Stromfee-Mediathek.
Energiemonitoring-Dashboard mit Echtzeit-Sensordaten aus einer Biogasanlage
Energiemonitoring-Dashboard mit Echtzeit-Sensordaten aus einer Biogasanlage

Was ist MQTT und warum eignet es sich für industrielle Anlagen?

MQTT (Message Queuing Telemetry Transport) ist ein leichtgewichtiges Nachrichtenprotokoll, das nach dem Publish-Subscribe-Prinzip arbeitet. Ein zentraler Broker – häufig Eclipse Mosquitto oder HiveMQ – empfängt Nachrichten von Sendern (Publisher) und verteilt sie an alle registrierten Empfänger (Subscriber). Geräte müssen sich gegenseitig nicht kennen; die Entkopplung erfolgt vollständig über den Broker.

Gegenüber anderen Industrieprotokollen wie Modbus TCP oder OPC UA punktet MQTT mit geringem Overhead: Pakete sind kompakt, Verbindungen bleiben dauerhaft offen (persistent connection), und Nachrichten lassen sich bei Verbindungsunterbrechung zwischenspeichern (QoS-Level 1 oder 2). Das macht das Protokoll besonders geeignet für Biogasanlagen mit vielen verteilten Sensoren und instabilen Mobilfunkanbindungen.

Siemens SPS – Voraussetzungen für MQTT-Kommunikation

Siemens bietet MQTT-Unterstützung ab bestimmten Modellreihen nativ an:

Im TIA Portal wird die MQTT-Verbindung über den Funktionsbaustein MQTT_Connect konfiguriert. Dabei werden Broker-Adresse, Port, Client-ID und Authentifizierungsdaten hinterlegt. Die Parametrierung erfolgt über Datenbausteine (DB), die zur Laufzeit beschrieben werden können.

Topic-Struktur und Nachrichtenformat

Eine durchdachte Topic-Hierarchie ist das Rückgrat einer wartbaren MQTT-Integration. Eine bewährte Struktur für Biogasanlagen sieht so aus:

Nachrichten werden typischerweise im JSON-Format übermittelt. Datenbausteine auf der SPS liefern die Messwerte, die der MQTT-Baustein als strukturierte Zeichenkette verpackt und publiziert. JSON erleichtert die spätere Weiterverarbeitung in Datenbank- oder Monitoring-Systemen erheblich.

Stolperfallen aus der Praxis

Bei der Einführung von MQTT in industriellen Biogasanlagen treten einige Probleme regelmäßig auf:

Fazit

MQTT ist ein etabliertes Protokoll für die Einbindung von Siemens-SPS-Systemen in industrielle Monitoring-Architekturen. Die Siemens-Baureihen S7-1200 und S7-1500 unterstützen MQTT nativ über TIA Portal; ältere Systeme benötigen ein Gateway. Entscheidend für den stabilen Betrieb sind eine saubere Topic-Hierarchie, konsequente TLS-Absicherung, korrekte QoS-Konfiguration und NTP-synchronisierte Zeitstempel. Wer diese Grundlagen beachtet, schafft eine robuste Datenbasis für Echtzeit-Monitoring, Wartungsplanung und Abrechnungskontrolle in Biogasanlagen.

Auf Ihren echten Daten rechnen lassen?
Wir lesen Anlage und Lastgang herstellerunabhängig aus und optimieren gegen den realen Strommarkt.
Zum BESS.optimizer →

FAQ

Welche Siemens-SPS-Modelle unterstützen MQTT nativ?

Die Baureihen S7-1200 und S7-1500 unterstützen MQTT über TIA-Portal-Bibliotheken nativ. Ältere Modelle wie S7-300 oder S7-400 benötigen ein externes Gateway, etwa das SIMATIC IOT2040 oder eine Linux-basierte Middleware.

Welchen MQTT-Broker sollte ich einsetzen?

Eclipse Mosquitto ist der verbreitetste Open-Source-Broker und eignet sich für kleine bis mittlere Anlagen. HiveMQ bietet erweiterte Cluster- und Persistenz-Funktionen für größere Installationen. Beide unterstützen TLS und ACL-basierte Zugriffskontrolle.

Wie sichere ich eine MQTT-Verbindung gegen unbefugten Zugriff ab?

Mindestanforderungen: TLS-Verschlüsselung auf Port 8883, Benutzername/Passwort-Authentifizierung und ACL-Regeln, die Topics auf benötigte Clients beschränken. In Produktionsumgebungen empfiehlt sich zusätzlich eine Client-Zertifikat-Authentifizierung.

Was passiert, wenn der MQTT-Broker kurz ausfällt?

Bei QoS 1 oder 2 speichert der Broker ausstehende Nachrichten für Clients mit persistenter Session und stellt sie nach Wiederverbindung zu. Bei QoS 0 gehen Nachrichten während des Ausfalls verloren. Für Alarmzustände ist QoS 1 mindestens erforderlich.

Stromfee — Energiemonitoring & Speicher-Optimierung
Herstellerunabhängig, auf echten Anlagendaten.
Beratung anfragen

MQTT Ports: welche Portnummern du für Broker und SPS brauchst

Die beiden offiziellen MQTT-Ports: 1883 und 8883

Bei der IANA sind genau zwei Ports für MQTT registriert. Port 1883 ist der Standard für unverschlüsselte Verbindungen (Dienstname "mqtt"), Port 8883 der Standard für MQTT über TLS (Dienstname "secure-mqtt"). Beide arbeiten über TCP. In einer Anlage heißt das: Du erreichst den Broker per 1883 nur im abgeschotteten Anlagennetz — sobald Daten über einen Router, eine DMZ oder ins Internet gehen, gehört ausschließlich 8883 in die Konfiguration. Der Port allein verschlüsselt nichts: 8883 ist eine Konvention, die Verschlüsselung entsteht erst durch die TLS-Konfiguration im Broker (Zertifikat, Schlüssel, ggf. CA für Client-Zertifikate). Ein Broker, der auf 8883 lauscht, aber TLS nicht aktiviert hat, überträgt Nutzername und Passwort weiterhin im Klartext.

WebSocket-Ports: 8080, 8081, 8083, 8084, 9001 — alles Herstellerwahl

Wenn ein Dashboard im Browser direkt mit dem Broker sprechen soll, läuft MQTT über WebSockets. Dafür gibt es keinen registrierten Port. Eclipse Mosquitto verwendet in vielen Beispielkonfigurationen 9001, HiveMQ und EMQX kommen mit 8000/8083 (ws) und 8084 (wss) bzw. 8080/8081 daher. Diese Nummern stehen in der jeweiligen Broker-Konfiguration und sind frei änderbar — sie sind keine Norm. Prüfe also immer die Konfigurationsdatei des eingesetzten Brokers, statt eine Portnummer aus einem Tutorial zu übernehmen. Praktischer Nebeneffekt: Läuft der WebSocket-Listener hinter einem Reverse-Proxy auf 443, kommst du auch durch restriktive Firmen-Firewalls, die 1883 und 8883 blockieren.

Freigaben planen: Richtung, Quelle, Ziel

Für die Firewall zählt nicht nur die Nummer, sondern die Richtung. MQTT-Clients — also SPS, Gateway, Energiezähler — bauen die Verbindung immer selbst zum Broker auf. Der Broker muss deshalb nie in Richtung SPS verbinden dürfen. Du brauchst also nur eine ausgehende Freigabe von jedem Client zum Broker auf 8883 (bzw. 1883 im internen Netz), keine eingehende Freigabe zur Steuerung. Diese Asymmetrie ist der eigentliche Sicherheitsvorteil gegenüber Modbus TCP (Port 502), wo das abfragende System aktiv auf die SPS zugreift. Nimm zusätzlich eine Quell-IP-Beschränkung dazu und binde den Broker im Anlagennetz an eine feste Adresse statt an 0.0.0.0, damit er nicht ungewollt auf allen Netzwerkschnittstellen lauscht.

Kann ich einen anderen MQTT-Port als 1883 oder 8883 verwenden?

Ja, jeder freie TCP-Port funktioniert — du trägst ihn im Broker als Listener ein und musst ihn dann in jedem Client identisch angeben. Ein abweichender Port ist aber keine Sicherheitsmaßnahme, sondern nur eine kleine Hürde für automatisierte Scanner. Gegen unbefugten Zugriff helfen TLS auf 8883, Benutzername/Passwort oder Client-Zertifikate und eine Zugriffsliste (ACL) auf Topic-Ebene.

Warum antwortet mein Broker auf Port 1883, aber nicht auf 8883?

In der Regel fehlt der zweite Listener. Bei Mosquitto etwa lauscht der Dienst nach der Installation nur auf 1883; der TLS-Listener auf 8883 muss mit Zertifikatspfad und Schlüssel separat konfiguriert und der Dienst neu gestartet werden. Prüfe in dieser Reihenfolge: Lauscht der Prozess überhaupt auf dem Port, lässt die Firewall ihn durch, und passt der Zertifikatsname zum Hostnamen, den der Client verwendet.

🛰️ Stromfee Radar öffnen →