Ein Zwischenruf von Martin Rostan, Executive Director, Ethercat Technology Group

Das Ende der Feldbuskriege?

"Die Zeit der Feldbuskriege ist vorbei, endlich kommt der einheitliche Kommunikationsstandard, den alle unterstützen. Alle Geräte werden interoperabel sein und sich problemlos mit den Tools dritter Hersteller konfigurieren lassen: konformitätsgetestet und zertifiziert. Der neue Standard wird gleich stabil sein und es wird daher keine Versionierungsprobleme geben - zumindest werden alle Versionen vollständig abwärtskompatibel sein. Performance wird auch kein Thema mehr sein, weil die neue Technologie ja viel schneller sein wird als alle bestehenden. Die Implementierung der Geräte wird ganz einfach und mit Standard-Chips zu realisieren sein - schließlich setzt man ja durchgängig auf IT-Standards. Deshalb werden auch die Kosten sinken. IT-Know-How wird der Inbetriebnehmer aber keines brauchen, und Cyber-Security wird auch keine Herausforderung mehr sein, weil die Prozessdaten ja verschlüsselt werden und jeder Sensor ein Zertifikat bekommt, das sich selbst regelmäßig aktualisiert. Und die Feldbusorganisationen werden überflüssig sein, weil es ja nur noch einen Standard gibt. Ach ja, und ab Ende 2019 werden die erforderlichen Produkte verfügbar und Anlagen mit dem neuen Standard realisierbar sein. Möglich macht dies die OPC Foundation (die selbsternannte 'United Nations der Automatisierungstechnik') mit der neuen Field Level Communications (FLC) Initiative."


So ungefähr sehen die Träume aus, die zurzeit von den Marketing-Abteilungen einiger Protagonisten als Realität dargestellt werden. Schließlich machen ja fast alle großen Automatisierungsanbieter weltweit bei der Initiative mit - was soll da noch schief gehen?

Ich denke, es wird Zeit, ein wenig Wasser in den Wein zu gießen!

Fangen wir mit den aktuellen Mitgliedern des FLC-Steering Committees an: Die 23 Firmen haben zusammen zwar einen großen Marktanteil in der Automatisierungsbranche, sie haben aber durchaus unterschiedliche Interessen. Nach meiner Einschätzung bilden sie vier Gruppen: Die erste Gruppe sind die Verlierer des letzten Feldbuskrieges. Sie konnten sich mit ihrer eigenen Industrial-Ethernet-Lösung nicht durchsetzen und suchen nun nach einem Nachfolger. Die zweite Gruppe sieht OPC UA zwar als geeignete Technologie für die Kommunikation zwischen Steuerungen, favorisiert unterhalb der Steuerung aber ein anderes Bussystem - und wird dieses sicherlich nicht zugunsten von OPC FLC aufgeben. Die dritte Gruppe möchte den anderen Komponenten und Chips verkaufen. Deren Mitglieder haben übrigens naturgemäß wenig Interesse daran, dass das entstehende System auf Standard-IT Komponenten basiert. Und die vierte Gruppe ist vermutlich die größte: Ich nenne sie die FOMO-Gruppe ('Fear Of Missing Out'). Da könnte ja was von Bedeutung entstehen, da bin ich dann doch lieber dabei.

Wer gehört zu welcher Gruppe? Nun, die Mitglieder der ersten Gruppe trommeln naturgemäß am lautesten für die Initiative. Hier zeigt die Erfahrung, dass nicht jede Trommelei zur Realisierung oder gar zur Marktdurchdringung führt. So kündigte die EPSG im Jahre 2006 Gigabit Powerlink an, und 2010 wurde Opensafety als das einheitliche, busunabhängige Protokoll für funktionale Sicherheit propagiert (Spoiler: bis heute gibt es meines Wissens nach weder Gigabit Powerlink noch ein einziges zertifiziertes Opensafety-Gerät, das nicht auf Powerlink basiert). Aber Papier ist ja bekanntlich geduldig. Und Powerlink ist nun ohnehin Geschichte.

Beckhoff und Kuka haben bisher am deutlichsten gesagt, dass man OPC als relevanten offenen Kommunikationsstandard nachhaltig unterstützt, aber unterhalb der Steuerung natürlich weiterhin auf Ethercat setzt. Siemens, Rockwell und Mitsubishi sehen das wohl entsprechend ähnlich.

Anzeige

Ich kann mir beim besten Willen nicht vorstellen, dass diese Konzerne ihre Systemarchitektur umkrempeln und ihre Industrial-Ethernet-Technologien Profinet, Ethernet/IP und CC-Link IE auf dem OPC FLC-Altar darbringen.

Und das ist auch aus Anwendersicht gut so: Der technische Wettbewerb zwischen den Systemen ist unbedingt erforderlich, um Technologien voranzubringen. Im ersten 'Feldbuskrieg' wäre es ohne Wettbewerb wohl bei Pro fibus-FMS geblieben und Siemens hätte kein Profibus-DP entwickelt, und im zweiten hat sich der Wettbewerb in unzähligen Versionen an der Ethercat-Performance abgearbeitet - wenngleich hier auch mit mäßigem Erfolg.

Apropos Performance: Die Mär, dass OPC UA mit TSN 18x schneller sei als alle bestehenden Systeme, wird auch durch ständige Wiederholung nicht wahrer. Wir haben einen der wenigen Automatisierungsexperten aus der IEEE 802.1 TSN Taskgruppe mal nachrechnen lassen: In allen Maschinensteuerungs-Szenarien werden sogar mit einem einzigen 100Mbit/s Ethercat-Segment kürzere Kommunikationszeiten erreicht als mit TSN-Elementen hochgerüsteter Switching-Technik auf Gbit/s-Ethernet. Und zwar unabhängig vom verwendeten Protokoll und unter der optimistischen (und nicht normgerechten) Annahme, dass bei TSN Cut-Through Switching zur Verfügung steht. Teilt man das Ethercat-Segment auf, schlägt 100Mbit/s Ethercat jedes Gbit/s-TSN System um Längen. Und welcher Anwender würde einen Gigabit Physical Layer für seine Antriebe, E/A-Baugruppen und Sensoren bevorzugen, wenn er bessere (oder auch nur ausreichende) Performance auf 100Mbit/s-Basis haben kann? Deshalb kombinieren sowohl der TSN-Ansatz der Ethercat Technology Group (ETG) als auch die Ethercat G Technologie, die Beckhoff im September in die ETG einbringen wird, einen Gbit/s-Backbone mit 100 Mbit/s Ethercat-Feldgeräten, die übrigens unverändert bleiben.

Dagegen sind die aktuellen Feldbusstandards geradezu schlank. Kein Wunder, dass man anders als bei den Feldbussen keinen Experten findet, der sich mit dem gesamten Konstrukt auskennt.

Mit FLC ist zudem ein neues Level an Komplexität zu erwarten: Der OPC-TSN-Ansatz setzt aktuell auf sieben IEEE 802.1-Standards auf und hat bereits sieben zusätzliche relevante Standards produziert - weitere werden folgen. Dabei liegt der Umfang alleine des IEEE 802.1 Q-Standards bei fast 2.000 Seiten. OPC UA selbst umfasst 14 Standards zu denen gerade nochmal drei Erweiterungen hinzukamen. Und Geräte müssen ja dann auf eine vernünftige Weise auf Konformität zu dieser Vielfalt an Standards geprüft werden.

Damit kommen wir zu Stabilität und Versionierung. Originell finde ich den Vorschlag, OPC FLC 'auf Raten' einzuführen: Man könne ja fehlende Technologiemodule im Feld 'nachladen'. Bei einem Tesla mag es cool sein, morgens ein neues Feature im Fahrerassistenzsystem vorzufinden, aber Bremsen, Lichter und Lenkrad sollten bereits bei der Auslieferung vorhanden sein: Hardware lässt sich nicht nachladen und auch Systemfeatures per Firmwareupdate im Feld nachzurüsten kann nur dann halbwegs zuverlässig funktionieren, wenn alle Geräte aus einem Hause stammen. Aber vielleicht ist ja genau das gewünscht?

Ganz nebenbei: Bei Ethercat ist weder das eine noch das andere erforderlich. Auch wenn im Laufe der Zeit viele neue Features hinzugekommen sind: Es gibt nur eine Version. Aktuelle Geräte laufen problemlos auch in Anlagen von 2004. Und Interoperabilität ist bei Ethercat keine Zukunftsmusik, sondern tausendfach bewiesen. Wie ja auch die verfügbare Gerätevielfalt: Über 2.000 registrierte Hersteller von Ethercat-Geräten sprechen eine deutliche Sprache. Übrigens haben auch 94 Prozent der Automatisierungsanbieter im OPC FLC Steering Committee Ethercat-Produkte bereits im Programm. Heute. Verfügbar. Erprobt.

Empfehlungen der Redaktion

Und die Erfahrung lehrt: Es dauert alles länger als ursprünglich erwartet. Viel länger.

Das kann man von TSN auch in absehbarer Zeit noch nicht seriös behaupten: Der für die Zeitsynchronisierung und damit für alle anderen Echtzeitfeatures relevante IEEE-Standard befindet sich zurzeit wieder in der Abstimmung und hat dabei bereits so viele negative Kommentare eingesammelt, dass er voraussichtlich wieder in eine neue Runde gehen muss. Ansätze zur herstellerübergreifenden Konfiguration sind erst in einem ganz frühen Stadium. Ende Februar auf der Embedded World waren zwar erste TSN-Chips für Endgeräte und einige 3-Porter mit vorläufigen Features zu sehen. Manche Multiport-Chips wurden zwar als verfügbar gepriesen, aber nach einem freigegebenen TSN-Switch mit diesen Komponenten suchte man auf der Messe oder im Internet vergebens. Aber das spielt aktuell noch keine Rolle, weil ja auch auf der Softwareebene noch das meiste komplett fehlt. OPC UA PubSub wurde zwar 2018 veröffentlicht und in einem Amendment in diesem Jahr noch weiter ausgeprägt, hat aber bisher weder Netzwerkmanagement noch Geräteprofile: Es war ja auch nicht als Feldbussystem gedacht. So ist die Spezifikation OPC UA for Devices (DI) kein Geräteprofil, sondern beschreibt, wie man ein Profil schreiben kann. Es gibt also bisher nicht einmal ein E/A-Profil und schon gar keines für modulare E/A-Baugruppen oder gar Antriebe. Das gesamte Ökosystem muss erst noch aufgebaut werden: Support und Schulung, Conformance-Testing und Zertifizierung, usw.

Seit 27 Jahren beschäftige ich mich beruflich hauptsächlich mit der Entwicklung und Verbreitung von Feldbussystemen. Damit darf ich mich wohl zu den Veteranen der Feldbuskriege zählen. Aber auch OPC Field Level Communications wird samt Ökosystem irgendwann fertig und vielleicht sogar halbwegs stabil sein. Das wird aber noch einige Jahre dauern - nicht Monate. Es wird dann im Zusammenspiel mit TSN eine Performance aufweisen, die für einige Anlagen heutiger Ausprägung ausreichen wird. Und es wird wohl auch einige der Verlierer der Feldbuskriege verdrängen - aber nicht diejenigen Gewinner, die es aus guten technischen Gründen geschafft haben, weltweite Verbreitung zu finden. Und das ist im besten Interesse der Anwender.

Ethercat ist ja nicht deswegen so erfolgreich, weil es von so vielen Firmen unterstützt wird, sondern es wird von vielen Firmen unterstützt, weil es technisch so überzeugend ist. Es ist auch nicht klar, was der Vorteil einer OPC FLC TSN IP65 Box mit acht Digitaleingängen und noch nicht standardisierten 8-poligen M8-Steckern und der ungünstigeren Energiebilanz von Gbit/s-Ethernet gegenüber einem heute schon schnelleren Ethercat-Gerät sein soll. Das Potential von TSN ist bei der Vernetzung von Produktionslinien doch deutlich größer, wo man mit synchronisierten Steuerungen und niedrigen Latenzzeiten die Interaktionen von Maschinen deutlich besser koordinieren könnte. Da gehören die TSN-Technologien hin und da werden sie von Ethercat auch genutzt werden.

Anzeige