Über die Technologie Time-Sensitive Networking (TSN) wird stark diskutiert. Entstanden sind unter diesem Begriff die subsumierten Standards aus dem Standardisierungsprojekt Audio Video Bridging (AVB), welches sich mit der Digitalisierung von Audio- und Videosignalen beschäftigt. Die Mitglieder der AVB Task Group haben hier schnell erkannt, dass die von ihnen erarbeitete Lösung mehr Potenzial aufweist, wenn sie um weitere Funktionen ergänzt wird. Deshalb wurde im Rahmen der IEEE im Standard 802.1 die Time-Sensitive Networking Task Group gegründet.

TSN eröffnet nicht nur in der Automatisierungstechnik neue Möglichkeiten: Die Technologie soll etwa auch zur Vernetzung im Auto oder Flugzeug genutzt werden, was die Stückzahlen entsprechender Chips nach oben treibt und ihre Kosten senkt. Daher haben alle Chiphersteller, die Ethernet-Integrationen anbieten, eine TSN-fähige Hardware freigegeben respektive in naher Zukunft erste Produkte angekündigt. Die TSN-Technologie wird sich somit auch ohne die Automatisierungstechnik entwickeln und etablieren. TSN fließt dann automatisch in Automatisierungsgeräte ein. Die jeweiligen Hersteller müssen den Standard lediglich richtig verwenden. Vor diesem Hintergrund unterstützen bereits zahlreiche Unternehmen und Feldbus-Organisationen die Technologie. Viele Protagonisten suchen eine Migrationsstrategie, um bestehende Lösungen auf den TSN-Standard zu überführen. Ein bekannter Mitstreiter ist die OPC Foundation, die mit OPC UA kein Feldbus-System, sondern ein sicheres, flexibles und skalierbares Datenaustausch-Modell vom Sensor bis in die Cloud propagiert. Als vorteilhaft erweist sich dabei die Einführung des Publisher-/Subscriber-Verfahrens, das optimal zur TSN-Technologie passt. Mit ein Grund, weshalb auch die OPC Foundation schon eine OPC-UA-TSN-Arbeitsgruppe ins Leben rief.

Datenaustausch über Netzwerk-Grenzen hinweg

Streams sichern einen Kanal zwischen Talker und Listener, der – isochron bis hin zu Event-basierte Daten – mit seinen Echtzeit-Anforderungen durch das gesamte Netzwerk leitet.

© Phoenix Contact

Sämtliche Akteure – seien es Standardisierungsgremien, Nutzerorganisationen oder Geräte- und Systemhersteller – bewerben die TSN-Technologie mit dem Begriff ‚Konvergenz für Ethernet-basierte Automatisierungslösungen‘. Im ersten Schritt gilt es deshalb, den Begriff ‚Konvergenz‘ eindeutiger zu beschreiben. Ein Versuch: „In einem konvergenten Automatisierungssystem können mehrere Engineering-Werkzeuge unterschiedliche Datenströme – von synchron mit niedrigen Latenzzeiten bis zu Event-basiert – einrichten und zu jeder Zeit erweitern oder verändern. Der Datenaustausch funktioniert über Netzwerk-Grenzen hinweg.“ Die Verantwortlichen in einem konvergenten System für Teilfunktionen – zum Beispiel die IO-Kommunikation, die Steuerungskommunikation oder auch die Kommunikation in die Cloud – haben folglich die Gewissheit, dass ihre Teillösung weder andere Kommunikation stört noch von dieser beeinträchtigt wird. 

An dieser Stelle gilt es, kurz auf die Technologie einzugehen: TSN-Standards bedienen die Schicht 2 im Ethernet-Kommunikationsmodell. Alle TSN-Teilnehmer in einem solchen Schicht-2-, also geswitchten Netzwerk umfassen eine Zeitsynchronisierungs-Funktion und können sich mittels einer Uhr im System mikrosekundengenau gemäß dem Standard IEEE 802.1ASref abgleichen. Bei der Zeitsynchronisation handelt es sich um eine der letzten TSN-Funktionen auf der unteren Automatisierungsebene, die noch nicht international verabschiedet ist, was aber kurzfristig erfolgen soll. Die einzurichtenden Datenströme heißen Streams und haben eine in der IEEE 802.1Qbu definierte Multicast-MAC-Destinationsadresse.

Wann wird ein Telegramm weitergeleitet?

Skizzierter Überholvorgang eines kurzen, hochprioren Telegramms (HP) an einem langen, niederprioren Telegramm (BE).

© Phoenix Contact

Entgegen der Praxis in heutigen Netzwerken wird die Route eines Telegramms durch einen Switch nicht automatisch gelernt, sondern muss vom Switch im Vorfeld der Telegrammaussendung über den Standard IEEE 802.1Qbv bekannt gemacht werden. Der Standard legt im weitesten Sinne drei verschiedene Konfigurationsmethoden fest: zentral, dezentral und hybrid. Im TSN-Standard gibt es mehrere Spezifikationen, die bestimmen, wann ein Telegramm weiterzuleiten ist. Im Allgemeinen wird dazu eine Stream-Priorität nach dem Strict-Priority-Verfahren herangezogen. Gemäß diesem Standard durchsucht der Switch alle eingehenden Telegramme und sendet diejenigen mit der höchsten Priorität weiter. Der Credit-based Shaper zielt hingegen darauf ab, dass auch Telegramme mit niedrigerer Priorität übermittelt werden, wenn seit langer Zeit nur hochpriore Telegramme kommuniziert worden sind. Soll der Switch zu einem definierten Zeitpunkt lediglich bestimmte Telegramme transportieren, kommt der Time-Aware Shaper zum Einsatz. Er hält in den Switches spezielle Zeiten für Telegramme frei. Niederpriore Telegramme werden zurückgehalten. Um Fehlersituationen zu bewältigen, sind Policies und Filter festgelegt worden. Sie beschreiben, was passiert, wenn ein Telegramm außerhalb der festgesetzten Zeit oder ein Stream öfter als geplant in das Netzwerk eingespeist wird (IEEE 802.1Qbu und IEEE 802.1Qav). 

Neben diesen Standards, die die eigentliche Weiterleitung der Telegramme beeinflussen, ist ein anderer wichtiger Standard zu nennen: Die IEEE 802.1Qbu – ebenso als Frame Preemption bezeichnet – ermöglicht, dass längere durch einen Switch geleitete Telegramme im Fall eines kurzzeitig später eingetroffenen höher priorisierten Telegramms abgeschnitten werden. Nachdem das höher priorisierte Telegramm vorgezogen worden ist, wird der Rest des abgeschnittenen Telegramms dann übertragen. Damit lässt sich insbesondere bei einer Gigabit-Datenrate die Latenzzeit eines höher priorisierten Telegramms deutlich reduzieren.

Laufende Standard-Arbeiten

Tabelle der wichtigsten TSN-Standards

© Phoenix Contact

Da die IEEE fast alle TSN-Standards abgeschlossen hat, versuchen – auf dieser Technologie aufbauend – nun verschiedene Gremien die noch fehlenden Bausteine zu definieren. Sehr wichtig ist eine gemeinsame Normungsgruppe der IEC/IEEE 60802-IA, die relevante Standards in einem Profil für die industrielle Automatisierung vereinen möchte.

Darüber hinaus spezifizieren weitere Organisationen – etwa die AVNU Alliance – allgemeine Definitionen, wie die Standards in einem konvergenten Automatisierungsnetzwerk zusammenlaufen und sich zum Beispiel auch testen lassen. Das Industrial Internet Consortium (IIC) wiederum legt im Rahmen seines TSN-Testbeds in einem Whitepaper sogenannte Traffic-Klassen fest. Hier wird zwischen hochprioren isochronen sowie zyklischen und Event-basierten Klassen unterschieden. Für sämtliche Klassen gibt es eine Definition, welche TSN-Standards wie ausgeprägt sein müssen. Die Traffic-Klassen stellen einen wichtigen Baustein für die zuvor genannten konvergenten Netzwerke dar. Erst wenn sich alle Teilnehmer auf dieses Regelwerk mit seinen TSN-Eigenschaften geeinigt haben, lassen sich Streams aus unterschiedlichen Engineering-Werkzeugen in einem Netzwerk konsistent einrichten. Diese Traffic-Klassen sind natürlich wieder in die Normung zu überführen.

Das LNI-Testbed (Labs Network Industrie 4.0) arbeitet derzeit an einem Interface, mit dem in einem dezentral konfigurierten Netzwerk Streams angelegt und betrieben werden können. In der OPC Foundation wird aktuell eine Schnittstelle präzisiert, wie sich in einem OPC-Pub-/Sub-Netzwerk die Streams für das zentrale Modell erstellen lassen. Eine Herausforderung dieser vielen Aktivitäten ist die kompatible Erweiterung. Nur dann bleibt auch das Ziel der Konvergenz erreichbar. 

Gigabit ist ein Muss

In konvergenten Netzwerken erweist sich eine Hardware-Eigenschaft der neuen TSN-fähigen Chipsätze in den Automatisierungsgeräten – die höhere Netzgeschwindigkeit mit 1 Gigabit oder mehr – als wesentlich. Der Anwender bekommt die Gigabit-Kommunikation quasi geschenkt. TSN wird somit den flächendeckenden Einzug der Gigabit-Technologien vorantreiben. Erst Gigabit ermöglicht die rückwirkungsfreie Nutzung des Netzwerks über konvergent eingerichtete Streams. 

Weitere wichtige Faktoren

Für den Erfolg der TSN-Technologie sind auch nichtfunktionale Anforderungen ausschlaggebend. Sämtliche Protagonisten des TSN-Standards gehen konform, dass die Anwender keinesfalls direkt mit den beschriebenen Technologien konfrontiert werden sollen. Vielmehr sind die TSN-Mechanismen durch Kommunikations-, Applikations- und Geräteprofile – ob auf OPC UA oder anderen Standards basierend – zu verdecken. Der Anwender soll die innere Komplexität des TSN-Systems nicht als solche wahrnehmen. Weitere funktionale kritische Erfolgsfaktoren ergeben sich aus den konvergenten Engineering-Prozessen. Die Automatisierung ist durch ein stark geplantes Vorgehen gekennzeichnet: Die Funktion wird in einer Grobplanung definiert und die Lösung in einer ausgeprägten Engineering-Phase weitestgehend offline zu Ende entwickelt. Verschiedene TSN-Geräte müssen jedoch über eine möglichst einheitliche Gerätebeschreibungssprache in die verschiedenen Engineering-Ökosysteme übernommen werden können. Die Engineering-Ökosysteme haben die Echtzeit-Eigenschaften des gesamten Netzwerks sicher zu kennen, damit während der Inbetriebnahme keine Überraschungen auftreten. 

Im Rahmen der Inbetriebnahme sowie im laufenden Betrieb erweisen sich die Diagnose-Eigenschaften in einem konvergenten Netzwerk als kritischer Erfolgsfaktor. Bei der Diagnose wird die reale Applikation während der Inbetriebnahme mit dem Sollzustand aus der Engineering-Phase verglichen beziehungsweise werden im laufenden Betrieb eher negative Veränderungsprozesse dargestellt. Hier muss sich das TSN-System mit den Diagnose-Eigenschaften aktueller Feldbus-Systeme messen lassen. Selbst ungeschultes Personal sollte in der Lage sein, den Betrieb rund um die Uhr sicher aufrechtzuerhalten. 

Die Vision

Trotz der aufgeführten kritischen Anforderungen an eine einheitliche Gerätebeschreibung und Diagnose, die noch nicht umgesetzt sind, verfügt die TSN-Technologie in Verbindung mit OPC über ein erhebliches Innovationspotenzial. Wenn alle Teilnehmer in einer Sprache Daten untereinander isochron, asynchron oder Event-basiert austauschen können, sind neue Szenarien und Funktionen herstellerübergreifend lösbar. Für die Geräte-Anbieter eröffnet sich darüber hinaus der große Vorteil, dass lediglich eine Hardware-Plattform vorgehalten werden muss, die sich prinzipiell durch ein Firmware-Update auf unterschiedliche Systeme anpassen lässt.

Autor:
Robert Wilmes ist Mitarbeiter im Software Marketing der Business Unit Control Systems bei Phoenix Contact Electronics.

Interview: "TSN ist erst der Anfang"

Findet der 30-jährige Feldbus-Krieg mit einer Einigung auf die Kombi TSN und OPC UA nun ein Ende? Und: Welche Trends kochen parallel zu diesen Technologien in der industriellen Kommunikation hoch? Martin Müller, Vice President Automation Infrastructure, bewertet die Entwicklungen. 

Martin Müller: „TSN wird die Automation prägen – aber nicht allein: Themen wie SPE, APL und 5G stehen schon in den Startlöchern!“

© Phoenix Contact

Herr Müller, Phoenix Contact sieht sich als führender Anbieter der Kommunikations- und Automatisierungstechnik. Wie wichtig ist Ihnen ein einheitlicher, herstellerübergreifender Kommunikationsstandard – wie er jetzt mit der Kombi TSN und OPC UA zum Greifen nahe scheint? 

Martin Müller: Für Phoenix Contact und auch für mich ganz persönlich ist momentan die spannendste Zeit in der über 30-jährigen Geschichte der industriellen Kommunikation. Mit OPC UA in Verbindung mit TSN ist es erstmalig gelungen, unter dem Dach der OPC Foundation mit der Field-Level-Initiative alle großen und wichtigen Hersteller von Automatisierungstechnik an einen Tisch zu bringen und an dem internationalen Standard für industrielle Kommunikation zu arbeiten. Dieser übergreifende Kommunikationsstandard ist damit tatsächlich zum Greifen nah. Nichtsdestotrotz müssen aber noch einige Aktivitäten in den gerade gestarteten Arbeitsgruppen erledigt werden, damit wir von einem wirklich einheitlichen Standard sprechen können.

Sie haben ja 30-jährige Erfahrung mit Feldbus-Rangeleien! Wie zuversichtlich sind Sie, dass dieses Mal tatsächlich alle Akteure aktiv an einem Strang ziehen – und 
der einheitliche Standard Realität wird?  

Martin Müller: Ich bin tatsächlich sehr zuversichtlich, dass es uns dieses Mal gelingen wird, einen einheitlichen Standard zu realisieren. Diese Zuversicht kommt daher, weil bei den vorbereitenden Treffen im letzten Jahr alle beteiligten Akteure erkennen ließen, dass sie die Feldbus-Kriege hinter sich lassen wollen und mit viel Engagement sowie personellem und finanziellem Invest an die Sache herangehen. Außerdem passiert dies auch nicht zum ersten Mal, denn Feldbus-Organisationen und Automatisierungshersteller haben bereits beim Thema FDI – der Field Device Integration – erfolgreich zusammengearbeitet und tun das ebenfalls im APL-Projekt – dem Advanced Physical Layer – für eine Zweidraht-Ethernet-Technologie im Umfeld 
der Prozessautomatisierung.

Wenn das Thema TSN und OPC UA vom Sensor bis zur Cloud unter Dach und Fach ist, können wir dann einen Erledigt-Haken an das Thema Kommunikation in der Fabrik machen?

Martin Müller: Die über 30-jährige Feldbus-Erfahrung hat eines gezeigt: Die Kommunikationstechnologien entwickeln sich kontinuierlich weiter und schaffen so Nutzen für die Anwender und Applikationen. Dies ist auch in Bezug auf die Themen TSN und OPC UA zu sehen. OPC UA wird mit dem FLC-Informationsmodell – auch ohne TSN – die Protokolle und Sichten auf die Felddaten vom Sensor bis in die Cloud vereinheitlichen. TSN wiederum bietet die Basis für eine hochdynamische und deterministische Kommunikation in der Feldebene. Aber es reicht ja noch weiter: Gerade entstehen in den IEEE-Standardisierungsgremien neue Standards für Zweidraht-Ethernet – dem Single Pair Ethernet, kurz SPE –, die angefangen bei der Übertragungsrate von 10 MB/s kostenseitig selbst für die einfachsten Feldgeräte interessant wären. Darauf basierend spezifiziert die APL-Gruppe die Erweiterungen, die notwendig sind, um diese Technologie im Bereich der Prozessindustrie ebenfalls für die eigensichere Übertragung im Feld einzusetzen. Darüber hinaus entwickelt sich insbesondere mit 5G der Mobilfunk-Standard der nächsten Generation, der in Bezug auf Leistungsfähigkeit, Latenz und Deterministik ebenso vollkommen neue Applikationsszenarien eröffnet. 

Wie schnell kommt das Thema 5G für die Fabrik? Was gilt es noch alles zu tun? Wo liegen noch die Probleme?

Martin Müller: Während in einigen Ländern 5G-Technik bereits eingesetzt wird, startet in Deutschland in diesem Jahr die 5G-Frequenzversteigerung. Nicht nur deshalb wird es noch eine Weile dauern, bis die Technologie in der Fabrik in der Breite nutzbar ist. Momentan werden erste private Testzellen aufgebaut, um hier die Leistungs­fähigkeit, aber auch die Grenzen der 5G-Technik in der industriellen Automatisierung zu testen. Darauf basierend beginnen dann Feldversuche zur Erprobung der Technologie in größeren Maßstäben. 

Die Themen SPE und APL befinden sich in der Definitionsphase. Warum sind diese beiden Themen so wichtig? Wo hakt es? Wie würden Sie die Zeitspanne für die Durchsetzung der Technologien sehen?

Martin Müller: SPE und APL sind tatsächlich vielversprechende Technologien, gerade für den Anschluss der einfachen Feldgeräte, die heute nur über Gateways in die überlagerten Kommunikationsarchitekturen eingebunden werden können. Aufbauend auf den Standardisierungsaktivitäten in der IEEE sind Chiphersteller aufgefordert, die Technologien in Serie in ihren Chipsätzen zur Verfügung zu stellen, damit die Hersteller von Automatisierungsgeräten und -systemen diese in ihre Lösungen integrieren können. Die Roadmaps der Chiphersteller gehen davon aus, dass erste prototypische Implementierungen schon im ersten Halbjahr dieses Jahres erhältlich sein werden und Ende 2020 dann Chipsätze in Serie lieferbar sind. Unmittelbar danach werden auch Geräte mit entsprechenden Schnittstellen am Markt angeboten.

Wie ein Damoklesschwert hängt über all diesen Themen die Cyber-Security! Was tun die Anbieter, um dieses Problem in den Griff zu bekommen?

Martin Müller: Ich sehe das Thema Cyber-Security nicht als Damoklesschwert, sondern als wichtigen Aspekt in modernen Automatisierungslösungen. Neben dem Einsatz von Automatisierungskomponenten mit ‚gehärteten‘ Kommunikationsschnittstellen erfordert dies aber auch von den Anwendern eine wesentlich genauere Planung der Automatisierungssysteme unter Einbeziehung möglicher Einfallstore sowie die Umsetzung darauf ausgerichteter Schutzmaßnahmen. Als Hersteller von Automatisierungskomponenten trägt Phoenix Contact dieser Thematik unter anderem durch einen zertifizierten Entwicklungsprozess nach IEC 62443 und entsprechenden Geräten bis hin zu industriellen Routern Rechnung. Um wieder zurück zur ersten Frage zu kommen, bietet gerade ein einheitlicher und herstellerüber­greifender Kommunikationsstandard die besten Voraussetzungen für die Cyber-Security in der Zukunft.