Optimierungen

Es gibt verschiedene Möglichkeiten, die Kommunikationsverbindung zwischen OPC UA Client- und -Server bzw. SPS zu optimieren. Auch das Laufzeitverhalten, insbesondere die CPU- und Arbeitsspeicherauslastung vom TwinCAT OPC UA Server, kann durch verschiedene Parameter optimiert werden. Dieses Kapitel stellt verschiedene Optimierungsmöglichkeiten vor, insbesondere zu den folgenden Themen:

SamplingInterval vs. PublishingInterval
StructuredTypes
StructuredTypes und deren Membervariablen

	Die hier dargestellten Screenshots und Performancewerte stellen Beispiele unter Laborbedingungen dar, welche auf unterschiedlichen Hardwaregeräten ausgeführt wurden. Sie lassen sich daher nicht 1:1 auf Kundenprojekte übertragen und dienen nur zur Veranschaulichung bestimmter Sachverhalte.

SamplingInterval vs. PublishingInterval

Beim Anlegen einer Subscription verwendet ein OPC UA Client verschiedene Parameter für die Subscription und die darin enthaltenen, sogenannten MonitoredItems, um Benachrichtigungen über Variablenänderungen zu erhalten. Die folgende Tabelle erklärt zwei dieser Parameter, welche anschließend näher beschrieben werden.

Parameter	Beschreibung
PublishingInterval	Das PublishingInterval gibt die Rate an, mit der ein OPC UA Client vom Server über Wertänderungen informiert wird. Das PublishingInterval wird in Part 4 der OPC UA Spezifikation detailliert beschrieben.
SamplingInterval	Das SamplingInterval gibt die Rate an, mit der der OPC UA Server seine unterliegende Datenquelle nach Wertänderungen abtasten soll, im Falle des TwinCAT OPC UA Servers über die ADS-Verbindung. Das SamplingInterval wird in Part 4 der OPC UA Spezifikation detailliert beschrieben.

Die folgende Grafik stellt den Zusammenhang zwischen diesen beiden Parametern noch einmal anschaulich dar. Es wird hierbei davon ausgegangen, dass der TwinCAT OPC UA Server auf der SPS-Steuerung installiert wurde und der OPC UA Client von einem externen System aus auf den Server zugreift.

Wie in dem Schaubild erkennbar, kann hierbei durchaus die Situation entstehen, dass der OPC UA Client bestimmte Wertänderungen in der SPS nicht mitbekommt, z. B. wenn diese entweder „zu schnell“ in der SPS passieren bzw. die SamplingRate nicht hoch genug ist bzw. ein Variablenwert wieder auf den ursprünglichen Wert zurück geht (wie oben erkennbar). Über einen weiteren Parameter, die sogenannte QueueSize, lassen sich mehrere Wertänderungen zwischen den PublishingIntervallen erfassen und an den OPC UA Client übertragen. In obigem Beispiel wurde eine QueueSize von 1 gewählt, d. h. es wird immer der „Last Known Value“ an den Client übertragen. In dem folgenden Schaubild wurde hingegen eine QueueSize von 2 gewählt, d. h. es werden die letzten zwei bekannten Wertänderungen an den Client übertragen.

Bei dem ersten PublishResponse lässt sich erkennen, dass nur eine Wertänderung an den Client übermittelt wird, da auch nur eine Wertänderung in der SPS stattgefunden hat. Beim zweiten PublishResponse lässt sich erkennen, dass zwei Wertänderungen in der SPS stattgefunden haben und beide auch an den Client übertragen werden.

Bei den oben beschriebenen Parametern handelt es sich um Einstellungen, die der Client üblicherweise selbst in der Hand hat und beim Server anfragt. Und genau hier lassen sich viele Optimierungen vornehmen, denn beide Parameter haben einen starken Einfluss darauf, wie viel CPU-Zeit der OPC UA Client- und -Server benötigen, da entsprechend viele Informationen verarbeitet bzw. angefragt werden müssen.

Abhängig vom verwendeten Einsatzszenario sollten die beiden Parameter entsprechend sinnvoll eingestellt werden. Wenn es sich bei dem OPC UA Client zum Beispiel um eine Visualisierung handelt, dann machen schnelle PublishingIntervalle und SamplingRaten nur bedingt Sinn, da das menschliche Auge ohnehin keine Informationen schneller als ~200 ms verarbeiten kann. Auch die Verwendung der QueueSize sollte in Abhängigkeit zum Einsatzszenario sinnvoll gewählt werden. Wenn der OPC UA Client ohnehin keine Werte aus der Queue verarbeitet, ist eine QueueSize von 1 ausreichend und sinnvoll, da entsprechend weniger Informationen übertragen werden müssen und dies das System weiter optimiert.

In dem folgenden Beispiel hat ein OPC UA Client eine Subscription mit 10.000 Variablen auf dem TwinCAT OPC UA Server angelegt. Als PublishingInterval wurden hierbei 500 ms und als SamplingInterval 250 ms gewählt. Die CPU-Auslastung des TwinCAT OPC UA Servers lag bei einem Durchschnittswert von ca. 6,9 %, siehe folgenden Screenshot vom Windows Performance Monitor.

Anschließend wurde das PublishingInterval auf 200 ms und das SamplingInterval auf 100 ms eingestellt. Die CPU-Auslastung des TwinCAT OPC UA Servers erhöhte sich hierdurch auf einen Durchschnittswert von ca. 19 %.

StructuredTypes

Standardmäßig stellt der TwinCAT OPC UA Server Strukturen als FolderType in seinem Adressraum bereit. Die Membervariablen werden dann als separate Nodes unterhalb des Folders dargestellt und auf sie kann zugegriffen werden. Der Server ermöglicht auch die Verwendung von StructuredTypes für die Struktur, wodurch die Typinformationen der Struktur vom Client verarbeitet werden und die Struktur datenkonsistent gelesen/geschrieben werden kann. Bei der Kommunikation mit der SPS (über das TwinCAT-ADS-Protokoll) verhalten sich beide Varianten grundlegend unterschiedlich.

Bei dem Zugriff eines OPC UA Clients auf einzelne Membervariablen kann es, je nach Anzahl der Variablen, durchaus passieren, dass die ADS-Kommunikation auf mehrere ADS Read/Write Kommandos aufgeteilt wird. Dies kann wiederum zur Folge haben, dass die ADS-Kommandos in unterschiedlichen SPS-Zyklen von der SPS abgearbeitet werden. Eine Datenkonsistenz kann hierbei also nicht garantiert werden.

Bei dem Zugriff eines OPC UA Clients auf einen StructuredType wird hingegen sichergestellt, dass der StructuredType in einem einzigen ADS Read/Write Kommando von der SPS abgearbeitet wird, wodurch eine Datenkonsistenz sichergestellt wird.

Bei der Verwendung von StructuredTypes für große SPS-Datenstrukturen sollten die folgenden Dinge beachtet werden:

Das ADS Read/Write Kommando bzw. die entsprechende Antwort kann je nach Strukturgröße sehr groß werden und entsprechend viel Speicher im TwinCAT-ADS-Router benötigen. Bitte achten Sie daher auf den Routerspeicher.
StructuredTypes müssen bei der Kommunikation mit der TwinCAT-Echtzeitumgebung vom TwinCAT OPC UA Server kodiert bzw. dekodiert werden, was zusätzliche CPU-Zeit benötigt.
Je nach Größe der Struktur können Lese-/Schreibkommandos lange dauern, was auch stark abhängig von der Zeit ist die der Server zum Codieren/Decodieren benötigt.

Aus diesen Gründen ist die Maximalgröße eines StructuredTypes im Auslieferungszustand des Servers limitiert, kann jedoch bei Bedarf über den Parameter <MaxStructureSize> in der Konfigurationsdatei TcUaDaConfig.xml angepasst werden. Dieser Parameter gibt die maximale Größe einer Struktur in Bytes an. Wenn eine Struktur die Größe <MaxStructureSize> überschreitet, wird sie als FolderType importiert, wo jedes Strukturelement als einzelner Knoten verfügbar ist. Für weitere Informationen siehe Kapitel Strukturen.

Gerade im Zusammenhang mit den bei einer Subscription einstellbaren Parametern zum SamplingInterval und PublishingInterval lassen sich bei StructuredTypes einige Optimierungen vornehmen, welche einen großen Einfluss auf das Laufzeitverhalten des Servers haben können.

In dem folgenden Beispiel hat ein OPC UA Client eine Subscription auf einen StructuredType angelegt. Die unterlagerte SPS-Datenstruktur ist hierbei wie folgt aufgebaut:

TYPE ST_TEST :
STRUCT
  stComplex : ST_Complex_1;
  strString5 : STRING[5]; 
  eEnum : E_Enum_1;
  strString3 : STRING[3]; 
  arrComplex : ARRAY[0..9999] OF ST_Complex_1;
  arrDint : ARRAY[0..9999] OF DINT;
END_STRUCT
END_TYPE

Die als Membervariable verwendete Struktur ST_Complex_1 ist ca. 91 Byte groß. Insgesamt handelt es sich hierbei also um eine Datenstruktur mit einer Gesamtgröße von ca. 1 Mbyte. Als PublishingInterval wurden 500 ms und als SamplingInterval 250 ms gewählt. Die CPU-Auslastung des TwinCAT OPC UA Servers lag nach dem Anlegen der Subscription bei einem Durchschnittswert von ca. 54,6 %, siehe folgenden Screenshot vom Windows Performance Monitor.

Entsprechend des gewählten SamplingIntervals wird bei der unterlagerten ADS-Kommunikation ca. alle 250 ms ein ADS Read abgesetzt. Bei dem zugehörigen Response erkennt man deutlich die Größe der Datenstruktur von ca. 1 Mbyte, d. h. dass alle 250 ms ein 1 Mbyte großes Datenpaket durch den TwinCAT-ADS-Router transportiert wird (und vom Server entsprechend verarbeitet werden muss). Der Codierungs/Decodierungs-Vorgang vom Server benötigt entsprechend viel CPU-Leistung, was die hohe CPU-Auslastung erklärt.

StructuredTypes und deren Membervariablen

Standardmäßig werden die Membervariablen eines StructuredType im Adressraum des Servers als eigene Nodes dargestellt und verfügbar gemacht. Dies benötigt zusätzlichen Arbeitsspeicher, da der TwinCAT OPC UA Server für jede Node Arbeitsspeicher allokiert. Ein OPC UA Client, der ausschließlich mit dem StructuredType, also dem „Rootelement“ einer Struktur arbeitet, benötigt diese zusätzlichen Nodes nicht. Diese lassen sich über ein spezielles Pragma explizit ausblenden, was die Arbeitsspeicherauslastung des Servers verringert. Das Pragma ist im Kapitel Strukturen näher beschrieben.