VERFAHREN ZUM KONFIGURIEREN EINES OPC UA PUBSUB TEILNEHMERS, AUTOMATISIERUNGSSYSTEM, COMPUTERPROGRAMM UND COMPUTERLESBARES MEDIUM

Die Erfindung betrifft ein Verfahren zum Konfigurieren we nigstens eines OPC UA PubSub Teilnehmers in einem insbesonde re industriellen Netzwerk. Darüber hinaus betrifft die Erfin dung ein Automatisierungssystem, ein Computerprogramm und ein computerlesbares Medium.

OPC UA (OPC Unified Architecture) ist ein industrielles Stan dardprotokoll der OPC Foundation zur hersteller-unabhängigen Kommunikation für den Austausch von Maschinendaten insbeson dere in der Prozess- sowie Fertigungsautomatisierung.

Von der OPC Foundation (https://opcfoundation.org/) ist eine mehrteilige Spezifikation zu OPC Unified Architecture veröf fentlicht worden (https://opcfoundation.org/developer- tools/specifications-unified-architecture/ ).

OPC UA ist auch in Kapitel 4 des vom DIN Institut für Normung e.V. herausgegebenen Buches "Industrie 4.0 - Industrielle Kommunikation - Basistechnologie für die Digitalisierung der Industrie" von Markus Weinländer, 2017, VDE Verlag, ISBN 978- 3-8007-4262-2 (VDE Verlag) behandelt.

OPC UA PubSub (Publish/Subscribe) ist eine Erweiterung des bisherigen Client/Server-basierten Ansatzes von OPC UA. Die PubSub-Erweiterung ist in Teil 14 der Spezifikation näher er läutert (OPC Foundation: OPC Unified Architecture, Part 14: PubSub, Release 1.04, 6. Februar 2018, https://opcfoundation .org/developer-tools/specifications- unified-architecture/part-14-pubsub/ ).

Der Standard Part 14 erweitert das bis zu diesem Zeitpunkt bestehende Request/Response-Verfahren um einen Publish- Subscribe-Kommunikationsmechanismus . Beim Publish/Subscribe- Ansatz sendet ein Publisher seine Daten in ein Netzwerk und alle Subscriber können diese Daten empfangen (one-to-many). Des Weiteren wird seit November 2018 in der OPC UA Foundation an einer möglichen Verwendung von OPC UA Pub/Sub in der Feld ebene (OPC UA FLC) gearbeitet (siehe den Artikel „Major Auto mation Industry Players join OPC UA including TSN initiative" unter https://opcfoundation.org/news/press-releases/major- automation-industry-players-join-opc-ua- including-tsn- initiative/ sowie den Artikel „New Initiative: Field Level Communications: OPC Foundation extends OPC UA including TSN down to field level" unter https://opcfoundation .org/news/press-releases/opc-foundation- extends-opc-ua-including-tsn-down-to-f ield-level/). Dabei eignet sich OPC UA PubSub nach Auffassung der Anmelderin ins besondere für die Maschine-zu-Maschine Kommunikation, während der Prozessdatenaustausch zwischen den IO-Geräten und dem Controller bevorzugt wie bisher über Profinet/Profinet TSN erfolgen kann. OPC UA PubSub ist somit eine passende Ergän zung zum Feldbus Profinet (TSN).

In Kapitel 6 des Standards (Part 14) sind die Kommunikations parameter von PubSub genannt und erläutert. Der Part 14 des Standards beschreibt auch die möglichen Transport Protocol Mappings (UDP, Ethernet, AMQP, MQTT) und Message Mappings (UADP, JSON). Kapitel 9 beschreibt das PubSub Konfigurations modell.

Aus „PTCC - TSN Endstation Centralized Configuration Inter face for OPC UA PubSub Systems", IEEE DRAFT, 60802-ADEMAJ- PTCC-0918-V05, IEEE-SA, PISCATAWAY, NJ USA ist ein Verfahren entsprechend dem Oberbegriff von Patentanspruch 1 bekannt. In US 2018/262592 Al ist ein Verfahren zum Konfigurieren eines Teilnehmers beschrieben, bei dem auf einem zum Teilnehmer se paraten Konfigurationsmodul für den Teilnehmer ein virtueller Adressraum vorgesehen wird. Im virtuellen Adressraum mittels Methodenaufrufen wird eine Konfiguration für den Teilnehmer vorgenommen. Die Konfiguration wird durch das Konfigurations- modul in eine Nachricht umsetzt, die an den Teilnehmer über tragen wird. Der Teilnehmer wird dann gemäß dieser Nachricht konfiguriert .

Die Konfiguration von OPC UA PubSub-Kommunikationsteilnehmern kann heute gemäß dem Standard (Part 14) auf zwei Wegen erfol gen.

Einerseits mittels einer Konfigurationsdatei (einem sogenann ten binary-File) dessen Format im Standard spezifiziert ist. Dabei lässt der Standard jedoch offen, wie die Konfigurati onsdatei dem jeweiligen Gerät, das als OPC UA PubSub-Kommuni kationsteilnehmer zu konfigurieren ist, zur Verfügung ge stellt wird. Dies muss somit auf proprietärem Wege erfolgen. Teilnehmer/Geräte, die diese Art der Konfiguration unterstüt zen, erfordern somit spezielle herstellerabhängige Tools und können dann - bezogen auf die Konfiguration - u.U. nicht in teroperabel mit Geräten anderer Hersteller sein. Dieser Kon figurationsansatz ist somit problematisch, insbesondere im Hinblick auf OPC UA FLC.

Eine zweite Möglichkeit besteht darin, auf Methodenaufrufe im OPC UA Server des zu konfigurierenden Teilnehmers zurückzu greifen. Hierfür verbindet sich dann das Konfigurationstool mit dem OPC UA Server des zu konfigurierenden Gerätes/Teil nehmers und führt die entsprechenden Methodenaufrufe z.B. zum Anlegen von DataSetWriterGroups, und DataSetWriter (Publis- her) bzw. DataSetReaderGroups und DataSetReaders (Subscriber) als auch zur Erstellung der DataSets durch (vgl. beispiels weise das Utthunga OPC UA PubSub-Konfigurationstool, welches über die OPC UA Foundation erhältlich ist). Dies erfordert, dass der zu konfigurierende Teilnehmer nicht nur den PubSub- Anteil sondern auch das bestehende Request/Response-Verfahren inkl. des OPC UA Server und Adressraums unterstützt, also ei nen OPC UA Server und Adressraum haben. Da das bestehende Re- quest/Response-Verfahren auf TCP/IP basiert, muss der Teil nehmer/das Gerät somit auch TCP in seinem Netzwerkstack un terstützen. Dies sowie die für den OPC UA Server und das Re- quest/Response-Protokoll (OPC UA Client/Server inklusive OPC UA SecureChannel) erforderlichen Ressourcen führen dazu, dass ein hoher Ressourcenbedarf insbesondere betreffend Flash und RAM besteht. TCP-Verbindungen müssen dabei ebenfalls vom Stack verwaltet werden und sind somit deutlich „teurer" als die Verwendung des verbindungslosen UDP.

Dies widerspricht der Anforderung, dass insbesondere IO-Ge- räte im industriellen Umfeld „klein" (im Sinne der verfügba ren HW-Ressourcen, z.B. Flash und RAM) sowie „günstig" sein sollen. Je mehr HW-Ressourcen erforderlich sind, desto teurer wird ein Gerät in der Regel.

Ausgehend davon besteht eine Aufgabe der vorliegenden Erfin dung darin, eine Möglichkeit zu schaffen, Geräte als OPC UA PubSub Teilnehmer zu konfigurieren, mit der ein gegenüber dem Stand der Technik reduzierten Ressourcenbedarf der Geräte verbunden ist.

Diese Aufgabe wird gelöst durch ein Verfahren zum Konfigurie ren wenigstens eines OPC UA PubSub Teilnehmers in einem ins besondere industriellen Netzwerk, bei dem a) auf einem zu dem wenigstens einen Teilnehmer separaten Konfigurationsmodul für den wenigstens einen Teilnehmer ein virtueller OPC UA PubSub Adressraum vorgesehen wird, b) in dem virtuellen Adressraum mittels Methodenaufrufen eine Konfiguration für den wenigstens einen Teilnehmer vorgenommen und/oder eine für den wenigstens einen Teil nehmer bereits vorhandene Konfiguration geändert wird, c) das Konfigurationsmodul die Konfiguration und/oder Kon figurationsänderung in wenigstens eine PubSub-Nachricht umsetzt, d) die wenigstens eine PubSub-Nachricht an den wenigstens einen Teilnehmer übertragen wird, und e) der wenigstens eine Teilnehmer gemäß der wenigstens ei nen PubSub-Nachricht konfiguriert wird. Erfindungsgemäß erhält das Konfigurationsmodul von dem we nigstens einen Teilnehmer dessen Identifikation und dessen aktuelle Konfiguration als PubSub-Nachricht und sieht in Re aktion darauf in Schritt a) den virtuellen Adressraum für den wenigstens einen Teilnehmer vor. Außerdem tritt das Konfigu rationsmodul einer erste Publishing-Gruppe bei, deren Publis- her es ist und auf der sich der wenigsten eine Teilnehmer subskribiert (subscribe). Zusätzlich tritt das Konfigurati onsmodul einer zweiten Publishing-Gruppe bei, an der er als Subscriber teilnimmt. Darüber hinaus gibt das Konfigurations modul in der ersten Publishing-Gruppe die zweite Publishing- Gruppe bekannt, und der wenigstens eine Teilnehmer subskri biert auf der zweiten Publishing-Gruppe. Des Weiteren sendet der wenigstens eine Teilnehmer seine Identifikation und seine aktuelle Konfiguration als PubSub-Nachricht in die zweite Publishing-Gruppe .

Die Aufgabe wird darüber hinaus gelöst durch ein Automatisie rungssystem zur Durchführung des erfindungsgemäßen Verfah rens. Das erfindungsgemäße Automatisierungssystem umfasst be vorzugt wenigstens ein den wenigstens einen Teilnehmer bil dendes Feldgerät und ein zu dem wenigstens einen Feldgerät separates Konfigurationsmodul, wobei in dem Konfigurationsmo dul ein virtueller Adressraum für das wenigstens eine Feldge rät vorgesehen oder vorsehbar ist, und das Konfigurationsmo dul derart ausgebildet und/oder eingerichtet ist, dass es für den Fall, dass in dem bzw. einem virtuellen Adressraum für das wenigstens eine Feldgerät eine Konfiguration für das we nigstens eine Feldgerät vorgenommen und/oder eine für das we nigstens eine Feldgerät vorhandene Konfiguration geändert wird, die Konfiguration und/oder Konfigurationsänderung in wenigstens eine PubSub-Nachricht umsetzt und die wenigstens eine PubSub-Nachricht an das wenigstens eine Feldgerät über trägt, und das wenigstens eine Feldgerät dazu ausgebildet und/oder eingerichtet ist, sich gemäß der wenigstens einen PubSub-Nachricht zu konfigurieren. Der Grundgedanke der vorliegenden Erfindung ist mit anderen Worten, dass der Adressraum des bzw. im Falle mehrerer des jeweiligen Teilnehmers von dem bzw. dem jeweiligen Teilnehmer an eine insbesondere zentrale Instanz im Netz „ausgelagert" mit anderen Worten virtualisiert wird. Der bzw. die Adress- räume sind dann nicht mehr auf den Teilnehmern selber sondern virtuell in der insbesondere zentralen Instanz im Netz vor handen, konkret dem Konfigurationsmodul, und ein Anwender kann wie gewohnt insbesondere mittels Methodenaufrufen in dem bzw. den virtuellen Adressräumen des oder der einzelnen Teil nehmer die Konfiguration vornehmen.

Bei Änderung einer Konfiguration eines Teilnehmers durch ei nen Anwender im virtuellen Adressraum im Konfigurationsmodul teilt das Konfigurationsmodul dies dem Teilnehmer erfindungs gemäß mittels PubSub mit und der bzw. der jeweilige Teilneh mer übernimmt die neue/geänderte Konfiguration. Das Konfigu rationsmodul stellt praktisch einen zentralen Manager, insbe sondere Konfigurationsmanager für den bzw. die Teilnehmer dar. Das Konfigurationsmodul kann durch Software der Hardware oder durch eine Kombination aus Software und Hardware imple mentiert sein.

Dank der Erfindung ist es nicht mehr zwingend erforderlich, dass der bzw. die Teilnehmer einen OPC UA Adressraum besitzen sowie OPC UA Client/Server-Funktionalität unterstützen. Dadurch kann im Netzwerkstack der Teilnehmer auch auf die Verwendung von TCP verzichtet werden, da OPC UA PubSub z.B. über UDP, Ethernet, TSN oder auch zukünftig 5G übertragen wird bzw. werden kann. Der Ressourcenbedarf (etwa Flash und RAM) des bzw. der Teilnehmer kann dadurch deutlich reduziert werden.

Der bzw. die Teilnehmer, bei dem bzw. denen es sich insbeson dere um IO-Geräte handeln kann, und die in der Regel mit deutlich höheren Stückzahlen im Vergleich zu dem einzelnen zentralen Konfigurationsmodul vorhanden sind, können daher deutlich kostengünstiger werden. Darüber hinaus wird auch der Wartungsaufwand reduziert und eine kleinere Security-An griffsfläche erzielt. Es besteht u.a. weniger Aufwand durch Firmware-Updates. Ein weiterer großer Vorteil ist, dass der bzw. der jeweilige Teilnehmer zum Zeitpunkt der Konfiguration durch den Anwender nicht verfügbar/online sein muss, da das von diesem separate Konfigurationsmodul die Konfiguration im zugehörigen virtuellen Adressraum speichert und diese dem Teilnehmer bei dessen nächstem „Auftauchen" mitgeteilt werden kann. Schließlich ist die erfindungsgemäße Vorgehensweise aus Anwendersicht völlig transparent, d.h. für den Anwender ergibt sich bei der Konfiguration kein Unterschied zu der bisherigen, bekannten Vorgehensweise.

Unter einem virtuellen bzw. virtualisierten Adressraum ist insbesondere ein Adressraum zu verstehen, der nicht bei bzw. auf dem oder im Falle mehrerer dem jeweiligen Teilnehmer liegt, insbesondere nicht auf der Hardware des bzw. des je weiligen Teilnehmers, sondern von dem bzw. dem jeweiligen Teilnehmer separat implementiert ist, insbesondere auf Hard ware, die von der Hardware des bzw. des jeweiligen Teilneh mers separat ist. Der bzw. die virtuellen Adressräume liegen auf bzw. in dem Konfigurationsmodul.

Bei der Konfiguration, die vorgenommen bzw. geändert wird, handelt es sich zweckmäßiger Weise um eine OPC UA PubSub Kon figuration, bevorzugt um eine solche im Sinne des Standards OPC Unified Architecture, Part 14: PubSub. Die Konfiguration bzw. Konfigurationsänderung betrifft bevorzugt wenigstens ei nen der Konfigurationsparameter, die in Kapitel 6 dieses Standards genannt sind.

Bei dem bzw. den virtuellen Adressräumen, die für den bzw. den jeweiligen Teilnehmer auf dem Konfigurationsmodul vorge sehen sind bzw. werden, handelt es sich zweckmäßiger Weise um einen bzw. mehrere OPC UA Adressräume, insbesondere im Sinne des vorgenannten Standards OPC Unified Architecture, Part 14: PubSub. Es kann sich insbesondere (jeweils) um einen Adress raum handeln, wie er in Figur 36 dargestellt ist. Das OPC UA Informationsmodell für die PubSub Konfiguration in Kapitel 9 dieses Standards spezifiziert die Objekte, die in einem OPC UA Adressraum verwendet werden, um eine OPC UA PubSub Konfi guration zu erzeugen bzw. zu ändern. Dass eine Konfiguration in dem auf dem Konfigurationsmodul vorgesehenen virtuellen Namensraum vorgenommen bzw. geändert wird bedeutet insbeson dere, dass wenigstens einer der Konfigurationsparameter, die in Kapitel 6 des Standards OPC Unified Architecture, Part 14: PubSub genannt sind, in dem virtuellen Adressraum gespeichert bzw. geändert wird.

Der bzw. die virtuellen Adressräume, die auf dem Konfigurati onsmodul für den bzw. den jeweiligen Teilnehmer vorgesehen sind, stellen insbesondere ein Informationsmodell für den bzw. den jeweiligen Teilnehmer dar. Es handelt sich insbeson dere um ein Informationsmodell, das die Pub-Sub-Kommunikation und den Variablenhaushalt des bzw. des jeweiligen Teilnehmers betrifft. Beispielsweise kann der (jeweilige) virtuelle Adressraum/das entsprechende Informationsmodell auch die In formation umfassen, welche Variablen Bestandteil des Publis- hedDataSet des (jeweiligen) Teilnehmers sind, und/oder die Abbildung von den DataSetltems einer SubscribedDataSet zu den Variablen im Variablenhaushalt. De bzw. die virtuellen Adressräume, die für den bzw. die Teilnehmer vorgesehen wer den, können entsprechend auch als virtuelle Informations- adressräume, insbesondere virtuelle OP UA Informationsadress- räume aufgefasst bzw. bezeichnet werden.

In weiterer vorteilhafter Ausgestaltung gilt, dass der virtu elle Adressraum des bzw. des jeweiligen Teilnehmers in einem Adressraum des Konfigurationsmoduls vorgesehen wird. Das Kon figurationsmodul hat dann mit anderen Worten einen eigenen Adressraum, innerhalb dem sich der bzw. die virtuellen Adressräume für den bzw. die Teilnehmer befindet bzw. befin den. Besonders bevorzugt gilt hinsichtlich des bzw. des je weiligen virtuellen Adressraums, dass dieser bzw. diese in einem Adressraum des Konfigurationsmoduls „eingeblendet" ist bzw. sind. Unter einer PubSub-Nachricht ist bevorzugt eine Nachricht bzw. Message zu verstehen, wie sie in dem genannten Standard Part 14 in Kapitel 5.3 beschrieben ist (siehe auch Figur 4 in diesem Kapitel).

In weiterer besonders bevorzugter Ausgestaltung gilt, dass in Schritt b) die Konfiguration in dem virtuellen Adressraum des wenigsten einen Teilnehmers mittels Methodenaufrufen vorge nommen und/oder geändert wird. Dies kann durch einen Anwender geschehen, der sich dazu vorbekannter Mittel bedienen kann, beispielsweise des Utthunga PubSub Konfigurationstools. Es sei angemerkt, dass alternativ oder zusätzlich zu dem Utt hunga PubSub Konfigurationstool auch jedes andere Tool ver wendet werden kann, mit dem insbesondere über Methodenaufru fe, bevorzugt Methodenaufrufe im Sinne des Standards OPC Uni- fied Architecture, Part 14: PubSub (Siehe z.B: Seite 114 Fi gur 40 sowie Tabelle 112), Konfigurationen vorgenommen werden können. Das erfindungsgemäße Automatisierungssystem ist in bevorzugter Ausgestaltung entsprechend ausgebildet und/oder eingerichtet .

Als ganz besonders geeignet hat es sich erwiesen, wenn das Konfigurationsmodul durch einen OPC UA Global Discovery Ser ver (OPC UA GDS) gegeben oder als Bestandteil eines solchen ausgebildet ist. Besonders bevorzugt ist das Konfigurations modul durch einen OPC UA Global Discovery Server gemäß der UA Specification Part 12 (Discovery and Global Services) gegeben oder Bestandteil eines solchen. Der OPC UA Global Discovery Server ist dann zweckmäßiger Weise um eine Publisher- und Subscriber-Funktionalität und einen eigenen Server Adressraum erweitert.

In bevorzugter Ausgestaltung erhält das Konfigurationsmodul von dem wenigstens einen Teilnehmer dessen Identifikation und dessen aktuelle Konfiguration bevorzugt, indem der wenigstens eine Teilnehmer die Identifikation und aktuelle Konfiguration als DataSet-MetaData sendet. Dann kennt das Konfigurationsmo- dul den wenigstens einen Teilnehmer und weiß, wie er zu ad ressieren ist.

Das Konfigurationsmodul kann den virtuellen Adressraum für den bzw. den jeweiligen Teilnehmer dann insbesondere in Reak tion darauf in Schritt a) vorsehen bzw. einrichten.

Das Konfigurationsmodul kann aufgrund der empfangenen Identi- fikations-/Konfigurations-Nachrichten sein Informationsmodell im Adressraum aufbauen, um den bzw. die Teilnehmerdort ent sprechend darstellzustellen.

Das Konfigurationsmodul kommuniziert zu dem oder den Teilneh mern bevorzugt ausschließlich über die erste Publishing- Gruppe. Dies insbesondere, indem es Kommandos in Form von Events in diese Publishing-Gruppe sendet.

Entsprechend gilt in weiterer vorteilhafter Ausgestaltung, dass das Konfigurationsmodul die wenigstens eine PubSub- Nachricht, in welche es die Konfiguration und/oder Konfigura tionsänderung umgesetzt hat, in Schritt d) in die erste Pub lishing-Gruppe sendet.

Die PubSub-Nachricht, in welche das Konfigurationsmodul die Konfiguration und/oder Konfigurationsänderung in Schritt d) umsetzt umfasst bevorzugter auch eine Adressierung des we nigstens einen Teilnehmers.

Das Konfigurationsmodul setzt in Schritt c) die Konfiguration und/oder Konfigurationsänderung insbesondere in wenigstens eine PubSub-Event-Nachricht um. So kann gegenüber dem bei PubSub üblicherweise zyklischen Senden eine ereignisbasierte Übertragung realisiert werden.

Den Erhalt der in Schritt d) übertragenen wenigstens einen PubSub-Nachricht bestätigt der wenigstens eine Teilnehmern zweckmäßiger Weise. Die Bestätigung kann dabei erfolgen, in dem der wenigstens eine Teilnehmer die in Schritt d) durchge- führte Konfiguration in der zweiten Publishing-Gruppe publis- hed.

Dass der wenigstens eine Teilnehmer in Schritt e) gemäß der wenigstens einen PubSub-Nachricht konfiguriert wird kann bei spielsweise bereits dadurch erfolgen bzw. umfassen, dass er die erhaltene PubSub-Nachricht bzw. zumindest Teile dieser speichert. Dies insbesondere, wenn diese die Konfiguration, etwa als binary-Datei, umfasst.

Der oder die Teilnehmer können Bestandteil eines industriel len Automatisierungssystem sein.

Bei dem oder bei wenigstens einem der Teilnehmer handelt es sich besonders bevorzugt um ein Feldgerät, insbesondere 10- Gerät. Entsprechend ist das bzw. wenigstens eines der Feldge räte des erfindungsgemäßen Systems durch ein IO-Gerät gege ben. Selbstverständlich kann es auch sein, dass einer oder mehrere Teilnehmer, die über das erfindungsgemäße Verfahren konfiguriert werden, durch eine andere Art von Automatisie rungskomponente, etwa ein HMI-Panle und/oder eine insbesonde re speicherprogrammierbare Steuerung gegeben ist.

Die Geräte bzw. Komponenten des erfindungsgemäßen Automati sierungssystems sind bevorzugt über ein Netzwerk verbunden bzw. verbindbar, wie es aus dem Stand der Technik hinlänglich vorbekannt ist. Das Konfigurationsmodul kann beispielsweise auf einer zu den Feldgeräten separaten Recheneinrichtung im plementiert sein, etwa einem Industrie-PC und/oder auf der Edge und/oder in einer Cloud, der bzw. die bzw. das über ein Netzwerk mit den Feldgeräten verbunden oder verbindbar ist.

Ein weiterer Gegenstand der vorliegenden Erfindung ist ein Computerprogramm umfassend Programmcode-Mittel, die bei der Ausführung des Programms auf wenigstens einem Computer den wenigstens einen Computer veranlassen, die Schritte des er findungsgemäßen Verfahrens durchzuführen. Darüber hinaus betrifft die Erfindung ein computerlesbares Medium, das Instruktionen umfasst, die, wenn sie auf wenigs tens einem Computer ausgeführt werden, den wenigstens einen Computer veranlassen, die Schritte des erfindungsgemäßen Ver fahrens durchzuführen.

Bei dem computerlesbaren Medium kann es sich beispielsweise um eine CD-ROM oder DVD oder einen USB oder Flash Speicher handeln. Es sei angemerkt, dass unter einem computerlesbaren Medium nicht ausschließlich ein körperliches Medium zu ver stehen sein soll, sondern ein solches beispielswiese auch in Form eines Datenstromes und/oder eines Signals, welches einen Datenstrom repräsentiert, vorliegen kann.

Weitere Merkmale und Vorteile der vorliegenden Erfindung wer den anhand der nachfolgenden Beschreibung erfindungsgemäßer Ausführungsformen unter Bezugnahme auf die beiliegende Zeich nung deutlich. Darin zeigt die

Figur 1 eine rein schematische Darstellung eines Ausfüh rungsbeispiels eines erfindungsgemäßen Automatisie rungssystems; und

Figur 2 ein konventionelles Automatisierungssystem.

Die Figur 1 zeigt ein Ausführungsbeispiel eines erfindungsge mäßen Automatisierungssystems 1 in stark vereinfachter, rein schematischer Darstellung.

Dieses umfasst eine Mehrzahl von Komponenten, u.a. mehrere Feldgeräte, von denen zumindest einige durch IO-Geräte gege ben sind, und speicherprogrammierbare Steuerungen. In der Fi gur sind von der Vielzahl der Komponenten beispielshaft zwei IO-Geräte 2 sowie eine speicherprogrammierbare Steuerung 3 dargestellt. Über die zwischen den beiden IO-Geräten 2 ist angedeutet, dass natürlich mehr IO-Geräte 2 vorhanden sein können bzw. vorhanden sind. Die Steuerung 3 und IO-Ge- räte 2 kommen, wie aus dem Stand der Technik hinlänglich vor- bekannt, zum Einsatz, um einen nicht weiter dargestellten technischen Prozess zu überwachen und zu steuern. Selbstver ständlich ist es in ebenfalls an sich vorbekannter Weise mög lich, dass auch mehr als eine Steuerung 3 und/oder noch ande re Komponenten, etwa HMI-Panels und/oder dergleichen vorgese hen sind.

Die Komponenten des Automatisierungssystems 1 sind zum Daten austausch über ein Netzwerk 4 miteinander verbunden. Das Netzwerk 4 umfasst mehrere Switche 5, von denen in der Figur einer beispielshaft gezeigt ist.

Das Automatisierungssystem 1 umfasst ferner ein Konfigurati onsmodul 6, welches bei dem dargestellten Ausführungsbeispiel durch einen OPC UA Global Discovery Server (OPC UA GDS) gege ben ist, der auf einem von den weiteren Komponenten des Sys tems 1 separaten Rechner, vorliegend Industrie-PC implemen tiert ist, welcher ebenfalls an dem Netzwerk 4 teilnimmt. Der OPC UA Global Discovery Server ist dabei um eine Publisher- und Subscriber-Funktionalität, die durch eine entsprechende funktionale Einheit 7 Software-basiert implementiert ist, und einen eigenen Server Adressraum 8 erweitert.

Die IO-Geräte 2 und die Steuerung 3 umfassen auch eine solche funktionale Einheit 7, über welche die PubSub-Funktion bei diesen implementiert ist. Die funktionalen Einheiten 7 der IO-Geräte 2 sind vorliegend ebenfalls Software-implementiert.

Das Konfigurationsmodul 6 dient als zentraler Manager, der für die OPC UA PubSub Kommunikationskonfiguration der IO- Geräte 2 und bei dem dargestellten Beispiel auch der Steue rung 3 zum Einsatz kommt.

Die Konfiguration erfolgt unter Durchführung des im Folgenden beschriebenen Ausführungsbeispiels des erfindungsgemäßen Ver fahrens. In einem ersten Schritt tritt das Konfigurationsmodul 6 zu nächst eine ersten Publishing-Gruppe bei (join), deren Publi- sher es ist. Auf dieser subscriben sich die Teilnehmer bil denden IO-Geräte 2 und die Steuerung 3.

Das Konfigurationsmodul 6 kann dem bzw. den Teilnehmern 2, 3 beispielsweise durch Verwendung einer well-known Multicast- Gruppe mitgeteilt werden bzw. vorab mitgeteilt worden sein.

Das Konfigurationsmodul 6 tritt dann noch einer zweiten Pub lishing-Gruppe bei (join), an der es als Subscriber teil nimmt.

Anschließend gibt das Konfigurationsmodul 6 in der ersten Publishing-Gruppe die zweite Publishing-Gruppe bekannt, auf die sich die IO-Geräte 2 und die Steuerung 3 subscriben. Hierdurch gibt sich das Konfigurationsmodul 6 als zuständig für die IO-Geräte 2 und die Steuerung 3 bekannt.

Das Konfigurationsmodul 6 kommuniziert zu den IO-Geräten 2 bzw. der Steuerung 3 ausschließlich über die erste Publi shing-Gruppe. Dies insbesondere, indem es Kommandos in Form von Events in diese Publishing-Gruppe sendet.

Das Konfigurationsmodul 6 erhält von dem jeweiligen IO-Gerät

2 und der Steuerung 3 jeweils deren Identifikation und deren aktuelle Konfiguration, indem das jeweilige IO-Gerät 2 bzw. die Steuerung 3 die Identifikation und aktuelle Konfiguration als PubSub-Nachricht, vorliegend als DataSet-MetaData in die zweite Publishing-Gruppe sendet. Dann kennt das Konfigurati onsmodul 6 den jeweiligen Teilnehmer 2, 3 und weiß, wie er zu adressieren ist.

Das Konfigurationsmodul 6 sieht dann für jeden Teilnehmer 2,

3 deren Identifikation und aktuelle Konfiguration es erhalten hat, einen virtuellen Adressraum 9 innerhalb seines Server Adressraumes 8 vor. Das Konfigurationsmodul 6 hat dann einen Server Adressraum 8, der virtuelle Adressräume 9 für alle Teilnehmer umfasst, für die das Konfigurationsmodul 6 zustän dig ist.

Das Konfigurationsmodul 6 baut mit anderen Worten aufgrund der empfangenen Identifikations-/Konfigurations-Nachrichten der Teilnehmer 2, 3 sein Informationsmodell im Adressraum auf, um den bzw. die Teilnehmer dort entsprechend darstellzu- stellen. Der jeweilige virtuelle Adressraum 9 umfasst bevor zugt den Variablenhaushalt des jeweiligen Teilnehmers 2, 3 (z.B. Published DataSet).

In der Figur der Server Adressraum 8 und darin beispielhaft die virtuellen Adressräume 9 für die beiden IO-Geräte 2 und die Steuerung 3 schematisch innerhalb des Konfigurationsmo duls 6 angedeutet. Auch hier ist über angedeutet, dass mehr virtuelle Adressräume 9 für mehr Teilnehmer 2, 3 vorge sehen sein bzw. werden können.

Anschließend kann ein Anwender 10 in dem virtuellen Adress raum 9 des jeweiligen Teilnehmers 2, 3 eine Konfiguration für diesen wie gewohnt mittels Methodenaufrufen vornehmen und/oder eine für den jeweiligen Teilnehmer 2, 3 bereits vor handene Konfiguration wie gewohnt mittels Methodenaufrufen ändern, etwa mittels eines OPC UA Clients und beispielsweise unter Verwendung des Utthunga PubSub Konfigurationstools, welches auf einem PC 11 installiert sein kann.

Dafür kann das Konfigurationsmodul 6 in an sich bekannter Weise einen OPC UA Server 12 aufweisen, und bevorzugt das vorbekannte Request/Response-Verfahren genutzt werden.

Es sei angemerkt, dass in der Figur durch Pfeile mit gestri chelter Linie die Methodenaufrufe und durch Pfeile mit strichpunktierter Linie die PubSub-Kommunikation/der Daten fluss betreffend die Konfigurationsinfo andeutet ist.

Wird in einem virtuellen Namensraum 9 eine Konfiguration für einen Teilnehmer 2, 3 vorgesehen bzw. geändert (z.B. eine neue WriterGroup erzeugt), setzt das Konfigurationsmodul 6 die Konfiguration und/oder Konfigurationsänderung in eine PubSub-Nachricht, vorliegend eine PubSub-Event-Nachricht um. Die Umsetzung der Konfiguration bzw. Konfigurationsänderung erfolgt bei dem dargestellten Ausführungsbeispiel mittels ei ner PubSub-Einheit 7 des Konfigurationsmoduls 6.

Die PubSub-Event-Nachricht wird anschließend an den bzw. den jeweiligen Teilnehmer 2, 3 übertragen. Hierzu wird die PubSub-Event-Nachricht von dem Konfigurationsmodul 6 in die erste Publishing-Gruppe gesendet. Die PubSub-Event-Nachricht enthält dabei in den Nutzdaten zweckmäßiger Weise auch die Adressierung des angesprochenen Gerätes 2, 3. Sie kann ferner wenigstens ein Kommando umfassen.

Der bzw. der jeweilige Teilnehmer 2, 3 konfiguriert sich dann gemäß der PubSub-Event-Nachricht. Dies kann beispielsweise bereits dadurch erfolgen, dass er die erhaltene PubSub-Event- Nachricht bzw. zumindest Teile dieser speichert. Bevorzugt ist vorgesehen, dass der bzw. der jeweilige Teilnehmer 2, 3 weiß, wie auf wenigstens ein enthaltenes Kommando reagieren muss, beispielsweise durch Speicherung.

Ferner bestätigt der jeweilige Teilnehmer 2, 3 zweckmäßiger weise den Erhalt der übertragenen PubSub-Event-Nachricht. Die Bestätigung kann z.B. erfolgen, indem der jeweilige Teilneh mer 2, 3 die durchgeführte Konfiguration in der zweiten Pub lishing-Gruppe published. Insbesondere kann die Bestätigung gemäß Standard Part 14 durch Publishen der aktuellen Konfig als DataSetMetaData erfolgen.

Es sei angemerkt, dass der vorstehend beispielhaft für die IO-Geräte 2 und die Steuerung 3 als Teilnehmer beschriebene Ablauf gleichermaßen für etwaige weitere Komponenten erfolgen kann, sowohl weitere IO-Geräte 2 und Steuerungen 3 als auch Komponenten anderer Art. Im Anschluss an die erfindungsgemäß durchgeführte Konfigura tion kann insbesondere die Maschine-zu-Maschine Kommunikation über OPC UA PubSub erfolgen, während der Prozessdatenaus tausch zwischen den IO-Geräten 2 und der Steuerung 3 bevor zugt wie bisher über Profinet/Profinet TSN erfolgen kann. OPC UA PubSub ist somit eine passende Ergänzung zum Feldbus Pro finet (TSN).

Dank der beschriebenen Vorgehensweise ist es dabei nicht mehr zwingend erforderlich, dass der bzw. die Teilnehmer 2, 3 ei nen lokal auf ihnen vorgesehenen OPC UA Adressraum 13 besit zen sowie OPC UA Client/Server-Funktionalität 14 unterstüt zen, wie es bei den aus dem Stand der Technik vorbekannten Automatisierungssystemen 1 der Fall ist. Ein solches ist zum Vergleich beispielhaft und rein schematisch in Figur 2 darge stellt. In Analogie zu Figur 1 sind von den Komponenten bei spielhaft zwei IO-Geräte 2 und eine Steuerung 3 gezeigt.

Aufgrund der erfindungsgemäßen Vorgehensweise kann im Netz werkstack der Teilnehmer 2, 3 auf die Verwendung von TCP ver zichtet werden, da OPC UA PubSub z.B. über UDP, Ethernet, TSN bzw. zukünftig 5G übertragen wird bzw. werden kann. Der Res sourcenbedarf (etwa Flash und RAM) der Teilnehmer 2, 3 kann dadurch deutlich reduziert werden. Die Teilnehmer 2, 3 können deutlich kostengünstiger werden. Ganz besonders vorteilhaft ist die erfindungsgemäße Vorgehensweise für Komponenten, die in der Regel in höheren Stückzahlen erforderlich sind, wie Feldgeräte, etwa in Form von IO-Geräten 2.