Herr Rostan, warum braucht Ethercat überhaupt eine Erweiterung wie Ethercat G?

Martin Rostan: Durch die höhere Bandbreite erweitert Ethercat G den sinnvollen Einsatzbereich unserer Technologie auf besonders ‚datenhungrige‘ Geräte. Entscheidend dabei ist: Das Protokoll an sich bleibt bei Ethercat G dasselbe. Für Ethercat-Steuerungen ändert sich deshalb zunächst einmal nichts: Wenn sie über eine Gbit/s-Ethernet-Schnittstelle verfügen, können sie Ethercat G sofort und ohne Software-Änderung nutzen. Die zusätzliche Erweiterung um sogenannte Branch-Controller führt zu zwei wichtigen zusätzlichen Eigenschaften: Zum einen können Bitraten gemischt werden, also 100-Mbit/s-Segmente unterhalb eines Gbit/s-‚Backbone‘ betrieben werden – und das in Zukunft mit Ethercat G10 auch auf 10 Gbit/s entsprechend hochskaliert.

Zum zweiten erlauben die Branch-Controller auch die Parallelisierung der Telegramm-Verarbeitung: Da dann nicht mehr jedes Frame durch alle Netzwerk-Teilnehmer durchgeleitet werden muss, ergibt das einen erheblichen Performance-Gewinn. Mit Gbit/s-Backbone und durchgängig 100-Mbit/s-Feldgeräten werden wir etwa fünfmal schneller, mit Gbit/s-Feldgeräten sogar rund siebenmal. Mit anderen Worten: Auch mit den bewährten Ethercat-Feldgeräten auf Basis der robusten 100-Mbit/s-Technologie wird durch die Ethercat-G Erweiterung ein neues Performance-Level erreicht.

Wer genau profitiert von Ethercat G?

Martin Rostan: Grundsätzlich alle Hersteller und Anwender heutiger Ethercat-Geräte, weil sie ganz ohne Änderung an ihren bestehenden Geräten einen weiteren, erheblichen Performance-Zuwachs bekommen. Im Besonderen zum Beispiel die Hersteller von Kameras oder High-End-Messtechnik-Komponenten, für die sich Ethercat jetzt noch besser eignet. Oder auch Anbieter besonders anspruchsvoller Motion- Control-Geräte, die von den kürzeren Zykluszeiten und den damit verbundenen noch kürzeren Regelungs-Totzeiten profitieren.

Nachdem unlängst der Startschuss für Ethercat G in der ETG gefallen ist: Wie geht es jetzt weiter?

Martin Rostan: Ethercat G und G10 sind zwar schon weit entwickelt, aber noch nicht in allen Details festgeschrieben. Der Schwerpunkt in der ETG liegt nun also in der Spezifikationsarbeit der Branch-Controller-Erweiterung. Vieles ist schon fertig, aber ein paar Monate brauchen wir dafür noch. Natürlich gehören dann die entsprechenden Erweiterungen der Test-Spezifikationen und der Test-Tools, das Einbringen in die internationale Normung und so weiter dazu – eben alles, was zu einem ordentlichen Feldbus-Ökosystem dazugehört.

Nun gibt es ja auch TSN und die ETG hat dazu bereits eine entsprechende Spezifikation veröffentlicht. Wie passt dies mit Ethercat G zusammen?

Martin Rostan: Unsere TSN-Aktivitäten verlieren durch Ethercat G nicht an Bedeutung: Wir sehen die TSN-Technologien weiterhin als wichtige Ergänzung von Ethernet, sind entsprechend offizieller Liaison-Partner der IEEE und waren nicht umsonst die erste größere Feldbus-Organisation mit einer TSN-Spezifikation. Mit der darin spezifizierten Schnittstelle werden wir Ethercat-Netzwerke – auch mit Ethercat G – an heterogene TSN-fähige Ethernet-Netze anbinden und damit den Einsatzbereich unserer Technologie erweitern, ohne Ethercat-Feldgeräte ändern zu müssen. Auch wird dank der TSN-Technologien unser Ethercat-Automation-Protokoll zur Vernetzung von Ethercat-Steuerungen über ein bestehendes Ethernet-Netz hart echtzeitfähig werden. Wir koppeln uns also an TSN an, während Ethercat G und G10 integrale Bestandteile unserer Technologiefamilie werden – und zwar mit der gewohnten Einfachheit, für die man kein IT-Know-how benötigt. In aller Kürze lautet die Strategie damit: Ethercat an TSN-Netze immer da, wo diese bereits vorhanden sind, und Ethercat G und G10 immer da, wo mit der Anwendung das Steuerungsnetzwerk neu entsteht.

Wie schätzen Sie persönlich die aktuellen Entwicklungen zu TSN und Industrial Ethernet ein?

Martin Rostan: Ethercat profitiert sicherlich von der Unruhe, die durch TSN in den Markt gekommen ist. PNO und CLPA arbeiten an der Integration von TSN in Profinet und CC-Link IE und werden noch Jahre brauchen, bis ihre auf TSN basierenden Systeme stabil sind – und Profinet IRT implementiert keiner mehr. Die ODVA scheint noch keine klare TSN-Strategie zu haben. Bosch Rexroth beispielsweise hat erkannt, dass TSN noch lange auf sich warten lässt und basiert seine neue Steuerungsgeneration folgerichtig auf Ethercat – damit ist Sercos III faktisch abgemeldet.

Ich persönlich erwarte, dass die ‚IEEE TSN Task Group‘ Ende dieses Jahres oder Anfang nächsten Jahres die Spezifikation für die TSN-Zeitsynchronisierung verabschieden wird – und damit der Startschuss für die Entwicklung von normgerechten TSN-Chips fällt. Schon bevor diese verfügbar sind, werden einzelne Hersteller TSN-Insellösungen vorstellen. Und auch auf der Konfigurationsseite ist nach wie vor viel in Bewegung; unter anderem ist noch nicht klar, ob es die eine herstellerübergreifende Lösung geben wird.