PROFINET zu MQTT ist eine Frage, die sich viele Automatisierungsteams stellen, sobald Maschinendaten in Dashboards oder die Cloud sollen, und die Antwort ist weniger offensichtlich als bei Modbus oder OPC UA. Dieser Leitfaden erklärt, warum sich PROFINET-Daten nicht einfach pollen lassen, vergleicht die vier praktikablen Gateway-Optionen und führt durch ein funktionierendes Beispiel, das Prozesswerte aus einer Siemens-S7-Steuerung liest und an einen MQTT-Broker veröffentlicht. Am Ende wissen Sie, welche Option zu Ihrem Werk passt und worauf Sie achten müssen.
Warum PROFINET anders ist
PROFINET IO ist ein Industrial-Ethernet-Standard für den zyklischen Echtzeitaustausch zwischen einem IO-Controller (meist einer SPS) und IO-Devices (dezentrale Peripherie, Antriebe, Ventilinseln, Sensoren). Der Controller baut gemäß der Hardwarekonfiguration im Engineering-Tool Application Relations zu jedem Device auf und tauscht dann Prozessdaten in einem festen Zyklus aus, oft alle paar Millisekunden. Alarme und azyklische Datensätze laufen parallel dazu.
Für die MQTT-Integration sind drei Eigenschaften wichtig:
- Der Controller besitzt die Devices. Ein IO-Device tauscht zyklische Daten mit dem Controller aus, für den es konfiguriert wurde. Ein beliebiger Client im Netz kann einen Antrieb nicht einfach nach seiner Drehzahl fragen, so wie ein Modbus-Master einen Zähler nach einem Register fragt.
- Prozessdaten sind rohe Bytes. Zyklische Daten sind ein Block aus Ein- und Ausgangsbytes, deren Bedeutung im SPS-Projekt und in den Gerätebeschreibungsdateien (GSDML) definiert ist, nicht auf der Leitung.
- Das Echtzeitnetz ist kostbar. Zusätzlicher Verkehr oder zusätzliche Geräte im PROFINET-Netz sollten mit dem Steuerungstechniker geplant und niemals improvisiert werden.
Die praktische Konsequenz: In fast allen Fällen ist die beste Quelle für PROFINET-Daten die SPS, die die Devices ohnehin steuert, denn sie hat die Daten, den Kontext und die Namen.
Die vier Optionen für PROFINET zu MQTT
| Option | Funktionsweise | Vorteile | Nachteile | Typischer Einsatz |
|---|---|---|---|---|
| 1. SPS über ein Edge-Gateway lesen | Gateway liest den SPS-Speicher über das native Protokoll oder den OPC-UA-Server und veröffentlicht per MQTT | Keine Änderung am PROFINET-Netz; nutzt vorhandene Tag-Namen | Polling; ggf. Änderungen an SPS-Einstellungen nötig (Zugriffsrechte, OPC UA aktiviert) | Die meisten Brownfield-Standorte |
| 2. SPS veröffentlicht selbst per MQTT | Eine MQTT-Client-Bibliothek des Herstellers läuft im SPS-Programm | Keine zusätzliche Hardware; Veröffentlichung bei Änderung in der SPS-Logik | Programmieraufwand in der SPS; CPU-Last und TLS-Handling in der SPS | Greenfield oder wenn SPS-Programmierung im eigenen Haus erfolgt |
| 3. PROFINET-Device-Gateway | Ein Gateway erscheint als IO-Device in der SPS-Konfiguration; die SPS schreibt Daten in dessen Ein-/Ausgangsbereich und das Gateway veröffentlicht per MQTT | Saubere zyklische Schnittstelle; kein Polling der SPS | Erfordert Änderung der Hardwarekonfiguration und einen SPS-Download | Standorte, die Hardware-Gateways mit fester Schnittstelle bevorzugen |
| 4. Passives Monitoring | Ein TAP oder Mirror-Port erfasst PROFINET-Frames zur Diagnose | Keine Änderung am Controller | Bedeutung der Daten ohne Projekt unbekannt; keine Methode zur Datenintegration | Nur Netzwerkdiagnose |
Option 4 ist aufgeführt, weil sie in Diskussionen immer wieder auftaucht. Sie ist jedoch eine Diagnosetechnik und kein solider Weg, eine Datenpipeline aufzubauen. Der Rest dieses Leitfadens konzentriert sich auf die ersten drei.
Option 1: Die SPS über ein Edge-Gateway lesen
Dies ist der am wenigsten invasive Ansatz und derjenige, mit dem die meisten Teams beginnen. Das Gateway sitzt im Werksnetz, liest Werte aus der SPS und veröffentlicht sie per MQTT. Bei Siemens-Steuerungen sind zwei Zugriffswege üblich:
- OPC-UA-Server. S7-1500-Steuerungen (und S7-1200 mit aktueller Firmware) können einen OPC-UA-Server betreiben. Sie aktivieren ihn in der Hardwarekonfiguration und wählen die freizugebenden Tags. Das Gateway nutzt dann einen OPC-UA-Client, wie in unserem Tutorial zum OPC-UA-zu-MQTT-Gateway. Das ist der bevorzugte Weg, wenn verfügbar: sicher, symbolisch und offiziell unterstützt.
- S7-Kommunikation (PUT/GET). Open-Source-Bibliotheken wie python-snap7 lesen Datenbausteine per Adresse. Bei S7-1200 und S7-1500 muss dafür der PUT/GET-Zugriff in den Schutzeinstellungen der CPU aktiviert und der Datenbaustein auf nicht optimierten Zugriff gestellt sein, damit die Byte-Offsets fest sind. Das Aktivieren von PUT/GET senkt die Schutzstufe der CPU; stimmen Sie es daher mit den Verantwortlichen für die SPS-Sicherheit ab, idealerweise im Rahmen Ihres Zonenkonzepts nach IEC 62443.
Andere Hersteller mit PROFINET-Controllern bieten ähnliche Möglichkeiten, typischerweise einen OPC-UA-Server oder ein herstellerspezifisches Leseprotokoll.
Beispiel: S7-Datenbaustein zu MQTT mit python-snap7
Angenommen, der SPS-Programmierer hat einen nicht optimierten Datenbaustein DB10 angelegt, der die freizugebenden Werte sammelt. Dieses verbreitete und empfohlene Muster nennt man Schnittstellenbaustein:
| Offset | Name | Typ |
|---|---|---|
| 0.0 | LineSpeed | Real |
| 4.0 | MotorCurrent | Real |
| 8.0 | GoodCount | DInt |
| 12.0 | Running | Bool |
| 12.1 | Fault | Bool |
pip install python-snap7 "paho-mqtt>=2.0"
# s7_profinet_mqtt.py - einen S7-Schnittstellen-DB lesen und an MQTT veröffentlichen
import json, logging, time, uuid
import paho.mqtt.client as mqtt
import snap7
from snap7.util import get_real, get_dint, get_bool
logging.basicConfig(level=logging.INFO)
log = logging.getLogger("s7")
PLC_IP, RACK, SLOT = "192.168.0.10", 0, 1 # S7-1200/1500: Rack 0, Slot 1 ist typisch
DB_NUMBER, DB_SIZE = 10, 14
TOPIC_ROOT = "connectmq/demo/p3x8/plant1/assembly/line3" # Ihre eigene Zufalls-ID
MQTT_HOST, MQTT_PORT = "broker.connectmq.com", 1883 # Produktion: 8883 mit TLS
MQTT_USER, MQTT_PASS = None, None # Produktion: "YOUR_USERNAME", "YOUR_PASSWORD"
CLIENT_ID = f"s7-bridge-{uuid.uuid4().hex[:8]}" # Produktion: "YOUR_CLIENT_ID"
def decode(buf):
return {
"line_speed": round(get_real(buf, 0), 2),
"motor_current": round(get_real(buf, 4), 2),
"good_count": get_dint(buf, 8),
"running": get_bool(buf, 12, 0),
"fault": get_bool(buf, 12, 1),
}
def main():
mq = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=CLIENT_ID)
if MQTT_USER:
mq.username_pw_set(MQTT_USER, MQTT_PASS)
mq.tls_set()
mq.will_set(f"{TOPIC_ROOT}/bridge", "offline", qos=1, retain=True)
mq.on_connect = lambda c, u, f, rc, p: c.publish(f"{TOPIC_ROOT}/bridge", "online", qos=1, retain=True)
mq.connect(MQTT_HOST, MQTT_PORT, keepalive=30)
mq.loop_start()
plc = snap7.client.Client()
last = {}
while True:
try:
if not plc.get_connected():
plc.connect(PLC_IP, RACK, SLOT)
log.info("connected to PLC %s", PLC_IP)
values = decode(plc.db_read(DB_NUMBER, 0, DB_SIZE))
ts = time.strftime("%Y-%m-%dT%H:%M:%SZ", time.gmtime())
for name, value in values.items():
if last.get(name) != value: # nur bei Änderung veröffentlichen
mq.publish(f"{TOPIC_ROOT}/{name}",
json.dumps({"value": value, "ts": ts}), qos=1, retain=True)
last[name] = value
except Exception as exc: # snap7 wirft bei Kommunikationsfehlern RuntimeError
log.error("PLC read failed: %s", exc)
plc.disconnect()
time.sleep(5)
time.sleep(1)
if __name__ == "__main__":
main()
Für Analogwerte, die ständig schwanken, fügen Sie ein Totband hinzu, damit die Brücke nicht jede winzige Änderung veröffentlicht; unser Leitfaden zu Report by Exception zeigt, wie das geht. Um das Ergebnis zu beobachten, abonnieren Sie auf dem öffentlichen MQTT-Broker. Er ist für Tests und Prototypen gedacht und für jeden lesbar, verwenden Sie also nur Testdaten:
mosquitto_sub -h broker.connectmq.com -p 1883 -i s7-viewer-p3x8 -t "connectmq/demo/p3x8/#" -v
Option 2: Die SPS direkt per MQTT veröffentlichen lassen
Mehrere SPS-Hersteller bieten MQTT-Client-Funktionsbausteine an. Für Siemens S7-1500 und S7-1200 gibt es beispielsweise eine MQTT-Client-Bibliothek für das TIA Portal, die auf der Open User Communication der CPU mit TLS-Unterstützung aufsetzt. Das SPS-Programm entscheidet dann genau, wann veröffentlicht wird. Das ist ideal für ereignisgesteuerte Daten wie Chargenabschlüsse oder Alarme.
Planen Sie Folgendes ein:
- Zertifikate. Für TLS muss die CPU der CA des Brokers vertrauen. Der Broker verwendet ein Let's-Encrypt-Zertifikat, laden Sie also das zugehörige Root-Zertifikat in den Zertifikatsspeicher der SPS.
- CPU- und Kommunikationslast. Viele Werte mit hoher Rate aus der SPS zu veröffentlichen, konkurriert mit den Steuerungsaufgaben. Veröffentlichen Sie Zusammenfassungen und Ereignisse, nicht jeden Zyklus.
- Wiederverbindung. Das Programm muss Verbindungsabbrüche zum Broker sauber behandeln und darf die Steuerungslogik nicht blockieren.
- Änderungsmanagement. Jede Änderung an Topic oder Payload bedeutet einen SPS-Download. Halten Sie die SPS-Seite einfach und erledigen Sie aufwendigeres Mapping nachgelagert.
Unser Artikel zu Siemens S7 und MQTT geht tiefer auf die Einrichtung auf der SPS-Seite ein.
Option 3: Ein PROFINET-Device-Gateway
Hardware-Gateways verschiedener Hersteller fungieren auf der einen Seite als PROFINET-IO-Device und auf der anderen als MQTT-Client. Sie importieren die GSDML-Datei des Gateways in das Engineering-Tool, fügen es der Hardwarekonfiguration hinzu und bilden SPS-Daten auf seinen zyklischen Ein-/Ausgangsbereich ab. Das Gateway wandelt diese Bytes gemäß seiner eigenen Konfiguration in MQTT-Nachrichten um.
Das ergibt eine saubere, deterministische Schnittstelle: Die SPS kopiert die Werte einfach in jedem Zyklus in den Ausgangsbereich des Gateways, und nichts pollt die SPS. Die Kompromisse sind eine Hardwareänderung, ein SPS-Download zum Hinzufügen des Geräts und ein zweiter Ort (die Weboberfläche des Gateways), an dem das Daten-Mapping liegt. Das passt zu Standorten mit strengen Regeln gegen das Aktivieren von PUT/GET oder OPC UA auf Steuerungen.
Die richtige Option wählen
Gehen Sie diese Checkliste mit dem Steuerungstechniker durch:
- Hat die SPS einen OPC-UA-Server, den Sie aktivieren können? Nutzen Sie Option 1 mit OPC UA.
- Ist PUT/GET nach Ihrer Sicherheitsrichtlinie zulässig? Option 1 mit S7-Kommunikation ist schnell und günstig.
- Benötigen Sie ereignisgesteuerte Daten, die in der SPS-Logik definiert sind? Option 2.
- Sind die Steuerungseinstellungen gesperrt, eine Hardwareänderung aber akzeptabel? Option 3.
- Handelt es sich um einen Pilot an einer Linie? Beginnen Sie mit Option 1; auf Option 2 oder 3 können Sie bei der Skalierung jederzeit wechseln.
Was auch immer Sie wählen, geben Sie den Daten eine Topic-Struktur im ISA-95-Stil, damit Werte aus PROFINET neben Modbus-, EtherNet/IP- und OPC-UA-Daten in einem Namensraum liegen; siehe unseren Leitfaden zu ISA-95-MQTT-Topics.
Dieser gemeinsame Namensraum ist der Kern eines Unified Namespace (UNS): Die ISA-95-Anlagenhierarchie (Enterprise → Site → Area → Line → Cell) wird zur Topic-Struktur auf dem Broker, etwa acme/werk-stuttgart/montage/linie-3/zelle-1/motorstrom. MES, ERP, Historian und OEE-Auswertung abonnieren dann dieselben Pfade, egal ob die Werte ursprünglich per PROFINET, Modbus oder OPC UA erfasst wurden. Wie Sparkplug B diesen Ansatz ergänzt, erklärt unser Artikel zu Sparkplug B und Unified Namespace.
Die Broker-Seite
Alle drei Optionen enden mit einem MQTT-Client, der an einen Broker veröffentlicht. Die Wahl des Brokers ist also unabhängig vom Feldprotokoll. Ein verwalteter MQTT-Broker wie ConnectMQ unterstützt MQTT 3.1.1 und 5.0 über TLS auf 8883, erkennt ISA-95- und UNS-Topics und zeigt sie in einem Live-Topic-Explorer sowie in einer nach ISA-95-Ebenen gegliederten Geräteansicht. Schwellwert-Alarmregeln können dann ein Störungsbit oder einen zu hohen Motorstrom ohne zusätzlichen Code melden. Die übergreifende Referenzarchitektur finden Sie im Leitfaden zu Industrial IoT mit MQTT.
Starten Sie mit ConnectMQ
Wählen Sie Ihren PROFINET-Weg, und überlassen Sie dem Broker den einfachen Teil. Registrieren Sie sich unter app.connectmq.com, wählen Sie den kostenlosen Serverless-Plan (ohne Kreditkarte), erstellen Sie einen Broker und verwenden Sie den generierten Benutzernamen, das Passwort und die Client-ID in Ihrem Gateway oder im MQTT-Client der SPS. Ihre Liniendaten sind innerhalb weniger Minuten im ConnectMQ-Portal sichtbar.
Häufig gestellte Fragen
Kann ein MQTT-Gateway PROFINET-Devices direkt lesen?
Nicht so, wie ein Modbus-Master einen Zähler pollt. PROFINET-IO-Devices tauschen zyklische Daten mit ihrem konfigurierten Controller aus. Gateways lesen daher entweder den Controller oder sind selbst als IO-Device konfiguriert.
Ist das Aktivieren von PUT/GET an einer S7-1200 oder S7-1500 sicher?
Es senkt den Zugriffsschutz der CPU und sollte daher eine bewusste, dokumentierte Entscheidung mit vorhandener Netzwerksegmentierung sein. Wo verfügbar, ist der OPC-UA-Server der SPS die sicherere Alternative.
Brauche ich GSDML-Dateien für ein PROFINET-zu-MQTT-Gateway?
Nur für Option 3, bei der das Gateway als IO-Device in die Hardwarekonfiguration der SPS aufgenommen wird. Das Lesen der SPS über OPC UA oder S7-Kommunikation erfordert sie nicht.
Beeinträchtigt das Lesen der SPS die Echtzeitleistung von PROFINET?
Lesezugriffe gehen an die Kommunikationsschnittstelle der CPU, nicht an den zyklischen IO-Austausch, und moderates Polling hat kaum Auswirkungen. Wählen Sie sinnvolle Polling-Raten und lesen Sie kompakte Schnittstellenbausteine.



