Sind alle TSN-Netzwerke gleich?

© WEKA Fachmedien

TSN-Netzwerke lassen sich, abhängig von den Anforderungen der Anwendungsdomäne in denen sie eingesetzt werden, auf unterschiedliche Art und Weise betreiben. Deshalb ist es wichtig, gemeinsame Spielregeln – etwa das ‚End Station Modell‘ –  für den Betrieb innerhalb eines Netzwerkes festzulegen sowie ihre Eigenschaften und das Set der TSN-Features, die in den Netzwerk-Geräten einheitlich nötig sind.

Das gemeinsame ‚End Station Modell‘ beschreibt einerseits die Mechanismen, mit denen Pakete zeitgesteuert ins Netzwerk übertragen werden. Zudem aber auch, auf welche Weise sich dadurch die entsprechenden Elemente der Netzwerk-Konfiguration einzelnen Applikationen zuweisen lassen. Das gemeinsame Modell ist besonders wichtig für die Konfiguration, denn um Herstellerunabhängig Endgeräte in ein Netzwerk einbinden zu können, muss das Verhalten der Geräte bekannt sein, welches durch die jeweilige Ausprägung von Eigenschaften in den Endgeräten parametriert wird. Für ein gemeinsames Modell sind Eigenschaften wie zeitgesteuertes Senden und Zeit-Synchronisation im Endgerät essenziell. Was nicht zwangsläufig festgelegt werden muss, sondern flexibel und an die jeweilige Applikation anpassbar bleiben sollte, sind Konfigurationsdetails, wie mögliche Zykluszeiten, Anzahl der zeitgesteuerten Sende-Slots und Präzision der Synchronisation. Wenn diese Informationen offengelegt werden, kann eine Konfigurationseinheit dies berücksichtigen.

Ebenso relevant ist das minimale Set an Mechanismen in den TSN-Bridges, welches die Basis für die Quality-of-Service-Garantien (QoS-Garantien) im Netzwerk bildet. Eine Einigung auf gemeinsame Mechanismen – wie etwa Time Aware Shaping und Preemption in TSN-Bridges – bildet die Basis für domänenweite Garantien. Auch hier muss die exakte Ausprägung offen, aber transparent bleiben. Für eine neutrale Definition eines Netzwerks sollte bei der Auswahl der TSN-Features und deren minimalen Ausprägung auf rein abstraktem Niveau der IEEE-Mechanismen gearbeitet werden.

Rene-Hummen ist Manager Technology and Innovation bei Hirschmann Automation and Control.

© Hirschmann

Wie schon erwähnt, wird im realen Einsatz nicht jedes TSN-Netzwerk identisch ausgeprägt sein. Da die Vorgaben für Endgeräte und Bridges ein minimales Set beschreiben, können die Garantien, die in einem Netzwerk gegeben werden können, durch Erweiterung um zusätzliche Features und durch unterschiedliche Ausprägungen dieser Features beeinflusst werden. Hierbei ist zu beachten, dass innerhalb eines Netzwerks Geräte mit einem möglichst einheitlichen Set an Features zum Einsatz kommen sollten. Nur so lassen sich die jeweiligen Mechanismen netzwerkweit einsetzen. Der Schlüssel, um eine entsprechende Homogenität bei den Features in einem Bereich eines Netzwerks zu erreichen, sind TSN-Domänen. Innerhalb einer TSN-Domäne muss gewährleistet sein, dass alle Geräte ein einheitliches Set an Features unterstützen, welches für die Erreichung der Garantien in der TSN-Domäne benötigt und bei der Definition der Domäne vorgegeben wird. Einzelne Geräte können durchaus auch noch zusätzliche Mechanismen bereitstellen. Die Nutzung solcher Mechanismen bringt allerdings nur eingeschränkt weitere Vorteile, da sie nicht zwangsläufig überall vorhanden sind. Eine weitere Eigenschaft einer TSN-Domäne ist, dass innerhalb einer Domäne nur eine Konfigurationseinheit – im zentralen Fall nur eine Centralized Network Configuration (CNC), möglicherweise aber mehrere Centralized User Configuration (CUC) – aktiv sein darf, sodass sich die Netzwerk-Konfiguration immer konsistent halten lässt und nur von einer Stelle aus gesteuert wird.

Das Zusammenspiel dieser einzelnen Komponenten ist im Bild auf der nächsten Seite dargestellt und gewährleistet ein einheitliches Verhalten des Netzwerk-Verkehrs, der mittels der TSN-Mechanismen gesteuert wird. Das exakte Verhalten lässt sich an die Applikationen, das Netzwerk oder die verwendeten Protokolle angepassen, basiert aber immer auf den Features und Eigenschaften, die domänenweit zur Verfügung stehen. 

Ein konkretes Beispiel

Physikalisches Netzwerk mit logischen zentralen Konfigurationseinheiten

© Hirschmann

Durch eine klare Modellierung des Verhaltens von End Stations und Bridges mittels der minimalen Funktionen kann eine Trennung zwischen Applikations- und Netzwerk-Anforderungen entstehen. Am Beispiel OPC FLC ist dies deutlich zu sehen. Dort werden zunächst in der Planungsphase ausschließlich die Applikations-Anforderungen bezüglich Datenmenge und zeitlichem Verhalten modelliert. Hierbei lassen sich alle gängigen Traffic-Modelle, wie Deadline, Cyclic-Latency oder Bandwidth, beschreiben. Bei der Integration geht es um ein allgemeines Setup des Netzwerks, in dessen Rahmen bereits spezifische Richtlinien vorkonfiguriert werden. Beispiele dafür sind Domänengrenzen, an welchen Ingress Shaping angewandt werden soll oder die Zeitsynchronisation innerhalb einer Domäne. Im finalen Schritt, der Operational-Phase, melden sich Applikationen mit ihren Applikations-Anforderungen im Netzwerk an. Diese werden dann, passend zu den in der Domäne bereits konfigurierten Netzwerk-Richtlinien und den in den TSN-Bridges vorhandenen Eigenschaften und Mechanismen, aufgelöst. Dies resultiert in einer Konfiguration des Netzwerks, die sicherstellt, dass die existierenden Quality-of-Service-Anforderungen eingehalten werden.

Stephan Kehrer ist Senior Architect im CTO Office bei Hirschmann Automation and Control.

© Hirschmann

In der Vergangenheit war das Einbinden von neuen Applikationen in existierende Netzwerke eine Aufgabe, die hauptsächlich manuell vorzunehmen war, sofern die Einbindung eine Änderung der QoS-Konfiguration nach sich zog. Da Konfigurationen jedoch schnell komplex werden können, besteht bei einer manuellen Neukonfiguration ein erhebliches Risiko, dass sich Fehler in die Konfigurationen einschleichen. Daher ist es für einen einfachen und flexiblen Einsatz der komplexeren Mechanismen aus dem TSN-Baukasten wichtig, die Übersetzung von Applikations-Anforderungen in eine Konfiguration zu automatisieren. Dies geschieht im zentralen Konfigurationsmodell innerhalb einer TSN-Domäne mithilfe von CUCs und der CNC. Für OPC-UA-Applikationen arbeitet die Working Group OPC UA TSN an der Standardisierung der ­Endgeräte-Schnittstelle. Basierend auf den in IEEE Std 802.1Qcc spezifizierten Modellen übermitteln End Stations ihre Appli­kations-Anforderungen per OPC UA und die CUC und warten auf die Stream-Konfigurationen, die nach erfolgreicher Berechnung und Konfiguration zurückgeliefert werden. In Testbeds hat sich allerdings bereits vor einiger Zeit gezeigt, dass die in IEEE Std 802.1Qcc definierten, grundlegenden Datenstrukturen nicht ausreichend sind, um einen einheitlichen Konfigurations-Workflow zu ermöglichen.

Um diese Lücke zu schließen startete die IEEE 802.1 TSN Task Group mit IEEE P802.1Qdj ein Projekt,  bei dem Hirschmann sich federführend mit einbringt. Ein Hauptziel, das bei diesen Arbeiten verfolgt wird ist: Applikationsingenieuren künftig zu ermöglichen, die zeitlichen Anforderungen der Kommunikation intuitiv zu definieren und zu erreichen, sodass das Netzwerk, sofern noch ausreichende Kapazitäten vorhanden sind, automatisiert die entsprechenden Garantien bereitstellen kann. 

Was gibt es bereits?

Schritte einer automatischen TSN-Stream-Konfiguration mittels CUC und CNC

© Hirschmann

Um eine automatische Integration von Applikationen in bestehende Netzwerke zu ermöglichen, gilt es eine Vielzahl an Szenarien abzudecken. Die Umsetzung in einer einheitlichen Konfigurationsschnittstelle erfordert es, viele Faktoren zu berücksichtigen. Um sicherzustellen, dass möglichst umfassend alle Anforderungen realer Anwendungen erfasst und berücksichtigt sowie mögliche offene Punkte in bestehenden Spezifikationen entdeckt werden, gibt es verschiedene Demonstratoren und herstellerübergreifende Projekte. So wurde zum Beispiel auf der SPS 2018 das erste Mal die Endgeräte-Konfiguration über OPC UA in einem TSN-Netzwerk gezeigt. Auf der TSN/A Conference 2020 wird von Hirschmann und Schneider Electric in einer Präsentation eine Erweiterung dieses Demonstrators als komplett automatische Ende-zu-Ende-Konfiguration, basierend auf den aktuellen Standards der IEEE 802.1 und OPC UA, vorgestellt. 

Wichtig ist, dass die Schnittstellen auf einheitlichem Konsens basieren. Hirschmann hat daher beispielhaft eine OPC-UA-CUC unter dem Namen ‚openCUC‘ auf GitHub veröffentlicht. Diese spiegelt die aktuellen Spezifikationen der OPC UA und IEEE wider, um dadurch umfangreiches Feedback für die Standardisierung einzuholen. Es zeigt, dass die automatische TSN-QoS-Konfiguration keine Zukunftsmusik mehr ist, sondern für alle schon bereitsteht. Für eine größere Reichweite der Aktivitäten und die Kontrolle auf Vollständigkeit der Spezifikationen sind Testbeds, wie in diesem Fall vor allem das IIC Testbed, sehr wichtig.

Die Rolle der Testbeds

Lukas Wüsteney ist Junior Architect im CTO Office bei Hirschmann Automation and Control.

© Hirschmann

Das Thema Konfiguration ist essenziell für den erfolgreichen Einsatz von TSN in produktiven Netzwerken. Die grundlegenden Herangehensweisen, um zukünftig TSN-Netzwerke möglichst einfach und umfassend konfigurieren zu können, sind dabei kein vollständig neues Problem. Einige Modelle und Grundlagen wurden bereits in IEEE Std 802.1Qcc spezifiziert. Darauf aufbauende Erweiterungen und Anpassungen für spezielle Anwendungsbereiche werden momentan in verschiedenen Gremien diskutiert und in Standardisierungsprojekten wie IEEE P802.1Qdj vorangetrieben. Diese Ansätze werden im Rahmen von verschiedenen Testbeds, Demonstratoren sowie Projekten wie der openCUC erprobt und weiterentwickelt. Testbeds sind daher ein gute Möglichkeit, bereits Erfahrungen mit der Konfiguration von TSN-Netzwerken zu sammeln.