-
Die vorliegende Erfindung betrifft ein Diagnose-Beacon-Telegramm für ein Kommunikationsnetz und dessen Betrieb, wobei das Kommunikationsnetz zumindest einen Master und mindestens einen Slave-Knoten umfasst, sowie ein Verfahren zum Betrieb von Kommunikationsnetzen gemäß der jeweiligen Oberbegriffe der unabhängigen Patentansprüche.
-
Bei Maschinen der Automatisierungstechnik kann die Diagnose von Problemen sehr aufwändig sein; insbesondere wenn es sich um große, verteilte Anlagen handelt.
-
Die einzelnen Komponenten einer Automatisierungsanlage (also die Netzknoten) werden heutzutage immer mehr über lndustrial-Ethernet vernetzt. Allerdings gibt es hier viele unterschiedliche Standards, die untereinander nicht kompatibel sind. Aus diesem Grund sind auch Diagnosemechanismen in der Regel nicht zueinander kompatibel. Das hat zur Folge, dass bei Produkten, die mit verschiedenen lndustrial-Ethernet Systemen lauffähig sind, jeweils verschiedene Diagnosemechanismen vom Hersteller implementiert und vom Anwender genutzt werden müssen.
-
Mit OPC UA wurde eine Schnittstelle geschaffen, die unabhängig vom lndustrial-Ethernet-System ist und auch eine Diagnose ermöglicht. Allerdings ist der Implementierungsaufwand von OPC UA hoch. Zusätzlich muss je nach lndustrial-Ethernet-System der Bus erst hochgefahren sein, bis OPC-UA Übertragungen erfolgen können. Dies wiederum ist, insbesondere im Fehlerfall, nicht immer möglich. Weiterhin handelt es sich um ein bidirektionales Protokoll, so dass nur Diagnosedaten übertragen werden, wenn diese explizit angefordert werden. Dies ist in vielen Fällen nicht praktikabel.
-
Um nun einen Mechanismus zu definieren, bei welchem die oben genannten Probleme behoben sind, der Implementierungsaufwand besonders gering ist und welcher gleichzeitig in besonders einfacher Art und Weise insbesondere Diagnosedaten überträgt, macht die vorliegende Erfindung unter anderem von der Idee Gebrauch, dass ein Diagnose-Beacon-Telegramm verwendet wird, welches Diagnosedaten eines Slave-Knotens und/oder des Masters beinhaltet und das Diagnose-Beacon-Telegramm frei von Betriebsdaten zum Betrieb, des Kommunikationsnetzes ist. Der Betriebsdatentransfer in dem Kommunikationsnetz der Automatisierungsanlage beinhaltet Daten wie etwa Steuerdaten, Sollwerte und Istwerte, die nicht spezifisch zur Diagnose dienen.
-
Insofern wird ein Diagnose-Beacon-Telegramm vorgeschlagen, welches anstatt Betriebsdaten Diagnosedaten, insbesondere nur Diagnosedaten, verwendet, so dass sich also das vorliegende Diagnose-Beacon-Telegramm auf solche Daten konzentrieren kann, welche insbesondere zur Diagnose des gesamten Systems genutzt werden können.
-
Mit anderen Worten können durch den Netzknoten beispielsweise zyklisch Telegramme (sogenannte „Beacon“-Telegramme) versendet werden, die von anderen Netzknoten ausgewertet werden können, aber auch nicht ausgewertet werden müssen. Diese Beacon- Telegramme sollen daher Diagnose-Daten wie zum Beispiel den Zustand von Automatisierungskomponenten enthalten.
-
Der große Vorteil dieses Diagnose-Beacon-Telegramms ist daher, dass dieser Mechanismus es ermöglicht, dass keine aktive Komponente in der Automatisierungsanlage, die explizit Diagnosedaten anfordert, notwendig ist; die einzelnen Komponenten können beispielsweise in vorgegebenen Zeitabständen, d.h. regelmäßig und/oder automatisch derartige Diagnose-Beacon-Telegramme aussenden, die z.B. auch in Aufzeichnungen eines Busdatentransfers automatisch enthalten sind. Insbesondere kann nämlich der Verlust von Beacon-Telegrammen auf Leistungsdefekte hindeuten und ermöglicht somit zusätzlich das Orten von Defekten.
-
Beacon-Mechanismen sind aus anderen Bereichen bekannt. Ursprünglich stammt der Begriff aus der Funktechnik, wo Baken (bzw. engl. Beacons) zur Orientierung oder zur Analyse von Funkausbreitungsbedingungen genutzt wurden. Heutzutage werden Beacon-Mechanismen zum Beispiel bei Wireless LAN verwendet, wobei ein Access Point regelmäßig kleine Datenpakete aussendet, damit Geräte diesen Access Point erkennen können.
-
Ein großer Vorteil bei der Nutzung von Beacon-Telegrammen gegenüber anderen Verfahren ist, dass eine Funktion auch möglich ist, wenn der Feldbus bzw. das lndustrial-Ethernet-Netz noch nicht hochgefahren ist, wobei das Hochfahren aufgrund einer Fehlersituation nicht möglich sein könnte.
-
Vorteilhaft ist dabei, wenn ein Verfahren genutzt wird, das bewirkt, dass nicht alle Netzteilnehmer gleichzeitig die Beacon-Telegramme aussenden, um keinen „Peak“ in der Gesamtdatenrate zu diesen Zeitpunkten zu erzeugen, und dadurch u. U. Probleme zu verursachen. Hierzu können aus anderen Bereichen bekannte Mechanismen (z.B. ein so genannter Back-Off'-Algorithmus) verwendet werden.
-
Gemäß zumindest einer Ausführungsform ist das Diagnose-Beacon-Telegramm für einen Betrieb eines Kommunikationsnetzes eingerichtet und vorgesehen, wobei das Kommunikationsnetz mindestens einen Master und mindestens einen Slave-Knoten umfasst, wobei das Diagnose-Beacon-Telegramm Diagnosedaten des Slave-Knotens und/oder des Masters beinhaltet, und das Diagnose-Beacon-Telegramm frei von Betriebsdaten zum Betrieb des Kommunikationsnetzes ist.
-
Gemäß zumindest einer Ausführungsform umfasst das Diagnose-Beacon-Telegramm zusätzlich zumindest eines der folgenden Diagnose-Felder:
- – Identifizierungsfeld zum Identifizieren des Slave-Knotens,
- – die Firmware-Version,
- – Daten zur Topologieermittlung des Kommunikationsnetzes.
-
Zum Aufbau des Diagnose-Beacon-Telegramms können Mechanismen, beispielsweise in Form von XML (extensible mark-up language) genutzt werden, um die Konfigurierbarkeit z.B. auf Basis von Marken zu gewährleisten. Auch denkbar ist aus Gründen der Übertragungseffizienz ein binäres Format, anders als bei XML.
-
Gemäß zumindest einer Ausführungsform ist das Diagnose-Beacon-Telegramm Netzwerktechnologie und/oder Netzwerktopologie-unabhängig. Dies bietet den entscheidenden Vorteil, dass insbesondere unabhängig von der konkreten Ausgestaltung der Datenleitstruktur des Kommunikationssystems (Ringtopolgie oder andere Netzwerktopologien) ein Diagnose-Beacon-Telegramm für ein Kommunikationsnetz generiert, versendet und empfangen werden kann.
-
Insofern ist das hier beschriebene Diagnose-Beacon-Telegramm nicht begrenzt auf eine einzige Netzwerk-Topologie und muss auch nicht gezwungenermaßen auf die konkrete Netzwerk-Topologie des Kommunikationsnetzes explizit und detailgerecht angepasst werden, sondern kann in ein beispielsweise bereits bestehendes Stern- oder Ringnetz integriert werden.
-
Des Weiteren umfasst das hier beschriebene Kommunikationsnetz mindestens einen Master sowie mindestens einen Slave-Knoten, wobei der Master und/oder der Slave-Knoten zumindest ein Diagnose-Beacon-Telegramm nach zumindest einem der vorhergehenden Ausführungsformen aussendet, und wobei das Diagnose-Beacon-Telegramm Diagnosedaten des Slave-Knotens und/oder des Masters beinhaltet.
-
Gemäß zumindest einer Ausführungsform umfasst das Kommunikationsnetz zumindest eine Monitoring-Einheit, welche dazu eingerichtet und dafür vorgesehen ist, Diagnose-Beacon-Telegramme zu speichern und/oder dieses, insbesondere unmittelbar, zu interpretieren.
-
Dabei kann die Monitoring-Einheit ein von dem Master separates Bauteil sein oder in den Master und/oder einen oder mehrere Slave-Knoten integriert angeordnet sein.
-
Die Monitoring-Einheit kann dazu in ein vorhandenes Gerät integriert werden. Dazu kann ein Funktionsbaustein, z.B. in Form eines lEC-Blocks oder einer C-Bibliothek, bereitgestellt werden.
-
Die Monitoring-Einheit kann ebenfalls als separates Gerät implementiert werden. Dieses verfügt über mindestens eine Kommunikationsschnittstelle (um direkt oder über eine zusätzliche Anschalteinheit an das lndustrial-Ethernet Netzwerk angeschlossen zu werden).
-
Das Gerät kann mit einem "Push-Service" ausgestattet werden um die Beacon-Signale per Knopfdruck an weitere Geräte zu versenden.
-
Um den Bedienkomfort zu erhöhen, sind weitere Ausführungsmerkmale wie z. B. ein Touch-Display denkbar. Insbesondere ist für die separate Anordnung auch eine Ausführung in hoher Schutzart zur Nutzung im Feld vorteilhaft.
-
Insbesondere kann die Monitoring-Einheit in zwei Varianten vorkommen:
- – Als Einheit, die die Beacon-Signale, insbesondere nur, aufzeichnet
- – Als Einheit, die die Beacon-Signale interpretiert.
-
Beide Varianten können in ein vorhandenes Gerät integriert oder in einem separaten Gerät (ggf. mit zusätzlichen Funktionen) implementiert werden.
-
Für den Fall, dass die Monitoring-Einheit, insbesondere nur, Daten aufzeichnet kann insbesondere gelten:
- – Empfängt Beacon-Diagramme und speichert diese.
Die Daten können anschließend (z. B. per drahtloser Verbindung, per USB-Stick o.ä.) auf eine andere Monitoring-Einheit übertragen und dort interpretiert werden.
-
Mögliche Implementierung: Ringpuffer, um die letzten Beacon-Telegramme, einer vorbestimmbaren Anzahl, zu speichern.
-
Für den Fall, dass die Monitoring-Einheit, insbesondere nur, Daten interpretiert, kann insbesondere gelten:
Das Gerät kann die Beacon-Telegramme interpretieren und kann über eine Analyse-Ergebnis-Anzeige verfügen, z.B. in Form von LEDs. Falls das Analyse-Ergebnis an ein separates Gerät mit Anzeigefunktion weitergeleitet wird ist eine Analyse-Ergebnis-Anzeige im Gerät natürlich nicht zwingend erforderlich.
-
Mögliche Interpretation: z.B. Erstellung von Topologie-Übersicht der Anlage (und ggf. Abgleich mit hinterlegter gewünschter Topologie); Fehlermeldung falls von einem Netzknoten keine Beacons (mehr) ankommen, etc. (vgl. nachfolgend beschriebene Anwendungsfälle).
-
Gemäß zumindest einer Ausführungsform umfasst das Kommunikationsnetz zumindest eine Aussendeeinheit, welche dazu eingerichtet und dafür vorgesehen ist, in einstellbaren Aussendeintervallen zumindest ein Diagnose-Beacon-Telegramm von dem Master und/oder von dem Slave-Knoten zu versenden.
-
Insbesondere kann es vorteilhaft sein, das Beacon-Telegramm konfigurierbar auszulegen, um verschiedene Anwendungsfälle abbilden zu können.
-
Des Weiteren umfasst die vorliegende Erfindung ein Verfahren zum Betrieb zumindest eines Kommunikationsnetzes, gemäß zumindest einem der oben genannten Ausführungsformen. Dies heißt, dass alle für das hier beschriebene Kommunikationsnetz offenbarten Merkmale auch für das hier beschriebene Verfahren offenbart sind und umgekehrt.
-
Erfindungswesentlich ist, dass das hier beschriebene Verfahren einen Schritt umfasst, wonach zumindest ein Diagnose-Beacon-Telegramm durch zumindest einen Master und/oder einen Slave-Knoten empfangen und/oder versendet wird, wobei des Diagnose-Beacon-Telegramm Diagnosedaten des Masters und/oder des Slave-Knotens beinhaltet und das Diagnose-Beacon-Telegramm frei von Betriebsdaten ist.
-
Dabei weist das hier beschriebene Verfahren die gleichen wie in Verbindung mit dem hier beschriebenen Kommunikationsnetz und/oder wie in Verbindung mit dem hier beschriebenen Diagnose-Beacon-Telegramm offenbarten Vorteile und Ausgestaltungen auf.
-
Gemäß zumindest einer Ausführungsform umfasst das Verfahren einen weiteren Schritt, wonach von dem Master und/oder von dem Slave-Knoten das Diagnose-Beacon-Telegramm, insbesondere in regelmäßigen, zeitlichen Abständen, ausgesendet und/oder empfangen wird.
-
Dabei kann in einem Hochfahrbetrieb des Kommunikationsnetzes das Diagnose-Beacon-Telegramm empfangen und/oder gesendet werden.
-
Grundsätzlich ist eine Inbetriebnahme, d.h. ein hier beschriebener Hochfahrbetrieb des Kommunikationsnetzes dadurch gekennzeichnet, dass während des Hochfahrbetriebes das Kommunikationsnetz in seiner eigentlichen Arbeitsfunktion zumindest noch nicht vollständig einsatzfähig ist und daher zumindest noch nicht alle Einsatznormen, zumindest nicht vollständig, erfüllt, jedoch grundsätzlich bereits während der Inbetriebnahme eine Kommunikation des Masters mit dem Slave-Knoten mittels des hier beschriebenen Diagnose-Beacon-Telegramms bereits stattfinden kann. Denkbar ist nämlich, dass bereits während der Inbetriebnahme folgende Aktionen einzeln oder in zeitlich sequentieller Reihenfolge durchgeführt werden können:
-
Während der Inbetriebnahme:
- – Validierung der Komponenten (Fragestellung: Sind die richtigen Komponenten verbaut?)
- – Topologieüberprüfung
- – Validierung der Verkabelung
- – Stimmt die Zuordnung Umrichter-Motor (Fragestellung: Hängt an jedem Umrichter der richtige Motor?)
- – Überprüfung der Adressvergabe (Fragestellung: Sind Kommunikationsadressen doppelt belegt?)
- – Validierung von Software- oder Firmware-Versionen
- – Überprüfen ob Parameterinitialisierung erfolgt ist.
-
Darüber hinaus ist denkbar, dass in einem Arbeitsbetrieb, welcher sich insbesondere von einem Hochfahrbetrieb zumindest dadurch unterscheidet, dass im Arbeitsbetrieb das Kommunikationsnetz den Arbeitsnormanforderungen genügt und somit mittels des Kommunikationsnetzes ein Automatisierungsbetrieb möglich ist, durch folgende Aktionen aus:
-
Während des Betriebs:
- – Nach Software/Firmware-Update: Validierung Software/Firmware-Versionen
- – Erkennung von Gerätefehlern
- – Erkennung von Verbindungsfehlern (Feldbusfehler, Kabelbruch)
- – Bei Gerätetausch; Fragestellung: Wurde das richtige Gerät ausgebaut?
- – Denkbar wäre auch eine Zustandsüberwachung (ausgewählte Parameter könnten mitgesendet und in Software ausgewertet werden: Warnung bei Grenzwertüberschreitung)
- – Optionale Aufforderung zur Wartung nach einer bestimmten Anzahl von Betriebsstunden
-
Darüber hinaus betrifft die Erfindung zudem ein Verfahren zum Betrieb eines Großkommunikationsnetzes, umfassend zumindest zwei Kommunikationsnetze gemäß zumindest einer der vorherigen Ausführungsformen, wobei in einem Arbeitsbetrieb und/oder Hochfahrbetrieb nur ein Teil der Netzwerkteilnehmer Diagnose-Beacon-Telegramme empfängt und/oder versendet.
-
Maßgeblich ist bei einer derartigen Ausgestaltung, dass bei einem derartigen Verfahren des Großkommunikationsnetzwerkes nicht alle Netzteilnehmer gleichzeitig die Beacon-Telegramme senden, um einen „Peak“ in der Gesamtdatenrate zu diesen Zeitpunkten (und dadurch unter Umständen verursachte Probleme) zu vermeiden. Hierzu können aus anderen Bereichen bekannte Mechanismen (z.B. ein sogenannter „Back-off-Algorithmus“) verwendet werden.
-
In einer derartigen Ausgestaltung des hier beschriebenen Verfahrens zum Betrieb eines Großkommunikationsnetzwerkes ist daher das hier beschriebene Großkommunikationsnetzwerk vor einer Überlastung geschützt.
-
Weitere vorteilhafte Ausgestaltungen und Vorteile der Erfindung können aus der an die Beschreibung angehängten Figur erkannt werden.
-
Dabei zeigt die
-
1 sowohl ein Kommunikationsnetz als auch ein hier beschriebenes Verfahren zum Betrieb eines solchen Kommunikationsnetzes, wobei das Kommunikationsnetz ein Ausführungsbeispiel eines hier beschriebenen Diagnose-Beacon-Telegramms umfasst.
-
Die hier beschriebenen Elemente können insbesondere, wie in den Figuren ersichtlich, übertrieben groß dargestellt sein. Es sei jedoch darauf hingewiesen, dass gleiche oder gleichwirkende Bestandteile jeweils mit dem gleichen Bezugszeichen versehen sind.
-
Insbesondere ist in der 1 eine Systemarchitektur eines Ausführungsbeispiels eines hier beschriebenen Kommunikationsnetzes 1 dargestellt, wobei in einem Slave-Knoten SN (auch Netzknoten) jeweils beispielhaft eine Aussendeeinheit A, welche dazu eingerichtet und dafür vorgesehen ist, in einstellbaren Intervallen ein Diagnose-Beacon-Telegramm 100 von einem Master GW zu dem Slave-Knoten SN oder umgekehrt zu versenden, implementiert ist. Diese Signale des Diagnose-Beacon-Telegramms 100 können, wie in dem Ausführungsbeispiel der 1 dargestellt, von einer Monitoring-Einheit M aufgezeichnet und/oder sofort interpretiert werden. Dabei werden die Signale von einem Industrial-Ethernet 100A zwischen den Slave-Knoten SN und dem Master GW versendet.
-
Folgende Richtlinien bei der Implementierung des Beacon-Mechanismus sind generell vorteilhaft:
- – Feldbus-unabhängiger Mechanismus (d.h. Implementierung auf Ethernet- oder IP-Ebene)
- – Erweiterbares Format von Beacon-Telegrammen
- – Je Netzknoten konfigurierbare Inhalte & Ausstrahlungsintervalle
-
Die Monitoring-Einheit M kann dabei als separates Gerät implementiert werden oder aber auch in ein vorhandenes Gerät (Master oder Slave) integriert werden. Auch mehrere Monitoring-Einheiten M sind innerhalb eines Netzwerkes möglich.
-
Ist die Monitoring-Einheit M als separates Gerät ausgeführt, kann sie direkt an das Kommunikationsnetz 1 angeschlossen sein oder über eine zusätzliche Anbindungseinheit 200 (z.B. Router) mit dem Kommunikationsnetz 1 verbunden sein.
-
Dieser Fall wäre insbesondere für eine drahtlose Anwendung der Monitoring-Einheit M vorteilhaft. Dabei umfasst das Ausführungsbeispiel der 1 eine Anbindungseinheit 200, welche Signale des Diagnose-Beacon-Telegramms 100 anstatt auszuwerten, lediglich an eine Einheit 300 zum Aufzeichnen und/oder Empfangen von Beacon-Signalen des Diagnose-Beacon-Telegramms 100 weiterleitet. Es sind nämlich die Einheit 300 zum Aufzeichnen und/oder Empfangen von Beacon-Signalen und die Einheit 200 zum Anbinden der Monitoring-Einheit M über beispielsweise eine drahtlose oder aber auch über eine drahtgebundene Verbindung in Kommunikationsverbindung miteinander.
-
Es sei nämlich bemerkt, dass ein Kernelement der vorliegenden Erfindung ist, dass das hier beschriebene Betriebsverfahren zum Betrieb des in der 1 dargestellten Kommunikationsnetzes 1 nicht auf eine Linienstruktur, d.h. nicht auf eine einzige Netzwerktopologie beschränkt ist, sondern abweichend von der 1 auch beispielsweise beliebig weitere Netzwerktopologien (z.B. Ring- oder Baumtopologien) angewandt werden können. In diesem Fall sollte dann jedoch sichergestellt werden, dass alle Slave-Knoten SN Diagnose-Beacon-Telegramme 100 weiterleiten können.
-
Die Erfindung ist nicht auf die hier beschriebene Ausführungsform beschränkt, sondern es sind alle Merkmale vorhanden, welche miteinander kombiniert werden können, solange dies im Rahmen des erfindungsgemäßen Gedankens liegt.
-
Bezugszeichenliste
-
- 1
- Kommunikationsnetz
- 100
- Diagnose-Beacon-Telegramm
- 100A
- Industrial-Ethernet
- 200
- Anbindungseinheit
- 300
- Einheit zum Aufzeichnen und/oder Empfangen
- A
- Aussendeeinheit
- M
- Monitoring-Einheit
- GW
- Master
- SN
- Slave-Knoten
