OPC UA auf der S7-1500: Grenzen, die selten dabeistehen

„Die Steuerung kann OPC UA“ steht in fast jedem Lastenheft, und es stimmt. Was dort selten steht, sind die Eigenschaften, an denen MES-Anbindungen später scheitern — und zwar nicht mit einer Fehlermeldung, sondern still.

Still heißt hier: Die Verbindung steht, der Client bekommt Antworten, und auf Protokollebene ist jede einzelne davon korrekt. Falsch wird erst, was das übergeordnete System daraus schließt. Dieser Artikel sammelt die Stellen, an denen das geschieht, bevor sie im Anlauf auffallen. Für den Vergleich mit der klassischen S7-Kommunikation lohnt der Blick auf die Frage, warum ein Snap7-Zugriff scheitert — die beiden Wege lösen dieselbe Aufgabe mit gegensätzlichen Nachteilen.

Was an welche Firmware gebunden ist

Die Aussage „die S7-1500 kann OPC UA“ ist zu grob für eine Zusage. Der Funktionsumfang hängt an der Firmware, und die Grenzen liegen an unerwarteten Stellen — am deutlichsten dort, wo die Steuerung nicht antworten, sondern selbst fragen soll. Wer eine CPU als OPC-UA-Client plant, prüft deshalb Firmware-Stand und Artikelnummer, nicht nur die Typbezeichnung.

Der Sprung von V2.9 auf V3.0 ist dabei ein starkes technisches Argument für ein Firmware-Update, das kaum jemand kennt: Die von Siemens empfohlene Zahl überwachter Elemente steigt von 1.000 auf 4.000 (CPU 1511 bis 1513), von 2.000 auf 4.000 (CPU 1515/1516) und von 10.000 auf 24.000 (CPU 1517/1518), die Subscriptions je Session von 20 auf 50; das kleinste Sendeintervall sinkt von 500 auf 200 ms (1511 bis 1513) und von 200 auf 100 ms (1515/1516). Sessions, Subscriptions je Server, die Obergrenze von 10.000 Elementen je Subscription und das kleinste Abtastintervall bleiben gleich — und die Elementzahlen sind Empfehlungen, keine harten Grenzen: Wer darüber liegt, bekommt BadOutOfMemory.

Ein Firmware-Update genügt dafür allerdings nur, wenn die CPU den Stand überhaupt annimmt. Siemens gibt V3.x für die Hardware-Generation mit Artikelnummer …03 (6ES751x-xxx03-0AB0) sowie für CPU 1516T, 1517 und 1518 frei; ältere Baugruppen der Klassen 1511 bis 1516 (…02 und früher) bleiben bei V2.9. Projektiert wird V3.0 ab TIA Portal V18 — das Projekt zieht also mit. Mit Firmware V4.0 (TIA Portal V20) hebt Siemens die Mengengerüste für die CPUs 151x-3 PN und 151xT-3 PN erneut an. Vor der Zusage deshalb Artikelnummer, Firmware-Stand und den Siemens-Firmware-Beitrag 109478459 prüfen.

Aber: Die empfohlene Gesamtzahl überwachter Elemente gilt unter Bedingungen, die Siemens ausdrücklich nennt.

Zwei Grenzen dagegen sind hart, und sie liegen beim Server, nicht beim Client. Die eine ist das kleinste Abtastintervall: 100 ms bei CPU 1511 bis 1516 (und dem Software Controller 1505S), 10 ms erst bei CPU 1517 und 1518 (und 1507S) — darunter geht es auf keiner S7-1500. Die andere ist das kleinste Sendeintervall, in dem der Server Änderungen überhaupt ausliefert: ab Firmware V3.0 200 ms bei 1511 bis 1513 (bis V2.9: 500 ms), 100 ms bei 1515/1516 (bis V2.9: 200 ms), 10 ms bei 1517/1518. Dazu kommt der Wert, den der Projekteur in den Server-Einstellungen als kleinstes Abtast- und Sendeintervall einträgt: Fordert ein Client weniger, bleibt der Server bei seinem Minimum; ein Client, der kein Abtastintervall vorgibt, wird im Sendeintervall abgetastet; kommt der Server mit der Abtastung nicht nach, quittiert er das mit dem Statuscode GoodOverload. Wer auf einer 1513 oder 1516 eine Erfassung im 10-ms-Raster zusagt, kann das prinzipbedingt nicht halten — unabhängig davon, was der Client anfordert. Beide Grenzen gehören in die Schnittstellenbeschreibung.

Der teuerste stille Fehler: Strukturen

SIMATIC-Strukturen sind über OPC UA nicht konsistent lesbar oder schreibbar. Betroffen sind anwenderdefinierte Typen, unbenannte Strukturen, strukturierte Systemdatentypen wie DTL, IEC_TIMER und IEC_COUNTER — und auch Zeichenketten (Array of Char). Konsistent bleiben dagegen alle elementaren Typen einschließlich LDT, DATE, TIME und TIME_OF_DAY: Ein Zeitstempel im Übergabebereich gehört deshalb als LDT hinein, nicht als DTL.

Was das praktisch heißt: Ein Rezept- oder Auftragsdatensatz, der als Struktur abgeholt wird, kann Werte aus zwei verschiedenen Zyklen enthalten. Auftragsnummer neu, Sollmenge alt. Es gibt keine Fehlermeldung zur Laufzeit; das Rezept ist einfach falsch.

Die Suche beginnt danach an der falschen Stelle: Ein Auftrag, der beim MES widersprüchlich ankommt, sieht dort wie ein Fehler des MES aus. Erst wenn dort alles geprüft ist, wandert der Verdacht zur Steuerung — und in der Steuerung funktioniert sichtbar alles.

Der Server verschweigt das allerdings nicht ganz, er sagt es nur vorher, an einer Stelle, die kaum ein Client liest: Ab Firmware V2.6 setzt er bei nicht konsistent lesbaren Knoten das Bit 8 (NonatomicRead) und bei nicht konsistent schreibbaren das Bit 9 (NonatomicWrite) im Attribut AccessLevelEx; im XML-Export der Server-Schnittstelle steht dieselbe Information im 32 Bit breiten Attribut AccessLevel. Wer die Anbindung einrichtet und diese Bits beim Browsen auswertet, findet die Strukturen, bevor das MES sie findet.

Zwei Wege bleiben. Wo die Gegenseite Methodenaufrufe beherrscht, übergibt eine serverseitige OPC-UA-Methode (ab Firmware V2.5) einen Datensatz konsistent — laut Funktionshandbuch der einzige Weg, der über elementare Datentypen hinaus Konsistenz sichert. Für alles andere — Lesen, Schreiben, Subscriptions — liegt die Lösung im Anwenderprogramm, nicht in der Anbindung: Zusammengehörige Daten in einem Zug in einen Übergabebereich kopieren und mit einem Gültigkeitskennzeichen versehen, das der Client zuerst prüft. Das ist in der Sache derselbe Mechanismus, den man auch bei der klassischen S7- und HMI-Kommunikation braucht — dort nimmt die S7-1500 einem einen Teil ab, weil sie Blöcke bis 512 Byte systemseitig konsistent kopiert, sofern das Programm sie in einem Zug schreibt; bei OPC UA gilt er für jede Struktur, egal wie klein. Nur erwartet ihn dort kaum jemand. Wie ein solcher Bereich aussieht, steht weiter unten.

Der Server antwortet auch im STOP

Diese Eigenschaft verdient einen eigenen Abschnitt, weil ihre Folgen so weitreichend sind: Der OPC-UA-Server läuft im Betriebszustand STOP weiter. Lese- und Schreibanfragen beantwortet er wie gewohnt und liefert die letzten Werte von vor dem Stopp. Schreibzugriffe nimmt er an, der Client bekommt eine Erfolgsmeldung, und ein Rücklesen zeigt den geschriebenen Wert — eine Rücklese-Prüfung im MES bestätigt den Auftrag also scheinbar. Die Steuerung verarbeitet ihn aber nicht, und beim Anlauf überschreibt sie mit den Startwerten, was im STOP geschrieben wurde. Nur Methodenaufrufe weist der Server im STOP mit dem Statuscode BadInvalidState (16#00AF_0000) zurück, weil ihr Programmteil nicht läuft: Eine Anbindung, die Aufträge per Methode übergibt, bemerkt den Stopp also — eine, die nur Variablen schreibt, nicht.

Die Gegenmaßnahme ist einfach und gehört in jede Anbindung: ein Lebenszeichen im Datenmodell — ein Zähler, den das Anwenderprogramm zyklisch hochzählt und den der Client auf Änderung überwacht. Steht der Zähler, steht die Steuerung. Den Betriebszustand der CPU stellt der Server zwar auch über seine Geräteinformationen bereit, und ein Client kann ihn überwachen; das Lebenszeichen ersetzt das nicht, es ergänzt es: Es belegt, dass das Anwenderprogramm tatsächlich rechnet und nicht nur die CPU in RUN steht.

Zeitstempel bedeuten nicht, was man denkt

Werden CPU-Variablen wie üblich in den Adressraum des Servers abgebildet, setzt der Server den Zeitstempel der Quelle (SourceTimestamp) nicht auf den Zeitpunkt der Wertänderung, sondern auf den Zeitpunkt, zu dem der Wert im Server erfasst wurde — durch einen Lesedienst oder die Abtastung einer Subscription, also auf den Abtastzeitpunkt.

• Wert im Anwenderprogramm und beim Client
• Abtastung durch den Server
• Zeitstempel, CPU-STOP und seine Folgen

Eigene Darstellung nach Siemens-Funktionshandbuch „Kommunikation" (S7-1500/ET 200, Beitrag 59192925, Ausgabe 11/2025), Kapitel OPC UA-Kommunikation — SourceTimestamp beim Abbilden von CPU-Variablen, Verhalten des Servers im Betriebszustand STOP.

Für Anzeigen ist das gleichgültig. Für Aufzeichnungen, Rückverfolgbarkeit und Chargennachweise ist es das nicht: Die Auflösung des Zeitstempels ist das Abtastintervall — und das ist, sobald der Client es nicht ausdrücklich setzt, das Sendeintervall der Subscription. Wer also im Sekundenbereich abtastet, bekommt Zeitstempel im Sekundenraster, die zudem systematisch später liegen als das Ereignis; ein kürzeres Abtastintervall verfeinert das Raster, hebt den Verzug aber nicht auf. Wo der Änderungszeitpunkt Teil des Nachweises ist, muss er aus dem Anwenderprogramm kommen.

Zwei Wege gibt es dafür. Der eine funktioniert auf jeder Firmware: den Zeitpunkt als eigenen Wert vom Typ LDT in den Übergabebereich schreiben, den der Client neben dem Nutzwert liest. Der andere setzt Firmware V3.0 (TIA Portal V18) und eine eigene Server-Schnittstelle voraus: Dort kann das Anwenderprogramm mit der Anweisung OPC_UA_WriteList über die lokale Verbindung Wert, StatusCode und SourceTimestamp (LDT) gemeinsam in einen Knoten schreiben — der Zeitstempel steht dann im OPC-UA-Attribut selbst, wo Archiv und MES ihn ohnehin suchen. Der Knoten darf dabei nicht auf eine CPU-Variable abgebildet sein und ist für Clients nur lesbar.

Ein Übergabebereich, der drei Fehlerbilder zugleich abstellt

Gültigkeitskennzeichen, Lebenszeichen und Änderungszeitpunkt lösen drei verschiedene Probleme — aber sie liegen an derselben Stelle: in dem Bereich des Anwenderprogramms, den der Client liest. Deshalb entstehen sie zusammen und nicht nacheinander.

Voreinstellungen des OPC-UA-Servers, die man kennen sollte

Die Runtime-Lizenz für OPC UA auf der S7-1500

Die Runtime-Lizenz gilt je CPU und deckt Server- wie Client-Funktion ab. Ihre Größe richtet sich nach einer festen Zuordnungsliste, nicht nach der Baugröße oder dem Gehäuse — wer nach Bauform kalkuliert, kalkuliert falsch. Die Liste ist kurz: „small“ für CPU 1511, 1512, 1513, alle ET-200SP-CPUs und die CPU 1515SP PC; „medium“ für CPU 1515, 1516, 1516pro-2 PN und den Software Controller CPU 1507S; „large“ nur für CPU 1517 und 1518 (Funktionshandbuch „Kommunikation“, Ausgabe 11/2025). Die 1516pro im Feldgehäuse zählt also wie eine 1516, und der Software Controller läuft bei den Mengengerüsten mit den großen CPUs, lizenziert wird er als medium. Den benötigten Typ zeigt TIA Portal für jede CPU selbst an, unter Eigenschaften > Allgemein > Runtime-Lizenzen > OPC UA.

Technisch erzwungen wird sie nicht: In den Eigenschaften der CPU wird lediglich der Typ der erworbenen Lizenz ausgewählt — das Handbuch nennt das „Bestätigung des Erwerbs“. Ein Lizenzschlüssel wird nicht in die Steuerung geladen; eine Prüfung in der CPU beschreibt Siemens nicht. Das erklärt, warum in der Praxis Anlagen unlizenziert laufen können, ohne dass es jemandem auffällt — eine Fehlermeldung oder einen Diagnoseeintrag dafür beschreibt das Handbuch ebenso wenig. Bei einer Bestandsaufnahme im Produktionsnetz gehört dieser Punkt deshalb auf die Liste: nicht, weil etwas nicht funktioniert, sondern weil eine Lizenzlücke sonst erst beim Audit sichtbar wird.

Wenn es passt, ist es der richtige Weg

Nichts davon spricht gegen OPC UA. Für eine neue Anbindung ist es der technisch sauberste Weg an die S7-1500: symbolisch statt absolut, authentifizierbar, verträglich mit optimierten Bausteinen und ohne die Freigaben, die die klassische Kommunikation verlangt.

Die Punkte oben sind keine Argumente dagegen, sondern die Liste dessen, was in die Auslegung gehört — bevor jemand ein Mengengerüst zusagt, das aus einer Labortabelle stammt.