Ist Time Sensitive Networking noch graue Theorie oder lassen sich heute schon TSN-basierte Netzwerke mit Steuerungen unterschiedlicher Hersteller realisieren? An der FH Kempten entstand ein Aufbau mit B&R- und Beckhoff-Steuerungen. Ein Erfahrungsbericht.
Getrieben durch den Nutzen von mehr standardisierten, neuen Technologien kristallisiert sich der Time-Sensitive Networking Standard, kurz TSN, als eine mögliche, echtzeitfähige Feldbus-Alternative heraus. Unterstrichen wird dieses Bild durch den Verzicht auf proprietäre Hardware und Ethernet-Formate, so dass TSN mit und in bestehenden Ethernet-Netzwerken integriert werden kann. Einziger Makel ist, dass sich der TSN-Standard immer noch in einer Definitionsphase befindet, was zu einem momentanen Mangel an nutzbarer Hardware und Software führt und die Evaluierung eines TSN-Netzwerks aufwendig macht.
Für die Umsetzung eines herstellerübergreifenden TSN-Netzwerkes an der Hochschule Kempten kamen folgende Komponenten zum Einsatz: Ein von der Firma B&R bereitgestellter TSN-Ethernet-Switch 0ACST052.1 sowie zwei B&R- und eine Beckhoff-Steuerung. Der TSN-Ethernet-Switch wird für die Umsetzung des herstellerübergreifenden TSN-Netzwerkes zwischen den zwei B&R- und der Beckhoff-Steuerung genutzt, in dem die Teilnehmer per OPC-UA Pub/Sub kommunizieren: eine der B&R-Steuerungen fungiert als Talker/Publisher und hat als Gegenüber eine B&R- sowie eine Beckhoff-Steuerung die als Listener/Subscriber dienen. Test-Datenströme im Netzwerk werden per Wireshark vermessen und das Netzwerk durch nicht-priorisierte Datenströme und Ethernet-Frames mit Maximallänge ausgelastet, um die TSN-Funktionalität auf Herz und Nieren zu überprüfen.
Zur Konfiguration des TSN-Switches, ist das Tool Slate XNS von TTTech Industrial nötig, sowie ein OPC-UA Client, in diesem Fall UaExpert von Unified Automation. Nach der Verbindung per OPC-UA auf den TSN-Switch, muss dort ein Benutzerkonto angelegt und mit den entsprechenden Rollen versehen werden. Das ermöglicht es erst die TSN-Netzwerkkonfiguration vom Tool Slate XNS per Secure Shell und YANG-Modell/XML auf alle am Netzwerk teilnehmenden Geräte zu übertragen.
Ein Realitätscheck |
---|
Time-Sensitive Networking (TSN) ist seit Jahren im Fokus von Forschung, Entwicklung und vielen Diskussionen. Auch wenn nach wie vor Standards in Entwicklung sind und viele Punkte noch nicht final gelöst wurden, stehen zunehmend Produkte in den Startlöchern oder sind bereits am Markt verfügbar. Und gerade hinsichtlich einer verfügbaren Infrastruktur und entsprechenden Hardwarekomponenten ist im Jahr 2022 noch einiges zu erwarten. Es gibt inzwischen auch schon einige Testbeds, die TSN-Szenarien umsetzen und evaluieren – aber diese Beispiele sind in aller Regel doch immer noch Hersteller-getrieben. In diesem Artikel nehmen Prof. Josef Griesbauer und Alexander Sturm von der Hochschule Kempten das Zusammenspiel von Steuerungen zweier Hersteller über TSN aus einer unabhängigen Warte heraus unter die Lupe und erläutern ihren Eindruck. Ein herzliches Dankeschön hierfür von unserer Seite. Wie immer freuen wir uns über Rückmeldungen, Kommentare oder Anregungen zu unserer Serie. Ihr Florian Frick und Meinrad Happacher (redaktion[at]computer-automation.de) |
Beim Anlegen des Netzwerkes in Slate XNS werden die Teilnehmer auf die entsprechenden Ports des TSN-Switches verteilt und der Verbindungstyp – Kupferkabel oder Glasfaser-Verbindung – sowie die Länge des Kabels/der Faser angegeben, um das Transmission-Delay berechnen zu können. Für die Konfiguration der eigentlichen TSN-Streams wird immer ein ‚Talker‘ (Sender) einem oder mehreren ‚Listeners‘ (Empfängern) zugeordnet, sowie eine VLAN-ID und eine VLAN-Priorität vergeben. Diese sind je Stream im Netzwerk unterschiedlich und werden zur Kennzeichnung der TSN-Pakete verwendet, so dass die TSN-Infrastruktur wichtigen Traffic erkennen und per TSN-Stream übertragen kann. Durch unterschiedliche VLAN-IDs und -Prioritäten lassen sich mehrere Datenströme in einem Netzwerk realisieren und priorisieren. Anhand der für jeden Listener angegebenen, maximal erlaubten Latenz, testet Slate XNS, ob eine Transmission innerhalb der Parameter möglich ist, oder ob durch die Netzwerktopologie oder die Kabellängen eine Latenz entstehen würde, die für die sichere Verwendung des Netzwerkes nicht erlaubt ist. Treten Fehler auf, wird der Nutzer gewarnt und kann das Netzwerkprojekt anpassen, um schließlich die Konfiguration eines erfolgreich geplanten TSN-Netzwerkes zu den Teilnehmern zu übertragen.