DLR für redundante Kommunikation im Ring mit Ethernet/IP

Anbieter zum Thema

ISH Ingenieursozietät GmbH

Würth Elektronik eiSos GmbH & Co. KG

Cadlog Group

Beacon-based DLR erkennt alle Fehler

Beacons sind in der Lage, alle Arten von Fehlern zu erkennen. Gebrochene Kabel, Stromausfälle oder andere physikalische Probleme können auch, und oft schneller, durch die Nachbarschaftsüberwachung detektiert werden. Stellt die Nachbarschaftsüberwachung ein Problem fest, informiert sie umgehend den Supervisor. Wird der Ring wieder geschlossen, können die Beacons erneut frei zirkulieren. Die Beacons verbreiten die gute Nachricht schnellstmöglich, indem sie den Netzwerkstatus wieder von FAULTED auf NORMAL setzen. Die Versendung und Überwachung der Beacons erfolgt größtenteils in Hardware, deshalb wird in diesem Zusammenhang auch von Hardware-DLR gesprochen – im Gegensatz zu Announced-Based-DLR.

So funktioniert der Anounced-based DLR

Mit Announced-Based-DLR gibt es eine Rückfalloption, sollte ein Feldgerät den DLR nicht mit Hardware unterstützen. Die Beacons werden dann nur durchgeleitet, aber nicht verstanden und verarbeitet. Der Ring-Supervisor sendet für diese Devices in regelmäßigen Abständen Informationen über den Ring-Status zu, da dieser nicht mehr den Beacons entnommen werden kann. Der Ring Supervisor nutzt diese Ankündigungen aber nicht um den Status des Rings zu prüfen, dafür werden auch weiterhin die Beacons genutzt. Der Supervisor selbst muss also immer Hardware-DLR unterstützen. Announced-Based-DLR muss alle Statusupdates in Software auswerten, somit erzeugt das eine gewisse Last Device. Daher spricht man auch von Software-DLR.

Bildergalerie

Bildergalerie mit 7 Bildern

Beacons werden typischerweise alle 400 μs vom Supervisor versendet. Diese Standardeinstellung kann je nach Applikation geändert werden. Der Beacon Timeout hingegen ist, wie auch einige andere Parameter, von mehreren Faktoren abhängig. In erster Linie entscheidet natürlich die Anzahl der Devices im Ring darüber, wie lange eine Beacon durch den Ring braucht. Des Weiteren ist der Ethernet-Mode zwischen den Geräten wichtig. Sollte sich ein Gerät (aus was für Gründen auch immer) im Ring auf 10 MBit/s eingestellt sein, dann hätte das Folgen für die Zeit, in der ein Beacon durch den Ring unterwegs ist. Ein Cut-Through-Switch verbessert das Timing und sollte für größere Ringe, aber auch für lange Linien Standard sein. Die Tabelle (die Sie im Online-Beitrag finden) ist den Unterlagen der ODVA entnommen. Hier werden die wichtigsten Parameter exemplarisch für verschiedene Modi und Netzgrößen dargestellt. Alle Zeiten sind in μs angeben.

Die Netzwerklast der Beacons beträgt nur 1,75%

Aus der Tabelle wird deutlich sichtbar, dass Announced-Based-DLR langsamer ist als Beacon-Based-DLR. Übrigens sollte das Beacon-Interval immer weniger als der Hälfte der schnellsten RPI (Request Paket Interval, I/O-Zykluszeit bei EtherNet/IP) der Applikation entsprechen, damit keine Applikations-Timeouts auftreten. Mit der Standardvorgabe 400 µs sind also RPIs bis 1 ms abgedeckt. Die Beacons, die 64 Byte lang sind, stellen dabei nur 1,75% der gesamten Netzwerklast dar.

DLR wurde als Ergänzung zu EtherNet/IP entwickelt, obwohl es natürlich grundsätzlich auch mit anderen Protokollen eingesetzt werden könnte. In EtherNet/IP wird DLR durch ein spezielles DLR-Objekt unterstützt (Class ID 0x47). Das Objekt im Supervisor hat dabei andere Attribute als im Device. Durch das Objekt sind der Zustand des Rings (NORMAL/FAULTED) und die aktuelle Topologie (RING/LINE) jederzeit individuell auch von der Applikation abfragbar. Außerdem lässt sich über das Objekt im Supervisor zum Beispiel das Beacon-Interval anpassen.

Die DLR-Lösung mit dem 3-Port Switch fido2100

Mit dem fido2100 3-Port Switch (Bild 5) bietet Innoavsic eine geeignete Lösung für EtherNet/IP und DLR. Es können sowohl Devices als auch DLR-Supervisoren damit aufgebaut werden. Die Beacons werden weitestgehend von der Hardware verarbeitet. Außerdem ist der fido2100 ein Cut-Through Switch, was bei größeren Ringen oder längeren Linien sehr empfehlenswert ist – vor allem, wenn man mit kleinen RPIs arbeiten möchte.

Der fido2100 kann mit jedem Host-Prozessor mit MII-Schnittstelle verwendet werden. Die von Innovasic kostenlos zur Verfügung gestellte Support-Bibliothek ist in C geschrieben und lässt sich nach Bedarf portieren. Ebenfalls möglich ist die Zeit-Synchronisation nach IEEE1588V2, sodass auch eine Unterstützung von CIP-Sync und CIP-Motion Profilen gegeben ist.

Noch einfacher wird die Entwicklung mit der RapID-Plattform (Bild 6) von Innovasic Semiconductor. Die RapID-Plattform für EtherNet/IP mit DLR kombiniert den fido2100 mit dem bekannten fido1100-Kommunikationsprozessor von Innovasic. Wie alle RapID-Plattform-Produkte bietet auch diese Variante PriorityChannel für robuste Performance auch bei hohen Netzlasten und das Unified Interface zur einfachen Integration mit einem Hostprozessor.

Fazit: Mit DLR lassen Ring-Topologien auch mit EtherNet/IP realisieren; dabei werden Fehler schnell erkannt und die Topologie des Netzes im Fehlerfall angepasst. DLR funktioniert im Alltag schnell und geräuschlos.

* Volker Goller ist Field Application Manager bei Innovasic Semiconductor, Aachen

(ID:38249520)