Time Sensitive Networking Standardübergreifende konvergente TSN-Netzwerke

Autor / Redakteur: Gunnar Leßmann * / Gerd Kucera

Sollen Netze der Informationstechnik und die der Feldkommunikation verknüpft werden, dann muss die höhere Anforderung der Feldkommunikation sichergestellt sein.

Firmen zum Thema

Zusammengeführt: In der IT beschreibt Netzwerkkonvergenz die gleichzeitige Verwendung eines Netzwerks durch Dienste mit unterschiedlichen Qualitätsanforderungen.
Zusammengeführt: In der IT beschreibt Netzwerkkonvergenz die gleichzeitige Verwendung eines Netzwerks durch Dienste mit unterschiedlichen Qualitätsanforderungen.
(Bild: Phoenix Contact)

In aktuellen Automatisierungslösungen kommen zum einen spezielle Kommunikationssysteme oder Feldbusse für die feldnahe Vernetzung (Operational Technology, OT) sowie andererseits Ethernet zur Kommunikation mit der Leitebene (Information Technology, IT) zum Einsatz. Diese IT- und OT-Systeme werden dabei oft getrennt voneinander in der Anwendung betrieben. Mit TSN ist nun die konvergente Nutzung von IT- und OT-Kommunikation in einem Netzwerk möglich (Bild 1).

In der IT beschreibt Netzwerkkonvergenz die gleichzeitige Verwendung eines Netzwerks durch Dienste mit unterschiedlichen Qualitätsanforderungen, beispielsweise IP-Telefonie (VoIP) und den Transfer großer Dateien. In der Vergangenheit erforderten diese Dienste getrennte Netzwerke. Daher ist die Konvergenz im IT-Bereich die Realität.

Bildergalerie
Bildergalerie mit 5 Bildern

Sollen jetzt IT und OT zusammenwachsen, muss das Gesamt-Netzwerk die erhöhten Qualitätsanforderungen der OT sicherstellen. Diese Anforderungen fallen allgemein unter den Begriff Quality of Service (QoS). Im Vergleich zur IP-Telefonie erweisen sich die QoS-Ansprüche der Automatisierungstechnik als höher, weil hier unter allen Umständen dafür Sorge zu tragen ist, dass ein Fertigungsprozess unter Echtzeitbedingungen weiterläuft und nicht von anderen Diensten im Netz beeinflusst wird.

Mit den IEEE-Standards des Time Sensitive Networking (TSN) lässt sich auch in Kombination mit der IT-Kommunikation ein mit den aktuellen Feldbussen vergleichbarer oder besserer QoS erreichen. Somit ist die Grundlage für das konvergente Netzwerk gelegt. Dieses erlaubt dann die Übertragung großer Datenmengen für Dienste wie die IP-Telefonie, während echtzeitkritische Signale der Remote-I/Os oder Motion-Control-Anwendungen parallel genutzt werden können.

Die Handhabung des Netzwerks soll allerdings so bleiben, wie von Standard-Ethernet bekannt. Es müssen also Netzwerkerweiterungen möglich sein, ohne dass es zu Auswirkungen auf die laufende Echtzeitkommunikation kommt. In diesem Zusammenhang wird von Plug&Produce gesprochen. Bei gleichem Verständnis der Konvergenz lässt sich das Netzwerk sogar von verschiedenen OT-Protokollen nutzen. Zur Schaffung eines solchen Verständnisses haben die beiden relevanten Standardisierungsgremien die Aktivität IEC/IEEE 60802 gegründet. Deren Ziel ist es, konvergente TSN-Netzwerke hersteller- und standardübergreifend umzusetzen (Bild 2).

Reservierung der benötigten Netzwerkressourcen

Da es sich bei TSN im Grunde genommen um eine Vielzahl von Standards handelt, deren Verwendung kombiniert werden kann, gibt es unterschiedliche Anwendungskonzepte. Die folgende Erläuterung beschreibt ein in der IEC/IEEE 60802 erörtertes Einsatzszenario, das ebenfalls bei Profinet über TSN genutzt wird. Darüber hinaus sind weitere Ansätze realisierbar und in der Diskussion. Die verschiedenen Optionen werden auch als Network Policies bezeichnet.

Ein wesentlicher Anspruch an ein konvergentes Netzwerk besteht in der Garantie, dass sich das Netzwerk ohne Auswirkung auf andere bestehende Kommunikationsbeziehungen betreiben und erweitern lässt. Diese Zusicherung ist machbar, wenn vor der Echtzeitübertragung die dafür notwendigen Ressourcen im Netzwerk reserviert sind. Erst bei einer erfolgreichen Reservierung kann eine zuverlässige Echtzeitkommunikation sichergestellt werden. Denn anders als im aktuellen Standard-Ethernet ist es möglich, dass eine Reservierung nicht zum Ziel führt. In diesem Fall erhält das Gerät eine Rückmeldung und darf die Echtzeitübertragung nicht verwenden, um das Netzwerk zu schützen (Bild 3).

Über ein konvergentes Netzwerk soll eine Echtzeitverbindung zwischen der Profinet-Steuerung und einem Profinet-Gerät aufgebaut werden. Im ersten Schritt erfordert dies eine Reservierung von Netzwerk-Ressourcen auf allen Switches, die sich auf dem Pfad von der Steuerung zum Remote-I/O befinden. Dabei prüfen die Switches, ob sie jeweils noch über genügend Ressourcen verfügen, damit der Datenaustausch garantiert stattfinden kann.

Weil sämtliche weiteren Verbindungen ebenfalls über diesen Weg reserviert werden, sind die Switches in der Lage, eine entsprechende Aussage zu treffen. Nur wenn die Reservierung erfolgreich ist, erfolgt im zweiten Schritt die Echtzeitkommunikation. Um die Zuordnung zum Stream sicherzustellen, benötigt die Steuerung eine eindeutige Stream-Identifikation, die bei der Echtzeitübertragung in der Ethernet-Ziel-MAC-Adresse genutzt wird. Nun stellt sich die Frage, wer für die Reservierung und das Management verantwortlich ist. Dies soll nachfolgend erläutert werden.

TSN Management Entity als digitaler Netz-Zwilling

Es liegen verschiedene Konzepte zur Konfiguration eines TSN-Netzwerks vor. Unterschieden wird zwischen einem dezentralen und einem zentralen Ansatz. Beide Modelle weisen spezifische Vor- und Nachteile auf. Die sich anschließenden Erklärungen basieren auf einem zentralen Modell. Hier muss es eine Instanz geben, die als Stellvertreter für das TSN-Netzwerk agiert. In der IEC/IEEE 60802 wird die Instanz als TSN Management Entity (TSN-ME) bezeichnet. Sie stellt den digitalen Zwilling des TSN-Netzwerks dar. Die TSN-ME kann im Netzwerk in einer Steuerung, einem Remote-I/O, Switch oder auf einem PC implementiert sein. Das Funktionsprinzip ist dabei immer gleich (Bild 4).

Im ersten Schritt ermittelt die TSN-ME kontinuierlich die Topologie des TSN-Netzwerks. Auf diese Weise erhält sie eine genaue Kenntnis über dessen derzeitigen physikalischen Aufbau. Ändert sich die Topologie oder kommen Geräte dazu, wandelt sich auch das digitale Abbild in der ME. Dies ist die Voraussetzung für Plug&Produce. Im nächsten Schritt möchte die Steuerung einen Stream für die Echtzeitkommunikation verwenden. Dazu muss sie bei der TSN-ME mit ihren QoS-Anforderungen – beispielsweise Ethernet-Paketgröße, Ethernet-Zykluszeit und gewünschten Kommunikationspartner – anfragen. Über diese Schnittstelle wird der SPS das Ergebnis der Anfrage ebenfalls zurückgemeldet.

Anschließend prüft die TNS-ME auf der Grundlage der Netzwerktopologie, welches der optimale Pfad durch das Netzwerk zum Profinet-Gerät ist. Ferner klärt sie ab, ob in jedem Switch auf dem Weg zum Profinet-Gerät noch ausreichend Bandbreite vorhanden ist, ohne das Netzwerk zu überlasten. Ist dies der Fall, bestimmt die TSN-ME eine Stream-Identifikation und speichert die notwendige Netzwerkkonfiguration in jedem relevanten Switch. Bei dieser Konfiguration handelt es sich technisch um einen statischen Eintrag in der Multicast-Forwarding-Tabelle des Switches, die jetzt eine Angabe zum Empfangsort und Ziel-Port sowie die Stream-Identifikation als Multicast-Adresse enthält.

Ist das Eintragen der Streams in allen Switches erfolgreich abgeschlossen, wird die Stream-Identifikation an die Steuerung zurückgegeben. Die SPS nutzt die Identifikation in der Ethernet-Zieladresse nun für die Echtzeitübertragung. Aufgrund der vorher in den Forwarding-Tabellen der Switches erfassten Routen lässt sich das Echtzeitpakt zuverlässig von der Steuerung zum Profinet-Gerät weiterleiten.

Das beschriebene Verfahren ist grundsätzlich unabhängig davon, ob das TSN-Echtzeitpakt ein Profinet-, OPC UA- oder anderes Echtzeittelegramm transportiert, da lediglich die Stream-Identifikation als Ethernet-Zieladresse zum Einsatz kommt. Es stellt somit ein universelles Konzept dar. Zudem lässt sich die Network Policy in der TSN-ME gegenüber den Endgeräten und Switches abstrahieren.

Priorisieren und synchronisieren der OT-Telegramme

Die Verwendung von reservierten Streams sorgt dafür, dass selbst bei Plug&Produce stets ein echtzeitfähiger Datenaustausch garantiert ist. Jedoch muss noch ein weiteres Problem gelöst werden, das anhand der folgenden Analogie erläutert werden soll: Das Grundprinzip eines Ethernet-Switches lässt sich vereinfacht mit einem Kreisverkehr vergleichen, bei dem sich die aus mehreren Einfahrten kommenden Fahrzeuge eine Ausfahrt teilen müssen. Darüber hinaus gibt es Fahrzeuge, die ihr Ziel schneller und deterministischer erreichen müssen, während andere Fahrzeuge Zeit haben. Das Szenario ist auf den OT- und IT-Verkehr in einem konvergenten Netzwerk übertragbar (Bild 5).

Wie kann jetzt dafür Sorge getragen werden, dass ein Switch die OT-Telegramme vorrangig behandelt, ohne dass es zu einer Störung durch IT-Telegramme kommt? Als Lösung bietet sich die Priorisierung der Ethernet-Telegramme an. Sämtliche echtzeitkritischen Telegramme sind mit einer Prioritätskennzeichnung (dem so genannten Priority-Tag) versehen. OT-Telegramme haben eine höhere Priorität als IT-Telegramme. Gehen mehrere Telegramme mit hoher Priorität beim Switch ein, werden sie gepuffert (das ist vergleichbar mit dem genannten Verkehrsbeispiel bei kleinerem Abstand der Fahrzeuge auf der Fahrspur und an der Ausfahrt).

Eine eigene Uhr vermeidet Überlastung

Telegramme mit hoher Priorität werden dann vor den Paketen mit niedrigerer Priorität verschickt. Auf diese Weise ist immer garantiert, dass der Versand von OT- vor IT-Telegrammen erfolgt. Das Prinzip der Priorisierung findet bereits heute bei Ethernet-basierten Protokollen wie Profinet RT Anwendung. Im schlimmsten Fall kann es allerdings vorkommen, dass die Puffer in den Switches durch viele gleichzeitige OT-Telegramme überlastet werden und damit keine gesicherte Kommunikation mehr möglich ist. Hier hilft die bei TSN nutzbare Uhrzeit-Synchronisation.

Dabei wird für die Echtzeitkommunikation eine eigene Uhr (Working Clock) etabliert, die nicht zwangsläufig auf die globale Uhrzeit (Wall Clock) synchronisiert sein muss. Zur Vermeidung von Überlastungen in den Switches werden nun alle echtzeitkritischen Telegramme zu einem synchronen Zeitpunkt versendet. Dadurch kann es nicht passieren, dass sich unplanbar viele OT-Telegramme in einem Switch stauen. Ein weiterer Vorteil dieser Methode liegt in der Unterstützung von Plug&Produce. Die Reihenfolge der Telegramme spielt keine Rolle. Wichtig ist nur, dass neue Teilnehmer ihre OT-Telegramme synchron verschicken. Die Switches selbst müssen für dieses Verfahren nicht synchronisiert sein. Das reduziert die Komplexität des gesamten Systems.

TSN-Einsatz unabhängig von den OT-Protokollen

Der beschriebene Ansatz sorgt für die erforderliche Robustheit der konvergenten Kommunikation. Es kann jedoch geschehen, dass der Ziel-Port des Switches durch ein langes IT-Telegramm belegt ist, welches erst komplett übermittelt werden muss. In diesem Fall tritt eine Verzögerung der OT-Telegramme auf. Der Werkzeugkasten aus TSN-Standards umfasst auch für dieses Problem eine Lösung. Die sogenannte Preemption ermöglicht die Unterbrechung von IT-Telegrammen, um die OT-Telegramme versenden zu können. So bleibt die Verzögerung von echtzeitkritischer OT-Kommunikation in einem konvergenten Netzwerk sogar bei hoher IT-Last sehr gering.

Durch das erläuterte Konzept wird die konvergente Nutzung von IT- und OT-Kommunikation in einem Netzwerk Realität. Die übergreifende Standardisierung in der IEC/IEEE 60802 bildet außerdem die Grundlage für den TSN-Einsatz unabhängig von OT-Protokollen. Das stellt einen deutlichen Vorteil gegenüber heutigen Lösungen dar.

Migration klassischer Lösungen in TSN-Architekturen

Bei den neuen FL Switch TSN 2300 handelt es sich um die ersten Ethernet-Switches für Time Sensitive Networking (TSN) von Phoenix Contact. Die Geräte erlauben den Aufbau von zeitsynchronen Anwendungen und sorgen für Echtzeitkommunikation und erhöhte Verfügbarkeit in Automatisierungsnetzen. Mit den Funktionen Frame Preemption, Stream-Management und präzise Zeitsynchronisation gemäß IEEE 802.1AS unterstützen sie das Profinet-TSN-Profil. Dazu ermöglichen sie eine einfache TSN-Konfiguration via Profinet 2.4-Engineering, vergleichbar einfach wie beim klassischen Profinet RT. Darüber hinaus gestattet das umfangreiche Feature-Set, das die weiteren Managed Switches von Phoenix Contact ebenfalls bieten, einen universellen Einsatz der TSN-Switches auch in klassischen Applikationen. Auf diese Weise lassen sich heutige Netzwerklösungen einfach in moderne TSN-Architekturen migrieren.

* * Gunnar Leßmann ... Master Specialist Profinet & TSN bei Phoenix Contact Electronics, Bad Pyrmont.

Artikelfiles und Artikellinks

(ID:47392919)