TF6100 vs. TF6105
Beckhoff bietet mit TF6100 TwinCAT 3 OPC UA und TF6105 TwinCAT 3 OPC UA Pub/Sub zwei TwinCAT 3 Funktionen für die OPC UA Kommunikation an. Beide Produkte basieren auf OPC UA, implementieren jedoch unterschiedliche Kommunikationsmodelle und adressieren unterschiedliche Anforderungen.
TF6100 wird vor allem dann eingesetzt, wenn Anwendungen einen dienstorientierten Zugriff auf ein OPC UA Informationsmodell benötigen. Clients können sich mit einem Server verbinden, dessen Adressraum durchsuchen, Werte lesen und schreiben, Wertänderungen abonnieren, Methoden aufrufen und weitere OPC UA Funktionen verwenden.
TF6105 ist für die zyklische oder ereignisgesteuerte Verteilung vordefinierter DataSets ausgelegt. Publisher versenden Nachrichten, ohne individuelle Leseanfragen jedes einzelnen Empfängers verarbeiten zu müssen. Abhängig vom gewählten Transport werden die Nachrichten direkt über UDP oder über einen MQTT Message Broker verteilt.
Die beiden Produkte ergänzen sich somit gegenseitig. Welches Produkt sich für eine Anwendung eignet, hängt in erster Linie davon ab, wie Informationen erkannt, abgerufen und ausgetauscht werden sollen.
TF6100: Dienstorientierter Zugriff mit OPC UA Client/Server
TF6100 implementiert das etablierte OPC UA Client/Server Kommunikationsmodell. Ein OPC UA Client baut eine sichere Verbindung und Session zu einem OPC UA Server auf und verwendet anschließend standardisierte Dienste, um mit dem Adressraum des Servers zu interagieren.
Das TF6100 Produktpaket enthält folgende Komponenten:
- TwinCAT OPC UA Server, der Daten und Funktionen aus TwinCAT-Laufzeitumgebungen über einen OPC UA Adressraum bereitstellt.
- TwinCAT OPC UA Client, mit dem TwinCAT-Anwendungen auf entfernte OPC UA Server zugreifen können.
- TwinCAT OPC UA Gateway, das untergeordnete OPC UA Server aggregieren und eine OPC-COM-DA Anbindung bereitstellen kann.
Der TwinCAT OPC UA Server kann SPS-Variablen und andere TwinCAT-Laufzeitdaten als Nodes in einem strukturierten Adressraum darstellen. Clients können die verfügbaren Nodes und deren Metadaten zur Laufzeit untersuchen. Es ist daher nicht erforderlich, jedes auszutauschende Element vorab festzulegen.
Zu den typischen Client/Server Operationen gehören:
- Durchsuchen des Adressraums
- Lesen und Schreiben von Variablenwerten
- Anlegen von Subscriptions für Wertänderungen
- Aufrufen von Methoden
- Empfangen von Alarmen und Ereignissen
- Zugriff auf historische Daten
- Untersuchen von Datentypen, Referenzen und semantischen Informationen
- Import von Companion Spezifikationen
Damit eignet sich TF6100 insbesondere für die Kommunikation mit HMIs, SCADA-Systemen, MES- und ERP-Anwendungen, Engineering-Werkzeugen, Diagnoseanwendungen und anderen Systemen, die einen flexiblen Zugriff auf Maschineninformationen benötigen.
TF6105: Verteilung von DataSets mit OPC UA Pub/Sub
TF6105 implementiert das in OPC UA Part 14 definierte Publisher/Subscriber Kommunikationsmodell. Das Produkt wird über das sogenannte OPC UA RT Device in die TwinCAT-Laufzeit integriert und unterstützt sowohl Publisher- als auch Subscriber-Konfigurationen.
Ein Publisher fasst ausgewählte Prozesswerte in einem PublishedDataSet zusammen und sendet die zugehörigen NetworkMessages in einem konfigurierten Intervall. Subscriber empfangen die Nachrichten, identifizieren das relevante DataSet, dekodieren dessen Felder und verknüpfen die empfangenen Werte mit ihrem lokalen Prozessabbild.
TF6105 unterstützt zwei grundlegende Transportvarianten:
- UDP mit UADP-Kodierung für eine direkte Kommunikation ohne Broker, einschließlich Unicast- und Multicast-Szenarien.
- MQTT mit UADP- oder JSON-Kodierung für eine brokerbasierte Verteilung über Netzwerkgrenzen hinweg sowie in IT- oder Cloud-Umgebungen.
Da die auszutauschenden DataSets und deren Zuordnungen im Voraus konfiguriert werden, muss die Laufzeit weder einen entfernten Adressraum durchsuchen noch für jeden Wert einzelne Leseoperationen ausführen. Dadurch eignet sich Pub/Sub besonders für die effiziente zyklische Datenverteilung und für Kommunikationsbeziehungen mit mehreren Empfängern.
Typische Anwendungen sind:
- Controller-to-Controller- und Machine-to-Machine-Datenaustausch
- Verteilung von Prozesswerten an mehrere Empfänger
- zyklische Kommunikation mit definierten Publishing-Intervallen
- brokerbasierte Verteilung von Maschinendaten über MQTT
- Integration von Automatisierungsdaten in Edge- oder Cloud-Anwendungen
- Entkopplung von Datenproduzenten und Datenkonsumenten
TF6105 stellt keinen durchsuchbaren Serveradressraum bereit und bietet keine Client/Server Dienste wie Read, Write, Call, Historical Access oder Alarms & Conditions. Das Produkt überträgt die Felder der konfigurierten DataSets.
Die wichtigsten Unterschiede im Überblick
Aspekt | TF6100 | TF6105 |
|---|---|---|
OPC UA Kommunikationsmodell | Client/Server | Publisher/Subscriber |
Hauptzweck | Flexibler, dienstorientierter Zugriff auf ein Informationsmodell | Effiziente Verteilung vordefinierter DataSets |
Hauptrollen | Server und Client | Publisher und Subscriber |
Kommunikationsbeziehung | Zustandsbehaftete Verbindung und Sitzung zwischen Client und Server. | Publisher und Subscriber sind auf Anwendungsebene entkoppelt. |
Datenauswahl | Ein Client durchsucht den Adressraum oder kennt die NodeIds und wählt die benötigten Nodes aus. | DataSet-Felder werden während des Engineerings ausgewählt und in der Konfiguration zugeordnet. |
Erkennung zur Laufzeit | Adressraum, Nodes, Referenzen, Datentypen und Metadaten können durchsucht werden. | Subscriber benötigen in der Regel eine passende Konfiguration oder ausgetauschte Pub/Sub-Konfigurationsinformationen. |
Wertezugriff | Read, Write und Client/Server-Subscriptions | Zyklische oder ereignisgesteuerte DataSet-Nachrichten |
Methodenaufrufe | Über das Client/Server-Dienstmodell unterstützt | Nicht Bestandteil des Pub/Sub-DataSet-Austauschs |
Alarme und historische Daten | Werden vom TwinCAT OPC UA Server unterstützt. | Werden nicht als entsprechende Client/Server-Dienste bereitgestellt. |
Topologie | Typischerweise verbindet sich ein Client mit einem Server; mehrere Clients können unabhängige Verbindungen aufbauen. | Geeignet für One-to-One-, One-to-Many- und Many-to-Many-Verteilungsmuster. |
Transportbeispiele | OPC UA Client/Server Transport mit sicheren Sessions | UDP oder MQTT |
Nachrichtenkodierung | OPC UA Client/Server Dienstnachrichten | UADP; bei MQTT ist zusätzlich JSON verfügbar |
Broker erforderlich | Nein | Nein bei UDP; ja bei MQTT |
Typischer Schwerpunkt | Interoperabilität, Informationsmodelle, Diagnose, Befehle und flexibler Datenzugriff | Zyklischer Prozessdatenaustausch, skalierbare Verteilung und Entkopplung von Produzenten und Konsumenten |