Sie sind hier: HomeFeldebeneVernetzung

Technologie-Evaluierung / Vernetzung: Beckhoff Automation kooperiert mit Huawei

Was steckt dahinter, wenn ein großer chinesischer IKT-Anbieter mit einem deutschen Automatisierer zusammenarbeitet? Guido Beckmann und Thomas Rettig von Beckhoff Automation klären auf.

Herr Beckmann, Herr Rettig, seit Ende 2017 kooperiert Beckhoff mit Huawei – auf welchem Gebiet und warum?
Guido Beckmann:
Bei der Kooperation geht es konkret um zwei Projekte, in deren Rahmen wir zusammen mit Huawei neue Kommunikationstechnologien evaluieren. Das eine dreht sich um das Thema 5G. Hier arbeiten wir mit dem sogenannten X-Lab von Huawei zusammen. Bei dem zweiten Projekt, das wir mit dem Network-Technology-Lab von Huawei gestartet haben, beschäftigen wir uns mit geswitchten und gerouteten Netzwerken. Mit ‚X-Ethernet‘ und ‚Deterministic IP‘ hat Huawei diesbezüglich eigene Technologien entwickelt.

Thomas Rettig: Für uns ist es einfach interessant zu untersuchen, ob beziehungsweise wie sich Technologien aus anderen Industrien wie etwa der Informations- und Kommunikationstechnik-Branche für die industrielle Kommunikation nutzen lassen. Im Übrigen war es so, dass in beiden Fällen Huawei auf uns zugekommen ist mit der Frage, ob wir nicht an einer entsprechenden Kooperation Interesse hätten.

Guido Beckmann, Beckhoff Bildquelle: © Beckhoff

Dr. Guido Beckmann, Senior Management Control System Architecture & ­International Key Account bei Beckhoff ­Automation.

Was verbirgt sich im Detail hinter dem an-gesprochenen X-Ethernet?
Beckmann:
X-Ethernet ist eine Technologie, die ursprünglich als Backbone für 4G/5G – sprich primär für den 100-GBit-Bereich – entwickelt wurde, um hier Daten in verschiedenen Pipes zu übertragen beziehungsweise diese Daten möglichst feingranular und deterministisch routen zu können. Das erwähnte Network-Lab von Huawei hat sich nun zur Aufgabe gemacht, dieses Thema auch auf die industrielle Kommunikation herunterzubrechen, sprich Echtzeit-Kommunikation im Bereich von 100 Mbit bis 1 Gbit zu realisieren.

Technisch gesehen ist X-Ethernet unterhalb des Layers 2 im OSI-Modell angesiedelt, auf dem wir üblicherweise die Kommunikation sehen – sei es bei Ethercat oder auch bei Standard-Ethernet. Anders ausgedrückt: X-Ethernet befindet sich – wie wir es nennen – auf dem Layer 1,5 respektive auf dem Coding-Layer, der im Ethernet-PHY integriert ist. Hier wird quasi alles in einzelne Bit-Blocks zerhackt; das heißt, ich sehe auf dieser Ebene keine reinen Frames mehr.

Thomas Rettig, Beckhoff Bildquelle: © Beckhoff

Thomas Rettig, Senior Management Control System and ­Communication Architecture bei Beckhoff Automation.

Rettig: Bei einer Gigabit-Kommunikation sind zum Beispiel zehn 100-Mbit-Kanäle definierbar. Indem diese rollierend immer hintereinander weg als einzelne feste Bit-Blöcke übertragen werden, ist die Kommunikation deterministisch, Jitter-frei und einfach zu konfigurieren. Und: Ich muss auch nichts Externes tun, um X-Ethernet-Switche zu synchronisieren – die Kommunikation erfolgt immer im Flankenstart zueinander. Für uns liegt der Reiz der Technologie darin, dass wir damit Standard-Ethercat-Geräte direkt über ein heterogenes X-Ethernet-Netzwerk, in dem parallel noch andere Standard-Ethernet-Kommunikation stattfindet, integrieren können. Aus der Ethercat-Master-Sicht ergibt sich damit lediglich ein Übertragungs-Delay wie bei einem Kabel. Huawei möchte diesbezüglich herunterkommen bis auf eine Mikrosekunde pro Switchdurchlauf. Auf der zurückliegenden Hannover Messe – hier hatten wir bereits eine entsprechende Demo am Laufen – lagen wir mit den ersten Prototypen bereits bei 3,5 Mikrosekunden. So konnte ein 50-Mikrosekunden-Zyklus von einem Ethercat-Master an ein abgesetztes Ethercat-Segment ohne weitere Anpassungen über ein 2-stufiges X-Ethernet-Netzwerk gezeigt werden.

Letztlich handelt es sich bei X-Ethernet aber um eine proprietäre Technologie von Huawei, oder nicht?
Beckmann:
Korrekt. Aber die Bestrebungen von Huawei gehen auf jeden Fall dahin, die Technologie zu normieren beziehungsweise eine internationale Spezifikation zu veröffentlichen. Zudem basiert das Ganze ja auf dem IEEE-Standard 802.3, wenn auch die Switching-Eigenschaft speziell ist.

Für welche konkreten Anwendungen wäre denn eine Technologie wie X-Ethernet prädestiniert?
Beckmann:
Im Grunde sind es ähnliche Anwendungen wie bei Ethernet TSN, also wenn man beispielsweise in der Maschine parallel noch Bildverarbeitung machen möchte – und das nicht nur mit einer, sondern auch mit mehreren Kameras. Ein anderes Beispiel wäre der Einsatz bei unserem linearen Transportsystem XTS – ebenfalls eine sehr ‚datenhungrige‘ Anwendung, bei der es durchaus von Vorteil sein könnte, wenn man X-Ethernet zum Verteilen der Daten nutzt.

Welche konkreten Vorteile hätte X-Ethernet gegenüber dem derzeit vielbeschworenen Ethernet TSN?
Rettig:
Da es bei X-Ethernet – wie bereits erwähnt – um die Übertragung fester Bitblöcke anstelle von Telegrammen geht, muss man nicht mehr mit verschieden langen Verzögerungszeiten hantieren. Das vereinfacht die Konfiguration enorm. Ich brauche auch die Adaption an eine 1588-Synchronisierung, die bei Ethernet TSN unter den Switchen und den Endgeräten funktionieren muss, nicht mehr. Das gleiche gilt in puncto MAC-Adressen-Adaption, die bei TSN nötig ist, um die Streams für quasi jedes Endgerät hinter dem TSN-Netzwerk zu definieren. Bei X-Ethernet muss ich lediglich einmal den Kanal definieren und dann ist es mir egal, was für eine Ethernet-Kommunikation darüber läuft – ob das jetzt Standard-Ethernet ist, UDP/IP, Profinet oder Ethercat.

Und was sind die Nachteile von X-Ethernet?
Beckmann:
Einmal, dass man eine feste Bandbreite reserviert. Das heißt, wenn ich einen 100-Mbit-Kanal definiere, fehlt dieser definitiv beim 1-Gbit-Kontingent und lässt sich auch nicht dynamisch woanders hin aufteilen. Dafür kann ich aber meine Ethercat-Konfiguration flexibel im Master anpassen. Sprich: Wenn das Ethercat-Netzwerk unter dem X-Ethernet-Netzwerk erweitert wird, braucht man sich um die Konfiguration der X-Ethernet-Switche nicht weiter zu kümmern, weil X-Ethernet lediglich wie ein 100-Mbit-Kabel zu betrachten ist.

Alle Welt möchte endlich ‚einen‘ Ethernet-basierten Kommunikationsstandard für das Zeitalter von Industrie 4.0 – das besagte Ethernet TSN + OPC UA wird hier hoch gehandelt. Macht es da grundsätzlich noch Sinn, sich mit einer proprietären Lösung wie X-Ethernet zu beschäftigen – wenn man die angesprochenen Vorteile einmal außer Acht lässt?

Beckmann: Lassen Sie mich zunächst klarstellen: Bei unseren Aktivitäten in puncto X-Ethernet handelt es sich um Technologie-Evaluierung – mehr nicht! Hier sind noch überhaupt keine Produkte andiskutiert worden. Wenn wir und unsere Kunden allerdings feststellen, dass neue Technologien klare Vorteile gegenüber etablierten Lösungen haben, dann sind diese für uns grundsätzlich immer interessant und wir schauen uns diese dementsprechend genau an.

X-Ethernet ist zwar etwa auf der gleichen Ebene anzusiedeln wie TSN; trotzdem sehen wir es zumindest aktuell nicht als direkten Wettbewerb. Auch werden wir uns deswegen nicht weniger mit TSN beschäftigen. Fakt ist aber auch, dass unser aller Bauchschmerz bei TSN ja immer noch die Frage ist, was in puncto Konfiguration passieren wird beziehungsweise wann es diesbezüglich etwas Vernünftiges gibt und wer sich letztendlich worauf einigt.

Grundsätzlich halten wir die OPC-UA-TSN-Technologie dort für sinnvoll, wofür sie ursprünglich gedacht war – sprich für die Kommunikation von Steuerung zu Steuerung beziehungsweise für die vertikale Kommunikation nach oben. Wir halten sie weniger sinnvoll für I/O-Kommunikation auf dem Buskoppler-Level – unter anderem aufgrund der komplexen Konfiguration der TSN-Netzwerke.

Insbesondere die Shaper Group proklamiert aber Ethernet TSN + OPC UA durchaus bis hinunter zur I/O-Kommunikation und ruft damit das Ende bisheriger Ethernet-basierter Feldbusse aus!

Rettig: Mag sein. Allerdings sollte man sich auch vor Augen halten, dass die Latte in puncto geringe Kosten, Diagnose oder auch Set-up der Maschine durch die etablierten Ethernet-basierten Feldbusse sehr hoch liegt. Was ist, wenn irgendwas nicht funktioniert? Dann muss ich in meiner Maschine sehr schnell den Fehler finden können. Oder was passiert, wenn ich tatsächlich mein Netzwerk erweitern muss? Wie stellt sich dann die ganze Kommunikation wieder ein? – Man will mit einer neuen Technologie ja nicht schlechter werden!

Ich glaube, dass frühestens in fünf Jahren wirklich abschätzbar ist, wie sich die Dinge diesbezüglich entwickeln – sprich ob Ethernet TSN in der Feldebene auf einen vergleichbaren Level kommen könnte wie heutige Ethernet-basierte Lösungen.

Neben X-Ethernet zeigten Sie im Rahmen der Messe-Demo in Hannover auch ‚Deterministic IP‘ – worum geht es hierbei?

Beckmann: Beim Deterministic-IP-Ansatz von Huawei geht es darum, auf einem gerouteten Netzwerk – sprich auf dem Layer 3 – Echtzeit-Eigenschaften herzustellen. Zum Verständnis: In einer Fabrik ergibt sich meist die Notwendigkeit, dass Hallen, Zellen beziehungsweise Subnetze miteinander kommunizieren müssen. Wenn dies echtzeitfähig über ein Kabel erfolgen soll, hilft eine Technologie wie TSN nicht mehr, da es sich ja hier um eine Layer-2-Switch-Technologie handelt. Vielmehr muss ich dann einen Schritt weiter – sprich auf eine geroutete Ebene – gehen.

Rettig: Vor diesem Hintergrund hat Huawei mit Deterministic IP eine ebenfalls Hardware-unterstützte Technologie entwickelt, mit der im Router zyklische Bandbreite angefordert beziehungsweise reserviert werden kann. Ein Routing von einem Port zum anderen Port dauert dabei weniger als 50 Mikrosekunden. Das heißt: Man hat ein schnelles Routing auf IP-Adress-Ebene mit deterministischen Eigenschaften. Damit lässt sich zum Beispiel ein Datenstrom durch die Fabrik definieren, um etwa in einem abgesetzten Serverraum einen Digitalen Zwilling rechnen zu lassen, der dann wiederum in Echtzeit auf den Prozess einwirkt. Ein anderes Anwendungsbeispiel wäre das Thema PLC-Cloudification – also wie man künftig aus einer lokalen Cloud heraus besser steuern könnte.

Lassen Sie uns zu Ihrem zweiten Projekt mit Huawei kommen – der Wireless-Kommunikation über 5G.
Beckmann:
Auch hier geht es zunächst um Technologie-Evaluierung und zudem da-rum, einem wichtigen Player im IKT-Markt, der sowohl Chips als auch Endgeräte herstellt, klar unsere Anforderungen an eine industrietaugliche Wireless-Kommunikation aufzuzeigen. Wir wiederum wollen verstehen, was die IKT-Branche diesbezüglich zu leisten in der Lage ist.

Warum Technologie-Evaluierung – sind die Eckpunkte bezüglich 5G nicht bereits klar definiert?
Rettig:
Was das Release 15 des Standards angeht, welches jetzt eingefroren wird und mit dem die Branche ab dem nächsten Jahr an den Start gehen wird, mag dies zutreffen. Über was wir mit Huawei reden, ist vielmehr das Release 16 des Standards, welches erst Ende 2019 definiert und anschließend umgesetzt wird!

Das Neue und für uns Spannende am Release 16 ist, dass es bei 5G zukünftig drei verschiedene Betriebsmodi geben wird, die parallel zueinander laufen können: Neben dem Modus ‚Enhanced Mobile Broadband‘ 1) – also der ‚normalen‘ Datenkommunikation mit einer erweiterten Bandbreite von 20 Gbit/s wie wir es im Release 15 jetzt schon haben – kommen neu die Modi ‚Ultra-Reliable Low-Latency Communication‘ 2) sowie die ‚massive Machine-Type Communication‘ 3) dazu. Gerade diese beiden machen 5G dann für die Industrie erst richtig interessant!

Was genau verbirgt sich hinter diesen beiden Modi? 
Rettig:
Bei uRLLC geht es um eine möglichst deterministische Übertragung. Geplant ist, eine Latenzzeit von einer Millisekunde von Hop zu Hop hinzubekommen – sprich von der Basisstation zum Endgerät – sowie eine aus funktechnischer Sicht sehr hohe Verfügbarkeit von 99,999 %. Letzteres ist zugegebenermaßen aus unserer Sicht sehr wenig, wenn man kabelgebundene Kommunikation zugrunde legt. Für die Funkkommunikation ist das aber schon ein extrem guter Wert.

Der Modus mMTC wiederum soll es ermöglichen, bis zu einer Million ‚connectet devices‘ – in unserem Fall also beispielsweise drahtlose Sensoren an einer Maschine – pro Quadratkilometer in ein 5G-Netzwerk einzubinden. 

Die Datenrate ist dann zwar reduziert, dafür ist aber der Energieverbrauch entsprechend niedrig, was wiederum enorm lange Batterielaufzeiten der Sensoren erlaubt. Bei einem einfachen Sensor etwa, der lediglich ein oder zweimal am Tag eine Temperatur übertragen soll, reicht es somit aus, ausschließlich mMTC zu unterstützen. Somit lässt sich der Sensor kleiner und damit kostengünstiger bauen. Auf den Punkt gebracht: Mit mMTC wird das ‚Industrial Internet of Things‘ in der Fläche überhaupt erst möglich.  

Beckmann: Was man in diesem Zusammenhang verstehen muss: Man bekommt bei 5G nicht alles auf einmal! Wenn ich 20 Gbit Datenrate habe, dann bekomme ich das nicht mehr mit 1 ms übertragen. Genau deshalb wurden jetzt die unterschiedlichen Modi definiert, genannt ‚Network Slicing‘. Wichtig ist dabei, dass die aufzubauende Infrastruktur – sprich meine Basisstation und mein Core-Netzwerk – all das unterstützt, was ich nutzen möchte. So soll es künftig durchaus Geräte beziehungsweise Chipsätze geben, die alle drei Modi unterstützen. Für eine SPS kann es beispielsweise sinnvoll sein, dass sie neben der kurzzyklischen Kommunikation gemäß uRLLC eine hohe Bandbreite unterstützt, wenn etwa ein Vision-Stream mit übertragen werden soll.

Für uns ist es auf jeden Fall erfreulich zu sehen, dass sich die im sogenannten 3GPP-Gremium organisierte 5G-Community genau mit diesen Themen auseinandersetzt. Mit anderen Worten: Sie hat nicht mehr nur die Smartphones im Kopf, sondern geht mittlerweile durchaus auch auf neue Industrien zu.

Welche weiteren Themen gilt es noch anzugehen, um 5G für einen Einsatz weiter zu optimieren?
Beckmann:
Zu nennen ist hier zum Beispiel das Thema ‚private Netze‘, das wir jetzt auch über den ZVEI beziehungsweise die im April ins Leben gerufene 5G-ACIA-Gruppe in Richtung Bundes-Netzagentur adressieren. Worum geht es dabei? Viele unserer Kunden wollen sich nicht auf den Antennenmast vor ihrem Haus verlassen, um ihre Maschine-zu-Maschine-Kommunikation zu realisieren. Vielmehr wollen sie ihre eigene Infrastruktur installieren können – quasi ein ‚privates‘ Netz.

In diesem Kontext stellen sich dann Fragen wie: Welche Frequenzen beziehungsweise welches Spektrum können dabei genutzt werden? Kann ich diese nicht nur in Deutschland nutzen sondern auch in ganz Europa? Und was ist, wenn ich meine Maschine in die USA verkaufe – welche Frequenzen brauche ich dann? Diese Fragen sind zwar eher politischer Natur, jedoch nicht weniger wichtig.

Rettig: Nicht zuletzt werden die Zuverlässigkeit der Verbindung sowie die Störanfälligkeit kritische Themen bleiben. Bei 5G handelt es sich nun einmal um ein Shared Medium – das heißt: Wenn es heute funktioniert, weiß ich nicht, ob es morgen auch noch funktioniert.

Was die Störanfälligkeit betrifft, so lässt sich diese reduzieren, indem man die Frequenzen erhöht. Wenn ich nicht mit 3 oder 5 GHz sende sondern mit 25 GHz oder mehr, komme ich aus meinem Gebäude nicht mehr heraus. Ergo störe ich auch ­meinen Nachbarn nicht mehr und kann zudem von außen nicht mehr gestört werden. Allerdings wird dadurch auch die Reichweite begrenzt, was wiederum die Telekom-Anbieter nicht mögen, weil sie dann ihre Masten in kürzeren Distanzen installieren müssen.

Letzteres wäre aber gerade für die In­dustrie durchaus interessant, denn: Letztendlich kann ich damit meine Fabrik auch schützen – Stichwort Security! Nachteil ist allerdings wieder: Die funktechnische Ausleuchtung meiner Anlage gestaltet sich schwieriger. Aber ich glaube, dass man auch diesbezüglich einiges hinbekommen wird.

Beckmann: Das Entscheidende bei all dem, was wir bis jetzt diskutiert haben, ist: Es muss uns als Automatisierungsindustrie nun gelingen, unsere Anforderungen an die Wireless-Kommunikation gegenüber der IKT-Branche klar zu kommunizieren, damit diesen im Release 16 von 5G ­Rechnung getragen wird. Gelingt uns das nicht, können wir bei 6G wieder weiter machen!