Pub Sub Brücke

Einführung

Verbesserte Interoperabilität und nahtlose Kommunikation sind die Hauptmotive für das Aufkommen von OPC UA. Das Klient-Server-Modell ist zwar die historische Art und Weise, wie OPC-UA-Anwendungen miteinander kommunizieren, wird aber für die Punkt zu Punkt Kommunikation als besser geeignet angesehen.

Der Klient und der Server sind direkt miteinander verbunden, so dass eine SPS oder eine Host Workstation eine Information anfordern kann, die dann von den Sensoren, Ventilen oder anderen Feldgeräten abgeholt wird. Wenn die Anzahl der Geräte auf beiden Seiten zunimmt, steigt jedoch auch die Anzahl der Datenanforderungen, und der Netzwerkdurchsatz nimmt ab. Außerdem war beim Klient-Server-Modell die Antwortrate für Daten immer das Mindeste, was beide Komponenten unterstützen konnten.

Angesichts der raschen Verbreitung von IIoT-Geräten war ein robustes Kommunikationsnetzwerk, das unabhängig von Klient-Server-Funktionen ist und in einer verbindungslosen Umgebung funktioniert, unerlässlich. Um diesem dringenden Bedarf zu genügen, ist die OPC UA Part 14 Spezifikation entstanden, die ein Pub-Sub Modell bespricht, eine perfekte Lösung, um die Kommunikation in modernen IIoT Szenarien zu ermöglichen. OPC UA Pub-Sub ist die etablierte Norm für IIoT-Plattformen bei allen Cloud Anbietern.

Gegenüber der Klient-Server-Kommunikation ermöglicht die OPC UA Pub-Sub Bridge eine skalierbare, schnelle Kommunikation, die unabhängig von Klient- oder Server-Einschränkungen ist.

Bei diesem Modell senden die Herausgeber die Nachrichten an die nachrichtenorientierte Middleware, ohne den oder die Teilnehmer zu kennen. Ebenso zeigen die Abonnenten Interesse an bestimmten Nachrichten, ohne den/die Herausgeber zu kennen. Diese Herausgeber sind OPC UA Server und die Abonnenten sind OPC UA Klienten.

Warum braucht die Industrie OPC UA Pub-Sub?

Bei der OPC UA Klient-Server basierten Kommunikation warten die Server darauf, dass der/die Klient(s) die Kommunikationsanfragen stellen. Sobald der Server auf die Anfrage(n) antwortet, geht er wieder in den Wartezustand über, bis eine weitere Kommunikationsanfrage eintrifft. Daher kann der OPC UA Server die Daten nicht schneller veröffentlichen, als der OPC UA Klient es verlangt.

Obwohl die typische Klient-Server-Kommunikation auf einer dienstorientierten Architektur beruht, die Kompatibilität und Interoperabilität bietet, hat sie einige Einschränkungen,die sind:

• Begrenzte Skalierbarkeit: Da Klient(s) und Server(s) direkt miteinander verbunden sind, wird die Leistungsfähigkeit beider Seiten mit zunehmender Belastung eingeschränkt. Ein OPC UA-Server kann nicht hochskalieren, der viele OPC-Klienten unterstützt, während die Aktualisierungsraten in Sekunden oder Millisekunden gehalten werden..
• Zyklus Abhängigkeit veröffentlichen: Die Datenmuster, die einen bestimmten Veröffentlichungszyklus verpasst haben, werden erst im nächsten Veröffentlichungszyklus nachgeholt.
• Erfordernis einer größeren Fußabdruck: Mit zunehmender Anzahl von Klienten steigen die Speicher- und Verarbeitungsanforderungen des Servers, um mehrere Klient-Nachrichtensitzungen, die Datenspeicherung und den Nachrichtenaustausch mit einzelnen Klienten zu unterstützen.

OPC UA Pub-Sub Bridge Architektur

OPC UA Pub-Sub befasst sich mit den oben genannten Herausforderungen auf eine sicherere und stromlinienförmiger Weise. Dabei können die OPC-Anwendungen die Rolle von Herausgeber und Abonnenten übernehmen, wobei die Nachrichten über eine Middleware ausgetauscht werden. Die Nachrichtenorientierte Middleware unterstützt das Verbinden, Senden und Empfangen von Nachrichten zwischen verteilten Anwendungen mit Hilfe von Protokollen.

Das Pub-Sub-Konzept ermöglicht die Nutzung von OPC UA direkt über das Internet oder die Cloud unter Verwendung von Middleware wie MQTT (Message Queue Telemetry Transport) und AMQP (Advanced Message Queuing Protocol). Daher kommuniziert keine der Anwendungen direkt miteinander. Die Middleware funktioniert als Makler, der die Nachrichten weiterleitet.

Jeder DataSet wird als DataSet-Nachricht in einem bestimmten, vom DataSet-Schreiber angegebenen Format übertragen. Es gibt zwei Formate, in denen die DataSets geschrieben werden JSON und UADP.

OPC UA Pub-Sub befasst sich mit den Herausforderungen, die Klient-Server mit sich bringt, und zwar auf folgende Weise

• Leicht skalierbar: Da Klient(s) und Server(s) nicht direkt miteinander verbunden sind, sondern über eine Makler-Middleware kommunizieren, wirkt sich eine Erhöhung der Anzahl der Geräte auf beiden Seiten nicht auf die Leistung aus. So wird die Architektur besser skalierbar.
• Keine Daten Antwortquote Beschränkungen: Gegenüber dem Klient-Server-Modell müssen sich die beiden Parteien nicht auf ein Nachrichten Intervall einigen. Der Server kann die Datasets jederzeit veröffentlichen, unabhängig von der Datenanfrage des Klient.
• IIoT Möglichmacher: OPC UA Pub-Sub ist die etablierte Norm für IIoT-Plattformen bei allen Cloud Anbietern. Durch die Fähigkeit, verteilte Intelligenz zu ermöglichen, gleicht Pub-Sub die Netzwerklasten aus und verteilt Nachrichten auf effektive Weise an die Gleichaltrigen, was die Grundlage für das IIoT ist.

Warum Utthunga für OPC UA Pub-Sub Bridge?

Utthunga gehört zu den frühen Anwendern der OPC Pub-Sub Produkte. Wir entwickeln eine OPC Pub-Sub Bridge, die mit der OPC UA-Spezifikation kompatibel ist. Die folgenden Gründe sprechen dafür, dass Utthunga Ihre erste Wahl für OPC UA Pub-Sub Bridge Implementierungen sein sollte,sind:

1. Mehrere Einsatzszenarien: Die erstklassigen OPC-Kenntnisse von Utthunga ermöglichen die Bereitstellung von Pub-Sub Bridge in mehreren Variationen. Zwei dieser Fälle werden im Folgenden erläutert.

• Eins zu Eins: Ein Herausgeber sendet die Nachricht an eine Middleware, über die ein Abonnent die gewünschte Nachricht erhält.
• Viele-zu-Viele: Mehrere Herausgeber senden die Daten an viele Middleware, danach viele Abonnenten die Nachricht erhalten.

2. Unterstützung für klassische Framework: Die Pub-Sub-Architektur von Utthunga unterstützt auch Nicht-OPC-UA-Datenquellen wie klassische Server, Datenbanken oder andere Nachrichten-Queues.

3. Reaktionsfähigkeit nahezu in Echtzeit: Bei Utthunga können Sie Nachrichten nahezu in Echtzeit (Mikrosekunden) übertragen und große Nachrichtenpakete empfangen.

4. Ende-zu-Ende Sicherheit: Durch den Bereitstellung des Pub-Sub-Modells von Utthunga rüsten Sie Ihr Netzwerk mit Ende-zu-Ende Sicherheit aus, unabhängig von dem von Ihnen eingesetzten Verkehrsprotokoll. Bei JSON und UADP bleibt Ihr Netzwerk sicher, egal ob es vor Ort oder in der Cloud ist.

Die OPC UA Pub-Sub Bridge ist die Zukunft der industriellen Automatisierung. OPC UA Pub-Sub kann auf eingebetteten Geräten bereitgestellt in der Produktionsstätte verwendet und in die skalierbaren Cloud-basierten Anwendungen integriert werden, um die Produktion intelligenter und optimierter zu machen. Obwohl die Entwicklung noch in den frühe Stufen steckt, gibt es bereits ein breites Spektrum an industriellen Anwendungen.

Arbeiten Sie mit uns zusammen, um Ihre Automatisierungsfähigkeiten auf die nächste Stufe zu heben!