S7-Daten auslesen: OPC UA, Snap7 und die Falle optimierter Datenbausteine

S7-Daten auslesen heißt bei SIMATIC-Steuerungen: entweder den in der S7-1500 integrierten OPC-UA-Server aktivieren und eine Runtime-Lizenz einplanen, oder mit einem S7-Client wie Snap7 über TCP-Port 102 direkt auf Datenbausteine zugreifen. Der zweite Weg ist lizenzfrei, scheitert aber an zwei Stellen, die in kaum einer Anleitung stehen: an der PUT/GET-Freigabe in der CPU und an optimierten Datenbausteinen, die keine absoluten Adressen haben. Dieser Artikel erklärt beide Wege, die Falle dazwischen und den Code, mit dem Werte sauber im Zeitreihenspeicher landen.

Die Entscheidung zuerst: S7-Daten auslesen per OPC-UA-Server oder direkt über S7comm?

Wer eine S7-1500 mit aktueller Firmware, Zugriff auf das TIA-Projekt und ein Lizenzbudget hat, nimmt den OPC-UA-Server der CPU. Wer eine S7-300/400 anbinden muss, keine Lizenz kaufen darf oder nur wenige Werte aus einem nicht-optimierten Datenbaustein braucht, nimmt Snap7 über Port 102. Alles dazwischen ist eine Abwägung zwischen Lizenzkosten, Eingriffstiefe in das SPS-Projekt und Sicherheitsniveau – Tab. 01 strukturiert sie.

Die SPS-Generation entscheidet zuerst. Laut Support-Matrix von python-snap7 funktionieren S7-300 und S7-400 ohne Vorarbeit, S7-1200 und S7-1500 nur mit aktivierter PUT/GET-Kommunikation; redundante S7-1500R/H-Systeme unterstützt das klassische Protokoll gar nicht. Für Maschinen ohne Netzwerkschnittstelle greift keiner der beiden Wege – dafür beschreibt Maschinendaten nachrüsten die Alternativen vom Signalabgriff bis zum Edge-Gerät.

S7comm / PUT-GET

Das klassische S7-Protokoll über ISO-on-TCP (RFC 1006) auf TCP-Port 102. Adressiert Speicherbereiche über Bausteinnummer, Byte-Offset und Länge; Symbolnamen kennt es nicht.

S7CommPlus

Das neuere, symbolische Protokoll, das TIA Portal und Bediengeräte mit S7-1200/1500 sprechen. Seit TIA Portal V17 und CPU-Firmware V2.9 (S7-1500) bzw. V4.5 (S7-1200) ist diese PG/HMI-Kommunikation zertifikatsbasiert über TLS abgesichert.

Optimierter Bausteinzugriff

Standardeinstellung für alle neu angelegten Bausteine der S7-1200/1500. Die CPU sortiert die Variablen nach Datentyp und legt sie lückenlos ab; es gibt nur symbolischen Zugriff und keine festen Byte-Adressen.

Weg 1: Den OPC-UA-Server der S7-1500 einrichten – inklusive Lizenzfrage

Der OPC-UA-Server ist in jeder S7-1500-CPU enthalten, aber ab Werk abgeschaltet: Laut Siemens-Dokumentation ist er aus Sicherheitsgründen standardmäßig nicht aktiviert, OPC-UA-Clients haben dann weder Lese- noch Schreibzugriff. Um eine S7-1500 als OPC-UA-Server einzurichten, braucht es das TIA-Projekt, einen Download in die CPU und eine gekaufte Runtime-Lizenz. Das Siemens-Kommunikationshandbuch beschreibt den Ablauf in sieben Schritten, hier zusammengefasst.

1. 01

   CPU auswählen und Server aktivieren

   In der Geräte- oder Netzsicht die CPU markieren, in den Eigenschaften zu „OPC UA > Server“ wechseln und den Server aktivieren. Die Sicherheitshinweise müssen bestätigt werden.

2. 02

   Runtime-Lizenz eintragen

   Unter „Eigenschaften > Allgemein > Runtime-Lizenzen > OPC UA“ zeigt TIA Portal den erforderlichen Lizenztyp an. Dort wird nach dem Kauf der Typ der erworbenen Lizenz aus der Liste gewählt.

3. 03

   Variablen freigeben – und Schreibrechte entziehen

   PLC- und DB-Variablen sind über die Attribute „Accessible from HMI/OPC UA“ und „Writable from HMI/OPC UA“ standardmäßig les- und schreibbar. Für ein Monitoring das Schreibrecht pro Variable oder für den ganzen DB abwählen; nicht benötigte Variablen ganz aus dem Adressraum nehmen.

4. 04

   Endpunkt und Security festlegen

   Der Server ist unter opc.tcp://<IP>:4840 erreichbar, der Port ist konfigurierbar. Endpunkte kombinieren Security Mode (None, Sign, SignAndEncrypt) und Security Policy. Siemens empfiehlt, nur die strengsten Policies zu aktivieren, die der Client noch unterstützt; zertifikatsbasierte Kommunikation setzt zudem eine korrekte CPU-Uhrzeit voraus.

5. 05

   Übersetzen, laden, prüfen

   Projekt übersetzen und in die CPU laden; danach startet der Server. Ein Verbindungstest mit einem generischen Client zeigt, ob Zertifikat, Endpunkt und Benutzer zusammenpassen – schlägt er fehl, hilft die Systematik in OPC-UA-Verbindung scheitert.

Die Lizenzfrage entscheidet über die Wirtschaftlichkeit des Weges und wird oft erst beim Übersetzen entdeckt, wenn TIA Portal die erforderliche Klasse anzeigt. Siemens unterscheidet für die S7-1500 drei Klassen nach CPU-Leistung (Tab. 02); für die S7-1200 gilt der Lizenztyp „Basic“. Die SIMATIC-OPC-UA-Lizenz gilt pro CPU; zehn Steuerungen brauchen zehn Lizenzen. Preise nennt die Dokumentation nicht, sie kommen aus der Siemens-Preisliste oder vom Distributor.

Der Gegenwert der Lizenz ist real: Der Server liefert Variablen symbolisch mit Datentyp, auch aus optimierten Bausteinen, und bietet Subscriptions statt Polling. Siemens empfiehlt für zyklische Zugriffe auf kleine Datenmengen bis etwa alle 5 Sekunden Subscriptions, für wiederkehrende Zugriffe „RegisteredRead“ und „RegisteredWrite“; minimales Publishing- und Sampling-Intervall lassen sich serverseitig begrenzen, damit kein Client die CPU überlastet.

Weg 2: Snap7 und S7comm – der Zugriff über Port 102 ohne OPC UA

Snap7 ist eine quelloffene Bibliothek für das klassische S7-Protokoll, python-snap7 der dazugehörige Python-Wrapper. Der Client verbindet sich über client.connect(host, rack, slot, tcp_port=102) per ISO-on-TCP mit der CPU; die Rack- und Slot-Werte stehen in Tab. 01. Port 102 ist laut Siemens-Kommunikationshandbuch in jeder S7-1500 aktiv und lässt sich nicht deaktivieren, weil die Engineering-Kommunikation ihn nutzt – eine offene Tür bedeutet das trotzdem nicht, denn ohne PUT/GET-Freigabe antwortet die CPU auf Datenzugriffe nicht.

Lesbar sind Datenbausteine (db_read), Merker (mb_read) sowie Ein- und Ausgänge, Timer und Zähler über read_area. Mit read_multi_vars fasst der Client bis zu 20 Elemente in einer Anfrage zusammen, was Round-Trips spart. Der Preis der Einfachheit: Das Protokoll kennt weder Symbolnamen noch Strukturinformation – die Dokumentation führt genau das unter „Limitations“. Es liefert Bytes ab Offset; die Bedeutung muss aus der DB-Deklaration im TIA-Projekt kommen. Wer das Projekt nicht sehen darf, kann mit Snap7 nur raten.

python-snap7 spricht laut Support-Matrix ausschließlich das klassische S7-Protokoll; S7-1200 und S7-1500 erreicht es über den PUT/GET-Weg, nicht über S7CommPlus. Wer die symbolische, TLS-gesicherte Kommunikation der neuen Generation nutzen will, braucht kommerzielle Treiber oder geht gleich den OPC-UA-Weg. Für den lizenzfreien Zugriff auf eine S7-1500 mit Python bleibt genau eine Kombination: python-snap7 plus PUT/GET-Freigabe plus nicht-optimierte Datenbausteine.

Die Falle: optimierte Datenbausteine und die PUT/GET-Freigabe

Der häufigste Fehler beim ersten Snap7-Versuch an einer S7-1500 ist keiner im Code: Die Verbindung steht, db_read liefert einen Fehler oder Nullen, und die Ursache liegt im TIA-Projekt. Zwei Einstellungen müssen stimmen. Erstens muss die CPU die PUT/GET-Kommunikation aktivieren – die Option „Permit access with PUT/GET communication from remote partner (PLC, HMI, OPC, …)“ unter „Protection & Security > Connection mechanisms“ ist bei S7-1200 und S7-1500 ab Werk abgewählt. Zweitens muss der gelesene Datenbaustein nicht-optimiert sein.

Der Grund für die zweite Bedingung steht in der Siemens-Programmierrichtlinie für S7-1200/1500: In optimierten Bausteinen sortiert die CPU alle Variablen automatisch nach Datentyp, damit keine Lücken entstehen, und „es gibt nur symbolischen Zugriff“ auf solche Bausteine. Snap7 adressiert aber ausschließlich über Byte-Offsets. Das Kommunikationshandbuch formuliert es für PUT/GET eindeutig: Es lassen sich nur Datenbausteine mit absoluter Adressierung verwenden. Snap7 und optimierte Datenbausteine schließen sich damit prinzipbedingt aus – kein Update und kein Parameter ändert das.

Erschwerend kommt hinzu, dass der optimierte Zugriff laut derselben Richtlinie für alle neu angelegten Bausteine voreingestellt ist und Siemens ausdrücklich empfiehlt, generell nur optimierte Bausteine zu verwenden; nicht-optimierte Bausteine gibt es in S7-1200/1500 nur noch aus Kompatibilitätsgründen. In einem Projekt, das der Anlagenbauer nach dieser Empfehlung aufgebaut hat, ist per Snap7 zunächst nichts lesbar.

1. 01

   PUT/GET-Kommunikation aktivieren

   CPU markieren, Eigenschaften, „Allgemein > Schutz & Security > Verbindungsmechanismen“ (englisch: Protection & Security > Connection mechanisms), Haken bei „Zugriff über PUT/GET-Kommunikation durch entfernten Partner erlauben“ setzen.

2. 02

   Schnittstellen-DB anlegen statt Prozess-DBs umzustellen

   Einen eigenen globalen DB anlegen, nur dort per Rechtsklick unter „Eigenschaften > Attribute“ den Haken „Optimierter Bausteinzugriff“ entfernen und im Zyklus die benötigten Werte hineinkopieren. Siemens warnt, dass Kopieren zwischen optimierten und nicht-optimierten Bausteinen Rechenzeit kostet – für einige Dutzend Werte vertretbar, für Tausende nicht.

3. 03

   Übersetzen und in die CPU laden

   Projekt übersetzen und laden („Online > Laden in Gerät“). Je nach Änderung verlangt die CPU einen Neustart – also nur im abgestimmten Wartungsfenster.

4. 04

   Offsets dokumentieren und minimal testen

   Im nicht-optimierten DB zeigt der Editor absolute Offsets an; diese Liste (Name, Typ, Offset, Einheit, Skalierung) ist die Schnittstellenbeschreibung für das Gateway. Dann erst zwei Byte ab Offset 0 lesen, dann das ganze Layout – so trennen Sie Verbindungsprobleme von Layoutproblemen.

Vom Rohbyte zur Bedeutung: Datentypen, Byte-Order und Zeitstempel

Snap7 liefert ein bytearray; jeder Wert darin muss mit dem richtigen Typ am richtigen Offset dekodiert werden. Nicht-optimierte Bausteine liegen in Big-Endian-Reihenfolge – laut Siemens-Programmierrichtlinie ein Erbe der S7-300/400, das die S7-1500 für Standardbausteine beibehält, obwohl ihr Prozessor intern in Little-Endian arbeitet. Wichtig bei s7.util: Der Parameter byte_index bezieht sich auf das zurückgegebene Bytearray, nicht auf die absolute DB-Adresse. Wer ab Offset 20 liest, findet DBW22 bei get_int(raw, 2).

Einheiten transportiert weder S7comm noch der Rohwert selbst. Analogwerte kommen häufig als Rohzahl an, die erst über den Skalierungsfaktor der Baugruppe – bei SIMATIC-Analogeingängen typisch 27 648 für 100 % des Messbereichs – zur physikalischen Größe wird. Skalierung, Einheit und Messbereich gehören in die Schnittstellentabelle; wer sie im Gateway hart codiert, verliert sie beim nächsten Personalwechsel.

Lauffähiges Minimalbeispiel: SPS-Daten mit Python auslesen, inklusive Fehlerbehandlung

Das folgende Beispiel liest mit python-snap7 aus einer S7-1500 acht Byte eines nicht-optimierten Schnittstellen-DBs, dekodiert drei Werte und pollt im Sekundentakt. Die Reconnect-Parameter stammen aus dem Abschnitt „Connection Issues“ der python-snap7-Dokumentation; der Standard-Timeout des Clients liegt bei 5 Sekunden. Das DB-Layout ist ein fiktives Beispiel und muss durch die Offsets aus Ihrem Projekt ersetzt werden.

import time
from datetime import datetime, timezone

from s7 import Client            # python-snap7 (Paketname "s7", aeltere Versionen "snap7")
from s7.util import get_bool, get_int, get_real

PLC_IP, RACK, SLOT = "192.168.0.10", 0, 1   # S7-1200/1500: Rack 0, Slot 1
DB_NUMBER, START, SIZE = 100, 0, 8          # nicht-optimierter DB, Layout siehe Tab. 03
POLL_S = 1.0                                # Sekundentakt, keine Millisekunden

client = Client(
    auto_reconnect=True,   # Reconnect mit Backoff (Doku: "Connection Issues")
    max_retries=5,
    retry_delay=1.0,
    backoff_factor=2.0,
    max_delay=30.0,
)
client.connect(PLC_IP, RACK, SLOT)          # TCP-Port 102 ist Standard (tcp_port=102)

try:
    while True:
        t0 = time.monotonic()
        try:
            raw = client.db_read(DB_NUMBER, START, SIZE)
        except Exception as exc:            # Timeout, Verbindungsabbruch, Zugriffsfehler
            print("read failed:", exc)      # hier: Log + Luecke markieren, kein Wiederholwert
            time.sleep(2.0)
            continue
        sample = {
            "ts": datetime.now(timezone.utc).isoformat(),  # Zeitstempel des Gateways!
            "running": get_bool(raw, 0, 0),   # DB100.DBX0.0  (Byte 0, Bit 0)
            "parts":   get_int(raw, 2),       # DB100.DBW2    (INT, Big-Endian)
            "temp_c":  get_real(raw, 4),      # DB100.DBD4    (REAL, IEEE 754)
        }
        print(sample)                       # hier: Puffer/Datenbank statt print
        time.sleep(max(0.0, POLL_S - (time.monotonic() - t0)))
except KeyboardInterrupt:
    pass
finally:
    client.disconnect()

Drei Entscheidungen im Code sind Absicht. Die Lesezeit wird vom Pollintervall abgezogen, damit sie nicht zur Drift wird. Ein Lesefehler erzeugt eine erkennbare Lücke, keinen Wiederholwert – sonst sieht ein Verbindungsabbruch später wie eine stabil laufende Maschine aus. Und das Intervall liegt bei einer Sekunde, nicht bei zehn Millisekunden: Jeder db_read ist ein Round-Trip im Kommunikationsanteil des CPU-Zyklus, den sich HMI und Engineering teilen. python-snap7 bringt dafür einen Rate-Limiter mit (max_requests_per_second); wer Zustandswechsel im Millisekundenbereich braucht, legt die Logik in die SPS, die Ereignisse mit eigenem Zeitstempel in den DB schreibt.

Das Gegenstück auf der OPC-UA-Seite kommt ohne Schleife aus. Nach Session-Aufbau legt der Client eine Subscription mit Publishing-Intervall an und hängt die gewünschten Knoten als Monitored Items daran. Laut OPC-UA-Spezifikation Teil 4 definiert das Publishing-Intervall die zyklische Rate der Subscription; ohne Änderungen sendet der Server Keep-Alive-Nachrichten, und bleiben die Publish-Anfragen des Clients zu lange aus, schließt er die Subscription mit Bad_Timeout. Der Client bekommt Änderungen und Verbindungszustand gemeldet, statt beides zu erraten.

Und jetzt? Von der Steuerung in Datenbank und Dashboard

Der gelesene Wert ist erst dann etwas wert, wenn er mit Zeitstempel, Herkunft und Einheit in einem Zeitreihenspeicher liegt, aus dem Dashboard und Kennzahl entstehen. Zwischen print(sample) und diesem Zustand liegen vier Entwurfsentscheidungen, die weder Siemens noch eine Bibliothek betreffen.

• —Pufferung: Das Gateway schreibt zuerst in einen lokalen Puffer (Datei oder eingebettete Datenbank) und erst daraus in den zentralen Speicher. Fällt das Netz zur Datenbank aus, gehen keine Werte verloren; fällt die SPS-Verbindung aus, entstehen erkennbare Lücken statt eingefrorener Werte.
• —Batch-Schreiben: Werte werden gesammelt und in Blöcken geschrieben, nicht pro Wert ein Insert. Das entlastet Datenbank und Netz und macht Rückstau nach Ausfällen beherrschbar.
• —Namenskonvention: plc1_db100_dbd4 ist ein Adress-, kein Datenname. Jeder Wert braucht einen eindeutigen Pfad nach Standort, Bereich, Linie, Maschine und Signal – festgelegt, bevor die erste Zeile gespeichert wird. Wie ein solches Schema nach ISA-95 aussieht, zeigt Unified Namespace mit ISA-95-Topic-Schema.
• —Transport zur Plattform: Ob das Gateway per OPC UA weiterreicht oder Werte als MQTT-Nachrichten an einen Broker gibt, hängt von der Zahl der Abnehmer ab und davon, wer die Semantik hält – die Abwägung steht in OPC UA oder MQTT.

Erst auf dieser Grundlage tragen Kennzahlen. Eine Verfügbarkeit aus Betriebszuständen mit Gateway-Zeitstempeln hat eine Unschärfe von einem Pollintervall pro Zustandswechsel – bei vielen kurzen Störungen summiert sich das. Welche Signale eine belastbare Kennzahl braucht, steht in OEE berechnen; dieser Artikel liefert die Rohwerte dafür.

Sicherheit und Betrieb: was Sie nicht dauerhaft so lassen dürfen

Beide Wege lassen sich in einer Testphase großzügig konfigurieren; im Dauerbetrieb müssen vier Dinge zurückgedreht werden. Die PUT/GET-Freigabe öffnet laut python-snap7-Dokumentation unauthentifizierten Lese- und Schreibzugriff auf den SPS-Speicher – für jeden Rechner, der Port 102 erreicht. Wer sie setzt, legt die Steuerung in ein Segment, das nur das Gateway erreicht; Siemens nennt in seinen Sicherheitshinweisen Firewalls und Netzsegmentierung als Voraussetzung. Ein Snap7-Gateway im Office-Netz ist kein Kompromiss, sondern ein offener Schreibzugriff auf die Anlage.

• —Security Mode „None“ abschalten: Laut OPC-UA-Spezifikation bedeutet None schlicht, dass keine Sicherheit angewendet wird. Für den Dauerbetrieb SignAndEncrypt mit der strengsten Policy, die der Client unterstützt, und die schwächeren Endpunkte deaktivieren – so empfiehlt es auch Siemens.
• —Schreibrechte entziehen: Beim OPC-UA-Server pro Variable oder pro DB „Writable from HMI/OPC UA“ abwählen; Siemens rät, Schreibzugriff nur dort zu erlauben, wo er nötig ist. Bei Snap7 gibt es diese Trennung serverseitig nicht – dort bleibt nur Segmentierung plus ein Gateway, das keine Schreibfunktionen aufruft.
• —Keine geteilten Bediener-Accounts: Für den OPC-UA-Zugriff eigene technische Benutzer mit eigenem Zertifikat je Gateway, damit sich Zugriffe später zuordnen lassen.
• —Schreibzugriff nur mit Freigabekonzept: Sollwerte aus einem IT-System in die SPS zu schreiben ist ein eigenes Projekt mit Plausibilisierung in der SPS, Freigabe durch den Anlagenverantwortlichen und Protokollierung – nicht die Erweiterung eines Monitoring-Skripts um db_write.

Fazit: erst der Weg, dann der Code

S7-Daten auslesen ist technisch in einem Nachmittag erledigt – wenn vorher entschieden wurde, welcher Weg zur Steuerungsgeneration, zum Lizenzbudget und zum Sicherheitsniveau passt. Für die S7-1500 mit Projektzugriff ist der OPC-UA-Server der sauberere Weg: symbolisch, mit Subscriptions, mit feinen Schreibrechten, aber lizenzpflichtig. Snap7 ist der pragmatische Weg für Altanlagen und lizenzfreie Lesezugriffe, verlangt dafür PUT/GET-Freigabe, nicht-optimierte Schnittstellen-DBs und konsequente Segmentierung.

Der eigentliche Aufwand beginnt hinter dem ersten gelesenen Byte: Offsets dokumentieren, Zeitstempel an der Quelle setzen, puffern, benennen, speichern. Wer diesen Teil als Projekt behandelt statt als Skript, hat in einem Jahr noch verwertbare Daten. Wie ein solcher Datenpfad von der Steuerung bis zum Dashboard in der Praxis aussieht, zeigen die Lösungen von ralwo.