Gelingt durch TSN im zweiten Versuch die Etablierung einer einheitlichen Lösung für die industrielle Kommunikation? Vor einigen Jahren war der Hype um Echtzeit-Ethernet für die industrielle Kommunikation groß. Damals befand sich die Branche gerade in der heterogenen Feldbus-Welt und die Fachleute glaubten, man könnte eine einheitliche Kommunikationslösung aus Hardware-Sicht erschaffen, indem man auf Ethernet als Übertragungsmedium setzt. Relativ schnell stellte sich heraus, dass die Ethernet-Spezifikation der IEEE nicht den Anforderungen der Industrie gerecht wird. Deshalb etablierten sich – wie in der Feldbus-Welt auch schon – mehrere proprietäre Echtzeit-Ethernet-Varianten. Folge ist: 

Das heutige ‚Industrial Ethernet‘ ist nicht gleich ‚Industrial Ethernet‘. Zusätzlich gab es wie bei den Feldbussen auch verschiedene Kommunikationsprotokolle, die inkompatibel zueinander sind. Fazit: Letztlich erfuhren lediglich die Kabel und Stecker eine Vereinheitlichung! 

Dabei ist TSN an sich als Baukasten aus insgesamt mehreren Sub-Standards zu sehen. Einige sind final verabschiedet, andere befinden sich aktuell noch im Draft-Status.

Die wichtigsten Sub-Standards kurz vorgestellt:

1. IEEE 802.1Qbv (Time Aware Shaper) behandelt das Scheduling von Traffic Classes. Damit werden höherprioren Frames Bandbreiten auf dem Kabel reserviert, die von niederprioren Frames nicht belegt werden können.
2. IEEE 802.1AS-rev (Synchronisation) ist ähnlich dem IEEE-1588-Mechanismus, um Uhren in Geräten zu synchronisieren.
3. IEEE 802.1Qbu (Frame Preemption) ist das Aufteilen von niederprioren Ethernet Frames in Fragmente, um höherpriore Frames zwischen diese Fragmente ‚hinein‘schieben zu können.
4. IEEE 802.1Qca ist die Möglichkeit, einzelnen Frames Pfade durch das Netzwerk zu reservieren.
5. IEEE 802.1Qcc beschreibt die Konfiguration eines jeden Teilnehmer des Netzwerks.
6. IEEE 802.1Qch ist ein weiterer Mechanismus neben dem Qbv, um eine deterministische Datenübertragung zu ­etablieren.
7. IEEE 802.1Qci beschreibt, wie Frames im Netzwerk zeitbasiert erkannt und in Traffic Classes eingeteilt werden.
8. IEEE 802.1QCB ermöglicht das Duplizieren und Versenden eines Frames über weitere Pfade, um eine höhere Verfügbarkeit durch Kabelredundanz bereitzustellen.

Oder bekommen wir tatsächlich ein konvergentes Netzwerk auf Basis eines durchgängigen einheitlichen Kommunikations-Standards?

© Hilscher

Die spannende Frage ist, ob die einzelnen Nutzerorganisationen, die zukünftig TSN verwenden möchten, sich auf ein einheitliches TSN-Profil einigen können. Denn die einzelnen Sub-Standards müssen nicht zwangsweise alle verwendet werden. Außerdem könnten die Implementierungen im Detail unter-einander abweichen, was im Feld zu Inkompatibilitäten führen würde. Dieser Umstand lässt sich nur durch ein einheitliches ‚gemeinsames‘ TSN-Profil umgehen.

Während Profinet International und die CLPA klare Vorstellungen von Profinet@TSN und CC-Link@TSN haben, hat vor allem das Thema OPC-UA@TSN am Anfang die Lager gespalten. Während die Fraktion der ‚Shaper‘ davon überzeugt ist, dass TSN in Verbindung mit OPC UA vom Sensor bis in die Cloud der richtige Ansatz ist, wollen andere Größen der Automatisierungswelt OPC UA mit TSN nur ab Zellenebene, das heißt für Controller-zu-Controller-Kommunikation und darüber, verwenden. Im Fall von Controller zu Controller bis in die Cloud verschmelzen vor allem die ERP- und MES-Ebene der klassischen Automatisierung-Pyramide miteinander.

Der Fokus der Firma Hilscher als Technologie-Lieferant liegt weder nur auf Controller-zu-Controller-Kommunikation noch auf OPC-UA@TSN. Das bedeutet: Hilscher wird sowohl CC-Link@TSN, OPC-UA@TSN als auch Profinet@TSN unterstützen.

Hoffnungsträger: Die IEC/IEEE-Arbeitsgruppe

Ein Lichtblick in Richtung einheitliches TSN-Profil geht von der IEC/IEEE 60802-Arbeitsgruppe aus, denn diese versucht ein einheitliches TSN-Profil für die Industrie zu definieren. Gelingt dies und ziehen alle großen Player der Automati­sierungstechnik hier mit, dann könnte die Vision vom sogenannten ‚Converged‘ (gemischten) Netzwerk wahr werden. Wir sehen drei mögliche Szenarien, die in den nächsten Jahren eintreten können:

1.    Jede Nutzerorganisation braut ihr eigenes TSN-Süppchen und ersetzt damit ihre heutige Echtzeit-Ethernet-Lösung. Dann sind wie heute weder Hardware noch Kommunikations-Protokoll zueinander kompatibel.
2.    Alle Nutzerorganisationen halten sich an die Ergebnisse der IEC/IEEE 60802-Arbeitsgruppe, das heißt, alle Lösungen lassen sich mit derselben Hardware umsetzen, bei den Kommunikationsprotokollen (Software Stacks und Profilen) ist die Welt aber weiterhin heterogen. Damit bleiben die Lösungen kommunikativ inkompatibel zueinander.
3.    Man einigt sich auf eine einheitliche Kommunikationslösung, bestehend aus TSN-Profil und Kommunikationsprotokoll. Dann können alle Geräte im selben Netzwerk miteinander betrieben werden und kommunizieren im sogenannten ‚Converged‘-Network.

Einigen sich die Nutzerorganisationen auf ein einheitliches TSN-Profil, könnte es möglich sein, dass sich die klassische Automatisierungs-Pyramide komplett auflöst und alles miteinander verbunden wäre. Über das passende Scheduling ließen sich dann Frames – über Pfade im Netzwerk – von einem Sensor zur Cloud in der anderen Ecke des Netzwerkes schicken, ohne dabei anderen Verkehr zu beeinflussen.                                                         

Während heute mit Profinet IRT 4-Port-Switches – bei Ethercat sogar nur 2-Port-Geräte – etabliert sind, wäre der Vorteil von TSN, dass sich mehrportfähige Switches anwenden lassen.  Aus diesem Grund haben auch etablierte Switch-Hersteller wie Belden/Hirschmann oder Cisco großes Interesse an TSN. Bezüglich Topologie und Verdrahtung würde sich eine höhere Flexibilität ergeben; mittels 2-Port-basierter Endgeräte ließe sich diese Flexibilität um die kostengünstige Linienstruktur erweitern. Das heißt, topologisch wäre alles möglich: Sterne, Bäume, Ringe, Kammstrukturen und auch Linien wären realisierbar. Die Firma Hilscher wird weiterhin mittels der netX-SoC-Familie 2-Port-fähige TSN-Switche anbieten.
 

Wird Gigabit zur Pflicht?

Neben der Topologie ist im Zusammenhang mit TSN eine andere Frage immer wieder in der Diskussion: Wird TSN bis in den letzten Sensor auf Gigabit Ethernet laufen, wird Gigabit sogar gänzlich zur Pflicht werden?

Im Hause Hilscher gibt es hierzu folgende Erfahrung: Mittels kleiner, stromsparender Multiprotokoll-SoCs sind Hilscher-Produkte heute in sehr vielen kompakten und temperaturkritischen Geräten verbaut. Dabei drücken die Kunden schon heute die Verlustleistung ihrer Devices auf unter 1 Watt. Dies ist nötig, um Applikationsprozesse im Device nicht zu beein­flussen. Auch wenn sich durch den Fortschritt die technologischen Möglichkeiten weiterentwickeln, wird die Gigabit-Ethernet-Technologie in ein paar Jahren weiterhin in der Verlustleistung um den Faktor 2 bis 3 höher liegen als bei den heutigen Fast-Ethernet-basierten Geräten. Das würde für einige Kundengeräte ein K.O.-Kriterium bedeuten. Da der Markt auf diese Geräte nicht verzichten kann, ist anzu­nehmen, dass sich neben der Gigabit-Ethernet-Variante immer eine Fast-Ethernet-Variante (100 Mbit) etablieren wird, um genau solche Geräte weiterhin nutzen zu können. – Nicht zu vergessen ist zudem die Söranfälligkeit: Auch hier gilt es mit Bedacht das Pro und das Kontra von Fast- und Gigabit-Ethernet abzu­wägen.

Fast-Ethernet-basiertes TSN kann Hilscher heute schon mit seiner verfügbaren multiprotokollfähigen netX-Familie abdecken. Kunden, die heute netX im Einsatz haben, können also per Software-Update auf TSN wechseln. Nichtsdestotrotz sehen wir in Zeiten von Vision-Systemen – die eine hohe Anforderung an Bandbreite haben – sehr wohl den Trend in Richtung Gigabit Ethernet. Sprich: Viele zukünftige Feldgeräte werden mit Gigabit Ethernet ausgestattet sein. Aus diesem Grund arbeitet die Firma Hilscher heute bereits an der Erweiterung ihrer netX-Familie um eine Gigabit-Ethernet-Variante – wie bisher wird vom Chip, über Software bis zur fertigen Einsteckkarte letztlich alles zur Verfügung stehen.

Die letztendlich spannende Frage bleibt derzeit allerdings noch unbeantwortet: Können sich die Nutzerorganisationen auf einen gemeinsamen Nenner einigen? Falls nicht, erleben wir einen dritten Feldbuskrieg! Jede Nutzerorganisation wird ihr eigenes ‚Geschmäckle‘ – wie proprietäre Synchronisationsmechanismen, eigenes Scheduling, inkompatible Frame-Formate oder Summenrahmenverfahren – in ‚ihr eigenes‘ TSN mit einbauen und zusätzlich noch darüber ihre eigene Sprache – sprich ihr eigenes Kommunikationsprotokoll – setzen.

Autor: Sebastian Hilscher ist Division Manager Development bei Hilscher.