Softwarearchitektur
Vorherige Versionen vom TwinCAT OPC UA Client (Versionen 1.x.x) bestanden aus mehreren Komponenten, welche eng miteinander verzahnt waren. Hierbei handelte es sich um:
- Einen Prozess im Betriebssystem (TcOpcUaClient.exe)
- Einen Kommunikationstreiber in der Echtzeit (TcIoOpcUa.sys)
- Eine Erweiterung für das TwinCAT XAE
Das Zusammenspiel dieser Komponenten wird in dem folgenden Schaubild dargestellt:
Prozess im Betriebssystem
Der Prozess im Betriebssystem (TcOpcUaClient.exe) kümmert sich um die OPC UA Protokollfunktionen und stellt diese über einen ADS-Server zur Verfügung, sodass die TwinCAT-Echtzeitkomponenten (z. B. der Treiber oder die SPS-Bibliothek) darauf zugreifen können.
Kommunikationstreiber in der Echtzeit
Der Treiber in der Echtzeit ist zuständig für die Kommunikation des I/O-Geräts mit dem Prozess im Betriebssystem. Er wandelt die konfigurierten Prozessdaten in ADS-Telegramme um, welche mit dem Prozess ausgetauscht werden, um dort in OPC UA Befehle umgewandelt zu werden. Für die Konfiguration der Kommunikationsverbindung sowie Auswahl der Datenpunkte, gibt es eine Engineering-Komponente im TwinCAT XAE.
TwinCAT XAE Extension
Die Engineering-Komponente im TwinCAT XAE stellt eine grafische Konfigurationsschnittstelle für das I/O-Gerät bereit. Das heißt, dort können Variablen von OPC UA Servern ausgelesen- und zum Prozessabbild hinzugefügt werden, damit sie später zur Laufzeit verarbeitet werden können.
SPS-Bibliothek
Die SPS-Bibliothek stellt die OPC UA Funktionen des Prozesses im Betriebssystem für die SPS-Logik zur Verfügung. Ähnlich wie der Treiber, kommuniziert die SPS-Bibliothek somit per ADS mit dem Prozess, um auf die OPC UA Funktionen zugreifen zu können.
TwinCAT OPC UA Client ab Version 2.x.x
Neuere Versionen vom TwinCAT OPC UA Client bestehen nur noch aus einer Engineering- und einer Runtime-Komponente (dem sogenannten „Treiber“). Der Prozess im Betriebssystem (TcOpcUaClient.exe) entfällt.
Der Treiber stellt hierbei den kompletten OPC UA Kommunikations-Stack zur Verfügung, welcher dann sowohl vom Engineering- als auch von der TwinCAT Runtime verwendet wird. Dies reduziert nicht nur die Komplexität, sondern ermöglicht auch die Verwendung einer einheitlichen und zentralen Kommunikationsverbindung mit dem Server. Das Engineering baut nämlich nicht mehr länger eine eigene Kommunikationsverbindung mit dem OPC UA Server auf, sondern verwendet hierfür den Treiber des ausgewählten Zielgeräts. (Natürlich kann das Zielgerät hierbei auch das lokale System sein.)
Das folgende Schaubild verdeutlicht diesen Zusammenhang nochmals.
Durch diese Vorgehensweise wird die Komplexität bei der Zertifikatsverwaltung reduziert, denn es gibt nur noch einen zu verwaltenden Zertifikatsspeicher – nämlich den des Treibers. Zusätzlich werden auch Netzwerkumgebungen unterstützt, in denen der OPC UA Server zwar vom Runtime-System, aber nicht vom Engineering-System aus erreichbar ist. Dies ist typischerweise in Betriebsumgebungen der Fall, in denen die Steuerung unterschiedliche Netzwerksegmente auf dedizierte Netzwerkkarten aufteilt, z.B. ein „Machine“ Segment und ein „Maintenance“ Segment – letzteres zum Verbinden eines Engineering-Laptops im Wartungsfall. Dieser Zusammenhang ist noch einmal in dem folgenden Schaubild exemplarisch dargestellt.
Das folgende Schaubild verdeutlich diesen Zusammenhang noch einmal in etwas anderer Darstellungsform.
