DE102019219023A1 - Übertragungsverfahren - Google Patents

Übertragungsverfahren Download PDF

Info

Publication number
DE102019219023A1
DE102019219023A1 DE102019219023.5A DE102019219023A DE102019219023A1 DE 102019219023 A1 DE102019219023 A1 DE 102019219023A1 DE 102019219023 A DE102019219023 A DE 102019219023A DE 102019219023 A1 DE102019219023 A1 DE 102019219023A1
Authority
DE
Germany
Prior art keywords
data
subscriber
network
machine control
publisher
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102019219023.5A
Other languages
English (en)
Inventor
Johannes Von Hoyningen-Huene
Frederick Prinz
Andreas Eckhardt
Sebastian Mueller
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch GmbH filed Critical Robert Bosch GmbH
Priority to DE102019219023.5A priority Critical patent/DE102019219023A1/de
Publication of DE102019219023A1 publication Critical patent/DE102019219023A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/163—Interprocessor communication
    • G06F15/173—Interprocessor communication using an interconnection network, e.g. matrix, shuffle, pyramid, star, snowflake
    • G06F15/17306—Intercommunication techniques
    • G06F15/17325—Synchronisation; Hardware support therefor

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)

Abstract

Die Erfindung betrifft ein Verfahren der Kommunikation von Maschinensteuerungsdaten (1) eines mechatronischen Systems (2) in einem Netzwerk (3) mit mindestens einer Maschinensteuerung (4), mittels eines Datenaustauschstandards, der ein Publish-/Subscribe-Kommunikationsmodell unterstützt, bei dem Publisher (Pn) und Subscriber (Sn) entkoppelt sind; wobei die Maschinensteuerung (4) wahlfrei als Publisher (P2) und/oder als Subscriber (S1) zu betreiben ist, und wobei die Maschinensteuerung (4) in ihrer Subscriber-Funktion (S1) Steuerungsdaten (1) mittels des Datenaustauschstandards von einem Remote-Publisher (P1) über das Netzwerk (3) bezieht bzw. in ihrer Publisher-Funktion (P2) Steuerungsdaten (1) über das Netzwerk (3) sendet. Um das Verfahren für eine zuverlässigere oder synchronisierbare Funktion in einem Automatisierungsnetzwerk zu befähigen, hat die Maschinensteuerung (4) in ihrer Subscriber-Funktion (S1) eine zusätzliche, mit der Subscriber-Funktion korrespondierende Publisher-Funktion (P2), mittels derer die Maschinensteuerung (4) Subscriber-Daten (5) über das Netzwerk (3) sendet, die über eine mit dem Remote-Publisher (P1) korrespondierende Remote-Subscriber-Funktion (S2) zu beziehen sind.

Description

  • Die vorliegende Erfindung betrifft ein Verfahren der Kommunikation von Maschinensteuerungsdaten eines mechatronischen Systems in einem Netzwerk mit mindestens einer Maschinensteuerung, das sich eines Datenaustauschstandards bedient, der ein Publish-/Subscribe-Kommunikationsmodell unterstützt. Nach dem genannten Datenaustauschstandard sind Publisher und Subscriber voneinander entkoppelt, sofern die standardgemäß vorgesehene Kommunikation unverändert zum Einsatz kommt. Des Weiteren ist die Maschinensteuerung wahlfrei als Publisher und/oder als Subscriber zu betreiben, und die Maschinensteuerung bezieht in ihrer Subscriber-Funktion Steuerungsdaten mittels des Datenaustauschstandards von einem Remote-Publisher über das Netzwerk bzw. sendet in ihrer Publisher-Funktion Steuerungsdaten ebenfalls über das Netzwerk oder jeweils über ein ausgewähltes Netzwerksegment.
  • Ein solches Verfahren ist in der nicht vorveröffentlichten, deutschen Patentanmeldung DE102018216111.9 beschrieben. Dort ist vorgesehen, dass die Maschinensteuerung sowohl als Publisher als auch als Subscriber fungieren und somit Daten, insbesondere Steuerungsdaten, sowohl über das Netzwerk versenden als auch aus dem Netzwerk empfangen kann. Ein solches Verfahren ist schlank und flexibel, aber aufgrund der standardgemäß entkoppelten Kommunikation im Hinblick auf die 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 für eine zuverlässigere oder synchronisierbare Funktion in einem Automatisierungsnetzwerk zu befähigen.
  • Diese Aufgaben werden jeweils teilweise oder vollständig gelöst durch ein Verfahren nach Anspruch 1, eine Maschinensteuerung oder Rechnereinrichtung nach Anspruch 15 und ein Computerprogrammprodukt nach Anspruch 16.
  • 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. Mittels der Erfindung kann sogar - obwohl dies standardgemäß in dem Publish-/Subscribe-Kommunikationsmodell nicht vorgesehen ist - eine gewisse Kopplung von Netzwerkteilnehmern erfolgen, die in ihren Eigenschaften, wie zum Beispiel der Kopplungsstärke, bedarfsgerecht und flexibel konfigurierbar ist,, d. h. vor allem hinsichtlich der Zeitkonstante der Kopplung, des Umfangs der zu koppelnden Funktionen/Daten, der Zykluszeit, mit der der Austausch der Daten zur Kopplung erfolgt sowie der Anzahl und Direktionalität der Kopplungsstrecken (unidirektional/bidirektional).
  • Die Erfindung hat 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.
  • Durch die vorgeschlagene Erweiterung des OPC-UA Publish-Subscribe-Protokolls kann der Status eines Subscribers/Readers (siehe dazu weiter unten) übertragen werden. Dadurch 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. Durch die virtuellen Reader kann der Zustand eines Readers eines anderen Geräts im OPC UA Server abgebildet werden. Das wird weiter unten noch eingehender beschrieben.
  • Die Erfindung erreicht diese Vorteile dadurch, dass die Maschinensteuerung in ihrer Subscriber-Funktion eine zusätzliche Publisher-Funktion hat. 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).
  • Dazu kann die Maschinensteuerung, die technisch wahlfrei als Publisher und gleichzeitig als Subscriber betreibbar ist, 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.
  • 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 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 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 die Maschinensteuerung zur Kommunikation der Steuerungsdaten wahlfrei als Subscriber und/oder als Publisher einer Publish-/Subscribe-Kommunikationsarchitektur konfiguriert werden kann. 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 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 des 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 des 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.
  • 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 wahlfrei als Publisher und/oder als Subscriber kann beispielsweise in einer Firmware und/oder in einer Maschinensteuerungsapplikation der Maschinensteuerung vorgesehen sein, sodass 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.
  • Bevorzugte Ausgestaltungen, die den Gegenstand der Erfindung nicht einschränken, sind in den Unteransprüchen beschrieben.
  • Die schnelle und schlanke Netzwerkkommunikation im Rahmen des Publish-/Subscribe-Kommunikationsmodells ermöglicht es, Steuerungsdaten mit einer Qualität, Verfügbarkeit und Schnelligkeit bzw. Zyklizität zu übertragen, die einem industriellen Feldbus, wie beispielsweise SERCOS, Profibus bzw. Profinet oder EtherCAT entspricht oder diesen übertrifft. Die Erfindung ermöglicht darüber hinaus eine komplette Deterministik der Kommunikation sowie eine sichere, insbesondere ausfallsichere und zuverlässige Kommunikation in industriellen Automatisierungsanlagen dadurch, dass der Bezug der Steuerungsdaten mittels der Übertragung der Subscriber-Daten zu überwachen ist. Dann wird die Kommunikationsstrecke Remote-Publisher zu Subscriber der Maschinensteuerung zur Übertragung der Steuerungsdaten verwendet und gleichzeitig auf Vorhandensein, Fehlerfreiheit bzw- - anfälligkeit, Kommunikations-Verbindungsqualität, Dienstgüte, Übertragungsgeschwindigkeit, Leitungsbruch und anderes überwacht. Dadurch wird auch sichergestellt, dass die Steuerungsdaten digital unverändert beim Subscriber ankommen. Dazu enthalten die Subscriber-Daten Überwachungsinformationen. Diese Überwachungsinformationen können etwa eine Rückmeldung an den Remote-Publisher enthalten, ob und welche der Steuerungsdaten empfangen wurden und/oder ob oder wie viele Datenpakete gegebenenfalls ausgefallen sind. Es ist sogar im Rahmen der Erfindung ohne weiteres möglich, etwa ausgefallene Datenpakete zurückzumelden und gegebenenfalls sogar die entsprechenden Steuerungsdaten gezielt/erneut anzufordern vom Remote-Publisher. Dies im Rahmen einer einfachen, sehr schnellen und schlanken Publish-Subscribe-Kommunikationsarchitektur zu bewerkstelligen, ist mit der Erfindung nun erstmals möglich.
  • 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. Dabei ist die Maschinensteuerung zunächst für den Bezug der Steuerungsdaten vom Remote-Publisher als Subscriber konfiguriert und der Remote-Netzwerkteilnehmer als Remote-Publisher, der Steuerungsdaten publiziert. Die bidirektionale Kommunikation weist jeweils für die Maschinensteuerung und den Remote-Netzwerkteilnehmer einen Hin-Kanal und einen RückKanal auf. Insbesondere umfasst die bidirektionale Kommunikationstopologie zumindest einen Primärkanal, über den der Remote-Netzwerkteilnehmer (insbesondere über seinen Remote-Publisher) Steuerungsdaten sendet und die Maschinensteuerung (insbesondere über ihren Subscriber) Steuerungsdaten empfängt, und einen Sekundärkanal, über den die Maschinensteuerung (insbesondere über ihren Publisher) Subscriber-Daten sendet und der Remote-Netzwerkteilnehmer (insbesondere über seinen Remote-Subscriber) Subscriber-Daten empfängt.
  • In der genannten bidirektionalen Kommunikationskonfiguration sind damit jeweils (etwa zwei) Kommunikationskanäle definiert, die mittels der erfindungsgemäßen Nutzung der Publish-/Subscribe-Kommunikationsarchitektur des Datenaustauschstandards sehr schlank und schnell ausgestaltet sind. Erfindungsgemäß kann es nunmehr realisiert werden, dass eine flexible und dem jeweiligen Bedarf optimal angepasste Überwachung erreicht wird. Dazu wird vorgeschlagen, dass die Maschinensteuerung und der Remote-Netzwerkteilnehmer Überwachungsdaten zumindest eines der oben genannten Kanäle austauschen. Überwachungsdaten sind insbesondere Zustandsdaten oder Qualitätsdaten oder sämtliche hierin genannten Subscriber-Datenarten, die sich auf den jeweils zu überwachenden Kanal beziehen. Bevorzugt ist dabei, dass Überwachungsdaten des Primärkanals (das ist dann der überwachte Kanal) über den Sekundärkanal (das ist dann der überwachende Kanal bzw. der für die Übertragung der Überwachungsinformationen verwendete Kanal) übertragen werden. Zum Beispiel enthalten die Subscriber-Daten Überwachungsinformationen bzw. Überwachungsdaten bezogen auf den Primärkanal und werden über den Sekundärkanal übertragen.
  • 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.
  • Um die zur Verfügung stehende, physikalische Bandbreite im erfindungsgemäßen Sinne effizient auszunutzen und eine Übertragung mit hoher, resultierender Netto-Bandbreite zu gewährleisten, wird vorgeschlagen, dass die Kommunikation der Steuerungsdaten und/oder der Subscriber-Daten mittels eines standardisierten, inhärent verbindungsfreien und/oder inhärent kopplungsfreien Übertragungsprotokolls erfolgt. Dies kann erfindungsgemäß bedeuten, dass etwa zwischen der Maschinensteuerung und dem Remote-Netzwerkteilnehmer keine TCP/IP-Verbindungen bzw. allgemeiner gesagt keine Client-/Server-Verbindungen etabliert werden. Dadurch wird signifikanter Kommunikations-Overhead (und zwar sowohl in zeitlicher wie auch in kapazitiver Hinsicht) eingespart, wobei es die Erfindung ermöglicht, trotz eines solchen, minimalen Kommunikationsprotokolls bzw. Kommunikations-Protokollstacks eine Automatisierungs-Infrastruktur trotzdem sehr systemtreu durch eine erfindungsgemäße Topologie bzw. ein erfindungsgemäßes Verfahren abzubilden. Dafür wird beispielsweise ein UDP (User Datagram Protocol)-basiertes Übertragungsprotokoll verwendet. Dabei handelt es sich um ein standardisiertes, kopplungsfreies, minimales Übertragungsprotokoll, welches die erfindungsgemäßen Vorteile unterstützt bzw. erreicht. Insbesondere werden mittels eines verwendeten Übertragungsprotokolls individuelle Netzwerknachrichten (Telegramme) in einem standardisierten Format übertragen. Bei dieser Übertragung - die vorzugsweise zyklisch und/oder in Echtzeit und/oder deterministisch erfolgt - werden in einem definierten Zeitschlitz wiederholt Telegramme mit Inhalten übertragen, wobei der Zeitschlitz eines Telegramms in standardisierte, dedizierte Unter-Zeitschlitze aufgeteilt ist, die zur Aufnahme von jeweils standardgemäß vorgesehenen, dedizierten Datenelementen vorgesehen sind (hierauf wird weiter unten noch näher eingegangen).
  • Besonders effizient, ressourcenschonend und zeitsparend ist es, wenn ein Übertragungs-Indikator in einem unter dem Übertragungsprotokoll übertragenen Telegramm das Vorhandensein von Subscriber-Daten in einem Nutzdatenabschnitt des Telegramms angibt. Minimal ist der Signalisierungsmechanismus, wenn lediglich ein Signalisierungsbit, insbesondere ein standardmäßig nicht belegtes oder reserviertes Bit eines Header-Abschnitts dazu verwendet wird. Da es sich bei der Information um eine 1-Bit-lnformation bzw. Ja/Nein-Information handelt, ist ein solches Signalisierungsbit grundsätzlich ausreichend. Dabei erfolgt die weitere Auswertung der Subscriber-Daten in einem nachfolgenden Verarbeitungsschritt lediglich, wenn das Vorhandensein von Subscriber-Daten entsprechend durch den Übertragungs-Indikator angezeigt ist. Ansonsten kann eine Kapazität beanspruchende Bearbeitung bzw. Suche oder Identifikation von Subscriber-Daten unterbleiben, wenn der Übertragungs-Indikator indiziert, dass dem Nutzdatenabschnitt des Telegramms ohnehin keine Subscriber-Daten eingeschrieben sind. Unter dem UDP-Standard sind solche nicht belegten Bits eines standardgemäßen Header-Abschnitts regelmäßig vorgesehen. Auf die Details zu der standardkonformen Ausgestaltung wird weiter unten noch näher eingegangen. Insbesondere ist ein solcher Übertragungs-Indikator für jede einzelne (insbesondere zyklisch übertragene) Netzwerknachricht vorhanden. Des Weiteren ist es vorteilhaft, wenn der Übertragungs-Indikator - in der zeitlichen Abfolge der Übertragung der Netzwerknachricht bzw. des Zeitschlitzes gesehen - vor dem Nutzdatenabschnitt des entsprechenden Telegramms bzw. der entsprechenden Netzwerknachricht angeordnet ist. Dann kann bereits bei der Übertragung bzw. beim Auslesen des Nutzdatenabschnitts das Vorhandensein oder Nichtvorhandensein von Subscriber-Daten entsprechend ressourcenschonend und zeitsparend berücksichtigt werden.
  • Eine deterministische und echtzeitkonforme Übertragung wird dadurch unterstützt, dass ein unter dem Datenaustauschstandard und/oder dem Übertragungsprotokoll standardisierter Subscriber-Daten-Abschnitt des Nutzdatenabschnitts alle oder zumindest ausgewählte Subscriber-Daten aufweist. Dann ist der Subscriber-Daten-Abschnitt ein Unter-Zeitschlitz des Nutzdaten-Zeitschlitzes des standardisierten Übertragungsprotokolls. Wenn etwa eine standardisierte Position und/oder eine standardisierte (Maximal-) Länge des Subscriber-Daten-Abschnitts des Nutzdatenabschnitts vorgesehen ist, ist das Auslesen bzw. Einschreiben der Subscriber-Daten standardisiert und interoperabel zwischen verschiedenen Geräten eines Netzwerks oder Netzwerksegments durchführbar.
  • Von der erfindungsgemäßen, schlanken Netzwerk-Infrastruktur sowie den variablen Konfigurationsmöglichkeiten und der systemtreuen Abbildung eines industriellen Automatisierungssystems wird besonders effizient Gebrauch gemacht, wenn die Subscriber-Daten einzeln oder in beliebiger Kombination folgendes umfassen:
    • - Identifikationsdaten des Remote-Publishers, von dem die Steuerungsdaten bezogen werden; dies können beispielsweise codierte Gerätedaten, wie eine Seriennummer oder eine variabel zugeordnete Netzwerk-Identifikationsnummer, wie beispielsweise eine IP-Adresse oder eine physische oder Geräteadresse, insbesondere MAC-Adresse (Media-Access-Control-Adresse), sein
    • - Statusangaben, die für den Bezugsstatus der Steuerungsdaten in der Maschinensteuerung relevant sind; solche Statusangaben können - neben den oben genannten Statusdaten - einen Online-/Offline-Status, einen Fehlerstatus oder auch allgemeine Betriebsstatusdaten umfassen
    • - Betriebsdaten, insbesondere Steuerungsdaten, der Maschinensteuerung; davon können etwa Sollwerte, Istwerte, aber auch physikalische Daten einer Maschine der Industrieautomatisierung, wie zum Beispiel Achsgeschwindigkeiten, Achspositionen, Beschleunigungen, Motordrehzahlen, Motordrehmomente, aber auch Messwerte von angeschlossenen Sensoren umfasst sein.
  • Gemäß dem Datenaustauschstandard kann vorgesehen sein, dass die Funktionen des Übertragens bzw. Sendens/Empfangens und des Schreibens bzw. Auslesens von Daten 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.
  • Dabei können die Subscriber-Daten einzeln oder in beliebiger Kombination folgendes umfassen:
    • - eine Information über die Anzahl der dem Subscriber der Maschinensteuerung nachgeordneten Reader, wobei insbesondere für jeden der Reader ein vorbestimmter Anteil an zu übertragenden Subscriber-Daten allokiert bzw. im Nutzdatenabschnitt eines Netzwerktelegramms vorgesehen ist
    • - für zumindest einen bis jeden der nachgeordneten Reader jeweils einzeln oder in beliebiger Kombination
      1. i. Reader-Headerinformationen, insbesondere die Art, weiter insbesondere die Identifikationsart, des Remote-Publishers (Publisher ID Type), und/oder ein Writer-Indikator, der das Vorhandensein einer Writer-Identifikation in den Subscriber-Daten angibt und/oder ein Zustandsindikator, der das Vorhandensein einer Zustandsinformation in den Subscriber-Daten angibt und/oder Dienstgüte-Indikator, der das Vorhandensein von Dienstgüteinformationen (Quality of Service QoA) in den Subscriber-Daten angibt, wobei die entsprechenden Protokollabschnitte dann und nur dann ausgewertet werden, wenn auch entsprechende Indikatoren, insbesondere in der Form eines Indikatorbits, das Vorhandensein der entsprechenden Informationen signalisieren,
      2. ii. Identifikationsdaten (insbesondere wie oben ausgeführt) des Remote-Publishers, von dem die Steuerungsdaten bezogen werden,
      3. iii. Writer-Identifikationsdaten des Writers des Remote-Publishers, von dem die Steuerungsdaten bereitgestellt werden, insbesondere eine Writer-Identifikationsnummer, die eindeutig ist und vom System des Remote-Netzwerkteilnehmers lokal vergeben ist,
      4. iv. Zustandsdaten des Readers, die insbesondere die Eigenschaften der oben genannten Subscriber-Daten umfassen.
  • 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 13 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 13 Genannte entsprechend.
  • Es ist dabei erfindungsgemäß bevorzugt, 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.
  • 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-14 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. Alles oben Gesagte gilt entsprechend.
  • Ebenfalls gelöst werden die oben genannten Aufgaben durch ein Computerprogrammprodukt für eine Rechnereinrichtung, insbesondere für eine netzwerkfähige Maschinensteuerung nach Anspruch 15, welches bei Ausführung auf dieser Rechnereinrichtung ein Verfahren nach einem der Ansprüche 1-14 ausführt.
  • 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 Netzwerknachricht in Form eines Daten-Telegramms auf UADP-Basis, wobei die Inhalte der Netzwerknachricht/des Telegramms in einer Schichtdarstellung angegeben sind, deren Detaillierungsgrad von unten nach oben zunimmt,
    • 5 ein schematisches Anwendungsbeispiel der multidirektionalen, erfindungsgemäß überwachten Kommunikation zwischen vier Netzwerkteilnehmern, wobei die jeweiligen Netzwerkteilnehmer mit ihren internen, logischen und/oder physikalischen Komponenten gezeigt sind und ausgewählte Telegramme beispielhaft dargestellt sind.
  • 1 zeigt zunächst eine Konfiguration, wie sie einem Verfahren der Kommunikation von Maschinensteuerungsdaten 1 (siehe dazu z.B. 4) 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 1 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 1 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 5 (siehe hierzu beispielsweise 4) ü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 5 können von einem Netzwerkteilnehmer 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 5 bezieht und ebenfalls auf dem Remote-Netzwerkteilnehmer 7 - wie auch der ursprüngliche Remote-Publisher P1, von dem die originären Steuerungsdaten 1 stammen - residiert bzw. implementiert ist.
  • Insgesamt ist dadurch der Bezug der Steuerungsdaten 1 mittels der Übertragung der Subscriber-Daten 5 zu überwachen. Gleichzeitig können die Subscriber-Daten 5, die über den Sekundärkanal 9 übertragen werden, auch Steuerungsdaten 1 der Maschinensteuerung 4 und gleichzeitig Statusdaten 6 (siehe dazu etwa 4) 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 basiert und dem UADP-Standard entsprechen kann. Es kann erfindungsgemäß um Komponenten erweitert werden, die weiter unten eingehender beschrieben werden. Vorzugsweise wird für das erweiterte Übertragungsprotokoll UADP als Payload (Nutzdaten) in einem OSI-Layer 2-Frame oder UDP-Datagramm integriert.
  • 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 1 über den Primärkanal 8 und die Rückkommunikation der Subscriber-Daten 5 über den Sekundärkanal 9. Die Subscriber-Daten 5 enthalten in dieser Variante der Erfindung Statusdaten 6, die eine Überwachung der Kommunikation der Steuerungsdaten 1 bzw. des Primärkanals 8 erlauben. Die von dem Publisher P1 des Remote-Netzwerkteilnehmers 7 über den Primärkanal 8 gesendeten Steuerungsdaten 1 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,A,B,C,D, siehe dazu 5) 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 1 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 5, die Zustände des Subscribers S1 und/oder einen Empfangsstatus der Steuerungsdaten 1 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 5, insbesondere auf Zustandsdaten oder Statusdaten 6 der Übertragung der Steuerungsdaten 1, 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 5 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 5 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 1 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 1 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 1 verwendet wird; gleichermaßen können auch bei Fehlerzuständen wiederholte Aussendungen der betreffenden Steuerungsdaten 1 ü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.
  • 4 zeigt eine Netzwerknachricht 40 in Form eines Daten-Telegramms 40 auf UADP-Basis, wobei die Inhalte der Netzwerknachricht/des Telegramms 40 in einer Schichtdarstellung angegeben sind, deren Detaillierungsgrad von unten nach oben zunimmt. Dabei werden die Bezeichnungen Netzwerknachricht 40 und Telegramm 40 jeweils austauschbar verwendet. Die Netzwerknachricht 40 wird insgesamt durch den in der 4 angegebenen, unteren Block 29 repräsentiert, der - etwa bezogen auf die 3 - eine Netzwerknachricht 40 des Publishers P2, von der Maschinensteuerung 4 stammend, aufweist. Der Block 29 setzt sich zusammen aus Identifikationsdaten ID1, ID2 und einen anschließenden Nutzdatenabschnitt 14, der Subscriber-Daten 5 und Steuerungsdaten 1 aufweist.
  • In der 4 weiter von unten nach oben vorgehend (das bedeutet mit schrittweise zunehmendem Detaillierungsgrad) weist die Netzwerknachricht 40 in dem Block 29 in der zeitlichen Abfolge der Netzwerknachricht 40 von links nach rechts gesehen jeweils Identifikationsdaten ID1, ID2 auf. ID1 können dabei etwa Identifikationsdaten des Publishers P2 umfassen, ID2 Identifikationsdaten des diesem Publisher P2 zugeordneten Writers W2. Dann würde der sich rechts an D2 anschließende Nachricht-Datensatz 28 Daten aufweisen, die sich auf den Remote-Publisher P1 beziehen und/oder generell an den Remote-Netzwerkteilnehmer 7 gerichtet bzw. für diesen vorgesehen sind.
  • Im nächsten Detaillierungsschritt ist dargestellt, dass der Nachricht-Datensatz 28 einem Nachrichten-Header 46 aufweist, an den sich ein Abschnitt mit Überwachungsdaten 27 anschließt; auf diesen Überwachungsabschnitt 27 folgen Steuerungsdaten 1, dies können beispielsweise Prozessdaten, Sollwerte, Istwerte oder generell Sensorwerte oder Parameter sein, die für den Netzwerkteilnehmer bestimmt sind, auf denen der Remote-Publisher P1 implementiert ist, also etwa für den Remote-Netzwerkteilnehmer 7 bestimmte Prozessdaten. Diese Steuerungsdaten 1 unterscheiden sich insbesondere von den Subscriber-Daten 5 und den Statusdaten 6. Sie erweitern die Erfindung um eine Möglichkeit der schlanken, bidirektionalen Kommunikation und können wiederum erfindungsgemäß hinsichtlich ihres Bezugsstatus beim beziehenden Subscriber überwacht werden; dies wird weiter unten näher ausgeführt.
  • Weiter detailliert ist in der nächsten Ebene dargestellt, dass die beiden Datensatzindikatoren 47,48 den Nachrichten-Header 46 bilden. In der zeitlichen Abfolge folgt auf die beiden Datensatzindikatoren 47,48 zunächst ein Datenfeld, welches die Anzahl 24 der (insbesondere überwachten) Reader angibt und darauf ein Reader-Status 25. In dieser Darstellung sind die Steuerungsdaten 1 nicht weiter detailliert.
  • In der nächsten Detaillierungsebene ist gezeigt, dass der Nachrichten-Header 46 einem Header-Abschnitt 12 entspricht und etwa der Datensatzindikator 48 aus einem Byte, also in Einzeldarstellung 8 Bit besteht, von denen das gezeigte Bit Nummer 6 dem Übertragungs-Indikator 11 entspricht. Dieses Bit kann beispielsweise signalisieren, dass eine Statusfunktion oder Überwachungsfunktion aktiviert ist. Das Übertragungs-Indikator-Bit 11 kann ein unter dem jeweils verwendeten Transportprotokoll (z.B. UDP und OSI-Layer 2-Frame oder UADP) reserviertes oder nicht unmittelbar belegtes Bit sein, das erfindungsgemäß genutzt werden kann, ohne andere, standardmäßig für UDP oder UADP vorgesehene Funktionen zu beeinträchtigen. Bevorzugt wird dazu ein vorbestimmtes, ausgewähltes (und ggf. zu standardisierendes) Bit, etwa Bit 11 im UADP-Frameaufbau verwendet.
  • Der darauffolgende Abschnitt Anzahl 24 der Reader kann zum Beispiel aus 2 Datenbytes bestehen und ist in der Darstellung nicht weiter detailliert. Es folgen Reader-Headerinformationen 15, die - unter gleichzeitiger Bezugnahme auf diese und die nächste Detaillierung - wieder aus einem Byte, entsprechend 8 Bit bestehen kann. Diese Reader-Headerinformationen 15 können - in zeitlich bitweiser Abfolge beschrieben - zum Beispiel in den Bits Nummern 0,1 und 2 eine Identifikationsart 16 eines Publishers angeben; in dem folgenden Bit Nummer 3 in 1 Bit einen Writer-Identifikator oder Writer-Indikator 17, in Bit 4 Nummer 4 in 1 Bit einen Zustands-Indikator 18, in Bit Nummer 5 in 1 Bit einen Dienstgüte-Indikator 19. Die beiden folgenden Bits Nummern 6 und 7 können etwa ein reserviertes Bit aufweisen, das bedarfsgemäß für die Erfindung konfiguriert und verwendet werden kann sowie 1 Bit, das erweiterte Reader-Header-Informationen aufweist oder Reader-Header-Informationen 15 ergänzt oder erweitert, etwa um ein erforderlichenfalls verwendetes Signalisierungsbit.
  • Weiter in zeitlicher Abfolge an die Reader-Headerinformationen 15 anschließend ist ein Identifikationsdatum ID3 sowie ein Identifikationsdatum ID4 vorgesehen. Das Identifikationsdatum ID3 kann etwa denjenigen Publisher (im gezeigten Beispiel der 3 in Verbindung mit 4 z.B. den Remote-Publisher P1) identifizieren, auf den der entsprechende Reader gehört hat bzw. von dem der entsprechende Reader seine Daten bezogen hat. Die Identifikationsdaten ID4 beinhalten die Identifikation des entsprechenden Writers W1 des Remote-Publishers P1, so dass in der Zusammenschau eine Identifikation des Publishers bzw. Remote-Publishers P1 und gleichzeitig des betreffenden Writers W1 gegeben ist; gegebenenfalls können für einen Publisher bzw. Remote-Publisher P1 auch mehrere, logische Writer 1 vorgesehen sein, so dass die Identifikation der entsprechenden Writer für eine höhere Ausbaustufe oder eine höhere Komplexität bzw. die Möglichkeit weiterer Kommunikationskanäle vorgesehen ist.
  • Daran anschließend ist ein Slot für Statusdaten 6 (im gezeigten Ausführungsbeispiel etwa 1 Byte) vorgesehen, der die eigentlichen Statusdaten enthält. Dabei kann es sich um kodierte Statusdaten 6 handeln, die etwa anhand einer im Datenaustauschstandard global hinterlegten Codierungs-Referenz definiert sind. Daran schließen sich sonstige Reader-Statusdaten 26 an, die alle der oben genannten Inhalte, die sich auf den entsprechenden Status beziehen können, aufweisen können. Insgesamt ist also ein differenzierter Subscriber-Daten-Abschnitt 13 vorhanden, der alle oder einige ausgewählte der oben genannten Abschnitte/Daten aufweist.
  • Unter gleichzeitiger Bezugnahme auf die 3 und 4 ergibt sich vereinfacht somit folgende Beschreibung des Ablaufes der Kommunikation:
    • Die Netzwerknachricht 40 des Publishers P2 beinhaltet einen Nachricht-Datensatz 28, der von dem Writer W2 des Publishers P2 stammt, beide sind Komponenten der Maschinensteuerung 4. Der Nachricht-Datensatz 28 beinhaltet einen Status bzw. Statusdaten 6 des Readers R1 bzw. des Subscribers S1, der jeweils von Publisher P1 bzw. Writer W1 des Remote-Netzwerkteilnehmers 7 Daten bezogen hat. Zudem beinhaltet der Nachricht-Datensatz 28 Prozessdaten, also insbesondere Steuerungsdaten 1, die etwa von der Maschinensteuerung 4 selber stammen können.
  • 5 stellt ein schematisches Anwendungsbeispiel der multidirektionalen, erfindungsgemäß überwachten Kommunikation zwischen vier Netzwerkteilnehmern A, B, C, D dar, wobei die jeweiligen Netzwerkteilnehmer A, B, C, D mit ihren internen, logischen und/oder physikalischen Komponenten gezeigt sind und ausgewählte Telegramme 41, 42, 43 detailliert dargestellt sind. Die Netzwerkteilnehmer sind der einfacheren Übersicht halber als A, B, C, D bezeichnet, wobei insbesondere Netzwerkteilnehmer A dem Remote-Netzwerkteilnehmer 7 und Netzwerkteilnehmer B der Maschinensteuerung 4 entspricht. Für die Telegramme 41, 42, 43 gilt - falls nicht explizit anders ausgeführt - alles hierin bereits Gesagte entsprechend. Insbesondere sind der Aufbau und der Inhalt dieser Telegramme 41, 42,43 analog dem Telegramm 40 der 4 ausgestaltet.
  • In dem gezeigten Ausführungsbeispiel der 5 tauschen die Netzwerkteilnehmer A, B, C Prozessdaten, d. h. Steuerungsdaten 1, aus. Für diesen Austausch sind jeweils erfindungsgemäße Verbindungen gezeigt, die jeweils Subscriber-Daten 5 austauschen (siehe 4). Für die - insbesondere generalisierten - Inhalte der einzelnen Telegramme wird im Folgenden im wesentlichen Bezug genommen auf die Bezugszeichen, die in der 4 im Einzelnen die Inhalts-Slots eines typisierten Telegramms 40 angeben. Einzelne Abschnitte der Telegramme sind insbesondere noch in Bezug auf das Telegramm 41 in der 5 näher gezeigt.
  • Netzwerkteilnehmer A (entsprechend dem Remote-Netzwerkteilnehmer 7) hat einen Publisher P1, dem zwei Writer W1, W2 vorgeschaltet sind. Diese Writer W1, W2 schreiben die zu veröffentlichenden Daten 31 in den Publisher P1 ein und bereiten diese zur Veröffentlichung/Übertragung vor. Dieser veröffentlichte Datensatz 31 kann sowohl Steuerungsdaten 1 als auch Subscriber-Daten 5 von einem oder mehreren, auf dem Netzwerkteilnehmer A residierenden Subscribern bzw. Readern S1 bzw. R1, S2 bzw. R2 aufweisen. Des Weiteren hat der Netzwerkteilnehmer A also zwei Subscriber S1, S2 mit jeweils nachgeschalteten Readern R1, R2. Die Reader R1, R2 setzen jeweils die empfangenen Daten um und schreiben Sie zur internen Weiterverarbeitung in interne, bezogene Datensätze 32, 33 ein. Schließlich hat der Netzwerkteilnehmer A noch zwei virtuelle, aktuelle Zustandsmodelle V1, V2. Diese Zustandsmodelle V1, V2 sind jeweils aus den Subscriber-Daten 5, die der jeweilige Subscriber S1, S2 bezieht, abgeleitet bzw. aktualisiert. Das aktuelle Zustandsmodell V1 bildet den Subscriber S3/Reader R3 des Netzwerkteilnehmers B ab, der (auch Steuerungs-) Datenübertragung von dem Publisher P1/ Writer W1 bezieht, und das Zustandsmodell V2 den Subscriber S4/Reader R4 des Netzwerkteilnehmers C, der (auch Steuerungs-) Datenübertragung von dem Publisher P1/ Writer W1 bezieht.
  • Analog dazu hat der Netzwerkteilnehmer B (entsprechend der Maschinensteuerung 4) einen Publisher P2 mit lediglich einem vorgeschalteten Writer W3, der einen veröffentlichten bzw. zu veröffentlichenden Datensatz 34 in den Publisher P2 einschreibt. Desgleichen hat der Netzwerkteilnehmer B einen Subscriber S3 mit nachgeschaltetem Reader R3, der die empfangenen Daten in den bezogenen Datensatz 37 transferiert. Analog dem oben zu dem Netzwerkteilnehmer A gesagten, hat auch der Netzwerkteilnehmer B ein Zustandsmodell V3, welches aus den Subscriber-Daten 5 erzeugt wird, die über den Subscriber S3 bzw. Reader R3 empfangen werden. Das Zustandsmodell V3 bildet dabei den momentanen Zustand des Readers R1 bzw. Subscribers S1 des Netzwerkteilnehmers A ab, der jeweils Daten von dem Publisher P2 bzw. Writer W3 bezogen hat.
  • Der Netzwerkteilnehmer C (kann z.B. eine Steuerung, ein Industrie-PC oder auch ein Office-PC sein) hat einen Publisher P3 mit einem vorgeschalteten Writer W4, der einen veröffentlichten bzw. zu veröffentlichenden Datensatz 35 in den Publisher P3 einschreibt. Desgleichen hat der Netzwerkteilnehmer C einen Subscriber S4 mit nachgeschaltetem Reader R4, der die empfangenen Daten in den bezogenen Datensatz 38 transferiert. Analog dem oben zu dem Netzwerkteilnehmer B gesagten, hat auch der Netzwerkteilnehmer C ein Zustandsmodell V4, welches aus den Subscriber-Daten 5 erzeugt wird, die über den Subscriber S4 bzw. Reader R4 empfangen werden. Das Zustandsmodell V4 bildet dabei den momentanen Zustand des Readers R2 bzw. Subscribers S2 des Netzwerkteilnehmers A ab, der jeweils Daten von dem Publisher P3 bzw. Writer W4 bezogen hat.
  • Schließlich hat der Netzwerkteilnehmer D einen Reader R5, der die von dem Publisher P1 des Netzwerkteilnehmers A transferierten und von dem zweiten Writer W2 dieses Publishers P1 eingeschriebenen Daten in den bezogenen Datensatz 36 transferiert. Der Netzwerkteilnehmer D hat - im Gegensatz zu den anderen, gezeigten Netzwerkteilnehmern A, B, C - lediglich eine nicht überwachte Bezugsfunktion über seinen Reader R5, so dass dieser Netzwerkteilnehmer D lediglich die von dem Publisher P1 des Netzwerkteilnehmers A transferierten und von dem zweiten, dem Publisher P1 zugeordneten Writer W2 eingeschriebenen Daten empfängt bzw. bezieht. Eine Rückübertragung von Subscriber-Daten 5 erfolgt durch den Netzwerkteilnehmer D nicht. Dies zeigt, dass die Erfindung flexibel angepasst implementiert werden kann, so dass auch gemischte Netzwerke von Netzwerkteilnehmern D ohne überwachte Kommunikation und gleichzeitig von Netzwerkteilnehmern A, B, C mit Statusmeldungen bzw. überwachter Netzwerkkommunikation gebildet werden können.
  • Der Publisher P1 des Netzwerkteilnehmers A überträgt das Telegramm 41, welches auf Daten beruht, die mit dem veröffentlichten Datensatz 31 gebildet werden. Die von dem Publisher P1 übertragene Netzwerknachricht 41 weist Daten der Writer W1, W2 auf. Teilweise im Unterschied zu dem Telegramm 40 aus 4 weist das Telegramm 41 somit im Telegrammkopf - in zeitlicher Abfolge gesehen - Identifikationsdaten ID1 auf, die den Publisher P1 identifizieren, Identifikationsdaten ID2, die den Writer W1 identifizieren sowie Identifikationsdaten ID5, die den Writer W2 identifizieren. Dies reflektiert den Umstand, dass das Telegramm 41 Daten von zwei verschiedenen Writern W1, W2 aufweist.
  • Das Telegramm 41 weist in seinem darauffolgenden Abschnitt jeweils einen Header-Abschnitt 12 auf, der analog dem in 4 beschriebenen Telegramm 40 aufgebaut ist und der in seinem Datensatzindikator 48 den Übertragungs-Indikator 11 in Form eines Indikatorbits aufweist, welches in diesem Falle auf 1 gesetzt ist, da in den darauf folgenden Abschnitten des Telegramms 41 zwei Reader-Abschnitte 44,45 folgen. Diese sind in dem Subscriber-Daten-Abschnitt 13 untergebracht und enthalten zunächst eine Angabe über die Anzahl 24 der Reader, die in dem gezeigten Ausführungsbeispiel der 5 zwei beträgt. In dem Reader-Abschnitt 44 folgen Daten, die sich auf den Reader R2 (bzw. Subscriber S2) beziehen. Der darauffolgende Reader-Abschnitt 45 enthält Daten, sich auf den Reader R1 (bzw. Subscriber S1) beziehen. Der Subscriber-Daten-Abschnitt 13 enthält darüber hinaus noch Steuerungsdaten 1, die beispielsweise von den Netzwerkteilnehmern B, C, D bezogen werden können.
  • Das gezeigte Telegramm 41 ist gemäß der Publish-/Subscribe-Kommunikationsarchitektur nicht an bestimmte Netzwerkteilnehmer gerichtet; es wird im gezeigten Ausführungsbeispiel von allen anderen Netzwerkteilnehmern B, C, D bezogen. Dies ist durch den Verlauf der Netzwerk 3-Pfeile angedeutet, die von dem Telegramm 41 ausgehend in jeden der Netzwerkteilnehmer B, C, D münden.
  • Durch die in der 5 gezeigten Pfeile, die die Modell-Abbildung 39 symbolisieren, wird angezeigt, dass mittels der Statusdaten 6 für den jeweiligen Subscriber S1, S2 bzw. Reader R1, R2 das jeweilige Zustandsmodell V3, V4 mit standardisierten Methoden des Datenaustauschstandards erzeugbar und insbesondere zyklisch aktualisierbar ist. Damit wird jeweils ein Zustandsmodell V3, das sich auf den Zustand des Readers R1 bzw. Subscribers S1 bezieht, zur Verfügung gestellt, und auf dem Netzwerkteilnehmer B erzeugt bzw. aktualisiert. Gleichermaßen wird ein Zustandsmodell V4, das sich auf den Zustand des Readers R2 bzw. Subscribers S2 bezieht, zur Verfügung gestellt, und auf dem Netzwerkteilnehmer C erzeugt bzw. aktualisiert.
  • Das Telegramm 42 wird von dem Publisher P2/Writer W3 des Netzwerkteilnehmers B erzeugt bzw. versendet. Es kann ebenfalls Prozessdaten bzw. Steuerungsdaten 1 enthalten, die von dem Netzwerkteilnehmer B stammen. Gleichzeitig enthält es Statusdaten 6, die sich auf den Reader R3/Subscriber S3 beziehen und dazu verwendet werden, nach Bezug im Netzwerkteilnehmer A das Zustandsmodell V1 aufzubauen und/oder zu aktualisieren, das sich auf den Zustand des Readers R3/Subscribers S3 bezieht.
  • Das Telegramm 43 wird von dem Publisher P2/Writer W3 des Netzwerkteilnehmers C erzeugt bzw. versendet. Es kann ebenso Prozessdaten oder Steuerungsdaten 1 enthalten, die von dem Netzwerkteilnehmer C stammen. Simultan weist es Statusdaten 6 auf, die sich auf den Reader R4/Subscriber S4 beziehen und dazu verwendet werden können, nach Bezug im Netzwerkteilnehmer A das Zustandsmodell V2 aufzubauen und/oder zu aktualisieren, welches sich auf den Zustand des Readers R4/Subscribers S4 bezieht.
  • Insgesamt ist in der 5 eine Kommunikationstopologie bzw. ein Kommunikationsverfahren gezeigt, welches sich etwa in einem fortlaufenden, etablierten, kontinuierlichen Kommunikationsprozess befindet und in einem stabilen Kommunikationsmodus gezeigt ist, der einen beispielhaften, zeitlichen Ausschnitt der gesamten Kommunikation darstellt.
  • Anhand der 5 kann das Kommunikationsverfahren vereinfacht wie folgt dargestellt werden:
    • Der Netzwerkteilnehmer A sendet über seinen Publisher P1 mittels des Telegramms 41 Steuerungsdaten 1 über das Netzwerk 3. Diese Steuerungsdaten 1 sind im rechtsseitigen Abschnitt des Telegramms 41 schematisch dargestellt. Sowohl Netzwerkteilnehmer B, C als auch D beziehen zunächst das Telegramm 41. Netzwerkteilnehmer B bezieht über seinen Subscriber S3 Steuerungsdaten 1 über das Telegramm 41 aus dem Netzwerkteilnehmer A. Im Zusammenhang mit dem Bezug dieser Steuerungsdaten 1 generiert der Netzwerkteilnehmer B Subscriber-Daten 5, die sich auf den Subscriber S3 und dessen Bezug der Steuerungsdaten 1 beziehen. Diese Subscriber-Daten 5 können beispielsweise Statusdaten 6 des Subscribers S3/Readers R3 oder auch der Maschinensteuerung 4 insgesamt aufweisen. Die Subscriber-Daten 5 werden dazu innerhalb des Netzwerkteilnehmers B erfasst und aktualisiert und anschließend über den korrespondierenden Publisher P2 des Netzwerkteilnehmers B als Bestandteil des Telegramms 42 publiziert.
  • Die Statusdaten 6 aus dem Telegramm 42, die sich auf den Status des Subscribers S3 des Netzwerkteilnehmers B beziehen, werden von dem Subscriber S1 des Netzwerkteilnehmers A bezogen und dort ausgewertet; die Statusdaten 6 werden beispielsweise zur Erzeugung des Zustandsmodells V1 verwendet, welches den Empfangsstatus bzw. einen generellen Zustand des Subscribers S3 des Netzwerkteilnehmers B wiedergibt. Das Zustandsmodell V1 wird dabei auf dem Netzwerkteilnehmer A erzeugt bzw. aktualisiert, sodass im Ergebnis der Netzwerkteilnehmer A eine Information über den Bezug der von ihm gesendeten Steuerungsdaten 1 in dem Netzwerkteilnehmer B bzw. in dessen Subscriber S3 erhält bzw. aktualisiert. Gleichzeitig mit der Übertragung der Statusdaten 6 vom Subscriber S3 kann das Telegramm 42 ebenfalls Steuerungsdaten 1 aufweisen, die vom Netzwerkteilnehmer B stammen und ebenfalls im Subscriber S1 bezogen und für die Verwendung im Netzwerkteilnehmer A extrahiert/aufbereitet oder ausgelesen werden. Im gezeigten Ausführungsbeispiel wird eine solche bidirektionale Kommunikationsschleife dadurch geschlossen, dass wiederum der Bezug solcher Steuerungsdaten 1 vom Netzwerkteilnehmer B im Netzwerkteilnehmer A überwacht wird bzw. ein Status mitgeführt werden kann und/oder Subscriber-Daten 5 erzeugt und kommuniziert werden, die sich wiederum auf den Subscriber S1 und gegebenenfalls auf den Bezug der Steuerungsdaten 1 von dem Netzwerkteilnehmer B im Subscriber S1 beziehen.
  • Bezugszeichenliste
    • 1
    Maschinensteuerungsdaten
    2
    mechatronisches System
    3
    Netzwerk
    4
    Maschinensteuerung (auch: B in 5)
    5
    Subscriber-Daten
    6
    Statusdaten
    7
    Remote-Netzwerkteilnehmer (auch: A in 5)
    8
    Primärkanal
    9
    Sekundärkanal
    10
    Übertragungsprotokoll
    11
    Übertragungs-Indikator
    12
    Header-Abschnitt
    13
    Subscriber-Daten-Abschnitt
    14
    Nutzdatenabschnitt
    15
    Reader-Headerinformationen
    16
    Identifikationsart eines Publishers
    17
    Writer-Identifikator
    18
    Zustands-Indikator
    19
    Dienstgüte-Indikator
    20
    erweitertes Übertragungsprotokoll
    21
    Datenaustauschstandard (OPC-UA-Stack)
    22
    OPC-UA-Informationsmodell (erweitertes Informationsmodell)
    23
    erweiterte Zustandsmaschine
    24
    Anzahl Reader
    25
    Reader-Status
    26
    sonstige Reader-Statusdaten
    27
    Überwachungsdaten
    28
    Nachricht-Datensatz
    29
    Netzwerknachricht
    30
    interne Schnittstelle
    31
    veröffentlichter Datensatz
    32
    bezogener Datensatz
    33
    bezogener Datensatz
    34
    bezogener Datensatz
    35
    bezogener Datensatz
    36
    veröffentlichter Datensatz
    37
    veröffentlichter Datensatz
    38
    veröffentlichter Datensatz
    39
    Modell-Abbildung
    40
    Netzwerknachricht/Telegramm
    41
    Netzwerknachricht/Telegramm
    42
    Netzwerknachricht/Telegramm
    43
    Netzwerknachricht/Telegramm
    44
    Reader-Abschnitt
    45
    Reader-Abschnitt
    A
    Netzwerkteilnehmer (auch: Remote-Netzwerkteilnehmer 7)
    B
    Netzwerkteilnehmer (auch: Maschinensteuerung 4)
    C
    Netzwerkteilnehmer
    D
    Netzwerkteilnehmer
    IDn
    Identifikationsdaten Nummer n
    Rn
    Reader Nummer n
    Wn
    Writer Nummer n
    Pn
    Publisher Nummer n
    Sn
    Subscriber Nummer n
    Tn
    Netzwerknachricht Nummer n
    Vn
    Zustandsmodell Nummer n
  • 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 (16)

  1. Verfahren der Kommunikation von Maschinensteuerungsdaten (1) eines mechatronischen Systems (2) in einem Netzwerk (3) mit mindestens einer Maschinensteuerung (4), mittels eines Datenaustauschstandards, der ein Publish-/Subscribe-Kommunikationsmodell unterstützt, bei dem Publisher (Pn) und Subscriber (Sn) entkoppelt sind; wobei die Maschinensteuerung (4) wahlfrei als Publisher (P2) und/oder als Subscriber (S1) zu betreiben ist, und wobei die Maschinensteuerung (4) in ihrer Subscriber-Funktion (S1) Steuerungsdaten (1) mittels des Datenaustauschstandards von einem Remote-Publisher (P1) über das Netzwerk (3) bezieht bzw. in ihrer Publisher-Funktion (P2) Daten über das Netzwerk (3) sendet, dadurch gekennzeichnet, dass 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 (5) über das Netzwerk (3) sendet, die über eine mit dem Remote-Publisher (P1) korrespondierende Remote-Subscriber-Funktion (S2) zu beziehen sind.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Bezug der Steuerungsdaten (1) mittels der Übertragung der Subscriber-Daten (5) zu überwachen ist.
  3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Subscriber-Daten (5) Steuerungsdaten (3) der Maschinensteuerung (4) und/oder Statusdaten (6) der Maschinensteuerung (4) und/oder Heartbeat-Daten und/oder Daten nach Art eines Rückkanals einer industriellen Automatisierungs-Feldbus-Architektur umfassen.
  4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass zwischen der Maschinensteuerung (4) und einem Remote-Netzwerkteilnehmer (7) eine bidirektionale Kommunikation erfolgt, die zumindest einen Primärkanal (8) umfasst, über den der Remote-Netzwerkteilnehmer (7) Steuerungsdaten (1) sendet und die Maschinensteuerung (4) Steuerungsdaten (1) empfängt, und einen Sekundärkanal (9), über den die Maschinensteuerung (4) Subscriber-Daten (5) sendet und der Remote-Netzwerkteilnehmer (7) Subscriber-Daten (5) empfängt.
  5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass die Maschinensteuerung (4) und der Remote-Netzwerkteilnehmer (7) Überwachungsdaten, insbesondere Statusdaten (6), zumindest eines der oben genannten Kanäle (8,9) austauschen, wobei insbesondere Überwachungsdaten des Primärkanals (8) über den Sekundärkanal (9) übertragen werden.
  6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass die Maschinensteuerung (4) und der Remote-Netzwerkteilnehmer (7) Steuerungsdaten (1) austauschen und/oder Statusdaten (6) 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 (IDn) 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).
  7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass die Kommunikation der Steuerungsdaten (1) und/oder der Subscriber-Daten (5) mittels eines standardisierten, inhärent verbindungsfreien und/oder inhärent kopplungsfreien Übertragungsprotokolls, insbesondere mittels eines UDP (User Datagram Protocol)-basierten Übertragungsprotokolls (10), weiter insbesondere mittels eines erweiterten UDP-basierten Übertragungsprotokolls (20), vorzugsweise mittels eines OSI-Layer 2-Frames (Telegramms) erfolgt, bei dem, insbesondere zyklisch, individuelle Netzwerknachrichten Tn (Telegramme) in einem standardisierten Format übertragen werden.
  8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass ein Übertragungs-Indikator (11), insbesondere ein Signalisierungsbit, weiter insbesondere ein standardmäßig nicht belegtes Bit eines Header-Abschnitts (12), in einem unter dem Übertragungsprotokoll (10) übertragenen Telegramm (Tn) das Vorhandensein von Subscriber-Daten (5) in einem Nutzdatenabschnitt (14) des Telegramms (Tn) angibt.
  9. Verfahren nach Anspruch 7 oder 8, dadurch gekennzeichnet, dass ein unter dem Datenaustauschstandard und/oder dem Übertragungsprotokoll (10) standardisierter Subscriber-Daten-Abschnitt (13) des Nutzdatenabschnitts (14) alle oder ausgewählte Subscriber-Daten (5) aufweist.
  10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass die Subscriber-Daten (5) einzeln oder in beliebiger Kombination folgendes umfassen: - Identifikationsdaten (ID1) des Remote-Publishers (P1), von dem die Steuerungsdaten (1) bezogen werden, - Statusdaten (6), die für den Bezugsstatus der Steuerungsdaten (1) in der Maschinensteuerung (4) relevant sind. - Betriebsdaten, insbesondere Steuerungsdaten (1), der Maschinensteuerung (4).
  11. Verfahren nach einem der Ansprüche 1 bis 10, 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 Subscriber-Daten (5) einzeln oder in beliebiger Kombination folgendes umfassen: - eine Information über die Anzahl der dem Subscriber (S3) der Maschinensteuerung (4) nachgeordneten Reader (R3), wobei insbesondere für jeden der Reader (R3) ein vorbestimmter Anteil an den zu übertragenden Subscriber-Daten (5) allokiert ist, - für zumindest einen bis jeden der nachgeordneten Reader (Rn) jeweils einzeln oder in beliebiger Kombination i. Reader-Headerinformationen (15), insbesondere die Art, weiter insbesondere die Identifikationsart (16), des Remote-Publishers (P1) (Publisher ID Type), und/oder ein Writer-Indikator (17), der das Vorhandensein einer Writer-Identifikation (ID4) in den Subscriber-Daten (5) angibt und/oder ein Zustandsindikator (18), der das Vorhandensein einer Zustandsinformation (6) in den Subscriber-Daten (5) angibt und/oder Dienstgüte-Indikator (19), der das Vorhandensein von Dienstgüteinformationen (Quality of Service QoS) in den Subscriber-Daten (5) angibt, ii. Identifikationsdaten (IDn) des Remote-Publishers, von dem die Steuerungsdaten (1) bezogen werden, iii. Writer-Identifikationsdaten (ID2, ID4) eines Writers, insbesondere des Writers (W2) des Remote-Publishers (P1), von dem die Steuerungsdaten (1) bereitgestellt werden, iv. Zustandsdaten (6) eines Readers (Rn).
  12. Verfahren nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass mittels der übertragenen Subscriber-Daten (5) ein virtuelles, aktuelles Zustandsmodell (Vn) des Subscribers (Sn) und/oder der Maschinensteuerung (4) und/oder einer physikalischen oder logischen Komponente (Wn,Rn) des Subscribers (Sn) erzeugbar und insbesondere zyklisch aktualisierbar ist.
  13. Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass das Zustandsmodell (V1,V2) lokal bezüglich des Remote-Publishers (P1) erzeugt und insbesondere aktualisiert wird.
  14. Verfahren nach Anspruch 12 oder 13, dadurch gekennzeichnet, dass das Zustandsmodell (Vn) mit standardisierten Methoden des Datenaustauschstandards netzwerkweit oder innerhalb eines Netzwerksegmentes für Netzwerkteilnehmer (A,B,C,D) zugänglich und insbesondere abrufbar und/oder herunterladbar ist.
  15. 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 14 auszuführen.
  16. Computerprogrammprodukt für eine Rechnereinrichtung, insbesondere für eine Maschinensteuerung (4), welches bei Ausführung auf einer Rechnereinrichtung ein Verfahren nach einem der Ansprüche 1 bis 14 ausführt.
DE102019219023.5A 2019-12-06 2019-12-06 Übertragungsverfahren Pending DE102019219023A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE102019219023.5A DE102019219023A1 (de) 2019-12-06 2019-12-06 Übertragungsverfahren

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102019219023.5A DE102019219023A1 (de) 2019-12-06 2019-12-06 Übertragungsverfahren

Publications (1)

Publication Number Publication Date
DE102019219023A1 true DE102019219023A1 (de) 2021-06-24

Family

ID=76206557

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102019219023.5A Pending DE102019219023A1 (de) 2019-12-06 2019-12-06 Übertragungsverfahren

Country Status (1)

Country Link
DE (1) DE102019219023A1 (de)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090003599A1 (en) * 2007-06-29 2009-01-01 Honeywell International, Inc. Systems and methods for publishing selectively altered sensor data in real time
US20190065353A1 (en) * 2017-08-24 2019-02-28 Salesforce.Com, Inc. Controlling executions of synchronous and/or non-synchronous operations with asynchronous messages
EP3576376A1 (de) * 2018-05-29 2019-12-04 Siemens Aktiengesellschaft Datenübermittlung innerhalb eines industriellen automatisierungssystems

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090003599A1 (en) * 2007-06-29 2009-01-01 Honeywell International, Inc. Systems and methods for publishing selectively altered sensor data in real time
US20190065353A1 (en) * 2017-08-24 2019-02-28 Salesforce.Com, Inc. Controlling executions of synchronous and/or non-synchronous operations with asynchronous messages
EP3576376A1 (de) * 2018-05-29 2019-12-04 Siemens Aktiengesellschaft Datenübermittlung innerhalb eines industriellen automatisierungssystems

Similar Documents

Publication Publication Date Title
EP3627800B1 (de) Publish-/subscribe-kommunikation von maschinensteuerungsdaten
DE102007004044B4 (de) Verfahren und Anlage zur optimierten Übertragung von Daten zwischen einer Steuereinrichtung und mehreren Feldgeräten
DE102010016283B4 (de) Verfahren zur Übertragung von Daten über einen CANopen-Bus sowie Verwendung des Verfahrens zum Konfigurieren und/oder Parametrieren von Feldgeräten über den CANopen-Bus
EP3679691B1 (de) Datenübertragungsverfahren und kommunikationsnetzwerk
DE102011107321A1 (de) System und Verfahren zur Parametrierung von Feldgeräten eines Automatisierungs- oder Steuerungssystems
EP3759871B1 (de) Master-slave bussystem und verfahren zum betrieb eines bussystems
DE102012102187B3 (de) Steuerungsvorrichtung zum Steuern von sicherheitskritischen Prozessen in einer automatisierten Anlage und Verfahren zur Parametrierung der Steuerungsvorrichtung
DE102017208831A1 (de) Verarbeitung von Prozessdaten
EP3632050B1 (de) Busumsetzer
DE102019208678A1 (de) Kommunikationsverfahren
WO2003027784A2 (de) Verfahren zur übertragung eines datentelegramms zwischen einer echtzeit-domain und einer nicht-echtzeit-domain und koppeleinheit
DE102019219023A1 (de) Übertragungsverfahren
WO2004030275A1 (de) Kommunikationssystem mit teilnehmer und diagnoseeinheit
EP3631630B1 (de) Verteilte verarbeitung von prozessdaten
DE102019219031A1 (de) Übertragungsverfahren
DE102018210615A1 (de) Übertragungsverfahren
EP4070530B1 (de) Verfahren zum zyklischen übertragen von daten zwischen kommunikationsteilnehmern auf einem datenübertragungskanal und datenübertragungssystem
DE10241183A1 (de) Verfahren zur Übertragung eines Datentelegramms zwischen einer Echtzeit-Domain und einer Nicht-Echtzeit-Domain und Koppeleinheit
DE102019219036A1 (de) Verfahren für die überwachung einer publish-subscribe verbindung
WO2022171575A1 (de) Verfahren zur einbindung in eine datenübertragung von einer anzahl von an einer i/o-station angeschlossenen i/o-modulen, ein stationskopf zur ausführung eines solchen verfahrens und ein system mit einem solchen stationskopf
DE102021103119A1 (de) Verfahren zur Einbindung in eine Datenübertragung von einer Anzahl von an einer I/O-Station angeschlossenen I/O-Modulen, ein Stationskopf zur Ausführung eines solchen Verfahrens und ein System mit einem solchen Stationskopf
EP1371193A2 (de) Electronical switch and method for a communication interface with cut through buffer memory
DE102018010209A1 (de) Master-Slave Bussystem und Verfahren zum Betrieb eines Bussystems
DE102017208818A1 (de) Initialisierung von Datenbusteilnehmern
WO2003028308A1 (de) Verfahren zur erstellung einer dynamischen adresstabelle für einen koppelknoten in einem datennetz und verfahren zur übertragung eines datentelegramms

Legal Events

Date Code Title Description
R163 Identified publications notified
R012 Request for examination validly filed