Profinet goes Motion Control

Echtzeit-Ethernet ist die Voraussetzung für durchgängige Ethernet-Konzepte in der Automatisierungstechnik. Mit dem hardwarebasierten Ansatz Profinet V3 soll zukünftig auch für die anspruchsvollen Motion-Control-Anwendungen der "Insel-Status" passé sein.

Echtzeit-Ethernet ist die Voraussetzung für durchgängige Ethernet-Konzepte in der Automatisierungstechnik. Mit dem hardwarebasierten Ansatz Profinet V3 soll zukünftig auch für die anspruchsvollen Motion-Control-Anwendungen der "Insel-Status" passé sein.

Taktsynchrone Anwendungen im Maschinenbau, die höhere Anforderungen an das Zeitverhalten stellen, lassen sich mit solchen reinen Softwarelösungen allerdings nicht realisieren. Denn Ethernet garantiert in seiner klassischen Ausprägung kein deterministisches Verhalten für die Datenübertragung.

Ein Workshop des VDMA im Oktober 2001 zum Thema "Ethernet in der Automatisierung" brachte die Anforderungen im Maschinenbau auf den Punkt: Die Benchmark für Antriebsregelungen im Maschinenbau sind: 1 µs Jittergenauigkeit, 1 ms Zykluszeit und garantierter Determinismus, verbunden mit uneingeschränkter IT-Offenheit – eine Ethernet-Herausforderung, die ohne Hardware-Unterstützung nicht zu lösen ist.

Switching-Technologie – die Zukunft

Im Büro- und Consumerbereich ist das ursprünglich als Bussystem ausgelegte Ethernet schon lange an seine Grenzen gestoßen, da die Bandbreite für den Anschluss vieler Teilnehmer und die Übertragung großer Datenmengen oft nicht mehr ausreicht. Dies führte schließlich zur Entwicklung von Switched Ethernet. Das als Punkt-zu-Punkt-Verbindungen aufgebaute Switched Ethernet ist eine Entwicklung, die auch für die Zukunft Perspektiven bietet, während die busbasierende Hubtechnologie nicht mehr für höhere Übertragungsraten weiterentwickelt wird. Somit liegt es auf der Hand, dass ein zukunftweisendes Ethernet-Konzept für die Automation auf dieser breiten, allgemein akzeptierten Basis der Switching-Technologie aufsetzen muss.

Die Vorteile höherer Datenraten, der Vollduplex-Kommunikation und des kollisionsfreien Zugriffes werden allerdings bei dieser Methodik durch eine unsymmetrische Kommunikation erkauft, da die Telegramme im Switch zwischengespeichert werden, was je nach Netzauslastung unterschiedlich lange dauert und im Überlastfall sogar zu Telegrammverlust führen kann. – Für anspruchsvolle Echtzeit-Anwendungen eine sehr unerwünschte Eigenheit.

Synchronisation ohne Kompromisse

Soll Ethernet also auch in anspruchsvolle Motion-Applikationen einziehen, muss es um einen deterministischen Kanal erweitert werden, der koexistent mit TCP/IP auf der Leitung und im Gerät ist. Eine Software-basierte Lösung wie Profinet V2 genügt diesen Ansprüchen nicht.

Denn: Für die geforderte isochrone Kommunikation mit hoher Qualität müssen alle Teilnehmer eines Netzes inklusive der Netzwerk-Knoten exakt synchronisiert sein. Nur so lassen sich unerwünschte Effekte verhindern und die gesamte Bandbreite definiert auf einen isochronen und einen asynchronen Teil verteilen. Die exakte Synchronisation wird umso wichtiger, je mehr Switches hintereinander geschaltet sind.

Für isochrones Realtime-Ethernet (IRT) werden daher die Switches mit ei-ner Genauigkeit im Submikrosekundenbereich auf den Kommunikationszyklus synchronisiert. Dies geschieht durch einen Automatismus, der alle Zeitparameter der Strecke exakt erfasst und somit eine hochgenaue Synchronisation aller Switches auf den Zyklusstart ermöglicht. Das Prinzip der Zyklussynchronisation basiert auf der hardwareseitigen Unterstützung spezieller Synchronisationstelegramme und gewährleistet eine bis dato nicht gekannte Genauigkeit in der Kommunikationstechnik.

Eine solche Qualität ist allerdings nur durch eine Hardware-Unterstützung direkt auf Layer 2 erreichbar. Softwarebasierte Lösungen auf den höheren Layern würden sofort zu Lasten der Genauigkeit und somit zu Abstrichen beim Jitter führen.

Es liegt nahe, dass ein Netz mit dieser hochgenauen Zyklussynchronisation auch besonders gut Uhrzeit-Synchronisations-Mechanismen unterstützen kann, wie etwa die IEEE 1588.

Der deterministische Kanal

Durch die Synchronisation der Switches lässt sich der Kommunikationszyklus in einen deterministischen Teil und einen offenen Teil aufspalten. Im deterministischen Kanal werden nur die zyklischen Realtime-Telegramme befördert, während die TCP/IP-Telegramme im offenen Kanal transportiert werden. Das Verfahren ist vergleichbar dem Verkehr auf einer Autobahn, welche die linke Fahrspur für PKW-Verkehr (Realtime-Verkehr) reserviert und verhindert, dass LKWs (TCP/IP-Verkehr) auf diese Fahrspur wechseln können.

Die für den Realtime-Verkehr reservierte Zeit ergibt sich aus der Anzahl der Teilnehmer und deren zyklischen Datenaufkommen.

Wer uneingeschränkte Offenheit zusichert, darf TCP/IP-Telegramme mit maximaler Länge nicht behindern. Daraus resultiert, dass für den TCP/IP-Verkehr bei 100 Mbit/s eine Zeit von mindestens 124 µs verbleiben muss. Für IRT wird daher empfohlen, eine Gesamtzykluszeit von 250 µs nicht zu unterschreiten.

Performance-Steigerung für Echtzeit-Anwendungen

Switching-Technologie bietet eine hohe Übertragungsrate, hat aber den Nachteil, dass die Telegramme in den Switches vor der Weiterleitung einige Zeit verweilen müssen. Dies wirkt sich negativ auf die Laufzeit der Daten aus. Spezielle Weiterleitungsmechanismen wie "Cut Through" bringen hier zwar eine Verbesserung, die aber erst bei längeren Telegrammen wirksam wird und voraussetzt, dass die Übertragungsstrecke frei ist.

Für isochrones Realtime-Ethernet wurde deshalb ein optimierter Weiterleitungsmechanismus entwickelt, mit dem quasi vorausschauend die Wege für die Telegramme freigeschaltet werden und so ein fast verzögerungsfreier Transport realisierbar ist.

Durch dieses "Switch-Tuning" werden bei 100 Mbit/s und Vollduplex-Betrieb Performance-Werte erreicht, die mit bisheriger Technik nicht zu realisieren waren. So werden sich mehr als 100 Antriebsachsen auf Gleichlauf regeln lassen bei Zykluszeiten von maximal 1 ms und einem Jitter von kleiner 1 µs – und dies bei parallelem uneingeschränktem TCP/ IP-Verkehr.