DE102019219036A1

DE102019219036A1 - Verfahren für die überwachung einer publish-subscribe verbindung

Info

Publication number: DE102019219036A1
Application number: DE102019219036.7A
Authority: DE
Inventors: Johannes Von Hoyningen-Huene; Frederick Prinz; Andreas Eckhardt; Sebastian Mueller
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2019-12-06
Filing date: 2019-12-06
Publication date: 2021-06-10

Abstract

Die vorliegende Erfindung bezieht sich auf einem Verfahren der Kommunikation von Maschinensteuerungsdaten eines mechatronischen Systems in einem Netzwerk mit mindestens einer Maschinensteuerung mittels eines Datenaustauschstandards, der ein Publish-/Subscribe-Kommunikationsmodell unterstützt, bei dem Publisher (100) und Subscriber (200) entkoppelt sind. Die Maschinensteuerung ist wahlweise als Publisher (100) und/oder als Subscriber (200) zu betreiben, und die Maschinensteuerung bezieht in ihrer Subscriber-Funktion (200) Steuerungsdaten mittels des Datenaustauschstandards über das Netzwerk. Darüber hinaus generiert die Maschinensteuerung in der Subscriber-Funktion (200) Statusdaten und überträgt die Statusdaten in der Publisher-Funktion über das Netzwerk.

Description

TECHNISCHER BEREICH
Die vorliegende Erfindung betrifft das technische Gebiet der Kommunikation von Maschinensteuerungsdaten eines mechatronischen Systems. Insbesondere betrifft die vorliegende Erfindung ein Verfahren, das eine Publish-/Subscribe Verbindung überwacht. Darüber hinaus betrifft die vorliegende Erfindung eine Maschinensteuerung, die das Verfahren ausführen kann und ein Computerprogrammprodukt für eine Rechnereinrichtung, welches bei Ausführung auf einer Rechnereinrichtung das Verfahren ausführt.
STAND DER TECHNIK
In der Patentanmeldung Nummer DE 10 2018 216111 (von nun an einfach PTL1 genannt) ist ein Verfahren der Kommunikation von Maschinensteuerungsdaten eines mechatronischen Systems in einem Netzwerk beschrieben. Das Netzwerk weist mindestens einen ersten und einen zweiten Netzwerkteilnehmer auf. Der erste Netzwerkteilnehmer ist dazu konfiguriert, die Steuerungsdaten mittels eines Datenaustauschstandards, der ein Publish-/Subscribe-Kommunikationsmodell unterstützt, über das Netzwerk zu übertragen. Andererseits ist der zweite Netzwerkteilnehmer dazu konfiguriert, die Steuerungsdaten mittels eines Datenaustauschstandards, der ein Publish-/Subscribe-Kommunikationsmodell unterstützt, über das Netzwerk selektiv zu erhalten oder auszuwählen.
Das Verfahren von PTL1 ist so konfiguriert, dass eine Maschinensteuerung des mechatronischen Systems als Netzwerkteilnehmer in das Netzwerk eingebunden ist und wahlfrei als Subscriber und/oder als Publisher zur Kommunikation der Steuerungsdaten konfiguriert werden kann. Ein solches Verfahren ist sehr vorteilhaft, weil es aufgrund der entkoppelten Kommunikation einfache Strukturen und ein hohes Maß an Flexibilität der Systemkonfiguration bietet und gleichzeitig die Vorteile der Publish-/Subscribe-Kommunikationsarchitektur für eine Vielzahl von Automatisierungsaufgaben erschließt.
Das Verfahren von PTL1 hat aber den Nachteil, dass die zwei Netzwerkteilnehmer einander nicht bekannt sind. Wenn z.B. der Subscriber aus bestimmten Gründen offline geht, ist dies dem Publisher nicht bewusst. Deswegen ist bei einem Kabelbruch oder bei einem defekten Switch dem Publisher nicht bekannt, dass der Subscriber die gesendeten Informationen nicht empfangen kann.
Ziel der Erfindung ist es deswegen einen Prozess anzugeben, in dem es bei dem Verfahren von PTL1 zusätzlich möglich ist, den Status eines anderen Netzwerkteilnehmers, und insbesondere dessen Verbindung, zu überwachen.
Aus diesem Grund bietet diese Erfindung ein Verfahren der Kommunikation von Maschinensteuerungsdaten eines mechatronischen Systems in einem Netzwerk mit mindestens einer Maschinensteuerung mittels eines Datenaustauschstandards, der ein Publish-/Subscribe-Kommunikationsmodell unterstützt, bei dem Publisher und Subscriber entkoppelt sind, und durch das der Status einer Verbindung überwacht werden kann.
KURZFASSUNG
Die vorliegende Erfindung basiert auf der Idee, dass ein Netzwerkteilnehmer wahlweise als Publisher und/oder als Subscriber zu betreiben ist und dass der Netzwerkteilnehmer in der Subscriber-Funktion Statusdaten generiert und die Statusdaten in der Publisher-Funktion über das Netzwerk überträgt, damit es für den Publisher ermöglicht werden kann, den Status des Subscribers zu erfassen.
Gemäß einer Ausführungsform der vorliegenden Erfindung wird ein Verfahren der Kommunikation von Maschinensteuerungsdaten eines mechatronischen Systems in einem Netzwerk mit mindestens einer Maschinensteuerung mittels eines Datenaustauschstandards, der ein Publish-/Subscribe-Kommunikationsmodell unterstützt, bei dem Publisher und Subscriber entkoppelt sind, bereitgestellt; wobei die Maschinensteuerung wahlweise als Publisher und/oder als Subscriber zu betreiben ist, und wobei die Maschinensteuerung in ihrer Subscriber-Funktion Steuerungsdaten mittels des Datenaustauschstandards über das Netzwerk bezieht, und wobei die Maschinensteuerung in der Subscriber-Funktion Statusdaten generiert und die Statusdaten in ihrer Publisher-Funktion über das Netzwerk überträgt. Dieses Verfahren ist besonders vorteilhaft, weil es ermöglicht, den Status eines Netzwerkteilnehmers zu erfassen, indem Statusdaten eines Subscribers über das Netzwerk übertragen werden. In diesem Fall ist es dann möglich, ein einfaches und bekanntes Publish-/Subscribe-Kommunikationsmodell zu benutzen und gleichzeitig die Verbindung zwischen verschiedenen Netzwerkteilnehmern zu überwachen.
Gemäß einer weiteren Ausführungsform der vorliegenden Erfindung wird ein Verfahren bereitgestellt, wobei die genannten Statusdaten für den momentanen Bezugsstatus der zu beziehenden Steuerungsdaten relevant sind. Mit „momentanem Bezugsstatus“ ist ein Status gemeint, der den regelmäßigen Bezug der Steuerungsdaten repräsentiert, insbesondere nach einem Fehlerstatus oder ordnungsgemäßen Status des Bezugs differenziert. Beispielsweise kann dadurch eine schlechte Netzwerkverbindung oder sonstige Störung - wie etwa ein Kabelbruch - detektiert werden. Durch den Status kann auch festgestellt werden, dass die Steuerungsdaten korrekt und insbesondere digital unverändert bezogen werden, was für eine synchronisierte Industrieautomatisierung von erheblicher Bedeutung ist. Mit „relevant“ ist gemeint, dass der momentane, also zeitlich aktuelle oder etwa in Echtzeit aktualisierte Bezugsstatus aus den Statusdaten abgeleitet werden kann oder dass die Statusdaten zumindest für den momentanen Bezugsstatus charakteristisch sind und/oder für den Bezugsstatus charakteristische Informationen/Daten enthalten. Diese Lösung ist besonders vorteilhaft, da es ermöglicht wird, den Status des Netzwerkteilnehmers, der die Steuerungsdaten über das Netzwerk bezieht, eindeutig durch einen anderen Netzwerkteilnehmer zu erfassen.
Gemäß einer weiteren Ausführungsform der vorliegenden Erfindung überträgt die Maschinensteuerung die Statusdaten dadurch, dass sie simultan zu ihrer Subscriber-Funktion eine mit der Subscriber-Funktion korrespondierende Publisher-Funktion ausübt, mittels derer die Statusdaten über das Netzwerk übertragen werden. Die mit der Subscriber-Funktion korrespondierende Publisher-Funktion ist eine vorzugsweise auf der Maschinensteuerung selber implementierte Funktion des Publishers, die den Status des Subscribers desselben Netzwerkteilnehmers (also vorzugsweise der Maschinensteuerung) erfasst und diesen über das Netzwerk überträgt. Diese Lösung ist besonders vorteilhaft, da es mit einem einzelnen Netzwerkteilnehmer ermöglicht wird, sowohl die Statusdaten durch den Subscriber zu generieren als auch diese durch den Publisher über das Netzwerk zu übertragen, also eine bidirektionale Kommunikation insbesondere unter Übermittlung von Kommunikations-Metadaten zu implementieren.
Gemäß dem Datenaustauschstandard kann generell 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 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.
Gemäß einer weiteren Ausführungsform der vorliegenden Erfindung wird ein Verfahren nach einer der Ausführungsformen der vorliegenden Erfindung bereitgestellt, wobei mit den Statusdaten zusätzlich Steuerungsdaten für einen oder mehrere Subscriber durch die Maschinensteuerung in der Publisher-Funktion übertragen werden, wobei die Steuerungsdaten vorzugsweise separat von den Statusdaten übertragen werden. Mit diesem Merkmal ist es möglich, sowohl die Steuerungsdaten als auch die Statusdaten durch einen Netzwerkteilnehmer über das Netzwerk zu übertragen, damit ein Empfänger den kompletten Überblick über einen anderen Netzwerkteilnehmer, der die Daten überträgt, erhalten kann.
Gemäß einer weiteren Ausführungsform der vorliegenden Erfindung wird ein Verfahren nach einer der Ausführungsformen der vorliegenden Erfindung bereitgestellt, wobei jeder Netzwerkteilnehmer, der Statusdaten und/oder Steuerungsdaten sendet oder empfängt, wahlweise als Publisher und/oder als Subscriber konfigurierbar ist, insbesondere jeder solche Netzwerkteilnehmer des gesamten Netzwerkes oder eines Netzwerksegments. Mit dieser Lösung ist es möglich, ein Netz zu erstellen, bei dem jeder Netzwerkteilnehmer mit den anderen Netzwerkteilnehmern durch das Publish-/Subscribe-Kommunikationsmodell kommunizieren kann und gleichzeitig erfassen kann, ob die gesendeten Daten tatsächlich von dem anderen Netzwerkteilnehmer erhalten werden.
Eine weitere Ausgestaltung der Erfindung sieht vor, dass das Netzwerk mindestens einen Remote-Netzwerkteilnehmer aufweist, der wahlweise als Publisher und/oder als Subscriber zu betreiben ist, wobei die Maschinensteuerung in der Subscriber-Funktion die Steuerungsdaten über eine Remote-Publisher-Funktion des Remote-Netzwerkteilnehmers bezieht, und wobei der Remote-Netzwerkteilnehmer eine Remote-Subscriber-Funktion ausübt, über die die Statusdaten der Maschinensteuerung zu beziehen sind. Mit dieser Lösung ist es möglich, ein Netz zu erstellen, bei dem die Maschinensteuerung durch das Publish-/Subscribe-Kommunikationsmodell den Status des Remote-Netzwerkteilnehmers erhalten kann und umgekehrt. Damit ist es auch möglich, zu erfassen, ob die gesendeten Daten tatsächlich von dem jeweils anderen Netzwerkteilnehmer erhalten werden oder nicht. Durch die vorgeschlagene Ausgestaltung wird die Kommunikationsstrecke zwischen Maschinensteuerung und Remote-Netzwerkteilnehmer geschlossen.
Die Flexibilität und Effizienz der Kommunikation kann dadurch gesteigert werden, dass die Maschinensteuerung, und gegebenenfalls der Remote-Netzwerkteilnehmer, einen oder mehrere lokale Publisher und eine Mehrzahl von lokalen Subscribern aufweist/aufweisen, von denen einer oder mehrere gleichzeitig Statusdaten generieren und diese an den lokalen Publisher zur Übertragung über das Netzwerk übertragen, insbesondere über einen Subscriber, der die Status einsammelt und gesammelt überträgt. Diese Lösung ist besonders vorteilhaft, da es ermöglicht wird, mehrere Subscriber pro Publisher anzuordnen, damit verschiedene Steuerungsdaten gleichzeitig von einem Netzwerkteilnehmer über das Netzwerk übertragen werden können. Beispielweise kann mit einer solchen Anordnung sowohl eine Drehzahl als auch ein Drehmoment und eine Temperatur eines Motors über das Netzwerk übertragen werden. Darüber hinaus wird der Publisher die Statusdaten der einzelnen Subscriber über das Netzwerk übertragen, damit der Status der einzelnen Subscriber von einem anderen Netzwerkteilnehmer erfasst werden kann. Die Aggregation der von mehreren Readern generierten Status und die aggregierte Übertragung mittels eines Publishers schonen darüber hinaus die informations- und kommunikationstechnischen Ressourcen.
Wie aus der Beschreibung klar hervorgeht, sind die Statusdaten 201-209 für den momentanen Bezugsstatus der zu beziehenden Steuerungsdaten relevant. Mit „momentanem Bezugsstatus“ ist ein Status gemeint, der den regelmäßigen Bezug der Steuerungsdaten repräsentiert, insbesondere nach einem Fehlerstatus oder ordnungsgemäßen Status des Bezugs differenziert. Beispielsweise kann dadurch eine schlechte Netzwerkverbindung oder sonstige Störung - wie etwa ein Kabelbruch - detektiert werden. Durch den Status kann auch festgestellt werden, dass die Steuerungsdaten korrekt und insbesondere digital unverändert bezogen werden. Mit „relevant“ ist gemeint, dass der momentane, also zeitlich aktuelle oder etwa in Echtzeit aktualisierte Bezugsstatus aus den Statusdaten abgeleitet werden kann oder dass die Statusdaten zumindest für den momentanen Bezugsstatus charakteristisch sind und/oder für den Bezugsstatus charakteristische Informationen/Daten enthalten.
Um Applikationen der Industrieautomatisierung, die eine zyklische Kommunikation in Echtzeit erfordern, zu unterstützen, wird vorgeschlagen, dass die Generierung und/oder die Aktualisierung und/oder die Übertragung von Statusdaten zyklisch erfolgt, insbesondere in Echtzeit. Echtzeit-Anwendungen können solche mit deterministischer Echtzeit, garantierter Zeitkonstante der Aktualisierung, Echtzeit nach einem Feldbus-Standard, wie etwa SERCOS, PROFINET oder EtherCAT oder allgemein mit garantierter Dienstgüte umfassen (Quality of Service QoS, insbesondere nach einem der QoS-Niveaus des IEEE 802.1 - Netzwerkstandards TSN - Time Sensitive Networking).
Wenn die Statusdaten, die durch die Maschinensteuerung, und gegebenenfalls durch den Remote-Netzwerkteilnehmer, in der Subscriber-Funktion über das Netzwerk übertragen werden, für den momentanen Bezugsstatus dedizierte oder explizite charakteristische Statusdaten sind, wird eine eindeutige Erkennung des Status des Netzwerkteilnehmers einfach und effizient ermöglicht.
Vorzugsweise sind die Statusdaten, die durch die Maschinensteuerung, und gegebenenfalls durch den Remote-Netzwerkteilnehmer, in der Subscriber-Funktion in das Netzwerk übertragen werden, codierte Statusdaten. Durch die Kodierung ist der Erkennungsprozess des Status des Netzwerkteilnehmers vereinfacht, weil durch die Kodierung nur die für die Anerkennung des Status relevanten Informationen über das Netzwerk übertragen werden können. Damit kann der Subscriber direkt nach dem Erhalt der kodierten Informationen den Status des anderen Netzwerkteilnehmers erfassen.
Gemäß einer weiteren Ausführungsform der vorliegenden Erfindung wird ein Verfahren nach einer der Ausführungsformen der vorliegenden Erfindung bereitgestellt, wobei die Netzwerkteilnehmer, die Statusdaten senden und/oder empfangen, dazu eine übereinstimmende, entsprechende Codierungsreferenz mit Referenz-Statuscodes verwenden, die insbesondere im Rahmen des Datenaustauschstandards einheitlich standardisiert ist. Durch die Kodierung ist der Erkennungsprozess des Status des Netzwerkteilnehmers wesentlich vereinfacht, weil durch die Kodierung nur die für die Erkennung des Status relevanten Informationen über das Netzwerk übertragen werden. Damit kann der Subscriber direkt nach dem Erhalt der kodierten Informationen den Status des anderen Netzwerkteilnehmers erfassen. Durch die Standardisierung ist es außerdem möglich, für jeden Netzwerkteilnehmer unabhängig von Programmiersprache und Betriebssystem den Status zu erfassen. Die Codierungsreferenz ist insbesondere übergreifend und/oder generisch definiert. Dies kann beispielsweise in einem für den Datenaustauschstandard spezifischen Stack oder Informationsmodell hinterlegt sein. Dann ist ein hohes Maß an Standardisierung und/oder Interoperabilität erreichbar - auch unabhängig von verschiedenen Gerätearten, Geräteherstellern und informationstechnischer I nfrastru ktu r.
Gemäß einer weiteren Ausführungsform der vorliegenden Erfindung wird ein Verfahren bereitgestellt, wobei die Maschinensteuerung, und gegebenenfalls der Remote-Netzwerkteilnehmer, in der Subscriber-Funktion, wenn diese sich in einem Wartestatus befindet, der einem der genannten Statusdaten entspricht, zyklisch überprüft, ob eine vorgegebene Netzwerknachricht empfangen wird, und zu einem Empfangsstatus wechselt, der einem der genannten Statusdaten entspricht, wenn die vorgegebene Netzwerknachricht empfangen wird, wobei in dem Empfangsstatus zyklisch durch den Empfang einer Netzwerknachricht der Status des Bezugs der Steuerungsdaten überprüft wird. Diese Lösung ermöglicht es, direkt durch die Sendung einer vorgegebenen Nachricht mittels des Publishers den Status des Subscribers bzw. des Bezugs von Steuerungsdaten zu überprüfen. Insbesondere wird in diesem Wartestatus zyklisch überprüft, ob vorzugsweise eine Netzwerknachricht mit den richtigen IDs, die von einem Publisher über das Netzwerk übertragen wurde, empfangen wurde. Sobald eine Netzwerknachricht mit den entsprechenden IDs empfangen wurde, wechselt der Subscriber den Status.
Durch die zyklische Überprüfung und die erfindungsgemäß deterministische Ausgestaltung der Zustände auf Basis der Statusdaten kann insgesamt die Zuverlässigkeit und Deterministik eines Kommunikationsverfahrens verbessert werden. Die vorgenannte und alle weiteren Ausgestaltungen in Bezug auf Status können etwa in einer Zustandsmaschine implementiert werden, die unter dem Datenaustauschstandard standardisiert sein kann. 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.
Gemäß einer weiteren Ausführungsform der vorliegenden Erfindung wird ein Verfahren bereitgestellt, wobei ein Netzwerkteilnehmer, insbesondere der Remote-Netzwerkteilnehmer, in der (Remote-)Publisher-Funktion die Steuerungsdaten, insbesondere mit einem zusätzlichen Statusindikator (Flag), über das Netzwerk überträgt, nachdem eine Information über den genannten Empfangsstatus von dem einen oder mehreren Subscribern der Maschinensteuerung empfangen wird. Diese Lösung ermöglicht einerseits durch einen Statusindikator eine Information zu übertragen, die dem Empfangsstatus des Subscribers entspricht, nachdem der Publisher erkannt hat, dass ein Subscriber oder mehrere Subscriber bereit sind, die Steuerungsdaten zu empfangen und zu konsumieren. Jeder Subscriber weist vorzugsweise einen oder mehreren Reader auf, die logische Leseeinheiten sind, die die zu übertragenden Daten verarbeiten (siehe dazu auch das oben Ausgeführte). Des Weiteren ermöglicht diese Lösung, durch einen Statusindikator eine Information zu übertragen, die dem Empfangsstatus des Readers entspricht, nachdem der Publisher erkannt hat, dass einer oder mehrere Reader bereit sind. Insbesondere wird durch den Statusindikator (Flag), der auf „Nicht gesetzt“ (false) eingestellt ist, angezeigt, dass die Steuerungsdaten noch nicht gültig oder benutzbar oder empfangbar sind. Das passiert, wenn der Publisher erfasst, dass nicht jeder der bestimmten Anzahl von Readern sich in dem genannten Empfangsstatus befindet. Anderseits wird durch den Statusindikator (Flag), der auf „gesetzt“ (true) eingestellt ist, gesagt, dass die Steuerungsdaten benutzbar/empfangbar sind.
Gemäß einer weiteren Ausführungsform der vorliegenden Erfindung wechselt die Maschinensteuerung, und gegebenenfalls der Remote-Netzwerkteilnehmer, in der Subscriber-Funktion zu einem Konsumstatus, der einem der genannten Statusdaten entspricht, wenn die Steuerungsdaten, und insbesondere der zusätzliche Statusindikator (Flag), empfangen werden, wobei in dem Konsumstatus zyklisch der Status des Publishers und/oder der Empfangsstatus des Subscribers (oder eines Readers) überprüft wird.
Gemäß einer weiteren Ausführungsform der vorliegenden Erfindung ist vorgesehen, dass die Maschinensteuerung, und gegebenenfalls der Remote-Netzwerkteilnehmer, in der Subscriber-Funktion zu einem Vorwarnungsstatus wechselt, der einem der genannten Statusdaten entspricht, und der über das Netzwerk übertragen wird, wenn gewünschte Maschinensteuerungsdaten nicht empfangen werden. Diese Lösung ermöglicht es, einem anderen Netzwerkteilnehmer zu kommunizieren, dass die gewünschten Steuerungsdaten nicht empfangen wurden, damit diese Information über das Netzwerk bezogen werden kann und die Überwachung der Verbindung tatsächlich erfolgen kann.
Wenn die Maschinensteuerung, und gegebenenfalls der Remote-Netzwerkteilnehmer, im Rahmen der Subscriber-Funktion zu einem Warnungsstatus wechselt, der einem der genannten Statusdaten entspricht, und der über das Netzwerk übertragen wird, wenn eine vorbestimmte Anzahl von gewünschten Informationen über eine bestimmte Zeit nicht empfangen wird, ist ein deterministischer Zustand kommunizierbar, der zuverlässig über ausgebliebene Datenpakete informiert. Dazu kann der Warnungsstatus einem Fehlerzustand entsprechen. Des Weiteren kann die Anzahl gewünschter (oder erwarteter) Informationen etwa eine Anzahl von nach regelmäßiger Netzwerkkommunikation ankommenden Netzwerktelegrammen umfassen. So kann ein Warnungsstatus eingenommen werden, wenn eines, zwei, drei, vier oder generell eine vordefinierte Anzahl n an Netzwerktelegrammen ausbleiben (oder fehlerbehaftet bezogen werden, so dass sie nicht auswertbar oder nicht zuverlässig sind).
Insbesondere nach der Einnahme des o.g. Warnungsstatus oder Vorwarnungsstatus kann die Maschinensteuerung, und gegebenenfalls der Remote-Netzwerkteilnehmer, in der Subscriber-Funktion wieder zu dem Konsumstatus wechseln, wenn die gewünschten Maschinensteuerungsdaten wieder empfangen werden. Wenn die Rückkehr zum Konsumstatus aus dem Vorwarnungsstatus erfolgt, muss die nächste Statuseskalation des Warnungsstatus erst gar nicht eingenommen werden, so dass kein Warnsignal erfolgt. Diese Lösung vermeidet somit höhere Fehlerstufen. Wenn die Rückkehr zum Konsumstatus aus dem Warnungsstatus erfolgt, wird sehr schnell wieder in einen Produktivmodus zurückgekehrt.
Gemäß einer weiteren Ausführungsform der vorliegenden Erfindung wird ein Verfahren nach einer der Ausführungsformen der vorliegenden Erfindung bereitgestellt, wobei bei der Maschinensteuerung, und gegebenenfalls bei dem Remote-Netzwerkteilnehmer, der Subscriber nach Maßgabe des Nachrichten-Identifikators seine zu beziehende Nachricht selektiv erhalten kann, bei Verwendung einer Publish/Subscribe-Architektur mit Unicast-Adressierung.
Gemäß einer weiteren Ausführungsform der vorliegenden Erfindung wird ein Verfahren nach einer der Ausführungsformen der vorliegenden Erfindung bereitgestellt, wobei der verwendete Datenaustauschstandard OPC-UA (Open Platform Communication - Unified Architecture) ist und/oder die verwendeten Übertragungsmechanismen und/oder das Publish-/Subscribe-Kommunikationsmodell und/oder die übertragenen Daten, insbesondere Steuerungsdaten und/oder Statusdaten bzw. deren Datenstruktur und/oder Datenformat, OPC-UA-konform sind.
Gemäß einer weiteren Ausführungsform der vorliegenden Erfindung wird eine Maschinensteuerung bereitgestellt, die dazu eingerichtet ist, ein Verfahren nach einer der Ausführungsformen der vorliegenden Erfindung auszuführen.
Figurenliste
Die vorliegende Erfindung wird unter Bezugnahme auf die beigefügten Figuren beschrieben, wobei sich gleiche Bezugszeichen auf gleiche Teile und / oder auf ähnliche Teile und / oder auf entsprechende Teile des Systems beziehen. Zu den Figuren:

1 zeigt schematisch eine Überwachung einer unidirektionalen Verbindung zwischen Publisher und Subscriber;
2 zeigt schematisch ein Design einer bidirektionalen Verbindung;
3 zeigt eine schematische Darstellung eines Arbeitsablaufes im Rahmen einer Publisher-Funktion gemäß einer Ausführungsform der vorliegenden Erfindung;
4 zeigt eine schematische Darstellung eines Arbeitsablaufes einer Subscriber-Funktion gemäß einer Ausführungsform der vorliegenden Erfindung.

DETAILLIERTE BESCHREIBUNG
Im Folgenden wird die vorliegende Erfindung unter Bezugnahme auf bestimmte Ausführungsformen beschrieben, wie sie in den beigefügten Figuren gezeigt sind. Nichtsdestotrotz ist die vorliegende Erfindung nicht auf die besonderen Ausführungsformen beschränkt, die in der folgenden detaillierten Beschreibung beschrieben und in den Figuren gezeigt sind, sondern die beschriebenen Ausführungsformen veranschaulichen lediglich einige Aspekte der vorliegenden Erfindung, deren Schutzbereich durch die Ansprüche definiert ist.
Weitere Änderungen und Variationen der vorliegenden Erfindung sind für den Fachmann klar. Die vorliegende Beschreibung umfasst somit alle Änderungen und / oder Variationen der vorliegenden Erfindung, deren Schutzbereich durch die Ansprüche definiert ist.
In der vorliegenden Erfindung ist mit dem Wortlaut „zyklisch“ gemeint, dass der zugehörige Prozess mit einer bestimmten Frequenz wiederholt wird, so dass z.B. bestimmte Daten mit einer bestimmten Frequenz veröffentlicht werden oder empfangen werden können. Durch einen Prozess, der zyklisch wiederholt wird, ist z.B. ermöglicht, Daten in Echtzeit zu übertragen und zu empfangen.
1 zeigt schematisch eine unidirektionale Verbindung 3 zwischen einem Publisher 100 eines ersten Netzwerkteilnehmers 1 und einem Subscriber 200 eines zweiten Netzwerkteilnehmers 2 auf Seiten des Subscribers 200, wie aus PTL1 bekannt ist.
Eine solche Verbindung 3 ist in einem mechatronischen System - insbesondere in einem System der Industrieautomatisierung - benutzt, um Maschinensteuerungsdaten (auch Steuerungsdaten genannt), wie zum Beispiel eine Drehzahl, eine Drehstellung oder ein Drehmoment, Sollwerte, Istwerte oder allgemein Sensordaten auszutauschen.
Der Publisher kann eine oder mehrere, physikalische oder logische Schreibeeinheiten (die von nun an einfach als „Writer“ bezeichnet werden) aufweisen, die die zu übertragende Daten bereitstellen. Darüber hinaus kann der Subscriber einen oder mehrere physikalische oder logische Leseeinheiten (die von nun an einfach als „Reader“ bezeichnet werden) aufweisen, die die bezogenen Daten auslesen.
Die Maschinensteuerungsdaten werden in dem mechatronischen System in einem Netzwerk mit mehreren Netzwerkteilnehmern (in 1 sind nur zwei davon abgebildet) kommuniziert. Insbesondere werden in dem Netzwerk die Steuerungsdaten mittels eines Datenaustauschstandards, der ein Publish-/Subscribe-Kommunikationsmodell unterstützt, von dem entsprechend konfigurierten Publisher 100 gesendet. Die gesendeten Daten werden dann durch einen Subscriber 200 des zweiten Netzwerkteilnehmers 2 über das Netzwerk mittels des Datenaustauschstandards empfangen.
Die versendeten Netzwerknachrichten sind generell jeweils für bedarfsweise auswählbare, vom Publisher entkoppelte Subscriber vorgesehen. Ein Subscriber erhält eine Netzwerknachricht mit seinen zu beziehenden Steuerungsdaten, jeweils vorzugsweise ereignisgesteuert, selektiv oder wählt diese aus; zusätzlich oder alternativ kann der betreffende Subscriber die zu beziehenden Steuerungsdaten auch aus einer empfangenen/analysierten Netzwerknachricht selektiv entnehmen.
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).
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.
Der Subscriber 200 wird vorzugsweise auf Änderungen reagieren, z.B. mit einem Statuswechsel. Der Subscriber 200 erwartet bei jedem Zyklus eine Nachricht, die durch den Publisher über das Netz übertragen wird und entnimmt die Steuerungsdaten aus der erhaltenen Nachricht.
Wenn der Subscriber 200 in einem Zyklus die erwartete Nachricht nicht empfängt, wechselt der Subscriber 200 zu einem Error-Zustand. Umgekehrt ist jedoch dem Publisher 100 nicht bekannt, ob der Subscriber tatsächlich die Daten empfangen darf. In diesem Zusammenhang ist eine bidirektionale Kommunikation mit einem solchen System nicht möglich.
Wenn eine bidirektionale Kommunikation zwischen zwei Netzwerkteilnehmern gefordert ist, wird ein zweites Paar, bestehend aus Publisher und Subscriber, verwendet. In 2 ist eine solche bidirektionale Verbindung dargestellt. Auch in diesem Fall ist es aber für den Publisher 100 eines ersten Netzwerkteilnehmers 1 nicht möglich zu wissen, ob der Subscriber 200 eines zweiten Netzwerkteilnehmers 2 die Steuerungsdaten, die über das Netzwerk übertragenen werden, tatsächlich empfangen kann.
Um dieses Problem zu lösen wird in dieser Erfindung ein Verfahren benutzt, das die Verbindung zwischen Publisher 100 und Subscriber 200 in der Anordnung von 2 überwacht. Das Verfahren der vorliegenden Erfindung kann in einer Zustandsmaschine, die die Verbindung zwischen zwei Netzwerkteilnehmern überwacht, durchgeführt werden. Zustandsmaschinen sind schon z.B. aus der OPC-UA bekannt. Diese Maschinen sind aber nicht in der Lage zu erkennen, ob tatsächlich eine Nachricht bei den gewünschten Empfängern ankommt. An dieser Stelle setzt die vorliegende Erfindung an.
Das Verfahren wird unter Bezugnahme auf die 3 und 4 im Detail erläutert.
Insbesondere in den Figuren werden die Arbeitsverläufe jeweils eines generischen Writers eines Publishers, der die zu übertragenden Daten bereitstellt, und eines generischen Readers eines Subscribers, der die bezogenen Daten ausliest, repräsentativ dargestellt.
Wie aus dem weiteren Verlauf der Beschreibung klarer hervorgehen wird, ist ein wichtiger Punkt der vorliegenden Erfindung, dass eine Maschinensteuerung wahlweise als Publisher und/oder als Subscriber zu betreiben ist. Darüber hinaus ist es wichtig, dass die Maschinensteuerung in der Subscriber-Funktion Statusdaten generiert und dass die Statusdaten über das Netzwerk übertragen werden, damit es für einen anderen Netzwerkteilnehmer ermöglicht ist, den Status der Maschinensteuerung zu erfassen. Mit einer solchen Lösung kann z.B. ein Reader eines Netzwerkteilnehmers den Zustand eines Readers eines anderen Netzwerkteilnehmers darstellen, damit der Zustand des anderen Netzwerkteilnehmers erfasst werden kann.
In diesem Zusammenhang zeigt 3 eine schematische Darstellung eines Arbeitsablaufes eines Writers 10 eines Publishers 100 der Maschinensteuerung gemäß einer Ausführungsform der vorliegenden Erfindung. Diese Darstellung gilt auch für jeden Writer eines Publishers eines anderen Netzwerkteilnehmers.
Der Writer 10 befindet sich am Anfang in einem Ausgangsstatus 101. Diesem Status wird beispielweise ein Betriebsstatus - hier etwa mit „0“ kodiert - zugewiesen. In diesem Betriebsstatus ist die Einstellung des Writers 10 mit Nicht-Operativ gekennzeichnet. Solange die Einstellung des Writers 10 mit Nicht-Operativ gekennzeichnet ist, bleibt der Writer 10 in diesem Ausgangsstatus 101.
Sobald die Charakterisierung der Einstellung sich in Operativ ändert, wird der Betriebsstatus wechseln. Insbesondere wird der Writer 10 den Ausgangsstatus 101 verlassen und in den unteren operativen Block 102 von 3 durch einen Einstiegspunkt 103a einspringen.
Insbesondere wechselt der Writer 10 zu dem Vorbereitungsstatus 103. Diesem Status wird beispielweise ein Betriebsstatus- hier etwa mit „1“ kodiert - zugewiesen. In diesem Status wird ein Statusindikator (Flag) auf „Nicht gesetzt“ (false) eingestellt. Dieser Statusindikator sagt aus, dass die Datensätze des Writers 10 bei der Netzwerknachricht, die über das Netzwerk durch den Writer 10 übertragen wird, noch nicht gültig und benutzbar sind. Darüber hinaus wird eine Sequenznummer des Datensatzes des Publishers 100 auf null gesetzt.
Durch ein externes Event oder Methode oder sonstige Einflüsse wird das Kopieren der Datensätze des Writers 10 in eine Netzwerknachricht gestartet. Insbesondere erfolgt, nachdem ein solches Event durch den Writer 10 erfasst wurde, ein Statuswechsel von dem Vorbereitungsstatus 103 zu einem Erstellungsstatus 104. Diesem Status wird beispielsweise ein Betriebsstatus - hier etwa mit „2“ kodiert - zugewiesen.
In diesem Status 104 werden zuerst die Status des einen oder mehreren Readers 20 desselben Netzwerkteilnehmers in den Datensatz des Writers 10 kopiert und danach wird in einem zweiten Schritt der Datensatz durch eine Netzwerknachricht über das Netzwerk übertragen. In dem Erstellungsstatus 104 werden zyklisch die genannten Operationen durchgeführt und die Sequenznummer des Datensatzes wird damit hochgezählt.
Wie aus dem weiteren Verlauf der Beschreibung klarer hervorgeht, wird ein Statuswechsel des Writers 10 von dem Erstellungsstatus 104 erfolgen, wenn der Writer 10 erfasst, dass jeder Reader 20 sich in einem vorbestimmten Status (Status 4 oder 6 des Readers) befindet. Der genannte vorbestimmte Status ist ein Status, bei dem der Reader 20 bereit ist die Daten zu erhalten und diese zu konsumieren.
Insbesondere erfolgt ein Statuswechsel von dem Erstellungsstatus 104 zu einem Erzeugungsstatus 105. Diesem Status wird beispielweise einen Betriebsstatus- hier etwa mit „3“ kodiert - zugewiesen. In diesem Status wird der Statusindikator (Flag) auf „gesetzt“ (true) eingestellt. Dieser Statusindikator sagt aus, dass die Datensätze des Writers 10 des Netzwerkteilnehmers bei der Netzwerknachricht gültig sind. Darüber hinaus werden die gleichen Prozesse wiederholt, die in dem Erstellungsstatus 104 durchgeführt werden. Wenn der Writer 10 bei einem Netzwerkteilnehmer angeordnet ist, der für die Übertragung der Steuerungsdaten zuständig ist, sind in diesem Erstellungsstatus 104 durch den Writer 10 vorzugsweise auch die Steuerungsdaten über das Netzwerk übertragen.
Der Writer 10 bleibt in dem genannten Erzeugungsstatus 105 solange der eine oder mehrere Reader 20 desselben Netzwerkteilnehmers sich in einem oder mehreren vorbestimmten Status befindet/beinden, die in dem weiteren Verlauf der Beschreibung im Detail beschrieben werden.
Sollte ein Reader 20 in einen Vorwarnungsstatus wechseln, wird sich somit der Status des Writers 10 auch ändern. Insbesondere wechselt in diesem Fall der Writer 10 von dem Erzeugungsstatus 105 zu einem Status Erzeugen mit Warnung 106. Diesem Status wird beispielweise ein Betriebsstatus - hier etwa mit „4“ kodiert - zugewiesen.
Der Writer 10 bleibt in diesem Status Erzeugen mit Warnung 106 solange sich mindestens ein Reader 20 in einem Vorwarnungsstatus befindet. In diesem Status Erzeugen mit Warnung 106 bliebt der Statusindikator (Flag) auf „gesetzt“ (true) eingestellt.
Wenn der Vorwarnungsstatus des Readers 20 überwunden wird, indem z.B. die gewünschten Daten durch den Reader 20 empfangen werden, wird der Writer 10 wieder in den Erzeugungsstatus 105 wechseln. Sollte aber der Reader 20 zu einem Warnungsstatus wechseln, wird der Writer 10 auch zu einem Warnungsstatus 107 wechseln. Diesem Status wird beispielweise einen Betriebsstatus - hier etwa mit „5“ kodiert - zugewiesen.
Wie in 3 dargestellt ist, wird nach dem Zurücksetzen des Fehlers durch z.B. eine Methode der Status des Writers 10 wieder zu dem Vorbereitungsstatus 103 wechseln.
Parallel zu dem internen Verlauf des Writers 10 eines Publishers 100 läuft der interne Verlauf des Readers 20 eines Subscribers 200.
4 zeigt eine schematische Darstellung eines Teils eines Arbeitsablaufes des Readers 20 eines Subscribers 200 eines Netzwerkteilnehmers, z.B. der Maschinensteuerung, gemäß einer Ausführungsform der vorliegenden Erfindung.
Der Reader 20 besitzt hauptsächlich zu den Funktionen des Readers 10 korrespondierende Funktionen. Zusätzlich gibt es Funktionen, die für die Überwachung der Verbindung zwischen Publisher 100 und Subscriber 200 relevant sind.
Der Reader 20 befindet sich am Anfang in einem Ausgangsstatus 201. Diesem Status wird beispielweise ein Betriebsstatus - hier etwa mit „0“ kodiert - zugewiesen. In diesem Betriebsstatus ist die Einstellung des Readers 20 mit Nicht-Operativ gekennzeichnet. Solange die Einstellung des Readers 20 mit Nicht-Operativ gekennzeichnet ist, bleibt der Reader 20 in diesem Ausgangsstatus 201.
Sobald sich die Charakterisierung der Einstellung in Operativ ändert, wird der Betriebsstatus wechseln. Insbesondere wird der Reader 20 den Ausgangsstatus 201 verlassen und in den unteren operativen Block 202 von 4 durch einen Einstiegspunkt 203a springen.
Insbesondere wechselt der Reader 20 in den Vorbereitungsstatus 203. Diesem Status wird beispielweise ein Betriebsstatus - hier etwa mit „1“ kodiert - zugewiesen. In diesem Vorbereitungsstatus 203 wartet der Reader 20 auf ein externes Event oder Methode oder sonstige Einflüsse.
Insbesondere erfolgt, nachdem ein solches Event mittels des Readers 20 erfasst wurde, ein Statuswechsel von dem Vorbereitungsstatus 203 zu einem Wartestatus 204. Diesem Status wird beispielsweise ein Betriebsstatus - hier etwa mit „2“ kodiert - zugewiesen.
In diesem Wartestatus 204 wird zyklisch überprüft, ob eine Netzwerknachricht mit einem vorgegebenen IDs, die von einem Publisher 100 eines Netzwerkteilnehmers über das Netzwerk übertragen ist, empfangen ist.
Sobald eine Netzwerknachricht mit den entsprechenden IDs empfangen ist, wechselt der Reader 20 den Status. Insbesondere erfolgt ein Statuswechsel von dem Wartestatus 204 zu einem Empfangsstatus 205. Diesem Status wird beispielsweise ein Betriebsstatus - hier etwa mit „3“ kodiert - zugewiesen.
In diesem Empfangsstatus 205 wird zyklisch auf ein Signal einer externen Applikation gewartet. Dies liegt daran, dass es sein könnte, dass der Subscriber 200 prinzipiell schon bereit wäre, Daten, z.B. Steuerungsdaten, über das Netzwerk zu beziehen, aber die genannte externe Applikation (z.B. eine Funktion für die Steuerung von Getrieben) noch nicht bereit ist, die Daten tatsächlich zu empfangen um diese zu konsumieren. Es ist deswegen wichtig, dass auch die externe Applikation bereit ist, die Daten zu konsumieren (insbesondere zu empfangen und weiter zu verarbeiten).
Wenn der Reader 20 die Information empfängt, dass die externe Applikation bereit ist, die Daten tatsächlich zu konsumieren, wird der Subscriber von dem Empfangsstatus 205 zu einem Status „Konsumierbereit-“ 206 wechseln. Diesem Status wird beispielweise ein Betriebsstatus - hier etwa mit „4“ kodiert - zugewiesen.
Dieser Konsumierbereit-Status 206 ist ein der Status, bei dem der Writer 10 eines Publishers 100 den Wechsel zwischen Betriebsstatus „3“ und Betriebsstatus „4“ durchführt.
Der Reader 20 bliebt in diesem Status 206, solange er zyklisch empfängt, dass die externe Applikation bereit ist, die Daten zu konsumieren (erste Bedingung), und gleichzeitig durch die Netzwerknachricht empfängt, dass der Statusindikator (Flag) des Writers 10 auf „nicht gesetzt“ (false) eingestellt ist (zweite Bedingung).
Wenn die erste Bedingung nicht mehr erfüllt ist, wechselt der Reader 20 von dem Konsumierbereit-Status 206 zu dem Empfangsstatus 205.
Im Gegenteil, wenn der Reader 20 erkennt, dass der Statusindikator (Flag) des Writers 10 auf „gesetzt“ (true) eingestellt ist, wird der Writer 20 den Status wechseln. Insbesondere erfolgt ein Statuswechsel von dem Konsumierbereit-Status 206 zu einem Konsumstatus 207. Diesem Status wird beispielweise ein Betriebsstatus - hier etwa mit „5“ kodiert - zugewiesen.
In dem Konsumstatus 207 werden zyklisch Daten z.B. Steuerungsdaten, durch eine Netzwerknachricht erhalten und durch die externe Applikation konsumiert.
In dem Konsumstatus 207 wird auch zyklisch überprüft, ob tatsächlich der Statusindikator (Flag) des Writers 10 noch auf „gesetzt“ (true) eingestellt ist. In dem Fall, dass der Statusindikator (Flag) des Writers 10 auf „nicht gesetzt“ (false) eingestellt ist, wird der Reader 20 von dem Konsumstatus 207 zu dem Konsumierbereit-Status 206 zurückwechseln.
Sowohl der Empfangsstatus 205 als auch der Konsumierbereit-status 206 und der Konsumstatus 207 haben eine Bedingung, die erfüllt werden soll, damit der Reader 20 nicht zu einem anderen Status wechselt. Diese Bedingung ist, dass der Reader 20 in einem dieser Status bleiben wird, solange alle die gewünschten Daten, z.B. Steuerungsdaten, durch Netzwerknachrichten empfangen werden. Wenn die gewünschten Daten durch Netzwerknachrichten nicht empfangen werden, wird der Status des Readers 20 zu einem Vorwarnungsstatus 208 wechseln. Diesem Status wird beispielweise ein Betriebsstatus - hier etwa mit „6“ kodiert - zugewiesen.
Von diesem Vorwarnungsstatus 208 wird der Reader 20 zu dem vorherigen Status wechseln, wenn die gewünschten Daten durch Netzwerknachrichten wieder empfangen werden, wie schon bereits mit Bezug auf dem Writer 10 beschrieben wurde.
Wenn z.B. der Reader 20 sich in dem Vorwarnungsstatus 208 befindet und gleichzeitig der Statusindikator (Flag) des Publishers 100 noch auf „gesetzt“ (true) eingestellt ist und die externe Applikation bereit ist, die Daten zu konsumieren, und die Daten wieder empfangen werden, wechselt der Reader 20 zu dem Konsumstatus 207. Andererseits, wenn der Reader 20 sich in dem Vorwarnungsstatus befindet und gleichzeitig der Statusindikator (Flag) des Publishers 100 auf „nicht gesetzt“ (false) (der durch eine Netzwerknachricht empfangen ist) eingestellt ist und die externe Applikation bereit ist, die Daten zu konsumieren, und die Daten durch die Netzwerknachricht wieder empfangen werden, wechselt der Reader 20 zu dem Konsumierbereit-Status 206.
In dem Fall, dass der Reader 20 sich in dem Vorwarnungsstatus 208 befindet und weitere Daten nicht empfangen werden und damit eine vorbestimmte Schwelle von nicht erhaltenen Daten überschritten wird, erfolgt ein Statuswechsel von dem Vorwarnungsstatus 208 zu einem Warnungsstatus 209. Diesem Status wird beispielweise ein Betriebsstatus - hier etwa mit „7“ kodiert - zugewiesen.
Dieser Fehler kann dann über ein externes Event oder Methode zurückgesetzt werden und der Zustand wieder zu dem Vorbereitungsstatus 203 wechseln.
Aus der obigen Beschreibung geht hervor, dass die Informationen über den Status eines Subscribers eines Netzwerkteilnehmers, und insbesondere der Maschinensteuerung, durch seinen Publisher über das Netzwerk übertragen werden. Damit ist es möglich für den Publisher eines anderen Netzwerkteilnehmers den Status zu erkennen.
Das Verfahren, das beschrieben wurde, kann auch in dem Fall ausgeführt werden, dass, anders als in 2 gezeigt ist, ein Netzwerkteilnehmer einen lokalen Publisher 100 und eine Mehrzahl von lokalen Subscriber 200 aufweist, von denen einer oder mehrere gleichzeitig Statusdaten generieren und diese an den lokalen Publisher übertragen. Darüber hinaus weist jeder der Subscriber 200 jeweils einen oder mehrere Reader 20 auf. Die Statusdaten können auch über einen ausgewählten Subscriber, der die Status einsammelt und gesammelt überträgt, an den lokalen Publisher übertragen werden.
In der Beschreibung wurden die Statusdaten des Readers 100 und des Writers 200 beispielhaft mit einer bestimmten Referenznummer als Beispiel versehen. Mit dieser Lösung ist es möglich, die codierten Daten über das Netzwerk zu übertragen, damit der Empfänger (der Subscriber eines Netzwerkteilnehmers) eindeutig den Status des anderen Netzwerkteilnehmers durch diese kodierte Statusreferenz erkennen kann.
Sowohl die Maschinensteuerung als auch andere oder alle Netzwerkteilnehmer, mit denen kommuniziert wird, können konform zu einem Datenaustauschstandard betrieben werden.
Solch ein 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 den Datenaustauschstandard 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.
Während die vorliegende Erfindung unter Bezugnahme auf die oben beschriebenen Ausführungsformen beschrieben wurde, ist es für den Fachmann klar, dass es möglich ist, verschiedene Modifikationen, Variationen und Verbesserungen der vorliegenden Erfindung im Lichte der oben beschriebenen Lehre und innerhalb des Bereichs der beigefügten Ansprüche zu realisieren, ohne von dem Schutzbereich der Erfindung abzuweichen.
Darüber hinaus wurden die Bereiche, auf denen Fachleute kundig sein dürften, hier nicht beschrieben, um die beschriebene Erfindung nicht unnötig zu verschleiern.
Dementsprechend soll die Erfindung nicht durch die spezifischen veranschaulichenden Ausführungsformen beschränkt sein, sondern nur durch den Schutzbereich der beigefügten Ansprüche.
Bezugszeichenliste

10:: Writer;
100:: Publisher;
101:: Ausgangsstatus;
102:: operativer Block;
103:: Vorbereitungsstatus;
103a:: Einstiegspunkt des Vorbereitungsstatus;
104:: Erstellungsstatus;
105:: Erzeugungsstatus;
106:: Erzeugen mit Warnung Status;
107:: Warnungsstatus;
20:: Reader;
200:: Subscriber;
201:: Ausgangsstatus;
202:: operativer Block;
203:: Vorbereitungsstatus;
203a:: Einstiegspunkt des Vorbereitungsstatus;
204:: Wartestatus;
205:: Empfangsstatus;
206:: bereit zu konsumieren Status;
207:: Konsumstatus;
208:: Vorwarnungsstatus;
209:: Warnungsstatus.

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

Verfahren der Kommunikation von Maschinensteuerungsdaten eines mechatronischen Systems in einem Netzwerk mit mindestens einer Maschinensteuerung mittels eines Datenaustauschstandards, der ein Publish-/Subscribe-Kommunikationsmodell unterstützt, bei dem Publisher (100) und Subscriber (200) entkoppelt sind; wobei die Maschinensteuerung wahlweise als Publisher (100) und/oder als Subscriber (200) zu betreiben ist, und wobei die Maschinensteuerung in ihrer Subscriber-Funktion (200) Steuerungsdaten mittels des Datenaustauschstandards über das Netzwerk bezieht; dadurch gekennzeichnet, dass die Maschinensteuerung in der Subscriber-Funktion (200) Statusdaten (201-209) generiert und die Statusdaten (201-209) in der Publisher-Funktion über das Netzwerk überträgt.
Verfahren nach Anspruch 1, wobei die genannten Statusdaten (201-209) für den momentanen Bezugsstatus der zu beziehenden Steuerungsdaten relevant sind.
Verfahren nach einem der Ansprüche 1 oder 2, wobei die Maschinensteuerung die Statusdaten (201-209) dadurch überträgt, dass sie simultan zu ihrer Subscriber-Funktion (200) eine mit der Subscriber-Funktion (200) korrespondierende Publisher-Funktion (100) ausübt, mittels derer die Statusdaten (201-209) über das Netzwerk übertragen werden.
Verfahren nach einem der Ansprüche 1 bis 3, wobei das Netzwerk mindestens einen Remote-Netzwerkteilnehmer aufweist, der wahlweise als Publisher (100) und/oder als Subscriber (200) zu betreiben ist, und wobei die Maschinensteuerung in der Subscriber-Funktion (200) die Steuerungsdaten über eine Remote-Publisher-Funktion (100) des Remote-Netzwerkteilnehmers bezieht, und wobei der Remote-Netzwerkteilnehmer eine Remote-Subscriber-Funktion (200) ausübt, über die die Statusdaten der Maschinensteuerung zu beziehen sind.
Verfahren nach einem der Ansprüche 1 bis 4, wobei die Maschinensteuerung, und gegebenenfalls der Remote-Netzwerkteilnehmer, einen oder mehrere lokale Publisher (100) und eine Mehrzahl von lokalen Subscribern (200) aufweist/aufweisen, von denen einer oder mehrere gleichzeitig Statusdaten (201-209) generieren und diese an den lokalen Publisher (100) zur Übertragung über das Netzwerk übertragen, insbesondere über einen Subscriber (200), der die Status einsammelt und gesammelt überträgt.
Verfahren nach einem der Ansprüche 1 bis 5, wobei die Generierung und/oder die Aktualisierung und/oder die Übertragung von Statusdaten (201-209) zyklisch erfolgt, insbesondere in Echtzeit.
Verfahren nach einem der Ansprüche 1 bis 6, wobei die Statusdaten (201-209), die durch die Maschinensteuerung, und gegebenenfalls durch den Remote-Netzwerkteilnehmer, in der Subscriber-Funktion (200) über das Netzwerk übertragen werden, für den momentanen Bezugsstatus dedizierte oder explizite charakteristische Statusdaten sind.
Verfahren nach einem der Ansprüche 1 bis 7, wobei die Netzwerkteilnehmer, die Statusdaten (201-209) senden und/oder empfangen, dazu eine übereinstimmende, entsprechende Codierungsreferenz mit Referenz-Statuscodes verwenden, die insbesondere im Rahmen des Datenaustauschstandards einheitlich standardisiert ist.
Verfahren nach einem der Ansprüche 1 bis 8, wobei die Maschinensteuerung, und gegebenenfalls der Remote-Netzwerkteilnehmer, in der Subscriber-Funktion (200), wenn diese sich in einem Wartestatus (204) befindet, der einem der genannten Statusdaten entspricht, zyklisch überprüft, ob eine vorgegebene Netzwerknachricht empfangen wird, und zu einem Empfangsstatus (205) wechselt, der einem der genannten Statusdaten entspricht, wenn die vorgegebene Netzwerknachricht empfangen wird, wobei in dem Empfangsstatus (205) zyklisch durch den Empfang einer Netzwerknachricht der Status des Publishers (100) überprüft wird.
Verfahren nach Anspruch 9, wobei ein Netzwerkteilnehmer in der Publisher-Funktion (100) die Steuerungsdaten, insbesondere mit einem zusätzlichen Statusindikator (Flag), über das Netzwerk überträgt, nachdem eine Information über den genannten Empfangsstatus (205) aus dem einen oder mehreren Subscribern der Maschinensteuerung empfangen wird.
Verfahren nach Anspruch 10, wobei die Maschinensteuerung, und gegebenenfalls der Remote-Netzwerkteilnehmer, in der Subscriber-Funktion (200) zu einem Konsumstatus (207) wechselt, der einem der genannten Statusdaten entspricht, wenn die Steuerungsdaten, und insbesondere der zusätzliche Statusindikator (Flag), empfangen werden, wobei in dem Konsumstatus (207) zyklisch der Status des Publishers (100) und/oder der Empfangsstatus des Subscribers (200) überprüft wird.
Verfahren nach Anspruch 11, wobei die Maschinensteuerung, und gegebenenfalls der Remote-Netzwerkteilnehmer, in der Subscriber-Funktion (200) zu einem Vorwarnungsstatus (208) wechselt, der einem der genannten Statusdaten entspricht, und der über das Netzwerk übertragen wird, wenn gewünschte Maschinensteuerungsdaten nicht empfangen werden.
Verfahren nach Anspruch 12, wobei die Maschinensteuerung, und gegebenenfalls der Remote-Netzwerkteilnehmer, in der Subscriber-Funktion (200) zu einem Warnungsstatus (209) wechselt, der einem der genannten Statusdaten entspricht, und der über das Netzwerk übertragen wird, wenn eine vorbestimmte Zahl von gewünschten Maschinensteuerungsdaten über eine bestimmte Zeit nicht empfangen werden.
Verfahren nach Anspruch 12, wobei die Maschinensteuerung, und gegebenenfalls der Remote-Netzwerkteilnehmer, in der Subscriber-Funktion (200) wieder zu dem Konsumstatus (207) wechselt, wenn die gewünschten Maschinensteuerungsdaten wieder empfangen werden.
Verfahren nach einem der Ansprüche 1 bis 14, wobei der verwendete Datenaustauschstandard OPC-UA (Open Platform Communication - Unified Architecture) ist und/oder die verwendeten Übertragungsmechanismen und/oder das Publish-/Subscribe-Kommunikationsmodell und/oder die übertragenen Daten, insbesondere Steuerungsdaten und/oder Statusdaten bzw. deren Datenstruktur und/oder Datenformat, OPC-UA-konform sind.
Maschinensteuerung, die dazu eingerichtet ist, ein Verfahren nach einem der Ansprüche 1 bis 15 auszuführen.
Computerprogrammprodukt für eine Rechnereinrichtung, insbesondere für eine Maschinensteuerung, welches bei Ausführung auf einer Rechnereinrichtung ein Verfahren nach einem der Ansprüche 1 bis 15 ausführt.