Dieser Beitrag zeigt zunächst, wie die seit einigen Jahren verfügbaren EtherNet/IP-Geräte Echtzeitanforderungen erfüllen können. Danach wird erläutert, welche Maßnahmen für die Erweiterung CIP Sync ergriffen wurden, um den Echtzeitbetrieb erheblich zu verbessern, ohne dabei die TCP/IP-Basis zu verlassen. Schließlich zeigt das auf CIP Sync basierende Anwendungsprofil CIP Motion1, dass sich auf dieser Basis koordinierte Antriebe mit einem Synchronisationsjitter von deutlich weniger als einer Mikrosekunde betreiben lassen.
· Grundsätzliches zu EtherNet/IP:
EtherNet/IP ist ein Protokoll für Industrie-Anwendungen, welches auf den bekannten und weit verbreiteten Protokollschichten TCP/IP und UDP/IP aufsetzt. Im Gegensatz zu einigen anderen Ethernet-basierten Lösungen werden diese Protokollschichten bei EtherNet/IP unverändert übernommen, es wird lediglich die schon von DeviceNet#1 und ControlNet# bekannte Anwendungsschicht CIP#1 (Common Industrial Protocol) auf Ethernet übertragen. Abbildung 1 zeigt den Zusammenhang zwischen EtherNet/IP und den anderen Protokollen auf TCP/IP-Basis. Durch das direkte Aufsetzen auf den bekannten Transportmechanismen ist in allen Situationen eine vollständige Kompatibilität zu Standardprotokollen auf TCP/IP-Basis auch ohne zusätzliche Maßnahmen gewährleistet. Prinzipiell unterscheidet CIP zwischen E/A-Nachrichten (Implicit Messages, im Rahmen von EtherNet/IP über UPD/IP übertragen) und individuellen Frage/Antwort-Telegrammen zur Konfiguration (Explicit Messages, im Rahmen von EtherNet/IP über TCP/IP übertragen). In Zusammenhang mit dem Echtzeitverhalten von EtherNet/IP ist natürlich in erster Linie das Verhalten der E/A-Nachrichten über UDP/IP von Bedeutung. Abbildung 1: CIP und andere Ethernet-Protokolle
Performance von EtherNet/IP ohne CIP Sync# und CIP Motion#
Die Echtzeit-Performance von einem EtherNet/IP-System in seiner bisherigen Form hängt von einer ganzen Reihe von Parametern ab. Zunächst einmal sind das die Performance-Parameter der angeschlossenen Geräte. Neben einer durch die Prozessorgeschwindigkeit und das Betriebssystem gegebenen Verarbeitungsgeschwindigkeit ist noch wichtig, welche Ethernet-Rahmen mit welcher Priorität bearbeitet werden. Grundsätzlich ist zur Erzielungen einer guten Echtzeit-Performance einer Bevorzugung der UPD-Rahmen für EtherNet/IP vorzusehen. Damit ist innerhalb der einzelnen Geräte zunächst einmal alles getan, was sich zur Beschleunigung der Nachrichtenverarbeitung tun lässt; alles Weitere findet außerhalb des Geräts statt. EtherNet/IP in seiner derzeitigen Form wird mit einer physikalischen Übertragungsschicht von 10 oder 100 MBit/s eingesetzt. In der EtherNet/IP-Spezifikation selbst wird allerdings bewusst keine Aussage dazu gemacht, wie die Infrastruktur dazu aussehen soll, der Anwender hat also freie Hand. Die aus Kostengründen noch gelegentlich verwendeten Hubs sind grundsätzlich in Systemen mit Echtzeit-Anforderungen nicht zu empfehlen, da dann durch die entstehenden Kollisionen unkalkulierbare Verzögerungen entstehen. Alle weiteren Betrachtungen stützen sich daher auf die Verwendung von Switches und dabei speziell auf den Vollduplex-Betrieb zu den einzelnen Geräten, da auch dort sonst noch unkalkulierbare Verzögerungen durch Kollisionen entstehen können. Abbildung 2 zeigt den grundsätzlichen Durchlauf eines Signals durch ein System mit EtherNet/IP-Geräten, bestehend aus einem Eingangsgerät, einer SPS mit EtherNet/IP-Interface, einem Ausgangsgerät, sowie einem Ethernet-Switch. Die Übertragung der E/A-Daten auf EtherNet/IP findet in diesem Beispiel zyklisch statt; die Zykluszeit wird durch die RPI-Timer (RPI = Requested Packet Interval) bestimmt. Solange das System nur aus den gezeigten Geräten besteht, wird die Gesamtdurchlaufzeit somit in erster Linie bestimmt durch die RPI-Zeiten und die Verarbeitungszeit in der SPS (beides meist im Bereich von wenigen Millisekunden), die Latenzzeit im Switch (wenige Mikrosekunden) und ein Queuing im Adapter können dagegen vernachlässigt werden. Reale Systeme enthalten jedoch eine Vielzahl von E/A-Geräten, so dass es zu Queuing-Effekten im Switch und im EtherNet/IP-Adapter der SPS kommen kann. Dabei zeigt sich in den heute verwendeten Systemen, dass die Queuing-Effekte im EtherNet/IP-Adapter weit größer sind als die im Switch, so dass es ausreicht, die Adaptereffekte zu berücksichtigen und die Verzögerung im Switch als konstant anzusehen. Dies liegt daran, dass die physikalische Übertragung über Ethernet vom Switch in voller Geschwindigkeit unterstützt eine weit höhere Nachrichtenrate unterstützt als die Applikationen der Geräte empfangen oder versenden können. Durch die langsamere Abarbeitung im Zielgerät ist daher nur die erste Durchlaufverzögerung im Switch maßgebend; alle weiteren direkt danach versendeten Rahmen warten also in der Queue des Endgerätes und nicht im Switch. Die Auslastung des physikalischen Kanals liegt in diesen Fällen meist nur bei wenigen Prozent. Abbildung 2: Durchlaufzeiten in einem EtherNet/IP-System Damit ergibt sich ein Zeitverhalten, das in etwa dem eines Feldbusses entspricht. Eine detaillierte Anleitung zur Berechnung der Verzögerungszeiten findet sich in [1]. Die wesentlichen Aussagen dieser Berechnung besagen, dass das resultierende Zeitverhalten des Gesamtsystems bei seinen Minimalzeiten durch die grundsätzlichen Übertragungs- und Programmdurchlaufzeiten bestimmt wird, eventuell noch je nach eingesetzter SPS durch die SPS-Zykluszeit, nicht aber durch Queuing-Effekte. Bei den maximalen Verzögerungszeiten dagegen dominieren die RPI-Zeiten in Verbindung mit den Queuing-Effekten und der Zykluszeit der SPS. Dabei ist natürlich zu berücksichtigen, dass ein Verkleinern der RPI-Werte mehr Busverkehr zur Folge hat und somit bei nicht korrekter Auslegung zu Überlastung auf Grund von Queuings-Effekten führen kann. Die Leistungsfähigkeit der einzelnen Geräte kann über Einträge in der [Capacity] Section der Geräte-EDS (Electronic Data Sheet) charakterisiert werden [2]. Ein Tool zur Überprüfung des Systemverhaltens kann dann diese Werte auslesen, auf mögliche Überlastungen hin überprüfen und Abhilfemaßnahmen vorschlagen.
· Koexistenz mit #Fremdgeräten#
Da alle Ethernet-Rahmen über TCP/IP- oder UDP/IP-Mechanismen übertragen werden, ist nach wie vor eine komplette Offenheit des Systems gegenüber #Fremdgeräten# gegeben. Alle anderen Protokolle auf der Basis von TCP/IP und UDP/IP werden einwandfrei toleriert. Überlastungseffekte durch diese #Fremdprotokolle# sind im Allgemeinen nicht zu erwarten und zwar aus folgenden Gründen: o Sämtlicher TCP/IP-Verkehr ist als Punkt-zu-Punkt-Verkehr eingerichtet. Nur die direkt betroffenen Geräte sind Start- oder Zielpunkt der Nachrichten. Bei Bevorzugung des UDP-Verkehrs von EtherNet/IP (siehe oben) ist keine Beeinträchtigung der EtherNet/IP-Performance zu erwarten. o Der Punkt-zu-Punkt-Verkehr über UDP/IP ist genauso zu sehen wie bei TCP/IP. Multicast-Verkehr kann über Switches mit IGMP-Snooping auf die direkt betroffenen Knoten beschränkt werden und ist dann genauso wie der Punkt-zu-Punkt-Verkehr zu betrachten.
