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 den Firmware-Stand, nicht das Typenschild.

Der Sprung auf den Stand V3.0 ist dabei das stärkste technische Argument für ein Firmware-Update, das kaum jemand kennt: Die Subscription-Grenzen vervielfachen sich bei gleicher Hardware. Man bekommt ein Vielfaches der überwachbaren Datenpunkte, ohne eine neue CPU zu kaufen.

Aber: Diese Mengengerüste gelten unter Bedingungen, die Siemens ausdrücklich nennt.

Eine harte Grenze dagegen ist das kleinste Abtastintervall, und sie liegt nicht beim Client. Wer auf einer kleineren CPU eine Erfassung im Bereich weniger Millisekunden zusagt, kann das prinzipbedingt nicht halten — unabhängig davon, was der Client anfordert.

Der teuerste stille Fehler: Strukturen

SIMATIC-Strukturen sind über OPC UA nicht konsistent lesbar oder schreibbar. Betroffen sind anwenderdefinierte Typen, unbenannte Strukturen, Systemdatentypen wie Datum-und-Uhrzeit-Strukturen oder Zeitgeber — und auch Zeichenketten.

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; 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.

Die Lösung liegt 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 derselbe Mechanismus, den man auch bei der klassischen S7-Kommunikation braucht — nur erwartet ihn bei OPC UA 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. Er beantwortet Anfragen wie gewohnt und liefert die eingefrorenen Werte von vor dem Stopp. Schreibzugriffe nimmt er an, der Client bekommt eine Erfolgsmeldung — die Steuerung verarbeitet die Werte aber 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.

Zeitstempel bedeuten nicht, was man denkt

Werden CPU-Variablen wie üblich in den Adressraum des Servers abgebildet, setzt der Server den Zeitstempel der Quelle nicht auf den Zeitpunkt der Wertänderung, sondern auf den Zeitpunkt, zu dem der Wert im Server erfasst wurde — 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 „S7-1500 OPC UA“ — Zeitstempel der Quelle 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: Wer mit Subscriptions im Sekundenbereich arbeitet, bekommt Zeitstempel mit sekundengrober Auflösung, die zudem systematisch später liegen als das Ereignis. Wo der Änderungszeitpunkt Teil des Nachweises ist, muss er aus dem Anwenderprogramm kommen und als eigener Wert übertragen werden.

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, die man kennen sollte

Zur Lizenz

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.

Technisch erzwungen wird sie nicht: In den Eigenschaften der CPU wird lediglich der Typ der erworbenen Lizenz ausgewählt; ein Schlüssel wird nicht in die Steuerung übertragen und nicht geprüft. Das erklärt, warum in der Praxis Anlagen unlizenziert laufen, ohne dass es jemandem auffällt — es gibt keine Fehlermeldung und keinen Eintrag. 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.