DE102019219031A1 - Übertragungsverfahren - Google Patents

Abstract

Die Erfindung betrifft ein Verfahren der Kommunikation von Maschinensteuerungsdaten eines mechatronischen Systems (2) in einem Netzwerk (3) mit mindestens einer Maschinensteuerung (4), mittels eines Datenaustauschstandards (21), der ein Publish-/Subscribe-Kommunikationsmodell unterstützt, bei dem Publisher (Pn) und Subscriber (Sn) entkoppelt sind; wobei die Maschinensteuerung (4) im Rahmen des Publish-/Subscribe-Kommunikationsmodells von einem Remote-Netzwerkteilnehmer (7) die Maschinensteuerungsdaten bezieht, bei dem der Bezug der Steuerungsdaten mittels einer Publish-/Subscribe-Datenübertragung von Überwachungsinformationen überwacht wird und die Überwachung mittels einheitlich verwendeter, kompatibler, jeweils sowohl für die Überwachungsfunktion als auch für die Publish-/Subscribe-Datenübertragung charakteristischer Objekte (On) erfolgt.

Description

• Die Erfindung betrifft ein Verfahren der Kommunikation von Maschinensteuerungsdaten eines mechatronischen Systems in einem Netzwerk mit mindestens einer Maschinensteuerung; die Kommunikation erfolgt mittels eines Datenaustauschstandards. Dieser unterstützt ein Publish-/Subscribe-Kommunikationsmodell, bei dem Publisher und Subscriber entkoppelt sind. Es ist unter anderem Ziel des Kommunikationsverfahrens, dass die Maschinensteuerung im Rahmen des Publish-/Subscribe-Kommunikationsmodells von einem Remote-Netzwerkteilnehmer die Maschinensteuerungsdaten bezieht.
• Ein solches Verfahren ist in der nicht vorveröffentlichten, deutschen Patentanmeldung DE102018216111.9 beschrieben. Dort ist vorgesehen, dass die Maschinensteuerung zumindest als Publisher fungieren und somit Steuerungsdaten aus dem Netzwerk, insbesondere von dem Remote-Netzwerkteilnehmer, empfangen kann. Ein solches Verfahren ist schlank und flexibel, aber aufgrund der standardgemäß entkoppelten Kommunikation im Hinblick auf die Zuverlässigkeit und Deterministik der Kommunikation von Daten eingeschränkt.
• Im Folgenden wird eine vereinfachte Zusammenfassung dargestellt, um ein grundlegendes Verständnis einiger der hierin beschriebenen Aspekte zu vermitteln. Dabei soll der Begriff „oder“ ein inklusives „oder“ und nicht ein exklusives „oder“ bedeuten. Das heißt, wenn nicht anders angegeben oder aus dem Kontext klar ersichtlich, soll der Ausdruck „X oder Y“ folgende, mögliche Bedeutungen haben: nur X, nicht Y; nur Y, nicht X; sowohl X als auch Y. Darüber hinaus ist der unbestimmte Artikel „ein (-er, -es, -e)“ hierin im Allgemeinen so auszulegen, dass er „ein(-er, es, e) oder mehrere“ bedeutet, sofern dies nicht explizit anders angegeben oder aus dem Kontext klar ersichtlich anders auszulegen ist. Sollte ein bestimmtes Merkmal hierin nur in Bezug auf eine bestimmte Ausgestaltung offenbart sein, ist dieses nicht auf die bestimmte Ausgestaltung eingeschränkt; vielmehr ist auch die Kombination dieses Merkmals mit einem oder mehreren anderen Merkmalen der anderen Ausgestaltungen hierin umfasst.
• Es ist Aufgabe der vorliegenden Erfindung, ein Verfahren der eingangs genannten Art zuverlässiger und in hohem Maße deterministisch, insbesondere für (Echtzeit-) Anwendungen der Industrieautomatisierung auszugestalten. Dabei ist es insbesondere Aufgabe, ein hohes Maß an Interoperabilität von Komponenten - insbesondere Komponenten unterschiedlicher Hersteller - zu erreichen.
• Diese Aufgabe wird jeweils teilweise oder vollständig gelöst durch ein Verfahren nach Anspruch 1, eine Maschinensteuerung oder Rechnereinrichtung nach Anspruch 11 und ein Computerprogrammprodukt nach Anspruch 12.
• Die Erfindung bietet den Vorteil, dass - vor allem in einer Netzwerk-Infrastruktur, die auch Automatisierungskomponenten umfasst - sowohl eine zuverlässigere (insbesondere fehlersicherere, robustere und ausfallsichere) und überwachte Kommunikation als auch eine Synchronisierung (etwa eine aufeinander bezogene oder voneinander abhängige Bewegung von Bewegungsbahnen verschiedener Netzwerkteilnehmer) einfach erfolgen kann, wobei die Schlankheit und Flexibilität einer Publish-/Subscribe-Infrastruktur beibehalten wird. Die Erfindung erreicht diese und andere Vorteile unter Wahrung etablierter, in der Industrie verwendeter Mechanismen des Publish-/Subscribe-Kommunikationsmodells, so dass ein hohes Maß an Kompatibilität und Interoperabilität von entsprechenden Komponenten, insbesondere von Komponenten verschiedener Hersteller, erreicht wird.
• Die Erfindung hat erkannt, dass mittels einer Publish-/Subscribe-Datenübertragung einerseits eine Überwachung der Kommunikation der Steuerungsdaten auf einfache und schlanke Weise realisiert werden kann; zum anderen kann weitestgehend auf im Rahmen der Publish-/Subscribe-Datenübertragung etablierte und durchgesetzte Standards zurückgegriffen werden, die lediglich geringfügig transformiert werden müssen, um einen Quantensprung bei der Zuverlässigkeit und Deterministik der Kommunikation von Maschinensteuerungsdaten zu erreichen.
• Dazu wird der Bezug der Steuerungsdaten mittels einer Publish-/Subscribe-Datenübertragung von Überwachungsinformationen überwacht. Dies erfolgt gänzlich im Rahmen der vorgesehenen und im Datenaustauschstandard normierten Publish-/Subscribe-Kommunikationsarchitektur. Beispielsweise kann dafür die Maschinensteuerung, die die Steuerungsdaten bezieht, gleichzeitig zu dieser Subscriber-Funktion, in der sie die Steuerungsdaten bezieht, als Publisher konfiguriert sein, der die Überwachungsinformationen, die sich auf den Bezugsstatus der Steuerungsdaten beziehen können, in das Netzwerk überträgt. Die Überwachungsinformationen sind dabei bevorzugt standardisierte oder auch codierte Daten, sich auf die Überwachung des ordnungsgemäßen Bezuges der Steuerungsdaten beziehen. Davon können beispielsweise Statusdaten, online-/offline-Daten oder Betriebsdaten sowie Quittierungsdaten oder dergleichen umfasst sein. Gleichzeitig können davon auch Daten umfasst sein, die einen Fehlerstatus oder ordnungsgemäßen Status repräsentieren.
• Dew Weiteren erfolgt eine Übertragung oder deren Konfiguration im Rahmen einer Publish-/Subscribe-Kommunikationsarchitektur unter Verwendung hierfür charakteristischer Objekte, wobei Objekte dabei insbesondere informationstechnische Objekte sein können. Dann sind die erfindungsgemäßen Objekte Ausprägungen (Instanzen) eines bestimmten Objekttyps, die während der Laufzeit erfindungsgemäß erzeugt werden. Der vorbestimmte Datentyp (oder die vorbestimmte Klasse) sind dabei beispielsweise im Rahmen des Datenaustauschstandards vorgegeben und ggf. standardisiert. Ein solches, informationstechnisches Objekt im engeren Sinne hat einen Zustand, der durch Eigenschaften und Beziehungen zu anderen Objekten vorgegeben wird. Darauf wird weiter unten noch näher eingegangen. Das Verhalten solcher, informationstechnischer Objekte kann durch Methoden (vorzugsweise Methoden des Datenaustauschstandards) festgelegt sein. Dadurch wird eine realistische und zugleich informationstechnisch einfach realisierbare Verkörperung einer Publish-/Subscribe-Kommunikationsarchitektur erreicht. Dabei können Variablen, Eigenschaften oder Referenzen sowie Zusammenhänge innerhalb der Publish-/Subscribe-Kommunikationsarchitektur als informationstechnische Objekte repräsentiert sein, die mit Eigenschaften und/oder Komponenten eines Publish-/Subscribe-Kommunikationsmodells korrespondieren. Solche informationstechnischen Objekte haben dann etwa Eigenschaften und/oder Komponenten des Publish-/Subscribe-Kommunikationsmodells zum Gegenstand. Beispielsweise kann eine Publish-/Subscribe-Verbindung ein Objekttyp sein, der die Charakteristik der Publish-/Subscribe-Verbindung repräsentiert, beispielsweise - im Sinne der erfindungsgemäßen Ausführung - ob es sich um eine einfache oder eine überwachte Verbindung bzw. Datenübertragung handelt.
• Erfindungsgemäß können Objekte allerdings auch Objekte im weiteren Sinne sein; dann sind damit etwa Variablen, Eigenschaften, Referenzen oder Beziehungen untereinander gemeint, die erfindungsgemäß vorbestimmt sein können. Insbesondere können solche Objekte auch Arten oder Klassen von Typdefinitionen oder Arten oder Klassen von Beziehungs- bzw.
• Referenztyp-Definitionen sein. Allgemein ausgedrückt können Objekte informationstechnische Verkörperungen, Umsetzungen oder Abbildungen von technischen Eigenschaften oder Merkmalen der jeweils bezogenen Modelle, Architekturen, Topologien oder Kommunikations-Infrastrukturen sein, wie etwa darauf bezogene Variablen, Referenzen, Prozeduren oder Module.
• Ein hohes Maß an Interoperabilität und Kompatibilität, auch zwischen Komponenten unterschiedlicher Hersteller, wird erfindungsgemäß dadurch erreicht, dass einerseits einheitliche und untereinander kompatible Objekte verwendet werden. Dann ist ein Objekt - beispielsweise im Rahmen des Datenaustauschstandards - unter mehreren oder allen Netzwerkteilnehmern des Netzwerks oder eines Netzwerksegmentes gleichartig vorbestimmt; solch ein Objekt kann etwa im Stack des Datenaustauschstandards normiert sein. Jedenfalls sind in den Netzwerkteilnehmern, die das erfindungsgemäße Verfahren implementieren, solche gleichartig definierten Objekte vorbekannt. Darüber hinaus sind die Objekte untereinander kompatibel, also insbesondere derart vorbestimmt, dass sie zwischen verschiedenen Netzwerkteilnehmern unter Wahrung ihrer Eigenschaften und Funktionalitäten austauschbar sind.
• Ein wesentlicher Aspekt, der aufgrund der Erfindung erstmalig technisch gelöst ist, besteht andererseits darin, dass die verwendeten Objekte (insbesondere simultan) sowohl für die erfindungsgemäße Überwachungsfunktion als auch für die (im Datenaustauschstandard normierte) Publish-/Subscribe-Datenübertragung gleichermaßen charakteristisch sind. Die verwendeten Objekte umfassen eine Integration von Überwachungseigenschaften mit Publish-/Subscribe-Eigenschaften. Sie können etwa von Publish-/Subscribe-Objekten abgeleitet sein oder auf diesen basieren und um für die Überwachungsfunktion charakteristische Eigenschaften ergänzt werden oder umgekehrt. Beispielsweise kann ein Objekt eine Eigenschaft des zugrundeliegenden Publish-/Subscribe-Verbindungstyps modellieren und dazu angeben, ob es sich bei dem spezifischen Verbindungstyp um eine überwachte oder nicht überwachte (einfache) Publish-/Subscribe-Verbindung handelt oder wie die Überwachung der entsprechenden Verbindung technisch erfolgt.
• Die Erfindung hat außerdem erkannt, dass einerseits bei einem Publish-/Subscribe-Kommunikationsmodell durch die im wesentlichen entkoppelte Kommunikation eine - zum Beispiel bei Automatisierungsaufgaben häufig erforderliche - Rückkopplung bzw. Kommunikation in die Rückrichtung bezüglich der vom Remote-Publisher empfangenen Steuerungsdaten grundsätzlich nicht erfolgt und schließt diese bislang nicht berücksichtigte Lücke. Zusätzlich wahrt die Erfindung die Schlankheit und Flexibilität sowie auch eine verlässliche oder deterministische Kommunikation mittels hoher Quality of Service bis hin zur Echtzeit dadurch, dass die Publish-/Subscribe-Architektur beibehalten und nicht grundsätzlich durchbrochen wird. Trotzdem erreicht es die Erfindung, die genannte Publish-/Subscribe-Architektur für eine deterministische Kommunikation, insbesondere für eine Industrie-Kommunikation von Maschinensteuerungen vor allem in Echtzeit zu befähigen.
• Mit der Erfindung kann eine (standardmäßig) entkoppelte Publish-/Subscribe-Verbindung überwacht werden. Das heißt insbesondere, dass ein Publisher weiß, ob seine Nachrichten bei den Subscribern ankommen und dass bei Unregelmäßigkeiten darauf reagiert werden kann. Solche Mechanismen werden durch die Objekte implementiert.
• Das beschriebene Verfahren ist in jeder Richtung auf alle Netzwerkteilnehmer anwendbar, die das Publish-/Subscribe-Kommunikationsmodell unterstützen. Dabei können die meisten oder alle Netzwerkteilnehmer Maschinensteuerungen sein; es kann sich aber auch um ein gemischtes Netzwerk handeln aus Maschinensteuerungen und anderen Netzwerkteilnehmern, beispielsweise Industrie-PCs oder Office-PCs. Um die Kommunikationsanforderungen bedarfsgemäß auf einen bestimmten Netzwerkbereich flexibel abstimmen zu können, können auch separate Netzwerksegmente gebildet werden, die jeweils segmentweise das erfindungsgemäße Verfahren umsetzen. Dann kann beispielsweise ein Netzwerksegment mit einer Echtzeit-Kommunikations-Konfiguration vorgesehen sein, in dem überwiegend oder vollständig Maschinensteuerungen (oder äquivalente Geräte der Industrieautomation) miteinander kommunizieren. Mehrere solcher Netzwerksegmente können auch untereinander kommunizieren. Dann kann beispielsweise in einer Feldebene ein Netzwerksegment (insbesondere mittels des IEEE 802.1-Netzwerkstandards TSN - Time Sensitive Networking) aus Maschinensteuerungen oder ähnlichem betrieben werden, in dem im Wesentlichen durch die Erfindung Echtzeit-Kommunikation gewährleistet werden kann mit einer Quality of Service (Dienstgüte) entsprechend dem oben genannten Netzwerkstandard TSN. In dem genannten Beispiel kann die Feldebene mit einem Netzwerksegment einer darüber angeordneten Leitungsebene oder Leitsteuerungsebene und/oder Administrations- oder Logistikebene kommunizieren. Dann kann das Feldebenen-Netzwerksegment, das im Wesentlichen auf Geräten der Industrieautomatisierung basiert, über die Kopplung der Netzwerksegmente mit den darüber liegenden Ebenen kommunizieren, wobei vorzugsweise der gleiche Datenaustauschstandard - und auch die gleichen Objekte, Überwachungseigenschaften oder Überwachungsbeziehungen - bis zu einer bestimmten Ebene, zum Beispiel der Leitungsebene oder der Logistikebene oder durchgängig auf allen Ebenen verwendet oder unterstützt wird. Dadurch ist eine extrem hochwertige Kommunikation erreichbar, die gleichzeitig mit einem hohen Maß an Standardisierung, Interoperabilität und Vereinfachung der entsprechenden Infrastruktur einhergeht.
• Sowohl die erfindungsgemäße Maschinensteuerung als auch andere oder alle Netzwerkteilnehmer, mit denen erfindungsgemäß kommuniziert wird, können konform zu einem Datenaustauschstandard betrieben werden. Solch ein erfindungsgemäßer Datenaustauschstandard kann ein industrielles Kommunikationsprotokoll, beispielsweise ein Maschine-zu-Maschine-Kommunikationsprotokoll, wie OPC-UA sein. Dabei steht OPC-UA für Open Platform Communication - Unified Architecture. Mittels der OPC-UA wird eine Vernetzung verschiedenster Komponentenhersteller herstellerunabhängig ermöglicht. OPC-UA erweitert OPC um wesentliche Eigenschaften, wie beispielsweise die Übertragung von Semantikinformationen und die erweiterten Möglichkeiten zum Aufrufen von Methoden, und ermöglicht einen standardisierten und herstellerübergreifenden Datenaustausch zwischen verschiedenen Komponenten, und zwar unabhängig von Programmiersprache und Betriebssystem. OPC-UA verbindet über ein standardisiertes Kommunikationsprotokoll und über standardisierte Schnittstellen sowie Funktionalitäten die Geräte verschiedener Ebenen der Automatisierungspyramide. Vor allem kann OPC-UA dem Austausch von Daten aus der Feldebene mit darüber liegenden Ebenen der Automatisierungspyramide dienen. So können über OPC-UA beispielsweise Daten aus einem Echtzeit-Bereich der Feldebene, in welchem die Feldgeräte über einen echtzeitfähigen Feldbus kommunizieren, zu einer Managementebene oder einer Steuerungsebene der Fabrikautomation übertragen werden, in der Planung, Ablaufsteuerung und Logistikprozesse erfolgen. Beispielsweise ermöglicht die OPC-UA-Technologie eine einheitliche Vernetzung von Maschinensteuerungen, wie etwa von CNC-Steuerungen, Bewegungssteuerungen (Motion) für z.B. Verpackungsmaschinen oder Logiksteuerungen wie z.B. speicherprogrammierbare Steuerungen (SPS), mit den darüber liegenden Steuerungs- und Managementebenen. Wenn hierin Maschinensteuerung oder SPS genannt wird, ist dies stets als austauschbar mit allen vorgenannten Steuerungen anzusehen und umgekehrt.
• Bevorzugt kommt auch die Verwendung von OPC-UA-TSN (Time Sensitive Networking) für die Erfindung in Betracht, da dadurch im Hinblick auf die Industrieautomation nützliche Verbesserungen der Echtzeitfähigkeit mittels der Erfindung erreicht werden können.
• Die Bezugnahmen hierin auf OPC-UA gelten auch für andere Datenaustauschstandards, die für die Erfindung verwendet werden können. Hierin wird allerdings beispielhaft im Wesentlichen auf OPC-UA Bezug genommen, wobei OPC-UA in diesem Sinne austauschbar mit funktionsgleichen oder mit ähnlichen Datenaustauschstandards oder auch mit Kommunikationsprotokollen und -standards sein soll und umgekehrt.
• Die Maschinensteuerung kann ein mechatronisches System steuern. Das mechatronische System weist einerseits mechatronische, das bedeutet beispielsweise elektrische, elektronische, hydraulische, mechanische, pneumatische oder aus diesen Prinzipien kombinierte oder anderweitige Komponenten auf, die in einem Systemverbund zusammengefasst sind und als solcher als eine zusammengefasste, mechatronische Einheit oder mechatronische Maschine fungieren. Dies kann beispielsweise eine Werkzeugmaschine sein, in der mehrere Elektromotoren die Achsen der Werkzeugmaschine antreiben, oder ein Maschinenverbund für eine Fertigungslinie. Komponenten des mechatronischen Systems werden vorzugsweise durch eine oder mehrere Maschinensteuerungen koordiniert, gegebenenfalls synchronisiert und als Systemverbund gesteuert. Dabei ist die Maschinensteuerung beispielsweise eine Logiksteuerung, wie zum Beispiel eine speicherprogrammierbare Steuerung (SPS), eine Bewegungssteuerung, wie beispielsweise eine CNC (Computer Numeric Control) oder - generell ausgedrückt - eine übergeordnete Systemsteuerung, die auch aus mehreren, unterschiedlichen Steuerungsplattformen und - Architekturen zusammengesetzt werden kann. Die Maschinensteuerung kann dabei eine integrierte Maschinensteuerung sein, die auch eine Echtzeitkomponente, in Software oder Hardware, und eine übergeordnete Logiksteuerung, Prozesssteuerung oder allgemeine Steuerung in einer Einheit, vorzugsweise in einem Gehäuse, integriert.
• Eine solche Maschinensteuerung kann eine separate und dedizierte Hardware sein, also etwa eine elektronische Komponente des mechatronischen Systems, die als eine physikalische Maschinensteuerung ausgestaltet ist. Es kann sich aber auch um eine Embedded-Steuerung handeln oder um eine virtuelle, beispielsweise auf einem Industrie-PC emulierte bzw. virtualisierte, Steuerung handeln. Eine Steuerung kann schließlich auch als Software-Applikation auf einem (Industrie-) PC realisiert sein.
• Erfindungsgemäß ist eine Maschinensteuerung als ein Netzwerkteilnehmer in das Netzwerk zum Datenaustausch eingebunden. Die Maschinensteuerung empfängt, sendet, bearbeitet, verwaltet, koordiniert, erzeugt oder generiert Maschinensteuerungsdaten. Solche Daten sind beispielsweise auf das mechatronische System bezogene oder von dem mechatronischen System stammende Daten. Diese Steuerungsdaten werden von der Maschinensteuerung kommuniziert, also gesendet und/oder empfangen. Dies ist für ein mechatronisches System eine wesentliche Voraussetzung des reibungslosen Funktionsablaufs. Hier setzt die Erfindung an, indem Objekte, Überwachungseigenschaften oder Überwachungsbeziehungen einheitlich verwendet und gleichzeitig auf die Überwachung und die Publish-/Subscribe-Systemarchitektur bezogen sind. Es können durch den Datenaustauschstandard verschiedene Übertragungsarchitekturen bereitgestellt werden, die die Erfindung anwendungsspezifisch nutzt. Vorliegend wird für die Übertragung eine Publish/Subscribe-Architektur des Datenaustauschstandards verwendet. Charakteristisch für eine solche Publish/Subscribe-Architektur ist es, dass der Publisher den oder die Subscriber nicht individuell adressiert und somit nicht unbedingt „kennt“.
• Erfindungsgemäß können Maschinensteuerungsdaten (der Einfachheit halber hierin auch verkürzt als „Steuerungsdaten“ bezeichnet) mit allen Vorzügen einer Publish/Subscribe-Architektur bereitgestellt werden (beispielsweise Steuerungsdaten gleichzeitig für eine Mehrzahl von Subscribern und/oder zyklisch zu verteilen). Dazu kann die Maschinensteuerung als mit dem Datenaustauschstandard konformer Subscriber oder Publisher unter Zuhilfenahme von erfindungsgemäßen Objekten konfiguriert sein. Die Übertragung kann dabei in Form von mit dem Datenaustauschstandard konformen Netzwerknachrichten erfolgen, die jeweils für eine flexible Anzahl von Subscribern vorgesehen sind, wobei ein Netzwerkteilnehmer - allgemein gesagt - nach Maßgabe des Nachrichten-Identifikators seine zu beziehende Nachricht selektiv erhält oder auswählt und/oder den ihn interessierenden Datensatz anhand des Nachrichten-Identifikators aus einer Netzwerknachricht selektiv entnimmt.
• In der genannten Publish-/Subscribe-Architektur nimmt ein Publisher die Übertragung in Form von mit dem Datenaustauschstandard konformen Netzwerknachrichten vor. Dabei werden die Daten mit Methoden oder Funktionalitäten, die in dem Datenaustauschstandard standardisiert sind, gekennzeichnet und übertragen. Solche Nachrichten sind jeweils für eine flexible Anzahl von Subscribern vorgesehen.
• Der Subscriber kann nach Maßgabe eines Nachrichten-Identifikators seine zu beziehende Nachricht selektiv erhalten (z.B. bei Verwendung einer Publish/Subscribe-Architektur mit Unicast-Adressierung, siehe unten). Alternativ oder zusätzlich kann der Subscriber den ihn interessierenden Datensatz anhand eines Nachrichten-Identifikators selektiv aus einer so identifizierten oder empfangenen Netzwerknachricht extrahieren (z.B. bei Verwendung einer Publish/Subscribe-Architektur mit Multicast-Adressierung, siehe unten).
• Bei der Unicast-Adressierung werden in einem Header einer Netzwerknachricht Absenderinformationen, wie etwa eine Publisher-ID, z.B. die Identifikation einer absendenden Maschinensteuerung, eingeschrieben; außerdem kann der Nachrichten-Identifikator bei einer Unicast-Adressierung Informationen (z.B. IP-Adresse) des Empfängers bzw. Adressaten tragen, anhand derer die jeweilige Netzwerknachricht mit den Steuerungsdaten zum jeweils vorgesehenen Adressaten geroutet wird. Vorzugsweise enthält eine solche Netzwerknachricht Steuerungsdaten nur für den vorgesehenen Adressaten, so dass für jeden Adressaten im Netzwerk eine eigene Unicast-Netzwerknachricht generiert, übertragen und entsprechend geroutet wird.
• Solche Spezifika der Publish-/Subscribe-Architektur können ebenfalls durch die erfindungsgemäßen Objekte (und deren Eigenschaften oder Beziehungen, siehe weiter unten) beschrieben und festgelegt werden. Dazu werden die entsprechenden Eigenschaften (beispielsweise Unicast- oder Multicast-Adressierung) als Instanz eines solchen Objektes ausgebildet und mit entsprechenden Eigenschaften befüllt.
• Demgegenüber trägt eine erfindungsgemäße Netzwerknachricht bei der Multicast-Adressierung - ggf. neben den o.g. Absenderinformationen - Steuerungsdaten für mehrere Empfänger, so dass jede Netzwerknachricht an mehrere Netzwerkteilnehmer geroutet wird und anhand des Nachrichten-Identifikators der Netzwerkteilnehmer aus der Netzwerknachricht seine ihn betreffenden Steuerungsdaten extrahiert.
• Die Konfigurationsfähigkeit der Maschinensteuerung (etwa wahlfrei als Publisher und/oder als Subscriber) kann beispielsweise in einer Firmware und/oder in einer Maschinensteuerungsapplikation der Maschinensteuerung vorgesehen sein, so dass der Anwender lediglich die entsprechende Konfiguration der Maschinensteuerung ansprechen oder auswählen muss. Bei einer etwa als Software-Applikation ausgebildeten Maschinensteuerung kann die Konfigurationsmöglichkeit in Software der entsprechenden Applikation realisiert sein. Wesentlich ist dabei, dass die Konfiguration wahlfrei erfolgt; dies kann bedeuten, dass eine Maschinensteuerung jederzeit und/oder frei auswählbar und/oder automatisch oder manuell einstellbar entsprechend vorgesehen und/oder konfiguriert werden kann. Durch die erfindungsgemäß verwendeten Objekte wird gewährleistet, dass jede Maschinensteuerung (und jeder andere Netzwerkteilnehmer) unter Verwendung austauschbarer, einheitlicher oder kompatibler Objekte entsprechend konfiguriert und betrieben werden kann.
• Bevorzugte Ausgestaltungen, die den Gegenstand der Erfindung nicht einschränken, sind in den Unteransprüchen beschrieben.
• Wenn die Überwachung mittels einheitlich verwendeter, untereinander kompatibler, sowohl für die Überwachung als auch für die Publish-/Subscribe-Datenübertragung charakteristischer Eigenschaften der Objekte (Überwachungseigenschaften) erfolgt, ist die Implementierung der Überwachung sehr flexibel und insbesondere sehr systemtreu bezogen auf das Publish-/Subscribe-Kommunikationsmodell und dessen Überwachungseigenschaften und Publish-/Subscribe-Eigenschaften. Bezüglich der Kompatibilität und einheitlichen Verwendung gilt das oben bereits ausgeführte entsprechend. Erfindungsgemäß sind die Überwachungseigenschaften gleichzeitig sowohl für die Überwachung als auch für die Publish-/Subscribe-Datenübertragung charakteristisch. Die Überwachungseigenschaften sind dabei insbesondere Arten oder Typen von Verbindungen oder von Komponenten von Verbindungen. Es kann sich auch um Arten von Variablen handeln, die sich auf die Konfiguration oder den Betrieb einer solchen Verbindung beziehen.
• Die Erfindung schlägt vor, dass die Überwachung mittels einheitlich verwendeter, untereinander kompatibler, sowohl in Bezug auf die Überwachungsfunktion als auch auf die Publish-/Subscribe-Datenübertragung relevanter Beziehungen der Objekte untereinander (Überwachungsbeziehungen) erfolgt. Dadurch können sehr einfach und flexibel technische Merkmale von Überwachungsfunktionen und deren technische Zusammenhänge implementiert werden. So kann beispielsweise durch Überwachungsbeziehungen konfiguriert werden, dass eine bestimmte Publish-/Subscribe-Verbindung andere Objekte oder Komponenten hat, auf die dann für die Überwachung zurückgegriffen werden kann. Dies können beispielsweise physikalische oder logische Komponenten eines Publishers oder Subscribers, wie etwa ein Reader oder ein Writer sein (hierauf wird weiter unten detailliert eingegangen).
• Um solche, vor allem im Rahmen der industriellen Automatisierung verwendeten Überwachungsfunktionen industrieweit, auch zwischen Geräten unterschiedlicher Hersteller verwenden zu können, wird vorgeschlagen, dass die Objekte und/oder Überwachungseigenschaften nach Anspruch 2 und/oder Überwachungsbeziehungen nach Anspruch 3 im Rahmen des Datenaustauschstandards, insbesondere in einem Informationsmodell des Datenaustauschstandards, standardisiert sind. Es ist eine besondere Erkenntnis der Erfindung, dass durch die Implementierung der Objekte und/oder Überwachungseigenschaften und/oder Überwachungsbeziehungen in einem Informationsmodell eine besonders effiziente und in hohem Maße interoperable Lösung geschaffen wird. Erfindungsgemäß eignet sich ein solches Informationsmodell eines Datenaustauschstandards - insbesondere von OPC-UA - besonders gut, um die oben genannten Merkmale netzwerkweit einheitlich und schlank sowie austauschbar zu definieren. Ein solches Informationsmodell ist in einem Datenaustauschstandard vorzugsweise ohnehin vorhanden, so dass die erfindungsgemäßen Objekte und/oder Überwachungseigenschaften und/oder Überwachungsbeziehungen basierend auf den Eigenschaften eines solchen, vorhandenen Informationsmodells ausgelegt sein können. So wird durch standardkonforme, minimale Maßnahmen gewährleistet, dass die Erfindung effizient und interoperabel implementiert werden kann.
• Ein geringer Overhead bei einem hohen Maße an Kompatibilität und Interoperabilität sowie eine schlanke Ausgestaltung der Erfindung wird dadurch erreicht, dass die Objekte und/oder die Überwachungseigenschaften und/oder die Überwachungsbeziehungen jeweils von entsprechenden Objekten bzw. Eigenschaften bzw. Beziehungen des Publish-/Subscribe-Kommunikationsmodells abgeleitet sind. Das Publish-/Subscribe-Kommunikationsmodell ist dabei etwa im Rahmen des Datenaustauschstandards bereits vorhanden und sieht entsprechende Objekte bzw. Eigenschaften bzw. Beziehungen von Publish-/Subscribe-Objekten schon vor, auf die die Erfindung einfach aufsetzen kann. Dadurch werden viele bereits vorhandene Merkmale übernommen und müssen nicht redundant erzeugt bzw. definiert sein. Besonders bevorzugt ist es, dass bei der Ableitung die Eigenschaften und/oder Beziehungen im Rahmen des Publish-/Subscribe-Kommunikationsmodells seitens der Überwachungseigenschaften bzw. Überwachungsbeziehungen geerbt, also unter Wahrung der entsprechenden Eigenschaften oder Funktionalitäten auf diese übertragen werden. Dann können die Eigenschaften und/oder Beziehungen aus dem Publish-/Subscribe-Kommunikationsmodell übernommen werden und sind dadurch einfacher vorzubelegen und auch bezüglich der Handhabung und Bedienung eines solchen Systems einfacher ausgestaltet, da Eigenschaften und/oder Beziehungen ja bereits bekannt und etabliert sind. Gleichzeitig wird dadurch gewährleistet, dass erfindungsgemäß lediglich bei den Eigenschaften/Beziehungen, die sich auch auf Überwachungsfunktionen beziehen, zusätzliche Merkmale in das Informationsmodell aufgenommen werden. Auch dadurch ist eine minimale bis äußerst effiziente Umsetzung einer erfindungsgemäßen Überwachung gegeben.
• Die Maschinensteuerung kann in ihrer Subscriber-Funktion eine zusätzliche Publisher-Funktion gemäß Anspruch 6 haben. Diese Publisher-Funktion ist lokal auf der Maschinensteuerung vorgesehen und korreliert mit der Subscriber-Funktion der Maschinensteuerung. Die Publisher-Funktion ist somit - zumindest teilweise - auf die Subscriber-Funktion bezogen bzw. dieser zugeordnet. Dies bedeutet, dass die Publisher-Funktion Daten überträgt, die mit der Subscriber-Funktion zusammenhängen und/oder von dieser stammen und/oder auf dieser basieren. Die Maschinensteuerung überträgt nämlich in ihrer Publisher-Funktion Subscriber-Daten über das Netzwerk; diese Subscriber-Daten können ausschließlich oder zusätzlich zu anderen, zu übertragenden Daten, wie etwa Steuerungsdaten, übertragen werden. Die Subscriber-Daten werden auf der Maschinensteuerung lokal zusammengestellt und beziehen sich auf die Subscriber-Funktion.
• Es ist ebenso eine Erkenntnis der Erfindung, dass die Subscriber-Funktion der Maschinensteuerung einerseits eine Meldung bezüglich der vom Remote-Publisher bezogenen Steuerungsdaten generieren und übertragen kann und andererseits diese Meldung im Sinne des Publish-/Subscribe-Kommunikationsmodells eine entsprechende Remote-Subscriber-Funktion benötigt, die einen Bezug zu der Einheit hat, die den Remote-Publisher implementiert. Auf diese Weise wird die Rückmeldung bzw. Kopplung der Kette erreicht: Remote-Publisher überträgt Steuerungsdaten - Subscriber der Maschinensteuerung bezieht Steuerungsdaten - Publisher der Maschinensteuerung überträgt Subscriber-Daten - Remote-Subscriber bezieht Maschinensteuerungs-Subscriber-Daten (die letztendlich vom Subscriber der Maschinensteuerung erhoben und übertragen werden). Die Konfiguration einer solchen Rückmeldung oder Kommunikationskette wird mit den erfindungsgemäßen Objekten (und deren Eigenschaften oder Beziehungen, siehe dazu weiter unten) implementiert, indem die Objekte auf die Konfiguration bezogene Merkmale repräsentieren.
• Die Maschinensteuerung kann technisch wahlfrei als Publisher und gleichzeitig als Subscriber betreibbar sein und in beiden Funktionen gleichermaßen simultan konfiguriert und betrieben sein. Dadurch hat die Maschinensteuerung gleichzeitig zu ihrer Subscriber-Funktion die Publisher-Funktion, die dazu erforderlich ist, im Rahmen und unter Wahrung der Publish-/Subscribe-Kommunikationsmodell-Architektur ihre Subscriber-Daten zu übertragen. In diesem Zusammenhang ist es bevorzugt, dass ein Netzwerkteilnehmer, auf dem der genannte Remote-Publisher realisiert ist, auf ein- und demselben Netzwerkgerät bzw. Netzwerkteilnehmer ebenfalls einen Remote-Subscriber implementiert hat. Dieser Remote-Subscriber empfängt vorzugsweise die Subscriber-Daten der Maschinensteuerung. Dazu kann der Netzwerkteilnehmer, auf dem die Remote-Subscriber-Funktion und die Remote-Publisher-Funktion implementiert sind, eine Maschinensteuerung, ein Industrie-PC oder ein anders gearteter Netzwerkteilnehmer, beispielsweise ein Office-PC, sein.
• Insoweit korrespondiert bzw. korreliert die Remote-Subscriber-Funktion mit dem Remote-Publisher. Während der Remote-Netzwerkteilnehmer in seiner Remote-Publisher-Funktion die Steuerungsdaten über das Netzwerk sendet/überträgt (die dann von der Maschinensteuerung im Rahmen ihrer Subscriber-Funktion empfangen und ausgewertet werden), empfängt er über die Remote-Subscriber-Funktion Subscriber-Daten vorzugsweise derjenigen Maschinensteuerung, die die Steuerungsdaten von dem Remote-Publisher empfängt. Insofern beziehen sich die von dem Remote-Subscriber empfangenen Subscriber-Daten auf die ursprünglich vom Remote-Publisher an den Subscriber der Maschinensteuerung übertragenen Steuerungsdaten und insbesondere auf einen Bezugsstatus oder sonstige Meta-Kommunikationsdaten der Kommunikation zwischen dem Remote-Netzwerkteilnehmer und der Maschinensteuerung. Es wird ein Kommunikationspfad zwischen der Maschinensteuerung und einem Netzwerkteilnehmer (dies können auch mehrere oder alle Netzwerkteilnehmer sein) geschlossen bzw. in beide Richtungen vervollständigt und/oder rückgekoppelt. Die Erfindung bewerkstelligt dies komplett im Rahmen der vorgesehenen Publish-/Subscribe-Kommunikationsarchitektur und durchbricht die gemäß dem Datenaustauschstandard vorgesehenen technischen Vorgaben vorzugsweise nicht oder nur bedarfsgemäß und dosiert. Dazu dient auch die erfindungsgemäße Definition von maßgeschneiderten Objekten, Überwachungseigenschaften und Überwachungsbeziehungen, indem bei minimaler Erweiterung des zugrundeliegenden Informationsmodells unter Anlehnung an ein vorhandenes Informationsmodell die technischen Grundlagen zur Konfiguration einer überwachten Verbindung bereitgestellt werden.
• Dabei bietet die Erfindung vielfältige Möglichkeiten der Erweiterung eines Netzwerkes der Industrieautomatisierung sowie eine praktisch vollständige, deterministische und vor allem einfach und zuverlässig zu überwachende Kommunikation, wenn die Subscriber-Daten Steuerungsdaten der Maschinensteuerung und/oder Statusdaten der Maschinensteuerung und/oder Heartbeat-Daten (also etwa zyklisch übertragene, den ordnungsgemäßen Betrieb oder Online-Status repräsentierende Überwachungs- oder funktionsbezogene Daten) und/oder Daten nach Art eines Rückkanals einer industriellen Automatisierung-Feldbus-Architektur umfassen. Einerseits können also auch auf dem „Rückkanal“ wieder Steuerungsdaten übertragen werden, und zwar vorzugsweise Steuerungsdaten der Maschinensteuerung selber oder Steuerungsdaten, die die Maschinensteuerung von anderen Netzwerkteilnehmern/Maschinensteuerungen empfangen hat. Dadurch wird eine praktisch unbegrenzte Kommunikation (auch in Echtzeit) im Hinblick auf auszutauschende Steuerungsdaten ermöglicht, beispielsweise eine Kommunikation von Sollwerten und/oder Istwerten gekoppelter Bewegungsbahnen einer Maschine der industriellen Automatisierung, wie beispielsweise einer Werkzeugmaschine.
• Andererseits enthalten Subscriber-Daten aber vorzugsweise immer auch Statusdaten der die Steuerungsdaten empfangenden Maschinensteuerung selber. Diese Statusdaten können einerseits einen Bezugsstatus der bezogenen Steuerungsdaten umfassen; sie können andererseits aber auch alternativ oder zusätzlich einen generellen Status der Maschinensteuerung umfassen, wie etwa einen Bereitschaftsstatus, einen Operationsstatus, einen Betriebsmodus, online/offline-Status, Empfangsbereitschaft und/oder Übertragungs- oder Sendebereitschaft.
• Insgesamt können die Daten insbesondere auch nach Art eines Rückkanals einer industriellen Automatisierungs-Feldbus-Architektur aufgebaut bzw. implementiert sein. Dies kann einer Kommunikations-Rückrichtung entsprechen, in der - etwa angeforderte oder vom sendenden Partner benötigte - Daten insbesondere zyklisch und/oder deterministisch und/oder in Echtzeit übertragen werden. Wenn eine Implementierung nach Art eines Rückkanals vorgesehen ist, dann werden insbesondere von dem Remote-Publisher angeforderte oder für diesen benötigte Daten/Merkmale rückgemeldet. Dies kann einer Primärteilnehmer-/Sekundärteilnehmer-Architektur entsprechen, in der der Remote-Publisher bzw. derjenige Netzwerkteilnehmer, auf dem der Remote-Publisher implementiert ist, einem Primärteilnehmer entspricht und der Subscriber bzw. die Maschinensteuerung einem Sekundärteilnehmer.
• Im Rahmen der Erfindung können die Daten auch zusätzliche Informationen enthalten oder die Kommunikation insgesamt kann in der „Rückrichtung“ zusätzliche Merkmale aufweisen, wobei die Informationen/Merkmale über diejenigen eines Rückkanals hinausgehen. Die Erfindung erlaubt es nämlich, flexible Kommunikationskanäle bzw. Kommunikationswege aufzubauen, die auch unabhängig von einer hierarchischen Primärteilnehmer-/Sekundärteilnehmer-Architektur sein können. Während hierarchische Kommunikationsmodelle unterstützt werden, kann es ein besonderer Vorteil sein, wenn gerade nicht solche vergleichsweise starren Strukturen die Topologie bzw. den Aufbau der Kommunikation einschränken. Vielmehr können prinzipiell gleichberechtigt zwischen allen Netzwerkteilnehmern gemäß der Erfindung realisierte Kommunikationsmechanismen etabliert werden. Dies ermöglicht es auch, Kommunikationswege oder vorgegebene Hierarchiebeziehungen flexibel abzubilden bzw. umzustellen, soweit dies erforderlich ist.
• Bei industriellen Automatisierungssystemen kann es zum Beispiel für eine Synchronisierung von Bewegungen automatisierter Achsen (beispielsweise durch Elektromotoren) oder für die Gewährleistung von Sicherheitsfunktionen, Qualitätsfunktionen oder Berichts- oder Dokumentationsfunktionen (auch für Zwecke der Qualitäts-Dokumentation) erforderlich sein, dass eine beidseitig bidirektionale Kommunikation erfolgt, dass also zwei Netzwerkteilnehmer in jede Richtung Daten untereinander austauschen können. Die Erfindung erreicht dies auf besonders schlanke und effiziente Weise bei einem hohen Standardisierungsgrad und prinzipieller Austauschbarkeit dadurch, dass zwischen der Maschinensteuerung und einem Remote-Netzwerkteilnehmer eine bidirektionale Kommunikation erfolgt, die durch die erfindungsgemäßen Objekte, Überwachungseigenschaften und Überwachungsbeziehungen zu implementieren ist.
• Insgesamt ermöglicht die Erfindung eine flexible, systemtreue und konfigurationstreue Abbildung der Automatisierungs-Infrastruktur, wenn Maschinensteuerung und der Remote-Netzwerkteilnehmer Steuerungsdaten austauschen und/oder Statusdaten einen Gerätestatus der Maschinensteuerung bzw. des Remote-Netzwerkteilnehmers betreffend. Sie können alternativ oder zusätzlich auch Kommunikations-Metadaten austauschen, die sich auf Eigenschaften des Kommunikationskanals bzw. auf einen Kommunikationsstatus beziehen und/oder Netzverbindungs-Statusdaten, zum Beispiel Dienstgütedaten und/oder Identifikationsdaten der Maschinensteuerung oder einer der Maschinensteuerung zugehörigen, logischen Einheit bzw. des Remote-Netzwerkteilnehmers oder einer dem Remote-Netzwerkteilnehmer zugehörenden, logischen Einheit. Solche Identifikationsdaten können technische Daten der Maschinensteuerung bzw. des Remote-Netzwerkteilnehmers oder Identifikationsnummern oder Codierungsdaten dieser Geräte umfassen, die für die Geräte charakteristisch sind. Die Konfiguration und Übertragung solcher Daten wird erfindungsgemäß durch die Verwendung systemweit vorgesehener Objekte, Überwachungseigenschaften oder Überwachungsbeziehungen bewerkstelligt.
• Insgesamt kann - insbesondere gemäß dem Datenaustauschstandard - vorgesehen sein, dass die Funktionen des Übertragens bzw. Sendens/Empfangens und des Schreibens bzw. Auslesens von Daten entsprechend separat oder modularisiert sind. Hierzu kann ein Publisher oder jeder Publisher gemäß dem Datenaustauschstandard einen oder mehrere, vorgeschaltete, physikalische, logische oder virtuelle Schreibeeinheit(en) (Writer) aufweisen, die die jeweils zu übertragenden Daten bereitstellt/bereitstellen. Dies kann insbesondere jeweils ein Hardware- oder Software-Modul, beispielsweise eine App oder eine Prozedur, sein. Ein Writer kann die zu übertragenden Daten lokal abrufen, zusammenstellen, bearbeiten und für eine Übertragung vorbereiten, etwa in ein bestimmtes Format oder in eine vorbereitete Netzwerknachricht einschreiben oder auch die vorgesehenen Daten in einen Codierungsstandard für die Netzwerknachricht kodieren. Ein solcher Writer ist in der gesamten Kommunikationssequenz dem Publisher vorgeschaltet; dadurch erfolgt die Bereitstellung durch den Writer vor der Übertragung durch den Publisher.
• Analog kann einem Subscriber gemäß dem Datenaustauschstandard eine (oder mehrere) physikalische, logische oder virtuelle Leseeinheit (-en) (Reader) nachgeordnet sein. Dafür gilt das oben für den Writer ausgeführte entsprechend. Ein solcher Reader liest die empfangenen oder bezogenen Daten aus. Er ist dem entsprechenden Subscriber in der Kommunikationssequenz nachgeordnet, sodass das Auslesen der Daten oder eine Dekodierung der Daten aus einer bezogenen Netzwerknachricht nach dem eigentlichen Empfang/Bezug der Netzwerknachricht erfolgt.
• Eine schlanke und flexible Implementierung wird dadurch erreicht, dass dabei die Objekte und/oder Überwachungseigenschaften und/oder Überwachungsbeziehungen der Objekte untereinander für jeweils einen solchen Writer und/oder einen solchen Reader relevant sind. Dadurch können die entsprechenden Eigenschaften von Writern/Readern aus dem Fundus an Eigenschaften, die in dem Datenaustauschstandard für die Publish-/Subscribe-Kommunikationsarchitektur normiert sind, übernommen bzw. geerbt werden. Die entsprechenden Objekte und/oder Überwachungseigenschaften und/oder Überwachungsbeziehungen der Objekte können dabei für einen Writer/Reader charakteristisch im oben genannten Sinne sein; sie sind bereits dann relevant, wenn sie Informationen oder Merkmale eines solchen Writers/Readers enthalten oder referenzieren.
• Die Subscriber-Daten sind erfindungsgemäß flexibel und bedarfsgemäß zu konfigurieren; auch deren Inhalte, Verteilung und Handhabung sowie Format können flexibel und wahlfrei festgelegt werden. Damit ermöglicht es die Erfindung, auf einfache Weise eine flexible und jederzeitige Übersicht über Status von Netzwerkteilnehmern zu erhalten. Dazu wird vorgeschlagen, dass mittels der übertragenen Subscriber-Daten ein virtuelles, aktuelles Zustandsmodell eines jeden Netzwerkteilnehmers und insbesondere des Subscribers und/oder der gesamten Maschinensteuerung bzw. von Unterkomponenten des Subscribers und/oder der Maschinensteuerung sowie alternativ oder zusätzlich einer physikalischen oder logischen Komponente des Subscribers und/oder der Maschinensteuerung und/oder eines jeden Netzwerkteilnehmers erzeugbar und insbesondere zyklisch aktualisierbar ist.
• Bei dem Zustandsmodell kann es sich um ein im Wesentlichen vollständiges oder auch reduziertes oder im Extremfall sogar minimales Zustandsmodell handeln. Alternativ oder zusätzlich kann es sich auch um einen sogenannten „Digital Twin“ handeln. Das Zustandsmodell kann einzelne, eine Untermenge von, bestimmte, ausgewählte oder ein praktisch vollständiges Abbild von Parametern eines der oben genannten Modelle abbilden und aktuell halten. Idealerweise verfügt ein solches Zustandsmodell (oder Digital Twin) zumindest über eine Übersicht, ob sich die entsprechende Komponente in einem Fehlerzustand oder einem regulären Zustand befindet. Dadurch wird jederzeit sichergestellt, dass die Funktionsfähigkeit der entsprechenden Komponente (insbesondere auch in Echtzeit) überwacht und aktualisiert werden kann.
• Das Zustandsmodell bezieht sich dabei auf den Subscriber und dessen Zustand selber, also insbesondere dessen Fehlerzustand oder regulären Zustand, insbesondere dessen Empfangszustand; es kann sich auch auf die Maschinensteuerung und deren Zustand selber ziehen, so dass mit den Subscriber-Daten eine Aussage über den Zustand, insbesondere den apparativen Zustand, der Maschinensteuerung selber anzugeben ist. Schließlich kann anhand der Subscriber-Daten auch ein Zustandsmodell lediglich einer - physikalischen oder logischen - Komponente des Subscribers oder der Maschinensteuerung gemeint sein. Damit kann eine jeweilige Untereinheit der entsprechenden Komponente umfasst sein; als logische Komponente kommt insbesondere ein Reader wie oben beschrieben infrage.
• Das oben Gesagte sowie die Lehre des Anspruchs 10 können jeweils auch auf jeden Netzwerkteilnehmer angewendet werden, so dass auf einem beliebigen Netzwerkteilnehmer (der in diesem Fall nicht zwingend eine Maschinensteuerung sein muss) ein Subscriber implementiert ist, dessen Subscriber-Daten ein virtuelles, aktuelles Zustandsmodell dieses Subscribers und/oder des betreffenden Netzwerkteilnehmers und/oder einer physikalischen oder logischen Komponente des jeweiligen Netzwerkteilnehmers zu erzeugen erlauben, welches ebenfalls insbesondere zyklisch aktualisierbar sein kann.
• Wie oben ausgeführt, empfängt der Subscriber gemäß der Erfindung von einem Remote-Publisher publizierte Daten. Das oben genannte Zustandsmodell bezieht sich somit auch auf die Empfangsbereitschaft bzw. den Status und insbesondere den Empfangsstatus der von dem Remote-Publisher veröffentlichten Daten. Um eine möglichst kompakte und effiziente Überwachung mittels eines Zustandsmodells zu erreichen, wird daher vorgeschlagen, dass das Zustandsmodell lokal in dem Remote-Publisher erzeugt und insbesondere aktualisiert wird. Dabei gilt alles oben insbesondere unter der Beschreibung zu Anspruch 10 Genannte entsprechend.
• Es ist dabei erfindungsgemäß vorgesehen, dass das Zustandsmodell jeweils mit Methoden des Datenaustauschstandards erzeugbar und gegebenenfalls zyklisch aktualisierbar ist. Es kann dann jeweils mit (informationstechnischen) Methodenaufrufen erzeugt, aktualisiert und gegebenenfalls angesprochen, abgefragt oder auch innerhalb des Netzwerks übertragen werden. Insbesondere soll eine interoperable Überwachung netzwerkweit bzw. innerhalb eines abgegrenzten Netzwerksegments dadurch ermöglicht werden, dass das Zustandsmodell mit standardisierten Methoden des Datenaustauschstandards netzwerkweit oder innerhalb eines Netzwerksegmentes für Netzwerkteilnehmer zugänglich und insbesondere abrufbar und/oder herunterladbar oder in sonstiger Weise informationstechnisch ansprechbar ist.
• Dabei kann eine smarte Überwachung einfach und interoperabel ausgestaltet werden, wenn die Objekte und/oder Überwachungseigenschaften und/oder Überwachungsbeziehungen jeweils für das Zustandsmodell relevant sind. Sie können auch für das Zustandsmodell charakteristisch sein; dann gilt das oben diesbezüglich ausgeführte entsprechend. Sie sind bereits dann für das Zustandsmodell relevant, wenn sie Informationen oder Merkmale haben, die sich auf das Zustandsmodell oder dessen Eigenschaften beziehen. Beispielsweise kann eine Überwachungsbeziehung angeben, dass ein Subscriber und/oder ein Reader ein entsprechendes Zustandsmodell besitzt, das auf einem anderen (Remote) Netzwerkteilnehmer mitgeführt/aktualisiert/aufgebaut wird. Des Weiteren kann eine Überwachungseigenschaft angeben, dass ein Zustandsmodell überhaupt vorhanden ist. Ein Objekt kann erfindungsgemäß beinhalten, dass ein solches Zustandsmodell aktualisiert (insbesondere zyklisch aktualisiert) wird.
• Die oben eingangs genannten Aufgaben werden ebenfalls gelöst durch eine netzwerkfähige Maschinensteuerung, insbesondere speicherprogrammierbare Steuerung (SPS bzw. Programmable Logic Control PLC), oder netzwerkfähige Rechnereinrichtung mit darauf implementierter, virtueller oder emulierter Maschinensteuerung, jeweils dazu eingerichtet ist, ein Verfahren nach einem der Ansprüche 1-10 auszuführen. Die Maschinensteuerung ist dabei das Netzwerk eingebunden und unterstützt den Datenaustauschstandard. Sie ist wahlfrei als Publisher und/oder als Subscriber zu konfigurieren, unterstützt den Datenaustauschstandard, und stellt intern die oben genannten Objekte, Überwachungseigenschaften und Überwachungsbeziehungen bereit. Alles oben Gesagte gilt entsprechend.
• Die Erfindung wird anhand von Ausführungsbeispielen und Zeichnungen, teilweise grob schematisch, erläutert. In den Zeichnungen sind gleiche oder funktionsgleiche Merkmale mit denselben Bezugszeichen versehen, sofern nichts anderes in der Beschreibung angegeben ist. Die in einer Figur gezeigten, technischen Ausgestaltungsmerkmale sind auf jede Variante der Erfindung anwendbar, und zwar auch unabhängig von anderen, in dieser Figur etwa enthaltenen und/oder beschriebenen Merkmalen, sofern zu dieser Figur bzw. diesem Ausgestaltungsmerkmal nichts anderes explizit ausgeführt ist. Es zeigen:
• 1 einen unidirektionalen Kommunikationskanal zwischen zwei Netzwerkgeräten über einen Publish-/Subscribe-Kommunikationsmechanismus, der auf einer entkoppelten Kommunikation basiert,
• 2 eine Kommunikation zwischen zwei Netzwerkgeräten, die ebenfalls auf der Publish-/Subscribe-Kommunikationsarchitektur beruht, aber gleichzeitig im Erfindungssinne eine bidirektionale Kommunikation bedarfsgerecht ermöglicht,
• 3 eine ebenfalls bidirektionale Kommunikation zwischen zwei Netzwerkgeräten über zwei Kommunikationskanäle, wobei zumindest einer der Kommunikationskanäle im Erfindungssinne überwacht ist,
• 4 eine grob schematische, stark vereinfachte Darstellung eines erfindungsgemäß erweiterten Informationsmodells als Ausschnitt aus einem Gesamt-Informationsmodell.
• 1 zeigt zunächst eine Konfiguration, wie sie einem Verfahren der Kommunikation von Maschinensteuerungsdaten eines mechatronischen Systems 2 in einem Netzwerk 3 zugrunde liegen kann. Das Netzwerk 3 ist dabei lediglich schematisch dargestellt. Das Netzwerk 3 verbindet zumindest eine Maschinensteuerung 4 und einen Remote-Netzwerkteilnehmer 7 mittels eines Datenaustauschstandards, der ein Publish-/Subscribe-Kommunikationsmodell unterstützt. Bei dem Datenaustauschstandard kann es sich - wie oben bereits näher ausgeführt - beispielsweise um OPC-UA handeln. Bei dem Kommunikationsmodell ist jeweils ein Publisher P1, der Daten über das Netzwerk 3 veröffentlicht bzw. sendet, von jeglichem Subscriber und in der Darstellung insbesondere von dem Subscriber S1 der Maschinensteuerung 4 prinzipiell entkoppelt. Die Kommunikation findet in der Darstellung der 1 über einen einzigen Kommunikationskanal (Primärkanal) 8 und lediglich unidirektional vom Publisher P1 zum Subscriber S1 statt.
• 2 zeigt eine Konfiguration, bei der Maschinensteuerung 4 bzw. Remote-Netzwerkteilnehmer 7 beide wahlfrei als Publisher P2 bzw. P1 und gleichzeitig als Subscriber S1 bzw. S2 zu betreiben sind. Erfindungsgemäß ist zumindest die Maschinensteuerung 4 so konfiguriert, dass sie in ihrer Subscriber-Funktion S1 Steuerungsdaten mittels des Datenaustauschstandards unter Verwendung der Publish-/Subscribe-Architektur von einem Remote-Publisher P1 über das Netzwerk 3 bezieht. Der Remote-Publisher P1 ist dabei auf dem gezeigten Remote-Netzwerkteilnehmer 7 implementiert. Diese Steuerungsdaten werden über den primären Kommunikationskanal 8 gesendet und vom Subscriber S1 ebenfalls über diesen Primärkanal 8 bezogen.
• Zumindest die Maschinensteuerung 4 (und im gezeigten Ausführungsbeispiel auch der Remote-Netzwerkteilnehmer 7) ist dabei simultan als Publisher P2 (bzw. P1) betrieben. Diese Publisher-Funktion P2 korrespondiert mit der Subscriber-Funktion S1 der Maschinensteuerung 4, indem die Maschinensteuerung 4 mittels der Publisher-Funktion P2 auf die Subscriber-Funktion S1 bezogene Subscriber-Daten über das Netzwerk 3 sendet. In der 2 ist gezeigt, dass die Maschinensteuerung 4 über ihre Publisher-Funktion P2 die Daten unter Verwendung des sekundären Kommunikationskanals 9 veröffentlicht bzw. überträgt. Diese Subscriber-Daten können von einem Netzwerkteilnehmer 7 bezogen werden; in dem gezeigten Ausführungsbeispiel werden sie gerade von dem Remote-Subscriber S2 bezogen, der mit der Remote-Publisher-Funktion P1 des Remote-Netzwerkteilnehmers 7 derart korrespondiert, dass die Subscriber-Funktion S2 sich auf die von dem Remote-Publisher P1 gesendeten und von dem Subscriber S1 der Maschinensteuerung 4 empfangenen Subscriber-Daten bezieht und ebenfalls auf dem Remote-Netzwerkteilnehmer 7-wie auch der ursprüngliche Remote-Publisher P1, von dem die originären Steuerungsdaten stammen - residiert bzw. implementiert ist.
• Insgesamt ist dadurch der Bezug der Steuerungsdaten mittels der Übertragung der Subscriber-Daten zu überwachen. Gleichzeitig können die Subscriber-Daten, die über den Sekundärkanal 9 übertragen werden, auch Steuerungsdaten der Maschinensteuerung 4 und gleichzeitig Statusdaten der Maschinensteuerung 4 sowie Daten nach Art eines Rückkanals einer industriellen Automatisierungs-Feldbus-Architektur umfassen. Dabei ist der Rückkanal durch den in der 2 gezeigten Sekundärkanal 9 realisiert. Insgesamt erfolgt eine bidirektionale Kommunikation. Über den Sekundärkanal 9 tauschen die Maschinensteuerung 4 und der Remote-Netzwerkteilnehmer 7 Überwachungsdaten aus, die sich auf die Überwachung des Primärkanals 8 beziehen.
• Lediglich symbolisch ist in der 2 (wie auch in der 1) noch gezeigt, dass die Kommunikation über beide Kanäle 8,9 mittels eines standardisierten, inhärent verbindungsfreien und/oder inhärent kopplungsfreien Übertragungsprotokolls 10, nämlich UADP, erfolgt. Dies ist ein auf dem UDP-Standard basierendes Übertragungsprotokoll 10.
• 3 zeigt - ebenfalls schematisch -, wie die Erfindung eine Überwachung der Kommunikation zwischen der Maschinensteuerung 4 und einem Remote-Netzwerkteilnehmer 7 realisiert. Dabei wird einerseits ein erweitertes Übertragungsprotokoll 20 verwendet, welches immer noch auf UDP basieren kann (insbesondere kann UADP als Payload in einem OSI-Layer 2-Frame oder UDP-Datagramm integriert werden) und dem UADP-Standard entspricht.
• Sowohl in der Maschinensteuerung 4 als auch in dem Remote-Netzwerkteilnehmer 7 ist symbolisch bzw. schematisch dargestellt, wie eine erfindungsgemäße Überwachung (gegebenenfalls mit dem erweiterten Übertragungsprotokoll 20) unter Verwendung eines Datenaustauschstandards, wie beispielsweise OPC-UA, und gegebenenfalls unter Erweiterung eines solchen Datenaustauschstandards bewerkstelligt werden kann. Grundsätzlich ist die Kommunikationsstrecke der 2 in 3 übernommen; dabei erfolgt die direkte Kommunikation der Steuerungsdaten über den Primärkanal 8 und die Rückkommunikation der Subscriber-Daten über den Sekundärkanal 9. Die Subscriber-Daten enthalten in dieser Variante der Erfindung Statusdaten, die eine Überwachung der Kommunikation der Steuerungsdaten bzw. des Primärkanals 8 erlauben. Die von dem Publisher P1 des Remote-Netzwerkteilnehmers 7 über den Primärkanal 8 gesendeten Steuerungsdaten werden - wie oben ausgeführt - über den Subscriber S1 der Maschinensteuerung 4 empfangen oder bezogen. Der Subscriber S1 greift dabei auf Mechanismen des Datenaustauschstandards (wie z.B. OPC-UA) zurück bzw. interagiert mit Komponenten bzw. Modulen dieses Datenaustauschstandards; dieser Rückgriff bzw. diese Interaktion ist jeweils in der 3 durch bidirektionale Pfeile angezeigt. So greift der Subscriber S1 auf Mechanismen einer erweiterten Zustandsmaschine 23 sowie auf ein OPC-UA-Informationsmodell 22 zu (gegenüber dem herkömmlichen OPC-UA-Standard kann es sich dabei erfindungsgemäß um ein um Überwachungsfunktionen erweitertes Informationsmodell handeln). Dabei sind Maschinensteuerung 4 und Remote-Netzwerkteilnehmer 7 jeweils als OPC-UA-Netzwerkteilnehmer bzw. OPC-UA-Server konfiguriert, so dass der gesamte OPC-UA-Stack oder der für die Erfindung erforderliche Anteil jeweils im Netzwerkteilnehmer 7 und in der Maschinensteuerung 4 (sowie ggf. in jedem relevanten Netzwerkteilnehmer 4,7) zugreifbar vorhanden bzw. installiert sind.
• Auch die erweiterte Zustandsmaschine 23 ist im Rahmen des Datenaustauschstandards definiert bzw. gegenüber dem konventionellen Rahmen standardkonform erweitert; eine solche Zustandsmaschine (auch endlicher Automat) ist ein Verhaltensmodell, welches im Wesentlichen aus Zuständen, Zustandsübergängen und Aktionen besteht und die Zustände, Zustandsübergänge und Bedingungen für Zustandsübergänge logisch in ein deterministisches Verhältnis bringt. In der praktischen Umsetzung kann eine solche Zustandsmaschine eine Abfolge von Befehlen, eine Prozedur oder ein Software- oder Hardware-Modul sein.
• Beispielsweise kann durch eine solche, erweiterte Zustandsmaschine 23 ein Fehlerzustand definiert bzw. eingenommen werden, sobald der Subscriber S1 eines oder mehrere Datenpakete verpasst. Jedenfalls wird der Zustand des Subscribers S1,S2/Readers R1,R2 (und auch des Publishers P1/P2/Writers W1,W2) und deren abgestimmte Zustände und Transitionen zwischen Zuständen mittels der Zustandsmaschine überwacht/geregelt/gesteuert. Dazu greift die erweiterte Zustandsmaschine 23 (wie auch der Subscriber S1) auf ein - ebenfalls erweitertes - Informationsmodell 22 des Datenaustauschstandards 21 zu. In dem Informationsmodell 22 sind die Variablen, deren Zusammenhänge, mögliche Zustände, Objekte und weitere, informationstechnische Elemente hinterlegt, die für die erfindungsgemäße Überwachung bzw. für die erfindungsgemäße Übertragung von Subscriber-Daten nutzbar sind. Hierzu können etwa Zustandsvariablen gehören, die einen Zustand des Primärkanals 8 oder einen Zustand des Subscribers 1 oder dergleichen repräsentieren; des Weiteren können dazu Indikatoren bzw. Indikatorvariablen, referenzielle Variablen und/oder Wertevariablen gehören, die sich auf eine Überwachung oder einen Status beziehen.
• Die über den Subscriber S1 von dem Remote-Publisher P1 bezogenen Steuerungsdaten werden - hier nicht gezeigt - für die Industrieautomatisierungs-Applikation intern weiter verwendet. Der bidirektionale Pfeil zur erweiterten Zustandsmaschine 23 und zum Informationsmodell 22 deuten an, dass insbesondere Subscriber-Daten, die Zustände des Subscribers S1 und/oder einen Empfangsstatus der Steuerungsdaten betreffen, erfindungsgemäß weiterverarbeitet werden. Dies erfolgt dadurch, dass der Publisher P2 der Maschinensteuerung 4 gleichzeitig Zugriff auf die erweiterte Zustandsmaschine 23 und das erweiterte Informationsmodell 22 hat. Über diesen standardisierten Zugriff kann der Publisher P2 auf Subscriber-Daten, insbesondere auf Zustandsdaten oder Statusdaten der Übertragung der Steuerungsdaten, zugreifen. Diese werden mithilfe des erweiterten Informationsmodells in der erweiterten Zustandsmaschine 23 bearbeitet und von dem Publisher P2 der Maschinensteuerung 4 über den sekundären Kommunikationskanal 9 unter Zuhilfenahme des erweiterten, UADP-basierten Übertragungsprotokolls 20 veröffentlicht oder übertragen. Diese Subscriber-Daten werden von dem Remote-Subscriber S2 des Remote-Netzwerkteilnehmers 7 bezogen. Auch für den Remote-Netzwerkteilnehmer 7 gilt das oben zu dem OPC-UA-Datenaustauschstandard 21, zu dem erweiterten Informationsmodell 22 sowie zu der erweiterten Zustandsmaschine 23 und deren bidirektionalen zusammen Wirkungsverhältnissen Ausgeführte entsprechend.
• Der Remote-Subscriber S2 wirkt mit der erweiterten Zustandsmaschine 23 zusammen; dadurch können die Subscriber-Daten entsprechend ausgewertet und unter Verwendung des erweiterten Informationsmodells 22 für die Auswahl bestimmter Zustände der erweiterten Zustandsmaschine 23 auf dem Remote-Netzwerkteilnehmer 7 verwendet werden. Beispielsweise kann dadurch ein Fehlerzustand und/oder ein ordnungsgemäßer Zustand, der sich auf die Übermittlung der Steuerungsdaten vom Remote-Publisher an den Subscriber S1 der Maschinensteuerung 4 bezieht, bei dem Remote-Netzwerkteilnehmer 7 bekannt gemacht und verwendet werden, um die Zuverlässigkeit und Deterministik der Kommunikation der Steuerungsdaten zu verbessern. So kann etwa ein zurückgemeldeter Fehlerzustand dazu führen, dass eine andere Netzwerkverbindung ausgewählt oder ein anderer Netzwerkpfad für die Übertragung der Steuerungsdaten verwendet wird; gleichermaßen können auch bei Fehlerzuständen wiederholte Aussendungen der betreffenden Steuerungsdaten über den Publisher P1 veranlasst werden.
• In der 3 ist noch schematisch gezeigt, dass der Publisher P1, P2 jeweils noch eine gemäß dem Datenaustauschstandard vorgeschaltete, logische Schreibeeinheit (Writer) W1, W2 aufweist, die jeweils die zu übertragenden Daten bereitstellt. Gleichermaßen ist jeweils eine dem Subscriber S1, S2 nachgeordnete, logische Leseeinheit (Reader) R1, R2 schematisch gezeigt, die jeweils die bezogenen Daten ausliest und/oder bearbeitet. Diese logischen Schreibeeinheiten W1, W2 sowie die logischen Leseeinheiten R1, R2 können dabei auch parallel oder in den Publisher P1, P2 bzw. den Subscriber S1, S2 integriert oder jeweils als dessen Komponente oder Modul ausgestattet sein. Schließlich zeigt 3 noch, dass mittels der Überwachung ein virtuelles, aktuelles Zustandsmodell (V1,V2) des Subscribers (S1, S2) und/oder der Maschinensteuerung (4) und/oder einer physikalischen oder logischen Komponente (R1,R2) des Subscribers (S1,S2) erzeugbar und insbesondere zyklisch aktualisierbar ist und wobei die Objekte (On) und/oder Überwachungseigenschaften (En) und/oder Überwachungsbeziehungen (Bn) für das Zustandsmodell (Vn) relevant sind, wie etwa in 4 durch das virtuelle Datensatz-Reader-Typ-Objekt 018, dessen Eigenschaft des virtuellen Datensatz-Reader-Typ-Objekts E18 und dessen Überwachungsbeziehungen B11,B12,B13 dargestellt - darauf wird weiter unten noch detaillierter eingegangen.
• Schließlich zeigt die 4 ein gemäß der Erfindung erweitertes Informationsmodell 22. Es kann sich auch um ein konzeptionelles oder logisches Datenmodell handeln. Jedenfalls ist es insbesondere eine Verkörperung der technischen oder informationstechnischen Objekte mit deren Eigenschaften und Beziehungen untereinander. Ein solches Informationsmodell 22 definiert daher die technischen Eigenschaften und Beziehungen der Objekte, die zum Einsatz der Erfindung erforderlich sind. Dadurch wird eine einheitliche Verwendung und datentechnische Interpretation der entsprechenden, informationstechnischen oder technischen Mechanismen oder Methoden gewährleistet.
• Das Informationsmodell 22 ist lediglich ein Ausschnitt aus einem gesamten Informationsmodell, welches beispielsweise im Rahmen des Datenaustauschstandards - insbesondere OPC-UA - vorhanden sein kann. Dabei sind allgemein die erfindungsgemäßen Objekte On angegeben, bei denen es sich sowohl um informationstechnische Objekte On im engeren Sinne handeln kann (siehe dazu Beschreibungstext oben) als auch um allgemeine Objekte On im weiteren Sinne (siehe oben). In der grob schematischen und stark vereinfachten Darstellung sind zu den jeweiligen Objekten On symbolisch die entsprechenden Eigenschaften En angegeben; es kann sich je nach Zusammenhang bei den Eigenschaften En auch um allgemeine Charakteristika oder lediglich Erläuterungen von Merkmalen der zugrundeliegenden Objekte On handeln. Des Weiteren sind allgemein Beziehungen Bn angegeben zwischen Objekten On; auch bei diesen Beziehungen Bn muss es sich nicht zwangsläufig um Überwachungsbeziehungen handeln; kontextgemäß können diese Beziehungen Bn auch lediglich Beschreibungen von Zusammenhängen zwischen den entsprechenden Objekten On bzw. Eigenschaften En aufweisen. Die oben genannten Details ergeben sich in der weiteren Beschreibung jeweils aus dem Zusammenhang.
• Die folgende Beschreibung bezieht sich im Wesentlichen auf die Definitionen und Standardisierungen bzw. Nomenklatur von OPC-UA; sie ist entsprechend auf jegliche andere Publish-/Subscribe-Kommunikationsarchitekturen und/oder Datenaustauschstandards anwendbar. Daher werden im folgenden insbesondere Typen (englisch type) und Referenztypen (englisch reference type) unterschieden, wobei die erstgenannten den Objekten On oder den Eigenschaften En und die letztgenannten den Beziehungen Bn entsprechen können. In der Bezugszeichenliste werden zu den Objekten On, den Eigenschaften En und den Beziehungen Bn noch jeweils Bezeichnungen in Klammern angehängt, die hinsichtlich der Sprache, der Syntax, der Zusammensetzung und ihres Inhaltes in einem Datenaustauschstandard (vorzugsweise OPC-UA) als einheitlich verwendete Bezeichner vorgesehen sein können. Die Sprache dieser Bezeichner ist Englisch, sie sind jeweils ohne Leerschritte ausgeführt, so dass sie den Charakter von informationstechnischen Bezeichnern widerspiegeln, die in einer entsprechenden, computerimplementierten Umsetzung ohne weiteres in der angegebenen Bezeichnerform verwendet werden könnten.
• Außerdem orientiert sich die gewählte Darstellung an dem grundsätzlichen Format eines Informationsmodells; demzufolge können die einzelnen Objekte On, die Eigenschaften En sowie die Beziehungen Bn als informationstechnische Objekte On im engeren Sinne, informationstechnische Eigenschaften En im engeren Sinne oder informationstechnische Beziehungen Bn im engeren Sinne zu verstehen sein. Andererseits können die genannten, in der 4 gezeigten Elemente auch lediglich Merkmale oder Beschreibungen im Rahmen eines allgemeinen Informationsmodells darstellen; dann sind die gezeigten Objekte On, Eigenschaften En, Beziehungen Bn als Elemente des Informationsmodells 22 auszulegen. Die Unterscheidung dieser Darstellungsweisen ergibt sich jeweils aus dem Zusammenhang. Es sind nicht alle Objekte On, Eigenschaften En, Beziehungen Bn als Überwachungsobjekte bzw. Überwachungseigenschaften bzw. Überwachungsbeziehungen ausgebildet; einzelne dieser Elemente können auch als standardisierte, konventionelle Elemente eines Datenaustauschstandards 21 ausgestaltet sein. Auch diese Differenzierung wird im Folgenden jeweils im Kontext ersichtlich.
• Wie oben bereits ausführlich beschrieben, wird der Bezug der Steuerungsdaten mittels einer Publish-/Subscribe-Datenübertragung von Überwachungsinformationen überwacht. Diese Überwachung erfolgt mittels einheitlich verwendeter, kompatibler, jeweils sowohl für die Überwachungsfunktion als auch für die Publish-/Subscribe-Datenübertragung charakteristischer Objekte On, die in dem Informationsmodell 22 mit ihren Eigenschaften En und Beziehungen Bn dargestellt sind. Durch die der Übersichtlichkeit halber einfach gehaltene und grob schematische Darstellung wird klar, dass die jeweiligen Objekte On jeweils sowohl für die Überwachungsfunktion als auch für die Publish-/Subscribe-Datenübertragung charakteristisch sind. Insbesondere können die folgenden Objekte On sowohl für die Überwachungsfunktion als auch für die Publish-/Subscribe-Datenübertragung charakteristisch sein:
  die überwachte Publish-/Subscribe-Verbindung 02 (kann ein informationstechnisches Objekt im engeren Sinne sein, welches die etablierte Publish-/Subscribe-Verbindung darstellt und als Instanz die entsprechenden Verbindungsparameter aufweisen kann), das überwachte Publish-/Subscribe-Verbindungs-Typ-Objekt 05 (kann lediglich die Eigenschaften zusammenfassen, die eine überwachte Publish-/Subscribe-Verbindung aufweist), die überwachte Writer-Gruppe 06 (kann ein informationstechnisches Objekt im engeren Sinne sein, welches überwachte Writer-Gruppen-Typ-Objekte gruppiert), die überwachende Reader-Gruppe 07 (kann ein informationstechnisches Objekt im engeren Sinne sein, welches die überwachenden Reader-Gruppen-Typen gruppiert), das überwachte Writer-Gruppen-Typ-Objekt 09 (kann etwa lediglich die Eigenschaften zusammenfassen, die überwachte Writer einer überwachten Writer-Gruppe als Typ aufweisen), das überwachende Reader-Gruppen-Typ-Objekt O10 (kann etwa lediglich die Eigenschaften zusammenfassen, die überwachte Reader einer überwachten Reader-Gruppe zum Beispiel als Typ aufweisen), der überwachte Datensatz-Writer 012 (kann ein informationstechnisches Objekt im engeren Sinne sein, der die eingerichteten Datensatz-Writer darstellt und als Instanz die entsprechenden Writer-Parameter aufweisen kann), der überwachende Datensatz-Reader 013 (kann ein informationstechnisches Objekt im engeren Sinne sein, das die etablierten Datensatz-Reader darstellt und als Instanz die entsprechenden Reader-Parameter aufweisen kann), das überwachte Datensatz-Writer-Typ-Objekt 016 (kann lediglich die Eigenschaften zusammenfassen, die überwachte Datensatz-Writer zum Beispiel als Typ aufweisen), das überwachende Datensatz-Reader-Typ-Objekt 017 (kann etwa als Objekt im weiteren Sinne lediglich die Eigenschaften zusammenfassen, die überwachende Datensatz-Reader zum Beispiel im Sinne eines Typs aufweisen) und schließlich das virtuelle Datensatz-Reader-Typ-Objekt 018 (kann etwa als Objekt im weiteren Sinne lediglich die Eigenschaften zusammenfassen, die virtuelle Datensatz-Reader zum Beispiel im Sinne eines Typs aufweisen). Die anderen, gezeigten Objekte können beispielsweise Objekte ohne Bezug zu einer Überwachungsfunktion im weiteren Sinne sein (also etwa Container oder Bezeichner für Eigenschaften oder andere Merkmale als Elemente des gezeigten Systems).
• Die Überwachung erfolgt erfindungsgemäß auch dadurch, dass einheitlich verwendete, untereinander kompatible, sowohl für die Überwachung als auch für die Publish-/Subscribe-Datenübertragung charakteristische Eigenschaften En der Objekte On vorgesehen sind (Überwachungseigenschaften); solche Überwachungseigenschaften sind insbesondere die folgenden in der 4 gezeigten:
• die überwachte Publish-/Subscribe-Verbindungs-Eigenschaft 2, der überwachte Publish-/Subscribe-Verbindungs-Typ E5, die überwachte Writer-Gruppen-Eigenschaft E6, die überwachende Reader-Gruppen-Eigenschaft E7, der überwachte Writer-Gruppen-Typ E9, der überwachende Reader-Gruppen-Typ E10, die überwachte Datensatz-Writer-Eigenschaft E12,
• die überwachende Datensatz-Reader-Eigenschaft E13, der überwachte Datensatz-Writer-Typ E16, der überwachende Datensatz-Reader-Typ E17 sowie der virtuelle Datensatz-Reader-Typ E 18. Die anderen, gezeigten Eigenschaften können beispielsweise Eigenschaften ohne Bezug zu einer Überwachungsfunktion oder Elemente im weiteren Sinne sein (also etwa Container oder Bezeichner für Eigenschaften oder andere Merkmale als Elemente des gezeigten Systems).
• Des Weiteren erfolgt die Überwachung erfindungsgemäß auch mittels einheitlich verwendeter, untereinander kompatibler, sowohl in Bezug auf die Überwachungsfunktion als auch auf die Publish-/Subscribe-Datenübertragung relevanter Beziehungen Bn der Objekte On untereinander (Überwachungsbeziehungen); solche Überwachungsbeziehungen sind insbesondere die folgenden, in der 4 gezeigten:
• die Komponenten-Beziehung B1 (da sie angibt, dass das konventionelle oder standardisierte Publish-/Subscribe-Typ-Objekt O1 eine überwachte Komponente 02 hat), die Typ-Definitions-Beziehung B4, Komponenten-Beziehung B5, die Komponenten-Beziehung B6, Untertypen-Beziehung B7, Untertypen-Beziehung B8, die Untertypen-Beziehungen B9, B10, die virtuelle Reader-Beziehung B11, die virtuelle Reader (Update-) Beziehung B12, die Untertypen-Beziehungen B13 und B14 sowie schließlich die Typ-Definitions-Beziehungen B15, B16, B17,
• B18. Die anderen, gezeigten Beziehungen können beispielsweise Beziehungen ohne Bezug zu einer Überwachungsfunktion oder Elemente im weiteren Sinne sein (also etwa Container oder Bezeichner für Eigenschaften oder andere Merkmale als Elemente des gezeigten Systems).
• Im Folgenden werden die technischen Eigenschaften und Zusammenhänge, die das Informationsmodell 22 der 4 darstellt, im Zusammenhang beschrieben:
• Links oben ist ein Publish-/Subscribe-Objekt O1 gezeigt mit einem Publish-/Subscribe-Typ, der einer Eigenschaft E1 entsprechen kann. Im gezeigten Fall kann es sich allerdings auch um eine Überschrift bzw. einen Einstiegspunkt in das (Teil-) Informationsmodell 22 handeln. Das Publish-/Subscribe-Objekt O1 hat (siehe die oberste Ebene der 4) zwei Beziehungen B1,B2. In der obersten Ebene der 4 ist ein reiner Bezug zur Publish-/Subscribe-Architektur gegeben; dies kann bedeuten, dass dort keine Beziehungen Bn/Objekte On/Eigenschaften En aufgeführt sind, die gleichzeitig einen Bezug zu Überwachungsfunktionen haben. Dabei kann es sich um reine Publish-/Subscribe-Elemente handeln, die so auch herkömmlich in dem Datenaustauschstandard 21 vorgesehen sind.
• Im gezeigten Ausführungsbeispiel hat das Publish-/Subscribe-Objekt O1 die Beziehung B2, die angibt, dass das Objekt O1 eine Komponente hat. Diese Komponente ist das gezeigte Verbindung-Objekt 03 mit der Verbindung-Eigenschaft E3. Das Verbindung-Objekt 03 kann ein Objekt im engeren Sinne (siehe oben) sein. Es hat eine Bezeichnung, beispielsweise einen Verbindungsnamen; seine Verbindungs-Eigenschaft E3 bezieht sich auf den Publish-/Subscribe-Verbindungstyp. Das Verbindungs-Objekt 03 hat einen über die Typ-Definitions-Beziehung B3 definierten Verbindungstyp, der in dem Objekt 04 wiedergegeben ist. Dazu hat das Objekt 04 die Publish-/Subscribe-Verbindungsart-Eigenschaft E4.
• Das Publish-/Subscribe-Objekt O1 hat über die Beziehung B1, die angibt, dass das Publish-/Subscribe-Objekt O1 über eine Komponente verfügt, eine Verbindung zu dem Objekt 02. Dabei kann es sich ebenfalls um ein Objekt im engeren Sinne handeln; das Objekt 02 hat die Eigenschaft E2, die angibt, dass es sich um einen überwachten Publish-/Subscribe-Verbindungstyp mit einer zugehörigen Verbindungsbezeichnung handelt. Dieser überwachte Publish-/Subscribe-Verbindungstyp ist eine Unterart des Publish-/Subscribe-Verbindungstyps und erbt damit sämtliche Eigenschaften dieses Publish-/Subscribe-Verbindungstyps. Außerdem können noch weitere Typen (etwa überwachte Writer-Gruppen-Typen/überwachte Reader-Gruppen-Typen) an den Publish-/Subscribe-Verbindungstyp angehängt werden. Eine Instanz des Publish-/Subscribe-Verbindungstyps kann sowohl standardgemäße, konventionelle als auch im Sinne der Erfindung überwachte Gruppentypen zugeordnet bekommen. Das Objekt 02 - als Objekt im engeren Sinne beispielsweise eine überwachte Publish-/Subscribe-Verbindung - hat den über die Überwachungsbeziehung B4 angegebenen Typ, der durch das Objekt 05 mit der Eigenschaft E5, ein überwachter Publish-/Subscribe-Verbindungstyp, gegeben ist. Dazu weist die Überwachungsbeziehung B4 darauf hin, dass das Objekt 02 diesen Typ aufweist. Bei den Beziehungen B1, B4 handelt es sich beispielsweise um einheitlich verwendete, untereinander kompatible, sowohl in Bezug auf die Überwachungsfunktion als auch auf die Publish-/Subscribe-Datenübertragung relevante Beziehungen B1, B4 der Objekte O1, 02, 05 untereinander. In diesem Sinne gibt die Überwachungsbeziehung B1 an, dass das einer überwachten Publish-/Subscribe-Verbindungen entsprechende Objekt 02 den Typ (verkörpert durch die Eigenschaft E1) des Objektes O1 erbt und dass das Objekt O1 als (abgeleitete) Komponente eben das Objekt 02 mit den oben genannten Eigenschaften E2 aufweist.
• Das Objekt 05 mit der Eigenschaft eines überwachten Publish-/Subscribe-Verbindungstyps hat einerseits (Pfeil nach oben) einen durch die Überwachungsbeziehung B14 gegebenen Untertypen einer Publish-/Subscribe-Verbindungsart, die wiederum durch die Eigenschaft E4 des Objektes 04 repräsentiert wird. Auf derselben Ebene wie die Objekte 02, 05 sind die beiden Objekte 08, 015 dargestellt. Diese repräsentieren jeweils einen Writer-Gruppentyp über die Eigenschaft E8 bzw. einen Datensatz-Writer-Typ über die Eigenschaft 15.
• Zunächst einmal hat das Typ-Definitions-Objekt 05, repräsentiert durch die Überwachungsbeziehungen B6, B5 jeweils zwei Komponenten; über die Überwachungsbeziehung B5 wird dem Typ-Definitions-Objekt 05 eine Komponente zugewiesen, die durch das Objekt 06 repräsentiert ist; dabei kann es sich um ein Objekt im engeren Sinne handeln, welches als instanziertes Objekt eine Writer-Gruppe darstellt und als Eigenschaft E6 einen überwachten Publish-/Subscribe-Writer-Gruppen-Typ und eine entsprechende Writer-Gruppen-Bezeichnung aufweist.
• Das überwachte Publish-/Subscribe-Verbindungs-Typ-Objekt 05 hat einerseits die Komponenten-Beziehung B5, über welche eine überwachte Writer-Gruppe 06 (etwa als instanziertes Objekt 06 im engeren Sinne) als Komponente des überwachten Publish-/Subscribe-Verbindung-Typ-Objekts 05 definiert ist. Die überwachte Writer-Gruppe 06 hat dabei die überwachte Writer-Gruppen-Eigenschaft E6 und gegebenenfalls einen Writer-Gruppen-Bezeichner (der in der 4 nicht explizit gezeigt ist). Die überwachte Writer-Gruppe 06 stellt ebenfalls ein im Erfindungssinne überwachtes Objekt dar. Andererseits weist das überwachte Publish-/Subscribe-Verbindungs-Typ-Objekt 05 die Komponenten-Beziehung B6 auf, über welche eine überwachende Reader-Gruppe 07 als Komponente des überwachten Publish-/Subscribe-Verbindungs-Typ-Objekts 05 definiert ist. Die überwachende Reader-Gruppe 07 hat dabei die überwachende Reader-Gruppen-Eigenschaft E7 und gegebenenfalls einen Reader-Gruppen-Bezeichner (der ebenfalls in der 4 nicht explizit gezeigt ist). Die überwachende Reader-Gruppe 07 stellt ebenfalls ein Überwachungsobjekt (und zwar ein im Erfindungssinne überwachendes Objekt) dar.
• Die überwachte Writer-Gruppe 06 hat über die Typ-Definitions-Beziehung B15 das überwachte Writer-Gruppen-Typ-Objekt 09 zugeordnet, welches den überwachten Writer-Gruppen-Typ E9 aufweist. Dieser überwachte Writer-Gruppen-Typ E9 ist ein Untertyp des (beispielsweise im Datenaustauschstandard konventionell vorgesehenen) Writer-Gruppen-Typs E8. Er gruppiert die Instanzen von überwachten Datensatz-Writer-Typen. Über die Untertypen-Beziehung B7 ist modelliert, dass die oben genannte Untertypen-Beziehung B7 zwischen dem überwachten Writer-Gruppen-Typ-Objekt 09 und dem Writer-Gruppen-Typ-Objekt 08 besteht. Das Writer-Gruppen-Typ-Objekt 08 hat dabei den Writer-Gruppen-Typ E8. Das überwachte Writer-Gruppen-Typ-Objekt 09 verweist auf einen überwachten Datensatz-Writer 012 mit der überwachten Datensatz-Writer-Eigenschaft E12. Durch die Typ-Definitions-Beziehung B17 wird klargestellt, dass der überwachte Datensatz-Writer 012 den überwachten Datensatz-Writer-Typ E16 des überwachten Datensatz-Writer-Typ-Objekts 016 aufweist. Bei diesem überwachten Datensatz-Writer-Typ E16 handelt es sich um einen Untertypen des Datensatz-Writer-Typs E15 des Datensatz-Writer-Typ-Objekts 15, was durch die Untertypen-Beziehung B9 symbolisiert ist. Damit erbt der überwachte Datensatz-Writer-Typ E16 sämtliche Eigenschaften des Datensatz-Writer-Typen E15. Außerdem schränkt er gewisse Konfigurationsmöglichkeiten (beispielsweise Transporteinstellungen oder Netzwerknachrichten-Einstellungen) ein, da das Konzept der erfindungsgemäß überwachten Verbindung auf einer brokerlosen Kommunikation, basierend auf den Transporteigenschaften des OPC-UA Ethernet oder OPC-UA-UDP (User Datagram Protocol) basiert sowie auf den Netzwerknachrichten-Einstellungen gemäß UADP. Der überwachte Datensatz-Writer-Typ E16 hat außerdem über die virtuelle Reader-Beziehung B11 eine weitere Referenztyp-Definition, die angibt, dass ein virtueller Datensatz-Reader besteht; die Referenztyp-Definition zeigt dabei auf einen virtuellen Datensatz-Reader. Dies ist in der 4 dadurch symbolisiert, dass die entsprechende virtuelle Reader-Beziehung B11 auf das virtuelle Datensatz-Reader-Typ-Objekt 018 mit dem virtuellen Datensatz-Reader-Typ E18 zeigt.
• Der virtuelle Datensatz-Reader-Typ E18 ist (angezeigt durch die Untertypen Beziehung B13) ein Untertyp des überwachenden Datensatz-Reader-Typs E17 (siehe weiter unten) und erbt damit sämtliche Eigenschaften dieses Typs. Außerdem kann der virtuelle Datensatz-Reader-Typ E18 weitere Informationen über die Dienstgüte (QoS Quality of Service) einer Publish-/Subscribe-Verbindungen in einem OPC-UA-Server darstellen.
• Die überwachende Reader-Gruppe 07 hat über die Typ-Definitions-Beziehung B16 das überwachende Reader-Gruppen-Typ-Objekt O10 zugeordnet, welches den überwachenden Reader-Gruppen-Typ E10 aufweist. Dieser überwachende Reader-Gruppen-Typ E10 ist - symbolisiert durch die Untertypen-Beziehung B8 - ein Untertyp eines Reader-Gruppen-Typs E11 eines Reader-Gruppen-Typ-Objekts O11. Er gruppiert die Instanzen von überwachenden Datensatz-Reader-Typen. Das überwachte Reader-Gruppen-Typ-Objekt O10 verweist auf einen überwachenden Datensatz-Reader 013 mit der überwachenden Datensatz-Reader-Eigenschaft E13. Durch die Typ-Definitions-Beziehung B18 wird klargestellt, dass der überwachende Datensatz-Reader 013 den überwachenden Datensatz-Reader-Typ E17 des überwachenden Datensatz-Reader-Typ-Objekts 017 aufweist; bei diesem überwachenden Datensatz-Reader-Typ E17 handelt es sich um einen Untertypen des Datensatz-Reader-Typs E14 des Datensatz-Reader-Typ-Objekts 014, was durch die Untertypen-Beziehung B10 symbolisiert ist. Damit erbt der überwachende Datensatz-Reader-Typ E17 sämtliche Eigenschaften des Datensatz-Reader-Typs E14, außerdem schränkt er wiederum gewisse Konfigurationsmöglichkeiten (beispielsweise Transporteinstellungen oder Netzwerknachrichten-Einstellungen) ein, da das Konzept der erfindungsgemäß überwachten Verbindung auf einer brokerlosen Kommunikation, basierend auf den Transporteigenschaften des OPC-UA Ethernet oder OPC-UA-UDP (User Datagram Protocol) basiert sowie auf den Netzwerknachrichten-Einstellungen gemäß UADP. Der überwachende Datensatz-Reader-Typ E17 hat eine weitere Referenztyp-Definition, die angibt, dass ein virtueller Datensatz-Reader (entsprechend einem erfindungsgemäßen Zustandsmodell) aktualisiert wird; die Referenztyp-Definition zeigt dabei auf den entsprechenden virtuellen Datensatz-Reader. Dies ist in der 4 dadurch symbolisiert, dass die entsprechende virtuelle Reader-Beziehung B12 auf das virtuelle Datensatz-Reader-Typ-Objekt 018 mit dem virtuellen Datensatz-Reader-Typ E18 zeigt.
• Bezugszeichenliste

2

mechatronisches System

3

Netzwerk

4

Maschinensteuerung

7

Remote-Netzwerkteilnehmer

8

Primärkanal

9

Sekundärkanal

10

Übertragungsprotokoll

20

erweitertes Übertragungsprotokoll

21

Datenaustauschstandard (OPC-UA-Stack)

22

OPC-UA-Informationsmodell (erweitertes Informationsmodell)

23

erweiterte Zustandsmaschine

Rn

Reader Nummer n

Wn

Writer Nummer n

Pn

Publisher Nummer n

Sn

Subscriber Nummer n

Vn

Zustandsmodell Nummer n

On

Objekt Nummer n

O1

Publish-/Subscribe-Typ-Objekt (PublishSubscribe)

02

überwachte Publish-/Subscribe-Verbindung (MonitoredPubSubConnection)

03

Publish-/Subscribe-Verbindung (PubSubConnectionType)

04

Publish-/Subscribe-Verbindungs-Typ-Objekt (PubSubConnectionType)

05

überwachter Publish-/Subscribe-Verbindungs-Typ-Objekt (Monitored PubSubConnectionType)

O6

überwachte Writer-Gruppe (MonitoredWriterGroup)

O7

überwachende Reader-Gruppe (MonitoringReaderGroup)

O8

Writer-Gruppen-Typ-Objekt (WriterGroupType)

O9

überwachte Writer-Gruppen-Typ-Objekt (MonitoredWriterGroupType)

O10

überwachende Reader-Gruppen-Typ-Objekt (Monitored ReaderGroupType)

O11

Reader-Gruppen-Typ-Objekt (ReaderGroupType)

012

überwachter Datensatz-Writer (MonitoredDataSetWriter)

013

überwachender Datensatz-Reader (MonitoringDataSetReader)

014

Datensatz-Reader-Typ-Objekt (DataSetReaderType)

015

Datensatz-Writer-Typ-Objekt (DataSetWriterType)

016

überwachter Datensatz-Writer-Typ-Objekt (MonitoredDataSetWriterType)

017

überwachender Datensatz-Reader-Typ-Objekt (MonitoringDataSetReaderType)

018

virtueller Datensatz-Reader-Typ-Objekt (VirtualDataSetReaderType)

En

Überwachungseigenschaft Nummer n

E1

Publish-/Subscribe-Typ (PublishSubscribe)

E2

überwachte Publish-/Subscribe-Verbindungs-Eigenschaft(en) (Monitored PubSubConnection)

E3

Publish-/Subscribe-Verbindungs-Eigenschaft(en) (PubSubConnectionType)

E4

Publish-/Subscribe-Verbindungs-Typ (PubSubConnectionType)

E5

überwachter Publish-/Subscribe-Verbindungs-Typ (MonitoredPubSubConnectionType)

E6

überwachte Writer-Gruppen-Eigenschaft (MonitoredWriterGroup)

E7

überwachende Reader-Gruppen-Eigenschaft (MonitoringReaderGroup)

E8

Writer-Gruppen-Typ (WriterGroupType)

E9

überwachter Writer-Gruppen-Typ (MonitoredWriterGroupType)

E10

überwachender Reader-Gruppen-Typ (Monitored ReaderGroupType)

E11

Reader-Gruppen-Typ (ReaderGroupType)

E12

überwachter Datensatz-Writer-Eigenschaft (MonitoredDataSetWriter)

E13

überwachender Datensatz-Reader-Eigenschaft (MonitoringDataSetReader)

E14

Datensatz-Reader-Typ (DataSetReaderType)

E15

Datensatz-Writer-Typ (DataSetWriterType)

E16

überwachter Datensatz-Writer-Typ (MonitoredDataSetWriterType)

E17

überwachender Datensatz-Reader-Typ (MonitoringDataSetReaderType)

E18

virtueller Datensatz-Reader-Typ (VirtualDataSetReaderType)

Bn

Überwachungsbeziehung Nummer n

B1

Komponenten-Beziehung (HasComponent)

B2

Komponenten-Beziehung (HasComponent)

B3

Typ-Definitions-Beziehung (HasTypeDefinition)

B4

Typ-Definitions-Beziehung (HasTypeDefinition)

B5

Komponenten-Beziehung (HasComponent)

B6

Komponenten-Beziehung (HasComponent)

B7

Untertypen-Beziehung (HasSubtype)

B8

Untertypen-Beziehung (HasSubtype)

B9

Untertypen-Beziehung (HasSubtype)

B10

Untertypen-Beziehung (HasSubtype)

B11

virtueller Reader-Beziehung (HasVirtuaIReader)

B12

virtueller Reader-Beziehung (HasVirtuaIReader)

B13

Untertypen-Beziehung (HasSubtype)

B14

Untertypen-Beziehung (HasSubtype)

B15

Typ-Definitions-Beziehung (HasTypeDefinition)

B16

Typ-Definitions-Beziehung (HasTypeDefinition)

B17

Typ-Definitions-Beziehung (HasTypeDefinition)

B18

Typ-Definitions-Beziehung (HasTypeDefinition)

• ZITATE ENTHALTEN IN DER BESCHREIBUNG
• Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
• Zitierte Patentliteratur
• DE 102018216111 [0002]

Claims (12)

1. Verfahren der Kommunikation von Maschinensteuerungsdaten eines mechatronischen Systems (2) in einem Netzwerk (3) mit mindestens einer Maschinensteuerung (4), mittels eines Datenaustauschstandards (21), der ein Publish-/Subscribe-Kommunikationsmodell unterstützt, bei dem Publisher (Pn) und Subscriber (Sn) entkoppelt sind; wobei die Maschinensteuerung (4) im Rahmen des Publish-/Subscribe-Kommunikationsmodells von einem Remote-Netzwerkteilnehmer (7) die Maschinensteuerungsdaten bezieht, dadurch gekennzeichnet, dass der Bezug der Steuerungsdaten mittels einer Publish-/Subscribe-Datenübertragung von Überwachungsinformationen überwacht wird und die Überwachung mittels einheitlich verwendeter, kompatibler, jeweils sowohl für die Überwachungsfunktion als auch für die Publish-/Subscribe-Datenübertragung charakteristischer Objekte (On) erfolgt.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Überwachung mittels einheitlich verwendeter, untereinander kompatibler, sowohl für die Überwachung als auch für die Publish-/Subscribe-Datenübertragung charakteristischer Eigenschaften (En) der Objekte (Überwachungseigenschaften) erfolgt.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Überwachung mittels einheitlich verwendeter, untereinander kompatibler, sowohl in Bezug auf die Überwachungsfunktion als auch auf die Publish-/Subscribe-Datenübertragung relevanter Beziehungen (Bn) der Objekte untereinander (Überwachungsbeziehungen) erfolgt.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass die Objekte (On) und/oder Überwachungseigenschaften (En) nach Anspruch 2 und/oder Überwachungsbeziehungen (Bn) nach Anspruch 3 im Rahmen des Datenaustauschstandards (21), insbesondere in einem Informationsmodell (22) des Datenaustauschstandards (21), standardisiert sind.
5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die Objekte (On) und/oder die Überwachungseigenschaften (En) und/oder die Überwachungsbeziehungen (Bn) jeweils von entsprechenden Objekten bzw. Eigenschaften bzw. Beziehungen des Publish-/Subscribe-Kommunikationsmodells abgeleitet sind und insbesondere die Eigenschaften und/oder Beziehungen im Rahmen des Publish-/Subscribe-Kommunikationsmodells erben.
6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass die Maschinensteuerung (4) wahlfrei als Publisher (P2) und/oder als Subscriber (S1) zu betreiben ist, wobei die Maschinensteuerung (4) in ihrer Subscriber-Funktion (S1) die Steuerungsdaten mittels des Datenaustauschstandards von einem Remote-Publisher (P1) des Remote-Netzwerkteilnehmers (7) über das Netzwerk (3) bezieht bzw. in ihrer Publisher-Funktion (P2) Daten (1) über das Netzwerk (3) senden kann, und wobei die Maschinensteuerung (4) in ihrer Subscriber-Funktion (S1) eine zusätzliche, mit der Subscriber-Funktion korrespondierende Publisher-Funktion (P2) hat, mittels derer die Maschinensteuerung (4) Subscriber-Daten über das Netzwerk (3) sendet, die über eine mit dem Remote-Publisher (P1) korrespondierende Remote-Subscriber-Funktion (S2) zu beziehen sind, und der Bezug der Steuerungsdaten mittels der Übertragung der Subscriber-Daten zu überwachen ist.
7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass die Subscriber-Daten zusätzlich Steuerungsdaten der Maschinensteuerung (4) und/oder Statusdaten der Maschinensteuerung (4) und/oder Heartbeat-Daten und/oder Daten nach Art eines Rückkanals einer industriellen Automatisierungs-Feldbus-Architektur umfassen.
8. Verfahren nach Anspruch 6 oder 7, dadurch gekennzeichnet, dass die Maschinensteuerung (4) und der Remote-Netzwerkteilnehmer (7) Steuerungsdaten austauschen und/oder Statusdaten einen Gerätestatus der Maschinensteuerung (4) bzw. des Remote-Netzwerkteilnehmers (7) betreffend und/oder Kommunikations-Metadaten und/oder Netzverbindungs-Statusdaten, wie etwa Dienstgütedaten, und/oder Identifikationsdaten der Maschinensteuerung (4) oder einer der Maschinensteuerung (4) zugehörigen, logischen Einheit (Rn,Wn), bzw. des Remote-Netzwerkteilnehmers (7) oder einer dem Remote-Netzwerkteilnehmer zugehörenden, logischen Einheit (Rn, Wn).
9. Verfahren nach einem der Ansprüche 6 bis 8, dadurch gekennzeichnet, dass ein Publisher (Pn) gemäß dem Datenaustauschstandard einen oder mehrere, vorgeschaltete, physikalische, logische oder virtuelle Schreibeeinheit(-en) (Wn) (Writer) aufweist, die die zu übertragenden Daten bereitstellt/bereitstellen, und dass ein Subscriber (Sn) gemäß dem Datenaustauschstandard einen oder mehrere, nachgeordnete, physikalische, logische oder virtuelle Leseeinheit(-en) (Rn) (Reader) aufweist, die die bezogenen Daten ausliest/auslesen, wobei die Objekte (On) und/oder Überwachungseigenschaften (En) und/oder Überwachungsbeziehungen (Bn) der Objekte untereinander für jeweils einen Writer (Wn) und/oder einen Reader (Rn) relevant sind.
10. Verfahren nach einem der Ansprüche 6 bis 9, dadurch gekennzeichnet, dass mittels der Überwachung ein virtuelles, aktuelles Zustandsmodell (Vn) des Subscribers (Sn) und/oder der Maschinensteuerung (4) und/oder einer physikalischen oder logischen Komponente (Rn) des Subscribers (Sn) erzeugbar und insbesondere zyklisch aktualisierbar ist und wobei die Objekte (On) und/oder Überwachungseigenschaften (En) und/oder Überwachungsbeziehungen (Bn) für das Zustandsmodell (Vn) relevant sind.
11. Netzwerkfähige Maschinensteuerung (4), insbesondere speicherprogrammierbare Steuerung (SPS), oder netzwerkfähige Rechnereinrichtung mit virtueller oder emulierter Maschinensteuerung, die dazu eingerichtet ist, ein Verfahren nach einem der Ansprüche 1 bis 10 auszuführen.
12. Computerprogrammprodukt für eine Rechnereinrichtung, insbesondere für eine netzwerkfähige Maschinensteuerung (4), welches bei Ausführung auf einer Rechnereinrichtung ein Verfahren nach einem der Ansprüche 1 bis 10 ausführt.

Images